Hi, On 08/13/2014 12:16 PM, Koen Kooi wrote: > > Op 13 aug. 2014, om 10:36 heeft Hans de Goede <[email protected]> het > volgende geschreven: > >> Hi, >> >> On 08/13/2014 10:21 AM, Koen Kooi wrote: >>> >>> Op 13 aug. 2014, om 09:54 heeft David Herrmann <[email protected]> het >>> volgende geschreven: >>> >>>> Hi >>>> >>>> On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <[email protected]> wrote: >>>>> This is needed for the sunxi platform, where the u-boot initialized >>>>> display >>>>> engine gets disabled by the clocks framework if certain clocks are not >>>>> claimed. Once these clocks are disabled, register content is lost, and >>>>> there >>>>> is no turning back unless a full display driver is loaded, which kind of >>>>> beats the purpose of having simplefb running. >>>>> >>>>> The lack of clock handling should plague more hardware, but so far rpi is >>>>> the >>>>> best known user of simplefb, and its stepmotherly handling of the arm core >>>>> has kept these sort of issues from the kernel. >>>>> >>>>> The sunxi u-boot side code can be found here: >>>>> https://groups.google.com/forum/#!topic/linux-sunxi/dPs958sIXvY >>>>> >>>>> Patch 3 might be controversial, as this does not achieve anything real >>>>> today, >>>>> since the status property in dt is only really evaluated when dealing >>>>> with a >>>>> nodes memory. It still seems like a good idea to at least flag this >>>>> memory or >>>>> node as disabled, as we really have no way back when the clocks get >>>>> disabled. >>>> >>>> Hans de Goede shortly told me about this and, tbh, I am not very >>>> pleased. Stephen tried to keep simplefd "as simple as possible", your >>>> patch now adds hardware-specific features. To be fair, the patch is >>>> simple and clocks are easy to handle, but I somehow fear we have to >>>> add more and more hardware-support that is required to keep the >>>> framebuffer active. This really defeats the purpose of simplefb. >>>> >>>> The biggest question I have, is why do you add the clocks to your DT >>>> at all? The framebuffer is set up by your boot-loader (or maybe >>>> platform code) and should prepare the clocks. I don't see why we add >>>> the clocks to DT now. If they're not added, then no-one will disable >>>> them and simplefb works just fine, right? >>> >>> All clocks known to linux without a consumer will get disabled on most >>> (all?) ARM systems to save power. Years ago OMAP had a Kconfig option to >>> change that behaviour and add printk warnings for the clocks it would >>> touch. >>> To be honest, I don't get why sunxi needs a simplefb to begin with, only a >>> proper kms/drm driver is needed which would register the clocks it needs >>> properly. These patches and discussion seem like a lot of effort wasted on >>> the wrong thing. But I can't complain about that since I'm not the one >>> doing the work. >> >> I believe that having some simple generic fb driver will be useful >> on non x86, since we don't have vga-console there, and most distros >> will build kms drivers as modules. Having the kernel / initrd code being >> able to show output (like e.g. missing symbols in the kms drivers) seems >> a very useful feature to me. >> >> The way I envision this to work is: >> >> u-boot lights up display, if it fails to load the kernel / ftd / ramdisk, >> it can show this on the display >> >> kernel takes over using something like simplefb (built into the kernel) >> for its initial output / any error messages. >> >> initrd loads kms, kms takes over. >> >> This way we've a way to show error messages during boot at all times. >> >> As we start supporting more ARM htpc boxes out of the box, telling the >> user to hook up a serial console (which often involves soldering wires >> to some test points) when things don't work really is not a viable >> answer. > > So what you are saying is that the only reason it is needed is because some > distros choose to build DRM drivers as modules. So as soon as they stop doing > that the problem goes away, right?
Right, except that that is not going to happen, see David's reply also. 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
