jernej

Members
  • Content count

    617
  • Joined

  • Last visited

1 Follower

About jernej

  • Rank
    Embedded member

Recent Profile Visitors

749 profile views
  1. 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.
  2. 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.
  3. @boobypi those video-codec and mpegts nodes don't have anything in common with mali.
  4. 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
  5. 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.
  6. 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.
  7. Kernel 4.14 for sun8i h3 wanted

    H3 I2S patches were backported in Armbiam due to HDMI Audio. It should already work if you add right DT node for your codec.
  8. 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.
  9. H3/H5/A64 DRM display driver

    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.
  10. H3/H5/A64 DRM display driver

    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?
  11. fix for 24/32bit H3 audio capture

    That's nice, but even better would be to send it to upstream. Did you do that?
  12. That probably won't work, unless both kernels were built from exactly the same kernel source. Additionally, drivers in LE reside in read only part of filesystem. So you have to have LE sources and put those drivers there. But since you have to build whole image, it makes much more sense to add those drivers as a source in build system and build them. BTW, part of LibreELEC team (me and omegamoon (builder of ugoos images) included) works on official LE support for Allwinner, Rockchip and Amlogic devices. RK3288 is included in that effort, so if you can wait a bit, you will get official LE image. You can ask at LE forum in Rockchip subforum what can be done. Please specify details, for example exact tablet model, which wifi driver you need, etc. If problems are minor, like enabling already present wifi driver, they will probably be resolved quickly, but of course I can't guarantee that.
  13. Enable video out on mainline kernel?

    I found some patches on Icenowy's github: https://github.com/Icenowy/linux/commits/tve-v2 Last 6 patches are needed for enabling TV on OPi PC.
  14. Enable video out on mainline kernel?

    Since BSP drivers are mostly unusable for mainline besides informational nature, somebody needs to be interested enough to do that, so I wouldn't phrase sentence in that way ("from now on"). I definetly wouldn't use word "permanently". Those patches definetly work(ed) (when they were sent), if you are interested enough, find them, apply them and test them. Some minor adjustment may be needed since some code may be changed from that time, I don't know.