Hello Hans, Thanks for your answers. On Fri, Oct 31, 2014 at 10:51 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >>>> What about regulators (to power the LCD), gpios (to keep the LCD >>>> enabled) and pinctrl (for video signals)? I guess any those could be >>>> reset by the kernel if no driver uses them. >>> >>> Yes this has been discussed before, AFAIK gpio / pinctrls should not be >>> spontaneously reset by the kernels. Regulators will be a problem, but there >>> we can pretty much follow whatever solution we end up with for clocks, since >>> they work very much alike (e.g. we could add a supply property to the >>> simplefb node). >>> >> >> I think someone already said this but with regulators is not that easy >> since you don't have an equivalent of the "clocks" property. >> >> You need a "<name>-supply" property for each regulator that is an >> input supply. Some boards may need different regulators for their >> display (e.g: one to power the LCD and another to power the backlight) >> so adding a single supply property will not be enough. > > Right so we can simply insert simplefbvdd1-supply, simplefbvdd2-supply, etc. > regulator nodes into the simplefb node, and have the simplefb kernel code look > for supplies with a name of simplefb_vdd%d in a loop until it fails to find one. > > Note that the foo-supply names are local to the simplefb node, these do not > need to be the same as the ones in the nodes describing the actual hardware > blocks. Not having an array is somewhat inconvenient, but easily worked around > and once worked around this really is just the same problem as with clocks. > Yes, I guess the question is how many regulators the driver should support but I expect most displays don't need more than a couple. >>> Note I've no intention to add regulator support atm, we can do that when the >>> need arises, so that we can actually test the code. >>> >> >> AFAIU that's exactly what Thierry was complaining about. There seems >> to be only a focus on solving the clocks issue since that is needed >> for sunxi but ignoring how the problem for other resources should be >> solved. > > That is simply not true, I'm fully aware that we may eventually need other > resources, e.g. regulators. I just want to take this one step at a time, > I really believe that once we have this figured out for one resource, it > becomes a lot easier to also figure out for other resources. > Great, I'm glad to hear that you are willing to add support for regulators (and other resources). >> The assumptions made by simplefb are quite fragile and only adding >> support for managing clocks is just a partial solution that will give >> a false sense of robustness since it could break later due to other >> resources. > > The key word here being resources. We need to figure out how to do > resource management for simplefb, once we have that figured out for one > resource, the others can follow the same "design-pattern". As the long > thread about the clocks support has shown, getting consensus on this > with only one resource in play already is hard enough, so baby steps > is the way to go. > I'm certainly not against adding clock management if that will make simplefb more robust. I was just worried that other resources could be ignored. But I'm ok of doing baby steps if there is a long term plan. As I mentioned in another thread, I believe Doug's suggestion is the best approach. That is to have the simplefb node with all its resources in the DTS but with status = "disabled". The bootloader should only fill the information about the framebuffer memory region (location and size, width, height, format, etc) and change the simplefb node status to "okay". If a FDT does not have a simplefb node then the bootloader can create one (like is made for the /choosen node in most bootloaders). That will better document which resources are really used when someone reads the DTS and also avoid duplicating code in the bootloaders to fill all the information about resources but is just my humble opinion and I really don't want to bikesheed more on this. Best regards, Javier -- 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
