[U-Boot] [PATCH] video: add cfb console driver for sunxi

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 08/06/2014 01:40 PM, Luc Verhaegen wrote:
> On Tue, Aug 05, 2014 at 01:56:36PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 08/02/2014 06:14 PM, Luc Verhaegen wrote:
>>> This adds a fixed mode hdmi driver (lcd to be added in future) for the
>>> sunxi platform. Current config is such that 8MB is shaved off at the top
>>> of the RAM. Simplefb support is available for kernels that know how to
>>> use it.
>>
>> I've been trying to follow all the discussion in this thread, and here
>> is what I think we should do:
>>
>> 1) There has been some discussion about using this console-driver
>> in u-boot without generating the simplefb dt node. This means yet another
>> variation in how all the bits fit together, so I don't think we should do
>> this. Note I realize that the original patch did not have a specific
>> config option for this, but it was mentioned later in the thread.
>> TL;DR: Enabling the console driver will always generate the simplefb dt
>> node.
> 
> When we do not claim clocks, we luckily cleanly disable hw, in our case.
> 
>> 2) I think we can worry about what to do with the reserved memory\when not using simplefb
>> (or when switching from simplefb to kms) later. For now lets focus on the
>> issue with the clocks.
> 
> Yes, this was the plan all along.
> 
>> 3) To me the issue with clocks seems simple, we should modify the
>> devicetree binding for simplefb to support a clocks property, and modify
>> the simplefb kernel code to get + prep_and_enable any clocks specified
>> in the dt node.
> 
> For me, an important part of this discussion was seemingly flawed way in 
> which clocks are defined. I was of course not going to completely 
> overturn the thinking here, but i had expected that people would've at 
> least agreed that something was obviously awry, as there are several 
> obvious indicators there.

I think the way clocks are defined is fine, it works fine for all
the other parts of the SoC we've added support for so far. I guess
it may take some getting used too.

Anyways I don't think having an extended discussion about how clocks
are defined is useful, this is simply something which we are not
going to change, so better get used to it.

> 
>> This means parsing enough of the dt to find the clocks to be able to
>> specify phandles to them in the added node. I don't know how hard it will
>> be to do this in u-boot, but IMHO it is simply the right thing to do, so
>> this is how it should be done.
> 
> No, you do not need to add nodes. This was never the case. &ahb_gates 
> is never used like that.
> 
> It is either used as <&ahb_gates bit> from the dt, or "ahb_bitname" 
> from kernel code which directly references clocks, with the 
> ahb_bitnames listed as part of ahb_gates in the "clock-output-names" 
> property. This lack of symmetry is one very clear sign.

That is how the gates are modeled yes, but we don't want to insert
direct refences to the gates into the generated simple-framebuffer
devicetree node. Instead what should be done is add module clock
nodes to the devicetree (in the dts file, not on the fly in u-boot),
and then the uboot code should search for those (this is what I meant
with parse the dtb) and then insert phandles to these into the
generated simpe-framebuffer node.

Note we will need multiple module-clocks node, one for lcd0 ch0 one for lcd0
ch1, etc. See for example the mmc0_clk node, and the usage of it in the mmc0
node. I think we don't need a module clock node for the hdmi encoder,
as it seems the module clock register for it at address 1c20150 does not do
anything, instead it seems the hdmi encoder is hooked up
directly to pll 3 / 7 and has its own clock selection mechanism through
one of the hdmi encoder registers. At least this is the conclusion I
came to when working on dvi support, etc. in the sunxi-3.4 kernels.

Regards,

Hans