From paweljarosz3691 at gmail.com  Sat Oct  1 07:09:39 2016
From: paweljarosz3691 at gmail.com (=?us-ascii?B?PT9VVEYtOD9xP1Bhd2U9QzU9ODI9MjBKYXJvc3o/PQ==?=)
Date: Sat, 1 Oct 2016 16:09:39 +0200
Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066
Message-ID: <20161001140939.GA31220@vaio-ubuntu>

For some reason accessing memory region above 0xfe000000 freezes
system on rk3066. There is similiar bug on later rockchip soc (rk3288)
solved same way.

Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
---
 arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 0d0dae3..44c8956 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -93,6 +93,19 @@
 		};
 	};
 
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/*
+		 * The rk3066 cannot use the memory area above 0x9F000000
+		 * for some unknown reason.
+		 */
+		unusable at 9F000000 {
+			reg = <0x9F000000 0x1000000>;
+		};
+	};
+
 	i2s0: i2s at 10118000 {
 		compatible = "rockchip,rk3066-i2s";
 		reg = <0x10118000 0x2000>;
-- 
2.7.4



From mark.rutland at arm.com  Sat Oct  1 11:17:11 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Sat, 1 Oct 2016 19:17:11 +0100
Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on
 rk3066
In-Reply-To: <20161001140939.GA31220@vaio-ubuntu>
References: <20161001140939.GA31220@vaio-ubuntu>
Message-ID: <20161001181711.GB17554@remoulade>

Hi,

On Sat, Oct 01, 2016 at 04:09:39PM +0200, =?UTF-8?q?Pawe=C5=82=20Jarosz?= wrote:
> For some reason accessing memory region above 0xfe000000 freezes
> system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> solved same way.
> 
> Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
> ---
>  arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> index 0d0dae3..44c8956 100644
> --- a/arch/arm/boot/dts/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rk3066a.dtsi
> @@ -93,6 +93,19 @@
>  		};
>  	};
>  
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +		/*
> +		 * The rk3066 cannot use the memory area above 0x9F000000
> +		 * for some unknown reason.
> +		 */
> +		unusable at 9F000000 {
> +			reg = <0x9F000000 0x1000000>;
> +		};

I don't think this is a sane workaround, but it is at best difficult to tell,
given there's no reason given for why this memory is unusable.

For instance, if bus accesses to this address hang, then this patch only makes
the hand less likely, since the kernel will still map the region (and therefore
the CPU can perform speculative accesses).

Are issues with this memory consistently seen in practice?

Can you enable CONFIG_MEMTEST and pass 'memtest' to the kernel, to determine if
the memory is returning erroneous values?

Thanks,
Mark.


From heiko at sntech.de  Sat Oct  1 12:18:15 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Sat, 01 Oct 2016 21:18:15 +0200
Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on
 rk3066
In-Reply-To: <20161001181711.GB17554@remoulade>
References: <20161001140939.GA31220@vaio-ubuntu>
 <20161001181711.GB17554@remoulade>
Message-ID: <6962779.A926KxJite@phil>

Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
> Hi,
> 
> On Sat, Oct 01, 2016 at 04:09:39PM +0200, =?UTF-8?q?Pawe=C5=82=20Jarosz?= 
wrote:
> > For some reason accessing memory region above 0xfe000000 freezes
> > system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> > solved same way.
> > 
> > Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
> > ---
> > 
> >  arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/rk3066a.dtsi
> > b/arch/arm/boot/dts/rk3066a.dtsi index 0d0dae3..44c8956 100644
> > --- a/arch/arm/boot/dts/rk3066a.dtsi
> > +++ b/arch/arm/boot/dts/rk3066a.dtsi
> > @@ -93,6 +93,19 @@
> > 
> >  		};
> >  	
> >  	};
> > 
> > +	reserved-memory {
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		ranges;
> > +		/*
> > +		 * The rk3066 cannot use the memory area above 0x9F000000
> > +		 * for some unknown reason.
> > +		 */
> > +		unusable at 9F000000 {
> > +			reg = <0x9F000000 0x1000000>;
> > +		};
> 
> I don't think this is a sane workaround, but it is at best difficult to
> tell, given there's no reason given for why this memory is unusable.
> 
> For instance, if bus accesses to this address hang, then this patch only
> makes the hand less likely, since the kernel will still map the region (and
> therefore the CPU can perform speculative accesses).
> 
> Are issues with this memory consistently seen in practice?
> 
> Can you enable CONFIG_MEMTEST and pass 'memtest' to the kernel, to determine
> if the memory is returning erroneous values?

just for the sake of completeness, on the rk3288 the issue was the dma not 
being able to access the specific memory region (interestingly also the last 
16MB but of the 4GB area supported on the rk3288). So memory itself was ok, 
just dma access to it failed.

We didn't find any other sane solution to limit the dma access in a general way 
at the time, so opted for just blocking the memory region (as it was similarly 
only 

In the patch above, the newly blocked area is in the middle of the two 1gb 
memory areas (0x60000000-0xa0000000-1, 0xa0000000-0xe0000000-1).

Pavel, apart from Mark's CONFIG_MEMTEST request above could you also specifiy 
what type of error you see please?


Thanks
Heiko


From paweljarosz3691 at gmail.com  Sat Oct  1 12:59:42 2016
From: paweljarosz3691 at gmail.com (=?UTF-8?Q?Pawe=c5=82_Jarosz?=)
Date: Sat, 1 Oct 2016 21:59:42 +0200
Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on
 rk3066
In-Reply-To: <6962779.A926KxJite@phil>
References: <20161001140939.GA31220@vaio-ubuntu>
 <20161001181711.GB17554@remoulade> <6962779.A926KxJite@phil>
Message-ID: <799e2fe9-36ac-6f95-7422-f8d834f2d2ec@gmail.com>

Hi,
main symptom is complete system freeze.
With CONFIG_MEMTEST enabled and with passed "memtest" to the kernel all 
tests run ok.
But when i run command for example "memtester 800M" or simple "apt 
update" freeze happening.
And when i reserve this region in dts, board is stable again.

Thanks,
Pawel

W dniu 01.10.2016 o 21:18, Heiko Stuebner pisze:
> Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
>> Hi,
>>
>> On Sat, Oct 01, 2016 at 04:09:39PM +0200, =?UTF-8?q?Pawe=C5=82=20Jarosz?=
> wrote:
>>> For some reason accessing memory region above 0xfe000000 freezes
>>> system on rk3066. There is similiar bug on later rockchip soc (rk3288)
>>> solved same way.
>>>
>>> Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
>>> ---
>>>
>>>   arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
>>>   1 file changed, 13 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/rk3066a.dtsi
>>> b/arch/arm/boot/dts/rk3066a.dtsi index 0d0dae3..44c8956 100644
>>> --- a/arch/arm/boot/dts/rk3066a.dtsi
>>> +++ b/arch/arm/boot/dts/rk3066a.dtsi
>>> @@ -93,6 +93,19 @@
>>>
>>>   		};
>>>   	
>>>   	};
>>>
>>> +	reserved-memory {
>>> +		#address-cells = <1>;
>>> +		#size-cells = <1>;
>>> +		ranges;
>>> +		/*
>>> +		 * The rk3066 cannot use the memory area above 0x9F000000
>>> +		 * for some unknown reason.
>>> +		 */
>>> +		unusable at 9F000000 {
>>> +			reg = <0x9F000000 0x1000000>;
>>> +		};
>> I don't think this is a sane workaround, but it is at best difficult to
>> tell, given there's no reason given for why this memory is unusable.
>>
>> For instance, if bus accesses to this address hang, then this patch only
>> makes the hand less likely, since the kernel will still map the region (and
>> therefore the CPU can perform speculative accesses).
>>
>> Are issues with this memory consistently seen in practice?
>>
>> Can you enable CONFIG_MEMTEST and pass 'memtest' to the kernel, to determine
>> if the memory is returning erroneous values?
> just for the sake of completeness, on the rk3288 the issue was the dma not
> being able to access the specific memory region (interestingly also the last
> 16MB but of the 4GB area supported on the rk3288). So memory itself was ok,
> just dma access to it failed.
>
> We didn't find any other sane solution to limit the dma access in a general way
> at the time, so opted for just blocking the memory region (as it was similarly
> only
>
> In the patch above, the newly blocked area is in the middle of the two 1gb
> memory areas (0x60000000-0xa0000000-1, 0xa0000000-0xe0000000-1).
>
> Pavel, apart from Mark's CONFIG_MEMTEST request above could you also specifiy
> what type of error you see please?
>
>
> Thanks
> Heiko



From mark.rutland at arm.com  Mon Oct  3 03:20:54 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 3 Oct 2016 11:20:54 +0100
Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on
 rk3066
In-Reply-To: <6962779.A926KxJite@phil>
References: <20161001140939.GA31220@vaio-ubuntu>
 <20161001181711.GB17554@remoulade> <6962779.A926KxJite@phil>
Message-ID: <20161003102054.GB7632@leverpostej>

On Sat, Oct 01, 2016 at 09:18:15PM +0200, Heiko Stuebner wrote:
> Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
> > On Sat, Oct 01, 2016 at 04:09:39PM +0200, =?UTF-8?q?Pawe=C5=82=20Jarosz?= 
> wrote:
> > > For some reason accessing memory region above 0xfe000000 freezes
> > > system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> > > solved same way.

[...]

> > > +	reserved-memory {
> > > +		#address-cells = <1>;
> > > +		#size-cells = <1>;
> > > +		ranges;
> > > +		/*
> > > +		 * The rk3066 cannot use the memory area above 0x9F000000
> > > +		 * for some unknown reason.
> > > +		 */
> > > +		unusable at 9F000000 {
> > > +			reg = <0x9F000000 0x1000000>;
> > > +		};
> > 
> > I don't think this is a sane workaround, but it is at best difficult to
> > tell, given there's no reason given for why this memory is unusable.
> > 
> > For instance, if bus accesses to this address hang, then this patch only
> > makes the hand less likely, since the kernel will still map the region (and
> > therefore the CPU can perform speculative accesses).
> > 
> > Are issues with this memory consistently seen in practice?
> > 
> > Can you enable CONFIG_MEMTEST and pass 'memtest' to the kernel, to determine
> > if the memory is returning erroneous values?
> 
> just for the sake of completeness, on the rk3288 the issue was the dma not 
> being able to access the specific memory region (interestingly also the last 
> 16MB but of the 4GB area supported on the rk3288). So memory itself was ok, 
> just dma access to it failed.

How odd.

> We didn't find any other sane solution to limit the dma access in a general way 
> at the time, so opted for just blocking the memory region (as it was similarly 
> only 

I was under the impression that dma-ranges could describe this kind of
DMA addressing limitation. Was there some problem with that? Perhaps the
driver is not acquiring/configuring its mask correctly?

Thanks,
Mark.


From heiko at sntech.de  Mon Oct  3 03:54:56 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 03 Oct 2016 12:54:56 +0200
Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on
 rk3066
In-Reply-To: <20161003102054.GB7632@leverpostej>
References: <20161001140939.GA31220@vaio-ubuntu> <6962779.A926KxJite@phil>
 <20161003102054.GB7632@leverpostej>
Message-ID: <2391111.dvDuarNnp9@phil>

Am Montag, 3. Oktober 2016, 11:20:54 CEST schrieb Mark Rutland:
> On Sat, Oct 01, 2016 at 09:18:15PM +0200, Heiko Stuebner wrote:
> > Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
> > > On Sat, Oct 01, 2016 at 04:09:39PM +0200,
> > > =?UTF-8?q?Pawe=C5=82=20Jarosz?=
> > 
> > wrote:
> > > > For some reason accessing memory region above 0xfe000000 freezes
> > > > system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> > > > solved same way.
> 
> [...]
> 
> > > > +	reserved-memory {
> > > > +		#address-cells = <1>;
> > > > +		#size-cells = <1>;
> > > > +		ranges;
> > > > +		/*
> > > > +		 * The rk3066 cannot use the memory area above 0x9F000000
> > > > +		 * for some unknown reason.
> > > > +		 */
> > > > +		unusable at 9F000000 {
> > > > +			reg = <0x9F000000 0x1000000>;
> > > > +		};
> > > 
> > > I don't think this is a sane workaround, but it is at best difficult to
> > > tell, given there's no reason given for why this memory is unusable.
> > > 
> > > For instance, if bus accesses to this address hang, then this patch only
> > > makes the hand less likely, since the kernel will still map the region
> > > (and
> > > therefore the CPU can perform speculative accesses).
> > > 
> > > Are issues with this memory consistently seen in practice?
> > > 
> > > Can you enable CONFIG_MEMTEST and pass 'memtest' to the kernel, to
> > > determine if the memory is returning erroneous values?
> > 
> > just for the sake of completeness, on the rk3288 the issue was the dma not
> > being able to access the specific memory region (interestingly also the
> > last 16MB but of the 4GB area supported on the rk3288). So memory itself
> > was ok, just dma access to it failed.
> 
> How odd.
> 
> > We didn't find any other sane solution to limit the dma access in a
> > general way at the time, so opted for just blocking the memory region (as
> > it was similarly only
> 
> I was under the impression that dma-ranges could describe this kind of
> DMA addressing limitation. Was there some problem with that? Perhaps the
> driver is not acquiring/configuring its mask correctly?

I remember looking at (and trying) different options back then.

dma-mask wanted power-of-2 values (so it's either 4GB or 2GB (or lower)),  
zone-dma was a 32bit (and non-dt) thing and dma-ranges seem to simply also 
calculate a dma-mask from the value, so you're down to 2GB again.

So just blocking of those 16MB at the end for 4GB devices somehow sounded 
nicer than limiting dma access to only half the memory.

I may be overlooking something but that was what I came up with last year.


Heiko


From architt at codeaurora.org  Mon Oct  3 04:13:41 2016
From: architt at codeaurora.org (Archit Taneja)
Date: Mon, 3 Oct 2016 16:43:41 +0530
Subject: [PATCH 2/2] drm/rockchip: analogix_dp: Refuse to enable PSR if
 panel doesn't support it
In-Reply-To: <CAOw6vbL1fDpPbFeePEFqYZ+i0sbbsB+vu7fCC8U88HAj-1D2Ag@mail.gmail.com>
References: <1474639600-30090-1-git-send-email-tomeu.vizoso@collabora.com>
 <1474639600-30090-2-git-send-email-tomeu.vizoso@collabora.com>
 <CAOw6vbL1fDpPbFeePEFqYZ+i0sbbsB+vu7fCC8U88HAj-1D2Ag@mail.gmail.com>
Message-ID: <de7a4a12-6e52-92c8-7c4c-fc5ec4533eeb@codeaurora.org>



On 09/27/2016 06:58 PM, Sean Paul wrote:
> On Fri, Sep 23, 2016 at 10:06 AM, Tomeu Vizoso
> <tomeu.vizoso at collabora.com> wrote:
>> There's no point in enabling PSR when the panel doesn't support it.
>>
>> This also avoids a problem when PSR gets enabled when a CRTC is being
>> disabled, because sometimes in that situation the DSP_HOLD_VALID_INTR
>> interrupt on which we wait will never arrive. This was observed on
>> RK3288 with a panel without PSR (veyron-jaq Chromebook).
>>
>> It's very easy to reproduce by running the kms_rmfb test in IGT a few
>> times.
>>
>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>
>
> Thanks for digging into this.
>
> Reviewed-by: Sean Paul <seanpaul at chromium.org>
>

queued to drm-misc.

Archit


>
>
>> Cc: Sean Paul <seanpaul at chromium.org>
>> Cc: Yakir Yang <ykk at rock-chips.com>
>> Cc: Archit Taneja <architt at codeaurora.org>
>> ---
>>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> index e83be157cc2a..8548e8271639 100644
>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> @@ -85,6 +85,9 @@ static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
>>         struct rockchip_dp_device *dp = to_dp(encoder);
>>         unsigned long flags;
>>
>> +       if (!analogix_dp_psr_supported(dp->dev))
>> +               return;
>> +
>>         dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
>>
>>         spin_lock_irqsave(&dp->psr_lock, flags);
>> --
>> 2.7.4
>>

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


From paweljarosz3691 at gmail.com  Tue Oct  4 04:56:07 2016
From: paweljarosz3691 at gmail.com (=?UTF-8?Q?Pawe=c5=82_Jarosz?=)
Date: Tue, 4 Oct 2016 13:56:07 +0200
Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on
 rk3066
In-Reply-To: <2391111.dvDuarNnp9@phil>
References: <20161001140939.GA31220@vaio-ubuntu> <6962779.A926KxJite@phil>
 <20161003102054.GB7632@leverpostej> <2391111.dvDuarNnp9@phil>
Message-ID: <81d1fb8b-ee0e-35a7-77db-5e15c3f46449@gmail.com>


>>>> I don't think this is a sane workaround, but it is at best difficult to
>>>> tell, given there's no reason given for why this memory is unusable.
>>>>
>>>> For instance, if bus accesses to this address hang, then this patch only
>>>> makes the hand less likely, since the kernel will still map the region
>>>> (and
>>>> therefore the CPU can perform speculative accesses).
>>>>
>>>> Are issues with this memory consistently seen in practice?
>>>>
>>>> Can you enable CONFIG_MEMTEST and pass 'memtest' to the kernel, to
>>>> determine if the memory is returning erroneous values?
>>> just for the sake of completeness, on the rk3288 the issue was the dma not
>>> being able to access the specific memory region (interestingly also the
>>> last 16MB but of the 4GB area supported on the rk3288). So memory itself
>>> was ok, just dma access to it failed.
>> How odd.
>>
>>> We didn't find any other sane solution to limit the dma access in a
>>> general way at the time, so opted for just blocking the memory region (as
>>> it was similarly only
>> I was under the impression that dma-ranges could describe this kind of
>> DMA addressing limitation. Was there some problem with that? Perhaps the
>> driver is not acquiring/configuring its mask correctly?
> I remember looking at (and trying) different options back then.
>
> dma-mask wanted power-of-2 values (so it's either 4GB or 2GB (or lower)),
> zone-dma was a 32bit (and non-dt) thing and dma-ranges seem to simply also
> calculate a dma-mask from the value, so you're down to 2GB again.
>
> So just blocking of those 16MB at the end for 4GB devices somehow sounded
> nicer than limiting dma access to only half the memory.
>
> I may be overlooking something but that was what I came up with last year.
>
>
> Heiko
Is there a chance to accept this patch?

I know it's not the best solution to this problem, but i don't know
a better one.


From seanpaul at chromium.org  Tue Oct  4 07:53:58 2016
From: seanpaul at chromium.org (Sean Paul)
Date: Tue, 4 Oct 2016 10:53:58 -0400
Subject: [PATCH v2 2/4] drm/bridge: analogix_dp: get sync PM when init eDP
In-Reply-To: <1475239256-16083-3-git-send-email-wzz@rock-chips.com>
References: <1475239256-16083-1-git-send-email-wzz@rock-chips.com>
 <1475239256-16083-3-git-send-email-wzz@rock-chips.com>
Message-ID: <CAOw6vb+jSg-N74Nj=md8kW0aukk_u=HjTBa45XwxJkyFVqtKFQ@mail.gmail.com>

On Fri, Sep 30, 2016 at 8:40 AM, zain wang <wzz at rock-chips.com> wrote:


Can you please add a commit message describing why this is needed.

Sean


> Signed-off-by: zain wang <wzz at rock-chips.com>
>
> ---
>
> Changes in v2: None
>
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index b4ce16a..1bd190e 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1411,10 +1411,12 @@ int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
>         }
>
>         pm_runtime_enable(dev);
> +       pm_runtime_get_sync(dev);
>
>         phy_power_on(dp->phy);
>
>         analogix_dp_init_dp(dp);
> +       pm_runtime_put_sync(dev);
>
>         ret = devm_request_threaded_irq(&pdev->dev, dp->irq,
>                                         analogix_dp_hardirq,
> --
> 1.9.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From helgaas at kernel.org  Tue Oct  4 10:24:04 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Tue, 4 Oct 2016 12:24:04 -0500
Subject: [PATCH 1/2] PCI: rockchip: improve the deassert sequence of four
 reset pins
In-Reply-To: <1474596360-23483-1-git-send-email-shawn.lin@rock-chips.com>
References: <1474596360-23483-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <20161004172404.GC3449@localhost>

On Fri, Sep 23, 2016 at 10:05:59AM +0800, Shawn Lin wrote:
> Per TRM, we need to deassert the four reset pins simultaneously.
> Currently the reset framework doesn't support that so we did it
> one by one. It seems no side effect found but it does impact the
> state machine of controller, so sometimes the change speed bit is
> not setted when sending training sequence from recover state.
> After the silicon RTL review from Soc guys, we don't need to do
> the sequence recommended by TRM, and could just move the deassert
> of mgmt_sticky_rst to the first place.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

Applied both to pci/host-rockchip for v4.9, thanks!

> ---
> 
>  drivers/pci/host/pcie-rockchip.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index c3593e6..5e51121 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -433,21 +433,25 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  		return err;
>  	}
>  
> -	err = reset_control_deassert(rockchip->core_rst);
> +	/*
> +	 * Please don't reorder the deassert sequence of the following
> +	 * four reset pins.
> +	 */
> +	err = reset_control_deassert(rockchip->mgmt_sticky_rst);
>  	if (err) {
> -		dev_err(dev, "deassert core_rst err %d\n", err);
> +		dev_err(dev, "deassert mgmt_sticky_rst err %d\n", err);
>  		return err;
>  	}
>  
> -	err = reset_control_deassert(rockchip->mgmt_rst);
> +	err = reset_control_deassert(rockchip->core_rst);
>  	if (err) {
> -		dev_err(dev, "deassert mgmt_rst err %d\n", err);
> +		dev_err(dev, "deassert core_rst err %d\n", err);
>  		return err;
>  	}
>  
> -	err = reset_control_deassert(rockchip->mgmt_sticky_rst);
> +	err = reset_control_deassert(rockchip->mgmt_rst);
>  	if (err) {
> -		dev_err(dev, "deassert mgmt_sticky_rst err %d\n", err);
> +		dev_err(dev, "deassert mgmt_rst err %d\n", err);
>  		return err;
>  	}
>  
> -- 
> 2.3.7
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From briannorris at chromium.org  Tue Oct  4 10:49:04 2016
From: briannorris at chromium.org (Brian Norris)
Date: Tue, 4 Oct 2016 10:49:04 -0700
Subject: [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in
 suspend
In-Reply-To: <20160929170847.1227a312@arm.com>
References: <20160916054917.16930-1-briannorris@chromium.org>
 <57DBA81F.2060404@arm.com> <20160919231441.GA60928@google.com>
 <57E0E97B.5000106@arm.com> <20160928012309.GA29518@localhost>
 <20160929170847.1227a312@arm.com>
Message-ID: <20161004174903.GA3098@localhost>

Hi Marc,

On Thu, Sep 29, 2016 at 05:08:47PM +0100, Marc Zyngier wrote:
> On Tue, 27 Sep 2016 18:23:11 -0700
> Brian Norris <briannorris at chromium.org> wrote:
> > On Tue, Sep 20, 2016 at 08:47:07AM +0100, Marc Zyngier wrote:
> > <Begin side note>
> > rk3288 (ARMv7 system widely used for our Chromebooks) has the same
> > issue, except the kernel we're using for production (based on v3.14)
> > doesn't have the following commit, which stopped utilizing the RTC:
> > 
> > commit 0fa88cb4b82b5cf7429bc1cef9db006ca035754e
> > Author: Xunlei Pang <pang.xunlei at linaro.org>
> > Date:   Wed Apr 1 20:34:38 2015 -0700
> > 
> >     time, drivers/rtc: Don't bother with rtc_resume() for the nonstop clocksource
> > 
> > And any mainline testing on rk3288 doesn't see the problem, because
> > mainline doesn't support its lowest-power sleep modes well enough (see
> > ROCKCHIP_ARM_OFF_LOGIC_DEEP in arch/arm/mach-rockchip/pm.c).
> 
> Arghh... So even my favourite Chromebook (from which I'm typing this
> email) is affected? Not very nice...

Yep. But if you're running mainline, you just get to have high S3 power
consumption instead!

> > <End side note>

> As for the 64bit kernel, it would be interesting to verify that on
> resume, the VDSO does return the right (corrected) value, and not
> something stale.

It would be interesting, except all my current user spaces are built for
32-bit, so it's not too easy for me to test. Perhaps I could pull in
this [1]. (On the bright side, this means that VDSO can't possibly be
breaking on my systems!)

Brian

[1] http://www.spinics.net/lists/arm-kernel/msg530185.html


From briannorris at chromium.org  Tue Oct  4 11:12:10 2016
From: briannorris at chromium.org (Brian Norris)
Date: Tue,  4 Oct 2016 11:12:10 -0700
Subject: [PATCH v2 2/2] arm64: dts: rockchip: arch counter doesn't tick in
 system suspend
In-Reply-To: <1475604730-140264-1-git-send-email-briannorris@chromium.org>
References: <1475604730-140264-1-git-send-email-briannorris@chromium.org>
Message-ID: <1475604730-140264-2-git-send-email-briannorris@chromium.org>

The "arm,no-tick-in-suspend" property was introduced to note
implementations where the system counter does not quite follow the ARM
specification that it "must be implemented in an always-on power
domain".

Particularly, RK3399's counter stops ticking when we switch from the
24MHz clock to the 32KHz clock in low-power suspend, so let's mark it as
such.

Signed-off-by: Brian Norris <briannorris at chromium.org>
---
v2: new in v2

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 76b28649f0b0..401c8be8c8ac 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -174,6 +174,7 @@
 			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW 0>,
 			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW 0>,
 			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW 0>;
+		arm,no-tick-in-suspend;
 	};
 
 	xin24m: xin24m {
-- 
2.8.0.rc3.226.g39d4020



From briannorris at chromium.org  Tue Oct  4 11:12:09 2016
From: briannorris at chromium.org (Brian Norris)
Date: Tue,  4 Oct 2016 11:12:09 -0700
Subject: [PATCH v2 1/2] clocksource: arm_arch_timer: Don't assume clock runs
 in suspend
Message-ID: <1475604730-140264-1-git-send-email-briannorris@chromium.org>

The ARM ARM specifies that the system counter "must be implemented in an
always-on power domain," and so we try to use the counter as a source of
timekeeping across suspend/resume. Unfortunately, some SoCs (e.g.,
Rockchip's RK3399) do not keep the counter ticking properly when
switched from their high-power clock to the lower-power clock used in
system suspend. Support this quirk by adding a new device tree property.

Signed-off-by: Brian Norris <briannorris at chromium.org>
---
v2:
 * add new device tree property, instead of re-using the "always-on"
   property (which has different meaning)

 Documentation/devicetree/bindings/arm/arch_timer.txt | 5 +++++
 drivers/clocksource/arm_arch_timer.c                 | 9 ++++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
index ef5fbe9a77c7..ad440a2b8051 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -38,6 +38,11 @@ to deliver its interrupts via SPIs.
   architecturally-defined reset values. Only supported for 32-bit
   systems which follow the ARMv7 architected reset values.
 
+- arm,no-tick-in-suspend : The main counter does not tick when the system is in
+  low-power system suspend on some SoCs. This behavior does not match the
+  Architecture Reference Manual's specification that the system counter "must
+  be implemented in an always-on power domain."
+
 
 Example:
 
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 73c487da6d2a..a2503db7e533 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -81,6 +81,7 @@ static struct clock_event_device __percpu *arch_timer_evt;
 static enum ppi_nr arch_timer_uses_ppi = VIRT_PPI;
 static bool arch_timer_c3stop;
 static bool arch_timer_mem_use_virtual;
+static bool arch_counter_suspend_stop;
 
 static bool evtstrm_enable = IS_ENABLED(CONFIG_ARM_ARCH_TIMER_EVTSTREAM);
 
@@ -576,7 +577,7 @@ static struct clocksource clocksource_counter = {
 	.rating	= 400,
 	.read	= arch_counter_read,
 	.mask	= CLOCKSOURCE_MASK(56),
-	.flags	= CLOCK_SOURCE_IS_CONTINUOUS | CLOCK_SOURCE_SUSPEND_NONSTOP,
+	.flags	= CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
 static struct cyclecounter cyclecounter = {
@@ -616,6 +617,8 @@ static void __init arch_counter_register(unsigned type)
 		arch_timer_read_counter = arch_counter_get_cntvct_mem;
 	}
 
+	if (!arch_counter_suspend_stop)
+		clocksource_counter.flags |= CLOCK_SOURCE_SUSPEND_NONSTOP;
 	start_count = arch_timer_read_counter();
 	clocksource_register_hz(&clocksource_counter, arch_timer_rate);
 	cyclecounter.mult = clocksource_counter.mult;
@@ -907,6 +910,10 @@ static int __init arch_timer_of_init(struct device_node *np)
 	    of_property_read_bool(np, "arm,cpu-registers-not-fw-configured"))
 		arch_timer_uses_ppi = PHYS_SECURE_PPI;
 
+	/* On some systems, the counter stops ticking when in suspend. */
+	arch_counter_suspend_stop = of_property_read_bool(np,
+							 "arm,no-tick-in-suspend");
+
 	return arch_timer_init();
 }
 CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_of_init);
-- 
2.8.0.rc3.226.g39d4020



From heiko at sntech.de  Tue Oct  4 11:56:27 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 04 Oct 2016 20:56:27 +0200
Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on
 rk3066
In-Reply-To: <81d1fb8b-ee0e-35a7-77db-5e15c3f46449@gmail.com>
References: <20161001140939.GA31220@vaio-ubuntu> <2391111.dvDuarNnp9@phil>
 <81d1fb8b-ee0e-35a7-77db-5e15c3f46449@gmail.com>
Message-ID: <2236986.cydz8Jad7F@diego>

Hi Pawe?,

Am Dienstag, 4. Oktober 2016, 13:56:07 schrieb Pawe? Jarosz:
> >>>> I don't think this is a sane workaround, but it is at best difficult to
> >>>> tell, given there's no reason given for why this memory is unusable.
> >>>> 
> >>>> For instance, if bus accesses to this address hang, then this patch
> >>>> only
> >>>> makes the hand less likely, since the kernel will still map the region
> >>>> (and
> >>>> therefore the CPU can perform speculative accesses).
> >>>> 
> >>>> Are issues with this memory consistently seen in practice?
> >>>> 
> >>>> Can you enable CONFIG_MEMTEST and pass 'memtest' to the kernel, to
> >>>> determine if the memory is returning erroneous values?
> >>> 
> >>> just for the sake of completeness, on the rk3288 the issue was the dma
> >>> not
> >>> being able to access the specific memory region (interestingly also the
> >>> last 16MB but of the 4GB area supported on the rk3288). So memory itself
> >>> was ok, just dma access to it failed.
> >> 
> >> How odd.
> >> 
> >>> We didn't find any other sane solution to limit the dma access in a
> >>> general way at the time, so opted for just blocking the memory region
> >>> (as
> >>> it was similarly only
> >> 
> >> I was under the impression that dma-ranges could describe this kind of
> >> DMA addressing limitation. Was there some problem with that? Perhaps the
> >> driver is not acquiring/configuring its mask correctly?
> > 
> > I remember looking at (and trying) different options back then.
> > 
> > dma-mask wanted power-of-2 values (so it's either 4GB or 2GB (or lower)),
> > zone-dma was a 32bit (and non-dt) thing and dma-ranges seem to simply also
> > calculate a dma-mask from the value, so you're down to 2GB again.
> > 
> > So just blocking of those 16MB at the end for 4GB devices somehow sounded
> > nicer than limiting dma access to only half the memory.
> > 
> > I may be overlooking something but that was what I came up with last year.
> > 
> > 
> > Heiko
> 
> Is there a chance to accept this patch?
> 
> I know it's not the best solution to this problem, but i don't know
> a better one.

there is always a "chance". But with changes like these, we always try to find 
a real cause first, before resorting to solutions like this. So it's definitly 
not off the table, but I'd like to investigate further first, so that we don't 
accumulate unnecessary hacks over time.

Especially that your region seems to be in the middle of the designated ram 
area is strange.

Could you please tell which board you're using (and how much memory it has)


Thanks
Heiko


From dianders at chromium.org  Tue Oct  4 15:14:29 2016
From: dianders at chromium.org (Doug Anderson)
Date: Tue, 4 Oct 2016 15:14:29 -0700
Subject: [PATCH v2 1/2] clocksource: arm_arch_timer: Don't assume clock
 runs in suspend
In-Reply-To: <1475604730-140264-1-git-send-email-briannorris@chromium.org>
References: <1475604730-140264-1-git-send-email-briannorris@chromium.org>
Message-ID: <CAD=FV=VO2f78AMRfWbhn8MZ8y1wKFPUdOf64BUpKuS+GEvnWGA@mail.gmail.com>

Hi,

On Tue, Oct 4, 2016 at 11:12 AM, Brian Norris <briannorris at chromium.org> wrote:
> The ARM ARM specifies that the system counter "must be implemented in an
> always-on power domain," and so we try to use the counter as a source of
> timekeeping across suspend/resume. Unfortunately, some SoCs (e.g.,
> Rockchip's RK3399) do not keep the counter ticking properly when
> switched from their high-power clock to the lower-power clock used in
> system suspend. Support this quirk by adding a new device tree property.
>
> Signed-off-by: Brian Norris <briannorris at chromium.org>
> ---
> v2:
>  * add new device tree property, instead of re-using the "always-on"
>    property (which has different meaning)
>
>  Documentation/devicetree/bindings/arm/arch_timer.txt | 5 +++++
>  drivers/clocksource/arm_arch_timer.c                 | 9 ++++++++-
>  2 files changed, 13 insertions(+), 1 deletion(-)

FWIW:

Reviewed-by: Douglas Anderson <dianders at chromium.org>


From dianders at chromium.org  Tue Oct  4 15:14:49 2016
From: dianders at chromium.org (Doug Anderson)
Date: Tue, 4 Oct 2016 15:14:49 -0700
Subject: [PATCH v2 2/2] arm64: dts: rockchip: arch counter doesn't tick in
 system suspend
In-Reply-To: <1475604730-140264-2-git-send-email-briannorris@chromium.org>
References: <1475604730-140264-1-git-send-email-briannorris@chromium.org>
 <1475604730-140264-2-git-send-email-briannorris@chromium.org>
Message-ID: <CAD=FV=XGwc8k-OctcKmdJoFK44v86qegAAFDOpN71wpciA=3Tg@mail.gmail.com>

Hi,

On Tue, Oct 4, 2016 at 11:12 AM, Brian Norris <briannorris at chromium.org> wrote:
> The "arm,no-tick-in-suspend" property was introduced to note
> implementations where the system counter does not quite follow the ARM
> specification that it "must be implemented in an always-on power
> domain".
>
> Particularly, RK3399's counter stops ticking when we switch from the
> 24MHz clock to the 32KHz clock in low-power suspend, so let's mark it as
> such.
>
> Signed-off-by: Brian Norris <briannorris at chromium.org>
> ---
> v2: new in v2
>
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Douglas Anderson <dianders at chromium.org>


From huangtao at rock-chips.com  Tue Oct  4 19:27:15 2016
From: huangtao at rock-chips.com (Huang, Tao)
Date: Wed, 5 Oct 2016 10:27:15 +0800
Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on
 rk3066
In-Reply-To: <20161001140939.GA31220@vaio-ubuntu>
References: <20161001140939.GA31220@vaio-ubuntu>
Message-ID: <6239b970-09d3-f7ee-e6f5-c019eaedb725@rock-chips.com>

Hi, Pawe?:
On 2016?10?01? 22:09, =?UTF-8?q?Pawe=C5=82=20Jarosz?= wrote:
> For some reason accessing memory region above 0xfe000000 freezes
> system on rk3066. There is similiar bug on later rockchip soc (rk3288)
RK3066 only support 2GB memory from 0x60000000 to 0xE0000000, can not access
above 0xfe000000. I think you mean 0x9F000000?
> solved same way.
>
> Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
> ---
>  arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> index 0d0dae3..44c8956 100644
> --- a/arch/arm/boot/dts/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rk3066a.dtsi
> @@ -93,6 +93,19 @@
>  		};
>  	};
>  
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +		/*
> +		 * The rk3066 cannot use the memory area above 0x9F000000
> +		 * for some unknown reason.
> +		 */

I don't remember RK3066 has such limit. I will double check with our IC
design team.
Do you know which master can not access this memory area
[0x9F000000~0xA0000000)?

> +		unusable at 9F000000 {
> +			reg = <0x9F000000 0x1000000>;
> +		};
> +	};
> +
>  	i2s0: i2s at 10118000 {
>  		compatible = "rockchip,rk3066-i2s";
>  		reg = <0x10118000 0x2000>;




From shawn.lin at rock-chips.com  Tue Oct  4 20:06:16 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed,  5 Oct 2016 11:06:16 +0800
Subject: [PATCH v2] PCI: rockchip: Support property to specify the link
 capability
Message-ID: <1475636776-11386-1-git-send-email-shawn.lin@rock-chips.com>

From: Brian Norris <briannorris at chromium.org>

rk3399 supports PCIe 2.x link speeds marginally at best, and on some
boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500
ms waiting for training that will never happen, let's add a property
from devicetree to specify link capability.

Signed-off-by: Brian Norris <briannorris at chromium.org>
Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v2:
- rename the property to rockchip,max-link-speed according to
  Bjorn's recommendation and take some bits from imx6q-pcie to
  make this requirement more consisent.

 .../devicetree/bindings/pci/rockchip-pcie.txt      |  2 +
 drivers/pci/host/pcie-rockchip.c                   | 61 ++++++++++++++--------
 2 files changed, 41 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
index ba67b39..8335f03 100644
--- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
@@ -42,6 +42,8 @@ Required properties:
 Optional Property:
 - ep-gpios: contain the entry for pre-reset gpio
 - num-lanes: number of lanes to use
+- rockchip,max-link-speed: Specify PCI gen for link capability. Must
+	be '2' for gen2, otherwise will default to gen1.
 - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
 - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe.
 - vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe.
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 35591b1..ca3db51 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -53,6 +53,7 @@
 #define   PCIE_CLIENT_ARI_ENABLE	  HIWORD_UPDATE_BIT(0x0008)
 #define   PCIE_CLIENT_CONF_LANE_NUM(x)	  HIWORD_UPDATE(0x0030, ENCODE_LANES(x))
 #define   PCIE_CLIENT_MODE_RC		  HIWORD_UPDATE_BIT(0x0040)
+#define   PCIE_CLIENT_GEN_SEL_1		  HIWORD_UPDATE(0x0080, 0)
 #define   PCIE_CLIENT_GEN_SEL_2		  HIWORD_UPDATE_BIT(0x0080)
 #define PCIE_CLIENT_BASIC_STATUS1	(PCIE_CLIENT_BASE + 0x48)
 #define   PCIE_CLIENT_LINK_STATUS_UP		0x00300000
@@ -205,6 +206,7 @@ struct rockchip_pcie {
 	struct	gpio_desc *ep_gpio;
 	u32	lanes;
 	u8	root_bus_nr;
+	int	link_gen;
 	struct	device *dev;
 	struct	irq_domain *irq_domain;
 };
@@ -443,13 +445,21 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		return err;
 	}
 
+	if (rockchip->link_gen == 2) {
+		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_2,
+				    PCIE_CLIENT_CONFIG);
+	} else {
+		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_1,
+				    PCIE_CLIENT_CONFIG);
+		dev_info(dev, "max link speed is gen 1\n");
+	}
+
 	rockchip_pcie_write(rockchip,
 			    PCIE_CLIENT_CONF_ENABLE |
 			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
 			    PCIE_CLIENT_ARI_ENABLE |
 			    PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
-			    PCIE_CLIENT_MODE_RC |
-			    PCIE_CLIENT_GEN_SEL_2,
+			    PCIE_CLIENT_MODE_RC,
 				PCIE_CLIENT_CONFIG);
 
 	err = phy_power_on(rockchip->phy);
@@ -550,29 +560,31 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		msleep(20);
 	}
 
-	/*
-	 * Enable retrain for gen2. This should be configured only after
-	 * gen1 finished.
-	 */
-	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
-	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
-	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
+	if (rockchip->link_gen == 2) {
+		/*
+		 * Enable retrain for gen2. This should be configured only after
+		 * gen1 finished.
+		 */
+		status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
+		status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
+		rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
+
+		timeout = jiffies + msecs_to_jiffies(500);
+		for (;;) {
+			status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
+			if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
+					PCIE_CORE_PL_CONF_SPEED_5G) {
+				dev_dbg(dev, "PCIe link training gen2 pass!\n");
+				break;
+			}
 
-	timeout = jiffies + msecs_to_jiffies(500);
-	for (;;) {
-		status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
-		if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
-		    PCIE_CORE_PL_CONF_SPEED_5G) {
-			dev_dbg(dev, "PCIe link training gen2 pass!\n");
-			break;
-		}
+			if (time_after(jiffies, timeout)) {
+				dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
+				break;
+			}
 
-		if (time_after(jiffies, timeout)) {
-			dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
-			break;
+			msleep(20);
 		}
-
-		msleep(20);
 	}
 
 	/* Check the final link width from negotiated lane counter from MGMT */
@@ -781,6 +793,11 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
 		rockchip->lanes = 1;
 	}
 
+	err = of_property_read_u32(node, "rockchip,max-link-speed",
+				   &rockchip->link_gen);
+	if (err)
+		rockchip->link_gen = 1;
+
 	rockchip->core_rst = devm_reset_control_get(dev, "core");
 	if (IS_ERR(rockchip->core_rst)) {
 		if (PTR_ERR(rockchip->core_rst) != -EPROBE_DEFER)
-- 
2.3.7




From briannorris at chromium.org  Tue Oct  4 21:36:48 2016
From: briannorris at chromium.org (Brian Norris)
Date: Tue, 4 Oct 2016 21:36:48 -0700
Subject: [PATCH v2] PCI: rockchip: Support property to specify the link
 capability
In-Reply-To: <1475636776-11386-1-git-send-email-shawn.lin@rock-chips.com>
References: <1475636776-11386-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <20161005043647.GA125531@google.com>

Hi Shawn,

On Wed, Oct 05, 2016 at 11:06:16AM +0800, Shawn Lin wrote:
> From: Brian Norris <briannorris at chromium.org>
> 
> rk3399 supports PCIe 2.x link speeds marginally at best, and on some
> boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500
> ms waiting for training that will never happen, let's add a property
> from devicetree to specify link capability.
> 
> Signed-off-by: Brian Norris <briannorris at chromium.org>
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> 
> ---
> 
> Changes in v2:
> - rename the property to rockchip,max-link-speed according to
>   Bjorn's recommendation and take some bits from imx6q-pcie to
>   make this requirement more consisent.
> 
>  .../devicetree/bindings/pci/rockchip-pcie.txt      |  2 +
>  drivers/pci/host/pcie-rockchip.c                   | 61 ++++++++++++++--------
>  2 files changed, 41 insertions(+), 22 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> index ba67b39..8335f03 100644
> --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> @@ -42,6 +42,8 @@ Required properties:
>  Optional Property:
>  - ep-gpios: contain the entry for pre-reset gpio
>  - num-lanes: number of lanes to use
> +- rockchip,max-link-speed: Specify PCI gen for link capability. Must
> +	be '2' for gen2, otherwise will default to gen1.
>  - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
>  - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe.
>  - vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe.
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index 35591b1..ca3db51 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -53,6 +53,7 @@
>  #define   PCIE_CLIENT_ARI_ENABLE	  HIWORD_UPDATE_BIT(0x0008)
>  #define   PCIE_CLIENT_CONF_LANE_NUM(x)	  HIWORD_UPDATE(0x0030, ENCODE_LANES(x))
>  #define   PCIE_CLIENT_MODE_RC		  HIWORD_UPDATE_BIT(0x0040)
> +#define   PCIE_CLIENT_GEN_SEL_1		  HIWORD_UPDATE(0x0080, 0)
>  #define   PCIE_CLIENT_GEN_SEL_2		  HIWORD_UPDATE_BIT(0x0080)
>  #define PCIE_CLIENT_BASIC_STATUS1	(PCIE_CLIENT_BASE + 0x48)
>  #define   PCIE_CLIENT_LINK_STATUS_UP		0x00300000
> @@ -205,6 +206,7 @@ struct rockchip_pcie {
>  	struct	gpio_desc *ep_gpio;
>  	u32	lanes;
>  	u8	root_bus_nr;
> +	int	link_gen;
>  	struct	device *dev;
>  	struct	irq_domain *irq_domain;
>  };
> @@ -443,13 +445,21 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  		return err;
>  	}
>  
> +	if (rockchip->link_gen == 2) {
> +		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_2,
> +				    PCIE_CLIENT_CONFIG);
> +	} else {
> +		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_1,
> +				    PCIE_CLIENT_CONFIG);
> +		dev_info(dev, "max link speed is gen 1\n");
> +	}
> +
>  	rockchip_pcie_write(rockchip,
>  			    PCIE_CLIENT_CONF_ENABLE |
>  			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
>  			    PCIE_CLIENT_ARI_ENABLE |
>  			    PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
> -			    PCIE_CLIENT_MODE_RC |
> -			    PCIE_CLIENT_GEN_SEL_2,
> +			    PCIE_CLIENT_MODE_RC,
>  				PCIE_CLIENT_CONFIG);
>  
>  	err = phy_power_on(rockchip->phy);
> @@ -550,29 +560,31 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  		msleep(20);
>  	}
>  
> -	/*
> -	 * Enable retrain for gen2. This should be configured only after
> -	 * gen1 finished.
> -	 */
> -	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> -	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
> -	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> +	if (rockchip->link_gen == 2) {
> +		/*
> +		 * Enable retrain for gen2. This should be configured only after
> +		 * gen1 finished.
> +		 */
> +		status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> +		status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
> +		rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> +
> +		timeout = jiffies + msecs_to_jiffies(500);
> +		for (;;) {
> +			status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
> +			if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
> +					PCIE_CORE_PL_CONF_SPEED_5G) {
> +				dev_dbg(dev, "PCIe link training gen2 pass!\n");
> +				break;
> +			}
>  
> -	timeout = jiffies + msecs_to_jiffies(500);
> -	for (;;) {
> -		status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
> -		if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
> -		    PCIE_CORE_PL_CONF_SPEED_5G) {
> -			dev_dbg(dev, "PCIe link training gen2 pass!\n");
> -			break;
> -		}
> +			if (time_after(jiffies, timeout)) {
> +				dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
> +				break;
> +			}
>  
> -		if (time_after(jiffies, timeout)) {
> -			dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
> -			break;
> +			msleep(20);
>  		}
> -
> -		msleep(20);
>  	}
>  
>  	/* Check the final link width from negotiated lane counter from MGMT */
> @@ -781,6 +793,11 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
>  		rockchip->lanes = 1;
>  	}
>  
> +	err = of_property_read_u32(node, "rockchip,max-link-speed",
> +				   &rockchip->link_gen);
> +	if (err)
> +		rockchip->link_gen = 1;

I realize you copied this from the IMX6 driver, but this allows people
to put anything but '2' in the property, and we'll treat it like '1'.
How about in the !err case, we check that the value is either 1 or 2,
and return an error for anything else?

Brian

> +
>  	rockchip->core_rst = devm_reset_control_get(dev, "core");
>  	if (IS_ERR(rockchip->core_rst)) {
>  		if (PTR_ERR(rockchip->core_rst) != -EPROBE_DEFER)
> -- 
> 2.3.7
> 
> 


From paweljarosz3691 at gmail.com  Tue Oct  4 23:09:17 2016
From: paweljarosz3691 at gmail.com (=?UTF-8?Q?Pawe=c5=82_Jarosz?=)
Date: Wed, 5 Oct 2016 08:09:17 +0200
Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on
 rk3066
In-Reply-To: <6239b970-09d3-f7ee-e6f5-c019eaedb725@rock-chips.com>
References: <20161001140939.GA31220@vaio-ubuntu>
 <6239b970-09d3-f7ee-e6f5-c019eaedb725@rock-chips.com>
Message-ID: <f8aba48d-6c69-b246-4cb2-48a2770c80e4@gmail.com>

Hi


W dniu 05.10.2016 o 04:27, Huang, Tao pisze:
> Hi, Pawe?:
> On 2016?10?01? 22:09, =?UTF-8?q?Pawe=C5=82=20Jarosz?= wrote:
>> For some reason accessing memory region above 0xfe000000 freezes
>> system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> RK3066 only support 2GB memory from 0x60000000 to 0xE0000000, can not access
> above 0xfe000000. I think you mean 0x9F000000?
Yes i meant 0x9F00000. Sorry for that.
> I don't remember RK3066 has such limit. I will double check with our IC
> design team.
> Do you know which master can not access this memory area
> [0x9F000000~0xA0000000)?
I don't.
> Could you please tell which board you're using (and how much memory it has)
Rikomagic MK808 1GB RAM

Thanks
Pawel



From shawn.lin at rock-chips.com  Wed Oct  5 00:41:54 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 5 Oct 2016 15:41:54 +0800
Subject: [PATCH v2] PCI: rockchip: Support property to specify the link
 capability
In-Reply-To: <20161005043647.GA125531@google.com>
References: <1475636776-11386-1-git-send-email-shawn.lin@rock-chips.com>
 <20161005043647.GA125531@google.com>
Message-ID: <6dc5a9b2-8ac3-93a5-3f82-143beeaeebee@rock-chips.com>

Hi Brian,

? 2016/10/5 12:36, Brian Norris ??:
> Hi Shawn,
>
> On Wed, Oct 05, 2016 at 11:06:16AM +0800, Shawn Lin wrote:
>> From: Brian Norris <briannorris at chromium.org>
>>
>> rk3399 supports PCIe 2.x link speeds marginally at best, and on some
>> boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500
>> ms waiting for training that will never happen, let's add a property
>> from devicetree to specify link capability.
>>
>> Signed-off-by: Brian Norris <briannorris at chromium.org>
>> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>>
>> ---
>>
>> Changes in v2:
>> - rename the property to rockchip,max-link-speed according to
>>   Bjorn's recommendation and take some bits from imx6q-pcie to
>>   make this requirement more consisent.
>>
>>  .../devicetree/bindings/pci/rockchip-pcie.txt      |  2 +
>>  drivers/pci/host/pcie-rockchip.c                   | 61 ++++++++++++++--------
>>  2 files changed, 41 insertions(+), 22 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
>> index ba67b39..8335f03 100644
>> --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
>> @@ -42,6 +42,8 @@ Required properties:
>>  Optional Property:
>>  - ep-gpios: contain the entry for pre-reset gpio
>>  - num-lanes: number of lanes to use
>> +- rockchip,max-link-speed: Specify PCI gen for link capability. Must
>> +	be '2' for gen2, otherwise will default to gen1.
>>  - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
>>  - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe.
>>  - vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe.
>> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
>> index 35591b1..ca3db51 100644
>> --- a/drivers/pci/host/pcie-rockchip.c
>> +++ b/drivers/pci/host/pcie-rockchip.c
>> @@ -53,6 +53,7 @@
>>  #define   PCIE_CLIENT_ARI_ENABLE	  HIWORD_UPDATE_BIT(0x0008)
>>  #define   PCIE_CLIENT_CONF_LANE_NUM(x)	  HIWORD_UPDATE(0x0030, ENCODE_LANES(x))
>>  #define   PCIE_CLIENT_MODE_RC		  HIWORD_UPDATE_BIT(0x0040)
>> +#define   PCIE_CLIENT_GEN_SEL_1		  HIWORD_UPDATE(0x0080, 0)
>>  #define   PCIE_CLIENT_GEN_SEL_2		  HIWORD_UPDATE_BIT(0x0080)
>>  #define PCIE_CLIENT_BASIC_STATUS1	(PCIE_CLIENT_BASE + 0x48)
>>  #define   PCIE_CLIENT_LINK_STATUS_UP		0x00300000
>> @@ -205,6 +206,7 @@ struct rockchip_pcie {
>>  	struct	gpio_desc *ep_gpio;
>>  	u32	lanes;
>>  	u8	root_bus_nr;
>> +	int	link_gen;
>>  	struct	device *dev;
>>  	struct	irq_domain *irq_domain;
>>  };
>> @@ -443,13 +445,21 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>>  		return err;
>>  	}
>>
>> +	if (rockchip->link_gen == 2) {
>> +		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_2,
>> +				    PCIE_CLIENT_CONFIG);
>> +	} else {
>> +		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_1,
>> +				    PCIE_CLIENT_CONFIG);
>> +		dev_info(dev, "max link speed is gen 1\n");
>> +	}
>> +
>>  	rockchip_pcie_write(rockchip,
>>  			    PCIE_CLIENT_CONF_ENABLE |
>>  			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
>>  			    PCIE_CLIENT_ARI_ENABLE |
>>  			    PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
>> -			    PCIE_CLIENT_MODE_RC |
>> -			    PCIE_CLIENT_GEN_SEL_2,
>> +			    PCIE_CLIENT_MODE_RC,
>>  				PCIE_CLIENT_CONFIG);
>>
>>  	err = phy_power_on(rockchip->phy);
>> @@ -550,29 +560,31 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>>  		msleep(20);
>>  	}
>>
>> -	/*
>> -	 * Enable retrain for gen2. This should be configured only after
>> -	 * gen1 finished.
>> -	 */
>> -	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
>> -	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
>> -	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>> +	if (rockchip->link_gen == 2) {
>> +		/*
>> +		 * Enable retrain for gen2. This should be configured only after
>> +		 * gen1 finished.
>> +		 */
>> +		status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
>> +		status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
>> +		rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>> +
>> +		timeout = jiffies + msecs_to_jiffies(500);
>> +		for (;;) {
>> +			status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
>> +			if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
>> +					PCIE_CORE_PL_CONF_SPEED_5G) {
>> +				dev_dbg(dev, "PCIe link training gen2 pass!\n");
>> +				break;
>> +			}
>>
>> -	timeout = jiffies + msecs_to_jiffies(500);
>> -	for (;;) {
>> -		status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
>> -		if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
>> -		    PCIE_CORE_PL_CONF_SPEED_5G) {
>> -			dev_dbg(dev, "PCIe link training gen2 pass!\n");
>> -			break;
>> -		}
>> +			if (time_after(jiffies, timeout)) {
>> +				dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
>> +				break;
>> +			}
>>
>> -		if (time_after(jiffies, timeout)) {
>> -			dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
>> -			break;
>> +			msleep(20);
>>  		}
>> -
>> -		msleep(20);
>>  	}
>>
>>  	/* Check the final link width from negotiated lane counter from MGMT */
>> @@ -781,6 +793,11 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
>>  		rockchip->lanes = 1;
>>  	}
>>
>> +	err = of_property_read_u32(node, "rockchip,max-link-speed",
>> +				   &rockchip->link_gen);
>> +	if (err)
>> +		rockchip->link_gen = 1;
>
> I realize you copied this from the IMX6 driver, but this allows people
> to put anything but '2' in the property, and we'll treat it like '1'.
> How about in the !err case, we check that the value is either 1 or 2,
> and return an error for anything else?
>

Sounds fine, but it shouldn't return error for anything else. We should
fall back to default state, namely gen 1. And we could cast a warning
there just like what we did for num-lanes.

I will respin v3.

Thanks.

> Brian
>
>> +
>>  	rockchip->core_rst = devm_reset_control_get(dev, "core");
>>  	if (IS_ERR(rockchip->core_rst)) {
>>  		if (PTR_ERR(rockchip->core_rst) != -EPROBE_DEFER)
>> --
>> 2.3.7
>>
>>
>
>
>


-- 
Best Regards
Shawn Lin



From shawn.lin at rock-chips.com  Wed Oct  5 01:05:17 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed,  5 Oct 2016 16:05:17 +0800
Subject: [PATCH v3] PCI: rockchip: Support property to specify the link
 capability
Message-ID: <1475654717-15159-1-git-send-email-shawn.lin@rock-chips.com>

From: Brian Norris <briannorris at chromium.org>

rk3399 supports PCIe 2.x link speeds marginally at best, and on some
boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500
ms waiting for training that will never happen, let's add a property
from devicetree to specify link capability.

Signed-off-by: Brian Norris <briannorris at chromium.org>
Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v3:
- Cast a warning for invalid max link speed and use gen1 for it.
  That looks better than v2. (Suggested by Brian)

Changes in v2:
- rename the property to rockchip,max-link-speed according to
  Bjorn's recommendation and take some bits from imx6q-pcie to
  make this requirement more consisent.

 .../devicetree/bindings/pci/rockchip-pcie.txt      |  2 +
 drivers/pci/host/pcie-rockchip.c                   | 62 ++++++++++++++--------
 2 files changed, 42 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
index ba67b39..7bb730e 100644
--- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
@@ -42,6 +42,8 @@ Required properties:
 Optional Property:
 - ep-gpios: contain the entry for pre-reset gpio
 - num-lanes: number of lanes to use
+- rockchip,max-link-speed: Specify PCI gen for link capability. Must
+	be '2' for gen2, and '1' for gen1, otherwise will default to gen1.
 - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
 - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe.
 - vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe.
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 35591b1..66476ea 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -53,6 +53,7 @@
 #define   PCIE_CLIENT_ARI_ENABLE	  HIWORD_UPDATE_BIT(0x0008)
 #define   PCIE_CLIENT_CONF_LANE_NUM(x)	  HIWORD_UPDATE(0x0030, ENCODE_LANES(x))
 #define   PCIE_CLIENT_MODE_RC		  HIWORD_UPDATE_BIT(0x0040)
+#define   PCIE_CLIENT_GEN_SEL_1		  HIWORD_UPDATE(0x0080, 0)
 #define   PCIE_CLIENT_GEN_SEL_2		  HIWORD_UPDATE_BIT(0x0080)
 #define PCIE_CLIENT_BASIC_STATUS1	(PCIE_CLIENT_BASE + 0x48)
 #define   PCIE_CLIENT_LINK_STATUS_UP		0x00300000
@@ -205,6 +206,7 @@ struct rockchip_pcie {
 	struct	gpio_desc *ep_gpio;
 	u32	lanes;
 	u8	root_bus_nr;
+	int	link_gen;
 	struct	device *dev;
 	struct	irq_domain *irq_domain;
 };
@@ -443,13 +445,19 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		return err;
 	}
 
+	if (rockchip->link_gen == 2)
+		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_2,
+				    PCIE_CLIENT_CONFIG);
+	else
+		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_1,
+				    PCIE_CLIENT_CONFIG);
+
 	rockchip_pcie_write(rockchip,
 			    PCIE_CLIENT_CONF_ENABLE |
 			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
 			    PCIE_CLIENT_ARI_ENABLE |
 			    PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
-			    PCIE_CLIENT_MODE_RC |
-			    PCIE_CLIENT_GEN_SEL_2,
+			    PCIE_CLIENT_MODE_RC,
 				PCIE_CLIENT_CONFIG);
 
 	err = phy_power_on(rockchip->phy);
@@ -550,29 +558,31 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		msleep(20);
 	}
 
-	/*
-	 * Enable retrain for gen2. This should be configured only after
-	 * gen1 finished.
-	 */
-	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
-	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
-	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
+	if (rockchip->link_gen == 2) {
+		/*
+		 * Enable retrain for gen2. This should be configured only after
+		 * gen1 finished.
+		 */
+		status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
+		status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
+		rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
+
+		timeout = jiffies + msecs_to_jiffies(500);
+		for (;;) {
+			status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
+			if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
+					PCIE_CORE_PL_CONF_SPEED_5G) {
+				dev_dbg(dev, "PCIe link training gen2 pass!\n");
+				break;
+			}
 
-	timeout = jiffies + msecs_to_jiffies(500);
-	for (;;) {
-		status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
-		if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
-		    PCIE_CORE_PL_CONF_SPEED_5G) {
-			dev_dbg(dev, "PCIe link training gen2 pass!\n");
-			break;
-		}
+			if (time_after(jiffies, timeout)) {
+				dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
+				break;
+			}
 
-		if (time_after(jiffies, timeout)) {
-			dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
-			break;
+			msleep(20);
 		}
-
-		msleep(20);
 	}
 
 	/* Check the final link width from negotiated lane counter from MGMT */
@@ -781,6 +791,14 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
 		rockchip->lanes = 1;
 	}
 
+	rockchip->link_gen = 2;
+	err = of_property_read_u32(node, "rockchip,max-link-speed",
+				   &rockchip->link_gen);
+	if (!err && rockchip->link_gen != 1 && rockchip->link_gen != 2) {
+		dev_warn(dev, "invalid max-link-speed, default to use gen1\n");
+		rockchip->link_gen = 1;
+	}
+
 	rockchip->core_rst = devm_reset_control_get(dev, "core");
 	if (IS_ERR(rockchip->core_rst)) {
 		if (PTR_ERR(rockchip->core_rst) != -EPROBE_DEFER)
-- 
2.3.7




From shawn.lin at rock-chips.com  Wed Oct  5 01:50:16 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed,  5 Oct 2016 16:50:16 +0800
Subject: [PATCH 1/2] PCI: rockchip: Provide captured slot power limit and scale
Message-ID: <1475657417-29163-1-git-send-email-shawn.lin@rock-chips.com>

If vpcie3v3 is available, we could provide these information
via RC's configure register to make EP able to know the power
limit.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/pci/host/pcie-rockchip.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index b8c82fc..7d16669 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -135,6 +135,10 @@
 #define PCIE_RC_CONFIG_VENDOR		(PCIE_RC_CONFIG_BASE + 0x00)
 #define PCIE_RC_CONFIG_RID_CCR		(PCIE_RC_CONFIG_BASE + 0x08)
 #define   PCIE_RC_CONFIG_SCC_SHIFT		16
+#define PCIE_RC_CONFIG_DCR		(PCIE_RC_CONFIG_BASE + 0xc4)
+#define   PCIE_RC_CONFIG_DCR_CSPL_SHIFT		18
+#define   PCIE_RC_CONFIG_DCR_CSPL_LIMIT		0xff
+#define   PCIE_RC_CONFIG_DCR_CPLS_SHIFT		26
 #define PCIE_RC_CONFIG_LCS		(PCIE_RC_CONFIG_BASE + 0xd0)
 #define   PCIE_RC_CONFIG_LCS_RETRAIN_LINK	BIT(5)
 #define   PCIE_RC_CONFIG_LCS_LBMIE		BIT(10)
@@ -395,6 +399,40 @@ static struct pci_ops rockchip_pcie_ops = {
 	.write = rockchip_pcie_wr_conf,
 };
 
+static void rockchip_pcie_set_power_limit(struct rockchip_pcie *rockchip)
+{
+	u32 status, curr, scale, power;
+
+	if (IS_ERR(rockchip->vpcie3v3))
+		return;
+
+	/*
+	 * Set RC's captured slot power limit and scale if
+	 * vpcie3v3 available. The default values are both zero
+	 * which means the software should set these two according
+	 * to the actual power supply.
+	 */
+	curr = regulator_get_current_limit(rockchip->vpcie3v3);
+	if (curr > 0) {
+		scale = 3; /* 0.001x */
+		curr = curr / 1000; /* convert to mA */
+		power = (curr * 3300) / 1000; /* milliwatt */
+		while (power > PCIE_RC_CONFIG_DCR_CSPL_LIMIT) {
+			if (!scale) {
+				dev_warn(rockchip->dev, "invalid power supply\n");
+				return;
+			}
+			scale--;
+			power = power / 10;
+		}
+
+		status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_DCR);
+		status |= (power << PCIE_RC_CONFIG_DCR_CSPL_SHIFT) |
+			  (scale << PCIE_RC_CONFIG_DCR_CPLS_SHIFT);
+		rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_DCR);
+	}
+}
+
 /**
  * rockchip_pcie_init_port - Initialize hardware
  * @rockchip: PCIe port information
@@ -496,6 +534,8 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		 (PCIE_CORE_CTRL_PLC1_FTS_CNT << PCIE_CORE_CTRL_PLC1_FTS_SHIFT);
 	rockchip_pcie_write(rockchip, status, PCIE_CORE_CTRL_PLC1);
 
+	rockchip_pcie_set_power_limit(rockchip);
+
 	/* Enable Gen1 training */
 	rockchip_pcie_write(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
 			    PCIE_CLIENT_CONFIG);
-- 
2.3.7




From shawn.lin at rock-chips.com  Wed Oct  5 01:50:17 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed,  5 Oct 2016 16:50:17 +0800
Subject: [PATCH 2/2] PCI: rockchip: Mark RC as common clock architecture
In-Reply-To: <1475657417-29163-1-git-send-email-shawn.lin@rock-chips.com>
References: <1475657417-29163-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1475657417-29163-2-git-send-email-shawn.lin@rock-chips.com>

The default value of common clock configuration is
zero indicating Rockchip's RC is using asynchronous
clock architecture but actually we are using common
clock. This will confuses some EP drivers if they
need some different settings referring to this value.
So let's fix it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/pci/host/pcie-rockchip.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 7d16669..f204f8b 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -141,6 +141,7 @@
 #define   PCIE_RC_CONFIG_DCR_CPLS_SHIFT		26
 #define PCIE_RC_CONFIG_LCS		(PCIE_RC_CONFIG_BASE + 0xd0)
 #define   PCIE_RC_CONFIG_LCS_RETRAIN_LINK	BIT(5)
+#define   PCIE_RC_CONFIG_LCS_CCC		BIT(6)
 #define   PCIE_RC_CONFIG_LCS_LBMIE		BIT(10)
 #define   PCIE_RC_CONFIG_LCS_LABIE		BIT(11)
 #define   PCIE_RC_CONFIG_LCS_LBMS		BIT(30)
@@ -536,6 +537,11 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 
 	rockchip_pcie_set_power_limit(rockchip);
 
+	/* Set RC's clock architecture as common clock */
+	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
+	status |= PCIE_RC_CONFIG_LCS_CCC;
+	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
+
 	/* Enable Gen1 training */
 	rockchip_pcie_write(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
 			    PCIE_CLIENT_CONFIG);
-- 
2.3.7




From jdelvare at suse.de  Wed Oct  5 08:17:04 2016
From: jdelvare at suse.de (Jean Delvare)
Date: Wed, 5 Oct 2016 17:17:04 +0200
Subject: [PATCH] i2c: don't print error when adding adapter fails
In-Reply-To: <1470742581-12971-2-git-send-email-wsa-dev@sang-engineering.com>
References: <1470742581-12971-1-git-send-email-wsa-dev@sang-engineering.com>
 <1470742581-12971-2-git-send-email-wsa-dev@sang-engineering.com>
Message-ID: <20161005171704.18fe1b9f@endymion>

On Tue,  9 Aug 2016 13:36:17 +0200, Wolfram Sang wrote:
> The core will do this for us now.
> 
> Signed-off-by: Wolfram Sang <wsa-dev at sang-engineering.com>
> ---
>  drivers/i2c/busses/i2c-amd756.c         | 5 +----
>  drivers/i2c/busses/i2c-at91.c           | 2 --
>  drivers/i2c/busses/i2c-axxia.c          | 8 +-------
>  drivers/i2c/busses/i2c-bcm-iproc.c      | 8 +-------
>  drivers/i2c/busses/i2c-bcm-kona.c       | 4 +---
>  drivers/i2c/busses/i2c-bfin-twi.c       | 4 +---
>  drivers/i2c/busses/i2c-brcmstb.c        | 4 +---
>  drivers/i2c/busses/i2c-cadence.c        | 4 +---
>  drivers/i2c/busses/i2c-cpm.c            | 4 +---
>  drivers/i2c/busses/i2c-cros-ec-tunnel.c | 4 +---
>  drivers/i2c/busses/i2c-davinci.c        | 4 +---
>  drivers/i2c/busses/i2c-diolan-u2c.c     | 4 +---
>  drivers/i2c/busses/i2c-dln2.c           | 4 +---
>  drivers/i2c/busses/i2c-efm32.c          | 1 -
>  drivers/i2c/busses/i2c-exynos5.c        | 4 +---
>  drivers/i2c/busses/i2c-hix5hd2.c        | 4 +---
>  drivers/i2c/busses/i2c-i801.c           | 1 -
>  drivers/i2c/busses/i2c-ibm_iic.c        | 4 +---
>  drivers/i2c/busses/i2c-img-scb.c        | 4 +---
>  drivers/i2c/busses/i2c-imx.c            | 4 +---
>  drivers/i2c/busses/i2c-isch.c           | 4 +---
>  drivers/i2c/busses/i2c-ismt.c           | 4 +---
>  drivers/i2c/busses/i2c-jz4780.c         | 4 +---
>  drivers/i2c/busses/i2c-lpc2k.c          | 4 +---
>  drivers/i2c/busses/i2c-meson.c          | 1 -
>  drivers/i2c/busses/i2c-mpc.c            | 4 +---
>  drivers/i2c/busses/i2c-mt65xx.c         | 4 +---
>  drivers/i2c/busses/i2c-mxs.c            | 1 -
>  drivers/i2c/busses/i2c-nforce2.c        | 1 -
>  drivers/i2c/busses/i2c-nomadik.c        | 4 +---
>  drivers/i2c/busses/i2c-ocores.c         | 4 +---
>  drivers/i2c/busses/i2c-octeon.c         | 4 +---
>  drivers/i2c/busses/i2c-omap.c           | 4 +---
>  drivers/i2c/busses/i2c-piix4.c          | 1 -
>  drivers/i2c/busses/i2c-pmcmsp.c         | 4 +---
>  drivers/i2c/busses/i2c-pnx.c            | 4 +---
>  drivers/i2c/busses/i2c-puv3.c           | 5 +----
>  drivers/i2c/busses/i2c-pxa.c            | 4 +---
>  drivers/i2c/busses/i2c-rcar.c           | 4 +---
>  drivers/i2c/busses/i2c-riic.c           | 4 +---
>  drivers/i2c/busses/i2c-rk3x.c           | 4 +---
>  drivers/i2c/busses/i2c-s3c2410.c        | 1 -
>  drivers/i2c/busses/i2c-sh7760.c         | 4 +---
>  drivers/i2c/busses/i2c-sh_mobile.c      | 1 -
>  drivers/i2c/busses/i2c-sirf.c           | 4 +---
>  drivers/i2c/busses/i2c-st.c             | 4 +---
>  drivers/i2c/busses/i2c-stu300.c         | 5 +----
>  drivers/i2c/busses/i2c-tegra.c          | 4 +---
>  drivers/i2c/busses/i2c-uniphier-f.c     | 7 +------
>  drivers/i2c/busses/i2c-uniphier.c       | 7 +------
>  drivers/i2c/busses/i2c-wmt.c            | 4 +---
>  drivers/i2c/busses/i2c-xgene-slimpro.c  | 1 -
>  drivers/i2c/busses/i2c-xiic.c           | 1 -
>  drivers/i2c/busses/i2c-xlp9xx.c         | 4 +---
>  drivers/i2c/busses/i2c-xlr.c            | 4 +---
>  55 files changed, 44 insertions(+), 161 deletions(-)
> (...)

I like the idea.

For i2c-amd756, i2c-diolan-u2c, i2c-i801, i2c-isch, i2c-ismt,
i2c-nforce and i2c-piix4:

Reviewed-by: Jean Delvare <jdelvare at suse.de>

-- 
Jean Delvare
SUSE L3 Support


From paweljarosz3691 at gmail.com  Wed Oct  5 09:18:11 2016
From: paweljarosz3691 at gmail.com (=?us-ascii?B?PT9VVEYtOD9xP1Bhd2U9QzU9ODI9MjBKYXJvc3o/PQ==?=)
Date: Wed, 5 Oct 2016 18:18:11 +0200
Subject: [PATCH v2] ARM: dts: rockchip: Reserve unusable memory region on
 rk3066
Message-ID: <20161005161811.GA17211@vaio-ubuntu>

For some reason accessing memory region above 0x9F000000 freezes
system on rk3066. There is similiar bug on later rockchip soc (rk3288)
solved same way.

Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
---

Changes in v2:
- updated commit message.

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

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 0d0dae3..44c8956 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -93,6 +93,19 @@
 		};
 	};
 
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/*
+		 * The rk3066 cannot use the memory area above 0x9F000000
+		 * for some unknown reason.
+		 */
+		unusable at 9F000000 {
+			reg = <0x9F000000 0x1000000>;
+		};
+	};
+
 	i2s0: i2s at 10118000 {
 		compatible = "rockchip,rk3066-i2s";
 		reg = <0x10118000 0x2000>;
-- 
2.7.4



From briannorris at chromium.org  Wed Oct  5 15:46:43 2016
From: briannorris at chromium.org (Brian Norris)
Date: Wed, 5 Oct 2016 15:46:43 -0700
Subject: [PATCH v3] PCI: rockchip: Support property to specify the link
 capability
In-Reply-To: <1475654717-15159-1-git-send-email-shawn.lin@rock-chips.com>
References: <1475654717-15159-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <20161005224642.GA111810@google.com>

Hi,

On Wed, Oct 05, 2016 at 04:05:17PM +0800, Shawn Lin wrote:
> From: Brian Norris <briannorris at chromium.org>
> 
> rk3399 supports PCIe 2.x link speeds marginally at best, and on some
> boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500
> ms waiting for training that will never happen, let's add a property
> from devicetree to specify link capability.
> 
> Signed-off-by: Brian Norris <briannorris at chromium.org>
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> 
> ---
> 
> Changes in v3:
> - Cast a warning for invalid max link speed and use gen1 for it.
>   That looks better than v2. (Suggested by Brian)
> 
> Changes in v2:
> - rename the property to rockchip,max-link-speed according to
>   Bjorn's recommendation and take some bits from imx6q-pcie to
>   make this requirement more consisent.
> 
>  .../devicetree/bindings/pci/rockchip-pcie.txt      |  2 +
>  drivers/pci/host/pcie-rockchip.c                   | 62 ++++++++++++++--------
>  2 files changed, 42 insertions(+), 22 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> index ba67b39..7bb730e 100644
> --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> @@ -42,6 +42,8 @@ Required properties:
>  Optional Property:
>  - ep-gpios: contain the entry for pre-reset gpio
>  - num-lanes: number of lanes to use
> +- rockchip,max-link-speed: Specify PCI gen for link capability. Must
> +	be '2' for gen2, and '1' for gen1, otherwise will default to gen1.

I'm still not sure why we want incorrect DT entries to default to 1
instead of just being rejected as incorrect (i.e., and error). But
assuming people are OK with that behavior, I'll review the rest...

>  - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
>  - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe.
>  - vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe.
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index 35591b1..66476ea 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -53,6 +53,7 @@
>  #define   PCIE_CLIENT_ARI_ENABLE	  HIWORD_UPDATE_BIT(0x0008)
>  #define   PCIE_CLIENT_CONF_LANE_NUM(x)	  HIWORD_UPDATE(0x0030, ENCODE_LANES(x))
>  #define   PCIE_CLIENT_MODE_RC		  HIWORD_UPDATE_BIT(0x0040)
> +#define   PCIE_CLIENT_GEN_SEL_1		  HIWORD_UPDATE(0x0080, 0)
>  #define   PCIE_CLIENT_GEN_SEL_2		  HIWORD_UPDATE_BIT(0x0080)
>  #define PCIE_CLIENT_BASIC_STATUS1	(PCIE_CLIENT_BASE + 0x48)
>  #define   PCIE_CLIENT_LINK_STATUS_UP		0x00300000
> @@ -205,6 +206,7 @@ struct rockchip_pcie {
>  	struct	gpio_desc *ep_gpio;
>  	u32	lanes;
>  	u8	root_bus_nr;
> +	int	link_gen;
>  	struct	device *dev;
>  	struct	irq_domain *irq_domain;
>  };
> @@ -443,13 +445,19 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  		return err;
>  	}
>  
> +	if (rockchip->link_gen == 2)
> +		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_2,
> +				    PCIE_CLIENT_CONFIG);
> +	else
> +		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_1,
> +				    PCIE_CLIENT_CONFIG);
> +
>  	rockchip_pcie_write(rockchip,
>  			    PCIE_CLIENT_CONF_ENABLE |
>  			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
>  			    PCIE_CLIENT_ARI_ENABLE |
>  			    PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
> -			    PCIE_CLIENT_MODE_RC |
> -			    PCIE_CLIENT_GEN_SEL_2,
> +			    PCIE_CLIENT_MODE_RC,
>  				PCIE_CLIENT_CONFIG);
>  
>  	err = phy_power_on(rockchip->phy);
> @@ -550,29 +558,31 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  		msleep(20);
>  	}
>  
> -	/*
> -	 * Enable retrain for gen2. This should be configured only after
> -	 * gen1 finished.
> -	 */
> -	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> -	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
> -	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> +	if (rockchip->link_gen == 2) {
> +		/*
> +		 * Enable retrain for gen2. This should be configured only after
> +		 * gen1 finished.
> +		 */
> +		status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> +		status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
> +		rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> +
> +		timeout = jiffies + msecs_to_jiffies(500);
> +		for (;;) {
> +			status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
> +			if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
> +					PCIE_CORE_PL_CONF_SPEED_5G) {
> +				dev_dbg(dev, "PCIe link training gen2 pass!\n");
> +				break;
> +			}
>  
> -	timeout = jiffies + msecs_to_jiffies(500);
> -	for (;;) {
> -		status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
> -		if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
> -		    PCIE_CORE_PL_CONF_SPEED_5G) {
> -			dev_dbg(dev, "PCIe link training gen2 pass!\n");
> -			break;
> -		}
> +			if (time_after(jiffies, timeout)) {
> +				dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
> +				break;
> +			}
>  
> -		if (time_after(jiffies, timeout)) {
> -			dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
> -			break;
> +			msleep(20);
>  		}
> -
> -		msleep(20);
>  	}
>  
>  	/* Check the final link width from negotiated lane counter from MGMT */
> @@ -781,6 +791,14 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
>  		rockchip->lanes = 1;
>  	}
>  
> +	rockchip->link_gen = 2;

Isn't the above assignment violating the binding doc? Setting to 2 means
that if the property isn't found, we default to gen2. That's OK with me,
but you should make the binding doc match it.

> +	err = of_property_read_u32(node, "rockchip,max-link-speed",
> +				   &rockchip->link_gen);

^^ you can get sign errors here, since link_gen is 'int', but this
function reads 'u32'. Maybe use a temporary u32.

Brian

> +	if (!err && rockchip->link_gen != 1 && rockchip->link_gen != 2) {
> +		dev_warn(dev, "invalid max-link-speed, default to use gen1\n");
> +		rockchip->link_gen = 1;
> +	}
> +
>  	rockchip->core_rst = devm_reset_control_get(dev, "core");
>  	if (IS_ERR(rockchip->core_rst)) {
>  		if (PTR_ERR(rockchip->core_rst) != -EPROBE_DEFER)
> -- 
> 2.3.7
> 
> 


From shawn.lin at rock-chips.com  Wed Oct  5 19:00:04 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Thu, 6 Oct 2016 10:00:04 +0800
Subject: [PATCH v3] PCI: rockchip: Support property to specify the link
 capability
In-Reply-To: <20161005224642.GA111810@google.com>
References: <1475654717-15159-1-git-send-email-shawn.lin@rock-chips.com>
 <20161005224642.GA111810@google.com>
Message-ID: <d81bcc67-22cc-774c-d9f3-445633303278@rock-chips.com>

? 2016/10/6 6:46, Brian Norris ??:
> Hi,
>
> On Wed, Oct 05, 2016 at 04:05:17PM +0800, Shawn Lin wrote:
>> From: Brian Norris <briannorris at chromium.org>
>>
>> rk3399 supports PCIe 2.x link speeds marginally at best, and on some
>> boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500
>> ms waiting for training that will never happen, let's add a property
>> from devicetree to specify link capability.
>>
>> Signed-off-by: Brian Norris <briannorris at chromium.org>
>> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>>
>> ---
>>
>> Changes in v3:
>> - Cast a warning for invalid max link speed and use gen1 for it.
>>   That looks better than v2. (Suggested by Brian)
>>
>> Changes in v2:
>> - rename the property to rockchip,max-link-speed according to
>>   Bjorn's recommendation and take some bits from imx6q-pcie to
>>   make this requirement more consisent.
>>
>>  .../devicetree/bindings/pci/rockchip-pcie.txt      |  2 +
>>  drivers/pci/host/pcie-rockchip.c                   | 62 ++++++++++++++--------
>>  2 files changed, 42 insertions(+), 22 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
>> index ba67b39..7bb730e 100644
>> --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
>> @@ -42,6 +42,8 @@ Required properties:
>>  Optional Property:
>>  - ep-gpios: contain the entry for pre-reset gpio
>>  - num-lanes: number of lanes to use
>> +- rockchip,max-link-speed: Specify PCI gen for link capability. Must
>> +	be '2' for gen2, and '1' for gen1, otherwise will default to gen1.
>
> I'm still not sure why we want incorrect DT entries to default to 1
> instead of just being rejected as incorrect (i.e., and error). But
> assuming people are OK with that behavior, I'll review the rest...

yep, personally I don't like to stop driver from running or to
trigger BUG_ON only if the incorrect DT value. If that happens, it
implies we should deploy proper error handling and cast a warning
should be enough for people to debug. If the max-link-speed is
incorrect, I assume the owner of this DT doesn't actually read
the doc at all. At least he/she doesn't know what this property means.
So we could use the *nature* capability for sure it could bring up
the boards, for instance 1 lanes, gen1... etc.

I was told to write code like this and have been insisting on this for
quite a long time. Does it sound sane to you? :)

>
>>  - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
>>  - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe.
>>  - vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe.
>> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
>> index 35591b1..66476ea 100644
>> --- a/drivers/pci/host/pcie-rockchip.c
>> +++ b/drivers/pci/host/pcie-rockchip.c
>> @@ -53,6 +53,7 @@
>>  #define   PCIE_CLIENT_ARI_ENABLE	  HIWORD_UPDATE_BIT(0x0008)
>>  #define   PCIE_CLIENT_CONF_LANE_NUM(x)	  HIWORD_UPDATE(0x0030, ENCODE_LANES(x))
>>  #define   PCIE_CLIENT_MODE_RC		  HIWORD_UPDATE_BIT(0x0040)
>> +#define   PCIE_CLIENT_GEN_SEL_1		  HIWORD_UPDATE(0x0080, 0)
>>  #define   PCIE_CLIENT_GEN_SEL_2		  HIWORD_UPDATE_BIT(0x0080)
>>  #define PCIE_CLIENT_BASIC_STATUS1	(PCIE_CLIENT_BASE + 0x48)
>>  #define   PCIE_CLIENT_LINK_STATUS_UP		0x00300000
>> @@ -205,6 +206,7 @@ struct rockchip_pcie {
>>  	struct	gpio_desc *ep_gpio;
>>  	u32	lanes;
>>  	u8	root_bus_nr;
>> +	int	link_gen;
>>  	struct	device *dev;
>>  	struct	irq_domain *irq_domain;
>>  };
>> @@ -443,13 +445,19 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>>  		return err;
>>  	}
>>
>> +	if (rockchip->link_gen == 2)
>> +		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_2,
>> +				    PCIE_CLIENT_CONFIG);
>> +	else
>> +		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_1,
>> +				    PCIE_CLIENT_CONFIG);
>> +
>>  	rockchip_pcie_write(rockchip,
>>  			    PCIE_CLIENT_CONF_ENABLE |
>>  			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
>>  			    PCIE_CLIENT_ARI_ENABLE |
>>  			    PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
>> -			    PCIE_CLIENT_MODE_RC |
>> -			    PCIE_CLIENT_GEN_SEL_2,
>> +			    PCIE_CLIENT_MODE_RC,
>>  				PCIE_CLIENT_CONFIG);
>>
>>  	err = phy_power_on(rockchip->phy);
>> @@ -550,29 +558,31 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>>  		msleep(20);
>>  	}
>>
>> -	/*
>> -	 * Enable retrain for gen2. This should be configured only after
>> -	 * gen1 finished.
>> -	 */
>> -	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
>> -	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
>> -	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>> +	if (rockchip->link_gen == 2) {
>> +		/*
>> +		 * Enable retrain for gen2. This should be configured only after
>> +		 * gen1 finished.
>> +		 */
>> +		status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
>> +		status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
>> +		rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
>> +
>> +		timeout = jiffies + msecs_to_jiffies(500);
>> +		for (;;) {
>> +			status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
>> +			if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
>> +					PCIE_CORE_PL_CONF_SPEED_5G) {
>> +				dev_dbg(dev, "PCIe link training gen2 pass!\n");
>> +				break;
>> +			}
>>
>> -	timeout = jiffies + msecs_to_jiffies(500);
>> -	for (;;) {
>> -		status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
>> -		if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
>> -		    PCIE_CORE_PL_CONF_SPEED_5G) {
>> -			dev_dbg(dev, "PCIe link training gen2 pass!\n");
>> -			break;
>> -		}
>> +			if (time_after(jiffies, timeout)) {
>> +				dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
>> +				break;
>> +			}
>>
>> -		if (time_after(jiffies, timeout)) {
>> -			dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
>> -			break;
>> +			msleep(20);
>>  		}
>> -
>> -		msleep(20);
>>  	}
>>
>>  	/* Check the final link width from negotiated lane counter from MGMT */
>> @@ -781,6 +791,14 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
>>  		rockchip->lanes = 1;
>>  	}
>>
>> +	rockchip->link_gen = 2;
>
> Isn't the above assignment violating the binding doc? Setting to 2 means
> that if the property isn't found, we default to gen2. That's OK with me,
> but you should make the binding doc match it.

It should be backward compatible with the old DTBs without this
propery. Otherwise, they did use gen2 but they cannot achieve it now
without adding the new propery.

But I agreee I should commet the doc more clearly.

>
>> +	err = of_property_read_u32(node, "rockchip,max-link-speed",
>> +				   &rockchip->link_gen);
>
> ^^ you can get sign errors here, since link_gen is 'int', but this
> function reads 'u32'. Maybe use a temporary u32.
>

Good catch.

> Brian
>
>> +	if (!err && rockchip->link_gen != 1 && rockchip->link_gen != 2) {
>> +		dev_warn(dev, "invalid max-link-speed, default to use gen1\n");
>> +		rockchip->link_gen = 1;
>> +	}
>> +
>>  	rockchip->core_rst = devm_reset_control_get(dev, "core");
>>  	if (IS_ERR(rockchip->core_rst)) {
>>  		if (PTR_ERR(rockchip->core_rst) != -EPROBE_DEFER)
>> --
>> 2.3.7
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Best Regards
Shawn Lin



From briannorris at chromium.org  Wed Oct  5 19:18:31 2016
From: briannorris at chromium.org (Brian Norris)
Date: Wed, 5 Oct 2016 19:18:31 -0700
Subject: [PATCH v3] PCI: rockchip: Support property to specify the link
 capability
In-Reply-To: <d81bcc67-22cc-774c-d9f3-445633303278@rock-chips.com>
References: <1475654717-15159-1-git-send-email-shawn.lin@rock-chips.com>
 <20161005224642.GA111810@google.com>
 <d81bcc67-22cc-774c-d9f3-445633303278@rock-chips.com>
Message-ID: <20161006021830.GA18624@localhost>

+ devicetree (you dropped them from v2 and v3)

On Thu, Oct 06, 2016 at 10:00:04AM +0800, Shawn Lin wrote:
> ? 2016/10/6 6:46, Brian Norris ??:
> >Hi,
> >
> >On Wed, Oct 05, 2016 at 04:05:17PM +0800, Shawn Lin wrote:
> >>From: Brian Norris <briannorris at chromium.org>
> >>
> >>rk3399 supports PCIe 2.x link speeds marginally at best, and on some
> >>boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500
> >>ms waiting for training that will never happen, let's add a property
> >>from devicetree to specify link capability.
> >>
> >>Signed-off-by: Brian Norris <briannorris at chromium.org>
> >>Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> >>
> >>---
> >>
> >>Changes in v3:
> >>- Cast a warning for invalid max link speed and use gen1 for it.
> >>  That looks better than v2. (Suggested by Brian)
> >>
> >>Changes in v2:
> >>- rename the property to rockchip,max-link-speed according to
> >>  Bjorn's recommendation and take some bits from imx6q-pcie to
> >>  make this requirement more consisent.
> >>
> >> .../devicetree/bindings/pci/rockchip-pcie.txt      |  2 +
> >> drivers/pci/host/pcie-rockchip.c                   | 62 ++++++++++++++--------
> >> 2 files changed, 42 insertions(+), 22 deletions(-)
> >>
> >>diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> >>index ba67b39..7bb730e 100644
> >>--- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> >>+++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> >>@@ -42,6 +42,8 @@ Required properties:
> >> Optional Property:
> >> - ep-gpios: contain the entry for pre-reset gpio
> >> - num-lanes: number of lanes to use
> >>+- rockchip,max-link-speed: Specify PCI gen for link capability. Must
> >>+	be '2' for gen2, and '1' for gen1, otherwise will default to gen1.
> >
> >I'm still not sure why we want incorrect DT entries to default to 1
> >instead of just being rejected as incorrect (i.e., and error). But
> >assuming people are OK with that behavior, I'll review the rest...
> 
> yep, personally I don't like to stop driver from running or to
> trigger BUG_ON only if the incorrect DT value. If that happens, it

I would never suggest BUG_ON() for this. But failing to probe with an
invalid DT is fine IMO. But I won't insist; the patch is fine with me
other than the doc vs. code issue below. I'll leave it to the
maintainers on this.

> implies we should deploy proper error handling and cast a warning
> should be enough for people to debug. If the max-link-speed is
> incorrect, I assume the owner of this DT doesn't actually read
> the doc at all. At least he/she doesn't know what this property means.
> So we could use the *nature* capability for sure it could bring up
> the boards, for instance 1 lanes, gen1... etc.
> 
> I was told to write code like this and have been insisting on this for
> quite a long time. Does it sound sane to you? :)

I tend to prefer strict DT interpretations, so you don't accidentally
cause yourself backwards compatibility problems in the future when you
want to extend this for chip N+1 that supports new features. But it's
not a big deal.

> >
> >> - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
> >> - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe.
> >> - vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe.
> >>diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> >>index 35591b1..66476ea 100644
> >>--- a/drivers/pci/host/pcie-rockchip.c
> >>+++ b/drivers/pci/host/pcie-rockchip.c
> >>@@ -53,6 +53,7 @@
> >> #define   PCIE_CLIENT_ARI_ENABLE	  HIWORD_UPDATE_BIT(0x0008)
> >> #define   PCIE_CLIENT_CONF_LANE_NUM(x)	  HIWORD_UPDATE(0x0030, ENCODE_LANES(x))
> >> #define   PCIE_CLIENT_MODE_RC		  HIWORD_UPDATE_BIT(0x0040)
> >>+#define   PCIE_CLIENT_GEN_SEL_1		  HIWORD_UPDATE(0x0080, 0)
> >> #define   PCIE_CLIENT_GEN_SEL_2		  HIWORD_UPDATE_BIT(0x0080)
> >> #define PCIE_CLIENT_BASIC_STATUS1	(PCIE_CLIENT_BASE + 0x48)
> >> #define   PCIE_CLIENT_LINK_STATUS_UP		0x00300000
> >>@@ -205,6 +206,7 @@ struct rockchip_pcie {
> >> 	struct	gpio_desc *ep_gpio;
> >> 	u32	lanes;
> >> 	u8	root_bus_nr;
> >>+	int	link_gen;
> >> 	struct	device *dev;
> >> 	struct	irq_domain *irq_domain;
> >> };
> >>@@ -443,13 +445,19 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
> >> 		return err;
> >> 	}
> >>
> >>+	if (rockchip->link_gen == 2)
> >>+		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_2,
> >>+				    PCIE_CLIENT_CONFIG);
> >>+	else
> >>+		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_1,
> >>+				    PCIE_CLIENT_CONFIG);
> >>+
> >> 	rockchip_pcie_write(rockchip,
> >> 			    PCIE_CLIENT_CONF_ENABLE |
> >> 			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
> >> 			    PCIE_CLIENT_ARI_ENABLE |
> >> 			    PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
> >>-			    PCIE_CLIENT_MODE_RC |
> >>-			    PCIE_CLIENT_GEN_SEL_2,
> >>+			    PCIE_CLIENT_MODE_RC,
> >> 				PCIE_CLIENT_CONFIG);
> >>
> >> 	err = phy_power_on(rockchip->phy);
> >>@@ -550,29 +558,31 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
> >> 		msleep(20);
> >> 	}
> >>
> >>-	/*
> >>-	 * Enable retrain for gen2. This should be configured only after
> >>-	 * gen1 finished.
> >>-	 */
> >>-	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> >>-	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
> >>-	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> >>+	if (rockchip->link_gen == 2) {
> >>+		/*
> >>+		 * Enable retrain for gen2. This should be configured only after
> >>+		 * gen1 finished.
> >>+		 */
> >>+		status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> >>+		status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
> >>+		rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> >>+
> >>+		timeout = jiffies + msecs_to_jiffies(500);
> >>+		for (;;) {
> >>+			status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
> >>+			if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
> >>+					PCIE_CORE_PL_CONF_SPEED_5G) {
> >>+				dev_dbg(dev, "PCIe link training gen2 pass!\n");
> >>+				break;
> >>+			}
> >>
> >>-	timeout = jiffies + msecs_to_jiffies(500);
> >>-	for (;;) {
> >>-		status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
> >>-		if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
> >>-		    PCIE_CORE_PL_CONF_SPEED_5G) {
> >>-			dev_dbg(dev, "PCIe link training gen2 pass!\n");
> >>-			break;
> >>-		}
> >>+			if (time_after(jiffies, timeout)) {
> >>+				dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
> >>+				break;
> >>+			}
> >>
> >>-		if (time_after(jiffies, timeout)) {
> >>-			dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
> >>-			break;
> >>+			msleep(20);
> >> 		}
> >>-
> >>-		msleep(20);
> >> 	}
> >>
> >> 	/* Check the final link width from negotiated lane counter from MGMT */
> >>@@ -781,6 +791,14 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
> >> 		rockchip->lanes = 1;
> >> 	}
> >>
> >>+	rockchip->link_gen = 2;
> >
> >Isn't the above assignment violating the binding doc? Setting to 2 means
> >that if the property isn't found, we default to gen2. That's OK with me,
> >but you should make the binding doc match it.
> 
> It should be backward compatible with the old DTBs without this
> propery. Otherwise, they did use gen2 but they cannot achieve it now
> without adding the new propery.

Yes, defaulting to gen2 is probably the best choice.

> But I agreee I should commet the doc more clearly.

Yes, just please update the doc.

Brian

> >
> >>+	err = of_property_read_u32(node, "rockchip,max-link-speed",
> >>+				   &rockchip->link_gen);
> >
> >^^ you can get sign errors here, since link_gen is 'int', but this
> >function reads 'u32'. Maybe use a temporary u32.
> >
> 
> Good catch.
> 
> >Brian
> >
> >>+	if (!err && rockchip->link_gen != 1 && rockchip->link_gen != 2) {
> >>+		dev_warn(dev, "invalid max-link-speed, default to use gen1\n");
> >>+		rockchip->link_gen = 1;
> >>+	}
> >>+
> >> 	rockchip->core_rst = devm_reset_control_get(dev, "core");
> >> 	if (IS_ERR(rockchip->core_rst)) {
> >> 		if (PTR_ERR(rockchip->core_rst) != -EPROBE_DEFER)


From shawn.lin at rock-chips.com  Thu Oct  6 01:50:00 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Thu,  6 Oct 2016 16:50:00 +0800
Subject: [PATCH v4] PCI: rockchip: Support property to specify the link
 capability
Message-ID: <1475743800-1036-1-git-send-email-shawn.lin@rock-chips.com>

From: Brian Norris <briannorris at chromium.org>

rk3399 supports PCIe 2.x link speeds marginally at best, and on some
boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500
ms waiting for training that will never happen, let's add a property
from devicetree to specify link capability.

Signed-off-by: Brian Norris <briannorris at chromium.org>
Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v4:
- define link_gen as u32
- elaborate more for rockchip,max-link-speed on doc

Changes in v3:
- Cast a warning for invalid max link speed and use gen1 for it.
  That looks better than v2. (Suggested by Brian)

Changes in v2:
- rename the property to rockchip,max-link-speed according to
  Bjorn's recommendation and take some bits from imx6q-pcie to
  make this requirement more consisent.

 .../devicetree/bindings/pci/rockchip-pcie.txt      |  4 ++
 drivers/pci/host/pcie-rockchip.c                   | 63 ++++++++++++++--------
 2 files changed, 44 insertions(+), 23 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
index ba67b39..9bb29de 100644
--- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
@@ -42,6 +42,10 @@ Required properties:
 Optional Property:
 - ep-gpios: contain the entry for pre-reset gpio
 - num-lanes: number of lanes to use
+- rockchip,max-link-speed: Specify PCI gen for link capability. Must
+	be '2' for gen2, and '1' for gen1, otherwise will default to gen1.
+	For backward compatibility, if this property isn't assigned, we
+	use gen2 by default.
 - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
 - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe.
 - vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe.
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 35591b1..6dde999 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -53,6 +53,7 @@
 #define   PCIE_CLIENT_ARI_ENABLE	  HIWORD_UPDATE_BIT(0x0008)
 #define   PCIE_CLIENT_CONF_LANE_NUM(x)	  HIWORD_UPDATE(0x0030, ENCODE_LANES(x))
 #define   PCIE_CLIENT_MODE_RC		  HIWORD_UPDATE_BIT(0x0040)
+#define   PCIE_CLIENT_GEN_SEL_1		  HIWORD_UPDATE(0x0080, 0)
 #define   PCIE_CLIENT_GEN_SEL_2		  HIWORD_UPDATE_BIT(0x0080)
 #define PCIE_CLIENT_BASIC_STATUS1	(PCIE_CLIENT_BASE + 0x48)
 #define   PCIE_CLIENT_LINK_STATUS_UP		0x00300000
@@ -205,6 +206,7 @@ struct rockchip_pcie {
 	struct	gpio_desc *ep_gpio;
 	u32	lanes;
 	u8	root_bus_nr;
+	u32	link_gen;
 	struct	device *dev;
 	struct	irq_domain *irq_domain;
 };
@@ -443,14 +445,19 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		return err;
 	}
 
+	if (rockchip->link_gen == 2)
+		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_2,
+				    PCIE_CLIENT_CONFIG);
+	else
+		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_1,
+				    PCIE_CLIENT_CONFIG);
+
 	rockchip_pcie_write(rockchip,
 			    PCIE_CLIENT_CONF_ENABLE |
 			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
 			    PCIE_CLIENT_ARI_ENABLE |
 			    PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
-			    PCIE_CLIENT_MODE_RC |
-			    PCIE_CLIENT_GEN_SEL_2,
-				PCIE_CLIENT_CONFIG);
+			    PCIE_CLIENT_MODE_RC, PCIE_CLIENT_CONFIG);
 
 	err = phy_power_on(rockchip->phy);
 	if (err) {
@@ -550,29 +557,31 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		msleep(20);
 	}
 
-	/*
-	 * Enable retrain for gen2. This should be configured only after
-	 * gen1 finished.
-	 */
-	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
-	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
-	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
+	if (rockchip->link_gen == 2) {
+		/*
+		 * Enable retrain for gen2. This should be configured only after
+		 * gen1 finished.
+		 */
+		status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
+		status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
+		rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
+
+		timeout = jiffies + msecs_to_jiffies(500);
+		for (;;) {
+			status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
+			if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
+					PCIE_CORE_PL_CONF_SPEED_5G) {
+				dev_dbg(dev, "PCIe link training gen2 pass!\n");
+				break;
+			}
 
-	timeout = jiffies + msecs_to_jiffies(500);
-	for (;;) {
-		status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
-		if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
-		    PCIE_CORE_PL_CONF_SPEED_5G) {
-			dev_dbg(dev, "PCIe link training gen2 pass!\n");
-			break;
-		}
+			if (time_after(jiffies, timeout)) {
+				dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
+				break;
+			}
 
-		if (time_after(jiffies, timeout)) {
-			dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
-			break;
+			msleep(20);
 		}
-
-		msleep(20);
 	}
 
 	/* Check the final link width from negotiated lane counter from MGMT */
@@ -781,6 +790,14 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
 		rockchip->lanes = 1;
 	}
 
+	rockchip->link_gen = 2;
+	err = of_property_read_u32(node, "rockchip,max-link-speed",
+				   &rockchip->link_gen);
+	if (!err && rockchip->link_gen != 1 && rockchip->link_gen != 2) {
+		dev_warn(dev, "invalid max-link-speed, default to use gen1\n");
+		rockchip->link_gen = 1;
+	}
+
 	rockchip->core_rst = devm_reset_control_get(dev, "core");
 	if (IS_ERR(rockchip->core_rst)) {
 		if (PTR_ERR(rockchip->core_rst) != -EPROBE_DEFER)
-- 
2.3.7




From paweljarosz3691 at gmail.com  Thu Oct  6 09:22:09 2016
From: paweljarosz3691 at gmail.com (=?us-ascii?B?PT9VVEYtOD9xP1Bhd2U9QzU9ODI9MjBKYXJvc3o/PQ==?=)
Date: Thu, 6 Oct 2016 18:22:09 +0200
Subject: [PATCH 0/3] Add MK808 RK3066 device
Message-ID: <cover.1475764778.git.paweljarosz3691@gmail.com>

This patchset adds support for Rikomagic MK808 v1 device with RK901 wifi.

It is hdmi stick with two usb ports(host and otg), sdmmc, wifi and uart
onboard.

It is RK3066 based.

Pawe? Jarosz (3):
  ARM: dts: rockchip: Enable build of rk3066 MK808 dts
  devicetree: Add vendor prefix for Rikomagic
  ARM: dts: rockchip: Add rk3066 MK808 board devicetree description file

 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/rk3066a-mk808.dts                | 184 +++++++++++++++++++++
 3 files changed, 186 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts

-- 
2.7.4



From paweljarosz3691 at gmail.com  Thu Oct  6 09:22:40 2016
From: paweljarosz3691 at gmail.com (=?us-ascii?B?PT9VVEYtOD9xP1Bhd2U9QzU9ODI9MjBKYXJvc3o/PQ==?=)
Date: Thu, 6 Oct 2016 18:22:40 +0200
Subject: [PATCH 1/3] ARM: dts: rockchip: Enable build of rk3066 MK808 dts
In-Reply-To: <cover.1475764778.git.paweljarosz3691@gmail.com>
References: <cover.1475764778.git.paweljarosz3691@gmail.com>
Message-ID: <84d4bc0b733cb9776f03ad54bb946fd1c4be4049.1475764778.git.paweljarosz3691@gmail.com>

MK808 is rockchip rk3066 based board made by Rickomagic. It has two usb
ports, sdmmc, wifi and uart onboard.

Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
---
 arch/arm/boot/dts/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..f19cc1d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -639,6 +639,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3036-kylin.dtb \
 	rk3066a-bqcurie2.dtb \
 	rk3066a-marsboard.dtb \
+	rk3066a-mk808.dtb \
 	rk3066a-rayeager.dtb \
 	rk3188-radxarock.dtb \
 	rk3228-evb.dtb \
-- 
2.7.4



From paweljarosz3691 at gmail.com  Thu Oct  6 09:23:05 2016
From: paweljarosz3691 at gmail.com (=?us-ascii?B?PT9VVEYtOD9xP1Bhd2U9QzU9ODI9MjBKYXJvc3o/PQ==?=)
Date: Thu, 6 Oct 2016 18:23:05 +0200
Subject: [PATCH 2/3] devicetree: Add vendor prefix for Rikomagic
In-Reply-To: <cover.1475764778.git.paweljarosz3691@gmail.com>
References: <cover.1475764778.git.paweljarosz3691@gmail.com>
Message-ID: <afaab1c83063f33a7cd4eb8b6d08a9997c2947bc.1475764778.git.paweljarosz3691@gmail.com>

Add Rikomagic to vendor-prefixes.txt

Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 69caf14..3edfa08 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -224,6 +224,7 @@ realtek Realtek Semiconductor Corp.
 renesas	Renesas Electronics Corporation
 richtek	Richtek Technology Corporation
 ricoh	Ricoh Co. Ltd.
+rikomagic	Rikomagic
 rockchip	Fuzhou Rockchip Electronics Co., Ltd
 samsung	Samsung Semiconductor
 sandisk	Sandisk Corporation
-- 
2.7.4



From paweljarosz3691 at gmail.com  Thu Oct  6 09:23:21 2016
From: paweljarosz3691 at gmail.com (=?us-ascii?B?PT9VVEYtOD9xP1Bhd2U9QzU9ODI9MjBKYXJvc3o/PQ==?=)
Date: Thu, 6 Oct 2016 18:23:21 +0200
Subject: [PATCH 3/3] ARM: dts: rockchip: Add rk3066 MK808 board devicetree
 description file
In-Reply-To: <cover.1475764778.git.paweljarosz3691@gmail.com>
References: <cover.1475764778.git.paweljarosz3691@gmail.com>
Message-ID: <3314a4b5fd563c7c0fb923a95039f3bcd51721cd.1475764778.git.paweljarosz3691@gmail.com>

MK808 is a tv stick which has rockchip rk3066 CPU inside, two usb ports
- host and otg, micro sd card slot and onboard wifi RK901.

Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
---
 arch/arm/boot/dts/rk3066a-mk808.dts | 184 ++++++++++++++++++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts

diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts b/arch/arm/boot/dts/rk3066a-mk808.dts
new file mode 100644
index 0000000..2878562
--- /dev/null
+++ b/arch/arm/boot/dts/rk3066a-mk808.dts
@@ -0,0 +1,184 @@
+/*
+ * Copyright (c) 2016 Pawe? Jarosz <paweljarosz3691 at gmail.com>
+ *
+ * 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 file 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 file 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.
+ */
+
+/dts-v1/;
+#include "rk3066a.dtsi"
+
+/ {
+	model = "Rikomagic MK808";
+	compatible = "rikomagic,mk808", "rockchip,rk3066a";
+
+	chosen {
+		stdout-path = "serial2:115200n8";
+	};
+
+	memory at 60000000 {
+		device_type = "memory";
+		reg = <0x60000000 0x40000000>;
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		blue {
+			label = "mk808:blue:power";
+			gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
+			default-state = "off";
+			linux,default-trigger = "default-on";
+		};
+	};
+
+	mmc_pwrseq: mmc-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		pinctrl-names = "default";
+		pinctrl-0 = <&sdmmc_pwr>;
+		reset-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_pwr>;
+		reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>;
+	};
+
+	vcc_io: vcc-io {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_io";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	vcc_host: usb-host-regulator {
+		compatible = "regulator-fixed";
+		gpio = <&gpio0 6 GPIO_ACTIVE_HIGH>;
+		pinctrl-0 = <&host_drv>;
+		pinctrl-names = "default";
+		regulator-always-on;
+		regulator-name = "host-pwr";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		startup-delay-us = <100000>;
+		vin-supply = <&vcc_io>;
+	};
+
+	vcc_otg: usb-otg-regulator {
+		compatible = "regulator-fixed";
+		gpio = <&gpio0 5 GPIO_ACTIVE_HIGH>;
+		pinctrl-0 = <&otg_drv>;
+		pinctrl-names = "default";
+		regulator-always-on;
+		regulator-name = "vcc_otg";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		startup-delay-us = <100000>;
+		vin-supply = <&vcc_io>;
+	};
+};
+
+&mmc0 {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	mmc-pwrseq = <&mmc_pwrseq>;
+	num-slots = <1>;
+	status = "okay";
+	vmmc-supply = <&vcc_io>;
+};
+
+&mmc1 {
+	bus-width = <4>;
+	disable-wp;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	num-slots = <1>;
+	status = "okay";
+	vmmc-supply = <&vcc_io>;
+};
+
+&pinctrl {
+	usb-host {
+		host_drv: host-drv {
+			rockchip,pins = <RK_GPIO0 6 RK_FUNC_GPIO &pcfg_pull_default>;
+		};
+	};
+
+	usb-otg {
+		otg_drv: otg-drv {
+			rockchip,pins = <RK_GPIO0 5 RK_FUNC_GPIO &pcfg_pull_default>;
+		};
+	};
+
+	sdmmc {
+		sdmmc_pwr: sdmmc-pwr {
+			rockchip,pins = <RK_GPIO3 7 RK_FUNC_GPIO &pcfg_pull_default>;
+		};
+	};
+
+	sdio {
+		wifi_pwr: wifi-pwr {
+			rockchip,pins = <RK_GPIO3 24 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usb_host {
+	status = "okay";
+};
+
+&usb_otg {
+	status = "okay";
+};
+
+&usbphy {
+	status = "okay";
+};
+
+&wdt {
+	status = "okay";
+};
+
-- 
2.7.4



From heiko at sntech.de  Thu Oct  6 09:33:13 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Thu, 06 Oct 2016 18:33:13 +0200
Subject: [PATCH 1/3] ARM: dts: rockchip: Enable build of rk3066 MK808 dts
In-Reply-To: <84d4bc0b733cb9776f03ad54bb946fd1c4be4049.1475764778.git.paweljarosz3691@gmail.com>
References: <cover.1475764778.git.paweljarosz3691@gmail.com>
 <84d4bc0b733cb9776f03ad54bb946fd1c4be4049.1475764778.git.paweljarosz3691@gmail.com>
Message-ID: <46121446.zsYkG9qnut@phil>

Hi Pawe?,

Am Donnerstag, 6. Oktober 2016, 18:22:40 CEST schrieb =?UTF-8?q?
Pawe=C5=82=20Jarosz?=:
> MK808 is rockchip rk3066 based board made by Rickomagic. It has two usb
> ports, sdmmc, wifi and uart onboard.
> 
> Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
> ---
>  arch/arm/boot/dts/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..f19cc1d 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -639,6 +639,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>  	rk3036-kylin.dtb \
>  	rk3066a-bqcurie2.dtb \
>  	rk3066a-marsboard.dtb \
> +	rk3066a-mk808.dtb \
>  	rk3066a-rayeager.dtb \
>  	rk3188-radxarock.dtb \
>  	rk3228-evb.dtb \

This patch breaks bisectability, as it adds a dtb to the makefile that you only 
add in patch3 which makes builds fail. Please fold your patches 1 and 3 into 
one patch and also add and entry to Documentation/devicetree/bindings/arm/
rockchip.txt for the board.


Heiko


From paweljarosz3691 at gmail.com  Thu Oct  6 10:05:15 2016
From: paweljarosz3691 at gmail.com (=?UTF-8?Q?Pawe=c5=82_Jarosz?=)
Date: Thu, 6 Oct 2016 19:05:15 +0200
Subject: [PATCH 1/3] ARM: dts: rockchip: Enable build of rk3066 MK808 dts
In-Reply-To: <46121446.zsYkG9qnut@phil>
References: <cover.1475764778.git.paweljarosz3691@gmail.com>
 <84d4bc0b733cb9776f03ad54bb946fd1c4be4049.1475764778.git.paweljarosz3691@gmail.com>
 <46121446.zsYkG9qnut@phil>
Message-ID: <c6d58e9b-8d36-61c5-5af1-59b1c293d969@gmail.com>

Hi Heiko



> This patch breaks bisectability, as it adds a dtb to the makefile that you only
> add in patch3 which makes builds fail. Please fold your patches 1 and 3 into
> one patch and also add and entry to Documentation/devicetree/bindings/arm/
> rockchip.txt for the board.
>
>
> Heiko

Should i squash all patches in one?

I saw now in logs that it's common practise.


Pawe?



From heiko at sntech.de  Thu Oct  6 10:05:26 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Thu, 06 Oct 2016 19:05:26 +0200
Subject: [PATCH 1/3] ARM: dts: rockchip: Enable build of rk3066 MK808 dts
In-Reply-To: <c6d58e9b-8d36-61c5-5af1-59b1c293d969@gmail.com>
References: <cover.1475764778.git.paweljarosz3691@gmail.com>
 <46121446.zsYkG9qnut@phil> <c6d58e9b-8d36-61c5-5af1-59b1c293d969@gmail.com>
Message-ID: <2552415.D3JWyKI0Mg@phil>

Am Donnerstag, 6. Oktober 2016, 19:05:15 CEST schrieb Pawe? Jarosz:
> Hi Heiko
> 
> > This patch breaks bisectability, as it adds a dtb to the makefile that you
> > only add in patch3 which makes builds fail. Please fold your patches 1
> > and 3 into one patch and also add and entry to
> > Documentation/devicetree/bindings/arm/ rockchip.txt for the board.
> > 
> > 
> > Heiko
> 
> Should i squash all patches in one?
> 
> I saw now in logs that it's common practise.

Nope ... vendor-prefix should stay separate, everything else can be in one 
patch.


From paweljarosz3691 at gmail.com  Thu Oct  6 10:37:31 2016
From: paweljarosz3691 at gmail.com (=?utf-8?B?UGF3ZcWC?= Jarosz)
Date: Thu, 6 Oct 2016 19:37:31 +0200
Subject: [PATCH v2 0/2] Add MK808 RK3066 device
Message-ID: <cover.1475774981.git.paweljarosz3691@gmail.com>

This patchset adds support for Rikomagic MK808 v1 device with RK901 wifi.

It is hdmi stick with two usb ports(host and otg), sdmmc, wifi and uart
onboard.

It is RK3066 based.

Pawe? Jarosz (2):
  devicetree: Add vendor prefix for Rikomagic
  ARM: dts: rockchip: Add rk3066 MK808 board

 Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/rk3066a-mk808.dts                | 184 +++++++++++++++++++++
 4 files changed, 190 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts

-- 
2.7.4



From paweljarosz3691 at gmail.com  Thu Oct  6 10:37:56 2016
From: paweljarosz3691 at gmail.com (=?utf-8?B?UGF3ZcWC?= Jarosz)
Date: Thu, 6 Oct 2016 19:37:56 +0200
Subject: [PATCH v2 1/2] devicetree: Add vendor prefix for Rikomagic
In-Reply-To: <cover.1475774981.git.paweljarosz3691@gmail.com>
References: <cover.1475774981.git.paweljarosz3691@gmail.com>
Message-ID: <d51c7719a314f723a0a69b932997502a2fe0e3ee.1475774981.git.paweljarosz3691@gmail.com>

Add Rikomagic to vendor-prefixes.txt

Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
---
Changes in v2:
- none
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 69caf14..3edfa08 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -224,6 +224,7 @@ realtek Realtek Semiconductor Corp.
 renesas	Renesas Electronics Corporation
 richtek	Richtek Technology Corporation
 ricoh	Ricoh Co. Ltd.
+rikomagic	Rikomagic
 rockchip	Fuzhou Rockchip Electronics Co., Ltd
 samsung	Samsung Semiconductor
 sandisk	Sandisk Corporation
-- 
2.7.4



From paweljarosz3691 at gmail.com  Thu Oct  6 10:38:15 2016
From: paweljarosz3691 at gmail.com (=?utf-8?B?UGF3ZcWC?= Jarosz)
Date: Thu, 6 Oct 2016 19:38:15 +0200
Subject: [PATCH v2 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
In-Reply-To: <cover.1475774981.git.paweljarosz3691@gmail.com>
References: <cover.1475774981.git.paweljarosz3691@gmail.com>
Message-ID: <b63a0ad452a487beb1d0c07addb9208cc3b3eeef.1475774981.git.paweljarosz3691@gmail.com>

MK808 is a tv stick which has rockchip rk3066 CPU inside, two usb ports
- host and otg, micro sd card slot and onboard wifi RK901.

Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
---

Changes in v2:
- included Heiko sugestion.

 Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/rk3066a-mk808.dts                | 184 +++++++++++++++++++++
 3 files changed, 189 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index 55f388f..c09595b 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -17,6 +17,10 @@ Rockchip platforms device tree bindings
     Required root node properties:
       - compatible = "chipspark,rayeager-px2", "rockchip,rk3066a";
 
+- Rikomagic MK808 v1 board:
+    Required root node properties:
+      - compatible = "rikomagic,mk808", "rockchip,rk3066a";
+
 - Radxa Rock board:
     Required root node properties:
       - compatible = "radxa,rock", "rockchip,rk3188";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..f19cc1d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -639,6 +639,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3036-kylin.dtb \
 	rk3066a-bqcurie2.dtb \
 	rk3066a-marsboard.dtb \
+	rk3066a-mk808.dtb \
 	rk3066a-rayeager.dtb \
 	rk3188-radxarock.dtb \
 	rk3228-evb.dtb \
diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts b/arch/arm/boot/dts/rk3066a-mk808.dts
new file mode 100644
index 0000000..2878562
--- /dev/null
+++ b/arch/arm/boot/dts/rk3066a-mk808.dts
@@ -0,0 +1,184 @@
+/*
+ * Copyright (c) 2016 Pawe? Jarosz <paweljarosz3691 at gmail.com>
+ *
+ * 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 file 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 file 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.
+ */
+
+/dts-v1/;
+#include "rk3066a.dtsi"
+
+/ {
+	model = "Rikomagic MK808";
+	compatible = "rikomagic,mk808", "rockchip,rk3066a";
+
+	chosen {
+		stdout-path = "serial2:115200n8";
+	};
+
+	memory at 60000000 {
+		device_type = "memory";
+		reg = <0x60000000 0x40000000>;
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		blue {
+			label = "mk808:blue:power";
+			gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
+			default-state = "off";
+			linux,default-trigger = "default-on";
+		};
+	};
+
+	mmc_pwrseq: mmc-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		pinctrl-names = "default";
+		pinctrl-0 = <&sdmmc_pwr>;
+		reset-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_pwr>;
+		reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>;
+	};
+
+	vcc_io: vcc-io {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_io";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	vcc_host: usb-host-regulator {
+		compatible = "regulator-fixed";
+		gpio = <&gpio0 6 GPIO_ACTIVE_HIGH>;
+		pinctrl-0 = <&host_drv>;
+		pinctrl-names = "default";
+		regulator-always-on;
+		regulator-name = "host-pwr";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		startup-delay-us = <100000>;
+		vin-supply = <&vcc_io>;
+	};
+
+	vcc_otg: usb-otg-regulator {
+		compatible = "regulator-fixed";
+		gpio = <&gpio0 5 GPIO_ACTIVE_HIGH>;
+		pinctrl-0 = <&otg_drv>;
+		pinctrl-names = "default";
+		regulator-always-on;
+		regulator-name = "vcc_otg";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		startup-delay-us = <100000>;
+		vin-supply = <&vcc_io>;
+	};
+};
+
+&mmc0 {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	mmc-pwrseq = <&mmc_pwrseq>;
+	num-slots = <1>;
+	status = "okay";
+	vmmc-supply = <&vcc_io>;
+};
+
+&mmc1 {
+	bus-width = <4>;
+	disable-wp;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	num-slots = <1>;
+	status = "okay";
+	vmmc-supply = <&vcc_io>;
+};
+
+&pinctrl {
+	usb-host {
+		host_drv: host-drv {
+			rockchip,pins = <RK_GPIO0 6 RK_FUNC_GPIO &pcfg_pull_default>;
+		};
+	};
+
+	usb-otg {
+		otg_drv: otg-drv {
+			rockchip,pins = <RK_GPIO0 5 RK_FUNC_GPIO &pcfg_pull_default>;
+		};
+	};
+
+	sdmmc {
+		sdmmc_pwr: sdmmc-pwr {
+			rockchip,pins = <RK_GPIO3 7 RK_FUNC_GPIO &pcfg_pull_default>;
+		};
+	};
+
+	sdio {
+		wifi_pwr: wifi-pwr {
+			rockchip,pins = <RK_GPIO3 24 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usb_host {
+	status = "okay";
+};
+
+&usb_otg {
+	status = "okay";
+};
+
+&usbphy {
+	status = "okay";
+};
+
+&wdt {
+	status = "okay";
+};
+
-- 
2.7.4



From paweljarosz3691 at gmail.com  Thu Oct  6 12:42:21 2016
From: paweljarosz3691 at gmail.com (=?utf-8?B?UGF3ZcWC?= Jarosz)
Date: Thu, 6 Oct 2016 21:42:21 +0200
Subject: [PATCH] ARM: dts: rockchip: initialize rk3066 PLL clock rate
Message-ID: <20161006194221.GA4895@vaio-ubuntu>

Initialize PLL rate while kernel init. No other module does than.
Clock rates are taken from rk3066 TRM. Assigned values are for 125 degrees
celcius operating point.
This gives us performance boost observable for example in mmc transfers.

Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
---
 arch/arm/boot/dts/rk3066a.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 0d0dae3..cf215e8 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -151,6 +151,10 @@
 
 		#clock-cells = <1>;
 		#reset-cells = <1>;
+		assigned-clocks = <&cru PLL_DPLL>, <&cru PLL_APLL>,
+				  <&cru PLL_CPLL>, <&cru PLL_GPLL>;
+		assigned-clock-rates = <533000000>, <600000000>,
+				       <600000000>, <600000000>;
 	};
 
 	timer at 2000e000 {
-- 
2.7.4



From briannorris at chromium.org  Thu Oct  6 14:38:00 2016
From: briannorris at chromium.org (Brian Norris)
Date: Thu, 6 Oct 2016 14:38:00 -0700
Subject: [PATCH v4] PCI: rockchip: Support property to specify the link
 capability
In-Reply-To: <1475743800-1036-1-git-send-email-shawn.lin@rock-chips.com>
References: <1475743800-1036-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <20161006213800.GA2347@localhost>

On Thu, Oct 06, 2016 at 04:50:00PM +0800, Shawn Lin wrote:
> From: Brian Norris <briannorris at chromium.org>
> 
> rk3399 supports PCIe 2.x link speeds marginally at best, and on some
> boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500
> ms waiting for training that will never happen, let's add a property
> from devicetree to specify link capability.
> 
> Signed-off-by: Brian Norris <briannorris at chromium.org>
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> 
> ---
> 
> Changes in v4:
> - define link_gen as u32
> - elaborate more for rockchip,max-link-speed on doc
> 
> Changes in v3:
> - Cast a warning for invalid max link speed and use gen1 for it.
>   That looks better than v2. (Suggested by Brian)
> 
> Changes in v2:
> - rename the property to rockchip,max-link-speed according to
>   Bjorn's recommendation and take some bits from imx6q-pcie to
>   make this requirement more consisent.
> 
>  .../devicetree/bindings/pci/rockchip-pcie.txt      |  4 ++
>  drivers/pci/host/pcie-rockchip.c                   | 63 ++++++++++++++--------
>  2 files changed, 44 insertions(+), 23 deletions(-)

Not sure if it means anything much, since I wrote half of this, but:

Reviewed-by: Brian Norris <briannorris at chromium.org>


From shawn.lin at rock-chips.com  Thu Oct  6 19:29:48 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Fri, 7 Oct 2016 10:29:48 +0800
Subject: [PATCH v2 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
In-Reply-To: <b63a0ad452a487beb1d0c07addb9208cc3b3eeef.1475774981.git.paweljarosz3691@gmail.com>
References: <cover.1475774981.git.paweljarosz3691@gmail.com>
 <b63a0ad452a487beb1d0c07addb9208cc3b3eeef.1475774981.git.paweljarosz3691@gmail.com>
Message-ID: <a166a444-8819-ffe7-8ee1-1f632f6a66ab@rock-chips.com>

Hi Pawe? ,

On 2016/10/7 1:38, Pawe? Jarosz wrote:
> MK808 is a tv stick which has rockchip rk3066 CPU inside, two usb ports
> - host and otg, micro sd card slot and onboard wifi RK901.
>
> Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
> ---
>
> Changes in v2:
> - included Heiko sugestion.
>
>  Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
>  arch/arm/boot/dts/Makefile                         |   1 +
>  arch/arm/boot/dts/rk3066a-mk808.dts                | 184 +++++++++++++++++++++
>  3 files changed, 189 insertions(+)
>  create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
> index 55f388f..c09595b 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -17,6 +17,10 @@ Rockchip platforms device tree bindings
>      Required root node properties:
>        - compatible = "chipspark,rayeager-px2", "rockchip,rk3066a";
>
> +- Rikomagic MK808 v1 board:
> +    Required root node properties:
> +      - compatible = "rikomagic,mk808", "rockchip,rk3066a";
> +
>  - Radxa Rock board:
>      Required root node properties:
>        - compatible = "radxa,rock", "rockchip,rk3188";
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..f19cc1d 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -639,6 +639,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>  	rk3036-kylin.dtb \
>  	rk3066a-bqcurie2.dtb \
>  	rk3066a-marsboard.dtb \
> +	rk3066a-mk808.dtb \
>  	rk3066a-rayeager.dtb \
>  	rk3188-radxarock.dtb \
>  	rk3228-evb.dtb \
> diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts b/arch/arm/boot/dts/rk3066a-mk808.dts
> new file mode 100644
> index 0000000..2878562
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk3066a-mk808.dts
> @@ -0,0 +1,184 @@
> +/*
> + * Copyright (c) 2016 Pawe? Jarosz <paweljarosz3691 at gmail.com>
> + *
> + * 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 file 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 file 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.
> + */
> +
> +/dts-v1/;
> +#include "rk3066a.dtsi"
> +
> +/ {
> +	model = "Rikomagic MK808";
> +	compatible = "rikomagic,mk808", "rockchip,rk3066a";
> +
> +	chosen {
> +		stdout-path = "serial2:115200n8";
> +	};
> +
> +	memory at 60000000 {
> +		device_type = "memory";
> +		reg = <0x60000000 0x40000000>;
> +	};
> +
> +	gpio-leds {
> +		compatible = "gpio-leds";
> +
> +		blue {
> +			label = "mk808:blue:power";
> +			gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
> +			default-state = "off";
> +			linux,default-trigger = "default-on";
> +		};
> +	};
> +
> +	mmc_pwrseq: mmc-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&sdmmc_pwr>;

sd slot does not contain a reset pin. So the power pin should be
enough. just add sdmmc_pwr to mmc0's pinctrl-0 and let mmc driver
control it should be enough. Typically pwrseq is for emmc and sdio.
We don't need a pwerseq to control power for sd slot..

But it seems sdmmc_pwr is a GPIO, but not functional port.
So I am interesting that why MK808 board doesn't use the mmc
controller's default power pin but chosing another gpio, so finally
we have to add thses code for your DT.

> +		reset-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	sdio_pwrseq: sdio-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_pwr>;
> +		reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>;
> +	};
> +
> +	vcc_io: vcc-io {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_io";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;

Are you sure it should be fixed to 5V? I ask this since I see
the mmc use this as vmmc which should be 3V~3V3 in principle.

> +		regulator-always-on;

I'm not sure whether you need this. The regulator would maintain
the user_count there. So from this patch, I think it should be turned
off since we possible don't enable usb and mmc?

Moreover, the always-on power supply is depreciated by vmmc since it
cause some problem to a certain degree.

> +	};
> +
> +	vcc_host: usb-host-regulator {
> +		compatible = "regulator-fixed";
> +		gpio = <&gpio0 6 GPIO_ACTIVE_HIGH>;
> +		pinctrl-0 = <&host_drv>;
> +		pinctrl-names = "default";
> +		regulator-always-on;
> +		regulator-name = "host-pwr";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		startup-delay-us = <100000>;
> +		vin-supply = <&vcc_io>;
> +	};
> +
> +	vcc_otg: usb-otg-regulator {
> +		compatible = "regulator-fixed";
> +		gpio = <&gpio0 5 GPIO_ACTIVE_HIGH>;
> +		pinctrl-0 = <&otg_drv>;
> +		pinctrl-names = "default";
> +		regulator-always-on;
> +		regulator-name = "vcc_otg";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		startup-delay-us = <100000>;
> +		vin-supply = <&vcc_io>;
> +	};
> +};

Same concern for these above.

> +
> +&mmc0 {
> +	bus-width = <4>;
> +	cap-mmc-highspeed;
> +	cap-sd-highspeed;
> +	mmc-pwrseq = <&mmc_pwrseq>;

Removed this could make SD works?

Also do you need disable-wp for sd slot?

> +	num-slots = <1>;
> +	status = "okay";
> +	vmmc-supply = <&vcc_io>;
> +};
> +
> +&mmc1 {
> +	bus-width = <4>;
> +	disable-wp;
> +	mmc-pwrseq = <&sdio_pwrseq>;
> +	non-removable;
> +	num-slots = <1>;
> +	status = "okay";
> +	vmmc-supply = <&vcc_io>;
> +};
> +
> +&pinctrl {
> +	usb-host {
> +		host_drv: host-drv {
> +			rockchip,pins = <RK_GPIO0 6 RK_FUNC_GPIO &pcfg_pull_default>;
> +		};
> +	};
> +
> +	usb-otg {
> +		otg_drv: otg-drv {
> +			rockchip,pins = <RK_GPIO0 5 RK_FUNC_GPIO &pcfg_pull_default>;
> +		};
> +	};
> +
> +	sdmmc {
> +		sdmmc_pwr: sdmmc-pwr {
> +			rockchip,pins = <RK_GPIO3 7 RK_FUNC_GPIO &pcfg_pull_default>;
> +		};
> +	};
> +
> +	sdio {
> +		wifi_pwr: wifi-pwr {
> +			rockchip,pins = <RK_GPIO3 24 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +};
> +
> +&uart2 {
> +	status = "okay";
> +};
> +
> +&usb_host {
> +	status = "okay";
> +};
> +
> +&usb_otg {
> +	status = "okay";
> +};
> +
> +&usbphy {
> +	status = "okay";
> +};
> +
> +&wdt {
> +	status = "okay";
> +};
> +
>


-- 
Best Regards
Shawn Lin



From jh80.chung at samsung.com  Thu Oct  6 21:12:54 2016
From: jh80.chung at samsung.com (Jaehoon Chung)
Date: Fri, 07 Oct 2016 13:12:54 +0900
Subject: [RFC PATCH v2 1/4] mmc: dw_mmc: add runtime PM callback
In-Reply-To: <1475225317-2815-2-git-send-email-shawn.lin@rock-chips.com>
References: <1475225317-2815-1-git-send-email-shawn.lin@rock-chips.com>
 <CGME20160930084627epcas1p182ccca03bf63d4cd072e061ca5800510@epcas1p1.samsung.com>
 <1475225317-2815-2-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <2dd84d82-a14b-7d5e-80f0-89e6c0b1aaae@samsung.com>

Hi Shawn,

On 09/30/2016 05:48 PM, Shawn Lin wrote:
> This patch add dw_mci_runtime_suspend/resume interfaces
> and expose it to dw_mci variant driver to support runtime
> PM.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> 
> ---
> 
>  drivers/mmc/host/dw_mmc.c | 60 +++++++++++++++++++++++++++++++++++++++++++++--
>  drivers/mmc/host/dw_mmc.h |  4 +++-
>  2 files changed, 61 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 4fcbc40..54b860e 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -3266,7 +3266,7 @@ EXPORT_SYMBOL(dw_mci_remove);
>  
>  
>  
> -#ifdef CONFIG_PM_SLEEP
> +#ifdef CONFIG_PM
>  /*
>   * TODO: we should probably disable the clock to the card in the suspend path.
>   */
> @@ -3324,7 +3324,63 @@ int dw_mci_resume(struct dw_mci *host)
>  	return 0;
>  }
>  EXPORT_SYMBOL(dw_mci_resume);
> -#endif /* CONFIG_PM_SLEEP */
> +
> +int dw_mci_runtime_suspend(struct dw_mci *host)
> +{
> +	printk("dw_mci_runtime_suspend\n");

Maybe I think you will remove this..if you send the patch, not RFC.

> +
> +	if (host->use_dma && host->dma_ops->exit)
> +		host->dma_ops->exit(host);

Can just call dw_mci_suspend()

> +
> +	clk_disable_unprepare(host->ciu_clk);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(dw_mci_runtime_suspend);
> +
> +int dw_mci_runtime_resume(struct dw_mci *host)
> +{
> +	int ret = 0;
> +	int i;

Can make one line.

> +
> +	printk("dw_mci_runtime_resume\n");
> +
> +	ret = clk_prepare_enable(host->ciu_clk);
> +	if (ret)
> +		return ret;
> +
> +	if (host->use_dma && host->dma_ops->init)
> +		host->dma_ops->init(host);
> +
> +	mci_writel(host, FIFOTH, host->fifoth_val);
> +	host->prev_blksz = 0;
> +
> +	mci_writel(host, TMOUT, 0xFFFFFFFF);
> +	mci_writel(host, RINTSTS, 0xFFFFFFFF);
> +	mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE |
> +				  SDMMC_INT_DATA_OVER |
> +				  SDMMC_INT_TXDR | SDMMC_INT_RXDR |
> +				  DW_MCI_ERROR_FLAGS);
> +	mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE);
> +
> +	for (i = 0; i < host->num_slots; i++) {
> +		struct dw_mci_slot *slot = host->slot[i];
> +
> +		if (!slot)
> +			continue;
> +
> +		if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
> +			dw_mci_set_ios(slot->mmc, &slot->mmc->ios);
> +			dw_mci_setup_bus(slot, true);
> +		}
> +	}
> +
> +	dw_mci_enable_cd(host);

Some part of this function can be reused with codes in dw_mci_resume().

Best Regards,
Jaehoon Chung

> +
> +	return ret;
> +}
> +EXPORT_SYMBOL(dw_mci_runtime_resume);
> +#endif /* CONFIG_PM */
>  
>  static int __init dw_mci_init(void)
>  {
> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
> index e8cd2de..baa7261 100644
> --- a/drivers/mmc/host/dw_mmc.h
> +++ b/drivers/mmc/host/dw_mmc.h
> @@ -234,9 +234,11 @@
>  
>  extern int dw_mci_probe(struct dw_mci *host);
>  extern void dw_mci_remove(struct dw_mci *host);
> -#ifdef CONFIG_PM_SLEEP
> +#ifdef CONFIG_PM
>  extern int dw_mci_suspend(struct dw_mci *host);
>  extern int dw_mci_resume(struct dw_mci *host);
> +extern int dw_mci_runtime_suspend(struct dw_mci *host);
> +extern int dw_mci_runtime_resume(struct dw_mci *host);
>  #endif
>  
>  /**
> 



From jh80.chung at samsung.com  Thu Oct  6 21:15:55 2016
From: jh80.chung at samsung.com (Jaehoon Chung)
Date: Fri, 07 Oct 2016 13:15:55 +0900
Subject: [RFC PATCH v2 4/4] mmc: dw_mmc-rockchip: disable biu clk and genpd
 if possible
In-Reply-To: <1475225317-2815-5-git-send-email-shawn.lin@rock-chips.com>
References: <1475225317-2815-1-git-send-email-shawn.lin@rock-chips.com>
 <CGME20160930084711epcas1p39c48a870457a6f9985574963ae683354@epcas1p3.samsung.com>
 <1475225317-2815-5-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <b9180674-648a-d2d1-0221-cec90b73adab@samsung.com>

On 09/30/2016 05:48 PM, Shawn Lin wrote:
> We could disable biu clk and power-off genpd if gpio
> card detect available.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> ---
> 
>  drivers/mmc/host/dw_mmc-rockchip.c | 18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
> index 3ad041c..e7b3b6d 100644
> --- a/drivers/mmc/host/dw_mmc-rockchip.c
> +++ b/drivers/mmc/host/dw_mmc-rockchip.c
> @@ -13,6 +13,7 @@
>  #include <linux/mmc/host.h>
>  #include <linux/mmc/dw_mmc.h>
>  #include <linux/of_address.h>
> +#include <linux/mmc/slot-gpio.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/slab.h>
>  
> @@ -366,14 +367,29 @@ static int dw_mci_rockchip_remove(struct platform_device *pdev)
>  static int dw_mci_rockchip_runtime_suspend(struct device *dev)
>  {
>  	struct dw_mci *host = dev_get_drvdata(dev);
> +	int ret;
>  
> -	return dw_mci_runtime_suspend(host);
> +	ret = dw_mci_runtime_suspend(host);
> +	if (ret)
> +		return ret;
> +
> +	if (mmc_can_gpio_cd(host->slot[0]->mmc)) {

Can use cur_slot instead of slot[0]? And doesn't need to check "host->slot[]" or "host->cur_slot"?

Best Regards,
Jaehoon Chung

> +		clk_disable_unprepare(host->biu_clk);
> +		pm_runtime_put(dev);
> +	}
> +
> +	return 0;
>  }
>  
>  static int dw_mci_rockchip_runtime_resume(struct device *dev)
>  {
>  	struct dw_mci *host = dev_get_drvdata(dev);
>  
> +	if (mmc_can_gpio_cd(host->slot[0]->mmc)) {
> +		pm_runtime_get_sync(dev);
> +		clk_prepare_enable(host->biu_clk);
> +	}
> +
>  	return dw_mci_runtime_resume(host);
>  }
>  #endif /* CONFIG_PM */
> 



From paweljarosz3691 at gmail.com  Fri Oct  7 01:40:21 2016
From: paweljarosz3691 at gmail.com (=?UTF-8?Q?Pawe=c5=82_Jarosz?=)
Date: Fri, 7 Oct 2016 10:40:21 +0200
Subject: [PATCH v2 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
In-Reply-To: <a166a444-8819-ffe7-8ee1-1f632f6a66ab@rock-chips.com>
References: <cover.1475774981.git.paweljarosz3691@gmail.com>
 <b63a0ad452a487beb1d0c07addb9208cc3b3eeef.1475774981.git.paweljarosz3691@gmail.com>
 <a166a444-8819-ffe7-8ee1-1f632f6a66ab@rock-chips.com>
Message-ID: <18c0552c-10fa-a749-9777-9a99da9f275f@gmail.com>

Hi Shawn,


>> +&mmc0 {
>> +    bus-width = <4>;
>> +    cap-mmc-highspeed;
>> +    cap-sd-highspeed;
>> +    mmc-pwrseq = <&mmc_pwrseq>;
>
> Removed this could make SD works?

Yes but disabling bus-width causes sd performance decrease(defaults to 
1?) so i'll leave this one.

Other sugestions will be included in v3.

Thanks

Pawe?.






From shawn.lin at rock-chips.com  Fri Oct  7 01:52:47 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Fri, 7 Oct 2016 16:52:47 +0800
Subject: [PATCH v2 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
In-Reply-To: <18c0552c-10fa-a749-9777-9a99da9f275f@gmail.com>
References: <cover.1475774981.git.paweljarosz3691@gmail.com>
 <b63a0ad452a487beb1d0c07addb9208cc3b3eeef.1475774981.git.paweljarosz3691@gmail.com>
 <a166a444-8819-ffe7-8ee1-1f632f6a66ab@rock-chips.com>
 <18c0552c-10fa-a749-9777-9a99da9f275f@gmail.com>
Message-ID: <202c4ce7-ffaa-33f8-66e4-a48c15fade69@rock-chips.com>

? 2016/10/7 16:40, Pawe? Jarosz ??:
> Hi Shawn,
>
>
>>> +&mmc0 {
>>> +    bus-width = <4>;
>>> +    cap-mmc-highspeed;
>>> +    cap-sd-highspeed;
>>> +    mmc-pwrseq = <&mmc_pwrseq>;
>>
>> Removed this could make SD works?
>
> Yes but disabling bus-width causes sd performance decrease(defaults to
> 1?) so i'll leave this one.

I just pointed to the mmc-pwrseq, not for others properties :)

>
> Other sugestions will be included in v3.
>
> Thanks
>
> Pawe?.
>
>
>
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip


-- 
Best Regards
Shawn Lin



From shawn.lin at rock-chips.com  Fri Oct  7 02:01:46 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Fri, 7 Oct 2016 17:01:46 +0800
Subject: [RFC PATCH v2 4/4] mmc: dw_mmc-rockchip: disable biu clk and
 genpd if possible
In-Reply-To: <b9180674-648a-d2d1-0221-cec90b73adab@samsung.com>
References: <1475225317-2815-1-git-send-email-shawn.lin@rock-chips.com>
 <CGME20160930084711epcas1p39c48a870457a6f9985574963ae683354@epcas1p3.samsung.com>
 <1475225317-2815-5-git-send-email-shawn.lin@rock-chips.com>
 <b9180674-648a-d2d1-0221-cec90b73adab@samsung.com>
Message-ID: <be4ffbce-0ea0-49d6-7fed-a0ed648fa2b9@rock-chips.com>

? 2016/10/7 12:15, Jaehoon Chung ??:
> On 09/30/2016 05:48 PM, Shawn Lin wrote:
>> We could disable biu clk and power-off genpd if gpio
>> card detect available.
>>
>> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>> ---
>>
>>  drivers/mmc/host/dw_mmc-rockchip.c | 18 +++++++++++++++++-
>>  1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
>> index 3ad041c..e7b3b6d 100644
>> --- a/drivers/mmc/host/dw_mmc-rockchip.c
>> +++ b/drivers/mmc/host/dw_mmc-rockchip.c
>> @@ -13,6 +13,7 @@
>>  #include <linux/mmc/host.h>
>>  #include <linux/mmc/dw_mmc.h>
>>  #include <linux/of_address.h>
>> +#include <linux/mmc/slot-gpio.h>
>>  #include <linux/pm_runtime.h>
>>  #include <linux/slab.h>
>>
>> @@ -366,14 +367,29 @@ static int dw_mci_rockchip_remove(struct platform_device *pdev)
>>  static int dw_mci_rockchip_runtime_suspend(struct device *dev)
>>  {
>>  	struct dw_mci *host = dev_get_drvdata(dev);
>> +	int ret;
>>
>> -	return dw_mci_runtime_suspend(host);
>> +	ret = dw_mci_runtime_suspend(host);
>> +	if (ret)
>> +		return ret;
>> +
>> +	if (mmc_can_gpio_cd(host->slot[0]->mmc)) {
>
> Can use cur_slot instead of slot[0]? And doesn't need to check "host->slot[]" or "host->cur_slot"?

yes, we could. I will fix this for RFC-V3. Also I think we could
disable biu_clk and genpd for non-removable devices since in these
cases, we don't have interaction from devices 2 host.. But for sd,
we should consider the card detect interrupt.


>
> Best Regards,
> Jaehoon Chung
>
>> +		clk_disable_unprepare(host->biu_clk);
>> +		pm_runtime_put(dev);
>> +	}
>> +
>> +	return 0;
>>  }
>>
>>  static int dw_mci_rockchip_runtime_resume(struct device *dev)
>>  {
>>  	struct dw_mci *host = dev_get_drvdata(dev);
>>
>> +	if (mmc_can_gpio_cd(host->slot[0]->mmc)) {
>> +		pm_runtime_get_sync(dev);
>> +		clk_prepare_enable(host->biu_clk);
>> +	}
>> +
>>  	return dw_mci_runtime_resume(host);
>>  }
>>  #endif /* CONFIG_PM */
>>
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>


-- 
Best Regards
Shawn Lin



From shawn.lin at rock-chips.com  Fri Oct  7 02:19:48 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Fri, 7 Oct 2016 17:19:48 +0800
Subject: [RFC PATCH v2 1/4] mmc: dw_mmc: add runtime PM callback
In-Reply-To: <2dd84d82-a14b-7d5e-80f0-89e6c0b1aaae@samsung.com>
References: <1475225317-2815-1-git-send-email-shawn.lin@rock-chips.com>
 <CGME20160930084627epcas1p182ccca03bf63d4cd072e061ca5800510@epcas1p1.samsung.com>
 <1475225317-2815-2-git-send-email-shawn.lin@rock-chips.com>
 <2dd84d82-a14b-7d5e-80f0-89e6c0b1aaae@samsung.com>
Message-ID: <90e9ac7c-9ced-1655-5310-78ee190c51cf@rock-chips.com>

? 2016/10/7 12:12, Jaehoon Chung ??:
> Hi Shawn,
>
> On 09/30/2016 05:48 PM, Shawn Lin wrote:
>> This patch add dw_mci_runtime_suspend/resume interfaces
>> and expose it to dw_mci variant driver to support runtime
>> PM.
>>
>> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>>
>> ---
>>
>>  drivers/mmc/host/dw_mmc.c | 60 +++++++++++++++++++++++++++++++++++++++++++++--
>>  drivers/mmc/host/dw_mmc.h |  4 +++-
>>  2 files changed, 61 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 4fcbc40..54b860e 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -3266,7 +3266,7 @@ EXPORT_SYMBOL(dw_mci_remove);
>>
>>
>>
>> -#ifdef CONFIG_PM_SLEEP
>> +#ifdef CONFIG_PM
>>  /*
>>   * TODO: we should probably disable the clock to the card in the suspend path.
>>   */
>> @@ -3324,7 +3324,63 @@ int dw_mci_resume(struct dw_mci *host)
>>  	return 0;
>>  }
>>  EXPORT_SYMBOL(dw_mci_resume);
>> -#endif /* CONFIG_PM_SLEEP */
>> +
>> +int dw_mci_runtime_suspend(struct dw_mci *host)
>> +{
>> +	printk("dw_mci_runtime_suspend\n");
>
> Maybe I think you will remove this..if you send the patch, not RFC.

yep, it just for me to print info for testing the rpm governer.
I will remove this when sending non-RFC one.

>
>> +
>> +	if (host->use_dma && host->dma_ops->exit)
>> +		host->dma_ops->exit(host);
>
> Can just call dw_mci_suspend()

If we deploy rpm properly, we don't need system PM at all..

To be frank, I was wanna remove dw_mci_suspend/resume pairs,
and only leave the runtime pairs here. As you could see that
runtime PM and system PM does the same thing, so personally
I realize we should help dw_mmc variant drivers migrate to use
runtime PM. That is what I did for dw_mmc-rockchip. If we are
not sure should we enable rpm for i.e., exynos, or k3, we don't
add pm_runtime_* for them for the first step and leave it to
the owners/users to make the decision. The following code should
be enough to help we achieve the first step.

static const struct dev_pm_ops dw_mci_XXXXXX_dev_pm_ops = {
	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
				pm_runtime_force_resume)
	SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
			   dw_mci_runtime_resume,
			   NULL)
};

If there are some special ops for system PM like exynos, we could wrap
new dw_mci_exynos_runtime_resume there..

The same for dw_mci_resume.

What's your opinion?  Seems Ulf was too busy to make comments
here. But I believe it is in the right direction.


>
>> +
>> +	clk_disable_unprepare(host->ciu_clk);
>> +
>> +	return 0;
>> +}
>> +EXPORT_SYMBOL(dw_mci_runtime_suspend);
>> +
>> +int dw_mci_runtime_resume(struct dw_mci *host)
>> +{
>> +	int ret = 0;
>> +	int i;
>
> Can make one line.
>
>> +
>> +	printk("dw_mci_runtime_resume\n");
>> +
>> +	ret = clk_prepare_enable(host->ciu_clk);
>> +	if (ret)
>> +		return ret;
>> +
>> +	if (host->use_dma && host->dma_ops->init)
>> +		host->dma_ops->init(host);
>> +
>> +	mci_writel(host, FIFOTH, host->fifoth_val);
>> +	host->prev_blksz = 0;
>> +
>> +	mci_writel(host, TMOUT, 0xFFFFFFFF);
>> +	mci_writel(host, RINTSTS, 0xFFFFFFFF);
>> +	mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE |
>> +				  SDMMC_INT_DATA_OVER |
>> +				  SDMMC_INT_TXDR | SDMMC_INT_RXDR |
>> +				  DW_MCI_ERROR_FLAGS);
>> +	mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE);
>> +
>> +	for (i = 0; i < host->num_slots; i++) {
>> +		struct dw_mci_slot *slot = host->slot[i];
>> +
>> +		if (!slot)
>> +			continue;
>> +
>> +		if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
>> +			dw_mci_set_ios(slot->mmc, &slot->mmc->ios);
>> +			dw_mci_setup_bus(slot, true);
>> +		}
>> +	}
>> +
>> +	dw_mci_enable_cd(host);
>
> Some part of this function can be reused with codes in dw_mci_resume().
>
> Best Regards,
> Jaehoon Chung
>
>> +
>> +	return ret;
>> +}
>> +EXPORT_SYMBOL(dw_mci_runtime_resume);
>> +#endif /* CONFIG_PM */
>>
>>  static int __init dw_mci_init(void)
>>  {
>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
>> index e8cd2de..baa7261 100644
>> --- a/drivers/mmc/host/dw_mmc.h
>> +++ b/drivers/mmc/host/dw_mmc.h
>> @@ -234,9 +234,11 @@
>>
>>  extern int dw_mci_probe(struct dw_mci *host);
>>  extern void dw_mci_remove(struct dw_mci *host);
>> -#ifdef CONFIG_PM_SLEEP
>> +#ifdef CONFIG_PM
>>  extern int dw_mci_suspend(struct dw_mci *host);
>>  extern int dw_mci_resume(struct dw_mci *host);
>> +extern int dw_mci_runtime_suspend(struct dw_mci *host);
>> +extern int dw_mci_runtime_resume(struct dw_mci *host);
>>  #endif
>>
>>  /**
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Best Regards
Shawn Lin



From heiko at sntech.de  Fri Oct  7 03:01:38 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 07 Oct 2016 12:01:38 +0200
Subject: [PATCH v2 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
In-Reply-To: <a166a444-8819-ffe7-8ee1-1f632f6a66ab@rock-chips.com>
References: <cover.1475774981.git.paweljarosz3691@gmail.com>
 <b63a0ad452a487beb1d0c07addb9208cc3b3eeef.1475774981.git.paweljarosz3691@gmail.com>
 <a166a444-8819-ffe7-8ee1-1f632f6a66ab@rock-chips.com>
Message-ID: <2320435.WKGs9crzlB@phil>

Am Freitag, 7. Oktober 2016, 10:29:48 CEST schrieb Shawn Lin:
> Hi Pawe? ,
> 
> On 2016/10/7 1:38, Pawe? Jarosz wrote:
> > MK808 is a tv stick which has rockchip rk3066 CPU inside, two usb ports
> > - host and otg, micro sd card slot and onboard wifi RK901.
> > 
> > Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
> > ---
> > 
> > Changes in v2:
> > - included Heiko sugestion.
> > 
> >  Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
> >  arch/arm/boot/dts/Makefile                         |   1 +
> >  arch/arm/boot/dts/rk3066a-mk808.dts                | 184
> >  +++++++++++++++++++++ 3 files changed, 189 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> > b/Documentation/devicetree/bindings/arm/rockchip.txt index
> > 55f388f..c09595b 100644
> > --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> > +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> > @@ -17,6 +17,10 @@ Rockchip platforms device tree bindings
> > 
> >      Required root node properties:
> >        - compatible = "chipspark,rayeager-px2", "rockchip,rk3066a";
> > 
> > +- Rikomagic MK808 v1 board:
> > +    Required root node properties:
> > +      - compatible = "rikomagic,mk808", "rockchip,rk3066a";
> > +
> > 
> >  - Radxa Rock board:
> >      Required root node properties:
> >        - compatible = "radxa,rock", "rockchip,rk3188";
> > 
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index befcd26..f19cc1d 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -639,6 +639,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> > 
> >  	rk3036-kylin.dtb \
> >  	rk3066a-bqcurie2.dtb \
> >  	rk3066a-marsboard.dtb \
> > 
> > +	rk3066a-mk808.dtb \
> > 
> >  	rk3066a-rayeager.dtb \
> >  	rk3188-radxarock.dtb \
> >  	rk3228-evb.dtb \
> > 
> > diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts
> > b/arch/arm/boot/dts/rk3066a-mk808.dts new file mode 100644
> > index 0000000..2878562
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/rk3066a-mk808.dts
> > @@ -0,0 +1,184 @@
> > +/*
> > + * Copyright (c) 2016 Pawe? Jarosz <paweljarosz3691 at gmail.com>
> > + *
> > + * 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 file 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 file 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.
> > + */
> > +
> > +/dts-v1/;
> > +#include "rk3066a.dtsi"
> > +
> > +/ {
> > +	model = "Rikomagic MK808";
> > +	compatible = "rikomagic,mk808", "rockchip,rk3066a";
> > +
> > +	chosen {
> > +		stdout-path = "serial2:115200n8";
> > +	};
> > +
> > +	memory at 60000000 {
> > +		device_type = "memory";
> > +		reg = <0x60000000 0x40000000>;
> > +	};
> > +
> > +	gpio-leds {
> > +		compatible = "gpio-leds";
> > +
> > +		blue {
> > +			label = "mk808:blue:power";
> > +			gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
> > +			default-state = "off";
> > +			linux,default-trigger = "default-on";
> > +		};
> > +	};
> > +
> > +	mmc_pwrseq: mmc-pwrseq {
> > +		compatible = "mmc-pwrseq-simple";
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&sdmmc_pwr>;
> 
> sd slot does not contain a reset pin. So the power pin should be
> enough. just add sdmmc_pwr to mmc0's pinctrl-0 and let mmc driver
> control it should be enough. Typically pwrseq is for emmc and sdio.
> We don't need a pwerseq to control power for sd slot..
> 
> But it seems sdmmc_pwr is a GPIO, but not functional port.
> So I am interesting that why MK808 board doesn't use the mmc
> controller's default power pin but chosing another gpio, so finally
> we have to add thses code for your DT.

Actually, we always model the sd-mmc pwr-pin as gpio-based regulator (see 
sdmmc-regulator for example in the rk3066a-rayeager.dts), and specifiy this 
regulator as vmmc. That way the mmc core really can control the power.


Heiko


From bhelgaas at google.com  Fri Oct  7 09:27:06 2016
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Fri, 07 Oct 2016 11:27:06 -0500
Subject: [PATCH 1/3] PCI: rockchip: Rename accessors
Message-ID: <20161007162706.23835.10081.stgit@bhelgaas-glaptop2.roam.corp.google.com>

Rename rockchip_pcie_read() to rockchip_readl() and rockchip_pcie_write()
to rockchip_writel() for consistency with other drivers.  No functional
change intended.

Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
---
 drivers/pci/host/pcie-rockchip.c |   85 +++++++++++++++++++-------------------
 1 file changed, 42 insertions(+), 43 deletions(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index b8c82fc..0ef2f9f 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -204,12 +204,12 @@ struct rockchip_pcie {
 	struct	irq_domain *irq_domain;
 };
 
-static u32 rockchip_pcie_read(struct rockchip_pcie *rockchip, u32 reg)
+static u32 rockchip_readl(struct rockchip_pcie *rockchip, u32 reg)
 {
 	return readl(rockchip->apb_base + reg);
 }
 
-static void rockchip_pcie_write(struct rockchip_pcie *rockchip, u32 val,
+static void rockchip_writel(struct rockchip_pcie *rockchip, u32 val,
 				u32 reg)
 {
 	writel(val, rockchip->apb_base + reg);
@@ -219,18 +219,18 @@ static void rockchip_pcie_enable_bw_int(struct rockchip_pcie *rockchip)
 {
 	u32 status;
 
-	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
+	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
 	status |= (PCIE_RC_CONFIG_LCS_LBMIE | PCIE_RC_CONFIG_LCS_LABIE);
-	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
+	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_LCS);
 }
 
 static void rockchip_pcie_clr_bw_int(struct rockchip_pcie *rockchip)
 {
 	u32 status;
 
-	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
+	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
 	status |= (PCIE_RC_CONFIG_LCS_LBMS | PCIE_RC_CONFIG_LCS_LAMS);
-	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
+	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_LCS);
 }
 
 static void rockchip_pcie_update_txcredit_mui(struct rockchip_pcie *rockchip)
@@ -238,10 +238,10 @@ static void rockchip_pcie_update_txcredit_mui(struct rockchip_pcie *rockchip)
 	u32 val;
 
 	/* Update Tx credit maximum update interval */
-	val = rockchip_pcie_read(rockchip, PCIE_CORE_TXCREDIT_CFG1);
+	val = rockchip_readl(rockchip, PCIE_CORE_TXCREDIT_CFG1);
 	val &= ~PCIE_CORE_TXCREDIT_CFG1_MUI_MASK;
 	val |= PCIE_CORE_TXCREDIT_CFG1_MUI_ENCODE(24000);	/* ns */
-	rockchip_pcie_write(rockchip, val, PCIE_CORE_TXCREDIT_CFG1);
+	rockchip_writel(rockchip, val, PCIE_CORE_TXCREDIT_CFG1);
 }
 
 static int rockchip_pcie_valid_device(struct rockchip_pcie *rockchip,
@@ -438,7 +438,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		return err;
 	}
 
-	rockchip_pcie_write(rockchip,
+	rockchip_writel(rockchip,
 			    PCIE_CLIENT_CONF_ENABLE |
 			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
 			    PCIE_CLIENT_ARI_ENABLE |
@@ -487,17 +487,17 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 	 * reliable and enabling ASPM doesn't work.  This is a controller
 	 * bug we need to work around.
 	 */
-	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
-	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
+	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
+	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
 
 	/* Fix the transmitted FTS count desired to exit from L0s. */
-	status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL_PLC1);
+	status = rockchip_readl(rockchip, PCIE_CORE_CTRL_PLC1);
 	status = (status & PCIE_CORE_CTRL_PLC1_FTS_MASK) |
 		 (PCIE_CORE_CTRL_PLC1_FTS_CNT << PCIE_CORE_CTRL_PLC1_FTS_SHIFT);
-	rockchip_pcie_write(rockchip, status, PCIE_CORE_CTRL_PLC1);
+	rockchip_writel(rockchip, status, PCIE_CORE_CTRL_PLC1);
 
 	/* Enable Gen1 training */
-	rockchip_pcie_write(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
+	rockchip_writel(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
 			    PCIE_CLIENT_CONFIG);
 
 	gpiod_set_value(rockchip->ep_gpio, 1);
@@ -506,8 +506,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 	timeout = jiffies + msecs_to_jiffies(500);
 
 	for (;;) {
-		status = rockchip_pcie_read(rockchip,
-					    PCIE_CLIENT_BASIC_STATUS1);
+		status = rockchip_readl(rockchip, PCIE_CLIENT_BASIC_STATUS1);
 		if ((status & PCIE_CLIENT_LINK_STATUS_MASK) ==
 		    PCIE_CLIENT_LINK_STATUS_UP) {
 			dev_dbg(dev, "PCIe link training gen1 pass!\n");
@@ -526,13 +525,13 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 	 * Enable retrain for gen2. This should be configured only after
 	 * gen1 finished.
 	 */
-	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
+	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
 	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
-	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
+	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_LCS);
 
 	timeout = jiffies + msecs_to_jiffies(500);
 	for (;;) {
-		status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
+		status = rockchip_readl(rockchip, PCIE_CORE_CTRL);
 		if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
 		    PCIE_CORE_PL_CONF_SPEED_5G) {
 			dev_dbg(dev, "PCIe link training gen2 pass!\n");
@@ -548,25 +547,25 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 	}
 
 	/* Check the final link width from negotiated lane counter from MGMT */
-	status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
+	status = rockchip_readl(rockchip, PCIE_CORE_CTRL);
 	status =  0x1 << ((status & PCIE_CORE_PL_CONF_LANE_MASK) >>
 			  PCIE_CORE_PL_CONF_LANE_MASK);
 	dev_dbg(dev, "current link width is x%d\n", status);
 
-	rockchip_pcie_write(rockchip, ROCKCHIP_VENDOR_ID,
+	rockchip_writel(rockchip, ROCKCHIP_VENDOR_ID,
 			    PCIE_RC_CONFIG_VENDOR);
-	rockchip_pcie_write(rockchip,
+	rockchip_writel(rockchip,
 			    PCI_CLASS_BRIDGE_PCI << PCIE_RC_CONFIG_SCC_SHIFT,
 			    PCIE_RC_CONFIG_RID_CCR);
-	rockchip_pcie_write(rockchip, 0x0, PCIE_RC_BAR_CONF);
+	rockchip_writel(rockchip, 0x0, PCIE_RC_BAR_CONF);
 
-	rockchip_pcie_write(rockchip,
+	rockchip_writel(rockchip,
 			    (RC_REGION_0_ADDR_TRANS_L + RC_REGION_0_PASS_BITS),
 			    PCIE_CORE_OB_REGION_ADDR0);
-	rockchip_pcie_write(rockchip, RC_REGION_0_ADDR_TRANS_H,
+	rockchip_writel(rockchip, RC_REGION_0_ADDR_TRANS_H,
 			    PCIE_CORE_OB_REGION_ADDR1);
-	rockchip_pcie_write(rockchip, 0x0080000a, PCIE_CORE_OB_REGION_DESC0);
-	rockchip_pcie_write(rockchip, 0x0, PCIE_CORE_OB_REGION_DESC1);
+	rockchip_writel(rockchip, 0x0080000a, PCIE_CORE_OB_REGION_DESC0);
+	rockchip_writel(rockchip, 0x0, PCIE_CORE_OB_REGION_DESC1);
 
 	return 0;
 }
@@ -578,10 +577,10 @@ static irqreturn_t rockchip_pcie_subsys_irq_handler(int irq, void *arg)
 	u32 reg;
 	u32 sub_reg;
 
-	reg = rockchip_pcie_read(rockchip, PCIE_CLIENT_INT_STATUS);
+	reg = rockchip_readl(rockchip, PCIE_CLIENT_INT_STATUS);
 	if (reg & PCIE_CLIENT_INT_LOCAL) {
 		dev_dbg(dev, "local interrupt received\n");
-		sub_reg = rockchip_pcie_read(rockchip, PCIE_CORE_INT_STATUS);
+		sub_reg = rockchip_readl(rockchip, PCIE_CORE_INT_STATUS);
 		if (sub_reg & PCIE_CORE_INT_PRFPE)
 			dev_dbg(dev, "parity error detected while reading from the PNP receive FIFO RAM\n");
 
@@ -624,15 +623,15 @@ static irqreturn_t rockchip_pcie_subsys_irq_handler(int irq, void *arg)
 		if (sub_reg & PCIE_CORE_INT_MMVC)
 			dev_dbg(dev, "MSI mask register changes\n");
 
-		rockchip_pcie_write(rockchip, sub_reg, PCIE_CORE_INT_STATUS);
+		rockchip_writel(rockchip, sub_reg, PCIE_CORE_INT_STATUS);
 	} else if (reg & PCIE_CLIENT_INT_PHY) {
 		dev_dbg(dev, "phy link changes\n");
 		rockchip_pcie_update_txcredit_mui(rockchip);
 		rockchip_pcie_clr_bw_int(rockchip);
 	}
 
-	rockchip_pcie_write(rockchip, reg & PCIE_CLIENT_INT_LOCAL,
-			    PCIE_CLIENT_INT_STATUS);
+	rockchip_writel(rockchip, reg & PCIE_CLIENT_INT_LOCAL,
+			PCIE_CLIENT_INT_STATUS);
 
 	return IRQ_HANDLED;
 }
@@ -643,7 +642,7 @@ static irqreturn_t rockchip_pcie_client_irq_handler(int irq, void *arg)
 	struct device *dev = rockchip->dev;
 	u32 reg;
 
-	reg = rockchip_pcie_read(rockchip, PCIE_CLIENT_INT_STATUS);
+	reg = rockchip_readl(rockchip, PCIE_CLIENT_INT_STATUS);
 	if (reg & PCIE_CLIENT_INT_LEGACY_DONE)
 		dev_dbg(dev, "legacy done interrupt received\n");
 
@@ -668,7 +667,7 @@ static irqreturn_t rockchip_pcie_client_irq_handler(int irq, void *arg)
 	if (reg & PCIE_CLIENT_INT_PHY)
 		dev_dbg(dev, "phy interrupt received\n");
 
-	rockchip_pcie_write(rockchip, reg & (PCIE_CLIENT_INT_LEGACY_DONE |
+	rockchip_writel(rockchip, reg & (PCIE_CLIENT_INT_LEGACY_DONE |
 			      PCIE_CLIENT_INT_MSG | PCIE_CLIENT_INT_HOT_RST |
 			      PCIE_CLIENT_INT_DPA | PCIE_CLIENT_INT_FATAL_ERR |
 			      PCIE_CLIENT_INT_NFATAL_ERR |
@@ -690,7 +689,7 @@ static void rockchip_pcie_legacy_int_handler(struct irq_desc *desc)
 
 	chained_irq_enter(chip, desc);
 
-	reg = rockchip_pcie_read(rockchip, PCIE_CLIENT_INT_STATUS);
+	reg = rockchip_readl(rockchip, PCIE_CLIENT_INT_STATUS);
 	reg = (reg & PCIE_CLIENT_INTR_MASK) >> PCIE_CLIENT_INTR_SHIFT;
 
 	while (reg) {
@@ -914,9 +913,9 @@ err_out:
 
 static void rockchip_pcie_enable_interrupts(struct rockchip_pcie *rockchip)
 {
-	rockchip_pcie_write(rockchip, (PCIE_CLIENT_INT_CLI << 16) &
+	rockchip_writel(rockchip, (PCIE_CLIENT_INT_CLI << 16) &
 			    (~PCIE_CLIENT_INT_CLI), PCIE_CLIENT_INT_MASK);
-	rockchip_pcie_write(rockchip, (u32)(~PCIE_CORE_INT),
+	rockchip_writel(rockchip, (u32)(~PCIE_CORE_INT),
 			    PCIE_CORE_INT_MASK);
 
 	rockchip_pcie_enable_bw_int(rockchip);
@@ -986,13 +985,13 @@ static int rockchip_pcie_prog_ob_atu(struct rockchip_pcie *rockchip,
 	ob_addr_1 = upper_addr;
 	ob_desc_0 = (1 << 23 | type);
 
-	rockchip_pcie_write(rockchip, ob_addr_0,
+	rockchip_writel(rockchip, ob_addr_0,
 			    PCIE_CORE_OB_REGION_ADDR0 + aw_offset);
-	rockchip_pcie_write(rockchip, ob_addr_1,
+	rockchip_writel(rockchip, ob_addr_1,
 			    PCIE_CORE_OB_REGION_ADDR1 + aw_offset);
-	rockchip_pcie_write(rockchip, ob_desc_0,
+	rockchip_writel(rockchip, ob_desc_0,
 			    PCIE_CORE_OB_REGION_DESC0 + aw_offset);
-	rockchip_pcie_write(rockchip, 0,
+	rockchip_writel(rockchip, 0,
 			    PCIE_CORE_OB_REGION_DESC1 + aw_offset);
 
 	return 0;
@@ -1019,8 +1018,8 @@ static int rockchip_pcie_prog_ib_atu(struct rockchip_pcie *rockchip,
 	ib_addr_0 |= (lower_addr << 8) & PCIE_CORE_IB_REGION_ADDR0_LO_ADDR;
 	ib_addr_1 = upper_addr;
 
-	rockchip_pcie_write(rockchip, ib_addr_0, PCIE_RP_IB_ADDR0 + aw_offset);
-	rockchip_pcie_write(rockchip, ib_addr_1, PCIE_RP_IB_ADDR1 + aw_offset);
+	rockchip_writel(rockchip, ib_addr_0, PCIE_RP_IB_ADDR0 + aw_offset);
+	rockchip_writel(rockchip, ib_addr_1, PCIE_RP_IB_ADDR1 + aw_offset);
 
 	return 0;
 }



From bhelgaas at google.com  Fri Oct  7 09:27:26 2016
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Fri, 07 Oct 2016 11:27:26 -0500
Subject: [PATCH 3/3] PCI: rockchip: Remove unused platform data
In-Reply-To: <20161007162706.23835.10081.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20161007162706.23835.10081.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <20161007162726.23835.51154.stgit@bhelgaas-glaptop2.roam.corp.google.com>

The rockchip driver never uses the platform drvdata pointer, so don't
bother setting it.  No functional change intended.

Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
---
 drivers/pci/host/pcie-rockchip.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 0a89d02..b3548d0 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -1019,8 +1019,8 @@ static int rockchip_pcie_prog_ib_atu(struct rockchip_pcie *rockchip,
 
 static int rockchip_pcie_probe(struct platform_device *pdev)
 {
-	struct rockchip_pcie *rockchip;
 	struct device *dev = &pdev->dev;
+	struct rockchip_pcie *rockchip;
 	struct pci_bus *bus, *child;
 	struct resource_entry *win;
 	resource_size_t io_base;
@@ -1083,8 +1083,6 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
 	if (err)
 		goto err_vpcie;
 
-	platform_set_drvdata(pdev, rockchip);
-
 	rockchip_pcie_enable_interrupts(rockchip);
 
 	err = rockchip_pcie_init_irq_domain(rockchip);



From bhelgaas at google.com  Fri Oct  7 09:27:14 2016
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Fri, 07 Oct 2016 11:27:14 -0500
Subject: [PATCH 2/3] PCI: rockchip: Swap order of rockchip_writel() reg/val
 arguments
In-Reply-To: <20161007162706.23835.10081.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20161007162706.23835.10081.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <20161007162714.23835.9272.stgit@bhelgaas-glaptop2.roam.corp.google.com>

Swap order of rockchip_writel() arguments to match the "dev, pos, val"
order used by pci_write_config_word() and other drivers.  No functional
change intended.

Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
---
 drivers/pci/host/pcie-rockchip.c |   95 ++++++++++++++++++--------------------
 1 file changed, 44 insertions(+), 51 deletions(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 0ef2f9f..0a89d02 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -209,8 +209,7 @@ static u32 rockchip_readl(struct rockchip_pcie *rockchip, u32 reg)
 	return readl(rockchip->apb_base + reg);
 }
 
-static void rockchip_writel(struct rockchip_pcie *rockchip, u32 val,
-				u32 reg)
+static void rockchip_writel(struct rockchip_pcie *rockchip, u32 reg, u32 val)
 {
 	writel(val, rockchip->apb_base + reg);
 }
@@ -221,7 +220,7 @@ static void rockchip_pcie_enable_bw_int(struct rockchip_pcie *rockchip)
 
 	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
 	status |= (PCIE_RC_CONFIG_LCS_LBMIE | PCIE_RC_CONFIG_LCS_LABIE);
-	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_LCS);
+	rockchip_writel(rockchip, PCIE_RC_CONFIG_LCS, status);
 }
 
 static void rockchip_pcie_clr_bw_int(struct rockchip_pcie *rockchip)
@@ -230,7 +229,7 @@ static void rockchip_pcie_clr_bw_int(struct rockchip_pcie *rockchip)
 
 	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
 	status |= (PCIE_RC_CONFIG_LCS_LBMS | PCIE_RC_CONFIG_LCS_LAMS);
-	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_LCS);
+	rockchip_writel(rockchip, PCIE_RC_CONFIG_LCS, status);
 }
 
 static void rockchip_pcie_update_txcredit_mui(struct rockchip_pcie *rockchip)
@@ -241,7 +240,7 @@ static void rockchip_pcie_update_txcredit_mui(struct rockchip_pcie *rockchip)
 	val = rockchip_readl(rockchip, PCIE_CORE_TXCREDIT_CFG1);
 	val &= ~PCIE_CORE_TXCREDIT_CFG1_MUI_MASK;
 	val |= PCIE_CORE_TXCREDIT_CFG1_MUI_ENCODE(24000);	/* ns */
-	rockchip_writel(rockchip, val, PCIE_CORE_TXCREDIT_CFG1);
+	rockchip_writel(rockchip, PCIE_CORE_TXCREDIT_CFG1, val);
 }
 
 static int rockchip_pcie_valid_device(struct rockchip_pcie *rockchip,
@@ -438,14 +437,13 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		return err;
 	}
 
-	rockchip_writel(rockchip,
+	rockchip_writel(rockchip, PCIE_CLIENT_CONFIG,
 			    PCIE_CLIENT_CONF_ENABLE |
 			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
 			    PCIE_CLIENT_ARI_ENABLE |
 			    PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
 			    PCIE_CLIENT_MODE_RC |
-			    PCIE_CLIENT_GEN_SEL_2,
-				PCIE_CLIENT_CONFIG);
+			    PCIE_CLIENT_GEN_SEL_2);
 
 	err = phy_power_on(rockchip->phy);
 	if (err) {
@@ -488,17 +486,17 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 	 * bug we need to work around.
 	 */
 	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
-	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
+	rockchip_writel(rockchip, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2, status);
 
 	/* Fix the transmitted FTS count desired to exit from L0s. */
 	status = rockchip_readl(rockchip, PCIE_CORE_CTRL_PLC1);
 	status = (status & PCIE_CORE_CTRL_PLC1_FTS_MASK) |
 		 (PCIE_CORE_CTRL_PLC1_FTS_CNT << PCIE_CORE_CTRL_PLC1_FTS_SHIFT);
-	rockchip_writel(rockchip, status, PCIE_CORE_CTRL_PLC1);
+	rockchip_writel(rockchip, PCIE_CORE_CTRL_PLC1, status);
 
 	/* Enable Gen1 training */
-	rockchip_writel(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
-			    PCIE_CLIENT_CONFIG);
+	rockchip_writel(rockchip, PCIE_CLIENT_CONFIG,
+			PCIE_CLIENT_LINK_TRAIN_ENABLE);
 
 	gpiod_set_value(rockchip->ep_gpio, 1);
 
@@ -527,7 +525,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 	 */
 	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
 	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
-	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_LCS);
+	rockchip_writel(rockchip, PCIE_RC_CONFIG_LCS, status);
 
 	timeout = jiffies + msecs_to_jiffies(500);
 	for (;;) {
@@ -552,20 +550,17 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 			  PCIE_CORE_PL_CONF_LANE_MASK);
 	dev_dbg(dev, "current link width is x%d\n", status);
 
-	rockchip_writel(rockchip, ROCKCHIP_VENDOR_ID,
-			    PCIE_RC_CONFIG_VENDOR);
-	rockchip_writel(rockchip,
-			    PCI_CLASS_BRIDGE_PCI << PCIE_RC_CONFIG_SCC_SHIFT,
-			    PCIE_RC_CONFIG_RID_CCR);
-	rockchip_writel(rockchip, 0x0, PCIE_RC_BAR_CONF);
-
-	rockchip_writel(rockchip,
-			    (RC_REGION_0_ADDR_TRANS_L + RC_REGION_0_PASS_BITS),
-			    PCIE_CORE_OB_REGION_ADDR0);
-	rockchip_writel(rockchip, RC_REGION_0_ADDR_TRANS_H,
-			    PCIE_CORE_OB_REGION_ADDR1);
-	rockchip_writel(rockchip, 0x0080000a, PCIE_CORE_OB_REGION_DESC0);
-	rockchip_writel(rockchip, 0x0, PCIE_CORE_OB_REGION_DESC1);
+	rockchip_writel(rockchip, PCIE_RC_CONFIG_VENDOR, ROCKCHIP_VENDOR_ID);
+	rockchip_writel(rockchip, PCIE_RC_CONFIG_RID_CCR,
+			PCI_CLASS_BRIDGE_PCI << PCIE_RC_CONFIG_SCC_SHIFT);
+	rockchip_writel(rockchip, PCIE_RC_BAR_CONF, 0);
+
+	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_ADDR0,
+			RC_REGION_0_ADDR_TRANS_L + RC_REGION_0_PASS_BITS);
+	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_ADDR1,
+			RC_REGION_0_ADDR_TRANS_H);
+	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_DESC0, 0x0080000a);
+	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_DESC1, 0);
 
 	return 0;
 }
@@ -623,15 +618,15 @@ static irqreturn_t rockchip_pcie_subsys_irq_handler(int irq, void *arg)
 		if (sub_reg & PCIE_CORE_INT_MMVC)
 			dev_dbg(dev, "MSI mask register changes\n");
 
-		rockchip_writel(rockchip, sub_reg, PCIE_CORE_INT_STATUS);
+		rockchip_writel(rockchip, PCIE_CORE_INT_STATUS, sub_reg);
 	} else if (reg & PCIE_CLIENT_INT_PHY) {
 		dev_dbg(dev, "phy link changes\n");
 		rockchip_pcie_update_txcredit_mui(rockchip);
 		rockchip_pcie_clr_bw_int(rockchip);
 	}
 
-	rockchip_writel(rockchip, reg & PCIE_CLIENT_INT_LOCAL,
-			PCIE_CLIENT_INT_STATUS);
+	rockchip_writel(rockchip, PCIE_CLIENT_INT_STATUS,
+			reg & PCIE_CLIENT_INT_LOCAL);
 
 	return IRQ_HANDLED;
 }
@@ -667,13 +662,13 @@ static irqreturn_t rockchip_pcie_client_irq_handler(int irq, void *arg)
 	if (reg & PCIE_CLIENT_INT_PHY)
 		dev_dbg(dev, "phy interrupt received\n");
 
-	rockchip_writel(rockchip, reg & (PCIE_CLIENT_INT_LEGACY_DONE |
-			      PCIE_CLIENT_INT_MSG | PCIE_CLIENT_INT_HOT_RST |
-			      PCIE_CLIENT_INT_DPA | PCIE_CLIENT_INT_FATAL_ERR |
-			      PCIE_CLIENT_INT_NFATAL_ERR |
-			      PCIE_CLIENT_INT_CORR_ERR |
-			      PCIE_CLIENT_INT_PHY),
-		   PCIE_CLIENT_INT_STATUS);
+	rockchip_writel(rockchip, PCIE_CLIENT_INT_STATUS,
+			reg & (PCIE_CLIENT_INT_LEGACY_DONE |
+			       PCIE_CLIENT_INT_MSG | PCIE_CLIENT_INT_HOT_RST |
+			       PCIE_CLIENT_INT_DPA | PCIE_CLIENT_INT_FATAL_ERR |
+			       PCIE_CLIENT_INT_NFATAL_ERR |
+			       PCIE_CLIENT_INT_CORR_ERR |
+			       PCIE_CLIENT_INT_PHY));
 
 	return IRQ_HANDLED;
 }
@@ -913,10 +908,9 @@ err_out:
 
 static void rockchip_pcie_enable_interrupts(struct rockchip_pcie *rockchip)
 {
-	rockchip_writel(rockchip, (PCIE_CLIENT_INT_CLI << 16) &
-			    (~PCIE_CLIENT_INT_CLI), PCIE_CLIENT_INT_MASK);
-	rockchip_writel(rockchip, (u32)(~PCIE_CORE_INT),
-			    PCIE_CORE_INT_MASK);
+	rockchip_writel(rockchip, PCIE_CLIENT_INT_MASK,
+			(PCIE_CLIENT_INT_CLI << 16) & (~PCIE_CLIENT_INT_CLI));
+	rockchip_writel(rockchip, PCIE_CORE_INT_MASK, (u32)(~PCIE_CORE_INT));
 
 	rockchip_pcie_enable_bw_int(rockchip);
 }
@@ -985,14 +979,13 @@ static int rockchip_pcie_prog_ob_atu(struct rockchip_pcie *rockchip,
 	ob_addr_1 = upper_addr;
 	ob_desc_0 = (1 << 23 | type);
 
-	rockchip_writel(rockchip, ob_addr_0,
-			    PCIE_CORE_OB_REGION_ADDR0 + aw_offset);
-	rockchip_writel(rockchip, ob_addr_1,
-			    PCIE_CORE_OB_REGION_ADDR1 + aw_offset);
-	rockchip_writel(rockchip, ob_desc_0,
-			    PCIE_CORE_OB_REGION_DESC0 + aw_offset);
-	rockchip_writel(rockchip, 0,
-			    PCIE_CORE_OB_REGION_DESC1 + aw_offset);
+	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_ADDR0 + aw_offset,
+			ob_addr_0);
+	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_ADDR1 + aw_offset,
+			ob_addr_1);
+	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_DESC0 + aw_offset,
+			ob_desc_0);
+	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_DESC1 + aw_offset, 0);
 
 	return 0;
 }
@@ -1018,8 +1011,8 @@ static int rockchip_pcie_prog_ib_atu(struct rockchip_pcie *rockchip,
 	ib_addr_0 |= (lower_addr << 8) & PCIE_CORE_IB_REGION_ADDR0_LO_ADDR;
 	ib_addr_1 = upper_addr;
 
-	rockchip_writel(rockchip, ib_addr_0, PCIE_RP_IB_ADDR0 + aw_offset);
-	rockchip_writel(rockchip, ib_addr_1, PCIE_RP_IB_ADDR1 + aw_offset);
+	rockchip_writel(rockchip, PCIE_RP_IB_ADDR0 + aw_offset, ib_addr_0);
+	rockchip_writel(rockchip, PCIE_RP_IB_ADDR1 + aw_offset, ib_addr_1);
 
 	return 0;
 }



From shawn.lin at rock-chips.com  Fri Oct  7 19:51:06 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sat, 8 Oct 2016 10:51:06 +0800
Subject: [PATCH 1/3] PCI: rockchip: Rename accessors
In-Reply-To: <20161007162706.23835.10081.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20161007162706.23835.10081.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <4417d4f0-312e-11eb-55b6-8265b948ed4c@rock-chips.com>

? 2016/10/8 0:27, Bjorn Helgaas ??:
> Rename rockchip_pcie_read() to rockchip_readl() and rockchip_pcie_write()
> to rockchip_writel() for consistency with other drivers.  No functional
> change intended.
>

It looks okay to me if this modification make pcie-rockchip looks more
consisten with other drivers.

Acked-by: Shawn Lin <shawn.lin at rock-chips.com>

> Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
> ---
>  drivers/pci/host/pcie-rockchip.c |   85 +++++++++++++++++++-------------------
>  1 file changed, 42 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index b8c82fc..0ef2f9f 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -204,12 +204,12 @@ struct rockchip_pcie {
>  	struct	irq_domain *irq_domain;
>  };
>
> -static u32 rockchip_pcie_read(struct rockchip_pcie *rockchip, u32 reg)
> +static u32 rockchip_readl(struct rockchip_pcie *rockchip, u32 reg)
>  {
>  	return readl(rockchip->apb_base + reg);
>  }
>
> -static void rockchip_pcie_write(struct rockchip_pcie *rockchip, u32 val,
> +static void rockchip_writel(struct rockchip_pcie *rockchip, u32 val,
>  				u32 reg)
>  {
>  	writel(val, rockchip->apb_base + reg);
> @@ -219,18 +219,18 @@ static void rockchip_pcie_enable_bw_int(struct rockchip_pcie *rockchip)
>  {
>  	u32 status;
>
> -	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> +	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
>  	status |= (PCIE_RC_CONFIG_LCS_LBMIE | PCIE_RC_CONFIG_LCS_LABIE);
> -	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> +	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_LCS);
>  }
>
>  static void rockchip_pcie_clr_bw_int(struct rockchip_pcie *rockchip)
>  {
>  	u32 status;
>
> -	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> +	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
>  	status |= (PCIE_RC_CONFIG_LCS_LBMS | PCIE_RC_CONFIG_LCS_LAMS);
> -	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> +	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_LCS);
>  }
>
>  static void rockchip_pcie_update_txcredit_mui(struct rockchip_pcie *rockchip)
> @@ -238,10 +238,10 @@ static void rockchip_pcie_update_txcredit_mui(struct rockchip_pcie *rockchip)
>  	u32 val;
>
>  	/* Update Tx credit maximum update interval */
> -	val = rockchip_pcie_read(rockchip, PCIE_CORE_TXCREDIT_CFG1);
> +	val = rockchip_readl(rockchip, PCIE_CORE_TXCREDIT_CFG1);
>  	val &= ~PCIE_CORE_TXCREDIT_CFG1_MUI_MASK;
>  	val |= PCIE_CORE_TXCREDIT_CFG1_MUI_ENCODE(24000);	/* ns */
> -	rockchip_pcie_write(rockchip, val, PCIE_CORE_TXCREDIT_CFG1);
> +	rockchip_writel(rockchip, val, PCIE_CORE_TXCREDIT_CFG1);
>  }
>
>  static int rockchip_pcie_valid_device(struct rockchip_pcie *rockchip,
> @@ -438,7 +438,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  		return err;
>  	}
>
> -	rockchip_pcie_write(rockchip,
> +	rockchip_writel(rockchip,
>  			    PCIE_CLIENT_CONF_ENABLE |
>  			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
>  			    PCIE_CLIENT_ARI_ENABLE |
> @@ -487,17 +487,17 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  	 * reliable and enabling ASPM doesn't work.  This is a controller
>  	 * bug we need to work around.
>  	 */
> -	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
> -	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
> +	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
> +	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
>
>  	/* Fix the transmitted FTS count desired to exit from L0s. */
> -	status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL_PLC1);
> +	status = rockchip_readl(rockchip, PCIE_CORE_CTRL_PLC1);
>  	status = (status & PCIE_CORE_CTRL_PLC1_FTS_MASK) |
>  		 (PCIE_CORE_CTRL_PLC1_FTS_CNT << PCIE_CORE_CTRL_PLC1_FTS_SHIFT);
> -	rockchip_pcie_write(rockchip, status, PCIE_CORE_CTRL_PLC1);
> +	rockchip_writel(rockchip, status, PCIE_CORE_CTRL_PLC1);
>
>  	/* Enable Gen1 training */
> -	rockchip_pcie_write(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
> +	rockchip_writel(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
>  			    PCIE_CLIENT_CONFIG);
>
>  	gpiod_set_value(rockchip->ep_gpio, 1);
> @@ -506,8 +506,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  	timeout = jiffies + msecs_to_jiffies(500);
>
>  	for (;;) {
> -		status = rockchip_pcie_read(rockchip,
> -					    PCIE_CLIENT_BASIC_STATUS1);
> +		status = rockchip_readl(rockchip, PCIE_CLIENT_BASIC_STATUS1);
>  		if ((status & PCIE_CLIENT_LINK_STATUS_MASK) ==
>  		    PCIE_CLIENT_LINK_STATUS_UP) {
>  			dev_dbg(dev, "PCIe link training gen1 pass!\n");
> @@ -526,13 +525,13 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  	 * Enable retrain for gen2. This should be configured only after
>  	 * gen1 finished.
>  	 */
> -	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
> +	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
>  	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
> -	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
> +	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_LCS);
>
>  	timeout = jiffies + msecs_to_jiffies(500);
>  	for (;;) {
> -		status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
> +		status = rockchip_readl(rockchip, PCIE_CORE_CTRL);
>  		if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
>  		    PCIE_CORE_PL_CONF_SPEED_5G) {
>  			dev_dbg(dev, "PCIe link training gen2 pass!\n");
> @@ -548,25 +547,25 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  	}
>
>  	/* Check the final link width from negotiated lane counter from MGMT */
> -	status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
> +	status = rockchip_readl(rockchip, PCIE_CORE_CTRL);
>  	status =  0x1 << ((status & PCIE_CORE_PL_CONF_LANE_MASK) >>
>  			  PCIE_CORE_PL_CONF_LANE_MASK);
>  	dev_dbg(dev, "current link width is x%d\n", status);
>
> -	rockchip_pcie_write(rockchip, ROCKCHIP_VENDOR_ID,
> +	rockchip_writel(rockchip, ROCKCHIP_VENDOR_ID,
>  			    PCIE_RC_CONFIG_VENDOR);
> -	rockchip_pcie_write(rockchip,
> +	rockchip_writel(rockchip,
>  			    PCI_CLASS_BRIDGE_PCI << PCIE_RC_CONFIG_SCC_SHIFT,
>  			    PCIE_RC_CONFIG_RID_CCR);
> -	rockchip_pcie_write(rockchip, 0x0, PCIE_RC_BAR_CONF);
> +	rockchip_writel(rockchip, 0x0, PCIE_RC_BAR_CONF);
>
> -	rockchip_pcie_write(rockchip,
> +	rockchip_writel(rockchip,
>  			    (RC_REGION_0_ADDR_TRANS_L + RC_REGION_0_PASS_BITS),
>  			    PCIE_CORE_OB_REGION_ADDR0);
> -	rockchip_pcie_write(rockchip, RC_REGION_0_ADDR_TRANS_H,
> +	rockchip_writel(rockchip, RC_REGION_0_ADDR_TRANS_H,
>  			    PCIE_CORE_OB_REGION_ADDR1);
> -	rockchip_pcie_write(rockchip, 0x0080000a, PCIE_CORE_OB_REGION_DESC0);
> -	rockchip_pcie_write(rockchip, 0x0, PCIE_CORE_OB_REGION_DESC1);
> +	rockchip_writel(rockchip, 0x0080000a, PCIE_CORE_OB_REGION_DESC0);
> +	rockchip_writel(rockchip, 0x0, PCIE_CORE_OB_REGION_DESC1);
>
>  	return 0;
>  }
> @@ -578,10 +577,10 @@ static irqreturn_t rockchip_pcie_subsys_irq_handler(int irq, void *arg)
>  	u32 reg;
>  	u32 sub_reg;
>
> -	reg = rockchip_pcie_read(rockchip, PCIE_CLIENT_INT_STATUS);
> +	reg = rockchip_readl(rockchip, PCIE_CLIENT_INT_STATUS);
>  	if (reg & PCIE_CLIENT_INT_LOCAL) {
>  		dev_dbg(dev, "local interrupt received\n");
> -		sub_reg = rockchip_pcie_read(rockchip, PCIE_CORE_INT_STATUS);
> +		sub_reg = rockchip_readl(rockchip, PCIE_CORE_INT_STATUS);
>  		if (sub_reg & PCIE_CORE_INT_PRFPE)
>  			dev_dbg(dev, "parity error detected while reading from the PNP receive FIFO RAM\n");
>
> @@ -624,15 +623,15 @@ static irqreturn_t rockchip_pcie_subsys_irq_handler(int irq, void *arg)
>  		if (sub_reg & PCIE_CORE_INT_MMVC)
>  			dev_dbg(dev, "MSI mask register changes\n");
>
> -		rockchip_pcie_write(rockchip, sub_reg, PCIE_CORE_INT_STATUS);
> +		rockchip_writel(rockchip, sub_reg, PCIE_CORE_INT_STATUS);
>  	} else if (reg & PCIE_CLIENT_INT_PHY) {
>  		dev_dbg(dev, "phy link changes\n");
>  		rockchip_pcie_update_txcredit_mui(rockchip);
>  		rockchip_pcie_clr_bw_int(rockchip);
>  	}
>
> -	rockchip_pcie_write(rockchip, reg & PCIE_CLIENT_INT_LOCAL,
> -			    PCIE_CLIENT_INT_STATUS);
> +	rockchip_writel(rockchip, reg & PCIE_CLIENT_INT_LOCAL,
> +			PCIE_CLIENT_INT_STATUS);
>
>  	return IRQ_HANDLED;
>  }
> @@ -643,7 +642,7 @@ static irqreturn_t rockchip_pcie_client_irq_handler(int irq, void *arg)
>  	struct device *dev = rockchip->dev;
>  	u32 reg;
>
> -	reg = rockchip_pcie_read(rockchip, PCIE_CLIENT_INT_STATUS);
> +	reg = rockchip_readl(rockchip, PCIE_CLIENT_INT_STATUS);
>  	if (reg & PCIE_CLIENT_INT_LEGACY_DONE)
>  		dev_dbg(dev, "legacy done interrupt received\n");
>
> @@ -668,7 +667,7 @@ static irqreturn_t rockchip_pcie_client_irq_handler(int irq, void *arg)
>  	if (reg & PCIE_CLIENT_INT_PHY)
>  		dev_dbg(dev, "phy interrupt received\n");
>
> -	rockchip_pcie_write(rockchip, reg & (PCIE_CLIENT_INT_LEGACY_DONE |
> +	rockchip_writel(rockchip, reg & (PCIE_CLIENT_INT_LEGACY_DONE |
>  			      PCIE_CLIENT_INT_MSG | PCIE_CLIENT_INT_HOT_RST |
>  			      PCIE_CLIENT_INT_DPA | PCIE_CLIENT_INT_FATAL_ERR |
>  			      PCIE_CLIENT_INT_NFATAL_ERR |
> @@ -690,7 +689,7 @@ static void rockchip_pcie_legacy_int_handler(struct irq_desc *desc)
>
>  	chained_irq_enter(chip, desc);
>
> -	reg = rockchip_pcie_read(rockchip, PCIE_CLIENT_INT_STATUS);
> +	reg = rockchip_readl(rockchip, PCIE_CLIENT_INT_STATUS);
>  	reg = (reg & PCIE_CLIENT_INTR_MASK) >> PCIE_CLIENT_INTR_SHIFT;
>
>  	while (reg) {
> @@ -914,9 +913,9 @@ err_out:
>
>  static void rockchip_pcie_enable_interrupts(struct rockchip_pcie *rockchip)
>  {
> -	rockchip_pcie_write(rockchip, (PCIE_CLIENT_INT_CLI << 16) &
> +	rockchip_writel(rockchip, (PCIE_CLIENT_INT_CLI << 16) &
>  			    (~PCIE_CLIENT_INT_CLI), PCIE_CLIENT_INT_MASK);
> -	rockchip_pcie_write(rockchip, (u32)(~PCIE_CORE_INT),
> +	rockchip_writel(rockchip, (u32)(~PCIE_CORE_INT),
>  			    PCIE_CORE_INT_MASK);
>
>  	rockchip_pcie_enable_bw_int(rockchip);
> @@ -986,13 +985,13 @@ static int rockchip_pcie_prog_ob_atu(struct rockchip_pcie *rockchip,
>  	ob_addr_1 = upper_addr;
>  	ob_desc_0 = (1 << 23 | type);
>
> -	rockchip_pcie_write(rockchip, ob_addr_0,
> +	rockchip_writel(rockchip, ob_addr_0,
>  			    PCIE_CORE_OB_REGION_ADDR0 + aw_offset);
> -	rockchip_pcie_write(rockchip, ob_addr_1,
> +	rockchip_writel(rockchip, ob_addr_1,
>  			    PCIE_CORE_OB_REGION_ADDR1 + aw_offset);
> -	rockchip_pcie_write(rockchip, ob_desc_0,
> +	rockchip_writel(rockchip, ob_desc_0,
>  			    PCIE_CORE_OB_REGION_DESC0 + aw_offset);
> -	rockchip_pcie_write(rockchip, 0,
> +	rockchip_writel(rockchip, 0,
>  			    PCIE_CORE_OB_REGION_DESC1 + aw_offset);
>
>  	return 0;
> @@ -1019,8 +1018,8 @@ static int rockchip_pcie_prog_ib_atu(struct rockchip_pcie *rockchip,
>  	ib_addr_0 |= (lower_addr << 8) & PCIE_CORE_IB_REGION_ADDR0_LO_ADDR;
>  	ib_addr_1 = upper_addr;
>
> -	rockchip_pcie_write(rockchip, ib_addr_0, PCIE_RP_IB_ADDR0 + aw_offset);
> -	rockchip_pcie_write(rockchip, ib_addr_1, PCIE_RP_IB_ADDR1 + aw_offset);
> +	rockchip_writel(rockchip, ib_addr_0, PCIE_RP_IB_ADDR0 + aw_offset);
> +	rockchip_writel(rockchip, ib_addr_1, PCIE_RP_IB_ADDR1 + aw_offset);
>
>  	return 0;
>  }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Best Regards
Shawn Lin



From shawn.lin at rock-chips.com  Fri Oct  7 19:52:41 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sat, 8 Oct 2016 10:52:41 +0800
Subject: [PATCH 2/3] PCI: rockchip: Swap order of rockchip_writel()
 reg/val arguments
In-Reply-To: <20161007162714.23835.9272.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20161007162706.23835.10081.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <20161007162714.23835.9272.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <be840daa-6602-eb04-e6ee-babf6d4c2aac@rock-chips.com>

? 2016/10/8 0:27, Bjorn Helgaas ??:
> Swap order of rockchip_writel() arguments to match the "dev, pos, val"
> order used by pci_write_config_word() and other drivers.  No functional
> change intended.
>

okay, i saw the pci-tree cleanup for all the host drivers there, so

Acked-by: Shawn Lin <shawn.lin at rock-chips.com>

> Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
> ---
>  drivers/pci/host/pcie-rockchip.c |   95 ++++++++++++++++++--------------------
>  1 file changed, 44 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index 0ef2f9f..0a89d02 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -209,8 +209,7 @@ static u32 rockchip_readl(struct rockchip_pcie *rockchip, u32 reg)
>  	return readl(rockchip->apb_base + reg);
>  }
>
> -static void rockchip_writel(struct rockchip_pcie *rockchip, u32 val,
> -				u32 reg)
> +static void rockchip_writel(struct rockchip_pcie *rockchip, u32 reg, u32 val)
>  {
>  	writel(val, rockchip->apb_base + reg);
>  }
> @@ -221,7 +220,7 @@ static void rockchip_pcie_enable_bw_int(struct rockchip_pcie *rockchip)
>
>  	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
>  	status |= (PCIE_RC_CONFIG_LCS_LBMIE | PCIE_RC_CONFIG_LCS_LABIE);
> -	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_LCS);
> +	rockchip_writel(rockchip, PCIE_RC_CONFIG_LCS, status);
>  }
>
>  static void rockchip_pcie_clr_bw_int(struct rockchip_pcie *rockchip)
> @@ -230,7 +229,7 @@ static void rockchip_pcie_clr_bw_int(struct rockchip_pcie *rockchip)
>
>  	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
>  	status |= (PCIE_RC_CONFIG_LCS_LBMS | PCIE_RC_CONFIG_LCS_LAMS);
> -	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_LCS);
> +	rockchip_writel(rockchip, PCIE_RC_CONFIG_LCS, status);
>  }
>
>  static void rockchip_pcie_update_txcredit_mui(struct rockchip_pcie *rockchip)
> @@ -241,7 +240,7 @@ static void rockchip_pcie_update_txcredit_mui(struct rockchip_pcie *rockchip)
>  	val = rockchip_readl(rockchip, PCIE_CORE_TXCREDIT_CFG1);
>  	val &= ~PCIE_CORE_TXCREDIT_CFG1_MUI_MASK;
>  	val |= PCIE_CORE_TXCREDIT_CFG1_MUI_ENCODE(24000);	/* ns */
> -	rockchip_writel(rockchip, val, PCIE_CORE_TXCREDIT_CFG1);
> +	rockchip_writel(rockchip, PCIE_CORE_TXCREDIT_CFG1, val);
>  }
>
>  static int rockchip_pcie_valid_device(struct rockchip_pcie *rockchip,
> @@ -438,14 +437,13 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  		return err;
>  	}
>
> -	rockchip_writel(rockchip,
> +	rockchip_writel(rockchip, PCIE_CLIENT_CONFIG,
>  			    PCIE_CLIENT_CONF_ENABLE |
>  			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
>  			    PCIE_CLIENT_ARI_ENABLE |
>  			    PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
>  			    PCIE_CLIENT_MODE_RC |
> -			    PCIE_CLIENT_GEN_SEL_2,
> -				PCIE_CLIENT_CONFIG);
> +			    PCIE_CLIENT_GEN_SEL_2);
>
>  	err = phy_power_on(rockchip->phy);
>  	if (err) {
> @@ -488,17 +486,17 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  	 * bug we need to work around.
>  	 */
>  	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
> -	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
> +	rockchip_writel(rockchip, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2, status);
>
>  	/* Fix the transmitted FTS count desired to exit from L0s. */
>  	status = rockchip_readl(rockchip, PCIE_CORE_CTRL_PLC1);
>  	status = (status & PCIE_CORE_CTRL_PLC1_FTS_MASK) |
>  		 (PCIE_CORE_CTRL_PLC1_FTS_CNT << PCIE_CORE_CTRL_PLC1_FTS_SHIFT);
> -	rockchip_writel(rockchip, status, PCIE_CORE_CTRL_PLC1);
> +	rockchip_writel(rockchip, PCIE_CORE_CTRL_PLC1, status);
>
>  	/* Enable Gen1 training */
> -	rockchip_writel(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
> -			    PCIE_CLIENT_CONFIG);
> +	rockchip_writel(rockchip, PCIE_CLIENT_CONFIG,
> +			PCIE_CLIENT_LINK_TRAIN_ENABLE);
>
>  	gpiod_set_value(rockchip->ep_gpio, 1);
>
> @@ -527,7 +525,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  	 */
>  	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
>  	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
> -	rockchip_writel(rockchip, status, PCIE_RC_CONFIG_LCS);
> +	rockchip_writel(rockchip, PCIE_RC_CONFIG_LCS, status);
>
>  	timeout = jiffies + msecs_to_jiffies(500);
>  	for (;;) {
> @@ -552,20 +550,17 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  			  PCIE_CORE_PL_CONF_LANE_MASK);
>  	dev_dbg(dev, "current link width is x%d\n", status);
>
> -	rockchip_writel(rockchip, ROCKCHIP_VENDOR_ID,
> -			    PCIE_RC_CONFIG_VENDOR);
> -	rockchip_writel(rockchip,
> -			    PCI_CLASS_BRIDGE_PCI << PCIE_RC_CONFIG_SCC_SHIFT,
> -			    PCIE_RC_CONFIG_RID_CCR);
> -	rockchip_writel(rockchip, 0x0, PCIE_RC_BAR_CONF);
> -
> -	rockchip_writel(rockchip,
> -			    (RC_REGION_0_ADDR_TRANS_L + RC_REGION_0_PASS_BITS),
> -			    PCIE_CORE_OB_REGION_ADDR0);
> -	rockchip_writel(rockchip, RC_REGION_0_ADDR_TRANS_H,
> -			    PCIE_CORE_OB_REGION_ADDR1);
> -	rockchip_writel(rockchip, 0x0080000a, PCIE_CORE_OB_REGION_DESC0);
> -	rockchip_writel(rockchip, 0x0, PCIE_CORE_OB_REGION_DESC1);
> +	rockchip_writel(rockchip, PCIE_RC_CONFIG_VENDOR, ROCKCHIP_VENDOR_ID);
> +	rockchip_writel(rockchip, PCIE_RC_CONFIG_RID_CCR,
> +			PCI_CLASS_BRIDGE_PCI << PCIE_RC_CONFIG_SCC_SHIFT);
> +	rockchip_writel(rockchip, PCIE_RC_BAR_CONF, 0);
> +
> +	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_ADDR0,
> +			RC_REGION_0_ADDR_TRANS_L + RC_REGION_0_PASS_BITS);
> +	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_ADDR1,
> +			RC_REGION_0_ADDR_TRANS_H);
> +	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_DESC0, 0x0080000a);
> +	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_DESC1, 0);
>
>  	return 0;
>  }
> @@ -623,15 +618,15 @@ static irqreturn_t rockchip_pcie_subsys_irq_handler(int irq, void *arg)
>  		if (sub_reg & PCIE_CORE_INT_MMVC)
>  			dev_dbg(dev, "MSI mask register changes\n");
>
> -		rockchip_writel(rockchip, sub_reg, PCIE_CORE_INT_STATUS);
> +		rockchip_writel(rockchip, PCIE_CORE_INT_STATUS, sub_reg);
>  	} else if (reg & PCIE_CLIENT_INT_PHY) {
>  		dev_dbg(dev, "phy link changes\n");
>  		rockchip_pcie_update_txcredit_mui(rockchip);
>  		rockchip_pcie_clr_bw_int(rockchip);
>  	}
>
> -	rockchip_writel(rockchip, reg & PCIE_CLIENT_INT_LOCAL,
> -			PCIE_CLIENT_INT_STATUS);
> +	rockchip_writel(rockchip, PCIE_CLIENT_INT_STATUS,
> +			reg & PCIE_CLIENT_INT_LOCAL);
>
>  	return IRQ_HANDLED;
>  }
> @@ -667,13 +662,13 @@ static irqreturn_t rockchip_pcie_client_irq_handler(int irq, void *arg)
>  	if (reg & PCIE_CLIENT_INT_PHY)
>  		dev_dbg(dev, "phy interrupt received\n");
>
> -	rockchip_writel(rockchip, reg & (PCIE_CLIENT_INT_LEGACY_DONE |
> -			      PCIE_CLIENT_INT_MSG | PCIE_CLIENT_INT_HOT_RST |
> -			      PCIE_CLIENT_INT_DPA | PCIE_CLIENT_INT_FATAL_ERR |
> -			      PCIE_CLIENT_INT_NFATAL_ERR |
> -			      PCIE_CLIENT_INT_CORR_ERR |
> -			      PCIE_CLIENT_INT_PHY),
> -		   PCIE_CLIENT_INT_STATUS);
> +	rockchip_writel(rockchip, PCIE_CLIENT_INT_STATUS,
> +			reg & (PCIE_CLIENT_INT_LEGACY_DONE |
> +			       PCIE_CLIENT_INT_MSG | PCIE_CLIENT_INT_HOT_RST |
> +			       PCIE_CLIENT_INT_DPA | PCIE_CLIENT_INT_FATAL_ERR |
> +			       PCIE_CLIENT_INT_NFATAL_ERR |
> +			       PCIE_CLIENT_INT_CORR_ERR |
> +			       PCIE_CLIENT_INT_PHY));
>
>  	return IRQ_HANDLED;
>  }
> @@ -913,10 +908,9 @@ err_out:
>
>  static void rockchip_pcie_enable_interrupts(struct rockchip_pcie *rockchip)
>  {
> -	rockchip_writel(rockchip, (PCIE_CLIENT_INT_CLI << 16) &
> -			    (~PCIE_CLIENT_INT_CLI), PCIE_CLIENT_INT_MASK);
> -	rockchip_writel(rockchip, (u32)(~PCIE_CORE_INT),
> -			    PCIE_CORE_INT_MASK);
> +	rockchip_writel(rockchip, PCIE_CLIENT_INT_MASK,
> +			(PCIE_CLIENT_INT_CLI << 16) & (~PCIE_CLIENT_INT_CLI));
> +	rockchip_writel(rockchip, PCIE_CORE_INT_MASK, (u32)(~PCIE_CORE_INT));
>
>  	rockchip_pcie_enable_bw_int(rockchip);
>  }
> @@ -985,14 +979,13 @@ static int rockchip_pcie_prog_ob_atu(struct rockchip_pcie *rockchip,
>  	ob_addr_1 = upper_addr;
>  	ob_desc_0 = (1 << 23 | type);
>
> -	rockchip_writel(rockchip, ob_addr_0,
> -			    PCIE_CORE_OB_REGION_ADDR0 + aw_offset);
> -	rockchip_writel(rockchip, ob_addr_1,
> -			    PCIE_CORE_OB_REGION_ADDR1 + aw_offset);
> -	rockchip_writel(rockchip, ob_desc_0,
> -			    PCIE_CORE_OB_REGION_DESC0 + aw_offset);
> -	rockchip_writel(rockchip, 0,
> -			    PCIE_CORE_OB_REGION_DESC1 + aw_offset);
> +	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_ADDR0 + aw_offset,
> +			ob_addr_0);
> +	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_ADDR1 + aw_offset,
> +			ob_addr_1);
> +	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_DESC0 + aw_offset,
> +			ob_desc_0);
> +	rockchip_writel(rockchip, PCIE_CORE_OB_REGION_DESC1 + aw_offset, 0);
>
>  	return 0;
>  }
> @@ -1018,8 +1011,8 @@ static int rockchip_pcie_prog_ib_atu(struct rockchip_pcie *rockchip,
>  	ib_addr_0 |= (lower_addr << 8) & PCIE_CORE_IB_REGION_ADDR0_LO_ADDR;
>  	ib_addr_1 = upper_addr;
>
> -	rockchip_writel(rockchip, ib_addr_0, PCIE_RP_IB_ADDR0 + aw_offset);
> -	rockchip_writel(rockchip, ib_addr_1, PCIE_RP_IB_ADDR1 + aw_offset);
> +	rockchip_writel(rockchip, PCIE_RP_IB_ADDR0 + aw_offset, ib_addr_0);
> +	rockchip_writel(rockchip, PCIE_RP_IB_ADDR1 + aw_offset, ib_addr_1);
>
>  	return 0;
>  }
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>


-- 
Best Regards
Shawn Lin



From shawn.lin at rock-chips.com  Fri Oct  7 19:54:11 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sat, 8 Oct 2016 10:54:11 +0800
Subject: [PATCH 3/3] PCI: rockchip: Remove unused platform data
In-Reply-To: <20161007162726.23835.51154.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20161007162706.23835.10081.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <20161007162726.23835.51154.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <70f86886-8ba8-1240-f6f0-4800486a9845@rock-chips.com>

? 2016/10/8 0:27, Bjorn Helgaas ??:
> The rockchip driver never uses the platform drvdata pointer, so don't
> bother setting it.  No functional change intended.
>

Currently it's a build-in driver, so it seems okay to remove
this now.

Acked-by: Shawn Lin <shawn.lin at rock-chips.com>

> Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
> ---
>  drivers/pci/host/pcie-rockchip.c |    4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index 0a89d02..b3548d0 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -1019,8 +1019,8 @@ static int rockchip_pcie_prog_ib_atu(struct rockchip_pcie *rockchip,
>
>  static int rockchip_pcie_probe(struct platform_device *pdev)
>  {
> -	struct rockchip_pcie *rockchip;
>  	struct device *dev = &pdev->dev;
> +	struct rockchip_pcie *rockchip;
>  	struct pci_bus *bus, *child;
>  	struct resource_entry *win;
>  	resource_size_t io_base;
> @@ -1083,8 +1083,6 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
>  	if (err)
>  		goto err_vpcie;
>
> -	platform_set_drvdata(pdev, rockchip);
> -
>  	rockchip_pcie_enable_interrupts(rockchip);
>
>  	err = rockchip_pcie_init_irq_domain(rockchip);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Best Regards
Shawn Lin



From shawn.lin at rock-chips.com  Fri Oct  7 20:01:08 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sat, 8 Oct 2016 11:01:08 +0800
Subject: [PATCH v2 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
In-Reply-To: <2320435.WKGs9crzlB@phil>
References: <cover.1475774981.git.paweljarosz3691@gmail.com>
 <b63a0ad452a487beb1d0c07addb9208cc3b3eeef.1475774981.git.paweljarosz3691@gmail.com>
 <a166a444-8819-ffe7-8ee1-1f632f6a66ab@rock-chips.com>
 <2320435.WKGs9crzlB@phil>
Message-ID: <c5ca69d3-698a-5ef4-623b-204c2a50c28f@rock-chips.com>

? 2016/10/7 18:01, Heiko Stuebner ??:
> Am Freitag, 7. Oktober 2016, 10:29:48 CEST schrieb Shawn Lin:
>> Hi Pawe? ,
>>
>> On 2016/10/7 1:38, Pawe? Jarosz wrote:
>>> MK808 is a tv stick which has rockchip rk3066 CPU inside, two usb ports
>>> - host and otg, micro sd card slot and onboard wifi RK901.
>>>
>>> Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
>>> ---
>>>
>>> Changes in v2:
>>> - included Heiko sugestion.
>>>
>>>  Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
>>>  arch/arm/boot/dts/Makefile                         |   1 +
>>>  arch/arm/boot/dts/rk3066a-mk808.dts                | 184
>>>  +++++++++++++++++++++ 3 files changed, 189 insertions(+)
>>>  create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
>>> b/Documentation/devicetree/bindings/arm/rockchip.txt index
>>> 55f388f..c09595b 100644
>>> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
>>> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
>>> @@ -17,6 +17,10 @@ Rockchip platforms device tree bindings
>>>
>>>      Required root node properties:
>>>        - compatible = "chipspark,rayeager-px2", "rockchip,rk3066a";
>>>
>>> +- Rikomagic MK808 v1 board:
>>> +    Required root node properties:
>>> +      - compatible = "rikomagic,mk808", "rockchip,rk3066a";
>>> +
>>>
>>>  - Radxa Rock board:
>>>      Required root node properties:
>>>        - compatible = "radxa,rock", "rockchip,rk3188";
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index befcd26..f19cc1d 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -639,6 +639,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>>>
>>>  	rk3036-kylin.dtb \
>>>  	rk3066a-bqcurie2.dtb \
>>>  	rk3066a-marsboard.dtb \
>>>
>>> +	rk3066a-mk808.dtb \
>>>
>>>  	rk3066a-rayeager.dtb \
>>>  	rk3188-radxarock.dtb \
>>>  	rk3228-evb.dtb \
>>>
>>> diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts
>>> b/arch/arm/boot/dts/rk3066a-mk808.dts new file mode 100644
>>> index 0000000..2878562
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/rk3066a-mk808.dts
>>> @@ -0,0 +1,184 @@
>>> +/*
>>> + * Copyright (c) 2016 Pawe? Jarosz <paweljarosz3691 at gmail.com>
>>> + *
>>> + * 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 file 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 file 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.
>>> + */
>>> +
>>> +/dts-v1/;
>>> +#include "rk3066a.dtsi"
>>> +
>>> +/ {
>>> +	model = "Rikomagic MK808";
>>> +	compatible = "rikomagic,mk808", "rockchip,rk3066a";
>>> +
>>> +	chosen {
>>> +		stdout-path = "serial2:115200n8";
>>> +	};
>>> +
>>> +	memory at 60000000 {
>>> +		device_type = "memory";
>>> +		reg = <0x60000000 0x40000000>;
>>> +	};
>>> +
>>> +	gpio-leds {
>>> +		compatible = "gpio-leds";
>>> +
>>> +		blue {
>>> +			label = "mk808:blue:power";
>>> +			gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
>>> +			default-state = "off";
>>> +			linux,default-trigger = "default-on";
>>> +		};
>>> +	};
>>> +
>>> +	mmc_pwrseq: mmc-pwrseq {
>>> +		compatible = "mmc-pwrseq-simple";
>>> +		pinctrl-names = "default";
>>> +		pinctrl-0 = <&sdmmc_pwr>;
>>
>> sd slot does not contain a reset pin. So the power pin should be
>> enough. just add sdmmc_pwr to mmc0's pinctrl-0 and let mmc driver
>> control it should be enough. Typically pwrseq is for emmc and sdio.
>> We don't need a pwerseq to control power for sd slot..
>>
>> But it seems sdmmc_pwr is a GPIO, but not functional port.
>> So I am interesting that why MK808 board doesn't use the mmc
>> controller's default power pin but chosing another gpio, so finally
>> we have to add thses code for your DT.
>
> Actually, we always model the sd-mmc pwr-pin as gpio-based regulator (see
> sdmmc-regulator for example in the rk3066a-rayeager.dts), and specifiy this
> regulator as vmmc. That way the mmc core really can control the power.

yes it did. There are two ways for us to control vmmc properly.
If we use gpio-based regulator or PMIC, mmc core take over it
to control the power correctly. But if we use the dafault functional
port, namely SDMMC_PWREN, the dw_mmc driver could handle the control
when doing set_ios.. Both of these two could work fine. But I always
chose the latter one to simplify the dts.

Anyway, I won't insist on it if it looks okay to you. :)

>
>
> Heiko
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>


-- 
Best Regards
Shawn Lin



From heiko at sntech.de  Sat Oct  8 08:24:38 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Sat, 08 Oct 2016 17:24:38 +0200
Subject: [PATCH v2 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
In-Reply-To: <c5ca69d3-698a-5ef4-623b-204c2a50c28f@rock-chips.com>
References: <cover.1475774981.git.paweljarosz3691@gmail.com>
 <2320435.WKGs9crzlB@phil>
 <c5ca69d3-698a-5ef4-623b-204c2a50c28f@rock-chips.com>
Message-ID: <6652929.xB7y1bpV6i@diego>

Am Samstag, 8. Oktober 2016, 11:01:08 schrieb Shawn Lin:
> ? 2016/10/7 18:01, Heiko Stuebner ??:
> > Am Freitag, 7. Oktober 2016, 10:29:48 CEST schrieb Shawn Lin:
> >> Hi Pawe? ,
> >> 
> >> On 2016/10/7 1:38, Pawe? Jarosz wrote:
> >>> MK808 is a tv stick which has rockchip rk3066 CPU inside, two usb ports
> >>> - host and otg, micro sd card slot and onboard wifi RK901.
> >>> 
> >>> Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
> >>> ---
> >>> 
> >>> Changes in v2:
> >>> - included Heiko sugestion.
> >>> 
> >>>  Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
> >>>  arch/arm/boot/dts/Makefile                         |   1 +
> >>>  arch/arm/boot/dts/rk3066a-mk808.dts                | 184
> >>>  +++++++++++++++++++++ 3 files changed, 189 insertions(+)
> >>>  create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts
> >>> 
> >>> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> >>> b/Documentation/devicetree/bindings/arm/rockchip.txt index
> >>> 55f388f..c09595b 100644
> >>> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> >>> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> >>> @@ -17,6 +17,10 @@ Rockchip platforms device tree bindings
> >>> 
> >>>      Required root node properties:
> >>>        - compatible = "chipspark,rayeager-px2", "rockchip,rk3066a";
> >>> 
> >>> +- Rikomagic MK808 v1 board:
> >>> +    Required root node properties:
> >>> +      - compatible = "rikomagic,mk808", "rockchip,rk3066a";
> >>> +
> >>> 
> >>>  - Radxa Rock board:
> >>>      Required root node properties:
> >>>        - compatible = "radxa,rock", "rockchip,rk3188";
> >>> 
> >>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >>> index befcd26..f19cc1d 100644
> >>> --- a/arch/arm/boot/dts/Makefile
> >>> +++ b/arch/arm/boot/dts/Makefile
> >>> @@ -639,6 +639,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> >>> 
> >>>  	rk3036-kylin.dtb \
> >>>  	rk3066a-bqcurie2.dtb \
> >>>  	rk3066a-marsboard.dtb \
> >>> 
> >>> +	rk3066a-mk808.dtb \
> >>> 
> >>>  	rk3066a-rayeager.dtb \
> >>>  	rk3188-radxarock.dtb \
> >>>  	rk3228-evb.dtb \
> >>> 
> >>> diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts
> >>> b/arch/arm/boot/dts/rk3066a-mk808.dts new file mode 100644
> >>> index 0000000..2878562
> >>> --- /dev/null
> >>> +++ b/arch/arm/boot/dts/rk3066a-mk808.dts
> >>> @@ -0,0 +1,184 @@
> >>> +/*
> >>> + * Copyright (c) 2016 Pawe? Jarosz <paweljarosz3691 at gmail.com>
> >>> + *
> >>> + * 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 file 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 file 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.
> >>> + */
> >>> +
> >>> +/dts-v1/;
> >>> +#include "rk3066a.dtsi"
> >>> +
> >>> +/ {
> >>> +	model = "Rikomagic MK808";
> >>> +	compatible = "rikomagic,mk808", "rockchip,rk3066a";
> >>> +
> >>> +	chosen {
> >>> +		stdout-path = "serial2:115200n8";
> >>> +	};
> >>> +
> >>> +	memory at 60000000 {
> >>> +		device_type = "memory";
> >>> +		reg = <0x60000000 0x40000000>;
> >>> +	};
> >>> +
> >>> +	gpio-leds {
> >>> +		compatible = "gpio-leds";
> >>> +
> >>> +		blue {
> >>> +			label = "mk808:blue:power";
> >>> +			gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
> >>> +			default-state = "off";
> >>> +			linux,default-trigger = "default-on";
> >>> +		};
> >>> +	};
> >>> +
> >>> +	mmc_pwrseq: mmc-pwrseq {
> >>> +		compatible = "mmc-pwrseq-simple";
> >>> +		pinctrl-names = "default";
> >>> +		pinctrl-0 = <&sdmmc_pwr>;
> >> 
> >> sd slot does not contain a reset pin. So the power pin should be
> >> enough. just add sdmmc_pwr to mmc0's pinctrl-0 and let mmc driver
> >> control it should be enough. Typically pwrseq is for emmc and sdio.
> >> We don't need a pwerseq to control power for sd slot..
> >> 
> >> But it seems sdmmc_pwr is a GPIO, but not functional port.
> >> So I am interesting that why MK808 board doesn't use the mmc
> >> controller's default power pin but chosing another gpio, so finally
> >> we have to add thses code for your DT.
> > 
> > Actually, we always model the sd-mmc pwr-pin as gpio-based regulator (see
> > sdmmc-regulator for example in the rk3066a-rayeager.dts), and specifiy
> > this
> > regulator as vmmc. That way the mmc core really can control the power.
> 
> yes it did. There are two ways for us to control vmmc properly.
> If we use gpio-based regulator or PMIC, mmc core take over it
> to control the power correctly. But if we use the dafault functional
> port, namely SDMMC_PWREN, the dw_mmc driver could handle the control
> when doing set_ios.. Both of these two could work fine. But I always
> chose the latter one to simplify the dts.
> 
> Anyway, I won't insist on it if it looks okay to you. :)

yes, I'd really prefer the mmc subsystem explicitly controlling the cards 
power via a regulator :-) .


Heiko


From paweljarosz3691 at gmail.com  Sat Oct  8 13:21:47 2016
From: paweljarosz3691 at gmail.com (=?utf-8?B?UGF3ZcWC?= Jarosz)
Date: Sat, 8 Oct 2016 22:21:47 +0200
Subject: [PATCH v3 0/2] Add MK808 RK3066 device
Message-ID: <cover.1475957884.git.paweljarosz3691@gmail.com>

Add MK808 RK3066 device

This patchset adds support for Rikomagic MK808 v1 device with RK901 wifi.

It is hdmi stick with two usb ports(host and otg), sdmmc, wifi and uart
onboard.

It is RK3066 based.

Pawe? Jarosz (2):
  devicetree: Add vendor prefix for Rikomagic
  ARM: dts: rockchip: Add rk3066 MK808 board

 Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/rk3066a-mk808.dts                | 196 +++++++++++++++++++++
 4 files changed, 202 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts

-- 
2.7.4



From paweljarosz3691 at gmail.com  Sat Oct  8 13:22:05 2016
From: paweljarosz3691 at gmail.com (=?utf-8?B?UGF3ZcWC?= Jarosz)
Date: Sat, 8 Oct 2016 22:22:05 +0200
Subject: [PATCH v3 1/2] devicetree: Add vendor prefix for Rikomagic
In-Reply-To: <cover.1475957884.git.paweljarosz3691@gmail.com>
References: <cover.1475957884.git.paweljarosz3691@gmail.com>
Message-ID: <d51c7719a314f723a0a69b932997502a2fe0e3ee.1475957884.git.paweljarosz3691@gmail.com>

Add Rikomagic to vendor-prefixes.txt

Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
---

Changes in v2:
- none

Changes in v3:
- none

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 69caf14..3edfa08 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -224,6 +224,7 @@ realtek Realtek Semiconductor Corp.
 renesas	Renesas Electronics Corporation
 richtek	Richtek Technology Corporation
 ricoh	Ricoh Co. Ltd.
+rikomagic	Rikomagic
 rockchip	Fuzhou Rockchip Electronics Co., Ltd
 samsung	Samsung Semiconductor
 sandisk	Sandisk Corporation
-- 
2.7.4



From paweljarosz3691 at gmail.com  Sat Oct  8 13:22:30 2016
From: paweljarosz3691 at gmail.com (=?utf-8?B?UGF3ZcWC?= Jarosz)
Date: Sat, 8 Oct 2016 22:22:30 +0200
Subject: [PATCH v3 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
In-Reply-To: <cover.1475957884.git.paweljarosz3691@gmail.com>
References: <cover.1475957884.git.paweljarosz3691@gmail.com>
Message-ID: <876234f84363b4a83c566137866cd823528ed07a.1475957884.git.paweljarosz3691@gmail.com>

MK808 is a tv stick which has rockchip rk3066 CPU inside, two usb ports
- host and otg, micro sd card slot and onboard wifi RK901.

Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
---

Changes in v2:
- included Heiko sugestion.

Changes in v3:
- added regulators for mmc0 and mmc1
- added proper pincontrol for mmc1
- removed regulator-always-on flag from vcc_io

 Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/rk3066a-mk808.dts                | 196 +++++++++++++++++++++
 3 files changed, 201 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index 55f388f..c09595b 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -17,6 +17,10 @@ Rockchip platforms device tree bindings
     Required root node properties:
       - compatible = "chipspark,rayeager-px2", "rockchip,rk3066a";
 
+- Rikomagic MK808 v1 board:
+    Required root node properties:
+      - compatible = "rikomagic,mk808", "rockchip,rk3066a";
+
 - Radxa Rock board:
     Required root node properties:
       - compatible = "radxa,rock", "rockchip,rk3188";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..f19cc1d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -639,6 +639,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3036-kylin.dtb \
 	rk3066a-bqcurie2.dtb \
 	rk3066a-marsboard.dtb \
+	rk3066a-mk808.dtb \
 	rk3066a-rayeager.dtb \
 	rk3188-radxarock.dtb \
 	rk3228-evb.dtb \
diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts b/arch/arm/boot/dts/rk3066a-mk808.dts
new file mode 100644
index 0000000..0123fa4
--- /dev/null
+++ b/arch/arm/boot/dts/rk3066a-mk808.dts
@@ -0,0 +1,196 @@
+/*
+ * Copyright (c) 2016 Pawe? Jarosz <paweljarosz3691 at gmail.com>
+ *
+ * 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 file 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 file 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.
+ */
+
+/dts-v1/;
+#include "rk3066a.dtsi"
+
+/ {
+	model = "Rikomagic MK808";
+	compatible = "rikomagic,mk808", "rockchip,rk3066a";
+
+	chosen {
+		stdout-path = "serial2:115200n8";
+	};
+
+	memory at 60000000 {
+		device_type = "memory";
+		reg = <0x60000000 0x40000000>;
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		blue {
+			label = "mk808:blue:power";
+			gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
+			default-state = "off";
+			linux,default-trigger = "default-on";
+		};
+	};
+
+	vcc_io: vcc-io {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_io";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
+
+	vcc_host: usb-host-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio0 6 GPIO_ACTIVE_HIGH>;
+		pinctrl-0 = <&host_drv>;
+		pinctrl-names = "default";
+		regulator-always-on;
+		regulator-name = "host-pwr";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		startup-delay-us = <100000>;
+		vin-supply = <&vcc_io>;
+	};
+
+	vcc_otg: usb-otg-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio0 5 GPIO_ACTIVE_HIGH>;
+		pinctrl-0 = <&otg_drv>;
+		pinctrl-names = "default";
+		regulator-always-on;
+		regulator-name = "vcc_otg";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		startup-delay-us = <100000>;
+		vin-supply = <&vcc_io>;
+	};
+
+	vcc_sd: sdmmc-regulator {
+		compatible = "regulator-fixed";
+		gpio = <&gpio3 7 GPIO_ACTIVE_LOW>;
+		pinctrl-0 = <&sdmmc_pwr>;
+		pinctrl-names = "default";
+		regulator-name = "vcc_sd";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		startup-delay-us = <100000>;
+		vin-supply = <&vcc_io>;
+	};
+
+	vcc_wifi: sdio-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio3 24 GPIO_ACTIVE_HIGH>;
+		pinctrl-0 = <&wifi_pwr>;
+		pinctrl-names = "default";
+		regulator-name = "vcc_wifi";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		startup-delay-us = <100000>;
+		vin-supply = <&vcc_io>;
+	};
+};
+
+&mmc0 {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	num-slots = <1>;
+	status = "okay";
+	vmmc-supply = <&vcc_sd>;
+};
+
+&mmc1 {
+	bus-width = <4>;
+	disable-wp;
+	non-removable;
+	num-slots = <1>;
+	pinctrl-0 = <&sd1_clk &sd1_cmd &sd1_bus4>;
+	pinctrl-names = "default";
+	status = "okay";
+	vmmc-supply = <&vcc_wifi>;
+};
+
+&pinctrl {
+	usb-host {
+		host_drv: host-drv {
+			rockchip,pins = <RK_GPIO0 6 RK_FUNC_GPIO &pcfg_pull_default>;
+		};
+	};
+
+	usb-otg {
+		otg_drv: otg-drv {
+			rockchip,pins = <RK_GPIO0 5 RK_FUNC_GPIO &pcfg_pull_default>;
+		};
+	};
+
+	sdmmc {
+		sdmmc_pwr: sdmmc-pwr {
+			rockchip,pins = <RK_GPIO3 7 RK_FUNC_GPIO &pcfg_pull_default>;
+		};
+	};
+
+	sdio {
+		wifi_pwr: wifi-pwr {
+			rockchip,pins = <RK_GPIO3 24 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usb_host {
+	status = "okay";
+};
+
+&usb_otg {
+	status = "okay";
+};
+
+&usbphy {
+	status = "okay";
+};
+
+&wdt {
+	status = "okay";
+};
+
-- 
2.7.4



From arthur.byers at sayohomme.com  Sun Oct  9 04:55:07 2016
From: arthur.byers at sayohomme.com (FedEx Ground)
Date: Sun, 9 Oct 2016 20:55:07 +0900
Subject: ROCK, Problem with parcel shipping, ID:000958254
Message-ID: <4e3db75bea0b0450f48e60eeb8e75843@sayohomme.com>

Dear Rock,

We could not deliver your parcel.
Please, download Delivery Label attached to this email.

Sincerely,
Arthur Byers,
Sr. Station Manager.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Delivery_Notification_000958254.zip
Type: application/zip
Size: 12310 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20161009/58347a1b/attachment-0001.zip>

From shawn.lin at rock-chips.com  Sun Oct  9 05:49:18 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 20:49:18 +0800
Subject: [PATCH] thermal: rockchip: improve the warning log
Message-ID: <1476017358-26143-1-git-send-email-shawn.lin@rock-chips.com>

There is no necessary to print warning agian and
again if we don't add rockchip,grf for dt, otherwise
I saw the following log when doning suspend-2-resume.
We only need to print it once when parsing dt. It looks
quite trivial but the log is apparently verbose.

[   26.615415] PM: early resume of devices complete after 1.539 msecs
[   26.622002] rk_tsadcv2_initialize: Missing rockchip,grf property
[   26.629359] rk_gmac-dwmac ff290000.ethernet: init for RGMII
[   26.639794] PM: resume of devices complete after 18.109 msecs
[   26.646925] Restarting tasks ... done.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/thermal/rockchip_thermal.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c
index e227a9f..b811b0f 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -524,11 +524,6 @@ static void rk_tsadcv2_initialize(struct regmap *grf, void __iomem *regs,
 		       regs + TSADCV2_AUTO_PERIOD_HT);
 	writel_relaxed(TSADCV2_HIGHT_TSHUT_DEBOUNCE_COUNT,
 		       regs + TSADCV2_HIGHT_TSHUT_DEBOUNCE);
-
-	if (IS_ERR(grf)) {
-		pr_warn("%s: Missing rockchip,grf property\n", __func__);
-		return;
-	}
 }
 
 /**
@@ -971,6 +966,8 @@ static int rockchip_configure_from_dt(struct device *dev,
 	 * need this property.
 	 */
 	thermal->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+	if (IS_ERR(thermal->grf))
+		dev_warn(dev, "Missing rockchip,grf property\n");
 
 	return 0;
 }
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 06:38:28 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun, 9 Oct 2016 21:38:28 +0800
Subject: [PATCH v3 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
In-Reply-To: <876234f84363b4a83c566137866cd823528ed07a.1475957884.git.paweljarosz3691@gmail.com>
References: <cover.1475957884.git.paweljarosz3691@gmail.com>
 <876234f84363b4a83c566137866cd823528ed07a.1475957884.git.paweljarosz3691@gmail.com>
Message-ID: <6926c482-e9c1-6cd0-fb2c-b7a10f5ee963@rock-chips.com>

? 2016/10/9 4:22, Pawe? Jarosz ??:
> MK808 is a tv stick which has rockchip rk3066 CPU inside, two usb ports
> - host and otg, micro sd card slot and onboard wifi RK901.
>
> Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>

It looks okay to me, so feel free to add

Reviewed-by: Shawn Lin <shawn.lin at rock-chip.com>

> ---
>
> Changes in v2:
> - included Heiko sugestion.
>
> Changes in v3:
> - added regulators for mmc0 and mmc1
> - added proper pincontrol for mmc1
> - removed regulator-always-on flag from vcc_io
>
>  Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
>  arch/arm/boot/dts/Makefile                         |   1 +
>  arch/arm/boot/dts/rk3066a-mk808.dts                | 196 +++++++++++++++++++++
>  3 files changed, 201 insertions(+)
>  create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
> index 55f388f..c09595b 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -17,6 +17,10 @@ Rockchip platforms device tree bindings
>      Required root node properties:
>        - compatible = "chipspark,rayeager-px2", "rockchip,rk3066a";
>
> +- Rikomagic MK808 v1 board:
> +    Required root node properties:
> +      - compatible = "rikomagic,mk808", "rockchip,rk3066a";
> +
>  - Radxa Rock board:
>      Required root node properties:
>        - compatible = "radxa,rock", "rockchip,rk3188";
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..f19cc1d 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -639,6 +639,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>  	rk3036-kylin.dtb \
>  	rk3066a-bqcurie2.dtb \
>  	rk3066a-marsboard.dtb \
> +	rk3066a-mk808.dtb \
>  	rk3066a-rayeager.dtb \
>  	rk3188-radxarock.dtb \
>  	rk3228-evb.dtb \
> diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts b/arch/arm/boot/dts/rk3066a-mk808.dts
> new file mode 100644
> index 0000000..0123fa4
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk3066a-mk808.dts
> @@ -0,0 +1,196 @@
> +/*
> + * Copyright (c) 2016 Pawe? Jarosz <paweljarosz3691 at gmail.com>
> + *
> + * 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 file 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 file 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.
> + */
> +
> +/dts-v1/;
> +#include "rk3066a.dtsi"
> +
> +/ {
> +	model = "Rikomagic MK808";
> +	compatible = "rikomagic,mk808", "rockchip,rk3066a";
> +
> +	chosen {
> +		stdout-path = "serial2:115200n8";
> +	};
> +
> +	memory at 60000000 {
> +		device_type = "memory";
> +		reg = <0x60000000 0x40000000>;
> +	};
> +
> +	gpio-leds {
> +		compatible = "gpio-leds";
> +
> +		blue {
> +			label = "mk808:blue:power";
> +			gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
> +			default-state = "off";
> +			linux,default-trigger = "default-on";
> +		};
> +	};
> +
> +	vcc_io: vcc-io {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_io";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +	};
> +
> +	vcc_host: usb-host-regulator {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio0 6 GPIO_ACTIVE_HIGH>;
> +		pinctrl-0 = <&host_drv>;
> +		pinctrl-names = "default";
> +		regulator-always-on;
> +		regulator-name = "host-pwr";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		startup-delay-us = <100000>;
> +		vin-supply = <&vcc_io>;
> +	};
> +
> +	vcc_otg: usb-otg-regulator {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio0 5 GPIO_ACTIVE_HIGH>;
> +		pinctrl-0 = <&otg_drv>;
> +		pinctrl-names = "default";
> +		regulator-always-on;
> +		regulator-name = "vcc_otg";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		startup-delay-us = <100000>;
> +		vin-supply = <&vcc_io>;
> +	};
> +
> +	vcc_sd: sdmmc-regulator {
> +		compatible = "regulator-fixed";
> +		gpio = <&gpio3 7 GPIO_ACTIVE_LOW>;
> +		pinctrl-0 = <&sdmmc_pwr>;
> +		pinctrl-names = "default";
> +		regulator-name = "vcc_sd";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		startup-delay-us = <100000>;
> +		vin-supply = <&vcc_io>;
> +	};
> +
> +	vcc_wifi: sdio-regulator {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio3 24 GPIO_ACTIVE_HIGH>;
> +		pinctrl-0 = <&wifi_pwr>;
> +		pinctrl-names = "default";
> +		regulator-name = "vcc_wifi";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		startup-delay-us = <100000>;
> +		vin-supply = <&vcc_io>;
> +	};
> +};
> +
> +&mmc0 {
> +	bus-width = <4>;
> +	cap-mmc-highspeed;
> +	cap-sd-highspeed;
> +	num-slots = <1>;
> +	status = "okay";
> +	vmmc-supply = <&vcc_sd>;
> +};
> +
> +&mmc1 {
> +	bus-width = <4>;
> +	disable-wp;
> +	non-removable;
> +	num-slots = <1>;
> +	pinctrl-0 = <&sd1_clk &sd1_cmd &sd1_bus4>;
> +	pinctrl-names = "default";
> +	status = "okay";
> +	vmmc-supply = <&vcc_wifi>;
> +};
> +
> +&pinctrl {
> +	usb-host {
> +		host_drv: host-drv {
> +			rockchip,pins = <RK_GPIO0 6 RK_FUNC_GPIO &pcfg_pull_default>;
> +		};
> +	};
> +
> +	usb-otg {
> +		otg_drv: otg-drv {
> +			rockchip,pins = <RK_GPIO0 5 RK_FUNC_GPIO &pcfg_pull_default>;
> +		};
> +	};
> +
> +	sdmmc {
> +		sdmmc_pwr: sdmmc-pwr {
> +			rockchip,pins = <RK_GPIO3 7 RK_FUNC_GPIO &pcfg_pull_default>;
> +		};
> +	};
> +
> +	sdio {
> +		wifi_pwr: wifi-pwr {
> +			rockchip,pins = <RK_GPIO3 24 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +};
> +
> +&uart2 {
> +	status = "okay";
> +};
> +
> +&usb_host {
> +	status = "okay";
> +};
> +
> +&usb_otg {
> +	status = "okay";
> +};
> +
> +&usbphy {
> +	status = "okay";
> +};
> +
> +&wdt {
> +	status = "okay";
> +};
> +
>


-- 
Best Regards
Shawn Lin



From shawn.lin at rock-chips.com  Sun Oct  9 06:41:38 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun, 9 Oct 2016 21:41:38 +0800
Subject: [PATCH] ARM: dts: rockchip: remove always-on and boot-on from
 vcc_sd for px3-evb
In-Reply-To: <1474589350-10877-1-git-send-email-shawn.lin@rock-chips.com>
References: <1474589350-10877-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <96174d9b-4960-551a-9844-8c0069da6de0@rock-chips.com>

Hi Heiko,

Friendly ping..

? 2016/9/23 8:09, Shawn Lin ??:
> Please don't add these for vcc_sd, and mmc-core/driver will control
> it. Otherwise, it will waste energy even without sdmmc in slot.
>
> Moreover, it will causes a bug:
> If we insert/remove sd card, we could see
> [9.337271] mmc0: new ultra high speed SDR25 SDHC card at address 0007
> [9.345144] mmcblk0: mmc0:0007 SD32G 29.3 GiB
>
> This is okay for normal sd insert/remove test, but when I debug some
> issues for sdmmc, I did unbind/bind test. And there is a interesting
> phenomenon when we bind the driver again:
> [58.314069] mmc0: new high speed SDHC card at address 0007
> [58.320282] mmcblk0: mmc0:0007 SD32G 29.3 GiB
>
> So the sd card could just support high speed without power cycle
> since the vcc_sd is always on, which makes the sd card fail to
> reinit its internal ocr mask.
>
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> ---
>
>  arch/arm/boot/dts/rk3188-px3-evb.dts | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/rk3188-px3-evb.dts b/arch/arm/boot/dts/rk3188-px3-evb.dts
> index c1e41b8..62cbdd5 100644
> --- a/arch/arm/boot/dts/rk3188-px3-evb.dts
> +++ b/arch/arm/boot/dts/rk3188-px3-evb.dts
> @@ -219,8 +219,6 @@
>  			};
>
>  			vcc_sd: LDO_REG7 {
> -				regulator-always-on;
> -				regulator-boot-on;
>  				regulator-min-microvolt = <1800000>;
>  				regulator-max-microvolt = <3300000>;
>  				regulator-name = "vcc_sd";
>


-- 
Best Regards
Shawn Lin



From shawn.lin at rock-chips.com  Sun Oct  9 06:42:07 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun, 9 Oct 2016 21:42:07 +0800
Subject: [PATCH 3/3] arm64: dts: rockchip: remove always-on and boot-on
 from vcc_sd
In-Reply-To: <1474516939-22001-3-git-send-email-shawn.lin@rock-chips.com>
References: <1474516939-22001-1-git-send-email-shawn.lin@rock-chips.com>
 <1474516939-22001-3-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <bfb38696-9e11-e75f-b169-6df41d594b37@rock-chips.com>

Hi Heiko,

Ping... :)

? 2016/9/22 12:02, Shawn Lin ??:
> Please don't add these for vcc_sd, and mmc-core/driver will control
> it. Otherwise, it will waste energy even without sdmmc in slot.
>
> Moreover, it will causes a bug:
> If we insert/remove sd card, we could see
> [9.337271] mmc0: new ultra high speed SDR25 SDHC card at address 0007
> [9.345144] mmcblk0: mmc0:0007 SD32G 29.3 GiB
>
> This is okay for normal sd insert/remove test, but when I debug some
> issues for sdmmc, I did unbind/bind test. And there is a interesting
> phenomenon when we bind the driver again:
> [58.314069] mmc0: new high speed SDHC card at address 0007
> [58.320282] mmcblk0: mmc0:0007 SD32G 29.3 GiB
>
> So the sd card could just support high speed without power cycle
> since the vcc_sd is always on, which makes the sd card fail to
> reinit its internal ocr mask.
>
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> ---
>
>  arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts        | 2 --
>  arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts | 2 --
>  arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts        | 2 --
>  3 files changed, 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
> index 46cdddf..353314c 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
> @@ -258,8 +258,6 @@
>  			};
>
>  			vcc_sd: SWITCH_REG1 {
> -				regulator-always-on;
> -				regulator-boot-on;
>  				regulator-name = "vcc_sd";
>  			};
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts b/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
> index 5797933..13b7f1ed 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
> @@ -152,8 +152,6 @@
>  		gpio = <&gpio3 11 GPIO_ACTIVE_LOW>;
>  		regulator-min-microvolt = <1800000>;
>  		regulator-max-microvolt = <3300000>;
> -		regulator-always-on;
> -		regulator-boot-on;
>  		vin-supply = <&vcc_io>;
>  	};
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts b/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
> index f59049b..8c47b01 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
> @@ -236,8 +236,6 @@
>  			};
>
>  			vcc_sd: SWITCH_REG1 {
> -				regulator-always-on;
> -				regulator-boot-on;
>  				regulator-name = "vcc_sd";
>  			};
>
>


-- 
Best Regards
Shawn Lin



From shawn.lin at rock-chips.com  Sun Oct  9 06:49:02 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 21:49:02 +0800
Subject: [PATCH 1/9] mmc: dw_mmc: add runtime PM callback
Message-ID: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>

This patch add dw_mci_runtime_suspend/resume interfaces
and expose it to dw_mci variant driver to support runtime
PM.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

 drivers/mmc/host/dw_mmc.c | 30 ++++++++++++++++++++++++++++--
 drivers/mmc/host/dw_mmc.h |  4 +++-
 2 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 4fcbc40..c5ef263 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3266,7 +3266,7 @@ EXPORT_SYMBOL(dw_mci_remove);
 
 
 
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
 /*
  * TODO: we should probably disable the clock to the card in the suspend path.
  */
@@ -3324,7 +3324,33 @@ int dw_mci_resume(struct dw_mci *host)
 	return 0;
 }
 EXPORT_SYMBOL(dw_mci_resume);
-#endif /* CONFIG_PM_SLEEP */
+
+int dw_mci_runtime_suspend(struct dw_mci *host)
+{
+	int err = 0;
+
+	err = dw_mci_suspend(host);
+	if (err)
+		return err;
+
+	clk_disable_unprepare(host->ciu_clk);
+
+	return err;
+}
+EXPORT_SYMBOL(dw_mci_runtime_suspend);
+
+int dw_mci_runtime_resume(struct dw_mci *host)
+{
+	int ret = 0;
+
+	ret = clk_prepare_enable(host->ciu_clk);
+	if (ret)
+		return ret;
+
+	return dw_mci_resume(host);
+}
+EXPORT_SYMBOL(dw_mci_runtime_resume);
+#endif /* CONFIG_PM */
 
 static int __init dw_mci_init(void)
 {
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index e8cd2de..baa7261 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -234,9 +234,11 @@
 
 extern int dw_mci_probe(struct dw_mci *host);
 extern void dw_mci_remove(struct dw_mci *host);
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
 extern int dw_mci_suspend(struct dw_mci *host);
 extern int dw_mci_resume(struct dw_mci *host);
+extern int dw_mci_runtime_suspend(struct dw_mci *host);
+extern int dw_mci_runtime_resume(struct dw_mci *host);
 #endif
 
 /**
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 06:49:04 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 21:49:04 +0800
Subject: [PATCH 3/9] mmc: core: expose the capability of gpio card detect
In-Reply-To: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476020951-31292-3-git-send-email-shawn.lin@rock-chips.com>

Add new helper API mmc_can_gpio_cd for slot-gpio to make
host drivers know whether it supports gpio card detect.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/core/slot-gpio.c  | 8 ++++++++
 include/linux/mmc/slot-gpio.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index 27117ba..babe591 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -258,6 +258,14 @@ int mmc_gpiod_request_cd(struct mmc_host *host, const char *con_id,
 }
 EXPORT_SYMBOL(mmc_gpiod_request_cd);
 
+bool mmc_can_gpio_cd(struct mmc_host *host)
+{
+	struct mmc_gpio *ctx = host->slot.handler_priv;
+
+	return ctx->cd_gpio ? true : false;
+}
+EXPORT_SYMBOL(mmc_can_gpio_cd);
+
 /**
  * mmc_gpiod_request_ro - request a gpio descriptor for write protection
  * @host: mmc host
diff --git a/include/linux/mmc/slot-gpio.h b/include/linux/mmc/slot-gpio.h
index 3945a8c..a7972cd 100644
--- a/include/linux/mmc/slot-gpio.h
+++ b/include/linux/mmc/slot-gpio.h
@@ -29,5 +29,6 @@ int mmc_gpiod_request_ro(struct mmc_host *host, const char *con_id,
 void mmc_gpio_set_cd_isr(struct mmc_host *host,
 			 irqreturn_t (*isr)(int irq, void *dev_id));
 void mmc_gpiod_request_cd_irq(struct mmc_host *host);
+bool mmc_can_gpio_cd(struct mmc_host *host);
 
 #endif
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 06:49:03 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 21:49:03 +0800
Subject: [PATCH 2/9] mmc: dw_mmc-rockchip: add runtime PM support
In-Reply-To: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476020951-31292-2-git-send-email-shawn.lin@rock-chips.com>

This patch adds runtime PM support for dw_mmc-rockchip.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/host/dw_mmc-rockchip.c | 57 ++++++++++++++++++++++++++++++++++++--
 1 file changed, 54 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
index 25eae35..28e0220 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -13,6 +13,7 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/dw_mmc.h>
 #include <linux/of_address.h>
+#include <linux/pm_runtime.h>
 #include <linux/slab.h>
 
 #include "dw_mmc.h"
@@ -325,6 +326,7 @@ static int dw_mci_rockchip_probe(struct platform_device *pdev)
 {
 	const struct dw_mci_drv_data *drv_data;
 	const struct of_device_id *match;
+	int ret;
 
 	if (!pdev->dev.of_node)
 		return -ENODEV;
@@ -332,16 +334,65 @@ static int dw_mci_rockchip_probe(struct platform_device *pdev)
 	match = of_match_node(dw_mci_rockchip_match, pdev->dev.of_node);
 	drv_data = match->data;
 
-	return dw_mci_pltfm_register(pdev, drv_data);
+	pm_runtime_get_noresume(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
+	pm_runtime_use_autosuspend(&pdev->dev);
+
+	ret = dw_mci_pltfm_register(pdev, drv_data);
+	if (ret) {
+		pm_runtime_disable(&pdev->dev);
+		pm_runtime_set_suspended(&pdev->dev);
+		pm_runtime_put_noidle(&pdev->dev);
+		return ret;
+	}
+
+	pm_runtime_put_autosuspend(&pdev->dev);
+
+	return 0;
+}
+
+static int dw_mci_rockchip_remove(struct platform_device *pdev)
+{
+	pm_runtime_get_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+	pm_runtime_put_noidle(&pdev->dev);
+
+	return dw_mci_pltfm_remove(pdev);
 }
 
+#ifdef CONFIG_PM
+static int dw_mci_rockchip_runtime_suspend(struct device *dev)
+{
+	struct dw_mci *host = dev_get_drvdata(dev);
+
+	return dw_mci_runtime_suspend(host);
+}
+
+static int dw_mci_rockchip_runtime_resume(struct device *dev)
+{
+	struct dw_mci *host = dev_get_drvdata(dev);
+
+	return dw_mci_runtime_resume(host);
+}
+#endif /* CONFIG_PM */
+
+static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_rockchip_runtime_suspend,
+			   dw_mci_rockchip_runtime_resume,
+			   NULL)
+};
+
 static struct platform_driver dw_mci_rockchip_pltfm_driver = {
 	.probe		= dw_mci_rockchip_probe,
-	.remove		= dw_mci_pltfm_remove,
+	.remove		= dw_mci_rockchip_remove,
 	.driver		= {
 		.name		= "dwmmc_rockchip",
 		.of_match_table	= dw_mci_rockchip_match,
-		.pm		= &dw_mci_pltfm_pmops,
+		.pm		= &dw_mci_rockchip_dev_pm_ops,
 	},
 };
 
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 06:49:05 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 21:49:05 +0800
Subject: [PATCH 4/9] mmc: dw_mmc-rockchip: disable biu clk if possible
In-Reply-To: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476020951-31292-4-git-send-email-shawn.lin@rock-chips.com>

We could disable biu clk and power-off genpd if gpio
card detect available.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/host/dw_mmc-rockchip.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
index 28e0220..7528720 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -13,6 +13,7 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/dw_mmc.h>
 #include <linux/of_address.h>
+#include <linux/mmc/slot-gpio.h>
 #include <linux/pm_runtime.h>
 #include <linux/slab.h>
 
@@ -366,14 +367,29 @@ static int dw_mci_rockchip_remove(struct platform_device *pdev)
 static int dw_mci_rockchip_runtime_suspend(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
+	int ret;
+
+	ret = dw_mci_runtime_suspend(host);
+	if (ret)
+		return ret;
 
-	return dw_mci_runtime_suspend(host);
+	if (host->cur_slot &&
+	    (mmc_can_gpio_cd(host->cur_slot->mmc) ||
+	     !mmc_card_is_removable(host->cur_slot->mmc)))
+		clk_disable_unprepare(host->biu_clk);
+
+	return 0;
 }
 
 static int dw_mci_rockchip_runtime_resume(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
 
+	if (host->cur_slot &&
+	    (mmc_can_gpio_cd(host->cur_slot->mmc) ||
+	     !mmc_card_is_removable(host->cur_slot->mmc)))
+		clk_prepare_enable(host->biu_clk);
+
 	return dw_mci_runtime_resume(host);
 }
 #endif /* CONFIG_PM */
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 06:49:06 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 21:49:06 +0800
Subject: [PATCH 5/9] mmc: dw_mmc-k3: deploay runtime PM facilities
In-Reply-To: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476020951-31292-5-git-send-email-shawn.lin@rock-chips.com>

Let's migrate it to use runtime PM and remove the system
PM callback from this driver. With this patch, it could
handle system PM properly and could also use runtime PM
if we enable it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/host/dw_mmc-k3.c | 37 ++++++++++++++++---------------------
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c
index 6247894..99b859d 100644
--- a/drivers/mmc/host/dw_mmc-k3.c
+++ b/drivers/mmc/host/dw_mmc-k3.c
@@ -15,6 +15,7 @@
 #include <linux/module.h>
 #include <linux/of_address.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 
@@ -162,35 +163,29 @@ static int dw_mci_k3_probe(struct platform_device *pdev)
 	return dw_mci_pltfm_register(pdev, drv_data);
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int dw_mci_k3_suspend(struct device *dev)
+#ifdef CONFIG_PM
+static int dw_mci_k3_runtime_suspend(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
-	int ret;
-
-	ret = dw_mci_suspend(host);
-	if (!ret)
-		clk_disable_unprepare(host->ciu_clk);
 
-	return ret;
+	return dw_mci_runtime_suspend(host);
 }
 
-static int dw_mci_k3_resume(struct device *dev)
+static int dw_mci_k3_runtime_resume(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
-	int ret;
 
-	ret = clk_prepare_enable(host->ciu_clk);
-	if (ret) {
-		dev_err(host->dev, "failed to enable ciu clock\n");
-		return ret;
-	}
-
-	return dw_mci_resume(host);
+	return dw_mci_runtime_resume(host);
 }
-#endif /* CONFIG_PM_SLEEP */
-
-static SIMPLE_DEV_PM_OPS(dw_mci_k3_pmops, dw_mci_k3_suspend, dw_mci_k3_resume);
+#endif /* CONFIG_PM */
+
+static const struct dev_pm_ops dw_mci_k3_dev_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_k3_runtime_suspend,
+			   dw_mci_k3_runtime_resume,
+			   NULL)
+};
 
 static struct platform_driver dw_mci_k3_pltfm_driver = {
 	.probe		= dw_mci_k3_probe,
@@ -198,7 +193,7 @@ static struct platform_driver dw_mci_k3_pltfm_driver = {
 	.driver		= {
 		.name		= "dwmmc_k3",
 		.of_match_table	= dw_mci_k3_match,
-		.pm		= &dw_mci_k3_pmops,
+		.pm		= &dw_mci_k3_dev_pm_ops,
 	},
 };
 
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 06:50:52 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 21:50:52 +0800
Subject: [PATCH 7/9] mmc: dw_mmc-pci: deploay runtime PM facilities
In-Reply-To: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476021052-31395-1-git-send-email-shawn.lin@rock-chips.com>

Let's migrate it to use runtime PM and remove the system
PM callback from this driver. With this patch, it could
handle system PM properly and could also use runtime PM
if we enable it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/host/dw_mmc-pci.c | 25 ++++++++++++++++---------
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-pci.c b/drivers/mmc/host/dw_mmc-pci.c
index 4c69fbd..61789b1 100644
--- a/drivers/mmc/host/dw_mmc-pci.c
+++ b/drivers/mmc/host/dw_mmc-pci.c
@@ -14,6 +14,7 @@
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/pci.h>
+#include <linux/pm_runtime.h>
 #include <linux/slab.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/mmc.h>
@@ -79,25 +80,31 @@ static void dw_mci_pci_remove(struct pci_dev *pdev)
 	dw_mci_remove(host);
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int dw_mci_pci_suspend(struct device *dev)
+#ifdef CONFIG_PM
+static int dw_mci_pci_runtime_suspend(struct device *dev)
 {
 	struct pci_dev *pdev = to_pci_dev(dev);
 	struct dw_mci *host = pci_get_drvdata(pdev);
 
-	return dw_mci_suspend(host);
+	return dw_mci_runtime_suspend(host);
 }
 
-static int dw_mci_pci_resume(struct device *dev)
+static int dw_mci_pci_runtime_resume(struct device *dev)
 {
 	struct pci_dev *pdev = to_pci_dev(dev);
 	struct dw_mci *host = pci_get_drvdata(pdev);
 
-	return dw_mci_resume(host);
+	return dw_mci_runtime_resume(host);
 }
-#endif /* CONFIG_PM_SLEEP */
-
-static SIMPLE_DEV_PM_OPS(dw_mci_pci_pmops, dw_mci_pci_suspend, dw_mci_pci_resume);
+#endif /* CONFIG_PM */
+
+static const struct dev_pm_ops dw_mci_pci_dev_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_pci_runtime_suspend,
+			   dw_mci_pci_runtime_resume,
+			   NULL)
+};
 
 static const struct pci_device_id dw_mci_pci_id[] = {
 	{ PCI_DEVICE(SYNOPSYS_DW_MCI_VENDOR_ID, SYNOPSYS_DW_MCI_DEVICE_ID) },
@@ -111,7 +118,7 @@ static struct pci_driver dw_mci_pci_driver = {
 	.probe		= dw_mci_pci_probe,
 	.remove		= dw_mci_pci_remove,
 	.driver		=	{
-		.pm =   &dw_mci_pci_pmops
+		.pm =   &dw_mci_pci_dev_pm_ops,
 	},
 };
 
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 06:50:44 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 21:50:44 +0800
Subject: [PATCH 6/9] mmc: dw_mmc-exynos: deploay runtime PM facilities
In-Reply-To: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476021044-31354-1-git-send-email-shawn.lin@rock-chips.com>

Let's migrate it to use runtime PM and remove the system
PM callback from this driver. With this patch, it could
handle system PM properly and could also use runtime PM
if we enable it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/host/dw_mmc-exynos.c | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 7ab3d74..189fd38 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -17,6 +17,7 @@
 #include <linux/mmc/mmc.h>
 #include <linux/of.h>
 #include <linux/of_gpio.h>
+#include <linux/pm_runtime.h>
 #include <linux/slab.h>
 
 #include "dw_mmc.h"
@@ -161,20 +162,20 @@ static void dw_mci_exynos_set_clksel_timing(struct dw_mci *host, u32 timing)
 		set_bit(DW_MMC_CARD_NO_USE_HOLD, &host->cur_slot->flags);
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int dw_mci_exynos_suspend(struct device *dev)
+#ifdef CONFIG_PM
+static int dw_mci_exynos_runtime_suspend(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
 
-	return dw_mci_suspend(host);
+	return dw_mci_runtime_suspend(host);
 }
 
-static int dw_mci_exynos_resume(struct device *dev)
+static int dw_mci_exynos_runtime_resume(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
 
 	dw_mci_exynos_config_smu(host);
-	return dw_mci_resume(host);
+	return dw_mci_runtime_resume(host);
 }
 
 /**
@@ -211,10 +212,8 @@ static int dw_mci_exynos_resume_noirq(struct device *dev)
 	return 0;
 }
 #else
-#define dw_mci_exynos_suspend		NULL
-#define dw_mci_exynos_resume		NULL
 #define dw_mci_exynos_resume_noirq	NULL
-#endif /* CONFIG_PM_SLEEP */
+#endif /* CONFIG_PM */
 
 static void dw_mci_exynos_config_hs400(struct dw_mci *host, u32 timing)
 {
@@ -531,7 +530,11 @@ static int dw_mci_exynos_probe(struct platform_device *pdev)
 }
 
 static const struct dev_pm_ops dw_mci_exynos_pmops = {
-	SET_SYSTEM_SLEEP_PM_OPS(dw_mci_exynos_suspend, dw_mci_exynos_resume)
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_exynos_runtime_suspend,
+			   dw_mci_exynos_runtime_resume,
+			   NULL)
 	.resume_noirq = dw_mci_exynos_resume_noirq,
 	.thaw_noirq = dw_mci_exynos_resume_noirq,
 	.restore_noirq = dw_mci_exynos_resume_noirq,
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 06:51:00 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 21:51:00 +0800
Subject: [PATCH 8/9] mmc: dw_mmc-pltfm: deploay runtime PM facilities
In-Reply-To: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476021060-31436-1-git-send-email-shawn.lin@rock-chips.com>

Let's migrate it to use runtime PM and remove the system
PM callback from this driver. With this patch, it could
handle system PM properly and could also use runtime PM
if we enable it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/host/dw_mmc-pltfm.c | 26 +++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index c0bb0c7..214e593 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -16,6 +16,7 @@
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/slab.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/mmc.h>
@@ -57,26 +58,29 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
 }
 EXPORT_SYMBOL_GPL(dw_mci_pltfm_register);
 
-#ifdef CONFIG_PM_SLEEP
-/*
- * TODO: we should probably disable the clock to the card in the suspend path.
- */
-static int dw_mci_pltfm_suspend(struct device *dev)
+#ifdef CONFIG_PM
+static int dw_mci_pltfm_runtime_suspend(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
 
-	return dw_mci_suspend(host);
+	return dw_mci_runtime_suspend(host);
 }
 
-static int dw_mci_pltfm_resume(struct device *dev)
+static int dw_mci_pltfm_runtime_resume(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
 
-	return dw_mci_resume(host);
+	return dw_mci_runtime_resume(host);
 }
-#endif /* CONFIG_PM_SLEEP */
-
-SIMPLE_DEV_PM_OPS(dw_mci_pltfm_pmops, dw_mci_pltfm_suspend, dw_mci_pltfm_resume);
+#endif /* CONFIG_PM */
+
+const struct dev_pm_ops dw_mci_pltfm_pmops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_pltfm_runtime_suspend,
+			   dw_mci_pltfm_runtime_resume,
+			   NULL)
+};
 EXPORT_SYMBOL_GPL(dw_mci_pltfm_pmops);
 
 static const struct of_device_id dw_mci_pltfm_match[] = {
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 06:51:11 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 21:51:11 +0800
Subject: [PATCH 9/9] mmc: dw_mmc: remove system PM callback
In-Reply-To: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476020951-31292-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476021071-31477-1-git-send-email-shawn.lin@rock-chips.com>

Now there are no variant drivers using dw_mci_suspend
and dw_mci_resume, so let's remove it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/host/dw_mmc.c | 44 ++++++++------------------------------------
 drivers/mmc/host/dw_mmc.h |  2 --
 2 files changed, 8 insertions(+), 38 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index c5ef263..46a14c5 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3267,26 +3267,24 @@ EXPORT_SYMBOL(dw_mci_remove);
 
 
 #ifdef CONFIG_PM
-/*
- * TODO: we should probably disable the clock to the card in the suspend path.
- */
-int dw_mci_suspend(struct dw_mci *host)
+int dw_mci_runtime_suspend(struct dw_mci *host)
 {
 	if (host->use_dma && host->dma_ops->exit)
 		host->dma_ops->exit(host);
 
+	clk_disable_unprepare(host->ciu_clk);
+
 	return 0;
 }
-EXPORT_SYMBOL(dw_mci_suspend);
+EXPORT_SYMBOL(dw_mci_runtime_suspend);
 
-int dw_mci_resume(struct dw_mci *host)
+int dw_mci_runtime_resume(struct dw_mci *host)
 {
-	int i, ret;
+	int i, ret = 0;
 
-	if (!dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS)) {
-		ret = -ENODEV;
+	ret = clk_prepare_enable(host->ciu_clk);
+	if (ret)
 		return ret;
-	}
 
 	if (host->use_dma && host->dma_ops->init)
 		host->dma_ops->init(host);
@@ -3323,32 +3321,6 @@ int dw_mci_resume(struct dw_mci *host)
 
 	return 0;
 }
-EXPORT_SYMBOL(dw_mci_resume);
-
-int dw_mci_runtime_suspend(struct dw_mci *host)
-{
-	int err = 0;
-
-	err = dw_mci_suspend(host);
-	if (err)
-		return err;
-
-	clk_disable_unprepare(host->ciu_clk);
-
-	return err;
-}
-EXPORT_SYMBOL(dw_mci_runtime_suspend);
-
-int dw_mci_runtime_resume(struct dw_mci *host)
-{
-	int ret = 0;
-
-	ret = clk_prepare_enable(host->ciu_clk);
-	if (ret)
-		return ret;
-
-	return dw_mci_resume(host);
-}
 EXPORT_SYMBOL(dw_mci_runtime_resume);
 #endif /* CONFIG_PM */
 
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index baa7261..b642dbb 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -235,8 +235,6 @@
 extern int dw_mci_probe(struct dw_mci *host);
 extern void dw_mci_remove(struct dw_mci *host);
 #ifdef CONFIG_PM
-extern int dw_mci_suspend(struct dw_mci *host);
-extern int dw_mci_resume(struct dw_mci *host);
 extern int dw_mci_runtime_suspend(struct dw_mci *host);
 extern int dw_mci_runtime_resume(struct dw_mci *host);
 #endif
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 06:58:17 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 21:58:17 +0800
Subject: [RESEND PATCH 0/9] Init runtime PM support for dw_mmc
Message-ID: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>


Hi Jaehoon and Ulf,

   This patch is gonna support runtime PM for dw_mmc.
It could support to disable ciu_clk by default and disable
biu_clk if the devices are non-removeable, or removeable
with gpio-base card detect.

   Then I remove the system PM since the runtime PM actually
does the same thing as it. So I help migrate the dw_mmc variant
drivers to use runtime PM pairs and pm_runtime_force_*. Note
that I only enable runtime PM for dw_mmc-rockchip as I will
leave the decision to the owners of the corresponding drivers.
I just tested it on my RK3288 platform with linux-next to make
the runtime PM and system PM work fine for my emmc, sd card and
sdio. But I don't have hardware to help test other variant drivers.
But in theory it should work fine as I mentioned that the runtime
PM does the same thing as system PM except for disabling ciu_clk
aggressively which should not be related to the variant hosts.

   As you could see that I just extend the slot-gpio a bit, so the
ideal way is Ulf could pick them up with Jaehoon's ack. :)



Shawn Lin (9):
  mmc: dw_mmc: add runtime PM callback
  mmc: dw_mmc-rockchip: add runtime PM support
  mmc: core: expose the capability of gpio card detect
  mmc: dw_mmc-rockchip: disable biu clk if possible
  mmc: dw_mmc-k3: deploay runtime PM facilities
  mmc: dw_mmc-exynos: deploay runtime PM facilities
  mmc: dw_mmc-pci: deploay runtime PM facilities
  mmc: dw_mmc-pltfm: deploay runtime PM facilities
  mmc: dw_mmc: remove system PM callback

 drivers/mmc/core/slot-gpio.c       |  8 +++++
 drivers/mmc/host/dw_mmc-exynos.c   | 21 ++++++-----
 drivers/mmc/host/dw_mmc-k3.c       | 37 +++++++++----------
 drivers/mmc/host/dw_mmc-pci.c      | 25 ++++++++-----
 drivers/mmc/host/dw_mmc-pltfm.c    | 26 ++++++++------
 drivers/mmc/host/dw_mmc-rockchip.c | 73 ++++++++++++++++++++++++++++++++++++--
 drivers/mmc/host/dw_mmc.c          | 24 ++++++-------
 drivers/mmc/host/dw_mmc.h          |  6 ++--
 include/linux/mmc/slot-gpio.h      |  1 +
 9 files changed, 152 insertions(+), 69 deletions(-)

-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 06:58:18 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 21:58:18 +0800
Subject: [RESEND PATCH 1/9] mmc: dw_mmc: add runtime PM callback
In-Reply-To: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476021506-869-2-git-send-email-shawn.lin@rock-chips.com>

This patch add dw_mci_runtime_suspend/resume interfaces
and expose it to dw_mci variant driver to support runtime
PM.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

 drivers/mmc/host/dw_mmc.c | 30 ++++++++++++++++++++++++++++--
 drivers/mmc/host/dw_mmc.h |  4 +++-
 2 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 4fcbc40..c5ef263 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3266,7 +3266,7 @@ EXPORT_SYMBOL(dw_mci_remove);
 
 
 
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
 /*
  * TODO: we should probably disable the clock to the card in the suspend path.
  */
@@ -3324,7 +3324,33 @@ int dw_mci_resume(struct dw_mci *host)
 	return 0;
 }
 EXPORT_SYMBOL(dw_mci_resume);
-#endif /* CONFIG_PM_SLEEP */
+
+int dw_mci_runtime_suspend(struct dw_mci *host)
+{
+	int err = 0;
+
+	err = dw_mci_suspend(host);
+	if (err)
+		return err;
+
+	clk_disable_unprepare(host->ciu_clk);
+
+	return err;
+}
+EXPORT_SYMBOL(dw_mci_runtime_suspend);
+
+int dw_mci_runtime_resume(struct dw_mci *host)
+{
+	int ret = 0;
+
+	ret = clk_prepare_enable(host->ciu_clk);
+	if (ret)
+		return ret;
+
+	return dw_mci_resume(host);
+}
+EXPORT_SYMBOL(dw_mci_runtime_resume);
+#endif /* CONFIG_PM */
 
 static int __init dw_mci_init(void)
 {
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index e8cd2de..baa7261 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -234,9 +234,11 @@
 
 extern int dw_mci_probe(struct dw_mci *host);
 extern void dw_mci_remove(struct dw_mci *host);
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
 extern int dw_mci_suspend(struct dw_mci *host);
 extern int dw_mci_resume(struct dw_mci *host);
+extern int dw_mci_runtime_suspend(struct dw_mci *host);
+extern int dw_mci_runtime_resume(struct dw_mci *host);
 #endif
 
 /**
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 06:58:19 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 21:58:19 +0800
Subject: [RESEND PATCH 2/9] mmc: dw_mmc-rockchip: add runtime PM support
In-Reply-To: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476021506-869-3-git-send-email-shawn.lin@rock-chips.com>

This patch adds runtime PM support for dw_mmc-rockchip.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/host/dw_mmc-rockchip.c | 57 ++++++++++++++++++++++++++++++++++++--
 1 file changed, 54 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
index 25eae35..28e0220 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -13,6 +13,7 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/dw_mmc.h>
 #include <linux/of_address.h>
+#include <linux/pm_runtime.h>
 #include <linux/slab.h>
 
 #include "dw_mmc.h"
@@ -325,6 +326,7 @@ static int dw_mci_rockchip_probe(struct platform_device *pdev)
 {
 	const struct dw_mci_drv_data *drv_data;
 	const struct of_device_id *match;
+	int ret;
 
 	if (!pdev->dev.of_node)
 		return -ENODEV;
@@ -332,16 +334,65 @@ static int dw_mci_rockchip_probe(struct platform_device *pdev)
 	match = of_match_node(dw_mci_rockchip_match, pdev->dev.of_node);
 	drv_data = match->data;
 
-	return dw_mci_pltfm_register(pdev, drv_data);
+	pm_runtime_get_noresume(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
+	pm_runtime_use_autosuspend(&pdev->dev);
+
+	ret = dw_mci_pltfm_register(pdev, drv_data);
+	if (ret) {
+		pm_runtime_disable(&pdev->dev);
+		pm_runtime_set_suspended(&pdev->dev);
+		pm_runtime_put_noidle(&pdev->dev);
+		return ret;
+	}
+
+	pm_runtime_put_autosuspend(&pdev->dev);
+
+	return 0;
+}
+
+static int dw_mci_rockchip_remove(struct platform_device *pdev)
+{
+	pm_runtime_get_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+	pm_runtime_put_noidle(&pdev->dev);
+
+	return dw_mci_pltfm_remove(pdev);
 }
 
+#ifdef CONFIG_PM
+static int dw_mci_rockchip_runtime_suspend(struct device *dev)
+{
+	struct dw_mci *host = dev_get_drvdata(dev);
+
+	return dw_mci_runtime_suspend(host);
+}
+
+static int dw_mci_rockchip_runtime_resume(struct device *dev)
+{
+	struct dw_mci *host = dev_get_drvdata(dev);
+
+	return dw_mci_runtime_resume(host);
+}
+#endif /* CONFIG_PM */
+
+static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_rockchip_runtime_suspend,
+			   dw_mci_rockchip_runtime_resume,
+			   NULL)
+};
+
 static struct platform_driver dw_mci_rockchip_pltfm_driver = {
 	.probe		= dw_mci_rockchip_probe,
-	.remove		= dw_mci_pltfm_remove,
+	.remove		= dw_mci_rockchip_remove,
 	.driver		= {
 		.name		= "dwmmc_rockchip",
 		.of_match_table	= dw_mci_rockchip_match,
-		.pm		= &dw_mci_pltfm_pmops,
+		.pm		= &dw_mci_rockchip_dev_pm_ops,
 	},
 };
 
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 06:58:20 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 21:58:20 +0800
Subject: [RESEND PATCH 3/9] mmc: core: expose the capability of gpio card
 detect
In-Reply-To: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476021506-869-4-git-send-email-shawn.lin@rock-chips.com>

Add new helper API mmc_can_gpio_cd for slot-gpio to make
host drivers know whether it supports gpio card detect.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/core/slot-gpio.c  | 8 ++++++++
 include/linux/mmc/slot-gpio.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index 27117ba..babe591 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -258,6 +258,14 @@ int mmc_gpiod_request_cd(struct mmc_host *host, const char *con_id,
 }
 EXPORT_SYMBOL(mmc_gpiod_request_cd);
 
+bool mmc_can_gpio_cd(struct mmc_host *host)
+{
+	struct mmc_gpio *ctx = host->slot.handler_priv;
+
+	return ctx->cd_gpio ? true : false;
+}
+EXPORT_SYMBOL(mmc_can_gpio_cd);
+
 /**
  * mmc_gpiod_request_ro - request a gpio descriptor for write protection
  * @host: mmc host
diff --git a/include/linux/mmc/slot-gpio.h b/include/linux/mmc/slot-gpio.h
index 3945a8c..a7972cd 100644
--- a/include/linux/mmc/slot-gpio.h
+++ b/include/linux/mmc/slot-gpio.h
@@ -29,5 +29,6 @@ int mmc_gpiod_request_ro(struct mmc_host *host, const char *con_id,
 void mmc_gpio_set_cd_isr(struct mmc_host *host,
 			 irqreturn_t (*isr)(int irq, void *dev_id));
 void mmc_gpiod_request_cd_irq(struct mmc_host *host);
+bool mmc_can_gpio_cd(struct mmc_host *host);
 
 #endif
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 06:58:21 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 21:58:21 +0800
Subject: [RESEND PATCH 4/9] mmc: dw_mmc-rockchip: disable biu clk if possible
In-Reply-To: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476021506-869-5-git-send-email-shawn.lin@rock-chips.com>

We could disable biu clk and power-off genpd if gpio
card detect available.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/host/dw_mmc-rockchip.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
index 28e0220..7528720 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -13,6 +13,7 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/dw_mmc.h>
 #include <linux/of_address.h>
+#include <linux/mmc/slot-gpio.h>
 #include <linux/pm_runtime.h>
 #include <linux/slab.h>
 
@@ -366,14 +367,29 @@ static int dw_mci_rockchip_remove(struct platform_device *pdev)
 static int dw_mci_rockchip_runtime_suspend(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
+	int ret;
+
+	ret = dw_mci_runtime_suspend(host);
+	if (ret)
+		return ret;
 
-	return dw_mci_runtime_suspend(host);
+	if (host->cur_slot &&
+	    (mmc_can_gpio_cd(host->cur_slot->mmc) ||
+	     !mmc_card_is_removable(host->cur_slot->mmc)))
+		clk_disable_unprepare(host->biu_clk);
+
+	return 0;
 }
 
 static int dw_mci_rockchip_runtime_resume(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
 
+	if (host->cur_slot &&
+	    (mmc_can_gpio_cd(host->cur_slot->mmc) ||
+	     !mmc_card_is_removable(host->cur_slot->mmc)))
+		clk_prepare_enable(host->biu_clk);
+
 	return dw_mci_runtime_resume(host);
 }
 #endif /* CONFIG_PM */
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 07:01:57 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 22:01:57 +0800
Subject: [RESEND PATCH 5/9] mmc: dw_mmc-k3: deploay runtime PM facilities
In-Reply-To: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476021721-923-1-git-send-email-shawn.lin@rock-chips.com>

Let's migrate it to use runtime PM and remove the system
PM callback from this driver. With this patch, it could
handle system PM properly and could also use runtime PM
if we enable it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/host/dw_mmc-k3.c | 37 ++++++++++++++++---------------------
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c
index 6247894..99b859d 100644
--- a/drivers/mmc/host/dw_mmc-k3.c
+++ b/drivers/mmc/host/dw_mmc-k3.c
@@ -15,6 +15,7 @@
 #include <linux/module.h>
 #include <linux/of_address.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 
@@ -162,35 +163,29 @@ static int dw_mci_k3_probe(struct platform_device *pdev)
 	return dw_mci_pltfm_register(pdev, drv_data);
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int dw_mci_k3_suspend(struct device *dev)
+#ifdef CONFIG_PM
+static int dw_mci_k3_runtime_suspend(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
-	int ret;
-
-	ret = dw_mci_suspend(host);
-	if (!ret)
-		clk_disable_unprepare(host->ciu_clk);
 
-	return ret;
+	return dw_mci_runtime_suspend(host);
 }
 
-static int dw_mci_k3_resume(struct device *dev)
+static int dw_mci_k3_runtime_resume(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
-	int ret;
 
-	ret = clk_prepare_enable(host->ciu_clk);
-	if (ret) {
-		dev_err(host->dev, "failed to enable ciu clock\n");
-		return ret;
-	}
-
-	return dw_mci_resume(host);
+	return dw_mci_runtime_resume(host);
 }
-#endif /* CONFIG_PM_SLEEP */
-
-static SIMPLE_DEV_PM_OPS(dw_mci_k3_pmops, dw_mci_k3_suspend, dw_mci_k3_resume);
+#endif /* CONFIG_PM */
+
+static const struct dev_pm_ops dw_mci_k3_dev_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_k3_runtime_suspend,
+			   dw_mci_k3_runtime_resume,
+			   NULL)
+};
 
 static struct platform_driver dw_mci_k3_pltfm_driver = {
 	.probe		= dw_mci_k3_probe,
@@ -198,7 +193,7 @@ static struct platform_driver dw_mci_k3_pltfm_driver = {
 	.driver		= {
 		.name		= "dwmmc_k3",
 		.of_match_table	= dw_mci_k3_match,
-		.pm		= &dw_mci_k3_pmops,
+		.pm		= &dw_mci_k3_dev_pm_ops,
 	},
 };
 
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 07:01:58 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 22:01:58 +0800
Subject: [RESEND PATCH 6/9] mmc: dw_mmc-exynos: deploay runtime PM facilities
In-Reply-To: <1476021721-923-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
 <1476021721-923-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476021721-923-2-git-send-email-shawn.lin@rock-chips.com>

Let's migrate it to use runtime PM and remove the system
PM callback from this driver. With this patch, it could
handle system PM properly and could also use runtime PM
if we enable it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/host/dw_mmc-exynos.c | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 7ab3d74..189fd38 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -17,6 +17,7 @@
 #include <linux/mmc/mmc.h>
 #include <linux/of.h>
 #include <linux/of_gpio.h>
+#include <linux/pm_runtime.h>
 #include <linux/slab.h>
 
 #include "dw_mmc.h"
@@ -161,20 +162,20 @@ static void dw_mci_exynos_set_clksel_timing(struct dw_mci *host, u32 timing)
 		set_bit(DW_MMC_CARD_NO_USE_HOLD, &host->cur_slot->flags);
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int dw_mci_exynos_suspend(struct device *dev)
+#ifdef CONFIG_PM
+static int dw_mci_exynos_runtime_suspend(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
 
-	return dw_mci_suspend(host);
+	return dw_mci_runtime_suspend(host);
 }
 
-static int dw_mci_exynos_resume(struct device *dev)
+static int dw_mci_exynos_runtime_resume(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
 
 	dw_mci_exynos_config_smu(host);
-	return dw_mci_resume(host);
+	return dw_mci_runtime_resume(host);
 }
 
 /**
@@ -211,10 +212,8 @@ static int dw_mci_exynos_resume_noirq(struct device *dev)
 	return 0;
 }
 #else
-#define dw_mci_exynos_suspend		NULL
-#define dw_mci_exynos_resume		NULL
 #define dw_mci_exynos_resume_noirq	NULL
-#endif /* CONFIG_PM_SLEEP */
+#endif /* CONFIG_PM */
 
 static void dw_mci_exynos_config_hs400(struct dw_mci *host, u32 timing)
 {
@@ -531,7 +530,11 @@ static int dw_mci_exynos_probe(struct platform_device *pdev)
 }
 
 static const struct dev_pm_ops dw_mci_exynos_pmops = {
-	SET_SYSTEM_SLEEP_PM_OPS(dw_mci_exynos_suspend, dw_mci_exynos_resume)
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_exynos_runtime_suspend,
+			   dw_mci_exynos_runtime_resume,
+			   NULL)
 	.resume_noirq = dw_mci_exynos_resume_noirq,
 	.thaw_noirq = dw_mci_exynos_resume_noirq,
 	.restore_noirq = dw_mci_exynos_resume_noirq,
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 07:01:59 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 22:01:59 +0800
Subject: [RESEND PATCH 7/9] mmc: dw_mmc-pci: deploay runtime PM facilities
In-Reply-To: <1476021721-923-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
 <1476021721-923-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476021721-923-3-git-send-email-shawn.lin@rock-chips.com>

Let's migrate it to use runtime PM and remove the system
PM callback from this driver. With this patch, it could
handle system PM properly and could also use runtime PM
if we enable it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/host/dw_mmc-pci.c | 25 ++++++++++++++++---------
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-pci.c b/drivers/mmc/host/dw_mmc-pci.c
index 4c69fbd..61789b1 100644
--- a/drivers/mmc/host/dw_mmc-pci.c
+++ b/drivers/mmc/host/dw_mmc-pci.c
@@ -14,6 +14,7 @@
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/pci.h>
+#include <linux/pm_runtime.h>
 #include <linux/slab.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/mmc.h>
@@ -79,25 +80,31 @@ static void dw_mci_pci_remove(struct pci_dev *pdev)
 	dw_mci_remove(host);
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int dw_mci_pci_suspend(struct device *dev)
+#ifdef CONFIG_PM
+static int dw_mci_pci_runtime_suspend(struct device *dev)
 {
 	struct pci_dev *pdev = to_pci_dev(dev);
 	struct dw_mci *host = pci_get_drvdata(pdev);
 
-	return dw_mci_suspend(host);
+	return dw_mci_runtime_suspend(host);
 }
 
-static int dw_mci_pci_resume(struct device *dev)
+static int dw_mci_pci_runtime_resume(struct device *dev)
 {
 	struct pci_dev *pdev = to_pci_dev(dev);
 	struct dw_mci *host = pci_get_drvdata(pdev);
 
-	return dw_mci_resume(host);
+	return dw_mci_runtime_resume(host);
 }
-#endif /* CONFIG_PM_SLEEP */
-
-static SIMPLE_DEV_PM_OPS(dw_mci_pci_pmops, dw_mci_pci_suspend, dw_mci_pci_resume);
+#endif /* CONFIG_PM */
+
+static const struct dev_pm_ops dw_mci_pci_dev_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_pci_runtime_suspend,
+			   dw_mci_pci_runtime_resume,
+			   NULL)
+};
 
 static const struct pci_device_id dw_mci_pci_id[] = {
 	{ PCI_DEVICE(SYNOPSYS_DW_MCI_VENDOR_ID, SYNOPSYS_DW_MCI_DEVICE_ID) },
@@ -111,7 +118,7 @@ static struct pci_driver dw_mci_pci_driver = {
 	.probe		= dw_mci_pci_probe,
 	.remove		= dw_mci_pci_remove,
 	.driver		=	{
-		.pm =   &dw_mci_pci_pmops
+		.pm =   &dw_mci_pci_dev_pm_ops,
 	},
 };
 
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 07:02:00 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 22:02:00 +0800
Subject: [RESEND PATCH 8/9] mmc: dw_mmc-pltfm: deploay runtime PM facilities
In-Reply-To: <1476021721-923-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
 <1476021721-923-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476021721-923-4-git-send-email-shawn.lin@rock-chips.com>

Let's migrate it to use runtime PM and remove the system
PM callback from this driver. With this patch, it could
handle system PM properly and could also use runtime PM
if we enable it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/host/dw_mmc-pltfm.c | 26 +++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index c0bb0c7..214e593 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -16,6 +16,7 @@
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/slab.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/mmc.h>
@@ -57,26 +58,29 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
 }
 EXPORT_SYMBOL_GPL(dw_mci_pltfm_register);
 
-#ifdef CONFIG_PM_SLEEP
-/*
- * TODO: we should probably disable the clock to the card in the suspend path.
- */
-static int dw_mci_pltfm_suspend(struct device *dev)
+#ifdef CONFIG_PM
+static int dw_mci_pltfm_runtime_suspend(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
 
-	return dw_mci_suspend(host);
+	return dw_mci_runtime_suspend(host);
 }
 
-static int dw_mci_pltfm_resume(struct device *dev)
+static int dw_mci_pltfm_runtime_resume(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
 
-	return dw_mci_resume(host);
+	return dw_mci_runtime_resume(host);
 }
-#endif /* CONFIG_PM_SLEEP */
-
-SIMPLE_DEV_PM_OPS(dw_mci_pltfm_pmops, dw_mci_pltfm_suspend, dw_mci_pltfm_resume);
+#endif /* CONFIG_PM */
+
+const struct dev_pm_ops dw_mci_pltfm_pmops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_pltfm_runtime_suspend,
+			   dw_mci_pltfm_runtime_resume,
+			   NULL)
+};
 EXPORT_SYMBOL_GPL(dw_mci_pltfm_pmops);
 
 static const struct of_device_id dw_mci_pltfm_match[] = {
-- 
2.3.7




From shawn.lin at rock-chips.com  Sun Oct  9 07:02:01 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Sun,  9 Oct 2016 22:02:01 +0800
Subject: [RESEND PATCH 9/9] mmc: dw_mmc: remove system PM callback
In-Reply-To: <1476021721-923-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
 <1476021721-923-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476021721-923-5-git-send-email-shawn.lin@rock-chips.com>

Now there are no variant drivers using dw_mci_suspend
and dw_mci_resume, so let's remove it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/mmc/host/dw_mmc.c | 44 ++++++++------------------------------------
 drivers/mmc/host/dw_mmc.h |  2 --
 2 files changed, 8 insertions(+), 38 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index c5ef263..46a14c5 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3267,26 +3267,24 @@ EXPORT_SYMBOL(dw_mci_remove);
 
 
 #ifdef CONFIG_PM
-/*
- * TODO: we should probably disable the clock to the card in the suspend path.
- */
-int dw_mci_suspend(struct dw_mci *host)
+int dw_mci_runtime_suspend(struct dw_mci *host)
 {
 	if (host->use_dma && host->dma_ops->exit)
 		host->dma_ops->exit(host);
 
+	clk_disable_unprepare(host->ciu_clk);
+
 	return 0;
 }
-EXPORT_SYMBOL(dw_mci_suspend);
+EXPORT_SYMBOL(dw_mci_runtime_suspend);
 
-int dw_mci_resume(struct dw_mci *host)
+int dw_mci_runtime_resume(struct dw_mci *host)
 {
-	int i, ret;
+	int i, ret = 0;
 
-	if (!dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS)) {
-		ret = -ENODEV;
+	ret = clk_prepare_enable(host->ciu_clk);
+	if (ret)
 		return ret;
-	}
 
 	if (host->use_dma && host->dma_ops->init)
 		host->dma_ops->init(host);
@@ -3323,32 +3321,6 @@ int dw_mci_resume(struct dw_mci *host)
 
 	return 0;
 }
-EXPORT_SYMBOL(dw_mci_resume);
-
-int dw_mci_runtime_suspend(struct dw_mci *host)
-{
-	int err = 0;
-
-	err = dw_mci_suspend(host);
-	if (err)
-		return err;
-
-	clk_disable_unprepare(host->ciu_clk);
-
-	return err;
-}
-EXPORT_SYMBOL(dw_mci_runtime_suspend);
-
-int dw_mci_runtime_resume(struct dw_mci *host)
-{
-	int ret = 0;
-
-	ret = clk_prepare_enable(host->ciu_clk);
-	if (ret)
-		return ret;
-
-	return dw_mci_resume(host);
-}
 EXPORT_SYMBOL(dw_mci_runtime_resume);
 #endif /* CONFIG_PM */
 
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index baa7261..b642dbb 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -235,8 +235,6 @@
 extern int dw_mci_probe(struct dw_mci *host);
 extern void dw_mci_remove(struct dw_mci *host);
 #ifdef CONFIG_PM
-extern int dw_mci_suspend(struct dw_mci *host);
-extern int dw_mci_resume(struct dw_mci *host);
 extern int dw_mci_runtime_suspend(struct dw_mci *host);
 extern int dw_mci_runtime_resume(struct dw_mci *host);
 #endif
-- 
2.3.7




From jh80.chung at samsung.com  Sun Oct  9 19:10:35 2016
From: jh80.chung at samsung.com (Jaehoon Chung)
Date: Mon, 10 Oct 2016 11:10:35 +0900
Subject: [RESEND PATCH 0/9] Init runtime PM support for dw_mmc
In-Reply-To: <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
References: <CGME20161009135255epcas1p4d5a9db74bb1dea56f61fcb2a720a07f0@epcas1p4.samsung.com>
 <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <9c4dd4aa-af9f-1765-fae6-f279ca45e60e@samsung.com>

Hi Shawn,

On 10/09/2016 10:58 PM, Shawn Lin wrote:
> Hi Jaehoon and Ulf,
> 
>    This patch is gonna support runtime PM for dw_mmc.
> It could support to disable ciu_clk by default and disable
> biu_clk if the devices are non-removeable, or removeable
> with gpio-base card detect.
> 
>    Then I remove the system PM since the runtime PM actually
> does the same thing as it. So I help migrate the dw_mmc variant
> drivers to use runtime PM pairs and pm_runtime_force_*. Note
> that I only enable runtime PM for dw_mmc-rockchip as I will
> leave the decision to the owners of the corresponding drivers.
> I just tested it on my RK3288 platform with linux-next to make
> the runtime PM and system PM work fine for my emmc, sd card and
> sdio. But I don't have hardware to help test other variant drivers.
> But in theory it should work fine as I mentioned that the runtime
> PM does the same thing as system PM except for disabling ciu_clk
> aggressively which should not be related to the variant hosts.

I'm testing this patchset with exynos SoCs. If it's possible to use other SoCs,
then I think your patches will be changed more clear than now.
e.g) Not need to define the each driver's runtime_pm_suspend/resume function.

> 
>    As you could see that I just extend the slot-gpio a bit, so the
> ideal way is Ulf could pick them up with Jaehoon's ack. :)
> 
> 
> 
> Shawn Lin (9):
>   mmc: dw_mmc: add runtime PM callback
>   mmc: dw_mmc-rockchip: add runtime PM support
>   mmc: core: expose the capability of gpio card detect
>   mmc: dw_mmc-rockchip: disable biu clk if possible
>   mmc: dw_mmc-k3: deploay runtime PM facilities
>   mmc: dw_mmc-exynos: deploay runtime PM facilities
>   mmc: dw_mmc-pci: deploay runtime PM facilities
>   mmc: dw_mmc-pltfm: deploay runtime PM facilities

Maybe s/deploay/deploy

Best Regards,
Jaehoon Chung

>   mmc: dw_mmc: remove system PM callback
> 
>  drivers/mmc/core/slot-gpio.c       |  8 +++++
>  drivers/mmc/host/dw_mmc-exynos.c   | 21 ++++++-----
>  drivers/mmc/host/dw_mmc-k3.c       | 37 +++++++++----------
>  drivers/mmc/host/dw_mmc-pci.c      | 25 ++++++++-----
>  drivers/mmc/host/dw_mmc-pltfm.c    | 26 ++++++++------
>  drivers/mmc/host/dw_mmc-rockchip.c | 73 ++++++++++++++++++++++++++++++++++++--
>  drivers/mmc/host/dw_mmc.c          | 24 ++++++-------
>  drivers/mmc/host/dw_mmc.h          |  6 ++--
>  include/linux/mmc/slot-gpio.h      |  1 +
>  9 files changed, 152 insertions(+), 69 deletions(-)
> 



From shawn.lin at rock-chips.com  Sun Oct  9 19:30:38 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Mon, 10 Oct 2016 10:30:38 +0800
Subject: [RESEND PATCH 0/9] Init runtime PM support for dw_mmc
In-Reply-To: <9c4dd4aa-af9f-1765-fae6-f279ca45e60e@samsung.com>
References: <CGME20161009135255epcas1p4d5a9db74bb1dea56f61fcb2a720a07f0@epcas1p4.samsung.com>
 <1476021506-869-1-git-send-email-shawn.lin@rock-chips.com>
 <9c4dd4aa-af9f-1765-fae6-f279ca45e60e@samsung.com>
Message-ID: <9290d000-73ee-6db3-34d1-4eb060c31447@rock-chips.com>

? 2016/10/10 10:10, Jaehoon Chung ??:
> Hi Shawn,
>
> On 10/09/2016 10:58 PM, Shawn Lin wrote:
>> Hi Jaehoon and Ulf,
>>
>>    This patch is gonna support runtime PM for dw_mmc.
>> It could support to disable ciu_clk by default and disable
>> biu_clk if the devices are non-removeable, or removeable
>> with gpio-base card detect.
>>
>>    Then I remove the system PM since the runtime PM actually
>> does the same thing as it. So I help migrate the dw_mmc variant
>> drivers to use runtime PM pairs and pm_runtime_force_*. Note
>> that I only enable runtime PM for dw_mmc-rockchip as I will
>> leave the decision to the owners of the corresponding drivers.
>> I just tested it on my RK3288 platform with linux-next to make
>> the runtime PM and system PM work fine for my emmc, sd card and
>> sdio. But I don't have hardware to help test other variant drivers.
>> But in theory it should work fine as I mentioned that the runtime
>> PM does the same thing as system PM except for disabling ciu_clk
>> aggressively which should not be related to the variant hosts.
>
> I'm testing this patchset with exynos SoCs. If it's possible to use other SoCs,

Thanks for testing this patchset, I will respin v2 if there are no any
other nitpick from folkz and regression when you test it.

> then I think your patches will be changed more clear than now.
> e.g) Not need to define the each driver's runtime_pm_suspend/resume function.
>

Sure.

>>
>>    As you could see that I just extend the slot-gpio a bit, so the
>> ideal way is Ulf could pick them up with Jaehoon's ack. :)
>>
>>
>>
>> Shawn Lin (9):
>>   mmc: dw_mmc: add runtime PM callback
>>   mmc: dw_mmc-rockchip: add runtime PM support
>>   mmc: core: expose the capability of gpio card detect
>>   mmc: dw_mmc-rockchip: disable biu clk if possible
>>   mmc: dw_mmc-k3: deploay runtime PM facilities
>>   mmc: dw_mmc-exynos: deploay runtime PM facilities
>>   mmc: dw_mmc-pci: deploay runtime PM facilities
>>   mmc: dw_mmc-pltfm: deploay runtime PM facilities
>
> Maybe s/deploay/deploy

Will fix the copy-paste error, mea culpa, but it is quite
interesting that checkpatch.pl didn't yell at it. :)

>
> Best Regards,
> Jaehoon Chung
>
>>   mmc: dw_mmc: remove system PM callback
>>
>>  drivers/mmc/core/slot-gpio.c       |  8 +++++
>>  drivers/mmc/host/dw_mmc-exynos.c   | 21 ++++++-----
>>  drivers/mmc/host/dw_mmc-k3.c       | 37 +++++++++----------
>>  drivers/mmc/host/dw_mmc-pci.c      | 25 ++++++++-----
>>  drivers/mmc/host/dw_mmc-pltfm.c    | 26 ++++++++------
>>  drivers/mmc/host/dw_mmc-rockchip.c | 73 ++++++++++++++++++++++++++++++++++++--
>>  drivers/mmc/host/dw_mmc.c          | 24 ++++++-------
>>  drivers/mmc/host/dw_mmc.h          |  6 ++--
>>  include/linux/mmc/slot-gpio.h      |  1 +
>>  9 files changed, 152 insertions(+), 69 deletions(-)
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Best Regards
Shawn Lin



From caesar.upstream at gmail.com  Sun Oct  9 20:53:20 2016
From: caesar.upstream at gmail.com (Caesar Wang)
Date: Mon, 10 Oct 2016 11:53:20 +0800
Subject: [PATCH] thermal: rockchip: improve the warning log
In-Reply-To: <1476017358-26143-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476017358-26143-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <57FB10B0.8080503@gmail.com>


On 2016?10?09? 20:49, Shawn Lin wrote:
> There is no necessary to print warning agian and
> again if we don't add rockchip,grf for dt, otherwise
> I saw the following log when doning suspend-2-resume.
> We only need to print it once when parsing dt. It looks
> quite trivial but the log is apparently verbose.
>
> [   26.615415] PM: early resume of devices complete after 1.539 msecs
> [   26.622002] rk_tsadcv2_initialize: Missing rockchip,grf property
> [   26.629359] rk_gmac-dwmac ff290000.ethernet: init for RGMII
> [   26.639794] PM: resume of devices complete after 18.109 msecs
> [   26.646925] Restarting tasks ... done.
>
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

Reviewed-by: Caesar Wang <wxt at rock-chips.com>

> ---
>
>   drivers/thermal/rockchip_thermal.c | 7 ++-----
>   1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c
> index e227a9f..b811b0f 100644
> --- a/drivers/thermal/rockchip_thermal.c
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -524,11 +524,6 @@ static void rk_tsadcv2_initialize(struct regmap *grf, void __iomem *regs,
>   		       regs + TSADCV2_AUTO_PERIOD_HT);
>   	writel_relaxed(TSADCV2_HIGHT_TSHUT_DEBOUNCE_COUNT,
>   		       regs + TSADCV2_HIGHT_TSHUT_DEBOUNCE);
> -
> -	if (IS_ERR(grf)) {
> -		pr_warn("%s: Missing rockchip,grf property\n", __func__);
> -		return;
> -	}
>   }
>   
>   /**
> @@ -971,6 +966,8 @@ static int rockchip_configure_from_dt(struct device *dev,
>   	 * need this property.
>   	 */
>   	thermal->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
> +	if (IS_ERR(thermal->grf))
> +		dev_warn(dev, "Missing rockchip,grf property\n");
>   
>   	return 0;
>   }



From huangtao at rock-chips.com  Mon Oct 10 00:18:34 2016
From: huangtao at rock-chips.com (Huang, Tao)
Date: Mon, 10 Oct 2016 15:18:34 +0800
Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on
 rk3066
In-Reply-To: <f8aba48d-6c69-b246-4cb2-48a2770c80e4@gmail.com>
References: <20161001140939.GA31220@vaio-ubuntu>
 <6239b970-09d3-f7ee-e6f5-c019eaedb725@rock-chips.com>
 <f8aba48d-6c69-b246-4cb2-48a2770c80e4@gmail.com>
Message-ID: <67831fd0-76af-a793-0b2f-958e45633fe8@rock-chips.com>

Hi Pawe?:
On 2016?10?05? 14:09, Pawe? Jarosz wrote:
> W dniu 05.10.2016 o 04:27, Huang, Tao pisze:
>> I don't remember RK3066 has such limit. I will double check with our IC
>> design team.
>> Do you know which master can not access this memory area
>> [0x9F000000~0xA0000000)?
> I don't.
>> Could you please tell which board you're using (and how much memory it has)
> Rikomagic MK808 1GB RAM
>
Our IC guy need us tell them which master can not access such area, DMA
or EMMC Controller or GPU, etc? Could you tell me how to reproduce such
issue?
And we can confirm CPU core can access this memory through /dev/mem and
the test board is 1GB too. Personally, I don't think RK3066 has such
limit because when we verify this chip, we don't found such limit at all.

Thanks,
Huang, Tao



From paweljarosz3691 at gmail.com  Mon Oct 10 02:11:09 2016
From: paweljarosz3691 at gmail.com (=?UTF-8?Q?Pawe=c5=82_Jarosz?=)
Date: Mon, 10 Oct 2016 11:11:09 +0200
Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on
 rk3066
In-Reply-To: <67831fd0-76af-a793-0b2f-958e45633fe8@rock-chips.com>
References: <20161001140939.GA31220@vaio-ubuntu>
 <6239b970-09d3-f7ee-e6f5-c019eaedb725@rock-chips.com>
 <f8aba48d-6c69-b246-4cb2-48a2770c80e4@gmail.com>
 <67831fd0-76af-a793-0b2f-958e45633fe8@rock-chips.com>
Message-ID: <149df5ee-3478-6d15-bb76-47becac146e9@gmail.com>

Hi


W dniu 10.10.2016 o 09:18, Huang, Tao pisze:
> Our IC guy need us tell them which master can not access such area, DMA
> or EMMC Controller or GPU, etc? Could you tell me how to reproduce such
> issue?
> And we can confirm CPU core can access this memory through /dev/mem and
> the test board is 1GB too. Personally, I don't think RK3066 has such
> limit because when we verify this chip, we don't found such limit at all.
>
> Thanks,
> Huang, Tao

I'm getting this on Ubuntu 16.04 with mainline kernel.
My board always freezes when i type: "memtester 800M"


From heiko at sntech.de  Mon Oct 10 02:54:01 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 10 Oct 2016 11:54:01 +0200
Subject: [PATCH v1 1/2] ARM: dts: add rockchip PX3 Evaluation board
In-Reply-To: <64f4be31-1b19-60e3-da7c-f2fec186fab9@suse.de>
References: <1473529249-6151-1-git-send-email-andy.yan@rock-chips.com>
 <1473529440-6202-1-git-send-email-andy.yan@rock-chips.com>
 <64f4be31-1b19-60e3-da7c-f2fec186fab9@suse.de>
Message-ID: <738050204.FfkOZgkGGl@phil>

Hi Andreas, Andy,

Am Dienstag, 13. September 2016, 14:14:01 CEST schrieb Andreas F?rber:
> Hi Andy,
> 
> This patch didn't make it to linux-rockchip list somehow...
> Not sure why I'm CC'ed, I don't have access to such a board to check, so
> just a couple formal nitpicks:
> 
> Am 10.09.2016 um 19:44 schrieb Andy Yan:
> > PX3 EVB is designed by Rockchip for automotive field,
> > which intergrated with CVBS(TP2825)/MIPI DSI/LVDS/HDMI
> 
> "integrated"
> but the grammar is somewhat incorrect with "which" referring to field -
> I assume you meant "with integrated CVBS..."?
> 
> > video input/output interface, WIFI/BT/GPS(on a module
> 
> Also please always leave a space before an opening parenthesis in
> English text. Similarly above, spaces around "/" would help recognize
> that MIPI DSI belongs together rather than being two lists.
> 
> If nothing else applies below then maybe Heiko can edit it for you?

I've fixed the remarks in the commit description.


> > named S500 which based on MT6620), Gsensor BMA250E and
> > light&proximity sensor STK3410.
> > 
> > Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
> > 
> > ---
> > 
> > Changes in v1:
> > - board rename
> > - add vendor prefix for i2c interfaced sensors
> > - use stdout-path to set the default console
> > 
> >  Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
> >  arch/arm/boot/dts/Makefile                         |   1 +
> >  arch/arm/boot/dts/rk3188-px3-evb.dts               | 337
> >  +++++++++++++++++++++ 3 files changed, 342 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/rk3188-px3-evb.dts
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> > b/Documentation/devicetree/bindings/arm/rockchip.txt index
> > 6668645..6da3881 100644
> > --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> > +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> > @@ -21,6 +21,10 @@ Rockchip platforms device tree bindings
> > 
> >      Required root node properties:
> >        - compatible = "radxa,rock", "rockchip,rk3188";
> > 
> > +- Rockchip PX3 Evaluation board:
> > +    Required root node properties:
> > +      - compatible = "rockchip,px3-evb", "rockchip,px3",
> > "rockchip,rk3188";
> How compatible is PX3 with RK3188? It is a separate SoC product:
> 
> http://www.rock-chips.com/a/en/products/rkpower/2015/1125/730.html
> 
> Wondering whether or not to drop the third compatible string.

As discussed in IRC (and with arm-soc maintainers), I intend to keep the 
rk3188 part, as the chip really is just a (hardened?) variant of the consumer 
rk3188, but shares the same internals with the original.

> > +
> > 
> >  - Radxa Rock2 Square board:
> >      Required root node properties:
> >        - compatible = "radxa,rock2-square", "rockchip,rk3288";
> > 
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index faacd52..88d27a2 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -620,6 +620,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> > 
> >  	rk3066a-marsboard.dtb \
> >  	rk3066a-rayeager.dtb \
> >  	rk3188-radxarock.dtb \
> > 
> > +	rk3188-px3-evb.dtb \
> 
> Affects file naming as well: px3-evb.dtb?

see above

> 
> >  	rk3228-evb.dtb \
> >  	rk3229-evb.dtb \
> >  	rk3288-evb-act8846.dtb \
> > 
> > diff --git a/arch/arm/boot/dts/rk3188-px3-evb.dts
> > b/arch/arm/boot/dts/rk3188-px3-evb.dts new file mode 100644
> > index 0000000..f6bc738
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/rk3188-px3-evb.dts
> > @@ -0,0 +1,337 @@
> > +/*
> > + * Copyright (c) 2016 Andy Yan <andy.yan at rock-chips.com>
> > + *
> > + * 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 file 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 file 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.
> > + */
> > +
> > +/dts-v1/;
> > +#include <dt-bindings/input/input.h>
> > +#include "rk3188.dtsi"
> 
> I'm surprised there is no [rk3188-]px3.dtsi here! Surely some automotive
> vendor may design their own board with it and should have at least the
> two trailing compatible strings pre-set.

see above. I don't think there is a need to pollute the directory with 
(nearly) empty dtsi files, especially as the compatible will get overwritten by 
a board compatible anyway.

> 
> > +
> > +/ {
> > +	model = "Rockchip PX3-EVB";
> > +	compatible = "rockchip,px3-evb", "rockchip,px3", "rockchip,rk3188";
> > +
> > +	chosen {
> > +		stdout-path = "serial2:115200n8";
> > +	};
> > +
> > +	memory {
> > +		device_type = "memory";
> > +		reg = <0x60000000 0x80000000>;
> > +	};
> > +
> > +	gpio-keys {
> > +		compatible = "gpio-keys";
> > +		autorepeat;
> > +
> > +		power {
> > +			gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
> > +			linux,code = <KEY_POWER>;
> > +			label = "GPIO Key Power";
> > +			linux,input-type = <1>;
> > +			wakeup-source;
> > +			debounce-interval = <100>;
> > +		};
> > +	};
> > +
> > +	vcc_sys: vsys-regulator {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "vsys";
> > +		regulator-min-microvolt = <5000000>;
> > +		regulator-max-microvolt = <5000000>;
> > +		regulator-boot-on;
> > +	};
> > +};
> > +
> > +&cpu0 {
> > +	cpu0-supply = <&vdd_cpu>;
> > +};
> > +
> > +&i2c0 {
> > +	status = "okay";
> > +
> > +	 /* Accelerometer */
> 
> Space after tab intentional?
> 
> > +	bma250 at 18 {
> > +		compatible = "bosch,bma250";
> > +		reg = <0x18>;
> > +		interrupt-parent = <&gpio0>;
> > +		interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
> > +	};
> > +
> > +	stk3410 at 48 {
> > +		compatible = "sensortek,STK3310";
> > +		reg = <0x48>;
> > +		interrupt-parent = <&gpio1>;
> > +		interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
> > +	};
> 
> Generally it is undesired to repeat the compatible name as node name -
> did you compare other .dts files? (e.g., accelerometer at 18 would be
> self-documenting) If this is a copy from an existing .dts then please
> ignore this comment.

due to the compatible ambiguity, I had dropped the stk3410 node anyway.
I've also checked how the bma250 gets specified and there are both variants in 
use (accelerometer@ and bmc250@). So to set a good example for the future, 
I've changed the node name to accelerometer at 18 and dropped the now self 
explanatory comment obove it.


> 
> > +};
> > +
> > +&i2c1 {
> > +	status = "okay";
> > +	clock-frequency = <400000>;
> 
> Insert white line?

done


Heiko


From shawn.lin at rock-chips.com  Mon Oct 10 03:25:28 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Mon, 10 Oct 2016 18:25:28 +0800
Subject: [PATCH v5] PCI: rockchip: Support property to specify the link
 capability
Message-ID: <1476095128-15380-1-git-send-email-shawn.lin@rock-chips.com>

From: Brian Norris <briannorris at chromium.org>

rk3399 supports PCIe 2.x link speeds marginally at best, and on some
boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500
ms waiting for training that will never happen, let's add a property
from devicetree to specify link capability.

Signed-off-by: Brian Norris <briannorris at chromium.org>
Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
Reviewed-by: Brian Norris <briannorris at chromium.org>

---

Changes in v5:
- rebase the code since it isn't cleanly applied after Bjorn's cleanup

Changes in v4:
- define link_gen as u32
- elaborate more for rockchip,max-link-speed on doc

Changes in v3:
- Cast a warning for invalid max link speed and use gen1 for it.
  That looks better than v2. (Suggested by Brian)

Changes in v2:
- rename the property to rockchip,max-link-speed according to
  Bjorn's recommendation and take some bits from imx6q-pcie to
  make this requirement more consisent.

 .../devicetree/bindings/pci/rockchip-pcie.txt      |  4 ++
 drivers/pci/host/pcie-rockchip.c                   | 62 ++++++++++++++--------
 2 files changed, 44 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
index ba67b39..9bb29de 100644
--- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
@@ -42,6 +42,10 @@ Required properties:
 Optional Property:
 - ep-gpios: contain the entry for pre-reset gpio
 - num-lanes: number of lanes to use
+- rockchip,max-link-speed: Specify PCI gen for link capability. Must
+	be '2' for gen2, and '1' for gen1, otherwise will default to gen1.
+	For backward compatibility, if this property isn't assigned, we
+	use gen2 by default.
 - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
 - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe.
 - vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe.
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index b3548d0..cdbd98d 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -53,6 +53,7 @@
 #define   PCIE_CLIENT_ARI_ENABLE	  HIWORD_UPDATE_BIT(0x0008)
 #define   PCIE_CLIENT_CONF_LANE_NUM(x)	  HIWORD_UPDATE(0x0030, ENCODE_LANES(x))
 #define   PCIE_CLIENT_MODE_RC		  HIWORD_UPDATE_BIT(0x0040)
+#define   PCIE_CLIENT_GEN_SEL_1		  HIWORD_UPDATE(0x0080, 0)
 #define   PCIE_CLIENT_GEN_SEL_2		  HIWORD_UPDATE_BIT(0x0080)
 #define PCIE_CLIENT_BASIC_STATUS1	(PCIE_CLIENT_BASE + 0x48)
 #define   PCIE_CLIENT_LINK_STATUS_UP		0x00300000
@@ -200,6 +201,7 @@ struct rockchip_pcie {
 	struct	gpio_desc *ep_gpio;
 	u32	lanes;
 	u8	root_bus_nr;
+	u32	link_gen;
 	struct	device *dev;
 	struct	irq_domain *irq_domain;
 };
@@ -437,13 +439,19 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		return err;
 	}
 
+	if (rockchip->link_gen == 2)
+		rockchip_writel(rockchip, PCIE_CLIENT_CONFIG,
+				PCIE_CLIENT_GEN_SEL_2);
+	else
+		rockchip_writel(rockchip, PCIE_CLIENT_CONFIG,
+				PCIE_CLIENT_GEN_SEL_1);
+
 	rockchip_writel(rockchip, PCIE_CLIENT_CONFIG,
 			    PCIE_CLIENT_CONF_ENABLE |
 			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
 			    PCIE_CLIENT_ARI_ENABLE |
 			    PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
-			    PCIE_CLIENT_MODE_RC |
-			    PCIE_CLIENT_GEN_SEL_2);
+			    PCIE_CLIENT_MODE_RC);
 
 	err = phy_power_on(rockchip->phy);
 	if (err) {
@@ -519,29 +527,31 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		msleep(20);
 	}
 
-	/*
-	 * Enable retrain for gen2. This should be configured only after
-	 * gen1 finished.
-	 */
-	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
-	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
-	rockchip_writel(rockchip, PCIE_RC_CONFIG_LCS, status);
+	if (rockchip->link_gen == 2) {
+		/*
+		 * Enable retrain for gen2. This should be configured
+		 * only after gen1 finished.
+		 */
+		status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
+		status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
+		rockchip_writel(rockchip, PCIE_RC_CONFIG_LCS, status);
+
+		timeout = jiffies + msecs_to_jiffies(500);
+		for (;;) {
+			status = rockchip_readl(rockchip, PCIE_CORE_CTRL);
+			if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
+			    PCIE_CORE_PL_CONF_SPEED_5G) {
+				dev_dbg(dev, "PCIe link training gen2 pass!\n");
+				break;
+			}
 
-	timeout = jiffies + msecs_to_jiffies(500);
-	for (;;) {
-		status = rockchip_readl(rockchip, PCIE_CORE_CTRL);
-		if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
-		    PCIE_CORE_PL_CONF_SPEED_5G) {
-			dev_dbg(dev, "PCIe link training gen2 pass!\n");
-			break;
-		}
+			if (time_after(jiffies, timeout)) {
+				dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
+				break;
+			}
 
-		if (time_after(jiffies, timeout)) {
-			dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
-			break;
+			msleep(20);
 		}
-
-		msleep(20);
 	}
 
 	/* Check the final link width from negotiated lane counter from MGMT */
@@ -747,6 +757,14 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
 		rockchip->lanes = 1;
 	}
 
+	rockchip->link_gen = 2;
+	err = of_property_read_u32(node, "rockchip,max-link-speed",
+				   &rockchip->link_gen);
+	if (!err && rockchip->link_gen != 1 && rockchip->link_gen != 2) {
+		dev_warn(dev, "invalid max-link-speed, default to use gen1\n");
+		rockchip->link_gen = 1;
+	}
+
 	rockchip->core_rst = devm_reset_control_get(dev, "core");
 	if (IS_ERR(rockchip->core_rst)) {
 		if (PTR_ERR(rockchip->core_rst) != -EPROBE_DEFER)
-- 
2.3.7




From shawn.lin at rock-chips.com  Mon Oct 10 03:26:18 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Mon, 10 Oct 2016 18:26:18 +0800
Subject: [PATCH v2 1/3] PCI: rockchip: Provide captured slot power limit and
 scale
Message-ID: <1476095180-15984-1-git-send-email-shawn.lin@rock-chips.com>

If vpcie3v3 is available, we could provide these information
via RC's configure register to make EP able to know the power
limit.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v2:
- rebase the code since it isn't cleanly applied after Bjorn's cleanup

 drivers/pci/host/pcie-rockchip.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index b3548d0..75b6bbf 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -135,6 +135,10 @@
 #define PCIE_RC_CONFIG_VENDOR		(PCIE_RC_CONFIG_BASE + 0x00)
 #define PCIE_RC_CONFIG_RID_CCR		(PCIE_RC_CONFIG_BASE + 0x08)
 #define   PCIE_RC_CONFIG_SCC_SHIFT		16
+#define PCIE_RC_CONFIG_DCR		(PCIE_RC_CONFIG_BASE + 0xc4)
+#define   PCIE_RC_CONFIG_DCR_CSPL_SHIFT		18
+#define   PCIE_RC_CONFIG_DCR_CSPL_LIMIT		0xff
+#define   PCIE_RC_CONFIG_DCR_CPLS_SHIFT		26
 #define PCIE_RC_CONFIG_LCS		(PCIE_RC_CONFIG_BASE + 0xd0)
 #define   PCIE_RC_CONFIG_LCS_RETRAIN_LINK	BIT(5)
 #define   PCIE_RC_CONFIG_LCS_LBMIE		BIT(10)
@@ -394,6 +398,40 @@ static struct pci_ops rockchip_pcie_ops = {
 	.write = rockchip_pcie_wr_conf,
 };
 
+static void rockchip_pcie_set_power_limit(struct rockchip_pcie *rockchip)
+{
+	u32 status, curr, scale, power;
+
+	if (IS_ERR(rockchip->vpcie3v3))
+		return;
+
+	/*
+	 * Set RC's captured slot power limit and scale if
+	 * vpcie3v3 available. The default values are both zero
+	 * which means the software should set these two according
+	 * to the actual power supply.
+	 */
+	curr = regulator_get_current_limit(rockchip->vpcie3v3);
+	if (curr > 0) {
+		scale = 3; /* 0.001x */
+		curr = curr / 1000; /* convert to mA */
+		power = (curr * 3300) / 1000; /* milliwatt */
+		while (power > PCIE_RC_CONFIG_DCR_CSPL_LIMIT) {
+			if (!scale) {
+				dev_warn(rockchip->dev, "invalid power supply\n");
+				return;
+			}
+			scale--;
+			power = power / 10;
+		}
+
+		status = rockchip_readl(rockchip, PCIE_RC_CONFIG_DCR);
+		status |= (power << PCIE_RC_CONFIG_DCR_CSPL_SHIFT) |
+			  (scale << PCIE_RC_CONFIG_DCR_CPLS_SHIFT);
+		rockchip_writel(rockchip, PCIE_RC_CONFIG_DCR, status);
+	}
+}
+
 /**
  * rockchip_pcie_init_port - Initialize hardware
  * @rockchip: PCIe port information
@@ -494,6 +532,8 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		 (PCIE_CORE_CTRL_PLC1_FTS_CNT << PCIE_CORE_CTRL_PLC1_FTS_SHIFT);
 	rockchip_writel(rockchip, PCIE_CORE_CTRL_PLC1, status);
 
+	rockchip_pcie_set_power_limit(rockchip);
+
 	/* Enable Gen1 training */
 	rockchip_writel(rockchip, PCIE_CLIENT_CONFIG,
 			PCIE_CLIENT_LINK_TRAIN_ENABLE);
-- 
2.3.7




From shawn.lin at rock-chips.com  Mon Oct 10 03:26:19 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Mon, 10 Oct 2016 18:26:19 +0800
Subject: [PATCH v2 2/3] PCI: rockchip: Mark RC as common clock architecture
In-Reply-To: <1476095180-15984-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476095180-15984-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476095180-15984-2-git-send-email-shawn.lin@rock-chips.com>

The default value of common clock configuration is
zero indicating Rockchip's RC is using asynchronous
clock architecture but actually we are using common
clock. This will confuses some EP drivers if they
need some different settings referring to this value.
So let's fix it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v2:
- rebase the code since it isn't cleanly applied after Bjorn's cleanup

 drivers/pci/host/pcie-rockchip.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 75b6bbf..35f1ce2 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -141,6 +141,7 @@
 #define   PCIE_RC_CONFIG_DCR_CPLS_SHIFT		26
 #define PCIE_RC_CONFIG_LCS		(PCIE_RC_CONFIG_BASE + 0xd0)
 #define   PCIE_RC_CONFIG_LCS_RETRAIN_LINK	BIT(5)
+#define   PCIE_RC_CONFIG_LCS_CCC		BIT(6)
 #define   PCIE_RC_CONFIG_LCS_LBMIE		BIT(10)
 #define   PCIE_RC_CONFIG_LCS_LABIE		BIT(11)
 #define   PCIE_RC_CONFIG_LCS_LBMS		BIT(30)
@@ -534,6 +535,11 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 
 	rockchip_pcie_set_power_limit(rockchip);
 
+	/* Set RC's clock architecture as common clock */
+	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
+	status |= PCIE_RC_CONFIG_LCS_CCC;
+	rockchip_writel(rockchip, PCIE_RC_CONFIG_LCS, status);
+
 	/* Enable Gen1 training */
 	rockchip_writel(rockchip, PCIE_CLIENT_CONFIG,
 			PCIE_CLIENT_LINK_TRAIN_ENABLE);
-- 
2.3.7




From shawn.lin at rock-chips.com  Mon Oct 10 03:26:20 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Mon, 10 Oct 2016 18:26:20 +0800
Subject: [PATCH v2 3/3] PCI: rockchip: add COMPILE_TEST for Kconfig
In-Reply-To: <1476095180-15984-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476095180-15984-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476095180-15984-3-git-send-email-shawn.lin@rock-chips.com>

Add this could help build the driver if we enable
CONFIG_COMPILE_TEST.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

Changes in v2: None

 drivers/pci/host/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d7e7c0a..096440e 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -276,7 +276,7 @@ config PCIE_ARTPEC6
 
 config PCIE_ROCKCHIP
 	bool "Rockchip PCIe controller"
-	depends on ARCH_ROCKCHIP
+	depends on ARCH_ROCKCHIP || COMPILE_TEST
 	depends on OF
 	depends on PCI_MSI_IRQ_DOMAIN
 	select MFD_SYSCON
-- 
2.3.7




From andy.yan at rock-chips.com  Mon Oct 10 04:25:52 2016
From: andy.yan at rock-chips.com (Andy Yan)
Date: Mon, 10 Oct 2016 19:25:52 +0800
Subject: [PATCH v1 1/2] ARM: dts: add rockchip PX3 Evaluation board
In-Reply-To: <738050204.FfkOZgkGGl@phil>
References: <1473529249-6151-1-git-send-email-andy.yan@rock-chips.com>
 <1473529440-6202-1-git-send-email-andy.yan@rock-chips.com>
 <64f4be31-1b19-60e3-da7c-f2fec186fab9@suse.de> <738050204.FfkOZgkGGl@phil>
Message-ID: <0a74b063-a94f-00d9-d1f7-a417c03c06a9@rock-chips.com>

Hi Heiko:


On 2016?10?10? 17:54, Heiko Stuebner wrote:
> Hi Andreas, Andy,
>
> Am Dienstag, 13. September 2016, 14:14:01 CEST schrieb Andreas F?rber:
>> Hi Andy,
>>
>> This patch didn't make it to linux-rockchip list somehow...
>> Not sure why I'm CC'ed, I don't have access to such a board to check, so
>> just a couple formal nitpicks:
>>
>> Am 10.09.2016 um 19:44 schrieb Andy Yan:
>>> PX3 EVB is designed by Rockchip for automotive field,
>>> which intergrated with CVBS(TP2825)/MIPI DSI/LVDS/HDMI
>> "integrated"
>> but the grammar is somewhat incorrect with "which" referring to field -
>> I assume you meant "with integrated CVBS..."?
>>
>>> video input/output interface, WIFI/BT/GPS(on a module
>> Also please always leave a space before an opening parenthesis in
>> English text. Similarly above, spaces around "/" would help recognize
>> that MIPI DSI belongs together rather than being two lists.
>>
>> If nothing else applies below then maybe Heiko can edit it for you?
> I've fixed the remarks in the commit description.
>
>
>>> named S500 which based on MT6620), Gsensor BMA250E and
>>> light&proximity sensor STK3410.
>>>
>>> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
>>>
>>> ---
>>>
>>> Changes in v1:
>>> - board rename
>>> - add vendor prefix for i2c interfaced sensors
>>> - use stdout-path to set the default console
>>>
>>>   Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
>>>   arch/arm/boot/dts/Makefile                         |   1 +
>>>   arch/arm/boot/dts/rk3188-px3-evb.dts               | 337
>>>   +++++++++++++++++++++ 3 files changed, 342 insertions(+)
>>>   create mode 100644 arch/arm/boot/dts/rk3188-px3-evb.dts
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
>>> b/Documentation/devicetree/bindings/arm/rockchip.txt index
>>> 6668645..6da3881 100644
>>> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
>>> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
>>> @@ -21,6 +21,10 @@ Rockchip platforms device tree bindings
>>>
>>>       Required root node properties:
>>>         - compatible = "radxa,rock", "rockchip,rk3188";
>>>
>>> +- Rockchip PX3 Evaluation board:
>>> +    Required root node properties:
>>> +      - compatible = "rockchip,px3-evb", "rockchip,px3",
>>> "rockchip,rk3188";
>> How compatible is PX3 with RK3188? It is a separate SoC product:
>>
>> http://www.rock-chips.com/a/en/products/rkpower/2015/1125/730.html
>>
>> Wondering whether or not to drop the third compatible string.
> As discussed in IRC (and with arm-soc maintainers), I intend to keep the
> rk3188 part, as the chip really is just a (hardened?) variant of the consumer
> rk3188, but shares the same internals with the original.
>
>>> +
>>>
>>>   - Radxa Rock2 Square board:
>>>       Required root node properties:
>>>         - compatible = "radxa,rock2-square", "rockchip,rk3288";
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index faacd52..88d27a2 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -620,6 +620,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>>>
>>>   	rk3066a-marsboard.dtb \
>>>   	rk3066a-rayeager.dtb \
>>>   	rk3188-radxarock.dtb \
>>>
>>> +	rk3188-px3-evb.dtb \
>> Affects file naming as well: px3-evb.dtb?
> see above
>
>>>   	rk3228-evb.dtb \
>>>   	rk3229-evb.dtb \
>>>   	rk3288-evb-act8846.dtb \
>>>
>>> diff --git a/arch/arm/boot/dts/rk3188-px3-evb.dts
>>> b/arch/arm/boot/dts/rk3188-px3-evb.dts new file mode 100644
>>> index 0000000..f6bc738
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/rk3188-px3-evb.dts
>>> @@ -0,0 +1,337 @@
>>> +/*
>>> + * Copyright (c) 2016 Andy Yan <andy.yan at rock-chips.com>
>>> + *
>>> + * 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 file 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 file 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.
>>> + */
>>> +
>>> +/dts-v1/;
>>> +#include <dt-bindings/input/input.h>
>>> +#include "rk3188.dtsi"
>> I'm surprised there is no [rk3188-]px3.dtsi here! Surely some automotive
>> vendor may design their own board with it and should have at least the
>> two trailing compatible strings pre-set.
> see above. I don't think there is a need to pollute the directory with
> (nearly) empty dtsi files, especially as the compatible will get overwritten by
> a board compatible anyway.
>
>>> +
>>> +/ {
>>> +	model = "Rockchip PX3-EVB";
>>> +	compatible = "rockchip,px3-evb", "rockchip,px3", "rockchip,rk3188";
>>> +
>>> +	chosen {
>>> +		stdout-path = "serial2:115200n8";
>>> +	};
>>> +
>>> +	memory {
>>> +		device_type = "memory";
>>> +		reg = <0x60000000 0x80000000>;
>>> +	};
>>> +
>>> +	gpio-keys {
>>> +		compatible = "gpio-keys";
>>> +		autorepeat;
>>> +
>>> +		power {
>>> +			gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
>>> +			linux,code = <KEY_POWER>;
>>> +			label = "GPIO Key Power";
>>> +			linux,input-type = <1>;
>>> +			wakeup-source;
>>> +			debounce-interval = <100>;
>>> +		};
>>> +	};
>>> +
>>> +	vcc_sys: vsys-regulator {
>>> +		compatible = "regulator-fixed";
>>> +		regulator-name = "vsys";
>>> +		regulator-min-microvolt = <5000000>;
>>> +		regulator-max-microvolt = <5000000>;
>>> +		regulator-boot-on;
>>> +	};
>>> +};
>>> +
>>> +&cpu0 {
>>> +	cpu0-supply = <&vdd_cpu>;
>>> +};
>>> +
>>> +&i2c0 {
>>> +	status = "okay";
>>> +
>>> +	 /* Accelerometer */
>> Space after tab intentional?
>>
>>> +	bma250 at 18 {
>>> +		compatible = "bosch,bma250";
>>> +		reg = <0x18>;
>>> +		interrupt-parent = <&gpio0>;
>>> +		interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
>>> +	};
>>> +
>>> +	stk3410 at 48 {
>>> +		compatible = "sensortek,STK3310";
>>> +		reg = <0x48>;
>>> +		interrupt-parent = <&gpio1>;
>>> +		interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
>>> +	};
>> Generally it is undesired to repeat the compatible name as node name -
>> did you compare other .dts files? (e.g., accelerometer at 18 would be
>> self-documenting) If this is a copy from an existing .dts then please
>> ignore this comment.
> due to the compatible ambiguity, I had dropped the stk3410 node anyway.
> I've also checked how the bma250 gets specified and there are both variants in
> use (accelerometer@ and bmc250@). So to set a good example for the future,
> I've changed the node name to accelerometer at 18 and dropped the now self
> explanatory comment obove it.
>
>
>>> +};
>>> +
>>> +&i2c1 {
>>> +	status = "okay";
>>> +	clock-frequency = <400000>;
>> Insert white line?
> done
>
>
> Heiko
>
>



  I have no problem with these above, Thanks for all you have done.








From heiko at sntech.de  Mon Oct 10 05:23:15 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 10 Oct 2016 14:23:15 +0200
Subject: [PATCH v1 2/2] arm64: dts: rockchip: Add PX5 Evaluation board
In-Reply-To: <ef2bb52c-26f9-49a5-fe18-538effcd30b0@suse.de>
References: <1473529249-6151-1-git-send-email-andy.yan@rock-chips.com>
 <1473529623-6268-1-git-send-email-andy.yan@rock-chips.com>
 <ef2bb52c-26f9-49a5-fe18-538effcd30b0@suse.de>
Message-ID: <16590443.vsxkmsdpMT@phil>

Hi Andreas, Andy,

Am Dienstag, 13. September 2016, 14:23:35 CEST schrieb Andreas F?rber:
> Hi,
> 
> Am 10.09.2016 um 19:47 schrieb Andy Yan:
> > PX5 EVB is designed by Rockchip for automotive field,
> > which intergrated with CVBS(TP2825)/MIPI DSI/CSI/LVDS
> > HDMI video input/output interface, audio codec ES8396,
> > WIFI/BT(on RTL8723BS), Gsensor BMA250E and light&proximity
> > sensor STK3410.
> > 
> > Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
> 
> Most comments from PX3 1/2 apply here, too.

ammended te commit

> > ---
> > 
> > Changes in v1:
> > - board rename
> > - add vendor prefix for i2c interfaced devices
> > 
> >  Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
> >  arch/arm64/boot/dts/rockchip/Makefile              |   1 +
> >  arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts    | 304
> >  +++++++++++++++++++++ 3 files changed, 309 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> > b/Documentation/devicetree/bindings/arm/rockchip.txt index
> > 6da3881..b6f92d6 100644
> > --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> > +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> > @@ -107,6 +107,10 @@ Rockchip platforms device tree bindings
> > 
> >      Required root node properties:
> >        - compatible = "rockchip,r88", "rockchip,rk3368";
> > 
> > +- Rockchip PX5 Evaluation board:
> > +    Required root node properties:
> > +      - compatible = "rockchip,px5-evb", "rockchip,px5",
> > "rockchip,rk3368"; +
> > 
> >  - Rockchip RK3228 Evaluation board:
> >      Required root node properties:
> >       - compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
> > 
> > diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> > b/arch/arm64/boot/dts/rockchip/Makefile index 7037a16..86c74b2 100644
> > --- a/arch/arm64/boot/dts/rockchip/Makefile
> > +++ b/arch/arm64/boot/dts/rockchip/Makefile
> > @@ -1,6 +1,7 @@
> > 
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
> > 
> > +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
> 
> There is no PX5 listed on your English website (yet), but given that you
> have your own rockchip/ folder for arm64 I would encourage you to rename
> to px5-evb.dtb independent of any internal heritage or compatibility the
> SoC has. Compare apq/ipq/msm in qcom.

I prefer to keep it like it is, see comment in px3 patch.

> 
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
> >  
> >  always		:= $(dtb-y)
> > 
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
> > b/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts new file mode 100644
> > index 0000000..be0e915
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
> > @@ -0,0 +1,304 @@
> > +/*
> > + * 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 file 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 file 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.
> > + */
> > +
> > +/dts-v1/;
> > +#include "rk3368.dtsi"
> 
> Similarly suggest a px5.dtsi here.
> 
> > +#include <dt-bindings/input/input.h>
> > +
> > +/ {
> > +	model = "Rockchip PX5 EVB";
> > +	compatible = "rockchip,px5-evb", "rockchip,px5", "rockchip,rk3368";
> > +
> > +	chosen {
> > +		stdout-path = "serial4:115200n8";
> > +	};
> > +
> > +	memory at 0 {
> > +		device_type = "memory";
> > +		reg = <0x0 0x0 0x0 0x80000000>;
> > +	};
> > +
> > +	keys: gpio-keys {
> > +		compatible = "gpio-keys";
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pwr_key>;
> > +
> > +		power {
> > +			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
> > +			label = "GPIO Power";
> > +			linux,code = <KEY_POWER>;
> > +			wakeup-source;
> > +		};
> > +	};
> > +
> > +	vcc_sys: vcc-sys-regulator {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "vcc_sys";
> > +		regulator-min-microvolt = <5000000>;
> > +		regulator-max-microvolt = <5000000>;
> > +		regulator-always-on;
> > +		regulator-boot-on;
> > +	};
> > +};
> > +
> > +&emmc {
> > +	status = "okay";
> > +	bus-width = <8>;
> > +	cap-mmc-highspeed;
> > +	clock-frequency = <150000000>;
> > +	disable-wp;
> > +	keep-power-in-suspend;
> > +	non-removable;
> > +	num-slots = <1>;
> > +	vmmc-supply = <&vcc_io>;
> > +	vqmmc-supply = <&vcc18_flash>;
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_bus8>;
> > +};
> > +
> > +&i2c0 {
> > +	status = "okay";
> > +
> > +	rk808: pmic at 1b {
> > +		compatible = "rockchip,rk808";
> > +		reg = <0x1b>;
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pmic_int>, <&pmic_sleep>;
> > +		interrupt-parent = <&gpio0>;
> > +		interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
> > +		rockchip,system-power-controller;
> > +		vcc1-supply = <&vcc_sys>;
> > +		vcc2-supply = <&vcc_sys>;
> > +		vcc3-supply = <&vcc_sys>;
> > +		vcc4-supply = <&vcc_sys>;
> > +		vcc6-supply = <&vcc_sys>;
> > +		vcc7-supply = <&vcc_sys>;
> > +		vcc8-supply = <&vcc_io>;
> > +		vcc9-supply = <&vcc_sys>;
> > +		vcc10-supply = <&vcc_sys>;
> > +		vcc11-supply = <&vcc_sys>;
> > +		vcc12-supply = <&vcc_io>;
> > +		clock-output-names = "xin32k", "rk808-clkout2";
> > +		#clock-cells = <1>;
> > +
> > +		regulators {
> > +			vdd_cpu: DCDC_REG1 {
> > +				regulator-always-on;
> > +				regulator-boot-on;
> > +				regulator-min-microvolt = <700000>;
> > +				regulator-max-microvolt = <1500000>;
> > +				regulator-name = "vdd_cpu";
> > +			};
> > +
> > +			vdd_log: DCDC_REG2 {
> > +				regulator-always-on;
> > +				regulator-boot-on;
> > +				regulator-min-microvolt = <700000>;
> > +				regulator-max-microvolt = <1500000>;
> > +				regulator-name = "vdd_log";
> > +			};
> > +
> > +			vcc_ddr: DCDC_REG3 {
> > +				regulator-always-on;
> > +				regulator-boot-on;
> > +				regulator-name = "vcc_ddr";
> > +			};
> > +
> > +			vcc_io: DCDC_REG4 {
> > +				regulator-always-on;
> > +				regulator-boot-on;
> > +				regulator-min-microvolt = <3300000>;
> > +				regulator-max-microvolt = <3300000>;
> > +				regulator-name = "vcc_io";
> > +			};
> > +
> > +			vcc18_flash: LDO_REG1 {
> > +				regulator-always-on;
> > +				regulator-boot-on;
> > +				regulator-min-microvolt = <1800000>;
> > +				regulator-max-microvolt = <1800000>;
> > +				regulator-name = "vcc18_flash";
> > +			};
> > +
> > +			vcca_33: LDO_REG2 {
> > +				regulator-always-on;
> > +				regulator-boot-on;
> > +				regulator-min-microvolt = <3300000>;
> > +				regulator-max-microvolt = <3300000>;
> > +				regulator-name = "vcca_33";
> > +			};
> > +
> > +			vdd_10: LDO_REG3 {
> > +				regulator-always-on;
> > +				regulator-boot-on;
> > +				regulator-min-microvolt = <1000000>;
> > +				regulator-max-microvolt = <1000000>;
> > +				regulator-name = "vdd_10";
> > +			};
> > +
> > +			avdd_33: LDO_REG4 {
> > +				regulator-min-microvolt = <3300000>;
> > +				regulator-max-microvolt = <3300000>;
> > +				regulator-name = "avdd_33";
> > +			};
> > +
> > +			vccio_sd: LDO_REG5 {
> > +				regulator-always-on;
> > +				regulator-boot-on;
> > +				regulator-min-microvolt = <1800000>;
> > +				regulator-max-microvolt = <3300000>;
> > +				regulator-name = "vccio_sd";
> > +			};
> > +
> > +			vdd10_lcd: LDO_REG6 {
> > +				regulator-always-on;
> > +				regulator-boot-on;
> > +				regulator-min-microvolt = <1000000>;
> > +				regulator-max-microvolt = <1000000>;
> > +				regulator-name = "vdd10_lcd";
> > +			};
> > +
> > +			vcc_18: LDO_REG7 {
> > +				regulator-always-on;
> > +				regulator-boot-on;
> > +				regulator-min-microvolt = <1800000>;
> > +				regulator-max-microvolt = <1800000>;
> > +				regulator-name = "vcc_18";
> > +			};
> > +
> > +			vcc18_lcd: LDO_REG8 {
> > +				regulator-always-on;
> > +				regulator-boot-on;
> > +				regulator-min-microvolt = <1800000>;
> > +				regulator-max-microvolt = <1800000>;
> > +				regulator-name = "vcc18_lcd";
> > +			};
> > +
> > +			vcc_sd: SWITCH_REG1 {
> > +				regulator-always-on;
> > +				regulator-boot-on;
> > +				regulator-name = "vcc_sd";
> > +			};
> > +
> > +			vcc33_lcd: SWITCH_REG2 {
> > +				regulator-always-on;
> > +				regulator-boot-on;
> > +				regulator-name = "vcc33_lcd";
> > +			};
> > +		};
> > +	};
> > +};
> > +
> > +&i2c1 {
> > +	status = "okay";
> > +
> > +	/* Accelerometer */
> > +	bma250 at 18 {

changed to accelerometer at 18 similar to px3

> > +		compatible = "bosch,bma250";
> > +		reg = <0x18>;
> > +		interrupt-parent = <&gpio2>;
> > +		interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
> > +	};
> > +
> > +	stk3410 at 48 {
> > +		compatible = "sensortek,STK3310";
> > +		reg = <0x48>;
> > +		interrupt-parent = <&gpio2>;
> > +		interrupts = <19 IRQ_TYPE_LEVEL_LOW>;
> > +	};
> > +};
> > +
> > +&i2c2 {
> > +	status = "okay";
> > +
> > +	gsl1680: touchscreen at 40 {
> > +		compatible = "silead,gsl1680";
> > +		reg = <0x40>;
> > +		interrupt-parent = <&gpio3>;
> > +		interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
> > +		power-gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;
> > +		touchscreen-size-x = <800>;
> > +		touchscreen-size-y = <1280>;
> > +		silead,max-fingers = <5>;
> > +	};
> > +};
> > +
> > +&pinctrl {
> > +
> 
> Drop white line?

seems I dropped that already.


> > +	keys {
> > +		pwr_key: pwr-key {
> > +			rockchip,pins = <0 2 RK_FUNC_GPIO &pcfg_pull_none>;
> > +		};
> > +	};
> > +
> > +	pmic {
> > +		pmic_sleep: pmic-sleep {
> > +			rockchip,pins = <0 0 RK_FUNC_2 &pcfg_pull_none>;
> > +		};
> > +
> > +		pmic_int: pmic-int {
> > +			rockchip,pins = <0 5 RK_FUNC_GPIO &pcfg_pull_up>;
> > +		};
> > +	};
> > +};
> > +
> > +&tsadc {
> > +	status = "okay";
> > +	rockchip,hw-tshut-mode = <0>; /* CRU */
> > +	rockchip,hw-tshut-polarity = <1>; /* high */
> > +};
> > +
> > +&uart4 {
> > +	status = "okay";
> > +};
> > +
> > +&usb_host0_ehci {
> > +	status = "okay";
> > +};
> > +
> > +&usb_otg {
> > +	status = "okay";
> > +};
> > +
> > +&wdt {
> > +	status = "okay";
> > +};
> 
> Otherwise formally looks fine.

Thanks for looking at the patch.


Heiko


From shawn.lin at rock-chips.com  Mon Oct 10 05:33:45 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Mon, 10 Oct 2016 20:33:45 +0800
Subject: [PATCH 1/2] ARM: dts: rockchip: Support UHS mode for SD card on
 PopMetal-RK3288 board
Message-ID: <1476102826-7143-1-git-send-email-shawn.lin@rock-chips.com>

PopMetal-RK3288 board could enable SD3.0 card but need vccio_sd
to support the voltage range from 1V8 to 3V3 and we also need to
add more UHS mode here.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 arch/arm/boot/dts/rk3288-popmetal.dts | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3288-popmetal.dts b/arch/arm/boot/dts/rk3288-popmetal.dts
index 23003a2..3831cd5 100644
--- a/arch/arm/boot/dts/rk3288-popmetal.dts
+++ b/arch/arm/boot/dts/rk3288-popmetal.dts
@@ -165,6 +165,10 @@
 	num-slots = <1>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
+	sd-uhs-sdr12;
+	sd-uhs-sdr25;
+	sd-uhs-sdr50;
+	sd-uhs-sdr104;
 	vmmc-supply = <&vcc_sd>;
 	vqmmc-supply = <&vccio_sd>;
 	status = "okay";
@@ -280,7 +284,7 @@
 			vccio_sd: LDO_REG2 {
 				regulator-always-on;
 				regulator-boot-on;
-				regulator-min-microvolt = <3300000>;
+				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <3300000>;
 				regulator-name = "vccio_sd";
 				regulator-state-mem {
-- 
2.3.7




From shawn.lin at rock-chips.com  Mon Oct 10 05:33:46 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Mon, 10 Oct 2016 20:33:46 +0800
Subject: [PATCH 2/2] ARM: dts: rockchip: enable HS200/DDR52 mode for emmc on
 rk3288-popmetal
In-Reply-To: <1476102826-7143-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476102826-7143-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476102826-7143-2-git-send-email-shawn.lin@rock-chips.com>

Enable these two modes to speed up the booting and improve
the performance.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 arch/arm/boot/dts/rk3288-popmetal.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-popmetal.dts b/arch/arm/boot/dts/rk3288-popmetal.dts
index 3831cd5..7500e98 100644
--- a/arch/arm/boot/dts/rk3288-popmetal.dts
+++ b/arch/arm/boot/dts/rk3288-popmetal.dts
@@ -148,6 +148,8 @@
 	cap-mmc-highspeed;
 	disable-wp;
 	non-removable;
+	mmc-ddr-1_8v;
+	mmc-hs200-1_8v;
 	num-slots = <1>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_pwr &emmc_bus8>;
-- 
2.3.7




From ulf.hansson at linaro.org  Mon Oct 10 05:38:01 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Mon, 10 Oct 2016 14:38:01 +0200
Subject: [PATCH v3 1/3] mmc: core: switch to 1V8 or 1V2 for hs400es mode
In-Reply-To: <1475216340-15344-1-git-send-email-shawn.lin@rock-chips.com>
References: <1475216340-15344-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <CAPDyKFrRGee=g4Nc5Cyb1d1O7Gux3DG4GX=Q-izr+kbz5M+YEw@mail.gmail.com>

On 30 September 2016 at 08:18, Shawn Lin <shawn.lin at rock-chips.com> wrote:
> When introducing hs400es, I didn't notice that we haven't
> switched voltage to 1V2 or 1V8 for it. That happens to work
> as the first controller claiming to support hs400es, arasan(5.1),
> which is designed to only support 1V8. So the voltage is fixed to 1V8.
> But it actually is wrong, and will not fit for other host controllers.
> Let's fix it.
>
> Fixes: commit 81ac2af65793ecf ("mmc: core: implement enhanced strobe support")
> Cc: <stable at vger.kernel.org>
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>
> Reviewed-by: Douglas Anderson <dianders at chromium.org>

Thanks, applied for fixes!

Kind regards
Uffe

> ---
>
> Changes in v3:
> - add Doug's tag
>
> Changes in v2:
> - fix copy-paste error, mea culpa
>
>  drivers/mmc/core/mmc.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 3486bc7..f4ed5ac 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1263,6 +1263,16 @@ static int mmc_select_hs400es(struct mmc_card *card)
>                 goto out_err;
>         }
>
> +       if (card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400_1_2V)
> +               err = __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_120);
> +
> +       if (err && card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400_1_8V)
> +               err = __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180);
> +
> +       /* If fails try again during next card power cycle */
> +       if (err)
> +               goto out_err;
> +
>         err = mmc_select_bus_width(card);
>         if (err < 0)
>                 goto out_err;
> --
> 2.3.7
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From ulf.hansson at linaro.org  Mon Oct 10 05:38:08 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Mon, 10 Oct 2016 14:38:08 +0200
Subject: [PATCH v3 2/3] mmc: core: changes frequency to hs_max_dtr when
 selecting hs400es
In-Reply-To: <1475216340-15344-2-git-send-email-shawn.lin@rock-chips.com>
References: <1475216340-15344-1-git-send-email-shawn.lin@rock-chips.com>
 <1475216340-15344-2-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <CAPDyKFrEdgVruJ7aVa6bpaaT3osS78cRO4uVqzLkMZ1FyuMpBQ@mail.gmail.com>

On 30 September 2016 at 08:18, Shawn Lin <shawn.lin at rock-chips.com> wrote:
> Per JESD84-B51 P49, Host need to change frequency to <=52MHz
> after setting HS_TIMING to 0x1, and host may changes frequency
> to <= 200MHz after setting HS_TIMING to 0x3. That means the card
> expects the clock rate to increase from the current used f_init
> (which is less than 400KHz, but still being less than 52MHz) to
> 52MHz, otherwise we find some eMMC devices significantly report
> failure when sending status.
>
> Reported-by: Xiao Yao <xiaoyao at rock-chips.com>
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>
> Reviewed-by: Douglas Anderson <dianders at chromium.org>

Thanks, applied for fixes!

Kind regards
Uffe


> ---
>
> Changes in v3:
> - add Doug's tag and fix the wrong page index of spec
>
> Changes in v2:
> - improve the changelog
>
>  drivers/mmc/core/mmc.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index f4ed5ac..39fc5b2 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1282,6 +1282,8 @@ static int mmc_select_hs400es(struct mmc_card *card)
>         if (err)
>                 goto out_err;
>
> +       mmc_set_clock(host, card->ext_csd.hs_max_dtr);
> +
>         err = mmc_switch_status(card);
>         if (err)
>                 goto out_err;
> --
> 2.3.7
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From ulf.hansson at linaro.org  Mon Oct 10 05:38:16 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Mon, 10 Oct 2016 14:38:16 +0200
Subject: [PATCH v3 3/3] mmc: sdhci-of-arasan: add
 sdhci_arasan_voltage_switch for arasan,5.1
In-Reply-To: <1475216340-15344-3-git-send-email-shawn.lin@rock-chips.com>
References: <1475216340-15344-1-git-send-email-shawn.lin@rock-chips.com>
 <1475216340-15344-3-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <CAPDyKFr4HGkbgOvtyVTUQH90N6SUmirRR-s--2vKPQdg1sEmQg@mail.gmail.com>

On 30 September 2016 at 08:19, Shawn Lin <shawn.lin at rock-chips.com> wrote:
> Per the vendor's requirement, we shouldn't do any setting for
> 1.8V Signaling Enable, otherwise the interaction/behaviour between
> phy and controller will be undefined. Mostly it works fine if we do
> that, but we still see failures. Anyway, let's fix it to meet the
> vendor's requirement. The error log looks like:
>
>  [   93.405085] mmc1: unexpected status 0x800900 after switch
>  [   93.408474] mmc1: switch to bus width 1 failed
>  [   93.408482] mmc1: mmc_select_hs200 failed, error -110
>  [   93.408492] mmc1: error -110 during resume (card was removed?)
>  [   93.408705] PM: resume of devices complete after 213.453 msecs
>
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>
> Acked-by: Adrian Hunter <adrian.hunter at intel.com>
> Reviewed-by: Douglas Anderson <dianders at chromium.org>

Thanks, applied for fixes!

Kind regards
Uffe

> ---
>
> Changes in v3:
> - add tag from Adrian and Doug
>
> Changes in v2: None
>
>  drivers/mmc/host/sdhci-of-arasan.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index da8e40a..1573a8d 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -265,6 +265,28 @@ void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
>         }
>  }
>
> +static int sdhci_arasan_voltage_switch(struct mmc_host *mmc,
> +                                      struct mmc_ios *ios)
> +{
> +       switch (ios->signal_voltage) {
> +       case MMC_SIGNAL_VOLTAGE_180:
> +               /*
> +                * Plese don't switch to 1V8 as arasan,5.1 doesn't
> +                * actually refer to this setting to indicate the
> +                * signal voltage and the state machine will be broken
> +                * actually if we force to enable 1V8. That's something
> +                * like broken quirk but we could work around here.
> +                */
> +               return 0;
> +       case MMC_SIGNAL_VOLTAGE_330:
> +       case MMC_SIGNAL_VOLTAGE_120:
> +               /* We don't support 3V3 and 1V2 */
> +               break;
> +       }
> +
> +       return -EINVAL;
> +}
> +
>  static struct sdhci_ops sdhci_arasan_ops = {
>         .set_clock = sdhci_arasan_set_clock,
>         .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> @@ -661,6 +683,8 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
>
>                 host->mmc_host_ops.hs400_enhanced_strobe =
>                                         sdhci_arasan_hs400_enhanced_strobe;
> +               host->mmc_host_ops.start_signal_voltage_switch =
> +                                       sdhci_arasan_voltage_switch;
>         }
>
>         ret = sdhci_add_host(host);
> --
> 2.3.7
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From shawn.lin at rock-chips.com  Mon Oct 10 05:44:22 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Mon, 10 Oct 2016 20:44:22 +0800
Subject: [PATCH] PM / AVS: rockchip-io: make the log more consistent
Message-ID: <1476103462-7559-1-git-send-email-shawn.lin@rock-chips.com>

When testing SD hotplug automatically, I got bunch of
useless log like this:

[  588.357838] mmc0: card 0007 removed
[  589.492664] rockchip-iodomain ff770000.syscon:io-domains: Setting to 3300000 done
[  589.500698] vccio_sd: ramp_delay not set
[  589.504817] rockchip-iodomain ff770000.syscon:io-domains: Setting to 3300000 done
[  589.669705] rockchip-iodomain ff770000.syscon:io-domains: Setting to 3300000 done
[  589.677593] vccio_sd: ramp_delay not set
[  589.681581] rockchip-iodomain ff770000.syscon:io-domains: Setting to 1800000 done
[  590.032820] dwmmc_rockchip ff0c0000.dwmmc: Successfully tuned phase to 140
[  590.039725] mmc0: new ultra high speed SDR50 SDHC card at address 0007
[  590.046641] mmcblk0: mmc0:0007 SD32G 29.3 GiB
[  590.052163]  mmcblk0: p1

Moreover the code is intent to print the 'uV' for debug but
later print it using dev_info. It looks more like to me that
it should be the real intention of the code. Anyway, let's
mark this verbose log as debug message.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/power/avs/rockchip-io-domain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/avs/rockchip-io-domain.c b/drivers/power/avs/rockchip-io-domain.c
index 01b6d3f..56bce19 100644
--- a/drivers/power/avs/rockchip-io-domain.c
+++ b/drivers/power/avs/rockchip-io-domain.c
@@ -143,7 +143,7 @@ static int rockchip_iodomain_notify(struct notifier_block *nb,
 	if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
 		return NOTIFY_BAD;
 
-	dev_info(supply->iod->dev, "Setting to %d done\n", uV);
+	dev_dbg(supply->iod->dev, "Setting to %d done\n", uV);
 	return NOTIFY_OK;
 }
 
-- 
2.3.7




From robh at kernel.org  Mon Oct 10 07:16:39 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 10 Oct 2016 09:16:39 -0500
Subject: [PATCH v4] PCI: rockchip: Support property to specify the link
 capability
In-Reply-To: <1475743800-1036-1-git-send-email-shawn.lin@rock-chips.com>
References: <1475743800-1036-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <20161010141639.GA22113@rob-hp-laptop>

On Thu, Oct 06, 2016 at 04:50:00PM +0800, Shawn Lin wrote:
> From: Brian Norris <briannorris at chromium.org>
> 
> rk3399 supports PCIe 2.x link speeds marginally at best, and on some
> boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500
> ms waiting for training that will never happen, let's add a property
> from devicetree to specify link capability.
> 
> Signed-off-by: Brian Norris <briannorris at chromium.org>
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> 
> ---
> 
> Changes in v4:
> - define link_gen as u32
> - elaborate more for rockchip,max-link-speed on doc
> 
> Changes in v3:
> - Cast a warning for invalid max link speed and use gen1 for it.
>   That looks better than v2. (Suggested by Brian)
> 
> Changes in v2:
> - rename the property to rockchip,max-link-speed according to
>   Bjorn's recommendation and take some bits from imx6q-pcie to
>   make this requirement more consisent.
> 
>  .../devicetree/bindings/pci/rockchip-pcie.txt      |  4 ++
>  drivers/pci/host/pcie-rockchip.c                   | 63 ++++++++++++++--------
>  2 files changed, 44 insertions(+), 23 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> index ba67b39..9bb29de 100644
> --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> @@ -42,6 +42,10 @@ Required properties:
>  Optional Property:
>  - ep-gpios: contain the entry for pre-reset gpio
>  - num-lanes: number of lanes to use
> +- rockchip,max-link-speed: Specify PCI gen for link capability. Must
> +	be '2' for gen2, and '1' for gen1, otherwise will default to gen1.
> +	For backward compatibility, if this property isn't assigned, we
> +	use gen2 by default.

Defaults to gen1 or gen2?

Let's drop rockchip and make this a common property. 

>  - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
>  - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe.
>  - vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe.


From ruben.ziegler at tuningtalents.com  Sun Oct  9 21:26:10 2016
From: ruben.ziegler at tuningtalents.com (FedEx International MailService)
Date: Mon, 10 Oct 2016 04:26:10 +0000
Subject: ROCK, Courier was unable to deliver the parcel, ID00000296927
Message-ID: <e9acdbc3f18960f76954ba65d1866d65@tuningtalents.com>

Dear Rock,

We could not deliver your parcel.
Delivery Label is attached to this email.

Thanks and best regards,
Ruben Ziegler,
Delivery Manager.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Label_00000296927.zip
Type: application/zip
Size: 8120 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20161010/9b5cc945/attachment-0001.zip>

From briannorris at chromium.org  Mon Oct 10 10:20:47 2016
From: briannorris at chromium.org (Brian Norris)
Date: Mon, 10 Oct 2016 10:20:47 -0700
Subject: [PATCH v4] PCI: rockchip: Support property to specify the link
 capability
In-Reply-To: <20161010141639.GA22113@rob-hp-laptop>
References: <1475743800-1036-1-git-send-email-shawn.lin@rock-chips.com>
 <20161010141639.GA22113@rob-hp-laptop>
Message-ID: <20161010172046.GA30803@localhost>

Hi Rob,

On Mon, Oct 10, 2016 at 09:16:39AM -0500, Rob Herring wrote:
> On Thu, Oct 06, 2016 at 04:50:00PM +0800, Shawn Lin wrote:
> > From: Brian Norris <briannorris at chromium.org>
> > 
> > rk3399 supports PCIe 2.x link speeds marginally at best, and on some
> > boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500
> > ms waiting for training that will never happen, let's add a property
> > from devicetree to specify link capability.
> > 
> > Signed-off-by: Brian Norris <briannorris at chromium.org>
> > Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> > 
> > ---
> > 
> > Changes in v4:
> > - define link_gen as u32
> > - elaborate more for rockchip,max-link-speed on doc
> > 
> > Changes in v3:
> > - Cast a warning for invalid max link speed and use gen1 for it.
> >   That looks better than v2. (Suggested by Brian)
> > 
> > Changes in v2:
> > - rename the property to rockchip,max-link-speed according to
> >   Bjorn's recommendation and take some bits from imx6q-pcie to
> >   make this requirement more consisent.
> > 
> >  .../devicetree/bindings/pci/rockchip-pcie.txt      |  4 ++
> >  drivers/pci/host/pcie-rockchip.c                   | 63 ++++++++++++++--------
> >  2 files changed, 44 insertions(+), 23 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > index ba67b39..9bb29de 100644
> > --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > @@ -42,6 +42,10 @@ Required properties:
> >  Optional Property:
> >  - ep-gpios: contain the entry for pre-reset gpio
> >  - num-lanes: number of lanes to use
> > +- rockchip,max-link-speed: Specify PCI gen for link capability. Must
> > +	be '2' for gen2, and '1' for gen1, otherwise will default to gen1.
> > +	For backward compatibility, if this property isn't assigned, we
> > +	use gen2 by default.
> 
> Defaults to gen1 or gen2?

The wording is a bit confusing, but I think Shawn intended for:
(a) if no property is provided, default to the maximum supported (i.e.,
    gen2), to keep backward compatibility
(b) if a property is provided, but it doesn't contain 1 or 2, just
    default to 1

I already disagreed with (b) (and suggested we make this an error
instead; we have no business accepting malformed device trees here IMO).
Alternatives to clear up the confusion Rob pointed out might include:
(1) explaining this better (i.e., what does "otherwise" mean in the
    original sentence?)
(2) changing this to uniformly default to 2 (if someone used an
    unsupported value, treat it as if the property wasn't there at all)
(3) reject incorrect values outright (so we don't have this fuzzy middle
    ground at all)

> Let's drop rockchip and make this a common property. 

As in, handle this in some generic/common way? AFAICT, there's really
no way to do that given the current structure of PCIe handling (and the
nature of these kinds of limitations).

Or, do you just mean make the name common? (i.e,. "max-link-speed"
instead of "rockchip,max-link-speed")

Also for the record, Shawn already sent v5 before your comments.
Presumably he'll need a v6 then...

Brian

> >  - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
> >  - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe.
> >  - vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe.


From dianders at chromium.org  Mon Oct 10 11:47:57 2016
From: dianders at chromium.org (Douglas Anderson)
Date: Mon, 10 Oct 2016 11:47:57 -0700
Subject: [PATCH] timers: Fix usleep_range() in the context of wake_up_process()
Message-ID: <1476125277-6061-1-git-send-email-dianders@chromium.org>

Users of usleep_range() expect that it will _never_ return in less time
than the minimum passed parameter.  However, nothing in any of the code
ensures this.  Specifically:

usleep_range() => do_usleep_range() => schedule_hrtimeout_range() =>
schedule_hrtimeout_range_clock() just ends up calling schedule() with an
appropriate timeout set using the hrtimer.  If someone else happens to
wake up our task then we'll happily return from usleep_range() early.

msleep() already has code to handle this case since it will loop as long
as there was still time left.  usleep_range() had no such loop.

The problem is is easily demonstrated with a small bit of test code:

  static int usleep_test_task(void *data)
  {
    atomic_t *done = data;
    ktime_t start, end;

    start = ktime_get();
    usleep_range(50000, 100000);
    end = ktime_get();
    pr_info("Requested 50000 - 100000 us.  Actually slept for %llu us\n",
      (unsigned long long)ktime_to_us(ktime_sub(end, start)));
    atomic_set(done, 1);

    return 0;
  }

  static void run_usleep_test(void)
  {
    struct task_struct *t;
    atomic_t done;

    atomic_set(&done, 0);

    t = kthread_run(usleep_test_task, &done, "usleep_test_task");
    while (!atomic_read(&done)) {
      wake_up_process(t);
      udelay(1000);
    }
    kthread_stop(t);
  }

If you run the above code without this patch you get things like:
  Requested 50000 - 100000 us.  Actually slept for 967 us

If you run the above code _with_ this patch, you get:
  Requested 50000 - 100000 us.  Actually slept for 50001 us

Presumably this problem was not detected before because:
- It's not terribly common to use wake_up_process() directly.
- Other ways for processes to wake up are not typically mixed with
  usleep_range().
- There aren't lotsof places that use usleep_range(), since many people
  call either msleep() or udelay().

Reported-by: Tao Huang <huangtao at rock-chips.com>
Signed-off-by: Douglas Anderson <dianders at chromium.org>
---
 kernel/time/timer.c | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 32bf6f75a8fe..ab03c7e403a4 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1898,12 +1898,29 @@ EXPORT_SYMBOL(msleep_interruptible);
 
 static void __sched do_usleep_range(unsigned long min, unsigned long max)
 {
+	ktime_t start, end;
 	ktime_t kmin;
 	u64 delta;
+	unsigned long elapsed = 0;
+	int ret;
+
+	start = ktime_get();
+	do {
+		kmin = ktime_set(0, min * NSEC_PER_USEC);
+		delta = (u64)(max - min) * NSEC_PER_USEC;
+		ret = schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
+
+		/*
+		 * If schedule_hrtimeout_range() returns 0 then we actually
+		 * hit the timeout. If not then we need to re-calculate the
+		 * new timeout ourselves.
+		 */
+		if (ret == 0)
+			break;
 
-	kmin = ktime_set(0, min * NSEC_PER_USEC);
-	delta = (u64)(max - min) * NSEC_PER_USEC;
-	schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
+		end = ktime_get();
+		elapsed = ktime_to_us(ktime_sub(end, start));
+	} while (elapsed < min);
 }
 
 /**
-- 
2.8.0.rc3.226.g39d4020



From robh at kernel.org  Mon Oct 10 12:34:10 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 10 Oct 2016 14:34:10 -0500
Subject: [PATCH v4] PCI: rockchip: Support property to specify the link
 capability
In-Reply-To: <20161010172046.GA30803@localhost>
References: <1475743800-1036-1-git-send-email-shawn.lin@rock-chips.com>
 <20161010141639.GA22113@rob-hp-laptop> <20161010172046.GA30803@localhost>
Message-ID: <CAL_Jsq+p3Vnw0U4ja09HRbfJ_ECzZjHCGmajAoVRdpPZrM6KTA@mail.gmail.com>

On Mon, Oct 10, 2016 at 12:20 PM, Brian Norris <briannorris at chromium.org> wrote:
> Hi Rob,
>
> On Mon, Oct 10, 2016 at 09:16:39AM -0500, Rob Herring wrote:
>> On Thu, Oct 06, 2016 at 04:50:00PM +0800, Shawn Lin wrote:
>> > From: Brian Norris <briannorris at chromium.org>
>> >
>> > rk3399 supports PCIe 2.x link speeds marginally at best, and on some
>> > boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500
>> > ms waiting for training that will never happen, let's add a property
>> > from devicetree to specify link capability.
>> >
>> > Signed-off-by: Brian Norris <briannorris at chromium.org>
>> > Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>> >
>> > ---
>> >
>> > Changes in v4:
>> > - define link_gen as u32
>> > - elaborate more for rockchip,max-link-speed on doc
>> >
>> > Changes in v3:
>> > - Cast a warning for invalid max link speed and use gen1 for it.
>> >   That looks better than v2. (Suggested by Brian)
>> >
>> > Changes in v2:
>> > - rename the property to rockchip,max-link-speed according to
>> >   Bjorn's recommendation and take some bits from imx6q-pcie to
>> >   make this requirement more consisent.
>> >
>> >  .../devicetree/bindings/pci/rockchip-pcie.txt      |  4 ++
>> >  drivers/pci/host/pcie-rockchip.c                   | 63 ++++++++++++++--------
>> >  2 files changed, 44 insertions(+), 23 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
>> > index ba67b39..9bb29de 100644
>> > --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
>> > +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
>> > @@ -42,6 +42,10 @@ Required properties:
>> >  Optional Property:
>> >  - ep-gpios: contain the entry for pre-reset gpio
>> >  - num-lanes: number of lanes to use
>> > +- rockchip,max-link-speed: Specify PCI gen for link capability. Must
>> > +   be '2' for gen2, and '1' for gen1, otherwise will default to gen1.
>> > +   For backward compatibility, if this property isn't assigned, we
>> > +   use gen2 by default.
>>
>> Defaults to gen1 or gen2?
>
> The wording is a bit confusing, but I think Shawn intended for:
> (a) if no property is provided, default to the maximum supported (i.e.,
>     gen2), to keep backward compatibility
> (b) if a property is provided, but it doesn't contain 1 or 2, just
>     default to 1
>
> I already disagreed with (b) (and suggested we make this an error
> instead; we have no business accepting malformed device trees here IMO).
> Alternatives to clear up the confusion Rob pointed out might include:
> (1) explaining this better (i.e., what does "otherwise" mean in the
>     original sentence?)
> (2) changing this to uniformly default to 2 (if someone used an
>     unsupported value, treat it as if the property wasn't there at all)
> (3) reject incorrect values outright (so we don't have this fuzzy middle
>     ground at all)

Sounds good.

>> Let's drop rockchip and make this a common property.
>
> As in, handle this in some generic/common way? AFAICT, there's really
> no way to do that given the current structure of PCIe handling (and the
> nature of these kinds of limitations).
>
> Or, do you just mean make the name common? (i.e,. "max-link-speed"
> instead of "rockchip,max-link-speed")

Right, just the name and document in a common spot. Could be a simple
helper function that drivers can call as well.

Rob


From andi at lisas.de  Mon Oct 10 12:53:56 2016
From: andi at lisas.de (Andreas Mohr)
Date: Mon, 10 Oct 2016 21:53:56 +0200
Subject: [PATCH] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <1476125277-6061-1-git-send-email-dianders@chromium.org>
References: <1476125277-6061-1-git-send-email-dianders@chromium.org>
Message-ID: <20161010195356.GA30513@rhlx01.hs-esslingen.de>

Hi,

On Mon, Oct 10, 2016 at 11:47:57AM -0700, Douglas Anderson wrote:
> Users of usleep_range() expect that it will _never_ return in less time
> than the minimum passed parameter.  However, nothing in any of the code
> ensures this.  Specifically:

Ouch (aka: good catch! - by the reporter, though... ;)


> diff --git a/kernel/time/timer.c b/kernel/time/timer.c
> index 32bf6f75a8fe..ab03c7e403a4 100644
> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
> @@ -1898,12 +1898,29 @@ EXPORT_SYMBOL(msleep_interruptible);
>  
>  static void __sched do_usleep_range(unsigned long min, unsigned long max)
>  {
> +	ktime_t start, end;
>  	ktime_t kmin;
>  	u64 delta;
> +	unsigned long elapsed = 0;
> +	int ret;
> +
> +	start = ktime_get();
> +	do {
> +		kmin = ktime_set(0, min * NSEC_PER_USEC);
> +		delta = (u64)(max - min) * NSEC_PER_USEC;
> +		ret = schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
> +
> +		/*
> +		 * If schedule_hrtimeout_range() returns 0 then we actually
> +		 * hit the timeout. If not then we need to re-calculate the
> +		 * new timeout ourselves.
> +		 */
> +		if (ret == 0)
> +			break;
>  
> -	kmin = ktime_set(0, min * NSEC_PER_USEC);
> -	delta = (u64)(max - min) * NSEC_PER_USEC;
> -	schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
> +		end = ktime_get();
> +		elapsed = ktime_to_us(ktime_sub(end, start));
> +	} while (elapsed < min);

Some thoughts:
- max >= min pre-condition is validated somewhere, I'd hope?
  (somewhere in outer API frame?)
> +		delta = (u64)(max - min) * NSEC_PER_USEC;

- there is a domain transition in there, **within** the repeated loop:
> +		elapsed = ktime_to_us(ktime_sub(end, start));
  -->
> +	} while (elapsed < min);
  should likely be made to be able to
  directly compare a *non-converted* "elapsed" value
  (IIRC there's an API such as ktime_before()).
  One could argue that the "repeat" case is the non-likely case
  (thus the conversion should possibly not be done before
  actually being required),
  however I guess it's exactly hitting the non-likely cases
  which will contribute towards
  non-predictable, non-deterministic latency behaviour of
  a code path
  (think RT requirements)

Thanks,

Andreas Mohr


From briannorris at chromium.org  Mon Oct 10 13:04:01 2016
From: briannorris at chromium.org (Brian Norris)
Date: Mon, 10 Oct 2016 13:04:01 -0700
Subject: [PATCH] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <1476125277-6061-1-git-send-email-dianders@chromium.org>
References: <1476125277-6061-1-git-send-email-dianders@chromium.org>
Message-ID: <20161010200400.GA9230@localhost>

Hi Doug,

On Mon, Oct 10, 2016 at 11:47:57AM -0700, Doug Anderson wrote:
> diff --git a/kernel/time/timer.c b/kernel/time/timer.c
> index 32bf6f75a8fe..ab03c7e403a4 100644
> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
> @@ -1898,12 +1898,29 @@ EXPORT_SYMBOL(msleep_interruptible);
>  
>  static void __sched do_usleep_range(unsigned long min, unsigned long max)
>  {
> +	ktime_t start, end;
>  	ktime_t kmin;
>  	u64 delta;
> +	unsigned long elapsed = 0;
> +	int ret;
> +
> +	start = ktime_get();
> +	do {
> +		kmin = ktime_set(0, min * NSEC_PER_USEC);

I believe 'min' is unmodified throughout, and therefore 'kmin' is
computed to be the same minimum timeout in each loop. Shouldn't this be
decreasing on each iteration of the loop? (i.e., either your compute
'kmin' differently here, or you recompute 'min' based on the elapsed
time?)

> +		delta = (u64)(max - min) * NSEC_PER_USEC;
> +		ret = schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
> +
> +		/*
> +		 * If schedule_hrtimeout_range() returns 0 then we actually
> +		 * hit the timeout. If not then we need to re-calculate the
> +		 * new timeout ourselves.
> +		 */
> +		if (ret == 0)
> +			break;
>  
> -	kmin = ktime_set(0, min * NSEC_PER_USEC);
> -	delta = (u64)(max - min) * NSEC_PER_USEC;
> -	schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
> +		end = ktime_get();
> +		elapsed = ktime_to_us(ktime_sub(end, start));
> +	} while (elapsed < min);

I think Andreas had similar comments, but it seemed to me like
ktime_before() might be nicer. But (as Andreas did) you might get into
(premature?) micro-optimizations down that path, and I'm certainly not
an expert there.

>  }
>  
>  /**

Brian


From dianders at chromium.org  Mon Oct 10 13:12:39 2016
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 10 Oct 2016 13:12:39 -0700
Subject: [PATCH] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <20161010200400.GA9230@localhost>
References: <1476125277-6061-1-git-send-email-dianders@chromium.org>
 <20161010200400.GA9230@localhost>
Message-ID: <CAD=FV=XfQB=BG4o08hmjd5waOHo=PsW=RYhyDSY_kbAJcE6spQ@mail.gmail.com>

Hi,

On Mon, Oct 10, 2016 at 1:04 PM, Brian Norris <briannorris at chromium.org> wrote:
> Hi Doug,
>
> On Mon, Oct 10, 2016 at 11:47:57AM -0700, Doug Anderson wrote:
>> diff --git a/kernel/time/timer.c b/kernel/time/timer.c
>> index 32bf6f75a8fe..ab03c7e403a4 100644
>> --- a/kernel/time/timer.c
>> +++ b/kernel/time/timer.c
>> @@ -1898,12 +1898,29 @@ EXPORT_SYMBOL(msleep_interruptible);
>>
>>  static void __sched do_usleep_range(unsigned long min, unsigned long max)
>>  {
>> +     ktime_t start, end;
>>       ktime_t kmin;
>>       u64 delta;
>> +     unsigned long elapsed = 0;
>> +     int ret;
>> +
>> +     start = ktime_get();
>> +     do {
>> +             kmin = ktime_set(0, min * NSEC_PER_USEC);
>
> I believe 'min' is unmodified throughout, and therefore 'kmin' is
> computed to be the same minimum timeout in each loop. Shouldn't this be
> decreasing on each iteration of the loop? (i.e., either your compute
> 'kmin' differently here, or you recompute 'min' based on the elapsed
> time?)

Yes, I stupidly changed something at the last second and then didn't
test again after my stupid change.  Fix coming soon with all comments
addressed.  Sorry for posting broken code.  :( :( :(

-Doug


From heiko at sntech.de  Mon Oct 10 13:15:50 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 10 Oct 2016 22:15:50 +0200
Subject: [PATCH] PM / AVS: rockchip-io: make the log more consistent
In-Reply-To: <1476103462-7559-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476103462-7559-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1883054.D2Rm2X9N2G@phil>

Am Montag, 10. Oktober 2016, 20:44:22 CEST schrieb Shawn Lin:
> When testing SD hotplug automatically, I got bunch of
> useless log like this:
> 
> [  588.357838] mmc0: card 0007 removed
> [  589.492664] rockchip-iodomain ff770000.syscon:io-domains: Setting to
> 3300000 done [  589.500698] vccio_sd: ramp_delay not set
> [  589.504817] rockchip-iodomain ff770000.syscon:io-domains: Setting to
> 3300000 done [  589.669705] rockchip-iodomain ff770000.syscon:io-domains:
> Setting to 3300000 done [  589.677593] vccio_sd: ramp_delay not set
> [  589.681581] rockchip-iodomain ff770000.syscon:io-domains: Setting to
> 1800000 done [  590.032820] dwmmc_rockchip ff0c0000.dwmmc: Successfully
> tuned phase to 140 [  590.039725] mmc0: new ultra high speed SDR50 SDHC
> card at address 0007 [  590.046641] mmcblk0: mmc0:0007 SD32G 29.3 GiB
> [  590.052163]  mmcblk0: p1
> 
> Moreover the code is intent to print the 'uV' for debug but
> later print it using dev_info. It looks more like to me that
> it should be the real intention of the code. Anyway, let's
> mark this verbose log as debug message.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

reducing the amount of logs, especially for information not generally needed 
looks sane

Reviewed-by: Heiko Stuebner <heiko at sntech.de>

> ---
> 
>  drivers/power/avs/rockchip-io-domain.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/avs/rockchip-io-domain.c
> b/drivers/power/avs/rockchip-io-domain.c index 01b6d3f..56bce19 100644
> --- a/drivers/power/avs/rockchip-io-domain.c
> +++ b/drivers/power/avs/rockchip-io-domain.c
> @@ -143,7 +143,7 @@ static int rockchip_iodomain_notify(struct
> notifier_block *nb, if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
>  		return NOTIFY_BAD;
> 
> -	dev_info(supply->iod->dev, "Setting to %d done\n", uV);
> +	dev_dbg(supply->iod->dev, "Setting to %d done\n", uV);
>  	return NOTIFY_OK;
>  }




From heiko at sntech.de  Mon Oct 10 13:28:49 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 10 Oct 2016 22:28:49 +0200
Subject: [PATCH] thermal: rockchip: improve the warning log
In-Reply-To: <1476017358-26143-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476017358-26143-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1729478.KIY7mRhFMh@phil>

Am Sonntag, 9. Oktober 2016, 20:49:18 CEST schrieb Shawn Lin:
> There is no necessary to print warning agian and

It is not necessary to print a warning again and ...

> again if we don't add rockchip,grf for dt, otherwise
> I saw the following log when doning suspend-2-resume.
								^ doing

> We only need to print it once when parsing dt. It looks
> quite trivial but the log is apparently verbose.
> 
> [   26.615415] PM: early resume of devices complete after 1.539 msecs
> [   26.622002] rk_tsadcv2_initialize: Missing rockchip,grf property
> [   26.629359] rk_gmac-dwmac ff290000.ethernet: init for RGMII
> [   26.639794] PM: resume of devices complete after 18.109 msecs
> [   26.646925] Restarting tasks ... done.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> ---
> 
>  drivers/thermal/rockchip_thermal.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/thermal/rockchip_thermal.c
> b/drivers/thermal/rockchip_thermal.c index e227a9f..b811b0f 100644
> --- a/drivers/thermal/rockchip_thermal.c
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -524,11 +524,6 @@ static void rk_tsadcv2_initialize(struct regmap *grf,
> void __iomem *regs, regs + TSADCV2_AUTO_PERIOD_HT);
>  	writel_relaxed(TSADCV2_HIGHT_TSHUT_DEBOUNCE_COUNT,
>  		       regs + TSADCV2_HIGHT_TSHUT_DEBOUNCE);
> -
> -	if (IS_ERR(grf)) {
> -		pr_warn("%s: Missing rockchip,grf property\n", __func__);
> -		return;
> -	}

dropping the pr_warn here is ok, as the v2 tsadc does not access it anyway

>  }
> 
>  /**
> @@ -971,6 +966,8 @@ static int rockchip_configure_from_dt(struct device
> *dev, * need this property.
>  	 */
>  	thermal->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
> +	if (IS_ERR(thermal->grf))
> +		dev_warn(dev, "Missing rockchip,grf property\n");

but I'm not sure if we need this warning here. As said above v2-tsadc does not 
need it at all and the v3 tsadc seems to work around a missing grf regmap?

So maybe don't do any warning at all or something like that?

Btw. it also seems like the binding txt document is missing an entry for the 
rockchip,grf property. So maybe you could do another patch to add that 
optional property to the binding doc?


Heiko


From andi at lisas.de  Mon Oct 10 13:42:14 2016
From: andi at lisas.de (Andreas Mohr)
Date: Mon, 10 Oct 2016 22:42:14 +0200
Subject: [PATCH] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <CAD=FV=XfQB=BG4o08hmjd5waOHo=PsW=RYhyDSY_kbAJcE6spQ@mail.gmail.com>
References: <1476125277-6061-1-git-send-email-dianders@chromium.org>
 <20161010200400.GA9230@localhost>
 <CAD=FV=XfQB=BG4o08hmjd5waOHo=PsW=RYhyDSY_kbAJcE6spQ@mail.gmail.com>
Message-ID: <20161010204214.GA3100@rhlx01.hs-esslingen.de>

On Mon, Oct 10, 2016 at 01:12:39PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Mon, Oct 10, 2016 at 1:04 PM, Brian Norris <briannorris at chromium.org> wrote:
> > I believe 'min' is unmodified throughout, and therefore 'kmin' is
> > computed to be the same minimum timeout in each loop. Shouldn't this be
> > decreasing on each iteration of the loop? (i.e., either your compute
> > 'kmin' differently here, or you recompute 'min' based on the elapsed
> > time?)
> 
> Yes, I stupidly changed something at the last second and then didn't
> test again after my stupid change.  Fix coming soon with all comments
> addressed.  Sorry for posting broken code.  :( :( :(

With a loop style that is actively re-calculating things,
such implementations should then not fall into the trap of
basing the "next" value on "current" time,
thereby bogusly accumulating scheduling-based delays
with each new loop iteration etc.
(i.e., things should still be based on hard, precise termination according to
an *initially* calculated, *absolute*, *minimum* expiry time).

Andreas Mohr

-- 
GNU/Linux. It's not the software that's free, it's you.


From andi at lisas.de  Mon Oct 10 13:47:37 2016
From: andi at lisas.de (Andreas Mohr)
Date: Mon, 10 Oct 2016 22:47:37 +0200
Subject: [PATCH] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <20161010200400.GA9230@localhost>
References: <1476125277-6061-1-git-send-email-dianders@chromium.org>
 <20161010200400.GA9230@localhost>
Message-ID: <20161010204737.GB3100@rhlx01.hs-esslingen.de>

Hi,

On Mon, Oct 10, 2016 at 01:04:01PM -0700, Brian Norris wrote:
> Hi Doug,
> 
> On Mon, Oct 10, 2016 at 11:47:57AM -0700, Doug Anderson wrote:
> > +		end = ktime_get();
> > +		elapsed = ktime_to_us(ktime_sub(end, start));
> > +	} while (elapsed < min);
> 
> I think Andreas had similar comments, but it seemed to me like
> ktime_before() might be nicer. But (as Andreas did) you might get into
> (premature?) micro-optimizations down that path, and I'm certainly not
> an expert there.

I'd justify it this way:
orientation/type of input data is rather irrelevant -
all that matters is how you want to treat things in your *inner handling* -
and if that happens to be ktime-based
(as is usually - if not pretty much always - the case within kernel code),
then it ought to be that way,
*consistently* (to avoid conversion transition overhead).

Andreas Mohr


From dianders at chromium.org  Mon Oct 10 14:04:02 2016
From: dianders at chromium.org (Douglas Anderson)
Date: Mon, 10 Oct 2016 14:04:02 -0700
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
Message-ID: <1476133442-17757-1-git-send-email-dianders@chromium.org>

Users of usleep_range() expect that it will _never_ return in less time
than the minimum passed parameter.  However, nothing in any of the code
ensures this.  Specifically:

usleep_range() => do_usleep_range() => schedule_hrtimeout_range() =>
schedule_hrtimeout_range_clock() just ends up calling schedule() with an
appropriate timeout set using the hrtimer.  If someone else happens to
wake up our task then we'll happily return from usleep_range() early.

msleep() already has code to handle this case since it will loop as long
as there was still time left.  usleep_range() had no such loop.

The problem is is easily demonstrated with a small bit of test code:

  static int usleep_test_task(void *data)
  {
    atomic_t *done = data;
    ktime_t start, end;

    start = ktime_get();
    usleep_range(50000, 100000);
    end = ktime_get();
    pr_info("Requested 50000 - 100000 us.  Actually slept for %llu us\n",
      (unsigned long long)ktime_to_us(ktime_sub(end, start)));
    atomic_set(done, 1);

    return 0;
  }

  static void run_usleep_test(void)
  {
    struct task_struct *t;
    atomic_t done;

    atomic_set(&done, 0);

    t = kthread_run(usleep_test_task, &done, "usleep_test_task");
    while (!atomic_read(&done)) {
      wake_up_process(t);
      udelay(1000);
    }
    kthread_stop(t);
  }

If you run the above code without this patch you get things like:
  Requested 50000 - 100000 us.  Actually slept for 967 us

If you run the above code _with_ this patch, you get:
  Requested 50000 - 100000 us.  Actually slept for 50001 us

Presumably this problem was not detected before because:
- It's not terribly common to use wake_up_process() directly.
- Other ways for processes to wake up are not typically mixed with
  usleep_range().
- There aren't lots of places that use usleep_range(), since many people
  call either msleep() or udelay().

Reported-by: Tao Huang <huangtao at rock-chips.com>
Signed-off-by: Douglas Anderson <dianders at chromium.org>
---
Changes in v2:
- Fixed stupid bug that snuck in before posting
- Use ktime_before
- Remove delta from the loop

NOTE: Tested against 4.4 tree w/ backports.  I'm trying to get myself
up and running with mainline again to test there now but it might be a
little while.  Hopefully this time I don't shoot myself in the foot.

 kernel/time/timer.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 32bf6f75a8fe..219439efd56a 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1898,12 +1898,28 @@ EXPORT_SYMBOL(msleep_interruptible);
 
 static void __sched do_usleep_range(unsigned long min, unsigned long max)
 {
+	ktime_t now, end;
 	ktime_t kmin;
 	u64 delta;
+	int ret;
 
-	kmin = ktime_set(0, min * NSEC_PER_USEC);
+	now = ktime_get();
+	end = ktime_add_us(now, min);
 	delta = (u64)(max - min) * NSEC_PER_USEC;
-	schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
+	do {
+		kmin = ktime_sub(end, now);
+		ret = schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
+
+		/*
+		 * If schedule_hrtimeout_range() returns 0 then we actually
+		 * hit the timeout. If not then we need to re-calculate the
+		 * new timeout ourselves.
+		 */
+		if (ret == 0)
+			break;
+
+		now = ktime_get();
+	} while (ktime_before(now, end));
 }
 
 /**
-- 
2.8.0.rc3.226.g39d4020



From dianders at chromium.org  Mon Oct 10 14:16:48 2016
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 10 Oct 2016 14:16:48 -0700
Subject: [PATCH] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <20161010195356.GA30513@rhlx01.hs-esslingen.de>
References: <1476125277-6061-1-git-send-email-dianders@chromium.org>
 <20161010195356.GA30513@rhlx01.hs-esslingen.de>
Message-ID: <CAD=FV=WmjQwt638sG5_d0pnCzjhvZM+YwPeETnh7Mp79F2oE0w@mail.gmail.com>

Hi,

On Mon, Oct 10, 2016 at 12:53 PM, Andreas Mohr <andi at lisas.de> wrote:
> Some thoughts:
> - max >= min pre-condition is validated somewhere, I'd hope?
>   (somewhere in outer API frame?)

I don't think this is validated, but it's not a new problem.  My patch
doesn't attempt to solve this.  A future patch could, though.  You can
speculate on whether a WARN_ON would be better or some type of
friendly warning.

-Doug


From heiko at sntech.de  Mon Oct 10 14:30:23 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 10 Oct 2016 23:30:23 +0200
Subject: [PATCH] ARM: dts: rockchip: remove always-on and boot-on from
 vcc_sd for px3-evb
In-Reply-To: <1474589350-10877-1-git-send-email-shawn.lin@rock-chips.com>
References: <1474589350-10877-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <7170729.x9hBlEviIo@phil>

Am Freitag, 23. September 2016, 08:09:10 CEST schrieb Shawn Lin:
> Please don't add these for vcc_sd, and mmc-core/driver will control
> it. Otherwise, it will waste energy even without sdmmc in slot.
> 
> Moreover, it will causes a bug:
> If we insert/remove sd card, we could see
> [9.337271] mmc0: new ultra high speed SDR25 SDHC card at address 0007
> [9.345144] mmcblk0: mmc0:0007 SD32G 29.3 GiB
> 
> This is okay for normal sd insert/remove test, but when I debug some
> issues for sdmmc, I did unbind/bind test. And there is a interesting
> phenomenon when we bind the driver again:
> [58.314069] mmc0: new high speed SDHC card at address 0007
> [58.320282] mmcblk0: mmc0:0007 SD32G 29.3 GiB
> 
> So the sd card could just support high speed without power cycle
> since the vcc_sd is always on, which makes the sd card fail to
> reinit its internal ocr mask.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

applied for 4.10


Thanks
Heiko


From dianders at chromium.org  Mon Oct 10 15:39:06 2016
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 10 Oct 2016 15:39:06 -0700
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <1476133442-17757-1-git-send-email-dianders@chromium.org>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
Message-ID: <CAD=FV=WCe==Dx_qRM3nKz-sc_7zxbNyOGK3HuA02oG1A9Fxwdg@mail.gmail.com>

Hi,

On Mon, Oct 10, 2016 at 2:04 PM, Douglas Anderson <dianders at chromium.org> wrote:
> Users of usleep_range() expect that it will _never_ return in less time
> than the minimum passed parameter.  However, nothing in any of the code
> ensures this.  Specifically:
>
> usleep_range() => do_usleep_range() => schedule_hrtimeout_range() =>
> schedule_hrtimeout_range_clock() just ends up calling schedule() with an
> appropriate timeout set using the hrtimer.  If someone else happens to
> wake up our task then we'll happily return from usleep_range() early.
>
> msleep() already has code to handle this case since it will loop as long
> as there was still time left.  usleep_range() had no such loop.
>
> The problem is is easily demonstrated with a small bit of test code:
>
>   static int usleep_test_task(void *data)
>   {
>     atomic_t *done = data;
>     ktime_t start, end;
>
>     start = ktime_get();
>     usleep_range(50000, 100000);
>     end = ktime_get();
>     pr_info("Requested 50000 - 100000 us.  Actually slept for %llu us\n",
>       (unsigned long long)ktime_to_us(ktime_sub(end, start)));
>     atomic_set(done, 1);
>
>     return 0;
>   }
>
>   static void run_usleep_test(void)
>   {
>     struct task_struct *t;
>     atomic_t done;
>
>     atomic_set(&done, 0);
>
>     t = kthread_run(usleep_test_task, &done, "usleep_test_task");
>     while (!atomic_read(&done)) {
>       wake_up_process(t);
>       udelay(1000);
>     }
>     kthread_stop(t);
>   }
>
> If you run the above code without this patch you get things like:
>   Requested 50000 - 100000 us.  Actually slept for 967 us
>
> If you run the above code _with_ this patch, you get:
>   Requested 50000 - 100000 us.  Actually slept for 50001 us
>
> Presumably this problem was not detected before because:
> - It's not terribly common to use wake_up_process() directly.
> - Other ways for processes to wake up are not typically mixed with
>   usleep_range().
> - There aren't lots of places that use usleep_range(), since many people
>   call either msleep() or udelay().
>
> Reported-by: Tao Huang <huangtao at rock-chips.com>
> Signed-off-by: Douglas Anderson <dianders at chromium.org>
> ---
> Changes in v2:
> - Fixed stupid bug that snuck in before posting
> - Use ktime_before
> - Remove delta from the loop
>
> NOTE: Tested against 4.4 tree w/ backports.  I'm trying to get myself
> up and running with mainline again to test there now but it might be a
> little while.  Hopefully this time I don't shoot myself in the foot.

OK, I finally resolved all my issues and have officially tested this
on mainline (not just in my private kernel) linux 4.8 on an
rk3288-veyron-jerry based device.  Problem still exists there and fix
still works.

Sorry for the noise earlier.  Hopefully this version of the patch
addresses all of Andreas's review feedback (and thank you very much
for the review!)

-Doug


From wxt at rock-chips.com  Mon Oct 10 16:11:07 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Tue, 11 Oct 2016 07:11:07 +0800
Subject: [PATCH] soc: rockchip: avoid infinite loop for power domain
Message-ID: <1476141067-21186-1-git-send-email-wxt@rock-chips.com>

In some cases, we have met the infinite loop in
rockchip_pmu_set_idle_request.

This patch adds the error message and avoid infinite loop if it
fails to get the ack.

Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 drivers/soc/rockchip/pm_domains.c | 37 ++++++++++++++++++++++++++++++++-----
 1 file changed, 32 insertions(+), 5 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 7acd151..cb2a076 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -9,6 +9,7 @@
  */
 
 #include <linux/io.h>
+#include <linux/iopoll.h>
 #include <linux/err.h>
 #include <linux/pm_clock.h>
 #include <linux/pm_domain.h>
@@ -105,12 +106,24 @@ static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
 	return (val & pd_info->idle_mask) == pd_info->idle_mask;
 }
 
+static u32 rockchip_pmu_read_ack(struct rockchip_pmu *pmu)
+{
+	u32 val;
+
+	regmap_read(pmu->regmap, pmu->info->ack_offset, &val);
+	return val;
+}
+
 static int rockchip_pmu_set_idle_request(struct rockchip_pm_domain *pd,
 					 bool idle)
 {
 	const struct rockchip_domain_info *pd_info = pd->info;
+	struct generic_pm_domain *genpd = &pd->genpd;
 	struct rockchip_pmu *pmu = pd->pmu;
 	unsigned int val;
+	u32 target_ack;
+	bool target_idle;
+	int ret;
 
 	if (pd_info->req_mask == 0)
 		return 0;
@@ -120,12 +133,26 @@ static int rockchip_pmu_set_idle_request(struct rockchip_pm_domain *pd,
 
 	dsb(sy);
 
-	do {
-		regmap_read(pmu->regmap, pmu->info->ack_offset, &val);
-	} while ((val & pd_info->ack_mask) != (idle ? pd_info->ack_mask : 0));
+	/* Wait util idle_ack = 1 */
+	target_ack = idle ? pd_info->ack_mask : 0;
+	ret = readx_poll_timeout_atomic(rockchip_pmu_read_ack, pmu, val,
+			(val & pd_info->ack_mask) == target_ack, 0, 10000);
+	if (ret) {
+		dev_err(pmu->dev,
+			"failed to get ack on domain '%s', val=0x%x\n",
+			genpd->name, val);
+		return ret;
+	}
 
-	while (rockchip_pmu_domain_is_idle(pd) != idle)
-		cpu_relax();
+	ret = readx_poll_timeout_atomic(rockchip_pmu_domain_is_idle, pd,
+					target_idle, target_idle == idle,
+					0, 10000);
+	if (ret) {
+		dev_err(pmu->dev,
+			"failed to set idle on domain '%s', val=0x%x\n",
+			genpd->name, target_idle);
+		return ret;
+	}
 
 	return 0;
 }
-- 
1.9.1



From shawn.lin at rock-chips.com  Mon Oct 10 18:16:10 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 11 Oct 2016 09:16:10 +0800
Subject: [PATCH] thermal: rockchip: improve the warning log
In-Reply-To: <1729478.KIY7mRhFMh@phil>
References: <1476017358-26143-1-git-send-email-shawn.lin@rock-chips.com>
 <1729478.KIY7mRhFMh@phil>
Message-ID: <53da8218-049a-086a-bbb7-45031cc05872@rock-chips.com>

? 2016/10/11 4:28, Heiko Stuebner ??:
> Am Sonntag, 9. Oktober 2016, 20:49:18 CEST schrieb Shawn Lin:
>> There is no necessary to print warning agian and
>
> It is not necessary to print a warning again and ...
>

Ah, actually I mean 'necessity', will fix it anyway.

>> again if we don't add rockchip,grf for dt, otherwise
>> I saw the following log when doning suspend-2-resume.
> 								^ doing

sure.

>
>> We only need to print it once when parsing dt. It looks
>> quite trivial but the log is apparently verbose.
>>
>> [   26.615415] PM: early resume of devices complete after 1.539 msecs
>> [   26.622002] rk_tsadcv2_initialize: Missing rockchip,grf property
>> [   26.629359] rk_gmac-dwmac ff290000.ethernet: init for RGMII
>> [   26.639794] PM: resume of devices complete after 18.109 msecs
>> [   26.646925] Restarting tasks ... done.
>>
>> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>> ---
>>
>>  drivers/thermal/rockchip_thermal.c | 7 ++-----
>>  1 file changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/thermal/rockchip_thermal.c
>> b/drivers/thermal/rockchip_thermal.c index e227a9f..b811b0f 100644
>> --- a/drivers/thermal/rockchip_thermal.c
>> +++ b/drivers/thermal/rockchip_thermal.c
>> @@ -524,11 +524,6 @@ static void rk_tsadcv2_initialize(struct regmap *grf,
>> void __iomem *regs, regs + TSADCV2_AUTO_PERIOD_HT);
>>  	writel_relaxed(TSADCV2_HIGHT_TSHUT_DEBOUNCE_COUNT,
>>  		       regs + TSADCV2_HIGHT_TSHUT_DEBOUNCE);
>> -
>> -	if (IS_ERR(grf)) {
>> -		pr_warn("%s: Missing rockchip,grf property\n", __func__);
>> -		return;
>> -	}
>
> dropping the pr_warn here is ok, as the v2 tsadc does not access it anyway
>
>>  }
>>
>>  /**
>> @@ -971,6 +966,8 @@ static int rockchip_configure_from_dt(struct device
>> *dev, * need this property.
>>  	 */
>>  	thermal->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
>> +	if (IS_ERR(thermal->grf))
>> +		dev_warn(dev, "Missing rockchip,grf property\n");
>
> but I'm not sure if we need this warning here. As said above v2-tsadc does not
> need it at all and the v3 tsadc seems to work around a missing grf regmap?

I didn't look into the driver but just want to drop the pr_warn there.

And yes, v2-tsadc doesn't use it at all and v3 does work around if
missing grf there. I think it it okay to carry on the log here since
it would be fine to cast a warning for folks to debug. Also we could
see that rockchip_configure_from_dt actually cast some similar warnings
there when failing to parse some properties properly which isn't
critical, i.e hw-tshut-temp, hw-tshut-mode, etc.. And that should
be harmless. :)

>
> So maybe don't do any warning at all or something like that?
>
> Btw. it also seems like the binding txt document is missing an entry for the
> rockchip,grf property. So maybe you could do another patch to add that
> optional property to the binding doc?

I will.

>
>
> Heiko
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>


-- 
Best Regards
Shawn Lin



From shawn.lin at rock-chips.com  Mon Oct 10 19:07:34 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 11 Oct 2016 10:07:34 +0800
Subject: [PATCH v2 1/2] thermal: rockchip: improve the warning log
Message-ID: <1476151655-18415-1-git-send-email-shawn.lin@rock-chips.com>

It is no necessary to print warning agian and again if we don't
add rockchip,grf for dt, otherwise I saw the following log when
doing suspend-2-resume. We only need to print it once when parsing
dt. It looks quite trivial but the log is apparently verbose.

[   26.615415] PM: early resume of devices complete after 1.539 msecs
[   26.622002] rk_tsadcv2_initialize: Missing rockchip,grf property
[   26.629359] rk_gmac-dwmac ff290000.ethernet: init for RGMII
[   26.639794] PM: resume of devices complete after 18.109 msecs
[   26.646925] Restarting tasks ... done.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

Reviewed-by: Caesar Wang <wxt at rock-chips.com>
---

Changes in v2:
- fix typos(Heiko)

 drivers/thermal/rockchip_thermal.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c
index e227a9f..b811b0f 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -524,11 +524,6 @@ static void rk_tsadcv2_initialize(struct regmap *grf, void __iomem *regs,
 		       regs + TSADCV2_AUTO_PERIOD_HT);
 	writel_relaxed(TSADCV2_HIGHT_TSHUT_DEBOUNCE_COUNT,
 		       regs + TSADCV2_HIGHT_TSHUT_DEBOUNCE);
-
-	if (IS_ERR(grf)) {
-		pr_warn("%s: Missing rockchip,grf property\n", __func__);
-		return;
-	}
 }
 
 /**
@@ -971,6 +966,8 @@ static int rockchip_configure_from_dt(struct device *dev,
 	 * need this property.
 	 */
 	thermal->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+	if (IS_ERR(thermal->grf))
+		dev_warn(dev, "Missing rockchip,grf property\n");
 
 	return 0;
 }
-- 
2.3.7




From shawn.lin at rock-chips.com  Mon Oct 10 19:07:35 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 11 Oct 2016 10:07:35 +0800
Subject: [PATCH v2 2/2] dt-bindings: rockchip-thermal: fix the misleading
 description
In-Reply-To: <1476151655-18415-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476151655-18415-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476151655-18415-2-git-send-email-shawn.lin@rock-chips.com>

"rockchip,hw-tshut-temp", "rockchip,hw-tshut-mode" and
"rockchip,hw-tshut-polarity" are not a required properties
actually as the code could also work by loading the default
settings there. So it is apprently misleading, although we
prefer to get these from DT. And it seems we miss the 'rockchip,grf'
here which should also be an optional property.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

Changes in v2: None

 Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
index 08efe6b..43003ae 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -22,10 +22,13 @@ Required properties:
 	      TSADC controller.
 - pinctrl-2 : The "sleep" pinctrl state, it will be in for suspend.
 - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
+
+Optional properties:
 - rockchip,hw-tshut-temp : The hardware-controlled shutdown temperature value.
 - rockchip,hw-tshut-mode : The hardware-controlled shutdown mode 0:CRU 1:GPIO.
 - rockchip,hw-tshut-polarity : The hardware-controlled active polarity 0:LOW
 			       1:HIGH.
+- rockchip,grf : The phandle of the syscon node for the general register file.
 
 Exiample:
 tsadc: tsadc at ff280000 {
-- 
2.3.7




From shawn.lin at rock-chips.com  Mon Oct 10 21:26:25 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 11 Oct 2016 12:26:25 +0800
Subject: [PATCH v6 1/3] Documentation/devicetree: Add new property to specify
 the max link speed
Message-ID: <1476159987-31372-1-git-send-email-shawn.lin@rock-chips.com>

Some of the host drivers have the requirement of knowing whether the
EP would never train at some link speed at all. For instance, on some
boards, the link won't train at 5 GT/s but the host driver still sacrifice
some cycle to wait for the resule of training at 5 GT/s as the host could
actually support 5 GT/s. So we could parse this new property and make the
host drivers be aware of these cases.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/pci/pci.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
index 08dcfad..e7d97a3 100644
--- a/Documentation/devicetree/bindings/pci/pci.txt
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -18,3 +18,9 @@ driver implementation may support the following properties:
    host bridges in the system, otherwise potentially conflicting domain numbers
    may be assigned to root buses behind different host bridges.  The domain
    number for each host bridge in the system must be unique.
+- max-link-speed:
+   If present this property specifies PCI gen for link capability. The host drivers
+   could add this as a strategy to avoid unnecessary operation for unsupported
+   link speed, for instance, trying to do training for unsupported link speed, etc.
+   Must be '4' for gen4, '3' for gen3, '2' for gen2, and '1' for gen1. Any other
+   values are invalid.
-- 
2.3.7




From shawn.lin at rock-chips.com  Mon Oct 10 21:26:26 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 11 Oct 2016 12:26:26 +0800
Subject: [PATCH v6 2/3] of/pci: Add helper function to parse max-link-speed
 from dt
In-Reply-To: <1476159987-31372-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476159987-31372-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476159987-31372-2-git-send-email-shawn.lin@rock-chips.com>

This new helper function could be used by host drivers to
get the limitaion of max link speed provided by dt. If the
property isn't assigned or is invalid, it will return -EINVAL
to the caller.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/of/of_pci.c    | 27 +++++++++++++++++++++++++++
 include/linux/of_pci.h |  7 +++++++
 2 files changed, 34 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 589b30c..91fd465 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -120,6 +120,33 @@ int of_get_pci_domain_nr(struct device_node *node)
 EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
 
 /**
+ * This function will try to find the limitation of link speed by finding
+ * a property called "max-link-speed" of the given device node.
+ *
+ * @node: device tree node with the max link speed information
+ *
+ * Returns the associated max link speed from DT, or a negative value if the
+ * required property is not found or is invalid.
+ */
+int of_get_pci_max_link_speed(struct device_node *node)
+{
+	const __be32 *value;
+	int len;
+	u16 max_link_speed;
+
+	value = of_get_property(node, "max-link-speed", &len);
+	if (!value || len < sizeof(*value))
+		return -EINVAL;
+
+	max_link_speed = (u16)be32_to_cpup(value);
+	if (max_link_speed > 4)
+		return -EINVAL;
+
+	return max_link_speed;
+}
+EXPORT_SYMBOL_GPL(of_get_pci_max_link_speed);
+
+/**
  * of_pci_check_probe_only - Setup probe only mode if linux,pci-probe-only
  *                           is present and valid
  */
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index b969e94..a8946d7 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -16,6 +16,7 @@ int of_pci_get_devfn(struct device_node *np);
 int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 int of_get_pci_domain_nr(struct device_node *node);
+int of_get_pci_max_link_speed(struct device_node *node);
 void of_pci_check_probe_only(void);
 #else
 static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq)
@@ -52,6 +53,12 @@ of_get_pci_domain_nr(struct device_node *node)
 	return -1;
 }
 
+static inline int
+of_get_pci_max_link_speed(struct device_node *node)
+{
+	return -EINVAL;
+}
+
 static inline void of_pci_check_probe_only(void) { }
 #endif
 
-- 
2.3.7




From shawn.lin at rock-chips.com  Mon Oct 10 21:26:27 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 11 Oct 2016 12:26:27 +0800
Subject: [PATCH v6 3/3] PCI: rockchip: Specify the link capability
In-Reply-To: <1476159987-31372-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476159987-31372-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476159987-31372-3-git-send-email-shawn.lin@rock-chips.com>

From: Brian Norris <briannorris at chromium.org>

rk3399 supports PCIe 2.x link speeds marginally at best, and on some
boards, the link won't train at 5 GT/s at all. Rather than sacrifice
500ms waiting for training that will never happen, let's use the helper
function, of_get_pci_max_link_speed, to get the max link speed from DT
and specify link capability.

Signed-off-by: Brian Norris <briannorris at chromium.org>
Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v6:
- user helper function of_get_pci_max_link_speed and use gen2 by default
  if finding any errors from of_get_pci_max_link_speed. It could be
  backward compatibe to the old dtb. (Suggested by Rob)

Changes in v5:
- rebase the code since it isn't cleanly applied after Bjorn's cleanup

Changes in v4:
- define link_gen as u32
- elaborate more for rockchip,max-link-speed on doc

Changes in v3:
- Cast a warning for invalid max link speed and use gen1 for it.
  That looks better than v2. (Suggested by Brian)

Changes in v2:
- rename the property to rockchip,max-link-speed according to
  Bjorn's recommendation and take some bits from imx6q-pcie to
  make this requirement more consisent.

 drivers/pci/host/pcie-rockchip.c | 58 +++++++++++++++++++++++++---------------
 1 file changed, 36 insertions(+), 22 deletions(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index b3548d0..7125e35 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -53,6 +53,7 @@
 #define   PCIE_CLIENT_ARI_ENABLE	  HIWORD_UPDATE_BIT(0x0008)
 #define   PCIE_CLIENT_CONF_LANE_NUM(x)	  HIWORD_UPDATE(0x0030, ENCODE_LANES(x))
 #define   PCIE_CLIENT_MODE_RC		  HIWORD_UPDATE_BIT(0x0040)
+#define   PCIE_CLIENT_GEN_SEL_1		  HIWORD_UPDATE(0x0080, 0)
 #define   PCIE_CLIENT_GEN_SEL_2		  HIWORD_UPDATE_BIT(0x0080)
 #define PCIE_CLIENT_BASIC_STATUS1	(PCIE_CLIENT_BASE + 0x48)
 #define   PCIE_CLIENT_LINK_STATUS_UP		0x00300000
@@ -200,6 +201,7 @@ struct rockchip_pcie {
 	struct	gpio_desc *ep_gpio;
 	u32	lanes;
 	u8	root_bus_nr;
+	int	link_gen;
 	struct	device *dev;
 	struct	irq_domain *irq_domain;
 };
@@ -437,13 +439,19 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		return err;
 	}
 
+	if (rockchip->link_gen == 2)
+		rockchip_writel(rockchip, PCIE_CLIENT_CONFIG,
+				PCIE_CLIENT_GEN_SEL_2);
+	else
+		rockchip_writel(rockchip, PCIE_CLIENT_CONFIG,
+				PCIE_CLIENT_GEN_SEL_1);
+
 	rockchip_writel(rockchip, PCIE_CLIENT_CONFIG,
 			    PCIE_CLIENT_CONF_ENABLE |
 			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
 			    PCIE_CLIENT_ARI_ENABLE |
 			    PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
-			    PCIE_CLIENT_MODE_RC |
-			    PCIE_CLIENT_GEN_SEL_2);
+			    PCIE_CLIENT_MODE_RC);
 
 	err = phy_power_on(rockchip->phy);
 	if (err) {
@@ -519,29 +527,31 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		msleep(20);
 	}
 
-	/*
-	 * Enable retrain for gen2. This should be configured only after
-	 * gen1 finished.
-	 */
-	status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
-	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
-	rockchip_writel(rockchip, PCIE_RC_CONFIG_LCS, status);
+	if (rockchip->link_gen == 2) {
+		/*
+		 * Enable retrain for gen2. This should be configured
+		 * only after gen1 finished.
+		 */
+		status = rockchip_readl(rockchip, PCIE_RC_CONFIG_LCS);
+		status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
+		rockchip_writel(rockchip, PCIE_RC_CONFIG_LCS, status);
+
+		timeout = jiffies + msecs_to_jiffies(500);
+		for (;;) {
+			status = rockchip_readl(rockchip, PCIE_CORE_CTRL);
+			if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
+			    PCIE_CORE_PL_CONF_SPEED_5G) {
+				dev_dbg(dev, "PCIe link training gen2 pass!\n");
+				break;
+			}
 
-	timeout = jiffies + msecs_to_jiffies(500);
-	for (;;) {
-		status = rockchip_readl(rockchip, PCIE_CORE_CTRL);
-		if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
-		    PCIE_CORE_PL_CONF_SPEED_5G) {
-			dev_dbg(dev, "PCIe link training gen2 pass!\n");
-			break;
-		}
+			if (time_after(jiffies, timeout)) {
+				dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
+				break;
+			}
 
-		if (time_after(jiffies, timeout)) {
-			dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
-			break;
+			msleep(20);
 		}
-
-		msleep(20);
 	}
 
 	/* Check the final link width from negotiated lane counter from MGMT */
@@ -747,6 +757,10 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
 		rockchip->lanes = 1;
 	}
 
+	rockchip->link_gen = of_get_pci_max_link_speed(node);
+	if (rockchip->link_gen < 0 || rockchip->link_gen > 2)
+		rockchip->link_gen = 2;
+
 	rockchip->core_rst = devm_reset_control_get(dev, "core");
 	if (IS_ERR(rockchip->core_rst)) {
 		if (PTR_ERR(rockchip->core_rst) != -EPROBE_DEFER)
-- 
2.3.7




From heiko at sntech.de  Tue Oct 11 00:01:44 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 11 Oct 2016 09:01:44 +0200
Subject: [PATCH v2 2/2] dt-bindings: rockchip-thermal: fix the misleading
 description
In-Reply-To: <1476151655-18415-2-git-send-email-shawn.lin@rock-chips.com>
References: <1476151655-18415-1-git-send-email-shawn.lin@rock-chips.com>
 <1476151655-18415-2-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <2090010.rzXtZk2lxz@phil>

Am Dienstag, 11. Oktober 2016, 10:07:35 CEST schrieb Shawn Lin:
> "rockchip,hw-tshut-temp", "rockchip,hw-tshut-mode" and
> "rockchip,hw-tshut-polarity" are not a required properties
> actually as the code could also work by loading the default
> settings there. So it is apprently misleading, although we
> prefer to get these from DT. And it seems we miss the 'rockchip,grf'
> here which should also be an optional property.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

Reviewed-by: Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Tue Oct 11 00:03:02 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 11 Oct 2016 09:03:02 +0200
Subject: [PATCH v2 1/2] thermal: rockchip: improve the warning log
In-Reply-To: <1476151655-18415-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476151655-18415-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <6259981.fCVDkTTFBl@phil>

Am Dienstag, 11. Oktober 2016, 10:07:34 CEST schrieb Shawn Lin:
> It is no necessary to print warning agian and again if we don't
> add rockchip,grf for dt, otherwise I saw the following log when
> doing suspend-2-resume. We only need to print it once when parsing
> dt. It looks quite trivial but the log is apparently verbose.
> 
> [   26.615415] PM: early resume of devices complete after 1.539 msecs
> [   26.622002] rk_tsadcv2_initialize: Missing rockchip,grf property
> [   26.629359] rk_gmac-dwmac ff290000.ethernet: init for RGMII
> [   26.639794] PM: resume of devices complete after 18.109 msecs
> [   26.646925] Restarting tasks ... done.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> 
> Reviewed-by: Caesar Wang <wxt at rock-chips.com>

Reviewed-by: Heiko Stuebner <heiko at sntech.de>


From tglx at linutronix.de  Tue Oct 11 00:14:38 2016
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 11 Oct 2016 09:14:38 +0200 (CEST)
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <1476133442-17757-1-git-send-email-dianders@chromium.org>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
Message-ID: <alpine.DEB.2.20.1610110908240.7794@nanos>

On Mon, 10 Oct 2016, Douglas Anderson wrote:
> Users of usleep_range() expect that it will _never_ return in less time
> than the minimum passed parameter.  However, nothing in any of the code
> ensures this.  Specifically:

There is no such guarantee for that interface and never has been, so how
did you make sure that none of the existing users is relying on this?

You can't just can't just declare that all all of the users expect that and
be done with it.

Thanks,

	tglx






From heiko at sntech.de  Tue Oct 11 02:19:27 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 11 Oct 2016 11:19:27 +0200
Subject: [PATCH] ARM: dts: rockchip: initialize rk3066 PLL clock rate
In-Reply-To: <20161006194221.GA4895@vaio-ubuntu>
References: <20161006194221.GA4895@vaio-ubuntu>
Message-ID: <12104842.0Sv0KpAWIA@phil>

Am Donnerstag, 6. Oktober 2016, 21:42:21 CEST schrieb Pawe? Jarosz:
> Initialize PLL rate while kernel init. No other module does than.
> Clock rates are taken from rk3066 TRM. Assigned values are for 125 degrees
> celcius operating point.
> This gives us performance boost observable for example in mmc transfers.
> 
> Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
> ---
>  arch/arm/boot/dts/rk3066a.dtsi | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> index 0d0dae3..cf215e8 100644
> --- a/arch/arm/boot/dts/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rk3066a.dtsi
> @@ -151,6 +151,10 @@
> 
>  		#clock-cells = <1>;
>  		#reset-cells = <1>;
> +		assigned-clocks = <&cru PLL_DPLL>, <&cru PLL_APLL>,

we shouldn't touch the DPLL and APLL at all in this context. They are quite 
reliant on the underlying voltages and the bootloader might've set other 
values. Also changing the DDR frequency through the DPLL requires special 
handling on the DDR side.

> +				  <&cru PLL_CPLL>, <&cru PLL_GPLL>;

please also initialize the PERI and BUS clocks (similar to what the rk3288 clk 
settings do), so that they stay sane, even if we change CPLL and GPLL 
frequencies.

> +		assigned-clock-rates = <533000000>, <600000000>,
> +				       <600000000>, <600000000>;

Also setting both CPLL and GPLL to the same value might be unhelpful to 
achieve special divided frequencies? Again see rk3288.dtsi where we have a 594 
/ 400 MHz division. Especially the downstream clocks normally can select 
between CPLL and GPLL.


Heiko


From robh at kernel.org  Tue Oct 11 07:02:51 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 11 Oct 2016 09:02:51 -0500
Subject: [PATCH v6 2/3] of/pci: Add helper function to parse
 max-link-speed from dt
In-Reply-To: <1476159987-31372-2-git-send-email-shawn.lin@rock-chips.com>
References: <1476159987-31372-1-git-send-email-shawn.lin@rock-chips.com>
 <1476159987-31372-2-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <CAL_JsqLkQ_q9rKmZ8pX4btWD8V5qTeYmgDncVuoXi_sAO9kGTA@mail.gmail.com>

On Mon, Oct 10, 2016 at 11:26 PM, Shawn Lin <shawn.lin at rock-chips.com> wrote:
> This new helper function could be used by host drivers to
> get the limitaion of max link speed provided by dt. If the
> property isn't assigned or is invalid, it will return -EINVAL
> to the caller.
>
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  drivers/of/of_pci.c    | 27 +++++++++++++++++++++++++++
>  include/linux/of_pci.h |  7 +++++++
>  2 files changed, 34 insertions(+)
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 589b30c..91fd465 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -120,6 +120,33 @@ int of_get_pci_domain_nr(struct device_node *node)
>  EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
>
>  /**
> + * This function will try to find the limitation of link speed by finding
> + * a property called "max-link-speed" of the given device node.
> + *
> + * @node: device tree node with the max link speed information
> + *
> + * Returns the associated max link speed from DT, or a negative value if the
> + * required property is not found or is invalid.
> + */
> +int of_get_pci_max_link_speed(struct device_node *node)

of_pci_get_max_link_speed

> +{
> +       const __be32 *value;
> +       int len;
> +       u16 max_link_speed;
> +
> +       value = of_get_property(node, "max-link-speed", &len);

Use of_property_read_u32 instead.

> +       if (!value || len < sizeof(*value))
> +               return -EINVAL;
> +
> +       max_link_speed = (u16)be32_to_cpup(value);

There's no point in making this a u16.

> +       if (max_link_speed > 4)
> +               return -EINVAL;
> +
> +       return max_link_speed;
> +}
> +EXPORT_SYMBOL_GPL(of_get_pci_max_link_speed);
> +
> +/**
>   * of_pci_check_probe_only - Setup probe only mode if linux,pci-probe-only
>   *                           is present and valid
>   */
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index b969e94..a8946d7 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -16,6 +16,7 @@ int of_pci_get_devfn(struct device_node *np);
>  int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
>  int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
>  int of_get_pci_domain_nr(struct device_node *node);
> +int of_get_pci_max_link_speed(struct device_node *node);
>  void of_pci_check_probe_only(void);
>  #else
>  static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq)
> @@ -52,6 +53,12 @@ of_get_pci_domain_nr(struct device_node *node)
>         return -1;
>  }
>
> +static inline int
> +of_get_pci_max_link_speed(struct device_node *node)
> +{
> +       return -EINVAL;
> +}
> +
>  static inline void of_pci_check_probe_only(void) { }
>  #endif
>
> --
> 2.3.7
>
>


From dianders at chromium.org  Tue Oct 11 09:33:15 2016
From: dianders at chromium.org (Doug Anderson)
Date: Tue, 11 Oct 2016 09:33:15 -0700
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <alpine.DEB.2.20.1610110908240.7794@nanos>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
 <alpine.DEB.2.20.1610110908240.7794@nanos>
Message-ID: <CAD=FV=VTc-RFNiUqkKDr=NFWhphV7r2J+EudSbqt4X3TX62mQw@mail.gmail.com>

Thomas,

+clock and regulator folks since part of my arguments below involve
the regulator / clock core.  If you're not interested in this topic,
feel free to ignore.  Original patch can be found on LKML or at
<https://patchwork.kernel.org/patch/9369963/>

On Tue, Oct 11, 2016 at 12:14 AM, Thomas Gleixner <tglx at linutronix.de> wrote:
> On Mon, 10 Oct 2016, Douglas Anderson wrote:
>> Users of usleep_range() expect that it will _never_ return in less time
>> than the minimum passed parameter.  However, nothing in any of the code
>> ensures this.  Specifically:
>
> There is no such guarantee for that interface and never has been, so how
> did you make sure that none of the existing users is relying on this?
>
> You can't just can't just declare that all all of the users expect that and
> be done with it.

You're right that I can't guarantee that no callers are relying on the
existing behavior of a wake_up_process() causing usleep_range() to
return early.  I would say, however, that all callers I've seen are
absolutely relying on the min delay being enforced and I've never
personally seen a caller relying on being woken up from
usleep_range().  All the users relying on the min delay being enforced
have never had a problem because it's not common for a task that's in
usleep_range() to be woken up, but if you happen to call some generic
code in a context where a wake up is possible you'll get a very
unexpected bug (like I just did).

I can try to look through some callers to usleep_range(), but there
are 1620 of them as per my "git grep", so I can't look at them all.
:(

...in any case, below are my arguments about why we should change
this.  If we can't agree to change this, then IMHO the way forward is
to deprecate usleep_range() and start the transition of all callers to
one of two functions: usleep_atlest() and usleep_wakeable().  As
argued below I think that usleep_range() name implies that it will at
least sleep the minimum so I would really like to avoid keeping the
name usleep_range() and also keeping the existing behavior.

--

1. I believe msleep() and usleep_range() should be parallel functions.
msleep() has this guarantee of not ending early.  I believe users will
expect that usleep() will also.

2. The "timers-howto.txt" does not have any information about the fact
that usleep_range() might end early.  This document implies that
(assuming you're not in atomic) udelay() / usleep_range() should be
chosen between simply based on how long the expected delay is.  There
is no note that you shouldn't use usleep_range() if you can't handle
ending early.

3. It seems to me that if someone wants to wait to be woken up but
they want a timeout, they wouldn't reach for usleep_range().  They
would instead think to use schedule_hrtimeout_range() directly.  Said
another way: we already have a function for scheduling a delay that
can be interrupted with a wakeup, so why do we need usleep_range() to
also behave this way?

4. We need to change a lot of places if we want to handle the fact
that usleep_range() might wake up early.  Every instance of
usleep_range() that I've ever seen is not expecting to end early and
is expecting at least the minimum delay for correctness.  These
functions have all worked correctly because they didn't happen to be
called in a context where someone might wake up the calling task.
...but if suddenly one of these functions is called on a task that
might be woken up then all their correctness will go out the door.

In other words, I see a lot of usleep_range() calls that look like this:

  /* After 5 ms we know reset is done */
  assert_reset()
  usleep_range(5000, 7000)

If that returns early then we'll get badness.

--

Here's a (perhaps more realistic) example of the problem.  Imagine
that we are trying to do some type of DVF (Dynamic Voltage Frequency)
switch.  That involves changing both a regulator and a clock.  It's
possible that we might want to try to do these two things in parallel
on two tasks, so we could imagine doing:

Task #1 (voltage)
A) Call into regulator core to change voltage.
A1) Regulator core will call into arbitrary regulator driver.
A2) Regulator core won't return until regulator is at the right level.
A3) Delay waiting for regulator might be done with usleep_range().
B) Signal Task #2 that we're done.
C) Wait on Task #2 to finish.

Task #2 (clock)
A) Call into clock core to change clock.
A1) Clock core will call into arbitrary clock driver.
A2) Clock core won't return until clock is stable.
A3) Delay waiting for clock might be done with usleep_range().
B) Signal Task #1 that we're done.
C) Wait on Task #1 to finish.

Depending on the delays and the mechanism used to signal and wait, it
is possible that the "Signal" step above will end up waking up the
other task.  If it does this while the other task is in the
usleep_range() code then we'll have serious problems: we'll either run
with an clock or a regulator that isn't all the way ready.

Now perhaps you will say that we should re-design the signaling
mechanism above so that it doesn't cause a wake up of the other task.
We certainly could try to do that if need be (we'd have to validate
that there is really NEVER an unexpected wakeup), but I'd expect a lot
of push back since I don't think folks would think that waking up a
task would cause such incorrect behavior.

Now perhaps you will say that we should re-design all clock and
regulator drivers to not call usleep_range() (or to add a loop).  This
implies that we should add a new function so they don't all need to
get this loop right.


NOTE: In the particular failure case I'm running into, I'm on a system
using the (out of tree) "interactive" governor.  I haven't followed
through the exact code path, but I see that it is using
wake_up_process() in at least several places to wake up the
"speedchange_task".  This is the same task that might be calling into
cpufreq to change the frequency and might be calling into the
regulator core to do the delay.  We were specifically seeing cases
where the usleep_range() in PWM regulator was returning early.

--

OK, I know that the above is pretty long.  Hopefully it made sense.
Feel free to grab me on IRC if it helps.  I can be found on freenode
as dianders and can join any channel where it's helpful to hash this
out.

-Doug


From andi at lisas.de  Tue Oct 11 11:25:41 2016
From: andi at lisas.de (Andreas Mohr)
Date: Tue, 11 Oct 2016 20:25:41 +0200
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <alpine.DEB.2.20.1610110908240.7794@nanos>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
 <alpine.DEB.2.20.1610110908240.7794@nanos>
Message-ID: <20161011182541.GA32165@rhlx01.hs-esslingen.de>

On Tue, Oct 11, 2016 at 09:14:38AM +0200, Thomas Gleixner wrote:
> On Mon, 10 Oct 2016, Douglas Anderson wrote:
> > Users of usleep_range() expect that it will _never_ return in less time
> > than the minimum passed parameter.  However, nothing in any of the code
> > ensures this.  Specifically:
> 
> There is no such guarantee for that interface and never has been, so how
> did you make sure that none of the existing users is relying on this?
> 
> You can't just can't just declare that all all of the users expect that and
> be done with it.

Hmm, somehow I don't manage to follow these thoughts.

https://www.kernel.org/doc/htmldocs/device-drivers/API-usleep-range.html
(as a hopefully sufficiently authoritative source of documentation)
clearly specifies min to be
"Minimum time in usecs to sleep"
, which is what one would expect a two-param interface here to be
(minimum-maximum),
i.e. what would be the *natural* protocol I'd think.

Also, [finally...] starting to enforce the minimum time
is an additional *constraint* on the protocol,
i.e. it's not at all like we are getting more *liberal* here
(since usually getting more liberal in certain protocols
is what will cause trouble, I'd think).

Not to mention that
desiring a delay in processing most certainly is
what caused users of this API to decide to invoke it in the first place
(else they would just have chosen to carry on with delay-less processing
and be done with it).
And those users then surely wouldn't want to experience a behaviour
where the delay may be ended at any time,
however short that may end up being.


A related topic probably is
premature wakeups (e.g. signal-induced) of select() etc. protocol.

Greetings,

Andreas Mohr


From briannorris at chromium.org  Tue Oct 11 11:54:28 2016
From: briannorris at chromium.org (Brian Norris)
Date: Tue, 11 Oct 2016 11:54:28 -0700
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <1476133442-17757-1-git-send-email-dianders@chromium.org>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
Message-ID: <20161011185427.GA18048@localhost>

Hi Doug,

On Mon, Oct 10, 2016 at 02:04:02PM -0700, Doug Anderson wrote:
> Users of usleep_range() expect that it will _never_ return in less time
> than the minimum passed parameter.  However, nothing in any of the code
> ensures this.

Like you and Andreas, I also don't understand Thomas's objection to your
above claim on what users of this function expect. I believe you have
clearly laid out why the current behavior needs to be changed somehow;
IMO the only remaining question is "how." Your follow up covers all this
plenty well for me.

Either we need a fix along the lines of what you've proposed, or else we
need to completely rethink almost all uses of usleep_range().

...

> Reported-by: Tao Huang <huangtao at rock-chips.com>
> Signed-off-by: Douglas Anderson <dianders at chromium.org>
> ---
> Changes in v2:
> - Fixed stupid bug that snuck in before posting
> - Use ktime_before
> - Remove delta from the loop
> 
> NOTE: Tested against 4.4 tree w/ backports.  I'm trying to get myself
> up and running with mainline again to test there now but it might be a
> little while.  Hopefully this time I don't shoot myself in the foot.
> 
>  kernel/time/timer.c | 20 ++++++++++++++++++--
>  1 file changed, 18 insertions(+), 2 deletions(-)

I've reviewed the logic here to the best of my ability, and it looks
good to me now. I'll admit that I'm not really a timekeeping or
scheduler expert, but FWIW:

Reviewed-by: Brian Norris <briannorris at chromium.org>

> diff --git a/kernel/time/timer.c b/kernel/time/timer.c
> index 32bf6f75a8fe..219439efd56a 100644
> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
> @@ -1898,12 +1898,28 @@ EXPORT_SYMBOL(msleep_interruptible);
>  
>  static void __sched do_usleep_range(unsigned long min, unsigned long max)
>  {
> +	ktime_t now, end;
>  	ktime_t kmin;
>  	u64 delta;
> +	int ret;
>  
> -	kmin = ktime_set(0, min * NSEC_PER_USEC);
> +	now = ktime_get();
> +	end = ktime_add_us(now, min);
>  	delta = (u64)(max - min) * NSEC_PER_USEC;
> -	schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
> +	do {
> +		kmin = ktime_sub(end, now);
> +		ret = schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
> +
> +		/*
> +		 * If schedule_hrtimeout_range() returns 0 then we actually
> +		 * hit the timeout. If not then we need to re-calculate the
> +		 * new timeout ourselves.
> +		 */
> +		if (ret == 0)
> +			break;
> +
> +		now = ktime_get();
> +	} while (ktime_before(now, end));
>  }
>  
>  /**
> -- 
> 2.8.0.rc3.226.g39d4020
> 


From andi at lisas.de  Tue Oct 11 12:30:34 2016
From: andi at lisas.de (Andreas Mohr)
Date: Tue, 11 Oct 2016 21:30:34 +0200
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <1476133442-17757-1-git-send-email-dianders@chromium.org>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
Message-ID: <20161011193034.GA10646@rhlx01.hs-esslingen.de>

Hi,

decided to write a review now, slightly delayed, sorry.

On Mon, Oct 10, 2016 at 02:04:02PM -0700, Douglas Anderson wrote:
> diff --git a/kernel/time/timer.c b/kernel/time/timer.c
> index 32bf6f75a8fe..219439efd56a 100644
> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
> @@ -1898,12 +1898,28 @@ EXPORT_SYMBOL(msleep_interruptible);
>  
>  static void __sched do_usleep_range(unsigned long min, unsigned long max)
>  {
> +	ktime_t now, end;
>  	ktime_t kmin;
>  	u64 delta;
> +	int ret;
>  
> -	kmin = ktime_set(0, min * NSEC_PER_USEC);
> +	now = ktime_get();
> +	end = ktime_add_us(now, min);
>  	delta = (u64)(max - min) * NSEC_PER_USEC;
> -	schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
> +	do {
> +		kmin = ktime_sub(end, now);
> +		ret = schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
> +
> +		/*
> +		 * If schedule_hrtimeout_range() returns 0 then we actually
> +		 * hit the timeout. If not then we need to re-calculate the
> +		 * new timeout ourselves.
> +		 */
> +		if (ret == 0)
> +			break;
> +
> +		now = ktime_get();
> +	} while (ktime_before(now, end));

This loop implementation relies on negative kmin (result of ktime_sub())
getting internally handled by schedule_hrtimeout_range() as a 0 result.
If that ain't the case, then the loop itself will need to handle
negative values.
OK, scratch that, due to guaranteed-unchanged values of now and end,
result of directly subsequent ktime_sub() is guaranteed to
not deviate from what ktime_before() figured.
However, this is somewhat differing handling of these two APIs.


Which brings me to my second point:
somehow doing both ktime_before() and ktime_sub() feels redundant,
since they are both about arguments now and end,
i.e. they are *both* evaluating a "distance".
(this could simply calculate the distance, and then
1. use that calculated distance value, and
2. check that calculated distance value against being negative).
So, most likely it ought to be achievable to have just *one* of these
two active (which would likely be ktime_sub(),
simply since we need its result as schedule_hrtimeout_range() input...).
And that way we would save big (hohumm) on instruction cache footprint :)

Hmm, but ktime API does not have sufficiently open-coded handling of the
ktime_sub()-based distance value - the possibly only way to do an
"is it negative?" check would be by doing
ktime_compare(dist, ktime_null_value),
which might be pointless
since it's a comparably large effort
vs. the current ktime_before(), ktime_sub() case.

BTW, another argument for loop rework might be that
the result of ktime_sub() might already be improper
(due to being negative!) for
subsequent invocation of schedule_hrtimeout_range(),
i.e. there's an argument to be made that
the loop tail check instead ought to be done as a negative-value check
directly prior to schedule_hrtimeout_range() invocation.


Hmm, if schedule_hrtimeout_range() can be relied on to
internally properly be doing the negative check,
then one could simply say that
the annoyingly extra calculation via ktime_before() call
should simply be removed completely.
Which would be a good step since it would centralize protocol behaviour
within the inner handling of the helper
rather than bloating user-side instruction cache footprint.


</micro_optimization> ?

Thanks,

Andreas Mohr


From dianders at chromium.org  Tue Oct 11 13:02:10 2016
From: dianders at chromium.org (Doug Anderson)
Date: Tue, 11 Oct 2016 13:02:10 -0700
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <20161011193034.GA10646@rhlx01.hs-esslingen.de>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
 <20161011193034.GA10646@rhlx01.hs-esslingen.de>
Message-ID: <CAD=FV=Ua8c18SGr54ThmVe1oR3bqfCyHxfhL=6z8vJXkMiUedA@mail.gmail.com>

Andreas,

On Tue, Oct 11, 2016 at 12:30 PM, Andreas Mohr <andi at lisas.de> wrote:
> Hi,
>
> decided to write a review now, slightly delayed, sorry.
>
> On Mon, Oct 10, 2016 at 02:04:02PM -0700, Douglas Anderson wrote:
>> diff --git a/kernel/time/timer.c b/kernel/time/timer.c
>> index 32bf6f75a8fe..219439efd56a 100644
>> --- a/kernel/time/timer.c
>> +++ b/kernel/time/timer.c
>> @@ -1898,12 +1898,28 @@ EXPORT_SYMBOL(msleep_interruptible);
>>
>>  static void __sched do_usleep_range(unsigned long min, unsigned long max)
>>  {
>> +     ktime_t now, end;
>>       ktime_t kmin;
>>       u64 delta;
>> +     int ret;
>>
>> -     kmin = ktime_set(0, min * NSEC_PER_USEC);
>> +     now = ktime_get();
>> +     end = ktime_add_us(now, min);
>>       delta = (u64)(max - min) * NSEC_PER_USEC;
>> -     schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
>> +     do {
>> +             kmin = ktime_sub(end, now);
>> +             ret = schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
>> +
>> +             /*
>> +              * If schedule_hrtimeout_range() returns 0 then we actually
>> +              * hit the timeout. If not then we need to re-calculate the
>> +              * new timeout ourselves.
>> +              */
>> +             if (ret == 0)
>> +                     break;
>> +
>> +             now = ktime_get();
>> +     } while (ktime_before(now, end));
>
> This loop implementation relies on negative kmin (result of ktime_sub())
> getting internally handled by schedule_hrtimeout_range() as a 0 result.
> If that ain't the case, then the loop itself will need to handle
> negative values.
> OK, scratch that, due to guaranteed-unchanged values of now and end,
> result of directly subsequent ktime_sub() is guaranteed to
> not deviate from what ktime_before() figured.
> However, this is somewhat differing handling of these two APIs.

I read this as: no bug, feel free to ignore.


> Which brings me to my second point:
> somehow doing both ktime_before() and ktime_sub() feels redundant,
> since they are both about arguments now and end,
> i.e. they are *both* evaluating a "distance".
> (this could simply calculate the distance, and then
> 1. use that calculated distance value, and
> 2. check that calculated distance value against being negative).
> So, most likely it ought to be achievable to have just *one* of these
> two active (which would likely be ktime_sub(),
> simply since we need its result as schedule_hrtimeout_range() input...).
> And that way we would save big (hohumm) on instruction cache footprint :)
>
> Hmm, but ktime API does not have sufficiently open-coded handling of the
> ktime_sub()-based distance value - the possibly only way to do an
> "is it negative?" check would be by doing
> ktime_compare(dist, ktime_null_value),
> which might be pointless
> since it's a comparably large effort
> vs. the current ktime_before(), ktime_sub() case.

I agree that we could try to save some math by making the loop more
complicated.  On the other hand, one could argue that a sufficiently
good compiler might actually be able to figure some of this stuff out,
since much of this stuff is just inlined 64-bit math comparisons.

That being said, if you want to propose some concrete changes that
save an instruction or two on most architectures and don't make the
code too complicated, I'm happy to spin my patch.


> BTW, another argument for loop rework might be that
> the result of ktime_sub() might already be improper
> (due to being negative!) for
> subsequent invocation of schedule_hrtimeout_range(),
> i.e. there's an argument to be made that
> the loop tail check instead ought to be done as a negative-value check
> directly prior to schedule_hrtimeout_range() invocation.
>
> Hmm, if schedule_hrtimeout_range() can be relied on to
> internally properly be doing the negative check,
> then one could simply say that
> the annoyingly extra calculation via ktime_before() call
> should simply be removed completely.
> Which would be a good step since it would centralize protocol behaviour
> within the inner handling of the helper
> rather than bloating user-side instruction cache footprint.

Ah, so you're saying just do a "while (true)" after changing the
behavior of schedule_hrtimeout_range_clock().  If everyone agrees that
they'd like to see this, I can do it.  I'd have to change
schedule_hrtimeout_range_clock() to check for <= 0 instead of just
comparing against 0.  ...and that would be an API change for
schedule_hrtimeout_range_clock(), and it seems like that would be yet
another source of bugs.  ...and this is to save an instruction?  It
doesn't seem worth it.


-Doug


From heiko at sntech.de  Tue Oct 11 13:34:55 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 11 Oct 2016 22:34:55 +0200
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <alpine.DEB.2.20.1610110908240.7794@nanos>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
 <alpine.DEB.2.20.1610110908240.7794@nanos>
Message-ID: <147626835.p3yipu2Yfe@phil>

Am Dienstag, 11. Oktober 2016, 09:14:38 CEST schrieb Thomas Gleixner:
> On Mon, 10 Oct 2016, Douglas Anderson wrote:
> > Users of usleep_range() expect that it will _never_ return in less time
> > than the minimum passed parameter.  However, nothing in any of the code
> 
> > ensures this.  Specifically:
> There is no such guarantee for that interface and never has been, so how
> did you make sure that none of the existing users is relying on this?
>
> You can't just can't just declare that all all of the users expect that and
> be done with it.

It may be my personal ignorance for not finding this explained, but the 
function documentation [0] states "min ... Minimum time in usecs to sleep"
which sounds pretty guaranteed to me.

One should of course make sure to not break anything intentionally, but having 
things expect to work outside these parameters sounds somewhat broken

If the specified values are flexible beyond their stated range, I guess the 
documentation should be updated to reflect that.


[0] https://www.kernel.org/doc/htmldocs/device-drivers/API-usleep-range.html



From andi at lisas.de  Tue Oct 11 13:40:03 2016
From: andi at lisas.de (Andreas Mohr)
Date: Tue, 11 Oct 2016 22:40:03 +0200
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <CAD=FV=Ua8c18SGr54ThmVe1oR3bqfCyHxfhL=6z8vJXkMiUedA@mail.gmail.com>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
 <20161011193034.GA10646@rhlx01.hs-esslingen.de>
 <CAD=FV=Ua8c18SGr54ThmVe1oR3bqfCyHxfhL=6z8vJXkMiUedA@mail.gmail.com>
Message-ID: <20161011204003.GA21387@rhlx01.hs-esslingen.de>

On Tue, Oct 11, 2016 at 01:02:10PM -0700, Doug Anderson wrote:
> Andreas,
> 
> On Tue, Oct 11, 2016 at 12:30 PM, Andreas Mohr <andi at lisas.de> wrote:
> > This loop implementation relies on negative kmin (result of ktime_sub())
> > getting internally handled by schedule_hrtimeout_range() as a 0 result.
> > If that ain't the case, then the loop itself will need to handle
> > negative values.
> > OK, scratch that, due to guaranteed-unchanged values of now and end,
> > result of directly subsequent ktime_sub() is guaranteed to
> > not deviate from what ktime_before() figured.
> > However, this is somewhat differing handling of these two APIs.
> 
> I read this as: no bug, feel free to ignore.

Heh, yeah ("an alternate style of review" ;).


> I agree that we could try to save some math by making the loop more
> complicated.  On the other hand, one could argue that a sufficiently
> good compiler might actually be able to figure some of this stuff out,
> since much of this stuff is just inlined 64-bit math comparisons.

Indeed. "micro-optimization again".


> > BTW, another argument for loop rework might be that
> > the result of ktime_sub() might already be improper
> > (due to being negative!) for
> > subsequent invocation of schedule_hrtimeout_range(),
> > i.e. there's an argument to be made that
> > the loop tail check instead ought to be done as a negative-value check
> > directly prior to schedule_hrtimeout_range() invocation.
> >
> > Hmm, if schedule_hrtimeout_range() can be relied on to
> > internally properly be doing the negative check,
> > then one could simply say that
> > the annoyingly extra calculation via ktime_before() call
> > should simply be removed completely.
> > Which would be a good step since it would centralize protocol behaviour
> > within the inner handling of the helper
> > rather than bloating user-side instruction cache footprint.
> 
> Ah, so you're saying just do a "while (true)" after changing the
> behavior of schedule_hrtimeout_range_clock().  If everyone agrees that
> they'd like to see this, I can do it.  I'd have to change
> schedule_hrtimeout_range_clock() to check for <= 0 instead of just
> comparing against 0.  ...and that would be an API change for
> schedule_hrtimeout_range_clock(), and it seems like that would be yet
> another source of bugs.  ...and this is to save an instruction?  It
> doesn't seem worth it.

Yup, I just realized that probably what we'd ideally want is
a very thin decorating wrapper (loop handler)
which cares about nothing else other than
eradicating the relevant "feature" of the inner handler
(namely, premature exit),
and otherwise leaves a much as possible to
central inner handler decision-making implementation.
That to me sounds like
the theoretically most precise (since dead simple) handling.
And even if such exceedingly simple handling is dangerous -
in case of failure we would realize it very soon (infinite loop),
and would then know what will need fixing.


I've been reviewing schedule_hrtimeout_range_clock() as well,
and I'm actually puzzled that it checks for zero value only,
and not less-equal zero.
That to me does not seem like a true-to-the-core protocol
to handle the task at hand.
OTOH perhaps less-equal comparison was deemed to be
much more expensive than a zero check,
and thus possibly has been done in inner handlers only.



For the loop code itself,
I'm not sure whether to pursue it -
given the schedule_hrtimeout_range_clock() API change risks you outlined,
and especially given that
optimization is likely to mostly benefit the "repeat" case only,
which likely would be the less relevant non-hotpath case anyway.

Plus, let's not forget the fact that
even hotpath handling *is* an invocation of the entire delay handler,
and then a couple measly opcodes to have the loop exited reliably. So...


Now, at least we have a
Reviewed-by: Andreas Mohr <andim2 at users.sf.net>


Oh well, lotsa discussion, some good thoughts,
but no truly revolutionary outcome so far.
However, sometimes the most important thing is
to have had a good educating discussion
(not everything in software circles is about the Get Rich Quick scheme -
you do have to spend some ample time - decades... -
to truly get mental concept things right).

Andreas Mohr


From heiko at sntech.de  Tue Oct 11 14:56:39 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 11 Oct 2016 23:56:39 +0200
Subject: [PATCH 2/2] ARM: dts: rockchip: enable HS200/DDR52 mode for emmc
 on rk3288-popmetal
In-Reply-To: <1476102826-7143-2-git-send-email-shawn.lin@rock-chips.com>
References: <1476102826-7143-1-git-send-email-shawn.lin@rock-chips.com>
 <1476102826-7143-2-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <30132025.B40M3pXsTH@phil>

Am Montag, 10. Oktober 2016, 20:33:46 CEST schrieb Shawn Lin:
> Enable these two modes to speed up the booting and improve
> the performance.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

applied both patches for 4.10 after moving the mmc-* above non-removable


Thanks
Heiko

> ---
> 
>  arch/arm/boot/dts/rk3288-popmetal.dts | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288-popmetal.dts
> b/arch/arm/boot/dts/rk3288-popmetal.dts index 3831cd5..7500e98 100644
> --- a/arch/arm/boot/dts/rk3288-popmetal.dts
> +++ b/arch/arm/boot/dts/rk3288-popmetal.dts
> @@ -148,6 +148,8 @@
>  	cap-mmc-highspeed;
>  	disable-wp;
>  	non-removable;
> +	mmc-ddr-1_8v;
> +	mmc-hs200-1_8v;
>  	num-slots = <1>;
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_pwr &emmc_bus8>;




From heiko at sntech.de  Tue Oct 11 15:00:12 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Wed, 12 Oct 2016 00:00:12 +0200
Subject: [PATCH v1 1/2] include: dt-bindings: Add GPIO pin index
 definition for rockchip pinctrl
In-Reply-To: <1473210053-23743-1-git-send-email-andy.yan@rock-chips.com>
References: <1473210053-23743-1-git-send-email-andy.yan@rock-chips.com>
Message-ID: <13068948.jkWM1OvpR7@phil>

Am Mittwoch, 7. September 2016, 09:00:53 CEST schrieb Andy Yan:
> Add gpio pin index definition to make it easier to describe
> GPIO in dts.
> 
> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>

just as a heads up, as I didn't respond yet:

Looks good and I'll take them, I just want to wait for the merge-window to 
close (should be the coming sunday), to be able to put the header change in a 
shared branch for the case that other users appear during the 4.10 cycle.


Heiko

> ---
> 
> Changes in v1:
> - remove gpio bank definition RK_GPIO7/8
> - redefine GPIO PIN as RK_PA/B/C/Dx
> 
>  include/dt-bindings/pinctrl/rockchip.h | 33
> +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
> 
> diff --git a/include/dt-bindings/pinctrl/rockchip.h
> b/include/dt-bindings/pinctrl/rockchip.h index 743e66a..aaec8ba 100644
> --- a/include/dt-bindings/pinctrl/rockchip.h
> +++ b/include/dt-bindings/pinctrl/rockchip.h
> @@ -25,6 +25,39 @@
>  #define RK_GPIO4	4
>  #define RK_GPIO6	6
> 
> +#define RK_PA0		0
> +#define RK_PA1		1
> +#define RK_PA2		2
> +#define RK_PA3		3
> +#define RK_PA4		4
> +#define RK_PA5		5
> +#define RK_PA6		6
> +#define RK_PA7		7
> +#define RK_PB0		8
> +#define RK_PB1		9
> +#define RK_PB2		10
> +#define RK_PB3		11
> +#define RK_PB4		12
> +#define RK_PB5		13
> +#define RK_PB6		14
> +#define RK_PB7		15
> +#define RK_PC0		16
> +#define RK_PC1		17
> +#define RK_PC2		18
> +#define RK_PC3		19
> +#define RK_PC4		20
> +#define RK_PC5		21
> +#define RK_PC6		22
> +#define RK_PC7		23
> +#define RK_PD0		24
> +#define RK_PD1		25
> +#define RK_PD2		26
> +#define RK_PD3		27
> +#define RK_PD4		28
> +#define RK_PD5		29
> +#define RK_PD6		30
> +#define RK_PD7		31
> +
>  #define RK_FUNC_GPIO	0
>  #define RK_FUNC_1	1
>  #define RK_FUNC_2	2




From shawn.lin at rock-chips.com  Tue Oct 11 19:01:23 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:01:23 +0800
Subject: [PATCH v7 1/3] Documentation/devicetree: Add new property to specify
 the max link speed
Message-ID: <1476237685-14539-1-git-send-email-shawn.lin@rock-chips.com>

Some of the host drivers have the requirement of knowing whether the
EP would never train at some link speed at all. For instance, on some
boards, the link won't train at 5 GT/s but the host driver still sacrifice
some cycle to wait for the resule of training at 5 GT/s as the host could
actually support 5 GT/s. So we could parse this new property and make the
host drivers be aware of these cases.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/pci/pci.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
index 08dcfad..e7d97a3 100644
--- a/Documentation/devicetree/bindings/pci/pci.txt
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -18,3 +18,9 @@ driver implementation may support the following properties:
    host bridges in the system, otherwise potentially conflicting domain numbers
    may be assigned to root buses behind different host bridges.  The domain
    number for each host bridge in the system must be unique.
+- max-link-speed:
+   If present this property specifies PCI gen for link capability. The host drivers
+   could add this as a strategy to avoid unnecessary operation for unsupported
+   link speed, for instance, trying to do training for unsupported link speed, etc.
+   Must be '4' for gen4, '3' for gen3, '2' for gen2, and '1' for gen1. Any other
+   values are invalid.
-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:01:24 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:01:24 +0800
Subject: [PATCH v7 2/3] of/pci: Add helper function to parse max-link-speed
 from dt
In-Reply-To: <1476237685-14539-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476237685-14539-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476237685-14539-2-git-send-email-shawn.lin@rock-chips.com>

This new helper function could be used by host drivers to
get the limitaion of max link speed provided by dt. If the
property isn't assigned or is invalid, it will return -EINVAL
to the caller.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v7:
- rename the function name and using of_property_read_u32
  suggested by Rob

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/of/of_pci.c    | 21 +++++++++++++++++++++
 include/linux/of_pci.h |  7 +++++++
 2 files changed, 28 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 589b30c..0c566ca 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -120,6 +120,27 @@ int of_get_pci_domain_nr(struct device_node *node)
 EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
 
 /**
+ * This function will try to find the limitation of link speed by finding
+ * a property called "max-link-speed" of the given device node.
+ *
+ * @node: device tree node with the max link speed information
+ *
+ * Returns the associated max link speed from DT, or a negative value if the
+ * required property is not found or is invalid.
+ */
+int of_pci_get_max_link_speed(struct device_node *node)
+{
+	u32 max_link_speed;
+
+	if (of_property_read_u32(node, "max-link-speed", &max_link_speed) ||
+	    max_link_speed > 4)
+		return -EINVAL;
+
+	return max_link_speed;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_max_link_speed);
+
+/**
  * of_pci_check_probe_only - Setup probe only mode if linux,pci-probe-only
  *                           is present and valid
  */
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index b969e94..2e668e3 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -16,6 +16,7 @@ int of_pci_get_devfn(struct device_node *np);
 int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 int of_get_pci_domain_nr(struct device_node *node);
+int of_pci_get_max_link_speed(struct device_node *node);
 void of_pci_check_probe_only(void);
 #else
 static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq)
@@ -52,6 +53,12 @@ of_get_pci_domain_nr(struct device_node *node)
 	return -1;
 }
 
+static inline int
+of_pci_get_max_link_speed(struct device_node *node)
+{
+	return -EINVAL;
+}
+
 static inline void of_pci_check_probe_only(void) { }
 #endif
 
-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:01:25 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:01:25 +0800
Subject: [PATCH v7 3/3] PCI: rockchip: Specify the link capability
In-Reply-To: <1476237685-14539-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476237685-14539-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476237685-14539-3-git-send-email-shawn.lin@rock-chips.com>

From: Brian Norris <briannorris at chromium.org>

rk3399 supports PCIe 2.x link speeds marginally at best, and on some
boards, the link won't train at 5 GT/s at all. Rather than sacrifice
500ms waiting for training that will never happen, let's use the helper
function, of_pci_get_max_link_speed, to get the max link speed from DT
and specify link capability.

Signed-off-by: Brian Norris <briannorris at chromium.org>
Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v7:
- rebase on Bjorn's host-rockcip branch again since it isn't applied
  cleanly after the cleanup
- call new function, of_pci_get_max_link_speed.

Changes in v6:
- user helper function of_get_pci_max_link_speed and use gen2 by default
  if finding any errors from of_get_pci_max_link_speed. It could be
  backward compatibe to the old dtb. (Suggested by Rob)

Changes in v5:
- rebase the code since it isn't cleanly applied after Bjorn's cleanup

Changes in v4:
- define link_gen as u32
- elaborate more for rockchip,max-link-speed on doc

Changes in v3:
- Cast a warning for invalid max link speed and use gen1 for it.
  That looks better than v2. (Suggested by Brian)

Changes in v2:
- rename the property to rockchip,max-link-speed according to
  Bjorn's recommendation and take some bits from imx6q-pcie to
  make this requirement more consisent.

 drivers/pci/host/pcie-rockchip.c | 67 ++++++++++++++++++++++++----------------
 1 file changed, 41 insertions(+), 26 deletions(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index db917c7..03734b7 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -53,6 +53,7 @@
 #define   PCIE_CLIENT_ARI_ENABLE	  HIWORD_UPDATE_BIT(0x0008)
 #define   PCIE_CLIENT_CONF_LANE_NUM(x)	  HIWORD_UPDATE(0x0030, ENCODE_LANES(x))
 #define   PCIE_CLIENT_MODE_RC		  HIWORD_UPDATE_BIT(0x0040)
+#define   PCIE_CLIENT_GEN_SEL_1		  HIWORD_UPDATE(0x0080, 0)
 #define   PCIE_CLIENT_GEN_SEL_2		  HIWORD_UPDATE_BIT(0x0080)
 #define PCIE_CLIENT_BASIC_STATUS1	(PCIE_CLIENT_BASE + 0x48)
 #define   PCIE_CLIENT_LINK_STATUS_UP		0x00300000
@@ -200,6 +201,7 @@ struct rockchip_pcie {
 	struct	gpio_desc *ep_gpio;
 	u32	lanes;
 	u8	root_bus_nr;
+	int	link_gen;
 	struct	device *dev;
 	struct	irq_domain *irq_domain;
 };
@@ -441,13 +443,19 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip_pcie)
 		return err;
 	}
 
+	if (rockchip_pcie->link_gen == 2)
+		rockchip_pcie_writel(rockchip_pcie, PCIE_CLIENT_CONFIG,
+				PCIE_CLIENT_GEN_SEL_2);
+	else
+		rockchip_pcie_writel(rockchip_pcie, PCIE_CLIENT_CONFIG,
+				PCIE_CLIENT_GEN_SEL_1);
+
 	rockchip_pcie_writel(rockchip_pcie, PCIE_CLIENT_CONFIG,
-			    PCIE_CLIENT_CONF_ENABLE |
-			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
-			    PCIE_CLIENT_ARI_ENABLE |
-			    PCIE_CLIENT_CONF_LANE_NUM(rockchip_pcie->lanes) |
-			    PCIE_CLIENT_MODE_RC |
-			    PCIE_CLIENT_GEN_SEL_2);
+			     PCIE_CLIENT_CONF_ENABLE |
+			     PCIE_CLIENT_LINK_TRAIN_ENABLE |
+			     PCIE_CLIENT_ARI_ENABLE |
+			     PCIE_CLIENT_CONF_LANE_NUM(rockchip_pcie->lanes) |
+			     PCIE_CLIENT_MODE_RC);
 
 	err = phy_power_on(rockchip_pcie->phy);
 	if (err) {
@@ -526,29 +534,32 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip_pcie)
 		msleep(20);
 	}
 
-	/*
-	 * Enable retrain for gen2. This should be configured only after
-	 * gen1 finished.
-	 */
-	status = rockchip_pcie_readl(rockchip_pcie, PCIE_RC_CONFIG_LCS);
-	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
-	rockchip_pcie_writel(rockchip_pcie, PCIE_RC_CONFIG_LCS, status);
+	if (rockchip_pcie->link_gen == 2) {
+		/*
+		 * Enable retrain for gen2. This should be configured
+		 * only after gen1 finished.
+		 */
+		status = rockchip_pcie_readl(rockchip_pcie, PCIE_RC_CONFIG_LCS);
+		status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
+		rockchip_pcie_writel(rockchip_pcie, PCIE_RC_CONFIG_LCS, status);
+
+		timeout = jiffies + msecs_to_jiffies(500);
+		for (;;) {
+			status = rockchip_pcie_readl(rockchip_pcie,
+						     PCIE_CORE_CTRL);
+			if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
+			    PCIE_CORE_PL_CONF_SPEED_5G) {
+				dev_dbg(dev, "PCIe link training gen2 pass!\n");
+				break;
+			}
 
-	timeout = jiffies + msecs_to_jiffies(500);
-	for (;;) {
-		status = rockchip_pcie_readl(rockchip_pcie, PCIE_CORE_CTRL);
-		if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
-		    PCIE_CORE_PL_CONF_SPEED_5G) {
-			dev_dbg(dev, "PCIe link training gen2 pass!\n");
-			break;
-		}
+			if (time_after(jiffies, timeout)) {
+				dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
+				break;
+			}
 
-		if (time_after(jiffies, timeout)) {
-			dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
-			break;
+			msleep(20);
 		}
-
-		msleep(20);
 	}
 
 	/* Check the final link width from negotiated lane counter from MGMT */
@@ -756,6 +767,10 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip_pcie)
 		rockchip_pcie->lanes = 1;
 	}
 
+	rockchip_pcie->link_gen = of_pci_get_max_link_speed(node);
+	if (rockchip_pcie->link_gen < 0 || rockchip_pcie->link_gen > 2)
+		rockchip_pcie->link_gen = 2;
+
 	rockchip_pcie->core_rst = devm_reset_control_get(dev, "core");
 	if (IS_ERR(rockchip_pcie->core_rst)) {
 		if (PTR_ERR(rockchip_pcie->core_rst) != -EPROBE_DEFER)
-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:05:01 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:05:01 +0800
Subject: [PATCH v3 1/3] PCI: rockchip: Provide captured slot power limit and
 scale
Message-ID: <1476237903-15076-1-git-send-email-shawn.lin@rock-chips.com>

If vpcie3v3 is available, we could provide these information
via RC's configure register to make EP able to know the power
limit.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v3:
- rebase the code since it isn't cleanly applied again.

Changes in v2:
- rebase the code since it isn't cleanly applied after Bjorn's cleanup

 drivers/pci/host/pcie-rockchip.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index db917c7..a67ff9e 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -135,6 +135,10 @@
 #define PCIE_RC_CONFIG_VENDOR		(PCIE_RC_CONFIG_BASE + 0x00)
 #define PCIE_RC_CONFIG_RID_CCR		(PCIE_RC_CONFIG_BASE + 0x08)
 #define   PCIE_RC_CONFIG_SCC_SHIFT		16
+#define PCIE_RC_CONFIG_DCR		(PCIE_RC_CONFIG_BASE + 0xc4)
+#define   PCIE_RC_CONFIG_DCR_CSPL_SHIFT		18
+#define   PCIE_RC_CONFIG_DCR_CSPL_LIMIT		0xff
+#define   PCIE_RC_CONFIG_DCR_CPLS_SHIFT		26
 #define PCIE_RC_CONFIG_LCS		(PCIE_RC_CONFIG_BASE + 0xd0)
 #define   PCIE_RC_CONFIG_LCS_RETRAIN_LINK	BIT(5)
 #define   PCIE_RC_CONFIG_LCS_LBMIE		BIT(10)
@@ -398,6 +402,40 @@ static struct pci_ops rockchip_pcie_ops = {
 	.write = rockchip_pcie_wr_conf,
 };
 
+static void rockchip_pcie_set_power_limit(struct rockchip_pcie *rockchip_pcie)
+{
+	u32 status, curr, scale, power;
+
+	if (IS_ERR(rockchip_pcie->vpcie3v3))
+		return;
+
+	/*
+	 * Set RC's captured slot power limit and scale if
+	 * vpcie3v3 available. The default values are both zero
+	 * which means the software should set these two according
+	 * to the actual power supply.
+	 */
+	curr = regulator_get_current_limit(rockchip_pcie->vpcie3v3);
+	if (curr > 0) {
+		scale = 3; /* 0.001x */
+		curr = curr / 1000; /* convert to mA */
+		power = (curr * 3300) / 1000; /* milliwatt */
+		while (power > PCIE_RC_CONFIG_DCR_CSPL_LIMIT) {
+			if (!scale) {
+				dev_warn(rockchip_pcie->dev, "invalid power supply\n");
+				return;
+			}
+			scale--;
+			power = power / 10;
+		}
+
+		status = rockchip_pcie_readl(rockchip_pcie, PCIE_RC_CONFIG_DCR);
+		status |= (power << PCIE_RC_CONFIG_DCR_CSPL_SHIFT) |
+			  (scale << PCIE_RC_CONFIG_DCR_CPLS_SHIFT);
+		rockchip_pcie_writel(rockchip_pcie, PCIE_RC_CONFIG_DCR, status);
+	}
+}
+
 /**
  * rockchip_pcie_init_port - Initialize hardware
  * @rockchip_pcie: PCIe port information
@@ -500,6 +538,8 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip_pcie)
 		 (PCIE_CORE_CTRL_PLC1_FTS_CNT << PCIE_CORE_CTRL_PLC1_FTS_SHIFT);
 	rockchip_pcie_writel(rockchip_pcie, PCIE_CORE_CTRL_PLC1, status);
 
+	rockchip_pcie_set_power_limit(rockchip_pcie);
+
 	/* Enable Gen1 training */
 	rockchip_pcie_writel(rockchip_pcie, PCIE_CLIENT_CONFIG,
 			PCIE_CLIENT_LINK_TRAIN_ENABLE);
-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:05:02 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:05:02 +0800
Subject: [PATCH v3 2/3] PCI: rockchip: Mark RC as common clock architecture
In-Reply-To: <1476237903-15076-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476237903-15076-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476237903-15076-2-git-send-email-shawn.lin@rock-chips.com>

The default value of common clock configuration is
zero indicating Rockchip's RC is using asynchronous
clock architecture but actually we are using common
clock. This will confuses some EP drivers if they
need some different settings referring to this value.
So let's fix it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v3:
- rebase the code since it isn't cleanly applied again

Changes in v2:
- rebase the code since it isn't cleanly applied after Bjorn's cleanup

 drivers/pci/host/pcie-rockchip.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index a67ff9e..d51afe6 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -141,6 +141,7 @@
 #define   PCIE_RC_CONFIG_DCR_CPLS_SHIFT		26
 #define PCIE_RC_CONFIG_LCS		(PCIE_RC_CONFIG_BASE + 0xd0)
 #define   PCIE_RC_CONFIG_LCS_RETRAIN_LINK	BIT(5)
+#define   PCIE_RC_CONFIG_LCS_CCC		BIT(6)
 #define   PCIE_RC_CONFIG_LCS_LBMIE		BIT(10)
 #define   PCIE_RC_CONFIG_LCS_LABIE		BIT(11)
 #define   PCIE_RC_CONFIG_LCS_LBMS		BIT(30)
@@ -540,6 +541,11 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip_pcie)
 
 	rockchip_pcie_set_power_limit(rockchip_pcie);
 
+	/* Set RC's clock architecture as common clock */
+	status = rockchip_pcie_readl(rockchip_pcie, PCIE_RC_CONFIG_LCS);
+	status |= PCIE_RC_CONFIG_LCS_CCC;
+	rockchip_pcie_writel(rockchip_pcie, PCIE_RC_CONFIG_LCS, status);
+
 	/* Enable Gen1 training */
 	rockchip_pcie_writel(rockchip_pcie, PCIE_CLIENT_CONFIG,
 			PCIE_CLIENT_LINK_TRAIN_ENABLE);
-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:05:03 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:05:03 +0800
Subject: [PATCH v3 3/3] PCI: rockchip: add COMPILE_TEST for Kconfig
In-Reply-To: <1476237903-15076-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476237903-15076-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476237903-15076-3-git-send-email-shawn.lin@rock-chips.com>

Add this could help build the driver if we enable
CONFIG_COMPILE_TEST.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

Changes in v3: None
Changes in v2: None

 drivers/pci/host/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d7e7c0a..096440e 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -276,7 +276,7 @@ config PCIE_ARTPEC6
 
 config PCIE_ROCKCHIP
 	bool "Rockchip PCIe controller"
-	depends on ARCH_ROCKCHIP
+	depends on ARCH_ROCKCHIP || COMPILE_TEST
 	depends on OF
 	depends on PCI_MSI_IRQ_DOMAIN
 	select MFD_SYSCON
-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:50:34 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:50:34 +0800
Subject: [PATCH v2 0/9] Init runtime PM support for dw_mmc
Message-ID: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>


Hi Jaehoon and Ulf,

   This patch is gonna support runtime PM for dw_mmc.
It could support to disable ciu_clk by default and disable
biu_clk if the devices are non-removeable, or removeable
with gpio-base card detect.

   Then I remove the system PM since the runtime PM actually
does the same thing as it. So I help migrate the dw_mmc variant
drivers to use runtime PM pairs and pm_runtime_force_*. Note
that I only enable runtime PM for dw_mmc-rockchip as I will
leave the decision to the owners of the corresponding drivers.
I just tested it on my RK3288 platform with linux-next to make
the runtime PM and system PM work fine for my emmc, sd card and
sdio. But I don't have hardware to help test other variant drivers.
But in theory it should work fine as I mentioned that the runtime
PM does the same thing as system PM except for disabling ciu_clk
aggressively which should not be related to the variant hosts.

   As you could see that I just extend the slot-gpio a bit, so the
ideal way is Ulf could pick them up with Jaehoon's ack. :)


Changes in v2:
- use struct device as argument for runtime callback
- use dw_mci_runtime_* directly
- use dw_mci_runtime_* directly
- minor fix since I change the argument for dw_mci_runtime_*
- use dw_mci_runtime_* directly
- use dw_mci_runtime_* directly

Shawn Lin (9):
  mmc: dw_mmc: add runtime PM callback
  mmc: dw_mmc-rockchip: add runtime PM support
  mmc: core: expose the capability of gpio card detect
  mmc: dw_mmc: disable biu clk if possible
  mmc: dw_mmc-k3: deploy runtime PM facilities
  mmc: dw_mmc-exynos: deploy runtime PM facilities
  mmc: dw_mmc-pci: deploy runtime PM facilities
  mmc: dw_mmc-pltfm: deploy runtime PM facilities
  mmc: dw_mmc: remove system PM callback

 drivers/mmc/core/slot-gpio.c       |  8 +++++++
 drivers/mmc/host/dw_mmc-exynos.c   | 24 +++++++++-----------
 drivers/mmc/host/dw_mmc-k3.c       | 39 ++++++++------------------------
 drivers/mmc/host/dw_mmc-pci.c      | 29 ++++++++----------------
 drivers/mmc/host/dw_mmc-pltfm.c    | 28 +++++++----------------
 drivers/mmc/host/dw_mmc-rockchip.c | 42 +++++++++++++++++++++++++++++++---
 drivers/mmc/host/dw_mmc.c          | 46 +++++++++++++++++++++++++-------------
 drivers/mmc/host/dw_mmc.h          |  6 ++---
 include/linux/mmc/slot-gpio.h      |  1 +
 9 files changed, 117 insertions(+), 106 deletions(-)

-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:50:35 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:50:35 +0800
Subject: [PATCH v2 1/9] mmc: dw_mmc: add runtime PM callback
In-Reply-To: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476240643-5701-2-git-send-email-shawn.lin@rock-chips.com>

This patch add dw_mci_runtime_suspend/resume interfaces
and expose it to dw_mci variant driver to support runtime
PM.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v2:
- use struct device as argument for runtime callback

 drivers/mmc/host/dw_mmc.c | 32 ++++++++++++++++++++++++++++++--
 drivers/mmc/host/dw_mmc.h |  4 +++-
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 4fcbc40..67fa088 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3266,7 +3266,7 @@ EXPORT_SYMBOL(dw_mci_remove);
 
 
 
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
 /*
  * TODO: we should probably disable the clock to the card in the suspend path.
  */
@@ -3324,7 +3324,35 @@ int dw_mci_resume(struct dw_mci *host)
 	return 0;
 }
 EXPORT_SYMBOL(dw_mci_resume);
-#endif /* CONFIG_PM_SLEEP */
+
+int dw_mci_runtime_suspend(struct device *dev)
+{
+	int err = 0;
+	struct dw_mci *host = dev_get_drvdata(dev);
+
+	err = dw_mci_suspend(host);
+	if (err)
+		return err;
+
+	clk_disable_unprepare(host->ciu_clk);
+
+	return err;
+}
+EXPORT_SYMBOL(dw_mci_runtime_suspend);
+
+int dw_mci_runtime_resume(struct device *dev)
+{
+	int ret = 0;
+	struct dw_mci *host = dev_get_drvdata(dev);
+
+	ret = clk_prepare_enable(host->ciu_clk);
+	if (ret)
+		return ret;
+
+	return dw_mci_resume(host);
+}
+EXPORT_SYMBOL(dw_mci_runtime_resume);
+#endif /* CONFIG_PM */
 
 static int __init dw_mci_init(void)
 {
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index e8cd2de..d14a391 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -234,9 +234,11 @@
 
 extern int dw_mci_probe(struct dw_mci *host);
 extern void dw_mci_remove(struct dw_mci *host);
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
 extern int dw_mci_suspend(struct dw_mci *host);
 extern int dw_mci_resume(struct dw_mci *host);
+extern int dw_mci_runtime_suspend(struct device *device);
+extern int dw_mci_runtime_resume(struct device *device);
 #endif
 
 /**
-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:50:36 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:50:36 +0800
Subject: [PATCH v2 2/9] mmc: dw_mmc-rockchip: add runtime PM support
In-Reply-To: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476240643-5701-3-git-send-email-shawn.lin@rock-chips.com>

This patch adds runtime PM support for dw_mmc-rockchip.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v2:
- use dw_mci_runtime_* directly

 drivers/mmc/host/dw_mmc-rockchip.c | 41 +++++++++++++++++++++++++++++++++++---
 1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
index 25eae35..0a05ad3 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -13,6 +13,7 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/dw_mmc.h>
 #include <linux/of_address.h>
+#include <linux/pm_runtime.h>
 #include <linux/slab.h>
 
 #include "dw_mmc.h"
@@ -325,6 +326,7 @@ static int dw_mci_rockchip_probe(struct platform_device *pdev)
 {
 	const struct dw_mci_drv_data *drv_data;
 	const struct of_device_id *match;
+	int ret;
 
 	if (!pdev->dev.of_node)
 		return -ENODEV;
@@ -332,16 +334,49 @@ static int dw_mci_rockchip_probe(struct platform_device *pdev)
 	match = of_match_node(dw_mci_rockchip_match, pdev->dev.of_node);
 	drv_data = match->data;
 
-	return dw_mci_pltfm_register(pdev, drv_data);
+	pm_runtime_get_noresume(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
+	pm_runtime_use_autosuspend(&pdev->dev);
+
+	ret = dw_mci_pltfm_register(pdev, drv_data);
+	if (ret) {
+		pm_runtime_disable(&pdev->dev);
+		pm_runtime_set_suspended(&pdev->dev);
+		pm_runtime_put_noidle(&pdev->dev);
+		return ret;
+	}
+
+	pm_runtime_put_autosuspend(&pdev->dev);
+
+	return 0;
 }
 
+static int dw_mci_rockchip_remove(struct platform_device *pdev)
+{
+	pm_runtime_get_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+	pm_runtime_put_noidle(&pdev->dev);
+
+	return dw_mci_pltfm_remove(pdev);
+}
+
+static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
+			   dw_mci_runtime_resume,
+			   NULL)
+};
+
 static struct platform_driver dw_mci_rockchip_pltfm_driver = {
 	.probe		= dw_mci_rockchip_probe,
-	.remove		= dw_mci_pltfm_remove,
+	.remove		= dw_mci_rockchip_remove,
 	.driver		= {
 		.name		= "dwmmc_rockchip",
 		.of_match_table	= dw_mci_rockchip_match,
-		.pm		= &dw_mci_pltfm_pmops,
+		.pm		= &dw_mci_rockchip_dev_pm_ops,
 	},
 };
 
-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:50:37 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:50:37 +0800
Subject: [PATCH v2 3/9] mmc: core: expose the capability of gpio card detect
In-Reply-To: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476240643-5701-4-git-send-email-shawn.lin@rock-chips.com>

Add new helper API mmc_can_gpio_cd for slot-gpio to make
host drivers know whether it supports gpio card detect.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

Changes in v2: None

 drivers/mmc/core/slot-gpio.c  | 8 ++++++++
 include/linux/mmc/slot-gpio.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index 27117ba..babe591 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -258,6 +258,14 @@ int mmc_gpiod_request_cd(struct mmc_host *host, const char *con_id,
 }
 EXPORT_SYMBOL(mmc_gpiod_request_cd);
 
+bool mmc_can_gpio_cd(struct mmc_host *host)
+{
+	struct mmc_gpio *ctx = host->slot.handler_priv;
+
+	return ctx->cd_gpio ? true : false;
+}
+EXPORT_SYMBOL(mmc_can_gpio_cd);
+
 /**
  * mmc_gpiod_request_ro - request a gpio descriptor for write protection
  * @host: mmc host
diff --git a/include/linux/mmc/slot-gpio.h b/include/linux/mmc/slot-gpio.h
index 3945a8c..a7972cd 100644
--- a/include/linux/mmc/slot-gpio.h
+++ b/include/linux/mmc/slot-gpio.h
@@ -29,5 +29,6 @@ int mmc_gpiod_request_ro(struct mmc_host *host, const char *con_id,
 void mmc_gpio_set_cd_isr(struct mmc_host *host,
 			 irqreturn_t (*isr)(int irq, void *dev_id));
 void mmc_gpiod_request_cd_irq(struct mmc_host *host);
+bool mmc_can_gpio_cd(struct mmc_host *host);
 
 #endif
-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:50:38 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:50:38 +0800
Subject: [PATCH v2 4/9] mmc: dw_mmc: disable biu clk if possible
In-Reply-To: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476240643-5701-5-git-send-email-shawn.lin@rock-chips.com>

We could disable biu clk if gpio card detect available,
or it is a non-removable device.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

Changes in v2: None

 drivers/mmc/host/dw_mmc-rockchip.c |  1 +
 drivers/mmc/host/dw_mmc.c          | 13 +++++++++++++
 2 files changed, 14 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
index 0a05ad3..9a46e46 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -13,6 +13,7 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/dw_mmc.h>
 #include <linux/of_address.h>
+#include <linux/mmc/slot-gpio.h>
 #include <linux/pm_runtime.h>
 #include <linux/slab.h>
 
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 67fa088..297b6c2 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3336,6 +3336,11 @@ int dw_mci_runtime_suspend(struct device *dev)
 
 	clk_disable_unprepare(host->ciu_clk);
 
+	if (host->cur_slot &&
+	    (mmc_can_gpio_cd(host->cur_slot->mmc) ||
+	     !mmc_card_is_removable(host->cur_slot->mmc)))
+		clk_disable_unprepare(host->biu_clk);
+
 	return err;
 }
 EXPORT_SYMBOL(dw_mci_runtime_suspend);
@@ -3345,6 +3350,14 @@ int dw_mci_runtime_resume(struct device *dev)
 	int ret = 0;
 	struct dw_mci *host = dev_get_drvdata(dev);
 
+	if (host->cur_slot &&
+	    (mmc_can_gpio_cd(host->cur_slot->mmc) ||
+	     !mmc_card_is_removable(host->cur_slot->mmc))) {
+		ret = clk_prepare_enable(host->biu_clk);
+		if (ret)
+			return ret;
+	}
+
 	ret = clk_prepare_enable(host->ciu_clk);
 	if (ret)
 		return ret;
-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:54:40 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:54:40 +0800
Subject: [PATCH v2 5/9] mmc: dw_mmc-k3: deploy runtime PM facilities
In-Reply-To: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476240880-5761-1-git-send-email-shawn.lin@rock-chips.com>

Let's migrate it to use runtime PM and remove the system
PM callback from this driver. With this patch, it could
handle system PM properly and could also use runtime PM
if we enable it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v2:
- use dw_mci_runtime_* directly

 drivers/mmc/host/dw_mmc-k3.c | 39 +++++++++------------------------------
 1 file changed, 9 insertions(+), 30 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c
index 6247894..9821e6b 100644
--- a/drivers/mmc/host/dw_mmc-k3.c
+++ b/drivers/mmc/host/dw_mmc-k3.c
@@ -15,6 +15,7 @@
 #include <linux/module.h>
 #include <linux/of_address.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 
@@ -162,35 +163,13 @@ static int dw_mci_k3_probe(struct platform_device *pdev)
 	return dw_mci_pltfm_register(pdev, drv_data);
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int dw_mci_k3_suspend(struct device *dev)
-{
-	struct dw_mci *host = dev_get_drvdata(dev);
-	int ret;
-
-	ret = dw_mci_suspend(host);
-	if (!ret)
-		clk_disable_unprepare(host->ciu_clk);
-
-	return ret;
-}
-
-static int dw_mci_k3_resume(struct device *dev)
-{
-	struct dw_mci *host = dev_get_drvdata(dev);
-	int ret;
-
-	ret = clk_prepare_enable(host->ciu_clk);
-	if (ret) {
-		dev_err(host->dev, "failed to enable ciu clock\n");
-		return ret;
-	}
-
-	return dw_mci_resume(host);
-}
-#endif /* CONFIG_PM_SLEEP */
-
-static SIMPLE_DEV_PM_OPS(dw_mci_k3_pmops, dw_mci_k3_suspend, dw_mci_k3_resume);
+static const struct dev_pm_ops dw_mci_k3_dev_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
+			   dw_mci_runtime_resume,
+			   NULL)
+};
 
 static struct platform_driver dw_mci_k3_pltfm_driver = {
 	.probe		= dw_mci_k3_probe,
@@ -198,7 +177,7 @@ static struct platform_driver dw_mci_k3_pltfm_driver = {
 	.driver		= {
 		.name		= "dwmmc_k3",
 		.of_match_table	= dw_mci_k3_match,
-		.pm		= &dw_mci_k3_pmops,
+		.pm		= &dw_mci_k3_dev_pm_ops,
 	},
 };
 
-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:55:55 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:55:55 +0800
Subject: [PATCH v2 6/9] mmc: dw_mmc-exynos: deploy runtime PM facilities
In-Reply-To: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476240955-5808-1-git-send-email-shawn.lin@rock-chips.com>

Let's migrate it to use runtime PM and remove the system
PM callback from this driver. With this patch, it could
handle system PM properly and could also use runtime PM
if we enable it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v2:
- minor fix since I change the argument for dw_mci_runtime_*

 drivers/mmc/host/dw_mmc-exynos.c | 24 ++++++++++--------------
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 7ab3d74..e2439a1 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -17,6 +17,7 @@
 #include <linux/mmc/mmc.h>
 #include <linux/of.h>
 #include <linux/of_gpio.h>
+#include <linux/pm_runtime.h>
 #include <linux/slab.h>
 
 #include "dw_mmc.h"
@@ -161,20 +162,13 @@ static void dw_mci_exynos_set_clksel_timing(struct dw_mci *host, u32 timing)
 		set_bit(DW_MMC_CARD_NO_USE_HOLD, &host->cur_slot->flags);
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int dw_mci_exynos_suspend(struct device *dev)
-{
-	struct dw_mci *host = dev_get_drvdata(dev);
-
-	return dw_mci_suspend(host);
-}
-
-static int dw_mci_exynos_resume(struct device *dev)
+#ifdef CONFIG_PM
+static int dw_mci_exynos_runtime_resume(struct device *dev)
 {
 	struct dw_mci *host = dev_get_drvdata(dev);
 
 	dw_mci_exynos_config_smu(host);
-	return dw_mci_resume(host);
+	return dw_mci_runtime_resume(dev);
 }
 
 /**
@@ -211,10 +205,8 @@ static int dw_mci_exynos_resume_noirq(struct device *dev)
 	return 0;
 }
 #else
-#define dw_mci_exynos_suspend		NULL
-#define dw_mci_exynos_resume		NULL
 #define dw_mci_exynos_resume_noirq	NULL
-#endif /* CONFIG_PM_SLEEP */
+#endif /* CONFIG_PM */
 
 static void dw_mci_exynos_config_hs400(struct dw_mci *host, u32 timing)
 {
@@ -531,7 +523,11 @@ static int dw_mci_exynos_probe(struct platform_device *pdev)
 }
 
 static const struct dev_pm_ops dw_mci_exynos_pmops = {
-	SET_SYSTEM_SLEEP_PM_OPS(dw_mci_exynos_suspend, dw_mci_exynos_resume)
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
+			   dw_mci_exynos_runtime_resume,
+			   NULL)
 	.resume_noirq = dw_mci_exynos_resume_noirq,
 	.thaw_noirq = dw_mci_exynos_resume_noirq,
 	.restore_noirq = dw_mci_exynos_resume_noirq,
-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:56:34 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:56:34 +0800
Subject: [PATCH v2 7/9] mmc: dw_mmc-pci: deploy runtime PM facilities
In-Reply-To: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476240994-5849-1-git-send-email-shawn.lin@rock-chips.com>

Let's migrate it to use runtime PM and remove the system
PM callback from this driver. With this patch, it could
handle system PM properly and could also use runtime PM
if we enable it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v2:
- use dw_mci_runtime_* directly

 drivers/mmc/host/dw_mmc-pci.c | 29 +++++++++--------------------
 1 file changed, 9 insertions(+), 20 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-pci.c b/drivers/mmc/host/dw_mmc-pci.c
index 4c69fbd..ab82796 100644
--- a/drivers/mmc/host/dw_mmc-pci.c
+++ b/drivers/mmc/host/dw_mmc-pci.c
@@ -14,6 +14,7 @@
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/pci.h>
+#include <linux/pm_runtime.h>
 #include <linux/slab.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/mmc.h>
@@ -79,25 +80,13 @@ static void dw_mci_pci_remove(struct pci_dev *pdev)
 	dw_mci_remove(host);
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int dw_mci_pci_suspend(struct device *dev)
-{
-	struct pci_dev *pdev = to_pci_dev(dev);
-	struct dw_mci *host = pci_get_drvdata(pdev);
-
-	return dw_mci_suspend(host);
-}
-
-static int dw_mci_pci_resume(struct device *dev)
-{
-	struct pci_dev *pdev = to_pci_dev(dev);
-	struct dw_mci *host = pci_get_drvdata(pdev);
-
-	return dw_mci_resume(host);
-}
-#endif /* CONFIG_PM_SLEEP */
-
-static SIMPLE_DEV_PM_OPS(dw_mci_pci_pmops, dw_mci_pci_suspend, dw_mci_pci_resume);
+static const struct dev_pm_ops dw_mci_pci_dev_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
+			   dw_mci_runtime_resume,
+			   NULL)
+};
 
 static const struct pci_device_id dw_mci_pci_id[] = {
 	{ PCI_DEVICE(SYNOPSYS_DW_MCI_VENDOR_ID, SYNOPSYS_DW_MCI_DEVICE_ID) },
@@ -111,7 +100,7 @@ static struct pci_driver dw_mci_pci_driver = {
 	.probe		= dw_mci_pci_probe,
 	.remove		= dw_mci_pci_remove,
 	.driver		=	{
-		.pm =   &dw_mci_pci_pmops
+		.pm =   &dw_mci_pci_dev_pm_ops,
 	},
 };
 
-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:56:46 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:56:46 +0800
Subject: [PATCH v2 8/9] mmc: dw_mmc-pltfm: deploy runtime PM facilities
In-Reply-To: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476241006-5891-1-git-send-email-shawn.lin@rock-chips.com>

Let's migrate it to use runtime PM and remove the system
PM callback from this driver. With this patch, it could
handle system PM properly and could also use runtime PM
if we enable it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v2:
- use dw_mci_runtime_* directly

 drivers/mmc/host/dw_mmc-pltfm.c | 28 ++++++++--------------------
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index c0bb0c7..b486fef 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -16,6 +16,7 @@
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/slab.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/mmc.h>
@@ -57,26 +58,13 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
 }
 EXPORT_SYMBOL_GPL(dw_mci_pltfm_register);
 
-#ifdef CONFIG_PM_SLEEP
-/*
- * TODO: we should probably disable the clock to the card in the suspend path.
- */
-static int dw_mci_pltfm_suspend(struct device *dev)
-{
-	struct dw_mci *host = dev_get_drvdata(dev);
-
-	return dw_mci_suspend(host);
-}
-
-static int dw_mci_pltfm_resume(struct device *dev)
-{
-	struct dw_mci *host = dev_get_drvdata(dev);
-
-	return dw_mci_resume(host);
-}
-#endif /* CONFIG_PM_SLEEP */
-
-SIMPLE_DEV_PM_OPS(dw_mci_pltfm_pmops, dw_mci_pltfm_suspend, dw_mci_pltfm_resume);
+const struct dev_pm_ops dw_mci_pltfm_pmops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+	SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
+			   dw_mci_runtime_resume,
+			   NULL)
+};
 EXPORT_SYMBOL_GPL(dw_mci_pltfm_pmops);
 
 static const struct of_device_id dw_mci_pltfm_match[] = {
-- 
2.3.7




From shawn.lin at rock-chips.com  Tue Oct 11 19:56:55 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 10:56:55 +0800
Subject: [PATCH v2 9/9] mmc: dw_mmc: remove system PM callback
In-Reply-To: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476241015-5932-1-git-send-email-shawn.lin@rock-chips.com>

Now there are no variant drivers using dw_mci_suspend
and dw_mci_resume, so let's remove it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

Changes in v2: None

 drivers/mmc/host/dw_mmc.c | 81 ++++++++++++++++-------------------------------
 drivers/mmc/host/dw_mmc.h |  2 --
 2 files changed, 27 insertions(+), 56 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 297b6c2..1c9ee36 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3267,27 +3267,41 @@ EXPORT_SYMBOL(dw_mci_remove);
 
 
 #ifdef CONFIG_PM
-/*
- * TODO: we should probably disable the clock to the card in the suspend path.
- */
-int dw_mci_suspend(struct dw_mci *host)
+int dw_mci_runtime_suspend(struct device *dev)
 {
+	struct dw_mci *host = dev_get_drvdata(dev);
+
 	if (host->use_dma && host->dma_ops->exit)
 		host->dma_ops->exit(host);
 
+	clk_disable_unprepare(host->ciu_clk);
+
+	if (host->cur_slot &&
+	    (mmc_can_gpio_cd(host->cur_slot->mmc) ||
+	     !mmc_card_is_removable(host->cur_slot->mmc)))
+		clk_disable_unprepare(host->biu_clk);
+
 	return 0;
 }
-EXPORT_SYMBOL(dw_mci_suspend);
+EXPORT_SYMBOL(dw_mci_runtime_suspend);
 
-int dw_mci_resume(struct dw_mci *host)
+int dw_mci_runtime_resume(struct device *dev)
 {
-	int i, ret;
+	int i, ret = 0;
+	struct dw_mci *host = dev_get_drvdata(dev);
 
-	if (!dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS)) {
-		ret = -ENODEV;
-		return ret;
+	if (host->cur_slot &&
+	    (mmc_can_gpio_cd(host->cur_slot->mmc) ||
+	     !mmc_card_is_removable(host->cur_slot->mmc))) {
+		ret = clk_prepare_enable(host->biu_clk);
+		if (ret)
+			return ret;
 	}
 
+	ret = clk_prepare_enable(host->ciu_clk);
+	if (ret)
+		return ret;
+
 	if (host->use_dma && host->dma_ops->init)
 		host->dma_ops->init(host);
 
@@ -3295,8 +3309,8 @@ int dw_mci_resume(struct dw_mci *host)
 	 * Restore the initial value at FIFOTH register
 	 * And Invalidate the prev_blksz with zero
 	 */
-	mci_writel(host, FIFOTH, host->fifoth_val);
-	host->prev_blksz = 0;
+	 mci_writel(host, FIFOTH, host->fifoth_val);
+	 host->prev_blksz = 0;
 
 	/* Put in max timeout */
 	mci_writel(host, TMOUT, 0xFFFFFFFF);
@@ -3321,48 +3335,7 @@ int dw_mci_resume(struct dw_mci *host)
 	/* Now that slots are all setup, we can enable card detect */
 	dw_mci_enable_cd(host);
 
-	return 0;
-}
-EXPORT_SYMBOL(dw_mci_resume);
-
-int dw_mci_runtime_suspend(struct device *dev)
-{
-	int err = 0;
-	struct dw_mci *host = dev_get_drvdata(dev);
-
-	err = dw_mci_suspend(host);
-	if (err)
-		return err;
-
-	clk_disable_unprepare(host->ciu_clk);
-
-	if (host->cur_slot &&
-	    (mmc_can_gpio_cd(host->cur_slot->mmc) ||
-	     !mmc_card_is_removable(host->cur_slot->mmc)))
-		clk_disable_unprepare(host->biu_clk);
-
-	return err;
-}
-EXPORT_SYMBOL(dw_mci_runtime_suspend);
-
-int dw_mci_runtime_resume(struct device *dev)
-{
-	int ret = 0;
-	struct dw_mci *host = dev_get_drvdata(dev);
-
-	if (host->cur_slot &&
-	    (mmc_can_gpio_cd(host->cur_slot->mmc) ||
-	     !mmc_card_is_removable(host->cur_slot->mmc))) {
-		ret = clk_prepare_enable(host->biu_clk);
-		if (ret)
-			return ret;
-	}
-
-	ret = clk_prepare_enable(host->ciu_clk);
-	if (ret)
-		return ret;
-
-	return dw_mci_resume(host);
+	return ret;
 }
 EXPORT_SYMBOL(dw_mci_runtime_resume);
 #endif /* CONFIG_PM */
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index d14a391..4a6ae750 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -235,8 +235,6 @@
 extern int dw_mci_probe(struct dw_mci *host);
 extern void dw_mci_remove(struct dw_mci *host);
 #ifdef CONFIG_PM
-extern int dw_mci_suspend(struct dw_mci *host);
-extern int dw_mci_resume(struct dw_mci *host);
 extern int dw_mci_runtime_suspend(struct device *device);
 extern int dw_mci_runtime_resume(struct device *device);
 #endif
-- 
2.3.7




From broonie at kernel.org  Wed Oct 12 01:56:59 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 12 Oct 2016 10:56:59 +0200
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <CAD=FV=VTc-RFNiUqkKDr=NFWhphV7r2J+EudSbqt4X3TX62mQw@mail.gmail.com>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
 <alpine.DEB.2.20.1610110908240.7794@nanos>
 <CAD=FV=VTc-RFNiUqkKDr=NFWhphV7r2J+EudSbqt4X3TX62mQw@mail.gmail.com>
Message-ID: <20161012085659.y74qnipuwdblkjjh@sirena.org.uk>

On Tue, Oct 11, 2016 at 09:33:15AM -0700, Doug Anderson wrote:
> On Tue, Oct 11, 2016 at 12:14 AM, Thomas Gleixner <tglx at linutronix.de> wrote:
> > On Mon, 10 Oct 2016, Douglas Anderson wrote:

> >> Users of usleep_range() expect that it will _never_ return in less time
> >> than the minimum passed parameter.  However, nothing in any of the code
> >> ensures this.  Specifically:

> > There is no such guarantee for that interface and never has been, so how
> > did you make sure that none of the existing users is relying on this?

> > You can't just can't just declare that all all of the users expect that and
> > be done with it.

> You're right that I can't guarantee that no callers are relying on the
> existing behavior of a wake_up_process() causing usleep_range() to
> return early.  I would say, however, that all callers I've seen are
> absolutely relying on the min delay being enforced and I've never
> personally seen a caller relying on being woken up from
> usleep_range().  All the users relying on the min delay being enforced

Indeed.  It's *highly* surprising for any sleep interface to undershoot
on delays, the usual thing is that they might delay for longer.  If the
function doesn't actually reliably delay for the minimum time then I'd
expect that a large proportion of those conversions and other recent
code that's been added is buggy.

> one of two functions: usleep_atlest() and usleep_wakeable().  As
> argued below I think that usleep_range() name implies that it will at
> least sleep the minimum so I would really like to avoid keeping the
> name usleep_range() and also keeping the existing behavior.

I tend to agree with everything Doug is saying in terms of API
expectations.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20161012/8c731db6/attachment.sig>

From mark.yao at rock-chips.com  Wed Oct 12 03:00:42 2016
From: mark.yao at rock-chips.com (Mark Yao)
Date: Wed, 12 Oct 2016 18:00:42 +0800
Subject: [PATCH] drm/bridge: analogix: protect power when get_modes or detect
Message-ID: <1476266442-29803-1-git-send-email-mark.yao@rock-chips.com>

The drm callback ->detect and ->get_modes seems is not power safe,
they may be called when device is power off, do register access on
detect or get_modes will cause system die.

Here is the path call ->detect before analogix_dp power on
[<ffffff800843babc>] analogix_dp_detect+0x44/0xdc
[<ffffff80083fd840>] drm_helper_probe_single_connector_modes_merge_bits+0xe8/0x41c
[<ffffff80083fdb84>] drm_helper_probe_single_connector_modes+0x10/0x18
[<ffffff8008418d24>] drm_mode_getconnector+0xf4/0x304
[<ffffff800840cff0>] drm_ioctl+0x23c/0x390
[<ffffff80081a8adc>] do_vfs_ioctl+0x4b8/0x58c
[<ffffff80081a8c10>] SyS_ioctl+0x60/0x88

Cc: Inki Dae <inki.dae at samsung.com>
Cc: Sean Paul <seanpaul at chromium.org>
Cc: Gustavo Padovan <gustavo.padovan at collabora.co.uk>
Cc: "Ville Syrj?l?" <ville.syrjala at linux.intel.com>

Signed-off-by: Mark Yao <mark.yao at rock-chips.com>
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 28 ++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index efac8ab..09dece2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1062,6 +1062,13 @@ int analogix_dp_get_modes(struct drm_connector *connector)
 		return 0;
 	}
 
+	if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+		pm_runtime_get_sync(dp->dev);
+
+		if (dp->plat_data->power_on)
+			dp->plat_data->power_on(dp->plat_data);
+	}
+
 	if (analogix_dp_handle_edid(dp) == 0) {
 		drm_mode_connector_update_edid_property(&dp->connector, edid);
 		num_modes += drm_add_edid_modes(&dp->connector, edid);
@@ -1073,6 +1080,13 @@ int analogix_dp_get_modes(struct drm_connector *connector)
 	if (dp->plat_data->get_modes)
 		num_modes += dp->plat_data->get_modes(dp->plat_data, connector);
 
+	if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+		if (dp->plat_data->power_off)
+			dp->plat_data->power_off(dp->plat_data);
+
+		pm_runtime_put_sync(dp->dev);
+	}
+
 	ret = analogix_dp_prepare_panel(dp, false, false);
 	if (ret)
 		DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
@@ -1106,9 +1120,23 @@ analogix_dp_detect(struct drm_connector *connector, bool force)
 		return connector_status_disconnected;
 	}
 
+	if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+		pm_runtime_get_sync(dp->dev);
+
+		if (dp->plat_data->power_on)
+			dp->plat_data->power_on(dp->plat_data);
+	}
+
 	if (!analogix_dp_detect_hpd(dp))
 		status = connector_status_connected;
 
+	if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+		if (dp->plat_data->power_off)
+			dp->plat_data->power_off(dp->plat_data);
+
+		pm_runtime_put_sync(dp->dev);
+	}
+
 	ret = analogix_dp_prepare_panel(dp, false, false);
 	if (ret)
 		DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
-- 
1.9.1




From dan.carpenter at oracle.com  Wed Oct 12 03:54:09 2016
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Wed, 12 Oct 2016 13:54:09 +0300
Subject: [patch] PCI: rockchip: Indent an if statement
Message-ID: <20161012105409.GA19070@mwanda>

The if statement wasn't intended.  Add a tab.

Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com>

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index b8c82fc..f54ef1e 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -972,7 +972,7 @@ static int rockchip_pcie_prog_ob_atu(struct rockchip_pcie *rockchip,
 		return -EINVAL;
 	if (region_no == 0) {
 		if (AXI_REGION_0_SIZE < (2ULL << num_pass_bits))
-		return -EINVAL;
+			return -EINVAL;
 	}
 	if (region_no != 0) {
 		if (AXI_REGION_SIZE < (2ULL << num_pass_bits))


From dan.carpenter at oracle.com  Wed Oct 12 03:54:34 2016
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Wed, 12 Oct 2016 13:54:34 +0300
Subject: [bug report] PCI: rockchip: Add Rockchip PCIe controller support
Message-ID: <20161012105434.GA21452@mwanda>

Hello Shawn Lin,

The patch e77f847df54c: "PCI: rockchip: Add Rockchip PCIe controller
support" from Sep 3, 2016, leads to the following static checker
warning:

	drivers/pci/host/pcie-rockchip.c:552 rockchip_pcie_init_port()
	warn: mask and shift to zero

drivers/pci/host/pcie-rockchip.c
   549  
   550          /* Check the final link width from negotiated lane counter from MGMT */
   551          status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
   552          status =  0x1 << ((status & PCIE_CORE_PL_CONF_LANE_MASK) >>
   553                            PCIE_CORE_PL_CONF_LANE_MASK);

Presumably we should be shifting by PCIE_CORE_PL_CONF_LANE_SHIFT but
this still looks all kind of jumbled up.

   554          dev_dbg(dev, "current link width is x%d\n", status);
   555  

regards,
dan carpenter


From shawn.lin at rock-chips.com  Wed Oct 12 04:04:11 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 19:04:11 +0800
Subject: [patch] PCI: rockchip: Indent an if statement
In-Reply-To: <20161012105409.GA19070@mwanda>
References: <20161012105409.GA19070@mwanda>
Message-ID: <2916ad6b-e6a4-b221-5820-c1c5f9387f76@rock-chips.com>

On 2016/10/12 18:54, Dan Carpenter wrote:
> The if statement wasn't intended.  Add a tab.
>
> Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com>

Thanks for this patch.

Currently the driver is under cleanup, so it would be fine
for Bjorn to pick it up for host-rockchip branch. :)

>
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index b8c82fc..f54ef1e 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -972,7 +972,7 @@ static int rockchip_pcie_prog_ob_atu(struct rockchip_pcie *rockchip,
>  		return -EINVAL;
>  	if (region_no == 0) {
>  		if (AXI_REGION_0_SIZE < (2ULL << num_pass_bits))
> -		return -EINVAL;
> +			return -EINVAL;
>  	}
>  	if (region_no != 0) {
>  		if (AXI_REGION_SIZE < (2ULL << num_pass_bits))
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>


-- 
Best Regards
Shawn Lin



From helgaas at kernel.org  Wed Oct 12 05:18:45 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Wed, 12 Oct 2016 07:18:45 -0500
Subject: [patch] PCI: rockchip: Indent an if statement
In-Reply-To: <20161012105409.GA19070@mwanda>
References: <20161012105409.GA19070@mwanda>
Message-ID: <20161012121845.GA21211@localhost>

On Wed, Oct 12, 2016 at 01:54:09PM +0300, Dan Carpenter wrote:
> The if statement wasn't intended.  Add a tab.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com>

Applied to pci/host-rockchip for v4.9, thanks, Dan.

> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index b8c82fc..f54ef1e 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -972,7 +972,7 @@ static int rockchip_pcie_prog_ob_atu(struct rockchip_pcie *rockchip,
>  		return -EINVAL;
>  	if (region_no == 0) {
>  		if (AXI_REGION_0_SIZE < (2ULL << num_pass_bits))
> -		return -EINVAL;
> +			return -EINVAL;
>  	}
>  	if (region_no != 0) {
>  		if (AXI_REGION_SIZE < (2ULL << num_pass_bits))
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From shawn.lin at rock-chips.com  Wed Oct 12 05:31:41 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 12 Oct 2016 20:31:41 +0800
Subject: [PATCH] clk: rockchip: don't return NULL when failing to register
 ddrclk branch
Message-ID: <1476275501-2653-1-git-send-email-shawn.lin@rock-chips.com>

rockchip_clk_register_ddrclk should not return NULL when faling
to call clk_register, otherwise rockchip_clk_register_branches
prints "unknown clock type". The acutal case is that it's a known
clock type but we fail to regiser it, which may makes user confuse
the reason of failure. And the pr_err here is pointless as
rockchip_clk_register_branches will also print the similar message.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/clk/rockchip/clk-ddr.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/clk/rockchip/clk-ddr.c b/drivers/clk/rockchip/clk-ddr.c
index 8feba93..e807535 100644
--- a/drivers/clk/rockchip/clk-ddr.c
+++ b/drivers/clk/rockchip/clk-ddr.c
@@ -144,11 +144,8 @@ struct clk *rockchip_clk_register_ddrclk(const char *name, int flags,
 	ddrclk->ddr_flag = ddr_flag;
 
 	clk = clk_register(NULL, &ddrclk->hw);
-	if (IS_ERR(clk)) {
-		pr_err("%s: could not register ddrclk %s\n", __func__,	name);
+	if (IS_ERR(clk))
 		kfree(ddrclk);
-		return NULL;
-	}
 
 	return clk;
 }
-- 
2.3.7




From bhelgaas at google.com  Wed Oct 12 06:04:16 2016
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Wed, 12 Oct 2016 08:04:16 -0500
Subject: [PATCH v2 0/2] PCI: rockchip: Cleanup
Message-ID: <20161012130256.25212.33689.stgit@bhelgaas-glaptop2.roam.corp.google.com>

  - Remove platform drvdata because it appears unused (we called
    platform_set_drvdata() but not platform_get_drvdata()).

Nothing here should change the behavior of the driver.

Changes from v1:
  Added Dan's indentation fix.
  I dropped the following patches because they were a lot of churn for
  questionable benefit:
    PCI: rockchip: Rename accessors
    PCI: rockchip: Swap order of rockchip_writel() reg/val arguments

---

Bjorn Helgaas (1):
      PCI: rockchip: Remove unused platform data

Dan Carpenter (1):
      PCI: rockchip: Indent "if" statement body


 drivers/pci/host/pcie-rockchip.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)


From bhelgaas at google.com  Wed Oct 12 06:04:24 2016
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Wed, 12 Oct 2016 08:04:24 -0500
Subject: [PATCH v2 1/2] PCI: rockchip: Remove unused platform data
In-Reply-To: <20161012130256.25212.33689.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20161012130256.25212.33689.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <20161012130424.25212.24525.stgit@bhelgaas-glaptop2.roam.corp.google.com>

The rockchip driver never uses the platform drvdata pointer, so don't
bother setting it.  No functional change intended.

Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
Acked-by: Shawn Lin <shawn.lin at rock-chips.com>
---
 drivers/pci/host/pcie-rockchip.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index b8c82fc..59bf0db 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -1091,8 +1091,6 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
 	if (err)
 		goto err_vpcie;
 
-	platform_set_drvdata(pdev, rockchip);
-
 	rockchip_pcie_enable_interrupts(rockchip);
 
 	err = rockchip_pcie_init_irq_domain(rockchip);



From bhelgaas at google.com  Wed Oct 12 06:04:37 2016
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Wed, 12 Oct 2016 08:04:37 -0500
Subject: [PATCH v2 2/2] PCI: rockchip: Indent "if" statement body
In-Reply-To: <20161012130256.25212.33689.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20161012130256.25212.33689.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <20161012130437.25212.34359.stgit@bhelgaas-glaptop2.roam.corp.google.com>

From: Dan Carpenter <dan.carpenter at oracle.com>

Body of an "if" statement wasn't indented.  Add a tab.

Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com>
Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
---
 drivers/pci/host/pcie-rockchip.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 59bf0db..e0b22da 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -972,7 +972,7 @@ static int rockchip_pcie_prog_ob_atu(struct rockchip_pcie *rockchip,
 		return -EINVAL;
 	if (region_no == 0) {
 		if (AXI_REGION_0_SIZE < (2ULL << num_pass_bits))
-		return -EINVAL;
+			return -EINVAL;
 	}
 	if (region_no != 0) {
 		if (AXI_REGION_SIZE < (2ULL << num_pass_bits))



From tglx at linutronix.de  Wed Oct 12 06:11:32 2016
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 12 Oct 2016 15:11:32 +0200 (CEST)
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <20161011182541.GA32165@rhlx01.hs-esslingen.de>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
 <alpine.DEB.2.20.1610110908240.7794@nanos>
 <20161011182541.GA32165@rhlx01.hs-esslingen.de>
Message-ID: <alpine.DEB.2.20.1610121506480.8572@nanos>

On Tue, 11 Oct 2016, Andreas Mohr wrote:
> On Tue, Oct 11, 2016 at 09:14:38AM +0200, Thomas Gleixner wrote:
> > On Mon, 10 Oct 2016, Douglas Anderson wrote:
> > > Users of usleep_range() expect that it will _never_ return in less time
> > > than the minimum passed parameter.  However, nothing in any of the code
> > > ensures this.  Specifically:
> > 
> > There is no such guarantee for that interface and never has been, so how
> > did you make sure that none of the existing users is relying on this?
> > 
> > You can't just can't just declare that all all of the users expect that and
> > be done with it.
> 
> Hmm, somehow I don't manage to follow these thoughts.
> 
> https://www.kernel.org/doc/htmldocs/device-drivers/API-usleep-range.html
> (as a hopefully sufficiently authoritative source of documentation)
> clearly specifies min to be
> "Minimum time in usecs to sleep"
> , which is what one would expect a two-param interface here to be
> (minimum-maximum),
> i.e. what would be the *natural* protocol I'd think.
> 
> Also, [finally...] starting to enforce the minimum time
> is an additional *constraint* on the protocol,
> i.e. it's not at all like we are getting more *liberal* here
> (since usually getting more liberal in certain protocols
> is what will cause trouble, I'd think).
> 
> Not to mention that
> desiring a delay in processing most certainly is
> what caused users of this API to decide to invoke it in the first place
> (else they would just have chosen to carry on with delay-less processing
> and be done with it).
> And those users then surely wouldn't want to experience a behaviour
> where the delay may be ended at any time,
> however short that may end up being.

I'm well aware what Doug wants to do and I'm not saying that this is wrong,
but I'm not going to look at all usleep() usage sites to make sure none is
relying on such a behaviour and gets surprised by the change,

The point is that we had cases over and over where stuff was depending on
implementation bugs which made the buggy behaviour into an expected
behaviour. I'm not saying that this is the case here, but it's not my duty
to make sure it isn't.

So the very minimum I need in the changelog is some mentioning that the
author at least tried to verify that this is not going to break the world
and some more. That's what I meant by:

You can't just can't just declare that all all of the users expect that and
be done with it.

Thanks,

	tglx


From seanpaul at chromium.org  Wed Oct 12 07:51:14 2016
From: seanpaul at chromium.org (Sean Paul)
Date: Wed, 12 Oct 2016 10:51:14 -0400
Subject: Question: Re: [PATCH] drm/bridge: analogix: protect power when
 get_modes or detect
In-Reply-To: <57FE0EF5.7010207@rock-chips.com>
References: <1476266442-29803-1-git-send-email-mark.yao@rock-chips.com>
 <57FE0EF5.7010207@rock-chips.com>
Message-ID: <CAOw6vbKe0d66O1MymP24UQ-M3EmdR+=pZVWmgZG9iVm5x1Arrg@mail.gmail.com>

On Wed, Oct 12, 2016 at 6:22 AM, Mark yao <mark.yao at rock-chips.com> wrote:
>
> I'm not familiar with the analogix driver, maybe use a power reference count
> would better then direct power on/off analogix_dp.
>
> Does anyone has the idea to protect detect and get_modes context?
>

I'm not sure a reference count is going to help here. The common
pattern is to call detect() followed by get_modes() and then modeset.
However, it's not guaranteed that any one of those functions will be
called after the other. So, if you leave things on after detect or
get_modes, you might be wasting power (or worse).

I recently ran into this exact problem with a panel we're using. Check
out "0b8b059a7: drm/bridge: analogix_dp: Ensure the panel is properly
prepared/unprepared". Perhaps you can piggyback on that function to
add your pm_runtime and plat_data callbacks (since using dpms_mode
might be racey).

Sean


> I found many other connector driver also direct access register on detect or
> get_modes, no problem for it?
>
> On 2016?10?12? 18:00, Mark Yao wrote:
>
> The drm callback ->detect and ->get_modes seems is not power safe,
> they may be called when device is power off, do register access on
> detect or get_modes will cause system die.
>
> Here is the path call ->detect before analogix_dp power on
> [<ffffff800843babc>] analogix_dp_detect+0x44/0xdc
> [<ffffff80083fd840>]
> drm_helper_probe_single_connector_modes_merge_bits+0xe8/0x41c
> [<ffffff80083fdb84>] drm_helper_probe_single_connector_modes+0x10/0x18
> [<ffffff8008418d24>] drm_mode_getconnector+0xf4/0x304
> [<ffffff800840cff0>] drm_ioctl+0x23c/0x390
> [<ffffff80081a8adc>] do_vfs_ioctl+0x4b8/0x58c
> [<ffffff80081a8c10>] SyS_ioctl+0x60/0x88
>
> Cc: Inki Dae <inki.dae at samsung.com>
> Cc: Sean Paul <seanpaul at chromium.org>
> Cc: Gustavo Padovan <gustavo.padovan at collabora.co.uk>
> Cc: "Ville Syrj?l?" <ville.syrjala at linux.intel.com>
>
> Signed-off-by: Mark Yao <mark.yao at rock-chips.com>
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 28
> ++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index efac8ab..09dece2 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1062,6 +1062,13 @@ int analogix_dp_get_modes(struct drm_connector
> *connector)
>   return 0;
>   }
>
> + if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
> + pm_runtime_get_sync(dp->dev);
> +
> + if (dp->plat_data->power_on)
> + dp->plat_data->power_on(dp->plat_data);
> + }
> +
>   if (analogix_dp_handle_edid(dp) == 0) {
>   drm_mode_connector_update_edid_property(&dp->connector, edid);
>   num_modes += drm_add_edid_modes(&dp->connector, edid);
> @@ -1073,6 +1080,13 @@ int analogix_dp_get_modes(struct drm_connector
> *connector)
>   if (dp->plat_data->get_modes)
>   num_modes += dp->plat_data->get_modes(dp->plat_data, connector);
>
> + if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
> + if (dp->plat_data->power_off)
> + dp->plat_data->power_off(dp->plat_data);
> +
> + pm_runtime_put_sync(dp->dev);
> + }
> +
>   ret = analogix_dp_prepare_panel(dp, false, false);
>   if (ret)
>   DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
> @@ -1106,9 +1120,23 @@ analogix_dp_detect(struct drm_connector *connector,
> bool force)
>   return connector_status_disconnected;
>   }
>
> + if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
> + pm_runtime_get_sync(dp->dev);
> +
> + if (dp->plat_data->power_on)
> + dp->plat_data->power_on(dp->plat_data);
> + }
> +
>   if (!analogix_dp_detect_hpd(dp))
>   status = connector_status_connected;
>
> + if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
> + if (dp->plat_data->power_off)
> + dp->plat_data->power_off(dp->plat_data);
> +
> + pm_runtime_put_sync(dp->dev);
> + }
> +
>   ret = analogix_dp_prepare_panel(dp, false, false);
>   if (ret)
>   DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
>
>
>
> --
> ?ark Yao


From helgaas at kernel.org  Wed Oct 12 09:02:40 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Wed, 12 Oct 2016 11:02:40 -0500
Subject: [PATCH v2 0/2] PCI: rockchip: Cleanup
In-Reply-To: <20161012130256.25212.33689.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20161012130256.25212.33689.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <20161012160240.GG4308@localhost>

On Wed, Oct 12, 2016 at 08:04:16AM -0500, Bjorn Helgaas wrote:
>   - Remove platform drvdata because it appears unused (we called
>     platform_set_drvdata() but not platform_get_drvdata()).
> 
> Nothing here should change the behavior of the driver.
> 
> Changes from v1:
>   Added Dan's indentation fix.
>   I dropped the following patches because they were a lot of churn for
>   questionable benefit:
>     PCI: rockchip: Rename accessors
>     PCI: rockchip: Swap order of rockchip_writel() reg/val arguments
> 
> ---
> 
> Bjorn Helgaas (1):
>       PCI: rockchip: Remove unused platform data
> 
> Dan Carpenter (1):
>       PCI: rockchip: Indent "if" statement body

I applied these to pci/host-rockchip for v4.9.  I hope to ask Linus to
pull them tomorrow, so if you see any issues, let me know soon.


From linux at roeck-us.net  Wed Oct 12 09:03:45 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 12 Oct 2016 09:03:45 -0700
Subject: [v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <1476133442-17757-1-git-send-email-dianders@chromium.org>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
Message-ID: <20161012160309.GA19146@roeck-us.net>

On Mon, Oct 10, 2016 at 02:04:02PM -0700, Douglas Anderson wrote:
> Users of usleep_range() expect that it will _never_ return in less time
> than the minimum passed parameter.  However, nothing in any of the code
> ensures this.  Specifically:
> 
> usleep_range() => do_usleep_range() => schedule_hrtimeout_range() =>
> schedule_hrtimeout_range_clock() just ends up calling schedule() with an
> appropriate timeout set using the hrtimer.  If someone else happens to
> wake up our task then we'll happily return from usleep_range() early.
> 
> msleep() already has code to handle this case since it will loop as long
> as there was still time left.  usleep_range() had no such loop.
> 
> The problem is is easily demonstrated with a small bit of test code:
> 
>   static int usleep_test_task(void *data)
>   {
>     atomic_t *done = data;
>     ktime_t start, end;
> 
>     start = ktime_get();
>     usleep_range(50000, 100000);
>     end = ktime_get();
>     pr_info("Requested 50000 - 100000 us.  Actually slept for %llu us\n",
>       (unsigned long long)ktime_to_us(ktime_sub(end, start)));
>     atomic_set(done, 1);
> 
>     return 0;
>   }
> 
>   static void run_usleep_test(void)
>   {
>     struct task_struct *t;
>     atomic_t done;
> 
>     atomic_set(&done, 0);
> 
>     t = kthread_run(usleep_test_task, &done, "usleep_test_task");
>     while (!atomic_read(&done)) {
>       wake_up_process(t);
>       udelay(1000);
>     }
>     kthread_stop(t);
>   }
> 
> If you run the above code without this patch you get things like:
>   Requested 50000 - 100000 us.  Actually slept for 967 us
> 
> If you run the above code _with_ this patch, you get:
>   Requested 50000 - 100000 us.  Actually slept for 50001 us
> 
> Presumably this problem was not detected before because:
> - It's not terribly common to use wake_up_process() directly.
> - Other ways for processes to wake up are not typically mixed with
>   usleep_range().
> - There aren't lots of places that use usleep_range(), since many people
>   call either msleep() or udelay().
> 
> Reported-by: Tao Huang <huangtao at rock-chips.com>
> Signed-off-by: Douglas Anderson <dianders at chromium.org>
> Reviewed-by: Brian Norris <briannorris at chromium.org>
> Reviewed-by: Andreas Mohr <andim2 at users.sf.net>

Reviewed-by: Guenter Roeck <linux at roeck-us.net>

The following drivers may expect the function to be interruptible.

drivers/iio/accel/kxcjk-1013.c: kxcjk1013_runtime_resume()
drivers/iio/accel/bmc150-accel-core.c:bmc150_accel_runtime_resume()
drivers/iio/accel/mma8452.c:mma8452_runtime_resume()
drivers/iio/accel/mma9551_core.c:mma9551_sleep()
kernel/trace/ring_buffer.c:rb_test()

A possible solution might be to introduce usleep_range_interruptible()
and use it there.

Note:
drivers/scsi/mvumi.c:mvumi_rescan_bus() uses msleep() but should possibly
use msleep_interruptible() instead.

Guenter


From dianders at chromium.org  Wed Oct 12 09:27:35 2016
From: dianders at chromium.org (Doug Anderson)
Date: Wed, 12 Oct 2016 09:27:35 -0700
Subject: [v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <20161012160309.GA19146@roeck-us.net>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
 <20161012160309.GA19146@roeck-us.net>
Message-ID: <CAD=FV=Ug9P1XDvF-Z_gPeU4CtFzoXQZuy7rmdg4FNGFdT77ENQ@mail.gmail.com>

Hi,

On Wed, Oct 12, 2016 at 9:03 AM, Guenter Roeck <linux at roeck-us.net> wrote:
> drivers/iio/accel/kxcjk-1013.c: kxcjk1013_runtime_resume()
> drivers/iio/accel/bmc150-accel-core.c:bmc150_accel_runtime_resume()
> drivers/iio/accel/mma8452.c:mma8452_runtime_resume()
> drivers/iio/accel/mma9551_core.c:mma9551_sleep()

As far as I can tell these drivers will not suffer unduly from my
change.  Worse case they will delay 20us more, which is listed as the
max.

Also note that I assume the reason you flagged these is because they
follow the pattern:

        if (sleep_val < 20000)
                usleep_range(sleep_val, 20000);
        else
                msleep_interruptible(sleep_val/1000);

I will note that usleep_range() is and has always been
uninterruptible, since the implementation says:

void __sched usleep_range(unsigned long min, unsigned long max)
{
       __set_current_state(TASK_UNINTERRUPTIBLE);
       do_usleep_range(min, max);
}

So I'm not at all convinced that we are changing behavior here.  The
"interruptible" vs. "uninterruptible" affects whether signals can
interrupt the sleep, not whether a random wake up of a task can.  What
we really need to know is if they are affected by a wakeup.

> kernel/trace/ring_buffer.c:rb_test()

I assume that the person who wrote this code was confused since they wrote:

  set_current_state(TASK_INTERRUPTIBLE);
  /* Now sleep between a min of 100-300us and a max of 1ms */
  usleep_range(((data->cnt % 3) + 1) * 100, 1000);

That doesn't seem to make sense given the first line of usleep_range().

In any case, again I don't think I am changing behavior.

> A possible solution might be to introduce usleep_range_interruptible()
> and use it there.

This could be a useful function, but I don't think we need it if we
find someone who needs a wakeup to cut short a sleep.  We can just
call one of the schedule functions directly and use a timeout.


Thank you for searching through for stuff and for your review, though!

-Doug


From linux at roeck-us.net  Wed Oct 12 09:53:51 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 12 Oct 2016 09:53:51 -0700
Subject: [v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <CAD=FV=Ug9P1XDvF-Z_gPeU4CtFzoXQZuy7rmdg4FNGFdT77ENQ@mail.gmail.com>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
 <20161012160309.GA19146@roeck-us.net>
 <CAD=FV=Ug9P1XDvF-Z_gPeU4CtFzoXQZuy7rmdg4FNGFdT77ENQ@mail.gmail.com>
Message-ID: <20161012165351.GA20472@roeck-us.net>

On Wed, Oct 12, 2016 at 09:27:35AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Wed, Oct 12, 2016 at 9:03 AM, Guenter Roeck <linux at roeck-us.net> wrote:
> > drivers/iio/accel/kxcjk-1013.c: kxcjk1013_runtime_resume()
> > drivers/iio/accel/bmc150-accel-core.c:bmc150_accel_runtime_resume()
> > drivers/iio/accel/mma8452.c:mma8452_runtime_resume()
> > drivers/iio/accel/mma9551_core.c:mma9551_sleep()
> 
> As far as I can tell these drivers will not suffer unduly from my
> change.  Worse case they will delay 20us more, which is listed as the
> max.
> 
20 ms.

> Also note that I assume the reason you flagged these is because they
> follow the pattern:
> 
>         if (sleep_val < 20000)
>                 usleep_range(sleep_val, 20000);
>         else
>                 msleep_interruptible(sleep_val/1000);
> 
Correct

> I will note that usleep_range() is and has always been
> uninterruptible, since the implementation says:
> 
> void __sched usleep_range(unsigned long min, unsigned long max)
> {
>        __set_current_state(TASK_UNINTERRUPTIBLE);
>        do_usleep_range(min, max);
> }
> 
Good point.

> So I'm not at all convinced that we are changing behavior here.  The
> "interruptible" vs. "uninterruptible" affects whether signals can
> interrupt the sleep, not whether a random wake up of a task can.  What
> we really need to know is if they are affected by a wakeup.
> 
Yes, you are correct.

> > kernel/trace/ring_buffer.c:rb_test()
> 
> I assume that the person who wrote this code was confused since they wrote:
> 
>   set_current_state(TASK_INTERRUPTIBLE);
>   /* Now sleep between a min of 100-300us and a max of 1ms */
>   usleep_range(((data->cnt % 3) + 1) * 100, 1000);
> 
> That doesn't seem to make sense given the first line of usleep_range().
> 
... which, for those who don't pay attention (like me), is
	__set_current_state(TASK_UNINTERRUPTIBLE);

> In any case, again I don't think I am changing behavior.
> 
> > A possible solution might be to introduce usleep_range_interruptible()
> > and use it there.
> 
> This could be a useful function, but I don't think we need it if we
> find someone who needs a wakeup to cut short a sleep.  We can just
> call one of the schedule functions directly and use a timeout.
> 

Agreed.

> 
> Thank you for searching through for stuff and for your review, though!
> 
No problem. Thanks for correcting me.

Note that I also searched for use of usleep_range() in conjunction with a
a task wakeup, but did not find anything. I did find a large number of cases,
though, where the explicit assumption is made that the minimum sleep time
is well defined.

Guenter


From dianders at chromium.org  Wed Oct 12 10:39:29 2016
From: dianders at chromium.org (Doug Anderson)
Date: Wed, 12 Oct 2016 10:39:29 -0700
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <alpine.DEB.2.20.1610121506480.8572@nanos>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
 <alpine.DEB.2.20.1610110908240.7794@nanos>
 <20161011182541.GA32165@rhlx01.hs-esslingen.de>
 <alpine.DEB.2.20.1610121506480.8572@nanos>
Message-ID: <CAD=FV=WbeSn3eh8eMaVaMucay5hf0GYx3J6ADE5mpnhk3tx=Nw@mail.gmail.com>

Hi,

On Wed, Oct 12, 2016 at 6:11 AM, Thomas Gleixner <tglx at linutronix.de> wrote:
> I'm well aware what Doug wants to do and I'm not saying that this is wrong,
> but I'm not going to look at all usleep() usage sites to make sure none is
> relying on such a behaviour and gets surprised by the change,
>
> The point is that we had cases over and over where stuff was depending on
> implementation bugs which made the buggy behaviour into an expected
> behaviour. I'm not saying that this is the case here, but it's not my duty
> to make sure it isn't.

Every change breaks something.  <https://xkcd.com/1172/>.  I don't
think we promise bug for bug compatibility for Linux releases, do we?
Though I definitely agree that we shouldn't be breaking something on
purpose and it's good to be careful.


> So the very minimum I need in the changelog is some mentioning that the
> author at least tried to verify that this is not going to break the world
> and some more. That's what I meant by:
>
> You can't just can't just declare that all all of the users expect that and
> be done with it.

Do you have some suggestion about how to do that?  In general I'm
hesitant to rely on code analysis of 1620 call sites and that would
really be the only way to "be sure".  It would also take a really long
time.  I think Guenter was searching for files that contained
usleep_range() and some other text.  That's a pretty good idea but it
is definitely not exhaustive since there's no reason that the usleep
and a wakeup are guaranteed to be in the same file.  It's also
entirely possible that a wakeup could happen through some other source
than just a direct call to wake_up_process().  It's why I didn't try
it originally.

...but I can do it anyway.  I tried "git grep -C10000 usleep_range |
grep wake_up_process".  I actually do find some things that I don't
think Guenter found (or maybe he found, analyzed, and rejected):

> drivers/block/cciss.c-  wake_up_process(cciss_scan_thread);

We possibly wake up scan_thread().  Sleep is in
cciss_wait_for_mode_change_ack().  Callers of that are
cciss_enter_performant_mode() and cciss_enter_simple_mode().  Callers
of those are cciss_put_controller_into_performant_mode() and
cciss_pci_init() (and the performant mode boils down to
cciss_pci_init() anyway).  Caller is cciss_init_one().  That is the
probe function.  AKA: the thread that is being woken up isn't the one
doing the usleep_range().

No obvious bug here.

> drivers/memstick/host/rtsx_usb_ms.c-    wake_up_process(host->detect_ms);

Function being woken is rtsx_usb_detect_ms_card().  Sleeps are in
ms_power_on() and rtsx_usb_ms_set_param() (with no loops).
ms_power_on() is called by rtsx_usb_ms_set_param() anyway.  That
function is stored in msh->set_param.  That will be fairly hard to
track down, but it seems unlikely it is called by
rtsx_usb_detect_ms_card() and that we intentionally want the usleep to
end early.

No obvious bug here.


> drivers/scsi/mvumi.c-                   wake_up_process(mhba->dm_thread);
> drivers/scsi/mvumi.c-   wake_up_process(mhba->dm_thread);

Function being woken is mvumi_rescan_bus().  Intended to wake up the
task when it's in schedule().  Even after the schedule there is a
hardcoded msleep(1000).  To me the msleep(1000) makes it seem like
this loop can't possibly be too performance critical.

...but even if there are performance critical parts of that loop and
somehow the wake was intended not just to wakeup from the schedule but
also the usleep_range, worse case we will sleep 2 ms extra.

No obvious bug here.


> kernel/time/timer.c-    wake_up_process((struct task_struct *)__data);

Generic timer code.


> kernel/trace/ring_buffer.c-             wake_up_process(rb_threads[cpu]);

This is test code and already seems a bit confused.  ...but it does
appear that the caller might actually be intending the the
wake_up_process() to take effect.  Looking closer.  I see that the
wakeup is called once at the start of the test, not midway through the
test.  So I don't think there's a problem already than the already
identified problem of a useless
"set_current_state(TASK_INTERRUPTIBLE);"

No obvious bug here.

===

So the net result of all the above is that:

* With my git grep + code inspection, I see no obvious bug.  I will
admit that I didn't do a super deep search and finding bugs by code
inspection is iffy at best, but it might give us some sort of warm
fuzzy.

* With Guenter's search we saw no obvious bugs.

* Several subsystem maintainers and reviewers of lots of code have
chimed in and say that they're not aware of any code where
usleep_range() was expected to wake up early and they were also aware
of lots of code that would break if usleep_range() returned early.


IMHO: let's land it in linuxnext and give it some bake time.  If
nobody screams then it can go into linux proper, possibly to stable
trees.

-Doug


From wxt at rock-chips.com  Wed Oct 12 11:16:08 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Thu, 13 Oct 2016 02:16:08 +0800
Subject: [PATCH v2] soc: rockchip: avoid infinite loop for power domain
Message-ID: <1476296168-29154-1-git-send-email-wxt@rock-chips.com>

In some cases, we have met the infinite loop in
rockchip_pmu_set_idle_request() or rockchip_do_pmu_set_power_domain().

As the crosbug.com/p/57351 reported, the boot hangs right after this
[1.629163] bootconsole [uart8250] disabled
[1.639286] [drm:drm_core_init] Initialized drm 1.1.0 20060810
[1.645926] [drm:drm_get_platform_dev] Initialized vgem 1.0.0 20120112..
[1.654558] iommu: Adding device ff8f0000.vop to group 0
[1.660569] iommu: Adding device ff900000.vop to group 1
<hang>

This patch adds the error message and timeout to avoid infinite loop if
it fails to get the ack.

Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

Changes in v2:
- As the Tomasz & Heiko feedback on http://crosreview.com/395589:
  * Also, need the timeout for rockchip_do_set_power_domain.
  * s/target_on/is_on, s/target_idle/is_idle.
  * unsigned int instear of u32.

 drivers/soc/rockchip/pm_domains.c | 48 +++++++++++++++++++++++++++++++++------
 1 file changed, 41 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 7acd151..260fbcc 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -9,6 +9,7 @@
  */
 
 #include <linux/io.h>
+#include <linux/iopoll.h>
 #include <linux/err.h>
 #include <linux/pm_clock.h>
 #include <linux/pm_domain.h>
@@ -105,12 +106,24 @@ static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
 	return (val & pd_info->idle_mask) == pd_info->idle_mask;
 }
 
+static unsigned int rockchip_pmu_read_ack(struct rockchip_pmu *pmu)
+{
+	unsigned int val;
+
+	regmap_read(pmu->regmap, pmu->info->ack_offset, &val);
+	return val;
+}
+
 static int rockchip_pmu_set_idle_request(struct rockchip_pm_domain *pd,
 					 bool idle)
 {
 	const struct rockchip_domain_info *pd_info = pd->info;
+	struct generic_pm_domain *genpd = &pd->genpd;
 	struct rockchip_pmu *pmu = pd->pmu;
 	unsigned int val;
+	unsigned int target_ack;
+	bool is_idle;
+	int ret;
 
 	if (pd_info->req_mask == 0)
 		return 0;
@@ -120,12 +133,26 @@ static int rockchip_pmu_set_idle_request(struct rockchip_pm_domain *pd,
 
 	dsb(sy);
 
-	do {
-		regmap_read(pmu->regmap, pmu->info->ack_offset, &val);
-	} while ((val & pd_info->ack_mask) != (idle ? pd_info->ack_mask : 0));
+	/* Wait util idle_ack = 1 */
+	target_ack = idle ? pd_info->ack_mask : 0;
+	ret = readx_poll_timeout_atomic(rockchip_pmu_read_ack, pmu, val,
+				(val & pd_info->ack_mask) == target_ack,
+				0, 10000);
+	if (ret) {
+		dev_err(pmu->dev,
+			"failed to get ack on domain '%s', val=0x%x\n",
+			genpd->name, val);
+		return ret;
+	}
 
-	while (rockchip_pmu_domain_is_idle(pd) != idle)
-		cpu_relax();
+	ret = readx_poll_timeout_atomic(rockchip_pmu_domain_is_idle, pd,
+					is_idle, is_idle == idle, 0, 10000);
+	if (ret) {
+		dev_err(pmu->dev,
+			"failed to set idle on domain '%s', val=%d\n",
+			genpd->name, is_idle);
+		return ret;
+	}
 
 	return 0;
 }
@@ -198,6 +225,8 @@ static void rockchip_do_pmu_set_power_domain(struct rockchip_pm_domain *pd,
 					     bool on)
 {
 	struct rockchip_pmu *pmu = pd->pmu;
+	struct generic_pm_domain *genpd = &pd->genpd;
+	bool is_on;
 
 	if (pd->info->pwr_mask == 0)
 		return;
@@ -207,8 +236,13 @@ static void rockchip_do_pmu_set_power_domain(struct rockchip_pm_domain *pd,
 
 	dsb(sy);
 
-	while (rockchip_pmu_domain_is_on(pd) != on)
-		cpu_relax();
+	if (readx_poll_timeout_atomic(rockchip_pmu_domain_is_on, pd, is_on,
+				      is_on == on, 0, 10000)) {
+		dev_err(pmu->dev,
+			"failed to set domain '%s', val=%d\n",
+			genpd->name, is_on);
+		return;
+	}
 }
 
 static int rockchip_pd_power(struct rockchip_pm_domain *pd, bool power_on)
-- 
1.9.1



From shawn.lin at rock-chips.com  Wed Oct 12 18:16:31 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Thu, 13 Oct 2016 09:16:31 +0800
Subject: [PATCH] PCI: rockchip: fix wrong print for negotiated lane numbers
Message-ID: <1476321391-6665-1-git-send-email-shawn.lin@rock-chips.com>

The negotiated lane numbers was incorrectly calculated, fix it.

Fixes: e77f847df54c6b0 ("PCI: rockchip: Add Rockchip PCIe controller support")
Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/pci/host/pcie-rockchip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index e0b22da..0d69d8c 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -549,7 +549,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 
 	/* Check the final link width from negotiated lane counter from MGMT */
 	status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
-	status =  0x1 << ((status & PCIE_CORE_PL_CONF_LANE_MASK) >>
+	status =  0x1 << ((status >> PCIE_CORE_PL_CONF_LANE_SHIFT) &
 			  PCIE_CORE_PL_CONF_LANE_MASK);
 	dev_dbg(dev, "current link width is x%d\n", status);
 
-- 
2.3.7




From shawn.lin at rock-chips.com  Wed Oct 12 18:32:10 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Thu, 13 Oct 2016 09:32:10 +0800
Subject: [PATCH v2 0/2] PCI: rockchip: Cleanup
In-Reply-To: <20161012160240.GG4308@localhost>
References: <20161012130256.25212.33689.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <20161012160240.GG4308@localhost>
Message-ID: <8b4f18cd-bced-6779-7988-574b14a42dce@rock-chips.com>

Hi Bjorn,

On 2016/10/13 0:02, Bjorn Helgaas wrote:
> On Wed, Oct 12, 2016 at 08:04:16AM -0500, Bjorn Helgaas wrote:
>>   - Remove platform drvdata because it appears unused (we called
>>     platform_set_drvdata() but not platform_get_drvdata()).
>>
>> Nothing here should change the behavior of the driver.
>>
>> Changes from v1:
>>   Added Dan's indentation fix.
>>   I dropped the following patches because they were a lot of churn for
>>   questionable benefit:
>>     PCI: rockchip: Rename accessors
>>     PCI: rockchip: Swap order of rockchip_writel() reg/val arguments
>>
>> ---
>>
>> Bjorn Helgaas (1):
>>       PCI: rockchip: Remove unused platform data
>>
>> Dan Carpenter (1):
>>       PCI: rockchip: Indent "if" statement body
>
> I applied these to pci/host-rockchip for v4.9.  I hope to ask Linus to
> pull them tomorrow, so if you see any issues, let me know soon.

Seems the first round of cleanup for host-rockchip again v10 when this
driver got merged was incorrectly changed. The issue wasn't exposed as
it's just a debug log which was easily overlooked.

So could you pick the  patch[0] to fix this problem ? :)

[0]: https://patchwork.kernel.org/patch/9374129/

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


-- 
Best Regards
Shawn Lin



From mark.yao at rock-chips.com  Wed Oct 12 18:50:38 2016
From: mark.yao at rock-chips.com (Mark Yao)
Date: Thu, 13 Oct 2016 09:50:38 +0800
Subject: [PATCH v2] drm/bridge: analogix: protect power when get_modes or
 detect
In-Reply-To: <1476266442-29803-1-git-send-email-mark.yao@rock-chips.com>
References: <1476266442-29803-1-git-send-email-mark.yao@rock-chips.com>
Message-ID: <1476323438-8435-1-git-send-email-mark.yao@rock-chips.com>

The drm callback ->detect and ->get_modes seems is not power safe,
they may be called when device is power off, do register access on
detect or get_modes will cause system die.

Here is the path call ->detect before analogix_dp power on
[<ffffff800843babc>] analogix_dp_detect+0x44/0xdc
[<ffffff80083fd840>] drm_helper_probe_single_connector_modes_merge_bits+0xe8/0x41c
[<ffffff80083fdb84>] drm_helper_probe_single_connector_modes+0x10/0x18
[<ffffff8008418d24>] drm_mode_getconnector+0xf4/0x304
[<ffffff800840cff0>] drm_ioctl+0x23c/0x390
[<ffffff80081a8adc>] do_vfs_ioctl+0x4b8/0x58c
[<ffffff80081a8c10>] SyS_ioctl+0x60/0x88

Cc: Inki Dae <inki.dae at samsung.com>
Cc: Sean Paul <seanpaul at chromium.org>
Cc: Gustavo Padovan <gustavo.padovan at collabora.co.uk>
Cc: "Ville Syrj?l?" <ville.syrjala at linux.intel.com>

Signed-off-by: Mark Yao <mark.yao at rock-chips.com>
---
Changes in v2:
- remove sub device power on/off callback, use pm_runtime_get/put is enough
to fix my problem, so will can avoid race to dpms.

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index efac8ab..ff2d328 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1062,11 +1062,15 @@ int analogix_dp_get_modes(struct drm_connector *connector)
 		return 0;
 	}
 
+	pm_runtime_get_sync(dp->dev);
+
 	if (analogix_dp_handle_edid(dp) == 0) {
 		drm_mode_connector_update_edid_property(&dp->connector, edid);
 		num_modes += drm_add_edid_modes(&dp->connector, edid);
 	}
 
+	pm_runtime_put(dp->dev);
+
 	if (dp->plat_data->panel)
 		num_modes += drm_panel_get_modes(dp->plat_data->panel);
 
@@ -1106,9 +1110,13 @@ analogix_dp_detect(struct drm_connector *connector, bool force)
 		return connector_status_disconnected;
 	}
 
+	pm_runtime_get_sync(dp->dev);
+
 	if (!analogix_dp_detect_hpd(dp))
 		status = connector_status_connected;
 
+	pm_runtime_put(dp->dev);
+
 	ret = analogix_dp_prepare_panel(dp, false, false);
 	if (ret)
 		DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
-- 
1.9.1




From mark.yao at rock-chips.com  Wed Oct 12 18:56:50 2016
From: mark.yao at rock-chips.com (Mark yao)
Date: Thu, 13 Oct 2016 09:56:50 +0800
Subject: Question: Re: [PATCH] drm/bridge: analogix: protect power when
 get_modes or detect
In-Reply-To: <CAOw6vbKe0d66O1MymP24UQ-M3EmdR+=pZVWmgZG9iVm5x1Arrg@mail.gmail.com>
References: <1476266442-29803-1-git-send-email-mark.yao@rock-chips.com>
 <57FE0EF5.7010207@rock-chips.com>
 <CAOw6vbKe0d66O1MymP24UQ-M3EmdR+=pZVWmgZG9iVm5x1Arrg@mail.gmail.com>
Message-ID: <57FEE9E2.20505@rock-chips.com>

On 2016?10?12? 22:51, Sean Paul wrote:
> On Wed, Oct 12, 2016 at 6:22 AM, Mark yao <mark.yao at rock-chips.com> wrote:
>> I'm not familiar with the analogix driver, maybe use a power reference count
>> would better then direct power on/off analogix_dp.
>>
>> Does anyone has the idea to protect detect and get_modes context?
>>
> I'm not sure a reference count is going to help here. The common
> pattern is to call detect() followed by get_modes() and then modeset.
> However, it's not guaranteed that any one of those functions will be
> called after the other. So, if you leave things on after detect or
> get_modes, you might be wasting power (or worse).
>
> I recently ran into this exact problem with a panel we're using. Check
> out "0b8b059a7: drm/bridge: analogix_dp: Ensure the panel is properly
> prepared/unprepared". Perhaps you can piggyback on that function to
> add your pm_runtime and plat_data callbacks (since using dpms_mode
> might be racey).
>
> Sean
Hi Sean

Thanks for your advice.

I re-test the detect and get_modes, only use pm_runtime_get/put also can 
fix my problem.
without plat_data callbacks can avoid race to dpms_mode.

I had send v2 patch,  you can review it.

Thanks.

>
>> I found many other connector driver also direct access register on detect or
>> get_modes, no problem for it?
>>
>> On 2016?10?12? 18:00, Mark Yao wrote:
>>
>> The drm callback ->detect and ->get_modes seems is not power safe,
>> they may be called when device is power off, do register access on
>> detect or get_modes will cause system die.
>>
>> Here is the path call ->detect before analogix_dp power on
>> [<ffffff800843babc>] analogix_dp_detect+0x44/0xdc
>> [<ffffff80083fd840>]
>> drm_helper_probe_single_connector_modes_merge_bits+0xe8/0x41c
>> [<ffffff80083fdb84>] drm_helper_probe_single_connector_modes+0x10/0x18
>> [<ffffff8008418d24>] drm_mode_getconnector+0xf4/0x304
>> [<ffffff800840cff0>] drm_ioctl+0x23c/0x390
>> [<ffffff80081a8adc>] do_vfs_ioctl+0x4b8/0x58c
>> [<ffffff80081a8c10>] SyS_ioctl+0x60/0x88
>>
>> Cc: Inki Dae <inki.dae at samsung.com>
>> Cc: Sean Paul <seanpaul at chromium.org>
>> Cc: Gustavo Padovan <gustavo.padovan at collabora.co.uk>
>> Cc: "Ville Syrj?l?" <ville.syrjala at linux.intel.com>
>>
>> Signed-off-by: Mark Yao <mark.yao at rock-chips.com>
>> ---
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 28
>> ++++++++++++++++++++++
>>   1 file changed, 28 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index efac8ab..09dece2 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> @@ -1062,6 +1062,13 @@ int analogix_dp_get_modes(struct drm_connector
>> *connector)
>>    return 0;
>>    }
>>
>> + if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
>> + pm_runtime_get_sync(dp->dev);
>> +
>> + if (dp->plat_data->power_on)
>> + dp->plat_data->power_on(dp->plat_data);
>> + }
>> +
>>    if (analogix_dp_handle_edid(dp) == 0) {
>>    drm_mode_connector_update_edid_property(&dp->connector, edid);
>>    num_modes += drm_add_edid_modes(&dp->connector, edid);
>> @@ -1073,6 +1080,13 @@ int analogix_dp_get_modes(struct drm_connector
>> *connector)
>>    if (dp->plat_data->get_modes)
>>    num_modes += dp->plat_data->get_modes(dp->plat_data, connector);
>>
>> + if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
>> + if (dp->plat_data->power_off)
>> + dp->plat_data->power_off(dp->plat_data);
>> +
>> + pm_runtime_put_sync(dp->dev);
>> + }
>> +
>>    ret = analogix_dp_prepare_panel(dp, false, false);
>>    if (ret)
>>    DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
>> @@ -1106,9 +1120,23 @@ analogix_dp_detect(struct drm_connector *connector,
>> bool force)
>>    return connector_status_disconnected;
>>    }
>>
>> + if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
>> + pm_runtime_get_sync(dp->dev);
>> +
>> + if (dp->plat_data->power_on)
>> + dp->plat_data->power_on(dp->plat_data);
>> + }
>> +
>>    if (!analogix_dp_detect_hpd(dp))
>>    status = connector_status_connected;
>>
>> + if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
>> + if (dp->plat_data->power_off)
>> + dp->plat_data->power_off(dp->plat_data);
>> +
>> + pm_runtime_put_sync(dp->dev);
>> + }
>> +
>>    ret = analogix_dp_prepare_panel(dp, false, false);
>>    if (ret)
>>    DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
>>
>>
>>
>> --
>> ?ark Yao
>
>


-- 
?ark Yao




From shawn.lin at rock-chips.com  Wed Oct 12 21:42:13 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Thu, 13 Oct 2016 12:42:13 +0800
Subject: [PATCH] phy-rockchip-pcie: remove deassert of phy_rst from exit
 callback
Message-ID: <1476333733-9696-1-git-send-email-shawn.lin@rock-chips.com>

The deassert of phy_rst from exit callback is incorrect as when
doing phy_exit, we expect the phy_rst is on asserted state which was
done by power_off callback, but not deasserted state. Meanwhile when
disabling clk_pciephy_ref, the assert/deassert signal can't actually
take effect on the phy. So let's fix it anyway.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/phy/phy-rockchip-pcie.c | 13 +------------
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/phy/phy-rockchip-pcie.c b/drivers/phy/phy-rockchip-pcie.c
index a2b4c6b..6904633 100644
--- a/drivers/phy/phy-rockchip-pcie.c
+++ b/drivers/phy/phy-rockchip-pcie.c
@@ -249,21 +249,10 @@ static int rockchip_pcie_phy_init(struct phy *phy)
 static int rockchip_pcie_phy_exit(struct phy *phy)
 {
 	struct rockchip_pcie_phy *rk_phy = phy_get_drvdata(phy);
-	int err = 0;
 
 	clk_disable_unprepare(rk_phy->clk_pciephy_ref);
 
-	err = reset_control_deassert(rk_phy->phy_rst);
-	if (err) {
-		dev_err(&phy->dev, "deassert phy_rst err %d\n", err);
-		goto err_reset;
-	}
-
-	return err;
-
-err_reset:
-	clk_prepare_enable(rk_phy->clk_pciephy_ref);
-	return err;
+	return 0;
 }
 
 static const struct phy_ops ops = {
-- 
2.3.7




From huangtao at rock-chips.com  Thu Oct 13 00:12:38 2016
From: huangtao at rock-chips.com (Huang, Tao)
Date: Thu, 13 Oct 2016 15:12:38 +0800
Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on
 rk3066
In-Reply-To: <149df5ee-3478-6d15-bb76-47becac146e9@gmail.com>
References: <20161001140939.GA31220@vaio-ubuntu>
 <6239b970-09d3-f7ee-e6f5-c019eaedb725@rock-chips.com>
 <f8aba48d-6c69-b246-4cb2-48a2770c80e4@gmail.com>
 <67831fd0-76af-a793-0b2f-958e45633fe8@rock-chips.com>
 <149df5ee-3478-6d15-bb76-47becac146e9@gmail.com>
Message-ID: <e3746f9a-084e-163e-a412-1a1fc66926d5@rock-chips.com>

Hi, Pawe?:
On 2016?10?10? 17:11, Pawe? Jarosz wrote:
> W dniu 10.10.2016 o 09:18, Huang, Tao pisze:
>> Our IC guy need us tell them which master can not access such area, DMA
>> or EMMC Controller or GPU, etc? Could you tell me how to reproduce such
>> issue?
>> And we can confirm CPU core can access this memory through /dev/mem and
>> the test board is 1GB too. Personally, I don't think RK3066 has such
>> limit because when we verify this chip, we don't found such limit at all.
>>
>> Thanks,
>> Huang, Tao
> I'm getting this on Ubuntu 16.04 with mainline kernel.
> My board always freezes when i type: "memtester 800M"
>
We try run memtest 800M with Linux kernel 4.8, which killed by OOM.
But if we run:
# memtester -p 0x9F000000 16K 1
memtester version 4.3.0 (32-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffff000
want 0MB (16384 bytes)
Loop 1/1:
   Stuck Address       : ok
   Random Value        : ok
   Compare XOR         : ok
   Compare SUB         : ok
   Compare MUL         : ok
   Compare DIV         : ok
   Compare OR          : ok
   Compare AND         : ok
   Sequential Increment: ok
   Solid Bits          : ok
   Block Sequential    : ok
   Checkerboard        : ok
   Bit Spread          : ok
   Bit Flip            : ok
   Walking Ones        : ok
   Walking Zeroes      : ok
   8-bit Writes        : ok
   16-bit Writes       : ok

So these memory should be fine to CPU core. Maybe your system just
freeze because out of memory.



From paweljarosz3691 at gmail.com  Thu Oct 13 01:55:17 2016
From: paweljarosz3691 at gmail.com (=?UTF-8?Q?Pawe=c5=82_Jarosz?=)
Date: Thu, 13 Oct 2016 10:55:17 +0200
Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on
 rk3066
In-Reply-To: <e3746f9a-084e-163e-a412-1a1fc66926d5@rock-chips.com>
References: <20161001140939.GA31220@vaio-ubuntu>
 <6239b970-09d3-f7ee-e6f5-c019eaedb725@rock-chips.com>
 <f8aba48d-6c69-b246-4cb2-48a2770c80e4@gmail.com>
 <67831fd0-76af-a793-0b2f-958e45633fe8@rock-chips.com>
 <149df5ee-3478-6d15-bb76-47becac146e9@gmail.com>
 <e3746f9a-084e-163e-a412-1a1fc66926d5@rock-chips.com>
Message-ID: <95e45ae4-f8cd-c7e0-4f3e-0ad0a5183078@gmail.com>

Hi


W dniu 13.10.2016 o 09:12, Huang, Tao pisze:
> Hi, Pawe?:
> On 2016?10?10? 17:11, Pawe? Jarosz wrote:
>> W dniu 10.10.2016 o 09:18, Huang, Tao pisze:
>>> Our IC guy need us tell them which master can not access such area, DMA
>>> or EMMC Controller or GPU, etc? Could you tell me how to reproduce such
>>> issue?
>>> And we can confirm CPU core can access this memory through /dev/mem and
>>> the test board is 1GB too. Personally, I don't think RK3066 has such
>>> limit because when we verify this chip, we don't found such limit at all.
>>>
>>> Thanks,
>>> Huang, Tao
>> I'm getting this on Ubuntu 16.04 with mainline kernel.
>> My board always freezes when i type: "memtester 800M"
>>
> We try run memtest 800M with Linux kernel 4.8, which killed by OOM.
> But if we run:
> # memtester -p 0x9F000000 16K 1
> memtester version 4.3.0 (32-bit)
> Copyright (C) 2001-2012 Charles Cazabon.
> Licensed under the GNU General Public License version 2 (only).
>
> pagesize is 4096
> pagesizemask is 0xfffff000
> want 0MB (16384 bytes)
> Loop 1/1:
>     Stuck Address       : ok
>     Random Value        : ok
>     Compare XOR         : ok
>     Compare SUB         : ok
>     Compare MUL         : ok
>     Compare DIV         : ok
>     Compare OR          : ok
>     Compare AND         : ok
>     Sequential Increment: ok
>     Solid Bits          : ok
>     Block Sequential    : ok
>     Checkerboard        : ok
>     Bit Spread          : ok
>     Bit Flip            : ok
>     Walking Ones        : ok
>     Walking Zeroes      : ok
>     8-bit Writes        : ok
>     16-bit Writes       : ok
>
> So these memory should be fine to CPU core. Maybe your system just
> freeze because out of memory.
>

weird ... memtester -p 0x9F000000 16K 1 gave me the same result.

Could you try one last command:

	memtester 400M

Values > 200M causing freeze.

If this won't do it, than maybe there is something wrong with my board.

Thanks for your time.


From dan.carpenter at oracle.com  Thu Oct 13 02:26:06 2016
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Thu, 13 Oct 2016 12:26:06 +0300
Subject: [bug report] drm/rockchip: add an common abstracted PSR driver
Message-ID: <20161013092606.GA23977@mwanda>

Hello Yakir Yang,

This is a semi-automatic email about new static checker warnings.

The patch 5182c1a556d7: "drm/rockchip: add an common abstracted PSR 
driver" from Jul 24, 2016, leads to the following Smatch complaint:

drivers/gpu/drm/rockchip/rockchip_drm_psr.c:228 rockchip_drm_psr_register()
	 warn: variable dereferenced before check 'encoder' (see line 224)

drivers/gpu/drm/rockchip/rockchip_drm_psr.c
   223	{
   224		struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
                                                       ^^^^^^^^^
Dereference.

   225		struct psr_drv *psr;
   226		unsigned long flags;
   227	
   228		if (!encoder || !psr_set)
                     ^^^^^^^
Check.

   229			return -EINVAL;
   230	

regards,
dan carpenter


From marc.zyngier at arm.com  Thu Oct 13 03:21:40 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 13 Oct 2016 11:21:40 +0100
Subject: [PATCH v2 1/2] clocksource: arm_arch_timer: Don't assume clock
 runs in suspend
In-Reply-To: <1475604730-140264-1-git-send-email-briannorris@chromium.org>
References: <1475604730-140264-1-git-send-email-briannorris@chromium.org>
Message-ID: <20161013112140.6f71fec7@arm.com>

On Tue,  4 Oct 2016 11:12:09 -0700
Brian Norris <briannorris at chromium.org> wrote:

> The ARM ARM specifies that the system counter "must be implemented in an
> always-on power domain," and so we try to use the counter as a source of
> timekeeping across suspend/resume. Unfortunately, some SoCs (e.g.,
> Rockchip's RK3399) do not keep the counter ticking properly when
> switched from their high-power clock to the lower-power clock used in
> system suspend. Support this quirk by adding a new device tree property.
> 
> Signed-off-by: Brian Norris <briannorris at chromium.org>

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

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


From daniel.lezcano at linaro.org  Thu Oct 13 05:25:34 2016
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 13 Oct 2016 14:25:34 +0200
Subject: [PATCH v2 1/2] clocksource: arm_arch_timer: Don't assume clock
 runs in suspend
In-Reply-To: <1475604730-140264-1-git-send-email-briannorris@chromium.org>
References: <1475604730-140264-1-git-send-email-briannorris@chromium.org>
Message-ID: <9d699d78-18cd-689f-02d4-529e10c7f2a0@linaro.org>

On 04/10/2016 20:12, Brian Norris wrote:
> The ARM ARM specifies that the system counter "must be implemented in an
> always-on power domain," and so we try to use the counter as a source of
> timekeeping across suspend/resume. Unfortunately, some SoCs (e.g.,
> Rockchip's RK3399) do not keep the counter ticking properly when
> switched from their high-power clock to the lower-power clock used in
> system suspend. Support this quirk by adding a new device tree property.
> 
> Signed-off-by: Brian Norris <briannorris at chromium.org>
> ---

Both patches applied for 4.10.

Thanks !

  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From seanpaul at chromium.org  Thu Oct 13 12:15:04 2016
From: seanpaul at chromium.org (Sean Paul)
Date: Thu, 13 Oct 2016 15:15:04 -0400
Subject: [PATCH v2] drm/bridge: analogix: protect power when get_modes or
 detect
In-Reply-To: <1476323438-8435-1-git-send-email-mark.yao@rock-chips.com>
References: <1476266442-29803-1-git-send-email-mark.yao@rock-chips.com>
 <1476323438-8435-1-git-send-email-mark.yao@rock-chips.com>
Message-ID: <CAOw6vb+Nj8KNhqQ9Rqk6wpUfubp+UW5HhYdoA2_O_EeHfaQLPQ@mail.gmail.com>

On Wed, Oct 12, 2016 at 9:50 PM, Mark Yao <mark.yao at rock-chips.com> wrote:
> The drm callback ->detect and ->get_modes seems is not power safe,
> they may be called when device is power off, do register access on
> detect or get_modes will cause system die.
>
> Here is the path call ->detect before analogix_dp power on
> [<ffffff800843babc>] analogix_dp_detect+0x44/0xdc
> [<ffffff80083fd840>] drm_helper_probe_single_connector_modes_merge_bits+0xe8/0x41c
> [<ffffff80083fdb84>] drm_helper_probe_single_connector_modes+0x10/0x18
> [<ffffff8008418d24>] drm_mode_getconnector+0xf4/0x304
> [<ffffff800840cff0>] drm_ioctl+0x23c/0x390
> [<ffffff80081a8adc>] do_vfs_ioctl+0x4b8/0x58c
> [<ffffff80081a8c10>] SyS_ioctl+0x60/0x88
>
> Cc: Inki Dae <inki.dae at samsung.com>
> Cc: Sean Paul <seanpaul at chromium.org>
> Cc: Gustavo Padovan <gustavo.padovan at collabora.co.uk>
> Cc: "Ville Syrj?l?" <ville.syrjala at linux.intel.com>
>
> Signed-off-by: Mark Yao <mark.yao at rock-chips.com>

Thanks for revising, this is much better.


Reviewed-by: Sean Paul <seanpaul at chromium.org>

> ---
> Changes in v2:
> - remove sub device power on/off callback, use pm_runtime_get/put is enough
> to fix my problem, so will can avoid race to dpms.
>
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index efac8ab..ff2d328 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1062,11 +1062,15 @@ int analogix_dp_get_modes(struct drm_connector *connector)
>                 return 0;
>         }
>
> +       pm_runtime_get_sync(dp->dev);
> +
>         if (analogix_dp_handle_edid(dp) == 0) {
>                 drm_mode_connector_update_edid_property(&dp->connector, edid);
>                 num_modes += drm_add_edid_modes(&dp->connector, edid);
>         }
>
> +       pm_runtime_put(dp->dev);
> +
>         if (dp->plat_data->panel)
>                 num_modes += drm_panel_get_modes(dp->plat_data->panel);
>
> @@ -1106,9 +1110,13 @@ analogix_dp_detect(struct drm_connector *connector, bool force)
>                 return connector_status_disconnected;
>         }
>
> +       pm_runtime_get_sync(dp->dev);
> +
>         if (!analogix_dp_detect_hpd(dp))
>                 status = connector_status_connected;
>
> +       pm_runtime_put(dp->dev);
> +
>         ret = analogix_dp_prepare_panel(dp, false, false);
>         if (ret)
>                 DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
> --
> 1.9.1
>
>


From paweljarosz3691 at gmail.com  Fri Oct 14 05:16:21 2016
From: paweljarosz3691 at gmail.com (=?utf-8?B?UGF3ZcWC?= Jarosz)
Date: Fri, 14 Oct 2016 14:16:21 +0200
Subject: [PATCH v2 0/2] Assign RK3066 clocks at boot time
Message-ID: <cover.1476447057.git.paweljarosz3691@gmail.com>

This patchset sets rk3066 PLL, CPU and PERI clocks while kernel init.

Pawe? Jarosz (2):
  clk: rockchip: Add bindings for cpu and peri clocks on rk3066
  ARM: dts: rockchip: initialize rk3066 PLL clock rate

 arch/arm/boot/dts/rk3066a.dtsi                |  9 +++++++++
 drivers/clk/rockchip/clk-rk3188.c             | 12 ++++++------
 include/dt-bindings/clock/rk3188-cru-common.h |  8 +++++++-
 3 files changed, 22 insertions(+), 7 deletions(-)

-- 
2.7.4



From paweljarosz3691 at gmail.com  Fri Oct 14 05:16:39 2016
From: paweljarosz3691 at gmail.com (=?utf-8?B?UGF3ZcWC?= Jarosz)
Date: Fri, 14 Oct 2016 14:16:39 +0200
Subject: [PATCH v2 1/2] clk: rockchip: Add bindings for cpu and peri clocks
 on rk3066
In-Reply-To: <cover.1476447057.git.paweljarosz3691@gmail.com>
References: <cover.1476447057.git.paweljarosz3691@gmail.com>
Message-ID: <938d05a66c34bd8af255979462fbed387a67abff.1476447057.git.paweljarosz3691@gmail.com>

Add bindings for ACLK_CPU, HCLK_CPU, PCLK_CPU, ACLK_PERI, HCLK_PERI, PCLK_PERI.

We need this to init it's rate at boot time.

Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
---

Changes in v2:
- none

 drivers/clk/rockchip/clk-rk3188.c             | 12 ++++++------
 include/dt-bindings/clock/rk3188-cru-common.h |  8 +++++++-
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3188.c b/drivers/clk/rockchip/clk-rk3188.c
index d0e722a..a6d398f 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -306,14 +306,14 @@ static struct rockchip_clk_branch common_clk_branches[] __initdata = {
 			RK2928_CLKSEL_CON(26), 8, 1, MFLAGS, 0, 2, DFLAGS | CLK_DIVIDER_POWER_OF_TWO,
 			RK2928_CLKGATE_CON(0), 2, GFLAGS),
 
-	GATE(0, "aclk_cpu", "aclk_cpu_pre", 0,
+	GATE(ACLK_CPU, "aclk_cpu", "aclk_cpu_pre", 0,
 			RK2928_CLKGATE_CON(0), 3, GFLAGS),
 
 	GATE(0, "atclk_cpu", "pclk_cpu_pre", 0,
 			RK2928_CLKGATE_CON(0), 6, GFLAGS),
-	GATE(0, "pclk_cpu", "pclk_cpu_pre", 0,
+	GATE(PCLK_CPU, "pclk_cpu", "pclk_cpu_pre", 0,
 			RK2928_CLKGATE_CON(0), 5, GFLAGS),
-	GATE(0, "hclk_cpu", "hclk_cpu_pre", CLK_IGNORE_UNUSED,
+	GATE(HCLK_CPU, "hclk_cpu", "hclk_cpu_pre", CLK_IGNORE_UNUSED,
 			RK2928_CLKGATE_CON(0), 4, GFLAGS),
 
 	COMPOSITE(0, "aclk_lcdc0_pre", mux_pll_src_cpll_gpll_p, CLK_IGNORE_UNUSED,
@@ -323,12 +323,12 @@ static struct rockchip_clk_branch common_clk_branches[] __initdata = {
 			RK2928_CLKSEL_CON(31), 15, 1, MFLAGS, 8, 5, DFLAGS,
 			RK2928_CLKGATE_CON(1), 4, GFLAGS),
 
-	GATE(0, "aclk_peri", "aclk_peri_pre", 0,
+	GATE(ACLK_PERI, "aclk_peri", "aclk_peri_pre", 0,
 			RK2928_CLKGATE_CON(2), 1, GFLAGS),
-	COMPOSITE_NOMUX(0, "hclk_peri", "aclk_peri_pre", 0,
+	COMPOSITE_NOMUX(HCLK_PERI, "hclk_peri", "aclk_peri_pre", 0,
 			RK2928_CLKSEL_CON(10), 8, 2, DFLAGS | CLK_DIVIDER_POWER_OF_TWO,
 			RK2928_CLKGATE_CON(2), 2, GFLAGS),
-	COMPOSITE_NOMUX(0, "pclk_peri", "aclk_peri_pre", 0,
+	COMPOSITE_NOMUX(PCLK_PERI, "pclk_peri", "aclk_peri_pre", 0,
 			RK2928_CLKSEL_CON(10), 12, 2, DFLAGS | CLK_DIVIDER_POWER_OF_TWO,
 			RK2928_CLKGATE_CON(2), 3, GFLAGS),
 
diff --git a/include/dt-bindings/clock/rk3188-cru-common.h b/include/dt-bindings/clock/rk3188-cru-common.h
index 4f53e70..d141c1f 100644
--- a/include/dt-bindings/clock/rk3188-cru-common.h
+++ b/include/dt-bindings/clock/rk3188-cru-common.h
@@ -72,6 +72,8 @@
 #define ACLK_IPP		200
 #define ACLK_RGA		201
 #define ACLK_CIF0		202
+#define ACLK_CPU		203
+#define ACLK_PERI		204
 
 /* pclk gates */
 #define PCLK_GRF		320
@@ -104,6 +106,8 @@
 #define PCLK_EFUSE		347
 #define PCLK_TZPC		348
 #define PCLK_TSADC		349
+#define PCLK_CPU		350
+#define PCLK_PERI		351
 
 /* hclk gates */
 #define HCLK_SDMMC		448
@@ -126,8 +130,10 @@
 #define HCLK_IPP		465
 #define HCLK_RGA		466
 #define HCLK_NANDC0		467
+#define HCLK_CPU		468
+#define HCLK_PERI		469
 
-#define CLK_NR_CLKS		(HCLK_NANDC0 + 1)
+#define CLK_NR_CLKS		(HCLK_PERI + 1)
 
 /* soft-reset indices */
 #define SRST_MCORE		2
-- 
2.7.4



From paweljarosz3691 at gmail.com  Fri Oct 14 05:16:54 2016
From: paweljarosz3691 at gmail.com (=?utf-8?B?UGF3ZcWC?= Jarosz)
Date: Fri, 14 Oct 2016 14:16:54 +0200
Subject: [PATCH v2 2/2] ARM: dts: rockchip: initialize rk3066 PLL clock rate
In-Reply-To: <cover.1476447057.git.paweljarosz3691@gmail.com>
References: <cover.1476447057.git.paweljarosz3691@gmail.com>
Message-ID: <6992e44d06e1615048717deb3dd76e52d26da869.1476447057.git.paweljarosz3691@gmail.com>

Initialize PLL, cpu bus and peripherial bus rate while kernel init.
No other module does than.

This gives us performance boost observable for example in mmc transfers.

Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
---

Changes in v2:
- added peripherial and cpu bus
- removed PLL_DPLL, PLL_APLL

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

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 0d0dae3..29dd434 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -151,6 +151,15 @@
 
 		#clock-cells = <1>;
 		#reset-cells = <1>;
+		assigned-clocks = <&cru PLL_CPLL>, <&cru PLL_GPLL>,
+				  <&cru ACLK_CPU>, <&cru HCLK_CPU>,
+				  <&cru PCLK_CPU>, <&cru ACLK_PERI>,
+				  <&cru HCLK_PERI>, <&cru PCLK_PERI>;
+
+		assigned-clock-rates = <400000000>, <594000000>,
+				       <300000000>, <150000000>,
+				       <75000000>, <300000000>,
+				       <150000000>, <75000000>;
 	};
 
 	timer at 2000e000 {
-- 
2.7.4



From heiko at sntech.de  Fri Oct 14 06:28:30 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 14 Oct 2016 15:28:30 +0200
Subject: [PATCH v2 0/2] Assign RK3066 clocks at boot time
In-Reply-To: <cover.1476447057.git.paweljarosz3691@gmail.com>
References: <cover.1476447057.git.paweljarosz3691@gmail.com>
Message-ID: <1569308.lsrqUgJ5m1@phil>

Am Freitag, 14. Oktober 2016, 14:16:21 CEST schrieb Pawe? Jarosz:
> This patchset sets rk3066 PLL, CPU and PERI clocks while kernel init.
> 
> Pawe? Jarosz (2):
>   clk: rockchip: Add bindings for cpu and peri clocks on rk3066
>   ARM: dts: rockchip: initialize rk3066 PLL clock rate

changes look good. One thing to keep in mind is that we need clock-id 
additions in a separate patch (as they need to be on a shared branch).

I can do this split of patch1 on my own here, so no need to resend the series 
and will do that after 4.9-rc1 (probably somewhere after sunday) as I need a 
stable base for that shared branch.


Heiko


From paweljarosz3691 at gmail.com  Fri Oct 14 07:11:26 2016
From: paweljarosz3691 at gmail.com (=?UTF-8?Q?Pawe=c5=82_Jarosz?=)
Date: Fri, 14 Oct 2016 16:11:26 +0200
Subject: [PATCH v2 0/2] Assign RK3066 clocks at boot time
In-Reply-To: <1569308.lsrqUgJ5m1@phil>
References: <cover.1476447057.git.paweljarosz3691@gmail.com>
 <1569308.lsrqUgJ5m1@phil>
Message-ID: <58a16125-d0bd-1019-eee3-615b35c71c6a@gmail.com>

W dniu 14.10.2016 o 15:28, Heiko Stuebner pisze:
> changes look good. One thing to keep in mind is that we need clock-id
> additions in a separate patch (as they need to be on a shared branch).
>
> I can do this split of patch1 on my own here, so no need to resend the series
> and will do that after 4.9-rc1 (probably somewhere after sunday) as I need a
> stable base for that shared branch.
>
>
> Heiko

Thanks Heiko.


From heiko at sntech.de  Fri Oct 14 07:18:06 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 14 Oct 2016 16:18:06 +0200
Subject: [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200
 speed from rk3288-veyron-speedy.
In-Reply-To: <87twd1vzc5.fsf@aikidev.net>
References: <87twd1vzc5.fsf@aikidev.net>
Message-ID: <1556360.cZVpdmzNha@phil>

Am Dienstag, 27. September 2016, 13:53:46 CEST schrieb Vagrant Cascadian:
> This essentially mimics what was done with rk3288-veyron-minnie in
> commit 984926781122f034d5bc9962815d135b6c4a8e1d.
> 
> The eMMC of the speedy Chromebook also appears to need the same tuning
> workaround, as it frequently fails to recognize the eMMC without it.
> 
> Signed-off-by: Vagrant Cascadian <vagrantc at aikidev.net>

applied as fix for 4.9.

Your mail client mangled that patch a lot (tabs etc), so it didn't apply 
cleanly. As it is a quite small one, I fixed that up myself, but please try to 
make your mail client send correct patches in the future or use git send-email 
:-)


Thanks
Heiko


From heiko at sntech.de  Fri Oct 14 10:06:00 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 14 Oct 2016 19:06:00 +0200
Subject: [PATCH] clk: rockchip: don't return NULL when failing to register
 ddrclk branch
In-Reply-To: <1476275501-2653-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476275501-2653-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <6436195.q1mHK715BP@phil>

Am Mittwoch, 12. Oktober 2016, 20:31:41 CEST schrieb Shawn Lin:
> rockchip_clk_register_ddrclk should not return NULL when faling
> to call clk_register, otherwise rockchip_clk_register_branches
> prints "unknown clock type". The acutal case is that it's a known
> clock type but we fail to regiser it, which may makes user confuse
> the reason of failure. And the pr_err here is pointless as
> rockchip_clk_register_branches will also print the similar message.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

thanks for catching this ... applied to a clk-fixes branch for 4.9


From heiko at sntech.de  Fri Oct 14 10:18:20 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 14 Oct 2016 19:18:20 +0200
Subject: [PATCH 3/3] arm64: dts: rockchip: remove always-on and boot-on
 from vcc_sd
In-Reply-To: <1474516939-22001-3-git-send-email-shawn.lin@rock-chips.com>
References: <1474516939-22001-1-git-send-email-shawn.lin@rock-chips.com>
 <1474516939-22001-3-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <2696393.duMc0ZLDdc@phil>

Hi Shawn,

Am Donnerstag, 22. September 2016, 12:02:19 CEST schrieb Shawn Lin:
> Please don't add these for vcc_sd, and mmc-core/driver will control
> it. Otherwise, it will waste energy even without sdmmc in slot.
> 
> Moreover, it will causes a bug:
> If we insert/remove sd card, we could see
> [9.337271] mmc0: new ultra high speed SDR25 SDHC card at address 0007
> [9.345144] mmcblk0: mmc0:0007 SD32G 29.3 GiB
> 
> This is okay for normal sd insert/remove test, but when I debug some
> issues for sdmmc, I did unbind/bind test. And there is a interesting
> phenomenon when we bind the driver again:
> [58.314069] mmc0: new high speed SDHC card at address 0007
> [58.320282] mmcblk0: mmc0:0007 SD32G 29.3 GiB
> 
> So the sd card could just support high speed without power cycle
> since the vcc_sd is always on, which makes the sd card fail to
> reinit its internal ocr mask.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

>  arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts        | 2 --
>  arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts | 2 --

I've applied the geekbox + r68 parts of the patch as fix for 4.9 ...

>  arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts        | 2 --

and merged the px5-evb-part with the core patch adding the px5-evb,
so that we don't introduce known regressions unecessarily.


Thanks for fixing this
Heiko


From heiko at sntech.de  Fri Oct 14 10:20:57 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 14 Oct 2016 19:20:57 +0200
Subject: [PATCH 1/3] arm64: dts: rockchip: Add more properties for emmc on
 px5-evb
In-Reply-To: <1474516939-22001-1-git-send-email-shawn.lin@rock-chips.com>
References: <1474516939-22001-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <2240375.BUoJWukMyM@phil>

Am Donnerstag, 22. September 2016, 12:02:17 CEST schrieb Shawn Lin:
> The emmc on px5-evb can support hs200, so let's add mmc-hs200-1_8v.
> And in order to speed up the boot time, we could add no-sdio and
> no-sd to simplify the initialization.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

applied after restoring the alphabetical ordering. Please try to keep that in 
mind in future patches :-)


Thanks
Heiko


From heiko at sntech.de  Fri Oct 14 10:29:08 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 14 Oct 2016 19:29:08 +0200
Subject: [PATCH 2/3] arm64: dts: rockchip: add sdmmc support for px5-evb
In-Reply-To: <1474516939-22001-2-git-send-email-shawn.lin@rock-chips.com>
References: <1474516939-22001-1-git-send-email-shawn.lin@rock-chips.com>
 <1474516939-22001-2-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <5652149.PmckHYSsLx@phil>

Am Donnerstag, 22. September 2016, 12:02:18 CEST schrieb Shawn Lin:
> px5-evb has one sdmmc slot, so we could support sdmmc.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

applied for 4.10 with the changes described below. Please keep them in mind 
for future patches :-) .


>  arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
> b/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts index 3e0b522..f59049b
> 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
> @@ -98,6 +98,25 @@
>  	vqmmc-supply = <&vcc18_flash>;
>  };
> 
> +&sdmmc {

moved sdmmc node to its alphabetical correct position

> +	status = "okay";
> +	bus-width = <4>;
> +	cap-mmc-highspeed;
> +	cap-sd-highspeed;
> +	card-detect-delay = <200>;
> +	rockchip,default-sample-phase = <90>;
> +	num-slots = <1>;

restored alphabetical ordering

> +	no-emmc;
> +	no-sdio;
> +	sd-uhs-sdr12;
> +	sd-uhs-sdr25;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdmmc_clk>, <&sdmmc_cmd>, <&sdmmc_bus4>, <&sdmmc_cd>;
> +	vmmc-supply = <&vcc_sd>;
> +	vqmmc-supply = <&vccio_sd>;
> +};
> +
> +

removed 2nd blank line

>  &i2c0 {
>  	status = "okay";


Heiko


From heiko at sntech.de  Fri Oct 14 11:21:46 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 14 Oct 2016 20:21:46 +0200
Subject: [PATCH v3 1/2] devicetree: Add vendor prefix for Rikomagic
In-Reply-To: <d51c7719a314f723a0a69b932997502a2fe0e3ee.1475957884.git.paweljarosz3691@gmail.com>
References: <cover.1475957884.git.paweljarosz3691@gmail.com>
 <d51c7719a314f723a0a69b932997502a2fe0e3ee.1475957884.git.paweljarosz3691@gmail.com>
Message-ID: <7746988.aAT8rmUZDV@phil>

Am Samstag, 8. Oktober 2016, 22:22:05 CEST schrieb Pawe? Jarosz:
> Add Rikomagic to vendor-prefixes.txt
> 
> Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
> ---
> 
> Changes in v2:
> - none
> 
> Changes in v3:
> - none
> 
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt index
> 69caf14..3edfa08 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -224,6 +224,7 @@ realtek Realtek Semiconductor Corp.
>  renesas	Renesas Electronics Corporation
>  richtek	Richtek Technology Corporation
>  ricoh	Ricoh Co. Ltd.
> +rikomagic	Rikomagic
				^ Rikomagic Tech Corp. Ltd

(according to http://www.rikomagic.com/en/index.html)

But I can change that myself. I'll just need to wait a bit more if Rob or Mark 
want to Ack this vendor-prefix addition.


Heiko


From paweljarosz3691 at gmail.com  Fri Oct 14 11:55:06 2016
From: paweljarosz3691 at gmail.com (=?UTF-8?Q?Pawe=c5=82_Jarosz?=)
Date: Fri, 14 Oct 2016 20:55:06 +0200
Subject: [PATCH v3 1/2] devicetree: Add vendor prefix for Rikomagic
In-Reply-To: <7746988.aAT8rmUZDV@phil>
References: <cover.1475957884.git.paweljarosz3691@gmail.com>
 <d51c7719a314f723a0a69b932997502a2fe0e3ee.1475957884.git.paweljarosz3691@gmail.com>
 <7746988.aAT8rmUZDV@phil>
Message-ID: <ded14706-1b9d-1808-283c-bdf3f1b51abf@gmail.com>

>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt index
>> 69caf14..3edfa08 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -224,6 +224,7 @@ realtek Realtek Semiconductor Corp.
>>   renesas	Renesas Electronics Corporation
>>   richtek	Richtek Technology Corporation
>>   ricoh	Ricoh Co. Ltd.
>> +rikomagic	Rikomagic
> 				^ Rikomagic Tech Corp. Ltd
>
> (according to http://www.rikomagic.com/en/index.html)
>
> But I can change that myself. I'll just need to wait a bit more if Rob or Mark
> want to Ack this vendor-prefix addition.
>
>
> Heiko

Sorry for that.


Pawe?


From robh+dt at kernel.org  Fri Oct 14 14:10:04 2016
From: robh+dt at kernel.org (Rob Herring)
Date: Fri, 14 Oct 2016 16:10:04 -0500
Subject: [PATCH v3 1/2] devicetree: Add vendor prefix for Rikomagic
In-Reply-To: <7746988.aAT8rmUZDV@phil>
References: <cover.1475957884.git.paweljarosz3691@gmail.com>
 <d51c7719a314f723a0a69b932997502a2fe0e3ee.1475957884.git.paweljarosz3691@gmail.com>
 <7746988.aAT8rmUZDV@phil>
Message-ID: <CAL_JsqJZoTa2ui_st1CeY96Qoaa3oXhvbGSUywWFbEfGC+KUqA@mail.gmail.com>

On Fri, Oct 14, 2016 at 1:21 PM, Heiko Stuebner <heiko at sntech.de> wrote:
> Am Samstag, 8. Oktober 2016, 22:22:05 CEST schrieb Pawe? Jarosz:
>> Add Rikomagic to vendor-prefixes.txt
>>
>> Signed-off-by: Pawe? Jarosz <paweljarosz3691 at gmail.com>
>> ---
>>
>> Changes in v2:
>> - none
>>
>> Changes in v3:
>> - none
>>
>>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt index
>> 69caf14..3edfa08 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -224,6 +224,7 @@ realtek Realtek Semiconductor Corp.
>>  renesas      Renesas Electronics Corporation
>>  richtek      Richtek Technology Corporation
>>  ricoh        Ricoh Co. Ltd.
>> +rikomagic    Rikomagic
>                                 ^ Rikomagic Tech Corp. Ltd
>
> (according to http://www.rikomagic.com/en/index.html)
>
> But I can change that myself. I'll just need to wait a bit more if Rob or Mark
> want to Ack this vendor-prefix addition.

Acked-by: Rob Herring <robh at kernel.org>


From jacobchen110 at gmail.com  Sat Oct 15 08:07:36 2016
From: jacobchen110 at gmail.com (=?UTF-8?B?6ZmI6LGq?=)
Date: Sat, 15 Oct 2016 23:07:36 +0800
Subject: [PATCH v8 2/3] usb: dwc2: assert phy reset when waking up in
 rk3288 platform
In-Reply-To: <1474743019-1050-3-git-send-email-ayaka@soulik.info>
References: <1474743019-1050-1-git-send-email-ayaka@soulik.info>
 <1474743019-1050-3-git-send-email-ayaka@soulik.info>
Message-ID: <CAFLEztRLJbMj-ttGBsCWCMW=+0N3bbMQ0c4YcgDyvUDYs1SSkA@mail.gmail.com>

2016-09-25 2:50 GMT+08:00 Randy Li <ayaka at soulik.info>:
> On the rk3288 USB host-only port (the one that's not the OTG-enabled
> port) the PHY can get into a bad state when a wakeup is asserted (not
> just a wakeup from full system suspend but also a wakeup from
> autosuspend).
>
> We can get the PHY out of its bad state by asserting its "port reset",
> but unfortunately that seems to assert a reset onto the USB bus so it
> could confuse things if we don't actually deenumerate / reenumerate the
> device.
>
> We can also get the PHY out of its bad state by fully resetting it using
> the reset from the CRU (clock reset unit) in chip, which does a more full
> reset.  The CRU-based reset appears to actually cause devices on the bus
> to be removed and reinserted, which fixes the problem (albeit in a hacky
> way).
>
> It's unfortunate that we need to do a full re-enumeration of devices at
> wakeup time, but this is better than alternative of letting the bus get
> wedged.
>
> Signed-off-by: Randy Li <ayaka at soulik.info>
> ---
>  drivers/usb/dwc2/core_intr.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
> index d85c5c9..af27edc 100644
> --- a/drivers/usb/dwc2/core_intr.c
> +++ b/drivers/usb/dwc2/core_intr.c
> @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg)
>  static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>  {
>         int ret;
> +       struct device_node *np = hsotg->dev->of_node;
>
>         /* Clear interrupt */
>         dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
> @@ -379,6 +380,16 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>                         /* Restart the Phy Clock */
>                         pcgcctl &= ~PCGCTL_STOPPCLK;
>                         dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
> +
> +                       /*
> +                        * It is a quirk in Rockchip RK3288, causing by
> +                        * a hardware bug. This will propagate out and
> +                        * eventually we'll re-enumerate the device.
> +                        * Not great but the best we can do.
> +                        */
> +                       if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
> +                               phy_reset(hsotg->phy);

It will call mutex_lock in phy_reset.


> +
>                         mod_timer(&hsotg->wkp_timer,
>                                   jiffies + msecs_to_jiffies(71));
>                 } else {
> --
> 2.7.4
>

What is the status of this patch?
Sleeping calls(phy_reset ==> mutex) shouldn't be used in irq handler.
Randy will correct that?


From Julia.Lawall at lip6.fr  Sat Oct 15 07:55:44 2016
From: Julia.Lawall at lip6.fr (Julia Lawall)
Date: Sat, 15 Oct 2016 16:55:44 +0200
Subject: [PATCH 0/7] constify snd_soc_ops structures
Message-ID: <1476543351-17858-1-git-send-email-Julia.Lawall@lip6.fr>

Constify snd_soc_ops structures.

---

 sound/soc/atmel/atmel_wm8904.c                  |    2 +-
 sound/soc/fsl/fsl-asoc-card.c                   |    2 +-
 sound/soc/fsl/imx-wm8962.c                      |    2 +-
 sound/soc/generic/simple-card.c                 |    2 +-
 sound/soc/generic/simple-scu-card.c             |    2 +-
 sound/soc/intel/boards/bdw-rt5677.c             |    2 +-
 sound/soc/intel/boards/broadwell.c              |    2 +-
 sound/soc/intel/boards/bxt_da7219_max98357a.c   |    4 ++--
 sound/soc/intel/boards/bxt_rt298.c              |    4 ++--
 sound/soc/intel/boards/bytcr_rt5640.c           |    4 ++--
 sound/soc/intel/boards/bytcr_rt5651.c           |    4 ++--
 sound/soc/intel/boards/cht_bsw_max98090_ti.c    |    4 ++--
 sound/soc/intel/boards/cht_bsw_rt5645.c         |    4 ++--
 sound/soc/intel/boards/cht_bsw_rt5672.c         |    4 ++--
 sound/soc/intel/boards/haswell.c                |    2 +-
 sound/soc/intel/boards/skl_nau88l25_max98357a.c |    6 +++---
 sound/soc/intel/boards/skl_nau88l25_ssm4567.c   |    6 +++---
 sound/soc/intel/boards/skl_rt286.c              |    4 ++--
 sound/soc/kirkwood/armada-370-db.c              |    2 +-
 sound/soc/mxs/mxs-sgtl5000.c                    |    2 +-
 sound/soc/qcom/storm.c                          |    2 +-
 sound/soc/rockchip/rk3399_gru_sound.c           |    6 +++---
 sound/soc/rockchip/rockchip_max98090.c          |    2 +-
 sound/soc/rockchip/rockchip_rt5645.c            |    2 +-
 sound/soc/tegra/tegra_alc5632.c                 |    2 +-
 sound/soc/tegra/tegra_max98090.c                |    2 +-
 sound/soc/tegra/tegra_rt5640.c                  |    2 +-
 sound/soc/tegra/tegra_rt5677.c                  |    2 +-
 sound/soc/tegra/tegra_sgtl5000.c                |    2 +-
 sound/soc/tegra/tegra_wm8753.c                  |    2 +-
 sound/soc/tegra/tegra_wm8903.c                  |    2 +-
 sound/soc/tegra/trimslice.c                     |    2 +-
 32 files changed, 46 insertions(+), 46 deletions(-)


From Julia.Lawall at lip6.fr  Sat Oct 15 07:55:47 2016
From: Julia.Lawall at lip6.fr (Julia Lawall)
Date: Sat, 15 Oct 2016 16:55:47 +0200
Subject: [PATCH 3/7] ASoC: rockchip: constify snd_soc_ops structures
In-Reply-To: <1476543351-17858-1-git-send-email-Julia.Lawall@lip6.fr>
References: <1476543351-17858-1-git-send-email-Julia.Lawall@lip6.fr>
Message-ID: <1476543351-17858-4-git-send-email-Julia.Lawall@lip6.fr>

Check for snd_soc_ops structures that are only stored in the ops field of a
snd_soc_dai_link structure.  This field is declared const, so snd_soc_ops
structures that have this property can be declared as const also.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct snd_soc_ops i at p = { ... };

@ok1@
identifier r.i;
struct snd_soc_dai_link e;
position p;
@@
e.ops = &i at p;

@ok2@
identifier r.i, e;
position p;
@@
struct snd_soc_dai_link e[] = { ..., { .ops = &i at p, }, ..., };

@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
struct snd_soc_ops e;
@@
e at i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct snd_soc_ops i = { ... };
// </smpl>

The effect on the layout of the .o files is shown by the following output
of the size command, first before then after the transformation:

   text    data     bss     dec     hex filename
   5027    2488     416    7931    1efb sound/soc/rockchip/rk3399_gru_sound.o
   5219    2312     416    7947    1f0b sound/soc/rockchip/rk3399_gru_sound.o

   text    data     bss     dec     hex filename
   3499    1648     384    5531    159b sound/soc/rockchip/rockchip_max98090.o
   3563    1584     384    5531    159b sound/soc/rockchip/rockchip_max98090.o

   text    data     bss     dec     hex filename
   3455    1536     384    5375    14ff sound/soc/rockchip/rockchip_rt5645.o
   3519    1480     384    5383    1507 sound/soc/rockchip/rockchip_rt5645.o

Signed-off-by: Julia Lawall <Julia.Lawall at lip6.fr>

---
 sound/soc/rockchip/rk3399_gru_sound.c  |    6 +++---
 sound/soc/rockchip/rockchip_max98090.c |    2 +-
 sound/soc/rockchip/rockchip_rt5645.c   |    2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff -u -p a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -228,15 +228,15 @@ static int rockchip_sound_da7219_init(st
 	return 0;
 }
 
-static struct snd_soc_ops rockchip_sound_max98357a_ops = {
+static const struct snd_soc_ops rockchip_sound_max98357a_ops = {
 	.hw_params = rockchip_sound_max98357a_hw_params,
 };
 
-static struct snd_soc_ops rockchip_sound_rt5514_ops = {
+static const struct snd_soc_ops rockchip_sound_rt5514_ops = {
 	.hw_params = rockchip_sound_rt5514_hw_params,
 };
 
-static struct snd_soc_ops rockchip_sound_da7219_ops = {
+static const struct snd_soc_ops rockchip_sound_da7219_ops = {
 	.hw_params = rockchip_sound_da7219_hw_params,
 };
 
diff -u -p a/sound/soc/rockchip/rockchip_max98090.c b/sound/soc/rockchip/rockchip_max98090.c
--- a/sound/soc/rockchip/rockchip_max98090.c
+++ b/sound/soc/rockchip/rockchip_max98090.c
@@ -119,7 +119,7 @@ static int rk_aif1_hw_params(struct snd_
 	return ret;
 }
 
-static struct snd_soc_ops rk_aif1_ops = {
+static const struct snd_soc_ops rk_aif1_ops = {
 	.hw_params = rk_aif1_hw_params,
 };
 
diff -u -p a/sound/soc/rockchip/rockchip_rt5645.c b/sound/soc/rockchip/rockchip_rt5645.c
--- a/sound/soc/rockchip/rockchip_rt5645.c
+++ b/sound/soc/rockchip/rockchip_rt5645.c
@@ -135,7 +135,7 @@ static int rk_init(struct snd_soc_pcm_ru
 				     &headset_jack);
 }
 
-static struct snd_soc_ops rk_aif1_ops = {
+static const struct snd_soc_ops rk_aif1_ops = {
 	.hw_params = rk_aif1_hw_params,
 };
 



From ayaka at soulik.info  Sat Oct 15 11:03:11 2016
From: ayaka at soulik.info (ayaka)
Date: Sun, 16 Oct 2016 02:03:11 +0800
Subject: rockchip: drm: analogix_dp-rockchip would stock the kernel
Message-ID: <1a7ebbe4-a9d8-610d-7cd5-41f5fe8355a5@soulik.info>

Hello:
    I meet a problem with eDP in rk3288 with the linux next 20161006, it 
is just like the early stage of 4.4
kernel.  I have added a eDP panel entry in the firefly reload board, 
once the kernel loaded analogix_dp-rockchip.ko, after printed the 
following two lines, the kernel stop working.
rockchip-drm display-subsystem: bound ff940000.vop (ops 
vop_component_ops [rockchipdrm])
rockchip-drm display-subsystem: bound ff930000.vop (ops 
vop_component_ops [rockchipdrm])
In the early June of the 4.4 kernel, I meet the same problem with rk3288 
evb board with different error message, I have to disable the display 
system that time.
   In the today test, I meet the same problem with rk3399 evb board in 4.4.
   I have no idea what caused that, and it is a little hard to debug as 
kernel still would never kill that task.
                                                             Randy Li


From contact at paulk.fr  Sun Oct 16 12:49:43 2016
From: contact at paulk.fr (Paul Kocialkowski)
Date: Sun, 16 Oct 2016 21:49:43 +0200
Subject: [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200
 speed from rk3288-veyron-speedy.
In-Reply-To: <87twd1vzc5.fsf@aikidev.net>
References: <87twd1vzc5.fsf@aikidev.net>
Message-ID: <1476647383.3885.3.camel@paulk.fr>

Hi,

Le mardi 27 septembre 2016 ? 13:53 -0700, Vagrant Cascadian a ?crit?:
> This essentially mimics what was done with rk3288-veyron-minnie in
> commit 984926781122f034d5bc9962815d135b6c4a8e1d.
> 
> The eMMC of the speedy Chromebook also appears to need the same tuning
> workaround, as it frequently fails to recognize the eMMC without it.

I have a device where (without this patch) eMMC sometimes fails, with:
[????3.561010] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to 175
[????3.571742] mmc2: new HS200 MMC card at address 0001
[????3.571943] mmcblk2: mmc2:0001 HAG2e 14.7 GiB?
[????3.572026] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
[????3.572107] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
[????3.572181] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
[????3.685647] mmcblk2: error -110 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0

And sometimes works, with:
[????3.451058] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to 176
[????3.491093] mmc2: new HS200 MMC card at address 0001
[????3.491277] mmcblk2: mmc2:0001 HAG2e 14.7 GiB?
[????3.491345] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
[????3.491409] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
[????3.491474] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
[????3.493548]??mmcblk2: p1 p2

However, with this change, it always fails, with:
[????3.322129] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
[????3.333174] mmc2: error -110 whilst initialising MMC card

I don't have so much time to investigate this issue, but it's clear that this
patch doesn't fix the issue (and actually worsens it) for my device.

Cheers!

> Signed-off-by: Vagrant Cascadian <vagrantc at aikidev.net>
> ---
> Changes in v2:
> ?- Added Signed-off-by.
> 
> ?arch/arm/boot/dts/rk3288-veyron-speedy.dts | 5 +++++
> ?1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> index a0d033f..500fd18 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> +++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> @@ -124,6 +124,11 @@
> ????????????&sdmmc_bus4>;
> ?};
> 
> +
> +&emmc {
> +???????/delete-property/mmc-hs200-1_8v;
> +};
> +
> ?&vcc_5v {
> ????enable-active-high;
> ????gpio = <&gpio7 21 GPIO_ACTIVE_HIGH>;
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
-- 
Paul Kocialkowski, developer of free digital technology at the lower levels

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20161016/6ae8dfd0/attachment.sig>

From contact at paulk.fr  Sun Oct 16 13:01:41 2016
From: contact at paulk.fr (Paul Kocialkowski)
Date: Sun, 16 Oct 2016 22:01:41 +0200
Subject: RK3288 USB issues with ath9k_htc Wi-Fi dongles on veyron devices
Message-ID: <1476648101.3885.14.camel@paulk.fr>

I'm trying to use ath9k_htc Wi-Fi dongles with various rk3288 veyron devices,
which currently do not work.

I have a bunch of different dongles, that all work nicely with other devices.
The kernel I'm running is 4.9-rc1 and the USB connectors I'm using are linked to
OTG and HOST1 (both DWC2 controllers).

I have applied the latest version of Randy Li's patches, that fix an USB error
with these controllers. They do not fix my issue, or otherwise change the
behavior I'm seeing. The very same device running with the chromeos-3.14 kernel
works nicely and doesn't have this issue.

There are two different cases, that happen interchangeably and randomly:

1. The dongle is detected and the driver is probed but the first register reads
fail:

[??322.841142] usb 2-1: new high-speed USB device number 3 using dwc2
[??323.104591] usb 2-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[??323.113489] usb 2-1: Direct firmware load for ath9k_htc/htc_9271-1.4.0.fw failed with error -2
[??323.122204] usb 2-1: ath9k_htc: Firmware htc_9271.fw requested
[??323.414012] usb 2-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51008
[??323.665556] ath9k_htc 2-1:1.0: ath9k_htc: HTC initialized with 33 credits
[??324.710992] ath: phy1: Timeout waiting for WMI command: WMI_REG_READ_CMDID
[??324.717899] ath: phy1: REGISTER READ FAILED: (0x4020, -110)
[??324.723525] ath: phy1: Mac Chip Rev 0x0f.3 is not supported by this driver
[??324.730416] ath: phy1: Unable to initialize hardware; initialization status: -95
[??324.737853] ath: phy1: Unable to initialize hardware; initialization status: -95
[??324.745296] ath9k_htc: Failed to initialize the device
[??324.755440] usb 2-1: ath9k_htc: USB layer deinitialized

2. The dongle is detected, the first few register reads succeed but register
reads fail as soon as the dongle enters power-saving mode:

[???68.070377] ath: phy0: Removed a station entry for VIF 0 (idx: 0)
[???68.078752] ath: phy0: Detach Interface at idx: 0
[???68.085260] ath: phy0: AWAKE -> FULL-SLEEP
[???68.090766] ath: phy0: FULL-SLEEP -> AWAKE
[???68.107512] ath: phy0: AWAKE -> FULL-SLEEP
[???68.112756] ath: phy0: Driver halt
[???68.117108] ath: phy0: Starting driver with initial channel: 2412 MHz
[???68.123577] ath: phy0: FULL-SLEEP -> AWAKE
[???69.191104] ath: phy0: Timeout waiting for WMI command: WMI_REG_READ_CMDID
[???69.197987] ath: phy0: REGISTER READ FAILED: (0x7044, -110)
[???70.231015] ath: phy0: Timeout waiting for WMI command: WMI_REG_RMW_CMDID

What could be causing these issues?

Cheers!

-- 
Paul Kocialkowski, developer of free digital technology at the lower levels

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20161016/1b55bd2d/attachment.sig>

From mark.yao at rock-chips.com  Sun Oct 16 17:57:09 2016
From: mark.yao at rock-chips.com (Mark yao)
Date: Mon, 17 Oct 2016 08:57:09 +0800
Subject: rockchip: drm: analogix_dp-rockchip would stock the kernel
In-Reply-To: <1a7ebbe4-a9d8-610d-7cd5-41f5fe8355a5@soulik.info>
References: <1a7ebbe4-a9d8-610d-7cd5-41f5fe8355a5@soulik.info>
Message-ID: <580421E5.9030609@rock-chips.com>

On 2016?10?16? 02:03, ayaka wrote:
> Hello:
>    I meet a problem with eDP in rk3288 with the linux next 20161006, 
> it is just like the early stage of 4.4
> kernel.  I have added a eDP panel entry in the firefly reload board, 
> once the kernel loaded analogix_dp-rockchip.ko, after printed the 
> following two lines, the kernel stop working.
> rockchip-drm display-subsystem: bound ff940000.vop (ops 
> vop_component_ops [rockchipdrm])
> rockchip-drm display-subsystem: bound ff930000.vop (ops 
> vop_component_ops [rockchipdrm])

Hi ayaka

This log seems no problem.

How about tested it with build-in? we had test it with build-in.

Maybe this patch can help you, you can have a try.
     https://patchwork.kernel.org/patch/9374135

Thanks.

> In the early June of the 4.4 kernel, I meet the same problem with 
> rk3288 evb board with different error message, I have to disable the 
> display system that time.
>   In the today test, I meet the same problem with rk3399 evb board in 
> 4.4.
>   I have no idea what caused that, and it is a little hard to debug as 
> kernel still would never kill that task.
>                                                             Randy Li
>
>
>


-- 
?ark Yao




From randy.li at rock-chips.com  Sun Oct 16 18:12:50 2016
From: randy.li at rock-chips.com (Randy Li)
Date: Mon, 17 Oct 2016 09:12:50 +0800
Subject: rockchip: drm: analogix_dp-rockchip would stock the kernel
In-Reply-To: <580421E5.9030609@rock-chips.com>
References: <1a7ebbe4-a9d8-610d-7cd5-41f5fe8355a5@soulik.info>
 <580421E5.9030609@rock-chips.com>
Message-ID: <e04e8feb-030e-5c74-cc77-5b6f58e24a2d@rock-chips.com>



On 10/17/2016 08:57 AM, Mark yao wrote:
> On 2016?10?16? 02:03, ayaka wrote:
>> Hello:
>>    I meet a problem with eDP in rk3288 with the linux next 20161006,
>> it is just like the early stage of 4.4
>> kernel.  I have added a eDP panel entry in the firefly reload board,
>> once the kernel loaded analogix_dp-rockchip.ko, after printed the
>> following two lines, the kernel stop working.
>> rockchip-drm display-subsystem: bound ff940000.vop (ops
>> vop_component_ops [rockchipdrm])
>> rockchip-drm display-subsystem: bound ff930000.vop (ops
>> vop_component_ops [rockchipdrm])
>
> Hi ayaka
>
> This log seems no problem.
I found the problem, it is the eDP_AVDD_1V0 and eDP_AVDD_1V8 must have a 
proper power supply. I would submit a patch to enable the regulator at 
DP driver.
>
> How about tested it with build-in? we had test it with build-in.
>
> Maybe this patch can help you, you can have a try.
>     https://patchwork.kernel.org/patch/9374135
>
> Thanks.
>
>> In the early June of the 4.4 kernel, I meet the same problem with
>> rk3288 evb board with different error message, I have to disable the
>> display system that time.
>>   In the today test, I meet the same problem with rk3399 evb board in
>> 4.4.
>>   I have no idea what caused that, and it is a little hard to debug as
>> kernel still would never kill that task.
>>                                                             Randy Li
>>
>>
>>
>
>

-- 
Randy Li
The third produce department
===========================================================================
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===========================================================================



From randy.li at rock-chips.com  Sun Oct 16 21:02:39 2016
From: randy.li at rock-chips.com (Randy Li)
Date: Mon, 17 Oct 2016 12:02:39 +0800
Subject: something different ideas from chromium's decoder settings API
Message-ID: <91e1ac78-8a2f-35da-f84f-b35616153860@rock-chips.com>

Hello Hans and all media staff:
   Recently I have try to run the my VA-API driver in Rockchip RK3399, 
after ported the driver in chromium to request API, it works now.
Thanks to the chromium project effort, both the decoder settings API and 
structures are the same between rk3288 and rk3399.
   However the those v4l2 decoder structures are too different between 
the VA-API, I know those VA-API structures would not enough for our 
situation. If we could expend the VA-API structures, it sounds more easy 
to start up a standard.
   Also creating a new v4l2 fourcc for each format is not convenience, 
also the data format may be a little different, but it is still a part 
of the original data right?
   The slice API and request API are still not clearly, I just put my 
ideas here and hoping more ideas coming.
P.S Does somebody know where the chromium would switch to request API 
instead of the config store?
-- 
Randy Li
The third produce department
===========================================================================
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===========================================================================



From haihao.xiang at intel.com  Sun Oct 16 21:42:52 2016
From: haihao.xiang at intel.com (Xiang, Haihao)
Date: Mon, 17 Oct 2016 04:42:52 +0000
Subject: [Libva] something different ideas from chromium's decoder
 settings API
In-Reply-To: <91e1ac78-8a2f-35da-f84f-b35616153860@rock-chips.com>
References: <91e1ac78-8a2f-35da-f84f-b35616153860@rock-chips.com>
Message-ID: <1476679372.4871.40.camel@intel.com>


Hi Randy,?

I saw a statement below at the end of your email:

======
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please
contact the sender by reply e-mail and destroy all copies of the
original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
======

Please do not send your email to libva at lists.freedesktop.org if you
don't want to discuss your question/idea publicly because?libva at lists.f
reedesktop?is only used for public discussion of libva, otherwise
please remove the above statement in your email.

Thanks
Haihao


From chenjh at rock-chips.com  Mon Oct 17 02:03:10 2016
From: chenjh at rock-chips.com (Jianhong Chen)
Date: Mon, 17 Oct 2016 17:03:10 +0800
Subject: [PATCH] mfd: rk808: RK818 uses DEV_OFF to power off supplies
Message-ID: <1476694990-1887-1-git-send-email-chenjh@rock-chips.com>

DEV_OFF and DEV_OFF_RST functions for RK808 are designed error that
only DEV_OFF_RST can power off supplies. RK818 has been fixed this
issue, so that DEV_OFF is used to power off supplies.

Signed-off-by: Jianhong Chen <chenjh at rock-chips.com>
---
 drivers/mfd/rk808.c       | 23 ++++++++++++++++++++++-
 include/linux/mfd/rk808.h |  1 +
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index 0f8acc5..2c9acdb 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -290,6 +290,24 @@ static void rk808_device_shutdown(void)
 		dev_err(&rk808_i2c_client->dev, "power off error!\n");
 }
 
+static void rk818_device_shutdown(void)
+{
+	int ret;
+	struct rk808 *rk808 = i2c_get_clientdata(rk808_i2c_client);
+
+	if (!rk808) {
+		dev_warn(&rk808_i2c_client->dev,
+			 "have no rk818, so do nothing here\n");
+		return;
+	}
+
+	ret = regmap_update_bits(rk808->regmap,
+				 RK818_DEVCTRL_REG,
+				 DEV_OFF, DEV_OFF);
+	if (ret)
+		dev_err(&rk808_i2c_client->dev, "power off error!\n");
+}
+
 static const struct of_device_id rk808_of_match[] = {
 	{ .compatible = "rockchip,rk808" },
 	{ .compatible = "rockchip,rk818" },
@@ -304,6 +322,7 @@ static int rk808_probe(struct i2c_client *client,
 	struct rk808 *rk808;
 	const struct rk808_reg_data *pre_init_reg;
 	const struct mfd_cell *cells;
+	void (*pm_pwroff_fn)(void);
 	int nr_pre_init_regs;
 	int nr_cells;
 	int pm_off = 0;
@@ -331,6 +350,7 @@ static int rk808_probe(struct i2c_client *client,
 		nr_pre_init_regs = ARRAY_SIZE(rk808_pre_init_reg);
 		cells = rk808s;
 		nr_cells = ARRAY_SIZE(rk808s);
+		pm_pwroff_fn = rk808_device_shutdown;
 		break;
 	case RK818_ID:
 		rk808->regmap_cfg = &rk818_regmap_config;
@@ -339,6 +359,7 @@ static int rk808_probe(struct i2c_client *client,
 		nr_pre_init_regs = ARRAY_SIZE(rk818_pre_init_reg);
 		cells = rk818s;
 		nr_cells = ARRAY_SIZE(rk818s);
+		pm_pwroff_fn = rk818_device_shutdown;
 		break;
 	default:
 		dev_err(&client->dev, "Unsupported RK8XX ID %lu\n",
@@ -393,7 +414,7 @@ static int rk808_probe(struct i2c_client *client,
 				"rockchip,system-power-controller");
 	if (pm_off && !pm_power_off) {
 		rk808_i2c_client = client;
-		pm_power_off = rk808_device_shutdown;
+		pm_power_off = pm_pwroff_fn;
 	}
 
 	return 0;
diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
index 6d435a3..83701ef 100644
--- a/include/linux/mfd/rk808.h
+++ b/include/linux/mfd/rk808.h
@@ -290,6 +290,7 @@ enum rk818_reg {
 #define SWITCH2_EN	BIT(6)
 #define SWITCH1_EN	BIT(5)
 #define DEV_OFF_RST	BIT(3)
+#define DEV_OFF		BIT(0)
 
 #define VB_LO_ACT		BIT(4)
 #define VB_LO_SEL_3500MV	(7 << 0)
-- 
1.9.1




From weiyj.lk at gmail.com  Mon Oct 17 07:57:22 2016
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Mon, 17 Oct 2016 14:57:22 +0000
Subject: [PATCH -next] PCI: rockchip: Add missing of_node_put() in
 rockchip_pcie_init_irq_domain()
Message-ID: <1476716242-31684-1-git-send-email-weiyj.lk@gmail.com>

From: Wei Yongjun <weiyongjun1 at huawei.com>

This node pointer is returned by of_get_next_child() with refcount
incremented in this function. of_node_put() on it before exitting
this function on error.

This is detected by Coccinelle semantic patch.

Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
---
 drivers/pci/host/pcie-rockchip.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index e0b22da..ab88859 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -949,6 +949,7 @@ static int rockchip_pcie_init_irq_domain(struct rockchip_pcie *rockchip)
 						    &intx_domain_ops, rockchip);
 	if (!rockchip->irq_domain) {
 		dev_err(dev, "failed to get a INTx IRQ domain\n");
+		of_node_put(intc);
 		return -EINVAL;
 	}



From weiyj.lk at gmail.com  Mon Oct 17 08:15:18 2016
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Mon, 17 Oct 2016 15:15:18 +0000
Subject: [PATCH -next] ASoC: rk3399_gru_sound: Fix non static symbol warning
Message-ID: <1476717318-12684-1-git-send-email-weiyj.lk@gmail.com>

From: Wei Yongjun <weiyongjun1 at huawei.com>

Fixes the following sparse warning:

sound/soc/rockchip/rk3399_gru_sound.c:41:14: warning:
 symbol 'rt5514_dmic_delay' was not declared. Should it be static?

Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
---
 sound/soc/rockchip/rk3399_gru_sound.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
index 9ed735a..0cbd235 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -38,7 +38,7 @@
 
 #define SOUND_FS	256
 
-unsigned int rt5514_dmic_delay;
+static unsigned int rt5514_dmic_delay;
 
 static struct snd_soc_jack rockchip_sound_jack;



From jh80.chung at samsung.com  Mon Oct 17 17:24:31 2016
From: jh80.chung at samsung.com (Jaehoon Chung)
Date: Tue, 18 Oct 2016 09:24:31 +0900
Subject: [PATCH v2 0/9] Init runtime PM support for dw_mmc
In-Reply-To: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
References: <CGME20161012024453epcas1p1bdc2c6bd18d864b5535bd2b067b491af@epcas1p1.samsung.com>
 <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <488999ee-acf5-47bd-3ebd-707899224749@samsung.com>

Hi Shawn,

On 10/12/2016 11:50 AM, Shawn Lin wrote:
> Hi Jaehoon and Ulf,
> 
>    This patch is gonna support runtime PM for dw_mmc.
> It could support to disable ciu_clk by default and disable
> biu_clk if the devices are non-removeable, or removeable
> with gpio-base card detect.
> 
>    Then I remove the system PM since the runtime PM actually
> does the same thing as it. So I help migrate the dw_mmc variant
> drivers to use runtime PM pairs and pm_runtime_force_*. Note
> that I only enable runtime PM for dw_mmc-rockchip as I will
> leave the decision to the owners of the corresponding drivers.
> I just tested it on my RK3288 platform with linux-next to make
> the runtime PM and system PM work fine for my emmc, sd card and
> sdio. But I don't have hardware to help test other variant drivers.
> But in theory it should work fine as I mentioned that the runtime
> PM does the same thing as system PM except for disabling ciu_clk
> aggressively which should not be related to the variant hosts.
> 
>    As you could see that I just extend the slot-gpio a bit, so the
> ideal way is Ulf could pick them up with Jaehoon's ack. :)

I have tested with my boards..it's working fine..I will apply on this if there is no special issue.

Thanks!

Best Regards,
Jaehoon Chung

> 
> 
> Changes in v2:
> - use struct device as argument for runtime callback
> - use dw_mci_runtime_* directly
> - use dw_mci_runtime_* directly
> - minor fix since I change the argument for dw_mci_runtime_*
> - use dw_mci_runtime_* directly
> - use dw_mci_runtime_* directly
> 
> Shawn Lin (9):
>   mmc: dw_mmc: add runtime PM callback
>   mmc: dw_mmc-rockchip: add runtime PM support
>   mmc: core: expose the capability of gpio card detect
>   mmc: dw_mmc: disable biu clk if possible
>   mmc: dw_mmc-k3: deploy runtime PM facilities
>   mmc: dw_mmc-exynos: deploy runtime PM facilities
>   mmc: dw_mmc-pci: deploy runtime PM facilities
>   mmc: dw_mmc-pltfm: deploy runtime PM facilities
>   mmc: dw_mmc: remove system PM callback
> 
>  drivers/mmc/core/slot-gpio.c       |  8 +++++++
>  drivers/mmc/host/dw_mmc-exynos.c   | 24 +++++++++-----------
>  drivers/mmc/host/dw_mmc-k3.c       | 39 ++++++++------------------------
>  drivers/mmc/host/dw_mmc-pci.c      | 29 ++++++++----------------
>  drivers/mmc/host/dw_mmc-pltfm.c    | 28 +++++++----------------
>  drivers/mmc/host/dw_mmc-rockchip.c | 42 +++++++++++++++++++++++++++++++---
>  drivers/mmc/host/dw_mmc.c          | 46 +++++++++++++++++++++++++-------------
>  drivers/mmc/host/dw_mmc.h          |  6 ++---
>  include/linux/mmc/slot-gpio.h      |  1 +
>  9 files changed, 117 insertions(+), 106 deletions(-)
> 



From shawn.lin at rock-chips.com  Mon Oct 17 17:50:28 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 18 Oct 2016 08:50:28 +0800
Subject: [PATCH -next] PCI: rockchip: Add missing of_node_put() in
 rockchip_pcie_init_irq_domain()
In-Reply-To: <1476716242-31684-1-git-send-email-weiyj.lk@gmail.com>
References: <1476716242-31684-1-git-send-email-weiyj.lk@gmail.com>
Message-ID: <87c39739-c9d0-b307-5256-591ef7324ffa@rock-chips.com>

? 2016/10/17 22:57, Wei Yongjun ??:
> From: Wei Yongjun <weiyongjun1 at huawei.com>
>
> This node pointer is returned by of_get_next_child() with refcount
> incremented in this function. of_node_put() on it before exitting
> this function on error.
>
> This is detected by Coccinelle semantic patch.

Thanks for fixing this.

Acked-by: Shawn Lin <shawn.lin at rock-chips.com>

>
> Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
> ---
>  drivers/pci/host/pcie-rockchip.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index e0b22da..ab88859 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -949,6 +949,7 @@ static int rockchip_pcie_init_irq_domain(struct rockchip_pcie *rockchip)
>  						    &intx_domain_ops, rockchip);
>  	if (!rockchip->irq_domain) {
>  		dev_err(dev, "failed to get a INTx IRQ domain\n");
> +		of_node_put(intc);
>  		return -EINVAL;
>  	}
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Best Regards
Shawn Lin



From shawn.lin at rock-chips.com  Mon Oct 17 18:04:34 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 18 Oct 2016 09:04:34 +0800
Subject: [PATCH v2 0/9] Init runtime PM support for dw_mmc
In-Reply-To: <488999ee-acf5-47bd-3ebd-707899224749@samsung.com>
References: <CGME20161012024453epcas1p1bdc2c6bd18d864b5535bd2b067b491af@epcas1p1.samsung.com>
 <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
 <488999ee-acf5-47bd-3ebd-707899224749@samsung.com>
Message-ID: <d56e8605-1b8d-9791-a742-af1f2fad4995@rock-chips.com>

Hi Jaehoon,

On 2016/10/18 8:24, Jaehoon Chung wrote:
> Hi Shawn,
>
> On 10/12/2016 11:50 AM, Shawn Lin wrote:
>> Hi Jaehoon and Ulf,
>>
>>    This patch is gonna support runtime PM for dw_mmc.
>> It could support to disable ciu_clk by default and disable
>> biu_clk if the devices are non-removeable, or removeable
>> with gpio-base card detect.
>>
>>    Then I remove the system PM since the runtime PM actually
>> does the same thing as it. So I help migrate the dw_mmc variant
>> drivers to use runtime PM pairs and pm_runtime_force_*. Note
>> that I only enable runtime PM for dw_mmc-rockchip as I will
>> leave the decision to the owners of the corresponding drivers.
>> I just tested it on my RK3288 platform with linux-next to make
>> the runtime PM and system PM work fine for my emmc, sd card and
>> sdio. But I don't have hardware to help test other variant drivers.
>> But in theory it should work fine as I mentioned that the runtime
>> PM does the same thing as system PM except for disabling ciu_clk
>> aggressively which should not be related to the variant hosts.
>>
>>    As you could see that I just extend the slot-gpio a bit, so the
>> ideal way is Ulf could pick them up with Jaehoon's ack. :)
>
> I have tested with my boards..it's working fine..I will apply on this if there is no special issue.

Great to hear this. The test for this patchset have been running for a
while on my rk3288/3368 boards and it seems no failures were found
until now.

Thanks!

>
> Thanks!
>
> Best Regards,
> Jaehoon Chung
>
>>
>>
>> Changes in v2:
>> - use struct device as argument for runtime callback
>> - use dw_mci_runtime_* directly
>> - use dw_mci_runtime_* directly
>> - minor fix since I change the argument for dw_mci_runtime_*
>> - use dw_mci_runtime_* directly
>> - use dw_mci_runtime_* directly
>>
>> Shawn Lin (9):
>>   mmc: dw_mmc: add runtime PM callback
>>   mmc: dw_mmc-rockchip: add runtime PM support
>>   mmc: core: expose the capability of gpio card detect
>>   mmc: dw_mmc: disable biu clk if possible
>>   mmc: dw_mmc-k3: deploy runtime PM facilities
>>   mmc: dw_mmc-exynos: deploy runtime PM facilities
>>   mmc: dw_mmc-pci: deploy runtime PM facilities
>>   mmc: dw_mmc-pltfm: deploy runtime PM facilities
>>   mmc: dw_mmc: remove system PM callback
>>
>>  drivers/mmc/core/slot-gpio.c       |  8 +++++++
>>  drivers/mmc/host/dw_mmc-exynos.c   | 24 +++++++++-----------
>>  drivers/mmc/host/dw_mmc-k3.c       | 39 ++++++++------------------------
>>  drivers/mmc/host/dw_mmc-pci.c      | 29 ++++++++----------------
>>  drivers/mmc/host/dw_mmc-pltfm.c    | 28 +++++++----------------
>>  drivers/mmc/host/dw_mmc-rockchip.c | 42 +++++++++++++++++++++++++++++++---
>>  drivers/mmc/host/dw_mmc.c          | 46 +++++++++++++++++++++++++-------------
>>  drivers/mmc/host/dw_mmc.h          |  6 ++---
>>  include/linux/mmc/slot-gpio.h      |  1 +
>>  9 files changed, 117 insertions(+), 106 deletions(-)
>>
>
>
>
>


-- 
Best Regards
Shawn Lin



From shawn.lin at rock-chips.com  Mon Oct 17 18:41:26 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 18 Oct 2016 09:41:26 +0800
Subject: [PATCH v4 1/4] PCI: rockchip: Provide captured slot power limit and
 scale
Message-ID: <1476754889-21804-1-git-send-email-shawn.lin@rock-chips.com>

If vpcie3v3 is available, we could provide these information
via RC's configure register to make EP able to know the power
limit.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v4:
- rebase on next branch

Changes in v3:
- rebase the code since it isn't cleanly applied again.

Changes in v2:
- rebase the code since it isn't cleanly applied after Bjorn's cleanup

 drivers/pci/host/pcie-rockchip.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index e0b22da..3ede865 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -135,6 +135,10 @@
 #define PCIE_RC_CONFIG_VENDOR		(PCIE_RC_CONFIG_BASE + 0x00)
 #define PCIE_RC_CONFIG_RID_CCR		(PCIE_RC_CONFIG_BASE + 0x08)
 #define   PCIE_RC_CONFIG_SCC_SHIFT		16
+#define PCIE_RC_CONFIG_DCR		(PCIE_RC_CONFIG_BASE + 0xc4)
+#define   PCIE_RC_CONFIG_DCR_CSPL_SHIFT		18
+#define   PCIE_RC_CONFIG_DCR_CSPL_LIMIT		0xff
+#define   PCIE_RC_CONFIG_DCR_CPLS_SHIFT		26
 #define PCIE_RC_CONFIG_LCS		(PCIE_RC_CONFIG_BASE + 0xd0)
 #define   PCIE_RC_CONFIG_LCS_RETRAIN_LINK	BIT(5)
 #define   PCIE_RC_CONFIG_LCS_LBMIE		BIT(10)
@@ -395,6 +399,40 @@ static struct pci_ops rockchip_pcie_ops = {
 	.write = rockchip_pcie_wr_conf,
 };
 
+static void rockchip_pcie_set_power_limit(struct rockchip_pcie *rockchip)
+{
+	u32 status, curr, scale, power;
+
+	if (IS_ERR(rockchip->vpcie3v3))
+		return;
+
+	/*
+	 * Set RC's captured slot power limit and scale if
+	 * vpcie3v3 available. The default values are both zero
+	 * which means the software should set these two according
+	 * to the actual power supply.
+	 */
+	curr = regulator_get_current_limit(rockchip->vpcie3v3);
+	if (curr > 0) {
+		scale = 3; /* 0.001x */
+		curr = curr / 1000; /* convert to mA */
+		power = (curr * 3300) / 1000; /* milliwatt */
+		while (power > PCIE_RC_CONFIG_DCR_CSPL_LIMIT) {
+			if (!scale) {
+				dev_warn(rockchip->dev, "invalid power supply\n");
+				return;
+			}
+			scale--;
+			power = power / 10;
+		}
+
+		status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_DCR);
+		status |= (power << PCIE_RC_CONFIG_DCR_CSPL_SHIFT) |
+			  (scale << PCIE_RC_CONFIG_DCR_CPLS_SHIFT);
+		rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_DCR);
+	}
+}
+
 /**
  * rockchip_pcie_init_port - Initialize hardware
  * @rockchip: PCIe port information
@@ -496,6 +534,8 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		 (PCIE_CORE_CTRL_PLC1_FTS_CNT << PCIE_CORE_CTRL_PLC1_FTS_SHIFT);
 	rockchip_pcie_write(rockchip, status, PCIE_CORE_CTRL_PLC1);
 
+	rockchip_pcie_set_power_limit(rockchip);
+
 	/* Enable Gen1 training */
 	rockchip_pcie_write(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
 			    PCIE_CLIENT_CONFIG);
-- 
2.3.7




From shawn.lin at rock-chips.com  Mon Oct 17 18:41:27 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 18 Oct 2016 09:41:27 +0800
Subject: [PATCH v4 2/4] PCI: rockchip: Mark RC as common clock architecture
In-Reply-To: <1476754889-21804-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476754889-21804-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476754889-21804-2-git-send-email-shawn.lin@rock-chips.com>

The default value of common clock configuration is
zero indicating Rockchip's RC is using asynchronous
clock architecture but actually we are using common
clock. This will confuses some EP drivers if they
need some different settings referring to this value.
So let's fix it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v4:
- rebase on the next branch

Changes in v3:
- rebase the code since it isn't cleanly applied again

Changes in v2:
- rebase the code since it isn't cleanly applied after Bjorn's cleanup

 drivers/pci/host/pcie-rockchip.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 3ede865..8e260d2 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -141,6 +141,7 @@
 #define   PCIE_RC_CONFIG_DCR_CPLS_SHIFT		26
 #define PCIE_RC_CONFIG_LCS		(PCIE_RC_CONFIG_BASE + 0xd0)
 #define   PCIE_RC_CONFIG_LCS_RETRAIN_LINK	BIT(5)
+#define   PCIE_RC_CONFIG_LCS_CCC		BIT(6)
 #define   PCIE_RC_CONFIG_LCS_LBMIE		BIT(10)
 #define   PCIE_RC_CONFIG_LCS_LABIE		BIT(11)
 #define   PCIE_RC_CONFIG_LCS_LBMS		BIT(30)
@@ -536,6 +537,11 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 
 	rockchip_pcie_set_power_limit(rockchip);
 
+	/* Set RC's clock architecture as common clock */
+	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
+	status |= PCIE_RC_CONFIG_LCS_CCC;
+	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
+
 	/* Enable Gen1 training */
 	rockchip_pcie_write(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
 			    PCIE_CLIENT_CONFIG);
-- 
2.3.7




From shawn.lin at rock-chips.com  Mon Oct 17 18:41:28 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 18 Oct 2016 09:41:28 +0800
Subject: [PATCH v4 3/4] PCI: rockchip: add COMPILE_TEST for Kconfig
In-Reply-To: <1476754889-21804-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476754889-21804-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476754889-21804-3-git-send-email-shawn.lin@rock-chips.com>

Add this could help build the driver if we enable
CONFIG_COMPILE_TEST.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/pci/host/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d7e7c0a..096440e 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -276,7 +276,7 @@ config PCIE_ARTPEC6
 
 config PCIE_ROCKCHIP
 	bool "Rockchip PCIe controller"
-	depends on ARCH_ROCKCHIP
+	depends on ARCH_ROCKCHIP || COMPILE_TEST
 	depends on OF
 	depends on PCI_MSI_IRQ_DOMAIN
 	select MFD_SYSCON
-- 
2.3.7




From shawn.lin at rock-chips.com  Mon Oct 17 18:41:29 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 18 Oct 2016 09:41:29 +0800
Subject: [PATCH v4 4/4] PCI: rockchip: fix wrong negotiated lanes calculation
In-Reply-To: <1476754889-21804-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476754889-21804-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476754889-21804-4-git-send-email-shawn.lin@rock-chips.com>

The calculation of negotiated lanes is wrong since it should
be shifted by PCIE_CORE_PL_CONF_LANE_SHIFT, but it is shifted
by PCIE_CORE_PL_CONF_LANE_MASK. Let's fix it.

Fixes: commit e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/pci/host/pcie-rockchip.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 8e260d2..279ef17 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -595,8 +595,8 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 
 	/* Check the final link width from negotiated lane counter from MGMT */
 	status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
-	status =  0x1 << ((status & PCIE_CORE_PL_CONF_LANE_MASK) >>
-			  PCIE_CORE_PL_CONF_LANE_MASK);
+	status = 0x1 << ((status & PCIE_CORE_PL_CONF_LANE_MASK) >>
+			  PCIE_CORE_PL_CONF_LANE_SHIFT);
 	dev_dbg(dev, "current link width is x%d\n", status);
 
 	rockchip_pcie_write(rockchip, ROCKCHIP_VENDOR_ID,
-- 
2.3.7




From shawn.lin at rock-chips.com  Mon Oct 17 18:45:08 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 18 Oct 2016 09:45:08 +0800
Subject: [PATCH v8 1/3] Documentation/devicetree: Add new property to specify
 the max link speed
Message-ID: <1476755110-22647-1-git-send-email-shawn.lin@rock-chips.com>

Some of the host drivers have the requirement of knowing whether the
EP would never train at some link speed at all. For instance, on some
boards, the link won't train at 5 GT/s but the host driver still sacrifice
some cycle to wait for the resule of training at 5 GT/s as the host could
actually support 5 GT/s. So we could parse this new property and make the
host drivers be aware of these cases.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/pci/pci.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
index 08dcfad..e7d97a3 100644
--- a/Documentation/devicetree/bindings/pci/pci.txt
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -18,3 +18,9 @@ driver implementation may support the following properties:
    host bridges in the system, otherwise potentially conflicting domain numbers
    may be assigned to root buses behind different host bridges.  The domain
    number for each host bridge in the system must be unique.
+- max-link-speed:
+   If present this property specifies PCI gen for link capability. The host drivers
+   could add this as a strategy to avoid unnecessary operation for unsupported
+   link speed, for instance, trying to do training for unsupported link speed, etc.
+   Must be '4' for gen4, '3' for gen3, '2' for gen2, and '1' for gen1. Any other
+   values are invalid.
-- 
2.3.7




From shawn.lin at rock-chips.com  Mon Oct 17 18:45:09 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 18 Oct 2016 09:45:09 +0800
Subject: [PATCH v8 2/3] of/pci: Add helper function to parse max-link-speed
 from dt
In-Reply-To: <1476755110-22647-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476755110-22647-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476755110-22647-2-git-send-email-shawn.lin@rock-chips.com>

This new helper function could be used by host drivers to
get the limitaion of max link speed provided by dt. If the
property isn't assigned or is invalid, it will return -EINVAL
to the caller.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v8: None
Changes in v7:
- rename the function name and using of_property_read_u32
  suggested by Rob

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/of/of_pci.c    | 21 +++++++++++++++++++++
 include/linux/of_pci.h |  7 +++++++
 2 files changed, 28 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 589b30c..0c566ca 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -120,6 +120,27 @@ int of_get_pci_domain_nr(struct device_node *node)
 EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
 
 /**
+ * This function will try to find the limitation of link speed by finding
+ * a property called "max-link-speed" of the given device node.
+ *
+ * @node: device tree node with the max link speed information
+ *
+ * Returns the associated max link speed from DT, or a negative value if the
+ * required property is not found or is invalid.
+ */
+int of_pci_get_max_link_speed(struct device_node *node)
+{
+	u32 max_link_speed;
+
+	if (of_property_read_u32(node, "max-link-speed", &max_link_speed) ||
+	    max_link_speed > 4)
+		return -EINVAL;
+
+	return max_link_speed;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_max_link_speed);
+
+/**
  * of_pci_check_probe_only - Setup probe only mode if linux,pci-probe-only
  *                           is present and valid
  */
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index b969e94..2e668e3 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -16,6 +16,7 @@ int of_pci_get_devfn(struct device_node *np);
 int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 int of_get_pci_domain_nr(struct device_node *node);
+int of_pci_get_max_link_speed(struct device_node *node);
 void of_pci_check_probe_only(void);
 #else
 static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq)
@@ -52,6 +53,12 @@ of_get_pci_domain_nr(struct device_node *node)
 	return -1;
 }
 
+static inline int
+of_pci_get_max_link_speed(struct device_node *node)
+{
+	return -EINVAL;
+}
+
 static inline void of_pci_check_probe_only(void) { }
 #endif
 
-- 
2.3.7




From shawn.lin at rock-chips.com  Mon Oct 17 18:45:10 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 18 Oct 2016 09:45:10 +0800
Subject: [PATCH v8 3/3] PCI: rockchip: Specify the link capability
In-Reply-To: <1476755110-22647-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476755110-22647-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1476755110-22647-3-git-send-email-shawn.lin@rock-chips.com>

rk3399 supports PCIe 2.x link speeds marginally at best, and on some
boards, the link won't train at 5 GT/s at all. Rather than sacrifice
500ms waiting for training that will never happen, let's use the helper
function, of_pci_get_max_link_speed, to get the max link speed from DT
and specify link capability.

Signed-off-by: Brian Norris <briannorris at chromium.org>
Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

Changes in v8:
- rebase on next branch

Changes in v7:
- rebase on Bjorn's host-rockcip branch again since it isn't applied
  cleanly after the cleanup
- call new function, of_pci_get_max_link_speed.

Changes in v6:
- user helper function of_get_pci_max_link_speed and use gen2 by default
  if finding any errors from of_get_pci_max_link_speed. It could be
  backward compatibe to the old dtb. (Suggested by Rob)

Changes in v5:
- rebase the code since it isn't cleanly applied after Bjorn's cleanup

Changes in v4:
- define link_gen as u32
- elaborate more for rockchip,max-link-speed on doc

Changes in v3:
- Cast a warning for invalid max link speed and use gen1 for it.
  That looks better than v2. (Suggested by Brian)

Changes in v2:
- rename the property to rockchip,max-link-speed according to
  Bjorn's recommendation and take some bits from imx6q-pcie to
  make this requirement more consisent.

 drivers/pci/host/pcie-rockchip.c | 60 +++++++++++++++++++++++++---------------
 1 file changed, 37 insertions(+), 23 deletions(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index e0b22da..1ba676f 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -53,6 +53,7 @@
 #define   PCIE_CLIENT_ARI_ENABLE	  HIWORD_UPDATE_BIT(0x0008)
 #define   PCIE_CLIENT_CONF_LANE_NUM(x)	  HIWORD_UPDATE(0x0030, ENCODE_LANES(x))
 #define   PCIE_CLIENT_MODE_RC		  HIWORD_UPDATE_BIT(0x0040)
+#define   PCIE_CLIENT_GEN_SEL_1		  HIWORD_UPDATE(0x0080, 0)
 #define   PCIE_CLIENT_GEN_SEL_2		  HIWORD_UPDATE_BIT(0x0080)
 #define PCIE_CLIENT_BASIC_STATUS1	(PCIE_CLIENT_BASE + 0x48)
 #define   PCIE_CLIENT_LINK_STATUS_UP		0x00300000
@@ -200,6 +201,7 @@ struct rockchip_pcie {
 	struct	gpio_desc *ep_gpio;
 	u32	lanes;
 	u8	root_bus_nr;
+	int	link_gen;
 	struct	device *dev;
 	struct	irq_domain *irq_domain;
 };
@@ -438,14 +440,20 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		return err;
 	}
 
+	if (rockchip->link_gen == 2)
+		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_2,
+				    PCIE_CLIENT_CONFIG);
+	else
+		rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_1,
+				    PCIE_CLIENT_CONFIG);
+
 	rockchip_pcie_write(rockchip,
 			    PCIE_CLIENT_CONF_ENABLE |
 			    PCIE_CLIENT_LINK_TRAIN_ENABLE |
 			    PCIE_CLIENT_ARI_ENABLE |
 			    PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes) |
-			    PCIE_CLIENT_MODE_RC |
-			    PCIE_CLIENT_GEN_SEL_2,
-				PCIE_CLIENT_CONFIG);
+			    PCIE_CLIENT_MODE_RC,
+			    PCIE_CLIENT_CONFIG);
 
 	err = phy_power_on(rockchip->phy);
 	if (err) {
@@ -522,29 +530,31 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		msleep(20);
 	}
 
-	/*
-	 * Enable retrain for gen2. This should be configured only after
-	 * gen1 finished.
-	 */
-	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
-	status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
-	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
+	if (rockchip->link_gen == 2) {
+		/*
+		 * Enable retrain for gen2. This should be configured only after
+		 * gen1 finished.
+		 */
+		status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LCS);
+		status |= PCIE_RC_CONFIG_LCS_RETRAIN_LINK;
+		rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LCS);
+
+		timeout = jiffies + msecs_to_jiffies(500);
+		for (;;) {
+			status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
+			if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
+			    PCIE_CORE_PL_CONF_SPEED_5G) {
+				dev_dbg(dev, "PCIe link training gen2 pass!\n");
+				break;
+			}
 
-	timeout = jiffies + msecs_to_jiffies(500);
-	for (;;) {
-		status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
-		if ((status & PCIE_CORE_PL_CONF_SPEED_MASK) ==
-		    PCIE_CORE_PL_CONF_SPEED_5G) {
-			dev_dbg(dev, "PCIe link training gen2 pass!\n");
-			break;
-		}
+			if (time_after(jiffies, timeout)) {
+				dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
+				break;
+			}
 
-		if (time_after(jiffies, timeout)) {
-			dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
-			break;
+			msleep(20);
 		}
-
-		msleep(20);
 	}
 
 	/* Check the final link width from negotiated lane counter from MGMT */
@@ -753,6 +763,10 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
 		rockchip->lanes = 1;
 	}
 
+	rockchip->link_gen = of_pci_get_max_link_speed(node);
+	if (rockchip->link_gen < 0 || rockchip->link_gen > 2)
+		rockchip->link_gen = 2;
+
 	rockchip->core_rst = devm_reset_control_get(dev, "core");
 	if (IS_ERR(rockchip->core_rst)) {
 		if (PTR_ERR(rockchip->core_rst) != -EPROBE_DEFER)
-- 
2.3.7




From daryl.emerson at hoodlumhounds.com  Mon Oct 17 20:05:08 2016
From: daryl.emerson at hoodlumhounds.com (FedEx 2Day A.M.)
Date: Tue, 18 Oct 2016 03:05:08 +0000
Subject: ROCK, Problems with item delivery, n.00900686
Message-ID: <a9c6249eb0e34ed560f731c7deea4089@hoodlumhounds.com>

Dear Rock,

Courier was unable to deliver the parcel to you.
Please, download Delivery Label attached to this email.

Sincerely,
Daryl Emerson,
FedEx Operation Agent.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Delivery_Notification_00900686.zip
Type: application/zip
Size: 8554 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20161018/71a9ee19/attachment-0001.zip>

From wzz at rock-chips.com  Mon Oct 17 23:14:37 2016
From: wzz at rock-chips.com (Zain Wang)
Date: Tue, 18 Oct 2016 14:14:37 +0800
Subject: [PATCH v3 0/6] Misc changes to Rockchip PSR drivers
Message-ID: <1476771283-11398-1-git-send-email-wzz@rock-chips.com>

This serise of patches works for saving power on eDP PHY and VOP during PSR.

BR,
- Zain

Changes in v3:
- add new patch to support fast link training.
- add new patch to make VOP standby when entry PSR.
- Misc changes.

Changes in v2:
- add spin_lock to protect dpms_mode
- misc changes.

Yakir Yang (1):
  drm/bridge: analogix_dp: detect Sink PSR state after configuring the
    PSR

zain wang (5):
  drm/bridge: analogix_dp: set psr activate/deactivate when
    enable/disable bridge
  drm/bridge: remove dp init from analogix_dp_bind
  drm: bridge/analogix: switch Main-link and eDP PHY when enable/disable
    psr
  drm: bridge/analogix: add fast link train for eDP
  drm: bridge/analogix: enable vop standby when entry PSR

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 218 +++++++++++++++------
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   7 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  25 ++-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c    |  33 +++-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h        |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c        |  30 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h        |   4 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c        |  23 ++-
 8 files changed, 259 insertions(+), 82 deletions(-)

-- 
1.9.1




From wzz at rock-chips.com  Mon Oct 17 23:14:38 2016
From: wzz at rock-chips.com (Zain Wang)
Date: Tue, 18 Oct 2016 14:14:38 +0800
Subject: [PATCH v3 1/6] drm/bridge: analogix_dp: set psr activate/deactivate
 when enable/disable bridge
In-Reply-To: <1476771283-11398-1-git-send-email-wzz@rock-chips.com>
References: <1476771283-11398-1-git-send-email-wzz@rock-chips.com>
Message-ID: <1476771283-11398-2-git-send-email-wzz@rock-chips.com>

From: zain wang <wzz at rock-chips.com>

There's a race between when bridge_disable and when vop_crtc_disable are called.
If the flush timer triggers a new psr work between these, we will operate eDP
without power shutdowned by bridge_disable.
In this case, moving activate/deactivate to enable/disable bridge to avoid it.

Signed-off-by: zain wang <wzz at rock-chips.com>
---

Changes in v3:
- remove changes before.
- move psr activat/deactivate to enable/disable bridge.

Changes in v2:
- add spin_lock to protect dpms_mode


 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |  4 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c     | 30 ++++++++++++++++++++-----
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h     |  4 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c     |  4 ----
 4 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8548e82..e5471e7 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -159,7 +159,7 @@ static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
 		return ret;
 	}
 
-	return 0;
+	return rockchip_drm_psr_activate(&dp->encoder);
 }
 
 static int rockchip_dp_powerdown(struct analogix_dp_plat_data *plat_data)
@@ -168,7 +168,7 @@ static int rockchip_dp_powerdown(struct analogix_dp_plat_data *plat_data)
 
 	clk_disable_unprepare(dp->pclk);
 
-	return 0;
+	return rockchip_drm_psr_deactivate(&dp->encoder);
 }
 
 static int rockchip_dp_get_modes(struct analogix_dp_plat_data *plat_data,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index a553e18..4c379e9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -57,6 +57,24 @@ out:
 	return psr;
 }
 
+static struct psr_drv *find_psr_by_encoder(struct drm_encoder *encoder)
+{
+	struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
+	struct psr_drv *psr;
+	unsigned long flags;
+
+	spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
+	list_for_each_entry(psr, &drm_drv->psr_list, list) {
+		if (psr->encoder == encoder)
+			goto out;
+	}
+	psr = ERR_PTR(-ENODEV);
+
+out:
+	spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
+	return psr;
+}
+
 static void psr_set_state_locked(struct psr_drv *psr, enum psr_state state)
 {
 	/*
@@ -115,14 +133,14 @@ static void psr_flush_handler(unsigned long data)
 
 /**
  * rockchip_drm_psr_activate - activate PSR on the given pipe
- * @crtc: CRTC to obtain the PSR encoder
+ * @encoder: encoder to obtain the PSR encoder
  *
  * Returns:
  * Zero on success, negative errno on failure.
  */
-int rockchip_drm_psr_activate(struct drm_crtc *crtc)
+int rockchip_drm_psr_activate(struct drm_encoder *encoder)
 {
-	struct psr_drv *psr = find_psr_by_crtc(crtc);
+	struct psr_drv *psr = find_psr_by_encoder(encoder);
 	unsigned long flags;
 
 	if (IS_ERR(psr))
@@ -138,14 +156,14 @@ EXPORT_SYMBOL(rockchip_drm_psr_activate);
 
 /**
  * rockchip_drm_psr_deactivate - deactivate PSR on the given pipe
- * @crtc: CRTC to obtain the PSR encoder
+ * @encoder: encoder to obtain the PSR encoder
  *
  * Returns:
  * Zero on success, negative errno on failure.
  */
-int rockchip_drm_psr_deactivate(struct drm_crtc *crtc)
+int rockchip_drm_psr_deactivate(struct drm_encoder *encoder)
 {
-	struct psr_drv *psr = find_psr_by_crtc(crtc);
+	struct psr_drv *psr = find_psr_by_encoder(encoder);
 	unsigned long flags;
 
 	if (IS_ERR(psr))
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
index b420cf1..b1ea015 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
@@ -18,8 +18,8 @@
 void rockchip_drm_psr_flush_all(struct drm_device *dev);
 int rockchip_drm_psr_flush(struct drm_crtc *crtc);
 
-int rockchip_drm_psr_activate(struct drm_crtc *crtc);
-int rockchip_drm_psr_deactivate(struct drm_crtc *crtc);
+int rockchip_drm_psr_activate(struct drm_encoder *encoder);
+int rockchip_drm_psr_deactivate(struct drm_encoder *encoder);
 
 int rockchip_drm_psr_register(struct drm_encoder *encoder,
 			void (*psr_set)(struct drm_encoder *, bool enable));
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c7eba30..1740a0b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -566,8 +566,6 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
 
 	WARN_ON(vop->event);
 
-	rockchip_drm_psr_deactivate(&vop->crtc);
-
 	/*
 	 * We need to make sure that all windows are disabled before we
 	 * disable that crtc. Otherwise we might try to scan from a destroyed
@@ -975,8 +973,6 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
 	clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
 
 	VOP_CTRL_SET(vop, standby, 0);
-
-	rockchip_drm_psr_activate(&vop->crtc);
 }
 
 static bool vop_fs_irq_is_pending(struct vop *vop)
-- 
1.9.1




From wzz at rock-chips.com  Mon Oct 17 23:14:39 2016
From: wzz at rock-chips.com (Zain Wang)
Date: Tue, 18 Oct 2016 14:14:39 +0800
Subject: [PATCH v3 2/6] drm/bridge: remove dp init from analogix_dp_bind
In-Reply-To: <1476771283-11398-1-git-send-email-wzz@rock-chips.com>
References: <1476771283-11398-1-git-send-email-wzz@rock-chips.com>
Message-ID: <1476771283-11398-3-git-send-email-wzz@rock-chips.com>

From: zain wang <wzz at rock-chips.com>

phy_power_on() and analogix_dp_init_dp would be called in bridge_eanble,
so remove them from analogix_dp_bind to be clear.

Signed-off-by: zain wang <wzz at rock-chips.com>
---

Changes in v3:
- remove changes before
- remove phy_power_on() and analogix_dp_init_dp from analogix_dp_bind().

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 001b075..bcae4dd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1389,10 +1389,6 @@ int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
 
 	pm_runtime_enable(dev);
 
-	phy_power_on(dp->phy);
-
-	analogix_dp_init_dp(dp);
-
 	ret = devm_request_threaded_irq(&pdev->dev, dp->irq,
 					analogix_dp_hardirq,
 					analogix_dp_irq_thread,
-- 
1.9.1




From wzz at rock-chips.com  Mon Oct 17 23:21:37 2016
From: wzz at rock-chips.com (Zain Wang)
Date: Tue, 18 Oct 2016 14:21:37 +0800
Subject: [PATCH v3 3/6] drm/bridge: analogix_dp: detect Sink PSR state after
 configuring the PSR
Message-ID: <1476771697-11895-1-git-send-email-wzz@rock-chips.com>

From: Yakir Yang <ykk at rock-chips.com>

Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
function, or print the sink PSR error state if we failed to apply the
requested PSR setting.

Signed-off-by: zain wang <wzz at rock-chips.com>
Signed-off-by: Yakir Yang <ykk at rock-chips.com>
---

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 ++----
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  6 ++++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 25 ++++++++++++++++++++--
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c    |  6 ++++--
 4 files changed, 33 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index bcae4dd..7faad93 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -124,8 +124,7 @@ int analogix_dp_enable_psr(struct device *dev)
 	psr_vsc.DB0 = 0;
 	psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
 
-	analogix_dp_send_psr_spd(dp, &psr_vsc);
-	return 0;
+	return analogix_dp_send_psr_spd(dp, &psr_vsc);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
 
@@ -147,8 +146,7 @@ int analogix_dp_disable_psr(struct device *dev)
 	psr_vsc.DB0 = 0;
 	psr_vsc.DB1 = 0;
 
-	analogix_dp_send_psr_spd(dp, &psr_vsc);
-	return 0;
+	return analogix_dp_send_psr_spd(dp, &psr_vsc);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 5c6a288..cdc0535 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,8 @@
 #define MAX_CR_LOOP 5
 #define MAX_EQ_LOOP 5
 
+#define DP_TIMEOUT_PSR_LOOP_MS			msecs_to_jiffies(300)
+
 /* DP_MAX_LANE_COUNT */
 #define DPCD_ENHANCED_FRAME_CAP(x)		(((x) >> 7) & 0x1)
 #define DPCD_MAX_LANE_COUNT(x)			((x) & 0x1f)
@@ -247,8 +249,8 @@ void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp);
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-			      struct edp_vsc_psr *vsc);
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+			     struct edp_vsc_psr *vsc);
 ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
 			     struct drm_dp_aux_msg *msg);
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index cd37ac0..9e1177c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -992,10 +992,12 @@ void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp)
 	writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
 }
 
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-			      struct edp_vsc_psr *vsc)
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+			     struct edp_vsc_psr *vsc)
 {
+	unsigned long timeout;
 	unsigned int val;
+	u8 sink;
 
 	/* don't send info frame */
 	val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
@@ -1036,6 +1038,25 @@ void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
 	val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
 	val |= IF_EN;
 	writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
+
+	timeout = jiffies + DP_TIMEOUT_PSR_LOOP_MS;
+	while (time_before(jiffies, timeout)) {
+		val = drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, &sink);
+		if (val != 1) {
+			dev_err(dp->dev, "PSR_STATUS read failed ret=%d", val);
+			return -EBUSY;
+		}
+
+		if ((vsc->DB1 && sink == DP_PSR_SINK_ACTIVE_RFB) ||
+		    (!vsc->DB1 && sink == DP_PSR_SINK_INACTIVE))
+			return 0;
+
+		usleep_range(1000, 1500);
+	}
+
+	dev_warn(dp->dev, "Failed to apply PSR, sink state was [%x]", sink);
+
+	return -ETIMEDOUT;
 }
 
 ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index e5471e7..1c2d756 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -105,7 +105,7 @@ static void analogix_dp_psr_work(struct work_struct *work)
 	struct rockchip_dp_device *dp =
 				container_of(work, typeof(*dp), psr_work);
 	struct drm_crtc *crtc = dp->encoder.crtc;
-	int psr_state = dp->psr_state;
+	int psr_state;
 	int vact_end;
 	int ret;
 	unsigned long flags;
@@ -123,11 +123,13 @@ static void analogix_dp_psr_work(struct work_struct *work)
 	}
 
 	spin_lock_irqsave(&dp->psr_lock, flags);
+	psr_state = dp->psr_state;
+	spin_unlock_irqrestore(&dp->psr_lock, flags);
+
 	if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
 		analogix_dp_enable_psr(dp->dev);
 	else
 		analogix_dp_disable_psr(dp->dev);
-	spin_unlock_irqrestore(&dp->psr_lock, flags);
 }
 
 static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
-- 
1.9.1




From wzz at rock-chips.com  Mon Oct 17 23:21:59 2016
From: wzz at rock-chips.com (Zain Wang)
Date: Tue, 18 Oct 2016 14:21:59 +0800
Subject: [PATCH v3 4/6] drm: bridge/analogix: switch Main-link and eDP PHY
 when enable/disable psr
Message-ID: <1476771719-11941-1-git-send-email-wzz@rock-chips.com>

From: zain wang <wzz at rock-chips.com>

turn off Main-link and power down eDP PHY when enable psr,
turn on Main-link and power up eDP PHY when disable psr.

Signed-off-by: zain wang <wzz at rock-chips.com>
---

Changes in v3:
- detecting PSR state at enable/disable_psr() avoid to make link training
  when sink in not PSR State.

Changes in v2:
- misc changes

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 123 +++++++++++++--------
 1 file changed, 76 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index c4f139a..c662e5d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -98,50 +98,6 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device *dp)
 	return 0;
 }
 
-int analogix_dp_enable_psr(struct device *dev)
-{
-	struct analogix_dp_device *dp = dev_get_drvdata(dev);
-	struct edp_vsc_psr psr_vsc;
-
-	if (!dp->psr_support)
-		return -EINVAL;
-
-	/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
-	memset(&psr_vsc, 0, sizeof(psr_vsc));
-	psr_vsc.sdp_header.HB0 = 0;
-	psr_vsc.sdp_header.HB1 = 0x7;
-	psr_vsc.sdp_header.HB2 = 0x2;
-	psr_vsc.sdp_header.HB3 = 0x8;
-
-	psr_vsc.DB0 = 0;
-	psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
-
-	return analogix_dp_send_psr_spd(dp, &psr_vsc);
-}
-EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
-
-int analogix_dp_disable_psr(struct device *dev)
-{
-	struct analogix_dp_device *dp = dev_get_drvdata(dev);
-	struct edp_vsc_psr psr_vsc;
-
-	if (!dp->psr_support)
-		return -EINVAL;
-
-	/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
-	memset(&psr_vsc, 0, sizeof(psr_vsc));
-	psr_vsc.sdp_header.HB0 = 0;
-	psr_vsc.sdp_header.HB1 = 0x7;
-	psr_vsc.sdp_header.HB2 = 0x2;
-	psr_vsc.sdp_header.HB3 = 0x8;
-
-	psr_vsc.DB0 = 0;
-	psr_vsc.DB1 = 0;
-
-	return analogix_dp_send_psr_spd(dp, &psr_vsc);
-}
-EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
-
 static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
 {
 	unsigned char psr_version;
@@ -162,12 +118,11 @@ static void analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
 	drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
 
 	/* Main-Link transmitter remains active during PSR active states */
-	psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
+	psr_en = DP_PSR_CRC_VERIFICATION;
 	drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
 
 	/* Enable psr function */
-	psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
-		 DP_PSR_CRC_VERIFICATION;
+	psr_en = DP_PSR_ENABLE | DP_PSR_CRC_VERIFICATION;
 	drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
 
 	analogix_dp_enable_psr_crc(dp);
@@ -870,6 +825,80 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
 		analogix_dp_enable_sink_psr(dp);
 }
 
+int analogix_dp_enable_psr(struct device *dev)
+{
+	struct analogix_dp_device *dp = dev_get_drvdata(dev);
+	struct edp_vsc_psr psr_vsc;
+	int retval;
+	u8 sink;
+
+	if (!dp->psr_support)
+		return -EINVAL;
+
+	drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, &sink);
+	if (sink == DP_PSR_SINK_ACTIVE_RFB)
+		return 0;
+
+	/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
+	memset(&psr_vsc, 0, sizeof(psr_vsc));
+	psr_vsc.sdp_header.HB0 = 0;
+	psr_vsc.sdp_header.HB1 = 0x7;
+	psr_vsc.sdp_header.HB2 = 0x2;
+	psr_vsc.sdp_header.HB3 = 0x8;
+
+	psr_vsc.DB0 = 0;
+	psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
+
+	retval = analogix_dp_send_psr_spd(dp, &psr_vsc);
+
+	if (!retval) {
+		/* Power down the eDP PHY */
+		analogix_dp_set_analog_power_down(dp, POWER_ALL, true);
+	}
+
+	return retval;
+}
+EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
+
+int analogix_dp_disable_psr(struct device *dev)
+{
+	struct analogix_dp_device *dp = dev_get_drvdata(dev);
+	struct edp_vsc_psr psr_vsc;
+	int ret;
+	u8 sink;
+
+	if (!dp->psr_support)
+		return -EINVAL;
+
+	/* Power up the eDP PHY */
+	analogix_dp_set_analog_power_down(dp, POWER_ALL, false);
+
+	drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, &sink);
+	if (sink == DP_PSR_SINK_INACTIVE)
+		return 0;
+
+	ret = drm_dp_dpcd_writeb(&dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
+	if (ret < 0) {
+		dev_err(dp->dev, "Failed to set DP Power0\n");
+	}
+
+	analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
+				   dp->video_info.max_link_rate);
+
+	/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
+	memset(&psr_vsc, 0, sizeof(psr_vsc));
+	psr_vsc.sdp_header.HB0 = 0;
+	psr_vsc.sdp_header.HB1 = 0x7;
+	psr_vsc.sdp_header.HB2 = 0x2;
+	psr_vsc.sdp_header.HB3 = 0x8;
+
+	psr_vsc.DB0 = 0;
+	psr_vsc.DB1 = 0;
+
+	return analogix_dp_send_psr_spd(dp, &psr_vsc);
+}
+EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
+
 /*
  * This function is a bit of a catch-all for panel preparation, hopefully
  * simplifying the logic of functions that need to prepare/unprepare the panel
-- 
1.9.1




From wzz at rock-chips.com  Mon Oct 17 23:22:21 2016
From: wzz at rock-chips.com (Zain Wang)
Date: Tue, 18 Oct 2016 14:22:21 +0800
Subject: [PATCH  v3 5/6] drm: bridge/analogix: add fast link train for eDP
Message-ID: <1476771741-11997-1-git-send-email-wzz@rock-chips.com>

From: zain wang <wzz at rock-chips.com>

we would meet a short black screen when exit PSR with the full link
training, In this case, we should use fast link train instead of full
link training.

Signed-off-by: zain wang <wzz at rock-chips.com>
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 89 +++++++++++++++++++++-
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  1 +
 2 files changed, 86 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 561b644..0516621 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -21,6 +21,7 @@
 #include <linux/gpio.h>
 #include <linux/component.h>
 #include <linux/phy/phy.h>
+#include <linux/iopoll.h>
 
 #include <drm/drmP.h>
 #include <drm/drm_atomic_helper.h>
@@ -35,6 +36,8 @@
 
 #define to_dp(nm)	container_of(nm, struct analogix_dp_device, nm)
 
+static const int FAST_LINK_VERIFICATION = false;
+
 struct bridge_init {
 	struct i2c_client *client;
 	struct device_node *node;
@@ -244,6 +247,7 @@ static int analogix_dp_link_start(struct analogix_dp_device *dp)
 		usleep_range(90, 120);
 	}
 
+
 	/* Set training pattern 1 */
 	analogix_dp_set_training_pattern(dp, TRAINING_PTN1);
 
@@ -481,7 +485,7 @@ static int analogix_dp_process_equalizer_training(struct analogix_dp_device *dp)
 {
 	int lane, lane_count, retval;
 	u32 reg;
-	u8 link_align, link_status[2], adjust_request[2];
+	u8 link_align, link_status[2], adjust_request[2], spread;
 
 	usleep_range(400, 401);
 
@@ -524,6 +528,12 @@ static int analogix_dp_process_equalizer_training(struct analogix_dp_device *dp)
 		dev_dbg(dp->dev, "final lane count = %.2x\n",
 			dp->link_train.lane_count);
 
+		drm_dp_dpcd_readb(&dp->aux, DP_MAX_DOWNSPREAD, &spread);
+		dp->fast_train_support = (spread &
+			DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ? true : false;
+		dev_dbg(dp->dev, "fast link training %s\n",
+			dp->fast_train_support ? "supported" : "unsupported");
+
 		/* set enhanced mode if available */
 		analogix_dp_set_enhanced_mode(dp);
 		dp->link_train.lt_state = FINISHED;
@@ -655,6 +665,75 @@ static int analogix_dp_sw_link_training(struct analogix_dp_device *dp)
 	return retval;
 }
 
+static int analogix_dp_full_link_train(struct analogix_dp_device *dp,
+					    u32 count, u32 bwtype)
+{
+	analogix_dp_init_training(dp, count, bwtype);
+	return analogix_dp_sw_link_training(dp);
+}
+
+static int analogix_dp_fast_link_train(struct analogix_dp_device *dp)
+{
+	int lane;
+	int retval;
+	u8 link_align, link_status[2];
+	enum pll_status status;
+
+	analogix_dp_reset_macro(dp);
+
+	analogix_dp_set_link_bandwidth(dp, dp->link_train.link_rate);
+	analogix_dp_set_lane_count(dp, dp->link_train.lane_count);
+
+	for (lane = 0; lane < dp->link_train.lane_count; lane++) {
+		analogix_dp_set_lane_link_training(dp,
+			dp->link_train.training_lane[lane], lane);
+	}
+
+	retval = readx_poll_timeout(analogix_dp_get_pll_lock_status, dp, status,
+				    status != PLL_UNLOCKED,
+				    120, 120 * DP_TIMEOUT_LOOP_COUNT);
+
+	if (retval)
+		return retval;
+
+	/* source Set training pattern 1 */
+	analogix_dp_set_training_pattern(dp, TRAINING_PTN1);
+	usleep_range(500, 600);
+
+	analogix_dp_set_training_pattern(dp, TRAINING_PTN2);
+	usleep_range(500, 600);
+
+	/* TODO: enhanced_mode?*/
+	analogix_dp_set_training_pattern(dp, DP_NONE);
+
+	if (FAST_LINK_VERIFICATION) {
+		retval = drm_dp_dpcd_readb(&dp->aux,
+					   DP_LANE_ALIGN_STATUS_UPDATED,
+					   &link_align);
+		if (retval < 0)
+			return retval;
+
+		retval = drm_dp_dpcd_read(&dp->aux, DP_LANE0_1_STATUS,
+					  link_status, 2);
+		if (retval < 0)
+			return retval;
+
+		if (analogix_dp_clock_recovery_ok(link_status,
+						  dp->link_train.lane_count)) {
+			analogix_dp_reduce_link_rate(dp);
+			return -EIO;
+		}
+
+		if (analogix_dp_channel_eq_ok(link_status, link_align,
+					      dp->link_train.lane_count)) {
+			analogix_dp_reduce_link_rate(dp);
+			return -EIO;
+		}
+	}
+
+	return 0;
+}
+
 static int analogix_dp_set_link_train(struct analogix_dp_device *dp,
 				      u32 count, u32 bwtype)
 {
@@ -662,11 +741,13 @@ static int analogix_dp_set_link_train(struct analogix_dp_device *dp,
 	int retval;
 
 	for (i = 0; i < DP_TIMEOUT_LOOP_COUNT; i++) {
-		analogix_dp_init_training(dp, count, bwtype);
-		retval = analogix_dp_sw_link_training(dp);
+		if (dp->fast_train_support)
+			retval = analogix_dp_fast_link_train(dp);
+		else
+			retval = analogix_dp_full_link_train(dp, count,
+								  bwtype);
 		if (retval == 0)
 			break;
-
 		usleep_range(100, 110);
 	}
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index cdc0535..b86039b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -171,6 +171,7 @@ struct analogix_dp_device {
 	int			hpd_gpio;
 	bool                    force_hpd;
 	bool			psr_support;
+	bool			fast_train_support;
 
 	struct mutex		panel_lock;
 	bool			panel_is_modeset;
-- 
1.9.1




From wzz at rock-chips.com  Mon Oct 17 23:22:36 2016
From: wzz at rock-chips.com (Zain Wang)
Date: Tue, 18 Oct 2016 14:22:36 +0800
Subject: [PATCH 6/6] drm: bridge/analogix: enable vop standby when entry PSR
Message-ID: <1476771756-12045-1-git-send-email-wzz@rock-chips.com>

From: zain wang <wzz at rock-chips.com>

make VOP standby when entry PSR to save some power.

Signed-off-by: zain wang <wzz at rock-chips.com>
---
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 29 ++++++++++++++++++-------
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h     |  1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c     | 19 ++++++++++++++++
 3 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 1c2d756..e0f3ed3 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -113,6 +113,13 @@ static void analogix_dp_psr_work(struct work_struct *work)
 	if (!crtc)
 		return;
 
+	spin_lock_irqsave(&dp->psr_lock, flags);
+	psr_state = dp->psr_state;
+	spin_unlock_irqrestore(&dp->psr_lock, flags);
+
+	if (psr_state != EDP_VSC_PSR_STATE_ACTIVE)
+		rockchip_drm_vop_set_standby(crtc, false);
+
 	vact_end = crtc->mode.vtotal - crtc->mode.vsync_start + crtc->mode.vdisplay;
 
 	ret = rockchip_drm_wait_line_flag(dp->encoder.crtc, vact_end,
@@ -122,14 +129,20 @@ static void analogix_dp_psr_work(struct work_struct *work)
 		return;
 	}
 
-	spin_lock_irqsave(&dp->psr_lock, flags);
-	psr_state = dp->psr_state;
-	spin_unlock_irqrestore(&dp->psr_lock, flags);
-
-	if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
-		analogix_dp_enable_psr(dp->dev);
-	else
-		analogix_dp_disable_psr(dp->dev);
+	if (psr_state == EDP_VSC_PSR_STATE_ACTIVE) {
+		ret = analogix_dp_enable_psr(dp->dev);
+		if (ret) {
+			dev_err(dp->dev, "failed to enable psr\n");
+			return;
+		}
+		rockchip_drm_vop_set_standby(crtc, true);
+	} else {
+		ret = analogix_dp_disable_psr(dp->dev);
+		if (ret) {
+			dev_err(dp->dev, "failed to disable psr\n");
+			return;
+		}
+	}
 }
 
 static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index fb6226c..7149c69 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -74,5 +74,6 @@ void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
 				    struct device *dev);
 int rockchip_drm_wait_line_flag(struct drm_crtc *crtc, unsigned int line_num,
 				unsigned int mstimeout);
+void rockchip_drm_vop_set_standby(struct drm_crtc *crtc, bool enabled);
 
 #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 1740a0b..13eabda 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1478,6 +1478,25 @@ int rockchip_drm_wait_line_flag(struct drm_crtc *crtc, unsigned int line_num,
 }
 EXPORT_SYMBOL(rockchip_drm_wait_line_flag);
 
+void rockchip_drm_vop_set_standby(struct drm_crtc *crtc, bool enabled)
+{
+	struct vop *vop = to_vop(crtc);
+
+	if (!crtc || !vop->is_enabled)
+		return;
+
+	spin_lock(&vop->reg_lock);
+
+	if (enabled)
+		VOP_CTRL_SET(vop, standby, 1);
+	else
+		VOP_CTRL_SET(vop, standby, 0);
+
+	spin_unlock(&vop->reg_lock);
+
+}
+EXPORT_SYMBOL(rockchip_drm_vop_set_standby);
+
 static int vop_bind(struct device *dev, struct device *master, void *data)
 {
 	struct platform_device *pdev = to_platform_device(dev);
-- 
1.9.1




From ulf.hansson at linaro.org  Tue Oct 18 01:46:12 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 18 Oct 2016 10:46:12 +0200
Subject: [PATCH v2 0/9] Init runtime PM support for dw_mmc
In-Reply-To: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <CAPDyKFopNgWh=+0RNFwJc+aaFPXGuJMAac5rPtfOawvLwSbN+g@mail.gmail.com>

+ Heiko

On 12 October 2016 at 04:50, Shawn Lin <shawn.lin at rock-chips.com> wrote:
>
> Hi Jaehoon and Ulf,
>
>    This patch is gonna support runtime PM for dw_mmc.
> It could support to disable ciu_clk by default and disable
> biu_clk if the devices are non-removeable, or removeable
> with gpio-base card detect.
>
>    Then I remove the system PM since the runtime PM actually
> does the same thing as it. So I help migrate the dw_mmc variant
> drivers to use runtime PM pairs and pm_runtime_force_*. Note
> that I only enable runtime PM for dw_mmc-rockchip as I will
> leave the decision to the owners of the corresponding drivers.
> I just tested it on my RK3288 platform with linux-next to make
> the runtime PM and system PM work fine for my emmc, sd card and
> sdio. But I don't have hardware to help test other variant drivers.
> But in theory it should work fine as I mentioned that the runtime
> PM does the same thing as system PM except for disabling ciu_clk
> aggressively which should not be related to the variant hosts.
>
>    As you could see that I just extend the slot-gpio a bit, so the
> ideal way is Ulf could pick them up with Jaehoon's ack. :)

The mmc core change looks fine to me, so I will wait for a pull
request from Jaehoon.

>
>
> Changes in v2:
> - use struct device as argument for runtime callback
> - use dw_mci_runtime_* directly
> - use dw_mci_runtime_* directly
> - minor fix since I change the argument for dw_mci_runtime_*
> - use dw_mci_runtime_* directly
> - use dw_mci_runtime_* directly
>
> Shawn Lin (9):
>   mmc: dw_mmc: add runtime PM callback
>   mmc: dw_mmc-rockchip: add runtime PM support
>   mmc: core: expose the capability of gpio card detect
>   mmc: dw_mmc: disable biu clk if possible
>   mmc: dw_mmc-k3: deploy runtime PM facilities
>   mmc: dw_mmc-exynos: deploy runtime PM facilities
>   mmc: dw_mmc-pci: deploy runtime PM facilities
>   mmc: dw_mmc-pltfm: deploy runtime PM facilities
>   mmc: dw_mmc: remove system PM callback
>
>  drivers/mmc/core/slot-gpio.c       |  8 +++++++
>  drivers/mmc/host/dw_mmc-exynos.c   | 24 +++++++++-----------
>  drivers/mmc/host/dw_mmc-k3.c       | 39 ++++++++------------------------
>  drivers/mmc/host/dw_mmc-pci.c      | 29 ++++++++----------------
>  drivers/mmc/host/dw_mmc-pltfm.c    | 28 +++++++----------------
>  drivers/mmc/host/dw_mmc-rockchip.c | 42 +++++++++++++++++++++++++++++++---
>  drivers/mmc/host/dw_mmc.c          | 46 +++++++++++++++++++++++++-------------
>  drivers/mmc/host/dw_mmc.h          |  6 ++---
>  include/linux/mmc/slot-gpio.h      |  1 +
>  9 files changed, 117 insertions(+), 106 deletions(-)
>

Overall these changes looks good to me, so I am ready to accept the PR
from Jaehoon!!


Although, highly related to this patchset, I am worried that there is
a misunderstanding on how MMC_PM_KEEP_POWER (DT binding
"keep-power-in-suspend") is being used for dw_mmc. Perhaps I am wrong,
but I would appreciate if you could elaborate a bit for my
understanding.

First, this cap is solely intended to be used for controllers which
may have SDIO cards attached, as it indicates those cards may be
configured to be powered on while the system enters suspend state. By
looking at some DTS files, for example
arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts which uses it
for an eMMC slot, this is clearly being abused.

Anyway, the wrong DT configurations might not be a big deal, as in
dw_mci_resume(), it's not the capabilities bit that is checked but the
corresponding "pm_flag". This flag is set via calling
sdio_set_host_pm_flags(), but as that doesn't happen for an eMMC card
we should be fine, right!?

Now, what also do puzzles me, is exactly that piece of code in
dw_mci_resume() that is being executed *when* the pm_flag contains
MMC_PM_KEEP_POWER:
if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
     dw_mci_set_ios(slot->mmc, &slot->mmc->ios);
     dw_mci_setup_bus(slot, true);
}

So, in the system resume path, the above do makes sense as you need to
restore the registers etc for the dw_mmc controller to enable it to
operate the SDIO card. Such as bus width, clocks, etc.

Although, I would expect something similar would be needed in the new
runtime resume path as well. And in particular also for eMMC/SD cards,
as you need to restore the dw_mmc registers to be able to operate the
card again. Don't you?

So in the end, perhaps you should *always* call dw_mci_set_ios() and
dw_mci_setup_bus() in dw_mci_resume() instead of conditionally check
for MMC_PM_KEEP_POWER? Or maybe only a subset of those functions?

Kind regards
Uffe


From heiko at sntech.de  Tue Oct 18 02:21:59 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 18 Oct 2016 11:21:59 +0200
Subject: [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200
 speed from rk3288-veyron-speedy.
In-Reply-To: <1476647383.3885.3.camel@paulk.fr>
References: <87twd1vzc5.fsf@aikidev.net> <1476647383.3885.3.camel@paulk.fr>
Message-ID: <12872023.2LumKfgYDl@diego>

Am Sonntag, 16. Oktober 2016, 21:49:43 schrieb Paul Kocialkowski:
> Hi,
> 
> Le mardi 27 septembre 2016 ? 13:53 -0700, Vagrant Cascadian a ?crit :
> > This essentially mimics what was done with rk3288-veyron-minnie in
> > commit 984926781122f034d5bc9962815d135b6c4a8e1d.
> > 
> > The eMMC of the speedy Chromebook also appears to need the same tuning
> > workaround, as it frequently fails to recognize the eMMC without it.
> 
> I have a device where (without this patch) eMMC sometimes fails, with:
> [    3.561010] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to
> 175 [    3.571742] mmc2: new HS200 MMC card at address 0001
> [    3.571943] mmcblk2: mmc2:0001 HAG2e 14.7 GiB 
> [    3.572026] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
> [    3.572107] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
> [    3.572181] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
> [    3.685647] mmcblk2: error -110 transferring data, sector 0, nr 8, cmd
> response 0x900, card status 0x0
> 
> And sometimes works, with:
> [    3.451058] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to
> 176 [    3.491093] mmc2: new HS200 MMC card at address 0001
> [    3.491277] mmcblk2: mmc2:0001 HAG2e 14.7 GiB 
> [    3.491345] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
> [    3.491409] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
> [    3.491474] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
> [    3.493548]  mmcblk2: p1 p2
> 
> However, with this change, it always fails, with:
> [    3.322129] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req
> 52000000Hz, actual 50000000HZ div = 0) [    3.333174] mmc2: error -110
> whilst initialising MMC card
> 
> I don't have so much time to investigate this issue, but it's clear that
> this patch doesn't fix the issue (and actually worsens it) for my device.

thanks for the heads up.

As discussed on IRC we now have varying reports of the emmc working or not 
working with and without that patch applied. So it's not really a bandaid fix 
and I've thus dropped this patch again.

Still hoping someone will find the source of the problem somewhere :-)


Heiko


From jh80.chung at samsung.com  Tue Oct 18 03:45:35 2016
From: jh80.chung at samsung.com (Jaehoon Chung)
Date: Tue, 18 Oct 2016 19:45:35 +0900
Subject: [PATCH v2 0/9] Init runtime PM support for dw_mmc
In-Reply-To: <CAPDyKFopNgWh=+0RNFwJc+aaFPXGuJMAac5rPtfOawvLwSbN+g@mail.gmail.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
 <CGME20161018085101epcas1p323c180baf3a9c34b97bc9fb4a9581c46@epcas1p3.samsung.com>
 <CAPDyKFopNgWh=+0RNFwJc+aaFPXGuJMAac5rPtfOawvLwSbN+g@mail.gmail.com>
Message-ID: <17f821c0-46d3-76e7-06dd-fbb415de37eb@samsung.com>

On 10/18/2016 05:46 PM, Ulf Hansson wrote:
> + Heiko
> 
> On 12 October 2016 at 04:50, Shawn Lin <shawn.lin at rock-chips.com> wrote:
>>
>> Hi Jaehoon and Ulf,
>>
>>    This patch is gonna support runtime PM for dw_mmc.
>> It could support to disable ciu_clk by default and disable
>> biu_clk if the devices are non-removeable, or removeable
>> with gpio-base card detect.
>>
>>    Then I remove the system PM since the runtime PM actually
>> does the same thing as it. So I help migrate the dw_mmc variant
>> drivers to use runtime PM pairs and pm_runtime_force_*. Note
>> that I only enable runtime PM for dw_mmc-rockchip as I will
>> leave the decision to the owners of the corresponding drivers.
>> I just tested it on my RK3288 platform with linux-next to make
>> the runtime PM and system PM work fine for my emmc, sd card and
>> sdio. But I don't have hardware to help test other variant drivers.
>> But in theory it should work fine as I mentioned that the runtime
>> PM does the same thing as system PM except for disabling ciu_clk
>> aggressively which should not be related to the variant hosts.
>>
>>    As you could see that I just extend the slot-gpio a bit, so the
>> ideal way is Ulf could pick them up with Jaehoon's ack. :)
> 
> The mmc core change looks fine to me, so I will wait for a pull
> request from Jaehoon.
> 
>>
>>
>> Changes in v2:
>> - use struct device as argument for runtime callback
>> - use dw_mci_runtime_* directly
>> - use dw_mci_runtime_* directly
>> - minor fix since I change the argument for dw_mci_runtime_*
>> - use dw_mci_runtime_* directly
>> - use dw_mci_runtime_* directly
>>
>> Shawn Lin (9):
>>   mmc: dw_mmc: add runtime PM callback
>>   mmc: dw_mmc-rockchip: add runtime PM support
>>   mmc: core: expose the capability of gpio card detect
>>   mmc: dw_mmc: disable biu clk if possible
>>   mmc: dw_mmc-k3: deploy runtime PM facilities
>>   mmc: dw_mmc-exynos: deploy runtime PM facilities
>>   mmc: dw_mmc-pci: deploy runtime PM facilities
>>   mmc: dw_mmc-pltfm: deploy runtime PM facilities
>>   mmc: dw_mmc: remove system PM callback
>>
>>  drivers/mmc/core/slot-gpio.c       |  8 +++++++
>>  drivers/mmc/host/dw_mmc-exynos.c   | 24 +++++++++-----------
>>  drivers/mmc/host/dw_mmc-k3.c       | 39 ++++++++------------------------
>>  drivers/mmc/host/dw_mmc-pci.c      | 29 ++++++++----------------
>>  drivers/mmc/host/dw_mmc-pltfm.c    | 28 +++++++----------------
>>  drivers/mmc/host/dw_mmc-rockchip.c | 42 +++++++++++++++++++++++++++++++---
>>  drivers/mmc/host/dw_mmc.c          | 46 +++++++++++++++++++++++++-------------
>>  drivers/mmc/host/dw_mmc.h          |  6 ++---
>>  include/linux/mmc/slot-gpio.h      |  1 +
>>  9 files changed, 117 insertions(+), 106 deletions(-)
>>
> 
> Overall these changes looks good to me, so I am ready to accept the PR
> from Jaehoon!!
> 

Yes..I will apply on my repository..i'm testing on dwmmc-testing branch..
Actually, i found the some blocking issue but it's not relevant to these patches.
after checking the stress test until today..(eMMC/SD/SDIO)..I will do.

Entire patches looks good to me..thanks for Shawn's effort! :)

> 
> Although, highly related to this patchset, I am worried that there is
> a misunderstanding on how MMC_PM_KEEP_POWER (DT binding
> "keep-power-in-suspend") is being used for dw_mmc. Perhaps I am wrong,
> but I would appreciate if you could elaborate a bit for my
> understanding.
> 
> First, this cap is solely intended to be used for controllers which
> may have SDIO cards attached, as it indicates those cards may be
> configured to be powered on while the system enters suspend state. By
> looking at some DTS files, for example
> arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts which uses it
> for an eMMC slot, this is clearly being abused.

Right..it doesn't need to uses "keep-power-in-suspend" for eMMC/SD.

> 
> Anyway, the wrong DT configurations might not be a big deal, as in
> dw_mci_resume(), it's not the capabilities bit that is checked but the
> corresponding "pm_flag". This flag is set via calling
> sdio_set_host_pm_flags(), but as that doesn't happen for an eMMC card
> we should be fine, right!?
> 
> Now, what also do puzzles me, is exactly that piece of code in
> dw_mci_resume() that is being executed *when* the pm_flag contains
> MMC_PM_KEEP_POWER:
> if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
>      dw_mci_set_ios(slot->mmc, &slot->mmc->ios);
>      dw_mci_setup_bus(slot, true);
> }

There is no place to set this in dw_mmc controller..Maybe it should be located in other vendor driver.
Almost all cards that used SDIO might be WiFi..Of course..there might be other cards.
e.g) In exnyos, use the sdio as WiFi card(broadcom chipset) then broadcom driver also used..
When broadcom driver initialized or suspending time, it should be set to this flag..
As i mentioned..it's not normal case.

> 
> So, in the system resume path, the above do makes sense as you need to
> restore the registers etc for the dw_mmc controller to enable it to
> operate the SDIO card. Such as bus width, clocks, etc.
> 
> Although, I would expect something similar would be needed in the new
> runtime resume path as well. And in particular also for eMMC/SD cards,
> as you need to restore the dw_mmc registers to be able to operate the
> card again. Don't you?

Need to check :)

> 
> So in the end, perhaps you should *always* call dw_mci_set_ios() and
> dw_mci_setup_bus() in dw_mci_resume() instead of conditionally check
> for MMC_PM_KEEP_POWER? Or maybe only a subset of those functions?

It's reasonable..but it also needs to check on real case and stress test.

Best Regards,
Jaehoon Chung

> 
> Kind regards
> Uffe
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 



From ulf.hansson at linaro.org  Tue Oct 18 04:15:22 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 18 Oct 2016 13:15:22 +0200
Subject: [PATCH v2 0/9] Init runtime PM support for dw_mmc
In-Reply-To: <17f821c0-46d3-76e7-06dd-fbb415de37eb@samsung.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
 <CGME20161018085101epcas1p323c180baf3a9c34b97bc9fb4a9581c46@epcas1p3.samsung.com>
 <CAPDyKFopNgWh=+0RNFwJc+aaFPXGuJMAac5rPtfOawvLwSbN+g@mail.gmail.com>
 <17f821c0-46d3-76e7-06dd-fbb415de37eb@samsung.com>
Message-ID: <CAPDyKFrHpfhJjHYEPvTDHBUV--MABiTqO1PjzC4_635V7zC+kQ@mail.gmail.com>

[...]

>>
>> Now, what also do puzzles me, is exactly that piece of code in
>> dw_mci_resume() that is being executed *when* the pm_flag contains
>> MMC_PM_KEEP_POWER:
>> if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
>>      dw_mci_set_ios(slot->mmc, &slot->mmc->ios);
>>      dw_mci_setup_bus(slot, true);
>> }
>
> There is no place to set this in dw_mmc controller..Maybe it should be located in other vendor driver.
> Almost all cards that used SDIO might be WiFi..Of course..there might be other cards.
> e.g) In exnyos, use the sdio as WiFi card(broadcom chipset) then broadcom driver also used..
> When broadcom driver initialized or suspending time, it should be set to this flag..
> As i mentioned..it's not normal case.
>
>>
>> So, in the system resume path, the above do makes sense as you need to
>> restore the registers etc for the dw_mmc controller to enable it to
>> operate the SDIO card. Such as bus width, clocks, etc.
>>
>> Although, I would expect something similar would be needed in the new
>> runtime resume path as well. And in particular also for eMMC/SD cards,
>> as you need to restore the dw_mmc registers to be able to operate the
>> card again. Don't you?
>
> Need to check :)
>
>>
>> So in the end, perhaps you should *always* call dw_mci_set_ios() and
>> dw_mci_setup_bus() in dw_mci_resume() instead of conditionally check
>> for MMC_PM_KEEP_POWER? Or maybe only a subset of those functions?
>
> It's reasonable..but it also needs to check on real case and stress test.

Yes, and we can try out that later on top of this series.

Anyway, I wanted to highlight my concern, as I think it's only a
matter of time before we needed this on for runtime PM for some SoCs
that uses dw_mmc.

Kind regards
Uffe


From shawn.lin at rock-chips.com  Tue Oct 18 04:35:31 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 18 Oct 2016 19:35:31 +0800
Subject: [PATCH v2 0/9] Init runtime PM support for dw_mmc
In-Reply-To: <CAPDyKFopNgWh=+0RNFwJc+aaFPXGuJMAac5rPtfOawvLwSbN+g@mail.gmail.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
 <CAPDyKFopNgWh=+0RNFwJc+aaFPXGuJMAac5rPtfOawvLwSbN+g@mail.gmail.com>
Message-ID: <5be33ac5-7b5e-4b53-67bf-1c38822832ea@rock-chips.com>

? 2016/10/18 16:46, Ulf Hansson ??:
> + Heiko
>
> On 12 October 2016 at 04:50, Shawn Lin <shawn.lin at rock-chips.com> wrote:
>>
>> Hi Jaehoon and Ulf,
>>
>>    This patch is gonna support runtime PM for dw_mmc.
>> It could support to disable ciu_clk by default and disable
>> biu_clk if the devices are non-removeable, or removeable
>> with gpio-base card detect.
>>
>>    Then I remove the system PM since the runtime PM actually
>> does the same thing as it. So I help migrate the dw_mmc variant
>> drivers to use runtime PM pairs and pm_runtime_force_*. Note
>> that I only enable runtime PM for dw_mmc-rockchip as I will
>> leave the decision to the owners of the corresponding drivers.
>> I just tested it on my RK3288 platform with linux-next to make
>> the runtime PM and system PM work fine for my emmc, sd card and
>> sdio. But I don't have hardware to help test other variant drivers.
>> But in theory it should work fine as I mentioned that the runtime
>> PM does the same thing as system PM except for disabling ciu_clk
>> aggressively which should not be related to the variant hosts.
>>
>>    As you could see that I just extend the slot-gpio a bit, so the
>> ideal way is Ulf could pick them up with Jaehoon's ack. :)
>
> The mmc core change looks fine to me, so I will wait for a pull
> request from Jaehoon.
>
>>
>>
>> Changes in v2:
>> - use struct device as argument for runtime callback
>> - use dw_mci_runtime_* directly
>> - use dw_mci_runtime_* directly
>> - minor fix since I change the argument for dw_mci_runtime_*
>> - use dw_mci_runtime_* directly
>> - use dw_mci_runtime_* directly
>>
>> Shawn Lin (9):
>>   mmc: dw_mmc: add runtime PM callback
>>   mmc: dw_mmc-rockchip: add runtime PM support
>>   mmc: core: expose the capability of gpio card detect
>>   mmc: dw_mmc: disable biu clk if possible
>>   mmc: dw_mmc-k3: deploy runtime PM facilities
>>   mmc: dw_mmc-exynos: deploy runtime PM facilities
>>   mmc: dw_mmc-pci: deploy runtime PM facilities
>>   mmc: dw_mmc-pltfm: deploy runtime PM facilities
>>   mmc: dw_mmc: remove system PM callback
>>
>>  drivers/mmc/core/slot-gpio.c       |  8 +++++++
>>  drivers/mmc/host/dw_mmc-exynos.c   | 24 +++++++++-----------
>>  drivers/mmc/host/dw_mmc-k3.c       | 39 ++++++++------------------------
>>  drivers/mmc/host/dw_mmc-pci.c      | 29 ++++++++----------------
>>  drivers/mmc/host/dw_mmc-pltfm.c    | 28 +++++++----------------
>>  drivers/mmc/host/dw_mmc-rockchip.c | 42 +++++++++++++++++++++++++++++++---
>>  drivers/mmc/host/dw_mmc.c          | 46 +++++++++++++++++++++++++-------------
>>  drivers/mmc/host/dw_mmc.h          |  6 ++---
>>  include/linux/mmc/slot-gpio.h      |  1 +
>>  9 files changed, 117 insertions(+), 106 deletions(-)
>>
>
> Overall these changes looks good to me, so I am ready to accept the PR
> from Jaehoon!!
>
>
> Although, highly related to this patchset, I am worried that there is
> a misunderstanding on how MMC_PM_KEEP_POWER (DT binding
> "keep-power-in-suspend") is being used for dw_mmc. Perhaps I am wrong,
> but I would appreciate if you could elaborate a bit for my
> understanding.
>
> First, this cap is solely intended to be used for controllers which
> may have SDIO cards attached, as it indicates those cards may be
> configured to be powered on while the system enters suspend state. By
> looking at some DTS files, for example
> arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts which uses it
> for an eMMC slot, this is clearly being abused.

Indeed. In general, it should be copy-paste issues as folks maybe write
their dts referring to the exist dts there. So yes, I will do some 
cleanup work for them in prevent of further spread of abused code.

>
> Anyway, the wrong DT configurations might not be a big deal, as in
> dw_mci_resume(), it's not the capabilities bit that is checked but the
> corresponding "pm_flag". This flag is set via calling
> sdio_set_host_pm_flags(), but as that doesn't happen for an eMMC card
> we should be fine, right!?
>
> Now, what also do puzzles me, is exactly that piece of code in
> dw_mci_resume() that is being executed *when* the pm_flag contains
> MMC_PM_KEEP_POWER:
> if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
>      dw_mci_set_ios(slot->mmc, &slot->mmc->ios);
>      dw_mci_setup_bus(slot, true);
> }
>
> So, in the system resume path, the above do makes sense as you need to
> restore the registers etc for the dw_mmc controller to enable it to
> operate the SDIO card. Such as bus width, clocks, etc.
>
> Although, I would expect something similar would be needed in the new
> runtime resume path as well. And in particular also for eMMC/SD cards,
> as you need to restore the dw_mmc registers to be able to operate the
> card again. Don't you?

yes, we do.

>
> So in the end, perhaps you should *always* call dw_mci_set_ios() and
> dw_mci_setup_bus() in dw_mci_resume() instead of conditionally check
> for MMC_PM_KEEP_POWER? Or maybe only a subset of those functions?
>

Thanks for noticing this.

Personally, I realize there is no need to check MMC_PM_KEEP_POWER but
it could be highly related to the cost of S-2-R, I guess. I just checked
sdhci and saw the similar cases you mentioned at the first glance.
Maybe I'm wrong but I need more time to investigate this issue later.

There are still some on-going cleanup work for dw_mmc listed on my TODO
list, including bugfix, legacy/redundant code etc.. So I will check this 
one either. Maybe Jaehoon could also do some stree test on enxyos
platforms. :)


> Kind regards
> Uffe
>
>
>


-- 
Best Regards
Shawn Lin



From robh at kernel.org  Tue Oct 18 05:41:20 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 18 Oct 2016 07:41:20 -0500
Subject: [PATCH v2 2/2] dt-bindings: rockchip-thermal: fix the misleading
 description
In-Reply-To: <1476151655-18415-2-git-send-email-shawn.lin@rock-chips.com>
References: <1476151655-18415-1-git-send-email-shawn.lin@rock-chips.com>
 <1476151655-18415-2-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <20161018124120.vgbamfjsgvf6ntxg@rob-hp-laptop>

On Tue, Oct 11, 2016 at 10:07:35AM +0800, Shawn Lin wrote:
> "rockchip,hw-tshut-temp", "rockchip,hw-tshut-mode" and
> "rockchip,hw-tshut-polarity" are not a required properties
> actually as the code could also work by loading the default
> settings there. So it is apprently misleading, although we
> prefer to get these from DT. And it seems we miss the 'rockchip,grf'
> here which should also be an optional property.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> ---
> 
> Changes in v2: None
> 
>  Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 3 +++
>  1 file changed, 3 insertions(+)

Acked-by: Rob Herring <robh at kernel.org>


From shawn.lin at rock-chips.com  Tue Oct 18 05:52:28 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 18 Oct 2016 20:52:28 +0800
Subject: [PATCH] arm64: dts: rockchip: remove the abuse of
 keep-power-in-suspend
Message-ID: <1476795148-7515-1-git-send-email-shawn.lin@rock-chips.com>

It was invented for sdio only, and should not be used for sdmmc
or emmc. Remove it.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts        | 1 -
 arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts | 2 --
 2 files changed, 3 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
index 46cdddf..7b2c43a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
@@ -116,7 +116,6 @@
 	cap-mmc-highspeed;
 	clock-frequency = <150000000>;
 	disable-wp;
-	keep-power-in-suspend;
 	non-removable;
 	num-slots = <1>;
 	vmmc-supply = <&vcc_io>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts b/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
index 5797933..e788b42 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
@@ -201,7 +201,6 @@
 	bus-width = <8>;
 	cap-mmc-highspeed;
 	disable-wp;
-	keep-power-in-suspend;
 	mmc-pwrseq = <&emmc_pwrseq>;
 	mmc-hs200-1_2v;
 	mmc-hs200-1_8v;
@@ -350,7 +349,6 @@
 	clock-freq-min-max = <400000 50000000>;
 	cap-sd-highspeed;
 	card-detect-delay = <200>;
-	keep-power-in-suspend;
 	num-slots = <1>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
-- 
2.3.7




From heiko at sntech.de  Tue Oct 18 06:26:31 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 18 Oct 2016 15:26:31 +0200
Subject: [PATCH v2 0/9] Init runtime PM support for dw_mmc
In-Reply-To: <5be33ac5-7b5e-4b53-67bf-1c38822832ea@rock-chips.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
 <CAPDyKFopNgWh=+0RNFwJc+aaFPXGuJMAac5rPtfOawvLwSbN+g@mail.gmail.com>
 <5be33ac5-7b5e-4b53-67bf-1c38822832ea@rock-chips.com>
Message-ID: <6835953.765HGVcz2e@diego>

Am Dienstag, 18. Oktober 2016, 19:35:31 schrieb Shawn Lin:
> ? 2016/10/18 16:46, Ulf Hansson ??:
> > + Heiko
> > 
> > On 12 October 2016 at 04:50, Shawn Lin <shawn.lin at rock-chips.com> wrote:
> >> Hi Jaehoon and Ulf,
> >> 
> >>    This patch is gonna support runtime PM for dw_mmc.
> >> 
> >> It could support to disable ciu_clk by default and disable
> >> biu_clk if the devices are non-removeable, or removeable
> >> with gpio-base card detect.
> >> 
> >>    Then I remove the system PM since the runtime PM actually
> >> 
> >> does the same thing as it. So I help migrate the dw_mmc variant
> >> drivers to use runtime PM pairs and pm_runtime_force_*. Note
> >> that I only enable runtime PM for dw_mmc-rockchip as I will
> >> leave the decision to the owners of the corresponding drivers.
> >> I just tested it on my RK3288 platform with linux-next to make
> >> the runtime PM and system PM work fine for my emmc, sd card and
> >> sdio. But I don't have hardware to help test other variant drivers.
> >> But in theory it should work fine as I mentioned that the runtime
> >> PM does the same thing as system PM except for disabling ciu_clk
> >> aggressively which should not be related to the variant hosts.
> >> 
> >>    As you could see that I just extend the slot-gpio a bit, so the
> >> 
> >> ideal way is Ulf could pick them up with Jaehoon's ack. :)
> > 
> > The mmc core change looks fine to me, so I will wait for a pull
> > request from Jaehoon.
> > 
> >> Changes in v2:
> >> - use struct device as argument for runtime callback
> >> - use dw_mci_runtime_* directly
> >> - use dw_mci_runtime_* directly
> >> - minor fix since I change the argument for dw_mci_runtime_*
> >> - use dw_mci_runtime_* directly
> >> - use dw_mci_runtime_* directly
> >> 
> >> Shawn Lin (9):
> >>   mmc: dw_mmc: add runtime PM callback
> >>   mmc: dw_mmc-rockchip: add runtime PM support
> >>   mmc: core: expose the capability of gpio card detect
> >>   mmc: dw_mmc: disable biu clk if possible
> >>   mmc: dw_mmc-k3: deploy runtime PM facilities
> >>   mmc: dw_mmc-exynos: deploy runtime PM facilities
> >>   mmc: dw_mmc-pci: deploy runtime PM facilities
> >>   mmc: dw_mmc-pltfm: deploy runtime PM facilities
> >>   mmc: dw_mmc: remove system PM callback
> >>  
> >>  drivers/mmc/core/slot-gpio.c       |  8 +++++++
> >>  drivers/mmc/host/dw_mmc-exynos.c   | 24 +++++++++-----------
> >>  drivers/mmc/host/dw_mmc-k3.c       | 39 ++++++++------------------------
> >>  drivers/mmc/host/dw_mmc-pci.c      | 29 ++++++++----------------
> >>  drivers/mmc/host/dw_mmc-pltfm.c    | 28 +++++++----------------
> >>  drivers/mmc/host/dw_mmc-rockchip.c | 42
> >>  +++++++++++++++++++++++++++++++---
> >>  drivers/mmc/host/dw_mmc.c          | 46
> >>  +++++++++++++++++++++++++------------- drivers/mmc/host/dw_mmc.h       
> >>    |  6 ++---
> >>  include/linux/mmc/slot-gpio.h      |  1 +
> >>  9 files changed, 117 insertions(+), 106 deletions(-)
> > 
> > Overall these changes looks good to me, so I am ready to accept the PR
> > from Jaehoon!!
> > 
> > 
> > Although, highly related to this patchset, I am worried that there is
> > a misunderstanding on how MMC_PM_KEEP_POWER (DT binding
> > "keep-power-in-suspend") is being used for dw_mmc. Perhaps I am wrong,
> > but I would appreciate if you could elaborate a bit for my
> > understanding.
> > 
> > First, this cap is solely intended to be used for controllers which
> > may have SDIO cards attached, as it indicates those cards may be
> > configured to be powered on while the system enters suspend state. By
> > looking at some DTS files, for example
> > arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts which uses it
> > for an eMMC slot, this is clearly being abused.
> 
> Indeed. In general, it should be copy-paste issues as folks maybe write
> their dts referring to the exist dts there. So yes, I will do some
> cleanup work for them in prevent of further spread of abused code.

late to the party, but a copy-paste mistake were my thoughts as well.
Thanks Shawn for providing the patch cleaning that up.


Heiko


> > Anyway, the wrong DT configurations might not be a big deal, as in
> > dw_mci_resume(), it's not the capabilities bit that is checked but the
> > corresponding "pm_flag". This flag is set via calling
> > sdio_set_host_pm_flags(), but as that doesn't happen for an eMMC card
> > we should be fine, right!?
> > 
> > Now, what also do puzzles me, is exactly that piece of code in
> > dw_mci_resume() that is being executed *when* the pm_flag contains
> > MMC_PM_KEEP_POWER:
> > if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
> > 
> >      dw_mci_set_ios(slot->mmc, &slot->mmc->ios);
> >      dw_mci_setup_bus(slot, true);
> > 
> > }
> > 
> > So, in the system resume path, the above do makes sense as you need to
> > restore the registers etc for the dw_mmc controller to enable it to
> > operate the SDIO card. Such as bus width, clocks, etc.
> > 
> > Although, I would expect something similar would be needed in the new
> > runtime resume path as well. And in particular also for eMMC/SD cards,
> > as you need to restore the dw_mmc registers to be able to operate the
> > card again. Don't you?
> 
> yes, we do.
> 
> > So in the end, perhaps you should *always* call dw_mci_set_ios() and
> > dw_mci_setup_bus() in dw_mci_resume() instead of conditionally check
> > for MMC_PM_KEEP_POWER? Or maybe only a subset of those functions?
> 
> Thanks for noticing this.
> 
> Personally, I realize there is no need to check MMC_PM_KEEP_POWER but
> it could be highly related to the cost of S-2-R, I guess. I just checked
> sdhci and saw the similar cases you mentioned at the first glance.
> Maybe I'm wrong but I need more time to investigate this issue later.
> 
> There are still some on-going cleanup work for dw_mmc listed on my TODO
> list, including bugfix, legacy/redundant code etc.. So I will check this
> one either. Maybe Jaehoon could also do some stree test on enxyos
> platforms. :)
> 
> > Kind regards
> > Uffe



From djkurtz at chromium.org  Tue Oct 18 06:44:16 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Tue, 18 Oct 2016 21:44:16 +0800
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <1476133442-17757-1-git-send-email-dianders@chromium.org>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
Message-ID: <CAGS+omAT5gFD3vF7iz=Mc=CO00W_x2MSyGdpgD+tO2YfGnwpsA@mail.gmail.com>

Hi Doug,

On Tue, Oct 11, 2016 at 5:04 AM, Douglas Anderson <dianders at chromium.org> wrote:
> Users of usleep_range() expect that it will _never_ return in less time
> than the minimum passed parameter.  However, nothing in any of the code
> ensures this.  Specifically:
>
> usleep_range() => do_usleep_range() => schedule_hrtimeout_range() =>
> schedule_hrtimeout_range_clock() just ends up calling schedule() with an
> appropriate timeout set using the hrtimer.  If someone else happens to
> wake up our task then we'll happily return from usleep_range() early.

I think this change works, and fixes a real issue, however, I don't
think you are fixing this at the right layer.
The comment for schedule_hrtimeout_range says:

/**
 * schedule_hrtimeout_range - sleep until timeout
 * @expires:    timeout value (ktime_t)
 * @delta:      slack in expires timeout (ktime_t)
 * @mode:       timer mode, HRTIMER_MODE_ABS or HRTIMER_MODE_REL
 *
 * Make the current task sleep until the given expiry time has
 * elapsed. The routine will return immediately unless
 * the current task state has been set (see set_current_state()).
 *
 * The @delta argument gives the kernel the freedom to schedule the
 * actual wakeup to a time that is both power and performance friendly.
 * The kernel give the normal best effort behavior for "@expires+ at delta",
 * but may decide to fire the timer earlier, but no earlier than @expires.
 *
 * You can set the task state as follows -
 *
 * %TASK_UNINTERRUPTIBLE - at least @timeout time is guaranteed to
 * pass before the routine returns.
 *
 * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
 * delivered to the current task.
 *
 * The current task state is guaranteed to be TASK_RUNNING when this
 * routine returns.
 *
 * Returns 0 when the timer has expired otherwise -EINTR
 */

The behavior as specified for this function "at least @timeout time is
guaranteed to pass before the routine returns" already guarantees the
behavior you are adding to do_usleep_range() whenever the current task
state is (pre-)set to TASK_UNINTERRUPTIBLE.

Thus, I think the loop around 'schedule()' should be moved to
schedule_hrtimeout_range() itself.
This would also fix direct callers of schedule_hrtimeout_range() that
use TASK_UNINTERRUPTIBLE, although, I could only find one:

pt3_fetch_thread()

-Dan


From seanpaul at chromium.org  Tue Oct 18 08:52:16 2016
From: seanpaul at chromium.org (Sean Paul)
Date: Tue, 18 Oct 2016 11:52:16 -0400
Subject: [PATCH v3 1/6] drm/bridge: analogix_dp: set psr
 activate/deactivate when enable/disable bridge
In-Reply-To: <1476771283-11398-2-git-send-email-wzz@rock-chips.com>
References: <1476771283-11398-1-git-send-email-wzz@rock-chips.com>
 <1476771283-11398-2-git-send-email-wzz@rock-chips.com>
Message-ID: <CAOw6vb+peajznT3BkAZSG7f_7NRB08rTA8Vh_AufPSmwYjT0EQ@mail.gmail.com>

On Tue, Oct 18, 2016 at 2:14 AM, Zain Wang <wzz at rock-chips.com> wrote:
> From: zain wang <wzz at rock-chips.com>
>
> There's a race between when bridge_disable and when vop_crtc_disable are called.
> If the flush timer triggers a new psr work between these, we will operate eDP
> without power shutdowned by bridge_disable.
> In this case, moving activate/deactivate to enable/disable bridge to avoid it.
>

Reviewed-by: Sean Paul <seanpaul at chromium.org>

> Signed-off-by: zain wang <wzz at rock-chips.com>
> ---
>
> Changes in v3:
> - remove changes before.
> - move psr activat/deactivate to enable/disable bridge.
>
> Changes in v2:
> - add spin_lock to protect dpms_mode
>
>
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |  4 ++--
>  drivers/gpu/drm/rockchip/rockchip_drm_psr.c     | 30 ++++++++++++++++++++-----
>  drivers/gpu/drm/rockchip/rockchip_drm_psr.h     |  4 ++--
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c     |  4 ----
>  4 files changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 8548e82..e5471e7 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -159,7 +159,7 @@ static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
>                 return ret;
>         }
>
> -       return 0;
> +       return rockchip_drm_psr_activate(&dp->encoder);
>  }
>
>  static int rockchip_dp_powerdown(struct analogix_dp_plat_data *plat_data)
> @@ -168,7 +168,7 @@ static int rockchip_dp_powerdown(struct analogix_dp_plat_data *plat_data)
>
>         clk_disable_unprepare(dp->pclk);
>
> -       return 0;
> +       return rockchip_drm_psr_deactivate(&dp->encoder);
>  }
>
>  static int rockchip_dp_get_modes(struct analogix_dp_plat_data *plat_data,
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> index a553e18..4c379e9 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> @@ -57,6 +57,24 @@ out:
>         return psr;
>  }
>
> +static struct psr_drv *find_psr_by_encoder(struct drm_encoder *encoder)
> +{
> +       struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
> +       struct psr_drv *psr;
> +       unsigned long flags;
> +
> +       spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
> +       list_for_each_entry(psr, &drm_drv->psr_list, list) {
> +               if (psr->encoder == encoder)
> +                       goto out;
> +       }
> +       psr = ERR_PTR(-ENODEV);
> +
> +out:
> +       spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
> +       return psr;
> +}
> +
>  static void psr_set_state_locked(struct psr_drv *psr, enum psr_state state)
>  {
>         /*
> @@ -115,14 +133,14 @@ static void psr_flush_handler(unsigned long data)
>
>  /**
>   * rockchip_drm_psr_activate - activate PSR on the given pipe
> - * @crtc: CRTC to obtain the PSR encoder
> + * @encoder: encoder to obtain the PSR encoder
>   *
>   * Returns:
>   * Zero on success, negative errno on failure.
>   */
> -int rockchip_drm_psr_activate(struct drm_crtc *crtc)
> +int rockchip_drm_psr_activate(struct drm_encoder *encoder)
>  {
> -       struct psr_drv *psr = find_psr_by_crtc(crtc);
> +       struct psr_drv *psr = find_psr_by_encoder(encoder);
>         unsigned long flags;
>
>         if (IS_ERR(psr))
> @@ -138,14 +156,14 @@ EXPORT_SYMBOL(rockchip_drm_psr_activate);
>
>  /**
>   * rockchip_drm_psr_deactivate - deactivate PSR on the given pipe
> - * @crtc: CRTC to obtain the PSR encoder
> + * @encoder: encoder to obtain the PSR encoder
>   *
>   * Returns:
>   * Zero on success, negative errno on failure.
>   */
> -int rockchip_drm_psr_deactivate(struct drm_crtc *crtc)
> +int rockchip_drm_psr_deactivate(struct drm_encoder *encoder)
>  {
> -       struct psr_drv *psr = find_psr_by_crtc(crtc);
> +       struct psr_drv *psr = find_psr_by_encoder(encoder);
>         unsigned long flags;
>
>         if (IS_ERR(psr))
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
> index b420cf1..b1ea015 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
> @@ -18,8 +18,8 @@
>  void rockchip_drm_psr_flush_all(struct drm_device *dev);
>  int rockchip_drm_psr_flush(struct drm_crtc *crtc);
>
> -int rockchip_drm_psr_activate(struct drm_crtc *crtc);
> -int rockchip_drm_psr_deactivate(struct drm_crtc *crtc);
> +int rockchip_drm_psr_activate(struct drm_encoder *encoder);
> +int rockchip_drm_psr_deactivate(struct drm_encoder *encoder);
>
>  int rockchip_drm_psr_register(struct drm_encoder *encoder,
>                         void (*psr_set)(struct drm_encoder *, bool enable));
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index c7eba30..1740a0b 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -566,8 +566,6 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
>
>         WARN_ON(vop->event);
>
> -       rockchip_drm_psr_deactivate(&vop->crtc);
> -
>         /*
>          * We need to make sure that all windows are disabled before we
>          * disable that crtc. Otherwise we might try to scan from a destroyed
> @@ -975,8 +973,6 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
>         clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
>
>         VOP_CTRL_SET(vop, standby, 0);
> -
> -       rockchip_drm_psr_activate(&vop->crtc);
>  }
>
>  static bool vop_fs_irq_is_pending(struct vop *vop)
> --
> 1.9.1
>
>


From seanpaul at chromium.org  Tue Oct 18 08:52:56 2016
From: seanpaul at chromium.org (Sean Paul)
Date: Tue, 18 Oct 2016 11:52:56 -0400
Subject: [PATCH v3 3/6] drm/bridge: analogix_dp: detect Sink PSR state
 after configuring the PSR
In-Reply-To: <1476771697-11895-1-git-send-email-wzz@rock-chips.com>
References: <1476771697-11895-1-git-send-email-wzz@rock-chips.com>
Message-ID: <CAOw6vbJ=8ZEW7pOgqePjpDaT1qc42bVCzqoC=uzSU+K=pSBJcw@mail.gmail.com>

On Tue, Oct 18, 2016 at 2:21 AM, Zain Wang <wzz at rock-chips.com> wrote:
> From: Yakir Yang <ykk at rock-chips.com>
>
> Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
> function, or print the sink PSR error state if we failed to apply the
> requested PSR setting.
>
> Signed-off-by: zain wang <wzz at rock-chips.com>
> Signed-off-by: Yakir Yang <ykk at rock-chips.com>
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 ++----
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  6 ++++--
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 25 ++++++++++++++++++++--
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c    |  6 ++++--
>  4 files changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index bcae4dd..7faad93 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -124,8 +124,7 @@ int analogix_dp_enable_psr(struct device *dev)
>         psr_vsc.DB0 = 0;
>         psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
>
> -       analogix_dp_send_psr_spd(dp, &psr_vsc);
> -       return 0;
> +       return analogix_dp_send_psr_spd(dp, &psr_vsc);
>  }
>  EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
>
> @@ -147,8 +146,7 @@ int analogix_dp_disable_psr(struct device *dev)
>         psr_vsc.DB0 = 0;
>         psr_vsc.DB1 = 0;
>
> -       analogix_dp_send_psr_spd(dp, &psr_vsc);
> -       return 0;
> +       return analogix_dp_send_psr_spd(dp, &psr_vsc);
>  }
>  EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> index 5c6a288..cdc0535 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> @@ -20,6 +20,8 @@
>  #define MAX_CR_LOOP 5
>  #define MAX_EQ_LOOP 5
>
> +#define DP_TIMEOUT_PSR_LOOP_MS                 msecs_to_jiffies(300)

This value isn't MS units, it's jiffies.

> +
>  /* DP_MAX_LANE_COUNT */
>  #define DPCD_ENHANCED_FRAME_CAP(x)             (((x) >> 7) & 0x1)
>  #define DPCD_MAX_LANE_COUNT(x)                 ((x) & 0x1f)
> @@ -247,8 +249,8 @@ void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp);
>  void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
>  void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
>  void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
> -void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> -                             struct edp_vsc_psr *vsc);
> +int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> +                            struct edp_vsc_psr *vsc);
>  ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
>                              struct drm_dp_aux_msg *msg);
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index cd37ac0..9e1177c 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -992,10 +992,12 @@ void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp)
>         writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
>  }
>
> -void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> -                             struct edp_vsc_psr *vsc)
> +int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> +                            struct edp_vsc_psr *vsc)
>  {
> +       unsigned long timeout;
>         unsigned int val;
> +       u8 sink;
>
>         /* don't send info frame */
>         val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
> @@ -1036,6 +1038,25 @@ void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
>         val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
>         val |= IF_EN;
>         writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
> +
> +       timeout = jiffies + DP_TIMEOUT_PSR_LOOP_MS;
> +       while (time_before(jiffies, timeout)) {
> +               val = drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, &sink);
> +               if (val != 1) {
> +                       dev_err(dp->dev, "PSR_STATUS read failed ret=%d", val);
> +                       return -EBUSY;
> +               }
> +
> +               if ((vsc->DB1 && sink == DP_PSR_SINK_ACTIVE_RFB) ||
> +                   (!vsc->DB1 && sink == DP_PSR_SINK_INACTIVE))
> +                       return 0;
> +
> +               usleep_range(1000, 1500);
> +       }
> +
> +       dev_warn(dp->dev, "Failed to apply PSR, sink state was [%x]", sink);
> +
> +       return -ETIMEDOUT;


This can all be replaced with readx_poll_timeout

>  }
>
>  ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index e5471e7..1c2d756 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -105,7 +105,7 @@ static void analogix_dp_psr_work(struct work_struct *work)
>         struct rockchip_dp_device *dp =
>                                 container_of(work, typeof(*dp), psr_work);
>         struct drm_crtc *crtc = dp->encoder.crtc;
> -       int psr_state = dp->psr_state;
> +       int psr_state;
>         int vact_end;
>         int ret;
>         unsigned long flags;
> @@ -123,11 +123,13 @@ static void analogix_dp_psr_work(struct work_struct *work)
>         }
>
>         spin_lock_irqsave(&dp->psr_lock, flags);
> +       psr_state = dp->psr_state;
> +       spin_unlock_irqrestore(&dp->psr_lock, flags);
> +
>         if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
>                 analogix_dp_enable_psr(dp->dev);
>         else
>                 analogix_dp_disable_psr(dp->dev);
> -       spin_unlock_irqrestore(&dp->psr_lock, flags);

I think we've been back and forth on this enough times to know what
I'm going to say about moving/removing the lock here :-)

It seems like the reason you need to do this is because of the
proliferation of spinlocks through the psr stack (which I think is due
to the way flush timer is implemented).

I just whipped up a patch to change this stuff to non-atomic context
such that we can keep locking things in a safe manner. I'll post it on
list and cc you, you can then rebase your set on that.

Sean



>  }
>
>  static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
> --
> 1.9.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From seanpaul at chromium.org  Tue Oct 18 08:53:32 2016
From: seanpaul at chromium.org (Sean Paul)
Date: Tue, 18 Oct 2016 11:53:32 -0400
Subject: [PATCH v3 5/6] drm: bridge/analogix: add fast link train for eDP
In-Reply-To: <1476771741-11997-1-git-send-email-wzz@rock-chips.com>
References: <1476771741-11997-1-git-send-email-wzz@rock-chips.com>
Message-ID: <CAOw6vbJ9oTcd6QACD7UROpXVymqf7xeMnSWjGqq8TYHkLWmYQw@mail.gmail.com>

On Tue, Oct 18, 2016 at 2:22 AM, Zain Wang <wzz at rock-chips.com> wrote:
> From: zain wang <wzz at rock-chips.com>
>
> we would meet a short black screen when exit PSR with the full link
> training, In this case, we should use fast link train instead of full
> link training.
>
> Signed-off-by: zain wang <wzz at rock-chips.com>
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 89 +++++++++++++++++++++-
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  1 +
>  2 files changed, 86 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 561b644..0516621 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -21,6 +21,7 @@
>  #include <linux/gpio.h>
>  #include <linux/component.h>
>  #include <linux/phy/phy.h>
> +#include <linux/iopoll.h>
>
>  #include <drm/drmP.h>
>  #include <drm/drm_atomic_helper.h>
> @@ -35,6 +36,8 @@
>
>  #define to_dp(nm)      container_of(nm, struct analogix_dp_device, nm)
>
> +static const int FAST_LINK_VERIFICATION = false;

/* Set this to true to verify fast link training succeeded */
static const bool verify_fast_training = false;

> +
>  struct bridge_init {
>         struct i2c_client *client;
>         struct device_node *node;
> @@ -244,6 +247,7 @@ static int analogix_dp_link_start(struct analogix_dp_device *dp)
>                 usleep_range(90, 120);
>         }
>
> +

remove extra line

>         /* Set training pattern 1 */
>         analogix_dp_set_training_pattern(dp, TRAINING_PTN1);
>
> @@ -481,7 +485,7 @@ static int analogix_dp_process_equalizer_training(struct analogix_dp_device *dp)
>  {
>         int lane, lane_count, retval;
>         u32 reg;
> -       u8 link_align, link_status[2], adjust_request[2];
> +       u8 link_align, link_status[2], adjust_request[2], spread;
>
>         usleep_range(400, 401);
>
> @@ -524,6 +528,12 @@ static int analogix_dp_process_equalizer_training(struct analogix_dp_device *dp)
>                 dev_dbg(dp->dev, "final lane count = %.2x\n",
>                         dp->link_train.lane_count);
>
> +               drm_dp_dpcd_readb(&dp->aux, DP_MAX_DOWNSPREAD, &spread);

check return value

> +               dp->fast_train_support = (spread &
> +                       DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ? true : false;
> +               dev_dbg(dp->dev, "fast link training %s\n",
> +                       dp->fast_train_support ? "supported" : "unsupported");
> +
>                 /* set enhanced mode if available */
>                 analogix_dp_set_enhanced_mode(dp);
>                 dp->link_train.lt_state = FINISHED;
> @@ -655,6 +665,75 @@ static int analogix_dp_sw_link_training(struct analogix_dp_device *dp)
>         return retval;
>  }
>
> +static int analogix_dp_full_link_train(struct analogix_dp_device *dp,
> +                                           u32 count, u32 bwtype)
> +{
> +       analogix_dp_init_training(dp, count, bwtype);
> +       return analogix_dp_sw_link_training(dp);
> +}
> +
> +static int analogix_dp_fast_link_train(struct analogix_dp_device *dp)
> +{
> +       int lane;
> +       int retval;

int ret;

> +       u8 link_align, link_status[2];
> +       enum pll_status status;
> +
> +       analogix_dp_reset_macro(dp);
> +
> +       analogix_dp_set_link_bandwidth(dp, dp->link_train.link_rate);
> +       analogix_dp_set_lane_count(dp, dp->link_train.lane_count);
> +
> +       for (lane = 0; lane < dp->link_train.lane_count; lane++) {
> +               analogix_dp_set_lane_link_training(dp,
> +                       dp->link_train.training_lane[lane], lane);
> +       }
> +
> +       retval = readx_poll_timeout(analogix_dp_get_pll_lock_status, dp, status,
> +                                   status != PLL_UNLOCKED,
> +                                   120, 120 * DP_TIMEOUT_LOOP_COUNT);
> +
> +       if (retval)
> +               return retval;
> +
> +       /* source Set training pattern 1 */
> +       analogix_dp_set_training_pattern(dp, TRAINING_PTN1);
> +       usleep_range(500, 600);

Add a comment to these sleeps explaining that the spec dictates each
training pattern must be output for minimum 500us

> +
> +       analogix_dp_set_training_pattern(dp, TRAINING_PTN2);
> +       usleep_range(500, 600);
> +
> +       /* TODO: enhanced_mode?*/
> +       analogix_dp_set_training_pattern(dp, DP_NONE);
> +
> +       if (FAST_LINK_VERIFICATION) {
> +               retval = drm_dp_dpcd_readb(&dp->aux,
> +                                          DP_LANE_ALIGN_STATUS_UPDATED,
> +                                          &link_align);
> +               if (retval < 0)
> +                       return retval;
> +
> +               retval = drm_dp_dpcd_read(&dp->aux, DP_LANE0_1_STATUS,
> +                                         link_status, 2);
> +               if (retval < 0)
> +                       return retval;
> +
> +               if (analogix_dp_clock_recovery_ok(link_status,
> +                                                 dp->link_train.lane_count)) {
> +                       analogix_dp_reduce_link_rate(dp);
> +                       return -EIO;
> +               }
> +
> +               if (analogix_dp_channel_eq_ok(link_status, link_align,
> +                                             dp->link_train.lane_count)) {
> +                       analogix_dp_reduce_link_rate(dp);
> +                       return -EIO;
> +               }
> +       }
> +
> +       return 0;
> +}
> +
>  static int analogix_dp_set_link_train(struct analogix_dp_device *dp,
>                                       u32 count, u32 bwtype)
>  {
> @@ -662,11 +741,13 @@ static int analogix_dp_set_link_train(struct analogix_dp_device *dp,
>         int retval;
>
>         for (i = 0; i < DP_TIMEOUT_LOOP_COUNT; i++) {
> -               analogix_dp_init_training(dp, count, bwtype);
> -               retval = analogix_dp_sw_link_training(dp);
> +               if (dp->fast_train_support)
> +                       retval = analogix_dp_fast_link_train(dp);
> +               else
> +                       retval = analogix_dp_full_link_train(dp, count,
> +                                                                 bwtype);
>                 if (retval == 0)
>                         break;
> -
>                 usleep_range(100, 110);
>         }
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> index cdc0535..b86039b 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> @@ -171,6 +171,7 @@ struct analogix_dp_device {
>         int                     hpd_gpio;
>         bool                    force_hpd;
>         bool                    psr_support;
> +       bool                    fast_train_support;
>
>         struct mutex            panel_lock;
>         bool                    panel_is_modeset;
> --
> 1.9.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From seanpaul at chromium.org  Tue Oct 18 08:52:35 2016
From: seanpaul at chromium.org (Sean Paul)
Date: Tue, 18 Oct 2016 11:52:35 -0400
Subject: [PATCH v3 2/6] drm/bridge: remove dp init from analogix_dp_bind
In-Reply-To: <1476771283-11398-3-git-send-email-wzz@rock-chips.com>
References: <1476771283-11398-1-git-send-email-wzz@rock-chips.com>
 <1476771283-11398-3-git-send-email-wzz@rock-chips.com>
Message-ID: <CAOw6vb+fSpiH75TFQ+kphSPFn3h3YOCMAOXbVy0KZppLsUi55A@mail.gmail.com>

On Tue, Oct 18, 2016 at 2:14 AM, Zain Wang <wzz at rock-chips.com> wrote:
> From: zain wang <wzz at rock-chips.com>
>
> phy_power_on() and analogix_dp_init_dp would be called in bridge_eanble,
> so remove them from analogix_dp_bind to be clear.
>

Reviewed-by: Sean Paul <seanpaul at chromium.org>

> Signed-off-by: zain wang <wzz at rock-chips.com>
> ---
>
> Changes in v3:
> - remove changes before
> - remove phy_power_on() and analogix_dp_init_dp from analogix_dp_bind().
>
> Changes in v2: None
>
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ----
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 001b075..bcae4dd 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1389,10 +1389,6 @@ int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
>
>         pm_runtime_enable(dev);
>
> -       phy_power_on(dp->phy);
> -
> -       analogix_dp_init_dp(dp);
> -
>         ret = devm_request_threaded_irq(&pdev->dev, dp->irq,
>                                         analogix_dp_hardirq,
>                                         analogix_dp_irq_thread,
> --
> 1.9.1
>
>


From seanpaul at chromium.org  Tue Oct 18 08:53:16 2016
From: seanpaul at chromium.org (Sean Paul)
Date: Tue, 18 Oct 2016 11:53:16 -0400
Subject: [PATCH v3 4/6] drm: bridge/analogix: switch Main-link and eDP PHY
 when enable/disable psr
In-Reply-To: <1476771719-11941-1-git-send-email-wzz@rock-chips.com>
References: <1476771719-11941-1-git-send-email-wzz@rock-chips.com>
Message-ID: <CAOw6vbLaSEmKn23XwZmmw=ToSb1_32Tb0KEEpu9UK3z86tM5aA@mail.gmail.com>

On Tue, Oct 18, 2016 at 2:21 AM, Zain Wang <wzz at rock-chips.com> wrote:
> From: zain wang <wzz at rock-chips.com>
>
> turn off Main-link and power down eDP PHY when enable psr,
> turn on Main-link and power up eDP PHY when disable psr.
>
> Signed-off-by: zain wang <wzz at rock-chips.com>
> ---
>
> Changes in v3:
> - detecting PSR state at enable/disable_psr() avoid to make link training
>   when sink in not PSR State.
>
> Changes in v2:
> - misc changes
>
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 123 +++++++++++++--------
>  1 file changed, 76 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index c4f139a..c662e5d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -98,50 +98,6 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device *dp)
>         return 0;
>  }
>
> -int analogix_dp_enable_psr(struct device *dev)
> -{
> -       struct analogix_dp_device *dp = dev_get_drvdata(dev);
> -       struct edp_vsc_psr psr_vsc;
> -
> -       if (!dp->psr_support)
> -               return -EINVAL;
> -
> -       /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
> -       memset(&psr_vsc, 0, sizeof(psr_vsc));
> -       psr_vsc.sdp_header.HB0 = 0;
> -       psr_vsc.sdp_header.HB1 = 0x7;
> -       psr_vsc.sdp_header.HB2 = 0x2;
> -       psr_vsc.sdp_header.HB3 = 0x8;
> -
> -       psr_vsc.DB0 = 0;
> -       psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
> -
> -       return analogix_dp_send_psr_spd(dp, &psr_vsc);
> -}
> -EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
> -
> -int analogix_dp_disable_psr(struct device *dev)
> -{
> -       struct analogix_dp_device *dp = dev_get_drvdata(dev);
> -       struct edp_vsc_psr psr_vsc;
> -
> -       if (!dp->psr_support)
> -               return -EINVAL;
> -
> -       /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
> -       memset(&psr_vsc, 0, sizeof(psr_vsc));
> -       psr_vsc.sdp_header.HB0 = 0;
> -       psr_vsc.sdp_header.HB1 = 0x7;
> -       psr_vsc.sdp_header.HB2 = 0x2;
> -       psr_vsc.sdp_header.HB3 = 0x8;
> -
> -       psr_vsc.DB0 = 0;
> -       psr_vsc.DB1 = 0;
> -
> -       return analogix_dp_send_psr_spd(dp, &psr_vsc);
> -}
> -EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
> -
>  static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
>  {
>         unsigned char psr_version;
> @@ -162,12 +118,11 @@ static void analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
>         drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
>
>         /* Main-Link transmitter remains active during PSR active states */
> -       psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
> +       psr_en = DP_PSR_CRC_VERIFICATION;
>         drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
>
>         /* Enable psr function */
> -       psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
> -                DP_PSR_CRC_VERIFICATION;
> +       psr_en = DP_PSR_ENABLE | DP_PSR_CRC_VERIFICATION;
>         drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
>
>         analogix_dp_enable_psr_crc(dp);
> @@ -870,6 +825,80 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
>                 analogix_dp_enable_sink_psr(dp);
>  }
>
> +int analogix_dp_enable_psr(struct device *dev)
> +{
> +       struct analogix_dp_device *dp = dev_get_drvdata(dev);
> +       struct edp_vsc_psr psr_vsc;
> +       int retval;

int ret;

> +       u8 sink;
> +
> +       if (!dp->psr_support)
> +               return -EINVAL;
> +
> +       drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, &sink);

return value not checked

> +       if (sink == DP_PSR_SINK_ACTIVE_RFB)
> +               return 0;
> +
> +       /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
> +       memset(&psr_vsc, 0, sizeof(psr_vsc));
> +       psr_vsc.sdp_header.HB0 = 0;
> +       psr_vsc.sdp_header.HB1 = 0x7;
> +       psr_vsc.sdp_header.HB2 = 0x2;
> +       psr_vsc.sdp_header.HB3 = 0x8;
> +
> +       psr_vsc.DB0 = 0;
> +       psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
> +
> +       retval = analogix_dp_send_psr_spd(dp, &psr_vsc);
> +

remove extra line

> +       if (!retval) {
> +               /* Power down the eDP PHY */
> +               analogix_dp_set_analog_power_down(dp, POWER_ALL, true);
> +       }
> +
> +       return retval;
> +}
> +EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
> +
> +int analogix_dp_disable_psr(struct device *dev)
> +{
> +       struct analogix_dp_device *dp = dev_get_drvdata(dev);
> +       struct edp_vsc_psr psr_vsc;
> +       int ret;
> +       u8 sink;
> +
> +       if (!dp->psr_support)
> +               return -EINVAL;
> +
> +       /* Power up the eDP PHY */
> +       analogix_dp_set_analog_power_down(dp, POWER_ALL, false);
> +
> +       drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, &sink);
> +       if (sink == DP_PSR_SINK_INACTIVE)
> +               return 0;
> +
> +       ret = drm_dp_dpcd_writeb(&dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
> +       if (ret < 0) {
> +               dev_err(dp->dev, "Failed to set DP Power0\n");

print ret in the error

> +       }
> +
> +       analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
> +                                  dp->video_info.max_link_rate);
> +
> +       /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
> +       memset(&psr_vsc, 0, sizeof(psr_vsc));
> +       psr_vsc.sdp_header.HB0 = 0;
> +       psr_vsc.sdp_header.HB1 = 0x7;
> +       psr_vsc.sdp_header.HB2 = 0x2;
> +       psr_vsc.sdp_header.HB3 = 0x8;
> +
> +       psr_vsc.DB0 = 0;
> +       psr_vsc.DB1 = 0;
> +
> +       return analogix_dp_send_psr_spd(dp, &psr_vsc);
> +}
> +EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
> +
>  /*
>   * This function is a bit of a catch-all for panel preparation, hopefully
>   * simplifying the logic of functions that need to prepare/unprepare the panel
> --
> 1.9.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From seanpaul at chromium.org  Tue Oct 18 08:54:56 2016
From: seanpaul at chromium.org (Sean Paul)
Date: Tue, 18 Oct 2016 11:54:56 -0400
Subject: [PATCH 6/6] drm: bridge/analogix: enable vop standby when entry
 PSR
In-Reply-To: <1476771756-12045-1-git-send-email-wzz@rock-chips.com>
References: <1476771756-12045-1-git-send-email-wzz@rock-chips.com>
Message-ID: <CAOw6vbLL-_GisEmLnE9S7uQvLGnqvfi5+KAcW9PSVHVo7TdMMQ@mail.gmail.com>

On Tue, Oct 18, 2016 at 2:22 AM, Zain Wang <wzz at rock-chips.com> wrote:
> From: zain wang <wzz at rock-chips.com>
>
> make VOP standby when entry PSR to save some power.

This is super racey and will cause bugs. Hopefully once you base it on
the updated locking it won't be.

I'll wait until then to review.

Sean


>
> Signed-off-by: zain wang <wzz at rock-chips.com>
> ---
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 29 ++++++++++++++++++-------
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h     |  1 +
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c     | 19 ++++++++++++++++
>  3 files changed, 41 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 1c2d756..e0f3ed3 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -113,6 +113,13 @@ static void analogix_dp_psr_work(struct work_struct *work)
>         if (!crtc)
>                 return;
>
> +       spin_lock_irqsave(&dp->psr_lock, flags);
> +       psr_state = dp->psr_state;
> +       spin_unlock_irqrestore(&dp->psr_lock, flags);
> +
> +       if (psr_state != EDP_VSC_PSR_STATE_ACTIVE)
> +               rockchip_drm_vop_set_standby(crtc, false);
> +
>         vact_end = crtc->mode.vtotal - crtc->mode.vsync_start + crtc->mode.vdisplay;
>
>         ret = rockchip_drm_wait_line_flag(dp->encoder.crtc, vact_end,
> @@ -122,14 +129,20 @@ static void analogix_dp_psr_work(struct work_struct *work)
>                 return;
>         }
>
> -       spin_lock_irqsave(&dp->psr_lock, flags);
> -       psr_state = dp->psr_state;
> -       spin_unlock_irqrestore(&dp->psr_lock, flags);
> -
> -       if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
> -               analogix_dp_enable_psr(dp->dev);
> -       else
> -               analogix_dp_disable_psr(dp->dev);
> +       if (psr_state == EDP_VSC_PSR_STATE_ACTIVE) {
> +               ret = analogix_dp_enable_psr(dp->dev);
> +               if (ret) {
> +                       dev_err(dp->dev, "failed to enable psr\n");
> +                       return;
> +               }
> +               rockchip_drm_vop_set_standby(crtc, true);
> +       } else {
> +               ret = analogix_dp_disable_psr(dp->dev);
> +               if (ret) {
> +                       dev_err(dp->dev, "failed to disable psr\n");
> +                       return;
> +               }
> +       }
>  }
>
>  static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> index fb6226c..7149c69 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> @@ -74,5 +74,6 @@ void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
>                                     struct device *dev);
>  int rockchip_drm_wait_line_flag(struct drm_crtc *crtc, unsigned int line_num,
>                                 unsigned int mstimeout);
> +void rockchip_drm_vop_set_standby(struct drm_crtc *crtc, bool enabled);
>
>  #endif /* _ROCKCHIP_DRM_DRV_H_ */
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 1740a0b..13eabda 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -1478,6 +1478,25 @@ int rockchip_drm_wait_line_flag(struct drm_crtc *crtc, unsigned int line_num,
>  }
>  EXPORT_SYMBOL(rockchip_drm_wait_line_flag);
>
> +void rockchip_drm_vop_set_standby(struct drm_crtc *crtc, bool enabled)
> +{
> +       struct vop *vop = to_vop(crtc);
> +
> +       if (!crtc || !vop->is_enabled)
> +               return;
> +
> +       spin_lock(&vop->reg_lock);
> +
> +       if (enabled)
> +               VOP_CTRL_SET(vop, standby, 1);
> +       else
> +               VOP_CTRL_SET(vop, standby, 0);
> +
> +       spin_unlock(&vop->reg_lock);
> +
> +}
> +EXPORT_SYMBOL(rockchip_drm_vop_set_standby);
> +
>  static int vop_bind(struct device *dev, struct device *master, void *data)
>  {
>         struct platform_device *pdev = to_platform_device(dev);
> --
> 1.9.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From robh at kernel.org  Tue Oct 18 09:41:39 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 18 Oct 2016 11:41:39 -0500
Subject: [PATCH v8 1/3] Documentation/devicetree: Add new property to
 specify the max link speed
In-Reply-To: <1476755110-22647-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476755110-22647-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <20161018164139.z52uo7eda5xgwkzu@rob-hp-laptop>

On Tue, Oct 18, 2016 at 09:45:08AM +0800, Shawn Lin wrote:
> Some of the host drivers have the requirement of knowing whether the
> EP would never train at some link speed at all. For instance, on some
> boards, the link won't train at 5 GT/s but the host driver still sacrifice
> some cycle to wait for the resule of training at 5 GT/s as the host could
> actually support 5 GT/s. So we could parse this new property and make the
> host drivers be aware of these cases.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> ---
> 
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None

Humm, either you are respinning versions too quickly or failed to copy 
the DT list.

> 
>  Documentation/devicetree/bindings/pci/pci.txt | 6 ++++++
>  1 file changed, 6 insertions(+)

Acked-by: Rob Herring <robh at kernel.org>

> 
> diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
> index 08dcfad..e7d97a3 100644
> --- a/Documentation/devicetree/bindings/pci/pci.txt
> +++ b/Documentation/devicetree/bindings/pci/pci.txt
> @@ -18,3 +18,9 @@ driver implementation may support the following properties:
>     host bridges in the system, otherwise potentially conflicting domain numbers
>     may be assigned to root buses behind different host bridges.  The domain
>     number for each host bridge in the system must be unique.
> +- max-link-speed:
> +   If present this property specifies PCI gen for link capability. The host drivers
> +   could add this as a strategy to avoid unnecessary operation for unsupported
> +   link speed, for instance, trying to do training for unsupported link speed, etc.
> +   Must be '4' for gen4, '3' for gen3, '2' for gen2, and '1' for gen1. Any other
> +   values are invalid.
> -- 
> 2.3.7
> 
> 


From heiko at sntech.de  Tue Oct 18 11:10:06 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 18 Oct 2016 20:10:06 +0200
Subject: [PATCH] arm64: dts: rockchip: remove the abuse of
 keep-power-in-suspend
In-Reply-To: <1476795148-7515-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476795148-7515-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <3417624.TgoaLD2vQ9@diego>

Am Dienstag, 18. Oktober 2016, 20:52:28 schrieb Shawn Lin:
> It was invented for sdio only, and should not be used for sdmmc
> or emmc. Remove it.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

applied to my fixes for 4.9

Thanks for cleaning that up
Heiko


From seanpaul at chromium.org  Tue Oct 18 13:07:13 2016
From: seanpaul at chromium.org (Sean Paul)
Date: Tue, 18 Oct 2016 16:07:13 -0400
Subject: [PATCH] drm/rockchip: Don't use atomic constructs for psr
Message-ID: <1476821233-32013-1-git-send-email-seanpaul@chromium.org>

Instead of using timer and spinlocks, use delayed_work and
mutexes for rockchip psr. This allows us to make blocking
calls when enabling/disabling psr (which is sort of important
given we're talking over dpcd to the display).

Cc: zain wang <wzz at rock-chips.com>
Signed-off-by: Sean Paul <seanpaul at chromium.org>
---
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 14 +++--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c     |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h     |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c     | 68 +++++++++++--------------
 4 files changed, 37 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index e5471e7..8877ba2 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -72,7 +72,7 @@ struct rockchip_dp_device {
 	struct reset_control     *rst;
 
 	struct work_struct	 psr_work;
-	spinlock_t		 psr_lock;
+	struct mutex		 psr_lock;
 	unsigned int             psr_state;
 
 	const struct rockchip_dp_chip_data *data;
@@ -83,21 +83,20 @@ struct rockchip_dp_device {
 static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
 {
 	struct rockchip_dp_device *dp = to_dp(encoder);
-	unsigned long flags;
 
 	if (!analogix_dp_psr_supported(dp->dev))
 		return;
 
 	dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
 
-	spin_lock_irqsave(&dp->psr_lock, flags);
+	mutex_lock(&dp->psr_lock);
 	if (enabled)
 		dp->psr_state = EDP_VSC_PSR_STATE_ACTIVE;
 	else
 		dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
 
 	schedule_work(&dp->psr_work);
-	spin_unlock_irqrestore(&dp->psr_lock, flags);
+	mutex_unlock(&dp->psr_lock);
 }
 
 static void analogix_dp_psr_work(struct work_struct *work)
@@ -108,7 +107,6 @@ static void analogix_dp_psr_work(struct work_struct *work)
 	int psr_state = dp->psr_state;
 	int vact_end;
 	int ret;
-	unsigned long flags;
 
 	if (!crtc)
 		return;
@@ -122,12 +120,12 @@ static void analogix_dp_psr_work(struct work_struct *work)
 		return;
 	}
 
-	spin_lock_irqsave(&dp->psr_lock, flags);
+	mutex_lock(&dp->psr_lock);
 	if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
 		analogix_dp_enable_psr(dp->dev);
 	else
 		analogix_dp_disable_psr(dp->dev);
-	spin_unlock_irqrestore(&dp->psr_lock, flags);
+	mutex_unlock(&dp->psr_lock);
 }
 
 static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
@@ -401,7 +399,7 @@ static int rockchip_dp_bind(struct device *dev, struct device *master,
 	dp->plat_data.power_off = rockchip_dp_powerdown;
 	dp->plat_data.get_modes = rockchip_dp_get_modes;
 
-	spin_lock_init(&dp->psr_lock);
+	mutex_init(&dp->psr_lock);
 	dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
 	INIT_WORK(&dp->psr_work, analogix_dp_psr_work);
 
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 8c8cbe8..5afd5a1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -157,7 +157,7 @@ static int rockchip_drm_bind(struct device *dev)
 	drm_dev->dev_private = private;
 
 	INIT_LIST_HEAD(&private->psr_list);
-	spin_lock_init(&private->psr_list_lock);
+	mutex_init(&private->psr_list_lock);
 
 	drm_mode_config_init(drm_dev);
 
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index fb6226c..095e178 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -62,7 +62,7 @@ struct rockchip_drm_private {
 	struct drm_atomic_state *state;
 
 	struct list_head psr_list;
-	spinlock_t psr_list_lock;
+	struct mutex psr_list_lock;
 };
 
 int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index 4c379e9..eb49f38 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -18,7 +18,7 @@
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_psr.h"
 
-#define PSR_FLUSH_TIMEOUT	msecs_to_jiffies(100)
+#define PSR_FLUSH_TIMEOUT_MS	100
 
 enum psr_state {
 	PSR_FLUSH,
@@ -30,11 +30,11 @@ struct psr_drv {
 	struct list_head	list;
 	struct drm_encoder	*encoder;
 
-	spinlock_t		lock;
+	struct mutex		lock;
 	bool			active;
 	enum psr_state		state;
 
-	struct timer_list	flush_timer;
+	struct delayed_work	flush_work;
 
 	void (*set)(struct drm_encoder *encoder, bool enable);
 };
@@ -43,9 +43,8 @@ static struct psr_drv *find_psr_by_crtc(struct drm_crtc *crtc)
 {
 	struct rockchip_drm_private *drm_drv = crtc->dev->dev_private;
 	struct psr_drv *psr;
-	unsigned long flags;
 
-	spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
+	mutex_lock(&drm_drv->psr_list_lock);
 	list_for_each_entry(psr, &drm_drv->psr_list, list) {
 		if (psr->encoder->crtc == crtc)
 			goto out;
@@ -53,7 +52,7 @@ static struct psr_drv *find_psr_by_crtc(struct drm_crtc *crtc)
 	psr = ERR_PTR(-ENODEV);
 
 out:
-	spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
+	mutex_unlock(&drm_drv->psr_list_lock);
 	return psr;
 }
 
@@ -61,9 +60,8 @@ static struct psr_drv *find_psr_by_encoder(struct drm_encoder *encoder)
 {
 	struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
 	struct psr_drv *psr;
-	unsigned long flags;
 
-	spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
+	mutex_lock(&drm_drv->psr_list_lock);
 	list_for_each_entry(psr, &drm_drv->psr_list, list) {
 		if (psr->encoder == encoder)
 			goto out;
@@ -71,7 +69,7 @@ static struct psr_drv *find_psr_by_encoder(struct drm_encoder *encoder)
 	psr = ERR_PTR(-ENODEV);
 
 out:
-	spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
+	mutex_unlock(&drm_drv->psr_list_lock);
 	return psr;
 }
 
@@ -112,23 +110,21 @@ static void psr_set_state_locked(struct psr_drv *psr, enum psr_state state)
 
 static void psr_set_state(struct psr_drv *psr, enum psr_state state)
 {
-	unsigned long flags;
-
-	spin_lock_irqsave(&psr->lock, flags);
+	mutex_lock(&psr->lock);
 	psr_set_state_locked(psr, state);
-	spin_unlock_irqrestore(&psr->lock, flags);
+	mutex_unlock(&psr->lock);
 }
 
-static void psr_flush_handler(unsigned long data)
+static void psr_flush_handler(struct work_struct *work)
 {
-	struct psr_drv *psr = (struct psr_drv *)data;
-	unsigned long flags;
+	struct psr_drv *psr = container_of(to_delayed_work(work),
+					   struct psr_drv, flush_work);
 
 	/* If the state has changed since we initiated the flush, do nothing */
-	spin_lock_irqsave(&psr->lock, flags);
+	mutex_lock(&psr->lock);
 	if (psr->state == PSR_FLUSH)
 		psr_set_state_locked(psr, PSR_ENABLE);
-	spin_unlock_irqrestore(&psr->lock, flags);
+	mutex_unlock(&psr->lock);
 }
 
 /**
@@ -141,14 +137,13 @@ static void psr_flush_handler(unsigned long data)
 int rockchip_drm_psr_activate(struct drm_encoder *encoder)
 {
 	struct psr_drv *psr = find_psr_by_encoder(encoder);
-	unsigned long flags;
 
 	if (IS_ERR(psr))
 		return PTR_ERR(psr);
 
-	spin_lock_irqsave(&psr->lock, flags);
+	mutex_lock(&psr->lock);
 	psr->active = true;
-	spin_unlock_irqrestore(&psr->lock, flags);
+	mutex_unlock(&psr->lock);
 
 	return 0;
 }
@@ -164,15 +159,14 @@ EXPORT_SYMBOL(rockchip_drm_psr_activate);
 int rockchip_drm_psr_deactivate(struct drm_encoder *encoder)
 {
 	struct psr_drv *psr = find_psr_by_encoder(encoder);
-	unsigned long flags;
 
 	if (IS_ERR(psr))
 		return PTR_ERR(psr);
 
-	spin_lock_irqsave(&psr->lock, flags);
+	mutex_lock(&psr->lock);
 	psr->active = false;
-	spin_unlock_irqrestore(&psr->lock, flags);
-	del_timer_sync(&psr->flush_timer);
+	mutex_unlock(&psr->lock);
+	cancel_delayed_work_sync(&psr->flush_work);
 
 	return 0;
 }
@@ -180,8 +174,7 @@ EXPORT_SYMBOL(rockchip_drm_psr_deactivate);
 
 static void rockchip_drm_do_flush(struct psr_drv *psr)
 {
-	mod_timer(&psr->flush_timer,
-		  round_jiffies_up(jiffies + PSR_FLUSH_TIMEOUT));
+	schedule_delayed_work(&psr->flush_work, PSR_FLUSH_TIMEOUT_MS);
 	psr_set_state(psr, PSR_FLUSH);
 }
 
@@ -219,12 +212,11 @@ void rockchip_drm_psr_flush_all(struct drm_device *dev)
 {
 	struct rockchip_drm_private *drm_drv = dev->dev_private;
 	struct psr_drv *psr;
-	unsigned long flags;
 
-	spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
+	mutex_lock(&drm_drv->psr_list_lock);
 	list_for_each_entry(psr, &drm_drv->psr_list, list)
 		rockchip_drm_do_flush(psr);
-	spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
+	mutex_unlock(&drm_drv->psr_list_lock);
 }
 EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
 
@@ -241,7 +233,6 @@ int rockchip_drm_psr_register(struct drm_encoder *encoder,
 {
 	struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
 	struct psr_drv *psr;
-	unsigned long flags;
 
 	if (!encoder || !psr_set)
 		return -EINVAL;
@@ -250,17 +241,17 @@ int rockchip_drm_psr_register(struct drm_encoder *encoder,
 	if (!psr)
 		return -ENOMEM;
 
-	setup_timer(&psr->flush_timer, psr_flush_handler, (unsigned long)psr);
-	spin_lock_init(&psr->lock);
+	INIT_DELAYED_WORK(&psr->flush_work, psr_flush_handler);
+	mutex_init(&psr->lock);
 
 	psr->active = true;
 	psr->state = PSR_DISABLE;
 	psr->encoder = encoder;
 	psr->set = psr_set;
 
-	spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
+	mutex_lock(&drm_drv->psr_list_lock);
 	list_add_tail(&psr->list, &drm_drv->psr_list);
-	spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
+	mutex_unlock(&drm_drv->psr_list_lock);
 
 	return 0;
 }
@@ -278,16 +269,15 @@ void rockchip_drm_psr_unregister(struct drm_encoder *encoder)
 {
 	struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
 	struct psr_drv *psr, *n;
-	unsigned long flags;
 
-	spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
+	mutex_lock(&drm_drv->psr_list_lock);
 	list_for_each_entry_safe(psr, n, &drm_drv->psr_list, list) {
 		if (psr->encoder == encoder) {
-			del_timer(&psr->flush_timer);
+			cancel_delayed_work_sync(&psr->flush_work);
 			list_del(&psr->list);
 			kfree(psr);
 		}
 	}
-	spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
+	mutex_unlock(&drm_drv->psr_list_lock);
 }
 EXPORT_SYMBOL(rockchip_drm_psr_unregister);
-- 
2.8.0.rc3.226.g39d4020



From dianders at chromium.org  Tue Oct 18 13:29:09 2016
From: dianders at chromium.org (Doug Anderson)
Date: Tue, 18 Oct 2016 13:29:09 -0700
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <CAGS+omAT5gFD3vF7iz=Mc=CO00W_x2MSyGdpgD+tO2YfGnwpsA@mail.gmail.com>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
 <CAGS+omAT5gFD3vF7iz=Mc=CO00W_x2MSyGdpgD+tO2YfGnwpsA@mail.gmail.com>
Message-ID: <CAD=FV=UHB4sqf9sAg6Pbrp67sgjwJRUFPKsEh_PXwUCM+o59ZQ@mail.gmail.com>

Dan,

On Tue, Oct 18, 2016 at 6:44 AM, Daniel Kurtz <djkurtz at chromium.org> wrote:
> Hi Doug,
>
> On Tue, Oct 11, 2016 at 5:04 AM, Douglas Anderson <dianders at chromium.org> wrote:
>> Users of usleep_range() expect that it will _never_ return in less time
>> than the minimum passed parameter.  However, nothing in any of the code
>> ensures this.  Specifically:
>>
>> usleep_range() => do_usleep_range() => schedule_hrtimeout_range() =>
>> schedule_hrtimeout_range_clock() just ends up calling schedule() with an
>> appropriate timeout set using the hrtimer.  If someone else happens to
>> wake up our task then we'll happily return from usleep_range() early.
>
> I think this change works, and fixes a real issue, however, I don't
> think you are fixing this at the right layer.
> The comment for schedule_hrtimeout_range says:
>
> /**
>  * schedule_hrtimeout_range - sleep until timeout
>  * @expires:    timeout value (ktime_t)
>  * @delta:      slack in expires timeout (ktime_t)
>  * @mode:       timer mode, HRTIMER_MODE_ABS or HRTIMER_MODE_REL
>  *
>  * Make the current task sleep until the given expiry time has
>  * elapsed. The routine will return immediately unless
>  * the current task state has been set (see set_current_state()).
>  *
>  * The @delta argument gives the kernel the freedom to schedule the
>  * actual wakeup to a time that is both power and performance friendly.
>  * The kernel give the normal best effort behavior for "@expires+ at delta",
>  * but may decide to fire the timer earlier, but no earlier than @expires.
>  *
>  * You can set the task state as follows -
>  *
>  * %TASK_UNINTERRUPTIBLE - at least @timeout time is guaranteed to
>  * pass before the routine returns.
>  *
>  * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
>  * delivered to the current task.
>  *
>  * The current task state is guaranteed to be TASK_RUNNING when this
>  * routine returns.
>  *
>  * Returns 0 when the timer has expired otherwise -EINTR
>  */
>
> The behavior as specified for this function "at least @timeout time is
> guaranteed to pass before the routine returns" already guarantees the
> behavior you are adding to do_usleep_range() whenever the current task
> state is (pre-)set to TASK_UNINTERRUPTIBLE.
>
> Thus, I think the loop around 'schedule()' should be moved to
> schedule_hrtimeout_range() itself.
> This would also fix direct callers of schedule_hrtimeout_range() that
> use TASK_UNINTERRUPTIBLE, although, I could only find one:
>
> pt3_fetch_thread()

Hmmm, I would agree with you that the behavior of
schedule_hrtimeout_range() doesn't seem to match the function
comments.

...but I'm not sure I agree with you about what to do here.
Specifically I think that whatever we do we need to try to keep
schedule_hrtimeout_range() and schedule_timeout() parallel.  For
schedule_timeout() we have the same comments but it's my understanding
that you'd expect that wake_up_process() would wake it up.  In any
case, if wake_up_process() doesn't wake it up then it seems like
msleep() and schedule_timeout_uninterruptible() are the same function
with two names, when in fact one is implemented in terms o the other.

NOTE that also it seems as if we need some other return values besides
0 and -EINTR from schedule_hrtimeout_range() (again, to match
schedule_timeout()) since right now we'll return -EINTR if we were
woken up with wake_up_process().  This would be unexpected in the case
where we had TASK_UNINTERRUPTIBLE set.

-Doug


From contact at paulk.fr  Tue Oct 18 14:00:17 2016
From: contact at paulk.fr (Paul Kocialkowski)
Date: Tue, 18 Oct 2016 23:00:17 +0200
Subject: [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200
 speed from rk3288-veyron-speedy.
In-Reply-To: <12872023.2LumKfgYDl@diego>
References: <87twd1vzc5.fsf@aikidev.net> <1476647383.3885.3.camel@paulk.fr>
 <12872023.2LumKfgYDl@diego>
Message-ID: <1476824417.1031.9.camel@paulk.fr>

Hi,

Le mardi 18 octobre 2016 ? 11:21 +0200, Heiko St?bner a ?crit?:
> Am Sonntag, 16. Oktober 2016, 21:49:43 schrieb Paul Kocialkowski:
> > 
> > Hi,
> > 
> > Le mardi 27 septembre 2016 ? 13:53 -0700, Vagrant Cascadian a ?crit :
> > > 
> > > This essentially mimics what was done with rk3288-veyron-minnie in
> > > commit 984926781122f034d5bc9962815d135b6c4a8e1d.
> > > 
> > > The eMMC of the speedy Chromebook also appears to need the same tuning
> > > workaround, as it frequently fails to recognize the eMMC without it.
> > 
> > I have a device where (without this patch) eMMC sometimes fails, with:
> > [????3.561010] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to
> > 175 [????3.571742] mmc2: new HS200 MMC card at address 0001
> > [????3.571943] mmcblk2: mmc2:0001 HAG2e 14.7 GiB?
> > [????3.572026] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
> > [????3.572107] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
> > [????3.572181] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
> > [????3.685647] mmcblk2: error -110 transferring data, sector 0, nr 8, cmd
> > response 0x900, card status 0x0
> > 
> > And sometimes works, with:
> > [????3.451058] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to
> > 176 [????3.491093] mmc2: new HS200 MMC card at address 0001
> > [????3.491277] mmcblk2: mmc2:0001 HAG2e 14.7 GiB?
> > [????3.491345] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
> > [????3.491409] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
> > [????3.491474] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
> > [????3.493548]??mmcblk2: p1 p2
> > 
> > However, with this change, it always fails, with:
> > [????3.322129] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req
> > 52000000Hz, actual 50000000HZ div = 0) [????3.333174] mmc2: error -110
> > whilst initialising MMC card
> > 
> > I don't have so much time to investigate this issue, but it's clear that
> > this patch doesn't fix the issue (and actually worsens it) for my device.
> 
> thanks for the heads up.
> 
> As discussed on IRC we now have varying reports of the emmc working or not?
> working with and without that patch applied. So it's not really a bandaid fix?
> and I've thus dropped this patch again.

Thanks for dropping it! For the record, my eMMC shows up as:
mmcblk2: mmc2:0001 HAG2e 14.7 GiB

Maybe it could help to share what each tested device reports as eMMC model and
associate that with the current behavior, in spite of getting a clearer idea of
what issue affects what model.

> Still hoping someone will find the source of the problem somewhere :-)

I have started investigating the issue, but did not discover anything
significant yet. I hope I'll be able to figure it out!

Cheers!

-- 
Paul Kocialkowski, developer of free digital technology at the lower levels

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20161018/1250804a/attachment.sig>

From khilman at baylibre.com  Tue Oct 18 14:14:18 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Tue, 18 Oct 2016 14:14:18 -0700
Subject: [PATCH] PM / AVS: rockchip-io: make the log more consistent
In-Reply-To: <1883054.D2Rm2X9N2G@phil> (Heiko Stuebner's message of "Mon, 10
 Oct 2016 22:15:50 +0200")
References: <1476103462-7559-1-git-send-email-shawn.lin@rock-chips.com>
 <1883054.D2Rm2X9N2G@phil>
Message-ID: <7heg3d9x79.fsf@baylibre.com>

Heiko Stuebner <heiko at sntech.de> writes:

> Am Montag, 10. Oktober 2016, 20:44:22 CEST schrieb Shawn Lin:
>> When testing SD hotplug automatically, I got bunch of
>> useless log like this:
>> 
>> [  588.357838] mmc0: card 0007 removed
>> [  589.492664] rockchip-iodomain ff770000.syscon:io-domains: Setting to
>> 3300000 done [  589.500698] vccio_sd: ramp_delay not set
>> [  589.504817] rockchip-iodomain ff770000.syscon:io-domains: Setting to
>> 3300000 done [  589.669705] rockchip-iodomain ff770000.syscon:io-domains:
>> Setting to 3300000 done [  589.677593] vccio_sd: ramp_delay not set
>> [  589.681581] rockchip-iodomain ff770000.syscon:io-domains: Setting to
>> 1800000 done [  590.032820] dwmmc_rockchip ff0c0000.dwmmc: Successfully
>> tuned phase to 140 [  590.039725] mmc0: new ultra high speed SDR50 SDHC
>> card at address 0007 [  590.046641] mmcblk0: mmc0:0007 SD32G 29.3 GiB
>> [  590.052163]  mmcblk0: p1
>> 
>> Moreover the code is intent to print the 'uV' for debug but
>> later print it using dev_info. It looks more like to me that
>> it should be the real intention of the code. Anyway, let's
>> mark this verbose log as debug message.
>> 
>> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>
> reducing the amount of logs, especially for information not generally needed 
> looks sane
>
> Reviewed-by: Heiko Stuebner <heiko at sntech.de>

Acked-by: Kevin Hilman <khilman at baylibre.com>

Rafael, feel free to apply directly as a fix for v4.9-rc, or wait for
v4.10 if you prefer.

Kevin


From briannorris at chromium.org  Tue Oct 18 15:57:05 2016
From: briannorris at chromium.org (Brian Norris)
Date: Tue, 18 Oct 2016 15:57:05 -0700
Subject: [PATCH 2/2] PCI: rockchip: fix wrong transmitted FTS count
In-Reply-To: <1474596360-23483-2-git-send-email-shawn.lin@rock-chips.com>
References: <1474596360-23483-1-git-send-email-shawn.lin@rock-chips.com>
 <1474596360-23483-2-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <20161018225703.GA114318@google.com>

On Fri, Sep 23, 2016 at 10:06:00AM +0800, Shawn Lin wrote:
> If the expected numbers of FTS aren't recevied by RC when
> exiting from L0s, the LTSSM will fall into recover state.
> So it will need to send TS for retraining which makes the
> latency of exiting from L0s a little longer than expected.
> This issue is caused by the wrong reset value of FTS count
> on PLC1 register(offset 0x4). The expected value for Gen1/2
> should be more than 240 and we may leave a little margin here.
> Let's fix this before starting Gen1 traning which will makes
> TS1 contains the correct FTS count.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> ---
> 
>  drivers/pci/host/pcie-rockchip.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index 5e51121..6a7a9df 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -95,6 +95,10 @@
>  #define   PCIE_CORE_PL_CONF_SPEED_MASK		0x00000018
>  #define   PCIE_CORE_PL_CONF_LANE_MASK		0x00000006
>  #define   PCIE_CORE_PL_CONF_LANE_SHIFT		1
> +#define PCIE_CORE_CTRL_PLC1		(PCIE_CORE_CTRL_MGMT_BASE + 0x004)
> +#define   PCIE_CORE_CTRL_PLC1_FTS_MASK		GENMASK(23, 8)

^^^ That's 0x00ffff00, isn't it?

> +#define   PCIE_CORE_CTRL_PLC1_FTS_SHIFT	8
> +#define   PCIE_CORE_CTRL_PLC1_FTS_CNT		0xffff
>  #define PCIE_CORE_INT_STATUS		(PCIE_CORE_CTRL_MGMT_BASE + 0x20c)
>  #define   PCIE_CORE_INT_PRFPE			BIT(0)
>  #define   PCIE_CORE_INT_CRFPE			BIT(1)
> @@ -470,6 +474,12 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
>  	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
>  
> +	/* Fix the transmitted FTS count desired to exit from L0s. */
> +	status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL_PLC1);
> +	status = (status & PCIE_CORE_CTRL_PLC1_FTS_MASK) |

^^^ That's not the way to use this then, is it? We want

	(status & ~PCIE_CORE_CTRL_PLC1_FTS_MASK) | ...

Fortunately the lowest 8 bits default to 0, and the highest 8 bits are
for 8GT/s operation (not used).

This is already upstream, so I guess we need a follow-up.

Brian

> +		 (PCIE_CORE_CTRL_PLC1_FTS_CNT << PCIE_CORE_CTRL_PLC1_FTS_SHIFT);
> +	rockchip_pcie_write(rockchip, status, PCIE_CORE_CTRL_PLC1);
> +
>  	/* Enable Gen1 training */
>  	rockchip_pcie_write(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
>  			    PCIE_CLIENT_CONFIG);
> -- 
> 2.3.7
> 
> 


From briannorris at chromium.org  Tue Oct 18 16:13:04 2016
From: briannorris at chromium.org (Brian Norris)
Date: Tue, 18 Oct 2016 16:13:04 -0700
Subject: [PATCH] PCI: rockchip: correct the use of FTS mask
Message-ID: <1476832384-10215-1-git-send-email-briannorris@chromium.org>

We're trying to mask out bits[23:8] while retaining [32:24, 7:0], but
we're doing the inverse. That doesn't have too much effect, since we're
setting all the [23:8] bits to 1, and the other bits are only relevant
for modes we're currently not using. But we should get this right.

Fixes: ca1989084054 ("PCI: rockchip: Fix wrong transmitted FTS count")
Signed-off-by: Brian Norris <briannorris at chromium.org>
---
 drivers/pci/host/pcie-rockchip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index e0b22dab9b7a..5c2e3297a3ff 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -492,7 +492,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 
 	/* Fix the transmitted FTS count desired to exit from L0s. */
 	status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL_PLC1);
-	status = (status & PCIE_CORE_CTRL_PLC1_FTS_MASK) |
+	status = (status & ~PCIE_CORE_CTRL_PLC1_FTS_MASK) |
 		 (PCIE_CORE_CTRL_PLC1_FTS_CNT << PCIE_CORE_CTRL_PLC1_FTS_SHIFT);
 	rockchip_pcie_write(rockchip, status, PCIE_CORE_CTRL_PLC1);
 
-- 
2.8.0.rc3.226.g39d4020



From ayaka at soulik.info  Tue Oct 18 18:17:01 2016
From: ayaka at soulik.info (Ayaka)
Date: Wed, 19 Oct 2016 09:17:01 +0800
Subject: question about [RESEND PATCH v7 0/4] the fix for the USB HOST1 at
 rk3288 platform
In-Reply-To: <CALd3UbQqw8VREZwkjPoPyk9SGnE0X0yi7W6wOU7DT88m4si=LA@mail.gmail.com>
References: <CALd3UbT=cxsNnW+aUoAtdWRsj3L4azF17L9c+znfQn_Vz3PzkQ@mail.gmail.com>
 <9b4a7c5f-a78b-26a6-8112-b6439cf3f224@soulik.info>
 <CALd3UbQ=wr7p_RjEJ5xBUCSmGOkH1kcM+zcfYzMDpD5Nxeur7Q@mail.gmail.com>
 <CALd3UbS7xe=5g+UbmGMY70dS8Rxeq8w10ZwBUz1ejY+R9zGy+A@mail.gmail.com>
 <CALd3UbQqw8VREZwkjPoPyk9SGnE0X0yi7W6wOU7DT88m4si=LA@mail.gmail.com>
Message-ID: <53425EB5-B46A-459C-BC99-7410C1CEEC4D@soulik.info>



??? iPad ??

> Bert Schiettecatte <bert at bertschiettecatte.com> ? 2016?10?19? ??3:33 ???
> 
> Hi Randy
> 
> I just noticed there is no LVDS driver yet -
> ./drivers/gpu/drm/rockchip/rockchip_lvds.c is missing, so I can't
why not, it exists.
> compile your .dts with my lvds changes.
> 
> Do you know how I can add the LVDS driver? If you give me a starting
> point I can work on it.
> 
> Thanks
> 
> Bert
> 
> 
> On Tue, Oct 18, 2016 at 9:16 PM, Bert Schiettecatte
> <bert at bertschiettecatte.com> wrote:
>> Hi Randy
>> 
>> I checked out your branch and USB works when I connect a mouse,
>> thanks! I then connected some other generic HID device and I got this:
>> 
>> [  543.353890] usb 1-1.3: new full-speed USB device number 10 using dwc2
>> [  543.468669] hid-generic 0003:16C0:07BC.0008: device has no
>> listeners, quitting
>> 
>> This is not an error, correct?
>> 
>> Thanks
>> Bert
>> 
>> 
>> On Tue, Oct 18, 2016 at 7:28 PM, Bert Schiettecatte
>> <bert at bertschiettecatte.com> wrote:
>>> OK, the patch is already applied there, right?
>>> 
>>>> On Tue, Oct 18, 2016 at 7:21 PM, ayaka <ayaka at soulik.info> wrote:
>>>> 
>>>> 
>>>> On 10/18/2016 10:06 PM, Bert Schiettecatte wrote:
>>>> 
>>>> Hi Randy
>>>> 
>>>> Hope you are well?
>>>> 
>>>> Meanwhile I solved my SD / LVDS problems. I have LVDS output and can boot
>>>> from SD.
>>>> 
>>>> Unfortunately there seems to be an issue with USB.  When I plug in a mouse
>>>> to one of the USB ports on the reload board I get this:
>>>> 
>>>> ...
>>>> [    3.431863] usb 1-1.3.2: Product: USB Optical Mouse
>>>> [    3.436737] usb 1-1.3.2: Manufacturer: Logitech
>>>> [    3.443943] input: Logitech USB Optical Mouse as
>>>> /devices/platform/ff540000.usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:046D:C077.0001/input/input0
>>>> [    3.457352] hid-generic 0003:046D:C077.0001: input,hidraw0: USB HID
>>>> v1.11 Mouse [Logitech USB Optical Mouse] on
>>>> usb-ff540000.usb-1.3.2/input0
>>>> [    4.588211] usb usb1-port1: disabled by hub (EMI?), re-enabling...
>>>> [    4.595848] usb 1-1: USB disconnect, device number 2
>>>> [    4.602261] usb 1-1.3: USB disconnect, device number 3
>>>> [    4.608815] usb 1-1.3.1: USB disconnect, device number 4
>>>> [    4.615884] usb 1-1.3.2: USB disconnect, device number 5
>>>> [    6.058190] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
>>>> [    7.318273] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
>>>> [    8.568319] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
>>>> [    9.828165] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
>>>> [    9.835164] usb usb1-port1: unable to enumerate USB device
>>>> root at linaro-alip:~#
>>>> 
>>>> Jacob already pointed me at your patch set [RESEND PATCH v7 0/4] the fix for
>>>> the USB HOST1 at rk3288 platform but I want to ask if these patches are
>>>> already finished, and what repository and branch you applied them to?
>>>> 
>>>> I am currently using release-4.4 from the rockchip repository on github. I
>>>> tried applying your patches but got several errors, so just want to double
>>>> check with you.
>>>> 
>>>> For the upstream, try this
>>>> https://github.com/hizukiayaka/linux-kernel/tree/firefly-rk3288-reload-next
>>>> 
>>>> 
>>>> Thanks for your help and patience,
>>>> Bert
>>>> 
>>>> 



From sboyd at codeaurora.org  Tue Oct 18 18:24:41 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 18 Oct 2016 18:24:41 -0700
Subject: [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in
 suspend
In-Reply-To: <20161004174903.GA3098@localhost>
References: <20160916054917.16930-1-briannorris@chromium.org>
 <57DBA81F.2060404@arm.com> <20160919231441.GA60928@google.com>
 <57E0E97B.5000106@arm.com> <20160928012309.GA29518@localhost>
 <20160929170847.1227a312@arm.com> <20161004174903.GA3098@localhost>
Message-ID: <20161019012441.GW8871@codeaurora.org>

On 10/04, Brian Norris wrote:
> Hi Marc,
> 
> On Thu, Sep 29, 2016 at 05:08:47PM +0100, Marc Zyngier wrote:
> > On Tue, 27 Sep 2016 18:23:11 -0700
> > Brian Norris <briannorris at chromium.org> wrote:
> > > On Tue, Sep 20, 2016 at 08:47:07AM +0100, Marc Zyngier wrote:
> > > <Begin side note>
> > > rk3288 (ARMv7 system widely used for our Chromebooks) has the same
> > > issue, except the kernel we're using for production (based on v3.14)
> > > doesn't have the following commit, which stopped utilizing the RTC:
> > > 
> > > commit 0fa88cb4b82b5cf7429bc1cef9db006ca035754e
> > > Author: Xunlei Pang <pang.xunlei at linaro.org>
> > > Date:   Wed Apr 1 20:34:38 2015 -0700
> > > 
> > >     time, drivers/rtc: Don't bother with rtc_resume() for the nonstop clocksource
> > > 
> > > And any mainline testing on rk3288 doesn't see the problem, because
> > > mainline doesn't support its lowest-power sleep modes well enough (see
> > > ROCKCHIP_ARM_OFF_LOGIC_DEEP in arch/arm/mach-rockchip/pm.c).
> > 
> > Arghh... So even my favourite Chromebook (from which I'm typing this
> > email) is affected? Not very nice...
> 
> Yep. But if you're running mainline, you just get to have high S3 power
> consumption instead!

Just curious, do we enter this state during cpuidle as well? Or
is it only across suspend that the clock stops working?

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


From briannorris at chromium.org  Tue Oct 18 18:36:13 2016
From: briannorris at chromium.org (Brian Norris)
Date: Tue, 18 Oct 2016 18:36:13 -0700
Subject: [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in
 suspend
In-Reply-To: <20161019012441.GW8871@codeaurora.org>
References: <20160916054917.16930-1-briannorris@chromium.org>
 <57DBA81F.2060404@arm.com> <20160919231441.GA60928@google.com>
 <57E0E97B.5000106@arm.com> <20160928012309.GA29518@localhost>
 <20160929170847.1227a312@arm.com> <20161004174903.GA3098@localhost>
 <20161019012441.GW8871@codeaurora.org>
Message-ID: <20161019013612.GA107490@google.com>

On Tue, Oct 18, 2016 at 06:24:41PM -0700, Stephen Boyd wrote:
> Just curious, do we enter this state during cpuidle as well? Or
> is it only across suspend that the clock stops working?

I believe we do not on either rk3288 or rk3399. We'd have to be powering
off almost the entire system before we'd be able to gate the 24 MHz
oscillator, AIUI.

Brian


From sboyd at codeaurora.org  Tue Oct 18 18:55:37 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 18 Oct 2016 18:55:37 -0700
Subject: [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in
 suspend
In-Reply-To: <20161019013612.GA107490@google.com>
References: <20160916054917.16930-1-briannorris@chromium.org>
 <57DBA81F.2060404@arm.com> <20160919231441.GA60928@google.com>
 <57E0E97B.5000106@arm.com> <20160928012309.GA29518@localhost>
 <20160929170847.1227a312@arm.com> <20161004174903.GA3098@localhost>
 <20161019012441.GW8871@codeaurora.org> <20161019013612.GA107490@google.com>
Message-ID: <86354ffe-9757-2a1f-92c9-9602fa08a057@codeaurora.org>

On 10/18/2016 06:36 PM, Brian Norris wrote:
> I believe we do not on either rk3288 or rk3399. We'd have to be powering
> off almost the entire system before we'd be able to gate the 24 MHz
> oscillator, AIUI.
>

Great! That avoids a major headache.

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



From vagrantc at aikidev.net  Tue Oct 18 20:42:44 2016
From: vagrantc at aikidev.net (Vagrant Cascadian)
Date: Tue, 18 Oct 2016 20:42:44 -0700
Subject: [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200
 speed from rk3288-veyron-speedy.
In-Reply-To: <1476824417.1031.9.camel@paulk.fr>
References: <87twd1vzc5.fsf@aikidev.net> <1476647383.3885.3.camel@paulk.fr>
 <12872023.2LumKfgYDl@diego> <1476824417.1031.9.camel@paulk.fr>
Message-ID: <878ttl9f7v.fsf@aikidev.net>

On 2016-10-18, Paul Kocialkowski wrote:
> Le mardi 18 octobre 2016 ? 11:21 +0200, Heiko St?bner a ?crit?:
>> Am Sonntag, 16. Oktober 2016, 21:49:43 schrieb Paul Kocialkowski:
>> > Le mardi 27 septembre 2016 ? 13:53 -0700, Vagrant Cascadian a ?crit :
>> > > 
>> > > This essentially mimics what was done with rk3288-veyron-minnie in
>> > > commit 984926781122f034d5bc9962815d135b6c4a8e1d.
>> > > 
>> > > The eMMC of the speedy Chromebook also appears to need the same tuning
>> > > workaround, as it frequently fails to recognize the eMMC without it.
>> > 
>> > I have a device where (without this patch) eMMC sometimes fails, with:
>> > [????3.561010] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to
>> > 175 [????3.571742] mmc2: new HS200 MMC card at address 0001
>> > [????3.571943] mmcblk2: mmc2:0001 HAG2e 14.7 GiB?
>> > [????3.572026] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
>> > [????3.572107] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
>> > [????3.572181] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
>> > [????3.685647] mmcblk2: error -110 transferring data, sector 0, nr 8, cmd
>> > response 0x900, card status 0x0

>> > And sometimes works, with:
>> > [????3.451058] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to
>> > 176 [????3.491093] mmc2: new HS200 MMC card at address 0001
>> > [????3.491277] mmcblk2: mmc2:0001 HAG2e 14.7 GiB?
>> > [????3.491345] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
>> > [????3.491409] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
>> > [????3.491474] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
>> > [????3.493548]??mmcblk2: p1 p2

This is similar behavior to my veyron-speedy. Here are several boot logs
From running 4.8.0-rc7, with some failures and some successes:

  https://cascadia.aikidev.net/~vagrant/veyron-speedy/


>> > However, with this change, it always fails, with:
>> > [????3.322129] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req
>> > 52000000Hz, actual 50000000HZ div = 0) [????3.333174] mmc2: error -110
>> > whilst initialising MMC card
>> > 
>> > I don't have so much time to investigate this issue, but it's clear that
>> > this patch doesn't fix the issue (and actually worsens it) for my device.

Well, that makes things more complicated.


>> As discussed on IRC we now have varying reports of the emmc working or not?
>> working with and without that patch applied. So it's not really a bandaid fix?
>> and I've thus dropped this patch again.
>
> Thanks for dropping it! For the record, my eMMC shows up as:
> mmcblk2: mmc2:0001 HAG2e 14.7 GiB

Mine looks similar, although reporting as mmc0:

  [    3.166550] mmcblk0: mmc0:0001 HAG2e 14.7 GiB


> Maybe it could help to share what each tested device reports as eMMC model and
> associate that with the current behavior, in spite of getting a clearer idea of
> what issue affects what model.

FWIW, I'm using a veyron-speedy with 4GB of ram, not sure what other
information might be useful to distinguish between different models.

On the bottom of the case, it claims to be a C201P. Near the serial,
it's marked as C201PA-DS02-LG.


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20161018/643b245b/attachment.sig>

From shawn.lin at rock-chips.com  Wed Oct 19 02:10:34 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 19 Oct 2016 17:10:34 +0800
Subject: [PATCH] PCI: rockchip: remove the pointer to L1 substate cap
Message-ID: <1476868234-15135-1-git-send-email-shawn.lin@rock-chips.com>

Per the errata of TRM, the RC can't support L1 substate, so we
need to remove the L1 substate cap.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/pci/host/pcie-rockchip.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index e0b22da..8370a85 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -142,6 +142,8 @@
 #define   PCIE_RC_CONFIG_LCS_LBMS		BIT(30)
 #define   PCIE_RC_CONFIG_LCS_LAMS		BIT(31)
 #define PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 (PCIE_RC_CONFIG_BASE + 0x90c)
+#define PCIE_RC_CONFIG_THP_CAP		(PCIE_RC_CONFIG_BASE + 0x274)
+#define   PCIE_RC_CONFIG_THP_CAP_NEXT_MASK	GENMASK(31, 20)
 
 #define PCIE_CORE_AXI_CONF_BASE		0xc00000
 #define PCIE_CORE_OB_REGION_ADDR0	(PCIE_CORE_AXI_CONF_BASE + 0x0)
@@ -558,6 +560,12 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 	rockchip_pcie_write(rockchip,
 			    PCI_CLASS_BRIDGE_PCI << PCIE_RC_CONFIG_SCC_SHIFT,
 			    PCIE_RC_CONFIG_RID_CCR);
+
+	/* Clear THP cap's next cap pointer to remove L1 substate cap */
+	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_THP_CAP);
+	status &= ~PCIE_RC_CONFIG_THP_CAP_NEXT_MASK;
+	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_THP_CAP);
+
 	rockchip_pcie_write(rockchip, 0x0, PCIE_RC_BAR_CONF);
 
 	rockchip_pcie_write(rockchip,
-- 
2.3.7




From rmk+kernel at armlinux.org.uk  Wed Oct 19 03:28:27 2016
From: rmk+kernel at armlinux.org.uk (Russell King)
Date: Wed, 19 Oct 2016 11:28:27 +0100
Subject: [PATCH] drm: convert DT component matching to
 component_match_add_release()
Message-ID: <E1bwo6l-0005Io-Q1@rmk-PC.armlinux.org.uk>

Convert DT component matching to use component_match_add_release().

Signed-off-by: Russell King <rmk+kernel at armlinux.org.uk>
---
Can we please get this patch from May merged into the drm-misc or
whatever trees so that we don't end up with conflicts?  I've no idea
who looks after drm-misc, as they have _still_ failed to add
themselves to MAINTAINERS.

 drivers/gpu/drm/arm/hdlcd_drv.c                 |  3 ++-
 drivers/gpu/drm/arm/malidp_drv.c                |  4 +++-
 drivers/gpu/drm/armada/armada_drv.c             |  2 +-
 drivers/gpu/drm/drm_of.c                        | 28 +++++++++++++++++++++++--
 drivers/gpu/drm/etnaviv/etnaviv_drv.c           |  5 +++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  7 ++++---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c          |  4 +++-
 drivers/gpu/drm/msm/msm_drv.c                   | 12 ++++++-----
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c     |  6 ++++--
 drivers/gpu/drm/sti/sti_drv.c                   |  5 +++--
 drivers/gpu/drm/sun4i/sun4i_drv.c               |  3 ++-
 drivers/gpu/drm/tilcdc/tilcdc_external.c        |  4 +++-
 include/drm/drm_of.h                            | 12 +++++++++++
 13 files changed, 73 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index fb6a418ce6be..6477d1a65266 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -453,7 +453,8 @@ static int hdlcd_probe(struct platform_device *pdev)
 		return -EAGAIN;
 	}
 
-	component_match_add(&pdev->dev, &match, compare_dev, port);
+	drm_of_component_match_add(&pdev->dev, &match, compare_dev, port);
+	of_node_put(port);
 
 	return component_master_add_with_match(&pdev->dev, &hdlcd_master_ops,
 					       match);
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 9280358b8f15..9f4739452a25 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -493,7 +493,9 @@ static int malidp_platform_probe(struct platform_device *pdev)
 		return -EAGAIN;
 	}
 
-	component_match_add(&pdev->dev, &match, malidp_compare_dev, port);
+	drm_of_component_match_add(&pdev->dev, &match, malidp_compare_dev,
+				   port);
+	of_node_put(port);
 	return component_master_add_with_match(&pdev->dev, &malidp_master_ops,
 					       match);
 }
diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
index 1e0e68f608e4..94e46da9a758 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -254,7 +254,7 @@ static void armada_add_endpoints(struct device *dev,
 			continue;
 		}
 
-		component_match_add(dev, match, compare_of, remote);
+		drm_of_component_match_add(dev, match, compare_of, remote);
 		of_node_put(remote);
 	}
 }
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index bc98bb94264d..47848ed8ca48 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -6,6 +6,11 @@
 #include <drm/drm_crtc.h>
 #include <drm/drm_of.h>
 
+static void drm_release_of(struct device *dev, void *data)
+{
+	of_node_put(data);
+}
+
 /**
  * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
  * @dev: DRM device
@@ -64,6 +69,24 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
 EXPORT_SYMBOL(drm_of_find_possible_crtcs);
 
 /**
+ * drm_of_component_match_add - Add a component helper OF node match rule
+ * @master: master device
+ * @matchptr: component match pointer
+ * @compare: compare function used for matching component
+ * @node: of_node
+ */
+void drm_of_component_match_add(struct device *master,
+				struct component_match **matchptr,
+				int (*compare)(struct device *, void *),
+				struct device_node *node)
+{
+	of_node_get(node);
+	component_match_add_release(master, matchptr, drm_release_of,
+				    compare, node);
+}
+EXPORT_SYMBOL_GPL(drm_of_component_match_add);
+
+/**
  * drm_of_component_probe - Generic probe function for a component based master
  * @dev: master device containing the OF node
  * @compare_of: compare function used for matching components
@@ -101,7 +124,7 @@ int drm_of_component_probe(struct device *dev,
 			continue;
 		}
 
-		component_match_add(dev, &match, compare_of, port);
+		drm_of_component_match_add(dev, &match, compare_of, port);
 		of_node_put(port);
 	}
 
@@ -140,7 +163,8 @@ int drm_of_component_probe(struct device *dev,
 				continue;
 			}
 
-			component_match_add(dev, &match, compare_of, remote);
+			drm_of_component_match_add(dev, &match, compare_of,
+						   remote);
 			of_node_put(remote);
 		}
 		of_node_put(port);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index aa687669e22b..0dee6acbd880 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -16,6 +16,7 @@
 
 #include <linux/component.h>
 #include <linux/of_platform.h>
+#include <drm/drm_of.h>
 
 #include "etnaviv_drv.h"
 #include "etnaviv_gpu.h"
@@ -629,8 +630,8 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
 			if (!core_node)
 				break;
 
-			component_match_add(&pdev->dev, &match, compare_of,
-					    core_node);
+			drm_of_component_match_add(&pdev->dev, &match,
+						   compare_of, core_node);
 			of_node_put(core_node);
 		}
 	} else if (dev->platform_data) {
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 90377a609c98..e88fde18c946 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -24,6 +24,7 @@
 #include <drm/drm_fb_cma_helper.h>
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_crtc_helper.h>
+#include <drm/drm_of.h>
 
 #include "kirin_drm_drv.h"
 
@@ -260,14 +261,13 @@ static struct device_node *kirin_get_remote_node(struct device_node *np)
 		DRM_ERROR("no valid endpoint node\n");
 		return ERR_PTR(-ENODEV);
 	}
-	of_node_put(endpoint);
 
 	remote = of_graph_get_remote_port_parent(endpoint);
+	of_node_put(endpoint);
 	if (!remote) {
 		DRM_ERROR("no valid remote node\n");
 		return ERR_PTR(-ENODEV);
 	}
-	of_node_put(remote);
 
 	if (!of_device_is_available(remote)) {
 		DRM_ERROR("not available for remote node\n");
@@ -294,7 +294,8 @@ static int kirin_drm_platform_probe(struct platform_device *pdev)
 	if (IS_ERR(remote))
 		return PTR_ERR(remote);
 
-	component_match_add(dev, &match, compare_of, remote);
+	drm_of_component_match_add(dev, &match, compare_of, remote);
+	of_node_put(remote);
 
 	return component_master_add_with_match(dev, &kirin_drm_ops, match);
 
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index cf83f6507ec8..9c5430fb82a2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -18,6 +18,7 @@
 #include <drm/drm_crtc_helper.h>
 #include <drm/drm_gem.h>
 #include <drm/drm_gem_cma_helper.h>
+#include <drm/drm_of.h>
 #include <linux/component.h>
 #include <linux/iommu.h>
 #include <linux/of_address.h>
@@ -415,7 +416,8 @@ static int mtk_drm_probe(struct platform_device *pdev)
 		    comp_type == MTK_DPI) {
 			dev_info(dev, "Adding component match for %s\n",
 				 node->full_name);
-			component_match_add(dev, &match, compare_of, node);
+			drm_of_component_match_add(dev, &match, compare_of,
+						   node);
 		} else {
 			struct mtk_ddp_comp *comp;
 
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index fb5c0b0a7594..84d38eaea585 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -15,6 +15,8 @@
  * this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <drm/drm_of.h>
+
 #include "msm_drv.h"
 #include "msm_debugfs.h"
 #include "msm_fence.h"
@@ -919,8 +921,8 @@ static int add_components_mdp(struct device *mdp_dev,
 			continue;
 		}
 
-		component_match_add(master_dev, matchptr, compare_of, intf);
-
+		drm_of_component_match_add(master_dev, matchptr, compare_of,
+					   intf);
 		of_node_put(intf);
 		of_node_put(ep_node);
 	}
@@ -962,8 +964,8 @@ static int add_display_components(struct device *dev,
 		put_device(mdp_dev);
 
 		/* add the MDP component itself */
-		component_match_add(dev, matchptr, compare_of,
-				    mdp_dev->of_node);
+		drm_of_component_match_add(dev, matchptr, compare_of,
+					   mdp_dev->of_node);
 	} else {
 		/* MDP4 */
 		mdp_dev = dev;
@@ -996,7 +998,7 @@ static int add_gpu_components(struct device *dev,
 	if (!np)
 		return 0;
 
-	component_match_add(dev, matchptr, compare_of, np);
+	drm_of_component_match_add(dev, matchptr, compare_of, np);
 
 	of_node_put(np);
 
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 8c8cbe837e61..6fe161192bb4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -20,6 +20,7 @@
 #include <drm/drm_crtc_helper.h>
 #include <drm/drm_fb_helper.h>
 #include <drm/drm_gem_cma_helper.h>
+#include <drm/drm_of.h>
 #include <linux/dma-mapping.h>
 #include <linux/pm_runtime.h>
 #include <linux/module.h>
@@ -388,7 +389,7 @@ static void rockchip_add_endpoints(struct device *dev,
 			continue;
 		}
 
-		component_match_add(dev, match, compare_of, remote);
+		drm_of_component_match_add(dev, match, compare_of, remote);
 		of_node_put(remote);
 	}
 }
@@ -437,7 +438,8 @@ static int rockchip_drm_platform_probe(struct platform_device *pdev)
 		}
 
 		of_node_put(iommu);
-		component_match_add(dev, &match, compare_of, port->parent);
+		drm_of_component_match_add(dev, &match, compare_of,
+					   port->parent);
 		of_node_put(port);
 	}
 
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 2784919a7366..5e819876e642 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -17,6 +17,7 @@
 #include <drm/drm_crtc_helper.h>
 #include <drm/drm_gem_cma_helper.h>
 #include <drm/drm_fb_cma_helper.h>
+#include <drm/drm_of.h>
 
 #include "sti_crtc.h"
 #include "sti_drv.h"
@@ -423,8 +424,8 @@ static int sti_platform_probe(struct platform_device *pdev)
 	child_np = of_get_next_available_child(node, NULL);
 
 	while (child_np) {
-		component_match_add(dev, &match, compare_of, child_np);
-		of_node_put(child_np);
+		drm_of_component_match_add(dev, &match, compare_of,
+					   child_np);
 		child_np = of_get_next_available_child(node, child_np);
 	}
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 0da9862ad8ed..b3c4ad605e81 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -18,6 +18,7 @@
 #include <drm/drm_fb_cma_helper.h>
 #include <drm/drm_gem_cma_helper.h>
 #include <drm/drm_fb_helper.h>
+#include <drm/drm_of.h>
 
 #include "sun4i_crtc.h"
 #include "sun4i_drv.h"
@@ -239,7 +240,7 @@ static int sun4i_drv_add_endpoints(struct device *dev,
 		/* Add current component */
 		DRM_DEBUG_DRIVER("Adding component %s\n",
 				 of_node_full_name(node));
-		component_match_add(dev, match, compare_of, node);
+		drm_of_component_match_add(dev, match, compare_of, node);
 		count++;
 	}
 
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 68e895021005..06a4c584f3cb 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -10,6 +10,7 @@
 
 #include <linux/component.h>
 #include <linux/of_graph.h>
+#include <drm/drm_of.h>
 
 #include "tilcdc_drv.h"
 #include "tilcdc_external.h"
@@ -160,7 +161,8 @@ int tilcdc_get_external_components(struct device *dev,
 
 		dev_dbg(dev, "Subdevice node '%s' found\n", node->name);
 		if (match)
-			component_match_add(dev, match, dev_match_of, node);
+			drm_of_component_match_add(dev, match, dev_match_of,
+						   node);
 		of_node_put(node);
 		count++;
 	}
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 3fd87b386ed7..d6b4c5587bbe 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -4,6 +4,7 @@
 #include <linux/of_graph.h>
 
 struct component_master_ops;
+struct component_match;
 struct device;
 struct drm_device;
 struct drm_encoder;
@@ -12,6 +13,10 @@ struct device_node;
 #ifdef CONFIG_OF
 extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
 					   struct device_node *port);
+extern void drm_of_component_match_add(struct device *master,
+				       struct component_match **matchptr,
+				       int (*compare)(struct device *, void *),
+				       struct device_node *node);
 extern int drm_of_component_probe(struct device *dev,
 				  int (*compare_of)(struct device *, void *),
 				  const struct component_master_ops *m_ops);
@@ -25,6 +30,13 @@ static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
 	return 0;
 }
 
+static void drm_of_component_match_add(struct device *master,
+				       struct component_match **matchptr,
+				       int (*compare)(struct device *, void *),
+				       struct device_node *node)
+{
+}
+
 static inline int
 drm_of_component_probe(struct device *dev,
 		       int (*compare_of)(struct device *, void *),
-- 
2.1.0



From randy.li at rock-chips.com  Wed Oct 19 06:52:26 2016
From: randy.li at rock-chips.com (Randy Li)
Date: Wed, 19 Oct 2016 21:52:26 +0800
Subject: the dp helper would try to enable the i2c channel for rockchip-edp
Message-ID: <24daffe0-42a4-2a37-d685-7d9ecf9c3b11@rock-chips.com>

Hello,

   Recently, I want to use a eDP panel in my RK3288 platform, but I got 
the following message:

[    8.935918] i2c i2c-6: of_i2c: modalias failure on /dp at ff970000/ports
[    8.936018] rockchip-drm display-subsystem: bound ff970000.dp (ops 
rockchip_dp_component_ops [analogix_dp_rockchip])
It try to enable the eDP aux channel and add a new I2C controller, but 
it failed then the whole display subsystem is broken, the panel doesn't 
power on either.

   I hope somebody could figure out what is wrong with it.




From briannorris at chromium.org  Wed Oct 19 10:42:05 2016
From: briannorris at chromium.org (Brian Norris)
Date: Wed, 19 Oct 2016 10:42:05 -0700
Subject: [PATCH] PCI: rockchip: remove the pointer to L1 substate cap
In-Reply-To: <1476868234-15135-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476868234-15135-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <20161019174205.GA78840@google.com>

Hi,

On Wed, Oct 19, 2016 at 05:10:34PM +0800, Shawn Lin wrote:
> Per the errata of TRM, the RC can't support L1 substate, so we
> need to remove the L1 substate cap.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> ---
> 
>  drivers/pci/host/pcie-rockchip.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index e0b22da..8370a85 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -142,6 +142,8 @@
>  #define   PCIE_RC_CONFIG_LCS_LBMS		BIT(30)
>  #define   PCIE_RC_CONFIG_LCS_LAMS		BIT(31)
>  #define PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 (PCIE_RC_CONFIG_BASE + 0x90c)
> +#define PCIE_RC_CONFIG_THP_CAP		(PCIE_RC_CONFIG_BASE + 0x274)
> +#define   PCIE_RC_CONFIG_THP_CAP_NEXT_MASK	GENMASK(31, 20)
>  
>  #define PCIE_CORE_AXI_CONF_BASE		0xc00000
>  #define PCIE_CORE_OB_REGION_ADDR0	(PCIE_CORE_AXI_CONF_BASE + 0x0)
> @@ -558,6 +560,12 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  	rockchip_pcie_write(rockchip,
>  			    PCI_CLASS_BRIDGE_PCI << PCIE_RC_CONFIG_SCC_SHIFT,
>  			    PCIE_RC_CONFIG_RID_CCR);
> +
> +	/* Clear THP cap's next cap pointer to remove L1 substate cap */
> +	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_THP_CAP);
> +	status &= ~PCIE_RC_CONFIG_THP_CAP_NEXT_MASK;
> +	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_THP_CAP);
> +

Tested-by: Brian Norris <briannorris at chromium.org>

>  	rockchip_pcie_write(rockchip, 0x0, PCIE_RC_BAR_CONF);
>  
>  	rockchip_pcie_write(rockchip,

You could also probably do away with the handling of L1 substates here,
since they're officially declared broken:

        /*
         * We need to read/write PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 before
         * enabling ASPM.  Otherwise L1PwrOnSc and L1PwrOnVal isn't
         * reliable and enabling ASPM doesn't work.  This is a controller
         * bug we need to work around.
         */
        status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
        rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);


From briannorris at chromium.org  Wed Oct 19 10:43:57 2016
From: briannorris at chromium.org (Brian Norris)
Date: Wed, 19 Oct 2016 10:43:57 -0700
Subject: [PATCH] PCI: rockchip: remove the pointer to L1 substate cap
In-Reply-To: <20161019174205.GA78840@google.com>
References: <1476868234-15135-1-git-send-email-shawn.lin@rock-chips.com>
 <20161019174205.GA78840@google.com>
Message-ID: <20161019174357.GB78840@google.com>

On Wed, Oct 19, 2016 at 10:42:05AM -0700, Brian Norris wrote:
> Hi,
> 
> On Wed, Oct 19, 2016 at 05:10:34PM +0800, Shawn Lin wrote:
> > Per the errata of TRM, the RC can't support L1 substate, so we
> > need to remove the L1 substate cap.
> > 
> > Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

[snip]

BTW, I couldn't actually find the original patch email in any mailing
list archive, nor in patchwork. Did the email get held up by the mailing
list or something?

Brian


From javier at osg.samsung.com  Wed Oct 19 14:06:23 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Wed, 19 Oct 2016 18:06:23 -0300
Subject: [PATCH 0/4] PM / devfreq: Fix module autoload for platform drivers
Message-ID: <1476911187-11040-1-git-send-email-javier@osg.samsung.com>

Hello,

I noticed that module autoload won't be working in some of the defreq
platform drivers. This patch series contains the fixes for these.

Best regards,
Javier


Javier Martinez Canillas (4):
  PM / devfreq: rk3399_dmc: Fix module autoload
  PM / devfreq: exynos-nocp: Fix module autoload
  PM / devfreq: rockchip-dfi: Fix module autoload
  PM / devfreq: exynos-ppmu: Fix module autoload

 drivers/devfreq/event/exynos-nocp.c  | 1 +
 drivers/devfreq/event/exynos-ppmu.c  | 1 +
 drivers/devfreq/event/rockchip-dfi.c | 1 +
 drivers/devfreq/rk3399_dmc.c         | 1 +
 4 files changed, 4 insertions(+)

-- 
2.7.4



From javier at osg.samsung.com  Wed Oct 19 14:06:26 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Wed, 19 Oct 2016 18:06:26 -0300
Subject: [PATCH 3/4] PM / devfreq: rockchip-dfi: Fix module autoload
In-Reply-To: <1476911187-11040-1-git-send-email-javier@osg.samsung.com>
References: <1476911187-11040-1-git-send-email-javier@osg.samsung.com>
Message-ID: <1476911187-11040-4-git-send-email-javier@osg.samsung.com>

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/devfreq/event/rockchip-dfi.ko | grep alias
$

After this patch:

$ modinfo drivers/devfreq/event/rockchip-dfi.ko | grep alias
alias:          of:N*T*Crockchip,rk3399-dfiC*
alias:          of:N*T*Crockchip,rk3399-dfi

Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
---

 drivers/devfreq/event/rockchip-dfi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/devfreq/event/rockchip-dfi.c b/drivers/devfreq/event/rockchip-dfi.c
index 43fcc5a7f515..22b113363ffc 100644
--- a/drivers/devfreq/event/rockchip-dfi.c
+++ b/drivers/devfreq/event/rockchip-dfi.c
@@ -188,6 +188,7 @@ static const struct of_device_id rockchip_dfi_id_match[] = {
 	{ .compatible = "rockchip,rk3399-dfi" },
 	{ },
 };
+MODULE_DEVICE_TABLE(of, rockchip_dfi_id_match);
 
 static int rockchip_dfi_probe(struct platform_device *pdev)
 {
-- 
2.7.4



From John.Youn at synopsys.com  Wed Oct 19 15:58:27 2016
From: John.Youn at synopsys.com (John Youn)
Date: Wed, 19 Oct 2016 15:58:27 -0700
Subject: [PATCH v8 2/3] usb: dwc2: assert phy reset when waking up in
 rk3288 platform
In-Reply-To: <CAFLEztRLJbMj-ttGBsCWCMW=+0N3bbMQ0c4YcgDyvUDYs1SSkA@mail.gmail.com>
References: <1474743019-1050-1-git-send-email-ayaka@soulik.info>
 <1474743019-1050-3-git-send-email-ayaka@soulik.info>
 <CAFLEztRLJbMj-ttGBsCWCMW=+0N3bbMQ0c4YcgDyvUDYs1SSkA@mail.gmail.com>
Message-ID: <d8f43ae4-bfca-ce37-772d-a61b77f5493a@synopsys.com>

On 10/15/2016 8:07 AM, ?? wrote:
> 2016-09-25 2:50 GMT+08:00 Randy Li <ayaka at soulik.info>:
>> On the rk3288 USB host-only port (the one that's not the OTG-enabled
>> port) the PHY can get into a bad state when a wakeup is asserted (not
>> just a wakeup from full system suspend but also a wakeup from
>> autosuspend).
>>
>> We can get the PHY out of its bad state by asserting its "port reset",
>> but unfortunately that seems to assert a reset onto the USB bus so it
>> could confuse things if we don't actually deenumerate / reenumerate the
>> device.
>>
>> We can also get the PHY out of its bad state by fully resetting it using
>> the reset from the CRU (clock reset unit) in chip, which does a more full
>> reset.  The CRU-based reset appears to actually cause devices on the bus
>> to be removed and reinserted, which fixes the problem (albeit in a hacky
>> way).
>>
>> It's unfortunate that we need to do a full re-enumeration of devices at
>> wakeup time, but this is better than alternative of letting the bus get
>> wedged.
>>
>> Signed-off-by: Randy Li <ayaka at soulik.info>
>> ---
>>  drivers/usb/dwc2/core_intr.c | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
>> index d85c5c9..af27edc 100644
>> --- a/drivers/usb/dwc2/core_intr.c
>> +++ b/drivers/usb/dwc2/core_intr.c
>> @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg)
>>  static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>>  {
>>         int ret;
>> +       struct device_node *np = hsotg->dev->of_node;
>>
>>         /* Clear interrupt */
>>         dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
>> @@ -379,6 +380,16 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>>                         /* Restart the Phy Clock */
>>                         pcgcctl &= ~PCGCTL_STOPPCLK;
>>                         dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
>> +
>> +                       /*
>> +                        * It is a quirk in Rockchip RK3288, causing by
>> +                        * a hardware bug. This will propagate out and
>> +                        * eventually we'll re-enumerate the device.
>> +                        * Not great but the best we can do.
>> +                        */
>> +                       if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
>> +                               phy_reset(hsotg->phy);
> 
> It will call mutex_lock in phy_reset.
> 
> 
>> +
>>                         mod_timer(&hsotg->wkp_timer,
>>                                   jiffies + msecs_to_jiffies(71));
>>                 } else {
>> --
>> 2.7.4
>>
> 
> What is the status of this patch?
> Sleeping calls(phy_reset ==> mutex) shouldn't be used in irq handler.
> Randy will correct that?
> 

Yes, that's right, I missed that.

It will have to be fixed.

Regards,
John



From randy.li at rock-chips.com  Wed Oct 19 17:50:40 2016
From: randy.li at rock-chips.com (Randy Li)
Date: Thu, 20 Oct 2016 08:50:40 +0800
Subject: [PATCH v8 2/3] usb: dwc2: assert phy reset when waking up in
 rk3288 platform
In-Reply-To: <d8f43ae4-bfca-ce37-772d-a61b77f5493a@synopsys.com>
References: <1474743019-1050-1-git-send-email-ayaka@soulik.info>
 <1474743019-1050-3-git-send-email-ayaka@soulik.info>
 <CAFLEztRLJbMj-ttGBsCWCMW=+0N3bbMQ0c4YcgDyvUDYs1SSkA@mail.gmail.com>
 <d8f43ae4-bfca-ce37-772d-a61b77f5493a@synopsys.com>
Message-ID: <458d5e4f-95ad-22f5-02ec-bb39c4e69ad9@rock-chips.com>



On 10/20/2016 06:58 AM, John Youn wrote:
> On 10/15/2016 8:07 AM, ?? wrote:
>> 2016-09-25 2:50 GMT+08:00 Randy Li <ayaka at soulik.info>:
>>> On the rk3288 USB host-only port (the one that's not the OTG-enabled
>>> port) the PHY can get into a bad state when a wakeup is asserted (not
>>> just a wakeup from full system suspend but also a wakeup from
>>> autosuspend).
>>>
>>> We can get the PHY out of its bad state by asserting its "port reset",
>>> but unfortunately that seems to assert a reset onto the USB bus so it
>>> could confuse things if we don't actually deenumerate / reenumerate the
>>> device.
>>>
>>> We can also get the PHY out of its bad state by fully resetting it using
>>> the reset from the CRU (clock reset unit) in chip, which does a more full
>>> reset.  The CRU-based reset appears to actually cause devices on the bus
>>> to be removed and reinserted, which fixes the problem (albeit in a hacky
>>> way).
>>>
>>> It's unfortunate that we need to do a full re-enumeration of devices at
>>> wakeup time, but this is better than alternative of letting the bus get
>>> wedged.
>>>
>>> Signed-off-by: Randy Li <ayaka at soulik.info>
>>> ---
>>>  drivers/usb/dwc2/core_intr.c | 11 +++++++++++
>>>  1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
>>> index d85c5c9..af27edc 100644
>>> --- a/drivers/usb/dwc2/core_intr.c
>>> +++ b/drivers/usb/dwc2/core_intr.c
>>> @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg)
>>>  static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>>>  {
>>>         int ret;
>>> +       struct device_node *np = hsotg->dev->of_node;
>>>
>>>         /* Clear interrupt */
>>>         dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
>>> @@ -379,6 +380,16 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>>>                         /* Restart the Phy Clock */
>>>                         pcgcctl &= ~PCGCTL_STOPPCLK;
>>>                         dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
>>> +
>>> +                       /*
>>> +                        * It is a quirk in Rockchip RK3288, causing by
>>> +                        * a hardware bug. This will propagate out and
>>> +                        * eventually we'll re-enumerate the device.
>>> +                        * Not great but the best we can do.
>>> +                        */
>>> +                       if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
>>> +                               phy_reset(hsotg->phy);
>>
>> It will call mutex_lock in phy_reset.
>>
>>
>>> +
>>>                         mod_timer(&hsotg->wkp_timer,
>>>                                   jiffies + msecs_to_jiffies(71));
>>>                 } else {
>>> --
>>> 2.7.4
>>>
>>
>> What is the status of this patch?
>> Sleeping calls(phy_reset ==> mutex) shouldn't be used in irq handler.
>> Randy will correct that?
>>
>
> Yes, that's right, I missed that.
>
> It will have to be fixed.
I am still thinking a method to instead it.
>
> Regards,
> John
>
>

-- 
Randy Li
The third produce department
===========================================================================
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===========================================================================



From shawn.lin at rock-chips.com  Wed Oct 19 18:03:26 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Thu, 20 Oct 2016 09:03:26 +0800
Subject: [PATCH] PCI: rockchip: remove the pointer to L1 substate cap
In-Reply-To: <20161019174205.GA78840@google.com>
References: <1476868234-15135-1-git-send-email-shawn.lin@rock-chips.com>
 <20161019174205.GA78840@google.com>
Message-ID: <13a8275f-da5e-31b8-512b-c597817aa349@rock-chips.com>

? 2016/10/20 1:42, Brian Norris ??:
> Hi,
>
> On Wed, Oct 19, 2016 at 05:10:34PM +0800, Shawn Lin wrote:
>> Per the errata of TRM, the RC can't support L1 substate, so we
>> need to remove the L1 substate cap.
>>
>> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>> ---
>>
>>  drivers/pci/host/pcie-rockchip.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
>> index e0b22da..8370a85 100644
>> --- a/drivers/pci/host/pcie-rockchip.c
>> +++ b/drivers/pci/host/pcie-rockchip.c
>> @@ -142,6 +142,8 @@
>>  #define   PCIE_RC_CONFIG_LCS_LBMS		BIT(30)
>>  #define   PCIE_RC_CONFIG_LCS_LAMS		BIT(31)
>>  #define PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 (PCIE_RC_CONFIG_BASE + 0x90c)
>> +#define PCIE_RC_CONFIG_THP_CAP		(PCIE_RC_CONFIG_BASE + 0x274)
>> +#define   PCIE_RC_CONFIG_THP_CAP_NEXT_MASK	GENMASK(31, 20)
>>
>>  #define PCIE_CORE_AXI_CONF_BASE		0xc00000
>>  #define PCIE_CORE_OB_REGION_ADDR0	(PCIE_CORE_AXI_CONF_BASE + 0x0)
>> @@ -558,6 +560,12 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>>  	rockchip_pcie_write(rockchip,
>>  			    PCI_CLASS_BRIDGE_PCI << PCIE_RC_CONFIG_SCC_SHIFT,
>>  			    PCIE_RC_CONFIG_RID_CCR);
>> +
>> +	/* Clear THP cap's next cap pointer to remove L1 substate cap */
>> +	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_THP_CAP);
>> +	status &= ~PCIE_RC_CONFIG_THP_CAP_NEXT_MASK;
>> +	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_THP_CAP);
>> +
>
> Tested-by: Brian Norris <briannorris at chromium.org>
>
>>  	rockchip_pcie_write(rockchip, 0x0, PCIE_RC_BAR_CONF);
>>
>>  	rockchip_pcie_write(rockchip,
>
> You could also probably do away with the handling of L1 substates here,
> since they're officially declared broken:

okay, I will respin v2 later to remove this.

>
>         /*
>          * We need to read/write PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 before
>          * enabling ASPM.  Otherwise L1PwrOnSc and L1PwrOnVal isn't
>          * reliable and enabling ASPM doesn't work.  This is a controller
>          * bug we need to work around.
>          */
>         status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
>         rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Best Regards
Shawn Lin



From shawn.lin at rock-chips.com  Wed Oct 19 18:07:14 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Thu, 20 Oct 2016 09:07:14 +0800
Subject: [PATCH] PCI: rockchip: remove the pointer to L1 substate cap
In-Reply-To: <20161019174357.GB78840@google.com>
References: <1476868234-15135-1-git-send-email-shawn.lin@rock-chips.com>
 <20161019174205.GA78840@google.com> <20161019174357.GB78840@google.com>
Message-ID: <22d32ccb-9c3c-4a8b-f2e2-2de471f8dac5@rock-chips.com>

? 2016/10/20 1:43, Brian Norris ??:
> On Wed, Oct 19, 2016 at 10:42:05AM -0700, Brian Norris wrote:
>> Hi,
>>
>> On Wed, Oct 19, 2016 at 05:10:34PM +0800, Shawn Lin wrote:
>>> Per the errata of TRM, the RC can't support L1 substate, so we
>>> need to remove the L1 substate cap.
>>>
>>> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>
> [snip]
>
> BTW, I couldn't actually find the original patch email in any mailing
> list archive, nor in patchwork. Did the email get held up by the mailing
> list or something?

I don't know if this patch was held by linux-pci, but I could find it
here:

https://patchwork.kernel.org/patch/9383721/



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


-- 
Best Regards
Shawn Lin



From briannorris at chromium.org  Wed Oct 19 18:39:26 2016
From: briannorris at chromium.org (Brian Norris)
Date: Wed, 19 Oct 2016 18:39:26 -0700
Subject: [PATCH] PCI: rockchip: fix wrong print for negotiated lane numbers
In-Reply-To: <1476321391-6665-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476321391-6665-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <20161020013925.GD78840@google.com>

On Thu, Oct 13, 2016 at 09:16:31AM +0800, Shawn Lin wrote:
> The negotiated lane numbers was incorrectly calculated, fix it.
> 
> Fixes: e77f847df54c6b0 ("PCI: rockchip: Add Rockchip PCIe controller support")
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> ---
> 
>  drivers/pci/host/pcie-rockchip.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index e0b22da..0d69d8c 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -549,7 +549,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  
>  	/* Check the final link width from negotiated lane counter from MGMT */
>  	status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
> -	status =  0x1 << ((status & PCIE_CORE_PL_CONF_LANE_MASK) >>
> +	status =  0x1 << ((status >> PCIE_CORE_PL_CONF_LANE_SHIFT) &
>  			  PCIE_CORE_PL_CONF_LANE_MASK);
>  	dev_dbg(dev, "current link width is x%d\n", status);
>  

Looks good to me:

Reviewed-by: Brian Norris <briannorris at chromium.org>


From myungjoo.ham at samsung.com  Wed Oct 19 19:22:46 2016
From: myungjoo.ham at samsung.com (=?UTF-8?B?TXl1bmdKb28gSGFt?=)
Date: Thu, 20 Oct 2016 02:22:46 +0000
Subject: =?UTF-8?B?UkU6IFtQQVRDSCAwLzRdIFBNIC8gZGV2ZnJlcTogRml4IG1v?=
 =?UTF-8?B?ZHVsZSBhdXRvbG9hZCBmb3IgcGxhdGZvcm0gZHJpdmVycw==?=
References: <CGME20161019210645epcas1p449463edf9c3cb3681b0a4e8116ccf7f2@epcas1p4.samsung.com>
Message-ID: <877108885.1462124.1476930166421.JavaMail.weblogic@ep1ml101a>

> Hello,
> 
> I noticed that module autoload won't be working in some of the defreq
> platform drivers. This patch series contains the fixes for these.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (4):
>   PM / devfreq: rk3399_dmc: Fix module autoload
>   PM / devfreq: exynos-nocp: Fix module autoload
>   PM / devfreq: rockchip-dfi: Fix module autoload
>   PM / devfreq: exynos-ppmu: Fix module autoload

Acked-by: MyungJoo Ham <myungjoo.ham at samsung.com>

All the four are not at for-4.9-rc branch.
https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/log/?h=for-4.9-rc


Cheers,
MyungJoo

> 
>  drivers/devfreq/event/exynos-nocp.c  | 1 +
>  drivers/devfreq/event/exynos-ppmu.c  | 1 +
>  drivers/devfreq/event/rockchip-dfi.c | 1 +
>  drivers/devfreq/rk3399_dmc.c         | 1 +
>  4 files changed, 4 insertions(+)
> 
> -- 
> 2.7.4

From cw00.choi at samsung.com  Wed Oct 19 19:24:10 2016
From: cw00.choi at samsung.com (Chanwoo Choi)
Date: Thu, 20 Oct 2016 11:24:10 +0900
Subject: [PATCH 0/4] PM / devfreq: Fix module autoload for platform drivers
In-Reply-To: <1476911187-11040-1-git-send-email-javier@osg.samsung.com>
References: <CGME20161019210649epcas1p4e0c178cb75709bb242da10d9c1fd77d2@epcas1p4.samsung.com>
 <1476911187-11040-1-git-send-email-javier@osg.samsung.com>
Message-ID: <58082ACA.90104@samsung.com>

Hi Javier,

On 2016? 10? 20? 06:06, Javier Martinez Canillas wrote:
> Hello,
> 
> I noticed that module autoload won't be working in some of the defreq
> platform drivers. This patch series contains the fixes for these.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (4):
>   PM / devfreq: rk3399_dmc: Fix module autoload
>   PM / devfreq: exynos-nocp: Fix module autoload
>   PM / devfreq: rockchip-dfi: Fix module autoload
>   PM / devfreq: exynos-ppmu: Fix module autoload
> 
>  drivers/devfreq/event/exynos-nocp.c  | 1 +
>  drivers/devfreq/event/exynos-ppmu.c  | 1 +
>  drivers/devfreq/event/rockchip-dfi.c | 1 +
>  drivers/devfreq/rk3399_dmc.c         | 1 +
>  4 files changed, 4 insertions(+)
> 

Looks good to me of all patches.

Reviewed-by: Chanwoo Choi <cw00.choi at samsung.com>

-- 
Best Regards,
Chanwoo Choi


From myungjoo.ham at samsung.com  Wed Oct 19 19:31:17 2016
From: myungjoo.ham at samsung.com (=?UTF-8?B?TXl1bmdKb28gSGFt?=)
Date: Thu, 20 Oct 2016 02:31:17 +0000
Subject: =?UTF-8?B?Rlc6IFJFOiBbUEFUQ0ggMC80XSBQTSAvIGRldmZyZXE6IEZp?=
 =?UTF-8?B?eCBtb2R1bGUgYXV0b2xvYWQgZm9yIHBsYXRmb3JtIGRyaXZl?= =?UTF-8?B?cnM=?=
References: <CGME20161019210645epcas1p449463edf9c3cb3681b0a4e8116ccf7f2@epcas1p4.samsung.com>
Message-ID: <1458141592.1463929.1476930677746.JavaMail.weblogic@ep1ml101a>

> > Hello,
> > 
> > I noticed that module autoload won't be working in some of the defreq
> > platform drivers. This patch series contains the fixes for these.
> > 
> > Best regards,
> > Javier
> > 
> > 
> > Javier Martinez Canillas (4):
> >   PM / devfreq: rk3399_dmc: Fix module autoload
> >   PM / devfreq: exynos-nocp: Fix module autoload
> >   PM / devfreq: rockchip-dfi: Fix module autoload
> >   PM / devfreq: exynos-ppmu: Fix module autoload
> 
> Acked-by: MyungJoo Ham <myungjoo.ham at samsung.com>
> 
> All the four are not at for-4.9-rc branch.

not --> now

> https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/log/?h=for-4.9-rc
> 
> 
> Cheers,
> MyungJoo
> 
> > 
> >  drivers/devfreq/event/exynos-nocp.c  | 1 +
> >  drivers/devfreq/event/exynos-ppmu.c  | 1 +
> >  drivers/devfreq/event/rockchip-dfi.c | 1 +
> >  drivers/devfreq/rk3399_dmc.c         | 1 +
> >  4 files changed, 4 insertions(+)
> > 
> > -- 
> > 2.7.4

From daniel at ffwll.ch  Wed Oct 19 23:36:11 2016
From: daniel at ffwll.ch (Daniel Vetter)
Date: Thu, 20 Oct 2016 08:36:11 +0200
Subject: [PATCH] drm: convert DT component matching to
 component_match_add_release()
In-Reply-To: <E1bwo6l-0005Io-Q1@rmk-PC.armlinux.org.uk>
References: <E1bwo6l-0005Io-Q1@rmk-PC.armlinux.org.uk>
Message-ID: <20161020063611.GJ20761@phenom.ffwll.local>

On Wed, Oct 19, 2016 at 11:28:27AM +0100, Russell King wrote:
> Convert DT component matching to use component_match_add_release().
> 
> Signed-off-by: Russell King <rmk+kernel at armlinux.org.uk>
> ---
> Can we please get this patch from May merged into the drm-misc or
> whatever trees so that we don't end up with conflicts?  I've no idea
> who looks after drm-misc, as they have _still_ failed to add
> themselves to MAINTAINERS.

Can pick, once someone from the arm world smashes at least an ack on this.
But I have no clue about of/DT, so won't just merge it.

And yes drm-misc will get a MAINTAINERS entry, after ks, because there's
some things to discuss about what that one needs to look like.
-Daniel

> 
>  drivers/gpu/drm/arm/hdlcd_drv.c                 |  3 ++-
>  drivers/gpu/drm/arm/malidp_drv.c                |  4 +++-
>  drivers/gpu/drm/armada/armada_drv.c             |  2 +-
>  drivers/gpu/drm/drm_of.c                        | 28 +++++++++++++++++++++++--
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c           |  5 +++--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  7 ++++---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c          |  4 +++-
>  drivers/gpu/drm/msm/msm_drv.c                   | 12 ++++++-----
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c     |  6 ++++--
>  drivers/gpu/drm/sti/sti_drv.c                   |  5 +++--
>  drivers/gpu/drm/sun4i/sun4i_drv.c               |  3 ++-
>  drivers/gpu/drm/tilcdc/tilcdc_external.c        |  4 +++-
>  include/drm/drm_of.h                            | 12 +++++++++++
>  13 files changed, 73 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index fb6a418ce6be..6477d1a65266 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -453,7 +453,8 @@ static int hdlcd_probe(struct platform_device *pdev)
>  		return -EAGAIN;
>  	}
>  
> -	component_match_add(&pdev->dev, &match, compare_dev, port);
> +	drm_of_component_match_add(&pdev->dev, &match, compare_dev, port);
> +	of_node_put(port);
>  
>  	return component_master_add_with_match(&pdev->dev, &hdlcd_master_ops,
>  					       match);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> index 9280358b8f15..9f4739452a25 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -493,7 +493,9 @@ static int malidp_platform_probe(struct platform_device *pdev)
>  		return -EAGAIN;
>  	}
>  
> -	component_match_add(&pdev->dev, &match, malidp_compare_dev, port);
> +	drm_of_component_match_add(&pdev->dev, &match, malidp_compare_dev,
> +				   port);
> +	of_node_put(port);
>  	return component_master_add_with_match(&pdev->dev, &malidp_master_ops,
>  					       match);
>  }
> diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
> index 1e0e68f608e4..94e46da9a758 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -254,7 +254,7 @@ static void armada_add_endpoints(struct device *dev,
>  			continue;
>  		}
>  
> -		component_match_add(dev, match, compare_of, remote);
> +		drm_of_component_match_add(dev, match, compare_of, remote);
>  		of_node_put(remote);
>  	}
>  }
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index bc98bb94264d..47848ed8ca48 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -6,6 +6,11 @@
>  #include <drm/drm_crtc.h>
>  #include <drm/drm_of.h>
>  
> +static void drm_release_of(struct device *dev, void *data)
> +{
> +	of_node_put(data);
> +}
> +
>  /**
>   * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
>   * @dev: DRM device
> @@ -64,6 +69,24 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>  EXPORT_SYMBOL(drm_of_find_possible_crtcs);
>  
>  /**
> + * drm_of_component_match_add - Add a component helper OF node match rule
> + * @master: master device
> + * @matchptr: component match pointer
> + * @compare: compare function used for matching component
> + * @node: of_node
> + */
> +void drm_of_component_match_add(struct device *master,
> +				struct component_match **matchptr,
> +				int (*compare)(struct device *, void *),
> +				struct device_node *node)
> +{
> +	of_node_get(node);
> +	component_match_add_release(master, matchptr, drm_release_of,
> +				    compare, node);
> +}
> +EXPORT_SYMBOL_GPL(drm_of_component_match_add);
> +
> +/**
>   * drm_of_component_probe - Generic probe function for a component based master
>   * @dev: master device containing the OF node
>   * @compare_of: compare function used for matching components
> @@ -101,7 +124,7 @@ int drm_of_component_probe(struct device *dev,
>  			continue;
>  		}
>  
> -		component_match_add(dev, &match, compare_of, port);
> +		drm_of_component_match_add(dev, &match, compare_of, port);
>  		of_node_put(port);
>  	}
>  
> @@ -140,7 +163,8 @@ int drm_of_component_probe(struct device *dev,
>  				continue;
>  			}
>  
> -			component_match_add(dev, &match, compare_of, remote);
> +			drm_of_component_match_add(dev, &match, compare_of,
> +						   remote);
>  			of_node_put(remote);
>  		}
>  		of_node_put(port);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index aa687669e22b..0dee6acbd880 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -16,6 +16,7 @@
>  
>  #include <linux/component.h>
>  #include <linux/of_platform.h>
> +#include <drm/drm_of.h>
>  
>  #include "etnaviv_drv.h"
>  #include "etnaviv_gpu.h"
> @@ -629,8 +630,8 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
>  			if (!core_node)
>  				break;
>  
> -			component_match_add(&pdev->dev, &match, compare_of,
> -					    core_node);
> +			drm_of_component_match_add(&pdev->dev, &match,
> +						   compare_of, core_node);
>  			of_node_put(core_node);
>  		}
>  	} else if (dev->platform_data) {
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> index 90377a609c98..e88fde18c946 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -24,6 +24,7 @@
>  #include <drm/drm_fb_cma_helper.h>
>  #include <drm/drm_atomic_helper.h>
>  #include <drm/drm_crtc_helper.h>
> +#include <drm/drm_of.h>
>  
>  #include "kirin_drm_drv.h"
>  
> @@ -260,14 +261,13 @@ static struct device_node *kirin_get_remote_node(struct device_node *np)
>  		DRM_ERROR("no valid endpoint node\n");
>  		return ERR_PTR(-ENODEV);
>  	}
> -	of_node_put(endpoint);
>  
>  	remote = of_graph_get_remote_port_parent(endpoint);
> +	of_node_put(endpoint);
>  	if (!remote) {
>  		DRM_ERROR("no valid remote node\n");
>  		return ERR_PTR(-ENODEV);
>  	}
> -	of_node_put(remote);
>  
>  	if (!of_device_is_available(remote)) {
>  		DRM_ERROR("not available for remote node\n");
> @@ -294,7 +294,8 @@ static int kirin_drm_platform_probe(struct platform_device *pdev)
>  	if (IS_ERR(remote))
>  		return PTR_ERR(remote);
>  
> -	component_match_add(dev, &match, compare_of, remote);
> +	drm_of_component_match_add(dev, &match, compare_of, remote);
> +	of_node_put(remote);
>  
>  	return component_master_add_with_match(dev, &kirin_drm_ops, match);
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index cf83f6507ec8..9c5430fb82a2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -18,6 +18,7 @@
>  #include <drm/drm_crtc_helper.h>
>  #include <drm/drm_gem.h>
>  #include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_of.h>
>  #include <linux/component.h>
>  #include <linux/iommu.h>
>  #include <linux/of_address.h>
> @@ -415,7 +416,8 @@ static int mtk_drm_probe(struct platform_device *pdev)
>  		    comp_type == MTK_DPI) {
>  			dev_info(dev, "Adding component match for %s\n",
>  				 node->full_name);
> -			component_match_add(dev, &match, compare_of, node);
> +			drm_of_component_match_add(dev, &match, compare_of,
> +						   node);
>  		} else {
>  			struct mtk_ddp_comp *comp;
>  
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index fb5c0b0a7594..84d38eaea585 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -15,6 +15,8 @@
>   * this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <drm/drm_of.h>
> +
>  #include "msm_drv.h"
>  #include "msm_debugfs.h"
>  #include "msm_fence.h"
> @@ -919,8 +921,8 @@ static int add_components_mdp(struct device *mdp_dev,
>  			continue;
>  		}
>  
> -		component_match_add(master_dev, matchptr, compare_of, intf);
> -
> +		drm_of_component_match_add(master_dev, matchptr, compare_of,
> +					   intf);
>  		of_node_put(intf);
>  		of_node_put(ep_node);
>  	}
> @@ -962,8 +964,8 @@ static int add_display_components(struct device *dev,
>  		put_device(mdp_dev);
>  
>  		/* add the MDP component itself */
> -		component_match_add(dev, matchptr, compare_of,
> -				    mdp_dev->of_node);
> +		drm_of_component_match_add(dev, matchptr, compare_of,
> +					   mdp_dev->of_node);
>  	} else {
>  		/* MDP4 */
>  		mdp_dev = dev;
> @@ -996,7 +998,7 @@ static int add_gpu_components(struct device *dev,
>  	if (!np)
>  		return 0;
>  
> -	component_match_add(dev, matchptr, compare_of, np);
> +	drm_of_component_match_add(dev, matchptr, compare_of, np);
>  
>  	of_node_put(np);
>  
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 8c8cbe837e61..6fe161192bb4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -20,6 +20,7 @@
>  #include <drm/drm_crtc_helper.h>
>  #include <drm/drm_fb_helper.h>
>  #include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_of.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/module.h>
> @@ -388,7 +389,7 @@ static void rockchip_add_endpoints(struct device *dev,
>  			continue;
>  		}
>  
> -		component_match_add(dev, match, compare_of, remote);
> +		drm_of_component_match_add(dev, match, compare_of, remote);
>  		of_node_put(remote);
>  	}
>  }
> @@ -437,7 +438,8 @@ static int rockchip_drm_platform_probe(struct platform_device *pdev)
>  		}
>  
>  		of_node_put(iommu);
> -		component_match_add(dev, &match, compare_of, port->parent);
> +		drm_of_component_match_add(dev, &match, compare_of,
> +					   port->parent);
>  		of_node_put(port);
>  	}
>  
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index 2784919a7366..5e819876e642 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -17,6 +17,7 @@
>  #include <drm/drm_crtc_helper.h>
>  #include <drm/drm_gem_cma_helper.h>
>  #include <drm/drm_fb_cma_helper.h>
> +#include <drm/drm_of.h>
>  
>  #include "sti_crtc.h"
>  #include "sti_drv.h"
> @@ -423,8 +424,8 @@ static int sti_platform_probe(struct platform_device *pdev)
>  	child_np = of_get_next_available_child(node, NULL);
>  
>  	while (child_np) {
> -		component_match_add(dev, &match, compare_of, child_np);
> -		of_node_put(child_np);
> +		drm_of_component_match_add(dev, &match, compare_of,
> +					   child_np);
>  		child_np = of_get_next_available_child(node, child_np);
>  	}
>  
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 0da9862ad8ed..b3c4ad605e81 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -18,6 +18,7 @@
>  #include <drm/drm_fb_cma_helper.h>
>  #include <drm/drm_gem_cma_helper.h>
>  #include <drm/drm_fb_helper.h>
> +#include <drm/drm_of.h>
>  
>  #include "sun4i_crtc.h"
>  #include "sun4i_drv.h"
> @@ -239,7 +240,7 @@ static int sun4i_drv_add_endpoints(struct device *dev,
>  		/* Add current component */
>  		DRM_DEBUG_DRIVER("Adding component %s\n",
>  				 of_node_full_name(node));
> -		component_match_add(dev, match, compare_of, node);
> +		drm_of_component_match_add(dev, match, compare_of, node);
>  		count++;
>  	}
>  
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> index 68e895021005..06a4c584f3cb 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> @@ -10,6 +10,7 @@
>  
>  #include <linux/component.h>
>  #include <linux/of_graph.h>
> +#include <drm/drm_of.h>
>  
>  #include "tilcdc_drv.h"
>  #include "tilcdc_external.h"
> @@ -160,7 +161,8 @@ int tilcdc_get_external_components(struct device *dev,
>  
>  		dev_dbg(dev, "Subdevice node '%s' found\n", node->name);
>  		if (match)
> -			component_match_add(dev, match, dev_match_of, node);
> +			drm_of_component_match_add(dev, match, dev_match_of,
> +						   node);
>  		of_node_put(node);
>  		count++;
>  	}
> diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> index 3fd87b386ed7..d6b4c5587bbe 100644
> --- a/include/drm/drm_of.h
> +++ b/include/drm/drm_of.h
> @@ -4,6 +4,7 @@
>  #include <linux/of_graph.h>
>  
>  struct component_master_ops;
> +struct component_match;
>  struct device;
>  struct drm_device;
>  struct drm_encoder;
> @@ -12,6 +13,10 @@ struct device_node;
>  #ifdef CONFIG_OF
>  extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>  					   struct device_node *port);
> +extern void drm_of_component_match_add(struct device *master,
> +				       struct component_match **matchptr,
> +				       int (*compare)(struct device *, void *),
> +				       struct device_node *node);
>  extern int drm_of_component_probe(struct device *dev,
>  				  int (*compare_of)(struct device *, void *),
>  				  const struct component_master_ops *m_ops);
> @@ -25,6 +30,13 @@ static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>  	return 0;
>  }
>  
> +static void drm_of_component_match_add(struct device *master,
> +				       struct component_match **matchptr,
> +				       int (*compare)(struct device *, void *),
> +				       struct device_node *node)
> +{
> +}
> +
>  static inline int
>  drm_of_component_probe(struct device *dev,
>  		       int (*compare_of)(struct device *, void *),
> -- 
> 2.1.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From vivek.gautam at codeaurora.org  Wed Oct 19 23:53:39 2016
From: vivek.gautam at codeaurora.org (Vivek Gautam)
Date: Thu, 20 Oct 2016 12:23:39 +0530
Subject: [PATCH 2/3] phy: Fix ptr_ret.cocci warnings
In-Reply-To: <1476946420-698-1-git-send-email-vivek.gautam@codeaurora.org>
References: <1476946420-698-1-git-send-email-vivek.gautam@codeaurora.org>
Message-ID: <1476946420-698-2-git-send-email-vivek.gautam@codeaurora.org>

Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR.

Generated by: scripts/coccinelle/api/ptr_ret.cocci

Signed-off-by: Vivek Gautam <vivek.gautam at codeaurora.org>
Cc: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/phy/phy-ti-pipe3.c | 10 ++--------
 drivers/phy/tegra/xusb.c   | 10 ++--------
 2 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index bf46844..9c84d32 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -537,10 +537,7 @@ static int ti_pipe3_get_pll_base(struct ti_pipe3 *phy)
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
 					   "pll_ctrl");
 	phy->pll_ctrl_base = devm_ioremap_resource(dev, res);
-	if (IS_ERR(phy->pll_ctrl_base))
-		return PTR_ERR(phy->pll_ctrl_base);
-
-	return 0;
+	return PTR_ERR_OR_ZERO(phy->pll_ctrl_base);
 }
 
 static int ti_pipe3_probe(struct platform_device *pdev)
@@ -592,10 +589,7 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 	ti_pipe3_power_off(generic_phy);
 
 	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
-	if (IS_ERR(phy_provider))
-		return PTR_ERR(phy_provider);
-
-	return 0;
+	return PTR_ERR_OR_ZERO(phy_provider);
 }
 
 static int ti_pipe3_remove(struct platform_device *pdev)
diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c
index 873424a..3cbcb25 100644
--- a/drivers/phy/tegra/xusb.c
+++ b/drivers/phy/tegra/xusb.c
@@ -561,10 +561,7 @@ static int tegra_xusb_usb2_port_parse_dt(struct tegra_xusb_usb2_port *usb2)
 	usb2->internal = of_property_read_bool(np, "nvidia,internal");
 
 	usb2->supply = devm_regulator_get(&port->dev, "vbus");
-	if (IS_ERR(usb2->supply))
-		return PTR_ERR(usb2->supply);
-
-	return 0;
+	return PTR_ERR_OR_ZERO(usb2->supply);
 }
 
 static int tegra_xusb_add_usb2_port(struct tegra_xusb_padctl *padctl,
@@ -731,10 +728,7 @@ static int tegra_xusb_usb3_port_parse_dt(struct tegra_xusb_usb3_port *usb3)
 	usb3->internal = of_property_read_bool(np, "nvidia,internal");
 
 	usb3->supply = devm_regulator_get(&port->dev, "vbus");
-	if (IS_ERR(usb3->supply))
-		return PTR_ERR(usb3->supply);
-
-	return 0;
+	return PTR_ERR_OR_ZERO(usb3->supply);
 }
 
 static int tegra_xusb_add_usb3_port(struct tegra_xusb_padctl *padctl,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From vivek.gautam at codeaurora.org  Wed Oct 19 23:53:38 2016
From: vivek.gautam at codeaurora.org (Vivek Gautam)
Date: Thu, 20 Oct 2016 12:23:38 +0530
Subject: [PATCH 1/3] phy: fix semicolon.cocci warnings
Message-ID: <1476946420-698-1-git-send-email-vivek.gautam@codeaurora.org>

Remove unneeded semicolon.

Generated by: coccinellery/semicolon/semicolon.cocci

Signed-off-by: Vivek Gautam <vivek.gautam at codeaurora.org>
Cc: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/phy/phy-brcm-sata.c       | 6 +++---
 drivers/phy/phy-exynos4210-usb2.c | 4 ++--
 drivers/phy/phy-exynos4x12-usb2.c | 4 ++--
 drivers/phy/phy-exynos5250-usb2.c | 2 +-
 drivers/phy/phy-rockchip-emmc.c   | 2 +-
 drivers/phy/phy-s5pv210-usb2.c    | 4 ++--
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/phy/phy-brcm-sata.c b/drivers/phy/phy-brcm-sata.c
index 8ffc44a..ccbc3d9 100644
--- a/drivers/phy/phy-brcm-sata.c
+++ b/drivers/phy/phy-brcm-sata.c
@@ -140,7 +140,7 @@ static inline void __iomem *brcm_sata_pcb_base(struct brcm_sata_port *port)
 	default:
 		dev_err(priv->dev, "invalid phy version\n");
 		break;
-	};
+	}
 
 	return priv->phy_base + (port->portnum * size);
 }
@@ -157,7 +157,7 @@ static inline void __iomem *brcm_sata_ctrl_base(struct brcm_sata_port *port)
 	default:
 		dev_err(priv->dev, "invalid phy version\n");
 		break;
-	};
+	}
 
 	return priv->ctrl_base + (port->portnum * size);
 }
@@ -365,7 +365,7 @@ static int brcm_sata_phy_init(struct phy *phy)
 		break;
 	default:
 		rc = -ENODEV;
-	};
+	}
 
 	return rc;
 }
diff --git a/drivers/phy/phy-exynos4210-usb2.c b/drivers/phy/phy-exynos4210-usb2.c
index f30bbb0..1f50e10 100644
--- a/drivers/phy/phy-exynos4210-usb2.c
+++ b/drivers/phy/phy-exynos4210-usb2.c
@@ -141,7 +141,7 @@ static void exynos4210_isol(struct samsung_usb2_phy_instance *inst, bool on)
 		break;
 	default:
 		return;
-	};
+	}
 
 	regmap_update_bits(drv->reg_pmu, offset, mask, on ? 0 : mask);
 }
@@ -179,7 +179,7 @@ static void exynos4210_phy_pwr(struct samsung_usb2_phy_instance *inst, bool on)
 		rstbits =	EXYNOS_4210_URSTCON_PHY1_P1P2 |
 				EXYNOS_4210_URSTCON_HOST_LINK_P2;
 		break;
-	};
+	}
 
 	if (on) {
 		clk = readl(drv->reg_phy + EXYNOS_4210_UPHYCLK);
diff --git a/drivers/phy/phy-exynos4x12-usb2.c b/drivers/phy/phy-exynos4x12-usb2.c
index 765da90..7f27a91 100644
--- a/drivers/phy/phy-exynos4x12-usb2.c
+++ b/drivers/phy/phy-exynos4x12-usb2.c
@@ -187,7 +187,7 @@ static void exynos4x12_isol(struct samsung_usb2_phy_instance *inst, bool on)
 		break;
 	default:
 		return;
-	};
+	}
 
 	regmap_update_bits(drv->reg_pmu, offset, mask, on ? 0 : mask);
 }
@@ -237,7 +237,7 @@ static void exynos4x12_phy_pwr(struct samsung_usb2_phy_instance *inst, bool on)
 		rstbits =	EXYNOS_4x12_URSTCON_HSIC1 |
 				EXYNOS_4x12_URSTCON_HOST_LINK_P1;
 		break;
-	};
+	}
 
 	if (on) {
 		pwr = readl(drv->reg_phy + EXYNOS_4x12_UPHYPWR);
diff --git a/drivers/phy/phy-exynos5250-usb2.c b/drivers/phy/phy-exynos5250-usb2.c
index 2ed1735..aad8062 100644
--- a/drivers/phy/phy-exynos5250-usb2.c
+++ b/drivers/phy/phy-exynos5250-usb2.c
@@ -192,7 +192,7 @@ static void exynos5250_isol(struct samsung_usb2_phy_instance *inst, bool on)
 		break;
 	default:
 		return;
-	};
+	}
 
 	regmap_update_bits(drv->reg_pmu, offset, mask, on ? 0 : mask);
 }
diff --git a/drivers/phy/phy-rockchip-emmc.c b/drivers/phy/phy-rockchip-emmc.c
index fd57345..f1b24f1 100644
--- a/drivers/phy/phy-rockchip-emmc.c
+++ b/drivers/phy/phy-rockchip-emmc.c
@@ -132,7 +132,7 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
 		default:
 			ideal_rate = 200000000;
 			break;
-		};
+		}
 
 		diff = (rate > ideal_rate) ?
 			rate - ideal_rate : ideal_rate - rate;
diff --git a/drivers/phy/phy-s5pv210-usb2.c b/drivers/phy/phy-s5pv210-usb2.c
index 004d320..f6f7233 100644
--- a/drivers/phy/phy-s5pv210-usb2.c
+++ b/drivers/phy/phy-s5pv210-usb2.c
@@ -103,7 +103,7 @@ static void s5pv210_isol(struct samsung_usb2_phy_instance *inst, bool on)
 		break;
 	default:
 		return;
-	};
+	}
 
 	regmap_update_bits(drv->reg_pmu, S5PV210_USB_ISOL_OFFSET,
 							mask, on ? 0 : mask);
@@ -127,7 +127,7 @@ static void s5pv210_phy_pwr(struct samsung_usb2_phy_instance *inst, bool on)
 		rstbits =	S5PV210_URSTCON_PHY1_ALL |
 				S5PV210_URSTCON_HOST_LINK_ALL;
 		break;
-	};
+	}
 
 	if (on) {
 		writel(drv->ref_reg_val, drv->reg_phy + S5PV210_UPHYCLK);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From vivek.gautam at codeaurora.org  Wed Oct 19 23:53:40 2016
From: vivek.gautam at codeaurora.org (Vivek Gautam)
Date: Thu, 20 Oct 2016 12:23:40 +0530
Subject: [PATCH 3/3] phy: fix returnvar.cocci warnings
In-Reply-To: <1476946420-698-1-git-send-email-vivek.gautam@codeaurora.org>
References: <1476946420-698-1-git-send-email-vivek.gautam@codeaurora.org>
Message-ID: <1476946420-698-3-git-send-email-vivek.gautam@codeaurora.org>

Remove unneeded variables when "0" can be returned.

Generated by: scripts/coccinelle/misc/returnvar.cocci

Signed-off-by: Vivek Gautam <vivek.gautam at codeaurora.org>
Cc: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/phy/phy-berlin-sata.c     | 3 +--
 drivers/phy/tegra/xusb-tegra124.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/phy-berlin-sata.c b/drivers/phy/phy-berlin-sata.c
index f84a33a..2c7a57f 100644
--- a/drivers/phy/phy-berlin-sata.c
+++ b/drivers/phy/phy-berlin-sata.c
@@ -85,7 +85,6 @@ static int phy_berlin_sata_power_on(struct phy *phy)
 	struct phy_berlin_desc *desc = phy_get_drvdata(phy);
 	struct phy_berlin_priv *priv = dev_get_drvdata(phy->dev.parent);
 	void __iomem *ctrl_reg = priv->base + 0x60 + (desc->index * 0x80);
-	int ret = 0;
 	u32 regval;
 
 	clk_prepare_enable(priv->clk);
@@ -130,7 +129,7 @@ static int phy_berlin_sata_power_on(struct phy *phy)
 
 	clk_disable_unprepare(priv->clk);
 
-	return ret;
+	return 0;
 }
 
 static int phy_berlin_sata_power_off(struct phy *phy)
diff --git a/drivers/phy/tegra/xusb-tegra124.c b/drivers/phy/tegra/xusb-tegra124.c
index 1199572..c45cbed 100644
--- a/drivers/phy/tegra/xusb-tegra124.c
+++ b/drivers/phy/tegra/xusb-tegra124.c
@@ -1483,7 +1483,6 @@ static int tegra124_usb3_port_enable(struct tegra_xusb_port *port)
 	struct tegra_xusb_padctl *padctl = port->padctl;
 	struct tegra_xusb_lane *lane = usb3->base.lane;
 	unsigned int index = port->index, offset;
-	int ret = 0;
 	u32 value;
 
 	value = padctl_readl(padctl, XUSB_PADCTL_SS_PORT_MAP);
@@ -1612,7 +1611,7 @@ static int tegra124_usb3_port_enable(struct tegra_xusb_port *port)
 	value &= ~XUSB_PADCTL_ELPG_PROGRAM_SSPX_ELPG_CLAMP_EN(index);
 	padctl_writel(padctl, value, XUSB_PADCTL_ELPG_PROGRAM);
 
-	return ret;
+	return 0;
 }
 
 static void tegra124_usb3_port_disable(struct tegra_xusb_port *port)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From tomeu.vizoso at collabora.com  Thu Oct 20 00:18:04 2016
From: tomeu.vizoso at collabora.com (Tomeu Vizoso)
Date: Thu, 20 Oct 2016 09:18:04 +0200
Subject: the dp helper would try to enable the i2c channel for rockchip-edp
In-Reply-To: <24daffe0-42a4-2a37-d685-7d9ecf9c3b11@rock-chips.com>
References: <24daffe0-42a4-2a37-d685-7d9ecf9c3b11@rock-chips.com>
Message-ID: <CAAObsKBkQuUgk_p76Mc3U-tMy6mhX0puwKNoNHZcrWW1LRfbPg@mail.gmail.com>

On 19 October 2016 at 15:52, Randy Li <randy.li at rock-chips.com> wrote:
> Hello,
>
>   Recently, I want to use a eDP panel in my RK3288 platform, but I got the
> following message:
>
> [    8.935918] i2c i2c-6: of_i2c: modalias failure on /dp at ff970000/ports
> [    8.936018] rockchip-drm display-subsystem: bound ff970000.dp (ops
> rockchip_dp_component_ops [analogix_dp_rockchip])
> It try to enable the eDP aux channel and add a new I2C controller, but it
> failed then the whole display subsystem is broken, the panel doesn't power
> on either.
>
>   I hope somebody could figure out what is wrong with it.

Hi Randy,

you want to debug why the call to of_modalias_node fails.

Good luck,

Tomeu


>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


From randy.li at rock-chips.com  Thu Oct 20 00:38:29 2016
From: randy.li at rock-chips.com (Randy Li)
Date: Thu, 20 Oct 2016 15:38:29 +0800
Subject: the dp helper would try to enable the i2c channel for rockchip-edp
In-Reply-To: <CAAObsKBkQuUgk_p76Mc3U-tMy6mhX0puwKNoNHZcrWW1LRfbPg@mail.gmail.com>
References: <24daffe0-42a4-2a37-d685-7d9ecf9c3b11@rock-chips.com>
 <CAAObsKBkQuUgk_p76Mc3U-tMy6mhX0puwKNoNHZcrWW1LRfbPg@mail.gmail.com>
Message-ID: <410fd2c1-e841-cffb-51ba-cc4907c81203@rock-chips.com>



On 10/20/2016 03:18 PM, Tomeu Vizoso wrote:
> On 19 October 2016 at 15:52, Randy Li <randy.li at rock-chips.com> wrote:
>> Hello,
>>
>>   Recently, I want to use a eDP panel in my RK3288 platform, but I got the
>> following message:
>>
>> [    8.935918] i2c i2c-6: of_i2c: modalias failure on /dp at ff970000/ports
>> [    8.936018] rockchip-drm display-subsystem: bound ff970000.dp (ops
>> rockchip_dp_component_ops [analogix_dp_rockchip])
>> It try to enable the eDP aux channel and add a new I2C controller, but it
>> failed then the whole display subsystem is broken, the panel doesn't power
>> on either.
>>
>>   I hope somebody could figure out what is wrong with it.
>
> Hi Randy,
>
> you want to debug why the call to of_modalias_node fails.
>
But I didn't know who register that I2C controller, as the system only 
have 6 I2C controller(0-5).
> Good luck,
>
> Tomeu
>
>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

-- 
Randy Li
The third produce department
===========================================================================
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===========================================================================



From shawn.lin at rock-chips.com  Thu Oct 20 00:53:20 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Thu, 20 Oct 2016 15:53:20 +0800
Subject: [PATCH v2] PCI: rockchip: remove the pointer to L1 substate cap
Message-ID: <1476950000-16910-1-git-send-email-shawn.lin@rock-chips.com>

Per the errata of TRM, the RC can't support L1 substate, so we
need to remove the L1 substate cap as well as operation for
PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

Tested-by: Brian Norris <briannorris at chromium.org>
---

Changes in v2:
- Add Brian's tag and remove operation for PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2.

 drivers/pci/host/pcie-rockchip.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index e0b22da..a23c7f1 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -142,6 +142,8 @@
 #define   PCIE_RC_CONFIG_LCS_LBMS		BIT(30)
 #define   PCIE_RC_CONFIG_LCS_LAMS		BIT(31)
 #define PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 (PCIE_RC_CONFIG_BASE + 0x90c)
+#define PCIE_RC_CONFIG_THP_CAP		(PCIE_RC_CONFIG_BASE + 0x274)
+#define   PCIE_RC_CONFIG_THP_CAP_NEXT_MASK	GENMASK(31, 20)
 
 #define PCIE_CORE_AXI_CONF_BASE		0xc00000
 #define PCIE_CORE_OB_REGION_ADDR0	(PCIE_CORE_AXI_CONF_BASE + 0x0)
@@ -481,15 +483,6 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 		return err;
 	}
 
-	/*
-	 * We need to read/write PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 before
-	 * enabling ASPM.  Otherwise L1PwrOnSc and L1PwrOnVal isn't
-	 * reliable and enabling ASPM doesn't work.  This is a controller
-	 * bug we need to work around.
-	 */
-	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
-	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2);
-
 	/* Fix the transmitted FTS count desired to exit from L0s. */
 	status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL_PLC1);
 	status = (status & PCIE_CORE_CTRL_PLC1_FTS_MASK) |
@@ -558,6 +551,12 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 	rockchip_pcie_write(rockchip,
 			    PCI_CLASS_BRIDGE_PCI << PCIE_RC_CONFIG_SCC_SHIFT,
 			    PCIE_RC_CONFIG_RID_CCR);
+
+	/* Clear THP cap's next cap pointer to remove L1 substate cap */
+	status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_THP_CAP);
+	status &= ~PCIE_RC_CONFIG_THP_CAP_NEXT_MASK;
+	rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_THP_CAP);
+
 	rockchip_pcie_write(rockchip, 0x0, PCIE_RC_BAR_CONF);
 
 	rockchip_pcie_write(rockchip,
-- 
2.3.7




From tomeu.vizoso at collabora.com  Thu Oct 20 01:02:22 2016
From: tomeu.vizoso at collabora.com (Tomeu Vizoso)
Date: Thu, 20 Oct 2016 10:02:22 +0200
Subject: the dp helper would try to enable the i2c channel for rockchip-edp
In-Reply-To: <410fd2c1-e841-cffb-51ba-cc4907c81203@rock-chips.com>
References: <24daffe0-42a4-2a37-d685-7d9ecf9c3b11@rock-chips.com>
 <CAAObsKBkQuUgk_p76Mc3U-tMy6mhX0puwKNoNHZcrWW1LRfbPg@mail.gmail.com>
 <410fd2c1-e841-cffb-51ba-cc4907c81203@rock-chips.com>
Message-ID: <CAAObsKD-9NoBz28O7ekTGUz_nr6Sp2Ho43=dfccJUOoNtkx8Tg@mail.gmail.com>

On 20 October 2016 at 09:38, Randy Li <randy.li at rock-chips.com> wrote:
>
>
> On 10/20/2016 03:18 PM, Tomeu Vizoso wrote:
>>
>> On 19 October 2016 at 15:52, Randy Li <randy.li at rock-chips.com> wrote:
>>>
>>> Hello,
>>>
>>>   Recently, I want to use a eDP panel in my RK3288 platform, but I got
>>> the
>>> following message:
>>>
>>> [    8.935918] i2c i2c-6: of_i2c: modalias failure on /dp at ff970000/ports
>>> [    8.936018] rockchip-drm display-subsystem: bound ff970000.dp (ops
>>> rockchip_dp_component_ops [analogix_dp_rockchip])
>>> It try to enable the eDP aux channel and add a new I2C controller, but it
>>> failed then the whole display subsystem is broken, the panel doesn't
>>> power
>>> on either.
>>>
>>>   I hope somebody could figure out what is wrong with it.
>>
>>
>> Hi Randy,
>>
>> you want to debug why the call to of_modalias_node fails.
>>
> But I didn't know who register that I2C controller, as the system only have
> 6 I2C controller(0-5).

Ah, now I remember that the warning is spurious, have just sent a
patch to avoid it with you on Cc ("ARM: dts: rockchip: add i2c-bus
subnode to edp").

Could you please test it out?

Regarding why a 7th I2C adapter is being registered, that's the one
used by the eDP controller, and the code registering it is DRM core
when the analogix driver calls drm_dp_aux_register.

Regarding your problem with DRM not loading properly, you would need
to attach more content from dmesg as the lines you attached doesn't
seem related to it. You can get more debug logs from DRM by booting
with this kernel parameter:

drm.debug=0x1f

Regards,

Tomeu


From tomeu.vizoso at collabora.com  Thu Oct 20 01:07:25 2016
From: tomeu.vizoso at collabora.com (Tomeu Vizoso)
Date: Thu, 20 Oct 2016 10:07:25 +0200
Subject: [PATCH] ARM: dts: rockchip: add i2c-bus subnode to edp
Message-ID: <1476950845-28242-1-git-send-email-tomeu.vizoso@collabora.com>

Add an empty 'i2c-bus' subnode to the edp node just so that the I2C core
doesn't attemp to parse the 'ports' subnode as containing i2c devices.

This is to avoid spurious failure messages such as:

i2c i2c-6: of_i2c: modalias failure on /dp at ff970000/ports

Signed-off-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>
Cc: Randy Li <randy.li at rock-chips.com>
Cc: Jon Hunter <jonathanh at nvidia.com>
---
 arch/arm/boot/dts/rk3288.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 2f814ffeb605..94f4b7eecca2 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1075,6 +1075,11 @@
 				};
 			};
 		};
+
+		i2c-bus {
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
 	};
 
 	hdmi: hdmi at ff980000 {
-- 
2.7.4



From djkurtz at chromium.org  Thu Oct 20 01:57:36 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Thu, 20 Oct 2016 16:57:36 +0800
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <CAD=FV=UHB4sqf9sAg6Pbrp67sgjwJRUFPKsEh_PXwUCM+o59ZQ@mail.gmail.com>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
 <CAGS+omAT5gFD3vF7iz=Mc=CO00W_x2MSyGdpgD+tO2YfGnwpsA@mail.gmail.com>
 <CAD=FV=UHB4sqf9sAg6Pbrp67sgjwJRUFPKsEh_PXwUCM+o59ZQ@mail.gmail.com>
Message-ID: <CAGS+omB3197rGzwvNM66Ok4JtP=fUCRS349jmttk2NYXvd0KHA@mail.gmail.com>

On Wed, Oct 19, 2016 at 4:29 AM, Doug Anderson <dianders at chromium.org> wrote:
>
> Dan,
>
> On Tue, Oct 18, 2016 at 6:44 AM, Daniel Kurtz <djkurtz at chromium.org> wrote:
> > Hi Doug,
> >
> > On Tue, Oct 11, 2016 at 5:04 AM, Douglas Anderson <dianders at chromium.org> wrote:
> >> Users of usleep_range() expect that it will _never_ return in less time
> >> than the minimum passed parameter.  However, nothing in any of the code
> >> ensures this.  Specifically:
> >>
> >> usleep_range() => do_usleep_range() => schedule_hrtimeout_range() =>
> >> schedule_hrtimeout_range_clock() just ends up calling schedule() with an
> >> appropriate timeout set using the hrtimer.  If someone else happens to
> >> wake up our task then we'll happily return from usleep_range() early.
> >
> > I think this change works, and fixes a real issue, however, I don't
> > think you are fixing this at the right layer.
> > The comment for schedule_hrtimeout_range says:
> >
> > /**
> >  * schedule_hrtimeout_range - sleep until timeout
> >  * @expires:    timeout value (ktime_t)
> >  * @delta:      slack in expires timeout (ktime_t)
> >  * @mode:       timer mode, HRTIMER_MODE_ABS or HRTIMER_MODE_REL
> >  *
> >  * Make the current task sleep until the given expiry time has
> >  * elapsed. The routine will return immediately unless
> >  * the current task state has been set (see set_current_state()).
> >  *
> >  * The @delta argument gives the kernel the freedom to schedule the
> >  * actual wakeup to a time that is both power and performance friendly.
> >  * The kernel give the normal best effort behavior for "@expires+ at delta",
> >  * but may decide to fire the timer earlier, but no earlier than @expires.
> >  *
> >  * You can set the task state as follows -
> >  *
> >  * %TASK_UNINTERRUPTIBLE - at least @timeout time is guaranteed to
> >  * pass before the routine returns.
> >  *
> >  * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
> >  * delivered to the current task.
> >  *
> >  * The current task state is guaranteed to be TASK_RUNNING when this
> >  * routine returns.
> >  *
> >  * Returns 0 when the timer has expired otherwise -EINTR
> >  */
> >
> > The behavior as specified for this function "at least @timeout time is
> > guaranteed to pass before the routine returns" already guarantees the
> > behavior you are adding to do_usleep_range() whenever the current task
> > state is (pre-)set to TASK_UNINTERRUPTIBLE.
> >
> > Thus, I think the loop around 'schedule()' should be moved to
> > schedule_hrtimeout_range() itself.
> > This would also fix direct callers of schedule_hrtimeout_range() that
> > use TASK_UNINTERRUPTIBLE, although, I could only find one:
> >
> > pt3_fetch_thread()
>
> Hmmm, I would agree with you that the behavior of
> schedule_hrtimeout_range() doesn't seem to match the function
> comments.
>
> ...but I'm not sure I agree with you about what to do here.
> Specifically I think that whatever we do we need to try to keep
> schedule_hrtimeout_range() and schedule_timeout() parallel.  For
> schedule_timeout() we have the same comments but it's my understanding
> that you'd expect that wake_up_process() would wake it up.  In any
> case, if wake_up_process() doesn't wake it up then it seems like
> msleep() and schedule_timeout_uninterruptible() are the same function
> with two names, when in fact one is implemented in terms o the other.

Sounds reasonable.
It would be nice to add a note to all of those function comments
though to make them sound less absolute -
"at least @timeout time is guaranteed to pass before the routine
returns unless the current task is explicitly woken up, (e.g. by
wake_up_process())"

> NOTE that also it seems as if we need some other return values besides
> 0 and -EINTR from schedule_hrtimeout_range() (again, to match
> schedule_timeout()) since right now we'll return -EINTR if we were
> woken up with wake_up_process().  This would be unexpected in the case
> where we had TASK_UNINTERRUPTIBLE set.
>
> -Doug


From tglx at linutronix.de  Thu Oct 20 02:51:12 2016
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 20 Oct 2016 11:51:12 +0200 (CEST)
Subject: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <CAGS+omB3197rGzwvNM66Ok4JtP=fUCRS349jmttk2NYXvd0KHA@mail.gmail.com>
References: <1476133442-17757-1-git-send-email-dianders@chromium.org>
 <CAGS+omAT5gFD3vF7iz=Mc=CO00W_x2MSyGdpgD+tO2YfGnwpsA@mail.gmail.com>
 <CAD=FV=UHB4sqf9sAg6Pbrp67sgjwJRUFPKsEh_PXwUCM+o59ZQ@mail.gmail.com>
 <CAGS+omB3197rGzwvNM66Ok4JtP=fUCRS349jmttk2NYXvd0KHA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1610201150510.5073@nanos>

On Thu, 20 Oct 2016, Daniel Kurtz wrote:
> On Wed, Oct 19, 2016 at 4:29 AM, Doug Anderson <dianders at chromium.org> wrote:
> > ...but I'm not sure I agree with you about what to do here.
> > Specifically I think that whatever we do we need to try to keep
> > schedule_hrtimeout_range() and schedule_timeout() parallel.  For
> > schedule_timeout() we have the same comments but it's my understanding
> > that you'd expect that wake_up_process() would wake it up.  In any
> > case, if wake_up_process() doesn't wake it up then it seems like
> > msleep() and schedule_timeout_uninterruptible() are the same function
> > with two names, when in fact one is implemented in terms o the other.
> 
> Sounds reasonable.
> It would be nice to add a note to all of those function comments
> though to make them sound less absolute -
> "at least @timeout time is guaranteed to pass before the routine
> returns unless the current task is explicitly woken up, (e.g. by
> wake_up_process())"

Agreed.


From heiko at sntech.de  Thu Oct 20 06:45:34 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Thu, 20 Oct 2016 15:45:34 +0200
Subject: [PATCH] ARM: dts: rockchip: add i2c-bus subnode to edp
In-Reply-To: <1476950845-28242-1-git-send-email-tomeu.vizoso@collabora.com>
References: <1476950845-28242-1-git-send-email-tomeu.vizoso@collabora.com>
Message-ID: <7604646.6yosK0XMNL@diego>

Am Donnerstag, 20. Oktober 2016, 10:07:25 schrieb Tomeu Vizoso:
> Add an empty 'i2c-bus' subnode to the edp node just so that the I2C core
> doesn't attemp to parse the 'ports' subnode as containing i2c devices.
> 
> This is to avoid spurious failure messages such as:
> 
> i2c i2c-6: of_i2c: modalias failure on /dp at ff970000/ports

On the one hand, the edp really has an i2c bus - with its only client the EDID 
listening at 0x50 (and maybe 0x30).

On the other hand, adding an empty bus to the (implementation independent) 
devicetree just to make the Linux i2c subsystem happy sounds heavily like a 
implementation-specific hack, as the edp i2c bus doesn't leak into the outside 
world otherwise.

I guess this empty i2c bus not being part of the binding document points 
heavily into the implementation-specific corner :-) .

My short search on other patches touching this didn't reveal anything but 
maybe this was already discussed somewhere and found to be ok?


Another option could be to just make of_i2c_register_device silent if 
of_modalias_node returns -ENODEV?


Heiko

> Signed-off-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>
> Cc: Randy Li <randy.li at rock-chips.com>
> Cc: Jon Hunter <jonathanh at nvidia.com>
> ---
>  arch/arm/boot/dts/rk3288.dtsi | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index 2f814ffeb605..94f4b7eecca2 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -1075,6 +1075,11 @@
>  				};
>  			};
>  		};
> +
> +		i2c-bus {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
>  	};
> 
>  	hdmi: hdmi at ff980000 {



From tomeu.vizoso at collabora.com  Thu Oct 20 06:47:56 2016
From: tomeu.vizoso at collabora.com (Tomeu Vizoso)
Date: Thu, 20 Oct 2016 15:47:56 +0200
Subject: [PATCH] ARM: dts: rockchip: add i2c-bus subnode to edp
In-Reply-To: <7604646.6yosK0XMNL@diego>
References: <1476950845-28242-1-git-send-email-tomeu.vizoso@collabora.com>
 <7604646.6yosK0XMNL@diego>
Message-ID: <6083453f-08e1-643a-9638-1db38c704aa5@collabora.com>

On 10/20/2016 03:45 PM, Heiko St?bner wrote:
> Am Donnerstag, 20. Oktober 2016, 10:07:25 schrieb Tomeu Vizoso:
>> Add an empty 'i2c-bus' subnode to the edp node just so that the I2C core
>> doesn't attemp to parse the 'ports' subnode as containing i2c devices.
>>
>> This is to avoid spurious failure messages such as:
>>
>> i2c i2c-6: of_i2c: modalias failure on /dp at ff970000/ports
> 
> On the one hand, the edp really has an i2c bus - with its only client the EDID 
> listening at 0x50 (and maybe 0x30).
> 
> On the other hand, adding an empty bus to the (implementation independent) 
> devicetree just to make the Linux i2c subsystem happy sounds heavily like a 
> implementation-specific hack, as the edp i2c bus doesn't leak into the outside 
> world otherwise.
> 
> I guess this empty i2c bus not being part of the binding document points 
> heavily into the implementation-specific corner :-) .
> 
> My short search on other patches touching this didn't reveal anything but 
> maybe this was already discussed somewhere and found to be ok?

Here it is:

http://www.spinics.net/lists/linux-tegra/msg27862.html

Regards,

Tomeu

> Another option could be to just make of_i2c_register_device silent if 
> of_modalias_node returns -ENODEV?
> 
> 
> Heiko
> 
>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>
>> Cc: Randy Li <randy.li at rock-chips.com>
>> Cc: Jon Hunter <jonathanh at nvidia.com>
>> ---
>>  arch/arm/boot/dts/rk3288.dtsi | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
>> index 2f814ffeb605..94f4b7eecca2 100644
>> --- a/arch/arm/boot/dts/rk3288.dtsi
>> +++ b/arch/arm/boot/dts/rk3288.dtsi
>> @@ -1075,6 +1075,11 @@
>>  				};
>>  			};
>>  		};
>> +
>> +		i2c-bus {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +		};
>>  	};
>>
>>  	hdmi: hdmi at ff980000 {
> 



From dianders at chromium.org  Thu Oct 20 13:34:23 2016
From: dianders at chromium.org (Douglas Anderson)
Date: Thu, 20 Oct 2016 13:34:23 -0700
Subject: [PATCH v3 1/2] timers: Fix usleep_range() in the context of
 wake_up_process()
Message-ID: <1476995664-15668-1-git-send-email-dianders@chromium.org>

Users of usleep_range() expect that it will _never_ return in less time
than the minimum passed parameter.  However, nothing in any of the code
ensures this.  Specifically:

usleep_range() => do_usleep_range() => schedule_hrtimeout_range() =>
schedule_hrtimeout_range_clock() just ends up calling schedule() with an
appropriate timeout set using the hrtimer.  If someone else happens to
wake up our task then we'll happily return from usleep_range() early.

msleep() already has code to handle this case since it will loop as long
as there was still time left.  usleep_range() had no such loop.

The problem is is easily demonstrated with a small bit of test code:

  static int usleep_test_task(void *data)
  {
    atomic_t *done = data;
    ktime_t start, end;

    start = ktime_get();
    usleep_range(50000, 100000);
    end = ktime_get();
    pr_info("Requested 50000 - 100000 us.  Actually slept for %llu us\n",
      (unsigned long long)ktime_to_us(ktime_sub(end, start)));
    atomic_set(done, 1);

    return 0;
  }

  static void run_usleep_test(void)
  {
    struct task_struct *t;
    atomic_t done;

    atomic_set(&done, 0);

    t = kthread_run(usleep_test_task, &done, "usleep_test_task");
    while (!atomic_read(&done)) {
      wake_up_process(t);
      udelay(1000);
    }
    kthread_stop(t);
  }

If you run the above code without this patch you get things like:
  Requested 50000 - 100000 us.  Actually slept for 967 us

If you run the above code _with_ this patch, you get:
  Requested 50000 - 100000 us.  Actually slept for 50001 us

Presumably this problem was not detected before because:
- It's not terribly common to use wake_up_process() directly.
- Other ways for processes to wake up are not typically mixed with
  usleep_range().
- There aren't lots of places that use usleep_range(), since many people
  call either msleep() or udelay().

NOTES:
- An effort was made to look for users relying on the old behavior by
  looking for usleep_range() in the same file as wake_up_process().
  No problems was found by this search, though it is conceivable that
  someone could have put the sleep and wakeup in two different files.
- An effort was made to ask several upstream maintainers if they were
  aware of people relying on wake_up_process() to wake up
  usleep_range().  No maintainers were aware of that but they were aware
  of many people relying on usleep_range() never returning before the
  minimum.

Reported-by: Tao Huang <huangtao at rock-chips.com>
Signed-off-by: Douglas Anderson <dianders at chromium.org>
Reviewed-by: Andreas Mohr <andim2 at users.sf.net>
Reviewed-by: Brian Norris <briannorris at chromium.org>
Reviewed-by: Guenter Roeck <linux at roeck-us.net>
---
Changes in v3:
- Add Reviewed-by tags
- Add notes about validation

Changes in v2:
- Fixed stupid bug that snuck in before posting
- Use ktime_before
- Remove delta from the loop

 kernel/time/timer.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 32bf6f75a8fe..219439efd56a 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1898,12 +1898,28 @@ EXPORT_SYMBOL(msleep_interruptible);
 
 static void __sched do_usleep_range(unsigned long min, unsigned long max)
 {
+	ktime_t now, end;
 	ktime_t kmin;
 	u64 delta;
+	int ret;
 
-	kmin = ktime_set(0, min * NSEC_PER_USEC);
+	now = ktime_get();
+	end = ktime_add_us(now, min);
 	delta = (u64)(max - min) * NSEC_PER_USEC;
-	schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
+	do {
+		kmin = ktime_sub(end, now);
+		ret = schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
+
+		/*
+		 * If schedule_hrtimeout_range() returns 0 then we actually
+		 * hit the timeout. If not then we need to re-calculate the
+		 * new timeout ourselves.
+		 */
+		if (ret == 0)
+			break;
+
+		now = ktime_get();
+	} while (ktime_before(now, end));
 }
 
 /**
-- 
2.8.0.rc3.226.g39d4020



From dianders at chromium.org  Thu Oct 20 13:34:24 2016
From: dianders at chromium.org (Douglas Anderson)
Date: Thu, 20 Oct 2016 13:34:24 -0700
Subject: [PATCH v3 2/2] timers: Fix documentation for schedule_timeout() and
 similar
In-Reply-To: <1476995664-15668-1-git-send-email-dianders@chromium.org>
References: <1476995664-15668-1-git-send-email-dianders@chromium.org>
Message-ID: <1476995664-15668-2-git-send-email-dianders@chromium.org>

The documentatoin for schedule_timeout(), schedule_hrtimeout(), and
schedule_hrtimeout_range() all claimed that the routines couldn't
possibly return early if the task state was TASK_UNINTERRUPTIBLE.  This
was simply not true, since anyone calling wake_up_process() would cause
those routines to exit early.

As some evidence that the documentation was broken (not the code):
- If we changed the code to match the documentation, msleep() would be
  identical to schedule_timeout_uninterruptible() and
  msleep_interruptible() would be identical to
  schedule_timeout_interruptible().  That doesn't seem likely to have
  been the intention.
- The schedule() function sleeps until a task is woken up.  Logically,
  one would expect that the schedule_timeout() function would sleep
  until a task is woken up or a timeout occurrs.

As part of the above observation, it can be seen that
schedule_hrtimeout() and schedule_hrtimeout_range() might return -EINTR
even if the task state was TASK_UNINTERRUPTIBLE.  This isn't terrible
behavior so we'll document it and keep it as-is.  After all, trying to
match schedule_timeout() and return the time left would incure a bunch
of extra calculation cost that isn't needed in all cases.

Suggested-by: Daniel Kurtz <djkurtz at chromium.org>
Signed-off-by: Douglas Anderson <dianders at chromium.org>
---
Changes in v3:
- Documentation fix new for v3.

 kernel/time/hrtimer.c | 20 ++++++++++++++------
 kernel/time/timer.c   | 11 +++++++----
 2 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index bb5ec425dfe0..707ecf47a5fd 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1742,15 +1742,19 @@ schedule_hrtimeout_range_clock(ktime_t *expires, u64 delta,
  * You can set the task state as follows -
  *
  * %TASK_UNINTERRUPTIBLE - at least @timeout time is guaranteed to
- * pass before the routine returns.
+ * pass before the routine returns unless the current task is explicitly
+ * woken up, (e.g. by wake_up_process())".
  *
  * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
- * delivered to the current task.
+ * delivered to the current task or the current task is explicitly woken
+ * up.
  *
  * The current task state is guaranteed to be TASK_RUNNING when this
  * routine returns.
  *
- * Returns 0 when the timer has expired otherwise -EINTR
+ * Returns 0 when the timer has expired otherwise -EINTR. Note that
+ * -EINTR can still be returned even if the task state is
+ * TASK_UNINTERRUPTIBLE if the current task is explicitly woken up.
  */
 int __sched schedule_hrtimeout_range(ktime_t *expires, u64 delta,
 				     const enum hrtimer_mode mode)
@@ -1772,15 +1776,19 @@ EXPORT_SYMBOL_GPL(schedule_hrtimeout_range);
  * You can set the task state as follows -
  *
  * %TASK_UNINTERRUPTIBLE - at least @timeout time is guaranteed to
- * pass before the routine returns.
+ * pass before the routine returns unless the current task is explicitly
+ * woken up, (e.g. by wake_up_process())".
  *
  * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
- * delivered to the current task.
+ * delivered to the current task or the current task is explicitly woken
+ * up.
  *
  * The current task state is guaranteed to be TASK_RUNNING when this
  * routine returns.
  *
- * Returns 0 when the timer has expired otherwise -EINTR
+ * Returns 0 when the timer has expired otherwise -EINTR. Note that
+ * -EINTR can still be returned even if the task state is
+ * TASK_UNINTERRUPTIBLE if the current task is explicitly woken up.
  */
 int __sched schedule_hrtimeout(ktime_t *expires,
 			       const enum hrtimer_mode mode)
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 219439efd56a..b2ca2a6bc4d2 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1691,11 +1691,12 @@ static void process_timeout(unsigned long __data)
  * You can set the task state as follows -
  *
  * %TASK_UNINTERRUPTIBLE - at least @timeout jiffies are guaranteed to
- * pass before the routine returns. The routine will return 0
+ * pass before the routine returns unless the current task is explicitly
+ * woken up, (e.g. by wake_up_process())".
  *
  * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
- * delivered to the current task. In this case the remaining time
- * in jiffies will be returned, or 0 if the timer expired in time
+ * delivered to the current task or the current task is explicitly woken
+ * up.
  *
  * The current task state is guaranteed to be TASK_RUNNING when this
  * routine returns.
@@ -1704,7 +1705,9 @@ static void process_timeout(unsigned long __data)
  * the CPU away without a bound on the timeout. In this case the return
  * value will be %MAX_SCHEDULE_TIMEOUT.
  *
- * In all cases the return value is guaranteed to be non-negative.
+ * Returns 0 when the timer has expired otherwise the remaining time in
+ * jiffies will be returned.  In all cases the return value is guaranteed
+ * to be non-negative.
  */
 signed long __sched schedule_timeout(signed long timeout)
 {
-- 
2.8.0.rc3.226.g39d4020



From seanpaul at chromium.org  Thu Oct 20 13:39:04 2016
From: seanpaul at chromium.org (Sean Paul)
Date: Thu, 20 Oct 2016 16:39:04 -0400
Subject: [PATCH] drm: convert DT component matching to
 component_match_add_release()
In-Reply-To: <E1bwo6l-0005Io-Q1@rmk-PC.armlinux.org.uk>
References: <E1bwo6l-0005Io-Q1@rmk-PC.armlinux.org.uk>
Message-ID: <CAOw6vbK=z3wJKTh8jZoU2Gj1PtTLLH_sAUUShbsxL=Qi7d+FLw@mail.gmail.com>

On Wed, Oct 19, 2016 at 6:28 AM, Russell King
<rmk+kernel at armlinux.org.uk> wrote:
> Convert DT component matching to use component_match_add_release().
>
> Signed-off-by: Russell King <rmk+kernel at armlinux.org.uk>
> ---
> Can we please get this patch from May merged into the drm-misc or
> whatever trees so that we don't end up with conflicts?  I've no idea
> who looks after drm-misc, as they have _still_ failed to add
> themselves to MAINTAINERS.

I think Daniel explained pretty clearly why this wasn't happening in
the previous thread.

Next time you send a v2, can you please mark it as such and include a
"Changes in v2" section?

>
>  drivers/gpu/drm/arm/hdlcd_drv.c                 |  3 ++-
>  drivers/gpu/drm/arm/malidp_drv.c                |  4 +++-
>  drivers/gpu/drm/armada/armada_drv.c             |  2 +-
>  drivers/gpu/drm/drm_of.c                        | 28 +++++++++++++++++++++++--
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c           |  5 +++--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  7 ++++---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c          |  4 +++-
>  drivers/gpu/drm/msm/msm_drv.c                   | 12 ++++++-----
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c     |  6 ++++--
>  drivers/gpu/drm/sti/sti_drv.c                   |  5 +++--
>  drivers/gpu/drm/sun4i/sun4i_drv.c               |  3 ++-
>  drivers/gpu/drm/tilcdc/tilcdc_external.c        |  4 +++-
>  include/drm/drm_of.h                            | 12 +++++++++++
>  13 files changed, 73 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index fb6a418ce6be..6477d1a65266 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -453,7 +453,8 @@ static int hdlcd_probe(struct platform_device *pdev)
>                 return -EAGAIN;
>         }
>
> -       component_match_add(&pdev->dev, &match, compare_dev, port);
> +       drm_of_component_match_add(&pdev->dev, &match, compare_dev, port);
> +       of_node_put(port);

There's no mention in your commit message about fixing these node leaks.

>
>         return component_master_add_with_match(&pdev->dev, &hdlcd_master_ops,
>                                                match);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> index 9280358b8f15..9f4739452a25 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -493,7 +493,9 @@ static int malidp_platform_probe(struct platform_device *pdev)
>                 return -EAGAIN;
>         }
>
> -       component_match_add(&pdev->dev, &match, malidp_compare_dev, port);
> +       drm_of_component_match_add(&pdev->dev, &match, malidp_compare_dev,
> +                                  port);
> +       of_node_put(port);
>         return component_master_add_with_match(&pdev->dev, &malidp_master_ops,
>                                                match);
>  }
> diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
> index 1e0e68f608e4..94e46da9a758 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -254,7 +254,7 @@ static void armada_add_endpoints(struct device *dev,
>                         continue;
>                 }
>
> -               component_match_add(dev, match, compare_of, remote);
> +               drm_of_component_match_add(dev, match, compare_of, remote);
>                 of_node_put(remote);
>         }
>  }
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index bc98bb94264d..47848ed8ca48 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -6,6 +6,11 @@
>  #include <drm/drm_crtc.h>
>  #include <drm/drm_of.h>
>
> +static void drm_release_of(struct device *dev, void *data)
> +{
> +       of_node_put(data);
> +}
> +
>  /**
>   * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
>   * @dev: DRM device
> @@ -64,6 +69,24 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>  EXPORT_SYMBOL(drm_of_find_possible_crtcs);
>
>  /**
> + * drm_of_component_match_add - Add a component helper OF node match rule
> + * @master: master device
> + * @matchptr: component match pointer
> + * @compare: compare function used for matching component
> + * @node: of_node
> + */
> +void drm_of_component_match_add(struct device *master,
> +                               struct component_match **matchptr,
> +                               int (*compare)(struct device *, void *),
> +                               struct device_node *node)
> +{
> +       of_node_get(node);
> +       component_match_add_release(master, matchptr, drm_release_of,
> +                                   compare, node);
> +}
> +EXPORT_SYMBOL_GPL(drm_of_component_match_add);
> +
> +/**
>   * drm_of_component_probe - Generic probe function for a component based master
>   * @dev: master device containing the OF node
>   * @compare_of: compare function used for matching components
> @@ -101,7 +124,7 @@ int drm_of_component_probe(struct device *dev,
>                         continue;
>                 }
>
> -               component_match_add(dev, &match, compare_of, port);
> +               drm_of_component_match_add(dev, &match, compare_of, port);
>                 of_node_put(port);
>         }
>
> @@ -140,7 +163,8 @@ int drm_of_component_probe(struct device *dev,
>                                 continue;
>                         }
>
> -                       component_match_add(dev, &match, compare_of, remote);
> +                       drm_of_component_match_add(dev, &match, compare_of,
> +                                                  remote);
>                         of_node_put(remote);
>                 }
>                 of_node_put(port);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index aa687669e22b..0dee6acbd880 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -16,6 +16,7 @@
>
>  #include <linux/component.h>
>  #include <linux/of_platform.h>
> +#include <drm/drm_of.h>
>
>  #include "etnaviv_drv.h"
>  #include "etnaviv_gpu.h"
> @@ -629,8 +630,8 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
>                         if (!core_node)
>                                 break;
>
> -                       component_match_add(&pdev->dev, &match, compare_of,
> -                                           core_node);
> +                       drm_of_component_match_add(&pdev->dev, &match,
> +                                                  compare_of, core_node);
>                         of_node_put(core_node);
>                 }
>         } else if (dev->platform_data) {
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> index 90377a609c98..e88fde18c946 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -24,6 +24,7 @@
>  #include <drm/drm_fb_cma_helper.h>
>  #include <drm/drm_atomic_helper.h>
>  #include <drm/drm_crtc_helper.h>
> +#include <drm/drm_of.h>
>
>  #include "kirin_drm_drv.h"
>
> @@ -260,14 +261,13 @@ static struct device_node *kirin_get_remote_node(struct device_node *np)
>                 DRM_ERROR("no valid endpoint node\n");
>                 return ERR_PTR(-ENODEV);
>         }
> -       of_node_put(endpoint);
>
>         remote = of_graph_get_remote_port_parent(endpoint);
> +       of_node_put(endpoint);

Another bug that's being fixed without mention in the commit.

>         if (!remote) {
>                 DRM_ERROR("no valid remote node\n");
>                 return ERR_PTR(-ENODEV);
>         }
> -       of_node_put(remote);
>
>         if (!of_device_is_available(remote)) {
>                 DRM_ERROR("not available for remote node\n");
> @@ -294,7 +294,8 @@ static int kirin_drm_platform_probe(struct platform_device *pdev)
>         if (IS_ERR(remote))
>                 return PTR_ERR(remote);
>
> -       component_match_add(dev, &match, compare_of, remote);
> +       drm_of_component_match_add(dev, &match, compare_of, remote);
> +       of_node_put(remote);
>
>         return component_master_add_with_match(dev, &kirin_drm_ops, match);
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index cf83f6507ec8..9c5430fb82a2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -18,6 +18,7 @@
>  #include <drm/drm_crtc_helper.h>
>  #include <drm/drm_gem.h>
>  #include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_of.h>
>  #include <linux/component.h>
>  #include <linux/iommu.h>
>  #include <linux/of_address.h>
> @@ -415,7 +416,8 @@ static int mtk_drm_probe(struct platform_device *pdev)
>                     comp_type == MTK_DPI) {
>                         dev_info(dev, "Adding component match for %s\n",
>                                  node->full_name);
> -                       component_match_add(dev, &match, compare_of, node);
> +                       drm_of_component_match_add(dev, &match, compare_of,
> +                                                  node);
>                 } else {
>                         struct mtk_ddp_comp *comp;
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index fb5c0b0a7594..84d38eaea585 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -15,6 +15,8 @@
>   * this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>
> +#include <drm/drm_of.h>
> +
>  #include "msm_drv.h"
>  #include "msm_debugfs.h"
>  #include "msm_fence.h"
> @@ -919,8 +921,8 @@ static int add_components_mdp(struct device *mdp_dev,
>                         continue;
>                 }
>
> -               component_match_add(master_dev, matchptr, compare_of, intf);
> -
> +               drm_of_component_match_add(master_dev, matchptr, compare_of,
> +                                          intf);
>                 of_node_put(intf);
>                 of_node_put(ep_node);
>         }
> @@ -962,8 +964,8 @@ static int add_display_components(struct device *dev,
>                 put_device(mdp_dev);
>
>                 /* add the MDP component itself */
> -               component_match_add(dev, matchptr, compare_of,
> -                                   mdp_dev->of_node);
> +               drm_of_component_match_add(dev, matchptr, compare_of,
> +                                          mdp_dev->of_node);
>         } else {
>                 /* MDP4 */
>                 mdp_dev = dev;
> @@ -996,7 +998,7 @@ static int add_gpu_components(struct device *dev,
>         if (!np)
>                 return 0;
>
> -       component_match_add(dev, matchptr, compare_of, np);
> +       drm_of_component_match_add(dev, matchptr, compare_of, np);
>
>         of_node_put(np);
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 8c8cbe837e61..6fe161192bb4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -20,6 +20,7 @@
>  #include <drm/drm_crtc_helper.h>
>  #include <drm/drm_fb_helper.h>
>  #include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_of.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/module.h>
> @@ -388,7 +389,7 @@ static void rockchip_add_endpoints(struct device *dev,
>                         continue;
>                 }
>
> -               component_match_add(dev, match, compare_of, remote);
> +               drm_of_component_match_add(dev, match, compare_of, remote);
>                 of_node_put(remote);
>         }
>  }
> @@ -437,7 +438,8 @@ static int rockchip_drm_platform_probe(struct platform_device *pdev)
>                 }
>
>                 of_node_put(iommu);
> -               component_match_add(dev, &match, compare_of, port->parent);
> +               drm_of_component_match_add(dev, &match, compare_of,
> +                                          port->parent);
>                 of_node_put(port);
>         }
>
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index 2784919a7366..5e819876e642 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -17,6 +17,7 @@
>  #include <drm/drm_crtc_helper.h>
>  #include <drm/drm_gem_cma_helper.h>
>  #include <drm/drm_fb_cma_helper.h>
> +#include <drm/drm_of.h>
>
>  #include "sti_crtc.h"
>  #include "sti_drv.h"
> @@ -423,8 +424,8 @@ static int sti_platform_probe(struct platform_device *pdev)
>         child_np = of_get_next_available_child(node, NULL);
>
>         while (child_np) {
> -               component_match_add(dev, &match, compare_of, child_np);
> -               of_node_put(child_np);
> +               drm_of_component_match_add(dev, &match, compare_of,
> +                                          child_np);
>                 child_np = of_get_next_available_child(node, child_np);
>         }
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 0da9862ad8ed..b3c4ad605e81 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -18,6 +18,7 @@
>  #include <drm/drm_fb_cma_helper.h>
>  #include <drm/drm_gem_cma_helper.h>
>  #include <drm/drm_fb_helper.h>
> +#include <drm/drm_of.h>
>
>  #include "sun4i_crtc.h"
>  #include "sun4i_drv.h"
> @@ -239,7 +240,7 @@ static int sun4i_drv_add_endpoints(struct device *dev,
>                 /* Add current component */
>                 DRM_DEBUG_DRIVER("Adding component %s\n",
>                                  of_node_full_name(node));
> -               component_match_add(dev, match, compare_of, node);
> +               drm_of_component_match_add(dev, match, compare_of, node);
>                 count++;
>         }
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> index 68e895021005..06a4c584f3cb 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> @@ -10,6 +10,7 @@
>
>  #include <linux/component.h>
>  #include <linux/of_graph.h>
> +#include <drm/drm_of.h>
>
>  #include "tilcdc_drv.h"
>  #include "tilcdc_external.h"
> @@ -160,7 +161,8 @@ int tilcdc_get_external_components(struct device *dev,
>
>                 dev_dbg(dev, "Subdevice node '%s' found\n", node->name);
>                 if (match)
> -                       component_match_add(dev, match, dev_match_of, node);
> +                       drm_of_component_match_add(dev, match, dev_match_of,
> +                                                  node);
>                 of_node_put(node);
>                 count++;
>         }
> diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> index 3fd87b386ed7..d6b4c5587bbe 100644
> --- a/include/drm/drm_of.h
> +++ b/include/drm/drm_of.h
> @@ -4,6 +4,7 @@
>  #include <linux/of_graph.h>
>
>  struct component_master_ops;
> +struct component_match;
>  struct device;
>  struct drm_device;
>  struct drm_encoder;
> @@ -12,6 +13,10 @@ struct device_node;
>  #ifdef CONFIG_OF
>  extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>                                            struct device_node *port);
> +extern void drm_of_component_match_add(struct device *master,
> +                                      struct component_match **matchptr,
> +                                      int (*compare)(struct device *, void *),
> +                                      struct device_node *node);
>  extern int drm_of_component_probe(struct device *dev,
>                                   int (*compare_of)(struct device *, void *),
>                                   const struct component_master_ops *m_ops);
> @@ -25,6 +30,13 @@ static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>         return 0;
>  }
>
> +static void drm_of_component_match_add(struct device *master,
> +                                      struct component_match **matchptr,
> +                                      int (*compare)(struct device *, void *),
> +                                      struct device_node *node)
> +{
> +}
> +
>  static inline int
>  drm_of_component_probe(struct device *dev,
>                        int (*compare_of)(struct device *, void *),
> --
> 2.1.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From tglx at linutronix.de  Thu Oct 20 14:06:48 2016
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 20 Oct 2016 23:06:48 +0200 (CEST)
Subject: [PATCH v3 2/2] timers: Fix documentation for schedule_timeout()
 and similar
In-Reply-To: <1476995664-15668-2-git-send-email-dianders@chromium.org>
References: <1476995664-15668-1-git-send-email-dianders@chromium.org>
 <1476995664-15668-2-git-send-email-dianders@chromium.org>
Message-ID: <alpine.DEB.2.20.1610202254071.4938@nanos>

On Thu, 20 Oct 2016, Douglas Anderson wrote:
> +++ b/kernel/time/hrtimer.c
> @@ -1742,15 +1742,19 @@ schedule_hrtimeout_range_clock(ktime_t *expires, u64 delta,
>   * You can set the task state as follows -
>   *
>   * %TASK_UNINTERRUPTIBLE - at least @timeout time is guaranteed to
> - * pass before the routine returns.
> + * pass before the routine returns unless the current task is explicitly
> + * woken up, (e.g. by wake_up_process())".

The double quote is stray.

>   *
>   * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
> - * delivered to the current task.
> + * delivered to the current task or the current task is explicitly woken
> + * up.
>   *
>   * The current task state is guaranteed to be TASK_RUNNING when this
>   * routine returns.
>   *
> - * Returns 0 when the timer has expired otherwise -EINTR
> + * Returns 0 when the timer has expired otherwise -EINTR. Note that
> + * -EINTR can still be returned even if the task state is
> + * TASK_UNINTERRUPTIBLE if the current task is explicitly woken up.

I'd prefer to word it this way:

Returns 0 when the timer has expired. If the task was woken before the
timer expired by a signal (only possible in state TASK_INTERRUPTIBLE) or by
an explicit wakeup, it returns -EINTR.


>   */
>  int __sched schedule_hrtimeout_range(ktime_t *expires, u64 delta,
>  				     const enum hrtimer_mode mode)
> @@ -1772,15 +1776,19 @@ EXPORT_SYMBOL_GPL(schedule_hrtimeout_range);
>   * You can set the task state as follows -
>   *
>   * %TASK_UNINTERRUPTIBLE - at least @timeout time is guaranteed to
> - * pass before the routine returns.
> + * pass before the routine returns unless the current task is explicitly
> + * woken up, (e.g. by wake_up_process())".

See above

>   *
>   * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
> - * delivered to the current task.
> + * delivered to the current task or the current task is explicitly woken
> + * up.
>   *
>   * The current task state is guaranteed to be TASK_RUNNING when this
>   * routine returns.
>   *
> - * Returns 0 when the timer has expired otherwise -EINTR
> + * Returns 0 when the timer has expired otherwise -EINTR. Note that
> + * -EINTR can still be returned even if the task state is
> + * TASK_UNINTERRUPTIBLE if the current task is explicitly woken up.

See above

> @@ -1691,11 +1691,12 @@ static void process_timeout(unsigned long __data)
>   * You can set the task state as follows -
>   *
>   * %TASK_UNINTERRUPTIBLE - at least @timeout jiffies are guaranteed to
> - * pass before the routine returns. The routine will return 0
> + * pass before the routine returns unless the current task is explicitly
> + * woken up, (e.g. by wake_up_process())".
>   *
>   * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
> - * delivered to the current task. In this case the remaining time
> - * in jiffies will be returned, or 0 if the timer expired in time
> + * delivered to the current task or the current task is explicitly woken
> + * up.
>   *
>   * The current task state is guaranteed to be TASK_RUNNING when this
>   * routine returns.
> @@ -1704,7 +1705,9 @@ static void process_timeout(unsigned long __data)
>   * the CPU away without a bound on the timeout. In this case the return
>   * value will be %MAX_SCHEDULE_TIMEOUT.
>   *
> - * In all cases the return value is guaranteed to be non-negative.
> + * Returns 0 when the timer has expired otherwise the remaining time in
> + * jiffies will be returned.  In all cases the return value is guaranteed
> + * to be non-negative.

That one is fine.

Thanks,

	tglx


From dianders at chromium.org  Thu Oct 20 14:21:29 2016
From: dianders at chromium.org (Douglas Anderson)
Date: Thu, 20 Oct 2016 14:21:29 -0700
Subject: [PATCH v4 1/2] timers: Fix usleep_range() in the context of
 wake_up_process()
Message-ID: <1476998490-4481-1-git-send-email-dianders@chromium.org>

Users of usleep_range() expect that it will _never_ return in less time
than the minimum passed parameter.  However, nothing in any of the code
ensures this.  Specifically:

usleep_range() => do_usleep_range() => schedule_hrtimeout_range() =>
schedule_hrtimeout_range_clock() just ends up calling schedule() with an
appropriate timeout set using the hrtimer.  If someone else happens to
wake up our task then we'll happily return from usleep_range() early.

msleep() already has code to handle this case since it will loop as long
as there was still time left.  usleep_range() had no such loop.

The problem is is easily demonstrated with a small bit of test code:

  static int usleep_test_task(void *data)
  {
    atomic_t *done = data;
    ktime_t start, end;

    start = ktime_get();
    usleep_range(50000, 100000);
    end = ktime_get();
    pr_info("Requested 50000 - 100000 us.  Actually slept for %llu us\n",
      (unsigned long long)ktime_to_us(ktime_sub(end, start)));
    atomic_set(done, 1);

    return 0;
  }

  static void run_usleep_test(void)
  {
    struct task_struct *t;
    atomic_t done;

    atomic_set(&done, 0);

    t = kthread_run(usleep_test_task, &done, "usleep_test_task");
    while (!atomic_read(&done)) {
      wake_up_process(t);
      udelay(1000);
    }
    kthread_stop(t);
  }

If you run the above code without this patch you get things like:
  Requested 50000 - 100000 us.  Actually slept for 967 us

If you run the above code _with_ this patch, you get:
  Requested 50000 - 100000 us.  Actually slept for 50001 us

Presumably this problem was not detected before because:
- It's not terribly common to use wake_up_process() directly.
- Other ways for processes to wake up are not typically mixed with
  usleep_range().
- There aren't lots of places that use usleep_range(), since many people
  call either msleep() or udelay().

NOTES:
- An effort was made to look for users relying on the old behavior by
  looking for usleep_range() in the same file as wake_up_process().
  No problems was found by this search, though it is conceivable that
  someone could have put the sleep and wakeup in two different files.
- An effort was made to ask several upstream maintainers if they were
  aware of people relying on wake_up_process() to wake up
  usleep_range().  No maintainers were aware of that but they were aware
  of many people relying on usleep_range() never returning before the
  minimum.

Reported-by: Tao Huang <huangtao at rock-chips.com>
Signed-off-by: Douglas Anderson <dianders at chromium.org>
Reviewed-by: Andreas Mohr <andim2 at users.sf.net>
Reviewed-by: Brian Norris <briannorris at chromium.org>
Reviewed-by: Guenter Roeck <linux at roeck-us.net>
---
Changes in v4: None
Changes in v3:
- Add Reviewed-by tags
- Add notes about validation

Changes in v2:
- Fixed stupid bug that snuck in before posting
- Use ktime_before
- Remove delta from the loop

 kernel/time/timer.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 32bf6f75a8fe..219439efd56a 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1898,12 +1898,28 @@ EXPORT_SYMBOL(msleep_interruptible);
 
 static void __sched do_usleep_range(unsigned long min, unsigned long max)
 {
+	ktime_t now, end;
 	ktime_t kmin;
 	u64 delta;
+	int ret;
 
-	kmin = ktime_set(0, min * NSEC_PER_USEC);
+	now = ktime_get();
+	end = ktime_add_us(now, min);
 	delta = (u64)(max - min) * NSEC_PER_USEC;
-	schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
+	do {
+		kmin = ktime_sub(end, now);
+		ret = schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
+
+		/*
+		 * If schedule_hrtimeout_range() returns 0 then we actually
+		 * hit the timeout. If not then we need to re-calculate the
+		 * new timeout ourselves.
+		 */
+		if (ret == 0)
+			break;
+
+		now = ktime_get();
+	} while (ktime_before(now, end));
 }
 
 /**
-- 
2.8.0.rc3.226.g39d4020



From dianders at chromium.org  Thu Oct 20 14:21:30 2016
From: dianders at chromium.org (Douglas Anderson)
Date: Thu, 20 Oct 2016 14:21:30 -0700
Subject: [PATCH v4 2/2] timers: Fix documentation for schedule_timeout() and
 similar
In-Reply-To: <1476998490-4481-1-git-send-email-dianders@chromium.org>
References: <1476998490-4481-1-git-send-email-dianders@chromium.org>
Message-ID: <1476998490-4481-2-git-send-email-dianders@chromium.org>

The documentatoin for schedule_timeout(), schedule_hrtimeout(), and
schedule_hrtimeout_range() all claimed that the routines couldn't
possibly return early if the task state was TASK_UNINTERRUPTIBLE.  This
was simply not true since anyone calling wake_up_process() would cause
those routines to exit early.

As some evidence that the documentation was broken (not the code):
- If we changed the code to match the documentation, msleep() would be
  identical to schedule_timeout_uninterruptible() and
  msleep_interruptible() would be identical to
  schedule_timeout_interruptible().  That doesn't seem likely to have
  been the intention.
- The schedule() function sleeps until a task is woken up.  Logically,
  one would expect that the schedule_timeout() function would sleep
  until a task is woken up or a timeout occurrs.

As part of the above observation, it can be seen that
schedule_hrtimeout() and schedule_hrtimeout_range() might return -EINTR
even if the task state was TASK_UNINTERRUPTIBLE.  This isn't terrible
behavior so we'll document it and keep it as-is.  After all, trying to
match schedule_timeout() and return the time left would incure a bunch
of extra calculation cost that isn't needed in all cases.

Suggested-by: Daniel Kurtz <djkurtz at chromium.org>
Signed-off-by: Douglas Anderson <dianders at chromium.org>
---
Changes in v4:
- Fixed stray double quotes.
- Updated wording as per Thomas Gleixner.

Changes in v3:
- Documentation fix new for v3.

 kernel/time/hrtimer.c | 20 ++++++++++++++------
 kernel/time/timer.c   | 11 +++++++----
 2 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index bb5ec425dfe0..08be5c99d26b 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1742,15 +1742,19 @@ schedule_hrtimeout_range_clock(ktime_t *expires, u64 delta,
  * You can set the task state as follows -
  *
  * %TASK_UNINTERRUPTIBLE - at least @timeout time is guaranteed to
- * pass before the routine returns.
+ * pass before the routine returns unless the current task is explicitly
+ * woken up, (e.g. by wake_up_process()).
  *
  * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
- * delivered to the current task.
+ * delivered to the current task or the current task is explicitly woken
+ * up.
  *
  * The current task state is guaranteed to be TASK_RUNNING when this
  * routine returns.
  *
- * Returns 0 when the timer has expired otherwise -EINTR
+ * Returns 0 when the timer has expired. If the task was woken before the
+ * timer expired by a signal (only possible in state TASK_INTERRUPTIBLE) or
+ * by an explicit wakeup, it returns -EINTR.
  */
 int __sched schedule_hrtimeout_range(ktime_t *expires, u64 delta,
 				     const enum hrtimer_mode mode)
@@ -1772,15 +1776,19 @@ EXPORT_SYMBOL_GPL(schedule_hrtimeout_range);
  * You can set the task state as follows -
  *
  * %TASK_UNINTERRUPTIBLE - at least @timeout time is guaranteed to
- * pass before the routine returns.
+ * pass before the routine returns unless the current task is explicitly
+ * woken up, (e.g. by wake_up_process()).
  *
  * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
- * delivered to the current task.
+ * delivered to the current task or the current task is explicitly woken
+ * up.
  *
  * The current task state is guaranteed to be TASK_RUNNING when this
  * routine returns.
  *
- * Returns 0 when the timer has expired otherwise -EINTR
+ * Returns 0 when the timer has expired. If the task was woken before the
+ * timer expired by a signal (only possible in state TASK_INTERRUPTIBLE) or
+ * by an explicit wakeup, it returns -EINTR.
  */
 int __sched schedule_hrtimeout(ktime_t *expires,
 			       const enum hrtimer_mode mode)
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 219439efd56a..b2ca2a6bc4d2 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1691,11 +1691,12 @@ static void process_timeout(unsigned long __data)
  * You can set the task state as follows -
  *
  * %TASK_UNINTERRUPTIBLE - at least @timeout jiffies are guaranteed to
- * pass before the routine returns. The routine will return 0
+ * pass before the routine returns unless the current task is explicitly
+ * woken up, (e.g. by wake_up_process())".
  *
  * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
- * delivered to the current task. In this case the remaining time
- * in jiffies will be returned, or 0 if the timer expired in time
+ * delivered to the current task or the current task is explicitly woken
+ * up.
  *
  * The current task state is guaranteed to be TASK_RUNNING when this
  * routine returns.
@@ -1704,7 +1705,9 @@ static void process_timeout(unsigned long __data)
  * the CPU away without a bound on the timeout. In this case the return
  * value will be %MAX_SCHEDULE_TIMEOUT.
  *
- * In all cases the return value is guaranteed to be non-negative.
+ * Returns 0 when the timer has expired otherwise the remaining time in
+ * jiffies will be returned.  In all cases the return value is guaranteed
+ * to be non-negative.
  */
 signed long __sched schedule_timeout(signed long timeout)
 {
-- 
2.8.0.rc3.226.g39d4020



From tglx at linutronix.de  Thu Oct 20 14:25:38 2016
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 20 Oct 2016 23:25:38 +0200 (CEST)
Subject: [PATCH v3 1/2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <1476995664-15668-1-git-send-email-dianders@chromium.org>
References: <1476995664-15668-1-git-send-email-dianders@chromium.org>
Message-ID: <alpine.DEB.2.20.1610202306550.4938@nanos>

On Thu, 20 Oct 2016, Douglas Anderson wrote:
> - An effort was made to look for users relying on the old behavior by
>   looking for usleep_range() in the same file as wake_up_process().
>   No problems was found by this search, though it is conceivable that
>   someone could have put the sleep and wakeup in two different files.
> - An effort was made to ask several upstream maintainers if they were
>   aware of people relying on wake_up_process() to wake up
>   usleep_range().  No maintainers were aware of that but they were aware
>   of many people relying on usleep_range() never returning before the
>   minimum.

Thanks for going the extra mile !
 
>  static void __sched do_usleep_range(unsigned long min, unsigned long max)
>  {
> +	ktime_t now, end;
>  	ktime_t kmin;
>  	u64 delta;
> +	int ret;
>  
> -	kmin = ktime_set(0, min * NSEC_PER_USEC);
> +	now = ktime_get();
> +	end = ktime_add_us(now, min);

So you calculate the absolute expiry time here.

>  	delta = (u64)(max - min) * NSEC_PER_USEC;
> -	schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
> +	do {
> +		kmin = ktime_sub(end, now);
> +		ret = schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);

And then you schedule the thing relative. That does not make sense.

> +
> +		/*
> +		 * If schedule_hrtimeout_range() returns 0 then we actually
> +		 * hit the timeout. If not then we need to re-calculate the
> +		 * new timeout ourselves.
> +		 */
> +		if (ret == 0)
> +			break;
> +
> +		now = ktime_get();

And this is broken because schedule_hrtimeout_range() returns with task
state TASK_RUNNING so the next schedule_hrtimeout_range() will return
-EINTR again because nothing sets the task state back to UNINTERRUPTIBLE.
So instead of sleeping you busy loop.

What you really want to do is something like this:

void __sched usleep_range(unsigned long min, unsigned long max)
{
	ktime_t expires = ktime_add_us(ktime_get(), min * NSEC_PER_USEC);
	ktime_t delta = ktime_set(0, (u64)(max - min) * NSEC_PER_USEC);

	for (;;) {
		__set_current_state(TASK_UNINTERRUPTIBLE);
		/* Do not return before the requested sleep time has elapsed */
		if (!schedule_hrtimeout_range(&expires, delta, HRTIMER_MODE_ABS))
			break;
	}
}

Thanks,

	tglx


From tglx at linutronix.de  Thu Oct 20 14:27:06 2016
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 20 Oct 2016 23:27:06 +0200 (CEST)
Subject: [PATCH v4 1/2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <1476998490-4481-1-git-send-email-dianders@chromium.org>
References: <1476998490-4481-1-git-send-email-dianders@chromium.org>
Message-ID: <alpine.DEB.2.20.1610202326070.4938@nanos>

On Thu, 20 Oct 2016, Douglas Anderson wrote:

Please wait for a full review and do not send out patches 5 seconds after
the first mail hits your inbox.

Thanks,

	tglx



From linux at armlinux.org.uk  Thu Oct 20 14:50:22 2016
From: linux at armlinux.org.uk (Russell King - ARM Linux)
Date: Thu, 20 Oct 2016 22:50:22 +0100
Subject: [PATCH] drm: convert DT component matching to
 component_match_add_release()
In-Reply-To: <CAOw6vbK=z3wJKTh8jZoU2Gj1PtTLLH_sAUUShbsxL=Qi7d+FLw@mail.gmail.com>
References: <E1bwo6l-0005Io-Q1@rmk-PC.armlinux.org.uk>
 <CAOw6vbK=z3wJKTh8jZoU2Gj1PtTLLH_sAUUShbsxL=Qi7d+FLw@mail.gmail.com>
Message-ID: <20161020215022.GZ1041@n2100.armlinux.org.uk>

On Thu, Oct 20, 2016 at 04:39:04PM -0400, Sean Paul wrote:
> On Wed, Oct 19, 2016 at 6:28 AM, Russell King
> <rmk+kernel at armlinux.org.uk> wrote:
> > Convert DT component matching to use component_match_add_release().
> >
> > Signed-off-by: Russell King <rmk+kernel at armlinux.org.uk>
> > ---
> > Can we please get this patch from May merged into the drm-misc or
> > whatever trees so that we don't end up with conflicts?  I've no idea
> > who looks after drm-misc, as they have _still_ failed to add
> > themselves to MAINTAINERS.
> 
> I think Daniel explained pretty clearly why this wasn't happening in
> the previous thread.
> 
> Next time you send a v2, can you please mark it as such and include a
> "Changes in v2" section?

Why - nothing's changed other than a rebase onto 4.9-rc1.  This isn't
a "I've changed it in XYZ way, so here's a new copy".  It's being
posted in the hope that someone will finally either comment on it or
merge the damn thing, rather than ignoring it was done when it was
last posted.

> >  drivers/gpu/drm/arm/hdlcd_drv.c                 |  3 ++-
> >  drivers/gpu/drm/arm/malidp_drv.c                |  4 +++-
> >  drivers/gpu/drm/armada/armada_drv.c             |  2 +-
> >  drivers/gpu/drm/drm_of.c                        | 28 +++++++++++++++++++++++--
> >  drivers/gpu/drm/etnaviv/etnaviv_drv.c           |  5 +++--
> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  7 ++++---
> >  drivers/gpu/drm/mediatek/mtk_drm_drv.c          |  4 +++-
> >  drivers/gpu/drm/msm/msm_drv.c                   | 12 ++++++-----
> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c     |  6 ++++--
> >  drivers/gpu/drm/sti/sti_drv.c                   |  5 +++--
> >  drivers/gpu/drm/sun4i/sun4i_drv.c               |  3 ++-
> >  drivers/gpu/drm/tilcdc/tilcdc_external.c        |  4 +++-
> >  include/drm/drm_of.h                            | 12 +++++++++++
> >  13 files changed, 73 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> > index fb6a418ce6be..6477d1a65266 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> > @@ -453,7 +453,8 @@ static int hdlcd_probe(struct platform_device *pdev)
> >                 return -EAGAIN;
> >         }
> >
> > -       component_match_add(&pdev->dev, &match, compare_dev, port);
> > +       drm_of_component_match_add(&pdev->dev, &match, compare_dev, port);
> > +       of_node_put(port);
> 
> There's no mention in your commit message about fixing these node leaks.

Isn't that kind-of the whole point of this patch?

> >
> >         return component_master_add_with_match(&pdev->dev, &hdlcd_master_ops,
> >                                                match);
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> > index 9280358b8f15..9f4739452a25 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -493,7 +493,9 @@ static int malidp_platform_probe(struct platform_device *pdev)
> >                 return -EAGAIN;
> >         }
> >
> > -       component_match_add(&pdev->dev, &match, malidp_compare_dev, port);
> > +       drm_of_component_match_add(&pdev->dev, &match, malidp_compare_dev,
> > +                                  port);
> > +       of_node_put(port);
> >         return component_master_add_with_match(&pdev->dev, &malidp_master_ops,
> >                                                match);
> >  }
> > diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
> > index 1e0e68f608e4..94e46da9a758 100644
> > --- a/drivers/gpu/drm/armada/armada_drv.c
> > +++ b/drivers/gpu/drm/armada/armada_drv.c
> > @@ -254,7 +254,7 @@ static void armada_add_endpoints(struct device *dev,
> >                         continue;
> >                 }
> >
> > -               component_match_add(dev, match, compare_of, remote);
> > +               drm_of_component_match_add(dev, match, compare_of, remote);
> >                 of_node_put(remote);
> >         }
> >  }
> > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> > index bc98bb94264d..47848ed8ca48 100644
> > --- a/drivers/gpu/drm/drm_of.c
> > +++ b/drivers/gpu/drm/drm_of.c
> > @@ -6,6 +6,11 @@
> >  #include <drm/drm_crtc.h>
> >  #include <drm/drm_of.h>
> >
> > +static void drm_release_of(struct device *dev, void *data)
> > +{
> > +       of_node_put(data);
> > +}
> > +
> >  /**
> >   * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
> >   * @dev: DRM device
> > @@ -64,6 +69,24 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> >  EXPORT_SYMBOL(drm_of_find_possible_crtcs);
> >
> >  /**
> > + * drm_of_component_match_add - Add a component helper OF node match rule
> > + * @master: master device
> > + * @matchptr: component match pointer
> > + * @compare: compare function used for matching component
> > + * @node: of_node
> > + */
> > +void drm_of_component_match_add(struct device *master,
> > +                               struct component_match **matchptr,
> > +                               int (*compare)(struct device *, void *),
> > +                               struct device_node *node)
> > +{
> > +       of_node_get(node);
> > +       component_match_add_release(master, matchptr, drm_release_of,
> > +                                   compare, node);
> > +}
> > +EXPORT_SYMBOL_GPL(drm_of_component_match_add);
> > +
> > +/**
> >   * drm_of_component_probe - Generic probe function for a component based master
> >   * @dev: master device containing the OF node
> >   * @compare_of: compare function used for matching components
> > @@ -101,7 +124,7 @@ int drm_of_component_probe(struct device *dev,
> >                         continue;
> >                 }
> >
> > -               component_match_add(dev, &match, compare_of, port);
> > +               drm_of_component_match_add(dev, &match, compare_of, port);
> >                 of_node_put(port);
> >         }
> >
> > @@ -140,7 +163,8 @@ int drm_of_component_probe(struct device *dev,
> >                                 continue;
> >                         }
> >
> > -                       component_match_add(dev, &match, compare_of, remote);
> > +                       drm_of_component_match_add(dev, &match, compare_of,
> > +                                                  remote);
> >                         of_node_put(remote);
> >                 }
> >                 of_node_put(port);
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > index aa687669e22b..0dee6acbd880 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > @@ -16,6 +16,7 @@
> >
> >  #include <linux/component.h>
> >  #include <linux/of_platform.h>
> > +#include <drm/drm_of.h>
> >
> >  #include "etnaviv_drv.h"
> >  #include "etnaviv_gpu.h"
> > @@ -629,8 +630,8 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
> >                         if (!core_node)
> >                                 break;
> >
> > -                       component_match_add(&pdev->dev, &match, compare_of,
> > -                                           core_node);
> > +                       drm_of_component_match_add(&pdev->dev, &match,
> > +                                                  compare_of, core_node);
> >                         of_node_put(core_node);
> >                 }
> >         } else if (dev->platform_data) {
> > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> > index 90377a609c98..e88fde18c946 100644
> > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> > @@ -24,6 +24,7 @@
> >  #include <drm/drm_fb_cma_helper.h>
> >  #include <drm/drm_atomic_helper.h>
> >  #include <drm/drm_crtc_helper.h>
> > +#include <drm/drm_of.h>
> >
> >  #include "kirin_drm_drv.h"
> >
> > @@ -260,14 +261,13 @@ static struct device_node *kirin_get_remote_node(struct device_node *np)
> >                 DRM_ERROR("no valid endpoint node\n");
> >                 return ERR_PTR(-ENODEV);
> >         }
> > -       of_node_put(endpoint);
> >
> >         remote = of_graph_get_remote_port_parent(endpoint);
> > +       of_node_put(endpoint);
> 
> Another bug that's being fixed without mention in the commit.
> 
> >         if (!remote) {
> >                 DRM_ERROR("no valid remote node\n");
> >                 return ERR_PTR(-ENODEV);
> >         }
> > -       of_node_put(remote);
> >
> >         if (!of_device_is_available(remote)) {
> >                 DRM_ERROR("not available for remote node\n");
> > @@ -294,7 +294,8 @@ static int kirin_drm_platform_probe(struct platform_device *pdev)
> >         if (IS_ERR(remote))
> >                 return PTR_ERR(remote);
> >
> > -       component_match_add(dev, &match, compare_of, remote);
> > +       drm_of_component_match_add(dev, &match, compare_of, remote);
> > +       of_node_put(remote);
> >
> >         return component_master_add_with_match(dev, &kirin_drm_ops, match);
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index cf83f6507ec8..9c5430fb82a2 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -18,6 +18,7 @@
> >  #include <drm/drm_crtc_helper.h>
> >  #include <drm/drm_gem.h>
> >  #include <drm/drm_gem_cma_helper.h>
> > +#include <drm/drm_of.h>
> >  #include <linux/component.h>
> >  #include <linux/iommu.h>
> >  #include <linux/of_address.h>
> > @@ -415,7 +416,8 @@ static int mtk_drm_probe(struct platform_device *pdev)
> >                     comp_type == MTK_DPI) {
> >                         dev_info(dev, "Adding component match for %s\n",
> >                                  node->full_name);
> > -                       component_match_add(dev, &match, compare_of, node);
> > +                       drm_of_component_match_add(dev, &match, compare_of,
> > +                                                  node);
> >                 } else {
> >                         struct mtk_ddp_comp *comp;
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > index fb5c0b0a7594..84d38eaea585 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -15,6 +15,8 @@
> >   * this program.  If not, see <http://www.gnu.org/licenses/>.
> >   */
> >
> > +#include <drm/drm_of.h>
> > +
> >  #include "msm_drv.h"
> >  #include "msm_debugfs.h"
> >  #include "msm_fence.h"
> > @@ -919,8 +921,8 @@ static int add_components_mdp(struct device *mdp_dev,
> >                         continue;
> >                 }
> >
> > -               component_match_add(master_dev, matchptr, compare_of, intf);
> > -
> > +               drm_of_component_match_add(master_dev, matchptr, compare_of,
> > +                                          intf);
> >                 of_node_put(intf);
> >                 of_node_put(ep_node);
> >         }
> > @@ -962,8 +964,8 @@ static int add_display_components(struct device *dev,
> >                 put_device(mdp_dev);
> >
> >                 /* add the MDP component itself */
> > -               component_match_add(dev, matchptr, compare_of,
> > -                                   mdp_dev->of_node);
> > +               drm_of_component_match_add(dev, matchptr, compare_of,
> > +                                          mdp_dev->of_node);
> >         } else {
> >                 /* MDP4 */
> >                 mdp_dev = dev;
> > @@ -996,7 +998,7 @@ static int add_gpu_components(struct device *dev,
> >         if (!np)
> >                 return 0;
> >
> > -       component_match_add(dev, matchptr, compare_of, np);
> > +       drm_of_component_match_add(dev, matchptr, compare_of, np);
> >
> >         of_node_put(np);
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > index 8c8cbe837e61..6fe161192bb4 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > @@ -20,6 +20,7 @@
> >  #include <drm/drm_crtc_helper.h>
> >  #include <drm/drm_fb_helper.h>
> >  #include <drm/drm_gem_cma_helper.h>
> > +#include <drm/drm_of.h>
> >  #include <linux/dma-mapping.h>
> >  #include <linux/pm_runtime.h>
> >  #include <linux/module.h>
> > @@ -388,7 +389,7 @@ static void rockchip_add_endpoints(struct device *dev,
> >                         continue;
> >                 }
> >
> > -               component_match_add(dev, match, compare_of, remote);
> > +               drm_of_component_match_add(dev, match, compare_of, remote);
> >                 of_node_put(remote);
> >         }
> >  }
> > @@ -437,7 +438,8 @@ static int rockchip_drm_platform_probe(struct platform_device *pdev)
> >                 }
> >
> >                 of_node_put(iommu);
> > -               component_match_add(dev, &match, compare_of, port->parent);
> > +               drm_of_component_match_add(dev, &match, compare_of,
> > +                                          port->parent);
> >                 of_node_put(port);
> >         }
> >
> > diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> > index 2784919a7366..5e819876e642 100644
> > --- a/drivers/gpu/drm/sti/sti_drv.c
> > +++ b/drivers/gpu/drm/sti/sti_drv.c
> > @@ -17,6 +17,7 @@
> >  #include <drm/drm_crtc_helper.h>
> >  #include <drm/drm_gem_cma_helper.h>
> >  #include <drm/drm_fb_cma_helper.h>
> > +#include <drm/drm_of.h>
> >
> >  #include "sti_crtc.h"
> >  #include "sti_drv.h"
> > @@ -423,8 +424,8 @@ static int sti_platform_probe(struct platform_device *pdev)
> >         child_np = of_get_next_available_child(node, NULL);
> >
> >         while (child_np) {
> > -               component_match_add(dev, &match, compare_of, child_np);
> > -               of_node_put(child_np);
> > +               drm_of_component_match_add(dev, &match, compare_of,
> > +                                          child_np);
> >                 child_np = of_get_next_available_child(node, child_np);
> >         }
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > index 0da9862ad8ed..b3c4ad605e81 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > @@ -18,6 +18,7 @@
> >  #include <drm/drm_fb_cma_helper.h>
> >  #include <drm/drm_gem_cma_helper.h>
> >  #include <drm/drm_fb_helper.h>
> > +#include <drm/drm_of.h>
> >
> >  #include "sun4i_crtc.h"
> >  #include "sun4i_drv.h"
> > @@ -239,7 +240,7 @@ static int sun4i_drv_add_endpoints(struct device *dev,
> >                 /* Add current component */
> >                 DRM_DEBUG_DRIVER("Adding component %s\n",
> >                                  of_node_full_name(node));
> > -               component_match_add(dev, match, compare_of, node);
> > +               drm_of_component_match_add(dev, match, compare_of, node);
> >                 count++;
> >         }
> >
> > diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> > index 68e895021005..06a4c584f3cb 100644
> > --- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
> > +++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> > @@ -10,6 +10,7 @@
> >
> >  #include <linux/component.h>
> >  #include <linux/of_graph.h>
> > +#include <drm/drm_of.h>
> >
> >  #include "tilcdc_drv.h"
> >  #include "tilcdc_external.h"
> > @@ -160,7 +161,8 @@ int tilcdc_get_external_components(struct device *dev,
> >
> >                 dev_dbg(dev, "Subdevice node '%s' found\n", node->name);
> >                 if (match)
> > -                       component_match_add(dev, match, dev_match_of, node);
> > +                       drm_of_component_match_add(dev, match, dev_match_of,
> > +                                                  node);
> >                 of_node_put(node);
> >                 count++;
> >         }
> > diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> > index 3fd87b386ed7..d6b4c5587bbe 100644
> > --- a/include/drm/drm_of.h
> > +++ b/include/drm/drm_of.h
> > @@ -4,6 +4,7 @@
> >  #include <linux/of_graph.h>
> >
> >  struct component_master_ops;
> > +struct component_match;
> >  struct device;
> >  struct drm_device;
> >  struct drm_encoder;
> > @@ -12,6 +13,10 @@ struct device_node;
> >  #ifdef CONFIG_OF
> >  extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> >                                            struct device_node *port);
> > +extern void drm_of_component_match_add(struct device *master,
> > +                                      struct component_match **matchptr,
> > +                                      int (*compare)(struct device *, void *),
> > +                                      struct device_node *node);
> >  extern int drm_of_component_probe(struct device *dev,
> >                                   int (*compare_of)(struct device *, void *),
> >                                   const struct component_master_ops *m_ops);
> > @@ -25,6 +30,13 @@ static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> >         return 0;
> >  }
> >
> > +static void drm_of_component_match_add(struct device *master,
> > +                                      struct component_match **matchptr,
> > +                                      int (*compare)(struct device *, void *),
> > +                                      struct device_node *node)
> > +{
> > +}
> > +
> >  static inline int
> >  drm_of_component_probe(struct device *dev,
> >                        int (*compare_of)(struct device *, void *),
> > --
> > 2.1.0
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From seanpaul at chromium.org  Thu Oct 20 16:15:56 2016
From: seanpaul at chromium.org (Sean Paul)
Date: Thu, 20 Oct 2016 19:15:56 -0400
Subject: [PATCH] drm: convert DT component matching to
 component_match_add_release()
In-Reply-To: <20161020215022.GZ1041@n2100.armlinux.org.uk>
References: <E1bwo6l-0005Io-Q1@rmk-PC.armlinux.org.uk>
 <CAOw6vbK=z3wJKTh8jZoU2Gj1PtTLLH_sAUUShbsxL=Qi7d+FLw@mail.gmail.com>
 <20161020215022.GZ1041@n2100.armlinux.org.uk>
Message-ID: <CAOw6vbJ64JOugR2b3R87pFRDGDVs9HM3uZJM2z1-jHyhPf6WOA@mail.gmail.com>

On Thu, Oct 20, 2016 at 5:50 PM, Russell King - ARM Linux
<linux at armlinux.org.uk> wrote:
> On Thu, Oct 20, 2016 at 04:39:04PM -0400, Sean Paul wrote:
>> On Wed, Oct 19, 2016 at 6:28 AM, Russell King
>> <rmk+kernel at armlinux.org.uk> wrote:
>> > Convert DT component matching to use component_match_add_release().
>> >
>> > Signed-off-by: Russell King <rmk+kernel at armlinux.org.uk>
>> > ---
>> > Can we please get this patch from May merged into the drm-misc or
>> > whatever trees so that we don't end up with conflicts?  I've no idea
>> > who looks after drm-misc, as they have _still_ failed to add
>> > themselves to MAINTAINERS.
>>
>> I think Daniel explained pretty clearly why this wasn't happening in
>> the previous thread.
>>
>> Next time you send a v2, can you please mark it as such and include a
>> "Changes in v2" section?
>
> Why - nothing's changed other than a rebase onto 4.9-rc1.  This isn't
> a "I've changed it in XYZ way, so here's a new copy".


Changes in v2: None

Is still useful since:
a) the diffstat is different from v1, which necessitates me going
through both versions to see what's changed from the previous reviews
(only to find out myself that it's been rebased and a function has
changed names)
b) in June, you said you were going to roll a new version with the
common OF bits extracted. it's nice to know at the outset that this
has/hasn't happened

Also, prefacing the subject with [PATCH v2] or [PATCH RESEND] lets me
know there is prior history with the change. Reading the previous
version is helpful to see what reviewer's concerns were, and whether
they've been addressed.


> It's being
> posted in the hope that someone will finally either comment on it or
> merge the damn thing, rather than ignoring it was done when it was
> last posted.
>
>> >  drivers/gpu/drm/arm/hdlcd_drv.c                 |  3 ++-
>> >  drivers/gpu/drm/arm/malidp_drv.c                |  4 +++-
>> >  drivers/gpu/drm/armada/armada_drv.c             |  2 +-
>> >  drivers/gpu/drm/drm_of.c                        | 28 +++++++++++++++++++++++--
>> >  drivers/gpu/drm/etnaviv/etnaviv_drv.c           |  5 +++--
>> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  7 ++++---
>> >  drivers/gpu/drm/mediatek/mtk_drm_drv.c          |  4 +++-
>> >  drivers/gpu/drm/msm/msm_drv.c                   | 12 ++++++-----
>> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c     |  6 ++++--
>> >  drivers/gpu/drm/sti/sti_drv.c                   |  5 +++--
>> >  drivers/gpu/drm/sun4i/sun4i_drv.c               |  3 ++-
>> >  drivers/gpu/drm/tilcdc/tilcdc_external.c        |  4 +++-
>> >  include/drm/drm_of.h                            | 12 +++++++++++
>> >  13 files changed, 73 insertions(+), 22 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
>> > index fb6a418ce6be..6477d1a65266 100644
>> > --- a/drivers/gpu/drm/arm/hdlcd_drv.c
>> > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
>> > @@ -453,7 +453,8 @@ static int hdlcd_probe(struct platform_device *pdev)
>> >                 return -EAGAIN;
>> >         }
>> >
>> > -       component_match_add(&pdev->dev, &match, compare_dev, port);
>> > +       drm_of_component_match_add(&pdev->dev, &match, compare_dev, port);
>> > +       of_node_put(port);
>>
>> There's no mention in your commit message about fixing these node leaks.
>
> Isn't that kind-of the whole point of this patch?
>

Not according to the commit msg, it isn't.

You could have just done the of_node_put adds/relocations without
wrapping component_match_add_release.

Sean

>> >
>> >         return component_master_add_with_match(&pdev->dev, &hdlcd_master_ops,
>> >                                                match);
>> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
>> > index 9280358b8f15..9f4739452a25 100644
>> > --- a/drivers/gpu/drm/arm/malidp_drv.c
>> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
>> > @@ -493,7 +493,9 @@ static int malidp_platform_probe(struct platform_device *pdev)
>> >                 return -EAGAIN;
>> >         }
>> >
>> > -       component_match_add(&pdev->dev, &match, malidp_compare_dev, port);
>> > +       drm_of_component_match_add(&pdev->dev, &match, malidp_compare_dev,
>> > +                                  port);
>> > +       of_node_put(port);
>> >         return component_master_add_with_match(&pdev->dev, &malidp_master_ops,
>> >                                                match);
>> >  }
>> > diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
>> > index 1e0e68f608e4..94e46da9a758 100644
>> > --- a/drivers/gpu/drm/armada/armada_drv.c
>> > +++ b/drivers/gpu/drm/armada/armada_drv.c
>> > @@ -254,7 +254,7 @@ static void armada_add_endpoints(struct device *dev,
>> >                         continue;
>> >                 }
>> >
>> > -               component_match_add(dev, match, compare_of, remote);
>> > +               drm_of_component_match_add(dev, match, compare_of, remote);
>> >                 of_node_put(remote);
>> >         }
>> >  }
>> > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
>> > index bc98bb94264d..47848ed8ca48 100644
>> > --- a/drivers/gpu/drm/drm_of.c
>> > +++ b/drivers/gpu/drm/drm_of.c
>> > @@ -6,6 +6,11 @@
>> >  #include <drm/drm_crtc.h>
>> >  #include <drm/drm_of.h>
>> >
>> > +static void drm_release_of(struct device *dev, void *data)
>> > +{
>> > +       of_node_put(data);
>> > +}
>> > +
>> >  /**
>> >   * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
>> >   * @dev: DRM device
>> > @@ -64,6 +69,24 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>> >  EXPORT_SYMBOL(drm_of_find_possible_crtcs);
>> >
>> >  /**
>> > + * drm_of_component_match_add - Add a component helper OF node match rule
>> > + * @master: master device
>> > + * @matchptr: component match pointer
>> > + * @compare: compare function used for matching component
>> > + * @node: of_node
>> > + */
>> > +void drm_of_component_match_add(struct device *master,
>> > +                               struct component_match **matchptr,
>> > +                               int (*compare)(struct device *, void *),
>> > +                               struct device_node *node)
>> > +{
>> > +       of_node_get(node);
>> > +       component_match_add_release(master, matchptr, drm_release_of,
>> > +                                   compare, node);
>> > +}
>> > +EXPORT_SYMBOL_GPL(drm_of_component_match_add);
>> > +
>> > +/**
>> >   * drm_of_component_probe - Generic probe function for a component based master
>> >   * @dev: master device containing the OF node
>> >   * @compare_of: compare function used for matching components
>> > @@ -101,7 +124,7 @@ int drm_of_component_probe(struct device *dev,
>> >                         continue;
>> >                 }
>> >
>> > -               component_match_add(dev, &match, compare_of, port);
>> > +               drm_of_component_match_add(dev, &match, compare_of, port);
>> >                 of_node_put(port);
>> >         }
>> >
>> > @@ -140,7 +163,8 @@ int drm_of_component_probe(struct device *dev,
>> >                                 continue;
>> >                         }
>> >
>> > -                       component_match_add(dev, &match, compare_of, remote);
>> > +                       drm_of_component_match_add(dev, &match, compare_of,
>> > +                                                  remote);
>> >                         of_node_put(remote);
>> >                 }
>> >                 of_node_put(port);
>> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > index aa687669e22b..0dee6acbd880 100644
>> > --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > @@ -16,6 +16,7 @@
>> >
>> >  #include <linux/component.h>
>> >  #include <linux/of_platform.h>
>> > +#include <drm/drm_of.h>
>> >
>> >  #include "etnaviv_drv.h"
>> >  #include "etnaviv_gpu.h"
>> > @@ -629,8 +630,8 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
>> >                         if (!core_node)
>> >                                 break;
>> >
>> > -                       component_match_add(&pdev->dev, &match, compare_of,
>> > -                                           core_node);
>> > +                       drm_of_component_match_add(&pdev->dev, &match,
>> > +                                                  compare_of, core_node);
>> >                         of_node_put(core_node);
>> >                 }
>> >         } else if (dev->platform_data) {
>> > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> > index 90377a609c98..e88fde18c946 100644
>> > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> > @@ -24,6 +24,7 @@
>> >  #include <drm/drm_fb_cma_helper.h>
>> >  #include <drm/drm_atomic_helper.h>
>> >  #include <drm/drm_crtc_helper.h>
>> > +#include <drm/drm_of.h>
>> >
>> >  #include "kirin_drm_drv.h"
>> >
>> > @@ -260,14 +261,13 @@ static struct device_node *kirin_get_remote_node(struct device_node *np)
>> >                 DRM_ERROR("no valid endpoint node\n");
>> >                 return ERR_PTR(-ENODEV);
>> >         }
>> > -       of_node_put(endpoint);
>> >
>> >         remote = of_graph_get_remote_port_parent(endpoint);
>> > +       of_node_put(endpoint);
>>
>> Another bug that's being fixed without mention in the commit.
>>
>> >         if (!remote) {
>> >                 DRM_ERROR("no valid remote node\n");
>> >                 return ERR_PTR(-ENODEV);
>> >         }
>> > -       of_node_put(remote);
>> >
>> >         if (!of_device_is_available(remote)) {
>> >                 DRM_ERROR("not available for remote node\n");
>> > @@ -294,7 +294,8 @@ static int kirin_drm_platform_probe(struct platform_device *pdev)
>> >         if (IS_ERR(remote))
>> >                 return PTR_ERR(remote);
>> >
>> > -       component_match_add(dev, &match, compare_of, remote);
>> > +       drm_of_component_match_add(dev, &match, compare_of, remote);
>> > +       of_node_put(remote);
>> >
>> >         return component_master_add_with_match(dev, &kirin_drm_ops, match);
>> >
>> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> > index cf83f6507ec8..9c5430fb82a2 100644
>> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> > @@ -18,6 +18,7 @@
>> >  #include <drm/drm_crtc_helper.h>
>> >  #include <drm/drm_gem.h>
>> >  #include <drm/drm_gem_cma_helper.h>
>> > +#include <drm/drm_of.h>
>> >  #include <linux/component.h>
>> >  #include <linux/iommu.h>
>> >  #include <linux/of_address.h>
>> > @@ -415,7 +416,8 @@ static int mtk_drm_probe(struct platform_device *pdev)
>> >                     comp_type == MTK_DPI) {
>> >                         dev_info(dev, "Adding component match for %s\n",
>> >                                  node->full_name);
>> > -                       component_match_add(dev, &match, compare_of, node);
>> > +                       drm_of_component_match_add(dev, &match, compare_of,
>> > +                                                  node);
>> >                 } else {
>> >                         struct mtk_ddp_comp *comp;
>> >
>> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
>> > index fb5c0b0a7594..84d38eaea585 100644
>> > --- a/drivers/gpu/drm/msm/msm_drv.c
>> > +++ b/drivers/gpu/drm/msm/msm_drv.c
>> > @@ -15,6 +15,8 @@
>> >   * this program.  If not, see <http://www.gnu.org/licenses/>.
>> >   */
>> >
>> > +#include <drm/drm_of.h>
>> > +
>> >  #include "msm_drv.h"
>> >  #include "msm_debugfs.h"
>> >  #include "msm_fence.h"
>> > @@ -919,8 +921,8 @@ static int add_components_mdp(struct device *mdp_dev,
>> >                         continue;
>> >                 }
>> >
>> > -               component_match_add(master_dev, matchptr, compare_of, intf);
>> > -
>> > +               drm_of_component_match_add(master_dev, matchptr, compare_of,
>> > +                                          intf);
>> >                 of_node_put(intf);
>> >                 of_node_put(ep_node);
>> >         }
>> > @@ -962,8 +964,8 @@ static int add_display_components(struct device *dev,
>> >                 put_device(mdp_dev);
>> >
>> >                 /* add the MDP component itself */
>> > -               component_match_add(dev, matchptr, compare_of,
>> > -                                   mdp_dev->of_node);
>> > +               drm_of_component_match_add(dev, matchptr, compare_of,
>> > +                                          mdp_dev->of_node);
>> >         } else {
>> >                 /* MDP4 */
>> >                 mdp_dev = dev;
>> > @@ -996,7 +998,7 @@ static int add_gpu_components(struct device *dev,
>> >         if (!np)
>> >                 return 0;
>> >
>> > -       component_match_add(dev, matchptr, compare_of, np);
>> > +       drm_of_component_match_add(dev, matchptr, compare_of, np);
>> >
>> >         of_node_put(np);
>> >
>> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>> > index 8c8cbe837e61..6fe161192bb4 100644
>> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>> > @@ -20,6 +20,7 @@
>> >  #include <drm/drm_crtc_helper.h>
>> >  #include <drm/drm_fb_helper.h>
>> >  #include <drm/drm_gem_cma_helper.h>
>> > +#include <drm/drm_of.h>
>> >  #include <linux/dma-mapping.h>
>> >  #include <linux/pm_runtime.h>
>> >  #include <linux/module.h>
>> > @@ -388,7 +389,7 @@ static void rockchip_add_endpoints(struct device *dev,
>> >                         continue;
>> >                 }
>> >
>> > -               component_match_add(dev, match, compare_of, remote);
>> > +               drm_of_component_match_add(dev, match, compare_of, remote);
>> >                 of_node_put(remote);
>> >         }
>> >  }
>> > @@ -437,7 +438,8 @@ static int rockchip_drm_platform_probe(struct platform_device *pdev)
>> >                 }
>> >
>> >                 of_node_put(iommu);
>> > -               component_match_add(dev, &match, compare_of, port->parent);
>> > +               drm_of_component_match_add(dev, &match, compare_of,
>> > +                                          port->parent);
>> >                 of_node_put(port);
>> >         }
>> >
>> > diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
>> > index 2784919a7366..5e819876e642 100644
>> > --- a/drivers/gpu/drm/sti/sti_drv.c
>> > +++ b/drivers/gpu/drm/sti/sti_drv.c
>> > @@ -17,6 +17,7 @@
>> >  #include <drm/drm_crtc_helper.h>
>> >  #include <drm/drm_gem_cma_helper.h>
>> >  #include <drm/drm_fb_cma_helper.h>
>> > +#include <drm/drm_of.h>
>> >
>> >  #include "sti_crtc.h"
>> >  #include "sti_drv.h"
>> > @@ -423,8 +424,8 @@ static int sti_platform_probe(struct platform_device *pdev)
>> >         child_np = of_get_next_available_child(node, NULL);
>> >
>> >         while (child_np) {
>> > -               component_match_add(dev, &match, compare_of, child_np);
>> > -               of_node_put(child_np);
>> > +               drm_of_component_match_add(dev, &match, compare_of,
>> > +                                          child_np);
>> >                 child_np = of_get_next_available_child(node, child_np);
>> >         }
>> >
>> > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
>> > index 0da9862ad8ed..b3c4ad605e81 100644
>> > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
>> > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
>> > @@ -18,6 +18,7 @@
>> >  #include <drm/drm_fb_cma_helper.h>
>> >  #include <drm/drm_gem_cma_helper.h>
>> >  #include <drm/drm_fb_helper.h>
>> > +#include <drm/drm_of.h>
>> >
>> >  #include "sun4i_crtc.h"
>> >  #include "sun4i_drv.h"
>> > @@ -239,7 +240,7 @@ static int sun4i_drv_add_endpoints(struct device *dev,
>> >                 /* Add current component */
>> >                 DRM_DEBUG_DRIVER("Adding component %s\n",
>> >                                  of_node_full_name(node));
>> > -               component_match_add(dev, match, compare_of, node);
>> > +               drm_of_component_match_add(dev, match, compare_of, node);
>> >                 count++;
>> >         }
>> >
>> > diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c b/drivers/gpu/drm/tilcdc/tilcdc_external.c
>> > index 68e895021005..06a4c584f3cb 100644
>> > --- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
>> > +++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
>> > @@ -10,6 +10,7 @@
>> >
>> >  #include <linux/component.h>
>> >  #include <linux/of_graph.h>
>> > +#include <drm/drm_of.h>
>> >
>> >  #include "tilcdc_drv.h"
>> >  #include "tilcdc_external.h"
>> > @@ -160,7 +161,8 @@ int tilcdc_get_external_components(struct device *dev,
>> >
>> >                 dev_dbg(dev, "Subdevice node '%s' found\n", node->name);
>> >                 if (match)
>> > -                       component_match_add(dev, match, dev_match_of, node);
>> > +                       drm_of_component_match_add(dev, match, dev_match_of,
>> > +                                                  node);
>> >                 of_node_put(node);
>> >                 count++;
>> >         }
>> > diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
>> > index 3fd87b386ed7..d6b4c5587bbe 100644
>> > --- a/include/drm/drm_of.h
>> > +++ b/include/drm/drm_of.h
>> > @@ -4,6 +4,7 @@
>> >  #include <linux/of_graph.h>
>> >
>> >  struct component_master_ops;
>> > +struct component_match;
>> >  struct device;
>> >  struct drm_device;
>> >  struct drm_encoder;
>> > @@ -12,6 +13,10 @@ struct device_node;
>> >  #ifdef CONFIG_OF
>> >  extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>> >                                            struct device_node *port);
>> > +extern void drm_of_component_match_add(struct device *master,
>> > +                                      struct component_match **matchptr,
>> > +                                      int (*compare)(struct device *, void *),
>> > +                                      struct device_node *node);
>> >  extern int drm_of_component_probe(struct device *dev,
>> >                                   int (*compare_of)(struct device *, void *),
>> >                                   const struct component_master_ops *m_ops);
>> > @@ -25,6 +30,13 @@ static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>> >         return 0;
>> >  }
>> >
>> > +static void drm_of_component_match_add(struct device *master,
>> > +                                      struct component_match **matchptr,
>> > +                                      int (*compare)(struct device *, void *),
>> > +                                      struct device_node *node)
>> > +{
>> > +}
>> > +
>> >  static inline int
>> >  drm_of_component_probe(struct device *dev,
>> >                        int (*compare_of)(struct device *, void *),
>> > --
>> > 2.1.0
>> >
>> >
>> > _______________________________________________
>> > linux-arm-kernel mailing list
>> > linux-arm-kernel at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.


From dianders at chromium.org  Thu Oct 20 16:36:45 2016
From: dianders at chromium.org (Doug Anderson)
Date: Thu, 20 Oct 2016 16:36:45 -0700
Subject: [PATCH v3 1/2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <alpine.DEB.2.20.1610202306550.4938@nanos>
References: <1476995664-15668-1-git-send-email-dianders@chromium.org>
 <alpine.DEB.2.20.1610202306550.4938@nanos>
Message-ID: <CAD=FV=U0sURwAmsiLg0q+=e8o7NfJLWEUAu4zeY1so83cDqXhA@mail.gmail.com>

Hi,

On Thu, Oct 20, 2016 at 2:25 PM, Thomas Gleixner <tglx at linutronix.de> wrote:
> On Thu, 20 Oct 2016, Douglas Anderson wrote:
>> - An effort was made to look for users relying on the old behavior by
>>   looking for usleep_range() in the same file as wake_up_process().
>>   No problems was found by this search, though it is conceivable that
>>   someone could have put the sleep and wakeup in two different files.
>> - An effort was made to ask several upstream maintainers if they were
>>   aware of people relying on wake_up_process() to wake up
>>   usleep_range().  No maintainers were aware of that but they were aware
>>   of many people relying on usleep_range() never returning before the
>>   minimum.
>
> Thanks for going the extra mile !
>
>>  static void __sched do_usleep_range(unsigned long min, unsigned long max)
>>  {
>> +     ktime_t now, end;
>>       ktime_t kmin;
>>       u64 delta;
>> +     int ret;
>>
>> -     kmin = ktime_set(0, min * NSEC_PER_USEC);
>> +     now = ktime_get();
>> +     end = ktime_add_us(now, min);
>
> So you calculate the absolute expiry time here.
>
>>       delta = (u64)(max - min) * NSEC_PER_USEC;
>> -     schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
>> +     do {
>> +             kmin = ktime_sub(end, now);
>> +             ret = schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
>
> And then you schedule the thing relative. That does not make sense.
>
>> +
>> +             /*
>> +              * If schedule_hrtimeout_range() returns 0 then we actually
>> +              * hit the timeout. If not then we need to re-calculate the
>> +              * new timeout ourselves.
>> +              */
>> +             if (ret == 0)
>> +                     break;
>> +
>> +             now = ktime_get();
>
> And this is broken because schedule_hrtimeout_range() returns with task
> state TASK_RUNNING so the next schedule_hrtimeout_range() will return
> -EINTR again because nothing sets the task state back to UNINTERRUPTIBLE.
> So instead of sleeping you busy loop.

That explains the mystery of why my delays were always so precise in
the test.  I was a bit baffled by the fact that I was ending up with a
delay of almost exactly 50001 or 50002 in my test case.

Thank you for catching!


> What you really want to do is something like this:
>
> void __sched usleep_range(unsigned long min, unsigned long max)
> {
>         ktime_t expires = ktime_add_us(ktime_get(), min * NSEC_PER_USEC);
>         ktime_t delta = ktime_set(0, (u64)(max - min) * NSEC_PER_USEC);
>
>         for (;;) {
>                 __set_current_state(TASK_UNINTERRUPTIBLE);
>                 /* Do not return before the requested sleep time has elapsed */
>                 if (!schedule_hrtimeout_range(&expires, delta, HRTIMER_MODE_ABS))
>                         break;
>         }
> }

The above mostly works other than some small fixups.  Thanks!

...other than small fixups, the one substantive change I'll make is to
actually check the timeout in the loop above.  If I use your code with
my test, I find that, even though I'm waking up every millisecond I
still end up not exiting the loop until the upper bound of the delay.

Presumably this happens because:

  a_time_in_the_past = ktime_sub_us(ktime_get(), 10);
  schedule_hrtimeout_range(&a_time_in_the_past, delta, HRTIMER_MODE_ABS)

...delays "delta" nano seconds even though "a_time_in_the_past" is in
the past.  I presume that behavior is OK (let me know if it's not).

In the case of usleep_range() if we're waking up anyway, it seems
sensible to spend a few cycles to see if the minimum bound has already
past.


I'll plan to send a new version tomorrow unless I hear that you don't
like the above.


-Doug


From dianders at chromium.org  Thu Oct 20 16:37:55 2016
From: dianders at chromium.org (Doug Anderson)
Date: Thu, 20 Oct 2016 16:37:55 -0700
Subject: [PATCH v4 1/2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <alpine.DEB.2.20.1610202326070.4938@nanos>
References: <1476998490-4481-1-git-send-email-dianders@chromium.org>
 <alpine.DEB.2.20.1610202326070.4938@nanos>
Message-ID: <CAD=FV=W4qSXHywGNEg6tOq8WiC7cROME4g3SwTxkD7h7=NsvvQ@mail.gmail.com>

Hi,

On Thu, Oct 20, 2016 at 2:27 PM, Thomas Gleixner <tglx at linutronix.de> wrote:
> On Thu, 20 Oct 2016, Douglas Anderson wrote:
>
> Please wait for a full review and do not send out patches 5 seconds after
> the first mail hits your inbox.

Since you had previously commented on patch 1 and had already
commented on patch 2, I presumed you were done reviewing, but I was
obviously in error.  My apologies.

-Doug


From jh80.chung at samsung.com  Thu Oct 20 18:56:55 2016
From: jh80.chung at samsung.com (Jaehoon Chung)
Date: Fri, 21 Oct 2016 10:56:55 +0900
Subject: [PATCH v2 0/9] Init runtime PM support for dw_mmc
In-Reply-To: <5be33ac5-7b5e-4b53-67bf-1c38822832ea@rock-chips.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
 <CAPDyKFopNgWh=+0RNFwJc+aaFPXGuJMAac5rPtfOawvLwSbN+g@mail.gmail.com>
 <CGME20161018113542epcas1p2b46f0b6ba79ab71543c62d7f7384912b@epcas1p2.samsung.com>
 <5be33ac5-7b5e-4b53-67bf-1c38822832ea@rock-chips.com>
Message-ID: <c4461e79-a478-0412-fbe7-8b6c0b1e4824@samsung.com>

Hi Shawn,

On 10/18/2016 08:35 PM, Shawn Lin wrote:
> ? 2016/10/18 16:46, Ulf Hansson ??:
>> + Heiko
>>
>> On 12 October 2016 at 04:50, Shawn Lin <shawn.lin at rock-chips.com> wrote:
>>>
>>> Hi Jaehoon and Ulf,

I applied this on my repository. If there are any issue, let me know.
And minor issue can be fixed..step by step.

Best Regards,
Jaehoon Chung

>>>
>>>    This patch is gonna support runtime PM for dw_mmc.
>>> It could support to disable ciu_clk by default and disable
>>> biu_clk if the devices are non-removeable, or removeable
>>> with gpio-base card detect.
>>>
>>>    Then I remove the system PM since the runtime PM actually
>>> does the same thing as it. So I help migrate the dw_mmc variant
>>> drivers to use runtime PM pairs and pm_runtime_force_*. Note
>>> that I only enable runtime PM for dw_mmc-rockchip as I will
>>> leave the decision to the owners of the corresponding drivers.
>>> I just tested it on my RK3288 platform with linux-next to make
>>> the runtime PM and system PM work fine for my emmc, sd card and
>>> sdio. But I don't have hardware to help test other variant drivers.
>>> But in theory it should work fine as I mentioned that the runtime
>>> PM does the same thing as system PM except for disabling ciu_clk
>>> aggressively which should not be related to the variant hosts.
>>>
>>>    As you could see that I just extend the slot-gpio a bit, so the
>>> ideal way is Ulf could pick them up with Jaehoon's ack. :)
>>
>> The mmc core change looks fine to me, so I will wait for a pull
>> request from Jaehoon.
>>
>>>
>>>
>>> Changes in v2:
>>> - use struct device as argument for runtime callback
>>> - use dw_mci_runtime_* directly
>>> - use dw_mci_runtime_* directly
>>> - minor fix since I change the argument for dw_mci_runtime_*
>>> - use dw_mci_runtime_* directly
>>> - use dw_mci_runtime_* directly
>>>
>>> Shawn Lin (9):
>>>   mmc: dw_mmc: add runtime PM callback
>>>   mmc: dw_mmc-rockchip: add runtime PM support
>>>   mmc: core: expose the capability of gpio card detect
>>>   mmc: dw_mmc: disable biu clk if possible
>>>   mmc: dw_mmc-k3: deploy runtime PM facilities
>>>   mmc: dw_mmc-exynos: deploy runtime PM facilities
>>>   mmc: dw_mmc-pci: deploy runtime PM facilities
>>>   mmc: dw_mmc-pltfm: deploy runtime PM facilities
>>>   mmc: dw_mmc: remove system PM callback
>>>
>>>  drivers/mmc/core/slot-gpio.c       |  8 +++++++
>>>  drivers/mmc/host/dw_mmc-exynos.c   | 24 +++++++++-----------
>>>  drivers/mmc/host/dw_mmc-k3.c       | 39 ++++++++------------------------
>>>  drivers/mmc/host/dw_mmc-pci.c      | 29 ++++++++----------------
>>>  drivers/mmc/host/dw_mmc-pltfm.c    | 28 +++++++----------------
>>>  drivers/mmc/host/dw_mmc-rockchip.c | 42 +++++++++++++++++++++++++++++++---
>>>  drivers/mmc/host/dw_mmc.c          | 46 +++++++++++++++++++++++++-------------
>>>  drivers/mmc/host/dw_mmc.h          |  6 ++---
>>>  include/linux/mmc/slot-gpio.h      |  1 +
>>>  9 files changed, 117 insertions(+), 106 deletions(-)
>>>
>>
>> Overall these changes looks good to me, so I am ready to accept the PR
>> from Jaehoon!!
>>
>>
>> Although, highly related to this patchset, I am worried that there is
>> a misunderstanding on how MMC_PM_KEEP_POWER (DT binding
>> "keep-power-in-suspend") is being used for dw_mmc. Perhaps I am wrong,
>> but I would appreciate if you could elaborate a bit for my
>> understanding.
>>
>> First, this cap is solely intended to be used for controllers which
>> may have SDIO cards attached, as it indicates those cards may be
>> configured to be powered on while the system enters suspend state. By
>> looking at some DTS files, for example
>> arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts which uses it
>> for an eMMC slot, this is clearly being abused.
> 
> Indeed. In general, it should be copy-paste issues as folks maybe write
> their dts referring to the exist dts there. So yes, I will do some cleanup work for them in prevent of further spread of abused code.
> 
>>
>> Anyway, the wrong DT configurations might not be a big deal, as in
>> dw_mci_resume(), it's not the capabilities bit that is checked but the
>> corresponding "pm_flag". This flag is set via calling
>> sdio_set_host_pm_flags(), but as that doesn't happen for an eMMC card
>> we should be fine, right!?
>>
>> Now, what also do puzzles me, is exactly that piece of code in
>> dw_mci_resume() that is being executed *when* the pm_flag contains
>> MMC_PM_KEEP_POWER:
>> if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
>>      dw_mci_set_ios(slot->mmc, &slot->mmc->ios);
>>      dw_mci_setup_bus(slot, true);
>> }
>>
>> So, in the system resume path, the above do makes sense as you need to
>> restore the registers etc for the dw_mmc controller to enable it to
>> operate the SDIO card. Such as bus width, clocks, etc.
>>
>> Although, I would expect something similar would be needed in the new
>> runtime resume path as well. And in particular also for eMMC/SD cards,
>> as you need to restore the dw_mmc registers to be able to operate the
>> card again. Don't you?
> 
> yes, we do.
> 
>>
>> So in the end, perhaps you should *always* call dw_mci_set_ios() and
>> dw_mci_setup_bus() in dw_mci_resume() instead of conditionally check
>> for MMC_PM_KEEP_POWER? Or maybe only a subset of those functions?
>>
> 
> Thanks for noticing this.
> 
> Personally, I realize there is no need to check MMC_PM_KEEP_POWER but
> it could be highly related to the cost of S-2-R, I guess. I just checked
> sdhci and saw the similar cases you mentioned at the first glance.
> Maybe I'm wrong but I need more time to investigate this issue later.
> 
> There are still some on-going cleanup work for dw_mmc listed on my TODO
> list, including bugfix, legacy/redundant code etc.. So I will check this one either. Maybe Jaehoon could also do some stree test on enxyos
> platforms. :)
> 
> 
>> Kind regards
>> Uffe
>>
>>
>>
> 
> 



From shawn.lin at rock-chips.com  Thu Oct 20 19:43:54 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Fri, 21 Oct 2016 10:43:54 +0800
Subject: [PATCH 0/2] Add new resets for pcie-rockchip
Message-ID: <1477017836-19317-1-git-send-email-shawn.lin@rock-chips.com>


Hi Bjorn and Heiko,

Sorry for updating pcie-rockchip so frequently under this development
cycle. This patch is going to fix a urgent issue of missing control for
pm_rst, aclk_rst and pclk_rst. These three resets was controlled by rom code
but now the driver will take over it in order to solve some weird issues
found by MP test. Thanks to that it is still under MP test internally, so
the backward compatibility of dtb won't be a big deal.

And there are still some on-going patches for pcie-rockchip on linux-pci
wasn't merged. All of them was also rebased on your next branch, so hope there
is no conflict if you wish to pick them(including this patch 1), otherwise I could
rebase all of them again. :)



Shawn Lin (2):
  PCI: rockchip: Add three new resets as required properties
  arm64: dts: rockchip: add three new resets for rk3399 PCIe controller

 .../devicetree/bindings/pci/rockchip-pcie.txt      | 11 ++--
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           |  7 ++-
 drivers/pci/host/pcie-rockchip.c                   | 62 ++++++++++++++++++++++
 3 files changed, 75 insertions(+), 5 deletions(-)

-- 
2.3.7




From shawn.lin at rock-chips.com  Thu Oct 20 19:43:55 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Fri, 21 Oct 2016 10:43:55 +0800
Subject: [PATCH 1/2] PCI: rockchip: Add three new resets as required properties
In-Reply-To: <1477017836-19317-1-git-send-email-shawn.lin@rock-chips.com>
References: <1477017836-19317-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1477017836-19317-2-git-send-email-shawn.lin@rock-chips.com>

pm_rst, aclk_rst, pclk_rst was controlled by rom code so the
software wasn't needed to control it again in theory. But it
didn't work properly, so we do need to do it again and add a
enough delay between the assert of pm_rst and the deassert of
pm_rst. The Soc intergrated with this controller, rk3399 is still
under MP test internally, so the backward compatibility won't be
a big deal.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

---

 .../devicetree/bindings/pci/rockchip-pcie.txt      | 11 ++--
 drivers/pci/host/pcie-rockchip.c                   | 62 ++++++++++++++++++++++
 2 files changed, 70 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
index ba67b39..71aeda1 100644
--- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
@@ -26,13 +26,16 @@ Required properties:
 	- "sys"
 	- "legacy"
 	- "client"
-- resets: Must contain five entries for each entry in reset-names.
+- resets: Must contain seven entries for each entry in reset-names.
 	   See ../reset/reset.txt for details.
 - reset-names: Must include the following names
 	- "core"
 	- "mgmt"
 	- "mgmt-sticky"
 	- "pipe"
+	- "pm"
+	- "aclk"
+	- "pclk"
 - pinctrl-names : The pin control state names
 - pinctrl-0: The "default" pinctrl state
 - #interrupt-cells: specifies the number of cells needed to encode an
@@ -86,8 +89,10 @@ pcie0: pcie at f8000000 {
 	reg = <0x0 0xf8000000 0x0 0x2000000>, <0x0 0xfd000000 0x0 0x1000000>;
 	reg-names = "axi-base", "apb-base";
 	resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
-		 <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE>;
-	reset-names = "core", "mgmt", "mgmt-sticky", "pipe";
+		 <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE> ,
+		 <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>, <&cru SRST_A_PCIE>;
+	reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
+		      "pm", "pclk", "aclk";
 	phys = <&pcie_phy>;
 	phy-names = "pcie-phy";
 	pinctrl-names = "default";
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index e0b22da..e04f69b 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -190,6 +190,9 @@ struct rockchip_pcie {
 	struct	reset_control *mgmt_rst;
 	struct	reset_control *mgmt_sticky_rst;
 	struct	reset_control *pipe_rst;
+	struct	reset_control *pm_rst;
+	struct	reset_control *aclk_rst;
+	struct	reset_control *pclk_rst;
 	struct	clk *aclk_pcie;
 	struct	clk *aclk_perf_pcie;
 	struct	clk *hclk_pcie;
@@ -408,6 +411,44 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
 
 	gpiod_set_value(rockchip->ep_gpio, 0);
 
+	err = reset_control_assert(rockchip->aclk_rst);
+	if (err) {
+		dev_err(dev, "assert aclk_rst err %d\n", err);
+		return err;
+	}
+
+	err = reset_control_assert(rockchip->pclk_rst);
+	if (err) {
+		dev_err(dev, "assert pclk_rst err %d\n", err);
+		return err;
+	}
+
+	err = reset_control_assert(rockchip->pm_rst);
+	if (err) {
+		dev_err(dev, "assert pm_rst err %d\n", err);
+		return err;
+	}
+
+	udelay(10);
+
+	err = reset_control_deassert(rockchip->pm_rst);
+	if (err) {
+		dev_err(dev, "deassert pm_rst err %d\n", err);
+		return err;
+	}
+
+	err = reset_control_deassert(rockchip->aclk_rst);
+	if (err) {
+		dev_err(dev, "deassert mgmt_sticky_rst err %d\n", err);
+		return err;
+	}
+
+	err = reset_control_deassert(rockchip->pclk_rst);
+	if (err) {
+		dev_err(dev, "deassert mgmt_sticky_rst err %d\n", err);
+		return err;
+	}
+
 	err = phy_init(rockchip->phy);
 	if (err < 0) {
 		dev_err(dev, "fail to init phy, err %d\n", err);
@@ -781,6 +822,27 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
 		return PTR_ERR(rockchip->pipe_rst);
 	}
 
+	rockchip->pm_rst = devm_reset_control_get(dev, "pm");
+	if (IS_ERR(rockchip->pm_rst)) {
+		if (PTR_ERR(rockchip->pm_rst) != -EPROBE_DEFER)
+			dev_err(dev, "missing pm reset property in node\n");
+		return PTR_ERR(rockchip->pm_rst);
+	}
+
+	rockchip->pclk_rst = devm_reset_control_get(dev, "pclk");
+	if (IS_ERR(rockchip->pclk_rst)) {
+		if (PTR_ERR(rockchip->pclk_rst) != -EPROBE_DEFER)
+			dev_err(dev, "missing pclk reset property in node\n");
+		return PTR_ERR(rockchip->pclk_rst);
+	}
+
+	rockchip->aclk_rst = devm_reset_control_get(dev, "aclk");
+	if (IS_ERR(rockchip->aclk_rst)) {
+		if (PTR_ERR(rockchip->aclk_rst) != -EPROBE_DEFER)
+			dev_err(dev, "missing aclk reset property in node\n");
+		return PTR_ERR(rockchip->aclk_rst);
+	}
+
 	rockchip->ep_gpio = devm_gpiod_get(dev, "ep", GPIOD_OUT_HIGH);
 	if (IS_ERR(rockchip->ep_gpio)) {
 		dev_err(dev, "missing ep-gpios property in node\n");
-- 
2.3.7




From shawn.lin at rock-chips.com  Thu Oct 20 19:43:56 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Fri, 21 Oct 2016 10:43:56 +0800
Subject: [PATCH 2/2] arm64: dts: rockchip: add three new resets for rk3399
 PCIe controller
In-Reply-To: <1477017836-19317-1-git-send-email-shawn.lin@rock-chips.com>
References: <1477017836-19317-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <1477017836-19317-3-git-send-email-shawn.lin@rock-chips.com>

pm_rst, aclk_rst and pclk_rst should be controlled by driver, so we
need to add these three resets for PCIe controller.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 76b2864..5191cfd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -300,8 +300,11 @@
 		ranges = <0x83000000 0x0 0xfa000000 0x0 0xfa000000 0x0 0x600000
 			  0x81000000 0x0 0xfa600000 0x0 0xfa600000 0x0 0x100000>;
 		resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
-			 <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE>;
-		reset-names = "core", "mgmt", "mgmt-sticky", "pipe";
+			 <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE>,
+			 <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>,
+			 <&cru SRST_A_PCIE>;
+		reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
+			      "pm", "pclk", "aclk";
 		status = "disabled";
 
 		pcie0_intc: interrupt-controller {
-- 
2.3.7




From shawn.lin at rock-chips.com  Thu Oct 20 19:43:51 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Fri, 21 Oct 2016 10:43:51 +0800
Subject: [PATCH v2 0/9] Init runtime PM support for dw_mmc
In-Reply-To: <c4461e79-a478-0412-fbe7-8b6c0b1e4824@samsung.com>
References: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
 <CAPDyKFopNgWh=+0RNFwJc+aaFPXGuJMAac5rPtfOawvLwSbN+g@mail.gmail.com>
 <CGME20161018113542epcas1p2b46f0b6ba79ab71543c62d7f7384912b@epcas1p2.samsung.com>
 <5be33ac5-7b5e-4b53-67bf-1c38822832ea@rock-chips.com>
 <c4461e79-a478-0412-fbe7-8b6c0b1e4824@samsung.com>
Message-ID: <1688e0bd-1648-99cf-48b4-699398891bf8@rock-chips.com>

Hi Jaehoon,

On 2016/10/21 9:56, Jaehoon Chung wrote:
> Hi Shawn,
>
> On 10/18/2016 08:35 PM, Shawn Lin wrote:
>> ? 2016/10/18 16:46, Ulf Hansson ??:
>>> + Heiko
>>>
>>> On 12 October 2016 at 04:50, Shawn Lin <shawn.lin at rock-chips.com> wrote:
>>>>
>>>> Hi Jaehoon and Ulf,
>
> I applied this on my repository. If there are any issue, let me know.
> And minor issue can be fixed..step by step.

I was checking your repository and there is no doubt for them.

Thanks a lot!

>
> Best Regards,
> Jaehoon Chung
>
>>>>
>>>>    This patch is gonna support runtime PM for dw_mmc.
>>>> It could support to disable ciu_clk by default and disable
>>>> biu_clk if the devices are non-removeable, or removeable
>>>> with gpio-base card detect.
>>>>
>>>>    Then I remove the system PM since the runtime PM actually
>>>> does the same thing as it. So I help migrate the dw_mmc variant
>>>> drivers to use runtime PM pairs and pm_runtime_force_*. Note
>>>> that I only enable runtime PM for dw_mmc-rockchip as I will
>>>> leave the decision to the owners of the corresponding drivers.
>>>> I just tested it on my RK3288 platform with linux-next to make
>>>> the runtime PM and system PM work fine for my emmc, sd card and
>>>> sdio. But I don't have hardware to help test other variant drivers.
>>>> But in theory it should work fine as I mentioned that the runtime
>>>> PM does the same thing as system PM except for disabling ciu_clk
>>>> aggressively which should not be related to the variant hosts.
>>>>
>>>>    As you could see that I just extend the slot-gpio a bit, so the
>>>> ideal way is Ulf could pick them up with Jaehoon's ack. :)
>>>
>>> The mmc core change looks fine to me, so I will wait for a pull
>>> request from Jaehoon.
>>>
>>>>
>>>>
>>>> Changes in v2:
>>>> - use struct device as argument for runtime callback
>>>> - use dw_mci_runtime_* directly
>>>> - use dw_mci_runtime_* directly
>>>> - minor fix since I change the argument for dw_mci_runtime_*
>>>> - use dw_mci_runtime_* directly
>>>> - use dw_mci_runtime_* directly
>>>>
>>>> Shawn Lin (9):
>>>>   mmc: dw_mmc: add runtime PM callback
>>>>   mmc: dw_mmc-rockchip: add runtime PM support
>>>>   mmc: core: expose the capability of gpio card detect
>>>>   mmc: dw_mmc: disable biu clk if possible
>>>>   mmc: dw_mmc-k3: deploy runtime PM facilities
>>>>   mmc: dw_mmc-exynos: deploy runtime PM facilities
>>>>   mmc: dw_mmc-pci: deploy runtime PM facilities
>>>>   mmc: dw_mmc-pltfm: deploy runtime PM facilities
>>>>   mmc: dw_mmc: remove system PM callback
>>>>
>>>>  drivers/mmc/core/slot-gpio.c       |  8 +++++++
>>>>  drivers/mmc/host/dw_mmc-exynos.c   | 24 +++++++++-----------
>>>>  drivers/mmc/host/dw_mmc-k3.c       | 39 ++++++++------------------------
>>>>  drivers/mmc/host/dw_mmc-pci.c      | 29 ++++++++----------------
>>>>  drivers/mmc/host/dw_mmc-pltfm.c    | 28 +++++++----------------
>>>>  drivers/mmc/host/dw_mmc-rockchip.c | 42 +++++++++++++++++++++++++++++++---
>>>>  drivers/mmc/host/dw_mmc.c          | 46 +++++++++++++++++++++++++-------------
>>>>  drivers/mmc/host/dw_mmc.h          |  6 ++---
>>>>  include/linux/mmc/slot-gpio.h      |  1 +
>>>>  9 files changed, 117 insertions(+), 106 deletions(-)
>>>>
>>>
>>> Overall these changes looks good to me, so I am ready to accept the PR
>>> from Jaehoon!!
>>>
>>>
>>> Although, highly related to this patchset, I am worried that there is
>>> a misunderstanding on how MMC_PM_KEEP_POWER (DT binding
>>> "keep-power-in-suspend") is being used for dw_mmc. Perhaps I am wrong,
>>> but I would appreciate if you could elaborate a bit for my
>>> understanding.
>>>
>>> First, this cap is solely intended to be used for controllers which
>>> may have SDIO cards attached, as it indicates those cards may be
>>> configured to be powered on while the system enters suspend state. By
>>> looking at some DTS files, for example
>>> arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts which uses it
>>> for an eMMC slot, this is clearly being abused.
>>
>> Indeed. In general, it should be copy-paste issues as folks maybe write
>> their dts referring to the exist dts there. So yes, I will do some cleanup work for them in prevent of further spread of abused code.
>>
>>>
>>> Anyway, the wrong DT configurations might not be a big deal, as in
>>> dw_mci_resume(), it's not the capabilities bit that is checked but the
>>> corresponding "pm_flag". This flag is set via calling
>>> sdio_set_host_pm_flags(), but as that doesn't happen for an eMMC card
>>> we should be fine, right!?
>>>
>>> Now, what also do puzzles me, is exactly that piece of code in
>>> dw_mci_resume() that is being executed *when* the pm_flag contains
>>> MMC_PM_KEEP_POWER:
>>> if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
>>>      dw_mci_set_ios(slot->mmc, &slot->mmc->ios);
>>>      dw_mci_setup_bus(slot, true);
>>> }
>>>
>>> So, in the system resume path, the above do makes sense as you need to
>>> restore the registers etc for the dw_mmc controller to enable it to
>>> operate the SDIO card. Such as bus width, clocks, etc.
>>>
>>> Although, I would expect something similar would be needed in the new
>>> runtime resume path as well. And in particular also for eMMC/SD cards,
>>> as you need to restore the dw_mmc registers to be able to operate the
>>> card again. Don't you?
>>
>> yes, we do.
>>
>>>
>>> So in the end, perhaps you should *always* call dw_mci_set_ios() and
>>> dw_mci_setup_bus() in dw_mci_resume() instead of conditionally check
>>> for MMC_PM_KEEP_POWER? Or maybe only a subset of those functions?
>>>
>>
>> Thanks for noticing this.
>>
>> Personally, I realize there is no need to check MMC_PM_KEEP_POWER but
>> it could be highly related to the cost of S-2-R, I guess. I just checked
>> sdhci and saw the similar cases you mentioned at the first glance.
>> Maybe I'm wrong but I need more time to investigate this issue later.
>>
>> There are still some on-going cleanup work for dw_mmc listed on my TODO
>> list, including bugfix, legacy/redundant code etc.. So I will check this one either. Maybe Jaehoon could also do some stree test on enxyos
>> platforms. :)
>>
>>
>>> Kind regards
>>> Uffe
>>>
>>>
>>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Best Regards
Shawn Lin



From zhengxing at rock-chips.com  Thu Oct 20 21:03:40 2016
From: zhengxing at rock-chips.com (Xing Zheng)
Date: Fri, 21 Oct 2016 12:03:40 +0800
Subject: [PATCH] clk: rockchip: add 533.25MHz to rk3399 clock rates table
Message-ID: <1477022620-8143-1-git-send-email-zhengxing@rock-chips.com>

We need to get the accurate 533.25MHz for the DP display.

Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
---

 drivers/clk/rockchip/clk-rk3399.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-rk3399.c b/drivers/clk/rockchip/clk-rk3399.c
index 2c7cba7..a87cb49 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -93,6 +93,7 @@ static struct rockchip_pll_rate_table rk3399_pll_rates[] = {
 	RK3036_PLL_RATE( 676000000, 3, 169, 2, 1, 1, 0),
 	RK3036_PLL_RATE( 600000000, 1, 75, 3, 1, 1, 0),
 	RK3036_PLL_RATE( 594000000, 1, 99, 4, 1, 1, 0),
+	RK3036_PLL_RATE( 533250000, 8, 711, 4, 1, 1, 0),
 	RK3036_PLL_RATE( 504000000, 1, 63, 3, 1, 1, 0),
 	RK3036_PLL_RATE( 500000000, 6, 250, 2, 1, 1, 0),
 	RK3036_PLL_RATE( 408000000, 1, 68, 2, 2, 1, 0),
-- 
2.7.4




From tglx at linutronix.de  Thu Oct 20 23:47:46 2016
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 21 Oct 2016 08:47:46 +0200 (CEST)
Subject: [PATCH v4 1/2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <CAD=FV=W4qSXHywGNEg6tOq8WiC7cROME4g3SwTxkD7h7=NsvvQ@mail.gmail.com>
References: <1476998490-4481-1-git-send-email-dianders@chromium.org>
 <alpine.DEB.2.20.1610202326070.4938@nanos>
 <CAD=FV=W4qSXHywGNEg6tOq8WiC7cROME4g3SwTxkD7h7=NsvvQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1610210846140.4797@nanos>

On Thu, 20 Oct 2016, Doug Anderson wrote:
> On Thu, Oct 20, 2016 at 2:27 PM, Thomas Gleixner <tglx at linutronix.de> wrote:
> > On Thu, 20 Oct 2016, Douglas Anderson wrote:
> >
> > Please wait for a full review and do not send out patches 5 seconds after
> > the first mail hits your inbox.
> 
> Since you had previously commented on patch 1 and had already
> commented on patch 2, I presumed you were done reviewing, but I was
> obviously in error.  My apologies.

No problem. As a general rule you should not send updates like a machine
gun. That issue is years old, so there is no rush to fix it just because
some random (probably out of tree) code trips over it.

Thanks,

	tglx


From tglx at linutronix.de  Fri Oct 21 00:08:23 2016
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 21 Oct 2016 09:08:23 +0200 (CEST)
Subject: [PATCH v3 1/2] timers: Fix usleep_range() in the context of
 wake_up_process()
In-Reply-To: <CAD=FV=U0sURwAmsiLg0q+=e8o7NfJLWEUAu4zeY1so83cDqXhA@mail.gmail.com>
References: <1476995664-15668-1-git-send-email-dianders@chromium.org>
 <alpine.DEB.2.20.1610202306550.4938@nanos>
 <CAD=FV=U0sURwAmsiLg0q+=e8o7NfJLWEUAu4zeY1so83cDqXhA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1610210847510.4797@nanos>

On Thu, 20 Oct 2016, Doug Anderson wrote:
> > And this is broken because schedule_hrtimeout_range() returns with task
> > state TASK_RUNNING so the next schedule_hrtimeout_range() will return
> > -EINTR again because nothing sets the task state back to UNINTERRUPTIBLE.
> > So instead of sleeping you busy loop.
> 
> That explains the mystery of why my delays were always so precise in
> the test.  I was a bit baffled by the fact that I was ending up with a
> delay of almost exactly 50001 or 50002 in my test case.

Well, if you see something as a mystery or you are baffled, then you
certainly should figure out why and not just declare: Works for me, but I
don't know why. That's stuff which comes back to hunt you sooner than
later.
    
> > What you really want to do is something like this:
> >
> > void __sched usleep_range(unsigned long min, unsigned long max)
> > {
> >         ktime_t expires = ktime_add_us(ktime_get(), min * NSEC_PER_USEC);
> >         ktime_t delta = ktime_set(0, (u64)(max - min) * NSEC_PER_USEC);
> >
> >         for (;;) {
> >                 __set_current_state(TASK_UNINTERRUPTIBLE);
> >                 /* Do not return before the requested sleep time has elapsed */
> >                 if (!schedule_hrtimeout_range(&expires, delta, HRTIMER_MODE_ABS))
> >                         break;
> >         }
> > }
> 
> The above mostly works other than some small fixups.  Thanks!

Yeah, delta is u64. Was too lazy to look it up.
 
> ...other than small fixups, the one substantive change I'll make is to
> actually check the timeout in the loop above.  If I use your code with
> my test, I find that, even though I'm waking up every millisecond I
> still end up not exiting the loop until the upper bound of the delay.
> 
> Presumably this happens because:
> 
>   a_time_in_the_past = ktime_sub_us(ktime_get(), 10);
>   schedule_hrtimeout_range(&a_time_in_the_past, delta, HRTIMER_MODE_ABS)
> 
> ...delays "delta" nano seconds even though "a_time_in_the_past" is in
> the past.  I presume that behavior is OK (let me know if it's not).

It does not delay delta nano seconds. It delays to 

   (now - 10us) + deltans

The core is free to use the full range for batching or extending idle sleep
times and with a delta > 10us it's expected and correct behaviour.

> In the case of usleep_range() if we're waking up anyway, it seems
> sensible to spend a few cycles to see if the minimum bound has already
> past.

We really can do without that. You are over engineering for something which
is pointless in 99.9% of the use cases. That stuff is what causes bloat. A
few lines of code here and there, which sums up in the end.

Thanks,

	tglx




From w.egorov at phytec.de  Fri Oct 21 00:44:47 2016
From: w.egorov at phytec.de (Wadim Egorov)
Date: Fri, 21 Oct 2016 09:44:47 +0200
Subject: [PATCH] mfd: rk808: RK818 uses DEV_OFF to power off supplies
In-Reply-To: <1476694990-1887-1-git-send-email-chenjh@rock-chips.com>
References: <1476694990-1887-1-git-send-email-chenjh@rock-chips.com>
Message-ID: <5809C76F.4070409@phytec.de>

Hi Jianhong,

with this patch a poweroff causes a restart on our board.
In our design a 5V USB voltage is supplied on the USB supply input pins.
After setting DEV_OFF bit, the RK818 restart automatically. The
ON_SOURCE_REG (Address AEH) is 0x40 after the automatic restart which
says that the RK818 was started by ON_PLUG_IN event.
Is there a possibility to configure the RK818 that it will not start
automatically in this case?

Regards,
Wadim

On 17.10.2016 11:03, Jianhong Chen wrote:
> DEV_OFF and DEV_OFF_RST functions for RK808 are designed error that
> only DEV_OFF_RST can power off supplies. RK818 has been fixed this
> issue, so that DEV_OFF is used to power off supplies.
>
> Signed-off-by: Jianhong Chen <chenjh at rock-chips.com>
> ---
>  drivers/mfd/rk808.c       | 23 ++++++++++++++++++++++-
>  include/linux/mfd/rk808.h |  1 +
>  2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
> index 0f8acc5..2c9acdb 100644
> --- a/drivers/mfd/rk808.c
> +++ b/drivers/mfd/rk808.c
> @@ -290,6 +290,24 @@ static void rk808_device_shutdown(void)
>  		dev_err(&rk808_i2c_client->dev, "power off error!\n");
>  }
>  
> +static void rk818_device_shutdown(void)
> +{
> +	int ret;
> +	struct rk808 *rk808 = i2c_get_clientdata(rk808_i2c_client);
> +
> +	if (!rk808) {
> +		dev_warn(&rk808_i2c_client->dev,
> +			 "have no rk818, so do nothing here\n");
> +		return;
> +	}
> +
> +	ret = regmap_update_bits(rk808->regmap,
> +				 RK818_DEVCTRL_REG,
> +				 DEV_OFF, DEV_OFF);
> +	if (ret)
> +		dev_err(&rk808_i2c_client->dev, "power off error!\n");
> +}
> +
>  static const struct of_device_id rk808_of_match[] = {
>  	{ .compatible = "rockchip,rk808" },
>  	{ .compatible = "rockchip,rk818" },
> @@ -304,6 +322,7 @@ static int rk808_probe(struct i2c_client *client,
>  	struct rk808 *rk808;
>  	const struct rk808_reg_data *pre_init_reg;
>  	const struct mfd_cell *cells;
> +	void (*pm_pwroff_fn)(void);
>  	int nr_pre_init_regs;
>  	int nr_cells;
>  	int pm_off = 0;
> @@ -331,6 +350,7 @@ static int rk808_probe(struct i2c_client *client,
>  		nr_pre_init_regs = ARRAY_SIZE(rk808_pre_init_reg);
>  		cells = rk808s;
>  		nr_cells = ARRAY_SIZE(rk808s);
> +		pm_pwroff_fn = rk808_device_shutdown;
>  		break;
>  	case RK818_ID:
>  		rk808->regmap_cfg = &rk818_regmap_config;
> @@ -339,6 +359,7 @@ static int rk808_probe(struct i2c_client *client,
>  		nr_pre_init_regs = ARRAY_SIZE(rk818_pre_init_reg);
>  		cells = rk818s;
>  		nr_cells = ARRAY_SIZE(rk818s);
> +		pm_pwroff_fn = rk818_device_shutdown;
>  		break;
>  	default:
>  		dev_err(&client->dev, "Unsupported RK8XX ID %lu\n",
> @@ -393,7 +414,7 @@ static int rk808_probe(struct i2c_client *client,
>  				"rockchip,system-power-controller");
>  	if (pm_off && !pm_power_off) {
>  		rk808_i2c_client = client;
> -		pm_power_off = rk808_device_shutdown;
> +		pm_power_off = pm_pwroff_fn;
>  	}
>  
>  	return 0;
> diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
> index 6d435a3..83701ef 100644
> --- a/include/linux/mfd/rk808.h
> +++ b/include/linux/mfd/rk808.h
> @@ -290,6 +290,7 @@ enum rk818_reg {
>  #define SWITCH2_EN	BIT(6)
>  #define SWITCH1_EN	BIT(5)
>  #define DEV_OFF_RST	BIT(3)
> +#define DEV_OFF		BIT(0)
>  
>  #define VB_LO_ACT		BIT(4)
>  #define VB_LO_SEL_3500MV	(7 << 0)



From heiko at sntech.de  Fri Oct 21 00:47:29 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 21 Oct 2016 09:47:29 +0200
Subject: [PATCH] clk: rockchip: add 533.25MHz to rk3399 clock rates table
In-Reply-To: <1477022620-8143-1-git-send-email-zhengxing@rock-chips.com>
References: <1477022620-8143-1-git-send-email-zhengxing@rock-chips.com>
Message-ID: <10119527.9b3VbjvMOc@phil>

Am Freitag, 21. Oktober 2016, 12:03:40 CEST schrieb Xing Zheng:
> We need to get the accurate 533.25MHz for the DP display.
> 
> Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>

applied to my clk-branch for 4.10


Thanks
Heiko


From heiko at sntech.de  Fri Oct 21 00:56:26 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 21 Oct 2016 09:56:26 +0200
Subject: [PATCH 1/2] PCI: rockchip: Add three new resets as required
 properties
In-Reply-To: <1477017836-19317-2-git-send-email-shawn.lin@rock-chips.com>
References: <1477017836-19317-1-git-send-email-shawn.lin@rock-chips.com>
 <1477017836-19317-2-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <2683489.TXdAHLhj84@phil>

Am Freitag, 21. Oktober 2016, 10:43:55 CEST schrieb Shawn Lin:
> pm_rst, aclk_rst, pclk_rst was controlled by rom code so the
> software wasn't needed to control it again in theory. But it
> didn't work properly, so we do need to do it again and add a
> enough delay between the assert of pm_rst and the deassert of
> pm_rst. The Soc intergrated with this controller, rk3399 is still
> under MP test internally, so the backward compatibility won't be
> a big deal.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

looks good from my side.
Reviewed-by: Heiko Stuebner <heiko at sntech.de>

As Shawn wrote the soc in question (first one at all with a pcie controller) 
has not yet found its way into any device, so no existing one can abviously be 
affected by this change. So doing it this way will hopefully be ok.

Obviously it would probably be nice, to have this in 4.9-rc to keep the gap 
small.


Heiko

>  .../devicetree/bindings/pci/rockchip-pcie.txt      | 11 ++--
>  drivers/pci/host/pcie-rockchip.c                   | 62
> ++++++++++++++++++++++ 2 files changed, 70 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt index
> ba67b39..71aeda1 100644
> --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> @@ -26,13 +26,16 @@ Required properties:
>  	- "sys"
>  	- "legacy"
>  	- "client"
> -- resets: Must contain five entries for each entry in reset-names.
> +- resets: Must contain seven entries for each entry in reset-names.
>  	   See ../reset/reset.txt for details.
>  - reset-names: Must include the following names
>  	- "core"
>  	- "mgmt"
>  	- "mgmt-sticky"
>  	- "pipe"
> +	- "pm"
> +	- "aclk"
> +	- "pclk"
>  - pinctrl-names : The pin control state names
>  - pinctrl-0: The "default" pinctrl state
>  - #interrupt-cells: specifies the number of cells needed to encode an
> @@ -86,8 +89,10 @@ pcie0: pcie at f8000000 {
>  	reg = <0x0 0xf8000000 0x0 0x2000000>, <0x0 0xfd000000 0x0 0x1000000>;
>  	reg-names = "axi-base", "apb-base";
>  	resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
> -		 <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE>;
> -	reset-names = "core", "mgmt", "mgmt-sticky", "pipe";
> +		 <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE> ,
> +		 <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>, <&cru SRST_A_PCIE>;
> +	reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
> +		      "pm", "pclk", "aclk";
>  	phys = <&pcie_phy>;
>  	phy-names = "pcie-phy";
>  	pinctrl-names = "default";
> diff --git a/drivers/pci/host/pcie-rockchip.c
> b/drivers/pci/host/pcie-rockchip.c index e0b22da..e04f69b 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -190,6 +190,9 @@ struct rockchip_pcie {
>  	struct	reset_control *mgmt_rst;
>  	struct	reset_control *mgmt_sticky_rst;
>  	struct	reset_control *pipe_rst;
> +	struct	reset_control *pm_rst;
> +	struct	reset_control *aclk_rst;
> +	struct	reset_control *pclk_rst;
>  	struct	clk *aclk_pcie;
>  	struct	clk *aclk_perf_pcie;
>  	struct	clk *hclk_pcie;
> @@ -408,6 +411,44 @@ static int rockchip_pcie_init_port(struct rockchip_pcie
> *rockchip)
> 
>  	gpiod_set_value(rockchip->ep_gpio, 0);
> 
> +	err = reset_control_assert(rockchip->aclk_rst);
> +	if (err) {
> +		dev_err(dev, "assert aclk_rst err %d\n", err);
> +		return err;
> +	}
> +
> +	err = reset_control_assert(rockchip->pclk_rst);
> +	if (err) {
> +		dev_err(dev, "assert pclk_rst err %d\n", err);
> +		return err;
> +	}
> +
> +	err = reset_control_assert(rockchip->pm_rst);
> +	if (err) {
> +		dev_err(dev, "assert pm_rst err %d\n", err);
> +		return err;
> +	}
> +
> +	udelay(10);
> +
> +	err = reset_control_deassert(rockchip->pm_rst);
> +	if (err) {
> +		dev_err(dev, "deassert pm_rst err %d\n", err);
> +		return err;
> +	}
> +
> +	err = reset_control_deassert(rockchip->aclk_rst);
> +	if (err) {
> +		dev_err(dev, "deassert mgmt_sticky_rst err %d\n", err);
> +		return err;
> +	}
> +
> +	err = reset_control_deassert(rockchip->pclk_rst);
> +	if (err) {
> +		dev_err(dev, "deassert mgmt_sticky_rst err %d\n", err);
> +		return err;
> +	}
> +
>  	err = phy_init(rockchip->phy);
>  	if (err < 0) {
>  		dev_err(dev, "fail to init phy, err %d\n", err);
> @@ -781,6 +822,27 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie
> *rockchip) return PTR_ERR(rockchip->pipe_rst);
>  	}
> 
> +	rockchip->pm_rst = devm_reset_control_get(dev, "pm");
> +	if (IS_ERR(rockchip->pm_rst)) {
> +		if (PTR_ERR(rockchip->pm_rst) != -EPROBE_DEFER)
> +			dev_err(dev, "missing pm reset property in node\n");
> +		return PTR_ERR(rockchip->pm_rst);
> +	}
> +
> +	rockchip->pclk_rst = devm_reset_control_get(dev, "pclk");
> +	if (IS_ERR(rockchip->pclk_rst)) {
> +		if (PTR_ERR(rockchip->pclk_rst) != -EPROBE_DEFER)
> +			dev_err(dev, "missing pclk reset property in node\n");
> +		return PTR_ERR(rockchip->pclk_rst);
> +	}
> +
> +	rockchip->aclk_rst = devm_reset_control_get(dev, "aclk");
> +	if (IS_ERR(rockchip->aclk_rst)) {
> +		if (PTR_ERR(rockchip->aclk_rst) != -EPROBE_DEFER)
> +			dev_err(dev, "missing aclk reset property in node\n");
> +		return PTR_ERR(rockchip->aclk_rst);
> +	}
> +
>  	rockchip->ep_gpio = devm_gpiod_get(dev, "ep", GPIOD_OUT_HIGH);
>  	if (IS_ERR(rockchip->ep_gpio)) {
>  		dev_err(dev, "missing ep-gpios property in node\n");




From heiko at sntech.de  Fri Oct 21 00:58:11 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 21 Oct 2016 09:58:11 +0200
Subject: [PATCH 2/2] arm64: dts: rockchip: add three new resets for rk3399
 PCIe controller
In-Reply-To: <1477017836-19317-3-git-send-email-shawn.lin@rock-chips.com>
References: <1477017836-19317-1-git-send-email-shawn.lin@rock-chips.com>
 <1477017836-19317-3-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <7351283.vgsyxVQ7sJ@phil>

Hi Bjorn,

Am Freitag, 21. Oktober 2016, 10:43:56 CEST schrieb Shawn Lin:
> pm_rst, aclk_rst and pclk_rst should be controlled by driver, so we
> need to add these three resets for PCIe controller.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

If patch1 is ok and you want to take both patches at once,
that is fine by me, so
Acked-by: Heiko Stuebner <heiko at sntech.de>

Otherwise I can also pick this one up after (and if) your ok with patch1.


Heiko

> ---
> 
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index 76b2864..5191cfd 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -300,8 +300,11 @@
>  		ranges = <0x83000000 0x0 0xfa000000 0x0 0xfa000000 0x0 0x600000
>  			  0x81000000 0x0 0xfa600000 0x0 0xfa600000 0x0 0x100000>;
>  		resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
> -			 <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE>;
> -		reset-names = "core", "mgmt", "mgmt-sticky", "pipe";
> +			 <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE>,
> +			 <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>,
> +			 <&cru SRST_A_PCIE>;
> +		reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
> +			      "pm", "pclk", "aclk";
>  		status = "disabled";
> 
>  		pcie0_intc: interrupt-controller {




From heiko at sntech.de  Fri Oct 21 01:25:29 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 21 Oct 2016 10:25:29 +0200
Subject: [PATCH] ARM: dts: rockchip: add i2c-bus subnode to edp
In-Reply-To: <6083453f-08e1-643a-9638-1db38c704aa5@collabora.com>
References: <1476950845-28242-1-git-send-email-tomeu.vizoso@collabora.com>
 <7604646.6yosK0XMNL@diego>
 <6083453f-08e1-643a-9638-1db38c704aa5@collabora.com>
Message-ID: <1681294.eoXpQL8f8l@phil>

Am Donnerstag, 20. Oktober 2016, 15:47:56 CEST schrieb Tomeu Vizoso:
> On 10/20/2016 03:45 PM, Heiko St?bner wrote:
> > Am Donnerstag, 20. Oktober 2016, 10:07:25 schrieb Tomeu Vizoso:
> >> Add an empty 'i2c-bus' subnode to the edp node just so that the I2C core
> >> doesn't attemp to parse the 'ports' subnode as containing i2c devices.
> >> 
> >> This is to avoid spurious failure messages such as:
> >> 
> >> i2c i2c-6: of_i2c: modalias failure on /dp at ff970000/ports
> > 
> > On the one hand, the edp really has an i2c bus - with its only client the
> > EDID listening at 0x50 (and maybe 0x30).
> > 
> > On the other hand, adding an empty bus to the (implementation independent)
> > devicetree just to make the Linux i2c subsystem happy sounds heavily like
> > a
> > implementation-specific hack, as the edp i2c bus doesn't leak into the
> > outside world otherwise.
> > 
> > I guess this empty i2c bus not being part of the binding document points
> > heavily into the implementation-specific corner :-) .
> > 
> > My short search on other patches touching this didn't reveal anything but
> > maybe this was already discussed somewhere and found to be ok?
> 
> Here it is:
> 
> http://www.spinics.net/lists/linux-tegra/msg27862.html

thanks ... I'm still not sure about the placeholder though, aka needing an 
undocumented subnode to make a Linux error message silent.

In the thread you pointed to I also did not see any dt-maintainer involvement 
pointing one way or another, but spinics is often not easy to navigate 
threads, so I may have missed that.


> > Another option could be to just make of_i2c_register_device silent if
> > of_modalias_node returns -ENODEV?


Heiko

> >> Signed-off-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>
> >> Cc: Randy Li <randy.li at rock-chips.com>
> >> Cc: Jon Hunter <jonathanh at nvidia.com>
> >> ---
> >> 
> >>  arch/arm/boot/dts/rk3288.dtsi | 5 +++++
> >>  1 file changed, 5 insertions(+)
> >> 
> >> diff --git a/arch/arm/boot/dts/rk3288.dtsi
> >> b/arch/arm/boot/dts/rk3288.dtsi
> >> index 2f814ffeb605..94f4b7eecca2 100644
> >> --- a/arch/arm/boot/dts/rk3288.dtsi
> >> +++ b/arch/arm/boot/dts/rk3288.dtsi
> >> @@ -1075,6 +1075,11 @@
> >> 
> >>  				};
> >>  			
> >>  			};
> >>  		
> >>  		};
> >> 
> >> +
> >> +		i2c-bus {
> >> +			#address-cells = <1>;
> >> +			#size-cells = <0>;
> >> +		};
> >> 
> >>  	};
> >>  	
> >>  	hdmi: hdmi at ff980000 {




From randy.li at rock-chips.com  Fri Oct 21 01:32:24 2016
From: randy.li at rock-chips.com (Randy Li)
Date: Fri, 21 Oct 2016 16:32:24 +0800
Subject: [PATCH] ARM: dts: rockchip: add i2c-bus subnode to edp
In-Reply-To: <1681294.eoXpQL8f8l@phil>
References: <1476950845-28242-1-git-send-email-tomeu.vizoso@collabora.com>
 <7604646.6yosK0XMNL@diego>
 <6083453f-08e1-643a-9638-1db38c704aa5@collabora.com>
 <1681294.eoXpQL8f8l@phil>
Message-ID: <13de56c8-accb-de5d-1713-1bdedf0291b7@rock-chips.com>



On 10/21/2016 04:25 PM, Heiko Stuebner wrote:
> Am Donnerstag, 20. Oktober 2016, 15:47:56 CEST schrieb Tomeu Vizoso:
>> On 10/20/2016 03:45 PM, Heiko St?bner wrote:
>>> Am Donnerstag, 20. Oktober 2016, 10:07:25 schrieb Tomeu Vizoso:
>>>> Add an empty 'i2c-bus' subnode to the edp node just so that the I2C core
>>>> doesn't attemp to parse the 'ports' subnode as containing i2c devices.
>>>>
>>>> This is to avoid spurious failure messages such as:
>>>>
>>>> i2c i2c-6: of_i2c: modalias failure on /dp at ff970000/ports
>>>
>>> On the one hand, the edp really has an i2c bus - with its only client the
>>> EDID listening at 0x50 (and maybe 0x30).
>>>
>>> On the other hand, adding an empty bus to the (implementation independent)
>>> devicetree just to make the Linux i2c subsystem happy sounds heavily like
>>> a
>>> implementation-specific hack, as the edp i2c bus doesn't leak into the
>>> outside world otherwise.
>>>
>>> I guess this empty i2c bus not being part of the binding document points
>>> heavily into the implementation-specific corner :-) .
>>>
>>> My short search on other patches touching this didn't reveal anything but
>>> maybe this was already discussed somewhere and found to be ok?
>>
>> Here it is:
>>
>> http://www.spinics.net/lists/linux-tegra/msg27862.html
>
> thanks ... I'm still not sure about the placeholder though, aka needing an
> undocumented subnode to make a Linux error message silent.
No it won't and the other error message. I have enabled the i2c debug, 
and would report what it is going on.
Just it is too late yesterday, I have no time to report that.
>
> In the thread you pointed to I also did not see any dt-maintainer involvement
> pointing one way or another, but spinics is often not easy to navigate
> threads, so I may have missed that.
>
>
>>> Another option could be to just make of_i2c_register_device silent if
>>> of_modalias_node returns -ENODEV?
>
>
> Heiko
>
>>>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>
>>>> Cc: Randy Li <randy.li at rock-chips.com>
>>>> Cc: Jon Hunter <jonathanh at nvidia.com>
>>>> ---
>>>>
>>>>  arch/arm/boot/dts/rk3288.dtsi | 5 +++++
>>>>  1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/rk3288.dtsi
>>>> b/arch/arm/boot/dts/rk3288.dtsi
>>>> index 2f814ffeb605..94f4b7eecca2 100644
>>>> --- a/arch/arm/boot/dts/rk3288.dtsi
>>>> +++ b/arch/arm/boot/dts/rk3288.dtsi
>>>> @@ -1075,6 +1075,11 @@
>>>>
>>>>  				};
>>>>  			
>>>>  			};
>>>>  		
>>>>  		};
>>>>
>>>> +
>>>> +		i2c-bus {
>>>> +			#address-cells = <1>;
>>>> +			#size-cells = <0>;
>>>> +		};
>>>>
>>>>  	};
>>>>  	
>>>>  	hdmi: hdmi at ff980000 {
>
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>

-- 
Randy Li
The third produce department
===========================================================================
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===========================================================================



From chenjh at rock-chips.com  Fri Oct 21 02:15:34 2016
From: chenjh at rock-chips.com (chenjh)
Date: Fri, 21 Oct 2016 17:15:34 +0800
Subject: [PATCH] mfd: rk808: RK818 uses DEV_OFF to power off supplies
In-Reply-To: <5809C76F.4070409@phytec.de>
References: <1476694990-1887-1-git-send-email-chenjh@rock-chips.com>
 <5809C76F.4070409@phytec.de>
Message-ID: <5809DCB6.9020703@rock-chips.com>

Hi Wadim:

     It's impossible not to restart automatically, this situation is 
normal for RK818.
     Because it is hardware designed that RK818 can't power off when a 
voltage is supplies on the USB supply input pins.



Best Regards

? 2016/10/21 15:44, Wadim Egorov ??:
> Hi Jianhong,
>
> with this patch a poweroff causes a restart on our board.
> In our design a 5V USB voltage is supplied on the USB supply input pins.
> After setting DEV_OFF bit, the RK818 restart automatically. The
> ON_SOURCE_REG (Address AEH) is 0x40 after the automatic restart which
> says that the RK818 was started by ON_PLUG_IN event.
> Is there a possibility to configure the RK818 that it will not start
> automatically in this case?
>
> Regards,
> Wadim
>
> On 17.10.2016 11:03, Jianhong Chen wrote:
>> DEV_OFF and DEV_OFF_RST functions for RK808 are designed error that
>> only DEV_OFF_RST can power off supplies. RK818 has been fixed this
>> issue, so that DEV_OFF is used to power off supplies.
>>
>> Signed-off-by: Jianhong Chen <chenjh at rock-chips.com>
>> ---
>>   drivers/mfd/rk808.c       | 23 ++++++++++++++++++++++-
>>   include/linux/mfd/rk808.h |  1 +
>>   2 files changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
>> index 0f8acc5..2c9acdb 100644
>> --- a/drivers/mfd/rk808.c
>> +++ b/drivers/mfd/rk808.c
>> @@ -290,6 +290,24 @@ static void rk808_device_shutdown(void)
>>   		dev_err(&rk808_i2c_client->dev, "power off error!\n");
>>   }
>>   
>> +static void rk818_device_shutdown(void)
>> +{
>> +	int ret;
>> +	struct rk808 *rk808 = i2c_get_clientdata(rk808_i2c_client);
>> +
>> +	if (!rk808) {
>> +		dev_warn(&rk808_i2c_client->dev,
>> +			 "have no rk818, so do nothing here\n");
>> +		return;
>> +	}
>> +
>> +	ret = regmap_update_bits(rk808->regmap,
>> +				 RK818_DEVCTRL_REG,
>> +				 DEV_OFF, DEV_OFF);
>> +	if (ret)
>> +		dev_err(&rk808_i2c_client->dev, "power off error!\n");
>> +}
>> +
>>   static const struct of_device_id rk808_of_match[] = {
>>   	{ .compatible = "rockchip,rk808" },
>>   	{ .compatible = "rockchip,rk818" },
>> @@ -304,6 +322,7 @@ static int rk808_probe(struct i2c_client *client,
>>   	struct rk808 *rk808;
>>   	const struct rk808_reg_data *pre_init_reg;
>>   	const struct mfd_cell *cells;
>> +	void (*pm_pwroff_fn)(void);
>>   	int nr_pre_init_regs;
>>   	int nr_cells;
>>   	int pm_off = 0;
>> @@ -331,6 +350,7 @@ static int rk808_probe(struct i2c_client *client,
>>   		nr_pre_init_regs = ARRAY_SIZE(rk808_pre_init_reg);
>>   		cells = rk808s;
>>   		nr_cells = ARRAY_SIZE(rk808s);
>> +		pm_pwroff_fn = rk808_device_shutdown;
>>   		break;
>>   	case RK818_ID:
>>   		rk808->regmap_cfg = &rk818_regmap_config;
>> @@ -339,6 +359,7 @@ static int rk808_probe(struct i2c_client *client,
>>   		nr_pre_init_regs = ARRAY_SIZE(rk818_pre_init_reg);
>>   		cells = rk818s;
>>   		nr_cells = ARRAY_SIZE(rk818s);
>> +		pm_pwroff_fn = rk818_device_shutdown;
>>   		break;
>>   	default:
>>   		dev_err(&client->dev, "Unsupported RK8XX ID %lu\n",
>> @@ -393,7 +414,7 @@ static int rk808_probe(struct i2c_client *client,
>>   				"rockchip,system-power-controller");
>>   	if (pm_off && !pm_power_off) {
>>   		rk808_i2c_client = client;
>> -		pm_power_off = rk808_device_shutdown;
>> +		pm_power_off = pm_pwroff_fn;
>>   	}
>>   
>>   	return 0;
>> diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
>> index 6d435a3..83701ef 100644
>> --- a/include/linux/mfd/rk808.h
>> +++ b/include/linux/mfd/rk808.h
>> @@ -290,6 +290,7 @@ enum rk818_reg {
>>   #define SWITCH2_EN	BIT(6)
>>   #define SWITCH1_EN	BIT(5)
>>   #define DEV_OFF_RST	BIT(3)
>> +#define DEV_OFF		BIT(0)
>>   
>>   #define VB_LO_ACT		BIT(4)
>>   #define VB_LO_SEL_3500MV	(7 << 0)
>
>
>




From heiko at sntech.de  Fri Oct 21 06:44:49 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 21 Oct 2016 15:44:49 +0200
Subject: [PATCH v2 0/2] Assign RK3066 clocks at boot time
In-Reply-To: <58a16125-d0bd-1019-eee3-615b35c71c6a@gmail.com>
References: <cover.1476447057.git.paweljarosz3691@gmail.com>
 <1569308.lsrqUgJ5m1@phil> <58a16125-d0bd-1019-eee3-615b35c71c6a@gmail.com>
Message-ID: <13309666.zpbVPubHs9@phil>

Am Freitag, 14. Oktober 2016, 16:11:26 CEST schrieb Pawe? Jarosz:
> W dniu 14.10.2016 o 15:28, Heiko Stuebner pisze:
> > changes look good. One thing to keep in mind is that we need clock-id
> > additions in a separate patch (as they need to be on a shared branch).
> > 
> > I can do this split of patch1 on my own here, so no need to resend the
> > series and will do that after 4.9-rc1 (probably somewhere after sunday)
> > as I need a stable base for that shared branch.
> > 

As written before, I've now split up patch1 into two and applied all 3 patches 
for 4.10


Thanks
Heiko


From linux at armlinux.org.uk  Fri Oct 21 08:23:12 2016
From: linux at armlinux.org.uk (Russell King - ARM Linux)
Date: Fri, 21 Oct 2016 16:23:12 +0100
Subject: [PATCH] drm: convert DT component matching to
 component_match_add_release()
In-Reply-To: <CAOw6vbJ64JOugR2b3R87pFRDGDVs9HM3uZJM2z1-jHyhPf6WOA@mail.gmail.com>
References: <E1bwo6l-0005Io-Q1@rmk-PC.armlinux.org.uk>
 <CAOw6vbK=z3wJKTh8jZoU2Gj1PtTLLH_sAUUShbsxL=Qi7d+FLw@mail.gmail.com>
 <20161020215022.GZ1041@n2100.armlinux.org.uk>
 <CAOw6vbJ64JOugR2b3R87pFRDGDVs9HM3uZJM2z1-jHyhPf6WOA@mail.gmail.com>
Message-ID: <20161021152312.GB1041@n2100.armlinux.org.uk>

On Thu, Oct 20, 2016 at 07:15:56PM -0400, Sean Paul wrote:
> On Thu, Oct 20, 2016 at 5:50 PM, Russell King - ARM Linux
> <linux at armlinux.org.uk> wrote:
> > On Thu, Oct 20, 2016 at 04:39:04PM -0400, Sean Paul wrote:
> >> On Wed, Oct 19, 2016 at 6:28 AM, Russell King
> >> <rmk+kernel at armlinux.org.uk> wrote:
> >> > Convert DT component matching to use component_match_add_release().
> >> >
> >> > Signed-off-by: Russell King <rmk+kernel at armlinux.org.uk>
> >> > ---
> >> > Can we please get this patch from May merged into the drm-misc or
> >> > whatever trees so that we don't end up with conflicts?  I've no idea
> >> > who looks after drm-misc, as they have _still_ failed to add
> >> > themselves to MAINTAINERS.
> >>
> >> I think Daniel explained pretty clearly why this wasn't happening in
> >> the previous thread.
> >>
> >> Next time you send a v2, can you please mark it as such and include a
> >> "Changes in v2" section?
> >
> > Why - nothing's changed other than a rebase onto 4.9-rc1.  This isn't
> > a "I've changed it in XYZ way, so here's a new copy".
> 
> 
> Changes in v2: None
> 
> Is still useful since:
> a) the diffstat is different from v1, which necessitates me going
> through both versions to see what's changed from the previous reviews
> (only to find out myself that it's been rebased and a function has
> changed names)

Sorry, but I don't track in any fine detail what the changes are
between patches when I bring them forward: I have far too many patches
to do that (I have 300 right now) and I never know whether they're
going to result in a pull request or not.  It means finding some way
to manually attach a change log to each patch I send out, which will
be very time consuming.  I'd rather not send patches out than jump
through hoops like that, especially when the reason is that the
previous version was ignored.

> b) in June, you said you were going to roll a new version with the
> common OF bits extracted. it's nice to know at the outset that this
> has/hasn't happened

Now if you were following the rest of it, rather than just random parts
that suited you, you'd have noticed that I posted the new version, but
that caused more issues, so I publically said I was reverting back to
the original version.

> Also, prefacing the subject with [PATCH v2] or [PATCH RESEND] lets me
> know there is prior history with the change. Reading the previous
> version is helpful to see what reviewer's concerns were, and whether
> they've been addressed.

Yea, I'm very bad at changing the subject line in that way, and I'm
getting worse at it.  Sorry, I try my best, but I can't do better than
that.

> 
> 
> > It's being
> > posted in the hope that someone will finally either comment on it or
> > merge the damn thing, rather than ignoring it was done when it was
> > last posted.
> >
> >> >  drivers/gpu/drm/arm/hdlcd_drv.c                 |  3 ++-
> >> >  drivers/gpu/drm/arm/malidp_drv.c                |  4 +++-
> >> >  drivers/gpu/drm/armada/armada_drv.c             |  2 +-
> >> >  drivers/gpu/drm/drm_of.c                        | 28 +++++++++++++++++++++++--
> >> >  drivers/gpu/drm/etnaviv/etnaviv_drv.c           |  5 +++--
> >> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  7 ++++---
> >> >  drivers/gpu/drm/mediatek/mtk_drm_drv.c          |  4 +++-
> >> >  drivers/gpu/drm/msm/msm_drv.c                   | 12 ++++++-----
> >> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c     |  6 ++++--
> >> >  drivers/gpu/drm/sti/sti_drv.c                   |  5 +++--
> >> >  drivers/gpu/drm/sun4i/sun4i_drv.c               |  3 ++-
> >> >  drivers/gpu/drm/tilcdc/tilcdc_external.c        |  4 +++-
> >> >  include/drm/drm_of.h                            | 12 +++++++++++
> >> >  13 files changed, 73 insertions(+), 22 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> >> > index fb6a418ce6be..6477d1a65266 100644
> >> > --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> >> > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> >> > @@ -453,7 +453,8 @@ static int hdlcd_probe(struct platform_device *pdev)
> >> >                 return -EAGAIN;
> >> >         }
> >> >
> >> > -       component_match_add(&pdev->dev, &match, compare_dev, port);
> >> > +       drm_of_component_match_add(&pdev->dev, &match, compare_dev, port);
> >> > +       of_node_put(port);
> >>
> >> There's no mention in your commit message about fixing these node leaks.
> >
> > Isn't that kind-of the whole point of this patch?
> >
> 
> Not according to the commit msg, it isn't.
> 
> You could have just done the of_node_put adds/relocations without
> wrapping component_match_add_release.

No, adding the of_node_put() there without the other changes means that
the OF layer can drop the "port" device node, kfree() it, and reallocate
it as a different device node - which means that we can end up matching
some random other device rather than the intended one.  Hence, it is
_fundamentally_ a part of this patch and isn't an independent change.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From dianders at chromium.org  Fri Oct 21 08:58:50 2016
From: dianders at chromium.org (Douglas Anderson)
Date: Fri, 21 Oct 2016 08:58:50 -0700
Subject: [PATCH v5 1/2] timers: Fix usleep_range() in the context of
 wake_up_process()
Message-ID: <1477065531-30342-1-git-send-email-dianders@chromium.org>

Users of usleep_range() expect that it will _never_ return in less time
than the minimum passed parameter.  However, nothing in any of the code
ensures this.  Specifically:

usleep_range() => do_usleep_range() => schedule_hrtimeout_range() =>
schedule_hrtimeout_range_clock() just ends up calling schedule() with an
appropriate timeout set using the hrtimer.  If someone else happens to
wake up our task then we'll happily return from usleep_range() early.

msleep() already has code to handle this case since it will loop as long
as there was still time left.  usleep_range() had no such loop.

The problem is is easily demonstrated with a small bit of test code:

  static int usleep_test_task(void *data)
  {
    atomic_t *done = data;
    ktime_t start, end;

    start = ktime_get();
    usleep_range(50000, 100000);
    end = ktime_get();
    pr_info("Requested 50000 - 100000 us.  Actually slept for %llu us\n",
      (unsigned long long)ktime_to_us(ktime_sub(end, start)));
    atomic_set(done, 1);

    return 0;
  }

  static void run_usleep_test(void)
  {
    struct task_struct *t;
    atomic_t done;

    atomic_set(&done, 0);

    t = kthread_run(usleep_test_task, &done, "usleep_test_task");
    while (!atomic_read(&done)) {
      wake_up_process(t);
      udelay(1000);
    }
    kthread_stop(t);
  }

If you run the above code without this patch you get things like:
  Requested 50000 - 100000 us.  Actually slept for 967 us

If you run the above code _with_ this patch, you get:
  Requested 50000 - 100000 us.  Actually slept for 98896 us

Presumably this problem was not detected before because:
- It's not terribly common to use wake_up_process() directly.
- Other ways for processes to wake up are not typically mixed with
  usleep_range().
- There aren't lots of places that use usleep_range(), since many people
  call either msleep() or udelay().

NOTES:
- An effort was made to look for users relying on the old behavior by
  looking for usleep_range() in the same file as wake_up_process().
  No problems was found by this search, though it is conceivable that
  someone could have put the sleep and wakeup in two different files.
- An effort was made to ask several upstream maintainers if they were
  aware of people relying on wake_up_process() to wake up
  usleep_range().  No maintainers were aware of that but they were aware
  of many people relying on usleep_range() never returning before the
  minimum.

Reported-by: Tao Huang <huangtao at rock-chips.com>
Signed-off-by: Douglas Anderson <dianders at chromium.org>
---
Changes in v5:
- Don't accidentally busy wait after first wakeup (Thomas Gleixner)
- Removed Reviewed-by tags

Changes in v4: None
Changes in v3:
- Add Reviewed-by tags
- Add notes about validation

Changes in v2:
- Fixed stupid bug that snuck in before posting
- Use ktime_before
- Remove delta from the loop

 kernel/time/timer.c | 22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 32bf6f75a8fe..ab65e7bcc2c2 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1896,16 +1896,6 @@ unsigned long msleep_interruptible(unsigned int msecs)
 
 EXPORT_SYMBOL(msleep_interruptible);
 
-static void __sched do_usleep_range(unsigned long min, unsigned long max)
-{
-	ktime_t kmin;
-	u64 delta;
-
-	kmin = ktime_set(0, min * NSEC_PER_USEC);
-	delta = (u64)(max - min) * NSEC_PER_USEC;
-	schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
-}
-
 /**
  * usleep_range - Sleep for an approximate time
  * @min: Minimum time in usecs to sleep
@@ -1919,7 +1909,15 @@ static void __sched do_usleep_range(unsigned long min, unsigned long max)
  */
 void __sched usleep_range(unsigned long min, unsigned long max)
 {
-	__set_current_state(TASK_UNINTERRUPTIBLE);
-	do_usleep_range(min, max);
+	ktime_t expires = ktime_add_us(ktime_get(), min);
+	u64 delta = (u64)(max - min) * NSEC_PER_USEC;
+
+	for (;;) {
+		__set_current_state(TASK_UNINTERRUPTIBLE);
+		/* Do not return before the requested sleep time has elapsed */
+		if (!schedule_hrtimeout_range(&expires, delta,
+					      HRTIMER_MODE_ABS))
+			break;
+	}
 }
 EXPORT_SYMBOL(usleep_range);
-- 
2.8.0.rc3.226.g39d4020



From dianders at chromium.org  Fri Oct 21 08:58:51 2016
From: dianders at chromium.org (Douglas Anderson)
Date: Fri, 21 Oct 2016 08:58:51 -0700
Subject: [PATCH v5 2/2] timers: Fix documentation for schedule_timeout() and
 similar
In-Reply-To: <1477065531-30342-1-git-send-email-dianders@chromium.org>
References: <1477065531-30342-1-git-send-email-dianders@chromium.org>
Message-ID: <1477065531-30342-2-git-send-email-dianders@chromium.org>

The documentatoin for schedule_timeout(), schedule_hrtimeout(), and
schedule_hrtimeout_range() all claimed that the routines couldn't
possibly return early if the task state was TASK_UNINTERRUPTIBLE.  This
was simply not true since anyone calling wake_up_process() would cause
those routines to exit early.

As some evidence that the documentation was broken (not the code):
- If we changed the code to match the documentation, msleep() would be
  identical to schedule_timeout_uninterruptible() and
  msleep_interruptible() would be identical to
  schedule_timeout_interruptible().  That doesn't seem likely to have
  been the intention.
- The schedule() function sleeps until a task is woken up.  Logically,
  one would expect that the schedule_timeout() function would sleep
  until a task is woken up or a timeout occurrs.

As part of the above observation, it can be seen that
schedule_hrtimeout() and schedule_hrtimeout_range() might return -EINTR
even if the task state was TASK_UNINTERRUPTIBLE.  This isn't terrible
behavior so we'll document it and keep it as-is.  After all, trying to
match schedule_timeout() and return the time left would incure a bunch
of extra calculation cost that isn't needed in all cases.

Suggested-by: Daniel Kurtz <djkurtz at chromium.org>
Signed-off-by: Douglas Anderson <dianders at chromium.org>
---
Changes in v5: None
Changes in v4:
- Fixed stray double quotes.
- Updated wording as per Thomas Gleixner.

Changes in v3:
- Documentation fix new for v3.

 kernel/time/hrtimer.c | 20 ++++++++++++++------
 kernel/time/timer.c   | 11 +++++++----
 2 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index bb5ec425dfe0..08be5c99d26b 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1742,15 +1742,19 @@ schedule_hrtimeout_range_clock(ktime_t *expires, u64 delta,
  * You can set the task state as follows -
  *
  * %TASK_UNINTERRUPTIBLE - at least @timeout time is guaranteed to
- * pass before the routine returns.
+ * pass before the routine returns unless the current task is explicitly
+ * woken up, (e.g. by wake_up_process()).
  *
  * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
- * delivered to the current task.
+ * delivered to the current task or the current task is explicitly woken
+ * up.
  *
  * The current task state is guaranteed to be TASK_RUNNING when this
  * routine returns.
  *
- * Returns 0 when the timer has expired otherwise -EINTR
+ * Returns 0 when the timer has expired. If the task was woken before the
+ * timer expired by a signal (only possible in state TASK_INTERRUPTIBLE) or
+ * by an explicit wakeup, it returns -EINTR.
  */
 int __sched schedule_hrtimeout_range(ktime_t *expires, u64 delta,
 				     const enum hrtimer_mode mode)
@@ -1772,15 +1776,19 @@ EXPORT_SYMBOL_GPL(schedule_hrtimeout_range);
  * You can set the task state as follows -
  *
  * %TASK_UNINTERRUPTIBLE - at least @timeout time is guaranteed to
- * pass before the routine returns.
+ * pass before the routine returns unless the current task is explicitly
+ * woken up, (e.g. by wake_up_process()).
  *
  * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
- * delivered to the current task.
+ * delivered to the current task or the current task is explicitly woken
+ * up.
  *
  * The current task state is guaranteed to be TASK_RUNNING when this
  * routine returns.
  *
- * Returns 0 when the timer has expired otherwise -EINTR
+ * Returns 0 when the timer has expired. If the task was woken before the
+ * timer expired by a signal (only possible in state TASK_INTERRUPTIBLE) or
+ * by an explicit wakeup, it returns -EINTR.
  */
 int __sched schedule_hrtimeout(ktime_t *expires,
 			       const enum hrtimer_mode mode)
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index ab65e7bcc2c2..330214a19beb 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1691,11 +1691,12 @@ static void process_timeout(unsigned long __data)
  * You can set the task state as follows -
  *
  * %TASK_UNINTERRUPTIBLE - at least @timeout jiffies are guaranteed to
- * pass before the routine returns. The routine will return 0
+ * pass before the routine returns unless the current task is explicitly
+ * woken up, (e.g. by wake_up_process())".
  *
  * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
- * delivered to the current task. In this case the remaining time
- * in jiffies will be returned, or 0 if the timer expired in time
+ * delivered to the current task or the current task is explicitly woken
+ * up.
  *
  * The current task state is guaranteed to be TASK_RUNNING when this
  * routine returns.
@@ -1704,7 +1705,9 @@ static void process_timeout(unsigned long __data)
  * the CPU away without a bound on the timeout. In this case the return
  * value will be %MAX_SCHEDULE_TIMEOUT.
  *
- * In all cases the return value is guaranteed to be non-negative.
+ * Returns 0 when the timer has expired otherwise the remaining time in
+ * jiffies will be returned.  In all cases the return value is guaranteed
+ * to be non-negative.
  */
 signed long __sched schedule_timeout(signed long timeout)
 {
-- 
2.8.0.rc3.226.g39d4020



From heiko at sntech.de  Fri Oct 21 09:18:10 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 21 Oct 2016 18:18:10 +0200
Subject: [PATCH v3 0/2] Add MK808 RK3066 device
In-Reply-To: <cover.1475957884.git.paweljarosz3691@gmail.com>
References: <cover.1475957884.git.paweljarosz3691@gmail.com>
Message-ID: <1671843.4nkAJvukGm@phil>

Am Samstag, 8. Oktober 2016, 22:21:47 CEST schrieb Pawe? Jarosz:
> Add MK808 RK3066 device
> 
> This patchset adds support for Rikomagic MK808 v1 device with RK901 wifi.
> 
> It is hdmi stick with two usb ports(host and otg), sdmmc, wifi and uart
> onboard.
> 
> It is RK3066 based.
> 
> Pawe? Jarosz (2):
>   devicetree: Add vendor prefix for Rikomagic
>   ARM: dts: rockchip: Add rk3066 MK808 board

applied both patches with received tags for 4.10.

If you have time could try to do a followup patch, adding (and testing) the 
usbphy supplies please?

Should be like

&usbphy0 {
	phy-supply = <&vcc_otg>;
};

&usbphy1 {
	phy-supply = <&vcc_host>;
};

That way we can drop the regulator-always-on property from those two supplies.


Thanks
Heiko


From heiko at sntech.de  Fri Oct 21 14:32:57 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 21 Oct 2016 23:32:57 +0200
Subject: [PATCH v1 1/2] include: dt-bindings: Add GPIO pin index
 definition for rockchip pinctrl
In-Reply-To: <13068948.jkWM1OvpR7@phil>
References: <1473210053-23743-1-git-send-email-andy.yan@rock-chips.com>
 <13068948.jkWM1OvpR7@phil>
Message-ID: <1517801.GjkO3No2Gs@phil>

Am Mittwoch, 12. Oktober 2016, 00:00:12 CEST schrieb Heiko Stuebner:
> Am Mittwoch, 7. September 2016, 09:00:53 CEST schrieb Andy Yan:
> > Add gpio pin index definition to make it easier to describe
> > GPIO in dts.
> > 
> > Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
> 
> just as a heads up, as I didn't respond yet:
> 
> Looks good and I'll take them, I just want to wait for the merge-window to
> close (should be the coming sunday), to be able to put the header change in
> a shared branch for the case that other users appear during the 4.10 cycle.

I've now applied both patches for 4.10


Thanks
Heiko


From ayaka at soulik.info  Fri Oct 21 20:52:45 2016
From: ayaka at soulik.info (ayaka)
Date: Sat, 22 Oct 2016 11:52:45 +0800
Subject: [PATCH] ARM: dts: rockchip: add i2c-bus subnode to edp
In-Reply-To: <1681294.eoXpQL8f8l@phil>
References: <1476950845-28242-1-git-send-email-tomeu.vizoso@collabora.com>
 <7604646.6yosK0XMNL@diego>
 <6083453f-08e1-643a-9638-1db38c704aa5@collabora.com>
 <1681294.eoXpQL8f8l@phil>
Message-ID: <1026cfe7-836f-7e78-af71-54c858b6a95e@soulik.info>


On 10/21/2016 04:25 PM, Heiko Stuebner wrote:
> Am Donnerstag, 20. Oktober 2016, 15:47:56 CEST schrieb Tomeu Vizoso:
>> On 10/20/2016 03:45 PM, Heiko St?bner wrote:
>>> Am Donnerstag, 20. Oktober 2016, 10:07:25 schrieb Tomeu Vizoso:
>>>> Add an empty 'i2c-bus' subnode to the edp node just so that the I2C core
>>>> doesn't attemp to parse the 'ports' subnode as containing i2c devices.
>>>>
>>>> This is to avoid spurious failure messages such as:
>>>>
>>>> i2c i2c-6: of_i2c: modalias failure on /dp at ff970000/ports
>>> On the one hand, the edp really has an i2c bus - with its only client the
>>> EDID listening at 0x50 (and maybe 0x30).
>>>
>>> On the other hand, adding an empty bus to the (implementation independent)
>>> devicetree just to make the Linux i2c subsystem happy sounds heavily like
>>> a
>>> implementation-specific hack, as the edp i2c bus doesn't leak into the
>>> outside world otherwise.
>>>
>>> I guess this empty i2c bus not being part of the binding document points
>>> heavily into the implementation-specific corner :-) .
>>>
>>> My short search on other patches touching this didn't reveal anything but
>>> maybe this was already discussed somewhere and found to be ok?
>> Here it is:
>>
>> http://www.spinics.net/lists/linux-tegra/msg27862.html
> thanks ... I'm still not sure about the placeholder though, aka needing an
> undocumented subnode to make a Linux error message silent.
Sorry, I report the error result, it would work.

And about the problem at this thread beginning, I found I have to use 
something like Xserver to access DRM or the panel would not be power on. 
The legacy fbdev won't help.
But there is still problem to be solved, so the eDP panel for firefly is 
not ready yet.
>
> In the thread you pointed to I also did not see any dt-maintainer involvement
> pointing one way or another, but spinics is often not easy to navigate
> threads, so I may have missed that.
>
>
>>> Another option could be to just make of_i2c_register_device silent if
>>> of_modalias_node returns -ENODEV?
>
> Heiko
>
>>>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>
>>>> Cc: Randy Li <randy.li at rock-chips.com>
>>>> Cc: Jon Hunter <jonathanh at nvidia.com>
>>>> ---
>>>>
>>>>   arch/arm/boot/dts/rk3288.dtsi | 5 +++++
>>>>   1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/rk3288.dtsi
>>>> b/arch/arm/boot/dts/rk3288.dtsi
>>>> index 2f814ffeb605..94f4b7eecca2 100644
>>>> --- a/arch/arm/boot/dts/rk3288.dtsi
>>>> +++ b/arch/arm/boot/dts/rk3288.dtsi
>>>> @@ -1075,6 +1075,11 @@
>>>>
>>>>   				};
>>>>   			
>>>>   			};
>>>>   		
>>>>   		};
>>>>
>>>> +
>>>> +		i2c-bus {
>>>> +			#address-cells = <1>;
>>>> +			#size-cells = <0>;
>>>> +		};
>>>>
>>>>   	};
>>>>   	
>>>>   	hdmi: hdmi at ff980000 {
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>



From david.wu at rock-chips.com  Sat Oct 22 01:43:42 2016
From: david.wu at rock-chips.com (David Wu)
Date: Sat, 22 Oct 2016 16:43:42 +0800
Subject: [PATCH] i2c: rk3x: Give the tuning value 0 during
 rk3x_i2c_v0_calc_timings
Message-ID: <1477125822-30644-1-git-send-email-david.wu@rock-chips.com>

We found a bug that i2c transfer sometimes failed on 3066a board with
stabel-4.8, the con register would be updated by uninitialized tuning
value, it made the i2c transfer failed.

So give the tuning value to be zero during rk3x_i2c_v0_calc_timings.

Signed-off-by: David Wu <david.wu at rock-chips.com>
---
 drivers/i2c/busses/i2c-rk3x.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 50702c7..df22066 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -694,6 +694,8 @@ static int rk3x_i2c_v0_calc_timings(unsigned long clk_rate,
 	t_calc->div_low--;
 	t_calc->div_high--;
 
+	/* Give the tuning value 0, that would not update con register */
+	t_calc->tuning = 0;
 	/* Maximum divider supported by hw is 0xffff */
 	if (t_calc->div_low > 0xffff) {
 		t_calc->div_low = 0xffff;
-- 
1.9.1




From andy.yan at rock-chips.com  Sat Oct 22 05:51:46 2016
From: andy.yan at rock-chips.com (Andy Yan)
Date: Sat, 22 Oct 2016 20:51:46 +0800
Subject: [PATCH 0/2] Use macros to describe gpios on rockchip platform
Message-ID: <1477140706-6886-1-git-send-email-andy.yan@rock-chips.com>


As patch 150696e2e3a4("Add GPIO pin index definition for rockchip pinctrl") has
been applied, now we can use these macros to describe the corresponding gpio
ranther than hard code numbers, this will make the dts easier to read and
write.

Some ideas from Krzysztof's patch on EXYNOS[0].

[0]https://lkml.org/lkml/2016/9/4/71



Andy Yan (2):
  ARM: dts: rockchip: use pin constants to describe gpios
  ARM64: dts: rockchip: use pin constants to describe gpios

 arch/arm/boot/dts/rk3036-evb.dts                   |  2 +-
 arch/arm/boot/dts/rk3036-kylin.dts                 | 10 ++++-----
 arch/arm/boot/dts/rk3066a-bqcurie2.dts             |  6 +++---
 arch/arm/boot/dts/rk3066a-marsboard.dts            |  2 +-
 arch/arm/boot/dts/rk3066a-mk808.dts                | 10 ++++-----
 arch/arm/boot/dts/rk3066a-rayeager.dts             | 12 +++++------
 arch/arm/boot/dts/rk3188-px3-evb.dts               |  4 ++--
 arch/arm/boot/dts/rk3188-radxarock.dts             | 16 +++++++--------
 arch/arm/boot/dts/rk3229-evb.dts                   |  2 +-
 arch/arm/boot/dts/rk3288-evb-act8846.dts           |  4 ++--
 arch/arm/boot/dts/rk3288-evb.dtsi                  | 14 ++++++-------
 arch/arm/boot/dts/rk3288-fennec.dts                |  4 ++--
 arch/arm/boot/dts/rk3288-firefly-beta.dts          |  2 +-
 arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi  |  2 +-
 arch/arm/boot/dts/rk3288-firefly-reload.dts        | 24 +++++++++++-----------
 arch/arm/boot/dts/rk3288-firefly.dts               |  2 +-
 arch/arm/boot/dts/rk3288-firefly.dtsi              | 16 +++++++--------
 arch/arm/boot/dts/rk3288-miqi.dts                  |  8 ++++----
 arch/arm/boot/dts/rk3288-popmetal.dts              |  2 +-
 arch/arm/boot/dts/rk3288-r89.dts                   | 12 +++++------
 arch/arm/boot/dts/rk3288-rock2-som.dtsi            |  4 ++--
 arch/arm/boot/dts/rk3288-rock2-square.dts          | 12 +++++------
 arch/arm/boot/dts/rk3288-veyron-analog-audio.dtsi  |  4 ++--
 arch/arm/boot/dts/rk3288-veyron-brain.dts          |  8 ++++----
 arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi    | 10 ++++-----
 arch/arm/boot/dts/rk3288-veyron-jaq.dts            | 14 ++++++-------
 arch/arm/boot/dts/rk3288-veyron-jerry.dts          | 10 ++++-----
 arch/arm/boot/dts/rk3288-veyron-mickey.dts         |  6 +++---
 arch/arm/boot/dts/rk3288-veyron-minnie.dts         | 16 +++++++--------
 arch/arm/boot/dts/rk3288-veyron-pinky.dts          |  4 ++--
 arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi         |  2 +-
 arch/arm/boot/dts/rk3288-veyron-speedy.dts         | 10 ++++-----
 arch/arm/boot/dts/rk3288-veyron.dtsi               |  8 ++++----
 arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi       | 10 ++++-----
 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts    |  8 ++++----
 .../boot/dts/rockchip/rk3368-orion-r68-meta.dts    | 14 ++++++-------
 arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts    |  4 ++--
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts        | 16 +++++++--------
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts        |  6 +++---
 39 files changed, 160 insertions(+), 160 deletions(-)

-- 
2.7.4




From andy.yan at rock-chips.com  Sat Oct 22 05:54:55 2016
From: andy.yan at rock-chips.com (Andy Yan)
Date: Sat, 22 Oct 2016 20:54:55 +0800
Subject: [PATCH 1/2] ARM: dts: rockchip: use pin constants to describe gpios
In-Reply-To: <1477140706-6886-1-git-send-email-andy.yan@rock-chips.com>
References: <1477140706-6886-1-git-send-email-andy.yan@rock-chips.com>
Message-ID: <1477140895-6938-1-git-send-email-andy.yan@rock-chips.com>

Use macros to describe gpios will make the dts easier to
read and write.

All the modifications done with sed:

sed -i -e 's/ 0  GPIO_ACTIVE_/ RK_PA0 GPIO_ACTIVE_/' arch/arm/boot/dts/rk*
sed -i -e 's/ 1  GPIO_ACTIVE_/ RK_PA1 GPIO_ACTIVE_/' arch/arm/boot/dts/rk*
sed -i -e 's/ 2  GPIO_ACTIVE_/ RK_PA2 GPIO_ACTIVE_/' arch/arm/boot/dts/rk*
.......
.......
sed -i -e 's/ 30 GPIO_ACTIVE_/ RK_PD6 GPIO_ACTIVE_/' arch/arm/boot/dts/rk*
sed -i -e 's/ 31 GPIO_ACTIVE_/ RK_PD7 GPIO_ACTIVE_/' arch/arm/boot/dts/rk*

Tested with:

for i in dts-old/*dtb; do scripts/dtc/dtx_diff $i dts-new/$(basename $i);  done

Signed-off-by: Andy Yan <andy.yan at rock-chips.com>

---

 arch/arm/boot/dts/rk3036-evb.dts                  |  2 +-
 arch/arm/boot/dts/rk3036-kylin.dts                | 10 +++++-----
 arch/arm/boot/dts/rk3066a-bqcurie2.dts            |  6 +++---
 arch/arm/boot/dts/rk3066a-marsboard.dts           |  2 +-
 arch/arm/boot/dts/rk3066a-mk808.dts               | 10 +++++-----
 arch/arm/boot/dts/rk3066a-rayeager.dts            | 12 ++++++------
 arch/arm/boot/dts/rk3188-px3-evb.dts              |  4 ++--
 arch/arm/boot/dts/rk3188-radxarock.dts            | 16 +++++++--------
 arch/arm/boot/dts/rk3229-evb.dts                  |  2 +-
 arch/arm/boot/dts/rk3288-evb-act8846.dts          |  4 ++--
 arch/arm/boot/dts/rk3288-evb.dtsi                 | 14 ++++++-------
 arch/arm/boot/dts/rk3288-fennec.dts               |  4 ++--
 arch/arm/boot/dts/rk3288-firefly-beta.dts         |  2 +-
 arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi |  2 +-
 arch/arm/boot/dts/rk3288-firefly-reload.dts       | 24 +++++++++++------------
 arch/arm/boot/dts/rk3288-firefly.dts              |  2 +-
 arch/arm/boot/dts/rk3288-firefly.dtsi             | 16 +++++++--------
 arch/arm/boot/dts/rk3288-miqi.dts                 |  8 ++++----
 arch/arm/boot/dts/rk3288-popmetal.dts             |  2 +-
 arch/arm/boot/dts/rk3288-r89.dts                  | 12 ++++++------
 arch/arm/boot/dts/rk3288-rock2-som.dtsi           |  4 ++--
 arch/arm/boot/dts/rk3288-rock2-square.dts         | 12 ++++++------
 arch/arm/boot/dts/rk3288-veyron-analog-audio.dtsi |  4 ++--
 arch/arm/boot/dts/rk3288-veyron-brain.dts         |  8 ++++----
 arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi   | 10 +++++-----
 arch/arm/boot/dts/rk3288-veyron-jaq.dts           | 14 ++++++-------
 arch/arm/boot/dts/rk3288-veyron-jerry.dts         | 10 +++++-----
 arch/arm/boot/dts/rk3288-veyron-mickey.dts        |  6 +++---
 arch/arm/boot/dts/rk3288-veyron-minnie.dts        | 16 +++++++--------
 arch/arm/boot/dts/rk3288-veyron-pinky.dts         |  4 ++--
 arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi        |  2 +-
 arch/arm/boot/dts/rk3288-veyron-speedy.dts        | 10 +++++-----
 arch/arm/boot/dts/rk3288-veyron.dtsi              |  8 ++++----
 33 files changed, 131 insertions(+), 131 deletions(-)

diff --git a/arch/arm/boot/dts/rk3036-evb.dts b/arch/arm/boot/dts/rk3036-evb.dts
index 2f5f155..c095341 100644
--- a/arch/arm/boot/dts/rk3036-evb.dts
+++ b/arch/arm/boot/dts/rk3036-evb.dts
@@ -56,7 +56,7 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&emac_xfer>, <&emac_mdio>;
 	phy = <&phy0>;
-	phy-reset-gpios = <&gpio2 22 GPIO_ACTIVE_LOW>; /* PHY_RST */
+	phy-reset-gpios = <&gpio2 RK_PC6 GPIO_ACTIVE_LOW>; /* PHY_RST */
 	phy-reset-duration = <10>; /* millisecond */
 
 	status = "okay";
diff --git a/arch/arm/boot/dts/rk3036-kylin.dts b/arch/arm/boot/dts/rk3036-kylin.dts
index 3de958e..2518259 100644
--- a/arch/arm/boot/dts/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rk3036-kylin.dts
@@ -55,7 +55,7 @@
 		compatible = "gpio-leds";
 
 		work {
-			gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;
+			gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
 			label = "kylin:red:led";
 			pinctrl-names = "default";
 			pinctrl-0 = <&led_ctl>;
@@ -74,9 +74,9 @@
 		 * - SDIO_RESET_L_WL_RST
 		 * - SDIO_RESET_L_BT_EN
 		 */
-		reset-gpios = <&gpio0 26 GPIO_ACTIVE_LOW>, /* WL_REG_ON */
-			      <&gpio0 27 GPIO_ACTIVE_LOW>, /* WL_RST */
-			      <&gpio2 9  GPIO_ACTIVE_LOW>; /* BT_EN */
+		reset-gpios = <&gpio0 RK_PD2 GPIO_ACTIVE_LOW>, /* WL_REG_ON */
+			      <&gpio0 RK_PD3 GPIO_ACTIVE_LOW>, /* WL_RST */
+			      <&gpio2 RK_PB1 GPIO_ACTIVE_LOW>; /* BT_EN */
 	};
 
 	sound {
@@ -121,7 +121,7 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&emac_xfer>, <&emac_mdio>;
 	phy = <&phy0>;
-	phy-reset-gpios = <&gpio2 22 GPIO_ACTIVE_LOW>; /* PHY_RST */
+	phy-reset-gpios = <&gpio2 RK_PC6 GPIO_ACTIVE_LOW>; /* PHY_RST */
 	phy-reset-duration = <10>; /* millisecond */
 
 	status = "okay";
diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
index c0d8b54..9e852c6 100644
--- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
+++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
@@ -71,7 +71,7 @@
 		regulator-name = "sdmmc-supply";
 		regulator-min-microvolt = <3000000>;
 		regulator-max-microvolt = <3000000>;
-		gpio = <&gpio3 7 GPIO_ACTIVE_LOW>;
+		gpio = <&gpio3 RK_PA7 GPIO_ACTIVE_LOW>;
 		startup-delay-us = <100000>;
 		vin-supply = <&vcc_io>;
 	};
@@ -81,7 +81,7 @@
 		autorepeat;
 
 		power {
-			gpios = <&gpio6 2 GPIO_ACTIVE_LOW>; /* GPIO6_A2 */
+			gpios = <&gpio6 RK_PA2 GPIO_ACTIVE_LOW>; /* GPIO6_A2 */
 			linux,code = <KEY_POWER>;
 			label = "GPIO Key Power";
 			linux,input-type = <1>;
@@ -89,7 +89,7 @@
 			debounce-interval = <100>;
 		};
 		volume-down {
-			gpios = <&gpio4 21 GPIO_ACTIVE_LOW>; /* GPIO4_C5 */
+			gpios = <&gpio4 RK_PC5 GPIO_ACTIVE_LOW>; /* GPIO4_C5 */
 			linux,code = <KEY_VOLUMEDOWN>;
 			label = "GPIO Key Vol-";
 			linux,input-type = <1>;
diff --git a/arch/arm/boot/dts/rk3066a-marsboard.dts b/arch/arm/boot/dts/rk3066a-marsboard.dts
index 0a54c4b..cdf0a88 100644
--- a/arch/arm/boot/dts/rk3066a-marsboard.dts
+++ b/arch/arm/boot/dts/rk3066a-marsboard.dts
@@ -69,7 +69,7 @@
 		regulator-name = "sdmmc-supply";
 		regulator-min-microvolt = <3000000>;
 		regulator-max-microvolt = <3000000>;
-		gpio = <&gpio3 7 GPIO_ACTIVE_LOW>;
+		gpio = <&gpio3 RK_PA7 GPIO_ACTIVE_LOW>;
 		startup-delay-us = <100000>;
 		vin-supply = <&vcc_io>;
 	};
diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts b/arch/arm/boot/dts/rk3066a-mk808.dts
index 658eb7d..7ca1cf5 100644
--- a/arch/arm/boot/dts/rk3066a-mk808.dts
+++ b/arch/arm/boot/dts/rk3066a-mk808.dts
@@ -61,7 +61,7 @@
 
 		blue {
 			label = "mk808:blue:power";
-			gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
+			gpios = <&gpio0 RK_PA3 GPIO_ACTIVE_HIGH>;
 			default-state = "off";
 			linux,default-trigger = "default-on";
 		};
@@ -77,7 +77,7 @@
 	vcc_host: usb-host-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 6 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
 		pinctrl-0 = <&host_drv>;
 		pinctrl-names = "default";
 		regulator-always-on;
@@ -91,7 +91,7 @@
 	vcc_otg: usb-otg-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 5 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
 		pinctrl-0 = <&otg_drv>;
 		pinctrl-names = "default";
 		regulator-always-on;
@@ -104,7 +104,7 @@
 
 	vcc_sd: sdmmc-regulator {
 		compatible = "regulator-fixed";
-		gpio = <&gpio3 7 GPIO_ACTIVE_LOW>;
+		gpio = <&gpio3 RK_PA7 GPIO_ACTIVE_LOW>;
 		pinctrl-0 = <&sdmmc_pwr>;
 		pinctrl-names = "default";
 		regulator-name = "vcc_sd";
@@ -117,7 +117,7 @@
 	vcc_wifi: sdio-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio3 24 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio3 RK_PD0 GPIO_ACTIVE_HIGH>;
 		pinctrl-0 = <&wifi_pwr>;
 		pinctrl-names = "default";
 		regulator-name = "vcc_wifi";
diff --git a/arch/arm/boot/dts/rk3066a-rayeager.dts b/arch/arm/boot/dts/rk3066a-rayeager.dts
index 82465b6..7c05e8b 100644
--- a/arch/arm/boot/dts/rk3066a-rayeager.dts
+++ b/arch/arm/boot/dts/rk3066a-rayeager.dts
@@ -55,7 +55,7 @@
 
 	ir: ir-receiver {
 		compatible = "gpio-ir-receiver";
-		gpios = <&gpio6 1 GPIO_ACTIVE_LOW>;
+		gpios = <&gpio6 RK_PA1 GPIO_ACTIVE_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&ir_int>;
 	};
@@ -65,7 +65,7 @@
 
 		power {
 			wakeup-source;
-			gpios = <&gpio6 2 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio6 RK_PA2 GPIO_ACTIVE_LOW>;
 			label = "GPIO Power";
 			linux,code = <KEY_POWER>;
 			pinctrl-names = "default";
@@ -115,7 +115,7 @@
 	vcc_sata: sata-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio4 22 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&sata_pwr>;
 		regulator-name = "usb_5v";
@@ -127,7 +127,7 @@
 
 	vcc_sd: sdmmc-regulator {
 		compatible = "regulator-fixed";
-		gpio = <&gpio3 7 GPIO_ACTIVE_LOW>;
+		gpio = <&gpio3 RK_PA7 GPIO_ACTIVE_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&sdmmc_pwr>;
 		regulator-name = "vcc_sd";
@@ -140,7 +140,7 @@
 	vcc_host: usb-host-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 6 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&host_drv>;
 		regulator-name = "host-pwr";
@@ -153,7 +153,7 @@
 	vcc_otg: usb-otg-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 5 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&otg_drv>;
 		regulator-name = "vcc_otg";
diff --git a/arch/arm/boot/dts/rk3188-px3-evb.dts b/arch/arm/boot/dts/rk3188-px3-evb.dts
index df727ba..4afd9d8 100644
--- a/arch/arm/boot/dts/rk3188-px3-evb.dts
+++ b/arch/arm/boot/dts/rk3188-px3-evb.dts
@@ -62,7 +62,7 @@
 		autorepeat;
 
 		power {
-			gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
 			label = "GPIO Key Power";
 			linux,input-type = <1>;
@@ -248,7 +248,7 @@
 		reg = <0x40>;
 		interrupt-parent = <&gpio1>;
 		interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
-		power-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+		power-gpios = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>;
 		touchscreen-size-x = <800>;
 		touchscreen-size-y = <1280>;
 		silead,max-fingers = <5>;
diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts b/arch/arm/boot/dts/rk3188-radxarock.dts
index 5e8a235..28a2931 100644
--- a/arch/arm/boot/dts/rk3188-radxarock.dts
+++ b/arch/arm/boot/dts/rk3188-radxarock.dts
@@ -58,7 +58,7 @@
 		autorepeat;
 
 		power {
-			gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
 			label = "GPIO Key Power";
 			linux,input-type = <1>;
@@ -72,19 +72,19 @@
 
 		green {
 			label = "rock:green:user1";
-			gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio0 RK_PB4 GPIO_ACTIVE_LOW>;
 			default-state = "off";
 		};
 
 		blue {
 			label = "rock:blue:user2";
-			gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio0 RK_PB6 GPIO_ACTIVE_LOW>;
 			default-state = "off";
 		};
 
 		sleep {
 			label = "rock:red:power";
-			gpios = <&gpio0 15 0>;
+			gpios = <&gpio0 RK_PB7 GPIO_ACTIVE_HIGH>;
 			default-state = "off";
 		};
 	};
@@ -106,7 +106,7 @@
 
 	ir_recv: gpio-ir-receiver {
 		compatible = "gpio-ir-receiver";
-		gpios = <&gpio0 10 1>;
+		gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&ir_recv_pin>;
 	};
@@ -114,7 +114,7 @@
 	vcc_otg: usb-otg-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio2 31 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio2 RK_PD7 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&otg_vbus_drv>;
 		regulator-name = "otg-vbus";
@@ -129,7 +129,7 @@
 		regulator-name = "sdmmc-supply";
 		regulator-min-microvolt = <3300000>;
 		regulator-max-microvolt = <3300000>;
-		gpio = <&gpio3 1 GPIO_ACTIVE_LOW>;
+		gpio = <&gpio3 RK_PA1 GPIO_ACTIVE_LOW>;
 		startup-delay-us = <100000>;
 		vin-supply = <&vcc_io>;
 	};
@@ -137,7 +137,7 @@
 	vcc_host: usb-host-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 3 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PA3 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&host_vbus_drv>;
 		regulator-name = "host-pwr";
diff --git a/arch/arm/boot/dts/rk3229-evb.dts b/arch/arm/boot/dts/rk3229-evb.dts
index dcdd0ce..275092a 100644
--- a/arch/arm/boot/dts/rk3229-evb.dts
+++ b/arch/arm/boot/dts/rk3229-evb.dts
@@ -77,7 +77,7 @@
 	phy-mode = "rgmii";
 	pinctrl-names = "default";
 	pinctrl-0 = <&rgmii_pins>;
-	snps,reset-gpio = <&gpio2 24 GPIO_ACTIVE_LOW>;
+	snps,reset-gpio = <&gpio2 RK_PD0 GPIO_ACTIVE_LOW>;
 	snps,reset-active-low;
 	snps,reset-delays-us = <0 10000 1000000>;
 	tx_delay = <0x30>;
diff --git a/arch/arm/boot/dts/rk3288-evb-act8846.dts b/arch/arm/boot/dts/rk3288-evb-act8846.dts
index 041dd5d..f4f29fe 100644
--- a/arch/arm/boot/dts/rk3288-evb-act8846.dts
+++ b/arch/arm/boot/dts/rk3288-evb-act8846.dts
@@ -47,7 +47,7 @@
 	vcc_lcd: vcc-lcd {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio7 3 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio7 RK_PA3 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&lcd_en>;
 		regulator-name = "vcc_lcd";
@@ -57,7 +57,7 @@
 	vcc_wl: vcc-wl {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio7 9 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio7 RK_PB1 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&wifi_pwr>;
 		regulator-name = "vcc_wl";
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi b/arch/arm/boot/dts/rk3288-evb.dtsi
index bf7ccfa..0dec94c 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -84,7 +84,7 @@
 			240 241 242 243 244 245 246 247
 			248 249 250 251 252 253 254 255>;
 		default-brightness-level = <128>;
-		enable-gpios = <&gpio7 2 GPIO_ACTIVE_HIGH>;
+		enable-gpios = <&gpio7 RK_PA2 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&bl_en>;
 		pwms = <&pwm0 0 1000000 PWM_POLARITY_INVERTED>;
@@ -100,7 +100,7 @@
 	panel: panel {
 		compatible ="lg,lp079qx1-sp0v", "simple-panel";
 		backlight = <&backlight>;
-		enable-gpios = <&gpio7 4 GPIO_ACTIVE_HIGH>;
+		enable-gpios = <&gpio7 RK_PA4 GPIO_ACTIVE_HIGH>;
 		pinctrl-0 = <&lcd_cs>;
 
 		ports {
@@ -120,7 +120,7 @@
 		pinctrl-0 = <&pwrbtn>;
 
 		power {
-			gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
 			label = "GPIO Key Power";
 			linux,input-type = <1>;
@@ -133,7 +133,7 @@
 	vcc_host: vcc-host-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&host_vbus_drv>;
 		regulator-name = "vcc_host";
@@ -144,7 +144,7 @@
 	vcc_phy: vcc-phy-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 6 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&eth_phy_pwr>;
 		regulator-name = "vcc_phy";
@@ -170,7 +170,7 @@
 	 */
 	vcc_sd: sdmmc-regulator {
 		compatible = "regulator-fixed";
-		gpio = <&gpio7 11 GPIO_ACTIVE_LOW>;
+		gpio = <&gpio7 RK_PB3 GPIO_ACTIVE_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&sdmmc_pwr>;
 		regulator-name = "vcc_sd";
@@ -236,7 +236,7 @@
 	phy-supply = <&vcc_phy>;
 	phy-mode = "rgmii";
 	clock_in_out = "input";
-	snps,reset-gpio = <&gpio4 7 0>;
+	snps,reset-gpio = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
 	snps,reset-active-low;
 	snps,reset-delays-us = <0 10000 1000000>;
 	assigned-clocks = <&cru SCLK_MAC>;
diff --git a/arch/arm/boot/dts/rk3288-fennec.dts b/arch/arm/boot/dts/rk3288-fennec.dts
index 805c0d2..dc00f12 100644
--- a/arch/arm/boot/dts/rk3288-fennec.dts
+++ b/arch/arm/boot/dts/rk3288-fennec.dts
@@ -93,7 +93,7 @@
 	phy-mode = "rgmii";
 	snps,reset-active-low;
 	snps,reset-delays-us = <0 10000 1000000>;
-	snps,reset-gpio = <&gpio4 8 GPIO_ACTIVE_LOW>;
+	snps,reset-gpio = <&gpio4 RK_PB0 GPIO_ACTIVE_LOW>;
 	tx_delay = <0x30>;
 	rx_delay = <0x10>;
 	status = "okay";
@@ -345,7 +345,7 @@
 &usbphy {
 	pinctrl-names = "default";
 	pinctrl-0 = <&host_drv>;
-	vbus_drv-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+	vbus_drv-gpios = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>;
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/rk3288-firefly-beta.dts b/arch/arm/boot/dts/rk3288-firefly-beta.dts
index 75d77e3..0195d97 100644
--- a/arch/arm/boot/dts/rk3288-firefly-beta.dts
+++ b/arch/arm/boot/dts/rk3288-firefly-beta.dts
@@ -49,7 +49,7 @@
 };
 
 &ir {
-	gpios = <&gpio7 5 GPIO_ACTIVE_LOW>;
+	gpios = <&gpio7 RK_PA5 GPIO_ACTIVE_LOW>;
 };
 
 &pinctrl {
diff --git a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
index d242588..8134966 100644
--- a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
@@ -96,7 +96,7 @@
 	phy-mode = "rgmii";
 	snps,reset-active-low;
 	snps,reset-delays-us = <0 10000 1000000>;
-	snps,reset-gpio = <&gpio4 8 GPIO_ACTIVE_LOW>;
+	snps,reset-gpio = <&gpio4 RK_PB0 GPIO_ACTIVE_LOW>;
 	tx_delay = <0x30>;
 	rx_delay = <0x10>;
 	status = "ok";
diff --git a/arch/arm/boot/dts/rk3288-firefly-reload.dts b/arch/arm/boot/dts/rk3288-firefly-reload.dts
index 751bee8..d28c8c3 100644
--- a/arch/arm/boot/dts/rk3288-firefly-reload.dts
+++ b/arch/arm/boot/dts/rk3288-firefly-reload.dts
@@ -53,7 +53,7 @@
 
 		power {
 			wakeup-source;
-			gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
 			label = "GPIO Power";
 			linux,code = <KEY_POWER>;
 			pinctrl-names = "default";
@@ -63,14 +63,14 @@
 
 	ir-receiver {
 		compatible = "gpio-ir-receiver";
-		gpios = <&gpio7 0 GPIO_ACTIVE_LOW>;
+		gpios = <&gpio7 RK_PA0 GPIO_ACTIVE_LOW>;
 	};
 
 	leds {
 		compatible = "gpio-leds";
 
 		power {
-			gpios = <&gpio8 2 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio8 RK_PA2 GPIO_ACTIVE_LOW>;
 			label = "firefly:blue:power";
 			pinctrl-names = "default";
 			pinctrl-0 = <&power_led>;
@@ -78,7 +78,7 @@
 		};
 
 		work {
-			gpios = <&gpio8 1 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio8 RK_PA1 GPIO_ACTIVE_LOW>;
 			label = "firefly:blue:user";
 			linux,default-trigger = "rc-feedback";
 			pinctrl-names = "default";
@@ -92,7 +92,7 @@
 		clock-names = "ext_clock";
 		pinctrl-names = "default";
 		pinctrl-0 = <&wifi_enable>;
-		reset-gpios = <&gpio4 28 GPIO_ACTIVE_LOW>;
+		reset-gpios = <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
 	};
 
 	sound {
@@ -112,7 +112,7 @@
 	vcc_host_5v: usb-host-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&host_vbus_drv>;
 		regulator-name = "vcc_host_5v";
@@ -133,7 +133,7 @@
 
 	vcc_sd: sdmmc-regulator {
 		compatible = "regulator-fixed";
-		gpio = <&gpio7 11 GPIO_ACTIVE_LOW>;
+		gpio = <&gpio7 RK_PB3 GPIO_ACTIVE_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&sdmmc_pwr>;
 		regulator-name = "vcc_sd";
@@ -146,7 +146,7 @@
 	vcc_otg_5v: usb-otg-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 12 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&otg_vbus_drv>;
 		regulator-name = "vcc_otg_5v";
@@ -159,7 +159,7 @@
 	dovdd_1v8: dovdd-1v8-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 11 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&dvp_pwr>;
 		regulator-name = "dovdd_1v8";
@@ -171,7 +171,7 @@
 	vcc28_dvp: vcc28-dvp-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 11 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&dvp_pwr>;
 		regulator-name = "vcc28_dvp";
@@ -183,7 +183,7 @@
 	af_28: af_28-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 11 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&dvp_pwr>;
 		regulator-name = "af_28";
@@ -195,7 +195,7 @@
 	dvdd_1v2: af_28-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio7 RK_PB4 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&cif_pwr>;
 		regulator-name = "dvdd_1v2";
diff --git a/arch/arm/boot/dts/rk3288-firefly.dts b/arch/arm/boot/dts/rk3288-firefly.dts
index c07fe92..14271be 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dts
+++ b/arch/arm/boot/dts/rk3288-firefly.dts
@@ -49,7 +49,7 @@
 };
 
 &ir {
-	gpios = <&gpio7 0 GPIO_ACTIVE_LOW>;
+	gpios = <&gpio7 RK_PA0 GPIO_ACTIVE_LOW>;
 };
 
 &pinctrl {
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 44935af..e4dd758 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -75,7 +75,7 @@
 
 		power {
 			wakeup-source;
-			gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
 			label = "GPIO Power";
 			linux,code = <KEY_POWER>;
 			pinctrl-names = "default";
@@ -87,7 +87,7 @@
 		compatible = "gpio-leds";
 
 		work {
-			gpios = <&gpio8 1 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio8 RK_PA1 GPIO_ACTIVE_LOW>;
 			label = "firefly:blue:user";
 			linux,default-trigger = "rc-feedback";
 			pinctrl-names = "default";
@@ -95,7 +95,7 @@
 		};
 
 		power {
-			gpios = <&gpio8 2 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio8 RK_PA2 GPIO_ACTIVE_LOW>;
 			label = "firefly:green:power";
 			linux,default-trigger = "default-on";
 			pinctrl-names = "default";
@@ -114,7 +114,7 @@
 
 	vcc_sd: sdmmc-regulator {
 		compatible = "regulator-fixed";
-		gpio = <&gpio7 11 GPIO_ACTIVE_LOW>;
+		gpio = <&gpio7 RK_PB3 GPIO_ACTIVE_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&sdmmc_pwr>;
 		regulator-name = "vcc_sd";
@@ -145,7 +145,7 @@
 	vcc_host_5v: usb-host-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&host_vbus_drv>;
 		regulator-name = "vcc_host_5v";
@@ -158,7 +158,7 @@
 	vcc_otg_5v: usb-otg-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 12 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&otg_vbus_drv>;
 		regulator-name = "vcc_otg_5v";
@@ -175,7 +175,7 @@
 	vcc28_dvp: vcc28-dvp-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 11 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&dvp_pwr>;
 		regulator-name = "vcc28_dvp";
@@ -213,7 +213,7 @@
 	phy-mode = "rgmii";
 	snps,reset-active-low;
 	snps,reset-delays-us = <0 10000 1000000>;
-	snps,reset-gpio = <&gpio4 8 GPIO_ACTIVE_LOW>;
+	snps,reset-gpio = <&gpio4 RK_PB0 GPIO_ACTIVE_LOW>;
 	tx_delay = <0x30>;
 	rx_delay = <0x10>;
 	status = "ok";
diff --git a/arch/arm/boot/dts/rk3288-miqi.dts b/arch/arm/boot/dts/rk3288-miqi.dts
index 441d450..21326f3 100644
--- a/arch/arm/boot/dts/rk3288-miqi.dts
+++ b/arch/arm/boot/dts/rk3288-miqi.dts
@@ -68,7 +68,7 @@
 		compatible = "gpio-leds";
 
 		work {
-			gpios = <&gpio7 4 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio7 RK_PA4 GPIO_ACTIVE_LOW>;
 			label = "miqi:green:user";
 			linux,default-trigger = "default-on";
 			pinctrl-names = "default";
@@ -87,7 +87,7 @@
 	vcc_host: usb-host-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&host_vbus_drv>;
 		regulator-name = "vcc_host";
@@ -99,7 +99,7 @@
 
 	vcc_sd: sdmmc-regulator {
 		compatible = "regulator-fixed";
-		gpio = <&gpio7 11 GPIO_ACTIVE_LOW>;
+		gpio = <&gpio7 RK_PB3 GPIO_ACTIVE_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&sdmmc_pwr>;
 		regulator-name = "vcc_sd";
@@ -146,7 +146,7 @@
 	phy-mode = "rgmii";
 	snps,reset-active-low;
 	snps,reset-delays-us = <0 10000 1000000>;
-	snps,reset-gpio = <&gpio4 8 GPIO_ACTIVE_LOW>;
+	snps,reset-gpio = <&gpio4 RK_PB0 GPIO_ACTIVE_LOW>;
 	tx_delay = <0x30>;
 	rx_delay = <0x10>;
 	status = "ok";
diff --git a/arch/arm/boot/dts/rk3288-popmetal.dts b/arch/arm/boot/dts/rk3288-popmetal.dts
index bc6d100..e0b5e84 100644
--- a/arch/arm/boot/dts/rk3288-popmetal.dts
+++ b/arch/arm/boot/dts/rk3288-popmetal.dts
@@ -180,7 +180,7 @@
 	phy-supply = <&vcc_lan>;
 	phy-mode = "rgmii";
 	clock_in_out = "input";
-	snps,reset-gpio = <&gpio4 RK_PB0 0>;
+	snps,reset-gpio = <&gpio4 RK_PB0 GPIO_ACTIVE_HIGH>;
 	snps,reset-active-low;
 	snps,reset-delays-us = <0 10000 1000000>;
 	assigned-clocks = <&cru SCLK_MAC>;
diff --git a/arch/arm/boot/dts/rk3288-r89.dts b/arch/arm/boot/dts/rk3288-r89.dts
index 04faa72..54a0fc0 100644
--- a/arch/arm/boot/dts/rk3288-r89.dts
+++ b/arch/arm/boot/dts/rk3288-r89.dts
@@ -68,7 +68,7 @@
 		pinctrl-0 = <&pwrbtn>;
 
 		power {
-			gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
 			label = "GPIO Key Power";
 			linux,input-type = <1>;
@@ -79,7 +79,7 @@
 
 	ir: ir-receiver {
 		compatible = "gpio-ir-receiver";
-		gpios = <&gpio7 0 GPIO_ACTIVE_LOW>;
+		gpios = <&gpio7 RK_PA0 GPIO_ACTIVE_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&ir_int>;
 	};
@@ -87,7 +87,7 @@
 	vcc_host: vcc-host-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&host_vbus_drv>;
 		regulator-name = "vcc_host";
@@ -98,7 +98,7 @@
 	vcc_otg: vcc-otg-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 12 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&otg_vbus_drv>;
 		regulator-name = "vcc_otg";
@@ -111,7 +111,7 @@
 		regulator-name = "sdmmc-supply";
 		regulator-min-microvolt = <3300000>;
 		regulator-max-microvolt = <3300000>;
-		gpio = <&gpio7 11 GPIO_ACTIVE_LOW>;
+		gpio = <&gpio7 RK_PB3 GPIO_ACTIVE_LOW>;
 		startup-delay-us = <100000>;
 		vin-supply = <&vcc_io>;
 	};
@@ -134,7 +134,7 @@
 	phy-supply = <&vcc_lan>;
 	phy-mode = "rgmii";
 	clock_in_out = "input";
-	snps,reset-gpio = <&gpio4 7 0>;
+	snps,reset-gpio = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
 	snps,reset-active-low;
 	snps,reset-delays-us = <0 10000 1000000>;
 	assigned-clocks = <&cru SCLK_MAC>;
diff --git a/arch/arm/boot/dts/rk3288-rock2-som.dtsi b/arch/arm/boot/dts/rk3288-rock2-som.dtsi
index b25ba80..1c0bbc9 100644
--- a/arch/arm/boot/dts/rk3288-rock2-som.dtsi
+++ b/arch/arm/boot/dts/rk3288-rock2-som.dtsi
@@ -51,7 +51,7 @@
 		compatible = "mmc-pwrseq-emmc";
 		pinctrl-0 = <&emmc_reset>;
 		pinctrl-names = "default";
-		reset-gpios = <&gpio3 9 GPIO_ACTIVE_LOW>;
+		reset-gpios = <&gpio3 RK_PB1 GPIO_ACTIVE_LOW>;
 	};
 
 	ext_gmac: external-gmac-clock {
@@ -106,7 +106,7 @@
 	phy-supply = <&vccio_pmu>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&rgmii_pins &phy_rst>;
-	snps,reset-gpio = <&gpio4 8 GPIO_ACTIVE_LOW>;
+	snps,reset-gpio = <&gpio4 RK_PB0 GPIO_ACTIVE_LOW>;
 	snps,reset-active-low;
 	snps,reset-delays-us = <0 10000 30000>;
 	rx_delay = <0x10>;
diff --git a/arch/arm/boot/dts/rk3288-rock2-square.dts b/arch/arm/boot/dts/rk3288-rock2-square.dts
index dd3ad2e..6cc83fe 100644
--- a/arch/arm/boot/dts/rk3288-rock2-square.dts
+++ b/arch/arm/boot/dts/rk3288-rock2-square.dts
@@ -53,13 +53,13 @@
 		compatible = "gpio-leds";
 
 		heartbeat {
-			gpios = <&gpio7 15 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio7 RK_PB7 GPIO_ACTIVE_LOW>;
 			label = "rock2:green:state1";
 			linux,default-trigger = "heartbeat";
 		};
 
 		mmc {
-			gpios = <&gpio0 11 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio0 RK_PB3 GPIO_ACTIVE_LOW>;
 			label = "rock2:blue:state2";
 			linux,default-trigger = "mmc0";
 		};
@@ -67,7 +67,7 @@
 
 	ir: ir-receiver {
 		compatible = "gpio-ir-receiver";
-		gpios = <&gpio8 1 GPIO_ACTIVE_LOW>;
+		gpios = <&gpio8 RK_PA1 GPIO_ACTIVE_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&ir_int>;
 	};
@@ -92,13 +92,13 @@
 		clock-names = "ext_clock";
 		pinctrl-names = "default";
 		pinctrl-0 = <&wifi_enable>;
-		reset-gpios = <&gpio4 28 GPIO_ACTIVE_LOW>;
+		reset-gpios = <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
 	};
 
 	vcc_usb_host: vcc-host-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&host_vbus_drv>;
 		/* Always on as the rockchip usb phy doesn't have a vbus-supply
@@ -110,7 +110,7 @@
 
 	vcc_sd: sdmmc-regulator {
 		compatible = "regulator-fixed";
-		gpio = <&gpio7 11 GPIO_ACTIVE_LOW>;
+		gpio = <&gpio7 RK_PB3 GPIO_ACTIVE_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&sdmmc_pwr>;
 		regulator-name = "vcc_sd";
diff --git a/arch/arm/boot/dts/rk3288-veyron-analog-audio.dtsi b/arch/arm/boot/dts/rk3288-veyron-analog-audio.dtsi
index 6d105914..f8c5a47 100644
--- a/arch/arm/boot/dts/rk3288-veyron-analog-audio.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-analog-audio.dtsi
@@ -17,8 +17,8 @@
 		rockchip,model = "VEYRON-I2S";
 		rockchip,i2s-controller = <&i2s>;
 		rockchip,audio-codec = <&max98090>;
-		rockchip,hp-det-gpios = <&gpio6 5 GPIO_ACTIVE_HIGH>;
-		rockchip,mic-det-gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+		rockchip,hp-det-gpios = <&gpio6 RK_PA5 GPIO_ACTIVE_HIGH>;
+		rockchip,mic-det-gpios = <&gpio6 RK_PB3 GPIO_ACTIVE_LOW>;
 		rockchip,headset-codec = <&headsetcodec>;
 	};
 };
diff --git a/arch/arm/boot/dts/rk3288-veyron-brain.dts b/arch/arm/boot/dts/rk3288-veyron-brain.dts
index cf5311d..ed42552 100644
--- a/arch/arm/boot/dts/rk3288-veyron-brain.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-brain.dts
@@ -67,7 +67,7 @@
 	vcc5_host2: vcc5-host2-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 12 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&usb2_pwr_en>;
 		regulator-name = "vcc5_host2";
@@ -103,8 +103,8 @@
 &rk808 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pmic_int_l &dvs_1 &dvs_2>;
-	dvs-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>,
-		    <&gpio7 15 GPIO_ACTIVE_HIGH>;
+	dvs-gpios = <&gpio7 RK_PB3 GPIO_ACTIVE_HIGH>,
+		    <&gpio7 RK_PB7 GPIO_ACTIVE_HIGH>;
 
 	/delete-property/ vcc6-supply;
 
@@ -133,7 +133,7 @@
 
 &vcc50_hdmi {
 	enable-active-high;
-	gpio = <&gpio7 2 GPIO_ACTIVE_HIGH>;
+	gpio = <&gpio7 RK_PA2 GPIO_ACTIVE_HIGH>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&vcc50_hdmi_en>;
 };
diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
index ce1f879..9e882f3 100644
--- a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
@@ -91,7 +91,7 @@
 			240 241 242 243 244 245 246 247
 			248 249 250 251 252 253 254 255>;
 		default-brightness-level = <128>;
-		enable-gpios = <&gpio7 2 GPIO_ACTIVE_HIGH>;
+		enable-gpios = <&gpio7 RK_PA2 GPIO_ACTIVE_HIGH>;
 		backlight-boot-off;
 		pinctrl-names = "default";
 		pinctrl-0 = <&bl_en>;
@@ -102,7 +102,7 @@
 	gpio-charger {
 		compatible = "gpio-charger";
 		charger-type = "mains";
-		gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
+		gpios = <&gpio0 RK_PB0 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&ac_present_ap>;
 	};
@@ -142,7 +142,7 @@
 	vcc5_host1: vcc5-host1-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 11 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&host1_pwr_en>;
 		regulator-name = "vcc5_host1";
@@ -154,7 +154,7 @@
 	vcc5v_otg: vcc5v-otg-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 12 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&usbotg_pwren_h>;
 		regulator-name = "vcc5_host2";
@@ -190,7 +190,7 @@
 	pinctrl-0 = <&pwr_key_l &ap_lid_int_l>;
 	lid {
 		label = "Lid";
-		gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
+		gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
 		wakeup-source;
 		linux,code = <0>; /* SW_LID */
 		linux,input-type = <5>; /* EV_SW */
diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
index 3748abf..d33f576 100644
--- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
@@ -57,7 +57,7 @@
 	panel_regulator: panel-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio7 14 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio7 RK_PB6 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&lcd_enable_h>;
 		regulator-name = "panel_regulator";
@@ -68,7 +68,7 @@
 	vcc18_lcd: vcc18-lcd {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio2 RK_PB5 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&avdd_1v8_disp_en>;
 		regulator-name = "vcc18_lcd";
@@ -80,7 +80,7 @@
 	backlight_regulator: backlight-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio2 12 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio2 RK_PB4 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&bl_pwr_en>;
 		regulator-name = "backlight_regulator";
@@ -134,8 +134,8 @@
 &rk808 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pmic_int_l &dvs_1 &dvs_2>;
-	dvs-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>,
-		    <&gpio7 15 GPIO_ACTIVE_HIGH>;
+	dvs-gpios = <&gpio7 RK_PB4 GPIO_ACTIVE_HIGH>,
+		    <&gpio7 RK_PB7 GPIO_ACTIVE_HIGH>;
 
 	regulators {
 		mic_vcc: LDO_REG2 {
@@ -160,14 +160,14 @@
 
 &vcc_5v {
 	enable-active-high;
-	gpio = <&gpio7 21 GPIO_ACTIVE_HIGH>;
+	gpio = <&gpio7 RK_PC5 GPIO_ACTIVE_HIGH>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&drv_5v>;
 };
 
 &vcc50_hdmi {
 	enable-active-high;
-	gpio = <&gpio5 19 GPIO_ACTIVE_HIGH>;
+	gpio = <&gpio5 RK_PC3 GPIO_ACTIVE_HIGH>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&vcc50_hdmi_en>;
 };
diff --git a/arch/arm/boot/dts/rk3288-veyron-jerry.dts b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
index f6b2eaa..6107f76 100644
--- a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
@@ -56,7 +56,7 @@
 	panel_regulator: panel-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio7 14 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio7 RK_PB6 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&lcd_enable_h>;
 		regulator-name = "panel_regulator";
@@ -67,7 +67,7 @@
 	vcc18_lcd: vcc18-lcd {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio2 RK_PB5 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&avdd_1v8_disp_en>;
 		regulator-name = "vcc18_lcd";
@@ -79,7 +79,7 @@
 	backlight_regulator: backlight-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio2 12 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio2 RK_PB4 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&bl_pwr_en>;
 		regulator-name = "backlight_regulator";
@@ -123,14 +123,14 @@
 
 &vcc_5v {
 	enable-active-high;
-	gpio = <&gpio7 21 GPIO_ACTIVE_HIGH>;
+	gpio = <&gpio7 RK_PC5 GPIO_ACTIVE_HIGH>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&drv_5v>;
 };
 
 &vcc50_hdmi {
 	enable-active-high;
-	gpio = <&gpio5 19 GPIO_ACTIVE_HIGH>;
+	gpio = <&gpio5 RK_PC3 GPIO_ACTIVE_HIGH>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&vcc50_hdmi_en>;
 };
diff --git a/arch/arm/boot/dts/rk3288-veyron-mickey.dts b/arch/arm/boot/dts/rk3288-veyron-mickey.dts
index f36f6f4..f0994f0 100644
--- a/arch/arm/boot/dts/rk3288-veyron-mickey.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-mickey.dts
@@ -182,8 +182,8 @@
 &rk808 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pmic_int_l &dvs_1 &dvs_2>;
-	dvs-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>,
-		    <&gpio7 15 GPIO_ACTIVE_HIGH>;
+	dvs-gpios = <&gpio7 RK_PB4 GPIO_ACTIVE_HIGH>,
+		    <&gpio7 RK_PB7 GPIO_ACTIVE_HIGH>;
 
 	/delete-property/ vcc6-supply;
 	/delete-property/ vcc12-supply;
@@ -244,7 +244,7 @@
 
 &vcc50_hdmi {
 	enable-active-high;
-	gpio = <&gpio7 11 GPIO_ACTIVE_HIGH>;
+	gpio = <&gpio7 RK_PB3 GPIO_ACTIVE_HIGH>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&power_hdmi_on>;
 };
diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index f72d616d..53c7205 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -55,7 +55,7 @@
 	backlight_regulator: backlight-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio2 12 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio2 RK_PB4 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&bl_pwr_en>;
 		regulator-name = "backlight_regulator";
@@ -66,7 +66,7 @@
 	panel_regulator: panel-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio7 14 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio7 RK_PB6 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&lcd_enable_h>;
 		regulator-name = "panel_regulator";
@@ -77,7 +77,7 @@
 	vcc18_lcd: vcc18-lcd {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio2 RK_PB5 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&avdd_1v8_disp_en>;
 		regulator-name = "vcc18_lcd";
@@ -134,14 +134,14 @@
 
 	volum_down {
 		label = "Volum_down";
-		gpios = <&gpio5 11 GPIO_ACTIVE_LOW>;
+		gpios = <&gpio5 RK_PB3 GPIO_ACTIVE_LOW>;
 		linux,code = <KEY_VOLUMEDOWN>;
 		debounce-interval = <100>;
 	};
 
 	volum_up {
 		label = "Volum_up";
-		gpios = <&gpio5 10 GPIO_ACTIVE_LOW>;
+		gpios = <&gpio5 RK_PB2 GPIO_ACTIVE_LOW>;
 		linux,code = <KEY_VOLUMEUP>;
 		debounce-interval = <100>;
 	};
@@ -168,7 +168,7 @@
 		interrupts = <14 IRQ_TYPE_EDGE_FALLING>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&touch_int &touch_rst>;
-		reset-gpios = <&gpio2 15 GPIO_ACTIVE_LOW>;
+		reset-gpios = <&gpio2 RK_PB7 GPIO_ACTIVE_LOW>;
 		vcc33-supply = <&vcc33_touch>;
 		vccio-supply = <&vcc33_touch>;
 	};
@@ -211,14 +211,14 @@
 
 &vcc_5v {
 	enable-active-high;
-	gpio = <&gpio7 21 GPIO_ACTIVE_HIGH>;
+	gpio = <&gpio7 RK_PC5 GPIO_ACTIVE_HIGH>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&drv_5v>;
 };
 
 &vcc50_hdmi {
 	enable-active-high;
-	gpio = <&gpio5 19 GPIO_ACTIVE_HIGH>;
+	gpio = <&gpio5 RK_PC3 GPIO_ACTIVE_HIGH>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&vcc50_hdmi_en>;
 };
diff --git a/arch/arm/boot/dts/rk3288-veyron-pinky.dts b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
index d44351e..995cff4 100644
--- a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
@@ -76,7 +76,7 @@
 	pinctrl-0 = <&pwr_key_h &ap_lid_int_l>;
 
 	power {
-		gpios = <&gpio0 5 GPIO_ACTIVE_HIGH>;
+		gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
 	};
 };
 
@@ -126,7 +126,7 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd_disabled &sdmmc_cd_gpio
 		     &sdmmc_wp_gpio &sdmmc_bus4>;
-	wp-gpios = <&gpio7 10 GPIO_ACTIVE_HIGH>;
+	wp-gpios = <&gpio7 RK_PB2 GPIO_ACTIVE_HIGH>;
 };
 
 &tsadc {
diff --git a/arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi b/arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi
index fec076e..aef0710 100644
--- a/arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi
@@ -115,7 +115,7 @@
 	cap-mmc-highspeed;
 	cap-sd-highspeed;
 	card-detect-delay = <200>;
-	cd-gpios = <&gpio7 5 GPIO_ACTIVE_LOW>;
+	cd-gpios = <&gpio7 RK_PA5 GPIO_ACTIVE_LOW>;
 	rockchip,default-sample-phase = <90>;
 	num-slots = <1>;
 	sd-uhs-sdr12;
diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
index a0d033f..cc0b78c 100644
--- a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
@@ -57,7 +57,7 @@
 	panel_regulator: panel-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio7 14 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio7 RK_PB6 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&lcd_enable_h>;
 		regulator-name = "panel_regulator";
@@ -68,7 +68,7 @@
 	vcc18_lcd: vcc18-lcd {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio2 RK_PB5 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&avdd_1v8_disp_en>;
 		regulator-name = "vcc18_lcd";
@@ -80,7 +80,7 @@
 	backlight_regulator: backlight-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio2 12 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio2 RK_PB4 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&bl_pwr_en>;
 		regulator-name = "backlight_regulator";
@@ -126,14 +126,14 @@
 
 &vcc_5v {
 	enable-active-high;
-	gpio = <&gpio7 21 GPIO_ACTIVE_HIGH>;
+	gpio = <&gpio7 RK_PC5 GPIO_ACTIVE_HIGH>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&drv_5v>;
 };
 
 &vcc50_hdmi {
 	enable-active-high;
-	gpio = <&gpio5 19 GPIO_ACTIVE_HIGH>;
+	gpio = <&gpio5 RK_PC3 GPIO_ACTIVE_HIGH>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&vcc50_hdmi_en>;
 };
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 2251d28..e2ecd57 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -61,7 +61,7 @@
 		pinctrl-0 = <&pwr_key_l>;
 		power {
 			label = "Power";
-			gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
 			debounce-interval = <100>;
 			wakeup-source;
@@ -70,7 +70,7 @@
 
 	gpio-restart {
 		compatible = "gpio-restart";
-		gpios = <&gpio0 13 GPIO_ACTIVE_HIGH>;
+		gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&ap_warm_reset_h>;
 		priority = <200>;
@@ -80,7 +80,7 @@
 		compatible = "mmc-pwrseq-emmc";
 		pinctrl-0 = <&emmc_reset>;
 		pinctrl-names = "default";
-		reset-gpios = <&gpio2 9 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&gpio2 RK_PB1 GPIO_ACTIVE_HIGH>;
 	};
 
 	sdio_pwrseq: sdio-pwrseq {
@@ -96,7 +96,7 @@
 		 * - SDIO_RESET_L_WL_REG_ON
 		 * - PDN (power down when low)
 		 */
-		reset-gpios = <&gpio4 28 GPIO_ACTIVE_LOW>;
+		reset-gpios = <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
 	};
 
 	vcc_5v: vcc-5v {
-- 
2.7.4




From andy.yan at rock-chips.com  Sat Oct 22 05:59:04 2016
From: andy.yan at rock-chips.com (Andy Yan)
Date: Sat, 22 Oct 2016 20:59:04 +0800
Subject: [PATCH 2/2] ARM64: dts: rockchip: use pin constants to describe gpios
In-Reply-To: <1477140706-6886-1-git-send-email-andy.yan@rock-chips.com>
References: <1477140706-6886-1-git-send-email-andy.yan@rock-chips.com>
Message-ID: <1477141144-6989-1-git-send-email-andy.yan@rock-chips.com>

Use macros to describe gpios will make the dts easier to
read and write.

Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
---

 arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi           | 10 +++++-----
 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts        |  8 ++++----
 arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts | 14 +++++++-------
 arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts        |  4 ++--
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts            | 16 ++++++++--------
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts            |  6 +++---
 6 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi b/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi
index fff8b19..4772917 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi
@@ -90,7 +90,7 @@
 			240 241 242 243 244 245 246 247
 			248 249 250 251 252 253 254 255>;
 		default-brightness-level = <128>;
-		enable-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+		enable-gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&bl_en>;
 		pwms = <&pwm0 0 1000000 PWM_POLARITY_INVERTED>;
@@ -101,7 +101,7 @@
 		compatible = "mmc-pwrseq-emmc";
 		pinctrl-0 = <&emmc_reset>;
 		pinctrl-names = "default";
-		reset-gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&gpio2 RK_PA3 GPIO_ACTIVE_HIGH>;
 	};
 
 	keys: gpio-keys {
@@ -111,7 +111,7 @@
 
 		power {
 			wakeup-source;
-			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
 			label = "GPIO Power";
 			linux,code = <KEY_POWER>;
 		};
@@ -121,7 +121,7 @@
 	vcc_host: vcc-host-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&host_vbus_drv>;
 		regulator-name = "vcc_host";
@@ -166,7 +166,7 @@
 	phy-supply = <&vcc_lan>;
 	phy-mode = "rmii";
 	clock_in_out = "output";
-	snps,reset-gpio = <&gpio3 12 0>;
+	snps,reset-gpio = <&gpio3 RK_PB4 GPIO_ACTIVE_HIGH>;
 	snps,reset-active-low;
 	snps,reset-delays-us = <0 10000 1000000>;
 	pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
index e5eeca2..e5b92d2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
@@ -66,7 +66,7 @@
 
 	ir: ir-receiver {
 		compatible = "gpio-ir-receiver";
-		gpios = <&gpio3 30 GPIO_ACTIVE_LOW>;
+		gpios = <&gpio3 RK_PD6 GPIO_ACTIVE_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&ir_int>;
 	};
@@ -77,7 +77,7 @@
 		pinctrl-0 = <&pwr_key>;
 
 		power {
-			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
 			label = "GPIO Power";
 			linux,code = <KEY_POWER>;
 			wakeup-source;
@@ -88,13 +88,13 @@
 		compatible = "gpio-leds";
 
 		blue {
-			gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
+			gpios = <&gpio2 RK_PA2 GPIO_ACTIVE_HIGH>;
 			label = "geekbox:blue:led";
 			default-state = "on";
 		};
 
 		red {
-			gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
+			gpios = <&gpio2 RK_PA3 GPIO_ACTIVE_HIGH>;
 			label = "geekbox:red:led";
 			default-state = "off";
 		};
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts b/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
index ea0a8ec..2e431f13 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
@@ -61,7 +61,7 @@
 		compatible = "mmc-pwrseq-emmc";
 		pinctrl-0 = <&emmc_reset>;
 		pinctrl-names = "default";
-		reset-gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&gpio2 RK_PA3 GPIO_ACTIVE_HIGH>;
 	};
 
 	ext_gmac: external-gmac-clock {
@@ -78,7 +78,7 @@
 
 		power {
 			wakeup-source;
-			gpios = <&gpio0 5 GPIO_ACTIVE_HIGH>;
+			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
 			label = "GPIO Power";
 			linux,code = <KEY_POWER>;
 		};
@@ -88,7 +88,7 @@
 		compatible = "gpio-leds";
 
 		red {
-			gpios = <&gpio3 29 GPIO_ACTIVE_HIGH>;
+			gpios = <&gpio3 RK_PD5 GPIO_ACTIVE_HIGH>;
 			label = "orion:red:led";
 			pinctrl-names = "default";
 			pinctrl-0 = <&led_ctl>;
@@ -96,7 +96,7 @@
 		};
 
 		blue {
-			gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>;
+			gpios = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
 			label = "orion:blue:led";
 			pinctrl-names = "default";
 			pinctrl-0 = <&stby_pwren>;
@@ -117,7 +117,7 @@
 	/* supplies both host and otg */
 	vcc_host: vcc-host-regulator {
 		compatible = "regulator-fixed";
-		gpio = <&gpio0 4 GPIO_ACTIVE_LOW>;
+		gpio = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&host_vbus_drv>;
 		regulator-name = "vcc_host";
@@ -149,7 +149,7 @@
 	vcc_sd: vcc-sd-regulator {
 		compatible = "regulator-fixed";
 		regulator-name = "vcc_sd";
-		gpio = <&gpio3 11 GPIO_ACTIVE_LOW>;
+		gpio = <&gpio3 RK_PB3 GPIO_ACTIVE_LOW>;
 		regulator-min-microvolt = <1800000>;
 		regulator-max-microvolt = <3300000>;
 		vin-supply = <&vcc_io>;
@@ -217,7 +217,7 @@
 	phy-mode = "rgmii";
 	pinctrl-names = "default";
 	pinctrl-0 = <&rgmii_pins>;
-	snps,reset-gpio = <&gpio3 12 0>;
+	snps,reset-gpio = <&gpio3 RK_PB4 GPIO_ACTIVE_HIGH>;
 	snps,reset-active-low;
 	snps,reset-delays-us = <0 10000 1000000>;
 	tx_delay = <0x30>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts b/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
index 85f7a24..62919c4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
@@ -63,7 +63,7 @@
 		pinctrl-0 = <&pwr_key>;
 
 		power {
-			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
 			label = "GPIO Power";
 			linux,code = <KEY_POWER>;
 			wakeup-source;
@@ -248,7 +248,7 @@
 		reg = <0x40>;
 		interrupt-parent = <&gpio3>;
 		interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
-		power-gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;
+		power-gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
 		touchscreen-size-x = <800>;
 		touchscreen-size-y = <1280>;
 		silead,max-fingers = <5>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
index eed1ef6..7134181 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
@@ -61,7 +61,7 @@
 		compatible = "mmc-pwrseq-emmc";
 		pinctrl-0 = <&emmc_reset>;
 		pinctrl-names = "default";
-		reset-gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&gpio2 RK_PA3 GPIO_ACTIVE_HIGH>;
 	};
 
 	keys: gpio-keys {
@@ -71,7 +71,7 @@
 
 		power {
 			wakeup-source;
-			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
 			label = "GPIO Power";
 			linux,code = <KEY_POWER>;
 		};
@@ -81,7 +81,7 @@
 		compatible = "gpio-leds";
 
 		work {
-			gpios = <&gpio3 29 GPIO_ACTIVE_HIGH>;
+			gpios = <&gpio3 RK_PD5 GPIO_ACTIVE_HIGH>;
 			label = "r88:green:led";
 			pinctrl-names = "default";
 			pinctrl-0 = <&led_ctl>;
@@ -90,7 +90,7 @@
 
 	ir: ir-receiver {
 		compatible = "gpio-ir-receiver";
-		gpios = <&gpio3 30 GPIO_ACTIVE_LOW>;
+		gpios = <&gpio3 RK_PD6 GPIO_ACTIVE_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&ir_int>;
 	};
@@ -104,10 +104,10 @@
 
 		reset-gpios =
 			/* BT_RST_N */
-			<&gpio3 5 GPIO_ACTIVE_LOW>,
+			<&gpio3 RK_PA5 GPIO_ACTIVE_LOW>,
 
 			/* WL_REG_ON */
-			<&gpio3 4 GPIO_ACTIVE_LOW>;
+			<&gpio3 RK_PA4 GPIO_ACTIVE_LOW>;
 	};
 
 	vcc_18: vcc18-regulator {
@@ -124,7 +124,7 @@
 	vcc_host: vcc-host-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&host_vbus_drv>;
 		regulator-name = "vcc_host";
@@ -199,7 +199,7 @@
 	phy-supply = <&vcc_lan>;
 	phy-mode = "rmii";
 	clock_in_out = "output";
-	snps,reset-gpio = <&gpio3 12 0>;
+	snps,reset-gpio = <&gpio3 RK_PB4 GPIO_ACTIVE_HIGH>;
 	snps,reset-active-low;
 	snps,reset-delays-us = <0 10000 1000000>;
 	pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
index 8e82497..f00e0d5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -88,7 +88,7 @@
 	vcc5v0_host: vcc5v0-host-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio4 RK_PD1 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&vcc5v0_host_en>;
 		regulator-name = "vcc5v0_host";
@@ -123,7 +123,7 @@
 	phy-mode = "rgmii";
 	pinctrl-names = "default";
 	pinctrl-0 = <&rgmii_pins>;
-	snps,reset-gpio = <&gpio3 15 GPIO_ACTIVE_LOW>;
+	snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
 	snps,reset-active-low;
 	snps,reset-delays-us = <0 10000 50000>;
 	tx_delay = <0x28>;
@@ -156,7 +156,7 @@
 };
 
 &pcie0 {
-	ep-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
+	ep-gpios = <&gpio3 RK_PB5 GPIO_ACTIVE_HIGH>;
 	num-lanes = <4>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pcie_clkreqn>;
-- 
2.7.4




From ayaka at soulik.info  Sat Oct 22 12:18:53 2016
From: ayaka at soulik.info (Randy Li)
Date: Sun, 23 Oct 2016 03:18:53 +0800
Subject: [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp
 IP
Message-ID: <1477163933-13140-1-git-send-email-ayaka@soulik.info>

I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
RK3288, once trying to enable the pclk clock, the kernel would dead.
This patch would try to enable them first. The eDP_AVDD_1V8 more
likely to be applied to eDP phy, but I have no time to confirmed
it yet.

Signed-off-by: Randy Li <ayaka at soulik.info>
---
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8548e82..6bf0441 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -17,6 +17,7 @@
 #include <linux/of_device.h>
 #include <linux/of_graph.h>
 #include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
 #include <linux/reset.h>
 #include <linux/clk.h>
 
@@ -70,6 +71,7 @@ struct rockchip_dp_device {
 	struct clk               *grfclk;
 	struct regmap            *grf;
 	struct reset_control     *rst;
+	struct regulator_bulk_data supplies[2];
 
 	struct work_struct	 psr_work;
 	spinlock_t		 psr_lock;
@@ -146,6 +148,13 @@ static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
 
 	cancel_work_sync(&dp->psr_work);
 
+	ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
+			dp->supplies);
+	if (ret) {
+		dev_err(dp->dev, "failed to enable vdd supply %d\n", ret);
+		return ret;
+	}
+
 	ret = clk_prepare_enable(dp->pclk);
 	if (ret < 0) {
 		dev_err(dp->dev, "failed to enable pclk %d\n", ret);
@@ -168,6 +177,9 @@ static int rockchip_dp_powerdown(struct analogix_dp_plat_data *plat_data)
 
 	clk_disable_unprepare(dp->pclk);
 
+	regulator_bulk_disable(ARRAY_SIZE(dp->supplies),
+			dp->supplies);
+
 	return 0;
 }
 
@@ -323,6 +335,19 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
 		return PTR_ERR(dp->rst);
 	}
 
+	dp->supplies[0].supply = "vcc";
+	dp->supplies[1].supply = "vccio";
+	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dp->supplies),
+			dp->supplies);
+	if (ret < 0) {
+		dev_err(dev, "failed to get regulators: %d\n", ret);
+	}
+	ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
+			dp->supplies);
+	if (ret < 0) {
+		dev_err(dev, "failed to enable regulators: %d\n", ret);
+	}
+
 	ret = clk_prepare_enable(dp->pclk);
 	if (ret < 0) {
 		dev_err(dp->dev, "failed to enable pclk %d\n", ret);
-- 
2.7.4



From randy.li at rock-chips.com  Mon Oct 24 00:59:27 2016
From: randy.li at rock-chips.com (Randy Li)
Date: Mon, 24 Oct 2016 15:59:27 +0800
Subject: How to implement a EGL or DRM display in VA-API driver
Message-ID: <8cbe53b0-29af-bb45-7895-6e0a6c23d024@rock-chips.com>

Hello:
   I am going to implement a EGL and DRM display for Rockchip VA-API 
driver. We do have a EGL implementation in Rockchip VA-API driver, but 
it is implemented in the standard way, we did that as a X11 display.
   I didn't see the usage of struct VADriverVTableEGL in gstreamer, and 
I have no idea about where should I implement something functions like 
eglExportDRMImageMESA().
   The DRM seems more complex, the reason I want to use the DRM is that, 
GPU would not work with the 4K video rendering, so the DRM means that 
directly output the video into video controller in our platform. But 
still have no idea what kind of thing I should implement in the VA-API 
driver. It seems that the VA-API base library would open a DRM instance 
for the driver, but leaving those configure for connector, encoder, 
planes to VA-API driver?
   Could you guys give me same sample code or example of those kind of 
display in VA-API or the documents would help(I would not image there is 
a VA-API documents)

-- 
Randy Li
The third produce department



From andy.yan at rock-chips.com  Mon Oct 24 04:55:32 2016
From: andy.yan at rock-chips.com (Andy Yan)
Date: Mon, 24 Oct 2016 19:55:32 +0800
Subject: [PATCH] i2c: rk3x: Give the tuning value 0 during
 rk3x_i2c_v0_calc_timings
In-Reply-To: <1477125822-30644-1-git-send-email-david.wu@rock-chips.com>
References: <1477125822-30644-1-git-send-email-david.wu@rock-chips.com>
Message-ID: <e2972b59-b648-88ed-ca0a-acd827b63c2b@rock-chips.com>

Hi:


On 2016?10?22? 16:43, David Wu wrote:
> We found a bug that i2c transfer sometimes failed on 3066a board with
> stabel-4.8, the con register would be updated by uninitialized tuning
> value, it made the i2c transfer failed.
>
> So give the tuning value to be zero during rk3x_i2c_v0_calc_timings.
>
> Signed-off-by: David Wu <david.wu at rock-chips.com>
> ---
>   drivers/i2c/busses/i2c-rk3x.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> index 50702c7..df22066 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -694,6 +694,8 @@ static int rk3x_i2c_v0_calc_timings(unsigned long clk_rate,
>   	t_calc->div_low--;
>   	t_calc->div_high--;
>   
> +	/* Give the tuning value 0, that would not update con register */
> +	t_calc->tuning = 0;
>   	/* Maximum divider supported by hw is 0xffff */
>   	if (t_calc->div_low > 0xffff) {
>   		t_calc->div_low = 0xffff;

rk3066a based board can't boot up(with endless i2c irq messages print 
out) from linux-4.8 without this fix.

Tested-by: Andy Yan <andy.yan at rock-chips.com>



From jsarha at ti.com  Mon Oct 24 06:21:59 2016
From: jsarha at ti.com (Jyri Sarha)
Date: Mon, 24 Oct 2016 16:21:59 +0300
Subject: [PATCH] drm: convert DT component matching to
 component_match_add_release()
In-Reply-To: <E1bwo6l-0005Io-Q1@rmk-PC.armlinux.org.uk>
References: <E1bwo6l-0005Io-Q1@rmk-PC.armlinux.org.uk>
Message-ID: <b5e34e26-cb73-bb10-ceeb-749565fde8ad@ti.com>

On 10/19/16 13:28, Russell King wrote:
> Convert DT component matching to use component_match_add_release().
> 
> Signed-off-by: Russell King <rmk+kernel at armlinux.org.uk>

Acked-by: Jyri Sarha <jsarha at ti.com>
Reviewed-by: Jyri Sarha <jsarha at ti.com>

However, the patch description is a bit brief. It took me this mail
thread to fully understand why simple comparison of pointer values may
cause problems if the of_node ref count goes to zero.

BR,
Jyri

> ---
> Can we please get this patch from May merged into the drm-misc or
> whatever trees so that we don't end up with conflicts?  I've no idea
> who looks after drm-misc, as they have _still_ failed to add
> themselves to MAINTAINERS.
> 
>  drivers/gpu/drm/arm/hdlcd_drv.c                 |  3 ++-
>  drivers/gpu/drm/arm/malidp_drv.c                |  4 +++-
>  drivers/gpu/drm/armada/armada_drv.c             |  2 +-
>  drivers/gpu/drm/drm_of.c                        | 28 +++++++++++++++++++++++--
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c           |  5 +++--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  7 ++++---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c          |  4 +++-
>  drivers/gpu/drm/msm/msm_drv.c                   | 12 ++++++-----
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c     |  6 ++++--
>  drivers/gpu/drm/sti/sti_drv.c                   |  5 +++--
>  drivers/gpu/drm/sun4i/sun4i_drv.c               |  3 ++-
>  drivers/gpu/drm/tilcdc/tilcdc_external.c        |  4 +++-
>  include/drm/drm_of.h                            | 12 +++++++++++
>  13 files changed, 73 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index fb6a418ce6be..6477d1a65266 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -453,7 +453,8 @@ static int hdlcd_probe(struct platform_device *pdev)
>  		return -EAGAIN;
>  	}
>  
> -	component_match_add(&pdev->dev, &match, compare_dev, port);
> +	drm_of_component_match_add(&pdev->dev, &match, compare_dev, port);
> +	of_node_put(port);
>  
>  	return component_master_add_with_match(&pdev->dev, &hdlcd_master_ops,
>  					       match);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> index 9280358b8f15..9f4739452a25 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -493,7 +493,9 @@ static int malidp_platform_probe(struct platform_device *pdev)
>  		return -EAGAIN;
>  	}
>  
> -	component_match_add(&pdev->dev, &match, malidp_compare_dev, port);
> +	drm_of_component_match_add(&pdev->dev, &match, malidp_compare_dev,
> +				   port);
> +	of_node_put(port);
>  	return component_master_add_with_match(&pdev->dev, &malidp_master_ops,
>  					       match);
>  }
> diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
> index 1e0e68f608e4..94e46da9a758 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -254,7 +254,7 @@ static void armada_add_endpoints(struct device *dev,
>  			continue;
>  		}
>  
> -		component_match_add(dev, match, compare_of, remote);
> +		drm_of_component_match_add(dev, match, compare_of, remote);
>  		of_node_put(remote);
>  	}
>  }
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index bc98bb94264d..47848ed8ca48 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -6,6 +6,11 @@
>  #include <drm/drm_crtc.h>
>  #include <drm/drm_of.h>
>  
> +static void drm_release_of(struct device *dev, void *data)
> +{
> +	of_node_put(data);
> +}
> +
>  /**
>   * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
>   * @dev: DRM device
> @@ -64,6 +69,24 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>  EXPORT_SYMBOL(drm_of_find_possible_crtcs);
>  
>  /**
> + * drm_of_component_match_add - Add a component helper OF node match rule
> + * @master: master device
> + * @matchptr: component match pointer
> + * @compare: compare function used for matching component
> + * @node: of_node
> + */
> +void drm_of_component_match_add(struct device *master,
> +				struct component_match **matchptr,
> +				int (*compare)(struct device *, void *),
> +				struct device_node *node)
> +{
> +	of_node_get(node);
> +	component_match_add_release(master, matchptr, drm_release_of,
> +				    compare, node);
> +}
> +EXPORT_SYMBOL_GPL(drm_of_component_match_add);
> +
> +/**
>   * drm_of_component_probe - Generic probe function for a component based master
>   * @dev: master device containing the OF node
>   * @compare_of: compare function used for matching components
> @@ -101,7 +124,7 @@ int drm_of_component_probe(struct device *dev,
>  			continue;
>  		}
>  
> -		component_match_add(dev, &match, compare_of, port);
> +		drm_of_component_match_add(dev, &match, compare_of, port);
>  		of_node_put(port);
>  	}
>  
> @@ -140,7 +163,8 @@ int drm_of_component_probe(struct device *dev,
>  				continue;
>  			}
>  
> -			component_match_add(dev, &match, compare_of, remote);
> +			drm_of_component_match_add(dev, &match, compare_of,
> +						   remote);
>  			of_node_put(remote);
>  		}
>  		of_node_put(port);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index aa687669e22b..0dee6acbd880 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -16,6 +16,7 @@
>  
>  #include <linux/component.h>
>  #include <linux/of_platform.h>
> +#include <drm/drm_of.h>
>  
>  #include "etnaviv_drv.h"
>  #include "etnaviv_gpu.h"
> @@ -629,8 +630,8 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
>  			if (!core_node)
>  				break;
>  
> -			component_match_add(&pdev->dev, &match, compare_of,
> -					    core_node);
> +			drm_of_component_match_add(&pdev->dev, &match,
> +						   compare_of, core_node);
>  			of_node_put(core_node);
>  		}
>  	} else if (dev->platform_data) {
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> index 90377a609c98..e88fde18c946 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -24,6 +24,7 @@
>  #include <drm/drm_fb_cma_helper.h>
>  #include <drm/drm_atomic_helper.h>
>  #include <drm/drm_crtc_helper.h>
> +#include <drm/drm_of.h>
>  
>  #include "kirin_drm_drv.h"
>  
> @@ -260,14 +261,13 @@ static struct device_node *kirin_get_remote_node(struct device_node *np)
>  		DRM_ERROR("no valid endpoint node\n");
>  		return ERR_PTR(-ENODEV);
>  	}
> -	of_node_put(endpoint);
>  
>  	remote = of_graph_get_remote_port_parent(endpoint);
> +	of_node_put(endpoint);
>  	if (!remote) {
>  		DRM_ERROR("no valid remote node\n");
>  		return ERR_PTR(-ENODEV);
>  	}
> -	of_node_put(remote);
>  
>  	if (!of_device_is_available(remote)) {
>  		DRM_ERROR("not available for remote node\n");
> @@ -294,7 +294,8 @@ static int kirin_drm_platform_probe(struct platform_device *pdev)
>  	if (IS_ERR(remote))
>  		return PTR_ERR(remote);
>  
> -	component_match_add(dev, &match, compare_of, remote);
> +	drm_of_component_match_add(dev, &match, compare_of, remote);
> +	of_node_put(remote);
>  
>  	return component_master_add_with_match(dev, &kirin_drm_ops, match);
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index cf83f6507ec8..9c5430fb82a2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -18,6 +18,7 @@
>  #include <drm/drm_crtc_helper.h>
>  #include <drm/drm_gem.h>
>  #include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_of.h>
>  #include <linux/component.h>
>  #include <linux/iommu.h>
>  #include <linux/of_address.h>
> @@ -415,7 +416,8 @@ static int mtk_drm_probe(struct platform_device *pdev)
>  		    comp_type == MTK_DPI) {
>  			dev_info(dev, "Adding component match for %s\n",
>  				 node->full_name);
> -			component_match_add(dev, &match, compare_of, node);
> +			drm_of_component_match_add(dev, &match, compare_of,
> +						   node);
>  		} else {
>  			struct mtk_ddp_comp *comp;
>  
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index fb5c0b0a7594..84d38eaea585 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -15,6 +15,8 @@
>   * this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <drm/drm_of.h>
> +
>  #include "msm_drv.h"
>  #include "msm_debugfs.h"
>  #include "msm_fence.h"
> @@ -919,8 +921,8 @@ static int add_components_mdp(struct device *mdp_dev,
>  			continue;
>  		}
>  
> -		component_match_add(master_dev, matchptr, compare_of, intf);
> -
> +		drm_of_component_match_add(master_dev, matchptr, compare_of,
> +					   intf);
>  		of_node_put(intf);
>  		of_node_put(ep_node);
>  	}
> @@ -962,8 +964,8 @@ static int add_display_components(struct device *dev,
>  		put_device(mdp_dev);
>  
>  		/* add the MDP component itself */
> -		component_match_add(dev, matchptr, compare_of,
> -				    mdp_dev->of_node);
> +		drm_of_component_match_add(dev, matchptr, compare_of,
> +					   mdp_dev->of_node);
>  	} else {
>  		/* MDP4 */
>  		mdp_dev = dev;
> @@ -996,7 +998,7 @@ static int add_gpu_components(struct device *dev,
>  	if (!np)
>  		return 0;
>  
> -	component_match_add(dev, matchptr, compare_of, np);
> +	drm_of_component_match_add(dev, matchptr, compare_of, np);
>  
>  	of_node_put(np);
>  
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 8c8cbe837e61..6fe161192bb4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -20,6 +20,7 @@
>  #include <drm/drm_crtc_helper.h>
>  #include <drm/drm_fb_helper.h>
>  #include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_of.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/module.h>
> @@ -388,7 +389,7 @@ static void rockchip_add_endpoints(struct device *dev,
>  			continue;
>  		}
>  
> -		component_match_add(dev, match, compare_of, remote);
> +		drm_of_component_match_add(dev, match, compare_of, remote);
>  		of_node_put(remote);
>  	}
>  }
> @@ -437,7 +438,8 @@ static int rockchip_drm_platform_probe(struct platform_device *pdev)
>  		}
>  
>  		of_node_put(iommu);
> -		component_match_add(dev, &match, compare_of, port->parent);
> +		drm_of_component_match_add(dev, &match, compare_of,
> +					   port->parent);
>  		of_node_put(port);
>  	}
>  
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index 2784919a7366..5e819876e642 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -17,6 +17,7 @@
>  #include <drm/drm_crtc_helper.h>
>  #include <drm/drm_gem_cma_helper.h>
>  #include <drm/drm_fb_cma_helper.h>
> +#include <drm/drm_of.h>
>  
>  #include "sti_crtc.h"
>  #include "sti_drv.h"
> @@ -423,8 +424,8 @@ static int sti_platform_probe(struct platform_device *pdev)
>  	child_np = of_get_next_available_child(node, NULL);
>  
>  	while (child_np) {
> -		component_match_add(dev, &match, compare_of, child_np);
> -		of_node_put(child_np);
> +		drm_of_component_match_add(dev, &match, compare_of,
> +					   child_np);
>  		child_np = of_get_next_available_child(node, child_np);
>  	}
>  
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 0da9862ad8ed..b3c4ad605e81 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -18,6 +18,7 @@
>  #include <drm/drm_fb_cma_helper.h>
>  #include <drm/drm_gem_cma_helper.h>
>  #include <drm/drm_fb_helper.h>
> +#include <drm/drm_of.h>
>  
>  #include "sun4i_crtc.h"
>  #include "sun4i_drv.h"
> @@ -239,7 +240,7 @@ static int sun4i_drv_add_endpoints(struct device *dev,
>  		/* Add current component */
>  		DRM_DEBUG_DRIVER("Adding component %s\n",
>  				 of_node_full_name(node));
> -		component_match_add(dev, match, compare_of, node);
> +		drm_of_component_match_add(dev, match, compare_of, node);
>  		count++;
>  	}
>  
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> index 68e895021005..06a4c584f3cb 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> @@ -10,6 +10,7 @@
>  
>  #include <linux/component.h>
>  #include <linux/of_graph.h>
> +#include <drm/drm_of.h>
>  
>  #include "tilcdc_drv.h"
>  #include "tilcdc_external.h"
> @@ -160,7 +161,8 @@ int tilcdc_get_external_components(struct device *dev,
>  
>  		dev_dbg(dev, "Subdevice node '%s' found\n", node->name);
>  		if (match)
> -			component_match_add(dev, match, dev_match_of, node);
> +			drm_of_component_match_add(dev, match, dev_match_of,
> +						   node);
>  		of_node_put(node);
>  		count++;
>  	}
> diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> index 3fd87b386ed7..d6b4c5587bbe 100644
> --- a/include/drm/drm_of.h
> +++ b/include/drm/drm_of.h
> @@ -4,6 +4,7 @@
>  #include <linux/of_graph.h>
>  
>  struct component_master_ops;
> +struct component_match;
>  struct device;
>  struct drm_device;
>  struct drm_encoder;
> @@ -12,6 +13,10 @@ struct device_node;
>  #ifdef CONFIG_OF
>  extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>  					   struct device_node *port);
> +extern void drm_of_component_match_add(struct device *master,
> +				       struct component_match **matchptr,
> +				       int (*compare)(struct device *, void *),
> +				       struct device_node *node);
>  extern int drm_of_component_probe(struct device *dev,
>  				  int (*compare_of)(struct device *, void *),
>  				  const struct component_master_ops *m_ops);
> @@ -25,6 +30,13 @@ static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>  	return 0;
>  }
>  
> +static void drm_of_component_match_add(struct device *master,
> +				       struct component_match **matchptr,
> +				       int (*compare)(struct device *, void *),
> +				       struct device_node *node)
> +{
> +}
> +
>  static inline int
>  drm_of_component_probe(struct device *dev,
>  		       int (*compare_of)(struct device *, void *),
> 



From broonie at kernel.org  Mon Oct 24 11:01:32 2016
From: broonie at kernel.org (Mark Brown)
Date: Mon, 24 Oct 2016 19:01:32 +0100
Subject: Applied "ASoC: rockchip: constify snd_soc_ops structures" to the asoc
 tree
In-Reply-To: <1476543351-17858-4-git-send-email-Julia.Lawall@lip6.fr>
Message-ID: <E1byjYy-0000sp-Cx@debutante>

The patch

   ASoC: rockchip: constify snd_soc_ops structures

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 705e9994a437bbdaf655612f3526e3567db56bdd Mon Sep 17 00:00:00 2001
From: Julia Lawall <Julia.Lawall at lip6.fr>
Date: Sat, 15 Oct 2016 16:55:47 +0200
Subject: [PATCH] ASoC: rockchip: constify snd_soc_ops structures

Check for snd_soc_ops structures that are only stored in the ops field of a
snd_soc_dai_link structure.  This field is declared const, so snd_soc_ops
structures that have this property can be declared as const also.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct snd_soc_ops i at p = { ... };

@ok1@
identifier r.i;
struct snd_soc_dai_link e;
position p;
@@
e.ops = &i at p;

@ok2@
identifier r.i, e;
position p;
@@
struct snd_soc_dai_link e[] = { ..., { .ops = &i at p, }, ..., };

@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
struct snd_soc_ops e;
@@
e at i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct snd_soc_ops i = { ... };
// </smpl>

The effect on the layout of the .o files is shown by the following output
of the size command, first before then after the transformation:

   text    data     bss     dec     hex filename
   5027    2488     416    7931    1efb sound/soc/rockchip/rk3399_gru_sound.o
   5219    2312     416    7947    1f0b sound/soc/rockchip/rk3399_gru_sound.o

   text    data     bss     dec     hex filename
   3499    1648     384    5531    159b sound/soc/rockchip/rockchip_max98090.o
   3563    1584     384    5531    159b sound/soc/rockchip/rockchip_max98090.o

   text    data     bss     dec     hex filename
   3455    1536     384    5375    14ff sound/soc/rockchip/rockchip_rt5645.o
   3519    1480     384    5383    1507 sound/soc/rockchip/rockchip_rt5645.o

Signed-off-by: Julia Lawall <Julia.Lawall at lip6.fr>
Signed-off-by: Mark Brown <broonie at kernel.org>
---
 sound/soc/rockchip/rk3399_gru_sound.c  | 6 +++---
 sound/soc/rockchip/rockchip_max98090.c | 2 +-
 sound/soc/rockchip/rockchip_rt5645.c   | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
index 0cbd23555ba4..3475c61a5fa0 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -228,15 +228,15 @@ static int rockchip_sound_da7219_init(struct snd_soc_pcm_runtime *rtd)
 	return 0;
 }
 
-static struct snd_soc_ops rockchip_sound_max98357a_ops = {
+static const struct snd_soc_ops rockchip_sound_max98357a_ops = {
 	.hw_params = rockchip_sound_max98357a_hw_params,
 };
 
-static struct snd_soc_ops rockchip_sound_rt5514_ops = {
+static const struct snd_soc_ops rockchip_sound_rt5514_ops = {
 	.hw_params = rockchip_sound_rt5514_hw_params,
 };
 
-static struct snd_soc_ops rockchip_sound_da7219_ops = {
+static const struct snd_soc_ops rockchip_sound_da7219_ops = {
 	.hw_params = rockchip_sound_da7219_hw_params,
 };
 
diff --git a/sound/soc/rockchip/rockchip_max98090.c b/sound/soc/rockchip/rockchip_max98090.c
index e70ffad07184..789d6f1e2b5f 100644
--- a/sound/soc/rockchip/rockchip_max98090.c
+++ b/sound/soc/rockchip/rockchip_max98090.c
@@ -119,7 +119,7 @@ static int rk_aif1_hw_params(struct snd_pcm_substream *substream,
 	return ret;
 }
 
-static struct snd_soc_ops rk_aif1_ops = {
+static const struct snd_soc_ops rk_aif1_ops = {
 	.hw_params = rk_aif1_hw_params,
 };
 
diff --git a/sound/soc/rockchip/rockchip_rt5645.c b/sound/soc/rockchip/rockchip_rt5645.c
index 440a8026346a..9e0c17805807 100644
--- a/sound/soc/rockchip/rockchip_rt5645.c
+++ b/sound/soc/rockchip/rockchip_rt5645.c
@@ -135,7 +135,7 @@ static int rk_init(struct snd_soc_pcm_runtime *runtime)
 				     &headset_jack);
 }
 
-static struct snd_soc_ops rk_aif1_ops = {
+static const struct snd_soc_ops rk_aif1_ops = {
 	.hw_params = rk_aif1_hw_params,
 };
 
-- 
2.8.1



From broonie at kernel.org  Mon Oct 24 11:03:36 2016
From: broonie at kernel.org (Mark Brown)
Date: Mon, 24 Oct 2016 19:03:36 +0100
Subject: Applied "ASoC: rk3399_gru_sound: Fix non static symbol warning" to
 the asoc tree
In-Reply-To: <1476717318-12684-1-git-send-email-weiyj.lk@gmail.com>
Message-ID: <E1byjay-000129-Lg@debutante>

The patch

   ASoC: rk3399_gru_sound: Fix non static symbol warning

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 818f76831992198121c8949789c71a1adb02e329 Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1 at huawei.com>
Date: Mon, 17 Oct 2016 15:15:18 +0000
Subject: [PATCH] ASoC: rk3399_gru_sound: Fix non static symbol warning

Fixes the following sparse warning:

sound/soc/rockchip/rk3399_gru_sound.c:41:14: warning:
 symbol 'rt5514_dmic_delay' was not declared. Should it be static?

Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
Signed-off-by: Mark Brown <broonie at kernel.org>
---
 sound/soc/rockchip/rk3399_gru_sound.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
index 9ed735a6cf49..0cbd23555ba4 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -38,7 +38,7 @@
 
 #define SOUND_FS	256
 
-unsigned int rt5514_dmic_delay;
+static unsigned int rt5514_dmic_delay;
 
 static struct snd_soc_jack rockchip_sound_jack;
 
-- 
2.8.1



From dianders at chromium.org  Mon Oct 24 11:29:54 2016
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 24 Oct 2016 11:29:54 -0700
Subject: [PATCH] i2c: rk3x: Give the tuning value 0 during
 rk3x_i2c_v0_calc_timings
In-Reply-To: <1477125822-30644-1-git-send-email-david.wu@rock-chips.com>
References: <1477125822-30644-1-git-send-email-david.wu@rock-chips.com>
Message-ID: <CAD=FV=VKJhaZtfT7CZBN1UE0-aHpJrMPYUDicO6vAcNUvfOP5g@mail.gmail.com>

Hi,

On Sat, Oct 22, 2016 at 1:43 AM, David Wu <david.wu at rock-chips.com> wrote:
> We found a bug that i2c transfer sometimes failed on 3066a board with
> stabel-4.8, the con register would be updated by uninitialized tuning
> value, it made the i2c transfer failed.
>
> So give the tuning value to be zero during rk3x_i2c_v0_calc_timings.
>
> Signed-off-by: David Wu <david.wu at rock-chips.com>
> ---
>  drivers/i2c/busses/i2c-rk3x.c | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Douglas Anderson <dianders at chromium.org>


From robh at kernel.org  Mon Oct 24 17:17:19 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 24 Oct 2016 19:17:19 -0500
Subject: [PATCH v8 2/3] of/pci: Add helper function to parse
 max-link-speed from dt
In-Reply-To: <1476755110-22647-2-git-send-email-shawn.lin@rock-chips.com>
References: <1476755110-22647-1-git-send-email-shawn.lin@rock-chips.com>
 <1476755110-22647-2-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <CAL_JsqKyGRU3T-gaFwG43zcChHDHUZhsH7Rn5FASrgnc-RBvCw@mail.gmail.com>

On Mon, Oct 17, 2016 at 8:45 PM, Shawn Lin <shawn.lin at rock-chips.com> wrote:
> This new helper function could be used by host drivers to
> get the limitaion of max link speed provided by dt. If the
> property isn't assigned or is invalid, it will return -EINVAL
> to the caller.
>
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

Acked-by: Rob Herring <robh at kernel.org>

Rob


From wsa at the-dreams.de  Tue Oct 25 02:12:49 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Tue, 25 Oct 2016 11:12:49 +0200
Subject: [PATCH] i2c: rk3x: Give the tuning value 0 during
 rk3x_i2c_v0_calc_timings
In-Reply-To: <1477125822-30644-1-git-send-email-david.wu@rock-chips.com>
References: <1477125822-30644-1-git-send-email-david.wu@rock-chips.com>
Message-ID: <20161025091249.GB1597@katana>

On Sat, Oct 22, 2016 at 04:43:42PM +0800, David Wu wrote:
> We found a bug that i2c transfer sometimes failed on 3066a board with
> stabel-4.8, the con register would be updated by uninitialized tuning
> value, it made the i2c transfer failed.
> 
> So give the tuning value to be zero during rk3x_i2c_v0_calc_timings.
> 
> Signed-off-by: David Wu <david.wu at rock-chips.com>

Added stable and applied to for-current, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20161025/0184c0eb/attachment.sig>

From randy.li at rock-chips.com  Tue Oct 25 05:47:49 2016
From: randy.li at rock-chips.com (Randy Li)
Date: Tue, 25 Oct 2016 20:47:49 +0800
Subject: The PWM is broken at RK3288
Message-ID: <e2f9b965-e025-e260-48a2-b6968f96e11b@rock-chips.com>

Hello
   Recently, paulk told me that he meet a problem with PWM backlight at 
rk3288, I do a test at EVB board a few minutes age, it is true. The 
kernel 4.4 would work fine. So the pwm driver at next-20161020 maybe 
broken. It is too late, so I have no time to confirm whether the PWM1 
would have the same problem.
   I would look into it in the other day and see whether I could do 
something for that.
-- 
Randy Li
The third produce department



From heiko at sntech.de  Tue Oct 25 05:58:11 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 25 Oct 2016 14:58:11 +0200
Subject: The PWM is broken at RK3288
In-Reply-To: <e2f9b965-e025-e260-48a2-b6968f96e11b@rock-chips.com>
References: <e2f9b965-e025-e260-48a2-b6968f96e11b@rock-chips.com>
Message-ID: <25477004.WQlyuGeDoO@diego>

Hi Randy,

Am Dienstag, 25. Oktober 2016, 20:47:49 schrieb Randy Li:
>    Recently, paulk told me that he meet a problem with PWM backlight at
> rk3288, I do a test at EVB board a few minutes age, it is true. The
> kernel 4.4 would work fine. So the pwm driver at next-20161020 maybe
> broken. It is too late, so I have no time to confirm whether the PWM1
> would have the same problem.
>    I would look into it in the other day and see whether I could do
> something for that.

just yesterday I booted a 4.9-rc2 on my rk3288-veyron-pinky Chromebook and the 
display (backlight supplied by the pwm) was still working correctly. I haven't 
tested any next-kernels yet though, so maybe something broke there.


Heiko


From ayaka at soulik.info  Tue Oct 25 07:15:34 2016
From: ayaka at soulik.info (Randy Li)
Date: Tue, 25 Oct 2016 22:15:34 +0800
Subject: [PATCH] phy: Add reset callback for not generic phy
Message-ID: <1477404934-7425-1-git-send-email-ayaka@soulik.info>

I forget to add a dummy function in case the CONFIG_GENERIC_PHY
is disabled.

Signed-off-by: Randy Li <ayaka at soulik.info>
---
 include/linux/phy/phy.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index ee1bed7..78bb0d7 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -253,6 +253,13 @@ static inline int phy_set_mode(struct phy *phy, enum phy_mode mode)
 	return -ENOSYS;
 }
 
+static inline int phy_reset(struct phy *phy)
+{
+	if (!phy)
+		return 0;
+	return -ENOSYS;
+}
+
 static inline int phy_get_bus_width(struct phy *phy)
 {
 	return -ENOSYS;
-- 
2.7.4



From seanpaul at chromium.org  Tue Oct 25 09:44:04 2016
From: seanpaul at chromium.org (Sean Paul)
Date: Tue, 25 Oct 2016 12:44:04 -0400
Subject: [PATCH] drm: convert DT component matching to
 component_match_add_release()
In-Reply-To: <E1bwo6l-0005Io-Q1@rmk-PC.armlinux.org.uk>
References: <E1bwo6l-0005Io-Q1@rmk-PC.armlinux.org.uk>
Message-ID: <CAOw6vb+x5kkuGHym5CY+p2v_inxAQSvxbjF7vs5WDUHMMD9p7w@mail.gmail.com>

On Wed, Oct 19, 2016 at 6:28 AM, Russell King
<rmk+kernel at armlinux.org.uk> wrote:
> Convert DT component matching to use component_match_add_release().
>
> Signed-off-by: Russell King <rmk+kernel at armlinux.org.uk>

Applied to drm-misc, thanks!

Sean

> ---
> Can we please get this patch from May merged into the drm-misc or
> whatever trees so that we don't end up with conflicts?  I've no idea
> who looks after drm-misc, as they have _still_ failed to add
> themselves to MAINTAINERS.
>
>  drivers/gpu/drm/arm/hdlcd_drv.c                 |  3 ++-
>  drivers/gpu/drm/arm/malidp_drv.c                |  4 +++-
>  drivers/gpu/drm/armada/armada_drv.c             |  2 +-
>  drivers/gpu/drm/drm_of.c                        | 28 +++++++++++++++++++++++--
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c           |  5 +++--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  7 ++++---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c          |  4 +++-
>  drivers/gpu/drm/msm/msm_drv.c                   | 12 ++++++-----
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c     |  6 ++++--
>  drivers/gpu/drm/sti/sti_drv.c                   |  5 +++--
>  drivers/gpu/drm/sun4i/sun4i_drv.c               |  3 ++-
>  drivers/gpu/drm/tilcdc/tilcdc_external.c        |  4 +++-
>  include/drm/drm_of.h                            | 12 +++++++++++
>  13 files changed, 73 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index fb6a418ce6be..6477d1a65266 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -453,7 +453,8 @@ static int hdlcd_probe(struct platform_device *pdev)
>                 return -EAGAIN;
>         }
>
> -       component_match_add(&pdev->dev, &match, compare_dev, port);
> +       drm_of_component_match_add(&pdev->dev, &match, compare_dev, port);
> +       of_node_put(port);
>
>         return component_master_add_with_match(&pdev->dev, &hdlcd_master_ops,
>                                                match);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> index 9280358b8f15..9f4739452a25 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -493,7 +493,9 @@ static int malidp_platform_probe(struct platform_device *pdev)
>                 return -EAGAIN;
>         }
>
> -       component_match_add(&pdev->dev, &match, malidp_compare_dev, port);
> +       drm_of_component_match_add(&pdev->dev, &match, malidp_compare_dev,
> +                                  port);
> +       of_node_put(port);
>         return component_master_add_with_match(&pdev->dev, &malidp_master_ops,
>                                                match);
>  }
> diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
> index 1e0e68f608e4..94e46da9a758 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -254,7 +254,7 @@ static void armada_add_endpoints(struct device *dev,
>                         continue;
>                 }
>
> -               component_match_add(dev, match, compare_of, remote);
> +               drm_of_component_match_add(dev, match, compare_of, remote);
>                 of_node_put(remote);
>         }
>  }
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index bc98bb94264d..47848ed8ca48 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -6,6 +6,11 @@
>  #include <drm/drm_crtc.h>
>  #include <drm/drm_of.h>
>
> +static void drm_release_of(struct device *dev, void *data)
> +{
> +       of_node_put(data);
> +}
> +
>  /**
>   * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
>   * @dev: DRM device
> @@ -64,6 +69,24 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>  EXPORT_SYMBOL(drm_of_find_possible_crtcs);
>
>  /**
> + * drm_of_component_match_add - Add a component helper OF node match rule
> + * @master: master device
> + * @matchptr: component match pointer
> + * @compare: compare function used for matching component
> + * @node: of_node
> + */
> +void drm_of_component_match_add(struct device *master,
> +                               struct component_match **matchptr,
> +                               int (*compare)(struct device *, void *),
> +                               struct device_node *node)
> +{
> +       of_node_get(node);
> +       component_match_add_release(master, matchptr, drm_release_of,
> +                                   compare, node);
> +}
> +EXPORT_SYMBOL_GPL(drm_of_component_match_add);
> +
> +/**
>   * drm_of_component_probe - Generic probe function for a component based master
>   * @dev: master device containing the OF node
>   * @compare_of: compare function used for matching components
> @@ -101,7 +124,7 @@ int drm_of_component_probe(struct device *dev,
>                         continue;
>                 }
>
> -               component_match_add(dev, &match, compare_of, port);
> +               drm_of_component_match_add(dev, &match, compare_of, port);
>                 of_node_put(port);
>         }
>
> @@ -140,7 +163,8 @@ int drm_of_component_probe(struct device *dev,
>                                 continue;
>                         }
>
> -                       component_match_add(dev, &match, compare_of, remote);
> +                       drm_of_component_match_add(dev, &match, compare_of,
> +                                                  remote);
>                         of_node_put(remote);
>                 }
>                 of_node_put(port);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index aa687669e22b..0dee6acbd880 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -16,6 +16,7 @@
>
>  #include <linux/component.h>
>  #include <linux/of_platform.h>
> +#include <drm/drm_of.h>
>
>  #include "etnaviv_drv.h"
>  #include "etnaviv_gpu.h"
> @@ -629,8 +630,8 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
>                         if (!core_node)
>                                 break;
>
> -                       component_match_add(&pdev->dev, &match, compare_of,
> -                                           core_node);
> +                       drm_of_component_match_add(&pdev->dev, &match,
> +                                                  compare_of, core_node);
>                         of_node_put(core_node);
>                 }
>         } else if (dev->platform_data) {
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> index 90377a609c98..e88fde18c946 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -24,6 +24,7 @@
>  #include <drm/drm_fb_cma_helper.h>
>  #include <drm/drm_atomic_helper.h>
>  #include <drm/drm_crtc_helper.h>
> +#include <drm/drm_of.h>
>
>  #include "kirin_drm_drv.h"
>
> @@ -260,14 +261,13 @@ static struct device_node *kirin_get_remote_node(struct device_node *np)
>                 DRM_ERROR("no valid endpoint node\n");
>                 return ERR_PTR(-ENODEV);
>         }
> -       of_node_put(endpoint);
>
>         remote = of_graph_get_remote_port_parent(endpoint);
> +       of_node_put(endpoint);
>         if (!remote) {
>                 DRM_ERROR("no valid remote node\n");
>                 return ERR_PTR(-ENODEV);
>         }
> -       of_node_put(remote);
>
>         if (!of_device_is_available(remote)) {
>                 DRM_ERROR("not available for remote node\n");
> @@ -294,7 +294,8 @@ static int kirin_drm_platform_probe(struct platform_device *pdev)
>         if (IS_ERR(remote))
>                 return PTR_ERR(remote);
>
> -       component_match_add(dev, &match, compare_of, remote);
> +       drm_of_component_match_add(dev, &match, compare_of, remote);
> +       of_node_put(remote);
>
>         return component_master_add_with_match(dev, &kirin_drm_ops, match);
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index cf83f6507ec8..9c5430fb82a2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -18,6 +18,7 @@
>  #include <drm/drm_crtc_helper.h>
>  #include <drm/drm_gem.h>
>  #include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_of.h>
>  #include <linux/component.h>
>  #include <linux/iommu.h>
>  #include <linux/of_address.h>
> @@ -415,7 +416,8 @@ static int mtk_drm_probe(struct platform_device *pdev)
>                     comp_type == MTK_DPI) {
>                         dev_info(dev, "Adding component match for %s\n",
>                                  node->full_name);
> -                       component_match_add(dev, &match, compare_of, node);
> +                       drm_of_component_match_add(dev, &match, compare_of,
> +                                                  node);
>                 } else {
>                         struct mtk_ddp_comp *comp;
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index fb5c0b0a7594..84d38eaea585 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -15,6 +15,8 @@
>   * this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>
> +#include <drm/drm_of.h>
> +
>  #include "msm_drv.h"
>  #include "msm_debugfs.h"
>  #include "msm_fence.h"
> @@ -919,8 +921,8 @@ static int add_components_mdp(struct device *mdp_dev,
>                         continue;
>                 }
>
> -               component_match_add(master_dev, matchptr, compare_of, intf);
> -
> +               drm_of_component_match_add(master_dev, matchptr, compare_of,
> +                                          intf);
>                 of_node_put(intf);
>                 of_node_put(ep_node);
>         }
> @@ -962,8 +964,8 @@ static int add_display_components(struct device *dev,
>                 put_device(mdp_dev);
>
>                 /* add the MDP component itself */
> -               component_match_add(dev, matchptr, compare_of,
> -                                   mdp_dev->of_node);
> +               drm_of_component_match_add(dev, matchptr, compare_of,
> +                                          mdp_dev->of_node);
>         } else {
>                 /* MDP4 */
>                 mdp_dev = dev;
> @@ -996,7 +998,7 @@ static int add_gpu_components(struct device *dev,
>         if (!np)
>                 return 0;
>
> -       component_match_add(dev, matchptr, compare_of, np);
> +       drm_of_component_match_add(dev, matchptr, compare_of, np);
>
>         of_node_put(np);
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 8c8cbe837e61..6fe161192bb4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -20,6 +20,7 @@
>  #include <drm/drm_crtc_helper.h>
>  #include <drm/drm_fb_helper.h>
>  #include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_of.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/module.h>
> @@ -388,7 +389,7 @@ static void rockchip_add_endpoints(struct device *dev,
>                         continue;
>                 }
>
> -               component_match_add(dev, match, compare_of, remote);
> +               drm_of_component_match_add(dev, match, compare_of, remote);
>                 of_node_put(remote);
>         }
>  }
> @@ -437,7 +438,8 @@ static int rockchip_drm_platform_probe(struct platform_device *pdev)
>                 }
>
>                 of_node_put(iommu);
> -               component_match_add(dev, &match, compare_of, port->parent);
> +               drm_of_component_match_add(dev, &match, compare_of,
> +                                          port->parent);
>                 of_node_put(port);
>         }
>
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index 2784919a7366..5e819876e642 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -17,6 +17,7 @@
>  #include <drm/drm_crtc_helper.h>
>  #include <drm/drm_gem_cma_helper.h>
>  #include <drm/drm_fb_cma_helper.h>
> +#include <drm/drm_of.h>
>
>  #include "sti_crtc.h"
>  #include "sti_drv.h"
> @@ -423,8 +424,8 @@ static int sti_platform_probe(struct platform_device *pdev)
>         child_np = of_get_next_available_child(node, NULL);
>
>         while (child_np) {
> -               component_match_add(dev, &match, compare_of, child_np);
> -               of_node_put(child_np);
> +               drm_of_component_match_add(dev, &match, compare_of,
> +                                          child_np);
>                 child_np = of_get_next_available_child(node, child_np);
>         }
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 0da9862ad8ed..b3c4ad605e81 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -18,6 +18,7 @@
>  #include <drm/drm_fb_cma_helper.h>
>  #include <drm/drm_gem_cma_helper.h>
>  #include <drm/drm_fb_helper.h>
> +#include <drm/drm_of.h>
>
>  #include "sun4i_crtc.h"
>  #include "sun4i_drv.h"
> @@ -239,7 +240,7 @@ static int sun4i_drv_add_endpoints(struct device *dev,
>                 /* Add current component */
>                 DRM_DEBUG_DRIVER("Adding component %s\n",
>                                  of_node_full_name(node));
> -               component_match_add(dev, match, compare_of, node);
> +               drm_of_component_match_add(dev, match, compare_of, node);
>                 count++;
>         }
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> index 68e895021005..06a4c584f3cb 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> @@ -10,6 +10,7 @@
>
>  #include <linux/component.h>
>  #include <linux/of_graph.h>
> +#include <drm/drm_of.h>
>
>  #include "tilcdc_drv.h"
>  #include "tilcdc_external.h"
> @@ -160,7 +161,8 @@ int tilcdc_get_external_components(struct device *dev,
>
>                 dev_dbg(dev, "Subdevice node '%s' found\n", node->name);
>                 if (match)
> -                       component_match_add(dev, match, dev_match_of, node);
> +                       drm_of_component_match_add(dev, match, dev_match_of,
> +                                                  node);
>                 of_node_put(node);
>                 count++;
>         }
> diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> index 3fd87b386ed7..d6b4c5587bbe 100644
> --- a/include/drm/drm_of.h
> +++ b/include/drm/drm_of.h
> @@ -4,6 +4,7 @@
>  #include <linux/of_graph.h>
>
>  struct component_master_ops;
> +struct component_match;
>  struct device;
>  struct drm_device;
>  struct drm_encoder;
> @@ -12,6 +13,10 @@ struct device_node;
>  #ifdef CONFIG_OF
>  extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>                                            struct device_node *port);
> +extern void drm_of_component_match_add(struct device *master,
> +                                      struct component_match **matchptr,
> +                                      int (*compare)(struct device *, void *),
> +                                      struct device_node *node);
>  extern int drm_of_component_probe(struct device *dev,
>                                   int (*compare_of)(struct device *, void *),
>                                   const struct component_master_ops *m_ops);
> @@ -25,6 +30,13 @@ static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>         return 0;
>  }
>
> +static void drm_of_component_match_add(struct device *master,
> +                                      struct component_match **matchptr,
> +                                      int (*compare)(struct device *, void *),
> +                                      struct device_node *node)
> +{
> +}
> +
>  static inline int
>  drm_of_component_probe(struct device *dev,
>                        int (*compare_of)(struct device *, void *),
> --
> 2.1.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From John.Youn at synopsys.com  Tue Oct 25 13:47:03 2016
From: John.Youn at synopsys.com (John Youn)
Date: Tue, 25 Oct 2016 13:47:03 -0700
Subject: [PATCH] phy: Add reset callback for not generic phy
In-Reply-To: <1477404934-7425-1-git-send-email-ayaka@soulik.info>
References: <1477404934-7425-1-git-send-email-ayaka@soulik.info>
Message-ID: <8c8d86e6-a3b1-a381-dd3f-70e43768cfb9@synopsys.com>

On 10/25/2016 7:15 AM, Randy Li wrote:
> I forget to add a dummy function in case the CONFIG_GENERIC_PHY
> is disabled.
> 
> Signed-off-by: Randy Li <ayaka at soulik.info>

Fixes: cac18ecb6f44 ("phy: Add reset callback")
Tested-by: John Youn <johnyoun at synopsys.com>

Hi Kishon,

Can you take this for 4.9-rc?

Thanks,
John



> ---
>  include/linux/phy/phy.h | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index ee1bed7..78bb0d7 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -253,6 +253,13 @@ static inline int phy_set_mode(struct phy *phy, enum phy_mode mode)
>  	return -ENOSYS;
>  }
>  
> +static inline int phy_reset(struct phy *phy)
> +{
> +	if (!phy)
> +		return 0;
> +	return -ENOSYS;
> +}
> +
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>  	return -ENOSYS;
> 
>





From lee.jones at linaro.org  Wed Oct 26 06:53:54 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 26 Oct 2016 14:53:54 +0100
Subject: [PATCH] mfd: rk808: RK818 uses DEV_OFF to power off supplies
In-Reply-To: <1476694990-1887-1-git-send-email-chenjh@rock-chips.com>
References: <1476694990-1887-1-git-send-email-chenjh@rock-chips.com>
Message-ID: <20161026135354.GB13127@dell>

On Mon, 17 Oct 2016, Jianhong Chen wrote:

> DEV_OFF and DEV_OFF_RST functions for RK808 are designed error that
> only DEV_OFF_RST can power off supplies. RK818 has been fixed this
> issue, so that DEV_OFF is used to power off supplies.
> 
> Signed-off-by: Jianhong Chen <chenjh at rock-chips.com>
> ---
>  drivers/mfd/rk808.c       | 23 ++++++++++++++++++++++-
>  include/linux/mfd/rk808.h |  1 +
>  2 files changed, 23 insertions(+), 1 deletion(-)

Applied, thanks.

> diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
> index 0f8acc5..2c9acdb 100644
> --- a/drivers/mfd/rk808.c
> +++ b/drivers/mfd/rk808.c
> @@ -290,6 +290,24 @@ static void rk808_device_shutdown(void)
>  		dev_err(&rk808_i2c_client->dev, "power off error!\n");
>  }
>  
> +static void rk818_device_shutdown(void)
> +{
> +	int ret;
> +	struct rk808 *rk808 = i2c_get_clientdata(rk808_i2c_client);
> +
> +	if (!rk808) {
> +		dev_warn(&rk808_i2c_client->dev,
> +			 "have no rk818, so do nothing here\n");
> +		return;
> +	}
> +
> +	ret = regmap_update_bits(rk808->regmap,
> +				 RK818_DEVCTRL_REG,
> +				 DEV_OFF, DEV_OFF);
> +	if (ret)
> +		dev_err(&rk808_i2c_client->dev, "power off error!\n");
> +}
> +
>  static const struct of_device_id rk808_of_match[] = {
>  	{ .compatible = "rockchip,rk808" },
>  	{ .compatible = "rockchip,rk818" },
> @@ -304,6 +322,7 @@ static int rk808_probe(struct i2c_client *client,
>  	struct rk808 *rk808;
>  	const struct rk808_reg_data *pre_init_reg;
>  	const struct mfd_cell *cells;
> +	void (*pm_pwroff_fn)(void);
>  	int nr_pre_init_regs;
>  	int nr_cells;
>  	int pm_off = 0;
> @@ -331,6 +350,7 @@ static int rk808_probe(struct i2c_client *client,
>  		nr_pre_init_regs = ARRAY_SIZE(rk808_pre_init_reg);
>  		cells = rk808s;
>  		nr_cells = ARRAY_SIZE(rk808s);
> +		pm_pwroff_fn = rk808_device_shutdown;
>  		break;
>  	case RK818_ID:
>  		rk808->regmap_cfg = &rk818_regmap_config;
> @@ -339,6 +359,7 @@ static int rk808_probe(struct i2c_client *client,
>  		nr_pre_init_regs = ARRAY_SIZE(rk818_pre_init_reg);
>  		cells = rk818s;
>  		nr_cells = ARRAY_SIZE(rk818s);
> +		pm_pwroff_fn = rk818_device_shutdown;
>  		break;
>  	default:
>  		dev_err(&client->dev, "Unsupported RK8XX ID %lu\n",
> @@ -393,7 +414,7 @@ static int rk808_probe(struct i2c_client *client,
>  				"rockchip,system-power-controller");
>  	if (pm_off && !pm_power_off) {
>  		rk808_i2c_client = client;
> -		pm_power_off = rk808_device_shutdown;
> +		pm_power_off = pm_pwroff_fn;
>  	}
>  
>  	return 0;
> diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
> index 6d435a3..83701ef 100644
> --- a/include/linux/mfd/rk808.h
> +++ b/include/linux/mfd/rk808.h
> @@ -290,6 +290,7 @@ enum rk818_reg {
>  #define SWITCH2_EN	BIT(6)
>  #define SWITCH1_EN	BIT(5)
>  #define DEV_OFF_RST	BIT(3)
> +#define DEV_OFF		BIT(0)
>  
>  #define VB_LO_ACT		BIT(4)
>  #define VB_LO_SEL_3500MV	(7 << 0)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From kishon at ti.com  Wed Oct 26 13:14:46 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 27 Oct 2016 01:44:46 +0530
Subject: [PATCH] phy: Add reset callback for not generic phy
In-Reply-To: <8c8d86e6-a3b1-a381-dd3f-70e43768cfb9@synopsys.com>
References: <1477404934-7425-1-git-send-email-ayaka@soulik.info>
 <8c8d86e6-a3b1-a381-dd3f-70e43768cfb9@synopsys.com>
Message-ID: <8899b220-5f6b-5c26-d966-68d1d79e5fc7@ti.com>



On Wednesday 26 October 2016 02:17 AM, John Youn wrote:
> On 10/25/2016 7:15 AM, Randy Li wrote:
>> I forget to add a dummy function in case the CONFIG_GENERIC_PHY
>> is disabled.
>>
>> Signed-off-by: Randy Li <ayaka at soulik.info>
> 
> Fixes: cac18ecb6f44 ("phy: Add reset callback")
> Tested-by: John Youn <johnyoun at synopsys.com>
> 
> Hi Kishon,
> 
> Can you take this for 4.9-rc?

sure, merged now.

Thanks
Kishon

> 
> Thanks,
> John
> 
> 
> 
>> ---
>>  include/linux/phy/phy.h | 7 +++++++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
>> index ee1bed7..78bb0d7 100644
>> --- a/include/linux/phy/phy.h
>> +++ b/include/linux/phy/phy.h
>> @@ -253,6 +253,13 @@ static inline int phy_set_mode(struct phy *phy, enum phy_mode mode)
>>  	return -ENOSYS;
>>  }
>>  
>> +static inline int phy_reset(struct phy *phy)
>> +{
>> +	if (!phy)
>> +		return 0;
>> +	return -ENOSYS;
>> +}
>> +
>>  static inline int phy_get_bus_width(struct phy *phy)
>>  {
>>  	return -ENOSYS;
>>
>>
> 
> 
> 


From randy.li at rock-chips.com  Wed Oct 26 18:08:08 2016
From: randy.li at rock-chips.com (Randy Li)
Date: Thu, 27 Oct 2016 09:08:08 +0800
Subject: [RFC] V4L2 unified low-level decoder API
In-Reply-To: <58C70A34B28DE743B9604C8841D375C2793D2999@SAFEX1MAIL5.st.com>
References: <58C70A34B28DE743B9604C8841D375C2793D2999@SAFEX1MAIL5.st.com>
Message-ID: <aab23d5d-d41d-78e1-7324-77b9d98ee127@rock-chips.com>



On 10/26/2016 11:09 PM, Hugues FRUCHET wrote:
> Hi,
>
>
>
> This RFC aims to start discussions in order to define the codec specific
> controls structures to fulfill the low-level decoder API needed by non
> ?Stream API? based decoders (?stateless? or ?Frame API? based decoders).
>
> Several implementation exists now which runs on several SoC and various
> software frameworks.
>
> The idea is to find the communalities between all those implementations
> and SoC to define a single unified interface in V4L2 includes.
>
> Even if ?Request API? is needed to pass those codec specific controls
> from userspace down to kernel on a per-buffer basis, we can start
> discussions and define the controls in parallel of its development.
Yes, I have sent a one for H.264 decoder and JPEG encoder.
>
> We can even propose some implementations based on existing V4L2 control
> framework (which doesn?t support ?per-frame? basis) by ensuring
> atomicity of sequence S_EXT_CTRL(header[i])/QBUF(stream[i]). Constraint
> can then be relaxed when ?Request API? is merged.
>
>
>
> I would like to propose to work on a ?per-codec? basis, having at least
> 2 different SoC and 2 different frameworks to test and validate controls.
>
> To do so, I have tried to identify some people that have worked on this
> subject and have proposed some implementations, feel free to correct me
> and enhance the list if needed:
>
> * MPEG2/MPEG4
>
>    - Florent Revest for Allwinner A13 CedarX support [1] tested with VLC
> -> libVA + sunxi-cedrus-drv-video -> V4L2
>
>    - Myself for STMicroelectronics Delta support [2] tested with
> GStreamer V4L2 -> libv4l2 + libv4l-delta plugin -> V4L2
>
>
>
> * VP8
>
> - Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [3] tested with
> Chromium -> V4L2
>
> - Jung Zhao for Rockchip RK3288 VPU support [4] <cannot find the
> framework used>
There is rockchip VDPAU driver supporting it, but it is .
>
>
>
> * H264
>
> - Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [5] tested with
> Chromium -> V4L2
>
> - Randy Li for Rockchip RK3288  VPU support [6] tested with VLC? ->
> libVA + rockchip-va-driver -> V4L2
I only tested it with Gstreamer -> VA-API element -> Rockchip VA-API 
driver -> V4L2
>
>                                                                                                                          VLC?
> -> libVDPAU + rockchip-va-driver -> V4L2
>
> I can work to define MPEG2/MPEG4 controls and propose functional
> implementations for those codecs, and will be glad to co-work with you
> Florent.
But it may not work with Rockchip's SoC, you may check the following branch
https://github.com/hizukiayaka/rockchip-video-driver/tree/rk_v4l2_mix
>
> I can help on H264 on a code review basis based on the functional H264
> setup I have in-house and codec knowledge, but I cannot provide
> implementation in a reasonable timeframe, same for VP8.
>
>
>
> Apart of very details of each codec, we have also to state about generic
> concerns such as:
>
> -          new pixel format introduction (VP8 => VP8F, H264 => S264,
> MPG2 => MG2F, MPG4 => MG4F)
I don't think it is necessary.
>
> -          new device caps to indicate that driver requires extra
> headers ? maybe not needed because redundant with new pixel format
I prefer this one.
>
> -          continue to modify v4l2-controls.h ? or do we add some new
> specific header files (H264 is huge!) ?
Not huge. You could check rockchip's kernel.
>
> -          how to manage sequence header & picture header,
> optional/extended controls (MPEG2 sequence/picture extensions, H264 SEI,
> ?). Personally I have added flags inside a single control structure,
> H264 is done in a different way using several controls
> (SPS/PPS/SLICE/DECODE/?)
the last one is dpb, except the dpb, it would have the same numbers of 
controls to those structures defined in VA-API H264 decoder.
>
>
> Thanks you to all of you for your attention and feel free to react on
> this topic if you are interested to work on this subject.
Currently, I have to pause the process of VA-API drive, and moving to 
the other idea I have said before, creating a new API in userspace(but 
won't archive the goal I set before in this step). There are some 
shortages in VA-API I have said in last email making the performance in 
4K video and extending the Gstreamer VA-API is a little difficult job 
and need more time.
And the development for the new VPU driver for rockchip would pause a 
while as well.

It would not be a long time(a few weeks) and I am still available in my 
free time(at home). It is good to know the wheel begin to roll. And do 
feel free to assign job to me.
>
>
>
> Best regards,
>
> Hugues.
>
>
>
> [0] [ANN] Codec & Request API Brainstorm meeting Oct 10 & 11
> https://www.spinics.net/lists/linux-media/msg106699.html
>
> [1] MPEG2 A13 CedarX http://www.spinics.net/lists/linux-media/msg104823.html
>
> [1] MPEG4 A13 CedarX http://www.spinics.net/lists/linux-media/msg104817.html
>
> [2] MPEG2 STi4xx Delta
> http://www.spinics.net/lists/linux-media/msg106240.html
>
> [2] MPEG4 STi4xx Delta is also supported but not yet pushed
>
> [3] VP8 Rockchip RK3288, RK3399? VPU
> https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/master/sys-kernel/linux-headers/files/0002-CHROMIUM-v4l-Add-VP8-low-level-decoder-API-controls.patch
>
>
> [4] VP8 Rockchip RK3288 VPU
> http://www.spinics.net/lists/linux-media/msg97997.html
>
> [5] H264 Rockchip RK3288, RK3399? VPU
> https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/master/sys-kernel/linux-headers/files/0001-CHROMIUM-media-headers-Import-V4L2-headers-from-Chro.patch
>
> [6] H264 Rockchip RK3288 VPU
> http://www.spinics.net/lists/linux-media/msg105095.html
>
>
>

-- 
Randy Li
The third produce department



From billy.mcintosh at radio.usim.edu.my  Thu Oct 27 01:28:27 2016
From: billy.mcintosh at radio.usim.edu.my (FedEx 2Day A.M.)
Date: Thu, 27 Oct 2016 08:28:27 +0000
Subject: ROCK, Shipment delivery problem #0000976484
Message-ID: <42a0ee17b7cef488734a32c6914706f5@radio.usim.edu.my>

Dear Rock,

We could not deliver your parcel.
Delivery Label is attached to this email.

Regards,
Billy Mcintosh,
Operation Manager.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Delivery_Notification_0000976484.zip
Type: application/zip
Size: 7550 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20161027/9fadaefc/attachment.zip>

From wsa at the-dreams.de  Thu Oct 27 06:11:21 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Thu, 27 Oct 2016 15:11:21 +0200
Subject: [PATCH] i2c: rk3x: Give the tuning value 0 during
 rk3x_i2c_v0_calc_timings
In-Reply-To: <1477125822-30644-1-git-send-email-david.wu@rock-chips.com>
References: <1477125822-30644-1-git-send-email-david.wu@rock-chips.com>
Message-ID: <20161027131121.GB1559@tetsubishi>

On Sat, Oct 22, 2016 at 04:43:42PM +0800, David Wu wrote:
> We found a bug that i2c transfer sometimes failed on 3066a board with
> stabel-4.8, the con register would be updated by uninitialized tuning
> value, it made the i2c transfer failed.
> 
> So give the tuning value to be zero during rk3x_i2c_v0_calc_timings.
> 
> Signed-off-by: David Wu <david.wu at rock-chips.com>

What I missed to say in my review:

Please use a subject line that describes WHY the change is needed not so
much WHAT is done. Like: "fix missing initialization causing boot
problems"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20161027/c2981e1f/attachment-0001.sig>

From robh at kernel.org  Thu Oct 27 07:54:27 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 27 Oct 2016 09:54:27 -0500
Subject: [PATCH 1/2] PCI: rockchip: Add three new resets as required
 properties
In-Reply-To: <1477017836-19317-2-git-send-email-shawn.lin@rock-chips.com>
References: <1477017836-19317-1-git-send-email-shawn.lin@rock-chips.com>
 <1477017836-19317-2-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <20161027145427.xxdtq7i37wgphowj@rob-hp-laptop>

On Fri, Oct 21, 2016 at 10:43:55AM +0800, Shawn Lin wrote:
> pm_rst, aclk_rst, pclk_rst was controlled by rom code so the
> software wasn't needed to control it again in theory. But it
> didn't work properly, so we do need to do it again and add a
> enough delay between the assert of pm_rst and the deassert of
> pm_rst. The Soc intergrated with this controller, rk3399 is still
> under MP test internally, so the backward compatibility won't be
> a big deal.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
> 
> ---
> 
>  .../devicetree/bindings/pci/rockchip-pcie.txt      | 11 ++--

Acked-by: Rob Herring <robh at kernel.org>

>  drivers/pci/host/pcie-rockchip.c                   | 62 ++++++++++++++++++++++
>  2 files changed, 70 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> index ba67b39..71aeda1 100644
> --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> @@ -26,13 +26,16 @@ Required properties:
>  	- "sys"
>  	- "legacy"
>  	- "client"
> -- resets: Must contain five entries for each entry in reset-names.
> +- resets: Must contain seven entries for each entry in reset-names.
>  	   See ../reset/reset.txt for details.
>  - reset-names: Must include the following names
>  	- "core"
>  	- "mgmt"
>  	- "mgmt-sticky"
>  	- "pipe"
> +	- "pm"
> +	- "aclk"
> +	- "pclk"
>  - pinctrl-names : The pin control state names
>  - pinctrl-0: The "default" pinctrl state
>  - #interrupt-cells: specifies the number of cells needed to encode an
> @@ -86,8 +89,10 @@ pcie0: pcie at f8000000 {
>  	reg = <0x0 0xf8000000 0x0 0x2000000>, <0x0 0xfd000000 0x0 0x1000000>;
>  	reg-names = "axi-base", "apb-base";
>  	resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
> -		 <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE>;
> -	reset-names = "core", "mgmt", "mgmt-sticky", "pipe";
> +		 <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE> ,
> +		 <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>, <&cru SRST_A_PCIE>;
> +	reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
> +		      "pm", "pclk", "aclk";
>  	phys = <&pcie_phy>;
>  	phy-names = "pcie-phy";
>  	pinctrl-names = "default";
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index e0b22da..e04f69b 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -190,6 +190,9 @@ struct rockchip_pcie {
>  	struct	reset_control *mgmt_rst;
>  	struct	reset_control *mgmt_sticky_rst;
>  	struct	reset_control *pipe_rst;
> +	struct	reset_control *pm_rst;
> +	struct	reset_control *aclk_rst;
> +	struct	reset_control *pclk_rst;
>  	struct	clk *aclk_pcie;
>  	struct	clk *aclk_perf_pcie;
>  	struct	clk *hclk_pcie;
> @@ -408,6 +411,44 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>  
>  	gpiod_set_value(rockchip->ep_gpio, 0);
>  
> +	err = reset_control_assert(rockchip->aclk_rst);
> +	if (err) {
> +		dev_err(dev, "assert aclk_rst err %d\n", err);
> +		return err;
> +	}
> +
> +	err = reset_control_assert(rockchip->pclk_rst);
> +	if (err) {
> +		dev_err(dev, "assert pclk_rst err %d\n", err);
> +		return err;
> +	}
> +
> +	err = reset_control_assert(rockchip->pm_rst);
> +	if (err) {
> +		dev_err(dev, "assert pm_rst err %d\n", err);
> +		return err;
> +	}
> +
> +	udelay(10);
> +
> +	err = reset_control_deassert(rockchip->pm_rst);
> +	if (err) {
> +		dev_err(dev, "deassert pm_rst err %d\n", err);
> +		return err;
> +	}
> +
> +	err = reset_control_deassert(rockchip->aclk_rst);
> +	if (err) {
> +		dev_err(dev, "deassert mgmt_sticky_rst err %d\n", err);
> +		return err;
> +	}
> +
> +	err = reset_control_deassert(rockchip->pclk_rst);
> +	if (err) {
> +		dev_err(dev, "deassert mgmt_sticky_rst err %d\n", err);
> +		return err;
> +	}
> +
>  	err = phy_init(rockchip->phy);
>  	if (err < 0) {
>  		dev_err(dev, "fail to init phy, err %d\n", err);
> @@ -781,6 +822,27 @@ static int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
>  		return PTR_ERR(rockchip->pipe_rst);
>  	}
>  
> +	rockchip->pm_rst = devm_reset_control_get(dev, "pm");
> +	if (IS_ERR(rockchip->pm_rst)) {
> +		if (PTR_ERR(rockchip->pm_rst) != -EPROBE_DEFER)
> +			dev_err(dev, "missing pm reset property in node\n");
> +		return PTR_ERR(rockchip->pm_rst);
> +	}
> +
> +	rockchip->pclk_rst = devm_reset_control_get(dev, "pclk");
> +	if (IS_ERR(rockchip->pclk_rst)) {
> +		if (PTR_ERR(rockchip->pclk_rst) != -EPROBE_DEFER)
> +			dev_err(dev, "missing pclk reset property in node\n");
> +		return PTR_ERR(rockchip->pclk_rst);
> +	}
> +
> +	rockchip->aclk_rst = devm_reset_control_get(dev, "aclk");
> +	if (IS_ERR(rockchip->aclk_rst)) {
> +		if (PTR_ERR(rockchip->aclk_rst) != -EPROBE_DEFER)
> +			dev_err(dev, "missing aclk reset property in node\n");
> +		return PTR_ERR(rockchip->aclk_rst);
> +	}
> +
>  	rockchip->ep_gpio = devm_gpiod_get(dev, "ep", GPIOD_OUT_HIGH);
>  	if (IS_ERR(rockchip->ep_gpio)) {
>  		dev_err(dev, "missing ep-gpios property in node\n");
> -- 
> 2.3.7
> 
> 


From haihao.xiang at intel.com  Thu Oct 27 08:03:42 2016
From: haihao.xiang at intel.com (Xiang, Haihao)
Date: Thu, 27 Oct 2016 15:03:42 +0000
Subject: How to implement a EGL or DRM display in VA-API driver
In-Reply-To: <8cbe53b0-29af-bb45-7895-6e0a6c23d024@rock-chips.com>
References: <8cbe53b0-29af-bb45-7895-6e0a6c23d024@rock-chips.com>
Message-ID: <9289A01B6775FB46847EB523F7DC186860933C03@SHSMSX103.ccr.corp.intel.com>

>-----Original Message-----
>From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
>Of Randy Li
>Sent: Monday, October 24, 2016 3:59 PM
>To: libva at lists.freedesktop.org
>Cc: gwenole.beauchesne at intel.com; dri-devel at lists.freedesktop.org; linux-
>rockchip at lists.infradead.org; Jaquez, VictorX <victorx.jaquez at intel.com>;
>eddie.cai <eddie.cai at rock-chips.com>; ??? <alpha.lin at rock-chips.com>;
>herman.chen at rock-chips.com; vjaquez at igalia.com
>Subject: How to implement a EGL or DRM display in VA-API driver
>
>Hello:
>   I am going to implement a EGL and DRM display for Rockchip VA-API driver.
>We do have a EGL implementation in Rockchip VA-API driver, but it is
>implemented in the standard way, we did that as a X11 display.
>   I didn't see the usage of struct VADriverVTableEGL in gstreamer, and I have
>no idea about where should I implement something functions like
>eglExportDRMImageMESA().

VADriverVTableEGL is deprecated in libva, we has a more efficient way to use vaapi and egl.
You can refer to the examples in libyami-utils (https://github.com/01org/libyami-utils.git) for 
how to use vaapi and egl.

>   The DRM seems more complex, the reason I want to use the DRM is that,
>GPU would not work with the 4K video rendering, so the DRM means that
>directly output the video into video controller in our platform. But still have no
>idea what kind of thing I should implement in the VA-API driver. It seems that
>the VA-API base library would open a DRM instance for the driver, but leaving
>those configure for connector, encoder, planes to VA-API driver?

configure for connector, encoder, planes aren't a part of va-api driver.  You should check libdrm and drm/i915.
You can refer to the test case of modetest in libdrm (git.freedesktop.org/git/mesa/drm)


>   Could you guys give me same sample code or example of those kind of
>display in VA-API or the documents would help(I would not image there is a
>VA-API documents)
>
>--
>Randy Li
>The third produce department
>
>_______________________________________________
>dri-devel mailing list
>dri-devel at lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel

From randy.li at rock-chips.com  Thu Oct 27 19:05:29 2016
From: randy.li at rock-chips.com (Randy Li)
Date: Fri, 28 Oct 2016 10:05:29 +0800
Subject: How to implement a EGL or DRM display in VA-API driver
In-Reply-To: <9289A01B6775FB46847EB523F7DC186860933C03@SHSMSX103.ccr.corp.intel.com>
References: <8cbe53b0-29af-bb45-7895-6e0a6c23d024@rock-chips.com>
 <9289A01B6775FB46847EB523F7DC186860933C03@SHSMSX103.ccr.corp.intel.com>
Message-ID: <d6924234-8490-cf4a-282d-cc3f5fa291af@rock-chips.com>



On 10/27/2016 11:03 PM, Xiang, Haihao wrote:
>> -----Original Message-----
>> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
>> Of Randy Li
>> Sent: Monday, October 24, 2016 3:59 PM
>> To: libva at lists.freedesktop.org
>> Cc: gwenole.beauchesne at intel.com; dri-devel at lists.freedesktop.org; linux-
>> rockchip at lists.infradead.org; Jaquez, VictorX <victorx.jaquez at intel.com>;
>> eddie.cai <eddie.cai at rock-chips.com>; ??? <alpha.lin at rock-chips.com>;
>> herman.chen at rock-chips.com; vjaquez at igalia.com
>> Subject: How to implement a EGL or DRM display in VA-API driver
>>
>> Hello:
>>   I am going to implement a EGL and DRM display for Rockchip VA-API driver.
>> We do have a EGL implementation in Rockchip VA-API driver, but it is
>> implemented in the standard way, we did that as a X11 display.
>>   I didn't see the usage of struct VADriverVTableEGL in gstreamer, and I have
>> no idea about where should I implement something functions like
>> eglExportDRMImageMESA().
>
> VADriverVTableEGL is deprecated in libva, we has a more efficient way to use vaapi and egl.
> You can refer to the examples in libyami-utils (https://github.com/01org/libyami-utils.git) for
> how to use vaapi and egl.
I see, thank you.
>
>>   The DRM seems more complex, the reason I want to use the DRM is that,
>> GPU would not work with the 4K video rendering, so the DRM means that
>> directly output the video into video controller in our platform. But still have no
>> idea what kind of thing I should implement in the VA-API driver. It seems that
>> the VA-API base library would open a DRM instance for the driver, but leaving
>> those configure for connector, encoder, planes to VA-API driver?
About the DRM, I have implemented a version which pretends a X output, I 
would like to know a better way.
>
> configure for connector, encoder, planes aren't a part of va-api driver.  You should check libdrm and drm/i915.
> You can refer to the test case of modetest in libdrm (git.freedesktop.org/git/mesa/drm)
>
>
>>   Could you guys give me same sample code or example of those kind of
>> display in VA-API or the documents would help(I would not image there is a
>> VA-API documents)
>>
>> --
>> Randy Li
>> The third produce department
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

-- 
Randy Li
The third produce department
===========================================================================
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===========================================================================



From heiko at sntech.de  Fri Oct 28 01:31:00 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 28 Oct 2016 10:31:00 +0200
Subject: [PATCH] phy-rockchip-pcie: remove deassert of phy_rst from exit
 callback
In-Reply-To: <1476333733-9696-1-git-send-email-shawn.lin@rock-chips.com>
References: <1476333733-9696-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <2348307.ygIaYT7LcH@phil>

Am Donnerstag, 13. Oktober 2016, 12:42:13 CEST schrieb Shawn Lin:
> The deassert of phy_rst from exit callback is incorrect as when
> doing phy_exit, we expect the phy_rst is on asserted state which was
> done by power_off callback, but not deasserted state. Meanwhile when
> disabling clk_pciephy_ref, the assert/deassert signal can't actually
> take effect on the phy. So let's fix it anyway.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

looks ok to have that removed, as any future phy_init call will make sure it 
gets asserted anyway.

Reviewed-by: Heiko Stuebner <heiko at sntech.de>



From shawn.lin at rock-chips.com  Fri Oct 28 02:11:59 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Fri, 28 Oct 2016 17:11:59 +0800
Subject: [PATCH] drm/rockchip: analogix_dp: add supports for regulators in
 edp IP
In-Reply-To: <1477163933-13140-1-git-send-email-ayaka@soulik.info>
References: <1477163933-13140-1-git-send-email-ayaka@soulik.info>
Message-ID: <6d050f06-996f-5ecc-20f9-587299ee34c7@rock-chips.com>

On 2016/10/23 3:18, Randy Li wrote:
> I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
> RK3288, once trying to enable the pclk clock, the kernel would dead.
> This patch would try to enable them first. The eDP_AVDD_1V8 more
> likely to be applied to eDP phy, but I have no time to confirmed
> it yet.

Comfirm it or at least someone should be able to answer your
question, Mark?

Have you considered to add some details about vcc-supply and vccio-
supply for your analogix_dp-rockchip.txt ?

 From your commit msg, these two properties are more likely to be
required but the code itself tell me them should be optional(from the
point of backward compatibility, it should also be optinoal).

>
> Signed-off-by: Randy Li <ayaka at soulik.info>
> ---
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 8548e82..6bf0441 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -17,6 +17,7 @@
>  #include <linux/of_device.h>
>  #include <linux/of_graph.h>
>  #include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
>  #include <linux/reset.h>
>  #include <linux/clk.h>
>
> @@ -70,6 +71,7 @@ struct rockchip_dp_device {
>  	struct clk               *grfclk;
>  	struct regmap            *grf;
>  	struct reset_control     *rst;
> +	struct regulator_bulk_data supplies[2];
>
>  	struct work_struct	 psr_work;
>  	spinlock_t		 psr_lock;
> @@ -146,6 +148,13 @@ static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
>
>  	cancel_work_sync(&dp->psr_work);
>
> +	ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
> +			dp->supplies);
> +	if (ret) {
> +		dev_err(dp->dev, "failed to enable vdd supply %d\n", ret);
> +		return ret;
> +	}
> +
>  	ret = clk_prepare_enable(dp->pclk);
>  	if (ret < 0) {
>  		dev_err(dp->dev, "failed to enable pclk %d\n", ret);
> @@ -168,6 +177,9 @@ static int rockchip_dp_powerdown(struct analogix_dp_plat_data *plat_data)
>
>  	clk_disable_unprepare(dp->pclk);
>
> +	regulator_bulk_disable(ARRAY_SIZE(dp->supplies),
> +			dp->supplies);
> +
>  	return 0;
>  }
>
> @@ -323,6 +335,19 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
>  		return PTR_ERR(dp->rst);
>  	}
>
> +	dp->supplies[0].supply = "vcc";
> +	dp->supplies[1].supply = "vccio";
> +	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dp->supplies),
> +			dp->supplies);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to get regulators: %d\n", ret);
> +	}
> +	ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
> +			dp->supplies);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to enable regulators: %d\n", ret);
> +	}
> +
>  	ret = clk_prepare_enable(dp->pclk);
>  	if (ret < 0) {
>  		dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>


-- 
Best Regards
Shawn Lin



From heiko at sntech.de  Fri Oct 28 02:18:47 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 28 Oct 2016 11:18:47 +0200
Subject: [GIT PULL] rockchip clock fixes for 4.9-rc
Message-ID: <2723813.N9JiJ3CpWT@phil>

Hi Mike, Stephen,

please find below one small fix to the newly introduced ddrclk type.

Thanks
Heiko

The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:

  Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.9-rockchip-clkfixes1

for you to fetch changes up to 4a262b14c57d6ec88982d40273e742f7b9151560:

  clk: rockchip: don't return NULL when failing to register ddrclk branch (2016-10-16 02:39:58 +0200)

----------------------------------------------------------------
Fix return value in error case of new ddrclk type.

----------------------------------------------------------------
Shawn Lin (1):
      clk: rockchip: don't return NULL when failing to register ddrclk branch

 drivers/clk/rockchip/clk-ddr.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)



From heiko at sntech.de  Fri Oct 28 02:22:20 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 28 Oct 2016 11:22:20 +0200
Subject: [GIT PULL] Rockchip dts64 fixes for 4.9-rc
Message-ID: <2007497.qXCdMDh9Wq@phil>

Hi Arnd, Kevin, Olof,

please find below two fixes for 64bit Rockchip boards. One makes
binds/unbinds fail and the other drops one unnecessary property.

Please pull.
Thanks
Heiko

The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:

  Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.9-rockchip-dts64-fixes1

for you to fetch changes up to 7c6273194445fe1316084d3096f9311c3dfa4da6:

  arm64: dts: rockchip: remove the abuse of keep-power-in-suspend (2016-10-18 20:03:54 +0200)

----------------------------------------------------------------
Correct regulator handling on Rockchip arm64 boards to make
bind/unbind calls work correctly and remove a sdio-only
property from non-sdio mmc hosts, that accidentially was
added there.

----------------------------------------------------------------
Shawn Lin (2):
      arm64: dts: rockchip: remove always-on and boot-on from vcc_sd
      arm64: dts: rockchip: remove the abuse of keep-power-in-suspend

 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts        | 3 ---
 arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts | 4 ----
 2 files changed, 7 deletions(-)



From randy.li at rock-chips.com  Fri Oct 28 02:29:15 2016
From: randy.li at rock-chips.com (Randy Li)
Date: Fri, 28 Oct 2016 17:29:15 +0800
Subject: [PATCH] drm/rockchip: analogix_dp: add supports for regulators in
 edp IP
In-Reply-To: <6d050f06-996f-5ecc-20f9-587299ee34c7@rock-chips.com>
References: <1477163933-13140-1-git-send-email-ayaka@soulik.info>
 <6d050f06-996f-5ecc-20f9-587299ee34c7@rock-chips.com>
Message-ID: <16dfbe16-eae7-8da9-4108-07e623210d35@rock-chips.com>



On 10/28/2016 05:11 PM, Shawn Lin wrote:
> On 2016/10/23 3:18, Randy Li wrote:
>> I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
>> RK3288, once trying to enable the pclk clock, the kernel would dead.
>> This patch would try to enable them first. The eDP_AVDD_1V8 more
>> likely to be applied to eDP phy, but I have no time to confirmed
>> it yet.
>
> Comfirm it or at least someone should be able to answer your
> question, Mark?
I just forget to ask the IC department, the TRM didn't cover that.
>
> Have you considered to add some details about vcc-supply and vccio-
> supply for your analogix_dp-rockchip.txt ?
>
> From your commit msg, these two properties are more likely to be
> required but the code itself tell me them should be optional(from the
> point of backward compatibility, it should also be optinoal).
Yes, I keep it optional for the same reason. Most of boards won't turn 
off those power supply and may use some fixed regulators.
>
>>
>> Signed-off-by: Randy Li <ayaka at soulik.info>
>> ---
>>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25
>> +++++++++++++++++++++++++
>>  1 file changed, 25 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> index 8548e82..6bf0441 100644
>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> @@ -17,6 +17,7 @@
>>  #include <linux/of_device.h>
>>  #include <linux/of_graph.h>
>>  #include <linux/regmap.h>
>> +#include <linux/regulator/consumer.h>
>>  #include <linux/reset.h>
>>  #include <linux/clk.h>
>>
>> @@ -70,6 +71,7 @@ struct rockchip_dp_device {
>>      struct clk               *grfclk;
>>      struct regmap            *grf;
>>      struct reset_control     *rst;
>> +    struct regulator_bulk_data supplies[2];
>>
>>      struct work_struct     psr_work;
>>      spinlock_t         psr_lock;
>> @@ -146,6 +148,13 @@ static int rockchip_dp_poweron(struct
>> analogix_dp_plat_data *plat_data)
>>
>>      cancel_work_sync(&dp->psr_work);
>>
>> +    ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>> +            dp->supplies);
>> +    if (ret) {
>> +        dev_err(dp->dev, "failed to enable vdd supply %d\n", ret);
>> +        return ret;
>> +    }
>> +
>>      ret = clk_prepare_enable(dp->pclk);
>>      if (ret < 0) {
>>          dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>> @@ -168,6 +177,9 @@ static int rockchip_dp_powerdown(struct
>> analogix_dp_plat_data *plat_data)
>>
>>      clk_disable_unprepare(dp->pclk);
>>
>> +    regulator_bulk_disable(ARRAY_SIZE(dp->supplies),
>> +            dp->supplies);
>> +
>>      return 0;
>>  }
>>
>> @@ -323,6 +335,19 @@ static int rockchip_dp_init(struct
>> rockchip_dp_device *dp)
>>          return PTR_ERR(dp->rst);
>>      }
>>
>> +    dp->supplies[0].supply = "vcc";
>> +    dp->supplies[1].supply = "vccio";
>> +    ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dp->supplies),
>> +            dp->supplies);
>> +    if (ret < 0) {
>> +        dev_err(dev, "failed to get regulators: %d\n", ret);
>> +    }
>> +    ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>> +            dp->supplies);
>> +    if (ret < 0) {
>> +        dev_err(dev, "failed to enable regulators: %d\n", ret);
>> +    }
>> +
>>      ret = clk_prepare_enable(dp->pclk);
>>      if (ret < 0) {
>>          dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>
>
>

-- 
Randy Li
The third produce department
===========================================================================
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===========================================================================



From olof at lixom.net  Sat Oct 29 11:10:44 2016
From: olof at lixom.net (Olof Johansson)
Date: Sat, 29 Oct 2016 11:10:44 -0700
Subject: [GIT PULL] Rockchip dts64 fixes for 4.9-rc
In-Reply-To: <2007497.qXCdMDh9Wq@phil>
References: <2007497.qXCdMDh9Wq@phil>
Message-ID: <20161029181044.GD4195@localhost>

On Fri, Oct 28, 2016 at 11:22:20AM +0200, Heiko Stuebner wrote:
> Hi Arnd, Kevin, Olof,
> 
> please find below two fixes for 64bit Rockchip boards. One makes
> binds/unbinds fail and the other drops one unnecessary property.
> 
> Please pull.
> Thanks
> Heiko
> 
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
> 
>   Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.9-rockchip-dts64-fixes1
> 
> for you to fetch changes up to 7c6273194445fe1316084d3096f9311c3dfa4da6:
> 
>   arm64: dts: rockchip: remove the abuse of keep-power-in-suspend (2016-10-18 20:03:54 +0200)
> 
> ----------------------------------------------------------------
> Correct regulator handling on Rockchip arm64 boards to make
> bind/unbind calls work correctly and remove a sdio-only
> property from non-sdio mmc hosts, that accidentially was
> added there.
> 
> ----------------------------------------------------------------
> Shawn Lin (2):
>       arm64: dts: rockchip: remove always-on and boot-on from vcc_sd
>       arm64: dts: rockchip: remove the abuse of keep-power-in-suspend

Merged, thanks.


-Olof


From xzy.xu at rock-chips.com  Sat Oct 29 19:57:25 2016
From: xzy.xu at rock-chips.com (Ziyuan Xu)
Date: Sun, 30 Oct 2016 10:57:25 +0800
Subject: [PATCH] arm64: dts: rockchip: add cpu-id nvmem cell node for rk3399
Message-ID: <20161030025725.32155-1-xzy.xu@rock-chips.com>

There is a 'cpu-id' field in efuse, export it for other drivers
reference.

Signed-off-by: Ziyuan Xu <xzy.xu at rock-chips.com>
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 76b2864..71c3ce7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1023,6 +1023,9 @@
 		clock-names = "pclk_efuse";
 
 		/* Data cells */
+		cpu_id: cpu-id {
+			reg = <0x07 0x10>;
+		};
 		cpub_leakage: cpu-leakage at 17 {
 			reg = <0x17 0x1>;
 		};
-- 
2.9.3




From zhengxing at rock-chips.com  Mon Oct 31 20:22:06 2016
From: zhengxing at rock-chips.com (Xing Zheng)
Date: Tue,  1 Nov 2016 11:22:06 +0800
Subject: [PATCH] clk: rockchip: optimize the configuration for 800MHz and 1GHz
 on RK3399
Message-ID: <1477970526-26388-1-git-send-email-zhengxing@rock-chips.com>

Usually, the 800MHz and 1GHz are supplied for CPLL and NPLL in the RK3399.
But dues to the carelessly copying from RK3036 when the RK3399 bringing up,
the refdiv == 6, it will increase the lock time, and it is not an optimal
configuration.

Please let's fix them for the lock time and jitter are lower:
800 MHz:
- FVCO == 2.4 GHz, revdiv == 1.
1 GHz:
- FVCO == 3 GHz, revdiv == 1.

Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
---

 drivers/clk/rockchip/clk-rk3399.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3399.c b/drivers/clk/rockchip/clk-rk3399.c
index a5a3f41..28aff45 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -77,7 +77,7 @@ static struct rockchip_pll_rate_table rk3399_pll_rates[] = {
 	RK3036_PLL_RATE(1104000000, 1, 46, 1, 1, 1, 0),
 	RK3036_PLL_RATE(1100000000, 12, 550, 1, 1, 1, 0),
 	RK3036_PLL_RATE(1008000000, 1, 84, 2, 1, 1, 0),
-	RK3036_PLL_RATE(1000000000, 6, 500, 2, 1, 1, 0),
+	RK3036_PLL_RATE(1000000000, 1, 125, 3, 1, 1, 0),
 	RK3036_PLL_RATE( 984000000, 1, 82, 2, 1, 1, 0),
 	RK3036_PLL_RATE( 960000000, 1, 80, 2, 1, 1, 0),
 	RK3036_PLL_RATE( 936000000, 1, 78, 2, 1, 1, 0),
@@ -87,7 +87,7 @@ static struct rockchip_pll_rate_table rk3399_pll_rates[] = {
 	RK3036_PLL_RATE( 864000000, 1, 72, 2, 1, 1, 0),
 	RK3036_PLL_RATE( 840000000, 1, 70, 2, 1, 1, 0),
 	RK3036_PLL_RATE( 816000000, 1, 68, 2, 1, 1, 0),
-	RK3036_PLL_RATE( 800000000, 6, 400, 2, 1, 1, 0),
+	RK3036_PLL_RATE( 800000000, 1, 100, 3, 1, 1, 0),
 	RK3036_PLL_RATE( 700000000, 6, 350, 2, 1, 1, 0),
 	RK3036_PLL_RATE( 696000000, 1, 58, 2, 1, 1, 0),
 	RK3036_PLL_RATE( 676000000, 3, 169, 2, 1, 1, 0),
-- 
2.7.4




