* [RFC] Which fb_var_screeninfo fields should FBIOPAN_DISPLAY use ?
From: Laurent Pinchart @ 2011-05-23 20:11 UTC (permalink / raw)
To: linux-fbdev
Hi everybody,
I've recently received a patch for my fbdev test application to fix a panning-
related issue. The application naively assumed that only the xoffset and
yoffset were used, and the patch commit message explained that several drivers
relied on other fields being filled with current values.
I got curious about this. As there's no FBIOPAN_DISPLAY documentation that
clearly states which fields are used and which fields must be ignored by
drivers, I checked the in-tree fbdev drivers and here's what I found.
First of all, the FBIOPAN_DISPLAY implementation (drivers/video/fbmem.c) uses
the xoffset, yoffset and vmode fields. That was expected, there's nothing too
weird there. Several drivers also use the activate field, which seems like a
valid use to me.
Then, two drivers (video/msm and staging/msm) use the reserved fields. As
usage of the reserved fields is by definition not standard, I decided to
ignore this.
Finally, here's a list of the drivers using other fields, along with the
fields that are being used.
media/video/ivtv - xres_virtual, bits_per_pixel
video/68328fb - xres, yres
video/acornfb - yres, yres_virtual
video/arkfb - bits_per_pixel, xres_virtual
video/atmel_lcdfb - bits_per_pixel, xres_virtual, xres
video/aty/radeon - xres, yres, xres_virtual, yres_virtual, bits_per_pixel
video/da8xx-fb - bits_per_pixel
video/fb-puv3 - xres, yres
video/g364fb - xres, yres, yres_virtual
video/gxt4500 - xres, yres, xres_virtual, yres_virtual
video/hgafb - xres, yres
video/imsttfb - bits_per_pixel
video/intelfb - xres, yres, xres_virtual, yres_virtual, bits_per_pixel
video/mb862xx - xres_virtual, yres_virtual
video/mx3fb - yres, xres_virtual, bits_per_pixel
video/neofb - xres_virtual, bits_per_pixel
video/pm2fb - bits_per_pixel, xres
video/pm3fb - xres, bits_per_pixel
video/s3c-fb - yres
video/s3fb - bits_per_pixel, xres_virtual
video/savage - xres_virtual, bits_per_pixel
video/sh_mobile_lcdcfb - nonstd, xres, yres_virtual
video/sis - xres, yres, xres_virtual, yres_virtual, bits_per_pixel
video/sm501fb - xres_virtual, yres_virtual, bits_per_pixel
video/tridentfb - xres_virtual, bits_per_pixel
video/vfb - xres, yres
video/vga16fb - bits_per_pixel
video/via - xres_virtual, bits_per_pixel
video/vt8500lcdfb - xres, xres_virtual
video/vt8623fb - bits_per_pixel, xres_virtual
video/xgifb - xres_virtual, yres_virtual, xres, yres, bits_per_pixel
These fields are used to validate the xoffset and yoffset parameters against
the active resolution, as well as to compute offset in vram.
This clearly looks like bugs to me, especially given that many other drivers
compute the same parameters using info->var instead of var. For instance, if
drivers/video/aty/radeon_base.c implements the pan display operation as
if ((var->xoffset + var->xres > var->xres_virtual)
|| (var->yoffset + var->yres > var->yres_virtual))
return -EINVAL;
...
OUTREG(CRTC_OFFSET, ((var->yoffset * var->xres_virtual + var->xoffset)
* var->bits_per_pixel / 8) & ~7);
If var isn't a copy of the current fb parameters, the code will clearly lead
to a wrong behaviour. Even worse, some drivers use var to validate parameters
and then info->var to compute offsets, or the other way around. This could
lead to security issues.
I believe all those drivers should be fixed to use info->var instead of var to
access the current xres, yres, xres_virtual, yres_virtual and bits_per_pixel
fields in their pan display operation handler. However, this could break
applications that rely on the current buggy behaviour. Would that be
acceptable ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC] Which fb_var_screeninfo fields should FBIOPAN_DISPLAY use
From: Florian Tobias Schandinat @ 2011-05-23 20:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <201105232211.40154.laurent.pinchart@ideasonboard.com>
Hi Laurent,
On 05/23/2011 08:11 PM, Laurent Pinchart wrote:
> Hi everybody,
>
> I've recently received a patch for my fbdev test application to fix a panning-
> related issue. The application naively assumed that only the xoffset and
> yoffset were used, and the patch commit message explained that several drivers
> relied on other fields being filled with current values.
>
> I got curious about this. As there's no FBIOPAN_DISPLAY documentation that
> clearly states which fields are used and which fields must be ignored by
> drivers, I checked the in-tree fbdev drivers and here's what I found.
>
> First of all, the FBIOPAN_DISPLAY implementation (drivers/video/fbmem.c) uses
> the xoffset, yoffset and vmode fields. That was expected, there's nothing too
> weird there. Several drivers also use the activate field, which seems like a
> valid use to me.
>
> Then, two drivers (video/msm and staging/msm) use the reserved fields. As
> usage of the reserved fields is by definition not standard, I decided to
> ignore this.
>
> Finally, here's a list of the drivers using other fields, along with the
> fields that are being used.
>
> media/video/ivtv - xres_virtual, bits_per_pixel
> video/68328fb - xres, yres
> video/acornfb - yres, yres_virtual
> video/arkfb - bits_per_pixel, xres_virtual
> video/atmel_lcdfb - bits_per_pixel, xres_virtual, xres
> video/aty/radeon - xres, yres, xres_virtual, yres_virtual, bits_per_pixel
> video/da8xx-fb - bits_per_pixel
> video/fb-puv3 - xres, yres
> video/g364fb - xres, yres, yres_virtual
> video/gxt4500 - xres, yres, xres_virtual, yres_virtual
> video/hgafb - xres, yres
> video/imsttfb - bits_per_pixel
> video/intelfb - xres, yres, xres_virtual, yres_virtual, bits_per_pixel
> video/mb862xx - xres_virtual, yres_virtual
> video/mx3fb - yres, xres_virtual, bits_per_pixel
> video/neofb - xres_virtual, bits_per_pixel
> video/pm2fb - bits_per_pixel, xres
> video/pm3fb - xres, bits_per_pixel
> video/s3c-fb - yres
> video/s3fb - bits_per_pixel, xres_virtual
> video/savage - xres_virtual, bits_per_pixel
> video/sh_mobile_lcdcfb - nonstd, xres, yres_virtual
> video/sis - xres, yres, xres_virtual, yres_virtual, bits_per_pixel
> video/sm501fb - xres_virtual, yres_virtual, bits_per_pixel
> video/tridentfb - xres_virtual, bits_per_pixel
> video/vfb - xres, yres
> video/vga16fb - bits_per_pixel
> video/via - xres_virtual, bits_per_pixel
> video/vt8500lcdfb - xres, xres_virtual
> video/vt8623fb - bits_per_pixel, xres_virtual
> video/xgifb - xres_virtual, yres_virtual, xres, yres, bits_per_pixel
>
> These fields are used to validate the xoffset and yoffset parameters against
> the active resolution, as well as to compute offset in vram.
>
> This clearly looks like bugs to me, especially given that many other drivers
> compute the same parameters using info->var instead of var. For instance, if
> drivers/video/aty/radeon_base.c implements the pan display operation as
>
> if ((var->xoffset + var->xres> var->xres_virtual)
> || (var->yoffset + var->yres> var->yres_virtual))
> return -EINVAL;
>
> ...
>
> OUTREG(CRTC_OFFSET, ((var->yoffset * var->xres_virtual + var->xoffset)
> * var->bits_per_pixel / 8)& ~7);
>
> If var isn't a copy of the current fb parameters, the code will clearly lead
> to a wrong behaviour. Even worse, some drivers use var to validate parameters
> and then info->var to compute offsets, or the other way around. This could
> lead to security issues.
You're right.
> I believe all those drivers should be fixed to use info->var instead of var to
> access the current xres, yres, xres_virtual, yres_virtual and bits_per_pixel
> fields in their pan display operation handler. However, this could break
> applications that rely on the current buggy behaviour. Would that be
> acceptable ?
Yes, as it is obviously wrong to assume other fields of var are valid (otherwise
there would be no need for pan at all). So let's fix those drivers. I'll fix
video/via ASAP (there it's also a bug to use xres_virtual as fix.line_length is
more correct (alignment)) and have a look at the others as time permits (though
it would be better if people fix them who have the ability to test).
Thanks a lot,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [RFC] Standardize YUV support in the fbdev API
From: Laurent Pinchart @ 2011-05-23 21:00 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-fbdev, dri-devel, linux-media
In-Reply-To: <4DD6EC1E.4090702@gmx.de>
Hi Florian,
On Saturday 21 May 2011 00:33:02 Florian Tobias Schandinat wrote:
> On 05/17/2011 10:07 PM, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > I need to implement support for a YUV frame buffer in an fbdev driver. As
> > the fbdev API doesn't support this out of the box, I've spent a couple
> > of days reading fbdev (and KMS) code and thinking about how we could
> > cleanly add YUV support to the API. I'd like to share my findings and
> > thoughts, and hopefully receive some comments back.
>
> Thanks. I think you did already a good job, hope we can get it done this
> time.
Thanks. I'll keep pushing then :-)
> > Given the overlap between the KMS, V4L2 and fbdev APIs, the need to share
> > data and buffers between those subsystems, and the planned use of V4L2
> > FCCs in the KMS overlay API, I believe using V4L2 FCCs to identify fbdev
> > formats would be a wise decision.
>
> I agree.
There seems to be a general agreement on this, so I'll consider this settled.
> > To select a frame buffer YUV format, the fb_var_screeninfo structure will
> > need to be extended with a format field. The fbdev API and ABI must not
> > be broken, which prevents us from changing the current structure layout
> > and replacing the existing format selection mechanism (through the red,
> > green, blue and alpha bitfields) completely.
>
> I agree.
>
> > - Other solutions are possible, such as adding new ioctls. Those
> > solutions are more intrusive, and require larger changes to both
> > userspace and kernelspace code.
>
> I'm against (ab)using the nonstd field (probably the only sane thing we can
> do with it is declare it non-standard which interpretation is completely
> dependent on the specific driver) or requiring previously unused fields to
> have a special value so I'd like to suggest a different method:
>
> I remembered an earlier discussion:
> [ http://marc.info/?l=linux-fbdev&m\x129896686208130&w=2 ]
>
> On 03/01/2011 08:07 AM, Geert Uytterhoeven wrote:
> > On Tue, Mar 1, 2011 at 04:13, Damian<dhobsong@igel.co.jp> wrote:
> >> On 2011/02/24 15:05, Geert Uytterhoeven wrote:
> >>> For YUV (do you mean YCbCr?), I'm inclined to suggest adding a new
> >>> FB_VISUAL_*
> >>> type instead, which indicates the fb_var_screeninfo.{red,green,blue}
> >>> fields are
> >>> YCbCr instead of RGB.
> >>> Depending on the frame buffer organization, you also need new
> >>> FB_TYPE_*/FB_AUX_*
> >>> types.
> >>
> >> I just wanted to clarify here. Is your comment about these new flags
> >> in specific reference to this patch or to Magnus' "going forward"
> >> comment? It
> >
> > About new flags.
> >
> >> seems like the beginnings of a method to standardize YCbCr support in
> >> fbdev across all platforms.
> >> Also, do I understand correctly that FB_VISUAL_ would specify the
> >> colorspace
> >
> > FB_VISUAL_* specifies how pixel values (which may be tuples) are mapped
> > to colors on the screen, so to me it looks like the sensible way to set
> > up YCbCr.
> >
> >> (RGB, YCbCr), FB_TYPE_* would be a format specifier (i.e. planar,
> >> semiplanar, interleaved, etc)? I'm not really sure what you are
> >> referring to with the FB_AUX_* however.
> >
> > Yep, FB_TYPE_* specifies how pixel values/tuples are laid out in frame
> > buffer memory.
> >
> > FB_AUX_* is only used if a specific value of FB_TYPE_* needs an
> > additional parameter (e.g. the interleave value for interleaved
> > bitplanes).
>
> Adding new standard values for these fb_fix_screeninfo fields would solve
> the issue for framebuffers which only support a single format.
I've never liked changing fixed screen information :-) It would be consistent
with the API though.
> If you have the need to switch
Yes I need that. This requires an API to set the mode through
fb_var_screeninfo, which is why I skipped modifying fb_fix_screeinfo.
A new FB_TYPE_* could be used to report that we use a 4CC-based mode, with the
exact mode reported in one of the fb_fix_screeninfo reserved fields (or the
type_aux field). This would duplicate the information passed through
fb_var_screeninfo though. Do you think it's worth it ?
> I guess it would be a good idea to add a new flag to the vmode bitfield in
> fb_var_screeninfo which looks like a general purpose modifier for the
> videomode. You could than reuse any RGB-specific field you like to pass more
> information.
That looks good to me. The grayscale field could be reused to pass the 4CC.
> Maybe we should also use this chance to declare one of the fix_screeninfo
> reserved fields to be used for capability flags or an API version as we can
> assume that those are 0 (at least in sane drivers).
That's always good, although it's not a hard requirement for the purpose of
YUV support.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] viafb: use display information in info not in var for panning
From: Florian Tobias Schandinat @ 2011-05-23 21:51 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat, stable
In-Reply-To: <201105232211.40154.laurent.pinchart@ideasonboard.com>
As Laurent pointed out we must not use any information in the passed
var besides xoffset, yoffset and vmode as otherwise applications
might abuse it. Also use the aligned fix.line_length and not the
(possible) unaligned xres_virtual.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: stable@kernel.org
---
drivers/video/via/viafbdev.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 3114a87..aa87529 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -348,8 +348,9 @@ static int viafb_pan_display(struct fb_var_screeninfo *var,
struct fb_info *info)
{
struct viafb_par *viapar = info->par;
- u32 vram_addr = (var->yoffset * var->xres_virtual + var->xoffset)
- * (var->bits_per_pixel / 8) + viapar->vram_addr;
+ u32 vram_addr = viapar->vram_addr
+ + var->yoffset * info->fix.line_length
+ + var->xoffset * info->var.bits_per_pixel / 8;
DEBUG_MSG(KERN_DEBUG "viafb_pan_display, address = %d\n", vram_addr);
if (!viafb_dual_fb) {
--
1.6.3.2
^ permalink raw reply related
* Re: [RFC] Standardize YUV support in the fbdev API
From: Florian Tobias Schandinat @ 2011-05-23 22:56 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-fbdev, linux-media, dri-devel
In-Reply-To: <201105232300.27087.laurent.pinchart@ideasonboard.com>
Hi Laurent,
On 05/23/2011 09:00 PM, Laurent Pinchart wrote:
> On Saturday 21 May 2011 00:33:02 Florian Tobias Schandinat wrote:
>> On 05/17/2011 10:07 PM, Laurent Pinchart wrote:
>>> - Other solutions are possible, such as adding new ioctls. Those
>>> solutions are more intrusive, and require larger changes to both
>>> userspace and kernelspace code.
>>
>> I'm against (ab)using the nonstd field (probably the only sane thing we can
>> do with it is declare it non-standard which interpretation is completely
>> dependent on the specific driver) or requiring previously unused fields to
>> have a special value so I'd like to suggest a different method:
>>
>> I remembered an earlier discussion:
>> [ http://marc.info/?l=linux-fbdev&m\x129896686208130&w=2 ]
>>
>> On 03/01/2011 08:07 AM, Geert Uytterhoeven wrote:
>> > On Tue, Mar 1, 2011 at 04:13, Damian<dhobsong@igel.co.jp> wrote:
>> >> On 2011/02/24 15:05, Geert Uytterhoeven wrote:
>> >>> For YUV (do you mean YCbCr?), I'm inclined to suggest adding a new
>> >>> FB_VISUAL_*
>> >>> type instead, which indicates the fb_var_screeninfo.{red,green,blue}
>> >>> fields are
>> >>> YCbCr instead of RGB.
>> >>> Depending on the frame buffer organization, you also need new
>> >>> FB_TYPE_*/FB_AUX_*
>> >>> types.
>> >>
>> >> I just wanted to clarify here. Is your comment about these new flags
>> >> in specific reference to this patch or to Magnus' "going forward"
>> >> comment? It
>> >
>> > About new flags.
>> >
>> >> seems like the beginnings of a method to standardize YCbCr support in
>> >> fbdev across all platforms.
>> >> Also, do I understand correctly that FB_VISUAL_ would specify the
>> >> colorspace
>> >
>> > FB_VISUAL_* specifies how pixel values (which may be tuples) are mapped
>> > to colors on the screen, so to me it looks like the sensible way to set
>> > up YCbCr.
>> >
>> >> (RGB, YCbCr), FB_TYPE_* would be a format specifier (i.e. planar,
>> >> semiplanar, interleaved, etc)? I'm not really sure what you are
>> >> referring to with the FB_AUX_* however.
>> >
>> > Yep, FB_TYPE_* specifies how pixel values/tuples are laid out in frame
>> > buffer memory.
>> >
>> > FB_AUX_* is only used if a specific value of FB_TYPE_* needs an
>> > additional parameter (e.g. the interleave value for interleaved
>> > bitplanes).
>>
>> Adding new standard values for these fb_fix_screeninfo fields would solve
>> the issue for framebuffers which only support a single format.
>
> I've never liked changing fixed screen information :-) It would be consistent
> with the API though.
Fixed does only mean that it can't be directly manipulated by applications. The
driver has to modify it anyway on about every mode change (line_length). Yes
perhaps some of these fields would be in var today and certainly others
shouldn't exist at all but I do not blame anyone for not being capable to look
into the future.
>> If you have the need to switch
>
> Yes I need that. This requires an API to set the mode through
> fb_var_screeninfo, which is why I skipped modifying fb_fix_screeinfo.
>
> A new FB_TYPE_* could be used to report that we use a 4CC-based mode, with the
> exact mode reported in one of the fb_fix_screeninfo reserved fields (or the
> type_aux field). This would duplicate the information passed through
> fb_var_screeninfo though. Do you think it's worth it ?
I think it's more like a FB_VISUAL_FOURCC as you want to express how the color
<-> pixel mapping is. The FB_TYPE_* is more about whether pixel are packed or
represented as planes (the 2 format groups mentioned on fourcc.org).
That's certainly something I'd introduce as it would (hopefully) work to prevent
old applications which don't know your extension manipulating a FOURCC format
thinking that it is RGB.
So I think we should
fix.visual = FB_VISUAL_FOURCC;
fix.type = FB_TYPE_PACKED_PIXELS | FB_TYPE_PLANES; /* (?) */
or maybe add a FB_TYPE_FOURCC and rely only on the information in FOURCC (as
things like UYVY could become confusing as macropixel!=pixel)
>> I guess it would be a good idea to add a new flag to the vmode bitfield in
>> fb_var_screeninfo which looks like a general purpose modifier for the
>> videomode. You could than reuse any RGB-specific field you like to pass more
>> information.
>
> That looks good to me. The grayscale field could be reused to pass the 4CC.
var.grayscale = <FOURCC_FORMAT>;
var.vmode = FB_VMODE_FOURCC;
and if this vmode flag is not set it means traditional mode (based on RGBA).
>> Maybe we should also use this chance to declare one of the fix_screeninfo
>> reserved fields to be used for capability flags or an API version as we can
>> assume that those are 0 (at least in sane drivers).
>
> That's always good, although it's not a hard requirement for the purpose of
> YUV support.
Sure. But it's good to let the application know whether you support the new
extension or whether you just ignore the flag. So I'm voting for a
fix.caps = FB_CAP_FOURCC;
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS updates for 2.6.40
From: Paul Mundt @ 2011-05-24 6:38 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: lo-ml, lfbdev-ml
In-Reply-To: <1306151004.1871.36.camel@deskari>
On Mon, May 23, 2011 at 02:43:24PM +0300, Tomi Valkeinen wrote:
> Here are the OMAP Display Subsystem updates for 2.6.40.
>
> Most of the patches are OMAP4 related, either fixing the old code to
> allow us to implement new OMAP4 features, or implementing those new
> features. Other bigger changes are ULPS power management feature and
> moving the DSS header file from arch/arm/plat-omap/include to
> include/video.
>
Pulled and pushed out, thanks. There were a couple of conflicts, so you
may want to doublecheck to make sure nothing was inadvertently broken.
^ permalink raw reply
* Re: [PATCH 0/5] mb862xxfb driver update for 2.6.40
From: Anatolij Gustschin @ 2011-05-24 7:12 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1305302089-7666-1-git-send-email-agust@denx.de>
Hi Paul,
On Fri, 13 May 2011 17:54:44 +0200
Anatolij Gustschin <agust@denx.de> wrote:
> This patch series extends the driver for Coral GDCs to support
> such controller features as video layer L1 and I2C bus for video
> decoder chips. First three patches are small fixes and improvements.
>
> These patches can also be pulled from
>
> git://git.denx.de/linux-2.6-agust.git mb862xxfb-for-next
Can you pull these patches for current merge window? Thanks!
>
> Anatolij Gustschin (5):
> video: mb862xxfb: correct fix.smem_len field initialization
> video: mb862xxfb: use pre-initialized configuration for PCI GDCs
> video: mb862xxfb: relocate register space to get contiguous vram
> video: mb862xx: add support for controller's I2C bus adapter
> video: mb862xxfb: add support for L1 displaying
>
> drivers/video/mb862xx/Makefile | 2 +-
> drivers/video/mb862xx/mb862xx-i2c.c | 168 +++++++++++++++++++++++++++++++++++
> drivers/video/mb862xx/mb862xx_reg.h | 58 +++++++++++-
> drivers/video/mb862xx/mb862xxfb.c | 150 +++++++++++++++++++++++++++++--
> drivers/video/mb862xx/mb862xxfb.h | 30 ++++++
> 5 files changed, 396 insertions(+), 12 deletions(-)
> create mode 100644 drivers/video/mb862xx/mb862xx-i2c.c
Anatolij
^ permalink raw reply
* Re: [PATCH 4/5] video: mb862xx: add support for controller's I2C bus adapter
From: Paul Mundt @ 2011-05-24 7:23 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1305302089-7666-5-git-send-email-agust@denx.de>
On Fri, May 13, 2011 at 05:54:48PM +0200, Anatolij Gustschin wrote:
> Add adapter driver for I2C adapter in Coral-P(A)/Lime GDCs.
> So we can easily access devices on controller's I2C bus using
> i2c-dev interface.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
I don't see anything in the Kconfig that prevents this from being built
with CONFIG_I2C=n, have you tested this case?
^ permalink raw reply
* Re: [PATCH 1/3] fbdev/amifb: Correct check for video memory size
From: Paul Mundt @ 2011-05-24 7:27 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-fbdev, linux-m68k
In-Reply-To: <1306006976-32117-1-git-send-email-geert@linux-m68k.org>
On Sat, May 21, 2011 at 09:42:54PM +0200, Geert Uytterhoeven wrote:
> The check should compare the available memory size with the highest allocation
> value (VIDEOMEMSIZE_*_2M), not with the lowest value (VIDEOMEMSIZE_*_1M).
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
On Sat, May 21, 2011 at 09:42:55PM +0200, Geert Uytterhoeven wrote:
> Fail gracefully instead.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
On Sat, May 21, 2011 at 09:42:56PM +0200, Geert Uytterhoeven wrote:
> amiga_chip_alloc() already aligns to the PAGE_SIZE
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
All applied, thanks.
^ permalink raw reply
* Re: [PATCH 4/5] video: mb862xx: add support for controller's I2C
From: Anatolij Gustschin @ 2011-05-24 7:45 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1305302089-7666-5-git-send-email-agust@denx.de>
On Tue, 24 May 2011 16:23:44 +0900
Paul Mundt <lethal@linux-sh.org> wrote:
> On Fri, May 13, 2011 at 05:54:48PM +0200, Anatolij Gustschin wrote:
> > Add adapter driver for I2C adapter in Coral-P(A)/Lime GDCs.
> > So we can easily access devices on controller's I2C bus using
> > i2c-dev interface.
> >
> > Signed-off-by: Anatolij Gustschin <agust@denx.de>
>
> I don't see anything in the Kconfig that prevents this from being built
> with CONFIG_I2C=n, have you tested this case?
No. Thanks for pointing this out, I'll fix it.
BR,
Anatolij
^ permalink raw reply
* [PATCH] [resend] video: s3c-fb: correct transparency checking in 32bpp
From: Jingoo Han @ 2011-05-24 8:55 UTC (permalink / raw)
To: linux-fbdev
32bpp means ARGB 8888 in the driver, therfore the transparency length
and offset should be 8 and 24 respectively. However, the transparency
length and offset were previously 0, which means that the driver supports
RGB 888 without alpha blending when 32bpp is used.
So, the transparency checking in 32bpp is corrected so that the
transparency length and offset are 8 and 24 respectively.
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 6b7c5a8..574e046 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -302,6 +302,7 @@ static int s3c_fb_check_var(struct fb_var_screeninfo *var,
var->blue.length = 5;
break;
+ case 32:
case 28:
case 25:
var->transp.length = var->bits_per_pixel - 24;
@@ -310,7 +311,6 @@ static int s3c_fb_check_var(struct fb_var_screeninfo *var,
case 24:
/* our 24bpp is unpacked, so 32bpp */
var->bits_per_pixel = 32;
- case 32:
var->red.offset = 16;
var->red.length = 8;
var->green.offset = 8;
--
1.7.1
^ permalink raw reply related
* [PATCH] [resend] video: s3c-fb: add gpio setup function to resume function
From: Jingoo Han @ 2011-05-24 8:55 UTC (permalink / raw)
To: linux-fbdev
This patch adds gpio setup function to resume function to ensure
gpio used by FIMD IP and LCD panel during a resume.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 6b7c5a8..2bd86a9 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1526,7 +1526,8 @@ static int s3c_fb_resume(struct device *dev)
clk_enable(sfb->bus_clk);
- /* setup registers */
+ /* setup gpio and output polarity controls */
+ pd->setup_gpio();
writel(pd->vidcon1, sfb->regs + VIDCON1);
/* zero all windows before we do anything */
@@ -1584,7 +1585,8 @@ static int s3c_fb_runtime_resume(struct device *dev)
clk_enable(sfb->bus_clk);
- /* setup registers */
+ /* setup gpio and output polarity controls */
+ pd->setup_gpio();
writel(pd->vidcon1, sfb->regs + VIDCON1);
/* zero all windows before we do anything */
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] [resend] video: s3c-fb: correct transparency checking in 32bpp
From: Paul Mundt @ 2011-05-24 9:05 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1306227323-22681-1-git-send-email-jg1.han@samsung.com>
On Tue, May 24, 2011 at 05:55:23PM +0900, Jingoo Han wrote:
> 32bpp means ARGB 8888 in the driver, therfore the transparency length
> and offset should be 8 and 24 respectively. However, the transparency
> length and offset were previously 0, which means that the driver supports
> RGB 888 without alpha blending when 32bpp is used.
>
> So, the transparency checking in 32bpp is corrected so that the
> transparency length and offset are 8 and 24 respectively.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
On Tue, May 24, 2011 at 05:55:31PM +0900, Jingoo Han wrote:
> This patch adds gpio setup function to resume function to ensure
> gpio used by FIMD IP and LCD panel during a resume.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Curiously the first version appears to have missed patchwork altogether,
and I missed it in my mail folder, too. Applied now, thanks.
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS updates for 2.6.40
From: Tomi Valkeinen @ 2011-05-24 9:37 UTC (permalink / raw)
To: Paul Mundt; +Cc: lo-ml, lfbdev-ml
In-Reply-To: <20110524063803.GC11986@linux-sh.org>
On Tue, 2011-05-24 at 15:38 +0900, Paul Mundt wrote:
> On Mon, May 23, 2011 at 02:43:24PM +0300, Tomi Valkeinen wrote:
> > Here are the OMAP Display Subsystem updates for 2.6.40.
> >
> > Most of the patches are OMAP4 related, either fixing the old code to
> > allow us to implement new OMAP4 features, or implementing those new
> > features. Other bigger changes are ULPS power management feature and
> > moving the DSS header file from arch/arm/plat-omap/include to
> > include/video.
> >
> Pulled and pushed out, thanks. There were a couple of conflicts, so you
> may want to doublecheck to make sure nothing was inadvertently broken.
I wonder where those conflicts came from...
I think this pull request never made into the 39 rcs:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg48334.html
I should have checked it, but it seems I've missed those. So you had
those patches in fbdev tree, and I had the same patches in my
development tree (which ended up being rebased a bit), and this led to
those conflicts.
But diff between omapdss in my master branch and fbdev master is null,
so the conflicts were resolved correctly.
Tomi
^ permalink raw reply
* [PATCH v2 4/5] video: mb862xx: add support for controller's I2C bus adapter
From: Anatolij Gustschin @ 2011-05-24 15:04 UTC (permalink / raw)
To: linux-fbdev
Add adapter driver for I2C adapter in Coral-P(A)/Lime GDCs.
So we can easily access devices on controller's I2C bus using
i2c-dev interface.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
v2:
- add Kconfig option for GDC I2C adapter driver,
fixes CONFIG_I2C=n build issue as pointed out by Paul
- fix to remove I2C adapter on module unload
- rename main mb862xx fb driver file to prevent mb862xxfb.o
circular dependency warnings from make
- rebase to apply cleanly on top of current fbdev-2.6 git tree
drivers/video/Kconfig | 9 +
drivers/video/mb862xx/Makefile | 5 +-
drivers/video/mb862xx/mb862xx-i2c.c | 177 ++++++++++++++++++++
drivers/video/mb862xx/mb862xx_reg.h | 21 +++
drivers/video/mb862xx/mb862xxfb.h | 9 +
.../video/mb862xx/{mb862xxfb.c => mb862xxfbdrv.c} | 4 +
6 files changed, 224 insertions(+), 1 deletions(-)
create mode 100644 drivers/video/mb862xx/mb862xx-i2c.c
rename drivers/video/mb862xx/{mb862xxfb.c => mb862xxfbdrv.c} (99%)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 7326962..549b960 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2294,6 +2294,15 @@ config FB_MB862XX_LIME
endchoice
+config FB_MB862XX_I2C
+ bool "Support I2C bus on MB862XX GDC"
+ depends on FB_MB862XX && I2C
+ default y
+ help
+ Selecting this option adds Coral-P(A)/Lime GDC I2C bus adapter
+ driver to support accessing I2C devices on controller's I2C bus.
+ These are usually some video decoder chips.
+
config FB_EP93XX
tristate "EP93XX frame buffer support"
depends on FB && ARCH_EP93XX
diff --git a/drivers/video/mb862xx/Makefile b/drivers/video/mb862xx/Makefile
index d777771..5707ed0 100644
--- a/drivers/video/mb862xx/Makefile
+++ b/drivers/video/mb862xx/Makefile
@@ -2,4 +2,7 @@
# Makefile for the MB862xx framebuffer driver
#
-obj-$(CONFIG_FB_MB862XX) := mb862xxfb.o mb862xxfb_accel.o
+obj-$(CONFIG_FB_MB862XX) += mb862xxfb.o
+
+mb862xxfb-y := mb862xxfbdrv.o mb862xxfb_accel.o
+mb862xxfb-$(CONFIG_FB_MB862XX_I2C) += mb862xx-i2c.o
diff --git a/drivers/video/mb862xx/mb862xx-i2c.c b/drivers/video/mb862xx/mb862xx-i2c.c
new file mode 100644
index 0000000..cb77d3b
--- /dev/null
+++ b/drivers/video/mb862xx/mb862xx-i2c.c
@@ -0,0 +1,177 @@
+/*
+ * Coral-P(A)/Lime I2C adapter driver
+ *
+ * (C) 2011 DENX Software Engineering, Anatolij Gustschin <agust@denx.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/fb.h>
+#include <linux/i2c.h>
+#include <linux/io.h>
+
+#include "mb862xxfb.h"
+#include "mb862xx_reg.h"
+
+static int mb862xx_i2c_wait_event(struct i2c_adapter *adap)
+{
+ struct mb862xxfb_par *par = adap->algo_data;
+ u32 reg;
+
+ do {
+ udelay(1);
+ reg = inreg(i2c, GC_I2C_BCR);
+ if (reg & (I2C_INT | I2C_BER))
+ break;
+ } while (1);
+
+ return (reg & I2C_BER) ? 0 : 1;
+}
+
+static int mb862xx_i2c_do_address(struct i2c_adapter *adap, int addr)
+{
+ struct mb862xxfb_par *par = adap->algo_data;
+
+ outreg(i2c, GC_I2C_DAR, addr);
+ outreg(i2c, GC_I2C_CCR, I2C_CLOCK_AND_ENABLE);
+ outreg(i2c, GC_I2C_BCR, par->i2c_rs ? I2C_REPEATED_START : I2C_START);
+ if (!mb862xx_i2c_wait_event(adap))
+ return -EIO;
+ par->i2c_rs = !(inreg(i2c, GC_I2C_BSR) & I2C_LRB);
+ return par->i2c_rs;
+}
+
+static int mb862xx_i2c_write_byte(struct i2c_adapter *adap, u8 byte)
+{
+ struct mb862xxfb_par *par = adap->algo_data;
+
+ outreg(i2c, GC_I2C_DAR, byte);
+ outreg(i2c, GC_I2C_BCR, I2C_START);
+ if (!mb862xx_i2c_wait_event(adap))
+ return -EIO;
+ return !(inreg(i2c, GC_I2C_BSR) & I2C_LRB);
+}
+
+static int mb862xx_i2c_read_byte(struct i2c_adapter *adap, u8 *byte, int last)
+{
+ struct mb862xxfb_par *par = adap->algo_data;
+
+ outreg(i2c, GC_I2C_BCR, I2C_START | (last ? 0 : I2C_ACK));
+ if (!mb862xx_i2c_wait_event(adap))
+ return 0;
+ *byte = inreg(i2c, GC_I2C_DAR);
+ return 1;
+}
+
+void mb862xx_i2c_stop(struct i2c_adapter *adap)
+{
+ struct mb862xxfb_par *par = adap->algo_data;
+
+ outreg(i2c, GC_I2C_BCR, I2C_STOP);
+ outreg(i2c, GC_I2C_CCR, I2C_DISABLE);
+ par->i2c_rs = 0;
+}
+
+static int mb862xx_i2c_read(struct i2c_adapter *adap, struct i2c_msg *m)
+{
+ int i, ret = 0;
+ int last = m->len - 1;
+
+ for (i = 0; i < m->len; i++) {
+ if (!mb862xx_i2c_read_byte(adap, &m->buf[i], i = last)) {
+ ret = -EIO;
+ break;
+ }
+ }
+ return ret;
+}
+
+static int mb862xx_i2c_write(struct i2c_adapter *adap, struct i2c_msg *m)
+{
+ int i, ret = 0;
+
+ for (i = 0; i < m->len; i++) {
+ if (!mb862xx_i2c_write_byte(adap, m->buf[i])) {
+ ret = -EIO;
+ break;
+ }
+ }
+ return ret;
+}
+
+static int mb862xx_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
+ int num)
+{
+ struct mb862xxfb_par *par = adap->algo_data;
+ struct i2c_msg *m;
+ int addr;
+ int i = 0, err = 0;
+
+ dev_dbg(par->dev, "%s: %d msgs\n", __func__, num);
+
+ for (i = 0; i < num; i++) {
+ m = &msgs[i];
+ if (!m->len) {
+ dev_dbg(par->dev, "%s: null msgs\n", __func__);
+ continue;
+ }
+ addr = m->addr;
+ if (m->flags & I2C_M_RD)
+ addr |= 1;
+
+ err = mb862xx_i2c_do_address(adap, addr);
+ if (err < 0)
+ break;
+ if (m->flags & I2C_M_RD)
+ err = mb862xx_i2c_read(adap, m);
+ else
+ err = mb862xx_i2c_write(adap, m);
+ }
+
+ if (i)
+ mb862xx_i2c_stop(adap);
+
+ return (err < 0) ? err : i;
+}
+
+static u32 mb862xx_func(struct i2c_adapter *adap)
+{
+ return I2C_FUNC_SMBUS_BYTE_DATA;
+}
+
+static const struct i2c_algorithm mb862xx_algo = {
+ .master_xfer = mb862xx_xfer,
+ .functionality = mb862xx_func,
+};
+
+static struct i2c_adapter mb862xx_i2c_adapter = {
+ .name = "MB862xx I2C adapter",
+ .algo = &mb862xx_algo,
+ .owner = THIS_MODULE,
+};
+
+int mb862xx_i2c_init(struct mb862xxfb_par *par)
+{
+ int ret;
+
+ mb862xx_i2c_adapter.algo_data = par;
+ par->adap = &mb862xx_i2c_adapter;
+
+ ret = i2c_add_adapter(par->adap);
+ if (ret < 0) {
+ dev_err(par->dev, "failed to add %s\n",
+ mb862xx_i2c_adapter.name);
+ }
+ return ret;
+}
+
+void mb862xx_i2c_exit(struct mb862xxfb_par *par)
+{
+ if (par->adap) {
+ i2c_del_adapter(par->adap);
+ par->adap = NULL;
+ }
+}
diff --git a/drivers/video/mb862xx/mb862xx_reg.h b/drivers/video/mb862xx/mb862xx_reg.h
index 737fc01..5784b01 100644
--- a/drivers/video/mb862xx/mb862xx_reg.h
+++ b/drivers/video/mb862xx/mb862xx_reg.h
@@ -80,6 +80,27 @@
#define GC_DISP_REFCLK_400 400
+/* I2C */
+#define GC_I2C_BSR 0x00000000 /* BSR */
+#define GC_I2C_BCR 0x00000004 /* BCR */
+#define GC_I2C_CCR 0x00000008 /* CCR */
+#define GC_I2C_ADR 0x0000000C /* ADR */
+#define GC_I2C_DAR 0x00000010 /* DAR */
+
+#define I2C_DISABLE 0x00000000
+#define I2C_STOP 0x00000000
+#define I2C_START 0x00000010
+#define I2C_REPEATED_START 0x00000030
+#define I2C_CLOCK_AND_ENABLE 0x0000003f
+#define I2C_READY 0x01
+#define I2C_INT 0x01
+#define I2C_INTE 0x02
+#define I2C_ACK 0x08
+#define I2C_BER 0x80
+#define I2C_BEIE 0x40
+#define I2C_TRX 0x80
+#define I2C_LRB 0x10
+
/* Carmine specific */
#define MB86297_DRAW_BASE 0x00020000
#define MB86297_DISP0_BASE 0x00100000
diff --git a/drivers/video/mb862xx/mb862xxfb.h b/drivers/video/mb862xx/mb862xxfb.h
index d7e7cb7..d5dd7d9 100644
--- a/drivers/video/mb862xx/mb862xxfb.h
+++ b/drivers/video/mb862xx/mb862xxfb.h
@@ -57,11 +57,20 @@ struct mb862xxfb_par {
unsigned int refclk; /* disp. reference clock */
struct mb862xx_gc_mode *gc_mode; /* GDC mode init data */
int pre_init; /* don't init display if 1 */
+ struct i2c_adapter *adap; /* GDC I2C bus adapter */
+ int i2c_rs;
u32 pseudo_palette[16];
};
extern void mb862xxfb_init_accel(struct fb_info *info, int xres);
+#ifdef CONFIG_FB_MB862XX_I2C
+extern int mb862xx_i2c_init(struct mb862xxfb_par *par);
+extern void mb862xx_i2c_exit(struct mb862xxfb_par *par);
+#else
+static inline int mb862xx_i2c_init(struct mb862xxfb_par *par) { return 0; }
+static inline void mb862xx_i2c_exit(struct mb862xxfb_par *par) { }
+#endif
#if defined(CONFIG_FB_MB862XX_LIME) && defined(CONFIG_FB_MB862XX_PCI_GDC)
#error "Select Lime GDC or CoralP/Carmine support, but not both together"
diff --git a/drivers/video/mb862xx/mb862xxfb.c b/drivers/video/mb862xx/mb862xxfbdrv.c
similarity index 99%
rename from drivers/video/mb862xx/mb862xxfb.c
rename to drivers/video/mb862xx/mb862xxfbdrv.c
index ffb6a2c..0cc20b4 100644
--- a/drivers/video/mb862xx/mb862xxfb.c
+++ b/drivers/video/mb862xx/mb862xxfbdrv.c
@@ -772,6 +772,8 @@ static int coralp_init(struct mb862xxfb_par *par)
} else {
return -ENODEV;
}
+
+ mb862xx_i2c_init(par);
return 0;
}
@@ -1029,6 +1031,8 @@ static void __devexit mb862xx_pci_remove(struct pci_dev *pdev)
outreg(host, GC_IMASK, 0);
}
+ mb862xx_i2c_exit(par);
+
device_remove_file(&pdev->dev, &dev_attr_dispregs);
pci_set_drvdata(pdev, NULL);
--
1.7.1
^ permalink raw reply related
* [PATCH v2 5/5] video: mb862xxfb: add support for L1 displaying
From: Anatolij Gustschin @ 2011-05-24 15:05 UTC (permalink / raw)
To: linux-fbdev
Allow displaying L1 video data on top of the primary L0 layer.
The L1 layer position and dimensions can be configured and the
layer enabled/disabled by using the appropriate L1 controls
added by this patch.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
v2:
- rebase to apply cleanly on top of previous 4/5 patch
drivers/video/mb862xx/mb862xx_reg.h | 31 +++++++++
drivers/video/mb862xx/mb862xxfb.h | 27 ++++++++
drivers/video/mb862xx/mb862xxfbdrv.c | 116 +++++++++++++++++++++++++++++++++-
3 files changed, 173 insertions(+), 1 deletions(-)
diff --git a/drivers/video/mb862xx/mb862xx_reg.h b/drivers/video/mb862xx/mb862xx_reg.h
index 5784b01..9df48b8 100644
--- a/drivers/video/mb862xx/mb862xx_reg.h
+++ b/drivers/video/mb862xx/mb862xx_reg.h
@@ -51,10 +51,16 @@
#define GC_L0OA0 0x00000024
#define GC_L0DA0 0x00000028
#define GC_L0DY_L0DX 0x0000002c
+#define GC_L1M 0x00000030
+#define GC_L1DA 0x00000034
#define GC_DCM1 0x00000100
#define GC_L0EM 0x00000110
#define GC_L0WY_L0WX 0x00000114
#define GC_L0WH_L0WW 0x00000118
+#define GC_L1EM 0x00000120
+#define GC_L1WY_L1WX 0x00000124
+#define GC_L1WH_L1WW 0x00000128
+#define GC_DLS 0x00000180
#define GC_DCM2 0x00000104
#define GC_DCM3 0x00000108
#define GC_CPM_CUTC 0x000000a0
@@ -66,6 +72,11 @@
#define GC_CPM_CEN0 0x00100000
#define GC_CPM_CEN1 0x00200000
+#define GC_DCM1_DEN 0x80000000
+#define GC_DCM1_L1E 0x00020000
+#define GC_L1M_16 0x80000000
+#define GC_L1M_YC 0x40000000
+#define GC_L1M_CS 0x20000000
#define GC_DCM01_ESY 0x00000004
#define GC_DCM01_SC 0x00003f00
@@ -77,6 +88,7 @@
#define GC_L0M_L0C_16 0x80000000
#define GC_L0EM_L0EC_24 0x40000000
#define GC_L0M_L0W_UNIT 64
+#define GC_L1EM_DM 0x02000000
#define GC_DISP_REFCLK_400 400
@@ -101,6 +113,25 @@
#define I2C_TRX 0x80
#define I2C_LRB 0x10
+/* Capture registers and bits */
+#define GC_CAP_VCM 0x00000000
+#define GC_CAP_CSC 0x00000004
+#define GC_CAP_VCS 0x00000008
+#define GC_CAP_CBM 0x00000010
+#define GC_CAP_CBOA 0x00000014
+#define GC_CAP_CBLA 0x00000018
+#define GC_CAP_IMG_START 0x0000001C
+#define GC_CAP_IMG_END 0x00000020
+#define GC_CAP_CMSS 0x00000048
+#define GC_CAP_CMDS 0x0000004C
+
+#define GC_VCM_VIE 0x80000000
+#define GC_VCM_CM 0x03000000
+#define GC_VCM_VS_PAL 0x00000002
+#define GC_CBM_OO 0x80000000
+#define GC_CBM_HRV 0x00000010
+#define GC_CBM_CBST 0x00000001
+
/* Carmine specific */
#define MB86297_DRAW_BASE 0x00020000
#define MB86297_DISP0_BASE 0x00100000
diff --git a/drivers/video/mb862xx/mb862xxfb.h b/drivers/video/mb862xx/mb862xxfb.h
index d5dd7d9..8550630 100644
--- a/drivers/video/mb862xx/mb862xxfb.h
+++ b/drivers/video/mb862xx/mb862xxfb.h
@@ -1,6 +1,26 @@
#ifndef __MB862XX_H__
#define __MB862XX_H__
+struct mb862xx_l1_cfg {
+ unsigned short sx;
+ unsigned short sy;
+ unsigned short sw;
+ unsigned short sh;
+ unsigned short dx;
+ unsigned short dy;
+ unsigned short dw;
+ unsigned short dh;
+ int mirror;
+};
+
+#define MB862XX_BASE 'M'
+#define MB862XX_L1_GET_CFG _IOR(MB862XX_BASE, 0, struct mb862xx_l1_cfg*)
+#define MB862XX_L1_SET_CFG _IOW(MB862XX_BASE, 1, struct mb862xx_l1_cfg*)
+#define MB862XX_L1_ENABLE _IOW(MB862XX_BASE, 2, int)
+#define MB862XX_L1_CAP_CTL _IOW(MB862XX_BASE, 3, int)
+
+#ifdef __KERNEL__
+
#define PCI_VENDOR_ID_FUJITSU_LIMITED 0x10cf
#define PCI_DEVICE_ID_FUJITSU_CORALP 0x2019
#define PCI_DEVICE_ID_FUJITSU_CORALPA 0x201e
@@ -38,6 +58,8 @@ struct mb862xxfb_par {
void __iomem *mmio_base; /* remapped registers */
size_t mapped_vram; /* length of remapped vram */
size_t mmio_len; /* length of register region */
+ unsigned long cap_buf; /* capture buffers offset */
+ size_t cap_len; /* length of capture buffers */
void __iomem *host; /* relocatable reg. bases */
void __iomem *i2c;
@@ -60,6 +82,9 @@ struct mb862xxfb_par {
struct i2c_adapter *adap; /* GDC I2C bus adapter */
int i2c_rs;
+ struct mb862xx_l1_cfg l1_cfg;
+ int l1_stride;
+
u32 pseudo_palette[16];
};
@@ -91,4 +116,6 @@ static inline void mb862xx_i2c_exit(struct mb862xxfb_par *par) { }
#define pack(a, b) (((a) << 16) | (b))
+#endif /* __KERNEL__ */
+
#endif
diff --git a/drivers/video/mb862xx/mb862xxfbdrv.c b/drivers/video/mb862xx/mb862xxfbdrv.c
index 0cc20b4..ea39336 100644
--- a/drivers/video/mb862xx/mb862xxfbdrv.c
+++ b/drivers/video/mb862xx/mb862xxfbdrv.c
@@ -27,7 +27,7 @@
#define NR_PALETTE 256
#define MB862XX_MEM_SIZE 0x1000000
-#define CORALP_MEM_SIZE 0x4000000
+#define CORALP_MEM_SIZE 0x2000000
#define CARMINE_MEM_SIZE 0x8000000
#define DRV_NAME "mb862xxfb"
@@ -309,6 +309,97 @@ static int mb862xxfb_blank(int mode, struct fb_info *fbi)
return 0;
}
+static int mb862xxfb_ioctl(struct fb_info *fbi, unsigned int cmd,
+ unsigned long arg)
+{
+ struct mb862xxfb_par *par = fbi->par;
+ struct mb862xx_l1_cfg *l1_cfg = &par->l1_cfg;
+ void __user *argp = (void __user *)arg;
+ int *enable;
+ u32 l1em = 0;
+
+ switch (cmd) {
+ case MB862XX_L1_GET_CFG:
+ if (copy_to_user(argp, l1_cfg, sizeof(*l1_cfg)))
+ return -EFAULT;
+ break;
+ case MB862XX_L1_SET_CFG:
+ if (copy_from_user(l1_cfg, argp, sizeof(*l1_cfg)))
+ return -EFAULT;
+ if ((l1_cfg->sw >= l1_cfg->dw) && (l1_cfg->sh >= l1_cfg->dh)) {
+ /* downscaling */
+ outreg(cap, GC_CAP_CSC,
+ pack((l1_cfg->sh << 11) / l1_cfg->dh,
+ (l1_cfg->sw << 11) / l1_cfg->dw));
+ l1em = inreg(disp, GC_L1EM);
+ l1em &= ~GC_L1EM_DM;
+ } else if ((l1_cfg->sw <= l1_cfg->dw) &&
+ (l1_cfg->sh <= l1_cfg->dh)) {
+ /* upscaling */
+ outreg(cap, GC_CAP_CSC,
+ pack((l1_cfg->sh << 11) / l1_cfg->dh,
+ (l1_cfg->sw << 11) / l1_cfg->dw));
+ outreg(cap, GC_CAP_CMSS,
+ pack(l1_cfg->sw >> 1, l1_cfg->sh));
+ outreg(cap, GC_CAP_CMDS,
+ pack(l1_cfg->dw >> 1, l1_cfg->dh));
+ l1em = inreg(disp, GC_L1EM);
+ l1em |= GC_L1EM_DM;
+ }
+
+ if (l1_cfg->mirror) {
+ outreg(cap, GC_CAP_CBM,
+ inreg(cap, GC_CAP_CBM) | GC_CBM_HRV);
+ l1em |= l1_cfg->dw * 2 - 8;
+ } else {
+ outreg(cap, GC_CAP_CBM,
+ inreg(cap, GC_CAP_CBM) & ~GC_CBM_HRV);
+ l1em &= 0xffff0000;
+ }
+ outreg(disp, GC_L1EM, l1em);
+ break;
+ case MB862XX_L1_ENABLE:
+ enable = (int *)arg;
+ if (*enable) {
+ outreg(disp, GC_L1DA, par->cap_buf);
+ outreg(cap, GC_CAP_IMG_START,
+ pack(l1_cfg->sy >> 1, l1_cfg->sx));
+ outreg(cap, GC_CAP_IMG_END,
+ pack(l1_cfg->sh, l1_cfg->sw));
+ outreg(disp, GC_L1M, GC_L1M_16 | GC_L1M_YC | GC_L1M_CS |
+ (par->l1_stride << 16));
+ outreg(disp, GC_L1WY_L1WX,
+ pack(l1_cfg->dy, l1_cfg->dx));
+ outreg(disp, GC_L1WH_L1WW,
+ pack(l1_cfg->dh - 1, l1_cfg->dw));
+ outreg(disp, GC_DLS, 1);
+ outreg(cap, GC_CAP_VCM,
+ GC_VCM_VIE | GC_VCM_CM | GC_VCM_VS_PAL);
+ outreg(disp, GC_DCM1, inreg(disp, GC_DCM1) |
+ GC_DCM1_DEN | GC_DCM1_L1E);
+ } else {
+ outreg(cap, GC_CAP_VCM,
+ inreg(cap, GC_CAP_VCM) & ~GC_VCM_VIE);
+ outreg(disp, GC_DCM1,
+ inreg(disp, GC_DCM1) & ~GC_DCM1_L1E);
+ }
+ break;
+ case MB862XX_L1_CAP_CTL:
+ enable = (int *)arg;
+ if (*enable) {
+ outreg(cap, GC_CAP_VCM,
+ inreg(cap, GC_CAP_VCM) | GC_VCM_VIE);
+ } else {
+ outreg(cap, GC_CAP_VCM,
+ inreg(cap, GC_CAP_VCM) & ~GC_VCM_VIE);
+ }
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
/* framebuffer ops */
static struct fb_ops mb862xxfb_ops = {
.owner = THIS_MODULE,
@@ -320,6 +411,7 @@ static struct fb_ops mb862xxfb_ops = {
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
.fb_imageblit = cfb_imageblit,
+ .fb_ioctl = mb862xxfb_ioctl,
};
/* initialize fb_info data */
@@ -328,6 +420,7 @@ static int mb862xxfb_init_fbinfo(struct fb_info *fbi)
struct mb862xxfb_par *par = fbi->par;
struct mb862xx_gc_mode *mode = par->gc_mode;
unsigned long reg;
+ int stride;
fbi->fbops = &mb862xxfb_ops;
fbi->pseudo_palette = par->pseudo_palette;
@@ -420,6 +513,27 @@ static int mb862xxfb_init_fbinfo(struct fb_info *fbi)
fbi->fix.line_length = (fbi->var.xres_virtual *
fbi->var.bits_per_pixel) / 8;
fbi->fix.smem_len = fbi->fix.line_length * fbi->var.yres_virtual;
+
+ /*
+ * reserve space for capture buffers and two cursors
+ * at the end of vram: 720x576 * 2 * 2.2 + 64x64 * 16.
+ */
+ par->cap_buf = par->mapped_vram - 0x1bd800 - 0x10000;
+ par->cap_len = 0x1bd800;
+ par->l1_cfg.sx = 0;
+ par->l1_cfg.sy = 0;
+ par->l1_cfg.sw = 720;
+ par->l1_cfg.sh = 576;
+ par->l1_cfg.dx = 0;
+ par->l1_cfg.dy = 0;
+ par->l1_cfg.dw = 720;
+ par->l1_cfg.dh = 576;
+ stride = par->l1_cfg.sw * (fbi->var.bits_per_pixel / 8);
+ par->l1_stride = stride / 64 + ((stride % 64) ? 1 : 0);
+ outreg(cap, GC_CAP_CBM, GC_CBM_OO | GC_CBM_CBST |
+ (par->l1_stride << 16));
+ outreg(cap, GC_CAP_CBOA, par->cap_buf);
+ outreg(cap, GC_CAP_CBLA, par->cap_buf + par->cap_len);
return 0;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 0/5] mb862xxfb driver update for 2.6.40
From: Anatolij Gustschin @ 2011-05-24 15:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1305302089-7666-1-git-send-email-agust@denx.de>
On Fri, 13 May 2011 17:54:44 +0200
Anatolij Gustschin <agust@denx.de> wrote:
> This patch series extends the driver for Coral GDCs to support
> such controller features as video layer L1 and I2C bus for video
> decoder chips. First three patches are small fixes and improvements.
Updated patches addressing comments can be pulled now. I rebased
them to apply on top of current fbdev-2.6 git tree.
The following changes since commit af1ce6b2fad7d572aef040d61a935da28a861853:
video: s3c-fb: correct transparency checking in 32bpp (2011-05-24 18:04:37 +0900)
are available in the git repository at:
git://git.denx.de/linux-2.6-agust.git mb862xxfb-for-next
Anatolij Gustschin (5):
video: mb862xxfb: correct fix.smem_len field initialization
video: mb862xxfb: use pre-initialized configuration for PCI GDCs
video: mb862xxfb: relocate register space to get contiguous vram
video: mb862xx: add support for controller's I2C bus adapter
video: mb862xxfb: add support for L1 displaying
drivers/video/Kconfig | 9 +
drivers/video/mb862xx/Makefile | 5 +-
drivers/video/mb862xx/mb862xx-i2c.c | 177 ++++++++++++++++++++
drivers/video/mb862xx/mb862xx_reg.h | 58 ++++++-
drivers/video/mb862xx/mb862xxfb.h | 36 ++++
.../video/mb862xx/{mb862xxfb.c => mb862xxfbdrv.c} | 152 ++++++++++++++++-
6 files changed, 425 insertions(+), 12 deletions(-)
create mode 100644 drivers/video/mb862xx/mb862xx-i2c.c
rename drivers/video/mb862xx/{mb862xxfb.c => mb862xxfbdrv.c} (86%)
Thanks,
Anatolij
^ permalink raw reply
* [PATCH] fbmem: fix race condition between register_framebuffer() and fb_open()
From: Fabio Erculiani @ 2011-05-24 19:54 UTC (permalink / raw)
To: linux-fbdev; +Cc: lethal, linux-kernel, Fabio Erculiani
register_framebuffer() acquires registration_lock, then calls
do_register_framebuffer() which calls fb_notifier_call_chain()
which calls fb_open() which calls get_fb_info() which tries
(at last) to acquire registration_lock again.
This is a workaround.
Signed-off-by: Fabio Erculiani <lxnay@sabayon.org>
---
drivers/video/fbmem.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 5aac00e..b9831a0 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1628,6 +1628,11 @@ static int do_register_framebuffer(struct fb_info *fb_info)
event.info = fb_info;
if (!lock_fb_info(fb_info))
return -ENODEV;
+
+ /* FIXME: unlock registration mutex before registration
+ * notification is sent, in order to avoid deadlock.
+ */
+ mutex_unlock(®istration_lock);
fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, &event);
unlock_fb_info(fb_info);
return 0;
@@ -1692,7 +1697,13 @@ register_framebuffer(struct fb_info *fb_info)
mutex_lock(®istration_lock);
ret = do_register_framebuffer(fb_info);
- mutex_unlock(®istration_lock);
+ if (ret != 0)
+ /*
+ * FIXME: mutex is unlocked only if ret = 0.
+ * This is the second part of the workaround
+ * that prevents deadlocking.
+ */
+ mutex_unlock(®istration_lock);
return ret;
}
--
1.7.5.rc1
^ permalink raw reply related
* [Patch 1/2] Fix use-after-free by vga16fb on rmmod
From: Bruno Prémont @ 2011-05-24 19:59 UTC (permalink / raw)
To: linux-fbdev
Since fb_info is now refcounted and thus may get freed at any time it
gets unregistered module unloading will try to unregister framebuffer
as stored in platform data on probe though this pointer may
be stale.
Cleanup platform data on framebuffer release.
CC: stable@kernel.org
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
---
This should also go into 2.6.39 stable as it didn't make it into 2.6.39
with the rest of fb_info refcounting work.
This comes from
[2.6.39-rc2, framebuffer] use after free oops
...
[PATCH 0/2] fbcon sanity
thread
---
diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c
index 53b2c5a..2bcfe32 100644
--- a/drivers/video/vga16fb.c
+++ b/drivers/video/vga16fb.c
@@ -1265,9 +1265,11 @@ static void vga16fb_imageblit(struct fb_info *info, const struct fb_image *image
static void vga16fb_destroy(struct fb_info *info)
{
+ struct platform_device *dev = container_of(info->device, struct platform_device, dev);
iounmap(info->screen_base);
fb_dealloc_cmap(&info->cmap);
/* XXX unshare VGA regions */
+ platform_set_drvdata(dev, NULL);
framebuffer_release(info);
}
^ permalink raw reply related
* [Patch 2/2 resend] Prevent vga16fb from accessing hw after it was
From: Bruno Prémont @ 2011-05-24 20:32 UTC (permalink / raw)
To: linux-fbdev
Since fb_info is refcounted it can successfully remain open while
being unregistered (though not freed).
Prevent the following sequence to corrupt modify hardware state
behind back of native driver that took over control of hardware:
- vga16fb registered
+ open /dev/fb0 (vga16fb)
- load native driver
- unregisters conflicting vga16fb
- configures GPU with nouveaufb and more
- fbcon takes over
+ close /dev/fb0
+ vga16fb resets hw to vgacon mode (in fbops.fb_release)
Add a new callback fb_unregistered to struct fbops to be called
at end of unregister_framebuffer() so interested drivers can
get know their fb was unregistered (previously they would know
through fb_destroy callback but now that callback may happen
way later)
Prevent such hardware access by setting a flag with new fb_unregistered
callback and checking it when vga16fb framebuffer is last closed and
skipping vga state restore in case it's not registered anymore.
CC: stable@kernel.org
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
---
Resend as my MUA decided to take wrong source address...
This should also go into 2.6.39 stable as it didn't make it into 2.6.39
with the rest of fb_info refcounting work.
This comes from
[2.6.39-rc2, framebuffer] use after free oops
...
[PATCH 0/2] fbcon sanity
thread
---
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 5aac00e..bd9f93b 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1661,6 +1661,11 @@ static int do_unregister_framebuffer(struct fb_info *fb_info)
device_destroy(fb_class, MKDEV(FB_MAJOR, i));
event.info = fb_info;
fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
+ if (fb_info->fbops->fb_unregistered) {
+ mutex_lock(&fb_info->lock);
+ fb_info->fbops->fb_unregistered(fb_info);
+ mutex_unlock(&fb_info->lock);
+ }
/* this may free fb info */
put_fb_info(fb_info);
diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c
index 53b2c5a..dad96e1 100644
--- a/drivers/video/vga16fb.c
+++ b/drivers/video/vga16fb.c
@@ -59,7 +59,7 @@ struct vga16fb_par {
struct vgastate state;
unsigned int ref_count;
int palette_blanked, vesa_blanked, mode, isVGA;
- u8 misc, pel_msk, vss, clkdiv;
+ u8 misc, pel_msk, vss, clkdiv, unregistered;
u8 crtc[VGA_CRT_C];
};
@@ -302,7 +302,7 @@ static int vga16fb_release(struct fb_info *info, int user)
if (!par->ref_count)
return -EINVAL;
- if (par->ref_count = 1)
+ if (par->ref_count = 1 && !par->unregistered)
restore_vga(&par->state);
par->ref_count--;
@@ -1271,19 +1271,26 @@ static void vga16fb_destroy(struct fb_info *info)
framebuffer_release(info);
}
+static void vga16fb_unregistered(struct fb_info *info)
+{
+ struct vga16fb_par *par = info->par;
+ par->unregistered = 1;
+}
+
static struct fb_ops vga16fb_ops = {
- .owner = THIS_MODULE,
- .fb_open = vga16fb_open,
- .fb_release = vga16fb_release,
- .fb_destroy = vga16fb_destroy,
- .fb_check_var = vga16fb_check_var,
- .fb_set_par = vga16fb_set_par,
- .fb_setcolreg = vga16fb_setcolreg,
- .fb_pan_display = vga16fb_pan_display,
- .fb_blank = vga16fb_blank,
- .fb_fillrect = vga16fb_fillrect,
- .fb_copyarea = vga16fb_copyarea,
- .fb_imageblit = vga16fb_imageblit,
+ .owner = THIS_MODULE,
+ .fb_open = vga16fb_open,
+ .fb_release = vga16fb_release,
+ .fb_destroy = vga16fb_destroy,
+ .fb_unregistered = vga16fb_unregistered,
+ .fb_check_var = vga16fb_check_var,
+ .fb_set_par = vga16fb_set_par,
+ .fb_setcolreg = vga16fb_setcolreg,
+ .fb_pan_display = vga16fb_pan_display,
+ .fb_blank = vga16fb_blank,
+ .fb_fillrect = vga16fb_fillrect,
+ .fb_copyarea = vga16fb_copyarea,
+ .fb_imageblit = vga16fb_imageblit,
};
#ifndef MODULE
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 6a82748..22a8796 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -685,6 +685,9 @@ struct fb_ops {
void (*fb_get_caps)(struct fb_info *info, struct fb_blit_caps *caps,
struct fb_var_screeninfo *var);
+ /* teardown hardware for this framebuffer (another driver may get
+ * ownership of hardware after this returns) */
+ void (*fb_unregistered)(struct fb_info *info);
/* teardown any resources to do with this framebuffer */
void (*fb_destroy)(struct fb_info *info);
^ permalink raw reply related
* Re: [PATCH] fbmem: fix race condition between
From: Bruno Prémont @ 2011-05-24 20:45 UTC (permalink / raw)
To: Fabio Erculiani; +Cc: linux-fbdev, lethal, linux-kernel
In-Reply-To: <1306266871-12464-1-git-send-email-lxnay@sabayon.org>
On Tue, 24 May 2011 Fabio Erculiani <lxnay@sabayon.org> wrote:
> register_framebuffer() acquires registration_lock, then calls
> do_register_framebuffer() which calls fb_notifier_call_chain()
> which calls fb_open() which calls get_fb_info() which tries
> (at last) to acquire registration_lock again.
> This is a workaround.
What calls fb_open() instead of just calling fb_info->fbops->fb_open
when it is set?
In other words what kernel handler of fb_notifier chain does file-based
open of the framebuffer or is the event pushed out synchronously to
userspace?
> Signed-off-by: Fabio Erculiani <lxnay@sabayon.org>
> ---
> drivers/video/fbmem.c | 13 ++++++++++++-
> 1 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 5aac00e..b9831a0 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1628,6 +1628,11 @@ static int do_register_framebuffer(struct fb_info *fb_info)
> event.info = fb_info;
> if (!lock_fb_info(fb_info))
> return -ENODEV;
> +
> + /* FIXME: unlock registration mutex before registration
> + * notification is sent, in order to avoid deadlock.
> + */
> + mutex_unlock(®istration_lock);
> fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, &event);
> unlock_fb_info(fb_info);
> return 0;
> @@ -1692,7 +1697,13 @@ register_framebuffer(struct fb_info *fb_info)
>
> mutex_lock(®istration_lock);
> ret = do_register_framebuffer(fb_info);
> - mutex_unlock(®istration_lock);
> + if (ret != 0)
> + /*
> + * FIXME: mutex is unlocked only if ret = 0.
> + * This is the second part of the workaround
> + * that prevents deadlocking.
> + */
> + mutex_unlock(®istration_lock);
>
> return ret;
> }
^ permalink raw reply
* Re: [PATCH 0/5] mb862xxfb driver update for 2.6.40
From: Paul Mundt @ 2011-05-25 2:07 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1305302089-7666-1-git-send-email-agust@denx.de>
On Tue, May 24, 2011 at 05:14:29PM +0200, Anatolij Gustschin wrote:
> On Fri, 13 May 2011 17:54:44 +0200
> Anatolij Gustschin <agust@denx.de> wrote:
>
> > This patch series extends the driver for Coral GDCs to support
> > such controller features as video layer L1 and I2C bus for video
> > decoder chips. First three patches are small fixes and improvements.
>
> Updated patches addressing comments can be pulled now. I rebased
> them to apply on top of current fbdev-2.6 git tree.
>
> The following changes since commit af1ce6b2fad7d572aef040d61a935da28a861853:
>
> video: s3c-fb: correct transparency checking in 32bpp (2011-05-24 18:04:37 +0900)
>
> are available in the git repository at:
> git://git.denx.de/linux-2.6-agust.git mb862xxfb-for-next
>
Pulled, thanks.
^ permalink raw reply
* [GIT PULL] fbdev updates for 2.6.40-rc1
From: Paul Mundt @ 2011-05-25 8:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-fbdev, linux-kernel
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/lethal/fbdev-2.6.git
Which contains:
Amber Jain (5):
OMAP: DSS2: Add new color formats for OMAP4
OMAP: DSS2: Ensure non-zero FIR values are configured
OMAP: DSS2: Use for loop where ever possible in SR(), RR()
OMAP: DSS2: Add new registers for NV12 support
OMAP: DSS2: Add support for NV12 format
Anatolij Gustschin (5):
video: mb862xxfb: correct fix.smem_len field initialization
video: mb862xxfb: use pre-initialized configuration for PCI GDCs
video: mb862xxfb: relocate register space to get contiguous vram
video: mb862xx: add support for controller's I2C bus adapter
video: mb862xxfb: add support for L1 displaying
Archit Taneja (24):
OMAP: DSS2: Fix: Return correct lcd clock source for OMAP2/3
OMAP: DSS2: Fix: Return correct lcd clock source for OMAP2/3
OMAP4: DSS2: Register configuration changes for DSI
OMAP: DSS2: DSI: Introduce sync_vc functions
OMAP2PLUS: DSS2: Change enum "dss_clk_source" to "omap_dss_clk_source"
OMAP2PLUS: DSS2: Add clock sources to dss device clock configuration
OMAP: DSS2: HDMI: Use dss_device clock configuration for HDMI PLL parameters
OMAP2PLUS: DSS2: Remove hack config "CONFIG_OMAP2_DSS_USE_DSI_PLL"
OMAP2PLUS: DSS2: Clean up omap_display_init()
OMAP: DSS2: DSI: enable scp clock in dsi_dump_regs()
OMAP: DSS2: Clean up DISPC overlay register definitions
OMAP: DSS2: Clean up DISPC overlay manager register definitions
OMAP: DSS2: Remove usage of struct dispc_reg
OMAP: DSS2: DSI: Add extra omap_dss_device argument in functions exported by dsi
OMAP: DSS2: Remove omap_dss_device argument from dsi_pll_init()
OMAP: DSS2: Pass platform_device as an argument in dsi functions
OMAP: DSS2: DSI: Use platform_device pointer to get dsi data
OMAP: DSS2: DSI: Pass pointer to struct to packet_sent_handler isrs
OMAP4: DSS2: DSI: Changes for DSI2 on OMAP4
OMAP: DSS2: Taal: Use device name in backlight_device_register
OMAP: DSS2: DSI: Remove DISPC pixel clock related info in dsi_dump_clocks()
OMAP: DSS2: DSI: Use system workqueue for delayed work instead of a private workqueue
OMAP: DSS2: DSI: Get number of DSI data lanes using DSI_GNQ register
OMAP: DSS2: DSI: Get line buffer size from DSI_GNQ register
Axel Lin (1):
video: da8xx-fb: fix section mismatch warning
Ben Hutchings (1):
video: mb862xxfb: Require either FB_MB862XX_PCI_GDC or FB_MB862XX_LIME
Damian (3):
sh_mobile_meram: MERAM framework for LCDC
sh_mobile_meram: Add support for NV24 framebuffers
sh_mobile_meram: Safely disable MERAM operation when not initialized
Enric Balletbo i Serra (2):
OMAP: DSS2: Support for Seiko 70WVW1TZ3
OMAP: DSS2: Support for Powertip PH480272T
Geert Uytterhoeven (3):
fbdev/amifb: Correct check for video memory size
fbdev/amifb: Do not call panic() if there's not enough Chip RAM
fbdev/amifb: Remove superfluous alignment of frame buffer memory
Guennadi Liakhovetski (3):
fbdev: sh_mobile_hdmi: runtime suspend HDMI on error and clean up paths
fbdev: sh_mobile_lcdc: reduce scope of a variable
fbdev: sh_mobile_lcdc: remove runtime PM calls from the notifier
Jani Nikula (2):
OMAP: DSS2: Add method for querying display dimensions from DSS drivers
OMAP: DSS2: OMAPFB: Remove implicit display update on unblank
Jingoo Han (7):
video: s3c-fb: make runtime pm functions static
video: s3c-fb: add spinlock to interrupt routine
video: s3c-fb: correct window osd size offset values
video: s3c-fb: add additional validate bpps
video: s3c-fb: add window variant information for S5P
video: s3c-fb: add gpio setup function to resume function
video: s3c-fb: correct transparency checking in 32bpp
Julia Lawall (3):
drivers/video: Convert release_resource to release_mem_region
drivers/video/sm501fb.c: Convert release_resource to release_mem_region
drivers/video/s3c2410fb.c: Convert release_resource to release_mem_region
Konstantin Khlebnikov (1):
efifb: fix int to pointer cast warning
Liu Yuan (1):
video, udlfb: Fix two build warnings about 'ignoring return value'
Mike Frysinger (1):
OMAP2: avoid descending into disabled framebuffer dirs
Niels de Vos (1):
OMAP: DSS2: OMAPFB: make DBG() more resistant in if-else constructions
Ondrej Zary (1):
s3fb: add DDC support
Paul Mundt (1):
s3fb: fix up DDC build with MTRR disabled.
Ricardo Neri (5):
OMAP4: DSS2: Create a DSS features structure for OMAP4430 ES1.0
OMAP4: DSS2: HDMI: Add DSS feature for CTS calculation
OMAP4: DSS2: HDMI: Add enums and structures for audio
OMAP4: DSS2: HDMI: Add functionality for audio configuration
OMAP4: DSS2: HDMI: Implement ASoC Codec driver for HDMI audio
Stephen Rothwell (1):
udlfb: include prefetch.h explicitly
Tomi Valkeinen (52):
OMAP: DSS2: DSI: fix use_sys_clk & highfreq
OMAP: DSS2: DSI: fix dsi_dump_clocks()
OMAP: DSS2: DSI: Fix DSI PLL power bug
OMAP: DSS2: fix panel Kconfig dependencies
OMAP: DSS2: Move display.h to include/video/
OMAP: DSS2: Move panel-generic-dpi.h to include/video/
OMAP: DSS2: Move nokia-dsi-panel.h to include/video/
OMAP: DSS2: DSI: fix use_sys_clk & highfreq
OMAP: DSS2: DSI: fix dsi_dump_clocks()
OMAP: DSS2: DSI: Fix DSI PLL power bug
OMAP: DSS2: fix panel Kconfig dependencies
OMAP: DSS2: move dss device clock configuration
OMAP: DSS2: remove non-working msleep(40) workaround
OMAP: DSS2: make 50ms bug-fix sleep optional
OMAP: DSS2: VENC: make 20ms venc bug-fix sleep optional
OMAP: DSS2: VENC: Remove sleeps at venc enable/disable
OMAP: DSS2: OMAPFB: Handle errors when initializing panel
OMAP: DSS2: VENC: Add missing start/stop_device calls
OMAP: DSS2: make omap_dss_(un)register_device static
OMAP: DSS2: use __exit for selected panel drivers
OMAP: DSS2: Convert simple/strict_strto* to kstrto*
OMAP: DSS2: improve clock debugfs output
OMAP: DSS2: DSI: Add lane override functions
OMAP: DSS2: DSI: Remove CIO LDO status check
OMAP: DSS2: DSI: implement ULPS enter and exit
OMAP: DSS2: DSI: add option to leave DSI lanes powered on
OMAP: DSS2: DSI: rename complexio related functions
OMAP: DSS2: Add FEAT_DSI_REVERSE_TXCLKESC
OMAP: DSS2: DSI: fix _dsi_print_reset_status
OMAP: DSS2: DSI: implement enable/disable SCP clk
OMAP: DSS2: DSI: fix CIO init and uninit
OMAP: DSS2: DSI: wait for TXCLKESC domain to come out of reset
OMAP: DSS2: DSI: add parameter to enter ulps on disable
OMAP: DSS2: DSI: Add DSI pad muxing support
OMAP: DSS2: DSI: ensure VDDS_DSI is disabled on exit
OMAP: DSS2: Taal: Implement configurable ESD interval
OMAP: DSS2: Taal: Clean up ESD queueing
OMAP: DSS2: Taal: Add sysfs file for ESD interval
OMAP: DSS2: Taal: Separate panel reset
OMAP: DSS2: Taal: Rename esd_wq to workqueue
OMAP: DSS2: Taal: Implement ULPS functionality
OMAP: DSS2: DSI: Add OMAP4 CIO irqs
OMAP: DSS2: FEATURES: Add missing consts
OMAP: DSS2: Remove DSS_IRQSTATUS
OMAP: DSS2: Add missing dummy functions
OMAPFB: fix wrong clock aliases and device name
OMAP: DSS2: RFBI: add rfbi_bus_lock
OMAP: DSS2: RFBI: clock enable/disable changes
OMAP: DSS2: RFBI: add omap_rfbi_configure
OMAP: DSS2: RFBI: cleanup
OMAP: DSS2: OMAPFB: remove dead code
OMAP: DSS2: OMAPFB: Reduce stack usage
Tormod Volden (2):
savagefb: New S3_TWISTER and S3_PROSAVAGEDDR chip families
savagefb: Enable LCD detection on mobile Twister
Vikram Pandita (1):
OMAP: DSS2: DSI: enable interface for omap4
arch/arm/mach-omap2/board-3430sdp.c | 4 +-
arch/arm/mach-omap2/board-4430sdp.c | 11 +-
arch/arm/mach-omap2/board-am3517evm.c | 4 +-
arch/arm/mach-omap2/board-cm-t35.c | 4 +-
arch/arm/mach-omap2/board-devkit8000.c | 4 +-
arch/arm/mach-omap2/board-igep0020.c | 4 +-
arch/arm/mach-omap2/board-omap3beagle.c | 4 +-
arch/arm/mach-omap2/board-omap3evm.c | 4 +-
arch/arm/mach-omap2/board-omap3pandora.c | 2 +-
arch/arm/mach-omap2/board-omap3stalker.c | 4 +-
arch/arm/mach-omap2/board-omap4panda.c | 4 +-
arch/arm/mach-omap2/board-overo.c | 4 +-
arch/arm/mach-omap2/board-rx51-video.c | 2 +-
arch/arm/mach-omap2/board-zoom-display.c | 2 +-
arch/arm/mach-omap2/display.c | 77 +-
arch/arm/mach-omap2/include/mach/board-zoom.h | 2 +-
drivers/media/video/omap/omap_vout.c | 2 +-
drivers/media/video/omap/omap_voutdef.h | 2 +-
drivers/video/Kconfig | 42 +-
drivers/video/Makefile | 1 +
drivers/video/amifb.c | 27 +-
drivers/video/da8xx-fb.c | 4 +-
drivers/video/efifb.c | 4 +-
drivers/video/mb862xx/Makefile | 5 +-
drivers/video/mb862xx/mb862xx-i2c.c | 177 ++
drivers/video/mb862xx/mb862xx_reg.h | 58 +-
drivers/video/mb862xx/mb862xxfb.h | 36 +
.../video/mb862xx/{mb862xxfb.c => mb862xxfbdrv.c} | 152 ++-
drivers/video/omap/dispc.c | 4 +-
drivers/video/omap/omapfb_main.c | 2 +-
drivers/video/omap/rfbi.c | 2 +-
drivers/video/omap2/Makefile | 4 +-
drivers/video/omap2/displays/Kconfig | 9 +-
drivers/video/omap2/displays/panel-acx565akm.c | 2 +-
drivers/video/omap2/displays/panel-generic-dpi.c | 57 +-
.../omap2/displays/panel-lgphilips-lb035q02.c | 2 +-
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 2 +-
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 6 +-
drivers/video/omap2/displays/panel-taal.c | 536 ++++-
.../video/omap2/displays/panel-tpo-td043mtea1.c | 10 +-
drivers/video/omap2/dss/Kconfig | 33 +-
drivers/video/omap2/dss/core.c | 15 +-
drivers/video/omap2/dss/dispc.c | 1552 +++++++------
drivers/video/omap2/dss/dispc.h | 691 ++++++
drivers/video/omap2/dss/display.c | 46 +-
drivers/video/omap2/dss/dpi.c | 113 +-
drivers/video/omap2/dss/dsi.c | 2367 +++++++++++++-------
drivers/video/omap2/dss/dss.c | 118 +-
drivers/video/omap2/dss/dss.h | 98 +-
drivers/video/omap2/dss/dss_features.c | 105 +-
drivers/video/omap2/dss/dss_features.h | 39 +-
drivers/video/omap2/dss/hdmi.c | 461 ++++-
drivers/video/omap2/dss/hdmi.h | 222 ++-
drivers/video/omap2/dss/hdmi_omap4_panel.c | 2 +-
drivers/video/omap2/dss/manager.c | 14 +-
drivers/video/omap2/dss/overlay.c | 43 +-
drivers/video/omap2/dss/rfbi.c | 176 +--
drivers/video/omap2/dss/sdi.c | 2 +-
drivers/video/omap2/dss/venc.c | 23 +-
drivers/video/omap2/omapfb/omapfb-ioctl.c | 14 +-
drivers/video/omap2/omapfb/omapfb-main.c | 231 ++-
drivers/video/omap2/omapfb/omapfb-sysfs.c | 23 +-
drivers/video/omap2/omapfb/omapfb.h | 8 +-
drivers/video/s3c-fb.c | 121 +-
drivers/video/s3c2410fb.c | 8 +-
drivers/video/s3fb.c | 209 ++-
drivers/video/savage/savagefb-i2c.c | 2 +
drivers/video/savage/savagefb.h | 8 +-
drivers/video/savage/savagefb_driver.c | 15 +-
drivers/video/sh7760fb.c | 6 +-
drivers/video/sh_mobile_hdmi.c | 10 +-
drivers/video/sh_mobile_lcdcfb.c | 126 +-
drivers/video/sh_mobile_lcdcfb.h | 1 +
drivers/video/sh_mobile_meram.c | 567 +++++
drivers/video/sh_mobile_meram.h | 41 +
drivers/video/sm501fb.c | 24 +-
drivers/video/udlfb.c | 20 +-
.../video/omap-panel-generic-dpi.h | 8 +-
.../video/omap-panel-nokia-dsi.h | 14 +-
.../plat/display.h => include/video/omapdss.h | 114 +-
include/video/sh_mobile_lcdc.h | 3 +
include/video/sh_mobile_meram.h | 68 +
82 files changed, 6771 insertions(+), 2272 deletions(-)
create mode 100644 drivers/video/mb862xx/mb862xx-i2c.c
rename drivers/video/mb862xx/{mb862xxfb.c => mb862xxfbdrv.c} (86%)
create mode 100644 drivers/video/omap2/dss/dispc.h
create mode 100644 drivers/video/sh_mobile_meram.c
create mode 100644 drivers/video/sh_mobile_meram.h
rename arch/arm/plat-omap/include/plat/panel-generic-dpi.h => include/video/omap-panel-generic-dpi.h (86%)
rename arch/arm/plat-omap/include/plat/nokia-dsi-panel.h => include/video/omap-panel-nokia-dsi.h (65%)
rename arch/arm/plat-omap/include/plat/display.h => include/video/omapdss.h (85%)
create mode 100644 include/video/sh_mobile_meram.h
^ permalink raw reply
* Re: [PATCH] viafb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-05-25 9:41 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-fbdev, linux-kernel, stable
In-Reply-To: <1306188446-5160-1-git-send-email-FlorianSchandinat@gmx.de>
Hi Florian,
On Tuesday 24 May 2011 00:07:26 Florian Tobias Schandinat wrote:
> As Laurent pointed out we must not use any information in the passed
> var besides xoffset, yoffset and vmode as otherwise applications
> might abuse it. Also use the aligned fix.line_length and not the
> (possible) unaligned xres_virtual.
>
> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: stable@kernel.org
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/video/via/viafbdev.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
> index 3114a87..aa87529 100644
> --- a/drivers/video/via/viafbdev.c
> +++ b/drivers/video/via/viafbdev.c
> @@ -348,8 +348,9 @@ static int viafb_pan_display(struct fb_var_screeninfo
> *var, struct fb_info *info)
> {
> struct viafb_par *viapar = info->par;
> - u32 vram_addr = (var->yoffset * var->xres_virtual + var->xoffset)
> - * (var->bits_per_pixel / 8) + viapar->vram_addr;
> + u32 vram_addr = viapar->vram_addr
> + + var->yoffset * info->fix.line_length
> + + var->xoffset * info->var.bits_per_pixel / 8;
>
> DEBUG_MSG(KERN_DEBUG "viafb_pan_display, address = %d\n", vram_addr);
> if (!viafb_dual_fb) {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] fbmem: fix race condition between
From: Bruno Prémont @ 2011-05-25 16:19 UTC (permalink / raw)
To: Fabio Erculiani; +Cc: linux-fbdev, lethal, linux-kernel
In-Reply-To: <20110524224545.08c53b1d@neptune.home>
On Tue, 24 May 2011 Bruno Prémont <bonbons@linux-vserver.org> wrote:
> On Tue, 24 May 2011 Fabio Erculiani <lxnay@sabayon.org> wrote:
> > register_framebuffer() acquires registration_lock, then calls
> > do_register_framebuffer() which calls fb_notifier_call_chain()
> > which calls fb_open() which calls get_fb_info() which tries
> > (at last) to acquire registration_lock again.
> > This is a workaround.
>
> What calls fb_open() instead of just calling fb_info->fbops->fb_open
> when it is set?
> In other words what kernel handler of fb_notifier chain does file-based
> open of the framebuffer or is the event pushed out synchronously to
> userspace?
Note that fb_info->lock is also taken on both sides:
- per definition around all fb_notifier_call_chain() calls
- as well in fb_open() to protect fb_info->fb_ops->fb_open call.
Bruno
> > Signed-off-by: Fabio Erculiani <lxnay@sabayon.org>
> > ---
> > drivers/video/fbmem.c | 13 ++++++++++++-
> > 1 files changed, 12 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> > index 5aac00e..b9831a0 100644
> > --- a/drivers/video/fbmem.c
> > +++ b/drivers/video/fbmem.c
> > @@ -1628,6 +1628,11 @@ static int do_register_framebuffer(struct fb_info *fb_info)
> > event.info = fb_info;
> > if (!lock_fb_info(fb_info))
> > return -ENODEV;
> > +
> > + /* FIXME: unlock registration mutex before registration
> > + * notification is sent, in order to avoid deadlock.
> > + */
> > + mutex_unlock(®istration_lock);
> > fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, &event);
> > unlock_fb_info(fb_info);
> > return 0;
> > @@ -1692,7 +1697,13 @@ register_framebuffer(struct fb_info *fb_info)
> >
> > mutex_lock(®istration_lock);
> > ret = do_register_framebuffer(fb_info);
> > - mutex_unlock(®istration_lock);
> > + if (ret != 0)
> > + /*
> > + * FIXME: mutex is unlocked only if ret = 0.
> > + * This is the second part of the workaround
> > + * that prevents deadlocking.
> > + */
> > + mutex_unlock(®istration_lock);
> >
> > return ret;
> > }
^ 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