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:
signature.asc
Description: This is a digitally signed message part
