[U-Boot] [PATCH v1 1/2] Revert "powerpc: mpc85xx: remove P2020DS board support"

[Bin Meng]

Hi York,

On Tue, Feb 2, 2016 at 11:31 AM, york sun <york.sun at nxp.com> wrote:
> On 02/01/2016 07:19 PM, Bin Meng wrote:
>> Hi York,
>>
>> On Tue, Feb 2, 2016 at 11:11 AM, york sun <york.sun at nxp.com> wrote:
>>> On 02/01/2016 04:05 PM, Simon Glass wrote:
>>> <snip>
>>>>>
>>>>> I will take this chance to convert P2020DS to use DM. Need some guidance here.
>>>>> For NS16550, it needs the clock. To keep it simple, let's presume platform data
>>>>> is used. My trouble is the clock is not unknown at compiling time. It needs to
>>>>> be updated by checking the board/soc configuration after power up. The clock is
>>>>> only available after get_clocks() is called in init_sequance. Is there a way I
>>>>> can update the clocks before the driver is initialized?
>>>>>
>>>>> York
>>>>
>>>> See this commit:
>>>>
>>>> 858530a8     dm: tegra: Enable driver model for serial
>>>>
>>>> It sets up its own clock.
>>>
>>> Simon,
>>>
>>> Thanks for the pointer. I actually noticed this commit but it adds some
>>> confusion to me. Take your code as an example
>>>
>>> U_BOOT_DRIVER(serial_ns16550) = {
>>>        .name   = "serial_tegra20",
>>>        .id     = UCLASS_SERIAL,
>>>        .of_match = tegra_serial_ids,
>>>        .ofdata_to_platdata = tegra_serial_ofdata_to_platdata,
>>>        .platdata_auto_alloc_size = sizeof(struct ns16550_platdata),
>>>        .priv_auto_alloc_size = sizeof(struct NS16550),
>>>        .probe = ns16550_serial_probe,
>>>        .ops    = &ns16550_serial_ops,
>>> };
>>>
>>> The name "serial_ns16550" is not directly used anywhere. So I guess you didn't
>>> have to name it as "serial_ns16550", right?
>>>
>>
>> The commit Simon gave was an old one. Now all ns16550 driver has been
>> unified into one.
>>
>>> One step forward, if I want to create a new driver, say "fsl_ns16550", I will
>>> have to use ofdata_to_platdata to fill in plat->clock. But for majority powerpc
>>> SoCs, we don't use device tree. We may start to use device tree on new products.
>>> But it is probably not a good idea to force every platform to change.
>>>
>>
>> Please do not create a new driver for FSL chipset. Does FSL have any
>
> That's a relief. I don't want to create a new driver just for the clock.
>
>> plan to continue maintaining all these PowerPC SoCs in U-Boot? If yes,
>> I believe the intention is to bring driver model and device tree to
>> these boards.
>
> I'd rather to add the device tree step by step, not all at once. And probably
> leave some legacy boards behind.
>

Agreed. We can add device tree and driver model drivers to these
PowerPC boards step by step as long as they are maintained. There is
no need to add them in a bunch. It's easy to convert these PowerPC
boards to driver model, given they share some of the IPs in the new
LayerScape ARM SoCs.

>>
>>> Is there another way to update plat->clock?
>>>
>>
>> You can define CONFIG_SYS_NS16550_CLK to a routine that gets the
>> correct clock freq at runtime: eg: get_serial_clock()
>
> Please explain in detail. I want to go down this path. For non-device tree
> platforms (for the time being), doesn't U_BOOT_DEVICES evaluate the platdata at
> compiling time? How can I use a routine as the clock for ns16550_platdata?
> It is pretty simple for fixed clock, as I am looking at an example
> arch/arm/cpu/armv7/am33xx/board.c.
>

We should add device tree to these platforms. The non-device tree
(U_BOOT_DEVICES) was mainly for some SPL boards which does not have
enough RAM before memory is initialized. I think you may refer to this
patch: http://patchwork.ozlabs.org/patch/561853/

Regards,
Bin