On Mon, Aug 25, 2014 at 10:53 AM, Thierry Reding
[off-list ref] wrote:

On Mon, Aug 25, 2014 at 04:23:59PM +0200, Hans de Goede wrote:

quoted

Hi,

On 08/25/2014 04:16 PM, 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 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.

quoted

As for the suggestion to simply never disable the plls / ahb gates by blocking
them from ever being disabled in the sunxi clock driver, that is not really
a solution either, as we want to be able to turn these things off to safe
power on screen blank once control has been turned over to the kms driver.

Then perhaps part of the hand-off procedure between simplefb and DRM/KMS
should involve marking PLLs or "gates" as properly managed.

And by your earlier argument also power domains, regulators, etc. So now we need
to add code to each of the clock core, power-domain core, regulator core, etc. to
have them now about this initially unmanaged state thing you're introducing, as
well as modify all involved clock / regulator / etc. drivers to mark certain
resources as unmanaged.

Hmm... that's true. But we already have a way to deal with exactly this
situation for regulators. There's a property called regulator-boot-on
which a bootloader should set whet it has enabled a given regulator. It
can of course also be set statically in a DTS if it's know upfront that
a bootloader will always enable it. Perhaps what we need is a similar
property for clocks so that the clock framework will not inadvertently
turn off a clock that's still being used.

There should probably be a generic 'boot-initialized;' property that
can be added to any DT device node.   Then uboot can add that property
to the device node for anything it has turned on.

You could even use it to add more info 'boot-initialized = <"9600 8 N 1">;'

That passes the info in an OS agnostic manner.

Thierry

-- 
Jon Smirl
jonsmirl at gmail.com