Re: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[Jagan Teki]

On Thu, Mar 29, 2018 at 2:37 PM, Maxime Ripard
 wrote:
> On Wed, Mar 28, 2018 at 11:29:10PM +0530, Jagan Teki wrote:
>> On Wed, Mar 28, 2018 at 4:45 PM, Maxime Ripard
>>  wrote:
>> > On Wed, Mar 28, 2018 at 03:22:20PM +0530, Jagan Teki wrote:
>> >> >> May it's good option to look at v3 changes, since DM_MMC Migration
>> >> >> expires in coming release, dt changes which are related to MMC we can
>> >> >> wait for proper supported feature get IN(like pinctrl, clock, reset),
>> >> >> that means we should anyway need to move DM_MMC but with working dt
>> >> >> changes.
>> >> >>
>> >> >> The big question for me here is about SPL, I'm sure we can get the
>> >> >> size issues. May be we try platdata but in any case we need to enable
>> >> >> DM ie increase the size (atleast for A64, H5)
>> >> >
>> >> > So my understanding is that those DM_ defines are just for
>> >> > U-Boot proper, and the SPL needs extra symbols to be also "DMed".
>> >>
>> >> I don't think so, Idea about migrating to BLK, DM_MMC should remove
>> >> #ifdef code with DM vs non-DM such that the driver should have DM
>> >> version with DT along with PLATDATA
>> >
>> > I'm not even sure what is the point of having the DM in the SPL. We
>> > won't be able to have any of the benefits due to our size constraint.
>>
>> True, but what if MIGRATION.txt intention is to remove old or non-dm
>> code after v2018.05?
>
> Then that intention is unreallistic, and unless the one that wrote it
> can make it fit in the SPL of all platforms, that's just wishful
> thinking.

I do have follow similar approach to remove #ifdef for SPI(_FLASH)
areas, I already written to MMC migration thread hope they come back
with proper.

Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[Maxime Ripard]

On Wed, Mar 28, 2018 at 11:29:10PM +0530, Jagan Teki wrote:
> On Wed, Mar 28, 2018 at 4:45 PM, Maxime Ripard
>  wrote:
> > On Wed, Mar 28, 2018 at 03:22:20PM +0530, Jagan Teki wrote:
> >> >> May it's good option to look at v3 changes, since DM_MMC Migration
> >> >> expires in coming release, dt changes which are related to MMC we can
> >> >> wait for proper supported feature get IN(like pinctrl, clock, reset),
> >> >> that means we should anyway need to move DM_MMC but with working dt
> >> >> changes.
> >> >>
> >> >> The big question for me here is about SPL, I'm sure we can get the
> >> >> size issues. May be we try platdata but in any case we need to enable
> >> >> DM ie increase the size (atleast for A64, H5)
> >> >
> >> > So my understanding is that those DM_ defines are just for
> >> > U-Boot proper, and the SPL needs extra symbols to be also "DMed".
> >>
> >> I don't think so, Idea about migrating to BLK, DM_MMC should remove
> >> #ifdef code with DM vs non-DM such that the driver should have DM
> >> version with DT along with PLATDATA
> >
> > I'm not even sure what is the point of having the DM in the SPL. We
> > won't be able to have any of the benefits due to our size constraint.
> 
> True, but what if MIGRATION.txt intention is to remove old or non-dm
> code after v2018.05?

Then that intention is unreallistic, and unless the one that wrote it
can make it fit in the SPL of all platforms, that's just wishful
thinking.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[Jagan Teki]

On Wed, Mar 28, 2018 at 4:45 PM, Maxime Ripard
 wrote:
> On Wed, Mar 28, 2018 at 03:22:20PM +0530, Jagan Teki wrote:
>> >> May it's good option to look at v3 changes, since DM_MMC Migration
>> >> expires in coming release, dt changes which are related to MMC we can
>> >> wait for proper supported feature get IN(like pinctrl, clock, reset),
>> >> that means we should anyway need to move DM_MMC but with working dt
>> >> changes.
>> >>
>> >> The big question for me here is about SPL, I'm sure we can get the
>> >> size issues. May be we try platdata but in any case we need to enable
>> >> DM ie increase the size (atleast for A64, H5)
>> >
>> > So my understanding is that those DM_ defines are just for
>> > U-Boot proper, and the SPL needs extra symbols to be also "DMed".
>>
>> I don't think so, Idea about migrating to BLK, DM_MMC should remove
>> #ifdef code with DM vs non-DM such that the driver should have DM
>> version with DT along with PLATDATA
>
> I'm not even sure what is the point of having the DM in the SPL. We
> won't be able to have any of the benefits due to our size constraint.

True, but what if MIGRATION.txt intention is to remove old or non-dm
code after v2018.05?

Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[Andre Przywara]

Hi,

On 28/03/18 10:52, Jagan Teki wrote:
> On Wed, Mar 28, 2018 at 4:23 AM, André Przywara  
> wrote:
>> On 27/03/18 18:58, Jagan Teki wrote:
>>> On Sat, Mar 24, 2018 at 6:37 AM, André Przywara  
>>> wrote:
 On 23/03/18 18:14, Jagan Teki wrote:
> On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara  
> wrote:
>> Update the .dts files for the various boards with an Allwinner A64 SoC.
>> This is as of v4.15-rc9, exactly Linux commit:

 

>>
>>   {
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins>;
>> -   vmmc-supply = <_vcc3v3>;
>> +   vmmc-supply = <_dcdc1>;
>
> These AXP regulator stuff need to wait until the relevant driver
> supported through dt

 Well, we could take the two patches I had in v3 that revert this change.
 As mentioned before, DCDC1 is an always-on regulator anyways.
>>>
>>> May it's good option to look at v3 changes, since DM_MMC Migration
>>> expires in coming release, dt changes which are related to MMC we can
>>> wait for proper supported feature get IN(like pinctrl, clock, reset),
>>> that means we should anyway need to move DM_MMC but with working dt
>>> changes.
>>>
>>> The big question for me here is about SPL, I'm sure we can get the
>>> size issues. May be we try platdata but in any case we need to enable
>>> DM ie increase the size (atleast for A64, H5)
>>
>> So my understanding is that those DM_ defines are just for
>> U-Boot proper, and the SPL needs extra symbols to be also "DMed".
> 
> I don't think so, Idea about migrating to BLK, DM_MMC should remove
> #ifdef code with DM vs non-DM such that the driver should have DM
> version with DT along with PLATDATA

Yes, but how do you want to make this happen in the one remaining week
of the merge window? For some reason I was totally unaware of this
deadline, and we should have started working on this months ago. But my
DeLorean is in the garage, so we can only look forward from here.

Which means we start with just DM_MMC, but not DM_SPL_MMC, and hope that
this threat of "Boards not converted by this time may be removed in a
subsequent release." does not really apply to sunxi as strictly as put
in this file.

The rest comes over time, giving us opportunity to find solutions for
the space constraint problems.

>> See the definition of CONFIG_IS_ENABLED().
>> So by just #defining CONFIG_DM_MMC the SPL still looks the same (using
>> the non-DM code), and indeed I don't run into size issues with the SPL.
> 
> Even to use DM_MMC in SPL we should enable SPL_DM so I'm unable to
> build SPL even with SPL_DM=y

??? I said we should *not* #define DM_SPL_MMC, because of (not only)
this reason. If we follow Heinrich's patch, it just selects DM_MMC, so
no changes for the SPL.

> SPL build, with SPL_DM_, SPL_DM_MMC, SPL_OF_PLATDATA
> 
> aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
> `.text' is not within region `.sram'
> aarch64-linux-gnu-ld.bfd: u-boot-spl section `.rodata' will not fit in
> region `.sram'
> aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
> `.text' is not within region `.sram'
> aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
> `.text' is not within region `.sram'
> aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 11104 bytes

Sure, no surprise.

>> Given the uniformity of at least the MMC device in sunxi, I think in the
>> medium term  we get away with some simple platdata, without pulling the
>> DT into SPL. The clocks might be a bit more hairy here, though. But
>> that's nothing for *now* to solve.
> 
> platdata available only for SPL, not for U-Boot proper.

Yes, that's what I meant: fixed platdata for SPL, U-Boot proper gets the
full DT glory.

> I agree that clock might be more hairy for now. and we can go with DT
> for U-Boot proper and just grab the minimum properties which are
> required for probe and rest we can use the driver as before, so-that
> regulator, clock, gpio, reset, pinctrl we use step by step.

That is what I was trying to say ;-)

Cheers,
Andre.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[Maxime Ripard]

On Wed, Mar 28, 2018 at 03:22:20PM +0530, Jagan Teki wrote:
> >> May it's good option to look at v3 changes, since DM_MMC Migration
> >> expires in coming release, dt changes which are related to MMC we can
> >> wait for proper supported feature get IN(like pinctrl, clock, reset),
> >> that means we should anyway need to move DM_MMC but with working dt
> >> changes.
> >>
> >> The big question for me here is about SPL, I'm sure we can get the
> >> size issues. May be we try platdata but in any case we need to enable
> >> DM ie increase the size (atleast for A64, H5)
> >
> > So my understanding is that those DM_ defines are just for
> > U-Boot proper, and the SPL needs extra symbols to be also "DMed".
> 
> I don't think so, Idea about migrating to BLK, DM_MMC should remove
> #ifdef code with DM vs non-DM such that the driver should have DM
> version with DT along with PLATDATA

I'm not even sure what is the point of having the DM in the SPL. We
won't be able to have any of the benefits due to our size constraint.

> > See the definition of CONFIG_IS_ENABLED().
> > So by just #defining CONFIG_DM_MMC the SPL still looks the same (using
> > the non-DM code), and indeed I don't run into size issues with the SPL.
> 
> Even to use DM_MMC in SPL we should enable SPL_DM so I'm unable to
> build SPL even with SPL_DM=y
> 
> SPL build, with SPL_DM_, SPL_DM_MMC, SPL_OF_PLATDATA
> 
> aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
> `.text' is not within region `.sram'
> aarch64-linux-gnu-ld.bfd: u-boot-spl section `.rodata' will not fit in
> region `.sram'
> aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
> `.text' is not within region `.sram'
> aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
> `.text' is not within region `.sram'
> aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 11104 bytes
> 
> > Given the uniformity of at least the MMC device in sunxi, I think in the
> > medium term  we get away with some simple platdata, without pulling the
> > DT into SPL. The clocks might be a bit more hairy here, though. But
> > that's nothing for *now* to solve.
> 
> platdata available only for SPL, not for U-Boot proper.
> 
> I agree that clock might be more hairy for now. and we can go with DT
> for U-Boot proper and just grab the minimum properties which are
> required for probe and rest we can use the driver as before, so-that
> regulator, clock, gpio, reset, pinctrl we use step by step.

I agree.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[Jagan Teki]

On Wed, Mar 28, 2018 at 4:23 AM, André Przywara  wrote:
> On 27/03/18 18:58, Jagan Teki wrote:
>> On Sat, Mar 24, 2018 at 6:37 AM, André Przywara  
>> wrote:
>>> On 23/03/18 18:14, Jagan Teki wrote:
 On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara  
 wrote:
> Update the .dts files for the various boards with an Allwinner A64 SoC.
> This is as of v4.15-rc9, exactly Linux commit:
>>>
>>> 
>>>
>
>   {
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> -   vmmc-supply = <_vcc3v3>;
> +   vmmc-supply = <_dcdc1>;

 These AXP regulator stuff need to wait until the relevant driver
 supported through dt
>>>
>>> Well, we could take the two patches I had in v3 that revert this change.
>>> As mentioned before, DCDC1 is an always-on regulator anyways.
>>
>> May it's good option to look at v3 changes, since DM_MMC Migration
>> expires in coming release, dt changes which are related to MMC we can
>> wait for proper supported feature get IN(like pinctrl, clock, reset),
>> that means we should anyway need to move DM_MMC but with working dt
>> changes.
>>
>> The big question for me here is about SPL, I'm sure we can get the
>> size issues. May be we try platdata but in any case we need to enable
>> DM ie increase the size (atleast for A64, H5)
>
> So my understanding is that those DM_ defines are just for
> U-Boot proper, and the SPL needs extra symbols to be also "DMed".

I don't think so, Idea about migrating to BLK, DM_MMC should remove
#ifdef code with DM vs non-DM such that the driver should have DM
version with DT along with PLATDATA

> See the definition of CONFIG_IS_ENABLED().
> So by just #defining CONFIG_DM_MMC the SPL still looks the same (using
> the non-DM code), and indeed I don't run into size issues with the SPL.

Even to use DM_MMC in SPL we should enable SPL_DM so I'm unable to
build SPL even with SPL_DM=y

SPL build, with SPL_DM_, SPL_DM_MMC, SPL_OF_PLATDATA

aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
`.text' is not within region `.sram'
aarch64-linux-gnu-ld.bfd: u-boot-spl section `.rodata' will not fit in
region `.sram'
aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
`.text' is not within region `.sram'
aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
`.text' is not within region `.sram'
aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 11104 bytes

>
> Given the uniformity of at least the MMC device in sunxi, I think in the
> medium term  we get away with some simple platdata, without pulling the
> DT into SPL. The clocks might be a bit more hairy here, though. But
> that's nothing for *now* to solve.

platdata available only for SPL, not for U-Boot proper.

I agree that clock might be more hairy for now. and we can go with DT
for U-Boot proper and just grab the minimum properties which are
required for probe and rest we can use the driver as before, so-that
regulator, clock, gpio, reset, pinctrl we use step by step.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[André Przywara]

On 27/03/18 18:58, Jagan Teki wrote:
> On Sat, Mar 24, 2018 at 6:37 AM, André Przywara  
> wrote:
>> On 23/03/18 18:14, Jagan Teki wrote:
>>> On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara  
>>> wrote:
 Update the .dts files for the various boards with an Allwinner A64 SoC.
 This is as of v4.15-rc9, exactly Linux commit:
>>
>> 
>>

   {
 pinctrl-names = "default";
 pinctrl-0 = <_pins>;
 -   vmmc-supply = <_vcc3v3>;
 +   vmmc-supply = <_dcdc1>;
>>>
>>> These AXP regulator stuff need to wait until the relevant driver
>>> supported through dt
>>
>> Well, we could take the two patches I had in v3 that revert this change.
>> As mentioned before, DCDC1 is an always-on regulator anyways.
> 
> May it's good option to look at v3 changes, since DM_MMC Migration
> expires in coming release, dt changes which are related to MMC we can
> wait for proper supported feature get IN(like pinctrl, clock, reset),
> that means we should anyway need to move DM_MMC but with working dt
> changes.
> 
> The big question for me here is about SPL, I'm sure we can get the
> size issues. May be we try platdata but in any case we need to enable
> DM ie increase the size (atleast for A64, H5)

So my understanding is that those DM_ defines are just for
U-Boot proper, and the SPL needs extra symbols to be also "DMed".
See the definition of CONFIG_IS_ENABLED().
So by just #defining CONFIG_DM_MMC the SPL still looks the same (using
the non-DM code), and indeed I don't run into size issues with the SPL.

Given the uniformity of at least the MMC device in sunxi, I think in the
medium term  we get away with some simple platdata, without pulling the
DT into SPL. The clocks might be a bit more hairy here, though. But
that's nothing for *now* to solve.

Just getting cheeky and wonder if we actually need to touch the clocks
since the boot ROM has actually done all this work already (since we
always load from the same media as the boot ROOM).

Cheers,
Andre.

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[Jagan Teki]

On Sat, Mar 24, 2018 at 6:37 AM, André Przywara  wrote:
> On 23/03/18 18:14, Jagan Teki wrote:
>> On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara  
>> wrote:
>>> Update the .dts files for the various boards with an Allwinner A64 SoC.
>>> This is as of v4.15-rc9, exactly Linux commit:
>
> 
>
>>>
>>>   {
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_pins>;
>>> -   vmmc-supply = <_vcc3v3>;
>>> +   vmmc-supply = <_dcdc1>;
>>
>> These AXP regulator stuff need to wait until the relevant driver
>> supported through dt
>
> Well, we could take the two patches I had in v3 that revert this change.
> As mentioned before, DCDC1 is an always-on regulator anyways.

May it's good option to look at v3 changes, since DM_MMC Migration
expires in coming release, dt changes which are related to MMC we can
wait for proper supported feature get IN(like pinctrl, clock, reset),
that means we should anyway need to move DM_MMC but with working dt
changes.

The big question for me here is about SPL, I'm sure we can get the
size issues. May be we try platdata but in any case we need to enable
DM ie increase the size (atleast for A64, H5)

Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[Jagan Teki]

On Tue, Mar 27, 2018 at 8:13 PM, Andre Przywara  wrote:
> Hi Maxime,
>
> thanks for the answer.
>
> On 27/03/18 15:30, Maxime Ripard wrote:
>> Hi,
>>
>> On Sat, Mar 24, 2018 at 01:07:27AM +, André Przywara wrote:
>>> On 23/03/18 18:14, Jagan Teki wrote:
 On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara  
 wrote:
> Update the .dts files for the various boards with an Allwinner A64 SoC.
> This is as of v4.15-rc9, exactly Linux commit:
>>>
>>> 
>>>
>
>   {
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> -   vmmc-supply = <_vcc3v3>;
> +   vmmc-supply = <_dcdc1>;

 These AXP regulator stuff need to wait until the relevant driver
 supported through dt
>>>
>>> Well, we could take the two patches I had in v3 that revert this change.
>>> As mentioned before, DCDC1 is an always-on regulator anyways.
>>>
>>> But actually that's not our problem, as we don't define DM_REGULATORS,
>>> so we will never parse those properties.
>>>
>>> Instead:
>>>
 otherwise moving to DM_MMC might fail to get the
 regulator? [1]
 [1] https://patchwork.ozlabs.org/patch/887405/
>>>
>>> Ah, thanks for the link, I totally missed that.
>>> So as Heinrich rightfully feared in his first patch, this change - for
>>> all sunxi boards - breaks most of them: The DM-MMC part of the sunxi MMC
>>> driver is not ready for any other SoC than the A20:
>>> a) The only compatible string it knows is "allwinner,sun5i-a13-mmc".
>>> b) It assumes the old style clocks, even without checking if the
>>> referenced nodes are compatible.
>>>
>>> So while a) is trivial to fix (U-Boot probably does not need to care
>>> about the differences in the MMC controllers of the different SoCs), b)
>>> is more of a beast.
>>> I started looking into an easy implementation of the new clocks,
>>> basically just enough to get MMC going, for the H3/H5 and A64. This
>>> could be extended for other clocks once we need them.
>>> But I am afraid this is not 2018.05 material anymore.
>>>
>>> So what do we do here?
>>>
>>> 1) Just switch over A20? The A20 DTs in U-Boot use the old-style clocks
>>> still, so that's fine. And we postpone the DM-MMC switch for the rest
>>> until we have some DM new-style clock driver?
>>
>> I'm not sure I'd like to do that to be honest, this sounds like
>> something that will never happen.
>>
>>> 2) Push forward on some simple sunxi-ng MMC clock driver?
>>
>> That one would work for me
>>
>>> 3) Don't use DM_MMC at all?
>>
>> Given the warning that was set for the next release, I'm not sure we
>> have much choice unfortunately.
>
> OK. So meanwhile I have something almost(TM) working:
> - drivers/clk/sunxi/clk-a64.c, which is a UCLASS_CLK implementation of
> the clock IDs from allwinner,sun50i-a64-ccu that we need: CLK_BUS_UARTx,
> CLK_BUS_MMCx, CLK_MMCx. Their implementation is fairly simple, actually
> (I did it the U-Boot way, not pulling in any super-fancy Linux code).
> Porting this over to H3/H5 and other SoCs should be trivial: copy/paste
> for now. We can look at how to unify this later.
> - drivers/mmc/sunxi_mmc.c extended to use UCLASS_CLK clocks. This is
> also not too bad, but I seem to miss a bit in here, as it times out.
> Will debug this tonight.
> - Cowardly dodging a proper UCLASS_RESET driver for now, instead hacking
> the single bit in :-(

I did this missing DM work like pinctrl, reset and clk and unable to
send because of size issues. which was with v2017.03.

I'm thinking DM_MMC should wait till the driver should have support of
these feature with all family SOC's

Jagan.

-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[Andre Przywara]

Hi Maxime,

thanks for the answer.

On 27/03/18 15:30, Maxime Ripard wrote:
> Hi,
> 
> On Sat, Mar 24, 2018 at 01:07:27AM +, André Przywara wrote:
>> On 23/03/18 18:14, Jagan Teki wrote:
>>> On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara  
>>> wrote:
 Update the .dts files for the various boards with an Allwinner A64 SoC.
 This is as of v4.15-rc9, exactly Linux commit:
>>
>> 
>>

   {
 pinctrl-names = "default";
 pinctrl-0 = <_pins>;
 -   vmmc-supply = <_vcc3v3>;
 +   vmmc-supply = <_dcdc1>;
>>>
>>> These AXP regulator stuff need to wait until the relevant driver
>>> supported through dt
>>
>> Well, we could take the two patches I had in v3 that revert this change.
>> As mentioned before, DCDC1 is an always-on regulator anyways.
>>
>> But actually that's not our problem, as we don't define DM_REGULATORS,
>> so we will never parse those properties.
>>
>> Instead:
>>
>>> otherwise moving to DM_MMC might fail to get the
>>> regulator? [1]
>>> [1] https://patchwork.ozlabs.org/patch/887405/
>>
>> Ah, thanks for the link, I totally missed that.
>> So as Heinrich rightfully feared in his first patch, this change - for
>> all sunxi boards - breaks most of them: The DM-MMC part of the sunxi MMC
>> driver is not ready for any other SoC than the A20:
>> a) The only compatible string it knows is "allwinner,sun5i-a13-mmc".
>> b) It assumes the old style clocks, even without checking if the
>> referenced nodes are compatible.
>>
>> So while a) is trivial to fix (U-Boot probably does not need to care
>> about the differences in the MMC controllers of the different SoCs), b)
>> is more of a beast.
>> I started looking into an easy implementation of the new clocks,
>> basically just enough to get MMC going, for the H3/H5 and A64. This
>> could be extended for other clocks once we need them.
>> But I am afraid this is not 2018.05 material anymore.
>>
>> So what do we do here?
>>
>> 1) Just switch over A20? The A20 DTs in U-Boot use the old-style clocks
>> still, so that's fine. And we postpone the DM-MMC switch for the rest
>> until we have some DM new-style clock driver?
> 
> I'm not sure I'd like to do that to be honest, this sounds like
> something that will never happen.
> 
>> 2) Push forward on some simple sunxi-ng MMC clock driver?
> 
> That one would work for me
> 
>> 3) Don't use DM_MMC at all?
> 
> Given the warning that was set for the next release, I'm not sure we
> have much choice unfortunately.

OK. So meanwhile I have something almost(TM) working:
- drivers/clk/sunxi/clk-a64.c, which is a UCLASS_CLK implementation of
the clock IDs from allwinner,sun50i-a64-ccu that we need: CLK_BUS_UARTx,
CLK_BUS_MMCx, CLK_MMCx. Their implementation is fairly simple, actually
(I did it the U-Boot way, not pulling in any super-fancy Linux code).
Porting this over to H3/H5 and other SoCs should be trivial: copy/paste
for now. We can look at how to unify this later.
- drivers/mmc/sunxi_mmc.c extended to use UCLASS_CLK clocks. This is
also not too bad, but I seem to miss a bit in here, as it times out.
Will debug this tonight.
- Cowardly dodging a proper UCLASS_RESET driver for now, instead hacking
the single bit in :-(

That looks tight to still get into this merge window, though, at least
if we follow the usual process.

Keep you posted.

Cheers,
Andre.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[Maxime Ripard]

Hi,

On Sat, Mar 24, 2018 at 01:07:27AM +, André Przywara wrote:
> On 23/03/18 18:14, Jagan Teki wrote:
> > On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara  
> > wrote:
> >> Update the .dts files for the various boards with an Allwinner A64 SoC.
> >> This is as of v4.15-rc9, exactly Linux commit:
> 
> 
> 
> >>
> >>   {
> >> pinctrl-names = "default";
> >> pinctrl-0 = <_pins>;
> >> -   vmmc-supply = <_vcc3v3>;
> >> +   vmmc-supply = <_dcdc1>;
> > 
> > These AXP regulator stuff need to wait until the relevant driver
> > supported through dt
> 
> Well, we could take the two patches I had in v3 that revert this change.
> As mentioned before, DCDC1 is an always-on regulator anyways.
> 
> But actually that's not our problem, as we don't define DM_REGULATORS,
> so we will never parse those properties.
> 
> Instead:
> 
> > otherwise moving to DM_MMC might fail to get the
> > regulator? [1]
> > [1] https://patchwork.ozlabs.org/patch/887405/
> 
> Ah, thanks for the link, I totally missed that.
> So as Heinrich rightfully feared in his first patch, this change - for
> all sunxi boards - breaks most of them: The DM-MMC part of the sunxi MMC
> driver is not ready for any other SoC than the A20:
> a) The only compatible string it knows is "allwinner,sun5i-a13-mmc".
> b) It assumes the old style clocks, even without checking if the
> referenced nodes are compatible.
> 
> So while a) is trivial to fix (U-Boot probably does not need to care
> about the differences in the MMC controllers of the different SoCs), b)
> is more of a beast.
> I started looking into an easy implementation of the new clocks,
> basically just enough to get MMC going, for the H3/H5 and A64. This
> could be extended for other clocks once we need them.
> But I am afraid this is not 2018.05 material anymore.
> 
> So what do we do here?
> 
> 1) Just switch over A20? The A20 DTs in U-Boot use the old-style clocks
> still, so that's fine. And we postpone the DM-MMC switch for the rest
> until we have some DM new-style clock driver?

I'm not sure I'd like to do that to be honest, this sounds like
something that will never happen.

> 2) Push forward on some simple sunxi-ng MMC clock driver?

That one would work for me

> 3) Don't use DM_MMC at all?

Given the warning that was set for the next release, I'm not sure we
have much choice unfortunately.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[André Przywara]

On 23/03/18 18:14, Jagan Teki wrote:
> On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara  
> wrote:
>> Update the .dts files for the various boards with an Allwinner A64 SoC.
>> This is as of v4.15-rc9, exactly Linux commit:



>>
>>   {
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins>;
>> -   vmmc-supply = <_vcc3v3>;
>> +   vmmc-supply = <_dcdc1>;
> 
> These AXP regulator stuff need to wait until the relevant driver
> supported through dt

Well, we could take the two patches I had in v3 that revert this change.
As mentioned before, DCDC1 is an always-on regulator anyways.

But actually that's not our problem, as we don't define DM_REGULATORS,
so we will never parse those properties.

Instead:

> otherwise moving to DM_MMC might fail to get the
> regulator? [1]
> [1] https://patchwork.ozlabs.org/patch/887405/

Ah, thanks for the link, I totally missed that.
So as Heinrich rightfully feared in his first patch, this change - for
all sunxi boards - breaks most of them: The DM-MMC part of the sunxi MMC
driver is not ready for any other SoC than the A20:
a) The only compatible string it knows is "allwinner,sun5i-a13-mmc".
b) It assumes the old style clocks, even without checking if the
referenced nodes are compatible.

So while a) is trivial to fix (U-Boot probably does not need to care
about the differences in the MMC controllers of the different SoCs), b)
is more of a beast.
I started looking into an easy implementation of the new clocks,
basically just enough to get MMC going, for the H3/H5 and A64. This
could be extended for other clocks once we need them.
But I am afraid this is not 2018.05 material anymore.

So what do we do here?

1) Just switch over A20? The A20 DTs in U-Boot use the old-style clocks
still, so that's fine. And we postpone the DM-MMC switch for the rest
until we have some DM new-style clock driver?
2) Push forward on some simple sunxi-ng MMC clock driver?
3) Don't use DM_MMC at all?

Would love to here other's opinions.

Cheers,
Andre.

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[Jagan Teki]

On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara  wrote:
> Update the .dts files for the various boards with an Allwinner A64 SoC.
> This is as of v4.15-rc9, exactly Linux commit:
> commit bdfe4cebea11476d278b1b98dd0f7cdac8269d62
> Author: Icenowy Zheng 
> Date:   Fri Nov 10 17:26:54 2017 +0800
> arm64: allwinner: a64: add Ethernet PHY regulator for several boards
>
> It updates the existing DT files, adds the newly added axp803.dtsi and
> removes our temporary kludge file to get Ethernet support in U-Boot.
>
> Signed-off-by: Andre Przywara 
> Acked-by: Maxime Ripard 
> ---
>  arch/arm/dts/axp803.dtsi| 150 
>  arch/arm/dts/sun50i-a64-bananapi-m64.dts| 161 +++--
>  arch/arm/dts/sun50i-a64-nanopi-a64.dts  | 108 --
>  arch/arm/dts/sun50i-a64-olinuxino.dts   | 131 +++--
>  arch/arm/dts/sun50i-a64-orangepi-win.dts|   7 +-
>  arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi |  20 ---
>  arch/arm/dts/sun50i-a64-pine64-plus.dts |  17 ++-
>  arch/arm/dts/sun50i-a64-pine64.dts  | 178 
> +++-
>  8 files changed, 716 insertions(+), 56 deletions(-)
>  create mode 100644 arch/arm/dts/axp803.dtsi
>  delete mode 100644 arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi
>
> diff --git a/arch/arm/dts/axp803.dtsi b/arch/arm/dts/axp803.dtsi
> new file mode 100644
> index 00..ff8af52743
> --- /dev/null
> +++ b/arch/arm/dts/axp803.dtsi
> @@ -0,0 +1,150 @@
> +/*
> + * Copyright 2017 Icenowy Zheng 
> + *
> + * 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.
> + */
> +
> +/*
> + * AXP803 Integrated Power Management Chip
> + * http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf
> + */
> +
> + {
> +   interrupt-controller;
> +   #interrupt-cells = <1>;
> +
> +   regulators {
> +   /* Default work frequency for buck regulators */
> +   x-powers,dcdc-freq = <3000>;
> +
> +   reg_aldo1: aldo1 {
> +   regulator-name = "aldo1";
> +   };
> +
> +   reg_aldo2: aldo2 {
> +   regulator-name = "aldo2";
> +   };
> +
> +   reg_aldo3: aldo3 {
> +   regulator-name = "aldo3";
> +   };
> +
> +   reg_dc1sw: dc1sw {
> +   regulator-name = "dc1sw";
> +   };
> +
> +   reg_dcdc1: dcdc1 {
> +   regulator-name = "dcdc1";
> +   };
> +
> +   reg_dcdc2: dcdc2 {
> +   regulator-name = "dcdc2";
> +   };
> +
> +   reg_dcdc3: dcdc3 {
> +   regulator-name = "dcdc3";
> +   };
> +
> +   reg_dcdc4: dcdc4 {
> +   regulator-name = "dcdc4";
> +   };
> +
> +