Hi, On 10/02/2014 02:56 PM, [email protected] wrote: > On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <[email protected]> wrote: >> Hi, >> >> On 10/02/2014 02:22 PM, [email protected] wrote: >>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <[email protected]> wrote: >>>> Hi, >>>> >>>> On 10/01/2014 08:12 PM, Stephen Warren wrote: >>>>> On 10/01/2014 11:54 AM, [email protected] wrote: >>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <[email protected]> >>>>>> wrote: >>>>> ... >>>>>>> We've been over all this again and again and again. >>>>>>> >>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH! >>>>>>> >>>>>>> All solutions provided sofar are both tons more complicated, then the >>>>>>> simple solution of simply having the simplefb dt node declare which >>>>>>> clocks it needs. And to make things worse all of them sofar have >>>>>>> unresolved issues (due to their complexity mostly). >>>>>>> >>>>>>> With the clocks in the simplefb node, then all a real driver has to do, >>>>>>> is claim those same clocks before unregistering the simplefb driver, >>>>>>> and everything will just work. >>>>>>> >>>>>>> Yet we've been discussing this for months, all because of some >>>>>>> vague worries from Thierry, and *only* from Thierry that this will >>>>>>> make simplefb less generic / not abstract enough, while a simple >>>>>>> generic clocks property is about as generic as things come. >>>>> >>>>> Note: I haven't been following this thread, and really don't have the >>>>> time to get involved, but I did want to point out one thing: >>>>> >>>>> As I think I mentioned very early on in this thread, one of the big >>>>> concerns when simplefb was merged was that it would slowly grow and >>>>> become a monster. As such, a condition of merging it was that it would >>>>> not grow features like resource management at all. That means no >>>>> clock/regulator/... support. It's intended as a simple stop-gap between >>>>> early platform bringup and whenever a real driver exists for the HW. If >>>>> you need resource management, write a HW-specific driver. The list >>>>> archives presumably have a record of the discussion, but I don't know the >>>>> links off the top of my head. If nobody >>>>> other than Thierry is objecting, presumably the people who originally >>>>> objected simply haven't noticed this patch/thread. I suppose it's >>>>> possible they changed their mind. >>>>> >>>>> BTW, there's no reason that the simplefb code couldn't be refactored out >>>>> into a support library that's used by both the simplefb we currently have >>>>> and any new HW-specific driver. It's just that the simplefb binding and >>>>> driver shouldn't grow. >>>> >>>> The whole reason why we want to use simplefb is not just to get things >>>> running until HW specific driver is in place, but also to have early >>>> console >>>> output (to help debugging boot problems on devices without a serial >>>> console), >>>> in a world where most video drivers are build as loadable modules, so we >>>> won't have video output until quite late into the boot process. >>> >>> You need both. >>> >>> 1) temporary early boot console -- this is nothing but an address in >>> RAM and the x/y layout. The character set from framebuffer is built >>> into the kernel. The parallel to this is early-printk and how it uses >>> the UARTs without interrupts. This console vaporizes late in the boot >>> process -- the same thing happens with the early printk UART driver. >>> EARLYPRINTK on the command line enables this. >>> >>> 2) a device specific driver -- this sits on initrd and it loaded as >>> soon as possible. The same thing happens with the real UART driver for >>> the console. CONSOLE= on the command line causes the transition. There >>> is an API in the kernel to do this transition, I believe it is called >>> set_console() but it's been a while. >> >> Eventually we need both, yes. But 1) should stay working until 2) loads, >> not until some phase of the bootup is completed, but simply until 2) loads. > > No, that is where you get into trouble. The device specific driver has > to go onto initrd where it can be loaded as early in the boot process > as possible.
This is an argument in the "you cannot do that" / "your use case is not valid" category, IOW this is not a technical argument. You say I cannot do that I say I can, deadlock. I've already explained that we not only can do that (we already have working code proving that), but also that this is something which we absolutely need: >> One example why this is necessary is e.g. to debug things where the problem >> is that the right module is not included in the initrd. If we ever want ARM support to stop being about cute embedded non-sense hacks, we must be able to have users get some meaningful output in failure cases like this without needing to first solder a serial console to some test pads. 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.
