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