* [PATCH 2/2] OMAPDSS: DPI: widen the pck search when using dss fck
From: Tomi Valkeinen @ 2013-04-11 9:35 UTC (permalink / raw)
To: linux-omap, linux-fbdev, Archit Taneja; +Cc: Tomi Valkeinen
In-Reply-To: <1365672662-612-1-git-send-email-tomi.valkeinen@ti.com>
When not using DSI PLL to generate the pixel clock, but DSS FCK, the
possible pixel clock rates are rather limited. DSS FCK is currently used
on OMAP2 and OMAP3.
When using Beagleboard with a monitor that supports high resolutions,
the clock rates do not match (at least for me) for the monitor's pixel
clocks within the current threshold in the code, which is +/- 1MHz.
This patch widens the search up to +/- 15MHz. The search is done in
steps, i.e. it first tries to find a rather exact clock, than a bit less
exact, etc. so this should not change the cases where a clock was
already found.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dpi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index abe1a4e2..e93c4de 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -222,10 +222,10 @@ static bool dpi_dss_clk_calc(unsigned long pck, struct dpi_clk_calc_ctx *ctx)
* DSS fck gives us very few possibilities, so finding a good pixel
* clock may not be possible. We try multiple times to find the clock,
* each time widening the pixel clock range we look for, up to
- * +/- 1MHz.
+ * +/- ~15MHz.
*/
- for (i = 0; i < 10; ++i) {
+ for (i = 0; i < 25; ++i) {
bool ok;
memset(ctx, 0, sizeof(*ctx));
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] OMAPDSS: fix dss_fck clock rate rounding
From: Tomi Valkeinen @ 2013-04-11 9:31 UTC (permalink / raw)
To: linux-omap, linux-fbdev, Archit Taneja; +Cc: Tomi Valkeinen
DSS func clock is calculated with prate / div * m. However, the current
omapdss code calculates it with prate * m / div, which yields a slightly
different result when there's a remainder. For example, 432000000 / 14 *
2 = 61714284, but 432000000 * 2 / 14 = 61714285.
In addition to that, the clock framework wants the clock rate given with
clk_set_rate to be higher than the actual (truncated) end result. So, if
prate is 432000000, and div is 14, the real result is 30857142.8571...
We need to call clk_set_rate with 30857143, which gives us a clock of
30857142. That's why we need to use DIV_ROUND_UP() when calling
clk_set_rate.
This patch fixes the clock calculation.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dss.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index fdd32e8..b9f6f24 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -480,6 +480,7 @@ bool dss_div_calc(unsigned long fck_min, dss_div_calc_func func, void *data)
unsigned long fck_hw_max;
unsigned long fckd_hw_max;
unsigned long prate;
+ unsigned m;
if (dss.dpll4_m4_ck = NULL) {
/*
@@ -495,15 +496,16 @@ bool dss_div_calc(unsigned long fck_min, dss_div_calc_func func, void *data)
fck_hw_max = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
fckd_hw_max = dss.feat->fck_div_max;
- prate = dss_get_dpll4_rate() * dss.feat->dss_fck_multiplier;
+ m = dss.feat->dss_fck_multiplier;
+ prate = dss_get_dpll4_rate();
fck_min = fck_min ? fck_min : 1;
- fckd_start = min(prate / fck_min, fckd_hw_max);
- fckd_stop = max(DIV_ROUND_UP(prate, fck_hw_max), 1ul);
+ fckd_start = min(prate * m / fck_min, fckd_hw_max);
+ fckd_stop = max(DIV_ROUND_UP(prate * m, fck_hw_max), 1ul);
for (fckd = fckd_start; fckd >= fckd_stop; --fckd) {
- fck = prate / fckd;
+ fck = prate / fckd * m;
if (func(fckd, fck, data))
return true;
@@ -521,7 +523,8 @@ int dss_set_clock_div(struct dss_clock_info *cinfo)
prate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
DSSDBG("dpll4_m4 = %ld\n", prate);
- r = clk_set_rate(dss.dpll4_m4_ck, prate / cinfo->fck_div);
+ r = clk_set_rate(dss.dpll4_m4_ck,
+ DIV_ROUND_UP(prate, cinfo->fck_div));
if (r)
return r;
} else {
@@ -531,7 +534,9 @@ int dss_set_clock_div(struct dss_clock_info *cinfo)
dss.dss_clk_rate = clk_get_rate(dss.dss_clk);
- WARN_ONCE(dss.dss_clk_rate != cinfo->fck, "clk rate mismatch");
+ WARN_ONCE(dss.dss_clk_rate != cinfo->fck,
+ "clk rate mismatch: %lu != %lu", dss.dss_clk_rate,
+ cinfo->fck);
DSSDBG("fck = %ld (%d)\n", cinfo->fck, cinfo->fck_div);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 13/30] video/s3c: move platform_data out of arch/arm
From: Jingoo Han @ 2013-04-11 5:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1365638712-1028578-14-git-send-email-arnd@arndb.de>
On Thursday, April 11, 2013 9:05 AM, Arnd Bergmann wrote:
>
> The s3c-fb driver requires header files from the samsung platforms
> to find its platform_data definition, but this no longer works on
> multiplatform kernels, so let's move the data into a new header
> file under include/linux/platform_data.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-fbdev@vger.kernel.org
> Cc: Jingoo Han <jg1.han@samsung.com>
> ---
> arch/arm/plat-samsung/include/plat/fb.h | 50 +-----------------------------
> drivers/video/s3c-fb.c | 3 +-
> include/linux/platform_data/video_s3c.h | 54 +++++++++++++++++++++++++++++++++
> 3 files changed, 56 insertions(+), 51 deletions(-)
> create mode 100644 include/linux/platform_data/video_s3c.h
>
[.....]
> +struct s3c_fb_platdata {
> + void (*setup_gpio)(void);
> +
> + struct s3c_fb_pd_win *win[S3C_FB_MAX_WIN];
> + struct fb_videomode *vtiming;
> +
> + u32 vidcon0;
> + u32 vidcon1;
> +};
> +
There is an unnecessary space.
When the patch is merged, this space should be removed.
Best regards,
Jingoo Han
> +#endif
> --
> 1.8.1.2
^ permalink raw reply
* Re: [PATCH 12/30] video/exynos: remove unnecessary header inclusions
From: Jingoo Han @ 2013-04-11 5:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1365638712-1028578-13-git-send-email-arnd@arndb.de>
On Thursday, April 11, 2013 9:05 AM, Arnd Bergmann wrote:
>
> In multiplatform configurations, we cannot include headers
> provided by only the exynos platform. Fortunately a number
> of drivers that include those headers do not actually need
> them, so we can just remove the inclusions.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-fbdev@vger.kernel.org
> Cc: Jingoo Han <jg1.han@samsung.com>
CC'ed Tomi Valkeinen, Inki Dae, Donghwa Lee, Kyungmin Park
Acked-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
> ---
> drivers/video/exynos/exynos_mipi_dsi.c | 2 --
> drivers/video/exynos/exynos_mipi_dsi_common.c | 2 --
> drivers/video/exynos/exynos_mipi_dsi_lowlevel.c | 2 --
> 3 files changed, 6 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
> index fac7df6..3dd43ca 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -35,8 +35,6 @@
>
> #include <video/exynos_mipi_dsim.h>
>
> -#include <plat/fb.h>
> -
> #include "exynos_mipi_dsi_common.h"
> #include "exynos_mipi_dsi_lowlevel.h"
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi_common.c
> b/drivers/video/exynos/exynos_mipi_dsi_common.c
> index c70cb89..520fc9b 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi_common.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi_common.c
> @@ -31,8 +31,6 @@
> #include <video/mipi_display.h>
> #include <video/exynos_mipi_dsim.h>
>
> -#include <mach/map.h>
> -
> #include "exynos_mipi_dsi_regs.h"
> #include "exynos_mipi_dsi_lowlevel.h"
> #include "exynos_mipi_dsi_common.h"
> diff --git a/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
> b/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
> index 95cb99a..15c5abd 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
> @@ -26,8 +26,6 @@
>
> #include <video/exynos_mipi_dsim.h>
>
> -#include <mach/map.h>
> -
> #include "exynos_mipi_dsi_regs.h"
>
> void exynos_mipi_dsi_func_reset(struct mipi_dsim_device *dsim)
> --
> 1.8.1.2
^ permalink raw reply
* Re: [PATCH 13/30] video/s3c: move platform_data out of arch/arm
From: Jingoo Han @ 2013-04-11 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1365638712-1028578-14-git-send-email-arnd@arndb.de>
On Thursday, April 11, 2013 9:05 AM, Arnd Bergmann wrote:
>
> The s3c-fb driver requires header files from the samsung platforms
> to find its platform_data definition, but this no longer works on
> multiplatform kernels, so let's move the data into a new header
> file under include/linux/platform_data.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-fbdev@vger.kernel.org
> Cc: Jingoo Han <jg1.han@samsung.com>
CC'ed Tomi Valkeinen.
Hi Arnd,
It looks good. Thank you for your patch. :)
Acked-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
> ---
> arch/arm/plat-samsung/include/plat/fb.h | 50 +-----------------------------
> drivers/video/s3c-fb.c | 3 +-
> include/linux/platform_data/video_s3c.h | 54 +++++++++++++++++++++++++++++++++
> 3 files changed, 56 insertions(+), 51 deletions(-)
> create mode 100644 include/linux/platform_data/video_s3c.h
>
> diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
> index b885322..9ae5072 100644
> --- a/arch/arm/plat-samsung/include/plat/fb.h
> +++ b/arch/arm/plat-samsung/include/plat/fb.h
> @@ -15,55 +15,7 @@
> #ifndef __PLAT_S3C_FB_H
> #define __PLAT_S3C_FB_H __FILE__
>
> -/* S3C_FB_MAX_WIN
> - * Set to the maximum number of windows that any of the supported hardware
> - * can use. Since the platform data uses this for an array size, having it
> - * set to the maximum of any version of the hardware can do is safe.
> - */
> -#define S3C_FB_MAX_WIN (5)
> -
> -/**
> - * struct s3c_fb_pd_win - per window setup data
> - * @xres : The window X size.
> - * @yres : The window Y size.
> - * @virtual_x: The virtual X size.
> - * @virtual_y: The virtual Y size.
> - */
> -struct s3c_fb_pd_win {
> - unsigned short default_bpp;
> - unsigned short max_bpp;
> - unsigned short xres;
> - unsigned short yres;
> - unsigned short virtual_x;
> - unsigned short virtual_y;
> -};
> -
> -/**
> - * struct s3c_fb_platdata - S3C driver platform specific information
> - * @setup_gpio: Setup the external GPIO pins to the right state to transfer
> - * the data from the display system to the connected display
> - * device.
> - * @vidcon0: The base vidcon0 values to control the panel data format.
> - * @vidcon1: The base vidcon1 values to control the panel data output.
> - * @vtiming: Video timing when connected to a RGB type panel.
> - * @win: The setup data for each hardware window, or NULL for unused.
> - * @display_mode: The LCD output display mode.
> - *
> - * The platform data supplies the video driver with all the information
> - * it requires to work with the display(s) attached to the machine. It
> - * controls the initial mode, the number of display windows (0 is always
> - * the base framebuffer) that are initialised etc.
> - *
> - */
> -struct s3c_fb_platdata {
> - void (*setup_gpio)(void);
> -
> - struct s3c_fb_pd_win *win[S3C_FB_MAX_WIN];
> - struct fb_videomode *vtiming;
> -
> - u32 vidcon0;
> - u32 vidcon1;
> -};
> +#include <linux/platform_data/video_s3c.h>
>
> /**
> * s3c_fb_set_platdata() - Setup the FB device with platform data.
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 968a625..2e7991c 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -24,10 +24,9 @@
> #include <linux/uaccess.h>
> #include <linux/interrupt.h>
> #include <linux/pm_runtime.h>
> +#include <linux/platform_data/video_s3c.h>
>
> #include <video/samsung_fimd.h>
> -#include <mach/map.h>
> -#include <plat/fb.h>
>
> /* This driver will export a number of framebuffer interfaces depending
> * on the configuration passed in via the platform data. Each fb instance
> diff --git a/include/linux/platform_data/video_s3c.h b/include/linux/platform_data/video_s3c.h
> new file mode 100644
> index 0000000..fa40f96
> --- /dev/null
> +++ b/include/linux/platform_data/video_s3c.h
> @@ -0,0 +1,54 @@
> +#ifndef __PLATFORM_DATA_VIDEO_S3C
> +#define __PLATFORM_DATA_VIDEO_S3C
> +
> +/* S3C_FB_MAX_WIN
> + * Set to the maximum number of windows that any of the supported hardware
> + * can use. Since the platform data uses this for an array size, having it
> + * set to the maximum of any version of the hardware can do is safe.
> + */
> +#define S3C_FB_MAX_WIN (5)
> +
> +/**
> + * struct s3c_fb_pd_win - per window setup data
> + * @xres : The window X size.
> + * @yres : The window Y size.
> + * @virtual_x: The virtual X size.
> + * @virtual_y: The virtual Y size.
> + */
> +struct s3c_fb_pd_win {
> + unsigned short default_bpp;
> + unsigned short max_bpp;
> + unsigned short xres;
> + unsigned short yres;
> + unsigned short virtual_x;
> + unsigned short virtual_y;
> +};
> +
> +/**
> + * struct s3c_fb_platdata - S3C driver platform specific information
> + * @setup_gpio: Setup the external GPIO pins to the right state to transfer
> + * the data from the display system to the connected display
> + * device.
> + * @vidcon0: The base vidcon0 values to control the panel data format.
> + * @vidcon1: The base vidcon1 values to control the panel data output.
> + * @vtiming: Video timing when connected to a RGB type panel.
> + * @win: The setup data for each hardware window, or NULL for unused.
> + * @display_mode: The LCD output display mode.
> + *
> + * The platform data supplies the video driver with all the information
> + * it requires to work with the display(s) attached to the machine. It
> + * controls the initial mode, the number of display windows (0 is always
> + * the base framebuffer) that are initialised etc.
> + *
> + */
> +struct s3c_fb_platdata {
> + void (*setup_gpio)(void);
> +
> + struct s3c_fb_pd_win *win[S3C_FB_MAX_WIN];
> + struct fb_videomode *vtiming;
> +
> + u32 vidcon0;
> + u32 vidcon1;
> +};
> +
> +#endif
> --
> 1.8.1.2
^ permalink raw reply
* [PATCH 13/30] video/s3c: move platform_data out of arch/arm
From: Arnd Bergmann @ 2013-04-11 0:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
The s3c-fb driver requires header files from the samsung platforms
to find its platform_data definition, but this no longer works on
multiplatform kernels, so let's move the data into a new header
file under include/linux/platform_data.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-fbdev@vger.kernel.org
Cc: Jingoo Han <jg1.han@samsung.com>
---
arch/arm/plat-samsung/include/plat/fb.h | 50 +-----------------------------
drivers/video/s3c-fb.c | 3 +-
include/linux/platform_data/video_s3c.h | 54 +++++++++++++++++++++++++++++++++
3 files changed, 56 insertions(+), 51 deletions(-)
create mode 100644 include/linux/platform_data/video_s3c.h
diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
index b885322..9ae5072 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -15,55 +15,7 @@
#ifndef __PLAT_S3C_FB_H
#define __PLAT_S3C_FB_H __FILE__
-/* S3C_FB_MAX_WIN
- * Set to the maximum number of windows that any of the supported hardware
- * can use. Since the platform data uses this for an array size, having it
- * set to the maximum of any version of the hardware can do is safe.
- */
-#define S3C_FB_MAX_WIN (5)
-
-/**
- * struct s3c_fb_pd_win - per window setup data
- * @xres : The window X size.
- * @yres : The window Y size.
- * @virtual_x: The virtual X size.
- * @virtual_y: The virtual Y size.
- */
-struct s3c_fb_pd_win {
- unsigned short default_bpp;
- unsigned short max_bpp;
- unsigned short xres;
- unsigned short yres;
- unsigned short virtual_x;
- unsigned short virtual_y;
-};
-
-/**
- * struct s3c_fb_platdata - S3C driver platform specific information
- * @setup_gpio: Setup the external GPIO pins to the right state to transfer
- * the data from the display system to the connected display
- * device.
- * @vidcon0: The base vidcon0 values to control the panel data format.
- * @vidcon1: The base vidcon1 values to control the panel data output.
- * @vtiming: Video timing when connected to a RGB type panel.
- * @win: The setup data for each hardware window, or NULL for unused.
- * @display_mode: The LCD output display mode.
- *
- * The platform data supplies the video driver with all the information
- * it requires to work with the display(s) attached to the machine. It
- * controls the initial mode, the number of display windows (0 is always
- * the base framebuffer) that are initialised etc.
- *
- */
-struct s3c_fb_platdata {
- void (*setup_gpio)(void);
-
- struct s3c_fb_pd_win *win[S3C_FB_MAX_WIN];
- struct fb_videomode *vtiming;
-
- u32 vidcon0;
- u32 vidcon1;
-};
+#include <linux/platform_data/video_s3c.h>
/**
* s3c_fb_set_platdata() - Setup the FB device with platform data.
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 968a625..2e7991c 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -24,10 +24,9 @@
#include <linux/uaccess.h>
#include <linux/interrupt.h>
#include <linux/pm_runtime.h>
+#include <linux/platform_data/video_s3c.h>
#include <video/samsung_fimd.h>
-#include <mach/map.h>
-#include <plat/fb.h>
/* This driver will export a number of framebuffer interfaces depending
* on the configuration passed in via the platform data. Each fb instance
diff --git a/include/linux/platform_data/video_s3c.h b/include/linux/platform_data/video_s3c.h
new file mode 100644
index 0000000..fa40f96
--- /dev/null
+++ b/include/linux/platform_data/video_s3c.h
@@ -0,0 +1,54 @@
+#ifndef __PLATFORM_DATA_VIDEO_S3C
+#define __PLATFORM_DATA_VIDEO_S3C
+
+/* S3C_FB_MAX_WIN
+ * Set to the maximum number of windows that any of the supported hardware
+ * can use. Since the platform data uses this for an array size, having it
+ * set to the maximum of any version of the hardware can do is safe.
+ */
+#define S3C_FB_MAX_WIN (5)
+
+/**
+ * struct s3c_fb_pd_win - per window setup data
+ * @xres : The window X size.
+ * @yres : The window Y size.
+ * @virtual_x: The virtual X size.
+ * @virtual_y: The virtual Y size.
+ */
+struct s3c_fb_pd_win {
+ unsigned short default_bpp;
+ unsigned short max_bpp;
+ unsigned short xres;
+ unsigned short yres;
+ unsigned short virtual_x;
+ unsigned short virtual_y;
+};
+
+/**
+ * struct s3c_fb_platdata - S3C driver platform specific information
+ * @setup_gpio: Setup the external GPIO pins to the right state to transfer
+ * the data from the display system to the connected display
+ * device.
+ * @vidcon0: The base vidcon0 values to control the panel data format.
+ * @vidcon1: The base vidcon1 values to control the panel data output.
+ * @vtiming: Video timing when connected to a RGB type panel.
+ * @win: The setup data for each hardware window, or NULL for unused.
+ * @display_mode: The LCD output display mode.
+ *
+ * The platform data supplies the video driver with all the information
+ * it requires to work with the display(s) attached to the machine. It
+ * controls the initial mode, the number of display windows (0 is always
+ * the base framebuffer) that are initialised etc.
+ *
+ */
+struct s3c_fb_platdata {
+ void (*setup_gpio)(void);
+
+ struct s3c_fb_pd_win *win[S3C_FB_MAX_WIN];
+ struct fb_videomode *vtiming;
+
+ u32 vidcon0;
+ u32 vidcon1;
+};
+
+#endif
--
1.8.1.2
^ permalink raw reply related
* [PATCH 12/30] video/exynos: remove unnecessary header inclusions
From: Arnd Bergmann @ 2013-04-11 0:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
In multiplatform configurations, we cannot include headers
provided by only the exynos platform. Fortunately a number
of drivers that include those headers do not actually need
them, so we can just remove the inclusions.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-fbdev@vger.kernel.org
Cc: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/exynos/exynos_mipi_dsi.c | 2 --
drivers/video/exynos/exynos_mipi_dsi_common.c | 2 --
drivers/video/exynos/exynos_mipi_dsi_lowlevel.c | 2 --
3 files changed, 6 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index fac7df6..3dd43ca 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -35,8 +35,6 @@
#include <video/exynos_mipi_dsim.h>
-#include <plat/fb.h>
-
#include "exynos_mipi_dsi_common.h"
#include "exynos_mipi_dsi_lowlevel.h"
diff --git a/drivers/video/exynos/exynos_mipi_dsi_common.c b/drivers/video/exynos/exynos_mipi_dsi_common.c
index c70cb89..520fc9b 100644
--- a/drivers/video/exynos/exynos_mipi_dsi_common.c
+++ b/drivers/video/exynos/exynos_mipi_dsi_common.c
@@ -31,8 +31,6 @@
#include <video/mipi_display.h>
#include <video/exynos_mipi_dsim.h>
-#include <mach/map.h>
-
#include "exynos_mipi_dsi_regs.h"
#include "exynos_mipi_dsi_lowlevel.h"
#include "exynos_mipi_dsi_common.h"
diff --git a/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c b/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
index 95cb99a..15c5abd 100644
--- a/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
+++ b/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
@@ -26,8 +26,6 @@
#include <video/exynos_mipi_dsim.h>
-#include <mach/map.h>
-
#include "exynos_mipi_dsi_regs.h"
void exynos_mipi_dsi_func_reset(struct mipi_dsim_device *dsim)
--
1.8.1.2
^ permalink raw reply related
* [PATCH 00/30] ARM: exynos multiplatform support
From: Arnd Bergmann @ 2013-04-11 0:04 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Kukjin Kim, linux-samsung-soc, Arnd Bergmann, stern,
a.zummo, ben-linux, cjb, dwmw2, grant.likely, gregkh, jg1.han,
john.stultz, broonie, mchehab, mturquette, padma.kvr,
thierry.reding, tglx, t.figa, wsa, rui.zhang, alsa-devel,
linux-fbdev, linux-i2c, linux-media, linux-mmc, linux-mtd,
linux-pm, linux-serial, linux-usb, rtc-linux, spi-devel-general
Hi everyone,
I have updated my series for multiplatform support of the ARM exynos
platform, based on what is currently queued up in arm-soc.
It would be really nice to still get this merged for 3.10. A lot of
the patches are really trivial, but there are some complex ones
as well.
To all subsystem maintainers: feel free to directly apply the patches
for your subsystem, there should be no dependencies between any of them,
aside from the last patch requiring all of the earlier ones to be applied
first. Getting an Ack is also fine so we can put the patches into arm-soc.
Arnd
Arnd Bergmann (30):
ARM: exynos: introduce EXYNOS_ATAGS symbol
ARM: exynos: prepare for sparse IRQ
ARM: exynos: move debug-macro.S to include/debug/
ARM: samsung: move mfc device definition to s5p-dev-mfc.c
tty: serial/samsung: prepare for common clock API
tty: serial/samsung: make register definitions global
tty: serial/samsung: fix modular build
i2c: s3c2410: make header file local
mmc: sdhci-s3c: remove platform dependencies
usb: exynos: do not include plat/usb-phy.h
[media] exynos: remove unnecessary header inclusions
video/exynos: remove unnecessary header inclusions
video/s3c: move platform_data out of arch/arm
thermal/exynos: remove unnecessary header inclusions
mtd: onenand/samsung: make regs-onenand.h file local
rtc: s3c: make header file local
pwm: samsung: repair the worst MMIO abuses
ASoC: samsung: move plat/ headers to local directory
ASoC: samsung: use irq resource for idma
ASoC: samsung: convert to dmaengine API
ASoC: samsung/i2s: fix module_device_table
ASoC: samsung/idma: export idma_reg_addr_init
clk: exynos: prepare for multiplatform
clocksource: exynos_mct: remove platform header dependency
irqchip: exynos: pass max combiner number to combiner_init
irqchip: exynos: allocate combiner_data dynamically
irqchip: exynos: localize irq lookup for ATAGS
irqchip: exynos: pass irq_base from platform
spi: s3c64xx: move to generic dmaengine API
ARM: exynos: enable multiplatform support
arch/arm/Kconfig | 10 +-
arch/arm/Kconfig.debug | 8 +
arch/arm/configs/exynos4_defconfig | 2 +-
.../mach/debug-macro.S => include/debug/exynos.S} | 12 +-
.../plat/debug-macro.S => include/debug/samsung.S} | 2 +-
arch/arm/mach-exynos/Kconfig | 40 ++-
arch/arm/mach-exynos/Makefile | 5 +-
arch/arm/mach-exynos/common.c | 26 +-
arch/arm/mach-exynos/common.h | 7 +-
arch/arm/mach-exynos/dev-uart.c | 1 +
arch/arm/mach-exynos/include/mach/irqs.h | 5 +-
arch/arm/mach-exynos/mach-armlex4210.c | 2 +
arch/arm/mach-exynos/mach-exynos4-dt.c | 3 +
arch/arm/mach-exynos/mach-exynos5-dt.c | 2 +
arch/arm/mach-exynos/mach-nuri.c | 2 +
arch/arm/mach-exynos/mach-origen.c | 2 +
arch/arm/mach-exynos/mach-smdk4x12.c | 2 +
arch/arm/mach-exynos/mach-smdkv310.c | 3 +
arch/arm/mach-exynos/setup-sdhci-gpio.c | 2 +-
arch/arm/mach-exynos/setup-usb-phy.c | 8 +-
arch/arm/mach-s3c24xx/clock-s3c2440.c | 5 +
arch/arm/mach-s3c24xx/common.c | 5 +
arch/arm/mach-s3c24xx/dma-s3c2410.c | 2 -
arch/arm/mach-s3c24xx/dma-s3c2412.c | 2 -
arch/arm/mach-s3c24xx/dma-s3c2440.c | 2 -
arch/arm/mach-s3c24xx/dma-s3c2443.c | 2 -
arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s3c24xx/mach-rx1950.c | 1 -
arch/arm/mach-s3c64xx/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s3c64xx/setup-usb-phy.c | 4 +-
arch/arm/mach-s5p64x0/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s5pc100/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s5pc100/setup-sdhci-gpio.c | 1 -
arch/arm/mach-s5pv210/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s5pv210/setup-sdhci-gpio.c | 1 -
arch/arm/mach-s5pv210/setup-usb-phy.c | 4 +-
arch/arm/plat-samsung/Kconfig | 7 +-
arch/arm/plat-samsung/Makefile | 8 +-
arch/arm/plat-samsung/devs.c | 62 ++---
arch/arm/plat-samsung/include/plat/fb.h | 50 +---
arch/arm/plat-samsung/include/plat/pm.h | 5 +
arch/arm/plat-samsung/include/plat/regs-serial.h | 282 +--------------------
arch/arm/plat-samsung/include/plat/sdhci.h | 56 +---
arch/arm/plat-samsung/include/plat/usb-phy.h | 5 +-
arch/arm/plat-samsung/irq-vic-timer.c | 1 +
arch/arm/plat-samsung/pm.c | 1 +
arch/arm/plat-samsung/s5p-dev-mfc.c | 42 ++-
arch/arm/plat-samsung/s5p-irq.c | 1 +
drivers/clk/samsung/clk-exynos4.c | 93 +++----
drivers/clk/samsung/clk-exynos5250.c | 1 -
drivers/clk/samsung/clk-exynos5440.c | 1 -
drivers/clk/samsung/clk.h | 2 -
drivers/clocksource/exynos_mct.c | 21 +-
drivers/gpio/Makefile | 2 +-
drivers/i2c/busses/i2c-s3c2410.c | 3 +-
.../regs-iic.h => drivers/i2c/busses/i2c-s3c2410.h | 0
drivers/irqchip/exynos-combiner.c | 116 +++++----
drivers/media/platform/exynos-gsc/gsc-regs.c | 1 -
drivers/media/platform/s5p-tv/sii9234_drv.c | 3 -
drivers/mmc/host/Kconfig | 2 +-
.../mmc/host/sdhci-s3c-regs.h | 0
drivers/mmc/host/sdhci-s3c.c | 5 +-
drivers/mtd/onenand/samsung.c | 4 +-
.../mtd/onenand/samsung.h | 2 -
drivers/pwm/pwm-samsung.c | 60 +++--
drivers/rtc/rtc-s3c.c | 3 +-
.../plat/regs-rtc.h => drivers/rtc/rtc-s3c.h | 3 +-
drivers/spi/spi-s3c64xx.c | 185 ++++++++++----
drivers/thermal/exynos_thermal.c | 2 -
drivers/tty/serial/samsung.c | 17 +-
drivers/tty/serial/samsung.h | 4 +-
drivers/usb/host/ehci-s5p.c | 1 -
drivers/usb/host/ohci-exynos.c | 1 -
drivers/video/exynos/exynos_mipi_dsi.c | 2 -
drivers/video/exynos/exynos_mipi_dsi_common.c | 2 -
drivers/video/exynos/exynos_mipi_dsi_lowlevel.c | 2 -
drivers/video/s3c-fb.c | 3 +-
include/linux/platform_data/mmc-sdhci-s3c.h | 56 ++++
include/linux/platform_data/spi-s3c64xx.h | 3 +
include/linux/platform_data/video_s3c.h | 54 ++++
include/linux/serial_s3c.h | 260 +++++++++++++++++++
sound/soc/samsung/ac97.c | 2 +-
sound/soc/samsung/dma.c | 219 ++++++++++++++++
sound/soc/samsung/dma.h | 15 +-
sound/soc/samsung/h1940_uda1380.c | 2 +-
sound/soc/samsung/i2s.c | 4 +-
sound/soc/samsung/idma.c | 11 +-
sound/soc/samsung/neo1973_wm8753.c | 2 +-
sound/soc/samsung/pcm.c | 1 -
.../include/plat => sound/soc/samsung}/regs-ac97.h | 0
.../include/plat => sound/soc/samsung}/regs-iis.h | 0
sound/soc/samsung/rx1950_uda1380.c | 2 +-
sound/soc/samsung/s3c24xx-i2s.c | 2 +-
sound/soc/samsung/s3c24xx_uda134x.c | 2 +-
sound/soc/samsung/spdif.c | 1 -
95 files changed, 1146 insertions(+), 734 deletions(-)
rename arch/arm/{mach-exynos/include/mach/debug-macro.S => include/debug/exynos.S} (84%)
rename arch/arm/{plat-samsung/include/plat/debug-macro.S => include/debug/samsung.S} (98%)
rename arch/arm/plat-samsung/include/plat/regs-iic.h => drivers/i2c/busses/i2c-s3c2410.h (100%)
rename arch/arm/plat-samsung/include/plat/regs-sdhci.h => drivers/mmc/host/sdhci-s3c-regs.h (100%)
rename arch/arm/plat-samsung/include/plat/regs-onenand.h => drivers/mtd/onenand/samsung.h (98%)
rename arch/arm/plat-samsung/include/plat/regs-rtc.h => drivers/rtc/rtc-s3c.h (97%)
create mode 100644 include/linux/platform_data/mmc-sdhci-s3c.h
create mode 100644 include/linux/platform_data/video_s3c.h
create mode 100644 include/linux/serial_s3c.h
rename {arch/arm/plat-samsung/include/plat => sound/soc/samsung}/regs-ac97.h (100%)
rename {arch/arm/plat-samsung/include/plat => sound/soc/samsung}/regs-iis.h (100%)
--
1.8.1.2
Cc: stern@rowland.harvard.edu
Cc: a.zummo@towertech.it
Cc: ben-linux@fluff.org
Cc: cjb@laptop.org
Cc: dwmw2@infradead.org
Cc: grant.likely@secretlab.ca
Cc: gregkh@linuxfoundation.org
Cc: jg1.han@samsung.com
Cc: john.stultz@linaro.org
Cc: broonie@opensource.wolfsonmicro.com
Cc: mchehab@redhat.com
Cc: mturquette@linaro.org
Cc: padma.kvr@gmail.com
Cc: thierry.reding@avionic-design.de
Cc: tglx@linutronix.de
Cc: t.figa@samsung.com
Cc: wsa@the-dreams.de
Cc: rui.zhang@intel.com
Cc: alsa-devel@alsa-project.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-i2c@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: linux-mmc@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-pm@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: rtc-linux@googlegroups.com
Cc: spi-devel-general@lists.sourceforge.net
.
^ permalink raw reply
* Re: How to manage OMAP display drivers in the future
From: Tomi Valkeinen @ 2013-04-10 10:00 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-fbdev, dri-devel@lists.freedesktop.org
In-Reply-To: <51403F91.7070401@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]
Hi Dave,
On 2013-03-13 10:57, Tomi Valkeinen wrote:
> Hi Dave,
>
> I'm writing this mail to get some ideas how we should manage OMAP's
> display drivers in the future.
>
> As a short intro, we have the following players around:
>
> omapdss - omapdss handles the DSS (display subsystem) hardware. omapdss
> doesn't do any buffer management or expose any userspace API (except a
> few sysfs files), so it doesn't do anything by itself.
> (drivers/video/omap2/dss/)
>
> panel drivers - Drivers for various panel models. The panel drivers use
> omapdss API to manage the video bus. (drivers/video/omap2/displays/)
>
> omapfb - Framebuffer driver, uses omapdss to handle the HW.
> (drivers/video/omap2/omapfb/)
>
> omap_vout - V4L2 driver for showing video, uses omapdss to handle the
> HW. (drivers/media/platform/omap/)
>
> omapdrm - DRM driver, uses omapdss to handle the HW.
> (drivers/gpu/drm/omapdrm/)
>
> omapdss and the panel drivers form the lowest level layer. omapfb and
> omap_vout can be used at the same time, but omapdrm must be used alone,
> without omapfb or omap_vout.
>
> omapfb and omap_vout are not much developed anymore, even though they
> are still commonly used. Most of the development happens in omapdss,
> panel drivers and omapdrm.
>
> So that's what we have now. In the distant future I see omapfb and
> omap_vout disappear totally, the panel drivers would be made generic
> using Common Display Framework, and omapdss and omapdrm would more or
> less be merged together. However, all that is still far away, and we
> need some plan to go forward for now.
>
> Most pressing question is how to get OMAP display patches merged. It
> seems that there's not really an fbdev maintainer for the time being,
> and fbdev tree has been the route for omapdss, panels and omapfb in the
> past. Now that omapdrm is the new main driver for omap display, fbdev
> would be somewhat wrong in any case.
>
> Dave, how would you feel about merging changes to all the above
> components through DRM tree? Merging all the above together would be the
> easiest way, as the changes may have dependencies to each other.
>
> As I said, most of the development should be in omapdss, panels and
> omapdrm. There would be an occasional fix for omapfb and omap_vout, or
> small changes when omapdss changes require changes elsewhere.
Ping. Do you have any thoughts of the above?
We have a few patches for omapdrm for 3.10 that depend on omapdss
patches. I'm currently acting as a fbdev maintainer (well, more like
somebody who collects the fbdev patches that are quite surely ok), so I
can take the problematic omapdrm patches via fbdev tree with the omapdss
patches, if that's ok for you. And send the other omapdrm patches to be
merged via drm tree.
Or, I could take all the omapdrm patches via fbdev tree, if that's
better. There aren't too many of them for 3.10.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH] omapdss: use devm_clk_get()
From: Archit Taneja @ 2013-04-10 9:41 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <516530B1.80203@ti.com>
On Wednesday 10 April 2013 02:58 PM, Archit Taneja wrote:
> On Wednesday 10 April 2013 02:49 PM, Tomi Valkeinen wrote:
>> On 2013-04-10 11:37, Archit Taneja wrote:
>>> On Wednesday 10 April 2013 01:43 PM, Tomi Valkeinen wrote:
>>>> On 2013-04-08 11:55, Archit Taneja wrote:
>>>>> Use devm_clk_get() instead of clk_get() for dss, and for outputs hdmi
>>>>> and venc.
>>>>> This reduces reduces code and simplifies error handling.
>>>>>
>>>>> Signed-off-by: Archit Taneja <archit@ti.com>
>>>>> ---
>>>>> drivers/video/omap2/dss/dss.c | 18 +++---------------
>>>>> drivers/video/omap2/dss/hdmi.c | 16 ++--------------
>>>>> drivers/video/omap2/dss/venc.c | 10 +---------
>>>>> 3 files changed, 6 insertions(+), 38 deletions(-)
>>>>>
>>>>> diff --git a/drivers/video/omap2/dss/dss.c
>>>>> b/drivers/video/omap2/dss/dss.c
>>>>> index 054c2a2..645b3bc 100644
>>>>> --- a/drivers/video/omap2/dss/dss.c
>>>>> +++ b/drivers/video/omap2/dss/dss.c
>>>>> @@ -767,13 +767,11 @@ int dss_dpi_select_source(enum omap_channel
>>>>> channel)
>>>>> static int dss_get_clocks(void)
>>>>> {
>>>>> struct clk *clk;
>>>>> - int r;
>>>>>
>>>>> - clk = clk_get(&dss.pdev->dev, "fck");
>>>>> + clk = devm_clk_get(&dss.pdev->dev, "fck");
>>>>> if (IS_ERR(clk)) {
>>>>> DSSERR("can't get clock fck\n");
>>>>> - r = PTR_ERR(clk);
>>>>> - goto err;
>>>>> + return PTR_ERR(clk);
>>>>> }
>>>>>
>>>>> dss.dss_clk = clk;
>>>>> @@ -782,8 +780,7 @@ static int dss_get_clocks(void)
>>>>> clk = clk_get(NULL, dss.feat->clk_name);
>>>>> if (IS_ERR(clk)) {
>>>>> DSSERR("Failed to get %s\n", dss.feat->clk_name);
>>>>> - r = PTR_ERR(clk);
>>>>> - goto err;
>>>>> + return PTR_ERR(clk);
>>>>> }
>>>>> } else {
>>>>> clk = NULL;
>>>>> @@ -792,21 +789,12 @@ static int dss_get_clocks(void)
>>>>> dss.dpll4_m4_ck = clk;
>>>>>
>>>>> return 0;
>>>>> -
>>>>> -err:
>>>>> - if (dss.dss_clk)
>>>>> - clk_put(dss.dss_clk);
>>>>> - if (dss.dpll4_m4_ck)
>>>>> - clk_put(dss.dpll4_m4_ck);
>>>>> -
>>>>> - return r;
>>>>> }
>>>>
>>>> Why didn't you use devm_clk_get for the dpll4_m4_ck clock also?
>>>
>>> clk_get of dpll4_m4_ck isn't tied to a device:
>>>
>>> clk = clk_get(NULL, dss.feat->clk_name);
>>>
>>> We can't use devm_clk_get() if we don't tie it to a device, right?
>>
>> Ah, true.
>>
>>> I think the dss.dss_clk clock above is same as the dpll4_m4_ck for all
>>> OMAPs. We could probably remove the dpll4_m4_clk all together, and use
>>> dss_clk to get the rate of DSS_FCK coming from PRCM.
>>
>> Hmm, no, if I recall right, dpll4_m4_clk is the parent of dss clock (or
>> parent of the parent of...), and the dss_fck_multiplier affects the
>> resulting dss fck. Or something like that. It's a bit messy, especially
>> as we can't just use the dss fck to change the rate, we need to change
>> the rate at the parent for some reason.
>
> Ah ok, I remember it now. One of the DPLL's divider's output is DSS_FCK.
> We get the parent's rate and iterate through all the possible hsdivider
> values to get the closest pixel clock. We don't/can't change
> dpll4_m4_clk as such, we just need to know it's rate for our calculations.
>
> So yes, we need dpll4_m4_clk, we just need to rename it to a better
> thing. Like dss_clk_parent.
>
> Anyway,
Sorry, hit the send button before completing the message. I wanted to
add that we could push this patch as it is.
Archit
^ permalink raw reply
* Re: [PATCH] omapdss: use devm_clk_get()
From: Archit Taneja @ 2013-04-10 9:40 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <51652EA4.9010606@ti.com>
On Wednesday 10 April 2013 02:49 PM, Tomi Valkeinen wrote:
> On 2013-04-10 11:37, Archit Taneja wrote:
>> On Wednesday 10 April 2013 01:43 PM, Tomi Valkeinen wrote:
>>> On 2013-04-08 11:55, Archit Taneja wrote:
>>>> Use devm_clk_get() instead of clk_get() for dss, and for outputs hdmi
>>>> and venc.
>>>> This reduces reduces code and simplifies error handling.
>>>>
>>>> Signed-off-by: Archit Taneja <archit@ti.com>
>>>> ---
>>>> drivers/video/omap2/dss/dss.c | 18 +++---------------
>>>> drivers/video/omap2/dss/hdmi.c | 16 ++--------------
>>>> drivers/video/omap2/dss/venc.c | 10 +---------
>>>> 3 files changed, 6 insertions(+), 38 deletions(-)
>>>>
>>>> diff --git a/drivers/video/omap2/dss/dss.c
>>>> b/drivers/video/omap2/dss/dss.c
>>>> index 054c2a2..645b3bc 100644
>>>> --- a/drivers/video/omap2/dss/dss.c
>>>> +++ b/drivers/video/omap2/dss/dss.c
>>>> @@ -767,13 +767,11 @@ int dss_dpi_select_source(enum omap_channel
>>>> channel)
>>>> static int dss_get_clocks(void)
>>>> {
>>>> struct clk *clk;
>>>> - int r;
>>>>
>>>> - clk = clk_get(&dss.pdev->dev, "fck");
>>>> + clk = devm_clk_get(&dss.pdev->dev, "fck");
>>>> if (IS_ERR(clk)) {
>>>> DSSERR("can't get clock fck\n");
>>>> - r = PTR_ERR(clk);
>>>> - goto err;
>>>> + return PTR_ERR(clk);
>>>> }
>>>>
>>>> dss.dss_clk = clk;
>>>> @@ -782,8 +780,7 @@ static int dss_get_clocks(void)
>>>> clk = clk_get(NULL, dss.feat->clk_name);
>>>> if (IS_ERR(clk)) {
>>>> DSSERR("Failed to get %s\n", dss.feat->clk_name);
>>>> - r = PTR_ERR(clk);
>>>> - goto err;
>>>> + return PTR_ERR(clk);
>>>> }
>>>> } else {
>>>> clk = NULL;
>>>> @@ -792,21 +789,12 @@ static int dss_get_clocks(void)
>>>> dss.dpll4_m4_ck = clk;
>>>>
>>>> return 0;
>>>> -
>>>> -err:
>>>> - if (dss.dss_clk)
>>>> - clk_put(dss.dss_clk);
>>>> - if (dss.dpll4_m4_ck)
>>>> - clk_put(dss.dpll4_m4_ck);
>>>> -
>>>> - return r;
>>>> }
>>>
>>> Why didn't you use devm_clk_get for the dpll4_m4_ck clock also?
>>
>> clk_get of dpll4_m4_ck isn't tied to a device:
>>
>> clk = clk_get(NULL, dss.feat->clk_name);
>>
>> We can't use devm_clk_get() if we don't tie it to a device, right?
>
> Ah, true.
>
>> I think the dss.dss_clk clock above is same as the dpll4_m4_ck for all
>> OMAPs. We could probably remove the dpll4_m4_clk all together, and use
>> dss_clk to get the rate of DSS_FCK coming from PRCM.
>
> Hmm, no, if I recall right, dpll4_m4_clk is the parent of dss clock (or
> parent of the parent of...), and the dss_fck_multiplier affects the
> resulting dss fck. Or something like that. It's a bit messy, especially
> as we can't just use the dss fck to change the rate, we need to change
> the rate at the parent for some reason.
Ah ok, I remember it now. One of the DPLL's divider's output is DSS_FCK.
We get the parent's rate and iterate through all the possible hsdivider
values to get the closest pixel clock. We don't/can't change
dpll4_m4_clk as such, we just need to know it's rate for our calculations.
So yes, we need dpll4_m4_clk, we just need to rename it to a better
thing. Like dss_clk_parent.
Anyway,
Archit
^ permalink raw reply
* Re: [PATCH] omapdss: use devm_clk_get()
From: Tomi Valkeinen @ 2013-04-10 9:32 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <516530B1.80203@ti.com>
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
On 2013-04-10 12:28, Archit Taneja wrote:
> Ah ok, I remember it now. One of the DPLL's divider's output is DSS_FCK.
> We get the parent's rate and iterate through all the possible hsdivider
> values to get the closest pixel clock. We don't/can't change
> dpll4_m4_clk as such, we just need to know it's rate for our calculations.
>
> So yes, we need dpll4_m4_clk, we just need to rename it to a better
> thing. Like dss_clk_parent.
Right. And the field name in struct dss_features, "clk_name" is rather
vague.
At some point we should fix the omap clk framework so that we can set
the dss fck directly. Presuming there's no good reason to have it as it
is now.
I'll apply the patch as it is now.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH] omapdss: use devm_clk_get()
From: Tomi Valkeinen @ 2013-04-10 9:19 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <516524B8.60205@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2818 bytes --]
On 2013-04-10 11:37, Archit Taneja wrote:
> On Wednesday 10 April 2013 01:43 PM, Tomi Valkeinen wrote:
>> On 2013-04-08 11:55, Archit Taneja wrote:
>>> Use devm_clk_get() instead of clk_get() for dss, and for outputs hdmi
>>> and venc.
>>> This reduces reduces code and simplifies error handling.
>>>
>>> Signed-off-by: Archit Taneja <archit@ti.com>
>>> ---
>>> drivers/video/omap2/dss/dss.c | 18 +++---------------
>>> drivers/video/omap2/dss/hdmi.c | 16 ++--------------
>>> drivers/video/omap2/dss/venc.c | 10 +---------
>>> 3 files changed, 6 insertions(+), 38 deletions(-)
>>>
>>> diff --git a/drivers/video/omap2/dss/dss.c
>>> b/drivers/video/omap2/dss/dss.c
>>> index 054c2a2..645b3bc 100644
>>> --- a/drivers/video/omap2/dss/dss.c
>>> +++ b/drivers/video/omap2/dss/dss.c
>>> @@ -767,13 +767,11 @@ int dss_dpi_select_source(enum omap_channel
>>> channel)
>>> static int dss_get_clocks(void)
>>> {
>>> struct clk *clk;
>>> - int r;
>>>
>>> - clk = clk_get(&dss.pdev->dev, "fck");
>>> + clk = devm_clk_get(&dss.pdev->dev, "fck");
>>> if (IS_ERR(clk)) {
>>> DSSERR("can't get clock fck\n");
>>> - r = PTR_ERR(clk);
>>> - goto err;
>>> + return PTR_ERR(clk);
>>> }
>>>
>>> dss.dss_clk = clk;
>>> @@ -782,8 +780,7 @@ static int dss_get_clocks(void)
>>> clk = clk_get(NULL, dss.feat->clk_name);
>>> if (IS_ERR(clk)) {
>>> DSSERR("Failed to get %s\n", dss.feat->clk_name);
>>> - r = PTR_ERR(clk);
>>> - goto err;
>>> + return PTR_ERR(clk);
>>> }
>>> } else {
>>> clk = NULL;
>>> @@ -792,21 +789,12 @@ static int dss_get_clocks(void)
>>> dss.dpll4_m4_ck = clk;
>>>
>>> return 0;
>>> -
>>> -err:
>>> - if (dss.dss_clk)
>>> - clk_put(dss.dss_clk);
>>> - if (dss.dpll4_m4_ck)
>>> - clk_put(dss.dpll4_m4_ck);
>>> -
>>> - return r;
>>> }
>>
>> Why didn't you use devm_clk_get for the dpll4_m4_ck clock also?
>
> clk_get of dpll4_m4_ck isn't tied to a device:
>
> clk = clk_get(NULL, dss.feat->clk_name);
>
> We can't use devm_clk_get() if we don't tie it to a device, right?
Ah, true.
> I think the dss.dss_clk clock above is same as the dpll4_m4_ck for all
> OMAPs. We could probably remove the dpll4_m4_clk all together, and use
> dss_clk to get the rate of DSS_FCK coming from PRCM.
Hmm, no, if I recall right, dpll4_m4_clk is the parent of dss clock (or
parent of the parent of...), and the dss_fck_multiplier affects the
resulting dss fck. Or something like that. It's a bit messy, especially
as we can't just use the dss fck to change the rate, we need to change
the rate at the parent for some reason.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH] omapdss: use devm_clk_get()
From: Archit Taneja @ 2013-04-10 8:49 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <51651F25.3020302@ti.com>
On Wednesday 10 April 2013 01:43 PM, Tomi Valkeinen wrote:
> On 2013-04-08 11:55, Archit Taneja wrote:
>> Use devm_clk_get() instead of clk_get() for dss, and for outputs hdmi and venc.
>> This reduces reduces code and simplifies error handling.
>>
>> Signed-off-by: Archit Taneja <archit@ti.com>
>> ---
>> drivers/video/omap2/dss/dss.c | 18 +++---------------
>> drivers/video/omap2/dss/hdmi.c | 16 ++--------------
>> drivers/video/omap2/dss/venc.c | 10 +---------
>> 3 files changed, 6 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
>> index 054c2a2..645b3bc 100644
>> --- a/drivers/video/omap2/dss/dss.c
>> +++ b/drivers/video/omap2/dss/dss.c
>> @@ -767,13 +767,11 @@ int dss_dpi_select_source(enum omap_channel channel)
>> static int dss_get_clocks(void)
>> {
>> struct clk *clk;
>> - int r;
>>
>> - clk = clk_get(&dss.pdev->dev, "fck");
>> + clk = devm_clk_get(&dss.pdev->dev, "fck");
>> if (IS_ERR(clk)) {
>> DSSERR("can't get clock fck\n");
>> - r = PTR_ERR(clk);
>> - goto err;
>> + return PTR_ERR(clk);
>> }
>>
>> dss.dss_clk = clk;
>> @@ -782,8 +780,7 @@ static int dss_get_clocks(void)
>> clk = clk_get(NULL, dss.feat->clk_name);
>> if (IS_ERR(clk)) {
>> DSSERR("Failed to get %s\n", dss.feat->clk_name);
>> - r = PTR_ERR(clk);
>> - goto err;
>> + return PTR_ERR(clk);
>> }
>> } else {
>> clk = NULL;
>> @@ -792,21 +789,12 @@ static int dss_get_clocks(void)
>> dss.dpll4_m4_ck = clk;
>>
>> return 0;
>> -
>> -err:
>> - if (dss.dss_clk)
>> - clk_put(dss.dss_clk);
>> - if (dss.dpll4_m4_ck)
>> - clk_put(dss.dpll4_m4_ck);
>> -
>> - return r;
>> }
>
> Why didn't you use devm_clk_get for the dpll4_m4_ck clock also?
clk_get of dpll4_m4_ck isn't tied to a device:
clk = clk_get(NULL, dss.feat->clk_name);
We can't use devm_clk_get() if we don't tie it to a device, right?
I think the dss.dss_clk clock above is same as the dpll4_m4_ck for all
OMAPs. We could probably remove the dpll4_m4_clk all together, and use
dss_clk to get the rate of DSS_FCK coming from PRCM.
Archit
^ permalink raw reply
* Re: [PATCH 1/1] video: wm8505fb: Convert to devm_ioremap_resource()
From: Tomi Valkeinen @ 2013-04-10 8:23 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1365415496-6825-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]
On 2013-04-08 13:04, Sachin Kamat wrote:
> Use the newly introduced devm_ioremap_resource() instead of
> devm_request_and_ioremap() which provides more consistent error handling.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> drivers/video/wm8505fb.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
> index 19e2e7f..01f9ace 100644
> --- a/drivers/video/wm8505fb.c
> +++ b/drivers/video/wm8505fb.c
> @@ -18,6 +18,7 @@
> #include <linux/dma-mapping.h>
> #include <linux/fb.h>
> #include <linux/errno.h>
> +#include <linux/err.h>
> #include <linux/init.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> @@ -303,9 +304,9 @@ static int wm8505fb_probe(struct platform_device *pdev)
> fbi->fb.pseudo_palette = addr;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - fbi->regbase = devm_request_and_ioremap(&pdev->dev, res);
> - if (fbi->regbase == NULL)
> - return -EBUSY;
> + fbi->regbase = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(fbi->regbase))
> + return PTR_ERR(fbi->regbase);
>
> disp_timing = of_get_display_timings(pdev->dev.of_node);
> if (!disp_timing)
>
Thanks, applying on top of the previous series from Tony Prisk.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH] omapdss: use devm_clk_get()
From: Tomi Valkeinen @ 2013-04-10 8:13 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1365411346-30611-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]
On 2013-04-08 11:55, Archit Taneja wrote:
> Use devm_clk_get() instead of clk_get() for dss, and for outputs hdmi and venc.
> This reduces reduces code and simplifies error handling.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> drivers/video/omap2/dss/dss.c | 18 +++---------------
> drivers/video/omap2/dss/hdmi.c | 16 ++--------------
> drivers/video/omap2/dss/venc.c | 10 +---------
> 3 files changed, 6 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
> index 054c2a2..645b3bc 100644
> --- a/drivers/video/omap2/dss/dss.c
> +++ b/drivers/video/omap2/dss/dss.c
> @@ -767,13 +767,11 @@ int dss_dpi_select_source(enum omap_channel channel)
> static int dss_get_clocks(void)
> {
> struct clk *clk;
> - int r;
>
> - clk = clk_get(&dss.pdev->dev, "fck");
> + clk = devm_clk_get(&dss.pdev->dev, "fck");
> if (IS_ERR(clk)) {
> DSSERR("can't get clock fck\n");
> - r = PTR_ERR(clk);
> - goto err;
> + return PTR_ERR(clk);
> }
>
> dss.dss_clk = clk;
> @@ -782,8 +780,7 @@ static int dss_get_clocks(void)
> clk = clk_get(NULL, dss.feat->clk_name);
> if (IS_ERR(clk)) {
> DSSERR("Failed to get %s\n", dss.feat->clk_name);
> - r = PTR_ERR(clk);
> - goto err;
> + return PTR_ERR(clk);
> }
> } else {
> clk = NULL;
> @@ -792,21 +789,12 @@ static int dss_get_clocks(void)
> dss.dpll4_m4_ck = clk;
>
> return 0;
> -
> -err:
> - if (dss.dss_clk)
> - clk_put(dss.dss_clk);
> - if (dss.dpll4_m4_ck)
> - clk_put(dss.dpll4_m4_ck);
> -
> - return r;
> }
Why didn't you use devm_clk_get for the dpll4_m4_ck clock also?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: nec-nl8048 panel: Use dev_pm_ops
From: Tomi Valkeinen @ 2013-04-10 8:07 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Florian Tobias Schandinat, Archit Taneja, linux-omap, linux-fbdev,
linux-kernel
In-Reply-To: <1365326053-16248-1-git-send-email-lars@metafoo.de>
[-- Attachment #1: Type: text/plain, Size: 401 bytes --]
On 2013-04-07 12:14, Lars-Peter Clausen wrote:
> Use dev_pm_ops instead of the deprecated legacy suspend/resume callbacks.
>
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> ---
> .../video/omap2/displays/panel-nec-nl8048hl11-01b.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
Thanks, looks good to me. I'll add to fbdev misc patches.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: Status of exporting an fbdev framebuffer with dma_buf?
From: Laurent Pinchart @ 2013-04-09 17:12 UTC (permalink / raw)
To: Tom Cooksey; +Cc: linaro-mm-sig, dri-devel, linux-media, linux-fbdev
Hi Tom,
On Tuesday 09 April 2013 12:21:08 Tom Cooksey wrote:
> Hi All,
>
> Last year Laurent posted an RFC patch[i] to add support for exporting an
> fbdev framebuffer through dma_buf. Looking through the mailing list
> archives, it doesn't appear to have progressed beyond an RFC? What would be
> needed to get this merged? It would be useful for our Mali T6xx driver
> (which supports importing dma_buf buffers) to allow the GPU to draw
> directly into the framebuffer on platforms which lack a DRM/KMS driver.
The patch was pretty simple, I don't think it would take lots of efforts to
get it to mainline. On the other hand, fbdev is a dying API, so I'm not sure
how much energy we want to spend on upgrading it. I suppose all that would be
needed is a developer with enough interest in the topic to fix the patch
according to the comments.
> [i] Subject: "[RFC/PATCH] fb: Add dma-buf support", sent 20/06/2012.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 08/10] drivers: mfd: use module_platform_driver_probe()
From: Fabio Porcedda @ 2013-04-09 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130409080653.GG24058@zurbaran>
On Tue, Apr 9, 2013 at 10:06 AM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> Hi Fabio,
>
> On Thu, Mar 14, 2013 at 02:11:29PM +0100, Fabio Porcedda wrote:
>> This patch converts the drivers to use the
>> module_platform_driver_probe() macro which makes the code smaller and
>> a bit simpler.
>>
>> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> ---
>> drivers/mfd/davinci_voicecodec.c | 12 +-----------
>> drivers/mfd/htc-pasic3.c | 13 +------------
>> 2 files changed, 2 insertions(+), 23 deletions(-)
> Jingoo Han sent a larger patchset to convert many MFD drivers to
> module_platform_driver_probe(), including htc-pasic3 and davinci_voicecodec.
>
> See my mfd-next tree for more details.
I understand, thanks for letting me know.
It's my fault for having waited too long to send this patch set.
Best regards
--
Fabio Porcedda
> Cheers,
> Samuel.
>
> --
> Intel Open Source Technology Centre
> http://oss.intel.com/
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Geert Uytterhoeven @ 2013-04-09 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130408171637.98b5ad1f867bcbda883af68b@linux-foundation.org>
On Tue, Apr 9, 2013 at 2:16 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 3 Apr 2013 20:39:43 -0600 Stephen Warren <swarren@wwwdotorg.org> wrote:
>> A simple frame-buffer describes a raw memory region that may be rendered
>> to, with the assumption that the display hardware has already been set
>> up to scan out from that buffer.
>>
>> This is useful in cases where a bootloader exists and has set up the
>> display hardware, but a Linux driver doesn't yet exist for the display
>> hardware.
>>
>> ...
>>
>> +config FB_SIMPLE
>> + bool "Simple framebuffer support"
>> + depends on (FB = y) && OF
>
> It's sad that this simple little thing requires Open Firmware. Could
> it be generalised in some way so that the small amount of setup info
> could be provided by other means (eg, module_param) or does the
> dependency go deeper than that?
Indeed. Instead of consolidating, we seem to get more of them: offb, vesafb,
efifb, ...
cfr. near the tail of drivers/video/Makefile (don't know about all of them):
# Platform or fallback drivers go here
obj-$(CONFIG_FB_UVESA) += uvesafb.o
obj-$(CONFIG_FB_VESA) += vesafb.o
obj-$(CONFIG_FB_EFI) += efifb.o
obj-$(CONFIG_FB_VGA16) += vga16fb.o
obj-$(CONFIG_FB_OF) += offb.o
obj-$(CONFIG_FB_BF537_LQ035) += bf537-lq035.o
obj-$(CONFIG_FB_BF54X_LQ043) += bf54x-lq043fb.o
obj-$(CONFIG_FB_BFIN_LQ035Q1) += bfin-lq035q1-fb.o
obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o
obj-$(CONFIG_FB_BFIN_7393) += bfin_adv7393fb.o
obj-$(CONFIG_FB_MX3) += mx3fb.o
obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o
obj-$(CONFIG_FB_MXS) += mxsfb.o
obj-$(CONFIG_FB_SSD1307) += ssd1307fb.o
# the test framebuffer is last
obj-$(CONFIG_FB_VIRTUAL) += vfb.o
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 08/10] drivers: mfd: use module_platform_driver_probe()
From: Samuel Ortiz @ 2013-04-09 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1363266691-15757-10-git-send-email-fabio.porcedda@gmail.com>
Hi Fabio,
On Thu, Mar 14, 2013 at 02:11:29PM +0100, Fabio Porcedda wrote:
> This patch converts the drivers to use the
> module_platform_driver_probe() macro which makes the code smaller and
> a bit simpler.
>
> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/mfd/davinci_voicecodec.c | 12 +-----------
> drivers/mfd/htc-pasic3.c | 13 +------------
> 2 files changed, 2 insertions(+), 23 deletions(-)
Jingoo Han sent a larger patchset to convert many MFD drivers to
module_platform_driver_probe(), including htc-pasic3 and davinci_voicecodec.
See my mfd-next tree for more details.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Stephen Warren @ 2013-04-09 3:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130408171637.98b5ad1f867bcbda883af68b@linux-foundation.org>
On 04/08/2013 06:16 PM, Andrew Morton wrote:
> On Wed, 3 Apr 2013 20:39:43 -0600 Stephen Warren <swarren@wwwdotorg.org> wrote:
>
>> A simple frame-buffer describes a raw memory region that may be rendered
>> to, with the assumption that the display hardware has already been set
>> up to scan out from that buffer.
>>
>> This is useful in cases where a bootloader exists and has set up the
>> display hardware, but a Linux driver doesn't yet exist for the display
>> hardware.
>>
>> ...
>>
>> +config FB_SIMPLE
>> + bool "Simple framebuffer support"
>> + depends on (FB = y) && OF
>
> It's sad that this simple little thing requires Open Firmware. Could
> it be generalised in some way so that the small amount of setup info
> could be provided by other means (eg, module_param) or does the
> dependency go deeper than that?
I wouldn't be at all surprised if others want to feed it platform data
rather than parameterizing it through device tree. All my platforms use
DT though, so I didn't want to add that support without any user; it'd
just be dead code for now. But, if someone wants that, I can certainly
code it up or test/review after the change etc.
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Andrew Morton @ 2013-04-09 0:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
On Wed, 3 Apr 2013 20:39:43 -0600 Stephen Warren <swarren@wwwdotorg.org> wrote:
> A simple frame-buffer describes a raw memory region that may be rendered
> to, with the assumption that the display hardware has already been set
> up to scan out from that buffer.
>
> This is useful in cases where a bootloader exists and has set up the
> display hardware, but a Linux driver doesn't yet exist for the display
> hardware.
>
> ...
>
> +config FB_SIMPLE
> + bool "Simple framebuffer support"
> + depends on (FB = y) && OF
It's sad that this simple little thing requires Open Firmware. Could
it be generalised in some way so that the small amount of setup info
could be provided by other means (eg, module_param) or does the
dependency go deeper than that?
> +struct simplefb_format simplefb_formats[] = {
> + { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
> +};
I'll make this static.
^ permalink raw reply
* Re: [PATCH 1/1] video: wm8505fb: Convert to devm_ioremap_resource()
From: Tony Prisk @ 2013-04-08 18:31 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1365415496-6825-1-git-send-email-sachin.kamat@linaro.org>
On 08/04/13 22:04, Sachin Kamat wrote:
> Use the newly introduced devm_ioremap_resource() instead of
> devm_request_and_ioremap() which provides more consistent error handling.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> drivers/video/wm8505fb.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
> index 19e2e7f..01f9ace 100644
> --- a/drivers/video/wm8505fb.c
> +++ b/drivers/video/wm8505fb.c
> @@ -18,6 +18,7 @@
> #include <linux/dma-mapping.h>
> #include <linux/fb.h>
> #include <linux/errno.h>
> +#include <linux/err.h>
> #include <linux/init.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> @@ -303,9 +304,9 @@ static int wm8505fb_probe(struct platform_device *pdev)
> fbi->fb.pseudo_palette = addr;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - fbi->regbase = devm_request_and_ioremap(&pdev->dev, res);
> - if (fbi->regbase = NULL)
> - return -EBUSY;
> + fbi->regbase = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(fbi->regbase))
> + return PTR_ERR(fbi->regbase);
>
> disp_timing = of_get_display_timings(pdev->dev.of_node);
> if (!disp_timing)
Looks fine,
Acked-by: Tony Prisk <linux@prisktech.co.nz>
Regards
Tony P
^ permalink raw reply
* [PATCH] of: videomode: Fix module loading problem
From: Mohsin Kazmi @ 2013-04-08 11:05 UTC (permalink / raw)
To: linux-fbdev
This patch adds the support load as a module of_videomode.c which is required by parallel display.
I have encountered the following problem.
imx_parallel_display: Unknown symbol of_get_video_mode (err 0)
insmod: can't insert 'imx-parallel-display.ko': unknown symbol in module, or unknown parameter
of_get_video_mode() is available in of_videomode.c but it couldn't loaded and gave the following error.
of_videomode: Unknown symbol of_property_read_u32_array (err 0)
modprobe: can't load module of_videomode (kernel/drivers/of/of_videomode.ko): unknown symbol in module, or unknown parameter
I have discussed this with Dmitry Eremin-Solenikov. He told me to do so as in this patch and it works.
Signed-off-by: Mohsin Kazmi <mohsin_kazmi@mentor.com>
---
drivers/of/of_videomode.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
index 859aefb..cd55f89 100644
--- a/drivers/of/of_videomode.c
+++ b/drivers/of/of_videomode.c
@@ -10,6 +10,7 @@
#include <linux/export.h>
#include <drm/drmP.h>
#include <drm/drm_crtc.h>
+#include <linux/module.h>
int of_get_video_mode(struct device_node *np, struct drm_display_mode *dmode,
struct fb_videomode *fbmode)
@@ -106,3 +107,5 @@ int of_get_video_mode(struct device_node *np, struct drm_display_mode *dmode,
return 0;
}
EXPORT_SYMBOL_GPL(of_get_video_mode);
+
+MODULE_LICENSE("GPL");
--
1.8.0
^ 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