On Mon, Aug 25, 2014 at 04:58:54PM +0200, Maxime Ripard wrote:

On Mon, Aug 25, 2014 at 04:16:29PM +0200, Thierry Reding wrote:

quoted

On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:

quoted

On 08/25/2014 03:39 PM, Thierry Reding wrote:

quoted

On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:

quoted

On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:

quoted

On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:

quoted

On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:

[...]

quoted

quoted

If not, perhaps the clock driver should force the clock to be
enabled (perhaps only if the DRM/KMS driver isn't enabled?).

I'm sorry, but I'm not going to take any code that will do that in our
clock driver.

I'm not going to have a huge list of ifdef depending on configuration
options to know which clock to enable, especially when clk_get should
have the consumer device as an argument.

Are you saying is that you want to solve a platform-specific problem by
pushing code into simple, generic drivers so that your platform code can
stay "clean"?

Are you saying that this driver would become "dirty" with such a patch?

Yes. Others have said the same and even provided alternative solutions
on how to solve what's seemingly a platform-specific problem in a
platform-specific way.

This is not platform specific, any platform with a complete clock driver
will suffer from the same problem (the clock driver disabling unclaimed
ahb gates, and thus killing the video output) if it wants to use simplefb
for early console support.

It is platform specific in that your platform may require certain clocks
to remain on.

The platform doesn't. simplefb does. simplefb is the obvious consumer
for these clocks, and given the current API and abstraction we have,
it should be the one claiming the clocks too.

No. simplefb just wants to write to some memory that hardware has been
set up to scan out. The platform requires that the clocks be on. Other
platforms may not even allow turning off the clocks.

quoted

The next platform may require power domains to remain on during boot
and yet another one may rely on regulators to stay on during
boot. By your argument simplefb will need to be taught to handle
pretty much every type of resource that the kernel has.

And I wouldn't find anything wrong with that. We're already doing so
for any generic driver in the kernel (AHCI, EHCI comes to my mind
first, there's probably a lot of others). Why wouldn't we do as such
for this one?

Yes, and we've had similar discussions in those subsystems too.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140825/32926166/attachment.sig>