[U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass]

Hi Michal,

On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek <monstr at monstr.eu> wrote:

> Hi Simon,
>
>
> On 06/28/2012 03:10 AM, Simon Glass wrote:
>
>> Hi Michal,
>>
>>
>> On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek <monstr at monstr.eu <mailto:
>> monstr at monstr.eu>> wrote:
>>
>>    Hi Simon,
>>
>>
>>    On 06/27/2012 03:58 PM, Simon Glass wrote:
>>
>>        Hi,
>>
>>
>>        On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <monstr at monstr.eu<mailto:
>> monstr at monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr at monstr.eu>>>
>> wrote:
>>
>>            Hi,
>>
>>            can you please update me about current state of
>> CONFIG_OF_CONTROL for ARM?
>>            Are there any other archs/boards which will use this option?
>>
>>            Or any other git repo out of mainline u-boot?
>>
>>
>>        Exynos is in progress - development is happening in the Chromium
>> tree and being upstreamed in chunks (although no fdt patches have been sent
>> yet).
>>
>>
>>    ok.
>>
>>
>>
>>
>>            Has someone tried to look for devices based on compatible
>> property?
>>            I see that in usb driver it is based on aliases which is not
>> the best solution.
>>
>>
>>        U-Boot doesn't yet have a device model which would allow this in
>> the general case. For now, drivers look for their own compatible nodes.
>> This works well enough until we have a device model.
>>
>>        There are other limitations also - for example USB supports only a
>> single controller type working at one time (a restriction we may need to
>> look at to support USB2 and USB3 together). So even if two USB drivers
>> decided that they both found compatible nodes, only one of them could
>> operate. So for now aliases provide just an ordering, nothing else.
>>
>>
>>
>>    I have looked at the code and did some tests on Microblaze.
>>
>>    Firstly I have tried to change emaclite ethernet initialization and I
>> ended with this code fragment which could be
>>    broadly used by other drivers.
>>
>>            int offset = 0;
>>            do {
>>                    offset = fdt_node_offset_by_compatible(**__gd->fdt_blob,
>> offset, "xlnx,xps-ethernetlite-1.00.a" );
>>
>>
>>
>> You could check if offset < 0 here, or !fdtdec_get_is_enabled(gd->**fdt_blob,
>> offset)
>>
>>                    u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset,
>> "xlnx,rx-ping-pong", 0);
>>                    u32 txpp = fdtdec_get_int(gd->fdt_blob, offset,
>> "xlnx,tx-ping-pong", 0);
>>                    u32 reg = fdtdec_get_int(gd->fdt_blob, offset, "reg",
>> 0);
>>
>>
>> Maybe fdtdec_get_addr()
>>
>
> yeah right.
>
>
>        do {
>                offset = fdt_node_offset_by_compatible(**gd->fdt_blob,
> offset, "xlnx,xps-ethernetlite-1.00.a" );
>                u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset,
> "xlnx,rx-ping-pong", 0);
>                u32 txpp = fdtdec_get_int(gd->fdt_blob, offset,
> "xlnx,tx-ping-pong", 0);
>                u32 reg = fdtdec_get_addr(gd->fdt_blob, offset, "reg");
>                if (reg != FDT_ADDR_T_NONE)
>
>                        ret |= xilinx_emaclite_initialize(**bis, reg,
> txpp, rxpp);
>        } while (offset != -1);
>
>
>
>
>>                    if (reg)
>>                            ret |= xilinx_emaclite_initialize(__**bis,
>> reg, txpp, rxpp);
>>
>>            } while (offset != -1);
>>
>>    What do you think? This code is in platform file.
>>
>>
>> Seems reasonable to me.
>>
>
> ok.
>
>
>
>>
>>    Also I have tested code around aliases which parse DTS aliases list
>> for console initialization
>>    and I have also get it work for !CONSOLE_SERIAL_MULTI case.
>>
>>
>> Great - I did send a patch to the list for fdt serial, but haven't really
>> got back to it.
>>
>
>
> Can you give me link to it or just subject?


WIP: fdt: Add serial port controlled by device tree

These are the related commits in the Chromium tree. I will get to
upstreaming these at some point.

 1fe36bf gen: serial: Disable FDT serial console if requested
c80331f gen: Adjust fdt console to be silent if no alias present
2006b07 gen: fdt: Add serial port controlled by device tree
711f29d fixup: gen: fdt: Fix compile-time errors
0c8fc5d lost: gen: x86: Allow NS16550 driver to support IO and memory
mapped reg
da92af5 gen: Fix a compiler warning in serial_fdt.c
ab1d572 gen: fdt: silence console in response to device tree 'silent' option
376c215 lost: gen: fdt: Add serial port controlled by device tree


>
>
>
>>
>>    What was the reason to use compat_names table in fdtdec.c file?
>>
>>
>> Just so there is a simple register of everything that uses fdt in U-Boot
>> - the enum is used by driver code. If we end up with a lot of support then
>> we might reconsider one day
>>
>
> Is it requirement that all new drivers should extend this table?
> Because from my point of view is just this not necessary to do.
> Based on function above this is enough for drivers to be probed.


Fair enough. If you don't want to I don't see why it should be a hard
requirement.

Regards,
Simon


>
>
> Thanks,
> Michal
>
> --
> Michal Simek, Ing. (M.Eng)
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel 2.6 Microblaze Linux -
> http://www.monstr.eu/fdt/
> Microblaze U-BOOT custodian
>