[U-Boot] [PATCH 7/8] serial: lpuart: Add driver model serial support

[Bin Meng]

Hi Stefan,

On Thu, Jan 14, 2016 at 3:20 AM, Stefan Agner <stefan at 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.dv at 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.dv at 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