Re: [PATCH v9 03/19] vfio: platform: add the VFIO PLATFORM module to Kconfig

[Hongbo Zhang]

On 12 November 2014 17:57, Antonios Motakis
 wrote:
> Hello Hongbo,
>
> On Wed, Nov 12, 2014 at 10:52 AM, Hongbo Zhang  
> wrote:
>> On 28 October 2014 02:07, Antonios Motakis
>>  wrote:
>>>
>>> Enable building the VFIO PLATFORM driver that allows to use Linux platform
>>> devices with VFIO.
>>>
>>> Signed-off-by: Antonios Motakis 
>>> ---
>>>  drivers/vfio/Kconfig   | 1 +
>>>  drivers/vfio/Makefile  | 1 +
>>>  drivers/vfio/platform/Kconfig  | 9 +
>>>  drivers/vfio/platform/Makefile | 4 
>>>  4 files changed, 15 insertions(+)
>>>  create mode 100644 drivers/vfio/platform/Kconfig
>>>  create mode 100644 drivers/vfio/platform/Makefile
>>>
>>> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
>>> index a0abe04..962fb80 100644
>>> --- a/drivers/vfio/Kconfig
>>> +++ b/drivers/vfio/Kconfig
>>> @@ -27,3 +27,4 @@ menuconfig VFIO
>>>   If you don't know what to do here, say N.
>>>
>>>  source "drivers/vfio/pci/Kconfig"
>>> +source "drivers/vfio/platform/Kconfig"
>>> diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
>>> index 0b035b1..dadf0ca 100644
>>> --- a/drivers/vfio/Makefile
>>> +++ b/drivers/vfio/Makefile
>>> @@ -3,3 +3,4 @@ obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
>>>  obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
>>>  obj-$(CONFIG_VFIO_SPAPR_EEH) += vfio_spapr_eeh.o
>>>  obj-$(CONFIG_VFIO_PCI) += pci/
>>> +obj-$(CONFIG_VFIO_PLATFORM) += platform/
>>> diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig
>>> new file mode 100644
>>> index 000..c51af17
>>> --- /dev/null
>>> +++ b/drivers/vfio/platform/Kconfig
>>> @@ -0,0 +1,9 @@
>>> +config VFIO_PLATFORM
>>> +   tristate "VFIO support for platform devices"
>>> +   depends on VFIO && EVENTFD && ARM
>>
>> Hi Antonios,
>> Is this only for ARM? how about X86 and PowerPC?
>> On Freescale's PowerPC platform, the IOMMU is called PAMU (Peripheral
>> Access Management Unit), and I am trying to use this VFIO framework on
>> it.
>>
>
> In principle it should be working on any platform with such devices;
> as long as you have a VFIO IOMMU driver for the PAMU (on ARM we use
> VFIO PLATFORM for the device, with VFIO IOMMU TYPE1 for the IOMMU).
>

Antonios,
As far as you know, on which ARM platform can I apply your patches directly?
My purpose is to apply you patches[1], and then implement a user space
driver to evaluate the performance.

[1]  It is better without manually merging conflicts/dependencies etc,
I am vfio-platform user, not a iommu expert.

> So if you have a suitable IOMMU driver for your target, feel free to
> test it, and let us know of the results.
>
>>>
>>> +   help
>>> + Support for platform devices with VFIO. This is required to make
>>> + use of platform devices present on the system using the VFIO
>>> + framework.
>>> +
>>> + If you don't know what to do here, say N.
>>> diff --git a/drivers/vfio/platform/Makefile b/drivers/vfio/platform/Makefile
>>> new file mode 100644
>>> index 000..279862b
>>> --- /dev/null
>>> +++ b/drivers/vfio/platform/Makefile
>>> @@ -0,0 +1,4 @@
>>> +
>>> +vfio-platform-y := vfio_platform.o vfio_platform_common.o
>>> +
>>> +obj-$(CONFIG_VFIO_PLATFORM) += vfio-platform.o
>>> --
>>> 2.1.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
--
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 v9 03/19] vfio: platform: add the VFIO PLATFORM module to Kconfig

[Hongbo Zhang]

On 12 November 2014 19:00, bharat.bhus...@freescale.com
 wrote:
>
>
>> -Original Message-----
>> From: Hongbo Zhang [mailto:hongbo.zh...@linaro.org]
>> Sent: Wednesday, November 12, 2014 4:09 PM
>> To: Bhushan Bharat-R65777
>> Cc: Antonios Motakis; open list:VFIO DRIVER; will.dea...@arm.com;
>> alex.william...@redhat.com; open list; io...@lists.linux-foundation.org;
>> t...@virtualopensystems.com; kvm...@lists.cs.columbia.edu
>> Subject: Re: [PATCH v9 03/19] vfio: platform: add the VFIO PLATFORM module to
>> Kconfig
>>
>> On 12 November 2014 18:05, bharat.bhus...@freescale.com
>>  wrote:
>> > Hi,
>> >
>> >
>> >
>> > This is not yet supported on Freescale PowerPC. I am still in process
>> > of upstreaming the FSL PAMU specific patches for same.
>> >
>> > Initial plan is to test with PCIe devices and then with Platform devices.
>> >
>>
>> I see there is already driver/iommu/fsl_pamu.c, doesn't it work?
>
> We need VFIO iommu driver for same.
>
>> Could you explain briefly what is wrong? I've heard that the vfio pci works 
>> on
>> powerpc platforms.
>
> Yes, patches are in Freescale internal git repository. But those patches are 
> yet to be upstreamed. I have started working on same.

(I come from Freescale too, just currently assigned to Linaro)
Oh, yes I now see vfio iommu driver in the internal git repo, but not
in the community one.
It seems I have to select another platform within Linaro to work with.


>
> Thanks
> -Bharat
>
>>
>> >
>> >
>> > Thanks
>> >
>> > -Bharat
>> >
>> >
>> >
>> > From: kvmarm-boun...@lists.cs.columbia.edu
>> > [mailto:kvmarm-boun...@lists.cs.columbia.edu] On Behalf Of Hongbo
>> > Zhang
>> > Sent: Wednesday, November 12, 2014 3:08 PM
>> > To: Antonios Motakis
>> > Cc: open list:VFIO DRIVER; will.dea...@arm.com;
>> > alex.william...@redhat.com; open list;
>> > io...@lists.linux-foundation.org; t...@virtualopensystems.com;
>> > kvm...@lists.cs.columbia.edu
>> > Subject: Re: [PATCH v9 03/19] vfio: platform: add the VFIO PLATFORM
>> > module to Kconfig
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 28 October 2014 02:07, Antonios Motakis
>> >  wrote:
>> >
>> > Enable building the VFIO PLATFORM driver that allows to use Linux
>> > platform devices with VFIO.
>> >
>> > Signed-off-by: Antonios Motakis 
>> > ---
>> >  drivers/vfio/Kconfig   | 1 +
>> >  drivers/vfio/Makefile  | 1 +
>> >  drivers/vfio/platform/Kconfig  | 9 +
>> > drivers/vfio/platform/Makefile | 4 
>> >  4 files changed, 15 insertions(+)
>> >  create mode 100644 drivers/vfio/platform/Kconfig  create mode 100644
>> > drivers/vfio/platform/Makefile
>> >
>> > diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig index
>> > a0abe04..962fb80 100644
>> > --- a/drivers/vfio/Kconfig
>> > +++ b/drivers/vfio/Kconfig
>> > @@ -27,3 +27,4 @@ menuconfig VFIO
>> >   If you don't know what to do here, say N.
>> >
>> >  source "drivers/vfio/pci/Kconfig"
>> > +source "drivers/vfio/platform/Kconfig"
>> > diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile index
>> > 0b035b1..dadf0ca 100644
>> > --- a/drivers/vfio/Makefile
>> > +++ b/drivers/vfio/Makefile
>> > @@ -3,3 +3,4 @@ obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
>> >  obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
>> >  obj-$(CONFIG_VFIO_SPAPR_EEH) += vfio_spapr_eeh.o
>> >  obj-$(CONFIG_VFIO_PCI) += pci/
>> > +obj-$(CONFIG_VFIO_PLATFORM) += platform/
>> > diff --git a/drivers/vfio/platform/Kconfig
>> > b/drivers/vfio/platform/Kconfig new file mode 100644 index
>> > 000..c51af17
>> > --- /dev/null
>> > +++ b/drivers/vfio/platform/Kconfig
>> > @@ -0,0 +1,9 @@
>> > +config VFIO_PLATFORM
>> > +   tristate "VFIO support for platform devices"
>> > +   depends on VFIO && EVENTFD && ARM
>> >
>> >
>> >
>> > Hi Antonios,
>> >
>> > Is this only for ARM? how about X86 and PowerPC?
>> >
>> > On Freescale's PowerPC platform, the IOMMU is called PAMU (Peripheral
>> > Access Management Unit), and I am trying to use this VFIO framework on it.

Re: [PATCH v9 03/19] vfio: platform: add the VFIO PLATFORM module to Kconfig

[Hongbo Zhang]

On 12 November 2014 18:05, bharat.bhus...@freescale.com
 wrote:
> Hi,
>
>
>
> This is not yet supported on Freescale PowerPC. I am still in process of
> upstreaming the FSL PAMU specific patches for same.
>
> Initial plan is to test with PCIe devices and then with Platform devices.
>

I see there is already driver/iommu/fsl_pamu.c, doesn't it work?
Could you explain briefly what is wrong? I've heard that the vfio pci
works on powerpc platforms
Thanks.

>
>
> Thanks
>
> -Bharat
>
>
>
> From: kvmarm-boun...@lists.cs.columbia.edu
> [mailto:kvmarm-boun...@lists.cs.columbia.edu] On Behalf Of Hongbo Zhang
> Sent: Wednesday, November 12, 2014 3:08 PM
> To: Antonios Motakis
> Cc: open list:VFIO DRIVER; will.dea...@arm.com; alex.william...@redhat.com;
> open list; io...@lists.linux-foundation.org; t...@virtualopensystems.com;
> kvm...@lists.cs.columbia.edu
> Subject: Re: [PATCH v9 03/19] vfio: platform: add the VFIO PLATFORM module
> to Kconfig
>
>
>
>
>
>
>
> On 28 October 2014 02:07, Antonios Motakis
>  wrote:
>
> Enable building the VFIO PLATFORM driver that allows to use Linux platform
> devices with VFIO.
>
> Signed-off-by: Antonios Motakis 
> ---
>  drivers/vfio/Kconfig   | 1 +
>  drivers/vfio/Makefile  | 1 +
>  drivers/vfio/platform/Kconfig  | 9 +
>  drivers/vfio/platform/Makefile | 4 
>  4 files changed, 15 insertions(+)
>  create mode 100644 drivers/vfio/platform/Kconfig
>  create mode 100644 drivers/vfio/platform/Makefile
>
> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> index a0abe04..962fb80 100644
> --- a/drivers/vfio/Kconfig
> +++ b/drivers/vfio/Kconfig
> @@ -27,3 +27,4 @@ menuconfig VFIO
>   If you don't know what to do here, say N.
>
>  source "drivers/vfio/pci/Kconfig"
> +source "drivers/vfio/platform/Kconfig"
> diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
> index 0b035b1..dadf0ca 100644
> --- a/drivers/vfio/Makefile
> +++ b/drivers/vfio/Makefile
> @@ -3,3 +3,4 @@ obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
>  obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
>  obj-$(CONFIG_VFIO_SPAPR_EEH) += vfio_spapr_eeh.o
>  obj-$(CONFIG_VFIO_PCI) += pci/
> +obj-$(CONFIG_VFIO_PLATFORM) += platform/
> diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig
> new file mode 100644
> index 000..c51af17
> --- /dev/null
> +++ b/drivers/vfio/platform/Kconfig
> @@ -0,0 +1,9 @@
> +config VFIO_PLATFORM
> +   tristate "VFIO support for platform devices"
> +   depends on VFIO && EVENTFD && ARM
>
>
>
> Hi Antonios,
>
> Is this only for ARM? how about X86 and PowerPC?
>
> On Freescale's PowerPC platform, the IOMMU is called PAMU (Peripheral Access
> Management Unit), and I am trying to use this VFIO framework on it.
>
>
>
> +   help
> + Support for platform devices with VFIO. This is required to make
> + use of platform devices present on the system using the VFIO
> + framework.
> +
> + If you don't know what to do here, say N.
> diff --git a/drivers/vfio/platform/Makefile b/drivers/vfio/platform/Makefile
> new file mode 100644
> index 000..279862b
> --- /dev/null
> +++ b/drivers/vfio/platform/Makefile
> @@ -0,0 +1,4 @@
> +
> +vfio-platform-y := vfio_platform.o vfio_platform_common.o
> +
> +obj-$(CONFIG_VFIO_PLATFORM) += vfio-platform.o
> --
> 2.1.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
--
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 v9 03/19] vfio: platform: add the VFIO PLATFORM module to Kconfig

[Hongbo Zhang]

On 28 October 2014 02:07, Antonios Motakis
 wrote:
>
> Enable building the VFIO PLATFORM driver that allows to use Linux platform
> devices with VFIO.
>
> Signed-off-by: Antonios Motakis 
> ---
>  drivers/vfio/Kconfig   | 1 +
>  drivers/vfio/Makefile  | 1 +
>  drivers/vfio/platform/Kconfig  | 9 +
>  drivers/vfio/platform/Makefile | 4 
>  4 files changed, 15 insertions(+)
>  create mode 100644 drivers/vfio/platform/Kconfig
>  create mode 100644 drivers/vfio/platform/Makefile
>
> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> index a0abe04..962fb80 100644
> --- a/drivers/vfio/Kconfig
> +++ b/drivers/vfio/Kconfig
> @@ -27,3 +27,4 @@ menuconfig VFIO
>   If you don't know what to do here, say N.
>
>  source "drivers/vfio/pci/Kconfig"
> +source "drivers/vfio/platform/Kconfig"
> diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
> index 0b035b1..dadf0ca 100644
> --- a/drivers/vfio/Makefile
> +++ b/drivers/vfio/Makefile
> @@ -3,3 +3,4 @@ obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
>  obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
>  obj-$(CONFIG_VFIO_SPAPR_EEH) += vfio_spapr_eeh.o
>  obj-$(CONFIG_VFIO_PCI) += pci/
> +obj-$(CONFIG_VFIO_PLATFORM) += platform/
> diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig
> new file mode 100644
> index 000..c51af17
> --- /dev/null
> +++ b/drivers/vfio/platform/Kconfig
> @@ -0,0 +1,9 @@
> +config VFIO_PLATFORM
> +   tristate "VFIO support for platform devices"
> +   depends on VFIO && EVENTFD && ARM

Hi Antonios,
Is this only for ARM? how about X86 and PowerPC?
On Freescale's PowerPC platform, the IOMMU is called PAMU (Peripheral
Access Management Unit), and I am trying to use this VFIO framework on
it.

>
> +   help
> + Support for platform devices with VFIO. This is required to make
> + use of platform devices present on the system using the VFIO
> + framework.
> +
> + If you don't know what to do here, say N.
> diff --git a/drivers/vfio/platform/Makefile b/drivers/vfio/platform/Makefile
> new file mode 100644
> index 000..279862b
> --- /dev/null
> +++ b/drivers/vfio/platform/Makefile
> @@ -0,0 +1,4 @@
> +
> +vfio-platform-y := vfio_platform.o vfio_platform_common.o
> +
> +obj-$(CONFIG_VFIO_PLATFORM) += vfio-platform.o
> --
> 2.1.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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 v4 8/8] DMA: Freescale: add suspend resume functions for DMA driver

[Hongbo Zhang]

On 05/21/2014 11:45 AM, Vinod Koul wrote:

On Thu, May 08, 2014 at 05:52:37PM +0800, Hongbo Zhang wrote:

On 05/07/2014 04:31 PM, Shevchenko, Andriy wrote:

On Sun, 2014-05-04 at 18:22 +0800, Hongbo Zhang wrote:

On 05/03/2014 12:46 AM, Vinod Koul wrote:

On Fri, Apr 18, 2014 at 04:17:51PM +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

This patch adds suspend resume functions for Freescale DMA driver.
.prepare callback is used to stop further descriptors from being added into the
pending queue, and also issue pending queues into execution if there is any.
.suspend callback makes sure all the pending jobs are cleaned up and all the
channels are idle, and save the mode registers.
.resume callback re-initializes the channels by restore the mode registers.

+
+static const struct dev_pm_ops fsldma_pm_ops = {
+   .prepare= fsldma_prepare,
+   .suspend= fsldma_suspend,
+   .resume = fsldma_resume,
+};

I think this is not correct. We discussed this sometime back on list. The
DMAengine drivers should use late resume and early suspend to ensure they get
suspended after clients (who should use normal ones) and resume before them


OK, will update it like this:
use .suspend to take place of current .prepare

Could you remove this at all?

Answering to your previous statements I could say that.
Device drivers (DMAc users) that don't implement .suspend callback are
on their own with troubles, you have not to care about them in the DMA
driver.

Thanks for pointing out this issue.
Then how to handle the descriptors in the pending list if there is any?
a. let them finished.
 but if the DMA user has already suspended prior DMA controller,
it is meaningless somehow and may even ask for trouble.
b. don't touch them.
 after resume these pending descriptors could be executed, it is
also meaningless because the resumed DMA user may in different state
from before being suspended.
c. delete them.
 should we do this? is is a bit crude?
d. return a non-success value
 then the whole suspend process is reversed, e.g. suspend fails.
I've looked through some dma drivers, most of them is in case b.

Yes and that makese sense.

In calssic suspend case we maybe in middle so graceful behaviour would be to for
client to PAUSE or terminate and then suspend followed by DMA suspend.
You need to rely on client doing the right thing here

OK, will resend this 6/8, 7/8 and 8/8 for another iteration, and will 
let the current 6/8 to be the last one for being reviewed and merged easier.



--
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 v4 6/8] DMA: Freescale: change descriptor release process for supporting async_tx

[Hongbo Zhang]

On 05/03/2014 12:50 AM, Vinod Koul wrote:

On Fri, Apr 18, 2014 at 04:17:49PM +0800, hongbo.zh...@freescale.com wrote:

This need review from Dan ...


Dan, could you please have a look at this? thanks.


--
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 v4 8/8] DMA: Freescale: add suspend resume functions for DMA driver

[Hongbo Zhang]

On 05/07/2014 04:31 PM, Shevchenko, Andriy wrote:

On Sun, 2014-05-04 at 18:22 +0800, Hongbo Zhang wrote:

On 05/03/2014 12:46 AM, Vinod Koul wrote:

On Fri, Apr 18, 2014 at 04:17:51PM +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

This patch adds suspend resume functions for Freescale DMA driver.
.prepare callback is used to stop further descriptors from being added into the
pending queue, and also issue pending queues into execution if there is any.
.suspend callback makes sure all the pending jobs are cleaned up and all the
channels are idle, and save the mode registers.
.resume callback re-initializes the channels by restore the mode registers.

+
+static const struct dev_pm_ops fsldma_pm_ops = {
+   .prepare= fsldma_prepare,
+   .suspend= fsldma_suspend,
+   .resume = fsldma_resume,
+};

I think this is not correct. We discussed this sometime back on list. The
DMAengine drivers should use late resume and early suspend to ensure they get
suspended after clients (who should use normal ones) and resume before them


OK, will update it like this:
use .suspend to take place of current .prepare

Could you remove this at all?

Answering to your previous statements I could say that.
Device drivers (DMAc users) that don't implement .suspend callback are
on their own with troubles, you have not to care about them in the DMA
driver.


Thanks for pointing out this issue.
Then how to handle the descriptors in the pending list if there is any?
a. let them finished.
but if the DMA user has already suspended prior DMA controller, it 
is meaningless somehow and may even ask for trouble.

b. don't touch them.
after resume these pending descriptors could be executed, it is 
also meaningless because the resumed DMA user may in different state 
from before being suspended.

c. delete them.
should we do this? is is a bit crude?
d. return a non-success value
then the whole suspend process is reversed, e.g. suspend fails.
I've looked through some dma drivers, most of them is in case b.


use .suspend_late to take place of current .suspend
use .resume_early to take place of current .resume



--
To unsubscribe from this list: send the line "unsubscribe dmaengine" 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 v4 8/8] DMA: Freescale: add suspend resume functions for DMA driver

[Hongbo Zhang]

On 05/03/2014 12:46 AM, Vinod Koul wrote:

On Fri, Apr 18, 2014 at 04:17:51PM +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

This patch adds suspend resume functions for Freescale DMA driver.
.prepare callback is used to stop further descriptors from being added into the
pending queue, and also issue pending queues into execution if there is any.
.suspend callback makes sure all the pending jobs are cleaned up and all the
channels are idle, and save the mode registers.
.resume callback re-initializes the channels by restore the mode registers.

+
+static const struct dev_pm_ops fsldma_pm_ops = {
+   .prepare= fsldma_prepare,
+   .suspend= fsldma_suspend,
+   .resume = fsldma_resume,
+};

I think this is not correct. We discussed this sometime back on list. The
DMAengine drivers should use late resume and early suspend to ensure they get
suspended after clients (who should use normal ones) and resume before them


OK, will update it like this:
use .suspend to take place of current .prepare
use .suspend_late to take place of current .suspend
use .resume_early to take place of current .resume



--
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 v4 7/8] DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave

[Hongbo Zhang]

On 05/03/2014 12:51 AM, Vinod Koul wrote:

On Fri, Apr 18, 2014 at 04:17:50PM +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

The usage of spin_lock_irqsave() is a stronger locking mechanism than is
required throughout the driver. The minimum locking required should be used
instead. Interrupts will be turned off and context will be saved, it is
unnecessary to use irqsave.

This patch changes all instances of spin_lock_irqsave() to spin_lock_bh(). All
manipulation of protected fields is done using tasklet context or weaker, which
makes spin_lock_bh() the correct choice.


This doesnt apply, perhpas due to depends on 6/8


So let's wait for the review result of 6/8.


--
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 4/8] DMA: Freescale: add fsl_dma_free_descriptor() to reduce code duplication

[Hongbo Zhang]

On 04/14/2014 09:40 PM, Andy Shevchenko wrote:

On Fri, 2014-04-11 at 16:14 +0800, Hongbo Zhang wrote:

On 04/10/2014 07:29 PM, Andy Shevchenko wrote:

On Thu, 2014-04-10 at 15:10 +0800, hongbo.zh...@freescale.com wrote:

[]


@@ -819,8 +826,7 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan 
*chan,
dma_run_dependencies(txd);
   
   	dma_descriptor_unmap(txd);

-   chan_dbg(chan, "LD %p free\n", desc);
-   dma_pool_free(chan->desc_pool, desc, txd->phys);
+   fsl_dma_free_descriptor(chan, desc);

Here is no list_del() call since it's been called in dma_do_tasklet().
What will be the result of double list_del() against the same node?

Not clear with your point.
This patch is only introducing a common fsl_dma_free_descriptor() to
reduce code duplication. And later in the patch 6/8 the
fsldma_cleanup_descriptor() is replaced by fsldma_cleanup_descriptorS().

In the last case you could have a broken kernel which will fails on
double list_del(). I think it's better to leave this one untouched and
you may remove it later.

Or move this patch after you have removed that lines.



Good catch, thank you Andy.
Yes I prefer to leave this untouched and handle it later.




--
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 6/8] DMA: Freescale: change descriptor release process for supporting async_tx

[Hongbo Zhang]

On 04/11/2014 04:00 PM, Hongbo Zhang wrote:


On 04/10/2014 07:56 PM, Andy Shevchenko wrote:

On Thu, 2014-04-10 at 15:10 +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Fix the potential risk when enable config NET_DMA and ASYNC_TX. 
Async_tx is
lack of support in current release process of dma descriptor, all 
descriptors
will be released whatever is acked or no-acked by async_tx, so there 
is a
potential race condition when dma engine is uesd by others clients 
(e.g. when

enable NET_DMA to offload TCP).

In our case, a race condition which is raised when use both of 
talitos and
dmaengine to offload xor is because napi scheduler will sync all 
pending
requests in dma channels, it affects the process of raid operations 
due to
ack_tx is not checked in fsl dma. The no-acked descriptor is freed 
which is

submitted just now, as a dependent tx, this freed descriptor trigger
BUG_ON(async_tx_test_ack(depend_tx)) in async_tx_submit().

TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf4 CPU: 0
GPR00: 0001 ecf41ca0 ee44/921a94a0 003f 0001 c00593e4 
 0001
GPR08:  a7a7a7a7 0001 045/92002 42028042 100a38d4 
ed576d98 
GPR16: ed5a11b0  2b162000 0200 046/92000 2d555000 
ed3015e8 c15a7aa0
GPR24:  c155fc40  ecb63220 ecf41d28 e47/92f640bb0 
ef640c30 ecf41ca0

NIP [c02b048c] async_tx_submit+0x6c/0x2b4
LR [c02b068c] async_tx_submit+0x26c/0x2b4
Call Trace:
[ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable)
[ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c
[ecf41d20] [c0421064] async_copy_data+0xa0/0x17c
[ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10
[ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8
[ecf41e90] [c0429080] raid5d+0x3d4/0x5b4
[ecf41f40] [c04329b8] md_thread+0x138/0x16c
[ecf41f90] [c008277c] kthread+0x8c/0x90
[ecf41ff0] [c0011630] kernel_thread+0x4c/0x68

Another modification in this patch is the change of completed 
descriptors,
there is a potential risk which caused by exception interrupt, all 
descriptors
in ld_running list are seemed completed when an interrupt raised, it 
works fine
under normal condition, but if there is an exception occured, it 
cannot work as
our excepted. Hardware should not be depend on s/w list, the right 
way is to
read current descriptor address register to find the last completed 
descriptor.
If an interrupt is raised by an error, all descriptors in ld_running 
should not
be seemed finished, or these unfinished descriptors in ld_running 
will be

released wrongly.

A simple way to reproduce:
Enable dmatest first, then insert some bad descriptors which can 
trigger
Programming Error interrupts before the good descriptors. Last, the 
good
descriptors will be freed before they are processsed because of the 
exception

intrerrupt.

Note: the bad descriptors are only for simulating an exception 
interrupt.  This

case can illustrate the potential risk in current fsl-dma very well.

Signed-off-by: Hongbo Zhang 
Signed-off-by: Qiang Liu 
Signed-off-by: Ira W. Snyder 
---
  drivers/dma/fsldma.c |  195 
--

  drivers/dma/fsldma.h |   17 -
  2 files changed, 158 insertions(+), 54 deletions(-)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 968877f..f8eee60 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -459,6 +459,87 @@ static struct fsl_desc_sw 
*fsl_dma_alloc_descriptor(struct fsldma_chan *chan)

  }
/**
+ * fsldma_clean_completed_descriptor - free all descriptors which
+ * has been completed and acked

IIRC the summary should be oneliner.
Check the rest of the code as well.


I don't think so.
See this Documentation/kernel-doc-nano-HOWTO.txt, and you can find 
this sentence "The short description following the subject can span 
multiple lines"



+ * @chan: Freescale DMA channel
+ *
+ * This function is used on all completed and acked descriptors.
+ * All descriptors should only be freed in this function.
+ */
+static void fsldma_clean_completed_descriptor(struct fsldma_chan 
*chan)

+{
+struct fsl_desc_sw *desc, *_desc;
+
+/* Run the callback for each descriptor, in order */
+list_for_each_entry_safe(desc, _desc, &chan->ld_completed, node)
+if (async_tx_test_ack(&desc->async_tx))
+fsl_dma_free_descriptor(chan, desc);
+}
+
+/**
+ * fsldma_run_tx_complete_actions - cleanup a single link descriptor
+ * @chan: Freescale DMA channel
+ * @desc: descriptor to cleanup and free
+ * @cookie: Freescale DMA transaction identifier
+ *
+ * This function is used on a descriptor which has been executed by 
the DMA

+ * controller. It will run any callbacks, submit any dependencies.
+ */
+static dma_cookie_t fsldma_run_tx_complete_actions(struct 
fsldma_chan *chan,

+struct fsl_desc_sw *desc, dma_cookie_t cookie)

Maybe you could use cookie as local variable?


Yes.. it doesn't seem good to set a value to input paramet

Re: [PATCH v3 4/8] DMA: Freescale: add fsl_dma_free_descriptor() to reduce code duplication

[Hongbo Zhang]

On 04/10/2014 07:29 PM, Andy Shevchenko wrote:

On Thu, 2014-04-10 at 15:10 +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

There are several places where descriptors are freed using identical code.
This patch puts this code into a function to reduce code duplication.

Signed-off-by: Hongbo Zhang 
Signed-off-by: Qiang Liu 
---
  drivers/dma/fsldma.c |   30 ++
  1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index b71cc04..b5a0ffa 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -418,6 +418,19 @@ static dma_cookie_t fsl_dma_tx_submit(struct 
dma_async_tx_descriptor *tx)
  }
  
  /**

+ * fsl_dma_free_descriptor - Free descriptor from channel's DMA pool.
+ * @chan : Freescale DMA channel
+ * @desc: descriptor to be freed
+ */
+static void fsl_dma_free_descriptor(struct fsldma_chan *chan,
+   struct fsl_desc_sw *desc)
+{
+   list_del(&desc->node);
+   chan_dbg(chan, "LD %p free\n", desc);
+   dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
+}
+
+/**
   * fsl_dma_alloc_descriptor - Allocate descriptor from channel's DMA pool.
   * @chan : Freescale DMA channel
   *
@@ -489,11 +502,8 @@ static void fsldma_free_desc_list(struct fsldma_chan *chan,
  {
struct fsl_desc_sw *desc, *_desc;
  
-	list_for_each_entry_safe(desc, _desc, list, node) {

-   list_del(&desc->node);
-   chan_dbg(chan, "LD %p free\n", desc);
-   dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
-   }
+   list_for_each_entry_safe(desc, _desc, list, node)
+   fsl_dma_free_descriptor(chan, desc);
  }
  
  static void fsldma_free_desc_list_reverse(struct fsldma_chan *chan,

@@ -501,11 +511,8 @@ static void fsldma_free_desc_list_reverse(struct 
fsldma_chan *chan,
  {
struct fsl_desc_sw *desc, *_desc;
  
-	list_for_each_entry_safe_reverse(desc, _desc, list, node) {

-   list_del(&desc->node);
-   chan_dbg(chan, "LD %p free\n", desc);
-   dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
-   }
+   list_for_each_entry_safe_reverse(desc, _desc, list, node)
+   fsl_dma_free_descriptor(chan, desc);
  }
  
  /**

@@ -819,8 +826,7 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan 
*chan,
dma_run_dependencies(txd);
  
  	dma_descriptor_unmap(txd);

-   chan_dbg(chan, "LD %p free\n", desc);
-   dma_pool_free(chan->desc_pool, desc, txd->phys);
+   fsl_dma_free_descriptor(chan, desc);

Here is no list_del() call since it's been called in dma_do_tasklet().
What will be the result of double list_del() against the same node?


Not clear with your point.
This patch is only introducing a common fsl_dma_free_descriptor() to 
reduce code duplication. And later in the patch 6/8 the 
fsldma_cleanup_descriptor() is replaced by fsldma_cleanup_descriptorS().



  }
  
  /**






--
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 6/8] DMA: Freescale: change descriptor release process for supporting async_tx

[Hongbo Zhang]

On 04/10/2014 07:56 PM, Andy Shevchenko wrote:

On Thu, 2014-04-10 at 15:10 +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Fix the potential risk when enable config NET_DMA and ASYNC_TX. Async_tx is
lack of support in current release process of dma descriptor, all descriptors
will be released whatever is acked or no-acked by async_tx, so there is a
potential race condition when dma engine is uesd by others clients (e.g. when
enable NET_DMA to offload TCP).

In our case, a race condition which is raised when use both of talitos and
dmaengine to offload xor is because napi scheduler will sync all pending
requests in dma channels, it affects the process of raid operations due to
ack_tx is not checked in fsl dma. The no-acked descriptor is freed which is
submitted just now, as a dependent tx, this freed descriptor trigger
BUG_ON(async_tx_test_ack(depend_tx)) in async_tx_submit().

TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf4 CPU: 0
GPR00: 0001 ecf41ca0 ee44/921a94a0 003f 0001 c00593e4  
0001
GPR08:  a7a7a7a7 0001 045/92002 42028042 100a38d4 ed576d98 

GPR16: ed5a11b0  2b162000 0200 046/92000 2d555000 ed3015e8 
c15a7aa0
GPR24:  c155fc40  ecb63220 ecf41d28 e47/92f640bb0 ef640c30 
ecf41ca0
NIP [c02b048c] async_tx_submit+0x6c/0x2b4
LR [c02b068c] async_tx_submit+0x26c/0x2b4
Call Trace:
[ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable)
[ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c
[ecf41d20] [c0421064] async_copy_data+0xa0/0x17c
[ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10
[ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8
[ecf41e90] [c0429080] raid5d+0x3d4/0x5b4
[ecf41f40] [c04329b8] md_thread+0x138/0x16c
[ecf41f90] [c008277c] kthread+0x8c/0x90
[ecf41ff0] [c0011630] kernel_thread+0x4c/0x68

Another modification in this patch is the change of completed descriptors,
there is a potential risk which caused by exception interrupt, all descriptors
in ld_running list are seemed completed when an interrupt raised, it works fine
under normal condition, but if there is an exception occured, it cannot work as
our excepted. Hardware should not be depend on s/w list, the right way is to
read current descriptor address register to find the last completed descriptor.
If an interrupt is raised by an error, all descriptors in ld_running should not
be seemed finished, or these unfinished descriptors in ld_running will be
released wrongly.

A simple way to reproduce:
Enable dmatest first, then insert some bad descriptors which can trigger
Programming Error interrupts before the good descriptors. Last, the good
descriptors will be freed before they are processsed because of the exception
intrerrupt.

Note: the bad descriptors are only for simulating an exception interrupt.  This
case can illustrate the potential risk in current fsl-dma very well.

Signed-off-by: Hongbo Zhang 
Signed-off-by: Qiang Liu 
Signed-off-by: Ira W. Snyder 
---
  drivers/dma/fsldma.c |  195 --
  drivers/dma/fsldma.h |   17 -
  2 files changed, 158 insertions(+), 54 deletions(-)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 968877f..f8eee60 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -459,6 +459,87 @@ static struct fsl_desc_sw *fsl_dma_alloc_descriptor(struct 
fsldma_chan *chan)
  }
  
  /**

+ * fsldma_clean_completed_descriptor - free all descriptors which
+ * has been completed and acked

IIRC the summary should be oneliner.
Check the rest of the code as well.


I don't think so.
See this Documentation/kernel-doc-nano-HOWTO.txt, and you can find this 
sentence "The short description following the subject can span multiple 
lines"



+ * @chan: Freescale DMA channel
+ *
+ * This function is used on all completed and acked descriptors.
+ * All descriptors should only be freed in this function.
+ */
+static void fsldma_clean_completed_descriptor(struct fsldma_chan *chan)
+{
+   struct fsl_desc_sw *desc, *_desc;
+
+   /* Run the callback for each descriptor, in order */
+   list_for_each_entry_safe(desc, _desc, &chan->ld_completed, node)
+   if (async_tx_test_ack(&desc->async_tx))
+   fsl_dma_free_descriptor(chan, desc);
+}
+
+/**
+ * fsldma_run_tx_complete_actions - cleanup a single link descriptor
+ * @chan: Freescale DMA channel
+ * @desc: descriptor to cleanup and free
+ * @cookie: Freescale DMA transaction identifier
+ *
+ * This function is used on a descriptor which has been executed by the DMA
+ * controller. It will run any callbacks, submit any dependencies.
+ */
+static dma_cookie_t fsldma_run_tx_complete_actions(struct fsldma_chan *chan,
+   struct fsl_desc_sw *desc, dma_cookie_t cookie)

Maybe you could use cookie as local variable?


Yes.. it doesn't seem good to set a value to input parameter.


+{
+   struct dma_async_tx_descriptor 

Re: [PATCH v3 8/8] DMA: Freescale: add suspend resume functions for DMA driver

[Hongbo Zhang]

On 04/10/2014 08:05 PM, Andy Shevchenko wrote:

On Thu, 2014-04-10 at 15:10 +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

This patch adds suspend resume functions for Freescale DMA driver.
.prepare callback is used to stop further descriptors from being added into the
pending queue, and also issue pending queues into execution if there is any.
.suspend callback makes sure all the pending jobs are cleaned up and all the
channels are idle, and save the mode registers.
.resume callback re-initializes the channels by restore the mode registers.

Like we discussed with Vinod [1] the DMA controller drivers should go to
suspend after users and come back before them.

After you reconsider this point the patch logic might be modified a lot.


Looked through that discussions, I really had thought such problem for a 
while.


For the dma-controller and dma-user, we don't know which .suspend 
callback is executed firstly, so the idea would be: which ever is called 
earlier, the dma-controller driver suspend function should be as  robust 
as possible.


It is better the dma-user .suspend callback is called earlier, some 
clean-ups should be done here such as stop dma request, but we cannot 
make sure every dma-user has a .suspend callback, some dma-users don't 
pay attention to or even don't care the suspend at all for some reason.


So even the suspend_late is used, we cannot assume every dma-user's 
activity is cleaned up neatly, dma-controller driver should be robust to 
handle this gracefully, that was my design target.


In the prepare() function, clean up the pending queue and stop receive 
new coming request, and in the suspend() function I do some register 
saving works. I don't think my code needs to be modified much, a 
possible change according to Vinod's idea would be:

use .suspend instead of my current .prepare
use . suspend_late instead of my current .suspend
e.g. postpone all my functions to be executed later, this method works 
and seems better for client/low-level module drivers.


The reason I didn't use the above functions was that I had read this 
Documentation/power/devices.txt, search the definitions of prepare, 
suspend, suspend_late and suspend_noirq, I think my usage complies with 
that definitions strictly, I can do the modification above if the 
maintainer like and if nobody says I break this law.



(Moreover, you abuse your own position to use only setters/getters to
access to the DMAc registers)


My shame, I will update it.
(reason is the setters/getters patch isn't merged into our internal 
tree, but this suspend patch has been done. I am trying to sync our 
internal kernel and the community now)



[1] http://www.spinics.net/lists/kernel/msg1650974.html



Signed-off-by: Hongbo Zhang 
---
  drivers/dma/fsldma.c |  100 ++
  drivers/dma/fsldma.h |   16 
  2 files changed, 116 insertions(+)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index c9bf54a..d6da222 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -400,6 +400,14 @@ static dma_cookie_t fsl_dma_tx_submit(struct 
dma_async_tx_descriptor *tx)
  
  	spin_lock_bh(&chan->desc_lock);
  
+#ifdef CONFIG_PM

+   if (unlikely(chan->pm_state != RUNNING)) {
+   chan_dbg(chan, "cannot submit due to suspend\n");
+   spin_unlock_bh(&chan->desc_lock);
+   return -1;
+   }
+#endif
+
/*
 * assign cookies to all of the software descriptors
 * that make up this transaction
@@ -1311,6 +1319,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
INIT_LIST_HEAD(&chan->ld_running);
INIT_LIST_HEAD(&chan->ld_completed);
chan->idle = true;
+#ifdef CONFIG_PM
+   chan->pm_state = RUNNING;
+#endif
  
  	chan->common.device = &fdev->common;

dma_cookie_init(&chan->common);
@@ -1450,6 +1461,92 @@ static int fsldma_of_remove(struct platform_device *op)
return 0;
  }
  
+#ifdef CONFIG_PM

+static int fsldma_prepare(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct fsldma_device *fdev = platform_get_drvdata(pdev);
+   struct fsldma_chan *chan;
+   int i;
+
+   for (i = 0; i < FSL_DMA_MAX_CHANS_PER_DEVICE; i++) {
+   chan = fdev->chan[i];
+   if (!chan)
+   continue;
+
+   spin_lock_bh(&chan->desc_lock);
+   chan->pm_state = SUSPENDING;
+   if (!list_empty(&chan->ld_pending))
+   fsl_chan_xfer_ld_queue(chan);
+   spin_unlock_bh(&chan->desc_lock);
+   }
+
+   return 0;
+}
+
+static int fsldma_suspend(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct fsldma_device *fdev = 

Re: [PATCH v3 2/8] DMA: Freescale: unify register access methods

[Hongbo Zhang]

On 04/10/2014 04:46 PM, David Laight wrote:

From: hongbo.zh...@freescale.com

Methods of accessing DMA contorller registers are inconsistent, some registers

^^


Thanks.
sorry, that it a typo.
I would wait to see if there are other defects I have to correct, if yes 
I can send a new iteration including this update, if no I would like to 
know if the maintainer can do me the favor to correct it when merging 
this patch, if still no, I will send a new iteration for this then.



are accessed by DMA_IN/OUT directly, while others are accessed by functions
get/set_* which are wrappers of DMA_IN/OUT, and even for the BCR register, it
is read by get_bcr but written by DMA_OUT.
This patch unifies the inconsistent methods, all registers are accessed by
get/set_* now.

David





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

[PATCH v3 0/8] DMA: Freescale: driver cleanups and enhancements

[Hongbo Zhang]

Sorry, forgot the cover letter, plus it here.


From: Hongbo Zhang 
Date: Thu, 10 Apr 2014 15:16:31 +0800
Subject: [PATCH v3 0/8] DMA: Freescale: driver cleanups and enhancements

Hi Vinod Koul,
Please have a look at the v3 patch set.

v2 -> v3 change:
Only add "chan->pm_state = RUNNING" for patch[8/8].

v1 -> v2 change:
The only one change is introducing a new patch[1/7] to remove the 
unnecessary

macro FSL_DMA_LD_DEBUG, thus the total patches number is 8 now (was 7)

Hongbo Zhang (8):
  DMA: Freescale: remove the unnecessary FSL_DMA_LD_DEBUG
  DMA: Freescale: unify register access methods
  DMA: Freescale: remove attribute DMA_INTERRUPT of dmaengine
  DMA: Freescale: add fsl_dma_free_descriptor() to reduce code
duplication
  DMA: Freescale: move functions to avoid forward declarations
  DMA: Freescale: change descriptor release process for supporting
async_tx
  DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave
  DMA: Freescale: add suspend resume functions for DMA driver

 drivers/dma/fsldma.c |  591 
--

 drivers/dma/fsldma.h |   33 ++-
 2 files changed, 409 insertions(+), 215 deletions(-)




--
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 8/8] DMA: Freescale: add suspend resume functions for DMA driver

[Hongbo Zhang]

On 04/04/2014 11:27 AM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

This patch adds suspend resume functions for Freescale DMA driver.
.prepare callback is used to stop further descriptors from being added into the
pending queue, and also issue pending queues into execution if there is any.
.suspend callback makes sure all the pending jobs are cleaned up and all the
channels are idle, and save the mode registers.
.resume callback re-initializes the channels by restore the mode registers.

Signed-off-by: Hongbo Zhang 
---
  drivers/dma/fsldma.c |   99 ++
  drivers/dma/fsldma.h |   16 
  2 files changed, 115 insertions(+)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index c9bf54a..91482d2 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -400,6 +400,14 @@ static dma_cookie_t fsl_dma_tx_submit(struct 
dma_async_tx_descriptor *tx)
  
  	spin_lock_bh(&chan->desc_lock);
  
+#ifdef CONFIG_PM

+   if (unlikely(chan->pm_state != RUNNING)) {
+   chan_dbg(chan, "cannot submit due to suspend\n");
+   spin_unlock_bh(&chan->desc_lock);
+   return -1;
+   }
+#endif
+
/*
 * assign cookies to all of the software descriptors
 * that make up this transaction
@@ -1311,6 +1319,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
INIT_LIST_HEAD(&chan->ld_running);
INIT_LIST_HEAD(&chan->ld_completed);
chan->idle = true;
+#ifdef CONFIG_PM
+   chan->pm_state = RUNNING;
+#endif
  
  	chan->common.device = &fdev->common;

dma_cookie_init(&chan->common);
@@ -1450,6 +1461,91 @@ static int fsldma_of_remove(struct platform_device *op)
return 0;
  }
  
+#ifdef CONFIG_PM

+static int fsldma_prepare(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct fsldma_device *fdev = platform_get_drvdata(pdev);
+   struct fsldma_chan *chan;
+   int i;
+
+   for (i = 0; i < FSL_DMA_MAX_CHANS_PER_DEVICE; i++) {
+   chan = fdev->chan[i];
+   if (!chan)
+   continue;
+
+   spin_lock_bh(&chan->desc_lock);
+   chan->pm_state = SUSPENDING;
+   if (!list_empty(&chan->ld_pending))
+   fsl_chan_xfer_ld_queue(chan);
+   spin_unlock_bh(&chan->desc_lock);
+   }
+
+   return 0;
+}
+
+static int fsldma_suspend(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct fsldma_device *fdev = platform_get_drvdata(pdev);
+   struct fsldma_chan *chan;
+   int i;
+
+   for (i = 0; i < FSL_DMA_MAX_CHANS_PER_DEVICE; i++) {
+   chan = fdev->chan[i];
+   if (!chan)
+   continue;
+
+   spin_lock_bh(&chan->desc_lock);
+   if (!chan->idle)
+   goto out;
+   chan->regs_save.mr = DMA_IN(chan, &chan->regs->mr, 32);
+   chan->pm_state = SUSPENDED;
+   spin_unlock_bh(&chan->desc_lock);
+   }
+   return 0;
+
+out:
+   for (; i >= 0; i--) {
+   chan = fdev->chan[i];
+   if (!chan)
+   continue;


the pm_state should be restored too, e.g.
chan->pm_state = RUNNING;
I will send new iteration for adding this.


+   spin_unlock_bh(&chan->desc_lock);
+   }
+   return -EBUSY;
+}
+
+static int fsldma_resume(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct fsldma_device *fdev = platform_get_drvdata(pdev);
+   struct fsldma_chan *chan;
+   u32 mode;
+   int i;
+
+   for (i = 0; i < FSL_DMA_MAX_CHANS_PER_DEVICE; i++) {
+   chan = fdev->chan[i];
+   if (!chan)
+   continue;
+
+   spin_lock_bh(&chan->desc_lock);
+   mode = chan->regs_save.mr
+   & ~FSL_DMA_MR_CS & ~FSL_DMA_MR_CC & ~FSL_DMA_MR_CA;
+   DMA_OUT(chan, &chan->regs->mr, mode, 32);
+   chan->pm_state = RUNNING;
+   spin_unlock_bh(&chan->desc_lock);
+   }
+
+   return 0;
+}
+
+static const struct dev_pm_ops fsldma_pm_ops = {
+   .prepare= fsldma_prepare,
+   .suspend= fsldma_suspend,
+   .resume = fsldma_resume,
+};
+#endif
+
  static const struct of_device_id fsldma_of_ids[] = {
{ .compatible = "fsl,elo3-dma", },
{ .compatible = "fsl,eloplus-dma", },
@@ -1462,6 +1558,9 @@ static struct platform_driver fsldma_of_driver = {
.name = "fsl-elo-dma",
.owner = THIS_MODULE,
  

Re: [PATCH 3/7] DMA: Freescale: add fsl_dma_free_descriptor() to reduce code duplication

[Hongbo Zhang]

On 03/28/2014 11:44 AM, Hongbo Zhang wrote:


On 03/11/2014 07:06 PM, Vinod Koul wrote:
On Thu, Jan 16, 2014 at 01:47:22PM +0800, hongbo.zh...@freescale.com 
wrote:

From: Hongbo Zhang 

There are several places where descriptors are freed using identical 
code.

This patch puts this code into a function to reduce code duplication.

Signed-off-by: Hongbo Zhang 
Signed-off-by: Qiang Liu 
---
  drivers/dma/fsldma.c |   38 --
  1 file changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 95236e6..ad73538 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -418,6 +418,21 @@ static dma_cookie_t fsl_dma_tx_submit(struct 
dma_async_tx_descriptor *tx)

  }
/**
+ * fsl_dma_free_descriptor - Free descriptor from channel's DMA pool.
+ * @chan : Freescale DMA channel
+ * @desc: descriptor to be freed
+ */
+static void fsl_dma_free_descriptor(struct fsldma_chan *chan,
+struct fsl_desc_sw *desc)
+{
+list_del(&desc->node);
+#ifdef FSL_DMA_LD_DEBUG
+chan_dbg(chan, "LD %p free\n", desc);
+#endif
why not wrap the define stuff in the defination of chan_dbg rather 
than its

usage :(



OK, I will fix it by another separate patch.
Thanks.



Think it again, I'd like to remove the FSL_DMA_LD_DEBUG usage, because 
the chan_dbg is a wrapper of dev_dbg, we do have macro to switch on/off 
dev_dbg, and most of other codes are calling chan_dbg directly without 
FSL_DMA_LD_DEBUG, the FSL_DMA_LD_DEBUG only shows up 3 times unnecessarily.



___
Linuxppc-dev mailing list
linuxppc-...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev




--
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 6/7] DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave

[Hongbo Zhang]

On 04/03/2014 12:35 AM, Vinod Koul wrote:

On Mon, Mar 31, 2014 at 12:08:55PM +0800, Hongbo Zhang wrote:

On 03/29/2014 09:45 PM, Vinod Koul wrote:

On Fri, Mar 28, 2014 at 02:33:37PM +0800, Hongbo Zhang wrote:

On 03/26/2014 03:01 PM, Vinod Koul wrote:

On Thu, 2014-01-16 at 13:47 +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

The usage of spin_lock_irqsave() is a stronger locking mechanism than is
required throughout the driver. The minimum locking required should be used
instead. Interrupts will be turned off and context will be saved, it is
unnecessary to use irqsave.

This patch changes all instances of spin_lock_irqsave() to spin_lock_bh(). All
manipulation of protected fields is done using tasklet context or weaker, which
makes spin_lock_bh() the correct choice.

  /**
@@ -1124,11 +1120,10 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
  static void dma_do_tasklet(unsigned long data)
  {
struct fsldma_chan *chan = (struct fsldma_chan *)data;
-   unsigned long flags;
chan_dbg(chan, "tasklet entry\n");
-   spin_lock_irqsave(&chan->desc_lock, flags);
+   spin_lock_bh(&chan->desc_lock);

okay here is the problem :(

You moved to _bh variant. So if you grab the lock in rest of the code
and irq gets triggered then here we will be spinning to grab the lock.
So effectively you made right locking solution into deadlock situation!

If the rest code grabs lock by spin_lock_bh(), and if irq raised,
the tasklet could not be executed because it has been disabled by
the _bh variant function.

yes if you are accessing resources only in tasklet and rest of the code, then
_bh variant works well. The problem here is usage in irq handler


The name dma_do_tasklet may mislead, it is tasklet handler, not irq
handler, not a trigger to load tasklet.
the irq handler is fsldma_chan_irq, and I don't use lock in it.

sorry my bad, i misread this as code in fsldma_chan_irq() insteadof
dma_do_tasklet(). In that case patch is doing the right thing.



OK, so I will send a v2 series with only updating 3/7 soon.




--
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 6/7] DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave

[Hongbo Zhang]

On 03/29/2014 09:45 PM, Vinod Koul wrote:

On Fri, Mar 28, 2014 at 02:33:37PM +0800, Hongbo Zhang wrote:

On 03/26/2014 03:01 PM, Vinod Koul wrote:

On Thu, 2014-01-16 at 13:47 +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

The usage of spin_lock_irqsave() is a stronger locking mechanism than is
required throughout the driver. The minimum locking required should be used
instead. Interrupts will be turned off and context will be saved, it is
unnecessary to use irqsave.

This patch changes all instances of spin_lock_irqsave() to spin_lock_bh(). All
manipulation of protected fields is done using tasklet context or weaker, which
makes spin_lock_bh() the correct choice.




  /**
@@ -1124,11 +1120,10 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
  static void dma_do_tasklet(unsigned long data)
  {
struct fsldma_chan *chan = (struct fsldma_chan *)data;
-   unsigned long flags;
chan_dbg(chan, "tasklet entry\n");
-   spin_lock_irqsave(&chan->desc_lock, flags);
+   spin_lock_bh(&chan->desc_lock);

okay here is the problem :(

You moved to _bh variant. So if you grab the lock in rest of the code
and irq gets triggered then here we will be spinning to grab the lock.
So effectively you made right locking solution into deadlock situation!

If the rest code grabs lock by spin_lock_bh(), and if irq raised,
the tasklet could not be executed because it has been disabled by
the _bh variant function.

yes if you are accessing resources only in tasklet and rest of the code, then
_bh variant works well. The problem here is usage in irq handler



The name dma_do_tasklet may mislead, it is tasklet handler, not irq 
handler, not a trigger to load tasklet.

the irq handler is fsldma_chan_irq, and I don't use lock in it.

If it is the problem, I would like to change dma_do_tasklet to 
dma_tasklet to eliminate misleading.




--
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 6/7] DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave

[Hongbo Zhang]

On 03/26/2014 03:01 PM, Vinod Koul wrote:

On Thu, 2014-01-16 at 13:47 +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

The usage of spin_lock_irqsave() is a stronger locking mechanism than is
required throughout the driver. The minimum locking required should be used
instead. Interrupts will be turned off and context will be saved, it is
unnecessary to use irqsave.

This patch changes all instances of spin_lock_irqsave() to spin_lock_bh(). All
manipulation of protected fields is done using tasklet context or weaker, which
makes spin_lock_bh() the correct choice.

Signed-off-by: Hongbo Zhang 
Signed-off-by: Qiang Liu 
---
  drivers/dma/fsldma.c |   25 ++---
  1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index bbace54..437794e 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -396,10 +396,9 @@ static dma_cookie_t fsl_dma_tx_submit(struct 
dma_async_tx_descriptor *tx)
struct fsldma_chan *chan = to_fsl_chan(tx->chan);
struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
struct fsl_desc_sw *child;
-   unsigned long flags;
dma_cookie_t cookie = -EINVAL;
  
-	spin_lock_irqsave(&chan->desc_lock, flags);

+   spin_lock_bh(&chan->desc_lock);
  
  	/*

 * assign cookies to all of the software descriptors
@@ -412,7 +411,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct 
dma_async_tx_descriptor *tx)
/* put this transaction onto the tail of the pending queue */
append_ld_queue(chan, desc);
  
-	spin_unlock_irqrestore(&chan->desc_lock, flags);

+   spin_unlock_bh(&chan->desc_lock);
  
  	return cookie;

  }
@@ -731,15 +730,14 @@ static void fsldma_free_desc_list_reverse(struct 
fsldma_chan *chan,
  static void fsl_dma_free_chan_resources(struct dma_chan *dchan)
  {
struct fsldma_chan *chan = to_fsl_chan(dchan);
-   unsigned long flags;
  
  	chan_dbg(chan, "free all channel resources\n");

-   spin_lock_irqsave(&chan->desc_lock, flags);
+   spin_lock_bh(&chan->desc_lock);
fsldma_cleanup_descriptors(chan);
fsldma_free_desc_list(chan, &chan->ld_pending);
fsldma_free_desc_list(chan, &chan->ld_running);
fsldma_free_desc_list(chan, &chan->ld_completed);
-   spin_unlock_irqrestore(&chan->desc_lock, flags);
+   spin_unlock_bh(&chan->desc_lock);
  
  	dma_pool_destroy(chan->desc_pool);

chan->desc_pool = NULL;
@@ -958,7 +956,6 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
  {
struct dma_slave_config *config;
struct fsldma_chan *chan;
-   unsigned long flags;
int size;
  
  	if (!dchan)

@@ -968,7 +965,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
  
  	switch (cmd) {

case DMA_TERMINATE_ALL:
-   spin_lock_irqsave(&chan->desc_lock, flags);
+   spin_lock_bh(&chan->desc_lock);
  
  		/* Halt the DMA engine */

dma_halt(chan);
@@ -979,7 +976,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
fsldma_free_desc_list(chan, &chan->ld_completed);
chan->idle = true;
  
-		spin_unlock_irqrestore(&chan->desc_lock, flags);

+   spin_unlock_bh(&chan->desc_lock);
return 0;
  
  	case DMA_SLAVE_CONFIG:

@@ -1021,11 +1018,10 @@ static int fsl_dma_device_control(struct dma_chan 
*dchan,
  static void fsl_dma_memcpy_issue_pending(struct dma_chan *dchan)
  {
struct fsldma_chan *chan = to_fsl_chan(dchan);
-   unsigned long flags;
  
-	spin_lock_irqsave(&chan->desc_lock, flags);

+   spin_lock_bh(&chan->desc_lock);
fsl_chan_xfer_ld_queue(chan);
-   spin_unlock_irqrestore(&chan->desc_lock, flags);
+   spin_unlock_bh(&chan->desc_lock);
  }
  
  /**

@@ -1124,11 +1120,10 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
  static void dma_do_tasklet(unsigned long data)
  {
struct fsldma_chan *chan = (struct fsldma_chan *)data;
-   unsigned long flags;
  
  	chan_dbg(chan, "tasklet entry\n");
  
-	spin_lock_irqsave(&chan->desc_lock, flags);

+   spin_lock_bh(&chan->desc_lock);

okay here is the problem :(

You moved to _bh variant. So if you grab the lock in rest of the code
and irq gets triggered then here we will be spinning to grab the lock.
So effectively you made right locking solution into deadlock situation!


If the rest code grabs lock by spin_lock_bh(), and if irq raised, the 
tasklet could not be executed because it has been disabled by the _bh 
variant function.

Right?

  
  	/* the hardware is now idle and ready for more */

chan->idle = true;
@@ -1136,7 +1131,7 @@ static void dma_do_tasklet(unsigned long data)
/* Run all cleanup for descriptors which have been

Re: [PATCH 3/7] DMA: Freescale: add fsl_dma_free_descriptor() to reduce code duplication

[Hongbo Zhang]

On 03/11/2014 07:06 PM, Vinod Koul wrote:

On Thu, Jan 16, 2014 at 01:47:22PM +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

There are several places where descriptors are freed using identical code.
This patch puts this code into a function to reduce code duplication.

Signed-off-by: Hongbo Zhang 
Signed-off-by: Qiang Liu 
---
  drivers/dma/fsldma.c |   38 --
  1 file changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 95236e6..ad73538 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -418,6 +418,21 @@ static dma_cookie_t fsl_dma_tx_submit(struct 
dma_async_tx_descriptor *tx)
  }
  
  /**

+ * fsl_dma_free_descriptor - Free descriptor from channel's DMA pool.
+ * @chan : Freescale DMA channel
+ * @desc: descriptor to be freed
+ */
+static void fsl_dma_free_descriptor(struct fsldma_chan *chan,
+   struct fsl_desc_sw *desc)
+{
+   list_del(&desc->node);
+#ifdef FSL_DMA_LD_DEBUG
+   chan_dbg(chan, "LD %p free\n", desc);
+#endif

why not wrap the define stuff in the defination of chan_dbg rather than its
usage :(



OK, I will fix it by another separate patch.
Thanks.



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

Re: [PATCH 0/7] DMA: Freescale: driver cleanups and enhancements

[Hongbo Zhang]

Hi Vinod,
How about these patches?
Thanks.


On 01/16/2014 01:47 PM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Hi Vinod Koul and Dan Williams,
Please have a look at these patches.

Note that patch 2~6 had beed sent out for upstream before, but were together
with other storage patches at that time, that was not easy for being reviewed
and merged, so I send them separately this time.

Thanks.

Hongbo Zhang (7):
   DMA: Freescale: unify register access methods
   DMA: Freescale: remove attribute DMA_INTERRUPT of dmaengine
   DMA: Freescale: add fsl_dma_free_descriptor() to reduce code
 duplication
   DMA: Freescale: move functions to avoid forward declarations
   DMA: Freescale: change descriptor release process for supporting
 async_tx
   DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave
   DMA: Freescale: add suspend resume functions for DMA driver

  drivers/dma/fsldma.c |  592 --
  drivers/dma/fsldma.h |   33 ++-
  2 files changed, 412 insertions(+), 213 deletions(-)





--
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 resend 1/2] Documentation: move all DMA documentations into Documentaion/dma

[Hongbo Zhang]

On 01/20/2014 12:29 PM, Vinod Koul wrote:

On Sat, Jan 18, 2014 at 11:59:13AM -0600, Rob Landley wrote:

On 01/16/14 09:59, Vinod Koul wrote:

On Thu, Jan 16, 2014 at 06:50:04PM +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Since there are already seven DMA documentations under the top Documentation/,
it is better to create one dedicated directory for them.

Well the problem is that not everything is same. Some of these mean how to use
dma mapping API, couple are related to dmaengine, so clubing everything into
"dma" doesnt sound right to me!

Putting everything in the world in the top level directory isn't all
flowers and kittens either.

Where would be a _better_ place to move one of those files to?

As pointed mostly things dma* are dma-mapping and dmaengine, so would apt
that we move to two folders, unless i overlooked and assumed everything else is
dma-mapping!


Understand your concern, dma-mapping and dmaengine are different, but 
they are all about dma, a general dma folder can include all dma related 
files. An example is Documentation/power, so many kinds of power related 
files go there.

Anyway, this is my point, it is up to you maintainers.


--
~Vinod






--
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 1/2] Documentation: move all DMA documentations into Documentaion/dma

[Hongbo Zhang]

Learned, will try, I didn't like this long patch either.
Thanks.


On 01/16/2014 06:43 PM, Andy Shevchenko wrote:

On Thu, 2014-01-16 at 18:37 +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Since there are already seven DMA documentations under the top Documentation/,
it is better to create one dedicated directory for them.


Can you rebuild this with -M -C and resend?

P.S. hint for future is to use -M -C when you rename files.





--
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] DTS: DMA: Fix DMA3 interrupts

[Hongbo Zhang]

On 12/11/2013 02:33 AM, Scott Wood wrote:

On Tue, 2013-12-10 at 18:33 +0800, Hongbo Zhang wrote:

Scott,
This issue is due to the non-continuous MPIC register, I think there is
two ways to fix it.

The first one is as what we are discussing, in fact the Bman/Qman DT
author had introduced this way, and I had to follow it, it is a trick,
adding 208 is a bit ugly I think, and even difficult to explain it to
customers etc, but this way changes less codes.

The second one is editing MPIC related codes without adding 208 to high
interrupts. The point of translate interrupt number to MPIC register
address is a so called 'isu' mechanism, we can do like the following
example codes, then the tricky adding 208 isn't needed any more.

Which one do you prefer?
In fact I myself prefer the second, if the idea is acceptable, I will
send a patch instead of this one. (and also alone with the internal
patch decreasing 208 for the Bman/Qman)

void __init corenet_ds_pic_init(void)
{
  ..

  mpic = mpic_alloc(NULL, 0, flags, 0, 512, "OpenPIC");
  BUG_ON(mpic == NULL);

// Add this start
  for (i = 0; i < 17; i++) {
  if (i < 11)
  addr_off = 0x1 + 0x20 * 16 * i;
  else
  addr_off = 0x13000 + 0x20 * 16 * (i - 11);  /* scape the
address not for interrupts */
  mpic_assign_isu(mpic, i, mpic->paddr + addr_off);
  }
// Add this end

  mpic_init(mpic);
}

NACK

We already have a binding that states that the interrupt number is based
on the register offset, rather than whatever arbitrary numbers hardware
documenters decide to use next week.

While I'm not terribly happy with the usability of this, especially now
that it's not a simple "add 16", redefining the existing binding is not
OK (and in any case the code above seems obfuscatory).  If we decide to
do something other than continue with register offset divided by 32,
then we need to define a new interrupt type (similar to current defined
types of error interrupt, timer, and IPI) for the new numberspace -- and
it should be handled when decoding that type of interrupt specifier,
rather than with the isu mechanism.

-Scott



Scott,
Thanks for your comments. Since the second way isn't so good, let's 
choose the original one.

But we meet a small accident now.
My patch is based on the http://patchwork.ozlabs.org/patch/291553/, 
which had been superseded, so this thread can be closed now.


And Shenzhou has already sent a complete dma3 dtsi patch including 
correct interrupt numbers, http://patchwork.ozlabs.org/patch/300026/, so 
let's focus on this patch, and I will forward your first comments of my 
patch there.


Thanks.



--
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] DTS: DMA: Fix DMA3 interrupts

[Hongbo Zhang]

Scott,
This issue is due to the non-continuous MPIC register, I think there is 
two ways to fix it.


The first one is as what we are discussing, in fact the Bman/Qman DT 
author had introduced this way, and I had to follow it, it is a trick, 
adding 208 is a bit ugly I think, and even difficult to explain it to 
customers etc, but this way changes less codes.


The second one is editing MPIC related codes without adding 208 to high 
interrupts. The point of translate interrupt number to MPIC register 
address is a so called 'isu' mechanism, we can do like the following 
example codes, then the tricky adding 208 isn't needed any more.


Which one do you prefer?
In fact I myself prefer the second, if the idea is acceptable, I will 
send a patch instead of this one. (and also alone with the internal 
patch decreasing 208 for the Bman/Qman)


void __init corenet_ds_pic_init(void)
{
..

mpic = mpic_alloc(NULL, 0, flags, 0, 512, "OpenPIC");
BUG_ON(mpic == NULL);

// Add this start
for (i = 0; i < 17; i++) {
if (i < 11)
addr_off = 0x1 + 0x20 * 16 * i;
else
addr_off = 0x13000 + 0x20 * 16 * (i - 11);  /* scape the 
address not for interrupts */

mpic_assign_isu(mpic, i, mpic->paddr + addr_off);
}
// Add this end

mpic_init(mpic);
}

On 12/07/2013 03:21 AM, Scott Wood wrote:

On Fri, 2013-11-29 at 16:07 +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

MPIC registers for internal interrupts is non-continous in address, any
internal interrupt number greater than 159 should be added (16+208) to work.
16 is due to external interrupts as usual, 208 is due to the non-continous MPIC
register space.
Tested on T4240 rev2 with SRIO2 disabled.

Signed-off-by: Hongbo Zhang 
---
  arch/powerpc/boot/dts/fsl/elo3-dma-2.dtsi |   16 
  1 file changed, 8 insertions(+), 8 deletions(-)

The FSL MPIC binding should be updated to point out how this works.

Technically it's not a change to the binding itself, since it's defined
in terms of register offset, but the explanatory text says "So interrupt
0 is at offset 0x0, interrupt 1 is at offset 0x20, and so on." which is
not accurate for these new high interrupt numbers.

-Scott







--
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 v11 0/3] DMA: Freescale: Add support for 8-channel DMA engine

[Hongbo Zhang]

On 11/13/2013 04:57 PM, Vinod Koul wrote:

On Thu, Sep 26, 2013 at 05:33:40PM +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Hi DMA and DT maintainers, please have a look at these V11 patches.

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set
adds support this DMA engine.


Applied all


Thanks.


Thanks
~Vinod





--
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 v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine

[Hongbo Zhang]

On 11/12/2013 08:09 AM, Dan Williams wrote:

On Mon, Nov 11, 2013 at 1:12 AM, Hongbo Zhang
 wrote:

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct
fsldma_device
*fdev,
WARN_ON(fdev->feature != chan->feature);
  chan->dev = fdev->dev;
-chan->id = ((res.start - 0x100) & 0xfff) >> 7;
+chan->id = (res.start & 0xfff) < 0x300 ?
+   ((res.start - 0x100) & 0xfff) >> 7 :
+   ((res.start - 0x200) & 0xfff) >> 7;
if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {

Isn't it a bit fragile to have this based on the resource address?
Can't device tree tell you the channel id directly by an index into
the "dma0: dma@100300" node?


Yes, both this way and putting a "cell-index" into device tree work.
This won't be fragile, because the resource address should always be defined
correctly, otherwise even if we can tell a channel id by "cell-index" but
with wrong resource address, nothing will work.
This piece of code only doesn't seem as neat as using "cell-index", but we
prefer the style that let the device tree describes as true as what hardware
really has. This doesn't mean "cell-index" isn't acceptable, if it is
necessary and unavoidable, we can send another patch to add it, but
currently there is no need and we don't have to do this.


I'm pointing it out because we just had a bug fix to another driver
motivated by the fact that resource addresses may move from one
implementation to another, whereas the cell index provided by device
tree is static.  Just a note, no need to fix it now.


Get it, and will remember it, thank you Dan.

--
Dan





--
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 v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine

[Hongbo Zhang]

On 11/08/2013 10:45 AM, Dan Williams wrote:

On Mon, Nov 4, 2013 at 6:31 PM, Hongbo Zhang  wrote:

Hi Vinod Koul and Dan Williams,
Ping?


Not much to review from the dmaengine side, just one question below.
It would be helpful if you can send these to the new dmaengine
patchwork at dmaeng...@vger.kernel.org with the Acks you have already
collected.



Sorry didn't notice this new mailing list.
I will resend these patches to it again.



On 10/17/2013 01:56 PM, Hongbo Zhang wrote:

Hi Vinod,
I have gotten ACK from Mark for both the 1/3 and 2/3 patches.
Thanks.


On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

This patch adds support to 8-channel DMA engine, thus the driver works
for both
the new 8-channel and the legacy 4-channel DMA engines.

Signed-off-by: Hongbo Zhang 
---
   drivers/dma/Kconfig  |9 +
   drivers/dma/fsldma.c |9 ++---
   drivers/dma/fsldma.h |2 +-
   3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..3979c65 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -89,14 +89,15 @@ config AT_HDMAC
 Support the Atmel AHB DMA controller.
 config FSL_DMA
-tristate "Freescale Elo and Elo Plus DMA support"
+tristate "Freescale Elo series DMA support"
   depends on FSL_SOC
   select DMA_ENGINE
   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
   ---help---
-  Enable support for the Freescale Elo and Elo Plus DMA controllers.
-  The Elo is the DMA controller on some 82xx and 83xx parts, and the
-  Elo Plus is the DMA controller on 85xx and 86xx parts.
+  Enable support for the Freescale Elo series DMA controllers.
+  The Elo is the DMA controller on some mpc82xx and mpc83xx parts,
the
+  EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 is
on
+  some Txxx and Bxxx parts.
 config MPC512X_DMA
   tristate "Freescale MPC512x built-in DMA engine support"
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct fsldma_device
*fdev,
   WARN_ON(fdev->feature != chan->feature);
 chan->dev = fdev->dev;
-chan->id = ((res.start - 0x100) & 0xfff) >> 7;
+chan->id = (res.start & 0xfff) < 0x300 ?
+   ((res.start - 0x100) & 0xfff) >> 7 :
+   ((res.start - 0x200) & 0xfff) >> 7;
   if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {

Isn't it a bit fragile to have this based on the resource address?
Can't device tree tell you the channel id directly by an index into
the "dma0: dma@100300" node?


Yes, both this way and putting a "cell-index" into device tree work.
This won't be fragile, because the resource address should always be 
defined correctly, otherwise even if we can tell a channel id by 
"cell-index" but with wrong resource address, nothing will work.
This piece of code only doesn't seem as neat as using "cell-index", but 
we prefer the style that let the device tree describes as true as what 
hardware really has. This doesn't mean "cell-index" isn't acceptable, if 
it is necessary and unavoidable, we can send another patch to add it, 
but currently there is no need and we don't have to do this.



--
Dan





--
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 v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine

[Hongbo Zhang]

Hi Vinod Koul and Dan Williams,
Ping?


On 10/17/2013 01:56 PM, Hongbo Zhang wrote:

Hi Vinod,
I have gotten ACK from Mark for both the 1/3 and 2/3 patches.
Thanks.


On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

This patch adds support to 8-channel DMA engine, thus the driver 
works for both

the new 8-channel and the legacy 4-channel DMA engines.

Signed-off-by: Hongbo Zhang 
---
  drivers/dma/Kconfig  |9 +
  drivers/dma/fsldma.c |9 ++---
  drivers/dma/fsldma.h |2 +-
  3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..3979c65 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -89,14 +89,15 @@ config AT_HDMAC
Support the Atmel AHB DMA controller.
config FSL_DMA
-tristate "Freescale Elo and Elo Plus DMA support"
+tristate "Freescale Elo series DMA support"
  depends on FSL_SOC
  select DMA_ENGINE
  select ASYNC_TX_ENABLE_CHANNEL_SWITCH
  ---help---
-  Enable support for the Freescale Elo and Elo Plus DMA 
controllers.
-  The Elo is the DMA controller on some 82xx and 83xx parts, and 
the

-  Elo Plus is the DMA controller on 85xx and 86xx parts.
+  Enable support for the Freescale Elo series DMA controllers.
+  The Elo is the DMA controller on some mpc82xx and mpc83xx 
parts, the
+  EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 
is on

+  some Txxx and Bxxx parts.
config MPC512X_DMA
  tristate "Freescale MPC512x built-in DMA engine support"
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct 
fsldma_device *fdev,

  WARN_ON(fdev->feature != chan->feature);
chan->dev = fdev->dev;
-chan->id = ((res.start - 0x100) & 0xfff) >> 7;
+chan->id = (res.start & 0xfff) < 0x300 ?
+   ((res.start - 0x100) & 0xfff) >> 7 :
+   ((res.start - 0x200) & 0xfff) >> 7;
  if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
  dev_err(fdev->dev, "too many channels for device\n");
  err = -EINVAL;
@@ -1434,6 +1436,7 @@ static int fsldma_of_remove(struct 
platform_device *op)

  }
static const struct of_device_id fsldma_of_ids[] = {
+{ .compatible = "fsl,elo3-dma", },
  { .compatible = "fsl,eloplus-dma", },
  { .compatible = "fsl,elo-dma", },
  {}
@@ -1455,7 +1458,7 @@ static struct platform_driver fsldma_of_driver = {
static __init int fsldma_init(void)
  {
-pr_info("Freescale Elo / Elo Plus DMA driver\n");
+pr_info("Freescale Elo series DMA driver\n");
  return platform_driver_register(&fsldma_of_driver);
  }
  @@ -1467,5 +1470,5 @@ static void __exit fsldma_exit(void)
  subsys_initcall(fsldma_init);
  module_exit(fsldma_exit);
  -MODULE_DESCRIPTION("Freescale Elo / Elo Plus DMA driver");
+MODULE_DESCRIPTION("Freescale Elo series DMA driver");
  MODULE_LICENSE("GPL");
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..1ffc244 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,7 +112,7 @@ struct fsldma_chan_regs {
  };
struct fsldma_chan;
-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
struct fsldma_device {
  void __iomem *regs;/* DGSR register base */







--
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 v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine

[Hongbo Zhang]

Hi Vinod,
I have gotten ACK from Mark for both the 1/3 and 2/3 patches.
Thanks.


On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

This patch adds support to 8-channel DMA engine, thus the driver works for both
the new 8-channel and the legacy 4-channel DMA engines.

Signed-off-by: Hongbo Zhang 
---
  drivers/dma/Kconfig  |9 +
  drivers/dma/fsldma.c |9 ++---
  drivers/dma/fsldma.h |2 +-
  3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..3979c65 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -89,14 +89,15 @@ config AT_HDMAC
  Support the Atmel AHB DMA controller.
  
  config FSL_DMA

-   tristate "Freescale Elo and Elo Plus DMA support"
+   tristate "Freescale Elo series DMA support"
depends on FSL_SOC
select DMA_ENGINE
select ASYNC_TX_ENABLE_CHANNEL_SWITCH
---help---
- Enable support for the Freescale Elo and Elo Plus DMA controllers.
- The Elo is the DMA controller on some 82xx and 83xx parts, and the
- Elo Plus is the DMA controller on 85xx and 86xx parts.
+ Enable support for the Freescale Elo series DMA controllers.
+ The Elo is the DMA controller on some mpc82xx and mpc83xx parts, the
+ EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 is on
+ some Txxx and Bxxx parts.
  
  config MPC512X_DMA

tristate "Freescale MPC512x built-in DMA engine support"
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
WARN_ON(fdev->feature != chan->feature);
  
  	chan->dev = fdev->dev;

-   chan->id = ((res.start - 0x100) & 0xfff) >> 7;
+   chan->id = (res.start & 0xfff) < 0x300 ?
+  ((res.start - 0x100) & 0xfff) >> 7 :
+  ((res.start - 0x200) & 0xfff) >> 7;
if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
dev_err(fdev->dev, "too many channels for device\n");
err = -EINVAL;
@@ -1434,6 +1436,7 @@ static int fsldma_of_remove(struct platform_device *op)
  }
  
  static const struct of_device_id fsldma_of_ids[] = {

+   { .compatible = "fsl,elo3-dma", },
{ .compatible = "fsl,eloplus-dma", },
{ .compatible = "fsl,elo-dma", },
{}
@@ -1455,7 +1458,7 @@ static struct platform_driver fsldma_of_driver = {
  
  static __init int fsldma_init(void)

  {
-   pr_info("Freescale Elo / Elo Plus DMA driver\n");
+   pr_info("Freescale Elo series DMA driver\n");
return platform_driver_register(&fsldma_of_driver);
  }
  
@@ -1467,5 +1470,5 @@ static void __exit fsldma_exit(void)

  subsys_initcall(fsldma_init);
  module_exit(fsldma_exit);
  
-MODULE_DESCRIPTION("Freescale Elo / Elo Plus DMA driver");

+MODULE_DESCRIPTION("Freescale Elo series DMA driver");
  MODULE_LICENSE("GPL");
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..1ffc244 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,7 +112,7 @@ struct fsldma_chan_regs {
  };
  
  struct fsldma_chan;

-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
  
  struct fsldma_device {

void __iomem *regs; /* DGSR register base */




--
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 v11 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

On 10/15/2013 09:38 PM, Mark Rutland wrote:

On Tue, Oct 08, 2013 at 04:22:07AM +0100, Hongbo Zhang wrote:

Hi Mark, Stephen and other DT maintainers?

The 1/3 had already been acked by Mark, and please have a further look
at this patch 2/3.
The DMA maintainer Vinod  needs ack for the DT related patches so that
he can take all this patch set.

Sorry for the delay.

This looks ok to me.

Acked-by: Mark Rutland 


Thanks, Mark.


On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.

Signed-off-by: Hongbo Zhang 
---
   .../devicetree/bindings/powerpc/fsl/dma.txt|   70 +
   arch/powerpc/boot/dts/fsl/b4si-post.dtsi   |4 +-
   arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi  |   82 

   arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi  |   82 

   arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
   5 files changed, 238 insertions(+), 4 deletions(-)
   create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
   create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt 
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index 0584168..7fc1b01 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -128,6 +128,76 @@ Example:
   };
   };

+** Freescale Elo3 DMA Controller
+   DMA controller which has same function as EloPlus except that Elo3 has 8
+   channels while EloPlus has only 4, it is used in Freescale Txxx and Bxxx
+   series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include "fsl,elo3-dma"
+- reg   : contains two entries for DMA General Status Registers,
+  i.e. DGSR0 which includes status for channel 1~4, and
+  DGSR1 for channel 5~8
+- ranges: describes the mapping between the address space of the
+  DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+- compatible: must include "fsl,eloplus-dma-channel"
+- reg   : DMA channel specific registers
+- interrupts: interrupt specifier for DMA channel IRQ
+- interrupt-parent  : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x100300 0x4>,
+   <0x100600 0x4>;
+ ranges = <0x0 0x100100 0x500>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <28 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <29 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <30 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <31 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <76 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <77 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <78 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <79 2 0 0>;
+ };
+};
+
   Note on DMA channel compatible properties: The compatible property must say
   "fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
   driver (fsldma).  Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
   reg = <0xe2000 0x1000>;
   };

-/include/ "qoriq-dma-0.dtsi"
+/include/ "elo3-dma-0.dtsi"
   dma@100300 {
   fsl,iommu-parent = <&pamu0>;
   fsl,liodn-reg = <&guts 0x

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Hongbo Zhang]

On 09/25/2013 10:15 PM, Eduardo Valentin wrote:

On 25-09-2013 03:13, Hongbo Zhang wrote:

On 09/19/2013 05:35 AM, Eduardo Valentin wrote:

   [...]
+
+/***   sensor API   ***/
+

You are introducing new concept here, the original framework and drivers
cannot use this, right? any further plan to update original framework
for this new feature?


Well, not new as such. Just a specific way to register sensors to
thermal framework. What is really new is the fact that we really need to
have sensors decoupled from thermal zone devices, and today we have
these concepts pretty merged together.
To answer your question, for now I am more concerned with the bindings
definition. Once that is at least agreed, then we can follow up with the
migration of existing drivers. For now, there are two examples in this
series, first one is using one existing thermal driver, which is the TI
SoC thermal driver, and the second one is the hwmon drivers, which are
existing sensor drivers, but are not thermal drivers.

The plan forward, once this series is accepted is to migrate existing
drivers, yes, so that they can use device tree uniformly. Of course,
this needs help from driver authors.

My proposal will be to follow up this series with a two fold migration.
First step to change the existing thermal drivers to have both, the
current support and the device tree support. And second step, for those
who wish to, we could remove the old code containing thermal data and
have only dt support. Of course, this requires drivers authors input.




+static struct thermal_zone_device *
+thermal_zone_of_add_sensor(struct device_node *zone,
+   struct device_node *sensor, void *data,
+   int (*get_temp)(void *, long *),
+   int (*get_trend)(void *, long *))
+{
+struct thermal_zone_device *tzd;
+struct __thermal_zone *tz;
+
+tzd = thermal_zone_get_zone_by_name(zone->name);
+if (IS_ERR(tzd))
+return ERR_PTR(-EPROBE_DEFER);
+
[...]
+
+/*
+ * Here are the thermal trip types. This must
+ * match with enum thermal_trip_type at
+ * include/linux/thermal.h
+ */
+#define THERMAL_TRIP_ACTIVE0
+#define THERMAL_TRIP_PASSIVE1
+#define THERMAL_TRIP_HOT2
+#define THERMAL_TRIP_CRITICAL3
+

These macros seem duplicated with enum thermal_trip_type in thermal.h,
do you have further plan to merge them?
Or by using string "active",  "passive" etc in the dts, then you can
reuse the original enum definition.

I am changing this so that in DT we have string constants, and we keep a
map from string to enum, just like we have for phy-mode, as suggested by
Mark.

You can have a taste of it here:
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux.git/commit/?h=thermal_work/thermal_core/dt_parser_rfc_v4&id=73f16c27fc763495188fba7d6e17b9c986efc6ac

I will be reposting this version once we are done with this thread
discussion and I am finished with my current test.

If you have the time, I would appreciate if you could try the series on
your board, as I am don't have access to your hardware. It would be
really nice to see how this work is behaving in other environments then
the one I have.


We have thermal management plan in next year, currently I don't have 
proper board to test this.
I would like to do it when I have time and board, but I will track these 
thermal treads.


Thanks for your interest in this work.


+/* On cooling devices upper and lower limits */
+#define THERMAL_NO_LIMIT(-1UL)
+
+#endif
[...]










--
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 v11 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

Hi Mark, Stephen and other DT maintainers?

The 1/3 had already been acked by Mark, and please have a further look 
at this patch 2/3.
The DMA maintainer Vinod  needs ack for the DT related patches so that 
he can take all this patch set.


On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.

Signed-off-by: Hongbo Zhang 
---
  .../devicetree/bindings/powerpc/fsl/dma.txt|   70 +
  arch/powerpc/boot/dts/fsl/b4si-post.dtsi   |4 +-
  arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi  |   82 
  arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi  |   82 
  arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
  5 files changed, 238 insertions(+), 4 deletions(-)
  create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
  create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt 
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index 0584168..7fc1b01 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -128,6 +128,76 @@ Example:
};
};
  
+** Freescale Elo3 DMA Controller

+   DMA controller which has same function as EloPlus except that Elo3 has 8
+   channels while EloPlus has only 4, it is used in Freescale Txxx and Bxxx
+   series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include "fsl,elo3-dma"
+- reg   : contains two entries for DMA General Status Registers,
+  i.e. DGSR0 which includes status for channel 1~4, and
+  DGSR1 for channel 5~8
+- ranges: describes the mapping between the address space of the
+  DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+- compatible: must include "fsl,eloplus-dma-channel"
+- reg   : DMA channel specific registers
+- interrupts: interrupt specifier for DMA channel IRQ
+- interrupt-parent  : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,elo3-dma";
+   reg = <0x100300 0x4>,
+ <0x100600 0x4>;
+   ranges = <0x0 0x100100 0x500>;
+   dma-channel@0 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x0 0x80>;
+   interrupts = <28 2 0 0>;
+   };
+   dma-channel@80 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x80 0x80>;
+   interrupts = <29 2 0 0>;
+   };
+   dma-channel@100 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x100 0x80>;
+   interrupts = <30 2 0 0>;
+   };
+   dma-channel@180 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x180 0x80>;
+   interrupts = <31 2 0 0>;
+   };
+   dma-channel@300 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x300 0x80>;
+   interrupts = <76 2 0 0>;
+   };
+   dma-channel@380 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x380 0x80>;
+   interrupts = <77 2 0 0>;
+   };
+   dma-channel@400 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x400 0x80>;
+   interrupts = <78 2 0 0>;
+   };
+   dma-channel@480 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x480 0x80>;
+   interrupts = <79 2 0 0>;
+   };
+};
+
  Note on DMA channel compatible properties: The compatible property must say
  "fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
  driver (fsldma).  Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
reg = <0xe2000 0x1000>;
};
  
-/include/ "qoriq-dma-0.dtsi"

+/include/ "elo3-dma-0.dtsi"
dma@100300 {
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x580>; /* DMA1LIODNR */
};
  
-/include/ "qoriq-dma-1.dtsi"

+/include/ &quo

Re: [PATCH v10 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

On 09/26/2013 10:28 AM, David Gibson wrote:

On Wed, Sep 25, 2013 at 08:46:32PM -0500, Scott Wood wrote:

On Wed, 2013-09-25 at 15:35 +0800, Hongbo Zhang wrote:

By the way, I know maybe it is difficult, but why not introduce a
document of maintaining rules for the dt binding docs? we have dedicated
maintainers for this part now. Description language from one submitter
cannot satisfy every reviewer/maintainer, for a reg property, is it
necessary to say "offset and length",

Don't say "offset and length".  It's both redundant with the base
definition of the reg property, and overly specific because it makes
assumptions about how the parent node's ranges are set up (sometimes we
want to be that specific, but usually not).


Thanks for your answer Scott.
In fact my questions are mainly sample questions to file the necessary 
rules of dt binding.

To look at it another way, the format of the 'reg' property is defined
by the parent bus's binding, not the binding of the node itself.

Whatever the rule is, if it is reasonable and accepted, just as I said, 
we need to file it.



--
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 v10 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

On 09/25/2013 01:31 AM, Stephen Warren wrote:

On 09/24/2013 04:30 AM, Hongbo Zhang wrote:

On 09/24/2013 01:04 AM, Stephen Warren wrote:

On 09/18/2013 04:15 AM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this
patch adds
the device tree nodes for them.
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+Required properties:
+
+- compatible: must include "fsl,elo3-dma"
+- reg   : DMA General Status Registers, i.e. DGSR0 which
contains
+  status for channel 1~4, and DGSR1 for channel 5~8

Is that a single entry, which is large enough to cover both registers,
or a pair of entries, one per register? Reading the text, I might assume
the former, but looking at the examples, it's the latter.

My impression is that I cannot tell it is one larger entry or two
entries by reading the description text, but the example gives the answer.
Is it so important to specify it is only one entry or entries list?
I prefer language as concise as possible, especially for the common
properties such as reg and interrupt (eg the reg is implicitly offset
and length of registers, can be continuous or not), it is difficult or
unnecessary or impossible to describe much details, the example can also
work as a complementary description, otherwise no need to put an example
in the binding document.

The description of the properties should fully describe them. The
example is just an example, not a specification of the properties.


It is OK for me to update the description like this:
reg:containing two entries for DMA General Status Registers, i.e. 
DGSR0 which contains + status for channel 1~4, and DGSR1 for channel 5~8


and let me wait one or more days to see if other reviewers/maintainers 
have further comments before I send our another iteration.


By the way, I know maybe it is difficult, but why not introduce a 
document of maintaining rules for the dt binding docs? we have dedicated 
maintainers for this part now. Description language from one submitter 
cannot satisfy every reviewer/maintainer, for a reg property, is it 
necessary to say "offset and length", to say "how many entries", to say 
"register functions and even names"? If there is specific rules (even 
with good examples), it will be convenient for both submitter and 
reviewers. Without rules/guidelines, new submitter would like to follow 
old bad samples.




--
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: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Hongbo Zhang]

On 09/19/2013 05:35 AM, Eduardo Valentin wrote:
  
[...]

+
+/***   sensor API   ***/
+


You are introducing new concept here, the original framework and drivers 
cannot use this, right? any further plan to update original framework 
for this new feature?



+static struct thermal_zone_device *
+thermal_zone_of_add_sensor(struct device_node *zone,
+  struct device_node *sensor, void *data,
+  int (*get_temp)(void *, long *),
+  int (*get_trend)(void *, long *))
+{
+   struct thermal_zone_device *tzd;
+   struct __thermal_zone *tz;
+
+   tzd = thermal_zone_get_zone_by_name(zone->name);
+   if (IS_ERR(tzd))
+   return ERR_PTR(-EPROBE_DEFER);
+
[...]
+
+/*
+ * Here are the thermal trip types. This must
+ * match with enum thermal_trip_type at
+ * include/linux/thermal.h
+ */
+#define THERMAL_TRIP_ACTIVE0
+#define THERMAL_TRIP_PASSIVE   1
+#define THERMAL_TRIP_HOT   2
+#define THERMAL_TRIP_CRITICAL  3
+


These macros seem duplicated with enum thermal_trip_type in thermal.h, 
do you have further plan to merge them?
Or by using string "active",  "passive" etc in the dts, then you can 
reuse the original enum definition.



+/* On cooling devices upper and lower limits */
+#define THERMAL_NO_LIMIT   (-1UL)
+
+#endif
[...]



--
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: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Hongbo Zhang]

On 09/24/2013 11:50 PM, Eduardo Valentin wrote:

Zhang,

I appreciate your interest. I am replying a couple of your comments.
Please also check my answers to Mark's queries on other email thread.

When I replied to Mark yesterday, I missed your mail replying him already.
I should check that mail and reply it for further concerns.

On 24-09-2013 04:11, Hongbo Zhang wrote:

On 09/23/2013 06:40 PM, Mark Rutland wrote:

Hi Eduardo,

Apologies for having taken so long to get back you on this.

I have several comments on the binding and the way it's parsed.

On Wed, Sep 18, 2013 at 10:35:36PM +0100, Eduardo Valentin wrote:

This patch introduces a device tree bindings for
describing the hardware thermal behavior and limits.
Also a parser to read and interpret the data and feed
it in the thermal framework is presented.

This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.

This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.

Note that, in order to be able to have control
on the sensor registration on the DT thermal zone,
it was required to allow changing the thermal zone
.get_temp callback. For this reason, this patch
also removes the 'const' modifier from the .ops
field of thermal zone devices.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
   .../devicetree/bindings/thermal/thermal.txt| 498 +
   drivers/thermal/Kconfig|  13 +
   drivers/thermal/Makefile   |   1 +
   drivers/thermal/of-thermal.c   | 775
+
   drivers/thermal/thermal_core.c |   9 +-
   drivers/thermal/thermal_core.h |   9 +
   include/dt-bindings/thermal/thermal.h  |  27 +
   include/linux/thermal.h|  28 +-
   8 files changed, 1357 insertions(+), 3 deletions(-)
   create mode 100644
Documentation/devicetree/bindings/thermal/thermal.txt
   create mode 100644 drivers/thermal/of-thermal.c
   create mode 100644 include/dt-bindings/thermal/thermal.h

---

Hello all,

Thanks Joe Perches for the effort of reviewing this code, I really
appreciate it.

Here is a version with a refactored init function without leaks in
the failure
patch. I also added a couple of comments to better understand the
intention of
that function. Besides, when there are no memory available, the function
rolls back what ever thermal zones have been added.

Thanks,

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt
b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* Thermal Framework Device Tree descriptor
+
+Generic binding to provide a way of defining hardware thermal
+structure using device tree. A thermal structure includes thermal
+zones and their components, such as trip points, polling intervals,
+sensors and cooling devices binding descriptors.
+
+The target of device tree thermal descriptors is to describe only
+the hardware thermal aspects, not how the system must control or which
+algorithm or policy must be taken in place.
+
+There are five types of nodes involved to describe thermal bindings:
+- sensors: used to describe the device source of temperature sensing;
+- cooling devices: used to describe devices source of power
dissipation control;
+- trip points: used to describe points in temperature domain defined to
+make the system aware of hardware limits;
+- cooling attachments: used to describe links between trip points and
+cooling devices;

I think "attachments" sounds a bit odd, though I don't have a better
naming suggestion.

"map" or "mapping" is better?

Well,  yeah, that could work.

:)

+- thermal zones: used to describe thermal data within the hardware;
+
+It follows a description of each type of these device tree nodes.
+
+* Sensor devices
+
+Sensor devices are nodes providing temperature sensing capabilities
on thermal
+zones. Typical devices are I2C ADC converters and bandgaps. Theses
are nodes
+providing temperature data to thermal zones. Temperature sensor
devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:   Used to provide sensor device specific
information
+   while referring to it. Must be at least 1, in
order
+   to identify uniquely the sensor instances within
+   the IC. See thermal zone binding for more
details
+   on how consumers refer to sensor devices.

I don't see why this needs to be at least one cell -- if an IC only has
one temperat

Re: [PATCH v10 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

On 09/24/2013 01:04 AM, Stephen Warren wrote:

On 09/18/2013 04:15 AM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt 
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+Required properties:
+
+- compatible: must include "fsl,elo3-dma"
+- reg   : DMA General Status Registers, i.e. DGSR0 which contains
+  status for channel 1~4, and DGSR1 for channel 5~8

Is that a single entry, which is large enough to cover both registers,
or a pair of entries, one per register? Reading the text, I might assume
the former, but looking at the examples, it's the latter.
My impression is that I cannot tell it is one larger entry or two 
entries by reading the description text, but the example gives the answer.

Is it so important to specify it is only one entry or entries list?
I prefer language as concise as possible, especially for the common 
properties such as reg and interrupt (eg the reg is implicitly offset 
and length of registers, can be continuous or not), it is difficult or 
unnecessary or impossible to describe much details, the example can also 
work as a complementary description, otherwise no need to put an example 
in the binding document.



...
  +Example:

+dma@100300 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,elo3-dma";
+   reg = <0x100300 0x4>,
+ <0x100600 0x4>;






--
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: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Hongbo Zhang]

On 09/23/2013 06:40 PM, Mark Rutland wrote:

Hi Eduardo,

Apologies for having taken so long to get back you on this.

I have several comments on the binding and the way it's parsed.

On Wed, Sep 18, 2013 at 10:35:36PM +0100, Eduardo Valentin wrote:

This patch introduces a device tree bindings for
describing the hardware thermal behavior and limits.
Also a parser to read and interpret the data and feed
it in the thermal framework is presented.

This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.

This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.

Note that, in order to be able to have control
on the sensor registration on the DT thermal zone,
it was required to allow changing the thermal zone
.get_temp callback. For this reason, this patch
also removes the 'const' modifier from the .ops
field of thermal zone devices.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
  .../devicetree/bindings/thermal/thermal.txt| 498 +
  drivers/thermal/Kconfig|  13 +
  drivers/thermal/Makefile   |   1 +
  drivers/thermal/of-thermal.c   | 775 +
  drivers/thermal/thermal_core.c |   9 +-
  drivers/thermal/thermal_core.h |   9 +
  include/dt-bindings/thermal/thermal.h  |  27 +
  include/linux/thermal.h|  28 +-
  8 files changed, 1357 insertions(+), 3 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
  create mode 100644 drivers/thermal/of-thermal.c
  create mode 100644 include/dt-bindings/thermal/thermal.h

---

Hello all,

Thanks Joe Perches for the effort of reviewing this code, I really appreciate 
it.

Here is a version with a refactored init function without leaks in the failure
patch. I also added a couple of comments to better understand the intention of
that function. Besides, when there are no memory available, the function
rolls back what ever thermal zones have been added.

Thanks,

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* Thermal Framework Device Tree descriptor
+
+Generic binding to provide a way of defining hardware thermal
+structure using device tree. A thermal structure includes thermal
+zones and their components, such as trip points, polling intervals,
+sensors and cooling devices binding descriptors.
+
+The target of device tree thermal descriptors is to describe only
+the hardware thermal aspects, not how the system must control or which
+algorithm or policy must be taken in place.
+
+There are five types of nodes involved to describe thermal bindings:
+- sensors: used to describe the device source of temperature sensing;
+- cooling devices: used to describe devices source of power dissipation 
control;
+- trip points: used to describe points in temperature domain defined to
+make the system aware of hardware limits;
+- cooling attachments: used to describe links between trip points and
+cooling devices;

I think "attachments" sounds a bit odd, though I don't have a better
naming suggestion.


"map" or "mapping" is better?


+- thermal zones: used to describe thermal data within the hardware;
+
+It follows a description of each type of these device tree nodes.
+
+* Sensor devices
+
+Sensor devices are nodes providing temperature sensing capabilities on thermal
+zones. Typical devices are I2C ADC converters and bandgaps. Theses are nodes
+providing temperature data to thermal zones. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:   Used to provide sensor device specific information
+   while referring to it. Must be at least 1, in order
+   to identify uniquely the sensor instances within
+   the IC. See thermal zone binding for more details
+   on how consumers refer to sensor devices.

I don't see why this needs to be at least one cell -- if an IC only has
one temperature sensor it should be fine for this to be zero and have no
ambiguity.

It may make sense to call these thermal sensor devices, there are plenty
of other sensors we might want to describe in the dt for other purposes,
and we can impose some consistency if we remove the ambiguity.


+
+* Cooling device nodes
+
+Cooling devices are nodes providing control on power dissipation. There
+are essentially two ways to provide control on power dissipation. First
+is by means of regul

Re: [RFC PATCH] thermal: add generic cpu hotplug cooling device

[Hongbo Zhang]

On 09/21/2013 06:15 AM, Zoran Markovic wrote:

This patch implements a generic CPU hotplug cooling device. The
implementation scales down the number of running CPUs when temperature
increases through a thermal trip point and prevents booting CPUs
until thermal conditions are restored. Upon restoration, the action
of starting up a CPU is left to another entity (e.g. CPU offline
governor, for which a patch is in the works).

In the past two years, ARM considerably reduced the time required for
CPUs to boot and shutdown; this time is now measured in microseconds.
This patch is predominantly intended for ARM big.LITTLE architectures
where big cores are expected to have a much bigger impact on thermal
budget than little cores, resulting in fast temperature ramps to a trip
point, i.e. thermal runaways. Switching off the big core(s) may be one
of the recovery mechanisms to restore system temperature, but the actual
strategy is left to the thermal governor.

The assumption is that CPU shutdown/startup is a rare event, so no
attempt was made to make the code atomic, i.e. the code evidently races
with CPU hotplug driver. The set_cur_state() function offlines CPUs
iteratively one at a time, checking the cooling state before each CPU
shutdown. A hotplug notifier callback validates any CPU boot requests
against current cooling state and approves/denies accordingly. This
mechanism guarantees that the desired cooling state could be reached in a
maximum of d-c iterations, where d and c are the "desired" and "current"
cooling states expressed in the number of offline CPUs.

Credits to Amit Daniel Kachhap for initial attempt to upstream this feature.

Cc: Zhang Rui
Cc: Eduardo Valentin
Cc: Rob Landley
Cc: Amit Daniel Kachhap
Cc: Andrew Morton
Cc: Durgadoss R
Cc: Christian Daudt
Cc: James King
Signed-off-by: Zoran Markovic
---
  Documentation/thermal/cpu-cooling-api.txt |   17 ++
  drivers/thermal/Kconfig   |   10 +
  drivers/thermal/Makefile  |1 +
  drivers/thermal/cpu_hotplug.c |  362 +
  include/linux/cpuhp_cooling.h |   57 +
  5 files changed, 447 insertions(+)
  create mode 100644 drivers/thermal/cpu_hotplug.c
  create mode 100644 include/linux/cpuhp_cooling.h

Only form my point of view:
I like the name of cpu_hotplug_cooling.c and cpu_hotplug_cooling.h
we already have a cpu_cooling.c, that isn't so exact either because we 
have more than one method to cool a CPU, these c and h files should be 
renamed to cpu_freq_cooling.c and cpu_freq_cooling.h later.


By the way, some servers with tens of CPUs may need this patch too.



--
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 05/21] cpuidle: make __cpuidle_driver_init() return void

[Hongbo Zhang]

On 09/22/2013 09:20 AM, Viresh Kumar wrote:

__cpuidle_driver_init() doesn't return anything except zero and so doesn't
really need a return type other than void.

Signed-off-by: Viresh Kumar 
---
  drivers/cpuidle/driver.c | 8 ++--
  1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index 25455e8..8df66c8 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -152,7 +152,7 @@ static void cpuidle_setup_broadcast_timer(void *arg)
   *
   * Returns 0 on success, a negative error code otherwise.
If you want to make it return void, you should also update the above 
comment.

   */
-static int __cpuidle_driver_init(struct cpuidle_driver *drv)
+static void __cpuidle_driver_init(struct cpuidle_driver *drv)
  {
int i;
  
@@ -179,8 +179,6 @@ static int __cpuidle_driver_init(struct cpuidle_driver *drv)

drv->bctimer = 1;
break;
}
-
-   return 0;
  }
  
  /**

@@ -206,9 +204,7 @@ static int __cpuidle_register_driver(struct cpuidle_driver 
*drv)
if (cpuidle_disabled())
return -ENODEV;
  
-	ret = __cpuidle_driver_init(drv);

-   if (ret)
-   return ret;
+   __cpuidle_driver_init(drv);
  
  	ret = __cpuidle_set_driver(drv);

if (ret)




--
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 v9 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

On 09/13/2013 01:15 AM, Mark Rutland wrote:

On Tue, Sep 03, 2013 at 10:01:50AM +0100, Hongbo Zhang wrote:

On 09/02/2013 11:58 PM, Mark Rutland wrote:

Hi,

On Fri, Aug 30, 2013 at 12:26:19PM +0100, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.

Signed-off-by: Hongbo Zhang 
---
   .../devicetree/bindings/powerpc/fsl/dma.txt|   67 
   arch/powerpc/boot/dts/fsl/b4si-post.dtsi   |4 +-
   arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi  |   82 

   arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi  |   82 

   arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
   5 files changed, 235 insertions(+), 4 deletions(-)
   create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
   create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt 
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index ddf17af..332ac77 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,73 @@ Example:
  };
  };

+** Freescale Elo3 DMA Controller
+   This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx

I was under the impression EloPlus was the previous revision. Should
that say Elo3, or is Elo3 considered to be an EloPlus implementation?

In this patch 1/3 I revise the doc to make it clear we have Elo and
EloPlus, and I'm adding another new Elo3. Yes the only difference
between Elo3 and EloPlus is channel numbers(8 channels vs 4 channels),
so we can call "Elo3 is an 8-channel EloPlus"

Ok.


+   series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include "fsl,elo3-dma"
+- reg   : 

The example has two reg entries. What both are should be specified. From
what you described last time, it sounds like each is a status register
for four channels.

Presumably the first covers the channels at 0x0,0x80,0x100,0x180, and
the second covers the channels at 0x300,0x380,0x400,0x480? If the
registers have specific names in a datasheet, it would be worth
mentioning them.

Yes, each is a status register for four channels, you got it -- this
means my statement works.
Is it necessary to specify all the register names?
I can describe my two registers, but in other cases the reg entryies can
cover tens even hundreds of registers, just a summary is OK I think.

I think there should at least be a description of which channels each
reg entry corresponds to. I see this hasn't been done so far for the
older Elo DMAs, but they only had 4 channels max, and one status reg.

OK, I will update the reg description to make it more clear.

If the specification of the DMA controller allows for more channels, it
may be worth describing that case now.

This DMA controller doesn't allows for more channels. (Even if it does,
it should be another new controller)

Ok.


+- ranges: describes the mapping between the address space of the
+  DMA channels and the address space of the DMA controller

This looks odd as a required property, and I'm slightly confused. Is
this used to map the reg values of the DMA channels, or is it used when
mapping the DMA address space (for which dma-ranges exists in ePAPR and
other bindings).

It is used to map the reg values of DMA channels.

Ok, I guess that makes sense.


+
+- DMA channel nodes:
+- compatible: must include "fsl,eloplus-dma-channel"
+- reg   : 

What does this represent? What are valid values?

In the example below it looks like these are offsets of control
registers within the dma controller.

Yes, they are offsets of control registers within dma controller, but
the contents in these registers are for dma channels.
Physically we have dma controller registers and dma channel registers,
they are in one continuous physical address space, we divide all these
registers into two controller/channel parts, according to contents in
these registers, common status registers for all channels are called dma
controller registers, otherwise channel specific registers are called
dma channel registers.

I see, so this reg represents a channels channel specific registers
(which are distinct from the shared status registers). I was confused
initially as to what address space they were in, but that makes sense
with your description of ranges above.


If the reg property may have any value, how do they get mapped to bits
in the status register(s)?

In fact, each channel has its own status register(and also other
registers), the dma controller status register is just aggregation of
all channel status register. (that seems duplicated somehow, maybe this
is due 

Re: [PATCH v9 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

Mark? ping.

On 09/03/2013 05:01 PM, Hongbo Zhang wrote:

On 09/02/2013 11:58 PM, Mark Rutland wrote:

Hi,

On Fri, Aug 30, 2013 at 12:26:19PM +0100, hongbo.zh...@freescale.com 
wrote:

From: Hongbo Zhang 

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this 
patch adds

the device tree nodes for them.

Signed-off-by: Hongbo Zhang 
---
  .../devicetree/bindings/powerpc/fsl/dma.txt|   67 


  arch/powerpc/boot/dts/fsl/b4si-post.dtsi   |4 +-
  arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi  |   82 

  arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi  |   82 


  arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
  5 files changed, 235 insertions(+), 4 deletions(-)
  create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
  create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt 
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt

index ddf17af..332ac77 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,73 @@ Example:
 };
 };

+** Freescale Elo3 DMA Controller
+   This is EloPlus controller with 8 channels, used in Freescale 
Txxx and Bxxx

I was under the impression EloPlus was the previous revision. Should
that say Elo3, or is Elo3 considered to be an EloPlus implementation?
In this patch 1/3 I revise the doc to make it clear we have Elo and 
EloPlus, and I'm adding another new Elo3. Yes the only difference 
between Elo3 and EloPlus is channel numbers(8 channels vs 4 channels), 
so we can call "Elo3 is an 8-channel EloPlus"

+   series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include "fsl,elo3-dma"
+- reg   : 

The example has two reg entries. What both are should be specified. From
what you described last time, it sounds like each is a status register
for four channels.

Presumably the first covers the channels at 0x0,0x80,0x100,0x180, and
the second covers the channels at 0x300,0x380,0x400,0x480? If the
registers have specific names in a datasheet, it would be worth
mentioning them.
Yes, each is a status register for four channels, you got it -- this 
means my statement works.

Is it necessary to specify all the register names?
I can describe my two registers, but in other cases the reg entryies 
can cover tens even hundreds of registers, just a summary is OK I think.

If the specification of the DMA controller allows for more channels, it
may be worth describing that case now.
This DMA controller doesn't allows for more channels. (Even if it 
does, it should be another new controller)
+- ranges: describes the mapping between the address 
space of the
+  DMA channels and the address space of the DMA 
controller

This looks odd as a required property, and I'm slightly confused. Is
this used to map the reg values of the DMA channels, or is it used when
mapping the DMA address space (for which dma-ranges exists in ePAPR and
other bindings).

It is used to map the reg values of DMA channels.

+
+- DMA channel nodes:
+- compatible: must include "fsl,eloplus-dma-channel"
+- reg   : 

What does this represent? What are valid values?

In the example below it looks like these are offsets of control
registers within the dma controller.
Yes, they are offsets of control registers within dma controller, but 
the contents in these registers are for dma channels.
Physically we have dma controller registers and dma channel registers, 
they are in one continuous physical address space, we divide all these 
registers into two controller/channel parts, according to contents in 
these registers, common status registers for all channels are called 
dma controller registers, otherwise channel specific registers are 
called dma channel registers.

If the reg property may have any value, how do they get mapped to bits
in the status register(s)?
In fact, each channel has its own status register(and also other 
registers), the dma controller status register is just aggregation of 
all channel status register. (that seems duplicated somehow, maybe 
this is due to hardware compatibility with legacy one, and the device 
tree just describes the physical hardware without lie)

May some channels be unusable for some reason, or will all eight
channels be wired on any given Elo3 DMA?
Sorry, not get your point clearly, maybe you are clear now because of 
my previous explanations.

Cheers,
Mark.

+- interrupts: IRQ>
+- interrupt-parent  : optional, if needed for interrupt 
mapping

+
+Example:
+dma@100300 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,elo3-dma";
+   reg = <0x

Re: [PATCH 2/2] fsl: set wakeup sources

[Hongbo Zhang]

Sorry linux-kernel subscribers,
This is for team internal review, linux-kernel is cced due to my 
carelessness, omit this mail please.



On 09/06/2013 02:46 PM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Some devices can work as wakeup sources, they should be powerred on during
system deep sleep, this patch adds interface for configuring devices power
supply status during deep sleep.

Signed-off-by: Hongbo Zhang 
---
  arch/powerpc/boot/dts/fsl/qoriq-power.dtsi |   73 
  arch/powerpc/sysdev/fsl_rcpm.c |   43 
  2 files changed, 116 insertions(+)
  create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-power.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/qoriq-power.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-power.dtsi
new file mode 100644
index 000..c5c2ba0
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-power.dtsi
@@ -0,0 +1,73 @@
+/*
+ * QorIQ Power Management device tree stub
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/* IPPDEXPCR: IP Power Down EXcePtion Control Register */
+rcpm-power@e2140 {
+   compatible = "fsl,rcpm-ippdexpcr";
+   reg = <0xe2140 0x4>;
+
+   mac1_1_power: soc-power@0 {
+   fsl,ippdexpcr-mask = <0x8000>;
+   };
+   mac1_2_power: soc-power@1 {
+   fsl,ippdexpcr-mask = <0x4000>;
+   };
+   mac1_3_power: soc-power@2 {
+   fsl,ippdexpcr-mask = <0x2000>;
+   };
+   mac1_4_power: soc-power@3 {
+   fsl,ippdexpcr-mask = <0x1000>;
+   };
+   mac1_5_power: soc-power@4 {
+   fsl,ippdexpcr-mask = <0x0800>;
+   };
+   sdhc_power: soc-power@24 {
+   fsl,ippdexpcr-mask = <0x0080>;
+   };
+   gpio_power: soc-power@25 {
+   fsl,ippdexpcr-mask = <0x0040>;
+   };
+   usb1_power: soc-power@26 {
+   fsl,ippdexpcr-mask = <0x0020>;
+   };
+   usb2_power: soc-power@27 {
+   fsl,ippdexpcr-mask = <0x0010>;
+   };
+   fman1_power: soc-power@28 {
+   fsl,ippdexpcr-mask = <0x0008>;
+   };
+   sap_power: soc-power@31 {
+   fsl,ippdexpcr-mask = <0x0001>;
+   };
+};
diff --git a/arch/powerpc/sysdev/fsl_rcpm.c b/arch/powerpc/sysdev/fsl_rcpm.c
index ecf43a2..bc21aea 100644
--- a/arch/powerpc/sysdev/fsl_rcpm.c
+++ b/arch/powerpc/sysdev/fsl_rcpm.c
@@ -23,6 +23,49 @@
  struct ccsr_rcpm __iomem *rcpm1_regs;
  struct ccsr_rcpm_v2 __iomem *rcpm2_regs;
  
+/**

+ * fsl_rcpm_set_wake - enable/disable device working as wakeup source
+ * @dev: device affected
+ * @enable: true for keeping power on for this device during deep sleep
+ *  false otherwise
+ *
+ * return 0 on success, return -EINVAL if the device cannot wake up system
+ * and -ENODEV if RCPM unavailable
+ */
+int fsl_rcpm_set_wake(struct device *dev, bool enable)
+{
+   int ret = 0;
+   struct device_node *pw_np;
+   u32 pw_mask;
+
+   if (!rcpm2_regs) {
+   dev_err(dev, "%s: RCPM is unavailable\n", __func__);
+

Re: [PATCH v9 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

On 09/02/2013 11:58 PM, Mark Rutland wrote:

Hi,

On Fri, Aug 30, 2013 at 12:26:19PM +0100, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.

Signed-off-by: Hongbo Zhang 
---
  .../devicetree/bindings/powerpc/fsl/dma.txt|   67 
  arch/powerpc/boot/dts/fsl/b4si-post.dtsi   |4 +-
  arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi  |   82 
  arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi  |   82 
  arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
  5 files changed, 235 insertions(+), 4 deletions(-)
  create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
  create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt 
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index ddf17af..332ac77 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,73 @@ Example:
 };
 };

+** Freescale Elo3 DMA Controller
+   This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx

I was under the impression EloPlus was the previous revision. Should
that say Elo3, or is Elo3 considered to be an EloPlus implementation?
In this patch 1/3 I revise the doc to make it clear we have Elo and 
EloPlus, and I'm adding another new Elo3. Yes the only difference 
between Elo3 and EloPlus is channel numbers(8 channels vs 4 channels), 
so we can call "Elo3 is an 8-channel EloPlus"

+   series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include "fsl,elo3-dma"
+- reg   : 

The example has two reg entries. What both are should be specified. From
what you described last time, it sounds like each is a status register
for four channels.

Presumably the first covers the channels at 0x0,0x80,0x100,0x180, and
the second covers the channels at 0x300,0x380,0x400,0x480? If the
registers have specific names in a datasheet, it would be worth
mentioning them.
Yes, each is a status register for four channels, you got it -- this 
means my statement works.

Is it necessary to specify all the register names?
I can describe my two registers, but in other cases the reg entryies can 
cover tens even hundreds of registers, just a summary is OK I think.

If the specification of the DMA controller allows for more channels, it
may be worth describing that case now.
This DMA controller doesn't allows for more channels. (Even if it does, 
it should be another new controller)

+- ranges: describes the mapping between the address space of the
+  DMA channels and the address space of the DMA controller

This looks odd as a required property, and I'm slightly confused. Is
this used to map the reg values of the DMA channels, or is it used when
mapping the DMA address space (for which dma-ranges exists in ePAPR and
other bindings).

It is used to map the reg values of DMA channels.

+
+- DMA channel nodes:
+- compatible: must include "fsl,eloplus-dma-channel"
+- reg   : 

What does this represent? What are valid values?

In the example below it looks like these are offsets of control
registers within the dma controller.
Yes, they are offsets of control registers within dma controller, but 
the contents in these registers are for dma channels.
Physically we have dma controller registers and dma channel registers, 
they are in one continuous physical address space, we divide all these 
registers into two controller/channel parts, according to contents in 
these registers, common status registers for all channels are called dma 
controller registers, otherwise channel specific registers are called 
dma channel registers.

If the reg property may have any value, how do they get mapped to bits
in the status register(s)?
In fact, each channel has its own status register(and also other 
registers), the dma controller status register is just aggregation of 
all channel status register. (that seems duplicated somehow, maybe this 
is due to hardware compatibility with legacy one, and the device tree 
just describes the physical hardware without lie)

May some channels be unusable for some reason, or will all eight
channels be wired on any given Elo3 DMA?
Sorry, not get your point clearly, maybe you are clear now because of my 
previous explanations.

Cheers,
Mark.


+- interrupts: 
+- interrupt-parent  : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,elo3-dma";
+   reg = <0x100300 0x4>,
+ <0x100600 0x4>;
+   ranges = <0x0 

Re: [PATCH v8 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

On 08/28/2013 08:51 PM, Mark Rutland wrote:

On Wed, Aug 28, 2013 at 07:54:01AM +0100, Hongbo Zhang wrote:

On 08/27/2013 07:35 PM, Mark Rutland wrote:

On Tue, Aug 27, 2013 at 11:42:02AM +0100, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.

Signed-off-by: Hongbo Zhang 
---
   .../devicetree/bindings/powerpc/fsl/dma.txt|   66 
   arch/powerpc/boot/dts/fsl/b4si-post.dtsi   |4 +-
   arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi  |   81 

   arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi  |   81 

   arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
   5 files changed, 232 insertions(+), 4 deletions(-)
   create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
   create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt 
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index ddf17af..10fd031 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,72 @@ Example:
  };
  };

+** Freescale Elo3 DMA Controller
+   This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx
+   series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include "fsl,elo3-dma"
+- reg   : 
+- ranges: describes the mapping between the address space of the
+  DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+- compatible: must include "fsl,eloplus-dma-channel"
+- reg   : 
+- interrupts: 
+- interrupt-parent  : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,elo3-dma";
+   reg = <0x100300 0x4 0x100600 0x4>;

Is that one reg entry where #size-cells=2 and #address-cells=2?

That's what the binding implies (given it only describes a single reg
entry).

if it's two entries, we should make that explicit (both in the binding
and example):

reg = <0x100300 0x4>,
  <0x100600 0x4>;

Yes they are two entries, I will change it this way.

Ok. Could you make sure you document what the two reg entries correspond
to? That's not clear from "".
Yes I am sure, we have reg for DMA controller and also reg for each DMA 
channel.
these two reg entries are "registers specifier for DMA general status 
reg", not "registers specifier for channel"
because this is an 8-channel DMA controller, we have two general status 
registers (vs. one status register for 4-chanel DMA controller previously )

+   ranges = <0x0 0x100100 0x500>;

If it is one reg entry then the example ranges property isn't big enough
to contain the parent-bus-address.

They are two reg entries, so the range is big enough.

Ok.


+   dma-channel@0 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x0 0x80>;
+   interrupts = <28 2 0 0>;
+   };
+   dma-channel@80 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x80 0x80>;
+   interrupts = <29 2 0 0>;
+   };
+   dma-channel@100 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x100 0x80>;
+   interrupts = <30 2 0 0>;
+   };
+   dma-channel@180 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x180 0x80>;
+   interrupts = <31 2 0 0>;
+   };
+   dma-channel@300 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x300 0x80>;
+   interrupts = <76 2 0 0>;
+   };
+   dma-channel@380 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x380 0x80>;
+   interrupts = <77 2 0 0>;
+   };
+   dma-channel@400 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x400 0x80>;
+   interrupts = <78 2 0 0>;
+   };
+   dma-channel@480 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x480 0x80>;
+   interrupts = <79 2 0 0>;
+   };
+};
+
   Note on DMA channel compatible properties: The compatible property must say
   "fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
   driver (fsldma).  Any DMA channel used by fsld

Re: [PATCH v8 1/3] DMA: Freescale: revise device tree binding document

[Hongbo Zhang]

On 08/27/2013 07:25 PM, Mark Rutland wrote:

On Tue, Aug 27, 2013 at 11:42:01AM +0100, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

This patch updates the discription of each type of DMA controller and its
channels, it is preparation for adding another new DMA controller binding, it
also fixes some defects of indent for text alignment at the same time.

Signed-off-by: Hongbo Zhang 
---
  .../devicetree/bindings/powerpc/fsl/dma.txt|   62 +---
  1 file changed, 27 insertions(+), 35 deletions(-)

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt 
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index 2a4b4bc..ddf17af 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -1,33 +1,29 @@
-* Freescale 83xx DMA Controller
+* Freescale DMA Controllers
  
-Freescale PowerPC 83xx have on chip general purpose DMA controllers.

+** Freescale Elo DMA Controller
+   This is a little-endian DMA controller, used in Freescale mpc83xx series
+   chips such as mpc8315, mpc8349, mpc8379 etc.
  
  Required properties:
  
-- compatible: compatible list, contains 2 entries, first is

-"fsl,CHIP-dma", where CHIP is the processor
-(mpc8349, mpc8360, etc.) and the second is
-"fsl,elo-dma"
-- reg   : 
-- ranges   : Should be defined as specified in 1) to describe the
- DMA controller channels.
+- compatible: must include "fsl,elo-dma"

We should list the other values that may be in the list also, unless
they are really of no consequence, in which case their presence in dt is
questionable.

Hmm.  Stephen questioned here too, it seems this is a default rule.
Although Scott@freescale had explained our thoughts, I'd like to edit 
this item like this:


"must include "fsl,eloplus-dma", and a "fsl,CHIP-dma" is optional, where 
CHIP is the processor name"


We don't list all the chip name because we have tens of them and we 
cannot list all of them, and it is unnecessary to list them because we 
even don't use "fsl,CHIP-dma" in the new driver, add "fsl,CHIP-dma" here 
just make it questionable when it presents in example and  old dts files.


I remove the examples in bracket "(mpc8349, mpc8360, etc.)" because we 
can see the real example below.
I don't say" if "fsl,CHIP-dma" presents, it should be the first one, and 
the "fsl,eloplus-dma" should be the second" because it is common rule.

the description language should be clear and concise too I think.

+- reg   : 
+- ranges: describes the mapping between the address space of the
+  DMA channels and the address space of the DMA controller
  - cell-index: controller index.  0 for controller @ 0x8100
-- interrupts: 
+- interrupts: 
  - interrupt-parent  : optional, if needed for interrupt mapping
  
-

  - DMA channel nodes:
-- compatible: compatible list, contains 2 entries, first is
-"fsl,CHIP-dma-channel", where CHIP is the processor
-(mpc8349, mpc8350, etc.) and the second is
-"fsl,elo-dma-channel". However, see note below.
-- reg   : 
+- compatible: must include "fsl,elo-dma-channel"
+  However, see note below.

Again, I think we should list the other entries that may be in the list.
Otherwise it's not clear what the binding defines. Similarly for the
other compatible list definitions below...


+- reg   : 
  - cell-index: dma channel index starts at 0.

I realise you haven't changed it, but it's unclear what the cell-index
property is (and somewhat confusingly there seem to be multiple
defnitions). It might be worth clarifying it while performing the other
cleanup.
not clear with your point "multiple definitions", we really have 
multiple dma channels for one dma controller.
cell-index is used as channel index, this is an old method used by old 
driver, my patch didn't touch this part.
  
  Optional properties:

-- interrupts: 
- (on 83xx this is expected to be identical to
-  the interrupts property of the parent node)
+- interrupts: 
+  (on 83xx this is expected to be identical to
+  the interrupts property of the parent node)
  - interrupt-parent  : optional, if needed for interrupt mapping
  
  Example:

@@ -70,30 +66,26 @@ Example:
};
};
  
-* Freescale 85xx/86xx DMA Controller

-
-Freescale PowerPC 85xx/86xx have on chip general p

Re: [PATCH v8 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

On 08/27/2013 07:35 PM, Mark Rutland wrote:

On Tue, Aug 27, 2013 at 11:42:02AM +0100, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.

Signed-off-by: Hongbo Zhang 
---
  .../devicetree/bindings/powerpc/fsl/dma.txt|   66 
  arch/powerpc/boot/dts/fsl/b4si-post.dtsi   |4 +-
  arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi  |   81 
  arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi  |   81 
  arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
  5 files changed, 232 insertions(+), 4 deletions(-)
  create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
  create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt 
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index ddf17af..10fd031 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,72 @@ Example:
 };
 };

+** Freescale Elo3 DMA Controller
+   This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx
+   series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include "fsl,elo3-dma"
+- reg   : 
+- ranges: describes the mapping between the address space of the
+  DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+- compatible: must include "fsl,eloplus-dma-channel"
+- reg   : 
+- interrupts: 
+- interrupt-parent  : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,elo3-dma";
+   reg = <0x100300 0x4 0x100600 0x4>;

Is that one reg entry where #size-cells=2 and #address-cells=2?

That's what the binding implies (given it only describes a single reg
entry).

if it's two entries, we should make that explicit (both in the binding
and example):

reg = <0x100300 0x4>,
  <0x100600 0x4>;

Yes they are two entries, I will change it this way.

+   ranges = <0x0 0x100100 0x500>;

If it is one reg entry then the example ranges property isn't big enough
to contain the parent-bus-address.

They are two reg entries, so the range is big enough.



+   dma-channel@0 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x0 0x80>;
+   interrupts = <28 2 0 0>;
+   };
+   dma-channel@80 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x80 0x80>;
+   interrupts = <29 2 0 0>;
+   };
+   dma-channel@100 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x100 0x80>;
+   interrupts = <30 2 0 0>;
+   };
+   dma-channel@180 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x180 0x80>;
+   interrupts = <31 2 0 0>;
+   };
+   dma-channel@300 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x300 0x80>;
+   interrupts = <76 2 0 0>;
+   };
+   dma-channel@380 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x380 0x80>;
+   interrupts = <77 2 0 0>;
+   };
+   dma-channel@400 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x400 0x80>;
+   interrupts = <78 2 0 0>;
+   };
+   dma-channel@480 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x480 0x80>;
+   interrupts = <79 2 0 0>;
+   };
+};
+
  Note on DMA channel compatible properties: The compatible property must say
  "fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
  driver (fsldma).  Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
 reg = <0xe2000 0x1000>;
 };

-/include/ "qoriq-dma-0.dtsi"
+/include/ "elo3-dma-0.dtsi"
 dma@100300 {
 fsl,iommu-parent = <&pamu0>;
 fsl,liodn-reg = <&guts 0x580>; /* DMA1LIODNR */
 };

-/include/ "qoriq-dma-1.dtsi&quo

Re: [PATCH v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

On 08/23/2013 11:17 AM, Hongbo Zhang wrote:

On 08/22/2013 07:16 AM, Stephen Warren wrote:

On 08/21/2013 05:00 PM, Scott Wood wrote:

On Wed, 2013-08-21 at 16:40 -0600, Stephen Warren wrote:

On 07/29/2013 04:49 AM, hongbo.zh...@freescale.com wrote:

+- reg   : 
+- interrupts: IRQ>

s/interrupts/specifier/

Do you mean s/interrupt mapping/interrupt specifier/?

And probably s/registers mapping/register specifier/ as well.

Yup.


OK, I will update these descriptions.

Since Scott has clarified all the doubts, and no further comment till 
now, so my next iteration will include this s/mapping/specifier only.
I will sent it out this Tuesday, if there is still any comment/doubt, 
please let me know.



--
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 v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

On 08/22/2013 07:16 AM, Stephen Warren wrote:

On 08/21/2013 05:00 PM, Scott Wood wrote:

On Wed, 2013-08-21 at 16:40 -0600, Stephen Warren wrote:

On 07/29/2013 04:49 AM, hongbo.zh...@freescale.com wrote:

+- reg   : 
+- interrupts: 

s/interrupts/specifier/

Do you mean s/interrupt mapping/interrupt specifier/?

And probably s/registers mapping/register specifier/ as well.

Yup.


OK, I will update these descriptions.



--
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 v7 0/3] DMA: Freescale: Add support for 8-channel DMA engine

[Hongbo Zhang]

Hi DT maintainers,
Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren, Ian Campbell, 
could you please have a look at [1/3] and [2/3] of these patch set.
These patches have been fully reviewed by Scott Wood, and the DMA 
maintainer Vinod needs a Acted-by: from DT maintainers.

Thanks.

On 08/20/2013 04:15 PM, Vinod Koul wrote:

On Tue, Aug 20, 2013 at 04:33:46PM +0800, Hongbo Zhang wrote:

On 07/29/2013 06:59 PM, Vinod Koul wrote:

On Mon, Jul 29, 2013 at 06:49:01PM +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Hi Vinod, Dan, Scott and Leo, please have a look at these V7 patches.

The dma relates changes look okay to me.

I need someone to review and ACK the DT bindings.

~Vinod

Vinod,
Are you using this tree?
http://git.infradead.org/users/vkoul/slave-dma.git

Yes


Did you merge these patches?

No

As I said I would like someone who know DT and dma binding to ack them. I see
devicetree ML has been cced, can Arnd or someone else review these...

~Vinod





--
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 v7 0/3] DMA: Freescale: Add support for 8-channel DMA engine

[Hongbo Zhang]

On 07/29/2013 06:59 PM, Vinod Koul wrote:

On Mon, Jul 29, 2013 at 06:49:01PM +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Hi Vinod, Dan, Scott and Leo, please have a look at these V7 patches.

The dma relates changes look okay to me.

I need someone to review and ACK the DT bindings.

~Vinod

Vinod,
Are you using this tree?
http://git.infradead.org/users/vkoul/slave-dma.git
Did you merge these patches?
Thanks.

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set
adds support this DMA engine.

V6->V7 changes:
- only remove unnecessary "CHIP-dma" explanations in [1/3]

V5->V6 changes:
- minor updates of descriptions in binding document and Kconfig
- remove [4/4], that should be another patch in future

V4->V5 changes:
- update description in the dt binding document, to make it more resonable
- add new patch [4/4] to eliminate a compiling warning which already exists
   for a long time

V3->V4 changes:
- introduce new patch [1/3] to revise the legacy dma binding document
- and then add new paragraph to describe new dt node binding in [2/3]
- rebase to latest kernel v3.11-rc1

V2->V3 changes:
- edit Documentation/devicetree/bindings/powerpc/fsl/dma.txt
- edit text string in Kconfig and the driver files, using "elo series" to
   mention all the current "elo*"

V1->V2 changes:
- removed the codes handling the register dgsr1, since it isn't used currently
- renamed the DMA DT compatible to "fsl,elo3-dma"
- renamed the new dts files to "elo3-dma-.dtsi"

Hongbo Zhang (3):
   DMA: Freescale: revise device tree binding document
   DMA: Freescale: Add new 8-channel DMA engine device tree nodes
   DMA: Freescale: update driver to support 8-channel DMA engine

  .../devicetree/bindings/powerpc/fsl/dma.txt|  114 +++-
  arch/powerpc/boot/dts/fsl/b4si-post.dtsi   |4 +-
  arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi  |   81 ++
  arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi  |   81 ++
  arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
  drivers/dma/Kconfig|9 +-
  drivers/dma/fsldma.c   |9 +-
  drivers/dma/fsldma.h   |2 +-
  8 files changed, 264 insertions(+), 40 deletions(-)
  create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
  create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi

--
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 v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

On 07/30/2013 06:10 AM, Scott Wood wrote:

On 07/29/2013 05:49:03 AM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this 
patch adds

the device tree nodes for them.

Signed-off-by: Hongbo Zhang 
---
 .../devicetree/bindings/powerpc/fsl/dma.txt|   66 


 arch/powerpc/boot/dts/fsl/b4si-post.dtsi   |4 +-
 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi  |   81 

 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi  |   81 


 arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
 5 files changed, 232 insertions(+), 4 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi


ACK

Thank you Scott for all the review comments.


-Scott




--
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 v7 0/3] DMA: Freescale: Add support for 8-channel DMA engine

[Hongbo Zhang]

On 07/29/2013 06:59 PM, Vinod Koul wrote:

On Mon, Jul 29, 2013 at 06:49:01PM +0800, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Hi Vinod, Dan, Scott and Leo, please have a look at these V7 patches.

The dma relates changes look okay to me.

I need someone to review and ACK the DT bindings.

Scott Wood has ACKed the [1/3] and [2/3].
Thank you Vinod.


~Vinod

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set
adds support this DMA engine.

V6->V7 changes:
- only remove unnecessary "CHIP-dma" explanations in [1/3]

V5->V6 changes:
- minor updates of descriptions in binding document and Kconfig
- remove [4/4], that should be another patch in future

V4->V5 changes:
- update description in the dt binding document, to make it more resonable
- add new patch [4/4] to eliminate a compiling warning which already exists
   for a long time

V3->V4 changes:
- introduce new patch [1/3] to revise the legacy dma binding document
- and then add new paragraph to describe new dt node binding in [2/3]
- rebase to latest kernel v3.11-rc1

V2->V3 changes:
- edit Documentation/devicetree/bindings/powerpc/fsl/dma.txt
- edit text string in Kconfig and the driver files, using "elo series" to
   mention all the current "elo*"

V1->V2 changes:
- removed the codes handling the register dgsr1, since it isn't used currently
- renamed the DMA DT compatible to "fsl,elo3-dma"
- renamed the new dts files to "elo3-dma-.dtsi"

Hongbo Zhang (3):
   DMA: Freescale: revise device tree binding document
   DMA: Freescale: Add new 8-channel DMA engine device tree nodes
   DMA: Freescale: update driver to support 8-channel DMA engine

  .../devicetree/bindings/powerpc/fsl/dma.txt|  114 +++-
  arch/powerpc/boot/dts/fsl/b4si-post.dtsi   |4 +-
  arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi  |   81 ++
  arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi  |   81 ++
  arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
  drivers/dma/Kconfig|9 +-
  drivers/dma/fsldma.c   |9 +-
  drivers/dma/fsldma.h   |2 +-
  8 files changed, 264 insertions(+), 40 deletions(-)
  create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
  create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi

--
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 v5 4/4] DMA: Freescale: eliminate a compiling warning

[Hongbo Zhang]

On 07/25/2013 03:33 AM, Scott Wood wrote:

On 07/24/2013 01:21:09 AM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

The variable cookie is initialized in a list_for_each_entry loop, 
if(unlikely)
the list is empty, this variable will be used uninitialized, so we 
get a gcc

compiling warning about this. This patch fixes this defect by setting an
initial value to the varialble cookie.

Signed-off-by: Hongbo Zhang 
---
 drivers/dma/fsldma.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 16a9a48..14d68a4 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -406,7 +406,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct 
dma_async_tx_descriptor *tx)

 struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
 struct fsl_desc_sw *child;
 unsigned long flags;
-dma_cookie_t cookie;
+dma_cookie_t cookie = 0;

 spin_lock_irqsave(&chan->desc_lock, flags);


This patch is unrelated to the rest of the patch series...

What are the semantics of this function if there are multiple entries 
in the list?  Returning the last cookie seems a bit odd.


Is zero the proper error value?  include/linux/dmaengine.h suggests 
that cookies should be < 0 to indicate error.
I found this compiling warning since the beginning of this work, it is 
better somebody fixes it sooner or later, so I take it at last.
Yes it was a bit hard to define the initial value, I saw the 
dmaengine.h, and I searched all the other DMA drivers with initial value 
before making the decision:

drivers/dma/mv_xor.c:dma_cookie_t cookie = 0;
drivers/dma/sh/shdma-base.c:dma_cookie_t cookie = 0;
drivers/dma/mmp_pdma.c:dma_cookie_t cookie = -EBUSY;
drivers/dma/ppc4xx/adma.c:dma_cookie_t cookie = 0;
drivers/dma/iop-adma.c:dma_cookie_t cookie = 0;
most of them using 0, and only one negative value, it seems better? but 
-EBUSY isn't  so accurate I think.
My thought is to drop this in the next iteration, and back to this after 
the first 3 get merged.


-Scott




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

Re: [PATCH V2 1/2] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

On 07/15/2013 09:31 PM, Kumar Gala wrote:

On Jul 5, 2013, at 1:27 AM,  
 wrote:


From: Hongbo Zhang 

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch add
the device tree nodes for them.

Signed-off-by: Hongbo Zhang 
---
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi   |   90 +++
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi   |   90 +++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi |4 +-
3 files changed, 182 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi

Why didn't you update b4si-post.dtsi as well?

OK, will update it too, thanks.


- k




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

Re: [PATCH V2 1/2] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

On 07/10/2013 12:48 AM, Scott Wood wrote:

On 07/05/2013 01:27:05 AM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this 
patch add

the device tree nodes for them.

Signed-off-by: Hongbo Zhang 
---
 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi   |   90 
+++
 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi   |   90 
+++

 arch/powerpc/boot/dts/fsl/t4240si-post.dtsi |4 +-
 3 files changed, 182 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi


Please update Documentation/devicetree/bindings/powerpc/fsl/dma.txt 
for the new compatible and dgsr1.

OK, thanks.
What's more, some text string in the driver and Kconfig files should be 
updated too, e.g. "Elo / Elo Plus DMA" may be changed to "Elo series 
DMA", will send out v3 patches soon.


-Scott




--
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 1/2] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

On 07/03/2013 11:53 AM, Hongbo Zhang wrote:

hmm...add the devicetree-disc...@lists.ozlabs.org into list.

Note that we are discussing a better naming for this new compatible 
property in the corresponding [PATCH 2/2], so I will resend a v2 of 
this patch.



On 07/01/2013 11:46 AM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this 
patch add

the device tree nodes for them.

Signed-off-by: Hongbo Zhang 
---
  arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi |   90 
+++
  arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi |   90 
+++

  arch/powerpc/boot/dts/fsl/t4240si-post.dtsi |4 +-
  3 files changed, 182 insertions(+), 2 deletions(-)
  create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi
  create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi

Scott, any comment of these two file names?


diff --git a/arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi

new file mode 100644
index 000..c626c49
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi
@@ -0,0 +1,90 @@
+/*
+ * QorIQ DMA device tree stub [ controller @ offset 0x10 ]
+ *
+ * Copyright 2011-2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following 
conditions are met:

+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above 
copyright
+ *   notice, this list of conditions and the following 
disclaimer in the
+ *   documentation and/or other materials provided with the 
distribution.

+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote 
products
+ *   derived from this software without specific prior written 
permission.

+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms 
of the

+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' 
AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE 
FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 
OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 
CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE 
USE OF THIS

+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+dma0: dma@100300 {
+#address-cells = <1>;
+#size-cells = <1>;
+compatible = "fsl,eloplus-dma2";
+reg = <0x100300 0x4 0x100600 0x4>;
+ranges = <0x0 0x100100 0x500>;
+cell-index = <0>;
+dma-channel@0 {
+compatible = "fsl,eloplus-dma-channel";
+reg = <0x0 0x80>;
+cell-index = <0>;
+interrupts = <28 2 0 0>;
+};
+dma-channel@80 {
+compatible = "fsl,eloplus-dma-channel";
+reg = <0x80 0x80>;
+cell-index = <1>;
+interrupts = <29 2 0 0>;
+};
+dma-channel@100 {
+compatible = "fsl,eloplus-dma-channel";
+reg = <0x100 0x80>;
+cell-index = <2>;
+interrupts = <30 2 0 0>;
+};
+dma-channel@180 {
+compatible = "fsl,eloplus-dma-channel";
+reg = <0x180 0x80>;
+cell-index = <3>;
+interrupts = <31 2 0 0>;
+};
+dma-channel@300 {
+compatible = "fsl,eloplus-dma-channel";
+reg = <0x300 0x80>;
+cell-index = <4>;
+interrupts = <76 2 0 0>;
+};
+dma-channel@380 {
+compatible = "fsl,eloplus-dma-channel";
+reg = <0x380 0x80>;
+cell-index = <5>;
+interrupts = <77 2 0 0>;
+};
+dma-channel@400 {
+compatible = "fsl,eloplus-dma-channel";
+reg = <0x400 0x80>;
+cell-index = <6>;
+interrupts = <78 2 0 0>;
+};
+dma-channel@480 {
+compatible = "fsl,eloplus-dma-channel";
+reg = <0x480 0x80>;
+cell-index = <7>;
+interrupts = <79 2 0 0>;
+};
+};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-dma2-1

Re: [PATCH 1/2] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Hongbo Zhang]

hmm...add the devicetree-disc...@lists.ozlabs.org into list.

Note that we are discussing a better naming for this new compatible 
property in the corresponding [PATCH 2/2], so I will resend a v2 of this 
patch.



On 07/01/2013 11:46 AM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch add
the device tree nodes for them.

Signed-off-by: Hongbo Zhang 
---
  arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi |   90 +++
  arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi |   90 +++
  arch/powerpc/boot/dts/fsl/t4240si-post.dtsi |4 +-
  3 files changed, 182 insertions(+), 2 deletions(-)
  create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi
  create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi
new file mode 100644
index 000..c626c49
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi
@@ -0,0 +1,90 @@
+/*
+ * QorIQ DMA device tree stub [ controller @ offset 0x10 ]
+ *
+ * Copyright 2011-2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+dma0: dma@100300 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,eloplus-dma2";
+   reg = <0x100300 0x4 0x100600 0x4>;
+   ranges = <0x0 0x100100 0x500>;
+   cell-index = <0>;
+   dma-channel@0 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x0 0x80>;
+   cell-index = <0>;
+   interrupts = <28 2 0 0>;
+   };
+   dma-channel@80 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x80 0x80>;
+   cell-index = <1>;
+   interrupts = <29 2 0 0>;
+   };
+   dma-channel@100 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x100 0x80>;
+   cell-index = <2>;
+   interrupts = <30 2 0 0>;
+   };
+   dma-channel@180 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x180 0x80>;
+   cell-index = <3>;
+   interrupts = <31 2 0 0>;
+   };
+   dma-channel@300 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x300 0x80>;
+   cell-index = <4>;
+   interrupts = <76 2 0 0>;
+   };
+   dma-channel@380 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x380 0x80>;
+   cell-index = <5>;
+   interrupts = <77 2 0 0>;
+   };
+   dma-channel@400 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x400 0x80>;
+   cell-index = <6>;
+   interrupts = <78 2 0 0>;
+   };
+   dma-channel@480 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg =

Re: [PATCH 2/2] DMA: Freescale: update driver to support 8-channel DMA engine

[Hongbo Zhang]

On 07/03/2013 07:13 AM, Scott Wood wrote:

On 06/30/2013 10:46:18 PM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

This patch adds support to 8-channel DMA engine, thus the driver 
works for both

the new 8-channel and the legacy 4-channel DMA engines.

Signed-off-by: Hongbo Zhang 
---
 drivers/dma/fsldma.c |   48 
++--

 drivers/dma/fsldma.h |4 ++--
 2 files changed, 36 insertions(+), 16 deletions(-)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 4fc2980..0f453ea 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1119,27 +1119,33 @@ static irqreturn_t fsldma_ctrl_irq(int irq, 
void *data)

 struct fsldma_device *fdev = data;
 struct fsldma_chan *chan;
 unsigned int handled = 0;
-u32 gsr, mask;
+u8 chan_sr[round_up(FSL_DMA_MAX_CHANS_PER_DEVICE, 4)];
+u32 gsr;
 int i;

-gsr = (fdev->feature & FSL_DMA_BIG_ENDIAN) ? in_be32(fdev->regs)
-   : in_le32(fdev->regs);
-mask = 0xff00;
-dev_dbg(fdev->dev, "IRQ: gsr 0x%.8x\n", gsr);
+memset(&chan_sr, 0, sizeof(chan_sr));
+gsr = (fdev->feature & FSL_DMA_BIG_ENDIAN) ? in_be32(fdev->regs0)
+   : in_le32(fdev->regs0);
+memcpy(&chan_sr[0], &gsr, 4);
+dev_dbg(fdev->dev, "IRQ: gsr0 0x%.8x\n", gsr);
+
+if (of_device_is_compatible(fdev->dev->of_node, 
"fsl,eloplus-dma2")) {


NACK; Figure out what sort of device you've got when you first probe 
the device, and store the information for later.  Do not call device 
tree stuff in an interrupt handler.



+gsr = (fdev->feature & FSL_DMA_BIG_ENDIAN) ?
+in_be32(fdev->regs1) : in_le32(fdev->regs1);
+memcpy(&chan_sr[4], &gsr, 4);
+dev_dbg(fdev->dev, "IRQ: gsr1 0x%.8x\n", gsr);
+}


Do these memcpy()s get inlined?  If not (and maybe even if they do), 
it'd be better to use a union instead.



For this and the first comments: good catches, thank you.
But it is very likely I will remove these codes, see the last comments 
of yours and mine.
Wait a second -- how are we even getting into this code on these new 
DMA controllers?  All 85xx-family DMA controllers use fsldma_chan_irq 
directly.



Right, we are using fsldma_chan_irq, this code never run.
I just see there is such code for elo/eloplus DMA controllers, so I 
update it for the new 8-channel DMA.
@@ -1341,13 +1349,22 @@ static int fsldma_of_probe(struct 
platform_device *op)

 INIT_LIST_HEAD(&fdev->common.channels);

 /* ioremap the registers for use */
-fdev->regs = of_iomap(op->dev.of_node, 0);
-if (!fdev->regs) {
-dev_err(&op->dev, "unable to ioremap registers\n");
+fdev->regs0 = of_iomap(op->dev.of_node, 0);
+if (!fdev->regs0) {
+dev_err(&op->dev, "unable to ioremap register0\n");
 err = -ENOMEM;
 goto out_free_fdev;
 }

+if (of_device_is_compatible(op->dev.of_node, "fsl,eloplus-dma2")) {


Not "fsl,eloplusplus-dma"? :-)

More seriously, if we're sticking with this "elo" naming, maybe 
"fsl,elo3-dma" would be better.  It would be odd to have "2" in the 
name of the third generation of this hardware.



It was really hard for me to name this new controller.
Yes "fsl,elo3-dma" seems better.

diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..880664d 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,10 +112,10 @@ struct fsldma_chan_regs {
 };

 struct fsldma_chan;
-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8

 struct fsldma_device {
-void __iomem *regs;/* DGSR register base */
+void __iomem *regs0, *regs1;/* DGSR registers */


Either give these meaningful names, or use an array.  Or both (dgsr[2]).

Or just get rid of this, since I don't see why we need DGSR1 at all, 
as previously noted.



I choose the names regs* just to follow the previous pattern.

Here comes the key point: both the previous DGSR and the new DGSR0/DGSR1 
are not actually used because we are using per channel irq.
I see we had such codes to handle DGSR, so I just follow the same 
pattern to handle the new DGSR0/DGSR1.
Since getting rid of this unused  DGSR1 is permitted, I'd like to remove 
all the related codes, then this patch becomes simple :)



-Scott




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

[PATCH v8 4/5] ab8500: power: export abx500_res_to_temp tables for hwmon

[Hongbo Zhang]

This patch exports the thermistor resistance-to-temperature tables, so that the
hwmon driver can access them, and also adds the corresponding table size
variables.

Signed-off-by: Hongbo Zhang 
---
 drivers/power/ab8500_bmdata.c | 20 ++--
 include/linux/power/ab8500.h  | 16 
 2 files changed, 30 insertions(+), 6 deletions(-)
 create mode 100644 include/linux/power/ab8500.h

diff --git a/drivers/power/ab8500_bmdata.c b/drivers/power/ab8500_bmdata.c
index 3cdcdcf..d298645 100644
--- a/drivers/power/ab8500_bmdata.c
+++ b/drivers/power/ab8500_bmdata.c
@@ -11,7 +11,7 @@
  * Note that the res_to_temp table must be strictly sorted by falling 
resistance
  * values to work.
  */
-static const struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
+const struct abx500_res_to_temp ab8500_temp_tbl_a_thermistor[] = {
{-5, 53407},
{ 0, 48594},
{ 5, 43804},
@@ -28,8 +28,12 @@ static const struct abx500_res_to_temp 
temp_tbl_a_thermistor[] = {
{60, 13437},
{65, 12500},
 };
+EXPORT_SYMBOL(ab8500_temp_tbl_a_thermistor);
 
-static const struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
+const int ab8500_temp_tbl_a_size = ARRAY_SIZE(ab8500_temp_tbl_a_thermistor);
+EXPORT_SYMBOL(ab8500_temp_tbl_a_size);
+
+const struct abx500_res_to_temp ab8500_temp_tbl_b_thermistor[] = {
{-5, 20},
{ 0, 159024},
{ 5, 151921},
@@ -46,6 +50,10 @@ static const struct abx500_res_to_temp 
temp_tbl_b_thermistor[] = {
{60,  85461},
{65,  82869},
 };
+EXPORT_SYMBOL(ab8500_temp_tbl_b_thermistor);
+
+const int ab8500_temp_tbl_b_size = ARRAY_SIZE(ab8500_temp_tbl_b_thermistor);
+EXPORT_SYMBOL(ab8500_temp_tbl_b_size);
 
 static const struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
{4171,  100},
@@ -230,8 +238,8 @@ static struct abx500_battery_type bat_type_thermistor[] = {
.maint_b_chg_timer_h = 200,
.low_high_cur_lvl = 300,
.low_high_vol_lvl = 4000,
-   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_a_thermistor),
-   .r_to_t_tbl = temp_tbl_a_thermistor,
+   .n_temp_tbl_elements = ARRAY_SIZE(ab8500_temp_tbl_a_thermistor),
+   .r_to_t_tbl = ab8500_temp_tbl_a_thermistor,
.n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_a_thermistor),
.v_to_cap_tbl = cap_tbl_a_thermistor,
.n_batres_tbl_elements = 
ARRAY_SIZE(temp_to_batres_tbl_thermistor),
@@ -258,8 +266,8 @@ static struct abx500_battery_type bat_type_thermistor[] = {
.maint_b_chg_timer_h = 200,
.low_high_cur_lvl = 300,
.low_high_vol_lvl = 4000,
-   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_b_thermistor),
-   .r_to_t_tbl = temp_tbl_b_thermistor,
+   .n_temp_tbl_elements = ARRAY_SIZE(ab8500_temp_tbl_b_thermistor),
+   .r_to_t_tbl = ab8500_temp_tbl_b_thermistor,
.n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_b_thermistor),
.v_to_cap_tbl = cap_tbl_b_thermistor,
.n_batres_tbl_elements = 
ARRAY_SIZE(temp_to_batres_tbl_thermistor),
diff --git a/include/linux/power/ab8500.h b/include/linux/power/ab8500.h
new file mode 100644
index 000..cdbb6c2
--- /dev/null
+++ b/include/linux/power/ab8500.h
@@ -0,0 +1,16 @@
+/*
+ * Copyright (C) ST-Ericsson 2013
+ * Author: Hongbo Zhang 
+ * License terms: GNU General Public License v2
+ */
+
+#ifndef PWR_AB8500_H
+#define PWR_AB8500_H
+
+extern const struct abx500_res_to_temp ab8500_temp_tbl_a_thermistor[];
+extern const int ab8500_temp_tbl_a_size;
+
+extern const struct abx500_res_to_temp ab8500_temp_tbl_b_thermistor[];
+extern const int ab8500_temp_tbl_b_size;
+
+#endif /* PWR_AB8500_H */
-- 
1.8.0

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

[PATCH v8 5/5] hwmon: add ST-Ericsson ABX500 hwmon driver

[Hongbo Zhang]

Each of ST-Ericsson X500 chip set series consists of both ABX500 and DBX500
chips. This is ABX500 hwmon driver, where the abx500.c is a common layer for
all ABX500s, and the ab8500.c is specific for AB8500 chip. Under this designed
structure, other chip specific files can be added simply using the same common
layer abx500.c.

Signed-off-by: Hongbo Zhang 
---
 Documentation/hwmon/ab8500 |  22 ++
 Documentation/hwmon/abx500 |  28 +++
 drivers/hwmon/Kconfig  |  13 ++
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/ab8500.c | 206 +++
 drivers/hwmon/abx500.c | 491 +
 drivers/hwmon/abx500.h |  69 +++
 7 files changed, 830 insertions(+)
 create mode 100644 Documentation/hwmon/ab8500
 create mode 100644 Documentation/hwmon/abx500
 create mode 100644 drivers/hwmon/ab8500.c
 create mode 100644 drivers/hwmon/abx500.c
 create mode 100644 drivers/hwmon/abx500.h

diff --git a/Documentation/hwmon/ab8500 b/Documentation/hwmon/ab8500
new file mode 100644
index 000..cf169c8
--- /dev/null
+++ b/Documentation/hwmon/ab8500
@@ -0,0 +1,22 @@
+Kernel driver ab8500
+
+
+Supported chips:
+  * ST-Ericsson AB8500
+Prefix: 'ab8500'
+Addresses scanned: -
+Datasheet: http://www.stericsson.com/developers/documentation.jsp
+
+Authors:
+Martin Persson 
+    Hongbo Zhang 
+
+Description
+---
+
+See also Documentation/hwmon/abx500. This is the ST-Ericsson AB8500 specific
+driver.
+
+Currently only the AB8500 internal sensor and one external sensor for battery
+temperature are monitored. Other GPADC channels can also be monitored if needed
+in future.
diff --git a/Documentation/hwmon/abx500 b/Documentation/hwmon/abx500
new file mode 100644
index 000..319a058
--- /dev/null
+++ b/Documentation/hwmon/abx500
@@ -0,0 +1,28 @@
+Kernel driver abx500
+
+
+Supported chips:
+  * ST-Ericsson ABx500 series
+Prefix: 'abx500'
+Addresses scanned: -
+Datasheet: http://www.stericsson.com/developers/documentation.jsp
+
+Authors:
+Martin Persson 
+Hongbo Zhang 
+
+Description
+---
+
+Every ST-Ericsson Ux500 SOC consists of both ABx500 and DBx500 physically,
+this is kernel hwmon driver for ABx500.
+
+There are some GPADCs inside ABx500 which are designed for connecting to
+thermal sensors, and there is also a thermal sensor inside ABx500 too, which
+raises interrupt when critical temperature reached.
+
+This abx500 is a common layer which can monitor all of the sensors, every
+specific abx500 chip has its special configurations in its own file, e.g. some
+sensors can be configured invisible if they are not available on that chip, and
+the corresponding gpadc_addr should be set to 0, thus this sensor won't be
+polled.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 89ac1cb..108e0c1 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -39,6 +39,19 @@ config HWMON_DEBUG_CHIP
 
 comment "Native drivers"
 
+config SENSORS_AB8500
+   tristate "AB8500 thermal monitoring"
+   depends on AB8500_GPADC && AB8500_BM
+   default n
+   help
+ If you say yes here you get support for the thermal sensor part
+ of the AB8500 chip. The driver includes thermal management for
+ AB8500 die and two GPADC channels. The GPADC channel are preferably
+ used to access sensors outside the AB8500 chip.
+
+ This driver can also be built as a module.  If so, the module
+ will be called abx500-temp.
+
 config SENSORS_ABITUGURU
tristate "Abit uGuru (rev 1 & 2)"
depends on X86 && DMI
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 8d6d97e..526a37d 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_SENSORS_W83795)  += w83795.o
 obj-$(CONFIG_SENSORS_W83781D)  += w83781d.o
 obj-$(CONFIG_SENSORS_W83791D)  += w83791d.o
 
+obj-$(CONFIG_SENSORS_AB8500)   += abx500.o ab8500.o
 obj-$(CONFIG_SENSORS_ABITUGURU)+= abituguru.o
 obj-$(CONFIG_SENSORS_ABITUGURU3)+= abituguru3.o
 obj-$(CONFIG_SENSORS_AD7314)   += ad7314.o
diff --git a/drivers/hwmon/ab8500.c b/drivers/hwmon/ab8500.c
new file mode 100644
index 000..ee0aa3e
--- /dev/null
+++ b/drivers/hwmon/ab8500.c
@@ -0,0 +1,206 @@
+/*
+ * Copyright (C) ST-Ericsson 2010 - 2013
+ * Author: Martin Persson 
+ * Hongbo Zhang 
+ * License Terms: GNU General Public License v2
+ *
+ * When the AB8500 thermal warning temperature is reached (threshold cannot
+ * be changed by SW), an interrupt is set, and if no further action is taken
+ * within a certain time frame, pm_power off will be called.
+ *
+ * When AB8500 thermal shutdown temperature is reached a hardware shutdown of
+ * the AB8500 will occur.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#

[PATCH v8 3/5] ab8500: power: add const attributes to some data arrays

[Hongbo Zhang]

This patch adds const attributes to AB8500 power and temperature related
read-only data arrays.

Signed-off-by: Hongbo Zhang 
---
 drivers/power/ab8500_bmdata.c | 20 ++--
 drivers/power/ab8500_fg.c |  4 ++--
 include/linux/mfd/abx500.h|  6 +++---
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/power/ab8500_bmdata.c b/drivers/power/ab8500_bmdata.c
index 05ad966..3cdcdcf 100644
--- a/drivers/power/ab8500_bmdata.c
+++ b/drivers/power/ab8500_bmdata.c
@@ -11,7 +11,7 @@
  * Note that the res_to_temp table must be strictly sorted by falling 
resistance
  * values to work.
  */
-static struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
+static const struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
{-5, 53407},
{ 0, 48594},
{ 5, 43804},
@@ -29,7 +29,7 @@ static struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
{65, 12500},
 };
 
-static struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
+static const struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
{-5, 20},
{ 0, 159024},
{ 5, 151921},
@@ -47,7 +47,7 @@ static struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
{65,  82869},
 };
 
-static struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
+static const struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
{4171,  100},
{4114,   95},
{4009,   83},
@@ -70,7 +70,7 @@ static struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
{3247,0},
 };
 
-static struct abx500_v_to_cap cap_tbl_b_thermistor[] = {
+static const struct abx500_v_to_cap cap_tbl_b_thermistor[] = {
{4161,  100},
{4124,   98},
{4044,   90},
@@ -93,7 +93,7 @@ static struct abx500_v_to_cap cap_tbl_b_thermistor[] = {
{3250,0},
 };
 
-static struct abx500_v_to_cap cap_tbl[] = {
+static const struct abx500_v_to_cap cap_tbl[] = {
{4186,  100},
{4163,   99},
{4114,   95},
@@ -124,7 +124,7 @@ static struct abx500_v_to_cap cap_tbl[] = {
  * Note that the res_to_temp table must be strictly sorted by falling
  * resistance values to work.
  */
-static struct abx500_res_to_temp temp_tbl[] = {
+static const struct abx500_res_to_temp temp_tbl[] = {
{-5, 214834},
{ 0, 162943},
{ 5, 124820},
@@ -146,7 +146,7 @@ static struct abx500_res_to_temp temp_tbl[] = {
  * Note that the batres_vs_temp table must be strictly sorted by falling
  * temperature values to work.
  */
-static struct batres_vs_temp temp_to_batres_tbl_thermistor[] = {
+static const struct batres_vs_temp temp_to_batres_tbl_thermistor[] = {
{ 40, 120},
{ 30, 135},
{ 20, 165},
@@ -160,7 +160,7 @@ static struct batres_vs_temp 
temp_to_batres_tbl_thermistor[] = {
  * Note that the batres_vs_temp table must be strictly sorted by falling
  * temperature values to work.
  */
-static struct batres_vs_temp temp_to_batres_tbl_ext_thermistor[] = {
+static const struct batres_vs_temp temp_to_batres_tbl_ext_thermistor[] = {
{ 60, 300},
{ 30, 300},
{ 20, 300},
@@ -171,7 +171,7 @@ static struct batres_vs_temp 
temp_to_batres_tbl_ext_thermistor[] = {
 };
 
 /* battery resistance table for LI ION 9100 battery */
-static struct batres_vs_temp temp_to_batres_tbl_9100[] = {
+static const struct batres_vs_temp temp_to_batres_tbl_9100[] = {
{ 60, 180},
{ 30, 180},
{ 20, 180},
@@ -547,7 +547,7 @@ int ab8500_bm_of_probe(struct device *dev,
   struct device_node *np,
   struct abx500_bm_data *bm)
 {
-   struct batres_vs_temp *tmp_batres_tbl;
+   const struct batres_vs_temp *tmp_batres_tbl;
struct device_node *battery_node;
const char *btech;
int i;
diff --git a/drivers/power/ab8500_fg.c b/drivers/power/ab8500_fg.c
index 1601d27..c5391f5 100644
--- a/drivers/power/ab8500_fg.c
+++ b/drivers/power/ab8500_fg.c
@@ -863,7 +863,7 @@ static int ab8500_fg_bat_voltage(struct ab8500_fg *di)
 static int ab8500_fg_volt_to_capacity(struct ab8500_fg *di, int voltage)
 {
int i, tbl_size;
-   struct abx500_v_to_cap *tbl;
+   const struct abx500_v_to_cap *tbl;
int cap = 0;
 
tbl = di->bm->bat_type[di->bm->batt_id].v_to_cap_tbl,
@@ -915,7 +915,7 @@ static int ab8500_fg_uncomp_volt_to_capacity(struct 
ab8500_fg *di)
 static int ab8500_fg_battery_resistance(struct ab8500_fg *di)
 {
int i, tbl_size;
-   struct batres_vs_temp *tbl;
+   const struct batres_vs_temp *tbl;
int resist = 0;
 
tbl = di->bm->bat_type[di->bm->batt_id].batres_tbl;
diff --git a/include/linux/mfd/abx500.h b/include/linux/mfd/abx500.h
index 33b0253..3301b20 100644
--- a/include/linux/mfd/abx500.h
+++ b/include/linux/mfd/abx500.h
@@ -183,11 +183,11 @@ struct abx500_battery_type {
int low_high_vol_lvl;
int battery_resistance;
int n_temp_tbl_elements;
-   struct abx500_res_to_temp *r

[PATCH v8 2/5] ab8500: power: eliminate CamelCase warning of some variables

[Hongbo Zhang]

Some AB8500 power related variable names don't comply with kernel coding rules,
any new patch using these variables will result in CamelCase warnings from
checkpatch.pl, this patch re-name these variables.

Signed-off-by: Hongbo Zhang 
---
 drivers/power/ab8500_bmdata.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/power/ab8500_bmdata.c b/drivers/power/ab8500_bmdata.c
index 85742a6..05ad966 100644
--- a/drivers/power/ab8500_bmdata.c
+++ b/drivers/power/ab8500_bmdata.c
@@ -11,7 +11,7 @@
  * Note that the res_to_temp table must be strictly sorted by falling 
resistance
  * values to work.
  */
-static struct abx500_res_to_temp temp_tbl_A_thermistor[] = {
+static struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
{-5, 53407},
{ 0, 48594},
{ 5, 43804},
@@ -29,7 +29,7 @@ static struct abx500_res_to_temp temp_tbl_A_thermistor[] = {
{65, 12500},
 };
 
-static struct abx500_res_to_temp temp_tbl_B_thermistor[] = {
+static struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
{-5, 20},
{ 0, 159024},
{ 5, 151921},
@@ -47,7 +47,7 @@ static struct abx500_res_to_temp temp_tbl_B_thermistor[] = {
{65,  82869},
 };
 
-static struct abx500_v_to_cap cap_tbl_A_thermistor[] = {
+static struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
{4171,  100},
{4114,   95},
{4009,   83},
@@ -70,7 +70,7 @@ static struct abx500_v_to_cap cap_tbl_A_thermistor[] = {
{3247,0},
 };
 
-static struct abx500_v_to_cap cap_tbl_B_thermistor[] = {
+static struct abx500_v_to_cap cap_tbl_b_thermistor[] = {
{4161,  100},
{4124,   98},
{4044,   90},
@@ -230,10 +230,10 @@ static struct abx500_battery_type bat_type_thermistor[] = 
{
.maint_b_chg_timer_h = 200,
.low_high_cur_lvl = 300,
.low_high_vol_lvl = 4000,
-   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_A_thermistor),
-   .r_to_t_tbl = temp_tbl_A_thermistor,
-   .n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_A_thermistor),
-   .v_to_cap_tbl = cap_tbl_A_thermistor,
+   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_a_thermistor),
+   .r_to_t_tbl = temp_tbl_a_thermistor,
+   .n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_a_thermistor),
+   .v_to_cap_tbl = cap_tbl_a_thermistor,
.n_batres_tbl_elements = 
ARRAY_SIZE(temp_to_batres_tbl_thermistor),
.batres_tbl = temp_to_batres_tbl_thermistor,
 
@@ -258,10 +258,10 @@ static struct abx500_battery_type bat_type_thermistor[] = 
{
.maint_b_chg_timer_h = 200,
.low_high_cur_lvl = 300,
.low_high_vol_lvl = 4000,
-   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_B_thermistor),
-   .r_to_t_tbl = temp_tbl_B_thermistor,
-   .n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_B_thermistor),
-   .v_to_cap_tbl = cap_tbl_B_thermistor,
+   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_b_thermistor),
+   .r_to_t_tbl = temp_tbl_b_thermistor,
+   .n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_b_thermistor),
+   .v_to_cap_tbl = cap_tbl_b_thermistor,
.n_batres_tbl_elements = 
ARRAY_SIZE(temp_to_batres_tbl_thermistor),
.batres_tbl = temp_to_batres_tbl_thermistor,
},
-- 
1.8.0

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

[PATCH v8 1/5] ab8500_btemp: make ab8500_btemp_get* interfaces public

[Hongbo Zhang]

Make ab8500_btemp_get_temp interface public, export it and also export the
ab8500_btemp_get, ab8500_btemp_get_batctrl_temp interfaces, so that the ab8500
hwmon driver can use them.

Signed-off-by: Hongbo Zhang 
---
 drivers/power/ab8500_btemp.c | 5 -
 include/linux/mfd/abx500/ab8500-bm.h | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/power/ab8500_btemp.c b/drivers/power/ab8500_btemp.c
index a9486f1..d412d34 100644
--- a/drivers/power/ab8500_btemp.c
+++ b/drivers/power/ab8500_btemp.c
@@ -131,6 +131,7 @@ struct ab8500_btemp *ab8500_btemp_get(void)
 
return btemp;
 }
+EXPORT_SYMBOL(ab8500_btemp_get);
 
 /**
  * ab8500_btemp_batctrl_volt_to_res() - convert batctrl voltage to resistance
@@ -815,7 +816,7 @@ static void ab8500_btemp_periodic(struct ab8500_btemp *di,
  *
  * Returns battery temperature
  */
-static int ab8500_btemp_get_temp(struct ab8500_btemp *di)
+int ab8500_btemp_get_temp(struct ab8500_btemp *di)
 {
int temp = 0;
 
@@ -851,6 +852,7 @@ static int ab8500_btemp_get_temp(struct ab8500_btemp *di)
}
return temp;
 }
+EXPORT_SYMBOL(ab8500_btemp_get_temp);
 
 /**
  * ab8500_btemp_get_batctrl_temp() - get the temperature
@@ -862,6 +864,7 @@ int ab8500_btemp_get_batctrl_temp(struct ab8500_btemp 
*btemp)
 {
return btemp->bat_temp * 1000;
 }
+EXPORT_SYMBOL(ab8500_btemp_get_batctrl_temp);
 
 /**
  * ab8500_btemp_get_property() - get the btemp properties
diff --git a/include/linux/mfd/abx500/ab8500-bm.h 
b/include/linux/mfd/abx500/ab8500-bm.h
index f5214dc..cc892a8 100644
--- a/include/linux/mfd/abx500/ab8500-bm.h
+++ b/include/linux/mfd/abx500/ab8500-bm.h
@@ -465,6 +465,7 @@ void ab8500_fg_reinit(void);
 void ab8500_charger_usb_state_changed(u8 bm_usb_state, u16 mA);
 struct ab8500_btemp *ab8500_btemp_get(void);
 int ab8500_btemp_get_batctrl_temp(struct ab8500_btemp *btemp);
+int ab8500_btemp_get_temp(struct ab8500_btemp *btemp);
 struct ab8500_fg *ab8500_fg_get(void);
 int ab8500_fg_inst_curr_blocking(struct ab8500_fg *dev);
 int ab8500_fg_inst_curr_start(struct ab8500_fg *di);
-- 
1.8.0

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

[PATCH v8 0/5] Add ST-Ericsson AB8500 HWMON driver

[Hongbo Zhang]

Guenter and Anton,
As suggested by Anton, I rebased these patches to his latest battery-2.6 tree.
Thanks.

v7 -> v8 changes:
- rebase these patches to Anton's latest battery-2.6 tree.

v6 -> v7 changes:
- move exporting symbols from [5/5] to [4/5], which was a mistake.

v5 -> v6 changes:
- add depend on AB8500_BM in Kconfig
- fix wrong usage of clamp_val()
- export symbols for module compiling

v4 -> v5 changes:
- split the old [2/3]-ab8500-re-arrange-ab8500-power-and-temperature-data into
  new three [2/5], [3/5] and [4/5] patches.
- hwmon driver minor coding style clean ups:
  - {} usage in if-else statement in ab8500_read_sensor function
  - index error fix in gpadc_monitor function
  - fix issue of clamp_val() usage
  - remove unnecessary else in function abx500_attrs_visible
  - remove redundant print message about irq set up
  - return the calling function return value directly in probe function

v3 -> v4 changes:
for patch [3/3]
- define delays in HZ
- update ab8500_read_sensor function, returning temp by parameter
- remove ab8500_is_visible function
- use clamp_val in set_min and set_max callback
- remove unnecessary locks in remove and suspend functions
- let abx500 and ab8500 use its own data structure
for patch [2/3]
- move the data tables from driver/power/ab8500_bmdata.c to
  include/linux/power/ab8500.h
- rename driver/power/ab8500_bmdata.c to driver/power/ab8500_bm.c
- rename these variable names to eliminate CamelCase warnings
- add const attribute to these data

v2 -> v3 changes:
- Add interface for converting voltage to temperature
- Remove temp5 sensor since we cannot offer temperature read interface of it
- Update hyst to use absolute temperature instead of a difference
- Add the 3/3 patch

v1 -> v2 changes:
- Add Documentation/hwmon/abx500 and Documentation/hwmon/abx500
- Make devices which cannot report milli-Celsius invisible
- Add temp5_crit interface
- Re-work the old find_active_thresholds() to threshold_updated()
- Reset updated_min_alarm and updated_max_alarm at the end of each loop
- Update the hyst mechamisn to make it works as real hyst
- Remove non-stand attributes
- Re-order the operations sequence inside probe and remove functions
- Update all the lock usages to eliminate race conditions
- Make attibutes index starts from 0
also changes:
- Since the old [1/2] "ARM: ux500: rename ab8500 to abx500 for hwmon driver"
  has been merged by Samuel, so won't send it again.
- Add another new patch "ab8500_btemp: export two symblols" as [2/2] of this
  patch set.

Hongbo Zhang (5):
  ab8500_btemp: make ab8500_btemp_get* interfaces public
  ab8500: power: eliminate CamelCase warning of some variables
  ab8500: power: add const attributes to some data arrays
  ab8500: power: export abx500_res_to_temp tables for hwmon
  hwmon: add ST-Ericsson ABX500 hwmon driver

 Documentation/hwmon/ab8500   |  22 ++
 Documentation/hwmon/abx500   |  28 ++
 drivers/hwmon/Kconfig|  13 +
 drivers/hwmon/Makefile   |   1 +
 drivers/hwmon/ab8500.c   | 206 +++
 drivers/hwmon/abx500.c   | 491 +++
 drivers/hwmon/abx500.h   |  69 +
 drivers/power/ab8500_bmdata.c|  44 ++--
 drivers/power/ab8500_btemp.c |   5 +-
 drivers/power/ab8500_fg.c|   4 +-
 include/linux/mfd/abx500.h   |   6 +-
 include/linux/mfd/abx500/ab8500-bm.h |   1 +
 include/linux/power/ab8500.h |  16 ++
 13 files changed, 882 insertions(+), 24 deletions(-)
 create mode 100644 Documentation/hwmon/ab8500
 create mode 100644 Documentation/hwmon/abx500
 create mode 100644 drivers/hwmon/ab8500.c
 create mode 100644 drivers/hwmon/abx500.c
 create mode 100644 drivers/hwmon/abx500.h
 create mode 100644 include/linux/power/ab8500.h

-- 
1.8.0

--
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 v7 5/5] hwmon: add ST-Ericsson ABX500 hwmon driver

[Hongbo Zhang]

On 28 March 2013 03:48, Guenter Roeck  wrote:
> On Wed, Mar 27, 2013 at 03:13:32PM +0800, Hongbo Zhang wrote:
>> Each of ST-Ericsson X500 chip set series consists of both ABX500 and DBX500
>> chips. This is ABX500 hwmon driver, where the abx500.c is a common layer for
>> all ABX500s, and the ab8500.c is specific for AB8500 chip. Under this 
>> designed
>> structure, other chip specific files can be added simply using the same 
>> common
>> layer abx500.c.
>>
>> Signed-off-by: Hongbo Zhang 
>
> Reviewed-by: Guenter Roeck 

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

[PATCH v7 5/5] hwmon: add ST-Ericsson ABX500 hwmon driver

[Hongbo Zhang]

Each of ST-Ericsson X500 chip set series consists of both ABX500 and DBX500
chips. This is ABX500 hwmon driver, where the abx500.c is a common layer for
all ABX500s, and the ab8500.c is specific for AB8500 chip. Under this designed
structure, other chip specific files can be added simply using the same common
layer abx500.c.

Signed-off-by: Hongbo Zhang 
---
 Documentation/hwmon/ab8500 |  22 ++
 Documentation/hwmon/abx500 |  28 +++
 drivers/hwmon/Kconfig  |  13 ++
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/ab8500.c | 206 +++
 drivers/hwmon/abx500.c | 491 +
 drivers/hwmon/abx500.h |  69 +++
 7 files changed, 830 insertions(+)
 create mode 100644 Documentation/hwmon/ab8500
 create mode 100644 Documentation/hwmon/abx500
 create mode 100644 drivers/hwmon/ab8500.c
 create mode 100644 drivers/hwmon/abx500.c
 create mode 100644 drivers/hwmon/abx500.h

diff --git a/Documentation/hwmon/ab8500 b/Documentation/hwmon/ab8500
new file mode 100644
index 000..cf169c8
--- /dev/null
+++ b/Documentation/hwmon/ab8500
@@ -0,0 +1,22 @@
+Kernel driver ab8500
+
+
+Supported chips:
+  * ST-Ericsson AB8500
+Prefix: 'ab8500'
+Addresses scanned: -
+Datasheet: http://www.stericsson.com/developers/documentation.jsp
+
+Authors:
+Martin Persson 
+    Hongbo Zhang 
+
+Description
+---
+
+See also Documentation/hwmon/abx500. This is the ST-Ericsson AB8500 specific
+driver.
+
+Currently only the AB8500 internal sensor and one external sensor for battery
+temperature are monitored. Other GPADC channels can also be monitored if needed
+in future.
diff --git a/Documentation/hwmon/abx500 b/Documentation/hwmon/abx500
new file mode 100644
index 000..319a058
--- /dev/null
+++ b/Documentation/hwmon/abx500
@@ -0,0 +1,28 @@
+Kernel driver abx500
+
+
+Supported chips:
+  * ST-Ericsson ABx500 series
+Prefix: 'abx500'
+Addresses scanned: -
+Datasheet: http://www.stericsson.com/developers/documentation.jsp
+
+Authors:
+Martin Persson 
+Hongbo Zhang 
+
+Description
+---
+
+Every ST-Ericsson Ux500 SOC consists of both ABx500 and DBx500 physically,
+this is kernel hwmon driver for ABx500.
+
+There are some GPADCs inside ABx500 which are designed for connecting to
+thermal sensors, and there is also a thermal sensor inside ABx500 too, which
+raises interrupt when critical temperature reached.
+
+This abx500 is a common layer which can monitor all of the sensors, every
+specific abx500 chip has its special configurations in its own file, e.g. some
+sensors can be configured invisible if they are not available on that chip, and
+the corresponding gpadc_addr should be set to 0, thus this sensor won't be
+polled.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 32f238f..d0d6b52 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -39,6 +39,19 @@ config HWMON_DEBUG_CHIP
 
 comment "Native drivers"
 
+config SENSORS_AB8500
+   tristate "AB8500 thermal monitoring"
+   depends on AB8500_GPADC && AB8500_BM
+   default n
+   help
+ If you say yes here you get support for the thermal sensor part
+ of the AB8500 chip. The driver includes thermal management for
+ AB8500 die and two GPADC channels. The GPADC channel are preferably
+ used to access sensors outside the AB8500 chip.
+
+ This driver can also be built as a module.  If so, the module
+ will be called abx500-temp.
+
 config SENSORS_ABITUGURU
tristate "Abit uGuru (rev 1 & 2)"
depends on X86 && DMI
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 5da2874..06dfe85 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_SENSORS_W83795)  += w83795.o
 obj-$(CONFIG_SENSORS_W83781D)  += w83781d.o
 obj-$(CONFIG_SENSORS_W83791D)  += w83791d.o
 
+obj-$(CONFIG_SENSORS_AB8500)   += abx500.o ab8500.o
 obj-$(CONFIG_SENSORS_ABITUGURU)+= abituguru.o
 obj-$(CONFIG_SENSORS_ABITUGURU3)+= abituguru3.o
 obj-$(CONFIG_SENSORS_AD7314)   += ad7314.o
diff --git a/drivers/hwmon/ab8500.c b/drivers/hwmon/ab8500.c
new file mode 100644
index 000..ee0aa3e
--- /dev/null
+++ b/drivers/hwmon/ab8500.c
@@ -0,0 +1,206 @@
+/*
+ * Copyright (C) ST-Ericsson 2010 - 2013
+ * Author: Martin Persson 
+ * Hongbo Zhang 
+ * License Terms: GNU General Public License v2
+ *
+ * When the AB8500 thermal warning temperature is reached (threshold cannot
+ * be changed by SW), an interrupt is set, and if no further action is taken
+ * within a certain time frame, pm_power off will be called.
+ *
+ * When AB8500 thermal shutdown temperature is reached a hardware shutdown of
+ * the AB8500 will occur.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#

[PATCH v7 4/5] ab8500: power: export abx500_res_to_temp tables for hwmon

[Hongbo Zhang]

This patch exports the thermistor resistance-to-temperature tables, so that the
hwmon driver can access them, and also adds the corresponding table size
variables.

Signed-off-by: Hongbo Zhang 
---
 drivers/power/ab8500_bmdata.c | 20 ++--
 include/linux/power/ab8500.h  | 16 
 2 files changed, 30 insertions(+), 6 deletions(-)
 create mode 100644 include/linux/power/ab8500.h

diff --git a/drivers/power/ab8500_bmdata.c b/drivers/power/ab8500_bmdata.c
index 9c25ca8..05a1077 100644
--- a/drivers/power/ab8500_bmdata.c
+++ b/drivers/power/ab8500_bmdata.c
@@ -11,7 +11,7 @@
  * Note that the res_to_temp table must be strictly sorted by falling 
resistance
  * values to work.
  */
-static const struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
+const struct abx500_res_to_temp ab8500_temp_tbl_a_thermistor[] = {
{-5, 53407},
{ 0, 48594},
{ 5, 43804},
@@ -28,8 +28,12 @@ static const struct abx500_res_to_temp 
temp_tbl_a_thermistor[] = {
{60, 13437},
{65, 12500},
 };
+EXPORT_SYMBOL(ab8500_temp_tbl_a_thermistor);
 
-static const struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
+const int ab8500_temp_tbl_a_size = ARRAY_SIZE(ab8500_temp_tbl_a_thermistor);
+EXPORT_SYMBOL(ab8500_temp_tbl_a_size);
+
+const struct abx500_res_to_temp ab8500_temp_tbl_b_thermistor[] = {
{-5, 20},
{ 0, 159024},
{ 5, 151921},
@@ -46,6 +50,10 @@ static const struct abx500_res_to_temp 
temp_tbl_b_thermistor[] = {
{60,  85461},
{65,  82869},
 };
+EXPORT_SYMBOL(ab8500_temp_tbl_b_thermistor);
+
+const int ab8500_temp_tbl_b_size = ARRAY_SIZE(ab8500_temp_tbl_b_thermistor);
+EXPORT_SYMBOL(ab8500_temp_tbl_b_size);
 
 static const struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
{4171,  100},
@@ -230,8 +238,8 @@ static struct abx500_battery_type bat_type_thermistor[] = {
.maint_b_chg_timer_h = 200,
.low_high_cur_lvl = 300,
.low_high_vol_lvl = 4000,
-   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_a_thermistor),
-   .r_to_t_tbl = temp_tbl_a_thermistor,
+   .n_temp_tbl_elements = ARRAY_SIZE(ab8500_temp_tbl_a_thermistor),
+   .r_to_t_tbl = ab8500_temp_tbl_a_thermistor,
.n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_a_thermistor),
.v_to_cap_tbl = cap_tbl_a_thermistor,
.n_batres_tbl_elements = ARRAY_SIZE(temp_to_batres_tbl_thermistor),
@@ -258,8 +266,8 @@ static struct abx500_battery_type bat_type_thermistor[] = {
.maint_b_chg_timer_h = 200,
.low_high_cur_lvl = 300,
.low_high_vol_lvl = 4000,
-   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_b_thermistor),
-   .r_to_t_tbl = temp_tbl_b_thermistor,
+   .n_temp_tbl_elements = ARRAY_SIZE(ab8500_temp_tbl_b_thermistor),
+   .r_to_t_tbl = ab8500_temp_tbl_b_thermistor,
.n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_b_thermistor),
.v_to_cap_tbl = cap_tbl_b_thermistor,
.n_batres_tbl_elements = ARRAY_SIZE(temp_to_batres_tbl_thermistor),
diff --git a/include/linux/power/ab8500.h b/include/linux/power/ab8500.h
new file mode 100644
index 000..cdbb6c2
--- /dev/null
+++ b/include/linux/power/ab8500.h
@@ -0,0 +1,16 @@
+/*
+ * Copyright (C) ST-Ericsson 2013
+ * Author: Hongbo Zhang 
+ * License terms: GNU General Public License v2
+ */
+
+#ifndef PWR_AB8500_H
+#define PWR_AB8500_H
+
+extern const struct abx500_res_to_temp ab8500_temp_tbl_a_thermistor[];
+extern const int ab8500_temp_tbl_a_size;
+
+extern const struct abx500_res_to_temp ab8500_temp_tbl_b_thermistor[];
+extern const int ab8500_temp_tbl_b_size;
+
+#endif /* PWR_AB8500_H */
-- 
1.8.0

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

[PATCH v7 3/5] ab8500: power: add const attributes to some data arrays

[Hongbo Zhang]

This patch adds const attributes to AB8500 power and temperature related
read-only data arrays.

Signed-off-by: Hongbo Zhang 
---
 drivers/power/ab8500_bmdata.c | 18 +-
 drivers/power/ab8500_fg.c |  4 ++--
 include/linux/mfd/abx500.h|  6 +++---
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/power/ab8500_bmdata.c b/drivers/power/ab8500_bmdata.c
index f836550..9c25ca8 100644
--- a/drivers/power/ab8500_bmdata.c
+++ b/drivers/power/ab8500_bmdata.c
@@ -11,7 +11,7 @@
  * Note that the res_to_temp table must be strictly sorted by falling 
resistance
  * values to work.
  */
-static struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
+static const struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
{-5, 53407},
{ 0, 48594},
{ 5, 43804},
@@ -29,7 +29,7 @@ static struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
{65, 12500},
 };
 
-static struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
+static const struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
{-5, 20},
{ 0, 159024},
{ 5, 151921},
@@ -47,7 +47,7 @@ static struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
{65,  82869},
 };
 
-static struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
+static const struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
{4171,  100},
{4114,   95},
{4009,   83},
@@ -70,7 +70,7 @@ static struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
{3247,0},
 };
 
-static struct abx500_v_to_cap cap_tbl_b_thermistor[] = {
+static const struct abx500_v_to_cap cap_tbl_b_thermistor[] = {
{4161,  100},
{4124,   98},
{4044,   90},
@@ -93,7 +93,7 @@ static struct abx500_v_to_cap cap_tbl_b_thermistor[] = {
{3250,0},
 };
 
-static struct abx500_v_to_cap cap_tbl[] = {
+static const struct abx500_v_to_cap cap_tbl[] = {
{4186,  100},
{4163,   99},
{4114,   95},
@@ -124,7 +124,7 @@ static struct abx500_v_to_cap cap_tbl[] = {
  * Note that the res_to_temp table must be strictly sorted by falling
  * resistance values to work.
  */
-static struct abx500_res_to_temp temp_tbl[] = {
+static const struct abx500_res_to_temp temp_tbl[] = {
{-5, 214834},
{ 0, 162943},
{ 5, 124820},
@@ -146,7 +146,7 @@ static struct abx500_res_to_temp temp_tbl[] = {
  * Note that the batres_vs_temp table must be strictly sorted by falling
  * temperature values to work.
  */
-static struct batres_vs_temp temp_to_batres_tbl_thermistor[] = {
+static const struct batres_vs_temp temp_to_batres_tbl_thermistor[] = {
{ 40, 120},
{ 30, 135},
{ 20, 165},
@@ -160,7 +160,7 @@ static struct batres_vs_temp 
temp_to_batres_tbl_thermistor[] = {
  * Note that the batres_vs_temp table must be strictly sorted by falling
  * temperature values to work.
  */
-static struct batres_vs_temp temp_to_batres_tbl_ext_thermistor[] = {
+static const struct batres_vs_temp temp_to_batres_tbl_ext_thermistor[] = {
{ 60, 300},
{ 30, 300},
{ 20, 300},
@@ -171,7 +171,7 @@ static struct batres_vs_temp 
temp_to_batres_tbl_ext_thermistor[] = {
 };
 
 /* battery resistance table for LI ION 9100 battery */
-static struct batres_vs_temp temp_to_batres_tbl_9100[] = {
+static const struct batres_vs_temp temp_to_batres_tbl_9100[] = {
{ 60, 180},
{ 30, 180},
{ 20, 180},
diff --git a/drivers/power/ab8500_fg.c b/drivers/power/ab8500_fg.c
index b3bf178..d21456d 100644
--- a/drivers/power/ab8500_fg.c
+++ b/drivers/power/ab8500_fg.c
@@ -811,7 +811,7 @@ static int ab8500_fg_bat_voltage(struct ab8500_fg *di)
 static int ab8500_fg_volt_to_capacity(struct ab8500_fg *di, int voltage)
 {
int i, tbl_size;
-   struct abx500_v_to_cap *tbl;
+   const struct abx500_v_to_cap *tbl;
int cap = 0;
 
tbl = di->bat->bat_type[di->bat->batt_id].v_to_cap_tbl,
@@ -863,7 +863,7 @@ static int ab8500_fg_uncomp_volt_to_capacity(struct 
ab8500_fg *di)
 static int ab8500_fg_battery_resistance(struct ab8500_fg *di)
 {
int i, tbl_size;
-   struct batres_vs_temp *tbl;
+   const struct batres_vs_temp *tbl;
int resist = 0;
 
tbl = di->bat->bat_type[di->bat->batt_id].batres_tbl;
diff --git a/include/linux/mfd/abx500.h b/include/linux/mfd/abx500.h
index 2138bd3..03fc0f1 100644
--- a/include/linux/mfd/abx500.h
+++ b/include/linux/mfd/abx500.h
@@ -173,11 +173,11 @@ struct abx500_battery_type {
int low_high_vol_lvl;
int battery_resistance;
int n_temp_tbl_elements;
-   struct abx500_res_to_temp *r_to_t_tbl;
+   const struct abx500_res_to_temp *r_to_t_tbl;
int n_v_cap_tbl_elements;
-   struct abx500_v_to_cap *v_to_cap_tbl;
+   const struct abx500_v_to_cap *v_to_cap_tbl;
int n_batres_tbl_elements;
-   struct batres_vs_temp *batres_tbl;
+   const struct batres_vs_temp *batres_tbl;
 };
 
 /**
-- 
1.8.0

[PATCH v7 2/5] ab8500: power: eliminate CamelCase warning of some variables

[Hongbo Zhang]

Some AB8500 power related variable names don't comply with kernel coding rules,
any new patch using these variables will result in CamelCase warnings from
checkpatch.pl, this patch re-name these variables.

Signed-off-by: Hongbo Zhang 
---
 drivers/power/ab8500_bmdata.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/power/ab8500_bmdata.c b/drivers/power/ab8500_bmdata.c
index f034ae4..f836550 100644
--- a/drivers/power/ab8500_bmdata.c
+++ b/drivers/power/ab8500_bmdata.c
@@ -11,7 +11,7 @@
  * Note that the res_to_temp table must be strictly sorted by falling 
resistance
  * values to work.
  */
-static struct abx500_res_to_temp temp_tbl_A_thermistor[] = {
+static struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
{-5, 53407},
{ 0, 48594},
{ 5, 43804},
@@ -29,7 +29,7 @@ static struct abx500_res_to_temp temp_tbl_A_thermistor[] = {
{65, 12500},
 };
 
-static struct abx500_res_to_temp temp_tbl_B_thermistor[] = {
+static struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
{-5, 20},
{ 0, 159024},
{ 5, 151921},
@@ -47,7 +47,7 @@ static struct abx500_res_to_temp temp_tbl_B_thermistor[] = {
{65,  82869},
 };
 
-static struct abx500_v_to_cap cap_tbl_A_thermistor[] = {
+static struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
{4171,  100},
{4114,   95},
{4009,   83},
@@ -70,7 +70,7 @@ static struct abx500_v_to_cap cap_tbl_A_thermistor[] = {
{3247,0},
 };
 
-static struct abx500_v_to_cap cap_tbl_B_thermistor[] = {
+static struct abx500_v_to_cap cap_tbl_b_thermistor[] = {
{4161,  100},
{4124,   98},
{4044,   90},
@@ -230,10 +230,10 @@ static struct abx500_battery_type bat_type_thermistor[] = 
{
.maint_b_chg_timer_h = 200,
.low_high_cur_lvl = 300,
.low_high_vol_lvl = 4000,
-   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_A_thermistor),
-   .r_to_t_tbl = temp_tbl_A_thermistor,
-   .n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_A_thermistor),
-   .v_to_cap_tbl = cap_tbl_A_thermistor,
+   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_a_thermistor),
+   .r_to_t_tbl = temp_tbl_a_thermistor,
+   .n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_a_thermistor),
+   .v_to_cap_tbl = cap_tbl_a_thermistor,
.n_batres_tbl_elements = ARRAY_SIZE(temp_to_batres_tbl_thermistor),
.batres_tbl = temp_to_batres_tbl_thermistor,
 
@@ -258,10 +258,10 @@ static struct abx500_battery_type bat_type_thermistor[] = 
{
.maint_b_chg_timer_h = 200,
.low_high_cur_lvl = 300,
.low_high_vol_lvl = 4000,
-   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_B_thermistor),
-   .r_to_t_tbl = temp_tbl_B_thermistor,
-   .n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_B_thermistor),
-   .v_to_cap_tbl = cap_tbl_B_thermistor,
+   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_b_thermistor),
+   .r_to_t_tbl = temp_tbl_b_thermistor,
+   .n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_b_thermistor),
+   .v_to_cap_tbl = cap_tbl_b_thermistor,
.n_batres_tbl_elements = ARRAY_SIZE(temp_to_batres_tbl_thermistor),
.batres_tbl = temp_to_batres_tbl_thermistor,
 },
-- 
1.8.0

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

[PATCH v7 1/5] ab8500_btemp: make ab8500_btemp_get* interfaces public

[Hongbo Zhang]

Make ab8500_btemp_get_temp interface public, export it and also export the
ab8500_btemp_get, ab8500_btemp_get_batctrl_temp interfaces, so that the ab8500
hwmon driver can use them.

Signed-off-by: Hongbo Zhang 
Acked-by: Anton Vorontsov 
---
 drivers/power/ab8500_btemp.c | 5 -
 include/linux/mfd/abx500/ab8500-bm.h | 5 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/power/ab8500_btemp.c b/drivers/power/ab8500_btemp.c
index 20e2a7d..3359075 100644
--- a/drivers/power/ab8500_btemp.c
+++ b/drivers/power/ab8500_btemp.c
@@ -123,6 +123,7 @@ struct ab8500_btemp *ab8500_btemp_get(void)
 
return btemp;
 }
+EXPORT_SYMBOL(ab8500_btemp_get);
 
 /**
  * ab8500_btemp_batctrl_volt_to_res() - convert batctrl voltage to resistance
@@ -727,7 +728,7 @@ static void ab8500_btemp_periodic(struct ab8500_btemp *di,
  *
  * Returns battery temperature
  */
-static int ab8500_btemp_get_temp(struct ab8500_btemp *di)
+int ab8500_btemp_get_temp(struct ab8500_btemp *di)
 {
int temp = 0;
 
@@ -763,6 +764,7 @@ static int ab8500_btemp_get_temp(struct ab8500_btemp *di)
}
return temp;
 }
+EXPORT_SYMBOL(ab8500_btemp_get_temp);
 
 /**
  * ab8500_btemp_get_batctrl_temp() - get the temperature
@@ -774,6 +776,7 @@ int ab8500_btemp_get_batctrl_temp(struct ab8500_btemp 
*btemp)
 {
return btemp->bat_temp * 1000;
 }
+EXPORT_SYMBOL(ab8500_btemp_get_batctrl_temp);
 
 /**
  * ab8500_btemp_get_property() - get the btemp properties
diff --git a/include/linux/mfd/abx500/ab8500-bm.h 
b/include/linux/mfd/abx500/ab8500-bm.h
index 44310c9..4dd79f6 100644
--- a/include/linux/mfd/abx500/ab8500-bm.h
+++ b/include/linux/mfd/abx500/ab8500-bm.h
@@ -427,6 +427,7 @@ void ab8500_fg_reinit(void);
 void ab8500_charger_usb_state_changed(u8 bm_usb_state, u16 mA);
 struct ab8500_btemp *ab8500_btemp_get(void);
 int ab8500_btemp_get_batctrl_temp(struct ab8500_btemp *btemp);
+int ab8500_btemp_get_temp(struct ab8500_btemp *btemp);
 struct ab8500_fg *ab8500_fg_get(void);
 int ab8500_fg_inst_curr_blocking(struct ab8500_fg *dev);
 int ab8500_fg_inst_curr_start(struct ab8500_fg *di);
@@ -451,6 +452,10 @@ static int ab8500_btemp_get_batctrl_temp(struct 
ab8500_btemp *btemp)
 {
return 0;
 }
+static int ab8500_btemp_get_temp(struct ab8500_btemp *btemp)
+{
+   return 0;
+}
 struct ab8500_fg *ab8500_fg_get(void)
 {
return NULL;
-- 
1.8.0

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

[PATCH v7 0/5] Add ST-Ericsson AB8500 HWMON driver

[Hongbo Zhang]

Guenter and Anton,
Only one minor update as Guenter mentioned for v6, thank you.

v6 -> v7 changes:
- move exporting symbols from [5/5] to [4/5], which was a mistake.

v5 -> v6 changes:
- add depend on AB8500_BM in Kconfig
- fix wrong usage of clamp_val()
- export symbols for module compiling

v4 -> v5 changes:
- split the old [2/3]-ab8500-re-arrange-ab8500-power-and-temperature-data into
  new three [2/5], [3/5] and [4/5] patches.
- hwmon driver minor coding style clean ups:
  - {} usage in if-else statement in ab8500_read_sensor function
  - index error fix in gpadc_monitor function
  - fix issue of clamp_val() usage
  - remove unnecessary else in function abx500_attrs_visible
  - remove redundant print message about irq set up
  - return the calling function return value directly in probe function

v3 -> v4 changes:
for patch [3/3]
- define delays in HZ
- update ab8500_read_sensor function, returning temp by parameter
- remove ab8500_is_visible function
- use clamp_val in set_min and set_max callback
- remove unnecessary locks in remove and suspend functions
- let abx500 and ab8500 use its own data structure
for patch [2/3]
- move the data tables from driver/power/ab8500_bmdata.c to
  include/linux/power/ab8500.h
- rename driver/power/ab8500_bmdata.c to driver/power/ab8500_bm.c
- rename these variable names to eliminate CamelCase warnings
- add const attribute to these data

v2 -> v3 changes:
- Add interface for converting voltage to temperature
- Remove temp5 sensor since we cannot offer temperature read interface of it
- Update hyst to use absolute temperature instead of a difference
- Add the 3/3 patch

v1 -> v2 changes:
- Add Documentation/hwmon/abx500 and Documentation/hwmon/abx500
- Make devices which cannot report milli-Celsius invisible
- Add temp5_crit interface
- Re-work the old find_active_thresholds() to threshold_updated()
- Reset updated_min_alarm and updated_max_alarm at the end of each loop
- Update the hyst mechamisn to make it works as real hyst
- Remove non-stand attributes
- Re-order the operations sequence inside probe and remove functions
- Update all the lock usages to eliminate race conditions
- Make attibutes index starts from 0
also changes:
- Since the old [1/2] "ARM: ux500: rename ab8500 to abx500 for hwmon driver"
  has been merged by Samuel, so won't send it again.
- Add another new patch "ab8500_btemp: export two symblols" as [2/2] of this
  patch set.

Hongbo Zhang (5):
  ab8500_btemp: make ab8500_btemp_get* interfaces public
  ab8500: power: eliminate CamelCase warning of some variables
  ab8500: power: add const attributes to some data arrays
  ab8500: power: export abx500_res_to_temp tables for hwmon
  hwmon: add ST-Ericsson ABX500 hwmon driver

 Documentation/hwmon/ab8500   |  22 ++
 Documentation/hwmon/abx500   |  28 ++
 drivers/hwmon/Kconfig|  13 +
 drivers/hwmon/Makefile   |   1 +
 drivers/hwmon/ab8500.c   | 206 +++
 drivers/hwmon/abx500.c   | 491 +++
 drivers/hwmon/abx500.h   |  69 +
 drivers/power/ab8500_bmdata.c|  42 +--
 drivers/power/ab8500_btemp.c |   5 +-
 drivers/power/ab8500_fg.c|   4 +-
 include/linux/mfd/abx500.h   |   6 +-
 include/linux/mfd/abx500/ab8500-bm.h |   5 +
 include/linux/power/ab8500.h |  16 ++
 13 files changed, 885 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/hwmon/ab8500
 create mode 100644 Documentation/hwmon/abx500
 create mode 100644 drivers/hwmon/ab8500.c
 create mode 100644 drivers/hwmon/abx500.c
 create mode 100644 drivers/hwmon/abx500.h
 create mode 100644 include/linux/power/ab8500.h

-- 
1.8.0

--
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 v6 5/5] hwmon: add ST-Ericsson ABX500 hwmon driver

[Hongbo Zhang]

On 26 March 2013 23:23, Guenter Roeck  wrote:
> On Tue, Mar 26, 2013 at 03:06:59PM +0800, Hongbo Zhang wrote:
>> Each of ST-Ericsson X500 chip set series consists of both ABX500 and DBX500
>> chips. This is ABX500 hwmon driver, where the abx500.c is a common layer for
>> all ABX500s, and the ab8500.c is specific for AB8500 chip. Under this 
>> designed
>> structure, other chip specific files can be added simply using the same 
>> common
>> layer abx500.c.
>>
>> Signed-off-by: Hongbo Zhang 
>
> Looks good except ...
>
>> diff --git a/drivers/power/ab8500_bmdata.c b/drivers/power/ab8500_bmdata.c
>> index d9f1f25..05a1077 100644
>> --- a/drivers/power/ab8500_bmdata.c
>> +++ b/drivers/power/ab8500_bmdata.c
>> @@ -28,8 +28,10 @@ const struct abx500_res_to_temp 
>> ab8500_temp_tbl_a_thermistor[] = {
>>   {60, 13437},
>>   {65, 12500},
>>  };
>> +EXPORT_SYMBOL(ab8500_temp_tbl_a_thermistor);
>>
> Those exports should be in the previous patch where you start exporting the 
> symbols,
> not in this patch.
>
Sorry, This was really my carelessness, will update it.

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

[PATCH v6 5/5] hwmon: add ST-Ericsson ABX500 hwmon driver

[Hongbo Zhang]

Each of ST-Ericsson X500 chip set series consists of both ABX500 and DBX500
chips. This is ABX500 hwmon driver, where the abx500.c is a common layer for
all ABX500s, and the ab8500.c is specific for AB8500 chip. Under this designed
structure, other chip specific files can be added simply using the same common
layer abx500.c.

Signed-off-by: Hongbo Zhang 
---
 Documentation/hwmon/ab8500|  22 ++
 Documentation/hwmon/abx500|  28 +++
 drivers/hwmon/Kconfig |  13 ++
 drivers/hwmon/Makefile|   1 +
 drivers/hwmon/ab8500.c| 206 ++
 drivers/hwmon/abx500.c| 491 ++
 drivers/hwmon/abx500.h|  69 ++
 drivers/power/ab8500_bmdata.c |   4 +
 8 files changed, 834 insertions(+)
 create mode 100644 Documentation/hwmon/ab8500
 create mode 100644 Documentation/hwmon/abx500
 create mode 100644 drivers/hwmon/ab8500.c
 create mode 100644 drivers/hwmon/abx500.c
 create mode 100644 drivers/hwmon/abx500.h

diff --git a/Documentation/hwmon/ab8500 b/Documentation/hwmon/ab8500
new file mode 100644
index 000..cf169c8
--- /dev/null
+++ b/Documentation/hwmon/ab8500
@@ -0,0 +1,22 @@
+Kernel driver ab8500
+
+
+Supported chips:
+  * ST-Ericsson AB8500
+Prefix: 'ab8500'
+Addresses scanned: -
+Datasheet: http://www.stericsson.com/developers/documentation.jsp
+
+Authors:
+Martin Persson 
+    Hongbo Zhang 
+
+Description
+---
+
+See also Documentation/hwmon/abx500. This is the ST-Ericsson AB8500 specific
+driver.
+
+Currently only the AB8500 internal sensor and one external sensor for battery
+temperature are monitored. Other GPADC channels can also be monitored if needed
+in future.
diff --git a/Documentation/hwmon/abx500 b/Documentation/hwmon/abx500
new file mode 100644
index 000..319a058
--- /dev/null
+++ b/Documentation/hwmon/abx500
@@ -0,0 +1,28 @@
+Kernel driver abx500
+
+
+Supported chips:
+  * ST-Ericsson ABx500 series
+Prefix: 'abx500'
+Addresses scanned: -
+Datasheet: http://www.stericsson.com/developers/documentation.jsp
+
+Authors:
+Martin Persson 
+Hongbo Zhang 
+
+Description
+---
+
+Every ST-Ericsson Ux500 SOC consists of both ABx500 and DBx500 physically,
+this is kernel hwmon driver for ABx500.
+
+There are some GPADCs inside ABx500 which are designed for connecting to
+thermal sensors, and there is also a thermal sensor inside ABx500 too, which
+raises interrupt when critical temperature reached.
+
+This abx500 is a common layer which can monitor all of the sensors, every
+specific abx500 chip has its special configurations in its own file, e.g. some
+sensors can be configured invisible if they are not available on that chip, and
+the corresponding gpadc_addr should be set to 0, thus this sensor won't be
+polled.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 32f238f..d0d6b52 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -39,6 +39,19 @@ config HWMON_DEBUG_CHIP
 
 comment "Native drivers"
 
+config SENSORS_AB8500
+   tristate "AB8500 thermal monitoring"
+   depends on AB8500_GPADC && AB8500_BM
+   default n
+   help
+ If you say yes here you get support for the thermal sensor part
+ of the AB8500 chip. The driver includes thermal management for
+ AB8500 die and two GPADC channels. The GPADC channel are preferably
+ used to access sensors outside the AB8500 chip.
+
+ This driver can also be built as a module.  If so, the module
+ will be called abx500-temp.
+
 config SENSORS_ABITUGURU
tristate "Abit uGuru (rev 1 & 2)"
depends on X86 && DMI
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 5da2874..06dfe85 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_SENSORS_W83795)  += w83795.o
 obj-$(CONFIG_SENSORS_W83781D)  += w83781d.o
 obj-$(CONFIG_SENSORS_W83791D)  += w83791d.o
 
+obj-$(CONFIG_SENSORS_AB8500)   += abx500.o ab8500.o
 obj-$(CONFIG_SENSORS_ABITUGURU)+= abituguru.o
 obj-$(CONFIG_SENSORS_ABITUGURU3)+= abituguru3.o
 obj-$(CONFIG_SENSORS_AD7314)   += ad7314.o
diff --git a/drivers/hwmon/ab8500.c b/drivers/hwmon/ab8500.c
new file mode 100644
index 000..ee0aa3e
--- /dev/null
+++ b/drivers/hwmon/ab8500.c
@@ -0,0 +1,206 @@
+/*
+ * Copyright (C) ST-Ericsson 2010 - 2013
+ * Author: Martin Persson 
+ * Hongbo Zhang 
+ * License Terms: GNU General Public License v2
+ *
+ * When the AB8500 thermal warning temperature is reached (threshold cannot
+ * be changed by SW), an interrupt is set, and if no further action is taken
+ * within a certain time frame, pm_power off will be called.
+ *
+ * When AB8500 thermal shutdown temperature is reached a hardware shutdown of
+ * the AB8500 will occur.
+ */
+
+#include 
+#include 
+#include 
+#include 

[PATCH v6 4/5] ab8500: power: export abx500_res_to_temp tables for hwmon

[Hongbo Zhang]

This patch exports the thermistor resistance-to-temperature tables, so that the
hwmon driver can access them, and also adds the corresponding table size
variables.

Signed-off-by: Hongbo Zhang 
---
 drivers/power/ab8500_bmdata.c | 16 ++--
 include/linux/power/ab8500.h  | 16 
 2 files changed, 26 insertions(+), 6 deletions(-)
 create mode 100644 include/linux/power/ab8500.h

diff --git a/drivers/power/ab8500_bmdata.c b/drivers/power/ab8500_bmdata.c
index 9c25ca8..d9f1f25 100644
--- a/drivers/power/ab8500_bmdata.c
+++ b/drivers/power/ab8500_bmdata.c
@@ -11,7 +11,7 @@
  * Note that the res_to_temp table must be strictly sorted by falling 
resistance
  * values to work.
  */
-static const struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
+const struct abx500_res_to_temp ab8500_temp_tbl_a_thermistor[] = {
{-5, 53407},
{ 0, 48594},
{ 5, 43804},
@@ -29,7 +29,9 @@ static const struct abx500_res_to_temp 
temp_tbl_a_thermistor[] = {
{65, 12500},
 };
 
-static const struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
+const int ab8500_temp_tbl_a_size = ARRAY_SIZE(ab8500_temp_tbl_a_thermistor);
+
+const struct abx500_res_to_temp ab8500_temp_tbl_b_thermistor[] = {
{-5, 20},
{ 0, 159024},
{ 5, 151921},
@@ -47,6 +49,8 @@ static const struct abx500_res_to_temp 
temp_tbl_b_thermistor[] = {
{65,  82869},
 };
 
+const int ab8500_temp_tbl_b_size = ARRAY_SIZE(ab8500_temp_tbl_b_thermistor);
+
 static const struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
{4171,  100},
{4114,   95},
@@ -230,8 +234,8 @@ static struct abx500_battery_type bat_type_thermistor[] = {
.maint_b_chg_timer_h = 200,
.low_high_cur_lvl = 300,
.low_high_vol_lvl = 4000,
-   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_a_thermistor),
-   .r_to_t_tbl = temp_tbl_a_thermistor,
+   .n_temp_tbl_elements = ARRAY_SIZE(ab8500_temp_tbl_a_thermistor),
+   .r_to_t_tbl = ab8500_temp_tbl_a_thermistor,
.n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_a_thermistor),
.v_to_cap_tbl = cap_tbl_a_thermistor,
.n_batres_tbl_elements = ARRAY_SIZE(temp_to_batres_tbl_thermistor),
@@ -258,8 +262,8 @@ static struct abx500_battery_type bat_type_thermistor[] = {
.maint_b_chg_timer_h = 200,
.low_high_cur_lvl = 300,
.low_high_vol_lvl = 4000,
-   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_b_thermistor),
-   .r_to_t_tbl = temp_tbl_b_thermistor,
+   .n_temp_tbl_elements = ARRAY_SIZE(ab8500_temp_tbl_b_thermistor),
+   .r_to_t_tbl = ab8500_temp_tbl_b_thermistor,
.n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_b_thermistor),
.v_to_cap_tbl = cap_tbl_b_thermistor,
.n_batres_tbl_elements = ARRAY_SIZE(temp_to_batres_tbl_thermistor),
diff --git a/include/linux/power/ab8500.h b/include/linux/power/ab8500.h
new file mode 100644
index 000..cdbb6c2
--- /dev/null
+++ b/include/linux/power/ab8500.h
@@ -0,0 +1,16 @@
+/*
+ * Copyright (C) ST-Ericsson 2013
+ * Author: Hongbo Zhang 
+ * License terms: GNU General Public License v2
+ */
+
+#ifndef PWR_AB8500_H
+#define PWR_AB8500_H
+
+extern const struct abx500_res_to_temp ab8500_temp_tbl_a_thermistor[];
+extern const int ab8500_temp_tbl_a_size;
+
+extern const struct abx500_res_to_temp ab8500_temp_tbl_b_thermistor[];
+extern const int ab8500_temp_tbl_b_size;
+
+#endif /* PWR_AB8500_H */
-- 
1.8.0

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

[PATCH v6 3/5] ab8500: power: add const attributes to some data arrays

[Hongbo Zhang]

This patch adds const attributes to AB8500 power and temperature related
read-only data arrays.

Signed-off-by: Hongbo Zhang 
---
 drivers/power/ab8500_bmdata.c | 18 +-
 drivers/power/ab8500_fg.c |  4 ++--
 include/linux/mfd/abx500.h|  6 +++---
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/power/ab8500_bmdata.c b/drivers/power/ab8500_bmdata.c
index f836550..9c25ca8 100644
--- a/drivers/power/ab8500_bmdata.c
+++ b/drivers/power/ab8500_bmdata.c
@@ -11,7 +11,7 @@
  * Note that the res_to_temp table must be strictly sorted by falling 
resistance
  * values to work.
  */
-static struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
+static const struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
{-5, 53407},
{ 0, 48594},
{ 5, 43804},
@@ -29,7 +29,7 @@ static struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
{65, 12500},
 };
 
-static struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
+static const struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
{-5, 20},
{ 0, 159024},
{ 5, 151921},
@@ -47,7 +47,7 @@ static struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
{65,  82869},
 };
 
-static struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
+static const struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
{4171,  100},
{4114,   95},
{4009,   83},
@@ -70,7 +70,7 @@ static struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
{3247,0},
 };
 
-static struct abx500_v_to_cap cap_tbl_b_thermistor[] = {
+static const struct abx500_v_to_cap cap_tbl_b_thermistor[] = {
{4161,  100},
{4124,   98},
{4044,   90},
@@ -93,7 +93,7 @@ static struct abx500_v_to_cap cap_tbl_b_thermistor[] = {
{3250,0},
 };
 
-static struct abx500_v_to_cap cap_tbl[] = {
+static const struct abx500_v_to_cap cap_tbl[] = {
{4186,  100},
{4163,   99},
{4114,   95},
@@ -124,7 +124,7 @@ static struct abx500_v_to_cap cap_tbl[] = {
  * Note that the res_to_temp table must be strictly sorted by falling
  * resistance values to work.
  */
-static struct abx500_res_to_temp temp_tbl[] = {
+static const struct abx500_res_to_temp temp_tbl[] = {
{-5, 214834},
{ 0, 162943},
{ 5, 124820},
@@ -146,7 +146,7 @@ static struct abx500_res_to_temp temp_tbl[] = {
  * Note that the batres_vs_temp table must be strictly sorted by falling
  * temperature values to work.
  */
-static struct batres_vs_temp temp_to_batres_tbl_thermistor[] = {
+static const struct batres_vs_temp temp_to_batres_tbl_thermistor[] = {
{ 40, 120},
{ 30, 135},
{ 20, 165},
@@ -160,7 +160,7 @@ static struct batres_vs_temp 
temp_to_batres_tbl_thermistor[] = {
  * Note that the batres_vs_temp table must be strictly sorted by falling
  * temperature values to work.
  */
-static struct batres_vs_temp temp_to_batres_tbl_ext_thermistor[] = {
+static const struct batres_vs_temp temp_to_batres_tbl_ext_thermistor[] = {
{ 60, 300},
{ 30, 300},
{ 20, 300},
@@ -171,7 +171,7 @@ static struct batres_vs_temp 
temp_to_batres_tbl_ext_thermistor[] = {
 };
 
 /* battery resistance table for LI ION 9100 battery */
-static struct batres_vs_temp temp_to_batres_tbl_9100[] = {
+static const struct batres_vs_temp temp_to_batres_tbl_9100[] = {
{ 60, 180},
{ 30, 180},
{ 20, 180},
diff --git a/drivers/power/ab8500_fg.c b/drivers/power/ab8500_fg.c
index b3bf178..d21456d 100644
--- a/drivers/power/ab8500_fg.c
+++ b/drivers/power/ab8500_fg.c
@@ -811,7 +811,7 @@ static int ab8500_fg_bat_voltage(struct ab8500_fg *di)
 static int ab8500_fg_volt_to_capacity(struct ab8500_fg *di, int voltage)
 {
int i, tbl_size;
-   struct abx500_v_to_cap *tbl;
+   const struct abx500_v_to_cap *tbl;
int cap = 0;
 
tbl = di->bat->bat_type[di->bat->batt_id].v_to_cap_tbl,
@@ -863,7 +863,7 @@ static int ab8500_fg_uncomp_volt_to_capacity(struct 
ab8500_fg *di)
 static int ab8500_fg_battery_resistance(struct ab8500_fg *di)
 {
int i, tbl_size;
-   struct batres_vs_temp *tbl;
+   const struct batres_vs_temp *tbl;
int resist = 0;
 
tbl = di->bat->bat_type[di->bat->batt_id].batres_tbl;
diff --git a/include/linux/mfd/abx500.h b/include/linux/mfd/abx500.h
index 2138bd3..03fc0f1 100644
--- a/include/linux/mfd/abx500.h
+++ b/include/linux/mfd/abx500.h
@@ -173,11 +173,11 @@ struct abx500_battery_type {
int low_high_vol_lvl;
int battery_resistance;
int n_temp_tbl_elements;
-   struct abx500_res_to_temp *r_to_t_tbl;
+   const struct abx500_res_to_temp *r_to_t_tbl;
int n_v_cap_tbl_elements;
-   struct abx500_v_to_cap *v_to_cap_tbl;
+   const struct abx500_v_to_cap *v_to_cap_tbl;
int n_batres_tbl_elements;
-   struct batres_vs_temp *batres_tbl;
+   const struct batres_vs_temp *batres_tbl;
 };
 
 /**
-- 
1.8.0

[PATCH v6 2/5] ab8500: power: eliminate CamelCase warning of some variables

[Hongbo Zhang]

Some AB8500 power related variable names don't comply with kernel coding rules,
any new patch using these variables will result in CamelCase warnings from
checkpatch.pl, this patch re-name these variables.

Signed-off-by: Hongbo Zhang 
---
 drivers/power/ab8500_bmdata.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/power/ab8500_bmdata.c b/drivers/power/ab8500_bmdata.c
index f034ae4..f836550 100644
--- a/drivers/power/ab8500_bmdata.c
+++ b/drivers/power/ab8500_bmdata.c
@@ -11,7 +11,7 @@
  * Note that the res_to_temp table must be strictly sorted by falling 
resistance
  * values to work.
  */
-static struct abx500_res_to_temp temp_tbl_A_thermistor[] = {
+static struct abx500_res_to_temp temp_tbl_a_thermistor[] = {
{-5, 53407},
{ 0, 48594},
{ 5, 43804},
@@ -29,7 +29,7 @@ static struct abx500_res_to_temp temp_tbl_A_thermistor[] = {
{65, 12500},
 };
 
-static struct abx500_res_to_temp temp_tbl_B_thermistor[] = {
+static struct abx500_res_to_temp temp_tbl_b_thermistor[] = {
{-5, 20},
{ 0, 159024},
{ 5, 151921},
@@ -47,7 +47,7 @@ static struct abx500_res_to_temp temp_tbl_B_thermistor[] = {
{65,  82869},
 };
 
-static struct abx500_v_to_cap cap_tbl_A_thermistor[] = {
+static struct abx500_v_to_cap cap_tbl_a_thermistor[] = {
{4171,  100},
{4114,   95},
{4009,   83},
@@ -70,7 +70,7 @@ static struct abx500_v_to_cap cap_tbl_A_thermistor[] = {
{3247,0},
 };
 
-static struct abx500_v_to_cap cap_tbl_B_thermistor[] = {
+static struct abx500_v_to_cap cap_tbl_b_thermistor[] = {
{4161,  100},
{4124,   98},
{4044,   90},
@@ -230,10 +230,10 @@ static struct abx500_battery_type bat_type_thermistor[] = 
{
.maint_b_chg_timer_h = 200,
.low_high_cur_lvl = 300,
.low_high_vol_lvl = 4000,
-   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_A_thermistor),
-   .r_to_t_tbl = temp_tbl_A_thermistor,
-   .n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_A_thermistor),
-   .v_to_cap_tbl = cap_tbl_A_thermistor,
+   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_a_thermistor),
+   .r_to_t_tbl = temp_tbl_a_thermistor,
+   .n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_a_thermistor),
+   .v_to_cap_tbl = cap_tbl_a_thermistor,
.n_batres_tbl_elements = ARRAY_SIZE(temp_to_batres_tbl_thermistor),
.batres_tbl = temp_to_batres_tbl_thermistor,
 
@@ -258,10 +258,10 @@ static struct abx500_battery_type bat_type_thermistor[] = 
{
.maint_b_chg_timer_h = 200,
.low_high_cur_lvl = 300,
.low_high_vol_lvl = 4000,
-   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_B_thermistor),
-   .r_to_t_tbl = temp_tbl_B_thermistor,
-   .n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_B_thermistor),
-   .v_to_cap_tbl = cap_tbl_B_thermistor,
+   .n_temp_tbl_elements = ARRAY_SIZE(temp_tbl_b_thermistor),
+   .r_to_t_tbl = temp_tbl_b_thermistor,
+   .n_v_cap_tbl_elements = ARRAY_SIZE(cap_tbl_b_thermistor),
+   .v_to_cap_tbl = cap_tbl_b_thermistor,
.n_batres_tbl_elements = ARRAY_SIZE(temp_to_batres_tbl_thermistor),
.batres_tbl = temp_to_batres_tbl_thermistor,
 },
-- 
1.8.0

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

[PATCH v6 1/5] ab8500_btemp: make ab8500_btemp_get* interfaces public

[Hongbo Zhang]

Make ab8500_btemp_get_temp interface public, export it and also export the
ab8500_btemp_get, ab8500_btemp_get_batctrl_temp interfaces, so that the ab8500
hwmon driver can use them.

Signed-off-by: Hongbo Zhang 
Acked-by: Anton Vorontsov 
---
 drivers/power/ab8500_btemp.c | 5 -
 include/linux/mfd/abx500/ab8500-bm.h | 5 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/power/ab8500_btemp.c b/drivers/power/ab8500_btemp.c
index 20e2a7d..3359075 100644
--- a/drivers/power/ab8500_btemp.c
+++ b/drivers/power/ab8500_btemp.c
@@ -123,6 +123,7 @@ struct ab8500_btemp *ab8500_btemp_get(void)
 
return btemp;
 }
+EXPORT_SYMBOL(ab8500_btemp_get);
 
 /**
  * ab8500_btemp_batctrl_volt_to_res() - convert batctrl voltage to resistance
@@ -727,7 +728,7 @@ static void ab8500_btemp_periodic(struct ab8500_btemp *di,
  *
  * Returns battery temperature
  */
-static int ab8500_btemp_get_temp(struct ab8500_btemp *di)
+int ab8500_btemp_get_temp(struct ab8500_btemp *di)
 {
int temp = 0;
 
@@ -763,6 +764,7 @@ static int ab8500_btemp_get_temp(struct ab8500_btemp *di)
}
return temp;
 }
+EXPORT_SYMBOL(ab8500_btemp_get_temp);
 
 /**
  * ab8500_btemp_get_batctrl_temp() - get the temperature
@@ -774,6 +776,7 @@ int ab8500_btemp_get_batctrl_temp(struct ab8500_btemp 
*btemp)
 {
return btemp->bat_temp * 1000;
 }
+EXPORT_SYMBOL(ab8500_btemp_get_batctrl_temp);
 
 /**
  * ab8500_btemp_get_property() - get the btemp properties
diff --git a/include/linux/mfd/abx500/ab8500-bm.h 
b/include/linux/mfd/abx500/ab8500-bm.h
index 44310c9..4dd79f6 100644
--- a/include/linux/mfd/abx500/ab8500-bm.h
+++ b/include/linux/mfd/abx500/ab8500-bm.h
@@ -427,6 +427,7 @@ void ab8500_fg_reinit(void);
 void ab8500_charger_usb_state_changed(u8 bm_usb_state, u16 mA);
 struct ab8500_btemp *ab8500_btemp_get(void);
 int ab8500_btemp_get_batctrl_temp(struct ab8500_btemp *btemp);
+int ab8500_btemp_get_temp(struct ab8500_btemp *btemp);
 struct ab8500_fg *ab8500_fg_get(void);
 int ab8500_fg_inst_curr_blocking(struct ab8500_fg *dev);
 int ab8500_fg_inst_curr_start(struct ab8500_fg *di);
@@ -451,6 +452,10 @@ static int ab8500_btemp_get_batctrl_temp(struct 
ab8500_btemp *btemp)
 {
return 0;
 }
+static int ab8500_btemp_get_temp(struct ab8500_btemp *btemp)
+{
+   return 0;
+}
 struct ab8500_fg *ab8500_fg_get(void)
 {
return NULL;
-- 
1.8.0

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

[PATCH v6 0/5] Add ST-Ericsson AB8500 HWMON driver

[Hongbo Zhang]

Guenter,
Please check this v6 patches,
thanks for all your reviews/comments for this patch set.

Anton Vorontsov, for this v5 and v6 patches:
I have add your Acked-by: into patch [1/5] (which was [1/3]); and split the
old [2/3] into new [2/5], [3/5] and [4/5] patches, so please have a look them
again, thank you.

v5 -> v6 changes:
- add depend on AB8500_BM in Kconfig
- fix wrong usage of clamp_val()
- export symbols for module compiling

v4 -> v5 changes:
- split the old [2/3]-ab8500-re-arrange-ab8500-power-and-temperature-data into
  new three [2/5], [3/5] and [4/5] patches.
- hwmon driver minor coding style clean ups:
  - {} usage in if-else statement in ab8500_read_sensor function
  - index error fix in gpadc_monitor function
  - fix issue of clamp_val() usage
  - remove unnecessary else in function abx500_attrs_visible
  - remove redundant print message about irq set up
  - return the calling function return value directly in probe function

v3 -> v4 changes:
for patch [3/3]
- define delays in HZ
- update ab8500_read_sensor function, returning temp by parameter
- remove ab8500_is_visible function
- use clamp_val in set_min and set_max callback
- remove unnecessary locks in remove and suspend functions
- let abx500 and ab8500 use its own data structure
for patch [2/3]
- move the data tables from driver/power/ab8500_bmdata.c to
  include/linux/power/ab8500.h
- rename driver/power/ab8500_bmdata.c to driver/power/ab8500_bm.c
- rename these variable names to eliminate CamelCase warnings
- add const attribute to these data

v2 -> v3 changes:
- Add interface for converting voltage to temperature
- Remove temp5 sensor since we cannot offer temperature read interface of it
- Update hyst to use absolute temperature instead of a difference
- Add the 3/3 patch

v1 -> v2 changes:
- Add Documentation/hwmon/abx500 and Documentation/hwmon/abx500
- Make devices which cannot report milli-Celsius invisible
- Add temp5_crit interface
- Re-work the old find_active_thresholds() to threshold_updated()
- Reset updated_min_alarm and updated_max_alarm at the end of each loop
- Update the hyst mechamisn to make it works as real hyst
- Remove non-stand attributes
- Re-order the operations sequence inside probe and remove functions
- Update all the lock usages to eliminate race conditions
- Make attibutes index starts from 0
also changes:
- Since the old [1/2] "ARM: ux500: rename ab8500 to abx500 for hwmon driver"
  has been merged by Samuel, so won't send it again.
- Add another new patch "ab8500_btemp: export two symblols" as [2/2] of this
  patch set.

Hongbo Zhang (5):
  ab8500_btemp: make ab8500_btemp_get* interfaces public
  ab8500: power: eliminate CamelCase warning of some variables
  ab8500: power: add const attributes to some data arrays
  ab8500: power: export abx500_res_to_temp tables for hwmon
  hwmon: add ST-Ericsson ABX500 hwmon driver

 Documentation/hwmon/ab8500   |  22 ++
 Documentation/hwmon/abx500   |  28 ++
 drivers/hwmon/Kconfig|  13 +
 drivers/hwmon/Makefile   |   1 +
 drivers/hwmon/ab8500.c   | 206 +++
 drivers/hwmon/abx500.c   | 491 +++
 drivers/hwmon/abx500.h   |  69 +
 drivers/power/ab8500_bmdata.c|  42 +--
 drivers/power/ab8500_btemp.c |   5 +-
 drivers/power/ab8500_fg.c|   4 +-
 include/linux/mfd/abx500.h   |   6 +-
 include/linux/mfd/abx500/ab8500-bm.h |   5 +
 include/linux/power/ab8500.h |  16 ++
 13 files changed, 885 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/hwmon/ab8500
 create mode 100644 Documentation/hwmon/abx500
 create mode 100644 drivers/hwmon/ab8500.c
 create mode 100644 drivers/hwmon/abx500.c
 create mode 100644 drivers/hwmon/abx500.h
 create mode 100644 include/linux/power/ab8500.h

-- 
1.8.0

--
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] hwmon: add ST-Ericsson ABX500 hwmon driver

[Hongbo Zhang]

Guenter,
Thank you so much for all the comments, will re-send a v2 iteration soon.

On 31 January 2013 02:37, Guenter Roeck  wrote:
> On Wed, Jan 30, 2013 at 06:21:28PM +0800, Hongbo Zhang wrote:
>> Each of ST-Ericsson X500 chip set series consists of both ABX500 and DBX500
>> chips. This is ABX500 hwmon driver, where the abx500.c is a common layer for
>> all ABX500s, and the ab8500.c is specific for AB8500 chip. Under this 
>> designed
>> structure, other chip specific files can be added simply using the same 
>> common
>> layer abx500.c.
>>
>> Signed-off-by: Hongbo Zhang 
>> ---
>>  drivers/hwmon/Kconfig  |  13 +
>>  drivers/hwmon/Makefile |   1 +
>>  drivers/hwmon/ab8500.c | 160 
>>  drivers/hwmon/abx500.c | 681 
>> +
>>  drivers/hwmon/abx500.h |  88 +++
>>  5 files changed, 943 insertions(+)
>>  create mode 100644 drivers/hwmon/ab8500.c
>>  create mode 100644 drivers/hwmon/abx500.c
>>  create mode 100644 drivers/hwmon/abx500.h
>>
> Hi,
>
> we'll also need Documentation/hwmon/ab8500 to describe the driver, and 
> possibly
> Documentation/hwmon/ab85xx to describe the common elements.
>
Sure, will add them.

>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>> index 32f238f..0a6fd21 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -39,6 +39,19 @@ config HWMON_DEBUG_CHIP
>>
>>  comment "Native drivers"
>>
>> +config SENSORS_AB8500
>> + tristate "AB8500 thermal monitoring"
>> + depends on AB8500_GPADC
>> + default n
>> + help
>> +   If you say yes here you get support for the thermal sensor part
>> +   of the AB8500 chip. The driver includes thermal management for
>> +   AB8500 die and two GPADC channels. The GPADC channel are preferably
>> +   used to access sensors outside the AB8500 chip.
>> +
>> +   This driver can also be built as a module.  If so, the module
>> +   will be called abx500-temp.
>> +
>>  config SENSORS_ABITUGURU
>>   tristate "Abit uGuru (rev 1 & 2)"
>>   depends on X86 && DMI
>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
>> index 5da2874..06dfe85 100644
>> --- a/drivers/hwmon/Makefile
>> +++ b/drivers/hwmon/Makefile
>> @@ -19,6 +19,7 @@ obj-$(CONFIG_SENSORS_W83795)+= w83795.o
>>  obj-$(CONFIG_SENSORS_W83781D)+= w83781d.o
>>  obj-$(CONFIG_SENSORS_W83791D)+= w83791d.o
>>
>> +obj-$(CONFIG_SENSORS_AB8500) += abx500.o ab8500.o
>>  obj-$(CONFIG_SENSORS_ABITUGURU)  += abituguru.o
>>  obj-$(CONFIG_SENSORS_ABITUGURU3)+= abituguru3.o
>>  obj-$(CONFIG_SENSORS_AD7314) += ad7314.o
>> diff --git a/drivers/hwmon/ab8500.c b/drivers/hwmon/ab8500.c
>> new file mode 100644
>> index 000..426872c
>> --- /dev/null
>> +++ b/drivers/hwmon/ab8500.c
>> @@ -0,0 +1,160 @@
>> +/*
>> + * Copyright (C) ST-Ericsson SA 2010
>> + * Author: Martin Persson  for
>> + * ST-Ericsson.
>> + * License Terms: GNU General Public License v2
>> + *
>> + * If/when the AB8500 thermal warning temperature is reached (threshold 
>> cannot
>> + * be changed by SW), an interrupt is set and the driver notifies user space
>> + * via a sysfs event. If a shut down is not triggered by user space within a
>> + * certain time frame, pm_power off is called.
>> + *
>> + * If/when AB8500 thermal shutdown temperature is reached a hardware 
>> shutdown
>> + * of the AB8500 will occur.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include "abx500.h"
>> +
>> +#define DEFAULT_POWER_OFF_DELAY 1
>> +
>> +/* The driver monitors GPADC - ADC_AUX1, ADC_AUX2, BTEMP_BALL and BAT_CTRL 
>> */
>> +#define NUM_MONITORED_SENSORS 4
>> +
>> +static int ab8500_read_sensor(struct abx500_temp *data, u8 sensor)
>> +{
>> + int val;
>> + /*
>> +  * Special treatment for the BAT_CTRL node, since this temperature
>> +  * measurement is more complex than just an ADC readout
>> +  */
>> + if (sensor == BAT_CTRL)
>> + val = ab8500_btemp_get_batctrl_temp(data->ab8500_btemp);
>> + else
>> + val = ab8500_gpadc_convert(data->ab8500_gpadc, sensor);
>> +
>> + return val;
>> +}
>> +
>> +static void ab8500_

Re: [PATCH 1/2] ARM: ux500: rename ab8500 to abx500 for hwmon driver

[Hongbo Zhang]

On 30 January 2013 23:45, Samuel Ortiz  wrote:
> Hi Hongbo,
>
> On Wed, Jan 30, 2013 at 06:21:27PM +0800, Hongbo Zhang wrote:
>> We are using a generic abx500 hwmon layer, so rename specific ab8500 to 
>> generic
>> abx500 for hwmon device and driver matching.
>>
>> Signed-off-by: Hongbo Zhang 
>> ---
>>  drivers/mfd/ab8500-core.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
> I'll take it although this patch subject should be prefixed with mfd: and not
> ARM:
>
Thanks.
I have to resend 2/2 of this patch set, so I would like to update this
prefix then.

> Cheers,
> Samuel.
>
> --
> Intel Open Source Technology Centre
> http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] hwmon: add ST-Ericsson ABX500 hwmon driver

[Hongbo Zhang]

Each of ST-Ericsson X500 chip set series consists of both ABX500 and DBX500
chips. This is ABX500 hwmon driver, where the abx500.c is a common layer for
all ABX500s, and the ab8500.c is specific for AB8500 chip. Under this designed
structure, other chip specific files can be added simply using the same common
layer abx500.c.

Signed-off-by: Hongbo Zhang 
---
 drivers/hwmon/Kconfig  |  13 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/ab8500.c | 160 
 drivers/hwmon/abx500.c | 681 +
 drivers/hwmon/abx500.h |  88 +++
 5 files changed, 943 insertions(+)
 create mode 100644 drivers/hwmon/ab8500.c
 create mode 100644 drivers/hwmon/abx500.c
 create mode 100644 drivers/hwmon/abx500.h

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 32f238f..0a6fd21 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -39,6 +39,19 @@ config HWMON_DEBUG_CHIP
 
 comment "Native drivers"
 
+config SENSORS_AB8500
+   tristate "AB8500 thermal monitoring"
+   depends on AB8500_GPADC
+   default n
+   help
+ If you say yes here you get support for the thermal sensor part
+ of the AB8500 chip. The driver includes thermal management for
+ AB8500 die and two GPADC channels. The GPADC channel are preferably
+ used to access sensors outside the AB8500 chip.
+
+ This driver can also be built as a module.  If so, the module
+ will be called abx500-temp.
+
 config SENSORS_ABITUGURU
tristate "Abit uGuru (rev 1 & 2)"
depends on X86 && DMI
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 5da2874..06dfe85 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_SENSORS_W83795)  += w83795.o
 obj-$(CONFIG_SENSORS_W83781D)  += w83781d.o
 obj-$(CONFIG_SENSORS_W83791D)  += w83791d.o
 
+obj-$(CONFIG_SENSORS_AB8500)   += abx500.o ab8500.o
 obj-$(CONFIG_SENSORS_ABITUGURU)+= abituguru.o
 obj-$(CONFIG_SENSORS_ABITUGURU3)+= abituguru3.o
 obj-$(CONFIG_SENSORS_AD7314)   += ad7314.o
diff --git a/drivers/hwmon/ab8500.c b/drivers/hwmon/ab8500.c
new file mode 100644
index 000..426872c
--- /dev/null
+++ b/drivers/hwmon/ab8500.c
@@ -0,0 +1,160 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2010
+ * Author: Martin Persson  for
+ * ST-Ericsson.
+ * License Terms: GNU General Public License v2
+ *
+ * If/when the AB8500 thermal warning temperature is reached (threshold cannot
+ * be changed by SW), an interrupt is set and the driver notifies user space
+ * via a sysfs event. If a shut down is not triggered by user space within a
+ * certain time frame, pm_power off is called.
+ *
+ * If/when AB8500 thermal shutdown temperature is reached a hardware shutdown
+ * of the AB8500 will occur.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "abx500.h"
+
+#define DEFAULT_POWER_OFF_DELAY 1
+
+/* The driver monitors GPADC - ADC_AUX1, ADC_AUX2, BTEMP_BALL and BAT_CTRL */
+#define NUM_MONITORED_SENSORS 4
+
+static int ab8500_read_sensor(struct abx500_temp *data, u8 sensor)
+{
+   int val;
+   /*
+* Special treatment for the BAT_CTRL node, since this temperature
+* measurement is more complex than just an ADC readout
+*/
+   if (sensor == BAT_CTRL)
+   val = ab8500_btemp_get_batctrl_temp(data->ab8500_btemp);
+   else
+   val = ab8500_gpadc_convert(data->ab8500_gpadc, sensor);
+
+   return val;
+}
+
+static void ab8500_thermal_power_off(struct work_struct *work)
+{
+   struct abx500_temp *data = container_of(work, struct abx500_temp,
+   power_off_work.work);
+
+   dev_warn(&data->pdev->dev,
+   "Power off due to AB8500 thermal warning.\n");
+   pm_power_off();
+}
+
+static ssize_t ab8500_show_name(struct device *dev,
+   struct device_attribute *devattr,
+   char *buf)
+{
+   return sprintf(buf, "ab8500\n");
+}
+
+static ssize_t ab8500_show_label(struct device *dev,
+   struct device_attribute *devattr,
+   char *buf)
+{
+   char *name;
+   struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+   int index = attr->index;
+
+   switch (index) {
+   case 1:
+   name = "ext_rtc_xtal";
+   break;
+   case 2:
+   name = "ext_db8500";
+   break;
+   case 3:
+   name = "bat_temp";
+   break;
+   case 4:
+   name = "bat_ctrl";
+   break;
+   case 5:
+   name = "ab8500";
+   break;
+   default:
+   return -EINVAL;
+   }
+

[PATCH 1/2] ARM: ux500: rename ab8500 to abx500 for hwmon driver

[Hongbo Zhang]

We are using a generic abx500 hwmon layer, so rename specific ab8500 to generic
abx500 for hwmon device and driver matching.

Signed-off-by: Hongbo Zhang 
---
 drivers/mfd/ab8500-core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index e1650ba..579753f 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -922,7 +922,7 @@ static struct resource ab8505_iddet_resources[] = {
 
 static struct resource ab8500_temp_resources[] = {
{
-   .name  = "AB8500_TEMP_WARM",
+   .name  = "ABX500_TEMP_WARM",
.start = AB8500_INT_TEMP_WARM,
.end   = AB8500_INT_TEMP_WARM,
.flags = IORESOURCE_IRQ,
@@ -998,8 +998,8 @@ static struct mfd_cell abx500_common_devs[] = {
.of_compatible = "stericsson,ab8500-denc",
},
{
-   .name = "ab8500-temp",
-   .of_compatible = "stericsson,ab8500-temp",
+   .name = "abx500-temp",
+   .of_compatible = "stericsson,abx500-temp",
.num_resources = ARRAY_SIZE(ab8500_temp_resources),
.resources = ab8500_temp_resources,
},
-- 
1.8.0

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

[PATCH 0/2] Add ST-Ericsson AB8500 HWMON driver

[Hongbo Zhang]

These patches are against the v3.8-rc4.

Guenter Roeck, Jean Delvare,
Please help to have a look at this.

Samuel Ortiz,
Please review 1/2 and leave your Acked-by: if no problem, I think these patches
should be merged into HWMON tree.

Thanks for all.

Hongbo Zhang (2):
  ARM: ux500: rename ab8500 to abx500 for hwmon driver
  hwmon: add ST-Ericsson ABX500 hwmon driver

 drivers/hwmon/Kconfig |  13 +
 drivers/hwmon/Makefile|   1 +
 drivers/hwmon/ab8500.c| 160 +++
 drivers/hwmon/abx500.c| 681 ++
 drivers/hwmon/abx500.h|  88 ++
 drivers/mfd/ab8500-core.c |   6 +-
 6 files changed, 946 insertions(+), 3 deletions(-)
 create mode 100644 drivers/hwmon/ab8500.c
 create mode 100644 drivers/hwmon/abx500.c
 create mode 100644 drivers/hwmon/abx500.h

-- 
1.8.0

--
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 4/8] Thermal: Add Thermal_trip sysfs node

[Hongbo Zhang]

On 18 December 2012 17:29, Durgadoss R  wrote:
> This patch adds a thermal_trip directory under
> /sys/class/thermal/zoneX. This directory contains
> the trip point values for sensors bound to this
> zone.
>
> Signed-off-by: Durgadoss R 
> ---
>  drivers/thermal/thermal_sys.c |  237 
> -
>  include/linux/thermal.h   |   37 +++
>  2 files changed, 272 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index b39bf97..29ec073 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -448,6 +448,22 @@ static void thermal_zone_device_check(struct work_struct 
> *work)
> thermal_zone_device_update(tz);
>  }
>
> +static int get_sensor_indx_by_kobj(struct thermal_zone *tz, const char *name)
> +{
> +   int i, indx = -EINVAL;
> +
> +   mutex_lock(&sensor_list_lock);
> +   for (i = 0; i < tz->sensor_indx; i++) {
> +   if (!strnicmp(name, kobject_name(tz->kobj_trip[i]),
> +   THERMAL_NAME_LENGTH)) {
> +   indx = i;
> +   break;
> +   }
> +   }
> +   mutex_unlock(&sensor_list_lock);
> +   return indx;
> +}
> +
>  static void remove_sensor_from_zone(struct thermal_zone *tz,
> struct thermal_sensor *ts)
>  {
> @@ -459,9 +475,15 @@ static void remove_sensor_from_zone(struct thermal_zone 
> *tz,
>
> sysfs_remove_link(&tz->device.kobj, kobject_name(&ts->device.kobj));
>
> +   /* Delete this sensor's trip Kobject */
> +   kobject_del(tz->kobj_trip[indx]);
> +
> /* Shift the entries in the tz->sensors array */
> -   for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++)
> +   for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++) {
> tz->sensors[j] = tz->sensors[j + 1];
> +   tz->sensor_trip[j] = tz->sensor_trip[j + 1];
> +   tz->kobj_trip[j] = tz->kobj_trip[j + 1];
> +   }
>
> tz->sensor_indx--;
>  }
> @@ -875,6 +897,120 @@ policy_show(struct device *dev, struct device_attribute 
> *devattr, char *buf)
> return sprintf(buf, "%s\n", tz->governor->name);
>  }
>
> +static ssize_t
> +active_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
> +{
> +   int i, indx, ret = 0;
> +   struct thermal_zone *tz;
> +   struct device *dev;
> +
> +   /* In this function, for
> +* /sys/class/thermal/zoneX/thermal_trip/sensorY:
> +* attr points to sysfs node 'active'
> +* kobj points to sensorY
> +* kobj->parent points to thermal_trip
> +* kobj->parent->parent points to zoneX
> +*/
> +
> +   /* Get the zone pointer */
> +   dev = container_of(kobj->parent->parent, struct device, kobj);
> +   tz = to_zone(dev);
> +   if (!tz)
> +   return -EINVAL;
> +
> +   /*
> +* We need this because in the sysfs tree, 'sensorY' is
> +* not really the sensor pointer. It just has the name
> +* 'sensorY'; whereas 'zoneX' is actually the zone pointer.
> +* This means container_of(kobj, struct device, kobj) will not
> +* provide the actual sensor pointer.
> +*/
> +   indx = get_sensor_indx_by_kobj(tz, kobject_name(kobj));
> +   if (indx < 0)
> +   return indx;
> +
> +   if (tz->sensor_trip[indx]->num_active_trips <= 0)
> +   return sprintf(buf, "\n");
> +
> +   ret += sprintf(buf, "0x%x", tz->sensor_trip[indx]->active_trip_mask);
> +   for (i = 0; i < tz->sensor_trip[indx]->num_active_trips; i++) {
> +   ret += sprintf(buf + ret, " %d",
> +   tz->sensor_trip[indx]->active_trips[i]);
> +   }
> +
> +   ret += sprintf(buf + ret, "\n");
> +   return ret;
> +}
> +
> +static ssize_t
> +ptrip_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
> +{
> +   int i, indx, ret = 0;
> +   struct thermal_zone *tz;
> +   struct device *dev;
> +
> +   /* Get the zone pointer */
> +   dev = container_of(kobj->parent->parent, struct device, kobj);
> +   tz = to_zone(dev);
> +   if (!tz)
> +   return -EINVAL;
> +
> +   indx = get_sensor_indx_by_kobj(tz, kobject_name(kobj));
> +   if (indx < 0)
> +   return indx;
> +
> +   if (tz->sensor_trip[indx]->num_passive_trips <= 0)
> +   return sprintf(buf, "\n");
> +
> +   for (i = 0; i < tz->sensor_trip[indx]->num_passive_trips; i++) {
> +   ret += sprintf(buf + ret, "%d ",
> +   tz->sensor_trip[indx]->passive_trips[i]);
> +   }
> +
> +   ret += sprintf(buf + ret, "\n");
> +   return ret;
> +}
> +
> +static ssize_t
> +hot_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
> +{
> +   int indx;
> +   struct thermal_zone *tz;
> +   str

Re: [PATCH 0/8] Thermal Framework Enhancements

[Hongbo Zhang]

On 21 December 2012 16:30, R, Durgadoss  wrote:
> Hi Ni,
>
>> -Original Message-
>> From: Wei Ni [mailto:w...@nvidia.com]
>> Sent: Friday, December 21, 2012 1:36 PM
>> To: R, Durgadoss
>> Cc: Zhang, Rui; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> hongbo.zh...@linaro.org
>> Subject: Re: [PATCH 0/8] Thermal Framework Enhancements
>>
>> On 12/18/2012 05:29 PM, Durgadoss R wrote:
>> > This patch is a v1 based on the RFC submitted here:
>> > https://patchwork.kernel.org/patch/1758921/
>> >
>> > This patch set is based on Rui's -thermal tree, and is
>> > tested on a Core-i5 and an Atom netbook.
>> >
>> > This series contains 8 patches:
>> > Patch 1/8: Creates new sensor level APIs
>> > Patch 2/8: Creates new zone level APIs. The existing tzd structure is
>> >kept as such for clarity and compatibility purposes.
>> > Patch 3/8: Creates functions to add/remove a cdev to/from a zone. The
>> >existing tcd structure need not be modified.
>> > Patch 4/8: Adds a thermal_trip sysfs node, which exposes various trip
>> >points for all sensors present in a zone.
>> > Patch 5/8: Adds a thermal_map sysfs node. It is a compact representation
>> >of the binding relationship between a sensor and a cdev,
>> >within a zone.
>> > Patch 6/8: Creates Documentation for the new APIs. A new file is
>> >created for clarity. Final goal is to merge with the existing
>> >file or refactor the files, as whatever seems appropriate.
>> > Patch 7/8: Make PER ZONE values configurable through Kconfig
>> > Patch 8/8: A dummy driver that can be used for testing. This is not for
>> merge.
>>
>> I read these patches, they create new APIs and sysfs, but it seems they
>> didn't use the thermal_zone to handle the thermal_throttle issue,
>> something like update thermal_zone, update temperature, handle
>> governors
>> when cross the trip temp. So will you send out next serial patches for
>> these implementation?
>
> Yes, once these get into Rui's tree, we will start migrating the existing 
> drivers/
> and governors, to get things working.
Durgadoss,
See function psy_register_thermal() in power_supply_core.c,
thermal_zone_device_register() is used here, what will this look like
in future?
Create thermal zone here?
Or add sensor to thermal zone? if so, how do we know which zone to add
sensor to?


>
> Thanks,
> Durga
--
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 V5 1/2] Thermal: Add ST-Ericsson DB8500 thermal driver.

[Hongbo Zhang]

On 15 November 2012 18:17, Viresh Kumar  wrote:
> On 15 November 2012 14:53, Hongbo Zhang  wrote:
>> this is a driver for ST-Ericsson u8500 board(Snowball), with a ARM core 
>> inside.
>> so you should compile like this:
>> make  ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- u8500_defconfig
>> make  ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage
>
> Then we must have a DEPENDS_ON in Kconfig entry for these.
Sorry for the negligence.
A V6 iteration has been sent out with "depends on ARCH_U8500" added.
Thank all of you.
>
>
> --
> viresh
--
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 V5 1/2] Thermal: Add ST-Ericsson DB8500 thermal driver.

[Hongbo Zhang]

this is a driver for ST-Ericsson u8500 board(Snowball), with a ARM core inside.
so you should compile like this:
make  ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- u8500_defconfig
make  ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage


On 15 November 2012 17:13, Zhang Rui  wrote:
> On Thu, 2012-11-15 at 16:32 +0800, Hongbo Zhang wrote:
>> On 15 November 2012 16:13, Zhang Rui  wrote:
>> > On Fri, 2012-11-09 at 19:29 +0800, hongbo.zhang wrote:
>> >> From: "hongbo.zhang" 
>> >>
>> >> This driver is based on the thermal management framework in 
>> >> thermal_sys.c. A
>> >> thermal zone device is created with the trip points to which cooling 
>> >> devices
>> >> can be bound, the current cooling device is cpufreq, e.g. CPU frequency is
>> >> clipped down to cool the CPU, and other cooling devices can be added and 
>> >> bound
>> >> to the trip points dynamically.  The platform specific PRCMU interrupts 
>> >> are
>> >> used to active thermal update when trip points are reached.
>> >>
>> >> Signed-off-by: hongbo.zhang 
>> >> Reviewed-by: Viresh Kumar 
>> >> Reviewed-by: Francesco Lavra 
>> >
>> >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> >> index e1cb6bd..54c8fd0 100644
>> >> --- a/drivers/thermal/Kconfig
>> >> +++ b/drivers/thermal/Kconfig
>> >> @@ -31,6 +31,26 @@ config CPU_THERMAL
>> >> and not the ACPI interface.
>> >> If you want this support, you should say Y here.
>> >>
>> >> +config DB8500_THERMAL
>> >> + bool "DB8500 thermal management"
>> >
>> > why is this bool?
>>
>> platform specific PRCMU interfaces are used, and those interfaces are
>> not exported, so my driver cannot be compiled as a module.
>>
> ok.
> But I still alway get this error message when set DB8500_THERMAL,
> include/linux/mfd/dbx500-prcmu.h:459:19: error: redefinition of
> ‘prcmu_abb_read’
> include/linux/mfd/db8500-prcmu.h:673:19: note: previous definition of
> ‘prcmu_abb_read’ was here
> include/linux/mfd/dbx500-prcmu.h:464:19: error: redefinition of
> ‘prcmu_abb_write’
> include/linux/mfd/db8500-prcmu.h:678:19: note: previous definition of
> ‘prcmu_abb_write’ was here
> include/linux/mfd/dbx500-prcmu.h:475:19: error: redefinition of
> ‘prcmu_config_clkout’
> include/linux/mfd/db8500-prcmu.h:643:19: note: previous definition of
> ‘prcmu_config_clkout’ was here
> include/linux/mfd/dbx500-prcmu.h:537:19: error: redefinition of
> ‘prcmu_ac_wake_req’
> include/linux/mfd/db8500-prcmu.h:683:19: note: previous definition of
> ‘prcmu_ac_wake_req’ was here
> include/linux/mfd/dbx500-prcmu.h:542:20: error: redefinition of
> ‘prcmu_ac_sleep_req’
> include/linux/mfd/db8500-prcmu.h:688:20: note: previous definition of
> ‘prcmu_ac_sleep_req’ was here
>
> $ grep prcmu_abb_read include/linux/mfd/*
> include/linux/mfd/db8500-prcmu.h:int prcmu_abb_read(u8 slave, u8 reg, u8
> *value, u8 size);
> include/linux/mfd/db8500-prcmu.h:static inline int prcmu_abb_read(u8
> slave, u8 reg, u8 *value, u8 size)
> include/linux/mfd/dbx500-prcmu.h:int prcmu_abb_read(u8 slave, u8 reg, u8
> *value, u8 size);
> include/linux/mfd/dbx500-prcmu.h:static inline int prcmu_abb_read(u8
> slave, u8 reg, u8 *value, u8 size)
>
> this functions are defined in both db8500-prmcu.h and dbx500-prcmu.h,
> plus linux/mfd/dbx500-prcmu.h includes linux/mfd/db8500-prcmu.h.
>
> I do not know how it works before, but this is a bug to me.
>
> thanks,
> rui
>
--
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 V5 1/2] Thermal: Add ST-Ericsson DB8500 thermal driver.

[Hongbo Zhang]

On 15 November 2012 16:13, Zhang Rui  wrote:
> On Fri, 2012-11-09 at 19:29 +0800, hongbo.zhang wrote:
>> From: "hongbo.zhang" 
>>
>> This driver is based on the thermal management framework in thermal_sys.c. A
>> thermal zone device is created with the trip points to which cooling devices
>> can be bound, the current cooling device is cpufreq, e.g. CPU frequency is
>> clipped down to cool the CPU, and other cooling devices can be added and 
>> bound
>> to the trip points dynamically.  The platform specific PRCMU interrupts are
>> used to active thermal update when trip points are reached.
>>
>> Signed-off-by: hongbo.zhang 
>> Reviewed-by: Viresh Kumar 
>> Reviewed-by: Francesco Lavra 
>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index e1cb6bd..54c8fd0 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -31,6 +31,26 @@ config CPU_THERMAL
>> and not the ACPI interface.
>> If you want this support, you should say Y here.
>>
>> +config DB8500_THERMAL
>> + bool "DB8500 thermal management"
>
> why is this bool?

platform specific PRCMU interfaces are used, and those interfaces are
not exported, so my driver cannot be compiled as a module.

>
> thanks,
> rui
>
>
> --
> 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/
--
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 V5 2/2] Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.

[Hongbo Zhang]

On 13 November 2012 04:46, Linus Walleij  wrote:
> On Mon, Nov 12, 2012 at 7:07 AM, Zhang Rui  wrote:
>> On Fri, 2012-11-09 at 19:29 +0800, hongbo.zhang wrote:
>>> From: "hongbo.zhang" 
>>>
>>> This patch adds device tree properties for ST-Ericsson DB8500 thermal 
>>> driver,
>>> also adds the platform data to support the old fashion.
>>>
>>> Signed-off-by: hongbo.zhang 
>>> Reviewed-by: Viresh Kumar 
>>
>> hmmm,
>>
>> who should take this patch?
>> I'd like to see ACK from the maintainer of these code before applying
>> them to thermal tree.
>
> I guess it needs to go through Thermal.
>
> Acked-by: Linus Walleij 

Thank you Linus Walleij.

Hi Rui, I got it.

> Let's hope it's not creating too much conflict...
>
> 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 V3 3/5] Thermal: Remove the cooling_cpufreq_list.

[Hongbo Zhang]

On 7 November 2012 14:54, Zhang Rui  wrote:
> On Tue, 2012-10-30 at 17:48 +0100, hongbo.zhang wrote:
>> From: "hongbo.zhang" 
>>
>> Problem of using this list is that the cpufreq_get_max_state callback will be
>> called when register cooling device by thermal_cooling_device_register, but
>> this list isn't ready at this moment. What's more, there is no need to 
>> maintain
>> such a list, we can get cpufreq_cooling_device instance by the private
>> thermal_cooling_device.devdata.
>>
>> Signed-off-by: hongbo.zhang 
>> Reviewed-by: Francesco Lavra 
>> Reviewed-by: Amit Daniel Kachhap 
>
> applied to thermal-next.
Thanks.
I have sent the other updated 4/5 5/5 patches with Reviewed-by added
in a new thread, please have a look there.

>
> thanks,
> rui
>
>> ---
>>  drivers/thermal/cpu_cooling.c | 91 
>> +--
>>  1 file changed, 19 insertions(+), 72 deletions(-)
>>
>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
>> index bfd62b7..392d57d 100644
>> --- a/drivers/thermal/cpu_cooling.c
>> +++ b/drivers/thermal/cpu_cooling.c
>> @@ -58,8 +58,9 @@ struct cpufreq_cooling_device {
>>  };
>>  static LIST_HEAD(cooling_cpufreq_list);
>>  static DEFINE_IDR(cpufreq_idr);
>> +static DEFINE_MUTEX(cooling_cpufreq_lock);
>>
>> -static struct mutex cooling_cpufreq_lock;
>> +static unsigned int cpufreq_dev_count;
>>
>>  /* notify_table passes value to the CPUFREQ_ADJUST callback function. */
>>  #define NOTIFY_INVALID NULL
>> @@ -240,28 +241,18 @@ static int cpufreq_thermal_notifier(struct 
>> notifier_block *nb,
>>  static int cpufreq_get_max_state(struct thermal_cooling_device *cdev,
>>unsigned long *state)
>>  {
>> - int ret = -EINVAL, i = 0;
>> - struct cpufreq_cooling_device *cpufreq_device;
>> - struct cpumask *maskPtr;
>> + struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
>> + struct cpumask *maskPtr = &cpufreq_device->allowed_cpus;
>>   unsigned int cpu;
>>   struct cpufreq_frequency_table *table;
>>   unsigned long count = 0;
>> + int i = 0;
>>
>> - mutex_lock(&cooling_cpufreq_lock);
>> - list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node) {
>> - if (cpufreq_device && cpufreq_device->cool_dev == cdev)
>> - break;
>> - }
>> - if (cpufreq_device == NULL)
>> - goto return_get_max_state;
>> -
>> - maskPtr = &cpufreq_device->allowed_cpus;
>>   cpu = cpumask_any(maskPtr);
>>   table = cpufreq_frequency_get_table(cpu);
>>   if (!table) {
>>   *state = 0;
>> - ret = 0;
>> - goto return_get_max_state;
>> + return 0;
>>   }
>>
>>   for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
>> @@ -272,12 +263,10 @@ static int cpufreq_get_max_state(struct 
>> thermal_cooling_device *cdev,
>>
>>   if (count > 0) {
>>   *state = --count;
>> - ret = 0;
>> + return 0;
>>   }
>>
>> -return_get_max_state:
>> - mutex_unlock(&cooling_cpufreq_lock);
>> - return ret;
>> + return -EINVAL;
>>  }
>>
>>  /**
>> @@ -288,20 +277,10 @@ return_get_max_state:
>>  static int cpufreq_get_cur_state(struct thermal_cooling_device *cdev,
>>unsigned long *state)
>>  {
>> - int ret = -EINVAL;
>> - struct cpufreq_cooling_device *cpufreq_device;
>> + struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
>>
>> - mutex_lock(&cooling_cpufreq_lock);
>> - list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node) {
>> - if (cpufreq_device && cpufreq_device->cool_dev == cdev) {
>> - *state = cpufreq_device->cpufreq_state;
>> - ret = 0;
>> - break;
>> - }
>> - }
>> - mutex_unlock(&cooling_cpufreq_lock);
>> -
>> - return ret;
>> + *state = cpufreq_device->cpufreq_state;
>> + return 0;
>>  }
>>
>>  /**
>> @@ -312,22 +291,9 @@ static int cpufreq_get_cur_state(struct 
>> thermal_cooling_device *cdev,
>>  static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
>>unsigned long state)
>>  {
>> - int ret = -EINVAL;
>> - struct cpufreq_cooling_device *cpufreq_device;
>> + struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
>>
>> - mutex_lock(&cooling_cpufreq_lock);
>> - list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node) {
>> - if (cpufreq_device && cpufreq_device->cool_dev == cdev) {
>> - ret = 0;
>> - break;
>> - }
>> - }
>> - if (!ret)
>> - ret = cpufreq_apply_cooling(cpufreq_device, state);
>> -
>> - mutex_unlock(&cooling_cpufreq_lock);
>> -
>> - return ret;
>> + return cpufreq_apply_cooling(cpufreq_device, state);
>>  }
>>
>>  /* Bind cpufreq callbacks to thermal cooling dev

Re: [PATCH V5 0/2] Upstream ST-Ericsson thermal driver

[Hongbo Zhang]

Hi Rui Zhang,
Please have a look at this patch set.
Since the previous 1/5, 2/5, 3/5 have been accepted, I'd like to send
these last two updated patches with Reviewed-by added in this new
thread.

Thanks.

On 9 November 2012 19:29, hongbo.zhang  wrote:
> From: "hongbo.zhang" 
>
> V4->V5 Changes:
>
> In patch "Thermal: Add ST-Ericsson DB8500 thermal driver":
>  - use flush_work instead of flush_work_sync since the later is deprecated 
> now.
>  - parameter trip_points of db8500_thermal_match_cdev is renamed to 
> trip_point;
>  - re-order oprerations in function db8500_thermal_update_config;
>
> hongbo.zhang (2):
>   Thermal: Add ST-Ericsson DB8500 thermal driver.
>   Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.
>
>  .../devicetree/bindings/thermal/db8500-thermal.txt |  44 ++
>  arch/arm/boot/dts/dbx5x0.dtsi  |  14 +
>  arch/arm/boot/dts/snowball.dts |  31 ++
>  arch/arm/configs/u8500_defconfig   |   2 +
>  arch/arm/mach-ux500/board-mop500.c |  64 +++
>  drivers/thermal/Kconfig|  20 +
>  drivers/thermal/Makefile   |   2 +
>  drivers/thermal/db8500_cpufreq_cooling.c   | 108 +
>  drivers/thermal/db8500_thermal.c   | 531 
> +
>  include/linux/platform_data/db8500_thermal.h   |  38 ++
>  10 files changed, 854 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/thermal/db8500-thermal.txt
>  create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c
>  create mode 100644 drivers/thermal/db8500_thermal.c
>  create mode 100644 include/linux/platform_data/db8500_thermal.h
>
> --
> 1.7.11.3
>
--
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 4/5] Thermal: Add ST-Ericsson DB8500 thermal driver.

[Hongbo Zhang]

On 6 November 2012 18:17, Hongbo Zhang  wrote:
> On 1 November 2012 09:52, Zhang, Rui  wrote:
>>
>>
>>> -Original Message-
>>> From: hongbo.zhang [mailto:hongbo.zh...@linaro.org]
>>> Sent: Wednesday, October 31, 2012 12:49 AM
>>> To: linaro-...@lists.linaro.org; linux-kernel@vger.kernel.org; linux-
>>> p...@vger.kernel.org; Zhang, Rui; amit.kach...@linaro.org
>>> Cc: patc...@linaro.org; linaro-ker...@lists.linaro.org;
>>> stericsson_nomadik_li...@list.st.com; ker...@igloocommunity.org;
>>> hongbo.zhang
>>> Subject: [PATCH V3 4/5] Thermal: Add ST-Ericsson DB8500 thermal driver.
>>> Importance: High
>>>
>>> From: "hongbo.zhang" 
>>>
>>> This diver is based on the thermal management framework in
>>> thermal_sys.c. A thermal zone device is created with the trip points to
>>> which cooling devices can be bound, the current cooling device is
>>> cpufreq, e.g. CPU frequency is clipped down to cool the CPU, and other
>>> cooling devices can be added and bound to the trip points dynamically.
>>> The platform specific PRCMU interrupts are used to active thermal
>>> update when trip points are reached.
>>>
>>> Signed-off-by: hongbo.zhang 
>>> ---
>>>  .../devicetree/bindings/thermal/db8500-thermal.txt |  40 ++
>>>  drivers/thermal/Kconfig|  20 +
>>>  drivers/thermal/Makefile   |   2 +
>>>  drivers/thermal/db8500_cpufreq_cooling.c   | 108 +
>>>  drivers/thermal/db8500_thermal.c   | 531
>>> +
>>>  include/linux/platform_data/db8500_thermal.h   |  38 ++
>>>  6 files changed, 739 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/thermal/db8500-
>>> thermal.txt
>>>  create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c
>>>  create mode 100644 drivers/thermal/db8500_thermal.c  create mode
>>> 100644 include/linux/platform_data/db8500_thermal.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/thermal/db8500-
>>> thermal.txt b/Documentation/devicetree/bindings/thermal/db8500-
>>> thermal.txt
>>> new file mode 100644
>>> index 000..cab6916
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
>>> @@ -0,0 +1,40 @@
>>> +* ST-Ericsson DB8500 Thermal
>>> +
>>> +** Thermal node properties:
>>> +
>>> +- compatible : "stericsson,db8500-thermal";
>>> +- reg : address range of the thermal sensor registers;
>>> +- interrupts : interrupts generated from PRCMU;
>>> +- interrupt-names : "IRQ_HOTMON_LOW" and "IRQ_HOTMON_HIGH";
>>> +- num-trips : number of total trip points;
>>> +- tripN-temp : temperature of trip point N, should be in ascending
>>> +order;
>>> +- tripN-type : type of trip point N, should be one of "active"
>>> +"passive" "hot" "critical";
>>> +- tripN-cdev-num : number of the cooling devices which can be bound to
>>> +trip point N;
>>> +- tripN-cdev-nameM : name of the No. M cooling device of trip point N;
>>> +
>>> +Usually the num-trips and tripN-*** are separated in board related dts
>>> files.
>>> +
>>> +Example:
>>> +thermal@801573c0 {
>>> + compatible = "stericsson,db8500-thermal";
>>> + reg = <0x801573c0 0x40>;
>>> + interrupts = <21 0x4>, <22 0x4>;
>>> + interrupt-names = "IRQ_HOTMON_LOW", "IRQ_HOTMON_HIGH";
>>> +
>>> + num-trips = <3>;
>>> +
>>> + trip0-temp = <7>;
>>> + trip0-type = "active";
>>> + trip0-cdev-num = <1>;
>>> + trip0-cdev-name0 = "thermal-cpufreq-0";
>>> +
>>> + trip1-temp = <75000>;
>>> + trip1-type = "active";
>>> + trip1-cdev-num = <2>;
>>> + trip1-cdev-name0 = "thermal-cpufreq-0";
>>> + trip1-cdev-name1 = "thermal-fan";
>>> +
>>> + trip2-temp = <85000>;
>>> + trip2-type = "critical";
>>> + trip2-cdev-num = <0>;
>>> +}
>>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index
>>> e1cb6bd..54c8fd0 100644
>>> --- a/drivers/thermal/Kconfig
>>> +++ b/drivers/thermal

Re: [PATCH V3 4/5] Thermal: Add ST-Ericsson DB8500 thermal driver.

[Hongbo Zhang]

; thermal
>> +   management framework. A thermal zone with several trip points
>> will be
>> +   created. Cooling devices can be bound to the trip points to
>> cool this
>> +   thermal zone if trip points reached.
>> +
>> +config DB8500_CPUFREQ_COOLING
>> + tristate "DB8500 cpufreq cooling"
>> + depends on CPU_THERMAL
>> + default y
>> + help
>> +   Adds DB8500 cpufreq cooling devices, and these cooling devices
>> can be
>> +   bound to thermal zone trip points. When a trip point reached,
>> the
>> +   bound cpufreq cooling device turns active to set CPU frequency
>> low to
>> +   cool down the CPU.
>> +
>>  config SPEAR_THERMAL
>>   bool "SPEAr thermal sensor driver"
>>   depends on THERMAL
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index
>> 885550d..c7a8dab 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -7,3 +7,5 @@ obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
>>  obj-$(CONFIG_SPEAR_THERMAL)  += spear_thermal.o
>>  obj-$(CONFIG_RCAR_THERMAL)   += rcar_thermal.o
>>  obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
>> +obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
>> +obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
>> diff --git a/drivers/thermal/db8500_cpufreq_cooling.c
>> b/drivers/thermal/db8500_cpufreq_cooling.c
>> new file mode 100644
>> index 000..4cf8e72
>> --- /dev/null
>> +++ b/drivers/thermal/db8500_cpufreq_cooling.c
>> @@ -0,0 +1,108 @@
>> +/*
>> + * db8500_cpufreq_cooling.c - DB8500 cpufreq works as cooling device.
>> + *
>> + * Copyright (C) 2012 ST-Ericsson
>> + * Copyright (C) 2012 Linaro Ltd.
>> + *
>> + * Author: Hongbo Zhang 
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify
>> + * it under the terms of the GNU General Public License as published
>> by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static int db8500_cpufreq_cooling_probe(struct platform_device *pdev)
>> {
>> + struct thermal_cooling_device *cdev;
>> + struct cpumask mask_val;
>> +
>> + /* make sure cpufreq driver has been initialized */
>> + if (!cpufreq_frequency_get_table(0))
>> + return -EPROBE_DEFER;
>> +
>> + cpumask_set_cpu(0, &mask_val);
>> + cdev = cpufreq_cooling_register(&mask_val);
>> +
>> + if (IS_ERR_OR_NULL(cdev)) {
>> + dev_err(&pdev->dev, "Failed to register cooling device\n");
>> + return PTR_ERR(cdev);
>> + }
>> +
>> + platform_set_drvdata(pdev, cdev);
>> +
>> + dev_info(&pdev->dev, "Cooling device registered: %s\n", cdev-
>> >type);
>> +
>> + return 0;
>> +}
>> +
>> +static int db8500_cpufreq_cooling_remove(struct platform_device *pdev)
>> +{
>> + struct thermal_cooling_device *cdev = platform_get_drvdata(pdev);
>> +
>> + cpufreq_cooling_unregister(cdev);
>> +
>> + return 0;
>> +}
>> +
>> +static int db8500_cpufreq_cooling_suspend(struct platform_device *pdev,
>> + pm_message_t state)
>> +{
>> + return -ENOSYS;
>> +}
>> +
>> +static int db8500_cpufreq_cooling_resume(struct platform_device *pdev)
>> +{
>> + return -ENOSYS;
>> +}
>> +
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id db8500_cpufreq_cooling_match[] = {
>> + { .compatible = "stericsson,db8500-cpufreq-cooling" },
>> + {},
>> +};
>> +#else
>> +#define db8500_cpufreq_cooling_match NULL #endif
>> +
>> +static struct platform_driver db8500_cpufreq_cooling_driver = {
>> + .driver = {
>> + .owner = THIS_MODULE,
>> + .name = "db8500-cpufreq-cooling",
>> + .of_match_table = db8500_cpufreq_cooling_match,
>> + },
>> + 

Re: [PATCH V3 5/5] Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.

[Hongbo Zhang]

On 31 October 2012 10:18, viresh kumar  wrote:
> On Tue, Oct 30, 2012 at 10:19 PM, hongbo.zhang  
> wrote:
>> From: "hongbo.zhang" 
>
> Just a minor comment below.
>
>> This patch adds device tree properties for ST-Ericsson DB8500 thermal driver,
>> also adds the platform data to support the old fashion.
>>
>> Signed-off-by: hongbo.zhang 
>
> Reviewed-by: Viresh Kumar 
>
>> ---
>>  arch/arm/boot/dts/dbx5x0.dtsi  | 14 +
>>  arch/arm/boot/dts/snowball.dts | 31 ++
>>  arch/arm/configs/u8500_defconfig   |  4 +++
>>  arch/arm/mach-ux500/board-mop500.c | 64 
>> ++
>>  4 files changed, 113 insertions(+)
>
>> diff --git a/arch/arm/configs/u8500_defconfig 
>> b/arch/arm/configs/u8500_defconfig
>> index cc5e7a8..34918c4 100644
>> --- a/arch/arm/configs/u8500_defconfig
>> +++ b/arch/arm/configs/u8500_defconfig
>> @@ -118,3 +118,7 @@ CONFIG_DEBUG_KERNEL=y
>>  CONFIG_DEBUG_INFO=y
>>  # CONFIG_FTRACE is not set
>>  CONFIG_DEBUG_USER=y
>> +CONFIG_THERMAL=y
>> +CONFIG_CPU_THERMAL=y
>> +CONFIG_DB8500_THERMAL=y
>> +CONFIG_DB8500_CPUFREQ_COOLING=y
>
> Have you entered these manually?? Or used make savedefconfig?
Yes these are added manually, make savedefconfig should be better, but
it seems the original defconfig file are not well generated by
savedefconfig, this file will be changed too much if I use make
savedefconfig. If this is an issue, I will inform the maintainer to
update this.
After consideration, for this time, I will use savedefconfig to find
right places for my configs, discarding the other dis-order ones.
--
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 2/6] Thermal: make sure cpufreq cooling register after cpufreq driver

[Hongbo Zhang]

On 29 October 2012 12:42, Amit Kachhap  wrote:
> On 24 October 2012 17:28, hongbo.zhang  wrote:
>> From: "hongbo.zhang" 
>>
>> The cpufreq works as a cooling device, so the cooling layer should check if 
>> the
>> cpufreq driver is initialized or not.
>>
>> Signed-off-by: hongbo.zhang 
>> ---
>>  drivers/thermal/cpu_cooling.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
>> index b6b4c2a..7519a0b 100644
>> --- a/drivers/thermal/cpu_cooling.c
>> +++ b/drivers/thermal/cpu_cooling.c
>> @@ -354,6 +354,10 @@ struct thermal_cooling_device *cpufreq_cooling_register(
>> int ret = 0, i;
>> struct cpufreq_policy policy;
>>
>> +   /* make sure cpufreq driver has been initialized */
>> +   if (!cpufreq_frequency_get_table(cpumask_any(clip_cpus)))
>> +   return ERR_PTR(-EPROBE_DEFER);
>> +
> Hi Hongbo,
>
> I am not against this change but this might cause unnecessary delay in
> probe thread. I also thought about it but have not put this
> restriction. Actually you can put a check in platform_bind for this
> condition and defer the binding till the time actual throttling
> starts. So basically only after throttling cpufreq_table is needed.
> (See my implementation exynos_thermal.c).
In fact, this piece of checking code was in my
db8500_cpufreq_cooling_probe() before, I will move it back there
again, and the ST-E's policy is separating cooling devs and thermal
zone, so cannot be in binding function on my platform, only in probe
function instead.
>
> Thanks,
> Amit Daniel
>> list_for_each_entry(cpufreq_dev, &cooling_cpufreq_list, node)
>> cpufreq_dev_count++;
>>
>> --
>> 1.7.11.3
>>
>>
>> ___
>> linaro-dev mailing list
>> linaro-...@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-dev
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 4/6] Thermal: Remove the cooling_cpufreq_list.

[Hongbo Zhang]

On 30 October 2012 09:03, Amit Kachhap  wrote:
> On 26 October 2012 12:39, hongbo.zhang  wrote:
>> From: "hongbo.zhang" 
>>
>> Problem of using this list is that the cpufreq_get_max_state callback will be
>> called when register cooling device by thermal_cooling_device_register, but
>> this list isn't ready at this moment. What's more, there is no need to 
>> maintain
>> such a list, we can get cpufreq_cooling_device instance by the private
>> thermal_cooling_device.devdata.
>
> Hi,
>
> Removing this list seems fine as most of frequency checks are moved
> inside generic thermal layer.
> Some minor review comments below,
>
> Reviewed-by: Amit Daniel Kachhap 
Thanks.
>>
>> Signed-off-by: hongbo.zhang 
>> ---
>>  drivers/thermal/cpu_cooling.c | 91 
>> +--
>>  1 file changed, 19 insertions(+), 72 deletions(-)
>>
>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
>> index 415b041..2ffd12c 100644
>> --- a/drivers/thermal/cpu_cooling.c
>> +++ b/drivers/thermal/cpu_cooling.c
>> @@ -58,8 +58,9 @@ struct cpufreq_cooling_device {
>>  };
>>  static LIST_HEAD(cooling_cpufreq_list);
>>  static DEFINE_IDR(cpufreq_idr);
>> +static DEFINE_MUTEX(cooling_cpufreq_lock);
>>
>> -static struct mutex cooling_cpufreq_lock;
>> +static unsigned int cpufreq_dev_count;
>>
>>  /* notify_table passes value to the CPUFREQ_ADJUST callback function. */
>>  #define NOTIFY_INVALID NULL
>> @@ -240,28 +241,18 @@ static int cpufreq_thermal_notifier(struct 
>> notifier_block *nb,
>>  static int cpufreq_get_max_state(struct thermal_cooling_device *cdev,
>>  unsigned long *state)
>>  {
>> -   int ret = -EINVAL, i = 0;
>> -   struct cpufreq_cooling_device *cpufreq_device;
>> -   struct cpumask *maskPtr;
>> +   struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
> check cdev is not null.
>> +   struct cpumask *maskPtr = &cpufreq_device->allowed_cpus;
>> unsigned int cpu;
>> struct cpufreq_frequency_table *table;
>> unsigned long count = 0;
>> +   int i = 0;
>>
>> -   mutex_lock(&cooling_cpufreq_lock);
>> -   list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node) {
>> -   if (cpufreq_device && cpufreq_device->cool_dev == cdev)
>> -   break;
>> -   }
>> -   if (cpufreq_device == NULL)
>> -   goto return_get_max_state;
>> -
>> -   maskPtr = &cpufreq_device->allowed_cpus;
>> cpu = cpumask_any(maskPtr);
>> table = cpufreq_frequency_get_table(cpu);
>> if (!table) {
>> *state = 0;
>> -   ret = 0;
>> -   goto return_get_max_state;
>> +   return 0;
>> }
>>
>> for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
>> @@ -272,12 +263,10 @@ static int cpufreq_get_max_state(struct 
>> thermal_cooling_device *cdev,
>>
>> if (count > 0) {
>> *state = --count;
>> -   ret = 0;
>> +   return 0;
>> }
>>
>> -return_get_max_state:
>> -   mutex_unlock(&cooling_cpufreq_lock);
>> -   return ret;
>> +   return -EINVAL;
>>  }
>>
>>  /**
>> @@ -288,20 +277,10 @@ return_get_max_state:
>>  static int cpufreq_get_cur_state(struct thermal_cooling_device *cdev,
>>  unsigned long *state)
>>  {
>> -   int ret = -EINVAL;
>> -   struct cpufreq_cooling_device *cpufreq_device;
>> +   struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
>>
>> -   mutex_lock(&cooling_cpufreq_lock);
>> -   list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node) {
>> -   if (cpufreq_device && cpufreq_device->cool_dev == cdev) {
>> -   *state = cpufreq_device->cpufreq_state;
>> -   ret = 0;
>> -   break;
>> -   }
>> -   }
>> -   mutex_unlock(&cooling_cpufreq_lock);
>> -
>> -   return ret;
>> +   *state = cpufreq_device->cpufreq_state;
>> +   return 0;
>>  }
>>
>>  /**
>> @@ -312,22 +291,9 @@ static int cpufreq_get_cur_state(struct 
>> thermal_cooling_device *cdev,
>>  static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
>>  unsigned long state)
>>  {
>> -   int ret = -EINVAL;
>> -   struct cpufreq_cooling_device *cpufreq_device;
>> +   struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
> check cdev is not null
Such values are used in all the three static cpufreq_***_state
callback functions, when these functions are called, cdev->devdata
should have been set in the registration function, and cannot be null,
no body can call these function before registration, so I think there
is no need to add such a check here.

>>
>> -   mutex_lock(&cooling_cpufreq_lock);
>> -   list_for_each_entry(cpufreq_device, &cooling_cpufreq_list, node) {
>> -   if (cpufreq_devic