[PATCH 1/2] clk: sunxi-ng: Provide a default reset hook

[PATCH 1/2] clk: sunxi-ng: Provide a default reset hook

[Maxime Ripard]

The reset hook was left implemented. Provide a dumb implementation so that
client drivers can depend on it.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/clk/sunxi-ng/ccu_reset.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu_reset.c b/drivers/clk/sunxi-ng/ccu_reset.c
index 6c31d48783a7..1dc4e98ea802 100644
--- a/drivers/clk/sunxi-ng/ccu_reset.c
+++ b/drivers/clk/sunxi-ng/ccu_reset.c
@@ -8,6 +8,7 @@
  * the License, or (at your option) any later version.
  */
 
+#include <linux/delay.h>
 #include <linux/io.h>
 #include <linux/reset-controller.h>
 
@@ -49,7 +50,18 @@ static int ccu_reset_deassert(struct reset_controller_dev *rcdev,
 	return 0;
 }
 
+static int ccu_reset_reset(struct reset_controller_dev *rcdev,
+			   unsigned long id)
+{
+	ccu_reset_assert(rcdev, id);
+	udelay(10);
+	ccu_reset_deassert(rcdev, id);
+
+	return 0;
+}
+
 const struct reset_control_ops ccu_reset_ops = {
 	.assert		= ccu_reset_assert,
 	.deassert	= ccu_reset_deassert,
+	.reset		= ccu_reset_reset,
 };
-- 
2.13.5

[PATCH 2/2] mmc: sunxi: Reset the device at probe time

[Maxime Ripard]

We might be into some troubles if the bootloader misconfigured the MMC
controller.

We currently only de-assert the reset line at probe time, which means that
if the device was already out of reset, we're going to keep whatever state
was set already.

Switch to a reset instead of the deassert to have a device in a pristine
state when we start operating.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/mmc/host/sunxi-mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index da5f46a14497..53c970fe0873 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -1242,7 +1242,7 @@ static int sunxi_mmc_resource_request(struct sunxi_mmc_host *host,
 	}
 
 	if (!IS_ERR(host->reset)) {
-		ret = reset_control_deassert(host->reset);
+		ret = reset_control_reset(host->reset);
 		if (ret) {
 			dev_err(&pdev->dev, "reset err %d\n", ret);
 			goto error_disable_clk_sample;
-- 
2.13.5

[PATCH 2/2] mmc: sunxi: Reset the device at probe time

[Ulf Hansson]

On 25 August 2017 at 11:49, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> We might be into some troubles if the bootloader misconfigured the MMC
> controller.
>
> We currently only de-assert the reset line at probe time, which means that
> if the device was already out of reset, we're going to keep whatever state
> was set already.
>
> Switch to a reset instead of the deassert to have a device in a pristine
> state when we start operating.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/sunxi-mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index da5f46a14497..53c970fe0873 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -1242,7 +1242,7 @@ static int sunxi_mmc_resource_request(struct sunxi_mmc_host *host,
>         }
>
>         if (!IS_ERR(host->reset)) {
> -               ret = reset_control_deassert(host->reset);
> +               ret = reset_control_reset(host->reset);
>                 if (ret) {
>                         dev_err(&pdev->dev, "reset err %d\n", ret);
>                         goto error_disable_clk_sample;
> --
> 2.13.5
>

[PATCH 1/2] clk: sunxi-ng: Provide a default reset hook

[icenowy at aosc.io]

? 2017-08-25 17:49?Maxime Ripard ???
> The reset hook was left implemented. Provide a dumb implementation so 
> that
> client drivers can depend on it.

I think some clients should also convert to use this.

For example:

- The TCON driver in sun4i-drm. (It now uses reset_control_status, but
   this is also not implemented in CCU.)
- The EPHY in dwmac-sun8i driver. (It uses explicit assert then 
deassert)

P.S. maybe the status hook should also be implemented?

> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  drivers/clk/sunxi-ng/ccu_reset.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu_reset.c 
> b/drivers/clk/sunxi-ng/ccu_reset.c
> index 6c31d48783a7..1dc4e98ea802 100644
> --- a/drivers/clk/sunxi-ng/ccu_reset.c
> +++ b/drivers/clk/sunxi-ng/ccu_reset.c
> @@ -8,6 +8,7 @@
>   * the License, or (at your option) any later version.
>   */
> 
> +#include <linux/delay.h>
>  #include <linux/io.h>
>  #include <linux/reset-controller.h>
> 
> @@ -49,7 +50,18 @@ static int ccu_reset_deassert(struct
> reset_controller_dev *rcdev,
>  	return 0;
>  }
> 
> +static int ccu_reset_reset(struct reset_controller_dev *rcdev,
> +			   unsigned long id)
> +{
> +	ccu_reset_assert(rcdev, id);
> +	udelay(10);
> +	ccu_reset_deassert(rcdev, id);
> +
> +	return 0;
> +}
> +
>  const struct reset_control_ops ccu_reset_ops = {
>  	.assert		= ccu_reset_assert,
>  	.deassert	= ccu_reset_deassert,
> +	.reset		= ccu_reset_reset,
>  };

[PATCH 1/2] clk: sunxi-ng: Provide a default reset hook

[Chen-Yu Tsai]

On Sun, Aug 27, 2017 at 9:01 PM,  <icenowy@aosc.io> wrote:
> ? 2017-08-25 17:49?Maxime Ripard ???
>>
>> The reset hook was left implemented. Provide a dumb implementation so that
>> client drivers can depend on it.
>
>
> I think some clients should also convert to use this.
>
> For example:
>
> - The TCON driver in sun4i-drm. (It now uses reset_control_status, but
>   this is also not implemented in CCU.)

I have patches for both sides of this.

> - The EPHY in dwmac-sun8i driver. (It uses explicit assert then deassert)
>
> P.S. maybe the status hook should also be implemented?

Yes.

ChenYu

[PATCH 1/2] clk: sunxi-ng: Provide a default reset hook

[Ulf Hansson]

On 25 August 2017 at 11:49, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The reset hook was left implemented. Provide a dumb implementation so that
> client drivers can depend on it.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Do you want me to pick this up via my mmc tree? If so, is that okay by
the clock maintainers?

Kind regards
Uffe

> ---
>  drivers/clk/sunxi-ng/ccu_reset.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_reset.c b/drivers/clk/sunxi-ng/ccu_reset.c
> index 6c31d48783a7..1dc4e98ea802 100644
> --- a/drivers/clk/sunxi-ng/ccu_reset.c
> +++ b/drivers/clk/sunxi-ng/ccu_reset.c
> @@ -8,6 +8,7 @@
>   * the License, or (at your option) any later version.
>   */
>
> +#include <linux/delay.h>
>  #include <linux/io.h>
>  #include <linux/reset-controller.h>
>
> @@ -49,7 +50,18 @@ static int ccu_reset_deassert(struct reset_controller_dev *rcdev,
>         return 0;
>  }
>
> +static int ccu_reset_reset(struct reset_controller_dev *rcdev,
> +                          unsigned long id)
> +{
> +       ccu_reset_assert(rcdev, id);
> +       udelay(10);
> +       ccu_reset_deassert(rcdev, id);
> +
> +       return 0;
> +}
> +
>  const struct reset_control_ops ccu_reset_ops = {
>         .assert         = ccu_reset_assert,
>         .deassert       = ccu_reset_deassert,
> +       .reset          = ccu_reset_reset,
>  };
> --
> 2.13.5
>

[PATCH 1/2] clk: sunxi-ng: Provide a default reset hook

[Maxime Ripard]

Hi Ulf,

On Wed, Aug 30, 2017 at 02:29:24PM +0200, Ulf Hansson wrote:
> On 25 August 2017 at 11:49, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The reset hook was left implemented. Provide a dumb implementation so that
> > client drivers can depend on it.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> 
> Do you want me to pick this up via my mmc tree? If so, is that okay by
> the clock maintainers?

I also happen to be the maintainer of that part of the kernel
(reporting to Mike and Stephen of course). We don't have anything
touching that file in next, so unless they feel like it should go
through their tree, it would be easier to keep the two changes
together and merge them through your tree.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170830/d85947be/attachment-0001.sig>

[PATCH 1/2] clk: sunxi-ng: Provide a default reset hook

[Ulf Hansson]

On 30 August 2017 at 14:36, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi Ulf,
>
> On Wed, Aug 30, 2017 at 02:29:24PM +0200, Ulf Hansson wrote:
>> On 25 August 2017 at 11:49, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > The reset hook was left implemented. Provide a dumb implementation so that
>> > client drivers can depend on it.
>> >
>> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>
>> Do you want me to pick this up via my mmc tree? If so, is that okay by
>> the clock maintainers?
>
> I also happen to be the maintainer of that part of the kernel
> (reporting to Mike and Stephen of course). We don't have anything
> touching that file in next, so unless they feel like it should go
> through their tree, it would be easier to keep the two changes
> together and merge them through your tree.

Alright, I have picked it up for next!

Kind regards
Uffe

[PATCH 1/2] clk: sunxi-ng: Provide a default reset hook

[Stephen Boyd]

On 08/30, Ulf Hansson wrote:
> On 30 August 2017 at 14:36, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi Ulf,
> >
> > On Wed, Aug 30, 2017 at 02:29:24PM +0200, Ulf Hansson wrote:
> >> On 25 August 2017 at 11:49, Maxime Ripard
> >> <maxime.ripard@free-electrons.com> wrote:
> >> > The reset hook was left implemented. Provide a dumb implementation so that
> >> > client drivers can depend on it.
> >> >
> >> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >>
> >> Do you want me to pick this up via my mmc tree? If so, is that okay by
> >> the clock maintainers?
> >
> > I also happen to be the maintainer of that part of the kernel
> > (reporting to Mike and Stephen of course). We don't have anything
> > touching that file in next, so unless they feel like it should go
> > through their tree, it would be easier to keep the two changes
> > together and merge them through your tree.
> 
> Alright, I have picked it up for next!
> 

Thanks!

Acked-by: Stephen Boyd <sboyd@codeaurora.org>

if that helps.

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