[U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Jorge Ramirez <jorge.ramirez-ortiz@linaro.org>]

On 05/26/2017 12:08 AM, Tom Rini wrote:
> On Thu, May 25, 2017 at 11:16:42PM +0200, Jorge Ramirez wrote:
>> On 05/25/2017 11:12 PM, Tom Rini wrote:
>>> On Thu, May 25, 2017 at 10:58:20PM +0200, Jorge Ramirez wrote:
>>>> On 05/25/2017 10:55 PM, Jorge Ramirez wrote:
>>>>> On 05/25/2017 10:31 PM, Tom Rini wrote:
>>>>>> On Thu, May 25, 2017 at 08:38:47PM +0200, Jorge Ramirez wrote:
>>>>>>> On 05/18/2017 12:06 AM, Tom Rini wrote:
>>>>>>>>>>> having platform data.
>>>>>>>>>> No, I think we're going for overkill here by not doing
>>>>>>>>>> serial_pl01x.c as
>>>>>>>>>> platform data.  ns16550 does platform data for this already.  This
>>>>>>>>>> sounds like the lowest overhead way to get the clock
>>>>>>>>>> populated and not
>>>>>>>>>> have some DT data that's not going to be accepted upstream.
>>>>>>>>>>
>>>>>>>>> ummmm I am a bit lost at this point, could we recap please?
>>>>>>>> Lets update the recap:
>>>>>>>> - Please re-submit the dts file, now with whatever form is
>>>>>>>> in v4.12-rc1,
>>>>>>>>    saying as such in the commit (if it's just the commit message that
>>>>>>>>    changes, that's fine and great).
>>>>>>> The DTS file in v4.12-rc2 still does NOT contain the usb node.
>>>>>>>
>>>>>>> ==> Should I then not use the DM on USB so I can avoid DTS changes?
>>>>>> Well, you can either put it in the -u-boot.dtsi file for the board, and
>>>>>> remove that later once it's upstream.
>>>> yes I'll do that. thanks.
>>>>
>>>>>>>> - Please update serial_pl01x.c to be able to get the clock
>>>>>>>> via platform
>>>>>>>>    data, update and test your board to confirm it works.
>>>>>>> um, It gets tricky;
>>>>>>> I can not use platform_data since I can not use SERIAL_DM because
>>>>>>> the device tree does have a UART node which gets picked up.
>>>>>> How about disabling the node in -u-boot.dtsi for the board and then you
>>>>>> can use platform data,
>>>> I dont think that would because CONFIG_OF is enabled for USB; so the
>>>> kernel dtsi that contains the uart node (without the clock!) will be
>>>> picked by u-boot and the uart will not be initialized properly.
>>>> I still think that the simplest solution is to let me merge with the
>>>> kernel's device tree plus this u-boot.dtsi [1];
>>>> then just get rid of the file when possible (and NEIHER the source
>>>> code NOR the configs) would need to change
>>>>
>>>> [1] https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi
>>> Yes, sorry.  [1] needs to be updated to disable uart0 so that you can
>>> use platform data, at least for now.  I do want to talk more with Rob
>>> about the general problem this exposes.
>> so you want me to
>>
>> 1) keep the node in https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi
> Well, a uart0 node, but no "clock" property as that just needs to go
> away.

Sounds good to me. now see below

>
>> 2) add status=disable
>> 3) then add the platform_data
>>
>> BUT for the pl011 driver to take the platform_data dont I also have
>> to disable CONFIG_OF?
>>
>> but  if I disable CONFIG_OF then I lose USB_DM
> No, the status = "disable" on uart0 should remove it from the dtb, or at
> least we should see it and go "Oh, no, we don't have uart0 via DT".
>


1) Since the UART0 is enabled in the kernel's DTS I will have to modify 
the device tree that I am importing from kernel.org to disable it.

2) But even doing this is not enough: I have to completely remove the 
uart0 node from the tree.


So to sum up:

In order to get the platform data for pl01x I have to either disable OF 
(so I lose the USB node as I said earlier) or *completely* remove the 
UART0 node from from the kernel dts.
I personally would rather not modify the kernel's DTS trees that I am 
importing into uboot but I am really confused about the policy now.

please could you clarify?

I still think what I proposed when we started is the better way to go: a 
uboot specific hi3798cv200-u-boot.dtsifile that contains the two nodes 
that are giving trouble.

The timeline then goes:
- the usb node will disappear as soon as it lands in korg
- the uart node and the whole file will be removed during the cleanup of 
all the pl01x uart offenders.

but if you think modifying the kernels dts is better I can do that as well.