Jump to content

H3/H5/A64 DRM display driver


jernej

Recommended Posts

@jernej As long as WIP images boot up to a serial console command prompt they are working good enough since it gives us a working base to test things.

Icenowy's branch has H5 related patches too - Mali device node, DE2 HDMI enabled on OPi PC2, some DE related clk-ng fixes from you, etc. In general Icenowy's kernel should boot on H5 and A64, but things may be missing or not working properly.

A non-optional HDMI regulator can be easily turned into optional or it can be supplied by a dummy regulator, so I don't think that it will cause many problems.

Link to comment
Share on other sites

25 minutes ago, zador.blood.stained said:

Does your patch solve a kernel warning in ccu_something_wait_for_lock during boot (with a stack trace pointing to DE2 code)

Yes, it does.

 

35 minutes ago, zador.blood.stained said:

A non-optional HDMI regulator can be easily turned into optional or it can be supplied by a dummy regulator, so I don't think that it will cause many problems.

True. Now that I managed to solve most of the driver problems + added HDMI audio & cec, I was thinking to add/update patches to Armbian. But I was thinking to start with H3, which means updating to 4.13 first. But enough of offtopic...

Link to comment
Share on other sites

4 minutes ago, jernej said:

Now that I managed to solve most of the driver problems + added HDMI audio & cec, I was thinking to add/update patches to Armbian.

So what is left regarding actual driver problems?

 

5 minutes ago, jernej said:

But I was thinking to start with H3, which means updating to 4.13 first.

If you need help with testing your driver then I can quickly switch the stable branch to 4.13 and add a "next" (stable) target to a couple of well supported boards like OPi One and OPi PC.

Link to comment
Share on other sites

1 minute ago, zador.blood.stained said:

So what is left regarding actual driver problems?

Uh, I typed too quickly. There is none known.

 

4 minutes ago, zador.blood.stained said:

If you need help with testing your driver then I can quickly switch the stable branch to 4.13 and add a "next" (stable) target to a couple of well supported boards like OPi One and OPi PC.

That would be nice, although I don't have none of those two. OPi Plus 2E?

Link to comment
Share on other sites

19 minutes ago, zador.blood.stained said:

Yes, but I have missed one patch which may or may not be important. It will have to wait till tomorrow.

 

22 minutes ago, zador.blood.stained said:

Will you keep "ARM: sun8i: h3: Enable HDMI output on xxx board" patches separate for each board?

For now, yes. I guess this doesn't really matter since we could squash all HDMI patches to one?

 

24 minutes ago, zador.blood.stained said:

Should this driver also work on H5 (i.e. OPi PC2)?

Driver should work (not tested), but DT must be updated.

 

Once everything works, I was thinking about adding Mali driver. Fortunately, we could borrow properly licensed X11 driver from CHIP.

Link to comment
Share on other sites

Did a quick test on OPi+2E. Video works, HDMI sound works, so that's a great work, thanks! Will try to do more tests (like resolution switching) later.

Small note - framebuffer switching from u-boot to kernel (at least without simplefb nodes in the DT) displays a distorted picture for several seconds. Is this something that will need fixes/workarounds for mainlining?

 

Also you added DT nodes to sun8i-h3.dtsi - so how big will be the differences for H5? Currently (for other hardware) some common properties are defined in sunxi-h3-h5.dtsi and then specific properties are added in sun8i-h3.dtsi and sun50i-h5.dtsi (including clocks, interrupts, "compatible" strings, etc.).

Link to comment
Share on other sites

This patch is realy needed for HDMI audio (without it, it works on my TV but not on monitor).

 

5 hours ago, zador.blood.stained said:

Small note - framebuffer switching from u-boot to kernel (at least without simplefb nodes in the DT) displays a distorted picture for several seconds. Is this something that will need fixes/workarounds for mainlining?

This is not a bug from either side. It comes from a fact that U-Boot puts framebuffer in such place that Linux puts some data into it when loading. Linux later reinitialize DE2 and puts framebuffer on different location. I agree that it may be annoying, but it doesn't hurt.

 

5 hours ago, zador.blood.stained said:

Also you added DT nodes to sun8i-h3.dtsi - so how big will be the differences for H5?

Only difference is in display_clocks node, which has to have "allwinner,sun50i-h5-de2-clk" as compatible. Everything else should work with the same nodes (not tested). I guess we can move most of the nodes to sunxi-h3-ht.dtsi.

 

 

Link to comment
Share on other sites

4 minutes ago, jernej said:

This is not a bug from either side. It comes from a fact that U-Boot puts framebuffer in such place that Linux puts some data into it when loading. Linux later reinitialize DE2 and puts framebuffer on different location.

And AFAIK there are no plans to add simplefb support using something like this?

 

12 minutes ago, jernej said:

This patch is realy needed for HDMI audio (without it, it works on my TV but not on monitor).

Thanks, I'll replace the previous patch with this one. Sound worked for me with HDMI to VGA adapter.

Link to comment
Share on other sites

1 minute ago, zador.blood.stained said:

And AFAIK there are no plans to add simplefb support using something like this?

Well, someone has to do it. I guess there is a lack of interest and/or time for such functionality for now. Would you care to do it? :)

 

3 minutes ago, zador.blood.stained said:

Thanks, I'll replace the previous patch with this one. Sound worked for me with HDMI to VGA adapter.

Replace? This needs to be added a top of previous patches. Please see my h3_hdmi_audio_v1 branch.

Link to comment
Share on other sites

22 minutes ago, jernej said:

Replace? This needs to be added a top of previous patches. Please see my h3_hdmi_audio_v1 branch.

Sorry, I saw "committed 3 days ago" and thought that you force-pushed a similar patch that was present before.

 

24 minutes ago, jernej said:

Well, someone has to do it. I guess there is a lack of interest and/or time for such functionality for now.

Well, last time I heard that simplefb is deprecated and EFI framebuffer is broken on armhf so I'm not sure that it's something that can be accepted upstream.

Link to comment
Share on other sites

Just now, Da Alchemist said:

it is limited to 2 channels.

Yes, because nobody implemented support for more channels. Rockchip has some support for them in BSP kernel, I don't know why they didn't port it to mainline. When HDMI side is covered, then I2S driver also needs improvement to support more channels... So a lot of work. Do you want to help?

Link to comment
Share on other sites

10 minutes ago, jernej said:

Yes, because nobody implemented support for more channels. Rockchip has some support for them in BSP kernel, I don't know why they didn't port it to mainline. When HDMI side is covered, then I2S driver also needs improvement to support more channels...

Hm, in dw-hdmi-i2s-audio.c:

pdata.max_i2s_channels	= 6;

or are these a different kind of channels?

 

I2S driver has this:

	.playback = {
		.stream_name = "Playback",
		.channels_min = 2,
		.channels_max = 2,
		.rates = SNDRV_PCM_RATE_8000_192000,
		.formats = SNDRV_PCM_FMTBIT_S16_LE,
	},

 

7 minutes ago, jernej said:

Can anybody select different resolution?

Building a desktop image right now...

 

7 minutes ago, jernej said:

@zador.blood.stained simplefb is completely off, right?

There are no simplefb nodes in H3 DT. Other than that it is enabled in the kernel because it's used for A10/A20.

Link to comment
Share on other sites

@jernej

I shut down the board (OPI+2E) without unpowering it and it still displays the last image (or rather console prompt). Should this be happening? Are there any ways to shut down the HDMI PHY or at least make the monitor think that there is no signal without unpowering it?

 

Also I have issues switching to 1080p due to CMA memory allocation issue, so what CMA configuration should we use to support 1080p or even 4k resolutions?

Link to comment
Share on other sites

2 hours ago, zador.blood.stained said:

Hm, in dw-hdmi-i2s-audio.c:


pdata.max_i2s_channels	= 6;

or are these a different kind of channels?

You are right, HDMI driver should then support 6 channels, although, at least sunxi version of controller, should support 8 channels. So, what is missing on HDMI side is 8 channel and passtrough support. I2S side needs at least code for enabling second, third and fourth I2S line (1 I2S line = 2 channels) and a channel map. I can write some hacks, but I really don't like remote debugging (when someone else have to test if it works).

 

45 minutes ago, zador.blood.stained said:

I shut down the board (OPI+2E) without unpowering it and it still displays the last image (or rather console prompt). Should this be happening? Are there any ways to shut down the HDMI PHY or at least make the monitor think that there is no signal without unpowering it?

I really don't know. I implemented HDMI PHY shutdown and it is DW HDMI bridge duty to call this function. It is true, that clocks don't get disabled on driver shutdown, since there are some issues with passing pointer to the driver private structure to driver unload function. I guess this area definetly has some room for improvement.

 

52 minutes ago, zador.blood.stained said:

Also I have issues switching to 1080p due to CMA memory allocation issue, so what CMA configuration should we use to support 1080p or even 4k resolutions?

Well, just enable CMA and give it some memory? I configured CMA to 128 MiB and it works well, although 64 MiB should work as well. BTW, current configuration works for me on 1080p.

Link to comment
Share on other sites

13 minutes ago, jernej said:

Well, just enable CMA and give it some memory?

It's enabled with 16M, so I guess we should give it a bit more. Hopefully 128M will be enough.

 

BTW, should we care about the default CONFIG_DRM_FBDEV_OVERALLOC=100? Will double buffering be useful for anything else apart from Mali?

 

Edit: since it can be changed with a kernel command line parameter I guess we can leave the default as is.

Link to comment
Share on other sites

2 hours ago, zador.blood.stained said:

ound an "issue" - fbturbo package is installed to these images and it contains X11 configuration for the framebuffer - /etc/X11/xorg.conf.d/50-fbturbo.conf

Deleting this file as a workaround switches to the DRM driver and allows changing the resolution.

Are you sure deleting this file is ok? On my board, it causes X11 not to start...

 

11 minutes ago, zador.blood.stained said:

It's enabled with 16M, so I guess we should give it a bit more. Hopefully 128M will be enough.

For single buffering you can calculate this way (4K): 3B * 3840 * 2160 = cca. 24 MiB I think it also depends how much CMA memory other subsystems allocates. 128 MiB should be more than enough.

 

15 minutes ago, zador.blood.stained said:

BTW, should we care about the default CONFIG_DRM_FBDEV_OVERALLOC=100? Will double buffering be useful for anything else apart from Mali?

AFAIK, this was introduced for Mali and it is useful only for fbdev version, although I might be wrong about that... Just leave it at 100?

Link to comment
Share on other sites

44 minutes ago, jernej said:

Are you sure deleting this file is ok? On my board, it causes X11 not to start...

With this file it should work with a framebuffer, so resolution change in the control panel will be unavailable. Without this file it should fall back to autodetect for the video output device, and at least for me it is working.

Link to comment
Share on other sites

I updated sources, rebuild image and flash it again and now it works. Does resolution swithching works for you? More importantly, does sound work on (every) new resolution?

 

Now I can play with mali driver, I guess. Although clock disabling issue also needs to be resolved to lower "shutdown current".

Link to comment
Share on other sites

Just now, zador.blood.stained said:

For the first boot - because you are still logged in as root when nodm starts the display manager as a different user. In any other case it must be a bug.

It was a third boot or so and I didn't even have console connected. I would say it is a bug. You don't have such problem?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines