On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > Hi, > > On 10/02/2014 04:41 PM, jonsmirl@xxxxxxxxx wrote: >> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >>> Hi, >>> >>> On 10/02/2014 04:16 PM, jonsmirl@xxxxxxxxx wrote: >>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > <snip> > >>>>>> So there are two ways to do this... >>>>>> 1) modify things like earlyconsole to protect device specific resource >>>>>> (I think this is a bad idea) >>>>> >>>>> Why is this a bad idea? If the bootloader tells us exactly which resources >>>>> are needed, then earlyconsole can claim them, and release them on >>>>> handover to the real display driver. >>> >>> Jon, can you please answer this ? I really really want to know why people >>> think this is such a bad idea. Understanding why people think this is a bad >>> idea is necessary to be able to come up with an alternative solution. >> >> The list of resources should not be duplicated in the device tree - >> once in the simplefb node and again in the real device node. > > It is not duplicated, the simplefb node will list the clocks used for the > mode / output as setup by the firmware, which are often not all clocks > which the display engine supports. Where as the real device node will list > all clocks the display engine may use. > >> Device >> tree is a hardware description and it is being twisted to solve a >> software issue. > > This is not true, various core devicetree developers have already said > that storing other info in the devicetree is fine, and being able to do so > is part of the original design. > >> This problem is not limited to clocks, same problem >> exists with regulators. On SGI systems this would exist with entire >> bus controllers (but they are x86 based, console is not on the root >> bus). This is a very messy problem and will lead to a Frankenstein >> sized driver over time. > > This is a "what if ..." argument, we can discuss potential hypothetical > problems all day long, what happens if the sky falls down? > >> But... I think this is a red herring which is masking the real >> problem. The real problem seems to be that there is no window for >> loading device specific drivers before the resource clean up phase >> happens. That's a real problem -- multi architecture distros are going >> to have lots of loadable device specific drivers. > > As Maxime pointed out to my alternative solution to fixing the clocks > problem, this is not strictly a when to do cleanup problem. If another > driver uses the same clocks, and does a clk_disable call after probing > (because the device is put in low power mode until used by userspace), > then the clk will be disabled even without any cleanup running at all. > > The real problem here is simply that to work the simplefb needs certain > resources, just like any other device. And while for any other device > simply listing the needed resources is an accepted practice, for simplefb > for some reason (which I still do not understand) people all of a sudden > see listing resources as a problem. Because you are creating two different device tree nodes describing a single piece of hardware and that's not suppose to happen in a device tree. The accurate description of the hardware is being perverted to solve a software problem. One node describes the hardware in a format to make simplefb happy. Another node describes the same hardware in a format to make the device specific driver happy. > > Regards, > > Hans > > -- > You received this message because you are subscribed to the Google Groups "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@xxxxxxxxxxxxxxxx. > For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsmirl@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
