Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline

Tomi Valkeinen
2012-09-14T08:27:43Z

[-- Attachment #1: Type: text/plain, Size: 2489 bytes --]

On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
> DSS HW on OMAP4 onwards supports a new pipeline called writeback. Unlike other
> pipelines(called overlays in OMAPDSS), writeback takes pixel data from an
> overlay output or a overlay manager output and writes it back into a specified
> address in memory.
>
> writeback pipeline allows us to take benefit of the hardware processing
> available inside the DISPC like color space conversion, rescaling, compositing
> etc and do either a) perform memory-to-memory transfer with data processing,
> b) capture a displayed frame. The former is known as memory to memory mode of
> the writeback pipeline, and the latter is known as capture mode. More details
> about writeback can be found in the Display Subsystem section of the OMAP4/5 TRMs.
>
> witeback has properties of both overlays and overlay managers. It is like an
> overlay as it has programmable base addresses and contains blocks like scalar,

You consistently use the term "scalar" in the patches, but I believe the
correct term is "scaler".

> color conversion unit, truncation unit, DISPC DMA FIFO. It is like a manager as
> enabling it immediately starts transfer to the memory, and it has a GO bit to use
> a new writeback configuration.
>
> This series prepares the low level DISPC driver(dispc.c) to configure writeback
> registers. The aim is to reuse most of the code as most of its registers are
> like overlay or manager registers, and are configured in the same way in most
> cases. The first few patches rename dispc_ovl_* functions to dispc_plane_*

I'm not sure if the renaming causes more confusion than clarity... It
kinda creates a mishmash of ovl/plane names, and the term "plane"
doesn't really sound like it's a base for both overlays and wb. Could we
consider the wb as a special case, and keep the ovl name for most of the
things and have "wb" used for wb specific things?

> functions. The next few patches change how overlay caps are used within the
> dispc functions, this helps reusing more functions between overlays and

I dislike this a bit, I think dispc driver should know what HW it has,
you shouldn't need to pass caps to it. So I'd prefer the dispc driver to
to have this information in dispc_features. I believe all OVL_CAPS
should be there, and then exported to other drivers via some means. I
guess this means could for now be just initializing ovl->caps with data
from dispc.c.

Tomi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]