Re: [PATCH v3 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions

[Kumar Gala]

On Oct 21, 2014, at 7:56 AM, Ankit Jindal  wrote:

> 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: Tushar Jagad 
> ---
> drivers/uio/uio.c  |   11 ---
> include/linux/uio_driver.h |1 +
> 2 files changed, 9 insertions(+), 3 deletions(-)

Rather than adding a new type, why not allow the driver to set the pgprot 
value, this way one has full control and we don’t need to keep adding types for 
various different cache attributions in the future.

- k

> 
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index 97e6444..120a84b 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -644,7 +644,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, bool cacheable)
> {
>   struct uio_device *idev = vma->vm_private_data;
>   int mi = uio_find_mem_index(vma);
> @@ -659,7 +659,9 @@ 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);
> +
> + if (!cacheable)
> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> 
>   /*
>* We cannot use the vm_iomap_memory() helper here,
> @@ -707,10 +709,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);
> + return uio_mmap_physical(vma, false);
>   case UIO_MEM_LOGICAL:
>   case UIO_MEM_VIRTUAL:
>   return uio_mmap_logical(vma);
> + case UIO_MEM_PHYS_CACHE:
> + return uio_mmap_physical(vma, true);
> +
>   default:
>   return -EINVAL;
>   }
> diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
> index 1ad4724..40ca3f3 100644
> --- a/include/linux/uio_driver.h
> +++ b/include/linux/uio_driver.h
> @@ -118,6 +118,7 @@ extern void uio_event_notify(struct uio_info *info);
> #define UIO_MEM_PHYS  1
> #define UIO_MEM_LOGICAL   2
> #define UIO_MEM_VIRTUAL 3
> +#define UIO_MEM_PHYS_CACHE   4
> 
> /* defines for uio_port->porttype */
> #define UIO_PORT_NONE 0
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/6] uio: Add X-Gene QMTM UIO driver

[Ankit Jindal]

On 21 October 2014 11:47, Varka Bhadram  wrote:
> On 10/21/2014 11:46 AM, Ankit Jindal wrote:
>>
>> On 21 October 2014 11:34, Varka Bhadram  wrote:
>>>
>>> On 10/21/2014 11:26 AM, Ankit Jindal wrote:

 The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
 and Traffic manager) which is hardware based Queue or Ring
 manager. This QMTM device can be used in conjunction with
 other devices such as DMA Engine, Ethernet, Security Engine,
 etc to assign work based on queues or rings.

 This patch allows user space access to X-Gene QMTM device.

 Signed-off-by: Ankit Jindal 
 Signed-off-by: Tushar Jagad 
>>>
>>>
>>> (...)
>>>
>>>
 +
 +static int qmtm_probe(struct platform_device *pdev)
 +{
 +   struct uio_info *info;
 +   struct uio_qmtm_dev *qmtm_dev;
 +   struct resource *csr;
 +   struct resource *fabric;
 +   struct resource qpool;
 +   unsigned int num_queues;
 +   unsigned int devid;
 +   phandle qpool_phandle;
 +   struct device_node *qpool_node;
 +   int ret;
 +
 +   qmtm_dev = devm_kzalloc(&pdev->dev, sizeof(struct uio_qmtm_dev),
 +   GFP_KERNEL);
 +   if (!qmtm_dev)
 +   return -ENOMEM;
 +
 +   qmtm_dev->info = devm_kzalloc(&pdev->dev, sizeof(*info),
 GFP_KERNEL);
 +   if (!qmtm_dev->info)
 +   return -ENOMEM;
 +
 +   /* Power on qmtm in case its not done as part of boot-loader */
 +   qmtm_dev->qmtm_clk = devm_clk_get(&pdev->dev, NULL);
 +   if (IS_ERR(qmtm_dev->qmtm_clk)) {
 +   dev_err(&pdev->dev, "Failed to get clock\n");
 +   ret = PTR_ERR(qmtm_dev->qmtm_clk);
 +   return ret;
 +   }
 +
 +   csr = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 +   if (!csr) {
 +   ret = -ENODEV;
 +   dev_err(&pdev->dev, "No QMTM CSR resource specified\n");
 +   goto out_err;
 +   }
 +
>>>
>>>
>>> This error check is not required. *csr* is checked in
>>> devm_ioremap_resource().
>>
>> I think its better to do sanity check before calling any function.
>
>
> It will be the duplication of code for sanity check. This sanity check is
> happening
> with devm_ioremap_resource(). No need to check it explicitly.

Okie, will remove it in next revision.

>
 +   if (!csr->start) {
 +   ret = -EINVAL;
 +   dev_err(&pdev->dev, "Invalid CSR resource\n");
 +   goto out_err;
 +   }
 +
 +   fabric = platform_get_resource(pdev, IORESOURCE_MEM, 1);
 +   if (!fabric) {
 +   ret = -ENODEV;
 +   dev_err(&pdev->dev, "No QMTM Fabric resource
 specified\n");
 +   goto out_err;
 +   }
 +
>>>
>>>
>>> same
>>
>> We do not ioremap this address.
>
>
> Ok..
>
> --
> Regards,
> Varka Bhadram.
>
Thanks,
Ankit
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/6] uio: Add X-Gene QMTM UIO driver

[Varka Bhadram]

On 10/21/2014 11:46 AM, Ankit Jindal wrote:

On 21 October 2014 11:34, Varka Bhadram  wrote:

On 10/21/2014 11:26 AM, Ankit Jindal wrote:

The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
and Traffic manager) which is hardware based Queue or Ring
manager. This QMTM device can be used in conjunction with
other devices such as DMA Engine, Ethernet, Security Engine,
etc to assign work based on queues or rings.

This patch allows user space access to X-Gene QMTM device.

Signed-off-by: Ankit Jindal 
Signed-off-by: Tushar Jagad 


(...)



+
+static int qmtm_probe(struct platform_device *pdev)
+{
+   struct uio_info *info;
+   struct uio_qmtm_dev *qmtm_dev;
+   struct resource *csr;
+   struct resource *fabric;
+   struct resource qpool;
+   unsigned int num_queues;
+   unsigned int devid;
+   phandle qpool_phandle;
+   struct device_node *qpool_node;
+   int ret;
+
+   qmtm_dev = devm_kzalloc(&pdev->dev, sizeof(struct uio_qmtm_dev),
+   GFP_KERNEL);
+   if (!qmtm_dev)
+   return -ENOMEM;
+
+   qmtm_dev->info = devm_kzalloc(&pdev->dev, sizeof(*info),
GFP_KERNEL);
+   if (!qmtm_dev->info)
+   return -ENOMEM;
+
+   /* Power on qmtm in case its not done as part of boot-loader */
+   qmtm_dev->qmtm_clk = devm_clk_get(&pdev->dev, NULL);
+   if (IS_ERR(qmtm_dev->qmtm_clk)) {
+   dev_err(&pdev->dev, "Failed to get clock\n");
+   ret = PTR_ERR(qmtm_dev->qmtm_clk);
+   return ret;
+   }
+
+   csr = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!csr) {
+   ret = -ENODEV;
+   dev_err(&pdev->dev, "No QMTM CSR resource specified\n");
+   goto out_err;
+   }
+


This error check is not required. *csr* is checked in
devm_ioremap_resource().

I think its better to do sanity check before calling any function.


It will be the duplication of code for sanity check. This sanity check is 
happening
with devm_ioremap_resource(). No need to check it explicitly.


+   if (!csr->start) {
+   ret = -EINVAL;
+   dev_err(&pdev->dev, "Invalid CSR resource\n");
+   goto out_err;
+   }
+
+   fabric = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   if (!fabric) {
+   ret = -ENODEV;
+   dev_err(&pdev->dev, "No QMTM Fabric resource
specified\n");
+   goto out_err;
+   }
+


same

We do not ioremap this address.


Ok..

--
Regards,
Varka Bhadram.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/6] uio: Add X-Gene QMTM UIO driver

[Ankit Jindal]

On 21 October 2014 11:34, Varka Bhadram  wrote:
> On 10/21/2014 11:26 AM, Ankit Jindal wrote:
>>
>> The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
>> and Traffic manager) which is hardware based Queue or Ring
>> manager. This QMTM device can be used in conjunction with
>> other devices such as DMA Engine, Ethernet, Security Engine,
>> etc to assign work based on queues or rings.
>>
>> This patch allows user space access to X-Gene QMTM device.
>>
>> Signed-off-by: Ankit Jindal 
>> Signed-off-by: Tushar Jagad 
>
>
> (...)
>
>
>> +
>> +static int qmtm_probe(struct platform_device *pdev)
>> +{
>> +   struct uio_info *info;
>> +   struct uio_qmtm_dev *qmtm_dev;
>> +   struct resource *csr;
>> +   struct resource *fabric;
>> +   struct resource qpool;
>> +   unsigned int num_queues;
>> +   unsigned int devid;
>> +   phandle qpool_phandle;
>> +   struct device_node *qpool_node;
>> +   int ret;
>> +
>> +   qmtm_dev = devm_kzalloc(&pdev->dev, sizeof(struct uio_qmtm_dev),
>> +   GFP_KERNEL);
>> +   if (!qmtm_dev)
>> +   return -ENOMEM;
>> +
>> +   qmtm_dev->info = devm_kzalloc(&pdev->dev, sizeof(*info),
>> GFP_KERNEL);
>> +   if (!qmtm_dev->info)
>> +   return -ENOMEM;
>> +
>> +   /* Power on qmtm in case its not done as part of boot-loader */
>> +   qmtm_dev->qmtm_clk = devm_clk_get(&pdev->dev, NULL);
>> +   if (IS_ERR(qmtm_dev->qmtm_clk)) {
>> +   dev_err(&pdev->dev, "Failed to get clock\n");
>> +   ret = PTR_ERR(qmtm_dev->qmtm_clk);
>> +   return ret;
>> +   }
>> +
>> +   csr = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +   if (!csr) {
>> +   ret = -ENODEV;
>> +   dev_err(&pdev->dev, "No QMTM CSR resource specified\n");
>> +   goto out_err;
>> +   }
>> +
>
>
> This error check is not required. *csr* is checked in
> devm_ioremap_resource().

I think its better to do sanity check before calling any function.

>
>> +   if (!csr->start) {
>> +   ret = -EINVAL;
>> +   dev_err(&pdev->dev, "Invalid CSR resource\n");
>> +   goto out_err;
>> +   }
>> +
>> +   fabric = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>> +   if (!fabric) {
>> +   ret = -ENODEV;
>> +   dev_err(&pdev->dev, "No QMTM Fabric resource
>> specified\n");
>> +   goto out_err;
>> +   }
>> +
>
>
> same

We do not ioremap this address.

>
>
>> +   if (!fabric->start) {
>> +   ret = -EINVAL;
>> +   dev_err(&pdev->dev, "Invalid Fabric resource\n");
>> +   goto out_err;
>> +   }
>> +
>> +   ret = of_property_read_u32(pdev->dev.of_node, "qpool",
>> &qpool_phandle);
>> +   if (ret < 0) {
>> +   dev_err(&pdev->dev, "No qpool resource specified\n");
>> +   goto out_err;
>> +   }
>> +
>> +   qpool_node = of_find_node_by_phandle(qpool_phandle);
>> +   if (IS_ERR_OR_NULL(qpool_node)) {
>> +   ret = PTR_ERR(qpool_node);
>> +   dev_err(&pdev->dev, "Failed to get node by phandle\n");
>> +   goto out_err;
>> +   }
>> +
>> +   ret = of_address_to_resource(qpool_node, 0, &qpool);
>> +
>> +   of_node_put(qpool_node);
>> +
>> +   if (ret < 0) {
>> +   dev_err(&pdev->dev, "Failed to get qpool resource from
>> node\n");
>> +   goto out_err;
>> +   }
>> +
>> +   if (!qpool.start) {
>> +   ret = -EINVAL;
>> +   dev_err(&pdev->dev, "Invalid qpool resource\n");
>> +   goto out_err;
>> +   }
>> +
>> +   ret = of_property_read_u32(pdev->dev.of_node, "num-queues",
>> +   &num_queues);
>> +   if (ret < 0) {
>> +   dev_err(&pdev->dev, "No num-queues resource specified\n");
>> +   goto out_err;
>> +   }
>> +
>> +   /* check whether sufficient memory is provided for the given
>> queues */
>> +   if (num_queues * QMTM_DEFAULT_QSIZE > resource_size(&qpool)) {
>> +   ret = -ENOSPC;
>> +   dev_err(&pdev->dev, "Insufficient Qpool for the given
>> queues\n");
>> +   goto out_err;
>> +   }
>> +
>> +   ret = of_property_read_u32(pdev->dev.of_node, "devid", &devid);
>> +   if (ret < 0) {
>> +   dev_err(&pdev->dev, "No devid resource specified\n");
>> +   goto out_err;
>> +   }
>> +
>> +   info = qmtm_dev->info;
>> +   info->mem[0].name = "csr";
>> +   info->mem[0].addr = csr->start;
>> +   info->mem[0].size = resource_size(csr);
>> +   info->mem[0].memtype = UIO_MEM_PHYS;
>> +   info->mem[0].internal_addr = devm_ioremap_resource(&pdev->dev,
>> csr);
>> +
>> +   if (IS_ERR(info->mem[0].internal_addr)) {
>> +   ret = PTR_ERR(info->mem[0].internal_addr);
>> +   dev_err(&pdev->dev, "F

Re: [PATCH v3 4/6] uio: Add X-Gene QMTM UIO driver

[Varka Bhadram]

On 10/21/2014 11:26 AM, Ankit Jindal wrote:

The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
and Traffic manager) which is hardware based Queue or Ring
manager. This QMTM device can be used in conjunction with
other devices such as DMA Engine, Ethernet, Security Engine,
etc to assign work based on queues or rings.

This patch allows user space access to X-Gene QMTM device.

Signed-off-by: Ankit Jindal 
Signed-off-by: Tushar Jagad 


(...)


+
+static int qmtm_probe(struct platform_device *pdev)
+{
+   struct uio_info *info;
+   struct uio_qmtm_dev *qmtm_dev;
+   struct resource *csr;
+   struct resource *fabric;
+   struct resource qpool;
+   unsigned int num_queues;
+   unsigned int devid;
+   phandle qpool_phandle;
+   struct device_node *qpool_node;
+   int ret;
+
+   qmtm_dev = devm_kzalloc(&pdev->dev, sizeof(struct uio_qmtm_dev),
+   GFP_KERNEL);
+   if (!qmtm_dev)
+   return -ENOMEM;
+
+   qmtm_dev->info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
+   if (!qmtm_dev->info)
+   return -ENOMEM;
+
+   /* Power on qmtm in case its not done as part of boot-loader */
+   qmtm_dev->qmtm_clk = devm_clk_get(&pdev->dev, NULL);
+   if (IS_ERR(qmtm_dev->qmtm_clk)) {
+   dev_err(&pdev->dev, "Failed to get clock\n");
+   ret = PTR_ERR(qmtm_dev->qmtm_clk);
+   return ret;
+   }
+
+   csr = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!csr) {
+   ret = -ENODEV;
+   dev_err(&pdev->dev, "No QMTM CSR resource specified\n");
+   goto out_err;
+   }
+


This error check is not required. *csr* is checked in devm_ioremap_resource().


+   if (!csr->start) {
+   ret = -EINVAL;
+   dev_err(&pdev->dev, "Invalid CSR resource\n");
+   goto out_err;
+   }
+
+   fabric = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   if (!fabric) {
+   ret = -ENODEV;
+   dev_err(&pdev->dev, "No QMTM Fabric resource specified\n");
+   goto out_err;
+   }
+


same


+   if (!fabric->start) {
+   ret = -EINVAL;
+   dev_err(&pdev->dev, "Invalid Fabric resource\n");
+   goto out_err;
+   }
+
+   ret = of_property_read_u32(pdev->dev.of_node, "qpool", &qpool_phandle);
+   if (ret < 0) {
+   dev_err(&pdev->dev, "No qpool resource specified\n");
+   goto out_err;
+   }
+
+   qpool_node = of_find_node_by_phandle(qpool_phandle);
+   if (IS_ERR_OR_NULL(qpool_node)) {
+   ret = PTR_ERR(qpool_node);
+   dev_err(&pdev->dev, "Failed to get node by phandle\n");
+   goto out_err;
+   }
+
+   ret = of_address_to_resource(qpool_node, 0, &qpool);
+
+   of_node_put(qpool_node);
+
+   if (ret < 0) {
+   dev_err(&pdev->dev, "Failed to get qpool resource from node\n");
+   goto out_err;
+   }
+
+   if (!qpool.start) {
+   ret = -EINVAL;
+   dev_err(&pdev->dev, "Invalid qpool resource\n");
+   goto out_err;
+   }
+
+   ret = of_property_read_u32(pdev->dev.of_node, "num-queues",
+   &num_queues);
+   if (ret < 0) {
+   dev_err(&pdev->dev, "No num-queues resource specified\n");
+   goto out_err;
+   }
+
+   /* check whether sufficient memory is provided for the given queues */
+   if (num_queues * QMTM_DEFAULT_QSIZE > resource_size(&qpool)) {
+   ret = -ENOSPC;
+   dev_err(&pdev->dev, "Insufficient Qpool for the given 
queues\n");
+   goto out_err;
+   }
+
+   ret = of_property_read_u32(pdev->dev.of_node, "devid", &devid);
+   if (ret < 0) {
+   dev_err(&pdev->dev, "No devid resource specified\n");
+   goto out_err;
+   }
+
+   info = qmtm_dev->info;
+   info->mem[0].name = "csr";
+   info->mem[0].addr = csr->start;
+   info->mem[0].size = resource_size(csr);
+   info->mem[0].memtype = UIO_MEM_PHYS;
+   info->mem[0].internal_addr = devm_ioremap_resource(&pdev->dev, csr);
+
+   if (IS_ERR(info->mem[0].internal_addr)) {
+   ret = PTR_ERR(info->mem[0].internal_addr);
+   dev_err(&pdev->dev, "Failed to ioremap CSR region\n");
+   goto out_err;
+   }
+
+   info->mem[1].name = "fabric";
+   info->mem[1].addr = fabric->start;
+   info->mem[1].size = resource_size(fabric);
+   info->mem[1].memtype = UIO_MEM_PHYS;
+
+   info->mem[2].name = "qpool";
+   info->mem[2].addr = qpool.start;
+   info->mem[2].size = resource_size(&qpool);
+   info->mem[2].memtype = UIO_MEM_PHYS_CACHE;
+
+   info->name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "qmtm%d", devid);
+   info->version = DRV_VERSION;
+
+   info

Re: [PATCH 1/2] ASoC: rockchip-max98090: add driver for rockchip board using a max98090

[Jianqun]

Hi , could someone help to review my patch ?

在 10/07/2014 09:43 AM, Jianqun 写道:
> The driver is used for rockchip board using a max98090.
> Test on RK3288 board with max98090.
>
> Signed-off-by: Jianqun Xu 
> ---
>  sound/soc/rockchip/Kconfig |   9 +
>  sound/soc/rockchip/Makefile|   5 +-
>  sound/soc/rockchip/rockchip_max98090.c | 346 
> +
>  3 files changed, 359 insertions(+), 1 deletion(-)
>  create mode 100644 sound/soc/rockchip/rockchip_max98090.c
>
> diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
> index 78fc159..f82fbf5 100644
> --- a/sound/soc/rockchip/Kconfig
> +++ b/sound/soc/rockchip/Kconfig
> @@ -9,3 +9,12 @@ config SND_SOC_ROCKCHIP
>  
>  config SND_SOC_ROCKCHIP_I2S
>   tristate
> +
> +config SND_SOC_ROCKCHIP_MAX98090
> + tristate "ASoC support for Rockchip boards using a MAX98090 codec"
> + depends on SND_SOC_ROCKCHIP && I2C && GPIOLIB
> + select SND_SOC_ROCKCHIP_I2S
> + select SND_SOC_MAX98090
> + help
> +   Say Y or M here if you want to add support for SoC audio on Rockchip
> +   boards using the MAX98090 codec, such as Veyron.
> diff --git a/sound/soc/rockchip/Makefile b/sound/soc/rockchip/Makefile
> index b921909..c324411 100644
> --- a/sound/soc/rockchip/Makefile
> +++ b/sound/soc/rockchip/Makefile
> @@ -1,4 +1,7 @@
>  # ROCKCHIP Platform Support
>  snd-soc-i2s-objs := rockchip_i2s.o
> -
>  obj-$(CONFIG_SND_SOC_ROCKCHIP_I2S) += snd-soc-i2s.o
> +
> +# ROCKCHIP Machine Support
> +snd-soc-rockchip-max98090-objs := rockchip_max98090.o
> +obj-$(CONFIG_SND_SOC_ROCKCHIP_MAX98090) += snd-soc-rockchip-max98090.o
> diff --git a/sound/soc/rockchip/rockchip_max98090.c 
> b/sound/soc/rockchip/rockchip_max98090.c
> new file mode 100644
> index 000..928b161
> --- /dev/null
> +++ b/sound/soc/rockchip/rockchip_max98090.c
> @@ -0,0 +1,346 @@
> +/*
> + * Rockchip machine ASoC driver for boards using a MAX90809 CODEC.
> + *
> + * Copyright (c) 2014, ROCKCHIP CORPORATION.  All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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 .
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "rockchip_i2s.h"
> +
> +#define DRV_NAME "rockchip-snd-max98090"
> +
> +struct rk_mc_private {
> + struct snd_soc_jack hp_jack;
> + struct snd_soc_jack mic_jack;
> +};
> +
> +static const struct snd_soc_dapm_widget rk_dapm_widgets[] = {
> + SND_SOC_DAPM_HP("Headphone", NULL),
> + SND_SOC_DAPM_MIC("Headset Mic", NULL),
> + SND_SOC_DAPM_MIC("Int Mic", NULL),
> + SND_SOC_DAPM_SPK("Ext Spk", NULL),
> +};
> +
> +static const struct snd_soc_dapm_route rk_audio_map[] = {
> + {"IN34", NULL, "Headset Mic"},
> + {"IN34", NULL, "MICBIAS"},
> + {"MICBIAS", NULL, "Headset Mic"},
> + {"DMICL", NULL, "Int Mic"},
> + {"Headphone", NULL, "HPL"},
> + {"Headphone", NULL, "HPR"},
> + {"Ext Spk", NULL, "SPKL"},
> + {"Ext Spk", NULL, "SPKR"},
> +};
> +
> +static const struct snd_kcontrol_new rk_mc_controls[] = {
> + SOC_DAPM_PIN_SWITCH("Headphone"),
> + SOC_DAPM_PIN_SWITCH("Headset Mic"),
> + SOC_DAPM_PIN_SWITCH("Int Mic"),
> + SOC_DAPM_PIN_SWITCH("Ext Spk"),
> +};
> +
> +static int rk_aif1_hw_params(struct snd_pcm_substream *substream,
> +  struct snd_pcm_hw_params *params)
> +{
> + int ret = 0;
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
> + struct snd_soc_dai *codec_dai = rtd->codec_dai;
> + int srate, mclk;
> +
> + srate = params_rate(params);
> + switch (srate) {
> + case 8000:
> + case 16000:
> + case 24000:
> + case 32000:
> + case 48000:
> + case 64000:
> + case 96000:
> + mclk = 12288000;
> + break;
> + case 11025:
> + case 22050:
> + case 44100:
> + case 88200:
> + mclk = 11289600;
> + break;
> + default:
> + mclk = 1200;
> + break;
> + }
> +
> + ret = snd_soc_dai_set_sysclk(cpu_dai, 0,
> +  mclk,
> +  SND_SOC_CLOCK_OUT);
> + if (ret < 0) {
> + dev_err(codec_dai->dev, "Can't set codec clock %d\n", ret);
> + return ret;
> + }
> +
>

[PATCH v3 3/6] Documentation: Update documentation for UIO_MEM_PHYS_CACHE

[Ankit Jindal]

This patch updates UIO documentation for new mem region
type UIO_MEM_PHYS_CACHE.

Signed-off-by: Ankit Jindal 
Signed-off-by: Tushar Jagad 
---
 Documentation/DocBook/uio-howto.tmpl |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/uio-howto.tmpl 
b/Documentation/DocBook/uio-howto.tmpl
index bbe9c1f..baa9185 100644
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -529,8 +529,9 @@ 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, and
+UIO_MEM_PHYS_CACHE for cacheable access to physical memory.
 
 
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions

[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: Tushar Jagad 
---
 drivers/uio/uio.c  |   11 ---
 include/linux/uio_driver.h |1 +
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 97e6444..120a84b 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -644,7 +644,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, bool cacheable)
 {
struct uio_device *idev = vma->vm_private_data;
int mi = uio_find_mem_index(vma);
@@ -659,7 +659,9 @@ 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);
+
+   if (!cacheable)
+   vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
 
/*
 * We cannot use the vm_iomap_memory() helper here,
@@ -707,10 +709,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);
+   return uio_mmap_physical(vma, false);
case UIO_MEM_LOGICAL:
case UIO_MEM_VIRTUAL:
return uio_mmap_logical(vma);
+   case UIO_MEM_PHYS_CACHE:
+   return uio_mmap_physical(vma, true);
+
default:
return -EINVAL;
}
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 1ad4724..40ca3f3 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -118,6 +118,7 @@ extern void uio_event_notify(struct uio_info *info);
 #define UIO_MEM_PHYS   1
 #define UIO_MEM_LOGICAL2
 #define UIO_MEM_VIRTUAL 3
+#define UIO_MEM_PHYS_CACHE 4
 
 /* defines for uio_port->porttype */
 #define UIO_PORT_NONE  0
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/6] uio: code style cleanup

[Ankit Jindal]

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

Signed-off-by: Ankit Jindal 
Signed-off-by: Tushar Jagad 
---
 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 a673e5b..97e6444 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -706,13 +706,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.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Ankit Jindal]

This patch adds device tree binding documentation for
X-Gene QMTM UIO driver.

Signed-off-by: Ankit Jindal 
Signed-off-by: Tushar Jagad 
---
 .../devicetree/bindings/uio/uio_xgene_qmtm.txt |   53 
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt

diff --git a/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt 
b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
new file mode 100644
index 000..288ed92
--- /dev/null
+++ b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
@@ -0,0 +1,53 @@
+APM X-Gene QMTM UIO nodes
+
+The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
+and Traffic manager). It is a device for managing hardware queues.
+It also implements QoS among hardware queues hence term "traffic"
+manager is present in its name. QMTM UIO nodes are defined for user
+space access to this device using UIO framework.
+
+Required properties:
+- compatible: Should be "apm,xgene-qmtm"
+- reg: Address and length of the register set for the device. It contains the
+  information of registers in the same order as described by reg-names.
+- reg-names: Should contain the register set names
+  - "csr": QMTM control and status register address space.
+  - "fabric": QMTM memory mapped access to queue states.
+- qpool: Points to the phandle of the node defining memory location for
+creating QMTM queues. This could point either to the reserved-memory
+node (as-per reserved memory bindings) or to the node of on-chip
+SRAM etc. It is expected that size and location of qpool memory will
+be configurable via bootloader.
+- clocks: Reference to the clock entry.
+- num-queues: Number of queues under this QMTM device.
+- devid: QMTM identification number for the system having multiple QMTM 
devices.
+This is used to form a unique id (a tuple of queue number and
+device id) for the queues belonging to this device.
+
+Example:
+   qmtm1_uio_qpool: qmtm1_uio_qpool {
+   reg = <0x0 0x0 0x0 0x0>
+   };
+
+   qmtm1clk: qmtmclk@1f20c000 {
+   compatible = "apm,xgene-device-clock";
+   clock-output-names = "qmtm1clk";
+   status = "ok";
+   };
+
+   qmtm1_uio: qmtm_uio@1f20 {
+   compatible = "apm,xgene-qmtm";
+   status = "disabled";
+   reg = <0x0 0x1f20 0x0 0x1>,
+ <0x0 0x1b00 0x0 0x40>;
+   reg-names = "csr", "fabric";
+   qpool = <&qmtm1_uio_qpool>;
+   clocks = <&qmtm1clk 0>;
+   num-queues = <0x400>;
+   devid = <1>;
+   };
+
+   /* Board-specific peripheral configurations */
+   &qmtm1_uio {
+   status = "ok";
+   };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/6] uio: Add X-Gene QMTM UIO driver

[Ankit Jindal]

The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
and Traffic manager) which is hardware based Queue or Ring
manager. This QMTM device can be used in conjunction with
other devices such as DMA Engine, Ethernet, Security Engine,
etc to assign work based on queues or rings.

This patch allows user space access to X-Gene QMTM device.

Signed-off-by: Ankit Jindal 
Signed-off-by: Tushar Jagad 
---
 drivers/uio/Kconfig  |8 ++
 drivers/uio/Makefile |1 +
 drivers/uio/uio_xgene_qmtm.c |  270 ++
 3 files changed, 279 insertions(+)
 create mode 100644 drivers/uio/uio_xgene_qmtm.c

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 5a90914..76b1858 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -135,4 +135,12 @@ config UIO_MF624
 
  If you compile this as a module, it will be called uio_mf624.
 
+config UIO_XGENE_QMTM
+   tristate "Applied Micro X-Gene QMTM driver"
+   depends on OF
+   help
+ Userspace I/O interface for the X-Gene QMTM. The userspace part of
+ this driver will be available for download from the Applied Micro
+ web site (http://www.apm.com/).
+
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index d3218bd..633eaa0 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_UIO_PCI_GENERIC)   += uio_pci_generic.o
 obj-$(CONFIG_UIO_NETX) += uio_netx.o
 obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
 obj-$(CONFIG_UIO_MF624) += uio_mf624.o
+obj-$(CONFIG_UIO_XGENE_QMTM)   += uio_xgene_qmtm.o
diff --git a/drivers/uio/uio_xgene_qmtm.c b/drivers/uio/uio_xgene_qmtm.c
new file mode 100644
index 000..65467a1
--- /dev/null
+++ b/drivers/uio/uio_xgene_qmtm.c
@@ -0,0 +1,270 @@
+/*
+ * X-Gene Queue Manager Traffic Manager (QMTM) UIO driver (uio_xgene_qmtm)
+ *
+ * This driver exports QMTM CSRs, Fabric and memory for queues to user-space
+ *
+ * Copyright (C) 2014 Applied Micro - http://www.apm.com/
+ * Copyright (C) 2014 Linaro Ltd.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME "qmtm_uio"
+#define DRV_VERSION "1.0"
+
+#define QMTM_CFG_MEM_RAM_SHUTDOWN  0xd070
+
+#define QMTM_DEFAULT_QSIZE 65536
+
+struct uio_qmtm_dev {
+   struct uio_info *info;
+   struct clk *qmtm_clk;
+};
+
+/* QMTM CSR read/write routine */
+static inline void qmtm_csr_write(struct uio_qmtm_dev *qmtm_dev, u32 offset,
+   u32 data)
+{
+   void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
+
+   writel(data, addr + offset);
+}
+
+static inline u32 qmtm_csr_read(struct uio_qmtm_dev *qmtm_dev, u32 offset)
+{
+   void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
+
+   return readl(addr + offset);
+}
+
+static int qmtm_reset(struct uio_qmtm_dev *qmtm_dev)
+{
+   u32 val;
+   int wait = 1000;
+
+   /* reset the internal memory of the device */
+   qmtm_csr_write(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN, 0);
+
+   /* check whether device internal memory is out of reset or not */
+   while (wait--) {
+   val = qmtm_csr_read(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN);
+
+   if (val != 0x)
+   return 0;
+
+   udelay(1);
+   }
+
+   return -ETIMEDOUT;
+}
+
+static int qmtm_probe(struct platform_device *pdev)
+{
+   struct uio_info *info;
+   struct uio_qmtm_dev *qmtm_dev;
+   struct resource *csr;
+   struct resource *fabric;
+   struct resource qpool;
+   unsigned int num_queues;
+   unsigned int devid;
+   phandle qpool_phandle;
+   struct device_node *qpool_node;
+   int ret;
+
+   qmtm_dev = devm_kzalloc(&pdev->dev, sizeof(struct uio_qmtm_dev),
+   GFP_KERNEL);
+   if (!qmtm_dev)
+   return -ENOMEM;
+
+   qmtm_dev->info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
+   if (!qmtm_dev->info)
+   return -ENOMEM;
+
+   /* Power on qmtm in case its not done as part of boot-loader */
+   qmtm_dev->qmtm_clk = devm_clk_get(&pdev->dev, NULL);
+   if (IS_ERR(qmtm_dev->qmtm_clk)) {
+   dev_err(&pdev->dev, "Failed to get clock\n");
+   ret = PTR_ERR(qmtm_dev->qmtm_clk);
+   return ret;
+   }
+
+   csr = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!csr) {
+   ret = -EN

[PATCH v3 6/6] MAINTAINERS: Add entry for APM X-Gene QMTM UIO driver

[Ankit Jindal]

Add entry to maintainer list for APM X-Gene QMTM UIO driver.

Signed-off-by: Ankit Jindal 
Signed-off-by: Tushar Jagad 
---
 MAINTAINERS |7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5e7866a..138663f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -727,6 +727,13 @@ S: Supported
 F: drivers/net/ethernet/apm/xgene/
 F: Documentation/devicetree/bindings/net/apm-xgene-enet.txt
 
+APPLIED MICRO (APM) X-GENE QMTM UIO DRIVER
+M: Ankit Jindal 
+M: Tushar Jagad 
+S: Supported
+F: drivers/uio/uio_xgene_qmtm.c
+F: Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
+
 APTINA CAMERA SENSOR PLL
 M: Laurent Pinchart 
 L: linux-me...@vger.kernel.org
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/6] UIO driver for APM X-Gene QMTM

[Ankit Jindal]

This patchset enables user space access to APM X-Gene QMTM
using UIO framework.

The patchset also introduces new type UIO_MEM_PHYS_CACHE
for mem regions because APM X-Gene QMTM device supports
cache coherency with CPU caches.

Changes since v2:
 - Formatting cleanups.
 - Remove qmtm_cleanup().

Changes since v1:
 - Factor-out formating related change in uio/uio.c as separate patch.
 - Use devm_xxx() APIs where appilicable.
 - Some cleanups and buggy loop fixed in qmtm_reset().
 - Removed open and release functions.
 - Use phandle for specifying QMTM qpool resource.
 - Removed "uio" from the compatible string.
 - Added more information about QMTM in binding documentation.

Ankit Jindal (6):
  uio: code style cleanup
  uio: Add new UIO_MEM_PHYS_CACHE type for mem regions
  Documentation: Update documentation for UIO_MEM_PHYS_CACHE
  uio: Add X-Gene QMTM UIO driver
  Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO
driver
  MAINTAINERS: Add entry for APM X-Gene QMTM UIO driver

 Documentation/DocBook/uio-howto.tmpl   |5 +-
 .../devicetree/bindings/uio/uio_xgene_qmtm.txt |   53 
 MAINTAINERS|7 +
 drivers/uio/Kconfig|8 +
 drivers/uio/Makefile   |1 +
 drivers/uio/uio.c  |   23 +-
 drivers/uio/uio_xgene_qmtm.c   |  270 
 include/linux/uio_driver.h |1 +
 8 files changed, 357 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
 create mode 100644 drivers/uio/uio_xgene_qmtm.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/6] drivers: uio: Add X-Gene QMTM UIO driver

[Ankit Jindal]

On 30 September 2014 11:35, Varka Bhadram  wrote:
> I think *drivers* is not required in the commit message...
>
>
> On 09/30/2014 09:56 AM, Ankit Jindal wrote:
>>
>> The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
>> and Traffic manager) which is hardware based Queue or Ring
>> manager. This QMTM device can be used in conjunction with
>> other devices such as DMA Engine, Ethernet, Security Engine,
>> etc to assign work based on queues or rings.
>>
>> This patch allows user space access to X-Gene QMTM device.
>>
>> Signed-off-by: Ankit Jindal 
>> Signed-off-by: Tushar Jagad 
>> ---
>>   drivers/uio/Kconfig  |8 ++
>>   drivers/uio/Makefile |1 +
>>   drivers/uio/uio_xgene_qmtm.c |  278
>> ++
>>   3 files changed, 287 insertions(+)
>>   create mode 100644 drivers/uio/uio_xgene_qmtm.c
>>
>> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
>> index 5a90914..76b1858 100644
>> --- a/drivers/uio/Kconfig
>> +++ b/drivers/uio/Kconfig
>> @@ -135,4 +135,12 @@ config UIO_MF624
>>   If you compile this as a module, it will be called uio_mf624.
>>   +config UIO_XGENE_QMTM
>> +   tristate "Applied Micro X-Gene QMTM driver"
>> +   depends on OF
>> +   help
>> + Userspace I/O interface for the X-Gene QMTM. The userspace part
>> of
>> + this driver will be available for download from the Applied
>> Micro
>> + web site (http://www.apm.com/).
>> +
>>   endif
>> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
>> index d3218bd..633eaa0 100644
>> --- a/drivers/uio/Makefile
>> +++ b/drivers/uio/Makefile
>> @@ -8,3 +8,4 @@ obj-$(CONFIG_UIO_PCI_GENERIC)   += uio_pci_generic.o
>>   obj-$(CONFIG_UIO_NETX)+= uio_netx.o
>>   obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
>>   obj-$(CONFIG_UIO_MF624) += uio_mf624.o
>> +obj-$(CONFIG_UIO_XGENE_QMTM)   += uio_xgene_qmtm.o
>> diff --git a/drivers/uio/uio_xgene_qmtm.c b/drivers/uio/uio_xgene_qmtm.c
>> new file mode 100644
>> index 000..36d9000
>> --- /dev/null
>> +++ b/drivers/uio/uio_xgene_qmtm.c
>> @@ -0,0 +1,278 @@
>> +/*
>> + * X-Gene Queue Manager Traffic Manager (QMTM) UIO driver
>> (uio_xgene_qmtm)
>> + *
>> + * This driver exports QMTM CSRs, Fabric and memory for queues to
>> user-space
>> + *
>> + * Copyright (C) 2014 Applied Micro - http://www.apm.com/
>> + * Copyright (C) 2014 Linaro Ltd.
>> + *
>> + * 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.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>
>
> Headers in alphabetical order...?
>
> #include 
> #include 
>
> ...
>
>
>> +#define DRV_NAME "qmtm_uio"
>> +#define DRV_VERSION "1.0"
>> +
>> +#define QMTM_CFG_MEM_RAM_SHUTDOWN  0xd070
>> +
>> +#define QMTM_DEFAULT_QSIZE 65536
>> +
>> +struct uio_qmtm_dev {
>> +   struct uio_info *info;
>> +   struct clk *qmtm_clk;
>> +};
>> +
>> +/* QMTM CSR read/write routine */
>> +static inline void qmtm_csr_write(struct uio_qmtm_dev *qmtm_dev, u32
>> offset,
>> +   u32 data)
>> +{
>> +   void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
>> +
>> +   writel(data, addr + offset);
>> +}
>> +
>> +static inline u32 qmtm_csr_read(struct uio_qmtm_dev *qmtm_dev, u32
>> offset)
>> +{
>> +   void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
>> +
>> +   return readl(addr + offset);
>> +}
>> +
>> +static int qmtm_reset(struct uio_qmtm_dev *qmtm_dev)
>> +{
>> +   u32 val;
>> +   int wait = 1000;
>> +
>> +   /* reset the internal memory of the device */
>> +   qmtm_csr_write(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN, 0);
>> +
>> +   /* check whether device internal memory is out of reset or not */
>> +   while (1) {
>> +   val = qmtm_csr_read(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN);
>> +
>> +   if (val != 0x)
>> +   return 0;
>> +
>> +   if (!wait--)
>> +   return -EBUSY;
>> +
>> +   udelay(1);
>> +   }
>> +}
>> +
>> +static void qmtm_cleanup(struct platform_device *pdev,
>> +   struct uio_qmtm_dev *qmtm_dev)
>> +{
>> +   struct uio_info *info = qmtm_dev->info;
>> +
>> +   uio_unregister_device(info);
>> +
>> +   clk_disable_unprepare(qmtm_dev->qmtm_clk);
>> +}
>> +
>> +static int qmtm_probe(struct platform_device *pdev)
>> +{
>> +   struct uio_info *info;
>> +   struct uio_qmtm_dev *qmtm_dev;
>> +   s

Re: [PATCH V2 4/9] Documentation: DT: Add entries for bcm63xx UART

[Arnd Bergmann]

On Monday 20 October 2014 15:53:53 Florian Fainelli wrote:
> 
> For now, I suppose that s simple fix could be to use an anonymous clock
> request when probed via DT. This code you quote dates from 2008 when
> there was no clkdev in the kernel at all. So something like this would
> probably do it for now:
> 
> diff --git a/drivers/tty/serial/bcm63xx_uart.c
> b/drivers/tty/serial/bcm63xx_uart.c
> index e0b87d507670..1b914b85dd31 100644
> --- a/drivers/tty/serial/bcm63xx_uart.c
> +++ b/drivers/tty/serial/bcm63xx_uart.c
> @@ -819,7 +819,7 @@ static int bcm_uart_probe(struct platform_device *pdev)
> if (!res_irq)
> return -ENODEV;
> 
> -   clk = clk_get(&pdev->dev, "periph");
> +   clk = clk_get(&pdev->dev, pdev->dev.of_node ? NULL : "periph");
> if (IS_ERR(clk))
> return -ENODEV;
> 
> 

Yes, that would work. Just make sure the same bug doesn't creep in
for other drivers you are converting.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] ARM: DT: apq8064: Add Support for SD Card Detect for ifc6410 board

[Pramod Gurav]

This changes muxes in gpio26 pin to function as gpio and adds support
for sd card detect for apq8064 based IFC6410 board.

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Russell King 
Cc: Srinivas Kandagatla 

Signed-off-by: Pramod Gurav 
---

Changes since v2:
 - Replaced hardcode value with GPIO_ACTIVE_LOW

 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |   12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index b396c83..e641001 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -1,4 +1,5 @@
 #include "qcom-apq8064-v2.0.dtsi"
+#include 
 
 / {
model = "Qualcomm APQ8064/IFC6410";
@@ -12,6 +13,14 @@
function = "gsbi1";
};
};
+
+   card_detect: card_detect {
+   mux {
+   pins = "gpio26";
+   function = "gpio";
+   bias-disable;
+   };
+   };
};
 
gsbi@1244 {
@@ -49,6 +58,9 @@
/* External micro SD card */
sdcc3: sdcc@1218 {
status = "okay";
+   pinctrl-names   = "default";
+   pinctrl-0   = <&card_detect>;
+   cd-gpios= <&tlmm_pinmux 26 
GPIO_ACTIVE_LOW>;
};
/* WLAN */
sdcc4: sdcc@121c {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/6] ARM: cygnus: Initial support for Broadcom Cygnus SoC

[Arnd Bergmann]

On Monday 20 October 2014 15:59:45 Scott Branden wrote:
> On 14-10-20 12:55 PM, Arnd Bergmann wrote:
> > On Tuesday 14 October 2014 19:58:51 Scott Branden wrote:
> >>   if ARCH_BCM
> >>
> >> +menu "iProc SoC based Machine types"
> >> +   config ARCH_BCM_IPROC
> >> +   bool
> >> +   select ARM_GIC
> >> +   select CACHE_L2X0
> >> +   select HAVE_ARM_SCU if SMP
> >> +   select HAVE_ARM_TWD if SMP
> >> +   select ARM_GLOBAL_TIMER
> >> +
> >> +   select CLKSRC_MMIO
> >> +   select ARCH_REQUIRE_GPIOLIB
> >> +   select ARM_AMBA
> >> +   select PINCTRL
> >> +   help
> >> + This enables support for systems based on Broadcom IPROC 
> >> architected SoCs.
> >> + The IPROC complex contains one or more ARM CPUs along 
> >> with common
> >> + core periperals. Application specific SoCs are created 
> >> by adding a
> >> + uArchitecture containing peripherals outside of the 
> >> IPROC complex.
> >> + Currently supported SoCs are Cygnus.
> >> +
> >> +   config ARCH_BCM_CYGNUS
> >> +   bool "Broadcom Cygnus Support" if ARCH_MULTI_V7
> >
> > You still have a three-level menu structure. Please fix.
> 
> Hi Arnd, we have ARCH_BCM->ARCH_BCM_CYGNUS.
> 
> ARCH_BCM_IPROC is silent and selected by ARCH_BCM_CYGNUS.  This was the 
> change made between v3 and v5.
> 
> Is there something else to be done here?
> 

You have

"Broadcom SoC Support" 
"iProc SoC based Machine types"
 "Broadcom Cygnus Support"

Get rid of one of them.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 7/7] arm64: exynos: Enable rtc and watchdog support for Exynos7

[Abhilash Kesavan]

Enable rtc and watchdog support for exynos7 SoCs.

Signed-off-by: Abhilash Kesavan 
---
 arch/arm64/Kconfig |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 238acff..9bb4e02 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -158,6 +158,9 @@ config ARCH_EXYNOS7
select COMMON_CLK_SAMSUNG
select PINCTRL
select PINCTRL_EXYNOS
+   select HAVE_S3C2410_WATCHDOG if WATCHDOG
+   select HAVE_S3C_RTC if RTC_CLASS
+
help
  This enables support for Samsung Exynos7 SoC family
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/7] arm64: dts: Add PMU DT node for exynos7 SoC

[Abhilash Kesavan]

Adds PMU DT node for exynos7 SoC.

Signed-off-by: Abhilash Kesavan 
---
 .../devicetree/bindings/arm/samsung/pmu.txt|1 +
 arch/arm64/boot/dts/exynos/exynos7.dtsi|5 +
 2 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt 
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index 1e1979b..67b2113 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -10,6 +10,7 @@ Properties:
   - "samsung,exynos5260-pmu" - for Exynos5260 SoC.
   - "samsung,exynos5410-pmu" - for Exynos5410 SoC,
   - "samsung,exynos5420-pmu" - for Exynos5420 SoC.
+  - "samsung,exynos7-pmu" - for Exynos7 SoC.
second value must be always "syscon".
 
  - reg : offset and length of the register set.
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index ce221ac..6db8c78 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -243,6 +243,11 @@
 <1 11 0xff01>,
 <1 10 0xff01>;
};
+
+   pmu_system_controller: system-controller@105c {
+   compatible = "samsung,exynos7-pmu", "syscon";
+   reg = <0x105c 0x5000>;
+   };
};
 };
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 6/7] arm64: dts: Add nodes for mmc, i2c, rtc, watchdog on Exynos7

[Abhilash Kesavan]

Add nodes for 3 mmc channels, 12 i2c channels, rtc, and watchdog
on Exynos7.

Signed-off-by: Naveen Krishna Ch 
Signed-off-by: Abhilash Kesavan 
---
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts |   41 
 arch/arm64/boot/dts/exynos/exynos7.dtsi |  256 +++
 2 files changed, 297 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts 
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index e2c8283..d081c26 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -18,6 +18,8 @@
 
aliases {
serial0 = &serial_2;
+   mshc0 = &mmc_0;
+   mshc2 = &mmc_2;
};
 
chosen {
@@ -37,3 +39,42 @@
 &serial_2 {
status = "okay";
 };
+
+&rtc {
+   status = "okay";
+};
+
+&watchdog {
+   status = "okay";
+};
+
+&mmc_0 {
+   status = "okay";
+   num-slots = <1>;
+   broken-cd;
+   caps2-mmc-hs200-1_8v;
+   supports-highspeed;
+   non-removable;
+   card-detect-delay = <200>;
+   clock-frequency = <8>;
+   samsung,dw-mshc-ciu-div = <3>;
+   samsung,dw-mshc-sdr-timing = <0 4>;
+   samsung,dw-mshc-ddr-timing = <0 2>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_qrdy &sd0_bus1 &sd0_bus4 &sd0_bus8>;
+   bus-width = <8>;
+};
+
+&mmc_2 {
+   status = "okay";
+   num-slots = <1>;
+   supports-highspeed;
+   card-detect-delay = <200>;
+   clock-frequency = <4>;
+   samsung,dw-mshc-ciu-div = <3>;
+   samsung,dw-mshc-sdr-timing = <2 3>;
+   samsung,dw-mshc-ddr-timing = <1 2>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
+   bus-width = <4>;
+};
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 6db8c78..1300ded 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -113,6 +113,27 @@
  "dout_sclk_mfc_pll";
};
 
+   clock_top1: clock-controller@105e {
+   compatible = "samsung,exynos7-clock-top1";
+   reg = <0x105e 0xb000>;
+   #clock-cells = <1>;
+   clocks = <&fin_pll>, <&clock_topc DOUT_SCLK_BUS0_PLL>,
+<&clock_topc DOUT_SCLK_BUS1_PLL>,
+<&clock_topc DOUT_SCLK_CC_PLL>,
+<&clock_topc DOUT_SCLK_MFC_PLL>;
+   clock-names = "fin_pll", "dout_sclk_bus0_pll",
+ "dout_sclk_bus1_pll", "dout_sclk_cc_pll",
+ "dout_sclk_mfc_pll";
+   };
+
+   clock_ccore: clock-controller@105b {
+   compatible = "samsung,exynos7-clock-ccore";
+   reg = <0x105b 0xd00>;
+   #clock-cells = <1>;
+   clocks = <&fin_pll>, <&clock_topc DOUT_ACLK_CCORE_133>;
+   clock-names = "fin_pll", "dout_aclk_ccore_133";
+   };
+
clock_peric0: clock-controller@1361 {
compatible = "samsung,exynos7-clock-peric0";
reg = <0x1361 0xd00>;
@@ -143,6 +164,27 @@
clock-names = "fin_pll", "dout_aclk_peris_66";
};
 
+   clock_fsys0: clock-controller@10e9 {
+   compatible = "samsung,exynos7-clock-fsys0";
+   reg = <0x10e9 0xd00>;
+   #clock-cells = <1>;
+   clocks = <&fin_pll>, <&clock_top1 DOUT_ACLK_FSYS0_200>,
+<&clock_top1 DOUT_SCLK_MMC2>;
+   clock-names = "fin_pll", "dout_aclk_fsys0_200",
+ "dout_sclk_mmc2";
+   };
+
+   clock_fsys1: clock-controller@156e {
+   compatible = "samsung,exynos7-clock-fsys1";
+   reg = <0x156e 0xd00>;
+   #clock-cells = <1>;
+   clocks = <&fin_pll>, <&clock_top1 DOUT_ACLK_FSYS1_200>,
+<&clock_top1 DOUT_SCLK_MMC0>,
+<&clock_top1 DOUT_SCLK_MMC1>;
+   clock-names = "fin_pll", "dout_aclk_fsys1_200",
+ "dout_sclk_mmc0", "dout_sclk_mmc1";
+   };
+
serial_0: serial@1363 {
compatible = "samsung,exynos4210-uart";
reg = <0x1363 0x100>;
@@ -236,6 +278,162 @@
interrupts = <0 203 0>;
};
 
+   hsi2c_0: hsi2c@1364 {
+   compatible = "samsung,exynos7-hs

[PATCH v2 4/7] clk: samsung: exynos7: add gate clocks for WDT, TMU and PWM blocks

[Abhilash Kesavan]

From: Naveen Krishna Ch 

Add clock support for the watchdog timer, pwm timer and thermal
management unit IPs in Exynos7.

Signed-off-by: Naveen Krishna Ch 
Signed-off-by: Abhilash Kesavan 
---
 drivers/clk/samsung/clk-exynos7.c   |   14 ++
 include/dt-bindings/clock/exynos7-clk.h |9 +++--
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos7.c 
b/drivers/clk/samsung/clk-exynos7.c
index 3a30f43..17e5cf4 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -486,9 +486,12 @@ static struct samsung_gate_clock peric0_gate_clks[] 
__initdata = {
ENABLE_PCLK_PERIC0, 14, 0, 0),
GATE(PCLK_UART0, "pclk_uart0", "mout_aclk_peric0_66_user",
ENABLE_PCLK_PERIC0, 16, 0, 0),
+   GATE(PCLK_PWM, "pclk_pwm", "mout_aclk_peric0_66_user",
+   ENABLE_PCLK_PERIC0, 21, 0, 0),
 
GATE(SCLK_UART0, "sclk_uart0_user", "mout_sclk_uart0_user",
ENABLE_SCLK_PERIC0, 16, 0, 0),
+   GATE(SCLK_PWM, "sclk_pwm", "fin_pll", ENABLE_SCLK_PERIC0, 21, 0, 0),
 };
 
 static struct samsung_cmu_info peric0_cmu_info __initdata = {
@@ -586,7 +589,9 @@ CLK_OF_DECLARE(exynos7_clk_peric1, 
"samsung,exynos7-clock-peric1",
 
 /* Register Offset definitions for CMU_PERIS (0x1004) */
 #define MUX_SEL_PERIS  0x0200
+#define ENABLE_PCLK_PERIS  0x0900
 #define ENABLE_PCLK_PERIS_SECURE_CHIPID0x0910
+#define ENABLE_SCLK_PERIS  0x0A00
 #define ENABLE_SCLK_PERIS_SECURE_CHIPID0x0A10
 
 /* List of parent clocks for Muxes in CMU_PERIS */
@@ -594,7 +599,9 @@ PNAME(mout_aclk_peris_66_p) = { "fin_pll", 
"dout_aclk_peris_66" };
 
 static unsigned long peris_clk_regs[] __initdata = {
MUX_SEL_PERIS,
+   ENABLE_PCLK_PERIS,
ENABLE_PCLK_PERIS_SECURE_CHIPID,
+   ENABLE_SCLK_PERIS,
ENABLE_SCLK_PERIS_SECURE_CHIPID,
 };
 
@@ -604,10 +611,17 @@ static struct samsung_mux_clock peris_mux_clks[] 
__initdata = {
 };
 
 static struct samsung_gate_clock peris_gate_clks[] __initdata = {
+   GATE(PCLK_WDT, "pclk_wdt", "mout_aclk_peris_66_user",
+   ENABLE_PCLK_PERIS, 6, 0, 0),
+   GATE(PCLK_TMU, "pclk_tmu_apbif", "mout_aclk_peris_66_user",
+   ENABLE_PCLK_PERIS, 10, 0, 0),
+
GATE(PCLK_CHIPID, "pclk_chipid", "mout_aclk_peris_66_user",
ENABLE_PCLK_PERIS_SECURE_CHIPID, 0, 0, 0),
GATE(SCLK_CHIPID, "sclk_chipid", "fin_pll",
ENABLE_SCLK_PERIS_SECURE_CHIPID, 0, 0, 0),
+
+   GATE(SCLK_TMU, "sclk_tmu", "fin_pll", ENABLE_SCLK_PERIS, 10, 0, 0),
 };
 
 static struct samsung_cmu_info peris_cmu_info __initdata = {
diff --git a/include/dt-bindings/clock/exynos7-clk.h 
b/include/dt-bindings/clock/exynos7-clk.h
index 3227679..28c8aa7 100644
--- a/include/dt-bindings/clock/exynos7-clk.h
+++ b/include/dt-bindings/clock/exynos7-clk.h
@@ -53,7 +53,9 @@
 #define PCLK_HSI2C97
 #define PCLK_HSI2C10   8
 #define PCLK_HSI2C11   9
-#define PERIC0_NR_CLK  10
+#define PCLK_PWM   10
+#define SCLK_PWM   11
+#define PERIC0_NR_CLK  12
 
 /* PERIC1 */
 #define PCLK_UART1 1
@@ -72,7 +74,10 @@
 /* PERIS */
 #define PCLK_CHIPID1
 #define SCLK_CHIPID2
-#define PERIS_NR_CLK   3
+#define PCLK_WDT   3
+#define PCLK_TMU   4
+#define SCLK_TMU   5
+#define PERIS_NR_CLK   6
 
 /* FSYS0 */
 #define ACLK_MMC2  1
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/7] clk: samsung: exynos7: add clocks for RTC block

[Abhilash Kesavan]

From: Naveen Krishna Ch 

Add clock support for the RTC block in Exynos7.

Signed-off-by: Naveen Krishna Ch 
Signed-off-by: Abhilash Kesavan 
---
 .../devicetree/bindings/clock/exynos7-clock.txt|5 ++
 drivers/clk/samsung/clk-exynos7.c  |   54 
 include/dt-bindings/clock/exynos7-clk.h|   17 +++---
 3 files changed, 70 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos7-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos7-clock.txt
index b29cb50..6d3d5f8 100644
--- a/Documentation/devicetree/bindings/clock/exynos7-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos7-clock.txt
@@ -28,6 +28,7 @@ Required Properties for Clock Controller:
- "samsung,exynos7-clock-topc"
- "samsung,exynos7-clock-top0"
- "samsung,exynos7-clock-top1"
+   - "samsung,exynos7-clock-ccore"
- "samsung,exynos7-clock-peric0"
- "samsung,exynos7-clock-peric1"
- "samsung,exynos7-clock-peris"
@@ -60,6 +61,10 @@ Input clocks for top1 clock controller:
- dout_sclk_cc_pll
- dout_sclk_mfc_pll
 
+Input clocks for ccore clock controller:
+   - fin_pll
+   - dout_aclk_ccore_133
+
 Input clocks for peric0 clock controller:
- fin_pll
- dout_aclk_peric0_66
diff --git a/drivers/clk/samsung/clk-exynos7.c 
b/drivers/clk/samsung/clk-exynos7.c
index f5e43fa..3a30f43 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -29,7 +29,9 @@
 #define AUD_PLL_CON0   0x0140
 #define MUX_SEL_TOPC0  0x0200
 #define MUX_SEL_TOPC1  0x0204
+#define MUX_SEL_TOPC2  0x0208
 #define MUX_SEL_TOPC3  0x020C
+#define DIV_TOPC0  0x0600
 #define DIV_TOPC1  0x0604
 #define DIV_TOPC3  0x060C
 
@@ -78,7 +80,9 @@ static unsigned long topc_clk_regs[] __initdata = {
AUD_PLL_CON0,
MUX_SEL_TOPC0,
MUX_SEL_TOPC1,
+   MUX_SEL_TOPC2,
MUX_SEL_TOPC3,
+   DIV_TOPC0,
DIV_TOPC1,
DIV_TOPC3,
 };
@@ -101,10 +105,15 @@ static struct samsung_mux_clock topc_mux_clks[] 
__initdata = {
MUX(0, "mout_sclk_bus0_pll_out", mout_sclk_bus0_pll_out_p,
MUX_SEL_TOPC1, 16, 1),
 
+   MUX(0, "mout_aclk_ccore_133", mout_topc_group2, MUX_SEL_TOPC2, 4, 2),
+
MUX(0, "mout_aclk_peris_66", mout_topc_group2, MUX_SEL_TOPC3, 24, 2),
 };
 
 static struct samsung_div_clock topc_div_clks[] __initdata = {
+   DIV(DOUT_ACLK_CCORE_133, "dout_aclk_ccore_133", "mout_aclk_ccore_133",
+   DIV_TOPC0, 4, 4),
+
DIV(DOUT_ACLK_PERIS, "dout_aclk_peris_66", "mout_aclk_peris_66",
DIV_TOPC1, 24, 4),
 
@@ -393,6 +402,51 @@ static void __init exynos7_clk_top1_init(struct 
device_node *np)
 CLK_OF_DECLARE(exynos7_clk_top1, "samsung,exynos7-clock-top1",
exynos7_clk_top1_init);
 
+/* Register Offset definitions for CMU_CCORE (0x105B) */
+#define MUX_SEL_CCORE  0x0200
+#define DIV_CCORE  0x0600
+#define ENABLE_ACLK_CCORE0 0x0800
+#define ENABLE_ACLK_CCORE1 0x0804
+#define ENABLE_PCLK_CCORE  0x0900
+
+/*
+ * List of parent clocks for Muxes in CMU_CCORE
+ */
+PNAME(mout_aclk_ccore_133_p)   = { "fin_pll", "dout_aclk_ccore_133" };
+
+static unsigned long ccore_clk_regs[] __initdata = {
+   MUX_SEL_CCORE,
+   ENABLE_PCLK_CCORE,
+};
+
+static struct samsung_mux_clock ccore_mux_clks[] __initdata = {
+   MUX(0, "mout_aclk_ccore_133_user", mout_aclk_ccore_133_p,
+   MUX_SEL_CCORE, 1, 1),
+};
+
+static struct samsung_gate_clock ccore_gate_clks[] __initdata = {
+   GATE(PCLK_RTC, "pclk_rtc", "mout_aclk_ccore_133_user",
+   ENABLE_PCLK_CCORE, 8, 0, 0),
+};
+
+static struct samsung_cmu_info ccore_cmu_info __initdata = {
+   .mux_clks   = ccore_mux_clks,
+   .nr_mux_clks= ARRAY_SIZE(ccore_mux_clks),
+   .gate_clks  = ccore_gate_clks,
+   .nr_gate_clks   = ARRAY_SIZE(ccore_gate_clks),
+   .nr_clk_ids = CCORE_NR_CLK,
+   .clk_regs   = ccore_clk_regs,
+   .nr_clk_regs= ARRAY_SIZE(ccore_clk_regs),
+};
+
+static void __init exynos7_clk_ccore_init(struct device_node *np)
+{
+   samsung_cmu_register_one(np, &ccore_cmu_info);
+}
+
+CLK_OF_DECLARE(exynos7_clk_ccore, "samsung,exynos7-clock-ccore",
+   exynos7_clk_ccore_init);
+
 /* Register Offset definitions for CMU_PERIC0 (0x1361) */
 #define MUX_SEL_PERIC0 0x0200
 #define ENABLE_PCLK_PERIC0 0x0900
diff --git a/include/dt-bindings/clock/exynos7-clk.h 
b/include/dt-bindings/clock/exynos7-clk.h
index ff63c4e..3227679 100644
--- a/include/dt-bindings/clock/exynos7-clk.h
+++ b/include/dt-bindings/clock/exynos7-clk.h
@@ -11,12 +11,13 @@
 #define _DT_BINDINGS_CLOCK_EXYNOS7_H
 
 /* TOPC */
-#define DOUT_ACLK_PERIS 

[PATCH v2 2/7] clk: samsung: exynos7: add clocks for MMC block

[Abhilash Kesavan]

From: Naveen Krishna Ch 

Exynos7 supports 3 MMC channels, add the MMC gate clocks to
support them.

Signed-off-by: Naveen Krishna Ch 
Signed-off-by: Abhilash Kesavan 
---
 .../devicetree/bindings/clock/exynos7-clock.txt|   21 ++
 drivers/clk/samsung/clk-exynos7.c  |  224 
 include/dt-bindings/clock/exynos7-clk.h|   20 ++
 3 files changed, 265 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/exynos7-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos7-clock.txt
index 789f761..b29cb50 100644
--- a/Documentation/devicetree/bindings/clock/exynos7-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos7-clock.txt
@@ -27,9 +27,12 @@ Required Properties for Clock Controller:
 
- "samsung,exynos7-clock-topc"
- "samsung,exynos7-clock-top0"
+   - "samsung,exynos7-clock-top1"
- "samsung,exynos7-clock-peric0"
- "samsung,exynos7-clock-peric1"
- "samsung,exynos7-clock-peris"
+   - "samsung,exynos7-clock-fsys0"
+   - "samsung,exynos7-clock-fsys1"
 
  - reg: physical base address of the controller and the length of
memory mapped region.
@@ -50,6 +53,13 @@ Input clocks for top0 clock controller:
- dout_sclk_cc_pll
- dout_sclk_mfc_pll
 
+Input clocks for top1 clock controller:
+   - fin_pll
+   - dout_sclk_bus0_pll
+   - dout_sclk_bus1_pll
+   - dout_sclk_cc_pll
+   - dout_sclk_mfc_pll
+
 Input clocks for peric0 clock controller:
- fin_pll
- dout_aclk_peric0_66
@@ -65,3 +75,14 @@ Input clocks for peric1 clock controller:
 Input clocks for peris clock controller:
- fin_pll
- dout_aclk_peris_66
+
+Input clocks for fsys0 clock controller:
+   - fin_pll
+   - dout_aclk_fsys0_200
+   - dout_sclk_mmc2
+
+Input clocks for fsys1 clock controller:
+   - fin_pll
+   - dout_aclk_fsys1_200
+   - dout_sclk_mmc0
+   - dout_sclk_mmc1
diff --git a/drivers/clk/samsung/clk-exynos7.c 
b/drivers/clk/samsung/clk-exynos7.c
index c700f65..f5e43fa 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -267,6 +267,132 @@ static void __init exynos7_clk_top0_init(struct 
device_node *np)
 CLK_OF_DECLARE(exynos7_clk_top0, "samsung,exynos7-clock-top0",
exynos7_clk_top0_init);
 
+/* Register Offset definitions for CMU_TOP1 (0x105E) */
+#define MUX_SEL_TOP10  0x0200
+#define MUX_SEL_TOP11  0x0204
+#define MUX_SEL_TOP13  0x020C
+#define MUX_SEL_TOP1_FSYS0 0x0224
+#define MUX_SEL_TOP1_FSYS1 0x0228
+#define DIV_TOP13  0x060C
+#define DIV_TOP1_FSYS0 0x0624
+#define DIV_TOP1_FSYS1 0x0628
+#define ENABLE_ACLK_TOP13  0x080C
+#define ENABLE_SCLK_TOP1_FSYS0 0x0A24
+#define ENABLE_SCLK_TOP1_FSYS1 0x0A28
+
+/* List of parent clocks for Muxes in CMU_TOP1 */
+PNAME(mout_top1_bus0_pll_p)= { "fin_pll", "dout_sclk_bus0_pll" };
+PNAME(mout_top1_bus1_pll_p)= { "fin_pll", "dout_sclk_bus1_pll_b" };
+PNAME(mout_top1_cc_pll_p)  = { "fin_pll", "dout_sclk_cc_pll_b" };
+PNAME(mout_top1_mfc_pll_p) = { "fin_pll", "dout_sclk_mfc_pll_b" };
+
+PNAME(mout_top1_half_bus0_pll_p) = {"mout_top1_bus0_pll",
+   "ffac_top1_bus0_pll_div2"};
+PNAME(mout_top1_half_bus1_pll_p) = {"mout_top1_bus1_pll",
+   "ffac_top1_bus1_pll_div2"};
+PNAME(mout_top1_half_cc_pll_p) = {"mout_top1_cc_pll",
+   "ffac_top1_cc_pll_div2"};
+PNAME(mout_top1_half_mfc_pll_p) = {"mout_top1_mfc_pll",
+   "ffac_top1_mfc_pll_div2"};
+
+PNAME(mout_top1_group1) = {"mout_top1_half_bus0_pll",
+   "mout_top1_half_bus1_pll", "mout_top1_half_cc_pll",
+   "mout_top1_half_mfc_pll"};
+
+static unsigned long top1_clk_regs[] __initdata = {
+   MUX_SEL_TOP10,
+   MUX_SEL_TOP11,
+   MUX_SEL_TOP13,
+   MUX_SEL_TOP1_FSYS0,
+   MUX_SEL_TOP1_FSYS1,
+   DIV_TOP13,
+   DIV_TOP1_FSYS0,
+   DIV_TOP1_FSYS1,
+   ENABLE_ACLK_TOP13,
+   ENABLE_SCLK_TOP1_FSYS0,
+   ENABLE_SCLK_TOP1_FSYS1,
+};
+
+static struct samsung_mux_clock top1_mux_clks[] __initdata = {
+   MUX(0, "mout_top1_mfc_pll", mout_top1_mfc_pll_p, MUX_SEL_TOP10, 4, 1),
+   MUX(0, "mout_top1_cc_pll", mout_top1_cc_pll_p, MUX_SEL_TOP10, 8, 1),
+   MUX(0, "mout_top1_bus1_pll", mout_top1_bus1_pll_p,
+   MUX_SEL_TOP10, 12, 1),
+   MUX(0, "mout_top1_bus0_pll", mout_top1_bus0_pll_p,
+   MUX_SEL_TOP10, 16, 1),
+
+   MUX(0, "mout_top1_half_mfc_pll", mout_top1_half_mfc_pll_p,
+   MUX_SEL_TOP11, 4, 1),
+   MUX(0, "mout_top1_half_cc_pll", mout_top1_half_cc_pll_p,
+   MUX_SEL_TOP11, 8, 1),
+   MUX(0, "mout_top1_half_bus1_pll", mout_top1_half_bus1_pll_p,
+   MUX_SEL_TOP11, 12, 1),
+   MUX(0, "mout_top1_half_bus0_pll", mout_top1_half_bus0_pll_p,
+   MUX_SEL_TOP11, 16, 1),
+
+   MUX(0,

[PATCH v2 1/7] clk: samsung: exynos7: add clocks for I2C block

[Abhilash Kesavan]

From: Naveen Krishna Ch 

Exynos7 supports 12 I2C channels, add the I2C gate clocks to
support them.

Signed-off-by: Naveen Krishna Ch 
Signed-off-by: Abhilash Kesavan 
---
 drivers/clk/samsung/clk-exynos7.c   |   24 
 include/dt-bindings/clock/exynos7-clk.h |   16 ++--
 2 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos7.c 
b/drivers/clk/samsung/clk-exynos7.c
index 54206d4..c700f65 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -290,6 +290,20 @@ static struct samsung_mux_clock peric0_mux_clks[] 
__initdata = {
 };
 
 static struct samsung_gate_clock peric0_gate_clks[] __initdata = {
+   GATE(PCLK_HSI2C0, "pclk_hsi2c0", "mout_aclk_peric0_66_user",
+   ENABLE_PCLK_PERIC0, 8, 0, 0),
+   GATE(PCLK_HSI2C1, "pclk_hsi2c1", "mout_aclk_peric0_66_user",
+   ENABLE_PCLK_PERIC0, 9, 0, 0),
+   GATE(PCLK_HSI2C4, "pclk_hsi2c4", "mout_aclk_peric0_66_user",
+   ENABLE_PCLK_PERIC0, 10, 0, 0),
+   GATE(PCLK_HSI2C5, "pclk_hsi2c5", "mout_aclk_peric0_66_user",
+   ENABLE_PCLK_PERIC0, 11, 0, 0),
+   GATE(PCLK_HSI2C9, "pclk_hsi2c9", "mout_aclk_peric0_66_user",
+   ENABLE_PCLK_PERIC0, 12, 0, 0),
+   GATE(PCLK_HSI2C10, "pclk_hsi2c10", "mout_aclk_peric0_66_user",
+   ENABLE_PCLK_PERIC0, 13, 0, 0),
+   GATE(PCLK_HSI2C11, "pclk_hsi2c11", "mout_aclk_peric0_66_user",
+   ENABLE_PCLK_PERIC0, 14, 0, 0),
GATE(PCLK_UART0, "pclk_uart0", "mout_aclk_peric0_66_user",
ENABLE_PCLK_PERIC0, 16, 0, 0),
 
@@ -347,6 +361,16 @@ static struct samsung_mux_clock peric1_mux_clks[] 
__initdata = {
 };
 
 static struct samsung_gate_clock peric1_gate_clks[] __initdata = {
+   GATE(PCLK_HSI2C2, "pclk_hsi2c2", "mout_aclk_peric1_66_user",
+   ENABLE_PCLK_PERIC1, 4, 0, 0),
+   GATE(PCLK_HSI2C3, "pclk_hsi2c3", "mout_aclk_peric1_66_user",
+   ENABLE_PCLK_PERIC1, 5, 0, 0),
+   GATE(PCLK_HSI2C6, "pclk_hsi2c6", "mout_aclk_peric1_66_user",
+   ENABLE_PCLK_PERIC1, 6, 0, 0),
+   GATE(PCLK_HSI2C7, "pclk_hsi2c7", "mout_aclk_peric1_66_user",
+   ENABLE_PCLK_PERIC1, 7, 0, 0),
+   GATE(PCLK_HSI2C8, "pclk_hsi2c8", "mout_aclk_peric1_66_user",
+   ENABLE_PCLK_PERIC1, 8, 0, 0),
GATE(PCLK_UART1, "pclk_uart1", "mout_aclk_peric1_66_user",
ENABLE_PCLK_PERIC1, 9, 0, 0),
GATE(PCLK_UART2, "pclk_uart2", "mout_aclk_peric1_66_user",
diff --git a/include/dt-bindings/clock/exynos7-clk.h 
b/include/dt-bindings/clock/exynos7-clk.h
index 00fd6de..6d07b6f 100644
--- a/include/dt-bindings/clock/exynos7-clk.h
+++ b/include/dt-bindings/clock/exynos7-clk.h
@@ -30,7 +30,14 @@
 /* PERIC0 */
 #define PCLK_UART0 1
 #define SCLK_UART0 2
-#define PERIC0_NR_CLK  3
+#define PCLK_HSI2C03
+#define PCLK_HSI2C14
+#define PCLK_HSI2C45
+#define PCLK_HSI2C56
+#define PCLK_HSI2C97
+#define PCLK_HSI2C10   8
+#define PCLK_HSI2C11   9
+#define PERIC0_NR_CLK  10
 
 /* PERIC1 */
 #define PCLK_UART1 1
@@ -39,7 +46,12 @@
 #define SCLK_UART1 4
 #define SCLK_UART2 5
 #define SCLK_UART3 6
-#define PERIC1_NR_CLK  7
+#define PCLK_HSI2C27
+#define PCLK_HSI2C38
+#define PCLK_HSI2C69
+#define PCLK_HSI2C710
+#define PCLK_HSI2C811
+#define PERIC1_NR_CLK  12
 
 /* PERIS */
 #define PCLK_CHIPID1
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/7] Add clock and DT support for a few IPs on Exynos7

[Abhilash Kesavan]

Changes since v1:
- Added documentation for input clocks of the newly added CMUs

Following are the dependencies:
1) dts, kbuild: Implement support for dtb vendor subdirs patchset 
http://comments.gmane.org/gmane.linux.kbuild.devel/12131
2) arch: arm64: Enable support for Samsung Exynos7 SoC
http://www.spinics.net/lists/linux-samsung-soc/msg37047.html
3) Serial clean-up patches for Exynos7
http://www.spinics.net/lists/arm-kernel/msg367348.html
http://www.spinics.net/lists/arm-kernel/msg367349.html
4) Add initial support for pinctrl on Exynos7
http://www.spinics.net/lists/linux-samsung-soc/msg37708.html

For testing I have applied the following:
1) mmc: dw_mmc: Add IDMAC 64-bit address mode support
http://www.spinics.net/lists/kernel/msg1842300.html
2) mmc: dw_mmc: Reset DMA before enabling IDMAC
http://www.gossamer-threads.com/lists/linux/kernel/2021576?page=last
3) drivers: rtc: fix s3c-rtc initialization failure without rtc source clock
https://lkml.org/lkml/2014/10/15/210
4) mfd: sec: add S2MPS15 PMIC support
https://lkml.org/lkml/2014/10/14/50
5) regulator: s2mps11: add support for S2MPS15 regulators
https://lkml.org/lkml/2014/10/14/52
6) Regulators dt nodes were added in the espresso dts file and I2C channel 4
which has the PMIC on it was tested.
7) watchdog: s3c2410_wdt: Fix the mask bit offset for Exynos7
http://www.spinics.net/lists/linux-watchdog/msg05292.html

Abhilash Kesavan (3):
  arm64: dts: Add PMU DT node for exynos7 SoC
  arm64: dts: Add nodes for mmc, i2c, rtc, watchdog on Exynos7
  arm64: exynos: Enable rtc and watchdog support for Exynos7

Naveen Krishna Ch (4):
  clk: samsung: exynos7: add clocks for I2C block
  clk: samsung: exynos7: add clocks for MMC block
  clk: samsung: exynos7: add clocks for RTC block
  clk: samsung: exynos7: add gate clocks for WDT, TMU and PWM blocks

 .../devicetree/bindings/arm/samsung/pmu.txt|1 +
 .../devicetree/bindings/clock/exynos7-clock.txt|   26 ++
 arch/arm64/Kconfig |3 +
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts|   41 +++
 arch/arm64/boot/dts/exynos/exynos7.dtsi|  261 
 drivers/clk/samsung/clk-exynos7.c  |  316 
 include/dt-bindings/clock/exynos7-clk.h|   60 +++-
 7 files changed, 699 insertions(+), 9 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] drm/exynos: Add DECON driver

[Ajay kumar]

ping!

On Fri, Oct 10, 2014 at 6:18 PM, Ajay Kumar  wrote:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> DECON(Display and Enhancement Controller) is the new IP
> in exynos7 SOC for generating video signals using pixel data.
>
> DECON driver can be used to drive 2 different interfaces on Exynos7:
> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
>
> The existing FIMD driver code was used as a template to create
> DECON driver. Only DECON-INT is supported as of now, and
> DECON-EXT support will be added later.
>
> Signed-off-by: Akshu Agrawal 
> Signed-off-by: Ajay Kumar 
> ---
>  .../devicetree/bindings/video/exynos-decon.txt |   68 ++
>  drivers/gpu/drm/exynos/Kconfig |   11 +-
>  drivers/gpu/drm/exynos/Makefile|1 +
>  drivers/gpu/drm/exynos/exynos_drm_decon.c  | 1086 
> 
>  drivers/gpu/drm/exynos/exynos_drm_drv.c|   17 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|   11 +
>  include/video/samsung_decon.h  |  346 +++
>  7 files changed, 1537 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt
>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c
>  create mode 100644 include/video/samsung_decon.h
>
> diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt 
> b/Documentation/devicetree/bindings/video/exynos-decon.txt
> new file mode 100644
> index 000..e865650
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt
> @@ -0,0 +1,68 @@
> +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
> +
> +DECON (Display and Enhancement Controller) is the Display Controller for the
> +Exynos7 series of SoCs which transfers the image data from a video memory
> +buffer to an external LCD interface.
> +
> +Required properties:
> +- compatible: value should be "samsung,exynos7-decon";
> +
> +- reg: physical base address and length of the DECON registers set.
> +
> +- interrupt-parent: should be the phandle of the decon controller's
> +   parent interrupt controller.
> +
> +- interrupts: should contain a list of all DECON IP block interrupts in the
> +order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
> +format depends on the interrupt controller used.
> +
> +- interrupt-names: should contain the interrupt names: "fifo", "vsync",
> +   "lcd_sys", in the same order as they were listed in the interrupts
> +property.
> +
> +- pinctrl-0: pin control group to be used for this controller.
> +
> +- pinctrl-names: must contain a "default" entry.
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +
> +- clock-names: list of clock names sorted in the same order as the clocks
> +   property. Must contain "pclk_decon0", "aclk_decon0",
> +  "decon0_eclk", "decon0_vclk", "sclk_dsd", aclk_lh_disp0",
> +  "aclk_disp", "aclk_lh_disp1".
> +
> +Optional Properties:
> +- samsung,power-domain: a phandle to DECON power domain node.
> +
> +Example:
> +
> +SoC specific DT entry:
> +
> +   decon@1393 {
> +   compatible = "samsung,exynos7-decon";
> +   interrupt-parent = <&combiner>;
> +   reg = <0x1393 0x1000>;
> +   interrupt-names = "lcd_sys", "vsync", "fifo";
> +   interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
> +   clocks = <&clock_disp PCLK_DECON_INT>,
> +<&clock_disp ACLK_DECON_INT>,
> +<&clock_disp SCLK_DECON_INT_ECLK>,
> +<&clock_disp SCLK_DECON_INT_EXTCLKPLL>,
> +<&clock_disp SCLK_DSD>,
> +<&clock_bus0 ACLK_LH_DISP0>,
> +<&clock_disp ACLK_CP_DISP>,
> +<&clock_bus0 ACLK_LH_DISP1>;
> +   clock-names = "pclk_decon0", "aclk_decon0", "decon0_eclk",
> +   "decon0_vclk", "sclk_dsd", "aclk_lh_disp0",
> +   "aclk_disp", "aclk_lh_disp1";
> +   status = "disabled";
> +   };
> +
> +Board specific DT entry:
> +
> +   decon@1393 {
> +   pinctrl-0 = <&lcd_clk &pwm1_out>;
> +   pinctrl-names = "default";
> +   status = "okay";
> +   };
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index fd1c070..89275ea 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -31,6 +31,13 @@ config DRM_EXYNOS_FIMD
> help
>   Choose this option if you want to use Exynos FIMD for DRM.
>
> +config DRM_EXYNOS_DECON
> +   bool "Exynos DRM DECON"
> +   depends on DRM_EXYNOS
> +   sele

GPIO bindings guidelines (Was: Re: [PATCH v5 10/12] gpio: Support for unified device properties interface)

[Alexandre Courbot]

On Mon, Oct 20, 2014 at 11:26 PM, Arnd Bergmann  wrote:
> On Monday 20 October 2014 15:12:50 Alexandre Courbot wrote:
>> On Sat, Oct 18, 2014 at 6:47 PM, Arnd Bergmann  wrote:
>> > On Friday 17 October 2014 20:09:51 Arnd Bergmann wrote:
>> >> On October 17, 2014 2:16:00 PM CEST, "Rafael J. Wysocki" 
>> >>  wrote:
>> >> >From: Mika Westerberg 
>> >> >
>> >> >Some drivers need to deal with only firmware representation of its
>> >> >GPIOs. An example would be a GPIO button array driver where each button
>> >> >is described as a separate firmware node in device tree. Typically
>> >> >these
>> >> >child nodes do not have physical representation in the Linux device
>> >> >model.
>> >> >
>> >> >In order to help device drivers to handle such firmware child nodes we
>> >> >add dev[m]_get_named_gpiod_from_child() that takes a child firmware
>> >> >node pointer as its second argument (the first one is the parent device
>> >> >itself), finds the GPIO using whatever is the underlying firmware
>> >> >method, and requests the GPIO properly.
>> >>
>> >> Could we also have a wrapper around this function without a "name" 
>> >> argument,
>> >> using just the index?
>> >
>> > Expanding on this thought: I think we should mandate for new bindings
>> > that they use either a name and no index, or an index but not name,
>>
>> I'm afraid this could forbid some useful use-cases, namely the ones
>> where several GPIOs serve the same function (and are typically set
>> together). We had a few patch proposals to handle such GPIO groups,
>> and even though one was in pretty good shape the submitter did not
>> push it until the end. :/
>>
>> But my concern is that instead of having this:
>>
>> enable-gpio = <&gpio 0 GPIO_ACTIVE_HIGH>;
>> value-gpios = <&gpio 1 GPIO_ACTIVE_HIGH ... &gpio 8 GPIO_ACTIVE_HIGH>;
>>
>> We would force this:
>>
>> enable-gpio = <&gpio 0 GPIO_ACTIVE_HIGH>;
>> value0-gpio = <&gpio 1 GPIO_ACTIVE_HIGH>;
>> ...
>> value7-gpio = <&gpio 8 GPIO_ACTIVE_HIGH>;
>>
>> Or this:
>>
>> // First GPIO is enable, other GPIOs are value
>> gpios = <&gpio 0 GPIO_ACTIVE_HIGH &gpio 1 GPIO_ACTIVE_HIGH ... &gpio 8
>> GPIO_ACTIVE_HIGH>;
>>
>> Most bindings don't need that much sophistication, and for these we
>> should indeed make sure that they stick to using either the names or
>> index (and in a consistent manner), but closing the possibility to use
>> both together may bite us in the end.
>
> I would actually prefer the single-property case here, but I see your
> point. Could we make it a strong suggestion rather than a mandatory
> requirement for new bindings then?

Definitely, and a very strong suggestion even. Having to use both
names *and* index in GPIO properties should not be needed 99% of the
time.

>
>> > and I also think that for named gpios, we should try to converge on a
>> > common naming scheme. As discussed, we will probably want to support all
>> > the existing ways to do this even with ACPI and with the unified
>> > interface, but it doesn't have to be the obvious way.
>>
>> Personally, I like the idea that each GPIO has a function, so now that
>> ACPI fully supports this I'd suggest the policy of using names for
>> each GPIO (e.g. never use the fallback "gpios" or "gpio" property),
>> and only ressort to indexes if several GPIOs happen to serve the same
>> function. I know we haven't reached consensus about this so far, but
>> it would be nice it we could discuss this point again in the light of
>> the new ACPI capabilities and come with something to write as a
>> guideline in the GPIO documentation.
>
> We have enforced naming things for the dmaengine binding, which has
> just led to everyone calling things "rx" and "tx". My fear is that
> if we start to enforce giving a name, we'd end up with lots of
> drivers that use a "gpio-gpios" property or something silly.

Checking the bindings is also part of the review process. :) Things
like "gpio-gpios" should simply not be accepted to begin with.

This sounds like a good chance to finally land some guidelines
regarding GPIO bindings. Let's summarize the situation:
- GPIO bindings can be defined using both DT and ACPI (both interfaces
nicely abstracted by the interface introduced by this series)
- Both firmware interfaces support indexed GPIOs
- Both firmware interfaces support named GPIO properties, with an
optional index (can we absolutely take this for granted on ACPI now?)
- For DT bindings, both foo-gpio and foo-gpios are valid properties
for the GPIO "foo".

That's what we have now and need to maintain. However for new drivers
we want to come with guidelines that will hopefully make things easier
to review. Here are my thoughts on the topic:

- GPIOs have a function, and this function should be the GPIO name.
Thus now that ACPI supports named properties, all new GPIO properties
*must* have an accurate, explicit name.
- Indexes are only used if several GPIOs fulfill the same function
(like parallel data lines). This situation should be exceptional.
GPIOs not fulfil

[PATCH/RFC 17/17] MAINTAINERS: Add entry for bcm63xx/bcm33xx UDC gadget driver

[Kevin Cernekee]

This hardware shows up on the newly-supported BCM3384 cable chip, as well
as several old BCM63xx DSL chips.

Signed-off-by: Kevin Cernekee 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 96608c7..7916665 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2093,6 +2093,12 @@ S:   Maintained
 F: arch/arm/mach-bcm/bcm63xx.c
 F: arch/arm/include/debug/bcm63xx.S
 
+BROADCOM BCM63XX/BCM33XX UDC DRIVER
+M: Kevin Cernekee 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/usb/gadget/udc/bcm63xx_udc.*
+
 BROADCOM BCM7XXX ARM ARCHITECTURE
 M: Marc Carino 
 M: Brian Norris 
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 16/17] MAINTAINERS: Add entry for BCM33xx cable chips

[Kevin Cernekee]

Add myself as a maintainer for the new BCM3384 board support code.

Signed-off-by: Kevin Cernekee 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index d483627..96608c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2069,6 +2069,14 @@ T:   git 
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git
 S: Maintained
 N: bcm2835
 
+BROADCOM BCM33XX MIPS ARCHITECTURE
+M: Kevin Cernekee 
+L: linux-m...@linux-mips.org
+S: Maintained
+F: arch/mips/bcm3384/*
+F: arch/mips/include/asm/mach-bcm3384/*
+F: arch/mips/kernel/*bmips*
+
 BROADCOM BCM5301X ARM ARCHITECTURE
 M: Hauke Mehrtens 
 L: linux-arm-ker...@lists.infradead.org
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 15/17] MIPS: bcm3384: Initial commit of bcm3384 platform support

[Kevin Cernekee]

This supports SMP Linux running on the BCM3384 Zephyr (BMIPS5000)
application processor, with fully functional UART and USB 1.1/2.0.
Device Tree is used to configure the following items:

 - All peripherals
 - Early console base address
 - SMP or UP mode
 - MIPS counter frequency
 - Memory size / regions
 - DMA offset
 - Kernel command line

The DT-enabled bootloader and build instructions are posted at
https://github.com/Broadcom/aeolus

Signed-off-by: Kevin Cernekee 
---
 arch/mips/Kbuild.platforms |   1 +
 arch/mips/Kconfig  |  26 +++
 arch/mips/bcm3384/Makefile |   1 +
 arch/mips/bcm3384/Platform |   7 +
 arch/mips/bcm3384/dma.c|  81 +
 arch/mips/bcm3384/irq.c| 193 +
 arch/mips/bcm3384/setup.c  |  97 +++
 arch/mips/boot/dts/Makefile|   1 +
 arch/mips/boot/dts/bcm3384.dtsi| 109 
 arch/mips/boot/dts/bcm93384wvg.dts |  32 
 arch/mips/configs/bcm3384_defconfig|  78 +
 arch/mips/include/asm/mach-bcm3384/dma-coherence.h |  48 +
 arch/mips/include/asm/mach-bcm3384/war.h   |  24 +++
 13 files changed, 698 insertions(+)
 create mode 100644 arch/mips/bcm3384/Makefile
 create mode 100644 arch/mips/bcm3384/Platform
 create mode 100644 arch/mips/bcm3384/dma.c
 create mode 100644 arch/mips/bcm3384/irq.c
 create mode 100644 arch/mips/bcm3384/setup.c
 create mode 100644 arch/mips/boot/dts/bcm3384.dtsi
 create mode 100644 arch/mips/boot/dts/bcm93384wvg.dts
 create mode 100644 arch/mips/configs/bcm3384_defconfig
 create mode 100644 arch/mips/include/asm/mach-bcm3384/dma-coherence.h
 create mode 100644 arch/mips/include/asm/mach-bcm3384/war.h

diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
index f5e18bf..7c50721 100644
--- a/arch/mips/Kbuild.platforms
+++ b/arch/mips/Kbuild.platforms
@@ -3,6 +3,7 @@
 platforms += alchemy
 platforms += ar7
 platforms += ath79
+platforms += bcm3384
 platforms += bcm47xx
 platforms += bcm63xx
 platforms += cavium-octeon
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 38e02e1..1c277d5 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -115,6 +115,32 @@ config ATH79
help
  Support for the Atheros AR71XX/AR724X/AR913X SoCs.
 
+config BCM3384
+   bool "Broadcom BCM3384 based boards"
+   select BOOT_RAW
+   select NO_EXCEPT_FILL
+   select USE_OF
+   select CEVT_R4K
+   select CSRC_R4K
+   select SYNC_R4K
+   select COMMON_CLK
+   select DMA_NONCOHERENT
+   select IRQ_CPU
+   select SYS_SUPPORTS_32BIT_KERNEL
+   select SYS_SUPPORTS_BIG_ENDIAN
+   select SYS_SUPPORTS_HIGHMEM
+   select SYS_HAS_CPU_BMIPS5000
+   select SWAP_IO_SPACE
+   select USB_EHCI_BIG_ENDIAN_DESC
+   select USB_EHCI_BIG_ENDIAN_MMIO
+   select USB_OHCI_BIG_ENDIAN_DESC
+   select USB_OHCI_BIG_ENDIAN_MMIO
+   help
+ Support for BCM3384 based boards.  BCM3384/BCM33843 is a cable modem
+ chipset with a Linux application processor that is often used to
+ provide Samba services, a CUPS print server, and/or advanced routing
+ features.
+
 config BCM47XX
bool "Broadcom BCM47XX based boards"
select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/mips/bcm3384/Makefile b/arch/mips/bcm3384/Makefile
new file mode 100644
index 000..a393955
--- /dev/null
+++ b/arch/mips/bcm3384/Makefile
@@ -0,0 +1 @@
+obj-y  += setup.o irq.o dma.o
diff --git a/arch/mips/bcm3384/Platform b/arch/mips/bcm3384/Platform
new file mode 100644
index 000..8e1ca08
--- /dev/null
+++ b/arch/mips/bcm3384/Platform
@@ -0,0 +1,7 @@
+#
+# Broadcom BCM3384 boards
+#
+platform-$(CONFIG_BCM3384) += bcm3384/
+cflags-$(CONFIG_BCM3384)   +=  \
+   -I$(srctree)/arch/mips/include/asm/mach-bcm3384/
+load-$(CONFIG_BCM3384) := 0x8001
diff --git a/arch/mips/bcm3384/dma.c b/arch/mips/bcm3384/dma.c
new file mode 100644
index 000..ea42012
--- /dev/null
+++ b/arch/mips/bcm3384/dma.c
@@ -0,0 +1,81 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2014 Kevin Cernekee 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * BCM3384 has configurable address translation windows which allow the
+ * peripherals' DMA addresses to be different from the Zephyr-visible
+ * physical addresses.  e.g. usb_dma_addr = zephyr_pa ^ 0x0800
+ *
+ * If our DT "memory" node has a "dma-xor-mask" property we will enable this
+ * translation using the provided offset.
+ */
+static u32 bcm3384_dma_xor_mask

[PATCH/RFC 13/17] Documentation: DT: Add entries for BCM3384 and its peripherals

[Kevin Cernekee]

This covers the new "brcm,*" devices added in the upcoming bcm3384 commit.

Signed-off-by: Kevin Cernekee 
---
 .../devicetree/bindings/mips/brcm/bcm3384-intc.txt | 37 ++
 .../devicetree/bindings/mips/brcm/bmips.txt|  8 +
 .../devicetree/bindings/mips/brcm/cm-dsl.txt   | 11 +++
 .../devicetree/bindings/mips/brcm/usb.txt  | 11 +++
 4 files changed, 67 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mips/brcm/bcm3384-intc.txt
 create mode 100644 Documentation/devicetree/bindings/mips/brcm/bmips.txt
 create mode 100644 Documentation/devicetree/bindings/mips/brcm/cm-dsl.txt
 create mode 100644 Documentation/devicetree/bindings/mips/brcm/usb.txt

diff --git a/Documentation/devicetree/bindings/mips/brcm/bcm3384-intc.txt 
b/Documentation/devicetree/bindings/mips/brcm/bcm3384-intc.txt
new file mode 100644
index 000..d4e0141
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/brcm/bcm3384-intc.txt
@@ -0,0 +1,37 @@
+* Interrupt Controller
+
+Properties:
+- compatible: "brcm,bcm3384-intc"
+
+  Compatibility with BCM3384 and possibly other BCM33xx/BCM63xx SoCs.
+
+- reg: Address/length pairs for each mask/status register set.  Length must
+  be 8.  If multiple register sets are specified, the first set will
+  handle IRQ offsets 0..31, the second set 32..63, and so on.
+
+- interrupt-controller: This is an interrupt controller.
+
+- #interrupt-cells: Must be <1>.  Just a simple IRQ offset; no level/edge
+  or polarity configuration is possible with this controller.
+
+- interrupt-parent: This controller is cascaded from a MIPS CPU HW IRQ, or
+  from another INTC.
+
+- interrupts: The IRQ on the parent controller.
+
+Example:
+   periph_intc: periph_intc@14e00038 {
+   compatible = "brcm,bcm3384-intc";
+
+   /*
+* IRQs 0..31:  mask reg 0x14e00038, status reg 0x14e0003c
+* IRQs 32..63: mask reg 0x14e00340, status reg 0x14e00344
+*/
+   reg = <0x14e00038 0x8 0x14e00340 0x8>;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   interrupt-parent = <&cpu_intc>;
+   interrupts = <4>;
+   };
diff --git a/Documentation/devicetree/bindings/mips/brcm/bmips.txt 
b/Documentation/devicetree/bindings/mips/brcm/bmips.txt
new file mode 100644
index 000..8ef71b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/brcm/bmips.txt
@@ -0,0 +1,8 @@
+* Broadcom MIPS (BMIPS) CPUs
+
+Required properties:
+- compatible: "brcm,bmips3300", "brcm,bmips4350", "brcm,bmips4380",
+  "brcm,bmips5000"
+
+- mips-hpt-frequency: This is common to all CPUs in the system so it lives
+  under the "cpus" node.
diff --git a/Documentation/devicetree/bindings/mips/brcm/cm-dsl.txt 
b/Documentation/devicetree/bindings/mips/brcm/cm-dsl.txt
new file mode 100644
index 000..8a139cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/brcm/cm-dsl.txt
@@ -0,0 +1,11 @@
+* Broadcom cable/DSL platforms
+
+SoCs:
+
+Required properties:
+- compatible: "brcm,bcm3384", "brcm,bcm33843"
+
+Boards:
+
+Required properties:
+- compatible: "brcm,bcm93384wvg"
diff --git a/Documentation/devicetree/bindings/mips/brcm/usb.txt 
b/Documentation/devicetree/bindings/mips/brcm/usb.txt
new file mode 100644
index 000..452c45c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/brcm/usb.txt
@@ -0,0 +1,11 @@
+* Broadcom USB controllers
+
+Required properties:
+- compatible: "brcm,bcm3384-ohci", "brcm,bcm3384-ehci"
+
+  These currently use the generic-ohci and generic-ehci drivers.  On some
+  systems, special handling may be needed in the following cases:
+
+  - Restoring state after systemwide power save modes
+  - Sharing PHYs with the USBD (UDC) hardware
+  - Figuring out which controllers are disabled on ASIC bondout variants
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 14/17] Documentation: DT: Add "mti" vendor prefix

[Kevin Cernekee]

We have a bunch of platforms using "mti,cpu-interrupt-controller" but
the "mti" prefix isn't documented.  Fix this.

Signed-off-by: Kevin Cernekee 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 723999d..b2114de 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -96,6 +96,7 @@ mitsubishiMitsubishi Electric Corporation
 mosaixtech Mosaix Technologies, Inc.
 moxa   Moxa
 mplMPL AG
+mtiImagination Technologies Ltd. (formerly MIPS Technologies Inc.)
 mundoreaderMundo Reader S.L.
 murata Murata Manufacturing Co., Ltd.
 mxicy  Macronix International Co., Ltd.
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 10/17] MIPS: BMIPS: Add special cache handling in c-r4k.c

[Kevin Cernekee]

BMIPS435x and BMIPS438x have a single shared L1 D$ and load/store unit,
so it isn't necessary to raise IPIs to keep both CPUs coherent.

BMIPS5000 has VIPT L1 caches that handle aliases in hardware, and its I$
fills from D$.  But a special sequence with 2 SYNCs and 32 NOPs is needed
to ensure coherency.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/mm/c-r4k.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index fbcd867..dd261df 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -917,6 +917,18 @@ static inline void alias_74k_erratum(struct cpuinfo_mips 
*c)
}
 }
 
+static void b5k_instruction_hazard(void)
+{
+   __sync();
+   __sync();
+   __asm__ __volatile__(
+   "   nop; nop; nop; nop; nop; nop; nop; nop\n"
+   "   nop; nop; nop; nop; nop; nop; nop; nop\n"
+   "   nop; nop; nop; nop; nop; nop; nop; nop\n"
+   "   nop; nop; nop; nop; nop; nop; nop; nop\n"
+   : : : "memory");
+}
+
 static char *way_string[] = { NULL, "direct mapped", "2-way",
"3-way", "4-way", "5-way", "6-way", "7-way", "8-way"
 };
@@ -1683,6 +1695,37 @@ void r4k_cache_init(void)
 
coherency_setup();
board_cache_error_setup = r4k_cache_error_setup;
+
+   /*
+* Per-CPU overrides
+*/
+   switch (current_cpu_type()) {
+   case CPU_BMIPS4350:
+   case CPU_BMIPS4380:
+   /* No IPI is needed because all CPUs share the same D$ */
+   flush_data_cache_page = r4k_blast_dcache_page;
+   break;
+   case CPU_BMIPS5000:
+   /* We lose our superpowers if L2 is disabled */
+   if (c->scache.flags & MIPS_CACHE_NOT_PRESENT)
+   break;
+
+   /* I$ fills from D$ just by emptying the write buffers */
+   flush_cache_page = (void *)b5k_instruction_hazard;
+   flush_cache_range = (void *)b5k_instruction_hazard;
+   flush_cache_sigtramp = (void *)b5k_instruction_hazard;
+   local_flush_data_cache_page = (void *)b5k_instruction_hazard;
+   flush_data_cache_page = (void *)b5k_instruction_hazard;
+   flush_icache_range = (void *)b5k_instruction_hazard;
+   local_flush_icache_range = (void *)b5k_instruction_hazard;
+
+   /* Cache aliases are handled in hardware; allow HIGHMEM */
+   current_cpu_data.dcache.flags &= ~MIPS_CACHE_ALIASES;
+
+   /* Optimization: an L2 flush implicitly flushes the L1 */
+   current_cpu_data.options |= MIPS_CPU_INCLUSIVE_CACHES;
+   break;
+   }
 }
 
 static int r4k_cache_pm_notifier(struct notifier_block *self, unsigned long 
cmd,
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 01/17] MIPS: BMIPS: Fix ".previous without corresponding .section" warnings

[Kevin Cernekee]

Commit 078a55fc824c1 ("Delete __cpuinit/__CPUINIT usage from MIPS code")
removed our __CPUINIT directives, so now the ".previous" directives
are superfluous.  Remove them.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/bmips_vec.S | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/mips/kernel/bmips_vec.S b/arch/mips/kernel/bmips_vec.S
index 290c23b..8649507 100644
--- a/arch/mips/kernel/bmips_vec.S
+++ b/arch/mips/kernel/bmips_vec.S
@@ -208,7 +208,6 @@ bmips_reset_nmi_vec_end:
 END(bmips_reset_nmi_vec)
 
.setpop
-   .previous
 
 /***
  * CPU1 warm restart vector (used for second and subsequent boots).
@@ -281,5 +280,3 @@ LEAF(bmips_enable_xks01)
jr  ra
 
 END(bmips_enable_xks01)
-
-   .previous
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 04/17] MIPS: BMIPS: Allow BMIPS3300 to utilize SMP ebase relocation code

[Kevin Cernekee]

From: Jon Fraser 

BMIPS3300 processors do not have the hardware to support SMP, but with a
small tweak, the SMP ebase relocation code allows BMIPS3300-based
platforms to reuse the S2/S3 power management code from BMIPS4380-based
chips.  Normally this is as simple as adding one line to prom_init():

board_ebase_setup = &bmips_ebase_setup;

Signed-off-by: Jon Fraser 
Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/smp-bmips.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index 8383fa4..887c3ea 100644
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -541,6 +541,7 @@ void bmips_ebase_setup(void)
&bmips_smp_int_vec, 0x80);
__sync();
return;
+   case CPU_BMIPS3300:
case CPU_BMIPS4380:
/*
 * 0x8000_: reset/NMI (initially in kseg1)
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 03/17] MIPS: BMIPS: Introduce helper function to change the reset vector

[Kevin Cernekee]

This will need to be called from a few different places, and the logic
is starting to get a bit hairy (with the need for IPIs, CPU bug
workarounds, and hazards).

Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/smp-bmips.c | 65 +++-
 1 file changed, 58 insertions(+), 7 deletions(-)

diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index 4e56911..8383fa4 100644
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int __maybe_unused max_cpus = 1;
 
@@ -43,6 +44,9 @@ int bmips_smp_enabled = 1;
 int bmips_cpu_offset;
 cpumask_t bmips_booted_mask;
 
+#define RESET_FROM_KSEG0   0x80080800
+#define RESET_FROM_KSEG1   0xa0080800
+
 #ifdef CONFIG_SMP
 
 /* initial $sp, $gp - used by arch/mips/kernel/bmips_vec.S */
@@ -463,10 +467,61 @@ static inline void bmips_nmi_handler_setup(void)
&bmips_smp_int_vec_end);
 }
 
+struct reset_vec_info {
+   int cpu;
+   u32 val;
+};
+
+static void bmips_set_reset_vec_remote(void *vinfo)
+{
+   struct reset_vec_info *info = vinfo;
+   int shift = info->cpu & 0x01 ? 16 : 0;
+   u32 mask = ~(0x << shift), val = info->val >> 16;
+
+   preempt_disable();
+   if (smp_processor_id() > 0) {
+   smp_call_function_single(0, &bmips_set_reset_vec_remote,
+info, 1);
+   } else {
+   if (info->cpu & 0x02) {
+   /* BMIPS5200 "should" use mask/shift, but it's buggy */
+   bmips_write_zscm_reg(0xa0, (val << 16) | val);
+   bmips_read_zscm_reg(0xa0);
+   } else {
+   write_c0_brcm_bootvec((read_c0_brcm_bootvec() & mask) |
+ (val << shift));
+   }
+   }
+   preempt_enable();
+}
+
+static void bmips_set_reset_vec(int cpu, u32 val)
+{
+   struct reset_vec_info info;
+
+   if (current_cpu_type() == CPU_BMIPS5000) {
+   /* this needs to run from CPU0 (which is always online) */
+   info.cpu = cpu;
+   info.val = val;
+   bmips_set_reset_vec_remote(&info);
+   } else {
+   void __iomem *cbr = BMIPS_GET_CBR();
+
+   if (cpu == 0)
+   __raw_writel(val, cbr + BMIPS_RELO_VECTOR_CONTROL_0);
+   else {
+   if (current_cpu_type() != CPU_BMIPS4380)
+   return;
+   __raw_writel(val, cbr + BMIPS_RELO_VECTOR_CONTROL_1);
+   }
+   }
+   __sync();
+   back_to_back_c0_hazard();
+}
+
 void bmips_ebase_setup(void)
 {
unsigned long new_ebase = ebase;
-   void __iomem __maybe_unused *cbr;
 
BUG_ON(ebase != CKSEG0);
 
@@ -492,9 +547,7 @@ void bmips_ebase_setup(void)
 * 0x8000_0400: normal vectors
 */
new_ebase = 0x8400;
-   cbr = BMIPS_GET_CBR();
-   __raw_writel(0x80080800, cbr + BMIPS_RELO_VECTOR_CONTROL_0);
-   __raw_writel(0xa0080800, cbr + BMIPS_RELO_VECTOR_CONTROL_1);
+   bmips_set_reset_vec(0, RESET_FROM_KSEG0);
break;
case CPU_BMIPS5000:
/*
@@ -502,10 +555,8 @@ void bmips_ebase_setup(void)
 * 0x8000_1000: normal vectors
 */
new_ebase = 0x80001000;
-   write_c0_brcm_bootvec(0xa0088008);
+   bmips_set_reset_vec(0, RESET_FROM_KSEG0);
write_c0_ebase(new_ebase);
-   if (max_cpus > 2)
-   bmips_write_zscm_reg(0xa0, 0xa008a008);
break;
default:
return;
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 00/17] MIPS: BMIPS updates and BCM3384 platform support

[Kevin Cernekee]

This patch series adds support for the Linux BMIPS5000 application
processor on BCM3384, a cable modem chipset.  It incorporates the
latest bugfixes and workarounds available for the BMIPS SMP and cache
maintenance code.

The bootloader code[1] passes a device tree blob describing the
memory setup, bootargs, peripheral configuration, clocks, etc.  For
this reason, very little needs to be hardcoded in the kernel.

Dependencies:

 - bcm63xx_uart and of-serial changes, under review on the linux-serial
   list

 - OHCI changes, pending inclusion on usb.git -next

[1] https://github.com/broadcom/aeolus


Jon Fraser (2):
  MIPS: BMIPS: Allow BMIPS3300 to utilize SMP ebase relocation code
  MIPS: BMIPS: Mask off timer IRQs when hot-unplugging a CPU

Kevin Cernekee (15):
  MIPS: BMIPS: Fix ".previous without corresponding .section" warnings
  MIPS: BMIPS: Align secondary boot sequence with latest firmware
releases
  MIPS: BMIPS: Introduce helper function to change the reset vector
  MIPS: BMIPS: Explicitly configure reset vectors prior to secondary
boot
  MIPS: Allow MIPS_CPU_SCACHE to be used with different line sizes
  MIPS: BMIPS: Select the appropriate L1_CACHE_SHIFT for 438x and 5000
CPUs
  MIPS: BMIPS: Let each platform customize the CPU1 IRQ mask
  MIPS: BMIPS: Add special cache handling in c-r4k.c
  MIPS: BMIPS: Add PRId for BMIPS5200 (Whirlwind)
  MIPS: Create a helper function for DT setup
  Documentation: DT: Add entries for BCM3384 and its peripherals
  Documentation: DT: Add "mti" vendor prefix
  MIPS: bcm3384: Initial commit of bcm3384 platform support
  MAINTAINERS: Add entry for BCM33xx cable chips
  MAINTAINERS: Add entry for bcm63xx/bcm33xx UDC gadget driver

 .../devicetree/bindings/mips/brcm/bcm3384-intc.txt |  37 
 .../devicetree/bindings/mips/brcm/bmips.txt|   8 +
 .../devicetree/bindings/mips/brcm/cm-dsl.txt   |  11 ++
 .../devicetree/bindings/mips/brcm/usb.txt  |  11 ++
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 MAINTAINERS|  14 ++
 arch/mips/Kbuild.platforms |   1 +
 arch/mips/Kconfig  |  30 +++-
 arch/mips/bcm3384/Makefile |   1 +
 arch/mips/bcm3384/Platform |   7 +
 arch/mips/bcm3384/dma.c|  81 +
 arch/mips/bcm3384/irq.c| 193 +
 arch/mips/bcm3384/setup.c  |  97 +++
 arch/mips/boot/dts/Makefile|   1 +
 arch/mips/boot/dts/bcm3384.dtsi| 109 
 arch/mips/boot/dts/bcm93384wvg.dts |  32 
 arch/mips/configs/bcm3384_defconfig|  78 +
 arch/mips/include/asm/bmips.h  |   1 +
 arch/mips/include/asm/cpu.h|   1 +
 arch/mips/include/asm/mach-bcm3384/dma-coherence.h |  48 +
 arch/mips/include/asm/mach-bcm3384/war.h   |  24 +++
 arch/mips/include/asm/prom.h   |   1 +
 arch/mips/kernel/bmips_vec.S   |   3 -
 arch/mips/kernel/cpu-probe.c   |   1 +
 arch/mips/kernel/prom.c|  18 ++
 arch/mips/kernel/smp-bmips.c   | 114 +++-
 arch/mips/lantiq/prom.c|  11 +-
 arch/mips/mm/c-r4k.c   |  43 +
 arch/mips/ralink/of.c  |  14 +-
 29 files changed, 924 insertions(+), 67 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mips/brcm/bcm3384-intc.txt
 create mode 100644 Documentation/devicetree/bindings/mips/brcm/bmips.txt
 create mode 100644 Documentation/devicetree/bindings/mips/brcm/cm-dsl.txt
 create mode 100644 Documentation/devicetree/bindings/mips/brcm/usb.txt
 create mode 100644 arch/mips/bcm3384/Makefile
 create mode 100644 arch/mips/bcm3384/Platform
 create mode 100644 arch/mips/bcm3384/dma.c
 create mode 100644 arch/mips/bcm3384/irq.c
 create mode 100644 arch/mips/bcm3384/setup.c
 create mode 100644 arch/mips/boot/dts/bcm3384.dtsi
 create mode 100644 arch/mips/boot/dts/bcm93384wvg.dts
 create mode 100644 arch/mips/configs/bcm3384_defconfig
 create mode 100644 arch/mips/include/asm/mach-bcm3384/dma-coherence.h
 create mode 100644 arch/mips/include/asm/mach-bcm3384/war.h

-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 02/17] MIPS: BMIPS: Align secondary boot sequence with latest firmware releases

[Kevin Cernekee]

On some older BMIPS5200 (dual core / quad thread) platforms, the
PROM code set up CPU2/CPU3 so they would be started through an NMI
instead of through the ACTION register.  But this was incompatible with
some power management features that were later added, so the scheme was
changed so that Linux is fully responsible for booting CPU2/CPU3.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/smp-bmips.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index 06bb5ed..4e56911 100644
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -213,17 +213,7 @@ static void bmips_boot_secondary(int cpu, struct 
task_struct *idle)
set_c0_brcm_cmt_ctrl(0x01);
break;
case CPU_BMIPS5000:
-   if (cpu & 0x01)
-   write_c0_brcm_action(ACTION_BOOT_THREAD(cpu));
-   else {
-   /*
-* core N thread 0 was already booted; just
-* pulse the NMI line
-*/
-   bmips_write_zscm_reg(0x210, 0xc000);
-   udelay(10);
-   bmips_write_zscm_reg(0x210, 0x00);
-   }
+   write_c0_brcm_action(ACTION_BOOT_THREAD(cpu));
break;
}
cpumask_set_cpu(cpu, &bmips_booted_mask);
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 08/17] MIPS: BMIPS: Select the appropriate L1_CACHE_SHIFT for 438x and 5000 CPUs

[Kevin Cernekee]

BMIPS438x has a 64-byte D$ line size and BMIPS5000 has a 128-byte L2
line size.  If L1_CACHE_SHIFT is undersized, DMA buffers will not be
cacheline-aligned and terrible things will happen.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 37b085c..38e02e1 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1587,12 +1587,14 @@ config CPU_BMIPS4350
 
 config CPU_BMIPS4380
bool
+   select MIPS_L1_CACHE_SHIFT_6
select SYS_SUPPORTS_SMP
select SYS_SUPPORTS_HOTPLUG_CPU
 
 config CPU_BMIPS5000
bool
select MIPS_CPU_SCACHE
+   select MIPS_L1_CACHE_SHIFT_7
select SYS_SUPPORTS_SMP
select SYS_SUPPORTS_HOTPLUG_CPU
 
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 07/17] MIPS: Allow MIPS_CPU_SCACHE to be used with different line sizes

[Kevin Cernekee]

CONFIG_MIPS_CPU_SCACHE determines whether to build sc-mips.c.  However,
it is currently hardwired to use an L1_SHIFT of 6 (64 bytes).  Move the
L1_SHIFT selection into the CPU or SoC section so that other SoCs can
select different values.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index ad6badb..37b085c 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -326,6 +326,7 @@ config MIPS_MALTA
select I8259
select MIPS_BONITO64
select MIPS_CPU_SCACHE
+   select MIPS_L1_CACHE_SHIFT_6
select PCI_GT64XXX_PCI0
select MIPS_MSC
select SWAP_IO_SPACE
@@ -1908,7 +1909,6 @@ config IP22_CPU_SCACHE
 config MIPS_CPU_SCACHE
bool
select BOARD_SCACHE
-   select MIPS_L1_CACHE_SHIFT_6
 
 config R5000_CPU_SCACHE
bool
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 11/17] MIPS: BMIPS: Add PRId for BMIPS5200 (Whirlwind)

[Kevin Cernekee]

This is a dual core (quad thread) BMIPS5000.  It needs a little extra
code to boot the second core (CPU2/CPU3), but for now we can treat it the
same as a single core BMIPS5000.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/include/asm/cpu.h  | 1 +
 arch/mips/kernel/cpu-probe.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/mips/include/asm/cpu.h b/arch/mips/include/asm/cpu.h
index dfdc77e..de9ca43 100644
--- a/arch/mips/include/asm/cpu.h
+++ b/arch/mips/include/asm/cpu.h
@@ -142,6 +142,7 @@
 #define PRID_IMP_BMIPS3300_BUG 0x
 #define PRID_IMP_BMIPS43XX 0xa000
 #define PRID_IMP_BMIPS5000 0x5a00
+#define PRID_IMP_BMIPS5200 0x5b00
 
 #define PRID_REV_BMIPS4380_LO  0x0040
 #define PRID_REV_BMIPS4380_HI  0x006f
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index 94c4a0c..5477d91 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -1024,6 +1024,7 @@ static inline void cpu_probe_broadcom(struct cpuinfo_mips 
*c, unsigned int cpu)
break;
}
case PRID_IMP_BMIPS5000:
+   case PRID_IMP_BMIPS5200:
c->cputype = CPU_BMIPS5000;
__cpu_name[cpu] = "Broadcom BMIPS5000";
set_elf_platform(cpu, "bmips5000");
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 06/17] MIPS: BMIPS: Explicitly configure reset vectors prior to secondary boot

[Kevin Cernekee]

The secondary CPU's reset vector needs to be set to KSEG1 for a cold
boot (release from reset), or KSEG0 for a warm restart.  On a cold boot
KSEG0 may be unavailable (BMIPS4380), and on a warm restart KSEG1 may
be unavailable (XKS01 mode on 4380 or 5000).

Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/smp-bmips.c | 29 -
 1 file changed, 8 insertions(+), 21 deletions(-)

diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index f7b1bee..162391d 100644
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -47,6 +47,8 @@ cpumask_t bmips_booted_mask;
 #define RESET_FROM_KSEG0   0x80080800
 #define RESET_FROM_KSEG1   0xa0080800
 
+static void bmips_set_reset_vec(int cpu, u32 val);
+
 #ifdef CONFIG_SMP
 
 /* initial $sp, $gp - used by arch/mips/kernel/bmips_vec.S */
@@ -198,6 +200,9 @@ static void bmips_boot_secondary(int cpu, struct 
task_struct *idle)
pr_info("SMP: Booting CPU%d...\n", cpu);
 
if (cpumask_test_cpu(cpu, &bmips_booted_mask)) {
+   /* kseg1 might not exist if this CPU enabled XKS01 */
+   bmips_set_reset_vec(cpu, RESET_FROM_KSEG0);
+
switch (current_cpu_type()) {
case CPU_BMIPS4350:
case CPU_BMIPS4380:
@@ -207,8 +212,9 @@ static void bmips_boot_secondary(int cpu, struct 
task_struct *idle)
bmips5000_send_ipi_single(cpu, 0);
break;
}
-   }
-   else {
+   } else {
+   bmips_set_reset_vec(cpu, RESET_FROM_KSEG1);
+
switch (current_cpu_type()) {
case CPU_BMIPS4350:
case CPU_BMIPS4380:
@@ -229,31 +235,12 @@ static void bmips_boot_secondary(int cpu, struct 
task_struct *idle)
  */
 static void bmips_init_secondary(void)
 {
-   /* move NMI vector to kseg0, in case XKS01 is enabled */
-
-   void __iomem *cbr;
-   unsigned long old_vec;
-   unsigned long relo_vector;
-   int boot_cpu;
-
switch (current_cpu_type()) {
case CPU_BMIPS4350:
case CPU_BMIPS4380:
-   cbr = BMIPS_GET_CBR();
-
-   boot_cpu = !!(read_c0_brcm_cmt_local() & (1 << 31));
-   relo_vector = boot_cpu ? BMIPS_RELO_VECTOR_CONTROL_0 :
- BMIPS_RELO_VECTOR_CONTROL_1;
-
-   old_vec = __raw_readl(cbr + relo_vector);
-   __raw_writel(old_vec & ~0x2000, cbr + relo_vector);
-
clear_c0_cause(smp_processor_id() ? C_SW1 : C_SW0);
break;
case CPU_BMIPS5000:
-   write_c0_brcm_bootvec(read_c0_brcm_bootvec() &
-   (smp_processor_id() & 0x01 ? ~0x2000 : ~0x2000));
-
write_c0_brcm_action(ACTION_CLR_IPI(smp_processor_id(), 0));
break;
}
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 09/17] MIPS: BMIPS: Let each platform customize the CPU1 IRQ mask

[Kevin Cernekee]

On some chips like bcm3384, "other stuff" gets wired up to CPU1's IE_IRQ1
input, generating spurious IRQs.  In this case we want the platform code
to be able to mask it off.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/include/asm/bmips.h | 1 +
 arch/mips/kernel/smp-bmips.c  | 6 --
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/mips/include/asm/bmips.h b/arch/mips/include/asm/bmips.h
index cbacceb..30939b0 100644
--- a/arch/mips/include/asm/bmips.h
+++ b/arch/mips/include/asm/bmips.h
@@ -84,6 +84,7 @@ extern char bmips_smp_int_vec_end;
 extern int bmips_smp_enabled;
 extern int bmips_cpu_offset;
 extern cpumask_t bmips_booted_mask;
+extern unsigned long bmips_tp1_irqs;
 
 extern void bmips_ebase_setup(void);
 extern asmlinkage void plat_wired_tlb_setup(void);
diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index 162391d..b8bd934 100644
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -43,6 +43,7 @@ static int __maybe_unused max_cpus = 1;
 int bmips_smp_enabled = 1;
 int bmips_cpu_offset;
 cpumask_t bmips_booted_mask;
+unsigned long bmips_tp1_irqs = IE_IRQ1;
 
 #define RESET_FROM_KSEG0   0x80080800
 #define RESET_FROM_KSEG1   0xa0080800
@@ -257,7 +258,7 @@ static void bmips_smp_finish(void)
write_c0_compare(read_c0_count() + mips_hpt_frequency / HZ);
 
irq_enable_hazard();
-   set_c0_status(IE_SW0 | IE_SW1 | IE_IRQ1 | IE_IRQ5 | ST0_IE);
+   set_c0_status(IE_SW0 | IE_SW1 | bmips_tp1_irqs | IE_IRQ5 | ST0_IE);
irq_enable_hazard();
 }
 
@@ -387,7 +388,8 @@ void __ref play_dead(void)
 * IRQ handlers; this clears ST0_IE and returns immediately.
 */
clear_c0_cause(CAUSEF_IV | C_SW0 | C_SW1);
-   change_c0_status(IE_IRQ5 | IE_IRQ1 | IE_SW0 | IE_SW1 | ST0_IE | ST0_BEV,
+   change_c0_status(
+   IE_IRQ5 | bmips_tp1_irqs | IE_SW0 | IE_SW1 | ST0_IE | ST0_BEV,
IE_SW0 | IE_SW1 | ST0_IE | ST0_BEV);
irq_disable_hazard();
 
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 12/17] MIPS: Create a helper function for DT setup

[Kevin Cernekee]

A couple of platforms register two buses and call of_platform_populate().
Move this into a common function to reduce duplication.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/include/asm/prom.h |  1 +
 arch/mips/kernel/prom.c  | 18 ++
 arch/mips/lantiq/prom.c  | 11 +--
 arch/mips/ralink/of.c| 14 ++
 4 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/mips/include/asm/prom.h b/arch/mips/include/asm/prom.h
index a9494c0..eaa2627 100644
--- a/arch/mips/include/asm/prom.h
+++ b/arch/mips/include/asm/prom.h
@@ -22,6 +22,7 @@ extern void device_tree_init(void);
 struct boot_param_header;
 
 extern void __dt_setup_arch(void *bph);
+extern int __dt_register_buses(const char *bus0, const char *bus1);
 
 #define dt_setup_arch(sym) \
 ({ \
diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
index 5d39bb8..452d435 100644
--- a/arch/mips/kernel/prom.c
+++ b/arch/mips/kernel/prom.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -54,4 +55,21 @@ void __init __dt_setup_arch(void *bph)
 
mips_set_machine_name(of_flat_dt_get_machine_name());
 }
+
+int __init __dt_register_buses(const char *bus0, const char *bus1)
+{
+   static struct of_device_id of_ids[3];
+
+   if (!of_have_populated_dt())
+   panic("device tree not present");
+
+   strlcpy(of_ids[0].compatible, bus0, sizeof(of_ids[0].compatible));
+   strlcpy(of_ids[1].compatible, bus1, sizeof(of_ids[1].compatible));
+
+   if (of_platform_populate(NULL, of_ids, NULL, NULL))
+   panic("failed to populate DT");
+
+   return 0;
+}
+
 #endif
diff --git a/arch/mips/lantiq/prom.c b/arch/mips/lantiq/prom.c
index 7447d32..758970e 100644
--- a/arch/mips/lantiq/prom.c
+++ b/arch/mips/lantiq/prom.c
@@ -97,16 +97,7 @@ void __init prom_init(void)
 
 int __init plat_of_setup(void)
 {
-   static struct of_device_id of_ids[3];
-
-   if (!of_have_populated_dt())
-   panic("device tree not present");
-
-   strlcpy(of_ids[0].compatible, soc_info.compatible,
-   sizeof(of_ids[0].compatible));
-   strncpy(of_ids[1].compatible, "simple-bus",
-   sizeof(of_ids[1].compatible));
-   return of_platform_populate(NULL, of_ids, NULL, NULL);
+   return __dt_register_buses(soc_info.compatible, "simple-bus");
 }
 
 arch_initcall(plat_of_setup);
diff --git a/arch/mips/ralink/of.c b/arch/mips/ralink/of.c
index 7c4598c..f68115f 100644
--- a/arch/mips/ralink/of.c
+++ b/arch/mips/ralink/of.c
@@ -74,19 +74,9 @@ void __init plat_mem_setup(void)
 
 static int __init plat_of_setup(void)
 {
-   static struct of_device_id of_ids[3];
-   int len = sizeof(of_ids[0].compatible);
+   __dt_register_buses(soc_info.compatible, "palmbus");
 
-   if (!of_have_populated_dt())
-   panic("device tree not present");
-
-   strlcpy(of_ids[0].compatible, soc_info.compatible, len);
-   strlcpy(of_ids[1].compatible, "palmbus", len);
-
-   if (of_platform_populate(NULL, of_ids, NULL, NULL))
-   panic("failed to populate DT");
-
-   /* make sure ithat the reset controller is setup early */
+   /* make sure that the reset controller is setup early */
ralink_rst_init();
 
return 0;
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC 05/17] MIPS: BMIPS: Mask off timer IRQs when hot-unplugging a CPU

[Kevin Cernekee]

From: Jon Fraser 

CPU interrupts need to be disabled on a cpu being taken down.
When a cpu is hot-plugged out of the system the following sequence occurs.

On the CPU where the hotplug sequence was initiated:
cpu_down
_cpu_down {
__cpu_notify(CPU_DOWN_PREPARE
__stop_machine(take_cpu_down
wait for cpu to run disable code.
__cpu_die
}

On the CPU  being disabled:
take_cpu_down
__cpu_disable {
mp_ops->cpu_disable
bmips_cpu_disable
clear_c0_status(IE_IRQ5) (added)
cpu_notify(CPU_DYING...
}

Before the cpu_notifier is called with CPU_DYING, all interrupts on the
dying cpu must be disabled.  This guarantees that before tick_notify is
called with the CPU_DYING event and sets the clock device pointer to
NULL, there can not be any more clock interrupts.

When this wasn't done, an unfortunately-timed timer interrupt sometimes
caused hangs immediately prior to system suspend:

Debug PM is not enabled. To enable partial suspend, rebuild kernel with 
CONFIG_PM_DEBUG
Pass 1 out of 1,PM: Syncing filesystems ... mode=none, tp1=done.
1, flags=5, cycle_tp=, sleep=
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: suspend of devices complete after 54.199 msecs
PM: late suspend of devices complete after 0.172 msecs
Disabling non-boot CPUs ...
SMP: CPU1 is offline
INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 0, t=62537 
jiffies)
Call Trace:
[<804baa78>] dump_stack+0x8/0x34
[<8008a2d8>] __rcu_pending+0x4b8/0x55c
[<8008adf4>] rcu_check_callbacks+0x78/0x180
[<80037830>] update_process_times+0x40/0x6c
[<80072fe4>] tick_sched_timer+0x74/0xe4
[<80050180>] __run_hrtimer.clone.30+0x64/0x140
[<80051150>] hrtimer_interrupt+0x19c/0x4bc
[<8000cdb8>] c0_compare_interrupt+0x50/0x88
[<80081b18>] handle_irq_event_percpu+0x5c/0x2f4
[<80086490>] handle_percpu_irq+0x8c/0xc0
[<800811b4>] generic_handle_irq+0x34/0x54
[<800067dc>] do_IRQ+0x18/0x2c
[<8000375c>] plat_irq_dispatch+0xd0/0x128
[<80004a04>] ret_from_irq+0x0/0x4
[<80004c40>] r4k_wait+0x20/0x40
[<80006b6c>] cpu_idle+0x98/0xf0
[<805d3988>] start_kernel+0x424/0x440

Signed-off-by: Jon Fraser 
Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/smp-bmips.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index 887c3ea..f7b1bee 100644
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -375,6 +375,7 @@ static int bmips_cpu_disable(void)
 
set_cpu_online(cpu, false);
cpu_clear(cpu, cpu_callin_map);
+   clear_c0_status(IE_IRQ5);
 
local_flush_tlb_all();
local_flush_icache_range(0, ~0);
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 06/47] gpio-poweroff: Drop reference to pm_power_off from devicetree bindings

[Guenter Roeck]

pm_power_off is an implementation detail. Replace it with a more generic
description of the driver's functionality.

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Acked-by: Mark Rutland 
Acked-by: Andrew Lunn 
Signed-off-by: Guenter Roeck 
---
v2: No change

 Documentation/devicetree/bindings/gpio/gpio-poweroff.txt | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt 
b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
index d4eab92..c95a1a6 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
@@ -2,12 +2,12 @@ Driver a GPIO line that can be used to turn the power off.
 
 The driver supports both level triggered and edge triggered power off.
 At driver load time, the driver will request the given gpio line and
-install a pm_power_off handler. If the optional properties 'input' is
-not found, the GPIO line will be driven in the inactive
+install a handler to power off the system. If the optional properties
+'input' is not found, the GPIO line will be driven in the inactive
 state. Otherwise its configured as an input.
 
-When the pm_power_off is called, the gpio is configured as an output,
-and drive active, so triggering a level triggered power off
+When the the poweroff handler is called, the gpio is configured as an
+output, and drive active, so triggering a level triggered power off
 condition. This will also cause an inactive->active edge condition, so
 triggering positive edge triggered power off. After a delay of 100ms,
 the GPIO is set to inactive, thus causing an active->inactive edge,
@@ -24,7 +24,7 @@ Required properties:
 
 Optional properties:
 - input : Initially configure the GPIO line as an input. Only reconfigure
-  it to an output when the pm_power_off function is called. If this optional
+  it to an output when the poweroff handler is called. If this optional
   property is not specified, the GPIO is initialized as an output in its
   inactive state.
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 07/47] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings

[Guenter Roeck]

Replace reference to pm_power_off (which is an implementation detail)
and replace it with a more generic description of the driver's functionality.

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Acked-by: Mark Rutland 
Acked-by: Andrew Lunn 
Signed-off-by: Guenter Roeck 
---
v2: Drop implementation details

 Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt 
b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
index af25e77..c363d71 100644
--- a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
+++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
@@ -3,8 +3,7 @@
 QNAP NAS devices have a microcontroller controlling the main power
 supply. This microcontroller is connected to UART1 of the Kirkwood and
 Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the
-microcontroller to turn the power off. This driver adds a handler to
-pm_power_off which is called to turn the power off.
+microcontroller to turn the power off.
 
 Synology NAS devices use a similar scheme, but a different baud rate,
 9600, and a different character, '1'.
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 05/47] mfd: as3722: Drop reference to pm_power_off from devicetree bindings

[Guenter Roeck]

Devicetree bindings are supposed to be operating system independent
and should thus not describe how a specific functionality is implemented
in Linux.

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Acked-by: Mark Rutland 
Signed-off-by: Guenter Roeck 
---
v2: No change

 Documentation/devicetree/bindings/mfd/as3722.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/as3722.txt 
b/Documentation/devicetree/bindings/mfd/as3722.txt
index 4f64b2a..0b2a609 100644
--- a/Documentation/devicetree/bindings/mfd/as3722.txt
+++ b/Documentation/devicetree/bindings/mfd/as3722.txt
@@ -122,8 +122,7 @@ Following are properties of regulator subnode.
 
 Power-off:
 =
-AS3722 supports the system power off by turning off all its rail. This
-is provided through pm_power_off.
+AS3722 supports the system power off by turning off all its rails.
 The device node should have the following properties to enable this
 functionality
 ams,system-power-controller: Boolean, to enable the power off functionality
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 6/6] ARM: dts: add RK3288 suspend support

[zyw]

From: Chris Zhong 

add pmu_intmem node for suspend, add global_pwroff pinctrl.
The pmu_intmem is used to store the resume code.
global_pwroff is held low level at work, it would be pull to high
when entering suspend. PMICs can get this singal, then shut down
some power rails. So please reference the global_pwroff pinctrl
as part of the PMIC config.

Signed-off-by: Tony Xie 
Signed-off-by: Chris Zhong 

---

Changes in v3: None
Changes in v2:
- put "rockchip,rk3288-pmu-sram" to first

 arch/arm/boot/dts/rk3288.dtsi |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 5950b0a..fcbe929 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -241,6 +241,11 @@
status = "disabled";
};
 
+   pmu_intmem@ff72 {
+   compatible = "rockchip,rk3288-pmu-sram", "mmio-sram";
+   reg = <0xff72 0x4000>;
+   };
+
pmu: power-management@ff73 {
compatible = "rockchip,rk3288-pmu", "syscon";
reg = <0xff73 0x100>;
@@ -421,6 +426,12 @@
bias-disable;
};
 
+   sleep {
+   global_pwroff: global-pwroff {
+   rockchip,pins = <0 0 RK_FUNC_1 &pcfg_pull_none>;
+   };
+   };
+
i2c0 {
i2c0_xfer: i2c0-xfer {
rockchip,pins = <0 15 RK_FUNC_1 
&pcfg_pull_none>,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 5/6] ARM: rockchip: Add pmu-sram binding

[zyw]

From: Chris Zhong 

The pmu-sram is used to store resume code, suspend/resume need get the
address of it. Therefore add a binding and documentation for it.

Signed-off-by: Tony Xie 
Signed-off-by: Chris Zhong 
---

Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/arm/rockchip/pmu-sram.txt  |   15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt

diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt 
b/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
new file mode 100644
index 000..77284c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
@@ -0,0 +1,15 @@
+Rockchip SRAM for pmu:
+--
+
+The sram of pmu is used to store the function of resume from maskrom(the 1st
+level loader).
+
+Required node properties:
+- compatible : should be "rockchip,rk3288-pmu-sram"
+- reg : physical base address and the size of the registers window
+
+Example:
+   pmu_intmem@ff72 {
+   compatible = "rockchip,rk3288-pmu-sram", "mmio-sram";
+   reg = <0xff72 0x4000>;
+   };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/6] ARM: rockchip: add suspend and resume for RK3288

[zyw]

From: Chris Zhong 

It's a basic version of suspend and resume for rockchip, it only support RK3288
now.

Signed-off-by: Tony Xie 
Signed-off-by: Chris Zhong 

---

Changes in v3:
- move the pinmux of gpio6_c6 save and restore to pinctrl-rockchip

Changes in v2:
- add the regulator calls in prepare and finish.
- add the pinmux of gpio6_c6 save and restore

 arch/arm/mach-rockchip/Makefile   |1 +
 arch/arm/mach-rockchip/pm.c   |  316 +
 arch/arm/mach-rockchip/pm.h   |  102 
 arch/arm/mach-rockchip/rockchip.c |   11 +-
 arch/arm/mach-rockchip/sleep.S|   87 ++
 5 files changed, 515 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-rockchip/pm.c
 create mode 100644 arch/arm/mach-rockchip/pm.h
 create mode 100644 arch/arm/mach-rockchip/sleep.S

diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index b29d8ea..5c3a9b2 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -1,4 +1,5 @@
 CFLAGS_platsmp.o := -march=armv7-a
 
 obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip.o
+obj-$(CONFIG_PM_SLEEP) += pm.o sleep.o
 obj-$(CONFIG_SMP) += headsmp.o platsmp.o
diff --git a/arch/arm/mach-rockchip/pm.c b/arch/arm/mach-rockchip/pm.c
new file mode 100644
index 000..e0d6594
--- /dev/null
+++ b/arch/arm/mach-rockchip/pm.c
@@ -0,0 +1,316 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Tony Xie 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "pm.h"
+
+struct rockchip_pm_device_id {
+   const char *compatible;
+   const struct platform_suspend_ops *ops;
+   int (*init)(void);
+};
+
+static char bootram_save_data[SZ_4K];
+
+static void __iomem *rk3288_bootram_base;
+static phys_addr_t rk3288_bootram_phy;
+
+static struct regmap *pmu_regmap;
+static struct regmap *grf_regmap;
+static struct regmap *sgrf_regmap;
+
+static inline void rk3288_copy_data_to_sram(void)
+{
+   u32 resume_code_size = (u32)&rkpm_bootdata_cpu_code -
+  (u32)rockchip_slp_cpu_resume + 4;
+
+   /* save root sram data in ddr mem */
+   memcpy(rk3288_bootram_base, bootram_save_data, SZ_4K);
+   /* move resume code and data to bootsram */
+   memcpy(rk3288_bootram_base, rockchip_slp_cpu_resume,
+  resume_code_size);
+}
+
+static inline void rk3288_restore_original_sram(void)
+{
+   memcpy(bootram_save_data, rk3288_bootram_base, SZ_4K);
+}
+
+static inline u32 rk3288_l2_config(void)
+{
+   u32 l2ctlr;
+
+   asm("mrc p15, 1, %0, c9, c0, 2" : "=r" (l2ctlr));
+   return l2ctlr;
+}
+
+static void rk3288_fill_in_bootram(u32 level)
+{
+   rkpm_bootdata_cpusp = rk3288_bootram_phy + (SZ_4K - 8);
+   rkpm_bootdata_cpu_code = virt_to_phys(cpu_resume);
+
+   rkpm_bootdata_l2ctlr_f  = 1;
+   rkpm_bootdata_l2ctlr = rk3288_l2_config();
+
+   if (level == ROCKCHIP_ARM_OFF_LOGIC_DEEP) {
+   /*
+   * In this mode the SDRAM power domain will be off,
+   * so it need to be resumed,
+   * but now the sdram resume code is not ready.
+   * i have to set "rkpm_bootdata_ddr_code" 0.
+   */
+   rkpm_bootdata_ddr_code = 0;
+   } else {
+   rkpm_bootdata_ddr_code = 0;
+   }
+
+   rk3288_copy_data_to_sram();
+}
+
+static u32 rk3288_pmu_pwr_mode_con;
+static u32 rk3288_sgrf_soc_con0;
+
+static void rk3288_slp_mode_set(int level)
+{
+   u32 mode_set, mode_set1;
+
+   regmap_read(sgrf_regmap, RK3288_SGRF_SOC_CON0, &rk3288_sgrf_soc_con0);
+
+   regmap_read(pmu_regmap, RK3288_PMU_PWRMODE_CON,
+   &rk3288_pmu_pwr_mode_con);
+
+   /* set bit 8 so that system will resume to FAST_BOOT_ADDR */
+   regmap_write(sgrf_regmap, RK3288_SGRF_SOC_CON0,
+BIT(SGRF_FAST_BOOT_EN) | BIT(SGRF_FAST_BOOT_EN + 16));
+
+   /* booting address of resuming system is from this register value */
+   regmap_write(sgrf_regmap, RK3288_SGRF_FAST_BOOT_ADDR,
+rk3288_bootram_phy);
+
+   regmap_write(pmu_regmap, RK3288_PMU_WAKEUP_CFG1,
+PMU_ARMINT_WAKEUP_EN);
+
+   mode_set = BIT(PMU_GLOBAL_INT_DISABLE) | BIT(PMU_L2FLUSH_EN) |
+  BIT(PMU_SREF0_ENTER_EN) | BIT(PMU_SREF1_ENTER_EN) |
+  BIT(PMU_DDR0_GATING_EN) | BIT(PMU_DDR1_GATING_EN) |
+  

[PATCH v3 3/6] clk: rockchip: RK3288: add suspend and resume

[zyw]

From: Chris Zhong 

save and restore some clks, which might be changed in suspend.

Signed-off-by: Tony Xie 
Signed-off-by: Chris Zhong 

---

Changes in v3: None
Changes in v2:
- __raw_readl/__raw_writel replaced by readl_relaxed/writel_relaxed

 drivers/clk/rockchip/clk-rk3288.c |   63 +
 1 file changed, 63 insertions(+)

diff --git a/drivers/clk/rockchip/clk-rk3288.c 
b/drivers/clk/rockchip/clk-rk3288.c
index b22a2d2..415b928 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "clk.h"
 
@@ -680,6 +681,67 @@ static struct rockchip_clk_branch rk3288_clk_branches[] 
__initdata = {
GATE(0, "pclk_isp_in", "ext_isp", 0, RK3288_CLKGATE_CON(16), 3, GFLAGS),
 };
 
+#ifdef CONFIG_PM_SLEEP
+static void __iomem *rk3288_cru_base;
+static const int rk3288_saved_cru_reg_ids[] = {
+   RK3288_MODE_CON,
+   RK3288_CLKSEL_CON(0),
+   RK3288_CLKSEL_CON(1),
+   RK3288_CLKSEL_CON(10),
+   RK3288_CLKSEL_CON(33),
+   RK3288_CLKSEL_CON(37),
+};
+
+static u32 rk3288_saved_cru_regs[ARRAY_SIZE(rk3288_saved_cru_reg_ids)];
+
+/*
+ * cru will be set in maskrom when system wake up from fastboot
+ * mode in suspend,
+ * so the operation is saving the changed regs.
+ * The apll/cpll/gpll will be set into slow mode in maskrom.
+ * It is mean that resume code run in 24m quit slowly!
+ * so we must resume these plls as soon as possible.
+ */
+static int rk3288_clk_suspend(void)
+{
+   int i, reg_id;
+
+   for (i = 0; i < ARRAY_SIZE(rk3288_saved_cru_reg_ids); i++) {
+   reg_id = rk3288_saved_cru_reg_ids[i];
+
+   rk3288_saved_cru_regs[i] =
+   readl_relaxed(rk3288_cru_base + reg_id);
+   }
+   return 0;
+}
+
+static void rk3288_clk_resume(void)
+{
+   int i, reg_id;
+
+   for (i = ARRAY_SIZE(rk3288_saved_cru_reg_ids) - 1; i >= 0; i--) {
+   reg_id = rk3288_saved_cru_reg_ids[i];
+
+   writel_relaxed(rk3288_saved_cru_regs[i] | 0x,
+  rk3288_cru_base + reg_id);
+   }
+}
+
+static struct syscore_ops rk3288_clk_syscore_ops = {
+   .suspend = rk3288_clk_suspend,
+   .resume = rk3288_clk_resume,
+};
+
+static void rk3288_clk_sleep_init(void __iomem *reg_base)
+{
+   rk3288_cru_base = reg_base;
+   register_syscore_ops(&rk3288_clk_syscore_ops);
+}
+
+#else /* CONFIG_PM_SLEEP */
+static void rk3288_clk_sleep_init(void __iomem *reg_base) {}
+#endif
+
 static void __init rk3288_clk_init(struct device_node *np)
 {
void __iomem *reg_base;
@@ -713,5 +775,6 @@ static void __init rk3288_clk_init(struct device_node *np)
 
rockchip_register_softrst(np, 9, reg_base + RK3288_SOFTRST_CON(0),
  ROCKCHIP_SOFTRST_HIWORD_MASK);
+   rk3288_clk_sleep_init(reg_base);
 }
 CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288-cru", rk3288_clk_init);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/6] pinctrl: rockchip: save and restore gpio6_c6 pinmux in suspend/resume

[zyw]

From: Chris Zhong 

Save and restore the gpio6_c6 pinmux setting, since Maskrom of RK3288
would modify it to sdmmc0_det, so it need to be restored to the correct
setting after resume from Maskrom.

Signed-off-by: Chris Zhong 
---

Changes in v3: None
Changes in v2: None

 drivers/pinctrl/pinctrl-rockchip.c |   30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index d384d99..85134e4 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -1796,26 +1796,54 @@ static struct rockchip_pin_ctrl 
*rockchip_pinctrl_get_soc_data(
 }
 
 #ifdef CONFIG_PM
+
+#define RK3288_GRF_GPIO6C_IOMUX0x64
+#define GPIO6C6_SEL_WRITE_ENABLE   BIT(28)
+
+static u32 rk3288_grf_gpio6c_iomux;
+
 static int rockchip_pinctrl_suspend(struct platform_device *pdev,
pm_message_t state)
 {
struct rockchip_pinctrl *info;
+   int ret;
 
info = platform_get_drvdata(pdev);
if (!info)
return -EINVAL;
 
-   return pinctrl_force_sleep(info->pctl_dev);
+   ret = pinctrl_force_sleep(info->pctl_dev);
+   if (ret)
+   return ret;
+
+   /*
+* RK3288 GPIO6_C6 mux would be modified by Maskrom when resume, so save
+* the setting here, and restore it at resume.
+*/
+   if (info->ctrl->type == RK3288) {
+   ret = regmap_read(info->regmap_base, RK3288_GRF_GPIO6C_IOMUX,
+ &rk3288_grf_gpio6c_iomux);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
 }
 
 static int rockchip_pinctrl_resume(struct platform_device *pdev)
 {
struct rockchip_pinctrl *info;
+   int ret;
 
info = platform_get_drvdata(pdev);
if (!info)
return -EINVAL;
 
+   ret = regmap_write(info->regmap_base, RK3288_GRF_GPIO6C_IOMUX,
+  rk3288_grf_gpio6c_iomux | GPIO6C6_SEL_WRITE_ENABLE);
+   if (ret)
+   return ret;
+
return pinctrl_force_default(info->pctl_dev);
 }
 #endif
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/6] pinctrl: rockchip: add suspend/resume functions

[zyw]

From: Chris 

support suspend/resume of pinctrl, it allows handling sleep mode
for hogged pins in pinctrl

Signed-off-by: Chris 
Signed-off-by: Chris Zhong 
---

Changes in v3: None
Changes in v2: None

 drivers/pinctrl/pinctrl-rockchip.c |   29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index d0f3c18..d384d99 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -1795,6 +1795,31 @@ static struct rockchip_pin_ctrl 
*rockchip_pinctrl_get_soc_data(
return ctrl;
 }
 
+#ifdef CONFIG_PM
+static int rockchip_pinctrl_suspend(struct platform_device *pdev,
+   pm_message_t state)
+{
+   struct rockchip_pinctrl *info;
+
+   info = platform_get_drvdata(pdev);
+   if (!info)
+   return -EINVAL;
+
+   return pinctrl_force_sleep(info->pctl_dev);
+}
+
+static int rockchip_pinctrl_resume(struct platform_device *pdev)
+{
+   struct rockchip_pinctrl *info;
+
+   info = platform_get_drvdata(pdev);
+   if (!info)
+   return -EINVAL;
+
+   return pinctrl_force_default(info->pctl_dev);
+}
+#endif
+
 static int rockchip_pinctrl_probe(struct platform_device *pdev)
 {
struct rockchip_pinctrl *info;
@@ -2010,6 +2035,10 @@ static struct platform_driver rockchip_pinctrl_driver = {
.owner  = THIS_MODULE,
.of_match_table = rockchip_pinctrl_dt_match,
},
+   #ifdef CONFIG_PM
+   .suspend = rockchip_pinctrl_suspend,
+   .resume = rockchip_pinctrl_resume,
+   #endif
 };
 
 static int __init rockchip_pinctrl_drv_register(void)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/6] add suspend support for RK3288

[zyw]

From: Chris Zhong 

this is the 1st version of suspend. RK3288 can shut down the cpu, gpu and
other device controllers in suspend, and it will pull the GLOBAL_PWROFF pin
to high in the final stage of the process of suspend, pull the pin to low again
when resume.

Changes in v3:
- move the pinmux of gpio6_c6 save and restore to pinctrl-rockchip

Changes in v2:
- __raw_readl/__raw_writel replaced by readl_relaxed/writel_relaxed
- add the regulator calls in prepare and finish.
- add the pinmux of gpio6_c6 save and restore
- put "rockchip,rk3288-pmu-sram" to first

Chris (1):
  pinctrl: rockchip: add suspend/resume functions

Chris Zhong (5):
  pinctrl: rockchip: save and restore gpio6_c6 pinmux in suspend/resume
  clk: rockchip: RK3288: add suspend and resume
  ARM: rockchip: add suspend and resume for RK3288
  ARM: rockchip: Add pmu-sram binding
  ARM: dts: add RK3288 suspend support

 .../devicetree/bindings/arm/rockchip/pmu-sram.txt  |   15 +
 arch/arm/boot/dts/rk3288.dtsi  |   11 +
 arch/arm/mach-rockchip/Makefile|1 +
 arch/arm/mach-rockchip/pm.c|  316 
 arch/arm/mach-rockchip/pm.h|  102 +++
 arch/arm/mach-rockchip/rockchip.c  |   11 +-
 arch/arm/mach-rockchip/sleep.S |   87 ++
 drivers/clk/rockchip/clk-rk3288.c  |   63 
 drivers/pinctrl/pinctrl-rockchip.c |   57 
 9 files changed, 661 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
 create mode 100644 arch/arm/mach-rockchip/pm.c
 create mode 100644 arch/arm/mach-rockchip/pm.h
 create mode 100644 arch/arm/mach-rockchip/sleep.S

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 2/2] mtd: nand: add sunxi NFC dt bindings doc

[Brian Norris]

Hi Boris,

On Mon, Oct 20, 2014 at 01:45:20PM +0200, Boris Brezillon wrote:
> Add the sunxi NAND Flash Controller dt bindings documentation.
> 
> Signed-off-by: Boris Brezillon 
> ---
>  .../devicetree/bindings/mtd/sunxi-nand.txt | 45 
> ++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/sunxi-nand.txt
> 
> diff --git a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt 
> b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
> new file mode 100644
> index 000..0273adb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
> @@ -0,0 +1,45 @@
> +Allwinner NAND Flash Controller (NFC)
> +
> +Required properties:
> +- compatible : "allwinner,sun4i-a10-nand".
> +- reg : shall contain registers location and length for data and reg.
> +- interrupts : shall define the nand controller interrupt.
> +- #address-cells: shall be set to 1. Encode the nand CS.
> +- #size-cells : shall be set to 0.
> +- clocks : shall reference nand controller clocks.
> +- clock-names : nand controller internal clock names. Shall contain :
> +* "ahb" : AHB gating clock
> +* "mod" : nand controller clock
> +
> +Optional children nodes:
> +Children nodes represent the available nand chips.
> +
> +Optional properties:
> +- allwinner,rb : shall contain the native Ready/Busy ids.
> + or
> +- rb-gpios : shall contain the gpios used as R/B pins.

I think you're relying on a named GPIO in your driver ("nand-rb"). That
should be documented here.

> +- nand-ecc-mode : one of the supported ECC modes ("hw", "hw_syndrome", 
> "soft",
> +  "soft_bch" or "none")

I think you're utilizing an undocumented 'nand-name' property for this
node in your driver too. Please document it. (That also goes for any
other undocumented properties I may have missed.)

> +
> +see Documentation/devicetree/mtd/nand.txt for generic bindings.
> +
> +
> +Examples:
> +nfc: nand@01c03000 {
> + compatible = "allwinner,sun4i-a10-nand";
> + reg = <0x01c03000 0x1000>;
> + interrupts = <0 37 1>;
> + clocks = <&ahb_gates 13>, <&nand_clk>;
> + clock-names = "ahb", "mod";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&nand_pins_a &nand_cs0_pins_a &nand_rb0_pins_a>;
> + status = "okay";
> +
> + nand@0 {
> + reg = <0>;
> + allwinner,rb = <0>;
> + nand-ecc-mode = "soft_bch";
> + };
> +};

Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/2] mtd: nand: add sunxi NAND flash controller support

[Brian Norris]

On Mon, Oct 20, 2014 at 01:45:19PM +0200, Boris Brezillon wrote:
> Add support for the sunxi NAND Flash Controller (NFC).
> 
> Signed-off-by: Boris Brezillon 

This driver looks mostly good. Sorry for the delays, and thanks for the
patience.

> ---
>  drivers/mtd/nand/Kconfig  |6 +
>  drivers/mtd/nand/Makefile |1 +
>  drivers/mtd/nand/sunxi_nand.c | 1400 
> +
>  3 files changed, 1407 insertions(+)
>  create mode 100644 drivers/mtd/nand/sunxi_nand.c
> 
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index dd10646..4c51d2c 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -516,4 +516,10 @@ config MTD_NAND_XWAY
> Enables support for NAND Flash chips on Lantiq XWAY SoCs. NAND is 
> attached
> to the External Bus Unit (EBU).
>  
> +config MTD_NAND_SUNXI
> + tristate "Support for NAND on Allwinner SoCs"
> + depends on ARCH_SUNXI
> + help
> +   Enables support for NAND Flash chips on Allwinner SoCs.
> +
>  endif # MTD_NAND
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index 9c847e4..bd38f21 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -50,5 +50,6 @@ obj-$(CONFIG_MTD_NAND_JZ4740)   += jz4740_nand.o
>  obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/
>  obj-$(CONFIG_MTD_NAND_XWAY)  += xway_nand.o
>  obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/
> +obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o
>  
>  nand-objs := nand_base.o nand_bbt.o nand_timings.o
> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> new file mode 100644
> index 000..c4e0559
> --- /dev/null
> +++ b/drivers/mtd/nand/sunxi_nand.c
> @@ -0,0 +1,1400 @@
> +/*
> + * Copyright (C) 2013 Boris BREZILLON 
> + *
> + * Derived from:
> + *   https://github.com/yuq/sunxi-nfc-mtd
> + *   Copyright (C) 2013 Qiang Yu 
> + *
> + *   https://github.com/hno/Allwinner-Info
> + *   Copyright (C) 2013 Henrik Nordström 
> + *
> + *   Copyright (C) 2013 Dmitriy B. 
> + *   Copyright (C) 2013 Sergey Lapin 
> + *
> + * 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; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * 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.
> + */
> +
> +#define pr_fmt(fmt)  KBUILD_MODNAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define NFC_REG_CTL  0x
> +#define NFC_REG_ST   0x0004
> +#define NFC_REG_INT  0x0008
> +#define NFC_REG_TIMING_CTL   0x000C
> +#define NFC_REG_TIMING_CFG   0x0010
> +#define NFC_REG_ADDR_LOW 0x0014
> +#define NFC_REG_ADDR_HIGH0x0018
> +#define NFC_REG_SECTOR_NUM   0x001C
> +#define NFC_REG_CNT  0x0020
> +#define NFC_REG_CMD  0x0024
> +#define NFC_REG_RCMD_SET 0x0028
> +#define NFC_REG_WCMD_SET 0x002C
> +#define NFC_REG_IO_DATA  0x0030
> +#define NFC_REG_ECC_CTL  0x0034
> +#define NFC_REG_ECC_ST   0x0038
> +#define NFC_REG_DEBUG0x003C
> +#define NFC_REG_ECC_CNT0 0x0040
> +#define NFC_REG_ECC_CNT1 0x0044
> +#define NFC_REG_ECC_CNT2 0x0048
> +#define NFC_REG_ECC_CNT3 0x004c
> +#define NFC_REG_USER_DATA_BASE   0x0050
> +#define NFC_REG_SPARE_AREA   0x00A0
> +#define NFC_RAM0_BASE0x0400
> +#define NFC_RAM1_BASE0x0800
> +
> +/* define bit use in NFC_CTL */
> +#define NFC_EN   BIT(0)
> +#define NFC_RESETBIT(1)
> +#define NFC_BUS_WIDYHBIT(2)
> +#define NFC_RB_SEL   BIT(3)
> +#define NFC_CE_SEL   GENMASK(26, 24)
> +#define NFC_CE_CTL   BIT(6)
> +#define NFC_CE_CTL1  BIT(7)
> +#define NFC_PAGE_SIZEGENMASK(11, 8)
> +#define NFC_SAM  BIT(12)
> +#define NFC_RAM_METHOD   BIT(14)
> +#define NFC_DEBUG_CTLBIT(31)
> +
> +/* define bit use in NFC_ST */
> +#define NFC_RB_B2R   BIT(0)
> +#define NFC_CMD_INT_FLAG BIT(1)
> +#define NFC_DMA_INT_FLAG BIT(2)
> +#define NFC_CMD_FIFO_STATUS  BIT(3)
> +#define NFC_STA  BIT(4)
> +#define NFC_NATCH_INT_FLAG   BIT(5)
> +#define NFC_RB_STATE0BIT(8)
> +#define NFC_RB_STATE1BIT(9)
> +#define NFC_RB_STATE2BIT(10)
> +#define NFC_RB_STATE3BIT(11)
> +
> +/* define bit 

RE: [PATCHv5 1/6] ARM: dts: Add SoC level device tree support for LS1021A

[Jingchang Lu]

>-Original Message-
>From: Shawn Guo [mailto:shawn@linaro.org]
>Sent: Sunday, October 19, 2014 9:37 AM
>To: Lu Jingchang-B35083
>Cc: a...@arndb.de; mark.rutl...@arm.com; linux-arm-
>ker...@lists.infradead.org; devicetree@vger.kernel.org; Lu Jingchang-
>B35083; Badola Nikhil-B46172; Zhao Chenhui-B35336; Gupta Suresh-B42813;
>Leekha Shaveta-B20052; Gupta Ruchika-R66431; Sharma Bhupesh-B45370; Fu
>Chao-B44548; Xiubo Li-B47053
>Subject: Re: [PATCHv5 1/6] ARM: dts: Add SoC level device tree support for
>LS1021A
>
>On Mon, Oct 13, 2014 at 05:35:58PM +0800, Jingchang Lu wrote:
>> +/ {
>> +compatible = "fsl,ls1021a";
>> +interrupt-parent = <&gic>;
>> +
>> +aliases {
>> +serial0 = &lpuart0;
>> +serial1 = &lpuart1;
>> +serial2 = &lpuart2;
>> +serial3 = &lpuart3;
>> +serial4 = &lpuart4;
>> +serial5 = &lpuart5;
>> +sysclk = &sysclk;
>
>What is this sysclk aliase used for?
The sysclk alias is used by dtb fixup stage in u-boot to set the proper clk 
frequency
for its configurable. The sysclk is compatible to "fixed-clock" but there may 
be more
than one "fixed-clock" source and only the sysclk is desired, so an alias is 
add to
located it exclusively. Thanks.

>
>> +};
>
>Bad indent.
>
>> +
>> +cpus {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +cpu@f00 {
>> +compatible = "arm,cortex-a7";
>> +device_type = "cpu";
>> +reg = <0xf00>;
>> +};
>> +
>> +cpu@f01 {
>> +compatible = "arm,cortex-a7";
>> +device_type = "cpu";
>> +reg = <0xf01>;
>> +};
>> +};
>> +
>> +timer {
>> +compatible = "arm,armv7-timer";
>> +interrupts = IRQ_TYPE_LEVEL_LOW)>,
>> + IRQ_TYPE_LEVEL_LOW)>,
>> + IRQ_TYPE_LEVEL_LOW)>,
>> + IRQ_TYPE_LEVEL_LOW)>;
>
>I like this indent style ...
>
>> +};
>> +
>> +pmu {
>> +compatible = "arm,cortex-a7-pmu";
>> +interrupts = ,
>> +;
>
>... not this style.  Please fix such indents through the file.

I will, thanks.

Best Regards,
Jingchang

>
>> +};
>
>Shawn
N�r��yb�X��ǧv�^�)޺{.n�+���z��z��z)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥

Re: [PATCH v8] coresight: bindings for coresight drivers

[Rob Herring]

On Tue, Oct 21, 2014 at 5:13 AM,   wrote:
> From: Mathieu Poirier 
>
> Coresight IP blocks allow for the support of HW assisted tracing
> on ARM SoCs.  Bindings for the currently available blocks are
> presented herein.
>
> Signed-off-by: Pratik Patel 
> Signed-off-by: Mathieu Poirier 

Didn't I give you a reviewed-by on this already?

Rob

> ---
>  .../devicetree/bindings/arm/coresight.txt  | 203 
> +
>  1 file changed, 203 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/coresight.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt 
> b/Documentation/devicetree/bindings/arm/coresight.txt
> new file mode 100644
> index 000..96dd947
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> @@ -0,0 +1,203 @@
> +* CoreSight Components:
> +
> +CoreSight components are compliant with the ARM CoreSight architecture
> +specification and can be connected in various topologies to suit a particular
> +SoCs tracing needs. These trace components can generally be classified as 
> sinks,
> +links and sources. Trace data produced by one or more sources flows through 
> the
> +intermediate links connecting the source to the currently selected sink. Each
> +CoreSight component device should use these properties to describe its 
> hardware
> +characteristcs.
> +
> +* Required properties for all components *except* non-configurable 
> replicators:
> +
> +   * compatible: These have to be supplemented with "arm,primecell" as
> + drivers are using the AMBA bus interface.  Possible values include:
> +   - "arm,coresight-etb10", "arm,primecell";
> +   - "arm,coresight-tpiu", "arm,primecell";
> +   - "arm,coresight-tmc", "arm,primecell";
> +   - "arm,coresight-funnel", "arm,primecell";
> +   - "arm,coresight-etm3x", "arm,primecell";
> +
> +   * reg: physical base address and length of the register
> + set(s) of the component.
> +
> +   * clocks: the clock associated to this component.
> +
> +   * clock-names: the name of the clock as referenced by the code.
> + Since we are using the AMBA framework, the name should be
> + "apb_pclk".
> +
> +   * port or ports: The representation of the component's port
> + layout using the generic DT graph presentation found in
> + "bindings/graph.txt".
> +
> +* Required properties for devices that don't show up on the AMBA bus, such as
> +  non-configurable replicators:
> +
> +   * compatible: Currently supported value is (note the absence of the
> + AMBA markee):
> +   - "arm,coresight-replicator"
> +
> +   * id: a unique number that will identify this replicator.
> +
> +   * port or ports: same as above.
> +
> +* Optional properties for ETM/PTMs:
> +
> +   * arm,cp14: must be present if the system accesses ETM/PTM management 
> registers
> + via co-processor 14.
> +
> +   * cpu: the cpu phandle this ETM/PTM is affined to. When omitted the 
> source is
> + considered to belong to CPU0.
> +
> +* Optional property for TMC:
> +
> +   * arm,buffer-size: size of contiguous buffer space for TMC ETR
> +(embedded trace router)
> +
> +
> +Example:
> +
> +1. Sinks
> +   etb@0,2001 {
> +   compatible = "arm,coresight-etb10", "arm,primecell";
> +   reg = <0 0x2001 0 0x1000>;
> +
> +   coresight-default-sink;
> +   clocks = <&oscclk6a>;
> +   clock-names = "apb_pclk";
> +   port {
> +   etb_in_port: endpoint@0 {
> +   slave-mode;
> +   remote-endpoint = <&replicator_out_port0>;
> +   };
> +   };
> +   };
> +
> +   tpiu@0,2003 {
> +   compatible = "arm,coresight-tpiu", "arm,primecell";
> +   reg = <0 0x2003 0 0x1000>;
> +
> +   clocks = <&oscclk6a>;
> +   clock-names = "apb_pclk";
> +   port {
> +   tpiu_in_port: endpoint@0 {
> +   slave-mode;
> +   remote-endpoint = <&replicator_out_port1>;
> +   };
> +   };
> +   };
> +
> +2. Links
> +   replicator {
> +   /* non-configurable replicators don't show up on the
> +* AMBA bus.  As such no need to add "arm,primecell".
> +*/
> +   compatible = "arm,coresight-replicator";
> +   /* this will show up in debugfs as "0.replicator" */
> +   id = <0>;
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   /* replicator output ports */
> +   port@0 {
> +   reg = <0>;
> +

Re: [PATCH 2/6] arm64: Add DTS support for Spreadtrum's Shark64 SoC

[Lyra Zhang]

Hi, Arnd

This problem have been solved, and was submitted in v2.
Thanks for your answer to the question(which Orson asked for me) about
this on Freenode.

Best regards,
Lyra

2014-10-21 3:00 GMT+08:00 Arnd Bergmann :
> On Wednesday 15 October 2014 11:17:07 Lyra Zhang wrote:
>> Hi, Arnd
>
> Hi Lyra,
>
> Sorry for the late reply, I've been away travelling and am just
> now catching up on email. Have you found a solution or do
> you still need help with this?
>
> Arnd
>
>> 2014-09-29 21:47 GMT+08:00 Arnd Bergmann :
>> > On Monday 29 September 2014 20:04:49 zhang.l...@gmail.com wrote:
>> >> +
>> >> +/memreserve/ 0x8000 0x0001;
>> >
>> > Maybe add a comment explaining why it is reserved?
>> >
>> >> + chosen {
>> >> + bootargs = "earlycon=serial_sprd,0x7000";
>> >> +  };
>> >
>> > Just remove this for now, the command line should really be set by the
>> > boot loader, not hardcoded in the dts file.
>> >
>> > IIRC, the earlycon=... syntax is not recommended on DT based systems,
>> > better use the "stdout-path" syntax instead.
>> >
>>
>> I have tried to use  "stdout-path" instead of "bootargs= "earlycon=
>> ..." like below :
>>
>> / {
>>  ...
>>
>>  chosen {
>>  stdout-path = "/serial@7000";
>>   };
>>
>>  uart0: serial@7000 {
>>  status="okay";
>>  };
>>   ...
>> };
>>
>> But then there is nothing output information on serial console.(I have
>> been testing in Fast Model)
>>
>>
>> I saw the below code in init/main.c
>>
>> /* Check for early params. */
>> static int __init do_early_param(char *param, char *val, const char *unused)
>> {
>> const struct obs_kernel_param *p;
>>
>> for (p = __setup_start; p < __setup_end; p++) {
>> if ((p->early && parameq(param, p->str)) ||
>>(strcmp(param, "console") == 0 &&
>> strcmp(p->str, "earlycon") == 0)
>> ) {
>> if (p->setup_func(val) != 0)
>> pr_warn("Malformed early option '%s'\n", param);
>> }
>> }
>> /* We accept everything at this stage. */
>> return 0;
>> }
>>
>> And I saw a patch from Grant Likely, he had a comment in it :
>> "If the devicetree specifies a serial port as a stdout device, then the
>> kernel can use it as the default console if nothing else was selected on
>> the command line. For any serial port that uses the uart_add_one_port()
>> feature, the uart_add_one_port() has all the information needed to
>> automatically enable the console device, which is what this patch does."
>>
>> So, I guess that the reason why I can't see any output information on
>> console after using "stdout-path" instead of "earlycon" is that I
>> haven't a driver of Spreadtrum's serial, and dose not use  the
>> uart_add_one_port() feature.
>>
>> I don't know is correct what I guess.
>>
>> Could you give me some suggestions to solve this problem?
>>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] core drm support for Rockchip SoCs

[Mark yao]

Hi, Dave

The following changes since commit bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9:

   Linux 3.17 (2014-10-05 12:23:04 -0700)

are available in the git repository at:

   https://github.com/markyzq/kernel-drm-rockchip.git  drmrockchip

for you to fetch changes up to 45bb5f4e7e82b30e9e7069c73441413680c9a59f:

   dt-bindings: video: Add documentation for rockchip vop (2014-10-17
16:39:31 +0800)


Mark yao (3):
   drm: rockchip: Add basic drm driver
   dt-bindings: video: Add for rockchip display subsytem
   dt-bindings: video: Add documentation for rockchip vop

  .../devicetree/bindings/video/rockchip-drm.txt |   19 +
  .../devicetree/bindings/video/rockchip-vop.txt |   58 +
  drivers/gpu/drm/Kconfig|2 +
  drivers/gpu/drm/Makefile   |1 +
  drivers/gpu/drm/rockchip/Kconfig   |   17 +
  drivers/gpu/drm/rockchip/Makefile  |8 +
  drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  449 ++
  drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   54 +
  drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  200 +++
  drivers/gpu/drm/rockchip/rockchip_drm_fb.h |   28 +
  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |  210 +++
  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h  |   20 +
  drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  293 
  drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   54 +
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1427 
  drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  196 +++
  16 files changed, 3036 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/video/rockchip-drm.txt
  create mode 100644 Documentation/devicetree/bindings/video/rockchip-vop.txt
  create mode 100644 drivers/gpu/drm/rockchip/Kconfig
  create mode 100644 drivers/gpu/drm/rockchip/Makefile
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/2] ARM: dts: socfpga: Fix SD card detect

[Doug Anderson]

Mark,

On Mon, Oct 20, 2014 at 3:41 PM, Mark Rutland  wrote:
> On Mon, Oct 20, 2014 at 08:26:55PM +0100, Doug Anderson wrote:
>> Mark,
>>
>> On Mon, Oct 20, 2014 at 11:41 AM, Mark Rutland  wrote:
>> > On Mon, Oct 20, 2014 at 04:31:18PM +0100, dingu...@opensource.altera.com 
>> > wrote:
>> >> From: Dinh Nguyen 
>> >>
>> >> Without this patch, the booting the SOCFPGA platform would hang at the
>> >> SDMMC driver loading. There were 2 patches that caused this to happen:
>> >>
>> >> - Patch 9795a846e10 "mmc: dw_mmc: remove dw_mci_of_cd_gpio/wp_gpio()" 
>> >> removed
>> >>   looking for "cd-gpios", since mmc_of_parse was getting called.
>> >> - Patch 3cf890fc42b "mmc: dw_mmc: Pass back errors from mmc_of_parse()" 
>> >> would
>> >>   hang the system at the SDMMC driver loading.
>> >
>> > Regardless of which patches caused the issue, the existing DTB should
>> > continue to function. This is a kernel bug, not a DTB bug.
>>
>> Right.  The kernel bug is that there is no "dtb fixup" stage of the
>> kernel to fix up old dtbs with this dtb bug.
>>
>> Said another way:
>>
>> 1. The old dtb was (possibly) not specifying the cd-gpio properly.
>>
>> 2. The kernel had a bug where it was ignoring that error.  Things may
>> have been working because of some other side effect (maybe polling was
>> working).
>>
>> 3. If we fix the kernel bug, what should we do?  The only sensible
>> thing (if we need to support old DTB with no changes) is to add a DTB
>> fixup stage.
>>
>> ...or did someone add that stage and I missed it?
>
> Unfortunately, we have no generic DTB fixup stage currently.

Right.  ...and that's the bug.

I think we may need to modify the general inclination to respond to
dts change requests with "the DTS can't have a bug in it".  DTS files
can indeed have bugs in it.  In this case the dts file was claiming
that the card detect GPIO was a GPIO on a controller that the same dts
claimed was "disabled".  If that's not a bug in the DTS I'm not sure
what it is.

There are all sorts of broken ways that we could work around this in
the driver.  We could pretend that EPROBE_DEFER really meant "I'm all
good".  We could add a special case for this particular board in
dw_mmc (do we check the overall device tree compatible string?).  We
could do all sorts of hacks.  None of them are right.  The "right"
behavior if we really care about maintaining compatbility with old DTB
files is to add a fixup stage for this particular broken board.

Given that no such fixup stage exists, if someone really wants old DTB
files to work then we should add one.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 4/4] crypto: Add Allwinner Security System crypto accelerator

[Joe Perches]

On Tue, 2014-10-21 at 02:28 +0300, Vladimir Zapolskiy wrote:
> On 19.10.2014 17:16, LABBE Corentin wrote:
> > Add support for the Security System included in Allwinner SoC A20.
> > The Security System is a hardware cryptographic accelerator that support 
> > AES/MD5/SHA1/DES/3DES/PRNG algorithms.
[]
> > diff --git a/drivers/crypto/sunxi-ss/sunxi-ss-core.c 
> > b/drivers/crypto/sunxi-ss/sunxi-ss-core.c
[]
> > +   cr = clk_get_rate(ss->busclk);
> > +   if (cr >= cr_ahb)
> > +   dev_dbg(&pdev->dev, "Clock bus %lu (%lu MHz) (must be >= 
> > %lu)\n",
> > +   cr, cr / 100, cr_ahb);
> > +   else
> > +   dev_warn(&pdev->dev, "Clock bus %lu (%lu MHz) (must be >= 
> > %lu)\n",
> > +   cr, cr / 100, cr_ahb);
> 
> See next comment.
> 
> > +   cr = clk_get_rate(ss->ssclk);
> > +   if (cr <= cr_mod)
> > +   if (cr < cr_mod)
> > +   dev_info(&pdev->dev, "Clock ss %lu (%lu MHz) (must be 
> > <= %lu)\n",
> > +   cr, cr / 100, cr_mod);
> > +   else
> > +   dev_dbg(&pdev->dev, "Clock ss %lu (%lu MHz) (must be <= 
> > %lu)\n",
> > +   cr, cr / 100, cr_mod);
> > +   else
> > +   dev_warn(&pdev->dev, "Clock ss is at %lu (%lu MHz) (must be <= 
> > %lu)\n",
> > +   cr, cr / 100, cr_mod);
> 
> The management of kernel log levels looks pretty strange. As far as I
> understand there is no error on any clock rate, I'd recommend to keep
> only one information message.

And if not, please add some braces.

> hash_init: initialize request context */
> > +int sunxi_hash_init(struct ahash_request *areq)
> > +{
> > +   const char *hash_type;
> > +   struct sunxi_req_ctx *op = ahash_request_ctx(areq);
> > +
> > +   memset(op, 0, sizeof(struct sunxi_req_ctx));
> > +
> > +   hash_type = crypto_tfm_alg_name(areq->base.tfm);
> > +
> > +   if (strcmp(hash_type, "sha1") == 0)
> > +   op->mode = SS_OP_SHA1;
> > +   if (strcmp(hash_type, "md5") == 0)
> > +   op->mode = SS_OP_MD5;

else if ?

> > +   if (op->mode == 0)
> > +   return -EINVAL;

maybe this?

if (!strcmp(hash_type, "sha1"))
op->mode = SS_OP_SHA1;
else if (!strcmp(hash_type, "md5"))
op->mode = SH_OP_MD5;
else
return -EINVAL;

> > +
> > +   return 0;
> > +}
[]
> > +int sunxi_hash_update(struct ahash_request *areq)
> > +{
[]
> > +   dev_dbg(ss->dev, "%s %s bc=%llu len=%u mode=%x bw=%u ww=%u",
> > +   __func__, crypto_tfm_alg_name(areq->base.tfm),
> > +   op->byte_count, areq->nbytes, op->mode,
> > +   op->nbw, op->nwait);

dev_dbg statements generally don't need __func__ as
dynamic_debug can add it.

If you want to keep it, the most common output form for
__func__ is '"%s: ...", __func__'

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 4/4] crypto: Add Allwinner Security System crypto accelerator

[Vladimir Zapolskiy]

Hello LABBE,

On 19.10.2014 17:16, LABBE Corentin wrote:
> Add support for the Security System included in Allwinner SoC A20.
> The Security System is a hardware cryptographic accelerator that support 
> AES/MD5/SHA1/DES/3DES/PRNG algorithms.
> 
> Signed-off-by: LABBE Corentin 
> ---
>  drivers/crypto/Kconfig|  17 ++
>  drivers/crypto/Makefile   |   1 +
>  drivers/crypto/sunxi-ss/Makefile  |   2 +
>  drivers/crypto/sunxi-ss/sunxi-ss-cipher.c | 489 
> ++
>  drivers/crypto/sunxi-ss/sunxi-ss-core.c   | 318 +++
>  drivers/crypto/sunxi-ss/sunxi-ss-hash.c   | 445 +++
>  drivers/crypto/sunxi-ss/sunxi-ss.h| 193 
>  7 files changed, 1465 insertions(+)
>  create mode 100644 drivers/crypto/sunxi-ss/Makefile
>  create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
>  create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-core.c
>  create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash.c
>  create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss.h
> 
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 2fb0fdf..9ba9759 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -436,4 +436,21 @@ config CRYPTO_DEV_QCE
> hardware. To compile this driver as a module, choose M here. The
> module will be called qcrypto.
>  
> +config CRYPTO_DEV_SUNXI_SS
> + tristate "Support for Allwinner Security System cryptographic 
> accelerator"
> + depends on ARCH_SUNXI
> + select CRYPTO_MD5
> + select CRYPTO_SHA1
> + select CRYPTO_AES
> + select CRYPTO_DES
> + select CRYPTO_BLKCIPHER
> + help
> +   Some Allwinner SoC have a crypto accelerator named
> +   Security System. Select this if you want to use it.
> +   The Security System handle AES/DES/3DES ciphers in CBC mode
> +   and SHA1 and MD5 hash algorithms.
> +
> +   To compile this driver as a module, choose M here: the module
> +   will be called sunxi-ss.
> +
>  endif # CRYPTO_HW
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index 3924f93..856545c 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -25,3 +25,4 @@ obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
>  obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
>  obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
>  obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
> +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss/
> diff --git a/drivers/crypto/sunxi-ss/Makefile 
> b/drivers/crypto/sunxi-ss/Makefile
> new file mode 100644
> index 000..8bb287d
> --- /dev/null
> +++ b/drivers/crypto/sunxi-ss/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss.o
> +sunxi-ss-y += sunxi-ss-core.o sunxi-ss-hash.o sunxi-ss-cipher.o
> diff --git a/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c 
> b/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
> new file mode 100644
> index 000..8d0416e
> --- /dev/null
> +++ b/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
> @@ -0,0 +1,489 @@
> +/*
> + * sunxi-ss-cipher.c - hardware cryptographic accelerator for Allwinner A20 
> SoC
> + *
> + * Copyright (C) 2013-2014 Corentin LABBE 
> + *
> + * This file add support for AES cipher with 128,192,256 bits
> + * keysize in CBC mode.
> + * Add support also for DES and 3DES in CBC mode.
> + *
> + * You could find the datasheet in Documentation/arm/sunxi/README
> + *
> + * 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; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include "sunxi-ss.h"
> +
> +extern struct sunxi_ss_ctx *ss;
> +
> +static int sunxi_ss_cipher(struct ablkcipher_request *areq, u32 mode)
> +{
> + struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(areq);
> + struct sunxi_tfm_ctx *op = crypto_ablkcipher_ctx(tfm);
> + const char *cipher_type;
> +
> + if (areq->nbytes == 0)
> + return 0;
> +
> + if (areq->info == NULL) {
> + dev_err(ss->dev, "ERROR: Empty IV\n");
> + return -EINVAL;
> + }
> +
> + if (areq->src == NULL || areq->dst == NULL) {
> + dev_err(ss->dev, "ERROR: Some SGs are NULL\n");
> + return -EINVAL;
> + }
> +
> + cipher_type = crypto_tfm_alg_name(crypto_ablkcipher_tfm(tfm));
> +
> + if (strcmp("cbc(aes)", cipher_type) == 0) {
> + mode |= SS_OP_AES | SS_CBC | SS_ENABLED | op->keymode;
> + return sunxi_ss_aes_poll(areq, mode);
> + }
> +
> + if (strcmp("cbc(des)", cipher_type) == 0) {
> + mode |= SS_OP_DES | SS_CBC | SS_ENABLED | op->keymode;
> + return sunxi_ss_des_poll(areq, mode);
> + }
> +
> + if (strcmp("cbc(des3_ede)", cipher_type) == 0) {
> + mode |= SS_OP_3DES | SS_CBC | SS_ENABLED | op->keymode;
> + return sunxi_ss_des_poll(areq

Re: [PATCH v5 1/6] ARM: cygnus: Initial support for Broadcom Cygnus SoC

[Scott Branden]

On 14-10-20 12:55 PM, Arnd Bergmann wrote:

On Tuesday 14 October 2014 19:58:51 Scott Branden wrote:

  if ARCH_BCM

+menu "iProc SoC based Machine types"
+   config ARCH_BCM_IPROC
+   bool
+   select ARM_GIC
+   select CACHE_L2X0
+   select HAVE_ARM_SCU if SMP
+   select HAVE_ARM_TWD if SMP
+   select ARM_GLOBAL_TIMER
+
+   select CLKSRC_MMIO
+   select ARCH_REQUIRE_GPIOLIB
+   select ARM_AMBA
+   select PINCTRL
+   help
+ This enables support for systems based on Broadcom IPROC 
architected SoCs.
+ The IPROC complex contains one or more ARM CPUs along with 
common
+ core periperals. Application specific SoCs are created by 
adding a
+ uArchitecture containing peripherals outside of the IPROC 
complex.
+ Currently supported SoCs are Cygnus.
+
+   config ARCH_BCM_CYGNUS
+   bool "Broadcom Cygnus Support" if ARCH_MULTI_V7


You still have a three-level menu structure. Please fix.


Hi Arnd, we have ARCH_BCM->ARCH_BCM_CYGNUS.

ARCH_BCM_IPROC is silent and selected by ARCH_BCM_CYGNUS.  This was the 
change made between v3 and v5.


Is there something else to be done here?



+static const char const *bcm_cygnus_dt_compat[] = {
+   "brcm,cygnus",
+   NULL,
+};
+
+DT_MACHINE_START(BCM_CYGNUS_DT, "Broadcom Cygnus SoC")
+   .l2c_aux_val= 0,
+   .l2c_aux_mask   = ~0,
+   .dt_compat = bcm_cygnus_dt_compat,
+MACHINE_END


This looks good.

Arnd



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 4/9] Documentation: DT: Add entries for bcm63xx UART

[Florian Fainelli]

On 10/20/2014 02:25 PM, Arnd Bergmann wrote:
> On Monday 20 October 2014 23:20:08 Arnd Bergmann wrote:
>>
>> In this example, the clock output name of the clock provider is
>> the same as the clock input of the consumer, that is almost always
>> a bug and would not be a good example at all.
>>
>>
> 
> Ah, found the bug: the MIPS code is written to ignore the device
> and just look up a global clock name:
> 
> struct clk *clk_get(struct device *dev, const char *id)
> {
> if (!strcmp(id, "enet0"))
> return &clk_enet0;
> if (!strcmp(id, "enet1"))
> return &clk_enet1;
> if (!strcmp(id, "enetsw"))
> return &clk_enetsw;
> if (!strcmp(id, "ephy"))
> return &clk_ephy;
> if (!strcmp(id, "usbh"))
> return &clk_usbh;
> if (!strcmp(id, "usbd"))
> return &clk_usbd;
> if (!strcmp(id, "spi"))
> return &clk_spi;
> if (!strcmp(id, "hsspi"))
> return &clk_hsspi;
> if (!strcmp(id, "xtm"))
> return &clk_xtm;
> if (!strcmp(id, "periph"))
> return &clk_periph;
> if ((BCMCPU_IS_3368() || BCMCPU_IS_6358()) && !strcmp(id, "pcm"))
> return &clk_pcm;
> if ((BCMCPU_IS_6362() || BCMCPU_IS_6368()) && !strcmp(id, "ipsec"))
> return &clk_ipsec;
> if ((BCMCPU_IS_6328() || BCMCPU_IS_6362()) && !strcmp(id, "pcie"))
> return &clk_pcie;
> return ERR_PTR(-ENOENT);
> }
> 
> This should be changed to use the drivers/clk/clkdev.c lookup code if
> you want to share drivers between architectures.

For now, I suppose that s simple fix could be to use an anonymous clock
request when probed via DT. This code you quote dates from 2008 when
there was no clkdev in the kernel at all. So something like this would
probably do it for now:

diff --git a/drivers/tty/serial/bcm63xx_uart.c
b/drivers/tty/serial/bcm63xx_uart.c
index e0b87d507670..1b914b85dd31 100644
--- a/drivers/tty/serial/bcm63xx_uart.c
+++ b/drivers/tty/serial/bcm63xx_uart.c
@@ -819,7 +819,7 @@ static int bcm_uart_probe(struct platform_device *pdev)
if (!res_irq)
return -ENODEV;

-   clk = clk_get(&pdev->dev, "periph");
+   clk = clk_get(&pdev->dev, pdev->dev.of_node ? NULL : "periph");
if (IS_ERR(clk))
return -ENODEV;



> 
> In particular, the "enet0"/"enet1" clock name makes no sense -- the
> clock input name should be independent of the instance, aside from
> the question of which output of the provider it is wired up to.
> 
>   Arnd
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/2] ARM: dts: socfpga: Fix SD card detect

[Jaehoon Chung]

On 10/21/2014 07:41 AM, Mark Rutland wrote:
> On Mon, Oct 20, 2014 at 08:26:55PM +0100, Doug Anderson wrote:
>> Mark,
>>
>> On Mon, Oct 20, 2014 at 11:41 AM, Mark Rutland  wrote:
>>> On Mon, Oct 20, 2014 at 04:31:18PM +0100, dingu...@opensource.altera.com 
>>> wrote:
 From: Dinh Nguyen 

 Without this patch, the booting the SOCFPGA platform would hang at the
 SDMMC driver loading. There were 2 patches that caused this to happen:

 - Patch 9795a846e10 "mmc: dw_mmc: remove dw_mci_of_cd_gpio/wp_gpio()" 
 removed
   looking for "cd-gpios", since mmc_of_parse was getting called.
 - Patch 3cf890fc42b "mmc: dw_mmc: Pass back errors from mmc_of_parse()" 
 would
   hang the system at the SDMMC driver loading.
>>>
>>> Regardless of which patches caused the issue, the existing DTB should
>>> continue to function. This is a kernel bug, not a DTB bug.
>>
>> Right.  The kernel bug is that there is no "dtb fixup" stage of the
>> kernel to fix up old dtbs with this dtb bug.
>>
>> Said another way:
>>
>> 1. The old dtb was (possibly) not specifying the cd-gpio properly.
>>
>> 2. The kernel had a bug where it was ignoring that error.  Things may
>> have been working because of some other side effect (maybe polling was
>> working).
>>
>> 3. If we fix the kernel bug, what should we do?  The only sensible
>> thing (if we need to support old DTB with no changes) is to add a DTB
>> fixup stage.
>>
>> ...or did someone add that stage and I missed it?
> 
> Unfortunately, we have no generic DTB fixup stage currently.
> 
> What exactly was wrong with this cd-gpios description that previously
> allowed it to function? Can we not print a warning and fall back to the
> old behaviour in this case?

I think this is Dinh's mistake.
Doug found the reason of this problem, and it seems that Dinh has checked after 
fixing.
He didn't enable the gpio controller.

Best Regards,
Jaehoon Chung

> 
> Thanks,
> Mark
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/2] ARM: dts: socfpga: Fix SD card detect

[Mark Rutland]

On Mon, Oct 20, 2014 at 08:26:55PM +0100, Doug Anderson wrote:
> Mark,
> 
> On Mon, Oct 20, 2014 at 11:41 AM, Mark Rutland  wrote:
> > On Mon, Oct 20, 2014 at 04:31:18PM +0100, dingu...@opensource.altera.com 
> > wrote:
> >> From: Dinh Nguyen 
> >>
> >> Without this patch, the booting the SOCFPGA platform would hang at the
> >> SDMMC driver loading. There were 2 patches that caused this to happen:
> >>
> >> - Patch 9795a846e10 "mmc: dw_mmc: remove dw_mci_of_cd_gpio/wp_gpio()" 
> >> removed
> >>   looking for "cd-gpios", since mmc_of_parse was getting called.
> >> - Patch 3cf890fc42b "mmc: dw_mmc: Pass back errors from mmc_of_parse()" 
> >> would
> >>   hang the system at the SDMMC driver loading.
> >
> > Regardless of which patches caused the issue, the existing DTB should
> > continue to function. This is a kernel bug, not a DTB bug.
> 
> Right.  The kernel bug is that there is no "dtb fixup" stage of the
> kernel to fix up old dtbs with this dtb bug.
> 
> Said another way:
> 
> 1. The old dtb was (possibly) not specifying the cd-gpio properly.
> 
> 2. The kernel had a bug where it was ignoring that error.  Things may
> have been working because of some other side effect (maybe polling was
> working).
> 
> 3. If we fix the kernel bug, what should we do?  The only sensible
> thing (if we need to support old DTB with no changes) is to add a DTB
> fixup stage.
> 
> ...or did someone add that stage and I missed it?

Unfortunately, we have no generic DTB fixup stage currently.

What exactly was wrong with this cd-gpios description that previously
allowed it to function? Can we not print a warning and fall back to the
old behaviour in this case?

Thanks,
Mark
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 09/12] Driver core: Unified interface for firmware node properties

[Rafael J. Wysocki]

On Monday, October 20, 2014 04:19:57 PM Arnd Bergmann wrote:
> On Monday 20 October 2014 01:46:00 Rafael J. Wysocki wrote:
> > 
> > > Something like:
> > > 
> > > #define define_fwnode_accessors(__type, __devprop_type) \
> > > int device_property_read_##__type(struct device *dev, \
> > >   const char *propname, __type *val) \
> > > { \
> > >   if (IS_ENABLED(CONFIG_OF) && dev->of_node) \
> > >   return of_property_read_##__type(dev->of_node, propname, 
> > > val); \
> > >   return acpi_dev_prop_read(ACPI_COMPANION(dev), propname, \
> > > __devprop_type, val); \
> > > } \
> > > int fwnode_property_read_##__type(struct fwnode_handle *fwnode, \
> > >   const char *propname, __type *val) \
> > > { \
> > >   if (IS_ENABLED(CONFIG_OF) && is_of_node(fwnode)) \
> > >   return of_property_read_##__type(of_node(fwnode), propname, 
> > > val); \
> > >   else if (IS_ENABLED(CONFIG_ACPI) && is_acpi_node(fwnode)) \
> > >   return acpi_dev_prop_read(acpi_node(fwnode), propname, \
> > > __devprop_type, val); \
> > >   return -ENXIO; \
> > > }
> > > 
> > > define_fwnode_accessors(u8, DEV_PROP_U8);
> > > define_fwnode_accessors(u16, DEV_PROP_U16);
> > > define_fwnode_accessors(u32, DEV_PROP_U32);
> > > define_fwnode_accessors(u64, DEV_PROP_U64);
> > > 
> > > That significantly reduces the code size for these things.
> > 
> > So I was considering to do that, but eventually decided not to, because (1)
> > adding kerneldoc comments to such things looks odd and (2) (which IMO is
> > more important) this breaks LXR (for example, the thing at 
> > lxr.free-electrons.com
> > that some people, including me in particular, occasionally use to check how 
> > things
> > are defined).  And even if you used the old good grep to look for a 
> > definition of
> > fwnode_property_read_u8, say, this wouldn't work exactly as expected I'm 
> > afraid. 
> 
> Agreed, I'd also prefer your proposed code over Grant's macros.
> 
> > I would very much like to retain the headers at least for this reason, if 
> > that's
> > not a big deal.
> > 
> > What I can do, however, is to use macros for generating the bodies of those
> > functions.
> 
> Yes, just don't do any concatenation to generate the names of the called
> functions, i.e.
> 
>   return fwnode_call(of_property_read_u32, acpi_dev_prop_read, 
> DEV_PROP_U32, node, propname, val);
> 
> is better than
> 
>   return fwnode_call(u32, DEV_PROP_U32, node, propname, val);
> 
> because it's easier to understand the call chain.

There is one concatenation like that in the code I have today, but it was
already present in the $subject series, in the of_dev_prop_read_array macro
in patch #2 (and it actually makes sense to me).

Rafael

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 03/12] ACPI: Allow drivers to match using Device Tree compatible property

[Rafael J. Wysocki]

On Monday, October 20, 2014 04:05:01 PM Grant Likely wrote:
> On Fri, 17 Oct 2014 14:05:59 +0200
> , "Rafael J. Wysocki" 
>  wrote:
> > From: Mika Westerberg 
> > 
> > We have lots of existing Device Tree enabled drivers and allocating
> > separate _HID for each is not feasible. Instead we allocate special _HID
> > "PRP0001" that means that the match should be done using Device Tree
> > compatible property using driver's .of_match_table instead if the driver
> > is missing .acpi_match_table.
> 
> (Not a critique of this patch, but merely a helpful comment; my previous
> ack remains intact) :-)
> 
> It would be useful for the code to point at some document that describes
> the semantics of the PRP0001 binding.

Well, we need to create that document in the first place. :-)

I'd prefer to wait with that until the thing settles, however.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 09/12] Driver core: Unified interface for firmware node properties

[Rafael J. Wysocki]

On Monday, October 20, 2014 04:18:18 PM Grant Likely wrote:
> On Mon, 20 Oct 2014 01:46 +0200
> , "Rafael J. Wysocki" 
>  wrote:
> > On Saturday, October 18, 2014 04:55:20 PM Grant Likely wrote:
> > > On Fri, 17 Oct 2014 14:14:53 +0200

[cut]

> > 
> > No, that wouldn't work for ACPI (if I understand your idea correctly), 
> > because
> > acpi_dev_prop_read(adev, propname, DEV_PROP_U8, val) will look for a 
> > single-value
> > int property, whereas acpi_dev_prop_read_array(adev, propname, DEV_PROP_U8, 
> > val, 1)
> > will look for a list (package) property and will attempt to retrieve the 
> > first
> > element of that.
> 
> That's a problem. There are certainly cases of DT code that use the
> non-array version to read something that could also be read as an array
> when the code only want the first value. It is a completely valid thing
> to do. The ACPI accessors should be completely okay with either a single
> value, or the first item(s) in a package when doing either a single read or
> an array read.

Yeah.

So I have a new version of the patchset in which that is implemented as
you are describing.  Fortunately, the differences are limited to patches #2,
#3 (for the "compatible" property to behave this way too) and #9 and are not
too big.

I'd prefer that to pass the Mika's tests before posting it, though, which will
take some time I suppose.

> so, if it is encoded as a singl values, then return that value, and the
> largest size of array it will return is 1 element.
> 
> If it is encoded as a package, then a single read should return the
> first element, and an array read should return up to the number of
> values in the package.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/3] power-domain: add power domain drivers for Rockchip platform

[Russell King - ARM Linux]

On Mon, Oct 20, 2014 at 02:31:17PM -0700, Kevin Hilman wrote:
> "jinkun.hong"  writes:
> > +   spin_lock_irqsave(&pd->idle_lock, flags);
> > +   val = (idle) ? mask : 0;
> > +   regmap_update_bits(pd->regmap_pmu, REQ_OFFSET, mask, val);
> > +   dsb();
> 
> A summary of the locking and barriers here (or in changelog) would be
> helpful for reviewers to verify you're protecting what you need to
> protect.

It's also worth saying that the Linux specific barrier names should be
used unless there is a pressing reason to use the ARM specific barrier
names.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] drivers: cpuidle: add status property to ARM idle states

[Kevin Hilman]

Lorenzo Pieralisi  writes:

> On some platforms the device tree bindings must provide the kernel
> with a status flag for idle states, that defines whether the idle
> state is operational or not in the current configuration.
>
> This patch adds a status property to the ARM idle states compliant
> with ePAPR v1.1 and updates the DT parsing code accordingly.
>
> Signed-off-by: Lorenzo Pieralisi 

For the series:

Acked-by: Kevin Hilman 

Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/6] add basic rk3288 smp support

[Kevin Hilman]

Kever Yang  writes:

> rk3288 is qual-core CPU Soc, we enable the smp in this patch.
>
> In version 3 we use regmap and pmu syscon for cpu power on/off.
> This should be work after Pankaj Dubey's patch applied:
> "syscon: Decouple syscon interface from platform devices"
> (https://lkml.org/lkml/2014/9/30/156)

Tested on top of linux-next (next-20141020) along with above syscon
dependency, and verifed that 4 CPUs boot up on my rk3288-evb-rk808.

Tested-by: Kevin Hilman 

Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/3] ARM: rk3288 : Add PM Domain support

[Kevin Hilman]

"jinkun.hong"  writes:

> From: "jinkun.hong" 
>
> Add power domain drivers based on generic power domain for Rockchip platform,
> and support RK3288.
>
> Based on:
> - [PATCH v1 1/4] PM / clock_ops: Add pm_clk_add_clk()
>   http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg735599.html

This series doesn't include any devices (or their clocks) being hooked
up to the power domains.  Is there another patch someplace that shows
how you add devices to the power domains (probably using DT?)

Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/3] power-domain: add power domain drivers for Rockchip platform

[Kevin Hilman]

"jinkun.hong"  writes:

> From: "jinkun.hong" 
>
> Add power domain drivers based on generic power domain for Rockchip platform,
> and support RK3288.
>
> Signed-off-by: Jack Dai 
> Signed-off-by: jinkun.hong 

[...]

> +static int rockchip_pmu_set_idle_request(struct rockchip_domain *pd,
> +  bool idle)
> +{
> + u32 idle_mask = BIT(pd->idle_shift);
> + u32 idle_target = idle << (pd->idle_shift);
> + u32 ack_mask = BIT(pd->ack_shift);
> + u32 ack_target = idle << (pd->ack_shift);
> + unsigned int mask = BIT(pd->req_shift);
> + unsigned int val;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&pd->idle_lock, flags);
> + val = (idle) ? mask : 0;
> + regmap_update_bits(pd->regmap_pmu, REQ_OFFSET, mask, val);
> + dsb();

A summary of the locking and barriers here (or in changelog) would be
helpful for reviewers to verify you're protecting what you need to
protect.

> + do {
> + regmap_read(pd->regmap_pmu, ACK_OFFSET, &val);
> + } while ((val & ack_mask) != ack_target);
> +
> + do {
> + regmap_read(pd->regmap_pmu, IDLE_OFFSET, &val);
> + } while ((val & idle_mask) != idle_target);
> +
> + spin_unlock_irqrestore(&pd->idle_lock, flags);

These IRQ-disabled while loops look like opportunities to lockup the
system.  Maybe add a timeout or a maximum number of tries?

> + return 0;
> +}

Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 4/9] Documentation: DT: Add entries for bcm63xx UART

[Arnd Bergmann]

On Monday 20 October 2014 23:20:08 Arnd Bergmann wrote:
> 
> In this example, the clock output name of the clock provider is
> the same as the clock input of the consumer, that is almost always
> a bug and would not be a good example at all.
> 
> 

Ah, found the bug: the MIPS code is written to ignore the device
and just look up a global clock name:

struct clk *clk_get(struct device *dev, const char *id)
{
if (!strcmp(id, "enet0"))
return &clk_enet0;
if (!strcmp(id, "enet1"))
return &clk_enet1;
if (!strcmp(id, "enetsw"))
return &clk_enetsw;
if (!strcmp(id, "ephy"))
return &clk_ephy;
if (!strcmp(id, "usbh"))
return &clk_usbh;
if (!strcmp(id, "usbd"))
return &clk_usbd;
if (!strcmp(id, "spi"))
return &clk_spi;
if (!strcmp(id, "hsspi"))
return &clk_hsspi;
if (!strcmp(id, "xtm"))
return &clk_xtm;
if (!strcmp(id, "periph"))
return &clk_periph;
if ((BCMCPU_IS_3368() || BCMCPU_IS_6358()) && !strcmp(id, "pcm"))
return &clk_pcm;
if ((BCMCPU_IS_6362() || BCMCPU_IS_6368()) && !strcmp(id, "ipsec"))
return &clk_ipsec;
if ((BCMCPU_IS_6328() || BCMCPU_IS_6362()) && !strcmp(id, "pcie"))
return &clk_pcie;
return ERR_PTR(-ENOENT);
}

This should be changed to use the drivers/clk/clkdev.c lookup code if
you want to share drivers between architectures.

In particular, the "enet0"/"enet1" clock name makes no sense -- the
clock input name should be independent of the instance, aside from
the question of which output of the provider it is wired up to.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 4/9] Documentation: DT: Add entries for bcm63xx UART

[Arnd Bergmann]

On Monday 20 October 2014 13:54:03 Kevin Cernekee wrote:
> +- clock-names: The appropriate output name in the referenced clock node.
> +
> +   uart0: serial@14e00520 {
> +   compatible = "brcm,bcm6345-uart";
> +   reg = <0x14e00520 0x18>;
> +   interrupt-parent = <&periph_intc>;
> +   interrupts = <2>;
> +   clocks = <&periph_clk>;
> +   clock-names = "periph";
> +   };
> +
> +   clocks {
> +   periph_clk: periph_clk@0 {
> +   compatible = "fixed-clock";
> +   #clock-cells = <0>;
> +   clock-frequency = <5400>;
> +   clock-output-names = "periph";
> +   };
> +   };

In this example, the clock output name of the clock provider is
the same as the clock input of the consumer, that is almost always
a bug and would not be a good example at all.

I assume the output name is correct and the input is not. If you
have access to the HDL source of the bcm6345-uart, please check
if the input has a proper name, otherwise just call it "uart"
or remove the clock-names property completely.

In the documentation enough, you must document the specific name
of the clock that is supposed to be used by the uart driver.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8] coresight: bindings for coresight drivers

[mathieu . poirier]

From: Mathieu Poirier 

Coresight IP blocks allow for the support of HW assisted tracing
on ARM SoCs.  Bindings for the currently available blocks are
presented herein.

Signed-off-by: Pratik Patel 
Signed-off-by: Mathieu Poirier 
---
 .../devicetree/bindings/arm/coresight.txt  | 203 +
 1 file changed, 203 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/coresight.txt

diff --git a/Documentation/devicetree/bindings/arm/coresight.txt 
b/Documentation/devicetree/bindings/arm/coresight.txt
new file mode 100644
index 000..96dd947
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -0,0 +1,203 @@
+* CoreSight Components:
+
+CoreSight components are compliant with the ARM CoreSight architecture
+specification and can be connected in various topologies to suit a particular
+SoCs tracing needs. These trace components can generally be classified as 
sinks,
+links and sources. Trace data produced by one or more sources flows through the
+intermediate links connecting the source to the currently selected sink. Each
+CoreSight component device should use these properties to describe its hardware
+characteristcs.
+
+* Required properties for all components *except* non-configurable replicators:
+
+   * compatible: These have to be supplemented with "arm,primecell" as
+ drivers are using the AMBA bus interface.  Possible values include:
+   - "arm,coresight-etb10", "arm,primecell";
+   - "arm,coresight-tpiu", "arm,primecell";
+   - "arm,coresight-tmc", "arm,primecell";
+   - "arm,coresight-funnel", "arm,primecell";
+   - "arm,coresight-etm3x", "arm,primecell";
+
+   * reg: physical base address and length of the register
+ set(s) of the component.
+
+   * clocks: the clock associated to this component.
+
+   * clock-names: the name of the clock as referenced by the code.
+ Since we are using the AMBA framework, the name should be
+ "apb_pclk".
+
+   * port or ports: The representation of the component's port
+ layout using the generic DT graph presentation found in
+ "bindings/graph.txt".
+
+* Required properties for devices that don't show up on the AMBA bus, such as
+  non-configurable replicators:
+
+   * compatible: Currently supported value is (note the absence of the
+ AMBA markee):
+   - "arm,coresight-replicator"
+
+   * id: a unique number that will identify this replicator.
+
+   * port or ports: same as above.
+
+* Optional properties for ETM/PTMs:
+
+   * arm,cp14: must be present if the system accesses ETM/PTM management 
registers
+ via co-processor 14.
+
+   * cpu: the cpu phandle this ETM/PTM is affined to. When omitted the 
source is
+ considered to belong to CPU0.
+
+* Optional property for TMC:
+
+   * arm,buffer-size: size of contiguous buffer space for TMC ETR
+(embedded trace router)
+
+
+Example:
+
+1. Sinks
+   etb@0,2001 {
+   compatible = "arm,coresight-etb10", "arm,primecell";
+   reg = <0 0x2001 0 0x1000>;
+
+   coresight-default-sink;
+   clocks = <&oscclk6a>;
+   clock-names = "apb_pclk";
+   port {
+   etb_in_port: endpoint@0 {
+   slave-mode;
+   remote-endpoint = <&replicator_out_port0>;
+   };
+   };
+   };
+
+   tpiu@0,2003 {
+   compatible = "arm,coresight-tpiu", "arm,primecell";
+   reg = <0 0x2003 0 0x1000>;
+
+   clocks = <&oscclk6a>;
+   clock-names = "apb_pclk";
+   port {
+   tpiu_in_port: endpoint@0 {
+   slave-mode;
+   remote-endpoint = <&replicator_out_port1>;
+   };
+   };
+   };
+
+2. Links
+   replicator {
+   /* non-configurable replicators don't show up on the
+* AMBA bus.  As such no need to add "arm,primecell".
+*/
+   compatible = "arm,coresight-replicator";
+   /* this will show up in debugfs as "0.replicator" */
+   id = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* replicator output ports */
+   port@0 {
+   reg = <0>;
+   replicator_out_port0: endpoint {
+   remote-endpoint = <&etb_in_port>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   replicator_out_port1: endpoint {
+   

Re: [PATCHv2 2/2] ARM: dts: socfpga: Add a 3.3V fixed regulator node

[Dinh Nguyen]

On 10/20/2014 10:51 AM, Doug Anderson wrote:
> Dinh,
> 
> On Mon, Oct 20, 2014 at 8:31 AM,   wrote:
>> +++ b/arch/arm/boot/dts/socfpga_arria5_socdk.dts
>> @@ -37,6 +37,15 @@
>> */
>> ethernet0 = &gmac1;
>> };
>> +
>> +   regulator_3_3v: regulator {
> 
> I think it's better to give this a real node name.  The
> "regulator_3_3v" will get dropped when you compile this into a binary
> format (for shipping), so you're creating a node that's just called
> "regulator".  If you had more than one fixed regulator like this it
> just won't work.
> 
> I haven't seen any official guidelines, but I tend to use "regulator"
> as a suffix and then put the schematic name.  Like:
> 
>   3_3v_regulator: 3-3-v-regulator
> 
>

Not sure if there's a limit on a node cannot start with numeric value?
But if I change it to your suggestion, the DTC does not compile:

Error: arch/arm/boot/dts/socfpga_cyclone5_socdk.dts:41.16-17 syntax error
FATAL ERROR: Unable to parse input tree


But regulator_3_3v: 3-3-v-regulator   will work fine.

Dinh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 1/9] tty: serial: bcm63xx: Allow bcm63xx_uart to be built on other platforms

[Kevin Cernekee]

This device was originally supported on bcm63xx only, but it shows up on
a wide variety of MIPS and ARM chipsets spanning multiple product lines.
Now that the driver has eliminated dependencies on bcm63xx-specific
header files, we can build it on any non-bcm63xx kernel.

Compile-tested on x86, both statically and as a module.  Tested for
functionality on bcm3384 (a new MIPS platform under active development).

Signed-off-by: Kevin Cernekee 
Acked-by: Florian Fainelli 
---
 drivers/tty/serial/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 649b784..4a5c0c8 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1283,7 +1283,7 @@ config SERIAL_TIMBERDALE
 config SERIAL_BCM63XX
tristate "bcm63xx serial port support"
select SERIAL_CORE
-   depends on BCM63XX
+   depends on MIPS || ARM || COMPILE_TEST
help
  If you have a bcm63xx CPU, you can enable its onboard
  serial port by enabling this options.
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 8/9] tty: serial: of-serial: Allow OF earlycon to default to "on"

[Kevin Cernekee]

On many development systems it is very common to see failures during the
early stages of the boot process, e.g. SMP boot or PCIe initialization.
This is one likely reason why some existing earlyprintk implementations,
such as arch/mips/kernel/early_printk.c, are enabled unconditionally
at compile time.

Now that earlycon's operating parameters can be passed into the kernel
via DT, it is helpful to be able to configure the kernel to turn it on
automatically.  Introduce a new CONFIG_SERIAL_EARLYCON_FORCE option for
this purpose.

Signed-off-by: Kevin Cernekee 
---
 drivers/of/fdt.c   |  5 +
 drivers/tty/serial/Kconfig | 11 +++
 2 files changed, 16 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 20193cc..3e2ea1e 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1013,6 +1013,11 @@ bool __init early_init_dt_verify(void *params)
 
 void __init early_init_dt_scan_nodes(void)
 {
+#ifdef CONFIG_SERIAL_EARLYCON_FORCE
+   if (early_init_dt_scan_chosen_serial() < 0)
+   pr_warn("Unable to set up earlycon from stdout-path\n");
+#endif
+
/* Retrieve various information from the /chosen node */
of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
 
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index fdd851e..bc4ebcc 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -14,6 +14,17 @@ config SERIAL_EARLYCON
  the console before standard serial driver is probed. The console is
  enabled when early_param is processed.
 
+config SERIAL_EARLYCON_FORCE
+   bool "Always enable early console"
+   depends on SERIAL_EARLYCON
+   help
+ Traditionally, enabling the early console has required passing in
+ the "earlycon" parameter on the kernel command line.  On systems
+ under development it may be desirable to enable earlycon
+ unconditionally rather than to force the user to manually add it
+ to the boot argument string, as boot failures often occur before
+ the standard serial driver is probed.
+
 source "drivers/tty/serial/8250/Kconfig"
 
 comment "Non-8250 serial port support"
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 0/9] bcm63xx_uart and of-serial updates

[Kevin Cernekee]

In the course of bringing up a new platform[1] that uses this hardware,
I made a couple of improvements:

 - Allow the driver to be built for targets that do not define
   CONFIG_BCM63xx (as mine doesn't)
 - Use devm_ioremap_resource() to simplify the initialization code
 - Allow OF earlycon to be hardwired "on" in the kernel build, so it can
   eventually replace the MIPS EARLY_PRINTK scheme
 - Update documentation; fix typos/grammar


V1->V2:

 - Add acks from Florian
 - Rebase on tty-next (3.18-rc1)
 - bcm63xx_uart: add patches 3,4,6
 - Rework my earlycon change (patches 7,8) to use a config option
   instead of a function call

[1] https://github.com/cernekee/linux/commits/bcm3384


Kevin Cernekee (9):
  tty: serial: bcm63xx: Allow bcm63xx_uart to be built on other
platforms
  tty: serial: bcm63xx: Update the Kconfig help text
  tty: serial: bcm63xx: Fix typo in MODULE_DESCRIPTION
  Documentation: DT: Add entries for bcm63xx UART
  tty: serial: bcm63xx: Enable DT earlycon support
  tty: serial: bcm63xx: Eliminate unnecessary request/release functions
  tty: serial: of-serial: Suppress warnings if OF earlycon is invoked
twice
  tty: serial: of-serial: Allow OF earlycon to default to "on"
  MAINTAINERS: Add entry for rp2 (Rocketport Express/Infinity) driver

 .../devicetree/bindings/serial/bcm63xx-uart.txt| 34 ++
 MAINTAINERS|  6 +++
 drivers/of/fdt.c   | 17 +--
 drivers/tty/serial/Kconfig | 30 +
 drivers/tty/serial/bcm63xx_uart.c  | 52 +-
 include/linux/serial_bcm63xx.h |  2 -
 6 files changed, 106 insertions(+), 35 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/bcm63xx-uart.txt

-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 3/9] tty: serial: bcm63xx: Fix typo in MODULE_DESCRIPTION

[Kevin Cernekee]

Remove the extra '<' character.

Signed-off-by: Kevin Cernekee 
---
 drivers/tty/serial/bcm63xx_uart.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/bcm63xx_uart.c 
b/drivers/tty/serial/bcm63xx_uart.c
index 2315190..a70910e 100644
--- a/drivers/tty/serial/bcm63xx_uart.c
+++ b/drivers/tty/serial/bcm63xx_uart.c
@@ -905,5 +905,5 @@ module_init(bcm_uart_init);
 module_exit(bcm_uart_exit);
 
 MODULE_AUTHOR("Maxime Bizon ");
-MODULE_DESCRIPTION("Broadcom 63http://vger.kernel.org/majordomo-info.html

[PATCH V2 5/9] tty: serial: bcm63xx: Enable DT earlycon support

[Kevin Cernekee]

This enables early console output if there is a chosen/stdout-path
property referencing a UART node with the "brcm,bcm6345-uart" compatible
string.  The bootloader sets up the pinmux and baud/parity/etc.
Tested on bcm3384 (MIPS, DT).

Signed-off-by: Kevin Cernekee 
---
 drivers/tty/serial/Kconfig|  1 +
 drivers/tty/serial/bcm63xx_uart.c | 20 
 2 files changed, 21 insertions(+)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 815b652..fdd851e 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1297,6 +1297,7 @@ config SERIAL_BCM63XX_CONSOLE
bool "Console on BCM63xx serial port"
depends on SERIAL_BCM63XX=y
select SERIAL_CORE_CONSOLE
+   select SERIAL_EARLYCON
help
  If you have enabled the serial port on the BCM63xx CPU
  you can make it the console by answering Y to this option.
diff --git a/drivers/tty/serial/bcm63xx_uart.c 
b/drivers/tty/serial/bcm63xx_uart.c
index a70910e..2015284 100644
--- a/drivers/tty/serial/bcm63xx_uart.c
+++ b/drivers/tty/serial/bcm63xx_uart.c
@@ -782,6 +782,26 @@ static int __init bcm63xx_console_init(void)
 
 console_initcall(bcm63xx_console_init);
 
+static void bcm_early_write(struct console *con, const char *s, unsigned n)
+{
+   struct earlycon_device *dev = con->data;
+
+   uart_console_write(&dev->port, s, n, bcm_console_putchar);
+   wait_for_xmitr(&dev->port);
+}
+
+static int __init bcm_early_console_setup(struct earlycon_device *device,
+ const char *opt)
+{
+   if (!device->port.membase)
+   return -ENODEV;
+
+   device->con->write = bcm_early_write;
+   return 0;
+}
+
+OF_EARLYCON_DECLARE(bcm63xx_uart, "brcm,bcm6345-uart", 
bcm_early_console_setup);
+
 #define BCM63XX_CONSOLE(&bcm63xx_console)
 #else
 #define BCM63XX_CONSOLENULL
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 9/9] MAINTAINERS: Add entry for rp2 (Rocketport Express/Infinity) driver

[Kevin Cernekee]

I wrote this driver and use it daily on several machines for work, so
why not.

Signed-off-by: Kevin Cernekee 
Acked-by: Florian Fainelli 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a20df9b..d483627 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7787,6 +7787,12 @@ S:   Maintained
 F: Documentation/serial/rocket.txt
 F: drivers/tty/rocket*
 
+ROCKETPORT EXPRESS/INFINITY DRIVER
+M: Kevin Cernekee 
+L: linux-ser...@vger.kernel.org
+S: Odd Fixes
+F: drivers/tty/serial/rp2.*
+
 ROSE NETWORK LAYER
 M: Ralf Baechle 
 L: linux-h...@vger.kernel.org
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 2/9] tty: serial: bcm63xx: Update the Kconfig help text

[Kevin Cernekee]

Remove incorrect "bcm963xx_uart" module name; add a list of known users;
tweak grammar/indentation/capitalization.

Signed-off-by: Kevin Cernekee 
Acked-by: Florian Fainelli 
---
 drivers/tty/serial/Kconfig | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 4a5c0c8..815b652 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1281,22 +1281,24 @@ config SERIAL_TIMBERDALE
Add support for UART controller on timberdale.
 
 config SERIAL_BCM63XX
-   tristate "bcm63xx serial port support"
+   tristate "Broadcom BCM63xx/BCM33xx UART support"
select SERIAL_CORE
depends on MIPS || ARM || COMPILE_TEST
help
- If you have a bcm63xx CPU, you can enable its onboard
- serial port by enabling this options.
+ This enables the driver for the onchip UART core found on
+ the following chipsets:
 
-  To compile this driver as a module, choose M here: the
-  module will be called bcm963xx_uart.
+   BCM33xx (cable modem)
+   BCM63xx/BCM63xxx (DSL)
+   BCM68xx (PON)
+   BCM7xxx (STB) - DOCSIS console
 
 config SERIAL_BCM63XX_CONSOLE
-   bool "Console on bcm63xx serial port"
+   bool "Console on BCM63xx serial port"
depends on SERIAL_BCM63XX=y
select SERIAL_CORE_CONSOLE
help
- If you have enabled the serial port on the bcm63xx CPU
+ If you have enabled the serial port on the BCM63xx CPU
  you can make it the console by answering Y to this option.
 
 config SERIAL_GRLIB_GAISLER_APBUART
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 6/9] tty: serial: bcm63xx: Eliminate unnecessary request/release functions

[Kevin Cernekee]

We don't really need to perform the ioremap "on demand" so it's simpler
just to do it from the probe function.  This also lets us eliminate the
UART_REG_SIZE constant and rely on the resource information passed in
from the DT or platform code.

Signed-off-by: Kevin Cernekee 
---
 drivers/tty/serial/bcm63xx_uart.c | 30 ++
 include/linux/serial_bcm63xx.h|  2 --
 2 files changed, 10 insertions(+), 22 deletions(-)

diff --git a/drivers/tty/serial/bcm63xx_uart.c 
b/drivers/tty/serial/bcm63xx_uart.c
index 2015284..999bb6fa 100644
--- a/drivers/tty/serial/bcm63xx_uart.c
+++ b/drivers/tty/serial/bcm63xx_uart.c
@@ -588,20 +588,7 @@ static void bcm_uart_set_termios(struct uart_port *port,
  */
 static int bcm_uart_request_port(struct uart_port *port)
 {
-   unsigned int size;
-
-   size = UART_REG_SIZE;
-   if (!request_mem_region(port->mapbase, size, "bcm63xx")) {
-   dev_err(port->dev, "Memory region busy\n");
-   return -EBUSY;
-   }
-
-   port->membase = ioremap(port->mapbase, size);
-   if (!port->membase) {
-   dev_err(port->dev, "Unable to map registers\n");
-   release_mem_region(port->mapbase, size);
-   return -EBUSY;
-   }
+   /* UARTs always present */
return 0;
 }
 
@@ -610,8 +597,7 @@ static int bcm_uart_request_port(struct uart_port *port)
  */
 static void bcm_uart_release_port(struct uart_port *port)
 {
-   release_mem_region(port->mapbase, UART_REG_SIZE);
-   iounmap(port->membase);
+   /* Nothing to release ... */
 }
 
 /*
@@ -833,13 +819,20 @@ static int bcm_uart_probe(struct platform_device *pdev)
if (pdev->id < 0 || pdev->id >= BCM63XX_NR_UARTS)
return -EINVAL;
 
-   if (ports[pdev->id].membase)
+   port = &ports[pdev->id];
+   if (port->membase)
return -EBUSY;
+   memset(port, 0, sizeof(*port));
 
res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res_mem)
return -ENODEV;
 
+   port->mapbase = res_mem->start;
+   port->membase = devm_ioremap_resource(&pdev->dev, res_mem);
+   if (IS_ERR(port->membase))
+   return PTR_ERR(port->membase);
+
res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res_irq)
return -ENODEV;
@@ -848,10 +841,7 @@ static int bcm_uart_probe(struct platform_device *pdev)
if (IS_ERR(clk))
return -ENODEV;
 
-   port = &ports[pdev->id];
-   memset(port, 0, sizeof(*port));
port->iotype = UPIO_MEM;
-   port->mapbase = res_mem->start;
port->irq = res_irq->start;
port->ops = &bcm_uart_ops;
port->flags = UPF_BOOT_AUTOCONF;
diff --git a/include/linux/serial_bcm63xx.h b/include/linux/serial_bcm63xx.h
index a80aa1a..570e964 100644
--- a/include/linux/serial_bcm63xx.h
+++ b/include/linux/serial_bcm63xx.h
@@ -116,6 +116,4 @@
UART_FIFO_PARERR_MASK | \
UART_FIFO_BRKDET_MASK)
 
-#define UART_REG_SIZE  24
-
 #endif /* _LINUX_SERIAL_BCM63XX_H */
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 7/9] tty: serial: of-serial: Suppress warnings if OF earlycon is invoked twice

[Kevin Cernekee]

Specifying "earlycon earlycon" on the kernel command line yields this
warning:

bootconsole [uart0] enabled
[ cut here ]
WARNING: CPU: 0 PID: 0 at kernel/printk/printk.c:2391 
register_console+0x244/0x3fc()
console 'uart0' already registered
CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc1+ #2
Stack :  0004 80af 80af    

  80ad4e12 0036   0001 805abe88 805606b4 
805abae7
    80ad38d8 805abe88 8055f304 43d42d03 9988c6a1 
804e2710
  805b 80032854   8056492c 80599c84 80599c84 
805606b4
         

  ...
Call Trace:
[<8001a22c>] show_stack+0x64/0x7c
[<804e47d8>] dump_stack+0xc8/0xfc
[<80032aa8>] warn_slowpath_common+0x7c/0xac
[<80032b38>] warn_slowpath_fmt+0x2c/0x38
[<80076524>] register_console+0x244/0x3fc
[<805d8314>] of_setup_earlycon+0x74/0x98
[<805daa40>] early_init_dt_scan_chosen_serial+0x104/0x134
[<805c51a0>] do_early_param+0xc4/0x13c
[<8004efa0>] parse_args+0x284/0x444
[<805c56cc>] parse_early_options+0x34/0x40
[<805c5714>] parse_early_param+0x3c/0x58
[<805c87a4>] setup_arch+0xec/0x6e4
[<805c57d4>] start_kernel+0x94/0x458

---[ end trace dc8fa200cb88537f ]---

In this case the duplicate "earlycon" was entered directly, but there are
other cases where this could happen inadvertently:

 - Some platforms allow user bootargs to be concatenated with builtin
   bootargs, e.g. CONFIG_CMDLINE_EXTEND.

 - Other platforms may want to hardwire earlycon to ON, so it isn't
   nice if a user manually specifying "earlycon" on the command line sees
   a big scary warning.

So, we will treat "earlycon" as a flag, and if happens to be requested
multiple times the kernel will not print any warnings.

Signed-off-by: Kevin Cernekee 
---
 drivers/of/fdt.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index d1ffca8..20193cc 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -755,6 +755,11 @@ int __init early_init_dt_scan_chosen_serial(void)
int l;
const struct of_device_id *match = __earlycon_of_table;
const void *fdt = initial_boot_params;
+   static int done;
+
+   if (done)
+   return -EBUSY;
+   done = 1;
 
offset = fdt_path_offset(fdt, "/chosen");
if (offset < 0)
@@ -792,10 +797,9 @@ int __init early_init_dt_scan_chosen_serial(void)
 
 static int __init setup_of_earlycon(char *buf)
 {
-   if (buf)
-   return 0;
-
-   return early_init_dt_scan_chosen_serial();
+   if (!buf)
+   early_init_dt_scan_chosen_serial();
+   return 0;
 }
 early_param("earlycon", setup_of_earlycon);
 #endif
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 4/9] Documentation: DT: Add entries for bcm63xx UART

[Kevin Cernekee]

This squashes a checkpatch warning on my new bcm3384 dts submission.

Signed-off-by: Kevin Cernekee 
---
 .../devicetree/bindings/serial/bcm63xx-uart.txt| 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/bcm63xx-uart.txt

diff --git a/Documentation/devicetree/bindings/serial/bcm63xx-uart.txt 
b/Documentation/devicetree/bindings/serial/bcm63xx-uart.txt
new file mode 100644
index 000..b01c76a
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/bcm63xx-uart.txt
@@ -0,0 +1,34 @@
+* BCM63xx UART
+
+Required properties:
+
+- compatible: "brcm,bcm6345-uart"
+
+- reg: The base address of the UART register bank.
+
+- interrupts: A single interrupt specifier.
+
+- clocks: Clock driving the hardware; used to figure out the baud rate
+  divisor.
+
+- clock-names: The appropriate output name in the referenced clock node.
+
+Example:
+
+   uart0: serial@14e00520 {
+   compatible = "brcm,bcm6345-uart";
+   reg = <0x14e00520 0x18>;
+   interrupt-parent = <&periph_intc>;
+   interrupts = <2>;
+   clocks = <&periph_clk>;
+   clock-names = "periph";
+   };
+
+   clocks {
+   periph_clk: periph_clk@0 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <5400>;
+   clock-output-names = "periph";
+   };
+   };
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/2] ARM: dts: socfpga: Fix SD card detect

[Dinh Nguyen]

On 10/20/2014 02:48 PM, Doug Anderson wrote:
> Dinh,
> 
> On Mon, Oct 20, 2014 at 12:30 PM, Doug Anderson  wrote:
>> Dinh,
>>
>> On Mon, Oct 20, 2014 at 9:31 AM, Dinh Nguyen
>>  wrote:
>  &mmc0 {
> -   cd-gpios = <&gpio1 18 0>;
> +   cd = <&gpio1 18 0>;

 This doesn't look right to me.  What was the error that was passed back?

 I think your change has the same net effect as just deleting the
 "cd-gpios" line.  ...or is there some code somewhere that is parsing
 the "cd" property.

>>>
>>> It just hangs here:
>>>
>>> dw_mmc ff704000.dwmmc0: Using PIO mode.
>>> dw_mmc ff704000.dwmmc0: Version ID is 240a
>>> dw_mmc ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host data
>>> width, 1024 deep fifo
>>> platform ff704000.dwmmc0: Driver dw_mmc requests probe deferral
>>>
>>>
>>> Without this patch :
>>> mmc_of_parse ret=-517 (EPROBE_DEFER)
>>
>> I think you need to dig more into this error.  Why are you getting an
>> -EPROBE_DEFER when you asked for this GPIO?
>>
>> The -EPROBE_DEFER tells the system that a resource is not available
>> yet and that it should try to re-run the dw_mmc init later once the
>> resource becomes available.  I believe that some other bug is causing
>> the resource to never become available.
>>
>> Guesses:
>>
>> * The GPIO specifier is wrong in the DTB and is pointing to a GPIO
>> that would never exist.
>>
>> * Something is happening in the GPIO driver that is causing it to fail.
>>
>>
>> ...so we need to dig in further.
> 
> One odd thing is that it looks like the GPIO controller you're
> referencing is disabled.  On today's linuxnext, you can see the
> "disabled":
> 
> arch/arm/boot/dts/socfpga.dtsi: gpio@ff709000 {
> arch/arm/boot/dts/socfpga.dtsi- #address-cells = <1>;
> arch/arm/boot/dts/socfpga.dtsi- #size-cells = <0>;
> arch/arm/boot/dts/socfpga.dtsi- compatible = 
> "snps,dw-apb-gpio";
> arch/arm/boot/dts/socfpga.dtsi- reg = <0xff709000 0x1000>;
> arch/arm/boot/dts/socfpga.dtsi- clocks = <&per_base_clk>;
> arch/arm/boot/dts/socfpga.dtsi- status = "disabled";
> arch/arm/boot/dts/socfpga.dtsi-
> arch/arm/boot/dts/socfpga.dtsi- gpio1: gpio-controller@0 {
> arch/arm/boot/dts/socfpga.dtsi- compatible =
> "snps,dw-apb-gpio-port";
> arch/arm/boot/dts/socfpga.dtsi- gpio-controller;
> 
> I don't see anyone else referencing that node to enable it.  ...to me
> that means that you can't use GPIOs on GPIO1 (???).
> 
> 
> ...or did I find something wrong?
> 

Ah yes, yes! Thanks so much for find this Doug!

With the following patch, boots fine with SD driver loading.


--- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
@@ -37,6 +37,12 @@
 */
ethernet0 = &gmac1;
};
+
+   soc {
+   gpio@ff709000 {
+   status = "okay";
+   };
+   };

Thanks,
Dinh


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/6] ARM: cygnus: Initial support for Broadcom Cygnus SoC

[Arnd Bergmann]

On Tuesday 14 October 2014 19:58:51 Scott Branden wrote:
>  if ARCH_BCM
>  
> +menu "iProc SoC based Machine types"
> +   config ARCH_BCM_IPROC
> +   bool
> +   select ARM_GIC
> +   select CACHE_L2X0
> +   select HAVE_ARM_SCU if SMP
> +   select HAVE_ARM_TWD if SMP
> +   select ARM_GLOBAL_TIMER
> +
> +   select CLKSRC_MMIO
> +   select ARCH_REQUIRE_GPIOLIB
> +   select ARM_AMBA
> +   select PINCTRL
> +   help
> + This enables support for systems based on Broadcom IPROC 
> architected SoCs.
> + The IPROC complex contains one or more ARM CPUs along with 
> common
> + core periperals. Application specific SoCs are created by 
> adding a
> + uArchitecture containing peripherals outside of the IPROC 
> complex.
> + Currently supported SoCs are Cygnus.
> +
> +   config ARCH_BCM_CYGNUS
> +   bool "Broadcom Cygnus Support" if ARCH_MULTI_V7

You still have a three-level menu structure. Please fix.

> +static const char const *bcm_cygnus_dt_compat[] = {
> +   "brcm,cygnus",
> +   NULL,
> +};
> +
> +DT_MACHINE_START(BCM_CYGNUS_DT, "Broadcom Cygnus SoC")
> +   .l2c_aux_val= 0,
> +   .l2c_aux_mask   = ~0,
> +   .dt_compat = bcm_cygnus_dt_compat,
> +MACHINE_END
> 
This looks good.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/2] ARM: dts: socfpga: Fix SD card detect

[Doug Anderson]

Dinh,

On Mon, Oct 20, 2014 at 12:30 PM, Doug Anderson  wrote:
> Dinh,
>
> On Mon, Oct 20, 2014 at 9:31 AM, Dinh Nguyen
>  wrote:
  &mmc0 {
 -   cd-gpios = <&gpio1 18 0>;
 +   cd = <&gpio1 18 0>;
>>>
>>> This doesn't look right to me.  What was the error that was passed back?
>>>
>>> I think your change has the same net effect as just deleting the
>>> "cd-gpios" line.  ...or is there some code somewhere that is parsing
>>> the "cd" property.
>>>
>>
>> It just hangs here:
>>
>> dw_mmc ff704000.dwmmc0: Using PIO mode.
>> dw_mmc ff704000.dwmmc0: Version ID is 240a
>> dw_mmc ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host data
>> width, 1024 deep fifo
>> platform ff704000.dwmmc0: Driver dw_mmc requests probe deferral
>>
>>
>> Without this patch :
>> mmc_of_parse ret=-517 (EPROBE_DEFER)
>
> I think you need to dig more into this error.  Why are you getting an
> -EPROBE_DEFER when you asked for this GPIO?
>
> The -EPROBE_DEFER tells the system that a resource is not available
> yet and that it should try to re-run the dw_mmc init later once the
> resource becomes available.  I believe that some other bug is causing
> the resource to never become available.
>
> Guesses:
>
> * The GPIO specifier is wrong in the DTB and is pointing to a GPIO
> that would never exist.
>
> * Something is happening in the GPIO driver that is causing it to fail.
>
>
> ...so we need to dig in further.

One odd thing is that it looks like the GPIO controller you're
referencing is disabled.  On today's linuxnext, you can see the
"disabled":

arch/arm/boot/dts/socfpga.dtsi: gpio@ff709000 {
arch/arm/boot/dts/socfpga.dtsi- #address-cells = <1>;
arch/arm/boot/dts/socfpga.dtsi- #size-cells = <0>;
arch/arm/boot/dts/socfpga.dtsi- compatible = "snps,dw-apb-gpio";
arch/arm/boot/dts/socfpga.dtsi- reg = <0xff709000 0x1000>;
arch/arm/boot/dts/socfpga.dtsi- clocks = <&per_base_clk>;
arch/arm/boot/dts/socfpga.dtsi- status = "disabled";
arch/arm/boot/dts/socfpga.dtsi-
arch/arm/boot/dts/socfpga.dtsi- gpio1: gpio-controller@0 {
arch/arm/boot/dts/socfpga.dtsi- compatible =
"snps,dw-apb-gpio-port";
arch/arm/boot/dts/socfpga.dtsi- gpio-controller;

I don't see anyone else referencing that node to enable it.  ...to me
that means that you can't use GPIOs on GPIO1 (???).


...or did I find something wrong?


-Doug
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/1] Documentation: dt-bindings: Explain order in patch series

[Javier Martinez Canillas]

Hello Jon,

On 10/20/2014 05:49 PM, Jonathan Corbet wrote:
> On Tue, 14 Oct 2014 10:25:52 +0100
> Mark Rutland  wrote:
> 
>> Following the discussion around [1], this makes sense to me, so:
>> 
>> Acked-by: Mark Rutland 
> 
> Applied to my shiny new docs tree in case nobody else grabs it.
> 
> jon
> 

Thanks a lot for picking this

Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] dma: Add Xilinx AXI Direct Memory Access Engine driver support

[Arnd Bergmann]

On Wednesday 15 October 2014 17:30:36 Srikanth Thokala wrote:
> @@ -15,6 +15,9 @@
>  #include 
>  #include 
>  
> +/* Number of AXI DMA APP Words */
> +#define XILINX_DMA_NUM_APP_WORDS   5
> +
>  /**
>   * struct xilinx_vdma_config - VDMA Configuration structure
>   * @frm_dly: Frame delay
> @@ -41,7 +44,21 @@ struct xilinx_vdma_config {
> int ext_fsync;
>  };
>  
> +/**
> + * struct xilinx_dma_config - DMA Configuration structure
> + * @coalesc: Interrupt coalescing threshold
> + * @delay: Delay counter
> + * @reset: Reset Channel
> + */
> +struct xilinx_dma_config {
> +   int coalesc;
> +   int delay;
> +   int reset;
> +};
> +
>  int xilinx_vdma_channel_set_config(struct dma_chan *dchan,
> struct xilinx_vdma_config *cfg);
> +int xilinx_dma_channel_set_config(struct dma_chan *dchan,
> +   struct xilinx_dma_config *cfg);
>  

You add this to a global header file, but I don't see any uses outside
of the driver itself. Please move all of this into the driver itself
and remove the header file.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/2] ARM: dts: socfpga: Fix SD card detect

[Doug Anderson]

Dinh,

On Mon, Oct 20, 2014 at 9:31 AM, Dinh Nguyen
 wrote:
>>>  &mmc0 {
>>> -   cd-gpios = <&gpio1 18 0>;
>>> +   cd = <&gpio1 18 0>;
>>
>> This doesn't look right to me.  What was the error that was passed back?
>>
>> I think your change has the same net effect as just deleting the
>> "cd-gpios" line.  ...or is there some code somewhere that is parsing
>> the "cd" property.
>>
>
> It just hangs here:
>
> dw_mmc ff704000.dwmmc0: Using PIO mode.
> dw_mmc ff704000.dwmmc0: Version ID is 240a
> dw_mmc ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host data
> width, 1024 deep fifo
> platform ff704000.dwmmc0: Driver dw_mmc requests probe deferral
>
>
> Without this patch :
> mmc_of_parse ret=-517 (EPROBE_DEFER)

I think you need to dig more into this error.  Why are you getting an
-EPROBE_DEFER when you asked for this GPIO?

The -EPROBE_DEFER tells the system that a resource is not available
yet and that it should try to re-run the dw_mmc init later once the
resource becomes available.  I believe that some other bug is causing
the resource to never become available.

Guesses:

* The GPIO specifier is wrong in the DTB and is pointing to a GPIO
that would never exist.

* Something is happening in the GPIO driver that is causing it to fail.


...so we need to dig in further.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/2] ARM: dts: socfpga: Fix SD card detect

[Doug Anderson]

Mark,

On Mon, Oct 20, 2014 at 11:41 AM, Mark Rutland  wrote:
> On Mon, Oct 20, 2014 at 04:31:18PM +0100, dingu...@opensource.altera.com 
> wrote:
>> From: Dinh Nguyen 
>>
>> Without this patch, the booting the SOCFPGA platform would hang at the
>> SDMMC driver loading. There were 2 patches that caused this to happen:
>>
>> - Patch 9795a846e10 "mmc: dw_mmc: remove dw_mci_of_cd_gpio/wp_gpio()" removed
>>   looking for "cd-gpios", since mmc_of_parse was getting called.
>> - Patch 3cf890fc42b "mmc: dw_mmc: Pass back errors from mmc_of_parse()" would
>>   hang the system at the SDMMC driver loading.
>
> Regardless of which patches caused the issue, the existing DTB should
> continue to function. This is a kernel bug, not a DTB bug.

Right.  The kernel bug is that there is no "dtb fixup" stage of the
kernel to fix up old dtbs with this dtb bug.

Said another way:

1. The old dtb was (possibly) not specifying the cd-gpio properly.

2. The kernel had a bug where it was ignoring that error.  Things may
have been working because of some other side effect (maybe polling was
working).

3. If we fix the kernel bug, what should we do?  The only sensible
thing (if we need to support old DTB with no changes) is to add a DTB
fixup stage.

...or did someone add that stage and I missed it?

-Doug
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/2] ARM: dts: socfpga: Fix SD card detect

[Dinh Nguyen]

On 10/20/2014 01:41 PM, Mark Rutland wrote:
> On Mon, Oct 20, 2014 at 04:31:18PM +0100, dingu...@opensource.altera.com 
> wrote:
>> From: Dinh Nguyen 
>>
>> Without this patch, the booting the SOCFPGA platform would hang at the
>> SDMMC driver loading. There were 2 patches that caused this to happen:
>>
>> - Patch 9795a846e10 "mmc: dw_mmc: remove dw_mci_of_cd_gpio/wp_gpio()" removed
>>   looking for "cd-gpios", since mmc_of_parse was getting called.
>> - Patch 3cf890fc42b "mmc: dw_mmc: Pass back errors from mmc_of_parse()" would
>>   hang the system at the SDMMC driver loading.
> 
> Regardless of which patches caused the issue, the existing DTB should
> continue to function. This is a kernel bug, not a DTB bug.

I apologize. I made the mistake when I looked at mmc_of_parse(). I made
the mistake when I saw this line of code:

mmc_gpiod_request_cd(host, "cd", 0, true, 0, &gpio_invert);

I thought it was looking for a "cd" property, but it's not.

> 
> How did you track down those two patches as being the cause(s)?

If I revert patch 3cf890fc42b "mmc: dw_mmc: Pass back errors from
mmc_of_parse()", then the system boots and gets past the SDMMC driver
loading, without doing anything else.

Basically, if I remove this change from the 3cf890fc42b patch, then the
system boots and does not hang at the sd driver:

+   ret = mmc_of_parse(mmc);
+   if (ret)
+   goto err_host_allocated;


Patch 9795a846e10 "mmc: dw_mmc: remove dw_mci_of_cd_gpio/wp_gpio()" is
probably not the cause of the problem.


> 
> I've heard a report of a similar issue on a sunxi platform (cubietruck),
> but I have not had the time to investigate.
> 
>> This patch will fix booting with SDMMC enabled on SOCFPGA dev kit.
>>
>> Signed-off-by: Dinh Nguyen 
>> ---
>>  arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts 
>> b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
>> index d7296a5..739c3b7 100644
>> --- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
>> +++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
>> @@ -69,7 +69,7 @@
>>  };
>>  
>>  &mmc0 {
>> -cd-gpios = <&gpio1 18 0>;
>> +cd = <&gpio1 18 0>;
> 
> This change should not be necessary.
> 

Agreed...

Thanks,
Dinh

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/6] arm64: Add DTS support for Spreadtrum's Shark64 SoC

[Arnd Bergmann]

On Wednesday 15 October 2014 11:17:07 Lyra Zhang wrote:
> Hi, Arnd

Hi Lyra,

Sorry for the late reply, I've been away travelling and am just
now catching up on email. Have you found a solution or do
you still need help with this?

Arnd

> 2014-09-29 21:47 GMT+08:00 Arnd Bergmann :
> > On Monday 29 September 2014 20:04:49 zhang.l...@gmail.com wrote:
> >> +
> >> +/memreserve/ 0x8000 0x0001;
> >
> > Maybe add a comment explaining why it is reserved?
> >
> >> + chosen {
> >> + bootargs = "earlycon=serial_sprd,0x7000";
> >> +  };
> >
> > Just remove this for now, the command line should really be set by the
> > boot loader, not hardcoded in the dts file.
> >
> > IIRC, the earlycon=... syntax is not recommended on DT based systems,
> > better use the "stdout-path" syntax instead.
> >
> 
> I have tried to use  "stdout-path" instead of "bootargs= "earlycon=
> ..." like below :
> 
> / {
>  ...
> 
>  chosen {
>  stdout-path = "/serial@7000";
>   };
> 
>  uart0: serial@7000 {
>  status="okay";
>  };
>   ...
> };
> 
> But then there is nothing output information on serial console.(I have
> been testing in Fast Model)
> 
> 
> I saw the below code in init/main.c
> 
> /* Check for early params. */
> static int __init do_early_param(char *param, char *val, const char *unused)
> {
> const struct obs_kernel_param *p;
> 
> for (p = __setup_start; p < __setup_end; p++) {
> if ((p->early && parameq(param, p->str)) ||
>(strcmp(param, "console") == 0 &&
> strcmp(p->str, "earlycon") == 0)
> ) {
> if (p->setup_func(val) != 0)
> pr_warn("Malformed early option '%s'\n", param);
> }
> }
> /* We accept everything at this stage. */
> return 0;
> }
> 
> And I saw a patch from Grant Likely, he had a comment in it :
> "If the devicetree specifies a serial port as a stdout device, then the
> kernel can use it as the default console if nothing else was selected on
> the command line. For any serial port that uses the uart_add_one_port()
> feature, the uart_add_one_port() has all the information needed to
> automatically enable the console device, which is what this patch does."
> 
> So, I guess that the reason why I can't see any output information on
> console after using "stdout-path" instead of "earlycon" is that I
> haven't a driver of Spreadtrum's serial, and dose not use  the
> uart_add_one_port() feature.
> 
> I don't know is correct what I guess.
> 
> Could you give me some suggestions to solve this problem?
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/2] ARM: dts: socfpga: Fix SD card detect

[Mark Rutland]

On Mon, Oct 20, 2014 at 04:31:18PM +0100, dingu...@opensource.altera.com wrote:
> From: Dinh Nguyen 
> 
> Without this patch, the booting the SOCFPGA platform would hang at the
> SDMMC driver loading. There were 2 patches that caused this to happen:
> 
> - Patch 9795a846e10 "mmc: dw_mmc: remove dw_mci_of_cd_gpio/wp_gpio()" removed
>   looking for "cd-gpios", since mmc_of_parse was getting called.
> - Patch 3cf890fc42b "mmc: dw_mmc: Pass back errors from mmc_of_parse()" would
>   hang the system at the SDMMC driver loading.

Regardless of which patches caused the issue, the existing DTB should
continue to function. This is a kernel bug, not a DTB bug.

How did you track down those two patches as being the cause(s)?

I've heard a report of a similar issue on a sunxi platform (cubietruck),
but I have not had the time to investigate.

> This patch will fix booting with SDMMC enabled on SOCFPGA dev kit.
> 
> Signed-off-by: Dinh Nguyen 
> ---
>  arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts 
> b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
> index d7296a5..739c3b7 100644
> --- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
> +++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
> @@ -69,7 +69,7 @@
>  };
>  
>  &mmc0 {
> - cd-gpios = <&gpio1 18 0>;
> + cd = <&gpio1 18 0>;

This change should not be necessary.

Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html