On Mon, Aug 04, 2014 at 10:39:13AM +0200, Hans de Goede wrote: > Hi Luc, > > First of all many thanks for your work on this. > > ATM I don't have time to do a full review, but I don't expect there > to be too many suprises when I do find the time. > > Really my only concern is the handover of the reserved memory, etc. to > the kernel. We need to get a plan in place for that *before* this can > be merged. Note I don't want to raise any artificial barriers here, > I would love to see this merged ASAP. But I don't want to paint us > in a corner where u-boot having hdmi console support makes it harder > to get kms support in the kernel going. I think we can both agree on that. > > So I really want to see some plan how this will work in place before merging. > Note just a plan, I don't expect kernel patches ready to be merged for this, > just a good idea / sketch of how all the bits will fit together.
Memory is not the biggest worry. Some kernel code needs to claim clocks if the mode is to cleanly survive the start of the kernel. If not, there is no coming back until a proper display driver runs. If the simplefb driver claims these clocks, then the simplefb driver also must release these clocks, and this driver should then never be started again, so it should set the simplefb dt node status to "disabled". But that's not the full extent of this story. If we have a kms driver, then we need to claim these clocks, and set a proper mode on the hw. So the simplefb driver claiming these resources must've properly unclaimed them by then, _and_ have set the dt node to disabled. This kills your flicker-free right here unless there is a clean way for the kms driver to reclaim the clocks before the simplefb driver unclaims them. But... What do we do when u-boot sets up cfb, without setting up a simplefb node in the dt. Or what do we do when a simplefb node is set up, but no simplefb code is included in the kernel? Well, we then either need to claim the clocks, and make sure that nothing else touches the memory, or we need to cleanly disable the display engine. But which do we choose, do we keep the u-boot output forever, or do we sync off when the kernel starts? Suddenly, simplefb doesn't look as simple anymore. It's turned into quite the mess. Life is easy when you are called rpi, and you sweep everything under the videocore rug, and do everything behind the lesser cores back. But if you want to solve this properly, then you end up smearing bits of simplefb driver code all over the kernel tree. As for memory, that's closely tied into the clock code, as whatever code claims or disables the clocks for the display engine, that's also where the dt node gets set to disabled, and thus also where the memory either is added to some cma area directly, released from (upcoming) reserved memory, or forgotten. Simplefb at least gives us a nice handle on the location and size of the memory, so we can always find a workable solution. So i don't think the memory issue is as important. We already give the kernel a nice handle on that. How the kernel wishes to handle it in detail is then pretty much up to the kernel, and i expect the kernels behaviour to change when kms comes out and i have to think about dealing with simplefb. Clocks are quite a bit more crucial in this context. How the memory is handled needs to follow how the clocks are handled. > In one of the threads about this there was some discussion about doing a > "flicker free" handover. I agree with you that given that we will be fixed > to 1024x768 in u-boot this won't be realistic. But in the light of that > it would be nice if we could make it so that if none of the stdout and stderr > variables point to vga we don't init the hdmi at all, this will avoid > what ever is attached to first have to sync at 1024x768 and then at its > native resolution when the kernel takes over, and this will also allow > for an easy way to not steal the 8MB of memory for people who care about > that (think headless server which is low on memory) That's not how u-boot or the console code works. First off, this stdout/stderr variable setting, that's all handled after the driver has been loaded and an (extra) console device is created. The cfb console driver is created because of a build time config, but it is allowed to fail (in our case, because HPD says nothing is attached). Iirc, without iomux, the last created console driver is the one that gets stdout, stderr and stdin, so you lose the UART console. With iomux, you always need to load env for anything but the uart console to work. This means that you can have both cfb and uart working side by side, but you do not get anything on cfb unless the env is set as such. For a future spin of this patch, the logic around enabling this code will be swapped around. People will have to manually add VIDEO to their board config. There's just to many hairy cornercases and tough to answer "what if"s here, when you actually start thinking things through, to keep this as the default. Luc Verhaegen. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
