Hi Michal, On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek <mon...@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 <mon...@monstr.eu <mailto: >> mon...@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 >> <mon...@monstr.eu<mailto: >> mon...@monstr.eu> <mailto:mon...@monstr.eu <mailto:mon...@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 >
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot