Jump to content

jernej

Members
  • Posts

    1115
  • Joined

  • Last visited

Reputation Activity

  1. Like
    jernej got a reaction from zador.blood.stained in Mali support announced for mainline (Allwinner SOC's)   
    I can tell that I tested Mali wayland/gbm driver version and it works well.
  2. Like
    jernej got a reaction from manuti in H3/H5/A64 DRM display driver   
    @Da Alchemist
    I prepared another test patch for multichannel audio support. Can you test it?
    http://sprunge.us/gcbB
  3. Like
    jernej got a reaction from manuti in H3/H5/A64 DRM display driver   
    Yeah, I'll fix that. Usually I'm lazy when it comes to DT...
     
    I tested it already. Just one line fix was required to make it work, which is already included on my github:
    https://github.com/jernejsk/linux-1/commit/5de498da7efd4593976c4e41ca7367ac23352616#diff-0dd6c05e592804ae87e06c218a333a37R318
  4. Like
    jernej got a reaction from zador.blood.stained in H3/H5/A64 DRM display driver   
    Yeah, I'll fix that. Usually I'm lazy when it comes to DT...
     
    I tested it already. Just one line fix was required to make it work, which is already included on my github:
    https://github.com/jernejsk/linux-1/commit/5de498da7efd4593976c4e41ca7367ac23352616#diff-0dd6c05e592804ae87e06c218a333a37R318
  5. Like
    jernej got a reaction from Naguissa in Mali support announced for mainline (Allwinner SOC's)   
    Which is not possible with all Mali GPUs Allwinner used till H6.
  6. Like
    jernej got a reaction from willmore in Mali support announced for mainline (Allwinner SOC's)   
    Which is not possible with all Mali GPUs Allwinner used till H6.
  7. Like
    jernej got a reaction from zador.blood.stained in H3/H5/A64 DRM display driver   
    But is needed anyway.
     
    My findings also.
     
    I hope I can play a bit with Mali in the evening.
  8. Like
    jernej got a reaction from zador.blood.stained in H3/H5/A64 DRM display driver   
    I think you must go trough all uargs->... references and replace it to job->uargs->... except for https://github.com/Icenowy/sunxi-mali/blob/master/r6p0/src/devicedrv/mali/common/mali_gp_job.c#L93, obviously.
  9. Like
    jernej got a reaction from zador.blood.stained in H3/H5/A64 DRM display driver   
    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.
  10. Like
    jernej reacted to zador.blood.stained in H3/H5/A64 DRM display driver   
    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.).
  11. Like
    jernej got a reaction from zador.blood.stained in H3/H5/A64 DRM display driver   
    Yes, but I have missed one patch which may or may not be important. It will have to wait till tomorrow.
     
    For now, yes. I guess this doesn't really matter since we could squash all HDMI patches to one?
     
    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.
  12. Like
    jernej got a reaction from lanefu in H3/H5/A64 DRM display driver   
    Yes, but I have missed one patch which may or may not be important. It will have to wait till tomorrow.
     
    For now, yes. I guess this doesn't really matter since we could squash all HDMI patches to one?
     
    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.
  13. Like
    jernej got a reaction from manuti in H3/H5/A64 DRM display driver   
    Yes, but I have missed one patch which may or may not be important. It will have to wait till tomorrow.
     
    For now, yes. I guess this doesn't really matter since we could squash all HDMI patches to one?
     
    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.
  14. Like
    jernej reacted to Myy in The VPU driver   
    Alright, the biggest issue with the ASUS Tinkerboard being "resolved", I'm starting to take care of the VPU driver, in order to use it with mainline kernels.
     
    The hardware video encoding/decoding facilities are the real meat of the RK3288, and recent Rockchip boards.
    The VPU driver aims to use these facilities in order to provide the smooth video playback experience that every Netflix/Hulu addict expects when buying such boards.
     
    Which mean, once this part dealt with, you might be able to enjoy your Multimedia oriented distributions/softwares on your Rockchip boards (MiQi, Tinkerboard and maybe Pine64 too !)
     
    So the driver is already available in Rockchip 4.4 kernels, and started to be ported in an Out-Of-Tree fashion by phhusson on Github, and then got the attention of wzyy2, one of the Rockchip guy, which updated it and took care of multiple bugs that were present in this version.
     
    I'm now reassembling the code, include files and all in my rockchip-vcodec repository, patching the code to use it with the latest 4.13 kernels.
     
    Now, the problems are : I don't get the big picture from the user side. So it's kinda hard to test this quickly.
     
    Rockchip seems to rely on their library, MPP, and patched gstreamer packages if I understand correctly. Last time I tried the "test-suite" of the MPP library, things were "clunky". Since it's mostly maintained by one person, ayaka, I'm pretty sure that it's the kind of test-suite that only the owner clearly understands. I know that problem, as I did the same thing with some of my libraries.
     
     
    So, basically, the main goals are :
    ! Compile the VPU driver without issues. I took care of that for now. The driver compiles, loads AND unloads correctly, without issues. ? Understand clearly what packages, patches and software are needed to use the VPU services provided by the VPU driver. ? Enjoy 1080p movies without a hitch on RK3288 boards (and others Rockchip boards if possible) !  
    I'll add these goals on the Github pages so that everyone gets how things are going, from the GH page.
     
    If you have any issue with the driver and/or it's use, file it on my repository and I'll see what I can do.
  15. Like
    jernej got a reaction from Mike R9FT in 7" hdmi display   
    Actually you can't do much except patch U-Boot. H3 and newer chips uses driver in U-Boot which doesn't consider video-mode variable. Since kernel relies on U-Boot to set up HDMI for now, the only thing you can do is to create U-Boot patch and rebuild the image on your own. You only need to change line 131.
  16. Like
    jernej got a reaction from Joshua Ellinger in 5" 800x480 waveshare lcd working but messed up image.   
    It seems that numbers in hdmi driver are wrong for this mode. Here is a patch which might solve the issue, although not tested for obvious reasons:
    https://transfer.sh/UCKIH/zzz-fix-video-modes.patch
    Note that link is valid only for 14 days.
     
    You can add this patch to build system and build your own image. If it works, we can include it in upstream repo. Although if you are not familiar with linux, this might be a nice challenge, but you will learn a few things along.
  17. Like
    jernej got a reaction from Da Alchemist in ROCK64   
    That may be hard, but I just checked mpp source (Rockchip HW video acceleration library) and it mentions that RK3328 is fully supported. Rockchip kernel 4.4 also has initial support for video decoding. I would say that future is bright.
  18. Like
    jernej got a reaction from bozden in ROCK64   
    That may be hard, but I just checked mpp source (Rockchip HW video acceleration library) and it mentions that RK3328 is fully supported. Rockchip kernel 4.4 also has initial support for video decoding. I would say that future is bright.
  19. Like
    jernej got a reaction from hmartin in ROCK64   
    I know that Rockchip doesn't usually provide full user manuals, but is there a chance to get them anyway?
  20. Like
    jernej got a reaction from tkaiser in ROCK64   
    @tkaiser
    yes, my board should be on the way, but it has same USB3 issue.
  21. Like
    jernej got a reaction from op1tjaap in dwmac-sun8i  driver ..... v6   
    dwmac-sun8i v6 driver was just merged to net-next and it will be included from 4.13 onwards. So just a 2-3 months away.
  22. Like
    jernej got a reaction from zador.blood.stained in dwmac-sun8i  driver ..... v6   
    dwmac-sun8i v6 driver was just merged to net-next and it will be included from 4.13 onwards. So just a 2-3 months away.
  23. Like
    jernej got a reaction from tkaiser in dwmac-sun8i  driver ..... v6   
    dwmac-sun8i v6 driver was just merged to net-next and it will be included from 4.13 onwards. So just a 2-3 months away.
  24. Like
    jernej got a reaction from giri@nwrk.biz in PSA: Orange Pi Zero expansion board tv-out not working solution   
    TV unit is described only in A10 and R40 datasheet. Even in those two datasheets some register descriptions are missing, but they should be enough. You can find them through linux-sunxi.org
  25. Like
    jernej got a reaction from Da Alchemist in RK3328 Kernel   
    4.4 kernel should support it since last month or something like that (I was analyzing exactly that piece of the code), but I didn't test it.
×
×
  • Create New...