Re: [RFC] arm64: Early printk support for virtio-mmio console devices.

[Anup Patel]

On 22 April 2013 06:51, Rusty Russell  wrote:
>
> Pranavkumar Sawargaonkar  writes:
> > On 18 April 2013 12:21, Rusty Russell  wrote:
> >>
> >> PranavkumarSawargaonkar  writes:
> >> > From: Pranavkumar Sawargaonkar 
> >> >
> >> > This patch implements early printk support for virtio-mmio console
> >> > devices without using any hypercalls.
> >>
> >> This makes some sense, though not sure that early console *read* makes
> >> much sense.  I can see the PCI version of this being useful as well.
> >
> > Read can be useful for "mach-virt" which will have only virtio console
> > as a console device. Then if someone wants to have UEFI or any other
> > boot-loader emulation, which expects user to input few things, in that
> > case read might become handy.
>
> But implementing virtio inside a bootloader has already been done for
> coreboot, for example.  A bootloader probably wants a virtio block
> device, so a console is trivial.
>
> A single writable field for debugging makes sense.  Anything more is far
> less certain.

The early read can be handy for bootloader who don't want to implement
complete VirtIO programming.

IMHO, early read would be totally optional for host and will not
introduce any new config register so it is good to have in VirtIO
console spec. Also, without early read the read behavior of early_rw
field would be undefined in VirtIO console spec.

>
> Thanks,
> Rusty.

Best Regards,
Anup
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] Early printk support for virtio console devices.

[Anup Patel]

On Wed, May 1, 2013 at 5:56 AM, Alexander Graf  wrote:
>
> On 30.04.2013, at 02:32, Rusty Russell wrote:
>
>> Alexander Graf  writes:
>>> Am 29.04.2013 um 05:09 schrieb Rusty Russell :
>>>
 Alexander Graf  writes:
> On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
>
>> This patch-set implements early printk support for virtio console 
>> devices without using any hypercalls.
>>
>> The current virtio early printk code in kernel expects that hypervisor 
>> will provide some mechanism generally a hypercall to support early 
>> printk. This patch-set does not break existing hypercall based early 
>> print support.
>>
>> This implementation adds:
>> 1. Early writeonly register named early_wr in virtio console's config 
>> space.
>> 2. Host feature flags namely VIRTIO_CONSOLE_F_EARLY_WRITE for telling 
>> guest about early-write capability in console device.
>>
>> Early write mechanism:
>> 1. When a guest wants to out some character, it has to simply write the 
>> character to early_wr register in config space of virtio console device.
>
> I won't nack this patch set, but I'll definitely express that I'm not 
> happy with it.
>
> MMIO registers are handled by a different layer than the virtio console 
> itself. After the virtio refactoring in QEMU, they will be completely 
> separate drivers. So we'll be in a similar mess with early printk as we 
> are on the s390-virtio machine, where early printk is done through 
> hypercalls and thus we can't directly link it to the console output.
>
> I still don't see what the issue is with just implementing a small 
> irq-less virtio driver for early printk.

 Well, this shouldn't be mmio-specific, but I kind of get what you mean.

 I consider this misnamed: it's an emergency write facility.  Linux may
 use it for an early console,
>>>
>>> If Linux uses it for early console, you won't see any messages from before 
>>> the virtio-console driver is initialized, because Linux thinks that it's 
>>> all been printed out.
>>
>> If you can't support it, don't offer the feature.
>
> Fair enough.
>
>>
 but it's also useful for bringup and to
 give a method of emitting errors like "the console ring is corrupt".

 A valid implementation may well be to only offer it with some magic
 qemu developer-only commandline and dump it to stdout.
>>>
>>> Why implement it differently from other machines? There are facilities to 
>>> call into firmware, so you could use that. There's the special Foundation 
>>> model call that you could implement and reuse for this.
>>
>> Sure, for ARM.  We *have* a console device.  It's the logical place to
>> provide a simple write mechanism.  eg. consider bhyve on FreeBSD.
>
> I don't quite see the point. The reason early printk works so well for x86 is 
> that you have a UART at a predefined place.
>
>>
>>> I don't see why anything like this has to live in virtio-mmio. Oh, and it 
>>> should default to off.
>>
>> virtio-console, not virtio-mmio.
>
> How will it live in virtio-console? Virtio-console speaks virtio, not 
> register values. If you put this into the config space you break the s390 
> virtio model.

This is a small limitation of QEMU VirtIO implementation and it can be
easily fixed in QEMU VirtIO.

The VirtIO spec does not tell that VirtIO device specific config
registers are to be emulated by VirtIO transport device (MMIO or PCI).

As per VirtIO spec, the only register that should be emulated by
transport device are the generic VirtIO registers and the VirtIO
device specific config registers should be emulated by VirtIO device
backend.

>
>
> Alex
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--Anup
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] Early printk support for virtio console devices.

[Anup Patel]

On Wed, May 1, 2013 at 7:37 AM, Rusty Russell  wrote:
> Alexander Graf  writes:
>> There are not device specific registers in
>> virtio-console. Virtio-console lives behind a virtio bus which doesn't
>> know what these registers are.
>
> You're not going to make coherent arguments without reading that actual
> patch we're discussing.  And you're going to just waste everyone else's
> time.
>
>> Even if you shove it into config space,
>
> Which is what the patch does...
>
>> it'd be broken because config access happens without intercepts on
>> some platforms.
>
> But people keep assuming it, which is one reason virtio_ccw switched
> from passive lguest-style config to active.  Only lguest and the old kvm
> virtio use it, and lguest can change.
>
> An emergency output is a reasonable idea, and this is a reasonable
> implementation.  The question is practical: will it be used?  Because we
> don't implement reasonable ideas which aren't going to be used.

We are already using it for Guest bring-up on APM ARM64 board using
KVMTOOL and so far it has been really helpful in debugging KVM ARM64
guest issues.

Also, this is a very useful debugging method for Guest bring-up on
other architectures supported by KVM and other Hypervisors that
support VirtIO.

>
> Cheers,
> Rusty.
> ___
> kvmarm mailing list
> kvm...@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

Regards,
Anup
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] Early printk support for virtio console devices.

[Anup Patel]

On 26 April 2013 17:03, Peter Maydell  wrote:
> On 26 April 2013 12:19, Alexander Graf  wrote:
>> MMIO registers are handled by a different layer than the virtio
>> console itself. After the virtio refactoring in QEMU, they will
>> be completely separate drivers.
>
> Good point -- we don't really want to be mixing up the
> transport and the backend. You can see it in the kvmtool
> patch, in fact -- it introduces an "if this is virtio-console"
> special case into the mmio.c file which previously was
> entirely backend agnostic.

Well, we can always have virtio device specific config registers
handle by virtio device backends and generic virtio config register
handled by transport.

kvmtool patch is hacky because it does not provide virtio device
specific config read/write callbacks.

>
> thanks
> -- PMM
> ___
> kvmarm mailing list
> kvm...@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

--Anup
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] Early printk support for virtio console devices.

[Anup Patel]

On 26 April 2013 18:03, Arnd Bergmann  wrote:
> On Friday 26 April 2013 17:36:16 Anup Patel wrote:
>> On 26 April 2013 17:03, Peter Maydell  wrote:
>> > On 26 April 2013 12:19, Alexander Graf  wrote:
>> >> MMIO registers are handled by a different layer than the virtio
>> >> console itself. After the virtio refactoring in QEMU, they will
>> >> be completely separate drivers.
>> >
>> > Good point -- we don't really want to be mixing up the
>> > transport and the backend. You can see it in the kvmtool
>> > patch, in fact -- it introduces an "if this is virtio-console"
>> > special case into the mmio.c file which previously was
>> > entirely backend agnostic.
>>
>> Well, we can always have virtio device specific config registers
>> handle by virtio device backends and generic virtio config register
>> handled by transport.
>>
>> kvmtool patch is hacky because it does not provide virtio device
>> specific config read/write callbacks.
>
> Couldn't kvmtool implement the interface used by smh_printch()
> for early output instead?
>
> Or if that's not a fitting inteface, maybe a psci call for writing
> a character to the console?
>
> Arnd

I am curious about how smh-based or hypercall-based early prints would
be handled in following scenario:

"A board is running KVM ARM enabled kernel and linux console on serial
port. Now a user remotely connects to the board via telnet/ssh and
launches a VM with smh-based or hypercall-based earlyprintk."

In the above scenario, will smh-based or hypercall-based earlyprints
appear to user on remote shell or not ?

--Anup
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND v2 0/8] Cache-coherent DMA access using UIO

[Anup Patel]

The goal of this patchset is to improve UIO framework and UIO dmem
driver to allow cache-coherent DMA accesses from user-space.

This patchset is based on two previous patchsets:
1) [PATCH v5 0/6] UIO driver for APM X-Gene QMTM
(Refer, http://www.spinics.net/lists/devicetree/msg58244.html)
2) [PATCH 0/4] Fix and extend uio_dmem_genirq
(Refer, https://lkml.org/lkml/2016/5/17/141)

We have adopted only patch0-3 of patchset1 which was abandoned
long time back. We have taken care of last few unaddressed comments
on these patches.

The patchset2 is quite recent has been adopted entirely. We have
taken care review comments on these patches too.

This patchset is based on v4.7-rc7 tag and it is available in uio-v2
branch of https://github.com/Broadcom/arm64-linux.git

Changes since v1:
 - Make patch5 as first patch1 and mark it for linux-stable
 - Check return value of dma_set_coherent_mask()
 - Get UIO dmem dynamic region details as module parameter instead
   of getting it from DT node

Ankit Jindal (3):
  uio: code style cleanup
  uio: Add new UIO_MEM_PHYS_CACHE type for mem regions
  Documentation: Update documentation for UIO_MEM_PHYS_CACHE and
UIO_MEM_DEVICE

Anup Patel (2):
  uio: Add new UIO_MEM_DEVICE type for mem regions
  uio: Use new memtypes in uio_dmem_genirq

Jan Viktorin (3):
  uio: fix dmem_region_start computation
  uio: UIO_IRQ_NONE is a valid option for uioinfo->irq
  uio: bind uio_dmem_genirq via OF

 Documentation/DocBook/uio-howto.tmpl |   6 +-
 drivers/uio/uio.c|  32 --
 drivers/uio/uio_dmem_genirq.c| 190 +++
 include/linux/uio_driver.h   |  10 +-
 4 files changed, 182 insertions(+), 56 deletions(-)

-- 
1.9.1

[PATCH RESEND v2 1/8] uio: fix dmem_region_start computation

[Anup Patel]

From: Jan Viktorin 

The variable i contains a total number of resources (including
IORESOURCE_IRQ). However, we want the dmem_region_start to point
after the last resource of type IORESOURCE_MEM. The original behaviour
leads (very likely) to skipping several UIO mapping regions and makes
them useless. Fix this by computing dmem_region_start from the uiomem
which points to the last used UIO mapping.

Fixes: 0a0c3b5a24bd ("Add new uio device for dynamic memory allocation")

Signed-off-by: Jan Viktorin 
Signed-off-by: Anup Patel 
Cc: linux-stable 
---
 drivers/uio/uio_dmem_genirq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/uio/uio_dmem_genirq.c b/drivers/uio/uio_dmem_genirq.c
index 915facb..e1134a4 100644
--- a/drivers/uio/uio_dmem_genirq.c
+++ b/drivers/uio/uio_dmem_genirq.c
@@ -229,7 +229,7 @@ static int uio_dmem_genirq_probe(struct platform_device 
*pdev)
++uiomem;
}
 
-   priv->dmem_region_start = i;
+   priv->dmem_region_start = uiomem - &uioinfo->mem[0];
priv->num_dmem_regions = pdata->num_dynamic_regions;
 
for (i = 0; i < pdata->num_dynamic_regions; ++i) {
-- 
1.9.1

[PATCH RESEND v2 2/8] uio: code style cleanup

[Anup Patel]

From: Ankit Jindal 

This patch fixes the indentation of switch-case block in uio driver.

Signed-off-by: Ankit Jindal 
Signed-off-by: Anup Patel 
---
 drivers/uio/uio.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index fba021f..f2729b7 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -703,13 +703,13 @@ static int uio_mmap(struct file *filep, struct 
vm_area_struct *vma)
}
 
switch (idev->info->mem[mi].memtype) {
-   case UIO_MEM_PHYS:
-   return uio_mmap_physical(vma);
-   case UIO_MEM_LOGICAL:
-   case UIO_MEM_VIRTUAL:
-   return uio_mmap_logical(vma);
-   default:
-   return -EINVAL;
+   case UIO_MEM_PHYS:
+   return uio_mmap_physical(vma);
+   case UIO_MEM_LOGICAL:
+   case UIO_MEM_VIRTUAL:
+   return uio_mmap_logical(vma);
+   default:
+   return -EINVAL;
}
 }
 
-- 
1.9.1

[PATCH RESEND v2 5/8] Documentation: Update documentation for UIO_MEM_PHYS_CACHE and UIO_MEM_DEVICE

[Anup Patel]

From: Ankit Jindal 

This patch updates UIO documentation for new mem region
types UIO_MEM_PHYS_CACHE and UIO_MEM_DEVICE.

Signed-off-by: Ankit Jindal 
Signed-off-by: Anup Patel 
---
 Documentation/DocBook/uio-howto.tmpl | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/uio-howto.tmpl 
b/Documentation/DocBook/uio-howto.tmpl
index cd0e452..de9dafe 100644
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -529,8 +529,10 @@ the memory region, it will show up in the corresponding 
sysfs node.
 int memtype: Required if the mapping is used. Set this to
 UIO_MEM_PHYS if you you have physical memory on your
 card to be mapped. Use UIO_MEM_LOGICAL for logical
-memory (e.g. allocated with kmalloc()). There's also
-UIO_MEM_VIRTUAL for virtual memory.
+memory (e.g. allocated with kmalloc()). There are also
+UIO_MEM_VIRTUAL for virtual memory,
+UIO_MEM_PHYS_CACHE for cacheable physical memory and,
+UIO_MEM_DEVICE for memory mapped device registers.
 
 
 
-- 
1.9.1

[PATCH RESEND v2 4/8] uio: Add new UIO_MEM_DEVICE type for mem regions

[Anup Patel]

On ARM64, the MMU supports special memory attributes for device
memory/registers. Due to this we have pgprot_device() provided
by asm/pgtable.h of arch/arm64.

On architectures that do not have special MMU attribute for device
memory/registers, the asm-generic/pgtable.h maps pgprot_device()
to pgprot_noncached().

This patch introduces a new UIO mem region type UIO_MEM_DEVICE to
represent device registers/memory. The UIO device drivers should
prefer this new UIO mem region type for memory mapped device registers.

Signed-off-by: Anup Patel 
---
 drivers/uio/uio.c  | 4 
 include/linux/uio_driver.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 0e53076..a00990c 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -663,6 +663,9 @@ static int uio_mmap_physical(struct vm_area_struct *vma, 
int memtype)
case UIO_MEM_PHYS_CACHE:
/* Do nothing. */
break;
+   case UIO_MEM_DEVICE:
+   vma->vm_page_prot = pgprot_device(vma->vm_page_prot);
+   break;
default:
return -EINVAL;
}
@@ -714,6 +717,7 @@ static int uio_mmap(struct file *filep, struct 
vm_area_struct *vma)
switch (idev->info->mem[mi].memtype) {
case UIO_MEM_PHYS:
case UIO_MEM_PHYS_CACHE:
+   case UIO_MEM_DEVICE:
return uio_mmap_physical(vma, idev->info->mem[mi].memtype);
case UIO_MEM_LOGICAL:
case UIO_MEM_VIRTUAL:
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 31359aee..7349f95 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -129,6 +129,7 @@ extern void uio_event_notify(struct uio_info *info);
 #define UIO_MEM_LOGICAL2
 #define UIO_MEM_VIRTUAL3
 #define UIO_MEM_PHYS_CACHE 4
+#define UIO_MEM_DEVICE 5
 
 /* defines for uio_port->porttype */
 #define UIO_PORT_NONE  0
-- 
1.9.1

[PATCH RESEND v2 3/8] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions

[Anup Patel]

From: Ankit Jindal 

Currently, three types of mem regions are supported: UIO_MEM_PHYS,
UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps
UIO driver export physcial memory to user space as non-cacheable
user memory. Typcially memory-mapped registers of a device are exported
to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type
is not efficient if dma-capable devices are capable of maintaining
coherency with CPU caches.

This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable
cacheable access to physical memory from user space.

Signed-off-by: Ankit Jindal 
Signed-off-by: Anup Patel 
---
 drivers/uio/uio.c  | 16 +---
 include/linux/uio_driver.h |  9 +
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index f2729b7..0e53076 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -641,7 +641,7 @@ static const struct vm_operations_struct 
uio_physical_vm_ops = {
 #endif
 };
 
-static int uio_mmap_physical(struct vm_area_struct *vma)
+static int uio_mmap_physical(struct vm_area_struct *vma, int memtype)
 {
struct uio_device *idev = vma->vm_private_data;
int mi = uio_find_mem_index(vma);
@@ -656,7 +656,16 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
return -EINVAL;
 
vma->vm_ops = &uio_physical_vm_ops;
-   vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+   switch (memtype) {
+   case UIO_MEM_PHYS:
+   vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+   break;
+   case UIO_MEM_PHYS_CACHE:
+   /* Do nothing. */
+   break;
+   default:
+   return -EINVAL;
+   }
 
/*
 * We cannot use the vm_iomap_memory() helper here,
@@ -704,7 +713,8 @@ static int uio_mmap(struct file *filep, struct 
vm_area_struct *vma)
 
switch (idev->info->mem[mi].memtype) {
case UIO_MEM_PHYS:
-   return uio_mmap_physical(vma);
+   case UIO_MEM_PHYS_CACHE:
+   return uio_mmap_physical(vma, idev->info->mem[mi].memtype);
case UIO_MEM_LOGICAL:
case UIO_MEM_VIRTUAL:
return uio_mmap_logical(vma);
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 32c0e83..31359aee 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -124,10 +124,11 @@ extern void uio_event_notify(struct uio_info *info);
 #define UIO_IRQ_NONE   0
 
 /* defines for uio_mem->memtype */
-#define UIO_MEM_NONE   0
-#define UIO_MEM_PHYS   1
-#define UIO_MEM_LOGICAL2
-#define UIO_MEM_VIRTUAL 3
+#define UIO_MEM_NONE   0
+#define UIO_MEM_PHYS   1
+#define UIO_MEM_LOGICAL2
+#define UIO_MEM_VIRTUAL3
+#define UIO_MEM_PHYS_CACHE 4
 
 /* defines for uio_port->porttype */
 #define UIO_PORT_NONE  0
-- 
1.9.1

[PATCH RESEND v2 6/8] uio: UIO_IRQ_NONE is a valid option for uioinfo->irq

[Anup Patel]

From: Jan Viktorin 

We can simplify handling of platform_get_irq into one place as it is
acceptable to see UIO_IRQ_NONE instead of a valid IRQ number. Some
devices don't have or don't need any interrupt to be handled. The
same change has been already done for uio_pdrv_genirq.

Signed-off-by: Jan Viktorin 
---
 drivers/uio/uio_dmem_genirq.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/uio/uio_dmem_genirq.c b/drivers/uio/uio_dmem_genirq.c
index e1134a4..a4d6d81 100644
--- a/drivers/uio/uio_dmem_genirq.c
+++ b/drivers/uio/uio_dmem_genirq.c
@@ -154,8 +154,6 @@ static int uio_dmem_genirq_probe(struct platform_device 
*pdev)
int i;
 
if (pdev->dev.of_node) {
-   int irq;
-
/* alloc uioinfo for one device */
uioinfo = kzalloc(sizeof(*uioinfo), GFP_KERNEL);
if (!uioinfo) {
@@ -165,13 +163,6 @@ static int uio_dmem_genirq_probe(struct platform_device 
*pdev)
}
uioinfo->name = pdev->dev.of_node->name;
uioinfo->version = "devicetree";
-
-   /* Multiple IRQs are not supported */
-   irq = platform_get_irq(pdev, 0);
-   if (irq == -ENXIO)
-   uioinfo->irq = UIO_IRQ_NONE;
-   else
-   uioinfo->irq = irq;
}
 
if (!uioinfo || !uioinfo->name || !uioinfo->version) {
@@ -200,14 +191,18 @@ static int uio_dmem_genirq_probe(struct platform_device 
*pdev)
priv->pdev = pdev;
mutex_init(&priv->alloc_lock);
 
+   /* Multiple IRQs are not supported */
if (!uioinfo->irq) {
ret = platform_get_irq(pdev, 0);
-   if (ret < 0) {
+   uioinfo->irq = ret;
+   if (ret == -ENXIO && pdev->dev.of_node)
+   uioinfo->irq = UIO_IRQ_NONE;
+   else if (ret < 0) {
dev_err(&pdev->dev, "failed to get IRQ\n");
goto bad1;
}
-   uioinfo->irq = ret;
}
+
uiomem = &uioinfo->mem[0];
 
for (i = 0; i < pdev->num_resources; ++i) {
-- 
1.9.1

[PATCH RESEND v2 8/8] uio: Use new memtypes in uio_dmem_genirq

[Anup Patel]

This patch extends uio_dmem_genirq driver to use recently
added memtypes as follows:
1. Use UIO_MEM_DEVICE memtype for MEM resources
2. Use UIO_MEM_PHYS_CACHE memtype for dynamic regions
when UIO DT node is marked as DMA coherent.

Signed-off-by: Anup Patel 
---
 drivers/uio/uio_dmem_genirq.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/uio/uio_dmem_genirq.c b/drivers/uio/uio_dmem_genirq.c
index 1db2559..ce36afd 100644
--- a/drivers/uio/uio_dmem_genirq.c
+++ b/drivers/uio/uio_dmem_genirq.c
@@ -327,7 +327,7 @@ static int uio_dmem_genirq_probe(struct platform_device 
*pdev)
break;
}
 
-   uiomem->memtype = UIO_MEM_PHYS;
+   uiomem->memtype = UIO_MEM_DEVICE;
uiomem->addr = r->start;
uiomem->size = resource_size(r);
++uiomem;
@@ -343,7 +343,12 @@ static int uio_dmem_genirq_probe(struct platform_device 
*pdev)
" dynamic and fixed memory regions.\n");
break;
}
-   uiomem->memtype = UIO_MEM_PHYS;
+
+   if (pdev->dev.of_node &&
+   of_dma_is_coherent(pdev->dev.of_node))
+   uiomem->memtype = UIO_MEM_PHYS_CACHE;
+   else
+   uiomem->memtype = UIO_MEM_PHYS;
uiomem->addr = DMEM_MAP_ERROR;
uiomem->size = pdata->dynamic_region_sizes[i];
++uiomem;
-- 
1.9.1

[PATCH RESEND v2 7/8] uio: bind uio_dmem_genirq via OF

[Anup Patel]

From: Jan Viktorin 

The uio_dmem_genirq works in a similar ways as uio_pdrv_genirq now.

It accepts the of_id module parameter to specify UIO compatible
string as module parameter. There are few other module parameters
to specify number bits in DMA mask and sizes dynamic regions.

Following are the newly added module parameters:
1) of_id: The UIO compatible string to be used for DT probing
2) dmem_dma_bits: This is the number of DMA mask bits for UIO device.
3) dmem_sizes: This is a formatted string specifying sizes of dynamic
required by some of the UIO devices.

Below are few examples of formatted string for dmem_sizes:
a) UIO dmem device with 3 dynamic regions:
uio_dmem_genirq.dmem_sizes=abc:4K,16K,4M
b) Two UIO dmem devices with different number of dynamic regions:
uio_dmem_genirq.dmem_sizes=abc:4K,16K,4M;xyz:8K

Signed-off-by: Jan Viktorin 
Signed-off-by: Anup Patel 
---
 drivers/uio/uio_dmem_genirq.c | 162 +++---
 1 file changed, 135 insertions(+), 27 deletions(-)

diff --git a/drivers/uio/uio_dmem_genirq.c b/drivers/uio/uio_dmem_genirq.c
index a4d6d81..1db2559 100644
--- a/drivers/uio/uio_dmem_genirq.c
+++ b/drivers/uio/uio_dmem_genirq.c
@@ -12,6 +12,27 @@
  * the Free Software Foundation.
  */
 
+/*
+ * For DeviceTree based platform devices, the compatible string, the DMA mask
+ * bits and sizes of dynamic regions are derived from kernel command-line.
+ *
+ * The format for specifying dynamic region sizes in kernel command line
+ * is as follows:
+ *
+ * uio_dmem_genirq.dmem_sizes := [;]
+ *:= :[,]
+ *  := name as shown in /sys/class/uio/uioX/name
+ *  := standard linux memsize
+ *
+ * Examples:
+ *
+ * 1) UIO dmem device with 3 dynamic regions:
+ * uio_dmem_genirq.dmem_sizes=abc:4K,16K,4M
+ *
+ * 2) Two UIO dmem devices with different number of dynamic regions:
+ * uio_dmem_genirq.dmem_sizes=abc:4K,16K,4M;xyz:8K
+ */
+
 #include 
 #include 
 #include 
@@ -144,46 +165,134 @@ static int uio_dmem_genirq_irqcontrol(struct uio_info 
*dev_info, s32 irq_on)
return 0;
 }
 
+static unsigned int uio_dmem_dma_bits = 32;
+static char uio_dmem_sizes[256];
+
+static int uio_dmem_genirq_alloc_platdata(struct platform_device *pdev)
+{
+   int ret, name_len;
+   u32 regions = 0;
+   char *s, *name, *sz;
+   char *sizes_str = NULL, *sizes_endstr = NULL;
+   struct uio_dmem_genirq_pdata pdata;
+   unsigned long long sizes[MAX_UIO_MAPS];
+
+   memset(&pdata, 0, sizeof(pdata));
+
+   /* Set DMA coherent mask */
+   if (uio_dmem_dma_bits > 64)
+   uio_dmem_dma_bits = 64;
+   ret = dma_set_coherent_mask(&pdev->dev,
+   DMA_BIT_MASK(uio_dmem_dma_bits));
+   if (ret) {
+   dev_err(&pdev->dev, "Unable to dma_set_coherent_mask\n");
+   return ret;
+   }
+
+   /* Find-out start and end of sizes list */
+   s = uio_dmem_sizes;
+   while (*s != '\0') {
+   name = s;
+   s = strchr(s, ':');
+   if (!s)
+   break;
+   name_len = s - name;
+   s++;
+   if (*s == '\0')
+   break;
+   sz = s;
+   s = strchr(s, ';');
+   if (!s)
+   s = &uio_dmem_sizes[strlen(uio_dmem_sizes)];
+   if (strncmp(name, pdev->dev.of_node->name, name_len) == 0) {
+   sizes_str = sz;
+   sizes_endstr = s;
+   break;
+   }
+   s++;
+   }
+
+   /* Parse dynamic regions from sizes list */
+   regions = 0;
+   sizes[0] = 0;
+   while (sizes_str && sizes_endstr &&
+  (sizes_str < sizes_endstr) &&
+  (*sizes_str != '\0') &&
+  (*sizes_str != ';') &&
+  (regions < MAX_UIO_MAPS)) {
+   if (*sizes_str == ',') {
+   sizes_str++;
+   continue;
+   }
+   sizes[regions] = memparse(sizes_str, &sizes_str);
+   if (sizes[regions])
+   regions++;
+   }
+
+   /* Populate platform data */
+   pdata.num_dynamic_regions = regions;
+   pdata.dynamic_region_sizes = devm_kzalloc(&pdev->dev,
+   sizeof(*pdata.dynamic_region_sizes) *
+   pdata.num_dynamic_regions, GFP_KERNEL);
+   if (!pdata.dynamic_region_sizes) {
+   dev_err(&pdev->dev, "Unable to alloc dynamic_region_sizes\n");
+   ret = -ENOMEM;
+   return ret;
+   }
+
+   while (regions--)
+   pdata.dynamic_region_sizes[regions] = sizes[regions];
+
+   pdata.uioinfo.name = pde

Re: [PATCH v4] vfio: platform: reset: Add Broadcom FlexRM reset module

[Anup Patel]

On Fri, Aug 11, 2017 at 12:53 AM, Alex Williamson
 wrote:
> On Wed,  2 Aug 2017 11:08:30 +0530
> Anup Patel  wrote:
>
>> This patch adds Broadcom FlexRM low-level reset for
>> VFIO platform.
>>
>> It will do the following:
>> 1. Disable/Deactivate each FlexRM ring
>> 2. Flush each FlexRM ring
>>
>> The cleanup sequence for FlexRM rings is adapted from
>> Broadcom FlexRM mailbox driver.
>>
>> Signed-off-by: Anup Patel 
>> Reviewed-by: Oza Oza 
>> Reviewed-by: Scott Branden 
>> Reviewed-by: Eric Auger 
>> ---
>>  drivers/vfio/platform/reset/Kconfig|   8 ++
>>  drivers/vfio/platform/reset/Makefile   |   1 +
>>  .../vfio/platform/reset/vfio_platform_bcmflexrm.c  | 100 
>> +
>>  3 files changed, 109 insertions(+)
>>  create mode 100644 drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c
>>
>> diff --git a/drivers/vfio/platform/reset/Kconfig 
>> b/drivers/vfio/platform/reset/Kconfig
>> index 705..8833805 100644
>> --- a/drivers/vfio/platform/reset/Kconfig
>> +++ b/drivers/vfio/platform/reset/Kconfig
>> @@ -13,3 +13,11 @@ config VFIO_PLATFORM_AMDXGBE_RESET
>> Enables the VFIO platform driver to handle reset for AMD XGBE
>>
>> If you don't know what to do here, say N.
>> +
>> +config VFIO_PLATFORM_BCMFLEXRM_RESET
>> + tristate "VFIO support for Broadcom FlexRM reset"
>> + depends on VFIO_PLATFORM && (ARCH_BCM_IPROC || COMPILE_TEST)
>> + help
>> +   Enables the VFIO platform driver to handle reset for Broadcom FlexRM
>> +
>> +   If you don't know what to do here, say N.
>> diff --git a/drivers/vfio/platform/reset/Makefile 
>> b/drivers/vfio/platform/reset/Makefile
>> index 93f4e23..8d9874b 100644
>> --- a/drivers/vfio/platform/reset/Makefile
>> +++ b/drivers/vfio/platform/reset/Makefile
>> @@ -5,3 +5,4 @@ ccflags-y += -Idrivers/vfio/platform
>>
>>  obj-$(CONFIG_VFIO_PLATFORM_CALXEDAXGMAC_RESET) += 
>> vfio-platform-calxedaxgmac.o
>>  obj-$(CONFIG_VFIO_PLATFORM_AMDXGBE_RESET) += vfio-platform-amdxgbe.o
>> +obj-$(CONFIG_VFIO_PLATFORM_BCMFLEXRM_RESET) += vfio_platform_bcmflexrm.o
>> diff --git a/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c 
>> b/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c
>> new file mode 100644
>> index 000..104c3c1
>> --- /dev/null
>> +++ b/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c
>> @@ -0,0 +1,100 @@
>> +/*
>> + * Copyright (C) 2017 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +/*
>> + * This driver provides reset support for Broadcom FlexRM ring manager
>> + * to VFIO platform.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "vfio_platform_private.h"
>> +
>> +/* FlexRM configuration */
>> +#define RING_REGS_SIZE   0x1
>> +#define RING_VER_MAGIC   0x76303031
>> +
>> +/* Per-Ring register offsets */
>> +#define RING_VER 0x000
>> +#define RING_CONTROL 0x034
>> +#define RING_FLUSH_DONE  0x038
>> +
>> +/* Register RING_CONTROL fields */
>> +#define CONTROL_FLUSH_SHIFT  5
>> +
>> +/* Register RING_FLUSH_DONE fields */
>> +#define FLUSH_DONE_MASK  0x1
>> +
>> +static int vfio_platform_bcmflexrm_shutdown(void __iomem *ring)
>> +{
>> + unsigned int timeout;
>> +
>> + /* Disable/inactivate ring */
>> + writel_relaxed(0x0, ring + RING_CONTROL);
>> +
>> + /* Flush ring with timeout of 1s */
>> + timeout = 1000;
>> + writel_relaxed(BIT(CONTROL_FLUSH_SHIFT), ring + RING_CONTROL);
>> + do {
>> + if (readl_relaxed(ring + RING_FLUSH_DONE) & FLUSH_DONE_MASK)
>> + break;
>> + mdelay(1);
>> + } while (timeout--);
>> +
>> + if (!timeout) {
>> + pr_warn("VFIO FlexRM shutdown timeout\n");
>> + return -ETIMEDOUT;
>> + }
>
>
> This doesn't work, timeout is ~0 here.

Sure, I will use "--timeout" instead of "timeout--" which will
fix the issue.

Thanks for pointing.

Regards,
Anup

Re: [PATCH v2 01/16] dmaengine: bcm-sba-raid: Minor improvments in comments

[Anup Patel]

On Thu, Aug 17, 2017 at 9:14 AM, Vinod Koul  wrote:
> On Tue, Aug 01, 2017 at 04:07:45PM +0530, Anup Patel wrote:
>> Make section comments consistent across the Broadcom SBA RAID driver
>> by avoiding " SBA " in some of the comments.
>
> and you add more comments..

OK, I will add this to commit description.

>
>>
>> Signed-off-by: Anup Patel 
>> ---
>>  drivers/dma/bcm-sba-raid.c | 9 ++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index e41bbc7..76999b7 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -48,7 +48,8 @@
>>
>>  #include "dmaengine.h"
>>
>> -/* SBA command related defines */
>> +/* == Driver macros and defines = */
>> +
>>  #define SBA_TYPE_SHIFT   48
>>  #define SBA_TYPE_MASKGENMASK(1, 0)
>>  #define SBA_TYPE_A   0x0
>> @@ -88,6 +89,8 @@
>>  #define to_sba_device(dchan) \
>>   container_of(dchan, struct sba_device, dma_chan)
>>
>> +/* = Driver data structures = */
>
> like this!!
>
>> +
>>  enum sba_request_state {
>>   SBA_REQUEST_STATE_FREE = 1,
>>   SBA_REQUEST_STATE_ALLOCED = 2,
>> @@ -164,7 +167,7 @@ struct sba_device {
>>   int reqs_free_count;
>>  };
>>
>> -/* == SBA command helper routines = */
>> +/* == Command helper routines = */
>>
>>  static inline u64 __pure sba_cmd_enc(u64 cmd, u32 val, u32 shift, u32 mask)
>>  {
>> @@ -196,7 +199,7 @@ static inline u32 __pure sba_cmd_pq_c_mdata(u32 d, u32 
>> b1, u32 b0)
>>  ((d & SBA_C_MDATA_DNUM_MASK) << SBA_C_MDATA_DNUM_SHIFT);
>>  }
>>
>> -/* == Channel resource management routines = */
>> +/* == General helper routines = */
>>

Regards,
Anup

Re: [PATCH v2 03/16] dmaengine: bcm-sba-raid: Common flags for sba_request state and fence

[Anup Patel]

On Thu, Aug 17, 2017 at 9:15 AM, Vinod Koul  wrote:
> On Tue, Aug 01, 2017 at 04:07:47PM +0530, Anup Patel wrote:
>> This patch merges sba_request state and fence into common
>> sba_request flags. Also, in-future we can extend sba_request
>> flags as required.
>
> and it also changes the flag values to bits, which I have no idea why that
> was done, care to explain that please...

I thought its better to have separate bit each sba_request state so
that when a sba_request is accidentally in two states then we can
debug better.

I will restore state values.

Regards,
Anup

Re: [PATCH v2 10/16] dmaengine: bcm-sba-raid: Alloc resources before registering DMA device

[Anup Patel]

On Thu, Aug 17, 2017 at 12:08 PM, Vinod Koul  wrote:
> On Tue, Aug 01, 2017 at 04:07:54PM +0530, Anup Patel wrote:
>> We should allocate DMA channel resources before registering the
>> DMA device in sba_probe() because we can get DMA request soon
>> after registering the DMA device. If DMA channel resources are
>> not allocated before first DMA request then SBA-RAID driver will
>> crash.
>>
>> Signed-off-by: Anup Patel 
>> ---
>>  drivers/dma/bcm-sba-raid.c | 30 +++---
>>  1 file changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index f6616da..f14ed0a 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -1478,13 +1478,13 @@ static int sba_prealloc_channel_resources(struct 
>> sba_device *sba)
>>   int i, j, ret = 0;
>>   struct sba_request *req = NULL;
>>
>> - sba->resp_base = dma_alloc_coherent(sba->dma_dev.dev,
>> + sba->resp_base = dma_alloc_coherent(sba->mbox_dev,
>
> how does this qualify as move before registering, you seem to be using
> different device now

The sba->dma_dev.dev is assigned in sba_async_register().

Now, if we are calling sba_async_register() after
sba_prealloc_channel_resources() then we cannot
use sba->dma_dev.dev in sba_prealloc_channel_resources()

Regards,
Anup

Re: [PATCH v2 15/16] dmaengine: bcm-sba-raid: Add debugfs support

[Anup Patel]

On Thu, Aug 17, 2017 at 1:31 PM, Vinod Koul  wrote:
> On Tue, Aug 01, 2017 at 04:07:59PM +0530, Anup Patel wrote:
>> This patch adds debugfs support to report stats via debugfs
>> which in-turn will help debug hang or error situations.
>>
>> Signed-off-by: Anup Patel 
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Scott Branden 
>> ---
>>  drivers/dma/bcm-sba-raid.c | 82 
>> +-
>>  1 file changed, 81 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index f0a0e80..f9d110c 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -36,6 +36,7 @@
>>   */
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -162,6 +163,9 @@ struct sba_device {
>>   struct list_head reqs_completed_list;
>>   struct list_head reqs_aborted_list;
>>   struct list_head reqs_free_list;
>> + /* DebugFS directory entries */
>> + struct dentry *root;
>> + struct dentry *stats;
>>  };
>>
>>  /* == Command helper routines = */
>> @@ -486,6 +490,45 @@ static void sba_process_received_request(struct 
>> sba_device *sba,
>>   }
>>  }
>>
>> +static void sba_write_stats_in_seqfile(struct sba_device *sba,
>> +struct seq_file *file)
>> +{
>> + unsigned long flags;
>> + struct sba_request *req;
>> + u32 free_count = 0, alloced_count = 0, pending_count = 0;
>> + u32 active_count = 0, aborted_count = 0, completed_count = 0;
>> +
>> + spin_lock_irqsave(&sba->reqs_lock, flags);
>> +
>> + list_for_each_entry(req, &sba->reqs_free_list, node)
>> + free_count++;
>> +
>> + list_for_each_entry(req, &sba->reqs_alloc_list, node)
>> + alloced_count++;
>> +
>> + list_for_each_entry(req, &sba->reqs_pending_list, node)
>> + pending_count++;
>> +
>> + list_for_each_entry(req, &sba->reqs_active_list, node)
>> + active_count++;
>> +
>> + list_for_each_entry(req, &sba->reqs_aborted_list, node)
>> + aborted_count++;
>> +
>> + list_for_each_entry(req, &sba->reqs_completed_list, node)
>> + completed_count++;
>> +
>> + spin_unlock_irqrestore(&sba->reqs_lock, flags);
>> +
>> + seq_printf(file, "maximum requests   = %d\n", sba->max_req);
>> + seq_printf(file, "free requests  = %d\n", free_count);
>> + seq_printf(file, "alloced requests   = %d\n", alloced_count);
>> + seq_printf(file, "pending requests   = %d\n", pending_count);
>> + seq_printf(file, "active requests= %d\n", active_count);
>> + seq_printf(file, "aborted requests   = %d\n", aborted_count);
>> + seq_printf(file, "completed requests = %d\n", completed_count);
>> +}
>> +
>>  /* == DMAENGINE callbacks = */
>>
>>  static void sba_free_chan_resources(struct dma_chan *dchan)
>> @@ -1451,6 +1494,19 @@ static void sba_receive_message(struct mbox_client 
>> *cl, void *msg)
>>   sba_process_received_request(sba, req);
>>  }
>>
>> +/* == Debugfs callbacks == */
>> +
>> +static int sba_debugfs_stats_show(struct seq_file *file, void *offset)
>> +{
>> + struct platform_device *pdev = to_platform_device(file->private);
>> + struct sba_device *sba = platform_get_drvdata(pdev);
>> +
>> + /* Write stats in file */
>> + sba_write_stats_in_seqfile(sba, file);
>> +
>> + return 0;
>> +}
>> +
>>  /* == Platform driver routines = */
>>
>>  static int sba_prealloc_channel_resources(struct sba_device *sba)
>> @@ -1721,10 +1777,30 @@ static int sba_probe(struct platform_device *pdev)
>>   if (ret)
>>   goto fail_free_mchans;
>>
>> + /* Check availability of debugfs */
>> + if (!debugfs_initialized())
>> + goto skip_debugfs;
>> +
>> + /* Create debugfs root entry */
>> + sba->root = debugfs_create_dir(dev_name(sba->dev), NULL);
>> + if (IS_ERR_OR_NULL(sba->root)) {
>> + ret = PTR_ERR_OR_ZERO(sba->root);
>> + goto fail_free_resources;
>
> why fail, debugfs should be an optional thingy, why would you want to fail 
> here?

Yes, we are handling the case when debugfs is not available
and skipping debugfs gracefully.

If debugfs is available then failure of debugfs_create_dir()
should be reported.

Regards,
Anup

Re: [PATCH v2 15/16] dmaengine: bcm-sba-raid: Add debugfs support

[Anup Patel]

On Fri, Aug 18, 2017 at 10:56 AM, Vinod Koul  wrote:
> On Fri, Aug 18, 2017 at 10:33:54AM +0530, Anup Patel wrote:
>> On Thu, Aug 17, 2017 at 1:31 PM, Vinod Koul  wrote:
>> > On Tue, Aug 01, 2017 at 04:07:59PM +0530, Anup Patel wrote:
>> > why fail, debugfs should be an optional thingy, why would you want to fail 
>> > here?
>>
>> Yes, we are handling the case when debugfs is not available
>> and skipping debugfs gracefully.
>>
>> If debugfs is available then failure of debugfs_create_dir()
>> should be reported.
>
> reported yes, bailing out on that err no..

OK, I will put dev_err() instead of bailing out.

Regards,
Anup

Re: [PATCH v2 03/16] dmaengine: bcm-sba-raid: Common flags for sba_request state and fence

[Anup Patel]

On Fri, Aug 18, 2017 at 10:55 AM, Vinod Koul  wrote:
> On Fri, Aug 18, 2017 at 10:26:54AM +0530, Anup Patel wrote:
>> On Thu, Aug 17, 2017 at 9:15 AM, Vinod Koul  wrote:
>> > On Tue, Aug 01, 2017 at 04:07:47PM +0530, Anup Patel wrote:
>> >> This patch merges sba_request state and fence into common
>> >> sba_request flags. Also, in-future we can extend sba_request
>> >> flags as required.
>> >
>> > and it also changes the flag values to bits, which I have no idea why that
>> > was done, care to explain that please...
>>
>> I thought its better to have separate bit each sba_request state so
>> that when a sba_request is accidentally in two states then we can
>> debug better.
>
> that is fine, but you need to comminucate the motivation behind such a
> change!!

Okay, I will add this info to commit description.

>
>>
>> I will restore state values.
>
> either ways am okay, but if we are not using bits smartly then why to change

Okay, I will keep new state values as-is and only update commit
description.

Regards,
Anup

Re: [PATCH v2 09/16] dmaengine: bcm-sba-raid: Improve sba_issue_pending() run duration

[Anup Patel]

On Thu, Aug 17, 2017 at 12:06 PM, Vinod Koul  wrote:
> On Tue, Aug 01, 2017 at 04:07:53PM +0530, Anup Patel wrote:
>> The pending sba_request list can become very long in real-life usage
>> (e.g. setting up RAID array) which can cause sba_issue_pending() to
>> run for long duration.
>
> that raises the warning flags.. Even if we have a long pending list why
> would issue_pending run for long. The purpose of the issue_pending() is to
> submit a txn if idle and return. The interrupt and tasklet shall push the
> subsequent txn to hardware...

Yes, we are doing very similar thing in PATCH13 by further
simplifying sba_process_deferred_requests()

Regards,
Anup

Re: linux-next: build warnings after merge of the clk tree

[Anup Patel]

On Wed, Jun 21, 2017 at 5:04 AM, Stephen Rothwell  wrote:
> Hi all,
>
> After merging the clk tree, today's linux-next build (x86_64 allmodconfig)
> produced these warnings:
>
> WARNING: drivers/clk/bcm/built-in.o(.text+0x4022): Section mismatch in 
> reference from the function sr_genpll3_clk_init() to the function 
> .init.text:iproc_pll_clk_setup()
> The function sr_genpll3_clk_init() references
> the function __init iproc_pll_clk_setup().
> This is often because sr_genpll3_clk_init lacks a __init
> annotation or the annotation of iproc_pll_clk_setup is wrong.
>
> WARNING: drivers/clk/bcm/built-in.o(.text+0x4069): Section mismatch in 
> reference from the function sr_lcpll_pcie_clk_init() to the function 
> .init.text:iproc_pll_clk_setup()
> The function sr_lcpll_pcie_clk_init() references
> the function __init iproc_pll_clk_setup().
> This is often because sr_lcpll_pcie_clk_init lacks a __init
> annotation or the annotation of iproc_pll_clk_setup is wrong.
>
> WARNING: drivers/clk/bcm/built-in.o(.text+0x40b9): Section mismatch in 
> reference from the function sr_lcpll1_clk_init() to the function 
> .init.text:iproc_pll_clk_setup()
> The function sr_lcpll1_clk_init() references
> the function __init iproc_pll_clk_setup().
> This is often because sr_lcpll1_clk_init lacks a __init
> annotation or the annotation of iproc_pll_clk_setup is wrong.
>
> WARNING: drivers/clk/bcm/built-in.o(.text+0x4109): Section mismatch in 
> reference from the function sr_lcpll0_clk_init() to the function 
> .init.text:iproc_pll_clk_setup()
> The function sr_lcpll0_clk_init() references
> the function __init iproc_pll_clk_setup().
> This is often because sr_lcpll0_clk_init lacks a __init
> annotation or the annotation of iproc_pll_clk_setup is wrong.
>
> WARNING: drivers/clk/bcm/built-in.o(.text+0x4159): Section mismatch in 
> reference from the function sr_genpll5_clk_init() to the function 
> .init.text:iproc_pll_clk_setup()
> The function sr_genpll5_clk_init() references
> the function __init iproc_pll_clk_setup().
> This is often because sr_genpll5_clk_init lacks a __init
> annotation or the annotation of iproc_pll_clk_setup is wrong.
>
> WARNING: drivers/clk/bcm/built-in.o(.text+0x41a9): Section mismatch in 
> reference from the function sr_genpll4_clk_init() to the function 
> .init.text:iproc_pll_clk_setup()
> The function sr_genpll4_clk_init() references
> the function __init iproc_pll_clk_setup().
> This is often because sr_genpll4_clk_init lacks a __init
> annotation or the annotation of iproc_pll_clk_setup is wrong.
>
> WARNING: drivers/clk/bcm/built-in.o(.text+0x41f9): Section mismatch in 
> reference from the function sr_genpll0_clk_init() to the function 
> .init.text:iproc_pll_clk_setup()
> The function sr_genpll0_clk_init() references
> the function __init iproc_pll_clk_setup().
> This is often because sr_genpll0_clk_init lacks a __init
> annotation or the annotation of iproc_pll_clk_setup is wrong.
>
> WARNING: drivers/clk/built-in.o(.text+0x14bf2): Section mismatch in reference 
> from the function sr_genpll3_clk_init() to the function 
> .init.text:iproc_pll_clk_setup()
> The function sr_genpll3_clk_init() references
> the function __init iproc_pll_clk_setup().
> This is often because sr_genpll3_clk_init lacks a __init
> annotation or the annotation of iproc_pll_clk_setup is wrong.
>
> WARNING: drivers/clk/built-in.o(.text+0x14c39): Section mismatch in reference 
> from the function sr_lcpll_pcie_clk_init() to the function 
> .init.text:iproc_pll_clk_setup()
> The function sr_lcpll_pcie_clk_init() references
> the function __init iproc_pll_clk_setup().
> This is often because sr_lcpll_pcie_clk_init lacks a __init
> annotation or the annotation of iproc_pll_clk_setup is wrong.
>
> WARNING: drivers/clk/built-in.o(.text+0x14c89): Section mismatch in reference 
> from the function sr_lcpll1_clk_init() to the function 
> .init.text:iproc_pll_clk_setup()
> The function sr_lcpll1_clk_init() references
> the function __init iproc_pll_clk_setup().
> This is often because sr_lcpll1_clk_init lacks a __init
> annotation or the annotation of iproc_pll_clk_setup is wrong.
>
> WARNING: drivers/clk/built-in.o(.text+0x14cd9): Section mismatch in reference 
> from the function sr_lcpll0_clk_init() to the function 
> .init.text:iproc_pll_clk_setup()
> The function sr_lcpll0_clk_init() references
> the function __init iproc_pll_clk_setup().
> This is often because sr_lcpll0_clk_init lacks a __init
> annotation or the annotation of iproc_pll_clk_setup is wrong.
>
> WARNING: drivers/clk/built-in.o(.text+0x14d29): Section mismatch in reference 
> from the function sr_genpll5_clk_init() to the function 
> .init.text:iproc_pll_clk_setup()
> The function sr_genpll5_clk_init() references
> the function __init iproc_pll_clk_setup().
> This is often because sr_genpll5_clk_init lacks a __init
> annotation or the annotation of iproc_pll_clk_setup is wrong.
>
> WARNING: drivers/clk/built-in.o(.text+0x14d79): Section mismatch in reference 

Re: [PATCH] ARM: multi_v7_defconfig: Select RPMSG_VIRTIO as module

[Anup Patel]

Ping ??

--
Anup

Re: [PATCH v3] rpmsg: Allow RPMSG_VIRTIO to be enabled via menuconfig or defconfig

[Anup Patel]

Ping ??

--
Anup

Re: [PATCH v4 03/11] clk: bcm: Add clocks for Stingray SOC

[Anup Patel]

On Fri, May 26, 2017 at 3:03 AM, Michael Turquette
 wrote:
> Hello Anup,
>
> Quoting Anup Patel (2017-05-22 04:58:19)
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>
> Are all of those headers really needed?

Yes, we can reduce the number of headers. I will send
revised patchset.

>
>> +CLK_OF_DECLARE(sr_genpll3_clk, "brcm,sr-genpll3",
>> +   sr_genpll3_clk_init);
>
> Why use CLK_OF_DECLARE here? You've got a proper platform driver here.

Like Sandeep mentioned previously, we have SP804 timers
which require clocks. The sr_genpll3_clk is root clock for
SP804 timer clock. Due to this reason we have registered
sr_genpll3_clk using CLK_OF_DECLARE() and rest of
the clocks via platform driver probe.

Regards,
Anup

[PATCH v5 09/11] arm64: dts: Add I2C DT nodes for Stingray SoC

[Anup Patel]

From: Oza Pawandeep 

This patch adds I2C DT nodes on Stingray SoC.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Vikram Prakash 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 22 ++
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 20 
 2 files changed, 42 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index aad45a2..ff59a26 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -54,6 +54,28 @@
status = "okay";
 };
 
+&i2c0 {
+   status = "okay";
+
+   pca9505: pca9505@20 {
+   compatible = "nxp,pca9505";
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x20>;
+   };
+};
+
+&i2c1 {
+   status = "okay";
+
+   pcf8574: pcf8574@20 {
+   compatible = "nxp,pcf8574a";
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x27>;
+   };
+};
+
 &nand {
status = "ok";
nandcs@0 {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 059086f..8a077ff 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -269,6 +269,16 @@
 
#include "stingray-pinctrl.dtsi"
 
+   i2c0: i2c@689b {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x000b 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
+
gpio_hsls: gpio@689d {
compatible = "brcm,iproc-gpio";
reg = <0x000d 0x864>;
@@ -295,6 +305,16 @@
<&pinmux 151 91 4>;
};
 
+   i2c1: i2c@689e {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x000e 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
+
uart0: uart@68a0 {
device_type = "serial";
compatible = "snps,dw-apb-uart";
-- 
2.7.4

[PATCH v5 04/11] arm64: dts: Initial DTS files for Broadcom Stingray SOC

[Anup Patel]

The Broadcom Stingray SoC is a new member in Broadcom iProc
SoC family.

This patch adds initial DTS files for Broadcom Stingray SoC
and two of its reference boards (bcm958742k and bcm958742t).

We have lot of reference boards and large number of devices
in Broadcom Stingray SoC so eventually we will have quite
a few DTS files for Stingray. To tackle, we have added a
separate directory for Stingray DTS files.

Signed-off-by: Anup Patel 
Signed-off-by: Scott Branden 
Reviewed-by: Ray Jui 
---
 arch/arm64/boot/dts/broadcom/Makefile  |   1 +
 arch/arm64/boot/dts/broadcom/stingray/Makefile |   6 +
 .../boot/dts/broadcom/stingray/bcm958742-base.dtsi |  55 
 .../boot/dts/broadcom/stingray/bcm958742k.dts  |  48 
 .../boot/dts/broadcom/stingray/bcm958742t.dts  |  40 +++
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 302 +
 6 files changed, 452 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/Makefile
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/Makefile 
b/arch/arm64/boot/dts/broadcom/Makefile
index bfa8f8e..f11bdd6 100644
--- a/arch/arm64/boot/dts/broadcom/Makefile
+++ b/arch/arm64/boot/dts/broadcom/Makefile
@@ -1,6 +1,7 @@
 dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-3-b.dtb
 dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb ns2-xmc.dtb
 
+dts-dirs   := stingray
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
 clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/broadcom/stingray/Makefile 
b/arch/arm64/boot/dts/broadcom/stingray/Makefile
new file mode 100644
index 000..f70028e
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/Makefile
@@ -0,0 +1,6 @@
+dtb-$(CONFIG_ARCH_BCM_IPROC) += bcm958742k.dtb
+dtb-$(CONFIG_ARCH_BCM_IPROC) += bcm958742t.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
new file mode 100644
index 000..992944b
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -0,0 +1,55 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2016-2017 Broadcom.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "stingray.dtsi"
+
+/ {
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   aliases {
+   serial0 = &uart1;
+   serial1 = &uart0;
+   serial2 = &uart2;
+   serial3 = &uart3;
+   };
+};
+
+&memory { /* Default DRAM banks */
+   reg = <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */
+ <0x0008 0x8000 0x1 0x8000>; /* 6G @ 34G */
+};
+
+&uart1 {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
new file mode 100644
index 000..c309cda
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
@@ -0,0 +1,48 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2016-2017 Broadcom.  All rights reserved.

[PATCH v5 06/11] arm64: dts: Add NAND DT nodes for Stingray SOC

[Anup Patel]

From: Pramod Kumar 

This patch adds NAND controller DT Node and NAND chip DT
node for Stingray SOC and Stingray reference boards.

Signed-off-by: Pramod Kumar 
Signed-off-by: Abhishek Shah 
Reviewed-by: Vikram Prakash 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi | 15 +++
 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi   | 13 +
 2 files changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index 992944b..aad45a2 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -53,3 +53,18 @@
 &uart1 {
status = "okay";
 };
+
+&nand {
+   status = "ok";
+   nandcs@0 {
+   compatible = "brcm,nandcs";
+   reg = <0>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <8>;
+   nand-ecc-step-size = <512>;
+   nand-bus-width = <16>;
+   brcm,nand-oob-sector-size = <16>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+};
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 6b690db..003f814 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -307,5 +307,18 @@
compatible = "brcm,iproc-rng200";
reg = <0x0022 0x28>;
};
+
+   nand: nand@68c6 {
+   compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+   reg = <0x0036 0x600>,
+ <0x0050a408 0x600>,
+ <0x00360f00 0x20>;
+   reg-names = "nand", "iproc-idm", "iproc-ext";
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   brcm,nand-has-wp;
+   status = "disabled";
+   };
};
 };
-- 
2.7.4

[PATCH v5 05/11] arm64: dts: Add clock DT nodes for Stingray SOC

[Anup Patel]

From: Sandeep Tripathy 

This patch describes Stingray SOC clock tree using
DT nodes in Stingray DTS.

Signed-off-by: Sandeep Tripathy 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../boot/dts/broadcom/stingray/stingray-clock.dtsi | 170 +
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi |   9 ++
 2 files changed, 179 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi
new file mode 100644
index 000..070e22e2
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi
@@ -0,0 +1,170 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2016-2017 Broadcom.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+
+   osc: oscillator {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <5000>;
+   };
+
+   crmu_ref25m: crmu_ref25m {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <&osc>;
+   clock-div = <2>;
+   clock-mult = <1>;
+   };
+
+   genpll0: genpll0@6641d104 {
+   #clock-cells = <1>;
+   compatible = "brcm,sr-genpll0";
+   reg = <0x0001d104 0x32>,
+ <0x0001c854 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "genpll0", "clk_125", "clk_scr",
+"clk_250", "clk_pcie_axi",
+"clk_paxc_axi_x2",
+"clk_paxc_axi";
+   };
+
+   genpll3: genpll3@6641d1e0 {
+   #clock-cells = <1>;
+   compatible = "brcm,sr-genpll3";
+   reg = <0x0001d1e0 0x32>,
+ <0x0001c854 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "genpll3", "clk_hsls",
+"clk_sdio";
+   };
+
+   genpll4: genpll4@6641d214 {
+   #clock-cells = <1>;
+   compatible = "brcm,sr-genpll4";
+   reg = <0x0001d214 0x32>,
+ <0x0001c854 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "genpll4", "clk_ccn",
+"clk_tpiu_pll", "noc_clk",
+"pll_chclk_fs4",
+"clk_bridge_fscpu";
+   };
+
+   genpll5: genpll5@6641d248 {
+   #clock-cells = <1>;
+   compatible = "brcm,sr-genpll5";
+   reg = <0x0001d248 0x32>,
+ <0x0001c870 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "genpll5", "fs4_hf_clk",
+"crypto_ae_clk", "raid_ae_clk";
+   };
+
+   lcpll0: lcpll0 {
+   #clock-cells = <1>;
+   

[PATCH v5 08/11] arm64: dts: Add GPIO DT nodes for Stingray SOC

[Anup Patel]

From: Pramod Kumar 

The GPIOs on Stingray SOC are based on iProc GPIOs hence
using this we add GPIO DT nodes for Stingray SOC.

Signed-off-by: Pramod Kumar 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index a4afd44..059086f 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -251,6 +251,14 @@
ranges = <0x0 0x0 0x6640 0x10>;
 
#include "stingray-clock.dtsi"
+
+   gpio_crmu: gpio@66424800 {
+   compatible = "brcm,iproc-gpio";
+   reg = <0x00024800 0x4c>;
+   ngpios = <6>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   };
};
 
hsls {
@@ -261,6 +269,32 @@
 
#include "stingray-pinctrl.dtsi"
 
+   gpio_hsls: gpio@689d {
+   compatible = "brcm,iproc-gpio";
+   reg = <0x000d 0x864>;
+   ngpios = <151>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   interrupt-controller;
+   interrupts = ;
+   gpio-ranges = <&pinmux 0 0 16>,
+   <&pinmux 16 71 2>,
+   <&pinmux 18 131 8>,
+   <&pinmux 26 83 6>,
+   <&pinmux 32 123 4>,
+   <&pinmux 36 43 24>,
+   <&pinmux 60 89 2>,
+   <&pinmux 62 73 4>,
+   <&pinmux 66 95 28>,
+   <&pinmux 94 127 4>,
+   <&pinmux 98 139 10>,
+   <&pinmux 108 16 27>,
+   <&pinmux 135 77 6>,
+   <&pinmux 141 67 4>,
+   <&pinmux 145 149 6>,
+   <&pinmux 151 91 4>;
+   };
+
uart0: uart@68a0 {
device_type = "serial";
compatible = "snps,dw-apb-uart";
-- 
2.7.4

[PATCH v5 07/11] arm64: dts: Add pinctrl DT nodes for Stingray SOC

[Anup Patel]

From: Pramod Kumar 

This patch adds pinctrl and pinmux related DT nodes for
Stingray SOC.

For manageability, pinctrl and pinmum DT nodes are added
as separate DTSi file and included in main DTSi file.

Signed-off-by: Pramod Kumar 
Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Vikram Prakash 
Reviewed-by: Scott Branden 
---
 .../dts/broadcom/stingray/stingray-pinctrl.dtsi| 345 +
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi |   2 +
 .../dt-bindings/pinctrl/brcm,pinctrl-stingray.h|  68 
 3 files changed, 415 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi
 create mode 100644 include/dt-bindings/pinctrl/brcm,pinctrl-stingray.h

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi
new file mode 100644
index 000..af5d480
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi
@@ -0,0 +1,345 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2016-2017 Broadcom.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+
+   pinconf: pinconf@68a4 {
+   compatible = "pinconf-single";
+   reg = <0x0014 0x250>;
+   pinctrl-single,register-width = <32>;
+
+   /* pinconf functions */
+   };
+
+   pinmux: pinmux@68a4029c {
+   compatible = "pinctrl-single";
+   reg = <0x0014029c 0x250>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   pinctrl-single,register-width = <32>;
+   pinctrl-single,function-mask = <0xf>;
+   pinctrl-single,gpio-range = <
+   &range 0 154 MODE_GPIO
+   >;
+   range: gpio-range {
+   #pinctrl-single,gpio-range-cells = <3>;
+   };
+
+   /* pinctrl functions */
+   tsio_pins: pinmux_gpio_14 {
+   pinctrl-single,pins = <
+   0x038 MODE_NITRO /* tsio_0 */
+   0x03c MODE_NITRO /* tsio_1 */
+   >;
+   };
+
+   nor_pins: pinmux_pnor_adv_n {
+   pinctrl-single,pins = <
+   0x0ac MODE_PNOR /* nand_ce1_n */
+   0x0b0 MODE_PNOR /* nand_ce0_n */
+   0x0b4 MODE_PNOR /* nand_we_n */
+   0x0b8 MODE_PNOR /* nand_wp_n */
+   0x0bc MODE_PNOR /* nand_re_n */
+   0x0c0 MODE_PNOR /* nand_rdy_bsy_n */
+   0x0c4 MODE_PNOR /* nand_io0_0 */
+   0x0c8 MODE_PNOR /* nand_io1_0 */
+   0x0cc MODE_PNOR /* nand_io2_0 */
+   0x0d0 MODE_PNOR /* nand_io3_0 */
+   0x0d4

[PATCH v5 10/11] arm64: dts: Add PL022, PL330 and SP805 DT nodes for Stingray

[Anup Patel]

We have two instance of PL022 SPI controllers, one instance of
DMA PL330, and one non-secure SP805 Watchdog on Stingray SOC.

This patch adds DT nodes for the above mentioned devices in
Stingray DT.

Signed-off-by: Anup Patel 
Reviewed-by: Pramod KUMAR 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../boot/dts/broadcom/stingray/bcm958742k.dts  | 30 +
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 52 ++
 2 files changed, 82 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
index c309cda..5671669 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
@@ -46,3 +46,33 @@
 &uart3 {
status = "okay";
 };
+
+&ssp0 {
+   pinctrl-0 = <&spi0_pins>;
+   pinctrl-names = "default";
+   cs-gpios = <&gpio_hsls 34 0>;
+   status = "okay";
+
+   spi-flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <2000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+};
+
+&ssp1 {
+   pinctrl-0 = <&spi1_pins>;
+   pinctrl-names = "default";
+   cs-gpios = <&gpio_hsls 96 0>;
+   status = "okay";
+
+   spi-flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <2000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+};
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 8a077ff..642d42c 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -279,6 +279,14 @@
status = "disabled";
};
 
+   wdt0: watchdog@689c {
+   compatible = "arm,sp805", "arm,primecell";
+   reg = <0x000c 0x1000>;
+   interrupts = ;
+   clocks = <&hsls_25m_div2_clk>, <&hsls_div4_clk>;
+   clock-names = "wdogclk", "apb_pclk";
+   };
+
gpio_hsls: gpio@689d {
compatible = "brcm,iproc-gpio";
reg = <0x000d 0x864>;
@@ -359,11 +367,55 @@
status = "disabled";
};
 
+   ssp0: ssp@68a8 {
+   compatible = "arm,pl022", "arm,primecell";
+   reg = <0x0018 0x1000>;
+   interrupts = ;
+   clocks = <&hsls_div2_clk>, <&hsls_div2_clk>;
+   clock-names = "spiclk", "apb_pclk";
+   num-cs = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   ssp1: ssp@68a9 {
+   compatible = "arm,pl022", "arm,primecell";
+   reg = <0x0019 0x1000>;
+   interrupts = ;
+   clocks = <&hsls_div2_clk>, <&hsls_div2_clk>;
+   clock-names = "spiclk", "apb_pclk";
+   num-cs = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
hwrng: hwrng@68b2 {
compatible = "brcm,iproc-rng200";
reg = <0x0022 0x28>;
};
 
+   dma0: dma@68c1 {
+   compatible = "arm,pl330", "arm,primecell";
+   reg = <0x0031 0x1000>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+;
+   #dma-cells = <1>;
+   #dma-channels = <8>;
+   #dma-requests = <32>;
+   clocks = <&hsls_div2_clk>;
+   clock-names = "apb_pclk";
+   iommus = <&smmu 0x6000 0x>;
+   };
+
nand: nand@68c6 {
compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
reg = <0x0036 0x600>,
-- 
2.7.4

[PATCH v5 11/11] arm64: dts: Add PWM and SDHCI DT nodes for Stingray SOC

[Anup Patel]

From: Srinath Mannam 

The Stingray SoC has two instances of SDHCI controller
and one instance of iProc PWM.

Let's enable above mentioned devices in Stingray DT.

Signed-off-by: Srinath Mannam 
Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 39 ++
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 28 
 2 files changed, 67 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index ff59a26..5dca7d1 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -43,6 +43,28 @@
serial2 = &uart2;
serial3 = &uart3;
};
+
+   sdio0_vddo_ctrl_reg: sdio0_vddo_ctrl {
+   compatible = "regulator-gpio";
+   regulator-name = "sdio0_vddo_ctrl_reg";
+   regulator-type = "voltage";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   gpios = <&pca9505 18 0>;
+   states = <330 0x0
+ 180 0x1>;
+   };
+
+   sdio1_vddo_ctrl_reg: sdio1_vddo_ctrl {
+   compatible = "regulator-gpio";
+   regulator-name = "sdio1_vddo_ctrl_reg";
+   regulator-type = "voltage";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   gpios = <&pca9505 19 0>;
+   states = <330 0x0
+ 180 0x1>;
+   };
 };
 
 &memory { /* Default DRAM banks */
@@ -54,6 +76,10 @@
status = "okay";
 };
 
+&pwm {
+   status = "okay";
+};
+
 &i2c0 {
status = "okay";
 
@@ -90,3 +116,16 @@
#size-cells = <1>;
};
 };
+
+&sdio0 {
+   vqmmc-supply = <&sdio0_vddo_ctrl_reg>;
+   non-removable;
+   full-pwr-cycle;
+   status = "okay";
+};
+
+&sdio1 {
+   vqmmc-supply = <&sdio1_vddo_ctrl_reg>;
+   full-pwr-cycle;
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 642d42c..44ed73c 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -269,6 +269,14 @@
 
#include "stingray-pinctrl.dtsi"
 
+   pwm: pwm@6891{
+   compatible = "brcm,iproc-pwm";
+   reg = <0x0001 0x1000>;
+   clocks = <&crmu_ref25m>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
i2c0: i2c@689b {
compatible = "brcm,iproc-i2c";
reg = <0x000b 0x100>;
@@ -428,5 +436,25 @@
brcm,nand-has-wp;
status = "disabled";
};
+
+   sdio0: sdhci@68cf1000 {
+   compatible = "brcm,sdhci-iproc";
+   reg = <0x003f1000 0x100>;
+   interrupts = ;
+   bus-width = <8>;
+   clocks = <&sdio0_clk>;
+   iommus = <&smmu 0x6002 0x>;
+   status = "disabled";
+   };
+
+   sdio1: sdhci@68cf2000 {
+   compatible = "brcm,sdhci-iproc";
+   reg = <0x003f2000 0x100>;
+   interrupts = ;
+   bus-width = <8>;
+   clocks = <&sdio1_clk>;
+   iommus = <&smmu 0x6003 0x>;
+   status = "disabled";
+   };
};
 };
-- 
2.7.4

[PATCH v5 01/11] dt-bindings: bcm: Add Broadcom Stingray bindings document

[Anup Patel]

This patch adds DT bindings info for Broadcom Stingray SOC
and related reference boards.

Signed-off-by: Anup Patel 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt 
b/Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt
new file mode 100644
index 000..23a0217
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt
@@ -0,0 +1,12 @@
+Broadcom Stingray device tree bindings
+
+
+Boards with Stingray shall have the following properties:
+
+Required root node property:
+
+Stingray Combo SVK board
+compatible = "brcm,bcm958742k", "brcm,stingray";
+
+Stingray SST100 board
+compatible = "brcm,bcm958742t", "brcm,stingray";
-- 
2.7.4

[PATCH v5 00/11] Broadcom Stingray SOC Initial Support

[Anup Patel]

This patchset adds initial support of Broadcom Stingray SOC
by reusing existing Broadcom iProc device drivers.

Most of the patches in this patchset are DT patches except
the Stingray clock tree support which just one patch.

This patchset is based on Linux-4.12-rc2 and it is also available
at stingray-v5 branch of https://github.com/Broadcom/arm64-linux.git

Changes since v4:
 - Reduce number of include headers in Stingray clk driver

Changes since v3:
 - Rebased patches for Linux-4.12-rc1
 - Updated PATCH3 to have all clocks except genpll3 to be
   registered via platform driver probe

Changes since v2:
 - Remove default bootargs from chosen DT node
 - Remove "linux" prefix from stdout DT attribute of chosen DT node
 - Remove use of GIC_CPU_MASK_xxx() for PPIs

Changes since v1:
 - Rebased patches for Linux-4.12-rc1
 - Removed unwanted /memreserve/ from bcm958742-base.dtsi
 - Use ranges DT property to clear view of memory-layout
 - Make bcm-sr.h part of clock DT bindings patch

Anup Patel (3):
  dt-bindings: bcm: Add Broadcom Stingray bindings document
  arm64: dts: Initial DTS files for Broadcom Stingray SOC
  arm64: dts: Add PL022, PL330 and SP805 DT nodes for Stingray

Oza Pawandeep (1):
  arm64: dts: Add I2C DT nodes for Stingray SoC

Pramod Kumar (3):
  arm64: dts: Add NAND DT nodes for Stingray SOC
  arm64: dts: Add pinctrl DT nodes for Stingray SOC
  arm64: dts: Add GPIO DT nodes for Stingray SOC

Sandeep Tripathy (3):
  dt-bindings: clk: Extend binding doc for Stingray SOC
  clk: bcm: Add clocks for Stingray SOC
  arm64: dts: Add clock DT nodes for Stingray SOC

Srinath Mannam (1):
  arm64: dts: Add PWM and SDHCI DT nodes for Stingray SOC

 .../devicetree/bindings/arm/bcm/brcm,stingray.txt  |  12 +
 .../bindings/clock/brcm,iproc-clocks.txt   |  76 
 arch/arm64/boot/dts/broadcom/Makefile  |   1 +
 arch/arm64/boot/dts/broadcom/stingray/Makefile |   6 +
 .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 131 ++
 .../boot/dts/broadcom/stingray/bcm958742k.dts  |  78 
 .../boot/dts/broadcom/stingray/bcm958742t.dts  |  40 ++
 .../boot/dts/broadcom/stingray/stingray-clock.dtsi | 170 
 .../dts/broadcom/stingray/stingray-pinctrl.dtsi| 345 
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 460 +
 drivers/clk/bcm/Kconfig|   8 +
 drivers/clk/bcm/Makefile   |   1 +
 drivers/clk/bcm/clk-sr.c   | 320 ++
 include/dt-bindings/clock/bcm-sr.h | 101 +
 .../dt-bindings/pinctrl/brcm,pinctrl-stingray.h|  68 +++
 15 files changed, 1817 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/Makefile
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
 create mode 100644 drivers/clk/bcm/clk-sr.c
 create mode 100644 include/dt-bindings/clock/bcm-sr.h
 create mode 100644 include/dt-bindings/pinctrl/brcm,pinctrl-stingray.h

-- 
2.7.4

[PATCH v5 03/11] clk: bcm: Add clocks for Stingray SOC

[Anup Patel]

From: Sandeep Tripathy 

This patch adds support for Stingray clocks in iproc
ccf. The Stingray SOC has various plls based on iproc
pll architecture.

Signed-off-by: Sandeep Tripathy 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/clk/bcm/Kconfig  |   8 ++
 drivers/clk/bcm/Makefile |   1 +
 drivers/clk/bcm/clk-sr.c | 320 +++
 3 files changed, 329 insertions(+)
 create mode 100644 drivers/clk/bcm/clk-sr.c

diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
index b5ae531..1d9187d 100644
--- a/drivers/clk/bcm/Kconfig
+++ b/drivers/clk/bcm/Kconfig
@@ -46,3 +46,11 @@ config CLK_BCM_NS2
default ARCH_BCM_IPROC
help
  Enable common clock framework support for the Broadcom Northstar 2 SoC
+
+config CLK_BCM_SR
+   bool "Broadcom Stingray clock support"
+   depends on ARCH_BCM_IPROC || COMPILE_TEST
+   select COMMON_CLK_IPROC
+   default ARCH_BCM_IPROC
+   help
+ Enable common clock framework support for the Broadcom Stingray SoC
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index d9dc848..a0c14fa 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_ARCH_BCM_53573)  += clk-bcm53573-ilp.o
 obj-$(CONFIG_CLK_BCM_CYGNUS)   += clk-cygnus.o
 obj-$(CONFIG_CLK_BCM_NSP)  += clk-nsp.o
 obj-$(CONFIG_CLK_BCM_NS2)  += clk-ns2.o
+obj-$(CONFIG_CLK_BCM_SR)   += clk-sr.o
diff --git a/drivers/clk/bcm/clk-sr.c b/drivers/clk/bcm/clk-sr.c
new file mode 100644
index 000..342f702
--- /dev/null
+++ b/drivers/clk/bcm/clk-sr.c
@@ -0,0 +1,320 @@
+/*
+ * Copyright 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation (the "GPL").
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License version 2 (GPLv2) for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * version 2 (GPLv2) along with this source code.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "clk-iproc.h"
+
+#define REG_VAL(o, s, w) { .offset = o, .shift = s, .width = w, }
+
+#define AON_VAL(o, pw, ps, is) { .offset = o, .pwr_width = pw, \
+   .pwr_shift = ps, .iso_shift = is }
+
+#define SW_CTRL_VAL(o, s) { .offset = o, .shift = s, }
+
+#define RESET_VAL(o, rs, prs) { .offset = o, .reset_shift = rs, \
+   .p_reset_shift = prs }
+
+#define DF_VAL(o, kis, kiw, kps, kpw, kas, kaw) { .offset = o, \
+   .ki_shift = kis, .ki_width = kiw, .kp_shift = kps, .kp_width = kpw, \
+   .ka_shift = kas, .ka_width = kaw }
+
+#define VCO_CTRL_VAL(uo, lo) { .u_offset = uo, .l_offset = lo }
+
+#define ENABLE_VAL(o, es, hs, bs) { .offset = o, .enable_shift = es, \
+   .hold_shift = hs, .bypass_shift = bs }
+
+
+static const struct iproc_pll_ctrl genpll0 = {
+   .flags = IPROC_CLK_AON | IPROC_CLK_PLL_HAS_NDIV_FRAC |
+   IPROC_CLK_PLL_NEEDS_SW_CFG,
+   .aon = AON_VAL(0x0, 5, 1, 0),
+   .reset = RESET_VAL(0x0, 12, 11),
+   .dig_filter = DF_VAL(0x0, 4, 3, 0, 4, 7, 3),
+   .sw_ctrl = SW_CTRL_VAL(0x10, 31),
+   .ndiv_int = REG_VAL(0x10, 20, 10),
+   .ndiv_frac = REG_VAL(0x10, 0, 20),
+   .pdiv = REG_VAL(0x14, 0, 4),
+   .status = REG_VAL(0x30, 12, 1),
+};
+
+static const struct iproc_clk_ctrl genpll0_clk[] = {
+   [BCM_SR_GENPLL0_SATA_CLK] = {
+   .channel = BCM_SR_GENPLL0_SATA_CLK,
+   .flags = IPROC_CLK_AON,
+   .enable = ENABLE_VAL(0x4, 6, 0, 12),
+   .mdiv = REG_VAL(0x18, 0, 9),
+   },
+   [BCM_SR_GENPLL0_SCR_CLK] = {
+   .channel = BCM_SR_GENPLL0_SCR_CLK,
+   .flags = IPROC_CLK_AON,
+   .enable = ENABLE_VAL(0x4, 7, 1, 13),
+   .mdiv = REG_VAL(0x18, 10, 9),
+   },
+   [BCM_SR_GENPLL0_250M_CLK] = {
+   .channel = BCM_SR_GENPLL0_250M_CLK,
+   .flags = IPROC_CLK_AON,
+   .enable = ENABLE_VAL(0x4, 8, 2, 14),
+   .mdiv = REG_VAL(0x18, 20, 9),
+   },
+   [BCM_SR_GENPLL0_PCIE_AXI_CLK] = {
+   .channel = BCM_SR_GENPLL0_PCIE_AXI_CLK,
+   .flags = IPROC_CLK_AON,
+   .enable = ENABLE_VAL(0x4, 9, 3, 15),
+   .mdiv = REG_VAL(0x1c, 0, 9),
+   },
+   [BCM_SR_GENPLL0_PAXC_AXI_X2_CLK] = {
+   .channel = BCM_SR_GENPLL0_PAXC_AXI_X2_CLK,
+   .flags = IPROC_CLK_AON,
+   .enable = ENABLE_VAL(0x4, 10, 4, 16),
+   .mdiv = REG_VAL(0x1c, 10, 9),
+   },
+   [BCM_SR_GENPLL0_PAXC_AXI_CLK] = {
+   .channel = BCM_SR_GENPLL0_PAXC_AXI_CLK,
+   .flags = IPROC_CLK_AON,
+   

[PATCH v5 02/11] dt-bindings: clk: Extend binding doc for Stingray SOC

[Anup Patel]

From: Sandeep Tripathy 

Update iproc clock dt-binding documentation with
Stingray pll and clock details.

Signed-off-by: Sandeep Tripathy 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Acked-by: Rob Herring 
---
 .../bindings/clock/brcm,iproc-clocks.txt   |  76 
 include/dt-bindings/clock/bcm-sr.h | 101 +
 2 files changed, 177 insertions(+)
 create mode 100644 include/dt-bindings/clock/bcm-sr.h

diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt 
b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
index 6f66e9a..f2c5f0e4a 100644
--- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
+++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
@@ -219,3 +219,79 @@ BCM63138
 
 PLL and leaf clock compatible strings for BCM63138 are:
 "brcm,bcm63138-armpll"
+
+Stingray
+---
+PLL and leaf clock compatible strings for Stingray are:
+"brcm,sr-genpll0"
+"brcm,sr-genpll1"
+"brcm,sr-genpll2"
+"brcm,sr-genpll3"
+"brcm,sr-genpll4"
+"brcm,sr-genpll5"
+"brcm,sr-genpll6"
+
+"brcm,sr-lcpll0"
+"brcm,sr-lcpll1"
+"brcm,sr-lcpll-pcie"
+
+
+The following table defines the set of PLL/clock index and ID for Stingray.
+These clock IDs are defined in:
+"include/dt-bindings/clock/bcm-sr.h"
+
+Clock  Source  Index   ID
+----   -   -
+crystalN/A N/A N/A
+crmu_ref25mcrystal N/A N/A
+
+genpll0crystal 0   BCM_SR_GENPLL0
+clk_125m   genpll0 1   BCM_SR_GENPLL0_125M_CLK
+clk_scrgenpll0 2   BCM_SR_GENPLL0_SCR_CLK
+clk_250genpll0 3   BCM_SR_GENPLL0_250M_CLK
+clk_pcie_axi   genpll0 4   BCM_SR_GENPLL0_PCIE_AXI_CLK
+clk_paxc_axi_x2genpll0 5   BCM_SR_GENPLL0_PAXC_AXI_X2_CLK
+clk_paxc_axi   genpll0 6   BCM_SR_GENPLL0_PAXC_AXI_CLK
+
+genpll1crystal 0   BCM_SR_GENPLL1
+clk_pcie_tlgenpll1 1   
BCM_SR_GENPLL1_PCIE_TL_CLK
+clk_mhb_apbgenpll1 2   
BCM_SR_GENPLL1_MHB_APB_CLK
+
+genpll2crystal 0   BCM_SR_GENPLL2
+clk_nicgenpll2 1   BCM_SR_GENPLL2_NIC_CLK
+clk_ts_500_ref genpll2 2   BCM_SR_GENPLL2_TS_500_REF_CLK
+clk_125_nitro  genpll2 3   BCM_SR_GENPLL2_125_NITRO_CLK
+clk_chimp  genpll2 4   BCM_SR_GENPLL2_CHIMP_CLK
+clk_nic_flash  genpll2 5   BCM_SR_GENPLL2_NIC_FLASH
+
+genpll3crystal 0   BCM_SR_GENPLL3
+clk_hsls   genpll3 1   BCM_SR_GENPLL3_HSLS_CLK
+clk_sdio   genpll3 2   BCM_SR_GENPLL3_SDIO_CLK
+
+genpll4crystal 0   BCM_SR_GENPLL4
+ccngenpll4 1   BCM_SR_GENPLL4_CCN_CLK
+clk_tpiu_pll   genpll4 2   BCM_SR_GENPLL4_TPIU_PLL_CLK
+noc_clkgenpll4 3   BCM_SR_GENPLL4_NOC_CLK
+clk_chclk_fs4  genpll4 4   BCM_SR_GENPLL4_CHCLK_FS4_CLK
+clk_bridge_fscpu   genpll4 5   BCM_SR_GENPLL4_BRIDGE_FSCPU_CLK
+
+
+genpll5crystal 0   BCM_SR_GENPLL5
+fs4_hf_clk genpll5 1   BCM_SR_GENPLL5_FS4_HF_CLK
+crypto_ae_clk  genpll5 2   BCM_SR_GENPLL5_CRYPTO_AE_CLK
+raid_ae_clkgenpll5 3   
BCM_SR_GENPLL5_RAID_AE_CLK
+
+genpll6crystal 0   BCM_SR_GENPLL6
+48_usb genpll6 1   BCM_SR_GENPLL6_48_USB_CLK
+
+lcpll0 crystal 0   BCM_SR_LCPLL0
+clk_sata_refp  lcpll0  1   BCM_SR_LCPLL0_SATA_REFP_CLK
+clk_sata_refn  lcpll0  2   BCM_SR_LCPLL0_SATA_REFN_CLK
+clk_usb_reflcpll0  3   
BCM_SR_LCPLL0_USB_REF_CLK
+sata_refpn lcpll0  3   BCM_SR_LCPLL0_SATA_REFPN_CLK
+
+lcpll1 crystal 0   BCM_SR_LCPLL1
+wanlcpll1  1   BCM_SR_LCPLL0_WAN_CLK
+
+lcpll_pcie crystal 0   BCM_SR_LCPLL_PCIE
+pcie_phy_ref   lcpll1  1   BCM_SR_LCPLL_PCIE_PHY_REF_CLK
diff --git a/include/dt-bindings/clock/bcm-sr.h 
b/include/dt-bindings/clock/bcm-sr.h
new file mode 100644
index 000..cff6c6f
--- /dev/null
+++ b/include/dt-bindings/clock/bcm-sr.h
@@ -0,0 +1,101 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2017 Broadcom. All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistri

Re: [PATCH v10] vfio: platform: reset: Add Broadcom FlexRM reset module

[Anup Patel]

On Tue, Oct 3, 2017 at 10:57 AM, Anup Patel  wrote:
> This patch adds Broadcom FlexRM low-level reset for
> VFIO platform.
>
> It will do the following:
> 1. Disable/Deactivate each FlexRM ring
> 2. Flush each FlexRM ring
>
> The cleanup sequence for FlexRM rings is adapted from
> Broadcom FlexRM mailbox driver.
>
> Signed-off-by: Anup Patel 
> Reviewed-by: Oza Oza 
> Reviewed-by: Scott Branden 
> Reviewed-by: Eric Auger 
> ---
>  drivers/vfio/platform/reset/Kconfig|   9 ++
>  drivers/vfio/platform/reset/Makefile   |   1 +
>  .../vfio/platform/reset/vfio_platform_bcmflexrm.c  | 113 
> +
>  3 files changed, 123 insertions(+)
>  create mode 100644 drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c
>
> diff --git a/drivers/vfio/platform/reset/Kconfig 
> b/drivers/vfio/platform/reset/Kconfig
> index 705..392e3c0 100644
> --- a/drivers/vfio/platform/reset/Kconfig
> +++ b/drivers/vfio/platform/reset/Kconfig
> @@ -13,3 +13,12 @@ config VFIO_PLATFORM_AMDXGBE_RESET
>   Enables the VFIO platform driver to handle reset for AMD XGBE
>
>   If you don't know what to do here, say N.
> +
> +config VFIO_PLATFORM_BCMFLEXRM_RESET
> +   tristate "VFIO support for Broadcom FlexRM reset"
> +   depends on VFIO_PLATFORM && (ARCH_BCM_IPROC || COMPILE_TEST)
> +   default ARCH_BCM_IPROC
> +   help
> + Enables the VFIO platform driver to handle reset for Broadcom FlexRM
> +
> + If you don't know what to do here, say N.
> diff --git a/drivers/vfio/platform/reset/Makefile 
> b/drivers/vfio/platform/reset/Makefile
> index 93f4e23..8d9874b 100644
> --- a/drivers/vfio/platform/reset/Makefile
> +++ b/drivers/vfio/platform/reset/Makefile
> @@ -5,3 +5,4 @@ ccflags-y += -Idrivers/vfio/platform
>
>  obj-$(CONFIG_VFIO_PLATFORM_CALXEDAXGMAC_RESET) += 
> vfio-platform-calxedaxgmac.o
>  obj-$(CONFIG_VFIO_PLATFORM_AMDXGBE_RESET) += vfio-platform-amdxgbe.o
> +obj-$(CONFIG_VFIO_PLATFORM_BCMFLEXRM_RESET) += vfio_platform_bcmflexrm.o
> diff --git a/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c 
> b/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c
> new file mode 100644
> index 000..d45c3be
> --- /dev/null
> +++ b/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c
> @@ -0,0 +1,113 @@
> +/*
> + * Copyright (C) 2017 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +/*
> + * This driver provides reset support for Broadcom FlexRM ring manager
> + * to VFIO platform.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "vfio_platform_private.h"
> +
> +/* FlexRM configuration */
> +#define RING_REGS_SIZE 0x1
> +#define RING_VER_MAGIC 0x76303031
> +
> +/* Per-Ring register offsets */
> +#define RING_VER   0x000
> +#define RING_CONTROL   0x034
> +#define RING_FLUSH_DONE0x038
> +
> +/* Register RING_CONTROL fields */
> +#define CONTROL_FLUSH_SHIFT5
> +
> +/* Register RING_FLUSH_DONE fields */
> +#define FLUSH_DONE_MASK0x1
> +
> +static int vfio_platform_bcmflexrm_shutdown(void __iomem *ring)
> +{
> +   unsigned int timeout;
> +
> +   /* Disable/inactivate ring */
> +   writel_relaxed(0x0, ring + RING_CONTROL);
> +
> +   /* Set ring flush state */
> +   timeout = 1000; /* timeout of 1s */
> +   writel_relaxed(BIT(CONTROL_FLUSH_SHIFT), ring + RING_CONTROL);
> +   do {
> +   if (readl_relaxed(ring + RING_FLUSH_DONE) &
> +   FLUSH_DONE_MASK)
> +   break;
> +   mdelay(1);
> +   } while (--timeout);
> +   if (!timeout)
> +   return -ETIMEDOUT;
> +
> +   /* Clear ring flush state */
> +   timeout = 1000; /* timeout of 1s */
> +   writel_relaxed(0x0, ring + RING_CONTROL);
> +   do {
> +   if (!(readl_relaxed(ring + RING_FLUSH_DONE) &
> +   

Re: [PATCH] ARM: multi_v7_defconfig: Select RPMSG_VIRTIO as module

[Anup Patel]

On Thu, Oct 5, 2017 at 10:19 PM, Anup Patel  wrote:
> The RPMSG_VIRTIO is now user selectable option so we explicitly
> select it in multi_v7_defconfig. Till now RPMSG_VIRTIO was
> selected by ST_REMOTEPROC=m in multi_v7_defconfig.
>
> Signed-off-by: Anup Patel 
> ---
>  arch/arm/configs/multi_v7_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index 0cacdbf..5e689e0 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -849,6 +849,7 @@ CONFIG_TEGRA_IOMMU_GART=y
>  CONFIG_TEGRA_IOMMU_SMMU=y
>  CONFIG_REMOTEPROC=m
>  CONFIG_ST_REMOTEPROC=m
> +CONFIG_RPMSG_VIRTIO=m
>  CONFIG_PM_DEVFREQ=y
>  CONFIG_ARM_TEGRA_DEVFREQ=m
>  CONFIG_MEMORY=y
> --
> 2.7.4
>

Hi Arnd/Olof,

Please have a look at this patch.

This is a follow-up patch for https://patchwork.kernel.org/patch/9987567/

Regards,
Anup

Re: [PATCH 0/5] Few more FlexRM driver improvements

[Anup Patel]

On Tue, Oct 3, 2017 at 10:51 AM, Anup Patel  wrote:
> This patchset does few more improvements to Broadcom FlexRM mailbox
> driver.
>
> The patches are based on Linux-4.14-rc3 and can also be found at
> flexrm-imp2-v1 branch of:
> https://github.com/Broadcom/arm64-linux.git
>
> Anup Patel (4):
>   mailbox: bcm-flexrm-mailbox: Fix FlexRM ring flush sequence
>   mailbox: bcm-flexrm-mailbox: Print ring number in errors and warnings
>   mailbox: bcm-flexrm-mailbox: Use common GPL comment header
>   mailbox: Build Broadcom FlexRM driver as loadable module for iProc
> SOCs
>
> Scott Branden (1):
>   mailbox: bcm-flexrm-mailbox: add depends on ARCH_BCM_IPROC
>
>  drivers/mailbox/Kconfig  |  3 +-
>  drivers/mailbox/bcm-flexrm-mailbox.c | 66 
> ++--
>  2 files changed, 51 insertions(+), 18 deletions(-)
>
> --
> 2.7.4
>

Ping ??

Regards,
Anup

Re: [PATCH] ARM: multi_v7_defconfig: Select RPMSG_VIRTIO as module

[Anup Patel]

On Thu, Oct 26, 2017 at 9:33 PM, Anup Patel  wrote:
> On Thu, Oct 5, 2017 at 10:19 PM, Anup Patel  wrote:
>> The RPMSG_VIRTIO is now user selectable option so we explicitly
>> select it in multi_v7_defconfig. Till now RPMSG_VIRTIO was
>> selected by ST_REMOTEPROC=m in multi_v7_defconfig.
>>
>> Signed-off-by: Anup Patel 
>> ---
>>  arch/arm/configs/multi_v7_defconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/configs/multi_v7_defconfig 
>> b/arch/arm/configs/multi_v7_defconfig
>> index 0cacdbf..5e689e0 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -849,6 +849,7 @@ CONFIG_TEGRA_IOMMU_GART=y
>>  CONFIG_TEGRA_IOMMU_SMMU=y
>>  CONFIG_REMOTEPROC=m
>>  CONFIG_ST_REMOTEPROC=m
>> +CONFIG_RPMSG_VIRTIO=m
>>  CONFIG_PM_DEVFREQ=y
>>  CONFIG_ARM_TEGRA_DEVFREQ=m
>>  CONFIG_MEMORY=y
>> --
>> 2.7.4
>>
>
> Hi Arnd/Olof,
>
> Please have a look at this patch.
>
> This is a follow-up patch for https://patchwork.kernel.org/patch/9987567/
>
> Regards,
> Anup

Hi All,

Ping  ???

Regards,
Anup

RE: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller

[Anup Patel]

> -Original Message-
> From: Florian Fainelli [mailto:f.faine...@gmail.com]
> Sent: 07 October 2015 04:51
> To: Scott Branden; Brian Norris; Anup Patel
> Cc: linux-arm-ker...@lists.infradead.org; Rob Herring; Pawel Moll; Mark
> Rutland; Ian Campbell; Kumar Gala; Catalin Marinas; Will Deacon; David
> Woodhouse; Ray Jui; Florian Fainelli; Pramod Kumar; Vikram Prakash; Sandeep
> Tripathy; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> m...@lists.infradead.org; bcm-kernel-feedback-list; Rafal Milecki
> Subject: Re: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND
> controller
> 
> On 06/10/15 15:25, Scott Branden wrote:
> > Hi Brian,
> >
> > On 15-10-06 06:41 AM, Brian Norris wrote:
> >
> >>>>
> >>>> Is there a reason not to do this reset unconditionally? I recall
> >>>> this came up in discussion previously, when the OpenWRT folks were
> >>>> trying to integrate with BCMA, where this reset was one of the few
> >>>> differences between the
> >>>> platform-
> >>>> device-based driver (i.e., this one) and the BCMA based driver.
> >>>> Might it help
> >>>> simplify things a bit if we just did the same thing everywhere?
> >>>
> >>> This driver is currently shared by Cygnus and NS2.
> >>>
> >>> We had similar suggestion when this patch was reviewed internally in
> >>> Broadcom.
> >>>
> >>> The rationale for adding optional DT flag is as follows:
> >>> 1. The NAND controller reset is currently required for NS2 only so
> >>> that it is in sane state before any NAND commands are issued. We are
> >>> not sure if Cygnus and all future iProc SoCs will require NAND
> >>> controller reset.
> >>
> >> I'm not sure this is a very strong reason. It seems fairly reasonable
> >> in general to reset a HW block before using it.
> >
> > Efficient Boot time is a very strong reason for needing this actually.
> > We use the NAND controller in the bootROM, boot1/BL1, u-boot/UEFI, and
> > then Kernel stage.  By properly initializing the controller once we do
> > not need to reset it 4 different times.
> 
> This could be used as a reverse argument, issuing a reset will increase the 
> boot
> time.
> 
> >
> >>
> >>> 2. The NAND controller reset in probe would certainly increase Linux
> >>> boot time so for certain iProc SoCs we might choose avoid NAND
> >>> controller reset to reduce boot time if possible.
> >>
> >> I recall this reason being mentioned before. I believe this only
> >> happens because the brcmnand driver doesn't yet handle configuring
> >> the timing registers, so iProc is implicitly relying on the
> >> bootloader to configure the NAND timings. Perhaps it's time that we
> >> fix that. I'd rather not add extra DT properties unless we actually
> >> need to [1]. And having proper timing configuration in the Linux
> >> driver will help improve speeds for all users (whose timings may not be
> configured in the bootloader).
> >
> > This is the very reason we need the optional reset property.  We need
> > to have timings configured by the linux driver or not.  Yes, in some
> > cases we will be relying on earlier boot stages to configure some of
> > the hardware.
> 
> Then instead of adding a "reset flag" to Device Tree, another approach could 
> be
> to put the desired or currently configured exhaustive list of NAND timings in
> Device Tree, and based on that you could have this:
> 
> - the NAND controller driver finds that these timings match the current
> configuration, you are good to go
> 
> - the NAND controller drivers finds a difference in how current timings are
> configured vs. desired timings, and issues a controller reset, prior to 
> applying
> new timing configuration

To add to this ...

The mechanism to reset is BRCM NAND controller is SOC specific so the
SoC independent BRCM NAND driver (i.e. brcmnand.c) does not know how
to reset the NAND controller.

For iProc SoC family, the NAND controller reset is through IDM register
space which is only iomap'ed by iproc_nand.c.

We might end-up having one more SoC specific callback which will be
Provided by iproc_nand.c to brcmnand.c.

> 
> - no timings are configured, reset the controller and use existing 
> auto-detection
> capabilities like ONFI modes
> 
> Typically you would put the desired timings instead of the currently 
> configured
> timings though..

Overall, it would go

RE: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller

[Anup Patel]

Hi Brian,

> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: 13 October 2015 02:58
> To: Anup Patel
> Cc: Florian Fainelli; Scott Branden; linux-arm-ker...@lists.infradead.org; Rob
> Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Catalin Marinas;
> Will Deacon; David Woodhouse; Ray Jui; Pramod Kumar; Vikram Prakash;
> Sandeep Tripathy; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-...@lists.infradead.org; bcm-kernel-feedback-list; Rafal Milecki
> Subject: Re: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND
> controller
> 
> Hi Anup,
> 
> On Wed, Oct 07, 2015 at 03:33:50AM +, Anup Patel wrote:
> > > -Original Message-
> > > From: Florian Fainelli [mailto:f.faine...@gmail.com]
> > >
> > > On 06/10/15 15:25, Scott Branden wrote:
> > >
> > > Then instead of adding a "reset flag" to Device Tree, another
> > > approach could be to put the desired or currently configured
> > > exhaustive list of NAND timings in Device Tree, and based on that you 
> > > could
> have this:
> > >
> > > - the NAND controller driver finds that these timings match the
> > > current configuration, you are good to go
> > >
> > > - the NAND controller drivers finds a difference in how current
> > > timings are configured vs. desired timings, and issues a controller
> > > reset, prior to applying new timing configuration
> >
> > To add to this ...
> >
> > The mechanism to reset is BRCM NAND controller is SOC specific so the
> > SoC independent BRCM NAND driver (i.e. brcmnand.c) does not know how
> > to reset the NAND controller.
> >
> > For iProc SoC family, the NAND controller reset is through IDM
> > register space which is only iomap'ed by iproc_nand.c.
> >
> > We might end-up having one more SoC specific callback which will be
> > Provided by iproc_nand.c to brcmnand.c.
> >
> > >
> > > - no timings are configured, reset the controller and use existing
> > > auto-detection capabilities like ONFI modes
> > >
> > > Typically you would put the desired timings instead of the currently
> > > configured timings though..
> >
> > Overall, it would good to support timing parameters through DT or ONFI
> > but for now have we can rely on reset and auto-devid configuration.
> 
> I don't want to support a DT property that is only used as a workaround for 
> the
> right solution. That means the property may quickly become obsolete, yet we
> have to support it forever.
> 
> 
> > > >> compatible = "brcm,iproc-nand-ns2", ...;
> > > >>
> > > > As described above - the option is not SoC specific.  It is system
> > > > specific.  In some systems we may wish to reset the NAND
> > > > controller in linux.  In some we may wish to rely on
> > > > initialization that has already been done to speed up boot times.
> > >
> > > It seems to me like having this property is fine as long as you are
> > > describing that the controller *needs* a reset to operate properly,
> > > it does not strike me as a particularly well suited property if its
> > > side effect and main usage is to keep or wipe-out existing NAND timings.
> >
> > IMHO, having SoC specific compatible string for NS2 is like saying
> > NAND controller on NS2 is different from other iProc SoCs whereas
> > Having optional DT flags for quirks/work-arounds (e.g. NAND controller
> > reset) is like saying NAND controller on NS2 same as other iProc SoCs
> > but some additional programming is required.
> 
> OK... so what is the reason that you have to reset the controller on NS2 and 
> not
> Cygnus? Is it a SoC difference (i.e., compatible string)?
> Firmware/bootloader difference? So far, all statements have been non-specific,
> AFAICT.
> 

On NS2 SVK, we have 16bit NAND chip whereas on all Cygnus SVKs we mostly
have 8bit NAND chip.

The bootloader on NS2 touches NAND controller and configures it to 16bit mode.
When we reach BRCMNAND driver probing on NS2, the BRCMNAND controller is
already in 16bit mode so NAND READID command does not work. On Cygnus,
we mostly have 8bit NAND chip so BRCMNAND controller is always in 8bit mode
so we don't see any issue with NAND READID command.

We really don't require to reset BRCNNAND controller on NS2 to get NAND
READID command working. Instead, we can simply force 8bit mode before
we do nand_scan_ident() for each CS. This will be a much simpler fix for all
versions of BRCMNAND because NAND READID command will only work
in 8bit mode irrespective to BRCMNAND version (NAND controllers from
other vendors might also have similar issue with NAND READID command).

I will send a revised patchset which will fix brcmnand_init_cs() as-per above.

Best Regards,
Anup
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/4] NAND support for Broadcom NS2 SoC

[Anup Patel]

We enable NAND support for Broadcom NS2 SoC by reusing existing
BRCMNAND driver.

This patchset applies on-top of "arm64: Simple additions to
NS2 DT" v1 patchset and is available in ns2_nand_v2 branch of
https://github.com/Broadcom/arm64-linux.git.

The patchset is tested on NS2 SVK.

Changes since v1:
 - Dropped patch3 and patch4 because we don't need to reset
   BRCMNAND controller for NS2.
 - Added patch to force 8bit mode before doing nand_scan_ident()
   in brcmnand_init_cs().

Anup Patel (4):
  mtd: brcmnand: Fix pointer type-cast in brcmnand_write()
  mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64
  mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
  arm64: dts: Add BRCM IPROC NAND DT node for NS2

 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 
 arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
 drivers/mtd/nand/Kconfig |  2 +-
 drivers/mtd/nand/brcmnand/brcmnand.c | 13 +++--
 4 files changed, 38 insertions(+), 3 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64

[Anup Patel]

The BRCM NAND driver can be re-used for Broadcom ARM64 SoCs hence
this patch updates Kconfig to allow selection of MTD_NAND_BRCMNAND
for ARM64.

Signed-off-by: Anup Patel 
Reviewed-by: Vikram Prakash 
Reviewed-by: Ray Jui 
Reviewed-by: Pramod KUMAR 
Reviewed-by: Scott Branden 
---
 drivers/mtd/nand/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 3324281..a1b5819 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -393,7 +393,7 @@ config MTD_NAND_GPMI_NAND
 
 config MTD_NAND_BRCMNAND
tristate "Broadcom STB NAND controller"
-   depends on ARM || MIPS
+   depends on ARM || ARM64 || MIPS
help
  Enables the Broadcom NAND controller driver. The controller was
  originally designed for Set-Top Box but is used on various BCM7xxx,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/4] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()

[Anup Patel]

Just like other NAND controllers, the NAND READID command only works
in 8bit mode for all versions of BRCMNAND controller.

This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
before doing nand_scan_ident() to ensure that BRCMNAND controller
is in 8bit mode when NAND READID command is issued.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 4cba03d..0be8ef9 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1888,6 +1888,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
struct mtd_info *mtd;
struct nand_chip *chip;
int ret;
+   u16 cfg_offs;
struct mtd_part_parser_data ppdata = { .of_node = dn };
 
ret = of_property_read_u32(dn, "reg", &host->cs);
@@ -1930,6 +1931,14 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
 
chip->controller = &ctrl->controller;
 
+   /*
+* The bootloader might have configured 16bit mode but
+* NAND READID command only works in 8bit mode. We force
+* 8bit mode here to ensure that NAND READID commands works.
+*/
+   cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
+   nand_writereg(ctrl, cfg_offs, nand_readreg(ctrl, cfg_offs) & ~BIT(23));
+
if (nand_scan_ident(mtd, 1, NULL))
return -ENXIO;
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/4] arm64: dts: Add BRCM IPROC NAND DT node for NS2

[Anup Patel]

The NAND controller on NS2 SoC is compatible with existing
BRCM IPROC NAND driver so let's enable it in NS2 DT and
NS2 SVK DT.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 
 arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
 2 files changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts 
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index e5950d5..a754160 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -63,5 +63,17 @@
uart3: serial@6613 {
status = "ok";
};
+
+   nand: nand@6646 {
+   nandcs@0 {
+   compatible = "brcm,nandcs";
+   reg = <0>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <8>;
+   nand-ecc-step-size = <512>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+   };
};
 };
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..9610822 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,19 @@
compatible = "brcm,iproc-rng200";
reg = <0x6622 0x28>;
};
+
+   nand: nand@6646 {
+   compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+   reg = <0x6646 0x600>,
+ <0x67015408 0x600>,
+ <0x66460f00 0x20>;
+   reg-names = "nand", "iproc-idm", "iproc-ext";
+   interrupts = ;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   brcm,nand-has-wp;
+   };
};
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in brcmnand_write()

[Anup Patel]

We should always type-cast pointer to "long" or "unsigned long"
because size of pointer is same as machine word size. This will
avoid pointer type-cast issues on both 32bit and 64bit systems.

This patch fixes pointer type-cast issue in brcmnand_write()
as-per above info.

Signed-off-by: Anup Patel 
Reviewed-by: Vikram Prakash 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index fddb795..4cba03d 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1544,9 +1544,9 @@ static int brcmnand_write(struct mtd_info *mtd, struct 
nand_chip *chip,
 
dev_dbg(ctrl->dev, "write %llx <- %p\n", (unsigned long long)addr, buf);
 
-   if (unlikely((u32)buf & 0x03)) {
+   if (unlikely((unsigned long)buf & 0x03)) {
dev_warn(ctrl->dev, "unaligned buffer: %p\n", buf);
-   buf = (u32 *)((u32)buf & ~0x03);
+   buf = (u32 *)((unsigned long)buf & ~0x03);
}
 
brcmnand_wp(mtd, 0);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in brcmnand_write()

[Anup Patel]

> -Original Message-
> From: Ray Jui [mailto:r...@broadcom.com]
> Sent: 16 October 2015 21:06
> To: Anup Patel; David Woodhouse; Brian Norris; linux-...@lists.infradead.org
> Cc: Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Catalin
> Marinas; Will Deacon; Scott Branden; Florian Fainelli; Pramod Kumar; Vikram
> Prakash; Sandeep Tripathy; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; bcm-kernel-
> feedback-list
> Subject: Re: [PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in
> brcmnand_write()
> 
> Correct me if I remember it wrong, but I thought this patch has already been
> merged by Brian?

Yes, patch1 and patch2 were merged by Brian. I realized this after I had
send-out v2. Anyways we can ignore patch1 and patch2 from this patchset
because they are same as v1.

Regards,
Anup
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2 4/4] arm64: dts: Add BRCM IPROC NAND DT node for NS2

[Anup Patel]

> -Original Message-
> From: Sudeep Holla [mailto:sudeep.ho...@arm.com]
> Sent: 20 October 2015 14:36
> To: Anup Patel
> Cc: David Woodhouse; Brian Norris; linux-...@lists.infradead.org; Sudeep
> Holla; Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; 
> Catalin
> Marinas; Will Deacon; Ray Jui; Scott Branden; Florian Fainelli; Pramod Kumar;
> Vikram Prakash; Sandeep Tripathy; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; bcm-kernel-
> feedback-list
> Subject: Re: [PATCH v2 4/4] arm64: dts: Add BRCM IPROC NAND DT node for
> NS2
> 
> 
> 
> On 16/10/15 10:08, Anup Patel wrote:
> > The NAND controller on NS2 SoC is compatible with existing BRCM IPROC
> > NAND driver so let's enable it in NS2 DT and
> > NS2 SVK DT.
> >
> > Signed-off-by: Anup Patel 
> > Reviewed-by: Ray Jui 
> > Reviewed-by: Scott Branden 
> > ---
> >   arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 
> >   arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
> >   2 files changed, 26 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> > b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> > index e5950d5..a754160 100644
> > --- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> > +++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> > @@ -63,5 +63,17 @@
> > uart3: serial@6613 {
> > status = "ok";
> > };
> 
> Better to change even the above reference, see below.
> 
> > +
> > +   nand: nand@6646 {
> 
> In most of the cases where such static overlays are done, I have seen the 
> labels
> being used to refer back the node. Using the complete node name again is kind
> of inviting trouble as even minor typo results in creation of another node.

Thanks for pointing. I will use label here for both uart3 and nand.

Regards,
Anup
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 0/2] NAND support for Broadcom NS2 SoC

[Anup Patel]

We enable NAND support for Broadcom NS2 SoC by reusing existing
BRCMNAND driver.

This patchset applies on-top of "arm64: Simple additions to
NS2 DT" v1 patchset and is available in ns2_nand_v3 branch of
https://github.com/Broadcom/arm64-linux.git.

The patchset is tested on NS2 SVK.

Changes since v2:
 - Dropped patch1 and patch2 because these are already merged
   by MTD maintainer.
 - Avoid using absolute node paths in ns2-svk.dts.

Changes since v1:
 - Dropped patch3 and patch4 because we don't need to reset
   BRCMNAND controller for NS2.
 - Added patch to force 8bit mode before doing nand_scan_ident()
   in brcmnand_init_cs().

Anup Patel (2):
  mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
  arm64: dts: Add BRCM IPROC NAND DT node for NS2

 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 --
 arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
 drivers/mtd/nand/brcmnand/brcmnand.c |  9 +
 3 files changed, 43 insertions(+), 10 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/2] arm64: dts: Add BRCM IPROC NAND DT node for NS2

[Anup Patel]

The NAND controller on NS2 SoC is compatible with existing
BRCM IPROC NAND driver so let's enable it in NS2 DT and
NS2 SVK DT.

This patch also fixes use of node labels in ns2-svk.dts.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 --
 arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
 2 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts 
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index e5950d5..6bb3d4d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -50,18 +50,28 @@
device_type = "memory";
reg = <0x0 0x8000 0x 0x4000>;
};
+};
 
-   soc: soc {
-   i2c0: i2c@6608 {
-   status = "ok";
-   };
+&i2c0 {
+   status = "ok";
+};
 
-   i2c1: i2c@660b {
-   status = "ok";
-   };
+&i2c1 {
+   status = "ok";
+};
+
+&uart3 {
+   status = "ok";
+};
 
-   uart3: serial@6613 {
-   status = "ok";
-   };
+&nand {
+   nandcs@0 {
+   compatible = "brcm,nandcs";
+   reg = <0>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <8>;
+   nand-ecc-step-size = <512>;
+   #address-cells = <1>;
+   #size-cells = <1>;
};
 };
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..9610822 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,19 @@
compatible = "brcm,iproc-rng200";
reg = <0x6622 0x28>;
};
+
+   nand: nand@6646 {
+   compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+   reg = <0x6646 0x600>,
+ <0x67015408 0x600>,
+ <0x66460f00 0x20>;
+   reg-names = "nand", "iproc-idm", "iproc-ext";
+   interrupts = ;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   brcm,nand-has-wp;
+   };
};
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/2] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()

[Anup Patel]

Just like other NAND controllers, the NAND READID command only works
in 8bit mode for all versions of BRCMNAND controller.

This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
before doing nand_scan_ident() to ensure that BRCMNAND controller
is in 8bit mode when NAND READID command is issued.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 4cba03d..0be8ef9 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1888,6 +1888,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
struct mtd_info *mtd;
struct nand_chip *chip;
int ret;
+   u16 cfg_offs;
struct mtd_part_parser_data ppdata = { .of_node = dn };
 
ret = of_property_read_u32(dn, "reg", &host->cs);
@@ -1930,6 +1931,14 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
 
chip->controller = &ctrl->controller;
 
+   /*
+* The bootloader might have configured 16bit mode but
+* NAND READID command only works in 8bit mode. We force
+* 8bit mode here to ensure that NAND READID commands works.
+*/
+   cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
+   nand_writereg(ctrl, cfg_offs, nand_readreg(ctrl, cfg_offs) & ~BIT(23));
+
if (nand_scan_ident(mtd, 1, NULL))
return -ENXIO;
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 0/6] arm64: Simple additions to NS2 DT

[Anup Patel]

Ping ???

Regards,
Anup
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/6] arm64: dts: Add L2-cache DT node for NS2

[Anup Patel]

Recent kernels requires cache hierrachy to be defined via DT hence
this patch updates NS2 DT accordingly.

Signed-off-by: Anup Patel 
Reviewed-by: Sandeep Tripathy 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/ns2.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 3c92d92..f759175 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -50,6 +50,7 @@
reg = <0 0>;
enable-method = "spin-table";
cpu-release-addr = <0 0x84b0>;
+   next-level-cache = <&CLUSTER0_L2>;
};
 
cpu@1 {
@@ -58,6 +59,7 @@
reg = <0 1>;
enable-method = "spin-table";
cpu-release-addr = <0 0x84b0>;
+   next-level-cache = <&CLUSTER0_L2>;
};
 
cpu@2 {
@@ -66,6 +68,7 @@
reg = <0 2>;
enable-method = "spin-table";
cpu-release-addr = <0 0x84b0>;
+   next-level-cache = <&CLUSTER0_L2>;
};
 
cpu@3 {
@@ -74,6 +77,11 @@
reg = <0 3>;
enable-method = "spin-table";
cpu-release-addr = <0 0x84b0>;
+   next-level-cache = <&CLUSTER0_L2>;
+   };
+
+   CLUSTER0_L2: l2-cache@000 {
+   compatible = "cache";
};
};
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/6] arm64: dts: Add IPROC RNG200 DT node for NS2

[Anup Patel]

We have IPROC RNG200 hardware random number generation in
NS2 SoC, lets enable it for NS2 in NS2 DT.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Pramod KUMAR 
Reviewed-by: Vikram Prakash 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/ns2.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index bc31c0e..92ecf1c 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -187,5 +187,10 @@
clock-frequency = <23961600>;
status = "disabled";
};
+
+   hwrng: hwrng@6622 {
+   compatible = "brcm,iproc-rng200";
+   reg = <0x6622 0x28>;
+   };
};
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/6] arm64: dts: Add I2C nodes for NS2

[Anup Patel]

From: Ray Jui 

This patch adds iProc I2C DT nodes for NS2 and enable them for the NS2
SVK board

Signed-off-by: Ray Jui 
Reviewed-by: Vikram Prakash 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/ns2-svk.dts |  8 
 arch/arm64/boot/dts/broadcom/ns2.dtsi| 20 
 2 files changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts 
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index 244baf8..e5950d5 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -52,6 +52,14 @@
};
 
soc: soc {
+   i2c0: i2c@6608 {
+   status = "ok";
+   };
+
+   i2c1: i2c@660b {
+   status = "ok";
+   };
+
uart3: serial@6613 {
status = "ok";
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 92ecf1c..f603277 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -178,6 +178,26 @@
  <0x6526 0x1000>;
};
 
+   i2c0: i2c@6608 {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x6608 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@660b {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x660b 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
+
uart3: serial@6613 {
compatible = "snps,dw-apb-uart";
reg = <0x6613 0x100>;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/6] arm64: dts: Add syscon based reboot in DT for NS2

[Anup Patel]

To reset NS2, we simply have to write '0' to BIT[1] at offset 0x90
of CRMU space.

The above can be easily achieved by writing 0xfffd at offset 0x90
using syscon-reboot driver. We don't need to have separate driver for
rebooting NS2.

This patch enables syscon-reboot driver for NS2 using DT.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/ns2.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index c5d90e4..5d2ac6b 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -144,6 +144,18 @@
mmu-masters;
};
 
+   crmu: crmu@65024000 {
+   compatible = "syscon";
+   reg = <0x65024000 0x100>;
+   };
+
+   reboot@65024000 {
+   compatible ="syscon-reboot";
+   regmap = <&crmu>;
+   offset = <0x90>;
+   mask = <0xfffd>;
+   };
+
gic: interrupt-controller@6521 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/6] arm64: dts: Add SMMU DT node for NS2

[Anup Patel]

The SMMU-500 driver is already available in Linux kernel. Let's
enable it for NS2 in DT.

This patch keeps mmu-masters attribute empty so that driver patches
can later extend this attribute when adding device DT nodes.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/ns2.dtsi | 41 +++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f759175..c5d90e4 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -103,6 +103,47 @@
#size-cells = <1>;
ranges = <0 0 0 0x>;
 
+   smmu: mmu@6400 {
+   compatible = "arm,mmu-500";
+   reg = <0x6400 0x4>;
+   #global-interrupts = <2>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   mmu-masters;
+   };
+
gic: interrupt-controller@6521 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/6] arm64: dts: Add ARM PMUv3 DT node in NS2 DT

[Anup Patel]

The NS2 SoC has Cortex-A57 CPUs which support ARM PMUv3 so,
lets enable ARM PMUv3 in NS2 DT.

Signed-off-by: Anup Patel 
Reviewed-by: Vikram Prakash 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/ns2.dtsi | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 5d2ac6b..bc31c0e 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -44,7 +44,7 @@
#address-cells = <2>;
#size-cells = <0>;
 
-   cpu@0 {
+   A57_0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0 0>;
@@ -53,7 +53,7 @@
next-level-cache = <&CLUSTER0_L2>;
};
 
-   cpu@1 {
+   A57_1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0 1>;
@@ -62,7 +62,7 @@
next-level-cache = <&CLUSTER0_L2>;
};
 
-   cpu@2 {
+   A57_2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0 2>;
@@ -71,7 +71,7 @@
next-level-cache = <&CLUSTER0_L2>;
};
 
-   cpu@3 {
+   A57_3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0 3>;
@@ -97,6 +97,18 @@
  IRQ_TYPE_EDGE_RISING)>;
};
 
+   pmu {
+   compatible = "arm,armv8-pmuv3";
+   interrupts = ,
+,
+,
+;
+   interrupt-affinity = <&A57_0>,
+<&A57_1>,
+<&A57_2>,
+<&A57_3>;
+   };
+
soc: soc {
compatible = "simple-bus";
#address-cells = <1>;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/6] arm64: Simple additions to NS2 DT

[Anup Patel]

We add l2-cache, SMMU, reboot, PMUv3, RNG, and I2C DT nodes
for NS2 SVK.

This patchset is based on v4.3-rc3 and available in ns2_dt1_v1
branch of https://github.com/Broadcom/arm64-linux.git.

The patchset is tested on NS2 SVK.

Anup Patel (5):
  arm64: dts: Add L2-cache DT node for NS2
  arm64: dts: Add SMMU DT node for NS2
  arm64: dts: Add syscon based reboot in DT for NS2
  arm64: dts: Add ARM PMUv3 DT node in NS2 DT
  arm64: dts: Add IPROC RNG200 DT node for NS2

Ray Jui (1):
  arm64: dts: Add I2C nodes for NS2

 arch/arm64/boot/dts/broadcom/ns2-svk.dts |   8 +++
 arch/arm64/boot/dts/broadcom/ns2.dtsi| 106 +--
 2 files changed, 110 insertions(+), 4 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/5] NAND support for Broadcom NS2 SoC

[Anup Patel]

We enable NAND support for Broadcom NS2 SoC by reusing existing
BRCMNAND driver.

This patchset applies on-top of "arm64: Simple additions to
NS2 DT" patchset and is available in ns2_nand_v1 branch of 
https://github.com/Broadcom/arm64-linux.git.

The patchset is tested on NS2 SVK.

Anup Patel (5):
  mtd: brcmnand: Fix pointer type-cast in brcmnand_write()
  mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64
  mtd: brcmnand: Optional DT flag to reset IPROC NAND controller
  Documentation: dt-bindings: Add info about brcm,nand-iproc-reset DT
flag
  arm64: dts: Add BRCM IPROC NAND DT node for NS2

 .../devicetree/bindings/mtd/brcm,brcmnand.txt |  4 
 arch/arm64/boot/dts/broadcom/ns2-svk.dts  | 12 
 arch/arm64/boot/dts/broadcom/ns2.dtsi | 15 +++
 drivers/mtd/nand/Kconfig  |  2 +-
 drivers/mtd/nand/brcmnand/brcmnand.c  |  4 ++--
 drivers/mtd/nand/brcmnand/iproc_nand.c| 19 +++
 6 files changed, 53 insertions(+), 3 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] Documentation: dt-bindings: Add info about brcm,nand-iproc-reset DT flag

[Anup Patel]

This patch updates the BRCM NAND controller DT bindings documentation
to add info about newly added optional flag "brcm,nand-iproc-reset".

Signed-off-by: Anup Patel 
Reviewed-by: Pramod KUMAR 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt 
b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
index 4ff7128..19b7a3c 100644
--- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
+++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
@@ -78,6 +78,10 @@ we define additional 'compatible' properties and associated 
register resources w
for interrupt status/ack.
  - reg-names: (required) a list of the names corresponding to the previous
register ranges. Should contain "iproc-idm" and "iproc-ext".
+ - brcm,nand-iproc-reset: (optional) Some of the Broadcom IPROC SoCs
+   require NAND controller to be resetted for cleanup of previously
+   configured NAND controller state. This optional flag resets the
+   NAND controller once before any NAND commands are issued.
 
 
 * NAND chip-select
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] arm64: dts: Add BRCM IPROC NAND DT node for NS2

[Anup Patel]

The NAND controller on NS2 SoC is compatible with existing
BRCM IPROC NAND driver so let's enable it in NS2 DT and
NS2 SVK DT.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 
 arch/arm64/boot/dts/broadcom/ns2.dtsi| 15 +++
 2 files changed, 27 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts 
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index e5950d5..a754160 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -63,5 +63,17 @@
uart3: serial@6613 {
status = "ok";
};
+
+   nand: nand@6646 {
+   nandcs@0 {
+   compatible = "brcm,nandcs";
+   reg = <0>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <8>;
+   nand-ecc-step-size = <512>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+   };
};
 };
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..55c3c5a 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,20 @@
compatible = "brcm,iproc-rng200";
reg = <0x6622 0x28>;
};
+
+   nand: nand@6646 {
+   compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+   reg = <0x6646 0x600>,
+ <0x67015408 0x600>,
+ <0x66460f00 0x20>;
+   reg-names = "nand", "iproc-idm", "iproc-ext";
+   interrupts = ;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   brcm,nand-iproc-reset;
+   brcm,nand-has-wp;
+   };
};
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller

[Anup Patel]

The BRCM NAND controller on NS2 SoC requires a reset to
cleanup previously configured NAND controller state.

This patch adds optional boolean device tree flag named
"brcm,nand-iproc-reset". If this flag is present in NAND
controller DT node then BRCM IPROC NAND driver will reset
the NAND controller before any commands are issued.

Signed-off-by: Anup Patel 
Reviewed-by: Pramod KUMAR 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/mtd/nand/brcmnand/iproc_nand.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/mtd/nand/brcmnand/iproc_nand.c 
b/drivers/mtd/nand/brcmnand/iproc_nand.c
index 683495c..d837207 100644
--- a/drivers/mtd/nand/brcmnand/iproc_nand.c
+++ b/drivers/mtd/nand/brcmnand/iproc_nand.c
@@ -11,6 +11,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -35,6 +36,10 @@ struct iproc_nand_soc_priv {
 #define IPROC_NAND_APB_LE_MODE BIT(24)
 #define IPROC_NAND_INT_CTRL_READ_ENABLEBIT(6)
 
+#define IPROC_NAND_RESET_OFFSET0x3f8
+#define IPROC_NAND_RESET_BIT_SHIFT 0
+#define IPROC_NAND_RESET_BIT   BIT(IPROC_NAND_RESET_BIT_SHIFT)
+
 static bool iproc_nand_intc_ack(struct brcmnand_soc *soc)
 {
struct iproc_nand_soc_priv *priv = soc->priv;
@@ -93,6 +98,7 @@ static void iproc_nand_apb_access(struct brcmnand_soc *soc, 
bool prepare)
 
 static int iproc_nand_probe(struct platform_device *pdev)
 {
+   u32 reset;
struct device *dev = &pdev->dev;
struct iproc_nand_soc_priv *priv;
struct brcmnand_soc *soc;
@@ -124,6 +130,19 @@ static int iproc_nand_probe(struct platform_device *pdev)
soc->ctlrdy_set_enabled = iproc_nand_intc_set;
soc->prepare_data_bus = iproc_nand_apb_access;
 
+   if (of_property_read_bool(dev->of_node, "brcm,nand-iproc-reset")) {
+   /* Put controller in reset and wait 10 usecs */
+   reset = readl(priv->idm_base + IPROC_NAND_RESET_OFFSET);
+   reset |= IPROC_NAND_RESET_BIT;
+   writel(reset, priv->idm_base + IPROC_NAND_RESET_OFFSET);
+   udelay(10);
+   /* Bring controller out of reset and wait 10 usecs */
+   reset = readl(priv->idm_base + IPROC_NAND_RESET_OFFSET);
+   reset &= ~IPROC_NAND_RESET_BIT;
+   writel(reset, priv->idm_base + IPROC_NAND_RESET_OFFSET);
+   udelay(10);
+   }
+
return brcmnand_probe(pdev, soc);
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64

[Anup Patel]

The BRCM NAND driver can be re-used for Broadcom ARM64 SoCs hence
this patch updates Kconfig to allow selection of MTD_NAND_BRCMNAND
for ARM64.

Signed-off-by: Anup Patel 
Reviewed-by: Vikram Prakash 
Reviewed-by: Ray Jui 
Reviewed-by: Pramod KUMAR 
Reviewed-by: Scott Branden 
---
 drivers/mtd/nand/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 3324281..a1b5819 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -393,7 +393,7 @@ config MTD_NAND_GPMI_NAND
 
 config MTD_NAND_BRCMNAND
tristate "Broadcom STB NAND controller"
-   depends on ARM || MIPS
+   depends on ARM || ARM64 || MIPS
help
  Enables the Broadcom NAND controller driver. The controller was
  originally designed for Set-Top Box but is used on various BCM7xxx,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] mtd: brcmnand: Fix pointer type-cast in brcmnand_write()

[Anup Patel]

We should always type-cast pointer to "long" or "unsigned long"
because size of pointer is same as machine word size. This will
avoid pointer type-cast issues on both 32bit and 64bit systems.

This patch fixes pointer type-cast issue in brcmnand_write()
as-per above info.

Signed-off-by: Anup Patel 
Reviewed-by: Vikram Prakash 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index fddb795..4cba03d 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1544,9 +1544,9 @@ static int brcmnand_write(struct mtd_info *mtd, struct 
nand_chip *chip,
 
dev_dbg(ctrl->dev, "write %llx <- %p\n", (unsigned long long)addr, buf);
 
-   if (unlikely((u32)buf & 0x03)) {
+   if (unlikely((unsigned long)buf & 0x03)) {
dev_warn(ctrl->dev, "unaligned buffer: %p\n", buf);
-   buf = (u32 *)((u32)buf & ~0x03);
+   buf = (u32 *)((unsigned long)buf & ~0x03);
}
 
brcmnand_wp(mtd, 0);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller

[Anup Patel]

> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: 05 October 2015 03:20
> To: Anup Patel
> Cc: linux-arm-ker...@lists.infradead.org; Rob Herring; Pawel Moll; Mark
> Rutland; Ian Campbell; Kumar Gala; Catalin Marinas; Will Deacon; David
> Woodhouse; Ray Jui; Scott Branden; Florian Fainelli; Pramod Kumar; Vikram
> Prakash; Sandeep Tripathy; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-...@lists.infradead.org; bcm-kernel-feedback-
> list; Rafal Milecki
> Subject: Re: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND
> controller
> 
> + Rafal (to extend this mighty CC list)
> 
> On Fri, Oct 02, 2015 at 11:26:44PM +0530, Anup Patel wrote:
> > The BRCM NAND controller on NS2 SoC requires a reset to cleanup
> > previously configured NAND controller state.
> >
> > This patch adds optional boolean device tree flag named
> > "brcm,nand-iproc-reset". If this flag is present in NAND controller DT
> > node then BRCM IPROC NAND driver will reset the NAND controller before
> > any commands are issued.
> 
> Is there a reason not to do this reset unconditionally? I recall this came up 
> in
> discussion previously, when the OpenWRT folks were trying to integrate with
> BCMA, where this reset was one of the few differences between the platform-
> device-based driver (i.e., this one) and the BCMA based driver. Might it help
> simplify things a bit if we just did the same thing everywhere?

This driver is currently shared by Cygnus and NS2.

We had similar suggestion when this patch was reviewed
internally in Broadcom.

The rationale for adding optional DT flag is as follows:
1. The NAND controller reset is currently required for NS2 only so
that it is in sane state before any NAND commands are issued. We
are not sure if Cygnus and all future iProc SoCs will require NAND
controller reset.
2. The NAND controller reset in probe would certainly increase
Linux boot time so for certain iProc SoCs we might choose avoid
NAND controller reset to reduce boot time if possible.

Regards
Anup

> 
> Brian
> 
> > Signed-off-by: Anup Patel 
> > Reviewed-by: Pramod KUMAR 
> > Reviewed-by: Ray Jui 
> > Reviewed-by: Scott Branden 
> > ---
> >  drivers/mtd/nand/brcmnand/iproc_nand.c | 19 +++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/mtd/nand/brcmnand/iproc_nand.c
> > b/drivers/mtd/nand/brcmnand/iproc_nand.c
> > index 683495c..d837207 100644
> > --- a/drivers/mtd/nand/brcmnand/iproc_nand.c
> > +++ b/drivers/mtd/nand/brcmnand/iproc_nand.c
> > @@ -11,6 +11,7 @@
> >   * GNU General Public License for more details.
> >   */
> >
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -35,6 +36,10 @@ struct iproc_nand_soc_priv {
> >  #define IPROC_NAND_APB_LE_MODE BIT(24)
> >  #define IPROC_NAND_INT_CTRL_READ_ENABLEBIT(6)
> >
> > +#define IPROC_NAND_RESET_OFFSET0x3f8
> > +#define IPROC_NAND_RESET_BIT_SHIFT 0
> > +#define IPROC_NAND_RESET_BIT
> BIT(IPROC_NAND_RESET_BIT_SHIFT)
> > +
> >  static bool iproc_nand_intc_ack(struct brcmnand_soc *soc)  {
> > struct iproc_nand_soc_priv *priv = soc->priv; @@ -93,6 +98,7 @@
> > static void iproc_nand_apb_access(struct brcmnand_soc *soc, bool
> > prepare)
> >
> >  static int iproc_nand_probe(struct platform_device *pdev)  {
> > +   u32 reset;
> > struct device *dev = &pdev->dev;
> > struct iproc_nand_soc_priv *priv;
> > struct brcmnand_soc *soc;
> > @@ -124,6 +130,19 @@ static int iproc_nand_probe(struct platform_device
> *pdev)
> > soc->ctlrdy_set_enabled = iproc_nand_intc_set;
> > soc->prepare_data_bus = iproc_nand_apb_access;
> >
> > +   if (of_property_read_bool(dev->of_node, "brcm,nand-iproc-reset")) {
> > +   /* Put controller in reset and wait 10 usecs */
> > +   reset = readl(priv->idm_base + IPROC_NAND_RESET_OFFSET);
> > +   reset |= IPROC_NAND_RESET_BIT;
> > +   writel(reset, priv->idm_base + IPROC_NAND_RESET_OFFSET);
> > +   udelay(10);
> > +   /* Bring controller out of reset and wait 10 usecs */
> > +   reset = readl(priv->idm_base + IPROC_NAND_RESET_OFFSET);
> > +   reset &= ~IPROC_NAND_RESET_BIT;
> > +   writel(reset, priv->idm_base + IPROC_NAND_RESET_OFFSET);
> > +   udelay(10);
> > +   }
> > +
> > return brcmnand_probe(pdev, soc);
> >  }
> >
> > --
> > 1.9.1
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 00/13] remoteproc: add fixed memory region support

[Anup Patel]

Hi Loic Pallardy, Bjorn Andersson,

This patchset also helps in getting VirtIO RPMSG driver working
with VirtIO MMIO transport.

Is it possible to have this patchset part of Linux-4.19 or Linux-4.20?

Regards,
Anup

Re: [PATCH v2 0/3] RISC-V: Add new smp features

[Anup Patel]

On Tue, Aug 28, 2018 at 4:36 AM, Atish Patra  wrote:
> This patch series implements following smp related features.
> Some of the work has been inspired from ARM64.
>
> 1. Decouple linux logical cpu ids from hardware cpu id
> 2. Support cpu hotplug.
>
> Tested on QEMU & HighFive Unleashed board with/without SMP enabled.
>
> v1->v2:
>
> 1. Dropped cpu_ops patch.
> 2. Moved back IRQ cause definiations to irq.h
> 3. Keep boot cpu hart id and assign zero as the cpu id for boot cpu.
> 4. Renamed cpu id and hart id correctly.
>
> Atish Patra (3):
>   RISC-V: Add logical CPU indexing for RISC-V
>   RISC-V: Use Linux logical cpu number instead of hartid
>   RISC-V: Support cpu hotplug.
>

This series looks good to me.

FWIW,
Reviewed-by: Anup Patel 

Regards,
Anup

Re: [PATCH v2 0/3] RISC-V: Add new smp features

[Anup Patel]

On Thu, Aug 30, 2018 at 10:11 AM, Christoph Hellwig  wrote:
> On Thu, Aug 30, 2018 at 09:53:50AM -0400, Anup Patel wrote:
>> > Atish Patra (3):
>> >   RISC-V: Add logical CPU indexing for RISC-V
>> >   RISC-V: Use Linux logical cpu number instead of hartid
>> >   RISC-V: Support cpu hotplug.
>> >
>>
>> This series looks good to me.
>
> Hmm, that series didn't make it to my inbox, neither directly, nor
> through the linux-riscv list.  Where did you see it?

Strange, I have subscribed to:
linux-kernel@vger.kernel.org
linux-ri...@lists.infradead.org

--
Anup

Re: [PATCH v2 0/3] RISC-V: Add new smp features

[Anup Patel]

On Thu, Aug 30, 2018 at 10:11 AM, Christoph Hellwig  wrote:
> On Thu, Aug 30, 2018 at 09:53:50AM -0400, Anup Patel wrote:
>> > Atish Patra (3):
>> >   RISC-V: Add logical CPU indexing for RISC-V
>> >   RISC-V: Use Linux logical cpu number instead of hartid
>> >   RISC-V: Support cpu hotplug.
>> >
>>
>> This series looks good to me.
>
> Hmm, that series didn't make it to my inbox, neither directly, nor
> through the linux-riscv list.  Where did you see it?

Ahh, looks like some issue indeed. I am in TO list of patch series, thats why
I got the patch series.

--
Anup

Re: [RFC PATCH 3/5] RISC-V: Add cpu_operatios structure

[Anup Patel]

On Tue, Aug 21, 2018 at 1:18 PM, Christoph Hellwig  wrote:
> On Thu, Aug 16, 2018 at 11:51:03AM +0530, Anup Patel wrote:
>> Having thought about this more, I think cpu_ops should be an pointer array
>> of NR_CPUS size. This means its not necessary to have have same ops for
>> all CPUs. The ARM64 implementation of CPU operations also allows separate
>> CPU operations for each CPU.
>>
>> For example, let's us assume that we have an SOC where we 2 cores
>> per-cluster and N clusters. All CPUs of cluster0 comes up at the same time
>> whereas cluster1 onwards we have to bring-up CPUs using special HW
>> mechanism.
>
> All this (including the patch itself) seems a little hypothetical.
> I'd rather only add all this infrastructure once it actually is needed.

The cpu_operations is certainly required because SOC vendors will add
vendor-specific mechanism to selectively bringing-up CPUs/HARTs instead
of all CPUs entering Linux kernel simultaneously. In fact, we might also end-up
having CPU ON/OFF operations in SBI.

Having separate cpu_operations for each CPU is good for flexibility because
CPU clusters might have different way of bringing up CPUs (for example, take
any Hetrogeneous Multiprocessor Systems (HMP)).

IMHO, RISCV Linux port is new and this the right time to implement critical
infrastructure things (such as cpu_operations). Also, its not something radical
because we are taking inspiration from existing Linux ports (such as ARM64).

Regards,
Anup

Re: [RFC PATCH 3/5] RISC-V: Add cpu_operatios structure

[Anup Patel]

On Wed, Aug 22, 2018 at 11:33 AM, Christoph Hellwig  wrote:
> On Tue, Aug 21, 2018 at 10:34:38PM +0530, Anup Patel wrote:
>> The cpu_operations is certainly required because SOC vendors will add
>> vendor-specific mechanism to selectively bringing-up CPUs/HARTs instead
>> of all CPUs entering Linux kernel simultaneously. In fact, we might also 
>> end-up
>> having CPU ON/OFF operations in SBI.
>
> Your forgot an essential part in your analysis:  Right now we only have
> one single way to deal with cpu on/offlining, and that is the dummy WFI
> kind.  Once other ways show up we can build proper infrastructure, but
> until then this is just a white elephant as we have no idea how these
> abstractions will look like.
>
> And my hope is that we'll just see new SBI calls, in which case we'll
> just need SBI and dummy version and can avoid all the indirect calls.

IMHO, rather than waiting for new CPU ON/OFF methods to come-up we
can keep the cpu_operations ready. Also, we are not re-inventing anything
here which we might have to discard later because cpu_operations are
already tried and hardened for Linux ARM64.

I agree with you that in long-term SBI-based CPU ON/OFF will be widely
used. Most likely we will have at-least two CPU ON/OFF methods:
1. Existing lottery based spinning
2. New SBI calls

Regards,
Anup

Re: [RFC PATCH 3/5] RISC-V: Add cpu_operatios structure

[Anup Patel]

On Thu, Aug 23, 2018 at 9:37 AM, Christoph Hellwig  wrote:
> On Wed, Aug 22, 2018 at 08:54:51PM +0530, Anup Patel wrote:
>> IMHO, rather than waiting for new CPU ON/OFF methods to come-up we
>> can keep the cpu_operations ready. Also, we are not re-inventing anything
>> here which we might have to discard later because cpu_operations are
>> already tried and hardened for Linux ARM64.
>
> Which is a different cpu architecture, and has shown to actually need
> it.  IFF we end up needing it on riscv we can still copy and paste
> it from AMD64.
>
>
>> I agree with you that in long-term SBI-based CPU ON/OFF will be widely
>> used. Most likely we will have at-least two CPU ON/OFF methods:
>> 1. Existing lottery based spinning
>> 2. New SBI calls
>
> And in this most likely case there is no need for an ops vector,
> a simple if/else will be much simpler and cleaner.

Like Atish mentioned, there is a possibility of existing HW going for
spin-table method instead of lottery based spinning.

This means in future we will have three or more CPU ON/OFF methods:
1. Existing lottery based spinning
2. spin-table
3. New SBI calls

I am fine dropping cpu_operations now but I am sure we will end-up
adding it back eventually.

Regards,
Anup

Re: [PATCH 3/6] irqchip: RISC-V Local Interrupt Controller Driver

[Anup Patel]

On Wed, Jul 25, 2018 at 4:54 PM, Christoph Hellwig  wrote:
> On Wed, Jul 25, 2018 at 12:18:39PM +0100, Marc Zyngier wrote:
>> This feels odd. It means that you cannot have the following sequence:
>>
>>   local_irq_disable();
>>   enable_irq(x); // where x is owned by a remote hart
>>
>> as smp_call_function_single() requires interrupts to be enabled.
>>
>> More fundamentally, why are you trying to make these interrupts look
>> global while they aren't? arm/arm64 have similar restrictions with GICv2
>> and earlier, and treats these interrupts as per-cpu.
>>
>> Given that the drivers that deal with drivers connected to the per-hart
>> irqchip are themselves likely to be aware of the per-cpu aspect, it
>> would make sense to align things (we've been through that same
>> discussion about the clocksource driver a few weeks back).
>
> Right now the only direct consumers are said clocksource, the PLIC
> driver later in this series and the RISC-V arch IPI code.  None of them
> is going to do a manual enable_irq, so I guess the remote case of the
> code is simply dead code.  I'll take a look at converting them to
> per-cpu.  I guess the GICv2 driver is the best template?

Actually, RISCV HLIC and PLIC are very similar to RPi2 and RPi3 SOCs.

On RPi2 and RPi3, we have per-CPU BCM2836 local intc and the global
interrupts are managed using BCM2835 intc. You should certainly have
a look a this drivers because these very simple compared to GICv2 and
GICv3 drivers.

Regards,
Anup

Re: [PATCH 3/6] irqchip: RISC-V Local Interrupt Controller Driver

[Anup Patel]

On Thu, Jul 26, 2018 at 1:57 PM, Christoph Hellwig  wrote:
> On Thu, Jul 26, 2018 at 09:08:00AM +0530, Anup Patel wrote:
>> Actually, RISCV HLIC and PLIC are very similar to RPi2 and RPi3 SOCs.
>>
>> On RPi2 and RPi3, we have per-CPU BCM2836 local intc and the global
>> interrupts are managed using BCM2835 intc. You should certainly have
>> a look a this drivers because these very simple compared to GICv2 and
>> GICv3 drivers.
>
> Yes, using that model makes writing the per-cpu irq controller driver
> trivial.  But retrofitting it into the device tree, where the existing
> bootloader (bbl) assumes the old DT layout is a giant pain in the neck.

This can also be taken care in HLIC driver probe function with something
like below:

if (parent)
return 0;

if (of_is_compatible(parent, "riscv,cpu")) {
/*
* Legacy DT binding so we have HLIC DT node
* under each CPU DT node. To provide backwared
* compatiblity we go forward for only one HLIC
* DT node
*/
if (atomic_inc_return(&hlic_lottery) > 1)
return 0;
}

In PLIC driver probe, register nested IRQ handler for only first two
entries of interrupts-extended because it is HLIC IRQs are per-CPU. We
can happily ignore other entries in interrupts-extended of Legacy DTS.

>
> At the same time I'm still not conveninced RISC-V really needs a full
> irqchip driver for the per-cpu interrupt 'controller' really is nothing
> but 1 and a half architectural control registers:
>
>   - the scause register that contains the reason for an exception
> (any exception including syscalls and page faults) for the entry
> into supervisor mode.  This includes a bit to indicate interrupts,
> and then logical interrupt reason, out of which only three are
> interesting for supervisor mode (timer, software, external)
>   - the sie register that allows to to enable/disable each of the above
> causes individually

Biggest plus is the ability show stats for per-CPU interrupts via
"cat /proc/interrupts" (just like other architectures).

Currently, we have only three per-CPU interrupts (timer, software,
and external) but in-future people might come-up with interesting
devices which might have per-CPU interrupts.

>
> So after burning out on DT hacking (never mind retrofitting that into
> actual shipping SOCs vs just qemu) I'm going to try a version that
> doesn't add an irqchip for this but just handles it hardcoded in
> RISC-V do_IRQ.  I'll still keep the irqchip for the PLIC, which while
> specificed in the RISC-V spec isn't architectural but an actual
> periphal.

I believe it possible to have RICV HLIC driver which maintains
backward compatibility with legacy DTS. I haven't tried above
approach myself on QEMU so I will let you decide.

Regards,
Anup

Re: [PATCH 7/9] irqchip: add a RISC-V PLIC driver

[Anup Patel]

On Sat 28 Jul, 2018, 5:34 AM Atish Patra,  wrote:
>
> On 7/26/18 7:38 AM, Christoph Hellwig wrote:
> > This patch adds a driver for the Platform Level Interrupt Controller (PLIC)
> > specified as part of the RISC-V supervisor level ISA manual, in the memory
> > layout implemented by SiFive and qemu.
> >
> > The PLIC connects global interrupt sources to the local interrupt controller
> > on each hart.
> >
> > This driver is based on the driver in the RISC-V tree from Palmer Dabbelt,
> > but has been almost entirely rewritten since.
> >
> > Signed-off-by: Christoph Hellwig 
>
> I tried to boot HighFive Unleashed with the patch series after applying
> all the patches from riscv-all branch except timer & irq patches. It
> gets stuck pretty early.
>
> Here is my github repo with all the changes:
> https://github.com/atishp04/riscv-linux/commits/master_chris_cleanup_hifive
>
> I am still looking into it.
> Palmer: Did I miss something?
>
> FWIW, here is the boot log.
> - Boot log ---
> [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=5
> [0.00] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
> [0.00] plic: mapped 53 interrupts to 4 (out of 9) handlers.
> [0.00] clocksource: riscv_clocksource: mask: 0x
> max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns
> [0.00] Calibrating delay loop (skipped), value calculated using
> timer frequency.. 2.00 BogoMIPS (lpj=1)
> [0.01] pid_max: default: 32768 minimum: 301
> [0.01] Mount-cache hash table entries: 16384 (order: 5, 131072
> bytes)
> [0.02] Mountpoint-cache hash table entries: 16384 (order: 5,
> 131072 bytes)
> [0.02] Hierarchical SRCU implementation.
> [0.03] smp: Bringing up secondary CPUs ...

I have noticed following:

1. plic_irq_toggle() works on all present CPUs which means an
IRQ will be enabled/disabled for all present CPUs. This further
imply that whenever an IRQ is triggered, all online CPUs will take
the interrupt but only one CPU will be successful in claiming the
IRQ and other CPUs will check for IRQ in vain.

2. irq_set_affinity() is not available which means IRQ balancing
will not work.

3. A PLIC context is for a particular HART+MODE. A HW designer
can choose to connect PLIC context only for particular MODE of
HART/CPU whereas this driver assumes that we have context
available for both M-mode and S-mode of all HARTs/CPUs.

Regards,
Anup

Re: [PATCH RESEND] rpmsg: virtio_rpmsg_bus: fix rpmsg_probe() for virtio-mmio transport

[Anup Patel]

On Wed, Jan 10, 2018 at 6:46 PM, Anup Patel  wrote:
> When virtio-rpmsg device is provided via virtio-mmio transport, the
> dma_alloc_coherent() (called by rpmsg_probe()) fails on ARM/ARM64
> systems because "vdev->dev.parent->parent" device is used as parameter
> to dma_alloc_coherent().
>
> The "vdev->dev.parent->parent" device represents underlying remoteproc
> platform device when virtio-rpmsg device is provided via virtio-remoteproc
> transport. When virtio-rpmsg device is provided via virtio-mmio transport,
> the "vdev->dev.parent->parent" device represents the parent device of
> virtio-mmio platform device and dma_alloc_coherent() fails for this device
> because generally there is no corresponding platform device and dma_ops
> are not setup for "vdev->dev.parent->parent".
>
> This patch fixes dma_alloc_coherent() usage in rpmsg_probe() by trying
> dma_alloc_coherent() with "vdev->dev.parent" device when it fails with
> "vdev->dev.parent->parent" device.
>
> Fixes: b5ab5e24e960 ("remoteproc: maintain a generic child device for
> each rproc")
>
> Signed-off-by: Anup Patel 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/rpmsg/virtio_rpmsg_bus.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c 
> b/drivers/rpmsg/virtio_rpmsg_bus.c
> index 82b8300..7f8710a 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -64,6 +64,7 @@
>  struct virtproc_info {
> struct virtio_device *vdev;
> struct virtqueue *rvq, *svq;
> +   struct device *bufs_dev;
> void *rbufs, *sbufs;
> unsigned int num_bufs;
> unsigned int buf_size;
> @@ -924,9 +925,16 @@ static int rpmsg_probe(struct virtio_device *vdev)
>  total_buf_space, &vrp->bufs_dma,
>  GFP_KERNEL);
> if (!bufs_va) {
> -   err = -ENOMEM;
> -   goto vqs_del;
> -   }
> +   bufs_va = dma_alloc_coherent(vdev->dev.parent,
> +total_buf_space, &vrp->bufs_dma,
> +GFP_KERNEL);
> +   if (!bufs_va) {
> +   err = -ENOMEM;
> +   goto vqs_del;
> +   } else
> +   vrp->bufs_dev = vdev->dev.parent;
> +   } else
> +   vrp->bufs_dev = vdev->dev.parent->parent;
>
> dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
> bufs_va, &vrp->bufs_dma);
> @@ -988,7 +996,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
> return 0;
>
>  free_coherent:
> -   dma_free_coherent(vdev->dev.parent->parent, total_buf_space,
> +   dma_free_coherent(vrp->bufs_dev, total_buf_space,
>   bufs_va, vrp->bufs_dma);
>  vqs_del:
> vdev->config->del_vqs(vrp->vdev);
> @@ -1023,7 +1031,7 @@ static void rpmsg_remove(struct virtio_device *vdev)
>
> vdev->config->del_vqs(vrp->vdev);
>
> -   dma_free_coherent(vdev->dev.parent->parent, total_buf_space,
> +   dma_free_coherent(vrp->bufs_dev, total_buf_space,
>   vrp->rbufs, vrp->bufs_dma);
>
> kfree(vrp);
> --
> 2.7.4
>

Hi All,

Any comments on this??

Regards,
Anup

Re: [PATCH RESEND] rpmsg: Add driver_override device attribute for rpmsg_device

[Anup Patel]

On Wed, Jan 10, 2018 at 6:47 PM, Anup Patel  wrote:
> This patch adds "driver_override" device attribute for rpmsg_device which
> will allow users to explicitly specify the rpmsg_driver to be used via
> sysfs entry.
>
> The "driver_override" device attribute implemented here is very similar
> to "driver_override" implemented for platform, pci, and amba bus types.
>
> One important use-case of "driver_override" device attribute is to force
> use of rpmsg_chrdev driver for certain rpmsg_device instances.
>
> Signed-off-by: Anup Patel 
> ---
>  Documentation/ABI/testing/sysfs-bus-rpmsg | 20 ++
>  drivers/rpmsg/rpmsg_core.c| 46 
> +--
>  2 files changed, 64 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-rpmsg 
> b/Documentation/ABI/testing/sysfs-bus-rpmsg
> index 189e419..1c8599e 100644
> --- a/Documentation/ABI/testing/sysfs-bus-rpmsg
> +++ b/Documentation/ABI/testing/sysfs-bus-rpmsg
> @@ -73,3 +73,23 @@ Description:
> This sysfs entry tells us whether the channel is a local
> server channel that is announced (values are either
> true or false).
> +
> +What:  /sys/bus/rpmsg/devices/.../driver_override
> +Date:  January 2018
> +KernelVersion: 4.16
> +Contact:   Ohad Ben-Cohen 
> +Description:
> +   Every rpmsg device is a communication channel with a remote
> +   processor. Channels are identified by a textual name (see
> +   /sys/bus/rpmsg/devices/.../name above) and have a local
> +   ("source") rpmsg address, and remote ("destination") rpmsg
> +   address.
> +
> +   The listening entity (or client) which communicates with a
> +   remote processor is referred as rpmsg driver. The rpmsg device
> +   and rpmsg driver are matched based on rpmsg device name and
> +   rpmsg driver ID table.
> +
> +   This sysfs entry allows the rpmsg driver for a rpmsg device
> +   to be specified which will override standard OF, ID table
> +   and name matching.
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index dffa3aa..9a25e42 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -321,11 +321,11 @@ struct device *rpmsg_find_device(struct device *parent,
>  }
>  EXPORT_SYMBOL(rpmsg_find_device);
>
> -/* sysfs show configuration fields */
> +/* sysfs configuration fields */
>  #define rpmsg_show_attr(field, path, format_string)\
>  static ssize_t \
>  field##_show(struct device *dev,   \
> -   struct device_attribute *attr, char *buf)   \
> +struct device_attribute *attr, char *buf)  \
>  {  \
> struct rpmsg_device *rpdev = to_rpmsg_device(dev);  \
> \
> @@ -333,11 +333,52 @@ field##_show(struct device *dev,
>   \
>  }  \
>  static DEVICE_ATTR_RO(field);
>
> +#define rpmsg_string_attr(field, path) \
> +static ssize_t \
> +field##_store(struct device *dev,  \
> + struct device_attribute *attr, const char *buf, size_t sz)\
> +{  \
> +   struct rpmsg_device *rpdev = to_rpmsg_device(dev);  \
> +   char *new, *old, *cp;   \
> +   \
> +   new = kstrndup(buf, sz, GFP_KERNEL);\
> +   if (!new)   \
> +   return -ENOMEM; \
> +   \
> +   cp = strchr(new, '\n'); \
> +   if (cp) \
> +   *cp = '\0'; \
> +   \
> +   device_lock(dev);  

[PATCH v8 0/4] Broadcom SBA RAID support

[Anup Patel]

The Broadcom SBA RAID is a stream-based device which provides
RAID5/6 offload.

It requires a SoC specific ring manager (such as Broadcom FlexRM
ring manager) to provide ring-based programming interface. Due to
this, the Broadcom SBA RAID driver (mailbox client) implements
DMA device having one DMA channel using a set of mailbox channels
provided by Broadcom SoC specific ring manager driver (mailbox
controller).

The Broadcom SBA RAID hardware requires PQ disk position instead
of PQ disk coefficient. To address this, we have added raid_gflog
table which will help driver to convert PQ disk coefficient to PQ
disk position.

This patchset is based on Linux-4.12-rc1 and is available at
sba-raid-v8 branch of
https://github.com/Broadcom/arm64-linux.git

Changes since v7:
 - Rebased patches for Linux-4.12-rc1 because Broadcom FlexRM
   ring manager support is available in Linux-4.12

Changes since v6:
 - Rebased patches for Linux-4.11-rc4 and v7 of Broadcom FlexRM
   ring manager support

Changes since v5:
 - Rebased patches for Linux-4.11-rc1

Changes since v4:
 - Removed dependency of bcm-sba-raid driver on kconfig opton
   ASYNC_TX_ENABLE_CHANNEL_SWITCH
 - Select kconfig options ASYNC_TX_DISABLE_XOR_VAL_DMA and
   ASYNC_TX_DISABLE_PQ_VAL_DMA for bcm-sba-raid driver
 - Implemented device_prep_dma_interrupt() using dummy 8-byte
   copy operation so that the dma_async_device_register() can
   set DMA_ASYNC_TX capability for the DMA device provided
   by bcm-sba-raid driver

Changes since v3:
 - Replaced SBA_ENC() with sba_cmd_enc() inline function
 - Use list_first_entry_or_null() wherever possible
 - Remove unwanted brances around loops wherever possible
 - Use lockdep_assert_held() where required

Changes since v2:
 - Droped patch to handle DMA devices having support for fewer
   PQ coefficients in Linux Async Tx
 - Added work-around in bcm-sba-raid driver to handle unsupported
   PQ coefficients using multiple SBA requests

Changes since v1:
 - Droped patch to add mbox_channel_device() API
 - Used GENMASK and BIT macros wherever possible in bcm-sba-raid driver
 - Replaced C_MDATA macros with static inline functions in
   bcm-sba-raid driver
 - Removed sba_alloc_chan_resources() callback in bcm-sba-raid driver
 - Used dev_err() instead of dev_info() wherever applicable
 - Removed call to sba_issue_pending() from sba_tx_submit() in
   bcm-sba-raid driver
 - Implemented SBA request chaning for handling (len > sba->req_size)
   in bcm-sba-raid driver
 - Implemented device_terminate_all() callback in bcm-sba-raid driver

Anup Patel (4):
  lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position
  async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
  dmaengine: Add Broadcom SBA RAID driver
  dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

 .../devicetree/bindings/dma/brcm,iproc-sba.txt |   29 +
 crypto/async_tx/async_pq.c |5 +-
 drivers/dma/Kconfig|   14 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1785 
 include/linux/raid/pq.h|1 +
 lib/raid6/mktables.c   |   20 +
 7 files changed, 1852 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
 create mode 100644 drivers/dma/bcm-sba-raid.c

-- 
2.7.4

[PATCH v8 1/4] lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position

[Anup Patel]

The raid6_gfexp table represents {2}^n values for 0 <= n < 256. The
Linux async_tx framework pass values from raid6_gfexp as coefficients
for each source to prep_dma_pq() callback of DMA channel with PQ
capability. This creates problem for RAID6 offload engines (such as
Broadcom SBA) which take disk position (i.e. log of {2}) instead of
multiplicative cofficients from raid6_gfexp table.

This patch adds raid6_gflog table having log-of-2 value for any given
x such that 0 <= x < 256. For any given disk coefficient x, the
corresponding disk position is given by raid6_gflog[x]. The RAID6
offload engine driver can use this newly added raid6_gflog table to
get disk position from multiplicative coefficient.

Signed-off-by: Anup Patel 
Reviewed-by: Scott Branden 
Reviewed-by: Ray Jui 
Acked-by: Shaohua Li 
---
 include/linux/raid/pq.h |  1 +
 lib/raid6/mktables.c| 20 
 2 files changed, 21 insertions(+)

diff --git a/include/linux/raid/pq.h b/include/linux/raid/pq.h
index 4d57bba..30f9453 100644
--- a/include/linux/raid/pq.h
+++ b/include/linux/raid/pq.h
@@ -142,6 +142,7 @@ int raid6_select_algo(void);
 extern const u8 raid6_gfmul[256][256] __attribute__((aligned(256)));
 extern const u8 raid6_vgfmul[256][32] __attribute__((aligned(256)));
 extern const u8 raid6_gfexp[256]  __attribute__((aligned(256)));
+extern const u8 raid6_gflog[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfinv[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfexi[256]  __attribute__((aligned(256)));
 
diff --git a/lib/raid6/mktables.c b/lib/raid6/mktables.c
index 39787db..e824d08 100644
--- a/lib/raid6/mktables.c
+++ b/lib/raid6/mktables.c
@@ -125,6 +125,26 @@ int main(int argc, char *argv[])
printf("EXPORT_SYMBOL(raid6_gfexp);\n");
printf("#endif\n");
 
+   /* Compute log-of-2 table */
+   printf("\nconst u8 __attribute__((aligned(256)))\n"
+  "raid6_gflog[256] =\n" "{\n");
+   for (i = 0; i < 256; i += 8) {
+   printf("\t");
+   for (j = 0; j < 8; j++) {
+   v = 255;
+   for (k = 0; k < 256; k++)
+   if (exptbl[k] == (i + j)) {
+   v = k;
+   break;
+   }
+   printf("0x%02x,%c", v, (j == 7) ? '\n' : ' ');
+   }
+   }
+   printf("};\n");
+   printf("#ifdef __KERNEL__\n");
+   printf("EXPORT_SYMBOL(raid6_gflog);\n");
+   printf("#endif\n");
+
/* Compute inverse table x^-1 == x^254 */
printf("\nconst u8 __attribute__((aligned(256)))\n"
   "raid6_gfinv[256] =\n" "{\n");
-- 
2.7.4

[PATCH v8 3/4] dmaengine: Add Broadcom SBA RAID driver

[Anup Patel]

The Broadcom stream buffer accelerator (SBA) provides offloading
capabilities for RAID operations. This SBA offload engine is
accessible via Broadcom SoC specific ring manager.

This patch adds Broadcom SBA RAID driver which provides one
DMA device with RAID capabilities using one or more Broadcom
SoC specific ring manager channels. The SBA RAID driver in its
current shape implements memcpy, xor, and pq operations.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Acked-by: Dan Williams 
---
 drivers/dma/Kconfig|   14 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1785 
 3 files changed, 1800 insertions(+)
 create mode 100644 drivers/dma/bcm-sba-raid.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 24e8597..b7e0ab9 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -99,6 +99,20 @@ config AXI_DMAC
  controller is often used in Analog Device's reference designs for FPGA
  platforms.
 
+config BCM_SBA_RAID
+   tristate "Broadcom SBA RAID engine support"
+   depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
+   select DMA_ENGINE
+   select DMA_ENGINE_RAID
+   select ASYNC_TX_DISABLE_XOR_VAL_DMA
+   select ASYNC_TX_DISABLE_PQ_VAL_DMA
+   default ARCH_BCM_IPROC
+   help
+ Enable support for Broadcom SBA RAID Engine. The SBA RAID
+ engine is available on most of the Broadcom iProc SoCs. It
+ has the capability to offload memcpy, xor and pq computation
+ for raid5/6.
+
 config COH901318
bool "ST-Ericsson COH901318 DMA support"
select DMA_ENGINE
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 0b723e9..d12ab29 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
 obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
 obj-$(CONFIG_AT_XDMAC) += at_xdmac.o
 obj-$(CONFIG_AXI_DMAC) += dma-axi-dmac.o
+obj-$(CONFIG_BCM_SBA_RAID) += bcm-sba-raid.o
 obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
 obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o
 obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
new file mode 100644
index 000..d6b927b
--- /dev/null
+++ b/drivers/dma/bcm-sba-raid.c
@@ -0,0 +1,1785 @@
+/*
+ * Copyright (C) 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Broadcom SBA RAID Driver
+ *
+ * The Broadcom stream buffer accelerator (SBA) provides offloading
+ * capabilities for RAID operations. The SBA offload engine is accessible
+ * via Broadcom SoC specific ring manager. Two or more offload engines
+ * can share same Broadcom SoC specific ring manager due to this Broadcom
+ * SoC specific ring manager driver is implemented as a mailbox controller
+ * driver and offload engine drivers are implemented as mallbox clients.
+ *
+ * Typically, Broadcom SoC specific ring manager will implement larger
+ * number of hardware rings over one or more SBA hardware devices. By
+ * design, the internal buffer size of SBA hardware device is limited
+ * but all offload operations supported by SBA can be broken down into
+ * multiple small size requests and executed parallely on multiple SBA
+ * hardware devices for achieving high through-put.
+ *
+ * The Broadcom SBA RAID driver does not require any register programming
+ * except submitting request to SBA hardware device via mailbox channels.
+ * This driver implements a DMA device with one DMA channel using a set
+ * of mailbox channels provided by Broadcom SoC specific ring manager
+ * driver. To exploit parallelism (as described above), all DMA request
+ * coming to SBA RAID DMA channel are broken down to smaller requests
+ * and submitted to multiple mailbox channels in round-robin fashion.
+ * For having more SBA DMA channels, we can create more SBA device nodes
+ * in Broadcom SoC specific DTS based on number of hardware rings supported
+ * by Broadcom SoC ring manager.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dmaengine.h"
+
+/* SBA command related defines */
+#define SBA_TYPE_SHIFT 48
+#define SBA_TYPE_MASK  GENMASK(1, 0)
+#define SBA_TYPE_A 0x0
+#define SBA_TYPE_B 0x2
+#define SBA_TYPE_C 0x3
+#define SBA_USER_DEF_SHIFT 32
+#define SBA_USER_DEF_MASK  GENMASK(15, 0)
+#define SBA_R_MDATA_SHIFT  24
+#define SBA_R_MDATA_MASK   GENMASK(7, 0)
+#define SBA_C_M

[PATCH v8 4/4] dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

[Anup Patel]

This patch adds the DT bindings document for newly added Broadcom
SBA RAID driver.

Acked-by: Rob Herring 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Signed-off-by: Anup Patel 
---
 .../devicetree/bindings/dma/brcm,iproc-sba.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt

diff --git a/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt 
b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
new file mode 100644
index 000..092913a
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
@@ -0,0 +1,29 @@
+* Broadcom SBA RAID engine
+
+Required properties:
+- compatible: Should be one of the following
+ "brcm,iproc-sba"
+ "brcm,iproc-sba-v2"
+  The "brcm,iproc-sba" has support for only 6 PQ coefficients
+  The "brcm,iproc-sba-v2" has support for only 30 PQ coefficients
+- mboxes: List of phandle and mailbox channel specifiers
+
+Example:
+
+raid_mbox: mbox@6740 {
+   ...
+   #mbox-cells = <3>;
+   ...
+};
+
+raid0 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <&raid_mbox 0 0x1 0x>,
+<&raid_mbox 1 0x1 0x>,
+<&raid_mbox 2 0x1 0x>,
+<&raid_mbox 3 0x1 0x>,
+<&raid_mbox 4 0x1 0x>,
+<&raid_mbox 5 0x1 0x>,
+<&raid_mbox 6 0x1 0x>,
+<&raid_mbox 7 0x1 0x>;
+};
-- 
2.7.4

[PATCH v8 2/4] async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()

[Anup Patel]

The DMA_PREP_FENCE is to be used when preparing Tx descriptor if output
of Tx descriptor is to be used by next/dependent Tx descriptor.

The DMA_PREP_FENSE will not be set correctly in do_async_gen_syndrome()
when calling dma->device_prep_dma_pq() under following conditions:
1. ASYNC_TX_FENCE not set in submit->flags
2. DMA_PREP_FENCE not set in dma_flags
3. src_cnt (= (disks - 2)) is greater than dma_maxpq(dma, dma_flags)

This patch fixes DMA_PREP_FENCE usage in do_async_gen_syndrome() taking
inspiration from do_async_xor() implementation.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Acked-by: Dan Williams 
---
 crypto/async_tx/async_pq.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index f83de99..56bd612 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -62,9 +62,6 @@ do_async_gen_syndrome(struct dma_chan *chan,
dma_addr_t dma_dest[2];
int src_off = 0;
 
-   if (submit->flags & ASYNC_TX_FENCE)
-   dma_flags |= DMA_PREP_FENCE;
-
while (src_cnt > 0) {
submit->flags = flags_orig;
pq_src_cnt = min(src_cnt, dma_maxpq(dma, dma_flags));
@@ -83,6 +80,8 @@ do_async_gen_syndrome(struct dma_chan *chan,
if (cb_fn_orig)
dma_flags |= DMA_PREP_INTERRUPT;
}
+   if (submit->flags & ASYNC_TX_FENCE)
+   dma_flags |= DMA_PREP_FENCE;
 
/* Drivers force forward progress in case they can not provide
 * a descriptor
-- 
2.7.4

Re: [PATCH 02/11] dt-bindings: clk: Extend binding doc for Stingray SOC

[Anup Patel]

On Fri, May 12, 2017 at 8:51 PM, Rob Herring  wrote:
> On Sat, May 06, 2017 at 05:24:37PM +0530, Anup Patel wrote:
>> From: Sandeep Tripathy 
>>
>> Update iproc clock dt-binding documentation with
>> Stingray pll and clock details.
>>
>> Signed-off-by: Sandeep Tripathy 
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Scott Branden 
>> ---
>>  .../bindings/clock/brcm,iproc-clocks.txt   | 76 
>> ++
>>  1 file changed, 76 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt 
>> b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
>> index 6f66e9a..f2c5f0e4a 100644
>> --- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
>> +++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
>> @@ -219,3 +219,79 @@ BCM63138
>>  
>>  PLL and leaf clock compatible strings for BCM63138 are:
>>  "brcm,bcm63138-armpll"
>> +
>> +Stingray
>> +---
>> +PLL and leaf clock compatible strings for Stingray are:
>> +"brcm,sr-genpll0"
>> +"brcm,sr-genpll1"
>> +"brcm,sr-genpll2"
>> +"brcm,sr-genpll3"
>> +"brcm,sr-genpll4"
>> +"brcm,sr-genpll5"
>> +"brcm,sr-genpll6"
>> +
>> +"brcm,sr-lcpll0"
>> +"brcm,sr-lcpll1"
>> +"brcm,sr-lcpll-pcie"
>> +
>> +
>> +The following table defines the set of PLL/clock index and ID for Stingray.
>> +These clock IDs are defined in:
>> +"include/dt-bindings/clock/bcm-sr.h"
>
> This header should be part of this commit. With that,

Sure, I will include bcm-sr.h as-part of this commit.

>
> Acked-by: Rob Herring 

Thanks,
Anup

Re: [PATCH 04/11] arm64: dts: Initial DTS files for Broadcom Stingray SOC

[Anup Patel]

On Mon, May 8, 2017 at 5:00 AM, Florian Fainelli  wrote:
> Le 05/06/17 à 04:54, Anup Patel a écrit :
>> The Broadcom Stingray SoC is a new member in Broadcom iProc
>> SoC family.
>>
>> This patch adds initial DTS files for Broadcom Stingray SoC
>> and two of its reference boards (bcm958742k and bcm958742t).
>>
>> We have lot of reference boards and large number of devices
>> in Broadcom Stingray SoC so eventually we will have quite
>> a few DTS files for Stingray. To tackle, we have added a
>> separate directory for Stingray DTS files.
>>
>> Signed-off-by: Anup Patel 
>> Signed-off-by: Scott Branden 
>> Reviewed-by: Ray Jui 
>> ---
>
>> +
>> + scr {
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0 0 0 0x>;
>
> Sorry for missing that during the internal review, the ranges property
> here should include the 6300_ offset such that everything else under
> the "scr" node is relative to that base address. This makes it a lot
> easier to understand the different physical addresses involved and the
> bus topology.

Sure, I will do this.

Regards,
Anup

Re: [PATCH 04/11] arm64: dts: Initial DTS files for Broadcom Stingray SOC

[Anup Patel]

On Tue, May 9, 2017 at 2:02 AM, Scott Branden
 wrote:
> One update below needed dealing with memreserve
>
>
> On 17-05-06 04:54 AM, Anup Patel wrote:
>>
>> The Broadcom Stingray SoC is a new member in Broadcom iProc
>> SoC family.
>>
>> This patch adds initial DTS files for Broadcom Stingray SoC
>> and two of its reference boards (bcm958742k and bcm958742t).
>>
>> We have lot of reference boards and large number of devices
>> in Broadcom Stingray SoC so eventually we will have quite
>> a few DTS files for Stingray. To tackle, we have added a
>> separate directory for Stingray DTS files.
>>
>> Signed-off-by: Anup Patel 
>> Signed-off-by: Scott Branden 
>> Reviewed-by: Ray Jui 
>> ---
>>  arch/arm64/boot/dts/broadcom/Makefile  |   1 +
>>  arch/arm64/boot/dts/broadcom/stingray/Makefile |   6 +
>>  .../boot/dts/broadcom/stingray/bcm958742-base.dtsi |  64 +
>>  .../boot/dts/broadcom/stingray/bcm958742k.dts  |  48 
>>  .../boot/dts/broadcom/stingray/bcm958742t.dts  |  40 +++
>>  .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 307
>> +
>>  6 files changed, 466 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/Makefile
>>  create mode 100644
>> arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/broadcom/Makefile
>> b/arch/arm64/boot/dts/broadcom/Makefile
>> index f1caece..a7c3208 100644
>> --- a/arch/arm64/boot/dts/broadcom/Makefile
>> +++ b/arch/arm64/boot/dts/broadcom/Makefile
>> @@ -2,6 +2,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-3-b.dtb
>>  dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb ns2-xmc.dtb
>>  dtb-$(CONFIG_ARCH_VULCAN) += vulcan-eval.dtb
>>
>> +dts-dirs   := stingray
>>  always := $(dtb-y)
>>  subdir-y   := $(dts-dirs)
>>  clean-files:= *.dtb
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/Makefile
>> b/arch/arm64/boot/dts/broadcom/stingray/Makefile
>> new file mode 100644
>> index 000..f70028e
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/Makefile
>> @@ -0,0 +1,6 @@
>> +dtb-$(CONFIG_ARCH_BCM_IPROC) += bcm958742k.dtb
>> +dtb-$(CONFIG_ARCH_BCM_IPROC) += bcm958742t.dtb
>> +
>> +always := $(dtb-y)
>> +subdir-y   := $(dts-dirs)
>> +clean-files:= *.dtb
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> new file mode 100644
>> index 000..e3a2a36
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> @@ -0,0 +1,64 @@
>> +/*
>> + *  BSD LICENSE
>> + *
>> + *  Copyright(c) 2016-2017 Broadcom.  All rights reserved.
>> + *
>> + *  Redistribution and use in source and binary forms, with or without
>> + *  modification, are permitted provided that the following conditions
>> + *  are met:
>> + *
>> + ** Redistributions of source code must retain the above copyright
>> + *  notice, this list of conditions and the following disclaimer.
>> + ** Redistributions in binary form must reproduce the above copyright
>> + *  notice, this list of conditions and the following disclaimer in
>> + *  the documentation and/or other materials provided with the
>> + *  distribution.
>> + ** Neither the name of Broadcom nor the names of its
>> + *  contributors may be used to endorse or promote products derived
>> + *  from this software without specific prior written permission.
>> + *
>> + *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> + *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> + *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>> + *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>> + *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>> + *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> + *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>> + *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>> + *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> + *  (INCLUDING NEGLI

[PATCH v2 02/11] dt-bindings: clk: Extend binding doc for Stingray SOC

[Anup Patel]

From: Sandeep Tripathy 

Update iproc clock dt-binding documentation with
Stingray pll and clock details.

Signed-off-by: Sandeep Tripathy 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Acked-by: Rob Herring 
---
 .../bindings/clock/brcm,iproc-clocks.txt   |  76 
 include/dt-bindings/clock/bcm-sr.h | 101 +
 2 files changed, 177 insertions(+)
 create mode 100644 include/dt-bindings/clock/bcm-sr.h

diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt 
b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
index 6f66e9a..f2c5f0e4a 100644
--- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
+++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
@@ -219,3 +219,79 @@ BCM63138
 
 PLL and leaf clock compatible strings for BCM63138 are:
 "brcm,bcm63138-armpll"
+
+Stingray
+---
+PLL and leaf clock compatible strings for Stingray are:
+"brcm,sr-genpll0"
+"brcm,sr-genpll1"
+"brcm,sr-genpll2"
+"brcm,sr-genpll3"
+"brcm,sr-genpll4"
+"brcm,sr-genpll5"
+"brcm,sr-genpll6"
+
+"brcm,sr-lcpll0"
+"brcm,sr-lcpll1"
+"brcm,sr-lcpll-pcie"
+
+
+The following table defines the set of PLL/clock index and ID for Stingray.
+These clock IDs are defined in:
+"include/dt-bindings/clock/bcm-sr.h"
+
+Clock  Source  Index   ID
+----   -   -
+crystalN/A N/A N/A
+crmu_ref25mcrystal N/A N/A
+
+genpll0crystal 0   BCM_SR_GENPLL0
+clk_125m   genpll0 1   BCM_SR_GENPLL0_125M_CLK
+clk_scrgenpll0 2   BCM_SR_GENPLL0_SCR_CLK
+clk_250genpll0 3   BCM_SR_GENPLL0_250M_CLK
+clk_pcie_axi   genpll0 4   BCM_SR_GENPLL0_PCIE_AXI_CLK
+clk_paxc_axi_x2genpll0 5   BCM_SR_GENPLL0_PAXC_AXI_X2_CLK
+clk_paxc_axi   genpll0 6   BCM_SR_GENPLL0_PAXC_AXI_CLK
+
+genpll1crystal 0   BCM_SR_GENPLL1
+clk_pcie_tlgenpll1 1   
BCM_SR_GENPLL1_PCIE_TL_CLK
+clk_mhb_apbgenpll1 2   
BCM_SR_GENPLL1_MHB_APB_CLK
+
+genpll2crystal 0   BCM_SR_GENPLL2
+clk_nicgenpll2 1   BCM_SR_GENPLL2_NIC_CLK
+clk_ts_500_ref genpll2 2   BCM_SR_GENPLL2_TS_500_REF_CLK
+clk_125_nitro  genpll2 3   BCM_SR_GENPLL2_125_NITRO_CLK
+clk_chimp  genpll2 4   BCM_SR_GENPLL2_CHIMP_CLK
+clk_nic_flash  genpll2 5   BCM_SR_GENPLL2_NIC_FLASH
+
+genpll3crystal 0   BCM_SR_GENPLL3
+clk_hsls   genpll3 1   BCM_SR_GENPLL3_HSLS_CLK
+clk_sdio   genpll3 2   BCM_SR_GENPLL3_SDIO_CLK
+
+genpll4crystal 0   BCM_SR_GENPLL4
+ccngenpll4 1   BCM_SR_GENPLL4_CCN_CLK
+clk_tpiu_pll   genpll4 2   BCM_SR_GENPLL4_TPIU_PLL_CLK
+noc_clkgenpll4 3   BCM_SR_GENPLL4_NOC_CLK
+clk_chclk_fs4  genpll4 4   BCM_SR_GENPLL4_CHCLK_FS4_CLK
+clk_bridge_fscpu   genpll4 5   BCM_SR_GENPLL4_BRIDGE_FSCPU_CLK
+
+
+genpll5crystal 0   BCM_SR_GENPLL5
+fs4_hf_clk genpll5 1   BCM_SR_GENPLL5_FS4_HF_CLK
+crypto_ae_clk  genpll5 2   BCM_SR_GENPLL5_CRYPTO_AE_CLK
+raid_ae_clkgenpll5 3   
BCM_SR_GENPLL5_RAID_AE_CLK
+
+genpll6crystal 0   BCM_SR_GENPLL6
+48_usb genpll6 1   BCM_SR_GENPLL6_48_USB_CLK
+
+lcpll0 crystal 0   BCM_SR_LCPLL0
+clk_sata_refp  lcpll0  1   BCM_SR_LCPLL0_SATA_REFP_CLK
+clk_sata_refn  lcpll0  2   BCM_SR_LCPLL0_SATA_REFN_CLK
+clk_usb_reflcpll0  3   
BCM_SR_LCPLL0_USB_REF_CLK
+sata_refpn lcpll0  3   BCM_SR_LCPLL0_SATA_REFPN_CLK
+
+lcpll1 crystal 0   BCM_SR_LCPLL1
+wanlcpll1  1   BCM_SR_LCPLL0_WAN_CLK
+
+lcpll_pcie crystal 0   BCM_SR_LCPLL_PCIE
+pcie_phy_ref   lcpll1  1   BCM_SR_LCPLL_PCIE_PHY_REF_CLK
diff --git a/include/dt-bindings/clock/bcm-sr.h 
b/include/dt-bindings/clock/bcm-sr.h
new file mode 100644
index 000..cff6c6f
--- /dev/null
+++ b/include/dt-bindings/clock/bcm-sr.h
@@ -0,0 +1,101 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2017 Broadcom. All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistri

[PATCH v2 04/11] arm64: dts: Initial DTS files for Broadcom Stingray SOC

[Anup Patel]

The Broadcom Stingray SoC is a new member in Broadcom iProc
SoC family.

This patch adds initial DTS files for Broadcom Stingray SoC
and two of its reference boards (bcm958742k and bcm958742t).

We have lot of reference boards and large number of devices
in Broadcom Stingray SoC so eventually we will have quite
a few DTS files for Stingray. To tackle, we have added a
separate directory for Stingray DTS files.

Signed-off-by: Anup Patel 
Signed-off-by: Scott Branden 
Reviewed-by: Ray Jui 
---
 arch/arm64/boot/dts/broadcom/Makefile  |   1 +
 arch/arm64/boot/dts/broadcom/stingray/Makefile |   6 +
 .../boot/dts/broadcom/stingray/bcm958742-base.dtsi |  58 
 .../boot/dts/broadcom/stingray/bcm958742k.dts  |  48 
 .../boot/dts/broadcom/stingray/bcm958742t.dts  |  40 +++
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 307 +
 6 files changed, 460 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/Makefile
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/Makefile 
b/arch/arm64/boot/dts/broadcom/Makefile
index bfa8f8e..f11bdd6 100644
--- a/arch/arm64/boot/dts/broadcom/Makefile
+++ b/arch/arm64/boot/dts/broadcom/Makefile
@@ -1,6 +1,7 @@
 dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-3-b.dtb
 dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb ns2-xmc.dtb
 
+dts-dirs   := stingray
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
 clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/broadcom/stingray/Makefile 
b/arch/arm64/boot/dts/broadcom/stingray/Makefile
new file mode 100644
index 000..f70028e
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/Makefile
@@ -0,0 +1,6 @@
+dtb-$(CONFIG_ARCH_BCM_IPROC) += bcm958742k.dtb
+dtb-$(CONFIG_ARCH_BCM_IPROC) += bcm958742t.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
new file mode 100644
index 000..0a427da
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -0,0 +1,58 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2016-2017 Broadcom.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "stingray.dtsi"
+
+/ {
+   chosen { /* Default kernel args */
+   bootargs = "root=/dev/ram rw rootwait \
+   earlycon=uart8250,mmio32,0x68a1 \
+   pci=pcie_bus_safe cma=64M";
+   linux,stdout-path = "serial0:115200n8";
+   };
+
+   aliases {
+   serial0 = &uart1;
+   serial1 = &uart0;
+   serial2 = &uart2;
+   serial3 = &uart3;
+   };
+};
+
+&memory { /* Default DRAM banks */
+   reg = <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */
+ <0x0008 0x8000 0x1 0x8000>; /* 6G @ 34G */
+};
+
+&uart1 {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.d

[PATCH v2 05/11] arm64: dts: Add clock DT nodes for Stingray SOC

[Anup Patel]

From: Sandeep Tripathy 

This patch describes Stingray SOC clock tree using
DT nodes in Stingray DTS.

Signed-off-by: Sandeep Tripathy 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../boot/dts/broadcom/stingray/stingray-clock.dtsi | 170 +
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi |   9 ++
 2 files changed, 179 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi
new file mode 100644
index 000..070e22e2
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi
@@ -0,0 +1,170 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2016-2017 Broadcom.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+
+   osc: oscillator {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <5000>;
+   };
+
+   crmu_ref25m: crmu_ref25m {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <&osc>;
+   clock-div = <2>;
+   clock-mult = <1>;
+   };
+
+   genpll0: genpll0@6641d104 {
+   #clock-cells = <1>;
+   compatible = "brcm,sr-genpll0";
+   reg = <0x0001d104 0x32>,
+ <0x0001c854 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "genpll0", "clk_125", "clk_scr",
+"clk_250", "clk_pcie_axi",
+"clk_paxc_axi_x2",
+"clk_paxc_axi";
+   };
+
+   genpll3: genpll3@6641d1e0 {
+   #clock-cells = <1>;
+   compatible = "brcm,sr-genpll3";
+   reg = <0x0001d1e0 0x32>,
+ <0x0001c854 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "genpll3", "clk_hsls",
+"clk_sdio";
+   };
+
+   genpll4: genpll4@6641d214 {
+   #clock-cells = <1>;
+   compatible = "brcm,sr-genpll4";
+   reg = <0x0001d214 0x32>,
+ <0x0001c854 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "genpll4", "clk_ccn",
+"clk_tpiu_pll", "noc_clk",
+"pll_chclk_fs4",
+"clk_bridge_fscpu";
+   };
+
+   genpll5: genpll5@6641d248 {
+   #clock-cells = <1>;
+   compatible = "brcm,sr-genpll5";
+   reg = <0x0001d248 0x32>,
+ <0x0001c870 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "genpll5", "fs4_hf_clk",
+"crypto_ae_clk", "raid_ae_clk";
+   };
+
+   lcpll0: lcpll0 {
+   #clock-cells = <1>;
+   

[PATCH v2 00/11] Broadcom Stingray SOC Initial Support

[Anup Patel]

This patchset adds initial support of Broadcom Stingray SOC
by reusing existing Broadcom iProc device drivers.

Most of the patches in this patchset are DT patches except
the Stingray clock tree support which just one patch.

This patchset is based on Linux-4.12-rc1 and it is also available
at stingray-v2 branch of https://github.com/Broadcom/arm64-linux.git

Changes since v1:
 - Rebased patches for Linux-4.12-rc1
 - Removed unwanted /memreserve/ from bcm958742-base.dtsi
 - Use ranges DT property to clear view of memory-layout
 - Make bcm-sr.h part of clock DT bindings patch

Anup Patel (3):
  dt-bindings: bcm: Add Broadcom Stingray bindings document
  arm64: dts: Initial DTS files for Broadcom Stingray SOC
  arm64: dts: Add PL022, PL330 and SP805 DT nodes for Stingray

Oza Pawandeep (1):
  arm64: dts: Add I2C DT nodes for Stingray SoC

Pramod Kumar (3):
  arm64: dts: Add NAND DT nodes for Stingray SOC
  arm64: dts: Add pinctrl DT nodes for Stingray SOC
  arm64: dts: Add GPIO DT nodes for Stingray SOC

Sandeep Tripathy (3):
  dt-bindings: clk: Extend binding doc for Stingray SOC
  clk: bcm: Add clocks for Stingray SOC
  arm64: dts: Add clock DT nodes for Stingray SOC

Srinath Mannam (1):
  arm64: dts: Add PWM and SDHCI DT nodes for Stingray SOC

 .../devicetree/bindings/arm/bcm/brcm,stingray.txt  |  12 +
 .../bindings/clock/brcm,iproc-clocks.txt   |  76 
 arch/arm64/boot/dts/broadcom/Makefile  |   1 +
 arch/arm64/boot/dts/broadcom/stingray/Makefile |   6 +
 .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 134 ++
 .../boot/dts/broadcom/stingray/bcm958742k.dts  |  78 
 .../boot/dts/broadcom/stingray/bcm958742t.dts  |  40 ++
 .../boot/dts/broadcom/stingray/stingray-clock.dtsi | 170 
 .../dts/broadcom/stingray/stingray-pinctrl.dtsi| 345 +++
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 465 +
 drivers/clk/bcm/Kconfig|   8 +
 drivers/clk/bcm/Makefile   |   1 +
 drivers/clk/bcm/clk-sr.c   | 300 +
 include/dt-bindings/clock/bcm-sr.h | 101 +
 .../dt-bindings/pinctrl/brcm,pinctrl-stingray.h|  68 +++
 15 files changed, 1805 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/Makefile
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
 create mode 100644 drivers/clk/bcm/clk-sr.c
 create mode 100644 include/dt-bindings/clock/bcm-sr.h
 create mode 100644 include/dt-bindings/pinctrl/brcm,pinctrl-stingray.h

-- 
2.7.4

[PATCH v2 01/11] dt-bindings: bcm: Add Broadcom Stingray bindings document

[Anup Patel]

This patch adds DT bindings info for Broadcom Stingray SOC
and related reference boards.

Signed-off-by: Anup Patel 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt 
b/Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt
new file mode 100644
index 000..23a0217
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt
@@ -0,0 +1,12 @@
+Broadcom Stingray device tree bindings
+
+
+Boards with Stingray shall have the following properties:
+
+Required root node property:
+
+Stingray Combo SVK board
+compatible = "brcm,bcm958742k", "brcm,stingray";
+
+Stingray SST100 board
+compatible = "brcm,bcm958742t", "brcm,stingray";
-- 
2.7.4

[PATCH v2 10/11] arm64: dts: Add PL022, PL330 and SP805 DT nodes for Stingray

[Anup Patel]

We have two instance of PL022 SPI controllers, one instance of
DMA PL330, and one non-secure SP805 Watchdog on Stingray SOC.

This patch adds DT nodes for the above mentioned devices in
Stingray DT.

Signed-off-by: Anup Patel 
Reviewed-by: Pramod KUMAR 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../boot/dts/broadcom/stingray/bcm958742k.dts  | 30 +
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 52 ++
 2 files changed, 82 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
index c309cda..5671669 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
@@ -46,3 +46,33 @@
 &uart3 {
status = "okay";
 };
+
+&ssp0 {
+   pinctrl-0 = <&spi0_pins>;
+   pinctrl-names = "default";
+   cs-gpios = <&gpio_hsls 34 0>;
+   status = "okay";
+
+   spi-flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <2000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+};
+
+&ssp1 {
+   pinctrl-0 = <&spi1_pins>;
+   pinctrl-names = "default";
+   cs-gpios = <&gpio_hsls 96 0>;
+   status = "okay";
+
+   spi-flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <2000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+};
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 476a6fa..6d9c9f8 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -284,6 +284,14 @@
status = "disabled";
};
 
+   wdt0: watchdog@689c {
+   compatible = "arm,sp805", "arm,primecell";
+   reg = <0x000c 0x1000>;
+   interrupts = ;
+   clocks = <&hsls_25m_div2_clk>, <&hsls_div4_clk>;
+   clock-names = "wdogclk", "apb_pclk";
+   };
+
gpio_hsls: gpio@689d {
compatible = "brcm,iproc-gpio";
reg = <0x000d 0x864>;
@@ -364,11 +372,55 @@
status = "disabled";
};
 
+   ssp0: ssp@68a8 {
+   compatible = "arm,pl022", "arm,primecell";
+   reg = <0x0018 0x1000>;
+   interrupts = ;
+   clocks = <&hsls_div2_clk>, <&hsls_div2_clk>;
+   clock-names = "spiclk", "apb_pclk";
+   num-cs = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   ssp1: ssp@68a9 {
+   compatible = "arm,pl022", "arm,primecell";
+   reg = <0x0019 0x1000>;
+   interrupts = ;
+   clocks = <&hsls_div2_clk>, <&hsls_div2_clk>;
+   clock-names = "spiclk", "apb_pclk";
+   num-cs = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
hwrng: hwrng@68b2 {
compatible = "brcm,iproc-rng200";
reg = <0x0022 0x28>;
};
 
+   dma0: dma@68c1 {
+   compatible = "arm,pl330", "arm,primecell";
+   reg = <0x0031 0x1000>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+;
+   #dma-cells = <1>;
+   #dma-channels = <8>;
+   #dma-requests = <32>;
+   clocks = <&hsls_div2_clk>;
+   clock-names = "apb_pclk";
+   iommus = <&smmu 0x6000 0x>;
+   };
+
nand: nand@68c6 {
compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
reg = <0x0036 0x600>,
-- 
2.7.4

[PATCH v2 06/11] arm64: dts: Add NAND DT nodes for Stingray SOC

[Anup Patel]

From: Pramod Kumar 

This patch adds NAND controller DT Node and NAND chip DT
node for Stingray SOC and Stingray reference boards.

Signed-off-by: Pramod Kumar 
Signed-off-by: Abhishek Shah 
Reviewed-by: Vikram Prakash 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi | 15 +++
 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi   | 13 +
 2 files changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index 0a427da..ce46224 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -56,3 +56,18 @@
 &uart1 {
status = "okay";
 };
+
+&nand {
+   status = "ok";
+   nandcs@0 {
+   compatible = "brcm,nandcs";
+   reg = <0>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <8>;
+   nand-ecc-step-size = <512>;
+   nand-bus-width = <16>;
+   brcm,nand-oob-sector-size = <16>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+};
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 24856e3..c5493e7 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -312,5 +312,18 @@
compatible = "brcm,iproc-rng200";
reg = <0x0022 0x28>;
};
+
+   nand: nand@68c6 {
+   compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+   reg = <0x0036 0x600>,
+ <0x0050a408 0x600>,
+ <0x00360f00 0x20>;
+   reg-names = "nand", "iproc-idm", "iproc-ext";
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   brcm,nand-has-wp;
+   status = "disabled";
+   };
};
 };
-- 
2.7.4

[PATCH v2 09/11] arm64: dts: Add I2C DT nodes for Stingray SoC

[Anup Patel]

From: Oza Pawandeep 

This patch adds I2C DT nodes on Stingray SoC.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Vikram Prakash 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 22 ++
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 20 
 2 files changed, 42 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index ce46224..e3f8c89 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -57,6 +57,28 @@
status = "okay";
 };
 
+&i2c0 {
+   status = "okay";
+
+   pca9505: pca9505@20 {
+   compatible = "nxp,pca9505";
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x20>;
+   };
+};
+
+&i2c1 {
+   status = "okay";
+
+   pcf8574: pcf8574@20 {
+   compatible = "nxp,pcf8574a";
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x27>;
+   };
+};
+
 &nand {
status = "ok";
nandcs@0 {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 2b24d07..476a6fa 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -274,6 +274,16 @@
 
#include "stingray-pinctrl.dtsi"
 
+   i2c0: i2c@689b {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x000b 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
+
gpio_hsls: gpio@689d {
compatible = "brcm,iproc-gpio";
reg = <0x000d 0x864>;
@@ -300,6 +310,16 @@
<&pinmux 151 91 4>;
};
 
+   i2c1: i2c@689e {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x000e 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
+
uart0: uart@68a0 {
device_type = "serial";
compatible = "snps,dw-apb-uart";
-- 
2.7.4

[PATCH v2 11/11] arm64: dts: Add PWM and SDHCI DT nodes for Stingray SOC

[Anup Patel]

From: Srinath Mannam 

The Stingray SoC has two instances of SDHCI controller
and one instance of iProc PWM.

Let's enable above mentioned devices in Stingray DT.

Signed-off-by: Srinath Mannam 
Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 39 ++
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 28 
 2 files changed, 67 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index e3f8c89..6185561 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -46,6 +46,28 @@
serial2 = &uart2;
serial3 = &uart3;
};
+
+   sdio0_vddo_ctrl_reg: sdio0_vddo_ctrl {
+   compatible = "regulator-gpio";
+   regulator-name = "sdio0_vddo_ctrl_reg";
+   regulator-type = "voltage";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   gpios = <&pca9505 18 0>;
+   states = <330 0x0
+ 180 0x1>;
+   };
+
+   sdio1_vddo_ctrl_reg: sdio1_vddo_ctrl {
+   compatible = "regulator-gpio";
+   regulator-name = "sdio1_vddo_ctrl_reg";
+   regulator-type = "voltage";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   gpios = <&pca9505 19 0>;
+   states = <330 0x0
+ 180 0x1>;
+   };
 };
 
 &memory { /* Default DRAM banks */
@@ -57,6 +79,10 @@
status = "okay";
 };
 
+&pwm {
+   status = "okay";
+};
+
 &i2c0 {
status = "okay";
 
@@ -93,3 +119,16 @@
#size-cells = <1>;
};
 };
+
+&sdio0 {
+   vqmmc-supply = <&sdio0_vddo_ctrl_reg>;
+   non-removable;
+   full-pwr-cycle;
+   status = "okay";
+};
+
+&sdio1 {
+   vqmmc-supply = <&sdio1_vddo_ctrl_reg>;
+   full-pwr-cycle;
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 6d9c9f8..aa0ecec 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -274,6 +274,14 @@
 
#include "stingray-pinctrl.dtsi"
 
+   pwm: pwm@6891{
+   compatible = "brcm,iproc-pwm";
+   reg = <0x0001 0x1000>;
+   clocks = <&crmu_ref25m>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
i2c0: i2c@689b {
compatible = "brcm,iproc-i2c";
reg = <0x000b 0x100>;
@@ -433,5 +441,25 @@
brcm,nand-has-wp;
status = "disabled";
};
+
+   sdio0: sdhci@68cf1000 {
+   compatible = "brcm,sdhci-iproc";
+   reg = <0x003f1000 0x100>;
+   interrupts = ;
+   bus-width = <8>;
+   clocks = <&sdio0_clk>;
+   iommus = <&smmu 0x6002 0x>;
+   status = "disabled";
+   };
+
+   sdio1: sdhci@68cf2000 {
+   compatible = "brcm,sdhci-iproc";
+   reg = <0x003f2000 0x100>;
+   interrupts = ;
+   bus-width = <8>;
+   clocks = <&sdio1_clk>;
+   iommus = <&smmu 0x6003 0x>;
+   status = "disabled";
+   };
};
 };
-- 
2.7.4

[PATCH v2 07/11] arm64: dts: Add pinctrl DT nodes for Stingray SOC

[Anup Patel]

From: Pramod Kumar 

This patch adds pinctrl and pinmux related DT nodes for
Stingray SOC.

For manageability, pinctrl and pinmum DT nodes are added
as separate DTSi file and included in main DTSi file.

Signed-off-by: Pramod Kumar 
Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Vikram Prakash 
Reviewed-by: Scott Branden 
---
 .../dts/broadcom/stingray/stingray-pinctrl.dtsi| 345 +
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi |   2 +
 .../dt-bindings/pinctrl/brcm,pinctrl-stingray.h|  68 
 3 files changed, 415 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi
 create mode 100644 include/dt-bindings/pinctrl/brcm,pinctrl-stingray.h

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi
new file mode 100644
index 000..af5d480
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi
@@ -0,0 +1,345 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2016-2017 Broadcom.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+
+   pinconf: pinconf@68a4 {
+   compatible = "pinconf-single";
+   reg = <0x0014 0x250>;
+   pinctrl-single,register-width = <32>;
+
+   /* pinconf functions */
+   };
+
+   pinmux: pinmux@68a4029c {
+   compatible = "pinctrl-single";
+   reg = <0x0014029c 0x250>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   pinctrl-single,register-width = <32>;
+   pinctrl-single,function-mask = <0xf>;
+   pinctrl-single,gpio-range = <
+   &range 0 154 MODE_GPIO
+   >;
+   range: gpio-range {
+   #pinctrl-single,gpio-range-cells = <3>;
+   };
+
+   /* pinctrl functions */
+   tsio_pins: pinmux_gpio_14 {
+   pinctrl-single,pins = <
+   0x038 MODE_NITRO /* tsio_0 */
+   0x03c MODE_NITRO /* tsio_1 */
+   >;
+   };
+
+   nor_pins: pinmux_pnor_adv_n {
+   pinctrl-single,pins = <
+   0x0ac MODE_PNOR /* nand_ce1_n */
+   0x0b0 MODE_PNOR /* nand_ce0_n */
+   0x0b4 MODE_PNOR /* nand_we_n */
+   0x0b8 MODE_PNOR /* nand_wp_n */
+   0x0bc MODE_PNOR /* nand_re_n */
+   0x0c0 MODE_PNOR /* nand_rdy_bsy_n */
+   0x0c4 MODE_PNOR /* nand_io0_0 */
+   0x0c8 MODE_PNOR /* nand_io1_0 */
+   0x0cc MODE_PNOR /* nand_io2_0 */
+   0x0d0 MODE_PNOR /* nand_io3_0 */
+   0x0d4

[PATCH v2 08/11] arm64: dts: Add GPIO DT nodes for Stingray SOC

[Anup Patel]

From: Pramod Kumar 

The GPIOs on Stingray SOC are based on iProc GPIOs hence
using this we add GPIO DT nodes for Stingray SOC.

Signed-off-by: Pramod Kumar 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index c3a8cee..2b24d07 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -256,6 +256,14 @@
ranges = <0x0 0x0 0x6640 0x10>;
 
#include "stingray-clock.dtsi"
+
+   gpio_crmu: gpio@66424800 {
+   compatible = "brcm,iproc-gpio";
+   reg = <0x00024800 0x4c>;
+   ngpios = <6>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   };
};
 
hsls {
@@ -266,6 +274,32 @@
 
#include "stingray-pinctrl.dtsi"
 
+   gpio_hsls: gpio@689d {
+   compatible = "brcm,iproc-gpio";
+   reg = <0x000d 0x864>;
+   ngpios = <151>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   interrupt-controller;
+   interrupts = ;
+   gpio-ranges = <&pinmux 0 0 16>,
+   <&pinmux 16 71 2>,
+   <&pinmux 18 131 8>,
+   <&pinmux 26 83 6>,
+   <&pinmux 32 123 4>,
+   <&pinmux 36 43 24>,
+   <&pinmux 60 89 2>,
+   <&pinmux 62 73 4>,
+   <&pinmux 66 95 28>,
+   <&pinmux 94 127 4>,
+   <&pinmux 98 139 10>,
+   <&pinmux 108 16 27>,
+   <&pinmux 135 77 6>,
+   <&pinmux 141 67 4>,
+   <&pinmux 145 149 6>,
+   <&pinmux 151 91 4>;
+   };
+
uart0: uart@68a0 {
device_type = "serial";
compatible = "snps,dw-apb-uart";
-- 
2.7.4