Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
From: Tomi Valkeinen <hidden>
Date: 2012-09-14 08:27:43
Also in:
linux-omap
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
Attachments
- signature.asc [application/pgp-signature] 836 bytes