jernej

Members
  • Content count

    626
  • Joined

  • Last visited

1 Follower

About jernej

  • Rank
    Embedded member

Recent Profile Visitors

897 profile views
  1. 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.
  2. Cheap HDMI monitor -1

    @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.
  3. Cheap HDMI monitor -1

    @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.
  4. I never had any similar issues, so I can give you only generic advice - test different and/or shorter cables.
  5. 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.
  6. AV/HDMI switch and display rotation

    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.
  7. 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.
  8. 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
  9. Kernel 4.14 for sun8i h3 wanted

    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.
  10. Kernel 4.14 for sun8i h3 wanted

    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.
  11. @boobypi those video-codec and mpegts nodes don't have anything in common with mali.
  12. 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
  13. 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.
  14. 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.