* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-07-11 15:32 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Geert Uytterhoeven, Paul Mundt, linux-fbdev, linux-media,
dri-devel
In-Reply-To: <4E04E975.2060003@gmx.de>
On Friday 24 June 2011 21:45:57 Florian Tobias Schandinat wrote:
> On 06/24/2011 06:55 PM, Geert Uytterhoeven wrote:
> > On Fri, Jun 24, 2011 at 08:19, Paul Mundt wrote:
> >> On Thu, Jun 23, 2011 at 06:08:03PM +0200, Geert Uytterhoeven wrote:
> >>> On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat wrote:
> >>>> On 06/21/2011 10:31 PM, Laurent Pinchart wrote:
> >>>>> On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote:
> >>>>>> As FOURCC values are always 4 ASCII characters (hence all 4 bytes
> >>>>>> must be non-zero), I don't think there are any conflicts with
> >>>>>> existing values of
> >>>>>> nonstd. To make it even safer and easier to parse, you could set bit
> >>>>>> 31 of
> >>>>>> nonstd as a FOURCC indicator.
> >>>>>
> >>>>> I would then create a union between nonstd and fourcc, and document
> >>>>> nonstd as
> >>>>> being used for the legacy API only. Most existing drivers use a
> >>>>> couple of nonstd bits only. The driver that (ab)uses nonstd the most
> >>>>> is pxafb and uses
> >>>>> bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd&
> >>>>> 0xff000000 != 0 could be used as a FOURCC mode test.
> >>>>>
> >>>>> This assumes that FOURCCs will never have their last character set to
> >>>>> '\0'. Is
> >>>>> that a safe assumption for the future ?
> >>>>
> >>>> Yes, I think. The information I found indicates that space should be
> >>>> used for padding, so a \0 shouldn't exist.
> >>>> I think using only the nonstd field and requiring applications to
> >>>> check the capabilities would be possible, although not fool proof ;)
> >>>
> >>> So we can declare the 8 msb bits of nonstd reserved, and assume FOURCC
> >>> if any of them is set.
> >>>
> >>> Nicely backwards compatible, as sane drivers should reject nonstd
> >>> values they don't support (apps _will_ start filling in FOURCC values
> >>> ignoring capabilities, won't they?).
> >>
> >> That seems like a reasonable case, but if we're going to do that then
> >> certainly the nonstd bit encoding needs to be documented and treated as
> >> a hard ABI.
> >>
> >> I'm not so sure about the if any bit in the upper byte is set assume
> >> FOURCC case though, there will presumably be other users in the future
> >> that will want bits for themselves, too. What exactly was the issue with
> >> having a FOURCC capability bit in the upper byte?
> >
> > That indeed gives less issues (as long as you don't stuff 8-bit ASCII
> > in the MSB) and more bits for tradiditional nonstd users.
>
> The only disadvantage I can see is that it requires adding this bit in the
> application and stripping it when interpreting it. But I think the 24 lower
> bits should be enough for driver specific behavior (as the current values
> really can only be interpreted per driver).
I'm also not keen on adding/stripping the MSB. It would be easier for
applications to use FOURCCs directly.
> > BTW, after giving it some more thought: what does the FB_CAP_FOURCC buys
> > us? It's not like all drivers will support whatever random FOURCC mode
> > you give them, so you have to check whether it's supported by doing a
> > set_var first.
>
> Because any solution purely based on the nonstd field is insane. The abuse
> of that field is just too widespread. Drivers that use nonstd usually only
> check whether it is zero or nonzero and others will just interpret parts
> of nonstd and ignore the rest. They will happily accept FOURCC values in
> the nonstd and just doing the wrong thing. Even if we would fix those the
> problems applications will run into with older kernels will remain.
I agree with Florian here. Many drivers currently check whether nonstd != 0.
Who knows what kind of values applications feed them ?
I'd like to reach an agreement on the API, and implement it. I'm fine with
either grayscale or nonstd to store the FOURCC (with a slight preference for
grayscale), and with either a vmode flag or using the most significant byte of
the grayscale/nonstd field to detect FOURCC mode. I believe FB_CAP_FOURCC (or
something similar) is needed.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] fbdev: sh_mobile_lcdc: Turn dot clock on before resuming
From: Guennadi Liakhovetski @ 2011-07-12 9:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1310387754-23033-1-git-send-email-laurent.pinchart@ideasonboard.com>
On Mon, 11 Jul 2011, Laurent Pinchart wrote:
> Resuming from runtime PM restores all LCDC registers. If the dot clock
> is off at that time display panning information will be corrupted.
>
> Turn the dot clock on before resuming from runtime PM. Similarly,
> turn the clock off after suspending the LCDC.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Damian Hobson-Garcia <dhobsong@igel.co.jp>
(testing would have been a bit easier, if prerequisites had been specified
in the patch;))
Tested-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Thanks
Guennadi
> ---
> drivers/video/sh_mobile_lcdcfb.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> This patch should fix the LCDC panning issue caused by runtime suspend. It
> applies on top of Rafael J. Wysocki's pm-domains branch and Damian
> Hobson-Garcia's MERAM patches.
>
> diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
> index 48a40e3..e9b80bc 100644
> --- a/drivers/video/sh_mobile_lcdcfb.c
> +++ b/drivers/video/sh_mobile_lcdcfb.c
> @@ -256,9 +256,9 @@ struct sh_mobile_lcdc_sys_bus_ops sh_mobile_lcdc_sys_bus_ops = {
> static void sh_mobile_lcdc_clk_on(struct sh_mobile_lcdc_priv *priv)
> {
> if (atomic_inc_and_test(&priv->hw_usecnt)) {
> - pm_runtime_get_sync(priv->dev);
> if (priv->dot_clk)
> clk_enable(priv->dot_clk);
> + pm_runtime_get_sync(priv->dev);
> if (priv->meram_dev && priv->meram_dev->pdev)
> pm_runtime_get_sync(&priv->meram_dev->pdev->dev);
> }
> @@ -267,11 +267,11 @@ static void sh_mobile_lcdc_clk_on(struct sh_mobile_lcdc_priv *priv)
> static void sh_mobile_lcdc_clk_off(struct sh_mobile_lcdc_priv *priv)
> {
> if (atomic_sub_return(1, &priv->hw_usecnt) = -1) {
> - if (priv->dot_clk)
> - clk_disable(priv->dot_clk);
> if (priv->meram_dev && priv->meram_dev->pdev)
> pm_runtime_put_sync(&priv->meram_dev->pdev->dev);
> pm_runtime_put(priv->dev);
> + if (priv->dot_clk)
> + clk_disable(priv->dot_clk);
> }
> }
>
> --
> Regards,
>
> Laurent Pinchart
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH] fbdev: sh_mobile_lcdc: Turn dot clock on before resuming from runtime PM
From: Laurent Pinchart @ 2011-07-12 9:37 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1310387754-23033-1-git-send-email-laurent.pinchart@ideasonboard.com>
On Tuesday 12 July 2011 11:33:09 Guennadi Liakhovetski wrote:
> On Mon, 11 Jul 2011, Laurent Pinchart wrote:
> > Resuming from runtime PM restores all LCDC registers. If the dot clock
> > is off at that time display panning information will be corrupted.
> >
> > Turn the dot clock on before resuming from runtime PM. Similarly,
> > turn the clock off after suspending the LCDC.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Cc: Magnus Damm <magnus.damm@gmail.com>
> > Cc: Damian Hobson-Garcia <dhobsong@igel.co.jp>
>
> (testing would have been a bit easier, if prerequisites had been specified
> in the patch;))
They're specified a couple of lines down ;-)
> Tested-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Thank you.
> > ---
> >
> > drivers/video/sh_mobile_lcdcfb.c | 6 +++---
> > 1 files changed, 3 insertions(+), 3 deletions(-)
> >
> > This patch should fix the LCDC panning issue caused by runtime suspend.
> > It applies on top of Rafael J. Wysocki's pm-domains branch and Damian
> > Hobson-Garcia's MERAM patches.
> >
> > diff --git a/drivers/video/sh_mobile_lcdcfb.c
> > b/drivers/video/sh_mobile_lcdcfb.c index 48a40e3..e9b80bc 100644
> > --- a/drivers/video/sh_mobile_lcdcfb.c
> > +++ b/drivers/video/sh_mobile_lcdcfb.c
> > @@ -256,9 +256,9 @@ struct sh_mobile_lcdc_sys_bus_ops
> > sh_mobile_lcdc_sys_bus_ops = {
> >
> > static void sh_mobile_lcdc_clk_on(struct sh_mobile_lcdc_priv *priv)
> > {
> >
> > if (atomic_inc_and_test(&priv->hw_usecnt)) {
> >
> > - pm_runtime_get_sync(priv->dev);
> >
> > if (priv->dot_clk)
> >
> > clk_enable(priv->dot_clk);
> >
> > + pm_runtime_get_sync(priv->dev);
> >
> > if (priv->meram_dev && priv->meram_dev->pdev)
> >
> > pm_runtime_get_sync(&priv->meram_dev->pdev->dev);
> >
> > }
> >
> > @@ -267,11 +267,11 @@ static void sh_mobile_lcdc_clk_on(struct
> > sh_mobile_lcdc_priv *priv)
> >
> > static void sh_mobile_lcdc_clk_off(struct sh_mobile_lcdc_priv *priv)
> > {
> >
> > if (atomic_sub_return(1, &priv->hw_usecnt) = -1) {
> >
> > - if (priv->dot_clk)
> > - clk_disable(priv->dot_clk);
> >
> > if (priv->meram_dev && priv->meram_dev->pdev)
> >
> > pm_runtime_put_sync(&priv->meram_dev->pdev->dev);
> >
> > pm_runtime_put(priv->dev);
> >
> > + if (priv->dot_clk)
> > + clk_disable(priv->dot_clk);
> >
> > }
> >
> > }
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] video: output: remove video_output_{register,unregister}
From: Paul Mundt @ 2011-07-13 7:52 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110706150251.30204.26171.stgit@mj.roinet.com>
On Wed, Jul 06, 2011 at 11:02:51AM -0400, Pavel Roskin wrote:
> Signed-off-by: Pavel Roskin <proski@gnu.org>
>
> video_output_register() and video_output_unregister() are not called
> anywhere in the kernel code. Also remove the fallback implementation
> from the header.
I'm not sure why your signed-off-by line is above your description?
This interface seems like it was primarily used by the ACPI video code,
which dropped support for the output switching fairly recently (see
677bd810eedce61edf15452491781ff046b92edc).
If you remove the registration interface then it's not clear that there's
any point in keeping the class handling or anything else around, either.
If the entire thing is to be killed off however we'll need the ack from
the author (added to Cc).
^ permalink raw reply
* Re: [PATCH 5/5] drivers/video/msm/mdp.c: adjust error handling code
From: Paul Mundt @ 2011-07-13 8:13 UTC (permalink / raw)
To: Julia Lawall
Cc: David Brown, kernel-janitors, Daniel Walker, Bryan Huntsman,
linux-arm-msm, linux-fbdev, linux-kernel
In-Reply-To: <1309788705-22278-5-git-send-email-julia@diku.dk>
On Mon, Jul 04, 2011 at 04:11:45PM +0200, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Use the error handling code at the end of the function, rather than
> returning directly.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @r@
> identifier x;
> @@
>
> kfree(x)
>
> @@
> identifier r.x;
> expression E1!=0,E2,E3,E4;
> statement S;
> @@
>
> (
> if (<+...x...+>) S
> |
> if (...) { ... when != kfree(x)
> when != if (...) { ... kfree(x); ... }
> when != x = E3
> * return E1;
> }
> ... when != x = E2
> if (...) { ... when != x = E4
> kfree(x); ... return ...; }
> )
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
>
Applied, thanks.
> I wonder if the error handling code at the end of the function should be
> calling clk_put as well? In that case, having a separate label for this
> case would be useful. Otherwise, one of error_request_irq and error_get_clk
> can be deleted
>
The MSM implementation for it is simply a nop, so it's not going to
really matter one way or the other. In terms of general consistency it
might be worth implementing.
I expect that there are probably quite a few drivers that don't balance
out their clk_get()'s with clk_put()'s however, perhaps this is another
semantic patch candidate? At the very least it would be interesting to
see the statistics.
^ permalink raw reply
* Re: [PATCH v3] video: Add Aeroflex Gaisler GRVGA framebuffer device driver
From: Paul Mundt @ 2011-07-13 8:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1309850959-8198-1-git-send-email-kristoffer@gaisler.com>
On Tue, Jul 05, 2011 at 09:29:19AM +0200, Kristoffer Glembo wrote:
> This patch adds support for the GRVGA framebuffer IP core from Aeroflex Gaisler.
> The device is used in LEON SPARCV8 based System on Chips. Documentation can
> be found here: www.gaisler.com/products/grlib/grip.pdf.
>
> Signed-off-by: Kristoffer Glembo <kristoffer@gaisler.com>
The updated version looks fine to me, I've added it to the 3.1 queue.
^ permalink raw reply
* Re: [PATCH] drivers/video/udlfb bind framebuffer to interface.
From: Paul Mundt @ 2011-07-13 8:17 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1309910651-3483-1-git-send-email-bernie@plugable.com>
On Tue, Jul 05, 2011 at 05:04:11PM -0700, bernie@plugable.com wrote:
> Udlfb has been binding the framebuffer device to its parent, which
> isn't correct and causes confusion with operations like udev remove.
>
> Coming plug and play multiseat support is dependent on this fix.
>
> Signed-off-by: Bernie Thompson <bernie@plugable.com>
On Sun, Jul 10, 2011 at 12:30:00AM -0700, bernie@plugable.com wrote:
> Match udlfb only against vendor-specific class (e.g. only DisplayLink
> graphics, not composite standard audio class interfaces). This enables
> compatibility with composite graphics+audio devices (e.g. HDMI).
>
> Match udlfb only against compatible subclass 0 and protocol 0 chips.
> DisplayLink's USB 3.0 generation chips increment these values
> to signal that they have a incompatible protocol, preventing udlfb
> from erroneously matching to hardware it does not support.
>
> Tested to confirm proper behavior on both USB 2.0 and USB 3.0
> generation devices.
>
> Reported-by: Andrew Kephart <akephart@akephart.org>
> Signed-off-by: Bernie Thompson <bernie@plugable.com>
Both queued for 3.0, thanks.
^ permalink raw reply
* Re: [PATCH v2] video: da8xx-fb: Interrupt configuration of revised LCDC IP
From: Paul Mundt @ 2011-07-13 8:18 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1309861280-32240-1-git-send-email-prakash.pm@ti.com>
On Tue, Jul 05, 2011 at 03:51:20PM +0530, Manjunathappa, Prakash wrote:
> An upcoming SoC of TI comes with an LCD controller which is an updated
> version of that found on TI's DA850 SoC. The da8xx-fb driver can support
> this LCD with some enhancements.
> This patch adds support for updated interrupt configuration on the new
> SoC.
> 1) Registers for setting and clearing interrupts are different.
> 2) Raw and masked status registers are different.
> The updates have been tested on an emulation platform for new features
> and the patch has been tested on DA850 platform to make sure nothing
> existing breaks.
>
> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] video: s3c2410: remove unused variable
From: Paul Mundt @ 2011-07-13 8:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1310034037-5090-1-git-send-email-w.sang@pengutronix.de>
On Thu, Jul 07, 2011 at 12:20:37PM +0200, Wolfram Sang wrote:
> Fixes:
>
> drivers/video/s3c2410fb.c: In function 's3c2410fb_cpufreq_transition':
> drivers/video/s3c2410fb.c:770:24: warning: unused variable 'freqs'
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Paul Mundt <lethal@linux-sh.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] carminefb: Fix module parameters permissions
From: Paul Mundt @ 2011-07-13 8:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <201107081104.38854.jdelvare@suse.de>
On Fri, Jul 08, 2011 at 11:04:38AM +0200, Jean Delvare wrote:
> The third parameter of module_param is supposed to be an octal value.
> The missing leading "0" causes the following:
>
> $ ls -l /sys/module/carminefb/parameters/
> total 0
> -rw-rwxr-- 1 root root 4096 Jul 8 08:55 fb_displays
> -rw-rwxr-- 1 root root 4096 Jul 8 08:55 fb_mode
> -rw-rwxr-- 1 root root 4096 Jul 8 08:55 fb_mode_str
>
> After fixing the perm parameter, we get the expected:
>
> $ ls -l /sys/module/carminefb/parameters/
> total 0
> -r--r--r-- 1 root root 4096 Jul 8 08:56 fb_displays
> -r--r--r-- 1 root root 4096 Jul 8 08:56 fb_mode
> -r--r--r-- 1 root root 4096 Jul 8 08:56 fb_mode_str
>
> Signed-off-by: Jean Delvare <jdelvare@suse.de>
> Cc: Paul Mundt <lethal@linux-sh.org>
> Cc: Sebastian Siewior <bigeasy@linutronix.de>
> Cc: stable@kernel.org
> ---
> drivers/video/carminefb.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] fbdev: sh_mobile_lcdc: Turn dot clock on before resuming from runtime PM
From: Paul Mundt @ 2011-07-13 8:21 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1310387754-23033-1-git-send-email-laurent.pinchart@ideasonboard.com>
On Tue, Jul 12, 2011 at 11:37:57AM +0200, Laurent Pinchart wrote:
> On Tuesday 12 July 2011 11:33:09 Guennadi Liakhovetski wrote:
> > On Mon, 11 Jul 2011, Laurent Pinchart wrote:
> > > Resuming from runtime PM restores all LCDC registers. If the dot clock
> > > is off at that time display panning information will be corrupted.
> > >
> > > Turn the dot clock on before resuming from runtime PM. Similarly,
> > > turn the clock off after suspending the LCDC.
> > >
> > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > Cc: Magnus Damm <magnus.damm@gmail.com>
> > > Cc: Damian Hobson-Garcia <dhobsong@igel.co.jp>
> >
> > (testing would have been a bit easier, if prerequisites had been specified
> > in the patch;))
>
> They're specified a couple of lines down ;-)
>
> > Tested-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>
> Thank you.
>
Folded in on top of the rest of the MERAM changes, thanks.
^ permalink raw reply
* Re: [PATCH v3 00/29] Use display information in info not in var for panning
From: Paul Mundt @ 2011-07-13 8:24 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1310123683-8064-1-git-send-email-laurent.pinchart@ideasonboard.com>
On Fri, Jul 08, 2011 at 01:14:14PM +0200, Laurent Pinchart wrote:
> Hi everybody,
>
> Here's the third version of the FBIOPAN_DISPLAY fixes patch series.
>
> As a reminder, while playing with the FBIOPAN_DISPLAY ioctl I noticed that many
> drivers use information from the ioctl argument such as the display resolution
> when they should use the current settings from the fb_info structure.
>
> These 29 patches fix most of those drivers. Missing drivers are ivtv (for
> which a patch has Andy Walls has already pushed a patch), sh_mobile_lcdcfb (for
> which the fix is a bit more complex, I will work on it later) and viafb (for
> which Florian Tobias Schandinat has already sent a patch).
>
> The patches have been compile-tested on architectures for which I have a
> working compiler (x86 and ARM) with allyesconfig. I don't own any hardware
> supported by these drivers so I haven't been able to perform additional tests.
>
> I've split the fixes in one patch per driver for easier review and handling of
> potential problems. The patches can be squashed together if needed. I've tried
> to CC individual driver maintainers when possible, and Acked-by lines received
> in reply to the first version have been included.
>
> Compared to v2, I've fixed a compile issue in the atmel_lcdfb driver and added
> a couple of SoB lines.
>
> Paul, is it time to push this for 3.1 ?
>
I have the v2 series queued up already, so it would be nice to simply
have the v2->v3 differences as incremental changes that can be piled on.
The signed-off-by lines are not that critical in this case since it's a
largely mechanical change all over the place, so it's primarily the build
fix(es?) that would be nice to have.
^ permalink raw reply
* Re: [PATCH] [v2] drivers/video: use strings to specify the Freescale DIU monitor port
From: Paul Mundt @ 2011-07-13 8:27 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-fbdev, agust
In-Reply-To: <1310243894-2660-1-git-send-email-timur@freescale.com>
On Sat, Jul 09, 2011 at 03:38:14PM -0500, Timur Tabi wrote:
> Instead of using ill-defined numbers (0, 1, and 2) for the monitor port, allow
> the user to specify the port by name ("dvi", "lvds", or "dlvds"). This works
> on the kernel command line, the module command-line, and the sysfs "monitor"
> device.
>
> Note that changing the monitor port does not currently work on the P1022DS,
> because the code that talks to the PIXIS FPGA is broken.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> Acked-by: Anatolij Gustschin <agust@denx.de>
> ---
> arch/powerpc/platforms/512x/mpc512x_shared.c | 22 +++-----
> arch/powerpc/platforms/85xx/p1022_ds.c | 47 ++++++++---------
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 55 +++++++++----------
> arch/powerpc/sysdev/fsl_soc.h | 25 ++++++---
> drivers/video/fsl-diu-fb.c | 74 +++++++++++++++++++-------
> 5 files changed, 128 insertions(+), 95 deletions(-)
>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 00/29] Use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-13 8:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1310123683-8064-1-git-send-email-laurent.pinchart@ideasonboard.com>
Hi Paul,
On Wednesday 13 July 2011 10:24:24 Paul Mundt wrote:
> On Fri, Jul 08, 2011 at 01:14:14PM +0200, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > Here's the third version of the FBIOPAN_DISPLAY fixes patch series.
> >
> > As a reminder, while playing with the FBIOPAN_DISPLAY ioctl I noticed
> > that many drivers use information from the ioctl argument such as the
> > display resolution when they should use the current settings from the
> > fb_info structure.
> >
> > These 29 patches fix most of those drivers. Missing drivers are ivtv (for
> > which a patch has Andy Walls has already pushed a patch),
> > sh_mobile_lcdcfb (for which the fix is a bit more complex, I will work
> > on it later) and viafb (for which Florian Tobias Schandinat has already
> > sent a patch).
> >
> > The patches have been compile-tested on architectures for which I have a
> > working compiler (x86 and ARM) with allyesconfig. I don't own any
> > hardware supported by these drivers so I haven't been able to perform
> > additional tests.
> >
> > I've split the fixes in one patch per driver for easier review and
> > handling of potential problems. The patches can be squashed together if
> > needed. I've tried to CC individual driver maintainers when possible,
> > and Acked-by lines received in reply to the first version have been
> > included.
> >
> > Compared to v2, I've fixed a compile issue in the atmel_lcdfb driver and
> > added a couple of SoB lines.
> >
> > Paul, is it time to push this for 3.1 ?
>
> I have the v2 series queued up already, so it would be nice to simply
> have the v2->v3 differences as incremental changes that can be piled on.
Ah. Next time please notify me when you queue the patches up. That was too
soon. This will end up potentially breaking bisections, which is never good.
> The signed-off-by lines are not that critical in this case since it's a
> largely mechanical change all over the place, so it's primarily the build
> fix(es?) that would be nice to have.
I would say they are more than "nice to have". Where have you queued v2 ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* RE: [PATCH] video: output: remove video_output_{register,unregister}
From: Yu, Luming @ 2011-07-13 9:07 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110706150251.30204.26171.stgit@mj.roinet.com>
> From: Paul Mundt [mailto:lethal@linux-sh.org]
>
> On Wed, Jul 06, 2011 at 11:02:51AM -0400, Pavel Roskin wrote:
> > Signed-off-by: Pavel Roskin <proski@gnu.org>
> >
> > video_output_register() and video_output_unregister() are not called
> > anywhere in the kernel code. Also remove the fallback implementation
> > from the header.
>
> I'm not sure why your signed-off-by line is above your description?
>
> This interface seems like it was primarily used by the ACPI video code,
> which dropped support for the output switching fairly recently (see
> 677bd810eedce61edf15452491781ff046b92edc).
>
> If you remove the registration interface then it's not clear that there's
> any point in keeping the class handling or anything else around, either.
> If the entire thing is to be killed off however we'll need the ack from
> the author (added to Cc).
Cc Len and Rui
/l
^ permalink raw reply
* RE: [PATCH] video: da8xx-fb: Increased resolution configuration of
From: Manjunathappa, Prakash @ 2011-07-13 10:50 UTC (permalink / raw)
To: linux-fbdev
Hi Paul,
I have found out bug in height configuration, will be sending out version 2 of this patch.
Thanks,
Prakash
On Mon, Jun 27, 2011 at 10:26:43, Manjunathappa, Prakash wrote:
> Revised LCDC IP of DA850 supports 2048*2048 resolution. Below are the
> encoding details:
> Width:
> Pixels Per Line = {pplmsb, ppllsb, 4'b1111} + 1
> Where pplmsb:1bit=>Raster Timing0[3], ppllsb:6bits=>Raster Timing0[9:4].
> And encoded value can range from 16 to 2048 in multiples of 16.
>
> Height:
> Lines Per Panel = {lpp_b10, lpp}
> Where lpp:10bits=>Raster Timing1[9:0], lpp_b10:1bit=>Raster Timing2[26].
> And encoded value can range from 1 to 2048, programmable range is 0 to
> 2047.
>
> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
> ---
> drivers/video/da8xx-fb.c | 30 +++++++++++++++++++++++++++---
> 1 files changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index 0e02665..367d839 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -460,20 +460,44 @@ static int lcd_cfg_frame_buffer(struct da8xx_fb_par *par, u32 width, u32 height,
>
> /* Set the Panel Width */
> /* Pixels per line = (PPL + 1)*16 */
> - /*0x3F in bits 4..9 gives max horisontal resolution = 1024 pixels*/
> - width &= 0x3f0;
> + if (lcd_revision = LCD_VERSION_1) {
> + /*
> + * 0x3F in bits 4..9 gives max horizontal resolution = 1024
> + * pixels.
> + */
> + width &= 0x3f0;
> + } else {
> + /*
> + * 0x7F in bits 3..9 gives max horizontal resolution = 2048
> + * pixels.
> + */
> + width &= 0x7f0;
> + }
>
> reg = lcdc_read(LCD_RASTER_TIMING_0_REG);
> reg &= 0xfffffc00;
> - reg |= ((width >> 4) - 1) << 4;
> + if (lcd_revision = LCD_VERSION_1) {
> + reg |= ((width >> 4) - 1) << 4;
> + } else {
> + width = ((width >> 4) - 1);
> + reg |= ((width & 0x3f) << 4) | ((width & 0x40) >> 3);
> + }
> lcdc_write(reg, LCD_RASTER_TIMING_0_REG);
>
> /* Set the Panel Height */
>
> + /* Set bits 9:0 of Lines Per Pixel */
> reg = lcdc_read(LCD_RASTER_TIMING_1_REG);
> reg = ((height - 1) & 0x3ff) | (reg & 0xfffffc00);
> lcdc_write(reg, LCD_RASTER_TIMING_1_REG);
>
> + /* Set bit 10 of Lines Per Pixel */
> + if (lcd_revision = LCD_VERSION_2) {
> + reg = lcdc_read(LCD_RASTER_TIMING_2_REG);
> + reg |= (((height - 1) & 0x40) << 20);
> + lcdc_write(reg, LCD_RASTER_TIMING_2_REG);
> + }
> +
> /* Set the Raster Order of the Frame Buffer */
> reg = lcdc_read(LCD_RASTER_CTRL_REG) & ~(1 << 8);
> if (raster_order)
> --
> 1.7.1
>
>
^ permalink raw reply
* [PATCH v2] video: da8xx-fb: Increased resolution configuration of revised LCDC IP
From: Manjunathappa, Prakash @ 2011-07-13 11:04 UTC (permalink / raw)
To: linux-fbdev
Revised LCD controller in upcoming TI SoC which is an updated version of
LCDC IP that was found on TI's DA850 SoC supports 2048*2048 resolution.
Below are the encoding details:
Width:
Pixels Per Line = {pplmsb, ppllsb, 4'b1111} + 1
Where pplmsb:1bit=>Raster Timing0[3], ppllsb:6bits=>Raster Timing0[9:4].
And encoded value can range from 16 to 2048 in multiples of 16.
Height:
Lines Per Panel = {lpp_b10, lpp}
Where lpp:10bits=>Raster Timing1[9:0], lpp_b10:1bit=>Raster Timing2[26].
And encoded value can range from 1 to 2048, programmable range is 0 to
2047.
Patch is verified on emulation platform of upcoming SoC for updated
feature and on DA850 platform to make sure nothing existing breaks.
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
---
Since v1:
1)Fixed the bug in configuration of lpp_b10 in Raster Timing2[26] register.
2)Reframed commit message.
drivers/video/da8xx-fb.c | 31 ++++++++++++++++++++++++++++---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 620f1c3..19ce407 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -460,18 +460,43 @@ static int lcd_cfg_frame_buffer(struct da8xx_fb_par *par, u32 width, u32 height,
/* Set the Panel Width */
/* Pixels per line = (PPL + 1)*16 */
- /*0x3F in bits 4..9 gives max horisontal resolution = 1024 pixels*/
- width &= 0x3f0;
+ if (lcd_revision = LCD_VERSION_1) {
+ /*
+ * 0x3F in bits 4..9 gives max horizontal resolution = 1024
+ * pixels.
+ */
+ width &= 0x3f0;
+ } else {
+ /*
+ * 0x7F in bits 3..9 gives max horizontal resolution = 2048
+ * pixels.
+ */
+ width &= 0x7f0;
+ }
+
reg = lcdc_read(LCD_RASTER_TIMING_0_REG);
reg &= 0xfffffc00;
- reg |= ((width >> 4) - 1) << 4;
+ if (lcd_revision = LCD_VERSION_1) {
+ reg |= ((width >> 4) - 1) << 4;
+ } else {
+ width = ((width >> 4) - 1);
+ reg |= ((width & 0x3f) << 4) | ((width & 0x40) >> 3);
+ }
lcdc_write(reg, LCD_RASTER_TIMING_0_REG);
/* Set the Panel Height */
+ /* Set bits 9:0 of Lines Per Pixel */
reg = lcdc_read(LCD_RASTER_TIMING_1_REG);
reg = ((height - 1) & 0x3ff) | (reg & 0xfffffc00);
lcdc_write(reg, LCD_RASTER_TIMING_1_REG);
+ /* Set bit 10 of Lines Per Pixel */
+ if (lcd_revision = LCD_VERSION_2) {
+ reg = lcdc_read(LCD_RASTER_TIMING_2_REG);
+ reg |= (((height - 1) & 0x400) << 16);
+ lcdc_write(reg, LCD_RASTER_TIMING_2_REG);
+ }
+
/* Set the Raster Order of the Frame Buffer */
reg = lcdc_read(LCD_RASTER_CTRL_REG) & ~(1 << 8);
if (raster_order)
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] video: output: remove video_output_{register,unregister}
From: Pavel Roskin @ 2011-07-13 15:25 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110706150251.30204.26171.stgit@mj.roinet.com>
On 07/13/2011 03:52 AM, Paul Mundt wrote:
> On Wed, Jul 06, 2011 at 11:02:51AM -0400, Pavel Roskin wrote:
>> Signed-off-by: Pavel Roskin<proski@gnu.org>
>>
>> video_output_register() and video_output_unregister() are not called
>> anywhere in the kernel code. Also remove the fallback implementation
>> from the header.
>
> I'm not sure why your signed-off-by line is above your description?
Thanks for pointing it out.
> This interface seems like it was primarily used by the ACPI video code,
> which dropped support for the output switching fairly recently (see
> 677bd810eedce61edf15452491781ff046b92edc).
>
> If you remove the registration interface then it's not clear that there's
> any point in keeping the class handling or anything else around, either.
> If the entire thing is to be killed off however we'll need the ack from
> the author (added to Cc).
Indeed. I didn't realize that.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 5/5] drivers/video/msm/mdp.c: adjust error handling code
From: David Brown @ 2011-07-13 17:49 UTC (permalink / raw)
To: Paul Mundt
Cc: Julia Lawall, kernel-janitors, Daniel Walker, Bryan Huntsman,
linux-arm-msm, linux-fbdev, linux-kernel
In-Reply-To: <20110713081318.GB13701@linux-sh.org>
On Wed, Jul 13 2011, Paul Mundt wrote:
>> I wonder if the error handling code at the end of the function should be
>> calling clk_put as well? In that case, having a separate label for this
>> case would be useful. Otherwise, one of error_request_irq and error_get_clk
>> can be deleted
>>
> The MSM implementation for it is simply a nop, so it's not going to
> really matter one way or the other. In terms of general consistency it
> might be worth implementing.
Today, at least. Hopefully this will get better, since we can turn off
our clocks.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH v2] video: da8xx-fb: Increased resolution configuration
From: Sergei Shtylyov @ 2011-07-14 10:35 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1310554333-25242-1-git-send-email-prakash.pm@ti.com>
Hello.
On 13-07-2011 14:52, Manjunathappa, Prakash wrote:
> Revised LCD controller in upcoming TI SoC which is an updated version of
> LCDC IP that was found on TI's DA850 SoC supports 2048*2048 resolution.
> Below are the encoding details:
> Width:
> Pixels Per Line = {pplmsb, ppllsb, 4'b1111} + 1
> Where pplmsb:1bit=>Raster Timing0[3], ppllsb:6bits=>Raster Timing0[9:4].
> And encoded value can range from 16 to 2048 in multiples of 16.
> Height:
> Lines Per Panel = {lpp_b10, lpp}
> Where lpp:10bits=>Raster Timing1[9:0], lpp_b10:1bit=>Raster Timing2[26].
> And encoded value can range from 1 to 2048, programmable range is 0 to
> 2047.
> Patch is verified on emulation platform of upcoming SoC for updated
> feature and on DA850 platform to make sure nothing existing breaks.
> Signed-off-by: Manjunathappa, Prakash<prakash.pm@ti.com>
> ---
> Since v1:
> 1)Fixed the bug in configuration of lpp_b10 in Raster Timing2[26] register.
> 2)Reframed commit message.
> drivers/video/da8xx-fb.c | 31 ++++++++++++++++++++++++++++---
> 1 files changed, 28 insertions(+), 3 deletions(-)
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index 620f1c3..19ce407 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -460,18 +460,43 @@ static int lcd_cfg_frame_buffer(struct da8xx_fb_par *par, u32 width, u32 height,
>
> /* Set the Panel Width */
> /* Pixels per line = (PPL + 1)*16 */
> - /*0x3F in bits 4..9 gives max horisontal resolution = 1024 pixels*/
> - width&= 0x3f0;
> + if (lcd_revision = LCD_VERSION_1) {
> + /*
> + * 0x3F in bits 4..9 gives max horizontal resolution = 1024
> + * pixels.
> + */
> + width&= 0x3f0;
> + } else {
> + /*
> + * 0x7F in bits 3..9 gives max horizontal resolution = 2048
Maybe bits 4..10?
> + * pixels.
> + */
> + width&= 0x7f0;
> + }
> +
> reg = lcdc_read(LCD_RASTER_TIMING_0_REG);
> reg &= 0xfffffc00;
> - reg |= ((width >> 4) - 1) << 4;
> + if (lcd_revision = LCD_VERSION_1) {
> + reg |= ((width>> 4) - 1)<< 4;
> + } else {
> + width = ((width>> 4) - 1);
Most outer parens not needed.
> + reg |= ((width & 0x3f) << 4) | ((width& 0x40) >> 3);
> + }
> lcdc_write(reg, LCD_RASTER_TIMING_0_REG);
>
> /* Set the Panel Height */
> + /* Set bits 9:0 of Lines Per Pixel */
> reg = lcdc_read(LCD_RASTER_TIMING_1_REG);
> reg = ((height - 1) & 0x3ff) | (reg & 0xfffffc00);
> lcdc_write(reg, LCD_RASTER_TIMING_1_REG);
>
> + /* Set bit 10 of Lines Per Pixel */
> + if (lcd_revision = LCD_VERSION_2) {
> + reg = lcdc_read(LCD_RASTER_TIMING_2_REG);
> + reg |= (((height - 1) & 0x400) << 16);
Most outer parens not needed.
WBR, Sergei
^ permalink raw reply
* RE: [PATCH v2] video: da8xx-fb: Increased resolution configuration
From: Manjunathappa, Prakash @ 2011-07-14 11:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1310554333-25242-1-git-send-email-prakash.pm@ti.com>
Hi Sergei,
On Thu, Jul 14, 2011 at 16:05:35, Sergei Shtylyov wrote:
> Hello.
>
> On 13-07-2011 14:52, Manjunathappa, Prakash wrote:
>
> > Revised LCD controller in upcoming TI SoC which is an updated version of
> > LCDC IP that was found on TI's DA850 SoC supports 2048*2048 resolution.
> > Below are the encoding details:
> > Width:
> > Pixels Per Line = {pplmsb, ppllsb, 4'b1111} + 1
> > Where pplmsb:1bit=>Raster Timing0[3], ppllsb:6bits=>Raster Timing0[9:4].
> > And encoded value can range from 16 to 2048 in multiples of 16.
>
> > Height:
> > Lines Per Panel = {lpp_b10, lpp}
> > Where lpp:10bits=>Raster Timing1[9:0], lpp_b10:1bit=>Raster Timing2[26].
> > And encoded value can range from 1 to 2048, programmable range is 0 to
> > 2047.
>
> > Patch is verified on emulation platform of upcoming SoC for updated
> > feature and on DA850 platform to make sure nothing existing breaks.
>
> > Signed-off-by: Manjunathappa, Prakash<prakash.pm@ti.com>
> > ---
> > Since v1:
> > 1)Fixed the bug in configuration of lpp_b10 in Raster Timing2[26] register.
> > 2)Reframed commit message.
> > drivers/video/da8xx-fb.c | 31 ++++++++++++++++++++++++++++---
> > 1 files changed, 28 insertions(+), 3 deletions(-)
>
> > diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> > index 620f1c3..19ce407 100644
> > --- a/drivers/video/da8xx-fb.c
> > +++ b/drivers/video/da8xx-fb.c
> > @@ -460,18 +460,43 @@ static int lcd_cfg_frame_buffer(struct da8xx_fb_par *par, u32 width, u32 height,
> >
> > /* Set the Panel Width */
> > /* Pixels per line = (PPL + 1)*16 */
> > - /*0x3F in bits 4..9 gives max horisontal resolution = 1024 pixels*/
> > - width&= 0x3f0;
> > + if (lcd_revision = LCD_VERSION_1) {
> > + /*
> > + * 0x3F in bits 4..9 gives max horizontal resolution = 1024
> > + * pixels.
> > + */
> > + width&= 0x3f0;
> > + } else {
> > + /*
> > + * 0x7F in bits 3..9 gives max horizontal resolution = 2048
>
> Maybe bits 4..10?
Correct, I will fix this comment.
>
> > + * pixels.
> > + */
> > + width&= 0x7f0;
> > + }
> > +
> > reg = lcdc_read(LCD_RASTER_TIMING_0_REG);
> > reg &= 0xfffffc00;
> > - reg |= ((width >> 4) - 1) << 4;
> > + if (lcd_revision = LCD_VERSION_1) {
> > + reg |= ((width>> 4) - 1)<< 4;
> > + } else {
> > + width = ((width>> 4) - 1);
>
> Most outer parens not needed.
Ok. I will remove them.
>
> > + reg |= ((width & 0x3f) << 4) | ((width& 0x40) >> 3);
> > + }
> > lcdc_write(reg, LCD_RASTER_TIMING_0_REG);
> >
> > /* Set the Panel Height */
> > + /* Set bits 9:0 of Lines Per Pixel */
> > reg = lcdc_read(LCD_RASTER_TIMING_1_REG);
> > reg = ((height - 1) & 0x3ff) | (reg & 0xfffffc00);
> > lcdc_write(reg, LCD_RASTER_TIMING_1_REG);
> >
> > + /* Set bit 10 of Lines Per Pixel */
> > + if (lcd_revision = LCD_VERSION_2) {
> > + reg = lcdc_read(LCD_RASTER_TIMING_2_REG);
> > + reg |= (((height - 1) & 0x400) << 16);
>
> Most outer parens not needed.
Ok. I will remove them.
Thanks,
Prakash
>
> WBR, Sergei
>
^ permalink raw reply
* Re: [PATCHv2 17/28] OMAP2420: HWMOD: Add DSS opt clocks
From: Paul Walmsley @ 2011-07-15 6:48 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, b-cousson, khilman
In-Reply-To: <1307627810-3768-18-git-send-email-tomi.valkeinen@ti.com>
On Thu, 9 Jun 2011, Tomi Valkeinen wrote:
> Add DSS optional clocks to HWMOD data for OMAP2420.
Thanks; queued for 3.1-rc fixes at git://git.pwsan.com/linux-2.6 in the
branch 'omap2_3_hwmod_dss_fixes_3.1rc'.
- Paul
^ permalink raw reply
* Re: [PATCHv2 16/28] OMAP3: HWMOD: Add DSS opt clocks
From: Paul Walmsley @ 2011-07-15 6:49 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, b-cousson, khilman
In-Reply-To: <1307627810-3768-17-git-send-email-tomi.valkeinen@ti.com>
On Thu, 9 Jun 2011, Tomi Valkeinen wrote:
> Add DSS optional clocks to HWMOD data for OMAP3xxx.
Thanks; queued for 3.1-rc fixes at git://git.pwsan.com/linux-2.6 in the
branch 'omap2_3_hwmod_dss_fixes_3.1rc'.
- Paul
^ permalink raw reply
* Re: [PATCHv2 18/28] OMAP2430: HWMOD: Add DSS opt clocks
From: Paul Walmsley @ 2011-07-15 6:49 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, b-cousson, khilman
In-Reply-To: <1307627810-3768-19-git-send-email-tomi.valkeinen@ti.com>
On Thu, 9 Jun 2011, Tomi Valkeinen wrote:
> Add DSS optional clocks to HWMOD data for OMAP2430.
Thanks; queued for 3.1-rc fixes at git://git.pwsan.com/linux-2.6 in the
branch 'omap2_3_hwmod_dss_fixes_3.1rc'.
- Paul
^ permalink raw reply
* [PATCH 0/3] sh_mobile_lcdc cleanup and fixes
From: Laurent Pinchart @ 2011-07-15 21:52 UTC (permalink / raw)
To: linux-fbdev
Hi everybody,
When trying to understand the sh_mobile_lcdc driver, I found it hard to read
statements that include hardcoded register values. I thus wrote a patch that
replace them with macros, making the code more readable.
While doing so, I found two potential issues in the driver. See patches 2 and
3 for detailed explanations and fixes.
Laurent Pinchart (3):
fbdev: sh_mobile_lcdc: Replace hardcoded register values with macros
fbdev: sh_mobile_lcdc: Don't acknowlege interrupts unintentionally
fbdev: sh_mobile_lcdc: Compute clock pattern using divider
denominator
drivers/video/sh_mobile_lcdcfb.c | 232 +++++++++++++++++---------------------
include/video/sh_mobile_lcdc.h | 135 +++++++++++++++++++---
2 files changed, 222 insertions(+), 145 deletions(-)
--
Best regards,
Laurent Pinchart
^ 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