from:"Karicheri, Muralidharan"

>-Original Message-
>From: David Laight [mailto:david.lai...@aculab.com]
>Sent: Tuesday, February 09, 2016 11:38 AM
>To: Karicheri, Muralidharan; Strashko, Grygorii; net...@vger.kernel.org; David 
>S . Miller;
>Arnd Bergmann
>Cc: Cooper Jr., Franklin; Nori, Sekhar; linux-kernel@vger.kernel.org; Kwok, 
>WingMan; N,
>Mugunthan V
>Subject: RE: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality
>
>From: Karicheri, Muralidharan
>> Sent: 09 February 2016 16:19
>> >...
>> >> >In reality the 'pad' fields ought to be renamed - since they aren't pads.
>> >> >Perhaps they should be a union?
>> >
>> >> No. At the end of the descriptor, host software can add scratchpad
>> >> which is not modified by the hardware, but is used by the driver.
>> >> So please don't rename.
>> >
>> >So comment in the definition that the hardware doesn't modify them.
>> >The driver is defining these fields and they are definitely NOT padding.
>>
>>
>> It is scratch pad, not padding. Looks like pad is a confusing name.
>> Can be renamed to sw_data to be in sync with spec below.
>>
>> The hardware spec from
>> http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf
>>
>> The other SW data portion of the descriptor exists after all of the
>> defined words and is reserved for use by the host software to store
>> completely private data. This region is not used in any way by the DMA
>> or queue manager modules in a Multicore Navigator system and these
>> modules will not modify any bytes within this region.
>
>Right, so comment that the hardware doesn't look at the fields.
>But name/type the structure fields to indicate what they contain.
>Maybe sw_buf_len etc - but I suspect there are much more meaningful names.

The descriptors are usable by different drivers, one driver may use it as 
buf ptr/ len, other for something else. So they should remain as generic
and it is up to individual drivers to use it in whatever way it requires.
My suggestion is to rename pad field in struct knav_dma_desc to sw_data
to avoid confusion. i.e 

+   __le32  pad[4];

to 

+   __le32  sw_data[4];

Murali
>
>   David

RE: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality



Murali Karicheri
Linux Kernel, Software Development


>-Original Message-
>From: David Laight [mailto:david.lai...@aculab.com]
>Sent: Tuesday, February 09, 2016 11:10 AM
>To: Karicheri, Muralidharan; Strashko, Grygorii; net...@vger.kernel.org; David 
>S . Miller;
>Arnd Bergmann
>Cc: Cooper Jr., Franklin; Nori, Sekhar; linux-kernel@vger.kernel.org; Kwok, 
>WingMan; N,
>Mugunthan V
>Subject: RE: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality
>
>From: Karicheri, Muralidharan
>> Sent: 09 February 2016 16:10
>...
>> >In reality the 'pad' fields ought to be renamed - since they aren't pads.
>> >Perhaps they should be a union?
>
>> No. At the end of the descriptor, host software can add scratchpad
>> which is not modified by the hardware, but is used by the driver. So
>> please don't rename.
>
>So comment in the definition that the hardware doesn't modify them.
>The driver is defining these fields and they are definitely NOT padding.


It is scratch pad, not padding. Looks like pad is a confusing name. Can be
renamed to sw_data to be in sync with spec below.

The hardware spec from 
http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf

The other SW data portion of the descriptor exists after all of the defined
words and is reserved for use by the host software to store completely
private data. This region is not used in any way by the DMA or queue manager
modules in a Multicore Navigator system and these modules will not modify
any bytes within this region.

Murali
>
>   David

RE: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality

>-Original Message-
>From: David Laight [mailto:david.lai...@aculab.com]
>Sent: Tuesday, February 09, 2016 9:13 AM
>To: Strashko, Grygorii; net...@vger.kernel.org; David S . Miller; Arnd Bergmann
>Cc: Cooper Jr., Franklin; Nori, Sekhar; linux-kernel@vger.kernel.org; Kwok, 
>WingMan;
>Karicheri, Muralidharan; N, Mugunthan V
>Subject: RE: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality
>
>From: Grygorii Strashko
>> Sent: 09 February 2016 13:58
>> From: Arnd Bergmann 
>>
>> The commit 899077791403 ("netcp: try to reduce type confusion in
>> descriptors") introduces a regression in Kernel 4.5-rc1 and it breaks
>> get/set_pad_info() functionality.
>>
>> The TI NETCP driver uses pad0 and pad1 fields of knav_dma_desc to
>> store DMA/MEM buffer pointer and buffer size respectively. And in both
>> cases for Keystone 2 the pointer type size is 32 bit regardless of
>> LAPE enabled or not, because CONFIG_ARCH_DMA_ADDR_T_64BIT originally
>> is not expected to be defined.
>>
>>  !LAPE   LPAE
>> sizeof(void*)32bit   32bit
>> sizeof(dma_addr_t)   32bit   32bit
>> sizeof(phys_addr_t)  32bit   64bit
>>
>> Unfortunately, above commit changed buffer's pointers save/restore
>> code (get/set_pad_info()) and added intermediate conversation to u64
>> which works incorrectly on 32bit Keystone 2 and causes TI NETCP driver
>> crash in RX/TX path due to "Unable to handle kernel NULL pointer"
>> exception. This issue was reported and discussed in [1].
>>
>> Hence, fix it by partially reverting above commit and restoring
>> get/set_pad_info() functionality as it was before.
>
>You should really get rid of most of the horrid pointer-integer casts.
>Code like:
>>  void *buf_ptr;
>...
>> +get_pad_info((u32 *)_ptr, _len, ndesc);
>is just asking for trouble.
>
>You'd be better using assignments like:
>   buf_ptr = (cast)get_pad_0(ndesc);
>   buf_len = get_pad_1(ndesc);
>Then the values are passed (and cast) as numerics.
>
>In reality the 'pad' fields ought to be renamed - since they aren't pads.
>Perhaps they should be a union?
No. At the end of the descriptor, host software can add scratchpad which is
not modified by the hardware, but is used by the driver. So please don't
rename.

Murali
>
>   David

RE: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality

>-Original Message-
>From: David Laight [mailto:david.lai...@aculab.com]
>Sent: Tuesday, February 09, 2016 9:13 AM
>To: Strashko, Grygorii; net...@vger.kernel.org; David S . Miller; Arnd Bergmann
>Cc: Cooper Jr., Franklin; Nori, Sekhar; linux-kernel@vger.kernel.org; Kwok, 
>WingMan;
>Karicheri, Muralidharan; N, Mugunthan V
>Subject: RE: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality
>
>From: Grygorii Strashko
>> Sent: 09 February 2016 13:58
>> From: Arnd Bergmann <a...@arndb.de>
>>
>> The commit 899077791403 ("netcp: try to reduce type confusion in
>> descriptors") introduces a regression in Kernel 4.5-rc1 and it breaks
>> get/set_pad_info() functionality.
>>
>> The TI NETCP driver uses pad0 and pad1 fields of knav_dma_desc to
>> store DMA/MEM buffer pointer and buffer size respectively. And in both
>> cases for Keystone 2 the pointer type size is 32 bit regardless of
>> LAPE enabled or not, because CONFIG_ARCH_DMA_ADDR_T_64BIT originally
>> is not expected to be defined.
>>
>>  !LAPE   LPAE
>> sizeof(void*)32bit   32bit
>> sizeof(dma_addr_t)   32bit   32bit
>> sizeof(phys_addr_t)  32bit   64bit
>>
>> Unfortunately, above commit changed buffer's pointers save/restore
>> code (get/set_pad_info()) and added intermediate conversation to u64
>> which works incorrectly on 32bit Keystone 2 and causes TI NETCP driver
>> crash in RX/TX path due to "Unable to handle kernel NULL pointer"
>> exception. This issue was reported and discussed in [1].
>>
>> Hence, fix it by partially reverting above commit and restoring
>> get/set_pad_info() functionality as it was before.
>
>You should really get rid of most of the horrid pointer-integer casts.
>Code like:
>>  void *buf_ptr;
>...
>> +get_pad_info((u32 *)_ptr, _len, ndesc);
>is just asking for trouble.
>
>You'd be better using assignments like:
>   buf_ptr = (cast)get_pad_0(ndesc);
>   buf_len = get_pad_1(ndesc);
>Then the values are passed (and cast) as numerics.
>
>In reality the 'pad' fields ought to be renamed - since they aren't pads.
>Perhaps they should be a union?
No. At the end of the descriptor, host software can add scratchpad which is
not modified by the hardware, but is used by the driver. So please don't
rename.

Murali
>
>   David

RE: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality



Murali Karicheri
Linux Kernel, Software Development


>-Original Message-
>From: David Laight [mailto:david.lai...@aculab.com]
>Sent: Tuesday, February 09, 2016 11:10 AM
>To: Karicheri, Muralidharan; Strashko, Grygorii; net...@vger.kernel.org; David 
>S . Miller;
>Arnd Bergmann
>Cc: Cooper Jr., Franklin; Nori, Sekhar; linux-kernel@vger.kernel.org; Kwok, 
>WingMan; N,
>Mugunthan V
>Subject: RE: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality
>
>From: Karicheri, Muralidharan
>> Sent: 09 February 2016 16:10
>...
>> >In reality the 'pad' fields ought to be renamed - since they aren't pads.
>> >Perhaps they should be a union?
>
>> No. At the end of the descriptor, host software can add scratchpad
>> which is not modified by the hardware, but is used by the driver. So
>> please don't rename.
>
>So comment in the definition that the hardware doesn't modify them.
>The driver is defining these fields and they are definitely NOT padding.


It is scratch pad, not padding. Looks like pad is a confusing name. Can be
renamed to sw_data to be in sync with spec below.

The hardware spec from 
http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf

The other SW data portion of the descriptor exists after all of the defined
words and is reserved for use by the host software to store completely
private data. This region is not used in any way by the DMA or queue manager
modules in a Multicore Navigator system and these modules will not modify
any bytes within this region.

Murali
>
>   David

RE: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality

>-Original Message-
>From: David Laight [mailto:david.lai...@aculab.com]
>Sent: Tuesday, February 09, 2016 11:38 AM
>To: Karicheri, Muralidharan; Strashko, Grygorii; net...@vger.kernel.org; David 
>S . Miller;
>Arnd Bergmann
>Cc: Cooper Jr., Franklin; Nori, Sekhar; linux-kernel@vger.kernel.org; Kwok, 
>WingMan; N,
>Mugunthan V
>Subject: RE: [PATCH] net: ti: netcp: restore get/set_pad_info() functionality
>
>From: Karicheri, Muralidharan
>> Sent: 09 February 2016 16:19
>> >...
>> >> >In reality the 'pad' fields ought to be renamed - since they aren't pads.
>> >> >Perhaps they should be a union?
>> >
>> >> No. At the end of the descriptor, host software can add scratchpad
>> >> which is not modified by the hardware, but is used by the driver.
>> >> So please don't rename.
>> >
>> >So comment in the definition that the hardware doesn't modify them.
>> >The driver is defining these fields and they are definitely NOT padding.
>>
>>
>> It is scratch pad, not padding. Looks like pad is a confusing name.
>> Can be renamed to sw_data to be in sync with spec below.
>>
>> The hardware spec from
>> http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf
>>
>> The other SW data portion of the descriptor exists after all of the
>> defined words and is reserved for use by the host software to store
>> completely private data. This region is not used in any way by the DMA
>> or queue manager modules in a Multicore Navigator system and these
>> modules will not modify any bytes within this region.
>
>Right, so comment that the hardware doesn't look at the fields.
>But name/type the structure fields to indicate what they contain.
>Maybe sw_buf_len etc - but I suspect there are much more meaningful names.

The descriptors are usable by different drivers, one driver may use it as 
buf ptr/ len, other for something else. So they should remain as generic
and it is up to individual drivers to use it in whatever way it requires.
My suggestion is to rename pad field in struct knav_dma_desc to sw_data
to avoid confusion. i.e 

+   __le32  pad[4];

to 

+   __le32  sw_data[4];

Murali
>
>   David

RE: [PATCH v2 03/18] PCI: designware: Configuration space should be specified in 'reg'

2014-05-30 Thread Karicheri, Muralidharan

>-Original Message-
>From: Murali Karicheri [mailto:m-kariche...@ti.com]
>Sent: Thursday, May 29, 2014 12:32 PM
>To: ABRAHAM, KISHON VIJAY
>Cc: devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-
>ker...@lists.infradead.org; linux-o...@vger.kernel.org; 
>linux-...@vger.kernel.org; linux-
>ker...@vger.kernel.org; a...@arndb.de; t...@atomide.com; jg1@samsung.com;
>Jason Gunthorpe; Bjorn Helgaas; Mohit Kumar; Marek Vasut
>Subject: Re: [PATCH v2 03/18] PCI: designware: Configuration space should be 
>specified
>in 'reg'
>
>On 5/29/2014 2:38 AM, ABRAHAM, KISHON VIJAY wrote:
>> The configuration address space has so far been specified in *ranges*,
>> however it should be specified in *reg* making it a platform MEM resource.
>> Hence used 'platform_get_resource_*' API to get configuration address
>> space in the designware driver.
>>
>> Cc: Jason Gunthorpe 
>> Cc: Bjorn Helgaas 
>> Cc: Mohit Kumar 
>> Cc: Jingoo Han 
>> Cc: Marek Vasut 
>> Cc: Arnd Bergmann 
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>   .../devicetree/bindings/pci/designware-pcie.txt|1 +
>>   drivers/pci/host/pcie-designware.c |   17 +++--
>>   2 files changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
>> b/Documentation/devicetree/bindings/pci/designware-pcie.txt
>> index d6fae13..8314360 100644
>> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
>> @@ -6,6 +6,7 @@ Required properties:
>>  as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie".
>>   - reg: base addresses and lengths of the pcie controller,
>>  the phy controller, additional register for the phy controller.
>> +The configuration address space should also be specified here.
>Kishon,
>
>I am working on the Keystone PCI driver for which v1 is already posted.
>Want to clarify
>following.
>1. Original text for reg states "base addresses and lengths of the pcie 
>controller,
> the phy controller, additional register for the phy controller"
>and you added
> "The configuration address space should also be specified here"
>
>and the code below added resource name "config"
>
>Does PCI designware follow some convention? Does it mean after applying this 
>patch
>config name is mandatory or optional? Below code you are not returning error. 
>Can you or
>author of PCI designware clarify what is expected to be present as mandatory 
>and what is
>optional.
>
>Does config refers to RC's config space or EP's config space or both?
>The code below divide
>the size by 2. So it appears to be RC's + EP's config space. Please clarify.
>
>>   - interrupts: interrupt values for level interrupt,
>>  pulse interrupt, special interrupt.
>>   - clocks: from common clock binding: handle to pci clock.
>> diff --git a/drivers/pci/host/pcie-designware.c
>> b/drivers/pci/host/pcie-designware.c
>> index c4e3732..603b386 100644
>> --- a/drivers/pci/host/pcie-designware.c
>> +++ b/drivers/pci/host/pcie-designware.c
>> @@ -20,6 +20,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>
>>   #include "pcie-designware.h"
>> @@ -392,11 +393,23 @@ static const struct irq_domain_ops msi_domain_ops = {
>>   int __init dw_pcie_host_init(struct pcie_port *pp)
>>   {
>>  struct device_node *np = pp->dev->of_node;
>> +struct platform_device *pdev = to_platform_device(pp->dev);
>>  struct of_pci_range range;
>>  struct of_pci_range_parser parser;
>> +struct resource *cfg_res;
>>  u32 val;
>>  int i;
>>
>> +cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
>> +if (cfg_res) {
>> +pp->config.cfg0_size = resource_size(cfg_res)/2;
>> +pp->config.cfg1_size = resource_size(cfg_res)/2;
>> +pp->cfg0_base = cfg_res->start;
>> +pp->cfg1_base = cfg_res->start + pp->config.cfg0_size;
>> +} else {
>> +dev_err(pp->dev, "missing *config* reg space\n");
>This should return error -EINVAL.
>
>> +}
>> +
>>  if (of_pci_range_parser_init(, np)) {
>>  dev_err(pp->dev, "missing ranges property\n");
>>  return -EINVAL;
>> @@ -429,6 +442,8 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
>>  of_pci_range_to_resource(, np, >cfg);
>>  pp->config.cfg0_size = resource_size(>cfg)/2;
>>  pp->config.cfg1_size = resource_size(>cfg)/2;
>> +pp->cfg0_base = pp->cfg.start;
>> +pp->cfg1_base = pp->cfg.start + pp->config.cfg0_size;
>>  }
>>  }
>>
>> @@ -441,8 +456,6 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
>>  }
>>  }
>>
>> -pp->cfg0_base = pp->cfg.start;
>> -pp->cfg1_base = pp->cfg.start + pp->config.cfg0_size;
>>  pp->mem_base = pp->mem.start;
>>
>>  pp->va_cfg0_base =

RE: [PATCH v2 03/18] PCI: designware: Configuration space should be specified in 'reg'

2014-05-30 Thread Karicheri, Muralidharan

-Original Message-
From: Murali Karicheri [mailto:m-kariche...@ti.com]
Sent: Thursday, May 29, 2014 12:32 PM
To: ABRAHAM, KISHON VIJAY
Cc: devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; linux-o...@vger.kernel.org; 
linux-...@vger.kernel.org; linux-
ker...@vger.kernel.org; a...@arndb.de; t...@atomide.com; jg1@samsung.com;
Jason Gunthorpe; Bjorn Helgaas; Mohit Kumar; Marek Vasut
Subject: Re: [PATCH v2 03/18] PCI: designware: Configuration space should be 
specified
in 'reg'

On 5/29/2014 2:38 AM, ABRAHAM, KISHON VIJAY wrote:
 The configuration address space has so far been specified in *ranges*,
 however it should be specified in *reg* making it a platform MEM resource.
 Hence used 'platform_get_resource_*' API to get configuration address
 space in the designware driver.

 Cc: Jason Gunthorpe jguntho...@obsidianresearch.com
 Cc: Bjorn Helgaas bhelg...@google.com
 Cc: Mohit Kumar mohit.ku...@st.com
 Cc: Jingoo Han jg1@samsung.com
 Cc: Marek Vasut ma...@denx.de
 Cc: Arnd Bergmann a...@arndb.de
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
   .../devicetree/bindings/pci/designware-pcie.txt|1 +
   drivers/pci/host/pcie-designware.c |   17 +++--
   2 files changed, 16 insertions(+), 2 deletions(-)

 diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
 b/Documentation/devicetree/bindings/pci/designware-pcie.txt
 index d6fae13..8314360 100644
 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
 +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
 @@ -6,6 +6,7 @@ Required properties:
  as samsung,exynos5440-pcie or fsl,imx6q-pcie.
   - reg: base addresses and lengths of the pcie controller,
  the phy controller, additional register for the phy controller.
 +The configuration address space should also be specified here.
Kishon,

I am working on the Keystone PCI driver for which v1 is already posted.
Want to clarify
following.
1. Original text for reg states base addresses and lengths of the pcie 
controller,
 the phy controller, additional register for the phy controller
and you added
 The configuration address space should also be specified here

and the code below added resource name config

Does PCI designware follow some convention? Does it mean after applying this 
patch
config name is mandatory or optional? Below code you are not returning error. 
Can you or
author of PCI designware clarify what is expected to be present as mandatory 
and what is
optional.

Does config refers to RC's config space or EP's config space or both?
The code below divide
the size by 2. So it appears to be RC's + EP's config space. Please clarify.

   - interrupts: interrupt values for level interrupt,
  pulse interrupt, special interrupt.
   - clocks: from common clock binding: handle to pci clock.
 diff --git a/drivers/pci/host/pcie-designware.c
 b/drivers/pci/host/pcie-designware.c
 index c4e3732..603b386 100644
 --- a/drivers/pci/host/pcie-designware.c
 +++ b/drivers/pci/host/pcie-designware.c
 @@ -20,6 +20,7 @@
   #include linux/of_pci.h
   #include linux/pci.h
   #include linux/pci_regs.h
 +#include linux/platform_device.h
   #include linux/types.h

   #include pcie-designware.h
 @@ -392,11 +393,23 @@ static const struct irq_domain_ops msi_domain_ops = {
   int __init dw_pcie_host_init(struct pcie_port *pp)
   {
  struct device_node *np = pp-dev-of_node;
 +struct platform_device *pdev = to_platform_device(pp-dev);
  struct of_pci_range range;
  struct of_pci_range_parser parser;
 +struct resource *cfg_res;
  u32 val;
  int i;

 +cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, config);
 +if (cfg_res) {
 +pp-config.cfg0_size = resource_size(cfg_res)/2;
 +pp-config.cfg1_size = resource_size(cfg_res)/2;
 +pp-cfg0_base = cfg_res-start;
 +pp-cfg1_base = cfg_res-start + pp-config.cfg0_size;
 +} else {
 +dev_err(pp-dev, missing *config* reg space\n);
This should return error -EINVAL.

 +}
 +
  if (of_pci_range_parser_init(parser, np)) {
  dev_err(pp-dev, missing ranges property\n);
  return -EINVAL;
 @@ -429,6 +442,8 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
  of_pci_range_to_resource(range, np, pp-cfg);
  pp-config.cfg0_size = resource_size(pp-cfg)/2;
  pp-config.cfg1_size = resource_size(pp-cfg)/2;
 +pp-cfg0_base = pp-cfg.start;
 +pp-cfg1_base = pp-cfg.start + pp-config.cfg0_size;
  }
  }

 @@ -441,8 +456,6 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
  }
  }

 -pp-cfg0_base = pp-cfg.start;
 -pp-cfg1_base = pp-cfg.start + pp-config.cfg0_size;
  pp-mem_base = pp-mem.start;

  pp-va_cfg0_base = devm_ioremap(pp-dev, pp-cfg0_base,
BTW, Please

RE: [RFC PATCH] pcie-designware: DT documentation update to clarify DT properties

2014-05-21 Thread Karicheri, Muralidharan

>-Original Message-
>From: Karicheri, Muralidharan
>Sent: Wednesday, May 21, 2014 6:52 PM
>To: jg1@samsung.com; x...@kosagi.com; devicet...@vger.kernel.org; linux-
>d...@vger.kernel.org; linux-kernel@vger.kernel.org; a...@arndb.de
>Cc: Karicheri, Muralidharan; Mohit Kumar; Pratyush Anand; Richard Zhu; ABRAHAM,
>KISHON VIJAY; Marek Vasut
>Subject: [RFC PATCH] pcie-designware: DT documentation update to clarify DT 
>properties
>
>Current documentation is not clear enough about the mandatory bindings to be 
>present in
>the device node of a snps,dw-pcie compatible pcie controller. In some cases 
>the property is
>not present in all drivers.
>For example pcie_bus is specified as a clock, but only one of the driver uses 
>it. This patch
>attempts to make the documentation consistent with current implementation so 
>that it is
>clear enough for anyone who develops a dw-pcie compatible pcie driver.
>
>CC: Mohit Kumar 
>CC: Jingoo Han 
>CC: Pratyush Anand 
>CC: Richard Zhu 
>CC: Kishon Vijay Abraham I 
>CC: Marek Vasut 
>
>Signed-off-by: Murali Karicheri 
>---
> .../devicetree/bindings/pci/designware-pcie.txt|   10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
>diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
>b/Documentation/devicetree/bindings/pci/designware-pcie.txt
>index d6fae13..8b9dc52 100644
>--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
>+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
>@@ -4,12 +4,14 @@ Required properties:
> - compatible: should contain "snps,dw-pcie" to identify the
>   core, plus an identifier for the specific instance, such
>   as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie".
>-- reg: base addresses and lengths of the pcie controller,
>-  the phy controller, additional register for the phy controller.
>+- reg: base addresses and lengths of the pcie controller.
>+index 0 - base address and length of RC's config space.
>+index 1 and above: additional registers for the PCI controller
>+that are specific to an implementation.
> - interrupts: interrupt values for level interrupt,
>   pulse interrupt, special interrupt.
>-- clocks: from common clock binding: handle to pci clock.
>-- clock-names: from common clock binding: should be "pcie" and "pcie_bus".
>+- clocks: from common clock binding: handle to list of pci clock.
>+- clock-names: from common clock binding: pci clock names: "pcie"
> - #address-cells: set to <3>
> - #size-cells: set to <2>
> - device_type: set to "pci"
>--
>1.7.9.5

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

RE: [RFC PATCH] pcie-designware: DT documentation update to clarify DT properties

2014-05-21 Thread Karicheri, Muralidharan

-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, May 21, 2014 6:52 PM
To: jg1@samsung.com; x...@kosagi.com; devicet...@vger.kernel.org; linux-
d...@vger.kernel.org; linux-kernel@vger.kernel.org; a...@arndb.de
Cc: Karicheri, Muralidharan; Mohit Kumar; Pratyush Anand; Richard Zhu; ABRAHAM,
KISHON VIJAY; Marek Vasut
Subject: [RFC PATCH] pcie-designware: DT documentation update to clarify DT 
properties

Current documentation is not clear enough about the mandatory bindings to be 
present in
the device node of a snps,dw-pcie compatible pcie controller. In some cases 
the property is
not present in all drivers.
For example pcie_bus is specified as a clock, but only one of the driver uses 
it. This patch
attempts to make the documentation consistent with current implementation so 
that it is
clear enough for anyone who develops a dw-pcie compatible pcie driver.

CC: Mohit Kumar mohit.ku...@st.com
CC: Jingoo Han jg1@samsung.com
CC: Pratyush Anand pratyush.an...@st.com
CC: Richard Zhu r65...@freescale.com
CC: Kishon Vijay Abraham I kis...@ti.com
CC: Marek Vasut ma...@denx.de

Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
 .../devicetree/bindings/pci/designware-pcie.txt|   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index d6fae13..8b9dc52 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -4,12 +4,14 @@ Required properties:
 - compatible: should contain snps,dw-pcie to identify the
   core, plus an identifier for the specific instance, such
   as samsung,exynos5440-pcie or fsl,imx6q-pcie.
-- reg: base addresses and lengths of the pcie controller,
-  the phy controller, additional register for the phy controller.
+- reg: base addresses and lengths of the pcie controller.
+index 0 - base address and length of RC's config space.
+index 1 and above: additional registers for the PCI controller
+that are specific to an implementation.
 - interrupts: interrupt values for level interrupt,
   pulse interrupt, special interrupt.
-- clocks: from common clock binding: handle to pci clock.
-- clock-names: from common clock binding: should be pcie and pcie_bus.
+- clocks: from common clock binding: handle to list of pci clock.
+- clock-names: from common clock binding: pci clock names: pcie
 - #address-cells: set to 3
 - #size-cells: set to 2
 - device_type: set to pci
--
1.7.9.5

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

RE: [PATCH v1 4/5] pci: dw: add common functions to support old hw based pci driver

Adding more people to the list for review.
>-Original Message-
>From: Karicheri, Muralidharan
>Sent: Thursday, May 15, 2014 12:02 PM
>To: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-
>ker...@lists.infradead.org
>Cc: Karicheri, Muralidharan; Shilimkar, Santosh; Mohit Kumar; Jingoo Han; 
>Bjorn Helgaas
>Subject: [PATCH v1 4/5] pci: dw: add common functions to support old hw based 
>pci driver
>
>The older version of DW hw has application space registers for MSI controller 
>and
>inbound/outbound access configuration. Also the legacy interrupt has registers 
>in the
>application space. Drivers such as keystone pci uses these common functions to 
>implement
>the driver.
>These are re-factored from the original driver to separate files to allow 
>re-use for the next
>driver that is based on old dw pci hw such as that found on keystone.
>
>CC: Santosh Shilimkar 
>CC: Mohit Kumar 
>CC: Jingoo Han 
>CC: Bjorn Helgaas 
>
>Signed-off-by: Murali Karicheri 
>---
> drivers/pci/host/Kconfig  |6 +-
> drivers/pci/host/Makefile |1 +
> drivers/pci/host/pci-dw-old-msi.c |  150 +++
> drivers/pci/host/pci-dw-old.c |  371
>+
> drivers/pci/host/pci-dw-old.h |   30 +++
> 5 files changed, 557 insertions(+), 1 deletion(-)  create mode 100644 
> drivers/pci/host/pci-
>dw-old-msi.c  create mode 100644 drivers/pci/host/pci-dw-old.c  create mode 
>100644
>drivers/pci/host/pci-dw-old.h
>
>diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index 
>a6f67ec..c4f4732
>100644
>--- a/drivers/pci/host/Kconfig
>+++ b/drivers/pci/host/Kconfig
>@@ -9,6 +9,11 @@ config PCI_MVEBU
> config PCIE_DW
>   bool
>
>+config PCI_DW_OLD
>+  bool "Designware Old PCIe h/w"
>+  help
>+ Say Y here if the DW h/w is old version (3.65)
>+
> config PCI_EXYNOS
>   bool "Samsung Exynos PCIe controller"
>   depends on SOC_EXYNOS5440
>@@ -32,5 +37,4 @@ config PCI_RCAR_GEN2
> Say Y here if you want internal PCI support on R-Car Gen2 SoC.
> There are 3 internal PCI controllers available with a single
> built-in EHCI/OHCI host controller present on each one.
>-
> endmenu
>diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile index 
>13fb333..be5d939
>100644
>--- a/drivers/pci/host/Makefile
>+++ b/drivers/pci/host/Makefile
>@@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
> obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
> obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
> obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
>+obj-$(CONFIG_PCI_DW_OLD) += pci-dw-old-msi.o pci-dw-old.o
>diff --git a/drivers/pci/host/pci-dw-old-msi.c 
>b/drivers/pci/host/pci-dw-old-msi.c
>new file mode 100644
>index 000..450bb2f
>--- /dev/null
>+++ b/drivers/pci/host/pci-dw-old-msi.c
>@@ -0,0 +1,150 @@
>+/*
>+ * Designware(dw) old MSI controller (v3.65 or similar)
>+ *
>+ * Copyright (C) 2013-2014 Texas Instruments., Ltd.
>+ *http://www.ti.com
>+ *
>+ * Author: Murali Karicheri 
>+ *
>+ *
>+ * This program is free software; you can redistribute it and/or modify
>+ * it under the terms of the GNU General Public License version 2 as
>+ * published by the Free Software Foundation.
>+ */
>+
>+#include 
>+#include 
>+#include 
>+#include 
>+
>+#include "pcie-designware.h"
>+#include "pci-dw-old.h"
>+
>+#define MSI_IRQ   0x054
>+#define MSI0_IRQ_STATUS   0x104
>+#define MSI0_IRQ_ENABLE_SET   0x108
>+#define MSI0_IRQ_ENABLE_CLR   0x10c
>+#define IRQ_STATUS0x184
>+#define IRQ_EOI 0x050
>+#define MSI_IRQ_OFFSET4
>+
>+static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys) {
>+  return sys->private_data;
>+}
>+
>+static inline void update_reg_offset_bit_pos(u32 offset, u32 *reg_offset,
>+  u32 *bit_pos)
>+{
>+  *reg_offset = offset % 8;
>+  *bit_pos = offset >> 3;
>+}
>+
>+inline u32 dw_old_get_msi_data(struct pcie_port *pp) {
>+  return pp->app_base + MSI_IRQ;
>+}
>+
>+void dw_old_handle_msi_irq(struct pcie_port *pp, int offset) {
>+  u32 pending, vector;
>+  int src, virq;
>+
>+  pending = readl(pp->va_app_base + MSI0_IRQ_STATUS + (offset << 4));
>+  /*
>+   * MSI0, Status bit 0-3 shows vectors 0, 8, 16, 24, MSI1 status bit
>+   * shows 1, 9, 17, 25 and so forth
>+   */
>+  for (src = 0; src < 4; src++) {
>+  if

RE: [PATCH v1 5/5] pci: keystone: add pcie driver based on designware core driver

Adding more people to the list for review.

>-Original Message-
>From: Karicheri, Muralidharan
>Sent: Thursday, May 15, 2014 12:02 PM
>To: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-
>ker...@lists.infradead.org
>Cc: Karicheri, Muralidharan; Shilimkar, Santosh; Mohit Kumar; Jingoo Han; 
>Bjorn Helgaas;
>Strashko, Grygorii
>Subject: [PATCH v1 5/5] pci: keystone: add pcie driver based on designware 
>core driver
>
>keystone pcie hardware is based on designware version 3.65.
>This driver make use of the functions from pci-dw-old.c and pci-dw-old-msi.c 
>to implement
>the driver.
>
>Driver mainly handle the platform specific part of the PCI driver and depends 
>on DW Old
>driver to configure application specific registers. Also routes the irq events 
>and ack the
>interrupt after the same is acked by the end point device driver. This 
>requires irqchip
>implementation for legacy and MSI irq handling. This patch adds a quirks to 
>override the
>max read request size as PCI controller has a limit of 256 bytes.
>
>CC: Santosh Shilimkar 
>CC: Mohit Kumar 
>CC: Jingoo Han 
>CC: Bjorn Helgaas 
>
>Signed-off-by: Murali Karicheri 
>Signed-off-by: Grygorii Strashko 
>---
> .../devicetree/bindings/pci/pcie-keystone.txt  |   68 
> drivers/pci/host/Kconfig   |8 +
> drivers/pci/host/Makefile  |1 +
> drivers/pci/host/pci-keystone.c|  400 
> drivers/pci/quirks.c   |   13 +
> 5 files changed, 490 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/pcie-keystone.txt
> create mode 100644 drivers/pci/host/pci-keystone.c
>
>diff --git a/Documentation/devicetree/bindings/pci/pcie-keystone.txt
>b/Documentation/devicetree/bindings/pci/pcie-keystone.txt
>new file mode 100644
>index 000..17cf261
>--- /dev/null
>+++ b/Documentation/devicetree/bindings/pci/pcie-keystone.txt
>@@ -0,0 +1,68 @@
>+Keystone PCIE Root complex device tree bindings
>+---
>+
>+Sample bindings shown below:-
>+
>+ - Remove ti,enable-linktrain if boot loader already does Link training and 
>do EP
>+   configuration.
>+ - Remove ti,init-phy if boot loader already initialize the phy and sets up 
>pcie
>+   link
>+
>+  pcie0_phy: pciephy@232 {
>+  #address-cells = <1>;
>+  #size-cells = <1>;
>+  #phy-cells = <0>;
>+  compatible = "ti,keystone-phy";
>+  reg = <0x0232 0x4000>;
>+  reg-names = "reg_serdes";
>+  };
>+
>+  pcie@2180 {
>+  compatible = "ti,keystone-pcie";
>+  device_type = "pci";
>+  clocks = <>;
>+  clock-names = "pcie";
>+  #address-cells = <3>;
>+  #size-cells = <2>;
>+  reg =  <0x2180 0x1000>, <0x0262014c 4>;
>+  reg-names = "reg_rc_app", "reg_devcfg";
>+  interrupts = ,
>+  ,
>+  ,
>+  ,
>+  ,
>+  ,
>+  ,
>+  ,
>+  ; /* 
>Error IRQ */
>+
>+  ranges = <0x0800 0 0x21801000 0x21801000 0 
>0x0002000/*
>Configuration space */
>+0x8100 0 0  0x2400 0 0x4000   
>/* downstream
>I/O */
>+0x8200 0 0x5000 0x5000 0 
>0x1000>; /*
>+non-prefetchable memory */
>+
>+  num-lanes = <2>;
>+  ti,enable-linktrain;
>+  ti,init-phy;
>+
>+  /* PCIE phy */
>+  phys = <_phy>;
>+  phy-names = "pcie-phy";
>+
>+  #interrupt-cells = <1>;
>+  interrupt-map-mask = <0 0 0 0>;
>+  interrupt-map = <0 0 0 1 _intc 1>, // INT A
>+  <0 0 0 2 _intc 2>, // INT B
>+  <0 0 0 3 _intc 3>, // INT C
>+  <0 0 0 4 _

RE: [PATCH v1 2/5] pci: designware: enhancements to support keystone pcie

Adding more to list.

>-Original Message-
>From: Karicheri, Muralidharan
>Sent: Thursday, May 15, 2014 12:01 PM
>To: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-
>ker...@lists.infradead.org
>Cc: Karicheri, Muralidharan; Mohit Kumar; Jingoo Han; Bjorn Helgaas; 
>Shilimkar, Santosh
>Subject: [PATCH v1 2/5] pci: designware: enhancements to support keystone pcie
>
>keystone pcie hardware is based on designware hw version 3.65.
>There is no support for ATU port and has registers in application space to 
>configure
>inbound/outbound access. Also doesn't support PCI PVM option. The MSI IRQ 
>registers
>available in application space is used to mask/unmask/enable the MSI IRQs.
>
>DW core driver is a set of common functions that are abstracted to support DW 
>pci drivers.
>To allow re-use of these functions for keystone pci driver, core driver is to 
>be enhanced.
>
>Following are done to allow re-use of the functions on keystone pci driver.
>
> 1. Some of the variables in pcie_port struct is folded inside
>a union that now contains both new DW hw related variables as well
>as old hardware related variables such as application reg base.
> 2. Added a dw_pcie_common_host_init() function that holds common
>host initialization code for old and new hw.
> 3. dw_pcie_parse_resource() is used for parsing resource related
>information from DT bindings.
> 4. dw_pcie_host_init() is called by new DW hw drivers as before.
>Added dw_old_pcie_host_init() is it's counter part on old dw hw.
>Both these functions now call dw_pcie_common_host_init().
> 5. Some of the static functions are made global to allow use from
>dw old pci drivers such as pci-keystone.
>
>CC: Mohit Kumar 
>CC: Jingoo Han 
>CC: Bjorn Helgaas 
>CC: Santosh Shilimkar 
>
>Signed-off-by: Murali Karicheri 
>---
> drivers/pci/host/pcie-designware.c |  101 
> drivers/pci/host/pcie-designware.h |   42 ---
> 2 files changed, 103 insertions(+), 40 deletions(-)
>
>diff --git a/drivers/pci/host/pcie-designware.c 
>b/drivers/pci/host/pcie-designware.c
>index c4e3732..9ea8e79 100644
>--- a/drivers/pci/host/pcie-designware.c
>+++ b/drivers/pci/host/pcie-designware.c
>@@ -277,11 +277,15 @@ static int assign_irq(int no_irqs, struct msi_desc 
>*desc, int *pos)
>   }
>   set_bit(pos0 + i, pp->msi_irq_in_use);
>   /*Enable corresponding interrupt in MSI interrupt controller */
>-  res = ((pos0 + i) / 32) * 12;
>-  bit = (pos0 + i) % 32;
>-  dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, );
>-  val |= 1 << bit;
>-  dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, val);
>+  if (!(pp->version & DW_VERSION_OLD)) {
>+  res = ((pos0 + i) / 32) * 12;
>+  bit = (pos0 + i) % 32;
>+  dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res,
>+   4, );
>+  val |= 1 << bit;
>+  dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res,
>+   4, val);
>+  }
>   }
>
>   *pos = pos0;
>@@ -349,7 +353,10 @@ static int dw_msi_setup_irq(struct msi_chip *chip, struct 
>pci_dev
>*pdev,
>*/
>   desc->msi_attrib.multiple = msgvec;
>
>-  msg.address_lo = virt_to_phys((void *)pp->msi_data);
>+  if (pp->ops->get_msi_data)
>+  msg.address_lo = pp->ops->get_msi_data(pp);
>+  else
>+  msg.address_lo = virt_to_phys((void *)pp->msi_data);
>   msg.address_hi = 0x0;
>   msg.data = pos;
>   write_msi_msg(irq, );
>@@ -389,13 +396,11 @@ static const struct irq_domain_ops msi_domain_ops = {
>   .map = dw_pcie_msi_map,
> };
>
>-int __init dw_pcie_host_init(struct pcie_port *pp)
>+int __init dw_pcie_parse_resource(struct pcie_port *pp)
> {
>   struct device_node *np = pp->dev->of_node;
>-  struct of_pci_range range;
>   struct of_pci_range_parser parser;
>-  u32 val;
>-  int i;
>+  struct of_pci_range range;
>
>   if (of_pci_range_parser_init(, np)) {
>   dev_err(pp->dev, "missing ranges property\n"); @@ -440,23 
> +445,17 @@ int
>__init dw_pcie_host_init(struct pcie_port *pp)
>   return -ENOMEM;
>   }
>   }
>-
>-  pp->cfg0_base = pp->cfg.start;
>-  pp->cfg1_base = pp->cfg.start + pp->config.cfg0_size;
>   pp->mem_base = pp->mem.s

RE: [PATCH v1 0/5] Add Keystone PCIe controller driver

>-Original Message-
>From: Jingoo Han [mailto:jg1@samsung.com]
>Sent: Thursday, May 15, 2014 8:49 PM
>To: Karicheri, Muralidharan
>Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-
>ker...@lists.infradead.org; Shilimkar, Santosh; 'Russell King'; 'Grant 
>Likely'; 'Rob Herring';
>'Mohit Kumar'; 'Bjorn Helgaas'; 'Jingoo Han'; 'Pratyush Anand'; 'Richard Zhu'; 
>ABRAHAM,
>KISHON VIJAY; 'Marek Vasut'
>Subject: Re: [PATCH v1 0/5] Add Keystone PCIe controller driver
>
>On Friday, May 16, 2014 1:01 AM, Murali Karicheri wrote:
>>
>> This patch adds a PCIe controller driver for Keystone SoCs. This is
>> based on the origin RFC patch that I had sent earlier. I have
>> incorporated following comments:-
>>
>>  - Add a interrupt controller node for Legacy irq chip and use
>>interrupt map/map-mask property to map legacy IRQs A/B/C/D
>>  - Add a Phy driver to replace the original serdes driver
>>  - Move common applicaiton register handling code to a separate
>>file to allow re-use across other platforms that use older
>>DW PCIe h/w
>>  - PCI quirk for maximum read request size. Check and override only
>>if the maximum is higher than what controller can handle.
>>  - Converted to a module platform driver.
>>
>> CC: Santosh Shilimkar 
>> CC: Russell King 
>> CC: Grant Likely 
>> CC: Rob Herring 
>> CC: Mohit Kumar 
>> CC: Jingoo Han 
>> CC: Bjorn Helgaas 
>>
>
>Your patches modify 'pcie-designware.c', and affects other PCIe drivers using 
>designware
>PCIe Core IP. Please add the following people to CC list. They are also 
>related to the
>designware PCIe.
>
>  Pratyush Anand 
>  Richard Zhu 
>  Kishon Vijay Abraham I 
>  Marek Vasut 
>
Will forward the patches to the above list as well.

Thanks

Murali
>Best regards,
>Jingoo Han
>
>>
>> Murali Karicheri (5):
>>   ARM: keystone: add pcie related options
>>   pci: designware: enhancements to support keystone pcie
>>   phy: pci serdes phy driver for keystone
>>   pci: dw: add common functions to support old hw based pci driver
>>   pci: keystone: add pcie driver based on designware core driver
>>
>>  .../devicetree/bindings/pci/pcie-keystone.txt  |   68 
>>  arch/arm/mach-keystone/Kconfig |2 +
>>  drivers/pci/host/Kconfig   |   12 +
>>  drivers/pci/host/Makefile  |2 +
>>  drivers/pci/host/pci-dw-old-msi.c  |  150 
>>  drivers/pci/host/pci-dw-old.c  |  371 ++
>>  drivers/pci/host/pci-dw-old.h  |   30 ++
>>  drivers/pci/host/pci-keystone.c|  400 
>> 
>>  drivers/pci/host/pcie-designware.c |  101 +++--
>>  drivers/pci/host/pcie-designware.h |   42 +-
>>  drivers/pci/quirks.c   |   13 +
>>  drivers/phy/Kconfig|6 +
>>  drivers/phy/Makefile   |1 +
>>  drivers/phy/phy-keystone.c |  230 +++
>>  14 files changed, 1388 insertions(+), 40 deletions(-)  create mode
>> 100644 Documentation/devicetree/bindings/pci/pcie-keystone.txt
>>  create mode 100644 drivers/pci/host/pci-dw-old-msi.c  create mode
>> 100644 drivers/pci/host/pci-dw-old.c  create mode 100644
>> drivers/pci/host/pci-dw-old.h  create mode 100644
>> drivers/pci/host/pci-keystone.c  create mode 100644
>> drivers/phy/phy-keystone.c
>>
>> --
>> 1.7.9.5

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

RE: [PATCH v1 5/5] pci: keystone: add pcie driver based on designware core driver

>-Original Message-
>From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
>Sent: Thursday, May 15, 2014 4:52 PM
>To: Karicheri, Muralidharan
>Cc: Arnd Bergmann; linux-arm-ker...@lists.infradead.org; Strashko, Grygorii; 
>linux-
>p...@vger.kernel.org; Jingoo Han; linux-kernel@vger.kernel.org; Shilimkar, 
>Santosh; Mohit
>Kumar; Bjorn Helgaas
>Subject: Re: [PATCH v1 5/5] pci: keystone: add pcie driver based on designware 
>core
>driver
>
>On Thu, May 15, 2014 at 04:04:47PM -0400, Murali Karicheri wrote:
>
>> Jason What you mean by "The PCI core handles setting the maximum read
>> request size already" I see there is function pcie_write_mrrs() in the
>> drivers/pci/probe.c that reads the mps using pcie_get_mps() and then
>> set mrrs to mps. But this function is called only from
>> pcie_bus_configure_set() that is called by
>> pcie_bus_configure_settings()
>
>Right, that is the common code that correctly sets the MRRS that you should be 
>using
>instead of quirks.
>
>> None of them gets called on ARM platform.
>
>Hmm, a cursory glance tells me the same as well.
>
>That seems to be the root problem here, ARM needs to do the PCIE setup just as 
>much as
>any other arch.
>
>So, I would prefer to see you fix ARM common code to call
>pcie_bus_configure_settings() properly, that seems very simple and is 
>obviously needed for
>any PCI-E host driver on ARM.
>

But pcie_bus_configure_settings just make sure the mrrs for a device is not 
greater than
the max payload size. But the quirk that I need is to limit the size of mrr to 
256 as required
by the keystone PCI controller. So I still need to implement a quirk to enforce 
this limit.

In my reply to Arnd, I have agreed to move the quirk to keystone driver.

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

RE: [PATCH v1 1/5] ARM: keystone: add pcie related options

>-Original Message-
>From: Jingoo Han [mailto:jg1@samsung.com]
>Sent: Thursday, May 15, 2014 8:28 PM
>To: Karicheri, Muralidharan
>Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-
>ker...@lists.infradead.org; Shilimkar, Santosh; 'Russell King'; 'Jingoo Han'
>Subject: Re: [PATCH v1 1/5] ARM: keystone: add pcie related options
>
>On Friday, May 16, 2014 1:01 AM, Murali Karicheri wrote:
>>
>> Add pcie related options by default for keystone architecture
>>
>> CC: Santosh Shilimkar 
>> CC: Russell King 
>>
>> Signed-off-by: Murali Karicheri 
>> ---
>>  arch/arm/mach-keystone/Kconfig |2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/mach-keystone/Kconfig
>> b/arch/arm/mach-keystone/Kconfig index f50bc93..f87844d 100644
>> --- a/arch/arm/mach-keystone/Kconfig
>> +++ b/arch/arm/mach-keystone/Kconfig
>> @@ -8,6 +8,8 @@ config ARCH_KEYSTONE
>>  select COMMON_CLK_KEYSTONE
>>  select ARCH_SUPPORTS_BIG_ENDIAN
>>  select ZONE_DMA if ARM_LPAE
>> +select MIGHT_HAVE_PCI
>> +select ARCH_SUPPORTS_MSI
>
>Please, don't select ARCH_SUPPORTS_MSI, because this kconfig option was already
>removed in v3.12 by the commit ebd97be635
>('PCI: remove ARCH_SUPPORTS_MSI kconfig option'). So. there is NO need to 
>select
>'ARCH_SUPPORTS_MSI'.
>

Will do. Thanks.

>Best regards,
>Jingoo Han
>
>>  help
>>Support for boards based on the Texas Instruments Keystone family of
>>SoCs.
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci"
>> in the body of a message to majord...@vger.kernel.org More majordomo
>> info at  http://vger.kernel.org/majordomo-info.html

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

RE: [PATCH v1 1/5] ARM: keystone: add pcie related options

-Original Message-
From: Jingoo Han [mailto:jg1@samsung.com]
Sent: Thursday, May 15, 2014 8:28 PM
To: Karicheri, Muralidharan
Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; Shilimkar, Santosh; 'Russell King'; 'Jingoo Han'
Subject: Re: [PATCH v1 1/5] ARM: keystone: add pcie related options

On Friday, May 16, 2014 1:01 AM, Murali Karicheri wrote:

 Add pcie related options by default for keystone architecture

 CC: Santosh Shilimkar santosh.shilim...@ti.com
 CC: Russell King li...@arm.linux.org.uk

 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 ---
  arch/arm/mach-keystone/Kconfig |2 ++
  1 file changed, 2 insertions(+)

 diff --git a/arch/arm/mach-keystone/Kconfig
 b/arch/arm/mach-keystone/Kconfig index f50bc93..f87844d 100644
 --- a/arch/arm/mach-keystone/Kconfig
 +++ b/arch/arm/mach-keystone/Kconfig
 @@ -8,6 +8,8 @@ config ARCH_KEYSTONE
  select COMMON_CLK_KEYSTONE
  select ARCH_SUPPORTS_BIG_ENDIAN
  select ZONE_DMA if ARM_LPAE
 +select MIGHT_HAVE_PCI
 +select ARCH_SUPPORTS_MSI

Please, don't select ARCH_SUPPORTS_MSI, because this kconfig option was already
removed in v3.12 by the commit ebd97be635
('PCI: remove ARCH_SUPPORTS_MSI kconfig option'). So. there is NO need to 
select
'ARCH_SUPPORTS_MSI'.


Will do. Thanks.

Best regards,
Jingoo Han

  help
Support for boards based on the Texas Instruments Keystone family of
SoCs.
 --
 1.7.9.5

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

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

RE: [PATCH v1 5/5] pci: keystone: add pcie driver based on designware core driver

-Original Message-
From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
Sent: Thursday, May 15, 2014 4:52 PM
To: Karicheri, Muralidharan
Cc: Arnd Bergmann; linux-arm-ker...@lists.infradead.org; Strashko, Grygorii; 
linux-
p...@vger.kernel.org; Jingoo Han; linux-kernel@vger.kernel.org; Shilimkar, 
Santosh; Mohit
Kumar; Bjorn Helgaas
Subject: Re: [PATCH v1 5/5] pci: keystone: add pcie driver based on designware 
core
driver

On Thu, May 15, 2014 at 04:04:47PM -0400, Murali Karicheri wrote:

 Jason What you mean by The PCI core handles setting the maximum read
 request size already I see there is function pcie_write_mrrs() in the
 drivers/pci/probe.c that reads the mps using pcie_get_mps() and then
 set mrrs to mps. But this function is called only from
 pcie_bus_configure_set() that is called by
 pcie_bus_configure_settings()

Right, that is the common code that correctly sets the MRRS that you should be 
using
instead of quirks.

 None of them gets called on ARM platform.

Hmm, a cursory glance tells me the same as well.

That seems to be the root problem here, ARM needs to do the PCIE setup just as 
much as
any other arch.

So, I would prefer to see you fix ARM common code to call
pcie_bus_configure_settings() properly, that seems very simple and is 
obviously needed for
any PCI-E host driver on ARM.

But pcie_bus_configure_settings just make sure the mrrs for a device is not 
greater than
the max payload size. But the quirk that I need is to limit the size of mrr to 
256 as required
by the keystone PCI controller. So I still need to implement a quirk to enforce 
this limit.

In my reply to Arnd, I have agreed to move the quirk to keystone driver.

Murali
Thoughts? Arnd? Bjorn?

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

RE: [PATCH v1 0/5] Add Keystone PCIe controller driver

-Original Message-
From: Jingoo Han [mailto:jg1@samsung.com]
Sent: Thursday, May 15, 2014 8:49 PM
To: Karicheri, Muralidharan
Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; Shilimkar, Santosh; 'Russell King'; 'Grant 
Likely'; 'Rob Herring';
'Mohit Kumar'; 'Bjorn Helgaas'; 'Jingoo Han'; 'Pratyush Anand'; 'Richard Zhu'; 
ABRAHAM,
KISHON VIJAY; 'Marek Vasut'
Subject: Re: [PATCH v1 0/5] Add Keystone PCIe controller driver

On Friday, May 16, 2014 1:01 AM, Murali Karicheri wrote:

 This patch adds a PCIe controller driver for Keystone SoCs. This is
 based on the origin RFC patch that I had sent earlier. I have
 incorporated following comments:-

  - Add a interrupt controller node for Legacy irq chip and use
interrupt map/map-mask property to map legacy IRQs A/B/C/D
  - Add a Phy driver to replace the original serdes driver
  - Move common applicaiton register handling code to a separate
file to allow re-use across other platforms that use older
DW PCIe h/w
  - PCI quirk for maximum read request size. Check and override only
if the maximum is higher than what controller can handle.
  - Converted to a module platform driver.

 CC: Santosh Shilimkar santosh.shilim...@ti.com
 CC: Russell King li...@arm.linux.org.uk
 CC: Grant Likely grant.lik...@linaro.org
 CC: Rob Herring robh...@kernel.org
 CC: Mohit Kumar mohit.ku...@st.com
 CC: Jingoo Han jg1@samsung.com
 CC: Bjorn Helgaas bhelg...@google.com


Your patches modify 'pcie-designware.c', and affects other PCIe drivers using 
designware
PCIe Core IP. Please add the following people to CC list. They are also 
related to the
designware PCIe.

  Pratyush Anand pratyush.an...@st.com
  Richard Zhu r65...@freescale.com
  Kishon Vijay Abraham I kis...@ti.com
  Marek Vasut ma...@denx.de

Will forward the patches to the above list as well.

Thanks

Murali
Best regards,
Jingoo Han


 Murali Karicheri (5):
   ARM: keystone: add pcie related options
   pci: designware: enhancements to support keystone pcie
   phy: pci serdes phy driver for keystone
   pci: dw: add common functions to support old hw based pci driver
   pci: keystone: add pcie driver based on designware core driver

  .../devicetree/bindings/pci/pcie-keystone.txt  |   68 
  arch/arm/mach-keystone/Kconfig |2 +
  drivers/pci/host/Kconfig   |   12 +
  drivers/pci/host/Makefile  |2 +
  drivers/pci/host/pci-dw-old-msi.c  |  150 
  drivers/pci/host/pci-dw-old.c  |  371 ++
  drivers/pci/host/pci-dw-old.h  |   30 ++
  drivers/pci/host/pci-keystone.c|  400 
 
  drivers/pci/host/pcie-designware.c |  101 +++--
  drivers/pci/host/pcie-designware.h |   42 +-
  drivers/pci/quirks.c   |   13 +
  drivers/phy/Kconfig|6 +
  drivers/phy/Makefile   |1 +
  drivers/phy/phy-keystone.c |  230 +++
  14 files changed, 1388 insertions(+), 40 deletions(-)  create mode
 100644 Documentation/devicetree/bindings/pci/pcie-keystone.txt
  create mode 100644 drivers/pci/host/pci-dw-old-msi.c  create mode
 100644 drivers/pci/host/pci-dw-old.c  create mode 100644
 drivers/pci/host/pci-dw-old.h  create mode 100644
 drivers/pci/host/pci-keystone.c  create mode 100644
 drivers/phy/phy-keystone.c

 --
 1.7.9.5

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

RE: [PATCH v1 2/5] pci: designware: enhancements to support keystone pcie

Adding more to list.

-Original Message-
From: Karicheri, Muralidharan
Sent: Thursday, May 15, 2014 12:01 PM
To: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-
ker...@lists.infradead.org
Cc: Karicheri, Muralidharan; Mohit Kumar; Jingoo Han; Bjorn Helgaas; 
Shilimkar, Santosh
Subject: [PATCH v1 2/5] pci: designware: enhancements to support keystone pcie

keystone pcie hardware is based on designware hw version 3.65.
There is no support for ATU port and has registers in application space to 
configure
inbound/outbound access. Also doesn't support PCI PVM option. The MSI IRQ 
registers
available in application space is used to mask/unmask/enable the MSI IRQs.

DW core driver is a set of common functions that are abstracted to support DW 
pci drivers.
To allow re-use of these functions for keystone pci driver, core driver is to 
be enhanced.

Following are done to allow re-use of the functions on keystone pci driver.

 1. Some of the variables in pcie_port struct is folded inside
a union that now contains both new DW hw related variables as well
as old hardware related variables such as application reg base.
 2. Added a dw_pcie_common_host_init() function that holds common
host initialization code for old and new hw.
 3. dw_pcie_parse_resource() is used for parsing resource related
information from DT bindings.
 4. dw_pcie_host_init() is called by new DW hw drivers as before.
Added dw_old_pcie_host_init() is it's counter part on old dw hw.
Both these functions now call dw_pcie_common_host_init().
 5. Some of the static functions are made global to allow use from
dw old pci drivers such as pci-keystone.

CC: Mohit Kumar mohit.ku...@st.com
CC: Jingoo Han jg1@samsung.com
CC: Bjorn Helgaas bhelg...@google.com
CC: Santosh Shilimkar santosh.shilim...@ti.com

Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
 drivers/pci/host/pcie-designware.c |  101 
 drivers/pci/host/pcie-designware.h |   42 ---
 2 files changed, 103 insertions(+), 40 deletions(-)

diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index c4e3732..9ea8e79 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -277,11 +277,15 @@ static int assign_irq(int no_irqs, struct msi_desc 
*desc, int *pos)
   }
   set_bit(pos0 + i, pp-msi_irq_in_use);
   /*Enable corresponding interrupt in MSI interrupt controller */
-  res = ((pos0 + i) / 32) * 12;
-  bit = (pos0 + i) % 32;
-  dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, val);
-  val |= 1  bit;
-  dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, val);
+  if (!(pp-version  DW_VERSION_OLD)) {
+  res = ((pos0 + i) / 32) * 12;
+  bit = (pos0 + i) % 32;
+  dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res,
+   4, val);
+  val |= 1  bit;
+  dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res,
+   4, val);
+  }
   }

   *pos = pos0;
@@ -349,7 +353,10 @@ static int dw_msi_setup_irq(struct msi_chip *chip, struct 
pci_dev
*pdev,
*/
   desc-msi_attrib.multiple = msgvec;

-  msg.address_lo = virt_to_phys((void *)pp-msi_data);
+  if (pp-ops-get_msi_data)
+  msg.address_lo = pp-ops-get_msi_data(pp);
+  else
+  msg.address_lo = virt_to_phys((void *)pp-msi_data);
   msg.address_hi = 0x0;
   msg.data = pos;
   write_msi_msg(irq, msg);
@@ -389,13 +396,11 @@ static const struct irq_domain_ops msi_domain_ops = {
   .map = dw_pcie_msi_map,
 };

-int __init dw_pcie_host_init(struct pcie_port *pp)
+int __init dw_pcie_parse_resource(struct pcie_port *pp)
 {
   struct device_node *np = pp-dev-of_node;
-  struct of_pci_range range;
   struct of_pci_range_parser parser;
-  u32 val;
-  int i;
+  struct of_pci_range range;

   if (of_pci_range_parser_init(parser, np)) {
   dev_err(pp-dev, missing ranges property\n); @@ -440,23 
 +445,17 @@ int
__init dw_pcie_host_init(struct pcie_port *pp)
   return -ENOMEM;
   }
   }
-
-  pp-cfg0_base = pp-cfg.start;
-  pp-cfg1_base = pp-cfg.start + pp-config.cfg0_size;
   pp-mem_base = pp-mem.start;

-  pp-va_cfg0_base = devm_ioremap(pp-dev, pp-cfg0_base,
-  pp-config.cfg0_size);
-  if (!pp-va_cfg0_base) {
-  dev_err(pp-dev, error with ioremap in function\n);
-  return -ENOMEM;
-  }
-  pp-va_cfg1_base = devm_ioremap(pp-dev, pp-cfg1_base,
-  pp-config.cfg1_size);
-  if (!pp-va_cfg1_base) {
-  dev_err(pp-dev, error

RE: [PATCH v1 5/5] pci: keystone: add pcie driver based on designware core driver

Adding more people to the list for review.

-Original Message-
From: Karicheri, Muralidharan
Sent: Thursday, May 15, 2014 12:02 PM
To: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-
ker...@lists.infradead.org
Cc: Karicheri, Muralidharan; Shilimkar, Santosh; Mohit Kumar; Jingoo Han; 
Bjorn Helgaas;
Strashko, Grygorii
Subject: [PATCH v1 5/5] pci: keystone: add pcie driver based on designware 
core driver

keystone pcie hardware is based on designware version 3.65.
This driver make use of the functions from pci-dw-old.c and pci-dw-old-msi.c 
to implement
the driver.

Driver mainly handle the platform specific part of the PCI driver and depends 
on DW Old
driver to configure application specific registers. Also routes the irq events 
and ack the
interrupt after the same is acked by the end point device driver. This 
requires irqchip
implementation for legacy and MSI irq handling. This patch adds a quirks to 
override the
max read request size as PCI controller has a limit of 256 bytes.

CC: Santosh Shilimkar santosh.shilim...@ti.com
CC: Mohit Kumar mohit.ku...@st.com
CC: Jingoo Han jg1@samsung.com
CC: Bjorn Helgaas bhelg...@google.com

Signed-off-by: Murali Karicheri m-kariche...@ti.com
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
 .../devicetree/bindings/pci/pcie-keystone.txt  |   68 
 drivers/pci/host/Kconfig   |8 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pci-keystone.c|  400 
 drivers/pci/quirks.c   |   13 +
 5 files changed, 490 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/pcie-keystone.txt
 create mode 100644 drivers/pci/host/pci-keystone.c

diff --git a/Documentation/devicetree/bindings/pci/pcie-keystone.txt
b/Documentation/devicetree/bindings/pci/pcie-keystone.txt
new file mode 100644
index 000..17cf261
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pcie-keystone.txt
@@ -0,0 +1,68 @@
+Keystone PCIE Root complex device tree bindings
+---
+
+Sample bindings shown below:-
+
+ - Remove ti,enable-linktrain if boot loader already does Link training and 
do EP
+   configuration.
+ - Remove ti,init-phy if boot loader already initialize the phy and sets up 
pcie
+   link
+
+  pcie0_phy: pciephy@232 {
+  #address-cells = 1;
+  #size-cells = 1;
+  #phy-cells = 0;
+  compatible = ti,keystone-phy;
+  reg = 0x0232 0x4000;
+  reg-names = reg_serdes;
+  };
+
+  pcie@2180 {
+  compatible = ti,keystone-pcie;
+  device_type = pci;
+  clocks = clkpcie;
+  clock-names = pcie;
+  #address-cells = 3;
+  #size-cells = 2;
+  reg =  0x2180 0x1000, 0x0262014c 4;
+  reg-names = reg_rc_app, reg_devcfg;
+  interrupts = GIC_SPI 30 IRQ_TYPE_EDGE_RISING,
+  GIC_SPI 31 IRQ_TYPE_EDGE_RISING,
+  GIC_SPI 32 IRQ_TYPE_EDGE_RISING,
+  GIC_SPI 33 IRQ_TYPE_EDGE_RISING,
+  GIC_SPI 34 IRQ_TYPE_EDGE_RISING,
+  GIC_SPI 35 IRQ_TYPE_EDGE_RISING,
+  GIC_SPI 36 IRQ_TYPE_EDGE_RISING,
+  GIC_SPI 37 IRQ_TYPE_EDGE_RISING,
+  GIC_SPI 38 IRQ_TYPE_EDGE_RISING; /* 
Error IRQ */
+
+  ranges = 0x0800 0 0x21801000 0x21801000 0 
0x0002000/*
Configuration space */
+0x8100 0 0  0x2400 0 0x4000   
/* downstream
I/O */
+0x8200 0 0x5000 0x5000 0 
0x1000; /*
+non-prefetchable memory */
+
+  num-lanes = 2;
+  ti,enable-linktrain;
+  ti,init-phy;
+
+  /* PCIE phy */
+  phys = pcie0_phy;
+  phy-names = pcie-phy;
+
+  #interrupt-cells = 1;
+  interrupt-map-mask = 0 0 0 0;
+  interrupt-map = 0 0 0 1 pcie_intc 1, // INT A
+  0 0 0 2 pcie_intc 2, // INT B
+  0 0 0 3 pcie_intc 3, // INT C
+  0 0 0 4 pcie_intc 4; // INT D
+
+  pcie_intc: legacy-interrupt-controller {
+  interrupt-controller;
+  #interrupt-cells = 1;
+  interrupt-parent = gic

RE: [PATCH v1 4/5] pci: dw: add common functions to support old hw based pci driver

Adding more people to the list for review.
-Original Message-
From: Karicheri, Muralidharan
Sent: Thursday, May 15, 2014 12:02 PM
To: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-
ker...@lists.infradead.org
Cc: Karicheri, Muralidharan; Shilimkar, Santosh; Mohit Kumar; Jingoo Han; 
Bjorn Helgaas
Subject: [PATCH v1 4/5] pci: dw: add common functions to support old hw based 
pci driver

The older version of DW hw has application space registers for MSI controller 
and
inbound/outbound access configuration. Also the legacy interrupt has registers 
in the
application space. Drivers such as keystone pci uses these common functions to 
implement
the driver.
These are re-factored from the original driver to separate files to allow 
re-use for the next
driver that is based on old dw pci hw such as that found on keystone.

CC: Santosh Shilimkar santosh.shilim...@ti.com
CC: Mohit Kumar mohit.ku...@st.com
CC: Jingoo Han jg1@samsung.com
CC: Bjorn Helgaas bhelg...@google.com

Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
 drivers/pci/host/Kconfig  |6 +-
 drivers/pci/host/Makefile |1 +
 drivers/pci/host/pci-dw-old-msi.c |  150 +++
 drivers/pci/host/pci-dw-old.c |  371
+
 drivers/pci/host/pci-dw-old.h |   30 +++
 5 files changed, 557 insertions(+), 1 deletion(-)  create mode 100644 
 drivers/pci/host/pci-
dw-old-msi.c  create mode 100644 drivers/pci/host/pci-dw-old.c  create mode 
100644
drivers/pci/host/pci-dw-old.h

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index 
a6f67ec..c4f4732
100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -9,6 +9,11 @@ config PCI_MVEBU
 config PCIE_DW
   bool

+config PCI_DW_OLD
+  bool Designware Old PCIe h/w
+  help
+ Say Y here if the DW h/w is old version (3.65)
+
 config PCI_EXYNOS
   bool Samsung Exynos PCIe controller
   depends on SOC_EXYNOS5440
@@ -32,5 +37,4 @@ config PCI_RCAR_GEN2
 Say Y here if you want internal PCI support on R-Car Gen2 SoC.
 There are 3 internal PCI controllers available with a single
 built-in EHCI/OHCI host controller present on each one.
-
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile index 
13fb333..be5d939
100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
 obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
 obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
 obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
+obj-$(CONFIG_PCI_DW_OLD) += pci-dw-old-msi.o pci-dw-old.o
diff --git a/drivers/pci/host/pci-dw-old-msi.c 
b/drivers/pci/host/pci-dw-old-msi.c
new file mode 100644
index 000..450bb2f
--- /dev/null
+++ b/drivers/pci/host/pci-dw-old-msi.c
@@ -0,0 +1,150 @@
+/*
+ * Designware(dw) old MSI controller (v3.65 or similar)
+ *
+ * Copyright (C) 2013-2014 Texas Instruments., Ltd.
+ *http://www.ti.com
+ *
+ * Author: Murali Karicheri m-kariche...@ti.com
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/of_irq.h
+#include linux/kernel.h
+#include linux/msi.h
+#include linux/pci.h
+
+#include pcie-designware.h
+#include pci-dw-old.h
+
+#define MSI_IRQ   0x054
+#define MSI0_IRQ_STATUS   0x104
+#define MSI0_IRQ_ENABLE_SET   0x108
+#define MSI0_IRQ_ENABLE_CLR   0x10c
+#define IRQ_STATUS0x184
+#define IRQ_EOI 0x050
+#define MSI_IRQ_OFFSET4
+
+static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys) {
+  return sys-private_data;
+}
+
+static inline void update_reg_offset_bit_pos(u32 offset, u32 *reg_offset,
+  u32 *bit_pos)
+{
+  *reg_offset = offset % 8;
+  *bit_pos = offset  3;
+}
+
+inline u32 dw_old_get_msi_data(struct pcie_port *pp) {
+  return pp-app_base + MSI_IRQ;
+}
+
+void dw_old_handle_msi_irq(struct pcie_port *pp, int offset) {
+  u32 pending, vector;
+  int src, virq;
+
+  pending = readl(pp-va_app_base + MSI0_IRQ_STATUS + (offset  4));
+  /*
+   * MSI0, Status bit 0-3 shows vectors 0, 8, 16, 24, MSI1 status bit
+   * shows 1, 9, 17, 25 and so forth
+   */
+  for (src = 0; src  4; src++) {
+  if (BIT(src)  pending) {
+  vector = offset + (src  3);
+  virq = irq_linear_revmap(pp-irq_domain, vector);
+  dev_dbg(pp-dev,
+  irq: bit %d, vector %d, virq %d\n,
+   src, vector, virq);
+  generic_handle_irq(virq);
+  }
+  }
+}
+
+static void dw_old_msi_irq_ack(struct irq_data *d) {
+  u32 offset

RE: [PATCH v2] serial: uart: add hw flow control support configuration

2014-05-09 Thread Karicheri, Muralidharan

>-Original Message-
>From: Karicheri, Muralidharan
>Sent: Thursday, May 01, 2014 3:05 PM
>To: devicet...@vger.kernel.org; linux-...@vger.kernel.org; 
>linux-kernel@vger.kernel.org;
>linux-ser...@vger.kernel.org
>Cc: Karicheri, Muralidharan; Rob Herring; Pawel Moll; Mark Rutland; Ian 
>Campbell; Kumar
>Gala; Randy Dunlap; Greg Kroah-Hartman; Jiri Slaby; Shilimkar, Santosh
>Subject: [PATCH v2] serial: uart: add hw flow control support configuration
>
>8250 uart driver currently supports only software assisted hw flow control. 
>The software
>assisted hw flow control maintains a hw_stopped flag in the tty structure to 
>stop and start
>transmission and use modem status interrupt for the event to drive the 
>handshake signals.
>This is not needed if hw has flow control capabilities. This patch adds a DT 
>attribute for
>enabling hw flow control for a uart port. Also skip stop and start if this 
>flag is present in flag
>field of the port structure.
>
>Signed-off-by: Murali Karicheri 
>
>CC: Rob Herring 
>CC: Pawel Moll 
>CC: Mark Rutland 
>CC: Ian Campbell 
>CC: Kumar Gala 
>CC: Randy Dunlap 
>CC: Greg Kroah-Hartman 
>CC: Jiri Slaby 
>CC: Santosh Shilimkar 
>---
> .../devicetree/bindings/serial/of-serial.txt   |1 +
> drivers/tty/serial/8250/8250_core.c|6 --
> drivers/tty/serial/of_serial.c |4 
> drivers/tty/serial/serial_core.c   |   12 +---
> 4 files changed, 18 insertions(+), 5 deletions(-)
>
>diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt
>b/Documentation/devicetree/bindings/serial/of-serial.txt
>index 1928a3e..7705477 100644
>--- a/Documentation/devicetree/bindings/serial/of-serial.txt
>+++ b/Documentation/devicetree/bindings/serial/of-serial.txt
>@@ -37,6 +37,7 @@ Optional properties:
> - auto-flow-control: one way to enable automatic flow control support. The
>   driver is allowed to detect support for the capability even without this
>   property.
>+- has-hw-flow-control: the hardware has flow control capability.
>
> Example:
>
>diff --git a/drivers/tty/serial/8250/8250_core.c 
>b/drivers/tty/serial/8250/8250_core.c
>index 0e1bf88..b69aff2 100644
>--- a/drivers/tty/serial/8250/8250_core.c
>+++ b/drivers/tty/serial/8250/8250_core.c
>@@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port, struct
>ktermios *termios,
>* the trigger, or the MCR RTS bit is cleared.  In the case where
>* the remote UART is not using CTS auto flow control, we must
>* have sufficient FIFO entries for the latency of the remote
>-   * UART to respond.  IOW, at least 32 bytes of FIFO.
>+   * UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
>+   * AFE if hw flow control is supported
>*/
>-  if (up->capabilities & UART_CAP_AFE && port->fifosize >= 32) {
>+  if ((up->capabilities & UART_CAP_AFE && (port->fifosize >= 32)) ||
>+  (port->flags & UPF_HARD_FLOW)) {
>   up->mcr &= ~UART_MCR_AFE;
>   if (termios->c_cflag & CRTSCTS)
>   up->mcr |= UART_MCR_AFE;
>diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c 
>index
>9924660..77ec6a1 100644
>--- a/drivers/tty/serial/of_serial.c
>+++ b/drivers/tty/serial/of_serial.c
>@@ -182,6 +182,10 @@ static int of_platform_serial_probe(struct 
>platform_device *ofdev)
> "auto-flow-control"))
>   port8250.capabilities |= UART_CAP_AFE;
>
>+  if (of_property_read_bool(ofdev->dev.of_node,
>+"has-hw-flow-control"))
>+  port8250.port.flags |= UPF_HARD_FLOW;
>+
>   ret = serial8250_register_8250_port();
>   break;
>   }
>diff --git a/drivers/tty/serial/serial_core.c 
>b/drivers/tty/serial/serial_core.c
>index b68550d..851707a 100644
>--- a/drivers/tty/serial/serial_core.c
>+++ b/drivers/tty/serial/serial_core.c
>@@ -174,8 +174,12 @@ static int uart_port_startup(struct tty_struct *tty, 
>struct
>uart_state *state,
>   if (tty->termios.c_cflag & CBAUD)
>   uart_set_mctrl(uport, TIOCM_RTS | TIOCM_DTR);
>   }
>-
>-  if (tty_port_cts_enabled(port)) {
>+  /*
>+   * if hw support flow control without software intervention,
>+   * then skip the below check
>+   */
>+  if (tty_port_cts_enabled(port) &&
>+  !(uport-&g

RE: [PATCH v2] serial: uart: add hw flow control support configuration

2014-05-09 Thread Karicheri, Muralidharan

-Original Message-
From: Karicheri, Muralidharan
Sent: Thursday, May 01, 2014 3:05 PM
To: devicet...@vger.kernel.org; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org;
linux-ser...@vger.kernel.org
Cc: Karicheri, Muralidharan; Rob Herring; Pawel Moll; Mark Rutland; Ian 
Campbell; Kumar
Gala; Randy Dunlap; Greg Kroah-Hartman; Jiri Slaby; Shilimkar, Santosh
Subject: [PATCH v2] serial: uart: add hw flow control support configuration

8250 uart driver currently supports only software assisted hw flow control. 
The software
assisted hw flow control maintains a hw_stopped flag in the tty structure to 
stop and start
transmission and use modem status interrupt for the event to drive the 
handshake signals.
This is not needed if hw has flow control capabilities. This patch adds a DT 
attribute for
enabling hw flow control for a uart port. Also skip stop and start if this 
flag is present in flag
field of the port structure.

Signed-off-by: Murali Karicheri m-kariche...@ti.com

CC: Rob Herring robh...@kernel.org
CC: Pawel Moll pawel.m...@arm.com
CC: Mark Rutland mark.rutl...@arm.com
CC: Ian Campbell ijc+devicet...@hellion.org.uk
CC: Kumar Gala ga...@codeaurora.org
CC: Randy Dunlap rdun...@infradead.org
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
CC: Jiri Slaby jsl...@suse.cz
CC: Santosh Shilimkar santosh.shilim...@ti.com
---
 .../devicetree/bindings/serial/of-serial.txt   |1 +
 drivers/tty/serial/8250/8250_core.c|6 --
 drivers/tty/serial/of_serial.c |4 
 drivers/tty/serial/serial_core.c   |   12 +---
 4 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt
b/Documentation/devicetree/bindings/serial/of-serial.txt
index 1928a3e..7705477 100644
--- a/Documentation/devicetree/bindings/serial/of-serial.txt
+++ b/Documentation/devicetree/bindings/serial/of-serial.txt
@@ -37,6 +37,7 @@ Optional properties:
 - auto-flow-control: one way to enable automatic flow control support. The
   driver is allowed to detect support for the capability even without this
   property.
+- has-hw-flow-control: the hardware has flow control capability.

 Example:

diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 0e1bf88..b69aff2 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port, struct
ktermios *termios,
* the trigger, or the MCR RTS bit is cleared.  In the case where
* the remote UART is not using CTS auto flow control, we must
* have sufficient FIFO entries for the latency of the remote
-   * UART to respond.  IOW, at least 32 bytes of FIFO.
+   * UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
+   * AFE if hw flow control is supported
*/
-  if (up-capabilities  UART_CAP_AFE  port-fifosize = 32) {
+  if ((up-capabilities  UART_CAP_AFE  (port-fifosize = 32)) ||
+  (port-flags  UPF_HARD_FLOW)) {
   up-mcr = ~UART_MCR_AFE;
   if (termios-c_cflag  CRTSCTS)
   up-mcr |= UART_MCR_AFE;
diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c 
index
9924660..77ec6a1 100644
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -182,6 +182,10 @@ static int of_platform_serial_probe(struct 
platform_device *ofdev)
 auto-flow-control))
   port8250.capabilities |= UART_CAP_AFE;

+  if (of_property_read_bool(ofdev-dev.of_node,
+has-hw-flow-control))
+  port8250.port.flags |= UPF_HARD_FLOW;
+
   ret = serial8250_register_8250_port(port8250);
   break;
   }
diff --git a/drivers/tty/serial/serial_core.c 
b/drivers/tty/serial/serial_core.c
index b68550d..851707a 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -174,8 +174,12 @@ static int uart_port_startup(struct tty_struct *tty, 
struct
uart_state *state,
   if (tty-termios.c_cflag  CBAUD)
   uart_set_mctrl(uport, TIOCM_RTS | TIOCM_DTR);
   }
-
-  if (tty_port_cts_enabled(port)) {
+  /*
+   * if hw support flow control without software intervention,
+   * then skip the below check
+   */
+  if (tty_port_cts_enabled(port) 
+  !(uport-flags  UPF_HARD_FLOW)) {
   spin_lock_irq(uport-lock);
   if (!(uport-ops-get_mctrl(uport)  TIOCM_CTS))
   tty-hw_stopped = 1;
@@ -2772,7 +2776,9 @@ void uart_handle_cts_change(struct uart_port *uport, 
unsigned
int status)

   uport-icount.cts++;

-  if (tty_port_cts_enabled(port

RE: [PATCH] i2c: davinci: Add block read functionality for IPMI

2014-05-05 Thread Karicheri, Muralidharan

>-Original Message-
>From: Karicheri, Muralidharan
>Sent: Thursday, May 01, 2014 2:50 PM
>To: davinci-linux-open-sou...@linux.davincidsp.com; linux-...@vger.kernel.org; 
>linux-
>ker...@vger.kernel.org
>Cc: Karicheri, Muralidharan; Ding, Garrett; Nori, Sekhar; Kevin Hilman; 
>Wolfram Sang;
>Shilimkar, Santosh
>Subject: [PATCH] i2c: davinci: Add block read functionality for IPMI
>
>Intelligent Plaform Management Interface (IPMI) requires I2C driver to support 
>block read,
>where the first byte received from slave is the length of following data:-  
>Added length
>check if the read type is block read (I2C_M_RECV_LEN)  Send NACK/STOP bits 
>before last
>byte is received
>
>Signed-off-by: Garrett Ding 
>Signed-off-by: Murali Karicheri 
>Tested-by: Garrett Ding 
>CC: Sekhar Nori 
>CC: Kevin Hilman 
>CC: Wolfram Sang 
>CC: Santosh Shilimkar 
>---
> Tested on a customer board based on K2HK SoC
> drivers/i2c/busses/i2c-davinci.c |   42 +-
>
> 1 file changed, 37 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/i2c/busses/i2c-davinci.c 
>b/drivers/i2c/busses/i2c-davinci.c
>index 389bc68..cd97920 100644
>--- a/drivers/i2c/busses/i2c-davinci.c
>+++ b/drivers/i2c/busses/i2c-davinci.c
>@@ -97,6 +97,10 @@
> #define DAVINCI_I2C_IMR_NACK  BIT(1)
> #define DAVINCI_I2C_IMR_ALBIT(0)
>
>+/* capabilities */
>+#define I2C_CAPABILITIES  (I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | \
>+   I2C_FUNC_SMBUS_READ_BLOCK_DATA)
>+
> struct davinci_i2c_dev {
>   struct device   *dev;
>   void __iomem*base;
>@@ -318,7 +322,13 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct 
>i2c_msg
>*msg, int stop)
>   davinci_i2c_write_reg(dev, DAVINCI_I2C_SAR_REG, msg->addr);
>
>   dev->buf = msg->buf;
>-  dev->buf_len = msg->len;
>+
>+   /* if first received byte is length, set buf_len = 0x as flag */
>+  if (msg->flags & I2C_M_RECV_LEN)
>+  dev->buf_len = 0x;
>+  else
>+  dev->buf_len = msg->len;
>+
>   dev->stop = stop;
>
>   davinci_i2c_write_reg(dev, DAVINCI_I2C_CNT_REG, dev->buf_len); @@ -456,7
>+466,7 @@ i2c_davinci_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], 
>int num)
>
> static u32 i2c_davinci_func(struct i2c_adapter *adap)  {
>-  return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
>+  return I2C_CAPABILITIES;
> }
>
> static void terminate_read(struct davinci_i2c_dev *dev) @@ -528,10 +538,32 @@ 
> static
>irqreturn_t i2c_davinci_isr(int this_irq, void *dev_id)
>
>   case DAVINCI_I2C_IVR_RDR:
>   if (dev->buf_len) {
>-  *dev->buf++ =
>-  davinci_i2c_read_reg(dev,
>-   DAVINCI_I2C_DRR_REG);
>+  *dev->buf++ = davinci_i2c_read_reg(dev,
>+  DAVINCI_I2C_DRR_REG);
>+  /*
>+   * check if the first received byte is message
>+   * length, i.e, I2C_M_RECV_LEN
>+   */
>+  if (dev->buf_len == 0x)
>+  dev->buf_len = *(dev->buf - 1) + 1;
>+
>   dev->buf_len--;
>+  /*
>+   * send NACK/STOP bits BEFORE last byte is
>+   * received
>+   */
>+  if (dev->buf_len == 1) {
>+  w = davinci_i2c_read_reg(dev,
>+  DAVINCI_I2C_MDR_REG);
>+  w |= DAVINCI_I2C_MDR_NACK;
>+  davinci_i2c_write_reg(dev,
>+  DAVINCI_I2C_MDR_REG, w);
>+
>+  w |= DAVINCI_I2C_MDR_STP;
>+  davinci_i2c_write_reg(dev,
>+  DAVINCI_I2C_MDR_REG, w);
>+  }
>+
>   if (dev->buf_len)
>   continue;
>
>--
>1.7.9.5
All,

Please review this when you get a chance.
Murali

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

RE: [PATCH] i2c: davinci: Add block read functionality for IPMI

2014-05-05 Thread Karicheri, Muralidharan

-Original Message-
From: Karicheri, Muralidharan
Sent: Thursday, May 01, 2014 2:50 PM
To: davinci-linux-open-sou...@linux.davincidsp.com; linux-...@vger.kernel.org; 
linux-
ker...@vger.kernel.org
Cc: Karicheri, Muralidharan; Ding, Garrett; Nori, Sekhar; Kevin Hilman; 
Wolfram Sang;
Shilimkar, Santosh
Subject: [PATCH] i2c: davinci: Add block read functionality for IPMI

Intelligent Plaform Management Interface (IPMI) requires I2C driver to support 
block read,
where the first byte received from slave is the length of following data:-  
Added length
check if the read type is block read (I2C_M_RECV_LEN)  Send NACK/STOP bits 
before last
byte is received

Signed-off-by: Garrett Ding g-d...@ti.com
Signed-off-by: Murali Karicheri m-kariche...@ti.com
Tested-by: Garrett Ding g-d...@ti.com
CC: Sekhar Nori nsek...@ti.com
CC: Kevin Hilman khil...@deeprootsystems.com
CC: Wolfram Sang w...@the-dreams.de
CC: Santosh Shilimkar santosh.shilim...@ti.com
---
 Tested on a customer board based on K2HK SoC
 drivers/i2c/busses/i2c-davinci.c |   42 +-

 1 file changed, 37 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-davinci.c 
b/drivers/i2c/busses/i2c-davinci.c
index 389bc68..cd97920 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -97,6 +97,10 @@
 #define DAVINCI_I2C_IMR_NACK  BIT(1)
 #define DAVINCI_I2C_IMR_ALBIT(0)

+/* capabilities */
+#define I2C_CAPABILITIES  (I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | \
+   I2C_FUNC_SMBUS_READ_BLOCK_DATA)
+
 struct davinci_i2c_dev {
   struct device   *dev;
   void __iomem*base;
@@ -318,7 +322,13 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct 
i2c_msg
*msg, int stop)
   davinci_i2c_write_reg(dev, DAVINCI_I2C_SAR_REG, msg-addr);

   dev-buf = msg-buf;
-  dev-buf_len = msg-len;
+
+   /* if first received byte is length, set buf_len = 0x as flag */
+  if (msg-flags  I2C_M_RECV_LEN)
+  dev-buf_len = 0x;
+  else
+  dev-buf_len = msg-len;
+
   dev-stop = stop;

   davinci_i2c_write_reg(dev, DAVINCI_I2C_CNT_REG, dev-buf_len); @@ -456,7
+466,7 @@ i2c_davinci_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], 
int num)

 static u32 i2c_davinci_func(struct i2c_adapter *adap)  {
-  return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+  return I2C_CAPABILITIES;
 }

 static void terminate_read(struct davinci_i2c_dev *dev) @@ -528,10 +538,32 @@ 
 static
irqreturn_t i2c_davinci_isr(int this_irq, void *dev_id)

   case DAVINCI_I2C_IVR_RDR:
   if (dev-buf_len) {
-  *dev-buf++ =
-  davinci_i2c_read_reg(dev,
-   DAVINCI_I2C_DRR_REG);
+  *dev-buf++ = davinci_i2c_read_reg(dev,
+  DAVINCI_I2C_DRR_REG);
+  /*
+   * check if the first received byte is message
+   * length, i.e, I2C_M_RECV_LEN
+   */
+  if (dev-buf_len == 0x)
+  dev-buf_len = *(dev-buf - 1) + 1;
+
   dev-buf_len--;
+  /*
+   * send NACK/STOP bits BEFORE last byte is
+   * received
+   */
+  if (dev-buf_len == 1) {
+  w = davinci_i2c_read_reg(dev,
+  DAVINCI_I2C_MDR_REG);
+  w |= DAVINCI_I2C_MDR_NACK;
+  davinci_i2c_write_reg(dev,
+  DAVINCI_I2C_MDR_REG, w);
+
+  w |= DAVINCI_I2C_MDR_STP;
+  davinci_i2c_write_reg(dev,
+  DAVINCI_I2C_MDR_REG, w);
+  }
+
   if (dev-buf_len)
   continue;

--
1.7.9.5
All,

Please review this when you get a chance.
Murali

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

RE: [PATCH v1] serial: uart: add hw flow control support configuration

2014-05-01 Thread Karicheri, Muralidharan

>-Original Message-
>From: Mark Rutland [mailto:mark.rutl...@arm.com]
>Sent: Tuesday, April 29, 2014 6:28 PM
>To: Karicheri, Muralidharan
>Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; 
>linux-ser...@vger.kernel.org;
>devicet...@vger.kernel.org; Rob Herring; Ian Campbell; Kumar Gala; Randy 
>Dunlap; Greg
>Kroah-Hartman; Jiri Slaby; Shilimkar, Santosh
>Subject: Re: [PATCH v1] serial: uart: add hw flow control support configuration
>
>Hi,
>
>On Tue, Apr 29, 2014 at 06:22:02PM +0100, Murali Karicheri wrote:
>> 8250 uart driver currently supports only software assisted hw flow
>> control. The software assisted hw flow control maintains a hw_stopped
>> flag in the tty structure to stop and start transmission and use modem
>> status interrupt for the event to drive the handshake signals. This is
>> not needed if hw has flow control capabilities. This patch adds a DT
>> attribute for enabling hw flow control for a uart port. Also skip stop
>> and start if this flag is present in flag field of the port structure.
>>
>> Signed-off-by: Murali Karicheri 
>>
>> CC: Rob Herring 
>> CC: Pawel Moll 
>> CC: Mark Rutland 
>> CC: Ian Campbell 
>> CC: Kumar Gala 
>> CC: Randy Dunlap 
>> CC: Greg Kroah-Hartman 
>> CC: Jiri Slaby 
>> CC: Santosh Shilimkar 
>> ---
>>  - Fixed brackets around port->flags & UPF_HARD_FLOW as per comments
>>  .../devicetree/bindings/serial/of-serial.txt   |2 ++
>>  drivers/tty/serial/8250/8250_core.c|6 --
>>  drivers/tty/serial/of_serial.c |4 
>>  drivers/tty/serial/serial_core.c   |   12 +---
>>  4 files changed, 19 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt
>> b/Documentation/devicetree/bindings/serial/of-serial.txt
>> index 1928a3e..123de01 100644
>> --- a/Documentation/devicetree/bindings/serial/of-serial.txt
>> +++ b/Documentation/devicetree/bindings/serial/of-serial.txt
>> @@ -37,6 +37,8 @@ Optional properties:
>>  - auto-flow-control: one way to enable automatic flow control support. The
>>driver is allowed to detect support for the capability even without this
>>property.
>> +- hw-flow-control: this enables pure hw flow control and no software
>> +  intervention needed.
>
>From the wording of the commit message, I believe this would be better worded
>something like:
>
>- hw-flow-control: the hardware has flow control capability.
>
>While the OS needs to know that flow control is present if it wishes to make 
>use of it,
>whether or not the OS does so is not a matter for the binding.
>
>It might also be better worded as "has-hw-flow-control", which would make that
>distinction clearer.
>
>Otherwise this looks fine to me.

Fine. Will re-send with rewording as

has-hw-flow-control: the hardware has flow control capability.

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

RE: [PATCH v1] serial: uart: add hw flow control support configuration

2014-05-01 Thread Karicheri, Muralidharan

-Original Message-
From: Mark Rutland [mailto:mark.rutl...@arm.com]
Sent: Tuesday, April 29, 2014 6:28 PM
To: Karicheri, Muralidharan
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; 
linux-ser...@vger.kernel.org;
devicet...@vger.kernel.org; Rob Herring; Ian Campbell; Kumar Gala; Randy 
Dunlap; Greg
Kroah-Hartman; Jiri Slaby; Shilimkar, Santosh
Subject: Re: [PATCH v1] serial: uart: add hw flow control support configuration

Hi,

On Tue, Apr 29, 2014 at 06:22:02PM +0100, Murali Karicheri wrote:
 8250 uart driver currently supports only software assisted hw flow
 control. The software assisted hw flow control maintains a hw_stopped
 flag in the tty structure to stop and start transmission and use modem
 status interrupt for the event to drive the handshake signals. This is
 not needed if hw has flow control capabilities. This patch adds a DT
 attribute for enabling hw flow control for a uart port. Also skip stop
 and start if this flag is present in flag field of the port structure.

 Signed-off-by: Murali Karicheri m-kariche...@ti.com

 CC: Rob Herring robh...@kernel.org
 CC: Pawel Moll pawel.m...@arm.com
 CC: Mark Rutland mark.rutl...@arm.com
 CC: Ian Campbell ijc+devicet...@hellion.org.uk
 CC: Kumar Gala ga...@codeaurora.org
 CC: Randy Dunlap rdun...@infradead.org
 CC: Greg Kroah-Hartman gre...@linuxfoundation.org
 CC: Jiri Slaby jsl...@suse.cz
 CC: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  - Fixed brackets around port-flags  UPF_HARD_FLOW as per comments
  .../devicetree/bindings/serial/of-serial.txt   |2 ++
  drivers/tty/serial/8250/8250_core.c|6 --
  drivers/tty/serial/of_serial.c |4 
  drivers/tty/serial/serial_core.c   |   12 +---
  4 files changed, 19 insertions(+), 5 deletions(-)

 diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt
 b/Documentation/devicetree/bindings/serial/of-serial.txt
 index 1928a3e..123de01 100644
 --- a/Documentation/devicetree/bindings/serial/of-serial.txt
 +++ b/Documentation/devicetree/bindings/serial/of-serial.txt
 @@ -37,6 +37,8 @@ Optional properties:
  - auto-flow-control: one way to enable automatic flow control support. The
driver is allowed to detect support for the capability even without this
property.
 +- hw-flow-control: this enables pure hw flow control and no software
 +  intervention needed.

From the wording of the commit message, I believe this would be better worded
something like:

- hw-flow-control: the hardware has flow control capability.

While the OS needs to know that flow control is present if it wishes to make 
use of it,
whether or not the OS does so is not a matter for the binding.

It might also be better worded as has-hw-flow-control, which would make that
distinction clearer.

Otherwise this looks fine to me.

Fine. Will re-send with rewording as

has-hw-flow-control: the hardware has flow control capability.

Murali

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

RE: [PATCH] serial: uart: add hw flow control support configuration

>-Original Message-
>From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
>Sent: Thursday, April 24, 2014 7:31 PM
>To: Karicheri, Muralidharan
>Cc: devicet...@vger.kernel.org; linux-...@vger.kernel.org; 
>linux-kernel@vger.kernel.org;
>linux-ser...@vger.kernel.org; Balbi, Felipe; Rob Herring; Mark Rutland; Ian 
>Campbell;
>Kumar Gala; Randy Dunlap; Jiri Slaby
>Subject: Re: [PATCH] serial: uart: add hw flow control support configuration
>
>On Wed, Apr 23, 2014 at 02:31:51PM +, Karicheri, Muralidharan wrote:
>>
>> Can this be queued up for merge if looks good?
>
>Can you fix up the line Alan had questions about?
>
>thanks,
>
>greg k-h

Greg,

I have posted v1 of the patch to list with the above change. Please pick it for
merge if it looks good.

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

RE: [PATCH] serial: uart: add hw flow control support configuration

>-Original Message-
>From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
>Sent: Thursday, April 24, 2014 7:31 PM
>To: Karicheri, Muralidharan
>Cc: devicet...@vger.kernel.org; linux-...@vger.kernel.org; 
>linux-kernel@vger.kernel.org;
>linux-ser...@vger.kernel.org; Balbi, Felipe; Rob Herring; Mark Rutland; Ian 
>Campbell;
>Kumar Gala; Randy Dunlap; Jiri Slaby
>Subject: Re: [PATCH] serial: uart: add hw flow control support configuration
>
>On Wed, Apr 23, 2014 at 02:31:51PM +, Karicheri, Muralidharan wrote:
>>
>> Can this be queued up for merge if looks good?
>
>Can you fix up the line Alan had questions about?
>
>thanks,
>
>greg k-h

Will fix and re-send the patch

Thanks

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

RE: [PATCH] serial: uart: add hw flow control support configuration

-Original Message-
From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
Sent: Thursday, April 24, 2014 7:31 PM
To: Karicheri, Muralidharan
Cc: devicet...@vger.kernel.org; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org;
linux-ser...@vger.kernel.org; Balbi, Felipe; Rob Herring; Mark Rutland; Ian 
Campbell;
Kumar Gala; Randy Dunlap; Jiri Slaby
Subject: Re: [PATCH] serial: uart: add hw flow control support configuration

On Wed, Apr 23, 2014 at 02:31:51PM +, Karicheri, Muralidharan wrote:

 Can this be queued up for merge if looks good?

Can you fix up the line Alan had questions about?

thanks,

greg k-h

Will fix and re-send the patch

Thanks

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

RE: [PATCH] serial: uart: add hw flow control support configuration

-Original Message-
From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
Sent: Thursday, April 24, 2014 7:31 PM
To: Karicheri, Muralidharan
Cc: devicet...@vger.kernel.org; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org;
linux-ser...@vger.kernel.org; Balbi, Felipe; Rob Herring; Mark Rutland; Ian 
Campbell;
Kumar Gala; Randy Dunlap; Jiri Slaby
Subject: Re: [PATCH] serial: uart: add hw flow control support configuration

On Wed, Apr 23, 2014 at 02:31:51PM +, Karicheri, Muralidharan wrote:

 Can this be queued up for merge if looks good?

Can you fix up the line Alan had questions about?

thanks,

greg k-h

Greg,

I have posted v1 of the patch to list with the above change. Please pick it for
merge if it looks good.

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

RE: [PATCH] serial: uart: add hw flow control support configuration

>-Original Message-
>From: Karicheri, Muralidharan
>Sent: Friday, April 11, 2014 3:18 PM
>To: devicet...@vger.kernel.org; linux-...@vger.kernel.org; 
>linux-kernel@vger.kernel.org;
>linux-ser...@vger.kernel.org
>Cc: Balbi, Felipe; Karicheri, Muralidharan; Rob Herring; Mark Rutland; Ian 
>Campbell;
>Kumar Gala; Randy Dunlap; Greg Kroah-Hartman; Jiri Slaby
>Subject: [PATCH] serial: uart: add hw flow control support configuration
>
>8250 uart driver currently supports only software assisted hw flow control. 
>The software
>assisted hw flow control maintains a hw_stopped flag in the tty structure to 
>stop and start
>transmission and use modem status interrupt for the event to drive the 
>handshake signals.
>This is not needed if hw has flow control capabilities. This patch adds a DT 
>attribute for
>enabling hw flow control for a uart port. Also skip stop and start if this 
>flag is present in flag
>field of the port structure.
>
>CC: Rob Herring 
>CC: Pawel Moll 
>CC: Mark Rutland 
>CC: Ian Campbell 
>CC: Kumar Gala 
>CC: Randy Dunlap 
>CC: Greg Kroah-Hartman 
>CC: Jiri Slaby 
>
>Signed-off-by: Murali Karicheri 
>---
> .../devicetree/bindings/serial/of-serial.txt   |2 ++
> drivers/tty/serial/8250/8250_core.c|6 --
> drivers/tty/serial/of_serial.c |4 
> drivers/tty/serial/serial_core.c   |   12 +---
> 4 files changed, 19 insertions(+), 5 deletions(-)
>
>diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt
>b/Documentation/devicetree/bindings/serial/of-serial.txt
>index 1928a3e..123de01 100644
>--- a/Documentation/devicetree/bindings/serial/of-serial.txt
>+++ b/Documentation/devicetree/bindings/serial/of-serial.txt
>@@ -37,6 +37,8 @@ Optional properties:
> - auto-flow-control: one way to enable automatic flow control support. The
>   driver is allowed to detect support for the capability even without this
>   property.
>+- hw-flow-control: this enables pure hw flow control and no software
>+  intervention needed.
>
> Example:
>
>diff --git a/drivers/tty/serial/8250/8250_core.c 
>b/drivers/tty/serial/8250/8250_core.c
>index 81f909c..6b1b868 100644
>--- a/drivers/tty/serial/8250/8250_core.c
>+++ b/drivers/tty/serial/8250/8250_core.c
>@@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port, struct
>ktermios *termios,
>* the trigger, or the MCR RTS bit is cleared.  In the case where
>* the remote UART is not using CTS auto flow control, we must
>* have sufficient FIFO entries for the latency of the remote
>-   * UART to respond.  IOW, at least 32 bytes of FIFO.
>+   * UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
>+   * AFE if hw flow control is supported
>*/
>-  if (up->capabilities & UART_CAP_AFE && port->fifosize >= 32) {
>+  if ((up->capabilities & UART_CAP_AFE && (port->fifosize >= 32)) ||
>+  port->flags & UPF_HARD_FLOW) {
>   up->mcr &= ~UART_MCR_AFE;
>   if (termios->c_cflag & CRTSCTS)
>   up->mcr |= UART_MCR_AFE;
>diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c 
>index
>9924660..1a5f528 100644
>--- a/drivers/tty/serial/of_serial.c
>+++ b/drivers/tty/serial/of_serial.c
>@@ -182,6 +182,10 @@ static int of_platform_serial_probe(struct 
>platform_device *ofdev)
> "auto-flow-control"))
>   port8250.capabilities |= UART_CAP_AFE;
>
>+  if (of_property_read_bool(ofdev->dev.of_node,
>+"hw-flow-control"))
>+  port8250.port.flags |= UPF_HARD_FLOW;
>+
>   ret = serial8250_register_8250_port();
>   break;
>   }
>diff --git a/drivers/tty/serial/serial_core.c 
>b/drivers/tty/serial/serial_core.c
>index 2cf5649..16e3615 100644
>--- a/drivers/tty/serial/serial_core.c
>+++ b/drivers/tty/serial/serial_core.c
>@@ -170,8 +170,12 @@ static int uart_port_startup(struct tty_struct *tty, 
>struct
>uart_state *state,
>   if (tty->termios.c_cflag & CBAUD)
>   uart_set_mctrl(uport, TIOCM_RTS | TIOCM_DTR);
>   }
>-
>-  if (tty_port_cts_enabled(port)) {
>+  /*
>+   * if hw support flow control without software intervention,
>+   * then skip the below check
>+   */
>+  if (tty_port_cts_enabled(port) &&
>+  !(uport-&g

RE: [PATCH] serial: uart: add hw flow control support configuration

Alan,

Sorry, I had to cut-n-paste your comment as I lost your email from my inbox.

>-Original Message-
>From: Karicheri, Muralidharan
>Sent: Friday, April 11, 2014 3:18 PM
>To: devicet...@vger.kernel.org; linux-...@vger.kernel.org; 
>linux-kernel@vger.kernel.org;
>linux-ser...@vger.kernel.org
>Cc: Balbi, Felipe; Karicheri, Muralidharan; Rob Herring; Mark Rutland; Ian 
>Campbell;
>Kumar Gala; Randy Dunlap; Greg Kroah-Hartman; Jiri Slaby
>Subject: [PATCH] serial: uart: add hw flow control support configuration
>
>8250 uart driver currently supports only software assisted hw flow control. 
>The software
>assisted hw flow control maintains a hw_stopped flag in the tty structure to 
>stop and start
>transmission and use modem status interrupt for the event to drive the 
>handshake signals.
>This is not needed if hw has flow control capabilities. This patch adds a DT 
>attribute for
>enabling hw flow control for a uart port. Also skip stop and start if this 
>flag is present in flag
>field of the port structure.

[Alan] That seems a sensible thing to add.

>
>CC: Rob Herring 
>CC: Pawel Moll 
>CC: Mark Rutland 
>CC: Ian Campbell 
>CC: Kumar Gala 
>CC: Randy Dunlap 
>CC: Greg Kroah-Hartman 
>CC: Jiri Slaby 
>
>Signed-off-by: Murali Karicheri 
>---
> .../devicetree/bindings/serial/of-serial.txt   |2 ++
> drivers/tty/serial/8250/8250_core.c|6 --
> drivers/tty/serial/of_serial.c |4 
> drivers/tty/serial/serial_core.c   |   12 +---
> 4 files changed, 19 insertions(+), 5 deletions(-)
>
>diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt
>b/Documentation/devicetree/bindings/serial/of-serial.txt
>index 1928a3e..123de01 100644
>--- a/Documentation/devicetree/bindings/serial/of-serial.txt
>+++ b/Documentation/devicetree/bindings/serial/of-serial.txt
>@@ -37,6 +37,8 @@ Optional properties:
> - auto-flow-control: one way to enable automatic flow control support. The
>   driver is allowed to detect support for the capability even without this
>   property.
>+- hw-flow-control: this enables pure hw flow control and no software
>+  intervention needed.
>
> Example:
>
>diff --git a/drivers/tty/serial/8250/8250_core.c 
>b/drivers/tty/serial/8250/8250_core.c
>index 81f909c..6b1b868 100644
>--- a/drivers/tty/serial/8250/8250_core.c
>+++ b/drivers/tty/serial/8250/8250_core.c
>@@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port, struct
>ktermios *termios,
>* the trigger, or the MCR RTS bit is cleared.  In the case where
>* the remote UART is not using CTS auto flow control, we must
>* have sufficient FIFO entries for the latency of the remote
>-   * UART to respond.  IOW, at least 32 bytes of FIFO.
>+   * UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
>+   * AFE if hw flow control is supported
>*/
>-  if (up->capabilities & UART_CAP_AFE && port->fifosize >= 32) {
>+  if ((up->capabilities & UART_CAP_AFE && (port->fifosize >= 32)) ||
>+  port->flags & UPF_HARD_FLOW) {

[Alan] Surely you want brackets on the port->flags & UPF_HARD_FLOW ??

The C precedence table shows following order:=
-> & ||

So flags will be accessed first and then AND-ed with  UPF_HARD_FLOW and
result will be OR-ed with left side expression value. So no need for bracket 
IMO.

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

RE: [PATCH] serial: uart: add hw flow control support configuration

Alan,

Sorry, I had to cut-n-paste your comment as I lost your email from my inbox.

-Original Message-
From: Karicheri, Muralidharan
Sent: Friday, April 11, 2014 3:18 PM
To: devicet...@vger.kernel.org; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org;
linux-ser...@vger.kernel.org
Cc: Balbi, Felipe; Karicheri, Muralidharan; Rob Herring; Mark Rutland; Ian 
Campbell;
Kumar Gala; Randy Dunlap; Greg Kroah-Hartman; Jiri Slaby
Subject: [PATCH] serial: uart: add hw flow control support configuration

8250 uart driver currently supports only software assisted hw flow control. 
The software
assisted hw flow control maintains a hw_stopped flag in the tty structure to 
stop and start
transmission and use modem status interrupt for the event to drive the 
handshake signals.
This is not needed if hw has flow control capabilities. This patch adds a DT 
attribute for
enabling hw flow control for a uart port. Also skip stop and start if this 
flag is present in flag
field of the port structure.

[Alan] That seems a sensible thing to add.


CC: Rob Herring robh...@kernel.org
CC: Pawel Moll pawel.m...@arm.com
CC: Mark Rutland mark.rutl...@arm.com
CC: Ian Campbell ijc+devicet...@hellion.org.uk
CC: Kumar Gala ga...@codeaurora.org
CC: Randy Dunlap rdun...@infradead.org
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
CC: Jiri Slaby jsl...@suse.cz

Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
 .../devicetree/bindings/serial/of-serial.txt   |2 ++
 drivers/tty/serial/8250/8250_core.c|6 --
 drivers/tty/serial/of_serial.c |4 
 drivers/tty/serial/serial_core.c   |   12 +---
 4 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt
b/Documentation/devicetree/bindings/serial/of-serial.txt
index 1928a3e..123de01 100644
--- a/Documentation/devicetree/bindings/serial/of-serial.txt
+++ b/Documentation/devicetree/bindings/serial/of-serial.txt
@@ -37,6 +37,8 @@ Optional properties:
 - auto-flow-control: one way to enable automatic flow control support. The
   driver is allowed to detect support for the capability even without this
   property.
+- hw-flow-control: this enables pure hw flow control and no software
+  intervention needed.

 Example:

diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 81f909c..6b1b868 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port, struct
ktermios *termios,
* the trigger, or the MCR RTS bit is cleared.  In the case where
* the remote UART is not using CTS auto flow control, we must
* have sufficient FIFO entries for the latency of the remote
-   * UART to respond.  IOW, at least 32 bytes of FIFO.
+   * UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
+   * AFE if hw flow control is supported
*/
-  if (up-capabilities  UART_CAP_AFE  port-fifosize = 32) {
+  if ((up-capabilities  UART_CAP_AFE  (port-fifosize = 32)) ||
+  port-flags  UPF_HARD_FLOW) {

[Alan] Surely you want brackets on the port-flags  UPF_HARD_FLOW ??

The C precedence table shows following order:=
-  ||

So flags will be accessed first and then AND-ed with  UPF_HARD_FLOW and
result will be OR-ed with left side expression value. So no need for bracket 
IMO.

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

RE: [PATCH] serial: uart: add hw flow control support configuration

-Original Message-
From: Karicheri, Muralidharan
Sent: Friday, April 11, 2014 3:18 PM
To: devicet...@vger.kernel.org; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org;
linux-ser...@vger.kernel.org
Cc: Balbi, Felipe; Karicheri, Muralidharan; Rob Herring; Mark Rutland; Ian 
Campbell;
Kumar Gala; Randy Dunlap; Greg Kroah-Hartman; Jiri Slaby
Subject: [PATCH] serial: uart: add hw flow control support configuration

8250 uart driver currently supports only software assisted hw flow control. 
The software
assisted hw flow control maintains a hw_stopped flag in the tty structure to 
stop and start
transmission and use modem status interrupt for the event to drive the 
handshake signals.
This is not needed if hw has flow control capabilities. This patch adds a DT 
attribute for
enabling hw flow control for a uart port. Also skip stop and start if this 
flag is present in flag
field of the port structure.

CC: Rob Herring robh...@kernel.org
CC: Pawel Moll pawel.m...@arm.com
CC: Mark Rutland mark.rutl...@arm.com
CC: Ian Campbell ijc+devicet...@hellion.org.uk
CC: Kumar Gala ga...@codeaurora.org
CC: Randy Dunlap rdun...@infradead.org
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
CC: Jiri Slaby jsl...@suse.cz

Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
 .../devicetree/bindings/serial/of-serial.txt   |2 ++
 drivers/tty/serial/8250/8250_core.c|6 --
 drivers/tty/serial/of_serial.c |4 
 drivers/tty/serial/serial_core.c   |   12 +---
 4 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt
b/Documentation/devicetree/bindings/serial/of-serial.txt
index 1928a3e..123de01 100644
--- a/Documentation/devicetree/bindings/serial/of-serial.txt
+++ b/Documentation/devicetree/bindings/serial/of-serial.txt
@@ -37,6 +37,8 @@ Optional properties:
 - auto-flow-control: one way to enable automatic flow control support. The
   driver is allowed to detect support for the capability even without this
   property.
+- hw-flow-control: this enables pure hw flow control and no software
+  intervention needed.

 Example:

diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 81f909c..6b1b868 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port, struct
ktermios *termios,
* the trigger, or the MCR RTS bit is cleared.  In the case where
* the remote UART is not using CTS auto flow control, we must
* have sufficient FIFO entries for the latency of the remote
-   * UART to respond.  IOW, at least 32 bytes of FIFO.
+   * UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
+   * AFE if hw flow control is supported
*/
-  if (up-capabilities  UART_CAP_AFE  port-fifosize = 32) {
+  if ((up-capabilities  UART_CAP_AFE  (port-fifosize = 32)) ||
+  port-flags  UPF_HARD_FLOW) {
   up-mcr = ~UART_MCR_AFE;
   if (termios-c_cflag  CRTSCTS)
   up-mcr |= UART_MCR_AFE;
diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c 
index
9924660..1a5f528 100644
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -182,6 +182,10 @@ static int of_platform_serial_probe(struct 
platform_device *ofdev)
 auto-flow-control))
   port8250.capabilities |= UART_CAP_AFE;

+  if (of_property_read_bool(ofdev-dev.of_node,
+hw-flow-control))
+  port8250.port.flags |= UPF_HARD_FLOW;
+
   ret = serial8250_register_8250_port(port8250);
   break;
   }
diff --git a/drivers/tty/serial/serial_core.c 
b/drivers/tty/serial/serial_core.c
index 2cf5649..16e3615 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -170,8 +170,12 @@ static int uart_port_startup(struct tty_struct *tty, 
struct
uart_state *state,
   if (tty-termios.c_cflag  CBAUD)
   uart_set_mctrl(uport, TIOCM_RTS | TIOCM_DTR);
   }
-
-  if (tty_port_cts_enabled(port)) {
+  /*
+   * if hw support flow control without software intervention,
+   * then skip the below check
+   */
+  if (tty_port_cts_enabled(port) 
+  !(uport-flags  UPF_HARD_FLOW)) {
   spin_lock_irq(uport-lock);
   if (!(uport-ops-get_mctrl(uport)  TIOCM_CTS))
   tty-hw_stopped = 1;
@@ -2768,7 +2772,9 @@ void uart_handle_cts_change(struct uart_port *uport, 
unsigned
int status)

   uport-icount.cts++;

-  if (tty_port_cts_enabled(port)) {
+  /* skip below code if the hw flow

RE: [PATCH 10/11] Revert "serial: omap: unlock the port lock"

>-Original Message-
>From: Balbi, Felipe
>Sent: Wednesday, March 26, 2014 11:37 PM
>To: Peter Hurley
>Cc: Balbi, Felipe; Tony Lindgren; Greg KH; linux-ser...@vger.kernel.org; linux-
>blueto...@vger.kernel.org; Karicheri, Muralidharan; b32...@freescale.com; 
>Linux OMAP
>Mailing List; Linux Kernel Mailing List
>Subject: Re: [PATCH 10/11] Revert "serial: omap: unlock the port lock"
>
>Hi,
>
>On Wed, Mar 26, 2014 at 10:27:13PM -0400, Peter Hurley wrote:
>> On 03/26/2014 10:10 PM, Felipe Balbi wrote:
>> >Hi,
>> >
>> >On Wed, Mar 26, 2014 at 08:39:11PM -0400, Peter Hurley wrote:
>> >>On 03/25/2014 02:28 PM, Tony Lindgren wrote:
>> >>>* Felipe Balbi  [140320 12:39]:
>> >>>>This reverts commit 0324a821029e1f54e7a7f8fed48693cfce42dc0e.
>> >>>>
>> >>>>That commit tried to fix a deadlock problem when using hci_ldisc,
>> >>>>but it turns out the bug was in hci_ldsic all along where it was
>> >>>>calling ->write() from within
>> >>>>->write_wakeup() callback.
>> >>>>
>> >>>>The problem is that ->write_wakeup() was called with port lock
>> >>>>held and ->write() tried to grab the same port lock.
>> >>>
>> >>>Should this and the next patch be earlier in the series as a fix
>> >>>for the v3.15-rc cycle? Should they be cc: stable as well?
>> >>
>> >>Well, right now the other fix has had _zero_ testing so not really a
>> >>-stable candidate just yet.
>> >
>> >how can you even say that ?
>>
>> I misunderstood when you wrote:
>>
>> On 03/20/2014 02:11 PM, Felipe Balbi wrote:
>> > here's a build-tested only patch which is waiting for testing from
>> > other colleagues who've got a platform to reproduce the problem:
>>
>> and then the version I reviewed had no Tested-by: tags.
>
>I wouldn't add that tag myself, but Murali (in Cc) did help testing together 
>with other

Yes. One of our customer did the test as the problem was reported by the
customer. The deadlock fix patch from Balbi (hci_ldsic) fixed the issue 
and customer confirmed that the issue is fixed.

Murali

>colleagues.
>
>> >How else would we have found the issue to start with ?
>>
>> Bug report?
>
>touchè :-)
>
>--
>balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RESEND: RFC PATCH 3/3] pcie: keystone: add pcie driver based on designware core driver

>-Original Message-
>From: Arnd Bergmann [mailto:a...@arndb.de]
>Sent: Tuesday, March 25, 2014 3:45 AM
>To: linux-arm-ker...@lists.infradead.org
>Cc: Karicheri, Muralidharan; linux-...@vger.kernel.org; linux-samsung-
>s...@vger.kernel.org; linux-kernel@vger.kernel.org; Richard Zhu; Kukjin Kim; 
>Mohit
>Kumar; Jingoo Han; Shilimkar, Santosh; Bjorn Helgaas; Shawn Guo
>Subject: Re: [RESEND: RFC PATCH 3/3] pcie: keystone: add pcie driver based on
>designware core driver
>
>On Monday 24 March 2014 20:35:26 Murali Karicheri wrote:
>> +
>> +int k2_pcie_platform_setup(struct platform_device *pdev) {
>> +struct resource *phy_base_r, *devstat_r;
>> +void __iomem *phy_base, *devstat;
>> +u32 val;
>> +int i;
>> +
>> +devstat_r = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>> + "reg_devcfg");
>> +if (!devstat_r)
>> +return -ENODEV;
>
>It seems you have a distinct register set for the PHY that you are driving 
>here. Why not
>make this part generic PHY API driver?
>
>> +static int ks_pcie_establish_link(struct keystone_pcie *ks_pcie) {
>> +struct pcie_port *pp = _pcie->pp;
>> +int count = 0;
>> +
>> +dw_pcie_setup_rc(pp);
>> +
>> +/* check if the link is up or not */
>> +while (!dw_pcie_link_up(pp)) {
>> +mdelay(100);
>> +count++;
>> +if (count == 10)
>> +return -EINVAL;
>> +}
>> +return 0;
>> +}
>
>You are blocking the CPU for up to one second here, which is really nasty. 
>Please find a way
>to move the code into a context where you can sleep and use msleep() instead, 
>or better
>use an interrupt if the hardware supports that and use wait_for_completion().
>
>> +
>> +static void ks_pcie_msi_irq_handler(unsigned int irq, struct irq_desc
>> +*desc) {
>> +struct keystone_pcie *ks_pcie = irq_desc_get_handler_data(desc);
>> +u32 offset = irq - ks_pcie->msi_host_irqs[0], pending, vector;
>> +struct pcie_port *pp = _pcie->pp;
>> +struct irq_chip *chip = irq_desc_get_chip(desc);
>> +int src, virq;
>
>Did I understand this right that the MSI implementation can be used by any 
>dw-pcie
>hardware of the same version? If so, it would be good to move it into an extra 
>file so it can
>be shared with the next host driver that uses this version.
>
>> +/**
>> + * ks_pcie_set_outbound_trans() - Set PHYADDR <-> BUSADDR
>> + * mapping for outbound
>> + */
>> +static void ks_pcie_set_outbound_trans(struct keystone_pcie *ks_pcie)
>
>> +static void ks_pcie_set_inbound_trans(struct pcie_port *pp)
>
>Why do you need to set this up from the kernel? Please move the translation 
>window setup
>into the boot loader if you can.
>
>> +static struct hw_pci keystone_pcie_hw = {
>> +.nr_controllers = 1,
>> +.setup  = dw_pcie_setup,
>> +.scan   = ks_pcie_scan_bus,
>> +.swizzle= pci_common_swizzle,
>> +.add_bus= dw_pcie_add_bus,
>> +.map_irq= ks_pcie_map_irq,
>> +};
>
>This can just be a local variable in the probe function.
>
>> +
>> +static int ks_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8
>> +pin) {
>> +struct pcie_port *pp = sys_to_pcie(dev->bus->sysdata);
>> +struct keystone_pcie *ks_pcie = to_keystone_pcie(pp);
>> +
>> +dev_info(pp->dev, "ks_pcie_map_irq: pin %d\n", pin);
>> +
>> +if (!pin || pin > ks_pcie->num_legacy_host_irqs) {
>> +dev_err(pp->dev, "pci irq pin out of range\n");
>> +return -1;
>> +}
>> +
>> +/* pin has values from 1-4 */
>> +return (ks_pcie->virqs[pin - 1] >= 0) ?
>> +ks_pcie->virqs[pin - 1] : -1;
>> +}
>> +
>> +
>> +static void ack_irq(struct irq_data *d) { }
>> +
>> +static void mask_irq(struct irq_data *d) { }
>> +
>> +static void unmask_irq(struct irq_data *d) { }
>> +
>> +static struct irq_chip ks_pcie_legacy_irq_chip = {
>> +.name = "PCIe-LEGACY-IRQ",
>> +.irq_ack = ack_irq,
>> +.irq_mask = mask_irq,
>> +.irq_unmask = unmask_irq,
>> +};
>
>Can you use the generic irqchip code here?
>
>> +/*
>> + * support upto MAX_LEGACY_HOST_IRQS host and legacy IRQs.
>> + * In dt from index 0 to 3
>> + */
>> +for (i = 0; i < MAX_LEGACY_HOST_IRQS; i++) {
>>

RE: [RESEND: RFC PATCH 3/3] pcie: keystone: add pcie driver based on designware core driver

-Original Message-
From: Arnd Bergmann [mailto:a...@arndb.de]
Sent: Tuesday, March 25, 2014 3:45 AM
To: linux-arm-ker...@lists.infradead.org
Cc: Karicheri, Muralidharan; linux-...@vger.kernel.org; linux-samsung-
s...@vger.kernel.org; linux-kernel@vger.kernel.org; Richard Zhu; Kukjin Kim; 
Mohit
Kumar; Jingoo Han; Shilimkar, Santosh; Bjorn Helgaas; Shawn Guo
Subject: Re: [RESEND: RFC PATCH 3/3] pcie: keystone: add pcie driver based on
designware core driver

On Monday 24 March 2014 20:35:26 Murali Karicheri wrote:
 +
 +int k2_pcie_platform_setup(struct platform_device *pdev) {
 +struct resource *phy_base_r, *devstat_r;
 +void __iomem *phy_base, *devstat;
 +u32 val;
 +int i;
 +
 +devstat_r = platform_get_resource_byname(pdev, IORESOURCE_MEM,
 + reg_devcfg);
 +if (!devstat_r)
 +return -ENODEV;

It seems you have a distinct register set for the PHY that you are driving 
here. Why not
make this part generic PHY API driver?

 +static int ks_pcie_establish_link(struct keystone_pcie *ks_pcie) {
 +struct pcie_port *pp = ks_pcie-pp;
 +int count = 0;
 +
 +dw_pcie_setup_rc(pp);
 +
 +/* check if the link is up or not */
 +while (!dw_pcie_link_up(pp)) {
 +mdelay(100);
 +count++;
 +if (count == 10)
 +return -EINVAL;
 +}
 +return 0;
 +}

You are blocking the CPU for up to one second here, which is really nasty. 
Please find a way
to move the code into a context where you can sleep and use msleep() instead, 
or better
use an interrupt if the hardware supports that and use wait_for_completion().

 +
 +static void ks_pcie_msi_irq_handler(unsigned int irq, struct irq_desc
 +*desc) {
 +struct keystone_pcie *ks_pcie = irq_desc_get_handler_data(desc);
 +u32 offset = irq - ks_pcie-msi_host_irqs[0], pending, vector;
 +struct pcie_port *pp = ks_pcie-pp;
 +struct irq_chip *chip = irq_desc_get_chip(desc);
 +int src, virq;

Did I understand this right that the MSI implementation can be used by any 
dw-pcie
hardware of the same version? If so, it would be good to move it into an extra 
file so it can
be shared with the next host driver that uses this version.

 +/**
 + * ks_pcie_set_outbound_trans() - Set PHYADDR - BUSADDR
 + * mapping for outbound
 + */
 +static void ks_pcie_set_outbound_trans(struct keystone_pcie *ks_pcie)

 +static void ks_pcie_set_inbound_trans(struct pcie_port *pp)

Why do you need to set this up from the kernel? Please move the translation 
window setup
into the boot loader if you can.

 +static struct hw_pci keystone_pcie_hw = {
 +.nr_controllers = 1,
 +.setup  = dw_pcie_setup,
 +.scan   = ks_pcie_scan_bus,
 +.swizzle= pci_common_swizzle,
 +.add_bus= dw_pcie_add_bus,
 +.map_irq= ks_pcie_map_irq,
 +};

This can just be a local variable in the probe function.

 +
 +static int ks_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8
 +pin) {
 +struct pcie_port *pp = sys_to_pcie(dev-bus-sysdata);
 +struct keystone_pcie *ks_pcie = to_keystone_pcie(pp);
 +
 +dev_info(pp-dev, ks_pcie_map_irq: pin %d\n, pin);
 +
 +if (!pin || pin  ks_pcie-num_legacy_host_irqs) {
 +dev_err(pp-dev, pci irq pin out of range\n);
 +return -1;
 +}
 +
 +/* pin has values from 1-4 */
 +return (ks_pcie-virqs[pin - 1] = 0) ?
 +ks_pcie-virqs[pin - 1] : -1;
 +}
 +
 +
 +static void ack_irq(struct irq_data *d) { }
 +
 +static void mask_irq(struct irq_data *d) { }
 +
 +static void unmask_irq(struct irq_data *d) { }
 +
 +static struct irq_chip ks_pcie_legacy_irq_chip = {
 +.name = PCIe-LEGACY-IRQ,
 +.irq_ack = ack_irq,
 +.irq_mask = mask_irq,
 +.irq_unmask = unmask_irq,
 +};

Can you use the generic irqchip code here?

 +/*
 + * support upto MAX_LEGACY_HOST_IRQS host and legacy IRQs.
 + * In dt from index 0 to 3
 + */
 +for (i = 0; i  MAX_LEGACY_HOST_IRQS; i++) {
 +ks_pcie-legacy_host_irqs[i] = irq_of_parse_and_map(np, i);
 +if (ks_pcie-legacy_host_irqs[i]  0)
 +break;
 +ks_pcie-num_legacy_host_irqs++;
 +}
 +
 +if (ks_pcie-num_legacy_host_irqs) {
 +ks_pcie-legacy_irqd = irq_domain_add_linear(np,
 +ks_pcie-num_legacy_host_irqs,
 +irq_domain_simple_ops, NULL);
 +
 +if (!ks_pcie-legacy_irqd) {
 +dev_err(dev,
 +Failed to add irq domain for legacy irqs\n);
 +return -EINVAL;
 +}
 +}
 +
 +for (i = 0; i  ks_pcie-num_legacy_host_irqs; i++) {
 +ks_pcie-virqs[i] =
 +irq_create_mapping(ks_pcie-legacy_irqd, i);
 +irq_set_chip_and_handler(ks_pcie-virqs[i],
 +ks_pcie_legacy_irq_chip, handle_level_irq

RE: [PATCH 10/11] Revert serial: omap: unlock the port lock

-Original Message-
From: Balbi, Felipe
Sent: Wednesday, March 26, 2014 11:37 PM
To: Peter Hurley
Cc: Balbi, Felipe; Tony Lindgren; Greg KH; linux-ser...@vger.kernel.org; linux-
blueto...@vger.kernel.org; Karicheri, Muralidharan; b32...@freescale.com; 
Linux OMAP
Mailing List; Linux Kernel Mailing List
Subject: Re: [PATCH 10/11] Revert serial: omap: unlock the port lock

Hi,

On Wed, Mar 26, 2014 at 10:27:13PM -0400, Peter Hurley wrote:
 On 03/26/2014 10:10 PM, Felipe Balbi wrote:
 Hi,
 
 On Wed, Mar 26, 2014 at 08:39:11PM -0400, Peter Hurley wrote:
 On 03/25/2014 02:28 PM, Tony Lindgren wrote:
 * Felipe Balbi ba...@ti.com [140320 12:39]:
 This reverts commit 0324a821029e1f54e7a7f8fed48693cfce42dc0e.
 
 That commit tried to fix a deadlock problem when using hci_ldisc,
 but it turns out the bug was in hci_ldsic all along where it was
 calling -write() from within
 -write_wakeup() callback.
 
 The problem is that -write_wakeup() was called with port lock
 held and -write() tried to grab the same port lock.
 
 Should this and the next patch be earlier in the series as a fix
 for the v3.15-rc cycle? Should they be cc: stable as well?
 
 Well, right now the other fix has had _zero_ testing so not really a
 -stable candidate just yet.
 
 how can you even say that ?

 I misunderstood when you wrote:

 On 03/20/2014 02:11 PM, Felipe Balbi wrote:
  here's a build-tested only patch which is waiting for testing from
  other colleagues who've got a platform to reproduce the problem:

 and then the version I reviewed had no Tested-by: tags.

I wouldn't add that tag myself, but Murali (in Cc) did help testing together 
with other

Yes. One of our customer did the test as the problem was reported by the
customer. The deadlock fix patch from Balbi (hci_ldsic) fixed the issue 
and customer confirmed that the issue is fixed.

Murali

colleagues.

 How else would we have found the issue to start with ?

 Bug report?

touchè :-)

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

RE: linux-next: manual merge of the clk tree with the keystone tree

2014-02-26 Thread Karicheri, Muralidharan

>-Original Message-
>From: Khoronzhuk, Ivan
>Sent: Wednesday, February 26, 2014 6:41 AM
>To: Stephen Rothwell; Mike Turquette; Shilimkar, Santosh
>Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Karicheri, 
>Muralidharan;
>Strashko, Grygorii
>Subject: Re: linux-next: manual merge of the clk tree with the keystone tree
>
>
>On 02/26/2014 09:15 AM, Stephen Rothwell wrote:
>> Hi Mike,
>>
>> Today's linux-next merge of the clk tree got a conflict in
>> arch/arm/boot/dts/keystone-clocks.dtsi between commit 0cfc9ccec2a8 ("ARM:
>> dts: keystone: preparatory patch to support K2L and K2E SOCs") from
>> the keystone tree and commit 565bbdcd3b91 ("ARM: keystone: dts: fix
>> clkvcp3 control register address") from the clk tree.
>>
>> I fixed it up (by adding the following merge fix patch) and can carry
>> the fix as necessary (no action is required).
>>
>> From: Stephen Rothwell 
>> Date: Wed, 26 Feb 2014 18:12:55 +1100
>> Subject: [PATCH] ARM: keystone: dts: fix for code movement
>>
>> Signed-off-by: Stephen Rothwell 
>> ---
>>   arch/arm/boot/dts/k2hk-clocks.dtsi | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/k2hk-clocks.dtsi
>> b/arch/arm/boot/dts/k2hk-clocks.dtsi
>> index 4eed84feb761..a71aa2996321 100644
>> --- a/arch/arm/boot/dts/k2hk-clocks.dtsi
>> +++ b/arch/arm/boot/dts/k2hk-clocks.dtsi
>> @@ -339,7 +339,7 @@ clocks {
>>  compatible = "ti,keystone,psc-clock";
>>  clocks = <>;
>>  clock-output-names = "vcp-3";
>> -reg = <0x0235000a8 0xb00>, <0x02350060 0x400>;
>> +reg = <0x023500a8 0xb00>, <0x02350060 0x400>;
>>  reg-names = "control", "domain";
>>  domain-id = <24>;
>>  };
>
>The patch "ARM: dts: keystone: preparatory patch to support K2L and K2E SOCs"
>is from "[PATCH 0/4] ARM: dts: keystone: Add support for K2H and K2E SOCs/EVMs"
>series (http://www.spinics.net/lists/arm-kernel/msg310946.html).
>
>As I understand, this series splits keystone clock tree into tree boards.
>As result clock "clkvcp3" (for wich reg is corrected) is moved to the 
>following two dts:
>
>k2hk-clocks.dtsi
>k2l-clocks.dtsi
>
>So probably you should apply this change to k2l-clocks.dtsi too.
>

Yes. The fix is needed for k2l-clocks.dtsi also. Thanks for taking care of this.

Murali Karicheri
Linux Kernel, Software Development

>--
>Regards,
>Ivan Khoronzhuk

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

RE: linux-next: manual merge of the clk tree with the keystone tree

2014-02-26 Thread Karicheri, Muralidharan

-Original Message-
From: Khoronzhuk, Ivan
Sent: Wednesday, February 26, 2014 6:41 AM
To: Stephen Rothwell; Mike Turquette; Shilimkar, Santosh
Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Karicheri, 
Muralidharan;
Strashko, Grygorii
Subject: Re: linux-next: manual merge of the clk tree with the keystone tree

On 02/26/2014 09:15 AM, Stephen Rothwell wrote:
 Hi Mike,

 Today's linux-next merge of the clk tree got a conflict in
 arch/arm/boot/dts/keystone-clocks.dtsi between commit 0cfc9ccec2a8 (ARM:
 dts: keystone: preparatory patch to support K2L and K2E SOCs) from
 the keystone tree and commit 565bbdcd3b91 (ARM: keystone: dts: fix
 clkvcp3 control register address) from the clk tree.

 I fixed it up (by adding the following merge fix patch) and can carry
 the fix as necessary (no action is required).

 From: Stephen Rothwell s...@canb.auug.org.au
 Date: Wed, 26 Feb 2014 18:12:55 +1100
 Subject: [PATCH] ARM: keystone: dts: fix for code movement

 Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
 ---
   arch/arm/boot/dts/k2hk-clocks.dtsi | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/arm/boot/dts/k2hk-clocks.dtsi
 b/arch/arm/boot/dts/k2hk-clocks.dtsi
 index 4eed84feb761..a71aa2996321 100644
 --- a/arch/arm/boot/dts/k2hk-clocks.dtsi
 +++ b/arch/arm/boot/dts/k2hk-clocks.dtsi
 @@ -339,7 +339,7 @@ clocks {
  compatible = ti,keystone,psc-clock;
  clocks = chipclk13;
  clock-output-names = vcp-3;
 -reg = 0x0235000a8 0xb00, 0x02350060 0x400;
 +reg = 0x023500a8 0xb00, 0x02350060 0x400;
  reg-names = control, domain;
  domain-id = 24;
  };

The patch ARM: dts: keystone: preparatory patch to support K2L and K2E SOCs
is from [PATCH 0/4] ARM: dts: keystone: Add support for K2H and K2E SOCs/EVMs
series (http://www.spinics.net/lists/arm-kernel/msg310946.html).

As I understand, this series splits keystone clock tree into tree boards.
As result clock clkvcp3 (for wich reg is corrected) is moved to the 
following two dts:

k2hk-clocks.dtsi
k2l-clocks.dtsi

So probably you should apply this change to k2l-clocks.dtsi too.

Yes. The fix is needed for k2l-clocks.dtsi also. Thanks for taking care of this.

Murali Karicheri
Linux Kernel, Software Development

--
Regards,
Ivan Khoronzhuk

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

RE: [PATCH v3 00/11] common clk drivers migration for DaVinci SoCs

2012-10-30 Thread Karicheri, Muralidharan

Mike, Sekhar,

Could you please take some time to review this patch set? Last one was reviewed 
by Sekhar and I have re-worked the patch to address his comments.

Murali

>> -Original Message-
>> From: Karicheri, Muralidharan
>> Sent: Thursday, October 25, 2012 12:12 PM
>> To: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
>> shawn@linaro.org; rob.herr...@calxeda.com; linus.wall...@linaro.org;
>> viresh.li...@gmail.com; linux-kernel@vger.kernel.org; Nori, Sekhar; Hilman, 
>> Kevin;
>> li...@arm.linux.org.uk; sshtyl...@mvista.com; davinci-linux-open-
>> sou...@linux.davincidsp.com; linux-arm-ker...@lists.infradead.org
>> Cc: linux-keyst...@list.ti.com - Linux developers for Keystone family of 
>> devices (May
>> contain non-TIers); Karicheri, Muralidharan
>> Subject: [PATCH v3 00/11] common clk drivers migration for DaVinci SoCs
>> 
>> This is v3 of the patch series for implementing clock tree for DaVinci SoCs 
>> using common
>> clk framework.
>> 
>> supported platforms: DM644x
>> 
>> This code base can be accessed at
>> 
>> https://gitorious.org/~m-karicheri/linux-davinci/linux-davinci-clk/commits/common-clk-
>> v3
>> 
>> The patch series is split in two parts:-
>>   patches prefixed with "clk" are for clk drivers
>>   patches prefixed with "ARM" are for davinci machine specific code.
>> 
>> revision history:
>> -
>> updates in v3:
>>  - Major changes done based on review of v2 to move the clock data and
>>initialization code to drivers/clk/davinci. There is a soc specific
>>code (for example dm644x-clock.c) for doing clock initialization.
>>  - Files renamed based on the review comments.
>>  - Only DM644x is supported. Other devices will be added as the code
>>matures so that unnecessary rework can be avoided.
>>  - Incorporated comments from Nori Sekhar and Linus (comments coding
>>style)
>>  - Added clk-div clock to represent DaVinci pll divider clocks
>>  - Removed clk-keystone-pll.c (will be added later)
>> 
>> updates in v2:
>>  - updates to davinci_clk to use union for clk driver platform data
>>  - Fixed Linus Walleij' comment on code comment
>>  - added code clean up that takes out the ifdef used in previous patches
>> 
>> updates in v1:
>>  - Added DM365 and DM355
>>  - updates to davinci_clk struct to accomodate clk-fixed-factor data
>> 
>> initial version:-
>> 
>> Currently arch/arm/mach-davinci/clock.c and arch/arm/mach-davinci/psc.c 
>> implements
>> clock drivers for DaVinci. This patch makes these code obsolete and migrate 
>> the SoC code
>> to use the common clk based drivers. This adds two clk drivers specific to 
>> DaVinci and
>> Keystone (found in c6x arch such as C6678) devices. Some of the existing clk 
>> drivers such
>> as clk-fixed-rate, clk-divider, and clk-mux are re-used in addition to the 
>> DaVinci specific
>> drivers to initialize the clock tree for the SoCs. Please refer chapter 6 of
>> http://www.ti.com/lit/ug/sprue14c/sprue14c.pdf for details of the PLL 
>> hardware in
>> DM6446 and chapter 7 for defails of the PSC hardware.
>> 
>> There are two Main PLLs in DM644x. PLL1 and PLL2. Each of these generate 
>> different
>> clocks in the DM device through PLL dividers. Figure above shows this for 
>> PLL1. Similar
>> hardware exists for PLL2 and the related output clocks. The hardware is 
>> similar in most of
>> the DM SoCs. Some of the recent Keystone devices
>> (c6678 under c6x architecture) include a slight variant of the PLL that 
>> implemented
>> different registers for the multipliers and dividers. All of these devices 
>> include PLL dividers
>> (PLLDIVx) and Power Sleep controllers (PSC). The SoCs defines various Power 
>> Domains
>> and Clock domains and there are PSC modules that controls power and clocks 
>> to various
>> hardware IPs of the SoC.
>> 
>> Following drivers are used for various clock hardware blocks:-
>> 
>> CLKIN and OSCIN - clk-fixed-rate (existing driver) MUX - clk-mux (existing 
>> driver)
>> PLLDIVx - davinci/clk-div (new driver) PLL mult/div - clk-pll (new driver) 
>> PSC - clk-psc.c
>> (new driver)
>> 
>> Please note that initially only platforms listed above are supported. The 
>> idea is to review
>> the initial patch set and get a feedback on the overall structure of the 
>> code organization.
>> T

RE: [PATCH v3 00/11] common clk drivers migration for DaVinci SoCs

2012-10-30 Thread Karicheri, Muralidharan

Mike, Sekhar,

Could you please take some time to review this patch set? Last one was reviewed 
by Sekhar and I have re-worked the patch to address his comments.

Murali

 -Original Message-
 From: Karicheri, Muralidharan
 Sent: Thursday, October 25, 2012 12:12 PM
 To: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
 shawn@linaro.org; rob.herr...@calxeda.com; linus.wall...@linaro.org;
 viresh.li...@gmail.com; linux-kernel@vger.kernel.org; Nori, Sekhar; Hilman, 
 Kevin;
 li...@arm.linux.org.uk; sshtyl...@mvista.com; davinci-linux-open-
 sou...@linux.davincidsp.com; linux-arm-ker...@lists.infradead.org
 Cc: linux-keyst...@list.ti.com - Linux developers for Keystone family of 
 devices (May
 contain non-TIers); Karicheri, Muralidharan
 Subject: [PATCH v3 00/11] common clk drivers migration for DaVinci SoCs
 
 This is v3 of the patch series for implementing clock tree for DaVinci SoCs 
 using common
 clk framework.
 
 supported platforms: DM644x
 
 This code base can be accessed at
 
 https://gitorious.org/~m-karicheri/linux-davinci/linux-davinci-clk/commits/common-clk-
 v3
 
 The patch series is split in two parts:-
   patches prefixed with clk are for clk drivers
   patches prefixed with ARM are for davinci machine specific code.
 
 revision history:
 -
 updates in v3:
  - Major changes done based on review of v2 to move the clock data and
initialization code to drivers/clk/davinci. There is a soc specific
code (for example dm644x-clock.c) for doing clock initialization.
  - Files renamed based on the review comments.
  - Only DM644x is supported. Other devices will be added as the code
matures so that unnecessary rework can be avoided.
  - Incorporated comments from Nori Sekhar and Linus (comments coding
style)
  - Added clk-div clock to represent DaVinci pll divider clocks
  - Removed clk-keystone-pll.c (will be added later)
 
 updates in v2:
  - updates to davinci_clk to use union for clk driver platform data
  - Fixed Linus Walleij' comment on code comment
  - added code clean up that takes out the ifdef used in previous patches
 
 updates in v1:
  - Added DM365 and DM355
  - updates to davinci_clk struct to accomodate clk-fixed-factor data
 
 initial version:-
 
 Currently arch/arm/mach-davinci/clock.c and arch/arm/mach-davinci/psc.c 
 implements
 clock drivers for DaVinci. This patch makes these code obsolete and migrate 
 the SoC code
 to use the common clk based drivers. This adds two clk drivers specific to 
 DaVinci and
 Keystone (found in c6x arch such as C6678) devices. Some of the existing clk 
 drivers such
 as clk-fixed-rate, clk-divider, and clk-mux are re-used in addition to the 
 DaVinci specific
 drivers to initialize the clock tree for the SoCs. Please refer chapter 6 of
 http://www.ti.com/lit/ug/sprue14c/sprue14c.pdf for details of the PLL 
 hardware in
 DM6446 and chapter 7 for defails of the PSC hardware.
 
 There are two Main PLLs in DM644x. PLL1 and PLL2. Each of these generate 
 different
 clocks in the DM device through PLL dividers. Figure above shows this for 
 PLL1. Similar
 hardware exists for PLL2 and the related output clocks. The hardware is 
 similar in most of
 the DM SoCs. Some of the recent Keystone devices
 (c6678 under c6x architecture) include a slight variant of the PLL that 
 implemented
 different registers for the multipliers and dividers. All of these devices 
 include PLL dividers
 (PLLDIVx) and Power Sleep controllers (PSC). The SoCs defines various Power 
 Domains
 and Clock domains and there are PSC modules that controls power and clocks 
 to various
 hardware IPs of the SoC.
 
 Following drivers are used for various clock hardware blocks:-
 
 CLKIN and OSCIN - clk-fixed-rate (existing driver) MUX - clk-mux (existing 
 driver)
 PLLDIVx - davinci/clk-div (new driver) PLL mult/div - clk-pll (new driver) 
 PSC - clk-psc.c
 (new driver)
 
 Please note that initially only platforms listed above are supported. The 
 idea is to review
 the initial patch set and get a feedback on the overall structure of the 
 code organization.
 The other SoCs will be added in subsequent patch revisions.
 
 The driver code implements the features needed to support the platforms 
 listed above. It
 is expected that these drivers get updated in subsequent patch revisions to 
 support
 additional SoCs. I have boot tested this on DM6446 EVM. Also verified reboot 
 command
 works and the clock rates are set as before.
 The patches depends on the following patches that I had sent for review 
 earlier:
 
 davinci spi driver preparation @
 https://patchwork.kernel.org/patch/1389321/
 davinci watchdog driver preparation @
 https://lkml.org/lkml/2012/9/7/634
 davinci nand driver preparation @
 https://lkml.org/lkml/2012/9/7/635
 davinci i2c driver preparation @
 https://patchwork.kernel.org/patch/1388841/
 davinci gpio driver preparation @
 https://lkml.org/lkml

RE: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use common clk drivers

--Cut

>> Subject: Re: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to 
>> use
>> common clk drivers
>> 
>> >>> You have chosen to keep all clock related data in platform files
>> >>> while using the common clock framework to provide just the
>> >>> infrastructure. If you look at how mxs and spear have been migrated, 
>> >>> they have
>> migrated the soc specific clock data to drivers/clk as well.
>> >>> See "drivers/clk/spear/spear3xx_clock.c" or
>> >>> "drivers/clk/mxs/clk-imx23.c
>> >
>> > I have to disagree on this one. I had investigated these code already
>> > and came up with a way that we can re-use code across all of the
>> > davinci platforms as well as other architectures that re-uses the clk 
>> > hardware IPs.
>> 
>> Which code you are talking about here? Even if you introduce clk-dm644x.c, 
>> clk-
>> keystone.c etc in drivers/clk/davinci/ you can reuse the code you introduce 
>> in patches 1-
>> 3. I cant see how that will be prevented.

I was talking about re-use of davinci_common_clk_init in 
drivers/clk/davinci/davinci-clock.c.
This is meant to be re-used across all of the DaVinci devices.

>> 
>> > spear3xx_clock.c has initialization code for each of the platforms and
>> > so is the case with imx23.c.
>> 
>> By each of the platforms, you mean they all cater to a family of devices? 
>> This depends on
>> how close together the family of devices are.
>> Otherwise, there would be a file per soc. DM644x also represents a family 
>> for that matter.
>> 
>> > By using platform_data approach, we are able to define clks for each of 
>> > the SoC and
>> then use davinci_common_clk_init() to do initialize the clk drivers based on 
>> platform
>> data.
>> 
>> You need to define and register the clocks present on each SoC either which 
>> way. I don't
>> see why just the platform_data approach allows this.
>> And looking closely, you have defined platform data, but don't actually have 
>> a platform
>> device, making things more confusing.
>> 

Ok. There are multiple ways to implement this software. We had discussed this
internally and picked the platform_data approach. The clk drivers are written 
not
following the platform driver model. But I don't see why we can't use platform 
data
to configure this drivers. Down below, you have made two interesting points, 
one is
ARM code reduction. This patch already does this by moving the API that 
initializes
the clk drivers (davinci_common_clk_init()) out of ARM to drivers/clk/davinci. 
So
this + removal of existing clk driver under arm/mach-davinci/clock.[ch], we have
achieved this goal. The second point is the moving of SoC specific clk data out 
of SoC
code to drive. Are you 100% sure this is the right thing to do for these 
drivers. If so,
I can start working on this change right away. As I am working on this as a 
background
activity, I want to be double or triple sure before doing the rework of these 
patches :).
So please confirm.

>> > Later once we migrate to device tree, davinci_common_clk_init() will
>> > go way and also the clk structures defined in the SoC file. I have 
>> > prototyped this on
>> one of the device that I am working on. davinci_common_clk_init() will be 
>> replaced with a
>> of_davinci_clk_init() that will use device tree to get all of the platform 
>> data for the clk
>> providers and do the initialization based on that. See 
>> highbank_clocks_init() in clk-
>> highbank.c. I have used this model for device tree based clk initialization.
>> 
>> I don't think we should wait till DT migration to get rid of clock data from 
>> platform code.
>> For many of the older DaVinci platforms, DT migration is a big if and when. 
>> This approach
>> you gave above might work for newer DT-only platforms, but even if there is 
>> one board
>> that is not migrated to DT, the entire clock data will have to stay. I have 
>> very less hope
>> this will happen for DaVinci (at least in the near term). So, I would rather 
>> take the
>> opportunity of common clock tree migration to move clock data out of 
>> mach-davinci.
>> 
>> Also, just moving soc-specific clk data to drivers/clk/davinci/* does not 
>> impede a future
>> DT conversion, no?
>> 
>> > So it make sense to keep the design the way it is. Otherwise we will
>> > end up writing dm644x_clk_init(), dm355_clk_init(), etc for each of the 
>> > platforms and
>> these code will get thrown away once we migrate to device tree.
>> 
>> I still don't see why davinci/keystone cannot follow the same approach taken 
>> by multiple
>> other socs - spear, mxs and ux500. I am unconvinced that we have a 
>> significantly
>> different case.
>> 
>> >>> ". I feel the
>> >>> latter way is better and I also think it will simplify some of the
>> >>> look-up infrastructure you had to build. This will also help some real 
>> >>> code reduction
>> from arch/arm/mach-davinci/.
>> >>>
>> >
>> > The look-up infrastructure is pretty much re-use of the existing code base 
>> > in SoC
>> specific

RE: [RESET PATCH 2/2] Documentation: of-serial.txt - update for clocks phandle for clk

>> -Original Message-
>> From: Karicheri, Muralidharan
>> Sent: Monday, October 15, 2012 11:00 AM
>> To: a...@linux.intel.com; gre...@linuxfoundation.org; 
>> linux-ser...@vger.kernel.org;
>> linux-kernel@vger.kernel.org; linux-keyst...@list.ti.com - Linux developers 
>> for Keystone
>> family of devices (May contain non-TIers)
>> Cc: Chemparathy, Cyril; Karicheri, Muralidharan
>> Subject: [RESET PATCH 2/2] Documentation: of-serial.txt - update for clocks 
>> phandle for
>> clk
Sorry for the typo, RESET->RESEND. 
>> 
>> Signed-off-by: Murali Karicheri 
>> 
>> diff --git a/Documentation/devicetree/bindings/tty/serial/of-serial.txt
>> b/Documentation/devicetree/bindings/tty/serial/of-serial.txt
>> index 0847fde..423b7ff 100644
>> --- a/Documentation/devicetree/bindings/tty/serial/of-serial.txt
>> +++ b/Documentation/devicetree/bindings/tty/serial/of-serial.txt
>> @@ -14,7 +14,10 @@ Required properties:
>>  - "serial" if the port type is unknown.
>>  - reg : offset and length of the register set for the device.
>>  - interrupts : should contain uart interrupt.
>> -- clock-frequency : the input clock frequency for the UART.
>> +- clock-frequency : the input clock frequency for the UART
>> + or
>> +  clocks phandle to refer to the clk used as per Documentation/devicetree
>> +  /bindings/clock/clock-bindings.txt
>> 
>>  Optional properties:
>>  - current-speed : the current active speed of the UART.
>> --
>> 1.7.9.5

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

RE: [RESET PATCH 2/2] Documentation: of-serial.txt - update for clocks phandle for clk

 -Original Message-
 From: Karicheri, Muralidharan
 Sent: Monday, October 15, 2012 11:00 AM
 To: a...@linux.intel.com; gre...@linuxfoundation.org; 
 linux-ser...@vger.kernel.org;
 linux-kernel@vger.kernel.org; linux-keyst...@list.ti.com - Linux developers 
 for Keystone
 family of devices (May contain non-TIers)
 Cc: Chemparathy, Cyril; Karicheri, Muralidharan
 Subject: [RESET PATCH 2/2] Documentation: of-serial.txt - update for clocks 
 phandle for
 clk
Sorry for the typo, RESET-RESEND. 
 
 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 
 diff --git a/Documentation/devicetree/bindings/tty/serial/of-serial.txt
 b/Documentation/devicetree/bindings/tty/serial/of-serial.txt
 index 0847fde..423b7ff 100644
 --- a/Documentation/devicetree/bindings/tty/serial/of-serial.txt
 +++ b/Documentation/devicetree/bindings/tty/serial/of-serial.txt
 @@ -14,7 +14,10 @@ Required properties:
  - serial if the port type is unknown.
  - reg : offset and length of the register set for the device.
  - interrupts : should contain uart interrupt.
 -- clock-frequency : the input clock frequency for the UART.
 +- clock-frequency : the input clock frequency for the UART
 + or
 +  clocks phandle to refer to the clk used as per Documentation/devicetree
 +  /bindings/clock/clock-bindings.txt
 
  Optional properties:
  - current-speed : the current active speed of the UART.
 --
 1.7.9.5

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

RE: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use common clk drivers

--Cut

 Subject: Re: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to 
 use
 common clk drivers
 
  You have chosen to keep all clock related data in platform files
  while using the common clock framework to provide just the
  infrastructure. If you look at how mxs and spear have been migrated, 
  they have
 migrated the soc specific clock data to drivers/clk as well.
  See drivers/clk/spear/spear3xx_clock.c or
  drivers/clk/mxs/clk-imx23.c
 
  I have to disagree on this one. I had investigated these code already
  and came up with a way that we can re-use code across all of the
  davinci platforms as well as other architectures that re-uses the clk 
  hardware IPs.
 
 Which code you are talking about here? Even if you introduce clk-dm644x.c, 
 clk-
 keystone.c etc in drivers/clk/davinci/ you can reuse the code you introduce 
 in patches 1-
 3. I cant see how that will be prevented.

I was talking about re-use of davinci_common_clk_init in 
drivers/clk/davinci/davinci-clock.c.
This is meant to be re-used across all of the DaVinci devices.

 
  spear3xx_clock.c has initialization code for each of the platforms and
  so is the case with imx23.c.
 
 By each of the platforms, you mean they all cater to a family of devices? 
 This depends on
 how close together the family of devices are.
 Otherwise, there would be a file per soc. DM644x also represents a family 
 for that matter.
 
  By using platform_data approach, we are able to define clks for each of 
  the SoC and
 then use davinci_common_clk_init() to do initialize the clk drivers based on 
 platform
 data.
 
 You need to define and register the clocks present on each SoC either which 
 way. I don't
 see why just the platform_data approach allows this.
 And looking closely, you have defined platform data, but don't actually have 
 a platform
 device, making things more confusing.
 

Ok. There are multiple ways to implement this software. We had discussed this
internally and picked the platform_data approach. The clk drivers are written 
not
following the platform driver model. But I don't see why we can't use platform 
data
to configure this drivers. Down below, you have made two interesting points, 
one is
ARM code reduction. This patch already does this by moving the API that 
initializes
the clk drivers (davinci_common_clk_init()) out of ARM to drivers/clk/davinci. 
So
this + removal of existing clk driver under arm/mach-davinci/clock.[ch], we have
achieved this goal. The second point is the moving of SoC specific clk data out 
of SoC
code to drive. Are you 100% sure this is the right thing to do for these 
drivers. If so,
I can start working on this change right away. As I am working on this as a 
background
activity, I want to be double or triple sure before doing the rework of these 
patches :).
So please confirm.

  Later once we migrate to device tree, davinci_common_clk_init() will
  go way and also the clk structures defined in the SoC file. I have 
  prototyped this on
 one of the device that I am working on. davinci_common_clk_init() will be 
 replaced with a
 of_davinci_clk_init() that will use device tree to get all of the platform 
 data for the clk
 providers and do the initialization based on that. See 
 highbank_clocks_init() in clk-
 highbank.c. I have used this model for device tree based clk initialization.
 
 I don't think we should wait till DT migration to get rid of clock data from 
 platform code.
 For many of the older DaVinci platforms, DT migration is a big if and when. 
 This approach
 you gave above might work for newer DT-only platforms, but even if there is 
 one board
 that is not migrated to DT, the entire clock data will have to stay. I have 
 very less hope
 this will happen for DaVinci (at least in the near term). So, I would rather 
 take the
 opportunity of common clock tree migration to move clock data out of 
 mach-davinci.
 
 Also, just moving soc-specific clk data to drivers/clk/davinci/* does not 
 impede a future
 DT conversion, no?
 
  So it make sense to keep the design the way it is. Otherwise we will
  end up writing dm644x_clk_init(), dm355_clk_init(), etc for each of the 
  platforms and
 these code will get thrown away once we migrate to device tree.
 
 I still don't see why davinci/keystone cannot follow the same approach taken 
 by multiple
 other socs - spear, mxs and ux500. I am unconvinced that we have a 
 significantly
 different case.
 
  . I feel the
  latter way is better and I also think it will simplify some of the
  look-up infrastructure you had to build. This will also help some real 
  code reduction
 from arch/arm/mach-davinci/.
 
 
  The look-up infrastructure is pretty much re-use of the existing code base 
  in SoC
 specific file.
 
 Yes, but that's no reason to keep maintaining it.
 
  About code reduction, I can't say I agree, as we need to add 
  platform_specific clock
 initialization code if we follow spear3xx_clock.c model and end up probably 
 adding more

RE: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use common clk drivers

>> -Original Message-
>> From: Nori, Sekhar
>> Sent: Thursday, October 11, 2012 8:25 AM
>> To: Karicheri, Muralidharan
>> Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
>> shawn@linaro.org; rob.herr...@calxeda.com; linus.wall...@linaro.org;
>> viresh.li...@gmail.com; linux-kernel@vger.kernel.org; Hilman, Kevin;
>> li...@arm.linux.org.uk; davinci-linux-open-sou...@linux.davincidsp.com; 
>> linux-arm-
>> ker...@lists.infradead.org; linux-keyst...@list.ti.com - Linux developers 
>> for Keystone
>> family of devices (May contain non-TIers); linux-c6x-...@linux-c6x.org; 
>> Chemparathy,
>> Cyril
>> Subject: Re: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to 
>> use
>> common clk drivers
>> 
>> Murali,
>> 
>> On 9/26/2012 11:40 PM, Murali Karicheri wrote:
>> > The clock tree for dm644x is defined using the new structure davinci_clk.
>> > The SoC specific code re-uses clk-fixed-rate, clk-divider and clk-mux
>> > drivers in addition to the davinci specific clk drivers,
>> > clk-davinci-pll and clk-davinci-psc. Macros are defined to define the
>> > various clocks in the SoC.
>> >
>> > Signed-off-by: Murali Karicheri 
>> 
>> You have chosen to keep all clock related data in platform files while using 
>> the common
>> clock framework to provide just the infrastructure. If you look at how mxs 
>> and spear
>> have been migrated, they have migrated the soc specific clock data to 
>> drivers/clk as well.
>> See "drivers/clk/spear/spear3xx_clock.c" or "drivers/clk/mxs/clk-imx23.c 

I have to disagree on this one. I had investigated these code already and came 
up with a way that we can re-use code across all of the davinci platforms as 
well as other architectures that re-uses the clk hardware IPs. spear3xx_clock.c 
has initialization code for each of the platforms and so is the case with 
imx23.c. By using platform_data approach, we are able to define clks for each 
of the SoC and then use davinci_common_clk_init() to do initialize the clk 
drivers based on platform data. Later once we migrate to device tree, 
davinci_common_clk_init() will go way and also the clk structures defined in 
the SoC file. I have prototyped this on one of the device that I am working on. 
davinci_common_clk_init() will be replaced with a of_davinci_clk_init() that 
will use device tree to get all of the platform data for the clk providers and 
do the initialization based on that. See highbank_clocks_init() in 
clk-highbank.c. I have used this model for device
tree based clk initialization.

So it make sense to keep the design the way it is. Otherwise we will end up 
writing dm644x_clk_init(), dm355_clk_init(), etc for each of the platforms and 
these code will get thrown away once we migrate to
device tree. 

>>". I feel the
>> latter way is better and I also think it will simplify some of the look-up 
>> infrastructure you
>> had to build. This will also help some real code reduction from 
>> arch/arm/mach-davinci/.
>>

The look-up infrastructure is pretty much re-use of the existing code base in 
SoC specific file. About code reduction, I can't say I agree, as we need to add 
platform_specific clock initialization code if we follow spear3xx_clock.c model 
and end up probably adding more code. SoC specific file (for example dm644x.c) 
has only data structures and all of SoC will re-use davinci_common_clk_init() 
to do the initialization. So I am not sure how you conclude we will have code 
reduction?

- Murali

>> Thanks,
>> Sekhar
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

RE: [PATCH 01/13] clk: davinci - add Main PLL clock driver

>> -Original Message-
>> From: Nori, Sekhar
>> Sent: Thursday, October 11, 2012 6:35 AM
>> To: Nori, Sekhar
>> Cc: Karicheri, Muralidharan; Hilman, Kevin; davinci-linux-open-
>> sou...@linux.davincidsp.com; mturque...@linaro.org; 
>> linux-c6x-...@linux-c6x.org;
>> a...@arndb.de; linus.wall...@linaro.org; linux-kernel@vger.kernel.org;
>> rob.herr...@calxeda.com; linux-keyst...@list.ti.com - Linux developers for 
>> Keystone
>> family of devices (May contain non-TIers); viresh.li...@gmail.com;
>> li...@arm.linux.org.uk; a...@linux-foundation.org; shawn@linaro.org; 
>> linux-arm-
>> ker...@lists.infradead.org
>> Subject: Re: [PATCH 01/13] clk: davinci - add Main PLL clock driver
>> 
>> On 10/10/2012 5:32 PM, Sekhar Nori wrote:
>> > Hi Murali,
>> >
>> > On 9/26/2012 11:37 PM, Murali Karicheri wrote:
>> >> This is the driver for the main PLL clock hardware found on DM SoCs.
>> >> This driver borrowed code from arch/arm/mach-davinci/clock.c and
>> >> implemented the driver as per common clock provider API. The main PLL
>> >> hardware typically has a multiplier, a pre-divider and a post-divider.
>> >> Some of the SoCs has the divider fixed meaning they can not be
>> >> configured through a register. HAS_PREDIV and HAS_POSTDIV flags are
>> >> used to tell the driver if a hardware has these dividers present or not.
>> >> Driver is configured through the structure clk_davinci_pll_data that
>> >> has the platform data for the driver.
>> >>
>> >> Signed-off-by: Murali Karicheri 
>> >
>> > Are you using git-format-patch to generate the patches? It should have
>> > added a diffstat here by default which is very useful in quickly
>> > understanding what the patch is touching.
>> >>
>> >> diff --git a/drivers/clk/davinci/clk-davinci-pll.c
>> >> b/drivers/clk/davinci/clk-davinci-pll.c
>> 
>> Looking at how common clock framework for mxs has been implemented, this 
>> file should
>> simply be clk-pll.c. That makes sense as you are creating a davinci folder 
>> anyway. Similar
>> change required for psc as well.
>> 

Alternately, do we need  a davinci folder? Can't we just add it to the clk/ 
directory? These IPs are re-used in c6x and keystone architectures. So it make 
sense to keep in the clk folder. If agree, I can make this change in v3.

>> Thanks,
>> Sekhar
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

RE: [PATCH 01/13] calk: davinci - add Main PLL clock driver

>> -Original Message-
>> From: Nori, Sekhar
>> Sent: Thursday, October 11, 2012 6:16 AM
>> To: Karicheri, Muralidharan
>> Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
>> shawn@linaro.org; rob.herr...@calxeda.com; linus.wall...@linaro.org;
>> viresh.li...@gmail.com; linux-kernel@vger.kernel.org; Hilman, Kevin;
>> li...@arm.linux.org.uk; davinci-linux-open-sou...@linux.davincidsp.com; 
>> linux-arm-
>> ker...@lists.infradead.org; linux-keyst...@list.ti.com - Linux developers 
>> for Keystone
>> family of devices (May contain non-TIers); linux-c6x-...@linux-c6x.org; 
>> Chemparathy,
>> Cyril
>> Subject: Re: [PATCH 01/13] calk: davinci - add Main PLL clock driver
>> 
>> On 10/10/2012 8:04 PM, Karicheri, Muralidharan wrote:
>> 
>> >>>> +struct clk *clk_register_davinci_pll(struct device *dev, const char 
>> >>>> *name,
>> >>>> +   const char *parent_name,
>> >>>> +   struct clk_davinci_pll_data *pll_data) {
>> >>>> +   struct clk_init_data init;
>> >>>> +   struct clk_davinci_pll *pll;
>> >>>> +   struct clk *clk;
>> >>>> +
>> >>>> +   if (!pll_data)
>> >>>> +   return ERR_PTR(-ENODEV);
>> >>>> +
>> >>>> +   pll = kzalloc(sizeof(*pll), GFP_KERNEL);
>> >>>> +   if (!pll)
>> >>>> +   return ERR_PTR(-ENOMEM);
>> >>>> +   init.name = name;
>> >>>> +   init.ops = _pll_ops;
>> >>>> +   init.flags = pll_data->flags;
>> >>>> +   init.parent_names = (parent_name ? _name : NULL);
>> >>>> +   init.num_parents = (parent_name ? 1 : 0);
>> >>>> +
>> >>>> +   pll->pll_data   = pll_data;
>> >>>> +   pll->hw.init = 
>> >>>> +
>> >>>> +   clk = clk_register(NULL, >hw);
>> >>>> +   if (IS_ERR(clk))
>> >>>> +   kfree(pll);
>> >>>> +
>> >>>> +   return clk;
>> >>>> +}
>> >>>
>> >>> I guess there is an an "unregister" required as well which will free
>> >>> the pll memory allocated above and unregister the clock? Not sure if
>> >>> you would ever unregister a PLL, but providing this will probably help 
>> >>> symmetry.
>> > Sekhar,
>> >
>> > clk_unregister() itself is a null statement in clk.c. Besides none of the 
>> > clk drivers
>> presently have implemented the unregister(). So I believe this is 
>> unnecessary.
>> 
>> I am ok with this.
>> 
>> > BTW, please review the v2 patch for the rest of the series. For the one 
>> > you have
>> already reviewed, it should be fine.
>> 
>> Okay. I see those now. BTW, this series also has a v2 in its 0/13. Are there 
>> any
>> differences between this and the other v2, or is that merely a resend?
>> 

You are right. I did a re-send to add v2 in all of the patch subject. We are 
fine.

>> Thanks,
>> Sekhar

RE: [PATCH 01/13] calk: davinci - add Main PLL clock driver

 -Original Message-
 From: Nori, Sekhar
 Sent: Thursday, October 11, 2012 6:16 AM
 To: Karicheri, Muralidharan
 Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
 shawn@linaro.org; rob.herr...@calxeda.com; linus.wall...@linaro.org;
 viresh.li...@gmail.com; linux-kernel@vger.kernel.org; Hilman, Kevin;
 li...@arm.linux.org.uk; davinci-linux-open-sou...@linux.davincidsp.com; 
 linux-arm-
 ker...@lists.infradead.org; linux-keyst...@list.ti.com - Linux developers 
 for Keystone
 family of devices (May contain non-TIers); linux-c6x-...@linux-c6x.org; 
 Chemparathy,
 Cyril
 Subject: Re: [PATCH 01/13] calk: davinci - add Main PLL clock driver

 On 10/10/2012 8:04 PM, Karicheri, Muralidharan wrote:

  +struct clk *clk_register_davinci_pll(struct device *dev, const char 
  *name,
  +   const char *parent_name,
  +   struct clk_davinci_pll_data *pll_data) {
  +   struct clk_init_data init;
  +   struct clk_davinci_pll *pll;
  +   struct clk *clk;
  +
  +   if (!pll_data)
  +   return ERR_PTR(-ENODEV);
  +
  +   pll = kzalloc(sizeof(*pll), GFP_KERNEL);
  +   if (!pll)
  +   return ERR_PTR(-ENOMEM);
  +   init.name = name;
  +   init.ops = clk_pll_ops;
  +   init.flags = pll_data-flags;
  +   init.parent_names = (parent_name ? parent_name : NULL);
  +   init.num_parents = (parent_name ? 1 : 0);
  +
  +   pll-pll_data   = pll_data;
  +   pll-hw.init = init;
  +
  +   clk = clk_register(NULL, pll-hw);
  +   if (IS_ERR(clk))
  +   kfree(pll);
  +
  +   return clk;
  +}

  I guess there is an an unregister required as well which will free
  the pll memory allocated above and unregister the clock? Not sure if
  you would ever unregister a PLL, but providing this will probably help 
  symmetry.
  Sekhar,

  clk_unregister() itself is a null statement in clk.c. Besides none of the 
  clk drivers
 presently have implemented the unregister(). So I believe this is 
 unnecessary.

 I am ok with this.

  BTW, please review the v2 patch for the rest of the series. For the one 
  you have
 already reviewed, it should be fine.

 Okay. I see those now. BTW, this series also has a v2 in its 0/13. Are there 
 any
 differences between this and the other v2, or is that merely a resend?

You are right. I did a re-send to add v2 in all of the patch subject. We are 
fine.

 Thanks,
 Sekhar

RE: [PATCH 01/13] clk: davinci - add Main PLL clock driver

-Original Message-
From: Nori, Sekhar
Sent: Thursday, October 11, 2012 6:35 AM
To: Nori, Sekhar
Cc: Karicheri, Muralidharan; Hilman, Kevin; davinci-linux-open-
sou...@linux.davincidsp.com; mturque...@linaro.org;
linux-c6x-...@linux-c6x.org;
a...@arndb.de; linus.wall...@linaro.org; linux-kernel@vger.kernel.org;
rob.herr...@calxeda.com; linux-keyst...@list.ti.com - Linux developers for
Keystone
family of devices (May contain non-TIers); viresh.li...@gmail.com;
li...@arm.linux.org.uk; a...@linux-foundation.org; shawn@linaro.org;
linux-arm-
ker...@lists.infradead.org
Subject: Re: [PATCH 01/13] clk: davinci - add Main PLL clock driver

On 10/10/2012 5:32 PM, Sekhar Nori wrote:
Hi Murali,

On 9/26/2012 11:37 PM, Murali Karicheri wrote:
This is the driver for the main PLL clock hardware found on DM SoCs.
This driver borrowed code from arch/arm/mach-davinci/clock.c and
implemented the driver as per common clock provider API. The main PLL
hardware typically has a multiplier, a pre-divider and a post-divider.
Some of the SoCs has the divider fixed meaning they can not be
configured through a register. HAS_PREDIV and HAS_POSTDIV flags are
used to tell the driver if a hardware has these dividers present or not.
Driver is configured through the structure clk_davinci_pll_data that
has the platform data for the driver.

Signed-off-by: Murali Karicheri m-kariche...@ti.com

Are you using git-format-patch to generate the patches? It should have
added a diffstat here by default which is very useful in quickly
understanding what the patch is touching.

diff --git a/drivers/clk/davinci/clk-davinci-pll.c
b/drivers/clk/davinci/clk-davinci-pll.c

Looking at how common clock framework for mxs has been implemented, this
file should
simply be clk-pll.c. That makes sense as you are creating a davinci folder
anyway. Similar
change required for psc as well.

Alternately, do we need a davinci folder? Can't we just add it to the clk/
directory? These IPs are re-used in c6x and keystone architectures. So it make
sense to keep in the clk folder. If agree, I can make this change in v3.

Thanks,
Sekhar
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

RE: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use common clk drivers

-Original Message-
From: Nori, Sekhar
Sent: Thursday, October 11, 2012 8:25 AM
To: Karicheri, Muralidharan
Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
shawn@linaro.org; rob.herr...@calxeda.com; linus.wall...@linaro.org;
viresh.li...@gmail.com; linux-kernel@vger.kernel.org; Hilman, Kevin;
li...@arm.linux.org.uk; davinci-linux-open-sou...@linux.davincidsp.com;
linux-arm-
ker...@lists.infradead.org; linux-keyst...@list.ti.com - Linux developers
for Keystone
family of devices (May contain non-TIers); linux-c6x-...@linux-c6x.org;
Chemparathy,
Cyril
Subject: Re: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to
use
common clk drivers

Murali,

On 9/26/2012 11:40 PM, Murali Karicheri wrote:
The clock tree for dm644x is defined using the new structure davinci_clk.
The SoC specific code re-uses clk-fixed-rate, clk-divider and clk-mux
drivers in addition to the davinci specific clk drivers,
clk-davinci-pll and clk-davinci-psc. Macros are defined to define the
various clocks in the SoC.

Signed-off-by: Murali Karicheri m-kariche...@ti.com

You have chosen to keep all clock related data in platform files while using
the common
clock framework to provide just the infrastructure. If you look at how mxs
and spear
have been migrated, they have migrated the soc specific clock data to
drivers/clk as well.
See drivers/clk/spear/spear3xx_clock.c or drivers/clk/mxs/clk-imx23.c

I have to disagree on this one. I had investigated these code already and came
up with a way that we can re-use code across all of the davinci platforms as
well as other architectures that re-uses the clk hardware IPs. spear3xx_clock.c
has initialization code for each of the platforms and so is the case with
imx23.c. By using platform_data approach, we are able to define clks for each
of the SoC and then use davinci_common_clk_init() to do initialize the clk
drivers based on platform data. Later once we migrate to device tree,
davinci_common_clk_init() will go way and also the clk structures defined in
the SoC file. I have prototyped this on one of the device that I am working on.
davinci_common_clk_init() will be replaced with a of_davinci_clk_init() that
will use device tree to get all of the platform data for the clk providers and
do the initialization based on that. See highbank_clocks_init() in
clk-highbank.c. I have used this model for device
tree based clk initialization.

So it make sense to keep the design the way it is. Otherwise we will end up
writing dm644x_clk_init(), dm355_clk_init(), etc for each of the platforms and
these code will get thrown away once we migrate to
device tree.

. I feel the
latter way is better and I also think it will simplify some of the look-up
infrastructure you
had to build. This will also help some real code reduction from
arch/arm/mach-davinci/.

The look-up infrastructure is pretty much re-use of the existing code base in
SoC specific file. About code reduction, I can't say I agree, as we need to add
platform_specific clock initialization code if we follow spear3xx_clock.c model
and end up probably adding more code. SoC specific file (for example dm644x.c)
has only data structures and all of SoC will re-use davinci_common_clk_init()
to do the initialization. So I am not sure how you conclude we will have code
reduction?

- Murali

RE: [PATCH 02/13] clk: davinci - add PSC clock driver

>> -Original Message-
>> From: Nori, Sekhar
>> Sent: Wednesday, October 10, 2012 8:36 AM
>> To: Karicheri, Muralidharan
>> Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
>> shawn@linaro.org; rob.herr...@calxeda.com; linus.wall...@linaro.org;
>> viresh.li...@gmail.com; linux-kernel@vger.kernel.org; Hilman, Kevin;
>> li...@arm.linux.org.uk; davinci-linux-open-sou...@linux.davincidsp.com; 
>> linux-arm-
>> ker...@lists.infradead.org; linux-keyst...@list.ti.com - Linux developers 
>> for Keystone
>> family of devices (May contain non-TIers); linux-c6x-...@linux-c6x.org; 
>> Chemparathy,
>> Cyril
>> Subject: Re: [PATCH 02/13] clk: davinci - add PSC clock driver
>> 
>> On 9/26/2012 11:37 PM, Murali Karicheri wrote:
>> > This is the driver for the Power Sleep Controller (PSC) hardware found
>> > on DM SoCs as well Keystone SoCs (c6x). This driver borrowed code from
>> > arch/arm/mach-davinci/psc.c and implemented the driver as per common
>> > clock provider API. The PSC module is responsible for
>> > enabling/disabling the Power Domain and Clock domain for different IPs
>> > present in the SoC. The driver is configured through the platform data
>> > structure struct clk_davinci_psc_data.
>> >
>> > Signed-off-by: Murali Karicheri 
>> >
>> > diff --git a/drivers/clk/davinci/clk-davinci-psc.c
>> > b/drivers/clk/davinci/clk-davinci-psc.c
>> > new file mode 100644
>> > index 000..b7aa332
>> > --- /dev/null
>> > +++ b/drivers/clk/davinci/clk-davinci-psc.c
>> > @@ -0,0 +1,197 @@
>> > +/*
>> > + * PSC clk driver for DaVinci devices
>> > + *
>> > + * Copyright (C) 2006-2012 Texas Instruments.
>> > + * Copyright (C) 2008-2009 Deep Root Systems, LLC
>> > + *
>> > + * 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 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> 
>> Sort these alphabetically.
>> 
>> > +
>> > +/* PSC register offsets */
>> > +#define EPCPR 0x070
>> > +#define PTCMD 0x120
>> > +#define PTSTAT0x128
>> > +#define PDSTAT0x200
>> > +#define PDCTL 0x300
>> > +#define MDSTAT0x800
>> > +#define MDCTL 0xA00
>> > +
>> > +/* PSC module states */
>> > +#define PSC_STATE_SWRSTDISABLE0
>> > +#define PSC_STATE_SYNCRST 1
>> > +#define PSC_STATE_DISABLE 2
>> > +#define PSC_STATE_ENABLE  3
>> > +
>> > +#define MDSTAT_STATE_MASK 0x3f
>> > +#define PDSTAT_STATE_MASK 0x1f
>> > +#define MDCTL_FORCE   BIT(31)
>> > +#define PDCTL_NEXTBIT(0)
>> > +#define PDCTL_EPCGOOD BIT(8)
>> > +
>> > +/* PSC flags */
>> > +#define PSC_SWRSTDISABLE  BIT(0) /* Disable state is SwRstDisable */
>> > +#define PSC_FORCE BIT(1) /* Force module state transtition */
>> > +#define PSC_HAS_EXT_POWER_CNTLBIT(2) /* PSC has external power control
>> > +  * available (for DM6446 SoC) */
>> 
>> Can you try and keep the comment above on a single line?
>> 
>> > +/**
>> > + * struct clk_psc - DaVinci PSC clock
>> > + * @hw: clk_hw for the psc
>> > + * @psc_data: PSC driver specific data
>> > + * @lock: Spinlock used by the driver  */ struct clk_psc {
>> > +  struct clk_hw hw;
>> > +  struct clk_davinci_psc_data *psc_data;
>> > +  spinlock_t *lock;
>> > +};
>> > +
>> > +#define to_clk_psc(_hw) container_of(_hw, struct clk_psc, hw)
>> > +
>> > +/* Enable or disable a PSC domain */
>> > +static void clk_psc_config(void __iomem *base, unsigned int domain,
>> > +  unsigned int id, bool enable, u32 flags) {
>> > +  u32 epcpr, ptcmd, ptstat, pdstat, pdctl, mdstat, mdctl;
>> > +  u32 next_state = PSC_STATE_ENABLE;
>> > +  void __iomem *psc_base = base;
>> > +
>> > +  if (!enable) {
>> > +  if (flags & PSC_SWRSTDISABLE)
>> > +

RE: [PATCH 01/13] calk: davinci - add Main PLL clock driver

>> -Original Message-
>> From: Nori, Sekhar
>> Sent: Wednesday, October 10, 2012 8:02 AM
>> To: Karicheri, Muralidharan
>> Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
>> shawn@linaro.org; rob.herr...@calxeda.com; linus.wall...@linaro.org;
>> viresh.li...@gmail.com; linux-kernel@vger.kernel.org; Hilman, Kevin;
>> li...@arm.linux.org.uk; davinci-linux-open-sou...@linux.davincidsp.com; 
>> linux-arm-
>> ker...@lists.infradead.org; linux-keyst...@list.ti.com - Linux developers 
>> for Keystone
>> family of devices (May contain non-TIers); linux-c6x-...@linux-c6x.org; 
>> Chemparathy,
>> Cyril
>> Subject: Re: [PATCH 01/13] clk: davinci - add Main PLL clock driver
>> 
>> Hi Murali,
>> 
>> On 9/26/2012 11:37 PM, Murali Karicheri wrote:
>> > This is the driver for the main PLL clock hardware found on DM SoCs.
>> > This driver borrowed code from arch/arm/mach-davinci/clock.c and
>> > implemented the driver as per common clock provider API. The main PLL
>> > hardware typically has a multiplier, a pre-divider and a post-divider.
>> > Some of the SoCs has the divider fixed meaning they can not be
>> > configured through a register. HAS_PREDIV and HAS_POSTDIV flags are
>> > used to tell the driver if a hardware has these dividers present or not.
>> > Driver is configured through the structure clk_davinci_pll_data that
>> > has the platform data for the driver.
>> >
>> > Signed-off-by: Murali Karicheri 
>> 
>> Are you using git-format-patch to generate the patches? It should have added 
>> a diffstat
>> here by default which is very useful in quickly understanding what the patch 
>> is touching.
>> >
>> > diff --git a/drivers/clk/davinci/clk-davinci-pll.c
>> > b/drivers/clk/davinci/clk-davinci-pll.c
>> > new file mode 100644
>> > index 000..13e1690
>> > --- /dev/null
>> > +++ b/drivers/clk/davinci/clk-davinci-pll.c
>> > @@ -0,0 +1,128 @@
>> > +/*
>> > + * PLL clk driver DaVinci devices
>> > + *
>> > + * Copyright (C) 2006-2012 Texas Instruments.
>> > + * Copyright (C) 2008-2009 Deep Root Systems, LLC
>> > + *
>> > + * 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.
>> > + * TODO - Add set_parent_rate()
>> > + */
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> 
>> It will be nice to keep these sorted in alphabetical order. You got it 
>> almost right, except
>> the last one. Keeping it sorted keeps out duplicates.
>> 
>> > +
>> > +#include 
>> 
>> Hmm, why is this needed? mach/ includes in driver files make it tough to use 
>> this on
>> other architectures/machines. You have plan to use this on driver on 
>> keystone and c6x as
>> well, right? It will also break multi-platform ARM build.
>> 
>> > +
>> > +#define PLLM  0x110
>> > +#define PLLM_PLLM_MASK  0xff
>> > +#define PREDIV  0x114
>> > +#define POSTDIV 0x128
>> > +#define PLLDIV_EN   BIT(15)
>> 
>> Can you use tabs for indentation?
>> 
>> > +
>> > +/**
>> > + * struct clk_davinci_pll - DaVinci Main pll clock
>> 
>> no capitalization on 'M' needed, I think.
>> 
>> > + * @hw: clk_hw for the pll
>> > + * @pll_data: PLL driver specific data  */ struct clk_davinci_pll {
>> > +  struct clk_hw hw;
>> > +  struct clk_davinci_pll_data *pll_data; };
>> > +
>> > +#define to_clk_pll(_hw) container_of(_hw, struct clk_davinci_pll, hw)
>> > +
>> > +static unsigned long clk_pllclk_recalc(struct clk_hw *hw,
>> > +  unsigned long parent_rate)
>> > +{
>> > +  struct clk_davinci_pll *pll = to_clk_pll(hw);
>> > +  struct clk_davinci_pll_data *pll_data = pll->pll_data;
>> > +  u32 mult = 1, prediv = 1, postdiv = 1;
>> 
>> No need to initialize mult here since you are doing it right away below.
>> 
>> > +  unsigned long rate = parent_rate;
>> > +
>> > +  /* If there is a device specific recalc defined invoke it. Otherwise
>

RE: [PATCH 02/13] clk: davinci - add PSC clock driver

>> -Original Message-
>> From: Nori, Sekhar
>> Sent: Wednesday, October 10, 2012 8:46 AM
>> To: Nori, Sekhar
>> Cc: Karicheri, Muralidharan; Hilman, Kevin; davinci-linux-open-
>> sou...@linux.davincidsp.com; mturque...@linaro.org; 
>> linux-c6x-...@linux-c6x.org;
>> a...@arndb.de; linus.wall...@linaro.org; linux-kernel@vger.kernel.org;
>> rob.herr...@calxeda.com; linux-keyst...@list.ti.com - Linux developers for 
>> Keystone
>> family of devices (May contain non-TIers); viresh.li...@gmail.com;
>> li...@arm.linux.org.uk; a...@linux-foundation.org; shawn@linaro.org; 
>> linux-arm-
>> ker...@lists.infradead.org
>> Subject: Re: [PATCH 02/13] clk: davinci - add PSC clock driver
>> 
>> On 10/10/2012 6:05 PM, Sekhar Nori wrote:
>> 
>> >> +struct clk *clk_register_davinci_psc(struct device *dev, const char 
>> >> *name,
>> >> + const char *parent_name,
>> >> + struct clk_davinci_psc_data *psc_data,
>> >> + spinlock_t *lock)
>> >
>> > Why do you need the lock to be provided from outside of this file? You
>> > can initialize a lock for serializing writes to PSC registers within
>> > this file, no?
>> 
>> Looking again, it seems like the common clock framework defines an 
>> "enable_lock" in
>> drivers/clk/clk.c to serialize the clock enable/disable calls. Unless I am 
>> missing something,
>> this lock seems unnecessary.
>> 

I think you are right. For enable() api, enable_lock is sufficient and I will 
remove this.

>> Thanks,
>> Sekhar

RE: [PATCH 02/13] clk: davinci - add PSC clock driver

 -Original Message-
 From: Nori, Sekhar
 Sent: Wednesday, October 10, 2012 8:46 AM
 To: Nori, Sekhar
 Cc: Karicheri, Muralidharan; Hilman, Kevin; davinci-linux-open-
 sou...@linux.davincidsp.com; mturque...@linaro.org; 
 linux-c6x-...@linux-c6x.org;
 a...@arndb.de; linus.wall...@linaro.org; linux-kernel@vger.kernel.org;
 rob.herr...@calxeda.com; linux-keyst...@list.ti.com - Linux developers for 
 Keystone
 family of devices (May contain non-TIers); viresh.li...@gmail.com;
 li...@arm.linux.org.uk; a...@linux-foundation.org; shawn@linaro.org; 
 linux-arm-
 ker...@lists.infradead.org
 Subject: Re: [PATCH 02/13] clk: davinci - add PSC clock driver

 On 10/10/2012 6:05 PM, Sekhar Nori wrote:

  +struct clk *clk_register_davinci_psc(struct device *dev, const char 
  *name,
  + const char *parent_name,
  + struct clk_davinci_psc_data *psc_data,
  + spinlock_t *lock)

  Why do you need the lock to be provided from outside of this file? You
  can initialize a lock for serializing writes to PSC registers within
  this file, no?

 Looking again, it seems like the common clock framework defines an 
 enable_lock in
 drivers/clk/clk.c to serialize the clock enable/disable calls. Unless I am 
 missing something,
 this lock seems unnecessary.

I think you are right. For enable() api, enable_lock is sufficient and I will 
remove this.

 Thanks,
 Sekhar

RE: [PATCH 01/13] calk: davinci - add Main PLL clock driver

 -Original Message-
 From: Nori, Sekhar
 Sent: Wednesday, October 10, 2012 8:02 AM
 To: Karicheri, Muralidharan
 Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
 shawn@linaro.org; rob.herr...@calxeda.com; linus.wall...@linaro.org;
 viresh.li...@gmail.com; linux-kernel@vger.kernel.org; Hilman, Kevin;
 li...@arm.linux.org.uk; davinci-linux-open-sou...@linux.davincidsp.com; 
 linux-arm-
 ker...@lists.infradead.org; linux-keyst...@list.ti.com - Linux developers 
 for Keystone
 family of devices (May contain non-TIers); linux-c6x-...@linux-c6x.org; 
 Chemparathy,
 Cyril
 Subject: Re: [PATCH 01/13] clk: davinci - add Main PLL clock driver

 Hi Murali,

 On 9/26/2012 11:37 PM, Murali Karicheri wrote:
  This is the driver for the main PLL clock hardware found on DM SoCs.
  This driver borrowed code from arch/arm/mach-davinci/clock.c and
  implemented the driver as per common clock provider API. The main PLL
  hardware typically has a multiplier, a pre-divider and a post-divider.
  Some of the SoCs has the divider fixed meaning they can not be
  configured through a register. HAS_PREDIV and HAS_POSTDIV flags are
  used to tell the driver if a hardware has these dividers present or not.
  Driver is configured through the structure clk_davinci_pll_data that
  has the platform data for the driver.

  Signed-off-by: Murali Karicheri m-kariche...@ti.com

 Are you using git-format-patch to generate the patches? It should have added 
 a diffstat
 here by default which is very useful in quickly understanding what the patch 
 is touching.

  diff --git a/drivers/clk/davinci/clk-davinci-pll.c
  b/drivers/clk/davinci/clk-davinci-pll.c
  new file mode 100644
  index 000..13e1690
  --- /dev/null
  +++ b/drivers/clk/davinci/clk-davinci-pll.c
  @@ -0,0 +1,128 @@
  +/*
  + * PLL clk driver DaVinci devices
  + *
  + * Copyright (C) 2006-2012 Texas Instruments.
  + * Copyright (C) 2008-2009 Deep Root Systems, LLC
  + *
  + * 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.
  + * TODO - Add set_parent_rate()
  + */
  +#include linux/clk.h
  +#include linux/clk-provider.h
  +#include linux/delay.h
  +#include linux/err.h
  +#include linux/io.h
  +#include linux/slab.h
  +#include linux/platform_data/clk-davinci-pll.h

 It will be nice to keep these sorted in alphabetical order. You got it 
 almost right, except
 the last one. Keeping it sorted keeps out duplicates.

  +
  +#include mach/cputype.h

 Hmm, why is this needed? mach/ includes in driver files make it tough to use 
 this on
 other architectures/machines. You have plan to use this on driver on 
 keystone and c6x as
 well, right? It will also break multi-platform ARM build.

  +
  +#define PLLM  0x110
  +#define PLLM_PLLM_MASK  0xff
  +#define PREDIV  0x114
  +#define POSTDIV 0x128
  +#define PLLDIV_EN   BIT(15)

 Can you use tabs for indentation?

  +
  +/**
  + * struct clk_davinci_pll - DaVinci Main pll clock

 no capitalization on 'M' needed, I think.

  + * @hw: clk_hw for the pll
  + * @pll_data: PLL driver specific data  */ struct clk_davinci_pll {
  +  struct clk_hw hw;
  +  struct clk_davinci_pll_data *pll_data; };
  +
  +#define to_clk_pll(_hw) container_of(_hw, struct clk_davinci_pll, hw)
  +
  +static unsigned long clk_pllclk_recalc(struct clk_hw *hw,
  +  unsigned long parent_rate)
  +{
  +  struct clk_davinci_pll *pll = to_clk_pll(hw);
  +  struct clk_davinci_pll_data *pll_data = pll-pll_data;
  +  u32 mult = 1, prediv = 1, postdiv = 1;

 No need to initialize mult here since you are doing it right away below.

  +  unsigned long rate = parent_rate;
  +
  +  /* If there is a device specific recalc defined invoke it. Otherwise
  +   * fallback to default one
  +   */

 This is not following the multi-line comment style defined in 
 Documentation/CodingStyle.

  +  mult = __raw_readl(pll_data-pllm);

 Do not use __raw_ variants since they are not safe on ARMv7. Use 
 readl/writel instead.

  +  if (pll_data-pllm_multiplier)
  +  mult =  pll_data-pllm_multiplier *
  +  (mult  pll_data-pllm_mask);
  +  else
  +  mult = (mult  pll_data-pllm_mask) + 1;
  +
  +  if (pll_data-flags  CLK_DAVINCI_PLL_HAS_PREDIV) {
  +  /* pre-divider is fixed, take prediv value from pll_data  */
  +  if (pll_data-fixed_prediv)
  +  prediv = pll_data-fixed_prediv;

 Since else is multi-line, if needs braces as well.

  +  else {
  +  prediv = __raw_readl(pll_data-prediv);
  +  if (prediv  PLLDIV_EN)
  +  prediv = (prediv  pll_data-prediv_mask) + 1;
  +  else
  +  prediv = 1

RE: [PATCH 02/13] clk: davinci - add PSC clock driver

 -Original Message-
 From: Nori, Sekhar
 Sent: Wednesday, October 10, 2012 8:36 AM
 To: Karicheri, Muralidharan
 Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
 shawn@linaro.org; rob.herr...@calxeda.com; linus.wall...@linaro.org;
 viresh.li...@gmail.com; linux-kernel@vger.kernel.org; Hilman, Kevin;
 li...@arm.linux.org.uk; davinci-linux-open-sou...@linux.davincidsp.com; 
 linux-arm-
 ker...@lists.infradead.org; linux-keyst...@list.ti.com - Linux developers 
 for Keystone
 family of devices (May contain non-TIers); linux-c6x-...@linux-c6x.org; 
 Chemparathy,
 Cyril
 Subject: Re: [PATCH 02/13] clk: davinci - add PSC clock driver
 
 On 9/26/2012 11:37 PM, Murali Karicheri wrote:
  This is the driver for the Power Sleep Controller (PSC) hardware found
  on DM SoCs as well Keystone SoCs (c6x). This driver borrowed code from
  arch/arm/mach-davinci/psc.c and implemented the driver as per common
  clock provider API. The PSC module is responsible for
  enabling/disabling the Power Domain and Clock domain for different IPs
  present in the SoC. The driver is configured through the platform data
  structure struct clk_davinci_psc_data.
 
  Signed-off-by: Murali Karicheri m-kariche...@ti.com
 
  diff --git a/drivers/clk/davinci/clk-davinci-psc.c
  b/drivers/clk/davinci/clk-davinci-psc.c
  new file mode 100644
  index 000..b7aa332
  --- /dev/null
  +++ b/drivers/clk/davinci/clk-davinci-psc.c
  @@ -0,0 +1,197 @@
  +/*
  + * PSC clk driver for DaVinci devices
  + *
  + * Copyright (C) 2006-2012 Texas Instruments.
  + * Copyright (C) 2008-2009 Deep Root Systems, LLC
  + *
  + * 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 linux/clk.h
  +#include linux/clk-provider.h
  +#include linux/delay.h
  +#include linux/err.h
  +#include linux/io.h
  +#include linux/slab.h
  +#include linux/platform_data/clk-davinci-psc.h
 
 Sort these alphabetically.
 
  +
  +/* PSC register offsets */
  +#define EPCPR 0x070
  +#define PTCMD 0x120
  +#define PTSTAT0x128
  +#define PDSTAT0x200
  +#define PDCTL 0x300
  +#define MDSTAT0x800
  +#define MDCTL 0xA00
  +
  +/* PSC module states */
  +#define PSC_STATE_SWRSTDISABLE0
  +#define PSC_STATE_SYNCRST 1
  +#define PSC_STATE_DISABLE 2
  +#define PSC_STATE_ENABLE  3
  +
  +#define MDSTAT_STATE_MASK 0x3f
  +#define PDSTAT_STATE_MASK 0x1f
  +#define MDCTL_FORCE   BIT(31)
  +#define PDCTL_NEXTBIT(0)
  +#define PDCTL_EPCGOOD BIT(8)
  +
  +/* PSC flags */
  +#define PSC_SWRSTDISABLE  BIT(0) /* Disable state is SwRstDisable */
  +#define PSC_FORCE BIT(1) /* Force module state transtition */
  +#define PSC_HAS_EXT_POWER_CNTLBIT(2) /* PSC has external power control
  +  * available (for DM6446 SoC) */
 
 Can you try and keep the comment above on a single line?
 
  +/**
  + * struct clk_psc - DaVinci PSC clock
  + * @hw: clk_hw for the psc
  + * @psc_data: PSC driver specific data
  + * @lock: Spinlock used by the driver  */ struct clk_psc {
  +  struct clk_hw hw;
  +  struct clk_davinci_psc_data *psc_data;
  +  spinlock_t *lock;
  +};
  +
  +#define to_clk_psc(_hw) container_of(_hw, struct clk_psc, hw)
  +
  +/* Enable or disable a PSC domain */
  +static void clk_psc_config(void __iomem *base, unsigned int domain,
  +  unsigned int id, bool enable, u32 flags) {
  +  u32 epcpr, ptcmd, ptstat, pdstat, pdctl, mdstat, mdctl;
  +  u32 next_state = PSC_STATE_ENABLE;
  +  void __iomem *psc_base = base;
  +
  +  if (!enable) {
  +  if (flags  PSC_SWRSTDISABLE)
  +  next_state = PSC_STATE_SWRSTDISABLE;
  +  else
  +  next_state = PSC_STATE_DISABLE;
  +  }
  +
  +  mdctl = __raw_readl(psc_base + MDCTL + 4 * id);
 
 Please convert all __raw_ variants to simple readl/writel() calls.
 
  +  mdctl = ~MDSTAT_STATE_MASK;
  +  mdctl |= next_state;
  +  if (flags  PSC_FORCE)
  +  mdctl |= MDCTL_FORCE;
  +  __raw_writel(mdctl, psc_base + MDCTL + 4 * id);
  +
  +  pdstat = __raw_readl(psc_base + PDSTAT + 4 * domain);
  +  if ((pdstat  PDSTAT_STATE_MASK) == 0) {
  +  pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
  +  pdctl |= PDCTL_NEXT;
  +  __raw_writel(pdctl, psc_base + PDCTL + 4 * domain);
  +
  +  ptcmd = 1  domain;
  +  __raw_writel(ptcmd, psc_base + PTCMD);
  +
  +  if (flags  PSC_HAS_EXT_POWER_CNTL) {
  +  do {
  +  epcpr = __raw_readl(psc_base + EPCPR);
  +  } while epcpr  domain)  1) == 0));
  +  }
  +
  +  pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
  +  pdctl

RE: [linux-keystone] Re: [PATCH 01/13] clk: davinci - add Main PLL clock driver

>> -Original Message-
>> From: Linus Walleij [mailto:linus.wall...@linaro.org]
>> Sent: Thursday, September 27, 2012 9:20 AM
>> To: Karicheri, Muralidharan
>> Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
>> shawn@linaro.org; rob.herr...@calxeda.com; viresh.li...@gmail.com; linux-
>> ker...@vger.kernel.org; Nori, Sekhar; Hilman, Kevin; li...@arm.linux.org.uk; 
>> davinci-
>> linux-open-sou...@linux.davincidsp.com; 
>> linux-arm-ker...@lists.infradead.org; linux-
>> keyst...@list.ti.com - Linux developers for Keystone family of devices (May 
>> contain non-
>> TIers); linux-c6x-...@linux-c6x.org; Chemparathy, Cyril
>> Subject: [linux-keystone] Re: [PATCH 01/13] clk: davinci - add Main PLL 
>> clock driver
>> 
>> On Wed, Sep 26, 2012 at 8:07 PM, Murali Karicheri  
>> wrote:
>> 
>> > +struct clk_davinci_pll_data {
>> > +   /* physical addresses set by platform code */
>> > +   u32 phy_pllm;
>> > +   /* if PLL has a prediv register this should be non zero */
>> > +   u32 phy_prediv;
>> > +   /* if PLL has a postdiv register this should be non zero */
>> > +   u32 phy_postdiv;
>> > +   /* mapped addresses. should be initialized by  */
>> > +   void __iomem *pllm;
>> > +   void __iomem *prediv;
>> > +   void __iomem *postdiv;
>> > +   u32 pllm_mask;
>> > +   u32 prediv_mask;
>> > +   u32 postdiv_mask;
>> > +   u32 num;
>> > +   /* framework flags */
>> > +   u32 flags;
>> > +   /* pll flags */
>> > +   u32 pll_flags;
>> > +   /* use this value for prediv */
>> > +   u32 fixed_prediv;
>> > +   /* multiply PLLM by this factor. By default most SOC set this to 
>> > zero
>> > +* that translates to a multiplier of 1 and incrementer of 1.
>> > +* To override default, set this factor
>> > +*/
>> > +   u32 pllm_multiplier;
>> > +};
>> > +
>> 
>> No, that's not what I meant.
>> 
>> I meant like this:
>> 
>> /**
>>  * struct clk_davinci_pll_data - struct holding the PLL data
>>  * phy_pllm: physical addresses set by platform code
>>  * phy_prediv: ...
>> (...)
>>  */
>> struct clk_davinci_pll_data {
>>   u32 phy_pllm;
>>   u32 phy_prediv;
>> (...)
>> };
>> 
Ok. Will do in the next revision.

Murali Karicheri
Software Design Engineer

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

[REMINDER: PATCH 1/1] spi:clk: preparation for switch to common clock framework

>> -Original Message-
>> From: Karicheri, Muralidharan
>> Sent: Monday, September 17, 2012 12:42 PM
>> To: spi-devel-gene...@lists.sourceforge.net; linux-kernel@vger.kernel.org; 
>> davinci-linux-
>> open-sou...@linux.davincidsp.com; grant.lik...@secretlab.ca; linux-arm-
>> ker...@lists.infradead.org
>> Cc: Chemparathy, Cyril; Karicheri, Muralidharan
>> Subject: [PATCH 1/1] spi:clk: preparation for switch to common clock 
>> framework
>> 
>> As a first step towards migrating davinci platforms to use common clock
>> framework, replace all instances of clk_enable() with clk_prepare_enable()
>> and clk_disable() with clk_disable_unprepare(). Until the platform is
>> switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
>> adds a might_sleep() call and would work without any issues.
>> 
>> This will make it easy later to switch to common clk based implementation
>> of clk driver from DaVinci specific driver.
>> 
>> Signed-off-by: Murali Karicheri 
>> Reviewed-by: Mike Turquette 
>> 
>> diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
>> index c1ec52d..3f54f9e 100644
>> --- a/drivers/spi/spi-davinci.c
>> +++ b/drivers/spi/spi-davinci.c
>> @@ -843,7 +843,7 @@ static int __devinit davinci_spi_probe(struct 
>> platform_device
>> *pdev)
>>  ret = -ENODEV;
>>  goto put_master;
>>  }
>> -clk_enable(dspi->clk);
>> +clk_prepare_enable(dspi->clk);
>> 
>>  master->bus_num = pdev->id;
>>  master->num_chipselect = pdata->num_chipselect;
>> @@ -927,7 +927,7 @@ free_dma:
>>  dma_release_channel(dspi->dma_rx);
>>  dma_release_channel(dspi->dma_tx);
>>  free_clk:
>> -clk_disable(dspi->clk);
>> +clk_disable_unprepare(dspi->clk);
>>  clk_put(dspi->clk);
>>  put_master:
>>  spi_master_put(master);
>> @@ -963,7 +963,7 @@ static int __devexit davinci_spi_remove(struct 
>> platform_device
>> *pdev)
>> 
>>  spi_bitbang_stop(>bitbang);
>> 
>> -clk_disable(dspi->clk);
>> +clk_disable_unprepare(dspi->clk);
>>  clk_put(dspi->clk);
>>  spi_master_put(master);
>>  free_irq(dspi->irq, dspi);
>> --
>> 1.7.9.5

Could you please review and apply this patch to linux-next?

Murali Karicheri
Software Design Engineer

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

[REMINDER: PATCH 1/1] mtd:nand:clk: preparation for switch to common clock framework

>> -Original Message-
>> From: Karicheri, Muralidharan
>> Sent: Monday, September 17, 2012 12:38 PM
>> To: dw...@infradead.org; artem.bityuts...@linux.intel.com; h...@denx.de;
>> miked...@newsguy.com; linux-...@lists.infradead.org; 
>> linux-kernel@vger.kernel.org;
>> davinci-linux-open-sou...@linux.davincidsp.com; 
>> linux-arm-ker...@lists.infradead.org
>> Cc: Karicheri, Muralidharan
>> Subject: [PATCH 1/1] mtd:nand:clk: preparation for switch to common clock 
>> framework
>> 
>> As a first step towards migrating davinci platforms to use common clock
>> framework, replace all instances of clk_enable() with clk_prepare_enable()
>> and clk_disable() with clk_disable_unprepare(). Until the platform is
>> switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
>> adds a might_sleep() call and would work without any issues.
>> 
>> This will make it easy later to switch to common clk based implementation
>> of clk driver from DaVinci specific driver.
>> 
>> Signed-off-by: Murali Karicheri 
>> Reviewed-by: Mike Turquette 
>> 
>> diff --git a/drivers/mtd/nand/davinci_nand.c 
>> b/drivers/mtd/nand/davinci_nand.c
>> index f386b3c..df1ab7d 100644
>> --- a/drivers/mtd/nand/davinci_nand.c
>> +++ b/drivers/mtd/nand/davinci_nand.c
>> @@ -724,7 +724,7 @@ static int __init nand_davinci_probe(struct 
>> platform_device
>> *pdev)
>>  goto err_clk;
>>  }
>> 
>> -ret = clk_enable(info->clk);
>> +ret = clk_prepare_enable(info->clk);
>>  if (ret < 0) {
>>  dev_dbg(>dev, "unable to enable AEMIF clock, err %d\n",
>>  ret);
>> @@ -835,7 +835,7 @@ syndrome_done:
>> 
>>  err_scan:
>>  err_timing:
>> -clk_disable(info->clk);
>> +clk_disable_unprepare(info->clk);
>> 
>>  err_clk_enable:
>>  clk_put(info->clk);
>> @@ -872,7 +872,7 @@ static int __exit nand_davinci_remove(struct 
>> platform_device
>> *pdev)
>> 
>>  nand_release(>mtd);
>> 
>> -clk_disable(info->clk);
>> +clk_disable_unprepare(info->clk);
>>  clk_put(info->clk);
>> 
>>  kfree(info);
>> --
>> 1.7.9.5

Could you please review and apply this patch to mtd subsystem tree for 
linux-next?

Murali Karicheri
Software Design Engineer


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

[REMINDER: PATCH 1/1] mtd:nand:clk: preparation for switch to common clock framework

 -Original Message-
 From: Karicheri, Muralidharan
 Sent: Monday, September 17, 2012 12:38 PM
 To: dw...@infradead.org; artem.bityuts...@linux.intel.com; h...@denx.de;
 miked...@newsguy.com; linux-...@lists.infradead.org; 
 linux-kernel@vger.kernel.org;
 davinci-linux-open-sou...@linux.davincidsp.com; 
 linux-arm-ker...@lists.infradead.org
 Cc: Karicheri, Muralidharan
 Subject: [PATCH 1/1] mtd:nand:clk: preparation for switch to common clock 
 framework
 
 As a first step towards migrating davinci platforms to use common clock
 framework, replace all instances of clk_enable() with clk_prepare_enable()
 and clk_disable() with clk_disable_unprepare(). Until the platform is
 switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
 adds a might_sleep() call and would work without any issues.
 
 This will make it easy later to switch to common clk based implementation
 of clk driver from DaVinci specific driver.
 
 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 Reviewed-by: Mike Turquette mturque...@linaro.org
 
 diff --git a/drivers/mtd/nand/davinci_nand.c 
 b/drivers/mtd/nand/davinci_nand.c
 index f386b3c..df1ab7d 100644
 --- a/drivers/mtd/nand/davinci_nand.c
 +++ b/drivers/mtd/nand/davinci_nand.c
 @@ -724,7 +724,7 @@ static int __init nand_davinci_probe(struct 
 platform_device
 *pdev)
  goto err_clk;
  }
 
 -ret = clk_enable(info-clk);
 +ret = clk_prepare_enable(info-clk);
  if (ret  0) {
  dev_dbg(pdev-dev, unable to enable AEMIF clock, err %d\n,
  ret);
 @@ -835,7 +835,7 @@ syndrome_done:
 
  err_scan:
  err_timing:
 -clk_disable(info-clk);
 +clk_disable_unprepare(info-clk);
 
  err_clk_enable:
  clk_put(info-clk);
 @@ -872,7 +872,7 @@ static int __exit nand_davinci_remove(struct 
 platform_device
 *pdev)
 
  nand_release(info-mtd);
 
 -clk_disable(info-clk);
 +clk_disable_unprepare(info-clk);
  clk_put(info-clk);
 
  kfree(info);
 --
 1.7.9.5

Could you please review and apply this patch to mtd subsystem tree for 
linux-next?

Murali Karicheri
Software Design Engineer


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

[REMINDER: PATCH 1/1] spi:clk: preparation for switch to common clock framework

 -Original Message-
 From: Karicheri, Muralidharan
 Sent: Monday, September 17, 2012 12:42 PM
 To: spi-devel-gene...@lists.sourceforge.net; linux-kernel@vger.kernel.org; 
 davinci-linux-
 open-sou...@linux.davincidsp.com; grant.lik...@secretlab.ca; linux-arm-
 ker...@lists.infradead.org
 Cc: Chemparathy, Cyril; Karicheri, Muralidharan
 Subject: [PATCH 1/1] spi:clk: preparation for switch to common clock 
 framework
 
 As a first step towards migrating davinci platforms to use common clock
 framework, replace all instances of clk_enable() with clk_prepare_enable()
 and clk_disable() with clk_disable_unprepare(). Until the platform is
 switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
 adds a might_sleep() call and would work without any issues.
 
 This will make it easy later to switch to common clk based implementation
 of clk driver from DaVinci specific driver.
 
 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 Reviewed-by: Mike Turquette mturque...@linaro.org
 
 diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
 index c1ec52d..3f54f9e 100644
 --- a/drivers/spi/spi-davinci.c
 +++ b/drivers/spi/spi-davinci.c
 @@ -843,7 +843,7 @@ static int __devinit davinci_spi_probe(struct 
 platform_device
 *pdev)
  ret = -ENODEV;
  goto put_master;
  }
 -clk_enable(dspi-clk);
 +clk_prepare_enable(dspi-clk);
 
  master-bus_num = pdev-id;
  master-num_chipselect = pdata-num_chipselect;
 @@ -927,7 +927,7 @@ free_dma:
  dma_release_channel(dspi-dma_rx);
  dma_release_channel(dspi-dma_tx);
  free_clk:
 -clk_disable(dspi-clk);
 +clk_disable_unprepare(dspi-clk);
  clk_put(dspi-clk);
  put_master:
  spi_master_put(master);
 @@ -963,7 +963,7 @@ static int __devexit davinci_spi_remove(struct 
 platform_device
 *pdev)
 
  spi_bitbang_stop(dspi-bitbang);
 
 -clk_disable(dspi-clk);
 +clk_disable_unprepare(dspi-clk);
  clk_put(dspi-clk);
  spi_master_put(master);
  free_irq(dspi-irq, dspi);
 --
 1.7.9.5

Could you please review and apply this patch to linux-next?

Murali Karicheri
Software Design Engineer

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

RE: [linux-keystone] Re: [PATCH 01/13] clk: davinci - add Main PLL clock driver

 -Original Message-
 From: Linus Walleij [mailto:linus.wall...@linaro.org]
 Sent: Thursday, September 27, 2012 9:20 AM
 To: Karicheri, Muralidharan
 Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
 shawn@linaro.org; rob.herr...@calxeda.com; viresh.li...@gmail.com; linux-
 ker...@vger.kernel.org; Nori, Sekhar; Hilman, Kevin; li...@arm.linux.org.uk; 
 davinci-
 linux-open-sou...@linux.davincidsp.com; 
 linux-arm-ker...@lists.infradead.org; linux-
 keyst...@list.ti.com - Linux developers for Keystone family of devices (May 
 contain non-
 TIers); linux-c6x-...@linux-c6x.org; Chemparathy, Cyril
 Subject: [linux-keystone] Re: [PATCH 01/13] clk: davinci - add Main PLL 
 clock driver
 
 On Wed, Sep 26, 2012 at 8:07 PM, Murali Karicheri m-kariche...@ti.com 
 wrote:
 
  +struct clk_davinci_pll_data {
  +   /* physical addresses set by platform code */
  +   u32 phy_pllm;
  +   /* if PLL has a prediv register this should be non zero */
  +   u32 phy_prediv;
  +   /* if PLL has a postdiv register this should be non zero */
  +   u32 phy_postdiv;
  +   /* mapped addresses. should be initialized by  */
  +   void __iomem *pllm;
  +   void __iomem *prediv;
  +   void __iomem *postdiv;
  +   u32 pllm_mask;
  +   u32 prediv_mask;
  +   u32 postdiv_mask;
  +   u32 num;
  +   /* framework flags */
  +   u32 flags;
  +   /* pll flags */
  +   u32 pll_flags;
  +   /* use this value for prediv */
  +   u32 fixed_prediv;
  +   /* multiply PLLM by this factor. By default most SOC set this to 
  zero
  +* that translates to a multiplier of 1 and incrementer of 1.
  +* To override default, set this factor
  +*/
  +   u32 pllm_multiplier;
  +};
  +
 
 No, that's not what I meant.
 
 I meant like this:
 
 /**
  * struct clk_davinci_pll_data - struct holding the PLL data
  * phy_pllm: physical addresses set by platform code
  * phy_prediv: ...
 (...)
  */
 struct clk_davinci_pll_data {
   u32 phy_pllm;
   u32 phy_prediv;
 (...)
 };
 
Ok. Will do in the next revision.

Murali Karicheri
Software Design Engineer

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

RE: [linux-keystone] Re: [PATCH v1 01/12] clk: davinci - add Main PLL clock driver

2012-09-26 Thread Karicheri, Muralidharan

>> -Original Message-
>> From: Linus Walleij [mailto:linus.wall...@linaro.org]
>> Sent: Wednesday, September 26, 2012 7:11 AM
>> To: Karicheri, Muralidharan
>> Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
>> shawn@linaro.org; rob.herr...@calxeda.com; viresh.li...@gmail.com; linux-
>> ker...@vger.kernel.org; Nori, Sekhar; Hilman, Kevin; li...@arm.linux.org.uk; 
>> davinci-
>> linux-open-sou...@linux.davincidsp.com; 
>> linux-arm-ker...@lists.infradead.org; linux-
>> keyst...@list.ti.com - Linux developers for Keystone family of devices (May 
>> contain non-
>> TIers); linux-c6x-...@linux-c6x.org; Chemparathy, Cyril
>> Subject: [linux-keystone] Re: [PATCH v1 01/12] clk: davinci - add Main PLL 
>> clock driver
>> 
>> On Tue, Sep 25, 2012 at 12:20 AM, Murali Karicheri  
>> wrote:
>> 
>> > +struct clk_davinci_pll_data {
>> > +   /* physical addresses set by platform code */
>> > +   u32 phy_pllm;
>> > +   /* if PLL has a prediv register this should be non zero */
>> > +   u32 phy_prediv;
>> > +   /* if PLL has a postdiv register this should be non zero */
>> > +   u32 phy_postdiv;
>> > +   /* mapped addresses. should be initialized by  */
>> > +   void __iomem *pllm;
>> > +   void __iomem *prediv;
>> > +   void __iomem *postdiv;
>> > +   u32 pllm_mask;
>> > +   u32 prediv_mask;
>> > +   u32 postdiv_mask;
>> > +   u32 num;
>> > +   /* framework flags */
>> > +   u32 flags;
>> > +   /* pll flags */
>> > +   u32 pll_flags;
>> > +   u32 fixed_prediv;   /* use this value for prediv */
>> > +   u32 pllm_multiplier;/* multiply PLLM by this factor. By default
>> > +* most SOC set this to zero that 
>> > translates
>> > +* to a multiplier of 1 and incrementer of 
>> > 1.
>> > +* To override default, set this factor */
>> > +};
>> 
>> OMG this commenting style hurt my eyes ;-)
>> 
>> Please use good old kerneldoc above the struct instead.
>> 
>> Yours,
>> Linus Walleij

Sure! I will fix these in my next revision.

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

RE: [linux-keystone] Re: [PATCH v1 01/12] clk: davinci - add Main PLL clock driver

2012-09-26 Thread Karicheri, Muralidharan

 -Original Message-
 From: Linus Walleij [mailto:linus.wall...@linaro.org]
 Sent: Wednesday, September 26, 2012 7:11 AM
 To: Karicheri, Muralidharan
 Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
 shawn@linaro.org; rob.herr...@calxeda.com; viresh.li...@gmail.com; linux-
 ker...@vger.kernel.org; Nori, Sekhar; Hilman, Kevin; li...@arm.linux.org.uk; 
 davinci-
 linux-open-sou...@linux.davincidsp.com; 
 linux-arm-ker...@lists.infradead.org; linux-
 keyst...@list.ti.com - Linux developers for Keystone family of devices (May 
 contain non-
 TIers); linux-c6x-...@linux-c6x.org; Chemparathy, Cyril
 Subject: [linux-keystone] Re: [PATCH v1 01/12] clk: davinci - add Main PLL 
 clock driver
 
 On Tue, Sep 25, 2012 at 12:20 AM, Murali Karicheri m-kariche...@ti.com 
 wrote:
 
  +struct clk_davinci_pll_data {
  +   /* physical addresses set by platform code */
  +   u32 phy_pllm;
  +   /* if PLL has a prediv register this should be non zero */
  +   u32 phy_prediv;
  +   /* if PLL has a postdiv register this should be non zero */
  +   u32 phy_postdiv;
  +   /* mapped addresses. should be initialized by  */
  +   void __iomem *pllm;
  +   void __iomem *prediv;
  +   void __iomem *postdiv;
  +   u32 pllm_mask;
  +   u32 prediv_mask;
  +   u32 postdiv_mask;
  +   u32 num;
  +   /* framework flags */
  +   u32 flags;
  +   /* pll flags */
  +   u32 pll_flags;
  +   u32 fixed_prediv;   /* use this value for prediv */
  +   u32 pllm_multiplier;/* multiply PLLM by this factor. By default
  +* most SOC set this to zero that 
  translates
  +* to a multiplier of 1 and incrementer of 
  1.
  +* To override default, set this factor */
  +};
 
 OMG this commenting style hurt my eyes ;-)
 
 Please use good old kerneldoc above the struct instead.
 
 Yours,
 Linus Walleij

Sure! I will fix these in my next revision.

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

RE: [GIT PULL REQUEST] watchdog - v3.6-rc5 Fixes

2012-09-24 Thread Karicheri, Muralidharan

>> -Original Message-
>> From: linux-watchdog-ow...@vger.kernel.org [mailto:linux-watchdog-
>> ow...@vger.kernel.org] On Behalf Of Wim Van Sebroeck
>> Sent: Thursday, September 20, 2012 4:14 AM
>> To: Linus Torvalds
>> Cc: Andrew Morton; LKML; Linux Watchdog Mailing List; Wei Yongjun; Toshi Kani
>> Subject: [GIT PULL REQUEST] watchdog - v3.6-rc5 Fixes
>> 
>> Hi Linus,
>> 
>> Please pull from 'master' branch of
>>  git://www.linux-watchdog.org/linux-watchdog.git
>> 
>> It will fix a kdump issue in hpwdt and a possible NULL dereference.
>> 
>> This will update the following files:
>> 
>>  hpwdt.c |3 +++
>>  watchdog_core.c |3 ++-
>>  2 files changed, 5 insertions(+), 1 deletion(-)
>> 
>> with these Changes:
>> 
>> commit b232a70a1735c004f9ee6fdf363def527b9234b6
>> Author: Wei Yongjun 
>> Date:   Mon Sep 10 12:41:15 2012 +0800
>> 
>> watchdog: move the dereference below the NULL test
>> 
>> The dereference should be moved below the NULL test.
>> 
>> spatch with a semantic match is used to found this.
>> (http://coccinelle.lip6.fr/)
>> 
>> Signed-off-by: Wei Yongjun 
>> Signed-off-by: Wim Van Sebroeck 
>> 
>> commit 308b135e4fcc00c80c07e0e04e7afa8edf78583c
>> Author: Toshi Kani 
>> Date:   Mon Aug 27 12:52:24 2012 -0600
>> 
>> hpwdt: Fix kdump issue in hpwdt
>> 
>> kdump can be interrupted by watchdog timer when the timer is left
>> activated on the crash kernel. Changed the hpwdt driver to disable
>> watchdog timer at boot-time. This assures that watchdog timer is
>> disabled until /dev/watchdog is opened, and prevents watchdog timer
>> to be left running on the crash kernel.
>> 
>> Signed-off-by: Toshi Kani 
>> Tested-by: Lisa Mitchell 
>> Signed-off-by: Thomas Mingarelli 
>> Signed-off-by: Wim Van Sebroeck 
>> Cc: stable 
>> 
>> For completeness, I added the overal diff below.
>> 
>> Greetings,
>> Wim.
>> 
>> 
>> 
>> diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
>> index 1eff743..ae60406 100644
>> --- a/drivers/watchdog/hpwdt.c
>> +++ b/drivers/watchdog/hpwdt.c
>> @@ -814,6 +814,9 @@ static int __devinit hpwdt_init_one(struct pci_dev *dev,
>>  hpwdt_timer_reg = pci_mem_addr + 0x70;
>>  hpwdt_timer_con = pci_mem_addr + 0x72;
>> 
>> +/* Make sure that timer is disabled until /dev/watchdog is opened */
>> +hpwdt_stop();
>> +
>>  /* Make sure that we have a valid soft_margin */
>>  if (hpwdt_change_timer(soft_margin))
>>  hpwdt_change_timer(DEFAULT_MARGIN);
>> diff --git a/drivers/watchdog/watchdog_core.c 
>> b/drivers/watchdog/watchdog_core.c
>> index 6aa46a9..3796434 100644
>> --- a/drivers/watchdog/watchdog_core.c
>> +++ b/drivers/watchdog/watchdog_core.c
>> @@ -128,11 +128,12 @@ EXPORT_SYMBOL_GPL(watchdog_register_device);
>>  void watchdog_unregister_device(struct watchdog_device *wdd)
>>  {
>>  int ret;
>> -int devno = wdd->cdev.dev;
>> +int devno;
>> 
>>  if (wdd == NULL)
>>  return;
>> 
>> +devno = wdd->cdev.dev;
>>  ret = watchdog_dev_unregister(wdd);
>>  if (ret)
>>  pr_err("error unregistering /dev/watchdog (err=%d)\n", ret);
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Wim,

Could you take the watchdog davinci patch as well?  
http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg23630.html

I have tried 2 times to send the patch to the linux-watchdog list, but the 
server is rejecting it for some reason. The second time I tried registering my 
email id to the list and re-sent, but no success.

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

RE: [GIT PULL REQUEST] watchdog - v3.6-rc5 Fixes

2012-09-24 Thread Karicheri, Muralidharan

 -Original Message-
 From: linux-watchdog-ow...@vger.kernel.org [mailto:linux-watchdog-
 ow...@vger.kernel.org] On Behalf Of Wim Van Sebroeck
 Sent: Thursday, September 20, 2012 4:14 AM
 To: Linus Torvalds
 Cc: Andrew Morton; LKML; Linux Watchdog Mailing List; Wei Yongjun; Toshi Kani
 Subject: [GIT PULL REQUEST] watchdog - v3.6-rc5 Fixes
 
 Hi Linus,
 
 Please pull from 'master' branch of
  git://www.linux-watchdog.org/linux-watchdog.git
 
 It will fix a kdump issue in hpwdt and a possible NULL dereference.
 
 This will update the following files:
 
  hpwdt.c |3 +++
  watchdog_core.c |3 ++-
  2 files changed, 5 insertions(+), 1 deletion(-)
 
 with these Changes:
 
 commit b232a70a1735c004f9ee6fdf363def527b9234b6
 Author: Wei Yongjun yongjun_...@trendmicro.com.cn
 Date:   Mon Sep 10 12:41:15 2012 +0800
 
 watchdog: move the dereference below the NULL test
 
 The dereference should be moved below the NULL test.
 
 spatch with a semantic match is used to found this.
 (http://coccinelle.lip6.fr/)
 
 Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
 Signed-off-by: Wim Van Sebroeck w...@iguana.be
 
 commit 308b135e4fcc00c80c07e0e04e7afa8edf78583c
 Author: Toshi Kani toshi.k...@hp.com
 Date:   Mon Aug 27 12:52:24 2012 -0600
 
 hpwdt: Fix kdump issue in hpwdt
 
 kdump can be interrupted by watchdog timer when the timer is left
 activated on the crash kernel. Changed the hpwdt driver to disable
 watchdog timer at boot-time. This assures that watchdog timer is
 disabled until /dev/watchdog is opened, and prevents watchdog timer
 to be left running on the crash kernel.
 
 Signed-off-by: Toshi Kani toshi.k...@hp.com
 Tested-by: Lisa Mitchell lisa.mitch...@hp.com
 Signed-off-by: Thomas Mingarelli thomas.mingare...@hp.com
 Signed-off-by: Wim Van Sebroeck w...@iguana.be
 Cc: stable sta...@vger.kernel.org
 
 For completeness, I added the overal diff below.
 
 Greetings,
 Wim.
 
 
 
 diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
 index 1eff743..ae60406 100644
 --- a/drivers/watchdog/hpwdt.c
 +++ b/drivers/watchdog/hpwdt.c
 @@ -814,6 +814,9 @@ static int __devinit hpwdt_init_one(struct pci_dev *dev,
  hpwdt_timer_reg = pci_mem_addr + 0x70;
  hpwdt_timer_con = pci_mem_addr + 0x72;
 
 +/* Make sure that timer is disabled until /dev/watchdog is opened */
 +hpwdt_stop();
 +
  /* Make sure that we have a valid soft_margin */
  if (hpwdt_change_timer(soft_margin))
  hpwdt_change_timer(DEFAULT_MARGIN);
 diff --git a/drivers/watchdog/watchdog_core.c 
 b/drivers/watchdog/watchdog_core.c
 index 6aa46a9..3796434 100644
 --- a/drivers/watchdog/watchdog_core.c
 +++ b/drivers/watchdog/watchdog_core.c
 @@ -128,11 +128,12 @@ EXPORT_SYMBOL_GPL(watchdog_register_device);
  void watchdog_unregister_device(struct watchdog_device *wdd)
  {
  int ret;
 -int devno = wdd-cdev.dev;
 +int devno;
 
  if (wdd == NULL)
  return;
 
 +devno = wdd-cdev.dev;
  ret = watchdog_dev_unregister(wdd);
  if (ret)
  pr_err(error unregistering /dev/watchdog (err=%d)\n, ret);
 --
 To unsubscribe from this list: send the line unsubscribe linux-watchdog in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

Wim,

Could you take the watchdog davinci patch as well?  
http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg23630.html

I have tried 2 times to send the patch to the linux-watchdog list, but the 
server is rejecting it for some reason. The second time I tried registering my 
email id to the list and re-sent, but no success.

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

RE: [RFC - PATCH] base:pm: prepare driver for common clock framework

+ Len Brown
>> -Original Message-
>> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-ow...@vger.kernel.org] 
>> On
>> Behalf Of Karicheri, Muralidharan
>> Sent: Wednesday, September 19, 2012 10:09 AM
>> To: Rafael J. Wysocki
>> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Chemparathy, 
>> Cyril;
>> mturque...@linaro.org; Magnus Damm; Linux-sh list
>> Subject: RE: [RFC - PATCH] base:pm: prepare driver for common clock framework
>> 
>> >> -Original Message-
>> >> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
>> >> Sent: Tuesday, September 18, 2012 5:34 PM
>> >> To: Karicheri, Muralidharan
>> >> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Chemparathy, 
>> >> Cyril;
>> >> mturque...@linaro.org; Magnus Damm; Linux-sh list
>> >> Subject: Re: [RFC - PATCH] base:pm: prepare driver for common clock 
>> >> framework
>> >>
>> >> On Saturday, September 15, 2012, Murali Karicheri wrote:
>> >> > As part of my work to migrate davinci SoC code to
>> >> > use common clk framework, I encountered an issue with this driver
>> >> > which is calling clk_enable() and clk_disable() without prepare()/
>> >> > unprepare(). This change is needed to enable common clock migration
>> >> > for davinci SoCs.
>> >> >
>> >> > Signed-off-by: Murali Karicheri 
>> >>
>> >> There are other users of this code than davinci.  For example, sh
>> >> and ARM/shmobile both use it.  Have you verified that your changes will
>> >> work for them too?
>> >>
>> Rafael,
>> 
>> Technically do you agree with the changes or do I need to get it reviewed by 
>> someone in
>> particular? I have no way of verifying if this works for sh and 
>> ARM/shmobile. I have
>> copied this RFC patch to the list showed up by scripts/get_maintainer.pl 
>> list. Any idea
>> how I can get this patch reviewed by the sh and ARM/shmobile maintainers and 
>> get it
>> tested as well? This is required for DaVinci for sure unless there is an 
>> alternate way of
>> doing this. Well, then that is the idea of sending an RFC patch.
>> 
>> -Murali
>> 
>> >> Rafael
>> >>
>> >>
>> >> > diff --git a/drivers/base/power/clock_ops.c 
>> >> > b/drivers/base/power/clock_ops.c
>> >> > index eb78e96..9d8fde7 100644
>> >> > --- a/drivers/base/power/clock_ops.c
>> >> > +++ b/drivers/base/power/clock_ops.c
>> >> > @@ -99,7 +99,7 @@ static void __pm_clk_remove(struct pm_clock_entry *ce)
>> >> >
>> >> > if (ce->status < PCE_STATUS_ERROR) {
>> >> > if (ce->status == PCE_STATUS_ENABLED)
>> >> > -   clk_disable(ce->clk);
>> >> > +   clk_disable_unprepare(ce->clk);
>> >> >
>> >> > if (ce->status >= PCE_STATUS_ACQUIRED)
>> >> > clk_put(ce->clk);
>> >> > @@ -396,7 +396,7 @@ static void enable_clock(struct device *dev, const 
>> >> > char
>> >> *con_id)
>> >> >
>> >> > clk = clk_get(dev, con_id);
>> >> > if (!IS_ERR(clk)) {
>> >> > -   clk_enable(clk);
>> >> > +   clk_prepare_enable(clk);
>> >> > clk_put(clk);
>> >> > dev_info(dev, "Runtime PM disabled, clock forced 
>> >> > on.\n");
>> >> > }
>> >> > @@ -413,7 +413,7 @@ static void disable_clock(struct device *dev, const 
>> >> > char
>> >> *con_id)
>> >> >
>> >> > clk = clk_get(dev, con_id);
>> >> > if (!IS_ERR(clk)) {
>> >> > -   clk_disable(clk);
>> >> > +   clk_disable_unprepare(clk);
>> >> > clk_put(clk);
>> >> > dev_info(dev, "Runtime PM disabled, clock forced 
>> >> > off.\n");
>> >> > }
>> >> >
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RFC - PATCH] base:pm: prepare driver for common clock framework

>> -Original Message-
>> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
>> Sent: Tuesday, September 18, 2012 5:34 PM
>> To: Karicheri, Muralidharan
>> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Chemparathy, 
>> Cyril;
>> mturque...@linaro.org; Magnus Damm; Linux-sh list
>> Subject: Re: [RFC - PATCH] base:pm: prepare driver for common clock framework
>> 
>> On Saturday, September 15, 2012, Murali Karicheri wrote:
>> > As part of my work to migrate davinci SoC code to
>> > use common clk framework, I encountered an issue with this driver
>> > which is calling clk_enable() and clk_disable() without prepare()/
>> > unprepare(). This change is needed to enable common clock migration
>> > for davinci SoCs.
>> >
>> > Signed-off-by: Murali Karicheri 
>> 
>> There are other users of this code than davinci.  For example, sh
>> and ARM/shmobile both use it.  Have you verified that your changes will
>> work for them too?
>> 
Rafael,

Technically do you agree with the changes or do I need to get it reviewed by 
someone in particular? I have no way of verifying if this works for sh and 
ARM/shmobile. I have copied this RFC patch to the list showed up by 
scripts/get_maintainer.pl list. Any idea how I can get this patch reviewed by 
the sh and ARM/shmobile maintainers and get it tested as well? This is required 
for DaVinci for sure unless there is an alternate way of doing this. Well, then 
that is the idea of sending an RFC patch.

-Murali

>> Rafael
>> 
>> 
>> > diff --git a/drivers/base/power/clock_ops.c 
>> > b/drivers/base/power/clock_ops.c
>> > index eb78e96..9d8fde7 100644
>> > --- a/drivers/base/power/clock_ops.c
>> > +++ b/drivers/base/power/clock_ops.c
>> > @@ -99,7 +99,7 @@ static void __pm_clk_remove(struct pm_clock_entry *ce)
>> >
>> >if (ce->status < PCE_STATUS_ERROR) {
>> >if (ce->status == PCE_STATUS_ENABLED)
>> > -  clk_disable(ce->clk);
>> > +  clk_disable_unprepare(ce->clk);
>> >
>> >if (ce->status >= PCE_STATUS_ACQUIRED)
>> >clk_put(ce->clk);
>> > @@ -396,7 +396,7 @@ static void enable_clock(struct device *dev, const char
>> *con_id)
>> >
>> >clk = clk_get(dev, con_id);
>> >if (!IS_ERR(clk)) {
>> > -  clk_enable(clk);
>> > +  clk_prepare_enable(clk);
>> >clk_put(clk);
>> >dev_info(dev, "Runtime PM disabled, clock forced on.\n");
>> >}
>> > @@ -413,7 +413,7 @@ static void disable_clock(struct device *dev, const 
>> > char
>> *con_id)
>> >
>> >clk = clk_get(dev, con_id);
>> >if (!IS_ERR(clk)) {
>> > -  clk_disable(clk);
>> > +  clk_disable_unprepare(clk);
>> >clk_put(clk);
>> >dev_info(dev, "Runtime PM disabled, clock forced off.\n");
>> >}
>> >

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

RE: [RFC - PATCH] base:pm: prepare driver for common clock framework

 -Original Message-
 From: Rafael J. Wysocki [mailto:r...@sisk.pl]
 Sent: Tuesday, September 18, 2012 5:34 PM
 To: Karicheri, Muralidharan
 Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Chemparathy, 
 Cyril;
 mturque...@linaro.org; Magnus Damm; Linux-sh list
 Subject: Re: [RFC - PATCH] base:pm: prepare driver for common clock framework

 On Saturday, September 15, 2012, Murali Karicheri wrote:
  As part of my work to migrate davinci SoC code to
  use common clk framework, I encountered an issue with this driver
  which is calling clk_enable() and clk_disable() without prepare()/
  unprepare(). This change is needed to enable common clock migration
  for davinci SoCs.

  Signed-off-by: Murali Karicheri m-kariche...@ti.com

 There are other users of this code than davinci.  For example, sh
 and ARM/shmobile both use it.  Have you verified that your changes will
 work for them too?

Rafael,

Technically do you agree with the changes or do I need to get it reviewed by 
someone in particular? I have no way of verifying if this works for sh and 
ARM/shmobile. I have copied this RFC patch to the list showed up by 
scripts/get_maintainer.pl list. Any idea how I can get this patch reviewed by 
the sh and ARM/shmobile maintainers and get it tested as well? This is required 
for DaVinci for sure unless there is an alternate way of doing this. Well, then 
that is the idea of sending an RFC patch.

-Murali

 Rafael

  diff --git a/drivers/base/power/clock_ops.c 
  b/drivers/base/power/clock_ops.c
  index eb78e96..9d8fde7 100644
  --- a/drivers/base/power/clock_ops.c
  +++ b/drivers/base/power/clock_ops.c
  @@ -99,7 +99,7 @@ static void __pm_clk_remove(struct pm_clock_entry *ce)

 if (ce-status  PCE_STATUS_ERROR) {
 if (ce-status == PCE_STATUS_ENABLED)
  -  clk_disable(ce-clk);
  +  clk_disable_unprepare(ce-clk);

 if (ce-status = PCE_STATUS_ACQUIRED)
 clk_put(ce-clk);
  @@ -396,7 +396,7 @@ static void enable_clock(struct device *dev, const char
 *con_id)

 clk = clk_get(dev, con_id);
 if (!IS_ERR(clk)) {
  -  clk_enable(clk);
  +  clk_prepare_enable(clk);
 clk_put(clk);
 dev_info(dev, Runtime PM disabled, clock forced on.\n);
 }
  @@ -413,7 +413,7 @@ static void disable_clock(struct device *dev, const 
  char
 *con_id)

 clk = clk_get(dev, con_id);
 if (!IS_ERR(clk)) {
  -  clk_disable(clk);
  +  clk_disable_unprepare(clk);
 clk_put(clk);
 dev_info(dev, Runtime PM disabled, clock forced off.\n);
 }

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

RE: [RFC - PATCH] base:pm: prepare driver for common clock framework

+ Len Brown
 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-ow...@vger.kernel.org] 
 On
 Behalf Of Karicheri, Muralidharan
 Sent: Wednesday, September 19, 2012 10:09 AM
 To: Rafael J. Wysocki
 Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Chemparathy, 
 Cyril;
 mturque...@linaro.org; Magnus Damm; Linux-sh list
 Subject: RE: [RFC - PATCH] base:pm: prepare driver for common clock framework
 
  -Original Message-
  From: Rafael J. Wysocki [mailto:r...@sisk.pl]
  Sent: Tuesday, September 18, 2012 5:34 PM
  To: Karicheri, Muralidharan
  Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Chemparathy, 
  Cyril;
  mturque...@linaro.org; Magnus Damm; Linux-sh list
  Subject: Re: [RFC - PATCH] base:pm: prepare driver for common clock 
  framework
 
  On Saturday, September 15, 2012, Murali Karicheri wrote:
   As part of my work to migrate davinci SoC code to
   use common clk framework, I encountered an issue with this driver
   which is calling clk_enable() and clk_disable() without prepare()/
   unprepare(). This change is needed to enable common clock migration
   for davinci SoCs.
  
   Signed-off-by: Murali Karicheri m-kariche...@ti.com
 
  There are other users of this code than davinci.  For example, sh
  and ARM/shmobile both use it.  Have you verified that your changes will
  work for them too?
 
 Rafael,
 
 Technically do you agree with the changes or do I need to get it reviewed by 
 someone in
 particular? I have no way of verifying if this works for sh and 
 ARM/shmobile. I have
 copied this RFC patch to the list showed up by scripts/get_maintainer.pl 
 list. Any idea
 how I can get this patch reviewed by the sh and ARM/shmobile maintainers and 
 get it
 tested as well? This is required for DaVinci for sure unless there is an 
 alternate way of
 doing this. Well, then that is the idea of sending an RFC patch.
 
 -Murali
 
  Rafael
 
 
   diff --git a/drivers/base/power/clock_ops.c 
   b/drivers/base/power/clock_ops.c
   index eb78e96..9d8fde7 100644
   --- a/drivers/base/power/clock_ops.c
   +++ b/drivers/base/power/clock_ops.c
   @@ -99,7 +99,7 @@ static void __pm_clk_remove(struct pm_clock_entry *ce)
  
   if (ce-status  PCE_STATUS_ERROR) {
   if (ce-status == PCE_STATUS_ENABLED)
   -   clk_disable(ce-clk);
   +   clk_disable_unprepare(ce-clk);
  
   if (ce-status = PCE_STATUS_ACQUIRED)
   clk_put(ce-clk);
   @@ -396,7 +396,7 @@ static void enable_clock(struct device *dev, const 
   char
  *con_id)
  
   clk = clk_get(dev, con_id);
   if (!IS_ERR(clk)) {
   -   clk_enable(clk);
   +   clk_prepare_enable(clk);
   clk_put(clk);
   dev_info(dev, Runtime PM disabled, clock forced 
   on.\n);
   }
   @@ -413,7 +413,7 @@ static void disable_clock(struct device *dev, const 
   char
  *con_id)
  
   clk = clk_get(dev, con_id);
   if (!IS_ERR(clk)) {
   -   clk_disable(clk);
   +   clk_disable_unprepare(clk);
   clk_put(clk);
   dev_info(dev, Runtime PM disabled, clock forced 
   off.\n);
   }
  
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-pm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Summary of changes for v3.7

2012-09-18 Thread Karicheri, Muralidharan

Rafael,

Could you review the attached patch which is sent to the list and merge it if 
it looks ok? If not, please provide your comment.

Murali Karicheri
Software Design Engineer


>> -Original Message-
>> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-ow...@vger.kernel.org] 
>> On
>> Behalf Of Rafael J. Wysocki
>> Sent: Tuesday, September 18, 2012 4:19 PM
>> To: LKML
>> Cc: ACPI Devel Mailing List; Linux PM list; Linux-sh list; Len Brown
>> Subject: PM: Summary of changes for v3.7
>> 
>> Hi all,
>> 
>> All of the changes I'd like to include into the first PM pull request during
>> the v3.7 merge window, except maybe for a couple of patches I know of, but
>> haven't decided what to do with them yet, is on the 'linux-next' branch of 
>> the
>> linux-pm.git tree now.
>> 
>> The summary of those changes is appended.  If anyone finds any of them
>> objectionable, please let me know ASAP.  Also please let me know if there are
>> any power management patches I've seen already that you'd like me to take for
>> v3.7 (if I haven't seen them yet, they clearly are not v3.7 material, unless
>> they are urgent fixes).
>> 
>> Thanks,
>> Rafael
>> 
>> ---
>> 
>>  Documentation/ABI/testing/sysfs-devices-system-cpu |  11 +
>>  Documentation/cpu-freq/boost.txt   |  93 +
>>  Documentation/cpuidle/sysfs.txt|  10 +-
>>  .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |  55 +++
>>  Documentation/devicetree/bindings/power/opp.txt|  25 ++
>>  arch/arm/kernel/smp.c  |  54 +++
>>  arch/arm/mach-shmobile/Makefile|   2 +-
>>  arch/arm/mach-shmobile/board-ap4evb.c  |  21 +-
>>  arch/arm/mach-shmobile/board-armadillo800eva.c |   6 +-
>>  arch/arm/mach-shmobile/board-mackerel.c|  34 +-
>>  arch/arm/mach-shmobile/common.c|  24 --
>>  arch/arm/mach-shmobile/cpuidle.c   |  39 +-
>>  arch/arm/mach-shmobile/include/mach/common.h   |  14 +-
>>  arch/arm/mach-shmobile/include/mach/pm-rmobile.h   |  35 +-
>>  arch/arm/mach-shmobile/include/mach/r8a7740.h  |   6 +-
>>  arch/arm/mach-shmobile/include/mach/r8a7779.h  |  12 +-
>>  arch/arm/mach-shmobile/include/mach/sh7372.h   |  20 +-
>>  arch/arm/mach-shmobile/pm-r8a7740.c|  42 ++-
>>  arch/arm/mach-shmobile/pm-r8a7779.c|  71 ++--
>>  arch/arm/mach-shmobile/pm-rmobile.c|  33 +-
>>  arch/arm/mach-shmobile/pm-sh7372.c | 283 --
>>  arch/arm/mach-shmobile/setup-r8a7740.c |  27 +-
>>  arch/arm/mach-shmobile/setup-r8a7779.c |   5 +-
>>  arch/arm/mach-shmobile/setup-sh7372.c  |  69 ++--
>>  arch/x86/include/asm/msr-index.h   |   3 +
>>  drivers/acpi/processor_driver.c|   8 +-
>>  drivers/acpi/processor_idle.c  |  40 +-
>>  drivers/acpi/processor_perflib.c   |  30 ++
>>  drivers/base/platform.c|   2 +
>>  drivers/base/power/domain.c| 244 ++---
>>  drivers/base/power/main.c  |  35 +-
>>  drivers/base/power/opp.c   |  47 +++
>>  drivers/base/power/power.h |  36 +-
>>  drivers/base/power/wakeup.c|  46 ++-
>>  drivers/clocksource/sh_cmt.c   |  71 +++-
>>  drivers/clocksource/sh_mtu2.c  |  41 ++-
>>  drivers/clocksource/sh_tmu.c   | 112 +-
>>  drivers/cpufreq/Kconfig|  11 +
>>  drivers/cpufreq/Kconfig.x86|  18 +-
>>  drivers/cpufreq/Makefile   |   4 +-
>>  drivers/cpufreq/acpi-cpufreq.c | 272 +-
>>  drivers/cpufreq/cpufreq-cpu0.c | 269 ++
>>  drivers/cpufreq/cpufreq_conservative.c |   2 +
>>  drivers/cpufreq/cpufreq_ondemand.c |   1 +
>>  drivers/cpufreq/longhaul.h |  26 +-
>>  drivers/cpufreq/omap-cpufreq.c |  35 --
>>  drivers/cpufreq/powernow-k8.c  | 406 
>> ++---
>>  drivers/cpufreq/powernow-k8.h  |  32 --
>>  drivers/cpuidle/governors/ladder.c |   6 +-
>>  drivers/xen/xen-acpi-processor.c   |   1 -
>>  include/acpi/processor.h   |   9 +-
>>  include/linux/clockchips.h |   8 +
>>  include/linux/device.h |   7 +
>>  include/linux/opp.h|   8 +
>>  include/linux/pm.h |   2 +
>>  include/linux/pm_domain.h  |  92 -
>>  kernel/power/Kconfig   |   4 +
>>  kernel/power/poweroff.c|   2 +-
>>  kernel/power/process.c

RE: Summary of changes for v3.7

2012-09-18 Thread Karicheri, Muralidharan

Rafael,

Could you review the attached patch which is sent to the list and merge it if 
it looks ok? If not, please provide your comment.

Murali Karicheri
Software Design Engineer


 -Original Message-
 From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-ow...@vger.kernel.org] 
 On
 Behalf Of Rafael J. Wysocki
 Sent: Tuesday, September 18, 2012 4:19 PM
 To: LKML
 Cc: ACPI Devel Mailing List; Linux PM list; Linux-sh list; Len Brown
 Subject: PM: Summary of changes for v3.7
 
 Hi all,
 
 All of the changes I'd like to include into the first PM pull request during
 the v3.7 merge window, except maybe for a couple of patches I know of, but
 haven't decided what to do with them yet, is on the 'linux-next' branch of 
 the
 linux-pm.git tree now.
 
 The summary of those changes is appended.  If anyone finds any of them
 objectionable, please let me know ASAP.  Also please let me know if there are
 any power management patches I've seen already that you'd like me to take for
 v3.7 (if I haven't seen them yet, they clearly are not v3.7 material, unless
 they are urgent fixes).
 
 Thanks,
 Rafael
 
 ---
 
  Documentation/ABI/testing/sysfs-devices-system-cpu |  11 +
  Documentation/cpu-freq/boost.txt   |  93 +
  Documentation/cpuidle/sysfs.txt|  10 +-
  .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |  55 +++
  Documentation/devicetree/bindings/power/opp.txt|  25 ++
  arch/arm/kernel/smp.c  |  54 +++
  arch/arm/mach-shmobile/Makefile|   2 +-
  arch/arm/mach-shmobile/board-ap4evb.c  |  21 +-
  arch/arm/mach-shmobile/board-armadillo800eva.c |   6 +-
  arch/arm/mach-shmobile/board-mackerel.c|  34 +-
  arch/arm/mach-shmobile/common.c|  24 --
  arch/arm/mach-shmobile/cpuidle.c   |  39 +-
  arch/arm/mach-shmobile/include/mach/common.h   |  14 +-
  arch/arm/mach-shmobile/include/mach/pm-rmobile.h   |  35 +-
  arch/arm/mach-shmobile/include/mach/r8a7740.h  |   6 +-
  arch/arm/mach-shmobile/include/mach/r8a7779.h  |  12 +-
  arch/arm/mach-shmobile/include/mach/sh7372.h   |  20 +-
  arch/arm/mach-shmobile/pm-r8a7740.c|  42 ++-
  arch/arm/mach-shmobile/pm-r8a7779.c|  71 ++--
  arch/arm/mach-shmobile/pm-rmobile.c|  33 +-
  arch/arm/mach-shmobile/pm-sh7372.c | 283 --
  arch/arm/mach-shmobile/setup-r8a7740.c |  27 +-
  arch/arm/mach-shmobile/setup-r8a7779.c |   5 +-
  arch/arm/mach-shmobile/setup-sh7372.c  |  69 ++--
  arch/x86/include/asm/msr-index.h   |   3 +
  drivers/acpi/processor_driver.c|   8 +-
  drivers/acpi/processor_idle.c  |  40 +-
  drivers/acpi/processor_perflib.c   |  30 ++
  drivers/base/platform.c|   2 +
  drivers/base/power/domain.c| 244 ++---
  drivers/base/power/main.c  |  35 +-
  drivers/base/power/opp.c   |  47 +++
  drivers/base/power/power.h |  36 +-
  drivers/base/power/wakeup.c|  46 ++-
  drivers/clocksource/sh_cmt.c   |  71 +++-
  drivers/clocksource/sh_mtu2.c  |  41 ++-
  drivers/clocksource/sh_tmu.c   | 112 +-
  drivers/cpufreq/Kconfig|  11 +
  drivers/cpufreq/Kconfig.x86|  18 +-
  drivers/cpufreq/Makefile   |   4 +-
  drivers/cpufreq/acpi-cpufreq.c | 272 +-
  drivers/cpufreq/cpufreq-cpu0.c | 269 ++
  drivers/cpufreq/cpufreq_conservative.c |   2 +
  drivers/cpufreq/cpufreq_ondemand.c |   1 +
  drivers/cpufreq/longhaul.h |  26 +-
  drivers/cpufreq/omap-cpufreq.c |  35 --
  drivers/cpufreq/powernow-k8.c  | 406 
 ++---
  drivers/cpufreq/powernow-k8.h  |  32 --
  drivers/cpuidle/governors/ladder.c |   6 +-
  drivers/xen/xen-acpi-processor.c   |   1 -
  include/acpi/processor.h   |   9 +-
  include/linux/clockchips.h |   8 +
  include/linux/device.h |   7 +
  include/linux/opp.h|   8 +
  include/linux/pm.h |   2 +
  include/linux/pm_domain.h  |  92 -
  kernel/power/Kconfig   |   4 +
  kernel/power/poweroff.c|   2 +-
  kernel/power/process.c |   2 +-
  kernel/power/qos.c |   1 +
  kernel/time/clockevents.c  |  24 ++

RE: [PATCH] of: add of_find_child_by_name implementation

2012-09-16 Thread Karicheri, Muralidharan

>> -Original Message-
>> From: Karicheri, Muralidharan
>> Sent: Thursday, August 30, 2012 11:42 AM
>> To: grant.lik...@secretlab.ca; rob.herr...@calxeda.com; devicetree-
>> disc...@lists.ozlabs.org; linux-kernel@vger.kernel.org
>> Cc: Karicheri, Muralidharan; Chemparathy, Cyril
>> Subject: [PATCH] of: add of_find_child_by_name implementation
>> 
>> This patch adds a helper to find a child node by name.
>> 
>> Signed-off-by: Cyril Chemparathy 
>> Signed-off-by: Murali Karicheri 
>> ---
>>  drivers/of/base.c  |   20 
>>  include/linux/of.h |2 ++
>>  2 files changed, 22 insertions(+)
>> 
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index d4a1c9a..bbdd0d4 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -441,6 +441,26 @@ struct device_node *of_find_node_by_name(struct
>> device_node *from,
>>  EXPORT_SYMBOL(of_find_node_by_name);
>> 
>>  /**
>> + *  of_find_child_by_name - Find a child node by its "name" property
>> + *  @parent:The parent node to search from
>> + *  @name:  The name string to match against
>> + *
>> + *  Returns a node pointer with refcount incremented, use
>> + *  of_node_put() on it when done.
>> + */
>> +struct device_node *of_find_child_by_name(struct device_node *parent,
>> +  const char *name)
>> +{
>> +struct device_node *child;
>> +
>> +for_each_child_of_node(parent, child)
>> +if (child->name && of_node_cmp(child->name, name) == 0)
>> +break;
>> +return child;
>> +}
>> +EXPORT_SYMBOL(of_find_child_by_name);
>> +
>> +/**
>>   *  of_find_node_by_type - Find a node by its "device_type" property
>>   *  @from:  The node to start searching from, or NULL to start searching
>>   *  the entire device tree. The node you pass will not be
>> diff --git a/include/linux/of.h b/include/linux/of.h
>> index 1b11632..a4cc8e7 100644
>> --- a/include/linux/of.h
>> +++ b/include/linux/of.h
>> @@ -193,6 +193,8 @@ extern struct device_node *of_get_next_child(const struct
>> device_node *node,
>>  extern struct device_node *of_get_next_available_child(
>>  const struct device_node *node, struct device_node *prev);
>> 
>> +struct device_node *of_find_child_by_name(struct device_node *parent,
>> +  const char *name);
>>  #define for_each_child_of_node(parent, child) \
>>  for (child = of_get_next_child(parent, NULL); child != NULL; \
>>   child = of_get_next_child(parent, child))
>> --
>> 1.7.9.5

Can someone review this? If this is okay, can this be merged to the next branch 
please?

Murali

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

RE: [PATCH] of: add of_find_child_by_name implementation

2012-09-16 Thread Karicheri, Muralidharan

 -Original Message-
 From: Karicheri, Muralidharan
 Sent: Thursday, August 30, 2012 11:42 AM
 To: grant.lik...@secretlab.ca; rob.herr...@calxeda.com; devicetree-
 disc...@lists.ozlabs.org; linux-kernel@vger.kernel.org
 Cc: Karicheri, Muralidharan; Chemparathy, Cyril
 Subject: [PATCH] of: add of_find_child_by_name implementation
 
 This patch adds a helper to find a child node by name.
 
 Signed-off-by: Cyril Chemparathy cy...@ti.com
 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 ---
  drivers/of/base.c  |   20 
  include/linux/of.h |2 ++
  2 files changed, 22 insertions(+)
 
 diff --git a/drivers/of/base.c b/drivers/of/base.c
 index d4a1c9a..bbdd0d4 100644
 --- a/drivers/of/base.c
 +++ b/drivers/of/base.c
 @@ -441,6 +441,26 @@ struct device_node *of_find_node_by_name(struct
 device_node *from,
  EXPORT_SYMBOL(of_find_node_by_name);
 
  /**
 + *  of_find_child_by_name - Find a child node by its name property
 + *  @parent:The parent node to search from
 + *  @name:  The name string to match against
 + *
 + *  Returns a node pointer with refcount incremented, use
 + *  of_node_put() on it when done.
 + */
 +struct device_node *of_find_child_by_name(struct device_node *parent,
 +  const char *name)
 +{
 +struct device_node *child;
 +
 +for_each_child_of_node(parent, child)
 +if (child-name  of_node_cmp(child-name, name) == 0)
 +break;
 +return child;
 +}
 +EXPORT_SYMBOL(of_find_child_by_name);
 +
 +/**
   *  of_find_node_by_type - Find a node by its device_type property
   *  @from:  The node to start searching from, or NULL to start searching
   *  the entire device tree. The node you pass will not be
 diff --git a/include/linux/of.h b/include/linux/of.h
 index 1b11632..a4cc8e7 100644
 --- a/include/linux/of.h
 +++ b/include/linux/of.h
 @@ -193,6 +193,8 @@ extern struct device_node *of_get_next_child(const struct
 device_node *node,
  extern struct device_node *of_get_next_available_child(
  const struct device_node *node, struct device_node *prev);
 
 +struct device_node *of_find_child_by_name(struct device_node *parent,
 +  const char *name);
  #define for_each_child_of_node(parent, child) \
  for (child = of_get_next_child(parent, NULL); child != NULL; \
   child = of_get_next_child(parent, child))
 --
 1.7.9.5

Can someone review this? If this is okay, can this be merged to the next branch 
please?

Murali

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

RE: i2c:clk: preparation for switch to common clock framework

2012-09-13 Thread Karicheri, Muralidharan

>> -Original Message-
>> From: Wolfram Sang [mailto:w.s...@pengutronix.de]
>> Sent: Thursday, September 13, 2012 5:30 AM
>> To: Karicheri, Muralidharan
>> Cc: Nori, Sekhar; Hilman, Kevin; kh...@linux-fr.org; ben-li...@fluff.org; 
>> davinci-linux-
>> open-sou...@linux.davincidsp.com; linux-...@vger.kernel.org; linux-
>> ker...@vger.kernel.org
>> Subject: Re: i2c:clk: preparation for switch to common clock framework
>> 
>> On Thu, Aug 30, 2012 at 06:10:36PM -, m-kariche...@ti.com wrote:
>> > As a first step towards migrating davinci platforms to use common
>> > clock framework, replace all instances of clk_enable() with
>> > clk_prepare_enable() and clk_disable() with clk_disable_unprepare().
>> > Until the platform is switched to use the CONFIG_HAVE_CLK_PREPARE
>> > Kconfig variable, this just adds a might_sleep() call and would work 
>> > without any issues.
>> >
>> > This will make it easy later to switch to common clk based
>> > implementation of clk driver from DaVinci specific driver.
>> >
>> > Signed-off-by: Murali Karicheri 
>> 
>> Subject had "i2c:clk" where "i2c: davinci" would be more precise.
>> 
>> Fixed that and pushed to -next.
>> 
>> Thanks,
>> 
>>Wolfram

Wolfram,

Thanks for pushing this to -next. Greatly appreciated.

Murali
>> 
>> --
>> Pengutronix e.K.   | Wolfram Sang|
>> Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: i2c:clk: preparation for switch to common clock framework

2012-09-13 Thread Karicheri, Muralidharan

 -Original Message-
 From: Wolfram Sang [mailto:w.s...@pengutronix.de]
 Sent: Thursday, September 13, 2012 5:30 AM
 To: Karicheri, Muralidharan
 Cc: Nori, Sekhar; Hilman, Kevin; kh...@linux-fr.org; ben-li...@fluff.org; 
 davinci-linux-
 open-sou...@linux.davincidsp.com; linux-...@vger.kernel.org; linux-
 ker...@vger.kernel.org
 Subject: Re: i2c:clk: preparation for switch to common clock framework

 On Thu, Aug 30, 2012 at 06:10:36PM -, m-kariche...@ti.com wrote:
  As a first step towards migrating davinci platforms to use common
  clock framework, replace all instances of clk_enable() with
  clk_prepare_enable() and clk_disable() with clk_disable_unprepare().
  Until the platform is switched to use the CONFIG_HAVE_CLK_PREPARE
  Kconfig variable, this just adds a might_sleep() call and would work 
  without any issues.

  This will make it easy later to switch to common clk based
  implementation of clk driver from DaVinci specific driver.

  Signed-off-by: Murali Karicheri m-kariche...@ti.com

 Subject had i2c:clk where i2c: davinci would be more precise.

 Fixed that and pushed to -next.

 Thanks,

Wolfram

Wolfram,

Thanks for pushing this to -next. Greatly appreciated.

Murali

 --
 Pengutronix e.K.   | Wolfram Sang|
 Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] mtd:nand:clk: preparation for switch to common clock framework

2012-09-10 Thread Karicheri, Muralidharan

>> -Original Message-
>> From: Brian Norris [mailto:computersforpe...@gmail.com]
>> Sent: Friday, September 07, 2012 8:44 PM
>> To: Karicheri, Muralidharan
>> Cc: Mike Turquette; dw...@infradead.org; artem.bityuts...@linux.intel.com;
>> dbarysh...@gmail.com; linux-...@lists.infradead.org; 
>> linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH] mtd:nand:clk: preparation for switch to common clock 
>> framework
>> 
>> On Fri, Sep 7, 2012 at 2:56 PM, Karicheri, Muralidharan
>>  wrote:
>> > How do these patch get to upstream? Does this get merged through davinci 
>> > maintainer
>> or through individual subsystem maintainers?
>> 
>> I think this driver would be taken by David Woodhouse in his linux-mtd
>> repo. Usually Artem Bityutskiy gleans the mailing list of patches and
>> puts them in his l2-mtd-2.6 git repo to help David out. Give it some
>> time, and I'm sure they'll be taking it. We don't really have a
>> full-time maintainer!
>> 
>> Brian

Thanks Brian for your response. Understood. Will wait.

Murali Karicheri
Software Design Engineer

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

RE: [PATCH] mtd:nand:clk: preparation for switch to common clock framework

2012-09-10 Thread Karicheri, Muralidharan

 -Original Message-
 From: Brian Norris [mailto:computersforpe...@gmail.com]
 Sent: Friday, September 07, 2012 8:44 PM
 To: Karicheri, Muralidharan
 Cc: Mike Turquette; dw...@infradead.org; artem.bityuts...@linux.intel.com;
 dbarysh...@gmail.com; linux-...@lists.infradead.org; 
 linux-kernel@vger.kernel.org
 Subject: Re: [PATCH] mtd:nand:clk: preparation for switch to common clock 
 framework

 On Fri, Sep 7, 2012 at 2:56 PM, Karicheri, Muralidharan
 m-kariche...@ti.com wrote:
  How do these patch get to upstream? Does this get merged through davinci 
  maintainer
 or through individual subsystem maintainers?

 I think this driver would be taken by David Woodhouse in his linux-mtd
 repo. Usually Artem Bityutskiy gleans the mailing list of patches and
 puts them in his l2-mtd-2.6 git repo to help David out. Give it some
 time, and I'm sure they'll be taking it. We don't really have a
 full-time maintainer!

 Brian

Thanks Brian for your response. Understood. Will wait.

Murali Karicheri
Software Design Engineer

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

RE: [PATCH] mtd:nand:clk: preparation for switch to common clock framework

Mike,

How do these patch get to upstream? Does this get merged through davinci 
maintainer or through individual subsystem maintainers? 

Thanks.

Murali Karicheri
Software Design Engineer


>> -Original Message-
>> From: Mike Turquette [mailto:mturque...@linaro.org]
>> Sent: Friday, September 07, 2012 5:29 PM
>> To: Karicheri, Muralidharan; dw...@infradead.org; 
>> artem.bityuts...@linux.intel.com;
>> dbarysh...@gmail.com; computersforpe...@gmail.com; 
>> linux-...@lists.infradead.org;
>> linux-kernel@vger.kernel.org
>> Cc: Karicheri, Muralidharan
>> Subject: Re: [PATCH] mtd:nand:clk: preparation for switch to common clock 
>> framework
>> 
>> Quoting Murali Karicheri (2012-08-30 11:17:04)
>> > As a first step towards migrating davinci platforms to use common clock
>> > framework, replace all instances of clk_enable() with clk_prepare_enable()
>> > and clk_disable() with clk_disable_unprepare(). Until the platform is
>> > switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
>> > adds a might_sleep() call and would work without any issues.
>> >
>> > This will make it easy later to switch to common clk based implementation
>> > of clk driver from DaVinci specific driver.
>> >
>> > Signed-off-by: Murali Karicheri 
>> 
>> Acked-by: Mike Turquette 
>> 
>> > ---
>> >  drivers/mtd/nand/davinci_nand.c |6 +++---
>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/mtd/nand/davinci_nand.c 
>> > b/drivers/mtd/nand/davinci_nand.c
>> > index d94b03c..6b8cf27 100644
>> > --- a/drivers/mtd/nand/davinci_nand.c
>> > +++ b/drivers/mtd/nand/davinci_nand.c
>> > @@ -656,7 +656,7 @@ static int __init nand_davinci_probe(struct 
>> > platform_device
>> *pdev)
>> > goto err_clk;
>> > }
>> >
>> > -   ret = clk_enable(info->clk);
>> > +   ret = clk_prepare_enable(info->clk);
>> > if (ret < 0) {
>> > dev_dbg(>dev, "unable to enable AEMIF clock, err 
>> > %d\n",
>> > ret);
>> > @@ -767,7 +767,7 @@ syndrome_done:
>> >
>> >  err_scan:
>> >  err_timing:
>> > -   clk_disable(info->clk);
>> > +   clk_disable_unprepare(info->clk);
>> >
>> >  err_clk_enable:
>> > clk_put(info->clk);
>> > @@ -804,7 +804,7 @@ static int __exit nand_davinci_remove(struct 
>> > platform_device
>> *pdev)
>> >
>> > nand_release(>mtd);
>> >
>> > -   clk_disable(info->clk);
>> > +   clk_disable_unprepare(info->clk);
>> > clk_put(info->clk);
>> >
>> > kfree(info);
>> > --
>> > 1.7.9.5

RE: [PATCH] mtd:nand:clk: preparation for switch to common clock framework

>> -Original Message-
>> From: Karicheri, Muralidharan
>> Sent: Thursday, August 30, 2012 2:17 PM
>> To: dw...@infradead.org; artem.bityuts...@linux.intel.com; 
>> dbarysh...@gmail.com;
>> computersforpe...@gmail.com; linux-...@lists.infradead.org; linux-
>> ker...@vger.kernel.org; mturque...@linaro.org
>> Cc: Karicheri, Muralidharan
>> Subject: [PATCH] mtd:nand:clk: preparation for switch to common clock 
>> framework
>> 
>> As a first step towards migrating davinci platforms to use common clock
>> framework, replace all instances of clk_enable() with clk_prepare_enable()
>> and clk_disable() with clk_disable_unprepare(). Until the platform is
>> switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
>> adds a might_sleep() call and would work without any issues.
>> 
>> This will make it easy later to switch to common clk based implementation
>> of clk driver from DaVinci specific driver.
>> 
>> Signed-off-by: Murali Karicheri 
>> ---
>>  drivers/mtd/nand/davinci_nand.c |6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/mtd/nand/davinci_nand.c 
>> b/drivers/mtd/nand/davinci_nand.c
>> index d94b03c..6b8cf27 100644
>> --- a/drivers/mtd/nand/davinci_nand.c
>> +++ b/drivers/mtd/nand/davinci_nand.c
>> @@ -656,7 +656,7 @@ static int __init nand_davinci_probe(struct 
>> platform_device
>> *pdev)
>>  goto err_clk;
>>  }
>> 
>> -ret = clk_enable(info->clk);
>> +ret = clk_prepare_enable(info->clk);
>>  if (ret < 0) {
>>  dev_dbg(>dev, "unable to enable AEMIF clock, err %d\n",
>>  ret);
>> @@ -767,7 +767,7 @@ syndrome_done:
>> 
>>  err_scan:
>>  err_timing:
>> -clk_disable(info->clk);
>> +clk_disable_unprepare(info->clk);
>> 
>>  err_clk_enable:
>>  clk_put(info->clk);
>> @@ -804,7 +804,7 @@ static int __exit nand_davinci_remove(struct 
>> platform_device
>> *pdev)
>> 
>>  nand_release(>mtd);
>> 
>> -clk_disable(info->clk);
>> +clk_disable_unprepare(info->clk);
>>  clk_put(info->clk);
>> 
>>  kfree(info);
>> --
>> 1.7.9.5

subsystem owner,

Could you please review and apply this patch as needed? We need to get this 
upstream before submitting the patch for Common clock framework support for 
mach-davinci. If I need to follow a specific procedure to get this merged, 
please direct me to a process page.

Thanks.

Murali Karicheri
Software Design Engineer

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

RE: [PATCH] spi:clk: preparation for switch to common clock framework

>> -Original Message-
>> From: Karicheri, Muralidharan
>> Sent: Thursday, August 30, 2012 2:25 PM
>> To: linux-kernel@vger.kernel.org; mturque...@linaro.org; spi-devel-
>> gene...@lists.sourceforge.net; grant.lik...@secretlab.ca
>> Cc: Karicheri, Muralidharan
>> Subject: [PATCH] spi:clk: preparation for switch to common clock framework
>> 
>> As a first step towards migrating davinci platforms to use common clock
>> framework, replace all instances of clk_enable() with clk_prepare_enable()
>> and clk_disable() with clk_disable_unprepare(). Until the platform is
>> switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
>> adds a might_sleep() call and would work without any issues.
>> 
>> This will make it easy later to switch to common clk based implementation
>> of clk driver from DaVinci specific driver.
>> 
>> Signed-off-by: Murali Karicheri 
>> ---
>>  drivers/spi/spi-davinci.c |6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
>> index 9b2901f..71a6423 100644
>> --- a/drivers/spi/spi-davinci.c
>> +++ b/drivers/spi/spi-davinci.c
>> @@ -873,7 +873,7 @@ static int __devinit davinci_spi_probe(struct 
>> platform_device
>> *pdev)
>>  ret = -ENODEV;
>>  goto put_master;
>>  }
>> -clk_enable(dspi->clk);
>> +clk_prepare_enable(dspi->clk);
>> 
>>  master->bus_num = pdev->id;
>>  master->num_chipselect = pdata->num_chipselect;
>> @@ -959,7 +959,7 @@ free_dma:
>>  edma_free_channel(dspi->dma.rx_channel);
>>  edma_free_slot(dspi->dma.dummy_param_slot);
>>  free_clk:
>> -clk_disable(dspi->clk);
>> +clk_disable_unprepare(dspi->clk);
>>  clk_put(dspi->clk);
>>  put_master:
>>  spi_master_put(master);
>> @@ -995,7 +995,7 @@ static int __devexit davinci_spi_remove(struct 
>> platform_device
>> *pdev)
>> 
>>  spi_bitbang_stop(>bitbang);
>> 
>> -clk_disable(dspi->clk);
>> +clk_disable_unprepare(dspi->clk);
>>  clk_put(dspi->clk);
>>  spi_master_put(master);
>>  free_irq(dspi->irq, dspi);
>> --
>> 1.7.9.5

subsystem owner,

Could you please review and apply this patch as needed? We need to get this 
upstream before submitting the patch for Common clock framework support for 
mach-davinci. If I need to follow a specific procedure to get this merged, 
please direct me to a process page.

Thanks.

Murali Karicheri
Software Design Engineer

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

RE: [PATCH] wdt:clk: preparation for switch to common clock framework

>> -Original Message-
>> From: Karicheri, Muralidharan
>> Sent: Thursday, August 30, 2012 2:29 PM
>> To: linux-kernel@vger.kernel.org; mturque...@linaro.org; linux-
>> watch...@vger.kernel.org; w...@iguana.be
>> Cc: Karicheri, Muralidharan
>> Subject: [PATCH] wdt:clk: preparation for switch to common clock framework
>> 
>> As a first step towards migrating davinci platforms to use common clock
>> framework, replace all instances of clk_enable() with clk_prepare_enable()
>> and clk_disable() with clk_disable_unprepare(). Until the platform is
>> switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
>> adds a might_sleep() call and would work without any issues.
>> 
>> This will make it easy later to switch to common clk based implementation
>> of clk driver from DaVinci specific driver.
>> 
>> Signed-off-by: Murali Karicheri 
>> ---
>>  drivers/watchdog/davinci_wdt.c |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
>> index c8c5c80..eb44b03 100644
>> --- a/drivers/watchdog/davinci_wdt.c
>> +++ b/drivers/watchdog/davinci_wdt.c
>> @@ -208,7 +208,7 @@ static int __devinit davinci_wdt_probe(struct 
>> platform_device
>> *pdev)
>>  if (WARN_ON(IS_ERR(wdt_clk)))
>>  return PTR_ERR(wdt_clk);
>> 
>> -clk_enable(wdt_clk);
>> +clk_prepare_enable(wdt_clk);
>> 
>>  if (heartbeat < 1 || heartbeat > MAX_HEARTBEAT)
>>  heartbeat = DEFAULT_HEARTBEAT;
>> @@ -256,7 +256,7 @@ static int __devexit davinci_wdt_remove(struct 
>> platform_device
>> *pdev)
>>  wdt_mem = NULL;
>>  }
>> 
>> -clk_disable(wdt_clk);
>> +clk_disable_unprepare(wdt_clk);
>>  clk_put(wdt_clk);
>> 
>>  return 0;
>> --
>> 1.7.9.5

subsystem owner,

Could you please review and apply this patch as needed? We need to get this 
upstream before submitting the patch for Common clock framework support for 
mach-davinci. If I need to follow a specific procedure to get this merged, 
please direct me to a process page.

Thanks.

Murali Karicheri
Software Design Engineer


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

RE: [PATCH] wdt:clk: preparation for switch to common clock framework

 -Original Message-
 From: Karicheri, Muralidharan
 Sent: Thursday, August 30, 2012 2:29 PM
 To: linux-kernel@vger.kernel.org; mturque...@linaro.org; linux-
 watch...@vger.kernel.org; w...@iguana.be
 Cc: Karicheri, Muralidharan
 Subject: [PATCH] wdt:clk: preparation for switch to common clock framework

 As a first step towards migrating davinci platforms to use common clock
 framework, replace all instances of clk_enable() with clk_prepare_enable()
 and clk_disable() with clk_disable_unprepare(). Until the platform is
 switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
 adds a might_sleep() call and would work without any issues.

 This will make it easy later to switch to common clk based implementation
 of clk driver from DaVinci specific driver.

 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 ---
  drivers/watchdog/davinci_wdt.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
 index c8c5c80..eb44b03 100644
 --- a/drivers/watchdog/davinci_wdt.c
 +++ b/drivers/watchdog/davinci_wdt.c
 @@ -208,7 +208,7 @@ static int __devinit davinci_wdt_probe(struct 
 platform_device
 *pdev)
  if (WARN_ON(IS_ERR(wdt_clk)))
  return PTR_ERR(wdt_clk);

 -clk_enable(wdt_clk);
 +clk_prepare_enable(wdt_clk);

  if (heartbeat  1 || heartbeat  MAX_HEARTBEAT)
  heartbeat = DEFAULT_HEARTBEAT;
 @@ -256,7 +256,7 @@ static int __devexit davinci_wdt_remove(struct 
 platform_device
 *pdev)
  wdt_mem = NULL;
  }

 -clk_disable(wdt_clk);
 +clk_disable_unprepare(wdt_clk);
  clk_put(wdt_clk);

  return 0;
 --
 1.7.9.5

subsystem owner,

Could you please review and apply this patch as needed? We need to get this 
upstream before submitting the patch for Common clock framework support for 
mach-davinci. If I need to follow a specific procedure to get this merged, 
please direct me to a process page.

Thanks.

Murali Karicheri
Software Design Engineer

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

RE: [PATCH] spi:clk: preparation for switch to common clock framework

 -Original Message-
 From: Karicheri, Muralidharan
 Sent: Thursday, August 30, 2012 2:25 PM
 To: linux-kernel@vger.kernel.org; mturque...@linaro.org; spi-devel-
 gene...@lists.sourceforge.net; grant.lik...@secretlab.ca
 Cc: Karicheri, Muralidharan
 Subject: [PATCH] spi:clk: preparation for switch to common clock framework
 
 As a first step towards migrating davinci platforms to use common clock
 framework, replace all instances of clk_enable() with clk_prepare_enable()
 and clk_disable() with clk_disable_unprepare(). Until the platform is
 switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
 adds a might_sleep() call and would work without any issues.
 
 This will make it easy later to switch to common clk based implementation
 of clk driver from DaVinci specific driver.
 
 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 ---
  drivers/spi/spi-davinci.c |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
 index 9b2901f..71a6423 100644
 --- a/drivers/spi/spi-davinci.c
 +++ b/drivers/spi/spi-davinci.c
 @@ -873,7 +873,7 @@ static int __devinit davinci_spi_probe(struct 
 platform_device
 *pdev)
  ret = -ENODEV;
  goto put_master;
  }
 -clk_enable(dspi-clk);
 +clk_prepare_enable(dspi-clk);
 
  master-bus_num = pdev-id;
  master-num_chipselect = pdata-num_chipselect;
 @@ -959,7 +959,7 @@ free_dma:
  edma_free_channel(dspi-dma.rx_channel);
  edma_free_slot(dspi-dma.dummy_param_slot);
  free_clk:
 -clk_disable(dspi-clk);
 +clk_disable_unprepare(dspi-clk);
  clk_put(dspi-clk);
  put_master:
  spi_master_put(master);
 @@ -995,7 +995,7 @@ static int __devexit davinci_spi_remove(struct 
 platform_device
 *pdev)
 
  spi_bitbang_stop(dspi-bitbang);
 
 -clk_disable(dspi-clk);
 +clk_disable_unprepare(dspi-clk);
  clk_put(dspi-clk);
  spi_master_put(master);
  free_irq(dspi-irq, dspi);
 --
 1.7.9.5

subsystem owner,

Could you please review and apply this patch as needed? We need to get this 
upstream before submitting the patch for Common clock framework support for 
mach-davinci. If I need to follow a specific procedure to get this merged, 
please direct me to a process page.

Thanks.

Murali Karicheri
Software Design Engineer

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

RE: [PATCH] mtd:nand:clk: preparation for switch to common clock framework

 -Original Message-
 From: Karicheri, Muralidharan
 Sent: Thursday, August 30, 2012 2:17 PM
 To: dw...@infradead.org; artem.bityuts...@linux.intel.com; 
 dbarysh...@gmail.com;
 computersforpe...@gmail.com; linux-...@lists.infradead.org; linux-
 ker...@vger.kernel.org; mturque...@linaro.org
 Cc: Karicheri, Muralidharan
 Subject: [PATCH] mtd:nand:clk: preparation for switch to common clock 
 framework

 As a first step towards migrating davinci platforms to use common clock
 framework, replace all instances of clk_enable() with clk_prepare_enable()
 and clk_disable() with clk_disable_unprepare(). Until the platform is
 switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
 adds a might_sleep() call and would work without any issues.

 This will make it easy later to switch to common clk based implementation
 of clk driver from DaVinci specific driver.

 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 ---
  drivers/mtd/nand/davinci_nand.c |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/drivers/mtd/nand/davinci_nand.c 
 b/drivers/mtd/nand/davinci_nand.c
 index d94b03c..6b8cf27 100644
 --- a/drivers/mtd/nand/davinci_nand.c
 +++ b/drivers/mtd/nand/davinci_nand.c
 @@ -656,7 +656,7 @@ static int __init nand_davinci_probe(struct 
 platform_device
 *pdev)
  goto err_clk;
  }

 -ret = clk_enable(info-clk);
 +ret = clk_prepare_enable(info-clk);
  if (ret  0) {
  dev_dbg(pdev-dev, unable to enable AEMIF clock, err %d\n,
  ret);
 @@ -767,7 +767,7 @@ syndrome_done:

  err_scan:
  err_timing:
 -clk_disable(info-clk);
 +clk_disable_unprepare(info-clk);

  err_clk_enable:
  clk_put(info-clk);
 @@ -804,7 +804,7 @@ static int __exit nand_davinci_remove(struct 
 platform_device
 *pdev)

  nand_release(info-mtd);

 -clk_disable(info-clk);
 +clk_disable_unprepare(info-clk);
  clk_put(info-clk);

  kfree(info);
 --
 1.7.9.5

subsystem owner,

Could you please review and apply this patch as needed? We need to get this 
upstream before submitting the patch for Common clock framework support for 
mach-davinci. If I need to follow a specific procedure to get this merged, 
please direct me to a process page.

Thanks.

Murali Karicheri
Software Design Engineer

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

RE: [PATCH] mtd:nand:clk: preparation for switch to common clock framework

Mike,

How do these patch get to upstream? Does this get merged through davinci 
maintainer or through individual subsystem maintainers? 

Thanks.

Murali Karicheri
Software Design Engineer


 -Original Message-
 From: Mike Turquette [mailto:mturque...@linaro.org]
 Sent: Friday, September 07, 2012 5:29 PM
 To: Karicheri, Muralidharan; dw...@infradead.org; 
 artem.bityuts...@linux.intel.com;
 dbarysh...@gmail.com; computersforpe...@gmail.com; 
 linux-...@lists.infradead.org;
 linux-kernel@vger.kernel.org
 Cc: Karicheri, Muralidharan
 Subject: Re: [PATCH] mtd:nand:clk: preparation for switch to common clock 
 framework
 
 Quoting Murali Karicheri (2012-08-30 11:17:04)
  As a first step towards migrating davinci platforms to use common clock
  framework, replace all instances of clk_enable() with clk_prepare_enable()
  and clk_disable() with clk_disable_unprepare(). Until the platform is
  switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
  adds a might_sleep() call and would work without any issues.
 
  This will make it easy later to switch to common clk based implementation
  of clk driver from DaVinci specific driver.
 
  Signed-off-by: Murali Karicheri m-kariche...@ti.com
 
 Acked-by: Mike Turquette mturque...@linaro.org
 
  ---
   drivers/mtd/nand/davinci_nand.c |6 +++---
   1 file changed, 3 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/mtd/nand/davinci_nand.c 
  b/drivers/mtd/nand/davinci_nand.c
  index d94b03c..6b8cf27 100644
  --- a/drivers/mtd/nand/davinci_nand.c
  +++ b/drivers/mtd/nand/davinci_nand.c
  @@ -656,7 +656,7 @@ static int __init nand_davinci_probe(struct 
  platform_device
 *pdev)
  goto err_clk;
  }
 
  -   ret = clk_enable(info-clk);
  +   ret = clk_prepare_enable(info-clk);
  if (ret  0) {
  dev_dbg(pdev-dev, unable to enable AEMIF clock, err 
  %d\n,
  ret);
  @@ -767,7 +767,7 @@ syndrome_done:
 
   err_scan:
   err_timing:
  -   clk_disable(info-clk);
  +   clk_disable_unprepare(info-clk);
 
   err_clk_enable:
  clk_put(info-clk);
  @@ -804,7 +804,7 @@ static int __exit nand_davinci_remove(struct 
  platform_device
 *pdev)
 
  nand_release(info-mtd);
 
  -   clk_disable(info-clk);
  +   clk_disable_unprepare(info-clk);
  clk_put(info-clk);
 
  kfree(info);
  --
  1.7.9.5

RE: [PATCH] gpio:clk: preparation for switch to common clock framework

2012-09-03 Thread Karicheri, Muralidharan

>> -Original Message-
>> From: Linus Walleij [mailto:linus.wall...@linaro.org]
>> Sent: Friday, August 31, 2012 7:14 PM
>> To: Karicheri, Muralidharan; Hilman, Kevin; Nori, Sekhar
>> Cc: grant.lik...@secretlab.ca; linux-kernel@vger.kernel.org; 
>> mturque...@linaro.org
>> Subject: Re: [PATCH] gpio:clk: preparation for switch to common clock 
>> framework
>> 
>> On Thu, Aug 30, 2012 at 8:03 PM, Murali Karicheri  
>> wrote:
>> 
>> > As a first step towards migrating davinci platforms to use common clock
>> > framework, replace all instances of clk_enable() with clk_prepare_enable()
>> > and clk_disable() with clk_disable_unprepare(). Until the platform is
>> > switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
>> > adds a might_sleep() call and would work without any issues.
>> >
>> > This will make it easy later to switch to common clk based implementation
>> > of clk driver from DaVinci specific driver.
>> >
>> > Signed-off-by: Murali Karicheri 
>> 
>> OK the patch is so obviously correct so I just applied it, DaVinci folks,
>> scream if you still don't want it for some reason...
>> 
Linus,

Thanks for applying this patch.

Murali Karicheri
Software Design Engineer
>> Yours,
>> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] gpio:clk: preparation for switch to common clock framework

2012-09-03 Thread Karicheri, Muralidharan

 -Original Message-
 From: Linus Walleij [mailto:linus.wall...@linaro.org]
 Sent: Friday, August 31, 2012 7:14 PM
 To: Karicheri, Muralidharan; Hilman, Kevin; Nori, Sekhar
 Cc: grant.lik...@secretlab.ca; linux-kernel@vger.kernel.org; 
 mturque...@linaro.org
 Subject: Re: [PATCH] gpio:clk: preparation for switch to common clock 
 framework

 On Thu, Aug 30, 2012 at 8:03 PM, Murali Karicheri m-kariche...@ti.com 
 wrote:

  As a first step towards migrating davinci platforms to use common clock
  framework, replace all instances of clk_enable() with clk_prepare_enable()
  and clk_disable() with clk_disable_unprepare(). Until the platform is
  switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
  adds a might_sleep() call and would work without any issues.

  This will make it easy later to switch to common clk based implementation
  of clk driver from DaVinci specific driver.

  Signed-off-by: Murali Karicheri m-kariche...@ti.com

 OK the patch is so obviously correct so I just applied it, DaVinci folks,
 scream if you still don't want it for some reason...

Linus,

Thanks for applying this patch.

Murali Karicheri
Software Design Engineer
 Yours,
 Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] of: add devres version of of_iomap

>> -Original Message-
>> From: Rob Herring [mailto:robherri...@gmail.com]
>> Sent: Thursday, August 30, 2012 2:27 PM
>> To: Karicheri, Muralidharan
>> Cc: grant.lik...@secretlab.ca; devicetree-disc...@lists.ozlabs.org; linux-
>> ker...@vger.kernel.org
>> Subject: Re: [PATCH] of: add devres version of of_iomap
>> 
>> On 08/30/2012 10:32 AM, Murali Karicheri wrote:
>> > This adds devres version of the of_iomap() to allow resource to be cleaned
>> > through devres.
>> 
>> If you have a struct device, then don't you already have a resource and
>> can just use devm_ioremap in a driver? New drivers should not be using
>> of_iomap.
>> 

That is the point. If you do a grep under driver, there are many drivers using 
the pattern
like this. This helper function is mean to replace this code.

>From dma/sirf-dma.c

ret = of_address_to_resource(dn, 0, );
if (ret) {
dev_err(dev, "Error parsing memory region!\n");
   goto error;
}

regs_start = res.start;
regs_size = resource_size();

base = devm_ioremap(dev, regs_start, regs_size);
if (!base) {
dev_err(dev, "Error mapping memory region!\n");
   goto error;
}

Other instances.

edac/mpc85xx_edac.c
media/video/fsl-viu.c
mtd/nand/mpc5121_nfc.c

Some of these code uses devm_request_mem_region() as well. Isn't a good idea to 
add this helper
that can be called by new drivers to replace this sequence? I could update the 
patch to do this call
as well?

>> Rob
>> 
>> >
>> > Signed-off-by: Murali Karicheri 
>> > ---
>> >  drivers/of/address.c   |   26 --
>> >  include/linux/of_address.h |2 ++
>> >  2 files changed, 26 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/of/address.c b/drivers/of/address.c
>> > index 7e262a6..d3da426 100644
>> > --- a/drivers/of/address.c
>> > +++ b/drivers/of/address.c
>> > @@ -602,10 +602,9 @@ struct device_node
>> *of_find_matching_node_by_address(struct device_node *from,
>> >return NULL;
>> >  }
>> >
>> > -
>> >  /**
>> >   * of_iomap - Maps the memory mapped IO for a given device_node
>> > - * @device:   the device whose io range will be mapped
>> > + * @device_node: Ptr to the device node that has the reg property
>> >   * @index:index of the io range
>> >   *
>> >   * Returns a pointer to the mapped memory
>> > @@ -620,3 +619,26 @@ void __iomem *of_iomap(struct device_node *np, int 
>> > index)
>> >return ioremap(res.start, resource_size());
>> >  }
>> >  EXPORT_SYMBOL(of_iomap);
>> > +
>> > +/**
>> > + * of_devm_iomap - devres version of of_iomap
>> > + * @device:   the device whose io range will be mapped
>> > + * @index:index of the io range
>> > + *
>> > + * Returns a pointer to the mapped memory
>> > + */
>> > +void __iomem *of_devm_iomap(struct device *dev, int index)
>> > +{
>> > +  struct device_node *np;
>> > +  struct resource res;
>> > +
>> > +  if (!dev)
>> > +  return NULL;
>> > +
>> > +  np = dev->of_node;
>> > +  if (of_address_to_resource(np, index, ))
>> > +  return NULL;
>> > +
>> > +  return devm_ioremap(dev, res.start, resource_size());
>> > +}
>> > +EXPORT_SYMBOL(of_devm_iomap);
>> > diff --git a/include/linux/of_address.h b/include/linux/of_address.h
>> > index 01b925a..67efa5f 100644
>> > --- a/include/linux/of_address.h
>> > +++ b/include/linux/of_address.h
>> > @@ -3,6 +3,7 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >
>> >  #ifdef CONFIG_OF_ADDRESS
>> >  extern u64 of_translate_address(struct device_node *np, const __be32 
>> > *addr);
>> > @@ -13,6 +14,7 @@ extern struct device_node 
>> > *of_find_matching_node_by_address(
>> >const struct of_device_id *matches,
>> >u64 base_address);
>> >  extern void __iomem *of_iomap(struct device_node *device, int index);
>> > +extern void __iomem *of_devm_iomap(struct device *dev, int index);
>> >
>> >  /* Extract an address from a device, returns the region size and
>> >   * the address space flags too. The PCI version uses a BAR number
>> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH - 2/2] arm: disable caches based on config option

Submitted. Thanks.

Murali Karicheri
Software Design Engineer


>> -Original Message-
>> From: Nicolas Pitre [mailto:nicolas.pi...@linaro.org]
>> Sent: Thursday, August 30, 2012 11:59 AM
>> To: Karicheri, Muralidharan
>> Cc: Russell King - ARM Linux; t...@atomide.com; Shilimkar, Santosh; 
>> w...@iguana.be;
>> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH - 2/2] arm: disable caches based on config option
>> 
>> On Thu, 30 Aug 2012, Murali Karicheri wrote:
>> 
>> > CONFIG_CPU_ICACHE_DISABLE and CONFIG_CPU_DCACHE_DISABLE are available
>> > to allow disabling of D-Cache and I-Cache. However the compressed version
>> > of head.S currently doesn't check these variables. This patch will fix
>> > this issue and is written similar to the uncompressed version of head.S
>> >
>> > Signed-off-by: Murali Karicheri 
>> 
>> Acked-by: nicolas Pitre 
>> 
>> You may submit your patch to http://www.arm.linux.org.uk/developer/patches/.
>> 
>> 
>> > ---
>> >  arch/arm/boot/compressed/head.S |6 ++
>> >  1 file changed, 6 insertions(+)
>> >
>> > diff --git a/arch/arm/boot/compressed/head.S 
>> > b/arch/arm/boot/compressed/head.S
>> > index b8c64b8..e1d2124 100644
>> > --- a/arch/arm/boot/compressed/head.S
>> > +++ b/arch/arm/boot/compressed/head.S
>> > @@ -659,6 +659,12 @@ __armv7_mmu_cache_on:
>> >  #ifdef CONFIG_CPU_ENDIAN_BE8
>> >orr r0, r0, #1 << 25@ big-endian page tables
>> >  #endif
>> > +#ifdef CONFIG_CPU_DCACHE_DISABLE
>> > +  bic r0, r0, #1 << 2
>> > +#endif
>> > +#ifdef CONFIG_CPU_ICACHE_DISABLE
>> > +  bic r0, r0, #1 << 12
>> > +#endif
>> >orrne   r0, r0, #1  @ MMU enabled
>> >movne   r1, #0xfffd @ domain 0 = client
>> >mcrne   p15, 0, r3, c2, c0, 0   @ load page table pointer
>> > --
>> > 1.7.9.5
>> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] of: adding devres version of of_iomap

Please ignore this patch. I am re-sending this with a minor typo fixed.

Murali Karicheri
Software Design Engineer

>> -Original Message-
>> From: Karicheri, Muralidharan
>> Sent: Thursday, August 30, 2012 11:30 AM
>> To: grant.lik...@secretlab.ca; rob.herr...@calxeda.com; devicetree-
>> disc...@lists.ozlabs.org; linux-kernel@vger.kernel.org
>> Cc: Karicheri, Muralidharan
>> Subject: [PATCH] of: adding devres version of of_iomap
>> 
>> This adds devres version of the of_iomap() to allow resource to be cleaned
>> through devres.
>> 
>> Signed-off-by: Murali Karicheri 
>> 
>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>> index 7e262a6..d3da426 100644
>> --- a/drivers/of/address.c
>> +++ b/drivers/of/address.c
>> @@ -602,10 +602,9 @@ struct device_node
>> *of_find_matching_node_by_address(struct device_node *from,
>>  return NULL;
>>  }
>> 
>> -
>>  /**
>>   * of_iomap - Maps the memory mapped IO for a given device_node
>> - * @device: the device whose io range will be mapped
>> + * @device_node: Ptr to the device node that has the reg property
>>   * @index:  index of the io range
>>   *
>>   * Returns a pointer to the mapped memory
>> @@ -620,3 +619,26 @@ void __iomem *of_iomap(struct device_node *np, int 
>> index)
>>  return ioremap(res.start, resource_size());
>>  }
>>  EXPORT_SYMBOL(of_iomap);
>> +
>> +/**
>> + * of_devm_iomap - devres version of of_iomap
>> + * @device: the device whose io range will be mapped
>> + * @index:  index of the io range
>> + *
>> + * Returns a pointer to the mapped memory
>> + */
>> +void __iomem *of_devm_iomap(struct device *dev, int index)
>> +{
>> +struct device_node *np;
>> +struct resource res;
>> +
>> +if (!dev)
>> +return NULL;
>> +
>> +np = dev->of_node;
>> +if (of_address_to_resource(np, index, ))
>> +return NULL;
>> +
>> +return devm_ioremap(dev, res.start, resource_size());
>> +}
>> +EXPORT_SYMBOL(of_devm_iomap);
>> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
>> index 01b925a..67efa5f 100644
>> --- a/include/linux/of_address.h
>> +++ b/include/linux/of_address.h
>> @@ -3,6 +3,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> 
>>  #ifdef CONFIG_OF_ADDRESS
>>  extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
>> @@ -13,6 +14,7 @@ extern struct device_node 
>> *of_find_matching_node_by_address(
>>  const struct of_device_id *matches,
>>  u64 base_address);
>>  extern void __iomem *of_iomap(struct device_node *device, int index);
>> +extern void __iomem *of_devm_iomap(struct device *dev, int index);
>> 
>>  /* Extract an address from a device, returns the region size and
>>   * the address space flags too. The PCI version uses a BAR number
>> --
>> 1.7.9.5

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

RE: [PATCH] of: adding devres version of of_iomap

Please ignore this patch. I am re-sending this with a minor typo fixed.

Murali Karicheri
Software Design Engineer

 -Original Message-
 From: Karicheri, Muralidharan
 Sent: Thursday, August 30, 2012 11:30 AM
 To: grant.lik...@secretlab.ca; rob.herr...@calxeda.com; devicetree-
 disc...@lists.ozlabs.org; linux-kernel@vger.kernel.org
 Cc: Karicheri, Muralidharan
 Subject: [PATCH] of: adding devres version of of_iomap
 
 This adds devres version of the of_iomap() to allow resource to be cleaned
 through devres.
 
 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 
 diff --git a/drivers/of/address.c b/drivers/of/address.c
 index 7e262a6..d3da426 100644
 --- a/drivers/of/address.c
 +++ b/drivers/of/address.c
 @@ -602,10 +602,9 @@ struct device_node
 *of_find_matching_node_by_address(struct device_node *from,
  return NULL;
  }
 
 -
  /**
   * of_iomap - Maps the memory mapped IO for a given device_node
 - * @device: the device whose io range will be mapped
 + * @device_node: Ptr to the device node that has the reg property
   * @index:  index of the io range
   *
   * Returns a pointer to the mapped memory
 @@ -620,3 +619,26 @@ void __iomem *of_iomap(struct device_node *np, int 
 index)
  return ioremap(res.start, resource_size(res));
  }
  EXPORT_SYMBOL(of_iomap);
 +
 +/**
 + * of_devm_iomap - devres version of of_iomap
 + * @device: the device whose io range will be mapped
 + * @index:  index of the io range
 + *
 + * Returns a pointer to the mapped memory
 + */
 +void __iomem *of_devm_iomap(struct device *dev, int index)
 +{
 +struct device_node *np;
 +struct resource res;
 +
 +if (!dev)
 +return NULL;
 +
 +np = dev-of_node;
 +if (of_address_to_resource(np, index, res))
 +return NULL;
 +
 +return devm_ioremap(dev, res.start, resource_size(res));
 +}
 +EXPORT_SYMBOL(of_devm_iomap);
 diff --git a/include/linux/of_address.h b/include/linux/of_address.h
 index 01b925a..67efa5f 100644
 --- a/include/linux/of_address.h
 +++ b/include/linux/of_address.h
 @@ -3,6 +3,7 @@
  #include linux/ioport.h
  #include linux/errno.h
  #include linux/of.h
 +#include linux/device.h
 
  #ifdef CONFIG_OF_ADDRESS
  extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
 @@ -13,6 +14,7 @@ extern struct device_node 
 *of_find_matching_node_by_address(
  const struct of_device_id *matches,
  u64 base_address);
  extern void __iomem *of_iomap(struct device_node *device, int index);
 +extern void __iomem *of_devm_iomap(struct device *dev, int index);
 
  /* Extract an address from a device, returns the region size and
   * the address space flags too. The PCI version uses a BAR number
 --
 1.7.9.5

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

RE: [PATCH - 2/2] arm: disable caches based on config option

Submitted. Thanks.

Murali Karicheri
Software Design Engineer


 -Original Message-
 From: Nicolas Pitre [mailto:nicolas.pi...@linaro.org]
 Sent: Thursday, August 30, 2012 11:59 AM
 To: Karicheri, Muralidharan
 Cc: Russell King - ARM Linux; t...@atomide.com; Shilimkar, Santosh; 
 w...@iguana.be;
 linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
 Subject: Re: [PATCH - 2/2] arm: disable caches based on config option
 
 On Thu, 30 Aug 2012, Murali Karicheri wrote:
 
  CONFIG_CPU_ICACHE_DISABLE and CONFIG_CPU_DCACHE_DISABLE are available
  to allow disabling of D-Cache and I-Cache. However the compressed version
  of head.S currently doesn't check these variables. This patch will fix
  this issue and is written similar to the uncompressed version of head.S
 
  Signed-off-by: Murali Karicheri m-kariche...@ti.com
 
 Acked-by: nicolas Pitre n...@linaro.org
 
 You may submit your patch to http://www.arm.linux.org.uk/developer/patches/.
 
 
  ---
   arch/arm/boot/compressed/head.S |6 ++
   1 file changed, 6 insertions(+)
 
  diff --git a/arch/arm/boot/compressed/head.S 
  b/arch/arm/boot/compressed/head.S
  index b8c64b8..e1d2124 100644
  --- a/arch/arm/boot/compressed/head.S
  +++ b/arch/arm/boot/compressed/head.S
  @@ -659,6 +659,12 @@ __armv7_mmu_cache_on:
   #ifdef CONFIG_CPU_ENDIAN_BE8
 orr r0, r0, #1  25@ big-endian page tables
   #endif
  +#ifdef CONFIG_CPU_DCACHE_DISABLE
  +  bic r0, r0, #1  2
  +#endif
  +#ifdef CONFIG_CPU_ICACHE_DISABLE
  +  bic r0, r0, #1  12
  +#endif
 orrne   r0, r0, #1  @ MMU enabled
 movne   r1, #0xfffd @ domain 0 = client
 mcrne   p15, 0, r3, c2, c0, 0   @ load page table pointer
  --
  1.7.9.5
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] of: add devres version of of_iomap