[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cd513378-7be2-a5eb-adc5-bf04c789f1d4@ti.com>
Date: Mon, 30 Apr 2018 10:06:11 +0300
From: Tomi Valkeinen <tomi.valkeinen@...com>
To: Aaro Koskinen <aaro.koskinen@....fi>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
CC: Laurent Pinchart <laurent.pinchart@...asonboard.com>,
<linux-fbdev@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
<linux-omap@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH] video: fbdev: omap2: remove rfbi
On 27/04/18 21:12, Aaro Koskinen wrote:
>> You should be targeting omapdrm driver instead, fbdev subsystem is closed
>> for the new hardware support.
>
> AFAIK, based on N950 display support discussion, it's impossible to get
> anything new into omapdrm for a long time. And based on Tomi's comments,
> restoring RFBI support with omapfb should be a minor thing.
I was perhaps a bit vague, but I didn't say it should be a minor thing.
I meant that there should be no architectural obstacles in omapfb, and I
think all the generic plumbing to enable N800 display is there in omapfb.
That said, it still needs a real amount of work with the rfbi driver,
the encoder driver and the panel driver on N800 (the encoder and the
panel driver are not in mainline anymore).
Also, if I remember right, omapfb doesn't support automatic updates (or
"flushing") with manual update displays. omapfb was designed to depend
on the userspace to flush the framebuffer. This may limit its uses.
I personally do think that it would be better to target omapdrm, on top
of the manual update series, but as discussed, the schedule to support
manual update is still unclear.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Powered by blists - more mailing lists