H2+/H3/H5/A64 Disp2 U-Boot video driver

[zador.blood.stained]

can you check h3_hdmi_tv_v1 branch?

I'll check this later. Will you enable composite video on boards where it is wired to 3.5mm jack in the configs or you won't touch anything else and focus onconverting the driver to DM?

 

I will think a bit how to add A64 support in (ifdef hell), but I guess that is really not that important, because code in this form won't be mainlined.

I guess you can make a hidden Kconfig option (i.e. in board/sunxi/Kconfig) for DE2 that will be selected by appropriate MACH_SUN* and use that symbol (i.e. CONFIG_VIDEO_SUNXI2) where you need to #ifdef clocks or whatever else common for DE2. And I think you still can reuse most of the code for the DM driver.

[jernej]

I'll check this later. Will you enable composite video on boards where it is wired to 3.5mm jack in the configs or you won't touch anything else and focus onconverting the driver to DM?

 

I was thinking about that. Do you think it makes sense? The biggest issue for now is that composite is missing plug in detection code and can't be just left enabled, because it will eat electricity for no good reason for most use cases. I will definetly try to add plug in detection in DM driver.

 

 

I guess you can make a hidden Kconfig option (i.e. in board/sunxi/Kconfig) for DE2 that will be selected by appropriate MACH_SUN* and use that symbol (i.e. CONFIG_VIDEO_SUNXI2) where you need to #ifdef clocks or whatever else common for DE2. And I think you still can reuse most of the code for the DM driver.

 

I will do that for sure in the next version of the driver, but I was referring more to the TCON/DE2 details. For example, A64/A83T have HDMI on TCON1 but H3/H5 on TCON0. TCON1 on H3/H5 doesn't have any gates or reset, but on A64 it has. I guess you know what I mean.

 

As soon as I get finished with squashing patches I will start writing DM driver.

[zador.blood.stained]

I was thinking about that. Do you think it makes sense? The biggest issue for now is that composite is missing plug in detection code and can't be just left enabled, because it will eat electricity for no good reason for most use cases. I will definetly try to add plug in detection in DM driver.

Is the plug detection even possible in this hardware?

It makes sense to enable composite output at compile time where it is accessible (i.e. all H3 oranges except for One, Lite and Zero), and after that it can be controlled at least by u-boot environment. Enabling it on OPi Zero where it is accessible only on pin header is more questionable for the maintainers.

 

I will do that for sure in the next version of the driver, but I was referring more to the TCON/DE2 details. For example, A64/A83T have HDMI on TCON1 but H3/H5 on TCON0. TCON1 on H3/H5 doesn't have any gates or reset, but on A64 it has. I guess you know what I mean.

Well, IMO pipeline details can easily go to the DT or even to Kconfig as a hidden string option, and then be selected depending on MACH_* like it's done with MMC0 CD pin or DRAM frequency

 

 

config DRAM_CLK
	int "sunxi dram clock speed"
	default 792 if MACH_SUN9I
	default 312 if MACH_SUN6I || MACH_SUN8I
	default 360 if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
	---help---
	Set the dram clock speed, valid range 240 - 480 (prior to sun9i),
	must be a multiple of 24. For the sun9i (A80), the tested values
	(for DDR3-1600) are 312 to 792. 

 

 

[jernej]

Is the plug detection even possible in this hardware?

It makes sense to enable composite output at compile time where it is accessible (i.e. all H3 oranges except for One, Lite and Zero), and after that it can be controlled at least by u-boot environment. Enabling it on OPi Zero where it is accessible only on pin header is more questionable for the maintainers.

 

It should be according to BSP code. Ok, I will enable it on all boards where it is easy accessible, so not on OPi0. You will adapt where needed. Does Linux disable all unused clocks, at least on mainline?

 

 

Well, IMO pipeline details can easily go to the DT or even to Kconfig as a hidden string option, and then be selected depending on MACH_* like it's done with MMC0 CD pin or DRAM frequency

 

This is definetly something to be defined in DT. But for now we don't have this in DT, so another option must be used. I will use platform data in DM driver, which should be similar enough to DT, so it should be easier to switch over.

[zador.blood.stained]

Does Linux disable all unused clocks, at least on mainline?

I think so, unless the kernel does not know about the clock or it is defined as critical in the clock driver (which obviously does not apply to display clocks).

 

While we are on topic, what do you want me to test in h3_hdmi_tv_v1 branch? Is testing 1080p HDMI and default TV output enough?

[jernej]

While we are on topic, what do you want me to test in h3_hdmi_tv_v1 branch? Is testing 1080p HDMI and default TV output enough?

 

Yes that would be enough. Please just wait half an hour till I rebase the code and add missing CONFIG_COMPOSITE=y in defconfig. But it will be H3 only. I will try to add H5 and A64 code later this evening.

[jernej]

H3/H2+ version should work now. One board test should be ok, but please check if I missed any defconfig. I didn't enable composite for OPiZero.

[jernej]

I finished with hammering old code: https://github.com/jernejsk/u-boot/commits/de2_wip

 

Now it should support also A64. Please keep in mind that this is based on latest u-boot master branch. Because of that, I added AXP patch for A64 which might conflict with ATF code (not sure anymore). Above branch was tested on H3 and A64. I thought that H5 support was already mainlined, so I put also H5 defines, but obviously it is not. Feel free to try it on some apritzel branch. I think it should work without any code changes.

[zador.blood.stained]

Test results of de2_wip branch:

 

H3 / Orange Pi Plus 2e

• HDMI output - works
• Composite output - works

H5 / Orange Pi PC2

• HDMI output - works
• Composite output - no signal, "Setting up a 720x576i composite-pal console (overscan 32x20)" is present in serial output, so the driver at least tries to enable it

A64 / Pine64+

• HDMI output - works, will try adding simplefb nodes to kernel DT later

 

Edit: Tested simplefb on Pine64 dev - works for me. Note: On newer boards HDMI 5V power is controlled by "DC5V/BAT POWER" jumper.

[jernej]

Please upload .config for H5 build with composite enabled.

[zador.blood.stained]

Please upload .config for H5 build with composite enabled.

orangepipc2-full.txt

[jernej]

TV base address is slightly moved. Please try with this patch applied: http://sprunge.us/TBPU

[zador.blood.stained]

TV base address is slightly moved. Please try with this patch applied: http://sprunge.us/TBPU

Still no signal.

Edit: oscilloscope detects some activity on the TV out, though it doesn't look like a CVBS (?)

Edit 2: oscilloscope can recognize video signal from OPi+2E as a "video signal", but doesn't recognize the signal from PC2. I'm not sure if this can be a black screen due to misconfigured pipeline or not.

[jernej]

Which is your base branch?

[zador.blood.stained]

Which is your base branch?

https://github.com/apritzel/u-boot/tree/h5

[jernej]

Ok, found the issue. Apply this patch a top of previous: http://sprunge.us/KETE

 

It seems that H3 TV works without calibration, but H5 doesn't. Fortunatelly, it work with fixed value for calibration.

[zador.blood.stained]

Works now, thanks.

[zador.blood.stained]

@jernej

Someone got DWC HDMI documentation: https://irclog.whitequark.org/linux-sunxi/2017-03-25#19109073;

Not sure if it is useful or can be used at all due to possible copyright/licensing issues.

[jernej]

Yeah, I know. Well, also Allwinner manuals are sometimes "leaked" and someone also uploaded Synopsys UART specs which are also regarded "confidential". I don't know when it is safe to use, but once it is easily publicly available, it can't be regarded as secret anymore. Anyway, imx6 manual has more or less everything covered already, except maybe I2S audio part, but that is already implemented in the kernel driver. So I would say not much new info, if at all.

[jernej]

Driver is merged in U-Boot sunxi master. However, it uses different framework (DM video) than my original attempt, so there are some differences, which must be taken into account:

 

1. It doesn't support simplefb. It does support efifb, but that doesn't work properly on 32 bit SoCs, since nobody invested time to go trough all places where 32/64 bit differences must be taken into account.

2. It also doesn't support TV out output, but patch for that could be taken from my working branch (only plug in detection is missing - always on).

3. DVI monitors doesn't work yet, since there is no differentiation between DVI and HDMI yet. Fix for that is already sent, but I'm not sure if it will be taken in before stable is released.

4. Some compilers might produce U-Boot with non working video driver, since one variable in edid parsing code is not initialized and might contain garbage. Fix for that is also sent and I'm also not sure if it will be taken in before stable is released.

5. Resolution can't be overriden and there is no overscan handling.

 

So 1 and 5 might be an issue for Armbian mainline images. Unfortunatelly, also patch with old driver can't be applied as-is and has to be adopted. On the bright side, I and Icenowy managed to make working DE2, TV out and HDMI DRM driver based on linux-next (Linux 4.12-rc1 material). HDMI driver supports arbitrary resolutions, but not yet audio. However, that shouldn't be too hard to do now. @zador.blood.stained, what do you think is the way to go?

[zador.blood.stained]

Well, if it's in sunxi master now, it will be merged to mainline u-boot 2017.07, right? I believe you missed 2017.05 merge window (or rather it wasn't reviewed and ACKed in time though you sent the patches 1 week before the merge window closed).

I hope by that time you will have all necessary fixes or even your WIP DRM driver in the branch that we wil be using for dev images.

 

3 minutes ago, jernej said:

@zador.blood.stained, what do you think is the way to go?

For you - probably focus on mainlining efforts, and we will try to sort Armbian specific problems when we face them. U-boot 2017.05 should still work with your old simplefb patches, so there shouldn't be any problems with losing display output anytime soon.

[jernej]

9 minutes ago, zador.blood.stained said:

Well, if it's in sunxi master now, it will be merged to mainline u-boot 2017.07, right?

I'm really not sure, since U-Boot merge process is not as strict as Linux one.

 

9 minutes ago, zador.blood.stained said:

I believe you missed 2017.05 merge window (or rather it wasn't reviewed and ACKed in time though you sent the patches 1 week before the merge window closed).

 

They were acked a day or two before merge window closed. I know there were some complaints in the past that new, not well tested, drivers were merged in rc2 or rc3, but then someone also comment that U-Boot is getting better in adhering to guidelines.

[jernej]

At least here is the (temporary) solution for simplefb:

https://github.com/Icenowy/u-boot/commit/315edb971fa05d80fd0f17190406125f7455dc96

[zador.blood.stained]

2017.05-rc3 is out, DE2 related clocks changes were merged, but the DE2 driver itself wasn't.

[jernej]

Yes, I know. This was because DE2 itself needs DM_I2C to be enabled (not really, just to prevent warnings), so I had to do some intermediate patches which was ready few days after clocks were merged. However, pull to master for rc3 was done in between those few days when I was preparing DM_I2C patches... Now I'm really not sure if DE2 will be merged or not. One week chance

[zador.blood.stained]

On 01.05.2017 at 11:48 AM, jernej said:

At least here is the (temporary) solution for simplefb:

https://github.com/Icenowy/u-boot/commit/315edb971fa05d80fd0f17190406125f7455dc96

Hm. Looks like this patch requires different DT setup?

Cannot setup simplefb: node not found

 

[jernej]

2 minutes ago, zador.blood.stained said:

Hm. Looks like this patch requires different DT setup?

Seems so. Compare this and this. Pick a place to fix it.

 

Please note that TV out is not included in this patch. I will add it when I will have time.

 

P.S.: It looks like this driver will be in next U-Boot release. Unfortunately, I can't say the same for fixes I sent later (they go in through different repo).

[zador.blood.stained]

Just now, jernej said:

Please note that TV out is not included in this patch. I will add it when I will have time.

I remember. I think for now TV out support is not mandatory

 

1 minute ago, jernej said:

P.S.: It looks like this driver will be in next U-Boot release. Unfortunately, I can't say the same for fixes I sent later (they go in through different repo).

Well, if they are clearly marked as "fixes" I hope they will be included even if they come after the rc1/merge window closing.

[jernej]

Nope, didn't make it. U-Boot 2017.05 was tagged few hours ago and sunxi merge is still pending. Well, at least fixes will be merged till next release for sure.

[zador.blood.stained]

I meant I hope they will be merged to 2017.07. I already switched Armbian to 2017.05 and I used u-boot-sunxi fork to extract your initial patches, so I saw that it doesn't have extra fixes that are present in Icenowy's branch.