On Thu, Aug 28, 2014 at 12:34:58PM -0400, jonsmirl at gmail.com wrote:

On Thu, Aug 28, 2014 at 12:25 PM, Michal Suchanek [off-list ref] wrote:

quoted

On 28 August 2014 16:33, jonsmirl at gmail.com [off-list ref] wrote:

quoted

On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl at gmail.com [off-list ref] wrote:

quoted

quoted

2) We don't want to hardcode these clocks into the kernel (sunxi) clk
driver, instead the bootloader should tell the kernel about these clocks.

So the only point of discussion left seems to be how to do 2...

Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
whip together a device specific driver that claims the proper
resources? And just implement the minimal about of fbdev possible?
fbdev already is a driver library.

Like... drivers/video/fbdev/offb.c?

I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
and use it as a template for making device specific versions of it.

I don't see why there is so much resistance to just making device
specific fb drivers.  Whenever the KMS driver gets written just
disable the device specific fb driver in the build.

Except that is not the goal here. The simplefb or whatever replacement
is supposed to stay as a  generic driver compiled into kernel whereas

There is no generic solution to this problem as this entire thread has
illustrated. The clocks/regulators needed by each SOC vary.

There is a generic solution. Genericity only works if you define a well
defined set of assumptions. In this case the assumptions are that some
firmware sets up display hardware to scan out from a memory region and
communicates the location, layout and format of that memory region so
that a generic driver can write into that framebuffer.

The generic solution here works because we've eliminated the platform
specificities and let firmware take care of it.

So there are two solutions..
1) modify simplefb to have some kind of heuristic that tries to guess
what needs to be protected. A heuristic that is probably going to fail
on every new SOC.

2) Spend a day implementing a device specific fbdev driver that does
the correct thing all of the time. These drivers would sit in initrd
and load before the clock/regulator clean up shuts everything off. Use
the existing simplefb code as a template for doing this.

There's a third possibility: find a way to prevent the clock framework
(and any other resource framework for that matter) from forcefully
disabling things that they shouldn't.

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/20140829/e055b012/attachment.sig>