* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-02 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4Oz8mL5jGzBHZeznd5NbPqq93q7PpTDqHHcV_HYSfqBVHA@mail.gmail.com>
Hi,
On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
<snip>
>>>>> So there are two ways to do this...
>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>> (I think this is a bad idea)
>>>>
>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>> are needed, then earlyconsole can claim them, and release them on
>>>> handover to the real display driver.
>>
>> Jon, can you please answer this ? I really really want to know why people
>> think this is such a bad idea. Understanding why people think this is a bad
>> idea is necessary to be able to come up with an alternative solution.
>
> The list of resources should not be duplicated in the device tree -
> once in the simplefb node and again in the real device node.
It is not duplicated, the simplefb node will list the clocks used for the
mode / output as setup by the firmware, which are often not all clocks
which the display engine supports. Where as the real device node will list
all clocks the display engine may use.
> Device
> tree is a hardware description and it is being twisted to solve a
> software issue.
This is not true, various core devicetree developers have already said
that storing other info in the devicetree is fine, and being able to do so
is part of the original design.
> This problem is not limited to clocks, same problem
> exists with regulators. On SGI systems this would exist with entire
> bus controllers (but they are x86 based, console is not on the root
> bus). This is a very messy problem and will lead to a Frankenstein
> sized driver over time.
This is a "what if ..." argument, we can discuss potential hypothetical
problems all day long, what happens if the sky falls down?
> But... I think this is a red herring which is masking the real
> problem. The real problem seems to be that there is no window for
> loading device specific drivers before the resource clean up phase
> happens. That's a real problem -- multi architecture distros are going
> to have lots of loadable device specific drivers.
As Maxime pointed out to my alternative solution to fixing the clocks
problem, this is not strictly a when to do cleanup problem. If another
driver uses the same clocks, and does a clk_disable call after probing
(because the device is put in low power mode until used by userspace),
then the clk will be disabled even without any cleanup running at all.
The real problem here is simply that to work the simplefb needs certain
resources, just like any other device. And while for any other device
simply listing the needed resources is an accepted practice, for simplefb
for some reason (which I still do not understand) people all of a sudden
see listing resources as a problem.
Regards,
Hans
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: jonsmirl @ 2014-10-02 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542D6633.20907@redhat.com>
On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>
> <snip>
>
>>>>>> So there are two ways to do this...
>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>> (I think this is a bad idea)
>>>>>
>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>> handover to the real display driver.
>>>
>>> Jon, can you please answer this ? I really really want to know why people
>>> think this is such a bad idea. Understanding why people think this is a bad
>>> idea is necessary to be able to come up with an alternative solution.
>>
>> The list of resources should not be duplicated in the device tree -
>> once in the simplefb node and again in the real device node.
>
> It is not duplicated, the simplefb node will list the clocks used for the
> mode / output as setup by the firmware, which are often not all clocks
> which the display engine supports. Where as the real device node will list
> all clocks the display engine may use.
>
>> Device
>> tree is a hardware description and it is being twisted to solve a
>> software issue.
>
> This is not true, various core devicetree developers have already said
> that storing other info in the devicetree is fine, and being able to do so
> is part of the original design.
>
>> This problem is not limited to clocks, same problem
>> exists with regulators. On SGI systems this would exist with entire
>> bus controllers (but they are x86 based, console is not on the root
>> bus). This is a very messy problem and will lead to a Frankenstein
>> sized driver over time.
>
> This is a "what if ..." argument, we can discuss potential hypothetical
> problems all day long, what happens if the sky falls down?
>
>> But... I think this is a red herring which is masking the real
>> problem. The real problem seems to be that there is no window for
>> loading device specific drivers before the resource clean up phase
>> happens. That's a real problem -- multi architecture distros are going
>> to have lots of loadable device specific drivers.
>
> As Maxime pointed out to my alternative solution to fixing the clocks
> problem, this is not strictly a when to do cleanup problem. If another
> driver uses the same clocks, and does a clk_disable call after probing
> (because the device is put in low power mode until used by userspace),
> then the clk will be disabled even without any cleanup running at all.
>
> The real problem here is simply that to work the simplefb needs certain
> resources, just like any other device. And while for any other device
> simply listing the needed resources is an accepted practice, for simplefb
> for some reason (which I still do not understand) people all of a sudden
> see listing resources as a problem.
Because you are creating two different device tree nodes describing a
single piece of hardware and that's not suppose to happen in a device
tree. The accurate description of the hardware is being perverted to
solve a software problem.
One node describes the hardware in a format to make simplefb happy.
Another node describes the same hardware in a format to make the
device specific driver happy.
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: jonsmirl @ 2014-10-02 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4OwMf-zXC_B=VqdVNrD_ExC3zGiGUm4j5KKgS-U4cPB2zg@mail.gmail.com>
On Thu, Oct 2, 2014 at 11:14 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> <snip>
>>
>>>>>>> So there are two ways to do this...
>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>> (I think this is a bad idea)
>>>>>>
>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>> handover to the real display driver.
>>>>
>>>> Jon, can you please answer this ? I really really want to know why people
>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>> idea is necessary to be able to come up with an alternative solution.
>>>
>>> The list of resources should not be duplicated in the device tree -
>>> once in the simplefb node and again in the real device node.
>>
>> It is not duplicated, the simplefb node will list the clocks used for the
>> mode / output as setup by the firmware, which are often not all clocks
>> which the display engine supports. Where as the real device node will list
>> all clocks the display engine may use.
>>
>>> Device
>>> tree is a hardware description and it is being twisted to solve a
>>> software issue.
>>
>> This is not true, various core devicetree developers have already said
>> that storing other info in the devicetree is fine, and being able to do so
>> is part of the original design.
>>
>>> This problem is not limited to clocks, same problem
>>> exists with regulators. On SGI systems this would exist with entire
>>> bus controllers (but they are x86 based, console is not on the root
>>> bus). This is a very messy problem and will lead to a Frankenstein
>>> sized driver over time.
>>
>> This is a "what if ..." argument, we can discuss potential hypothetical
>> problems all day long, what happens if the sky falls down?
>>
>>> But... I think this is a red herring which is masking the real
>>> problem. The real problem seems to be that there is no window for
>>> loading device specific drivers before the resource clean up phase
>>> happens. That's a real problem -- multi architecture distros are going
>>> to have lots of loadable device specific drivers.
>>
>> As Maxime pointed out to my alternative solution to fixing the clocks
>> problem, this is not strictly a when to do cleanup problem. If another
>> driver uses the same clocks, and does a clk_disable call after probing
>> (because the device is put in low power mode until used by userspace),
>> then the clk will be disabled even without any cleanup running at all.
>>
>> The real problem here is simply that to work the simplefb needs certain
>> resources, just like any other device. And while for any other device
>> simply listing the needed resources is an accepted practice, for simplefb
>> for some reason (which I still do not understand) people all of a sudden
>> see listing resources as a problem.
>
> Because you are creating two different device tree nodes describing a
> single piece of hardware and that's not suppose to happen in a device
> tree. The accurate description of the hardware is being perverted to
> solve a software problem.
>
> One node describes the hardware in a format to make simplefb happy.
> Another node describes the same hardware in a format to make the
> device specific driver happy.
But... I think all of this device tree stuff is a red herring and not
the core problem.
Core problem.....
Bios sets stuff up
Built-in drivers initialize
Bios settings get cleaned up (display goes blank)
Loadable drivers initialize (display comes back)
In multi-architecture kernels almost all of the drivers are loadable.
We need to figure out how to change the order....
Bios sets stuff up
Built-in drivers initialize
Loadable drivers initialize
Bios settings get cleaned up
Maybe the Bios cleanup turns into a small app you place at the end of
your init scripts. It's just a power saving cleanup and shouldn't be
causing this much trouble.
I don't think leaving the order as is and using the device tree to
construct a big list of exceptions to the clean up process is the
right approach.
>
>
>>
>> Regards,
>>
>> Hans
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Michal Suchanek @ 2014-10-02 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4OwMf-zXC_B=VqdVNrD_ExC3zGiGUm4j5KKgS-U4cPB2zg@mail.gmail.com>
On 2 October 2014 17:30, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 11:14 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> <snip>
>>>
>>>>>>>> So there are two ways to do this...
>>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>>> (I think this is a bad idea)
>>>>>>>
>>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>>> handover to the real display driver.
>>>>>
>>>>> Jon, can you please answer this ? I really really want to know why people
>>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>>> idea is necessary to be able to come up with an alternative solution.
>>>>
>>>> The list of resources should not be duplicated in the device tree -
>>>> once in the simplefb node and again in the real device node.
>>>
>>> It is not duplicated, the simplefb node will list the clocks used for the
>>> mode / output as setup by the firmware, which are often not all clocks
>>> which the display engine supports. Where as the real device node will list
>>> all clocks the display engine may use.
>>>
>>>> Device
>>>> tree is a hardware description and it is being twisted to solve a
>>>> software issue.
>>>
>>> This is not true, various core devicetree developers have already said
>>> that storing other info in the devicetree is fine, and being able to do so
>>> is part of the original design.
>>>
>>>> This problem is not limited to clocks, same problem
>>>> exists with regulators. On SGI systems this would exist with entire
>>>> bus controllers (but they are x86 based, console is not on the root
>>>> bus). This is a very messy problem and will lead to a Frankenstein
>>>> sized driver over time.
>>>
>>> This is a "what if ..." argument, we can discuss potential hypothetical
>>> problems all day long, what happens if the sky falls down?
>>>
>>>> But... I think this is a red herring which is masking the real
>>>> problem. The real problem seems to be that there is no window for
>>>> loading device specific drivers before the resource clean up phase
>>>> happens. That's a real problem -- multi architecture distros are going
>>>> to have lots of loadable device specific drivers.
>>>
>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.
>>>
>>> The real problem here is simply that to work the simplefb needs certain
>>> resources, just like any other device. And while for any other device
>>> simply listing the needed resources is an accepted practice, for simplefb
>>> for some reason (which I still do not understand) people all of a sudden
>>> see listing resources as a problem.
>>
>> Because you are creating two different device tree nodes describing a
>> single piece of hardware and that's not suppose to happen in a device
>> tree. The accurate description of the hardware is being perverted to
>> solve a software problem.
>>
>> One node describes the hardware in a format to make simplefb happy.
>> Another node describes the same hardware in a format to make the
>> device specific driver happy.
No.
one node describes the state in which the hardware was left by u-boot
and other node describes the display hardware in full.
Obviously, this will overlap but is not duplication.
Or as pointed out the simplefb node is not hardware description but
'other information' which is part of the DT design. If your system
does not use simplefb it can be ignored with no ill side effect (once
the part with claiming memory for simplefb cleanly is resolved).
Did we not discuss that several times already?
>
> But... I think all of this device tree stuff is a red herring and not
> the core problem.
>
> Core problem.....
>
> Bios sets stuff up
> Built-in drivers initialize
> Bios settings get cleaned up (display goes blank)
> Loadable drivers initialize (display comes back)
>
> In multi-architecture kernels almost all of the drivers are loadable.
> We need to figure out how to change the order....
>
> Bios sets stuff up
> Built-in drivers initialize
> Loadable drivers initialize
> Bios settings get cleaned up
>
> Maybe the Bios cleanup turns into a small app you place at the end of
> your init scripts. It's just a power saving cleanup and shouldn't be
> causing this much trouble.
No. You need to do cleanup during driver loading as well. So not doing
the cleanup early gives you more bizarre problems.
Did we not discuss that several times as well?
Thanks
Michal
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-02 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4OyvUeSidyR8OWk9BM4X3BmvzSLyZtbhnMaB75kr-AFuew@mail.gmail.com>
Hi,
On 10/02/2014 05:30 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 11:14 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> <snip>
>>>
>>>>>>>> So there are two ways to do this...
>>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>>> (I think this is a bad idea)
>>>>>>>
>>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>>> handover to the real display driver.
>>>>>
>>>>> Jon, can you please answer this ? I really really want to know why people
>>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>>> idea is necessary to be able to come up with an alternative solution.
>>>>
>>>> The list of resources should not be duplicated in the device tree -
>>>> once in the simplefb node and again in the real device node.
>>>
>>> It is not duplicated, the simplefb node will list the clocks used for the
>>> mode / output as setup by the firmware, which are often not all clocks
>>> which the display engine supports. Where as the real device node will list
>>> all clocks the display engine may use.
>>>
>>>> Device
>>>> tree is a hardware description and it is being twisted to solve a
>>>> software issue.
>>>
>>> This is not true, various core devicetree developers have already said
>>> that storing other info in the devicetree is fine, and being able to do so
>>> is part of the original design.
>>>
>>>> This problem is not limited to clocks, same problem
>>>> exists with regulators. On SGI systems this would exist with entire
>>>> bus controllers (but they are x86 based, console is not on the root
>>>> bus). This is a very messy problem and will lead to a Frankenstein
>>>> sized driver over time.
>>>
>>> This is a "what if ..." argument, we can discuss potential hypothetical
>>> problems all day long, what happens if the sky falls down?
>>>
>>>> But... I think this is a red herring which is masking the real
>>>> problem. The real problem seems to be that there is no window for
>>>> loading device specific drivers before the resource clean up phase
>>>> happens. That's a real problem -- multi architecture distros are going
>>>> to have lots of loadable device specific drivers.
>>>
>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.
>>>
>>> The real problem here is simply that to work the simplefb needs certain
>>> resources, just like any other device. And while for any other device
>>> simply listing the needed resources is an accepted practice, for simplefb
>>> for some reason (which I still do not understand) people all of a sudden
>>> see listing resources as a problem.
>>
>> Because you are creating two different device tree nodes describing a
>> single piece of hardware and that's not suppose to happen in a device
>> tree.
That again is a very narrow reading of what is a very generic descriptive
language. Also note that we are already in this situation with simplefb,
all we're advocating is extending the info which is in the simplefb node
so that it is actually usable in a much wider range of scenarios.
>> The accurate description of the hardware is being perverted to
>> solve a software problem.
Again, devicetree is not strictly a hardware description language.
>> One node describes the hardware in a format to make simplefb happy.
>> Another node describes the same hardware in a format to make the
>> device specific driver happy.
>
> But... I think all of this device tree stuff is a red herring and not
> the core problem.
Actually the red herring is people focussing on the init ordering
solution, which as already explained will simply never work, quoting
myself (from above):
>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.
And to repeat myself yet again:
"The real problem here is simply that to work the simplefb needs certain
resources, just like any other device."
So the logical thing to do is to just put the clocks in the node. The only
counter argument I hear you make is "this is not a hardware description,
so it does not belong in devicetree". An argument which has already
been discussed earlier in this thread (about a month ago) and one of the
officialo devicetree maintainers responded to that saying that it is fine
to have non hardware info in the dt.
Regards,
Hans
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Stephen Warren @ 2014-10-02 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542CF3C3.2050708@redhat.com>
On 10/02/2014 12:42 AM, Hans de Goede wrote:
...
> The whole reason why we want to use simplefb is not just to get things
> running until HW specific driver is in place, but also to have early console
> output (to help debugging boot problems on devices without a serial console),
> in a world where most video drivers are build as loadable modules, so we
> won't have video output until quite late into the boot process.
That's a very different use-case than what was originally envisaged.
...
> You indicate that you don't have the time for this discussion, and I note that
> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
> my responsibility (and in my own benefit) to stop this from growing into
> a monster ?
I have no issue with you being the maintainer.
I would suggest you track down whoever it was that was involved in the
original discussion and objected to simplefb performing resource
management, and get their explicit ack for the addition of
clocks/regulators/... to it. But, that's just a suggestion.
^ permalink raw reply
* FOSDEM15: Graphics DevRoom: call for speakers.
From: Luc Verhaegen @ 2014-10-02 17:44 UTC (permalink / raw)
To: mesa-dev, xorg-devel, dri-devel, xorg, wayland-devel,
xorg-announce, mir-devel, directfb-dev, linux-fbdev, linux-media
Hi,
At FOSDEM on the 31st of january and the 1st of February 2015, there
will be another graphics DevRoom. URL: https://fosdem.org/2015/
The focus of this DevRoom is of course the same as last year, namely:
* Graphics drivers: from display to media to 3d drivers, both in kernel
or userspace. Be it part of DRM, KMS, (direct)FB, V4L, Xorg, Mesa...
* Input drivers: kernel and userspace.
* Windowing systems: X, Wayland, Mir, directFB, ...
* Even colour management and other areas which i might have overlooked
above are accepted.
Slots are 50 minutes long, and scheduled hourly. This partly to avoid
confusion and people running all over the place all the time. As a
speaker, you do not have to fill your whole hour, gaps are never wasted
time.
Slots will be handed out on a first come, first serve basis. The best
slots will go to those who apply the earliest. The amount of slots is
currently not known yet, but i expect there to be around 16 available (8
on each day), so act quickly.
Talk Submission:
----------------
Like last year, the pentabarf system will be used for talk submission.
It is not perfect from a devroom organizer and talk submitters usability
point-of-view, but the fosdem organizers are working on it. It is
however workable and it ended up working out pretty well last year.
https://penta.fosdem.org/submission/FOSDEM15
Remember that FOSDEM is not like XDC, it's not some 50 odd people
meeting with a sliding schedule which only gets filled out on the last
day. Upwards of 8000 people are visiting this event, and most of them
get a printed booklet or use the schedule on the FOSDEM website or an
app for their phone to figure out what to watch or participate in next.
So please put some effort in your talk submission and details.
Since this an open source community event, please refrain from turning
in a talk that is a pure corporate or product commercial. Also, if you
are unsure on whether you can come or not (this is FOSDEM, why are you
not there anyway?), please wait with submitting your talk. Submitting a
talk and then not turning up because you could not be bothered is a
sure-fire way to get larted and then to never be allowed to talk again.
As for deadlines, i hope to have a pretty much complete schedule between
christmas and the new year. The rockhard printed schedule deadline is
probably January 9th, after that you will not be featured in the booklet
and you will have a lot less visitors. I will hopefully be able to lock
down entries and descriptions after that date.
Don't count on this deadline: first come first serve! There are perhaps
only 16 slots. And the worst slots will be assigned to those who come
last. Do you really want to talk on saturday at 10:00 when people are
still in zombie mode after the beer event, if they are there at all?
Use your account from last year, so you can try to recycle some of your
data from last year. If you have forgotten your password, then you can
reset it here: https://penta.fosdem.org/user/forgot_password
Necessary information:
----------------------
Below is a list of what i need to see filled in when you apply for a
devroom before i consider it a valid submission. Remember: first come,
first serve. The best slots are for the earliest submissions and there
are only around 16 slots.
On your personal page:
* General:
* First and last name
* Nickname
* Image
* Contact:
* email
* mobile number (this is a very hard requirement as there will be no
other reliable form of emergency communication on the day)
* Description:
* Abstract
* Description
Create an event:
* On the General page:
* Event title
* Event subtitle.
* Track: Graphics Devroom
* Event type: Lecture (talk) or Meeting (BoF)
* Persons:
* Add yourself as speaker.
* Description:
* Abstract:
* Full Description
* Links:
* Add relevant links.
Everything else can be ignored or will be filled in by me or the FOSDEM
organizers.
That's about it. Hope to see you all at FOSDEM :)
Luc Verhaegen.
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Geert Uytterhoeven @ 2014-10-02 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4Oy8sZ-d6JzWLi7pUeNFE5ge0fr5Tgoc_PSpKcOoiN-0yQ@mail.gmail.com>
On Thu, Oct 2, 2014 at 2:22 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> 1) temporary early boot console -- this is nothing but an address in
> RAM and the x/y layout. The character set from framebuffer is built
> into the kernel. The parallel to this is early-printk and how it uses
> the UARTs without interrupts. This console vaporizes late in the boot
> process -- the same thing happens with the early printk UART driver.
> EARLYPRINTK on the command line enables this.
JFYI, the early serial console can also vanish, even very early in the boot
process, before the unused clocks are disabled.
Cfr. http://marc.info/?l=linux-sh&m\x141227657322649&w=2
So there's no safety in this world without calling clk_prepare_enable().
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Julian Calaby @ 2014-10-02 23:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKON4OwMf-zXC_B=VqdVNrD_ExC3zGiGUm4j5KKgS-U4cPB2zg@mail.gmail.com>
Hi,
On Fri, Oct 3, 2014 at 1:14 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> <snip>
>>
>>>>>>> So there are two ways to do this...
>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>> (I think this is a bad idea)
>>>>>>
>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>> handover to the real display driver.
>>>>
>>>> Jon, can you please answer this ? I really really want to know why people
>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>> idea is necessary to be able to come up with an alternative solution.
>>>
>>> The list of resources should not be duplicated in the device tree -
>>> once in the simplefb node and again in the real device node.
>>
>> It is not duplicated, the simplefb node will list the clocks used for the
>> mode / output as setup by the firmware, which are often not all clocks
>> which the display engine supports. Where as the real device node will list
>> all clocks the display engine may use.
>>
>>> Device
>>> tree is a hardware description and it is being twisted to solve a
>>> software issue.
>>
>> This is not true, various core devicetree developers have already said
>> that storing other info in the devicetree is fine, and being able to do so
>> is part of the original design.
>>
>>> This problem is not limited to clocks, same problem
>>> exists with regulators. On SGI systems this would exist with entire
>>> bus controllers (but they are x86 based, console is not on the root
>>> bus). This is a very messy problem and will lead to a Frankenstein
>>> sized driver over time.
>>
>> This is a "what if ..." argument, we can discuss potential hypothetical
>> problems all day long, what happens if the sky falls down?
>>
>>> But... I think this is a red herring which is masking the real
>>> problem. The real problem seems to be that there is no window for
>>> loading device specific drivers before the resource clean up phase
>>> happens. That's a real problem -- multi architecture distros are going
>>> to have lots of loadable device specific drivers.
>>
>> As Maxime pointed out to my alternative solution to fixing the clocks
>> problem, this is not strictly a when to do cleanup problem. If another
>> driver uses the same clocks, and does a clk_disable call after probing
>> (because the device is put in low power mode until used by userspace),
>> then the clk will be disabled even without any cleanup running at all.
>>
>> The real problem here is simply that to work the simplefb needs certain
>> resources, just like any other device. And while for any other device
>> simply listing the needed resources is an accepted practice, for simplefb
>> for some reason (which I still do not understand) people all of a sudden
>> see listing resources as a problem.
>
> Because you are creating two different device tree nodes describing a
> single piece of hardware and that's not suppose to happen in a device
> tree. The accurate description of the hardware is being perverted to
> solve a software problem.
>
> One node describes the hardware in a format to make simplefb happy.
> Another node describes the same hardware in a format to make the
> device specific driver happy.
Stupid question: What about mangling an existing device node to be
simplefb compatible, and writing simplefb to be binding agnostic?
I listed some psuedo-code to do the latter earlier in the thread.
I.e. changing something like this:
vopb: vopb@ff930000 {
compatible = "rockchip,rk3288-vop";
reg = <0xff930000 0x19c>;
interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru
SRST_LCDC1_DCLK>;
reset-names = "axi", "ahb", "dclk";
iommus = <&vopb_mmu>;
vopb_out: port {
#address-cells = <1>;
#size-cells = <0>;
vopb_out_edp: endpoint@0 {
reg = <0>;
remote-endpoint=<&edp_in_vopb>;
};
vopb_out_hdmi: endpoint@1 {
reg = <1>;
remote-endpoint=<&hdmi_in_vopb>;
};
};
};
into something like this:
vopb: vopb@ff930000 {
compatible = "rockchip,rk3288-vop", "simple-framebuffer";
framebuffer {
reg = <0x1d385000 (1600 * 1200 * 2)>;
width = <1600>;
height = <1200>;
stride = <(1600 * 2)>;
format = "r5g6b5";
};
reg = <0xff930000 0x19c>;
interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru
SRST_LCDC1_DCLK>;
reset-names = "axi", "ahb", "dclk";
iommus = <&vopb_mmu>;
vopb_out: port {
#address-cells = <1>;
#size-cells = <0>;
vopb_out_edp: endpoint@0 {
reg = <0>;
remote-endpoint=<&edp_in_vopb>;
};
vopb_out_hdmi: endpoint@1 {
reg = <1>;
remote-endpoint=<&hdmi_in_vopb>;
};
};
};
And if the clocks are output port specific, we could add some lines
like "simple-framebuffer,ignore-node" to it so simplefb doesn't enable
HDMI clocks when we're using a build-in LCD.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-03 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGRGNgUUG6TOzC5YJgqqKfCM_iK9KcDXW9DPEr1P5OoO1qwd8w@mail.gmail.com>
Hi,
On 10/03/2014 01:31 AM, Julian Calaby wrote:
> Hi,
>
> On Fri, Oct 3, 2014 at 1:14 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> <snip>
>>>
>>>>>>>> So there are two ways to do this...
>>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>>> (I think this is a bad idea)
>>>>>>>
>>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>>> handover to the real display driver.
>>>>>
>>>>> Jon, can you please answer this ? I really really want to know why people
>>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>>> idea is necessary to be able to come up with an alternative solution.
>>>>
>>>> The list of resources should not be duplicated in the device tree -
>>>> once in the simplefb node and again in the real device node.
>>>
>>> It is not duplicated, the simplefb node will list the clocks used for the
>>> mode / output as setup by the firmware, which are often not all clocks
>>> which the display engine supports. Where as the real device node will list
>>> all clocks the display engine may use.
>>>
>>>> Device
>>>> tree is a hardware description and it is being twisted to solve a
>>>> software issue.
>>>
>>> This is not true, various core devicetree developers have already said
>>> that storing other info in the devicetree is fine, and being able to do so
>>> is part of the original design.
>>>
>>>> This problem is not limited to clocks, same problem
>>>> exists with regulators. On SGI systems this would exist with entire
>>>> bus controllers (but they are x86 based, console is not on the root
>>>> bus). This is a very messy problem and will lead to a Frankenstein
>>>> sized driver over time.
>>>
>>> This is a "what if ..." argument, we can discuss potential hypothetical
>>> problems all day long, what happens if the sky falls down?
>>>
>>>> But... I think this is a red herring which is masking the real
>>>> problem. The real problem seems to be that there is no window for
>>>> loading device specific drivers before the resource clean up phase
>>>> happens. That's a real problem -- multi architecture distros are going
>>>> to have lots of loadable device specific drivers.
>>>
>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.
>>>
>>> The real problem here is simply that to work the simplefb needs certain
>>> resources, just like any other device. And while for any other device
>>> simply listing the needed resources is an accepted practice, for simplefb
>>> for some reason (which I still do not understand) people all of a sudden
>>> see listing resources as a problem.
>>
>> Because you are creating two different device tree nodes describing a
>> single piece of hardware and that's not suppose to happen in a device
>> tree. The accurate description of the hardware is being perverted to
>> solve a software problem.
>>
>> One node describes the hardware in a format to make simplefb happy.
>> Another node describes the same hardware in a format to make the
>> device specific driver happy.
>
> Stupid question: What about mangling an existing device node to be
> simplefb compatible, and writing simplefb to be binding agnostic?
That will not work, with simplefb a single node represents the currently
active video output. While in real hardware that may involve multiple
blocks, e.g on sunxi for hdmi out this involves the compositor (which
generates video data from 1 or more layers) which feeds into the
lcd-controller (which in this case is only used to generate hsync + vsync)
signals really, which feeds into the hdmi encoder, all 3 of which are
separate hardware blocks with their own clocks, etc.
And which hardware blocks exactly are involved will differ depending
on which video output of the device has been setup by the firmware.
The simplefb node is a virtual device, describing what the firmware
has setup, where as the hardware nodes are describing the real hardware.
I can see that people see this as duplicate info, but really it is not,
one is runtime information passed from the bootloader/firmware to the
kernel, the other is standard hardware description as people are used
to seeing in devicetree.
Regards,
Hans
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-03 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542D73F5.9040605@wwwdotorg.org>
Hi,
On 10/02/2014 05:49 PM, Stephen Warren wrote:
> On 10/02/2014 12:42 AM, Hans de Goede wrote:
> ...
>> The whole reason why we want to use simplefb is not just to get things
>> running until HW specific driver is in place, but also to have early console
>> output (to help debugging boot problems on devices without a serial console),
>> in a world where most video drivers are build as loadable modules, so we
>> won't have video output until quite late into the boot process.
>
> That's a very different use-case than what was originally envisaged.
I realize that, it is always amazing what sort of uses code finds once it is
out there in the wild :)
>
> ...
>> You indicate that you don't have the time for this discussion, and I note that
>> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
>> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
>> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
>> my responsibility (and in my own benefit) to stop this from growing into
>> a monster ?
>
> I have no issue with you being the maintainer.
Great, I'll send a patch for MAINTAINERS for this then.
> I would suggest you track down whoever it was that was involved in the original discussion and objected to simplefb performing resource management, and get their explicit ack for the addition of clocks/regulators/... to it. But, that's just a suggestion.
I appreciate the suggestion, but various people involved have been discussing this
for over a month now. All arguments in favor and against have been made many times
now, and I doubt that those people (in sofar as they are not already involved in
the discussion) will have anything new to add.
IMHO we've come at a point here where a decision needs to be made how to deal with
this, because any decision, is better then no decision (and thus no progress) at all.
I fully commit myself to actively maintain simplefb, and deal with any fallout, for
the foreseeable future.
Regards,
Hans
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Tomi Valkeinen @ 2014-10-03 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542E8590.70206@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 796 bytes --]
On 03/10/14 14:16, Hans de Goede wrote:
>>> You indicate that you don't have the time for this discussion, and I note that
>>> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
>>> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
>>> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
>>> my responsibility (and in my own benefit) to stop this from growing into
>>> a monster ?
>>
>> I have no issue with you being the maintainer.
>
> Great, I'll send a patch for MAINTAINERS for this then.
In that case, could you, as the maintainer, summarize the plans and/or
biggest issues for simplefb? =)
I've been planning to read this monster thread, but I just haven't found
time.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v2 0/5] simplefb: Add clock support to simplefb
From: Hans de Goede @ 2014-10-03 11:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomi,
Here is v2 of the patch-set to add clocks support to simplefb.
Changes in v2:
-Added "simplefb: Add simplefb MAINTAINERS entry" patch
If you've followed the discussion sofar, then you know that not everyone
agrees 100% with this. The primary concern being that this will turn simplefb
into not-so-simplefb.
However no-one has been able to come up with a workable alternative solution.
We've asked input from Mike Turquette, the clk maintainer, and he agrees
that the solution in this patch-set is the right way to deal with clocks for
simplefb, and he has given his Reviewed-by for the dt-bindings patch.
As for the simplefb code becoming to complex for this, I noticed that
simplefb currently does not have an active maintainer. I've discussed this
with Stephen Warren <swarren@wwwdotorg.org>, the original author of simplefb,
and with his permisson I'm picking up maintainership of simplefb.
And as the new maintainer of simplefb I agree that the approach in this
patch-set is the best way forward, and I've added my Reviewed-by to Luc's
patches adding the clocks property support. I fully commit myself to
actively maintain simplefb for the foreseeable future.
I believe that having the acks of both the clk and simplefb maintainer
is more then good enough to get this set merged despite not everyone
agreeing 100% with it (note some people have expressed concerns, but no one
has actually nacked it).
Therefor I would like to ask you to merge this set for 3.19, or if there is
still time for 3.18.
Thanks & Regards,
Hans
^ permalink raw reply
* [PATCH v2 1/5] simplefb: Add simplefb MAINTAINERS entry
From: Hans de Goede @ 2014-10-03 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1412337125-14388-1-git-send-email-hdegoede@redhat.com>
During the discussion about adding clock handling code to simplefb, it became
clear that simplefb currently does not have an active maintainer.
I've discussed this with Stephen Warren <swarren@wwwdotorg.org>, the original
author of simplefb, and with his permisson I'm picking up maintainership of
simplefb.
Cc: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3705430..01a5fd8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8289,6 +8289,13 @@ F: drivers/media/usb/siano/
F: drivers/media/usb/siano/
F: drivers/media/mmc/siano/
+SIMPLEFB FB DRIVER
+M: Hans de Goede <hdegoede@redhat.com>
+L: linux-fbdev@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/video/simple-framebuffer.txt
+F: drivers/video/fbdev/simplefb.c
+
SH_VEU V4L2 MEM2MEM DRIVER
L: linux-media@vger.kernel.org
S: Orphan
--
2.1.0
^ permalink raw reply related
* [PATCH v2 2/5] dt-bindings: Add a clocks property to the simple-framebuffer binding
From: Hans de Goede @ 2014-10-03 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1412337125-14388-1-git-send-email-hdegoede@redhat.com>
A simple-framebuffer node represents a framebuffer setup by the firmware /
bootloader. Such a framebuffer may have a number of clocks in use, add a
property to communicate this to the OS.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mike Turquette <mturquette@linaro.org>
---
Documentation/devicetree/bindings/video/simple-framebuffer.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 70c26f3..e75478e 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -14,6 +14,9 @@ Required properties:
- r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
- a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
+Optional properties:
+- clocks : List of clocks used by the framebuffer
+
Example:
framebuffer {
--
2.1.0
^ permalink raw reply related
* [PATCH v2 3/5] simplefb: formalize pseudo palette handling
From: Hans de Goede @ 2014-10-03 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1412337125-14388-1-git-send-email-hdegoede@redhat.com>
From: Luc Verhaegen <libv@skynet.be>
Signed-off-by: Luc Verhaegen <libv@skynet.be>
Acked-by: Stephen Warren <swarren@nvidia.com>
[hdegoede@redhat.com: drop unnecessary void * cast]
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/video/fbdev/simplefb.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 210f3a0..ec112c1 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -41,6 +41,8 @@ static struct fb_var_screeninfo simplefb_var = {
.vmode = FB_VMODE_NONINTERLACED,
};
+#define PSEUDO_PALETTE_SIZE 16
+
static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
u_int transp, struct fb_info *info)
{
@@ -50,7 +52,7 @@ static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
u32 cb = blue >> (16 - info->var.blue.length);
u32 value;
- if (regno >= 16)
+ if (regno >= PSEUDO_PALETTE_SIZE)
return -EINVAL;
value = (cr << info->var.red.offset) |
@@ -163,11 +165,16 @@ static int simplefb_parse_pd(struct platform_device *pdev,
return 0;
}
+struct simplefb_par {
+ u32 palette[PSEUDO_PALETTE_SIZE];
+};
+
static int simplefb_probe(struct platform_device *pdev)
{
int ret;
struct simplefb_params params;
struct fb_info *info;
+ struct simplefb_par *par;
struct resource *mem;
if (fb_get_options("simplefb", NULL))
@@ -188,11 +195,13 @@ static int simplefb_probe(struct platform_device *pdev)
return -EINVAL;
}
- info = framebuffer_alloc(sizeof(u32) * 16, &pdev->dev);
+ info = framebuffer_alloc(sizeof(struct simplefb_par), &pdev->dev);
if (!info)
return -ENOMEM;
platform_set_drvdata(pdev, info);
+ par = info->par;
+
info->fix = simplefb_fix;
info->fix.smem_start = mem->start;
info->fix.smem_len = resource_size(mem);
@@ -225,7 +234,7 @@ static int simplefb_probe(struct platform_device *pdev)
framebuffer_release(info);
return -ENODEV;
}
- info->pseudo_palette = (void *)(info + 1);
+ info->pseudo_palette = par->palette;
dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
info->fix.smem_start, info->fix.smem_len,
--
2.1.0
^ permalink raw reply related
* [PATCH v2 4/5] simplefb: add goto error path to probe
From: Hans de Goede @ 2014-10-03 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1412337125-14388-1-git-send-email-hdegoede@redhat.com>
From: Luc Verhaegen <libv@skynet.be>
Signed-off-by: Luc Verhaegen <libv@skynet.be>
Acked-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/video/fbdev/simplefb.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index ec112c1..b7d5c08 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -220,8 +220,8 @@ static int simplefb_probe(struct platform_device *pdev)
info->apertures = alloc_apertures(1);
if (!info->apertures) {
- framebuffer_release(info);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto error_fb_release;
}
info->apertures->ranges[0].base = info->fix.smem_start;
info->apertures->ranges[0].size = info->fix.smem_len;
@@ -231,8 +231,8 @@ static int simplefb_probe(struct platform_device *pdev)
info->screen_base = ioremap_wc(info->fix.smem_start,
info->fix.smem_len);
if (!info->screen_base) {
- framebuffer_release(info);
- return -ENODEV;
+ ret = -ENODEV;
+ goto error_fb_release;
}
info->pseudo_palette = par->palette;
@@ -247,14 +247,20 @@ static int simplefb_probe(struct platform_device *pdev)
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
- iounmap(info->screen_base);
- framebuffer_release(info);
- return ret;
+ goto error_unmap;
}
dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
return 0;
+
+ error_unmap:
+ iounmap(info->screen_base);
+
+ error_fb_release:
+ framebuffer_release(info);
+
+ return ret;
}
static int simplefb_remove(struct platform_device *pdev)
--
2.1.0
^ permalink raw reply related
* [PATCH v2 5/5] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-03 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1412337125-14388-1-git-send-email-hdegoede@redhat.com>
From: Luc Verhaegen <libv@skynet.be>
This claims and enables clocks listed in the simple framebuffer dt node.
This is needed so that the display engine, in case the required clocks
are known by the kernel code and are described in the dt, will remain
properly enabled.
Signed-off-by: Luc Verhaegen <libv@skynet.be>
[hdegoede@redhat.com: drop dev_err on kzalloc failure]
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/video/fbdev/simplefb.c | 100 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 98 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index b7d5c08..f329cc1 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -26,6 +26,7 @@
#include <linux/module.h>
#include <linux/platform_data/simplefb.h>
#include <linux/platform_device.h>
+#include <linux/clk-provider.h>
static struct fb_fix_screeninfo simplefb_fix = {
.id = "simple",
@@ -165,8 +166,98 @@ static int simplefb_parse_pd(struct platform_device *pdev,
return 0;
}
+/*
+ * Clock handling code.
+ *
+ * Here we handle the clocks property of our "simple-framebuffer" dt node.
+ * This is necessary so that we can make sure that any clocks needed by
+ * the display engine that the bootloader set up for us (and for which it
+ * provided a simplefb dt node), stay up, for the life of the simplefb
+ * driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the clocks.
+ */
+struct simplefb_clock {
+ struct list_head list;
+ struct clk *clock;
+};
+
+/*
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the clock definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+static void
+simplefb_clocks_init(struct platform_device *pdev, struct list_head *list)
+{
+ struct device_node *np = pdev->dev.of_node;
+ int clock_count, i;
+
+ INIT_LIST_HEAD(list);
+
+ if (dev_get_platdata(&pdev->dev) || !np)
+ return;
+
+ clock_count = of_clk_get_parent_count(np);
+ for (i = 0; i < clock_count; i++) {
+ struct simplefb_clock *entry;
+ struct clk *clock = of_clk_get(np, i);
+ int ret;
+
+ if (IS_ERR(clock)) {
+ dev_err(&pdev->dev, "%s: clock %d not found: %ld\n",
+ __func__, i, PTR_ERR(clock));
+ continue;
+ }
+
+ ret = clk_prepare_enable(clock);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "%s: failed to enable clock %d: %d\n",
+ __func__, i, ret);
+ clk_put(clock);
+ continue;
+ }
+
+ entry = kzalloc(sizeof(struct simplefb_clock), GFP_KERNEL);
+ if (!entry) {
+ clk_disable_unprepare(clock);
+ clk_put(clock);
+ continue;
+ }
+
+ entry->clock = clock;
+ /*
+ * add to the front of the list, so we disable clocks in the
+ * correct order.
+ */
+ list_add(&entry->list, list);
+ }
+}
+
+static void
+simplefb_clocks_destroy(struct list_head *list)
+{
+ struct list_head *pos, *n;
+
+ list_for_each_safe(pos, n, list) {
+ struct simplefb_clock *entry + container_of(pos, struct simplefb_clock, list);
+
+ list_del(&entry->list);
+
+ clk_disable_unprepare(entry->clock);
+ clk_put(entry->clock);
+ kfree(entry);
+ }
+}
+
struct simplefb_par {
u32 palette[PSEUDO_PALETTE_SIZE];
+ struct list_head clock_list[1];
};
static int simplefb_probe(struct platform_device *pdev)
@@ -236,6 +327,8 @@ static int simplefb_probe(struct platform_device *pdev)
}
info->pseudo_palette = par->palette;
+ simplefb_clocks_init(pdev, par->clock_list);
+
dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
info->fix.smem_start, info->fix.smem_len,
info->screen_base);
@@ -247,14 +340,15 @@ static int simplefb_probe(struct platform_device *pdev)
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
- goto error_unmap;
+ goto error_clocks;
}
dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
return 0;
- error_unmap:
+ error_clocks:
+ simplefb_clocks_destroy(par->clock_list);
iounmap(info->screen_base);
error_fb_release:
@@ -266,8 +360,10 @@ static int simplefb_probe(struct platform_device *pdev)
static int simplefb_remove(struct platform_device *pdev)
{
struct fb_info *info = platform_get_drvdata(pdev);
+ struct simplefb_par *par = info->par;
unregister_framebuffer(info);
+ simplefb_clocks_destroy(par->clock_list);
framebuffer_release(info);
return 0;
--
2.1.0
^ permalink raw reply related
* Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-03 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <542E8C4E.7010001@ti.com>
Hi Tomi,
On 10/03/2014 01:45 PM, Tomi Valkeinen wrote:
> On 03/10/14 14:16, Hans de Goede wrote:
>
>>>> You indicate that you don't have the time for this discussion, and I note that
>>>> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
>>>> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
>>>> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
>>>> my responsibility (and in my own benefit) to stop this from growing into
>>>> a monster ?
>>>
>>> I have no issue with you being the maintainer.
>>
>> Great, I'll send a patch for MAINTAINERS for this then.
>
> In that case, could you, as the maintainer, summarize the plans and/or
> biggest issues for simplefb? =)
>
> I've been planning to read this monster thread, but I just haven't found
> time.
See the cover letter of the patch-set I've just send.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v2 2/5] dt-bindings: Add a clocks property to the simple-framebuffer binding
From: Rob Herring @ 2014-10-03 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1412337125-14388-3-git-send-email-hdegoede@redhat.com>
On Fri, Oct 3, 2014 at 6:52 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> A simple-framebuffer node represents a framebuffer setup by the firmware /
> bootloader. Such a framebuffer may have a number of clocks in use, add a
> property to communicate this to the OS.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Reviewed-by: Mike Turquette <mturquette@linaro.org>
> ---
> Documentation/devicetree/bindings/video/simple-framebuffer.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> index 70c26f3..e75478e 100644
> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> @@ -14,6 +14,9 @@ Required properties:
> - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
> - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>
> +Optional properties:
> +- clocks : List of clocks used by the framebuffer
A simple framebuffer represents a memory region. So now you are saying
this memory region has a clock. That does not make sense and the
description of simple framebuffer is no longer correct.
I assume you are trying to work around the clock framework turning off
clocks on you. If you bothered to describe the clock such that it can
be turned off by the kernel, you should then describe it's actual
connection to the hardware.
Furthermore, when you do add actual driver(s) for the hardware, that
driver will not be able to turn off the clocks because the simplefb
has forced them on. I can see the cases where you want to use
simple-framebuffer early for splash screen or something before the
real driver is up and use it to provide the default video mode for the
real driver.
Rob
^ permalink raw reply
* Re: [PATCH v2 2/5] dt-bindings: Add a clocks property to the simple-framebuffer binding
From: Hans de Goede @ 2014-10-03 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+mG1WnPBADdSVxShZp4-Gaw12gLWzBt2_zYmqWogoknQ@mail.gmail.com>
Hi,
On 10/03/2014 03:20 PM, Rob Herring wrote:
> On Fri, Oct 3, 2014 at 6:52 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> A simple-framebuffer node represents a framebuffer setup by the firmware /
>> bootloader. Such a framebuffer may have a number of clocks in use, add a
>> property to communicate this to the OS.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> Reviewed-by: Mike Turquette <mturquette@linaro.org>
>> ---
>> Documentation/devicetree/bindings/video/simple-framebuffer.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> index 70c26f3..e75478e 100644
>> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> @@ -14,6 +14,9 @@ Required properties:
>> - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
>> - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>>
>> +Optional properties:
>> +- clocks : List of clocks used by the framebuffer
>
> A simple framebuffer represents a memory region. So now you are saying
> this memory region has a clock. That does not make sense and the
> description of simple framebuffer is no longer correct.
Good point, I'll do a v3 updating the description changing it to:
"A simple frame-buffer describes a frame-buffer setup by firmware or
the bootloader, with the assumption that the display hardware has already
been set up to scan out from the memory pointed to by the ref property."
> I assume you are trying to work around the clock framework turning off
> clocks on you. If you bothered to describe the clock such that it can
> be turned off by the kernel, you should then describe it's actual
> connection to the hardware.
In the parts of devicetree where we actually describe the hardware yes,
for the simplefb virtual device it suffices to simple list the used
clocks. Note that a display pipeline often consists of multiple hw-blocks,
so there is not 1:1 mapping between the involved hardware blocks and
the simplefb. The blocks (and clocks) used my even differ between boots
depending on which video output the firmware / bootloader has setup.
> Furthermore, when you do add actual driver(s) for the hardware, that
> driver will not be able to turn off the clocks because the simplefb
> has forced them on. I can see the cases where you want to use
> simple-framebuffer early for splash screen or something before the
> real driver is up and use it to provide the default video mode for the
> real driver.
When we get a real driver, that will (and must) unregister simplefb, at
which point simplefb will release the clocks, and from then on that real
driver can turn off the clocks just fine.
Regards,
Hans
^ permalink raw reply
* [PATCH v3] dt-bindings: Add a clocks property to the simple-framebuffer binding
From: Hans de Goede @ 2014-10-03 14:05 UTC (permalink / raw)
To: linux-arm-kernel
A simple-framebuffer node represents a framebuffer setup by the firmware /
bootloader. Such a framebuffer may have a number of clocks in use, add a
property to communicate this to the OS.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mike Turquette <mturquette@linaro.org>
--
Changes in v2:
-Added Reviewed-by: Mike Turquette <mturquette@linaro.org>
Changes in v3:
-Updated description to make clear simplefb deals with more then just memory
---
Documentation/devicetree/bindings/video/simple-framebuffer.txt | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 70c26f3..91176ee 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -1,8 +1,8 @@
Simple Framebuffer
-A simple frame-buffer describes a raw memory region that may be rendered to,
-with the assumption that the display hardware has already been set up to scan
-out from that buffer.
+A simple frame-buffer describes a frame-buffer setup by firmware or
+the bootloader, with the assumption that the display hardware has already
+been set up to scan out from the memory pointed to by the ref property.
Required properties:
- compatible: "simple-framebuffer"
@@ -14,6 +14,9 @@ Required properties:
- r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
- a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
+Optional properties:
+- clocks : List of clocks used by the framebuffer
+
Example:
framebuffer {
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v3] dt-bindings: Add a clocks property to the simple-framebuffer binding
From: Rob Herring @ 2014-10-03 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1412345120-24588-1-git-send-email-hdegoede@redhat.com>
On Fri, Oct 3, 2014 at 9:05 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> A simple-framebuffer node represents a framebuffer setup by the firmware /
> bootloader. Such a framebuffer may have a number of clocks in use, add a
> property to communicate this to the OS.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Reviewed-by: Mike Turquette <mturquette@linaro.org>
>
> --
> Changes in v2:
> -Added Reviewed-by: Mike Turquette <mturquette@linaro.org>
> Changes in v3:
> -Updated description to make clear simplefb deals with more then just memory
NAK. "Fixing" the description is not what I meant and does not address
my concerns. Currently, simplefb is configuration data. It is
auxiliary data about how a chunk of memory is used. Using it or not
has no side effects on the hardware setup, but you are changing that
aspect. You are mixing in a hardware description that is simply
inaccurate.
The kernel has made the decision to turn off "unused" clocks. If its
determination of what is unused is wrong, then it is not a problem to
fix in DT.
Rob
> ---
> Documentation/devicetree/bindings/video/simple-framebuffer.txt | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> index 70c26f3..91176ee 100644
> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> @@ -1,8 +1,8 @@
> Simple Framebuffer
>
> -A simple frame-buffer describes a raw memory region that may be rendered to,
> -with the assumption that the display hardware has already been set up to scan
> -out from that buffer.
> +A simple frame-buffer describes a frame-buffer setup by firmware or
> +the bootloader, with the assumption that the display hardware has already
> +been set up to scan out from the memory pointed to by the ref property.
>
> Required properties:
> - compatible: "simple-framebuffer"
> @@ -14,6 +14,9 @@ Required properties:
> - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
> - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>
> +Optional properties:
> +- clocks : List of clocks used by the framebuffer
> +
> Example:
>
> framebuffer {
> --
> 2.1.0
>
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: Add a clocks property to the simple-framebuffer binding
From: Geert Uytterhoeven @ 2014-10-03 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKU2n8p=YfJua3k-mR40bG_4SiZY8_-SL-MXtuWN5NeHg@mail.gmail.com>
Hi Rob,
On Fri, Oct 3, 2014 at 5:57 PM, Rob Herring <robherring2@gmail.com> wrote:
> On Fri, Oct 3, 2014 at 9:05 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> A simple-framebuffer node represents a framebuffer setup by the firmware /
>> bootloader. Such a framebuffer may have a number of clocks in use, add a
>> property to communicate this to the OS.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> Reviewed-by: Mike Turquette <mturquette@linaro.org>
>>
>> --
>> Changes in v2:
>> -Added Reviewed-by: Mike Turquette <mturquette@linaro.org>
>> Changes in v3:
>> -Updated description to make clear simplefb deals with more then just memory
>
> NAK. "Fixing" the description is not what I meant and does not address
> my concerns. Currently, simplefb is configuration data. It is
> auxiliary data about how a chunk of memory is used. Using it or not
> has no side effects on the hardware setup, but you are changing that
> aspect. You are mixing in a hardware description that is simply
> inaccurate.
>
> The kernel has made the decision to turn off "unused" clocks. If its
> determination of what is unused is wrong, then it is not a problem to
> fix in DT.
The kernel has made that decision because the driver hadn't told the
kernel that those clocks had to be enabled.
The only way for the driver to know which clocks to enable is by adding
them to the description in DT.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: Add a clocks property to the simple-framebuffer binding
From: Rob Herring @ 2014-10-03 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVgaXoGXyJdD8PRufZQYLTSY=_ZWRRo=OtRo3mrg3uEug@mail.gmail.com>
On Fri, Oct 3, 2014 at 11:04 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Rob,
>
> On Fri, Oct 3, 2014 at 5:57 PM, Rob Herring <robherring2@gmail.com> wrote:
>> On Fri, Oct 3, 2014 at 9:05 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> A simple-framebuffer node represents a framebuffer setup by the firmware /
>>> bootloader. Such a framebuffer may have a number of clocks in use, add a
>>> property to communicate this to the OS.
>>>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> Reviewed-by: Mike Turquette <mturquette@linaro.org>
>>>
>>> --
>>> Changes in v2:
>>> -Added Reviewed-by: Mike Turquette <mturquette@linaro.org>
>>> Changes in v3:
>>> -Updated description to make clear simplefb deals with more then just memory
>>
>> NAK. "Fixing" the description is not what I meant and does not address
>> my concerns. Currently, simplefb is configuration data. It is
>> auxiliary data about how a chunk of memory is used. Using it or not
>> has no side effects on the hardware setup, but you are changing that
>> aspect. You are mixing in a hardware description that is simply
>> inaccurate.
>>
>> The kernel has made the decision to turn off "unused" clocks. If its
>> determination of what is unused is wrong, then it is not a problem to
>> fix in DT.
>
> The kernel has made that decision because the driver hadn't told the
> kernel that those clocks had to be enabled.
> The only way for the driver to know which clocks to enable is by adding
> them to the description in DT.
Lack of a proper and complete driver is still a kernel problem. Now,
if you want to accurately describe the display h/w in DT and you
happen to use the simplefb driver, I don't really care. It just needs
to be a separate binding.
A driver is not the only solution here. The SOC or clock controller
code could keep the clock on based on either the fact that the clock
is already on or it is just hardcoded. This is not a problem unique to
displays.
Rob
^ 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