Re: [PATCH] ARM: dts: stm32: Reinstate card detect behavior on DHSOM

2020-10-28 Thread Marek Vasut 
On 10/28/20 11:20 AM, Patrick DELAUNAY wrote:
> Hi Marek,

Hello Patrick,

[...]

>>> But after investigation the internall pull-up is not configurated in
>>> stm32 pinctrol (cheked with pinmux command) even it is requested in device-
>> tree of EV1/DK2.
>>>
>>> It is clearly a bug (I isolate the issue) and I am working on a patch
>>> (it  should be sent to u-boot mailing liste next week).
>>>
 btw it is bugged in SPL.
>>>
>>> Ah, what is the issue.
>>>
>>> In the stm32 driver or in the framework ?
>>>
>>> I will cross-check it also on EV1/DK2.
>>
>> The card is not detected in SPL again, same fail mode as before.
>> Now that I think about it, note to self, I should check whether the CD GPIO
>> controller node is u-boot,dm-spl
> 
> I found a big issue in stm32 pincontrol: the bias configuration was only 
> managed for ouput pin.
> 
> With this serie [1], I checked the pull-up configuration (including in SPL by 
> adding a  debug trace).
> 
> With [2], the bias configuration is now correct in DK2 / EV1 boards (even if 
> the pull-up configuration is not mandatory,
> because I don't see cart detection issue on ST board).
> 
> I expect this patch correct the DHSOM issue.

It does not, but the following does:
[PATCH] ARM: dts: stm32: Fix uSD card-detect GPIO on DHCOM

So it's a bug on both ends, good thing we found them.

Thanks!

RE: [PATCH] ARM: dts: stm32: Reinstate card detect behavior on DHSOM

2020-10-28 Thread Patrick DELAUNAY 
Hi Marek,

> From: Marek Vasut 
> Sent: vendredi 23 octobre 2020 17:04
> 
> On 10/23/20 4:39 PM, Patrick DELAUNAY wrote:
> 
> Hi,
> 
> [...]
> 
>  From: Marek Vasut 
>  Sent: lundi 19 octobre 2020 23:38
> 
>  The cd-gpios with (GPIO_ACTIVE_LOW | GPIO_PULL_UP) gpio is thus far
>  unsupported, reinstate the old cd-gpios behavior until this
>  handling is fully implemented. This permits the DHSOM to boot from
>  SD again, without this patch the card detect fails.
> >>>
> >>> It is strange if it is not working... I will check why the
> >>> configuration is not managed correctly in stm32 gpio/pincontrol driver.
> >>>
>  Signed-off-by: Marek Vasut 
>  Cc: Patrick Delaunay 
>  Cc: Patrice Chotard 
>  ---
>   arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 3 +++
>   1 file changed, 3 insertions(+)
> 
>  diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>  b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>  index 92345b7ba3..73bb5f1c6d 100644
>  --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>  +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>  @@ -265,6 +265,9 @@
> 
>    {
>   u-boot,dm-spl;
>  +broken-cd;
>  +/delete-property/ cd-gpios;
>  +/delete-property/ disable-wp;
>   };
> 
>   _b4_pins_a {
>  --
>  2.28.0
> >>>
> >>> Reviewed-by: Patrick Delaunay 
> >>>
> >>> But I will be try to fix the issue before to accept this patch.
> >>>
> >>> I will merge it only if I can't found the root cause for v2020.01-rc2
> >>
> >> Do you not see the same behavior on EV/DK ?
> >
> > No but I think we have pull-up on board.
> >
> > But after investigation the internall pull-up is not configurated in
> > stm32 pinctrol (cheked with pinmux command) even it is requested in device-
> tree of EV1/DK2.
> >
> > It is clearly a bug (I isolate the issue) and I am working on a patch
> > (it  should be sent to u-boot mailing liste next week).
> >
> >> btw it is bugged in SPL.
> >
> > Ah, what is the issue.
> >
> > In the stm32 driver or in the framework ?
> >
> > I will cross-check it also on EV1/DK2.
> 
> The card is not detected in SPL again, same fail mode as before.
> Now that I think about it, note to self, I should check whether the CD GPIO
> controller node is u-boot,dm-spl

I found a big issue in stm32 pincontrol: the bias configuration was only 
managed for ouput pin.

With this serie [1], I checked the pull-up configuration (including in SPL by 
adding a  debug trace).

With [2], the bias configuration is now correct in DK2 / EV1 boards (even if 
the pull-up configuration is not mandatory,
because I don't see cart detection issue on ST board).

I expect this patch correct the DHSOM issue.

[1]: http://patchwork.ozlabs.org/project/uboot/list/?series=210501

[2]: patch [2/2] gpio: stm32: correct the bias management
  
http://patchwork.ozlabs.org/project/uboot/patch/20201028094908.11031-2-patrick.delau...@st.com/

Regards,

Patrick

Re: [PATCH] ARM: dts: stm32: Reinstate card detect behavior on DHSOM

2020-10-23 Thread Marek Vasut 
On 10/23/20 4:39 PM, Patrick DELAUNAY wrote:

Hi,

[...]

 From: Marek Vasut 
 Sent: lundi 19 octobre 2020 23:38

 The cd-gpios with (GPIO_ACTIVE_LOW | GPIO_PULL_UP) gpio is thus far
 unsupported, reinstate the old cd-gpios behavior until this handling
 is fully implemented. This permits the DHSOM to boot from SD again,
 without this patch the card detect fails.
>>>
>>> It is strange if it is not working... I will check why the
>>> configuration is not managed correctly in stm32 gpio/pincontrol driver.
>>>
 Signed-off-by: Marek Vasut 
 Cc: Patrick Delaunay 
 Cc: Patrice Chotard 
 ---
  arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 3 +++
  1 file changed, 3 insertions(+)

 diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
 b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
 index 92345b7ba3..73bb5f1c6d 100644
 --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
 +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
 @@ -265,6 +265,9 @@

   {
u-boot,dm-spl;
 +  broken-cd;
 +  /delete-property/ cd-gpios;
 +  /delete-property/ disable-wp;
  };

  _b4_pins_a {
 --
 2.28.0
>>>
>>> Reviewed-by: Patrick Delaunay 
>>>
>>> But I will be try to fix the issue before to accept this patch.
>>>
>>> I will merge it only if I can't found the root cause for v2020.01-rc2
>>
>> Do you not see the same behavior on EV/DK ?
> 
> No but I think we have pull-up on board.
> 
> But after investigation the internall pull-up is not configurated in stm32 
> pinctrol
> (cheked with pinmux command) even it is requested in device-tree of EV1/DK2.
> 
> It is clearly a bug (I isolate the issue) and I am working on a patch 
> (it  should be sent to u-boot mailing liste next week).
> 
>> btw it is bugged in SPL.
> 
> Ah, what is the issue.
> 
> In the stm32 driver or in the framework ?
> 
> I will cross-check it also on EV1/DK2.

The card is not detected in SPL again, same fail mode as before.
Now that I think about it, note to self, I should check whether the CD
GPIO controller node is u-boot,dm-spl .

RE: [PATCH] ARM: dts: stm32: Reinstate card detect behavior on DHSOM

2020-10-23 Thread Patrick DELAUNAY 
Hi,

> From: Marek Vasut 
> Sent: jeudi 22 octobre 2020 20:19
> To: Patrick DELAUNAY ; u-boot@lists.denx.de
> Cc: Patrice CHOTARD 
> Subject: Re: [PATCH] ARM: dts: stm32: Reinstate card detect behavior on
> DHSOM
> Importance: High
> 
> On 10/22/20 7:17 PM, Patrick DELAUNAY wrote:
> > Hi Marek,
> 
> Hi,
> 
> >> From: Marek Vasut 
> >> Sent: lundi 19 octobre 2020 23:38
> >>
> >> The cd-gpios with (GPIO_ACTIVE_LOW | GPIO_PULL_UP) gpio is thus far
> >> unsupported, reinstate the old cd-gpios behavior until this handling
> >> is fully implemented. This permits the DHSOM to boot from SD again,
> >> without this patch the card detect fails.
> >
> > It is strange if it is not working... I will check why the
> > configuration is not managed correctly in stm32 gpio/pincontrol driver.
> >
> >> Signed-off-by: Marek Vasut 
> >> Cc: Patrick Delaunay 
> >> Cc: Patrice Chotard 
> >> ---
> >>  arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> >> b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> >> index 92345b7ba3..73bb5f1c6d 100644
> >> --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> >> +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> >> @@ -265,6 +265,9 @@
> >>
> >>   {
> >>u-boot,dm-spl;
> >> +  broken-cd;
> >> +  /delete-property/ cd-gpios;
> >> +  /delete-property/ disable-wp;
> >>  };
> >>
> >>  _b4_pins_a {
> >> --
> >> 2.28.0
> >
> > Reviewed-by: Patrick Delaunay 
> >
> > But I will be try to fix the issue before to accept this patch.
> >
> > I will merge it only if I can't found the root cause for v2020.01-rc2
> 
> Do you not see the same behavior on EV/DK ?

No but I think we have pull-up on board.

But after investigation the internall pull-up is not configurated in stm32 
pinctrol
(cheked with pinmux command) even it is requested in device-tree of EV1/DK2.

It is clearly a bug (I isolate the issue) and I am working on a patch 
(it  should be sent to u-boot mailing liste next week).

> btw it is bugged in SPL.

Ah, what is the issue.

In the stm32 driver or in the framework ?

I will cross-check it also on EV1/DK2.

Patrick

Re: [PATCH] ARM: dts: stm32: Reinstate card detect behavior on DHSOM

2020-10-22 Thread Marek Vasut 
On 10/22/20 7:17 PM, Patrick DELAUNAY wrote:
> Hi Marek,

Hi,

>> From: Marek Vasut 
>> Sent: lundi 19 octobre 2020 23:38
>>
>> The cd-gpios with (GPIO_ACTIVE_LOW | GPIO_PULL_UP) gpio is thus far
>> unsupported, reinstate the old cd-gpios behavior until this handling is fully
>> implemented. This permits the DHSOM to boot from SD again, without this patch
>> the card detect fails.
> 
> It is strange if it is not working... I will check why the configuration is 
> not managed
> correctly in stm32 gpio/pincontrol driver.
> 
>> Signed-off-by: Marek Vasut 
>> Cc: Patrick Delaunay 
>> Cc: Patrice Chotard 
>> ---
>>  arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> index 92345b7ba3..73bb5f1c6d 100644
>> --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> @@ -265,6 +265,9 @@
>>
>>   {
>>  u-boot,dm-spl;
>> +broken-cd;
>> +/delete-property/ cd-gpios;
>> +/delete-property/ disable-wp;
>>  };
>>
>>  _b4_pins_a {
>> --
>> 2.28.0
> 
> Reviewed-by: Patrick Delaunay 
> 
> But I will be try to fix the issue before to accept this patch.
> 
> I will merge it only if I can't found the root cause for v2020.01-rc2

Do you not see the same behavior on EV/DK ?

btw it is bugged in SPL.

RE: [PATCH] ARM: dts: stm32: Reinstate card detect behavior on DHSOM

2020-10-22 Thread Patrick DELAUNAY 
Hi Marek,

> From: Marek Vasut 
> Sent: lundi 19 octobre 2020 23:38
> 
> The cd-gpios with (GPIO_ACTIVE_LOW | GPIO_PULL_UP) gpio is thus far
> unsupported, reinstate the old cd-gpios behavior until this handling is fully
> implemented. This permits the DHSOM to boot from SD again, without this patch
> the card detect fails.

It is strange if it is not working... I will check why the configuration is not 
managed
correctly in stm32 gpio/pincontrol driver.

> Signed-off-by: Marek Vasut 
> Cc: Patrick Delaunay 
> Cc: Patrice Chotard 
> ---
>  arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> index 92345b7ba3..73bb5f1c6d 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> @@ -265,6 +265,9 @@
> 
>   {
>   u-boot,dm-spl;
> + broken-cd;
> + /delete-property/ cd-gpios;
> + /delete-property/ disable-wp;
>  };
> 
>  _b4_pins_a {
> --
> 2.28.0

Reviewed-by: Patrick Delaunay 

But I will be try to fix the issue before to accept this patch.

I will merge it only if I can't found the root cause for v2020.01-rc2

Thanks

Patrick

RE: [PATCH] ARM: dts: stm32: Reinstate card detect behavior on DHSOM

2020-06-19 Thread Patrick DELAUNAY 
Dear Marek

> From: Marek Vasut 
> Sent: jeudi 18 juin 2020 20:35
> 
> The cd-gpios with (GPIO_ACTIVE_LOW | GPIO_PULL_UP) gpio is thus far
> unsupported, reinstate the old cd-gpios behavior until this handling is fully
> implemented. This permits the DHSOM to boot from SD again, without this patch
> the card detect fails.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrick Delaunay 
> Cc: Patrice Chotard 
> ---

Applied to u-boot-stm/master, thanks!

Regards

Patrick

Re: [PATCH] ARM: dts: stm32: Reinstate card detect behavior on DHSOM

2020-06-19 Thread Marek Vasut 
On 6/19/20 9:41 AM, Patrick DELAUNAY wrote:
> Hi Marek,
> 
>> From: Marek Vasut 
>> Sent: jeudi 18 juin 2020 20:35
>>
>> The cd-gpios with (GPIO_ACTIVE_LOW | GPIO_PULL_UP) gpio is thus far
>> unsupported, reinstate the old cd-gpios behavior until this handling is fully
>> implemented. This permits the DHSOM to boot from SD again, without this patch
>> the card detect fails.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Patrick Delaunay 
>> Cc: Patrice Chotard 
>> ---
>>  arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> index 75d75266e8..df63ad4a24 100644
>> --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> @@ -273,6 +273,9 @@
>>
>>   {
>>  u-boot,dm-spl;
>> +broken-cd;
>> +/delete-property/ cd-gpios;
>> +/delete-property/ disable-wp;
>>  };
>>
>>  _b4_pins_a {
>> --
>> 2.27.0
> 
> Reviewed-by: Patrick Delaunay 
> 
> This fix should be included in v2020.07
> So I will prepare a pull request.
> 
> Just for information: I assumed that PULL_UP was correctly managed when I 
> update the device tree.
> 
> Support is added in ucalss  by the serie with the patches
> 788ea834124 ("gpio: add function _dm_gpio_set_dir_flags")
> 477ca57b9a5 ("gpio: add support of new GPIO direction flag")
> 
> But I forget that the driver part wasn't yet accepted / merged in master 
> branch.
> 
> http://patchwork.ozlabs.org/project/uboot/list/?series=181294
> 
> In particular the commit "gpio: stm32: add ops set_dir_flags"
> 
> Today I target this serie in v2020.10 after review
> (I think it is late v2020.07 as it is impacting STM32MP MPU and STM32 MCU)
> 
> Sorry for disturbance

No problem, thanks!

RE: [PATCH] ARM: dts: stm32: Reinstate card detect behavior on DHSOM

2020-06-19 Thread Patrick DELAUNAY 
Hi Marek,

> From: Marek Vasut 
> Sent: jeudi 18 juin 2020 20:35
> 
> The cd-gpios with (GPIO_ACTIVE_LOW | GPIO_PULL_UP) gpio is thus far
> unsupported, reinstate the old cd-gpios behavior until this handling is fully
> implemented. This permits the DHSOM to boot from SD again, without this patch
> the card detect fails.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrick Delaunay 
> Cc: Patrice Chotard 
> ---
>  arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> index 75d75266e8..df63ad4a24 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> @@ -273,6 +273,9 @@
> 
>   {
>   u-boot,dm-spl;
> + broken-cd;
> + /delete-property/ cd-gpios;
> + /delete-property/ disable-wp;
>  };
> 
>  _b4_pins_a {
> --
> 2.27.0

Reviewed-by: Patrick Delaunay 

This fix should be included in v2020.07
So I will prepare a pull request.

Just for information: I assumed that PULL_UP was correctly managed when I 
update the device tree.

Support is added in ucalss  by the serie with the patches
788ea834124 ("gpio: add function _dm_gpio_set_dir_flags")
477ca57b9a5 ("gpio: add support of new GPIO direction flag")

But I forget that the driver part wasn't yet accepted / merged in master branch.

http://patchwork.ozlabs.org/project/uboot/list/?series=181294

In particular the commit "gpio: stm32: add ops set_dir_flags"

Today I target this serie in v2020.10 after review
(I think it is late v2020.07 as it is impacting STM32MP MPU and STM32 MCU)

Sorry for disturbance

Thanks

Patrick