On 7 May 2015 at 10:09, Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> wrote: > Hi Michal, > >> On May 7, 2015, at 11:07 , Michal Suchanek <hramrach@xxxxxxxxx> wrote: >> >> Hello, >> >> On 7 May 2015 at 09:28, Pantelis Antoniou >> <pantelis.antoniou@xxxxxxxxxxxx> wrote: >>> Hi Geert, >>> >>>> On May 7, 2015, at 10:17 , Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: >>>> >>>> On Tue, May 5, 2015 at 6:51 PM, Michal Suchanek <hramrach@xxxxxxxxx> wrote: >>>>> On 5 May 2015 at 17:18, Michal Suchanek <hramrach@xxxxxxxxx> wrote: >>>>>> where is a device tree compiler that can compile an overlay? >>>>>> >>>>>> The compiler at git://git.kernel.org/pub/scm/utils/dtc/dtc.git shrieks >>>>>> there is a syntax error as soon as the /plugin/ tag is present. >>>>> >>>>> ok, so I found a dtc patch here https://lkml.org/lkml/2013/1/4/295 >>>>> >>>>> This does not apply cleanly to current DTC but the parts that fail are >>>>> due to cosmetic changes in the code so I went ahead and applied it. >>>> >>>> Thanks for the link! That patch indeed requires some manual rework. >>>> >>>>> However, the created blob is not what the kernel can accept into >>>>> of_overlay_create so what do I do with the blob to load it? >>>> >>>> Use "OF: DT-Overlay configfs interface" from Pantelis? >>>> >>>> That depends on "configfs: Implement binary attributes", also from Pantelis, >>>> which requires reverting commit 28444a2bde8d1695i ("configfs_add_file: >>>> fold into its sole caller"). >>>> >>>> All of the above require manual fixups to apply. >>>> >>>> Still have to try the actual loading, new to the overlay game on mainline >>>> kernels (I did use it on boneblack with its original kernel and its overlay >>>> manager). >>>> >>> >>> Posted the patches recently, but for your convenience here’s the git tree. >>> >>> https://github.com/pantoniou/dtc/tree/dt-overlays5 >>> >>> FWIW, I’ll post the capemgr patch today too. >>> >> >> I did not find those so tried loading the overlay by hand. FWIW like >> the half dozen patches of this https://github.com/hramrach/linux-sunxi >> are the overlay loading atm. >> >> I can cat the overlay blob to sysfs and it creates a device so I guess >> it basically works. >> >> What I need to investigate is exporting some useful information about >> the overlays in sysfs. >> > > If you were to share some details of what you’re trying to achieve I might be able to help. > > I have no clue what you guys are trying to do :) > I am trying to load overlays at runtime to see if that's usable for something. For example, with the above tree I can load simple overlay like this (the compatible and part number is not used for anything atm): /dts-v1/; /plugin/; / { compatible = "olimex,a10s-olinuxino-micro"; /* identification */ part-number = "A10S-SPI2"; fragment@0 { target = <&spi2>; __overlay__ { #address-cells = <1>; #size-cells = <0>; flash: m25p80@0 { #address-cells = <1>; #size-cells = <1>; compatible = "nor-jedec"; reg = <0>; spi-max-frequency = <40000000>; m25p,fast-read; }; }; }; }; and it probes the flash and does not find any because I have none attached. I can also destroy and reload the overlay so that works nice. Loading the overlay twice without destroying it in between causes kernel oops. So presumably if I wired my display backlight to PWM I could write an overlay for the PWM backlight and patch it in at runtime and possibly test different settings by destroying the overlay and reloading an updated one. This is already good enough for testing even complex devices without reboot provided the driver for them is compiled into the kernel. With your node kprintf providing enough information about the overlays so they can be identified should not be that difficult. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
