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.
- 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 think... But Rob, this loops us back around to the first problem too, kind of. Can we really just not make use of clock-frequency and the kernel just not use it?