* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-02 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20141002141849.GD4039@lukather>
Hi,
On 10/02/2014 04:18 PM, Maxime Ripard wrote:
> On Thu, Oct 02, 2014 at 04:08:52PM +0200, Hans de Goede wrote:
>>> 2) delay the clock/regulator cleanup until after there is a fixed
>>> window for device specific drivers to load in. Loading from initrd is
>>> a fixed window.
>>
>> As I already explained by example in another mail, this won't work:
>>
>> "delaying over the initrd is not helpful. Not having the real driver
>> load for whatever reasons, is not necessarily a boot blocking event,
>> and if it us just missing will not lead to any error messages.
>>
>> So the boot will continue normally with a black screen, and things are
>> still impossible to debug."
>
> Plus:
>
> 1) you might not have an initrd, which doesn't change a thing: your
> clock get disabled before you can load your driver
>
> 2) you might not have a rootfs, and no driver to load, which would
> leave the clock enabled forever.
>
>> We've been down the whole delay till $random point in time thing in the
>> past with storage enumeration, where you need to wait for say all members
>> of a raid set to show up. The lesson learned from that is that you should
>> not wait $random time / event, but wait for the actual storage device to
>> show up.
>>
>> And this is just like that, we need to wait for the actual display driver
>> to have loaded and taken over before "cleaning up" the clocks used by
>> the display engine.
>>
>> I guess we could just delay all clock cleanup until then, not really
>> pretty, and I still prefer to just list the clocks in the simplefb
>> dtnode, but if this version would be acceptable to all involved, I can
>> live with it.
>>
>> Mike, would a patch adding 2 calls like these to the clock core be
>> acceptable ? :
>>
>> clk_block_disable_unused()
>> clk_unblock_disable_unused()
>
> Thierry actually already made such a patch somewhere in this
> thread. The thing is that it should also block clk_disable (and all
> the potential users of clk_disable: clk_set_rate, clk_set_parent,
> etc.) from actually disabling them. Otherwise, you might still end up
> with your clock disabled.
A valid point, which brings us back to simply adding the clocks to the
dt node really being both the simplest solution, as well as the only
solution without any pitfalls.
Regards,
Hans
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-02 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4OxHeHszmcbMw_LRJbcaFW5JP7Atsa4RMRwWfqMrCueAnQ@mail.gmail.com>
Hi,
On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 03:40 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 03:27 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>>>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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.
>>>>>
>>>>> It is certainly possible to extend an earlyframebuffer to be able to
>>>>> run as a user space console. It is just going to turn into a
>>>>> Frankenmonster driver with piles of device specific, special case code
>>>>> in it.
>>>>
>>>> There is nothing hardware specific about a framebuffer needing some
>>>> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
>>>> that is hardware specific, but the framebuffer driver does not need to
>>>> worry about that, it just sees a clocks property with some random clocks
>>>> in there, and that is as generic as it gets.
>>>>
>>>>> I think that device specific code belongs in a device specific driver
>>>>> and earlyframebuffer should handoff to it as soon as possible.
>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> A generic earlyframebuffer would show this error.
>>>>
>>>> If it reserves the clocks it needs, yes. If it does not then the clocks will
>>>> be disabled before the initrd starts, and the screen will be black from then
>>>
>>> I thought the clock/regulator clean up happened after initrd loading,
>>> but maybe that is not the case.
>>>
>>> A cleaner solution would then be to modify the clock/regulator clean
>>> up to happen after driver loading is finished from initrd. Deferring
>>> until after that completes is a fixed limit, everything is sitting
>>> there in RAM. I would not propose extending it until harddisk based
>>> loading happens.
>>>
>>> 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.
>>
>>> 2) delay the clock/regulator cleanup until after there is a fixed
>>> window for device specific drivers to load in. Loading from initrd is
>>> a fixed window.
>>
>> As I already explained by example in another mail, this won't work:
>>
>> "delaying over the initrd is not helpful. Not having the real driver
>> load for whatever reasons, is not necessarily a boot blocking event,
>> and if it us just missing will not lead to any error messages.
>>
>> So the boot will continue normally with a black screen, and things are
>> still impossible to debug."
>>
>> We've been down the whole delay till $random point in time thing in the
>> past with storage enumeration, where you need to wait for say all members
>> of a raid set to show up. The lesson learned from that is that you should
>> not wait $random time / event, but wait for the actual storage device to
>> show up.
>>
>> And this is just like that, we need to wait for the actual display driver
>> to have loaded and taken over before "cleaning up" the clocks used by
>> the display engine.
>>
>> I guess we could just delay all clock cleanup until then, not really
>> pretty, and I still prefer to just list the clocks in the simplefb
>> dtnode, but if this version would be acceptable to all involved, I can
>> live with it.
>>
>> Mike, would a patch adding 2 calls like these to the clock core be
>> acceptable ? :
>>
>> clk_block_disable_unused()
>> clk_unblock_disable_unused()
>>
>> Where an earlyconsole driver can then call clk_block_disable_unused(),
>> which will turn any calls to clk_disable_unused into a nop.
>
> Is there a way to use the existing eprobe_defer system to do this?
No, that is not what it is intended for (at all). If we go this way
2 subsystem specific calls for this is the best way to deal with this.
Regards,
Hans
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Maxime Ripard @ 2014-10-02 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542D5C74.4050602@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2178 bytes --]
On Thu, Oct 02, 2014 at 04:08:52PM +0200, Hans de Goede wrote:
> > 2) delay the clock/regulator cleanup until after there is a fixed
> > window for device specific drivers to load in. Loading from initrd is
> > a fixed window.
>
> As I already explained by example in another mail, this won't work:
>
> "delaying over the initrd is not helpful. Not having the real driver
> load for whatever reasons, is not necessarily a boot blocking event,
> and if it us just missing will not lead to any error messages.
>
> So the boot will continue normally with a black screen, and things are
> still impossible to debug."
Plus:
1) you might not have an initrd, which doesn't change a thing: your
clock get disabled before you can load your driver
2) you might not have a rootfs, and no driver to load, which would
leave the clock enabled forever.
> We've been down the whole delay till $random point in time thing in the
> past with storage enumeration, where you need to wait for say all members
> of a raid set to show up. The lesson learned from that is that you should
> not wait $random time / event, but wait for the actual storage device to
> show up.
>
> And this is just like that, we need to wait for the actual display driver
> to have loaded and taken over before "cleaning up" the clocks used by
> the display engine.
>
> I guess we could just delay all clock cleanup until then, not really
> pretty, and I still prefer to just list the clocks in the simplefb
> dtnode, but if this version would be acceptable to all involved, I can
> live with it.
>
> Mike, would a patch adding 2 calls like these to the clock core be
> acceptable ? :
>
> clk_block_disable_unused()
> clk_unblock_disable_unused()
Thierry actually already made such a patch somewhere in this
thread. The thing is that it should also block clk_disable (and all
the potential users of clk_disable: clk_set_rate, clk_set_parent,
etc.) from actually disabling them. Otherwise, you might still end up
with your clock disabled.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Michal Suchanek @ 2014-10-02 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4OxTmNRxSJum17RZGLLku5dAFPauzqyP0BOF-VC=bD=Hng@mail.gmail.com>
On 2 October 2014 15:40, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 03:27 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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.
>>>
>>> It is certainly possible to extend an earlyframebuffer to be able to
>>> run as a user space console. It is just going to turn into a
>>> Frankenmonster driver with piles of device specific, special case code
>>> in it.
>>
>> There is nothing hardware specific about a framebuffer needing some
>> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
>> that is hardware specific, but the framebuffer driver does not need to
>> worry about that, it just sees a clocks property with some random clocks
>> in there, and that is as generic as it gets.
>>
>>> I think that device specific code belongs in a device specific driver
>>> and earlyframebuffer should handoff to it as soon as possible.
>>>
>>>>
>>>> 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.
>>>
>>> A generic earlyframebuffer would show this error.
>>
>> If it reserves the clocks it needs, yes. If it does not then the clocks will
>> be disabled before the initrd starts, and the screen will be black from then
>
> I thought the clock/regulator clean up happened after initrd loading,
> but maybe that is not the case.
>
> A cleaner solution would then be to modify the clock/regulator clean
> up to happen after driver loading is finished from initrd. Deferring
> until after that completes is a fixed limit, everything is sitting
> there in RAM. I would not propose extending it until harddisk based
> loading happens.
>
> 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)
> 2) delay the clock/regulator cleanup until after there is a fixed
> window for device specific drivers to load in. Loading from initrd is
> a fixed window.
Fixed window is timeout.
Time and time again timeouts break.
How is loading a module from harddisk different form loading from initrd?
How is even the kernel going to tell?
How should systems that run completely off initrd behave?
How should the kernel behave during this 'fixed window'? If it cannot
touch resources that were in enabled or unknown state at boot how can
it allocate resources for newly loaded drivers?
Or to put it differently: when the firmware inserts dynamically at
boot time or the DT writer statically at compile time the resources
which are needed by console then kernel knows that the *other* stuff
that has been enabled by firmware or for which it cannot be determined
if it's enabled or not can be reused.
For example, if the firmware loaded the kernel from mmc or just probed
mmc the mmc clocks have been likely left enabled. You need to
reprogram mmc clocks to access mmc most of the time. If you assume no
knowledge of hardware then you cannot know that mmc clocks are not
used for console and cannot touch them. Hence if loading a kms driver
fails in initrd you are needlessly locked out of loading system from
mmc.
I am sure you can find other examples for both clocks or other
resources so the solution to properly name what you need for the
console to keep running is more scalable.
If your board is simple you might get away with a static DT. If you do
not care about early graphics you can just drop it.
BTW this has *also* been discussed here, at length.
Thanks
Michal
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: jonsmirl @ 2014-10-02 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542D5C74.4050602@redhat.com>
On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 03:40 PM, jonsmirl@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 03:27 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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.
>>>>
>>>> It is certainly possible to extend an earlyframebuffer to be able to
>>>> run as a user space console. It is just going to turn into a
>>>> Frankenmonster driver with piles of device specific, special case code
>>>> in it.
>>>
>>> There is nothing hardware specific about a framebuffer needing some
>>> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
>>> that is hardware specific, but the framebuffer driver does not need to
>>> worry about that, it just sees a clocks property with some random clocks
>>> in there, and that is as generic as it gets.
>>>
>>>> I think that device specific code belongs in a device specific driver
>>>> and earlyframebuffer should handoff to it as soon as possible.
>>>>
>>>>>
>>>>> 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.
>>>>
>>>> A generic earlyframebuffer would show this error.
>>>
>>> If it reserves the clocks it needs, yes. If it does not then the clocks will
>>> be disabled before the initrd starts, and the screen will be black from then
>>
>> I thought the clock/regulator clean up happened after initrd loading,
>> but maybe that is not the case.
>>
>> A cleaner solution would then be to modify the clock/regulator clean
>> up to happen after driver loading is finished from initrd. Deferring
>> until after that completes is a fixed limit, everything is sitting
>> there in RAM. I would not propose extending it until harddisk based
>> loading happens.
>>
>> 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.
>
>> 2) delay the clock/regulator cleanup until after there is a fixed
>> window for device specific drivers to load in. Loading from initrd is
>> a fixed window.
>
> As I already explained by example in another mail, this won't work:
>
> "delaying over the initrd is not helpful. Not having the real driver
> load for whatever reasons, is not necessarily a boot blocking event,
> and if it us just missing will not lead to any error messages.
>
> So the boot will continue normally with a black screen, and things are
> still impossible to debug."
>
> We've been down the whole delay till $random point in time thing in the
> past with storage enumeration, where you need to wait for say all members
> of a raid set to show up. The lesson learned from that is that you should
> not wait $random time / event, but wait for the actual storage device to
> show up.
>
> And this is just like that, we need to wait for the actual display driver
> to have loaded and taken over before "cleaning up" the clocks used by
> the display engine.
>
> I guess we could just delay all clock cleanup until then, not really
> pretty, and I still prefer to just list the clocks in the simplefb
> dtnode, but if this version would be acceptable to all involved, I can
> live with it.
>
> Mike, would a patch adding 2 calls like these to the clock core be
> acceptable ? :
>
> clk_block_disable_unused()
> clk_unblock_disable_unused()
>
> Where an earlyconsole driver can then call clk_block_disable_unused(),
> which will turn any calls to clk_disable_unused into a nop.
Is there a way to use the existing eprobe_defer system to do this?
>
> And when the earlyconsole gets unregistered because the real driver
> takes over, it calls clk_unblock_disable_unused(), which then checks if
> clk_disable_unused() has already been called (iow check if we're post
> late_init), and if it has calls clk_disable_unused() at that time.
>
> If this is acceptable I can whip up a patch for this.
>
> 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@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-02 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4OxTmNRxSJum17RZGLLku5dAFPauzqyP0BOF-VC=bD=Hng@mail.gmail.com>
Hi,
On 10/02/2014 03:40 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 03:27 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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.
>>>
>>> It is certainly possible to extend an earlyframebuffer to be able to
>>> run as a user space console. It is just going to turn into a
>>> Frankenmonster driver with piles of device specific, special case code
>>> in it.
>>
>> There is nothing hardware specific about a framebuffer needing some
>> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
>> that is hardware specific, but the framebuffer driver does not need to
>> worry about that, it just sees a clocks property with some random clocks
>> in there, and that is as generic as it gets.
>>
>>> I think that device specific code belongs in a device specific driver
>>> and earlyframebuffer should handoff to it as soon as possible.
>>>
>>>>
>>>> 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.
>>>
>>> A generic earlyframebuffer would show this error.
>>
>> If it reserves the clocks it needs, yes. If it does not then the clocks will
>> be disabled before the initrd starts, and the screen will be black from then
>
> I thought the clock/regulator clean up happened after initrd loading,
> but maybe that is not the case.
>
> A cleaner solution would then be to modify the clock/regulator clean
> up to happen after driver loading is finished from initrd. Deferring
> until after that completes is a fixed limit, everything is sitting
> there in RAM. I would not propose extending it until harddisk based
> loading happens.
>
> 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.
> 2) delay the clock/regulator cleanup until after there is a fixed
> window for device specific drivers to load in. Loading from initrd is
> a fixed window.
As I already explained by example in another mail, this won't work:
"delaying over the initrd is not helpful. Not having the real driver
load for whatever reasons, is not necessarily a boot blocking event,
and if it us just missing will not lead to any error messages.
So the boot will continue normally with a black screen, and things are
still impossible to debug."
We've been down the whole delay till $random point in time thing in the
past with storage enumeration, where you need to wait for say all members
of a raid set to show up. The lesson learned from that is that you should
not wait $random time / event, but wait for the actual storage device to
show up.
And this is just like that, we need to wait for the actual display driver
to have loaded and taken over before "cleaning up" the clocks used by
the display engine.
I guess we could just delay all clock cleanup until then, not really
pretty, and I still prefer to just list the clocks in the simplefb
dtnode, but if this version would be acceptable to all involved, I can
live with it.
Mike, would a patch adding 2 calls like these to the clock core be
acceptable ? :
clk_block_disable_unused()
clk_unblock_disable_unused()
Where an earlyconsole driver can then call clk_block_disable_unused(),
which will turn any calls to clk_disable_unused into a nop.
And when the earlyconsole gets unregistered because the real driver
takes over, it calls clk_unblock_disable_unused(), which then checks if
clk_disable_unused() has already been called (iow check if we're post
late_init), and if it has calls clk_disable_unused() at that time.
If this is acceptable I can whip up a patch for this.
Regards,
Hans
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Michal Suchanek @ 2014-10-02 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4Oyb3KBWhGgKfwNop7+cwR=p=ZpVs-jfH0iQwm5scfOJ-A@mail.gmail.com>
On 2 October 2014 15:27, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>
>>>>> 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.
>
> It is certainly possible to extend an earlyframebuffer to be able to
> run as a user space console. It is just going to turn into a
> Frankenmonster driver with piles of device specific, special case code
> in it.
What is device specific about code that reads a list of clocks and
just asks tells kernel it uses them all?
That's been discussed to death in this thread already.
>
> I think that device specific code belongs in a device specific driver
> and earlyframebuffer should handoff to it as soon as possible.
Even it that case it needs to tell the kernel it needs the clocks so
that they are not shut of until that handoff happens.
>
>>
>> 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.
>
> A generic earlyframebuffer would show this error.
>
> Just use earlyprintk as a guideline, if earlyprintk shows the error
> earlyframebuffer would also show it.
>
It does not. It hands off to an uart driver built into the kernel. The
handoff is broken on sunxi and the earlyprintk continues to work
indefinitely replicating all kernel messages twice on the serial
console unless something happens to reconfigure the uart used for
earlyprink later on. When that does happen the early console can fail
very early, even way before the time you would load an initrd. It just
happens to work most of the time because when you use earlyprintk most
of the time you also use serial console with the same parameters on
the same pins.
Thanks
Michal
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: jonsmirl @ 2014-10-02 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXLf3iVFOxFa__xf17tFGD_tFFr0FLnEgJeQP4xz17YCA@mail.gmail.com>
On Thu, Oct 2, 2014 at 9:46 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Oct 2, 2014 at 3:34 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> 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.
>
> Yes
>
> drivers/base/power/domain.c:late_initcall(genpd_poweroff_unused);
> drivers/clk/clk.c:late_initcall_sync(clk_disable_unused);
> drivers/regulator/core.c:late_initcall_sync(regulator_init_complete);
I think this is the basic problem, we need to open a window where
drivers can be loaded before the clock/regulator clean up happens.
That window needs to be fixed length (ie Ramdisk based loading).
This is a core problem in a multi-architecture kernel, we need to get
the device specific drivers loaded before this clean up happens.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Geert Uytterhoeven @ 2014-10-02 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4Ow4WU8yhy+LKGgKfvS8E15MU=gfRoZXNW6AWGOBVPG8SQ@mail.gmail.com>
On Thu, Oct 2, 2014 at 3:34 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> 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.
Yes
drivers/base/power/domain.c:late_initcall(genpd_poweroff_unused);
drivers/clk/clk.c:late_initcall_sync(clk_disable_unused);
drivers/regulator/core.c:late_initcall_sync(regulator_init_complete);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: jonsmirl @ 2014-10-02 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542D55C0.4020306@redhat.com>
On Thu, Oct 2, 2014 at 9:40 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 03:34 PM, jonsmirl@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek <hramrach@gmail.com> wrote:
>>> On 2 October 2014 14:56, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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.
>
> Yes the cleanup happens before the first userspace process starts, be
> that the fake /sbin/init from the initrd, or the real /sbin/init if
> no initrd is used.
Does that init have to be running to get device drivers off from
initrd? I thought the kernel was able to load them directly from
initrd earlier.
>
>> 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.
>
> And delaying over the initrd is not helpful. Not having the real driver
> load for whatever reasons, is not necessarily a boot blocking event,
> and if it us just missing will not lead to any error messages.
>
> So the boot will continue normally with a black screen, and things are
> still impossible to debug.
>
> Regards,
>
> Hans
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: jonsmirl @ 2014-10-02 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542D5444.8090903@redhat.com>
On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 03:27 PM, jonsmirl@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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.
>>
>> It is certainly possible to extend an earlyframebuffer to be able to
>> run as a user space console. It is just going to turn into a
>> Frankenmonster driver with piles of device specific, special case code
>> in it.
>
> There is nothing hardware specific about a framebuffer needing some
> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
> that is hardware specific, but the framebuffer driver does not need to
> worry about that, it just sees a clocks property with some random clocks
> in there, and that is as generic as it gets.
>
>> I think that device specific code belongs in a device specific driver
>> and earlyframebuffer should handoff to it as soon as possible.
>>
>>>
>>> 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.
>>
>> A generic earlyframebuffer would show this error.
>
> If it reserves the clocks it needs, yes. If it does not then the clocks will
> be disabled before the initrd starts, and the screen will be black from then
I thought the clock/regulator clean up happened after initrd loading,
but maybe that is not the case.
A cleaner solution would then be to modify the clock/regulator clean
up to happen after driver loading is finished from initrd. Deferring
until after that completes is a fixed limit, everything is sitting
there in RAM. I would not propose extending it until harddisk based
loading happens.
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)
2) delay the clock/regulator cleanup until after there is a fixed
window for device specific drivers to load in. Loading from initrd is
a fixed window.
Two seems to me to be the better solution.
> on.
>
> 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@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-02 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4Ow4WU8yhy+LKGgKfvS8E15MU=gfRoZXNW6AWGOBVPG8SQ@mail.gmail.com>
Hi,
On 10/02/2014 03:34 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek <hramrach@gmail.com> wrote:
>> On 2 October 2014 14:56, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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.
Yes the cleanup happens before the first userspace process starts, be
that the fake /sbin/init from the initrd, or the real /sbin/init if
no initrd is used.
> 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.
And delaying over the initrd is not helpful. Not having the real driver
load for whatever reasons, is not necessarily a boot blocking event,
and if it us just missing will not lead to any error messages.
So the boot will continue normally with a black screen, and things are
still impossible to debug.
Regards,
Hans
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: jonsmirl @ 2014-10-02 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMqctSnmN3YScH8+hCkmEVB076u=VsCAJVTz5=NEYzQJpYR6A@mail.gmail.com>
On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek <hramrach@gmail.com> wrote:
> On 2 October 2014 14:56, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-02 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4Oyb3KBWhGgKfwNop7+cwR=p=ZpVs-jfH0iQwm5scfOJ-A@mail.gmail.com>
Hi,
On 10/02/2014 03:27 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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.
>
> It is certainly possible to extend an earlyframebuffer to be able to
> run as a user space console. It is just going to turn into a
> Frankenmonster driver with piles of device specific, special case code
> in it.
There is nothing hardware specific about a framebuffer needing some
clocks to not be disabled. Tons of SoC's will have this. Which clocks,
that is hardware specific, but the framebuffer driver does not need to
worry about that, it just sees a clocks property with some random clocks
in there, and that is as generic as it gets.
> I think that device specific code belongs in a device specific driver
> and earlyframebuffer should handoff to it as soon as possible.
>
>>
>> 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.
>
> A generic earlyframebuffer would show this error.
If it reserves the clocks it needs, yes. If it does not then the clocks will
be disabled before the initrd starts, and the screen will be black from then
on.
Regards,
Hans
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: jonsmirl @ 2014-10-02 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542D4FB9.6090805@redhat.com>
On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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.
It is certainly possible to extend an earlyframebuffer to be able to
run as a user space console. It is just going to turn into a
Frankenmonster driver with piles of device specific, special case code
in it.
I think that device specific code belongs in a device specific driver
and earlyframebuffer should handoff to it as soon as possible.
>
> 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.
A generic earlyframebuffer would show this error.
Just use earlyprintk as a guideline, if earlyprintk shows the error
earlyframebuffer would also show it.
>
> 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 linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Michal Suchanek @ 2014-10-02 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4OwOFVFZjxN-SJpDJLcyCpNOT4_mjjr9OpgGXmTYvZwT+A@mail.gmail.com>
On 2 October 2014 14:56, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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.
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
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-02 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4OwOFVFZjxN-SJpDJLcyCpNOT4_mjjr9OpgGXmTYvZwT+A@mail.gmail.com>
Hi,
On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: jonsmirl @ 2014-10-02 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542D476D.50004@redhat.com>
On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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.
>
> Which means we must reserve necessary resources so that they don't get
> disabled until 2 loads.
>
> 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.
>
> Regards,
>
> Hans
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] fonts: Add 6x10 font
From: One Thousand Gnomes @ 2014-10-02 12:40 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Maarten ter Huurne, Jean-Christophe Plagniol-Villard,
Geert Uytterhoeven, Apelete Seketeli, linux-fbdev, linux-kernel
In-Reply-To: <542A7ADA.4010500@ti.com>
On Tue, 30 Sep 2014 12:41:46 +0300
Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi,
>
> On 09/09/14 14:46, Maarten ter Huurne wrote:
> > This font is suitable for framebuffer consoles on devices with a
> > 320x240 screen, to get a reasonable number of characters (53x24) that
> > are still at a readable size.
> >
> > The font is derived from the existing 6x11 font, but gets 3 extra
> > lines without sacrificing readability. Also I redesigned a some glyhps
> > so they are more distinct and better fill the available space.
> >
> > Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
> > ---
> > include/linux/font.h | 4 +-
> > lib/fonts/Kconfig | 9 +
> > lib/fonts/Makefile | 1 +
> > lib/fonts/font_6x10.c | 3086 +++++++++++++++++++++++++++++++++++++++++++++++++
> > lib/fonts/fonts.c | 4 +
> > 5 files changed, 3103 insertions(+), 1 deletion(-)
> > create mode 100644 lib/fonts/font_6x10.c
>
> I think the patch is fine, but there hasn't been any comments or acks
> for this. I'm a bit reluctant to add this much data to the kernel if
> there are no users (except you) for this.
>
> So I'd like to hear at least one "yeah, I could maybe use that font"
> from someone =).
It only going to get linked if someone asks for it so that seems ok to
me. We support a variety of panels and the like with 320x240 displays and
ucLinux platforms so IMHO it makes sense to have such a font available.
I am planning to use the font - just ermm.. not in Linux ;)
Alan
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-02 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4Oy8sZ-d6JzWLi7pUeNFE5ge0fr5Tgoc_PSpKcOoiN-0yQ@mail.gmail.com>
Hi,
On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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.
Which means we must reserve necessary resources so that they don't get
disabled until 2 loads.
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.
Regards,
Hans
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: jonsmirl @ 2014-10-02 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542CF3C3.2050708@redhat.com>
On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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.
>
> This is also the reason why we're working on adding hdmi console support
> to u-boot in the first place, to debug boot problems.
>
> So the whole "write a HW specific driver" answer just does not cut it. Just
> like we have vgacon / efifb on x86, we need something similar on ARM, and
> since ARM does not have a generic hw interface like vga, we need a firmware
> solution like efifb.
>
> So as said the whole "write a HW specific driver" just will not work, so
> that means using something like simplefb. Now I can take simplefb, copy
> it to rename it to firmwarefb or ubootfb or something, and then add the clocks
> support, but that is just silly.
>
> You indicate that you don't have the time for this discussion, and I note that
> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
> my responsibility (and in my own benefit) to stop this from growing into
> a monster ?
>
> To me that seems better then adding a new drivers/video/fbdev/firmwarefb.c
> which will be just a copy with the clocks added.
>
> Regards,
>
> Hans
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Thierry Reding @ 2014-10-02 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXQ8bWCyaLiyOBKQNhB4rJDHBUzHnNMCf7_sPBtR1AKVg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]
On Wed, Oct 01, 2014 at 08:43:27PM +0200, Geert Uytterhoeven wrote:
> On Wed, Oct 1, 2014 at 7:17 PM, Mark Brown <broonie@kernel.org> wrote:
> >> Well, I don't think it should because it describes the same resources
> >> that the device tree node for the real device already describes. But
> >> perhaps this is one of the cases where duplication isn't all that bad?
> >
> > If we were worried about this wecould also do it by referring to
> > those nodes and saying "get all the resources these things need" rather
> > than duplicating the references (this might make it easier to work out
> > when the system is ready to hand off to the real drivers).
>
> You can have a single node for both simplefb and the later "real" driver.
> DT describes the hardware, not the software ecosystem running on the
> hardware. Clock, regulators, etc. don't change from a hardware point of
> view.
>
> If the firmware initialized a suitable graphics mode, it just has to add
> "linux,simplefb" to the compatible property (and perhaps a few other
> simplefb-specific properties).
Unfortunately I don't think that's going to work. Especially on ARM SoCs
there is no single node for a display device. The display device is
typically composed of several subdevices.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Thierry Reding @ 2014-10-02 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20141001171704.GG4273@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]
On Wed, Oct 01, 2014 at 06:17:04PM +0100, Mark Brown wrote:
> On Wed, Oct 01, 2014 at 02:48:53PM +0200, Thierry Reding wrote:
> > On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote:
[...]
> > > and that the DT must not contain any hint of simplefb as
> > > shipped separately.
>
> > Well, I don't think it should because it describes the same resources
> > that the device tree node for the real device already describes. But
> > perhaps this is one of the cases where duplication isn't all that bad?
>
> If we were worried about this wecould also do it by referring to
> those nodes and saying "get all the resources these things need" rather
> than duplicating the references (this might make it easier to work out
> when the system is ready to hand off to the real drivers).
That's problematic to some degree because not all resource types may
have a binding that allows them to be automatically probed, so it could
be difficult to implement "get all the resources this thing needs". But
perhaps we can come up with good enough heuristics to make that work
reliably.
One downside of that is that there may be a lot of components involved
in getting display to work and not all resources may be needed to keep
the current state running, so we may be claiming too many. But given
that we'd eventually release all of them anyway this shouldn't be too
much of an issue.
> > > That's never going to work well as far as I can see
> > > but doesn't seem like an ABI stability issue, or at least not a
> > > reasonable one.
>
> > It would work well under the assumption that the kernel wouldn't be
> > touching any of the resources that simplefb depends on. If that's not a
> > reasonable assumption then I think we can't make simplefb work the way
> > it's currently written.
>
> I can't see how that's reasonable unless the kernel has some way of
> figuring out what it shouldn't be touching.
Agreed. It's become clear in this discussion that we can't do this in
the way x86 and other more firmware-oriented architectures do it. They
get away with it because they in fact hide all of this in the firmware
or don't provide a way to control the resources in such a fine-grained
manner to begin with.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Thierry Reding @ 2014-10-02 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPtuhTgJ7TLg8CKe3pQiBeEw9s33UrYEXPj6SDCga2yAh7WfEA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5217 bytes --]
On Wed, Oct 01, 2014 at 11:17:23AM -0700, Mike Turquette wrote:
> On Wed, Oct 1, 2014 at 12:30 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Tue, Sep 30, 2014 at 02:37:53PM -0700, Mike Turquette wrote:
> >> Quoting Thierry Reding (2014-09-29 06:54:00)
> >> > On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> >> > > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> >> > > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> >> > > > > >> your clock to be shut down as a side effect of a later clk_disable
> >> > > > > >> call from another driver.
> >> > > > >
> >> > > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> >> > > > > > preceding clk_enable()? There are patches being worked on that will
> >> > > > > > enable per-user clocks and as I understand it they will specifically
> >> > > > > > disallow drivers to disable the hardware clock if other drivers are
> >> > > > > > still keeping them on via their own referenc.
> >> > > > >
> >> > > > > Calling clk_disable() preceding clk_enable() is a bug.
> >> > > > >
> >> > > > > Calling clk_disable() after clk_enable() will disable the clock (and
> >> > > > > its parents)
> >> > > > > if the clock subsystem thinks there are no other users, which is what will
> >> > > > > happen here.
> >> > > >
> >> > > > Right. I'm not sure this is really applicable to this situation, though.
> >> > >
> >> > > It's actually very easy to do. Have a driver that probes, enables its
> >> > > clock, fails to probe for any reason, call clk_disable in its exit
> >> > > path. If there's no other user at that time of this particular clock
> >> > > tree, it will be shut down. Bam. You just lost your framebuffer.
> >> > >
> >> > > Really, it's just that simple, and relying on the fact that some other
> >> > > user of the same clock tree will always be their is beyond fragile.
> >> >
> >> > Perhaps the meaning clk_ignore_unused should be revised, then. What you
> >> > describe isn't at all what I'd expect from such an option. And it does
> >> > not match the description in Documentation/kernel-parameters.txt either.
> >>
> >> From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001
> >> From: Mike Turquette <mturquette@linaro.org>
> >> Date: Tue, 30 Sep 2014 14:24:38 -0700
> >> Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused
> >>
> >> Refine the definition around clk_ignore_unused, which caused some
> >> confusion recently on the linux-fbdev and linux-arm-kernel mailing
> >> lists[0].
> >>
> >> [0] http://lkml.kernel.org/r/<20140929135358.GC30998@ulmo>
> >>
> >> Signed-off-by: Mike Turquette <mturquette@linaro.org>
> >> ---
> >> Thierry,
> >>
> >> Please let me know if this wording makes the feature more clear.
> >
> > I think that's better than before, but I don't think it's accurate yet.
> > As pointed out by Maxime unused clock may still be disabled if it's part
> > of a tree and that tree is being disabled because there are no users
> > left.
>
> It is entirely accurate. This feature does in fact "prevent the clock
> framework from *automatically* gating clock ...".
According to what Maxime said if an unused clock is a sibling (has the
same parent) of a clock that is used and then gets disabled, then if the
parent has no other clocks that are enabled, the unused clock will still
be disabled.
That's still counts as "automatically" to me. Not automatically would
mean that the clock needs to be disabled explicitly for it to become
disabled. Disabling it as a side-effect of its parent getting disabled
is still automatic.
> And it was merged by Olof so that he could use simplefb with the
> Chromebook!
And presumably it does work for that specific Chromebook. It seems,
though that for hardware with a somewhat whackier clock tree it doesn't
work so well. As far as I can tell that's the reason for this patch and
the ensuing discussion in the first place.
Although, perhaps nobody ever really tested whether or not the above
scenario was actually a problem for sunxi and maybe clk_ignore_unused
would work for them. But as I understand they don't want to use it, so
this whole debate about this kernel parameter is a bit moot.
> > What I had argued is that it's unexpected behavior, because the clock
> > is still unused (or becomes unused again), therefore shouldn't be
> > disabled at that point either.
>
> Leaving clocks enabled because nobody claimed them is not an option.
But that's exactly what clk_ignore_unused is, isn't it? I'm now totally
confused.
> > So if you want to keep the current behaviour where an unused clock can
> > still be disabled depending on what other users do, then I think it'd be
> > good to mention that as a potential caveat.
>
> Do you have a suggestion on the wording?
Perhaps something like this:
Note that if an unused clock shares a parent with clocks that
are used, the unused clock may still become disabled as a side-
effect of the parent clock being disabled when none of the
children that are used remain enabled.
?
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-02 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542C4404.8040501@wwwdotorg.org>
Hi,
On 10/01/2014 08:12 PM, Stephen Warren wrote:
> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> 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.
This is also the reason why we're working on adding hdmi console support
to u-boot in the first place, to debug boot problems.
So the whole "write a HW specific driver" answer just does not cut it. Just
like we have vgacon / efifb on x86, we need something similar on ARM, and
since ARM does not have a generic hw interface like vga, we need a firmware
solution like efifb.
So as said the whole "write a HW specific driver" just will not work, so
that means using something like simplefb. Now I can take simplefb, copy
it to rename it to firmwarefb or ubootfb or something, and then add the clocks
support, but that is just silly.
You indicate that you don't have the time for this discussion, and I note that
there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
my responsibility (and in my own benefit) to stop this from growing into
a monster ?
To me that seems better then adding a new drivers/video/fbdev/firmwarefb.c
which will be just a copy with the clocks added.
Regards,
Hans
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox