jernej

No, it is for mainline. Please read this thread for some explanation how to get right numbers. I really don't know.

I meant how to add custom resolution to BSP kernel in general, not this resolution specifically. Did you use latest sunxi-next kernel with this patch included: https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/09-dw-hdmi-add-workarounds.patch ? I don't know about this. I guess you have test it and decide for yourself.

You mean predefined resolutions for old BSP kernel 3.4? Mainline kernel should in theory support all resolutions, albeit in practice some may not work correctly. How did you test that? If you go with mainline image, it should work. But then, mainline images for H3 are considered WIP and thus not directly supported, e.g. you are on your own with issues. If you go with old BSP 3.4 kernel, you have to patch the kernel to add your resolution. Procedure was already explained on this forum.

Here is attempt to make mainline driver for AR100: https://github.com/mripard/linux/commits/sunxi/wip/ar100 But as branch name says, it's wip and not necessarly working. I didn't try it, I just though it might interest you.

Video drivers didn't change much in last few months. There is only one commit which seems relevant to this issue is this. However, it should be present only in 2018.01. You are using 2017.11, right? Can you do a bisect? It's possible that some change here is responsible too, but nothing stands out. Unfortunately, I don't have this HW, so I can't help further.

@stguenth Yes, I mean patching and recompiling the kernel, there is no other way, except if @Igor and @zador.blood.stained are ok with adding patch for all SoCs.

I'm not sure if I completely understand the issue, but recently I came across this LE PR: https://github.com/LibreELEC/LibreELEC.tv/pull/2382 Long story short, kernel from 4.9 onwards has latency issues on USB, which could cause visible artifacts when using DVB dongles. It is not clear what is correct solution, but in this thread some possible workarounds are proposed: https://www.spinics.net/lists/linux-usb/msg163892.html I think that most promising workaround can be found in LE PR mentioned at the beginning. Let me know if this is what you're after.

@valant Yeah, I mean that, but if I understand you correctly, you need just a basic (static?) setup, without any bells and whistels. Then you should probably check U-Boot implementation located here. It is much more basic and it can be reduced even further if you remove audio related stuff. If you want to support only one predefined resolution, then you could also remove all DDC/EDID related stuff. Both changes will probably leave you with only half of the code. I think this is really bare minimum for DW HDMI. i.MX6 documentation should suffice for such setup. You can even find original pre-release version of DW HDMI documentation on some Chinese forum (I don't know which), but as I said, i.MX6 doc is enough for probably everything you need.

@valant I can give you some help since I'm working on Allwinner DW-HDMI implementation, but what you asking is totally platform dependant. At least on Allwinner, LCD controller (called TCON) is just something which outputs raw data on parallel or LVDS interface. If you want anything else (TV, HDMI, MIPI-DSI) you must chose pipeline which has encoder right behind LCD controller. So it looks something like: LCD: Display Engine (HW composer) -> TCON (LCD controller) -> LCD panel HDMI: Display Engine -> TCON -> HDMI I took a quick look at your BSP code and it seems that you have same situation. That means that LCD controller needs to be enabled and properly set up in order to use HDMI. If you are writing driver for mainline kernel or U-Boot, you are fortunate that most heavy lifting is already done for DW HDMI. You just use library provided inside. If your SoC uses Synopsys PHY, you just need to provide few numbers extracted from BSP driver and some boilerplate code. Unfortunatelly, you have to write full DRM driver for, I'm not sure how there is called, Display Engine and/or (only?) LCD controller.

I never had any similar issues, so I can give you only generic advice - test different and/or shorter cables.

Only Armbian with mainline kernel is available for H5, where TV driver does not exist... You linked issue from BSP kernel, which is not used here.

Probably, but it is not HW accelerated on H3. About other things, something can be done, IF you rebuild kernel with CONFIG_SWITCH or CONFIG_ANDROID_SWITCH enabled. That way you will get few files, which will have different content, based on TV or HDMI hot plug detection status. Not sure where those files will be located, but it will be probably somewhere in /sys or /proc. Code for that is located here: https://github.com/armbian/linux/blob/sun8i/drivers/video/sunxi/disp2/hdmi/drv_hdmi.c#L491-L510 https://github.com/armbian/linux/blob/sun8i/drivers/video/sunxi/disp2/tv/drv_tv.c#L31-L82 In script.bin you would need enabled both, hdmi and tv, or else you won't get status notification. Final step would be writing simple daemon, which will monitor aforementioned files and react on content change accordingly. There is simple way how to enable/disable TV/HDMI display from userspace on running system, but you would need root access. Since you already need to recompile the kernel, you should patch this part of code to have access rights 0666, so root rights are not needed The procedure how to turn on/off hdmi/tv can be found here Just instead "disp" use "disp0" and "disp1" respectively. There is another procedure if this doesn't work. I'm not sure if work described above is worth the hassle, but your strategy may work.

You can use LibreELEC for H3 which can be build from this sources: https://github.com/LibreELEC/LibreELEC.tv/tree/allwinner But there is no support for HW decoding with mainline kernel. Work on this is already planned, but don't expect anything useful before middle of the next year.

That format is not yet supported by mainline driver (http://elixir.free-electrons.com/linux/latest/source/drivers/gpu/drm/sun4i/sun8i_layer.c#L64). Fortunately, it is easy to add support. In the aforementioned array add DRM_FORMAT_RGB565 and here http://elixir.free-electrons.com/linux/latest/source/drivers/gpu/drm/sun4i/sun8i_mixer.c#L69 add: case DRM_FORMAT_RGB565: *mode = 10; break; Currently I'm working on a improved DE2 DRM driver, which will include this. However, I'm still not sure how to make that default choice. But first it must be supported by the driver

That is not really true. Check cover letter of the I2S driver patches: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/525407.html While I ask him to support I2S2 for HDMI audio, he started to develop this driver before with DACs like pcm5102 and uda1380. Actually I2S2 node is not even in upstream DT. You can ask him for 24/32 bit and 192 kHz support and he may help you.

Yes, because it is not implemented yet. Mainline I2S driver supports only 16 bits for now. Shouldn't be hard to add 24/32 bit support. I'm not sure about 192kHz though, maybe it's only not marked as supported or maybe something more is missing.

@boobypi those video-codec and mpegts nodes don't have anything in common with mali.

That is the line you are looking for: http://elixir.free-electrons.com/linux/latest/source/drivers/gpu/drm/drm_probe_helper.c#L504 Unfortunately, only resolutions from this array can be selected: http://elixir.free-electrons.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L661

drivers/gpu/drm ?

it is hardcoded somewhere in general DRM code, you have to search for it, but I think it shouldn't be hard to change it.

That is a bit outdated, since 4.13 has proper DRM driver and U-Boot settings aren't considered anymore. Those instruction are also for non mainlined U-Boot driver and with the stock U-Boot driver can't be used anymore. Detecting monitor resolution is a bit quirky on H3. It doesn't have interrupt for for hot plug detection, so kernel will check every 10s or so for monitor attachment/removal. I'm not sure about reading EDID though. I can only confirm what you already know - if EDID is not read out correctly, fallback resolution is 1024x768. Try with detaching hdmi cable, wait more than 10s and plug it back.

H3 I2S patches were backported in Armbiam due to HDMI Audio. It should already work if you add right DT node for your codec.

Apart from DT changes, driver shouldn't need much adjustements for 4.14, if any. 4.15 (current linux-next) is a different story though.

That would suggest race condition. But since I develop driver with a kernel with only built in drivers, problem may be masked. Driver unloading needs some work anyway, since clocks are not disabled.

No, not really. I never observed that, but then again, I test everything exclusively on H3, drivers built in and in 99% cases with cable plugged in at all times . I will check that case. Can you try with drivers built in and with disabled cec & dw hdmi i2s driver?