* 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: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: 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: 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: [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: 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: [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: 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: 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: 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: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: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: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: 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: 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: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: 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: 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: 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: 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: 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: 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: 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: jonsmirl @ 2014-10-02 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542D5F62.60907@redhat.com>
On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> 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.
The list of resources should not be duplicated in the device tree -
once in the simplefb node and again in the real device node. Device
tree is a hardware description and it is being twisted to solve a
software issue. This problem is not limited to clocks, same problem
exists with regulators. On SGI systems this would exist with entire
bus controllers (but they are x86 based, console is not on the root
bus). This is a very messy problem and will lead to a Frankenstein
sized driver over time.
But... I think this is a red herring which is masking the real
problem. The real problem seems to be that there is no window for
loading device specific drivers before the resource clean up phase
happens. That's a real problem -- multi architecture distros are going
to have lots of loadable device specific drivers.
This leads me into thinking that the resource cleanup is not being
done at the right time. Maybe it should be part of the housekeeping
that goes on in the system idle task or something like that. I don't
work enough with the user space transition to know the right place to
move it to.
If we can get this resource clean up sorted out, the problem with
simplefb needing a protected resource list disappears. It make sense
to me that we have to have some way of loading device specific drivers
before this clean up happens.
I'll add Linus to the list, maybe he'll give us some guidance on how
to handle this.
>
>>>
>>>> 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
>
> --
> 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:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4Oz8mL5jGzBHZeznd5NbPqq93q7PpTDqHHcV_HYSfqBVHA@mail.gmail.com>
Hi,
On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> 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:
<snip>
>>>>> So there are two ways to do this...
>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>> (I think this is a bad idea)
>>>>
>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>> are needed, then earlyconsole can claim them, and release them on
>>>> handover to the real display driver.
>>
>> Jon, can you please answer this ? I really really want to know why people
>> think this is such a bad idea. Understanding why people think this is a bad
>> idea is necessary to be able to come up with an alternative solution.
>
> The list of resources should not be duplicated in the device tree -
> once in the simplefb node and again in the real device node.
It is not duplicated, the simplefb node will list the clocks used for the
mode / output as setup by the firmware, which are often not all clocks
which the display engine supports. Where as the real device node will list
all clocks the display engine may use.
> Device
> tree is a hardware description and it is being twisted to solve a
> software issue.
This is not true, various core devicetree developers have already said
that storing other info in the devicetree is fine, and being able to do so
is part of the original design.
> This problem is not limited to clocks, same problem
> exists with regulators. On SGI systems this would exist with entire
> bus controllers (but they are x86 based, console is not on the root
> bus). This is a very messy problem and will lead to a Frankenstein
> sized driver over time.
This is a "what if ..." argument, we can discuss potential hypothetical
problems all day long, what happens if the sky falls down?
> But... I think this is a red herring which is masking the real
> problem. The real problem seems to be that there is no window for
> loading device specific drivers before the resource clean up phase
> happens. That's a real problem -- multi architecture distros are going
> to have lots of loadable device specific drivers.
As Maxime pointed out to my alternative solution to fixing the clocks
problem, this is not strictly a when to do cleanup problem. If another
driver uses the same clocks, and does a clk_disable call after probing
(because the device is put in low power mode until used by userspace),
then the clk will be disabled even without any cleanup running at all.
The real problem here is simply that to work the simplefb needs certain
resources, just like any other device. And while for any other device
simply listing the needed resources is an accepted practice, for simplefb
for some reason (which I still do not understand) people all of a sudden
see listing resources as a problem.
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