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.
> 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.
The fact that only the kernel knows how to map the "clock-output-names"
list, which is only defined in the dts, to bits only defined in the clk
driver code in the kernel, that's another very clear sign.
> If others agree that specifying the clocks in the simplefb dt node is
> the right way to ensure that the clocks don't get enabled I'm willing
> at taking a shot on coding this.
I have been on it since last friday, when i started seeing the issues
here, but haven't done much code til now, and am only uncovering many
more inconsistencies.
For instance, in the linux kernel,
Documentation/devicetree/bindings/clock/clock-bindings.txt only adds to
the confusion.
Now trying to find a working solution from the kernel side, as i already
manually inserted 6 u32s: {phandle, bit, phandle, bit, phandle, bit}.
Wait and see how that pans out, but i know that this will not provide a
proper or lasting solution, as the pairs of cells needed now will at one
point need to be mixed with directly referenced clocks (pll3/pll7, which
are currently not defined in dts yet).
Luc Verhaegen.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
