Hi Andrea,

On 11 December 2016 at 22:48, Andrea Venturi <[email protected]>
wrote:

> hello,
>
> this mail just to report an experience about using the DRM driver on sun7i
> (Olimex A20 SOM EVB). let me start thanking all the guys doing the
> "heavylifting" for this feature/driver.
>
> *TL;DR* i'll be very synthetic, it starts to work (you can see a picture,
> then some minutes later screen shuts off) albeit it's still a  hard to gain
> feature as lot's of info is scattered here and there or implicit, that's
> why i try to recap here the simpler recipe to "see the light"..
>
> first i've got the* 4.9rc7 kernel* runnng from sunxi-next git tree:
>
>  https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-next
>
> i compiled with the default defconfig for this Olimex A20 SOM EVB board
> and booted.
>
> i've got *simplefb* working; as the FB was working since uboot phase,
> thanx to this "modeline":
>
>  CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:24,pclk_khz:33000,
> le:45,ri:209,up:22,lo:22,hs:1,vs:1,sync:3,vmode:0"
>
> then i added in DTS the extended lines as from this commit by "net147"
> (thanx):
>
>  https://github.com/net147/linux/commit/cd93810d8a565d2348e27756f4bb27
> 62dc6cc79d
>
> BTW i added in *drivers/gpu/drm/panel/panel-simple.c* the setup of my
> panel (a noname 800x480 7inch working in uboot), and put accordingly the
> panel's compatible entry in place of the *lcd-olinuxino-43-ts* in DTS:
>  ...
>  panel: panel {
>   compatible = "olimex,lcd-olinuxino-43-ts";
>  ...
>
> then i had to patch kernel for "relaxing" the panel *clock validation
> step*  with this very recent "hack" for the clock matching:
>
>  http://www.spinics.net/lists/kernel/msg2390747.html
>
> and this is more or less everything to see the DRM LCD working on A20
>
> in *dmesg* the relevant lines are:
>
> ---
> [    1.082842] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>
> [    1.082846] [drm] No driver support for vblank timestamp query.
>
> [    1.083328] sun4i-drm display-engine: bound 1e60000.display-backend
> (ops 0xc063d87c)
> [    1.083841] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops
> 0xc063d410)
> [    1.083886] checking generic (7fe89000 177000) vs hw (0 ffffffff)
>
> [    1.083890] fb: switching to sun4i-drm-fb from simple
>
> [    1.137201 <13%2072%2001>] Console: switching to colour dummy device
> 80x30
>
> and this is all fantastic. i could display fancy images with *fbv* (i'm
> working on straight framebuffer, no X), thanks to all those involved.
>
> the only issue is that, after few minutes (10 or so), the display switch
> to this kind of rendering:
>
>  https://drive.google.com/open?id=0B9QRW6Oy0GmeOGdvM3YyYUtqZHM
>
> no messages on syslog or console. i'm wondering which kind of "glitch"
> could bring to this (i suppose some kind of "clock power down"?).
>
Console blank is 600 seconds by default - kernel will turn off the console
after 10 minutes of inactivity.
Try adding consoleblank=0 to your kernel command line.

It is powering down the display engine without powering off the LCD.


> maybe setting up some *DRM debug level,* could bring to helpful messages.
> i'll check how to enable those, if any has suggestions, are welcome.
>
> later, i'd like to test the  mali binary libraries as net147 tells they
> works too (i'll test ES GL on plain framebuffer and not X) .
>
> i see this kernel open sorce low level driver compiles (adding some setup
> on *build.sh*):
>  https://github.com/mripard/sunxi-mali
> but i'm stopping on adding the relevant entry in the DTS. and this is the
> topic for another report, eventually.
>
> Andrea
>
>
Regards,
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to