Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
Hi Grant,
On Tue, Nov 11, 2014 at 10:49 PM, Grant Likely grant.lik...@linaro.org wrote:
However, I am concerned about handover. I've lost track over the entire
thread on whether the handover mechanism has been resolved, and I would
really like to have a proposed solution to this documented in the
binding. The fact that there is nothing tying the simple framebuffer to
the actual hardware backing the framebuffer is concerning. It means the
kernel needs to guess which graphics device is associated with the
framebuffer.
We did discuss handover in Düsseldorf, and concluded that the simplefb's
regs property can be used for this.
While on a modern system with unified memory this association cannot be
derived in a generic way, a device-specific driver for the graphics hardware
can if the regs property of the simplefb node matches the address the CRTC
engine is configured for.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
On Wednesday, November 12, 2014, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
Hi Grant,
On Tue, Nov 11, 2014 at 10:49 PM, Grant Likely grant.lik...@linaro.org
wrote:
However, I am concerned about handover. I've lost track over the entire
thread on whether the handover mechanism has been resolved, and I would
really like to have a proposed solution to this documented in the
binding. The fact that there is nothing tying the simple framebuffer to
the actual hardware backing the framebuffer is concerning. It means the
kernel needs to guess which graphics device is associated with the
framebuffer.
We did discuss handover in Düsseldorf, and concluded that the simplefb's
regs property can be used for this.
While on a modern system with unified memory this association cannot be
derived in a generic way, a device-specific driver for the graphics hardware
can if the regs property of the simplefb node matches the address the CRTC
engine is configured for.
???
Right, I'm going to be blunt here: That's just dumb. All the
capability needed is there in the DT to associate a simple FB to a
display controller, and the solution chosen is to use a heuristic?
The association needs to be explicit. I strongly prefer putting the
simple FB directly into the display controller node, but I would
consider phandle linkage also.
g.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
ge...@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
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
Hi Grant,
On Wed, Nov 12, 2014 at 10:57 AM, Grant Likely grant.lik...@linaro.org wrote:
On Wednesday, November 12, 2014, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Tue, Nov 11, 2014 at 10:49 PM, Grant Likely grant.lik...@linaro.org
wrote:
However, I am concerned about handover. I've lost track over the entire
thread on whether the handover mechanism has been resolved, and I would
really like to have a proposed solution to this documented in the
binding. The fact that there is nothing tying the simple framebuffer to
the actual hardware backing the framebuffer is concerning. It means the
kernel needs to guess which graphics device is associated with the
framebuffer.
We did discuss handover in Düsseldorf, and concluded that the simplefb's
regs property can be used for this.
While on a modern system with unified memory this association cannot be
derived in a generic way, a device-specific driver for the graphics hardware
can if the regs property of the simplefb node matches the address the CRTC
engine is configured for.
???
Right, I'm going to be blunt here: That's just dumb. All the
capability needed is there in the DT to associate a simple FB to a
display controller, and the solution chosen is to use a heuristic?
The association needs to be explicit. I strongly prefer putting the
simple FB directly into the display controller node, but I would
consider phandle linkage also.
IFF there's a display controller node, you can put it there.
I actually proposed to have a minimal/preliminary display controller node,
but people countered that for various reasons (too many components
with multiple nodes on many systems, bindings not yet defined, etc.).
And if there's no graphics driver/bindings yet at the time the bootloader
is written, it doesn't know how to link simplefb with it in DT.
Hence the heuristic to match regs... Does that make sense?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
On Wed, Nov 12, 2014 at 10:08 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote: Hi Grant, On Wed, Nov 12, 2014 at 10:57 AM, Grant Likely grant.lik...@linaro.org wrote: On Wednesday, November 12, 2014, Geert Uytterhoeven ge...@linux-m68k.org wrote: On Tue, Nov 11, 2014 at 10:49 PM, Grant Likely grant.lik...@linaro.org wrote: However, I am concerned about handover. I've lost track over the entire thread on whether the handover mechanism has been resolved, and I would really like to have a proposed solution to this documented in the binding. The fact that there is nothing tying the simple framebuffer to the actual hardware backing the framebuffer is concerning. It means the kernel needs to guess which graphics device is associated with the framebuffer. We did discuss handover in Düsseldorf, and concluded that the simplefb's regs property can be used for this. While on a modern system with unified memory this association cannot be derived in a generic way, a device-specific driver for the graphics hardware can if the regs property of the simplefb node matches the address the CRTC engine is configured for. ??? Right, I'm going to be blunt here: That's just dumb. All the capability needed is there in the DT to associate a simple FB to a display controller, and the solution chosen is to use a heuristic? The association needs to be explicit. I strongly prefer putting the simple FB directly into the display controller node, but I would consider phandle linkage also. IFF there's a display controller node, you can put it there. I actually proposed to have a minimal/preliminary display controller node, but people countered that for various reasons (too many components with multiple nodes on many systems, bindings not yet defined, etc.). And if there's no graphics driver/bindings yet at the time the bootloader is written, it doesn't know how to link simplefb with it in DT. Hence the heuristic to match regs... Does that make sense? No, not really. The simplefb binding /should/ make it clear that handover to the real display controller driver is an expected use case; therefore the simplefb binding should itemize exactly how that linkage is supposed to be expressed. When the display controller binding is written, it should go hand in glove with the simplefb binding. We want to be sure that generic code can be used to resolve a display controller with (one of) the simple framebuffers. It also sounds like some are making the assumption that firmware should generate the simplefb node from scratch, hence all the hand wringing about firmware not knowing what extra stuff to put into the simplefb node. I don't think this is necessary, or even a good approach. A disabled simplefb node can be put into the dts file with any dependencies it needs to care about and linkage to the real display controller. Firmware should be able to locate that node, update the parameters as needed, and enable it. That gets out of the cycle of updating firmware in lockstep. g. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
On Sat, 1 Nov 2014 04:47:56 +0800 , Rob Herring robherri...@gmail.com wrote: On Wed, Oct 29, 2014 at 7:08 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi Hans, Rob, On 28/10/14 13:30, Hans de Goede wrote: Hi, On 10/28/2014 12:11 PM, Rob Herring wrote: Yes, I object to the binding still as it has not changed from what was previously posted. It would be helpful if you could explain why you object. Last time you said: You are mixing in a hardware description that is simply inaccurate. I then explained that this is not hardware description, but runtime state information, as it tells the kernel which clocks were chosen to drive the display (out of typically a list of possible options, depending on which output is used, etc.). Just like which memory address the bootloader has chosen to scan out the video image from. Then you got quiet, so sorry, but this time your objection really is too late. You cannot simply go quiet halfway through a discussion and then pop up again when a new version is posted to say I object yet another time, you've had your chance to make your arguments last time, and chose to stay quiet after I explained in detail that this is not hardware description but state information, so now it is simply too late. These bindings have been discussed at Plumbers with various interested people present, and the conclusion was that this really is the best way to handle this, so this patch is: Signed-off-by: Hans de Goede hdego...@redhat.com Reviewed-by: Mike Turquette mturque...@linaro.org Acked-by: Geert Uytterhoeven ge...@linux-m68k.org Reviewed-by: Maxime Ripard maxime.rip...@free-electrons.com And David Herrman who is working on simpledrm, which will be merged soon, which will also use the simplefb bindings also agrees. So we have the simplefb maintainer, simpledrm maintainer, and the clk subsystem maintainer + 2 other maintainers all agreeing on a way forward, the time for bikeshedding now really really really is over. Tomi, can you please let us know how you plan to proceed with this ? I won't merge DT bindings via fbdev tree, if a DT maintainer says no. I took Rob's silence to the earlier series as a silent ack for your explanation. Obviously that was not the case. Rob, please advice asap what should be done to the bindings to get your ack. As Hans explained above, this discussion has been going on for a long time, and afaik this series is the best way forward of all the options discussed. I still think for the most part this is a kernel problem. It is a kernel policy to turn off unused clocks. The clock framework could just as easily decide that any clocks enabled at boot and left un-managed (i.e. w/o a driver) are kept on until they are managed. I'm not saying this can't be in DT, only that DT is not the only solution here. This problem is not unique to simplefb. A serial console could stop working if no serial driver is loaded before unused clocks are disabled. CPU core clocks have a similar issue as well (often enabled in platform code). I want to see this solved in a generic way for any clock. I've spent most of today rereading the entire thread and thinking about this issue. Given that the clock binding is a well established core binding at this point, it is entirely reasonable for a generic driver to have part of the binding specify the clock resources that it depends on to keep working. The binding needs to be very clear that it is a mere dependency, and that the OS must not make any attempt to modify the clock settings, but it is reasonable indicate to the OS that the clocks are used by the firmware framebuffer, and turning them off will cause the framebuffer will break. The best place to provide that guidance is directly in the node. If we were talking about a resource that didn't have a well established binding, ie, the video path configuration, then I'd still say no way because there is no way to do it generically. Claiming clocks on the other hand is straight forward and simple. Aside from wanting the documentation to be more explicit about what the driver does with the clocks, I don't have a problem with doing it. However, I am concerned about handover. I've lost track over the entire thread on whether the handover mechanism has been resolved, and I would really like to have a proposed solution to this documented in the binding. The fact that there is nothing tying the simple framebuffer to the actual hardware backing the framebuffer is concerning. It means the kernel needs to guess which graphics device is associated with the framebuffer. The best solution in my opinion is to embed the simplefb properties directly into the graphics device node (Yes, I know some have argued that the graphics subsystem is composed of multiple devices; That doesn't matter. Just choose one of the device nodes; the device that actually DMAs
Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
On Thu, 06 Nov 2014 16:05:13 +0100 , Hans de Goede hdego...@redhat.com wrote: Hi, On 11/06/2014 03:18 PM, Tomi Valkeinen wrote: On 31/10/14 10:15, Tomi Valkeinen wrote: Hi Hans, On 22/10/14 19:45, Hans de Goede wrote: -We will add a clocks property to the simplefb devicetree bindings, so that u-boot setup framebuffers passed to the kernel (for early console support) can properly list the clocks used, and simplefb can claim them to avoid them getting turned off, thereby breaking the early console Perhaps this has been discussed earlier, but I started to wonder if managing clocks is enough. What about regulators (to power the LCD), gpios (to keep the LCD enabled) and pinctrl (for video signals)? I guess any those could be reset by the kernel if no driver uses them. I'm okay with extending the binding for each of these dependencies /providing/ it can be argued that the way simplefb uses it is merely to inhibit the kernel from making any changes to the resource, and then releasing the resource when it is done. Each resource type will need to be taken on a case-by-case basis since each has it's own behaviour. I'll want to see that the simplefb driver doesn't need to do anything special per device, and that the resource binding is well established and generic. g. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
Hi, On 11/06/2014 03:18 PM, Tomi Valkeinen wrote: On 31/10/14 10:15, Tomi Valkeinen wrote: Hi Hans, On 22/10/14 19:45, Hans de Goede wrote: -We will add a clocks property to the simplefb devicetree bindings, so that u-boot setup framebuffers passed to the kernel (for early console support) can properly list the clocks used, and simplefb can claim them to avoid them getting turned off, thereby breaking the early console Perhaps this has been discussed earlier, but I started to wonder if managing clocks is enough. What about regulators (to power the LCD), gpios (to keep the LCD enabled) and pinctrl (for video signals)? I guess any those could be reset by the kernel if no driver uses them. Hans, ping. Have these been already discussed? Yes, and I already responded to your original mail on this on Oct. 31th, for some reason my mail client drops you from the CC, when I do a reply-to-all to one of your mails (I've added you manually this time). My replies did go to simple...@vger.kernel.org .I'll forward my 2 mails on this to you. 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
On Sun, Nov 02, 2014 at 10:28:48AM -0500, jonsm...@gmail.com wrote: Simplefb is also being developed as a way of protecting the BIOS setup of the framebuffer past the boot process and out into use as a normal user space console. I in no way support this use. We have experienced decades of problems on the x86 with VGA and BIOSes that I do not wish to repeat in the ARM world. Oh wow. Luc Verhaegen, aka, the guy who made BIOS-free display drivers possible. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
Hi, On 10/31/2014 09:47 PM, Rob Herring wrote: On Wed, Oct 29, 2014 at 7:08 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi Hans, Rob, On 28/10/14 13:30, Hans de Goede wrote: Hi, On 10/28/2014 12:11 PM, Rob Herring wrote: Yes, I object to the binding still as it has not changed from what was previously posted. It would be helpful if you could explain why you object. Last time you said: You are mixing in a hardware description that is simply inaccurate. I then explained that this is not hardware description, but runtime state information, as it tells the kernel which clocks were chosen to drive the display (out of typically a list of possible options, depending on which output is used, etc.). Just like which memory address the bootloader has chosen to scan out the video image from. Then you got quiet, so sorry, but this time your objection really is too late. You cannot simply go quiet halfway through a discussion and then pop up again when a new version is posted to say I object yet another time, you've had your chance to make your arguments last time, and chose to stay quiet after I explained in detail that this is not hardware description but state information, so now it is simply too late. These bindings have been discussed at Plumbers with various interested people present, and the conclusion was that this really is the best way to handle this, so this patch is: Signed-off-by: Hans de Goede hdego...@redhat.com Reviewed-by: Mike Turquette mturque...@linaro.org Acked-by: Geert Uytterhoeven ge...@linux-m68k.org Reviewed-by: Maxime Ripard maxime.rip...@free-electrons.com And David Herrman who is working on simpledrm, which will be merged soon, which will also use the simplefb bindings also agrees. So we have the simplefb maintainer, simpledrm maintainer, and the clk subsystem maintainer + 2 other maintainers all agreeing on a way forward, the time for bikeshedding now really really really is over. Tomi, can you please let us know how you plan to proceed with this ? I won't merge DT bindings via fbdev tree, if a DT maintainer says no. I took Rob's silence to the earlier series as a silent ack for your explanation. Obviously that was not the case. Rob, please advice asap what should be done to the bindings to get your ack. As Hans explained above, this discussion has been going on for a long time, and afaik this series is the best way forward of all the options discussed. I still think for the most part this is a kernel problem. It is a kernel policy to turn off unused clocks. The clock framework could just as easily decide that any clocks enabled at boot and left un-managed (i.e. w/o a driver) are kept on until they are managed. This is not just about being unmanaged, clocks can be shared, and another driver can actively claim the clock and turn it off, we need to protect against this too. I'm not saying this can't be in DT, only that DT is not the only solution here. Basically the problem is that we must keep the clock enabled for the lifetime of the simplefb device. We've been over this in 2 very long threads already, and many alternatives have been evaluated and found wanting. The only 100% safe way to ensure clocks are not turned off is to tie there lifetime to that of the simplefb device, and the only reliable way to do that is through a clocks property. It really is that simple, and I don't understand why people keep insisting there must be another way, while they fail to offer a (reliable, working) other way. This problem is not unique to simplefb. A serial console could stop working if no serial driver is loaded before unused clocks are disabled. CPU core clocks have a similar issue as well (often enabled in platform code). I want to see this solved in a generic way for any clock. As regulators were also mentioned, they already have a regulator-boot-on property defined. Perhaps this is suitable to be mirrored for clocks. If it is not, then I'm wondering why we have it. A key difference here is that the property is part of the provider and can be dealt with in the clock driver rather than requiring a temporary driver. regulator-boot-on tells the regulator framework to enable a regulator at boot, but it does not protect it from getting turned of by another driver later (it does not increase use_count). So this is the same none solution as not turning off unmanaged clocks, what if another driver who shares the clock, enables it during probe, then disables it while done probing (to put things in low power state until userspace uses the device). This is not about not turning the clock off, this is about keeping the clock on for the lifetime of the simplefb device, which is a different problem, cause we must not remove a single calling point of clock_off, put we must block all attempts to turn the clock off, which is done by increasing its use-count, which is done by claiming + enabling it,
Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
On Fri, Oct 31, 2014 at 4:47 PM, Rob Herring robherri...@gmail.com wrote: On Wed, Oct 29, 2014 at 7:08 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi Hans, Rob, On 28/10/14 13:30, Hans de Goede wrote: Hi, On 10/28/2014 12:11 PM, Rob Herring wrote: Yes, I object to the binding still as it has not changed from what was previously posted. It would be helpful if you could explain why you object. Last time you said: You are mixing in a hardware description that is simply inaccurate. I then explained that this is not hardware description, but runtime state information, as it tells the kernel which clocks were chosen to drive the display (out of typically a list of possible options, depending on which output is used, etc.). Just like which memory address the bootloader has chosen to scan out the video image from. Then you got quiet, so sorry, but this time your objection really is too late. You cannot simply go quiet halfway through a discussion and then pop up again when a new version is posted to say I object yet another time, you've had your chance to make your arguments last time, and chose to stay quiet after I explained in detail that this is not hardware description but state information, so now it is simply too late. These bindings have been discussed at Plumbers with various interested people present, and the conclusion was that this really is the best way to handle this, so this patch is: Signed-off-by: Hans de Goede hdego...@redhat.com Reviewed-by: Mike Turquette mturque...@linaro.org Acked-by: Geert Uytterhoeven ge...@linux-m68k.org Reviewed-by: Maxime Ripard maxime.rip...@free-electrons.com And David Herrman who is working on simpledrm, which will be merged soon, which will also use the simplefb bindings also agrees. So we have the simplefb maintainer, simpledrm maintainer, and the clk subsystem maintainer + 2 other maintainers all agreeing on a way forward, the time for bikeshedding now really really really is over. Tomi, can you please let us know how you plan to proceed with this ? I won't merge DT bindings via fbdev tree, if a DT maintainer says no. I took Rob's silence to the earlier series as a silent ack for your explanation. Obviously that was not the case. Rob, please advice asap what should be done to the bindings to get your ack. As Hans explained above, this discussion has been going on for a long time, and afaik this series is the best way forward of all the options discussed. I still think for the most part this is a kernel problem. It is a kernel policy to turn off unused clocks. The clock framework could just as easily decide that any clocks enabled at boot and left un-managed (i.e. w/o a driver) are kept on until they are managed. I'm not saying this can't be in DT, only that DT is not the only solution here. This problem is not unique to simplefb. A serial console could stop working if no serial driver is loaded before unused clocks are disabled. CPU core clocks have a similar issue as well (often enabled in platform code). I want to see this solved in a generic way for any clock. I am in agreement this point of view. This is a problem in the Linux kernel. It is not a generic problem. The Linux problem is that during boot device drivers are loaded in two phases - built-in and loadable modules. The clock-regulator clean up is happening too early. It happens after the built-in drivers load and before the loadable modules have a chance to load. That's simply the wrong place for that clean up happen. A simple alternative would be to make a tiny loadable module that triggers the clean up. Then adjust your boot scripts to load this module after the other ones have loaded. But instead of fixing this simple timing flaw in the Linux boot process a complex mechanism is being created to work around it. Simplefb is also being developed as a way of protecting the BIOS setup of the framebuffer past the boot process and out into use as a normal user space console. I in no way support this use. We have experienced decades of problems on the x86 with VGA and BIOSes that I do not wish to repeat in the ARM world. Write a correct, device specific framebuffer driver for this piece of hardware. That device specific driver will load before the clock/regulator cleanup and claim all of the correct resources. As regulators were also mentioned, they already have a regulator-boot-on property defined. Perhaps this is suitable to be mirrored for clocks. If it is not, then I'm wondering why we have it. A key difference here is that the property is part of the provider and can be dealt with in the clock driver rather than requiring a temporary driver. Rob -- 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
Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
Hello Hans, On Fri, Oct 31, 2014 at 10:00 AM, Hans de Goede hdego...@redhat.com wrote: Hi Tomi, On 10/31/2014 09:15 AM, Tomi Valkeinen wrote: Hi Hans, On 22/10/14 19:45, Hans de Goede wrote: -We will add a clocks property to the simplefb devicetree bindings, so that u-boot setup framebuffers passed to the kernel (for early console support) can properly list the clocks used, and simplefb can claim them to avoid them getting turned off, thereby breaking the early console Perhaps this has been discussed earlier, but I started to wonder if managing clocks is enough. Managing clocks is definitely not enough. For example, adding some regulators to the Snow Chromebook DTS broke simplefb [0]. This has been mentioned on at least one of the many simplefb threads. What about regulators (to power the LCD), gpios (to keep the LCD enabled) and pinctrl (for video signals)? I guess any those could be reset by the kernel if no driver uses them. Yes this has been discussed before, AFAIK gpio / pinctrls should not be spontaneously reset by the kernels. Regulators will be a problem, but there we can pretty much follow whatever solution we end up with for clocks, since they work very much alike (e.g. we could add a supply property to the simplefb node). I think someone already said this but with regulators is not that easy since you don't have an equivalent of the clocks property. You need a name-supply property for each regulator that is an input supply. Some boards may need different regulators for their display (e.g: one to power the LCD and another to power the backlight) so adding a single supply property will not be enough. Note I've no intention to add regulator support atm, we can do that when the need arises, so that we can actually test the code. AFAIU that's exactly what Thierry was complaining about. There seems to be only a focus on solving the clocks issue since that is needed for sunxi but ignoring how the problem for other resources should be solved. The assumptions made by simplefb are quite fragile and only adding support for managing clocks is just a partial solution that will give a false sense of robustness since it could break later due to other resources. Best regards, Javier [0]: http://www.spinics.net/lists/arm-kernel/msg360119.html -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
Hello Hans, Thanks for your answers. On Fri, Oct 31, 2014 at 10:51 AM, Hans de Goede hdego...@redhat.com wrote: What about regulators (to power the LCD), gpios (to keep the LCD enabled) and pinctrl (for video signals)? I guess any those could be reset by the kernel if no driver uses them. Yes this has been discussed before, AFAIK gpio / pinctrls should not be spontaneously reset by the kernels. Regulators will be a problem, but there we can pretty much follow whatever solution we end up with for clocks, since they work very much alike (e.g. we could add a supply property to the simplefb node). I think someone already said this but with regulators is not that easy since you don't have an equivalent of the clocks property. You need a name-supply property for each regulator that is an input supply. Some boards may need different regulators for their display (e.g: one to power the LCD and another to power the backlight) so adding a single supply property will not be enough. Right so we can simply insert simplefbvdd1-supply, simplefbvdd2-supply, etc. regulator nodes into the simplefb node, and have the simplefb kernel code look for supplies with a name of simplefb_vdd%d in a loop until it fails to find one. Note that the foo-supply names are local to the simplefb node, these do not need to be the same as the ones in the nodes describing the actual hardware blocks. Not having an array is somewhat inconvenient, but easily worked around and once worked around this really is just the same problem as with clocks. Yes, I guess the question is how many regulators the driver should support but I expect most displays don't need more than a couple. Note I've no intention to add regulator support atm, we can do that when the need arises, so that we can actually test the code. AFAIU that's exactly what Thierry was complaining about. There seems to be only a focus on solving the clocks issue since that is needed for sunxi but ignoring how the problem for other resources should be solved. That is simply not true, I'm fully aware that we may eventually need other resources, e.g. regulators. I just want to take this one step at a time, I really believe that once we have this figured out for one resource, it becomes a lot easier to also figure out for other resources. Great, I'm glad to hear that you are willing to add support for regulators (and other resources). The assumptions made by simplefb are quite fragile and only adding support for managing clocks is just a partial solution that will give a false sense of robustness since it could break later due to other resources. The key word here being resources. We need to figure out how to do resource management for simplefb, once we have that figured out for one resource, the others can follow the same design-pattern. As the long thread about the clocks support has shown, getting consensus on this with only one resource in play already is hard enough, so baby steps is the way to go. I'm certainly not against adding clock management if that will make simplefb more robust. I was just worried that other resources could be ignored. But I'm ok of doing baby steps if there is a long term plan. As I mentioned in another thread, I believe Doug's suggestion is the best approach. That is to have the simplefb node with all its resources in the DTS but with status = disabled. The bootloader should only fill the information about the framebuffer memory region (location and size, width, height, format, etc) and change the simplefb node status to okay. If a FDT does not have a simplefb node then the bootloader can create one (like is made for the /choosen node in most bootloaders). That will better document which resources are really used when someone reads the DTS and also avoid duplicating code in the bootloaders to fill all the information about resources but is just my humble opinion and I really don't want to bikesheed more on this. Best regards, Javier -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
On 22/10/14 19:45, Hans de Goede wrote: Since we seem to have broad agreement on how to move forward with this, I would like to ask you to please merge this patch-set for 3.19. I know 3.19 is still somewhat ar away, but I would like to submit the u-boot side of this to upstream ASAP, so can you please let me know if you plan to take this patch-set for 3.19 soon ? This series looks fine to me, except patch 3 is missing a description, and patch 4 makes the desc a continuation of the subject. Each patch should have a description (independent from subject). No need to resend, I can cook up something for those, or I can edit the descs if you provide the text. So if there are no strong objections, I'll queue this for 3.19. Tomi signature.asc Description: OpenPGP digital signature
