* Re: [PATCH v2] fbdev: sh_mobile_lcdc: fixup B side hsync adjust settings
From: Laurent Pinchart @ 2013-03-19 12:38 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87txoqmo3p.wl%kuninori.morimoto.gx@renesas.com>
Hi Simon,
On Tuesday 19 March 2013 13:19:52 Simon Horman wrote:
> On Tue, Mar 05, 2013 at 04:45:46PM +0100, Laurent Pinchart wrote:
> > On Monday 04 March 2013 21:07:10 Kuninori Morimoto wrote:
> > > The lcdc B side horizon output is shifted
> > > if sh_mobile_lcdc_pan() was called.
> > > This patch fixup this issue.
> > > It is tested on R8A7740 Armadillo800eva HDMI output.
> > > Special thanks to Fukushima-san, and Sano-san
> > >
> > > Reported-by: Osamu Fukushima <osamu.fukushima.wr@renesas.com>
> > > Signed-off-by: Hideyuki Sano <hideyuki.sano.dn@renesas.com>
> > > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >
> > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> Laurent, can you handle getting this merged?
> If not, please let me know who to prod.
We have no fbdev maintainer anymore. Can this be pushed through your tree ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: How to manage OMAP display drivers in the future
From: Tomi Valkeinen @ 2013-03-19 11:56 UTC (permalink / raw)
To: Rob Clark; +Cc: linux-fbdev, dri-devel@lists.freedesktop.org
In-Reply-To: <CAF6AEGs_6kLU=OR-mX9kvr=_t9-z4+StobksaW+MfcnhEu2XvA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]
On 2013-03-18 22:46, Rob Clark wrote:
> 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..
I've been playing with that idea, but copying omapdss is not so
straightforward either. The panel drivers, headers, kconfig options,
board file code related to dss... It could easily create a rather
confusing mess.
I'm hoping that CDF in some form would realize soon, and then copying
omapdss would be at least somewhwat easier, as there's no need to drag
the panel drivers along.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Marek Vasut @ 2013-03-19 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130319054846.GI12462@S2101-09.ap.freescale.net>
Dear Shawn Guo,
> On Mon, Mar 18, 2013 at 04:19:52PM +0100, Marek Vasut wrote:
> > 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.
>
> Thanks, Marek. Yeah, now I can see the problem and your patch does fix
> it.
Whew, cool. Can you please apply it and push mainline so I can re-send the one
for -stable then?
Thank you!
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] ARM: OMAP: remove "config FB_OMAP_CONSISTENT_DMA_SIZE"
From: Paul Bolle @ 2013-03-19 10:07 UTC (permalink / raw)
To: Tomi Valkeinen, Florian Tobias Schandinat
Cc: linux-fbdev, linux-omap, linux-kernel
The only user of Kconfig symbol FB_OMAP_CONSISTENT_DMA_SIZE got removed
in v3.8, with commit 6ba54ab4a49bbad736b0254aa6bdf0cb83013815 ("ARM:
OMAP: Remove omap_init_consistent_dma_size()"). Remove this symbol too.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
Eyeball tested only.
drivers/video/omap/Kconfig | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
index e512581..0bc3a93 100644
--- a/drivers/video/omap/Kconfig
+++ b/drivers/video/omap/Kconfig
@@ -39,17 +39,6 @@ config FB_OMAP_LCD_MIPID
the Mobile Industry Processor Interface DBI-C/DCS
specification. (Supported LCDs: Philips LPH8923, Sharp LS041Y3)
-config FB_OMAP_CONSISTENT_DMA_SIZE
- int "Consistent DMA memory size (MB)"
- depends on FB_OMAP
- range 1 14
- default 2
- help
- Increase the DMA consistent memory size according to your video
- memory needs, for example if you want to use multiple planes.
- The size must be 2MB aligned.
- If unsure say 1.
-
config FB_OMAP_DMA_TUNE
bool "Set DMA SDRAM access priority high"
depends on FB_OMAP
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()
From: Geert Uytterhoeven @ 2013-03-19 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkwnC9fg7_uhLM2KD3vvj_oFx3EBoQfw8mCN=V9pyV5=k37aA@mail.gmail.com>
On Tue, Mar 19, 2013 at 9:55 AM, Fabio Porcedda
<fabio.porcedda@gmail.com> wrote:
> On Mon, Mar 18, 2013 at 12:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> 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.
>
> Thanks for the explanation.
Hmm, so we may have drivers that (now) work perfectly fine with
module_platform_driver_probe()/platform_driver_probe(), but will start
failing suddenly in the future?
I guess we need a big fat WARN_ON(-EPROBE_DEFER) in
platform_driver_probe() to catch these?
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 10/10] drivers: misc: use module_platform_driver_probe()
From: Fabio Porcedda @ 2013-03-19 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201303181128.45215.arnd@arndb.de>
On Mon, Mar 18, 2013 at 12:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 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.
Thanks for the explanation.
Regards
Fabio Porcedda
> Arnd
^ permalink raw reply
* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Shawn Guo @ 2013-03-19 5:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1363631042-5321-1-git-send-email-marex@denx.de>
On Mon, Mar 18, 2013 at 07:24:02PM +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>
Applied with one trivial change below.
...
> @@ -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;
> +
I removed this unnecessary new line.
Shawn
> }
^ permalink raw reply
* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Shawn Guo @ 2013-03-19 5:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201303181619.52377.marex@denx.de>
On Mon, Mar 18, 2013 at 04:19:52PM +0100, Marek Vasut wrote:
> 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.
>
Thanks, Marek. Yeah, now I can see the problem and your patch does fix
it.
Shawn
> [1] ftp://ftp.denx.de/pub/eldk/5.3/targets/armv5te/core-image-sato-sdk-generic-
> armv5te.tar.gz
^ permalink raw reply
* Re: [PATCH v2] fbdev: sh_mobile_lcdc: fixup B side hsync adjust settings
From: Simon Horman @ 2013-03-19 4:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87txoqmo3p.wl%kuninori.morimoto.gx@renesas.com>
On Tue, Mar 05, 2013 at 04:45:46PM +0100, Laurent Pinchart wrote:
> Hi Morimoto-san,
>
> Thanks for the patch.
>
> On Monday 04 March 2013 21:07:10 Kuninori Morimoto wrote:
> > The lcdc B side horizon output is shifted
> > if sh_mobile_lcdc_pan() was called.
> > This patch fixup this issue.
> > It is tested on R8A7740 Armadillo800eva HDMI output.
> > Special thanks to Fukushima-san, and Sano-san
> >
> > Reported-by: Osamu Fukushima <osamu.fukushima.wr@renesas.com>
> > Signed-off-by: Hideyuki Sano <hideyuki.sano.dn@renesas.com>
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Laurent, can you handle getting this merged?
If not, please let me know who to prod.
>
> > ---
> > v1 -> v2
> >
> > - git log has tested SoC/board
> >
> > drivers/video/sh_mobile_lcdcfb.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/video/sh_mobile_lcdcfb.c
> > b/drivers/video/sh_mobile_lcdcfb.c index 63203ac..0264704 100644
> > --- a/drivers/video/sh_mobile_lcdcfb.c
> > +++ b/drivers/video/sh_mobile_lcdcfb.c
> > @@ -858,6 +858,7 @@ static void sh_mobile_lcdc_geometry(struct
> > sh_mobile_lcdc_chan *ch) tmp = ((mode->xres & 7) << 24) | ((display_h_total
> > & 7) << 16)
> >
> > | ((mode->hsync_len & 7) << 8) | (hsync_pos & 7);
> >
> > lcdc_write_chan(ch, LDHAJR, tmp);
> > + lcdc_write_chan_mirror(ch, LDHAJR, tmp);
> > }
> >
> > static void sh_mobile_lcdc_overlay_setup(struct sh_mobile_lcdc_overlay
> > *ovl)
>
> --
> Regards,
>
> Laurent Pinchart
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" 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] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Marek Vasut @ 2013-03-18 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130318220134.GC5062@elie.Belkin>
Hi Jonathan,
> Marek Vasut wrote:
> > - 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?
>
> Yes, please write again with a patch referencing the upstream commit
> id when this has been fixed upstream.
Roger that, will do. Is that all that needs repairing in the patch?
Thank you!
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Jonathan Nieder @ 2013-03-18 22:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201303182231.22749.marex@denx.de>
Marek Vasut wrote:
> - 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?
Yes, please write again with a patch referencing the upstream commit
id when this has been fixed upstream.
Thanks and hope that helps,
Jonathan
^ permalink raw reply
* 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
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