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. Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
