* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Marek Vasut @ 2013-03-18 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130318185810.GA11040@kroah.com>
Hi Greg,
[...]
> > NOTE: This is the version for stable v3.8.3, so I'm sending it to
> > -stable.
> >
> > I will send adjusted version for mainline 3.9-rc , since there is
> > one more board in mainline and therefore the versions of the patch
> > must differ.
>
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
I'm somewhat sure I violated a few (see below), I won't argue there as you
surely are much more experienced, but let me dissect the rules so I can learn
which one to be careful about. Please help me if I did not understand something
properly.
- It must be obviously correct and tested.
YES, Fabio tested it on MX28EVK, me on M28EVK (two different devices)
- It cannot be bigger than 100 lines, with context.
NO, but I see no way to compress it under 100 lines.
- It must fix only one thing.
YES, it fixes broken X11 on MX28
- It must fix a real bug that bothers people (not a, "This could be a
problem..." type thing).
YES, it fixes broken X11 on MX28
- It must fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short, something
critical.
YES, it fixes broken X11 on MX28
- Serious issues as reported by a user of a distribution kernel may also
be considered if they fix a notable performance or interactivity issue.
As these fixes are not as obvious and have a higher risk of a subtle
regression they should only be submitted by a distribution kernel
maintainer and include an addendum linking to a bugzilla entry if it
exists and additional information on the user-visible impact.
This doesn't apply I guess?
- New device IDs and quirks are also accepted.
This doesn't apply for sure.
- No "theoretical race condition" issues, unless an explanation of how the
race can be exploited is also provided.
This doesn't apply for sure.
- It cannot contain any "trivial" fixes in it (spelling changes,
whitespace cleanups, etc).
This doesn't apply for sure.
- It must follow the Documentation/SubmittingPatches rules.
I believe it does. It has one checkpatch warning, but to keep the amount of
changes to bare minimum, I left it in there.
- It or an equivalent fix must already exist in Linus' tree (upstream).
This can not happen, the fix in Linus' tree will have to be different since in
v3.9 there is one more MX28 platform which also needs fixing. I suppose I will
now wait for Shawn to merge the patch for 3.9-rc, get it mainline and then this
one can be merged?
Thank you!
Best regards,
Marek Vasut
^ permalink raw reply
* Re: How to manage OMAP display drivers in the future
From: Rob Clark @ 2013-03-18 20:46 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, dri-devel@lists.freedesktop.org
In-Reply-To: <51403F91.7070401@iki.fi>
On Wed, Mar 13, 2013 at 4:57 AM, Tomi Valkeinen <tomba@iki.fi> 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.
I'd guess if changes in omapfb or omap_vout are mainly just updates
resulting from omapdss changes, maybe merging it all via drm tree
would make most sense..
Although I tend to think life would be easier w/ some copy/paste.. Ie.
just move a copy of omapdss into omapdrm directory and start
refactoring.. Offhand I think at least in the hdmi code, I think we
could jettison the big timings table, and avi-infoframe stuff and use
drm helpers. Probably other places where we could get rid of code
that duplicates stuff that drm does (or could) provide helpers for..
BR,
-R
> 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.
>
> Tomi
^ permalink raw reply
* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Greg KH @ 2013-03-18 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1363630997-5254-1-git-send-email-marex@denx.de>
On Mon, Mar 18, 2013 at 07:23:17PM +0100, Marek Vasut wrote:
> The issue fixed by this patch manifests only then using X11
> with mxsfb driver. The X11 will display either shifted image
> or otherwise distorted image on the LCD.
>
> The problem is that the X11 tries to reconfigure the framebuffer
> and along the way calls fb_ops.fb_set_par() with X11's desired
> configuration values. The field of particular interest is
> fb_info->var.sync which contains non-standard values if
> configured by kernel. These are either FB_SYNC_DATA_ENABLE_HIGH_ACT,
> FB_SYNC_DOTCLK_FAILING_ACT or both, depending on the platform
> configuration. Both of these values are defined in the
> include/linux/mxsfb.h file.
>
> The driver interprets these values and configures the LCD controller
> accordingly. Yet X11 only has access to the standard values for this
> field defined in include/uapi/linux/fb.h and thus, unlike kernel,
> omits these special values. This results in distorted image on the
> LCD.
>
> This patch moves these non-standard values into new field of the
> mxsfb_platform_data structure so the driver can in turn check this
> field instead of the video mode field for these specific portions.
>
> Moreover, this patch prefixes these values with MXSFB_SYNC_ prefix
> instead of FB_SYNC_ prefix to prevent confusion of subsequent users.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>
> Cc: Linux FBDEV <linux-fbdev@vger.kernel.org>
> Cc: Lothar Waßmann <LW@karo-electronics.de>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> arch/arm/mach-mxs/mach-mxs.c | 22 +++++++++++-----------
> drivers/video/mxsfb.c | 7 +++++--
> include/linux/mxsfb.h | 7 +++++--
> 3 files changed, 21 insertions(+), 15 deletions(-)
>
> NOTE: This is the version for stable v3.8.3, so I'm sending it to -stable.
> I will send adjusted version for mainline 3.9-rc , since there is
> one more board in mainline and therefore the versions of the patch
> must differ.
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply
* [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Marek Vasut @ 2013-03-18 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AwD7Q3G+xp9DW0vioZnHZJX538nFeE9F-P+jbHMHPqoQ@mail.gmail.com>
The issue fixed by this patch manifests only then using X11
with mxsfb driver. The X11 will display either shifted image
or otherwise distorted image on the LCD.
The problem is that the X11 tries to reconfigure the framebuffer
and along the way calls fb_ops.fb_set_par() with X11's desired
configuration values. The field of particular interest is
fb_info->var.sync which contains non-standard values if
configured by kernel. These are either FB_SYNC_DATA_ENABLE_HIGH_ACT,
FB_SYNC_DOTCLK_FAILING_ACT or both, depending on the platform
configuration. Both of these values are defined in the
include/linux/mxsfb.h file.
The driver interprets these values and configures the LCD controller
accordingly. Yet X11 only has access to the standard values for this
field defined in include/uapi/linux/fb.h and thus, unlike kernel,
omits these special values. This results in distorted image on the
LCD.
This patch moves these non-standard values into new field of the
mxsfb_platform_data structure so the driver can in turn check this
field instead of the video mode field for these specific portions.
Moreover, this patch prefixes these values with MXSFB_SYNC_ prefix
instead of FB_SYNC_ prefix to prevent confusion of subsequent users.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>
Cc: Linux FBDEV <linux-fbdev@vger.kernel.org>
Cc: Lothar Waßmann <LW@karo-electronics.de>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-mxs/mach-mxs.c | 25 +++++++++++++------------
drivers/video/mxsfb.c | 7 +++++--
include/linux/mxsfb.h | 7 +++++--
3 files changed, 23 insertions(+), 16 deletions(-)
NOTE: This is the version for mainline, I'm not CCing stable.
diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
index 3218f1f..cc8d704 100644
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@ -41,8 +41,6 @@ static struct fb_videomode mx23evk_video_modes[] = {
.lower_margin = 4,
.hsync_len = 1,
.vsync_len = 1,
- .sync = FB_SYNC_DATA_ENABLE_HIGH_ACT |
- FB_SYNC_DOTCLK_FAILING_ACT,
},
};
@@ -59,8 +57,6 @@ static struct fb_videomode mx28evk_video_modes[] = {
.lower_margin = 10,
.hsync_len = 10,
.vsync_len = 10,
- .sync = FB_SYNC_DATA_ENABLE_HIGH_ACT |
- FB_SYNC_DOTCLK_FAILING_ACT,
},
};
@@ -77,7 +73,6 @@ static struct fb_videomode m28evk_video_modes[] = {
.lower_margin = 45,
.hsync_len = 1,
.vsync_len = 1,
- .sync = FB_SYNC_DATA_ENABLE_HIGH_ACT,
},
};
@@ -94,9 +89,7 @@ static struct fb_videomode apx4devkit_video_modes[] = {
.lower_margin = 13,
.hsync_len = 48,
.vsync_len = 3,
- .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT |
- FB_SYNC_DATA_ENABLE_HIGH_ACT |
- FB_SYNC_DOTCLK_FAILING_ACT,
+ .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
},
};
@@ -113,9 +106,7 @@ static struct fb_videomode apf28dev_video_modes[] = {
.lower_margin = 0x15,
.hsync_len = 64,
.vsync_len = 4,
- .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT |
- FB_SYNC_DATA_ENABLE_HIGH_ACT |
- FB_SYNC_DOTCLK_FAILING_ACT,
+ .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
},
};
@@ -132,7 +123,6 @@ static struct fb_videomode cfa10049_video_modes[] = {
.lower_margin = 2,
.hsync_len = 15,
.vsync_len = 15,
- .sync = FB_SYNC_DATA_ENABLE_HIGH_ACT
},
};
@@ -259,6 +249,8 @@ static void __init imx23_evk_init(void)
mxsfb_pdata.mode_count = ARRAY_SIZE(mx23evk_video_modes);
mxsfb_pdata.default_bpp = 32;
mxsfb_pdata.ld_intf_width = STMLCDIF_24BIT;
+ mxsfb_pdata.sync = MXSFB_SYNC_DATA_ENABLE_HIGH_ACT |
+ MXSFB_SYNC_DOTCLK_FAILING_ACT;
}
static inline void enable_clk_enet_out(void)
@@ -278,6 +270,8 @@ static void __init imx28_evk_init(void)
mxsfb_pdata.mode_count = ARRAY_SIZE(mx28evk_video_modes);
mxsfb_pdata.default_bpp = 32;
mxsfb_pdata.ld_intf_width = STMLCDIF_24BIT;
+ mxsfb_pdata.sync = MXSFB_SYNC_DATA_ENABLE_HIGH_ACT |
+ MXSFB_SYNC_DOTCLK_FAILING_ACT;
mxs_saif_clkmux_select(MXS_DIGCTL_SAIF_CLKMUX_EXTMSTR0);
}
@@ -297,6 +291,7 @@ static void __init m28evk_init(void)
mxsfb_pdata.mode_count = ARRAY_SIZE(m28evk_video_modes);
mxsfb_pdata.default_bpp = 16;
mxsfb_pdata.ld_intf_width = STMLCDIF_18BIT;
+ mxsfb_pdata.sync = MXSFB_SYNC_DATA_ENABLE_HIGH_ACT;
}
static void __init sc_sps1_init(void)
@@ -322,6 +317,8 @@ static void __init apx4devkit_init(void)
mxsfb_pdata.mode_count = ARRAY_SIZE(apx4devkit_video_modes);
mxsfb_pdata.default_bpp = 32;
mxsfb_pdata.ld_intf_width = STMLCDIF_24BIT;
+ mxsfb_pdata.sync = MXSFB_SYNC_DATA_ENABLE_HIGH_ACT |
+ MXSFB_SYNC_DOTCLK_FAILING_ACT;
}
#define ENET0_MDC__GPIO_4_0 MXS_GPIO_NR(4, 0)
@@ -407,6 +404,8 @@ static void __init cfa10049_init(void)
mxsfb_pdata.mode_count = ARRAY_SIZE(cfa10049_video_modes);
mxsfb_pdata.default_bpp = 32;
mxsfb_pdata.ld_intf_width = STMLCDIF_18BIT;
+ mxsfb_pdata.sync = MXSFB_SYNC_DATA_ENABLE_HIGH_ACT;
+
}
static void __init cfa10037_init(void)
@@ -423,6 +422,8 @@ static void __init apf28_init(void)
mxsfb_pdata.mode_count = ARRAY_SIZE(apf28dev_video_modes);
mxsfb_pdata.default_bpp = 16;
mxsfb_pdata.ld_intf_width = STMLCDIF_16BIT;
+ mxsfb_pdata.sync = MXSFB_SYNC_DATA_ENABLE_HIGH_ACT |
+ MXSFB_SYNC_DOTCLK_FAILING_ACT;
}
static void __init mxs_machine_init(void)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 755556c..45169cb 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -169,6 +169,7 @@ struct mxsfb_info {
unsigned dotclk_delay;
const struct mxsfb_devdata *devdata;
int mapped;
+ u32 sync;
};
#define mxsfb_is_v3(host) (host->devdata->ipversion = 3)
@@ -456,9 +457,9 @@ static int mxsfb_set_par(struct fb_info *fb_info)
vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH;
if (fb_info->var.sync & FB_SYNC_VERT_HIGH_ACT)
vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
- if (fb_info->var.sync & FB_SYNC_DATA_ENABLE_HIGH_ACT)
+ if (host->sync & MXSFB_SYNC_DATA_ENABLE_HIGH_ACT)
vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH;
- if (fb_info->var.sync & FB_SYNC_DOTCLK_FAILING_ACT)
+ if (host->sync & MXSFB_SYNC_DOTCLK_FAILING_ACT)
vdctrl0 |= VDCTRL0_DOTCLK_ACT_FAILING;
writel(vdctrl0, host->base + LCDC_VDCTRL0);
@@ -861,6 +862,8 @@ static int mxsfb_probe(struct platform_device *pdev)
INIT_LIST_HEAD(&fb_info->modelist);
+ host->sync = pdata->sync;
+
ret = mxsfb_init_fbinfo(host);
if (ret != 0)
goto error_init_fb;
diff --git a/include/linux/mxsfb.h b/include/linux/mxsfb.h
index f14943d..f80af86 100644
--- a/include/linux/mxsfb.h
+++ b/include/linux/mxsfb.h
@@ -24,8 +24,8 @@
#define STMLCDIF_18BIT 2 /** pixel data bus to the display is of 18 bit width */
#define STMLCDIF_24BIT 3 /** pixel data bus to the display is of 24 bit width */
-#define FB_SYNC_DATA_ENABLE_HIGH_ACT (1 << 6)
-#define FB_SYNC_DOTCLK_FAILING_ACT (1 << 7) /* failing/negtive edge sampling */
+#define MXSFB_SYNC_DATA_ENABLE_HIGH_ACT (1 << 6)
+#define MXSFB_SYNC_DOTCLK_FAILING_ACT (1 << 7) /* failing/negtive edge sampling */
struct mxsfb_platform_data {
struct fb_videomode *mode_list;
@@ -44,6 +44,9 @@ struct mxsfb_platform_data {
* allocated. If specified,fb_size must also be specified.
* fb_phys must be unused by Linux.
*/
+ u32 sync; /* sync mask, contains MXSFB specifics not
+ * carried in fb_info->var.sync
+ */
};
#endif /* __LINUX_MXSFB_H */
--
1.7.10.4
^ permalink raw reply related
* [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Marek Vasut @ 2013-03-18 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AwD7Q3G+xp9DW0vioZnHZJX538nFeE9F-P+jbHMHPqoQ@mail.gmail.com>
The issue fixed by this patch manifests only then using X11
with mxsfb driver. The X11 will display either shifted image
or otherwise distorted image on the LCD.
The problem is that the X11 tries to reconfigure the framebuffer
and along the way calls fb_ops.fb_set_par() with X11's desired
configuration values. The field of particular interest is
fb_info->var.sync which contains non-standard values if
configured by kernel. These are either FB_SYNC_DATA_ENABLE_HIGH_ACT,
FB_SYNC_DOTCLK_FAILING_ACT or both, depending on the platform
configuration. Both of these values are defined in the
include/linux/mxsfb.h file.
The driver interprets these values and configures the LCD controller
accordingly. Yet X11 only has access to the standard values for this
field defined in include/uapi/linux/fb.h and thus, unlike kernel,
omits these special values. This results in distorted image on the
LCD.
This patch moves these non-standard values into new field of the
mxsfb_platform_data structure so the driver can in turn check this
field instead of the video mode field for these specific portions.
Moreover, this patch prefixes these values with MXSFB_SYNC_ prefix
instead of FB_SYNC_ prefix to prevent confusion of subsequent users.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>
Cc: Linux FBDEV <linux-fbdev@vger.kernel.org>
Cc: Lothar Waßmann <LW@karo-electronics.de>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-mxs/mach-mxs.c | 22 +++++++++++-----------
drivers/video/mxsfb.c | 7 +++++--
include/linux/mxsfb.h | 7 +++++--
3 files changed, 21 insertions(+), 15 deletions(-)
NOTE: This is the version for stable v3.8.3, so I'm sending it to -stable.
I will send adjusted version for mainline 3.9-rc , since there is
one more board in mainline and therefore the versions of the patch
must differ.
diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
index c66129b..ebf592c 100644
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@ -41,8 +41,6 @@ static struct fb_videomode mx23evk_video_modes[] = {
.lower_margin = 4,
.hsync_len = 1,
.vsync_len = 1,
- .sync = FB_SYNC_DATA_ENABLE_HIGH_ACT |
- FB_SYNC_DOTCLK_FAILING_ACT,
},
};
@@ -59,8 +57,6 @@ static struct fb_videomode mx28evk_video_modes[] = {
.lower_margin = 10,
.hsync_len = 10,
.vsync_len = 10,
- .sync = FB_SYNC_DATA_ENABLE_HIGH_ACT |
- FB_SYNC_DOTCLK_FAILING_ACT,
},
};
@@ -77,7 +73,6 @@ static struct fb_videomode m28evk_video_modes[] = {
.lower_margin = 45,
.hsync_len = 1,
.vsync_len = 1,
- .sync = FB_SYNC_DATA_ENABLE_HIGH_ACT,
},
};
@@ -94,9 +89,7 @@ static struct fb_videomode apx4devkit_video_modes[] = {
.lower_margin = 13,
.hsync_len = 48,
.vsync_len = 3,
- .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT |
- FB_SYNC_DATA_ENABLE_HIGH_ACT |
- FB_SYNC_DOTCLK_FAILING_ACT,
+ .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
},
};
@@ -113,9 +106,7 @@ static struct fb_videomode apf28dev_video_modes[] = {
.lower_margin = 0x15,
.hsync_len = 64,
.vsync_len = 4,
- .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT |
- FB_SYNC_DATA_ENABLE_HIGH_ACT |
- FB_SYNC_DOTCLK_FAILING_ACT,
+ .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
},
};
@@ -250,6 +241,8 @@ static void __init imx23_evk_init(void)
mxsfb_pdata.mode_count = ARRAY_SIZE(mx23evk_video_modes);
mxsfb_pdata.default_bpp = 32;
mxsfb_pdata.ld_intf_width = STMLCDIF_24BIT;
+ mxsfb_pdata.sync = MXSFB_SYNC_DATA_ENABLE_HIGH_ACT |
+ MXSFB_SYNC_DOTCLK_FAILING_ACT;
}
static inline void enable_clk_enet_out(void)
@@ -269,6 +262,8 @@ static void __init imx28_evk_init(void)
mxsfb_pdata.mode_count = ARRAY_SIZE(mx28evk_video_modes);
mxsfb_pdata.default_bpp = 32;
mxsfb_pdata.ld_intf_width = STMLCDIF_24BIT;
+ mxsfb_pdata.sync = MXSFB_SYNC_DATA_ENABLE_HIGH_ACT |
+ MXSFB_SYNC_DOTCLK_FAILING_ACT;
mxs_saif_clkmux_select(MXS_DIGCTL_SAIF_CLKMUX_EXTMSTR0);
}
@@ -288,6 +283,7 @@ static void __init m28evk_init(void)
mxsfb_pdata.mode_count = ARRAY_SIZE(m28evk_video_modes);
mxsfb_pdata.default_bpp = 16;
mxsfb_pdata.ld_intf_width = STMLCDIF_18BIT;
+ mxsfb_pdata.sync = MXSFB_SYNC_DATA_ENABLE_HIGH_ACT;
}
static void __init sc_sps1_init(void)
@@ -313,6 +309,8 @@ static void __init apx4devkit_init(void)
mxsfb_pdata.mode_count = ARRAY_SIZE(apx4devkit_video_modes);
mxsfb_pdata.default_bpp = 32;
mxsfb_pdata.ld_intf_width = STMLCDIF_24BIT;
+ mxsfb_pdata.sync = MXSFB_SYNC_DATA_ENABLE_HIGH_ACT |
+ MXSFB_SYNC_DOTCLK_FAILING_ACT;
}
#define ENET0_MDC__GPIO_4_0 MXS_GPIO_NR(4, 0)
@@ -403,6 +401,8 @@ static void __init apf28_init(void)
mxsfb_pdata.mode_count = ARRAY_SIZE(apf28dev_video_modes);
mxsfb_pdata.default_bpp = 16;
mxsfb_pdata.ld_intf_width = STMLCDIF_16BIT;
+ mxsfb_pdata.sync = MXSFB_SYNC_DATA_ENABLE_HIGH_ACT |
+ MXSFB_SYNC_DOTCLK_FAILING_ACT;
}
static void __init mxs_machine_init(void)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 755556c..45169cb 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -169,6 +169,7 @@ struct mxsfb_info {
unsigned dotclk_delay;
const struct mxsfb_devdata *devdata;
int mapped;
+ u32 sync;
};
#define mxsfb_is_v3(host) (host->devdata->ipversion = 3)
@@ -456,9 +457,9 @@ static int mxsfb_set_par(struct fb_info *fb_info)
vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH;
if (fb_info->var.sync & FB_SYNC_VERT_HIGH_ACT)
vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
- if (fb_info->var.sync & FB_SYNC_DATA_ENABLE_HIGH_ACT)
+ if (host->sync & MXSFB_SYNC_DATA_ENABLE_HIGH_ACT)
vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH;
- if (fb_info->var.sync & FB_SYNC_DOTCLK_FAILING_ACT)
+ if (host->sync & MXSFB_SYNC_DOTCLK_FAILING_ACT)
vdctrl0 |= VDCTRL0_DOTCLK_ACT_FAILING;
writel(vdctrl0, host->base + LCDC_VDCTRL0);
@@ -861,6 +862,8 @@ static int mxsfb_probe(struct platform_device *pdev)
INIT_LIST_HEAD(&fb_info->modelist);
+ host->sync = pdata->sync;
+
ret = mxsfb_init_fbinfo(host);
if (ret != 0)
goto error_init_fb;
diff --git a/include/linux/mxsfb.h b/include/linux/mxsfb.h
index f14943d..f80af86 100644
--- a/include/linux/mxsfb.h
+++ b/include/linux/mxsfb.h
@@ -24,8 +24,8 @@
#define STMLCDIF_18BIT 2 /** pixel data bus to the display is of 18 bit width */
#define STMLCDIF_24BIT 3 /** pixel data bus to the display is of 24 bit width */
-#define FB_SYNC_DATA_ENABLE_HIGH_ACT (1 << 6)
-#define FB_SYNC_DOTCLK_FAILING_ACT (1 << 7) /* failing/negtive edge sampling */
+#define MXSFB_SYNC_DATA_ENABLE_HIGH_ACT (1 << 6)
+#define MXSFB_SYNC_DOTCLK_FAILING_ACT (1 << 7) /* failing/negtive edge sampling */
struct mxsfb_platform_data {
struct fb_videomode *mode_list;
@@ -44,6 +44,9 @@ struct mxsfb_platform_data {
* allocated. If specified,fb_size must also be specified.
* fb_phys must be unused by Linux.
*/
+ u32 sync; /* sync mask, contains MXSFB specifics not
+ * carried in fb_info->var.sync
+ */
};
#endif /* __LINUX_MXSFB_H */
--
1.7.10.4
^ permalink raw reply related
* RE: [PATCH 1/3] backlight: ep93xx_bl: fix section mismatch
From: H Hartley Sweeten @ 2013-03-18 17:51 UTC (permalink / raw)
To: Ryan Mallon
Cc: Linux Kernel, linux-fbdev@vger.kernel.org, rpurdie@rpsys.net,
FlorianSchandinat@gmx.de
In-Reply-To: <5143D6C4.9060503@gmail.com>
T24gRnJpZGF5LCBNYXJjaCAxNSwgMjAxMyA3OjIwIFBNLCBSeWFuIE1hbGxvbiB3cm90ZToNCj4g
T24gMTYvMDMvMTMgMTI6MDMsIEggSGFydGxleSBTd2VldGVuIHdyb3RlOg0KPg0KPj4gUmVtb3Zl
IHRoZSBfX2luaXQgdGFnIGZyb20gZXA5M3h4YmxfcHJvYmUoKSB0byBmaXggdGhlIHNlY3Rpb24N
Cj4+IG1pc21hdGNoIHdhcm5pbmcuDQo+PiANCj4+IFNpZ25lZC1vZmYtYnk6IEggSGFydGxleSBT
d2VldGVuIDxoc3dlZXRlbkB2aXNpb25lbmdyYXZlcnMuY29tPg0KPj4gQ2M6IFJ5YW4gTWFsbG9u
IDxybWFsbG9uQGdtYWlsLmNvbT4NCj4+IENjOiBSaWNoYXJkIFB1cmRpZSA8cnB1cmRpZUBycHN5
cy5uZXQ+DQo+PiBDYzogRmxvcmlhbiBUb2JpYXMgU2NoYW5kaW5hdCA8RmxvcmlhblNjaGFuZGlu
YXRAZ214LmRlPg0KPg0KPg0KPiBUaGVyZSBpcyBhIHBhdGNoIGZvciB0aGlzIGFscmVhZHkgcXVl
dWVkIGluIEFuZHJldyBNb3J0b24ncyB0cmVlLg0KDQpBaCwgbWlzc2VkIHRoYXQgb25lLiBQbGVh
c2UgZHJvcCBwYXRjaCAxLzMuDQoNClRoZSBvdGhlciB0d28sIGFzIHdlbGwgYXMgdGhlIGNvbXBp
bGUgYnVnIGZpeCBmb3IgZXA5M3h4X2ZiLmMgc2hvdWxkIHN0aWxsDQpiZSBvay4gVGhlIGJ1ZyBm
aXggcGF0Y2ggaXMgcHJvYmFibHkgdmFsaWQgZm9yIHN0YWJsZSBhcyBhcHByb3ByaWF0ZS4NCg0K
W1BBVENIXSB2aWRlbzogZXA5M3h4X2ZiOiBpbmNsdWRlIDxsaW51eC9pby5oPiBmb3IgZGV2bV9p
b3JlbWFwKCkNCltQQVRDSCAyLzNdIHZpZGVvOiBlcDkzeHgtZmIuYzogZml4IHNlY3Rpb24gbWlz
bWF0Y2ggYW5kIHVzZSBtb2R1bGVfcGxhdGZvcm1fZHJpdmVyDQpbUEFUQ0ggMy8zXSBtaXNjOiBl
cDkzeHhfcHdtLmM6IGZpeCBzZWN0aW9uIG1pc21hdGNoIGFuZCB1c2UgbW9kdWxlX3BsYXRmb3Jt
X2RyaXZlcg0KDQpUaGFua3MsDQpIYXJ0bGV5DQoNCg=
^ permalink raw reply
* [PATCH V3 7/7] fbcon: queue work on any cpu
From: Viresh Kumar @ 2013-03-18 15:35 UTC (permalink / raw)
To: pjt, paul.mckenney, tglx, tj, suresh.b.siddha, venki, mingo,
peterz, rostedt
Cc: linaro-kernel, robin.randhawa, Steve.Bannister, Liviu.Dudau,
charles.garcia-tobin, Arvind.Chauhan, linux-rt-users,
linux-kernel, Viresh Kumar, Dave Airlie, linux-fbdev
In-Reply-To: <cover.1363617402.git.viresh.kumar@linaro.org>
fbcon uses workqueues and it has no real dependency of scheduling these on the
cpu which scheduled them.
On a idle system, it is observed that and idle cpu wakes up few times just to
service this work. It would be better if we can schedule it on a cpu which isn't
idle to save on power.
By idle cpu (from scheduler's perspective) we mean:
- Current task is idle task
- nr_running = 0
- wake_list is empty
This patch replaces schedule_work() routine with queue_work_on_any_cpu()
sibling with system_wq as workqueue.
This routine would look for the closest (via scheduling domains) non-idle cpu
(non-idle from schedulers perspective). If the current cpu is not idle or all
cpus are idle, work will be scheduled on local cpu.
Cc: Dave Airlie <airlied@redhat.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/video/console/fbcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 3cd6759..a900997 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -404,7 +404,7 @@ static void cursor_timer_handler(unsigned long dev_addr)
struct fb_info *info = (struct fb_info *) dev_addr;
struct fbcon_ops *ops = info->fbcon_par;
- schedule_work(&info->queue);
+ queue_work_on_any_cpu(system_wq, &info->queue);
mod_timer(&ops->cursor_timer, jiffies + HZ/5);
}
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Marek Vasut @ 2013-03-18 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130318143129.GG12462@S2101-09.ap.freescale.net>
Dear Shawn Guo,
> On Mon, Mar 18, 2013 at 03:18:13PM +0100, Marek Vasut wrote:
> > Did you manage to test it please?
>
> I do not have X11 environment handy to test, but framework console
> seems still working.
Even after me poking in it, lol :-)
You can grab [1], extract it onto card or NFS and just use it as root
filesystem, the X11 will come up automagically.
[1] ftp://ftp.denx.de/pub/eldk/5.3/targets/armv5te/core-image-sato-sdk-generic-
armv5te.tar.gz
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Shawn Guo @ 2013-03-18 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201303181518.14171.marex@denx.de>
On Mon, Mar 18, 2013 at 03:18:13PM +0100, Marek Vasut wrote:
> Did you manage to test it please?
I do not have X11 environment handy to test, but framework console
seems still working.
Shawn
^ permalink raw reply
* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Marek Vasut @ 2013-03-18 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130318140633.GF12462@S2101-09.ap.freescale.net>
Dear Shawn Guo,
> On Mon, Mar 18, 2013 at 02:58:17PM +0100, Marek Vasut wrote:
> > Dear Shawn Guo,
> >
> > > On Mon, Mar 18, 2013 at 10:11:47AM -0300, Fabio Estevam wrote:
> > > > Shawn Guo wrote:
> > > > > Since it touches mach-mxs as well, let me send it through arm-soc
> > > > > tree as fix for 3.9.
> > > >
> > > > Please CC stable as well, so that we can have X11 functional with
> > > > 3.8.
> > >
> > > Ok, done.
> >
> > Shawn, I think this patch applies to 3.9-rc but there's one more platform
> > in mach-mxs.c in 3.9-rc thus this will have compile issue. Just renaming
> > those two FB_SYNC_ values to MXSFB_SYNC_ fixes the compile issue on
> > 3.9-rc.
>
> Yes, I noticed that and fixed it when applying the patch.
>
> > Also the
> > commit log doesn't look all that cool .... I probably should have marked
> > the patch as RFC.
> >
> > Shall I send you one for 3.9-rc and one for stable maybe ?
>
> Yeah, improved patch is welcomed. So I'm dropping the current one and
> waiting for the new one.
Perfect, latest tomorrow then.
Did you manage to test it please?
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Shawn Guo @ 2013-03-18 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201303181458.17656.marex@denx.de>
On Mon, Mar 18, 2013 at 02:58:17PM +0100, Marek Vasut wrote:
> Dear Shawn Guo,
>
> > On Mon, Mar 18, 2013 at 10:11:47AM -0300, Fabio Estevam wrote:
> > > Shawn Guo wrote:
> > > > Since it touches mach-mxs as well, let me send it through arm-soc tree
> > > > as fix for 3.9.
> > >
> > > Please CC stable as well, so that we can have X11 functional with 3.8.
> >
> > Ok, done.
>
> Shawn, I think this patch applies to 3.9-rc but there's one more platform in
> mach-mxs.c in 3.9-rc thus this will have compile issue. Just renaming those two
> FB_SYNC_ values to MXSFB_SYNC_ fixes the compile issue on 3.9-rc.
Yes, I noticed that and fixed it when applying the patch.
> Also the
> commit log doesn't look all that cool .... I probably should have marked the
> patch as RFC.
>
> Shall I send you one for 3.9-rc and one for stable maybe ?
Yeah, improved patch is welcomed. So I'm dropping the current one and
waiting for the new one.
Shawn
^ permalink raw reply
* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Marek Vasut @ 2013-03-18 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130318130108.GE12462@S2101-09.ap.freescale.net>
Dear Shawn Guo,
> On Mon, Mar 18, 2013 at 10:11:47AM -0300, Fabio Estevam wrote:
> > Shawn Guo wrote:
> > > Since it touches mach-mxs as well, let me send it through arm-soc tree
> > > as fix for 3.9.
> >
> > Please CC stable as well, so that we can have X11 functional with 3.8.
>
> Ok, done.
Shawn, I think this patch applies to 3.9-rc but there's one more platform in
mach-mxs.c in 3.9-rc thus this will have compile issue. Just renaming those two
FB_SYNC_ values to MXSFB_SYNC_ fixes the compile issue on 3.9-rc. Also the
commit log doesn't look all that cool .... I probably should have marked the
patch as RFC.
Shall I send you one for 3.9-rc and one for stable maybe ?
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Shawn Guo @ 2013-03-18 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51471293.5070105@freescale.com>
On Mon, Mar 18, 2013 at 10:11:47AM -0300, Fabio Estevam wrote:
> Shawn Guo wrote:
>
> > Since it touches mach-mxs as well, let me send it through arm-soc tree
> > as fix for 3.9.
>
> Please CC stable as well, so that we can have X11 functional with 3.8.
Ok, done.
^ permalink raw reply
* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Fabio Estevam @ 2013-03-18 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130318122650.GD12462@S2101-09.ap.freescale.net>
Shawn Guo wrote:
> Since it touches mach-mxs as well, let me send it through arm-soc tree
> as fix for 3.9.
Please CC stable as well, so that we can have X11 functional with 3.8.
^ permalink raw reply
* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Shawn Guo @ 2013-03-18 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1363471581-10132-1-git-send-email-marex@denx.de>
On Sat, Mar 16, 2013 at 11:06:21PM +0100, Marek Vasut wrote:
> The issue fixed by this patch manifests only then using X11
> with mxsfb driver. The X11 will display either shifted image
> or otherwise distorted image on the LCD.
>
> The problem is that the X11 tries to reconfigure the framebuffer
> and along the way call fb_ops.fb_set_par() with it's configuration
> values. The field of particular interest is fb_info->var.sync which
> contains non-standard values if configured by kernel. These are
> FB_SYNC_DATA_ENABLE_HIGH_ACT and FB_SYNC_DOTCLK_FAILING_ACT defined
> in include/linux/mxsfb.h . The driver interprets those and configures
> the LCD controller accordingly. Yet X11 only has access to standard
> values for this field defined in include/uapi/linux/fb.h and thus
> omits these special values. This results in distorted image on the
> LCD.
>
> This patch moves these non-standard values into new field of the
> mxsfb_platform_data structure so the driver can in turn check this
> field instead of the video mode field for these specific portions.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Fabio Estevam <fabio.estavem@freescale.com>
> Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>
> Cc: Linux FBDEV <linux-fbdev@vger.kernel.org>
> Cc: Lothar Waßmann <LW@karo-electronics.de>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> ---
> arch/arm/mach-mxs/mach-mxs.c | 22 +++++++++++-----------
> drivers/video/mxsfb.c | 7 +++++--
> include/linux/mxsfb.h | 7 +++++--
> 3 files changed, 21 insertions(+), 15 deletions(-)
Since it touches mach-mxs as well, let me send it through arm-soc tree
as fix for 3.9.
Shawn
^ permalink raw reply
* Re: [PATCH 5/5] videomode: rename fields
From: Tomi Valkeinen @ 2013-03-18 12:28 UTC (permalink / raw)
To: Daniel Vetter; +Cc: linux-fbdev, Steffen Trumtrar, Laurent Pinchart, dri-devel
In-Reply-To: <20130318080057.GL9021@phenom.ffwll.local>
[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]
On 2013-03-18 10:00, Daniel Vetter wrote:
> On Tue, Mar 12, 2013 at 03:40:14PM +0200, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 2013-03-12 15:37, Laurent Pinchart wrote:
>>> Hi Tomi,
>>>
>>> Thanks for the patch.
>>>
>>> On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
>>>> Structs videomode and display_timing have rather long field names for
>>>> the timing values. Nothing wrong with that as such, but this patch
>>>> changes them to abbreviations for the following reasons:
>>>>
>>>> * The timing values often need to be used in calculations, and long
>>>> field names makes their direct use clumsier.
>>>>
>>>> * The current names are a bit of a mishmash: some words are used as
>>>> such, some are shortened, and for some only first letter is used. Some
>>>> names use underscode, some don't. All this makes it difficult to
>>>> remember what the field names are.
>>>>
>>>> * The abbreviations used in this patch are very common, and there
>>>> shouldn't be any misunderstanding about their meaning.
>>>>
>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>>> Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
>>>> ---
>>>
>>> I have no strong opinion on this, but I find the existing names easier to
>>> read. I might be biased by having read them often though.
>>
>> Yes, the last patch was a bit of a "teaser" =). I found myself typoing
>> them a lot, using helper local variables to shorten the code lines, and
>> as I mention in the description, I find them a bit of a mishmash. So,
>> while they're not used in any drivers yet, I thought it'd be worth a
>> shot to change them.
>
> Imo the new names look quite a bit more ugly and less readable, for very
> few saved chars. And at least for i915.ko development it's been a long
> time since I've last had to type them ... Maybe the real problem is that
> we have a few too many video mode structures and can't properly share
> them?
I guess it's a matter of taste. But I've received three "I don't like
the new names" comments, and no positive comments, so I'm dropping the
last patch. The first four should be fine, though.
And yes, we should definitely try to use only this new videomode struct
in the future everywhere in the kernel. It sure would make me remember
the names better =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()
From: Arnd Bergmann @ 2013-03-18 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkwnC-aHwd24S5MyLhnVzTqqQj2L7MMuVX9dirhS-G830jZcw@mail.gmail.com>
On Monday 18 March 2013, Fabio Porcedda wrote:
>
> On Mon, Mar 18, 2013 at 11:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 18 March 2013, Fabio Porcedda wrote:
> >> Since by using platform_driver_probe() the function
> >> ep93xx_pwm_probe() is freed after initialization,
> >> is better to use module_platform_drive_probe().
> >> IMHO i don't see any good reason to use module_platform_driver() for
> >> this driver.
> >
> > As I commented earlier, the platform_driver_probe() and
> > module_platform_drive_probe() interfaces are rather dangerous in combination
> > with deferred probing, I would much prefer Harley's patch.
>
> Since those drivers don't use -EPROBE_DEFER i was thinking that they don't use
> deferred probing.
> I'm missing something?
clk_get() may return -EPROBE_DEFER after ep93xx is converted to use the
common clk API. We currently return the value of clk_get from the probe()
function, which will automatically do the right thing as long as the probe
function remains reachable.
Arnd
^ permalink raw reply
* Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()
From: Fabio Porcedda @ 2013-03-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201303181058.51641.arnd@arndb.de>
On Mon, Mar 18, 2013 at 11:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 18 March 2013, Fabio Porcedda wrote:
>> Since by using platform_driver_probe() the function
>> ep93xx_pwm_probe() is freed after initialization,
>> is better to use module_platform_drive_probe().
>> IMHO i don't see any good reason to use module_platform_driver() for
>> this driver.
>
> As I commented earlier, the platform_driver_probe() and
> module_platform_drive_probe() interfaces are rather dangerous in combination
> with deferred probing, I would much prefer Harley's patch.
Since those drivers don't use -EPROBE_DEFER i was thinking that they don't use
deferred probing.
I'm missing something?
Best regards
Fabio Porcedda
> Arnd
^ permalink raw reply
* Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()
From: Arnd Bergmann @ 2013-03-18 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkwnC9YFTw8gVzyZB3_gZCgM5zMA6tLch15EDqcA2F4CAOpAQ@mail.gmail.com>
On Monday 18 March 2013, Fabio Porcedda wrote:
> Since by using platform_driver_probe() the function
> ep93xx_pwm_probe() is freed after initialization,
> is better to use module_platform_drive_probe().
> IMHO i don't see any good reason to use module_platform_driver() for
> this driver.
As I commented earlier, the platform_driver_probe() and
module_platform_drive_probe() interfaces are rather dangerous in combination
with deferred probing, I would much prefer Harley's patch.
Arnd
^ permalink raw reply
* Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()
From: Fabio Porcedda @ 2013-03-18 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201303152018.09094.arnd@arndb.de>
On Fri, Mar 15, 2013 at 9:18 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 15 March 2013, H Hartley Sweeten wrote:
>> Arnd,
>>
>> Ill look at converting the ep93xx pwm driver to the PWM subsystem. The only issue is
>> the current driver exposes a sysfs interface that I think is not available in that subsystem.
>
> You can probably keep providing that interface if you have active users.
>
>> >* Regarding the use of module_platform_driver_probe, I'm a little worried about
>> > the interactions with deferred probing. I don't think there are any regressions,
>> > but we should probably make people aware that one cannot return -EPROBE_DEFER
>> > from a platform_driver_probe function.
>>
>> The ep93xx pwm driver does not need to use platform_driver_probe(). It can be changed
>> to use module_platform_driver() by just moving the .probe to the platform_driver. This
>> driver was added before module_platform_driver() was available and I used the
>> platform_driver_probe() thinking it would save a couple lines of code.
Since by using platform_driver_probe() the function
ep93xx_pwm_probe() is freed after initialization,
is better to use module_platform_drive_probe().
IMHO i don't see any good reason to use module_platform_driver() for
this driver.
Best regards
Fabio Porcedda
>> I'll change this in a bit. Right now I'm trying to work out why kernel 3.8 is not booting
>> on the ep93xx. I had 3.6.6 on my development board and 3.7 works fine but 3.8 hangs
>> without uncompressing the kernel.
>
> Ok, thanks!
>
> Arnd
^ permalink raw reply
* Re: [PATCH 5/5] videomode: rename fields
From: Daniel Vetter @ 2013-03-18 7:58 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, Steffen Trumtrar, Laurent Pinchart, dri-devel
In-Reply-To: <513F303E.5000007@ti.com>
On Tue, Mar 12, 2013 at 03:40:14PM +0200, Tomi Valkeinen wrote:
> Hi,
>
> On 2013-03-12 15:37, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > Thanks for the patch.
> >
> > On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
> >> Structs videomode and display_timing have rather long field names for
> >> the timing values. Nothing wrong with that as such, but this patch
> >> changes them to abbreviations for the following reasons:
> >>
> >> * The timing values often need to be used in calculations, and long
> >> field names makes their direct use clumsier.
> >>
> >> * The current names are a bit of a mishmash: some words are used as
> >> such, some are shortened, and for some only first letter is used. Some
> >> names use underscode, some don't. All this makes it difficult to
> >> remember what the field names are.
> >>
> >> * The abbreviations used in this patch are very common, and there
> >> shouldn't be any misunderstanding about their meaning.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >> Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> >> ---
> >
> > I have no strong opinion on this, but I find the existing names easier to
> > read. I might be biased by having read them often though.
>
> Yes, the last patch was a bit of a "teaser" =). I found myself typoing
> them a lot, using helper local variables to shorten the code lines, and
> as I mention in the description, I find them a bit of a mishmash. So,
> while they're not used in any drivers yet, I thought it'd be worth a
> shot to change them.
Imo the new names look quite a bit more ugly and less readable, for very
few saved chars. And at least for i915.ko development it's been a long
time since I've last had to type them ... Maybe the real problem is that
we have a few too many video mode structures and can't properly share
them?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH v2 2/8] drivers: ata: use module_platform_driver_probe()
From: Jingoo Han @ 2013-03-18 3:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1363280978-24051-3-git-send-email-fabio.porcedda@gmail.com>
On Friday, March 15, 2013 2:10 AM, 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: Jeff Garzik <jgarzik@pobox.com>
> Cc: linux-ide@vger.kernel.org
> ---
> drivers/ata/pata_at32.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
I already submitted the patch 2 weeks ago.
http://www.spinics.net/lists/linux-ide/msg45141.html
Best regards,
Jingoo Han
>
> diff --git a/drivers/ata/pata_at32.c b/drivers/ata/pata_at32.c
> index 36f189c..8d493b4 100644
> --- a/drivers/ata/pata_at32.c
> +++ b/drivers/ata/pata_at32.c
> @@ -393,18 +393,7 @@ static struct platform_driver pata_at32_driver = {
> },
> };
>
> -static int __init pata_at32_init(void)
> -{
> - return platform_driver_probe(&pata_at32_driver, pata_at32_probe);
> -}
> -
> -static void __exit pata_at32_exit(void)
> -{
> - platform_driver_unregister(&pata_at32_driver);
> -}
> -
> -module_init(pata_at32_init);
> -module_exit(pata_at32_exit);
> +module_platform_driver_probe(pata_at32_driver, pata_at32_probe);
>
> MODULE_LICENSE("GPL");
> MODULE_DESCRIPTION("AVR32 SMC/CFC PATA Driver");
> --
> 1.8.1.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 6/8] drivers: mfd: use module_platform_driver_probe()
From: Jingoo Han @ 2013-03-18 3:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1363280978-24051-7-git-send-email-fabio.porcedda@gmail.com>
On Friday, March 15, 2013 2:10 AM, 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(-)
I already submitted the patch 2 weeks ago.
https://patchwork.kernel.org/patch/2217301/
https://patchwork.kernel.org/patch/2217291/
Best regards,
Jingoo Han
>
> diff --git a/drivers/mfd/davinci_voicecodec.c b/drivers/mfd/davinci_voicecodec.c
> index c0bcc87..c60ab0c 100644
> --- a/drivers/mfd/davinci_voicecodec.c
> +++ b/drivers/mfd/davinci_voicecodec.c
> @@ -177,17 +177,7 @@ static struct platform_driver davinci_vc_driver = {
> .remove = davinci_vc_remove,
> };
>
> -static int __init davinci_vc_init(void)
> -{
> - return platform_driver_probe(&davinci_vc_driver, davinci_vc_probe);
> -}
> -module_init(davinci_vc_init);
> -
> -static void __exit davinci_vc_exit(void)
> -{
> - platform_driver_unregister(&davinci_vc_driver);
> -}
> -module_exit(davinci_vc_exit);
> +module_platform_driver_probe(davinci_vc_driver, davinci_vc_probe);
>
> MODULE_AUTHOR("Miguel Aguilar");
> MODULE_DESCRIPTION("Texas Instruments DaVinci Voice Codec Core Interface");
> diff --git a/drivers/mfd/htc-pasic3.c b/drivers/mfd/htc-pasic3.c
> index 9e5453d..0285fce 100644
> --- a/drivers/mfd/htc-pasic3.c
> +++ b/drivers/mfd/htc-pasic3.c
> @@ -208,18 +208,7 @@ static struct platform_driver pasic3_driver = {
> .remove = pasic3_remove,
> };
>
> -static int __init pasic3_base_init(void)
> -{
> - return platform_driver_probe(&pasic3_driver, pasic3_probe);
> -}
> -
> -static void __exit pasic3_base_exit(void)
> -{
> - platform_driver_unregister(&pasic3_driver);
> -}
> -
> -module_init(pasic3_base_init);
> -module_exit(pasic3_base_exit);
> +module_platform_driver_probe(pasic3_driver, pasic3_probe);
>
> MODULE_AUTHOR("Philipp Zabel <philipp.zabel@gmail.com>");
> MODULE_DESCRIPTION("Core driver for HTC PASIC3");
> --
> 1.8.1.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] drivers/video: fsl-diu-fb: add hardware cursor support
From: Timur Tabi @ 2013-03-17 23:09 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1358281046-31552-1-git-send-email-timur@tabi.org>
On Tue, Jan 15, 2013 at 2:17 PM, Timur Tabi <timur@tabi.org> wrote:
> From: Timur Tabi <timur@freescale.com>
>
> The Freescale DIU supports a 32x32 color hardware cursor. Framebuffer
> cursors are monochrome, so the driver converts the image data to the
> format that the DIU expects and then programs to hardware accordingly.
>
> The support cursor enabling/disabling, we provide two cursor image buffers.
> One is always blank (all zeroes), and the other contains the real cursor
> image data. To disable the cursor (used typically for cursor blinking),
> we just tell the hardware to use the blank cursor data.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Florian, this patch was posted a month before the 3.9 merge window
opened. Is there any chance it will still get into 3.9?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Fabio Estevam @ 2013-03-16 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1363471581-10132-1-git-send-email-marex@denx.de>
On Sat, Mar 16, 2013 at 7:06 PM, Marek Vasut <marex@denx.de> wrote:
> The issue fixed by this patch manifests only then using X11
> with mxsfb driver. The X11 will display either shifted image
> or otherwise distorted image on the LCD.
>
> The problem is that the X11 tries to reconfigure the framebuffer
> and along the way call fb_ops.fb_set_par() with it's configuration
> values. The field of particular interest is fb_info->var.sync which
> contains non-standard values if configured by kernel. These are
> FB_SYNC_DATA_ENABLE_HIGH_ACT and FB_SYNC_DOTCLK_FAILING_ACT defined
> in include/linux/mxsfb.h . The driver interprets those and configures
> the LCD controller accordingly. Yet X11 only has access to standard
> values for this field defined in include/uapi/linux/fb.h and thus
> omits these special values. This results in distorted image on the
> LCD.
>
> This patch moves these non-standard values into new field of the
> mxsfb_platform_data structure so the driver can in turn check this
> field instead of the video mode field for these specific portions.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Fabio Estevam <fabio.estavem@freescale.com>
> Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>
> Cc: Linux FBDEV <linux-fbdev@vger.kernel.org>
> Cc: Lothar Waßmann <LW@karo-electronics.de>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Shawn Guo <shawn.guo@linaro.org>
This fixes the X11 offset issue on my mx28evk, thanks!
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox