On 01/14/2016 07:54 AM, Bin Meng wrote:
Hi Stefan,
On Thu, Jan 14, 2016 at 3:20 AM, Stefan Agner <ste...@agner.ch> wrote:
On 2016-01-13 00:19, Bin Meng wrote:
+Simon
Hi Bhuvan,
On Wed, Jan 13, 2016 at 4:07 PM, Bhuvanchandra DV
<bhuvanchandra...@toradex.com> wrote:
Hi Bin,
On 01/13/2016 11:43 AM, Bin Meng wrote:
Hi Bhuvan,
On Wed, Jan 13, 2016 at 1:49 PM, Bhuvanchandra DV
<bhuvanchandra...@gmail.com> wrote:
Hi Bin,
With reference to the discussion here[1].
Unfortunately the lpuart driver is now broken for legacy code and also
the driver doesn't
work with serial driver model enabled on Toradex Colibri VF50/VF61,
Freescale VF610twr
and Phytec pcm052 boards. Did some one tested this patchset on these
boards ?
I will fix the legacy code build in v2. About serial driver model not
working on these boards, is that the caused by no device tree of these
boards?
Yes, i tested on Colibri VF50/VF61 with device tree and it works fine.
Great to know!
I think it would be nice to have the support for both platform data and
device tree so that we can use it with platform data via board files and
device tree too.
I believe we should introduce device tree support on these boards. The
configuration data (like in your patches the reg base for LPUART)
should really be put into device tree. I adapted the comments from
platdata.h below:
Currently colibri_vf has both, a DT and a non-DT config. There has been
only one driver (SPI I think?) which required DT so far, and since most
user do not use that driver, we created two configs.
However, if something like UART requires DT, then we can as well drop
the non-DT config for colibri_vf.
I vote for dropping the non-DT config.
31/**
32 * NOTE: Avoid using these except in extreme circumstances, where device tree
33 * is not feasible (e.g. serial driver in SPL where <8KB of SRAM is
34 * available). U-Boot's driver model uses device tree for configuration.
35 */
36#define U_BOOT_DEVICE(__name) \
37 ll_entry_declare(struct driver_info, __name, driver_info)
Since Vybrid has so large internal SRAM, there has been no need for SPL
at all so far. Not sure about LS1021a/other LPUART SoCs...
LS1021 has 128KB SRAM, and current lp1021atwr_nor_lpuart does not use
SPL. It boots from NOR flash.
Since only few boards are using lpuart driver we can update the driver
completly to driver model, drop the legacy code and update the boards.
Since in my patches I only updated ls1021atwr board to use driver
model serial, and I don't have those other boards (like Colibri
VF50/VF61) to test this lpuart dm driver. I chose to leave the legacy
codes there. On top of my series, you can prepare a patch to
completely drop those legacy codes after you switch to use driver
model lpuart driver on those boards in your series. Then we get a
legacy-free driver for lpuart boards :)
I guess nobody has all this boards, we should nontheless try to find a
solution for all of them.
I see three options:
- Leave legacy code and the other boards as is (pcm052/vf610twr)
- Drop legacy code, and add platform data support and the corresponding
platform data for pcm052/vf610twr (in this case, we could also keep the
colibri_vf non-DT config)
- Drop legacy code, add device tree for pcm052/vf610twr, extend
colibri_vf device tree and drop non-DT config for colibri_vf.
I am inclined to say lets go for the pure DT solution, since that is
where U-Boot is evolving to long term anyway. Not sure how much work is
required to make that happen. I guess the lpuart only DT for
pcm052/vf610twr should be fairly easy to create...?
Other opinions?
--
I would go for option 3.
I too agree with Stefan and Bin for going with pure DT solution. Will do
the device tree files for vf610-twr, pcm052 boards and extend
Colibri-VFxx board with lpuart support. Will submit the new patchset
after Bin's patchset upstreamed.
Regards,
Bin
--
Best regards,
Bhuvan
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
