* [PATCH fix-3.8] video: vt8500: Fix X crash when initializing framebuffer.
From: Tony Prisk @ 2012-12-27 0:25 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for .fb_check_var which is required when
X attempts to initialize the framebuffer. The only supported
resolution is the native resolution of the LCD panel, so we test
against the resolution supplied from the DT panel definition.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
drivers/video/wm8505fb.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 77539c1..c84e376 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -41,10 +41,18 @@
#define to_wm8505fb_info(__info) container_of(__info, \
struct wm8505fb_info, fb)
+
+struct lcd_params {
+ u32 pixel_width;
+ u32 pixel_height;
+ u32 color_depth;
+};
+
struct wm8505fb_info {
struct fb_info fb;
void __iomem *regbase;
unsigned int contrast;
+ struct lcd_params lcd_params;
};
@@ -248,8 +256,21 @@ static int wm8505fb_blank(int blank, struct fb_info *info)
return 0;
}
+static int wm8505fb_check_var(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ struct wm8505fb_info *fbi = to_wm8505fb_info(info);
+ if (!fbi) return -EINVAL;
+
+ if (info->var.bits_per_pixel != fbi->lcd_params.color_depth) return -EINVAL;
+ if (info->var.xres != fbi->lcd_params.pixel_width) return -EINVAL;
+ if (info->var.yres != fbi->lcd_params.pixel_height) return -EINVAL;
+ return 0;
+}
+
static struct fb_ops wm8505fb_ops = {
.owner = THIS_MODULE,
+ .fb_check_var = wm8505fb_check_var,
.fb_set_par = wm8505fb_set_par,
.fb_setcolreg = wm8505fb_setcolreg,
.fb_fillrect = wmt_ge_fillrect,
@@ -354,6 +375,10 @@ static int __devinit wm8505fb_probe(struct platform_device *pdev)
goto failed_free_res;
}
+ fbi->lcd_params.pixel_width = of_mode.xres;
+ fbi->lcd_params.pixel_height = of_mode.yres;
+ fbi->lcd_params.color_depth = bpp;
+
of_mode.vmode = FB_VMODE_NONINTERLACED;
fb_videomode_to_var(&fbi->fb.var, &of_mode);
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC 0/6] Common Display Framework-T
From: Laurent Pinchart @ 2012-12-26 12:14 UTC (permalink / raw)
To: Vikas Sajjan; +Cc: linux-fbdev, Tomi Valkeinen, dri-devel
In-Reply-To: <CAGm_ybjbVbKDFCdMtqZhBOxkBCb-8kO4kwEXRLFsrNQqCvezwg@mail.gmail.com>
Hi Vikas,
On Monday 24 December 2012 12:33:50 Vikas Sajjan wrote:
> On Wed, Dec 19, 2012 at 6:51 PM, Laurent Pinchart wrote:
> > On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote:
> >> Hi,
> >>
> >> I have been testing Common Display Framework on OMAP, and making changes
> >> that I've discussed in the posts I've sent in reply to the CDF series
> >> from Laurent. While my CDF code is rather hacky and not at all ready, I
> >> wanted to post the code for comments and also as a reference code to my
> >> posts.
> >>
> >> So here is CDF-T (Tomi-edition =).
> >
> > We've discussed your approach extensively face-to-face today so I won't
> > review the patches in detail, but I will instead summarize our discussion
> > to make sure we understood each other (and let other developers jump in).
> >
> > For the purpose of this discussion the term "display controller driver"
> > (or just "display controller") refer to both the low-level driver layer
> > that communicates directly with the display controller hardware, and to
> > the higher- level driver layer that implements and exposes the userspace
> > API (FBDEV, KMS and/or V4L). Those layers can be implemented in multiple
> > kernel modules (such as in the OMAP DSS case, with omapdss for the
> > low-level layer and omapdrm, omapfb and omapvout for the API-level layer)
> > or a single kernel module.
> >
> > Control model
> > -------------
> >
> > The figure at http://www.ideasonboard.org/media/cdf/cdf-panel-control-
> > model.png shows the CDF control model.
> >
> > The panel object depicted on the figure doesn't need to be a panel in the
> > stricter sense but could be any chain of off-SoC (both on-board or
> > off-board) display entities. It however helps thinking about it as a
> > panel and doesn't hurt the model.
> >
> > The panel is controlled through abstract control requests. Those requests
> > are used to retrieve panel information (such as the physical size, the
> > supported video modes, EDID information, ...), set the panel
> > configuration (such as the active video timings) or control the panel
> > operation state (enabling/disabling the panel, controlling panel blanking
> > and power management, ...). They are exposed by the panel using function
> > pointers, and called by other kernel components in response to userspace
> > requests (through the FBDEV, KMS or V4L2 APIs) or in-kernel events (for
> > instance hotplug notifications).
> >
> > In response to the control requests the panel driver will communicate with
> > the panel through the panel control bus (I2C, SPI, DBI, DSI, GPIO, ...,
> > not shown on the figure) and will control the video stream it receives on
> > its input.
> >
> > The panel is connected at the hardware level to a video source (shown as a
> > green hashed rectangle) that provides it with a video stream. The video
> > stream flows from the video source to the panel and is directly
> > controlled by its source, as shown by the green arrow from the display
> > controller to the video stream. The video source exposes stream control
> > operations as function pointers that are used by the panel to control the
> > video stream, as shown by the green arrow from the panel to the video
> > source.
> >
> > The figure at http://www.ideasonboard.org/media/cdf/cdf-panel-control-
> > model-2.png shows the call flow across entities when the panel is a
> > pipeline made of more than a single entity. In this case the SoC (on the
> > left of the dashed line) outputs a video stream on a DSI bus connected to
> > a DSI to LVDS transmitter. The output of the DSI to LVDS transmitter is
> > connected to an LVDS panel (or, more accurately, an LVDS panel module
> > made of an LVDS panel controller and a panel).
> >
> > The transmitter and panel module are seen by the display controller and
> > userspace API implementations as a single entity that exposes control
> > request operations and controls its input video stream. When a control
> > request is performed (outermost green arrow) the DSI to LVDS transmitter
> > will propagate it to the panel, possibly mangling the input parameters or
> > the response. For panel operation state control requests the last entity
> > in the pipeline will likely want to control the video stream it receives
> > on its input. The video stream control calls will be propagated from
> > right to left as shown by the red arrows.
> >
> > Every entity in the call stack can communicate with its hardware device
> > through the corresponding control bus, and/or control the video stream it
> > receives on its input.
> >
> > This model allows filtering out modes and timings supported by the panel
> > but unsupported by the transmitter and mangling the modes and timings
> > according to the transmitter limitations. It has no complexity drawback
> > for simple devices, as the corresponding drivers can just forward the
> > calls directly. Similar use cases could exist for other control
> > operations than mode and information retrieval.
> >
> > Discovery
> > ---------
> >
> > Before being able to issue control requests, panel devices need to be
> > discovered and associated with the connected display controller(s).
> >
> > Panels and display controllers are cross-dependent. There is no way around
> > that, as the display controller needs a reference to the panel to call
> > control requests in response to userspace API, and the panel needs a
> > reference to the display controller to call video stream control
> > functions (in addition to requiring generic resources such as clocks,
> > GPIOs or even regulators that could be provided by the display
> > controller).
> >
> > As we can't probe the display controller and the panel together, a probe
> > order needs to be defined. The decision was to consider video sources as
> > resources and defer panel probing until all required resources (video
> > stream source, clocks, GPIOs, regulators and more) are available. Display
> > controller probing must succeed without the panel being available. This
> > mimicks the hotpluggable monitor model (VGA, HDMI, DP) that doesn't
> > prevent display controllers from being successfully probed without a
> > connected monitor.
> >
> > Our design goal is to handle panel discovery in a similar (if not
> > identical) way as HDMI/DP hotplug in order to implement a single display
> > discovery method in display controller drivers. This might not be
> > achievable, in which case we'll reconsider the design requirement.
> >
> > When the display controller driver probes the device it will register the
> > video source(s) at the output of the display controller with the CDF core.
> > Those sources will be identified by the display controller dev_name() and
> > a source integer index. A new structure, likely called
> > display_entity_port, will be used to represent a source or sink video port
> > on a display entity.
> >
> > Panel drivers will handle video sources as resources. They will retrieve
> > at probe time the video source the panel is connected to using a phandle
> > or a source name (depending on whether the platform uses DT). If the
> > source isn't available the probe function will return -EPROBE_DEFER.
> >
> > In addition to the video stream control operations mentioned above, ports
> > will also expose a connect/disconnect operation use to notify them of
> > connection/disconnection events. After retrieving the connected video
> > source panel drivers call the connect/disconnect operation on the video
> > source to notify it that the panel is available.
> >
> > When the panel is a pipeline made of more than a single entity, entities
> > are probed in video source to video sink order. Out-of-order probe will
> > result in probe deferral as explained above due to the video source not
> > being available, resulting in the source to sink probe order. Entities
> > should not call the connect operation of their video source at probe time
> > in that case, but only when their own connect operation for the video
> > source(s) they provide to the next entity is called by the next entity.
> > Connect operations will thus be called in sink to source order starting
> > at the entity at the end of the pipeline and going all the way back to
> > the display controller.
> >
> > This notification system is a hotplug mechanism that replaces the display
> > entity notifier system from my previous RFC. Alan Cox rightly objected to
> > the notification system, arguing that such system-wide notifications were
> > used by FBDEV and very subject to abuse. I agree with his argument, this
> > new mechanism should result in a cleaner implementation as video sources
> > will only be notified of connect/disconnect events for the entity they're
> > connected to.
> >
> > DBI/DSI busses
> > --------------
> >
> > My RFC introduced a DBI bus using the Linux device and bus model. Its
> > purpose was multifold:
> >
> > - Support (un)registration, matching and binding of devices and drivers.
> >
> > - Provide power management (suspend/resume) services through the standard
> > Linux PM bus/device model, to make sure that DBI devices will be
> > suspended/resumed after/before their DBI bus controller.
> >
> > - Provide bus services to access the connected devices. For DBI that took
> > the form of command read and data read/write functions.
> >
> > A DSI bus implementation using the same model was also planned.
> >
> > Tomi's patches removed the DBI bus and replaced DBI devices with platform
> > devices, moving the bus services implementation to the video source. DBI
> > and DSI busses are always either pure video or video + control busses
> > (although controlling a DPI panel through DSI is conceivable, nobody in
> > his right mind, not even a hardware engineer, would likely implement
> > that), so there will always be a video source to provide the DBI/DSI
> > control operations.
> >
> > (Un)registration, matching and binding of devices and drivers is provided
> > by the platform device bus. Bus services to access connected devices are
> > provided by the video source, wrapper functions will be used to handle
> > serialization and locking, and possibly to offer higher level services
> > (such as DCS for instance).
> >
> > One drawback of using the platform bus is that PM relationships between
> > the bus master and slaves will not be taken into account during
> > suspend/resume. However, a similar issue exists for DPI panels, and PM
> > relationships at the video bus level for DBI and DSI are not handled by
> > the DBI/DSI busses either. As we need a generic solution to handle those
> > (likely through early suspend and late resume), the same solution can be
> > used to handle DBI and DSI control bus PM relationships without requiring
> > a Linux DBI or DSI bus.
> >
> > Even though I still like the idea of DBI and DSI busses, I agree with Tomi
> > that they're not strictly needed and I will drop them.
> >
> > Entity model
> > ------------
> >
> > Tomi's proposal split the display entities into video sources (struct
> > video_source) and display entities (struct display_entity). To make
> > generic pipeline operations easier, we agreed to merge the video source
> > and the display entity back. struct display_entity thus models a display
> > entity that has any number of sink and/or source ports, modeled as struct
> > display_entity_port instances.
>
> Looking at Tomi's patchset, he has considered panel as "display entity"
> and MIPI DSI as "video source entity". So if we are planning to merge it
> back how should we treat panel and MIPI DSI. i mean should we consider both
> panel and MIPI DSI has 2 different display entities.
> i.e, during the probe of each of these drivers, should we register a
> display entity with CDF.
Both the DSI encoder and the DSI panel would be modeled as display entities.
The DSI encoder would have a source port that models its DSI video source, and
the DSI panel would have a sink port.
> > Video stream operations will be exposed by the display entity as function
> > pointers and will take a port reference as argument (this could take the
> > form of struct display_entity * and port index, or struct
> > display_entity_port *). The DVI and DSI operations model proposed by Tomi
> > in this patch series will be kept.
>
> so you mean you will be adding these "ops" as part of "struct display
> entity" rather than video source ops,
That's correct.
> static const struct dsi_video_source_ops dsi_dsi_ops = {
>
> .update = dsi_bus_update,
> .dcs_write = dsi_bus_dcs_write,
> .dcs_read = dsi_bus_dcs_read,
> .configure_pins = dsi_bus_configure_pins,
> .set_clocks = dsi_bus_set_clocks,
> .enable = dsi_bus_enable,
> .disable = dsi_bus_disable,
> .set_size = dsi_bus_set_size,
> .set_operation_mode = dsi_bus_set_operation_mode,
> .set_pixel_format = dsi_bus_set_pixel_format,
> .enable_hs = dsi_bus_enable_hs,
> };
>
> if you can post CDF v3 patches early, it will give us more clarity
> w.r.t to discussions you and Tomi had.
I'm working on that.
> > Points that we forgot to discuss
> > --------------------------------
> >
> > - DISPLAY_ENTITY_STREAM_SINGLE_SHOT vs. update() operation
> >
> > I'll look into that.
> >
> > Please let me know if I've forgotten anything.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 4/4] video: s3c-fb: add the bit definitions for CSC EQ709 and EQ601
From: Jingoo Han @ 2012-12-26 8:15 UTC (permalink / raw)
To: linux-fbdev
This patch adds the bit definitions for CSC EQ709 and EQ601.
These definitons are used to control the CSC parameter such as
equation 709 and equation 601.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
include/video/samsung_fimd.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index be7b853..2f95d9a 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -176,6 +176,8 @@
/* WINCONx */
#define WINCON(_win) (0x20 + ((_win) * 4))
+#define WINCONx_CSCCON_EQ601 (0x0 << 28)
+#define WINCONx_CSCCON_EQ709 (0x1 << 28)
#define WINCONx_CSCWIDTH_MASK (0x3 << 26)
#define WINCONx_CSCWIDTH_SHIFT 26
#define WINCONx_CSCWIDTH_WIDE (0x0 << 26)
--
1.7.2.5
^ permalink raw reply related
* [PATCH 3/4] video: s3c-fb: remove unnecessary brackets
From: Jingoo Han @ 2012-12-26 8:15 UTC (permalink / raw)
To: linux-fbdev
This patch removes unnecessary brackets and the duplicated
VIDTCON2 definition.
Also, header comment is modified, because EXYNOS series is
supported and <mach/regs-fb.h> is not available.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
include/video/samsung_fimd.h | 199 ++++++++++++++++++++---------------------
1 files changed, 97 insertions(+), 102 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index 0865256..be7b853 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -8,12 +8,8 @@
* S3C Platform - new-style fimd and framebuffer register definitions
*
* This is the register set for the fimd and new style framebuffer interface
- * found from the S3C2443 onwards into the S3C2416, S3C2450 and the
- * S3C64XX series such as the S3C6400 and S3C6410.
- *
- * The file does not contain the cpu specific items which are based on
- * whichever architecture is selected, it only contains the core of the
- * register set. See <mach/regs-fb.h> to get the specifics.
+ * found from the S3C2443 onwards into the S3C2416, S3C2450, the
+ * S3C64XX series such as the S3C6400 and S3C6410, and EXYNOS series.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -22,10 +18,10 @@
/* VIDCON0 */
-#define VIDCON0 (0x00)
+#define VIDCON0 0x00
#define VIDCON0_INTERLACE (1 << 29)
#define VIDCON0_VIDOUT_MASK (0x7 << 26)
-#define VIDCON0_VIDOUT_SHIFT (26)
+#define VIDCON0_VIDOUT_SHIFT 26
#define VIDCON0_VIDOUT_RGB (0x0 << 26)
#define VIDCON0_VIDOUT_TV (0x1 << 26)
#define VIDCON0_VIDOUT_I80_LDI0 (0x2 << 26)
@@ -35,7 +31,7 @@
#define VIDCON0_VIDOUT_WB_I80_LDI1 (0x7 << 26)
#define VIDCON0_L1_DATA_MASK (0x7 << 23)
-#define VIDCON0_L1_DATA_SHIFT (23)
+#define VIDCON0_L1_DATA_SHIFT 23
#define VIDCON0_L1_DATA_16BPP (0x0 << 23)
#define VIDCON0_L1_DATA_18BPP16 (0x1 << 23)
#define VIDCON0_L1_DATA_18BPP9 (0x2 << 23)
@@ -44,7 +40,7 @@
#define VIDCON0_L1_DATA_16BPP8 (0x5 << 23)
#define VIDCON0_L0_DATA_MASK (0x7 << 20)
-#define VIDCON0_L0_DATA_SHIFT (20)
+#define VIDCON0_L0_DATA_SHIFT 20
#define VIDCON0_L0_DATA_16BPP (0x0 << 20)
#define VIDCON0_L0_DATA_18BPP16 (0x1 << 20)
#define VIDCON0_L0_DATA_18BPP9 (0x2 << 20)
@@ -53,7 +49,7 @@
#define VIDCON0_L0_DATA_16BPP8 (0x5 << 20)
#define VIDCON0_PNRMODE_MASK (0x3 << 17)
-#define VIDCON0_PNRMODE_SHIFT (17)
+#define VIDCON0_PNRMODE_SHIFT 17
#define VIDCON0_PNRMODE_RGB (0x0 << 17)
#define VIDCON0_PNRMODE_BGR (0x1 << 17)
#define VIDCON0_PNRMODE_SERIAL_RGB (0x2 << 17)
@@ -61,14 +57,14 @@
#define VIDCON0_CLKVALUP (1 << 16)
#define VIDCON0_CLKVAL_F_MASK (0xff << 6)
-#define VIDCON0_CLKVAL_F_SHIFT (6)
-#define VIDCON0_CLKVAL_F_LIMIT (0xff)
+#define VIDCON0_CLKVAL_F_SHIFT 6
+#define VIDCON0_CLKVAL_F_LIMIT 0xff
#define VIDCON0_CLKVAL_F(_x) ((_x) << 6)
#define VIDCON0_VLCKFREE (1 << 5)
#define VIDCON0_CLKDIR (1 << 4)
#define VIDCON0_CLKSEL_MASK (0x3 << 2)
-#define VIDCON0_CLKSEL_SHIFT (2)
+#define VIDCON0_CLKSEL_SHIFT 2
#define VIDCON0_CLKSEL_HCLK (0x0 << 2)
#define VIDCON0_CLKSEL_LCD (0x1 << 2)
#define VIDCON0_CLKSEL_27M (0x3 << 2)
@@ -76,13 +72,13 @@
#define VIDCON0_ENVID (1 << 1)
#define VIDCON0_ENVID_F (1 << 0)
-#define VIDCON1 (0x04)
+#define VIDCON1 0x04
#define VIDCON1_LINECNT_MASK (0x7ff << 16)
-#define VIDCON1_LINECNT_SHIFT (16)
+#define VIDCON1_LINECNT_SHIFT 16
#define VIDCON1_LINECNT_GET(_v) (((_v) >> 16) & 0x7ff)
#define VIDCON1_FSTATUS_EVEN (1 << 15)
#define VIDCON1_VSTATUS_MASK (0x3 << 13)
-#define VIDCON1_VSTATUS_SHIFT (13)
+#define VIDCON1_VSTATUS_SHIFT 13
#define VIDCON1_VSTATUS_VSYNC (0x0 << 13)
#define VIDCON1_VSTATUS_BACKPORCH (0x1 << 13)
#define VIDCON1_VSTATUS_ACTIVE (0x2 << 13)
@@ -98,12 +94,12 @@
/* VIDCON2 */
-#define VIDCON2 (0x08)
+#define VIDCON2 0x08
#define VIDCON2_EN601 (1 << 23)
#define VIDCON2_TVFMTSEL_SW (1 << 14)
#define VIDCON2_TVFMTSEL1_MASK (0x3 << 12)
-#define VIDCON2_TVFMTSEL1_SHIFT (12)
+#define VIDCON2_TVFMTSEL1_SHIFT 12
#define VIDCON2_TVFMTSEL1_RGB (0x0 << 12)
#define VIDCON2_TVFMTSEL1_YUV422 (0x1 << 12)
#define VIDCON2_TVFMTSEL1_YUV444 (0x2 << 12)
@@ -115,74 +111,73 @@
* Might not be present in the S3C6410 documentation,
* but tests prove it's there almost for sure; shouldn't hurt in any case.
*/
-#define PRTCON (0x0c)
+#define PRTCON 0x0c
#define PRTCON_PROTECT (1 << 11)
/* VIDTCON0 */
-#define VIDTCON0 (0x10)
+#define VIDTCON0 0x10
#define VIDTCON0_VBPDE_MASK (0xff << 24)
-#define VIDTCON0_VBPDE_SHIFT (24)
-#define VIDTCON0_VBPDE_LIMIT (0xff)
+#define VIDTCON0_VBPDE_SHIFT 24
+#define VIDTCON0_VBPDE_LIMIT 0xff
#define VIDTCON0_VBPDE(_x) ((_x) << 24)
#define VIDTCON0_VBPD_MASK (0xff << 16)
-#define VIDTCON0_VBPD_SHIFT (16)
-#define VIDTCON0_VBPD_LIMIT (0xff)
+#define VIDTCON0_VBPD_SHIFT 16
+#define VIDTCON0_VBPD_LIMIT 0xff
#define VIDTCON0_VBPD(_x) ((_x) << 16)
#define VIDTCON0_VFPD_MASK (0xff << 8)
-#define VIDTCON0_VFPD_SHIFT (8)
-#define VIDTCON0_VFPD_LIMIT (0xff)
+#define VIDTCON0_VFPD_SHIFT 8
+#define VIDTCON0_VFPD_LIMIT 0xff
#define VIDTCON0_VFPD(_x) ((_x) << 8)
#define VIDTCON0_VSPW_MASK (0xff << 0)
-#define VIDTCON0_VSPW_SHIFT (0)
-#define VIDTCON0_VSPW_LIMIT (0xff)
+#define VIDTCON0_VSPW_SHIFT 0
+#define VIDTCON0_VSPW_LIMIT 0xff
#define VIDTCON0_VSPW(_x) ((_x) << 0)
/* VIDTCON1 */
-#define VIDTCON1 (0x14)
+#define VIDTCON1 0x14
#define VIDTCON1_VFPDE_MASK (0xff << 24)
-#define VIDTCON1_VFPDE_SHIFT (24)
-#define VIDTCON1_VFPDE_LIMIT (0xff)
+#define VIDTCON1_VFPDE_SHIFT 24
+#define VIDTCON1_VFPDE_LIMIT 0xff
#define VIDTCON1_VFPDE(_x) ((_x) << 24)
#define VIDTCON1_HBPD_MASK (0xff << 16)
-#define VIDTCON1_HBPD_SHIFT (16)
-#define VIDTCON1_HBPD_LIMIT (0xff)
+#define VIDTCON1_HBPD_SHIFT 16
+#define VIDTCON1_HBPD_LIMIT 0xff
#define VIDTCON1_HBPD(_x) ((_x) << 16)
#define VIDTCON1_HFPD_MASK (0xff << 8)
-#define VIDTCON1_HFPD_SHIFT (8)
-#define VIDTCON1_HFPD_LIMIT (0xff)
+#define VIDTCON1_HFPD_SHIFT 8
+#define VIDTCON1_HFPD_LIMIT 0xff
#define VIDTCON1_HFPD(_x) ((_x) << 8)
#define VIDTCON1_HSPW_MASK (0xff << 0)
-#define VIDTCON1_HSPW_SHIFT (0)
-#define VIDTCON1_HSPW_LIMIT (0xff)
+#define VIDTCON1_HSPW_SHIFT 0
+#define VIDTCON1_HSPW_LIMIT 0xff
#define VIDTCON1_HSPW(_x) ((_x) << 0)
-#define VIDTCON2 (0x18)
-#define VIDTCON2 (0x18)
+#define VIDTCON2 0x18
#define VIDTCON2_LINEVAL_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDTCON2_LINEVAL_MASK (0x7ff << 11)
-#define VIDTCON2_LINEVAL_SHIFT (11)
-#define VIDTCON2_LINEVAL_LIMIT (0x7ff)
+#define VIDTCON2_LINEVAL_SHIFT 11
+#define VIDTCON2_LINEVAL_LIMIT 0x7ff
#define VIDTCON2_LINEVAL(_x) (((_x) & 0x7ff) << 11)
#define VIDTCON2_HOZVAL_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDTCON2_HOZVAL_MASK (0x7ff << 0)
-#define VIDTCON2_HOZVAL_SHIFT (0)
-#define VIDTCON2_HOZVAL_LIMIT (0x7ff)
+#define VIDTCON2_HOZVAL_SHIFT 0
+#define VIDTCON2_HOZVAL_LIMIT 0x7ff
#define VIDTCON2_HOZVAL(_x) (((_x) & 0x7ff) << 0)
/* WINCONx */
#define WINCON(_win) (0x20 + ((_win) * 4))
#define WINCONx_CSCWIDTH_MASK (0x3 << 26)
-#define WINCONx_CSCWIDTH_SHIFT (26)
+#define WINCONx_CSCWIDTH_SHIFT 26
#define WINCONx_CSCWIDTH_WIDE (0x0 << 26)
#define WINCONx_CSCWIDTH_NARROW (0x3 << 26)
#define WINCONx_ENLOCAL (1 << 22)
@@ -195,14 +190,14 @@
#define WINCONx_WSWP (1 << 15)
#define WINCONx_YCbCr (1 << 13)
#define WINCONx_BURSTLEN_MASK (0x3 << 9)
-#define WINCONx_BURSTLEN_SHIFT (9)
+#define WINCONx_BURSTLEN_SHIFT 9
#define WINCONx_BURSTLEN_16WORD (0x0 << 9)
#define WINCONx_BURSTLEN_8WORD (0x1 << 9)
#define WINCONx_BURSTLEN_4WORD (0x2 << 9)
#define WINCONx_ENWIN (1 << 0)
#define WINCON0_BPPMODE_MASK (0xf << 2)
-#define WINCON0_BPPMODE_SHIFT (2)
+#define WINCON0_BPPMODE_SHIFT 2
#define WINCON0_BPPMODE_1BPP (0x0 << 2)
#define WINCON0_BPPMODE_2BPP (0x1 << 2)
#define WINCON0_BPPMODE_4BPP (0x2 << 2)
@@ -215,7 +210,7 @@
#define WINCON1_LOCALSEL_CAMIF (1 << 23)
#define WINCON1_BLD_PIX (1 << 6)
#define WINCON1_BPPMODE_MASK (0xf << 2)
-#define WINCON1_BPPMODE_SHIFT (2)
+#define WINCON1_BPPMODE_SHIFT 2
#define WINCON1_BPPMODE_1BPP (0x0 << 2)
#define WINCON1_BPPMODE_2BPP (0x1 << 2)
#define WINCON1_BPPMODE_4BPP (0x2 << 2)
@@ -234,7 +229,7 @@
#define WINCON1_ALPHA_SEL (1 << 1)
/* S5PV210 */
-#define SHADOWCON (0x34)
+#define SHADOWCON 0x34
#define SHADOWCON_WINx_PROTECT(_win) (1 << (10 + (_win)))
/* DMA channels (all windows) */
#define SHADOWCON_CHx_ENABLE(_win) (1 << (_win))
@@ -243,52 +238,52 @@
/* VIDOSDx */
-#define VIDOSD_BASE (0x40)
+#define VIDOSD_BASE 0x40
#define VIDOSDxA_TOPLEFT_X_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDOSDxA_TOPLEFT_X_MASK (0x7ff << 11)
-#define VIDOSDxA_TOPLEFT_X_SHIFT (11)
-#define VIDOSDxA_TOPLEFT_X_LIMIT (0x7ff)
+#define VIDOSDxA_TOPLEFT_X_SHIFT 11
+#define VIDOSDxA_TOPLEFT_X_LIMIT 0x7ff
#define VIDOSDxA_TOPLEFT_X(_x) (((_x) & 0x7ff) << 11)
#define VIDOSDxA_TOPLEFT_Y_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDOSDxA_TOPLEFT_Y_MASK (0x7ff << 0)
-#define VIDOSDxA_TOPLEFT_Y_SHIFT (0)
-#define VIDOSDxA_TOPLEFT_Y_LIMIT (0x7ff)
+#define VIDOSDxA_TOPLEFT_Y_SHIFT 0
+#define VIDOSDxA_TOPLEFT_Y_LIMIT 0x7ff
#define VIDOSDxA_TOPLEFT_Y(_x) (((_x) & 0x7ff) << 0)
#define VIDOSDxB_BOTRIGHT_X_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDOSDxB_BOTRIGHT_X_MASK (0x7ff << 11)
-#define VIDOSDxB_BOTRIGHT_X_SHIFT (11)
-#define VIDOSDxB_BOTRIGHT_X_LIMIT (0x7ff)
+#define VIDOSDxB_BOTRIGHT_X_SHIFT 11
+#define VIDOSDxB_BOTRIGHT_X_LIMIT 0x7ff
#define VIDOSDxB_BOTRIGHT_X(_x) (((_x) & 0x7ff) << 11)
#define VIDOSDxB_BOTRIGHT_Y_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDOSDxB_BOTRIGHT_Y_MASK (0x7ff << 0)
-#define VIDOSDxB_BOTRIGHT_Y_SHIFT (0)
-#define VIDOSDxB_BOTRIGHT_Y_LIMIT (0x7ff)
+#define VIDOSDxB_BOTRIGHT_Y_SHIFT 0
+#define VIDOSDxB_BOTRIGHT_Y_LIMIT 0x7ff
#define VIDOSDxB_BOTRIGHT_Y(_x) (((_x) & 0x7ff) << 0)
/* For VIDOSD[1..4]C */
#define VIDISD14C_ALPHA0_R(_x) ((_x) << 20)
#define VIDISD14C_ALPHA0_G_MASK (0xf << 16)
-#define VIDISD14C_ALPHA0_G_SHIFT (16)
-#define VIDISD14C_ALPHA0_G_LIMIT (0xf)
+#define VIDISD14C_ALPHA0_G_SHIFT 16
+#define VIDISD14C_ALPHA0_G_LIMIT 0xf
#define VIDISD14C_ALPHA0_G(_x) ((_x) << 16)
#define VIDISD14C_ALPHA0_B_MASK (0xf << 12)
-#define VIDISD14C_ALPHA0_B_SHIFT (12)
-#define VIDISD14C_ALPHA0_B_LIMIT (0xf)
+#define VIDISD14C_ALPHA0_B_SHIFT 12
+#define VIDISD14C_ALPHA0_B_LIMIT 0xf
#define VIDISD14C_ALPHA0_B(_x) ((_x) << 12)
#define VIDISD14C_ALPHA1_R_MASK (0xf << 8)
-#define VIDISD14C_ALPHA1_R_SHIFT (8)
-#define VIDISD14C_ALPHA1_R_LIMIT (0xf)
+#define VIDISD14C_ALPHA1_R_SHIFT 8
+#define VIDISD14C_ALPHA1_R_LIMIT 0xf
#define VIDISD14C_ALPHA1_R(_x) ((_x) << 8)
#define VIDISD14C_ALPHA1_G_MASK (0xf << 4)
-#define VIDISD14C_ALPHA1_G_SHIFT (4)
-#define VIDISD14C_ALPHA1_G_LIMIT (0xf)
+#define VIDISD14C_ALPHA1_G_SHIFT 4
+#define VIDISD14C_ALPHA1_G_LIMIT 0xf
#define VIDISD14C_ALPHA1_G(_x) ((_x) << 4)
#define VIDISD14C_ALPHA1_B_MASK (0xf << 0)
-#define VIDISD14C_ALPHA1_B_SHIFT (0)
-#define VIDISD14C_ALPHA1_B_LIMIT (0xf)
+#define VIDISD14C_ALPHA1_B_SHIFT 0
+#define VIDISD14C_ALPHA1_B_LIMIT 0xf
#define VIDISD14C_ALPHA1_B(_x) ((_x) << 0)
/* Video buffer addresses */
@@ -300,22 +295,22 @@
#define VIDW_BUF_SIZE_OFFSET_E(_x) ((((_x) & 0x2000) >> 13) << 27)
#define VIDW_BUF_SIZE_OFFSET_MASK (0x1fff << 13)
-#define VIDW_BUF_SIZE_OFFSET_SHIFT (13)
-#define VIDW_BUF_SIZE_OFFSET_LIMIT (0x1fff)
+#define VIDW_BUF_SIZE_OFFSET_SHIFT 13
+#define VIDW_BUF_SIZE_OFFSET_LIMIT 0x1fff
#define VIDW_BUF_SIZE_OFFSET(_x) (((_x) & 0x1fff) << 13)
#define VIDW_BUF_SIZE_PAGEWIDTH_E(_x) ((((_x) & 0x2000) >> 13) << 26)
#define VIDW_BUF_SIZE_PAGEWIDTH_MASK (0x1fff << 0)
-#define VIDW_BUF_SIZE_PAGEWIDTH_SHIFT (0)
-#define VIDW_BUF_SIZE_PAGEWIDTH_LIMIT (0x1fff)
+#define VIDW_BUF_SIZE_PAGEWIDTH_SHIFT 0
+#define VIDW_BUF_SIZE_PAGEWIDTH_LIMIT 0x1fff
#define VIDW_BUF_SIZE_PAGEWIDTH(_x) (((_x) & 0x1fff) << 0)
/* Interrupt controls and status */
-#define VIDINTCON0 (0x130)
+#define VIDINTCON0 0x130
#define VIDINTCON0_FIFOINTERVAL_MASK (0x3f << 20)
-#define VIDINTCON0_FIFOINTERVAL_SHIFT (20)
-#define VIDINTCON0_FIFOINTERVAL_LIMIT (0x3f)
+#define VIDINTCON0_FIFOINTERVAL_SHIFT 20
+#define VIDINTCON0_FIFOINTERVAL_LIMIT 0x3f
#define VIDINTCON0_FIFOINTERVAL(_x) ((_x) << 20)
#define VIDINTCON0_INT_SYSMAINCON (1 << 19)
@@ -323,7 +318,7 @@
#define VIDINTCON0_INT_I80IFDONE (1 << 17)
#define VIDINTCON0_FRAMESEL0_MASK (0x3 << 15)
-#define VIDINTCON0_FRAMESEL0_SHIFT (15)
+#define VIDINTCON0_FRAMESEL0_SHIFT 15
#define VIDINTCON0_FRAMESEL0_BACKPORCH (0x0 << 15)
#define VIDINTCON0_FRAMESEL0_VSYNC (0x1 << 15)
#define VIDINTCON0_FRAMESEL0_ACTIVE (0x2 << 15)
@@ -338,7 +333,7 @@
#define VIDINTCON0_INT_FRAME (1 << 12)
#define VIDINTCON0_FIFIOSEL_MASK (0x7f << 5)
-#define VIDINTCON0_FIFIOSEL_SHIFT (5)
+#define VIDINTCON0_FIFIOSEL_SHIFT 5
#define VIDINTCON0_FIFIOSEL_WINDOW0 (0x1 << 5)
#define VIDINTCON0_FIFIOSEL_WINDOW1 (0x2 << 5)
#define VIDINTCON0_FIFIOSEL_WINDOW2 (0x10 << 5)
@@ -346,7 +341,7 @@
#define VIDINTCON0_FIFIOSEL_WINDOW4 (0x40 << 5)
#define VIDINTCON0_FIFOLEVEL_MASK (0x7 << 2)
-#define VIDINTCON0_FIFOLEVEL_SHIFT (2)
+#define VIDINTCON0_FIFOLEVEL_SHIFT 2
#define VIDINTCON0_FIFOLEVEL_TO25PC (0x0 << 2)
#define VIDINTCON0_FIFOLEVEL_TO50PC (0x1 << 2)
#define VIDINTCON0_FIFOLEVEL_TO75PC (0x2 << 2)
@@ -354,46 +349,46 @@
#define VIDINTCON0_FIFOLEVEL_FULL (0x4 << 2)
#define VIDINTCON0_INT_FIFO_MASK (0x3 << 0)
-#define VIDINTCON0_INT_FIFO_SHIFT (0)
+#define VIDINTCON0_INT_FIFO_SHIFT 0
#define VIDINTCON0_INT_ENABLE (1 << 0)
-#define VIDINTCON1 (0x134)
+#define VIDINTCON1 0x134
#define VIDINTCON1_INT_I180 (1 << 2)
#define VIDINTCON1_INT_FRAME (1 << 1)
#define VIDINTCON1_INT_FIFO (1 << 0)
/* Window colour-key control registers */
-#define WKEYCON (0x140) /* 6410,V210 */
+#define WKEYCON 0x140
-#define WKEYCON0 (0x00)
-#define WKEYCON1 (0x04)
+#define WKEYCON0 0x00
+#define WKEYCON1 0x04
#define WxKEYCON0_KEYBL_EN (1 << 26)
#define WxKEYCON0_KEYEN_F (1 << 25)
#define WxKEYCON0_DIRCON (1 << 24)
#define WxKEYCON0_COMPKEY_MASK (0xffffff << 0)
-#define WxKEYCON0_COMPKEY_SHIFT (0)
-#define WxKEYCON0_COMPKEY_LIMIT (0xffffff)
+#define WxKEYCON0_COMPKEY_SHIFT 0
+#define WxKEYCON0_COMPKEY_LIMIT 0xffffff
#define WxKEYCON0_COMPKEY(_x) ((_x) << 0)
#define WxKEYCON1_COLVAL_MASK (0xffffff << 0)
-#define WxKEYCON1_COLVAL_SHIFT (0)
-#define WxKEYCON1_COLVAL_LIMIT (0xffffff)
+#define WxKEYCON1_COLVAL_SHIFT 0
+#define WxKEYCON1_COLVAL_LIMIT 0xffffff
#define WxKEYCON1_COLVAL(_x) ((_x) << 0)
/* Dithering control */
-#define DITHMODE (0x170)
+#define DITHMODE 0x170
#define DITHMODE_R_POS_MASK (0x3 << 5)
-#define DITHMODE_R_POS_SHIFT (5)
+#define DITHMODE_R_POS_SHIFT 5
#define DITHMODE_R_POS_8BIT (0x0 << 5)
#define DITHMODE_R_POS_6BIT (0x1 << 5)
#define DITHMODE_R_POS_5BIT (0x2 << 5)
#define DITHMODE_G_POS_MASK (0x3 << 3)
-#define DITHMODE_G_POS_SHIFT (3)
+#define DITHMODE_G_POS_SHIFT 3
#define DITHMODE_G_POS_8BIT (0x0 << 3)
#define DITHMODE_G_POS_6BIT (0x1 << 3)
#define DITHMODE_G_POS_5BIT (0x2 << 3)
#define DITHMODE_B_POS_MASK (0x3 << 1)
-#define DITHMODE_B_POS_SHIFT (1)
+#define DITHMODE_B_POS_SHIFT 1
#define DITHMODE_B_POS_8BIT (0x0 << 1)
#define DITHMODE_B_POS_6BIT (0x1 << 1)
#define DITHMODE_B_POS_5BIT (0x2 << 1)
@@ -403,18 +398,18 @@
#define WINxMAP(_win) (0x180 + ((_win) * 4))
#define WINxMAP_MAP (1 << 24)
#define WINxMAP_MAP_COLOUR_MASK (0xffffff << 0)
-#define WINxMAP_MAP_COLOUR_SHIFT (0)
-#define WINxMAP_MAP_COLOUR_LIMIT (0xffffff)
+#define WINxMAP_MAP_COLOUR_SHIFT 0
+#define WINxMAP_MAP_COLOUR_LIMIT 0xffffff
#define WINxMAP_MAP_COLOUR(_x) ((_x) << 0)
/* Winodw palette control */
-#define WPALCON (0x1A0)
+#define WPALCON 0x1A0
#define WPALCON_PAL_UPDATE (1 << 9)
#define WPALCON_W4PAL_16BPP_A555 (1 << 8)
#define WPALCON_W3PAL_16BPP_A555 (1 << 7)
#define WPALCON_W2PAL_16BPP_A555 (1 << 6)
#define WPALCON_W1PAL_MASK (0x7 << 3)
-#define WPALCON_W1PAL_SHIFT (3)
+#define WPALCON_W1PAL_SHIFT 3
#define WPALCON_W1PAL_25BPP_A888 (0x0 << 3)
#define WPALCON_W1PAL_24BPP (0x1 << 3)
#define WPALCON_W1PAL_19BPP_A666 (0x2 << 3)
@@ -423,7 +418,7 @@
#define WPALCON_W1PAL_16BPP_A555 (0x5 << 3)
#define WPALCON_W1PAL_16BPP_565 (0x6 << 3)
#define WPALCON_W0PAL_MASK (0x7 << 0)
-#define WPALCON_W0PAL_SHIFT (0)
+#define WPALCON_W0PAL_SHIFT 0
#define WPALCON_W0PAL_25BPP_A888 (0x0 << 0)
#define WPALCON_W0PAL_24BPP (0x1 << 0)
#define WPALCON_W0PAL_19BPP_A666 (0x2 << 0)
@@ -433,7 +428,7 @@
#define WPALCON_W0PAL_16BPP_565 (0x6 << 0)
/* Blending equation control */
-#define BLENDCON (0x260)
+#define BLENDCON 0x260
#define BLENDCON_NEW_MASK (1 << 0)
#define BLENDCON_NEW_8BIT_ALPHA_VALUE (1 << 0)
#define BLENDCON_NEW_4BIT_ALPHA_VALUE (0 << 0)
@@ -460,8 +455,8 @@
*/
/* FIMD Version 8 register offset definitions */
-#define FIMD_V8_VIDTCON0 (0x20010)
-#define FIMD_V8_VIDTCON1 (0x20014)
-#define FIMD_V8_VIDTCON2 (0x20018)
-#define FIMD_V8_VIDTCON3 (0x2001C)
-#define FIMD_V8_VIDCON1 (0x20004)
+#define FIMD_V8_VIDTCON0 0x20010
+#define FIMD_V8_VIDTCON1 0x20014
+#define FIMD_V8_VIDTCON2 0x20018
+#define FIMD_V8_VIDTCON3 0x2001C
+#define FIMD_V8_VIDCON1 0x20004
--
1.7.2.5
^ permalink raw reply related
* [PATCH 2/4] video: s3c-fb: remove duplicated S3C_FB_MAX_WIN
From: Jingoo Han @ 2012-12-26 8:14 UTC (permalink / raw)
To: linux-fbdev
S3C_FB_MAX_WIN is already defined in 'plat-samsung/include/plat/fb.h'.
So, this definition in 'include/video/samsung_fimd.h' should be
removed to avoid the duplication.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
include/video/samsung_fimd.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index e755448..0865256 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -438,8 +438,6 @@
#define BLENDCON_NEW_8BIT_ALPHA_VALUE (1 << 0)
#define BLENDCON_NEW_4BIT_ALPHA_VALUE (0 << 0)
-#define S3C_FB_MAX_WIN (5) /* number of hardware windows available. */
-
/* Notes on per-window bpp settings
*
* Value Win0 Win1 Win2 Win3 Win 4
--
1.7.2.5
^ permalink raw reply related
* [PATCH 1/4] video: s3c-fb: use ARCH_ dependancy
From: Jingoo Han @ 2012-12-26 8:13 UTC (permalink / raw)
To: linux-fbdev
This patch uses ARCH_ dependancy when using s3c-fb.
S3C_DEV_FB, S5P_DEV_FIMD0 cannot be enabled on EXYNOS5.
So, ARCH_ should be used as dependancy for s3c-fb.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/Kconfig | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index e7068c5..049fff1 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2025,7 +2025,8 @@ config FB_TMIO_ACCELL
config FB_S3C
tristate "Samsung S3C framebuffer support"
- depends on FB && (S3C_DEV_FB || S5P_DEV_FIMD0)
+ depends on FB && (CPU_S3C2416 || ARCH_S3C64XX || ARCH_S5P64X0 || \
+ ARCH_S5PC100 || ARCH_S5PV210 || ARCH_EXYNOS)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
1.7.2.5
^ permalink raw reply related
* [PATCH] drivers: video: fix warnings int-to-pointer-cast
From: Stefan Hasko @ 2012-12-24 21:44 UTC (permalink / raw)
To: Florian Tobias Schandinat, linux-fbdev; +Cc: linux-kernel, Stefan Hasko
Fixed compile warnings cast to pointer from integer of different size
Signed-off-by: Stefan Hasko <hasko.stevo@gmail.com>
---
drivers/video/arkfb.c | 2 +-
drivers/video/s3fb.c | 2 +-
drivers/video/vt8623fb.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/arkfb.c b/drivers/video/arkfb.c
index 555dd4c..3e4ed96 100644
--- a/drivers/video/arkfb.c
+++ b/drivers/video/arkfb.c
@@ -1016,7 +1016,7 @@ static int __devinit ark_pci_probe(struct pci_dev *dev, const struct pci_device_
pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
- par->state.vgabase = (void __iomem *) vga_res.start;
+ par->state.vgabase = (void __iomem *)(unsigned long) vga_res.start;
/* FIXME get memsize */
regval = vga_rseq(par->state.vgabase, 0x10);
diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c
index 1d00736..def0a86 100644
--- a/drivers/video/s3fb.c
+++ b/drivers/video/s3fb.c
@@ -1183,7 +1183,7 @@ static int __devinit s3_pci_probe(struct pci_dev *dev, const struct pci_device_i
pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
- par->state.vgabase = (void __iomem *) vga_res.start;
+ par->state.vgabase = (void __iomem *)(unsigned long) vga_res.start;
/* Unlock regs */
cr38 = vga_rcrt(par->state.vgabase, 0x38);
diff --git a/drivers/video/vt8623fb.c b/drivers/video/vt8623fb.c
index 4e74d26..2516808 100644
--- a/drivers/video/vt8623fb.c
+++ b/drivers/video/vt8623fb.c
@@ -729,7 +729,7 @@ static int __devinit vt8623_pci_probe(struct pci_dev *dev, const struct pci_devi
pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
- par->state.vgabase = (void __iomem *) vga_res.start;
+ par->state.vgabase = (void __iomem *)(unsigned long) vga_res.start;
/* Find how many physical memory there is on card */
memsize1 = (vga_rseq(par->state.vgabase, 0x34) + 1) >> 1;
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-24 17:40 UTC (permalink / raw)
To: Rob Clark
Cc: Tomi Valkeinen, Jani Nikula, Thomas Petazzoni,
Linux Fbdev development list, Philipp Zabel, Tom Gall,
Ragesh Radhakrishnan, dri-devel@lists.freedesktop.org,
Kyungmin Park, Benjamin Gaignard, Maxime Ripard, Vikas Sajjan,
Sumit Semwal, Sebastien Guiriec, linux-media@vger.kernel.org,
hans.verkuil
In-Reply-To: <CAF6AEGt6=RhKRnJZJVytzObvxm2GuvwADNhACOR9vnY-9n=ATw@mail.gmail.com>
Hi Rob,
(CC'ing Hans Verkuil)
On Wednesday 19 December 2012 10:05:27 Rob Clark wrote:
> On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote:
> > On 2012-12-19 17:26, Rob Clark wrote:
> >> And, there are also external HDMI encoders (for example connected over
> >> i2c) that can also be shared between boards. So I think there will be
> >> a number of cases where CDF is appropriate for HDMI drivers. Although
> >> trying to keep this all independent of DRM (as opposed to just something
> >> similar to what drivers/gpu/i2c is today) seems a bit overkill for me.
> >> Being able to use the helpers in drm and avoiding an extra layer of
> >> translation seems like the better option to me. So my vote would be
> >> drivers/gpu/cdf.
> >
> > Well, we need to think about that. I would like to keep CDF independent
> > of DRM. I don't like tying different components/frameworks together if
> > there's no real need for that.
> >
> > Also, something that Laurent mentioned in our face-to-face discussions:
> > Some IPs/chips can be used for other purposes than with DRM.
> >
> > He had an example of a board, that (if I understood right) gets video
> > signal from somewhere outside the board, processes the signal with some
> > IPs/chips, and then outputs the signal. So there's no framebuffer, and
> > the image is not stored anywhere. I think the framework used in these
> > cases is always v4l2.
> >
> > The IPs/chips in the above model may be the exact same IPs/chips that
> > are used with "normal" display. If the CDF was tied to DRM, using the
> > same drivers for normal and these streaming cases would probably not be
> > possible.
>
> Well, maybe there is a way, but it really seems to be over-complicating
> things unnecessarily to keep CDF independent of DRM.. there will be a lot
> more traditional uses of CDF compared to one crazy use-case. So I don't
> really fancy making it more difficult than in needs to be for everyone.
Most of the use cases will be in DRM, we agree on that. However, I don't think
that the use case mentioned by Tomi is in any way crazy. TI has DaVinci chips
that can process/capture/generate up to 18 (if my memory is correct) video
streams, and those are extensively used in video conferencing solutions or set
top boxes for instance. A couple of the output video streams are display-based
and should be handled by DRM/KMS, but most of them are V4L2 streams. That's
something we should discuss with Hans Verkuil, he might be able to provide us
with more information.
> Probably the thing to do is take a step back and reconsider that one crazy
> use-case. For example, KMS doesn't enforce that the buffer handled passed
> when you create a drm framebuffer object to scan out is a GEM buffer. So on
> that one crazy platform, maybe it makes sense to have a DRM/KMS display
> driver that takes a handle to identify which video stream coming from the
> capture end of the pipeline. Anyways, that is just an off-the-top-of-my-
> head idea, probably there are other options too.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-24 17:35 UTC (permalink / raw)
To: Rob Clark, Maxime Ripard
Cc: Jani Nikula, Tomi Valkeinen, Thomas Petazzoni,
Linux Fbdev development list, Philipp Zabel, Tom Gall,
Ragesh Radhakrishnan, dri-devel@lists.freedesktop.org,
Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal,
Sebastien Guiriec, linux-media@vger.kernel.org
In-Reply-To: <CAF6AEGuSt0CL2sFGK-PZnw6+r9zhGHO4CEjJEWaR8eGhks2=UQ@mail.gmail.com>
Hi Rob,
On Wednesday 19 December 2012 09:26:40 Rob Clark wrote:
> On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula wrote:
> > On Tue, 18 Dec 2012, Laurent Pinchart wrote:
> >> On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
> >>> 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 ?
> >
> > It just seems to me that, at least from a DRM/KMS perspective, adding
> > another layer (ÍF) for HDMI or DP (or legacy outputs) would be
> > overengineering it. They are pretty well standardized, and I don't see
> > there would be a need to write multiple display drivers for them. Each
> > display controller has one, and can easily handle any chip specific
> > requirements right there. It's my gut feeling that an additional
> > framework would just get in the way. Perhaps there could be more common
> > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
> > but that's another thing.
> >
> > So is the HDMI/DP drivers using CDF a more interesting idea from a
> > non-DRM perspective? Or, put another way, is it more of an alternative
> > to using DRM? Please enlighten me if there's some real benefit here that
> > I fail to see!
>
> fwiw, I think there are at least a couple cases where multiple SoC's
> have the same HDMI IP block.
>
> And, there are also external HDMI encoders (for example connected over
> i2c) that can also be shared between boards. So I think there will be
> a number of cases where CDF is appropriate for HDMI drivers. Although
> trying to keep this all independent of DRM (as opposed to just
> something similar to what drivers/gpu/i2c is today) seems a bit
> overkill for me. Being able to use the helpers in drm and avoiding an
> extra layer of translation seems like the better option to me. So my
> vote would be drivers/gpu/cdf.
I don't think there will be any need for translation (except perhaps between
the DRM mode structures and the common video mode structure that is being
discussed). Add a drm_ prefix to the existing CDF functions and structures,
and there you go :-)
The reason why I'd like to keep CDF separate from DRM (or at least not
requiring a drm_device) is that HDMI/DP encoders can be used by pure V4L2
drivers.
> > For DSI panels (or DSI-to-whatever bridges) it's of course another
> > story. You typically need a panel specific driver. And here I see the
> > main point of the whole CDF: decoupling display controllers and the
> > panel drivers, and sharing panel (and converter chip) specific drivers
> > across display controllers. Making it easy to write new drivers, as
> > there would be a model to follow. I'm definitely in favour of coming up
> > with some framework that would tackle that.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-24 17:31 UTC (permalink / raw)
To: Tomi Valkeinen, Maxime Ripard
Cc: Jani Nikula, Thomas Petazzoni, linux-fbdev, Philipp Zabel,
Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark,
Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal,
Sebastien Guiriec, linux-media
In-Reply-To: <50D1D846.6010005@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]
Hi Tomi,
On Wednesday 19 December 2012 17:07:50 Tomi Valkeinen wrote:
> On 2012-12-19 16:57, Jani Nikula wrote:
> > It just seems to me that, at least from a DRM/KMS perspective, adding
> > another layer (=CDF) for HDMI or DP (or legacy outputs) would be
> > overengineering it. They are pretty well standardized, and I don't see
> > there would be a need to write multiple display drivers for them. Each
> > display controller has one, and can easily handle any chip specific
> > requirements right there. It's my gut feeling that an additional
> > framework would just get in the way. Perhaps there could be more common
> > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
> > but that's another thing.
> >
> > So is the HDMI/DP drivers using CDF a more interesting idea from a
> > non-DRM perspective? Or, put another way, is it more of an alternative
> > to using DRM? Please enlighten me if there's some real benefit here that
> > I fail to see!
>
> The use of CDF is an option, not something that has to be done. A DRM
> driver developer may use it if it gives benefit for him for that
> particular driver.
>
> I don't know much about desktop display hardware, but I guess that using
> CDF would not really give much there. In some cases it could, if the IPs
> used on the graphics card are something that are used elsewhere also
> (sounds quite unlikely, though). In that case there could be separate
> drivers for the IPs.
>
> And note that CDF is not really about the dispc side, i.e. the part that
> creates the video stream from pixels in the memory. It's more about the
> components after that, and how to connect those components.
>
> > For DSI panels (or DSI-to-whatever bridges) it's of course another
> > story. You typically need a panel specific driver. And here I see the
> > main point of the whole CDF: decoupling display controllers and the
> > panel drivers, and sharing panel (and converter chip) specific drivers
> > across display controllers. Making it easy to write new drivers, as
> > there would be a model to follow. I'm definitely in favour of coming up
> > with some framework that would tackle that.
>
> Right. But if you implement drivers for DSI panels with CDF for, say,
> OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP.
> Otherwise it'll be a mishmash with two different models.
I second your point here, using CDF for encoders should be simpler, but it
will not be enforced. A display controller driver developer who wants to
control the on-SoC encoder without conforming to the CDF model will be totally
free to do so and won't be blamed.
--
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-24 17:27 UTC (permalink / raw)
To: Jani Nikula, Maxime Ripard
Cc: Tomi Valkeinen, Thomas Petazzoni, linux-fbdev, Philipp Zabel,
Tom Gall, Ragesh Radhakrishnan, dri-devel, Rob Clark,
Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal,
Sebastien Guiriec, linux-media
In-Reply-To: <87pq26ay2z.fsf@intel.com>
Hi Jani,
On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote:
> On Tue, 18 Dec 2012, Laurent Pinchart wrote:
> > On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
> >> 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 ?
>
> It just seems to me that, at least from a DRM/KMS perspective, adding
> another layer (ÍF) for HDMI or DP (or legacy outputs) would be
> overengineering it. They are pretty well standardized, and I don't see there
> would be a need to write multiple display drivers for them. Each display
> controller has one, and can easily handle any chip specific requirements
> right there. It's my gut feeling that an additional framework would just get
> in the way. Perhaps there could be more common HDMI/DP helper style code in
> DRM to reduce overlap across KMS drivers, but that's another thing.
>
> So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM
> perspective? Or, put another way, is it more of an alternative to using DRM?
> Please enlighten me if there's some real benefit here that I fail to see!
As Rob pointed out, you can have external HDMI/DP encoders, and even internal
HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at
sharing a single driver between SoCs and boards for a given HDMI/DP encoder.
CDF isn't an alternative to DRM/KMS. It should be seen as a framework that
helps DRM/KMS drivers (as well as V4L2 drivers, and possibly FBDEV drivers,
although those should be ported to DRM/KMS) sharing encoder and connector
code.
> For DSI panels (or DSI-to-whatever bridges) it's of course another story.
> You typically need a panel specific driver. And here I see the main point of
> the whole CDF: decoupling display controllers and the panel drivers, and
> sharing panel (and converter chip) specific drivers across display
> controllers. Making it easy to write new drivers, as there would be a model
> to follow. I'm definitely in favour of coming up with some framework that
> would tackle that.
That's the main (and original) goal of CDF (originally called Generic Panel
Framwork, and renamed to CDF to support encoder drivers as explained above).
I'm glad to know that you're in favour of it :-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-24 17:19 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: Rob Clark, Dave Airlie, 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: <50D04C97.4080104@gmail.com>
Hi Sylwester,
On Tuesday 18 December 2012 11:59:35 Sylwester Nawrocki wrote:
> 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 agree with you, or at least I believe we should research a proper
solution in the PM framework. In the meantime, though, I think early
suspend/late resume might provide an intermediate solution.
> > 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
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-24 17:09 UTC (permalink / raw)
To: Marcus Lorentzon
Cc: Dave Airlie, 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, Vikas
In-Reply-To: <50D047CF.2040904@stericsson.com>
Hi Marcus,
On Tuesday 18 December 2012 11:39:11 Marcus Lorentzon wrote:
> 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.
On the topic of discussions, would anyone be interested in a
BoF/brainstorming/whatever session during the FOSDEM ?
> > 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?
Tomi Valkeinen proposed dropping the DSI and DBI busses in favor of the
platform bus. Although I still believe that DSI and DBI busses would make
sense, I agree that they don't provide much in terms of probing and power
management. You can read the discussion at http://www.spinics.net/lists/linux-
fbdev/msg09250.html.
> 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.
I don't either. CDF will mostly target KMS connectors, and can also be used
for KMS encoders. I have no plan to touch the CRTC.
> 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.
That's a topic I was planning to discuss at some point. One of the issues is
that the KMS model can only have 3 entities in the pipeline, while hardware
pipelines (especially in the embedded world) could be made of 4 or more
entities (such as CRTC -> DSI encoder -> DSI to HDMI converter -> HDMI
connector). We might not have to expose all details to userspace, but we need
mapping rules.
> 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?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-24 14:12 UTC (permalink / raw)
To: Tomasz Figa
Cc: dri-devel, Vikas Sajjan, Thomas Petazzoni, linux-fbdev,
Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark,
Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu,
Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec,
linux-media
In-Reply-To: <7255068.DBf2OgseHL@amdc1227>
Hi Tomasz,
On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
> On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
> > On 17 December 2012 20:55, Laurent Pinchart 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.
>
> I am currently in progress of reworking Exynos MIPI DSIM code and s6e8ax0
> LCD driver to use the v2 RFC of Common Display Framework. I have most of
> the work done, I have just to solve several remaining problems.
Do you already have code that you can publish ? I'm particularly interested
(and I think Tomi Valkeinen would be as well) in looking at the DSI operations
you expose to DSI sinks (panels, transceivers, ...).
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-24 14:08 UTC (permalink / raw)
To: Inki Dae
Cc: Daniel Vetter, Rob Clark, Dave Airlie, Thomas Petazzoni,
Linux Fbdev development list, Benjamin Gaignard, Tom Gall,
Kyungmin Park, dri-devel@lists.freedesktop.org,
Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu,
Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec,
linux-media@vger.kernel.org
In-Reply-To: <CAAQKjZMt+13oooEw39mOM1rF2=ss4ih1s7iVS362di-50h4+Hg@mail.gmail.com>
Hi Inki,
On Tuesday 18 December 2012 18:38:31 Inki Dae wrote:
> 2012/12/18 Daniel Vetter <daniel@ffwll.ch>
> > 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.
>
> I think the one reason that the CDF was appeared is to avoid duplicating
> codes. For example, we should duplicate mipi-dsi or dbi drivers into drm to
> avoid ordering issue. And for this, those should be re-implemented in based
> on drm framework so that those could be treated as all one device.
> Actually, in case of Exynos, some guys tried to duplicate eDP driver into
> exynos drm framework in same issue. So I think the best way is to avoid
> duplicating codes and resolve ordering issue such as s/r operations between
> all the various components.
>
> And the below is my opinion,
>
> +--------------------------------+
> Display Controller -------- CDF --------- |MIPI-DSI/DBI-----------LCD Panel|
> +--------------------------------+
>
> 1. to access MIPI-DSI/DBI and LCD Panel drivers.
> - Display Controller is controlled by linux framebuffer or drm kms
> based specific drivers like now. And each driver calls some interfaces of
> CDF.
>
> 2. to control the power of these devices.
> - drm kms based specific driver calls dpms operation and next the dpms
> operation calls fb blank operation of linux framebuffer.
> But for this, we need some interfaces that it can connect between drm
> and linux framebuffer framework and you can refer to the below link.
>
> http://lists.freedesktop.org/archives/dri-devel/2011-July/013242.html
(Just FYI, I plan to clean up the backlight framework when I'll be done with
CDF, to remove the FBDEV dependency)
> - linux framebuffer based driver calls fb blank operation.
>
> fb blank(fb)---------pm runtime(fb)-----------fb_blank----------mipi and lcd
> dpms(drm kms)--------pm runtime(drm kms)------fb_blank----------mipi and lcd
>
> 3. suspend/resume
> - pm suspend/resume are implemented only in linux framebuffer or drm
> kms based specific drivers.
> - MIPI-DSI/DBI and LCD Panel drivers are controlled only by fb blank
> interfaces.
>
> s/r(fb)------------------------pm runtime(fb)--------fb blank---mipi and lcd
> s/r(drm kms)---dpms(drm kms)---pm runtime(drm kms)---fb_blank---mipi and lcd
>
>
> We could resolve ordering issue to suspend/resume simply duplicating
> relevant drivers but couldn't avoid duplicating codes. So I think we could
> avoid the ordering issue using fb blank interface of linux framebuffer and
> also duplicating codes.
As I mentioned before, we have multiple ordering issues related to suspend and
resume. Panels and display controllers will likely want to enforce a S/R order
on the video bus, and control busses will also require a specific S/R order.
My plan is to use early suspend/late resume in the display controller driver
to control the video busses, and let the PM core handle control bus ordering
issues. This will of course need to be prototyped and tested.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-24 13:39 UTC (permalink / raw)
To: Daniel Vetter
Cc: Rob Clark, Dave Airlie, Thomas Petazzoni,
Linux Fbdev development list, Benjamin Gaignard, Tom Gall,
Kyungmin Park, dri-devel@lists.freedesktop.org,
Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu,
Maxime Ripard, Vikas Sajjan, Sumit Semwal, Sebastien Guiriec,
linux-media@vger.kernel.org
In-Reply-To: <CAKMK7uF3Ahh8isvzZr4605X3wz-TQ2EHreTUnc5K_Z0DwrY6xw@mail.gmail.com>
Hi Daniel,
On Tuesday 18 December 2012 09:30:00 Daniel Vetter wrote:
> 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.
I totally agree. As explained in my replies to Dave and Rob, I don't want to
share devices between the different subsystems at runtime, but I'd like to
avoid writing two drivers for a single device that can be used for display and
graphics on one board, and video output on another board (HDMI transmitters
are a good example).
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-24 13:37 UTC (permalink / raw)
To: Rob Clark
Cc: Dave Airlie, 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>
Hi Rob,
On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
> 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.
I tend to agree, except that I try to reuse the existing PM infrastructure
when possible to avoid reinventing the wheel. So far handling suspend/resume
ordering related to data busses in early suspend/late resume operations and
allowing the Linux PM core to handle control busses using the Linux device
tree worked pretty well.
> 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.
We've tried that in V4L2 years ago and realized that the approach led to a
dead-end, especially when OF/DT got involved. With DT-based device probing,
I2C camera sensors started getting probed asynchronously to the main camera
device, as they are children of the I2C bus master. We will have similar
issues with I2C HDMI transmitters or panels, so we should be prepared for it.
On PC hardware the I2C devices are connected to an I2C master provided by the
GPU, but on embedded devices they are usually connected to an independent I2C
master. We thus can't have a single self-contained driver that controls
everything internally, and need to interface with the rest of the SoC drivers.
I agree that probing/removing devices independently of the master driver can
lead to bad surprises, which is why I want to establish clear rules in CDF
regarding what can and can't be done with display entities. Reference counting
will be one way to make sure that devices don't disappear all of a sudden.
> > 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)..
Agreed. I've started to advocate the deprecation of FBDEV during LPC. The
positive response has motivated me to continue doing so :-) For V4L2 the
situation is a little bit different, I think V4L2 shouldn't be used for
graphics and display hardware, but it still has use cases on the video output
side for pure video devices (such as pass-through video pipelines with
embedded processing for instance). As those can use subdevices found in
display and graphics hardware, I'd like to avoid code duplication.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-24 13:24 UTC (permalink / raw)
To: Dave Airlie
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, Tomi Valkeinen,
Vikas Sajjan
In-Reply-To: <CAPM=9txFJzJ0haTyBnr8hEmmqNb+gSAyBno+Zs0Z-qvVMTwz9A@mail.gmail.com>
Hi Dave,
On Tuesday 18 December 2012 15:04:02 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:
>
> 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.
We share the same concern, although my analysis of the problem is somewhat
different. The power management ordering issues isn't only caused by the
software architecture, but also comes from complex hardware requirements. The
root cause, in my opinion, is the split control and data busses: as soon as a
device sits on multiple busses and has power management ordering requirements
related to those busses the Linux power management model breaks. Note that the
problem isn't restricted to the display, we have run into the exact same
issues years ago on the video capture side.
> How do you enforce ordering of s/r operations between all the various
> components?
The way we have handled this problem on the camera side is to use early
suspend and late resume operations to handle the data (video) busses suspend
and resume operations, and let the kernel handle the rest using the control
bus based device tree model. The camera controller stops the video pipeline in
its early suspend operation (and resumes it in the late resume operation) by
calling operations provided by the entities (through function pointers of
course, we don't want direct dependencies between the drivers). The control
suspend/resume (such as sending a standby command through I2C to put the chip
in low-power mode, or turning its power supply or clock off) is then handled
by the PM core.
> 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 think there's a misunderstanding here. I'm definitely not trying to create a
framework to expose the FBDEV/KMS/V4L2 APIs through different drivers on top
of the same hardware device. That's an idea I really dislike, and I fully
agree that the FBDEV API should be provided on top of KMS using the DRM FBDEV
emulation layer. V4L2 on top of KMS doesn't make too much sense to me, as V4L2
isn't really a display and graphics API anyway.
My goal here is to share code for chips that are used by different "devices"
(in the sense of an agregate device, such as a camera or a graphics card)
supported by different subsystems. For instance, the same I2C-controlled HDMI
transmitter can be used by a display device when connected to a display
controller on an SoC, but can also be used by a video output device when
connected to a video output (some complex TI SoCs have pass-through video
pipelines with no associated frame buffer, making the V4L2 API better suited
than DRM/KMS). As the first device would be supported by a DRM/KMS driver and
the second device by a pure V4L2 driver, we need a common framework to share
code between both.
If the same framework can be used to share panel drivers between DRM/KMS and
pure FBDEV drivers (we have a bunch of those, not all of them will be ported
to DRM/KMS, at least not in the very near future) that's also a bonus.
To summarize my point, CDF aims at creating a self-contained framework that
can be used by FBDEV, DRM/KMS and V4L2 drivers to interface with various
display-related devices. It does not provide any userspace API, and does not
offer any way to share devices between the three subsystems at runtime. In a
way you can think of CDF as a DRM panel framework, but without the drm_
prefix.
I hope this clarifies my goals. If not, or if there's still concerns and/or
disagreements, let's discuss them.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Laurent Pinchart @ 2012-12-24 12:59 UTC (permalink / raw)
To: Vikas Sajjan
Cc: Jesse Barker, Ragesh Radhakrishnan, Tomi Valkeinen,
Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall, dri-devel,
Rob Clark, Kyungmin Park, Benjamin Gaignard, Bryan Wu,
Maxime Ripard, Sumit Semwal, Sebastien Guiriec, linux-media,
sunil joshi
In-Reply-To: <CAD025yQoCiNaKvaCwvUWhk_jV70CPhV35UzV9MR6HtE+1baCxg@mail.gmail.com>
Hi Vikas,
On Tuesday 18 December 2012 08:31:30 Vikas Sajjan wrote:
> On 17 December 2012 20:55, Laurent Pinchart 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.
After discussing the DBI/DSI busses with Tomi Valkeinen we concluded that
creating a real bus for DBI and DSI, although possible, wasn't required. DSI
operations should thus be provided through display entity video source
operations. You can find a proposed implementation in Tomi's patch set.
> > 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
^ permalink raw reply
* Re: [RFC 0/6] Common Display Framework-T
From: Vikas Sajjan @ 2012-12-24 7:15 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-fbdev, Tomi Valkeinen, dri-devel
In-Reply-To: <5024715.KeGkjOKZ3Q@avalon>
Hi Laurent,
On Wed, Dec 19, 2012 at 6:51 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Tomi,
>
> On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote:
>> Hi,
>>
>> I have been testing Common Display Framework on OMAP, and making changes
>> that I've discussed in the posts I've sent in reply to the CDF series from
>> Laurent. While my CDF code is rather hacky and not at all ready, I wanted
>> to post the code for comments and also as a reference code to my posts.
>>
>> So here is CDF-T (Tomi-edition =).
>
> We've discussed your approach extensively face-to-face today so I won't review
> the patches in detail, but I will instead summarize our discussion to make
> sure we understood each other (and let other developers jump in).
>
> For the purpose of this discussion the term "display controller driver" (or
> just "display controller") refer to both the low-level driver layer that
> communicates directly with the display controller hardware, and to the higher-
> level driver layer that implements and exposes the userspace API (FBDEV, KMS
> and/or V4L). Those layers can be implemented in multiple kernel modules (such
> as in the OMAP DSS case, with omapdss for the low-level layer and omapdrm,
> omapfb and omapvout for the API-level layer) or a single kernel module.
>
> Control model
> -------------
>
> The figure at http://www.ideasonboard.org/media/cdf/cdf-panel-control-
> model.png shows the CDF control model.
>
> The panel object depicted on the figure doesn't need to be a panel in the
> stricter sense but could be any chain of off-SoC (both on-board or off-board)
> display entities. It however helps thinking about it as a panel and doesn't
> hurt the model.
>
> The panel is controlled through abstract control requests. Those requests are
> used to retrieve panel information (such as the physical size, the supported
> video modes, EDID information, ...), set the panel configuration (such as the
> active video timings) or control the panel operation state (enabling/disabling
> the panel, controlling panel blanking and power management, ...). They are
> exposed by the panel using function pointers, and called by other kernel
> components in response to userspace requests (through the FBDEV, KMS or V4L2
> APIs) or in-kernel events (for instance hotplug notifications).
>
> In response to the control requests the panel driver will communicate with the
> panel through the panel control bus (I2C, SPI, DBI, DSI, GPIO, ..., not shown
> on the figure) and will control the video stream it receives on its input.
>
> The panel is connected at the hardware level to a video source (shown as a
> green hashed rectangle) that provides it with a video stream. The video stream
> flows from the video source to the panel and is directly controlled by its
> source, as shown by the green arrow from the display controller to the video
> stream. The video source exposes stream control operations as function
> pointers that are used by the panel to control the video stream, as shown by
> the green arrow from the panel to the video source.
>
> The figure at http://www.ideasonboard.org/media/cdf/cdf-panel-control-
> model-2.png shows the call flow across entities when the panel is a pipeline
> made of more than a single entity. In this case the SoC (on the left of the
> dashed line) outputs a video stream on a DSI bus connected to a DSI to LVDS
> transmitter. The output of the DSI to LVDS transmitter is connected to an LVDS
> panel (or, more accurately, an LVDS panel module made of an LVDS panel
> controller and a panel).
>
> The transmitter and panel module are seen by the display controller and
> userspace API implementations as a single entity that exposes control request
> operations and controls its input video stream. When a control request is
> performed (outermost green arrow) the DSI to LVDS transmitter will propagate
> it to the panel, possibly mangling the input parameters or the response. For
> panel operation state control requests the last entity in the pipeline will
> likely want to control the video stream it receives on its input. The video
> stream control calls will be propagated from right to left as shown by the red
> arrows.
>
> Every entity in the call stack can communicate with its hardware device
> through the corresponding control bus, and/or control the video stream it
> receives on its input.
>
> This model allows filtering out modes and timings supported by the panel but
> unsupported by the transmitter and mangling the modes and timings according to
> the transmitter limitations. It has no complexity drawback for simple devices,
> as the corresponding drivers can just forward the calls directly. Similar use
> cases could exist for other control operations than mode and information
> retrieval.
>
> Discovery
> ---------
>
> Before being able to issue control requests, panel devices need to be
> discovered and associated with the connected display controller(s).
>
> Panels and display controllers are cross-dependent. There is no way around
> that, as the display controller needs a reference to the panel to call control
> requests in response to userspace API, and the panel needs a reference to the
> display controller to call video stream control functions (in addition to
> requiring generic resources such as clocks, GPIOs or even regulators that
> could be provided by the display controller).
>
> As we can't probe the display controller and the panel together, a probe order
> needs to be defined. The decision was to consider video sources as resources
> and defer panel probing until all required resources (video stream source,
> clocks, GPIOs, regulators and more) are available. Display controller probing
> must succeed without the panel being available. This mimicks the hotpluggable
> monitor model (VGA, HDMI, DP) that doesn't prevent display controllers from
> being successfully probed without a connected monitor.
>
> Our design goal is to handle panel discovery in a similar (if not identical)
> way as HDMI/DP hotplug in order to implement a single display discovery method
> in display controller drivers. This might not be achievable, in which case
> we'll reconsider the design requirement.
>
> When the display controller driver probes the device it will register the
> video source(s) at the output of the display controller with the CDF core.
> Those sources will be identified by the display controller dev_name() and a
> source integer index. A new structure, likely called display_entity_port, will
> be used to represent a source or sink video port on a display entity.
>
> Panel drivers will handle video sources as resources. They will retrieve at
> probe time the video source the panel is connected to using a phandle or a
> source name (depending on whether the platform uses DT). If the source isn't
> available the probe function will return -EPROBE_DEFER.
>
> In addition to the video stream control operations mentioned above, ports will
> also expose a connect/disconnect operation use to notify them of
> connection/disconnection events. After retrieving the connected video source
> panel drivers call the connect/disconnect operation on the video source to
> notify it that the panel is available.
>
> When the panel is a pipeline made of more than a single entity, entities are
> probed in video source to video sink order. Out-of-order probe will result in
> probe deferral as explained above due to the video source not being available,
> resulting in the source to sink probe order. Entities should not call the
> connect operation of their video source at probe time in that case, but only
> when their own connect operation for the video source(s) they provide to the
> next entity is called by the next entity. Connect operations will thus be
> called in sink to source order starting at the entity at the end of the
> pipeline and going all the way back to the display controller.
>
> This notification system is a hotplug mechanism that replaces the display
> entity notifier system from my previous RFC. Alan Cox rightly objected to the
> notification system, arguing that such system-wide notifications were used by
> FBDEV and very subject to abuse. I agree with his argument, this new mechanism
> should result in a cleaner implementation as video sources will only be
> notified of connect/disconnect events for the entity they're connected to.
>
> DBI/DSI busses
> --------------
>
> My RFC introduced a DBI bus using the Linux device and bus model. Its purpose
> was multifold:
>
> - Support (un)registration, matching and binding of devices and drivers.
>
> - Provide power management (suspend/resume) services through the standard
> Linux PM bus/device model, to make sure that DBI devices will be
> suspended/resumed after/before their DBI bus controller.
>
> - Provide bus services to access the connected devices. For DBI that took the
> form of command read and data read/write functions.
>
> A DSI bus implementation using the same model was also planned.
>
> Tomi's patches removed the DBI bus and replaced DBI devices with platform
> devices, moving the bus services implementation to the video source. DBI and
> DSI busses are always either pure video or video + control busses (although
> controlling a DPI panel through DSI is conceivable, nobody in his right mind,
> not even a hardware engineer, would likely implement that), so there will
> always be a video source to provide the DBI/DSI control operations.
>
> (Un)registration, matching and binding of devices and drivers is provided by
> the platform device bus. Bus services to access connected devices are provided
> by the video source, wrapper functions will be used to handle serialization
> and locking, and possibly to offer higher level services (such as DCS for
> instance).
>
> One drawback of using the platform bus is that PM relationships between the
> bus master and slaves will not be taken into account during suspend/resume.
> However, a similar issue exists for DPI panels, and PM relationships at the
> video bus level for DBI and DSI are not handled by the DBI/DSI busses either.
> As we need a generic solution to handle those (likely through early suspend
> and late resume), the same solution can be used to handle DBI and DSI control
> bus PM relationships without requiring a Linux DBI or DSI bus.
>
> Even though I still like the idea of DBI and DSI busses, I agree with Tomi
> that they're not strictly needed and I will drop them.
>
> Entity model
> ------------
>
> Tomi's proposal split the display entities into video sources (struct
> video_source) and display entities (struct display_entity). To make generic
> pipeline operations easier, we agreed to merge the video source and the
> display entity back. struct display_entity thus models a display entity that
> has any number of sink and/or source ports, modeled as struct
> display_entity_port instances.
>
Looking at Tomi's patchset, he has considered panel as "display entity"
and MIPI DSI as "video source entity". So if we are planning to merge it back
how should we treat panel and MIPI DSI. i mean should we consider both
panel and MIPI DSI has 2 different display entities.
i.e, during the probe of each of these drivers, should we register a
display entity with CDF.
> Video stream operations will be exposed by the display entity as function
> pointers and will take a port reference as argument (this could take the form
> of struct display_entity * and port index, or struct display_entity_port *).
> The DVI and DSI operations model proposed by Tomi in this patch series will be
> kept.
>
so you mean you will be adding these "ops" as part of "struct display
entity" rather than video source ops,
static const struct dsi_video_source_ops dsi_dsi_ops = {
.update = dsi_bus_update,
.dcs_write = dsi_bus_dcs_write,
.dcs_read = dsi_bus_dcs_read,
.configure_pins = dsi_bus_configure_pins,
.set_clocks = dsi_bus_set_clocks,
.enable = dsi_bus_enable,
.disable = dsi_bus_disable,
.set_size = dsi_bus_set_size,
.set_operation_mode = dsi_bus_set_operation_mode,
.set_pixel_format = dsi_bus_set_pixel_format,
.enable_hs = dsi_bus_enable_hs,
};
if you can post CDF v3 patches early, it will give us more clarity
w.r.t to discussions you and Tomi had.
> Points that we forgot to discuss
> --------------------------------
>
> - DISPLAY_ENTITY_STREAM_SINGLE_SHOT vs. update() operation
>
> I'll look into that.
>
> Please let me know if I've forgotten anything.
>
> --
> Regards,
>
> Laurent Pinchart
Regards
Vikas Sajjan
Samsung India Software Operations Pvt Ltd.
Bangalore , India.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 11/29] video/uvesafb: rename random32() to prandom_u32()
From: Akinobu Mita @ 2012-12-24 2:13 UTC (permalink / raw)
To: linux-kernel, akpm
Cc: Akinobu Mita, Michal Januszewski, Florian Tobias Schandinat,
linux-fbdev
In-Reply-To: <1356315256-6572-1-git-send-email-akinobu.mita@gmail.com>
Use more preferable function name which implies using a pseudo-random
number generator.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Michal Januszewski <spock@gentoo.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/uvesafb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 2f8f82d..d120b11 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -166,7 +166,7 @@ static int uvesafb_exec(struct uvesafb_ktask *task)
memcpy(&m->id, &uvesafb_cn_id, sizeof(m->id));
m->seq = seq;
m->len = len;
- m->ack = random32();
+ m->ack = prandom_u32();
/* uvesafb_task structure */
memcpy(m + 1, &task->t, sizeof(task->t));
--
1.7.11.7
^ permalink raw reply related
* N/A
From: mrs philips Rita @ 2012-12-22 22:13 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20121222221114.M77589@live.com>
Dear
friend please i need your quick reply do not ignore this email for no reason
i am Mrs.Rita Philips
Thanks and God Be with you
Best Regards
^ permalink raw reply
* N/A
From: mrs philips Rita @ 2012-12-22 22:09 UTC (permalink / raw)
To: linux-fbdev
Dear
friend please i need your quick reply do not ignore this email for no reason
i am Mrs.Rita Philips
Thanks and God Be with you
Best Regards
^ permalink raw reply
* Re: [PATCHv16 0/7] of: add display helper
From: Leela Krishna Amudala @ 2012-12-21 15:48 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, David Airlie,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Florian Tobias Schandinat,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Rob Clark,
Tomi Valkeinen, Laurent Pinchart, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Guennady Liakhovetski, linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1355850256-16135-1-git-send-email-s.trumtrar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hello All,
Any comments for this patch set..?
Best Wishes,
Leela Krishna Amudala.
On Tue, Dec 18, 2012 at 10:34 PM, Steffen Trumtrar
<s.trumtrar@pengutronix.de> wrote:
>
> 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
* Re: [RFC v2 0/5] Common Display Framework
From: Tomasz Figa @ 2012-12-21 10:00 UTC (permalink / raw)
To: dri-devel
Cc: Vikas Sajjan, Laurent Pinchart, Thomas Petazzoni, linux-fbdev,
Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark,
Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu,
Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec,
linux-media
In-Reply-To: <CAD025yQoCiNaKvaCwvUWhk_jV70CPhV35UzV9MR6HtE+1baCxg@mail.gmail.com>
Hi Vikas,
On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
> Hi Laurent,
>
> Thanks for the reply.
>
> 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.
I am currently in progress of reworking Exynos MIPI DSIM code and s6e8ax0
LCD driver to use the v2 RFC of Common Display Framework. I have most of
the work done, I have just to solve several remaining problems.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply
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