Re: [PATCH 3/4] simplefb: Change simplefb_init from module_init to fs_initcall

Started by Thierry Reding on Nov 18, 2014 · 2 messages from 2 authors · Last reply Nov 18, 2014

open the first message on its own page

Message details and related content
On Tue, Nov 18, 2014 at 01:44:44PM +0100, Hans de Goede wrote:
Hi,

On 11/18/2014 12:46 PM, Hans de Goede wrote:
quoted
Hi,

On 11/18/2014 12:21 PM, Thierry Reding wrote:
quoted
On Tue, Nov 18, 2014 at 12:01:08PM +0100, Hans de Goede wrote:
quoted
Hi,

On 11/18/2014 11:19 AM, Thierry Reding wrote:
quoted
On Thu, Nov 13, 2014 at 09:58:41AM +0100, Geert Uytterhoeven wrote:
quoted
Hi Maxime,

On Thu, Nov 13, 2014 at 9:52 AM, Maxime Ripard
[off-list ref] wrote:
quoted
quoted
-module_init(simplefb_init);
+/*
+ * While this can be a module, if builtin it's most likely the console
+ * So let's leave module_exit but move module_init to an earlier place
+ */
Not really related to this patch itself, but do we want to support
simplefb as a module? It seems like it's going to be most of the time
broken.
If it depends on clocks, it won't work as a module, as CCF will have disabled
all unused clocks at that point.
If it does depend on anything beyond clocks it won't work at all. Clocks
are special because they get set up very early at boot time. If it turns
out that a simplefb ever needs a regulator to remain on, and that's even
quite likely to happen eventually, it's going to fail miserably, because
those regulators will typically be provided by a PMIC on an I2C bus. The
regulator won't be registered until very late into the boot process and
a regulator_get() call will almost certainly cause the simplefb driver
to defer probing.
Right, this has been discussed already and the plan is to have simplefb
continue its probe function and return success from it if it encounters
any -eprobe_defer errors, while tracking which resources it misses.

73 more quoted lines

That sounds like a reasonable solution to me.
Then when we move simplefb to a 2 fase probe, we can simply register the
framebuffer at the first probe call, and claim any resources we get, but
return -eprobe_defer if some resources returned that themselves.

Then when simplefb_probe gets re-called, it can first check if it did not
already register a fb, and if it did, it can use that and see which
resources are missing, and only try to claim those. If some resources
still return probe_defer, return eprobe_defer again, otherwise success.
I'm not sure you can check that the fb was already registered. When the
driver probe fails the driver core will pretty much remove any trace of
the driver, so checking for an already-reagistered framebuffer isn't
going to be easy.

But if you can manage to make that work it should give us a pretty good
solution that should be easy to make use of by other drivers as well.

Thierry
Message details and related content
On Tue, Nov 18, 2014 at 04:16:04PM +0100, Thierry Reding wrote:
On Tue, Nov 18, 2014 at 01:44:44PM +0100, Hans de Goede wrote:
quoted
Hi,

On 11/18/2014 12:46 PM, Hans de Goede wrote:
quoted
Hi,

On 11/18/2014 12:21 PM, Thierry Reding wrote:
quoted
On Tue, Nov 18, 2014 at 12:01:08PM +0100, Hans de Goede wrote:
quoted
Hi,

On 11/18/2014 11:19 AM, Thierry Reding wrote:
quoted
On Thu, Nov 13, 2014 at 09:58:41AM +0100, Geert Uytterhoeven wrote:
quoted
Hi Maxime,

On Thu, Nov 13, 2014 at 9:52 AM, Maxime Ripard
[off-list ref] wrote:
quoted
quoted
-module_init(simplefb_init);
+/*
+ * While this can be a module, if builtin it's most likely the console
+ * So let's leave module_exit but move module_init to an earlier place
+ */
Not really related to this patch itself, but do we want to support
simplefb as a module? It seems like it's going to be most of the time
broken.
If it depends on clocks, it won't work as a module, as CCF will have disabled
all unused clocks at that point.
If it does depend on anything beyond clocks it won't work at all. Clocks
are special because they get set up very early at boot time. If it turns
out that a simplefb ever needs a regulator to remain on, and that's even
quite likely to happen eventually, it's going to fail miserably, because
those regulators will typically be provided by a PMIC on an I2C bus. The
regulator won't be registered until very late into the boot process and
a regulator_get() call will almost certainly cause the simplefb driver
to defer probing.
Right, this has been discussed already and the plan is to have simplefb
continue its probe function and return success from it if it encounters

93 more quoted lines

What about handling priorities in the suggested cleanup mechanism, and
just add the second phase as the highest priority cleanup callback?

That way, we would be guaranteed to be run just before any cleanup
function.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help