* 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
* [PATCH] ARM: video: mxs: Fix mxsfb misconfiguring VDCTRL0
From: Marek Vasut @ 2013-03-16 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CDuODRrJEEaDKm5nepfkuvuF77ZQmarB69hL6gg386ww@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 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(-)
NOTE: We ought to get rid of this platform data goo, but we can't do
it in here. This is a bugfix.
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: Shifted framebuffer after X11 starts on mx28
From: Marek Vasut @ 2013-03-16 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201303162155.28230.marex@denx.de>
Dear Marek Vasut,
> Dear Fabio Estevam,
>
> > Hi,
> >
> > I am running 3.8.2 kernel on a mx28evk and when I start X11 I get a
> > "shifted" framebuffer.
> >
> > The framebuffer works well if X11 is not called.
> >
> > There is no issue with X11 when running with Freescale 2.6.35 kernel.
> >
> > Looking at drivers/video/mxsfb.c there is the following comment:
> > /*
> >
> > * It seems, you can't re-program the controller if it is still running.
> > * This may lead into shifted pictures (FIFO issue?).
> > * So, first stop the controller and drain its FIFOs
> > */
> >
> > So, it looks like that I am still facing this issue when X11 starts.
> >
> > If anyone has any suggestions, please let me know.
>
> This is not it, I almost hunted the bug down. Hang on.
>
> Basically check mxsfb_set_par() and observe fb_info->var.sync . It's set to
> "something" during regular framebuffer operation and it's set to "something
> else" during Xorg operation. And that's what causes it to get broken. I
> forced fb_info->var.sync to the "something" value by hardcoding it in
> kernel just now for a quick test and X works for me.
Uh, being in hacking-mode and replying to email doesn't work well together :-)
In my case, fb_info->var.sync is set to FB_SYNC_DATA_ENABLE_HIGH_ACT during
regular operation (framebuffer console), but if X11 starts, this fb_info-
>var.sync is forced to value 0 which causes the malfunction. Now back into
hacking-mode ;-)
Best regards,
Marek Vasut
^ permalink raw reply
* Re: Shifted framebuffer after X11 starts on mx28
From: Marek Vasut @ 2013-03-16 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CDuODRrJEEaDKm5nepfkuvuF77ZQmarB69hL6gg386ww@mail.gmail.com>
Dear Fabio Estevam,
> Hi,
>
> I am running 3.8.2 kernel on a mx28evk and when I start X11 I get a
> "shifted" framebuffer.
>
> The framebuffer works well if X11 is not called.
>
> There is no issue with X11 when running with Freescale 2.6.35 kernel.
>
> Looking at drivers/video/mxsfb.c there is the following comment:
>
> /*
> * It seems, you can't re-program the controller if it is still running.
> * This may lead into shifted pictures (FIFO issue?).
> * So, first stop the controller and drain its FIFOs
> */
>
> So, it looks like that I am still facing this issue when X11 starts.
>
> If anyone has any suggestions, please let me know.
This is not it, I almost hunted the bug down. Hang on.
Basically check mxsfb_set_par() and observe fb_info->var.sync . It's set to
"something" during regular framebuffer operation and it's set to "something
else" during Xorg operation. And that's what causes it to get broken. I forced
fb_info->var.sync to the "something" value by hardcoding it in kernel just now
for a quick test and X works for me.
Best regards,
Marek Vasut
^ permalink raw reply
* Shifted framebuffer after X11 starts on mx28
From: Fabio Estevam @ 2013-03-16 20:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I am running 3.8.2 kernel on a mx28evk and when I start X11 I get a
"shifted" framebuffer.
The framebuffer works well if X11 is not called.
There is no issue with X11 when running with Freescale 2.6.35 kernel.
Looking at drivers/video/mxsfb.c there is the following comment:
/*
* It seems, you can't re-program the controller if it is still running.
* This may lead into shifted pictures (FIFO issue?).
* So, first stop the controller and drain its FIFOs
*/
So, it looks like that I am still facing this issue when X11 starts.
If anyone has any suggestions, please let me know.
Thanks,
Fabio Estevam
^ permalink raw reply
* [PATCH v2, part3 06/12] mm/acornfb: use common help functions to free reserved pages
From: Jiang Liu @ 2013-03-16 17:03 UTC (permalink / raw)
To: Andrew Morton, David Rientjes
Cc: Jiang Liu, Wen Congyang, Mel Gorman, Minchan Kim,
KAMEZAWA Hiroyuki, Michal Hocko, Jianguo Wu, linux-mm,
linux-kernel, linux-fbdev
In-Reply-To: <1363453413-8139-1-git-send-email-jiang.liu@huawei.com>
Use common help functions to free reserved pages.
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Cc: Florian Tobias Schandinat
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/video/acornfb.c | 28 ++--------------------------
1 file changed, 2 insertions(+), 26 deletions(-)
diff --git a/drivers/video/acornfb.c b/drivers/video/acornfb.c
index 6488a73..344f2bb 100644
--- a/drivers/video/acornfb.c
+++ b/drivers/video/acornfb.c
@@ -1188,32 +1188,8 @@ static int acornfb_detect_monitortype(void)
static inline void
free_unused_pages(unsigned int virtual_start, unsigned int virtual_end)
{
- int mb_freed = 0;
-
- /*
- * Align addresses
- */
- virtual_start = PAGE_ALIGN(virtual_start);
- virtual_end = PAGE_ALIGN(virtual_end);
-
- while (virtual_start < virtual_end) {
- struct page *page;
-
- /*
- * Clear page reserved bit,
- * set count to 1, and free
- * the page.
- */
- page = virt_to_page(virtual_start);
- ClearPageReserved(page);
- init_page_count(page);
- free_page(virtual_start);
-
- virtual_start += PAGE_SIZE;
- mb_freed += PAGE_SIZE / 1024;
- }
-
- printk("acornfb: freed %dK memory\n", mb_freed);
+ free_reserved_area(virtual_start, PAGE_ALIGN(virtual_end),
+ -1, "acornfb");
}
static int acornfb_probe(struct platform_device *dev)
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 1/3] backlight: ep93xx_bl: fix section mismatch
From: Ryan Mallon @ 2013-03-16 2:19 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: Linux Kernel, linux-fbdev, rpurdie, FlorianSchandinat
In-Reply-To: <201303151803.08774.hartleys@visionengravers.com>
On 16/03/13 12:03, H Hartley Sweeten wrote:
> Remove the __init tag from ep93xxbl_probe() to fix the section
> mismatch warning.
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Ryan Mallon <rmallon@gmail.com>
> Cc: Richard Purdie <rpurdie@rpsys.net>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
There is a patch for this already queued in Andrew Morton's tree.
~Ryan
> ---
> drivers/video/backlight/ep93xx_bl.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/ep93xx_bl.c b/drivers/video/backlight/ep93xx_bl.c
> index ef3e21e..17b8abb 100644
> --- a/drivers/video/backlight/ep93xx_bl.c
> +++ b/drivers/video/backlight/ep93xx_bl.c
> @@ -60,7 +60,7 @@ static const struct backlight_ops ep93xxbl_ops = {
> .get_brightness = ep93xxbl_get_brightness,
> };
>
> -static int __init ep93xxbl_probe(struct platform_device *dev)
> +static int ep93xxbl_probe(struct platform_device *dev)
> {
> struct ep93xxbl *ep93xxbl;
> struct backlight_device *bl;
> @@ -145,7 +145,6 @@ static struct platform_driver ep93xxbl_driver = {
> .suspend = ep93xxbl_suspend,
> .resume = ep93xxbl_resume,
> };
> -
> module_platform_driver(ep93xxbl_driver);
>
> MODULE_DESCRIPTION("EP93xx Backlight Driver");
^ permalink raw reply
* [PATCH 2/3] video: ep93xx-fb.c: fix section mismatch and use module_platform_driver
From: H Hartley Sweeten @ 2013-03-16 1:05 UTC (permalink / raw)
To: Linux Kernel; +Cc: linux-fbdev, Ryan Mallon, FlorianSchandinat
Remove the __init tags from the ep93xxfb_calc_fbsize() and
ep93xxfb_alloc_videomem() functions to fix the section mismatch
warnings.
Use module_platform_driver() to remove the init/exit boilerplate.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ryan Mallon <rmallon@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/ep93xx-fb.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/video/ep93xx-fb.c b/drivers/video/ep93xx-fb.c
index e06cd5d..ee1ee54 100644
--- a/drivers/video/ep93xx-fb.c
+++ b/drivers/video/ep93xx-fb.c
@@ -419,7 +419,7 @@ static struct fb_ops ep93xxfb_ops = {
.fb_mmap = ep93xxfb_mmap,
};
-static int __init ep93xxfb_calc_fbsize(struct ep93xxfb_mach_info *mach_info)
+static int ep93xxfb_calc_fbsize(struct ep93xxfb_mach_info *mach_info)
{
int i, fb_size = 0;
@@ -441,7 +441,7 @@ static int __init ep93xxfb_calc_fbsize(struct ep93xxfb_mach_info *mach_info)
return fb_size;
}
-static int __init ep93xxfb_alloc_videomem(struct fb_info *info)
+static int ep93xxfb_alloc_videomem(struct fb_info *info)
{
struct ep93xx_fbi *fbi = info->par;
char __iomem *virt_addr;
@@ -627,19 +627,7 @@ static struct platform_driver ep93xxfb_driver = {
.owner = THIS_MODULE,
},
};
-
-static int ep93xxfb_init(void)
-{
- return platform_driver_register(&ep93xxfb_driver);
-}
-
-static void __exit ep93xxfb_exit(void)
-{
- platform_driver_unregister(&ep93xxfb_driver);
-}
-
-module_init(ep93xxfb_init);
-module_exit(ep93xxfb_exit);
+module_platform_driver(ep93xxfb_driver);
MODULE_DESCRIPTION("EP93XX Framebuffer Driver");
MODULE_ALIAS("platform:ep93xx-fb");
--
1.8.1.4
^ permalink raw reply related
* [PATCH 1/3] backlight: ep93xx_bl: fix section mismatch
From: H Hartley Sweeten @ 2013-03-16 1:03 UTC (permalink / raw)
To: Linux Kernel; +Cc: linux-fbdev, Ryan Mallon, rpurdie, FlorianSchandinat
Remove the __init tag from ep93xxbl_probe() to fix the section
mismatch warning.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ryan Mallon <rmallon@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/backlight/ep93xx_bl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/backlight/ep93xx_bl.c b/drivers/video/backlight/ep93xx_bl.c
index ef3e21e..17b8abb 100644
--- a/drivers/video/backlight/ep93xx_bl.c
+++ b/drivers/video/backlight/ep93xx_bl.c
@@ -60,7 +60,7 @@ static const struct backlight_ops ep93xxbl_ops = {
.get_brightness = ep93xxbl_get_brightness,
};
-static int __init ep93xxbl_probe(struct platform_device *dev)
+static int ep93xxbl_probe(struct platform_device *dev)
{
struct ep93xxbl *ep93xxbl;
struct backlight_device *bl;
@@ -145,7 +145,6 @@ static struct platform_driver ep93xxbl_driver = {
.suspend = ep93xxbl_suspend,
.resume = ep93xxbl_resume,
};
-
module_platform_driver(ep93xxbl_driver);
MODULE_DESCRIPTION("EP93xx Backlight Driver");
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH] video: ep93xx_fb: include <linux/io.h> for devm_ioremap()
From: Ryan Mallon @ 2013-03-15 22:30 UTC (permalink / raw)
To: H Hartley Sweeten
Cc: linux-kernel, linux-fbdev, stable, FlorianSchandinat,
damien.cassou
In-Reply-To: <201303151520.26873.hartleys@visionengravers.com>
On 16/03/13 09:20, H Hartley Sweeten wrote:
> commit be867814 "drivers/video/ep93xx-fb.c: use devm_ functions"
>
> Introduced a build error:
>
> drivers/video/ep93xx-fb.c: In function 'ep93xxfb_probe':
> drivers/video/ep93xx-fb.c:532: error: implicit declaration of function 'devm_ioremap'
> drivers/video/ep93xx-fb.c:533: warning: assignment makes pointer from integer without a cast
>
> Include <linux/io.h> to pickup the declaration of 'devm_ioremap'.
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: <stable@vger.kernel.org>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: Ryan Mallon <rmallon@gmail.com>
> Cc: Damien Cassou <damien.cassou@lifl.fr>
Acked-by: Ryan Mallon <rmallon@gmail.com>
> ---
> drivers/video/ep93xx-fb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/ep93xx-fb.c b/drivers/video/ep93xx-fb.c
> index 3f2519d..e06cd5d 100644
> --- a/drivers/video/ep93xx-fb.c
> +++ b/drivers/video/ep93xx-fb.c
> @@ -23,6 +23,7 @@
> #include <linux/slab.h>
> #include <linux/clk.h>
> #include <linux/fb.h>
> +#include <linux/io.h>
>
> #include <linux/platform_data/video-ep93xx.h>
>
^ 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