* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-01 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20141001170517.GF4273@sirena.org.uk>
Hi,
On 10/01/2014 07:05 PM, Mark Brown wrote:
> On Wed, Oct 01, 2014 at 02:48:02PM +0200, Thierry Reding wrote:
>> On Wed, Oct 01, 2014 at 01:32:50PM +0100, Mark Brown wrote:
>
>>> So don't do that if you're worried about it then, provide the bits of DT
>>> that hook everything up from the start or otherwise describe things as
>>> being in use.
>
>> "Otherwise describe things as being in use" doesn't work for clocks for
>> example. And Mike already said he wasn't willing to add something like
>> an always-on DT property for clocks.
>
> That's not the only way of doing things - another way would be to have a
> stub driver that just holds the resources while working on getting a
> full one in place for example.
That won't work because the real driver which will eventually replace the
stub one will likely be a module, and then we will loose video output
between the kernel finalizing the initial boot, and the module actually
loading.
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.
This madness has to end! Thierry can we please have a clear and
unambiguous NACK from you on having the clocks property in the simplefb
dt node, and if you do so I expect a proof of concept patch from you
with an alternative solution within a week, or can you please stop
blocking this from getting merged?
And again, if you believe this will cause some sort of dt compat
issues or whatever, no one is making you use this property for
your boards!
Regards,
Hans
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: jonsmirl @ 2014-10-01 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542C3934.3040409@redhat.com>
On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/01/2014 07:05 PM, Mark Brown wrote:
>> On Wed, Oct 01, 2014 at 02:48:02PM +0200, Thierry Reding wrote:
>>> On Wed, Oct 01, 2014 at 01:32:50PM +0100, Mark Brown wrote:
>>
>>>> So don't do that if you're worried about it then, provide the bits of DT
>>>> that hook everything up from the start or otherwise describe things as
>>>> being in use.
>>
>>> "Otherwise describe things as being in use" doesn't work for clocks for
>>> example. And Mike already said he wasn't willing to add something like
>>> an always-on DT property for clocks.
>>
>> That's not the only way of doing things - another way would be to have a
>> stub driver that just holds the resources while working on getting a
>> full one in place for example.
>
> That won't work because the real driver which will eventually replace the
> stub one will likely be a module, and then we will loose video output
> between the kernel finalizing the initial boot, and the module actually
> loading.
Is this correct? Do the clocks really get shut off before a driver on
initrd can load?
I agree this is true if you wait until user space is fully up and
stick this driver out on a disk drive.
>
> 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.
>
> This madness has to end! Thierry can we please have a clear and
> unambiguous NACK from you on having the clocks property in the simplefb
> dt node, and if you do so I expect a proof of concept patch from you
> with an alternative solution within a week, or can you please stop
> blocking this from getting merged?
>
> And again, if you believe this will cause some sort of dt compat
> issues or whatever, no one is making you use this property for
> your boards!
>
> 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: Stephen Warren @ 2014-10-01 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4OxzerMyuza-GSfmYiLMqA=Y3HOXko7a8rOcP_8PkHVF3w@mail.gmail.com>
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.
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Luc Verhaegen @ 2014-10-01 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542C4404.8040501@wwwdotorg.org>
On Wed, Oct 01, 2014 at 12:12:20PM -0600, 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.
Define "resource management".
Simplefb should never alter resources. It should never alter anything
that $bootloader set up. It should however claim resources to prevent
them from being altered.
Perhaps the word "managing" should be split up in "claiming" and
"altering" here.
Luc Verhaegen.
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Mike Turquette @ 2014-10-01 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20141001073043.GA18463@ulmo>
On Wed, Oct 1, 2014 at 12:30 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Tue, Sep 30, 2014 at 02:37:53PM -0700, Mike Turquette wrote:
>> Quoting Thierry Reding (2014-09-29 06:54:00)
>> > On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
>> > > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
>> > > > > >> Plus, speaking more specifically about the clocks, that won't prevent
>> > > > > >> your clock to be shut down as a side effect of a later clk_disable
>> > > > > >> call from another driver.
>> > > > >
>> > > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
>> > > > > > preceding clk_enable()? There are patches being worked on that will
>> > > > > > enable per-user clocks and as I understand it they will specifically
>> > > > > > disallow drivers to disable the hardware clock if other drivers are
>> > > > > > still keeping them on via their own referenc.
>> > > > >
>> > > > > Calling clk_disable() preceding clk_enable() is a bug.
>> > > > >
>> > > > > Calling clk_disable() after clk_enable() will disable the clock (and
>> > > > > its parents)
>> > > > > if the clock subsystem thinks there are no other users, which is what will
>> > > > > happen here.
>> > > >
>> > > > Right. I'm not sure this is really applicable to this situation, though.
>> > >
>> > > It's actually very easy to do. Have a driver that probes, enables its
>> > > clock, fails to probe for any reason, call clk_disable in its exit
>> > > path. If there's no other user at that time of this particular clock
>> > > tree, it will be shut down. Bam. You just lost your framebuffer.
>> > >
>> > > Really, it's just that simple, and relying on the fact that some other
>> > > user of the same clock tree will always be their is beyond fragile.
>> >
>> > Perhaps the meaning clk_ignore_unused should be revised, then. What you
>> > describe isn't at all what I'd expect from such an option. And it does
>> > not match the description in Documentation/kernel-parameters.txt either.
>>
>> From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001
>> From: Mike Turquette <mturquette@linaro.org>
>> Date: Tue, 30 Sep 2014 14:24:38 -0700
>> Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused
>>
>> Refine the definition around clk_ignore_unused, which caused some
>> confusion recently on the linux-fbdev and linux-arm-kernel mailing
>> lists[0].
>>
>> [0] http://lkml.kernel.org/r/<20140929135358.GC30998@ulmo>
>>
>> Signed-off-by: Mike Turquette <mturquette@linaro.org>
>> ---
>> Thierry,
>>
>> Please let me know if this wording makes the feature more clear.
>
> I think that's better than before, but I don't think it's accurate yet.
> As pointed out by Maxime unused clock may still be disabled if it's part
> of a tree and that tree is being disabled because there are no users
> left.
It is entirely accurate. This feature does in fact "prevent the clock
framework from *automatically* gating clock ...".
And it was merged by Olof so that he could use simplefb with the Chromebook!
>
> What I had argued is that it's unexpected behavior, because the clock
> is still unused (or becomes unused again), therefore shouldn't be
> disabled at that point either.
Leaving clocks enabled because nobody claimed them is not an option.
>
> So if you want to keep the current behaviour where an unused clock can
> still be disabled depending on what other users do, then I think it'd be
> good to mention that as a potential caveat.
Do you have a suggestion on the wording?
Thanks,
Mike
>
> Thierry
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Geert Uytterhoeven @ 2014-10-01 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20141001171704.GG4273@sirena.org.uk>
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).
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: Hans de Goede @ 2014-10-02 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542C4404.8040501@wwwdotorg.org>
Hi,
On 10/01/2014 08:12 PM, Stephen Warren wrote:
> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> ...
>>> We've been over all this again and again and again.
>>>
>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>
>>> All solutions provided sofar are both tons more complicated, then the
>>> simple solution of simply having the simplefb dt node declare which
>>> clocks it needs. And to make things worse all of them sofar have
>>> unresolved issues (due to their complexity mostly).
>>>
>>> With the clocks in the simplefb node, then all a real driver has to do,
>>> is claim those same clocks before unregistering the simplefb driver,
>>> and everything will just work.
>>>
>>> Yet we've been discussing this for months, all because of some
>>> vague worries from Thierry, and *only* from Thierry that this will
>>> make simplefb less generic / not abstract enough, while a simple
>>> generic clocks property is about as generic as things come.
>
> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>
> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>
> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
The whole reason why we want to use simplefb is not just to get things
running until HW specific driver is in place, but also to have early console
output (to help debugging boot problems on devices without a serial console),
in a world where most video drivers are build as loadable modules, so we
won't have video output until quite late into the boot process.
This is also the reason why we're working on adding hdmi console support
to u-boot in the first place, to debug boot problems.
So the whole "write a HW specific driver" answer just does not cut it. Just
like we have vgacon / efifb on x86, we need something similar on ARM, and
since ARM does not have a generic hw interface like vga, we need a firmware
solution like efifb.
So as said the whole "write a HW specific driver" just will not work, so
that means using something like simplefb. Now I can take simplefb, copy
it to rename it to firmwarefb or ubootfb or something, and then add the clocks
support, but that is just silly.
You indicate that you don't have the time for this discussion, and I note that
there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
my responsibility (and in my own benefit) to stop this from growing into
a monster ?
To me that seems better then adding a new drivers/video/fbdev/firmwarefb.c
which will be just a copy with the clocks added.
Regards,
Hans
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Thierry Reding @ 2014-10-02 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPtuhTgJ7TLg8CKe3pQiBeEw9s33UrYEXPj6SDCga2yAh7WfEA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5217 bytes --]
On Wed, Oct 01, 2014 at 11:17:23AM -0700, Mike Turquette wrote:
> On Wed, Oct 1, 2014 at 12:30 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Tue, Sep 30, 2014 at 02:37:53PM -0700, Mike Turquette wrote:
> >> Quoting Thierry Reding (2014-09-29 06:54:00)
> >> > On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> >> > > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> >> > > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> >> > > > > >> your clock to be shut down as a side effect of a later clk_disable
> >> > > > > >> call from another driver.
> >> > > > >
> >> > > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> >> > > > > > preceding clk_enable()? There are patches being worked on that will
> >> > > > > > enable per-user clocks and as I understand it they will specifically
> >> > > > > > disallow drivers to disable the hardware clock if other drivers are
> >> > > > > > still keeping them on via their own referenc.
> >> > > > >
> >> > > > > Calling clk_disable() preceding clk_enable() is a bug.
> >> > > > >
> >> > > > > Calling clk_disable() after clk_enable() will disable the clock (and
> >> > > > > its parents)
> >> > > > > if the clock subsystem thinks there are no other users, which is what will
> >> > > > > happen here.
> >> > > >
> >> > > > Right. I'm not sure this is really applicable to this situation, though.
> >> > >
> >> > > It's actually very easy to do. Have a driver that probes, enables its
> >> > > clock, fails to probe for any reason, call clk_disable in its exit
> >> > > path. If there's no other user at that time of this particular clock
> >> > > tree, it will be shut down. Bam. You just lost your framebuffer.
> >> > >
> >> > > Really, it's just that simple, and relying on the fact that some other
> >> > > user of the same clock tree will always be their is beyond fragile.
> >> >
> >> > Perhaps the meaning clk_ignore_unused should be revised, then. What you
> >> > describe isn't at all what I'd expect from such an option. And it does
> >> > not match the description in Documentation/kernel-parameters.txt either.
> >>
> >> From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001
> >> From: Mike Turquette <mturquette@linaro.org>
> >> Date: Tue, 30 Sep 2014 14:24:38 -0700
> >> Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused
> >>
> >> Refine the definition around clk_ignore_unused, which caused some
> >> confusion recently on the linux-fbdev and linux-arm-kernel mailing
> >> lists[0].
> >>
> >> [0] http://lkml.kernel.org/r/<20140929135358.GC30998@ulmo>
> >>
> >> Signed-off-by: Mike Turquette <mturquette@linaro.org>
> >> ---
> >> Thierry,
> >>
> >> Please let me know if this wording makes the feature more clear.
> >
> > I think that's better than before, but I don't think it's accurate yet.
> > As pointed out by Maxime unused clock may still be disabled if it's part
> > of a tree and that tree is being disabled because there are no users
> > left.
>
> It is entirely accurate. This feature does in fact "prevent the clock
> framework from *automatically* gating clock ...".
According to what Maxime said if an unused clock is a sibling (has the
same parent) of a clock that is used and then gets disabled, then if the
parent has no other clocks that are enabled, the unused clock will still
be disabled.
That's still counts as "automatically" to me. Not automatically would
mean that the clock needs to be disabled explicitly for it to become
disabled. Disabling it as a side-effect of its parent getting disabled
is still automatic.
> And it was merged by Olof so that he could use simplefb with the
> Chromebook!
And presumably it does work for that specific Chromebook. It seems,
though that for hardware with a somewhat whackier clock tree it doesn't
work so well. As far as I can tell that's the reason for this patch and
the ensuing discussion in the first place.
Although, perhaps nobody ever really tested whether or not the above
scenario was actually a problem for sunxi and maybe clk_ignore_unused
would work for them. But as I understand they don't want to use it, so
this whole debate about this kernel parameter is a bit moot.
> > What I had argued is that it's unexpected behavior, because the clock
> > is still unused (or becomes unused again), therefore shouldn't be
> > disabled at that point either.
>
> Leaving clocks enabled because nobody claimed them is not an option.
But that's exactly what clk_ignore_unused is, isn't it? I'm now totally
confused.
> > So if you want to keep the current behaviour where an unused clock can
> > still be disabled depending on what other users do, then I think it'd be
> > good to mention that as a potential caveat.
>
> Do you have a suggestion on the wording?
Perhaps something like this:
Note that if an unused clock shares a parent with clocks that
are used, the unused clock may still become disabled as a side-
effect of the parent clock being disabled when none of the
children that are used remain enabled.
?
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: 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
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