* [GIT PULL] OMAP DSS for v3.5-rc2
From: Tomi Valkeinen @ 2012-06-05 15:11 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-omap, linux-fbdev, Archit Taneja
[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]
Hi Florian,
Here are 5 small fixes for omapdss. The most important is the "fix
registration..." patch, without which omapdss crashes when
suspending/resuming. The compilation bug ("fix build...") is also rather
annoying for those users not interested in debug outputs. The rest are
quite minor small fixes.
It'd be great if these made it in for -rc2, as the crash bug is quite
bad, but -rc3 is good also.
Tomi
The following changes since commit e92a5b28f71aea01b281f9c89d97a4bc5b24748f:
OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request (2012-05-22 11:00:09 +0300)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.5-rc2
for you to fetch changes up to c3a21fc79b6bc097d8b0e47498903a649a111127:
OMAPDSS: fix registration of DPI and SDI devices (2012-06-05 17:15:24 +0300)
----------------------------------------------------------------
Small fixes for omapdss driver. Most importantly, fixes a build problem when
debugfs or omapdss debug support is turned off, and fixes a suspend related
crash.
----------------------------------------------------------------
Archit Taneja (1):
OMAPDSS: DSI: Fix bug when calculating LP command interleaving parameters
Tomi Valkeinen (4):
OMAPDSS: fix build when DEBUG_FS or DSS_DEBUG_SUPPORT disabled
OMAPDSS: Taal: fix compilation warning
OMAPDSS: fix bogus WARN_ON in dss_runtime_put()
OMAPDSS: fix registration of DPI and SDI devices
arch/arm/mach-omap2/display.c | 4 ++--
drivers/video/omap2/displays/panel-taal.c | 2 +-
drivers/video/omap2/dss/core.c | 3 +--
drivers/video/omap2/dss/dsi.c | 2 +-
drivers/video/omap2/dss/dss.c | 2 +-
5 files changed, 6 insertions(+), 7 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Circular locking (and possible deadlock), when exiting from mplayer -vo fbdev2
From: Witold Baryluk @ 2012-06-05 17:18 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20120604173702.GZ16584@smp.if.uj.edu.pl>
On 06-05 17:10, Dan Carpenter wrote:
> My patch can't cause this. I'd be surprised if my patch has any
> effect beyond silencing a static checker warning, honestly.
>
Yes, you are right. Your patch cannot be cause of it. Sorry for
confusion.
> I'm not sure this is a new bug.
>
Indeed, last time I used mplayer -vo fbdev2 was years ago, so bug could
appear anywhere in this period, or it is a more a matter of my
configuration.
> The problem is we hold ->mmap_sem when we call fb_release() which
> takes the info->lock.
>
> We take the info->lock in do_fb_ioctl() before we call fb_set_var()
> which calls drm_fb_helper_set_par() which takes the
> mode_config.mutex.
>
> In drm_mode_getresources() we take the mode_config.mutex() and call
> put_user() which takes the ->mmap_sem.
>
> So on one CPU we are holding the ->mmap_sem and want the info->lock.
> On another CPU we are holding the info->lock and want the
> config.mutex. On the other CPU we hold the config.mutex and want
> the ->mmap_sem.
>
> Deadlock.
Temporary solution would be to break a cycle, and for example take
info->lock first on first processor before taking ->mmap_sem and calling
fb_release - it is just fb release, so performance doesn't matter so
much. Other possibility is to protect this code paths by separate common
lock, but it will increase memory and make it slower probably in this
function and other ones. I do not know which subsystems use
drm_mode_getresources, and if this is important performance wise.
There is probably other possibilities, but only fbdev people can tell
which is best.
>
> I'm not sure how to make this work with just two CPUs... Or how to
> fix it. But I'm going to disclaim all responsibility and hope the
> fbdev people can take a look. ;)
>
> regards,
> dan carpenter
>
thanks for analysis,
Regards,
Witek
--
Witold Baryluk
^ permalink raw reply
* Re: Circular locking (and possible deadlock), when exiting from mplayer -vo fbdev2
From: Florian Tobias Schandinat @ 2012-06-05 18:37 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20120604173702.GZ16584@smp.if.uj.edu.pl>
Hi,
On 06/05/2012 05:18 PM, Witold Baryluk wrote:
> On 06-05 17:10, Dan Carpenter wrote:
>> My patch can't cause this. I'd be surprised if my patch has any
>> effect beyond silencing a static checker warning, honestly.
>>
>
> Yes, you are right. Your patch cannot be cause of it. Sorry for
> confusion.
>
>> I'm not sure this is a new bug.
>>
>
> Indeed, last time I used mplayer -vo fbdev2 was years ago, so bug could
> appear anywhere in this period, or it is a more a matter of my
> configuration.
>
>> The problem is we hold ->mmap_sem when we call fb_release() which
>> takes the info->lock.
>>
>> We take the info->lock in do_fb_ioctl() before we call fb_set_var()
>> which calls drm_fb_helper_set_par() which takes the
>> mode_config.mutex.
>>
>> In drm_mode_getresources() we take the mode_config.mutex() and call
>> put_user() which takes the ->mmap_sem.
>>
>> So on one CPU we are holding the ->mmap_sem and want the info->lock.
>> On another CPU we are holding the info->lock and want the
>> config.mutex. On the other CPU we hold the config.mutex and want
>> the ->mmap_sem.
>>
>> Deadlock.
>
> Temporary solution would be to break a cycle, and for example take
> info->lock first on first processor before taking ->mmap_sem and calling
> fb_release - it is just fb release, so performance doesn't matter so
> much. Other possibility is to protect this code paths by separate common
> lock, but it will increase memory and make it slower probably in this
> function and other ones. I do not know which subsystems use
> drm_mode_getresources, and if this is important performance wise.
>
> There is probably other possibilities, but only fbdev people can tell
> which is best.
That's not true. This is the wrong mailing list as this happens only
with DRM-based framebuffers (in drivers/gpu/drm/ not drivers/video/) and
therefore you should resend your initial mail to
dri-devel@lists.freedesktop.org.
Best regards,
Florian Tobias Schandinat
>>
>> I'm not sure how to make this work with just two CPUs... Or how to
>> fix it. But I'm going to disclaim all responsibility and hope the
>> fbdev people can take a look. ;)
>>
>> regards,
>> dan carpenter
>>
>
>
> thanks for analysis,
>
> Regards,
> Witek
>
^ permalink raw reply
* Re: [PATCH] mbxfb: unbreak compilation with CONFIG_FB_MBX_DEBUG
From: Florian Tobias Schandinat @ 2012-06-05 19:15 UTC (permalink / raw)
To: tartler
Cc: Eric Miao, Arnd Bergmann, linux-fbdev, linux-kernel, vamos-dev,
Reinhard Tartler
In-Reply-To: <1337013111-7732-1-git-send-email-tartler@cs.fau.de>
Hi,
On 05/14/2012 04:31 PM, tartler@cs.fau.de wrote:
> From: Reinhard Tartler <siretart@tauware.de>
>
> This patch adds missing function prototypes.
>
> Signed-off-by: Reinhard Tartler <tartler@cs.fau.de>
> ---
> drivers/video/mbx/mbxfb.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> This patch was found with tools developed in the VAMOS project:
> http://www4.cs.fau.de/Research/VAMOS/
>
> TBH, I'm not sure if this is the correct solution. However, I'd
> appreciate if someone could confirm that this is a real bug.
>
>
> diff --git a/drivers/video/mbx/mbxfb.c b/drivers/video/mbx/mbxfb.c
> index 6ce3416..c2200ec 100644
> --- a/drivers/video/mbx/mbxfb.c
> +++ b/drivers/video/mbx/mbxfb.c
> @@ -878,6 +878,9 @@ static int mbxfb_resume(struct platform_device *dev)
> #ifndef CONFIG_FB_MBX_DEBUG
> #define mbxfb_debugfs_init(x) do {} while(0)
> #define mbxfb_debugfs_remove(x) do {} while(0)
> +#else
> +void mbxfb_debugfs_init(struct fb_info *fbi);
> +void mbxfb_debugfs_remove(struct fb_info *fbi);
I don't agree. checkpatch complains
WARNING: externs should be avoided in .c files
#71: FILE: drivers/video/mbx/mbxfb.c:882:
+void mbxfb_debugfs_init(struct fb_info *fbi);
And in drivers/video/mbx/mbxdebugfs.c
static void __devinit mbxfb_debugfs_init(struct fb_info *fbi)
static void __devexit mbxfb_debugfs_remove(struct fb_info *fbi)
So even if you want to ignore the checkpatch warning (which I could
understand for just 2 includes even if headers are certainly better)
you'd have to remove the static at the implementation and for
consistency include the __devinit/exit in your prototypes.
> #endif
>
> #define res_size(_r) (((_r)->end - (_r)->start) + 1)
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH] mbxfb: unbreak compilation with CONFIG_FB_MBX_DEBUG
From: Eric Miao @ 2012-06-05 20:54 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: tartler, Arnd Bergmann, linux-fbdev, linux-kernel, vamos-dev,
Reinhard Tartler
In-Reply-To: <4FCE5AD1.6040705@gmx.de>
On Wed, Jun 6, 2012 at 3:15 AM, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> Hi,
>
> On 05/14/2012 04:31 PM, tartler@cs.fau.de wrote:
>> From: Reinhard Tartler <siretart@tauware.de>
>>
>> This patch adds missing function prototypes.
>>
>> Signed-off-by: Reinhard Tartler <tartler@cs.fau.de>
>> ---
>> drivers/video/mbx/mbxfb.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> This patch was found with tools developed in the VAMOS project:
>> http://www4.cs.fau.de/Research/VAMOS/
>>
>> TBH, I'm not sure if this is the correct solution. However, I'd
>> appreciate if someone could confirm that this is a real bug.
>>
>>
>> diff --git a/drivers/video/mbx/mbxfb.c b/drivers/video/mbx/mbxfb.c
>> index 6ce3416..c2200ec 100644
>> --- a/drivers/video/mbx/mbxfb.c
>> +++ b/drivers/video/mbx/mbxfb.c
>> @@ -878,6 +878,9 @@ static int mbxfb_resume(struct platform_device *dev)
>> #ifndef CONFIG_FB_MBX_DEBUG
>> #define mbxfb_debugfs_init(x) do {} while(0)
>> #define mbxfb_debugfs_remove(x) do {} while(0)
>> +#else
>> +void mbxfb_debugfs_init(struct fb_info *fbi);
>> +void mbxfb_debugfs_remove(struct fb_info *fbi);
>
> I don't agree. checkpatch complains
> WARNING: externs should be avoided in .c files
> #71: FILE: drivers/video/mbx/mbxfb.c:882:
> +void mbxfb_debugfs_init(struct fb_info *fbi);
>
> And in drivers/video/mbx/mbxdebugfs.c
> static void __devinit mbxfb_debugfs_init(struct fb_info *fbi)
> static void __devexit mbxfb_debugfs_remove(struct fb_info *fbi)
>
> So even if you want to ignore the checkpatch warning (which I could
> understand for just 2 includes even if headers are certainly better)
> you'd have to remove the static at the implementation and for
> consistency include the __devinit/exit in your prototypes.
That actually made a very good point, and I seriously doubt whether the
mbxfb_debugfs_* thing has ever been tested. Instead of making them
public, I see a chance maybe we could remove them completely instead.
>
>> #endif
>>
>> #define res_size(_r) (((_r)->end - (_r)->start) + 1)
>
>
> Best regards,
>
> Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH 1/1] mx3fb: support pan display with fb_set_var
From: Liu Ying @ 2012-06-06 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1338351267-25561-1-git-send-email-Ying.Liu@freescale.com>
2012/5/30, Liu Ying <Ying.Liu@freescale.com>:
> Users may call FBIOPUT_VSCREENINFO ioctrl to do pan display.
> This ioctrl relies on fb_set_var() to do the job. fb_set_var()
> calls custom fb_set_par() method and then calls custom
> fb_pan_display() method. The current implementation of mx3fb
> reinitializes IPU display controller every time the custom
> fb_set_par() method is called, which makes the display flash
> if fb_set_var() is called to do panning frequently. The custom
> fb_pan_display() method checks if the current xoffset and
> yoffset are different from previous ones before doing actual
> panning, which prevents the panning from happening within the
> fb_set_var() context. This patch checks new var info to decide
> whether we really need to reinitialize IPU display controller.
> We ignore xoffset and yoffset update because it doesn't require
> to reinitialize the controller. Users may specify activate field
> of var info with FB_ACTIVATE_NOW and FB_ACTIVATE_FORCE to
> reinialize the controller by force. Meanwhile, this patch removes
> the check in custom fb_pan_display() method mentioned before to
> have the panning work within fb_set_var() context. It doesn't
> hurt to do panning again if there is no update for xoffset and
> yoffset.
>
> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
> ---
> drivers/video/mx3fb.c | 31 +++++++++++++++++++++++++++----
> 1 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> index e3406ab..86daabe 100644
> --- a/drivers/video/mx3fb.c
> +++ b/drivers/video/mx3fb.c
> @@ -269,6 +269,8 @@ struct mx3fb_info {
> struct scatterlist sg[2];
>
> u32 sync; /* preserve var->sync flags */
> +
> + struct fb_var_screeninfo cur_var; /* current var info */
> };
>
> static void mx3fb_dma_done(void *);
> @@ -721,6 +723,26 @@ static void mx3fb_dma_done(void *arg)
> complete(&mx3_fbi->flip_cmpl);
> }
>
> +static bool fb_need_not_to_set_par(struct fb_info *fbi)
> +{
> + struct mx3fb_info *mx3_fbi = fbi->par;
> + struct fb_var_screeninfo old_var = mx3_fbi->cur_var;
> + struct fb_var_screeninfo new_var = fbi->var;
> +
> + if ((fbi->var.activate & FB_ACTIVATE_FORCE) &&
> + (fbi->var.activate & FB_ACTIVATE_MASK) = FB_ACTIVATE_NOW)
> + return false;
> +
> + /*
> + * Ignore xoffset and yoffset update,
> + * because pan display handles this case.
> + */
> + old_var.xoffset = new_var.xoffset;
> + old_var.yoffset = new_var.yoffset;
> +
> + return !memcmp(&old_var, &new_var, sizeof(struct fb_var_screeninfo));
> +}
> +
> static int __set_par(struct fb_info *fbi, bool lock)
> {
> u32 mem_len;
> @@ -732,6 +754,9 @@ static int __set_par(struct fb_info *fbi, bool lock)
> struct idmac_video_param *video = &ichan->params.video;
> struct scatterlist *sg = mx3_fbi->sg;
>
> + if (fb_need_not_to_set_par(fbi))
> + return 0;
> +
> /* Total cleanup */
> if (mx3_fbi->txd)
> sdc_disable_channel(mx3_fbi);
> @@ -808,6 +833,8 @@ static int __set_par(struct fb_info *fbi, bool lock)
> if (mx3_fbi->blank = FB_BLANK_UNBLANK)
> sdc_enable_channel(mx3_fbi);
>
> + mx3_fbi->cur_var = fbi->var;
> +
> return 0;
> }
>
> @@ -1068,10 +1095,6 @@ static int mx3fb_pan_display(struct fb_var_screeninfo
> *var,
> return -EINVAL;
> }
>
> - if (fbi->var.xoffset = var->xoffset &&
> - fbi->var.yoffset = var->yoffset)
> - return 0; /* No change, do nothing */
> -
> y_bottom = var->yoffset;
>
> if (!(var->vmode & FB_VMODE_YWRAP))
> --
> 1.7.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
The patch is present here for a period of time.
Can someone help to review this?
Thanks.
--
Best Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH 1/1] mx3fb: support pan display with fb_set_var
From: Guennadi Liakhovetski @ 2012-06-06 15:54 UTC (permalink / raw)
To: Liu Ying; +Cc: FlorianSchandinat, linux-fbdev, linux-kernel
In-Reply-To: <1338352042-26522-1-git-send-email-Ying.Liu@freescale.com>
On Wed, 30 May 2012, Liu Ying wrote:
> Users may call FBIOPUT_VSCREENINFO ioctrl to do pan display.
> This ioctrl relies on fb_set_var() to do the job. fb_set_var()
> calls custom fb_set_par() method and then calls custom
> fb_pan_display() method. The current implementation of mx3fb
> reinitializes IPU display controller every time the custom
> fb_set_par() method is called, which makes the display flash
> if fb_set_var() is called to do panning frequently. The custom
> fb_pan_display() method checks if the current xoffset and
> yoffset are different from previous ones before doing actual
> panning, which prevents the panning from happening within the
> fb_set_var() context. This patch checks new var info to decide
> whether we really need to reinitialize IPU display controller.
> We ignore xoffset and yoffset update because it doesn't require
> to reinitialize the controller. Users may specify activate field
> of var info with FB_ACTIVATE_NOW and FB_ACTIVATE_FORCE to
> reinialize the controller by force. Meanwhile, this patch removes
> the check in custom fb_pan_display() method mentioned before to
> have the panning work within fb_set_var() context. It doesn't
> hurt to do panning again if there is no update for xoffset and
> yoffset.
You are really addressing 2 separate problems here: (1) panning cannot be
set using FBIOPUT_VSCREENINFO and (2) screen flashes every time
fb_set_var() is called, even if only panning is required. The reason for
the first one is, that in fb_set_var() info->var is already updated from
the new *var when fb_pan_display() is called. So, as you correctly
identified, the condition
if (fbi->var.xoffset = var->xoffset &&
fbi->var.yoffset = var->yoffset)
return 0; /* No change, do nothing */
is trivially met and no panning takes place. Instead, you can use your
idea to cache var_info locally and check against that one to see, whether
offsets have changed, instead of removing that check completely.
To solve the second problem you can use your check against the cached copy
of var_info. See below for more details.
>
> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
> ---
> drivers/video/mx3fb.c | 31 +++++++++++++++++++++++++++----
> 1 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> index e3406ab..238b9aa 100644
> --- a/drivers/video/mx3fb.c
> +++ b/drivers/video/mx3fb.c
> @@ -269,6 +269,8 @@ struct mx3fb_info {
> struct scatterlist sg[2];
>
> u32 sync; /* preserve var->sync flags */
An incremental patch could then also remove the above .sync member and
switch to using .cur_var.sync instead.
> +
> + struct fb_var_screeninfo cur_var; /* current var info */
> };
>
> static void mx3fb_dma_done(void *);
> @@ -721,6 +723,26 @@ static void mx3fb_dma_done(void *arg)
> complete(&mx3_fbi->flip_cmpl);
> }
>
> +static bool mx3fb_need_not_to_set_par(struct fb_info *fbi)
How about inverting logic and calling the function
mx3fb_must_update_par()?
> +{
> + struct mx3fb_info *mx3_fbi = fbi->par;
> + struct fb_var_screeninfo old_var = mx3_fbi->cur_var;
> + struct fb_var_screeninfo new_var = fbi->var;
> +
> + if ((fbi->var.activate & FB_ACTIVATE_FORCE) &&
> + (fbi->var.activate & FB_ACTIVATE_MASK) = FB_ACTIVATE_NOW)
> + return false;
> +
> + /*
> + * Ignore xoffset and yoffset update,
> + * because pan display handles this case.
> + */
> + old_var.xoffset = new_var.xoffset;
> + old_var.yoffset = new_var.yoffset;
> +
> + return !memcmp(&old_var, &new_var, sizeof(struct fb_var_screeninfo));
> +}
> +
> static int __set_par(struct fb_info *fbi, bool lock)
> {
> u32 mem_len;
> @@ -732,6 +754,9 @@ static int __set_par(struct fb_info *fbi, bool lock)
> struct idmac_video_param *video = &ichan->params.video;
> struct scatterlist *sg = mx3_fbi->sg;
>
> + if (mx3fb_need_not_to_set_par(fbi))
> + return 0;
> +
__set_par() is called from 2 locations: from mx3fb_set_par() and
init_fb_chan(), called from probing. You don't need to perform the above
check in init_fb_chan() - there you always have to configure. Maybe better
put it in mx3fb_set_par() just before calling __set_par() like
ret = mx3fb_must_set_par() ? __set_par() : 0;
As mentioned above, this solves problem #2 and should go into patch #2.
> /* Total cleanup */
> if (mx3_fbi->txd)
> sdc_disable_channel(mx3_fbi);
> @@ -808,6 +833,8 @@ static int __set_par(struct fb_info *fbi, bool lock)
> if (mx3_fbi->blank = FB_BLANK_UNBLANK)
> sdc_enable_channel(mx3_fbi);
>
> + mx3_fbi->cur_var = fbi->var;
> +
Yes, but preserve xoffset and yoffset - you don't apply them yet in
__set_par().
> return 0;
> }
>
> @@ -1068,10 +1095,6 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
> return -EINVAL;
> }
>
> - if (fbi->var.xoffset = var->xoffset &&
> - fbi->var.yoffset = var->yoffset)
> - return 0; /* No change, do nothing */
> -
I think, it would be better not to remove these completely, but check
against cached .cur_var, and then update those values too.
> y_bottom = var->yoffset;
>
> if (!(var->vmode & FB_VMODE_YWRAP))
> --
> 1.7.1
Makes sense? Or have I misunderstood something?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 0/6] drivers: randconfig patches for kernel 3.5
From: Arnd Bergmann @ 2012-06-09 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1339194280-27475-1-git-send-email-mathieu.poirier@linaro.org>
On Friday 08 June 2012, mathieu.poirier@linaro.org wrote:
> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> These patches fix miscellaneous problems when working
> with make randconfig. They were discovered on kernel
> 3.1-rc4 and sent out during the 3.4 cycle but were not
> ack'ed.
>
> Sending out again for completeness.
Hi Mathieu,
I just realized that most of these are for the same subsystem
(framebuffer), so you should have kept the respective mailing list
and maintainer on Cc (added now).
The mg_disk driver is not listed in the MAINTAINERS file but
has an author email listed in the file itself.
I can take the mg_disk patch into the arm-soc tree as a fix,
but I'd prefer the other patches to go through the framebuffer
tree.
Arnd
> Arnd Bergmann (6):
> drivers/video: use correct __devexit_p annotation
> mg_disk: use readb/writeb instead of inb/outb
> video/ili9320: do not mark exported functions __devexit
> video/console: automatically select a font
> drivers/savagefb: use mdelay instead of udelay
> drivers/tosa: driver needs I2C and SPI to compile
>
> drivers/block/mg_disk.c | 78 ++++++++++++++++----------------
> drivers/video/backlight/Kconfig | 2 +-
> drivers/video/backlight/ili9320.c | 2 +-
> drivers/video/broadsheetfb.c | 2 +-
> drivers/video/console/Kconfig | 14 ++++++
> drivers/video/mbx/mbxfb.c | 2 +-
> drivers/video/savage/savagefb_driver.c | 10 ++--
> 7 files changed, 62 insertions(+), 48 deletions(-)
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS for v3.5-rc2
From: Florian Tobias Schandinat @ 2012-06-09 12:39 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1338909099.4456.13.camel@deskari>
Hi Tomi,
On 06/05/2012 03:11 PM, Tomi Valkeinen wrote:
> Hi Florian,
>
> Here are 5 small fixes for omapdss. The most important is the "fix
> registration..." patch, without which omapdss crashes when
> suspending/resuming. The compilation bug ("fix build...") is also rather
> annoying for those users not interested in debug outputs. The rest are
> quite minor small fixes.
>
> It'd be great if these made it in for -rc2, as the crash bug is quite
> bad, but -rc3 is good also.
I merged this some days ago. Sorry that I didn't realize that rc2 would
be released early and hence didn't manage to get it in.
Best regards,
Florian Tobias Schandinat
>
> Tomi
>
>
> The following changes since commit e92a5b28f71aea01b281f9c89d97a4bc5b24748f:
>
> OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request (2012-05-22 11:00:09 +0300)
>
> are available in the git repository at:
>
> git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.5-rc2
>
> for you to fetch changes up to c3a21fc79b6bc097d8b0e47498903a649a111127:
>
> OMAPDSS: fix registration of DPI and SDI devices (2012-06-05 17:15:24 +0300)
>
> ----------------------------------------------------------------
> Small fixes for omapdss driver. Most importantly, fixes a build problem when
> debugfs or omapdss debug support is turned off, and fixes a suspend related
> crash.
>
> ----------------------------------------------------------------
> Archit Taneja (1):
> OMAPDSS: DSI: Fix bug when calculating LP command interleaving parameters
>
> Tomi Valkeinen (4):
> OMAPDSS: fix build when DEBUG_FS or DSS_DEBUG_SUPPORT disabled
> OMAPDSS: Taal: fix compilation warning
> OMAPDSS: fix bogus WARN_ON in dss_runtime_put()
> OMAPDSS: fix registration of DPI and SDI devices
>
> arch/arm/mach-omap2/display.c | 4 ++--
> drivers/video/omap2/displays/panel-taal.c | 2 +-
> drivers/video/omap2/dss/core.c | 3 +--
> drivers/video/omap2/dss/dsi.c | 2 +-
> drivers/video/omap2/dss/dss.c | 2 +-
> 5 files changed, 6 insertions(+), 7 deletions(-)
>
^ permalink raw reply
* Re: [PATCH] video: bfin_adv7393fb: Convert to kstrtouint_from_user
From: Florian Tobias Schandinat @ 2012-06-09 12:41 UTC (permalink / raw)
To: Emil Goode; +Cc: linux-fbdev, linux-kernel, kernel-janitors
In-Reply-To: <1338310620-6886-1-git-send-email-emilgoode@gmail.com>
On 05/29/2012 04:57 PM, Emil Goode wrote:
> This patch removes a call to the deprecated simple_strtoul function
> and simplifies the code by replacing two function calls with one
> call to kstrtouint_from_user.
>
> -Simplify the adv7393_write_proc function by replacing the
> simple_strtoul and copy_from_user calls with one call
> to kstrtouint_from_user.
>
> -Change the count parameter from unsigned long to size_t as
> this is the type that the kstrtouint_from_user function expects.
> (size_t is what will be passed to the adv7393_write_proc function
> by the proc write handler function proc_file_write anyway)
>
> Signed-off-by: Emil Goode <emilgoode@gmail.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/bfin_adv7393fb.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/bfin_adv7393fb.c b/drivers/video/bfin_adv7393fb.c
> index 1a268a2..8c6edfd 100644
> --- a/drivers/video/bfin_adv7393fb.c
> +++ b/drivers/video/bfin_adv7393fb.c
> @@ -353,18 +353,16 @@ adv7393_read_proc(char *page, char **start, off_t off,
>
> static int
> adv7393_write_proc(struct file *file, const char __user * buffer,
> - unsigned long count, void *data)
> + size_t count, void *data)
> {
> struct adv7393fb_device *fbdev = data;
> - char line[8];
> unsigned int val;
> int ret;
>
> - ret = copy_from_user(line, buffer, count);
> + ret = kstrtouint_from_user(buffer, count, 0, &val);
> if (ret)
> return -EFAULT;
>
> - val = simple_strtoul(line, NULL, 0);
> adv7393_write(fbdev->client, val >> 8, val & 0xff);
>
> return count;
^ permalink raw reply
* Re: [PATCH 0/6] drivers: randconfig patches for kernel 3.5
From: Florian Tobias Schandinat @ 2012-06-09 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201206090013.27149.arnd@arndb.de>
Hi Arnd, Mathieu,
On 06/09/2012 12:13 AM, Arnd Bergmann wrote:
> On Friday 08 June 2012, mathieu.poirier@linaro.org wrote:
>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>
>> These patches fix miscellaneous problems when working
>> with make randconfig. They were discovered on kernel
>> 3.1-rc4 and sent out during the 3.4 cycle but were not
>> ack'ed.
>>
>> Sending out again for completeness.
>
> Hi Mathieu,
>
> I just realized that most of these are for the same subsystem
> (framebuffer), so you should have kept the respective mailing list
> and maintainer on Cc (added now).
>
> The mg_disk driver is not listed in the MAINTAINERS file but
> has an author email listed in the file itself.
>
> I can take the mg_disk patch into the arm-soc tree as a fix,
> but I'd prefer the other patches to go through the framebuffer
> tree.
Applied all (including the backlight patches which are usually handled
by Andrew Morton) but the mg_disk patch.
Thanks,
Florian Tobias Schandinat
>
> Arnd
>
>> Arnd Bergmann (6):
>> drivers/video: use correct __devexit_p annotation
>> mg_disk: use readb/writeb instead of inb/outb
>> video/ili9320: do not mark exported functions __devexit
>> video/console: automatically select a font
>> drivers/savagefb: use mdelay instead of udelay
>> drivers/tosa: driver needs I2C and SPI to compile
>>
>> drivers/block/mg_disk.c | 78 ++++++++++++++++----------------
>> drivers/video/backlight/Kconfig | 2 +-
>> drivers/video/backlight/ili9320.c | 2 +-
>> drivers/video/broadsheetfb.c | 2 +-
>> drivers/video/console/Kconfig | 14 ++++++
>> drivers/video/mbx/mbxfb.c | 2 +-
>> drivers/video/savage/savagefb_driver.c | 10 ++--
>> 7 files changed, 62 insertions(+), 48 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 0/6] drivers: randconfig patches for kernel 3.5
From: Arnd Bergmann @ 2012-06-09 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4FD3482B.5050004@gmx.de>
On Saturday 09 June 2012, Florian Tobias Schandinat wrote:
> >
> > I just realized that most of these are for the same subsystem
> > (framebuffer), so you should have kept the respective mailing list
> > and maintainer on Cc (added now).
> >
> > The mg_disk driver is not listed in the MAINTAINERS file but
> > has an author email listed in the file itself.
> >
> > I can take the mg_disk patch into the arm-soc tree as a fix,
> > but I'd prefer the other patches to go through the framebuffer
> > tree.
>
> Applied all (including the backlight patches which are usually handled
> by Andrew Morton) but the mg_disk patch.
Ok, Thanks a lot!
Arnd
^ permalink raw reply
* [PATCH 1/3] mx3fb: do not support panning with fb blanked
From: Liu Ying @ 2012-06-11 1:06 UTC (permalink / raw)
To: linux-arm-kernel
This patch checks if framebuffer is unblanked before
we actually trigger panning in custom pan display
function.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
drivers/video/mx3fb.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index e3406ab..d53db60 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -1063,6 +1063,11 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
dev_dbg(fbi->device, "%s [%c]\n", __func__,
list_empty(&mx3_fbi->idmac_channel->queue) ? '-' : '+');
+ if (mx3_fbi->blank != FB_BLANK_UNBLANK) {
+ dev_dbg(fbi->device, "panning with fb blanked not supported\n");
+ return -EFAULT;
+ }
+
if (var->xoffset > 0) {
dev_dbg(fbi->device, "x panning not supported\n");
return -EINVAL;
--
1.7.1
^ permalink raw reply related
* [PATCH 2/3] mx3fb: support pan display with fb_set_var
From: Liu Ying @ 2012-06-11 1:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1339376810-8247-1-git-send-email-Ying.Liu@freescale.com>
Users may call FBIOPUT_VSCREENINFO ioctrl to do pan display.
This ioctrl relies on fb_set_var() to do the job. fb_set_var()
calls the custom fb_set_par() method and then calls the custom
fb_pan_display() method. Before calling the custom fb_pan_display()
method, info->var is already updated from the new *var in fb_set_var().
And, the custom fb_pan_display() method checks if xoffset and yoffset
in info->var and the new *var are different before doing actual panning,
which prevents the panning from happening within fb_set_var() context.
This patch caches the current var info locally in mx3fb driver so that
pan display with fb_set_var is supported.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
drivers/video/mx3fb.c | 33 ++++++++++++++++++++++++++-------
1 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index d53db60..2dd11c4 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -268,7 +268,7 @@ struct mx3fb_info {
dma_cookie_t cookie;
struct scatterlist sg[2];
- u32 sync; /* preserve var->sync flags */
+ struct fb_var_screeninfo cur_var; /* current var info */
};
static void mx3fb_dma_done(void *);
@@ -723,7 +723,7 @@ static void mx3fb_dma_done(void *arg)
static int __set_par(struct fb_info *fbi, bool lock)
{
- u32 mem_len;
+ u32 mem_len, cur_xoffset, cur_yoffset;
struct ipu_di_signal_cfg sig_cfg;
enum ipu_panel mode = IPU_PANEL_TFT;
struct mx3fb_info *mx3_fbi = fbi->par;
@@ -805,8 +805,25 @@ static int __set_par(struct fb_info *fbi, bool lock)
video->out_height = fbi->var.yres;
video->out_stride = fbi->var.xres_virtual;
- if (mx3_fbi->blank = FB_BLANK_UNBLANK)
+ if (mx3_fbi->blank = FB_BLANK_UNBLANK) {
sdc_enable_channel(mx3_fbi);
+ /*
+ * sg[0] points to fb smem_start address
+ * and is actually active in controller.
+ */
+ mx3_fbi->cur_var.xoffset = 0;
+ mx3_fbi->cur_var.yoffset = 0;
+ }
+
+ /*
+ * Preserve xoffset and yoffest in case they are
+ * inactive in controller as fb is blanked.
+ */
+ cur_xoffset = mx3_fbi->cur_var.xoffset;
+ cur_yoffset = mx3_fbi->cur_var.yoffset;
+ mx3_fbi->cur_var = fbi->var;
+ mx3_fbi->cur_var.xoffset = cur_xoffset;
+ mx3_fbi->cur_var.yoffset = cur_yoffset;
return 0;
}
@@ -926,8 +943,8 @@ static int mx3fb_check_var(struct fb_var_screeninfo *var, struct fb_info *fbi)
var->grayscale = 0;
/* Preserve sync flags */
- var->sync |= mx3_fbi->sync;
- mx3_fbi->sync |= var->sync;
+ var->sync |= mx3_fbi->cur_var.sync;
+ mx3_fbi->cur_var.sync |= var->sync;
return 0;
}
@@ -1073,8 +1090,8 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
return -EINVAL;
}
- if (fbi->var.xoffset = var->xoffset &&
- fbi->var.yoffset = var->yoffset)
+ if (mx3_fbi->cur_var.xoffset = var->xoffset &&
+ mx3_fbi->cur_var.yoffset = var->yoffset)
return 0; /* No change, do nothing */
y_bottom = var->yoffset;
@@ -1157,6 +1174,8 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
else
fbi->var.vmode &= ~FB_VMODE_YWRAP;
+ mx3_fbi->cur_var = fbi->var;
+
mutex_unlock(&mx3_fbi->mutex);
dev_dbg(fbi->device, "Update complete\n");
--
1.7.1
^ permalink raw reply related
* [PATCH 3/3] mx3fb: avoid screen flash when panning with fb_set_var
From: Liu Ying @ 2012-06-11 1:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1339376810-8247-1-git-send-email-Ying.Liu@freescale.com>
Users may call FBIOPUT_VSCREENINFO ioctrl to do pan display.
This ioctrl relies on fb_set_var() to do the job. fb_set_var()
calls custom fb_set_par() method and then calls custom
fb_pan_display() method. The current implementation of mx3fb
reinitializes IPU display controller every time the custom
fb_set_par() method is called, which makes the screen flash
if fb_set_var() is called to do panning frequently. This patch
compares the new var info with the cached old one to decide
whether we really need to reinitialize IPU display controller.
We ignore xoffset and yoffset update because it doesn't require
to reinitialize the controller. Users may specify activate field
of var info with FB_ACTIVATE_NOW and FB_ACTIVATE_FORCE to
reinialize the controller by force.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
drivers/video/mx3fb.c | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index 2dd11c4..7d0aa7b 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -721,6 +721,26 @@ static void mx3fb_dma_done(void *arg)
complete(&mx3_fbi->flip_cmpl);
}
+static bool mx3fb_must_set_par(struct fb_info *fbi)
+{
+ struct mx3fb_info *mx3_fbi = fbi->par;
+ struct fb_var_screeninfo old_var = mx3_fbi->cur_var;
+ struct fb_var_screeninfo new_var = fbi->var;
+
+ if ((fbi->var.activate & FB_ACTIVATE_FORCE) &&
+ (fbi->var.activate & FB_ACTIVATE_MASK) = FB_ACTIVATE_NOW)
+ return true;
+
+ /*
+ * Ignore xoffset and yoffset update,
+ * because pan display handles this case.
+ */
+ old_var.xoffset = new_var.xoffset;
+ old_var.yoffset = new_var.yoffset;
+
+ return !!memcmp(&old_var, &new_var, sizeof(struct fb_var_screeninfo));
+}
+
static int __set_par(struct fb_info *fbi, bool lock)
{
u32 mem_len, cur_xoffset, cur_yoffset;
@@ -844,7 +864,7 @@ static int mx3fb_set_par(struct fb_info *fbi)
mutex_lock(&mx3_fbi->mutex);
- ret = __set_par(fbi, true);
+ ret = mx3fb_must_set_par(fbi) ? __set_par(fbi, true) : 0;
mutex_unlock(&mx3_fbi->mutex);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/1] mx3fb: support pan display with fb_set_var
From: Liu Ying @ 2012-06-11 2:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1206061711090.12739@axis700.grange>
2012/6/6, Guennadi Liakhovetski <g.liakhovetski@gmx.de>:
> On Wed, 30 May 2012, Liu Ying wrote:
>
>> Users may call FBIOPUT_VSCREENINFO ioctrl to do pan display.
>> This ioctrl relies on fb_set_var() to do the job. fb_set_var()
>> calls custom fb_set_par() method and then calls custom
>> fb_pan_display() method. The current implementation of mx3fb
>> reinitializes IPU display controller every time the custom
>> fb_set_par() method is called, which makes the display flash
>> if fb_set_var() is called to do panning frequently. The custom
>> fb_pan_display() method checks if the current xoffset and
>> yoffset are different from previous ones before doing actual
>> panning, which prevents the panning from happening within the
>> fb_set_var() context. This patch checks new var info to decide
>> whether we really need to reinitialize IPU display controller.
>> We ignore xoffset and yoffset update because it doesn't require
>> to reinitialize the controller. Users may specify activate field
>> of var info with FB_ACTIVATE_NOW and FB_ACTIVATE_FORCE to
>> reinialize the controller by force. Meanwhile, this patch removes
>> the check in custom fb_pan_display() method mentioned before to
>> have the panning work within fb_set_var() context. It doesn't
>> hurt to do panning again if there is no update for xoffset and
>> yoffset.
>
> You are really addressing 2 separate problems here: (1) panning cannot be
> set using FBIOPUT_VSCREENINFO and (2) screen flashes every time
> fb_set_var() is called, even if only panning is required. The reason for
> the first one is, that in fb_set_var() info->var is already updated from
> the new *var when fb_pan_display() is called. So, as you correctly
> identified, the condition
>
> if (fbi->var.xoffset = var->xoffset &&
> fbi->var.yoffset = var->yoffset)
> return 0; /* No change, do nothing */
>
> is trivially met and no panning takes place. Instead, you can use your
> idea to cache var_info locally and check against that one to see, whether
> offsets have changed, instead of removing that check completely.
>
> To solve the second problem you can use your check against the cached copy
> of var_info. See below for more details.
>
Thanks for your review. I think your suggestion is good and I have
sent you an updated series of patches for your review. Please find
more detail feedback inline.
>>
>> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>> ---
>> drivers/video/mx3fb.c | 31 +++++++++++++++++++++++++++----
>> 1 files changed, 27 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
>> index e3406ab..238b9aa 100644
>> --- a/drivers/video/mx3fb.c
>> +++ b/drivers/video/mx3fb.c
>> @@ -269,6 +269,8 @@ struct mx3fb_info {
>> struct scatterlist sg[2];
>>
>> u32 sync; /* preserve var->sync flags */
>
> An incremental patch could then also remove the above .sync member and
> switch to using .cur_var.sync instead.
Ok. I have addressed this in an updated patch.
>
>> +
>> + struct fb_var_screeninfo cur_var; /* current var info */
>> };
>>
>> static void mx3fb_dma_done(void *);
>> @@ -721,6 +723,26 @@ static void mx3fb_dma_done(void *arg)
>> complete(&mx3_fbi->flip_cmpl);
>> }
>>
>> +static bool mx3fb_need_not_to_set_par(struct fb_info *fbi)
>
> How about inverting logic and calling the function
> mx3fb_must_update_par()?
Ok. I use mx3fb_must_set_par() in an updated patch.
>
>> +{
>> + struct mx3fb_info *mx3_fbi = fbi->par;
>> + struct fb_var_screeninfo old_var = mx3_fbi->cur_var;
>> + struct fb_var_screeninfo new_var = fbi->var;
>> +
>> + if ((fbi->var.activate & FB_ACTIVATE_FORCE) &&
>> + (fbi->var.activate & FB_ACTIVATE_MASK) = FB_ACTIVATE_NOW)
>> + return false;
>> +
>> + /*
>> + * Ignore xoffset and yoffset update,
>> + * because pan display handles this case.
>> + */
>> + old_var.xoffset = new_var.xoffset;
>> + old_var.yoffset = new_var.yoffset;
>> +
>> + return !memcmp(&old_var, &new_var, sizeof(struct fb_var_screeninfo));
>> +}
>> +
>> static int __set_par(struct fb_info *fbi, bool lock)
>> {
>> u32 mem_len;
>> @@ -732,6 +754,9 @@ static int __set_par(struct fb_info *fbi, bool lock)
>> struct idmac_video_param *video = &ichan->params.video;
>> struct scatterlist *sg = mx3_fbi->sg;
>>
>> + if (mx3fb_need_not_to_set_par(fbi))
>> + return 0;
>> +
>
> __set_par() is called from 2 locations: from mx3fb_set_par() and
> init_fb_chan(), called from probing. You don't need to perform the above
> check in init_fb_chan() - there you always have to configure. Maybe better
> put it in mx3fb_set_par() just before calling __set_par() like
>
> ret = mx3fb_must_set_par() ? __set_par() : 0;
>
> As mentioned above, this solves problem #2 and should go into patch #2.
Ok. I have implemented your suggestion in an updated patch and
splitted this single patch into 2 separate ones. One is to support pan
display with fb_set_var(), the other is to fix screen flash issue when
panning with fb_set_var() frequently.
>
>> /* Total cleanup */
>> if (mx3_fbi->txd)
>> sdc_disable_channel(mx3_fbi);
>> @@ -808,6 +833,8 @@ static int __set_par(struct fb_info *fbi, bool lock)
>> if (mx3_fbi->blank = FB_BLANK_UNBLANK)
>> sdc_enable_channel(mx3_fbi);
>>
>> + mx3_fbi->cur_var = fbi->var;
>> +
>
> Yes, but preserve xoffset and yoffset - you don't apply them yet in
> __set_par().
Yes. I have perserved xoffset and yoffset in case fb is blanked when
calling __set_par() in an updated patch. I found that in case fb is
unblanked when calling __set_par(), fb smem_start address is set to
the controller, so I set mx3_fbi->cur_var.xoffset and
mx3_fbi->cur_var.yoffset to zero in __set_par() in this case. Please
fix me if I misunderstood anything.
>
>> return 0;
>> }
>>
>> @@ -1068,10 +1095,6 @@ static int mx3fb_pan_display(struct
>> fb_var_screeninfo *var,
>> return -EINVAL;
>> }
>>
>> - if (fbi->var.xoffset = var->xoffset &&
>> - fbi->var.yoffset = var->yoffset)
>> - return 0; /* No change, do nothing */
>> -
>
> I think, it would be better not to remove these completely, but check
> against cached .cur_var, and then update those values too.
Ok. I have addressed this in an updated patch.
>
>> y_bottom = var->yoffset;
>>
>> if (!(var->vmode & FB_VMODE_YWRAP))
>> --
>> 1.7.1
>
> Makes sense? Or have I misunderstood something?
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Best Regards,
Liu Ying
^ permalink raw reply
* [PATCH 1/2] video: s3c-fb: clear SHADOWCON register when clearing hardware window registers
From: Jingoo Han @ 2012-06-11 2:26 UTC (permalink / raw)
To: linux-fbdev
All bits of SHADOWCON register should be cleared when clearing
hardware window registers; however, some bits of SHADOWCON register
are not cleared previously.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 5f9d8e6..b5c2939 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1348,8 +1348,14 @@ static void s3c_fb_clear_win(struct s3c_fb *sfb, int win)
writel(0, regs + VIDOSD_A(win, sfb->variant));
writel(0, regs + VIDOSD_B(win, sfb->variant));
writel(0, regs + VIDOSD_C(win, sfb->variant));
- reg = readl(regs + SHADOWCON);
- writel(reg & ~SHADOWCON_WINx_PROTECT(win), regs + SHADOWCON);
+
+ if (sfb->variant.has_shadowcon) {
+ reg = readl(sfb->regs + SHADOWCON);
+ reg &= ~(SHADOWCON_WINx_PROTECT(win) |
+ SHADOWCON_CHx_ENABLE(win) |
+ SHADOWCON_CHx_LOCAL_ENABLE(win));
+ writel(reg, sfb->regs + SHADOWCON);
+ }
}
static int __devinit s3c_fb_probe(struct platform_device *pdev)
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] video: s3c-fb: fix possible division by zero in s3c_fb_calc_pixclk
From: Jingoo Han @ 2012-06-11 2:27 UTC (permalink / raw)
To: linux-fbdev
Divider value can be zero and it makes division by zero
from debug message in s3c_fb_calc_pixclk; therefore, it
should be fixed.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index b5c2939..ea7b661 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -361,7 +361,7 @@ static int s3c_fb_calc_pixclk(struct s3c_fb *sfb, unsigned int pixclk)
result = (unsigned int)tmp / 1000;
dev_dbg(sfb->dev, "pixclk=%u, clk=%lu, div=%d (%lu)\n",
- pixclk, clk, result, clk / result);
+ pixclk, clk, result, result ? clk / result : clk);
return result;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/3] mx3fb: do not support panning with fb blanked
From: Russell King - ARM Linux @ 2012-06-11 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1339376810-8247-1-git-send-email-Ying.Liu@freescale.com>
On Mon, Jun 11, 2012 at 09:06:48AM +0800, Liu Ying wrote:
> This patch checks if framebuffer is unblanked before
> we actually trigger panning in custom pan display
> function.
>
> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
> ---
> drivers/video/mx3fb.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> index e3406ab..d53db60 100644
> --- a/drivers/video/mx3fb.c
> +++ b/drivers/video/mx3fb.c
> @@ -1063,6 +1063,11 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
> dev_dbg(fbi->device, "%s [%c]\n", __func__,
> list_empty(&mx3_fbi->idmac_channel->queue) ? '-' : '+');
>
> + if (mx3_fbi->blank != FB_BLANK_UNBLANK) {
> + dev_dbg(fbi->device, "panning with fb blanked not supported\n");
> + return -EFAULT;
> + }
Why is this an error, and why return -EFAULT? What userspace access
failed?
^ permalink raw reply
* Re: [PATCH 1/3] mx3fb: do not support panning with fb blanked
From: Liu Ying @ 2012-06-11 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120611095102.GD11168@n2100.arm.linux.org.uk>
2012/6/11, Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Mon, Jun 11, 2012 at 09:06:48AM +0800, Liu Ying wrote:
>> This patch checks if framebuffer is unblanked before
>> we actually trigger panning in custom pan display
>> function.
>>
>> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>> ---
>> drivers/video/mx3fb.c | 5 +++++
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
>> index e3406ab..d53db60 100644
>> --- a/drivers/video/mx3fb.c
>> +++ b/drivers/video/mx3fb.c
>> @@ -1063,6 +1063,11 @@ static int mx3fb_pan_display(struct
>> fb_var_screeninfo *var,
>> dev_dbg(fbi->device, "%s [%c]\n", __func__,
>> list_empty(&mx3_fbi->idmac_channel->queue) ? '-' : '+');
>>
>> + if (mx3_fbi->blank != FB_BLANK_UNBLANK) {
>> + dev_dbg(fbi->device, "panning with fb blanked not supported\n");
>> + return -EFAULT;
>> + }
>
> Why is this an error, and why return -EFAULT? What userspace access
> failed?
>
Hi, Russell,
IMHO, panning with framebuffer blanked is meaningless, at least, it is
not a common usecase. Most users use pan display to swap front buffer
and back buffer when framebuffer is unblanked/active. So, I choose to
take the in question case as an error. Pan display may let user select
a buffer address to be active on display and I saw the head file
'errno-base.h' comments EFAULT macro to be 'Bad address', so I use
this return value. Perhaps, this return value is not good enough.
Maybe, EIO is better? Would you please help to give some advice on
this?
Thanks.
--
Best Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH 1/3] mx3fb: do not support panning with fb blanked
From: Russell King - ARM Linux @ 2012-06-11 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+8Hj81L9-NC=08_dvV2u_eM0NdssJsjduAgTbH37nusu56Avw@mail.gmail.com>
On Mon, Jun 11, 2012 at 06:46:14PM +0800, Liu Ying wrote:
> 2012/6/11, Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > On Mon, Jun 11, 2012 at 09:06:48AM +0800, Liu Ying wrote:
> >> This patch checks if framebuffer is unblanked before
> >> we actually trigger panning in custom pan display
> >> function.
> >>
> >> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
> >> ---
> >> drivers/video/mx3fb.c | 5 +++++
> >> 1 files changed, 5 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> >> index e3406ab..d53db60 100644
> >> --- a/drivers/video/mx3fb.c
> >> +++ b/drivers/video/mx3fb.c
> >> @@ -1063,6 +1063,11 @@ static int mx3fb_pan_display(struct
> >> fb_var_screeninfo *var,
> >> dev_dbg(fbi->device, "%s [%c]\n", __func__,
> >> list_empty(&mx3_fbi->idmac_channel->queue) ? '-' : '+');
> >>
> >> + if (mx3_fbi->blank != FB_BLANK_UNBLANK) {
> >> + dev_dbg(fbi->device, "panning with fb blanked not supported\n");
> >> + return -EFAULT;
> >> + }
> >
> > Why is this an error, and why return -EFAULT? What userspace access
> > failed?
> >
> Hi, Russell,
>
> IMHO, panning with framebuffer blanked is meaningless, at least, it is
> not a common usecase.
Yes, but why should anything in userspace care whether the display is
blanked or not?
For example, we may pan the display when a user program produces output,
and we're on the last line of the display. We don't fail that just
because the screen happens to be blank. So I don't see why we should
actively fail an explicit userspace pan request just because the console
happened to be blanked.
What I'm basically saying is that as far as _userspace_ is concerned,
all the standard APIs should just work as normal whether the display is
blanked or not.
^ permalink raw reply
* Re: [PATCH 1/3] mx3fb: do not support panning with fb blanked
From: Liu Ying @ 2012-06-11 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120611110517.GE11168@n2100.arm.linux.org.uk>
2012/6/11, Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Mon, Jun 11, 2012 at 06:46:14PM +0800, Liu Ying wrote:
>> 2012/6/11, Russell King - ARM Linux <linux@arm.linux.org.uk>:
>> > On Mon, Jun 11, 2012 at 09:06:48AM +0800, Liu Ying wrote:
>> >> This patch checks if framebuffer is unblanked before
>> >> we actually trigger panning in custom pan display
>> >> function.
>> >>
>> >> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>> >> ---
>> >> drivers/video/mx3fb.c | 5 +++++
>> >> 1 files changed, 5 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
>> >> index e3406ab..d53db60 100644
>> >> --- a/drivers/video/mx3fb.c
>> >> +++ b/drivers/video/mx3fb.c
>> >> @@ -1063,6 +1063,11 @@ static int mx3fb_pan_display(struct
>> >> fb_var_screeninfo *var,
>> >> dev_dbg(fbi->device, "%s [%c]\n", __func__,
>> >> list_empty(&mx3_fbi->idmac_channel->queue) ? '-' : '+');
>> >>
>> >> + if (mx3_fbi->blank != FB_BLANK_UNBLANK) {
>> >> + dev_dbg(fbi->device, "panning with fb blanked not supported\n");
>> >> + return -EFAULT;
>> >> + }
>> >
>> > Why is this an error, and why return -EFAULT? What userspace access
>> > failed?
>> >
>> Hi, Russell,
>>
>> IMHO, panning with framebuffer blanked is meaningless, at least, it is
>> not a common usecase.
>
> Yes, but why should anything in userspace care whether the display is
> blanked or not?
>
> For example, we may pan the display when a user program produces output,
> and we're on the last line of the display. We don't fail that just
> because the screen happens to be blank. So I don't see why we should
> actively fail an explicit userspace pan request just because the console
> happened to be blanked.
>
> What I'm basically saying is that as far as _userspace_ is concerned,
> all the standard APIs should just work as normal whether the display is
> blanked or not.
>
Ok, understand your point. I am ok to drop this patch.
Thanks.
--
Best Regards,
Liu Ying
^ permalink raw reply
* [PATCH] fbdev: make scripts/pnmtologo dependency portable
From: Yaakov (Cygwin/X) @ 2012-06-11 23:02 UTC (permalink / raw)
To: linux-fbdev
From: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Commit a53c9d5b7115173fba9f82ff8120b624ef206f48 added a dependency on
scripts/pnmtologo to all autogenerated .c files. An explicit rule
is required on platforms where the .exe suffix is used for hostprogs.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
---
Also applies to all 3.x stable branches
drivers/video/logo/Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/video/logo/Makefile b/drivers/video/logo/Makefile
index 3b43781..3854dbb 100644
--- a/drivers/video/logo/Makefile
+++ b/drivers/video/logo/Makefile
@@ -38,6 +38,7 @@ extra-y += $(call logo-cfiles,_clut224,ppm)
extra-y += $(call logo-cfiles,_gray256,pgm)
pnmtologo := scripts/pnmtologo
+$(pnmtologo): $(objtree)/scripts/pnmtologo
# Create commands like "pnmtologo -t mono -n logo_mac_mono -o ..."
quiet_cmd_logo = LOGO $@
--
1.7.9
^ permalink raw reply related
* Re: [PATCH] fbdev: make scripts/pnmtologo dependency portable
From: Geert Uytterhoeven @ 2012-06-12 7:32 UTC (permalink / raw)
To: Yaakov (Cygwin/X); +Cc: linux-fbdev, linux-kbuild
In-Reply-To: <1339455720-2384-1-git-send-email-yselkowitz@users.sourceforge.net>
Cc linux-kbuild added
On Tue, Jun 12, 2012 at 1:02 AM, Yaakov (Cygwin/X)
<yselkowitz@users.sourceforge.net> wrote:
> From: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
>
> Commit a53c9d5b7115173fba9f82ff8120b624ef206f48 added a dependency on
> scripts/pnmtologo to all autogenerated .c files. An explicit rule
> is required on platforms where the .exe suffix is used for hostprogs.
>
> Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
> ---
> Also applies to all 3.x stable branches
>
> drivers/video/logo/Makefile | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/logo/Makefile b/drivers/video/logo/Makefile
> index 3b43781..3854dbb 100644
> --- a/drivers/video/logo/Makefile
> +++ b/drivers/video/logo/Makefile
> @@ -38,6 +38,7 @@ extra-y += $(call logo-cfiles,_clut224,ppm)
> extra-y += $(call logo-cfiles,_gray256,pgm)
>
> pnmtologo := scripts/pnmtologo
> +$(pnmtologo): $(objtree)/scripts/pnmtologo
>
> # Create commands like "pnmtologo -t mono -n logo_mac_mono -o ..."
> quiet_cmd_logo = LOGO $@
> --
> 1.7.9
>
> --
> 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] da8xx-fb: Rounding FB size to satisfy SGX buffer requirements
From: Nellutla, Aditya @ 2012-06-12 9:34 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1337753191-14802-1-git-send-email-aditya.n@ti.com>
Florian,
I didn't receive any review comments for the patch below. So could you please merge the patch?
Regards,
Aditya
-----Original Message-----
From: Nellutla, Aditya
Sent: Monday, June 04, 2012 11:33 AM
To: Nellutla, Aditya; linux-fbdev@vger.kernel.org
Cc: Hiremath, Vaibhav
Subject: RE: [PATCH] da8xx-fb: Rounding FB size to satisfy SGX buffer requirements
All,
Did you get chance to review this patch? Request to give your feedback as early as possible.
Regards,
Aditya
-----Original Message-----
From: Nellutla, Aditya
Sent: Wednesday, May 23, 2012 11:37 AM
To: linux-fbdev@vger.kernel.org
Cc: Nellutla, Aditya
Subject: [PATCH] da8xx-fb: Rounding FB size to satisfy SGX buffer requirements
In the real time use-case when SGX is used for rendering to FB buffers it has been
observed that, the available memory from framebuffer driver is not sufficient for
SGX under certain cases (like 16-bit WVGA resolution). SGX requires 2 swap buffers
with each of the buffers aligned to lcm(line_length, PAGE_SIZE).
Inorder to satisfy this requirement, we have two options,
- Increase number of FB buffers (LCD_NUM_BUFFERS) to 3. This is not
recommended as we end up wasting huge memory in most of the cases.
- Align FB buffers to lcm(line_length, PAGE_SIZE).This ensures framebuffer
size is increased to satisfy SGX requirements keeping alignment intact.
This patch makes sure that FB allocates buffers aligned to above formula.
Signed-off-by: Aditya Nellutla <aditya.n@ti.com>
---
drivers/video/da8xx-fb.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 47118c7..2f24c19 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -31,6 +31,7 @@
#include <linux/cpufreq.h>
#include <linux/console.h>
#include <linux/slab.h>
+#include <linux/lcm.h>
#include <video/da8xx-fb.h>
#include <asm/div64.h>
@@ -1114,6 +1115,7 @@ static int __devinit fb_probe(struct platform_device *device)
struct da8xx_fb_par *par;
resource_size_t len;
int ret, i;
+ unsigned long ulcm;
if (fb_pdata = NULL) {
dev_err(&device->dev, "Can not get platform data\n");
@@ -1209,7 +1211,8 @@ static int __devinit fb_probe(struct platform_device *device)
/* allocate frame buffer */
par->vram_size = lcdc_info->width * lcdc_info->height * lcd_cfg->bpp;
- par->vram_size = PAGE_ALIGN(par->vram_size/8);
+ ulcm = lcm((lcdc_info->width * lcd_cfg->bpp)/8, PAGE_SIZE);
+ par->vram_size = roundup(par->vram_size/8, ulcm);
par->vram_size = par->vram_size * LCD_NUM_BUFFERS;
par->vram_virt = dma_alloc_coherent(NULL,
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox