Re: [GIT PULL 0/5] EFI urgent fixes

[Ingo Molnar]

* Matt Fleming  wrote:

> On Tue, 16 Feb, at 01:15:45PM, Ingo Molnar wrote:
> > 
> > Pulled, thanks Matt!
> 
> Thanks a lot Ingo.
> 
> I've actually got a couple of stragglers that came before the weekend
> that fix bugs. It would be good to pick them up before you send a pull
> request to Linus.
> 
> I'll send out a second pull request momentarily.

I've pulled it all, so tip:x86/urgent should have everything needed. Please let 
me 
know if anything is amiss - I intend to send the fixes to Linus tomorrow-ish.

Thanks,

Ingo

Re: [GIT PULL 0/5] EFI urgent fixes

[Ingo Molnar]

* Matt Fleming  wrote:

> On Tue, 16 Feb, at 01:15:45PM, Ingo Molnar wrote:
> > 
> > Pulled, thanks Matt!
> 
> Thanks a lot Ingo.
> 
> I've actually got a couple of stragglers that came before the weekend
> that fix bugs. It would be good to pick them up before you send a pull
> request to Linus.
> 
> I'll send out a second pull request momentarily.

I've pulled it all, so tip:x86/urgent should have everything needed. Please let 
me 
know if anything is amiss - I intend to send the fixes to Linus tomorrow-ish.

Thanks,

Ingo

Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

[Heikki Krogerus]

On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
> > > That question has not been answered. It would be awkward for the OS
> > > to find itself in the slave role, which it is ill equipped for. So
> > > the data role should be switched before the new device is announced
> > > to user space. How is that handled?
> > 
> > In the class driver, once we add support for preselecting the role,
> > when the connection happens we compare the initial role to the
> > preselected one and execute swap if it differs. Only after that we
> > notify userspace.
> 
> Yes, but we need an API. We can't keep adding to it. So if that
> is to be supported, it needs to be defined now.

When you say API, do you mean the API the class provides to the
drivers? Or did you mean ABI which would be the sysfs in this case?

For the sysfs I would image we can manage with the current files,
current_data_role and current_power_role. If somebody writes to them
when we are disconnected, we still callback the dr_swap or pr_swap
hooks, and make a rule that when disconnected, it means we are
setting the "preferred" roles.

Would that be OK? Or did I still misunderstood your question?


Thanks,

-- 
heikki

Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

[Heikki Krogerus]

On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
> > > That question has not been answered. It would be awkward for the OS
> > > to find itself in the slave role, which it is ill equipped for. So
> > > the data role should be switched before the new device is announced
> > > to user space. How is that handled?
> > 
> > In the class driver, once we add support for preselecting the role,
> > when the connection happens we compare the initial role to the
> > preselected one and execute swap if it differs. Only after that we
> > notify userspace.
> 
> Yes, but we need an API. We can't keep adding to it. So if that
> is to be supported, it needs to be defined now.

When you say API, do you mean the API the class provides to the
drivers? Or did you mean ABI which would be the sysfs in this case?

For the sysfs I would image we can manage with the current files,
current_data_role and current_power_role. If somebody writes to them
when we are disconnected, we still callback the dr_swap or pr_swap
hooks, and make a rule that when disconnected, it means we are
setting the "preferred" roles.

Would that be OK? Or did I still misunderstood your question?


Thanks,

-- 
heikki

Re: [PATCH] crypto: fix compile errors of XTS

[Herbert Xu]

On Wed, Feb 17, 2016 at 07:00:01AM +0100, Stephan Mueller wrote:
> Commit 28856a9e52c7 missed the addition of the crypto/xts.h include file
> for different architecture-specific AES implementations.
> 
> Signed-off-by: Stephan Mueller 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: fix compile errors of XTS

[Herbert Xu]

On Wed, Feb 17, 2016 at 07:00:01AM +0100, Stephan Mueller wrote:
> Commit 28856a9e52c7 missed the addition of the crypto/xts.h include file
> for different architecture-specific AES implementations.
> 
> Signed-off-by: Stephan Mueller 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

RE: [PATCH] dts: ls102xa: ifc: Add the partition for NOR flash

[Huan Wang]

> On Wed, Feb 03, 2016 at 04:16:44PM +0800, Alison Wang wrote:
> > According to the new mapping table, the partition for NOR flash is
> > added.
> 
> How do you know that everyone using the board wants the NOR flash to be
> partitioned this way?  It's really a matter of software configuration
> and may vary from system to system.
>
[Alison Wang] Yes, the different partition could be used too. I just want to
provide one partition way.

Best Regards,
Alison Wang
> 
> >
> > Signed-off-by: Alison Wang 
> > ---
> >  arch/arm/boot/dts/ls1021a-qds.dts | 60
> > +++
> >  arch/arm/boot/dts/ls1021a-twr.dts | 60
> > +++
> >  2 files changed, 120 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/ls1021a-qds.dts
> > b/arch/arm/boot/dts/ls1021a-qds.dts
> > index 9408753..904ee09 100644
> > --- a/arch/arm/boot/dts/ls1021a-qds.dts
> > +++ b/arch/arm/boot/dts/ls1021a-qds.dts
> > @@ -237,6 +237,66 @@
> > reg = <0x0 0x0 0x800>;
> > bank-width = <2>;
> > device-width = <1>;
> > +
> > +   partition@0 {
> > +   /* 128KB for bank0 RCW */
> > +   reg = <0x 0x0002>;
> > +   label = "NOR bank0 RCW Image";
> > +   };
> > +
> > +   partition@10 {
> > +   /* 1MB for bank0 u-boot Image */
> > +   reg = <0x0010 0x0010>;
> > +   label = "NOR bank0 u-boot Image";
> > +   };
> > +
> > +   partition@20 {
> > +   /* 1MB for bank0 DTB */
> > +   reg = <0x0020 0x0010>;
> > +   label = "NOR bank0 DTB Image";
> > +   };
> > +
> > +   partition@30 {
> > +   /* 7MB for bank0 Linux Kernel */
> > +   reg = <0x0030 0x0070>;
> > +   label = "NOR bank0 Linux Kernel Image";
> > +   };
> > +
> > +   partition@a0 {
> > +   /* 54MB for bank0 Ramdisk Root File System */
> > +   reg = <0x00a0 0x0360>;
> > +   label = "NOR bank0 Ramdisk Root File System Image";
> > +   };
> > +
> > +   partition@400 {
> > +   /* 128KB for bank4 RCW */
> > +   reg = <0x0400 0x0002>;
> > +   label = "NOR bank4 RCW Image";
> > +   };
> > +
> > +   partition@410 {
> > +   /* 1MB for bank4 u-boot Image */
> > +   reg = <0x0410 0x0010>;
> > +   label = "NOR bank4 u-boot Image";
> > +   };
> > +
> > +   partition@420 {
> > +   /* 1MB for bank4 DTB */
> > +   reg = <0x0420 0x0010>;
> > +   label = "NOR bank4 DTB Image";
> > +   };
> > +
> > +   partition@430 {
> > +   /* 7MB for bank4 Linux Kernel */
> > +   reg = <0x0430 0x0070>;
> > +   label = "NOR bank4 Linux Kernel Image";
> > +   };
> > +
> > +   partition@4a0 {
> > +   /* 54MB for bank4 Ramdisk Root File System */
> > +   reg = <0x04a0 0x0360>;
> > +   label = "NOR bank4 Ramdisk Root File System Image";
> > +   };
> > };
> >
> > fpga: board-control@3,0 {
> > diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
> > b/arch/arm/boot/dts/ls1021a-twr.dts
> > index 75ecaed..f5e9616 100644
> > --- a/arch/arm/boot/dts/ls1021a-twr.dts
> > +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> > @@ -194,6 +194,66 @@
> > reg = <0x0 0x0 0x800>;
> > bank-width = <2>;
> > device-width = <1>;
> > +
> > +   partition@0 {
> > +   /* 128KB for bank0 RCW */
> > +   reg = <0x 0x0002>;
> > +   label = "NOR bank0 RCW Image";
> > +   };
> > +
> > +   partition@10 {
> > +   /* 1MB for bank0 u-boot Image */
> > +   reg = <0x0010 0x0010>;
> > +   label = "NOR bank0 u-boot Image";
> > +   };
> > +
> > +   partition@20 {
> > +   /* 1MB for bank0 DTB */
> > +   reg = <0x0020 0x0010>;
> > +   label = "NOR bank0 DTB Image";
> > +   };
> > +
> > +   partition@30 {
> > +   /* 7MB for bank0 Linux Kernel */
> > +   reg = <0x0030 0x0070>;
> > +   label = "NOR bank0 Linux Kernel Image";
> > +   };
> > +
> > +   partition@a0 {
> > +   /* 54MB for bank0 Ramdisk Root File System */
> > +   reg = <0x00a0 0x0360>;
> > +   label = "NOR bank0 Ramdisk Root File System Image";
> > +   };
> > 

RE: [PATCH] dts: ls102xa: ifc: Add the partition for NOR flash

[Huan Wang]

> On Wed, Feb 03, 2016 at 04:16:44PM +0800, Alison Wang wrote:
> > According to the new mapping table, the partition for NOR flash is
> > added.
> 
> How do you know that everyone using the board wants the NOR flash to be
> partitioned this way?  It's really a matter of software configuration
> and may vary from system to system.
>
[Alison Wang] Yes, the different partition could be used too. I just want to
provide one partition way.

Best Regards,
Alison Wang
> 
> >
> > Signed-off-by: Alison Wang 
> > ---
> >  arch/arm/boot/dts/ls1021a-qds.dts | 60
> > +++
> >  arch/arm/boot/dts/ls1021a-twr.dts | 60
> > +++
> >  2 files changed, 120 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/ls1021a-qds.dts
> > b/arch/arm/boot/dts/ls1021a-qds.dts
> > index 9408753..904ee09 100644
> > --- a/arch/arm/boot/dts/ls1021a-qds.dts
> > +++ b/arch/arm/boot/dts/ls1021a-qds.dts
> > @@ -237,6 +237,66 @@
> > reg = <0x0 0x0 0x800>;
> > bank-width = <2>;
> > device-width = <1>;
> > +
> > +   partition@0 {
> > +   /* 128KB for bank0 RCW */
> > +   reg = <0x 0x0002>;
> > +   label = "NOR bank0 RCW Image";
> > +   };
> > +
> > +   partition@10 {
> > +   /* 1MB for bank0 u-boot Image */
> > +   reg = <0x0010 0x0010>;
> > +   label = "NOR bank0 u-boot Image";
> > +   };
> > +
> > +   partition@20 {
> > +   /* 1MB for bank0 DTB */
> > +   reg = <0x0020 0x0010>;
> > +   label = "NOR bank0 DTB Image";
> > +   };
> > +
> > +   partition@30 {
> > +   /* 7MB for bank0 Linux Kernel */
> > +   reg = <0x0030 0x0070>;
> > +   label = "NOR bank0 Linux Kernel Image";
> > +   };
> > +
> > +   partition@a0 {
> > +   /* 54MB for bank0 Ramdisk Root File System */
> > +   reg = <0x00a0 0x0360>;
> > +   label = "NOR bank0 Ramdisk Root File System Image";
> > +   };
> > +
> > +   partition@400 {
> > +   /* 128KB for bank4 RCW */
> > +   reg = <0x0400 0x0002>;
> > +   label = "NOR bank4 RCW Image";
> > +   };
> > +
> > +   partition@410 {
> > +   /* 1MB for bank4 u-boot Image */
> > +   reg = <0x0410 0x0010>;
> > +   label = "NOR bank4 u-boot Image";
> > +   };
> > +
> > +   partition@420 {
> > +   /* 1MB for bank4 DTB */
> > +   reg = <0x0420 0x0010>;
> > +   label = "NOR bank4 DTB Image";
> > +   };
> > +
> > +   partition@430 {
> > +   /* 7MB for bank4 Linux Kernel */
> > +   reg = <0x0430 0x0070>;
> > +   label = "NOR bank4 Linux Kernel Image";
> > +   };
> > +
> > +   partition@4a0 {
> > +   /* 54MB for bank4 Ramdisk Root File System */
> > +   reg = <0x04a0 0x0360>;
> > +   label = "NOR bank4 Ramdisk Root File System Image";
> > +   };
> > };
> >
> > fpga: board-control@3,0 {
> > diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
> > b/arch/arm/boot/dts/ls1021a-twr.dts
> > index 75ecaed..f5e9616 100644
> > --- a/arch/arm/boot/dts/ls1021a-twr.dts
> > +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> > @@ -194,6 +194,66 @@
> > reg = <0x0 0x0 0x800>;
> > bank-width = <2>;
> > device-width = <1>;
> > +
> > +   partition@0 {
> > +   /* 128KB for bank0 RCW */
> > +   reg = <0x 0x0002>;
> > +   label = "NOR bank0 RCW Image";
> > +   };
> > +
> > +   partition@10 {
> > +   /* 1MB for bank0 u-boot Image */
> > +   reg = <0x0010 0x0010>;
> > +   label = "NOR bank0 u-boot Image";
> > +   };
> > +
> > +   partition@20 {
> > +   /* 1MB for bank0 DTB */
> > +   reg = <0x0020 0x0010>;
> > +   label = "NOR bank0 DTB Image";
> > +   };
> > +
> > +   partition@30 {
> > +   /* 7MB for bank0 Linux Kernel */
> > +   reg = <0x0030 0x0070>;
> > +   label = "NOR bank0 Linux Kernel Image";
> > +   };
> > +
> > +   partition@a0 {
> > +   /* 54MB for bank0 Ramdisk Root File System */
> > +   reg = <0x00a0 0x0360>;
> > +   label = "NOR bank0 Ramdisk Root File System Image";
> > +   };
> > +
> > +   

Re: [PATCH v5 RESEND 4/5] ARM: amba: Move reading of periphid to amba_match()

[Marek Szyprowski]

Hello,

On 2016-02-15 18:52, Russell King - ARM Linux wrote:

On Wed, Feb 10, 2016 at 11:47:29AM +0100, Marek Szyprowski wrote:

From: Tomeu Vizoso 

Reading the periphid when the Primecell device is registered means that
the apb pclk must be available by then or the device won't be registered
at all.

By reading the periphid in amba_match() we can return -EPROBE_DEFER if
the apb pclk isn't there yet and the device will be retried later.

I've just realised, we can't do this.  We need to read the peripheral
ID at registration time, because that's published to userspace via
(a) a sysfs attribute, and (b) as part of the uevent, which will be
used by udev to locate the driver module.

So, this will have the side effect of breaking systems which have
AMBA primecell devices configured as modules.

Sorry, I can't apply this.  We can't regress existing platforms for
the sake of introducing new platforms to this code.


Then the only solution right now I see is to get back to v1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/388199.html
which at least handles correctly device registration when power domain 
driver

is available. You pointed that the patch cannot be applied, because failure
of dev_pm_domain_attach() will be fatal for device registration. Right now
lack of such call is fatal for the whole system, so there is really not a
big difference. Please also note that amba_get_enable_pclk() calls 
clk_get(),

which also might return -EPROBE_DEFER, which already breaks device
registration the same way.

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH v5 RESEND 4/5] ARM: amba: Move reading of periphid to amba_match()

[Marek Szyprowski]

Hello,

On 2016-02-15 18:52, Russell King - ARM Linux wrote:

On Wed, Feb 10, 2016 at 11:47:29AM +0100, Marek Szyprowski wrote:

From: Tomeu Vizoso 

Reading the periphid when the Primecell device is registered means that
the apb pclk must be available by then or the device won't be registered
at all.

By reading the periphid in amba_match() we can return -EPROBE_DEFER if
the apb pclk isn't there yet and the device will be retried later.

I've just realised, we can't do this.  We need to read the peripheral
ID at registration time, because that's published to userspace via
(a) a sysfs attribute, and (b) as part of the uevent, which will be
used by udev to locate the driver module.

So, this will have the side effect of breaking systems which have
AMBA primecell devices configured as modules.

Sorry, I can't apply this.  We can't regress existing platforms for
the sake of introducing new platforms to this code.


Then the only solution right now I see is to get back to v1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/388199.html
which at least handles correctly device registration when power domain 
driver

is available. You pointed that the patch cannot be applied, because failure
of dev_pm_domain_attach() will be fatal for device registration. Right now
lack of such call is fatal for the whole system, so there is really not a
big difference. Please also note that amba_get_enable_pclk() calls 
clk_get(),

which also might return -EPROBE_DEFER, which already breaks device
registration the same way.

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH 2/4] mfd: max77686: Use module_i2c_driver() instead of subsys initcall

[Krzysztof Kozlowski]

On 17.02.2016 05:45, Javier Martinez Canillas wrote:
> Hello Krzysztof,
> 
> On 02/15/2016 08:20 PM, Krzysztof Kozlowski wrote:
>> On 16.02.2016 00:21, Javier Martinez Canillas wrote:
>>> Hello Krzysztof,
>>>
>>> On 02/15/2016 03:54 AM, Krzysztof Kozlowski wrote:
 On 12.02.2016 13:30, Javier Martinez Canillas wrote:
> The driver's init and exit function don't do anything besides
> adding and
> deleting the I2C driver so the module_i2c_driver() macro could be
> used.
>
> Currently is not being used because the driver is initialized at
> subsys
> initcall level, claiming that this is done to allow consumers
> devices to
> use the resources provided by this driver. But dependencies should
> be in
> the DT and consumers drivers should not rely in the registration
> order.
>
> Signed-off-by: Javier Martinez Canillas 
> ---
>
>drivers/mfd/max77686.c | 13 +
>1 file changed, 1 insertion(+), 12 deletions(-)
>

 In the past not all dependencies supported deferred probing so such
 ordering was required.

 I don't like the "dependencies should be in DT" reason for the
 change...
 because it is kind of wishful thinking. Yeah, the dependencies
 should be
 in DT, but are they?

 Instead *please check it* and write:
 "Dependencies are in DT so manual ordering of init calls is not
 necessary any more".

>>>
>>> For the max77802 I know that's the case since the only two DTS in
>>> mainline
>>> that use it are the Peach Pit and Pi and I'm very familiar with those
>>> two.
>>>
>>> But I wonder how can I check that this is the case for the max77686.
>>> Most
>>> DTS in mainline have nodes that use some clocks and regulators
>>> provided by
>>> the PMIC, only arch/arm/boot/dts/exynos5250-smdk5250.dts doesn't have
>>> one
>>> of the regulators as input supply or clock consumer defined.
>>
>> +Cc Marek Szyprowski, who may know a lot more about dependencies between
>> these.
>>
>> I wouldn't care for drivers not taking references to regulators/clocks.
>> Most of necessary regulators and clocks are turned on by bootloader or
>> by default values in PMIC. This means that later probing of PMIC
>> shouldn't influence drivers which are not using it.
>>
>> The remaining problem was unsupported deferred probing by some of the
>> drivers using regulators/clocks (drivers being consumers of regulators
>> or clocks). AFAIR one of example was USB OTG.
>>
>> By "please check" in this case I mean - look if every regulator/clock
>> consumer using stuff exposed by PMIC, supports properly deferred probing.
>>
> 
> Got it, I checked and all but one consumer driver that use resources
> provided by the max77686 defer probe when this is not found AFAICT.
> 
> Clocks:
> 
> drivers/mmc/core/pwrseq_simple.c
> drivers/rtc/rtc-s3c.c
> 
> Regulators:
> 
> drivers/cpufreq/cpufreq-dt.c
> drivers/gpu/drm/exynos/exynos_drm_dsi.c
> drivers/gpu/drm/exynos/exynos_hdmi.c
> drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
> drivers/iio/adc/exynos_adc.c
> drivers/input/misc/max77693-haptic.c
> drivers/input/touchscreen/mms114.c
> drivers/media/i2c/s5c73m3/s5c73m3-core.c
> drivers/media/i2c/s5k6a3.c
> drivers/media/platform/exynos4-is/mipi-csis.c
> drivers/mfd/wm8994-core.c
> drivers/mmc/host/dw_mmc.c
> drivers/mmc/host/sdhci.c
> drivers/usb/dwc2/platform.c
> 
> The only driver that does not defer probe when an input supply
> isn't found is drivers/thermal/samsung/exynos_tmu.c (vtmu-supply).
> 
> So that should be handled before this series are merged.

Thanks for the analysis. Indeed the exynos_tmu does not support probe
deferral. Instead it just ignores the error and skips the regulator. It
would be good to fix this before applying this patch.

Rest looks indeed good so I don't have objections (beside tmu case).

Best regards,
Krzysztof

Re: [PATCH 2/4] mfd: max77686: Use module_i2c_driver() instead of subsys initcall

[Krzysztof Kozlowski]

On 17.02.2016 05:45, Javier Martinez Canillas wrote:
> Hello Krzysztof,
> 
> On 02/15/2016 08:20 PM, Krzysztof Kozlowski wrote:
>> On 16.02.2016 00:21, Javier Martinez Canillas wrote:
>>> Hello Krzysztof,
>>>
>>> On 02/15/2016 03:54 AM, Krzysztof Kozlowski wrote:
 On 12.02.2016 13:30, Javier Martinez Canillas wrote:
> The driver's init and exit function don't do anything besides
> adding and
> deleting the I2C driver so the module_i2c_driver() macro could be
> used.
>
> Currently is not being used because the driver is initialized at
> subsys
> initcall level, claiming that this is done to allow consumers
> devices to
> use the resources provided by this driver. But dependencies should
> be in
> the DT and consumers drivers should not rely in the registration
> order.
>
> Signed-off-by: Javier Martinez Canillas 
> ---
>
>drivers/mfd/max77686.c | 13 +
>1 file changed, 1 insertion(+), 12 deletions(-)
>

 In the past not all dependencies supported deferred probing so such
 ordering was required.

 I don't like the "dependencies should be in DT" reason for the
 change...
 because it is kind of wishful thinking. Yeah, the dependencies
 should be
 in DT, but are they?

 Instead *please check it* and write:
 "Dependencies are in DT so manual ordering of init calls is not
 necessary any more".

>>>
>>> For the max77802 I know that's the case since the only two DTS in
>>> mainline
>>> that use it are the Peach Pit and Pi and I'm very familiar with those
>>> two.
>>>
>>> But I wonder how can I check that this is the case for the max77686.
>>> Most
>>> DTS in mainline have nodes that use some clocks and regulators
>>> provided by
>>> the PMIC, only arch/arm/boot/dts/exynos5250-smdk5250.dts doesn't have
>>> one
>>> of the regulators as input supply or clock consumer defined.
>>
>> +Cc Marek Szyprowski, who may know a lot more about dependencies between
>> these.
>>
>> I wouldn't care for drivers not taking references to regulators/clocks.
>> Most of necessary regulators and clocks are turned on by bootloader or
>> by default values in PMIC. This means that later probing of PMIC
>> shouldn't influence drivers which are not using it.
>>
>> The remaining problem was unsupported deferred probing by some of the
>> drivers using regulators/clocks (drivers being consumers of regulators
>> or clocks). AFAIR one of example was USB OTG.
>>
>> By "please check" in this case I mean - look if every regulator/clock
>> consumer using stuff exposed by PMIC, supports properly deferred probing.
>>
> 
> Got it, I checked and all but one consumer driver that use resources
> provided by the max77686 defer probe when this is not found AFAICT.
> 
> Clocks:
> 
> drivers/mmc/core/pwrseq_simple.c
> drivers/rtc/rtc-s3c.c
> 
> Regulators:
> 
> drivers/cpufreq/cpufreq-dt.c
> drivers/gpu/drm/exynos/exynos_drm_dsi.c
> drivers/gpu/drm/exynos/exynos_hdmi.c
> drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
> drivers/iio/adc/exynos_adc.c
> drivers/input/misc/max77693-haptic.c
> drivers/input/touchscreen/mms114.c
> drivers/media/i2c/s5c73m3/s5c73m3-core.c
> drivers/media/i2c/s5k6a3.c
> drivers/media/platform/exynos4-is/mipi-csis.c
> drivers/mfd/wm8994-core.c
> drivers/mmc/host/dw_mmc.c
> drivers/mmc/host/sdhci.c
> drivers/usb/dwc2/platform.c
> 
> The only driver that does not defer probe when an input supply
> isn't found is drivers/thermal/samsung/exynos_tmu.c (vtmu-supply).
> 
> So that should be handled before this series are merged.

Thanks for the analysis. Indeed the exynos_tmu does not support probe
deferral. Instead it just ignores the error and skips the regulator. It
would be good to fix this before applying this patch.

Rest looks indeed good so I don't have objections (beside tmu case).

Best regards,
Krzysztof

Re: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver

[Hans Verkuil]

On 02/16/2016 07:37 AM, tiffany lin wrote:
>>> +static int fops_vcodec_open(struct file *file)
>>> +{
>>> +   struct video_device *vfd = video_devdata(file);
>>> +   struct mtk_vcodec_dev *dev = video_drvdata(file);
>>> +   struct mtk_vcodec_ctx *ctx = NULL;
>>> +   int ret = 0;
>>> +
>>> +   mutex_lock(>dev_mutex);
>>> +
>>> +   ctx = devm_kzalloc(>plat_dev->dev, sizeof(*ctx), GFP_KERNEL);
>>> +   if (!ctx) {
>>> +   ret = -ENOMEM;
>>> +   goto err_alloc;
>>> +   }
>>> +
>>> +   if (dev->num_instances >= MTK_VCODEC_MAX_ENCODER_INSTANCES) {
>>> +   mtk_v4l2_err("Too many open contexts\n");
>>> +   ret = -EBUSY;
>>> +   goto err_no_ctx;
>>
>> Hmm. I never like it if you can't open a video node because of a reason like 
>> this.
>>
>> I.e. a simple 'v4l2-ctl -D' (i.e. calling QUERYCAP) should never fail.
>>
>> If there are hardware limitation that prevent more than X instances from 
>> running at
>> the same time, then those limitations typically kick in when you start to 
>> stream
>> (or possibly when calling REQBUFS). But before that it should always be 
>> possible to
>> open the device.
>>
>> Having this check at open() is an indication of a poor design.
>>
>> Is this is a hardware limitation at all?
>>
> This is to make sure performance meet requirements, such as bitrate and
> framerate.

Is it the driver's job to make enforce this? What if the application only
deals with low-res video, but wants to encode a lot of those? Or is encoding
a video off-line?

The driver generally doesn't know the use-case, so if this is an artificial
limitation as opposed to a hardware limitation, then I would just drop this.

Regards,

Hans

> We got your point. We will remove this and move limitation control to
> start_streaming or REQBUFS.
> Appreciated for your suggestion.:)
> 
> 
>>> +   }

Re: [PATCH v2 4/5] irqchip:create irq domain for each mbigen device

[Marc Zyngier]

On Wed, 17 Feb 2016 12:18:52 +0800
"majun (F)"  wrote:

> 
> 
> 在 2016/2/16 16:50, Marc Zyngier 写道:
> > On Tue, 16 Feb 2016 14:37:27 +0800
> > MaJun  wrote:
> > 
> >> From: Ma Jun 
> [...]
> >> +  unsigned int nid;
> >> +
> >> +  nid = get_mbigen_nid(hwirq);
> >> +
> >> +  if (nid < 4)
> >> +  return (nid * 4) + REG_MBIGEN_VEC_OFFSET;
> >> +  else
> >> +  return (nid - 4) * 4 + REG_MBIGEN_EXT_VEC_OFFSET;
> >> +}
> >> +
> >> +static struct irq_chip mbigen_irq_chip = {
> >> +  .name = "mbigen-v1",
> >> +};
> >> +
> >> +static void mbigen_write_msg(struct msi_desc *desc, struct msi_msg *msg)
> >> +{
> >> +  /* The address of doorbell is encoded in mbigen register by default
> >> +   * So,we don't need to program the doorbell address at here
> >> +   * Besides, the event ID is decided by the hardware pin number,
> >> +   * we can't change it in software.So, we don't need to encode the
> >> +   * event ID in mbigen register.
> >> +   */
> > 
> > Really? What if tomorrow I decide to change the EventID allocation
> > policy in the ITS driver? Have your HW engineers really baked the
> > behaviour of the Linux driver into the device?
> > 
> 
> Yes.
> If we really need to support this chip,is there
> any possible solution for this problem?

You would have to provide some sort of lookup table from the
device-tree, or find a way to pass this information down the ITS code.

The real question is: do we take this as it is and fix it once it
breaks? or do we mandate a proper solution before this has a remote
chance of getting in?

At the moment, I don't know, because the idea of hardcoded MSIs is so
wrong and so against the way the whole stack works that I just want to
say no to this and run away.

I need to think.

M.
-- 
Jazz is not dead. It just smells funny.

Re: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver

[Hans Verkuil]

On 02/16/2016 07:37 AM, tiffany lin wrote:
>>> +static int fops_vcodec_open(struct file *file)
>>> +{
>>> +   struct video_device *vfd = video_devdata(file);
>>> +   struct mtk_vcodec_dev *dev = video_drvdata(file);
>>> +   struct mtk_vcodec_ctx *ctx = NULL;
>>> +   int ret = 0;
>>> +
>>> +   mutex_lock(>dev_mutex);
>>> +
>>> +   ctx = devm_kzalloc(>plat_dev->dev, sizeof(*ctx), GFP_KERNEL);
>>> +   if (!ctx) {
>>> +   ret = -ENOMEM;
>>> +   goto err_alloc;
>>> +   }
>>> +
>>> +   if (dev->num_instances >= MTK_VCODEC_MAX_ENCODER_INSTANCES) {
>>> +   mtk_v4l2_err("Too many open contexts\n");
>>> +   ret = -EBUSY;
>>> +   goto err_no_ctx;
>>
>> Hmm. I never like it if you can't open a video node because of a reason like 
>> this.
>>
>> I.e. a simple 'v4l2-ctl -D' (i.e. calling QUERYCAP) should never fail.
>>
>> If there are hardware limitation that prevent more than X instances from 
>> running at
>> the same time, then those limitations typically kick in when you start to 
>> stream
>> (or possibly when calling REQBUFS). But before that it should always be 
>> possible to
>> open the device.
>>
>> Having this check at open() is an indication of a poor design.
>>
>> Is this is a hardware limitation at all?
>>
> This is to make sure performance meet requirements, such as bitrate and
> framerate.

Is it the driver's job to make enforce this? What if the application only
deals with low-res video, but wants to encode a lot of those? Or is encoding
a video off-line?

The driver generally doesn't know the use-case, so if this is an artificial
limitation as opposed to a hardware limitation, then I would just drop this.

Regards,

Hans

> We got your point. We will remove this and move limitation control to
> start_streaming or REQBUFS.
> Appreciated for your suggestion.:)
> 
> 
>>> +   }

Re: [PATCH v2 4/5] irqchip:create irq domain for each mbigen device

[Marc Zyngier]

On Wed, 17 Feb 2016 12:18:52 +0800
"majun (F)"  wrote:

> 
> 
> 在 2016/2/16 16:50, Marc Zyngier 写道:
> > On Tue, 16 Feb 2016 14:37:27 +0800
> > MaJun  wrote:
> > 
> >> From: Ma Jun 
> [...]
> >> +  unsigned int nid;
> >> +
> >> +  nid = get_mbigen_nid(hwirq);
> >> +
> >> +  if (nid < 4)
> >> +  return (nid * 4) + REG_MBIGEN_VEC_OFFSET;
> >> +  else
> >> +  return (nid - 4) * 4 + REG_MBIGEN_EXT_VEC_OFFSET;
> >> +}
> >> +
> >> +static struct irq_chip mbigen_irq_chip = {
> >> +  .name = "mbigen-v1",
> >> +};
> >> +
> >> +static void mbigen_write_msg(struct msi_desc *desc, struct msi_msg *msg)
> >> +{
> >> +  /* The address of doorbell is encoded in mbigen register by default
> >> +   * So,we don't need to program the doorbell address at here
> >> +   * Besides, the event ID is decided by the hardware pin number,
> >> +   * we can't change it in software.So, we don't need to encode the
> >> +   * event ID in mbigen register.
> >> +   */
> > 
> > Really? What if tomorrow I decide to change the EventID allocation
> > policy in the ITS driver? Have your HW engineers really baked the
> > behaviour of the Linux driver into the device?
> > 
> 
> Yes.
> If we really need to support this chip,is there
> any possible solution for this problem?

You would have to provide some sort of lookup table from the
device-tree, or find a way to pass this information down the ITS code.

The real question is: do we take this as it is and fix it once it
breaks? or do we mandate a proper solution before this has a remote
chance of getting in?

At the moment, I don't know, because the idea of hardcoded MSIs is so
wrong and so against the way the whole stack works that I just want to
say no to this and run away.

I need to think.

M.
-- 
Jazz is not dead. It just smells funny.

Re: [GIT PULL 00/10] perf/core improvements and fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> The following changes since commit fe7a2eaa71c55aadbf95d01d32df8dccc0db0646:
> 
>   Merge tag 'perf-core-for-mingo' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
> (2016-02-16 08:45:56 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo
> 
> for you to fetch changes up to cb110f471025f3278978aaccb18f3164ea2b8189:
> 
>   perf stat: Move noise/running printing into printout (2016-02-16 17:13:02 
> -0300)
> 
> 
> perf/core improvements and fixes:
> 
> User visible:
> 
> - Make 'perf record' collect CPU cache info in the perf.data file header:
> 
>   $ perf record usleep 1
>   [ perf record: Woken up 1 times to write data ]
>   [ perf record: Captured and wrote 0.017 MB perf.data (7 samples) ]
>   $ perf report --header-only -I | tail -10 | head -8
>   # CPU cache info:
>   #  L1 Data 32K [0-1]
>   #  L1 Instruction  32K [0-1]
>   #  L1 Data 32K [2-3]
>   #  L1 Instruction  32K [2-3]
>   #  L2 Unified 256K [0-1]
>   #  L2 Unified 256K [2-3]
>   #  L3 Unified4096K [0-3]
>   $
> 
>   Will be used in 'perf c2c' and eventually in 'perf diff' to allow, for 
> instance
>   running the same workload in multiple machines and then when using 'diff' 
> show
>   the hardware difference. (Jiri Olsa)
> 
> - 'perf stat' now shows shadow metrics (insn per cycle, etc) in
>   interval mode too. E.g:
> 
> # perf stat -I 1000 -e instructions,cycles sleep 1
> # time   counts unit events
>1.000215928  519,620  instructions #  0.69 insn per cycle
>1.000215928  752,003  cycles
> 
> 
> Infrastructure:
> 
> - libapi now can also use pr_{warning,info,debug}() and that can be
>   set by tools using it (Jiri Olsa)
> 
> - libapi adopts filename__read_str() from perf, adds sysfs__read_str() (Jiri 
> Olsa)
> 
> - Add check for java alternatives cmd in jvmti Makefile, so that it manages
>   to automatically find the right path for the JDK devel files in Ubuntu like
>   systems in addition to Fedora like ones (Stephane Eranian)
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Andi Kleen (3):
>   perf stat: Abstract stat metrics printing
>   perf stat: Add support for metrics in interval mode
>   perf stat: Move noise/running printing into printout
> 
> Arnaldo Carvalho de Melo (1):
>   perf debug: Rename __eprintf(va_list args) to veprintf
> 
> Jiri Olsa (5):
>   tools lib api: Add debug output support
>   tools lib api fs: Adopt filename__read_str from perf
>   tools lib api fs: Add sysfs__read_str function
>   perf tools: Initialize libapi debug output
>   perf tools: Add perf data cache feature
> 
> Stephane Eranian (1):
>   perf jvmti: Add check for java alternatives cmd in Makefile
> 
>  tools/lib/api/Build|   1 +
>  tools/lib/api/Makefile |   1 +
>  tools/lib/api/debug-internal.h |  20 +++
>  tools/lib/api/debug.c  |  28 +
>  tools/lib/api/debug.h  |  10 ++
>  tools/lib/api/fs/fs.c  |  64 ++
>  tools/lib/api/fs/fs.h  |   3 +
>  tools/perf/builtin-stat.c  | 202 +++---
>  tools/perf/jvmti/Makefile  |   6 +-
>  tools/perf/perf.c  |   2 +
>  tools/perf/util/debug.c|  36 --
>  tools/perf/util/debug.h|   1 +
>  tools/perf/util/env.c  |  13 ++
>  tools/perf/util/env.h  |  15 +++
>  tools/perf/util/header.c   | 270 
> +
>  tools/perf/util/header.h   |   1 +
>  tools/perf/util/stat-shadow.c  | 211 +---
>  tools/perf/util/stat.h |  15 ++-
>  tools/perf/util/trace-event.c  |   1 +
>  tools/perf/util/util.c |  48 
>  tools/perf/util/util.h |   1 -
>  21 files changed, 694 insertions(+), 255 deletions(-)
>  create mode 100644 tools/lib/api/debug-internal.h
>  create mode 100644 tools/lib/api/debug.c
>  create mode 100644 tools/lib/api/debug.h

Pulled, thanks a lot Arnaldo!

Ingo

Re: [GIT PULL 00/10] perf/core improvements and fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> The following changes since commit fe7a2eaa71c55aadbf95d01d32df8dccc0db0646:
> 
>   Merge tag 'perf-core-for-mingo' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
> (2016-02-16 08:45:56 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo
> 
> for you to fetch changes up to cb110f471025f3278978aaccb18f3164ea2b8189:
> 
>   perf stat: Move noise/running printing into printout (2016-02-16 17:13:02 
> -0300)
> 
> 
> perf/core improvements and fixes:
> 
> User visible:
> 
> - Make 'perf record' collect CPU cache info in the perf.data file header:
> 
>   $ perf record usleep 1
>   [ perf record: Woken up 1 times to write data ]
>   [ perf record: Captured and wrote 0.017 MB perf.data (7 samples) ]
>   $ perf report --header-only -I | tail -10 | head -8
>   # CPU cache info:
>   #  L1 Data 32K [0-1]
>   #  L1 Instruction  32K [0-1]
>   #  L1 Data 32K [2-3]
>   #  L1 Instruction  32K [2-3]
>   #  L2 Unified 256K [0-1]
>   #  L2 Unified 256K [2-3]
>   #  L3 Unified4096K [0-3]
>   $
> 
>   Will be used in 'perf c2c' and eventually in 'perf diff' to allow, for 
> instance
>   running the same workload in multiple machines and then when using 'diff' 
> show
>   the hardware difference. (Jiri Olsa)
> 
> - 'perf stat' now shows shadow metrics (insn per cycle, etc) in
>   interval mode too. E.g:
> 
> # perf stat -I 1000 -e instructions,cycles sleep 1
> # time   counts unit events
>1.000215928  519,620  instructions #  0.69 insn per cycle
>1.000215928  752,003  cycles
> 
> 
> Infrastructure:
> 
> - libapi now can also use pr_{warning,info,debug}() and that can be
>   set by tools using it (Jiri Olsa)
> 
> - libapi adopts filename__read_str() from perf, adds sysfs__read_str() (Jiri 
> Olsa)
> 
> - Add check for java alternatives cmd in jvmti Makefile, so that it manages
>   to automatically find the right path for the JDK devel files in Ubuntu like
>   systems in addition to Fedora like ones (Stephane Eranian)
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Andi Kleen (3):
>   perf stat: Abstract stat metrics printing
>   perf stat: Add support for metrics in interval mode
>   perf stat: Move noise/running printing into printout
> 
> Arnaldo Carvalho de Melo (1):
>   perf debug: Rename __eprintf(va_list args) to veprintf
> 
> Jiri Olsa (5):
>   tools lib api: Add debug output support
>   tools lib api fs: Adopt filename__read_str from perf
>   tools lib api fs: Add sysfs__read_str function
>   perf tools: Initialize libapi debug output
>   perf tools: Add perf data cache feature
> 
> Stephane Eranian (1):
>   perf jvmti: Add check for java alternatives cmd in Makefile
> 
>  tools/lib/api/Build|   1 +
>  tools/lib/api/Makefile |   1 +
>  tools/lib/api/debug-internal.h |  20 +++
>  tools/lib/api/debug.c  |  28 +
>  tools/lib/api/debug.h  |  10 ++
>  tools/lib/api/fs/fs.c  |  64 ++
>  tools/lib/api/fs/fs.h  |   3 +
>  tools/perf/builtin-stat.c  | 202 +++---
>  tools/perf/jvmti/Makefile  |   6 +-
>  tools/perf/perf.c  |   2 +
>  tools/perf/util/debug.c|  36 --
>  tools/perf/util/debug.h|   1 +
>  tools/perf/util/env.c  |  13 ++
>  tools/perf/util/env.h  |  15 +++
>  tools/perf/util/header.c   | 270 
> +
>  tools/perf/util/header.h   |   1 +
>  tools/perf/util/stat-shadow.c  | 211 +---
>  tools/perf/util/stat.h |  15 ++-
>  tools/perf/util/trace-event.c  |   1 +
>  tools/perf/util/util.c |  48 
>  tools/perf/util/util.h |   1 -
>  21 files changed, 694 insertions(+), 255 deletions(-)
>  create mode 100644 tools/lib/api/debug-internal.h
>  create mode 100644 tools/lib/api/debug.c
>  create mode 100644 tools/lib/api/debug.h

Pulled, thanks a lot Arnaldo!

Ingo

[PATCH v1] GPIO/ACPI: DesignWare: Add GPIO-signaled ACPI events support for power button

[qiujiang]

This patch modifies the DesignWare GPIO controller driver to
support the GPIO-signaled ACPI Events. This is used for power
button function on ARM server.

To make it work, the _AEI and _EVT object must be defined in
the corresponding GPIO driver's dsdt table in UEFI as follow:

Device(GPI0) {
Name(_HID, "HISI0181")
Name(_ADR, 0) // _ADR: Address
Name(_UID, 0)

Name (_CRS, ResourceTemplate ()  {
Memory32Fixed (ReadWrite, 0x802e, 0x1)
Interrupt (ResourceConsumer, Level, ActiveHigh,
Exclusive,,,) {344}
})

Device(PRTa) {
Name (_DSD, Package () {
Package () {
Package () {"reg",0},
Package () {"snps,nr-gpios",32},
}
})
}

Name (_AEI, ResourceTemplate () {
GpioInt(Edge, ActiveLow, ExclusiveAndWake, PullUp, ,
" \\_SB.GPI0") {8}
})

Method (_E08, 0x0, NotSerialized) {
Notify (\_SB.PWRB, 0x80)
}
}

Signed-off-by: qiujiang 
---
 drivers/gpio/gpio-dwapb.c| 71 
 include/linux/platform_data/gpio-dwapb.h |  2 +-
 2 files changed, 45 insertions(+), 28 deletions(-)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index fcd5b0a..e482e32 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -7,6 +7,7 @@
  *
  * All enquiries to supp...@picochip.com
  */
+#include 
 #include 
 #include 
 #include 
@@ -24,6 +25,8 @@
 #include 
 #include 
 
+#include "gpiolib.h"
+
 #define GPIO_SWPORTA_DR0x00
 #define GPIO_SWPORTA_DDR   0x04
 #define GPIO_SWPORTB_DR0x0c
@@ -296,14 +299,14 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
 struct dwapb_port_property *pp)
 {
struct gpio_chip *gc = >bgc.gc;
-   struct device_node *node = pp->node;
+   struct fwnode_handle  *fwnode = pp->fwnode;
struct irq_chip_generic *irq_gc = NULL;
unsigned int hwirq, ngpio = gc->ngpio;
struct irq_chip_type *ct;
int err, i;
 
-   gpio->domain = irq_domain_add_linear(node, ngpio,
-_generic_chip_ops, gpio);
+   gpio->domain = irq_domain_create_linear(fwnode,
+   ngpio, _generic_chip_ops, gpio);
if (!gpio->domain)
return;
 
@@ -421,7 +424,7 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
}
 
 #ifdef CONFIG_OF_GPIO
-   port->bgc.gc.of_node = pp->node;
+   port->bgc.gc.of_node = to_of_node(pp->fwnode);
 #endif
port->bgc.gc.ngpio = pp->ngpio;
port->bgc.gc.base = pp->gpio_base;
@@ -440,6 +443,10 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
else
port->is_registered = true;
 
+   /* Add GPIO-signaled ACPI event support */
+   if (pp->irq)
+   acpi_gpiochip_request_interrupts(&(port->bgc.gc));
+
return err;
 }
 
@@ -453,19 +460,15 @@ static void dwapb_gpio_unregister(struct dwapb_gpio *gpio)
 }
 
 static struct dwapb_platform_data *
-dwapb_gpio_get_pdata_of(struct device *dev)
+dwapb_gpio_get_pdata(struct device *dev)
 {
-   struct device_node *node, *port_np;
+   struct fwnode_handle *fwnode;
struct dwapb_platform_data *pdata;
struct dwapb_port_property *pp;
int nports;
int i;
 
-   node = dev->of_node;
-   if (!IS_ENABLED(CONFIG_OF_GPIO) || !node)
-   return ERR_PTR(-ENODEV);
-
-   nports = of_get_child_count(node);
+   nports = device_get_child_node_count(dev);
if (nports == 0)
return ERR_PTR(-ENODEV);
 
@@ -480,21 +483,19 @@ dwapb_gpio_get_pdata_of(struct device *dev)
pdata->nports = nports;
 
i = 0;
-   for_each_child_of_node(node, port_np) {
-   pp = >properties[i++];
-   pp->node = port_np;
+   device_for_each_child_node(dev, fwnode) {
+   pp = >properties[i];
+   pp->fwnode = fwnode;
 
-   if (of_property_read_u32(port_np, "reg", >idx) ||
+   if (fwnode_property_read_u32(fwnode, "reg", >idx) ||
pp->idx >= DWAPB_MAX_PORTS) {
-   dev_err(dev, "missing/invalid port index for %s\n",
-   port_np->full_name);
+   dev_err(dev, "missing/invalid port index\n");
return ERR_PTR(-EINVAL);
}
 
-   if (of_property_read_u32(port_np, "snps,nr-gpios",
+   if (fwnode_property_read_u32(fwnode, "snps,nr-gpios",
 >ngpio)) {
-   dev_info(dev, "failed to get number of gpios for %s\n",
-

[PATCH v1] GPIO/ACPI: DesignWare: Add GPIO-signaled ACPI events support for power button

[qiujiang]

This patch modifies the DesignWare GPIO controller driver to
support the GPIO-signaled ACPI Events. This is used for power
button function on ARM server.

To make it work, the _AEI and _EVT object must be defined in
the corresponding GPIO driver's dsdt table in UEFI as follow:

Device(GPI0) {
Name(_HID, "HISI0181")
Name(_ADR, 0) // _ADR: Address
Name(_UID, 0)

Name (_CRS, ResourceTemplate ()  {
Memory32Fixed (ReadWrite, 0x802e, 0x1)
Interrupt (ResourceConsumer, Level, ActiveHigh,
Exclusive,,,) {344}
})

Device(PRTa) {
Name (_DSD, Package () {
Package () {
Package () {"reg",0},
Package () {"snps,nr-gpios",32},
}
})
}

Name (_AEI, ResourceTemplate () {
GpioInt(Edge, ActiveLow, ExclusiveAndWake, PullUp, ,
" \\_SB.GPI0") {8}
})

Method (_E08, 0x0, NotSerialized) {
Notify (\_SB.PWRB, 0x80)
}
}

Signed-off-by: qiujiang 
---
 drivers/gpio/gpio-dwapb.c| 71 
 include/linux/platform_data/gpio-dwapb.h |  2 +-
 2 files changed, 45 insertions(+), 28 deletions(-)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index fcd5b0a..e482e32 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -7,6 +7,7 @@
  *
  * All enquiries to supp...@picochip.com
  */
+#include 
 #include 
 #include 
 #include 
@@ -24,6 +25,8 @@
 #include 
 #include 
 
+#include "gpiolib.h"
+
 #define GPIO_SWPORTA_DR0x00
 #define GPIO_SWPORTA_DDR   0x04
 #define GPIO_SWPORTB_DR0x0c
@@ -296,14 +299,14 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
 struct dwapb_port_property *pp)
 {
struct gpio_chip *gc = >bgc.gc;
-   struct device_node *node = pp->node;
+   struct fwnode_handle  *fwnode = pp->fwnode;
struct irq_chip_generic *irq_gc = NULL;
unsigned int hwirq, ngpio = gc->ngpio;
struct irq_chip_type *ct;
int err, i;
 
-   gpio->domain = irq_domain_add_linear(node, ngpio,
-_generic_chip_ops, gpio);
+   gpio->domain = irq_domain_create_linear(fwnode,
+   ngpio, _generic_chip_ops, gpio);
if (!gpio->domain)
return;
 
@@ -421,7 +424,7 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
}
 
 #ifdef CONFIG_OF_GPIO
-   port->bgc.gc.of_node = pp->node;
+   port->bgc.gc.of_node = to_of_node(pp->fwnode);
 #endif
port->bgc.gc.ngpio = pp->ngpio;
port->bgc.gc.base = pp->gpio_base;
@@ -440,6 +443,10 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
else
port->is_registered = true;
 
+   /* Add GPIO-signaled ACPI event support */
+   if (pp->irq)
+   acpi_gpiochip_request_interrupts(&(port->bgc.gc));
+
return err;
 }
 
@@ -453,19 +460,15 @@ static void dwapb_gpio_unregister(struct dwapb_gpio *gpio)
 }
 
 static struct dwapb_platform_data *
-dwapb_gpio_get_pdata_of(struct device *dev)
+dwapb_gpio_get_pdata(struct device *dev)
 {
-   struct device_node *node, *port_np;
+   struct fwnode_handle *fwnode;
struct dwapb_platform_data *pdata;
struct dwapb_port_property *pp;
int nports;
int i;
 
-   node = dev->of_node;
-   if (!IS_ENABLED(CONFIG_OF_GPIO) || !node)
-   return ERR_PTR(-ENODEV);
-
-   nports = of_get_child_count(node);
+   nports = device_get_child_node_count(dev);
if (nports == 0)
return ERR_PTR(-ENODEV);
 
@@ -480,21 +483,19 @@ dwapb_gpio_get_pdata_of(struct device *dev)
pdata->nports = nports;
 
i = 0;
-   for_each_child_of_node(node, port_np) {
-   pp = >properties[i++];
-   pp->node = port_np;
+   device_for_each_child_node(dev, fwnode) {
+   pp = >properties[i];
+   pp->fwnode = fwnode;
 
-   if (of_property_read_u32(port_np, "reg", >idx) ||
+   if (fwnode_property_read_u32(fwnode, "reg", >idx) ||
pp->idx >= DWAPB_MAX_PORTS) {
-   dev_err(dev, "missing/invalid port index for %s\n",
-   port_np->full_name);
+   dev_err(dev, "missing/invalid port index\n");
return ERR_PTR(-EINVAL);
}
 
-   if (of_property_read_u32(port_np, "snps,nr-gpios",
+   if (fwnode_property_read_u32(fwnode, "snps,nr-gpios",
 >ngpio)) {
-   dev_info(dev, "failed to get number of gpios for %s\n",
-port_np->full_name);
+  

Re: [PATCH] asus-nb-wmi: add wapf=4 quirk for ASUS X75VD

[Darren Hart]

On Fri, Feb 12, 2016 at 03:35:21PM +0200, Oleksandr Natalenko wrote:
> Wi-Fi on ASUS X75VD laptop does not work unless asus_nb_wmi module
> is loaded with wapf=4 option. Add quirk for this.

Concept is fine, checkpatch complains bitterly about whitespace. Please ensure
you are not adding spaces at the beginning of lines in your editor or in your
patch submission process.

> 
> ---
>  drivers/platform/x86/asus-nb-wmi.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/platform/x86/asus-nb-wmi.c
> b/drivers/platform/x86/asus-nb-wmi.c
> index 131fee2..091ca7a 100644
> --- a/drivers/platform/x86/asus-nb-wmi.c
> +++ b/drivers/platform/x86/asus-nb-wmi.c
> @@ -272,6 +272,15 @@ static const struct dmi_system_id asus_quirks[] = {
> },
> {
> .callback = dmi_matched,
> +   .ident = "ASUSTeK COMPUTER INC. X75VD",
> +   .matches = {
> +   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> +   DMI_MATCH(DMI_PRODUCT_NAME, "X75VD"),
> +   },
> +   .driver_data = _asus_wapf4,
> +   },
> +   {
> +   .callback = dmi_matched,
> .ident = "ASUSTeK COMPUTER INC. 1015E",
> .matches = {
> DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> -- 
> 2.7.1
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH] asus-nb-wmi: add wapf=4 quirk for ASUS X75VD

[Darren Hart]

On Fri, Feb 12, 2016 at 03:35:21PM +0200, Oleksandr Natalenko wrote:
> Wi-Fi on ASUS X75VD laptop does not work unless asus_nb_wmi module
> is loaded with wapf=4 option. Add quirk for this.

Concept is fine, checkpatch complains bitterly about whitespace. Please ensure
you are not adding spaces at the beginning of lines in your editor or in your
patch submission process.

> 
> ---
>  drivers/platform/x86/asus-nb-wmi.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/platform/x86/asus-nb-wmi.c
> b/drivers/platform/x86/asus-nb-wmi.c
> index 131fee2..091ca7a 100644
> --- a/drivers/platform/x86/asus-nb-wmi.c
> +++ b/drivers/platform/x86/asus-nb-wmi.c
> @@ -272,6 +272,15 @@ static const struct dmi_system_id asus_quirks[] = {
> },
> {
> .callback = dmi_matched,
> +   .ident = "ASUSTeK COMPUTER INC. X75VD",
> +   .matches = {
> +   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> +   DMI_MATCH(DMI_PRODUCT_NAME, "X75VD"),
> +   },
> +   .driver_data = _asus_wapf4,
> +   },
> +   {
> +   .callback = dmi_matched,
> .ident = "ASUSTeK COMPUTER INC. 1015E",
> .matches = {
> DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> -- 
> 2.7.1
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator

[Ivaylo Dimitrov]

Hi,

On 16.02.2016 15:51, Tomi Valkeinen wrote:


Does it work for you? I haven't used DT reserved-memory, do you have an
example .dts change?



Yes, it does work, I tested it on n900:

diff --git a/arch/arm/boot/dts/omap3-n900.dts 
b/arch/arm/boot/dts/omap3-n900.dts

index 1e94237..863d547 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -59,6 +59,18 @@
reg = <0x8000 0x1000>; /* 256 MB */
};

+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   omapfb_reserved: omapfb {
+   size = <0x70>;
+   alignment = <0x10>;
+   compatible = "ti,omapfb-memsize";
+   };
+   };
+
gpio_keys {
compatible = "gpio-keys";

@@ -1083,6 +1095,8 @@

vdds_sdi-supply = <>;

+   memory-region = <_reserved>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;


Now, having to support DT bindings is not any better than supporting
cmdline options. But with a quick read of reserved-memory.txt I like the
idea. However we should have "reserved memory for display", not for
omapfb, so that the same reserved area could be used by omapdrm too.


Sounds reasonable and I don't really care how it is to be called or who 
does the actual reservation, as long as there is some reserved memory we 
can use for omapfb :)


Keep in mind that the changes I did were just a quick-n-dirty hack to 
see if it will work and if you will accept something like that. A better 
approach is maybe to move RESERVEDMEM_OF_DECLARE() and co to display.c 
and pass base and size to whoever needs them (be it omapfb or omapdrm). 
Also, compatible could be called "ti,dss-memsize" or the like, but those 
are cosmetics IMO.




Another thing, with v4.5, omapfb has moved into maintenance mode. I
don't want to merge new features there. Are you planning to move to
omapdrm, and if not, why? I'd rather see all this done for omapdrm only.


I don't see a reason to not merge a small change like that in omapfb if 
there is reserved display memory used by omapdrm, but still, I am not 
the maintainer.


Pali already explained the situation with PVR driver we use to boot 
maemo UI. Honestly, I have no idea what it takes to move from omapfb to 
omapdrm. Any hints?


Ivo

Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator

[Ivaylo Dimitrov]

Hi,

On 16.02.2016 15:51, Tomi Valkeinen wrote:


Does it work for you? I haven't used DT reserved-memory, do you have an
example .dts change?



Yes, it does work, I tested it on n900:

diff --git a/arch/arm/boot/dts/omap3-n900.dts 
b/arch/arm/boot/dts/omap3-n900.dts

index 1e94237..863d547 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -59,6 +59,18 @@
reg = <0x8000 0x1000>; /* 256 MB */
};

+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   omapfb_reserved: omapfb {
+   size = <0x70>;
+   alignment = <0x10>;
+   compatible = "ti,omapfb-memsize";
+   };
+   };
+
gpio_keys {
compatible = "gpio-keys";

@@ -1083,6 +1095,8 @@

vdds_sdi-supply = <>;

+   memory-region = <_reserved>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;


Now, having to support DT bindings is not any better than supporting
cmdline options. But with a quick read of reserved-memory.txt I like the
idea. However we should have "reserved memory for display", not for
omapfb, so that the same reserved area could be used by omapdrm too.


Sounds reasonable and I don't really care how it is to be called or who 
does the actual reservation, as long as there is some reserved memory we 
can use for omapfb :)


Keep in mind that the changes I did were just a quick-n-dirty hack to 
see if it will work and if you will accept something like that. A better 
approach is maybe to move RESERVEDMEM_OF_DECLARE() and co to display.c 
and pass base and size to whoever needs them (be it omapfb or omapdrm). 
Also, compatible could be called "ti,dss-memsize" or the like, but those 
are cosmetics IMO.




Another thing, with v4.5, omapfb has moved into maintenance mode. I
don't want to merge new features there. Are you planning to move to
omapdrm, and if not, why? I'd rather see all this done for omapdrm only.


I don't see a reason to not merge a small change like that in omapfb if 
there is reserved display memory used by omapdrm, but still, I am not 
the maintainer.


Pali already explained the situation with PVR driver we use to boot 
maemo UI. Honestly, I have no idea what it takes to move from omapfb to 
omapdrm. Any hints?


Ivo

Re: [PATCH] drivers/platform: make x86/intel_scu_ipc.c explicitly non-modular

[Darren Hart]

On Sun, Feb 14, 2016 at 03:00:52PM -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
> 
> drivers/platform/x86/Kconfig:config INTEL_SCU_IPC
> drivers/platform/x86/Kconfig:   bool "Intel SCU IPC Support"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> Lets remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.
> 
> We explicitly disallow a driver unbind, since that doesn't have a
> sensible use case anyway, and it allows us to drop the ".remove"
> code for non-modular drivers.
> 
> Since module_pci_driver() uses the same init level priority as
> builtin_pci_driver() the init ordering remains unchanged with
> this commit.
> 
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> 
> We don't replace module.h with init.h since the file already has that.
> 
> We also delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.

Alan, Sreedhara, any objection to Paul's changes?

This appears to have been introduced as bool in the original commit.

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH] drivers/platform: make x86/intel_scu_ipc.c explicitly non-modular

[Darren Hart]

On Sun, Feb 14, 2016 at 03:00:52PM -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
> 
> drivers/platform/x86/Kconfig:config INTEL_SCU_IPC
> drivers/platform/x86/Kconfig:   bool "Intel SCU IPC Support"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> Lets remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.
> 
> We explicitly disallow a driver unbind, since that doesn't have a
> sensible use case anyway, and it allows us to drop the ".remove"
> code for non-modular drivers.
> 
> Since module_pci_driver() uses the same init level priority as
> builtin_pci_driver() the init ordering remains unchanged with
> this commit.
> 
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> 
> We don't replace module.h with init.h since the file already has that.
> 
> We also delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.

Alan, Sreedhara, any objection to Paul's changes?

This appears to have been introduced as bool in the original commit.

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH 4/6] pinctrl: rockchip: add bindings for rk3399 pinctrl

[Jianqun Xu]

在 17/02/2016 14:47, Heiko Stuebner 写道:

Hi Jianqun,

Am Mittwoch, 17. Februar 2016, 09:53:10 schrieb jianqun.xu:

From: Xu Jianqun 

Add devicetree bindings for pinctrl found on rk3399
processors from rockchip.

Signed-off-by: Xu Jianqun 
---
  Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git
a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index
0cd701b..c68b955 100644
--- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
@@ -22,7 +22,7 @@ Required properties for iomux controller:
- compatible: one of "rockchip,rk2928-pinctrl",
"rockchip,rk3066a-pinctrl" "rockchip,rk3066b-pinctrl",
"rockchip,rk3188-pinctrl"
   "rockchip,rk3228-pinctrl", "rockchip,rk3288-pinctrl"
-  "rockchip,rk3368-pinctrl"
+  "rockchip,rk3368-pinctrl", "rockchip,rk3399-pinctrl"
- rockchip,grf: phandle referencing a syscon providing the
 "general register files"


that is already contained in David's core pinctrl patch that already got
applied to the pinctrl tree.


Sorry very much, I forgot it after a long time of spring holiday
thanks


Heiko

Re: [PATCH 4/6] pinctrl: rockchip: add bindings for rk3399 pinctrl

[Jianqun Xu]

在 17/02/2016 14:47, Heiko Stuebner 写道:

Hi Jianqun,

Am Mittwoch, 17. Februar 2016, 09:53:10 schrieb jianqun.xu:

From: Xu Jianqun 

Add devicetree bindings for pinctrl found on rk3399
processors from rockchip.

Signed-off-by: Xu Jianqun 
---
  Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git
a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index
0cd701b..c68b955 100644
--- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
@@ -22,7 +22,7 @@ Required properties for iomux controller:
- compatible: one of "rockchip,rk2928-pinctrl",
"rockchip,rk3066a-pinctrl" "rockchip,rk3066b-pinctrl",
"rockchip,rk3188-pinctrl"
   "rockchip,rk3228-pinctrl", "rockchip,rk3288-pinctrl"
-  "rockchip,rk3368-pinctrl"
+  "rockchip,rk3368-pinctrl", "rockchip,rk3399-pinctrl"
- rockchip,grf: phandle referencing a syscon providing the
 "general register files"


that is already contained in David's core pinctrl patch that already got
applied to the pinctrl tree.


Sorry very much, I forgot it after a long time of spring holiday
thanks


Heiko

Re: [PATCH v5 1/4] x86/signal/64: Add a comment about sigcontext->fs and gs

[Ingo Molnar]

* Andy Lutomirski  wrote:

> +  * If the kernel ever adds explicit fs, gs, fsbase, and gsbase
> +  * save/restore, it will most likely need to be opt-in and use
> +  * different context slots.

Btw., that's not necessarily true: it could also be made opt-out, and a 
modify_ldt() or any other cleanly identifiable legacy usage/signature that is 
associated with DOSEMU might trigger the opt-out automatically as well.

I.e. behaviorally it would still keep the ABI and modern default behavior could 
still be whatever we want to make it.

Thanks,

Ingo

Re: [PATCH v5 1/4] x86/signal/64: Add a comment about sigcontext->fs and gs

[Ingo Molnar]

* Andy Lutomirski  wrote:

> +  * If the kernel ever adds explicit fs, gs, fsbase, and gsbase
> +  * save/restore, it will most likely need to be opt-in and use
> +  * different context slots.

Btw., that's not necessarily true: it could also be made opt-out, and a 
modify_ldt() or any other cleanly identifiable legacy usage/signature that is 
associated with DOSEMU might trigger the opt-out automatically as well.

I.e. behaviorally it would still keep the ABI and modern default behavior could 
still be whatever we want to make it.

Thanks,

Ingo

Re: [PATCH] kernel/hung_task.c: printk address for hung_task

[Kassey]

Ingo, Mandeep:
 can you review this patch ?
BR
Kassey

On Thu, Jan 14, 2016 at 5:33 PM, Kassey  wrote:
> Xinhui:
>   when I got a  DDR dump, with the task_struct address for this
> task, I can see what file this task is accessing, as well as
> task_struct member.
>   this is very useful and popular on arch where we can generate a
> DDR dump when system crash.
>
> BR
> Kassey
>
> On Thu, Jan 14, 2016 at 10:45 AM, Pan Xinhui  
> wrote:
>> hi, Li
>> I have a little confusion. for what you want to know this ptr's 
>> value. Can that help you debug or root the cause?
>> I'm just wondering :)
>>
>> thanks
>> xinhui
>>
>> On 2016年01月13日 10:42, Li wrote:
>>> From: Kassey Li 
>>>
>>> this is used to check task_struct info when got a dump.
>>>
>>> Signed-off-by: Kassey Li 
>>> ---
>>>  kernel/hung_task.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
>>> index d234022..b5dd7dd 100644
>>> --- a/kernel/hung_task.c
>>> +++ b/kernel/hung_task.c
>>> @@ -108,8 +108,8 @@ static void check_hung_task(struct task_struct *t, 
>>> unsigned long timeout)
>>>* Ok, the task did not get scheduled for more than 2 minutes,
>>>* complain:
>>>*/
>>> - pr_err("INFO: task %s:%d blocked for more than %ld seconds.\n",
>>> - t->comm, t->pid, timeout);
>>> + pr_err("INFO: task %s:%d 0x%p blocked for more than %ld seconds.\n",
>>> + t->comm, t->pid, t, timeout);
>>>   pr_err("  %s %s %.*s\n",
>>>   print_tainted(), init_utsname()->release,
>>>   (int)strcspn(init_utsname()->version, " "),
>>>
>>
>
>
>
> --
> Best regards
> Kassey



-- 
Best regards
Kassey

Re: [PATCH] kernel/hung_task.c: printk address for hung_task

[Kassey]

Ingo, Mandeep:
 can you review this patch ?
BR
Kassey

On Thu, Jan 14, 2016 at 5:33 PM, Kassey  wrote:
> Xinhui:
>   when I got a  DDR dump, with the task_struct address for this
> task, I can see what file this task is accessing, as well as
> task_struct member.
>   this is very useful and popular on arch where we can generate a
> DDR dump when system crash.
>
> BR
> Kassey
>
> On Thu, Jan 14, 2016 at 10:45 AM, Pan Xinhui  
> wrote:
>> hi, Li
>> I have a little confusion. for what you want to know this ptr's 
>> value. Can that help you debug or root the cause?
>> I'm just wondering :)
>>
>> thanks
>> xinhui
>>
>> On 2016年01月13日 10:42, Li wrote:
>>> From: Kassey Li 
>>>
>>> this is used to check task_struct info when got a dump.
>>>
>>> Signed-off-by: Kassey Li 
>>> ---
>>>  kernel/hung_task.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
>>> index d234022..b5dd7dd 100644
>>> --- a/kernel/hung_task.c
>>> +++ b/kernel/hung_task.c
>>> @@ -108,8 +108,8 @@ static void check_hung_task(struct task_struct *t, 
>>> unsigned long timeout)
>>>* Ok, the task did not get scheduled for more than 2 minutes,
>>>* complain:
>>>*/
>>> - pr_err("INFO: task %s:%d blocked for more than %ld seconds.\n",
>>> - t->comm, t->pid, timeout);
>>> + pr_err("INFO: task %s:%d 0x%p blocked for more than %ld seconds.\n",
>>> + t->comm, t->pid, t, timeout);
>>>   pr_err("  %s %s %.*s\n",
>>>   print_tainted(), init_utsname()->release,
>>>   (int)strcspn(init_utsname()->version, " "),
>>>
>>
>
>
>
> --
> Best regards
> Kassey



-- 
Best regards
Kassey

Re: [PATCH 1/2] ideapad: No hardware switch after 2016

[Darren Hart]

On Tue, Feb 16, 2016 at 10:04:02AM +0800, Ike Panhc wrote:
> On 02/16/2016 01:32 AM, Bjørn Mork wrote:
> > Ike Panhc  writes:
> >> On 02/15/2016 08:08 PM, Bjørn Mork wrote:
> >>> Ike Panhc  writes:
> >>>
>  There are complains on few ideapads that wireless is always hard
>  blocked but there is no physical radio switch. For now, we need
>  each user to report its dmi information and ignore hard blocks
>  on their ideapad. With more and more ideapads available in market
>  to maintain the dmi table becomes never-ended job.
> 
>  I've checked lenovo website and for recent design none of the
>  ideapads has radio switch. I do not believe there will be in the
>  future. Therefore to disable hard block according to BIOS date is
>  reasonable approach.
> 
>  This patch will disable rfkill hardblock if BIOS year > 2015.
> >>>
> >>> Huh?  And what happens when a user upgrades the BIOS on older hardware?
> >>>
> >>
> >> That's why I believe > 2015 is a better choice, not > 2014.
> >>
> >> Ideapads in market now carries BIOS year 2015 and I found no radio switch
> >> on them. And I don't believe anyone will receive or upgrade BIOS for more
> >> then 1y old machine. In fact I haven't heard anyone upgrading BIOS for a
> >> long time.
> > 
> > Now I don't know this platform, but that assumption seems terribly
> > fragile to me.
> 
> Maybe I do not say why I propose this patch clearly. User can not use
> wireless with network manager if hardblock reports yes faultily. For
> now, more then half of ideapad models has no ethernet port and even
> with ethernet, user will only find out wireless does not work. User
> without ability to blacklist ideapad_laptop will consider Linux faulty
> and choose other solution.
> 
> > 
> > Do you own a crystal ball?  Are BIOS updates for older machines so
> > unlikely that you don't even have to consider the possibility?  What
> > about a security flaw affecting the BIOS of a large number of older
> > machines?  Has that never happened?
> 
> Upgrading BIOS might brick the machine. Laptop seller likes that even
> less.

I'm going to have to concur with Bjørn Mork here. While vendors do not upgrade
their firmware as frequently as they should or as we would like, we really
should avoid penalizing them if they do choose to provide an update!

> 
> > 
> > Sorry, but I don't think it's very nice to owners of older ideapads to
> > just let their rfkill devices disappear silently if they ever upgrade
> > their BIOS after 2015.  Yes, that may not be possible right now.  And it
> > might never become possible.  I don't know.  But what exactly is your
> > plan *if* it becomes possible?
> 
> This is very close to impossible. In this case, I can introduce a new
> dmi tables to whitelist those models.
> 

The long list DMI whitelist is particularly tedious to generate and maintain.

> > 
> > And are you sure there is no proper way to fix this issue?  I know
> > firmware engineers are evil ;) But it would be surprising if they didn't
> > put some clue about the physical switch into the BIOS tables.  I see
> > that you check flags for wlan/bt/3g existence.  Maybe there is another
> > flag indicating the switch existence? Or maybe some other acpi method?
> 
> Indeed. They are evil.
> 
> I've asked acpidump for one of the ideapads[1] and find out those flags[2]
> are from EC register[3] which is blackbox to us.
> 
> [1] https://bugs.launchpad.net/bugs/1528299
> [2] http://pastebin.ubuntu.com/15088110/
> [3] http://pastebin.ubuntu.com/15088128/
> 
> > 
> > At the very least, I am convinced there are other hardware you can
> > correlate the switch existence with.
> 
> I believe so but I do not believe they are ideapads.

I think his point is that you may be able to detect a newer ideapad by the
presence or absence of another device. Heck, CPU ID would give a reasonable idea
regarding date of manufacture if all else fails.

-- 
Darren Hart
Intel Open Source Technology Center

Re: [RRC PATCH 2/2] vfs: Use per-cpu list for superblock's inode list

[Ingo Molnar]

* Waiman Long  wrote:

> When many threads are trying to add or delete inode to or from
> a superblock's s_inodes list, spinlock contention on the list can
> become a performance bottleneck.
> 
> This patch changes the s_inodes field to become a per-cpu list with
> per-cpu spinlocks.
> 
> With an exit microbenchmark that creates a large number of threads,
> attachs many inodes to them and then exits. The runtimes of that
> microbenchmark with 1000 threads before and after the patch on a
> 4-socket Intel E7-4820 v3 system (40 cores, 80 threads) were as
> follows:
> 
>   KernelElapsed TimeSystem Time
>   -----
>   Vanilla 4.5-rc4  65.29s 82m14s
>   Patched 4.5-rc4  22.81s 23m03s
> 
> Before the patch, spinlock contention at the inode_sb_list_add()
> function at the startup phase and the inode_sb_list_del() function at
> the exit phase were about 79% and 93% of total CPU time respectively
> (as measured by perf). After the patch, the percpu_list_add()
> function consumed only about 0.04% of CPU time at startup phase. The
> percpu_list_del() function consumed about 0.4% of CPU time at exit
> phase. There were still some spinlock contention, but they happened
> elsewhere.

Pretty impressive IMHO!

Just for the record, here's your former 'batched list' number inserted into the 
above table:

   Kernel   Elapsed TimeSystem Time
   --   ---
   Vanilla  [v4.5-rc4]  65.29s  82m14s
   batched list [v4.4]  45.69s  49m44s
   percpu list  [v4.5-rc4]  22.81s  23m03s

i.e. the proper per CPU data structure and the resulting improvement in cache 
locality gave another doubling in performance.

Just out of curiosity, could you post the profile of the latest patches - is 
there 
any (bigger) SMP overhead left, or is the profile pretty flat now?

Thanks,

Ingo

Re: [PATCH 1/2] ideapad: No hardware switch after 2016

[Darren Hart]

On Tue, Feb 16, 2016 at 10:04:02AM +0800, Ike Panhc wrote:
> On 02/16/2016 01:32 AM, Bjørn Mork wrote:
> > Ike Panhc  writes:
> >> On 02/15/2016 08:08 PM, Bjørn Mork wrote:
> >>> Ike Panhc  writes:
> >>>
>  There are complains on few ideapads that wireless is always hard
>  blocked but there is no physical radio switch. For now, we need
>  each user to report its dmi information and ignore hard blocks
>  on their ideapad. With more and more ideapads available in market
>  to maintain the dmi table becomes never-ended job.
> 
>  I've checked lenovo website and for recent design none of the
>  ideapads has radio switch. I do not believe there will be in the
>  future. Therefore to disable hard block according to BIOS date is
>  reasonable approach.
> 
>  This patch will disable rfkill hardblock if BIOS year > 2015.
> >>>
> >>> Huh?  And what happens when a user upgrades the BIOS on older hardware?
> >>>
> >>
> >> That's why I believe > 2015 is a better choice, not > 2014.
> >>
> >> Ideapads in market now carries BIOS year 2015 and I found no radio switch
> >> on them. And I don't believe anyone will receive or upgrade BIOS for more
> >> then 1y old machine. In fact I haven't heard anyone upgrading BIOS for a
> >> long time.
> > 
> > Now I don't know this platform, but that assumption seems terribly
> > fragile to me.
> 
> Maybe I do not say why I propose this patch clearly. User can not use
> wireless with network manager if hardblock reports yes faultily. For
> now, more then half of ideapad models has no ethernet port and even
> with ethernet, user will only find out wireless does not work. User
> without ability to blacklist ideapad_laptop will consider Linux faulty
> and choose other solution.
> 
> > 
> > Do you own a crystal ball?  Are BIOS updates for older machines so
> > unlikely that you don't even have to consider the possibility?  What
> > about a security flaw affecting the BIOS of a large number of older
> > machines?  Has that never happened?
> 
> Upgrading BIOS might brick the machine. Laptop seller likes that even
> less.

I'm going to have to concur with Bjørn Mork here. While vendors do not upgrade
their firmware as frequently as they should or as we would like, we really
should avoid penalizing them if they do choose to provide an update!

> 
> > 
> > Sorry, but I don't think it's very nice to owners of older ideapads to
> > just let their rfkill devices disappear silently if they ever upgrade
> > their BIOS after 2015.  Yes, that may not be possible right now.  And it
> > might never become possible.  I don't know.  But what exactly is your
> > plan *if* it becomes possible?
> 
> This is very close to impossible. In this case, I can introduce a new
> dmi tables to whitelist those models.
> 

The long list DMI whitelist is particularly tedious to generate and maintain.

> > 
> > And are you sure there is no proper way to fix this issue?  I know
> > firmware engineers are evil ;) But it would be surprising if they didn't
> > put some clue about the physical switch into the BIOS tables.  I see
> > that you check flags for wlan/bt/3g existence.  Maybe there is another
> > flag indicating the switch existence? Or maybe some other acpi method?
> 
> Indeed. They are evil.
> 
> I've asked acpidump for one of the ideapads[1] and find out those flags[2]
> are from EC register[3] which is blackbox to us.
> 
> [1] https://bugs.launchpad.net/bugs/1528299
> [2] http://pastebin.ubuntu.com/15088110/
> [3] http://pastebin.ubuntu.com/15088128/
> 
> > 
> > At the very least, I am convinced there are other hardware you can
> > correlate the switch existence with.
> 
> I believe so but I do not believe they are ideapads.

I think his point is that you may be able to detect a newer ideapad by the
presence or absence of another device. Heck, CPU ID would give a reasonable idea
regarding date of manufacture if all else fails.

-- 
Darren Hart
Intel Open Source Technology Center

Re: [RRC PATCH 2/2] vfs: Use per-cpu list for superblock's inode list

[Ingo Molnar]

* Waiman Long  wrote:

> When many threads are trying to add or delete inode to or from
> a superblock's s_inodes list, spinlock contention on the list can
> become a performance bottleneck.
> 
> This patch changes the s_inodes field to become a per-cpu list with
> per-cpu spinlocks.
> 
> With an exit microbenchmark that creates a large number of threads,
> attachs many inodes to them and then exits. The runtimes of that
> microbenchmark with 1000 threads before and after the patch on a
> 4-socket Intel E7-4820 v3 system (40 cores, 80 threads) were as
> follows:
> 
>   KernelElapsed TimeSystem Time
>   -----
>   Vanilla 4.5-rc4  65.29s 82m14s
>   Patched 4.5-rc4  22.81s 23m03s
> 
> Before the patch, spinlock contention at the inode_sb_list_add()
> function at the startup phase and the inode_sb_list_del() function at
> the exit phase were about 79% and 93% of total CPU time respectively
> (as measured by perf). After the patch, the percpu_list_add()
> function consumed only about 0.04% of CPU time at startup phase. The
> percpu_list_del() function consumed about 0.4% of CPU time at exit
> phase. There were still some spinlock contention, but they happened
> elsewhere.

Pretty impressive IMHO!

Just for the record, here's your former 'batched list' number inserted into the 
above table:

   Kernel   Elapsed TimeSystem Time
   --   ---
   Vanilla  [v4.5-rc4]  65.29s  82m14s
   batched list [v4.4]  45.69s  49m44s
   percpu list  [v4.5-rc4]  22.81s  23m03s

i.e. the proper per CPU data structure and the resulting improvement in cache 
locality gave another doubling in performance.

Just out of curiosity, could you post the profile of the latest patches - is 
there 
any (bigger) SMP overhead left, or is the profile pretty flat now?

Thanks,

Ingo

Re: [PATCH] fs/pnode.c: treat zero mnt_group_id-s as unequal

[Maxim Patlasov]

On 02/16/2016 11:54 AM, Al Viro wrote:

On Tue, Feb 16, 2016 at 11:45:33AM -0800, Maxim Patlasov wrote:

propagate_one(m) calculates "type" argument for copy_tree() like this:


if (m->mnt_group_id == last_dest->mnt_group_id) {
type = CL_MAKE_SHARED;
} else {
type = CL_SLAVE;
if (IS_MNT_SHARED(m))
   type |= CL_MAKE_SHARED;
   }

The "type" argument then governs clone_mnt() behavior with respect to flags
and mnt_master of new mount. When we iterate through a slave group, it is
possible that both current "m" and "last_dest" are not shared (although,
both are slaves, i.e. have non-NULL mnt_master-s). Then the comparison
above erroneously makes new mount shared and sets its mnt_master to
last_source->mnt_master. The patch fixes the problem by handling zero
mnt_group_id-s as though they are unequal.

The similar problem exists in the implementation of "else" clause above
when we have to ascend upward in the master/slave tree by calling:


last_source = last_source->mnt_master;
last_dest = last_source->mnt_parent;

proper number of times. The last step is governed by
"n->mnt_group_id != last_dest->mnt_group_id" condition that may lie if
both are zero. The patch fixes this case in the same way as the former one.

Mind putting together a reproducer?


There are two files attached: reproducer1.c and reproducer2.c. The 
former demonstrates the problem before applying the patch. The latter 
demonstrates why the first hunk of the patch is not enough.


[root@f22ml ~]# reproducer1
main pid = 1496
monitor pid = 1497
child pid = 1498
grand-child pid = 1499

[root@f22ml ~]# grep "child" /proc/1496/mountinfo
243 144 0:37 /child /tmp/child rw shared:93 - tmpfs tmpfs rw,seclabel
[root@f22ml ~]# grep "child" /proc/1498/mountinfo
244 208 0:37 /child /tmp/child rw shared:127 master:93 - tmpfs tmpfs 
rw,seclabel

[root@f22ml ~]# grep "child" /proc/1499/mountinfo
245 240 0:37 /child /tmp/child rw master:127 - tmpfs tmpfs rw,seclabel
[root@f22ml ~]# grep "child" /proc/1497/mountinfo
246 176 0:37 /child /tmp/child rw shared:128 master:127 - tmpfs tmpfs 
rw,seclabel


while expected info for 1497 would be:
246 176 0:37 /child /tmp/child rw master:93 - tmpfs tmpfs rw,seclabel

Now, assuming that only the first hunk of the patch is applied:

> -if (m->mnt_group_id == last_dest->mnt_group_id) {
> +if (m->mnt_group_id && m->mnt_group_id == last_dest->mnt_group_id) {

[root@f22ml ~]# reproducer2
main pid = 1506
monitor pid = 1507
child pid = 1508
grand-child pid = 1509

[root@f22ml ~]# grep "child" /proc/1506/mountinfo
243 144 0:37 /child /tmp/child rw shared:93 - tmpfs tmpfs rw,seclabel
[root@f22ml ~]# grep "child" /proc/1508/mountinfo
244 208 0:37 /child /tmp/child rw shared:93 - tmpfs tmpfs rw,seclabel
[root@f22ml ~]# grep "child" /proc/1509/mountinfo
245 240 0:37 /child /tmp/child rw master:93 - tmpfs tmpfs rw,seclabel
[root@f22ml ~]# grep "child" /proc/1507/mountinfo
246 176 0:37 /child /tmp/child rw master:0 - tmpfs tmpfs rw,seclabel

while expected info for 1507 would be:
246 176 0:37 /child /tmp/child rw master:93 - tmpfs tmpfs rw,seclabel

Thanks,
Maxim
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main()
{
	const char *child  = "/tmp/child";
	int ret;

	printf("main pid = %d\n", getpid());	

	/* make our own private playground ... */
	ret = unshare(CLONE_NEWNS);
	if (ret) {
		perror("unshare");
		exit(1);
	}

	ret = mount("none", "/", NULL, MS_REC|MS_PRIVATE, NULL);
	if (ret) {
		perror("mount");
		exit(1);
	}

	ret = mount("none", "/", NULL, MS_REC|MS_SHARED, NULL);
	if (ret) {
		perror("mount2");
		exit(1);
	}

	/* fork monitor ... */
	ret = fork();
	if (ret < 0) {
		perror("fork");
		exit(1);
	} else if (!ret) {
		printf("monitor pid = %d\n", getpid());

		ret = unshare(CLONE_NEWNS);
		if (ret) {
			perror("unshare in monitor");
			exit(1);
		}

		ret = mount("none", "/", NULL, MS_REC|MS_SHARED, NULL);
		if (ret) {
			perror("mount in monitor");
			exit(1);
		}

		ret = mount("none", "/", NULL, MS_REC|MS_SLAVE, NULL);
		if (ret) {
			perror("mount2 in monitor");
			exit(1);
		}

		sleep(-1);
	}

	/* wait monitor to setup */
	sleep(1);


	/* fork child ... */	
	ret = fork();
	if (ret < 0) {
		perror("fork");
		exit(1);
	} else if (!ret) {
		printf("child pid = %d\n", getpid());

		ret = unshare(CLONE_NEWNS);
		if (ret) {
			perror("unshare in child");
			exit(1);
		}

		ret = mount("none", "/", NULL, MS_REC|MS_SLAVE, NULL);
		if (ret) {
			perror("mount in child");
			exit(1);
		}
		ret = mount(NULL, "/", NULL, MS_REC|MS_SHARED, NULL);
		if (ret) {
			perror("mount2 in child");
			exit(1);
		}

		if (!fork()) { /* grand-child */
			printf("grand-child pid = %d\n", getpid());
			ret = unshare(CLONE_NEWNS);
			if (ret) {
perror("unshare in grand-child");
exit(1);
			}

			ret = mount("none", "/", NULL, MS_REC|MS_SHARED, NULL);
			if (ret) {
perror("mount in grand-child");
exit(1);
			}

Re: [PATCH] fs/pnode.c: treat zero mnt_group_id-s as unequal

[Maxim Patlasov]

On 02/16/2016 11:54 AM, Al Viro wrote:

On Tue, Feb 16, 2016 at 11:45:33AM -0800, Maxim Patlasov wrote:

propagate_one(m) calculates "type" argument for copy_tree() like this:


if (m->mnt_group_id == last_dest->mnt_group_id) {
type = CL_MAKE_SHARED;
} else {
type = CL_SLAVE;
if (IS_MNT_SHARED(m))
   type |= CL_MAKE_SHARED;
   }

The "type" argument then governs clone_mnt() behavior with respect to flags
and mnt_master of new mount. When we iterate through a slave group, it is
possible that both current "m" and "last_dest" are not shared (although,
both are slaves, i.e. have non-NULL mnt_master-s). Then the comparison
above erroneously makes new mount shared and sets its mnt_master to
last_source->mnt_master. The patch fixes the problem by handling zero
mnt_group_id-s as though they are unequal.

The similar problem exists in the implementation of "else" clause above
when we have to ascend upward in the master/slave tree by calling:


last_source = last_source->mnt_master;
last_dest = last_source->mnt_parent;

proper number of times. The last step is governed by
"n->mnt_group_id != last_dest->mnt_group_id" condition that may lie if
both are zero. The patch fixes this case in the same way as the former one.

Mind putting together a reproducer?


There are two files attached: reproducer1.c and reproducer2.c. The 
former demonstrates the problem before applying the patch. The latter 
demonstrates why the first hunk of the patch is not enough.


[root@f22ml ~]# reproducer1
main pid = 1496
monitor pid = 1497
child pid = 1498
grand-child pid = 1499

[root@f22ml ~]# grep "child" /proc/1496/mountinfo
243 144 0:37 /child /tmp/child rw shared:93 - tmpfs tmpfs rw,seclabel
[root@f22ml ~]# grep "child" /proc/1498/mountinfo
244 208 0:37 /child /tmp/child rw shared:127 master:93 - tmpfs tmpfs 
rw,seclabel

[root@f22ml ~]# grep "child" /proc/1499/mountinfo
245 240 0:37 /child /tmp/child rw master:127 - tmpfs tmpfs rw,seclabel
[root@f22ml ~]# grep "child" /proc/1497/mountinfo
246 176 0:37 /child /tmp/child rw shared:128 master:127 - tmpfs tmpfs 
rw,seclabel


while expected info for 1497 would be:
246 176 0:37 /child /tmp/child rw master:93 - tmpfs tmpfs rw,seclabel

Now, assuming that only the first hunk of the patch is applied:

> -if (m->mnt_group_id == last_dest->mnt_group_id) {
> +if (m->mnt_group_id && m->mnt_group_id == last_dest->mnt_group_id) {

[root@f22ml ~]# reproducer2
main pid = 1506
monitor pid = 1507
child pid = 1508
grand-child pid = 1509

[root@f22ml ~]# grep "child" /proc/1506/mountinfo
243 144 0:37 /child /tmp/child rw shared:93 - tmpfs tmpfs rw,seclabel
[root@f22ml ~]# grep "child" /proc/1508/mountinfo
244 208 0:37 /child /tmp/child rw shared:93 - tmpfs tmpfs rw,seclabel
[root@f22ml ~]# grep "child" /proc/1509/mountinfo
245 240 0:37 /child /tmp/child rw master:93 - tmpfs tmpfs rw,seclabel
[root@f22ml ~]# grep "child" /proc/1507/mountinfo
246 176 0:37 /child /tmp/child rw master:0 - tmpfs tmpfs rw,seclabel

while expected info for 1507 would be:
246 176 0:37 /child /tmp/child rw master:93 - tmpfs tmpfs rw,seclabel

Thanks,
Maxim
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main()
{
	const char *child  = "/tmp/child";
	int ret;

	printf("main pid = %d\n", getpid());	

	/* make our own private playground ... */
	ret = unshare(CLONE_NEWNS);
	if (ret) {
		perror("unshare");
		exit(1);
	}

	ret = mount("none", "/", NULL, MS_REC|MS_PRIVATE, NULL);
	if (ret) {
		perror("mount");
		exit(1);
	}

	ret = mount("none", "/", NULL, MS_REC|MS_SHARED, NULL);
	if (ret) {
		perror("mount2");
		exit(1);
	}

	/* fork monitor ... */
	ret = fork();
	if (ret < 0) {
		perror("fork");
		exit(1);
	} else if (!ret) {
		printf("monitor pid = %d\n", getpid());

		ret = unshare(CLONE_NEWNS);
		if (ret) {
			perror("unshare in monitor");
			exit(1);
		}

		ret = mount("none", "/", NULL, MS_REC|MS_SHARED, NULL);
		if (ret) {
			perror("mount in monitor");
			exit(1);
		}

		ret = mount("none", "/", NULL, MS_REC|MS_SLAVE, NULL);
		if (ret) {
			perror("mount2 in monitor");
			exit(1);
		}

		sleep(-1);
	}

	/* wait monitor to setup */
	sleep(1);


	/* fork child ... */	
	ret = fork();
	if (ret < 0) {
		perror("fork");
		exit(1);
	} else if (!ret) {
		printf("child pid = %d\n", getpid());

		ret = unshare(CLONE_NEWNS);
		if (ret) {
			perror("unshare in child");
			exit(1);
		}

		ret = mount("none", "/", NULL, MS_REC|MS_SLAVE, NULL);
		if (ret) {
			perror("mount in child");
			exit(1);
		}
		ret = mount(NULL, "/", NULL, MS_REC|MS_SHARED, NULL);
		if (ret) {
			perror("mount2 in child");
			exit(1);
		}

		if (!fork()) { /* grand-child */
			printf("grand-child pid = %d\n", getpid());
			ret = unshare(CLONE_NEWNS);
			if (ret) {
perror("unshare in grand-child");
exit(1);
			}

			ret = mount("none", "/", NULL, MS_REC|MS_SHARED, NULL);
			if (ret) {
perror("mount in grand-child");
exit(1);
			}

Re: [RFC 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420

[Krzysztof Kozlowski]

On 17.02.2016 16:01, Viresh Kumar wrote:
> On 17-02-16, 15:55, Krzysztof Kozlowski wrote:
>> On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
>> 12 steps for big core (700-1800 MHz). Add respective cooling cells.
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  arch/arm/boot/dts/exynos5420-cpus.dtsi | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi 
>> b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> index 261d25173f61..498ae82e1cb2 100644
>> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> @@ -33,6 +33,9 @@
>>  clock-frequency = <18>;
>>  cci-control-port = <_control1>;
>>  operating-points-v2 = <_a15_opp_table>;
>> +cooling-min-level = <0>;
>> +cooling-max-level = <11>;
>> +#cooling-cells = <2>; /* min followed by max */
>>  };
>>  
>>  cpu1: cpu@1 {
>> @@ -70,6 +73,9 @@
>>  clock-frequency = <10>;
>>  cci-control-port = <_control0>;
>>  operating-points-v2 = <_a7_opp_table>;
>> +cooling-min-level = <0>;
>> +cooling-max-level = <7>;
>> +#cooling-cells = <2>; /* min followed by max */
>>  };
> 
> Though it wouldn't matter (for the issue you are getting), but this should be
> added for all the CPUs in case some other CPU is booted first.

Thanks! I'll fix it also for patch 2/3.

Best regards,
Krzysztof

Re: [RFC 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420

[Krzysztof Kozlowski]

On 17.02.2016 16:01, Viresh Kumar wrote:
> On 17-02-16, 15:55, Krzysztof Kozlowski wrote:
>> On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
>> 12 steps for big core (700-1800 MHz). Add respective cooling cells.
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  arch/arm/boot/dts/exynos5420-cpus.dtsi | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi 
>> b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> index 261d25173f61..498ae82e1cb2 100644
>> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> @@ -33,6 +33,9 @@
>>  clock-frequency = <18>;
>>  cci-control-port = <_control1>;
>>  operating-points-v2 = <_a15_opp_table>;
>> +cooling-min-level = <0>;
>> +cooling-max-level = <11>;
>> +#cooling-cells = <2>; /* min followed by max */
>>  };
>>  
>>  cpu1: cpu@1 {
>> @@ -70,6 +73,9 @@
>>  clock-frequency = <10>;
>>  cci-control-port = <_control0>;
>>  operating-points-v2 = <_a7_opp_table>;
>> +cooling-min-level = <0>;
>> +cooling-max-level = <7>;
>> +#cooling-cells = <2>; /* min followed by max */
>>  };
> 
> Though it wouldn't matter (for the issue you are getting), but this should be
> added for all the CPUs in case some other CPU is booted first.

Thanks! I'll fix it also for patch 2/3.

Best regards,
Krzysztof

RE: [PATCH v5 0/3] Adding NPS400 drivers

[Noam Camus]

Waiting for your feedback on my v5 patch set :)

-Original Message-
From: Noam Camus 
Sent: Thursday, February 11, 2016 8:41 PM
To: linux-kernel@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org; daniel.lezc...@linaro.org; 
marc.zyng...@arm.com; Chris Metcalf; Tal Zilcer; Gilad Ben Yossef; Noam Camus
Subject: [PATCH v5 0/3] Adding NPS400 drivers

From: Noam Camus 

Change Log--
v5:
Clocksource, irqchip - Fix gracefull return.
replace call to panic() with pr_err() and 
proper return value.

v4:
clocksource -- Apply all Daniel comments (Thanks)
Handle gracefull return and also using 
clocksoure mmio driver at init

v3:
irqchip - Fix ARM build failure by adding missing include of linux/irq.h 
clocksource -- Avoid 64bit arch's to build driver by adding new dependency 
!PHYS_ADDR_T_64BIT
This is since we use explicit io access of 32 
bit. So for test coverage we allow
not only build for ARC, but restrict it to 32 
bit arch's.
irqchip - Apply all Thomas comments (Thank you)

v2:
Add header file include/soc/nps/common.h.
Now to build we do not depend on ARC subtree.

General summay:
Both drivers are now apart of previous basic patch set of new platform for ARC.
The rest is now can be seen at ARC srctree:
https://git.kernel.org/cgit/linux/kernel/git/vgupta/arc.git/

Now ARC is supporting DT for clockevents and the interrupt controller ARC uses 
irq domain handling.

Compare to last version now clocksource driver do not include clockevent 
registration since NPS400 can use ARC generic driver.

Compare to last version now irqchip driver sets domain as default since it is 
the root domain.
Also mapping of IPI is done in this driver.

Last thing is that drivers can be build cleanly for i386 (still runs only for 
ARC)
Note: in order to build we need to merge drivers into srctree which includes 
new header:
soc/nps/common.h
This header is part of patch set applied to ARC srctree.

Regards,
Noam Camus

Noam Camus (3):
  soc: Support for EZchip SoC
  clocksource: Add NPS400 timers driver
  irqchip: add nps Internal and external irqchips

 .../interrupt-controller/ezchip,nps400-ic.txt  |   17 +++
 .../bindings/timer/ezchip,nps400-timer.txt |   15 ++
 drivers/clocksource/Kconfig|   10 ++
 drivers/clocksource/Makefile   |1 +
 drivers/clocksource/timer-nps.c|   82 +++
 drivers/irqchip/Kconfig|6 +
 drivers/irqchip/Makefile   |1 +
 drivers/irqchip/irq-eznps.c|  149 +++
 include/soc/nps/common.h   |  150 
 9 files changed, 431 insertions(+), 0 deletions(-)  create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/ezchip,nps400-ic.txt
 create mode 100644 
Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
 create mode 100644 drivers/clocksource/timer-nps.c  create mode 100644 
drivers/irqchip/irq-eznps.c  create mode 100644 include/soc/nps/common.h

RE: [PATCH v5 0/3] Adding NPS400 drivers

[Noam Camus]

Waiting for your feedback on my v5 patch set :)

-Original Message-
From: Noam Camus 
Sent: Thursday, February 11, 2016 8:41 PM
To: linux-kernel@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org; daniel.lezc...@linaro.org; 
marc.zyng...@arm.com; Chris Metcalf; Tal Zilcer; Gilad Ben Yossef; Noam Camus
Subject: [PATCH v5 0/3] Adding NPS400 drivers

From: Noam Camus 

Change Log--
v5:
Clocksource, irqchip - Fix gracefull return.
replace call to panic() with pr_err() and 
proper return value.

v4:
clocksource -- Apply all Daniel comments (Thanks)
Handle gracefull return and also using 
clocksoure mmio driver at init

v3:
irqchip - Fix ARM build failure by adding missing include of linux/irq.h 
clocksource -- Avoid 64bit arch's to build driver by adding new dependency 
!PHYS_ADDR_T_64BIT
This is since we use explicit io access of 32 
bit. So for test coverage we allow
not only build for ARC, but restrict it to 32 
bit arch's.
irqchip - Apply all Thomas comments (Thank you)

v2:
Add header file include/soc/nps/common.h.
Now to build we do not depend on ARC subtree.

General summay:
Both drivers are now apart of previous basic patch set of new platform for ARC.
The rest is now can be seen at ARC srctree:
https://git.kernel.org/cgit/linux/kernel/git/vgupta/arc.git/

Now ARC is supporting DT for clockevents and the interrupt controller ARC uses 
irq domain handling.

Compare to last version now clocksource driver do not include clockevent 
registration since NPS400 can use ARC generic driver.

Compare to last version now irqchip driver sets domain as default since it is 
the root domain.
Also mapping of IPI is done in this driver.

Last thing is that drivers can be build cleanly for i386 (still runs only for 
ARC)
Note: in order to build we need to merge drivers into srctree which includes 
new header:
soc/nps/common.h
This header is part of patch set applied to ARC srctree.

Regards,
Noam Camus

Noam Camus (3):
  soc: Support for EZchip SoC
  clocksource: Add NPS400 timers driver
  irqchip: add nps Internal and external irqchips

 .../interrupt-controller/ezchip,nps400-ic.txt  |   17 +++
 .../bindings/timer/ezchip,nps400-timer.txt |   15 ++
 drivers/clocksource/Kconfig|   10 ++
 drivers/clocksource/Makefile   |1 +
 drivers/clocksource/timer-nps.c|   82 +++
 drivers/irqchip/Kconfig|6 +
 drivers/irqchip/Makefile   |1 +
 drivers/irqchip/irq-eznps.c|  149 +++
 include/soc/nps/common.h   |  150 
 9 files changed, 431 insertions(+), 0 deletions(-)  create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/ezchip,nps400-ic.txt
 create mode 100644 
Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
 create mode 100644 drivers/clocksource/timer-nps.c  create mode 100644 
drivers/irqchip/irq-eznps.c  create mode 100644 include/soc/nps/common.h

[PATCH v5 4/4] soc: mediatek: Add MT2701 scpsys driver

[James Liao]

From: Shunli Wang 

Add scpsys driver for MT2701.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
---
 drivers/soc/mediatek/mtk-scpsys.c | 108 +-
 1 file changed, 107 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index ebfc887..171fd8e 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #define SPM_VDE_PWR_CON0x0210
@@ -27,8 +28,13 @@
 #define SPM_VEN_PWR_CON0x0230
 #define SPM_ISP_PWR_CON0x0238
 #define SPM_DIS_PWR_CON0x023c
+#define SPM_CONN_PWR_CON   0x0280
 #define SPM_VEN2_PWR_CON   0x0298
-#define SPM_AUDIO_PWR_CON  0x029c
+#define SPM_AUDIO_PWR_CON  0x029c  /* MT8173 */
+#define SPM_BDP_PWR_CON0x029c  /* MT2701 */
+#define SPM_ETH_PWR_CON0x02a0
+#define SPM_HIF_PWR_CON0x02a4
+#define SPM_IFR_MSC_PWR_CON0x02a8
 #define SPM_MFG_2D_PWR_CON 0x02c0
 #define SPM_MFG_ASYNC_PWR_CON  0x02c4
 #define SPM_USB_PWR_CON0x02cc
@@ -42,10 +48,15 @@
 #define PWR_ON_2ND_BIT BIT(3)
 #define PWR_CLK_DIS_BITBIT(4)
 
+#define PWR_STATUS_CONNBIT(1)
 #define PWR_STATUS_DISPBIT(3)
 #define PWR_STATUS_MFG BIT(4)
 #define PWR_STATUS_ISP BIT(5)
 #define PWR_STATUS_VDECBIT(7)
+#define PWR_STATUS_BDP BIT(14)
+#define PWR_STATUS_ETH BIT(15)
+#define PWR_STATUS_HIF BIT(16)
+#define PWR_STATUS_IFR_MSC BIT(17)
 #define PWR_STATUS_VENC_LT BIT(20)
 #define PWR_STATUS_VENCBIT(21)
 #define PWR_STATUS_MFG_2D  BIT(22)
@@ -469,6 +480,98 @@ static void mtk_register_power_domains(struct 
platform_device *pdev,
 }
 
 /*
+ * MT2701 power domain support
+ */
+
+static const struct scp_domain_data scp_domain_data_mt2701[] __initconst = {
+   [MT2701_POWER_DOMAIN_CONN] = {
+   .name = "conn",
+   .sta_mask = PWR_STATUS_CONN,
+   .ctl_offs = SPM_CONN_PWR_CON,
+   .bus_prot_mask = 0x0104,
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_DISP] = {
+   .name = "disp",
+   .sta_mask = PWR_STATUS_DISP,
+   .ctl_offs = SPM_DIS_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .clk_id = {CLK_MM},
+   .bus_prot_mask = 0x0002,
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_MFG] = {
+   .name = "mfg",
+   .sta_mask = PWR_STATUS_MFG,
+   .ctl_offs = SPM_MFG_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_VDEC] = {
+   .name = "vdec",
+   .sta_mask = PWR_STATUS_VDEC,
+   .ctl_offs = SPM_VDE_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_MM},
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_ISP] = {
+   .name = "isp",
+   .sta_mask = PWR_STATUS_ISP,
+   .ctl_offs = SPM_ISP_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(13, 12),
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_BDP] = {
+   .name = "bdp",
+   .sta_mask = PWR_STATUS_BDP,
+   .ctl_offs = SPM_BDP_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_ETH] = {
+   .name = "eth",
+   .sta_mask = PWR_STATUS_ETH,
+   .ctl_offs = SPM_ETH_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(15, 12),
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_HIF] = {
+   .name = "hif",
+   .sta_mask = PWR_STATUS_HIF,
+   .ctl_offs = SPM_HIF_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(15, 12),
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_IFR_MSC] = {
+   .name = "ifr_msc",
+   .sta_mask = PWR_STATUS_IFR_MSC,
+   .ctl_offs = SPM_IFR_MSC_PWR_CON,
+   .active_wakeup = true,
+

[PATCH v5 4/4] soc: mediatek: Add MT2701 scpsys driver

[James Liao]

From: Shunli Wang 

Add scpsys driver for MT2701.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
---
 drivers/soc/mediatek/mtk-scpsys.c | 108 +-
 1 file changed, 107 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index ebfc887..171fd8e 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #define SPM_VDE_PWR_CON0x0210
@@ -27,8 +28,13 @@
 #define SPM_VEN_PWR_CON0x0230
 #define SPM_ISP_PWR_CON0x0238
 #define SPM_DIS_PWR_CON0x023c
+#define SPM_CONN_PWR_CON   0x0280
 #define SPM_VEN2_PWR_CON   0x0298
-#define SPM_AUDIO_PWR_CON  0x029c
+#define SPM_AUDIO_PWR_CON  0x029c  /* MT8173 */
+#define SPM_BDP_PWR_CON0x029c  /* MT2701 */
+#define SPM_ETH_PWR_CON0x02a0
+#define SPM_HIF_PWR_CON0x02a4
+#define SPM_IFR_MSC_PWR_CON0x02a8
 #define SPM_MFG_2D_PWR_CON 0x02c0
 #define SPM_MFG_ASYNC_PWR_CON  0x02c4
 #define SPM_USB_PWR_CON0x02cc
@@ -42,10 +48,15 @@
 #define PWR_ON_2ND_BIT BIT(3)
 #define PWR_CLK_DIS_BITBIT(4)
 
+#define PWR_STATUS_CONNBIT(1)
 #define PWR_STATUS_DISPBIT(3)
 #define PWR_STATUS_MFG BIT(4)
 #define PWR_STATUS_ISP BIT(5)
 #define PWR_STATUS_VDECBIT(7)
+#define PWR_STATUS_BDP BIT(14)
+#define PWR_STATUS_ETH BIT(15)
+#define PWR_STATUS_HIF BIT(16)
+#define PWR_STATUS_IFR_MSC BIT(17)
 #define PWR_STATUS_VENC_LT BIT(20)
 #define PWR_STATUS_VENCBIT(21)
 #define PWR_STATUS_MFG_2D  BIT(22)
@@ -469,6 +480,98 @@ static void mtk_register_power_domains(struct 
platform_device *pdev,
 }
 
 /*
+ * MT2701 power domain support
+ */
+
+static const struct scp_domain_data scp_domain_data_mt2701[] __initconst = {
+   [MT2701_POWER_DOMAIN_CONN] = {
+   .name = "conn",
+   .sta_mask = PWR_STATUS_CONN,
+   .ctl_offs = SPM_CONN_PWR_CON,
+   .bus_prot_mask = 0x0104,
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_DISP] = {
+   .name = "disp",
+   .sta_mask = PWR_STATUS_DISP,
+   .ctl_offs = SPM_DIS_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .clk_id = {CLK_MM},
+   .bus_prot_mask = 0x0002,
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_MFG] = {
+   .name = "mfg",
+   .sta_mask = PWR_STATUS_MFG,
+   .ctl_offs = SPM_MFG_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_VDEC] = {
+   .name = "vdec",
+   .sta_mask = PWR_STATUS_VDEC,
+   .ctl_offs = SPM_VDE_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_MM},
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_ISP] = {
+   .name = "isp",
+   .sta_mask = PWR_STATUS_ISP,
+   .ctl_offs = SPM_ISP_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(13, 12),
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_BDP] = {
+   .name = "bdp",
+   .sta_mask = PWR_STATUS_BDP,
+   .ctl_offs = SPM_BDP_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_ETH] = {
+   .name = "eth",
+   .sta_mask = PWR_STATUS_ETH,
+   .ctl_offs = SPM_ETH_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(15, 12),
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_HIF] = {
+   .name = "hif",
+   .sta_mask = PWR_STATUS_HIF,
+   .ctl_offs = SPM_HIF_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(15, 12),
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_IFR_MSC] = {
+   .name = "ifr_msc",
+   .sta_mask = PWR_STATUS_IFR_MSC,
+   .ctl_offs = SPM_IFR_MSC_PWR_CON,
+   .active_wakeup = true,
+   },
+};
+
+#define NUM_DOMAINS_MT2701 ARRAY_SIZE(scp_domain_data_mt2701)

[PATCH v5 1/4] soc: mediatek: Refine scpsys to support multiple platform

[James Liao]

Refine scpsys driver common code to support multiple SoC / platform.

Signed-off-by: James Liao 
---
 drivers/soc/mediatek/mtk-scpsys.c | 363 +++---
 1 file changed, 220 insertions(+), 143 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index 0221387..6d2874d 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -11,17 +11,15 @@
  * GNU General Public License for more details.
  */
 #include 
-#include 
+#include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
+#include 
+
 #include 
 
 #define SPM_VDE_PWR_CON0x0210
@@ -34,6 +32,7 @@
 #define SPM_MFG_2D_PWR_CON 0x02c0
 #define SPM_MFG_ASYNC_PWR_CON  0x02c4
 #define SPM_USB_PWR_CON0x02cc
+
 #define SPM_PWR_STATUS 0x060c
 #define SPM_PWR_STATUS_2ND 0x0610
 
@@ -55,12 +54,12 @@
 #define PWR_STATUS_USB BIT(25)
 
 enum clk_id {
-   MT8173_CLK_NONE,
-   MT8173_CLK_MM,
-   MT8173_CLK_MFG,
-   MT8173_CLK_VENC,
-   MT8173_CLK_VENC_LT,
-   MT8173_CLK_MAX,
+   CLK_NONE,
+   CLK_MM,
+   CLK_MFG,
+   CLK_VENC,
+   CLK_VENC_LT,
+   CLK_MAX,
 };
 
 #define MAX_CLKS   2
@@ -76,98 +75,6 @@ struct scp_domain_data {
bool active_wakeup;
 };
 
-static const struct scp_domain_data scp_domain_data[] __initconst = {
-   [MT8173_POWER_DOMAIN_VDEC] = {
-   .name = "vdec",
-   .sta_mask = PWR_STATUS_VDEC,
-   .ctl_offs = SPM_VDE_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(12, 12),
-   .clk_id = {MT8173_CLK_MM},
-   },
-   [MT8173_POWER_DOMAIN_VENC] = {
-   .name = "venc",
-   .sta_mask = PWR_STATUS_VENC,
-   .ctl_offs = SPM_VEN_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC},
-   },
-   [MT8173_POWER_DOMAIN_ISP] = {
-   .name = "isp",
-   .sta_mask = PWR_STATUS_ISP,
-   .ctl_offs = SPM_ISP_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(13, 12),
-   .clk_id = {MT8173_CLK_MM},
-   },
-   [MT8173_POWER_DOMAIN_MM] = {
-   .name = "mm",
-   .sta_mask = PWR_STATUS_DISP,
-   .ctl_offs = SPM_DIS_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(12, 12),
-   .clk_id = {MT8173_CLK_MM},
-   .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
-   MT8173_TOP_AXI_PROT_EN_MM_M1,
-   },
-   [MT8173_POWER_DOMAIN_VENC_LT] = {
-   .name = "venc_lt",
-   .sta_mask = PWR_STATUS_VENC_LT,
-   .ctl_offs = SPM_VEN2_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC_LT},
-   },
-   [MT8173_POWER_DOMAIN_AUDIO] = {
-   .name = "audio",
-   .sta_mask = PWR_STATUS_AUDIO,
-   .ctl_offs = SPM_AUDIO_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = {MT8173_CLK_NONE},
-   },
-   [MT8173_POWER_DOMAIN_USB] = {
-   .name = "usb",
-   .sta_mask = PWR_STATUS_USB,
-   .ctl_offs = SPM_USB_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = {MT8173_CLK_NONE},
-   .active_wakeup = true,
-   },
-   [MT8173_POWER_DOMAIN_MFG_ASYNC] = {
-   .name = "mfg_async",
-   .sta_mask = PWR_STATUS_MFG_ASYNC,
-   .ctl_offs = SPM_MFG_ASYNC_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = 0,
-   .clk_id = {MT8173_CLK_MFG},
-   },
-   [MT8173_POWER_DOMAIN_MFG_2D] = {
-   .name = "mfg_2d",
-   .sta_mask = PWR_STATUS_MFG_2D,
-   .ctl_offs = SPM_MFG_2D_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(13, 12),
-   .clk_id = {MT8173_CLK_NONE},
-   },
-   [MT8173_POWER_DOMAIN_MFG] = {
-   .name = "mfg",
-   .sta_mask = PWR_STATUS_MFG,
-   .ctl_offs = SPM_MFG_PWR_CON,
-   .sram_pdn_bits = GENMASK(13, 8),
-   .sram_pdn_ack_bits = GENMASK(21, 16),
-   .clk_id = {MT8173_CLK_NONE},
-   .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S |
-   

[PATCH v5 2/4] soc: mediatek: Init MT8173 scpsys driver earlier

[James Liao]

Some power domain comsumers may init before module_init.
So the power domain provider (scpsys) need to be initialized
earlier too.

Take an example for our IOMMU (M4U) and SMI. SMI is a bridge
between IOMMU and multimedia HW. SMI is responsible to
enable/disable iommu and help transfer data for each multimedia
HW. Both of them have to wait until the power and clocks are
enabled.

So scpsys driver should be initialized before SMI, and SMI should
be initialized before IOMMU, and then init IOMMU consumers
(display/vdec/venc/camera etc.).

IOMMU is subsys_init by default. So we need to init scpsys driver
before subsys_init.

Signed-off-by: James Liao 
---
 drivers/soc/mediatek/mtk-scpsys.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index 6d2874d..ebfc887 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -625,4 +625,21 @@ static struct platform_driver scpsys_drv = {
.of_match_table = of_match_ptr(of_scpsys_match_tbl),
},
 };
-builtin_platform_driver_probe(scpsys_drv, scpsys_probe);
+
+static int __init scpsys_drv_init(void)
+{
+   return platform_driver_probe(_drv, scpsys_probe);
+}
+
+/*
+ * There are some Mediatek drivers which depend on the power domain driver need
+ * to probe in earlier initcall levels. So scpsys driver also need to probe
+ * earlier.
+ *
+ * IOMMU(M4U) and SMI drivers for example. SMI is a bridge between IOMMU and
+ * multimedia HW. IOMMU depends on SMI, and SMI is a power domain consumer,
+ * so the proper probe sequence should be scpsys -> SMI -> IOMMU driver.
+ * IOMMU drivers are initialized during subsys_init by default, so we need to
+ * move SMI and scpsys drivers to subsys_init or earlier init levels.
+ */
+subsys_initcall(scpsys_drv_init);
-- 
1.9.1

[PATCH v5 0/4] Mediatek MT2701 SCPSYS power domain support

[James Liao]

This patchset is based on v4.5-rc4 and adds scpsys power domain support
for Mediatek MT2701.

To share the code between MT2701 and MT8173, this patchset also refined
original mtk-scpsys.c to separate common codes and platform codes, so
that mtk-scpsys.c can support new SoCs more easily.

MT8173 and MT2701 scpsys init level are now subsys_init. Please refer to [1]
to see discussion details.

changes since v4:
- Rebase to v4.5-rc4.
- Remove mtk-scpsys.h and Merge its code into mtk-scpsys.c.
- Add names for every controlling registers and bits.
- Include dt-bindings headers at the beginning of mtk-scpsys.c.
- Sort compatible string in dt-binding documents.

changes since v3:
- Implement MT8173 and MT2701 scpsys drivers in a signle file.
- Remove naming of registers that can't be shared among SoCs.

changes since v2:
- Rebase to mbgg/linux-mediatek v4.4-next/soc [1].
- Remove MTK_SCPSYS_MT8173 and MTK_SCPSYS_MT2701.
- Modify scpsys dt-binding document to support MT2701.

changes since v1:
- Make MTK_SCPSYS in Kconfig invisible from users.
- Add comments for changing scpsys init level to subsys_init.

[1] 
http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003416.html

James Liao (2):
  soc: mediatek: Refine scpsys to support multiple platform
  soc: mediatek: Init MT8173 scpsys driver earlier

Shunli Wang (2):
  soc: mediatek: Add MT2701 power dt-bindings
  soc: mediatek: Add MT2701 scpsys driver

 .../devicetree/bindings/soc/mediatek/scpsys.txt|   6 +-
 drivers/soc/mediatek/mtk-scpsys.c  | 490 +++--
 include/dt-bindings/power/mt2701-power.h   |  27 ++
 3 files changed, 376 insertions(+), 147 deletions(-)
 create mode 100644 include/dt-bindings/power/mt2701-power.h

--
1.9.1

[PATCH v5 1/4] soc: mediatek: Refine scpsys to support multiple platform

[James Liao]

Refine scpsys driver common code to support multiple SoC / platform.

Signed-off-by: James Liao 
---
 drivers/soc/mediatek/mtk-scpsys.c | 363 +++---
 1 file changed, 220 insertions(+), 143 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index 0221387..6d2874d 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -11,17 +11,15 @@
  * GNU General Public License for more details.
  */
 #include 
-#include 
+#include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
+#include 
+
 #include 
 
 #define SPM_VDE_PWR_CON0x0210
@@ -34,6 +32,7 @@
 #define SPM_MFG_2D_PWR_CON 0x02c0
 #define SPM_MFG_ASYNC_PWR_CON  0x02c4
 #define SPM_USB_PWR_CON0x02cc
+
 #define SPM_PWR_STATUS 0x060c
 #define SPM_PWR_STATUS_2ND 0x0610
 
@@ -55,12 +54,12 @@
 #define PWR_STATUS_USB BIT(25)
 
 enum clk_id {
-   MT8173_CLK_NONE,
-   MT8173_CLK_MM,
-   MT8173_CLK_MFG,
-   MT8173_CLK_VENC,
-   MT8173_CLK_VENC_LT,
-   MT8173_CLK_MAX,
+   CLK_NONE,
+   CLK_MM,
+   CLK_MFG,
+   CLK_VENC,
+   CLK_VENC_LT,
+   CLK_MAX,
 };
 
 #define MAX_CLKS   2
@@ -76,98 +75,6 @@ struct scp_domain_data {
bool active_wakeup;
 };
 
-static const struct scp_domain_data scp_domain_data[] __initconst = {
-   [MT8173_POWER_DOMAIN_VDEC] = {
-   .name = "vdec",
-   .sta_mask = PWR_STATUS_VDEC,
-   .ctl_offs = SPM_VDE_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(12, 12),
-   .clk_id = {MT8173_CLK_MM},
-   },
-   [MT8173_POWER_DOMAIN_VENC] = {
-   .name = "venc",
-   .sta_mask = PWR_STATUS_VENC,
-   .ctl_offs = SPM_VEN_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC},
-   },
-   [MT8173_POWER_DOMAIN_ISP] = {
-   .name = "isp",
-   .sta_mask = PWR_STATUS_ISP,
-   .ctl_offs = SPM_ISP_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(13, 12),
-   .clk_id = {MT8173_CLK_MM},
-   },
-   [MT8173_POWER_DOMAIN_MM] = {
-   .name = "mm",
-   .sta_mask = PWR_STATUS_DISP,
-   .ctl_offs = SPM_DIS_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(12, 12),
-   .clk_id = {MT8173_CLK_MM},
-   .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
-   MT8173_TOP_AXI_PROT_EN_MM_M1,
-   },
-   [MT8173_POWER_DOMAIN_VENC_LT] = {
-   .name = "venc_lt",
-   .sta_mask = PWR_STATUS_VENC_LT,
-   .ctl_offs = SPM_VEN2_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC_LT},
-   },
-   [MT8173_POWER_DOMAIN_AUDIO] = {
-   .name = "audio",
-   .sta_mask = PWR_STATUS_AUDIO,
-   .ctl_offs = SPM_AUDIO_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = {MT8173_CLK_NONE},
-   },
-   [MT8173_POWER_DOMAIN_USB] = {
-   .name = "usb",
-   .sta_mask = PWR_STATUS_USB,
-   .ctl_offs = SPM_USB_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = {MT8173_CLK_NONE},
-   .active_wakeup = true,
-   },
-   [MT8173_POWER_DOMAIN_MFG_ASYNC] = {
-   .name = "mfg_async",
-   .sta_mask = PWR_STATUS_MFG_ASYNC,
-   .ctl_offs = SPM_MFG_ASYNC_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = 0,
-   .clk_id = {MT8173_CLK_MFG},
-   },
-   [MT8173_POWER_DOMAIN_MFG_2D] = {
-   .name = "mfg_2d",
-   .sta_mask = PWR_STATUS_MFG_2D,
-   .ctl_offs = SPM_MFG_2D_PWR_CON,
-   .sram_pdn_bits = GENMASK(11, 8),
-   .sram_pdn_ack_bits = GENMASK(13, 12),
-   .clk_id = {MT8173_CLK_NONE},
-   },
-   [MT8173_POWER_DOMAIN_MFG] = {
-   .name = "mfg",
-   .sta_mask = PWR_STATUS_MFG,
-   .ctl_offs = SPM_MFG_PWR_CON,
-   .sram_pdn_bits = GENMASK(13, 8),
-   .sram_pdn_ack_bits = GENMASK(21, 16),
-   .clk_id = {MT8173_CLK_NONE},
-   .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S |
-   

[PATCH v5 2/4] soc: mediatek: Init MT8173 scpsys driver earlier

[James Liao]

Some power domain comsumers may init before module_init.
So the power domain provider (scpsys) need to be initialized
earlier too.

Take an example for our IOMMU (M4U) and SMI. SMI is a bridge
between IOMMU and multimedia HW. SMI is responsible to
enable/disable iommu and help transfer data for each multimedia
HW. Both of them have to wait until the power and clocks are
enabled.

So scpsys driver should be initialized before SMI, and SMI should
be initialized before IOMMU, and then init IOMMU consumers
(display/vdec/venc/camera etc.).

IOMMU is subsys_init by default. So we need to init scpsys driver
before subsys_init.

Signed-off-by: James Liao 
---
 drivers/soc/mediatek/mtk-scpsys.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index 6d2874d..ebfc887 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -625,4 +625,21 @@ static struct platform_driver scpsys_drv = {
.of_match_table = of_match_ptr(of_scpsys_match_tbl),
},
 };
-builtin_platform_driver_probe(scpsys_drv, scpsys_probe);
+
+static int __init scpsys_drv_init(void)
+{
+   return platform_driver_probe(_drv, scpsys_probe);
+}
+
+/*
+ * There are some Mediatek drivers which depend on the power domain driver need
+ * to probe in earlier initcall levels. So scpsys driver also need to probe
+ * earlier.
+ *
+ * IOMMU(M4U) and SMI drivers for example. SMI is a bridge between IOMMU and
+ * multimedia HW. IOMMU depends on SMI, and SMI is a power domain consumer,
+ * so the proper probe sequence should be scpsys -> SMI -> IOMMU driver.
+ * IOMMU drivers are initialized during subsys_init by default, so we need to
+ * move SMI and scpsys drivers to subsys_init or earlier init levels.
+ */
+subsys_initcall(scpsys_drv_init);
-- 
1.9.1

[PATCH v5 0/4] Mediatek MT2701 SCPSYS power domain support

[James Liao]

This patchset is based on v4.5-rc4 and adds scpsys power domain support
for Mediatek MT2701.

To share the code between MT2701 and MT8173, this patchset also refined
original mtk-scpsys.c to separate common codes and platform codes, so
that mtk-scpsys.c can support new SoCs more easily.

MT8173 and MT2701 scpsys init level are now subsys_init. Please refer to [1]
to see discussion details.

changes since v4:
- Rebase to v4.5-rc4.
- Remove mtk-scpsys.h and Merge its code into mtk-scpsys.c.
- Add names for every controlling registers and bits.
- Include dt-bindings headers at the beginning of mtk-scpsys.c.
- Sort compatible string in dt-binding documents.

changes since v3:
- Implement MT8173 and MT2701 scpsys drivers in a signle file.
- Remove naming of registers that can't be shared among SoCs.

changes since v2:
- Rebase to mbgg/linux-mediatek v4.4-next/soc [1].
- Remove MTK_SCPSYS_MT8173 and MTK_SCPSYS_MT2701.
- Modify scpsys dt-binding document to support MT2701.

changes since v1:
- Make MTK_SCPSYS in Kconfig invisible from users.
- Add comments for changing scpsys init level to subsys_init.

[1] 
http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003416.html

James Liao (2):
  soc: mediatek: Refine scpsys to support multiple platform
  soc: mediatek: Init MT8173 scpsys driver earlier

Shunli Wang (2):
  soc: mediatek: Add MT2701 power dt-bindings
  soc: mediatek: Add MT2701 scpsys driver

 .../devicetree/bindings/soc/mediatek/scpsys.txt|   6 +-
 drivers/soc/mediatek/mtk-scpsys.c  | 490 +++--
 include/dt-bindings/power/mt2701-power.h   |  27 ++
 3 files changed, 376 insertions(+), 147 deletions(-)
 create mode 100644 include/dt-bindings/power/mt2701-power.h

--
1.9.1

[PATCH v5 3/4] soc: mediatek: Add MT2701 power dt-bindings

[James Liao]

From: Shunli Wang 

Add power dt-bindings for MT2701.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
---
 .../devicetree/bindings/soc/mediatek/scpsys.txt|  6 +++--
 include/dt-bindings/power/mt2701-power.h   | 27 ++
 2 files changed, 31 insertions(+), 2 deletions(-)
 create mode 100644 include/dt-bindings/power/mt2701-power.h

diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt 
b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
index e8f15e3..5f3d1c9 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -9,10 +9,12 @@ domain control.
 
 The driver implements the Generic PM domain bindings described in
 power/power_domain.txt. It provides the power domains defined in
-include/dt-bindings/power/mt8173-power.h.
+include/dt-bindings/power/mt8173-power.h and mt2701-power.h.
 
 Required properties:
-- compatible: Must be "mediatek,mt8173-scpsys"
+- compatible: Should be one of:
+   - "mediatek,mt2701-scpsys"
+   - "mediatek,mt8173-scpsys"
 - #power-domain-cells: Must be 1
 - reg: Address range of the SCPSYS unit
 - infracfg: must contain a phandle to the infracfg controller
diff --git a/include/dt-bindings/power/mt2701-power.h 
b/include/dt-bindings/power/mt2701-power.h
new file mode 100644
index 000..64cc826
--- /dev/null
+++ b/include/dt-bindings/power/mt2701-power.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2015 MediaTek Inc.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_POWER_MT2701_POWER_H
+#define _DT_BINDINGS_POWER_MT2701_POWER_H
+
+#define MT2701_POWER_DOMAIN_CONN   0
+#define MT2701_POWER_DOMAIN_DISP   1
+#define MT2701_POWER_DOMAIN_MFG2
+#define MT2701_POWER_DOMAIN_VDEC   3
+#define MT2701_POWER_DOMAIN_ISP4
+#define MT2701_POWER_DOMAIN_BDP5
+#define MT2701_POWER_DOMAIN_ETH6
+#define MT2701_POWER_DOMAIN_HIF7
+#define MT2701_POWER_DOMAIN_IFR_MSC8
+
+#endif /* _DT_BINDINGS_POWER_MT2701_POWER_H */
-- 
1.9.1

[PATCH v5 3/4] soc: mediatek: Add MT2701 power dt-bindings

[James Liao]

From: Shunli Wang 

Add power dt-bindings for MT2701.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
---
 .../devicetree/bindings/soc/mediatek/scpsys.txt|  6 +++--
 include/dt-bindings/power/mt2701-power.h   | 27 ++
 2 files changed, 31 insertions(+), 2 deletions(-)
 create mode 100644 include/dt-bindings/power/mt2701-power.h

diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt 
b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
index e8f15e3..5f3d1c9 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -9,10 +9,12 @@ domain control.
 
 The driver implements the Generic PM domain bindings described in
 power/power_domain.txt. It provides the power domains defined in
-include/dt-bindings/power/mt8173-power.h.
+include/dt-bindings/power/mt8173-power.h and mt2701-power.h.
 
 Required properties:
-- compatible: Must be "mediatek,mt8173-scpsys"
+- compatible: Should be one of:
+   - "mediatek,mt2701-scpsys"
+   - "mediatek,mt8173-scpsys"
 - #power-domain-cells: Must be 1
 - reg: Address range of the SCPSYS unit
 - infracfg: must contain a phandle to the infracfg controller
diff --git a/include/dt-bindings/power/mt2701-power.h 
b/include/dt-bindings/power/mt2701-power.h
new file mode 100644
index 000..64cc826
--- /dev/null
+++ b/include/dt-bindings/power/mt2701-power.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2015 MediaTek Inc.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_POWER_MT2701_POWER_H
+#define _DT_BINDINGS_POWER_MT2701_POWER_H
+
+#define MT2701_POWER_DOMAIN_CONN   0
+#define MT2701_POWER_DOMAIN_DISP   1
+#define MT2701_POWER_DOMAIN_MFG2
+#define MT2701_POWER_DOMAIN_VDEC   3
+#define MT2701_POWER_DOMAIN_ISP4
+#define MT2701_POWER_DOMAIN_BDP5
+#define MT2701_POWER_DOMAIN_ETH6
+#define MT2701_POWER_DOMAIN_HIF7
+#define MT2701_POWER_DOMAIN_IFR_MSC8
+
+#endif /* _DT_BINDINGS_POWER_MT2701_POWER_H */
-- 
1.9.1

Re: [PATCH 6/6] ARM64: dts: rockchip: add core dtsi file for rk3399

[Heiko Stuebner]

Hi Jianqun,

Am Mittwoch, 17. Februar 2016, 10:01:16 schrieb jianqun.xu:
> From: Xu Jianqun 
> 
> Add dtsi file for Rockchip rk3399 SoCs, which includes some
> general nodes such as cpu, pmu, cru, gic, amba and so on.
> 
> Change-Id: Ie3b824e8ead967d4cb119d73222b7a198478c29c

please remove any review-cruft like Change-Ids from mainline patches :-)

> Signed-off-by: Xu Jianqun 
> ---
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 989
> +++ 1 file changed, 989 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi new file mode 100644
> index 000..eb671f6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -0,0 +1,989 @@
> +/*
> + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library 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 library 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + compatible = "rockchip,rk3399";
> + interrupt-parent = <>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = 
> + serial1 = 
> + serial2 = 
> + serial3 = 
> + };
> +
> + psci {
> + compatible = "arm,psci";
> + method = "smc";
> + };
> +
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <_l0>;
> + };
> + core1 {
> + cpu = <_l1>;
> + };
> + core2 {
> + cpu = <_l2>;
> + };
> + core3 {
> + cpu = <_l3>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <_b0>;
> + };
> + core1 {
> + cpu = <_b1>;
> + };
> + };
> + };
> +
> + idle-states {
> + entry-method = "psci";
> +
> + cpu_sleep: cpu-sleep-0 {
> + compatible = "arm,idle-state";
> + };
> + };

why the essentially empty idle-states, which is probably missing properties? 
In the absence of a real idle driver the kernel will fall back to 
arch_cpu_idle(), which already does WFI handling even on arm64.


> +
> + cpu_l0: cpu@0 {
> + device_type = "cpu";
> +   

Re: [RFC 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420

[Viresh Kumar]

On 17-02-16, 15:55, Krzysztof Kozlowski wrote:
> On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
> 12 steps for big core (700-1800 MHz). Add respective cooling cells.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm/boot/dts/exynos5420-cpus.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi 
> b/arch/arm/boot/dts/exynos5420-cpus.dtsi
> index 261d25173f61..498ae82e1cb2 100644
> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
> @@ -33,6 +33,9 @@
>   clock-frequency = <18>;
>   cci-control-port = <_control1>;
>   operating-points-v2 = <_a15_opp_table>;
> + cooling-min-level = <0>;
> + cooling-max-level = <11>;
> + #cooling-cells = <2>; /* min followed by max */
>   };
>  
>   cpu1: cpu@1 {
> @@ -70,6 +73,9 @@
>   clock-frequency = <10>;
>   cci-control-port = <_control0>;
>   operating-points-v2 = <_a7_opp_table>;
> + cooling-min-level = <0>;
> + cooling-max-level = <7>;
> + #cooling-cells = <2>; /* min followed by max */
>   };

Though it wouldn't matter (for the issue you are getting), but this should be
added for all the CPUs in case some other CPU is booted first.

-- 
viresh

Re: [PATCH 6/6] ARM64: dts: rockchip: add core dtsi file for rk3399

[Heiko Stuebner]

Hi Jianqun,

Am Mittwoch, 17. Februar 2016, 10:01:16 schrieb jianqun.xu:
> From: Xu Jianqun 
> 
> Add dtsi file for Rockchip rk3399 SoCs, which includes some
> general nodes such as cpu, pmu, cru, gic, amba and so on.
> 
> Change-Id: Ie3b824e8ead967d4cb119d73222b7a198478c29c

please remove any review-cruft like Change-Ids from mainline patches :-)

> Signed-off-by: Xu Jianqun 
> ---
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 989
> +++ 1 file changed, 989 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi new file mode 100644
> index 000..eb671f6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -0,0 +1,989 @@
> +/*
> + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library 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 library 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + compatible = "rockchip,rk3399";
> + interrupt-parent = <>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = 
> + serial1 = 
> + serial2 = 
> + serial3 = 
> + };
> +
> + psci {
> + compatible = "arm,psci";
> + method = "smc";
> + };
> +
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <_l0>;
> + };
> + core1 {
> + cpu = <_l1>;
> + };
> + core2 {
> + cpu = <_l2>;
> + };
> + core3 {
> + cpu = <_l3>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <_b0>;
> + };
> + core1 {
> + cpu = <_b1>;
> + };
> + };
> + };
> +
> + idle-states {
> + entry-method = "psci";
> +
> + cpu_sleep: cpu-sleep-0 {
> + compatible = "arm,idle-state";
> + };
> + };

why the essentially empty idle-states, which is probably missing properties? 
In the absence of a real idle driver the kernel will fall back to 
arch_cpu_idle(), which already does WFI handling even on arm64.


> +
> + cpu_l0: cpu@0 {
> + device_type = "cpu";
> + compatible = 

Re: [RFC 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420

[Viresh Kumar]

On 17-02-16, 15:55, Krzysztof Kozlowski wrote:
> On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
> 12 steps for big core (700-1800 MHz). Add respective cooling cells.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm/boot/dts/exynos5420-cpus.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi 
> b/arch/arm/boot/dts/exynos5420-cpus.dtsi
> index 261d25173f61..498ae82e1cb2 100644
> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
> @@ -33,6 +33,9 @@
>   clock-frequency = <18>;
>   cci-control-port = <_control1>;
>   operating-points-v2 = <_a15_opp_table>;
> + cooling-min-level = <0>;
> + cooling-max-level = <11>;
> + #cooling-cells = <2>; /* min followed by max */
>   };
>  
>   cpu1: cpu@1 {
> @@ -70,6 +73,9 @@
>   clock-frequency = <10>;
>   cci-control-port = <_control0>;
>   operating-points-v2 = <_a7_opp_table>;
> + cooling-min-level = <0>;
> + cooling-max-level = <7>;
> + #cooling-cells = <2>; /* min followed by max */
>   };

Though it wouldn't matter (for the issue you are getting), but this should be
added for all the CPUs in case some other CPU is booted first.

-- 
viresh

[RFC 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420

[Krzysztof Kozlowski]

On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
12 steps for big core (700-1800 MHz). Add respective cooling cells.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos5420-cpus.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi 
b/arch/arm/boot/dts/exynos5420-cpus.dtsi
index 261d25173f61..498ae82e1cb2 100644
--- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
@@ -33,6 +33,9 @@
clock-frequency = <18>;
cci-control-port = <_control1>;
operating-points-v2 = <_a15_opp_table>;
+   cooling-min-level = <0>;
+   cooling-max-level = <11>;
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu1: cpu@1 {
@@ -70,6 +73,9 @@
clock-frequency = <10>;
cci-control-port = <_control0>;
operating-points-v2 = <_a7_opp_table>;
+   cooling-min-level = <0>;
+   cooling-max-level = <7>;
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu5: cpu@101 {
-- 
2.5.0

[RFC 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420

[Krzysztof Kozlowski]

On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
12 steps for big core (700-1800 MHz). Add respective cooling cells.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos5420-cpus.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi 
b/arch/arm/boot/dts/exynos5420-cpus.dtsi
index 261d25173f61..498ae82e1cb2 100644
--- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
@@ -33,6 +33,9 @@
clock-frequency = <18>;
cci-control-port = <_control1>;
operating-points-v2 = <_a15_opp_table>;
+   cooling-min-level = <0>;
+   cooling-max-level = <11>;
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu1: cpu@1 {
@@ -70,6 +73,9 @@
clock-frequency = <10>;
cci-control-port = <_control0>;
operating-points-v2 = <_a7_opp_table>;
+   cooling-min-level = <0>;
+   cooling-max-level = <7>;
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu5: cpu@101 {
-- 
2.5.0

[RFC-help needed 0/3] ARM: dts: thermal: Fix Odroid XU3-Lite overheat

[Krzysztof Kozlowski]

Hi,

I mentioned overheating problem of Odroid XU3-Lite after enabling
cpufreq-dt (when busy in a quite warm room). [0]

The patchset tries to fix this by adding CPU cooling device.
Unfortunately apparently I screwed something because on next-20160216
it does not help.

The fan works at full but CPU cooler is not enabled.

Patchset adds 2 additional trip points (so total 5). First 3 trip
points enable the fan. The new two trip points should trigger CPU
cooler.

However after reaching last fan trip point, the thermal zone stops
sending updates to the step-wise governor.
The last log for thermal_zone0 is:

[ 1366.604672] thermal thermal_zone0: last_temperature=71000, 
current_temperature=71000
[ 1366.604699] thermal thermal_zone0: 
Trip0[type=0,temp=5]:trend=0,throttle=1
 instance->upper:
instance->lower:
   throttle:
[ 1366.604713] thermal cooling_device0: cur_state=0, 1, 0, throttle: 1
[ 1366.604725] thermal cooling_device0: CUR_state=0, 1, 0, throttle: 1
[ 1366.604735] thermal cooling_device0: old_target=1, target=1
[ 1366.604754] thermal thermal_zone0: 
Trip1[type=0,temp=6]:trend=0,throttle=1
[ 1366.604776] thermal cooling_device0: cur_state=0, 2, 1, throttle: 1
[ 1366.604786] thermal cooling_device0: CUR_state=0, 2, 1, throttle: 1
[ 1366.604796] thermal cooling_device0: old_target=2, target=2
[ 1366.604810] thermal thermal_zone0: 
Trip2[type=0,temp=7]:trend=0,throttle=1
[ 1366.604821] thermal cooling_device0: cur_state=0, 3, 2, throttle: 1
[ 1366.604832] thermal cooling_device0: CUR_state=0, 3, 2, throttle: 1
[ 1366.604841] thermal cooling_device0: old_target=3, target=3
[ 1366.604856] thermal thermal_zone0: 
Trip4[type=1,temp=9]:trend=0,throttle=0
[ 1366.604869] thermal cooling_device1: cur_state=0, 3, 0, throttle: 0
[ 1366.604879] thermal cooling_device1: CUR_state=0, 3, 0, throttle: 0
[ 1366.604889] thermal cooling_device1: old_target=-1, target=-1
[ 1366.604901] thermal cooling_device2: cur_state=0, 3, 0, throttle: 0
[ 1366.604911] thermal cooling_device2: CUR_state=0, 3, 0, throttle: 0
[ 1366.604921] thermal cooling_device2: old_target=-1, target=-1
[ 1366.604935] thermal thermal_zone0: 
Trip5[type=1,temp=11]:trend=0,throttle=0
[ 1366.604946] thermal cooling_device1: cur_state=0, 7, 7, throttle: 0
[ 1366.604957] thermal cooling_device1: CUR_state=0, 7, 7, throttle: 0
[ 1366.604967] thermal cooling_device1: old_target=-1, target=-1
[ 1366.604977] thermal cooling_device2: cur_state=0, 11, 11, throttle: 0
[ 1366.604988] thermal cooling_device2: CUR_state=0, 11, 11, throttle: 0
[ 1366.604997] thermal cooling_device2: old_target=-1, target=-1

After this, the temperature in zone0 rises but cooling devices do not
receive any pokes...

Did I make some mistake or this is thermal issue?


[0] http://www.spinics.net/lists/arm-kernel/msg482748.html


Best regards,
Krzysztof


Krzysztof Kozlowski (3):
  ARM: dts: Add cooling levels for CPUs on exynos5420
  ARM: dts: Add cooling levels for CPUs on exynos5422/5800
  ARM: dts: Don't overheat the Odroid XU3-Lite on high load

 arch/arm/boot/dts/exynos5420-cpus.dtsi|  6 
 arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 41 +++
 arch/arm/boot/dts/exynos5422-cpus.dtsi|  6 
 3 files changed, 53 insertions(+)

-- 
2.5.0

[RFC 2/3] ARM: dts: Add cooling levels for CPUs on exynos5422/5800

[Krzysztof Kozlowski]

On Exynos5422 and Exynos5800 we support 12 cpufreq steps (200-1300 MHz) for 
LITTLE
and 18 steps for big core (200-1700 MHz). Add respective cooling cells.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos5422-cpus.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi 
b/arch/arm/boot/dts/exynos5422-cpus.dtsi
index 9b46b9fbac4e..858bb7f57d76 100644
--- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -32,6 +32,9 @@
clock-frequency = <10>;
cci-control-port = <_control0>;
operating-points-v2 = <_a7_opp_table>;
+   cooling-min-level = <0>;
+   cooling-max-level = <11>;
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu1: cpu@101 {
@@ -69,6 +72,9 @@
clock-frequency = <18>;
cci-control-port = <_control1>;
operating-points-v2 = <_a15_opp_table>;
+   cooling-min-level = <0>;
+   cooling-max-level = <15>;
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu5: cpu@1 {
-- 
2.5.0

[RFC-help needed 0/3] ARM: dts: thermal: Fix Odroid XU3-Lite overheat

[Krzysztof Kozlowski]

Hi,

I mentioned overheating problem of Odroid XU3-Lite after enabling
cpufreq-dt (when busy in a quite warm room). [0]

The patchset tries to fix this by adding CPU cooling device.
Unfortunately apparently I screwed something because on next-20160216
it does not help.

The fan works at full but CPU cooler is not enabled.

Patchset adds 2 additional trip points (so total 5). First 3 trip
points enable the fan. The new two trip points should trigger CPU
cooler.

However after reaching last fan trip point, the thermal zone stops
sending updates to the step-wise governor.
The last log for thermal_zone0 is:

[ 1366.604672] thermal thermal_zone0: last_temperature=71000, 
current_temperature=71000
[ 1366.604699] thermal thermal_zone0: 
Trip0[type=0,temp=5]:trend=0,throttle=1
 instance->upper:
instance->lower:
   throttle:
[ 1366.604713] thermal cooling_device0: cur_state=0, 1, 0, throttle: 1
[ 1366.604725] thermal cooling_device0: CUR_state=0, 1, 0, throttle: 1
[ 1366.604735] thermal cooling_device0: old_target=1, target=1
[ 1366.604754] thermal thermal_zone0: 
Trip1[type=0,temp=6]:trend=0,throttle=1
[ 1366.604776] thermal cooling_device0: cur_state=0, 2, 1, throttle: 1
[ 1366.604786] thermal cooling_device0: CUR_state=0, 2, 1, throttle: 1
[ 1366.604796] thermal cooling_device0: old_target=2, target=2
[ 1366.604810] thermal thermal_zone0: 
Trip2[type=0,temp=7]:trend=0,throttle=1
[ 1366.604821] thermal cooling_device0: cur_state=0, 3, 2, throttle: 1
[ 1366.604832] thermal cooling_device0: CUR_state=0, 3, 2, throttle: 1
[ 1366.604841] thermal cooling_device0: old_target=3, target=3
[ 1366.604856] thermal thermal_zone0: 
Trip4[type=1,temp=9]:trend=0,throttle=0
[ 1366.604869] thermal cooling_device1: cur_state=0, 3, 0, throttle: 0
[ 1366.604879] thermal cooling_device1: CUR_state=0, 3, 0, throttle: 0
[ 1366.604889] thermal cooling_device1: old_target=-1, target=-1
[ 1366.604901] thermal cooling_device2: cur_state=0, 3, 0, throttle: 0
[ 1366.604911] thermal cooling_device2: CUR_state=0, 3, 0, throttle: 0
[ 1366.604921] thermal cooling_device2: old_target=-1, target=-1
[ 1366.604935] thermal thermal_zone0: 
Trip5[type=1,temp=11]:trend=0,throttle=0
[ 1366.604946] thermal cooling_device1: cur_state=0, 7, 7, throttle: 0
[ 1366.604957] thermal cooling_device1: CUR_state=0, 7, 7, throttle: 0
[ 1366.604967] thermal cooling_device1: old_target=-1, target=-1
[ 1366.604977] thermal cooling_device2: cur_state=0, 11, 11, throttle: 0
[ 1366.604988] thermal cooling_device2: CUR_state=0, 11, 11, throttle: 0
[ 1366.604997] thermal cooling_device2: old_target=-1, target=-1

After this, the temperature in zone0 rises but cooling devices do not
receive any pokes...

Did I make some mistake or this is thermal issue?


[0] http://www.spinics.net/lists/arm-kernel/msg482748.html


Best regards,
Krzysztof


Krzysztof Kozlowski (3):
  ARM: dts: Add cooling levels for CPUs on exynos5420
  ARM: dts: Add cooling levels for CPUs on exynos5422/5800
  ARM: dts: Don't overheat the Odroid XU3-Lite on high load

 arch/arm/boot/dts/exynos5420-cpus.dtsi|  6 
 arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 41 +++
 arch/arm/boot/dts/exynos5422-cpus.dtsi|  6 
 3 files changed, 53 insertions(+)

-- 
2.5.0

[RFC 2/3] ARM: dts: Add cooling levels for CPUs on exynos5422/5800

[Krzysztof Kozlowski]

On Exynos5422 and Exynos5800 we support 12 cpufreq steps (200-1300 MHz) for 
LITTLE
and 18 steps for big core (200-1700 MHz). Add respective cooling cells.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos5422-cpus.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi 
b/arch/arm/boot/dts/exynos5422-cpus.dtsi
index 9b46b9fbac4e..858bb7f57d76 100644
--- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -32,6 +32,9 @@
clock-frequency = <10>;
cci-control-port = <_control0>;
operating-points-v2 = <_a7_opp_table>;
+   cooling-min-level = <0>;
+   cooling-max-level = <11>;
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu1: cpu@101 {
@@ -69,6 +72,9 @@
clock-frequency = <18>;
cci-control-port = <_control1>;
operating-points-v2 = <_a15_opp_table>;
+   cooling-min-level = <0>;
+   cooling-max-level = <15>;
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu5: cpu@1 {
-- 
2.5.0

[RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high load

[Krzysztof Kozlowski]

After adding cpufreq-dt support to Exynos542x, the Odroid XU3-Lite can
be easily overheated when launching eight CPU-intensive tasks:
thermal thermal_zone3: critical temperature reached(121 C),shutting down

This seems to be specific to Odroid XU3-Lite board which officially
supports lower frequencies than regular XU3 or XU4. When working at
maximum CPU speed (1800 MHz big and 1300 MHz LITTLE) in warmer place for
longer time, the fan fails to cool down the board and it reaches
critical temperature.

Add CPU cooling to Exynos5422/5800 to fix this issue. When reaching 95
degrees of Celsius, the board will slow down by 3 steps (around
1400/1000 MHz). When reaching 110 degrees of Celsius go to 600 MHz.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 41 +++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi 
b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
index 2b289d7c0d13..66073ce29aee 100644
--- a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
@@ -34,6 +34,16 @@
hysteresis = <5000>; /* millicelsius */
type = "active";
};
+   cpu_alert3: cpu-alert-3 {
+   temperature = <95000>; /* millicelsius 
*/
+   hysteresis = <5000>; /* millicelsius */
+   type = "passive";
+   };
+   cpu_alert4: cpu-alert-4 {
+   temperature = <11>; /* millicelsius 
*/
+   hysteresis = <5000>; /* millicelsius */
+   type = "passive";
+   };
cpu_crit0: cpu-crit-0 {
temperature = <12>; /* millicelsius 
*/
hysteresis = <0>; /* millicelsius */
@@ -53,6 +63,37 @@
 trip = <_alert2>;
 cooling-device = < 2 3>;
};
+
+   /*
+* When reaching cpu_alert3, reduce CPU
+* by 3 steps. On Exynos5422/5800 that would
+* be: 1400 MHz and 1000 MHz.
+*/
+   map3 {
+trip = <_alert3>;
+cooling-device = < 3 3>;
+   };
+   map4 {
+trip = <_alert3>;
+cooling-device = < 3 3>;
+   };
+
+   /*
+* When reaching cpu_alert4, reduce CPU
+* to 600 MHz (11 steps for big, 7 steps for
+* LITTLE).
+* Exynos5420 has less OPPs and reversed
+* numbering of CPUs (big/LITTLE) so this
+* would not match.
+*/
+   map5 {
+trip = <_alert4>;
+cooling-device = < 7 7>;
+   };
+   map6 {
+trip = <_alert4>;
+cooling-device = < 11 11>;
+   };
};
};
};
-- 
2.5.0

[RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high load

[Krzysztof Kozlowski]

After adding cpufreq-dt support to Exynos542x, the Odroid XU3-Lite can
be easily overheated when launching eight CPU-intensive tasks:
thermal thermal_zone3: critical temperature reached(121 C),shutting down

This seems to be specific to Odroid XU3-Lite board which officially
supports lower frequencies than regular XU3 or XU4. When working at
maximum CPU speed (1800 MHz big and 1300 MHz LITTLE) in warmer place for
longer time, the fan fails to cool down the board and it reaches
critical temperature.

Add CPU cooling to Exynos5422/5800 to fix this issue. When reaching 95
degrees of Celsius, the board will slow down by 3 steps (around
1400/1000 MHz). When reaching 110 degrees of Celsius go to 600 MHz.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 41 +++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi 
b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
index 2b289d7c0d13..66073ce29aee 100644
--- a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
@@ -34,6 +34,16 @@
hysteresis = <5000>; /* millicelsius */
type = "active";
};
+   cpu_alert3: cpu-alert-3 {
+   temperature = <95000>; /* millicelsius 
*/
+   hysteresis = <5000>; /* millicelsius */
+   type = "passive";
+   };
+   cpu_alert4: cpu-alert-4 {
+   temperature = <11>; /* millicelsius 
*/
+   hysteresis = <5000>; /* millicelsius */
+   type = "passive";
+   };
cpu_crit0: cpu-crit-0 {
temperature = <12>; /* millicelsius 
*/
hysteresis = <0>; /* millicelsius */
@@ -53,6 +63,37 @@
 trip = <_alert2>;
 cooling-device = < 2 3>;
};
+
+   /*
+* When reaching cpu_alert3, reduce CPU
+* by 3 steps. On Exynos5422/5800 that would
+* be: 1400 MHz and 1000 MHz.
+*/
+   map3 {
+trip = <_alert3>;
+cooling-device = < 3 3>;
+   };
+   map4 {
+trip = <_alert3>;
+cooling-device = < 3 3>;
+   };
+
+   /*
+* When reaching cpu_alert4, reduce CPU
+* to 600 MHz (11 steps for big, 7 steps for
+* LITTLE).
+* Exynos5420 has less OPPs and reversed
+* numbering of CPUs (big/LITTLE) so this
+* would not match.
+*/
+   map5 {
+trip = <_alert4>;
+cooling-device = < 7 7>;
+   };
+   map6 {
+trip = <_alert4>;
+cooling-device = < 11 11>;
+   };
};
};
};
-- 
2.5.0

[PATCH 2/2] drm/panel: Add support for LG lp120up1 panel

[Jitao Shi]

The LG lp120up1 panel is a 12.0" 1920x1280 panel,
which can be supported by the simple panel driver

Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/panel/panel-simple.c |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f88a631..2030c37 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -982,6 +982,29 @@ static const struct panel_desc lg_lb070wv8 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
 };
 
+static const struct drm_display_mode lg_lp120up1_mode = {
+   .clock = 162300,
+   .hdisplay = 1920,
+   .hsync_start = 1920 + 40,
+   .hsync_end = 1920 + 40 + 40,
+   .htotal = 1920 + 40 + 40+ 80,
+   .vdisplay = 1280,
+   .vsync_start = 1280 + 4,
+   .vsync_end = 1280 + 4 + 4,
+   .vtotal = 1280 + 4 + 4 + 12,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc lg_lp120up1 = {
+   .modes = _lp120up1_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 267,
+   .height = 183,
+   },
+};
+
 static const struct drm_display_mode lg_lp129qe_mode = {
.clock = 285250,
.hdisplay = 2560,
@@ -1256,6 +1279,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "lg,lb070wv8",
.data = _lb070wv8,
}, {
+   .compatible = "lg,lp120up1",
+   .data = _lp120up1,
+   }, {
.compatible = "lg,lp129qe",
.data = _lp129qe,
}, {
-- 
1.7.9.5

[PATCH 1/2] dt-bindings: Add LG lp120up1 panel bindings

[Jitao Shi]

Add documentation for lp120up1 panel

Signed-off-by: Jitao Shi 
---
 .../bindings/display/panel/lg,lp120up1.txt |7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt

diff --git a/Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt 
b/Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt
new file mode 100644
index 000..ff0b6c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt
@@ -0,0 +1,7 @@
+LG 12.0" (1920x1280 pixels) TFT LCD panel
+
+Required properties:
+- compatible: should be "lg,lp120up1"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
1.7.9.5

[PATCH 2/2] drm/panel: Add support for LG lp120up1 panel

[Jitao Shi]

The LG lp120up1 panel is a 12.0" 1920x1280 panel,
which can be supported by the simple panel driver

Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/panel/panel-simple.c |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f88a631..2030c37 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -982,6 +982,29 @@ static const struct panel_desc lg_lb070wv8 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
 };
 
+static const struct drm_display_mode lg_lp120up1_mode = {
+   .clock = 162300,
+   .hdisplay = 1920,
+   .hsync_start = 1920 + 40,
+   .hsync_end = 1920 + 40 + 40,
+   .htotal = 1920 + 40 + 40+ 80,
+   .vdisplay = 1280,
+   .vsync_start = 1280 + 4,
+   .vsync_end = 1280 + 4 + 4,
+   .vtotal = 1280 + 4 + 4 + 12,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc lg_lp120up1 = {
+   .modes = _lp120up1_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 267,
+   .height = 183,
+   },
+};
+
 static const struct drm_display_mode lg_lp129qe_mode = {
.clock = 285250,
.hdisplay = 2560,
@@ -1256,6 +1279,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "lg,lb070wv8",
.data = _lb070wv8,
}, {
+   .compatible = "lg,lp120up1",
+   .data = _lp120up1,
+   }, {
.compatible = "lg,lp129qe",
.data = _lp129qe,
}, {
-- 
1.7.9.5

[PATCH 1/2] dt-bindings: Add LG lp120up1 panel bindings

[Jitao Shi]

Add documentation for lp120up1 panel

Signed-off-by: Jitao Shi 
---
 .../bindings/display/panel/lg,lp120up1.txt |7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt

diff --git a/Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt 
b/Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt
new file mode 100644
index 000..ff0b6c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt
@@ -0,0 +1,7 @@
+LG 12.0" (1920x1280 pixels) TFT LCD panel
+
+Required properties:
+- compatible: should be "lg,lp120up1"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
1.7.9.5

[PATCH] staging: xgifb: Fix comment style

[Bo YU]

Fix comments to use trailing */ on separate lines.

Signed-off-by: YU BO 
---
  drivers/staging/xgifb/vb_init.c |   10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/xgifb/vb_init.c b/drivers/staging/xgifb/vb_init.c
index 26b539b..c7f02c7 100644
--- a/drivers/staging/xgifb/vb_init.c
+++ b/drivers/staging/xgifb/vb_init.c
@@ -699,11 +699,11 @@ static void XGINew_CheckChannel(struct
xgi_hw_device_info *HwDeviceExtension,
  break;
  case XG42:
  /*
- XG42 SR14 D[3] Reserve
- D[2] = 1, Dual Channel
- = 0, Single Channel
-
- It's Different from Other XG40 Series.
+ * XG42 SR14 D[3] Reserve
+ * D[2] = 1, Dual Channel
+ * = 0, Single Channel
+ *
+ * It's Different from Other XG40 Series.
  */
  if (XGINew_CheckFrequence(pVBInfo) == 1) { /* DDRII, DDR2x */
  pVBInfo->ram_bus = 32; /* 32 bits */
--
1.7.10.4


--
Best Regards

[PATCH] staging: xgifb: Fix comment style

[Bo YU]

Fix comments to use trailing */ on separate lines.

Signed-off-by: YU BO 
---
  drivers/staging/xgifb/vb_init.c |   10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/xgifb/vb_init.c b/drivers/staging/xgifb/vb_init.c
index 26b539b..c7f02c7 100644
--- a/drivers/staging/xgifb/vb_init.c
+++ b/drivers/staging/xgifb/vb_init.c
@@ -699,11 +699,11 @@ static void XGINew_CheckChannel(struct
xgi_hw_device_info *HwDeviceExtension,
  break;
  case XG42:
  /*
- XG42 SR14 D[3] Reserve
- D[2] = 1, Dual Channel
- = 0, Single Channel
-
- It's Different from Other XG40 Series.
+ * XG42 SR14 D[3] Reserve
+ * D[2] = 1, Dual Channel
+ * = 0, Single Channel
+ *
+ * It's Different from Other XG40 Series.
  */
  if (XGINew_CheckFrequence(pVBInfo) == 1) { /* DDRII, DDR2x */
  pVBInfo->ram_bus = 32; /* 32 bits */
--
1.7.10.4


--
Best Regards

[PATCH] eCryptfs: fix typos in comment

[Wei Yuan]

Signed-off-by: Weiyuan 
---
 fs/ecryptfs/crypto.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index 80d6901..d47a7d4 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -44,7 +44,7 @@
  * ecryptfs_to_hex
  * @dst: Buffer to take hex character representation of contents of
  *   src; must be at least of size (src_size * 2)
- * @src: Buffer to be converted to a hex string respresentation
+ * @src: Buffer to be converted to a hex string representation
  * @src_size: number of bytes to convert
  */
 void ecryptfs_to_hex(char *dst, char *src, size_t src_size)
@@ -59,7 +59,7 @@ void ecryptfs_to_hex(char *dst, char *src, size_t src_size)
  * ecryptfs_from_hex
  * @dst: Buffer to take the bytes from src hex; must be at least of
  *   size (src_size / 2)
- * @src: Buffer to be converted from a hex string respresentation to raw value
+ * @src: Buffer to be converted from a hex string representation to raw value
  * @dst_size: size of dst buffer, or number of hex characters pairs to convert
  */
 void ecryptfs_from_hex(char *dst, char *src, int dst_size)
-- 
2.1.0

[PATCH] eCryptfs: fix typos in comment

[Wei Yuan]

Signed-off-by: Weiyuan 
---
 fs/ecryptfs/crypto.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index 80d6901..d47a7d4 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -44,7 +44,7 @@
  * ecryptfs_to_hex
  * @dst: Buffer to take hex character representation of contents of
  *   src; must be at least of size (src_size * 2)
- * @src: Buffer to be converted to a hex string respresentation
+ * @src: Buffer to be converted to a hex string representation
  * @src_size: number of bytes to convert
  */
 void ecryptfs_to_hex(char *dst, char *src, size_t src_size)
@@ -59,7 +59,7 @@ void ecryptfs_to_hex(char *dst, char *src, size_t src_size)
  * ecryptfs_from_hex
  * @dst: Buffer to take the bytes from src hex; must be at least of
  *   size (src_size / 2)
- * @src: Buffer to be converted from a hex string respresentation to raw value
+ * @src: Buffer to be converted from a hex string representation to raw value
  * @dst_size: size of dst buffer, or number of hex characters pairs to convert
  */
 void ecryptfs_from_hex(char *dst, char *src, int dst_size)
-- 
2.1.0

Re: [PATCH 4/6] pinctrl: rockchip: add bindings for rk3399 pinctrl

[Heiko Stuebner]

Hi Jianqun,

Am Mittwoch, 17. Februar 2016, 09:53:10 schrieb jianqun.xu:
> From: Xu Jianqun 
> 
> Add devicetree bindings for pinctrl found on rk3399
> processors from rockchip.
> 
> Signed-off-by: Xu Jianqun 
> ---
>  Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index
> 0cd701b..c68b955 100644
> --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> @@ -22,7 +22,7 @@ Required properties for iomux controller:
>- compatible: one of "rockchip,rk2928-pinctrl",
> "rockchip,rk3066a-pinctrl" "rockchip,rk3066b-pinctrl",
> "rockchip,rk3188-pinctrl"
>  "rockchip,rk3228-pinctrl", "rockchip,rk3288-pinctrl"
> -"rockchip,rk3368-pinctrl"
> +"rockchip,rk3368-pinctrl", "rockchip,rk3399-pinctrl"
>- rockchip,grf: phandle referencing a syscon providing the
>"general register files"

that is already contained in David's core pinctrl patch that already got 
applied to the pinctrl tree.


Heiko

Re: [PATCH 4/6] pinctrl: rockchip: add bindings for rk3399 pinctrl

[Heiko Stuebner]

Hi Jianqun,

Am Mittwoch, 17. Februar 2016, 09:53:10 schrieb jianqun.xu:
> From: Xu Jianqun 
> 
> Add devicetree bindings for pinctrl found on rk3399
> processors from rockchip.
> 
> Signed-off-by: Xu Jianqun 
> ---
>  Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index
> 0cd701b..c68b955 100644
> --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> @@ -22,7 +22,7 @@ Required properties for iomux controller:
>- compatible: one of "rockchip,rk2928-pinctrl",
> "rockchip,rk3066a-pinctrl" "rockchip,rk3066b-pinctrl",
> "rockchip,rk3188-pinctrl"
>  "rockchip,rk3228-pinctrl", "rockchip,rk3288-pinctrl"
> -"rockchip,rk3368-pinctrl"
> +"rockchip,rk3368-pinctrl", "rockchip,rk3399-pinctrl"
>- rockchip,grf: phandle referencing a syscon providing the
>"general register files"

that is already contained in David's core pinctrl patch that already got 
applied to the pinctrl tree.


Heiko

Re: [PATCH] spi/rockchip: Add dt-binding for Rockchip rk3399 spi

[Heiko Stuebner]

Hi Jianqun,

Am Mittwoch, 17. Februar 2016, 08:21:58 schrieb Jianqun Xu:
> 在 16/02/2016 22:37, Heiko Stuebner 写道:
> > Am Dienstag, 16. Februar 2016, 13:22:23 schrieb Mark Brown:
> >> On Tue, Feb 16, 2016 at 05:22:18PM +0800, jianqun.xu wrote:
> >>>   Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
> >>>   1 file changed, 1 insertion(+)
> >> 
> >> I'd expect this to be added to both the driver and the binding document
> >> not just the document.
> > 
> > It seems the driver can still use the rk3066-variant - aka nobody has
> > found specific issues in the rk3399 IP implementation.
> > 
> > Having the more specific IP names already in the dts before actually
> > using them was suggested by devicetree people to not have to exchange
> > everything once specific issues were found.
> > 
> > So right now it's using the fallback-mechanism of binding to the rk3066
> > name, but if some obstacle appears it will only take adding the binding
> > in the driver to make it work (even with old devicetrees).
> 
> Thank you, got it, and I will re-send this patch with the driver patch.

you have me confused now :-) .

That was meant as a reply to Mark's comment, explaining why the double 
compatible and the driver only binding to the rk3066-one right now.


Heiko

Re: [PATCH] spi/rockchip: Add dt-binding for Rockchip rk3399 spi

[Heiko Stuebner]

Hi Jianqun,

Am Mittwoch, 17. Februar 2016, 08:21:58 schrieb Jianqun Xu:
> 在 16/02/2016 22:37, Heiko Stuebner 写道:
> > Am Dienstag, 16. Februar 2016, 13:22:23 schrieb Mark Brown:
> >> On Tue, Feb 16, 2016 at 05:22:18PM +0800, jianqun.xu wrote:
> >>>   Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
> >>>   1 file changed, 1 insertion(+)
> >> 
> >> I'd expect this to be added to both the driver and the binding document
> >> not just the document.
> > 
> > It seems the driver can still use the rk3066-variant - aka nobody has
> > found specific issues in the rk3399 IP implementation.
> > 
> > Having the more specific IP names already in the dts before actually
> > using them was suggested by devicetree people to not have to exchange
> > everything once specific issues were found.
> > 
> > So right now it's using the fallback-mechanism of binding to the rk3066
> > name, but if some obstacle appears it will only take adding the binding
> > in the driver to make it work (even with old devicetrees).
> 
> Thank you, got it, and I will re-send this patch with the driver patch.

you have me confused now :-) .

That was meant as a reply to Mark's comment, explaining why the double 
compatible and the driver only binding to the rk3066-one right now.


Heiko

Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Magnus Damm]

Hi Simon,

On Wed, Feb 17, 2016 at 3:28 PM, Simon Horman  wrote:
> On Wed, Feb 17, 2016 at 11:33:27AM +0900, Magnus Damm wrote:
>> Hi Geert,
>>
>> On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven
>>  wrote:
>> > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm  wrote:
>> >> From: Magnus Damm 
>> >>
>> >> Add documentation for new separate CMT0 and CMT1 DT compatible strings
>> >> for R-Car Gen2. These compat strings allow us to enable CMT1-specific
>> >> features in the driver. The old compat strings will be deprecated in
>> >> the not so distant future.
>> >>
>> >> Signed-off-by: Magnus Damm 
>> >> Acked-by: Geert Uytterhoeven 
>> >> Acked-by: Laurent Pinchart 
>> >> Acked-by: Rob Herring 
>> >> ---
>> >>
>> >>  Changes since V2:
>> >>  - Added Acked-by from Rob
>> >>  - Removed Tested-by tag from DT binding patch - duh!
>> >>
>> >>  Changes since V1:
>> >>  - Added Acked-by and Tested-by from Geert
>> >>  - Added Acked-by from Laurent
>> >>
>> >>  Documentation/devicetree/bindings/timer/renesas,cmt.txt |3 +++
>> >>  1 file changed, 3 insertions(+)
>> >>
>> >> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> >> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> >> 2015-09-17 17:26:57.440513000 +0900
>> >> @@ -36,6 +36,9 @@ Required Properties:
>> >> (CMT1 on sh73a0 and r8a7740)
>> >> This is a fallback for the above renesas,cmt-48-* entries.
>> >>
>> >> +- "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car 
>> >> Gen2.
>> >> +- "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car 
>> >> Gen2.
>> >
>> > (advancing a few months always means more comments ;-)
>>
>> Indeed!
>>
>> > I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead?
>>
>> I have no strong feelings one way or the other, but I agree that
>> aiming to make things more consistent must be good.
>
> FWIW, I agree with Geert's suggestion.
> But I also think it is not particularly important.
>
>> Your proposal makes the fallback match with what we do for a bunch
>> other devices on R-Car Gen2 like:
>> "rcar-gen2-cpg-clocks"
>> "rcar-gen2-scif"
>> But we also seem to have:
>> "pci-rcar-gen2"
>
> Bother, it looks like I got pci backwards :(
>
>> On R-Car Gen3 we seem to have the following per-SoC compat strings:
>> "dmac-r8a7795"
>> "etheravb-r8a7795"
>> "gpio-r8a7795"
>> "scif-r8a7795"
>
> I believe the above are to follow the existing pattern for
> per-SoC compat strings in the same driver, which seems sane.
>
>> But we also have:
>> "r8a7795-cpg-mssr"
>>
>> My only feeling is that it looks a tad odd if we follow
>> ",-" for fallback strings but
>> ",-" for the per-soc binding. Why not
>> using the same order? Maybe this is specified in some document
>> somewhere?
>
> I believe that the problem is a historical one. Perhaps when
> we started adding bindings for our hardware there were no clear
> guidelines. But regardless we ended up with a mix as you describe.

Right, that seems to be the way things have happened.

> In the mean time guidelines have emerged and we (or at least I) have
> agreed with the device tree people (probably Rob) to use the
> ,- format for new bindings. My reading is that
> applies even if it results in fallback and non-fallback bindings for the
> same driver have different orders. Some precedence for this can now be found
> in renesas,rcar-dmac.txt.

Some sort of agreed format sounds good.

Your proposal of ,- sounds good to me.

I'm however slightly more confused by seeing that your example
renesas,rcar-dmac.txt included in renesas-drivers-2016-02-16-v4.5-rc4
does not match the proposed format:

$ grep "renesas," Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
- compatible: "renesas,dmac-", "renesas,rcar-dmac" as fallback.
- "renesas,dmac-r8a7790" (R-Car H2)
- "renesas,dmac-r8a7791" (R-Car M2-W)
- "renesas,dmac-r8a7792" (R-Car V2H)
- "renesas,dmac-r8a7793" (R-Car M2-N)
- "renesas,dmac-r8a7794" (R-Car E2)
- "renesas,dmac-r8a7795" (R-Car H3)
compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
$

> I don't, however, think it applies where we add more soc-specific to a
> driver that already has such bindings. Or new fallback bindings to a driver
> that already has such bindings.

Right, but for rcar-dmac.c there is no matching on per-SoC strings in
the driver so I guess we can pick anything we want?

$ grep "renesas," drivers/dma/sh/rcar-dmac.c
{ .compatible = "renesas,rcar-dmac", },
$

>> I guess your take with "r8a7795-cpg-mssr" above is to follow the same
>> order as for the fallback case? This seems sane to me, and if so then
>> perhaps the per-soc 

Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Magnus Damm]

Hi Simon,

On Wed, Feb 17, 2016 at 3:28 PM, Simon Horman  wrote:
> On Wed, Feb 17, 2016 at 11:33:27AM +0900, Magnus Damm wrote:
>> Hi Geert,
>>
>> On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven
>>  wrote:
>> > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm  wrote:
>> >> From: Magnus Damm 
>> >>
>> >> Add documentation for new separate CMT0 and CMT1 DT compatible strings
>> >> for R-Car Gen2. These compat strings allow us to enable CMT1-specific
>> >> features in the driver. The old compat strings will be deprecated in
>> >> the not so distant future.
>> >>
>> >> Signed-off-by: Magnus Damm 
>> >> Acked-by: Geert Uytterhoeven 
>> >> Acked-by: Laurent Pinchart 
>> >> Acked-by: Rob Herring 
>> >> ---
>> >>
>> >>  Changes since V2:
>> >>  - Added Acked-by from Rob
>> >>  - Removed Tested-by tag from DT binding patch - duh!
>> >>
>> >>  Changes since V1:
>> >>  - Added Acked-by and Tested-by from Geert
>> >>  - Added Acked-by from Laurent
>> >>
>> >>  Documentation/devicetree/bindings/timer/renesas,cmt.txt |3 +++
>> >>  1 file changed, 3 insertions(+)
>> >>
>> >> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> >> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> >> 2015-09-17 17:26:57.440513000 +0900
>> >> @@ -36,6 +36,9 @@ Required Properties:
>> >> (CMT1 on sh73a0 and r8a7740)
>> >> This is a fallback for the above renesas,cmt-48-* entries.
>> >>
>> >> +- "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car 
>> >> Gen2.
>> >> +- "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car 
>> >> Gen2.
>> >
>> > (advancing a few months always means more comments ;-)
>>
>> Indeed!
>>
>> > I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead?
>>
>> I have no strong feelings one way or the other, but I agree that
>> aiming to make things more consistent must be good.
>
> FWIW, I agree with Geert's suggestion.
> But I also think it is not particularly important.
>
>> Your proposal makes the fallback match with what we do for a bunch
>> other devices on R-Car Gen2 like:
>> "rcar-gen2-cpg-clocks"
>> "rcar-gen2-scif"
>> But we also seem to have:
>> "pci-rcar-gen2"
>
> Bother, it looks like I got pci backwards :(
>
>> On R-Car Gen3 we seem to have the following per-SoC compat strings:
>> "dmac-r8a7795"
>> "etheravb-r8a7795"
>> "gpio-r8a7795"
>> "scif-r8a7795"
>
> I believe the above are to follow the existing pattern for
> per-SoC compat strings in the same driver, which seems sane.
>
>> But we also have:
>> "r8a7795-cpg-mssr"
>>
>> My only feeling is that it looks a tad odd if we follow
>> ",-" for fallback strings but
>> ",-" for the per-soc binding. Why not
>> using the same order? Maybe this is specified in some document
>> somewhere?
>
> I believe that the problem is a historical one. Perhaps when
> we started adding bindings for our hardware there were no clear
> guidelines. But regardless we ended up with a mix as you describe.

Right, that seems to be the way things have happened.

> In the mean time guidelines have emerged and we (or at least I) have
> agreed with the device tree people (probably Rob) to use the
> ,- format for new bindings. My reading is that
> applies even if it results in fallback and non-fallback bindings for the
> same driver have different orders. Some precedence for this can now be found
> in renesas,rcar-dmac.txt.

Some sort of agreed format sounds good.

Your proposal of ,- sounds good to me.

I'm however slightly more confused by seeing that your example
renesas,rcar-dmac.txt included in renesas-drivers-2016-02-16-v4.5-rc4
does not match the proposed format:

$ grep "renesas," Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
- compatible: "renesas,dmac-", "renesas,rcar-dmac" as fallback.
- "renesas,dmac-r8a7790" (R-Car H2)
- "renesas,dmac-r8a7791" (R-Car M2-W)
- "renesas,dmac-r8a7792" (R-Car V2H)
- "renesas,dmac-r8a7793" (R-Car M2-N)
- "renesas,dmac-r8a7794" (R-Car E2)
- "renesas,dmac-r8a7795" (R-Car H3)
compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
$

> I don't, however, think it applies where we add more soc-specific to a
> driver that already has such bindings. Or new fallback bindings to a driver
> that already has such bindings.

Right, but for rcar-dmac.c there is no matching on per-SoC strings in
the driver so I guess we can pick anything we want?

$ grep "renesas," drivers/dma/sh/rcar-dmac.c
{ .compatible = "renesas,rcar-dmac", },
$

>> I guess your take with "r8a7795-cpg-mssr" above is to follow the same
>> order as for the fallback case? This seems sane to me, and if so then
>> perhaps the per-soc compat strings for the CMT should also be updated?
>> Same for other devices too then, like the recently added
>> "dmac-r8a7795"?
>
> From my point of view it would be nice to clean things up and
> 

perf object code reading test crashes

[Steven Noonan]

I oddly didn't run into this issue on every machine I tried, but
there's some issues here:

$ sudo perf test 21
21: Test object code reading :***
Error in `perf': corrupted double-linked list: 0x023ffcd0 ***
=== Backtrace: =
/usr/lib/libc.so.6(+0x72055)[0x7f25be0f3055]
/usr/lib/libc.so.6(+0x779b6)[0x7f25be0f89b6]
/usr/lib/libc.so.6(+0x7a0ed)[0x7f25be0fb0ed]
/usr/lib/libc.so.6(__libc_calloc+0xba)[0x7f25be0fceda]
perf(parse_events_lex_init_extra+0x38)[0x4cfff8]
perf(parse_events+0x55)[0x4a0615]
perf(perf_evlist__config+0xcf)[0x4eeb2f]
perf[0x479f82]
perf(test__code_reading+0x1e)[0x47ad4e]
perf(cmd_test+0x5dd)[0x46452d]
perf[0x47f4e3]
perf(main+0x603)[0x42c723]
/usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7f25be0a1610]
perf(_start+0x29)[0x42c859]
=== Memory map: 
0040-0068d000 r-xp  08:03 2384296
  /usr/bin/perf
0088d000-008a1000 r--p 0028d000 08:03 2384296
  /usr/bin/perf
008a1000-008c2000 rw-p 002a1000 08:03 2384296
  /usr/bin/perf
008c2000-0194f000 rw-p  00:00 0
02193000-021b4000 rw-p  00:00 0  [heap]
021b4000-0254a000 rw-p  00:00 0  [heap]
7f25b800-7f25b8021000 rw-p  00:00 0
7f25b8021000-7f25bc00 ---p  00:00 0
7f25bcdff000-7f25bce15000 r-xp  08:03 2378588
  /usr/lib/libgcc_s.so.1
7f25bce15000-7f25bd014000 ---p 00016000 08:03 2378588
  /usr/lib/libgcc_s.so.1
7f25bd014000-7f25bd015000 rw-p 00015000 08:03 2378588
  /usr/lib/libgcc_s.so.1
7f25bd015000-7f25bd017000 r-xp  08:03 2361423
  /usr/lib/libutil-2.22.so
7f25bd017000-7f25bd216000 ---p 2000 08:03 2361423
  /usr/lib/libutil-2.22.so
7f25bd216000-7f25bd217000 r--p 1000 08:03 2361423
  /usr/lib/libutil-2.22.so
7f25bd217000-7f25bd218000 rw-p 2000 08:03 2361423
  /usr/lib/libutil-2.22.so
7f25bd218000-7f25bd22 r-xp  08:03 2361358
  /usr/lib/libcrypt-2.22.so
7f25bd22-7f25bd42 ---p 8000 08:03 2361358
  /usr/lib/libcrypt-2.22.so
7f25bd42-7f25bd421000 r--p 8000 08:03 2361358
  /usr/lib/libcrypt-2.22.so
7f25bd421000-7f25bd422000 rw-p 9000 08:03 2361358
  /usr/lib/libcrypt-2.22.so
7f25bd422000-7f25bd45 rw-p  00:00 0
7f25bd45-7f25bd45f000 r-xp  08:03 2365752
  /usr/lib/libbz2.so.1.0.6
7f25bd45f000-7f25bd65e000 ---p f000 08:03 2365752
  /usr/lib/libbz2.so.1.0.6
7f25bd65e000-7f25bd66 rw-p e000 08:03 2365752
  /usr/lib/libbz2.so.1.0.6
7f25bd66-7f25bd66a000 r-xp  08:03 2379940
  /usr/lib/libnuma.so.1.0.0
7f25bd66a000-7f25bd86a000 ---p a000 08:03 2379940
  /usr/lib/libnuma.so.1.0.0
7f25bd86a000-7f25bd86b000 r--p a000 08:03 2379940
  /usr/lib/libnuma.so.1.0.0
7f25bd86b000-7f25bd86c000 rw-p b000 08:03 2379940
  /usr/lib/libnuma.so.1.0.0
7f25bd86c000-7f25bd891000 r-xp  08:03 2365772
  /usr/lib/liblzma.so.5.2.2
7f25bd891000-7f25bda9 ---p 00025000 08:03 2365772
  /usr/lib/liblzma.so.5.2.2
7f25bda9-7f25bda91000 r--p 00024000 08:03 2365772
  /usr/lib/liblzma.so.5.2.2
7f25bda91000-7f25bda92000 rw-p 00025000 08:03 2365772
  /usr/lib/liblzma.so.5.2.2
7f25bda92000-7f25bdaa7000 r-xp  08:03 2365728
  /usr/lib/libz.so.1.2.8
7f25bdaa7000-7f25bdca6000 ---p 00015000 08:03 2365728
  /usr/lib/libz.so.1.2.8
7f25bdca6000-7f25bdca7000 r--p 00014000 08:03 2365728
  /usr/lib/libz.so.1.2.8
7f25bdca7000-7f25bdca8000 rw-p 00015000 08:03 2365728
  /usr/lib/libz.so.1.2.8
7f25bdca8000-7f25bde33000 r-xp  08:03 2380612
  /usr/lib/libpython2.7.so.1.0
7f25bde33000-7f25be032000 ---p 0018b000 08:03 2380612
  /usr/lib/libpython2.7.so.1.0
7f25be032000-7f25be034000 r--p 0018a000 08:03 2380612
  /usr/lib/libpython2.7.so.1.0
7f25be034000-7f25be072000 rw-p 0018c000 08:03 2380612
  /usr/lib/libpython2.7.so.1.0
7f25be072000-7f25be081000 rw-p  00:00 0
7f25be081000-7f25be21b000 r-xp  08:03 2361437
  /usr/lib/libc-2.22.so
7f25be21b000-7f25be41b000 ---p 0019a000 08:03 2361437
  /usr/lib/libc-2.22.so
7f25be41b000-7f25be41f000 r--p 0019a000 08:03 2361437
  /usr/lib/libc-2.22.so
7f25be41f000-7f25be421000 rw-p 0019e000 08:03 2361437
  /usr/lib/libc-2.22.so
7f25be421000-7f25be425000 rw-p  00:00 0
7f25be425000-7f25be5ff000 r-xp  08:03 2367396
  /usr/lib/perl5/core_perl/CORE/libperl.so
7f25be5ff000-7f25be7ff000 ---p 001da000 08:03 2367396
  /usr/lib/perl5/core_perl/CORE/libperl.so
7f25be7ff000-7f25be804000 r--p 001da000 08:03 2367396
  /usr/lib/perl5/core_perl/CORE/libperl.so
7f25be804000-7f25be808000 rw-p 001df000 08:03 2367396
  /usr/lib/perl5/core_perl/CORE/libperl.so
7f25be808000-7f25be905000 r-xp  08:03 2392491
  /usr/lib/libslang.so.2.3.0
7f25be905000-7f25beb04000 ---p 000fd000 08:03 2392491
  /usr/lib/libslang.so.2.3.0
7f25beb04000-7f25beb09000 r--p 000fc000 08:03 2392491
  /usr/lib/libslang.so.2.3.0
7f25beb09000-7f25beb22000 rw-p 00101000 08:03 2392491
  /usr/lib/libslang.so.2.3.0
7f25beb22000-7f25beb77000 rw-p  00:00 0

perf object code reading test crashes

[Steven Noonan]

I oddly didn't run into this issue on every machine I tried, but
there's some issues here:

$ sudo perf test 21
21: Test object code reading :***
Error in `perf': corrupted double-linked list: 0x023ffcd0 ***
=== Backtrace: =
/usr/lib/libc.so.6(+0x72055)[0x7f25be0f3055]
/usr/lib/libc.so.6(+0x779b6)[0x7f25be0f89b6]
/usr/lib/libc.so.6(+0x7a0ed)[0x7f25be0fb0ed]
/usr/lib/libc.so.6(__libc_calloc+0xba)[0x7f25be0fceda]
perf(parse_events_lex_init_extra+0x38)[0x4cfff8]
perf(parse_events+0x55)[0x4a0615]
perf(perf_evlist__config+0xcf)[0x4eeb2f]
perf[0x479f82]
perf(test__code_reading+0x1e)[0x47ad4e]
perf(cmd_test+0x5dd)[0x46452d]
perf[0x47f4e3]
perf(main+0x603)[0x42c723]
/usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7f25be0a1610]
perf(_start+0x29)[0x42c859]
=== Memory map: 
0040-0068d000 r-xp  08:03 2384296
  /usr/bin/perf
0088d000-008a1000 r--p 0028d000 08:03 2384296
  /usr/bin/perf
008a1000-008c2000 rw-p 002a1000 08:03 2384296
  /usr/bin/perf
008c2000-0194f000 rw-p  00:00 0
02193000-021b4000 rw-p  00:00 0  [heap]
021b4000-0254a000 rw-p  00:00 0  [heap]
7f25b800-7f25b8021000 rw-p  00:00 0
7f25b8021000-7f25bc00 ---p  00:00 0
7f25bcdff000-7f25bce15000 r-xp  08:03 2378588
  /usr/lib/libgcc_s.so.1
7f25bce15000-7f25bd014000 ---p 00016000 08:03 2378588
  /usr/lib/libgcc_s.so.1
7f25bd014000-7f25bd015000 rw-p 00015000 08:03 2378588
  /usr/lib/libgcc_s.so.1
7f25bd015000-7f25bd017000 r-xp  08:03 2361423
  /usr/lib/libutil-2.22.so
7f25bd017000-7f25bd216000 ---p 2000 08:03 2361423
  /usr/lib/libutil-2.22.so
7f25bd216000-7f25bd217000 r--p 1000 08:03 2361423
  /usr/lib/libutil-2.22.so
7f25bd217000-7f25bd218000 rw-p 2000 08:03 2361423
  /usr/lib/libutil-2.22.so
7f25bd218000-7f25bd22 r-xp  08:03 2361358
  /usr/lib/libcrypt-2.22.so
7f25bd22-7f25bd42 ---p 8000 08:03 2361358
  /usr/lib/libcrypt-2.22.so
7f25bd42-7f25bd421000 r--p 8000 08:03 2361358
  /usr/lib/libcrypt-2.22.so
7f25bd421000-7f25bd422000 rw-p 9000 08:03 2361358
  /usr/lib/libcrypt-2.22.so
7f25bd422000-7f25bd45 rw-p  00:00 0
7f25bd45-7f25bd45f000 r-xp  08:03 2365752
  /usr/lib/libbz2.so.1.0.6
7f25bd45f000-7f25bd65e000 ---p f000 08:03 2365752
  /usr/lib/libbz2.so.1.0.6
7f25bd65e000-7f25bd66 rw-p e000 08:03 2365752
  /usr/lib/libbz2.so.1.0.6
7f25bd66-7f25bd66a000 r-xp  08:03 2379940
  /usr/lib/libnuma.so.1.0.0
7f25bd66a000-7f25bd86a000 ---p a000 08:03 2379940
  /usr/lib/libnuma.so.1.0.0
7f25bd86a000-7f25bd86b000 r--p a000 08:03 2379940
  /usr/lib/libnuma.so.1.0.0
7f25bd86b000-7f25bd86c000 rw-p b000 08:03 2379940
  /usr/lib/libnuma.so.1.0.0
7f25bd86c000-7f25bd891000 r-xp  08:03 2365772
  /usr/lib/liblzma.so.5.2.2
7f25bd891000-7f25bda9 ---p 00025000 08:03 2365772
  /usr/lib/liblzma.so.5.2.2
7f25bda9-7f25bda91000 r--p 00024000 08:03 2365772
  /usr/lib/liblzma.so.5.2.2
7f25bda91000-7f25bda92000 rw-p 00025000 08:03 2365772
  /usr/lib/liblzma.so.5.2.2
7f25bda92000-7f25bdaa7000 r-xp  08:03 2365728
  /usr/lib/libz.so.1.2.8
7f25bdaa7000-7f25bdca6000 ---p 00015000 08:03 2365728
  /usr/lib/libz.so.1.2.8
7f25bdca6000-7f25bdca7000 r--p 00014000 08:03 2365728
  /usr/lib/libz.so.1.2.8
7f25bdca7000-7f25bdca8000 rw-p 00015000 08:03 2365728
  /usr/lib/libz.so.1.2.8
7f25bdca8000-7f25bde33000 r-xp  08:03 2380612
  /usr/lib/libpython2.7.so.1.0
7f25bde33000-7f25be032000 ---p 0018b000 08:03 2380612
  /usr/lib/libpython2.7.so.1.0
7f25be032000-7f25be034000 r--p 0018a000 08:03 2380612
  /usr/lib/libpython2.7.so.1.0
7f25be034000-7f25be072000 rw-p 0018c000 08:03 2380612
  /usr/lib/libpython2.7.so.1.0
7f25be072000-7f25be081000 rw-p  00:00 0
7f25be081000-7f25be21b000 r-xp  08:03 2361437
  /usr/lib/libc-2.22.so
7f25be21b000-7f25be41b000 ---p 0019a000 08:03 2361437
  /usr/lib/libc-2.22.so
7f25be41b000-7f25be41f000 r--p 0019a000 08:03 2361437
  /usr/lib/libc-2.22.so
7f25be41f000-7f25be421000 rw-p 0019e000 08:03 2361437
  /usr/lib/libc-2.22.so
7f25be421000-7f25be425000 rw-p  00:00 0
7f25be425000-7f25be5ff000 r-xp  08:03 2367396
  /usr/lib/perl5/core_perl/CORE/libperl.so
7f25be5ff000-7f25be7ff000 ---p 001da000 08:03 2367396
  /usr/lib/perl5/core_perl/CORE/libperl.so
7f25be7ff000-7f25be804000 r--p 001da000 08:03 2367396
  /usr/lib/perl5/core_perl/CORE/libperl.so
7f25be804000-7f25be808000 rw-p 001df000 08:03 2367396
  /usr/lib/perl5/core_perl/CORE/libperl.so
7f25be808000-7f25be905000 r-xp  08:03 2392491
  /usr/lib/libslang.so.2.3.0
7f25be905000-7f25beb04000 ---p 000fd000 08:03 2392491
  /usr/lib/libslang.so.2.3.0
7f25beb04000-7f25beb09000 r--p 000fc000 08:03 2392491
  /usr/lib/libslang.so.2.3.0
7f25beb09000-7f25beb22000 rw-p 00101000 08:03 2392491
  /usr/lib/libslang.so.2.3.0
7f25beb22000-7f25beb77000 rw-p  00:00 0

Re: [lustre-devel] [PATCH] staging: lustre: Fixed the parenthesis

[shalin mehta]

Hello,

Should I send this patch again due the spelling mistake in the patch
description?

Thanks,
Shalin

On Mon, Feb 15, 2016 at 6:51 PM, Drokin, Oleg  wrote:
>
> On Feb 14, 2016, at 10:37 PM, Shalin Mehta wrote:
>
>> The parentehsis are fixed in the macro for the ldlm lock to set and
>> clear the flags.
>>
>> Signed-off-by: Shalin Mehta 
>> ---
>> drivers/staging/lustre/lustre/include/lustre_dlm_flags.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h 
>> b/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h
>> index 0d3ed87..4f9e9ad 100644
>> --- a/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h
>> +++ b/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h
>> @@ -365,10 +365,10 @@
>> #define LDLM_TEST_FLAG(_l, _b)(((_l)->l_flags & (_b)) != 0)
>>
>> /** set a ldlm_lock flag bit */
>> -#define LDLM_SET_FLAG(_l, _b) (((_l)->l_flags |= (_b))
>> +#define LDLM_SET_FLAG(_l, _b) ((_l)->l_flags |= (_b))
>>
>> /** clear a ldlm_lock flag bit */
>> -#define LDLM_CLEAR_FLAG(_l, _b)   (((_l)->l_flags &= ~(_b))
>> +#define LDLM_CLEAR_FLAG(_l, _b)   ((_l)->l_flags &= ~(_b))
>>
>> /** Mask of flags inherited from parent lock when doing intents. */
>> #define LDLM_INHERIT_FLAGSLDLM_FL_INHERIT_MASK
>
> Acked-by: Oleg Drokin 
>

Re: [lustre-devel] [PATCH] staging: lustre: Fixed the parenthesis

[shalin mehta]

Hello,

Should I send this patch again due the spelling mistake in the patch
description?

Thanks,
Shalin

On Mon, Feb 15, 2016 at 6:51 PM, Drokin, Oleg  wrote:
>
> On Feb 14, 2016, at 10:37 PM, Shalin Mehta wrote:
>
>> The parentehsis are fixed in the macro for the ldlm lock to set and
>> clear the flags.
>>
>> Signed-off-by: Shalin Mehta 
>> ---
>> drivers/staging/lustre/lustre/include/lustre_dlm_flags.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h 
>> b/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h
>> index 0d3ed87..4f9e9ad 100644
>> --- a/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h
>> +++ b/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h
>> @@ -365,10 +365,10 @@
>> #define LDLM_TEST_FLAG(_l, _b)(((_l)->l_flags & (_b)) != 0)
>>
>> /** set a ldlm_lock flag bit */
>> -#define LDLM_SET_FLAG(_l, _b) (((_l)->l_flags |= (_b))
>> +#define LDLM_SET_FLAG(_l, _b) ((_l)->l_flags |= (_b))
>>
>> /** clear a ldlm_lock flag bit */
>> -#define LDLM_CLEAR_FLAG(_l, _b)   (((_l)->l_flags &= ~(_b))
>> +#define LDLM_CLEAR_FLAG(_l, _b)   ((_l)->l_flags &= ~(_b))
>>
>> /** Mask of flags inherited from parent lock when doing intents. */
>> #define LDLM_INHERIT_FLAGSLDLM_FL_INHERIT_MASK
>
> Acked-by: Oleg Drokin 
>

[PATCH] mm: remove unnecessary description about a non-exist gfp flag

[Satoru Takeuchi]

Since __GFP_NOACCOUNT is removed by the following commit,
its description is not necessary.

commit 20b5c3039863 ("Revert 'gfp: add __GFP_NOACCOUNT'")

Signed-off-by: Satoru Takeuchi 
---
 include/linux/gfp.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index af1f2b2..7c76a6e 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -101,8 +101,6 @@ struct vm_area_struct;
  *
  * __GFP_NOMEMALLOC is used to explicitly forbid access to emergency reserves.
  *   This takes precedence over the __GFP_MEMALLOC flag if both are set.
- *
- * __GFP_NOACCOUNT ignores the accounting for kmemcg limit enforcement.
  */
 #define __GFP_ATOMIC   ((__force gfp_t)___GFP_ATOMIC)
 #define __GFP_HIGH ((__force gfp_t)___GFP_HIGH)
-- 
2.5.0

[PATCH] mm: remove unnecessary description about a non-exist gfp flag

[Satoru Takeuchi]

Since __GFP_NOACCOUNT is removed by the following commit,
its description is not necessary.

commit 20b5c3039863 ("Revert 'gfp: add __GFP_NOACCOUNT'")

Signed-off-by: Satoru Takeuchi 
---
 include/linux/gfp.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index af1f2b2..7c76a6e 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -101,8 +101,6 @@ struct vm_area_struct;
  *
  * __GFP_NOMEMALLOC is used to explicitly forbid access to emergency reserves.
  *   This takes precedence over the __GFP_MEMALLOC flag if both are set.
- *
- * __GFP_NOACCOUNT ignores the accounting for kmemcg limit enforcement.
  */
 #define __GFP_ATOMIC   ((__force gfp_t)___GFP_ATOMIC)
 #define __GFP_HIGH ((__force gfp_t)___GFP_HIGH)
-- 
2.5.0

Re: [PATCH v3 04/06] devicetree: bindings: Deprecate property, update example

[Simon Horman]

On Tue, Feb 16, 2016 at 04:17:59PM +0900, Magnus Damm wrote:
> From: Magnus Damm 
> 
> Deprecate "renesas,channels-mask" and update the r8a7790 CMT example.
> 
> Signed-off-by: Magnus Damm 
> Acked-by: Geert Uytterhoeven 
> Acked-by: Laurent Pinchart 
> Acked-by: Rob Herring 

Acked-by: Simon Horman 

Re: [PATCH v3 04/06] devicetree: bindings: Deprecate property, update example

[Simon Horman]

On Tue, Feb 16, 2016 at 04:17:59PM +0900, Magnus Damm wrote:
> From: Magnus Damm 
> 
> Deprecate "renesas,channels-mask" and update the r8a7790 CMT example.
> 
> Signed-off-by: Magnus Damm 
> Acked-by: Geert Uytterhoeven 
> Acked-by: Laurent Pinchart 
> Acked-by: Rob Herring 

Acked-by: Simon Horman 

[RFC PATCH] staging/android/ion : fix a race condition in the ion driver

[EunTaik Lee]

There was a use-after-free problem in the ion driver.

The problem is detected as an unaligned access in the
spin lock functions since it uses load exclusive
 instruction. In some cases it corrupts the slub's
free pointer which causes a unaligned access to the
next free pointer.(thus the kmalloc function returns 
a pointer like c0745b4580aa). And it causes lots of other
hard-to-debug problems.

This symptom is caused since the first member in the
ion_handle structure is the reference count and the
ion driver decrements the reference after it has been
freed.

To fix this problem client->lock mutex is extended
to protect all the codes that uses the handle.

Signed-off-by: Eun Taik Lee 
---
 drivers/staging/android/ion/ion.c | 102 ++
 1 file changed, 82 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index e237e9f..cb03b59 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -385,13 +385,22 @@ static void ion_handle_get(struct ion_handle *handle)
kref_get(>ref);
 }
 
+static int ion_handle_put_nolock(struct ion_handle *handle)
+{
+   int ret;
+
+   ret = kref_put(>ref, ion_handle_destroy);
+
+   return ret;
+}
+
 static int ion_handle_put(struct ion_handle *handle)
 {
struct ion_client *client = handle->client;
int ret;
 
mutex_lock(>lock);
-   ret = kref_put(>ref, ion_handle_destroy);
+   ret = ion_handle_put_nolock(handle);
mutex_unlock(>lock);
 
return ret;
@@ -415,20 +424,30 @@ static struct ion_handle *ion_handle_lookup(struct 
ion_client *client,
return ERR_PTR(-EINVAL);
 }
 
-static struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
-   int id)
+static struct ion_handle *ion_handle_get_by_id_nolock(struct ion_client 
*client,
+ int id)
 {
struct ion_handle *handle;
 
-   mutex_lock(>lock);
handle = idr_find(>idr, id);
if (handle)
ion_handle_get(handle);
-   mutex_unlock(>lock);
 
return handle ? handle : ERR_PTR(-EINVAL);
 }
 
+struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
+   int id)
+{
+   struct ion_handle *handle;
+
+   mutex_lock(>lock);
+   handle = ion_handle_get_by_id_nolock(client, id);
+   mutex_unlock(>lock);
+
+   return handle;
+}
+
 static bool ion_handle_validate(struct ion_client *client,
struct ion_handle *handle)
 {
@@ -530,7 +549,8 @@ struct ion_handle *ion_alloc(struct ion_client *client, 
size_t len,
 }
 EXPORT_SYMBOL(ion_alloc);
 
-void ion_free(struct ion_client *client, struct ion_handle *handle)
+static void ion_free_nolock(struct ion_client *client,
+   struct ion_handle *handle)
 {
bool valid_handle;
 
@@ -538,15 +558,24 @@ void ion_free(struct ion_client *client, struct 
ion_handle *handle)
 
mutex_lock(>lock);
valid_handle = ion_handle_validate(client, handle);
-
if (!valid_handle) {
WARN(1, "%s: invalid handle passed to free.\n", __func__);
mutex_unlock(>lock);
return;
}
+   ion_handle_put_nolock(handle);
+}
+
+void ion_free(struct ion_client *client, struct ion_handle *handle)
+{
+   BUG_ON(client != handle->client);
+
+   mutex_lock(>lock);
+   ion_free_nolock(client, handle);
mutex_unlock(>lock);
ion_handle_put(handle);
 }
+
 EXPORT_SYMBOL(ion_free);
 
 int ion_phys(struct ion_client *client, struct ion_handle *handle,
@@ -830,6 +859,7 @@ void ion_client_destroy(struct ion_client *client)
struct rb_node *n;
 
pr_debug("%s: %d\n", __func__, __LINE__);
+   mutex_lock(>lock);
while ((n = rb_first(>handles))) {
struct ion_handle *handle = rb_entry(n, struct ion_handle,
 node);
@@ -837,6 +867,7 @@ void ion_client_destroy(struct ion_client *client)
}
 
idr_destroy(>idr);
+   mutex_unlock(>lock);
 
down_write(>lock);
if (client->task)
@@ -1100,7 +1131,7 @@ static struct dma_buf_ops dma_buf_ops = {
.kunmap = ion_dma_buf_kunmap,
 };
 
-struct dma_buf *ion_share_dma_buf(struct ion_client *client,
+static struct dma_buf *ion_share_dma_buf_nolock(struct ion_client *client,
struct ion_handle *handle)
 {
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
@@ -1108,7 +1139,6 @@ struct dma_buf *ion_share_dma_buf(struct ion_client 
*client,
struct dma_buf *dmabuf;
bool valid_handle;
 
-   mutex_lock(>lock);
valid_handle = ion_handle_validate(client, handle);
if (!valid_handle) {
WARN(1, "%s: invalid 

[RFC PATCH] staging/android/ion : fix a race condition in the ion driver

[EunTaik Lee]

There was a use-after-free problem in the ion driver.

The problem is detected as an unaligned access in the
spin lock functions since it uses load exclusive
 instruction. In some cases it corrupts the slub's
free pointer which causes a unaligned access to the
next free pointer.(thus the kmalloc function returns 
a pointer like c0745b4580aa). And it causes lots of other
hard-to-debug problems.

This symptom is caused since the first member in the
ion_handle structure is the reference count and the
ion driver decrements the reference after it has been
freed.

To fix this problem client->lock mutex is extended
to protect all the codes that uses the handle.

Signed-off-by: Eun Taik Lee 
---
 drivers/staging/android/ion/ion.c | 102 ++
 1 file changed, 82 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index e237e9f..cb03b59 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -385,13 +385,22 @@ static void ion_handle_get(struct ion_handle *handle)
kref_get(>ref);
 }
 
+static int ion_handle_put_nolock(struct ion_handle *handle)
+{
+   int ret;
+
+   ret = kref_put(>ref, ion_handle_destroy);
+
+   return ret;
+}
+
 static int ion_handle_put(struct ion_handle *handle)
 {
struct ion_client *client = handle->client;
int ret;
 
mutex_lock(>lock);
-   ret = kref_put(>ref, ion_handle_destroy);
+   ret = ion_handle_put_nolock(handle);
mutex_unlock(>lock);
 
return ret;
@@ -415,20 +424,30 @@ static struct ion_handle *ion_handle_lookup(struct 
ion_client *client,
return ERR_PTR(-EINVAL);
 }
 
-static struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
-   int id)
+static struct ion_handle *ion_handle_get_by_id_nolock(struct ion_client 
*client,
+ int id)
 {
struct ion_handle *handle;
 
-   mutex_lock(>lock);
handle = idr_find(>idr, id);
if (handle)
ion_handle_get(handle);
-   mutex_unlock(>lock);
 
return handle ? handle : ERR_PTR(-EINVAL);
 }
 
+struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
+   int id)
+{
+   struct ion_handle *handle;
+
+   mutex_lock(>lock);
+   handle = ion_handle_get_by_id_nolock(client, id);
+   mutex_unlock(>lock);
+
+   return handle;
+}
+
 static bool ion_handle_validate(struct ion_client *client,
struct ion_handle *handle)
 {
@@ -530,7 +549,8 @@ struct ion_handle *ion_alloc(struct ion_client *client, 
size_t len,
 }
 EXPORT_SYMBOL(ion_alloc);
 
-void ion_free(struct ion_client *client, struct ion_handle *handle)
+static void ion_free_nolock(struct ion_client *client,
+   struct ion_handle *handle)
 {
bool valid_handle;
 
@@ -538,15 +558,24 @@ void ion_free(struct ion_client *client, struct 
ion_handle *handle)
 
mutex_lock(>lock);
valid_handle = ion_handle_validate(client, handle);
-
if (!valid_handle) {
WARN(1, "%s: invalid handle passed to free.\n", __func__);
mutex_unlock(>lock);
return;
}
+   ion_handle_put_nolock(handle);
+}
+
+void ion_free(struct ion_client *client, struct ion_handle *handle)
+{
+   BUG_ON(client != handle->client);
+
+   mutex_lock(>lock);
+   ion_free_nolock(client, handle);
mutex_unlock(>lock);
ion_handle_put(handle);
 }
+
 EXPORT_SYMBOL(ion_free);
 
 int ion_phys(struct ion_client *client, struct ion_handle *handle,
@@ -830,6 +859,7 @@ void ion_client_destroy(struct ion_client *client)
struct rb_node *n;
 
pr_debug("%s: %d\n", __func__, __LINE__);
+   mutex_lock(>lock);
while ((n = rb_first(>handles))) {
struct ion_handle *handle = rb_entry(n, struct ion_handle,
 node);
@@ -837,6 +867,7 @@ void ion_client_destroy(struct ion_client *client)
}
 
idr_destroy(>idr);
+   mutex_unlock(>lock);
 
down_write(>lock);
if (client->task)
@@ -1100,7 +1131,7 @@ static struct dma_buf_ops dma_buf_ops = {
.kunmap = ion_dma_buf_kunmap,
 };
 
-struct dma_buf *ion_share_dma_buf(struct ion_client *client,
+static struct dma_buf *ion_share_dma_buf_nolock(struct ion_client *client,
struct ion_handle *handle)
 {
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
@@ -1108,7 +1139,6 @@ struct dma_buf *ion_share_dma_buf(struct ion_client 
*client,
struct dma_buf *dmabuf;
bool valid_handle;
 
-   mutex_lock(>lock);
valid_handle = ion_handle_validate(client, handle);
if (!valid_handle) {
WARN(1, "%s: invalid handle passed to share.\n", 

Re: [PATCH v3 06/06] devicetree: bindings: Remove deprecated properties

[Simon Horman]

On Tue, Feb 16, 2016 at 04:18:19PM +0900, Magnus Damm wrote:
> From: Magnus Damm 
> 
> The deprecated DT properties are part of the GIT history,
> no need to keep them around any longer.
> 
> Signed-off-by: Magnus Damm 
> Acked-by: Rob Herring 
> Acked-by: Geert Uytterhoeven 

Acked-by: Simon Horman 

Re: [PATCH v3] phy: marvell: Fix and unify reg-init behavior

[Florian Fainelli]

On February 15, 2016 2:46:45 PM PST, Clemens Gruber 
 wrote:
>For the Marvell 88E1510, marvell_of_reg_init was called too late, in
>the
>config_aneg function.
>Since commit 113c74d83eef ("net: phy: turn carrier off on phy attach"),
>this lead to the link not coming up at boot anymore, due to the phy
>state machine being stuck at waiting for interrupts (off by default on
>the 88E1510).
>For seven other Marvell PHYs, marvell_of_reg_init was not called at
>all.
>
>Add a generic marvell_config_init function, which in turn calls
>marvell_of_reg_init.
>PHYs, which already have a specific config_init function with a call to
>marvell_of_reg_init, are left untouched. The generic
>marvell_config_init
>function is called for all the others, to get consistent behavior
>across
>all Marvell PHYs.
>
>Signed-off-by: Clemens Gruber 

Reviewed-by: Florian Fainelli 

Thanks!

-- 
Florian

Re: [PATCH v3 06/06] devicetree: bindings: Remove deprecated properties

[Simon Horman]

On Tue, Feb 16, 2016 at 04:18:19PM +0900, Magnus Damm wrote:
> From: Magnus Damm 
> 
> The deprecated DT properties are part of the GIT history,
> no need to keep them around any longer.
> 
> Signed-off-by: Magnus Damm 
> Acked-by: Rob Herring 
> Acked-by: Geert Uytterhoeven 

Acked-by: Simon Horman 

Re: [PATCH v3] phy: marvell: Fix and unify reg-init behavior

[Florian Fainelli]

On February 15, 2016 2:46:45 PM PST, Clemens Gruber 
 wrote:
>For the Marvell 88E1510, marvell_of_reg_init was called too late, in
>the
>config_aneg function.
>Since commit 113c74d83eef ("net: phy: turn carrier off on phy attach"),
>this lead to the link not coming up at boot anymore, due to the phy
>state machine being stuck at waiting for interrupts (off by default on
>the 88E1510).
>For seven other Marvell PHYs, marvell_of_reg_init was not called at
>all.
>
>Add a generic marvell_config_init function, which in turn calls
>marvell_of_reg_init.
>PHYs, which already have a specific config_init function with a call to
>marvell_of_reg_init, are left untouched. The generic
>marvell_config_init
>function is called for all the others, to get consistent behavior
>across
>all Marvell PHYs.
>
>Signed-off-by: Clemens Gruber 

Reviewed-by: Florian Fainelli 

Thanks!

-- 
Florian

Re: [PATCH v3 05/06] devicetree: bindings: Remove unused 32-bit CMT bindings

[Simon Horman]

On Tue, Feb 16, 2016 at 04:18:09PM +0900, Magnus Damm wrote:
> From: Magnus Damm 
> 
> Remove the 32-bit CMT compat strings to reduce maintenance burden.
> 
> It should be fine to break DT compatibility because the 32-bit
> 32-bit CMT DT binding was never part of any upstream DTS file.
> 
> Signed-off-by: Magnus Damm 
> Acked-by: Rob Herring 
> Acked-by: Geert Uytterhoeven 

Acked-by: Simon Horman 

Re: [PATCH v3 05/06] devicetree: bindings: Remove unused 32-bit CMT bindings

[Simon Horman]

On Tue, Feb 16, 2016 at 04:18:09PM +0900, Magnus Damm wrote:
> From: Magnus Damm 
> 
> Remove the 32-bit CMT compat strings to reduce maintenance burden.
> 
> It should be fine to break DT compatibility because the 32-bit
> 32-bit CMT DT binding was never part of any upstream DTS file.
> 
> Signed-off-by: Magnus Damm 
> Acked-by: Rob Herring 
> Acked-by: Geert Uytterhoeven 

Acked-by: Simon Horman 

[PATCH] intel_telemetry_pltdrv: Change verbosity control bits

[Souvik Kumar Chakravarty]

Due to a recent fix in the firmware, the Punit verbosity control bits
now adhere to the correct pattern. Hence remove the workaround and
do a read-mofiy-write of the register.

Signed-off-by: Souvik Kumar Chakravarty 
---
 drivers/platform/x86/intel_telemetry_pltdrv.c |   13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/intel_telemetry_pltdrv.c 
b/drivers/platform/x86/intel_telemetry_pltdrv.c
index f97019b..397119f 100644
--- a/drivers/platform/x86/intel_telemetry_pltdrv.c
+++ b/drivers/platform/x86/intel_telemetry_pltdrv.c
@@ -1030,8 +1030,19 @@ static int telemetry_plt_set_trace_verbosity(enum 
telemetry_unit telem_unit,
switch (telem_unit) {
case TELEM_PSS:
ret = intel_punit_ipc_command(
+   IPC_PUNIT_BIOS_READ_TELE_TRACE_CTRL,
+   0, 0, NULL, );
+   if (ret) {
+   pr_err("PSS TRACE_CTRL Read Failed\n");
+   goto out;
+   }
+
+   TELEM_CLEAR_VERBOSITY_BITS(temp);
+   TELEM_SET_VERBOSITY_BITS(temp, verbosity);
+
+   ret = intel_punit_ipc_command(
IPC_PUNIT_BIOS_WRITE_TELE_TRACE_CTRL,
-   0, 0, , NULL);
+   0, 0, , NULL);
if (ret) {
pr_err("PSS TRACE_CTRL Verbosity Set Failed\n");
goto out;
-- 
1.7.9.5

[PATCH] intel_telemetry_pltdrv: Change verbosity control bits

[Souvik Kumar Chakravarty]

Due to a recent fix in the firmware, the Punit verbosity control bits
now adhere to the correct pattern. Hence remove the workaround and
do a read-mofiy-write of the register.

Signed-off-by: Souvik Kumar Chakravarty 
---
 drivers/platform/x86/intel_telemetry_pltdrv.c |   13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/intel_telemetry_pltdrv.c 
b/drivers/platform/x86/intel_telemetry_pltdrv.c
index f97019b..397119f 100644
--- a/drivers/platform/x86/intel_telemetry_pltdrv.c
+++ b/drivers/platform/x86/intel_telemetry_pltdrv.c
@@ -1030,8 +1030,19 @@ static int telemetry_plt_set_trace_verbosity(enum 
telemetry_unit telem_unit,
switch (telem_unit) {
case TELEM_PSS:
ret = intel_punit_ipc_command(
+   IPC_PUNIT_BIOS_READ_TELE_TRACE_CTRL,
+   0, 0, NULL, );
+   if (ret) {
+   pr_err("PSS TRACE_CTRL Read Failed\n");
+   goto out;
+   }
+
+   TELEM_CLEAR_VERBOSITY_BITS(temp);
+   TELEM_SET_VERBOSITY_BITS(temp, verbosity);
+
+   ret = intel_punit_ipc_command(
IPC_PUNIT_BIOS_WRITE_TELE_TRACE_CTRL,
-   0, 0, , NULL);
+   0, 0, , NULL);
if (ret) {
pr_err("PSS TRACE_CTRL Verbosity Set Failed\n");
goto out;
-- 
1.7.9.5

Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Simon Horman]

On Wed, Feb 17, 2016 at 11:33:27AM +0900, Magnus Damm wrote:
> Hi Geert,
> 
> On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven
>  wrote:
> > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm  wrote:
> >> From: Magnus Damm 
> >>
> >> Add documentation for new separate CMT0 and CMT1 DT compatible strings
> >> for R-Car Gen2. These compat strings allow us to enable CMT1-specific
> >> features in the driver. The old compat strings will be deprecated in
> >> the not so distant future.
> >>
> >> Signed-off-by: Magnus Damm 
> >> Acked-by: Geert Uytterhoeven 
> >> Acked-by: Laurent Pinchart 
> >> Acked-by: Rob Herring 
> >> ---
> >>
> >>  Changes since V2:
> >>  - Added Acked-by from Rob
> >>  - Removed Tested-by tag from DT binding patch - duh!
> >>
> >>  Changes since V1:
> >>  - Added Acked-by and Tested-by from Geert
> >>  - Added Acked-by from Laurent
> >>
> >>  Documentation/devicetree/bindings/timer/renesas,cmt.txt |3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> >> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> >> 2015-09-17 17:26:57.440513000 +0900
> >> @@ -36,6 +36,9 @@ Required Properties:
> >> (CMT1 on sh73a0 and r8a7740)
> >> This is a fallback for the above renesas,cmt-48-* entries.
> >>
> >> +- "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car 
> >> Gen2.
> >> +- "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car 
> >> Gen2.
> >
> > (advancing a few months always means more comments ;-)
> 
> Indeed!
> 
> > I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead?
> 
> I have no strong feelings one way or the other, but I agree that
> aiming to make things more consistent must be good.

FWIW, I agree with Geert's suggestion.
But I also think it is not particularly important.

> Your proposal makes the fallback match with what we do for a bunch
> other devices on R-Car Gen2 like:
> "rcar-gen2-cpg-clocks"
> "rcar-gen2-scif"
> But we also seem to have:
> "pci-rcar-gen2"

Bother, it looks like I got pci backwards :(

> On R-Car Gen3 we seem to have the following per-SoC compat strings:
> "dmac-r8a7795"
> "etheravb-r8a7795"
> "gpio-r8a7795"
> "scif-r8a7795"

I believe the above are to follow the existing pattern for
per-SoC compat strings in the same driver, which seems sane.

> But we also have:
> "r8a7795-cpg-mssr"
> 
> My only feeling is that it looks a tad odd if we follow
> ",-" for fallback strings but
> ",-" for the per-soc binding. Why not
> using the same order? Maybe this is specified in some document
> somewhere?

I believe that the problem is a historical one. Perhaps when
we started adding bindings for our hardware there were no clear
guidelines. But regardless we ended up with a mix as you describe.

In the mean time guidelines have emerged and we (or at least I) have
agreed with the device tree people (probably Rob) to use the
,- format for new bindings. My reading is that
applies even if it results in fallback and non-fallback bindings for the
same driver have different orders. Some precedence for this can now be found
in renesas,rcar-dmac.txt.

I don't, however, think it applies where we add more soc-specific to a
driver that already has such bindings. Or new fallback bindings to a driver
that already has such bindings.

> I guess your take with "r8a7795-cpg-mssr" above is to follow the same
> order as for the fallback case? This seems sane to me, and if so then
> perhaps the per-soc compat strings for the CMT should also be updated?
> Same for other devices too then, like the recently added
> "dmac-r8a7795"?

>From my point of view it would be nice to clean things up and
re-order all the bindings. But I think the drivers would
need to maintain compatibility with the old strings. And I wonder
if it is really worth the effort.

Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Simon Horman]

On Wed, Feb 17, 2016 at 11:33:27AM +0900, Magnus Damm wrote:
> Hi Geert,
> 
> On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven
>  wrote:
> > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm  wrote:
> >> From: Magnus Damm 
> >>
> >> Add documentation for new separate CMT0 and CMT1 DT compatible strings
> >> for R-Car Gen2. These compat strings allow us to enable CMT1-specific
> >> features in the driver. The old compat strings will be deprecated in
> >> the not so distant future.
> >>
> >> Signed-off-by: Magnus Damm 
> >> Acked-by: Geert Uytterhoeven 
> >> Acked-by: Laurent Pinchart 
> >> Acked-by: Rob Herring 
> >> ---
> >>
> >>  Changes since V2:
> >>  - Added Acked-by from Rob
> >>  - Removed Tested-by tag from DT binding patch - duh!
> >>
> >>  Changes since V1:
> >>  - Added Acked-by and Tested-by from Geert
> >>  - Added Acked-by from Laurent
> >>
> >>  Documentation/devicetree/bindings/timer/renesas,cmt.txt |3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> >> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> >> 2015-09-17 17:26:57.440513000 +0900
> >> @@ -36,6 +36,9 @@ Required Properties:
> >> (CMT1 on sh73a0 and r8a7740)
> >> This is a fallback for the above renesas,cmt-48-* entries.
> >>
> >> +- "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car 
> >> Gen2.
> >> +- "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car 
> >> Gen2.
> >
> > (advancing a few months always means more comments ;-)
> 
> Indeed!
> 
> > I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead?
> 
> I have no strong feelings one way or the other, but I agree that
> aiming to make things more consistent must be good.

FWIW, I agree with Geert's suggestion.
But I also think it is not particularly important.

> Your proposal makes the fallback match with what we do for a bunch
> other devices on R-Car Gen2 like:
> "rcar-gen2-cpg-clocks"
> "rcar-gen2-scif"
> But we also seem to have:
> "pci-rcar-gen2"

Bother, it looks like I got pci backwards :(

> On R-Car Gen3 we seem to have the following per-SoC compat strings:
> "dmac-r8a7795"
> "etheravb-r8a7795"
> "gpio-r8a7795"
> "scif-r8a7795"

I believe the above are to follow the existing pattern for
per-SoC compat strings in the same driver, which seems sane.

> But we also have:
> "r8a7795-cpg-mssr"
> 
> My only feeling is that it looks a tad odd if we follow
> ",-" for fallback strings but
> ",-" for the per-soc binding. Why not
> using the same order? Maybe this is specified in some document
> somewhere?

I believe that the problem is a historical one. Perhaps when
we started adding bindings for our hardware there were no clear
guidelines. But regardless we ended up with a mix as you describe.

In the mean time guidelines have emerged and we (or at least I) have
agreed with the device tree people (probably Rob) to use the
,- format for new bindings. My reading is that
applies even if it results in fallback and non-fallback bindings for the
same driver have different orders. Some precedence for this can now be found
in renesas,rcar-dmac.txt.

I don't, however, think it applies where we add more soc-specific to a
driver that already has such bindings. Or new fallback bindings to a driver
that already has such bindings.

> I guess your take with "r8a7795-cpg-mssr" above is to follow the same
> order as for the fallback case? This seems sane to me, and if so then
> perhaps the per-soc compat strings for the CMT should also be updated?
> Same for other devices too then, like the recently added
> "dmac-r8a7795"?

>From my point of view it would be nice to clean things up and
re-order all the bindings. But I think the drivers would
need to maintain compatibility with the old strings. And I wonder
if it is really worth the effort.

[PATCH] clk: check the actual phase if get_phase is provided

[Shawn Lin]

set_phase does sanity checking of degree and ask sub-driver
to set the degree. If set_phase is limited to support the
degree what the caller need, sub-driver may select a
approximate value and return success state. In this case, it's
inappropriate to assign the degree directly to clk->core->phase.
We should ask sub-driver to decide the strategy. If sub-driver just
want to support accurate degree, it can fail the set_phase. Otherwise,
store the actual degree provided by sub-driver into clk->core->phase
if get_phase is provided.

Signed-off-by: Shawn Lin 
---

 drivers/clk/clk.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index b4db67a..352bdd2 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1891,6 +1891,7 @@ EXPORT_SYMBOL_GPL(clk_set_parent);
 int clk_set_phase(struct clk *clk, int degrees)
 {
int ret = -EINVAL;
+   int actual_phase;
 
if (!clk)
return 0;
@@ -1900,6 +1901,8 @@ int clk_set_phase(struct clk *clk, int degrees)
if (degrees < 0)
degrees += 360;
 
+   actual_phase = degrees;
+
clk_prepare_lock();
 
trace_clk_set_phase(clk->core, degrees);
@@ -1909,9 +1912,12 @@ int clk_set_phase(struct clk *clk, int degrees)
 
trace_clk_set_phase_complete(clk->core, degrees);
 
-   if (!ret)
-   clk->core->phase = degrees;
+   if (!ret) {
+   if (clk->core->ops->get_phase)
+   actual_phase = clk->core->ops->get_phase(clk->core->hw);
 
+   clk->core->phase = actual_phase;
+   }
clk_prepare_unlock();
 
return ret;
-- 
2.3.7

[PATCH] clk: check the actual phase if get_phase is provided

[Shawn Lin]

set_phase does sanity checking of degree and ask sub-driver
to set the degree. If set_phase is limited to support the
degree what the caller need, sub-driver may select a
approximate value and return success state. In this case, it's
inappropriate to assign the degree directly to clk->core->phase.
We should ask sub-driver to decide the strategy. If sub-driver just
want to support accurate degree, it can fail the set_phase. Otherwise,
store the actual degree provided by sub-driver into clk->core->phase
if get_phase is provided.

Signed-off-by: Shawn Lin 
---

 drivers/clk/clk.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index b4db67a..352bdd2 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1891,6 +1891,7 @@ EXPORT_SYMBOL_GPL(clk_set_parent);
 int clk_set_phase(struct clk *clk, int degrees)
 {
int ret = -EINVAL;
+   int actual_phase;
 
if (!clk)
return 0;
@@ -1900,6 +1901,8 @@ int clk_set_phase(struct clk *clk, int degrees)
if (degrees < 0)
degrees += 360;
 
+   actual_phase = degrees;
+
clk_prepare_lock();
 
trace_clk_set_phase(clk->core, degrees);
@@ -1909,9 +1912,12 @@ int clk_set_phase(struct clk *clk, int degrees)
 
trace_clk_set_phase_complete(clk->core, degrees);
 
-   if (!ret)
-   clk->core->phase = degrees;
+   if (!ret) {
+   if (clk->core->ops->get_phase)
+   actual_phase = clk->core->ops->get_phase(clk->core->hw);
 
+   clk->core->phase = actual_phase;
+   }
clk_prepare_unlock();
 
return ret;
-- 
2.3.7