* Re: [PATCH V3] video: exynos_dp: Add device tree support to DP driver
From: Jingoo Han @ 2012-10-04 1:50 UTC (permalink / raw)
To: 'Ajay kumar', linux-fbdev
Cc: linux-samsung-soc, FlorianSchandinat, thomas.ab,
'devicetree-discuss', 'Sylwester Nawrocki',
'Tomasz Figa', 'Jingoo Han'
In-Reply-To: <CAEC9eQNFos4Sw57eubX-USEjKBnKf9ETeWCU_sT1vdX3MgN4dA@mail.gmail.com>
On Monday, October 01, 2012 2:40 PM Ajay kumar wrote
>
> On Fri, Sep 28, 2012 at 5:41 AM, Jingoo Han <jg1.han@samsung.com> wrote:
> > On Thursday, September 27, 2012 10:45 PM Sylwester Nawrocki wrote
> >> On 09/24/2012 09:36 PM, Ajay Kumar wrote:
[...]
> >> > +Example:
> >> > +
> >> > +SOC specific portion:
> >> > + dptx_phy: dptx_phy@0x10040720 {
> >> > + compatible = "samsung,dp-phy";
> >> > + samsung,dptx_phy_reg =<0x10040720>;
> >> > + samsung,enable_bit =<1>;
> >> > + };
> >> > +
> >> > + display-port-controller {
> >> > + compatible = "samsung,exynos5-dp";
> >> > + reg =<0x145B0000 0x10000>;
> >> > + interrupts =<10 3>;
> >> > + interrupt-parent =<&combiner>;
> >> > + dp_phy =<&dptx_phy>;
> >>
> >> Shouldn't it be "samsung,dp_phy" ?
> >
> > Do you mean this ? It is not working.
> > + dp_phy = "samsung,dp_phy";
> I din't get this.
> What do I need to change here?
As Tomasz Figa mentioned, it means that
-+ dp_phy =<&dptx_phy>;
++ samsung,dp_phy =<&dptx_phy>;
It is because this is a Samsung-specific property.
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: use clk_prepare_enable and clk_disable_unprepare
From: Jingoo Han @ 2012-10-04 6:18 UTC (permalink / raw)
To: 'Thomas Abraham', linux-fbdev
Cc: FlorianSchandinat, kgene.kim, linux-samsung-soc,
'Jingoo Han'
In-Reply-To: <1349222260-3248-1-git-send-email-thomas.abraham@linaro.org>
On Wednesday, October 03, 2012 8:58 AM Thomas Abraham wrote
>
> Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
> calls as required by common clock framework.
>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
It looks good. Also, I have tested this patch with Exynos4210.
Acked-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
> ---
> drivers/video/s3c-fb.c | 28 ++++++++++++++--------------
> 1 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 52b744f..2ed7b63 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -1404,7 +1404,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
> return PTR_ERR(sfb->bus_clk);
> }
>
> - clk_enable(sfb->bus_clk);
> + clk_prepare_enable(sfb->bus_clk);
>
> if (!sfb->variant.has_clksel) {
> sfb->lcd_clk = devm_clk_get(dev, "sclk_fimd");
> @@ -1414,7 +1414,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
> goto err_bus_clk;
> }
>
> - clk_enable(sfb->lcd_clk);
> + clk_prepare_enable(sfb->lcd_clk);
> }
>
> pm_runtime_enable(sfb->dev);
> @@ -1504,10 +1504,10 @@ err_lcd_clk:
> pm_runtime_disable(sfb->dev);
>
> if (!sfb->variant.has_clksel)
> - clk_disable(sfb->lcd_clk);
> + clk_disable_unprepare(sfb->lcd_clk);
>
> err_bus_clk:
> - clk_disable(sfb->bus_clk);
> + clk_disable_unprepare(sfb->bus_clk);
>
> return ret;
> }
> @@ -1531,9 +1531,9 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
> s3c_fb_release_win(sfb, sfb->windows[win]);
>
> if (!sfb->variant.has_clksel)
> - clk_disable(sfb->lcd_clk);
> + clk_disable_unprepare(sfb->lcd_clk);
>
> - clk_disable(sfb->bus_clk);
> + clk_disable_unprepare(sfb->bus_clk);
>
> pm_runtime_put_sync(sfb->dev);
> pm_runtime_disable(sfb->dev);
> @@ -1561,9 +1561,9 @@ static int s3c_fb_suspend(struct device *dev)
> }
>
> if (!sfb->variant.has_clksel)
> - clk_disable(sfb->lcd_clk);
> + clk_disable_unprepare(sfb->lcd_clk);
>
> - clk_disable(sfb->bus_clk);
> + clk_disable_unprepare(sfb->bus_clk);
>
> pm_runtime_put_sync(sfb->dev);
>
> @@ -1581,10 +1581,10 @@ static int s3c_fb_resume(struct device *dev)
>
> pm_runtime_get_sync(sfb->dev);
>
> - clk_enable(sfb->bus_clk);
> + clk_prepare_enable(sfb->bus_clk);
>
> if (!sfb->variant.has_clksel)
> - clk_enable(sfb->lcd_clk);
> + clk_prepare_enable(sfb->lcd_clk);
>
> /* setup gpio and output polarity controls */
> pd->setup_gpio();
> @@ -1640,9 +1640,9 @@ static int s3c_fb_runtime_suspend(struct device *dev)
> struct s3c_fb *sfb = platform_get_drvdata(pdev);
>
> if (!sfb->variant.has_clksel)
> - clk_disable(sfb->lcd_clk);
> + clk_disable_unprepare(sfb->lcd_clk);
>
> - clk_disable(sfb->bus_clk);
> + clk_disable_unprepare(sfb->bus_clk);
>
> return 0;
> }
> @@ -1653,10 +1653,10 @@ static int s3c_fb_runtime_resume(struct device *dev)
> struct s3c_fb *sfb = platform_get_drvdata(pdev);
> struct s3c_fb_platdata *pd = sfb->pdata;
>
> - clk_enable(sfb->bus_clk);
> + clk_prepare_enable(sfb->bus_clk);
>
> if (!sfb->variant.has_clksel)
> - clk_enable(sfb->lcd_clk);
> + clk_prepare_enable(sfb->lcd_clk);
>
> /* setup gpio and output polarity controls */
> pd->setup_gpio();
> --
> 1.7.4.1
^ permalink raw reply
* [PATCH] video: exynos_dp: use clk_prepare_enable and clk_disable_unprepare
From: Jingoo Han @ 2012-10-04 6:45 UTC (permalink / raw)
To: 'Florian Tobias Schandinat'
Cc: linux-fbdev, linux-samsung-soc, 'Thomas Abraham',
'Jingoo Han'
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
calls as required by common clock framework.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/exynos/exynos_dp_core.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index cdc1398..d55470e 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -885,7 +885,7 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
return PTR_ERR(dp->clock);
}
- clk_enable(dp->clock);
+ clk_prepare_enable(dp->clock);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -956,7 +956,7 @@ static int __devexit exynos_dp_remove(struct platform_device *pdev)
if (pdata && pdata->phy_exit)
pdata->phy_exit();
- clk_disable(dp->clock);
+ clk_disable_unprepare(dp->clock);
return 0;
}
@@ -971,7 +971,7 @@ static int exynos_dp_suspend(struct device *dev)
if (pdata && pdata->phy_exit)
pdata->phy_exit();
- clk_disable(dp->clock);
+ clk_disable_unprepare(dp->clock);
return 0;
}
@@ -985,7 +985,7 @@ static int exynos_dp_resume(struct device *dev)
if (pdata && pdata->phy_init)
pdata->phy_init();
- clk_enable(dp->clock);
+ clk_prepare_enable(dp->clock);
exynos_dp_init_dp(dp);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/2] drivers/video/exynos/exynos_mipi_dsi.c: fix error return code
From: Donghwa Lee @ 2012-10-04 7:42 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: Inki Dae, kernel-janitors, Kyungmin Park,
Florian Tobias Schandinat, linux-fbdev, linux-kernel
In-Reply-To: <1349268044-32616-2-git-send-email-peter.senna@gmail.com>
On Wed, Oct 03, 2012 at 21:40, Peter Senna Tschudin wrote
> From: Peter Senna Tschudin <peter.senna@gmail.com>
>
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> (
> if@p1 (\(ret < 0\|ret != 0\))
> { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
> ... when != ret = e2
> when forall
> return ret;
> }
> // </smpl>
>
I agree with you. Other codes is already used negative error return codes.
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
>
> ---
> drivers/video/exynos/exynos_mipi_dsi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
> index c4f25de..07d70a3 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -375,6 +375,7 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
> dsim->clock = clk_get(&pdev->dev, "dsim0");
> if (IS_ERR(dsim->clock)) {
> dev_err(&pdev->dev, "failed to get dsim clock source\n");
> + ret = -ENODEV;
> goto err_clock_get;
> }
>
> @@ -383,6 +384,7 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> dev_err(&pdev->dev, "failed to get io memory region\n");
> + ret = -ENODEV;
> goto err_platform_get;
> }
>
> @@ -407,6 +409,7 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
> dsim_ddi = exynos_mipi_dsi_bind_lcd_ddi(dsim, dsim_pd->lcd_panel_name);
> if (!dsim_ddi) {
> dev_err(&pdev->dev, "mipi_dsim_ddi object not found.\n");
> + ret = -EINVAL;
> goto err_bind;
> }
>
>
>
^ permalink raw reply
* omap DSS cmdline resolution not working for HDMI?
From: Tony Lindgren @ 2012-10-04 17:56 UTC (permalink / raw)
To: linux-omap; +Cc: linux-fbdev, Tomi Valkeinen
Hi,
FYI, looks like for some reason DSS command line is not
working for HDMI while it works for DSS. On my panda es
I'm trying to set my motorola lapdock resolution from
cmdline with:
omapdss.def_disp=hdmi omapfb.mode=hdmi:1366x768@60
But it does not seem to do anything and resolution is
VGA. If I change the cable to DVI port this works:
omapdss.def_disp=dvi omapfb.mode=dvi:1366x768@60
Any ideas? This is with current linux next.
I can change the HDMI resolution OK from userspace with:
echo "1" > /sys/devices/platform/omapdss/display1/enabled
echo "0" > /sys/devices/platform/omapdss/overlay0/enabled
echo "tv" > /sys/devices/platform/omapdss/overlay0/manager
echo "1" > /sys/devices/platform/omapdss/overlay0/enabled
echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/display1/timings
The reason to use HDMI instead of DVI here is that HDMI
also has the speakers on the lapdock ;)
Then I'm able to switch between HDMI panel and DVI panel
just fine using overlay0. I don't know if getting both
HDMI and DVI to work the same time using overlay1 is
supposed to work, but trying use overlay1 produces the
following:
echo "1" > /sys/devices/platform/omapdss/display0/enabled
echo "0" > /sys/devices/platform/omapdss/overlay1/enabled
echo "lcd2" > /sys/devices/platform/omapdss/overlay1/manager
echo "1" > /sys/devices/platform/omapdss/overlay1/enabled
echo "170666,1920/336/128/208,1200/38/1/3" > /sys/devices/platform/omapdss/display0/timings
[ 816.446044] omapdss DPI: Could not find exact pixel clock. Requested 23500 kHz, got 23630 kHz
[ 881.639221] omapdss APPLY: timeout in wait_pending_extra_info_updates
[ 958.946594] ------------[ cut here ]------------
[ 958.953277] WARNING: at drivers/bus/omap_l3_noc.c:97 l3_interrupt_handler+0xc0/0x184()
[ 958.965576] L3 standard error: TARGET:DMM2 at address 0x0
...
Regards,
Tony
^ permalink raw reply
* [PATCH 0/2 v6] of: add display helper
From: Steffen Trumtrar @ 2012-10-04 17:59 UTC (permalink / raw)
To: devicetree-discuss
Cc: Steffen Trumtrar, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, linux-media, Tomi Valkeinen
Hi!
In accordance with Stepehn Warren, I downsized the binding.
Now, just the display-timing is described, as I think, it is way easier to agree
on those and have a complete binding.
Regards,
Steffen
Steffen Trumtrar (2):
of: add helper to parse display timings
of: add generic videomode description
.../devicetree/bindings/video/display-timings.txt | 222 ++++++++++++++++++++
drivers/of/Kconfig | 10 +
drivers/of/Makefile | 2 +
drivers/of/of_display_timings.c | 183 ++++++++++++++++
drivers/of/of_videomode.c | 212 +++++++++++++++++++
include/linux/of_display_timings.h | 85 ++++++++
include/linux/of_videomode.h | 41 ++++
7 files changed, 755 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt
create mode 100644 drivers/of/of_display_timings.c
create mode 100644 drivers/of/of_videomode.c
create mode 100644 include/linux/of_display_timings.h
create mode 100644 include/linux/of_videomode.h
--
1.7.10.4
^ permalink raw reply
* [PATCH 1/2 v6] of: add helper to parse display timings
From: Steffen Trumtrar @ 2012-10-04 17:59 UTC (permalink / raw)
To: devicetree-discuss
Cc: Steffen Trumtrar, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, linux-media, Tomi Valkeinen
In-Reply-To: <1349373560-11128-1-git-send-email-s.trumtrar@pengutronix.de>
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
.../devicetree/bindings/video/display-timings.txt | 222 ++++++++++++++++++++
drivers/of/Kconfig | 5 +
drivers/of/Makefile | 1 +
drivers/of/of_display_timings.c | 183 ++++++++++++++++
include/linux/of_display_timings.h | 85 ++++++++
5 files changed, 496 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt
create mode 100644 drivers/of/of_display_timings.c
create mode 100644 include/linux/of_display_timings.h
diff --git a/Documentation/devicetree/bindings/video/display-timings.txt b/Documentation/devicetree/bindings/video/display-timings.txt
new file mode 100644
index 0000000..45e39bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-timings.txt
@@ -0,0 +1,222 @@
+display-timings bindings
+=========
+
+display-timings-node
+------------
+
+required properties:
+ - none
+
+optional properties:
+ - default-timing: the default timing value
+
+timings-subnode
+---------------
+
+required properties:
+ - hactive, vactive: Display resolution
+ - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
+ in pixels
+ vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
+ lines
+ - clock: displayclock in Hz
+
+optional properties:
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse is active high
+ - de-active-high (bool): Data-Enable pulse is active high
+ - pixelclk-inverted (bool): pixelclock is inverted
+ - interlaced (bool)
+ - doublescan (bool)
+
+There are different ways of describing the capabilities of a display. The devicetree
+representation corresponds to the one commonly found in datasheets for displays.
+If a display supports multiple signal timings, the default-timing can be specified.
+
+The parameters are defined as
+
+struct signal_timing
+=========+
+ +----------+---------------------------------------------+----------+-------+
+ | | ↑ | | |
+ | | |vback_porch | | |
+ | | ↓ | | |
+ +----------###############################################----------+-------+
+ | # ↑ # | |
+ | # | # | |
+ | hback # | # hfront | hsync |
+ | porch # | hactive # porch | len |
+ |<-------->#<---------------+--------------------------->#<-------->|<----->|
+ | # | # | |
+ | # |vactive # | |
+ | # | # | |
+ | # ↓ # | |
+ +----------###############################################----------+-------+
+ | | ↑ | | |
+ | | |vfront_porch | | |
+ | | ↓ | | |
+ +----------+---------------------------------------------+----------+-------+
+ | | ↑ | | |
+ | | |vsync_len | | |
+ | | ↓ | | |
+ +----------+---------------------------------------------+----------+-------+
+
+
+Example:
+
+ display-timings {
+ default-timing = <&timing0>;
+ timing0: 1920p24 {
+ /* 1920x1080p24 */
+ clock = <52000000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hfront-porch = <25>;
+ hback-porch = <25>;
+ hsync-len = <25>;
+ vback-porch = <2>;
+ vfront-porch = <2>;
+ vsync-len = <2>;
+ hsync-active-high;
+ };
+ };
+
+Every property also supports the use of ranges, so the commonly used datasheet
+description with <min typ max>-tuples can be used.
+
+Example:
+
+ timing1: timing {
+ /* 1920x1080p24 */
+ clock = <148500000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <0 44 60>;
+ hfront-porch = <80 88 95>;
+ hback-porch = <100 148 160>;
+ vfront-porch = <0 4 6>;
+ vback-porch = <0 36 50>;
+ vsync-len = <0 5 6>;
+ };
+
+Usage in backend
+========
+
+A backend driver may choose to use the display-timings directly and convert the timing
+ranges to a suitable mode. Or it may just use the conversion of the display timings
+to the required mode via the generic videomode struct.
+
+ dtb
+ |
+ | of_get_display_timing_list
+ ↓
+ struct display_timings
+ |
+ | videomode_from_timing
+ ↓
+ --- struct videomode ---
+ | |
+ videomode_to_displaymode | | videomode_to_fb_videomode
+ ↓ ↓
+ drm_display_mode fb_videomode
+
+The functions of_get_fb_videomode and of_get_display_mode are provided
+to conveniently get the respective mode representation from the devicetree.
+
+Conversion to videomode
+===========+
+As device drivers normally work with some kind of video mode, the timings can be
+converted (may be just a simple copying of the typical value) to a generic videomode
+structure which then can be converted to the according mode used by the backend.
+
+Supported modes
+=======+
+The generic videomode read in by the driver can be converted to the following
+modes with the following parameters
+
+struct fb_videomode
+=========+
+ +----------+---------------------------------------------+----------+-------+
+ | | ↑ | | |
+ | | |upper_margin | | |
+ | | ↓ | | |
+ +----------###############################################----------+-------+
+ | # ↑ # | |
+ | # | # | |
+ | # | # | |
+ | # | # | |
+ | left # | # right | hsync |
+ | margin # | xres # margin | len |
+ |<-------->#<---------------+--------------------------->#<-------->|<----->|
+ | # | # | |
+ | # | # | |
+ | # | # | |
+ | # |yres # | |
+ | # | # | |
+ | # | # | |
+ | # | # | |
+ | # | # | |
+ | # | # | |
+ | # | # | |
+ | # | # | |
+ | # | # | |
+ | # ↓ # | |
+ +----------###############################################----------+-------+
+ | | ↑ | | |
+ | | |lower_margin | | |
+ | | ↓ | | |
+ +----------+---------------------------------------------+----------+-------+
+ | | ↑ | | |
+ | | |vsync_len | | |
+ | | ↓ | | |
+ +----------+---------------------------------------------+----------+-------+
+
+clock in nanoseconds
+
+struct drm_display_mode
+===========+
+ +----------+---------------------------------------------+----------+-------+
+ | | | | | ↑
+ | | | | | |
+ | | | | | |
+ +----------###############################################----------+-------+ |
+ | # ↑ ↑ ↑ # | | |
+ | # | | | # | | |
+ | # | | | # | | |
+ | # | | | # | | |
+ | # | | | # | | |
+ | # | | | hdisplay # | | |
+ | #<--+--------------------+-------------------># | | |
+ | # | | | # | | |
+ | # |vsync_start | # | | |
+ | # | | | # | | |
+ | # | |vsync_end | # | | |
+ | # | | |vdisplay # | | |
+ | # | | | # | | |
+ | # | | | # | | |
+ | # | | | # | | | vtotal
+ | # | | | # | | |
+ | # | | | hsync_start # | | |
+ | #<--+---------+----------+------------------------------>| | |
+ | # | | | # | | |
+ | # | | | hsync_end # | | |
+ | #<--+---------+----------+-------------------------------------->| |
+ | # | | ↓ # | | |
+ +----------####|#########|################################----------+-------+ |
+ | | | | | | | |
+ | | | | | | | |
+ | | ↓ | | | | |
+ +----------+-------------+-------------------------------+----------+-------+ |
+ | | | | | | |
+ | | | | | | |
+ | | ↓ | | | ↓
+ +----------+---------------------------------------------+----------+-------+
+ htotal
+ <------------------------------------------------------------------------->
+
+clock in kilohertz
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index dfba3e6..646deb0 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -83,4 +83,9 @@ config OF_MTD
depends on MTD
def_bool y
+config OF_DISPLAY_TIMINGS
+ def_bool y
+ help
+ helper to parse display timings from the devicetree
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index e027f44..c8e9603 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
+obj-$(CONFIG_OF_DISPLAY_TIMINGS) += of_display_timings.o
diff --git a/drivers/of/of_display_timings.c b/drivers/of/of_display_timings.c
new file mode 100644
index 0000000..e47bc63
--- /dev/null
+++ b/drivers/of/of_display_timings.c
@@ -0,0 +1,183 @@
+/*
+ * OF helpers for parsing display timings
+ *
+ * Copyright (c) 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>, Pengutronix
+ *
+ * based on of_videomode.c by Sascha Hauer <s.hauer@pengutronix.de>
+ *
+ * This file is released under the GPLv2
+ */
+#include <linux/of.h>
+#include <linux/slab.h>
+#include <linux/export.h>
+#include <linux/of_display_timings.h>
+
+/* every signal_timing can be specified with either
+ * just the typical value or a range consisting of
+ * min/typ/max.
+ * This function helps handling this
+ */
+static int parse_property(struct device_node *np, char *name,
+ struct timing_entry *result)
+{
+ struct property *prop;
+ int length;
+ int cells;
+ int ret;
+
+ prop = of_find_property(np, name, &length);
+ if (!prop) {
+ pr_err("%s: could not find property %s\n", __func__, name);
+ return -EINVAL;
+ }
+
+ cells = length / sizeof(u32);
+
+ if (cells = 1)
+ ret = of_property_read_u32_array(np, name, &result->typ, cells);
+ else if (cells = 3)
+ ret = of_property_read_u32_array(np, name, &result->min, cells);
+ else {
+ pr_err("%s: illegal timing specification in %s\n", __func__,
+ name);
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+struct signal_timing *of_get_display_timing(struct device_node *np)
+{
+ struct signal_timing *st;
+ int ret = 0;
+
+ st = kzalloc(sizeof(*st), GFP_KERNEL);
+
+ if (!st) {
+ pr_err("%s: could not allocate signal_timing struct\n", __func__);
+ return NULL;
+ }
+
+ ret |= parse_property(np, "hback-porch", &st->hback_porch);
+ ret |= parse_property(np, "hfront-porch", &st->hfront_porch);
+ ret |= parse_property(np, "hactive", &st->hactive);
+ ret |= parse_property(np, "hsync-len", &st->hsync_len);
+ ret |= parse_property(np, "vback-porch", &st->vback_porch);
+ ret |= parse_property(np, "vfront-porch", &st->vfront_porch);
+ ret |= parse_property(np, "vactive", &st->vactive);
+ ret |= parse_property(np, "vsync-len", &st->vsync_len);
+ ret |= parse_property(np, "clock", &st->pixelclock);
+
+ st->vsync_pol_active_high = of_property_read_bool(np, "vsync-active-high");
+ st->hsync_pol_active_high = of_property_read_bool(np, "hsync-active-high");
+ st->de_pol_active_high = of_property_read_bool(np, "de-active-high");
+ st->pixelclk_pol_inverted = of_property_read_bool(np, "pixelclk-inverted");
+ st->interlaced = of_property_read_bool(np, "interlaced");
+ st->doublescan = of_property_read_bool(np, "doublescan");
+
+ if (ret) {
+ pr_err("%s: error reading timing properties\n", __func__);
+ return NULL;
+ }
+
+ return st;
+}
+EXPORT_SYMBOL_GPL(of_get_display_timing);
+
+struct display_timings *of_get_display_timing_list(struct device_node *np)
+{
+ struct device_node *timings_np;
+ struct device_node *entry;
+ struct display_timings *disp;
+ char *default_timing;
+
+ if (!np) {
+ pr_err("%s: no devicenode given\n", __func__);
+ return NULL;
+ }
+
+ timings_np = of_find_node_by_name(np, "display-timings");
+
+ if (!timings_np) {
+ pr_err("%s: could not find display-timings node\n", __func__);
+ return NULL;
+ }
+
+ disp = kzalloc(sizeof(*disp), GFP_KERNEL);
+
+ entry = of_parse_phandle(timings_np, "default-timing", 0);
+
+ if (!entry) {
+ pr_info("%s: no default-timing specified\n", __func__);
+ entry = of_find_node_by_name(np, "timing");
+ }
+
+ if (!entry) {
+ pr_info("%s: no timing specifications given\n", __func__);
+ return disp;
+ }
+
+ pr_info("%s: using %s as default timing\n", __func__, entry->name);
+
+ default_timing = (char *)entry->full_name;
+
+ disp->num_timings = 0;
+
+ for_each_child_of_node(timings_np, entry) {
+ disp->num_timings++;
+ }
+
+ disp->timings = kzalloc(sizeof(struct signal_timing *)*disp->num_timings,
+ GFP_KERNEL);
+
+ disp->num_timings = 0;
+
+ for_each_child_of_node(timings_np, entry) {
+ struct signal_timing *st;
+
+ st = of_get_display_timing(entry);
+
+ if (!st)
+ continue;
+
+ if (strcmp(default_timing, entry->full_name) = 0)
+ disp->default_timing = disp->num_timings;
+
+ disp->timings[disp->num_timings] = st;
+ disp->num_timings++;
+ }
+
+
+ of_node_put(timings_np);
+
+ if (disp->num_timings >= 0)
+ pr_info("%s: got %d timings. Using timing #%d as default\n", __func__,
+ disp->num_timings , disp->default_timing + 1);
+ else
+ pr_info("%s: no timings specified\n", __func__);
+
+ return disp;
+}
+EXPORT_SYMBOL_GPL(of_get_display_timing_list);
+
+int of_display_timings_exists(struct device_node *np)
+{
+ struct device_node *timings_np;
+ struct device_node *default_np;
+
+ if (!np)
+ return -EINVAL;
+
+ timings_np = of_parse_phandle(np, "display-timings", 0);
+
+ if (!timings_np)
+ return -EINVAL;
+
+ default_np = of_parse_phandle(np, "default-timing", 0);
+
+ if (default_np)
+ return 0;
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(of_display_timings_exists);
diff --git a/include/linux/of_display_timings.h b/include/linux/of_display_timings.h
new file mode 100644
index 0000000..1ad719e
--- /dev/null
+++ b/include/linux/of_display_timings.h
@@ -0,0 +1,85 @@
+/*
+ * Copyright 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>
+ *
+ * description of display timings
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_OF_DISPLAY_TIMINGS_H
+#define __LINUX_OF_DISPLAY_TIMINGS_H
+
+#define OF_DEFAULT_TIMING -1
+
+struct display_timings {
+ unsigned int num_timings;
+ unsigned int default_timing;
+
+ struct signal_timing **timings;
+};
+
+struct timing_entry {
+ u32 min;
+ u32 typ;
+ u32 max;
+};
+
+struct signal_timing {
+ struct timing_entry pixelclock;
+
+ struct timing_entry hactive;
+ struct timing_entry hfront_porch;
+ struct timing_entry hback_porch;
+ struct timing_entry hsync_len;
+
+ struct timing_entry vactive;
+ struct timing_entry vfront_porch;
+ struct timing_entry vback_porch;
+ struct timing_entry vsync_len;
+
+ bool vsync_pol_active_high;
+ bool hsync_pol_active_high;
+ bool de_pol_active_high;
+ bool pixelclk_pol_inverted;
+ bool interlaced;
+ bool doublescan;
+};
+
+struct display_timings *of_get_display_timing_list(struct device_node *np);
+struct signal_timing *of_get_display_timing(struct device_node *np);
+int of_display_timings_exists(struct device_node *np);
+
+/* placeholder function until ranges are really needed */
+static inline u32 signal_timing_get_value(struct timing_entry *te, int index)
+{
+ return te->typ;
+}
+
+static inline void timings_release(struct display_timings *disp)
+{
+ int i;
+
+ for (i = 0; i < disp->num_timings; i++)
+ kfree(disp->timings[i]);
+}
+
+static inline void display_timings_release(struct display_timings *disp)
+{
+ timings_release(disp);
+ kfree(disp->timings);
+}
+
+static inline struct signal_timing *display_timings_get(struct display_timings *disp,
+ int index)
+{
+ struct signal_timing *st;
+
+ if (disp->num_timings > index) {
+ st = disp->timings[index];
+ return st;
+ }
+ else
+ return NULL;
+}
+
+#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2 v6] of: add generic videomode description
From: Steffen Trumtrar @ 2012-10-04 17:59 UTC (permalink / raw)
To: devicetree-discuss
Cc: Steffen Trumtrar, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, linux-media, Tomi Valkeinen
In-Reply-To: <1349373560-11128-1-git-send-email-s.trumtrar@pengutronix.de>
Get videomode from devicetree in a format appropriate for the
backend. drm_display_mode and fb_videomode are supported atm.
Uses the display signal timings from of_display_timings
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
drivers/of/Kconfig | 5 +
drivers/of/Makefile | 1 +
drivers/of/of_videomode.c | 212 ++++++++++++++++++++++++++++++++++++++++++
include/linux/of_videomode.h | 41 ++++++++
4 files changed, 259 insertions(+)
create mode 100644 drivers/of/of_videomode.c
create mode 100644 include/linux/of_videomode.h
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 646deb0..74282e2 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -88,4 +88,9 @@ config OF_DISPLAY_TIMINGS
help
helper to parse display timings from the devicetree
+config OF_VIDEOMODE
+ def_bool y
+ help
+ helper to get videomodes from the devicetree
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index c8e9603..09d556f 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
obj-$(CONFIG_OF_DISPLAY_TIMINGS) += of_display_timings.o
+obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
new file mode 100644
index 0000000..76ac16e
--- /dev/null
+++ b/drivers/of/of_videomode.c
@@ -0,0 +1,212 @@
+/*
+ * generic videomode helper
+ *
+ * Copyright (c) 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+#include <linux/of.h>
+#include <linux/fb.h>
+#include <linux/slab.h>
+#include <drm/drm_mode.h>
+#include <linux/of_display_timings.h>
+#include <linux/of_videomode.h>
+
+void dump_fb_videomode(struct fb_videomode *m)
+{
+ pr_debug("fb_videomode = %d %d %d %d %d %d %d %d %d %d %d %d %d\n",
+ m->refresh, m->xres, m->yres, m->pixclock, m->left_margin,
+ m->right_margin, m->upper_margin, m->lower_margin,
+ m->hsync_len, m->vsync_len, m->sync, m->vmode, m->flag);
+}
+
+void dump_drm_displaymode(struct drm_display_mode *m)
+{
+ pr_debug("drm_displaymode = %d %d %d %d %d %d %d %d %d\n",
+ m->hdisplay, m->hsync_start, m->hsync_end, m->htotal,
+ m->vdisplay, m->vsync_start, m->vsync_end, m->vtotal,
+ m->clock);
+}
+
+int videomode_from_timing(struct display_timings *disp, struct videomode *vm,
+ int index)
+{
+ struct signal_timing *st = NULL;
+
+ if (!vm)
+ return -EINVAL;
+
+ st = display_timings_get(disp, index);
+
+ if (!st) {
+ pr_err("%s: no signal timings found\n", __func__);
+ return -EINVAL;
+ }
+
+ vm->pixelclock = signal_timing_get_value(&st->pixelclock, 0);
+ vm->hactive = signal_timing_get_value(&st->hactive, 0);
+ vm->hfront_porch = signal_timing_get_value(&st->hfront_porch, 0);
+ vm->hback_porch = signal_timing_get_value(&st->hback_porch, 0);
+ vm->hsync_len = signal_timing_get_value(&st->hsync_len, 0);
+
+ vm->vactive = signal_timing_get_value(&st->vactive, 0);
+ vm->vfront_porch = signal_timing_get_value(&st->vfront_porch, 0);
+ vm->vback_porch = signal_timing_get_value(&st->vback_porch, 0);
+ vm->vsync_len = signal_timing_get_value(&st->vsync_len, 0);
+
+ vm->vah = st->vsync_pol_active_high;
+ vm->hah = st->hsync_pol_active_high;
+ vm->interlaced = st->interlaced;
+ vm->doublescan = st->doublescan;
+
+ return 0;
+}
+
+int of_get_videomode(struct device_node *np, struct videomode *vm, int index)
+{
+ struct display_timings *disp;
+ int ret = 0;
+
+ disp = of_get_display_timing_list(np);
+
+ if (!disp) {
+ pr_err("%s: no timings specified\n", __func__);
+ return -EINVAL;
+ }
+
+ if (index = OF_DEFAULT_TIMING)
+ index = disp->default_timing;
+
+ ret = videomode_from_timing(disp, vm, index);
+
+ if (ret)
+ return ret;
+
+ display_timings_release(disp);
+
+ if (!vm) {
+ pr_err("%s: could not get videomode %d\n", __func__, index);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_videomode);
+
+#if defined(CONFIG_DRM)
+int videomode_to_display_mode(struct videomode *vm, struct drm_display_mode *dmode)
+{
+ memset(dmode, 0, sizeof(*dmode));
+
+ dmode->hdisplay = vm->hactive;
+ dmode->hsync_start = dmode->hdisplay + vm->hfront_porch;
+ dmode->hsync_end = dmode->hsync_start + vm->hsync_len;
+ dmode->htotal = dmode->hsync_end + vm->hback_porch;
+
+ dmode->vdisplay = vm->vactive;
+ dmode->vsync_start = dmode->vdisplay + vm->vfront_porch;
+ dmode->vsync_end = dmode->vsync_start + vm->vsync_len;
+ dmode->vtotal = dmode->vsync_end + vm->vback_porch;
+
+ dmode->clock = vm->pixelclock / 1000;
+
+ if (vm->hah)
+ dmode->flags |= DRM_MODE_FLAG_PHSYNC;
+ else
+ dmode->flags |= DRM_MODE_FLAG_NHSYNC;
+ if (vm->vah)
+ dmode->flags |= DRM_MODE_FLAG_PVSYNC;
+ else
+ dmode->flags |= DRM_MODE_FLAG_NVSYNC;
+ if (vm->interlaced)
+ dmode->flags |= DRM_MODE_FLAG_INTERLACE;
+ if (vm->doublescan)
+ dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
+ drm_mode_set_name(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_to_display_mode);
+
+int of_get_drm_display_mode(struct device_node *np, struct drm_display_mode *dmode,
+ int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, &vm, index);
+
+ if (ret)
+ return ret;
+
+ videomode_to_display_mode(&vm, dmode);
+
+ pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive,
+ vm.vactive, np->name);
+ dump_drm_displaymode(dmode);
+
+ return 0;
+
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#else
+int videomode_to_display_mode(struct videomode *vm, struct drm_display_mode *dmode)
+{
+ return 0;
+}
+
+int of_get_drm_display_mode(struct device_node *np, struct drm_display_mode *dmode,
+ int index)
+{
+ return 0;
+}
+#endif
+
+int videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode *fbmode)
+{
+ memset(fbmode, 0, sizeof(*fbmode));
+
+ fbmode->xres = vm->hactive;
+ fbmode->left_margin = vm->hback_porch;
+ fbmode->right_margin = vm->hfront_porch;
+ fbmode->hsync_len = vm->hsync_len;
+
+ fbmode->yres = vm->vactive;
+ fbmode->upper_margin = vm->vback_porch;
+ fbmode->lower_margin = vm->vfront_porch;
+ fbmode->vsync_len = vm->vsync_len;
+
+ fbmode->pixclock = KHZ2PICOS(vm->pixelclock) / 1000;
+
+ if (vm->hah)
+ fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vm->vah)
+ fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
+ if (vm->interlaced)
+ fbmode->vmode |= FB_VMODE_INTERLACED;
+ if (vm->doublescan)
+ fbmode->vmode |= FB_VMODE_DOUBLE;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_to_fb_videomode);
+
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+ int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, &vm, index);
+ if (ret)
+ return ret;
+
+ videomode_to_fb_videomode(&vm, fb);
+
+ pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive,
+ vm.vactive, np->name);
+ dump_fb_videomode(fb);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h
new file mode 100644
index 0000000..96efe01
--- /dev/null
+++ b/include/linux/of_videomode.h
@@ -0,0 +1,41 @@
+/*
+ * Copyright 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>
+ *
+ * generic videomode description
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_VIDEOMODE_H
+#define __LINUX_VIDEOMODE_H
+
+#include <drm/drmP.h>
+
+struct videomode {
+ u32 pixelclock;
+ u32 refreshrate;
+
+ u32 hactive;
+ u32 hfront_porch;
+ u32 hback_porch;
+ u32 hsync_len;
+
+ u32 vactive;
+ u32 vfront_porch;
+ u32 vback_porch;
+ u32 vsync_len;
+
+ bool hah;
+ bool vah;
+ bool interlaced;
+ bool doublescan;
+
+};
+
+int videomode_to_display_mode(struct videomode *vm, struct drm_display_mode *dmode);
+int videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode *fbmode);
+int of_get_videomode(struct device_node *np, struct videomode *vm, int index);
+int of_get_drm_display_mode(struct device_node *np, struct drm_display_mode *dmode,
+ int index);
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb, int index);
+#endif /* __LINUX_VIDEOMODE_H */
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 1/2 v6] of: add helper to parse display timings
From: Stephen Warren @ 2012-10-04 18:47 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: devicetree-discuss, linux-fbdev, dri-devel, Tomi Valkeinen,
Laurent Pinchart, linux-media
In-Reply-To: <1349373560-11128-2-git-send-email-s.trumtrar@pengutronix.de>
On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
A patch description would be useful for something like this.
> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt b/Documentation/devicetree/bindings/video/display-timings.txt
> new file mode 100644
...
> +Usage in backend
> +========
Everything before that point in the file looks fine to me.
Everything after this point in the file seems to be Linux-specific
implementation details. Does it really belong in the DT binding
documentation, rather than some Linux-specific documentation file?
> +struct drm_display_mode
> +===========> +
> + +----------+---------------------------------------------+----------+-------+
> + | | | | | ↑
> + | | | | | |
> + | | | | | |
> + +----------###############################################----------+-------+ |
I suspect the entire horizontal box above (and the entire vertical box
all the way down the left-hand side) should be on the bottom/right
instead of top/left. The reason I think this is because all of
vsync_start, vsync_end, vdisplay have to be referenced to some known
point, which is usually zero or the start of the timing definition, /or/
there would be some value indicating the size of the top marging/porch
in order to say where those other values are referenced to.
> + | # ↑ ↑ ↑ # | | |
> + | # | | | # | | |
> + | # | | | # | | |
> + | # | | | # | | |
> + | # | | | # | | |
> + | # | | | hdisplay # | | |
> + | #<--+--------------------+-------------------># | | |
> + | # | | | # | | |
> + | # |vsync_start | # | | |
> + | # | | | # | | |
> + | # | |vsync_end | # | | |
> + | # | | |vdisplay # | | |
> + | # | | | # | | |
> + | # | | | # | | |
> + | # | | | # | | | vtotal
> + | # | | | # | | |
> + | # | | | hsync_start # | | |
> + | #<--+---------+----------+------------------------------>| | |
> + | # | | | # | | |
> + | # | | | hsync_end # | | |
> + | #<--+---------+----------+-------------------------------------->| |
> + | # | | ↓ # | | |
> + +----------####|#########|################################----------+-------+ |
> + | | | | | | | |
> + | | | | | | | |
> + | | ↓ | | | | |
> + +----------+-------------+-------------------------------+----------+-------+ |
> + | | | | | | |
> + | | | | | | |
> + | | ↓ | | | ↓
> + +----------+---------------------------------------------+----------+-------+
> + htotal
> + <------------------------------------------------------------------------->
> diff --git a/drivers/of/of_display_timings.c b/drivers/of/of_display_timings.c
> +static int parse_property(struct device_node *np, char *name,
> + struct timing_entry *result)
> + if (cells = 1)
> + ret = of_property_read_u32_array(np, name, &result->typ, cells);
Should that branch not just set result->min/max to typ as well?
Presumably it'd prevent any code that interprets struct timing_entry
from having to check if those values were 0 or not?
> + else if (cells = 3)
> + ret = of_property_read_u32_array(np, name, &result->min, cells);
> +struct display_timings *of_get_display_timing_list(struct device_node *np)
> + entry = of_parse_phandle(timings_np, "default-timing", 0);
> +
> + if (!entry) {
> + pr_info("%s: no default-timing specified\n", __func__);
> + entry = of_find_node_by_name(np, "timing");
I don't think you want to require the node have an explicit name; I
don't recall the DT binding documentation making that a requirement.
Instead, can't you either just leave the default unset, or pick the
first DT child node, irrespective of name?
> + if (!entry) {
> + pr_info("%s: no timing specifications given\n", __func__);
> + return disp;
> + }
The DT bindings don't state that it's mandatory to have some timing
specified, although I agree that it makes sense in practice.
> + for_each_child_of_node(timings_np, entry) {
> + struct signal_timing *st;
> +
> + st = of_get_display_timing(entry);
> +
> + if (!st)
> + continue;
I wonder if that shouldn't be an error?
> + if (strcmp(default_timing, entry->full_name) = 0)
> + disp->default_timing = disp->num_timings;
Hmm. Why not compare the node pointers rather than the name? Also, if
the parsing failed, then this can lead to default_timing being
uninitialized anyway...
> + disp->timings[disp->num_timings] = st;
> + disp->num_timings++;
> + }
> + if (disp->num_timings >= 0)
> + pr_info("%s: got %d timings. Using timing #%d as default\n", __func__,
> + disp->num_timings , disp->default_timing + 1);
> + else
> + pr_info("%s: no timings specified\n", __func__);
The message in the else clause is not necessarily true; there may have
been some specified, but they just couldn't be parsed.
> +int of_display_timings_exists(struct device_node *np)
> +{
> + struct device_node *timings_np;
> + struct device_node *default_np;
> +
> + if (!np)
> + return -EINVAL;
> +
> + timings_np = of_parse_phandle(np, "display-timings", 0);
> +
> + if (!timings_np)
> + return -EINVAL;
> +
> + default_np = of_parse_phandle(np, "default-timing", 0);
> +
> + if (default_np)
> + return 0;
If this function checks that a default-timing property exists, shouldn't
the function be named of_display_default_timing_exists()?
^ permalink raw reply
* Re: [PATCH 2/2 v6] of: add generic videomode description
From: Stephen Warren @ 2012-10-04 18:51 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: devicetree-discuss, linux-fbdev, dri-devel, Tomi Valkeinen,
Laurent Pinchart, linux-media
In-Reply-To: <1349373560-11128-3-git-send-email-s.trumtrar@pengutronix.de>
On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
> Get videomode from devicetree in a format appropriate for the
> backend. drm_display_mode and fb_videomode are supported atm.
> Uses the display signal timings from of_display_timings
> +++ b/drivers/of/of_videomode.c
> +int videomode_from_timing(struct display_timings *disp, struct videomode *vm,
> + st = display_timings_get(disp, index);
> +
> + if (!st) {
It's a little odd to leave a blank line between those two lines.
Only half of the code in this file seems OF-related; the routines to
convert a timing to a videomode or drm display mode seem like they'd be
useful outside device tree, so I wonder if putting them into
of_videomode.c is the correct thing to do. Still, it's probably not a
big deal.
^ permalink raw reply
* Re: [PATCH 1/2 v6] of: add helper to parse display timings
From: Guennadi Liakhovetski @ 2012-10-04 21:35 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Tomi Valkeinen,
Laurent Pinchart, linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1349373560-11128-2-git-send-email-s.trumtrar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hi Steffen
Sorry for chiming in so late in the game, but I've long been wanting to
have a look at this and compare with what we do for V4L2, so, this seems a
great opportunity to me:-)
On Thu, 4 Oct 2012, Steffen Trumtrar wrote:
> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> ---
> .../devicetree/bindings/video/display-timings.txt | 222 ++++++++++++++++++++
> drivers/of/Kconfig | 5 +
> drivers/of/Makefile | 1 +
> drivers/of/of_display_timings.c | 183 ++++++++++++++++
> include/linux/of_display_timings.h | 85 ++++++++
> 5 files changed, 496 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt
> create mode 100644 drivers/of/of_display_timings.c
> create mode 100644 include/linux/of_display_timings.h
>
> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt b/Documentation/devicetree/bindings/video/display-timings.txt
> new file mode 100644
> index 0000000..45e39bd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display-timings.txt
> @@ -0,0 +1,222 @@
> +display-timings bindings
> +=========
> +
> +display-timings-node
> +------------
> +
> +required properties:
> + - none
> +
> +optional properties:
> + - default-timing: the default timing value
> +
> +timings-subnode
> +---------------
> +
> +required properties:
> + - hactive, vactive: Display resolution
> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
> + in pixels
> + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
> + lines
> + - clock: displayclock in Hz
You're going to hate me for this, but eventually we want to actually
reference clock objects in our DT bindings. For now, even if you don't
want to actually add clock phandles and stuff here, I think, using the
standard "clock-frequency" property would be much better!
> +
> +optional properties:
> + - hsync-active-high (bool): Hsync pulse is active high
> + - vsync-active-high (bool): Vsync pulse is active high
For the above two we also considered using bool properties but eventually
settled down with integer ones:
- hsync-active = <1>
for active-high and 0 for active low. This has the added advantage of
being able to omit this property in the .dts, which then doesn't mean,
that the polarity is active low, but rather, that the hsync line is not
used on this hardware. So, maybe it would be good to use the same binding
here too?
> + - de-active-high (bool): Data-Enable pulse is active high
> + - pixelclk-inverted (bool): pixelclock is inverted
We don't (yet) have a de-active property in V4L, don't know whether we'll
ever have to distingsuish between what some datasheets call "HREF" and
HSYNC in DT, but maybe similarly to the above an integer would be
preferred. As for pixclk, we call the property "pclk-sample" and it's also
an integer.
> + - interlaced (bool)
Is "interlaced" a property of the hardware, i.e. of the board? Can the
same display controller on one board require interlaced data and on
another board - progressive? BTW, I'm not very familiar with display
interfaces, but for interlaced you probably sometimes use a field signal,
whose polarity you also want to specify here? We use a "field-even-active"
integer property for it.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH 04/16] ARM: OMAP: Make plat/fpga.h local to arch/arm/plat-omap
From: Tony Lindgren @ 2012-10-04 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004213950.26676.21898.stgit@muffinssi.local>
There's no need to have this file in plat/fpga.h. We can
make it local to plat-omap replacing fpga_read/write
functions directly with readb/writeb as that's how
they are already defined in fpga.h.
Note that 2420 based H4 is also using the fpga, so let's
keep the led support around in plat-omap until we flip
over mach-omap2 to device tree.
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
Cc: Felipe Balbi <balbi@ti.com>
Cc: linux-usb@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap1/board-fsample.c | 6 -
arch/arm/mach-omap1/board-innovator.c | 26 ++--
arch/arm/mach-omap1/board-perseus2.c | 6 -
arch/arm/mach-omap1/common.h | 1
arch/arm/mach-omap1/fpga.c | 2
arch/arm/mach-omap1/include/mach/omap1510.h | 113 ++++++++++++++++
arch/arm/mach-omap1/serial.c | 1
arch/arm/plat-omap/debug-leds.c | 2
arch/arm/plat-omap/fpga.h | 74 ++++++++++
arch/arm/plat-omap/include/plat/fpga.h | 193 ---------------------------
drivers/usb/host/ohci-omap.c | 5 -
drivers/video/omap/lcd_inn1510.c | 7 +
12 files changed, 216 insertions(+), 220 deletions(-)
create mode 100644 arch/arm/plat-omap/fpga.h
delete mode 100644 arch/arm/plat-omap/include/plat/fpga.h
diff --git a/arch/arm/mach-omap1/board-fsample.c b/arch/arm/mach-omap1/board-fsample.c
index 4b6de70..6f496df 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -30,7 +30,7 @@
#include <plat/tc.h>
#include <mach/mux.h>
#include <mach/flash.h>
-#include <plat/fpga.h>
+#include <../plat-omap/fpga.h>
#include <linux/platform_data/keypad-omap.h>
#include <mach/hardware.h>
@@ -123,9 +123,9 @@ static struct resource smc91x_resources[] = {
static void __init fsample_init_smc91x(void)
{
- fpga_write(1, H2P2_DBG_FPGA_LAN_RESET);
+ __raw_writeb(1, H2P2_DBG_FPGA_LAN_RESET);
mdelay(50);
- fpga_write(fpga_read(H2P2_DBG_FPGA_LAN_RESET) & ~1,
+ __raw_writeb(__raw_readb(H2P2_DBG_FPGA_LAN_RESET) & ~1,
H2P2_DBG_FPGA_LAN_RESET);
mdelay(50);
}
diff --git a/arch/arm/mach-omap1/board-innovator.c b/arch/arm/mach-omap1/board-innovator.c
index db5f7d2..5804da7 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -33,7 +33,7 @@
#include <mach/mux.h>
#include <mach/flash.h>
-#include <plat/fpga.h>
+#include <../plat-omap/fpga.h>
#include <plat/tc.h>
#include <linux/platform_data/keypad-omap.h>
#include <plat/mmc.h>
@@ -215,7 +215,7 @@ static struct platform_device *innovator1510_devices[] __initdata = {
static int innovator_get_pendown_state(void)
{
- return !(fpga_read(OMAP1510_FPGA_TOUCHSCREEN) & (1 << 5));
+ return !(__raw_readb(OMAP1510_FPGA_TOUCHSCREEN) & (1 << 5));
}
static const struct ads7846_platform_data innovator1510_ts_info = {
@@ -279,7 +279,7 @@ static struct platform_device *innovator1610_devices[] __initdata = {
static void __init innovator_init_smc91x(void)
{
if (cpu_is_omap1510()) {
- fpga_write(fpga_read(OMAP1510_FPGA_RST) & ~1,
+ __raw_writeb(__raw_readb(OMAP1510_FPGA_RST) & ~1,
OMAP1510_FPGA_RST);
udelay(750);
} else {
@@ -335,10 +335,10 @@ static int mmc_set_power(struct device *dev, int slot, int power_on,
int vdd)
{
if (power_on)
- fpga_write(fpga_read(OMAP1510_FPGA_POWER) | (1 << 3),
+ __raw_writeb(__raw_readb(OMAP1510_FPGA_POWER) | (1 << 3),
OMAP1510_FPGA_POWER);
else
- fpga_write(fpga_read(OMAP1510_FPGA_POWER) & ~(1 << 3),
+ __raw_writeb(__raw_readb(OMAP1510_FPGA_POWER) & ~(1 << 3),
OMAP1510_FPGA_POWER);
return 0;
@@ -390,14 +390,14 @@ static void __init innovator_init(void)
omap_cfg_reg(UART3_TX);
omap_cfg_reg(UART3_RX);
- reg = fpga_read(OMAP1510_FPGA_POWER);
+ reg = __raw_readb(OMAP1510_FPGA_POWER);
reg |= OMAP1510_FPGA_PCR_COM1_EN;
- fpga_write(reg, OMAP1510_FPGA_POWER);
+ __raw_writeb(reg, OMAP1510_FPGA_POWER);
udelay(10);
- reg = fpga_read(OMAP1510_FPGA_POWER);
+ reg = __raw_readb(OMAP1510_FPGA_POWER);
reg |= OMAP1510_FPGA_PCR_COM2_EN;
- fpga_write(reg, OMAP1510_FPGA_POWER);
+ __raw_writeb(reg, OMAP1510_FPGA_POWER);
udelay(10);
platform_add_devices(innovator1510_devices, ARRAY_SIZE(innovator1510_devices));
@@ -437,6 +437,7 @@ static void __init innovator_init(void)
*/
static void __init innovator_map_io(void)
{
+#ifdef CONFIG_ARCH_OMAP15XX
omap15xx_map_io();
iotable_init(innovator1510_io_desc, ARRAY_SIZE(innovator1510_io_desc));
@@ -444,9 +445,10 @@ static void __init innovator_map_io(void)
/* Dump the Innovator FPGA rev early - useful info for support. */
pr_debug("Innovator FPGA Rev %d.%d Board Rev %d\n",
- fpga_read(OMAP1510_FPGA_REV_HIGH),
- fpga_read(OMAP1510_FPGA_REV_LOW),
- fpga_read(OMAP1510_FPGA_BOARD_REV));
+ __raw_readb(OMAP1510_FPGA_REV_HIGH),
+ __raw_readb(OMAP1510_FPGA_REV_LOW),
+ __raw_readb(OMAP1510_FPGA_BOARD_REV));
+#endif
}
MACHINE_START(OMAP_INNOVATOR, "TI-Innovator")
diff --git a/arch/arm/mach-omap1/board-perseus2.c b/arch/arm/mach-omap1/board-perseus2.c
index 198b054..a1cdeeb 100644
--- a/arch/arm/mach-omap1/board-perseus2.c
+++ b/arch/arm/mach-omap1/board-perseus2.c
@@ -30,7 +30,7 @@
#include <plat/tc.h>
#include <mach/mux.h>
-#include <plat/fpga.h>
+#include <../plat-omap/fpga.h>
#include <mach/flash.h>
#include <mach/hardware.h>
@@ -231,9 +231,9 @@ static struct omap_lcd_config perseus2_lcd_config __initdata = {
static void __init perseus2_init_smc91x(void)
{
- fpga_write(1, H2P2_DBG_FPGA_LAN_RESET);
+ __raw_writeb(1, H2P2_DBG_FPGA_LAN_RESET);
mdelay(50);
- fpga_write(fpga_read(H2P2_DBG_FPGA_LAN_RESET) & ~1,
+ __raw_writeb(__raw_readb(H2P2_DBG_FPGA_LAN_RESET) & ~1,
H2P2_DBG_FPGA_LAN_RESET);
mdelay(50);
}
diff --git a/arch/arm/mach-omap1/common.h b/arch/arm/mach-omap1/common.h
index 9f2d8b6..26e19d3 100644
--- a/arch/arm/mach-omap1/common.h
+++ b/arch/arm/mach-omap1/common.h
@@ -41,6 +41,7 @@ static inline void omap7xx_map_io(void)
#endif
#ifdef CONFIG_ARCH_OMAP15XX
+void omap1510_fpga_init_irq(void);
void omap15xx_map_io(void);
#else
static inline void omap15xx_map_io(void)
diff --git a/arch/arm/mach-omap1/fpga.c b/arch/arm/mach-omap1/fpga.c
index 29ec50f..4ec220d 100644
--- a/arch/arm/mach-omap1/fpga.c
+++ b/arch/arm/mach-omap1/fpga.c
@@ -27,7 +27,7 @@
#include <asm/irq.h>
#include <asm/mach/irq.h>
-#include <plat/fpga.h>
+#include <../plat-omap/fpga.h>
#include <mach/hardware.h>
diff --git a/arch/arm/mach-omap1/include/mach/omap1510.h b/arch/arm/mach-omap1/include/mach/omap1510.h
index 8fe05d6..3d23524 100644
--- a/arch/arm/mach-omap1/include/mach/omap1510.h
+++ b/arch/arm/mach-omap1/include/mach/omap1510.h
@@ -45,5 +45,118 @@
#define OMAP1510_DSP_MMU_BASE (0xfffed200)
+/*
+ * ---------------------------------------------------------------------------
+ * OMAP-1510 FPGA
+ * ---------------------------------------------------------------------------
+ */
+#define OMAP1510_FPGA_BASE 0xE8000000 /* VA */
+#define OMAP1510_FPGA_SIZE SZ_4K
+#define OMAP1510_FPGA_START 0x08000000 /* PA */
+
+/* Revision */
+#define OMAP1510_FPGA_REV_LOW IOMEM(OMAP1510_FPGA_BASE + 0x0)
+#define OMAP1510_FPGA_REV_HIGH IOMEM(OMAP1510_FPGA_BASE + 0x1)
+#define OMAP1510_FPGA_LCD_PANEL_CONTROL IOMEM(OMAP1510_FPGA_BASE + 0x2)
+#define OMAP1510_FPGA_LED_DIGIT IOMEM(OMAP1510_FPGA_BASE + 0x3)
+#define INNOVATOR_FPGA_HID_SPI IOMEM(OMAP1510_FPGA_BASE + 0x4)
+#define OMAP1510_FPGA_POWER IOMEM(OMAP1510_FPGA_BASE + 0x5)
+
+/* Interrupt status */
+#define OMAP1510_FPGA_ISR_LO IOMEM(OMAP1510_FPGA_BASE + 0x6)
+#define OMAP1510_FPGA_ISR_HI IOMEM(OMAP1510_FPGA_BASE + 0x7)
+
+/* Interrupt mask */
+#define OMAP1510_FPGA_IMR_LO IOMEM(OMAP1510_FPGA_BASE + 0x8)
+#define OMAP1510_FPGA_IMR_HI IOMEM(OMAP1510_FPGA_BASE + 0x9)
+
+/* Reset registers */
+#define OMAP1510_FPGA_HOST_RESET IOMEM(OMAP1510_FPGA_BASE + 0xa)
+#define OMAP1510_FPGA_RST IOMEM(OMAP1510_FPGA_BASE + 0xb)
+
+#define OMAP1510_FPGA_AUDIO IOMEM(OMAP1510_FPGA_BASE + 0xc)
+#define OMAP1510_FPGA_DIP IOMEM(OMAP1510_FPGA_BASE + 0xe)
+#define OMAP1510_FPGA_FPGA_IO IOMEM(OMAP1510_FPGA_BASE + 0xf)
+#define OMAP1510_FPGA_UART1 IOMEM(OMAP1510_FPGA_BASE + 0x14)
+#define OMAP1510_FPGA_UART2 IOMEM(OMAP1510_FPGA_BASE + 0x15)
+#define OMAP1510_FPGA_OMAP1510_STATUS IOMEM(OMAP1510_FPGA_BASE + 0x16)
+#define OMAP1510_FPGA_BOARD_REV IOMEM(OMAP1510_FPGA_BASE + 0x18)
+#define INNOVATOR_FPGA_CAM_USB_CONTROL IOMEM(OMAP1510_FPGA_BASE + 0x20c)
+#define OMAP1510P1_PPT_DATA IOMEM(OMAP1510_FPGA_BASE + 0x100)
+#define OMAP1510P1_PPT_STATUS IOMEM(OMAP1510_FPGA_BASE + 0x101)
+#define OMAP1510P1_PPT_CONTROL IOMEM(OMAP1510_FPGA_BASE + 0x102)
+
+#define OMAP1510_FPGA_TOUCHSCREEN IOMEM(OMAP1510_FPGA_BASE + 0x204)
+
+#define INNOVATOR_FPGA_INFO IOMEM(OMAP1510_FPGA_BASE + 0x205)
+#define INNOVATOR_FPGA_LCD_BRIGHT_LO IOMEM(OMAP1510_FPGA_BASE + 0x206)
+#define INNOVATOR_FPGA_LCD_BRIGHT_HI IOMEM(OMAP1510_FPGA_BASE + 0x207)
+#define INNOVATOR_FPGA_LED_GRN_LO IOMEM(OMAP1510_FPGA_BASE + 0x208)
+#define INNOVATOR_FPGA_LED_GRN_HI IOMEM(OMAP1510_FPGA_BASE + 0x209)
+#define INNOVATOR_FPGA_LED_RED_LO IOMEM(OMAP1510_FPGA_BASE + 0x20a)
+#define INNOVATOR_FPGA_LED_RED_HI IOMEM(OMAP1510_FPGA_BASE + 0x20b)
+#define INNOVATOR_FPGA_EXP_CONTROL IOMEM(OMAP1510_FPGA_BASE + 0x20d)
+#define INNOVATOR_FPGA_ISR2 IOMEM(OMAP1510_FPGA_BASE + 0x20e)
+#define INNOVATOR_FPGA_IMR2 IOMEM(OMAP1510_FPGA_BASE + 0x210)
+
+#define OMAP1510_FPGA_ETHR_START (OMAP1510_FPGA_START + 0x300)
+
+/*
+ * Power up Giga UART driver, turn on HID clock.
+ * Turn off BT power, since we're not using it and it
+ * draws power.
+ */
+#define OMAP1510_FPGA_RESET_VALUE 0x42
+
+#define OMAP1510_FPGA_PCR_IF_PD0 (1 << 7)
+#define OMAP1510_FPGA_PCR_COM2_EN (1 << 6)
+#define OMAP1510_FPGA_PCR_COM1_EN (1 << 5)
+#define OMAP1510_FPGA_PCR_EXP_PD0 (1 << 4)
+#define OMAP1510_FPGA_PCR_EXP_PD1 (1 << 3)
+#define OMAP1510_FPGA_PCR_48MHZ_CLK (1 << 2)
+#define OMAP1510_FPGA_PCR_4MHZ_CLK (1 << 1)
+#define OMAP1510_FPGA_PCR_RSRVD_BIT0 (1 << 0)
+
+/*
+ * Innovator/OMAP1510 FPGA HID register bit definitions
+ */
+#define OMAP1510_FPGA_HID_SCLK (1<<0) /* output */
+#define OMAP1510_FPGA_HID_MOSI (1<<1) /* output */
+#define OMAP1510_FPGA_HID_nSS (1<<2) /* output 0/1 chip idle/select */
+#define OMAP1510_FPGA_HID_nHSUS (1<<3) /* output 0/1 host active/suspended */
+#define OMAP1510_FPGA_HID_MISO (1<<4) /* input */
+#define OMAP1510_FPGA_HID_ATN (1<<5) /* input 0/1 chip idle/ATN */
+#define OMAP1510_FPGA_HID_rsrvd (1<<6)
+#define OMAP1510_FPGA_HID_RESETn (1<<7) /* output - 0/1 USAR reset/run */
+
+/* The FPGA IRQ is cascaded through GPIO_13 */
+#define OMAP1510_INT_FPGA (IH_GPIO_BASE + 13)
+
+/* IRQ Numbers for interrupts muxed through the FPGA */
+#define OMAP1510_INT_FPGA_ATN (OMAP_FPGA_IRQ_BASE + 0)
+#define OMAP1510_INT_FPGA_ACK (OMAP_FPGA_IRQ_BASE + 1)
+#define OMAP1510_INT_FPGA2 (OMAP_FPGA_IRQ_BASE + 2)
+#define OMAP1510_INT_FPGA3 (OMAP_FPGA_IRQ_BASE + 3)
+#define OMAP1510_INT_FPGA4 (OMAP_FPGA_IRQ_BASE + 4)
+#define OMAP1510_INT_FPGA5 (OMAP_FPGA_IRQ_BASE + 5)
+#define OMAP1510_INT_FPGA6 (OMAP_FPGA_IRQ_BASE + 6)
+#define OMAP1510_INT_FPGA7 (OMAP_FPGA_IRQ_BASE + 7)
+#define OMAP1510_INT_FPGA8 (OMAP_FPGA_IRQ_BASE + 8)
+#define OMAP1510_INT_FPGA9 (OMAP_FPGA_IRQ_BASE + 9)
+#define OMAP1510_INT_FPGA10 (OMAP_FPGA_IRQ_BASE + 10)
+#define OMAP1510_INT_FPGA11 (OMAP_FPGA_IRQ_BASE + 11)
+#define OMAP1510_INT_FPGA12 (OMAP_FPGA_IRQ_BASE + 12)
+#define OMAP1510_INT_ETHER (OMAP_FPGA_IRQ_BASE + 13)
+#define OMAP1510_INT_FPGAUART1 (OMAP_FPGA_IRQ_BASE + 14)
+#define OMAP1510_INT_FPGAUART2 (OMAP_FPGA_IRQ_BASE + 15)
+#define OMAP1510_INT_FPGA_TS (OMAP_FPGA_IRQ_BASE + 16)
+#define OMAP1510_INT_FPGA17 (OMAP_FPGA_IRQ_BASE + 17)
+#define OMAP1510_INT_FPGA_CAM (OMAP_FPGA_IRQ_BASE + 18)
+#define OMAP1510_INT_FPGA_RTC_A (OMAP_FPGA_IRQ_BASE + 19)
+#define OMAP1510_INT_FPGA_RTC_B (OMAP_FPGA_IRQ_BASE + 20)
+#define OMAP1510_INT_FPGA_CD (OMAP_FPGA_IRQ_BASE + 21)
+#define OMAP1510_INT_FPGA22 (OMAP_FPGA_IRQ_BASE + 22)
+#define OMAP1510_INT_FPGA23 (OMAP_FPGA_IRQ_BASE + 23)
+
#endif /* __ASM_ARCH_OMAP15XX_H */
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index b9d6834..d1ac080 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -23,7 +23,6 @@
#include <asm/mach-types.h>
#include <mach/mux.h>
-#include <plat/fpga.h>
#include "pm.h"
diff --git a/arch/arm/plat-omap/debug-leds.c b/arch/arm/plat-omap/debug-leds.c
index ea29bbe..feca128 100644
--- a/arch/arm/plat-omap/debug-leds.c
+++ b/arch/arm/plat-omap/debug-leds.c
@@ -20,7 +20,7 @@
#include <mach/hardware.h>
#include <asm/mach-types.h>
-#include <plat/fpga.h>
+#include "fpga.h"
/* Many OMAP development platforms reuse the same "debug board"; these
* platforms include H2, H3, H4, and Perseus2. There are 16 LEDs on the
diff --git a/arch/arm/plat-omap/fpga.h b/arch/arm/plat-omap/fpga.h
new file mode 100644
index 0000000..54faaa9
--- /dev/null
+++ b/arch/arm/plat-omap/fpga.h
@@ -0,0 +1,74 @@
+/*
+ * arch/arm/plat-omap/include/mach/fpga.h
+ *
+ * Interrupt handler for OMAP-1510 FPGA
+ *
+ * Copyright (C) 2001 RidgeRun, Inc.
+ * Author: Greg Lonnon <glonnon@ridgerun.com>
+ *
+ * Copyright (C) 2002 MontaVista Software, Inc.
+ *
+ * Separated FPGA interrupts from innovator1510.c and cleaned up for 2.6
+ * Copyright (C) 2004 Nokia Corporation by Tony Lindrgen <tony@atomide.com>
+ *
+ * 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
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_ARCH_OMAP_FPGA_H
+#define __ASM_ARCH_OMAP_FPGA_H
+
+/*
+ * ---------------------------------------------------------------------------
+ * H2/P2 Debug board FPGA
+ * ---------------------------------------------------------------------------
+ */
+/* maps in the FPGA registers and the ETHR registers */
+#define H2P2_DBG_FPGA_BASE 0xE8000000 /* VA */
+#define H2P2_DBG_FPGA_SIZE SZ_4K /* SIZE */
+#define H2P2_DBG_FPGA_START 0x04000000 /* PA */
+
+#define H2P2_DBG_FPGA_ETHR_START (H2P2_DBG_FPGA_START + 0x300)
+#define H2P2_DBG_FPGA_FPGA_REV IOMEM(H2P2_DBG_FPGA_BASE + 0x10) /* FPGA Revision */
+#define H2P2_DBG_FPGA_BOARD_REV IOMEM(H2P2_DBG_FPGA_BASE + 0x12) /* Board Revision */
+#define H2P2_DBG_FPGA_GPIO IOMEM(H2P2_DBG_FPGA_BASE + 0x14) /* GPIO outputs */
+#define H2P2_DBG_FPGA_LEDS IOMEM(H2P2_DBG_FPGA_BASE + 0x16) /* LEDs outputs */
+#define H2P2_DBG_FPGA_MISC_INPUTS IOMEM(H2P2_DBG_FPGA_BASE + 0x18) /* Misc inputs */
+#define H2P2_DBG_FPGA_LAN_STATUS IOMEM(H2P2_DBG_FPGA_BASE + 0x1A) /* LAN Status line */
+#define H2P2_DBG_FPGA_LAN_RESET IOMEM(H2P2_DBG_FPGA_BASE + 0x1C) /* LAN Reset line */
+
+/* NOTE: most boards don't have a static mapping for the FPGA ... */
+struct h2p2_dbg_fpga {
+ /* offset 0x00 */
+ u16 smc91x[8];
+ /* offset 0x10 */
+ u16 fpga_rev;
+ u16 board_rev;
+ u16 gpio_outputs;
+ u16 leds;
+ /* offset 0x18 */
+ u16 misc_inputs;
+ u16 lan_status;
+ u16 lan_reset;
+ u16 reserved0;
+ /* offset 0x20 */
+ u16 ps2_data;
+ u16 ps2_ctrl;
+ /* plus also 4 rs232 ports ... */
+};
+
+/* LEDs definition on debug board (16 LEDs, all physically green) */
+#define H2P2_DBG_FPGA_LED_GREEN (1 << 15)
+#define H2P2_DBG_FPGA_LED_AMBER (1 << 14)
+#define H2P2_DBG_FPGA_LED_RED (1 << 13)
+#define H2P2_DBG_FPGA_LED_BLUE (1 << 12)
+/* cpu0 load-meter LEDs */
+#define H2P2_DBG_FPGA_LOAD_METER (1 << 0) // A bit of fun on our board ...
+#define H2P2_DBG_FPGA_LOAD_METER_SIZE 11
+#define H2P2_DBG_FPGA_LOAD_METER_MASK ((1 << H2P2_DBG_FPGA_LOAD_METER_SIZE) - 1)
+
+#define H2P2_DBG_FPGA_P2_LED_TIMER (1 << 0)
+#define H2P2_DBG_FPGA_P2_LED_IDLE (1 << 1)
+
+#endif
diff --git a/arch/arm/plat-omap/include/plat/fpga.h b/arch/arm/plat-omap/include/plat/fpga.h
deleted file mode 100644
index bd3c632..0000000
--- a/arch/arm/plat-omap/include/plat/fpga.h
+++ /dev/null
@@ -1,193 +0,0 @@
-/*
- * arch/arm/plat-omap/include/mach/fpga.h
- *
- * Interrupt handler for OMAP-1510 FPGA
- *
- * Copyright (C) 2001 RidgeRun, Inc.
- * Author: Greg Lonnon <glonnon@ridgerun.com>
- *
- * Copyright (C) 2002 MontaVista Software, Inc.
- *
- * Separated FPGA interrupts from innovator1510.c and cleaned up for 2.6
- * Copyright (C) 2004 Nokia Corporation by Tony Lindrgen <tony@atomide.com>
- *
- * 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
- * published by the Free Software Foundation.
- */
-
-#ifndef __ASM_ARCH_OMAP_FPGA_H
-#define __ASM_ARCH_OMAP_FPGA_H
-
-extern void omap1510_fpga_init_irq(void);
-
-#define fpga_read(reg) __raw_readb(reg)
-#define fpga_write(val, reg) __raw_writeb(val, reg)
-
-/*
- * ---------------------------------------------------------------------------
- * H2/P2 Debug board FPGA
- * ---------------------------------------------------------------------------
- */
-/* maps in the FPGA registers and the ETHR registers */
-#define H2P2_DBG_FPGA_BASE 0xE8000000 /* VA */
-#define H2P2_DBG_FPGA_SIZE SZ_4K /* SIZE */
-#define H2P2_DBG_FPGA_START 0x04000000 /* PA */
-
-#define H2P2_DBG_FPGA_ETHR_START (H2P2_DBG_FPGA_START + 0x300)
-#define H2P2_DBG_FPGA_FPGA_REV IOMEM(H2P2_DBG_FPGA_BASE + 0x10) /* FPGA Revision */
-#define H2P2_DBG_FPGA_BOARD_REV IOMEM(H2P2_DBG_FPGA_BASE + 0x12) /* Board Revision */
-#define H2P2_DBG_FPGA_GPIO IOMEM(H2P2_DBG_FPGA_BASE + 0x14) /* GPIO outputs */
-#define H2P2_DBG_FPGA_LEDS IOMEM(H2P2_DBG_FPGA_BASE + 0x16) /* LEDs outputs */
-#define H2P2_DBG_FPGA_MISC_INPUTS IOMEM(H2P2_DBG_FPGA_BASE + 0x18) /* Misc inputs */
-#define H2P2_DBG_FPGA_LAN_STATUS IOMEM(H2P2_DBG_FPGA_BASE + 0x1A) /* LAN Status line */
-#define H2P2_DBG_FPGA_LAN_RESET IOMEM(H2P2_DBG_FPGA_BASE + 0x1C) /* LAN Reset line */
-
-/* NOTE: most boards don't have a static mapping for the FPGA ... */
-struct h2p2_dbg_fpga {
- /* offset 0x00 */
- u16 smc91x[8];
- /* offset 0x10 */
- u16 fpga_rev;
- u16 board_rev;
- u16 gpio_outputs;
- u16 leds;
- /* offset 0x18 */
- u16 misc_inputs;
- u16 lan_status;
- u16 lan_reset;
- u16 reserved0;
- /* offset 0x20 */
- u16 ps2_data;
- u16 ps2_ctrl;
- /* plus also 4 rs232 ports ... */
-};
-
-/* LEDs definition on debug board (16 LEDs, all physically green) */
-#define H2P2_DBG_FPGA_LED_GREEN (1 << 15)
-#define H2P2_DBG_FPGA_LED_AMBER (1 << 14)
-#define H2P2_DBG_FPGA_LED_RED (1 << 13)
-#define H2P2_DBG_FPGA_LED_BLUE (1 << 12)
-/* cpu0 load-meter LEDs */
-#define H2P2_DBG_FPGA_LOAD_METER (1 << 0) // A bit of fun on our board ...
-#define H2P2_DBG_FPGA_LOAD_METER_SIZE 11
-#define H2P2_DBG_FPGA_LOAD_METER_MASK ((1 << H2P2_DBG_FPGA_LOAD_METER_SIZE) - 1)
-
-#define H2P2_DBG_FPGA_P2_LED_TIMER (1 << 0)
-#define H2P2_DBG_FPGA_P2_LED_IDLE (1 << 1)
-
-/*
- * ---------------------------------------------------------------------------
- * OMAP-1510 FPGA
- * ---------------------------------------------------------------------------
- */
-#define OMAP1510_FPGA_BASE 0xE8000000 /* VA */
-#define OMAP1510_FPGA_SIZE SZ_4K
-#define OMAP1510_FPGA_START 0x08000000 /* PA */
-
-/* Revision */
-#define OMAP1510_FPGA_REV_LOW IOMEM(OMAP1510_FPGA_BASE + 0x0)
-#define OMAP1510_FPGA_REV_HIGH IOMEM(OMAP1510_FPGA_BASE + 0x1)
-
-#define OMAP1510_FPGA_LCD_PANEL_CONTROL IOMEM(OMAP1510_FPGA_BASE + 0x2)
-#define OMAP1510_FPGA_LED_DIGIT IOMEM(OMAP1510_FPGA_BASE + 0x3)
-#define INNOVATOR_FPGA_HID_SPI IOMEM(OMAP1510_FPGA_BASE + 0x4)
-#define OMAP1510_FPGA_POWER IOMEM(OMAP1510_FPGA_BASE + 0x5)
-
-/* Interrupt status */
-#define OMAP1510_FPGA_ISR_LO IOMEM(OMAP1510_FPGA_BASE + 0x6)
-#define OMAP1510_FPGA_ISR_HI IOMEM(OMAP1510_FPGA_BASE + 0x7)
-
-/* Interrupt mask */
-#define OMAP1510_FPGA_IMR_LO IOMEM(OMAP1510_FPGA_BASE + 0x8)
-#define OMAP1510_FPGA_IMR_HI IOMEM(OMAP1510_FPGA_BASE + 0x9)
-
-/* Reset registers */
-#define OMAP1510_FPGA_HOST_RESET IOMEM(OMAP1510_FPGA_BASE + 0xa)
-#define OMAP1510_FPGA_RST IOMEM(OMAP1510_FPGA_BASE + 0xb)
-
-#define OMAP1510_FPGA_AUDIO IOMEM(OMAP1510_FPGA_BASE + 0xc)
-#define OMAP1510_FPGA_DIP IOMEM(OMAP1510_FPGA_BASE + 0xe)
-#define OMAP1510_FPGA_FPGA_IO IOMEM(OMAP1510_FPGA_BASE + 0xf)
-#define OMAP1510_FPGA_UART1 IOMEM(OMAP1510_FPGA_BASE + 0x14)
-#define OMAP1510_FPGA_UART2 IOMEM(OMAP1510_FPGA_BASE + 0x15)
-#define OMAP1510_FPGA_OMAP1510_STATUS IOMEM(OMAP1510_FPGA_BASE + 0x16)
-#define OMAP1510_FPGA_BOARD_REV IOMEM(OMAP1510_FPGA_BASE + 0x18)
-#define OMAP1510P1_PPT_DATA IOMEM(OMAP1510_FPGA_BASE + 0x100)
-#define OMAP1510P1_PPT_STATUS IOMEM(OMAP1510_FPGA_BASE + 0x101)
-#define OMAP1510P1_PPT_CONTROL IOMEM(OMAP1510_FPGA_BASE + 0x102)
-
-#define OMAP1510_FPGA_TOUCHSCREEN IOMEM(OMAP1510_FPGA_BASE + 0x204)
-
-#define INNOVATOR_FPGA_INFO IOMEM(OMAP1510_FPGA_BASE + 0x205)
-#define INNOVATOR_FPGA_LCD_BRIGHT_LO IOMEM(OMAP1510_FPGA_BASE + 0x206)
-#define INNOVATOR_FPGA_LCD_BRIGHT_HI IOMEM(OMAP1510_FPGA_BASE + 0x207)
-#define INNOVATOR_FPGA_LED_GRN_LO IOMEM(OMAP1510_FPGA_BASE + 0x208)
-#define INNOVATOR_FPGA_LED_GRN_HI IOMEM(OMAP1510_FPGA_BASE + 0x209)
-#define INNOVATOR_FPGA_LED_RED_LO IOMEM(OMAP1510_FPGA_BASE + 0x20a)
-#define INNOVATOR_FPGA_LED_RED_HI IOMEM(OMAP1510_FPGA_BASE + 0x20b)
-#define INNOVATOR_FPGA_CAM_USB_CONTROL IOMEM(OMAP1510_FPGA_BASE + 0x20c)
-#define INNOVATOR_FPGA_EXP_CONTROL IOMEM(OMAP1510_FPGA_BASE + 0x20d)
-#define INNOVATOR_FPGA_ISR2 IOMEM(OMAP1510_FPGA_BASE + 0x20e)
-#define INNOVATOR_FPGA_IMR2 IOMEM(OMAP1510_FPGA_BASE + 0x210)
-
-#define OMAP1510_FPGA_ETHR_START (OMAP1510_FPGA_START + 0x300)
-
-/*
- * Power up Giga UART driver, turn on HID clock.
- * Turn off BT power, since we're not using it and it
- * draws power.
- */
-#define OMAP1510_FPGA_RESET_VALUE 0x42
-
-#define OMAP1510_FPGA_PCR_IF_PD0 (1 << 7)
-#define OMAP1510_FPGA_PCR_COM2_EN (1 << 6)
-#define OMAP1510_FPGA_PCR_COM1_EN (1 << 5)
-#define OMAP1510_FPGA_PCR_EXP_PD0 (1 << 4)
-#define OMAP1510_FPGA_PCR_EXP_PD1 (1 << 3)
-#define OMAP1510_FPGA_PCR_48MHZ_CLK (1 << 2)
-#define OMAP1510_FPGA_PCR_4MHZ_CLK (1 << 1)
-#define OMAP1510_FPGA_PCR_RSRVD_BIT0 (1 << 0)
-
-/*
- * Innovator/OMAP1510 FPGA HID register bit definitions
- */
-#define OMAP1510_FPGA_HID_SCLK (1<<0) /* output */
-#define OMAP1510_FPGA_HID_MOSI (1<<1) /* output */
-#define OMAP1510_FPGA_HID_nSS (1<<2) /* output 0/1 chip idle/select */
-#define OMAP1510_FPGA_HID_nHSUS (1<<3) /* output 0/1 host active/suspended */
-#define OMAP1510_FPGA_HID_MISO (1<<4) /* input */
-#define OMAP1510_FPGA_HID_ATN (1<<5) /* input 0/1 chip idle/ATN */
-#define OMAP1510_FPGA_HID_rsrvd (1<<6)
-#define OMAP1510_FPGA_HID_RESETn (1<<7) /* output - 0/1 USAR reset/run */
-
-/* The FPGA IRQ is cascaded through GPIO_13 */
-#define OMAP1510_INT_FPGA (IH_GPIO_BASE + 13)
-
-/* IRQ Numbers for interrupts muxed through the FPGA */
-#define OMAP1510_INT_FPGA_ATN (OMAP_FPGA_IRQ_BASE + 0)
-#define OMAP1510_INT_FPGA_ACK (OMAP_FPGA_IRQ_BASE + 1)
-#define OMAP1510_INT_FPGA2 (OMAP_FPGA_IRQ_BASE + 2)
-#define OMAP1510_INT_FPGA3 (OMAP_FPGA_IRQ_BASE + 3)
-#define OMAP1510_INT_FPGA4 (OMAP_FPGA_IRQ_BASE + 4)
-#define OMAP1510_INT_FPGA5 (OMAP_FPGA_IRQ_BASE + 5)
-#define OMAP1510_INT_FPGA6 (OMAP_FPGA_IRQ_BASE + 6)
-#define OMAP1510_INT_FPGA7 (OMAP_FPGA_IRQ_BASE + 7)
-#define OMAP1510_INT_FPGA8 (OMAP_FPGA_IRQ_BASE + 8)
-#define OMAP1510_INT_FPGA9 (OMAP_FPGA_IRQ_BASE + 9)
-#define OMAP1510_INT_FPGA10 (OMAP_FPGA_IRQ_BASE + 10)
-#define OMAP1510_INT_FPGA11 (OMAP_FPGA_IRQ_BASE + 11)
-#define OMAP1510_INT_FPGA12 (OMAP_FPGA_IRQ_BASE + 12)
-#define OMAP1510_INT_ETHER (OMAP_FPGA_IRQ_BASE + 13)
-#define OMAP1510_INT_FPGAUART1 (OMAP_FPGA_IRQ_BASE + 14)
-#define OMAP1510_INT_FPGAUART2 (OMAP_FPGA_IRQ_BASE + 15)
-#define OMAP1510_INT_FPGA_TS (OMAP_FPGA_IRQ_BASE + 16)
-#define OMAP1510_INT_FPGA17 (OMAP_FPGA_IRQ_BASE + 17)
-#define OMAP1510_INT_FPGA_CAM (OMAP_FPGA_IRQ_BASE + 18)
-#define OMAP1510_INT_FPGA_RTC_A (OMAP_FPGA_IRQ_BASE + 19)
-#define OMAP1510_INT_FPGA_RTC_B (OMAP_FPGA_IRQ_BASE + 20)
-#define OMAP1510_INT_FPGA_CD (OMAP_FPGA_IRQ_BASE + 21)
-#define OMAP1510_INT_FPGA22 (OMAP_FPGA_IRQ_BASE + 22)
-#define OMAP1510_INT_FPGA23 (OMAP_FPGA_IRQ_BASE + 23)
-
-#endif
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 4531d03..439e6e4 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -25,7 +25,6 @@
#include <asm/mach-types.h>
#include <mach/mux.h>
-#include <plat/fpga.h>
#include <mach/hardware.h>
#include <mach/irqs.h>
@@ -93,14 +92,14 @@ static int omap_ohci_transceiver_power(int on)
{
if (on) {
if (machine_is_omap_innovator() && cpu_is_omap1510())
- fpga_write(fpga_read(INNOVATOR_FPGA_CAM_USB_CONTROL)
+ __raw_writeb(__raw_readb(INNOVATOR_FPGA_CAM_USB_CONTROL)
| ((1 << 5/*usb1*/) | (1 << 3/*usb2*/)),
INNOVATOR_FPGA_CAM_USB_CONTROL);
else if (machine_is_omap_osk())
tps65010_set_gpio_out_value(GPIO1, LOW);
} else {
if (machine_is_omap_innovator() && cpu_is_omap1510())
- fpga_write(fpga_read(INNOVATOR_FPGA_CAM_USB_CONTROL)
+ __raw_writeb(__raw_readb(INNOVATOR_FPGA_CAM_USB_CONTROL)
& ~((1 << 5/*usb1*/) | (1 << 3/*usb2*/)),
INNOVATOR_FPGA_CAM_USB_CONTROL);
else if (machine_is_omap_osk())
diff --git a/drivers/video/omap/lcd_inn1510.c b/drivers/video/omap/lcd_inn1510.c
index b38b1dd..2ee4232 100644
--- a/drivers/video/omap/lcd_inn1510.c
+++ b/drivers/video/omap/lcd_inn1510.c
@@ -23,7 +23,8 @@
#include <linux/platform_device.h>
#include <linux/io.h>
-#include <plat/fpga.h>
+#include <mach/hardware.h>
+
#include "omapfb.h"
static int innovator1510_panel_init(struct lcd_panel *panel,
@@ -38,13 +39,13 @@ static void innovator1510_panel_cleanup(struct lcd_panel *panel)
static int innovator1510_panel_enable(struct lcd_panel *panel)
{
- fpga_write(0x7, OMAP1510_FPGA_LCD_PANEL_CONTROL);
+ __raw_writeb(0x7, OMAP1510_FPGA_LCD_PANEL_CONTROL);
return 0;
}
static void innovator1510_panel_disable(struct lcd_panel *panel)
{
- fpga_write(0x0, OMAP1510_FPGA_LCD_PANEL_CONTROL);
+ __raw_writeb(0x0, OMAP1510_FPGA_LCD_PANEL_CONTROL);
}
static unsigned long innovator1510_panel_get_caps(struct lcd_panel *panel)
^ permalink raw reply related
* Re: [PATCH 1/2 v6] of: add helper to parse display timings
From: Robert Schwebel @ 2012-10-05 7:17 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Steffen Trumtrar, devicetree-discuss, Rob Herring, linux-fbdev,
dri-devel, Laurent Pinchart, linux-media, Tomi Valkeinen,
Philipp Zabel
In-Reply-To: <Pine.LNX.4.64.1210042307300.3744@axis700.grange>
On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote:
> > +optional properties:
> > + - hsync-active-high (bool): Hsync pulse is active high
> > + - vsync-active-high (bool): Vsync pulse is active high
>
> For the above two we also considered using bool properties but eventually
> settled down with integer ones:
>
> - hsync-active = <1>
>
> for active-high and 0 for active low. This has the added advantage of
> being able to omit this property in the .dts, which then doesn't mean,
> that the polarity is active low, but rather, that the hsync line is not
> used on this hardware. So, maybe it would be good to use the same binding
> here too?
Philipp, this is the same argumentation as we discussed yesterday for
the dual-link LVDS option, so that one could be modelled in a similar
way.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] video/mx3fb: set .owner to prevent module unloading while being used
From: Uwe Kleine-König @ 2012-10-05 9:20 UTC (permalink / raw)
To: linux-fbdev
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/video/mx3fb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index d738108..ce1d452 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -1568,7 +1568,8 @@ static int mx3fb_remove(struct platform_device *dev)
static struct platform_driver mx3fb_driver = {
.driver = {
- .name = MX3FB_NAME,
+ .name = MX3FB_NAME,
+ .owner = THIS_MODULE,
},
.probe = mx3fb_probe,
.remove = mx3fb_remove,
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 04/14] media: add V4L2 DT binding documentation
From: Guennadi Liakhovetski @ 2012-10-05 9:43 UTC (permalink / raw)
To: Rob Herring
Cc: Linux Media Mailing List, linux-sh, devicetree-discuss,
Mark Brown, Magnus Damm, Hans Verkuil, Laurent Pinchart,
Sylwester Nawrocki, linux-fbdev, dri-devel, Steffen Trumtrar,
Robert Schwebel, Philipp Zabel
In-Reply-To: <506CA5F7.3060807@gmail.com>
On Wed, 3 Oct 2012, Rob Herring wrote:
> On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote:
> > Hi Rob
> >
> > On Tue, 2 Oct 2012, Rob Herring wrote:
> >
> >> On 09/27/2012 09:07 AM, Guennadi Liakhovetski wrote:
> >>> This patch adds a document, describing common V4L2 device tree bindings.
> >>>
> >>> Co-authored-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> >>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> >>> ---
> >>> Documentation/devicetree/bindings/media/v4l2.txt | 162 ++++++++++++++++++++++
> >>> 1 files changed, 162 insertions(+), 0 deletions(-)
> >>> create mode 100644 Documentation/devicetree/bindings/media/v4l2.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/media/v4l2.txt b/Documentation/devicetree/bindings/media/v4l2.txt
> >>> new file mode 100644
> >>> index 0000000..b8b3f41
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/media/v4l2.txt
> >>> @@ -0,0 +1,162 @@
> >>> +Video4Linux Version 2 (V4L2)
> >>
> >> DT describes the h/w, but V4L2 is Linux specific. I think the binding
> >> looks pretty good in terms of it is describing the h/w and not V4L2
> >> components or settings. So in this case it's really just the name of the
> >> file and title I have issue with.
> >
> > Hm, I see your point, then, I guess, you'd also like the file name
> > changed. What should we use then? Just "video?" But there's already a
> > whole directory Documentation/devicetree/bindings/video dedicated to
> > graphics output (drm, fbdev). "video-camera" or "video-capture?" But this
> > file shall also be describing video output. Use "video.txt" and describe
> > inside what exactly this file is for?
>
> Video output will probably have a lot of overlap with the graphics side.
> How about video-interfaces.txt?
Hm, that's a bit too vague for me. Somewhere on the outskirts of my mind
I'm still considering making just one standard for both V4L2 and fbdev /
DRM? Just yesterday we were discussing some common properties with what is
being proposed in
http://www.mail-archive.com/linux-media@vger.kernel.org/index.html#53322
Still, I think, these two subsystems deserve two separate standards and
should just try to re-use properties wherever that makes sense.
video-stream seems a bit better, but this too is just a convention -
talking about video cameras and TV output as video streaming devices and
considering displays more static devices. In principle displays can be
considered taking streaming data just as well as TV encoders. What if we
just call this camera-tv.txt?
> >> One other comment below:
> >>
> >>> +
> >>> +General concept
> >>> +---------------
> >>> +
> >>> +Video pipelines consist of external devices, e.g. camera sensors, controlled
> >>> +over an I2C, SPI or UART bus, and SoC internal IP blocks, including video DMA
> >>> +engines and video data processors.
> >>> +
> >>> +SoC internal blocks are described by DT nodes, placed similarly to other SoC
> >>> +blocks. External devices are represented as child nodes of their respective bus
> >>> +controller nodes, e.g. I2C.
> >>> +
> >>> +Data interfaces on all video devices are described by "port" child DT nodes.
> >>> +Configuration of a port depends on other devices participating in the data
> >>> +transfer and is described by "link" DT nodes, specified as children of the
> >>> +"port" nodes:
> >>> +
> >>> +/foo {
> >>> + port@0 {
> >>> + link@0 { ... };
> >>> + link@1 { ... };
> >>> + };
> >>> + port@1 { ... };
> >>> +};
> >>> +
> >>> +If a port can be configured to work with more than one other device on the same
> >>> +bus, a "link" child DT node must be provided for each of them. If more than one
> >>> +port is present on a device or more than one link is connected to a port, a
> >>> +common scheme, using "#address-cells," "#size-cells" and "reg" properties is
> >>> +used.
> >>> +
> >>> +Optional link properties:
> >>> +- remote: phandle to the other endpoint link DT node.
> >>
> >> This name is a little vague. Perhaps "endpoint" would be better.
> >
> > "endpoint" can also refer to something local like in USB case. Maybe
> > rather the description of the "remote" property should be improved?
>
> remote-endpoint?
Sorry, I really don't want to pull in yet another term here. We've got
ports and links already, now you're proposing to also use "endpoind."
Until now everyone was happy with "remote," any more opinions on this?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: omap DSS cmdline resolution not working for HDMI?
From: Tomi Valkeinen @ 2012-10-05 11:04 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev
In-Reply-To: <20121004175604.GE3874@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 3270 bytes --]
On Thu, 2012-10-04 at 10:56 -0700, Tony Lindgren wrote:
> Hi,
>
> FYI, looks like for some reason DSS command line is not
> working for HDMI while it works for DSS. On my panda es
> I'm trying to set my motorola lapdock resolution from
> cmdline with:
>
> omapdss.def_disp=hdmi omapfb.mode=hdmi:1366x768@60
>
> But it does not seem to do anything and resolution is
> VGA. If I change the cable to DVI port this works:
>
> omapdss.def_disp=dvi omapfb.mode=dvi:1366x768@60
>
> Any ideas? This is with current linux next.
That's because our HDMI only supports certain timings. To be honest, I
don't really understand this restriction, as I believe the hardware
should be able to use more or less any timings just like DVI.
The 1366x768@60 mode is parsed with fbdev functions, which returns a
video timings. These timings are then given to the HDMI driver, which
tries to find matching timings from its timing table. And when it
doesn't find a match, it fails.
This is a known problem, and the hdmi driver would really need some love
in other aspects also. I'm not sure what would be the best way to
improve this without doing major rewrites. Perhaps the check in the hdmi
driver could be more relaxed, but that needs some careful thought.
> I can change the HDMI resolution OK from userspace with:
>
> echo "1" > /sys/devices/platform/omapdss/display1/enabled
> echo "0" > /sys/devices/platform/omapdss/overlay0/enabled
> echo "tv" > /sys/devices/platform/omapdss/overlay0/manager
> echo "1" > /sys/devices/platform/omapdss/overlay0/enabled
> echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/display1/timings
That's because the above line has timings that are in the hdmi driver's
table. They are somewhat different than what fbdev gives for
"1366x768@60".
> The reason to use HDMI instead of DVI here is that HDMI
> also has the speakers on the lapdock ;)
>
> Then I'm able to switch between HDMI panel and DVI panel
> just fine using overlay0. I don't know if getting both
> HDMI and DVI to work the same time using overlay1 is
> supposed to work, but trying use overlay1 produces the
> following:
HDMI and DVI cannot be used reliably at the same time, due to a HW issue
we've had unresolved for a long time. Luckily, it was solved this week
and we'll have a patch for next merge window to get this working.
> echo "1" > /sys/devices/platform/omapdss/display0/enabled
> echo "0" > /sys/devices/platform/omapdss/overlay1/enabled
> echo "lcd2" > /sys/devices/platform/omapdss/overlay1/manager
> echo "1" > /sys/devices/platform/omapdss/overlay1/enabled
> echo "170666,1920/336/128/208,1200/38/1/3" > /sys/devices/platform/omapdss/display0/timings
>
> [ 816.446044] omapdss DPI: Could not find exact pixel clock. Requested 23500 kHz, got 23630 kHz
> [ 881.639221] omapdss APPLY: timeout in wait_pending_extra_info_updates
> [ 958.946594] ------------[ cut here ]------------
> [ 958.953277] WARNING: at drivers/bus/omap_l3_noc.c:97 l3_interrupt_handler+0xc0/0x184()
> [ 958.965576] L3 standard error: TARGET:DMM2 at address 0x0
> ...
Having said the above, I don't quite know where this error comes from...
Tiler (DMM) is not even used by omapfb.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 04/14] media: add V4L2 DT binding documentation
From: Hans Verkuil @ 2012-10-05 11:31 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Rob Herring, Linux Media Mailing List, linux-sh,
devicetree-discuss, Mark Brown, Magnus Damm, Laurent Pinchart,
Sylwester Nawrocki, linux-fbdev, dri-devel, Steffen Trumtrar,
Robert Schwebel, Philipp Zabel
In-Reply-To: <Pine.LNX.4.64.1210051119420.13761@axis700.grange>
On Fri October 5 2012 11:43:27 Guennadi Liakhovetski wrote:
> On Wed, 3 Oct 2012, Rob Herring wrote:
>
> > On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote:
> > > Hi Rob
> > >
> > > On Tue, 2 Oct 2012, Rob Herring wrote:
> > >
> > >> On 09/27/2012 09:07 AM, Guennadi Liakhovetski wrote:
> > >>> This patch adds a document, describing common V4L2 device tree bindings.
> > >>>
> > >>> Co-authored-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> > >>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > >>> ---
> > >>> Documentation/devicetree/bindings/media/v4l2.txt | 162 ++++++++++++++++++++++
> > >>> 1 files changed, 162 insertions(+), 0 deletions(-)
> > >>> create mode 100644 Documentation/devicetree/bindings/media/v4l2.txt
> > >>>
> > >>> diff --git a/Documentation/devicetree/bindings/media/v4l2.txt b/Documentation/devicetree/bindings/media/v4l2.txt
> > >>> new file mode 100644
> > >>> index 0000000..b8b3f41
> > >>> --- /dev/null
> > >>> +++ b/Documentation/devicetree/bindings/media/v4l2.txt
> > >>> @@ -0,0 +1,162 @@
> > >>> +Video4Linux Version 2 (V4L2)
> > >>
> > >> DT describes the h/w, but V4L2 is Linux specific. I think the binding
> > >> looks pretty good in terms of it is describing the h/w and not V4L2
> > >> components or settings. So in this case it's really just the name of the
> > >> file and title I have issue with.
> > >
> > > Hm, I see your point, then, I guess, you'd also like the file name
> > > changed. What should we use then? Just "video?" But there's already a
> > > whole directory Documentation/devicetree/bindings/video dedicated to
> > > graphics output (drm, fbdev). "video-camera" or "video-capture?" But this
> > > file shall also be describing video output. Use "video.txt" and describe
> > > inside what exactly this file is for?
> >
> > Video output will probably have a lot of overlap with the graphics side.
> > How about video-interfaces.txt?
>
> Hm, that's a bit too vague for me. Somewhere on the outskirts of my mind
> I'm still considering making just one standard for both V4L2 and fbdev /
> DRM? Just yesterday we were discussing some common properties with what is
> being proposed in
>
> http://www.mail-archive.com/linux-media@vger.kernel.org/index.html#53322
>
> Still, I think, these two subsystems deserve two separate standards and
> should just try to re-use properties wherever that makes sense.
> video-stream seems a bit better, but this too is just a convention -
> talking about video cameras and TV output as video streaming devices and
> considering displays more static devices. In principle displays can be
> considered taking streaming data just as well as TV encoders. What if we
> just call this camera-tv.txt?
>
> > >> One other comment below:
> > >>
> > >>> +
> > >>> +General concept
> > >>> +---------------
> > >>> +
> > >>> +Video pipelines consist of external devices, e.g. camera sensors, controlled
> > >>> +over an I2C, SPI or UART bus, and SoC internal IP blocks, including video DMA
> > >>> +engines and video data processors.
> > >>> +
> > >>> +SoC internal blocks are described by DT nodes, placed similarly to other SoC
> > >>> +blocks. External devices are represented as child nodes of their respective bus
> > >>> +controller nodes, e.g. I2C.
> > >>> +
> > >>> +Data interfaces on all video devices are described by "port" child DT nodes.
> > >>> +Configuration of a port depends on other devices participating in the data
> > >>> +transfer and is described by "link" DT nodes, specified as children of the
> > >>> +"port" nodes:
> > >>> +
> > >>> +/foo {
> > >>> + port@0 {
> > >>> + link@0 { ... };
> > >>> + link@1 { ... };
> > >>> + };
> > >>> + port@1 { ... };
> > >>> +};
> > >>> +
> > >>> +If a port can be configured to work with more than one other device on the same
> > >>> +bus, a "link" child DT node must be provided for each of them. If more than one
> > >>> +port is present on a device or more than one link is connected to a port, a
> > >>> +common scheme, using "#address-cells," "#size-cells" and "reg" properties is
> > >>> +used.
> > >>> +
> > >>> +Optional link properties:
> > >>> +- remote: phandle to the other endpoint link DT node.
> > >>
> > >> This name is a little vague. Perhaps "endpoint" would be better.
> > >
> > > "endpoint" can also refer to something local like in USB case. Maybe
> > > rather the description of the "remote" property should be improved?
> >
> > remote-endpoint?
>
> Sorry, I really don't want to pull in yet another term here. We've got
> ports and links already, now you're proposing to also use "endpoind."
> Until now everyone was happy with "remote," any more opinions on this?
Actually, when I was reviewing the patch series today I got confused as
well by 'remote'. What about 'remote-link'?
And v4l2_of_get_remote() can be renamed to v4l2_of_get_remote_link() which
I think is a lot clearer.
The text can be improved as well since this:
- remote: phandle to the other endpoint link DT node.
is a bit vague. How about:
- remote-link: phandle to the remote end of this link.
Regards,
Hans
^ permalink raw reply
* Re: omap DSS cmdline resolution not working for HDMI?
From: Archit Taneja @ 2012-10-05 11:35 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Tony Lindgren, linux-omap, linux-fbdev
In-Reply-To: <1349435094.2401.17.camel@deskari>
On Friday 05 October 2012 04:34 PM, Tomi Valkeinen wrote:
> On Thu, 2012-10-04 at 10:56 -0700, Tony Lindgren wrote:
>> Hi,
>>
>> FYI, looks like for some reason DSS command line is not
>> working for HDMI while it works for DSS. On my panda es
>> I'm trying to set my motorola lapdock resolution from
>> cmdline with:
>>
>> omapdss.def_disp=hdmi omapfb.mode=hdmi:1366x768@60
>>
>> But it does not seem to do anything and resolution is
>> VGA. If I change the cable to DVI port this works:
>>
>> omapdss.def_disp=dvi omapfb.mode=dvi:1366x768@60
>>
>> Any ideas? This is with current linux next.
>
> That's because our HDMI only supports certain timings. To be honest, I
> don't really understand this restriction, as I believe the hardware
> should be able to use more or less any timings just like DVI.
>
> The 1366x768@60 mode is parsed with fbdev functions, which returns a
> video timings. These timings are then given to the HDMI driver, which
> tries to find matching timings from its timing table. And when it
> doesn't find a match, it fails.
>
> This is a known problem, and the hdmi driver would really need some love
> in other aspects also. I'm not sure what would be the best way to
> improve this without doing major rewrites. Perhaps the check in the hdmi
> driver could be more relaxed, but that needs some careful thought.
>
>> I can change the HDMI resolution OK from userspace with:
>>
>> echo "1" > /sys/devices/platform/omapdss/display1/enabled
>> echo "0" > /sys/devices/platform/omapdss/overlay0/enabled
>> echo "tv" > /sys/devices/platform/omapdss/overlay0/manager
>> echo "1" > /sys/devices/platform/omapdss/overlay0/enabled
>> echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/display1/timings
>
> That's because the above line has timings that are in the hdmi driver's
> table. They are somewhat different than what fbdev gives for
> "1366x768@60".
>
>> The reason to use HDMI instead of DVI here is that HDMI
>> also has the speakers on the lapdock ;)
>>
>> Then I'm able to switch between HDMI panel and DVI panel
>> just fine using overlay0. I don't know if getting both
>> HDMI and DVI to work the same time using overlay1 is
>> supposed to work, but trying use overlay1 produces the
>> following:
>
> HDMI and DVI cannot be used reliably at the same time, due to a HW issue
> we've had unresolved for a long time. Luckily, it was solved this week
> and we'll have a patch for next merge window to get this working.
>
>> echo "1" > /sys/devices/platform/omapdss/display0/enabled
>> echo "0" > /sys/devices/platform/omapdss/overlay1/enabled
>> echo "lcd2" > /sys/devices/platform/omapdss/overlay1/manager
>> echo "1" > /sys/devices/platform/omapdss/overlay1/enabled
>> echo "170666,1920/336/128/208,1200/38/1/3" > /sys/devices/platform/omapdss/display0/timings
>>
>> [ 816.446044] omapdss DPI: Could not find exact pixel clock. Requested 23500 kHz, got 23630 kHz
>> [ 881.639221] omapdss APPLY: timeout in wait_pending_extra_info_updates
>> [ 958.946594] ------------[ cut here ]------------
>> [ 958.953277] WARNING: at drivers/bus/omap_l3_noc.c:97 l3_interrupt_handler+0xc0/0x184()
>> [ 958.965576] L3 standard error: TARGET:DMM2 at address 0x0
>> ...
>
> Having said the above, I don't quite know where this error comes from...
> Tiler (DMM) is not even used by omapfb.
There is a timeout in wait_pending_extra_info_updates() which happens
before. That's something that shouldn't have occurred.
The overlay1 disable would have led to extra info being dirty. The
unsetting of the manager led to the call of
wait_pending_extra_info_updates(). This function noticed that there is
an extra_info update on going, and waited for the completion, but never
got it. I'm not sure why that's happened.
Archit
^ permalink raw reply
* Re: [PATCH 04/14] media: add V4L2 DT binding documentation
From: Guennadi Liakhovetski @ 2012-10-05 11:37 UTC (permalink / raw)
To: Hans Verkuil
Cc: Rob Herring, Linux Media Mailing List, linux-sh,
devicetree-discuss, Mark Brown, Magnus Damm, Laurent Pinchart,
Sylwester Nawrocki, linux-fbdev, dri-devel, Steffen Trumtrar,
Robert Schwebel, Philipp Zabel
In-Reply-To: <201210051331.18586.hverkuil@xs4all.nl>
On Fri, 5 Oct 2012, Hans Verkuil wrote:
> On Fri October 5 2012 11:43:27 Guennadi Liakhovetski wrote:
> > On Wed, 3 Oct 2012, Rob Herring wrote:
> >
> > > On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote:
> > > > Hi Rob
> > > >
> > > > On Tue, 2 Oct 2012, Rob Herring wrote:
> > > >
> > > >> On 09/27/2012 09:07 AM, Guennadi Liakhovetski wrote:
[snip]
> > > >>> +Optional link properties:
> > > >>> +- remote: phandle to the other endpoint link DT node.
> > > >>
> > > >> This name is a little vague. Perhaps "endpoint" would be better.
> > > >
> > > > "endpoint" can also refer to something local like in USB case. Maybe
> > > > rather the description of the "remote" property should be improved?
> > >
> > > remote-endpoint?
> >
> > Sorry, I really don't want to pull in yet another term here. We've got
> > ports and links already, now you're proposing to also use "endpoind."
> > Until now everyone was happy with "remote," any more opinions on this?
>
> Actually, when I was reviewing the patch series today I got confused as
> well by 'remote'. What about 'remote-link'?
Yes, I was thinking about this one too, it looks a bit clumsy, but it does
make it clearer, what is meant.
> And v4l2_of_get_remote() can be renamed to v4l2_of_get_remote_link() which
> I think is a lot clearer.
>
> The text can be improved as well since this:
>
> - remote: phandle to the other endpoint link DT node.
>
> is a bit vague. How about:
>
> - remote-link: phandle to the remote end of this link.
Looks good to me.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH V4 4/5] OMAPDSS: Replace multi part debug prints with pr_debug
From: Tomi Valkeinen @ 2012-10-05 12:33 UTC (permalink / raw)
To: Chandrabhanu Mahapatra; +Cc: linux-omap, linux-fbdev
In-Reply-To: <8fb0b3848f5d6148889f2b5160b8aa40e764f409.1348914940.git.cmahapatra@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]
On Sat, 2012-09-29 at 16:19 +0530, Chandrabhanu Mahapatra wrote:
> The omap_dispc_unregister_isr() and _dsi_print_reset_status() consist of a
> number of debug prints which need to be enabled all at once or none at all. So,
> these debug prints in corresponding functions are replaced with one dynamic
> debug enabled pr_debug() each.
>
> Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
> ---
> drivers/video/omap2/dss/dispc.c | 32 +++++++++++++-------------------
> drivers/video/omap2/dss/dsi.c | 30 ++++++++++++++----------------
> 2 files changed, 27 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index a173a94..67d9f3b 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -3675,26 +3675,20 @@ static void print_irq_status(u32 status)
> if ((status & dispc.irq_error_mask) == 0)
> return;
>
> - printk(KERN_DEBUG "DISPC IRQ: 0x%x: ", status);
> -
> -#define PIS(x) \
> - if (status & DISPC_IRQ_##x) \
> - printk(#x " ");
> - PIS(GFX_FIFO_UNDERFLOW);
> - PIS(OCP_ERR);
> - PIS(VID1_FIFO_UNDERFLOW);
> - PIS(VID2_FIFO_UNDERFLOW);
> - if (dss_feat_get_num_ovls() > 3)
> - PIS(VID3_FIFO_UNDERFLOW);
> - PIS(SYNC_LOST);
> - PIS(SYNC_LOST_DIGIT);
> - if (dss_has_feature(FEAT_MGR_LCD2))
> - PIS(SYNC_LOST2);
> - if (dss_has_feature(FEAT_MGR_LCD3))
> - PIS(SYNC_LOST3);
> +#define PIS(x) (status & DISPC_IRQ_##x) ? (#x " ") : ""
> +
> + pr_debug("DISPC IRQ: 0x%x: %s%s%s%s%s%s%s%s%s\n",
> + status,
> + PIS(OCP_ERR),
> + PIS(GFX_FIFO_UNDERFLOW),
> + PIS(VID1_FIFO_UNDERFLOW),
> + PIS(VID2_FIFO_UNDERFLOW),
> + dss_feat_get_num_ovls() > 3 ? PIS(VID3_FIFO_UNDERFLOW) : "",
> + PIS(SYNC_LOST),
> + PIS(SYNC_LOST_DIGIT),
> + dss_has_feature(FEAT_MGR_LCD2) ? PIS(SYNC_LOST2) : "",
> + dss_has_feature(FEAT_MGR_LCD3) ? PIS(SYNC_LOST3) : "");
> #undef PIS
> -
> - printk("\n");
> }
> #endif
There's similar irq printing code in dsi.c that should also be converted
to the above style.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH V4 0/5] OMAPDSS: Enable dynamic debug printing
From: Tomi Valkeinen @ 2012-10-05 12:46 UTC (permalink / raw)
To: Chandrabhanu Mahapatra; +Cc: linux-omap, linux-fbdev
In-Reply-To: <cover.1348914940.git.cmahapatra@ti.com>
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
On Sat, 2012-09-29 at 16:19 +0530, Chandrabhanu Mahapatra wrote:
> Hi everyone,
> this patch series aims at cleaning up of DSS of printk()'s enabled with
> dss_debug and replace them with generic dynamic debug printing.
Except for the missing debug print conversions in dsi.c this looks good.
Do you want me to apply the current series and you can send the dsi.c
patch later, or do you want to fix the dsi.c also before I apply?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 0/2] da8xx-fb LCDC driver cleanup
From: Manjunathappa, Prakash @ 2012-10-05 14:03 UTC (permalink / raw)
To: linux-fbdev
This patch series clean up driver as it is necessary for DT migration
1) Moves panel information from driver to platform file.
2) Panel independent LCDC configuration are set to optimal values.
Manjunathappa, Prakash (2):
da8xx-fb: move panel information from driver to platform file
da8xx-fb: cleanup LCDC configurations
arch/arm/mach-davinci/devices-da8xx.c | 55 ++++++-----
drivers/video/da8xx-fb.c | 164 +++++++++------------------------
include/video/da8xx-fb.h | 28 +-----
3 files changed, 79 insertions(+), 168 deletions(-)
^ permalink raw reply
* [PATCH 1/2] da8xx-fb: move panel information from driver to platform file
From: Manjunathappa, Prakash @ 2012-10-05 14:03 UTC (permalink / raw)
To: linux-fbdev
Moving panel information from driver to platform file, patch also made
compliant to fb_videomode data.
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
---
arch/arm/mach-davinci/devices-da8xx.c | 32 +++++++-
drivers/video/da8xx-fb.c | 127 ++++++++-------------------------
include/video/da8xx-fb.h | 8 ++-
3 files changed, 64 insertions(+), 103 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 783eab6..12a47cd 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -550,15 +550,39 @@ static struct lcd_ctrl_config lcd_cfg = {
};
struct da8xx_lcdc_platform_data sharp_lcd035q3dg01_pdata = {
- .manu_name = "sharp",
.controller_data = &lcd_cfg,
- .type = "Sharp_LCD035Q3DG01",
+ .fb_videomode = {
+ .name = "Sharp_LCD035Q3DG01",
+ .xres = 320,
+ .yres = 240,
+ .pixclock = 4608000,
+ .left_margin = 6,
+ .right_margin = 8,
+ .upper_margin = 2,
+ .lower_margin = 2,
+ .hsync_len = 0,
+ .vsync_len = 0,
+ .sync = FB_SYNC_CLK_INVERT,
+ .flag = 0,
+ },
};
struct da8xx_lcdc_platform_data sharp_lk043t1dg01_pdata = {
- .manu_name = "sharp",
.controller_data = &lcd_cfg,
- .type = "Sharp_LK043T1DG01",
+ .fb_videomode = {
+ .name = "Sharp_LK043T1DG01",
+ .xres = 480,
+ .yres = 272,
+ .pixclock = 7833600,
+ .left_margin = 2,
+ .right_margin = 2,
+ .upper_margin = 2,
+ .lower_margin = 2,
+ .hsync_len = 41,
+ .vsync_len = 10,
+ .sync = 0,
+ .flag = 0,
+ },
};
static struct resource da8xx_lcdc_resources[] = {
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 65a11ef..bacf82b 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -21,7 +21,6 @@
*/
#include <linux/module.h>
#include <linux/kernel.h>
-#include <linux/fb.h>
#include <linux/dma-mapping.h>
#include <linux/device.h>
#include <linux/platform_device.h>
@@ -213,65 +212,6 @@ static struct fb_fix_screeninfo da8xx_fb_fix __devinitdata = {
.accel = FB_ACCEL_NONE
};
-struct da8xx_panel {
- const char name[25]; /* Full name <vendor>_<model> */
- unsigned short width;
- unsigned short height;
- int hfp; /* Horizontal front porch */
- int hbp; /* Horizontal back porch */
- int hsw; /* Horizontal Sync Pulse Width */
- int vfp; /* Vertical front porch */
- int vbp; /* Vertical back porch */
- int vsw; /* Vertical Sync Pulse Width */
- unsigned int pxl_clk; /* Pixel clock */
- unsigned char invert_pxl_clk; /* Invert Pixel clock */
-};
-
-static struct da8xx_panel known_lcd_panels[] = {
- /* Sharp LCD035Q3DG01 */
- [0] = {
- .name = "Sharp_LCD035Q3DG01",
- .width = 320,
- .height = 240,
- .hfp = 8,
- .hbp = 6,
- .hsw = 0,
- .vfp = 2,
- .vbp = 2,
- .vsw = 0,
- .pxl_clk = 4608000,
- .invert_pxl_clk = 1,
- },
- /* Sharp LK043T1DG01 */
- [1] = {
- .name = "Sharp_LK043T1DG01",
- .width = 480,
- .height = 272,
- .hfp = 2,
- .hbp = 2,
- .hsw = 41,
- .vfp = 2,
- .vbp = 2,
- .vsw = 10,
- .pxl_clk = 7833600,
- .invert_pxl_clk = 0,
- },
- [2] = {
- /* Hitachi SP10Q010 */
- .name = "SP10Q010",
- .width = 320,
- .height = 240,
- .hfp = 10,
- .hbp = 10,
- .hsw = 10,
- .vfp = 10,
- .vbp = 10,
- .vsw = 10,
- .pxl_clk = 7833600,
- .invert_pxl_clk = 0,
- },
-};
-
/* Enable the Raster Engine of the LCD Controller */
static inline void lcd_enable_raster(void)
{
@@ -728,7 +668,7 @@ static void lcd_calc_clk_divider(struct da8xx_fb_par *par)
}
static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
- struct da8xx_panel *panel)
+ struct fb_videomode *panel)
{
u32 bpp;
int ret = 0;
@@ -738,7 +678,7 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
/* Calculate the divider */
lcd_calc_clk_divider(par);
- if (panel->invert_pxl_clk)
+ if (panel->sync & FB_SYNC_CLK_INVERT)
lcdc_write((lcdc_read(LCD_RASTER_TIMING_2_REG) |
LCD_INVERT_PIXEL_CLOCK), LCD_RASTER_TIMING_2_REG);
else
@@ -754,8 +694,10 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
lcd_cfg_ac_bias(cfg->ac_bias, cfg->ac_bias_intrpt);
/* Configure the vertical and horizontal sync properties. */
- lcd_cfg_vertical_sync(panel->vbp, panel->vsw, panel->vfp);
- lcd_cfg_horizontal_sync(panel->hbp, panel->hsw, panel->hfp);
+ lcd_cfg_vertical_sync(panel->lower_margin, panel->vsync_len,
+ panel->upper_margin);
+ lcd_cfg_horizontal_sync(panel->right_margin, panel->hsync_len,
+ panel->left_margin);
/* Configure for disply */
ret = lcd_cfg_display(cfg);
@@ -772,8 +714,8 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
bpp = cfg->p_disp_panel->max_bpp;
if (bpp = 12)
bpp = 16;
- ret = lcd_cfg_frame_buffer(par, (unsigned int)panel->width,
- (unsigned int)panel->height, bpp,
+ ret = lcd_cfg_frame_buffer(par, (unsigned int)panel->xres,
+ (unsigned int)panel->yres, bpp,
cfg->raster_order);
if (ret < 0)
return ret;
@@ -1235,12 +1177,12 @@ static int __devinit fb_probe(struct platform_device *device)
struct da8xx_lcdc_platform_data *fb_pdata device->dev.platform_data;
struct lcd_ctrl_config *lcd_cfg;
- struct da8xx_panel *lcdc_info;
+ struct fb_videomode *lcd_panel_info;
struct fb_info *da8xx_fb_info;
struct clk *fb_clk = NULL;
struct da8xx_fb_par *par;
resource_size_t len;
- int ret, i;
+ int ret;
unsigned long ulcm;
if (fb_pdata = NULL) {
@@ -1293,20 +1235,10 @@ static int __devinit fb_probe(struct platform_device *device)
break;
}
- for (i = 0, lcdc_info = known_lcd_panels;
- i < ARRAY_SIZE(known_lcd_panels);
- i++, lcdc_info++) {
- if (strcmp(fb_pdata->type, lcdc_info->name) = 0)
- break;
- }
+ lcd_panel_info = &fb_pdata->fb_videomode;
- if (i = ARRAY_SIZE(known_lcd_panels)) {
- dev_err(&device->dev, "GLCD: No valid panel found\n");
- ret = -ENODEV;
- goto err_pm_runtime_disable;
- } else
- dev_info(&device->dev, "GLCD: Found %s panel\n",
- fb_pdata->type);
+ dev_info(&device->dev, "Configuring GLCD %s panel\n",
+ lcd_panel_info->name);
lcd_cfg = (struct lcd_ctrl_config *)fb_pdata->controller_data;
@@ -1323,21 +1255,22 @@ static int __devinit fb_probe(struct platform_device *device)
#ifdef CONFIG_CPU_FREQ
par->lcd_fck_rate = clk_get_rate(fb_clk);
#endif
- par->pxl_clk = lcdc_info->pxl_clk;
+ par->pxl_clk = lcd_panel_info->pixclock;
if (fb_pdata->panel_power_ctrl) {
par->panel_power_ctrl = fb_pdata->panel_power_ctrl;
par->panel_power_ctrl(1);
}
- if (lcd_init(par, lcd_cfg, lcdc_info) < 0) {
+ if (lcd_init(par, lcd_cfg, lcd_panel_info) < 0) {
dev_err(&device->dev, "lcd_init failed\n");
ret = -EFAULT;
goto err_release_fb;
}
/* allocate frame buffer */
- par->vram_size = lcdc_info->width * lcdc_info->height * lcd_cfg->bpp;
- ulcm = lcm((lcdc_info->width * lcd_cfg->bpp)/8, PAGE_SIZE);
+ par->vram_size + lcd_panel_info->xres * lcd_panel_info->yres * lcd_cfg->bpp;
+ ulcm = lcm((lcd_panel_info->xres * lcd_cfg->bpp)/8, PAGE_SIZE);
par->vram_size = roundup(par->vram_size/8, ulcm);
par->vram_size = par->vram_size * LCD_NUM_BUFFERS;
@@ -1355,10 +1288,10 @@ static int __devinit fb_probe(struct platform_device *device)
da8xx_fb_info->screen_base = (char __iomem *) par->vram_virt;
da8xx_fb_fix.smem_start = par->vram_phys;
da8xx_fb_fix.smem_len = par->vram_size;
- da8xx_fb_fix.line_length = (lcdc_info->width * lcd_cfg->bpp) / 8;
+ da8xx_fb_fix.line_length = (lcd_panel_info->xres * lcd_cfg->bpp) / 8;
par->dma_start = par->vram_phys;
- par->dma_end = par->dma_start + lcdc_info->height *
+ par->dma_end = par->dma_start + lcd_panel_info->yres *
da8xx_fb_fix.line_length - 1;
/* allocate palette buffer */
@@ -1384,22 +1317,22 @@ static int __devinit fb_probe(struct platform_device *device)
/* Initialize par */
da8xx_fb_info->var.bits_per_pixel = lcd_cfg->bpp;
- da8xx_fb_var.xres = lcdc_info->width;
- da8xx_fb_var.xres_virtual = lcdc_info->width;
+ da8xx_fb_var.xres = lcd_panel_info->xres;
+ da8xx_fb_var.xres_virtual = lcd_panel_info->yres;
- da8xx_fb_var.yres = lcdc_info->height;
- da8xx_fb_var.yres_virtual = lcdc_info->height * LCD_NUM_BUFFERS;
+ da8xx_fb_var.yres = lcd_panel_info->yres;
+ da8xx_fb_var.yres_virtual = lcd_panel_info->yres * LCD_NUM_BUFFERS;
da8xx_fb_var.grayscale lcd_cfg->p_disp_panel->panel_shade = MONOCHROME ? 1 : 0;
da8xx_fb_var.bits_per_pixel = lcd_cfg->bpp;
- da8xx_fb_var.hsync_len = lcdc_info->hsw;
- da8xx_fb_var.vsync_len = lcdc_info->vsw;
- da8xx_fb_var.right_margin = lcdc_info->hfp;
- da8xx_fb_var.left_margin = lcdc_info->hbp;
- da8xx_fb_var.lower_margin = lcdc_info->vfp;
- da8xx_fb_var.upper_margin = lcdc_info->vbp;
+ da8xx_fb_var.hsync_len = lcd_panel_info->hsync_len;
+ da8xx_fb_var.vsync_len = lcd_panel_info->vsync_len;
+ da8xx_fb_var.right_margin = lcd_panel_info->left_margin;
+ da8xx_fb_var.left_margin = lcd_panel_info->right_margin;
+ da8xx_fb_var.lower_margin = lcd_panel_info->upper_margin;
+ da8xx_fb_var.upper_margin = lcd_panel_info->lower_margin;
da8xx_fb_var.pixclock = da8xxfb_pixel_clk_period(par);
/* Initialize fbinfo */
diff --git a/include/video/da8xx-fb.h b/include/video/da8xx-fb.h
index 5a0e4f9..a6796ff 100644
--- a/include/video/da8xx-fb.h
+++ b/include/video/da8xx-fb.h
@@ -12,6 +12,8 @@
#ifndef DA8XX_FB_H
#define DA8XX_FB_H
+#include <linux/fb.h>
+
enum panel_type {
QVGA = 0
};
@@ -35,10 +37,9 @@ struct display_panel {
};
struct da8xx_lcdc_platform_data {
- const char manu_name[10];
void *controller_data;
- const char type[25];
void (*panel_power_ctrl)(int);
+ struct fb_videomode fb_videomode;
};
struct lcd_ctrl_config {
@@ -103,5 +104,8 @@ struct lcd_sync_arg {
#define FBIPUT_HSYNC _IOW('F', 9, int)
#define FBIPUT_VSYNC _IOW('F', 10, int)
+/* Proprietary FB_SYNC_ flags */
+#define FB_SYNC_CLK_INVERT 0x40000000
+
#endif /* ifndef DA8XX_FB_H */
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] da8xx-fb: cleanup LCDC configurations
From: Manjunathappa, Prakash @ 2012-10-05 14:03 UTC (permalink / raw)
To: linux-fbdev
Configure below LCDC configurations to optimal values, also have an
option configure these optional parameters for platform.
1) AC bias configuration: Required only for passive panels
2) Dma_burst_size:
3) FIFO_DMA_DELAY:
4) FIFO threshold: Does not apply for da830 LCDC.
Patch is verified for 16bpp and 24bpp configurations on da830, da850 and am335x
EVMs.
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
---
arch/arm/mach-davinci/devices-da8xx.c | 27 +++--------------------
drivers/video/da8xx-fb.c | 37 +++++++++++---------------------
include/video/da8xx-fb.h | 22 +------------------
3 files changed, 18 insertions(+), 68 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 12a47cd..eb0a1ec 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -524,29 +524,9 @@ void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata)
}
}
-static const struct display_panel disp_panel = {
- QVGA,
- 16,
- 16,
- COLOR_ACTIVE,
-};
-
static struct lcd_ctrl_config lcd_cfg = {
- &disp_panel,
- .ac_bias = 255,
- .ac_bias_intrpt = 0,
- .dma_burst_sz = 16,
+ .panel_shade = COLOR_ACTIVE,
.bpp = 16,
- .fdd = 255,
- .tft_alt_mode = 0,
- .stn_565_mode = 0,
- .mono_8bit_mode = 0,
- .invert_line_clock = 1,
- .invert_frm_clock = 1,
- .sync_edge = 0,
- .sync_ctrl = 1,
- .raster_order = 0,
- .fifo_th = 6,
};
struct da8xx_lcdc_platform_data sharp_lcd035q3dg01_pdata = {
@@ -562,7 +542,8 @@ struct da8xx_lcdc_platform_data sharp_lcd035q3dg01_pdata = {
.lower_margin = 2,
.hsync_len = 0,
.vsync_len = 0,
- .sync = FB_SYNC_CLK_INVERT,
+ .sync = FB_SYNC_CLK_INVERT |
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
.flag = 0,
},
};
@@ -580,7 +561,7 @@ struct da8xx_lcdc_platform_data sharp_lk043t1dg01_pdata = {
.lower_margin = 2,
.hsync_len = 41,
.vsync_len = 10,
- .sync = 0,
+ .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
.flag = 0,
},
};
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index bacf82b..36af88b 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -339,10 +339,9 @@ static int lcd_cfg_dma(int burst_size, int fifo_th)
reg |= LCD_DMA_BURST_SIZE(LCD_DMA_BURST_8);
break;
case 16:
+ default: /* Configuring for highest burst */
reg |= LCD_DMA_BURST_SIZE(LCD_DMA_BURST_16);
break;
- default:
- return -EINVAL;
}
reg |= (fifo_th << 8);
@@ -387,7 +386,8 @@ static void lcd_cfg_vertical_sync(int back_porch, int pulse_width,
lcdc_write(reg, LCD_RASTER_TIMING_1_REG);
}
-static int lcd_cfg_display(const struct lcd_ctrl_config *cfg)
+static int lcd_cfg_display(const struct lcd_ctrl_config *cfg,
+ struct fb_videomode *panel)
{
u32 reg;
u32 reg_int;
@@ -396,7 +396,7 @@ static int lcd_cfg_display(const struct lcd_ctrl_config *cfg)
LCD_MONO_8BIT_MODE |
LCD_MONOCHROME_MODE);
- switch (cfg->p_disp_panel->panel_shade) {
+ switch (cfg->panel_shade) {
case MONOCHROME:
reg |= LCD_MONOCHROME_MODE;
if (cfg->mono_8bit_mode)
@@ -409,7 +409,9 @@ static int lcd_cfg_display(const struct lcd_ctrl_config *cfg)
break;
case COLOR_PASSIVE:
- if (cfg->stn_565_mode)
+ /* AC bias applicable only for Pasive panels */
+ lcd_cfg_ac_bias(cfg->ac_bias, cfg->ac_bias_intrpt);
+ if (cfg->bpp = 12 && cfg->stn_565_mode)
reg |= LCD_STN_565_ENABLE;
break;
@@ -430,22 +432,19 @@ static int lcd_cfg_display(const struct lcd_ctrl_config *cfg)
reg = lcdc_read(LCD_RASTER_TIMING_2_REG);
- if (cfg->sync_ctrl)
- reg |= LCD_SYNC_CTRL;
- else
- reg &= ~LCD_SYNC_CTRL;
+ reg |= LCD_SYNC_CTRL;
if (cfg->sync_edge)
reg |= LCD_SYNC_EDGE;
else
reg &= ~LCD_SYNC_EDGE;
- if (cfg->invert_line_clock)
+ if (panel->sync & FB_SYNC_HOR_HIGH_ACT)
reg |= LCD_INVERT_LINE_CLOCK;
else
reg &= ~LCD_INVERT_LINE_CLOCK;
- if (cfg->invert_frm_clock)
+ if (panel->sync & FB_SYNC_VERT_HIGH_ACT)
reg |= LCD_INVERT_FRAME_CLOCK;
else
reg &= ~LCD_INVERT_FRAME_CLOCK;
@@ -690,9 +689,6 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
if (ret < 0)
return ret;
- /* Configure the AC bias properties. */
- lcd_cfg_ac_bias(cfg->ac_bias, cfg->ac_bias_intrpt);
-
/* Configure the vertical and horizontal sync properties. */
lcd_cfg_vertical_sync(panel->lower_margin, panel->vsync_len,
panel->upper_margin);
@@ -700,18 +696,12 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
panel->left_margin);
/* Configure for disply */
- ret = lcd_cfg_display(cfg);
+ ret = lcd_cfg_display(cfg, panel);
if (ret < 0)
return ret;
- if (QVGA != cfg->p_disp_panel->panel_type)
- return -EINVAL;
+ bpp = cfg->bpp;
- if (cfg->bpp <= cfg->p_disp_panel->max_bpp &&
- cfg->bpp >= cfg->p_disp_panel->min_bpp)
- bpp = cfg->bpp;
- else
- bpp = cfg->p_disp_panel->max_bpp;
if (bpp = 12)
bpp = 16;
ret = lcd_cfg_frame_buffer(par, (unsigned int)panel->xres,
@@ -1323,8 +1313,7 @@ static int __devinit fb_probe(struct platform_device *device)
da8xx_fb_var.yres = lcd_panel_info->yres;
da8xx_fb_var.yres_virtual = lcd_panel_info->yres * LCD_NUM_BUFFERS;
- da8xx_fb_var.grayscale - lcd_cfg->p_disp_panel->panel_shade = MONOCHROME ? 1 : 0;
+ da8xx_fb_var.grayscale = lcd_cfg->panel_shade = MONOCHROME ? 1 : 0;
da8xx_fb_var.bits_per_pixel = lcd_cfg->bpp;
da8xx_fb_var.hsync_len = lcd_panel_info->hsync_len;
diff --git a/include/video/da8xx-fb.h b/include/video/da8xx-fb.h
index a6796ff..3eada34 100644
--- a/include/video/da8xx-fb.h
+++ b/include/video/da8xx-fb.h
@@ -14,10 +14,6 @@
#include <linux/fb.h>
-enum panel_type {
- QVGA = 0
-};
-
enum panel_shade {
MONOCHROME = 0,
COLOR_ACTIVE,
@@ -29,13 +25,6 @@ enum raster_load_mode {
LOAD_PALETTE,
};
-struct display_panel {
- enum panel_type panel_type; /* QVGA */
- int max_bpp;
- int min_bpp;
- enum panel_shade panel_shade;
-};
-
struct da8xx_lcdc_platform_data {
void *controller_data;
void (*panel_power_ctrl)(int);
@@ -43,7 +32,7 @@ struct da8xx_lcdc_platform_data {
};
struct lcd_ctrl_config {
- const struct display_panel *p_disp_panel;
+ enum panel_shade panel_shade;
/* AC Bias Pin Frequency */
int ac_bias;
@@ -69,18 +58,9 @@ struct lcd_ctrl_config {
/* Mono 8-bit Mode: 1Ð-D7 or 0Ð-D3 */
unsigned char mono_8bit_mode;
- /* Invert line clock */
- unsigned char invert_line_clock;
-
- /* Invert frame clock */
- unsigned char invert_frm_clock;
-
/* Horizontal and Vertical Sync Edge: 0=rising 1úlling */
unsigned char sync_edge;
- /* Horizontal and Vertical Sync: Control: 0=ignore */
- unsigned char sync_ctrl;
-
/* Raster Data Order Select: 1=Most-to-least 0=Least-to-most */
unsigned char raster_order;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 12/16] video: mark nuc900fb_map_video_memory as __devinit
From: Arnd Bergmann @ 2012-10-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349448930-23976-1-git-send-email-arnd@arndb.de>
nuc900fb_map_video_memory is called by an devinit function
that may be called at run-time, but the function itself is
marked __init and will be discarded after boot.
To avoid calling into a function that may have been overwritten,
mark nuc900fb_map_video_memory itself as __devinit.
Without this patch, building nuc950_defconfig results in:
WARNING: drivers/video/built-in.o(.devinit.text+0x26c): Section mismatch in reference from the function nuc900fb_probe() to the function .init.text:nuc900fb_map_video_memory()
The function __devinit nuc900fb_probe() references
a function __init nuc900fb_map_video_memory().
If nuc900fb_map_video_memory is only used by nuc900fb_probe then
annotate nuc900fb_map_video_memory with a matching annotation.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Wan ZongShun <mcuos.com@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/nuc900fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
index e10f551..b31b12b 100644
--- a/drivers/video/nuc900fb.c
+++ b/drivers/video/nuc900fb.c
@@ -387,7 +387,7 @@ static int nuc900fb_init_registers(struct fb_info *info)
* The buffer should be a non-cached, non-buffered, memory region
* to allow palette and pixel writes without flushing the cache.
*/
-static int __init nuc900fb_map_video_memory(struct fb_info *info)
+static int __devinit nuc900fb_map_video_memory(struct fb_info *info)
{
struct nuc900fb_info *fbi = info->par;
dma_addr_t map_dma;
--
1.7.10
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox