[U-Boot] [RFC PATCH 0/3] sunxi: video: Add support for HDMI output on H3

[Simon Glass]

Hi,

On 14 December 2016 at 01:37, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
> On 13-12-16 21:28, Simon Glass wrote:
>>
>> Hi,
>>
>> On 12 December 2016 at 19:36, Jernej Skrabec <jernej.skrabec at siol.net>
>> wrote:
>>>
>>> This patch series add support for HDMI output. Support for other,
>>> newer, SoCs, which also uses DE2 and same or similar HDMI controller
>>> and PHY can be easily added later (A83T/A64/H5/R40). Current driver
>>> can also be easily extended with TV out support, just like video
>>> driver for older Allwinner SoCs.
>>>
>>> While driver works, I would like to get few opinions first.
>>> - From what I understand, drivers which supports DT are preferred.
>>>   Would it be better to rewrite this driver to support device tree?
>>
>>
>> Yes I think so, and in fact it should use driver model also.
>>
>> The rockchip driver provides a reasonable example of how to split the
>> driver up as you suggest below. The VIDEO driver provides the
>> top-level video interface, DISPLAY drivers provide display output for
>> the video, and you have PANEL as well for receiving the display
>> output. VIDCONSOLE works automatically to display text.
>>
>> I actually took a bit of a look at this a few weeks ago so am happy to
>> help with review or discussions.
>
>
> I'm all in favor of moving to the driver-model, but I believe that
> we first need proper support for the DE2 and new HMDI encoder in
> the kernel, so that the dt bindings are clear.
>
> Once that is in place it would be good to look into converting the
> u-boot code to the driver-model. Since that likely is going to
> take a while I think it would be good to move ahead with this
> patch set as is (with review comments addressed) and later replace
> it with a driver-model based implementation. But that is no longer
> my call :)

We can disconnect DT from driver model without too much trouble. But I
do worry about adding more code to what is there. I think it would be
better to tease apart things into separate files for each block. At
least the display driver could converted to driver model
(UCLASS_VIDEO) since FWICT it has a compatible string in the kernel.
Even if there is nothing else, that is enough to cause the driver to
be probed.

Then it is easier to build on. If we go further down the non-DM path
it will become infeasible to re-architect later.

So my suggestion is:

- Create a UCLASS_VIDEO driver and put some of the code in that
- Create UCLASS_DISPLAY drivers for the HDMI, LCD, etc. and move that
code into a separate file for each
- Use manual probing or whatever to make it work for now. In other
words, instead of doing things entirely with the DT as rockchip and
tegra do, find the display devices manually / hard coded for now.

Then when DT is sorted out it will be relatively easy to adjust things
 without wholesale rewrites.

So please let's not wait for DT bindings. It is just going to create
too much tech debt for any one person to fix.

Regards,
Simon