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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
