jernej Posted September 5, 2017 Posted September 5, 2017 @zador.blood.stained I think Icenowy's linux git is only A64 oriented. For example, she added non-optional regulator to HDMI driver, which doesn't exist on OrangePi PC2. There may be more hidden issues...
zador.blood.stained Posted September 5, 2017 Posted September 5, 2017 @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.
zador.blood.stained Posted September 5, 2017 Posted September 5, 2017 @jernej Does your patch solve a kernel warning in ccu_something_wait_for_lock during boot (with a stack trace pointing to DE2 code) or is there a real crash that we didn't encounter yet?
jernej Posted September 5, 2017 Author Posted September 5, 2017 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...
zador.blood.stained Posted September 5, 2017 Posted September 5, 2017 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.
jernej Posted September 5, 2017 Author Posted September 5, 2017 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?
zador.blood.stained Posted September 5, 2017 Posted September 5, 2017 Moved display driver related posts to a separate thread. @jernej So should we test this? https://github.com/jernejsk/linux-1/commits/h3_hdmi_audio_v1 Will you keep "ARM: sun8i: h3: Enable HDMI output on xxx board" patches separate for each board? Should this driver also work on H5 (i.e. OPi PC2)?
jernej Posted September 5, 2017 Author Posted September 5, 2017 19 minutes ago, zador.blood.stained said: So should we test this? https://github.com/jernejsk/linux-1/commits/h3_hdmi_audio_v1 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. 3
zador.blood.stained Posted September 6, 2017 Posted September 6, 2017 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.). 1
jernej Posted September 6, 2017 Author Posted September 6, 2017 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.
zador.blood.stained Posted September 6, 2017 Posted September 6, 2017 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.
jernej Posted September 6, 2017 Author Posted September 6, 2017 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.
jernej Posted September 6, 2017 Author Posted September 6, 2017 Some clock patches are also needed. Take a look at my patches from 1. Avgust here: https://github.com/jernejsk/linux-1/commits/h3_hdmi_audio_v1/drivers/clk/sunxi-ng Without them, resolution switching to resolutions like 1080p or 720p won't work. 1
zador.blood.stained Posted September 6, 2017 Posted September 6, 2017 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.
jernej Posted September 6, 2017 Author Posted September 6, 2017 1 minute ago, zador.blood.stained said: Well, last time I heard that simplefb is deprecated I'm don't remember anybody saying that...
Da Alchemist Posted September 7, 2017 Posted September 7, 2017 I have tested HDMI Audio on my Opi +2e, it is limited to 2 channels.(tested with speaker-test) Anyway it is good to know, that there is still developement on H5/H3 Boards.
jernej Posted September 7, 2017 Author Posted September 7, 2017 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?
jernej Posted September 7, 2017 Author Posted September 7, 2017 Can anybody select different resolution? That worked well with my kernel, which was based on linux-next (1. September). @zador.blood.stained simplefb is completely off, right?
zador.blood.stained Posted September 7, 2017 Posted September 7, 2017 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.
zador.blood.stained Posted September 7, 2017 Posted September 7, 2017 Found 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.
Da Alchemist Posted September 7, 2017 Posted September 7, 2017 50 minutes ago, jernej said: . So a lot of work. Do you want to help? I am Sorry Jernej, I do not have any programming skills. You are doing a fantastic job!
zador.blood.stained Posted September 7, 2017 Posted September 7, 2017 @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?
jernej Posted September 7, 2017 Author Posted September 7, 2017 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.
zador.blood.stained Posted September 7, 2017 Posted September 7, 2017 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.
jernej Posted September 7, 2017 Author Posted September 7, 2017 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?
zador.blood.stained Posted September 7, 2017 Posted September 7, 2017 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.
jernej Posted September 7, 2017 Author Posted September 7, 2017 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".
jernej Posted September 7, 2017 Author Posted September 7, 2017 @zador.blood.stained Do you know why I have to type password for shutdown?
zador.blood.stained Posted September 7, 2017 Posted September 7, 2017 Just now, jernej said: Do you know why I have to type password for shutdown? 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.
jernej Posted September 7, 2017 Author Posted September 7, 2017 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?
Recommended Posts