On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek <hramrach@xxxxxxxxx> wrote: > On 2 October 2014 14:56, jonsmirl@xxxxxxxxx <jonsmirl@xxxxxxxxx> wrote: >> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >>> Hi, >>> >>> On 10/02/2014 02:22 PM, jonsmirl@xxxxxxxxx wrote: >>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >>>>> Hi, >>>>> >>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote: >>>>>> On 10/01/2014 11:54 AM, jonsmirl@xxxxxxxxx wrote: >>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@xxxxxxxxxx> 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. >> >> Trying to indefinitely extend the life of the earlyprintk or >> earlyframeuffer is what causes problems. Doing that forces you to >> basically turn them into device specific drivers which do things like >> claiming device specific resources and gaining device specific >> dependency knowledge, things that shouldn't be in earlyframebuffer. >> > > No. When initrd is running boot has already finished as far as kernel > is concerned. > > And you have to extend the life of the simplefb from the time boot has > finished through the time kernel mounts initrd (or other root) and > hands over to userspace found on the initrd, through the time this > userspace searches for the kms driver and until the time it has > finally loaded if that ever succeeds. Does the clock and regulator cleanup happen before drivers can load off from initrd? I didn't think it did but I might be wrong. So maybe a solution to this is to delay that cleanup until after initrd drivers have a chance to load. Of course it is not possible to delay it indefinitely (like for disk based loading) but delaying over initrd is a fixed limit. > > From the point of view of kernel once it has handed over to init in > initrd the boot is finished. The init is normal userspace running off > normal filesystem backed by a device-specific driver (initrd). > > That some systems do not continue to run off this filesystem > indefinitely and in fact go out of their way to expunge the initrd > filesystem and reclaim its resources by exercising some syscalls > specifically devised for that use case is not relevant to the kernel. > It cannot know when the userspace considers the boot finished enough. > Sometimes even manual steps are required to finish booting when the > automatic scripts fail. > > simplefb as early console is meant exactly for diagnosing and fixing > such failures in absence of an uart. > > Thanks > > Michal > > -- > 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
