* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Michal Suchanek @ 2014-08-28 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4Oy8X9CSpZjYnTRgZ_MsxXQ=zaP+kxiZ2b7Es4GjN+1iJw@mail.gmail.com>
On 28 August 2014 16:33, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>>
>>>> So the only point of discussion left seems to be how to do 2...
>>>
>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>> whip together a device specific driver that claims the proper
>>> resources? And just implement the minimal about of fbdev possible?
>>> fbdev already is a driver library.
>>
>> Like... drivers/video/fbdev/offb.c?
>
> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
> and use it as a template for making device specific versions of it.
>
> I don't see why there is so much resistance to just making device
> specific fb drivers. Whenever the KMS driver gets written just
> disable the device specific fb driver in the build.
Except that is not the goal here. The simplefb or whatever replacement
is supposed to stay as a generic driver compiled into kernel whereas
the complete platform-specific driver is supposed to be provided as
module and loaded at the init system's leasure sometime during boot.
This way you can have generic distribution kernel which supports many
devices but does not have built-in support for every graphics
hardware.
Thanks
Michal
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: jonsmirl @ 2014-08-28 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMqctRvNbvFTb9dixCO1D0PfOWDgmBBs2U3yR5pvL8dFM_Lvw@mail.gmail.com>
On Thu, Aug 28, 2014 at 12:25 PM, Michal Suchanek <hramrach@gmail.com> wrote:
> On 28 August 2014 16:33, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>>>
>>>>> So the only point of discussion left seems to be how to do 2...
>>>>
>>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>>> whip together a device specific driver that claims the proper
>>>> resources? And just implement the minimal about of fbdev possible?
>>>> fbdev already is a driver library.
>>>
>>> Like... drivers/video/fbdev/offb.c?
>>
>> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
>> and use it as a template for making device specific versions of it.
>>
>> I don't see why there is so much resistance to just making device
>> specific fb drivers. Whenever the KMS driver gets written just
>> disable the device specific fb driver in the build.
>
> Except that is not the goal here. The simplefb or whatever replacement
> is supposed to stay as a generic driver compiled into kernel whereas
There is no generic solution to this problem as this entire thread has
illustrated. The clocks/regulators needed by each SOC vary.
So there are two solutions..
1) modify simplefb to have some kind of heuristic that tries to guess
what needs to be protected. A heuristic that is probably going to fail
on every new SOC.
2) Spend a day implementing a device specific fbdev driver that does
the correct thing all of the time. These drivers would sit in initrd
and load before the clock/regulator clean up shuts everything off. Use
the existing simplefb code as a template for doing this.
> the complete platform-specific driver is supposed to be provided as
> module and loaded at the init system's leasure sometime during boot.
> This way you can have generic distribution kernel which supports many
> devices but does not have built-in support for every graphics
> hardware.
>
> 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: Luc Verhaegen @ 2014-08-28 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4OyB55L5q7fVo43V8kgtqHRZ3vkBMaA+Htxpob-FA1obaA@mail.gmail.com>
On Thu, Aug 28, 2014 at 12:34:58PM -0400, jonsmirl@gmail.com wrote:
>
> 2) Spend a day implementing a device specific fbdev driver that does
> the correct thing all of the time. These drivers would sit in initrd
> and load before the clock/regulator clean up shuts everything off. Use
> the existing simplefb code as a template for doing this.
If that finally ends this discussion, i'll more than happily do it. I'm
sure that we've all could've done this a hundred times in the time we've
wasted here.
Good call Geert.
Luc Verhaegen.
^ permalink raw reply
* EARLY_PRINTK equivalent for framebuffers.
From: jonsmirl @ 2014-08-28 19:19 UTC (permalink / raw)
To: linux-fbdev
Is there some existing way to do early printk type output to a
framebuffer that has been set up by the bootloader? early printk is
before any device drivers are loaded.
If not, what would it take to create a way to do this? Something along
the lines of build in the fbdev library and give it an address plus
x/y layout of the buffer. Assume that everything else is set up and
anything written to the buffer will appear on the display. Then hook
into where the kernel does early printk on uarts and add in support
for this buffer. The core fbdev library implements scrolling and
graphical characters.
I'm only looking to address early boot messages so that if the kernel
fails to boot before it can get to a real video driver, the output is
still visible.
Note that you get this early output right now, but it is buffered by
the kernel until the console driver is loaded, then it gets dumped. If
you fail before that console driver loads you see nothing. The idea is
to make the output that gets lost visible.
To communicate this you need the existing fb mode line on the kernel
command line (to get x/y layout) plus the framebuffer address. Or this
info can come via the DT.
No intention to keep this display working once real display drivers
get loaded. So no touching clocks, regulators, display modes, etc....
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Michal Suchanek @ 2014-08-28 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4OyB55L5q7fVo43V8kgtqHRZ3vkBMaA+Htxpob-FA1obaA@mail.gmail.com>
On 28 August 2014 18:34, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Aug 28, 2014 at 12:25 PM, Michal Suchanek <hramrach@gmail.com> wrote:
>> On 28 August 2014 16:33, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>>>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>>>>
>>>>>> So the only point of discussion left seems to be how to do 2...
>>>>>
>>>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>>>> whip together a device specific driver that claims the proper
>>>>> resources? And just implement the minimal about of fbdev possible?
>>>>> fbdev already is a driver library.
>>>>
>>>> Like... drivers/video/fbdev/offb.c?
>>>
>>> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
>>> and use it as a template for making device specific versions of it.
>>>
>>> I don't see why there is so much resistance to just making device
>>> specific fb drivers. Whenever the KMS driver gets written just
>>> disable the device specific fb driver in the build.
>>
>> Except that is not the goal here. The simplefb or whatever replacement
>> is supposed to stay as a generic driver compiled into kernel whereas
>
> There is no generic solution to this problem as this entire thread has
> illustrated. The clocks/regulators needed by each SOC vary.
>
> So there are two solutions..
> 1) modify simplefb to have some kind of heuristic that tries to guess
> what needs to be protected. A heuristic that is probably going to fail
> on every new SOC.
You do not need a heuristic when the bootloader that enabled the
clocks and regulators can tell you which.
And this patch was initially about adding support to simplefb to read
from DT where u-boot fills in the clocks that are needed for HDMI
output to keep running on sunxi.
>
> 2) Spend a day implementing a device specific fbdev driver that does
> the correct thing all of the time. These drivers would sit in initrd
> and load before the clock/regulator clean up shuts everything off. Use
> the existing simplefb code as a template for doing this.
But then you need to spend a day implementing such driver for every
SoC and it will not work before initrd is loaded.
In contrast simplefb with resource management support can work on any
platform where the bootloader enables framebuffer and then can be
compiled into generic kernel and work before even initrd is loaded.
Thanks
Michal
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Maxime Ripard @ 2014-08-28 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140828101140.GB14388@ulmo>
[-- Attachment #1: Type: text/plain, Size: 3316 bytes --]
On Thu, Aug 28, 2014 at 12:11:41PM +0200, Thierry Reding wrote:
> On Wed, Aug 27, 2014 at 05:42:21PM +0200, Maxime Ripard wrote:
> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> > > On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> > > > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> > > > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> > > > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> > > [...]
> > > > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> > > > > > > > https://lkml.org/lkml/2014/5/12/693
> > > > > > >
> > > > > > > Mike says in that email that he's opposing the addition of a property
> > > > > > > for clocks that is the equivalent of regulator-always-on. That's not
> > > > > > > what this is about. If at all it'd be a property to mark a clock that
> > > > > > > should not be disabled by default because it's essential.
> > > > > >
> > > > > > It's just semantic. How is "a clock that should not be disabled by
> > > > > > default because it's essential" not a clock that stays always on?
> > > > >
> > > > > Because a clock that should not be disabled by default can be turned off
> > > > > when appropriate. A clock that is always on can't be turned off.
> > > >
> > > > If a clock is essential, then it should never be disabled. Or we don't
> > > > share the same meaning of essential.
> > >
> > > Essential for the particular use-case.
> >
> > So, how would the clock driver would know about which use case we're
> > in? How would it know about which display engine is currently running?
> > How would it know about which video output is being set?
> >
> > Currently, we have two separate display engines, which can each output
> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> > one of these combinations would require different clocks. What clocks
> > will we put in the driver? All of them?
>
> Ideally the solution wouldn't involve hard-coding this into the clock
> driver at all.
Cool, so we do agree on that too :)
> There should be a way for firmware to communicate to the kernel that
> a given clock shouldn't be disabled.
And this patch was such an attempt. I guess it wasn't that far off
then.
> Then since firmware already knows what it set up it can tell the
> kernel to not touch those.
Somehow, I've been raised kernel-wise into thinking that you can never
fully trust your firmware. Or at least that you should have a way to
recover from any bug/bad behaviour from it.
Moreover, the way I see it, there's a major flaw in having an
attribute in the clock node: you don't even know if the clock is ever
going to be used.
If simplefb is not compiled in, you won't claim the clocks, and they
will be disabled, which is imho a good thing. This case wouldn't be
covered with an attribute at the clock node, because you don't have a
link to what device/feature actually uses it in the system, and so you
have to make the assumption that it will be used. And you will end up
with clocks with a rather high rate running for nothing.
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: EARLY_PRINTK equivalent for framebuffers.
From: Alexandre Courbot @ 2014-08-29 1:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAKON4Owx5wQS29qj9Ks2CzP-Q9Kos6=6MbPRxS+4n9WkdbWegQ@mail.gmail.com>
On Thu, Aug 28, 2014 at 12:19 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> Is there some existing way to do early printk type output to a
> framebuffer that has been set up by the bootloader? early printk is
> before any device drivers are loaded.
>
> If not, what would it take to create a way to do this? Something along
> the lines of build in the fbdev library and give it an address plus
> x/y layout of the buffer. Assume that everything else is set up and
> anything written to the buffer will appear on the display. Then hook
> into where the kernel does early printk on uarts and add in support
> for this buffer. The core fbdev library implements scrolling and
> graphical characters.
simplefb does something like this (implement a console on top of a
framebuffer set up by the bootloader), but I don't think you can use
it for earlyprintk. It would be a very interesting option though (and
even better if it could be used by the kernel decompression code), but
I suspect this is more involved than good old UART as you need to
manage fonts, pixel format, screen geometry, etc.
OTOH it would be very useful for some retail devices that come without
an accessible serial line, but have a framebuffer set up by the
bootloader.
Alex.
^ permalink raw reply
* Re: EARLY_PRINTK equivalent for framebuffers.
From: jonsmirl @ 2014-08-29 1:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAKON4Owx5wQS29qj9Ks2CzP-Q9Kos6=6MbPRxS+4n9WkdbWegQ@mail.gmail.com>
On Thu, Aug 28, 2014 at 9:36 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
> On Thu, Aug 28, 2014 at 12:19 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> Is there some existing way to do early printk type output to a
>> framebuffer that has been set up by the bootloader? early printk is
>> before any device drivers are loaded.
>>
>> If not, what would it take to create a way to do this? Something along
>> the lines of build in the fbdev library and give it an address plus
>> x/y layout of the buffer. Assume that everything else is set up and
>> anything written to the buffer will appear on the display. Then hook
>> into where the kernel does early printk on uarts and add in support
>> for this buffer. The core fbdev library implements scrolling and
>> graphical characters.
>
> simplefb does something like this (implement a console on top of a
> framebuffer set up by the bootloader), but I don't think you can use
> it for earlyprintk. It would be a very interesting option though (and
simplefb is a device driver so it doesn't process the early output.
This would need to be some custom code that gets the framebuffer
address and x/y setup very early in the boot process. I'm fairly sure
nothing like it current exists.
> even better if it could be used by the kernel decompression code), but
> I suspect this is more involved than good old UART as you need to
> manage fonts, pixel format, screen geometry, etc.
>
> OTOH it would be very useful for some retail devices that come without
> an accessible serial line, but have a framebuffer set up by the
> bootloader.
>
> Alex.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: EARLY_PRINTK equivalent for framebuffers.
From: Alexandre Courbot @ 2014-08-29 1:54 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAKON4Owx5wQS29qj9Ks2CzP-Q9Kos6=6MbPRxS+4n9WkdbWegQ@mail.gmail.com>
On Thu, Aug 28, 2014 at 6:40 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Aug 28, 2014 at 9:36 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
>> On Thu, Aug 28, 2014 at 12:19 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>> Is there some existing way to do early printk type output to a
>>> framebuffer that has been set up by the bootloader? early printk is
>>> before any device drivers are loaded.
>>>
>>> If not, what would it take to create a way to do this? Something along
>>> the lines of build in the fbdev library and give it an address plus
>>> x/y layout of the buffer. Assume that everything else is set up and
>>> anything written to the buffer will appear on the display. Then hook
>>> into where the kernel does early printk on uarts and add in support
>>> for this buffer. The core fbdev library implements scrolling and
>>> graphical characters.
>>
>> simplefb does something like this (implement a console on top of a
>> framebuffer set up by the bootloader), but I don't think you can use
>> it for earlyprintk. It would be a very interesting option though (and
>
> simplefb is a device driver so it doesn't process the early output.
> This would need to be some custom code that gets the framebuffer
> address and x/y setup very early in the boot process. I'm fairly sure
> nothing like it current exists.
You're right AFAICT. And although simplefb shares part of of idea it
also doesn't operate at the required level. Also contrary to what I
said it also does not implement a console, but just a framebuffer
device on top of which you need some more logic before you can think
about displaying strings.
It seems like what would be needed is an early platform driver that
would operate like earlyprintk, with some extra parameters to specify
the FB's location and properties. Such a driver would be very
simplistic though, and I don't think we could have things like a
smooth transition with the "real" console, although I guess that's not
the goal here.
^ permalink raw reply
* Re: EARLY_PRINTK equivalent for framebuffers.
From: jonsmirl @ 2014-08-29 2:00 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAKON4Owx5wQS29qj9Ks2CzP-Q9Kos6=6MbPRxS+4n9WkdbWegQ@mail.gmail.com>
On Thu, Aug 28, 2014 at 9:54 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
> On Thu, Aug 28, 2014 at 6:40 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Aug 28, 2014 at 9:36 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
>>> On Thu, Aug 28, 2014 at 12:19 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>> Is there some existing way to do early printk type output to a
>>>> framebuffer that has been set up by the bootloader? early printk is
>>>> before any device drivers are loaded.
>>>>
>>>> If not, what would it take to create a way to do this? Something along
>>>> the lines of build in the fbdev library and give it an address plus
>>>> x/y layout of the buffer. Assume that everything else is set up and
>>>> anything written to the buffer will appear on the display. Then hook
>>>> into where the kernel does early printk on uarts and add in support
>>>> for this buffer. The core fbdev library implements scrolling and
>>>> graphical characters.
>>>
>>> simplefb does something like this (implement a console on top of a
>>> framebuffer set up by the bootloader), but I don't think you can use
>>> it for earlyprintk. It would be a very interesting option though (and
>>
>> simplefb is a device driver so it doesn't process the early output.
>> This would need to be some custom code that gets the framebuffer
>> address and x/y setup very early in the boot process. I'm fairly sure
>> nothing like it current exists.
>
> You're right AFAICT. And although simplefb shares part of of idea it
> also doesn't operate at the required level. Also contrary to what I
> said it also does not implement a console, but just a framebuffer
> device on top of which you need some more logic before you can think
> about displaying strings.
turn on fbconsole support and it should work.
>
> It seems like what would be needed is an early platform driver that
> would operate like earlyprintk, with some extra parameters to specify
> the FB's location and properties. Such a driver would be very
> simplistic though, and I don't think we could have things like a
> smooth transition with the "real" console, although I guess that's not
> the goal here.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: EARLY_PRINTK equivalent for framebuffers.
From: Alexandre Courbot @ 2014-08-29 2:05 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAKON4Owx5wQS29qj9Ks2CzP-Q9Kos6=6MbPRxS+4n9WkdbWegQ@mail.gmail.com>
On Thu, Aug 28, 2014 at 7:00 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Aug 28, 2014 at 9:54 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
>> On Thu, Aug 28, 2014 at 6:40 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>> On Thu, Aug 28, 2014 at 9:36 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
>>>> On Thu, Aug 28, 2014 at 12:19 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>>> Is there some existing way to do early printk type output to a
>>>>> framebuffer that has been set up by the bootloader? early printk is
>>>>> before any device drivers are loaded.
>>>>>
>>>>> If not, what would it take to create a way to do this? Something along
>>>>> the lines of build in the fbdev library and give it an address plus
>>>>> x/y layout of the buffer. Assume that everything else is set up and
>>>>> anything written to the buffer will appear on the display. Then hook
>>>>> into where the kernel does early printk on uarts and add in support
>>>>> for this buffer. The core fbdev library implements scrolling and
>>>>> graphical characters.
>>>>
>>>> simplefb does something like this (implement a console on top of a
>>>> framebuffer set up by the bootloader), but I don't think you can use
>>>> it for earlyprintk. It would be a very interesting option though (and
>>>
>>> simplefb is a device driver so it doesn't process the early output.
>>> This would need to be some custom code that gets the framebuffer
>>> address and x/y setup very early in the boot process. I'm fairly sure
>>> nothing like it current exists.
>>
>> You're right AFAICT. And although simplefb shares part of of idea it
>> also doesn't operate at the required level. Also contrary to what I
>> said it also does not implement a console, but just a framebuffer
>> device on top of which you need some more logic before you can think
>> about displaying strings.
>
> turn on fbconsole support and it should work.
Yeah, but my point was, that I don't think you can use fbconsole that
early in the kernel?
^ permalink raw reply
* Re: EARLY_PRINTK equivalent for framebuffers.
From: jonsmirl @ 2014-08-29 2:09 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAKON4Owx5wQS29qj9Ks2CzP-Q9Kos6=6MbPRxS+4n9WkdbWegQ@mail.gmail.com>
On Thu, Aug 28, 2014 at 10:05 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
> On Thu, Aug 28, 2014 at 7:00 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Aug 28, 2014 at 9:54 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
>>> On Thu, Aug 28, 2014 at 6:40 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>> On Thu, Aug 28, 2014 at 9:36 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
>>>>> On Thu, Aug 28, 2014 at 12:19 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>>>> Is there some existing way to do early printk type output to a
>>>>>> framebuffer that has been set up by the bootloader? early printk is
>>>>>> before any device drivers are loaded.
>>>>>>
>>>>>> If not, what would it take to create a way to do this? Something along
>>>>>> the lines of build in the fbdev library and give it an address plus
>>>>>> x/y layout of the buffer. Assume that everything else is set up and
>>>>>> anything written to the buffer will appear on the display. Then hook
>>>>>> into where the kernel does early printk on uarts and add in support
>>>>>> for this buffer. The core fbdev library implements scrolling and
>>>>>> graphical characters.
>>>>>
>>>>> simplefb does something like this (implement a console on top of a
>>>>> framebuffer set up by the bootloader), but I don't think you can use
>>>>> it for earlyprintk. It would be a very interesting option though (and
>>>>
>>>> simplefb is a device driver so it doesn't process the early output.
>>>> This would need to be some custom code that gets the framebuffer
>>>> address and x/y setup very early in the boot process. I'm fairly sure
>>>> nothing like it current exists.
>>>
>>> You're right AFAICT. And although simplefb shares part of of idea it
>>> also doesn't operate at the required level. Also contrary to what I
>>> said it also does not implement a console, but just a framebuffer
>>> device on top of which you need some more logic before you can think
>>> about displaying strings.
>>
>> turn on fbconsole support and it should work.
>
> Yeah, but my point was, that I don't think you can use fbconsole that
> early in the kernel?
You can't. But all of the needed code is sitting there in fbconsole.
There is just a small bit missing to make an early console work.
Mainly just the bit about address of buffer and x/y layout.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Michal Suchanek @ 2014-08-29 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140828100834.GA14388@ulmo>
On 28 August 2014 12:08, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
>> Hello,
>>
>> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
>> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
>> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
>> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>> >> [...]
>> >> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
>> >> > > > > > https://lkml.org/lkml/2014/5/12/693
>> >> > > > >
>> >> > > > > Mike says in that email that he's opposing the addition of a property
>> >> > > > > for clocks that is the equivalent of regulator-always-on. That's not
>> >> > > > > what this is about. If at all it'd be a property to mark a clock that
>> >> > > > > should not be disabled by default because it's essential.
>> >> > > >
>> >> > > > It's just semantic. How is "a clock that should not be disabled by
>> >> > > > default because it's essential" not a clock that stays always on?
>> >> > >
>> >> > > Because a clock that should not be disabled by default can be turned off
>> >> > > when appropriate. A clock that is always on can't be turned off.
>> >> >
>> >> > If a clock is essential, then it should never be disabled. Or we don't
>> >> > share the same meaning of essential.
>> >>
>> >> Essential for the particular use-case.
>> >
>> > So, how would the clock driver would know about which use case we're
>> > in? How would it know about which display engine is currently running?
>> > How would it know about which video output is being set?
>> >
>> > Currently, we have two separate display engines, which can each output
>> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
>> > one of these combinations would require different clocks. What clocks
>> > will we put in the driver? All of them?
>> >
>>
>> since simplefb cannot be extended how about adding, say, dtfb which
>> claims the resources from dt and then instantiates a simplefb once the
>> resources are claimed? That is have a dtfb which has the clocks
>> assigned and has simplefb as child dt node.
>
> I don't see how that changes anything. All you do is add another layer
> of indirection. The fundamental problem remains the same and isn't
> solved.
It keeps clock code out of simplefb and provides driver for the kind
of framebuffer set up by firmware that exists on sunxi, exynos, and
probably many other SoCs. That is a framebuffer that needs some clocks
and possibly regulators enabled to keep running because the reality of
the platform is that it has clocks and regulators unlike some other
platforms that do not.
These clocks and regulators are used but not configured by the
framebuffer and should be reclaimed when firmware framebuffer is
disabled. This is the same as the chunk of memory used by simplefb
which is currently lost but should be reclaimed when simplefb is
disabled.
This memory is not 'reserved for firmware' and unusable but reserved
for framebuffer and the regulators are not 'always on' or 'should
never be disabled' but should be enabled while framebuffer is used.
As far as I can tell in DT this is expressed by creating a DT node
associated with the framebuffer driver that tells the kernel that this
memory, clocks and regulators are associated with the framebuffer
driver and can be reclaimed if this driver is stopped or not enabled
in the kernel at all. If you are going to be asinine about simplefb
not getting support for managing any resource other than the memory
chunk then another layer of indirection is required for platforms that
have more resources to manage.
If there is another way to associate resources with a driver in DT
then please enlighten me.
AFAICT simplefb is the framebuffer driver already in kernel closest to
the driver that is required for sunxi - simplefb also relies on
firmware to set up the framebuffer but unlike vesafb or efifb it
already has DT integration. So the most efficient way to implement
framebuffer for sunxi is to extend simplefb or if necessary add
another layer of indirection under simplefb. If there is a better
fitting driver in the kernel then please enlighten me and the
developer that wrote this patch what driver it would be.
Thanks
Michal
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Thierry Reding @ 2014-08-29 6:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMqctSwhQHJynn=tW==uuznJW+0CrivNP=os+xem1MAuDP7ZQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5621 bytes --]
On Fri, Aug 29, 2014 at 07:13:22AM +0200, Michal Suchanek wrote:
> On 28 August 2014 12:08, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
> >> Hello,
> >>
> >> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> >> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> >> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> >> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> >> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> >> >> [...]
> >> >> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> >> >> > > > > > https://lkml.org/lkml/2014/5/12/693
> >> >> > > > >
> >> >> > > > > Mike says in that email that he's opposing the addition of a property
> >> >> > > > > for clocks that is the equivalent of regulator-always-on. That's not
> >> >> > > > > what this is about. If at all it'd be a property to mark a clock that
> >> >> > > > > should not be disabled by default because it's essential.
> >> >> > > >
> >> >> > > > It's just semantic. How is "a clock that should not be disabled by
> >> >> > > > default because it's essential" not a clock that stays always on?
> >> >> > >
> >> >> > > Because a clock that should not be disabled by default can be turned off
> >> >> > > when appropriate. A clock that is always on can't be turned off.
> >> >> >
> >> >> > If a clock is essential, then it should never be disabled. Or we don't
> >> >> > share the same meaning of essential.
> >> >>
> >> >> Essential for the particular use-case.
> >> >
> >> > So, how would the clock driver would know about which use case we're
> >> > in? How would it know about which display engine is currently running?
> >> > How would it know about which video output is being set?
> >> >
> >> > Currently, we have two separate display engines, which can each output
> >> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> >> > one of these combinations would require different clocks. What clocks
> >> > will we put in the driver? All of them?
> >> >
> >>
> >> since simplefb cannot be extended how about adding, say, dtfb which
> >> claims the resources from dt and then instantiates a simplefb once the
> >> resources are claimed? That is have a dtfb which has the clocks
> >> assigned and has simplefb as child dt node.
> >
> > I don't see how that changes anything. All you do is add another layer
> > of indirection. The fundamental problem remains the same and isn't
> > solved.
>
> It keeps clock code out of simplefb and provides driver for the kind
> of framebuffer set up by firmware that exists on sunxi, exynos, and
> probably many other SoCs. That is a framebuffer that needs some clocks
> and possibly regulators enabled to keep running because the reality of
> the platform is that it has clocks and regulators unlike some other
> platforms that do not.
>
> These clocks and regulators are used but not configured by the
> framebuffer and should be reclaimed when firmware framebuffer is
> disabled. This is the same as the chunk of memory used by simplefb
> which is currently lost but should be reclaimed when simplefb is
> disabled.
>
> This memory is not 'reserved for firmware' and unusable but reserved
> for framebuffer and the regulators are not 'always on' or 'should
> never be disabled' but should be enabled while framebuffer is used.
>
> As far as I can tell in DT this is expressed by creating a DT node
> associated with the framebuffer driver that tells the kernel that this
> memory, clocks and regulators are associated with the framebuffer
> driver and can be reclaimed if this driver is stopped or not enabled
> in the kernel at all. If you are going to be asinine about simplefb
> not getting support for managing any resource other than the memory
> chunk then another layer of indirection is required for platforms that
> have more resources to manage.
>
> If there is another way to associate resources with a driver in DT
> then please enlighten me.
>
> AFAICT simplefb is the framebuffer driver already in kernel closest to
> the driver that is required for sunxi - simplefb also relies on
> firmware to set up the framebuffer but unlike vesafb or efifb it
> already has DT integration. So the most efficient way to implement
> framebuffer for sunxi is to extend simplefb or if necessary add
> another layer of indirection under simplefb. If there is a better
> fitting driver in the kernel then please enlighten me and the
> developer that wrote this patch what driver it would be.
I think simplefb is exactly the right driver to use for this case. But I
don't think making it manage all the resources is the right thing to do.
While it's fairly easy to do it, it's also something that needs to be
done for every other driver with similar requirements. Consider for
example what happens if you want to play some welcome sound in the
bootloader and keep it playing while the kernel is booting. You'd need
to repeat exactly what this driver does to keep clocks for audio
hardware running. And there are possibly other similar use-cases as
well.
One other issue with simplefb is that it isn't a real device to begin
with. It's completely virtual, so in the same way that it doesn't
program any device-specific registers I don't think it should claim any
resources.
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-08-29 6:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140828204603.GB15297@lukather>
[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]
On Thu, Aug 28, 2014 at 10:46:03PM +0200, Maxime Ripard wrote:
> On Thu, Aug 28, 2014 at 12:11:41PM +0200, Thierry Reding wrote:
[...]
> > Then since firmware already knows what it set up it can tell the
> > kernel to not touch those.
>
> Somehow, I've been raised kernel-wise into thinking that you can never
> fully trust your firmware. Or at least that you should have a way to
> recover from any bug/bad behaviour from it.
If you don't trust your firmware then you shouldn't be taking over a
device that it's set up for you. Rather you should write a proper driver
that sets things up from the start.
This whole "we don't trust firmware" isn't going to work if we want to
have hand-off from firmware to kernel. And it's already been decided in
other threads that moving more code out of the kernel and into firmware
is a requirement (c.f. ARM64).
Also in this case you wrote the firmware, so why wouldn't you trust it?
> Moreover, the way I see it, there's a major flaw in having an
> attribute in the clock node: you don't even know if the clock is ever
> going to be used.
>
> If simplefb is not compiled in, you won't claim the clocks, and they
> will be disabled, which is imho a good thing. This case wouldn't be
> covered with an attribute at the clock node, because you don't have a
> link to what device/feature actually uses it in the system, and so you
> have to make the assumption that it will be used. And you will end up
> with clocks with a rather high rate running for nothing.
That's completely hypothetical. If simplefb isn't enabled and the clock
isn't claimed there's probably still going to be some other driver
taking over eventually. If there isn't, what's the point of firmware
setting up display in the first case?
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: Michal Suchanek @ 2014-08-29 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140829061910.GA13106@ulmo>
On 29 August 2014 08:19, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Fri, Aug 29, 2014 at 07:13:22AM +0200, Michal Suchanek wrote:
>> On 28 August 2014 12:08, Thierry Reding <thierry.reding@gmail.com> wrote:
>> > On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
>> >> Hello,
>> >>
>> >> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>> >> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
>> >> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
>> >> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
>> >> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> >> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>> >> >> [...]
>> >> >> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
>> >> >> > > > > > https://lkml.org/lkml/2014/5/12/693
>> >> >> > > > >
>> >> >> > > > > Mike says in that email that he's opposing the addition of a property
>> >> >> > > > > for clocks that is the equivalent of regulator-always-on. That's not
>> >> >> > > > > what this is about. If at all it'd be a property to mark a clock that
>> >> >> > > > > should not be disabled by default because it's essential.
>> >> >> > > >
>> >> >> > > > It's just semantic. How is "a clock that should not be disabled by
>> >> >> > > > default because it's essential" not a clock that stays always on?
>> >> >> > >
>> >> >> > > Because a clock that should not be disabled by default can be turned off
>> >> >> > > when appropriate. A clock that is always on can't be turned off.
>> >> >> >
>> >> >> > If a clock is essential, then it should never be disabled. Or we don't
>> >> >> > share the same meaning of essential.
>> >> >>
>> >> >> Essential for the particular use-case.
>> >> >
>> >> > So, how would the clock driver would know about which use case we're
>> >> > in? How would it know about which display engine is currently running?
>> >> > How would it know about which video output is being set?
>> >> >
>> >> > Currently, we have two separate display engines, which can each output
>> >> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
>> >> > one of these combinations would require different clocks. What clocks
>> >> > will we put in the driver? All of them?
>> >> >
>> >>
>> >> since simplefb cannot be extended how about adding, say, dtfb which
>> >> claims the resources from dt and then instantiates a simplefb once the
>> >> resources are claimed? That is have a dtfb which has the clocks
>> >> assigned and has simplefb as child dt node.
>> >
>> > I don't see how that changes anything. All you do is add another layer
>> > of indirection. The fundamental problem remains the same and isn't
>> > solved.
>>
>> It keeps clock code out of simplefb and provides driver for the kind
>> of framebuffer set up by firmware that exists on sunxi, exynos, and
>> probably many other SoCs. That is a framebuffer that needs some clocks
>> and possibly regulators enabled to keep running because the reality of
>> the platform is that it has clocks and regulators unlike some other
>> platforms that do not.
>>
>> These clocks and regulators are used but not configured by the
>> framebuffer and should be reclaimed when firmware framebuffer is
>> disabled. This is the same as the chunk of memory used by simplefb
>> which is currently lost but should be reclaimed when simplefb is
>> disabled.
>>
>> This memory is not 'reserved for firmware' and unusable but reserved
>> for framebuffer and the regulators are not 'always on' or 'should
>> never be disabled' but should be enabled while framebuffer is used.
>>
>> As far as I can tell in DT this is expressed by creating a DT node
>> associated with the framebuffer driver that tells the kernel that this
>> memory, clocks and regulators are associated with the framebuffer
>> driver and can be reclaimed if this driver is stopped or not enabled
>> in the kernel at all. If you are going to be asinine about simplefb
>> not getting support for managing any resource other than the memory
>> chunk then another layer of indirection is required for platforms that
>> have more resources to manage.
>>
>> If there is another way to associate resources with a driver in DT
>> then please enlighten me.
>>
>> AFAICT simplefb is the framebuffer driver already in kernel closest to
>> the driver that is required for sunxi - simplefb also relies on
>> firmware to set up the framebuffer but unlike vesafb or efifb it
>> already has DT integration. So the most efficient way to implement
>> framebuffer for sunxi is to extend simplefb or if necessary add
>> another layer of indirection under simplefb. If there is a better
>> fitting driver in the kernel then please enlighten me and the
>> developer that wrote this patch what driver it would be.
>
> I think simplefb is exactly the right driver to use for this case. But I
> don't think making it manage all the resources is the right thing to do.
And what is supposed to manage resources used by simplefb when not simplefb?
> While it's fairly easy to do it, it's also something that needs to be
> done for every other driver with similar requirements.
Other drivers that require clocks do manage them, yes. And some
drivers that did not do that in the past were extended for that.
> Consider for
> example what happens if you want to play some welcome sound in the
> bootloader and keep it playing while the kernel is booting. You'd need
> to repeat exactly what this driver does to keep clocks for audio
> hardware running. And there are possibly other similar use-cases as
> well.
Why would you want to do that? If the kernel boots fast the welcome
sound can be played from userspace when all drivers all in place. If
it boots slow you can just play the sound and let the kernel boot.
If you implement enough of audio driver that the kernel can actually
change the startup sound then there is not much left out. You cannot
just place random data in a buffer but have to synchronize with the
hardware for audio playback to work.
>
> One other issue with simplefb is that it isn't a real device to begin
> with. It's completely virtual, so in the same way that it doesn't
> program any device-specific registers I don't think it should claim any
> resources.
OK, so the framebuffer memory that simplefb uses for scanout should
not be claimed by it ever, either?
So how is it supposed to be handled? Reserved as unusable memory
forever as it is now?
Thanks
Michal
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Thierry Reding @ 2014-08-29 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53FF1D6C.6090205@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 6253 bytes --]
On Thu, Aug 28, 2014 at 02:15:40PM +0200, Hans de Goede wrote:
> On 08/27/2014 04:16 PM, Thierry Reding wrote:
[...]
> >> Hmm I see, in my mind the problem is not that the clk framework disables
> >> unused clocks, but that no one is marking the clocks in question as used.
> >> Someone should mark these clocks as used so that they do not get disabled.
> >>
> >> We could add a clk_mark_in_use function and have the simplefb patch call
> >> that instead of clk_prepare_and_enable, or maybe even better just only
> >> claim the clks and teach the clk framework to not disable claimed clk
> >> in its cleanup run. That would make it clear that simplefb is not enabling
> >> anything, just claiming resource its need to avoid them getting removed
> >> from underneath simplefb, would that work for you ?
> >
> > That would be more accurate, but it boils down to the same problem where
> > we still need a driver to claim the resources in some way whereas the
> > problem is fundamentally one where the bootloader should be telling the
> > kernel not to disable it. It's in fact the bootloader that's claiming
> > the resources.
>
> Yes, but those resources do not belong to the bootloader in a sense
> that traditional bootloader / firmware claimed resources (e.g. acpi
> reserved resources) do. These traditional resources are claimed for ever.
I thought that at least on x86 there was a way for the kernel to reclaim
memory set apart for an early framebuffer.
> Where as these resources are claimed by the bootloader to keep the simplefb
> it provides working, as soon as the simplefb is no longer used, they become
> unused.
Right. And when simplefb goes away it is because a real driver is taking
over, in which case it will claim the resources explicitly.
> > The copy and paste is for code that's platform specific. The clocks have
> > different names, resets are different, supplies are different. The fact
> > that many can currently use the same driver is likely just coincidence
> > rather than design and it's entirely possible that at some point they'll
> > add support for a more advanced feature that makes them incompatible
> > with the rest of the generic drivers. And then you have a big mess
> > because you need to add quirks all over the place.
> >
> > And this isn't all that far off-topic, since simplefb also needs to deal
> > with this kind of situation. And what I've been arguing is that in order
> > to really be generic it has to make assumptions, one of which is that it
> > uses only resources that it doesn't need to explicitly handle.
>
> I can understand that you're worried about generic ?hci drivers dealing with
> clocks / resets / etc. As there may be strict ordering requirements there,
> but for simplefb that is not the case.
>
> All we're asking for is for a way to communicate 2 things to the kernel:
>
> 1) These resources are in use (we are not asking the kernel to do anything
> with them, rather the opposite, we're asking to leave them alone so no
> ordering issues)
Right. That's the issue that needs to be solved. We still only disagree
on how it should be solved.
> 2) Tie these resources to simplefb so that the kernel can know when they
> are no longer in use, and it may e.g. re-use the memory
For the memory there shouldn't be a problem because it's already in the
DT node anyway. It has to be there so that simplefb knows where to write
to.
For all the other resources, if 1) is solved properly then 2) becomes a
non-issue.
> To me the most logical and also most "correct" way of modelling this is to
> put the resources inside the simplefb dt node.
Except that simplefb isn't a real device, so there's a hard time
justifying its existence in DT as it is. Claiming resources from a
virtual device doesn't sound correct to me at all.
> >> The key word here is "the used resources" to me this is not about simlefb
> >> managing resources, but marking them as used as long as it needs them, like
> >> it will need to do for the reserved mem chunk.
> >
> > The difference between the clocks and the memory resource is that the
> > driver needs to directly access the memory (it needs to map it and
> > provide a userspace mapping for it) whereas it doesn't need to touch the
> > clocks (except to workaround a Linux-specific implementation detail).
>
> Erm, no, the need to map the memory and the memory being a resource
> which may be released are an orthogonal problem. E.g. a system with
> dedicated framebuffer memory won't need to use a reserved main-memory
> chunk, nor need to worry about returning that mem when simplefb is no
> longer in use.
I would think the memory should still be reserved anyway to make sure
nothing else is writing over it. And it's in the device tree anyway
because the driver needs to know where to put framebuffer content. So
the point I was trying to make is that we can't treat the memory in the
same way as clocks because it needs to be explicitly managed. Whereas
clocks don't. The driver is simply too generic to know what to do with
the clocks. It doesn't know what frequency they should be running at or
what they're used for, so by any definition of what DT should describe
they're useless for this virtual device.
Furthermore it's fairly likely that as your kernel support progresses
you'll find that the driver all of a sudden needs to manage some other
type of resource that you just haven't needed until now because it may
default to being always on. Then you'll have a hard time keeping
backwards-compatibility and will have to resort to the kinds of hacks
that you don't want to see in the kernel.
So it really boils down to the DT needing to describe a complete device
with all the dependencies. And just clocks aren't the complete
description. But if you want the complete description then you're going
to need a complete driver as well and simplefb is out of the picture
anyway. Once again, the current, basic form of the binding allows for a
completely generic implementation of the driver because it makes
assumptions about firmware setting things up the right way so that the
driver doesn't have to.
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-08-29 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMqctTUZA-Fx1pOaqxvC9W0G5BGNFYq-gh1019pqXZ1mNynJA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7403 bytes --]
On Fri, Aug 29, 2014 at 08:48:42AM +0200, Michal Suchanek wrote:
> On 29 August 2014 08:19, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Fri, Aug 29, 2014 at 07:13:22AM +0200, Michal Suchanek wrote:
> >> On 28 August 2014 12:08, Thierry Reding <thierry.reding@gmail.com> wrote:
> >> > On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
> >> >> Hello,
> >> >>
> >> >> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >> >> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> >> >> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> >> >> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> >> >> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> >> >> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> >> >> >> [...]
> >> >> >> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> >> >> >> > > > > > https://lkml.org/lkml/2014/5/12/693
> >> >> >> > > > >
> >> >> >> > > > > Mike says in that email that he's opposing the addition of a property
> >> >> >> > > > > for clocks that is the equivalent of regulator-always-on. That's not
> >> >> >> > > > > what this is about. If at all it'd be a property to mark a clock that
> >> >> >> > > > > should not be disabled by default because it's essential.
> >> >> >> > > >
> >> >> >> > > > It's just semantic. How is "a clock that should not be disabled by
> >> >> >> > > > default because it's essential" not a clock that stays always on?
> >> >> >> > >
> >> >> >> > > Because a clock that should not be disabled by default can be turned off
> >> >> >> > > when appropriate. A clock that is always on can't be turned off.
> >> >> >> >
> >> >> >> > If a clock is essential, then it should never be disabled. Or we don't
> >> >> >> > share the same meaning of essential.
> >> >> >>
> >> >> >> Essential for the particular use-case.
> >> >> >
> >> >> > So, how would the clock driver would know about which use case we're
> >> >> > in? How would it know about which display engine is currently running?
> >> >> > How would it know about which video output is being set?
> >> >> >
> >> >> > Currently, we have two separate display engines, which can each output
> >> >> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> >> >> > one of these combinations would require different clocks. What clocks
> >> >> > will we put in the driver? All of them?
> >> >> >
> >> >>
> >> >> since simplefb cannot be extended how about adding, say, dtfb which
> >> >> claims the resources from dt and then instantiates a simplefb once the
> >> >> resources are claimed? That is have a dtfb which has the clocks
> >> >> assigned and has simplefb as child dt node.
> >> >
> >> > I don't see how that changes anything. All you do is add another layer
> >> > of indirection. The fundamental problem remains the same and isn't
> >> > solved.
> >>
> >> It keeps clock code out of simplefb and provides driver for the kind
> >> of framebuffer set up by firmware that exists on sunxi, exynos, and
> >> probably many other SoCs. That is a framebuffer that needs some clocks
> >> and possibly regulators enabled to keep running because the reality of
> >> the platform is that it has clocks and regulators unlike some other
> >> platforms that do not.
> >>
> >> These clocks and regulators are used but not configured by the
> >> framebuffer and should be reclaimed when firmware framebuffer is
> >> disabled. This is the same as the chunk of memory used by simplefb
> >> which is currently lost but should be reclaimed when simplefb is
> >> disabled.
> >>
> >> This memory is not 'reserved for firmware' and unusable but reserved
> >> for framebuffer and the regulators are not 'always on' or 'should
> >> never be disabled' but should be enabled while framebuffer is used.
> >>
> >> As far as I can tell in DT this is expressed by creating a DT node
> >> associated with the framebuffer driver that tells the kernel that this
> >> memory, clocks and regulators are associated with the framebuffer
> >> driver and can be reclaimed if this driver is stopped or not enabled
> >> in the kernel at all. If you are going to be asinine about simplefb
> >> not getting support for managing any resource other than the memory
> >> chunk then another layer of indirection is required for platforms that
> >> have more resources to manage.
> >>
> >> If there is another way to associate resources with a driver in DT
> >> then please enlighten me.
> >>
> >> AFAICT simplefb is the framebuffer driver already in kernel closest to
> >> the driver that is required for sunxi - simplefb also relies on
> >> firmware to set up the framebuffer but unlike vesafb or efifb it
> >> already has DT integration. So the most efficient way to implement
> >> framebuffer for sunxi is to extend simplefb or if necessary add
> >> another layer of indirection under simplefb. If there is a better
> >> fitting driver in the kernel then please enlighten me and the
> >> developer that wrote this patch what driver it would be.
> >
> > I think simplefb is exactly the right driver to use for this case. But I
> > don't think making it manage all the resources is the right thing to do.
>
> And what is supposed to manage resources used by simplefb when not simplefb?
Nothing should be managing them. There's no need to manage them at all.
The issue that this patch works around is that the clock framework is
trying to be smart and turning all unused clocks off and making
incomplete assumptions about what "all unused clocks" means.
> > While it's fairly easy to do it, it's also something that needs to be
> > done for every other driver with similar requirements.
>
> Other drivers that require clocks do manage them, yes. And some
> drivers that did not do that in the past were extended for that.
Not generic drivers. Not drivers that take over something that firmware
has set up.
> > Consider for
> > example what happens if you want to play some welcome sound in the
> > bootloader and keep it playing while the kernel is booting. You'd need
> > to repeat exactly what this driver does to keep clocks for audio
> > hardware running. And there are possibly other similar use-cases as
> > well.
>
> Why would you want to do that? If the kernel boots fast the welcome
> sound can be played from userspace when all drivers all in place.
In that case you don't need simplefb either. Just use a real driver.
> If it boots slow you can just play the sound and let the kernel boot.
And have audio interrupted by the kernel booting and disabling the
clocks?
> > One other issue with simplefb is that it isn't a real device to begin
> > with. It's completely virtual, so in the same way that it doesn't
> > program any device-specific registers I don't think it should claim any
> > resources.
>
> OK, so the framebuffer memory that simplefb uses for scanout should
> not be claimed by it ever, either?
No. simplefb needs to manage the framebuffer memory because it needs
explicit access to it. The contents of that memory need to be modified.
The frequency of the clocks don't need to be modified. They don't need
to be enabled or disabled either.
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-08-29 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4OyB55L5q7fVo43V8kgtqHRZ3vkBMaA+Htxpob-FA1obaA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2779 bytes --]
On Thu, Aug 28, 2014 at 12:34:58PM -0400, jonsmirl@gmail.com wrote:
> On Thu, Aug 28, 2014 at 12:25 PM, Michal Suchanek <hramrach@gmail.com> wrote:
> > On 28 August 2014 16:33, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> >> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
> >> <geert@linux-m68k.org> wrote:
> >>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> >>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
> >>>>> driver, instead the bootloader should tell the kernel about these clocks.
> >>>>>
> >>>>> So the only point of discussion left seems to be how to do 2...
> >>>>
> >>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
> >>>> whip together a device specific driver that claims the proper
> >>>> resources? And just implement the minimal about of fbdev possible?
> >>>> fbdev already is a driver library.
> >>>
> >>> Like... drivers/video/fbdev/offb.c?
> >>
> >> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
> >> and use it as a template for making device specific versions of it.
> >>
> >> I don't see why there is so much resistance to just making device
> >> specific fb drivers. Whenever the KMS driver gets written just
> >> disable the device specific fb driver in the build.
> >
> > Except that is not the goal here. The simplefb or whatever replacement
> > is supposed to stay as a generic driver compiled into kernel whereas
>
> There is no generic solution to this problem as this entire thread has
> illustrated. The clocks/regulators needed by each SOC vary.
There is a generic solution. Genericity only works if you define a well
defined set of assumptions. In this case the assumptions are that some
firmware sets up display hardware to scan out from a memory region and
communicates the location, layout and format of that memory region so
that a generic driver can write into that framebuffer.
The generic solution here works because we've eliminated the platform
specificities and let firmware take care of it.
> So there are two solutions..
> 1) modify simplefb to have some kind of heuristic that tries to guess
> what needs to be protected. A heuristic that is probably going to fail
> on every new SOC.
>
> 2) Spend a day implementing a device specific fbdev driver that does
> the correct thing all of the time. These drivers would sit in initrd
> and load before the clock/regulator clean up shuts everything off. Use
> the existing simplefb code as a template for doing this.
There's a third possibility: find a way to prevent the clock framework
(and any other resource framework for that matter) from forcefully
disabling things that they shouldn't.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-08-29 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140829070116.GC13106@ulmo>
Hi,
On 08/29/2014 09:01 AM, Thierry Reding wrote:
> On Thu, Aug 28, 2014 at 02:15:40PM +0200, Hans de Goede wrote:
>> On 08/27/2014 04:16 PM, Thierry Reding wrote:
> [...]
>>>> Hmm I see, in my mind the problem is not that the clk framework disables
>>>> unused clocks, but that no one is marking the clocks in question as used.
>>>> Someone should mark these clocks as used so that they do not get disabled.
>>>>
>>>> We could add a clk_mark_in_use function and have the simplefb patch call
>>>> that instead of clk_prepare_and_enable, or maybe even better just only
>>>> claim the clks and teach the clk framework to not disable claimed clk
>>>> in its cleanup run. That would make it clear that simplefb is not enabling
>>>> anything, just claiming resource its need to avoid them getting removed
>>>> from underneath simplefb, would that work for you ?
>>>
>>> That would be more accurate, but it boils down to the same problem where
>>> we still need a driver to claim the resources in some way whereas the
>>> problem is fundamentally one where the bootloader should be telling the
>>> kernel not to disable it. It's in fact the bootloader that's claiming
>>> the resources.
>>
>> Yes, but those resources do not belong to the bootloader in a sense
>> that traditional bootloader / firmware claimed resources (e.g. acpi
>> reserved resources) do. These traditional resources are claimed for ever.
>
> I thought that at least on x86 there was a way for the kernel to reclaim
> memory set apart for an early framebuffer.
>
>> Where as these resources are claimed by the bootloader to keep the simplefb
>> it provides working, as soon as the simplefb is no longer used, they become
>> unused.
>
> Right. And when simplefb goes away it is because a real driver is taking
> over, in which case it will claim the resources explicitly.
>
>>> The copy and paste is for code that's platform specific. The clocks have
>>> different names, resets are different, supplies are different. The fact
>>> that many can currently use the same driver is likely just coincidence
>>> rather than design and it's entirely possible that at some point they'll
>>> add support for a more advanced feature that makes them incompatible
>>> with the rest of the generic drivers. And then you have a big mess
>>> because you need to add quirks all over the place.
>>>
>>> And this isn't all that far off-topic, since simplefb also needs to deal
>>> with this kind of situation. And what I've been arguing is that in order
>>> to really be generic it has to make assumptions, one of which is that it
>>> uses only resources that it doesn't need to explicitly handle.
>>
>> I can understand that you're worried about generic ?hci drivers dealing with
>> clocks / resets / etc. As there may be strict ordering requirements there,
>> but for simplefb that is not the case.
>>
>> All we're asking for is for a way to communicate 2 things to the kernel:
>>
>> 1) These resources are in use (we are not asking the kernel to do anything
>> with them, rather the opposite, we're asking to leave them alone so no
>> ordering issues)
>
> Right. That's the issue that needs to be solved. We still only disagree
> on how it should be solved.
>
>> 2) Tie these resources to simplefb so that the kernel can know when they
>> are no longer in use, and it may e.g. re-use the memory
>
> For the memory there shouldn't be a problem because it's already in the
> DT node anyway. It has to be there so that simplefb knows where to write
> to.
The memory information currently in the dt node is not complete enough to
reclaim memory, e.g. the sunxi driver always reserves 8M, but the simplefb
reg entry only describes the part actually used for the framebuffer.
> For all the other resources, if 1) is solved properly then 2) becomes a
> non-issue.
>
>> To me the most logical and also most "correct" way of modelling this is to
>> put the resources inside the simplefb dt node.
>
> Except that simplefb isn't a real device, so there's a hard time
> justifying its existence in DT as it is. Claiming resources from a
> virtual device doesn't sound correct to me at all.
Yet you want it to claim memory that does not seem consistent to me.
>
>>>> The key word here is "the used resources" to me this is not about simlefb
>>>> managing resources, but marking them as used as long as it needs them, like
>>>> it will need to do for the reserved mem chunk.
>>>
>>> The difference between the clocks and the memory resource is that the
>>> driver needs to directly access the memory (it needs to map it and
>>> provide a userspace mapping for it) whereas it doesn't need to touch the
>>> clocks (except to workaround a Linux-specific implementation detail).
>>
>> Erm, no, the need to map the memory and the memory being a resource
>> which may be released are an orthogonal problem. E.g. a system with
>> dedicated framebuffer memory won't need to use a reserved main-memory
>> chunk, nor need to worry about returning that mem when simplefb is no
>> longer in use.
>
> I would think the memory should still be reserved anyway to make sure
> nothing else is writing over it. And it's in the device tree anyway
> because the driver needs to know where to put framebuffer content.
No, the address were to write framebuffer contents currently is in the
simplefb node, not the actually backing memory info. I can fully see
some crazy hardware where a chunk of main memory is reserved for some
funky video engine, and then that chunk of memory gets accessed through
io-mem addresses for framebuffer access (e.g. the hardware may need this
to know when the fb is dirtied).
> So
> the point I was trying to make is that we can't treat the memory in the
> same way as clocks because it needs to be explicitly managed. Whereas
> clocks don't. The driver is simply too generic to know what to do with
> the clocks. It doesn't know what frequency they should be running at or
> what they're used for, so by any definition of what DT should describe
> they're useless for this virtual device.
I don't see why you keep insisting that the memory is so special, it is
just another resource which we need to claim, and tie to the simplefb node
so that it can be re-used (or disabled) when simplefb is no longer used
(it could e.g. be unbound explicitly on headless systems).
> Furthermore it's fairly likely that as your kernel support progresses
> you'll find that the driver all of a sudden needs to manage some other
> type of resource that you just haven't needed until now because it may
> default to being always on. Then you'll have a hard time keeping
> backwards-compatibility and will have to resort to the kinds of hacks
> that you don't want to see in the kernel.
kernel support? This is about u-boot's video code and the simplefb bindings.
> So it really boils down to the DT needing to describe a complete device
> with all the dependencies. And just clocks aren't the complete
> description. But if you want the complete description then you're going
> to need a complete driver as well and simplefb is out of the picture
> anyway.
Yes we eventually need a full kernel driver, with its own bindings, that
is not what this is about.
> Once again, the current, basic form of the binding allows for a
> completely generic implementation of the driver because it makes
> assumptions about firmware setting things up the right way so that the
> driver doesn't have to.
Except that it does not work because it does not claim the necessary
resources.
We seem to be at a point where this discussion is just going in circles,
and since there seems to be no reasonable alternative to the proposed
solution of adding the clocks to the simplefb node, can you please just
stop blocking progress on this?
Your objection to this has been duly noted, but no one is forcing you or
other people to actually use the clocks property in your implementation
of simplefb. So if your 101% certain that this is a bad idea, can you
please just let us (the sunxi people) make our own mistakes and learn
from those ? As we actually plan to use the clocks property, we will be
the ones which will have to deal with any issues. For the record, I
don't think this is a bad idea myself, but that just brings us full
circle again.
I'm willing to look into just marking the clocks as used, instead of
actually enabling them.
Regards,
Hans
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Thierry Reding @ 2014-08-29 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54002A7D.90402@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 8039 bytes --]
On Fri, Aug 29, 2014 at 09:23:41AM +0200, Hans de Goede wrote:
> On 08/29/2014 09:01 AM, Thierry Reding wrote:
> > On Thu, Aug 28, 2014 at 02:15:40PM +0200, Hans de Goede wrote:
[...]
> >> 2) Tie these resources to simplefb so that the kernel can know when they
> >> are no longer in use, and it may e.g. re-use the memory
> >
> > For the memory there shouldn't be a problem because it's already in the
> > DT node anyway. It has to be there so that simplefb knows where to write
> > to.
>
> The memory information currently in the dt node is not complete enough to
> reclaim memory, e.g. the sunxi driver always reserves 8M, but the simplefb
> reg entry only describes the part actually used for the framebuffer.
You can easily fix that.
> >> To me the most logical and also most "correct" way of modelling this is to
> >> put the resources inside the simplefb dt node.
> >
> > Except that simplefb isn't a real device, so there's a hard time
> > justifying its existence in DT as it is. Claiming resources from a
> > virtual device doesn't sound correct to me at all.
>
> Yet you want it to claim memory that does not seem consistent to me.
Because it needs to explicitly access that memory. It does not need to
explicitly access the clocks.
> >>>> The key word here is "the used resources" to me this is not about simlefb
> >>>> managing resources, but marking them as used as long as it needs them, like
> >>>> it will need to do for the reserved mem chunk.
> >>>
> >>> The difference between the clocks and the memory resource is that the
> >>> driver needs to directly access the memory (it needs to map it and
> >>> provide a userspace mapping for it) whereas it doesn't need to touch the
> >>> clocks (except to workaround a Linux-specific implementation detail).
> >>
> >> Erm, no, the need to map the memory and the memory being a resource
> >> which may be released are an orthogonal problem. E.g. a system with
> >> dedicated framebuffer memory won't need to use a reserved main-memory
> >> chunk, nor need to worry about returning that mem when simplefb is no
> >> longer in use.
> >
> > I would think the memory should still be reserved anyway to make sure
> > nothing else is writing over it. And it's in the device tree anyway
> > because the driver needs to know where to put framebuffer content.
>
> No, the address were to write framebuffer contents currently is in the
> simplefb node, not the actually backing memory info. I can fully see
> some crazy hardware where a chunk of main memory is reserved for some
> funky video engine, and then that chunk of memory gets accessed through
> io-mem addresses for framebuffer access (e.g. the hardware may need this
> to know when the fb is dirtied).
We're drifting off into the realm of hypotheses here. Of course if you
can't make the hardware work with these simple assumptions because it's
too whacky then that's just tough luck.
> > So
> > the point I was trying to make is that we can't treat the memory in the
> > same way as clocks because it needs to be explicitly managed. Whereas
> > clocks don't. The driver is simply too generic to know what to do with
> > the clocks. It doesn't know what frequency they should be running at or
> > what they're used for, so by any definition of what DT should describe
> > they're useless for this virtual device.
>
> I don't see why you keep insisting that the memory is so special, it is
> just another resource which we need to claim,
It's the only resource which we need to claim. Because it is the only
resource that needs to be explicitly accessed. simplefb is useless if
you don't write to that memory.
> and tie to the simplefb node
> so that it can be re-used (or disabled) when simplefb is no longer used
> (it could e.g. be unbound explicitly on headless systems).
On headless systems the firmware shouldn't be setting up a framebuffer
in the first place.
> > Furthermore it's fairly likely that as your kernel support progresses
> > you'll find that the driver all of a sudden needs to manage some other
> > type of resource that you just haven't needed until now because it may
> > default to being always on. Then you'll have a hard time keeping
> > backwards-compatibility and will have to resort to the kinds of hacks
> > that you don't want to see in the kernel.
>
> kernel support? This is about u-boot's video code and the simplefb bindings.
And the kernel doesn't need to use the simplefb bindings? Why are we
even having this conversation, then?
> > So it really boils down to the DT needing to describe a complete device
> > with all the dependencies. And just clocks aren't the complete
> > description. But if you want the complete description then you're going
> > to need a complete driver as well and simplefb is out of the picture
> > anyway.
>
> Yes we eventually need a full kernel driver, with its own bindings, that
> is not what this is about.
It is to some degree. The whole point of simplefb is to provide a useful
graphical output until a full driver is in place. The way to achieve
that is by taking advantage of the firmware setting things up for you.
Which is what I've been saying all along. If the firmware has already
set things up for you, you shouldn't need to do anything special like
enabling clocks because they are already on.
Oh, and let me restate that that's not actually what the patch is doing.
It isn't enabling clocks at all. It's merely a workaround to keep them
running.
> > Once again, the current, basic form of the binding allows for a
> > completely generic implementation of the driver because it makes
> > assumptions about firmware setting things up the right way so that the
> > driver doesn't have to.
>
> Except that it does not work because it does not claim the necessary
> resources.
Wrong. The reason it doesn't work is because the clock framework
disables the clocks. That's a Linux-specific implementation detail and
therefore shouldn't influence the binding in any way.
> We seem to be at a point where this discussion is just going in circles,
> and since there seems to be no reasonable alternative to the proposed
> solution of adding the clocks to the simplefb node, can you please just
> stop blocking progress on this?
A couple of different solutions to the problem were proposed during the
discussion. It's just that nobody's been willing to take a step back and
look at this from a different perspective.
> Your objection to this has been duly noted,
Right. Ignored is how I would put it.
> but no one is forcing you or
> other people to actually use the clocks property in your implementation
> of simplefb. So if your 101% certain that this is a bad idea, can you
> please just let us (the sunxi people) make our own mistakes and learn
> from those ?
Ugh... This isn't just about letting you make your own mistakes. This is
about solving things in a wrong way (and device specific way) and baking
something into an ABI that really doesn't need to be there. And more
specifically if we let clocks be "managed" by simplefb we can no longer
claim that it is simple and therefore can't block adding all other sorts
of device-specific hacks to it.
> As we actually plan to use the clocks property, we will be
> the ones which will have to deal with any issues.
Wrong. Everyone that potentially wants to use the driver will have to
deal with this.
Anyway, I am getting tired of this whole discussion and as you already
said we're not making any progress. You really should repost this series
to the devicetree mailing list and give people there a chance to look at
the proposed changes. If everybody else is fine with it my objections
will be overruled anyway. I'll just have to sort out/live with the mess
when I want to use simplefb for hand-off.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: EARLY_PRINTK equivalent for framebuffers.
From: Geert Uytterhoeven @ 2014-08-29 8:51 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAKON4Owx5wQS29qj9Ks2CzP-Q9Kos6=6MbPRxS+4n9WkdbWegQ@mail.gmail.com>
Hi Jon,
On Thu, Aug 28, 2014 at 9:19 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> Is there some existing way to do early printk type output to a
> framebuffer that has been set up by the bootloader? early printk is
> before any device drivers are loaded.
arch/m68k/kernel/head.S does this on Mac.
ISTR offb also used to do that on PPC, or perhaps it was the
old PowerMac console driver we had before that.
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
* [PATCH] backlight: add new lm3509 backlight driver
From: Daniel Jeong @ 2014-08-29 10:46 UTC (permalink / raw)
To: Jingoo Han, Bryan Wu, Lee Jones, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen
Cc: Daniel Jeong, linux-kernel, linux-fbdev, Daniel Jeong
This is a general driver for LM3509 backlgiht chip of TI.
LM3509 is High Efficiency Boost for White LED's and/or OLED Displays with Dual
Current Sinks. This driver supports OLED/White LED select, brightness control
sub/main conrtorl.
You can refer to the datasheet at http://www.ti.com/product/lm3509 for review.
Signed-off-by: Daniel Jeong <gshark.jeong@gmail.com>
---
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/lm3509_bl.c | 399 +++++++++++++++++++++++++++++++++++
3 files changed, 407 insertions(+)
create mode 100644 drivers/video/backlight/lm3509_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 8d03924..9dc119e 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -366,6 +366,13 @@ config BACKLIGHT_AAT2870
If you have a AnalogicTech AAT2870 say Y to enable the
backlight driver.
+config BACKLIGHT_LM3509
+ tristate "Backlight Driver for LM3509"
+ depends on BACKLIGHT_CLASS_DEVICE && I2C
+ select REGMAP_I2C
+ help
+ This supports TI LM3509 Backlight Driver
+
config BACKLIGHT_LM3630A
tristate "Backlight Driver for LM3630A"
depends on BACKLIGHT_CLASS_DEVICE && I2C && PWM
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index fcd50b73..c34ed98 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_BACKLIGHT_GPIO) += gpio_backlight.o
obj-$(CONFIG_BACKLIGHT_HP680) += hp680_bl.o
obj-$(CONFIG_BACKLIGHT_HP700) += jornada720_bl.o
obj-$(CONFIG_BACKLIGHT_IPAQ_MICRO) += ipaq_micro_bl.o
+obj-$(CONFIG_BACKLIGHT_LM3509) += lm3509_bl.o
obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
obj-$(CONFIG_BACKLIGHT_LM3630A) += lm3630a_bl.o
obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
diff --git a/drivers/video/backlight/lm3509_bl.c b/drivers/video/backlight/lm3509_bl.c
new file mode 100644
index 0000000..4f4fb85
--- /dev/null
+++ b/drivers/video/backlight/lm3509_bl.c
@@ -0,0 +1,399 @@
+/*
+ * Simple driver for Texas Instruments LM3509 Backlight driver chip
+ * Copyright (C) 2014 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include <linux/backlight.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+
+#define LM3509_NAME "lm3509"
+
+#define REG_GP 0x10
+#define REG_BMAIN 0xa0
+#define REG_BSUB 0xb0
+#define REG_MAX 0xff
+
+#define LM3509_POR_BR_MAIN 0xe0
+#define LM3509_POR_BR_SUB 0xe0
+#define LM3509_MAX_BR 0xff
+
+enum lm3509_leds {
+ BLED_BMAIN = 0,
+ BLED_BSUB
+};
+
+struct lm3509_chip {
+ struct device *dev;
+ struct backlight_device *bmain;
+ struct backlight_device *bsub;
+ struct regmap *regmap;
+};
+
+/*
+ * enable main
+ * 0 : disables the main current sink and forces MAIN high impedence.
+ * 1 : enables the main current sink.
+ */
+static ssize_t lm3509_bmain_enable_store(struct device *dev,
+ struct device_attribute *devAttr,
+ const char *buf, size_t size)
+{
+ struct lm3509_chip *pchip = dev_get_drvdata(dev);
+ unsigned int state;
+ ssize_t ret;
+
+ ret = kstrtouint(buf, 10, &state);
+ if (ret) {
+ dev_err(pchip->dev, "input conversion fail\n");
+ return ret;
+ }
+
+ if (!state)
+ ret = regmap_update_bits(pchip->regmap, REG_GP, 0x1, 0x0);
+ else
+ ret = regmap_update_bits(pchip->regmap, REG_GP, 0x1, 0x1);
+ if (ret < 0) {
+ dev_err(pchip->dev, "i2c access fail to register\n");
+ return ret;
+ }
+
+ return size;
+}
+
+static DEVICE_ATTR(main_enable, S_IWUSR, NULL, lm3509_bmain_enable_store);
+
+/*
+ * OLED mode control
+ * 0 : white led mode - main and sub current sinks are active
+ * 1 : OLED mode - sub current sink is idabled
+ */
+static ssize_t lm3509_oled_mode_store(struct device *dev,
+ struct device_attribute *devAttr,
+ const char *buf, size_t size)
+{
+ struct lm3509_chip *pchip = dev_get_drvdata(dev);
+ unsigned int state;
+ ssize_t ret;
+
+ ret = kstrtouint(buf, 10, &state);
+ if (ret) {
+ dev_err(pchip->dev, "input conversion fail\n");
+ return ret;
+ }
+
+ if (!state)
+ ret = regmap_update_bits(pchip->regmap, REG_GP, 0x20, 0x00);
+ else
+ ret = regmap_update_bits(pchip->regmap, REG_GP, 0x20, 0x20);
+ if (ret < 0) {
+ dev_err(pchip->dev, "i2c access fail to register\n");
+ return ret;
+ }
+
+ return size;
+}
+
+static DEVICE_ATTR(oled_enable, S_IWUSR, NULL, lm3509_oled_mode_store);
+
+/*
+ * brightness rate of change
+ * set the rate of change of the LED current in to MAIN and SUB/FB
+ * in response to change in the contents of registers
+ * 0 - 51 us/step
+ * 1 - 13 ms/step
+ * 2 - 26 ms/step
+ * 3 - 52 ms/step
+ */
+static ssize_t lm3509_rate_store(struct device *dev,
+ struct device_attribute *devAttr,
+ const char *buf, size_t size)
+{
+ struct lm3509_chip *pchip = dev_get_drvdata(dev);
+ unsigned int state;
+ ssize_t ret;
+
+ ret = kstrtouint(buf, 10, &state);
+ if (ret) {
+ dev_err(pchip->dev, "input conversion fail\n");
+ return ret;
+ }
+
+ ret = regmap_update_bits(pchip->regmap, REG_GP, 0x18, state << 3);
+ if (ret < 0) {
+ dev_err(pchip->dev, "i2c access fail to register\n");
+ return ret;
+ }
+
+ return size;
+}
+
+static DEVICE_ATTR(rate, S_IWUSR, NULL, lm3509_rate_store);
+
+/* update and get brightness */
+static int lm3509_bmain_update_status(struct backlight_device *bl)
+{
+ struct lm3509_chip *pchip = bl_get_data(bl);
+ int ret;
+
+ ret = regmap_write(pchip->regmap, REG_BMAIN, bl->props.brightness);
+ if (ret < 0)
+ dev_err(pchip->dev, "i2c access fail to register\n");
+ return bl->props.brightness;
+}
+
+static int lm3509_bmain_get_brightness(struct backlight_device *bl)
+{
+ return bl->props.brightness;
+}
+
+static const struct backlight_ops lm3509_bmain_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = lm3509_bmain_update_status,
+ .get_brightness = lm3509_bmain_get_brightness,
+};
+
+/*
+ * enable sub
+ * 0 : disables the secondary current sink and forces SUB/FB high impedence.
+ * 1 : enables the secondary current sink.
+ */
+static ssize_t lm3509_bsub_enable_store(struct device *dev,
+ struct device_attribute *devAttr,
+ const char *buf, size_t size)
+{
+ struct lm3509_chip *pchip = dev_get_drvdata(dev);
+ unsigned int state;
+ ssize_t ret;
+
+ ret = kstrtouint(buf, 10, &state);
+ if (ret) {
+ dev_err(pchip->dev, "input conversion fail\n");
+ return ret;
+ }
+
+ if (!state)
+ ret = regmap_update_bits(pchip->regmap, REG_GP, 0x2, 0x0);
+ else
+ ret = regmap_update_bits(pchip->regmap, REG_GP, 0x2, 0x2);
+ if (ret < 0) {
+ dev_err(pchip->dev, "i2c access fail to register\n");
+ return ret;
+ }
+
+ return size;
+}
+
+static DEVICE_ATTR(sub_enable, S_IWUSR, NULL, lm3509_bsub_enable_store);
+
+/*
+ * uni mode select
+ * 0 : allows the current into MAIN and SUB/FB to be independently controlled
+ * via the bmain and bsub.
+ * 1 : disables the bsub register and causes the contents of bmain to set
+ * the current in both the MAIN and SUB/FB current sinks.
+ */
+static ssize_t lm3509_uni_mode_store(struct device *dev,
+ struct device_attribute *devAttr,
+ const char *buf, size_t size)
+{
+ struct lm3509_chip *pchip = dev_get_drvdata(dev);
+ unsigned int state;
+ ssize_t ret;
+
+ ret = kstrtouint(buf, 10, &state);
+ if (ret) {
+ dev_err(pchip->dev, "input conversion fail\n");
+ return ret;
+ }
+
+ if (!state)
+ ret = regmap_update_bits(pchip->regmap, REG_GP, 0x4, 0x0);
+ else
+ ret = regmap_update_bits(pchip->regmap, REG_GP, 0x4, 0x4);
+ if (ret < 0) {
+ dev_err(pchip->dev, "i2c access fail to register\n");
+ return ret;
+ }
+
+ return size;
+}
+
+static DEVICE_ATTR(uni_mode, S_IWUSR, NULL, lm3509_uni_mode_store);
+
+/* update and get brightness */
+static int lm3509_bsub_update_status(struct backlight_device *bl)
+{
+ struct lm3509_chip *pchip = bl_get_data(bl);
+ int ret;
+
+ ret = regmap_write(pchip->regmap, REG_BSUB, bl->props.brightness);
+ if (ret < 0)
+ dev_err(pchip->dev, "i2c access fail to register\n");
+ return bl->props.brightness;
+}
+
+static int lm3509_bsub_get_brightness(struct backlight_device *bl)
+{
+ return bl->props.brightness;
+}
+
+static const struct backlight_ops lm3509_bsub_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = lm3509_bsub_update_status,
+ .get_brightness = lm3509_bsub_get_brightness,
+};
+
+static int lm3509_backlight_register(struct lm3509_chip *pchip,
+ enum lm3509_leds ledno)
+{
+ struct backlight_properties props;
+
+ props.type = BACKLIGHT_RAW;
+ switch (ledno) {
+ case BLED_BMAIN:
+ props.brightness = LM3509_POR_BR_MAIN;
+ props.max_brightness = LM3509_MAX_BR;
+ pchip->bmain + devm_backlight_device_register(pchip->dev, "bmain",
+ pchip->dev, pchip, &lm3509_bmain_ops, &props);
+ if (IS_ERR(pchip->bmain))
+ return -EIO;
+ break;
+ case BLED_BSUB:
+ props.brightness = LM3509_POR_BR_SUB;
+ props.max_brightness = LM3509_MAX_BR;
+ pchip->bsub + devm_backlight_device_register(pchip->dev, "bsub",
+ pchip->dev, pchip, &lm3509_bsub_ops, &props);
+ if (IS_ERR(pchip->bsub))
+ return -EIO;
+ break;
+ default:
+ BUG();
+ }
+ return 0;
+}
+
+static const struct regmap_config lm3509_regmap = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = REG_MAX,
+};
+
+static int lm3509_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct lm3509_chip *pchip;
+ int ret;
+
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
+ dev_err(&client->dev, "fail : i2c functionality check\n");
+ return -EOPNOTSUPP;
+ }
+
+ pchip = devm_kzalloc(&client->dev, sizeof(struct lm3509_chip),
+ GFP_KERNEL);
+ if (!pchip)
+ return -ENOMEM;
+ pchip->dev = &client->dev;
+
+ pchip->regmap = devm_regmap_init_i2c(client, &lm3509_regmap);
+ if (IS_ERR(pchip->regmap)) {
+ dev_err(&client->dev, "fail : allocate register map\n");
+ ret = PTR_ERR(pchip->regmap);
+ return ret;
+ }
+ i2c_set_clientdata(client, pchip);
+
+ ret = lm3509_backlight_register(pchip, BLED_BMAIN);
+ if (ret < 0)
+ return ret;
+
+ ret = lm3509_backlight_register(pchip, BLED_BSUB);
+ if (ret < 0)
+ return ret;
+
+ ret = device_create_file(&(pchip->bmain->dev), &dev_attr_main_enable);
+ if (ret < 0)
+ return ret;
+
+ ret = device_create_file(&(pchip->bmain->dev), &dev_attr_oled_enable);
+ if (ret < 0)
+ goto err_oled_enable;
+
+ ret = device_create_file(&(pchip->bmain->dev), &dev_attr_rate);
+ if (ret < 0)
+ goto err_rate;
+
+ ret = device_create_file(&(pchip->bsub->dev), &dev_attr_sub_enable);
+ if (ret < 0)
+ goto err_sub_enable;
+
+ ret = device_create_file(&(pchip->bsub->dev), &dev_attr_uni_mode);
+ if (ret < 0)
+ goto err_uni_mode;
+
+ return 0;
+
+err_uni_mode:
+ device_remove_file(&(pchip->bsub->dev), &dev_attr_sub_enable);
+err_sub_enable:
+ device_remove_file(&(pchip->bmain->dev), &dev_attr_rate);
+err_rate:
+ device_remove_file(&(pchip->bmain->dev), &dev_attr_oled_enable);
+err_oled_enable:
+ device_remove_file(&(pchip->bmain->dev), &dev_attr_main_enable);
+ dev_err(pchip->dev, "failed : add sysfs entries\n");
+
+ return ret;
+}
+
+static int lm3509_remove(struct i2c_client *client)
+{
+ int ret;
+ struct lm3509_chip *pchip = i2c_get_clientdata(client);
+
+ device_remove_file(&(pchip->bsub->dev), &dev_attr_uni_mode);
+ device_remove_file(&(pchip->bsub->dev), &dev_attr_sub_enable);
+ device_remove_file(&(pchip->bmain->dev), &dev_attr_rate);
+ device_remove_file(&(pchip->bmain->dev), &dev_attr_oled_enable);
+ device_remove_file(&(pchip->bmain->dev), &dev_attr_main_enable);
+
+ ret = regmap_write(pchip->regmap, REG_GP, 0x0);
+ if (ret < 0)
+ dev_err(pchip->dev, "i2c failed to access register\n");
+
+ return 0;
+}
+
+static const struct i2c_device_id lm3509_id[] = {
+ {LM3509_NAME, 0},
+ {}
+};
+
+MODULE_DEVICE_TABLE(i2c, lm3509_id);
+
+static struct i2c_driver lm3509_i2c_driver = {
+ .driver = {
+ .name = LM3509_NAME,
+ },
+ .probe = lm3509_probe,
+ .remove = lm3509_remove,
+ .id_table = lm3509_id,
+};
+
+module_i2c_driver(lm3509_i2c_driver);
+
+MODULE_DESCRIPTION("Texas Instruments Backlight driver for LM3509");
+MODULE_AUTHOR("Daniel Jeong <gshark.jeong@gmail.com>");
+MODULE_LICENSE("GPL v2");
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v4 00/15] Rework OMAP4+ HDMI audio support
From: Jyri Sarha @ 2014-08-29 11:43 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
detheridge
In-Reply-To: <cover.1408993242.git.jsarha@ti.com>
After discussing with Tomi we decided to turn the omap-hdmi-audio ASoC
library into a platform device. So do not waste too much time in
reviewing these patches. I'll mail a new series soon.
Best regards,
Jyri
On 08/25/2014 10:04 PM, Jyri Sarha wrote:
> The patches are based on:
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git for-next
>
> The base, the patches, and couple of additional not-to-be-merged
> omap2plus_defconfig patches can be found here:
>
> git://git.ti.com/~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git omap-hdmi-audio
>
> Changes since v3:
> - Move ASoC parts into library module under sound/soc/omap
> - Come up with API for the library
> - Some cleaning up
>
> The patch set fixes OMAP4+ HDMI audio. The structure of the
> implementation looks a bit different than before. Instead of creating
> a driver specific API for a separate ASoC component driver to connect
> to, these patches implement a single audio library module under
> sound/soc/omap for ASoC side implementation. The library exports
> omap_hdmi_audio_register() and omap_hdmi_audio_unregister()
> functions. With the functions OMAPDSS HDMI implementation registers
> and unregisters all ASoC components needed for OMAP HDMI audio.
>
> The library implements cpu-dai component using the callbacks provided
> by OMAPDSS. Omap-pcm is registered for platform component, dummy
> hdmi-audio-codec is registered for codec component, and
> asoc-simple-card is registered for machine driver.
>
> Big part of the HDMI audio code is still unchanged and there is a need
> for a cleanup there. Also there is still probably something wrong with
> speaker mapping of multi-channel streams. I will get back to cleaning
> up these issues later.
>
> Best regards,
> Jyri
>
> Jyri Sarha (15):
> OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
> OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs
> OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port()
> OMAPDSS: hdmi_wp: Add function for getting audio dma address
> OMAPDSS: hdmi: Make hdmi structure public
> OMAPDSS: hdmi: Add exported functions for storing HDMI audio data
> OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
> ASoC: omap-hdmi-audio: Add OMAP HDMI audio support library
> OMAPDSS: Kconfig: Implement options for OMAP4 and OMAP5 HDMI audio
> support
> OMAPDSS: hdmi4: Register HDMI audio with omap_hdmi_audio_register()
> OMAPDSS: hdmi5: Register HDMI audio with omap_hdmi_audio_register()
> ASoC: omap: Remove obsolete HDMI audio code and Kconfig options
> OMAPDSS: hdmi4: Remove callbacks for an external ASoC DAI driver
> OMAPDSS: hdmi5: Remove callbacks for an external ASoC DAI driver
> OMAPDSS: Remove all references to obsolete HDMI audio callbacks
>
> .../fbdev/omap2/displays-new/connector-hdmi.c | 99 ------
> .../fbdev/omap2/displays-new/encoder-tpd12s015.c | 56 ---
> drivers/video/fbdev/omap2/dss/Kconfig | 28 +-
> drivers/video/fbdev/omap2/dss/hdmi.h | 35 +-
> drivers/video/fbdev/omap2/dss/hdmi4.c | 233 ++++++-------
> drivers/video/fbdev/omap2/dss/hdmi4_core.c | 14 -
> drivers/video/fbdev/omap2/dss/hdmi4_core.h | 4 -
> drivers/video/fbdev/omap2/dss/hdmi5.c | 216 +++++-------
> drivers/video/fbdev/omap2/dss/hdmi5_core.c | 6 -
> drivers/video/fbdev/omap2/dss/hdmi5_core.h | 2 -
> drivers/video/fbdev/omap2/dss/hdmi_common.c | 18 +-
> drivers/video/fbdev/omap2/dss/hdmi_wp.c | 8 +-
> include/sound/omap-hdmi-audio.h | 50 +++
> include/video/omapdss.h | 34 +-
> sound/soc/omap/Kconfig | 15 +-
> sound/soc/omap/Makefile | 6 +-
> sound/soc/omap/omap-hdmi-audio.c | 357 +++++++++++++++++++
> sound/soc/omap/omap-hdmi-card.c | 87 -----
> sound/soc/omap/omap-hdmi.c | 364 --------------------
> sound/soc/omap/omap-hdmi.h | 38 --
> 20 files changed, 676 insertions(+), 994 deletions(-)
> create mode 100644 include/sound/omap-hdmi-audio.h
> create mode 100644 sound/soc/omap/omap-hdmi-audio.c
> delete mode 100644 sound/soc/omap/omap-hdmi-card.c
> delete mode 100644 sound/soc/omap/omap-hdmi.c
> delete mode 100644 sound/soc/omap/omap-hdmi.h
>
^ permalink raw reply
* [GIT PULL] fbdev fixes for 3.17
From: Tomi Valkeinen @ 2014-08-29 13:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Fbdev development list, LKML
[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]
Hi Linus,
The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef:
Linux 3.17-rc2 (2014-08-25 15:36:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-fixes-3.17
for you to fetch changes up to 4d4e2c003bd6c6bdd85080bd096d54d5d251defa:
video: da8xx-fb: preserve display width when changing HSYNC (2014-08-26 15:36:51 +0300)
----------------------------------------------------------------
fbdev fixes for 3.17
Minor fbdev fixes for da8xx-fb, atmel_lcdfb, arm clcd and chipsfb.
----------------------------------------------------------------
Dan Carpenter (1):
video: of: display_timing: double free on error
Ian Abbott (1):
video: da8xx-fb: preserve display width when changing HSYNC
Jon Medhurst (Tixy) (1):
video: ARM CLCD: Fix calculation of bits-per-pixel
Julia Lawall (1):
drivers: video: fbdev: atmel_lcdfb.c: fix error return code
Pranith Kumar (1):
fbdev: Remove __init from chips_hw_init() to fix build failure
drivers/video/fbdev/amba-clcd.c | 23 ++++++++++++++++++-----
drivers/video/fbdev/atmel_lcdfb.c | 2 ++
drivers/video/fbdev/chipsfb.c | 2 +-
drivers/video/fbdev/da8xx-fb.c | 2 +-
drivers/video/of_display_timing.c | 1 +
5 files changed, 23 insertions(+), 7 deletions(-)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ 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