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,
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_*
functions. The next few patches change how overlay caps are used within the
dispc functions, this helps reusing more functions between overlays and
writeback. The patches in the end add writeback register offsets, and make
changes in the code where writeback behaves differently than
The changes are made only keeping writeback mem to mem support in mind. There
would be a few changes required when capture mode is added, but those are
minimal.
Reference branch:
git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git 1-writeback-dispc
Archit Taneja (21):
OMAPDSS: DISPC: Constify omap_overlay_info in dispc_ovl_setup()
OMAPDSS: DISPC: Rename scalar related functions from dispc_ovl_* to
dispc_plane_*
OMAPDSS: DISPC: Rename fifo/burst related functions from dispc_ovl_*
to dispc_plane_*
OMAPDSS: DISPC: Rename misc functions from dispc_ovl_* to
dispc_plane_*
OMAPDSS: DISPC: Simplify function names for setting pipeline input
and output sizes
OMAPDSS: DISPC: Pass overlay caps as a parameter to dispc plane
functions
OMAPDSS: OVERLAY: Add position and replication as overlay caps
OMAPDSS: DISPC: Make dispc_ovl_setup call dispc_plane_setup
OMAPDSS: DISPC: Calculate scaling limits in a more generic way
OMAPDSS: DISPC: Allow both upscaling and downscaling of chroma
OMAPDSS: DISPC: Add writeback register offsets and dss features
structs
OMAPDSS: DISPC: Configure input and output sizes for writeback
OMAPDSS: DISPC: Pass dummy scalar output rates for writeback pipeline
OMAPDSS: DISPC: Downscale chroma if plane is writeback
OMAPDSS: DISPC: Don't set chroma resampling bit for writeback
OMAPDSS: DISPC: Add function to set channel in for writeback
OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup
OMAPDSS: DISPC: Configure writeback specific parameters in
dispc_wb_setup()
OMAPDSS: DISPC: Configure writeback FIFOs
OMAPDSS: DISPC: Add manager like functions for writeback
OMAPDSS: DISPC: Configure color conversion coefficients for writeback
drivers/video/omap2/dss/apply.c | 4 +-
drivers/video/omap2/dss/dispc.c | 659 +++++++++++++++++++++-----------
drivers/video/omap2/dss/dispc.h | 35 +-
drivers/video/omap2/dss/dispc_coefs.c | 2 +-
drivers/video/omap2/dss/dss.h | 26 +-
drivers/video/omap2/dss/dss_features.c | 57 ++-
drivers/video/omap2/dss/dss_features.h | 1 +
include/video/omapdss.h | 15 +
8 files changed, 564 insertions(+), 235 deletions(-)
--
1.7.9.5
The struct omap_overlay_info passed to dispc_ovl_setup() is used to configure
DISPC registers. It shouldn't modify the overlay_info structure. The pos_y field
was being changed in dispc_ovl_setup in the case of interlaced displays. Fix
this and const qualifier to the omap_overlay_info argument.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 9 +++++----
drivers/video/omap2/dss/dss.h | 2 +-
2 files changed, 6 insertions(+), 5 deletions(-)
Writeback pipeline has an identical scalar block as in video pipelines. Rename
the scalar related function from dispc_ovl_* to dispc_plane_*. The actual
registers are kept as DISPC_OVL_* only to prevent too much change.
All functions which are common to overlays and writeback are to be named as
dispc_plane_*, functions which are specific to overlays are to be named as
dispc_ovl_*, and writeback as dispc_wb_*.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 92 ++++++++++++++++++---------------
drivers/video/omap2/dss/dispc.h | 2 +-
drivers/video/omap2/dss/dispc_coefs.c | 2 +-
3 files changed, 51 insertions(+), 45 deletions(-)
Writeback pipeline uses fifo and burst related IP similar to what the graphics
and video pipe have. Rename the related functions from dispc_ovl_* to
dispc_plane_*. The actual registers are kept as DISPC_OVL_* only to prevent too
much change.
All functions which are common to overlays and writeback are to be named as
dispc_plane_*, functions which are specific to overlays are to be named as
dispc_ovl_*, and writeback as dispc_wb_*.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/apply.c | 4 ++--
drivers/video/omap2/dss/dispc.c | 30 +++++++++++++++---------------
drivers/video/omap2/dss/dss.h | 4 ++--
3 files changed, 19 insertions(+), 19 deletions(-)
@@ -436,8 +436,8 @@ int dispc_calc_clock_rates(unsigned long dispc_fclk_rate,structdispc_clock_info*cinfo);-voiddispc_ovl_set_fifo_threshold(enumomap_planeplane,u32low,u32high);-voiddispc_ovl_compute_fifo_thresholds(enumomap_planeplane,+voiddispc_plane_set_fifo_threshold(enumomap_planeplane,u32low,u32high);+voiddispc_plane_compute_fifo_thresholds(enumomap_planeplane,u32*fifo_low,u32*fifo_high,booluse_fifomerge,boolmanual_update);intdispc_ovl_setup(enumomap_planeplane,conststructomap_overlay_info*oi,
Writeback pipeline has similar registers compared to graphics and video pipes
for setting base addresses, color conversion, row inc, pix inc etc. Rename these
functions from dispc_ovl_* to dispc_plane_*. The actual registers are kept as
DISPC_OVL_* only to prevent too much change.
All functions which are common to overlays and writeback are to be named as
dispc_plane_*, functions which are specific to overlays are to be named as
dispc_ovl_*, and writeback as dispc_wb_*.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 67 ++++++++++++++++++++-------------------
1 file changed, 35 insertions(+), 32 deletions(-)
The DISPC pipeline register names in the TRM for setting the buffer size and
the output size are a bit misleading, for example, there are different register
names for setting the buffer size for VID and GFX pipes. Things get more
confusing when considering writeback pipeline.
Rename the functions so that they tell whether they are configuring the input
to the scalar or the output. These will be extended later to support writeback
registers.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Currently, the functions below take the omap_plane parameter and derive the
overlay caps within them. Pass the overlay caps as a parameter to the function
to allow these to be used by writeback too.
- dispc_plane_set_zorder()
- dispc_plane_set_pre_mult_alpha()
- dispc_plane_setup_global_alpha()
- dispc_plane_calc_scaling()
- dispc_ovl_setup()
These functions will be used for writeback later, and the caps will help in
deciding if they are to be used for writeback or not. This allows reuse of
overlay caps for writeback.
Using omap_overlay_caps for writeback seems a bit incorrect, but caps is
something already in use by users of OMAPDSS(omapfb/omap_vout), so we use
overlay caps for overlay like features of writeback too.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 40 +++++++++++++++++++--------------------
1 file changed, 19 insertions(+), 21 deletions(-)
Add position and replication as overlay caps, and pass overlay caps as an
argument to the corresponding functions. Adding position and replication to
overlay caps seems a bit unnecessary, but it allows us to use the
corresponding functions for writeback too.
These caps will be set for all overlays, but not for writeback. This is done
so writeback can reuse dispc_ovl_setup() to the maximum.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 20 ++++++++++++-----
drivers/video/omap2/dss/dss_features.c | 38 +++++++++++++++++++++-----------
include/video/omapdss.h | 2 ++
3 files changed, 42 insertions(+), 18 deletions(-)
Add a new static function called dispc_plane_setup(). This function is used by
dispc_ovl_setup() to configure the overlay registers.
This split is done so that dispc_wb_setup() can reuse the common overlay related
registers configured in dispc_plane_setup().
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 125 ++++++++++++++++++++++-----------------
1 file changed, 70 insertions(+), 55 deletions(-)
Scaling calculations for an overlay are done by comparing pixel clock of the
connected overlay manager and the core clock of DISPC. The pixel clock is the
output rate of the scalar. The scalar block needs to provide pixels at this rate
since the manager is connected to a panel, which has real time constraints.
In the case of writeback in memory to memory mode, the output of the scalar
blocks aren't connected to a display, and hence there isn't a pixel clock which
causes downscaling limitations.
Make the input to scaling calculations a bit more generic by passing the scalar
output rate rather than passing pixel clock of the overlay manager connected to
the pipeline, as we now have use cases where the scalar's output may not go to
a manager connected to a panel.
This also helps us in replacing omap_channel arguments with output_rate, making
dispc_plane_setup more pipeline specific.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 126 ++++++++++++++++++++++-----------------
1 file changed, 72 insertions(+), 54 deletions(-)
In the function dispc_plane_set_scaling_uv(), create a parameter which tells if
we want to upscale or downscale the chroma plane.
Downscaling of chroma is required by writeback pipeline for converting the input
YUV444 color format to YUV422 or NV12.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 32 ++++++++++++++++++++++----------
1 file changed, 22 insertions(+), 10 deletions(-)
@@ -1478,23 +1479,34 @@ static void dispc_plane_set_scaling_uv(enum omap_plane plane,switch(color_mode){caseOMAP_DSS_COLOR_NV12:-/* UV is subsampled by 2 vertically*/-orig_height>>=1;-/* UV is subsampled by 2 horz.*/-orig_width>>=1;+if(chroma_upscale){+/* UV is subsampled by 2 horizontally and vertically */+orig_height>>=1;+orig_width>>=1;+}else{+/* UV is downsampled by 2 horizontally and vertically */+orig_height<<=1;+orig_width<<=1;+}+break;caseOMAP_DSS_COLOR_YUV2:caseOMAP_DSS_COLOR_UYVY:-/*For YUV422 with 90/270 rotation,-*wedon'tupsamplechroma-*/+/* For YUV422 with 90/270 rotation, we don't upsample chroma */if(rotation=OMAP_DSS_ROT_0||-rotation=OMAP_DSS_ROT_180)-/* UV is subsampled by 2 hrz*/-orig_width>>=1;+rotation=OMAP_DSS_ROT_180){+if(chroma_upscale)+/* UV is subsampled by 2 horizontally */+orig_width>>=1;+else+/* UV is downsampled by 2 horizontally */+orig_width<<=1;+}+/* must use FIR for YUV422 if rotated */if(rotation!=OMAP_DSS_ROT_0)scale_x=scale_y=true;+break;default:BUG();
Since writeback has many overlay like properties, and most of it's registers are
similar to that of overlays, it's possible to reuse most of the overlay related
DISPC code for writeback when considering it as a plane. Writeback was added as
a plane in the omap_plane field as OMAP_DSS_WB.
Add the writeback register offsets in dispc.h, add minimal WB plane related info
needed in dss_features. Add a function which returns the number of writeback
pipelines an OMAP version has.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.h | 33 ++++++++++++++++++++++++++++++++
drivers/video/omap2/dss/dss_features.c | 19 ++++++++++++++++++
drivers/video/omap2/dss/dss_features.h | 1 +
3 files changed, 53 insertions(+)
Writeback uses the WB_PICTURE_SIZE register to define the size of the content
written to memory, this is the output of the scalar. It uses the WB_SIZE
register to define the size of the content coming from the overlay/manager to
which it is connected, this is the input to the scalar. This naming is different
as compared to overlays.
Add checks for writeback in dispc_plane_set_input_size() and
dispc_plane_set_output_size() to write to the correct registers.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
The scalar output rate for writeback pipeline when configured in memory to
memory mode isn't a fixed rate, it can increase or reduce based on the time
it needs to downscale. It also depends on the rate at which it can receive
and push out data from/to the interconnect.
Set the scalar output rates for writeback to a low dummy value(set to 1) to
represent that it can output at low rates, this is done so that maximum
downscaling is possible in memory to memory mode.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
When converting YUYV444 content to YUV422 or NV12 formats through writeback
pipeline, the scalar needs to downscale the chroma plane. Ensure that chroma
is downscaled when the pipeline is writeback.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The bit YUVCHROMARESAMPLING isn't there for writeback in DISPC_WB_ATTRIBUTES2.
It isn't there because we don't upsample chroma like for video pipelines, we
downsample chroma in writeback to get YUV422 or NV12 formats from the YUV444
input.
Ignore this bit in dispc_ovl_set_scaling_uv() if the plane is OMAP_DSS_WB.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
@@ -1525,8 +1526,10 @@ static void dispc_plane_set_scaling_uv(enum omap_plane plane,out_width,out_height,five_taps,rotation,DISPC_COLOR_COMPONENT_UV);-REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane),-(scale_x||scale_y)?1:0,8,8);+if(plane!=OMAP_DSS_WB)+REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane),+(scale_x||scale_y)?1:0,8,8);+/* set H scaling */REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane),scale_x?1:0,5,5);/* set V scaling */
Writeback can take input from either one of the overlays, or one of the overlay
managers. Add an enum which represents the channel_in for writeback, and maps
to the register field programming.
Add a function to configure channel in for writeback. This will be used later in
APPLY.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 7 +++++++
drivers/video/omap2/dss/dss.h | 13 +++++++++++++
2 files changed, 20 insertions(+)
@@ -113,6 +113,17 @@ enum dss_dsi_content_type {DSS_DSI_CONTENT_GENERIC,};+enumdss_writeback_channel{+DSS_WB_LCD1_MGR=0,+DSS_WB_LCD2_MGR=1,+DSS_WB_TV_MGR=2,+DSS_WB_OVL0=3,+DSS_WB_OVL1=4,+DSS_WB_OVL2=5,+DSS_WB_OVL3=6,+DSS_WB_LCD3_MGR=7,+};+structdss_clock_info{/* rates that we get with dividers below */unsignedlongfck;
Create struct omap_dss_writeback_info, this is similar to omap_overlay_info,
the major difference is that there is no parameter which describes the input
size to writeback, this is because this is always fixed, and decided by the
connected overlay or overlay manager. One more difference is that screen_width
is renamed to buf_width, to give the value of stride the writeback buffer has.
Call dispc_plane_setup() through dispc_wb_setup() to configure overlay-like
parameters. The parameters in dispc_plane_setup() which do not hold for
writeback are filled passed as zeroes or false, dispc_plane_setup() takes
care of not configuring them as they won't possess the needed overlay caps.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 30 ++++++++++++++++++++++++++++++
drivers/video/omap2/dss/dss.h | 2 ++
include/video/omapdss.h | 13 +++++++++++++
3 files changed, 45 insertions(+)
Configure some of the writeback specific parameters in dispc_wb_setup(). The
writeback parameters configured are:
truncation: This needs to be set if the color depth input to writeback is more
than the color depth of the color mode we want to store in memory.
writeback mode: This configures whether we want to use writeback in mem to mem
or capture mode. This information will be directly passed by APPLY later.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 26 +++++++++++++++++++++++++-
drivers/video/omap2/dss/dss.h | 2 +-
2 files changed, 26 insertions(+), 2 deletions(-)
Extend the DISPC fifo functions to also configure the writeback FIFO thresholds.
The most optimal configuration for writeback is to push out data to the
interconnect the moment writeback pushes enough pixels in the FIFO to form a
burst. This reduces the chance of writeback overflowing it's FIFO.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
Add functions to enable writeback, and set/check state of GO bit. These bits are
identical in behaviour with the corresponding overlay manager bits. Configure
them in a similar way to mgr_enable() and mgr_go_* functions. Add a helper to
get the FRAMEDONE irq corresponding to writeback.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 70 +++++++++++++++++++++++++++++++++++++++
drivers/video/omap2/dss/dss.h | 5 +++
2 files changed, 75 insertions(+)
@@ -562,6 +567,30 @@ void dispc_mgr_go(enum omap_channel channel)mgr_fld_write(channel,DISPC_MGR_FLD_GO,1);}+booldispc_wb_go_busy(void)+{+returnREG_GET(DISPC_CONTROL2,6,6)=1;+}++voiddispc_wb_go(void)+{+enumomap_planeplane=OMAP_DSS_WB;+boolenable,go;++enable=REG_GET(DISPC_OVL_ATTRIBUTES(plane),0,0)=1;++if(!enable)+return;++go=REG_GET(DISPC_CONTROL2,6,6)=1;+if(go){+DSSERR("GO bit not down for WB\n");+return;+}++REG_FLD_MOD(DISPC_CONTROL2,1,6,6);+}+staticvoiddispc_plane_write_firh_reg(enumomap_planeplane,intreg,u32value){
@@ -2678,6 +2707,47 @@ void dispc_mgr_enable(enum omap_channel channel, bool enable)BUG();}+voiddispc_wb_enable(boolenable)+{+enumomap_planeplane=OMAP_DSS_WB;+structcompletionframe_done_completion;+boolis_on;+intr;+u32irq;++is_on=REG_GET(DISPC_OVL_ATTRIBUTES(plane),0,0);+irq=DISPC_IRQ_FRAMEDONEWB;++if(!enable&&is_on){+init_completion(&frame_done_completion);++r=omap_dispc_register_isr(dispc_disable_isr,+&frame_done_completion,irq);+if(r)+DSSERR("failed to register FRAMEDONEWB isr\n");+}++REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane),enable?1:0,0,0);++if(!enable&&is_on){+if(!wait_for_completion_timeout(&frame_done_completion,+msecs_to_jiffies(100)))+DSSERR("timeout waiting for FRAMEDONEWB\n");++r=omap_dispc_unregister_isr(dispc_disable_isr,+&frame_done_completion,irq);+if(r)+DSSERR("failed to unregister FRAMEDONEWB isr\n");+}+}++booldispc_wb_is_enabled(void)+{+enumomap_planeplane=OMAP_DSS_WB;++returnREG_GET(DISPC_OVL_ATTRIBUTES(plane),0,0);+}+voiddispc_lcd_enable_signal_polarity(boolact_high){if(!dss_has_feature(FEAT_LCDENABLEPOL))
Writeback pipeline receives RGB data from one of the overlays or one of the
overlay managers. If the target color mode is YUV422 or NV12, we need to convert
the RGB pixels to YUV. The scalar in WB then converts it to the target color
mode.
Hence, the color conversion coefficients that need to be programmed are the ones
which convert a RGB24 pixel to YUV444. Program these coefficients for writeback
pipeline.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2012-09-14 08:27:43
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
From: Tomi Valkeinen <hidden> Date: 2012-09-14 08:46:32
On Fri, 2012-09-14 at 11:27 +0300, Tomi Valkeinen wrote:
On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
quoted
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?
And while WB is a combination of overlays and ovl managers, do you think
it'd be difficult to consider WB as a special, extended overlay? So just
call it an overlay, and consider it as an overlay with special features,
at least inside dispc.c. We probably need to have it as a totally
different entity from user's point of view (i.e. the list of overlays
wouldn't return WB, etc).
Tomi
From: Tomi Valkeinen <hidden> Date: 2012-09-14 08:53:08
On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
Scaling calculations for an overlay are done by comparing pixel clock of the
connected overlay manager and the core clock of DISPC. The pixel clock is the
output rate of the scalar. The scalar block needs to provide pixels at this rate
since the manager is connected to a panel, which has real time constraints.
In the case of writeback in memory to memory mode, the output of the scalar
blocks aren't connected to a display, and hence there isn't a pixel clock which
causes downscaling limitations.
Make the input to scaling calculations a bit more generic by passing the scalar
output rate rather than passing pixel clock of the overlay manager connected to
the pipeline, as we now have use cases where the scalar's output may not go to
a manager connected to a panel.
Pixel clock is the rate at which pixels are processed. I don't see it
only meaning a clock that's related to actual video signal going out of
OMAP. So if in normal case the scaler outputs pixels at the rate of
pixel clock, we can call it pixel clock with WB's case also, instead of
renaming it to output clock.
Or was there some other reason for the rename, that I missed?
Tomi
From: Tomi Valkeinen <hidden> Date: 2012-09-14 09:07:29
On Thu, 2012-09-13 at 17:45 +0530, Archit Taneja wrote:
quoted hunk
Writeback pipeline receives RGB data from one of the overlays or one of the
overlay managers. If the target color mode is YUV422 or NV12, we need to convert
the RGB pixels to YUV. The scalar in WB then converts it to the target color
mode.
Hence, the color conversion coefficients that need to be programmed are the ones
which convert a RGB24 pixel to YUV444. Program these coefficients for writeback
pipeline.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
This looks a bit funny. I'd suggest to take the actual register writes
to a separate function, and have a separate tables for ovls and wb, and
have two for loops, first for ovls and then for wbs.
Btw, I wonder if we could consider WB as a single special entity, i.e.
no need for "num_wbs" or such. I know things may change in the future
HW, but I got the impression that adding overlays to DSS is costly, and
single WB is enough.
Then again, I'm not sure if handling only single WB would simplify much.
If you think it's no issue to have support for multiple WBs, perhaps we
can have it, just in case.
Tomi
On Friday 14 September 2012 02:23 PM, Tomi Valkeinen wrote:
On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
quoted
Scaling calculations for an overlay are done by comparing pixel clock of the
connected overlay manager and the core clock of DISPC. The pixel clock is the
output rate of the scalar. The scalar block needs to provide pixels at this rate
since the manager is connected to a panel, which has real time constraints.
In the case of writeback in memory to memory mode, the output of the scalar
blocks aren't connected to a display, and hence there isn't a pixel clock which
causes downscaling limitations.
Make the input to scaling calculations a bit more generic by passing the scalar
output rate rather than passing pixel clock of the overlay manager connected to
the pipeline, as we now have use cases where the scalar's output may not go to
a manager connected to a panel.
Pixel clock is the rate at which pixels are processed. I don't see it
only meaning a clock that's related to actual video signal going out of
OMAP. So if in normal case the scaler outputs pixels at the rate of
pixel clock, we can call it pixel clock with WB's case also, instead of
renaming it to output clock.
Pixel clock, in OMAP DSS terms, is the rate at which the video port of
an overlay manager provides pixels to an output. It is a fixed rate at
which the scaler needs to push out data.
If we stick to this terminology of pixel clock, I don't think it applies
to writeback. As far as I see it, there is no specific rate at which the
scaler outputs data, it adjusts itself based on how much scaling is
done, and at the rate we can get/push data to the interconnect. That's
why I didn't want to call it pixel clock. Because, that sounds a lot
like a fixed rate at which pixels need to be output.
Or was there some other reason for the rename, that I missed?
The main aim of this patch was to pass pixel clock rate/or output rate
as an argument to scaler functions, rather than passing the overlay
manager's channel id to calculate this rate. I can rename it to pixel
clock if that seems better.
Archit
From: Tomi Valkeinen <hidden> Date: 2012-09-14 09:49:05
On Fri, 2012-09-14 at 14:43 +0530, Archit Taneja wrote:
On Friday 14 September 2012 02:23 PM, Tomi Valkeinen wrote:
quoted
On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
quoted
Scaling calculations for an overlay are done by comparing pixel clock of the
connected overlay manager and the core clock of DISPC. The pixel clock is the
output rate of the scalar. The scalar block needs to provide pixels at this rate
since the manager is connected to a panel, which has real time constraints.
In the case of writeback in memory to memory mode, the output of the scalar
blocks aren't connected to a display, and hence there isn't a pixel clock which
causes downscaling limitations.
Make the input to scaling calculations a bit more generic by passing the scalar
output rate rather than passing pixel clock of the overlay manager connected to
the pipeline, as we now have use cases where the scalar's output may not go to
a manager connected to a panel.
Pixel clock is the rate at which pixels are processed. I don't see it
only meaning a clock that's related to actual video signal going out of
OMAP. So if in normal case the scaler outputs pixels at the rate of
pixel clock, we can call it pixel clock with WB's case also, instead of
renaming it to output clock.
Pixel clock, in OMAP DSS terms, is the rate at which the video port of
an overlay manager provides pixels to an output. It is a fixed rate at
which the scaler needs to push out data.
If we stick to this terminology of pixel clock, I don't think it applies
to writeback. As far as I see it, there is no specific rate at which the
scaler outputs data, it adjusts itself based on how much scaling is
done, and at the rate we can get/push data to the interconnect. That's
why I didn't want to call it pixel clock. Because, that sounds a lot
like a fixed rate at which pixels need to be output.
I see your reasoning. I'm a bit reluctant to add a new clock term to
omapdss. You can't (probably) find it in the TRM. Does the TRM talk
about clocks with regard to WB?
I do think pixel clock can be used as well here. While normally used for
output, it's just a clock used for pixels, and at each tick we process
one pixel, which is exactly what happens with WB also.
Also, if I understood right, this pixel clock is not even used for WB,
and in a later patch you just use a dummy value of 1 for the clock for
WB. So even if pixel clock would not be the best name, would it make
sense to use the name of pixel clock, but return 0 as the pck for WB,
implying that pck is not valid/does not exist, and the scaling
restrictions can be skipped for that?
Tomi
On Friday 14 September 2012 03:19 PM, Tomi Valkeinen wrote:
On Fri, 2012-09-14 at 14:43 +0530, Archit Taneja wrote:
quoted
On Friday 14 September 2012 02:23 PM, Tomi Valkeinen wrote:
quoted
On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
quoted
Scaling calculations for an overlay are done by comparing pixel clock of the
connected overlay manager and the core clock of DISPC. The pixel clock is the
output rate of the scalar. The scalar block needs to provide pixels at this rate
since the manager is connected to a panel, which has real time constraints.
In the case of writeback in memory to memory mode, the output of the scalar
blocks aren't connected to a display, and hence there isn't a pixel clock which
causes downscaling limitations.
Make the input to scaling calculations a bit more generic by passing the scalar
output rate rather than passing pixel clock of the overlay manager connected to
the pipeline, as we now have use cases where the scalar's output may not go to
a manager connected to a panel.
Pixel clock is the rate at which pixels are processed. I don't see it
only meaning a clock that's related to actual video signal going out of
OMAP. So if in normal case the scaler outputs pixels at the rate of
pixel clock, we can call it pixel clock with WB's case also, instead of
renaming it to output clock.
Pixel clock, in OMAP DSS terms, is the rate at which the video port of
an overlay manager provides pixels to an output. It is a fixed rate at
which the scaler needs to push out data.
If we stick to this terminology of pixel clock, I don't think it applies
to writeback. As far as I see it, there is no specific rate at which the
scaler outputs data, it adjusts itself based on how much scaling is
done, and at the rate we can get/push data to the interconnect. That's
why I didn't want to call it pixel clock. Because, that sounds a lot
like a fixed rate at which pixels need to be output.
I see your reasoning. I'm a bit reluctant to add a new clock term to
omapdss. You can't (probably) find it in the TRM. Does the TRM talk
about clocks with regard to WB?
Yes, you can't find the word pixel clock linked to WB in the TRM.
I do think pixel clock can be used as well here. While normally used for
output, it's just a clock used for pixels, and at each tick we process
one pixel, which is exactly what happens with WB also.
Also, if I understood right, this pixel clock is not even used for WB,
and in a later patch you just use a dummy value of 1 for the clock for
WB. So even if pixel clock would not be the best name, would it make
sense to use the name of pixel clock, but return 0 as the pck for WB,
implying that pck is not valid/does not exist, and the scaling
restrictions can be skipped for that?
Yes, we could do that. I can check if zero leads to some bad results, or
we could just bypass the scaler clock stuff if the pixel clock is 0.
Archit
From: Tomi Valkeinen <hidden> Date: 2012-09-14 10:18:13
On Fri, 2012-09-14 at 15:33 +0530, Archit Taneja wrote:
On Friday 14 September 2012 03:19 PM, Tomi Valkeinen wrote:
quoted
I see your reasoning. I'm a bit reluctant to add a new clock term to
omapdss. You can't (probably) find it in the TRM. Does the TRM talk
about clocks with regard to WB?
Yes, you can't find the word pixel clock linked to WB in the TRM.
Is there some other term for the clock related to WB?
Yes, we could do that. I can check if zero leads to some bad results, or
we could just bypass the scaler clock stuff if the pixel clock is 0.
I think 0 value would make more sense than a dummy 1. 1 is still a valid
clock, and it could go unnoticed in some other code paths that would use
the function to get the clock.
Of course, the scaler check function could internally check if the pck
is 0, and then use 1 in its calculations, if that makes the function
simpler.
Tomi
On Friday 14 September 2012 01:57 PM, Tomi Valkeinen wrote:
On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
quoted
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".
Yes, my bad, I'll fix this.
quoted
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?
I initially kept all of this the same, but I changed my mind at some
point, not totally sure why. Even if we stick to the dispc_ovl_* names,
we would still need to create q common function which dispc_ovl_setup()
and dispc_wb_setup() could call. I called this dispc_plane_setup(), and
then it felt weird to call everything else ovl specifuic, hence renamed
all of them to dispc_plane_*.
Could you suggest a better name than dispc_plane_setup?
quoted
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.
Currently, we pass the plane id to these low level functions, it
extracts out the ovl struct usingthe plane id, and checks the ovl caps.
What I'm doing now is just passing the caps directly to these low level
functions. So that I don't need to have complicated checks in every
function to extract caps between overlays or writeback.
Archit
On Friday 14 September 2012 02:16 PM, Tomi Valkeinen wrote:
On Fri, 2012-09-14 at 11:27 +0300, Tomi Valkeinen wrote:
quoted
On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
quoted
quoted
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?
And while WB is a combination of overlays and ovl managers, do you think
it'd be difficult to consider WB as a special, extended overlay? So just
call it an overlay, and consider it as an overlay with special features,
at least inside dispc.c. We probably need to have it as a totally
different entity from user's point of view (i.e. the list of overlays
wouldn't return WB, etc).
Yes, we could do that within dispc.c, we would still need some manager
like functions which set GO or ENABLE. But apart from that it should be
okay.
I think for dispc.c in general, for future, it might be a good idea to
represent each piece of HW(like scalar or color converter, or a timing
FSM) as a little function/module, and construct
overlay/writeback/manager out of those, it might be cleaner. However,
this may be an overkill, and not needed much if there aren't any new
blocks comprising of these little blocks.
Archit
From: Tomi Valkeinen <hidden> Date: 2012-09-14 10:53:16
On Fri, 2012-09-14 at 15:43 +0530, Archit Taneja wrote:
On Friday 14 September 2012 01:57 PM, Tomi Valkeinen wrote:
I initially kept all of this the same, but I changed my mind at some
point, not totally sure why. Even if we stick to the dispc_ovl_* names,
we would still need to create q common function which dispc_ovl_setup()
and dispc_wb_setup() could call. I called this dispc_plane_setup(), and
then it felt weird to call everything else ovl specifuic, hence renamed
all of them to dispc_plane_*.
Could you suggest a better name than dispc_plane_setup?
Well... dispc_ovl_setup_common?
The function is also quite big, with huge number of arguments. Makes me
wonder if we could split it up to some sensible parts. Would it be
possible to have functions to setup, say, input related parameters
(base-address, pix format, etc.), output related parameters (ovl
position, ...).
Well, it could just make it more confusing, as some things are shared
between input and output, like scaling related things. But just an idea.
quoted
quoted
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.
Currently, we pass the plane id to these low level functions, it
extracts out the ovl struct usingthe plane id, and checks the ovl caps.
What I'm doing now is just passing the caps directly to these low level
functions. So that I don't need to have complicated checks in every
function to extract caps between overlays or writeback.
Yep, I see. It's ok.
My main dislike is the use of omap_dss_get_overlay() in dispc.c. I'd
like dispc.c to be self-contained, so what I mean is that instead of
initializing the caps in dss_features.c, and calling the above function
in dispc.c, we should have a dispc.c internal table for dispc's HW,
which would contain the caps and other necessary information.
But that's not really related to this series.
Tomi
From: Tomi Valkeinen <hidden> Date: 2012-09-14 10:57:18
On Fri, 2012-09-14 at 15:54 +0530, Archit Taneja wrote:
On Friday 14 September 2012 02:16 PM, Tomi Valkeinen wrote:
quoted
On Fri, 2012-09-14 at 11:27 +0300, Tomi Valkeinen wrote:
quoted
On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
quoted
quoted
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?
And while WB is a combination of overlays and ovl managers, do you think
it'd be difficult to consider WB as a special, extended overlay? So just
call it an overlay, and consider it as an overlay with special features,
at least inside dispc.c. We probably need to have it as a totally
different entity from user's point of view (i.e. the list of overlays
wouldn't return WB, etc).
Yes, we could do that within dispc.c, we would still need some manager
like functions which set GO or ENABLE. But apart from that it should be
okay.
Yep, I was going through the WB registers, and to me it looks like 99%
of them are like overlay regs. Then there are a few bits like GO which
are special.
I think for dispc.c in general, for future, it might be a good idea to
represent each piece of HW(like scalar or color converter, or a timing
Scal_e_r! ;)
FSM) as a little function/module, and construct
overlay/writeback/manager out of those, it might be cleaner. However,
this may be an overkill, and not needed much if there aren't any new
blocks comprising of these little blocks.
I agree. In the minimum we should try to somehow group functions related
to certain block, perhaps with name prefixes etc. I think it'll also
help understanding the code.
We probably currently have functions that touch multiple different
blocks. Those funcs should be split to handle only one of the blocks.
Tomi
This series prepares the low level DISPC driver(dispc.c) to configure writeback
registers. Original series can be seen here:
http://marc.info/?l=linux-fbdev&m4753851619354&w=2
Changes since v2:
- Removed patches which rename dispc_ovl_* functions to dispc_plane_*
- Revisited the scaling related code a bit. Removed the usage of 'output rate'
to fit in writeback. Instead, added a new parameter called mem_to_mem, passed
by APPLY. This tells whether we have to consider a display pixel clock for
scaling limitations or not.
- All 'Scalar' references renamed to 'Scaler'.
- Minor cleanups.
Reference branch:
git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git 1-writeback-dispc
Archit Taneja (18):
OMAPDSS: DISPC: Constify omap_overlay_info in dispc_ovl_setup()
OMAPDSS: DISPC: Simplify function names for setting pipeline input
and output sizes
OMAPDSS: DISPC: Pass overlay caps as a parameter to dispc plane
functions
OMAPDSS: OVERLAY: Add position and replication as overlay caps
OMAPDSS: DISPC: Make dispc_ovl_setup call dispc_ovl_setup_common
OMAPDSS: DISPC: Don't pass channel out when configuring overlays
OMAPDSS: DIPSC: Relax scaling limitations when in memory to memory
mode
OMAPDSS: DISPC: Allow both upscaling and downscaling of chroma
OMAPDSS: DISPC: Add writeback register offsets and dss features
structs
OMAPDSS: DISPC: Configure input and output sizes for writeback
OMAPDSS: DISPC: Downscale chroma if plane is writeback
OMAPDSS: DISPC: Don't set chroma resampling bit for writeback
OMAPDSS: DISPC: Add function to set channel in for writeback
OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup
OMAPDSS: DISPC: Configure writeback specific parameters in
dispc_wb_setup()
OMAPDSS: DISPC: Configure writeback FIFOs
OMAPDSS: DISPC: Add manager like functions for writeback
OMAPDSS: DISPC: Configure color conversion coefficients for writeback
drivers/video/omap2/dss/apply.c | 2 +-
drivers/video/omap2/dss/dispc.c | 561 ++++++++++++++++++++++----------
drivers/video/omap2/dss/dispc.h | 33 ++
drivers/video/omap2/dss/dss.h | 25 +-
drivers/video/omap2/dss/dss_features.c | 57 +++-
drivers/video/omap2/dss/dss_features.h | 1 +
include/video/omapdss.h | 15 +
7 files changed, 510 insertions(+), 184 deletions(-)
--
1.7.9.5
This series prepares the low level DISPC driver(dispc.c) to configure writeback
registers. Original series can be seen here:
http://marc.info/?l=linux-fbdev&m4753851619354&w=2
Changes since v2:
- Removed patches which rename dispc_ovl_* functions to dispc_plane_*
- Revisited the scaling related code a bit. Removed the usage of 'output rate'
to fit in writeback. Instead, added a new parameter called mem_to_mem, passed
by APPLY. This tells whether we have to consider a display pixel clock for
scaling limitations or not.
- All 'Scalar' references renamed to 'Scaler'.
- Minor cleanups.
Reference branch:
git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git 1-writeback-dispc
Archit Taneja (18):
OMAPDSS: DISPC: Constify omap_overlay_info in dispc_ovl_setup()
OMAPDSS: DISPC: Simplify function names for setting pipeline input
and output sizes
OMAPDSS: DISPC: Pass overlay caps as a parameter to dispc plane
functions
OMAPDSS: OVERLAY: Add position and replication as overlay caps
OMAPDSS: DISPC: Make dispc_ovl_setup call dispc_ovl_setup_common
OMAPDSS: DISPC: Don't pass channel out when configuring overlays
OMAPDSS: DIPSC: Relax scaling limitations when in memory to memory
mode
OMAPDSS: DISPC: Allow both upscaling and downscaling of chroma
OMAPDSS: DISPC: Add writeback register offsets and dss features
structs
OMAPDSS: DISPC: Configure input and output sizes for writeback
OMAPDSS: DISPC: Downscale chroma if plane is writeback
OMAPDSS: DISPC: Don't set chroma resampling bit for writeback
OMAPDSS: DISPC: Add function to set channel in for writeback
OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup
OMAPDSS: DISPC: Configure writeback specific parameters in
dispc_wb_setup()
OMAPDSS: DISPC: Configure writeback FIFOs
OMAPDSS: DISPC: Add manager like functions for writeback
OMAPDSS: DISPC: Configure color conversion coefficients for writeback
drivers/video/omap2/dss/apply.c | 2 +-
drivers/video/omap2/dss/dispc.c | 561 ++++++++++++++++++++++----------
drivers/video/omap2/dss/dispc.h | 33 ++
drivers/video/omap2/dss/dss.h | 25 +-
drivers/video/omap2/dss/dss_features.c | 57 +++-
drivers/video/omap2/dss/dss_features.h | 1 +
include/video/omapdss.h | 15 +
7 files changed, 510 insertions(+), 184 deletions(-)
--
1.7.9.5
The struct omap_overlay_info passed to dispc_ovl_setup() is used to configure
DISPC registers. It shouldn't modify the overlay_info structure. The pos_y field
was being changed in dispc_ovl_setup in the case of interlaced displays. Fix
this and const qualifier to the omap_overlay_info argument.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 9 +++++----
drivers/video/omap2/dss/dss.h | 2 +-
2 files changed, 6 insertions(+), 5 deletions(-)
The DISPC pipeline register names in the TRM for setting the buffer size and
the output size are a bit misleading, for example, there are different register
names for setting the buffer size for VID and GFX pipes. Things get more
confusing when considering writeback pipeline.
Rename the functions so that they tell whether they are configuring the input
to the scalar or the output. These will be extended later to support writeback
registers.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
Currently, the functions below take the omap_plane parameter and derive the
overlay caps within them. Pass the overlay caps as a parameter to the function
to allow these to be used by writeback too.
- dispc_ovl_set_zorder()
- dispc_ovl_set_pre_mult_alpha()
- dispc_ovl_setup_global_alpha()
- dispc_ovl_calc_scaling()
- dispc_ovl_setup()
These functions will be used for writeback later, and the caps will help in
deciding if they are to be used for writeback or not. This allows reuse of
overlay caps for writeback.
Using omap_overlay_caps for writeback seems a bit incorrect, but caps is
something already in use by users of OMAPDSS(omapfb/omap_vout), so we use
overlay caps for overlay like features of writeback too.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 41 +++++++++++++++++++--------------------
1 file changed, 20 insertions(+), 21 deletions(-)
Add position and replication as overlay caps, and pass overlay caps as an
argument to the corresponding functions. Adding position and replication to
overlay caps seems a bit unnecessary, but it allows us to use the
corresponding functions for writeback too.
These caps will be set for all overlays, but not for writeback. This is done
so writeback can reuse dispc_ovl_setup() to the maximum.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 20 ++++++++++++-----
drivers/video/omap2/dss/dss_features.c | 38 +++++++++++++++++++++-----------
include/video/omapdss.h | 2 ++
3 files changed, 42 insertions(+), 18 deletions(-)
Add a new static function called dispc_ovl_setup_common(). This function is used by
dispc_ovl_setup() to configure the overlay registers. This split is done so that
dispc_wb_setup() can reuse overlay register configuration related code.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 128 ++++++++++++++++++++++-----------------
1 file changed, 71 insertions(+), 57 deletions(-)
dispc_ovl_setup_common() is to be used by both overlays and writeback. We pass
channel out to figure out what manager the overlay is connected to, to determine
the pixel clock rate. This is used to decide the scaling limitations for that
overlay.
writeback doesn't have a channel out, it has a channel in field which tells
where writeback gets its input from. These are 2 different fields, and this
prevents us reusing the overlay configuration code for writeback.
To overcome this, we now pass omap_plane to overlay related functions rather
than passing channel out. We create helper functions which can derive pclk/lclk
from the omap_plane id.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 115 ++++++++++++++++++++++-----------------
1 file changed, 66 insertions(+), 49 deletions(-)
The scalers of overlays and writeback do not have any constraints on downscale
ratio when operating in memory to memory mode.
This is because in memory to memory mode, we aren't connected to a display which
needs data output at the rate of pixel clock. The scalers can perform as much
downscaling as needed, the rate at which the scaler outputs is adjusted
accordingly.
Relax constraints related to downscaling based on whether the input overlays are
connected to writeback in memory to memory mode. We pass a mem_to_mem boolean
parameter to dispc_ovl_setup() from APPLY. This is currently set to false, this
will later be configured to the correct value based on whether the overlay is
connected to writeback or not. Do the same later for writeback when writeback is
configured.
In the scaling calculation code, we calculate the minimum amount of core clock we
need to achieve the required downscaling. If we are in memory to memory mode, we
set this to a very small value(1 in this case), this value would always be
lesser than the actual DISPC core clock value, and hence the scaling checks
would succeed.
We take care that pixel clock isn't calculated for writeback and the overlays
connected to it when in memory to memory mode. A pixel clock in such cases
doesn't make sense.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/apply.c | 2 +-
drivers/video/omap2/dss/dispc.c | 60 ++++++++++++++++++++++++++-------------
drivers/video/omap2/dss/dss.h | 3 +-
3 files changed, 44 insertions(+), 21 deletions(-)
In the function dispc_plane_set_scaling_uv(), create a parameter which tells if
we want to upscale or downscale the chroma plane.
Downscaling of chroma is required by writeback pipeline for converting the input
YUV444 color format to YUV422 or NV12.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 32 ++++++++++++++++++++++----------
1 file changed, 22 insertions(+), 10 deletions(-)
@@ -1473,23 +1474,34 @@ static void dispc_ovl_set_scaling_uv(enum omap_plane plane,switch(color_mode){caseOMAP_DSS_COLOR_NV12:-/* UV is subsampled by 2 vertically*/-orig_height>>=1;-/* UV is subsampled by 2 horz.*/-orig_width>>=1;+if(chroma_upscale){+/* UV is subsampled by 2 horizontally and vertically */+orig_height>>=1;+orig_width>>=1;+}else{+/* UV is downsampled by 2 horizontally and vertically */+orig_height<<=1;+orig_width<<=1;+}+break;caseOMAP_DSS_COLOR_YUV2:caseOMAP_DSS_COLOR_UYVY:-/*For YUV422 with 90/270 rotation,-*wedon'tupsamplechroma-*/+/* For YUV422 with 90/270 rotation, we don't upsample chroma */if(rotation=OMAP_DSS_ROT_0||-rotation=OMAP_DSS_ROT_180)-/* UV is subsampled by 2 hrz*/-orig_width>>=1;+rotation=OMAP_DSS_ROT_180){+if(chroma_upscale)+/* UV is subsampled by 2 horizontally */+orig_width>>=1;+else+/* UV is downsampled by 2 horizontally */+orig_width<<=1;+}+/* must use FIR for YUV422 if rotated */if(rotation!=OMAP_DSS_ROT_0)scale_x=scale_y=true;+break;default:BUG();
Since writeback has many overlay like properties, and most of it's registers are
similar to that of overlays, it's possible to reuse most of the overlay related
DISPC code for writeback when considering it as a plane. Writeback was added as
a plane in the omap_plane field as OMAP_DSS_WB.
Add the writeback register offsets in dispc.h, add minimal WB plane related info
needed in dss_features. Add a function which returns the number of writeback
pipelines an OMAP version has.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.h | 33 ++++++++++++++++++++++++++++++++
drivers/video/omap2/dss/dss_features.c | 19 ++++++++++++++++++
drivers/video/omap2/dss/dss_features.h | 1 +
3 files changed, 53 insertions(+)
Writeback uses the WB_PICTURE_SIZE register to define the size of the content
written to memory, this is the output of the scaler. It uses the WB_SIZE
register to define the size of the content coming from the overlay/manager to
which it is connected, this is the input to the scaler. This naming is different
as compared to overlays.
Add checks for writeback in dispc_ovl_set_input_size() and
dispc_ovl_set_output_size() to write to the correct registers.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
When converting YUYV444 content to YUV422 or NV12 formats through writeback
pipeline, the scaler needs to downscale the chroma plane. Ensure that chroma
is downscaled when the pipeline is writeback.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The bit YUVCHROMARESAMPLING isn't there for writeback in DISPC_WB_ATTRIBUTES2.
It isn't there because we don't upsample chroma like for video pipelines, we
downsample chroma in writeback to get YUV422 or NV12 formats from the YUV444
input.
Ignore this bit in dispc_ovl_set_scaling_uv() if the plane is OMAP_DSS_WB.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
@@ -1520,8 +1521,10 @@ static void dispc_ovl_set_scaling_uv(enum omap_plane plane,out_width,out_height,five_taps,rotation,DISPC_COLOR_COMPONENT_UV);-REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane),-(scale_x||scale_y)?1:0,8,8);+if(plane!=OMAP_DSS_WB)+REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane),+(scale_x||scale_y)?1:0,8,8);+/* set H scaling */REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane),scale_x?1:0,5,5);/* set V scaling */
Writeback can take input from either one of the overlays, or one of the overlay
managers. Add an enum which represents the channel_in for writeback, and maps
to the register field programming.
Add a function to configure channel in for writeback. This will be used later in
APPLY.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 7 +++++++
drivers/video/omap2/dss/dss.h | 13 +++++++++++++
2 files changed, 20 insertions(+)
@@ -113,6 +113,17 @@ enum dss_dsi_content_type {DSS_DSI_CONTENT_GENERIC,};+enumdss_writeback_channel{+DSS_WB_LCD1_MGR=0,+DSS_WB_LCD2_MGR=1,+DSS_WB_TV_MGR=2,+DSS_WB_OVL0=3,+DSS_WB_OVL1=4,+DSS_WB_OVL2=5,+DSS_WB_OVL3=6,+DSS_WB_LCD3_MGR=7,+};+structdss_clock_info{/* rates that we get with dividers below */unsignedlongfck;
Create struct omap_dss_writeback_info, this is similar to omap_overlay_info,
the major difference is that there is no parameter which describes the input
size to writeback, this is because this is always fixed, and decided by the
connected overlay or overlay manager. One more difference is that screen_width
is renamed to buf_width, to give the value of stride the writeback buffer has.
Call dispc_ovl_setup_common() through dispc_wb_setup() to configure overlay-like
parameters. The parameters in dispc_ovl_setup_common() which do not hold for
writeback are filled passed as zeroes or false, the code takes care of not
configuring them as they won't possess the needed overlay caps.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 27 +++++++++++++++++++++++++++
drivers/video/omap2/dss/dss.h | 2 ++
include/video/omapdss.h | 13 +++++++++++++
3 files changed, 42 insertions(+)
Configure some of the writeback specific parameters in dispc_wb_setup(). The
writeback parameters configured are:
truncation: This needs to be set if the color depth input to writeback is more
than the color depth of the color mode we want to store in memory.
writeback mode: This configures whether we want to use writeback in mem to mem
or capture mode. This information will be directly passed by APPLY later.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 28 ++++++++++++++++++++++++++--
drivers/video/omap2/dss/dss.h | 2 +-
2 files changed, 27 insertions(+), 3 deletions(-)
Extend the DISPC fifo functions to also configure the writeback FIFO thresholds.
The most optimal configuration for writeback is to push out data to the
interconnect the moment writeback pushes enough pixels in the FIFO to form a
burst. This reduces the chance of writeback overflowing it's FIFO.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
Add functions to enable writeback, and set/check state of GO bit. These bits are
identical in behaviour with the corresponding overlay manager bits. Configure
them in a similar way to mgr_enable() and mgr_go_* functions. Add a helper to
get the FRAMEDONE irq corresponding to writeback.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 70 +++++++++++++++++++++++++++++++++++++++
drivers/video/omap2/dss/dss.h | 5 +++
2 files changed, 75 insertions(+)
@@ -563,6 +568,30 @@ void dispc_mgr_go(enum omap_channel channel)mgr_fld_write(channel,DISPC_MGR_FLD_GO,1);}+booldispc_wb_go_busy(void)+{+returnREG_GET(DISPC_CONTROL2,6,6)=1;+}++voiddispc_wb_go(void)+{+enumomap_planeplane=OMAP_DSS_WB;+boolenable,go;++enable=REG_GET(DISPC_OVL_ATTRIBUTES(plane),0,0)=1;++if(!enable)+return;++go=REG_GET(DISPC_CONTROL2,6,6)=1;+if(go){+DSSERR("GO bit not down for WB\n");+return;+}++REG_FLD_MOD(DISPC_CONTROL2,1,6,6);+}+staticvoiddispc_ovl_write_firh_reg(enumomap_planeplane,intreg,u32value){dispc_write_reg(DISPC_OVL_FIR_COEF_H(plane,reg),value);
@@ -2690,6 +2719,47 @@ void dispc_mgr_enable(enum omap_channel channel, bool enable)BUG();}+voiddispc_wb_enable(boolenable)+{+enumomap_planeplane=OMAP_DSS_WB;+structcompletionframe_done_completion;+boolis_on;+intr;+u32irq;++is_on=REG_GET(DISPC_OVL_ATTRIBUTES(plane),0,0);+irq=DISPC_IRQ_FRAMEDONEWB;++if(!enable&&is_on){+init_completion(&frame_done_completion);++r=omap_dispc_register_isr(dispc_disable_isr,+&frame_done_completion,irq);+if(r)+DSSERR("failed to register FRAMEDONEWB isr\n");+}++REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane),enable?1:0,0,0);++if(!enable&&is_on){+if(!wait_for_completion_timeout(&frame_done_completion,+msecs_to_jiffies(100)))+DSSERR("timeout waiting for FRAMEDONEWB\n");++r=omap_dispc_unregister_isr(dispc_disable_isr,+&frame_done_completion,irq);+if(r)+DSSERR("failed to unregister FRAMEDONEWB isr\n");+}+}++booldispc_wb_is_enabled(void)+{+enumomap_planeplane=OMAP_DSS_WB;++returnREG_GET(DISPC_OVL_ATTRIBUTES(plane),0,0);+}+voiddispc_lcd_enable_signal_polarity(boolact_high){if(!dss_has_feature(FEAT_LCDENABLEPOL))
Writeback pipeline receives RGB data from one of the overlays or one of the
overlay managers. If the target color mode is YUV422 or NV12, we need to convert
the RGB pixels to YUV. The scaler in WB then converts it to the target color
mode.
Hence, the color conversion coefficients that need to be programmed are the ones
which convert a RGB24 pixel to YUV444. Program these coefficients for writeback
pipeline.
Rearrange the code a bit to configure different coefficients for overlays and
writeback.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 61 +++++++++++++++++++++------------------
1 file changed, 33 insertions(+), 28 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2012-09-25 14:33:15
On Tue, 2012-09-25 at 11:49 +0530, Archit Taneja wrote:
quoted hunk
Writeback uses the WB_PICTURE_SIZE register to define the size of the content
written to memory, this is the output of the scaler. It uses the WB_SIZE
register to define the size of the content coming from the overlay/manager to
which it is connected, this is the input to the scaler. This naming is different
as compared to overlays.
Add checks for writeback in dispc_ovl_set_input_size() and
dispc_ovl_set_output_size() to write to the correct registers.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Should we just rename the dispc registers to DISPC_OVL_IN_SIZE and
DISPC_OVL_OUT_SIZE, and then we could do without the ifs? The registers
have always confused me a bit, I don't know why they are named so in the
TRM.
Tomi
From: Tomi Valkeinen <hidden> Date: 2012-09-25 14:50:52
On Tue, 2012-09-25 at 11:49 +0530, Archit Taneja wrote:
Extend the DISPC fifo functions to also configure the writeback FIFO thresholds.
The most optimal configuration for writeback is to push out data to the
interconnect the moment writeback pushes enough pixels in the FIFO to form a
burst. This reduces the chance of writeback overflowing it's FIFO.
Hmm, why is this optimal?
The FIFO for WB is the output fifo, right? In mem-to-mem mode the whole
WB pipeline can stall, so the fifo can't overflow? If so, isn't it
better to collect more data and flush all that to the memory, instead of
sending each burst-size piece one by one?
Then again, if the input side is reading pixels from the memory all the
time, even if the output fifo helps to keep the output side idle for
longer periods, it probably doesn't help as the input side keeps the
memory bus awake.
Tomi
On Tuesday 25 September 2012 08:20 PM, Tomi Valkeinen wrote:
On Tue, 2012-09-25 at 11:49 +0530, Archit Taneja wrote:
quoted
Extend the DISPC fifo functions to also configure the writeback FIFO thresholds.
The most optimal configuration for writeback is to push out data to the
interconnect the moment writeback pushes enough pixels in the FIFO to form a
burst. This reduces the chance of writeback overflowing it's FIFO.
Hmm, why is this optimal?
The FIFO for WB is the output fifo, right? In mem-to-mem mode the whole
WB pipeline can stall, so the fifo can't overflow? If so, isn't it
better to collect more data and flush all that to the memory, instead of
sending each burst-size piece one by one?
I guess this configuration is optimal for capture mode. Where the input
side will push out data at the rate of pixel clock, and writeback has to
collect this data and flush to memory. Writeback can't stall here.
About writeback FIFO overflowing in mem-to-mem mode, I'm not totally
sure about this. But what you are saying seems valid, writeback would
stall the input. So it should be safe to accumulate content in the FIFO,
and push out large number of bursts together.
Then again, if the input side is reading pixels from the memory all the
time, even if the output fifo helps to keep the output side idle for
longer periods, it probably doesn't help as the input side keeps the
memory bus awake.
Maybe if the FIFOs are adjusted such that reading of the pixels from
input side and writeback flushing out can be done at the same time, then
we might idle the memory bus more. I don't know if this is possible though.
Archit
On Tuesday 25 September 2012 08:03 PM, Tomi Valkeinen wrote:
On Tue, 2012-09-25 at 11:49 +0530, Archit Taneja wrote:
quoted
Writeback uses the WB_PICTURE_SIZE register to define the size of the content
written to memory, this is the output of the scaler. It uses the WB_SIZE
register to define the size of the content coming from the overlay/manager to
which it is connected, this is the input to the scaler. This naming is different
as compared to overlays.
Add checks for writeback in dispc_ovl_set_input_size() and
dispc_ovl_set_output_size() to write to the correct registers.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Should we just rename the dispc registers to DISPC_OVL_IN_SIZE and
DISPC_OVL_OUT_SIZE, and then we could do without the ifs? The registers
have always confused me a bit, I don't know why they are named so in the
TRM.
It'll be hard for someone who's referring to the TRM in that case. It'll
also be hard to track reg dumps if these names change. I think we should
stick to the TRM names only.
Archit
From: Tomi Valkeinen <hidden> Date: 2012-09-26 06:34:49
On Wed, 2012-09-26 at 11:52 +0530, Archit Taneja wrote:
On Tuesday 25 September 2012 08:03 PM, Tomi Valkeinen wrote:
quoted
On Tue, 2012-09-25 at 11:49 +0530, Archit Taneja wrote:
quoted
Writeback uses the WB_PICTURE_SIZE register to define the size of the content
written to memory, this is the output of the scaler. It uses the WB_SIZE
register to define the size of the content coming from the overlay/manager to
which it is connected, this is the input to the scaler. This naming is different
as compared to overlays.
Add checks for writeback in dispc_ovl_set_input_size() and
dispc_ovl_set_output_size() to write to the correct registers.
Signed-off-by: Archit Taneja <redacted>
---
drivers/video/omap2/dss/dispc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Should we just rename the dispc registers to DISPC_OVL_IN_SIZE and
DISPC_OVL_OUT_SIZE, and then we could do without the ifs? The registers
have always confused me a bit, I don't know why they are named so in the
TRM.
It'll be hard for someone who's referring to the TRM in that case. It'll
also be hard to track reg dumps if these names change. I think we should
stick to the TRM names only.
Generally speaking I agree.
However, with each new OMAP we get register name changes. We already
have at least a few of those, and I think it'll just get worse. So at
some point we'll have a mishmash of register names from different omap
versions, or we'll rename the registers according to one particular omap
version (probably the latest one), or we'll name the registers as seems
best for the driver.
But yes, perhaps it's still best to keep the reg names as they are.
Perhaps there's even a logic with the names, I just can't see it =).
Tomi