* Re: [GIT PULL] fbdev changes for 3.8
From: Felipe Balbi @ 2012-12-17 10:05 UTC (permalink / raw)
To: Tony Lindgren
Cc: Dave Jones, Linus Torvalds, Tomi Valkeinen, linux-omap,
linux-fbdev, linux-kernel, Florian Tobias Schandinat,
Dmitry Torokhov, Felipe Balbi, Evgeniy Polyakov, Arnd Bergmann
In-Reply-To: <20121216203536.GR4989@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 4094 bytes --]
Hi,
On Sun, Dec 16, 2012 at 12:35:37PM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [121216 09:49]:
> > * Dave Jones <davej@redhat.com> [121215 14:27]:
> > > On Sat, Dec 15, 2012 at 01:11:04PM -0800, Linus Torvalds wrote:
> > > > On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > > > > Hi Linus,
> > > > >
> > > > > Florian, the fbdev maintainer, has been very busy lately, so I offered to send
> > > > > the pull request for fbdev for this merge window.
> > > >
> > > > Pulled. However, with this I get the Kconfig question
> > > >
> > > > OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW)
> > > >
> > > > which doesn't make a whole lot of sense on x86-64, unless there's
> > > > something about OMAP2 that I don't know.
> > > >
> > > > So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at
> > > > least ARM. Because showing it to anybody else seems insane.
> > > >
> > > > Same goes for FB_OMAP2 for that matter. I realize that it's likely
> > > > nice to get compile testing for this on x86-64 too, but if that's the
> > > > intent, we need to think about it some more. I don't think it's good
> > > > to ask actual normal users questions like this just for compile
> > > > coverage.
> > >
> > > This OMAP stuff has been creeping into x86 builds for a while.
> > > Grep from my current build config ..
> > >
> > > # CONFIG_OMAP_OCP2SCP is not set
> > > # CONFIG_KEYBOARD_OMAP4 is not set
> > > # CONFIG_OMAP2_DSS is not set
> > > # CONFIG_OMAP_USB2 is not set
> > >
> > > There was some other arm-ism that does the same that I' currently forgetting,
> > > or maybe that got fixed..
> >
> > Those are all omap internal devices and should be all marked with
> > depends on ARCH_OMAP2PLUS.
> >
> > It's a different story for external devices that may be used on other
> > architectures.
> >
> > I only came up with one reason to compile internal devices for other
> > architectures: In some cases the driver subsystem maintainer may want to
> > be able to compile test subsystem wide changes without having to compile
> > for each target separately. But for those cases it's trivial to carry a
> > compile test patch that just drops the depends Kconfig entries.
>
> And here's a patch to limit the omap drivers above to omap only.
>
> Regards,
>
> Tony
>
>
> From: Tony Lindgren <tony@atomide.com>
> Date: Sun, 16 Dec 2012 12:28:46 -0800
> Subject: [PATCH] ARM: OMAP: Fix drivers to depend on omap for internal devices
>
> These devices are not available on other architectures, so
> let's limit them to omap.
>
> If the driver subsystem maintainers want to build test
> system wide changes without building for each target,
> it's easy to carry a test patch that just strips out the
> depends entries from Kconfig files.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -6,6 +6,7 @@ menu "Bus devices"
>
> config OMAP_OCP2SCP
> tristate "OMAP OCP2SCP DRIVER"
> + depends on ARCH_OMAP2PLUS
> help
> Driver to enable ocp2scp module which transforms ocp interface
> protocol to scp protocol. In OMAP4, USB PHY is connected via
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -544,6 +544,7 @@ config KEYBOARD_OMAP
>
> config KEYBOARD_OMAP4
> tristate "TI OMAP4+ keypad support"
> + depends on ARCH_OMAP2PLUS
> select INPUT_MATRIXKMAP
> help
> Say Y here if you want to use the OMAP4+ keypad.
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -6,6 +6,7 @@ comment "USB Physical Layer drivers"
>
> config OMAP_USB2
> tristate "OMAP USB2 PHY Driver"
> + depends on ARCH_OMAP2PLUS
> select USB_OTG_UTILS
> help
> Enable this to support the transceiver that is part of SOC. This
for Keypad, PHY and OCP2SCP I would rather not as I want to use
linux-next for compile testing our stuff in all arches.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 1/2] smscufx: ensure framebuffer is byte-swapped to LE
From: Steve Glendinning @ 2012-12-17 11:24 UTC (permalink / raw)
To: linux-fbdev
This patch fixes the smscufx driver on big endian platforms, by
ensuring the framebuffer is correctly byte-swapped before sending
to the device.
Register and control words were already correctly swapped, so
without this patch the device "works" but with obviously incorrect
RGB values displayed on the output device.
This is implemented as an ifdef so platforms that don't require
byte swapping can use the faster memcpy method.
Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
---
drivers/video/smscufx.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c
index 97bd662..8009400 100644
--- a/drivers/video/smscufx.c
+++ b/drivers/video/smscufx.c
@@ -840,8 +840,16 @@ static void ufx_raw_rect(struct ufx_data *dev, u16 *cmd, int x, int y,
for (line = 0; line < height; line++) {
const int line_offset = dev->info->fix.line_length * (y + line);
const int byte_offset = line_offset + (x * BPP);
- memcpy(&cmd[(24 + (packed_line_len * line)) / 2],
- (char *)dev->info->fix.smem_start + byte_offset, width * BPP);
+ const int cmd_base = (24 + (packed_line_len * line)) / 2;
+ const u16 *source = (u16 *)((char *)dev->info->fix.smem_start + byte_offset);
+ u16 *dest = (u16 *)(&cmd[cmd_base]);
+#ifdef __BIG_ENDIAN
+ int pixel;
+ for (pixel = 0; pixel < width; pixel++)
+ dest[pixel] = cpu_to_le16(source[pixel]);
+#else /* __BIG_ENDIAN */
+ memcpy(dest, source, width * BPP);
+#endif /* __BIG_ENDIAN */
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] smscufx: fix EDID parsing on big-endian systems
From: Steve Glendinning @ 2012-12-17 11:24 UTC (permalink / raw)
To: linux-fbdev
This patch allows smscufx to correctly detect the resolution of a
connected monitor on big-endian systems.
Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
---
drivers/video/smscufx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c
index 8009400..bdf7d36 100644
--- a/drivers/video/smscufx.c
+++ b/drivers/video/smscufx.c
@@ -1465,8 +1465,9 @@ static int ufx_read_edid(struct ufx_data *dev, u8 *edid, int edid_len)
for (j = 0; j < 16; j++) {
u32 data_reg_addr = 0x1110 + (j * 4);
- status = ufx_reg_read(dev, data_reg_addr, edid_u32++);
+ status = ufx_reg_read(dev, data_reg_addr, &temp);
check_warn_return(status, "Error reading i2c data");
+ *edid_u32++ = cpu_to_le32(temp);
}
}
--
1.7.10.4
^ permalink raw reply related
* Re: [patch] OMAPDSS: reading past end of array in dispc_dump_regs()
From: Tomi Valkeinen @ 2012-12-17 12:09 UTC (permalink / raw)
To: Dan Carpenter, Archit Taneja
Cc: Florian Tobias Schandinat, Chandrabhanu Mahapatra, linux-omap,
linux-fbdev, kernel-janitors
In-Reply-To: <20121214150133.GB15839@elgon.mountain>
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
On 2012-12-14 17:01, Dan Carpenter wrote:
> We added another kind of plane in 66a0f9e4ac "OMAPDSS: Use WB fifo for
> GFX overlay" so this array needs a new entry as well.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> Static checker work. I don't have a way to test this.
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index fedbd2c..bfe62cc 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -3163,6 +3163,7 @@ static void dispc_dump_regs(struct seq_file *s)
> [OMAP_DSS_VIDEO1] = "VID1",
> [OMAP_DSS_VIDEO2] = "VID2",
> [OMAP_DSS_VIDEO3] = "VID3",
> + [OMAP_DSS_WB] = "WB",
> };
> const char **p_names;
>
>
We don't count WB as an overlay currently, as it's handled a bit
differently, so we never try to access that array with OMAP_DSS_WB. We
don't actually dump any WB related registers currently, it seems.
So I think I'll leave this out for now.
Why does the static checker think OMAP_DSS_WB is needed in the array? I
wonder if I'm reading the code wrong, and we indeed do access the array
with OMAP_DSS_WB...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH V2 4/6] OMAPDSS: DSI: Move DSI specific reg_fields to dsi_feats
From: Tomi Valkeinen @ 2012-12-17 12:23 UTC (permalink / raw)
To: Chandrabhanu Mahapatra; +Cc: linux-omap, linux-fbdev
In-Reply-To: <55965d940f45ecaf56f5145d7dcc8c28e4c9586f.1354702077.git.cmahapatra@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]
Hi,
On 2012-12-05 12:16, Chandrabhanu Mahapatra wrote:
> The DSI specific dss_reg_fields are moved to corresponding dsi_reg_fields
> initialized in dsi_feats. The dsi_feats structure is initialized as per
> corresponding DSS version in dsi_init_features().
>
> Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
> ---
> drivers/video/omap2/dss/dsi.c | 126 +++++++++++++++++++++++++++++---
> drivers/video/omap2/dss/dss_features.c | 16 ----
> drivers/video/omap2/dss/dss_features.h | 4 -
> 3 files changed, 114 insertions(+), 32 deletions(-)
>
> +static int __init dsi_init_features(struct platform_device *dsidev)
> +{
> + const struct feats *src;
> + struct feats *dst;
> +
> + dst = devm_kzalloc(&dsidev->dev, sizeof(*dst), GFP_KERNEL);
> + if (!dst) {
> + dev_err(&dsidev->dev, "Failed to allocate DISPC Features\n");
> + return -ENOMEM;
> + }
> +
> + switch (omapdss_get_version()) {
> + case OMAPDSS_VER_OMAP24xx:
> + src = &omap24xx_dsi_feats;
> + break;
> +
> + case OMAPDSS_VER_OMAP34xx_ES1:
> + case OMAPDSS_VER_OMAP34xx_ES3:
> + case OMAPDSS_VER_OMAP3630:
> + case OMAPDSS_VER_AM35xx:
> + src = &omap34xx_dsi_feats;
> + break;
> +
> + case OMAPDSS_VER_OMAP4430_ES1:
> + case OMAPDSS_VER_OMAP4430_ES2:
> + case OMAPDSS_VER_OMAP4:
> + src = &omap44xx_dsi_feats;
> + break;
> +
> + case OMAPDSS_VER_OMAP5:
> + src = &omap54xx_dsi_feats;
> + break;
> +
> + default:
> + return -ENODEV;
> + }
There's no DSI on OMAP2, so that case can be left out.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH V2 2/6] OMAPDSS: DISPC: Move DISPC specific dss_reg_fields to dispc_features
From: Tomi Valkeinen @ 2012-12-17 12:37 UTC (permalink / raw)
To: Chandrabhanu Mahapatra; +Cc: linux-omap, linux-fbdev
In-Reply-To: <08d6240ab26427a9e437421c2cc76ade29036817.1354702077.git.cmahapatra@ti.com>
[-- Attachment #1: Type: text/plain, Size: 10254 bytes --]
On 2012-12-05 12:16, Chandrabhanu Mahapatra wrote:
> The register fields in dss_reg_fields specific to DISPC are moved from struct
> omap_dss_features to corresponding dispc_reg_fields, initialized in struct
> dispc_features, thereby enabling local access.
>
> Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
> ---
> drivers/video/omap2/dss/dispc.c | 114 ++++++++++++++++++++++++--------
> drivers/video/omap2/dss/dss.h | 4 ++
> drivers/video/omap2/dss/dss_features.c | 28 --------
> drivers/video/omap2/dss/dss_features.h | 7 --
> 4 files changed, 89 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index bbba83f..ee4b152 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -80,6 +80,16 @@ struct dispc_irq_stats {
> unsigned irqs[32];
> };
>
> +struct dispc_reg_fields {
> + struct omapdss_reg_field firhinc;
> + struct omapdss_reg_field firvinc;
> + struct omapdss_reg_field fifo_low_thresh;
> + struct omapdss_reg_field fifo_high_thresh;
> + struct omapdss_reg_field fifosize;
> + struct omapdss_reg_field hori_accu;
> + struct omapdss_reg_field vert_accu;
> +};
> +
> struct dispc_features {
> u8 sw_start;
> u8 fp_start;
> @@ -110,6 +120,8 @@ struct dispc_features {
>
> u32 buffer_size_unit; /* in bytes */
> u32 burst_size_unit; /* in bytes */
> +
> + struct dispc_reg_fields *reg_fields;
This can be pointer to const.
> };
>
> #define DISPC_MAX_NR_FIFOS 5
> @@ -1137,17 +1149,17 @@ static void dispc_mgr_set_size(enum omap_channel channel, u16 width,
>
> static void dispc_init_fifos(void)
> {
> - u32 size;
> + u32 size, unit;
> int fifo;
> - u8 start, end;
> - u32 unit;
> + const struct omapdss_reg_field *fifo_field;
>
> unit = dispc.feat->buffer_size_unit;
>
> - dss_feat_get_reg_field(FEAT_REG_FIFOSIZE, &start, &end);
> + fifo_field = &dispc.feat->reg_fields->fifosize;
>
> for (fifo = 0; fifo < dispc.feat->num_fifos; ++fifo) {
> - size = REG_GET(DISPC_OVL_FIFO_SIZE_STATUS(fifo), start, end);
> + size = REG_GET(DISPC_OVL_FIFO_SIZE_STATUS(fifo),
> + fifo_field->start, fifo_field->end);
> size *= unit;
> dispc.fifo_size[fifo] = size;
>
> @@ -1197,8 +1209,8 @@ static u32 dispc_ovl_get_fifo_size(enum omap_plane plane)
>
> void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high)
> {
> - u8 hi_start, hi_end, lo_start, lo_end;
> u32 unit;
> + const struct omapdss_reg_field *hi_field, *lo_field;
>
> unit = dispc.feat->buffer_size_unit;
>
> @@ -1208,20 +1220,20 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high)
> low /= unit;
> high /= unit;
>
> - dss_feat_get_reg_field(FEAT_REG_FIFOHIGHTHRESHOLD, &hi_start, &hi_end);
> - dss_feat_get_reg_field(FEAT_REG_FIFOLOWTHRESHOLD, &lo_start, &lo_end);
> + hi_field = &dispc.feat->reg_fields->fifo_high_thresh;
> + lo_field = &dispc.feat->reg_fields->fifo_low_thresh;
>
> DSSDBG("fifo(%d) threshold (bytes), old %u/%u, new %u/%u\n",
> plane,
> REG_GET(DISPC_OVL_FIFO_THRESHOLD(plane),
> - lo_start, lo_end) * unit,
> + lo_field->start, lo_field->end) * unit,
> REG_GET(DISPC_OVL_FIFO_THRESHOLD(plane),
> - hi_start, hi_end) * unit,
> + hi_field->start, hi_field->end) * unit,
> low * unit, high * unit);
>
> dispc_write_reg(DISPC_OVL_FIFO_THRESHOLD(plane),
> - FLD_VAL(high, hi_start, hi_end) |
> - FLD_VAL(low, lo_start, lo_end));
> + FLD_VAL(high, hi_field->start, hi_field->end) |
> + FLD_VAL(low, lo_field->start, lo_field->end));
> }
>
> void dispc_enable_fifomerge(bool enable)
> @@ -1289,14 +1301,13 @@ static void dispc_ovl_set_fir(enum omap_plane plane,
> u32 val;
>
> if (color_comp == DISPC_COLOR_COMPONENT_RGB_Y) {
> - u8 hinc_start, hinc_end, vinc_start, vinc_end;
> + const struct omapdss_reg_field *hinc_field, *vinc_field;
>
> - dss_feat_get_reg_field(FEAT_REG_FIRHINC,
> - &hinc_start, &hinc_end);
> - dss_feat_get_reg_field(FEAT_REG_FIRVINC,
> - &vinc_start, &vinc_end);
> - val = FLD_VAL(vinc, vinc_start, vinc_end) |
> - FLD_VAL(hinc, hinc_start, hinc_end);
> + hinc_field = &dispc.feat->reg_fields->firhinc;
> + vinc_field = &dispc.feat->reg_fields->firvinc;
> +
> + val = FLD_VAL(vinc, vinc_field->start, vinc_field->end) |
> + FLD_VAL(hinc, hinc_field->start, hinc_field->end);
>
> dispc_write_reg(DISPC_OVL_FIR(plane), val);
> } else {
> @@ -1308,13 +1319,13 @@ static void dispc_ovl_set_fir(enum omap_plane plane,
> static void dispc_ovl_set_vid_accu0(enum omap_plane plane, int haccu, int vaccu)
> {
> u32 val;
> - u8 hor_start, hor_end, vert_start, vert_end;
> + const struct omapdss_reg_field *haccu_field, *vaccu_field;
>
> - dss_feat_get_reg_field(FEAT_REG_HORIZONTALACCU, &hor_start, &hor_end);
> - dss_feat_get_reg_field(FEAT_REG_VERTICALACCU, &vert_start, &vert_end);
> + haccu_field = &dispc.feat->reg_fields->hori_accu;
> + vaccu_field = &dispc.feat->reg_fields->vert_accu;
>
> - val = FLD_VAL(vaccu, vert_start, vert_end) |
> - FLD_VAL(haccu, hor_start, hor_end);
> + val = FLD_VAL(vaccu, vaccu_field->start, vaccu_field->end) |
> + FLD_VAL(haccu, haccu_field->start, haccu_field->end);
>
> dispc_write_reg(DISPC_OVL_ACCU0(plane), val);
> }
> @@ -1322,13 +1333,13 @@ static void dispc_ovl_set_vid_accu0(enum omap_plane plane, int haccu, int vaccu)
> static void dispc_ovl_set_vid_accu1(enum omap_plane plane, int haccu, int vaccu)
> {
> u32 val;
> - u8 hor_start, hor_end, vert_start, vert_end;
> + const struct omapdss_reg_field *haccu_field, *vaccu_field;
>
> - dss_feat_get_reg_field(FEAT_REG_HORIZONTALACCU, &hor_start, &hor_end);
> - dss_feat_get_reg_field(FEAT_REG_VERTICALACCU, &vert_start, &vert_end);
> + haccu_field = &dispc.feat->reg_fields->hori_accu;
> + vaccu_field = &dispc.feat->reg_fields->vert_accu;
>
> - val = FLD_VAL(vaccu, vert_start, vert_end) |
> - FLD_VAL(haccu, hor_start, hor_end);
> + val = FLD_VAL(vaccu, vaccu_field->start, vaccu_field->end) |
> + FLD_VAL(haccu, haccu_field->start, haccu_field->end);
>
> dispc_write_reg(DISPC_OVL_ACCU1(plane), val);
> }
> @@ -4048,6 +4059,46 @@ static void _omap_dispc_initial_config(void)
> dispc_ovl_enable_zorder_planes();
> }
>
> +static struct dispc_reg_fields omap2_dispc_reg_fields = {
> + .firhinc = { 11, 0 },
> + .firvinc = { 27, 16 },
> + .fifo_low_thresh = { 8, 0 },
> + .fifo_high_thresh = { 24, 16 },
> + .fifosize = { 8, 0 },
> + .hori_accu = { 9, 0 },
> + .vert_accu = { 25, 16 },
> +};
And these tables can be consts.
> +static struct dispc_reg_fields omap3_dispc_reg_fields = {
> + .firhinc = { 12, 0 },
> + .firvinc = { 28, 16 },
> + .fifo_low_thresh = { 11, 0 },
> + .fifo_high_thresh = { 27, 16 },
> + .fifosize = { 10, 0 },
> + .hori_accu = { 9, 0 },
> + .vert_accu = { 25, 16 },
> +};
> +
> +static struct dispc_reg_fields omap4_dispc_reg_fields = {
> + .firhinc = { 12, 0 },
> + .firvinc = { 28, 16 },
> + .fifo_low_thresh = { 15, 0 },
> + .fifo_high_thresh = { 31, 16 },
> + .fifosize = { 15, 0 },
> + .hori_accu = { 10, 0 },
> + .vert_accu = { 26, 16 },
> +};
> +
> +static struct dispc_reg_fields omap5_dispc_reg_fields = {
> + .firhinc = { 12, 0 },
> + .firvinc = { 28, 16 },
> + .fifo_low_thresh = { 15, 0 },
> + .fifo_high_thresh = { 31, 16 },
> + .fifosize = { 15, 0 },
> + .hori_accu = { 10, 0 },
> + .vert_accu = { 26, 16 },
> +};
> +
> static const struct dispc_features omap24xx_dispc_feats __initconst = {
> .sw_start = 5,
> .fp_start = 15,
> @@ -4065,6 +4116,7 @@ static const struct dispc_features omap24xx_dispc_feats __initconst = {
> .no_framedone_tv = true,
> .buffer_size_unit = 1,
> .burst_size_unit = 8,
> + .reg_fields = &omap2_dispc_reg_fields,
> };
>
> static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
> @@ -4084,6 +4136,7 @@ static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
> .no_framedone_tv = true,
> .buffer_size_unit = 1,
> .burst_size_unit = 8,
> + .reg_fields = &omap3_dispc_reg_fields,
> };
>
> static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
> @@ -4103,6 +4156,7 @@ static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
> .no_framedone_tv = true,
> .buffer_size_unit = 1,
> .burst_size_unit = 8,
> + .reg_fields = &omap3_dispc_reg_fields,
> };
>
> static const struct dispc_features omap44xx_dispc_feats __initconst = {
> @@ -4122,6 +4176,7 @@ static const struct dispc_features omap44xx_dispc_feats __initconst = {
> .gfx_fifo_workaround = true,
> .buffer_size_unit = 16,
> .burst_size_unit = 16,
> + .reg_fields = &omap4_dispc_reg_fields,
> };
>
> static const struct dispc_features omap54xx_dispc_feats __initconst = {
> @@ -4141,6 +4196,7 @@ static const struct dispc_features omap54xx_dispc_feats __initconst = {
> .gfx_fifo_workaround = true,
> .buffer_size_unit = 16,
> .burst_size_unit = 16,
> + .reg_fields = &omap5_dispc_reg_fields,
> };
There's one thing to note here (and the same applies to DSI patches).
The *_dispc_feats tables above are __initconst, and we make a copy of
the needed table at probe time, so that the unneeded tables can be
discarded. Now you add new tables, but they are not handled the same
way. This is not a bug, but it's a bit inconsistent.
So I think we have three options:
- Make the new tables also __initconst, and create a copy of the needed
tables, and fix up the pointers to point to the copied tables.
- Embed the new tables into the *_dispc_feats table, as you suggested
previously. This would mean multiple copies of the same data in some cases.
- Remove the __initconst and the copy code.
I'm not sure which one to pick. The first one feels a bit complex, but
perhaps it should be tried first to see how the actual code would look
like. If it's just a few lines per table, I guess it's ok.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [patch] OMAPDSS: reading past end of array in dispc_dump_regs()
From: Dan Carpenter @ 2012-12-17 12:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Archit Taneja, Florian Tobias Schandinat, Chandrabhanu Mahapatra,
linux-omap, linux-fbdev, kernel-janitors
In-Reply-To: <50CF0B5C.9080707@ti.com>
On Mon, Dec 17, 2012 at 02:09:00PM +0200, Tomi Valkeinen wrote:
> Why does the static checker think OMAP_DSS_WB is needed in the array?
drivers/video/omap2/dss/dispc.c +3284
3274 #define DISPC_REG(plane, name, i) name(plane, i)
3275 #define DUMPREG(plane, name, i) \
3276 seq_printf(s, "%s_%d(%s)%*s %08x\n", #name, i, p_names[plane], \
3277 (int)(46 - strlen(#name) - strlen(p_names[plane])), " ", \
3278 dispc_read_reg(DISPC_REG(plane, name, i)))
3279
3280 /* Video pipeline coefficient registers */
3281
3282 /* start from OMAP_DSS_VIDEO1 */
3283 for (i = 1; i < dss_feat_get_num_ovls(); i++) {
3284 for (j = 0; j < 8; j++)
3285 DUMPREG(i, DISPC_OVL_FIR_COEF_H, j);
The logic here is that we pass i to DISPC_OVL_FIR_COEF_H() which
passes i to DISPC_FIR_COEF_H_OFFSET(). Anything higher than
OMAP_DSS_WB will trigger a BUG() in DISPC_FIR_COEF_H_OFFSET().
So it's not rock hard logic at all.
regards,
dan carpenter
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-17 14:36 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja,
Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker,
Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel,
Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec,
Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan
In-Reply-To: <50AF8D79.1070309@ti.com>
[-- Attachment #1: Type: text/plain, Size: 5321 bytes --]
Hi Tomi,
I finally have time to work on a v3 :-)
On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
> On 2012-11-22 23:45, Laurent Pinchart wrote:
> > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> >
> > Hi everybody,
> >
> > Here's the second RFC of what was previously known as the Generic Panel
> > Framework.
>
> Nice work! Thanks for working on this.
>
> I was doing some testing with the code, seeing how to use it in omapdss.
> Here are some thoughts:
>
> In your model the DSS gets the panel devices connected to it from
> platform data. After the DSS and the panel drivers are loaded, DSS gets
> a notification and connects DSS and the panel.
>
> I think it's a bit limited way. First of all, it'll make the DT data a
> bit more complex (although this is not a major problem). With your
> model, you'll need something like:
>
> soc-base.dtsi:
>
> dss {
> dpi0: dpi {
> };
> };
>
> board.dts:
>
> &dpi0 {
> panel = &dpi-panel;
> };
>
> / {
> dpi-panel: dpi-panel {
> ...panel data...;
> };
> };
>
> Second, it'll prevent hotplug, and even if real hotplug would not be
> supported, it'll prevent cases where the connected panel must be found
> dynamically (like reading ID from eeprom).
Hotplug definitely needs to be supported, as the common display framework also
targets HDMI and DP. The notification mechanism was actually designed to
support hotplug.
How do you see the proposal preventing hotplug ?
> Third, it kinda creates a cyclical dependency: the DSS needs to know
> about the panel and calls ops in the panel, and the panel calls ops in
> the DSS. I'm not sure if this is an actual problem, but I usually find
> it simpler if calls are done only in one direction.
I don't see any way around that. The panel is not a standalone entity that can
only receive calls (as it needs to control video streams, per your request
:-)) or only emit calls (as something needs to control it, userspace doesn't
control the panel directly).
> What I suggest is take a simpler approach, something alike to how regulators
> or gpios are used, even if slightly more complex than those: the entity that
> has a video output (SoC's DSS, external chips) offers that video output as
> resource. It doesn't know or care who uses it. The user of the video output
> (panel, external chips) will find the video output (to which it is connected
> in the HW) by some means, and will use different operations on that output
> to operate the device.
>
> This would give us something like the following DT data:
>
> soc-base.dtsi:
>
> dss {
> dpi0: dpi {
> };
> };
>
> board.dts:
>
> / {
> dpi-panel: dpi-panel {
> source = <&dpi0>;
> ...panel data...;
> };
> };
>
> The panel driver would do something like this in its probe:
>
> int dpi_panel_probe()
> {
> // Find the video source, increase ref
> src = get_video_source_from_of("source");
>
> // Reserve the video source for us. others can still get and
> // observe it, but cannot use it as video data source.
> // I think this should cascade upstream, so that after this call
> // each video entity from the panel to the SoC's CRTC is
> // reserved and locked for this video pipeline.
> reserve_video_source(src);
>
> // set DPI HW configuration, like DPI data lines. The
> // configuration would come from panel's platform data
> set_dpi_config(src, config);
>
> // register this panel as a display.
> register_display(this);
> }
>
>
> The DSS's dpi driver would do something like:
>
> int dss_dpi_probe()
> {
> // register as a DPI video source
> register_video_source(this);
> }
>
> A DSI-2-DPI chip would do something like:
>
> int dsi2dpi_probe()
> {
> // get, reserve and config the DSI bus from SoC
> src = get_video_source_from_of("source");
> reserve_video_source(src);
> set_dsi_config(src, config);
>
> // register as a DPI video source
> register_video_source(this);
> }
>
>
> Here we wouldn't have similar display_entity as you have, but video sources
> and displays. Video sources are elements in the video pipeline, and a video
> source is used only by the next downstream element. The last element in the
> pipeline would not be a video source, but a display, which would be used by
> the upper layer.
I don't think we should handle pure sources, pure sinks (displays) and mixed
entities (transceivers) differently. I prefer having abstract entities that
can have a source and a sink, and expose the corresponding operations. That
would make pipeline handling much easier, as the code will only need to deal
with a single type of object. Implementing support for entities with multiple
sinks and/or sources would also be possible.
> Video source's ops would deal with things related to the video bus in
> question, like configuring data lanes, sending DSI packets, etc. The
> display ops would be more high level things, like enable, update, etc.
> Actually, I guess you could consider the display to represent and deal
> with the whole pipeline, while video source deals with the bus between
> two display entities.
What is missing in your proposal is an explanation of how the panel is
controlled. What does your register_display() function register the display
with, and what then calls the display operations ?
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-17 14:58 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-fbdev, dri-devel, Thomas Petazzoni, Philipp Zabel, Tom Gall,
Ragesh Radhakrishnan, Rob Clark, Kyungmin Park, Tomi Valkeinen,
Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan,
Sumit Semwal, Sebastien Guiriec, linux-media
In-Reply-To: <20121123195607.GA20990@avionic-0098.adnet.avionic-design.de>
[-- Attachment #1: Type: text/plain, Size: 3859 bytes --]
Hi Thierry,
On Friday 23 November 2012 20:56:07 Thierry Reding wrote:
> On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> [...]
>
> > Display entities are accessed by driver using notifiers. Any driver can
> > register a display entity notifier with the CDF, which then calls the
> > notifier when a matching display entity is registered. The reason for
> > this asynchronous mode of operation, compared to how drivers acquire
> > regulator or clock resources, is that the display entities can use
> > resources provided by the display driver. For instance a panel can be a
> > child of the DBI or DSI bus controlled by the display device, or use a
> > clock provided by that device. We can't defer the display device probe
> > until the panel is registered and also defer the panel device probe until
> > the display is registered. As most display drivers need to handle output
> > devices hotplug (HDMI monitors for instance), handling other display
> > entities through a notification system seemed to be the easiest solution.
> >
> > Note that this brings a different issue after registration, as display
> > controller and display entity drivers would take a reference to each
> > other. Those circular references would make driver unloading impossible.
> > One possible solution to this problem would be to simulate an unplug event
> > for the display entity, to force the display driver to release the dislay
> > entities it uses. We would need a userspace API for that though. Better
> > solutions would of course be welcome.
>
> Maybe I don't understand all of the underlying issues correctly, but a
> parent/child model would seem like a better solution to me. We discussed
> this back when designing the DT bindings for Tegra DRM and came to the
> conclusion that the output resource of the display controller (RGB,
> HDMI, DSI or TVO) was the most suitable candidate to be the parent of
> the panel or display attached to it. The reason for that decision was
> that it keeps the flow of data or addressing of nodes consistent. So the
> chain would look something like this (on Tegra):
>
> CPU
> +-host1x
> +-dc
> +-rgb
> | +-panel
> +-hdmi
> +-monitor
>
> In a natural way this makes the output resource the master of the panel
> or display. From a programming point of view this becomes quite easy to
> implement and is very similar to how other busses like I2C or SPI are
> modelled. In device tree these would be represented as subnodes, while
> with platform data some kind of lookup could be done like for regulators
> or alternatively a board setup registration mechanism like what's in
> place for I2C or SPI.
That works well for panels that have a shared control and video bus (DBI, DSI)
or only a video bus (DPI), but breaks when you need to support panels with
separate control and video busses, such as panels with a parallel data bus and
an I2C or SPI control bus.
Both Linux and DT have a tree-based device model. Devices can have a single
parent, so you can't represent your panel as a child of both the video source
and the control bus master. We have the exact same problem in V4L2 with I2C
camera sensors that output video data on a separate parallel or serial bus,
and we decided to handle the device as a child of its control bus master. This
model makes usage of the Linux power management model easier (but not
straightforward when power management dependencies exist across video busses,
outside of the kernel device tree).
As the common display framework should handle both panels with common control
and video busses and panels with separate busses in a similar fashion, DT
bindings needs to reference the panel through a phandle, even though in some
cases they could technically just be children of the display controller.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-17 15:02 UTC (permalink / raw)
To: Sascha Hauer, Inki Dae
Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja,
Benjamin Gaignard, Jesse Barker, Kyungmin Park, Marcus Lorentzon,
Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan, Rob Clark,
Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni, Tom Gall,
Tomi Valkeinen, Vikas Sajjan
In-Reply-To: <20121123214158.GO10369@pengutronix.de>
Hi Sascha,
On Friday 23 November 2012 22:41:58 Sascha Hauer wrote:
> On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> >
> > The CDF models this using a Russian doll's model. From the display
> > controller point of view only the first external entity (LVDS to DSI
> > converter) is visible. The display controller thus calls the control
> > operations implemented by the LVDS to DSI transmitter driver (left-most
> > green arrow). The driver is aware of the next entity in the chain,
>
> I can't find this in the code. I can see the video operations
> propagating upstream using the source field of struct display_entity,
> but how do the control operations propagate downstream? Am I missing
> something?
There's no downstream propagation yet, as there's no display entity driver
that requires it at the moment. Propagation would be implemented in
transceiver drivers for instance. I'll have to find one with public
documentation (and hopefully an existing mainline driver) on one of the boards
I own.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-17 15:15 UTC (permalink / raw)
To: Alan Cox, Maxime Ripard
Cc: Tomi Valkeinen, Thierry Reding, Thomas Petazzoni, linux-fbdev,
Benjamin Gaignard, Tom Gall, Kyungmin Park, dri-devel, Rob Clark,
Ragesh Radhakrishnan, Philipp Zabel, Vikas Sajjan, Sumit Semwal,
Sebastien Guiriec, linux-media
In-Reply-To: <20121126144708.3daec09e@pyramind.ukuu.org.uk>
Hi Alan,
On Monday 26 November 2012 14:47:08 Alan Cox wrote:
> On Sat, 24 Nov 2012 09:15:51 +0200 Tomi Valkeinen wrote:
> > On 2012-11-23 21:56, Thierry Reding wrote:
> > > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> > > [...]
> > >
> > >> Display entities are accessed by driver using notifiers. Any driver can
> > >> register a display entity notifier with the CDF, which then calls the
> > >> notifier when a matching display entity is registered.
>
> The framebuffer layer has some similar 'anyone can' type notifier
> behaviour and its not a good thing. That kind of "any one can" behaviour
> leads to some really horrible messes unless the connections and the
> locking are well defined IMHO.
I agree with you. I dislike the FBDEV notifier model, and I definitely don't
intend to duplicate it in the common display framework.
In the CDF model, when the display device driver registers a notifier, it
tells the core which device it wants to receive events for. This currently
takes the form of a struct device pointer, and the API will also support
device nodes in a future version (this is still work in progress). The goal is
to implement panel discovery in a way that is compatible with (and very
similar to) hotpluggable display discovery.
Thinking about it now, the API could be cleaner and less subject to abuse if
the notifier was registered for a given video port instead of a given
connected device. I'll add that to my TODO list.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Tomi Valkeinen @ 2012-12-17 15:29 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja,
Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker,
Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel,
Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec,
Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan
In-Reply-To: <1608840.IleINgrx5J@avalon>
[-- Attachment #1: Type: text/plain, Size: 5869 bytes --]
On 2012-12-17 16:36, Laurent Pinchart wrote:
> Hi Tomi,
>
> I finally have time to work on a v3 :-)
>
> On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
>> On 2012-11-22 23:45, Laurent Pinchart wrote:
>>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>>>
>>> Hi everybody,
>>>
>>> Here's the second RFC of what was previously known as the Generic Panel
>>> Framework.
>>
>> Nice work! Thanks for working on this.
>>
>> I was doing some testing with the code, seeing how to use it in omapdss.
>> Here are some thoughts:
>>
>> In your model the DSS gets the panel devices connected to it from
>> platform data. After the DSS and the panel drivers are loaded, DSS gets
>> a notification and connects DSS and the panel.
>>
>> I think it's a bit limited way. First of all, it'll make the DT data a
>> bit more complex (although this is not a major problem). With your
>> model, you'll need something like:
>>
>> soc-base.dtsi:
>>
>> dss {
>> dpi0: dpi {
>> };
>> };
>>
>> board.dts:
>>
>> &dpi0 {
>> panel = &dpi-panel;
>> };
>>
>> / {
>> dpi-panel: dpi-panel {
>> ...panel data...;
>> };
>> };
>>
>> Second, it'll prevent hotplug, and even if real hotplug would not be
>> supported, it'll prevent cases where the connected panel must be found
>> dynamically (like reading ID from eeprom).
>
> Hotplug definitely needs to be supported, as the common display framework also
> targets HDMI and DP. The notification mechanism was actually designed to
> support hotplug.
HDMI or DP hotplug may or may not be a different thing than what I talk
about here. We may have two kinds of hotplug: real linux device hotplug,
i.e. a linux device appears or is removed during runtime, or just a
cable hotplug, handled inside a driver, which doesn't have any effect on
the linux devices.
If we do implement HDMI and DP monitors with real linux drivers, then
yes, we could use real hotplug. But we could as well have the monitor
driver always registered, and just have a driver internal cable-hotplug
system.
To be honest, I'm not sure if implementing real hotplug is easily
possible, as we don't have real, probable (probe-able =) busses. So even
if we'd get a hotplug event of a new display device, what kind of device
would the bus master register? It has no way to know that.
> How do you see the proposal preventing hotplug ?
Well, probably it doesn't prevent. But it doesn't feel right to me.
Say, if we have a DPI panel, controlled via foo-bus, which has a probing
mechanism. When the foo-bus master detects a new hardware device, it'll
create linux device for it. The driver for this device will then be
probed. In the probe function it should somehow register itself to the
cdf, or perhaps the previous entity in the chain.
This sounds to me that the link is from the panel to the previous
entity, not the other way around as you describe, and also the previous
entity doesn't know of the panel entities.
>> Third, it kinda creates a cyclical dependency: the DSS needs to know
>> about the panel and calls ops in the panel, and the panel calls ops in
>> the DSS. I'm not sure if this is an actual problem, but I usually find
>> it simpler if calls are done only in one direction.
>
> I don't see any way around that. The panel is not a standalone entity that can
> only receive calls (as it needs to control video streams, per your request
> :-)) or only emit calls (as something needs to control it, userspace doesn't
> control the panel directly).
Right, but as I see it, the destination of the panel's calls, and the
source of the calls to panel are different things. The destination is
the bus layer, dealing with the video signal being transferred. The
source is a bit higher level thing, something that's controlling the
display in general.
>> Here we wouldn't have similar display_entity as you have, but video sources
>> and displays. Video sources are elements in the video pipeline, and a video
>> source is used only by the next downstream element. The last element in the
>> pipeline would not be a video source, but a display, which would be used by
>> the upper layer.
>
> I don't think we should handle pure sources, pure sinks (displays) and mixed
> entities (transceivers) differently. I prefer having abstract entities that
> can have a source and a sink, and expose the corresponding operations. That
> would make pipeline handling much easier, as the code will only need to deal
> with a single type of object. Implementing support for entities with multiple
> sinks and/or sources would also be possible.
Ok. I think having pure sources is simpler model, but it's true that if
we need to iterate and study the pipeline during runtime, it's probably
better to have single entities with multiple sources/sinks.
>> Video source's ops would deal with things related to the video bus in
>> question, like configuring data lanes, sending DSI packets, etc. The
>> display ops would be more high level things, like enable, update, etc.
>> Actually, I guess you could consider the display to represent and deal
>> with the whole pipeline, while video source deals with the bus between
>> two display entities.
>
> What is missing in your proposal is an explanation of how the panel is
> controlled. What does your register_display() function register the display
> with, and what then calls the display operations ?
In my particular case, the omapfb calls the display operations, which is
the higher level "manager" for the whole display. So omapfb does calls
both to the DSS side and to the panel side of the pipeline.
I agree that making calls to both ends is a bit silly, but then again, I
think it also happens in your model, it's just hidden there.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Jani Nikula @ 2012-12-17 16:53 UTC (permalink / raw)
To: Laurent Pinchart, Tomi Valkeinen
Cc: Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall,
Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park,
Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan,
Sumit Semwal, Sebastien Guiriec, linux-media
In-Reply-To: <1608840.IleINgrx5J@avalon>
Hi Laurent -
On Mon, 17 Dec 2012, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> Hi Tomi,
>
> I finally have time to work on a v3 :-)
>
> On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
>> On 2012-11-22 23:45, Laurent Pinchart wrote:
>> > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>> >
>> > Hi everybody,
>> >
>> > Here's the second RFC of what was previously known as the Generic Panel
>> > Framework.
>>
>> Nice work! Thanks for working on this.
>>
>> I was doing some testing with the code, seeing how to use it in omapdss.
>> Here are some thoughts:
>>
>> In your model the DSS gets the panel devices connected to it from
>> platform data. After the DSS and the panel drivers are loaded, DSS gets
>> a notification and connects DSS and the panel.
>>
>> I think it's a bit limited way. First of all, it'll make the DT data a
>> bit more complex (although this is not a major problem). With your
>> model, you'll need something like:
>>
>> soc-base.dtsi:
>>
>> dss {
>> dpi0: dpi {
>> };
>> };
>>
>> board.dts:
>>
>> &dpi0 {
>> panel = &dpi-panel;
>> };
>>
>> / {
>> dpi-panel: dpi-panel {
>> ...panel data...;
>> };
>> };
>>
>> Second, it'll prevent hotplug, and even if real hotplug would not be
>> supported, it'll prevent cases where the connected panel must be found
>> dynamically (like reading ID from eeprom).
>
> Hotplug definitely needs to be supported, as the common display framework also
> targets HDMI and DP. The notification mechanism was actually designed to
> support hotplug.
I can see the need for a framework for DSI panels and such (in fact Tomi
and I have talked about it like 2-3 years ago already!) but what is the
story for HDMI and DP? In particular, what's the relationship between
DRM and CDF here? Is there a world domination plan to switch the DRM
drivers to use this framework too? ;) Do you have some rough plans how
DRM and CDF should work together in general?
BR,
Jani.
>
> How do you see the proposal preventing hotplug ?
>
>> Third, it kinda creates a cyclical dependency: the DSS needs to know
>> about the panel and calls ops in the panel, and the panel calls ops in
>> the DSS. I'm not sure if this is an actual problem, but I usually find
>> it simpler if calls are done only in one direction.
>
> I don't see any way around that. The panel is not a standalone entity that can
> only receive calls (as it needs to control video streams, per your request
> :-)) or only emit calls (as something needs to control it, userspace doesn't
> control the panel directly).
>
>> What I suggest is take a simpler approach, something alike to how regulators
>> or gpios are used, even if slightly more complex than those: the entity that
>> has a video output (SoC's DSS, external chips) offers that video output as
>> resource. It doesn't know or care who uses it. The user of the video output
>> (panel, external chips) will find the video output (to which it is connected
>> in the HW) by some means, and will use different operations on that output
>> to operate the device.
>>
>> This would give us something like the following DT data:
>>
>> soc-base.dtsi:
>>
>> dss {
>> dpi0: dpi {
>> };
>> };
>>
>> board.dts:
>>
>> / {
>> dpi-panel: dpi-panel {
>> source = <&dpi0>;
>> ...panel data...;
>> };
>> };
>>
>> The panel driver would do something like this in its probe:
>>
>> int dpi_panel_probe()
>> {
>> // Find the video source, increase ref
>> src = get_video_source_from_of("source");
>>
>> // Reserve the video source for us. others can still get and
>> // observe it, but cannot use it as video data source.
>> // I think this should cascade upstream, so that after this call
>> // each video entity from the panel to the SoC's CRTC is
>> // reserved and locked for this video pipeline.
>> reserve_video_source(src);
>>
>> // set DPI HW configuration, like DPI data lines. The
>> // configuration would come from panel's platform data
>> set_dpi_config(src, config);
>>
>> // register this panel as a display.
>> register_display(this);
>> }
>>
>>
>> The DSS's dpi driver would do something like:
>>
>> int dss_dpi_probe()
>> {
>> // register as a DPI video source
>> register_video_source(this);
>> }
>>
>> A DSI-2-DPI chip would do something like:
>>
>> int dsi2dpi_probe()
>> {
>> // get, reserve and config the DSI bus from SoC
>> src = get_video_source_from_of("source");
>> reserve_video_source(src);
>> set_dsi_config(src, config);
>>
>> // register as a DPI video source
>> register_video_source(this);
>> }
>>
>>
>> Here we wouldn't have similar display_entity as you have, but video sources
>> and displays. Video sources are elements in the video pipeline, and a video
>> source is used only by the next downstream element. The last element in the
>> pipeline would not be a video source, but a display, which would be used by
>> the upper layer.
>
> I don't think we should handle pure sources, pure sinks (displays) and mixed
> entities (transceivers) differently. I prefer having abstract entities that
> can have a source and a sink, and expose the corresponding operations. That
> would make pipeline handling much easier, as the code will only need to deal
> with a single type of object. Implementing support for entities with multiple
> sinks and/or sources would also be possible.
>
>> Video source's ops would deal with things related to the video bus in
>> question, like configuring data lanes, sending DSI packets, etc. The
>> display ops would be more high level things, like enable, update, etc.
>> Actually, I guess you could consider the display to represent and deal
>> with the whole pipeline, while video source deals with the bus between
>> two display entities.
>
> What is missing in your proposal is an explanation of how the panel is
> controlled. What does your register_display() function register the display
> with, and what then calls the display operations ?
>
> --
> Regards,
>
> Laurent Pinchart
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [GIT PULL] fbdev changes for 3.8
From: Tony Lindgren @ 2012-12-17 18:29 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Dave Jones, Linus Torvalds, Tomi Valkeinen, linux-omap,
linux-fbdev, linux-kernel, Florian Tobias Schandinat,
Felipe Balbi, Evgeniy Polyakov, Arnd Bergmann
In-Reply-To: <20121217060032.GB13300@core.coreip.homeip.net>
* Dmitry Torokhov <dmitry.torokhov@gmail.com> [121216 22:03]:
> On Sun, Dec 16, 2012 at 12:35:37PM -0800, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [121216 09:49]:
> > > * Dave Jones <davej@redhat.com> [121215 14:27]:
> > > > On Sat, Dec 15, 2012 at 01:11:04PM -0800, Linus Torvalds wrote:
> > > > > On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > > > > > Hi Linus,
> > > > > >
> > > > > > Florian, the fbdev maintainer, has been very busy lately, so I offered to send
> > > > > > the pull request for fbdev for this merge window.
> > > > >
> > > > > Pulled. However, with this I get the Kconfig question
> > > > >
> > > > > OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW)
> > > > >
> > > > > which doesn't make a whole lot of sense on x86-64, unless there's
> > > > > something about OMAP2 that I don't know.
> > > > >
> > > > > So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at
> > > > > least ARM. Because showing it to anybody else seems insane.
> > > > >
> > > > > Same goes for FB_OMAP2 for that matter. I realize that it's likely
> > > > > nice to get compile testing for this on x86-64 too, but if that's the
> > > > > intent, we need to think about it some more. I don't think it's good
> > > > > to ask actual normal users questions like this just for compile
> > > > > coverage.
> > > >
> > > > This OMAP stuff has been creeping into x86 builds for a while.
> > > > Grep from my current build config ..
> > > >
> > > > # CONFIG_OMAP_OCP2SCP is not set
> > > > # CONFIG_KEYBOARD_OMAP4 is not set
> > > > # CONFIG_OMAP2_DSS is not set
> > > > # CONFIG_OMAP_USB2 is not set
> > > >
> > > > There was some other arm-ism that does the same that I' currently forgetting,
> > > > or maybe that got fixed..
> > >
> > > Those are all omap internal devices and should be all marked with
> > > depends on ARCH_OMAP2PLUS.
> > >
> > > It's a different story for external devices that may be used on other
> > > architectures.
> > >
> > > I only came up with one reason to compile internal devices for other
> > > architectures: In some cases the driver subsystem maintainer may want to
> > > be able to compile test subsystem wide changes without having to compile
> > > for each target separately. But for those cases it's trivial to carry a
> > > compile test patch that just drops the depends Kconfig entries.
> >
> > And here's a patch to limit the omap drivers above to omap only.
>
> Do you think we could add a new symbol to debug options, something like
> COMPILE_COVERAGE, and have drivers that can be compiled on platforms
> other than ones having the hardware to do
>
> depend on ARCH_XXX || COMPILE_CONVERAGE
>
> This way people who want to do compile coverage do not have to carry
> patches and allyesconfig will pick this right up.
I like that idea. Looks like Linus already applied the earlier
patch, I'll do a patch for COMPILE_COVERAGE separately.
Regards,
Tony
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-17 22:19 UTC (permalink / raw)
To: Jani Nikula
Cc: Tomi Valkeinen, Thomas Petazzoni, linux-fbdev, Philipp Zabel,
Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark,
Kyungmin Park, Benjamin Gaignard, Bryan Wu, Maxime Ripard,
Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media
In-Reply-To: <87pq28hb72.fsf@intel.com>
Hi Jani,
On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
> On Mon, 17 Dec 2012, Laurent Pinchart wrote:
> > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
> >> On 2012-11-22 23:45, Laurent Pinchart wrote:
> >> > From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> >> >
> >> > Hi everybody,
> >> >
> >> > Here's the second RFC of what was previously known as the Generic Panel
> >> > Framework.
> >>
> >> Nice work! Thanks for working on this.
> >>
> >> I was doing some testing with the code, seeing how to use it in omapdss.
> >> Here are some thoughts:
> >>
> >> In your model the DSS gets the panel devices connected to it from
> >> platform data. After the DSS and the panel drivers are loaded, DSS gets
> >> a notification and connects DSS and the panel.
> >>
> >> I think it's a bit limited way. First of all, it'll make the DT data a
> >> bit more complex (although this is not a major problem). With your
> >> model, you'll need something like:
> >>
> >> soc-base.dtsi:
> >>
> >> dss {
> >> dpi0: dpi {
> >> };
> >> };
> >>
> >> board.dts:
> >>
> >> &dpi0 {
> >> panel = &dpi-panel;
> >> };
> >>
> >> / {
> >> dpi-panel: dpi-panel {
> >> ...panel data...;
> >> };
> >> };
> >>
> >> Second, it'll prevent hotplug, and even if real hotplug would not be
> >> supported, it'll prevent cases where the connected panel must be found
> >> dynamically (like reading ID from eeprom).
> >
> > Hotplug definitely needs to be supported, as the common display framework
> > also targets HDMI and DP. The notification mechanism was actually
> > designed to support hotplug.
>
> I can see the need for a framework for DSI panels and such (in fact Tomi
> and I have talked about it like 2-3 years ago already!) but what is the
> story for HDMI and DP? In particular, what's the relationship between
> DRM and CDF here? Is there a world domination plan to switch the DRM
> drivers to use this framework too? ;) Do you have some rough plans how
> DRM and CDF should work together in general?
There's always a world domination plan, isn't there ? :-)
I certainly want CDF to be used by DRM (or more accurately KMS). That's what
the C stands for, common refers to sharing panel and other display entity
drivers between FBDEV, KMS and V4L2.
I currently have no plan to expose CDF internals to userspace through the KMS
API. We might have to do so later if the hardware complexity grows in such a
way that finer control than what KMS provides needs to be exposed to
userspace, but I don't think we're there yet. The CDF API will thus only be
used internally in the kernel by display controller drivers. The KMS core
might get functions to handle common display entity operations, but the bulk
of the work will be in the display controller drivers to start with. We will
then see what can be abstracted in KMS helper functions.
Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF
API. That's just a thought for now, I haven't tried to implement them, but it
would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way.
Do you have thoughts to share on this topic ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-17 23:18 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev, dri-devel, linux-media, Archit Taneja,
Benjamin Gaignard, Bryan Wu, Inki Dae, Jesse Barker,
Kyungmin Park, Marcus Lorentzon, Maxime Ripard, Philipp Zabel,
Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec,
Sumit Semwal, Thomas Petazzoni, Tom Gall, Vikas Sajjan
In-Reply-To: <50CF3A4B.8030206@ti.com>
[-- Attachment #1: Type: text/plain, Size: 8668 bytes --]
Hi Tomi,
On Monday 17 December 2012 17:29:15 Tomi Valkeinen wrote:
> On 2012-12-17 16:36, Laurent Pinchart wrote:
> > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
> >> On 2012-11-22 23:45, Laurent Pinchart wrote:
> >>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> >>>
> >>> Hi everybody,
> >>>
> >>> Here's the second RFC of what was previously known as the Generic Panel
> >>> Framework.
> >>
> >> Nice work! Thanks for working on this.
> >>
> >> I was doing some testing with the code, seeing how to use it in omapdss.
> >> Here are some thoughts:
> >>
> >> In your model the DSS gets the panel devices connected to it from
> >> platform data. After the DSS and the panel drivers are loaded, DSS gets
> >> a notification and connects DSS and the panel.
> >>
> >> I think it's a bit limited way. First of all, it'll make the DT data a
> >> bit more complex (although this is not a major problem). With your
> >> model, you'll need something like:
> >>
> >> soc-base.dtsi:
> >>
> >> dss {
> >> dpi0: dpi {
> >> };
> >> };
> >>
> >> board.dts:
> >>
> >> &dpi0 {
> >> panel = &dpi-panel;
> >> };
> >>
> >> / {
> >> dpi-panel: dpi-panel {
> >> ...panel data...;
> >> };
> >> };
> >>
> >> Second, it'll prevent hotplug, and even if real hotplug would not be
> >> supported, it'll prevent cases where the connected panel must be found
> >> dynamically (like reading ID from eeprom).
> >
> > Hotplug definitely needs to be supported, as the common display framework
> > also targets HDMI and DP. The notification mechanism was actually
> > designed to support hotplug.
>
> HDMI or DP hotplug may or may not be a different thing than what I talk
> about here. We may have two kinds of hotplug: real linux device hotplug,
> i.e. a linux device appears or is removed during runtime, or just a cable
> hotplug, handled inside a driver, which doesn't have any effect on the linux
> devices.
>
> If we do implement HDMI and DP monitors with real linux drivers, then yes,
> we could use real hotplug. But we could as well have the monitor driver
> always registered, and just have a driver internal cable-hotplug system.
>
> To be honest, I'm not sure if implementing real hotplug is easily possible,
> as we don't have real, probable (probe-able =) busses. So even if we'd get a
> hotplug event of a new display device, what kind of device would the bus
> master register? It has no way to know that.
I get your point.
My design goal is to handle both HDMI/DP and panels through a single hotplug
interface. I believe it would be simpler for display controller drivers to
handle all display entities with a common API instead of implementing support
for HDMI/DP and panels separately. This would require real HDMI and DP monitor
drivers. I share your concern, I don't know whether this can work in the end,
the only way to find out will be to try it.
> > How do you see the proposal preventing hotplug ?
>
> Well, probably it doesn't prevent. But it doesn't feel right to me.
>
> Say, if we have a DPI panel, controlled via foo-bus, which has a probing
> mechanism. When the foo-bus master detects a new hardware device, it'll
> create linux device for it. The driver for this device will then be probed.
That's correct. That's how Linux handles devices, and I don't think we should
diverge from that model without a very good reason to do so. In my
understanding you agree with me here, could you please confirm that ?
> In the probe function it should somehow register itself to the cdf, or
> perhaps the previous entity in the chain.
The panel driver would register the panel device to CDF in its probe function.
From a panel point of view I think we agree that two sets of operations exist.
- The panel control operations are called by an upper layer component (let's
call it A) to control the panel (retrieve the list of modes, enable the panel,
...). That upper layer component will usually call the panel in response to a
userspace request (that can go through several layers in the kernel before
reaching the panel), but can also call it in response to a hotplug event,
without userspace being involved.
- The panel calls video operations of the entity that provides it with a video
stream (the video source entity, let's call it B) to configure and control the
video bus.
A and B could be implemented in the same driver or in two separate drivers,
but at the end of the day I don't think that matters much. A needs a reference
to the panel, and the panel needs a reference to B, that's all we need to
provide, regardless of whether A and B come from the same kernel module or
not.
> This sounds to me that the link is from the panel to the previous entity,
> not the other way around as you describe, and also the previous entity
> doesn't know of the panel entities.
The data flows from the video source to the panel (I'm 100% confident that we
agree on that :-)), and the video source is controlled by the panel as per
your request. The link is thus from the video source to the panel, but is
controlled by the sink, not the source.
> >> Third, it kinda creates a cyclical dependency: the DSS needs to know
> >> about the panel and calls ops in the panel, and the panel calls ops in
> >> the DSS. I'm not sure if this is an actual problem, but I usually find
> >> it simpler if calls are done only in one direction.
> >
> > I don't see any way around that. The panel is not a standalone entity that
> > can only receive calls (as it needs to control video streams, per your
> > request :-)) or only emit calls (as something needs to control it,
> > userspace doesn't control the panel directly).
>
> Right, but as I see it, the destination of the panel's calls, and the source
> of the calls to panel are different things. The destination is the bus
> layer, dealing with the video signal being transferred. The source is a bit
> higher level thing, something that's controlling the display in general.
That's correct. They can both be implemented in the same driver, but they're
different logical entities. (I actually think they should be implemented in
the same driver, but that's not very relevant here.)
> >> Here we wouldn't have similar display_entity as you have, but video
> >> sources and displays. Video sources are elements in the video pipeline,
> >> and a video source is used only by the next downstream element. The last
> >> element in the pipeline would not be a video source, but a display, which
> >> would be used by the upper layer.
> >
> > I don't think we should handle pure sources, pure sinks (displays) and
> > mixed entities (transceivers) differently. I prefer having abstract
> > entities that can have a source and a sink, and expose the corresponding
> > operations. That would make pipeline handling much easier, as the code
> > will only need to deal with a single type of object. Implementing support
> > for entities with multiple sinks and/or sources would also be possible.
>
> Ok. I think having pure sources is simpler model, but it's true that if
> we need to iterate and study the pipeline during runtime, it's probably
> better to have single entities with multiple sources/sinks.
A pure source is an entity with a source pad only that only exposes source pad
operations, I think the complexity to handle them from the panel point of view
would roughly be the same (there might be an extra argument to a couple of
functions with a pad number, but that's more or less it).
> >> Video source's ops would deal with things related to the video bus in
> >> question, like configuring data lanes, sending DSI packets, etc. The
> >> display ops would be more high level things, like enable, update, etc.
> >> Actually, I guess you could consider the display to represent and deal
> >> with the whole pipeline, while video source deals with the bus between
> >> two display entities.
> >
> > What is missing in your proposal is an explanation of how the panel is
> > controlled. What does your register_display() function register the
> > display with, and what then calls the display operations ?
>
> In my particular case, the omapfb calls the display operations, which is
> the higher level "manager" for the whole display. So omapfb does calls
> both to the DSS side and to the panel side of the pipeline.
>
> I agree that making calls to both ends is a bit silly, but then again, I
> think it also happens in your model, it's just hidden there.
That's probably the biggest difference between our models. Let's discuss it
face to face tomorrow and hopefully come up with an agreement.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Dave Airlie @ 2012-12-18 5:04 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall,
Ragesh Radhakrishnan, dri-devel, Rob Clark, Kyungmin Park,
Tomi Valkeinen, Benjamin Gaignard, Bryan Wu, Maxime Ripard,
Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media
In-Reply-To: <1353620736-6517-1-git-send-email-laurent.pinchart@ideasonboard.com>
>
> Many developers showed interest in the first RFC, and I've had the opportunity
> to discuss it with most of them. I would like to thank (in no particular
> order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus
> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for
> inviting me to Connect and providing a venue to discuss this topic.
>
So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:
The biggest problem I'm having currently with the whole ARM graphics
and output world is the proliferation of platform drivers for every
little thing. The whole ordering of operations with respect to things
like suspend/resume or dynamic power management is going to be a real
nightmare if there are dependencies between the drivers. How do you
enforce ordering of s/r operations between all the various components?
The other thing I'd like you guys to do is kill the idea of fbdev and
v4l drivers that are "shared" with the drm codebase, really just
implement fbdev and v4l on top of the drm layer, some people might
think this is some sort of maintainer thing, but really nothing else
makes sense, and having these shared display frameworks just to avoid
having using drm/kms drivers seems totally pointless. Fix the drm
fbdev emulation if an fbdev interface is needed. But creating a fourth
framework because our previous 3 frameworks didn't work out doesn't
seem like a situation I want to get behind too much.
Dave.
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Rob Clark @ 2012-12-18 6:21 UTC (permalink / raw)
To: Dave Airlie
Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list,
Philipp Zabel, Tom Gall, Ragesh Radhakrishnan,
dri-devel@lists.freedesktop.org, Kyungmin Park, Tomi Valkeinen,
Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan,
Sumit Semwal, Sebastien Guiriec, linux-media@vger.kernel.org
In-Reply-To: <CAPM=9txFJzJ0haTyBnr8hEmmqNb+gSAyBno+Zs0Z-qvVMTwz9A@mail.gmail.com>
On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote:
>>
>> Many developers showed interest in the first RFC, and I've had the opportunity
>> to discuss it with most of them. I would like to thank (in no particular
>> order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus
>> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for
>> inviting me to Connect and providing a venue to discuss this topic.
>>
>
> So this might be a bit off topic but this whole CDF triggered me
> looking at stuff I generally avoid:
>
> The biggest problem I'm having currently with the whole ARM graphics
> and output world is the proliferation of platform drivers for every
> little thing. The whole ordering of operations with respect to things
> like suspend/resume or dynamic power management is going to be a real
> nightmare if there are dependencies between the drivers. How do you
> enforce ordering of s/r operations between all the various components?
I tend to think that sub-devices are useful just to have a way to
probe hw which may or may not be there, since on ARM we often don't
have any alternative.. but beyond that, suspend/resume, and other
life-cycle aspects, they should really be treated as all one device.
Especially to avoid undefined suspend/resume ordering.
CDF or some sort of mechanism to share panel drivers between drivers
is useful. Keeping it within drm, is probably a good idea, if nothing
else to simplify re-use of helper fxns (like avi-infoframe stuff, for
example) and avoid dealing with merging changes across multiple trees.
Treating them more like shared libraries and less like sub-devices
which can be dynamically loaded/unloaded (ie. they should be not built
as separate modules or suspend/resumed or probed/removed independently
of the master driver) is a really good idea to avoid uncovering nasty
synchronization issues later (remove vs modeset or pageflip) or
surprising userspace in bad ways.
> The other thing I'd like you guys to do is kill the idea of fbdev and
> v4l drivers that are "shared" with the drm codebase, really just
> implement fbdev and v4l on top of the drm layer, some people might
> think this is some sort of maintainer thing, but really nothing else
> makes sense, and having these shared display frameworks just to avoid
> having using drm/kms drivers seems totally pointless. Fix the drm
> fbdev emulation if an fbdev interface is needed. But creating a fourth
> framework because our previous 3 frameworks didn't work out doesn't
> seem like a situation I want to get behind too much.
yeah, let's not have multiple frameworks to do the same thing.. For
fbdev, it is pretty clear that it is a dead end. For v4l2
(subdev+mcf), it is perhaps bit more flexible when it comes to random
arbitrary hw pipelines than kms. But to take advantage of that, your
userspace isn't going to be portable anyways, so you might as well use
driver specific properties/ioctls. But I tend to think that is more
useful for cameras. And from userspace perspective, kms planes are
less painful to use for output than v4l2, so lets stick to drm/kms for
output (and not try to add camera/capture support to kms).. k, thx
BR,
-R
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Vikas Sajjan @ 2012-12-18 6:25 UTC (permalink / raw)
To: dri-devel, linux-fbdev, linux-media
In-Reply-To: <CAD025yQoCiNaKvaCwvUWhk_jV70CPhV35UzV9MR6HtE+1baCxg@mail.gmail.com>
Hi All,
On 17 December 2012 20:55, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Vikas,
>
> Sorry for the late reply. I now have more time to work on CDF, so delays
> should be much shorter.
>
> On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote:
> > Hi Laurent,
> >
> > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what I found
> > is that, the exynos display controller is MIPI DSI based controller.
> >
> > But if I look at CDF patches, it has only support for MIPI DBI based Display
> > controller.
> >
> > So my question is, do we have any generic framework for MIPI DSI based
> > display controller? basically I wanted to know, how to go about porting CDF
> > for such kind of display controller.
>
> MIPI DSI support is not available yet. The only reason for that is that I
> don't have any MIPI DSI hardware to write and test the code with :-)
>
> The common display framework should definitely support MIPI DSI. I think the
> existing MIPI DBI code could be used as a base, so the implementation
> shouldn't be too high.
>
Yeah, i was also thinking in similar lines, below is my though for
MIPI DSI support in CDF.
o MIPI DSI support as part of CDF framework will expose
> mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c file )
> mipi_dsi_register_driver(mipi_driver, bus ops) (will be called
from platform specific init driver call )
· bus ops will be
o read data
o write data
o write command
> MIPI DSI will be registered as bus_register()
When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will
initialize the MIPI DSI HW IP.
This probe will also parse the DT file for MIPI DSI based panel, add
the panel device (device_add() ) to kernel and register the display
entity with its control and video ops with CDF.
>
> I can give this a try. Does the existing Exynos 5250 driver support MIPI DSI ?
> Is the device documentation publicly available ? Can you point me to a MIPI
> DSI panel with public documentation (preferably with an existing mainline
> driver if possible) ?
>
yeah, existing Exynos 5250 driver support MIPI DSI ass well as eDP.
i think device documentation is NOT available publicly.
> --
> Regards,
>
> Laurent Pinchart
>
--
Thanks and Regards
Vikas Sajjan
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Daniel Vetter @ 2012-12-18 8:30 UTC (permalink / raw)
To: Rob Clark
Cc: Dave Airlie, Thomas Petazzoni, Linux Fbdev development list,
Benjamin Gaignard, Tom Gall, Kyungmin Park,
dri-devel@lists.freedesktop.org, Ragesh Radhakrishnan,
Tomi Valkeinen, Laurent Pinchart, Philipp Zabel, Bryan Wu,
Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec,
linux-media@vger.kernel.org
In-Reply-To: <CAF6AEGsLdLasS4=j1PsX_P8miG8NcTXMUP9VYj+4gdU8Qhm2YQ@mail.gmail.com>
On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark <rob.clark@linaro.org> wrote:
>> The other thing I'd like you guys to do is kill the idea of fbdev and
>> v4l drivers that are "shared" with the drm codebase, really just
>> implement fbdev and v4l on top of the drm layer, some people might
>> think this is some sort of maintainer thing, but really nothing else
>> makes sense, and having these shared display frameworks just to avoid
>> having using drm/kms drivers seems totally pointless. Fix the drm
>> fbdev emulation if an fbdev interface is needed. But creating a fourth
>> framework because our previous 3 frameworks didn't work out doesn't
>> seem like a situation I want to get behind too much.
>
> yeah, let's not have multiple frameworks to do the same thing.. For
> fbdev, it is pretty clear that it is a dead end. For v4l2
> (subdev+mcf), it is perhaps bit more flexible when it comes to random
> arbitrary hw pipelines than kms. But to take advantage of that, your
> userspace isn't going to be portable anyways, so you might as well use
> driver specific properties/ioctls. But I tend to think that is more
> useful for cameras. And from userspace perspective, kms planes are
> less painful to use for output than v4l2, so lets stick to drm/kms for
> output (and not try to add camera/capture support to kms).. k, thx
Yeah, I guess having a v4l device also exported by the same driver
that exports the drm interface might make sense in some cases. But in
many cases I think the video part is just an independent IP block and
shuffling data around with dma-buf is all we really need. So yeah, I
guess sharing display resources between v4l and drm kms driver should
be a last resort option, since coordination (especially if it's
supposed to be somewhat dynamic) will be extremely hairy.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Marcus Lorentzon @ 2012-12-18 10:39 UTC (permalink / raw)
To: Dave Airlie
Cc: Laurent Pinchart, linux-fbdev@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
Archit Taneja, Benjamin Gaignard, Bryan Wu, Inki Dae,
Jesse Barker, Kyungmin Park, Maxime Ripard, Philipp Zabel,
Ragesh Radhakrishnan, Rob Clark, Sascha Hauer, Sebastien Guiriec,
Sumit Semwal, Thomas Petazzoni, Tom Gall,
Tomi Valkeinen <tomi.valkei>
In-Reply-To: <CAPM=9txFJzJ0haTyBnr8hEmmqNb+gSAyBno+Zs0Z-qvVMTwz9A@mail.gmail.com>
On 12/18/2012 06:04 AM, Dave Airlie wrote:
>> Many developers showed interest in the first RFC, and I've had the opportunity
>> to discuss it with most of them. I would like to thank (in no particular
>> order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus
>> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for
>> inviting me to Connect and providing a venue to discuss this topic.
>>
> So this might be a bit off topic but this whole CDF triggered me
> looking at stuff I generally avoid:
I like the effort, right now it seems like x86 and arm display sub
systems are quite different in terms of DRM driver (and HW) design. I
think this is partly due to little information shared about these
different architectures and ideas behind the choices made. I hope some
discussion will light up both sides. And an early discussion will
hopefully give you less pain when CDF drivers starts to get pushed your way.
> The biggest problem I'm having currently with the whole ARM graphics
> and output world is the proliferation of platform drivers for every
> little thing. The whole ordering of operations with respect to things
> like suspend/resume or dynamic power management is going to be a real
> nightmare if there are dependencies between the drivers. How do you
> enforce ordering of s/r operations between all the various components?
Could you give an example? Personally I don't think it is that many. I
might not have counted the plat devs in all arm drivers. But the STE one
have one per HW IP block in the HW (1 DSS + 3 DSI encoder/formatters).
Then of course there are all these panel devices. But I hope that when
CDF is "finished" we will have DSI devices on the DSI bus and DBI
devices on the DBI bus. I think most vendors have used platform devices
for these since they normally can't be probed in a generic way. But as
they are off SoC I feel this is not the best choice. And then many of
the panels are I2C devices (control bus) and that I guess is similar to
"x86" encoders/connectors?
Another part of the difference I feel is that in x86 a DRM device is
most likely a PCI device, and as such has one huge driver for all IPs on
that board. The closest thing we get to that in ARM is probably the DSS
(collection of IPs on SoC, like 3D, 2D, display output, encoders). But
it doesn't fell right to create a single driver for all these. And as
you know often 3D is even from a separate vendor. All these lead up to a
slight increase in the number of devices and drivers. Right way, I feel
so, but you are welcome to show a better way.
> The other thing I'd like you guys to do is kill the idea of fbdev and
> v4l drivers that are "shared" with the drm codebase, really just
> implement fbdev and v4l on top of the drm layer, some people might
> think this is some sort of maintainer thing, but really nothing else
> makes sense, and having these shared display frameworks just to avoid
> having using drm/kms drivers seems totally pointless. Fix the drm
> fbdev emulation if an fbdev interface is needed. But creating a fourth
> framework because our previous 3 frameworks didn't work out doesn't
> seem like a situation I want to get behind too much.
>
I have no intention to use CDF outside KMS connector/encoder and I have
not heard Laurent talk about this either. Personally I see CDF as
"helpers" to create and reuse connector/encoder drivers between SoCs
instead of each SoC do their own panel drivers (which would be about a
hundred, times the number of supported SoCs). We probably need to
discuss the connector/encoder mappings to CDF/panels. But I think we
need to flush out the higher level details like control bus vs. data bus
vs. display entities. While I like the generic way of the display
entities, I also like the pure bus/device/driver model without too many
generalizations.
Do you have any support in x86 world that could be compared to mobile
phone DSI/DBI/DPI panels? That is, different encoder/lcd-driver chips
between the on chip/cpu/SoC CRTC and the external LCD depending on
product (mobile/netbook/...) or is it all HDMI/DP/LVDS etc on x86?
And if you do, how do you model/setup/share all those in DRM driver? Or
it is manageable (< 10) and not up in the hundreds of different
encoders/lcd-drivers?
/BR
/Marcus
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Sylwester Nawrocki @ 2012-12-18 10:59 UTC (permalink / raw)
To: Rob Clark
Cc: Dave Airlie, Laurent Pinchart, Thomas Petazzoni,
Linux Fbdev development list, Philipp Zabel, Tom Gall,
Ragesh Radhakrishnan, dri-devel@lists.freedesktop.org,
Kyungmin Park, Tomi Valkeinen, Benjamin Gaignard, Bryan Wu,
Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec,
linux-media@vger.kernel.org
In-Reply-To: <CAF6AEGsLdLasS4=j1PsX_P8miG8NcTXMUP9VYj+4gdU8Qhm2YQ@mail.gmail.com>
On 12/18/2012 07:21 AM, Rob Clark wrote:
> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie<airlied@gmail.com> wrote:
>> So this might be a bit off topic but this whole CDF triggered me
>> looking at stuff I generally avoid:
>>
>> The biggest problem I'm having currently with the whole ARM graphics
>> and output world is the proliferation of platform drivers for every
>> little thing. The whole ordering of operations with respect to things
>> like suspend/resume or dynamic power management is going to be a real
>> nightmare if there are dependencies between the drivers. How do you
>> enforce ordering of s/r operations between all the various components?
There have been already some ideas proposed to resolve this at the PM
subsystem level [1]. And this problem is of course not only specific
to platform drivers. The idea of having monolithic drivers, just because
we can't get the suspend/resume sequences right otherwise, doesn't really
sound appealing. SoC IPs get reused on multiple different SoC series,
no only by single manufacturer. Whole graphics/video subsystems are
composed from smaller blocks in SoCs, with various number of distinct
sub-blocks and same sub-blocks repeated different number of times in
a specific SoC revision.
Expressing an IP as a platform device seems justified to me, often these
platform devices have enough differences to treat them as such. E.g.
belong in different power domain/use different clocks. Except there is
big issue with the power management... However probably more important
is to be able to have driver for a specific IP in a separate module.
And this suspend/resume ordering issue is not only about the platform
devices. E.g. camera subsystem can be composed of an image sensor
sub-device driver, which is most often an I2C client driver, and of
multiple SoC processing blocks. The image sensor can have dependencies
on the SoC sub-blocks. So even if we created monolithic driver for the
SoC part, there are still two pieces to get s/r ordering right - I2C
client and SoC drivers. And please don't propose to merge the sensor
sub-device driver too. There has been a lot of effort in V4L2 to
separate those various functional blocks into sub-devices, so they can
be freely reused, without reimplementing same functionality in each
driver. BTW, there has been a nice talk about these topics at ELCE [2],
particularly slide 22 is interesting.
I believe the solution for these issues really needs to be sought in the
PM subsystem itself.
> I tend to think that sub-devices are useful just to have a way to
> probe hw which may or may not be there, since on ARM we often don't
> have any alternative.. but beyond that, suspend/resume, and other
> life-cycle aspects, they should really be treated as all one device.
> Especially to avoid undefined suspend/resume ordering.
[1] https://lkml.org/lkml/2009/9/9/373
[2]
http://elinux.org/images/9/90/ELCE2012-Modular-Graphics-on-Embedded-ARM.pdf
Thanks,
Sylwester
^ permalink raw reply
* [PATCH] video: ssd1307fb: Fix bit order bug in the byte translation function
From: Maxime Ripard @ 2012-12-18 13:49 UTC (permalink / raw)
To: linux-fbdev
This was leading to a strange behaviour when using the fbcon driver on
top of this one: the letter were in the right order, but each letter was
having a vertical symmetry.
This was because the addressing was right for the byte, but the
addressing of each individual bit was inverted.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Brian Lilly <brian@crystalfontz.com>
Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Thomas Petazzoni <thomas@free-electrons.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
drivers/video/ssd1307fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/ssd1307fb.c b/drivers/video/ssd1307fb.c
index 9e46633..7f5f824 100644
--- a/drivers/video/ssd1307fb.c
+++ b/drivers/video/ssd1307fb.c
@@ -145,8 +145,8 @@ static void ssd1307fb_update_display(struct ssd1307fb_par *par)
u32 page_length = SSD1307FB_WIDTH * i;
u32 index = page_length + (SSD1307FB_WIDTH * k + j) / 8;
u8 byte = *(vmem + index);
- u8 bit = byte & (1 << (7 - (j % 8)));
- bit = bit >> (7 - (j % 8));
+ u8 bit = byte & (1 << (j % 8));
+ bit = bit >> (j % 8);
buf |= bit << k;
}
ssd1307fb_write_data(par->client, buf);
--
1.7.9.5
^ permalink raw reply related
* [PATCHv16 0/7] of: add display helper
From: Steffen Trumtrar @ 2012-12-18 16:57 UTC (permalink / raw)
To: devicestree-discuss
Cc: Steffen Trumtrar, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren, kernel,
Florian Tobias Schandinat, David Airlie, Rob Clark,
Leela Krishna Amudala
Hi!
Finally, right in time before the end of the world on friday, v16 of the
display helpers.
Changes since v15:
- move include/linux/{videomode,display_timing}.h to include/video
- move include/linux/of_{videomode,display_timing}.h to include/video
- reimplement flags: add VESA flags and data flags
- let pixelclock in struct videomode be unsigned long
- rename of_display_timings_exists to of_display_timings_exist
- revise logging/error messages: replace __func__ with np->full_name
- rename pixelclk-inverted to pixelclk-active
- revise comments in code
Changes since v14:
- fix "const struct *" warning
(reported by: Leela Krishna Amudala <l.krishna@samsung.com>)
- return -EINVAL when htotal or vtotal are zero
- remove unreachable code in of_get_display_timings
- include headers in .c files and not implicit in .h
- sort includes alphabetically
- fix lower/uppercase in binding documentation
- rebase onto v3.7-rc7
Changes since v13:
- fix "const struct *" warning
(reported by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>)
- prevent division by zero in fb_videomode_from_videomode
Changes since v12:
- rename struct display_timing to via_display_timing in via subsystem
- fix refreshrate calculation
- fix "const struct *" warnings
(reported by: Manjunathappa, Prakash <prakash.pm@ti.com>)
- some CodingStyle fixes
- rewrite parts of commit messages and display-timings.txt
- let display_timing_get_value get all values instead of just typical
Changes since v11:
- make pointers const where applicable
- add reviewed-by Laurent Pinchart
Changes since v10:
- fix function name (drm_)display_mode_from_videomode
- add acked-by, reviewed-by, tested-by
Changes since v9:
- don't leak memory when previous timings were correct
- CodingStyle fixes
- move blank lines around
Changes since v8:
- fix memory leaks
- change API to be more consistent (foo_from_bar(struct bar, struct foo))
- include headers were necessary
- misc minor bugfixes
Changes since v7:
- move of_xxx to drivers/video
- remove non-binding documentation from display-timings.txt
- squash display_timings and videomode in one patch
- misc minor fixes
Changes since v6:
- get rid of some empty lines etc.
- move functions to their subsystems
- split of_ from non-of_ functions
- add at least some kerneldoc to some functions
Changes since v5:
- removed all display stuff and just describe timings
Changes since v4:
- refactored functions
Changes since v3:
- print error messages
- free alloced memory
- general cleanup
Changes since v2:
- use hardware-near property-names
- provide a videomode structure
- allow ranges for all properties (<min,typ,max>)
- functions to get display_mode or fb_videomode
Regards,
Steffen
Steffen Trumtrar (7):
viafb: rename display_timing to via_display_timing
video: add display_timing and videomode
video: add of helper for display timings/videomode
fbmon: add videomode helpers
fbmon: add of_videomode helpers
drm_modes: add videomode helpers
drm_modes: add of_videomode helpers
.../devicetree/bindings/video/display-timing.txt | 109 +++++++++
drivers/gpu/drm/drm_modes.c | 70 ++++++
drivers/video/Kconfig | 21 ++
drivers/video/Makefile | 4 +
drivers/video/display_timing.c | 24 ++
drivers/video/fbmon.c | 94 ++++++++
drivers/video/of_display_timing.c | 239 ++++++++++++++++++++
drivers/video/of_videomode.c | 54 +++++
drivers/video/via/hw.c | 6 +-
drivers/video/via/hw.h | 2 +-
drivers/video/via/lcd.c | 2 +-
drivers/video/via/share.h | 2 +-
drivers/video/via/via_modesetting.c | 8 +-
drivers/video/via/via_modesetting.h | 6 +-
drivers/video/videomode.c | 39 ++++
include/drm/drmP.h | 9 +
include/linux/fb.h | 8 +
include/video/display_timing.h | 124 ++++++++++
include/video/of_display_timing.h | 20 ++
include/video/of_videomode.h | 18 ++
include/video/videomode.h | 48 ++++
21 files changed, 894 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
create mode 100644 drivers/video/display_timing.c
create mode 100644 drivers/video/of_display_timing.c
create mode 100644 drivers/video/of_videomode.c
create mode 100644 drivers/video/videomode.c
create mode 100644 include/video/display_timing.h
create mode 100644 include/video/of_display_timing.h
create mode 100644 include/video/of_videomode.h
create mode 100644 include/video/videomode.h
--
1.7.10.4
^ permalink raw reply
* [PATCHv16 1/7] viafb: rename display_timing to via_display_timing
From: Steffen Trumtrar @ 2012-12-18 16:57 UTC (permalink / raw)
To: devicestree-discuss
Cc: Steffen Trumtrar, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren, kernel,
Florian Tobias Schandinat, David Airlie, Rob Clark,
Leela Krishna Amudala
In-Reply-To: <1355849873-8051-1-git-send-email-s.trumtrar@pengutronix.de>
The struct display_timing is specific to the via subsystem. The naming leads to
collisions with the new struct display_timing, which is supposed to be a shared
struct between different subsystems.
To clean this up, prepend the existing struct with the subsystem it is specific
to.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
drivers/video/via/hw.c | 6 +++---
drivers/video/via/hw.h | 2 +-
drivers/video/via/lcd.c | 2 +-
drivers/video/via/share.h | 2 +-
drivers/video/via/via_modesetting.c | 8 ++++----
drivers/video/via/via_modesetting.h | 6 +++---
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 898590d..5563c67 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1467,10 +1467,10 @@ void viafb_set_vclock(u32 clk, int set_iga)
via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
}
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres)
{
- struct display_timing timing;
+ struct via_display_timing timing;
u16 dx = (var->xres - cxres) / 2, dy = (var->yres - cyres) / 2;
timing.hor_addr = cxres;
@@ -1491,7 +1491,7 @@ struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga)
{
- struct display_timing crt_reg = var_to_timing(var,
+ struct via_display_timing crt_reg = var_to_timing(var,
cxres ? cxres : var->xres, cyres ? cyres : var->yres);
if (iga = IGA1)
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 6be243c..c3f2572 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -637,7 +637,7 @@ extern int viafb_LCD_ON;
extern int viafb_DVI_ON;
extern int viafb_hotplug;
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres);
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 1650379..022b0df 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -549,7 +549,7 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo *var, u16 cxres,
int panel_hres = plvds_setting_info->lcd_panel_hres;
int panel_vres = plvds_setting_info->lcd_panel_vres;
u32 clock;
- struct display_timing timing;
+ struct via_display_timing timing;
struct fb_var_screeninfo panel_var;
const struct fb_videomode *mode_crt_table, *panel_crt_table;
diff --git a/drivers/video/via/share.h b/drivers/video/via/share.h
index 3158dfc..65c65c6 100644
--- a/drivers/video/via/share.h
+++ b/drivers/video/via/share.h
@@ -319,7 +319,7 @@ struct crt_mode_table {
int refresh_rate;
int h_sync_polarity;
int v_sync_polarity;
- struct display_timing crtc;
+ struct via_display_timing crtc;
};
struct io_reg {
diff --git a/drivers/video/via/via_modesetting.c b/drivers/video/via/via_modesetting.c
index 0e431ae..0b414b0 100644
--- a/drivers/video/via/via_modesetting.c
+++ b/drivers/video/via/via_modesetting.c
@@ -30,9 +30,9 @@
#include "debug.h"
-void via_set_primary_timing(const struct display_timing *timing)
+void via_set_primary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing->hor_total / 8 - 5;
raw.hor_addr = timing->hor_addr / 8 - 1;
@@ -88,9 +88,9 @@ void via_set_primary_timing(const struct display_timing *timing)
via_write_reg_mask(VIACR, 0x17, 0x80, 0x80);
}
-void via_set_secondary_timing(const struct display_timing *timing)
+void via_set_secondary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing->hor_total - 1;
raw.hor_addr = timing->hor_addr - 1;
diff --git a/drivers/video/via/via_modesetting.h b/drivers/video/via/via_modesetting.h
index 06e09fe..f6a6503 100644
--- a/drivers/video/via/via_modesetting.h
+++ b/drivers/video/via/via_modesetting.h
@@ -33,7 +33,7 @@
#define VIA_PITCH_MAX 0x3FF8
-struct display_timing {
+struct via_display_timing {
u16 hor_total;
u16 hor_addr;
u16 hor_blank_start;
@@ -49,8 +49,8 @@ struct display_timing {
};
-void via_set_primary_timing(const struct display_timing *timing);
-void via_set_secondary_timing(const struct display_timing *timing);
+void via_set_primary_timing(const struct via_display_timing *timing);
+void via_set_secondary_timing(const struct via_display_timing *timing);
void via_set_primary_address(u32 addr);
void via_set_secondary_address(u32 addr);
void via_set_primary_pitch(u32 pitch);
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox