* [PATCH 4/4] fbdev: sh_mobile_meram: Remove unneeded sh_mobile_meram.h
From: Laurent Pinchart @ 2011-07-30 20:26 UTC (permalink / raw)
To: linux-fbdev
The drivers/video/sh_mobile_meram.h header contains unused definitions
and declarations. Move the only used macro to sh_mobile_meram.c, and
remove the header.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_lcdcfb.c | 2 +-
drivers/video/sh_mobile_meram.c | 5 +++--
drivers/video/sh_mobile_meram.h | 33 ---------------------------------
3 files changed, 4 insertions(+), 36 deletions(-)
delete mode 100644 drivers/video/sh_mobile_meram.h
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index d0f768e..93e10ef 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -24,10 +24,10 @@
#include <linux/backlight.h>
#include <linux/gpio.h>
#include <video/sh_mobile_lcdc.h>
+#include <video/sh_mobile_meram.h>
#include <asm/atomic.h>
#include "sh_mobile_lcdcfb.h"
-#include "sh_mobile_meram.h"
#define SIDE_B_OFFSET 0x1000
#define MIRROR_OFFSET 0x2000
diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
index 7ba6dce..f632970 100644
--- a/drivers/video/sh_mobile_meram.c
+++ b/drivers/video/sh_mobile_meram.c
@@ -16,8 +16,7 @@
#include <linux/io.h>
#include <linux/slab.h>
#include <linux/platform_device.h>
-
-#include "sh_mobile_meram.h"
+#include <video/sh_mobile_meram.h>
/* meram registers */
#define MEVCR1 0x4
@@ -82,6 +81,8 @@
((yszm1) << MExxBSIZE_YSZM1_SHIFT) | \
((xszm1) << MExxBSIZE_XSZM1_SHIFT))
+#define SH_MOBILE_MERAM_ICB_NUM 32
+
static unsigned long common_regs[] = {
MEVCR1,
MEQSEL1,
diff --git a/drivers/video/sh_mobile_meram.h b/drivers/video/sh_mobile_meram.h
deleted file mode 100644
index 1615204..0000000
--- a/drivers/video/sh_mobile_meram.h
+++ /dev/null
@@ -1,33 +0,0 @@
-#ifndef __sh_mobile_meram_h__
-#define __sh_mobile_meram_h__
-
-#include <linux/mutex.h>
-#include <video/sh_mobile_meram.h>
-
-/*
- * MERAM private
- */
-
-#define MERAM_ICB_Y 0x1
-#define MERAM_ICB_C 0x2
-
-/* MERAM cache size */
-#define SH_MOBILE_MERAM_ICB_NUM 32
-
-#define SH_MOBILE_MERAM_CACHE_OFFSET(p) ((p) >> 16)
-#define SH_MOBILE_MERAM_CACHE_SIZE(p) ((p) & 0xffff)
-
-int sh_mobile_meram_alloc_icb(const struct sh_mobile_meram_cfg *cfg,
- int xres,
- int yres,
- unsigned int base_addr,
- int yuv_mode,
- int *marker_icb,
- int *out_pitch);
-
-void sh_mobile_meram_free_icb(int marker_icb);
-
-#define SH_MOBILE_MERAM_START(ind, ab) \
- (0xC0000000 | ((ab & 0x1) << 23) | ((ind & 0x1F) << 24))
-
-#endif /* !__sh_mobile_meram_h__ */
--
1.7.3.4
^ permalink raw reply related
* Patch fixing savagefb driver typo/regression in linux-3.0.0
From: John Stanley @ 2011-07-31 10:04 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 992 bytes --]
I have an old T22 Thinkpad with integrated Savage/IX-MV video. As of
linux-3.0, the video is non-functional; the PC either hard hangs
immediately or has totally garbled video, and then hard hangs, as soon
as I attempt to edit a file or cat a file with more than a screen-full
of text. The foregoing details are actually not important any more as in
looking at the code changes I discovered a typo in
linux-3.0.0/drivers/video/savage/savagefb.h and have applied the
attached patch to fix the issue.
PLEASE NOTE:
I realize that the patch does not quite adhere to linux kernel patch
coding-style conventions (in particular, spaces around logical
operators, and lines not exceeding 80 chars), but I have simply changed an
'||' to an '&&' -- and NOT attempted to resolve pre-existing
coding-style violations.
thanks much,
John
P.S. Many, many thanks for lifting the 800x600 resolution limit! I've
been using a patch/hack to bump the limit to 1024x768 for an very long
time...
[-- Attachment #2: linux-3.0.0-savagefb-savage4-series-def-fix.patch --]
[-- Type: text/plain, Size: 1290 bytes --]
This patch corrects a typo/regression in the savage driver code occurring in going
from linux-2.6.39.3 to linux-3.0.0.
In linux-2.6.39.3, there were two savage4 variants (S3_SAVAGE4 and S3_PROSAVAGE).
Hence, S3_SAVAGE4_SERIES was defined as
S3_SAVAGE4 or S3_PROSAVAGE
In linux-3.0.0, two additional savage4 variants (S3_TWISTER and S3_PROSAVAGEDDR) have
been added. Hence S3_SAVAGE4_SERIES should be defined as
S3_SAVAGE4, S3_PROSAVAGE, S3_TWISTER, or S3_PROSAVAGEDDR
In going from linux-2.6.39.3 to linux-3.0.0, the define statement for S3_SAVAGE4_SERIES
was incompletely modified: the '||' should have been changed to an '&&'; for an '||' will
set S3_SAVAGE4_SERIES true for any card.
Signed-off-by: John P. Stanley <jpsinthemix@verizon.net>
--- linux-3.0.0/drivers/video/savage/savagefb.h.orig 2011-07-21 22:17:23.000000000 -0400
+++ linux-3.0.0/drivers/video/savage/savagefb.h 2011-07-31 05:27:47.314798215 -0400
@@ -55,7 +55,7 @@
#define S3_SAVAGE3D_SERIES(chip) ((chip>=S3_SAVAGE3D) && (chip<=S3_SAVAGE_MX))
-#define S3_SAVAGE4_SERIES(chip) ((chip>=S3_SAVAGE4) || (chip<=S3_PROSAVAGEDDR))
+#define S3_SAVAGE4_SERIES(chip) ((chip>=S3_SAVAGE4) && (chip<=S3_PROSAVAGEDDR))
#define S3_SAVAGE_MOBILE_SERIES(chip) ((chip==S3_SAVAGE_MX) || (chip==S3_SUPERSAVAGE))
^ permalink raw reply
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Geert Uytterhoeven @ 2011-07-31 20:32 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Guennadi Liakhovetski, Florian Tobias Schandinat, Paul Mundt,
linux-fbdev, linux-media, dri-devel
In-Reply-To: <201107281251.35018.laurent.pinchart@ideasonboard.com>
On Thu, Jul 28, 2011 at 12:51, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>> As for struct fb_var_screeninfo fields to support switching to a FOURCC
>> mode, I also prefer an explicit dedicated flag to specify switching to it.
>> Even though using FOURCC doesn't fit under the notion of a videomode, using
>> one of .vmode bits is too tempting, so, I would actually take the plunge and
>> use FB_VMODE_FOURCC.
>
> Another option would be to consider any grayscale > 1 value as a FOURCC. I've
> briefly checked the in-tree drivers: they only assign grayscale with 0 or 1,
> and check whether grayscale is 0 or different than 0. If a userspace
> application only sets grayscale > 1 when talking to a driver that supports the
> FOURCC-based API, we could get rid of the flag.
>
> What can't be easily found out is whether existing applications set grayscale
> to a > 1 value. They would break when used with FOURCC-aware drivers if we
> consider any grayscale > 1 value as a FOURCC. Is that a risk we can take ?
I think we can. I'd expect applications to use either 1 or -1 (i.e.
all ones), both are
invalid FOURCC values.
Still, I prefer the nonstd way.
And limiting traditional nonstd values to the lowest 24 bits (there
are no in-tree
drivers using the highest 8 bits, right?).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Florian Tobias Schandinat @ 2011-07-31 22:54 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Laurent Pinchart, Guennadi Liakhovetski, Paul Mundt, linux-fbdev,
linux-media, dri-devel
In-Reply-To: <CAMuHMdX=c=p7oASCE+GgY9AgaCPWoXRQyjEGpn4BvA9xSY6GQg@mail.gmail.com>
On 07/31/2011 08:32 PM, Geert Uytterhoeven wrote:
> On Thu, Jul 28, 2011 at 12:51, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>>> As for struct fb_var_screeninfo fields to support switching to a FOURCC
>>> mode, I also prefer an explicit dedicated flag to specify switching to it.
>>> Even though using FOURCC doesn't fit under the notion of a videomode, using
>>> one of .vmode bits is too tempting, so, I would actually take the plunge and
>>> use FB_VMODE_FOURCC.
>>
>> Another option would be to consider any grayscale> 1 value as a FOURCC. I've
>> briefly checked the in-tree drivers: they only assign grayscale with 0 or 1,
>> and check whether grayscale is 0 or different than 0. If a userspace
>> application only sets grayscale> 1 when talking to a driver that supports the
>> FOURCC-based API, we could get rid of the flag.
>>
>> What can't be easily found out is whether existing applications set grayscale
>> to a> 1 value. They would break when used with FOURCC-aware drivers if we
>> consider any grayscale> 1 value as a FOURCC. Is that a risk we can take ?
>
> I think we can. I'd expect applications to use either 1 or -1 (i.e.
> all ones), both are
> invalid FOURCC values.
>
> Still, I prefer the nonstd way.
> And limiting traditional nonstd values to the lowest 24 bits (there
> are no in-tree
> drivers using the highest 8 bits, right?).
Okay, it would be okay for me to
- write raw FOURCC values in nonstd, enable FOURCC mode if upper byte != 0
- not having an explicit flag to enable FOURCC
- in FOURCC mode drivers must set visual to FB_VISUAL_FOURCC
- making support of FOURCC visible to userspace by capabilites |= FB_CAP_FOURCC
The capabilities is not strictly necessary but I think it's very useful as
- it allows applications to make sure the extension is supported (for example to
adjust the UI)
- it allows applications to distinguish whether a particular format is not
supported or FOURCC at all
- it allows signaling further extensions of the API
- it does not hurt, one line per driver and still some bytes in fixinfo free
So using it would look like this:
- the driver must have capabilities |= FB_CAP_FOURCC
- the application may check capabilities to know whether FOURCC is supported
- the application may write a raw FOURCC value in nonstd to request changing to
FOURCC mode with this format
- when the driver switches to a FOURCC mode it must have visual =
FB_VISUAL_FOURCC and the current FOURCC format in nonstd
- the application should check visual and nonstd to make sure it gets what it wanted
So if there are no strong objections against this I think we should implement it.
I do not really care whether we use a union or not but I think if we decide to
have one it should cover all fields that are undefined/unused in FOURCC mode.
Hope we can find anything that everyone considers acceptable,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-07-31 23:28 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Geert Uytterhoeven, Guennadi Liakhovetski, Paul Mundt,
linux-fbdev, linux-media, dri-devel
In-Reply-To: <4E35DD38.7070609@gmx.de>
Hi Florian,
Thanks for the feedback.
On Monday 01 August 2011 00:54:48 Florian Tobias Schandinat wrote:
> On 07/31/2011 08:32 PM, Geert Uytterhoeven wrote:
> > On Thu, Jul 28, 2011 at 12:51, Laurent Pinchart wrote:
> >>> As for struct fb_var_screeninfo fields to support switching to a FOURCC
> >>> mode, I also prefer an explicit dedicated flag to specify switching to
> >>> it. Even though using FOURCC doesn't fit under the notion of a
> >>> videomode, using one of .vmode bits is too tempting, so, I would
> >>> actually take the plunge and use FB_VMODE_FOURCC.
> >>
> >> Another option would be to consider any grayscale> 1 value as a FOURCC.
> >> I've briefly checked the in-tree drivers: they only assign grayscale
> >> with 0 or 1, and check whether grayscale is 0 or different than 0. If a
> >> userspace application only sets grayscale> 1 when talking to a driver
> >> that supports the FOURCC-based API, we could get rid of the flag.
> >>
> >> What can't be easily found out is whether existing applications set
> >> grayscale to a> 1 value. They would break when used with FOURCC-aware
> >> drivers if we consider any grayscale> 1 value as a FOURCC. Is that a
> >> risk we can take ?
> >
> > I think we can. I'd expect applications to use either 1 or -1 (i.e.
> > all ones), both are
> > invalid FOURCC values.
> >
> > Still, I prefer the nonstd way.
> > And limiting traditional nonstd values to the lowest 24 bits (there
> > are no in-tree
> > drivers using the highest 8 bits, right?).
>
> Okay, it would be okay for me to
> - write raw FOURCC values in nonstd, enable FOURCC mode if upper byte != 0
> - not having an explicit flag to enable FOURCC
> - in FOURCC mode drivers must set visual to FB_VISUAL_FOURCC
> - making support of FOURCC visible to userspace by capabilites |> FB_CAP_FOURCC
>
> The capabilities is not strictly necessary but I think it's very useful as
> - it allows applications to make sure the extension is supported (for
> example to adjust the UI)
> - it allows applications to distinguish whether a particular format is not
> supported or FOURCC at all
> - it allows signaling further extensions of the API
> - it does not hurt, one line per driver and still some bytes in fixinfo
> free
Without a FOURCC capability applications will need to try FOURCCs blindly.
Drivers that are not FOURCC aware would then risk interpreting the FOURCC as
something else. As you mention below applications will need that check that
visual = FB_VISUAL_FOURCC, so it's less of an issue than I initially thought,
but it doesn't become a non-issue. The display might still show glitches.
> So using it would look like this:
> - the driver must have capabilities |= FB_CAP_FOURCC
> - the application may check capabilities to know whether FOURCC is
> supported - the application may write a raw FOURCC value in nonstd to
> request changing to FOURCC mode with this format
> - when the driver switches to a FOURCC mode it must have visual > FB_VISUAL_FOURCC and the current FOURCC format in nonstd
> - the application should check visual and nonstd to make sure it gets what
> it wanted
>
>
> So if there are no strong objections against this I think we should
> implement it. I do not really care whether we use a union or not but I
> think if we decide to have one it should cover all fields that are
> undefined/unused in FOURCC mode.
>
>
> Hope we can find anything that everyone considers acceptable,
This sounds good to me, except that I would use the grayscale field instead of
the nonstd field. nonstd has pretty weird usecases, while grayscale is better
defined. nonstd might also make sense combined with FOURCC-based modes, while
grayscale would be completely redundant.
What's your opinion on that ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-07-31 23:30 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Guennadi Liakhovetski, Florian Tobias Schandinat, Paul Mundt,
linux-fbdev, linux-media, dri-devel
In-Reply-To: <CAMuHMdX=c=p7oASCE+GgY9AgaCPWoXRQyjEGpn4BvA9xSY6GQg@mail.gmail.com>
Hi Geert,
Thanks for the feedback.
On Sunday 31 July 2011 22:32:42 Geert Uytterhoeven wrote:
> On Thu, Jul 28, 2011 at 12:51, Laurent Pinchart wrote:
> >> As for struct fb_var_screeninfo fields to support switching to a FOURCC
> >> mode, I also prefer an explicit dedicated flag to specify switching to
> >> it. Even though using FOURCC doesn't fit under the notion of a
> >> videomode, using one of .vmode bits is too tempting, so, I would
> >> actually take the plunge and use FB_VMODE_FOURCC.
> >
> > Another option would be to consider any grayscale > 1 value as a FOURCC.
> > I've briefly checked the in-tree drivers: they only assign grayscale
> > with 0 or 1, and check whether grayscale is 0 or different than 0. If a
> > userspace application only sets grayscale > 1 when talking to a driver
> > that supports the FOURCC-based API, we could get rid of the flag.
> >
> > What can't be easily found out is whether existing applications set
> > grayscale to a > 1 value. They would break when used with FOURCC-aware
> > drivers if we consider any grayscale > 1 value as a FOURCC. Is that a
> > risk we can take ?
>
> I think we can. I'd expect applications to use either 1 or -1 (i.e. all
> ones), both are invalid FOURCC values.
OK.
> Still, I prefer the nonstd way.
> And limiting traditional nonstd values to the lowest 24 bits (there
> are no in-tree drivers using the highest 8 bits, right?).
None that I've found. I still have a preference for the grayscale field
though. As mentioned by Guennadi, the grayscale field would become redundant
for FOURCC-based formats. It's then a good candidate, and would let drivers
(and applications) do any crazy stuff they want with the nonstd field.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Florian Tobias Schandinat @ 2011-07-31 23:58 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Geert Uytterhoeven, Guennadi Liakhovetski, Paul Mundt,
linux-fbdev, linux-media, dri-devel
In-Reply-To: <201108010128.13832.laurent.pinchart@ideasonboard.com>
Hi Laurent,
On 07/31/2011 11:28 PM, Laurent Pinchart wrote:
> Hi Florian,
>
> Thanks for the feedback.
>
> On Monday 01 August 2011 00:54:48 Florian Tobias Schandinat wrote:
>> On 07/31/2011 08:32 PM, Geert Uytterhoeven wrote:
>>> On Thu, Jul 28, 2011 at 12:51, Laurent Pinchart wrote:
>>>>> As for struct fb_var_screeninfo fields to support switching to a FOURCC
>>>>> mode, I also prefer an explicit dedicated flag to specify switching to
>>>>> it. Even though using FOURCC doesn't fit under the notion of a
>>>>> videomode, using one of .vmode bits is too tempting, so, I would
>>>>> actually take the plunge and use FB_VMODE_FOURCC.
>>>>
>>>> Another option would be to consider any grayscale> 1 value as a FOURCC.
>>>> I've briefly checked the in-tree drivers: they only assign grayscale
>>>> with 0 or 1, and check whether grayscale is 0 or different than 0. If a
>>>> userspace application only sets grayscale> 1 when talking to a driver
>>>> that supports the FOURCC-based API, we could get rid of the flag.
>>>>
>>>> What can't be easily found out is whether existing applications set
>>>> grayscale to a> 1 value. They would break when used with FOURCC-aware
>>>> drivers if we consider any grayscale> 1 value as a FOURCC. Is that a
>>>> risk we can take ?
>>>
>>> I think we can. I'd expect applications to use either 1 or -1 (i.e.
>>> all ones), both are
>>> invalid FOURCC values.
>>>
>>> Still, I prefer the nonstd way.
>>> And limiting traditional nonstd values to the lowest 24 bits (there
>>> are no in-tree
>>> drivers using the highest 8 bits, right?).
>>
>> Okay, it would be okay for me to
>> - write raw FOURCC values in nonstd, enable FOURCC mode if upper byte != 0
>> - not having an explicit flag to enable FOURCC
>> - in FOURCC mode drivers must set visual to FB_VISUAL_FOURCC
>> - making support of FOURCC visible to userspace by capabilites |>> FB_CAP_FOURCC
>>
>> The capabilities is not strictly necessary but I think it's very useful as
>> - it allows applications to make sure the extension is supported (for
>> example to adjust the UI)
>> - it allows applications to distinguish whether a particular format is not
>> supported or FOURCC at all
>> - it allows signaling further extensions of the API
>> - it does not hurt, one line per driver and still some bytes in fixinfo
>> free
>
> Without a FOURCC capability applications will need to try FOURCCs blindly.
> Drivers that are not FOURCC aware would then risk interpreting the FOURCC as
> something else. As you mention below applications will need that check that
> visual = FB_VISUAL_FOURCC, so it's less of an issue than I initially thought,
> but it doesn't become a non-issue. The display might still show glitches.
True.
>> So using it would look like this:
>> - the driver must have capabilities |= FB_CAP_FOURCC
>> - the application may check capabilities to know whether FOURCC is
>> supported - the application may write a raw FOURCC value in nonstd to
>> request changing to FOURCC mode with this format
>> - when the driver switches to a FOURCC mode it must have visual >> FB_VISUAL_FOURCC and the current FOURCC format in nonstd
>> - the application should check visual and nonstd to make sure it gets what
>> it wanted
>>
>>
>> So if there are no strong objections against this I think we should
>> implement it. I do not really care whether we use a union or not but I
>> think if we decide to have one it should cover all fields that are
>> undefined/unused in FOURCC mode.
>>
>>
>> Hope we can find anything that everyone considers acceptable,
>
> This sounds good to me, except that I would use the grayscale field instead of
> the nonstd field. nonstd has pretty weird usecases, while grayscale is better
> defined. nonstd might also make sense combined with FOURCC-based modes, while
> grayscale would be completely redundant.
>
> What's your opinion on that ?
I do not really care, either one would be okay for me.
You're right that nonstd is used for a lot of things and perhaps some of those
should still be possible in FOURCC mode. On the other hand I think applications
are more likely to pass random values to grayscale as its meaning seems globally
accepted (in contrast to nonstd where the application needs to know the driver
to get any use of it).
Perhaps you should also say that in FOURCC mode all unused pixel format fields
should be set to 0 by the application and other values of those may get a
meaning in later extensions or individual drivers.
Regards,
Florian Tobias Schandinat
^ permalink raw reply
* Fwd: [PATCH 0/2] video: add Samsung SoC based MIPI-DSI support.
From: InKi Dae @ 2011-08-01 4:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4DA6E551.1060300@samsung.com>
Hello, Paul.
I had posted patch sets below on 15 Apr.
but there is no any comments.
please review this patch sets.
thank you.
---------- Forwarded message ----------
From: daeinki <inki.dae@samsung.com>
Date: 2011/4/14
Subject: [PATCH 0/2] video: add Samsung SoC based MIPI-DSI support.
To: linux-fbdev@vger.kernel.org, lethal@linux-sh.org
ÂüÁ¶: kyungmin.park@samsung.com, Kukjin Kim <kgene.kim@samsung.com>,
akpm@linux-foundation.org, linux-arm-kernel@lists.infradead.org
Hello, all.
Samsung S5PV210 and EXYNOS4 SoC platform have one or two MIPI-DSI
controller and MIPI-DSI based LCD Panel could be used with this one.
this patch adds Samsung SoC based MIPI-DSI support.
to use MIPI-DSI based LCD Panel driver, mipi_dsim_lcd_device shoule be
registered to MIPI-DSI driver through s5p_mipi_dsi_register_lcd_device()
at machine code or machine specific somewhere first, and
mipi_dsim_lcd_driver should be registered when
s5p_mipi_dsi_register_driver() is called at init function of lcd driver,
and then probe() of that driver would be called by MIPI-DSI controller
driver if lcd panel name and id of mipi_dsim_lcd_device are same as ones
of mipi_dsim_lcd_driver.
for this, you can refer to sample lcd panel driver.
please see "Documentation/s5p_mipi_dsim/dsim_sample_lcd.c"
this patch series includes the following.
[PATCH 1/2] video: add Samsung SoC MIPI-DSI controller driver.
[PATCH 2/2] video: add Samsung SoC MIPI-DSI based sample lcd panel driver.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Geert Uytterhoeven @ 2011-08-01 9:49 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Laurent Pinchart, Guennadi Liakhovetski, Paul Mundt, linux-fbdev,
linux-media, dri-devel
In-Reply-To: <4E35DD38.7070609@gmx.de>
On Mon, Aug 1, 2011 at 00:54, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> On 07/31/2011 08:32 PM, Geert Uytterhoeven wrote:
>> On Thu, Jul 28, 2011 at 12:51, Laurent Pinchart
>> <laurent.pinchart@ideasonboard.com> wrote:
>>>>
>>>> As for struct fb_var_screeninfo fields to support switching to a FOURCC
>>>> mode, I also prefer an explicit dedicated flag to specify switching to
>>>> it.
>>>> Even though using FOURCC doesn't fit under the notion of a videomode,
>>>> using
>>>> one of .vmode bits is too tempting, so, I would actually take the plunge
>>>> and
>>>> use FB_VMODE_FOURCC.
>>>
>>> Another option would be to consider any grayscale> 1 value as a FOURCC.
>>> I've
>>> briefly checked the in-tree drivers: they only assign grayscale with 0 or
>>> 1,
>>> and check whether grayscale is 0 or different than 0. If a userspace
>>> application only sets grayscale> 1 when talking to a driver that
>>> supports the
>>> FOURCC-based API, we could get rid of the flag.
>>>
>>> What can't be easily found out is whether existing applications set
>>> grayscale
>>> to a> 1 value. They would break when used with FOURCC-aware drivers if
>>> we
>>> consider any grayscale> 1 value as a FOURCC. Is that a risk we can take
>>> ?
>>
>> I think we can. I'd expect applications to use either 1 or -1 (i.e.
>> all ones), both are
>> invalid FOURCC values.
>>
>> Still, I prefer the nonstd way.
>> And limiting traditional nonstd values to the lowest 24 bits (there
>> are no in-tree
>> drivers using the highest 8 bits, right?).
>
> Okay, it would be okay for me to
> - write raw FOURCC values in nonstd, enable FOURCC mode if upper byte != 0
> - not having an explicit flag to enable FOURCC
> - in FOURCC mode drivers must set visual to FB_VISUAL_FOURCC
> - making support of FOURCC visible to userspace by capabilites |> FB_CAP_FOURCC
>
> The capabilities is not strictly necessary but I think it's very useful as
> - it allows applications to make sure the extension is supported (for
> example to adjust the UI)
> - it allows applications to distinguish whether a particular format is not
> supported or FOURCC at all
> - it allows signaling further extensions of the API
> - it does not hurt, one line per driver and still some bytes in fixinfo free
>
>
> So using it would look like this:
> - the driver must have capabilities |= FB_CAP_FOURCC
> - the application may check capabilities to know whether FOURCC is supported
> - the application may write a raw FOURCC value in nonstd to request changing
> to FOURCC mode with this format
> - when the driver switches to a FOURCC mode it must have visual > FB_VISUAL_FOURCC and the current FOURCC format in nonstd
> - the application should check visual and nonstd to make sure it gets what
> it wanted
As several of the FOURCC formats duplicate formats you can already
specify in some
other way (e.g. the RGB and greyscale formats), and as FOURCC makes life easier
for the application writer, I'm wondering whether it makes sense to add FOURCC
support in the generic layer for drivers that don't support it? I.e.
the generic layer would
fill in fb_var_screeninfo depending on the requested FOURCC mode, if possible.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [GIT PULL] OMAP display subsystem patches for 3.1
From: Tomi Valkeinen @ 2011-08-01 13:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mundt, linux-omap mailing list, linux-fbdev, lk-ml
Hi Linus,
Sorry for sending this pull request so late.
This pull request contains mostly OMAP display subsystem driver patches
related to preparing and making the DSS driver use runtime PM. Using
runtime PM creates new dependencies to the lower level arch stuff
(clocks and HWMODs), and while the patches for arch side have been ready
for some time, some of them seem to have fallen into some cracks and
didn't make it into the pull requests sent by the HWMOD maintainer. And
then the maintainer went to vacation before I could react.
I had to make two hack patches to the DSS driver to circumvent the
problems. The hack patches are small and easily removed for -rc2
presuming the arch side gets fixed at that point.
So, this pull request got delayed until I could make the fixes and test
them, and thus I'm sending this directly to you, and not via fbdev tree.
I hope this is not too late to make it into 3.1-rc1.
Br,
Tomi
The following changes since commit 56299378726d5f2ba8d3c8cbbd13cb280ba45e4f:
Linux 3.0-rc4 (2011-06-20 20:25:46 -0700)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-3.1-rc1
Nishant Kamat (1):
OMAP: DSS: Minor cleanup in ovl and mgr cache structs
Tomi Valkeinen (30):
OMAP: DSS2: remove extra includes from include/video/omapdss.h
OMAP: DSS2: DSI: Change dummy macros to inline functions
OMAP: DSS2: OMAPFB: Add struct to store per-display data
OMAP: DSS2: OMAPFB: Implement auto-update mode
OMAP: DSS2: remove update_mode from omapdss
OMAP: DSS2: Taal: Make driver more fault tolerant
OMAP: DSS2: Reset LANEx_ULPS_SIG2 bits after use
OMAP: DSS2: Add FEAT_VENC_REQUIRES_TV_DAC_CLK
OMAP: DSS2: Add new FEAT definitions for features missing from OMAP2
OMAP: DSS2: Add Color Phase Rotation support
OMAP: DSS2: DSI: sync when disabling a display
OMAP: DSS2: Fix FIFO threshold and burst size for OMAP4
OMAP: DSS2: Handle dpll4_m4_ck in dss_get/put_clocks
OMAP: DSS2: Clean up probe for DSS & DSI
OMAP: DSS2: Fix init and unit sequence
OMAP: DSS2: Remove clk optimization at dss init
OMAP: DSS2: rewrite use of context_loss_count
OMAP: DSS2: Use omap_pm_get_dev_context_loss_count to get ctx loss count
OMAP: DSS2: DPI: remove unneeded SYSCK enable/disable
OMAP: DSS2: Remove core_dump_clocks
OMAP: DSS2: Remove CONFIG_OMAP2_DSS_SLEEP_BEFORE_RESET
OMAP: DSS2: Use PM runtime & HWMOD support
OMAP: DSS2: Remove unused opt_clock_available
OMAP: DSS2: DISPC: remove finegrained clk enables/disables
OMAP: DSS2: Remove unused code from display.c
OMAP: DSS2: Remove ctx loss count from dss.c
OMAP: DSS2: DISPC: Fix context save/restore
OMAP: DSS2: DSS: Fix context save/restore
HACK: OMAP: DSS2: clk hack for OMAP2/3
OMAP: DSS2: HDMI: fix hdmi clock name
arch/arm/mach-omap2/display.c | 26 +--
drivers/video/omap2/displays/panel-taal.c | 55 ++--
drivers/video/omap2/dss/Kconfig | 12 -
drivers/video/omap2/dss/core.c | 21 +-
drivers/video/omap2/dss/dispc.c | 562 ++++++++++++++++------------
drivers/video/omap2/dss/display.c | 57 +---
drivers/video/omap2/dss/dpi.c | 73 +++--
drivers/video/omap2/dss/dsi.c | 296 +++++++++------
drivers/video/omap2/dss/dss.c | 583 +++++++----------------------
drivers/video/omap2/dss/dss.h | 54 ++--
drivers/video/omap2/dss/dss_features.c | 36 ++-
drivers/video/omap2/dss/dss_features.h | 7 +
drivers/video/omap2/dss/hdmi.c | 162 ++++++--
drivers/video/omap2/dss/manager.c | 351 ++++++++++--------
drivers/video/omap2/dss/overlay.c | 27 +-
drivers/video/omap2/dss/rfbi.c | 114 +++++-
drivers/video/omap2/dss/sdi.c | 40 ++-
drivers/video/omap2/dss/venc.c | 183 +++++++--
drivers/video/omap2/omapfb/omapfb-ioctl.c | 72 ++--
drivers/video/omap2/omapfb/omapfb-main.c | 166 +++++++--
drivers/video/omap2/omapfb/omapfb-sysfs.c | 34 ++
drivers/video/omap2/omapfb/omapfb.h | 37 ++-
include/video/omapdss.h | 26 +-
23 files changed, 1639 insertions(+), 1355 deletions(-)
^ permalink raw reply
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-08-01 14:11 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Geert Uytterhoeven, Guennadi Liakhovetski, Paul Mundt,
linux-fbdev, linux-media, dri-devel
In-Reply-To: <4E35EC23.1010701@gmx.de>
Hi Florian,
On Monday 01 August 2011 01:58:27 Florian Tobias Schandinat wrote:
> On 07/31/2011 11:28 PM, Laurent Pinchart wrote:
> > On Monday 01 August 2011 00:54:48 Florian Tobias Schandinat wrote:
> >> On 07/31/2011 08:32 PM, Geert Uytterhoeven wrote:
> >>> On Thu, Jul 28, 2011 at 12:51, Laurent Pinchart wrote:
> >>>>> As for struct fb_var_screeninfo fields to support switching to a
> >>>>> FOURCC mode, I also prefer an explicit dedicated flag to specify
> >>>>> switching to it. Even though using FOURCC doesn't fit under the
> >>>>> notion of a videomode, using one of .vmode bits is too tempting, so,
> >>>>> I would actually take the plunge and use FB_VMODE_FOURCC.
> >>>>
> >>>> Another option would be to consider any grayscale> 1 value as a
> >>>> FOURCC. I've briefly checked the in-tree drivers: they only assign
> >>>> grayscale with 0 or 1, and check whether grayscale is 0 or different
> >>>> than 0. If a userspace application only sets grayscale> 1 when
> >>>> talking to a driver that supports the FOURCC-based API, we could get
> >>>> rid of the flag.
> >>>>
> >>>> What can't be easily found out is whether existing applications set
> >>>> grayscale to a> 1 value. They would break when used with
> >>>> FOURCC-aware drivers if we consider any grayscale> 1 value as a
> >>>> FOURCC. Is that a risk we can take ?
> >>>
> >>> I think we can. I'd expect applications to use either 1 or -1 (i.e.
> >>> all ones), both are
> >>> invalid FOURCC values.
> >>>
> >>> Still, I prefer the nonstd way.
> >>> And limiting traditional nonstd values to the lowest 24 bits (there
> >>> are no in-tree
> >>> drivers using the highest 8 bits, right?).
> >>
> >> Okay, it would be okay for me to
> >> - write raw FOURCC values in nonstd, enable FOURCC mode if upper byte !> >> 0 - not having an explicit flag to enable FOURCC
> >> - in FOURCC mode drivers must set visual to FB_VISUAL_FOURCC
> >> - making support of FOURCC visible to userspace by capabilites |> >> FB_CAP_FOURCC
> >>
> >> The capabilities is not strictly necessary but I think it's very useful
> >> as - it allows applications to make sure the extension is supported
> >> (for example to adjust the UI)
> >> - it allows applications to distinguish whether a particular format is
> >> not supported or FOURCC at all
> >> - it allows signaling further extensions of the API
> >> - it does not hurt, one line per driver and still some bytes in fixinfo
> >> free
> >
> > Without a FOURCC capability applications will need to try FOURCCs
> > blindly. Drivers that are not FOURCC aware would then risk interpreting
> > the FOURCC as something else. As you mention below applications will
> > need that check that visual = FB_VISUAL_FOURCC, so it's less of an
> > issue than I initially thought, but it doesn't become a non-issue. The
> > display might still show glitches.
>
> True.
>
> >> So using it would look like this:
> >> - the driver must have capabilities |= FB_CAP_FOURCC
> >> - the application may check capabilities to know whether FOURCC is
> >> supported - the application may write a raw FOURCC value in nonstd to
> >> request changing to FOURCC mode with this format
> >> - when the driver switches to a FOURCC mode it must have visual > >> FB_VISUAL_FOURCC and the current FOURCC format in nonstd
> >> - the application should check visual and nonstd to make sure it gets
> >> what it wanted
> >>
> >>
> >> So if there are no strong objections against this I think we should
> >> implement it. I do not really care whether we use a union or not but I
> >> think if we decide to have one it should cover all fields that are
> >> undefined/unused in FOURCC mode.
> >>
> >>
> >> Hope we can find anything that everyone considers acceptable,
> >
> > This sounds good to me, except that I would use the grayscale field
> > instead of the nonstd field. nonstd has pretty weird usecases, while
> > grayscale is better defined. nonstd might also make sense combined with
> > FOURCC-based modes, while grayscale would be completely redundant.
> >
> > What's your opinion on that ?
>
> I do not really care, either one would be okay for me.
> You're right that nonstd is used for a lot of things and perhaps some of
> those should still be possible in FOURCC mode. On the other hand I think
> applications are more likely to pass random values to grayscale as its
> meaning seems globally accepted (in contrast to nonstd where the
> application needs to know the driver to get any use of it).
> Perhaps you should also say that in FOURCC mode all unused pixel format
> fields should be set to 0 by the application and other values of those may
> get a meaning in later extensions or individual drivers.
Good point. I'll add that to the documentation.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: Patch fixing savagefb driver typo/regression in linux-3.0.0
From: Tormod Volden @ 2011-08-01 22:56 UTC (permalink / raw)
To: linux-fbdev
On Sun, Jul 31, 2011 at 12:04 PM, John Stanley wrote:
> I have an old T22 Thinkpad with integrated Savage/IX-MV video. As of
> linux-3.0, the video is non-functional; the PC either hard hangs immediately
> or has totally garbled video, and then hard hangs, as soon as I attempt to
> edit a file or cat a file with more than a screen-full of text. The
> foregoing details are actually not important any more as in looking at the
> code changes I discovered a typo in
> linux-3.0.0/drivers/video/savage/savagefb.h and have applied the attached
> patch to fix the issue.
John, you are absolutely correct. My bad, this was from a commit of
mine. You may add my
Reviewed-by: Tormod Volden <debian.tormod@gmail.com>
to your patch. I'd suggest you change the patch description (mail
subject) to "[PATCH] Fix typo in savage4 series definition" or
something similar.
The patch should also go into the stable series (by cc'ing
stable@vger.kernel.org if I remember correctly).
> PLEASE NOTE:
> I realize that the patch does not quite adhere to linux kernel patch
> coding-style conventions (in particular, spaces around logical operators,
> and lines not exceeding 80 chars), but I have simply changed an
> '||' to an '&&' -- and NOT attempted to resolve pre-existing coding-style
> violations.
I also preserved the old coding style, which is the same in the xorg
driver which shares much of this code. We can always change it there
as well if somebody would like to fix it up.
>
> thanks much,
> John
>
> P.S. Many, many thanks for lifting the 800x600 resolution limit! I've been
> using a patch/hack to bump the limit to 1024x768 for an very long time...
Glad to hear that! So there are still other savagefb users around :)
My apologies to those who were affected by the typo.
Cheers,
Tormod
^ permalink raw reply
* Re: [PATCHv2 17/28] OMAP2420: HWMOD: Add DSS opt clocks
From: Paul Walmsley @ 2011-08-02 1:14 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, b-cousson, khilman
In-Reply-To: <alpine.DEB.2.00.1107150047160.16606@utopia.booyaka.com>
Hello Tomi
On Fri, 15 Jul 2011, Paul Walmsley wrote:
> On Thu, 9 Jun 2011, Tomi Valkeinen wrote:
>
> > Add DSS optional clocks to HWMOD data for OMAP2420.
This patch has been combined with the 2430 patch and the OMAP2xxx portion
of the temporary hack in the DSS driver has been removed. Care to review
the new changes before it's sent to Tony?
- Paul
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Mon, 1 Aug 2011 19:02:23 -0600
Subject: [PATCH 1/2] OMAP2xxx: HWMOD: Add DSS opt clocks
Add DSS optional clocks to HWMOD data for OMAP2420 and OMAP2430.
Revert OMAP2xxx portion of commit
9ede365aa6f74428a1f69c21ca1cf21213167576 ("HACK: OMAP: DSS2: clk hack
for OMAP2/3").
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[paul@pwsan.com: merge 2420 and 2430 patches; remove temporary DSS driver hack;
update changelog]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 17 ++++++++---------
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 17 ++++++++---------
drivers/video/omap2/dss/rfbi.c | 2 +-
3 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a015c69..b075188 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -873,11 +873,6 @@ static struct omap_hwmod_ocp_if *omap2420_dss_slaves[] = {
&omap2420_l4_core__dss,
};
-static struct omap_hwmod_opt_clk dss_opt_clks[] = {
- { .role = "tv_clk", .clk = "dss_54m_fck" },
- { .role = "sys_clk", .clk = "dss2_fck" },
-};
-
static struct omap_hwmod omap2420_dss_core_hwmod = {
.name = "dss_core",
.class = &omap2_dss_hwmod_class,
@@ -892,8 +887,6 @@ static struct omap_hwmod omap2420_dss_core_hwmod = {
.idlest_stdby_bit = OMAP24XX_ST_DSS_SHIFT,
},
},
- .opt_clks = dss_opt_clks,
- .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
.slaves = omap2420_dss_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_dss_slaves),
.masters = omap2420_dss_masters,
@@ -962,6 +955,10 @@ static struct omap_hwmod_ocp_if *omap2420_dss_rfbi_slaves[] = {
&omap2420_l4_core__dss_rfbi,
};
+static struct omap_hwmod_opt_clk dss_rfbi_opt_clks[] = {
+ { .role = "ick", .clk = "dss_ick" },
+};
+
static struct omap_hwmod omap2420_dss_rfbi_hwmod = {
.name = "dss_rfbi",
.class = &omap2_rfbi_hwmod_class,
@@ -973,6 +970,8 @@ static struct omap_hwmod omap2420_dss_rfbi_hwmod = {
.module_offs = CORE_MOD,
},
},
+ .opt_clks = dss_rfbi_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_rfbi_opt_clks),
.slaves = omap2420_dss_rfbi_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_dss_rfbi_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
@@ -983,7 +982,7 @@ static struct omap_hwmod omap2420_dss_rfbi_hwmod = {
static struct omap_hwmod_ocp_if omap2420_l4_core__dss_venc = {
.master = &omap2420_l4_core_hwmod,
.slave = &omap2420_dss_venc_hwmod,
- .clk = "dss_54m_fck",
+ .clk = "dss_ick",
.addr = omap2_dss_venc_addrs,
.fw = {
.omap2 = {
@@ -1003,7 +1002,7 @@ static struct omap_hwmod_ocp_if *omap2420_dss_venc_slaves[] = {
static struct omap_hwmod omap2420_dss_venc_hwmod = {
.name = "dss_venc",
.class = &omap2_venc_hwmod_class,
- .main_clk = "dss1_fck",
+ .main_clk = "dss_54m_fck",
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 16743c7..3569084 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -939,11 +939,6 @@ static struct omap_hwmod_ocp_if *omap2430_dss_slaves[] = {
&omap2430_l4_core__dss,
};
-static struct omap_hwmod_opt_clk dss_opt_clks[] = {
- { .role = "tv_clk", .clk = "dss_54m_fck" },
- { .role = "sys_clk", .clk = "dss2_fck" },
-};
-
static struct omap_hwmod omap2430_dss_core_hwmod = {
.name = "dss_core",
.class = &omap2_dss_hwmod_class,
@@ -958,8 +953,6 @@ static struct omap_hwmod omap2430_dss_core_hwmod = {
.idlest_stdby_bit = OMAP24XX_ST_DSS_SHIFT,
},
},
- .opt_clks = dss_opt_clks,
- .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
.slaves = omap2430_dss_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_dss_slaves),
.masters = omap2430_dss_masters,
@@ -1016,6 +1009,10 @@ static struct omap_hwmod_ocp_if *omap2430_dss_rfbi_slaves[] = {
&omap2430_l4_core__dss_rfbi,
};
+static struct omap_hwmod_opt_clk dss_rfbi_opt_clks[] = {
+ { .role = "ick", .clk = "dss_ick" },
+};
+
static struct omap_hwmod omap2430_dss_rfbi_hwmod = {
.name = "dss_rfbi",
.class = &omap2_rfbi_hwmod_class,
@@ -1027,6 +1024,8 @@ static struct omap_hwmod omap2430_dss_rfbi_hwmod = {
.module_offs = CORE_MOD,
},
},
+ .opt_clks = dss_rfbi_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_rfbi_opt_clks),
.slaves = omap2430_dss_rfbi_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_dss_rfbi_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
@@ -1037,7 +1036,7 @@ static struct omap_hwmod omap2430_dss_rfbi_hwmod = {
static struct omap_hwmod_ocp_if omap2430_l4_core__dss_venc = {
.master = &omap2430_l4_core_hwmod,
.slave = &omap2430_dss_venc_hwmod,
- .clk = "dss_54m_fck",
+ .clk = "dss_ick",
.addr = omap2_dss_venc_addrs,
.flags = OCPIF_SWSUP_IDLE,
.user = OCP_USER_MPU | OCP_USER_SDMA,
@@ -1051,7 +1050,7 @@ static struct omap_hwmod_ocp_if *omap2430_dss_venc_slaves[] = {
static struct omap_hwmod omap2430_dss_venc_hwmod = {
.name = "dss_venc",
.class = &omap2_venc_hwmod_class,
- .main_clk = "dss1_fck",
+ .main_clk = "dss_54m_fck",
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 39f4c59..457f1ac 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -952,7 +952,7 @@ static int omap_rfbihw_probe(struct platform_device *pdev)
msleep(10);
- if (cpu_is_omap24xx() || cpu_is_omap34xx() || cpu_is_omap3630())
+ if (cpu_is_omap34xx() || cpu_is_omap3630())
clk = dss_get_ick();
else
clk = clk_get(&pdev->dev, "ick");
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCHv2 16/28] OMAP3: HWMOD: Add DSS opt clocks
From: Paul Walmsley @ 2011-08-02 1:27 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, b-cousson, khilman
In-Reply-To: <alpine.DEB.2.00.1107150048530.16606@utopia.booyaka.com>
Hello Tomi,
On Fri, 15 Jul 2011, Paul Walmsley wrote:
> 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'.
This patch has been updated to remove the temporary hack added to the DSS
driver. Care to review it before it's sent to Tony?
- Paul
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Fri, 15 Jul 2011 00:54:34 -0600
Subject: [PATCH 2/2] OMAP3: HWMOD: Add DSS opt clocks
Add DSS optional clocks to HWMOD data for OMAP3xxx.
Revert OMAP3 portion of commit
9ede365aa6f74428a1f69c21ca1cf21213167576 ("HACK: OMAP: DSS2: clk hack
for OMAP2/3").
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[paul@pwsan.com: remove temporary DSS driver hack; update changelog]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 32 ++++++++++++++++++++++++---
drivers/video/omap2/dss/dsi.c | 2 +-
drivers/video/omap2/dss/dss.h | 2 -
drivers/video/omap2/dss/rfbi.c | 5 +---
drivers/video/omap2/dss/venc.c | 5 +---
5 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 25bf43b..38ee033 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1365,9 +1365,14 @@ static struct omap_hwmod_ocp_if *omap3xxx_dss_slaves[] = {
};
static struct omap_hwmod_opt_clk dss_opt_clks[] = {
- { .role = "tv_clk", .clk = "dss_tv_fck" },
- { .role = "video_clk", .clk = "dss_96m_fck" },
+ /*
+ * The rest of the clocks are not needed by the driver,
+ * but are needed by the hwmod to reset DSS properly.
+ */
{ .role = "sys_clk", .clk = "dss2_alwon_fck" },
+ { .role = "tv_clk", .clk = "dss_tv_fck" },
+ /* required only on OMAP3430 */
+ { .role = "tv_dac_clk", .clk = "dss_96m_fck" },
};
static struct omap_hwmod omap3430es1_dss_core_hwmod = {
@@ -1504,6 +1509,10 @@ static struct omap_hwmod_ocp_if *omap3xxx_dss_dsi1_slaves[] = {
&omap3xxx_l4_core__dss_dsi1,
};
+static struct omap_hwmod_opt_clk dss_dsi1_opt_clks[] = {
+ { .role = "sys_clk", .clk = "dss2_alwon_fck" },
+};
+
static struct omap_hwmod omap3xxx_dss_dsi1_hwmod = {
.name = "dss_dsi1",
.class = &omap3xxx_dsi_hwmod_class,
@@ -1516,6 +1525,8 @@ static struct omap_hwmod omap3xxx_dss_dsi1_hwmod = {
.module_offs = OMAP3430_DSS_MOD,
},
},
+ .opt_clks = dss_dsi1_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_dsi1_opt_clks),
.slaves = omap3xxx_dss_dsi1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_dss_dsi1_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1 |
@@ -1545,6 +1556,10 @@ static struct omap_hwmod_ocp_if *omap3xxx_dss_rfbi_slaves[] = {
&omap3xxx_l4_core__dss_rfbi,
};
+static struct omap_hwmod_opt_clk dss_rfbi_opt_clks[] = {
+ { .role = "ick", .clk = "dss_ick" },
+};
+
static struct omap_hwmod omap3xxx_dss_rfbi_hwmod = {
.name = "dss_rfbi",
.class = &omap2_rfbi_hwmod_class,
@@ -1556,6 +1571,8 @@ static struct omap_hwmod omap3xxx_dss_rfbi_hwmod = {
.module_offs = OMAP3430_DSS_MOD,
},
},
+ .opt_clks = dss_rfbi_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_rfbi_opt_clks),
.slaves = omap3xxx_dss_rfbi_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_dss_rfbi_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1 |
@@ -1568,7 +1585,7 @@ static struct omap_hwmod omap3xxx_dss_rfbi_hwmod = {
static struct omap_hwmod_ocp_if omap3xxx_l4_core__dss_venc = {
.master = &omap3xxx_l4_core_hwmod,
.slave = &omap3xxx_dss_venc_hwmod,
- .clk = "dss_tv_fck",
+ .clk = "dss_ick",
.addr = omap2_dss_venc_addrs,
.fw = {
.omap2 = {
@@ -1586,10 +1603,15 @@ static struct omap_hwmod_ocp_if *omap3xxx_dss_venc_slaves[] = {
&omap3xxx_l4_core__dss_venc,
};
+static struct omap_hwmod_opt_clk dss_venc_opt_clks[] = {
+ /* required only on OMAP3430 */
+ { .role = "tv_dac_clk", .clk = "dss_96m_fck" },
+};
+
static struct omap_hwmod omap3xxx_dss_venc_hwmod = {
.name = "dss_venc",
.class = &omap2_venc_hwmod_class,
- .main_clk = "dss1_alwon_fck",
+ .main_clk = "dss_tv_fck",
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -1597,6 +1619,8 @@ static struct omap_hwmod omap3xxx_dss_venc_hwmod = {
.module_offs = OMAP3430_DSS_MOD,
},
},
+ .opt_clks = dss_venc_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_venc_opt_clks),
.slaves = omap3xxx_dss_venc_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_dss_venc_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1 |
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 7adbbeb..0645170 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4427,7 +4427,7 @@ static int dsi_get_clocks(struct platform_device *dsidev)
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
struct clk *clk;
- clk = clk_get(&dsidev->dev, "fck");
+ clk = clk_get(&dsidev->dev, "sys_clk");
if (IS_ERR(clk)) {
DSSERR("can't get fck\n");
return PTR_ERR(clk);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 9c94b11..adeff04 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -209,8 +209,6 @@ void dss_uninit_platform_driver(void);
int dss_runtime_get(void);
void dss_runtime_put(void);
-struct clk *dss_get_ick(void);
-
void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select);
const char *dss_get_generic_clk_source_name(enum omap_dss_clk_source clk_src);
void dss_dump_clocks(struct seq_file *s);
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 457f1ac..2d31cc1 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -952,10 +952,7 @@ static int omap_rfbihw_probe(struct platform_device *pdev)
msleep(10);
- if (cpu_is_omap34xx() || cpu_is_omap3630())
- clk = dss_get_ick();
- else
- clk = clk_get(&pdev->dev, "ick");
+ clk = clk_get(&pdev->dev, "ick");
if (IS_ERR(clk)) {
DSSERR("can't get ick\n");
r = PTR_ERR(clk);
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 173c664..71e005d 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -741,10 +741,7 @@ static int venc_get_clocks(struct platform_device *pdev)
venc.tv_clk = clk;
if (dss_has_feature(FEAT_VENC_REQUIRES_TV_DAC_CLK)) {
- if (cpu_is_omap34xx() || cpu_is_omap3630())
- clk = clk_get(&pdev->dev, "dss_96m_fck");
- else
- clk = clk_get(&pdev->dev, "tv_dac_clk");
+ clk = clk_get(&pdev->dev, "tv_dac_clk");
if (IS_ERR(clk)) {
DSSERR("can't get tv_dac_clk\n");
clk_put(venc.tv_clk);
--
1.7.5.4
^ permalink raw reply related
* [PATCH] Fix typo in savage4 series definition in linux-3.0.0
From: John Stanley @ 2011-08-02 3:19 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 2127 bytes --]
Thanks Tormod,
Attached is the same patch, but with your 'Reviewed-by' added.
Yeah, the T22 is rather old, and a bit of a 'Frankenstein PC' at this
point, but its quite functional even with Linux-3.0 and KDE-4.7
thanks again,
John
On 08/01/2011 06:56 PM, Tormod Volden wrote:
> On Sun, Jul 31, 2011 at 12:04 PM, John Stanley wrote:
>> I have an old T22 Thinkpad with integrated Savage/IX-MV video. As of
>> linux-3.0, the video is non-functional; the PC either hard hangs immediately
>> or has totally garbled video, and then hard hangs, as soon as I attempt to
>> edit a file or cat a file with more than a screen-full of text. The
>> foregoing details are actually not important any more as in looking at the
>> code changes I discovered a typo in
>> linux-3.0.0/drivers/video/savage/savagefb.h and have applied the attached
>> patch to fix the issue.
> John, you are absolutely correct. My bad, this was from a commit of
> mine. You may add my
> Reviewed-by: Tormod Volden<debian.tormod@gmail.com>
> to your patch. I'd suggest you change the patch description (mail
> subject) to "[PATCH] Fix typo in savage4 series definition" or
> something similar.
>
> The patch should also go into the stable series (by cc'ing
> stable@vger.kernel.org if I remember correctly).
>
>> PLEASE NOTE:
>> I realize that the patch does not quite adhere to linux kernel patch
>> coding-style conventions (in particular, spaces around logical operators,
>> and lines not exceeding 80 chars), but I have simply changed an
>> '||' to an'&&' -- and NOT attempted to resolve pre-existing coding-style
>> violations.
> I also preserved the old coding style, which is the same in the xorg
> driver which shares much of this code. We can always change it there
> as well if somebody would like to fix it up.
>
>> thanks much,
>> John
>>
>> P.S. Many, many thanks for lifting the 800x600 resolution limit! I've been
>> using a patch/hack to bump the limit to 1024x768 for an very long time...
> Glad to hear that! So there are still other savagefb users around :)
> My apologies to those who were affected by the typo.
>
> Cheers,
> Tormod
>
[-- Attachment #2: linux-3.0.0-savagefb-savage4-series-def-fix.patch --]
[-- Type: text/plain, Size: 1344 bytes --]
This patch corrects a typo/regression in the savage driver code occurring in going
from linux-2.6.39.3 to linux-3.0.0.
In linux-2.6.39.3, there were two savage4 variants (S3_SAVAGE4 and S3_PROSAVAGE).
Hence, S3_SAVAGE4_SERIES was defined as
S3_SAVAGE4 or S3_PROSAVAGE
In linux-3.0.0, two additional savage4 variants (S3_TWISTER and S3_PROSAVAGEDDR) have
been added. Hence S3_SAVAGE4_SERIES should be defined as
S3_SAVAGE4, S3_PROSAVAGE, S3_TWISTER, or S3_PROSAVAGEDDR
In going from linux-2.6.39.3 to linux-3.0.0, the define statement for S3_SAVAGE4_SERIES
was incompletely modified: the '||' should have been changed to an '&&'; for an '||' will
set S3_SAVAGE4_SERIES true for any card.
Signed-off-by: John P. Stanley <jpsinthemix@verizon.net>
Reviewed-by: Tormod Volden <debian.tormod@gmail.com>
--- linux-3.0.0/drivers/video/savage/savagefb.h.orig 2011-07-21 22:17:23.000000000 -0400
+++ linux-3.0.0/drivers/video/savage/savagefb.h 2011-07-31 05:27:47.314798215 -0400
@@ -55,7 +55,7 @@
#define S3_SAVAGE3D_SERIES(chip) ((chip>=S3_SAVAGE3D) && (chip<=S3_SAVAGE_MX))
-#define S3_SAVAGE4_SERIES(chip) ((chip>=S3_SAVAGE4) || (chip<=S3_PROSAVAGEDDR))
+#define S3_SAVAGE4_SERIES(chip) ((chip>=S3_SAVAGE4) && (chip<=S3_PROSAVAGEDDR))
#define S3_SAVAGE_MOBILE_SERIES(chip) ((chip==S3_SAVAGE_MX) || (chip==S3_SUPERSAVAGE))
^ permalink raw reply
* [PATCH 1/5] udlfb: add more comprehensive support for DPMS FB_BLANK_* modes
From: bernie @ 2011-08-02 5:54 UTC (permalink / raw)
To: linux-fbdev
From: Bernie Thompson <bernie@plugable.com>
Fixes earlier problems where monitor would not return from blank
Test with any DisplayLink-based USB 2.0 graphics adapter
sudo nano /sys/class/graphics/fb?/blank
and write out single digit FB_BLANK_* code from include/linux/fb.h
Supports on (0), blank (1), suspend (2,3), powerdown (4)
Signed-off-by: Bernie Thompson <bernie@plugable.com>
---
drivers/video/udlfb.c | 97 +++++++++++++++++++++++++++++++++++++------------
include/video/udlfb.h | 1 +
2 files changed, 74 insertions(+), 24 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 4e13375..844b371 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -104,17 +104,39 @@ static char *dlfb_vidreg_unlock(char *buf)
}
/*
- * On/Off for driving the DisplayLink framebuffer to the display
- * 0x00 H and V sync on
- * 0x01 H and V sync off (screen blank but powered)
- * 0x07 DPMS powerdown (requires modeset to come back)
+ * Map FB_BLANK_* to DisplayLink register
+ * DLReg FB_BLANK_*
+ * ----- -----------------------------
+ * 0x00 FB_BLANK_UNBLANK (0)
+ * 0x01 FB_BLANK (1)
+ * 0x03 FB_BLANK_VSYNC_SUSPEND (2)
+ * 0x05 FB_BLANK_HSYNC_SUSPEND (3)
+ * 0x07 FB_BLANK_POWERDOWN (4) Note: requires modeset to come back
*/
-static char *dlfb_enable_hvsync(char *buf, bool enable)
+static char *dlfb_blanking(char *buf, int fb_blank)
{
- if (enable)
- return dlfb_set_register(buf, 0x1F, 0x00);
- else
- return dlfb_set_register(buf, 0x1F, 0x07);
+ u8 reg;
+
+ switch (fb_blank) {
+ case FB_BLANK_POWERDOWN:
+ reg = 0x07;
+ break;
+ case FB_BLANK_HSYNC_SUSPEND:
+ reg = 0x05;
+ break;
+ case FB_BLANK_VSYNC_SUSPEND:
+ reg = 0x03;
+ break;
+ case FB_BLANK_NORMAL:
+ reg = 0x01;
+ break;
+ default:
+ reg = 0x00;
+ }
+
+ buf = dlfb_set_register(buf, 0x1F, reg);
+
+ return buf;
}
static char *dlfb_set_color_depth(char *buf, u8 selection)
@@ -282,13 +304,15 @@ static int dlfb_set_video_mode(struct dlfb_data *dev,
wrptr = dlfb_set_base8bpp(wrptr, dev->info->fix.smem_len);
wrptr = dlfb_set_vid_cmds(wrptr, var);
- wrptr = dlfb_enable_hvsync(wrptr, true);
+ wrptr = dlfb_blanking(wrptr, FB_BLANK_UNBLANK);
wrptr = dlfb_vidreg_unlock(wrptr);
writesize = wrptr - buf;
retval = dlfb_submit_urb(dev, urb, writesize);
+ dev->blank_mode = FB_BLANK_UNBLANK;
+
return retval;
}
@@ -1049,32 +1073,57 @@ static int dlfb_ops_set_par(struct fb_info *info)
return result;
}
+/* To fonzi the jukebox (e.g. make blanking changes take effect) */
+static char *dlfb_dummy_render(char *buf)
+{
+ *buf++ = 0xAF;
+ *buf++ = 0x6A; /* copy */
+ *buf++ = 0x00; /* from address*/
+ *buf++ = 0x00;
+ *buf++ = 0x00;
+ *buf++ = 0x01; /* one pixel */
+ *buf++ = 0x00; /* to address */
+ *buf++ = 0x00;
+ *buf++ = 0x00;
+ return buf;
+}
+
/*
* In order to come back from full DPMS off, we need to set the mode again
*/
static int dlfb_ops_blank(int blank_mode, struct fb_info *info)
{
struct dlfb_data *dev = info->par;
+ char *bufptr;
+ struct urb *urb;
- if (blank_mode != FB_BLANK_UNBLANK) {
- char *bufptr;
- struct urb *urb;
-
- urb = dlfb_get_urb(dev);
- if (!urb)
- return 0;
+ pr_info("/dev/fb%d FB_BLANK mode %d --> %d\n",
+ info->node, dev->blank_mode, blank_mode);
- bufptr = (char *) urb->transfer_buffer;
- bufptr = dlfb_vidreg_lock(bufptr);
- bufptr = dlfb_enable_hvsync(bufptr, false);
- bufptr = dlfb_vidreg_unlock(bufptr);
+ if ((dev->blank_mode = FB_BLANK_POWERDOWN) &&
+ (blank_mode != FB_BLANK_POWERDOWN)) {
- dlfb_submit_urb(dev, urb, bufptr -
- (char *) urb->transfer_buffer);
- } else {
+ /* returning from powerdown requires a fresh modeset */
dlfb_set_video_mode(dev, &info->var);
}
+ urb = dlfb_get_urb(dev);
+ if (!urb)
+ return 0;
+
+ bufptr = (char *) urb->transfer_buffer;
+ bufptr = dlfb_vidreg_lock(bufptr);
+ bufptr = dlfb_blanking(bufptr, blank_mode);
+ bufptr = dlfb_vidreg_unlock(bufptr);
+
+ /* seems like a render op is needed to have blank change take effect */
+ bufptr = dlfb_dummy_render(bufptr);
+
+ dlfb_submit_urb(dev, urb, bufptr -
+ (char *) urb->transfer_buffer);
+
+ dev->blank_mode = blank_mode;
+
return 0;
}
diff --git a/include/video/udlfb.h b/include/video/udlfb.h
index 69d485a..c41f308 100644
--- a/include/video/udlfb.h
+++ b/include/video/udlfb.h
@@ -50,6 +50,7 @@ struct dlfb_data {
int base16;
int base8;
u32 pseudo_palette[256];
+ int blank_mode; /*one of FB_BLANK_ */
/* blit-only rendering path metrics, exposed through sysfs */
atomic_t bytes_rendered; /* raw pixel-bytes driver asked to render */
atomic_t bytes_identical; /* saved effort with backbuffer comparison */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/5] udlfb: Search config descriptor if not at device level
From: bernie @ 2011-08-02 5:54 UTC (permalink / raw)
To: linux-fbdev
From: Andrew Kephart <akephart@akephart.org>
For at least one DisplayLink device, the vendor-specific information can
be found in the config descriptor instead of as a separate, device-level
descriptor. This patch searches the current interface (of the current
config descriptor) for the DL vendor-specific descriptor.
Signed-off-by: Andrew Kephart <akephart@akephart.org>
Signed-off-by: Bernie Thompson <bernie@plugable.com>
---
drivers/video/udlfb.c | 21 ++++++++++++++++-----
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 844b371..bdd21de 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1489,21 +1489,30 @@ static int dlfb_select_std_channel(struct dlfb_data *dev)
}
static int dlfb_parse_vendor_descriptor(struct dlfb_data *dev,
- struct usb_device *usbdev)
+ struct usb_interface *interface)
{
char *desc;
char *buf;
char *desc_end;
- u8 total_len = 0;
+ int total_len = 0;
buf = kzalloc(MAX_VENDOR_DESCRIPTOR_SIZE, GFP_KERNEL);
if (!buf)
return false;
desc = buf;
- total_len = usb_get_descriptor(usbdev, 0x5f, /* vendor specific */
- 0, desc, MAX_VENDOR_DESCRIPTOR_SIZE);
+ total_len = usb_get_descriptor(interface_to_usbdev(interface),
+ 0x5f, /* vendor specific */
+ 0, desc, MAX_VENDOR_DESCRIPTOR_SIZE);
+
+ /* if not found, look in configuration descriptor */
+ if (total_len < 0) {
+ if (0 = usb_get_extra_descriptor(interface->cur_altsetting,
+ 0x5f, &desc))
+ total_len = (int) desc[0];
+ }
+
if (total_len > 5) {
pr_info("vendor descriptor length:%x data:%02x %02x %02x %02x" \
"%02x %02x %02x %02x %02x %02x %02x\n",
@@ -1544,6 +1553,8 @@ static int dlfb_parse_vendor_descriptor(struct dlfb_data *dev,
}
desc += length;
}
+ } else {
+ pr_info("vendor descriptor not available (%d)\n", total_len);
}
goto success;
@@ -1593,7 +1604,7 @@ static int dlfb_usb_probe(struct usb_interface *interface,
dev->sku_pixel_limit = 2048 * 1152; /* default to maximum */
- if (!dlfb_parse_vendor_descriptor(dev, usbdev)) {
+ if (!dlfb_parse_vendor_descriptor(dev, interface)) {
pr_err("firmware not recognized. Assume incompatible device\n");
goto error;
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/5] udlfb: fix issues found with Sparse static analysis
From: bernie @ 2011-08-02 5:54 UTC (permalink / raw)
To: linux-fbdev
From: Dr. David Alan Gilbert <linux@treblig.org>
Add __user casting, a missing copy_from_user, and proper boolean
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Bernie Thompson <bernie@plugable.com>
---
drivers/video/udlfb.c | 30 ++++++++++++++++--------------
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index bdd21de..f5df3d3 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -786,14 +786,13 @@ static int dlfb_ops_ioctl(struct fb_info *info, unsigned int cmd,
{
struct dlfb_data *dev = info->par;
- struct dloarea *area = NULL;
if (!atomic_read(&dev->usb_active))
return 0;
/* TODO: Update X server to get this from sysfs instead */
if (cmd = DLFB_IOCTL_RETURN_EDID) {
- char *edid = (char *)arg;
+ void __user *edid = (void __user *)arg;
if (copy_to_user(edid, dev->edid, dev->edid_size))
return -EFAULT;
return 0;
@@ -801,6 +800,11 @@ static int dlfb_ops_ioctl(struct fb_info *info, unsigned int cmd,
/* TODO: Help propose a standard fb.h ioctl to report mmap damage */
if (cmd = DLFB_IOCTL_REPORT_DAMAGE) {
+ struct dloarea area;
+
+ if (copy_from_user(&area, (void __user *)arg,
+ sizeof(struct dloarea)))
+ return -EFAULT;
/*
* If we have a damage-aware client, turn fb_defio "off"
@@ -812,21 +816,19 @@ static int dlfb_ops_ioctl(struct fb_info *info, unsigned int cmd,
if (info->fbdefio)
info->fbdefio->delay = DL_DEFIO_WRITE_DISABLE;
- area = (struct dloarea *)arg;
-
- if (area->x < 0)
- area->x = 0;
+ if (area.x < 0)
+ area.x = 0;
- if (area->x > info->var.xres)
- area->x = info->var.xres;
+ if (area.x > info->var.xres)
+ area.x = info->var.xres;
- if (area->y < 0)
- area->y = 0;
+ if (area.y < 0)
+ area.y = 0;
- if (area->y > info->var.yres)
- area->y = info->var.yres;
+ if (area.y > info->var.yres)
+ area.y = info->var.yres;
- dlfb_handle_damage(dev, area->x, area->y, area->w, area->h,
+ dlfb_handle_damage(dev, area.x, area.y, area.w, area.h,
info->screen_base);
}
@@ -874,7 +876,7 @@ static int dlfb_ops_open(struct fb_info *info, int user)
* preventing other clients (X) from working properly. Usually
* not what the user wants. Fail by default with option to enable.
*/
- if ((user = 0) & (!console))
+ if ((user = 0) && (!console))
return -EBUSY;
/* If the USB device is gone, we don't accept new opens */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 4/5] udlfb: Add module option to do without shadow framebuffer
From: bernie @ 2011-08-02 5:54 UTC (permalink / raw)
To: linux-fbdev
From: Stuart Hopkins <stuart@linux-depot.com>
By default, udlfb allocates a 2nd buffer to shadow what's across
the bus on the USB device. It can operate without this shadow,
but then it cannot tell which pixels have changed, and must send all.
Saves host memory, but worsens the USB 2.0 bus bottleneck.
This option allows users in very low memory situations (e.g.
bifferboard) to optionally turn off this shadow framebuffer.
Signed-off-by: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Stuart Hopkins <stuart@linux-depot.com>
---
Documentation/fb/udlfb.txt | 5 +++++
drivers/video/udlfb.c | 10 ++++++++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/fb/udlfb.txt b/Documentation/fb/udlfb.txt
index 7fdde2a..473ceed 100644
--- a/Documentation/fb/udlfb.txt
+++ b/Documentation/fb/udlfb.txt
@@ -105,6 +105,11 @@ console Allow fbcon to attach to udlfb provided framebuffers. This
the first framebuffer it finds, which isn't usually what the
user wants in the case of USB displays.
+shadow Allocate a 2nd framebuffer to shadow what's currently across
+ the USB bus in device memory. If any pixels are unchanged,
+ do not transmit. Spends host memory to save USB transfers.
+ Enabled by default. Only disable on very low memory systems.
+
Sysfs Attributes
========
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index f5df3d3..5a13dc5 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -72,6 +72,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
/* module options */
static int console; /* Optionally allow fbcon to consume first framebuffer */
static int fb_defio; /* Optionally enable experimental fb_defio mmap support */
+static int shadow = 1; /* Optionally disable shadow framebuffer */
/* dlfb keeps a list of urbs for efficient bulk transfers */
static void dlfb_urb_completion(struct urb *urb);
@@ -1158,7 +1159,7 @@ static int dlfb_realloc_framebuffer(struct dlfb_data *dev, struct fb_info *info)
int new_len;
unsigned char *old_fb = info->screen_base;
unsigned char *new_fb;
- unsigned char *new_back;
+ unsigned char *new_back = 0;
pr_warn("Reallocating framebuffer. Addresses will change!\n");
@@ -1190,7 +1191,8 @@ static int dlfb_realloc_framebuffer(struct dlfb_data *dev, struct fb_info *info)
* But with imperfect damage info we may send pixels over USB
* that were, in fact, unchanged - wasting limited USB bandwidth
*/
- new_back = vzalloc(new_len);
+ if (shadow)
+ new_back = vzalloc(new_len);
if (!new_back)
pr_info("No shadow/backing buffer allocated\n");
else {
@@ -1603,6 +1605,7 @@ static int dlfb_usb_probe(struct usb_interface *interface,
usbdev->descriptor.bcdDevice, dev);
pr_info("console enable=%d\n", console);
pr_info("fb_defio enable=%d\n", fb_defio);
+ pr_info("shadow enable=%d\n", shadow);
dev->sku_pixel_limit = 2048 * 1152; /* default to maximum */
@@ -1960,6 +1963,9 @@ MODULE_PARM_DESC(console, "Allow fbcon to consume first framebuffer found");
module_param(fb_defio, bool, S_IWUSR | S_IRUSR | S_IWGRP | S_IRGRP);
MODULE_PARM_DESC(fb_defio, "Enable fb_defio mmap support. *Experimental*");
+module_param(shadow, bool, S_IWUSR | S_IRUSR | S_IWGRP | S_IRGRP);
+MODULE_PARM_DESC(shadow, "Shadow vid mem. Disable to save mem but lose perf");
+
MODULE_AUTHOR("Roberto De Ioris <roberto@unbit.it>, "
"Jaya Kumar <jayakumar.lkml@gmail.com>, "
"Bernie Thompson <bernie@plugable.com>");
--
1.7.4.1
^ permalink raw reply related
* [PATCH 5/5] udlfb: Enable fb_defio by default
From: bernie @ 2011-08-02 5:54 UTC (permalink / raw)
To: linux-fbdev
From: Bernie Thompson <bernie@plugable.com>
Enables page fault based detection of mmap writes to the framebuffer,
which allows standard fbdev apps (like the generic fbdev xorg driver)
to work on DisplayLink devices.
Not all bugs are shaken out of the fb_defio path of udlfb, but it's
tantalizingly close, so this seems a good time to enable by default.
Alternatively, option can be disabled when running with an xorg driver
that can more directly communicate damaged regions of the framebuffer
via IOCTL. This is a simpler, higher perf option, when available.
Signed-off-by: Bernie Thompson <bernie@plugable.com>
---
Documentation/fb/udlfb.txt | 24 ++++++++++++++++--------
drivers/video/udlfb.c | 4 ++--
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/Documentation/fb/udlfb.txt b/Documentation/fb/udlfb.txt
index 473ceed..c6d90a6 100644
--- a/Documentation/fb/udlfb.txt
+++ b/Documentation/fb/udlfb.txt
@@ -87,20 +87,28 @@ Special configuration for udlfb is usually unnecessary. There are a few
options, however.
From the command line, pass options to modprobe
-modprobe udlfb defio=1 console=1
+modprobe udlfb fb_defio=0 console=1 shadow=1
-Or for permanent option, create file like /etc/modprobe.d/options with text
-options udlfb defio=1 console=1
+Or modify options on the fly at /sys/module/udlfb/parameters directory via
+sudo nano fb_defio
+change the parameter in place, and save the file.
-Accepted options:
+Unplug/replug USB device to apply with new settings
+
+Or for permanent option, create file like /etc/modprobe.d/udlfb.conf with text
+options udlfb fb_defio=0 console=1 shadow=1
+
+Accepted boolean options:
fb_defio Make use of the fb_defio (CONFIG_FB_DEFERRED_IO) kernel
module to track changed areas of the framebuffer by page faults.
- Standard fbdev applications that use mmap but that do not
- report damage, may be able to work with this enabled.
- Disabled by default because of overhead and other issues.
+ Standard fbdev applications that use mmap but that do not
+ report damage, should be able to work with this enabled.
+ Disable when running with X server that supports reporting
+ changed regions via ioctl, as this method is simpler,
+ more stable, and higher performance.
-console Allow fbcon to attach to udlfb provided framebuffers. This
+console Allow fbcon to attach to udlfb provided framebuffers. This
is disabled by default because fbcon will aggressively consume
the first framebuffer it finds, which isn't usually what the
user wants in the case of USB displays.
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 5a13dc5..5207bd2 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -71,7 +71,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
/* module options */
static int console; /* Optionally allow fbcon to consume first framebuffer */
-static int fb_defio; /* Optionally enable experimental fb_defio mmap support */
+static int fb_defio = 1; /* Detect mmap writes using page faults */
static int shadow = 1; /* Optionally disable shadow framebuffer */
/* dlfb keeps a list of urbs for efficient bulk transfers */
@@ -1961,7 +1961,7 @@ module_param(console, bool, S_IWUSR | S_IRUSR | S_IWGRP | S_IRGRP);
MODULE_PARM_DESC(console, "Allow fbcon to consume first framebuffer found");
module_param(fb_defio, bool, S_IWUSR | S_IRUSR | S_IWGRP | S_IRGRP);
-MODULE_PARM_DESC(fb_defio, "Enable fb_defio mmap support. *Experimental*");
+MODULE_PARM_DESC(fb_defio, "Page fault detection of mmap writes");
module_param(shadow, bool, S_IWUSR | S_IRUSR | S_IWGRP | S_IRGRP);
MODULE_PARM_DESC(shadow, "Shadow vid mem. Disable to save mem but lose perf");
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCHv2 16/28] OMAP3: HWMOD: Add DSS opt clocks
From: Tomi Valkeinen @ 2011-08-02 7:47 UTC (permalink / raw)
To: Paul Walmsley; +Cc: linux-omap, linux-fbdev, b-cousson, khilman
In-Reply-To: <alpine.DEB.2.00.1108011914280.28427@utopia.booyaka.com>
HI,
On Mon, 2011-08-01 at 19:27 -0600, Paul Walmsley wrote:
> Hello Tomi,
>
> On Fri, 15 Jul 2011, Paul Walmsley wrote:
>
> > 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'.
>
> This patch has been updated to remove the temporary hack added to the DSS
> driver. Care to review it before it's sent to Tony?
My hacks (for the OMAP2 case also) use the clocks from the clockdata,
thus fixing the hwmod data won't make the hacks break. So I think it's
cleaner if the HWMOD patches go separately through you, and I'll revert
the hacks in my tree.
But a few comments inline, which I noticed just now.
> - Paul
>
> From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Fri, 15 Jul 2011 00:54:34 -0600
> Subject: [PATCH 2/2] OMAP3: HWMOD: Add DSS opt clocks
>
> Add DSS optional clocks to HWMOD data for OMAP3xxx.
>
> Revert OMAP3 portion of commit
> 9ede365aa6f74428a1f69c21ca1cf21213167576 ("HACK: OMAP: DSS2: clk hack
> for OMAP2/3").
>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> [paul@pwsan.com: remove temporary DSS driver hack; update changelog]
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> ---
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 32 ++++++++++++++++++++++++---
> drivers/video/omap2/dss/dsi.c | 2 +-
> drivers/video/omap2/dss/dss.h | 2 -
> drivers/video/omap2/dss/rfbi.c | 5 +---
> drivers/video/omap2/dss/venc.c | 5 +---
> 5 files changed, 31 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index 25bf43b..38ee033 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -1365,9 +1365,14 @@ static struct omap_hwmod_ocp_if *omap3xxx_dss_slaves[] = {
> };
>
> static struct omap_hwmod_opt_clk dss_opt_clks[] = {
> - { .role = "tv_clk", .clk = "dss_tv_fck" },
> - { .role = "video_clk", .clk = "dss_96m_fck" },
> + /*
> + * The rest of the clocks are not needed by the driver,
> + * but are needed by the hwmod to reset DSS properly.
> + */
I think this wording should be changed, as with the latest hwmod code
changes the dss_core does not use any opt clocks, and these all are just
to make the dss reset work.
Perhaps something like "The DSS HW needs all DSS clocks enabled during
reset. The dss_core driver does not use these clocks."
> { .role = "sys_clk", .clk = "dss2_alwon_fck" },
> + { .role = "tv_clk", .clk = "dss_tv_fck" },
> + /* required only on OMAP3430 */
> + { .role = "tv_dac_clk", .clk = "dss_96m_fck" },
> };
The dss_96m_fck exists only on OMAP3430. What happens when the HWMOD
code tries to reset DSS on OMAP3630, and it first enables all the opt
clocks, and encounters the dss_96m_fck which doesn't exist?
Although, looking at the clock3xxx_data.c, it looks like dss_96m_fck is
there, but I'm not sure what it is controlling. Does the clock exist in
the HW, but it's just not connected to DSS?
The hwmod code should also set HWMOD_CONTROL_OPT_CLKS_IN_RESET for
dss_core, shouldn't it?
> static struct omap_hwmod omap3430es1_dss_core_hwmod = {
> @@ -1504,6 +1509,10 @@ static struct omap_hwmod_ocp_if *omap3xxx_dss_dsi1_slaves[] = {
> &omap3xxx_l4_core__dss_dsi1,
> };
>
> +static struct omap_hwmod_opt_clk dss_dsi1_opt_clks[] = {
> + { .role = "sys_clk", .clk = "dss2_alwon_fck" },
> +};
> +
DSI is missing the interface clock in omap3xxx_l4_core__dss_dsi1. Should
it have .clk = "dss_ick" like the other dss modules?
I can make a new patch with these changes if they look correct to you.
Tomi
^ permalink raw reply
* Re: [PATCHv2 17/28] OMAP2420: HWMOD: Add DSS opt clocks
From: Tomi Valkeinen @ 2011-08-02 7:57 UTC (permalink / raw)
To: Paul Walmsley; +Cc: linux-omap, linux-fbdev, b-cousson, khilman
In-Reply-To: <alpine.DEB.2.00.1108011910410.28427@utopia.booyaka.com>
Hi,
On Mon, 2011-08-01 at 19:14 -0600, Paul Walmsley wrote:
> Hello Tomi
>
> On Fri, 15 Jul 2011, Paul Walmsley wrote:
>
> > On Thu, 9 Jun 2011, Tomi Valkeinen wrote:
> >
> > > Add DSS optional clocks to HWMOD data for OMAP2420.
>
> This patch has been combined with the 2430 patch and the OMAP2xxx portion
> of the temporary hack in the DSS driver has been removed. Care to review
> the new changes before it's sent to Tony?
Same thing here, I can revert the dss hacks separately.
>
> - Paul
>
>
> From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Mon, 1 Aug 2011 19:02:23 -0600
> Subject: [PATCH 1/2] OMAP2xxx: HWMOD: Add DSS opt clocks
>
> Add DSS optional clocks to HWMOD data for OMAP2420 and OMAP2430.
>
> Revert OMAP2xxx portion of commit
> 9ede365aa6f74428a1f69c21ca1cf21213167576 ("HACK: OMAP: DSS2: clk hack
> for OMAP2/3").
>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> [paul@pwsan.com: merge 2420 and 2430 patches; remove temporary DSS driver hack;
> update changelog]
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> ---
> arch/arm/mach-omap2/omap_hwmod_2420_data.c | 17 ++++++++---------
> arch/arm/mach-omap2/omap_hwmod_2430_data.c | 17 ++++++++---------
> drivers/video/omap2/dss/rfbi.c | 2 +-
> 3 files changed, 17 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> index a015c69..b075188 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> @@ -873,11 +873,6 @@ static struct omap_hwmod_ocp_if *omap2420_dss_slaves[] = {
> &omap2420_l4_core__dss,
> };
>
> -static struct omap_hwmod_opt_clk dss_opt_clks[] = {
> - { .role = "tv_clk", .clk = "dss_54m_fck" },
> - { .role = "sys_clk", .clk = "dss2_fck" },
> -};
I removed the opt clocks as the TRM doesn't say that the clocks need to
be enabled when resetting the DSS, but now thinking about it, I feel
it's safer to enable the clocks like we do on OMAP3. I think it's
unlikely that the HW could finish the reset if the clocks are off.
So let's forget this removal of dss opt clocks and add them back. And
also I think HWMOD_CONTROL_OPT_CLKS_IN_RESET is needed for dss_core.
I can make a new patch for this also.
Tomi
^ permalink raw reply
* Re: [PATCH 1/4] fbdev: sh_mobile_meram: Replace hardcoded register
From: Damian Hobson-Garcia @ 2011-08-02 8:43 UTC (permalink / raw)
To: linux-fbdev
Hi Laurent,
> -#define MExxCTL 0x0
> -#define MExxBSIZE 0x4
> -#define MExxMNCF 0x8
> -#define MExxSARA 0x10
> -#define MExxSARB 0x14
> -#define MExxSBSIZE 0x18
[snip]
> +#define MExxCTL 0x400
> +#define MExxBSIZE 0x404
> +#define MExxMNCF 0x408
> +#define MExxSARA 0x410
> +#define MExxSARB 0x414
> +#define MExxSBSIZE 0x418
One small comment on the definition of these register offsets and
explanation of what I was originally thinking. Since each of these
actually reprents a series of registers, one per ICB, (i.e. ME00CTL,
ME01CTL, etc.) it makes sense to me to represent them as an offset from
the base address (0x400) + the start of each ICB address (0x20 * index).
Other than that, looks great.
Thanks very much,
Damian
^ permalink raw reply
* [PATCH] OMAP: DSS2: Don't allow moving managers away from enabled displays
From: Daniel Morsing @ 2011-08-03 20:10 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, Daniel Morsing, linux-fbdev
If a manager is moved while attached to an enabled display, the DSS
system will be left in an inconsistent state. This will eventually cause
a kernel oops when the enabled display is disabled.
Fix this by not allowing the user to move a manager away from an enabled
display.
Signed-off-by: Daniel Morsing <daniel.morsing@gmail.com>
---
drivers/video/omap2/dss/manager.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c
index 9aeea50..d3372d1 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -502,6 +502,13 @@ static int omap_dss_unset_device(struct omap_overlay_manager *mgr)
return -EINVAL;
}
+ /*
+ * Don't allow currently enabled displays to have the overlay manager
+ * pulled out from underneath them
+ */
+ if (mgr->device->state != OMAP_DSS_DISPLAY_DISABLED)
+ return -EINVAL;
+
mgr->device->manager = NULL;
mgr->device = NULL;
mgr->device_changed = true;
--
1.7.6
^ permalink raw reply related
* [PATCH] savagedb: Fix savage4 series video chip detection regression
From: John Stanley @ 2011-08-04 0:41 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, adaplas, Andrew Morton, linux-fbdev
From: John Stanley <jpsinthemix@verizon.net>
savagedb: Fix typo causing regression in savage4 series video chip detection
Two additional savage4 variants were added, but the S3_SAVAGE4_SERIES
macro was incompletely modified, resulting in a false positive detection
of a savage4 card regardless of which savage card is actually present.
For non-savage4 series
cards, such as a Savage/IX-MV card, this results in garbled video and/or
a hard-hang at boot time. Fix this by changing an '||' to an '&&' in the
S3_SAVAGE4_SERIES macro.
Signed-off-by: John P. Stanley <jpsinthemix@verizon.net>
Reviewed-by: Tormod Volden <debian.tormod@gmail.com>
---
Specifically, prior to linux-3.0, there were two savage4 variants
(S3_SAVAGE4 and S3_PROSAVAGE). Hence, S3_SAVAGE4_SERIES was defined as
S3_SAVAGE4 or S3_PROSAVAGE
In linux-3.0, two additional savage4 variants (S3_TWISTER and
S3_PROSAVAGEDDR) have been added. Hence S3_SAVAGE4_SERIES should be
defined as
S3_SAVAGE4, S3_PROSAVAGE, S3_TWISTER, or S3_PROSAVAGEDDR
However, the #define macro for S3_SAVAGE4_SERIES was incompletely
updated: the '||' should have been changed to an '&&'.
--- linux-3.0.0/drivers/video/savage/savagefb.h.orig 2011-07-21
22:17:23.000000000 -0400
+++ linux-3.0.0/drivers/video/savage/savagefb.h 2011-07-31
05:27:47.314798215 -0400
@@ -55,7 +55,7 @@
#define S3_SAVAGE3D_SERIES(chip) ((chip>=S3_SAVAGE3D) &&
(chip<=S3_SAVAGE_MX))
-#define S3_SAVAGE4_SERIES(chip) ((chip>=S3_SAVAGE4) ||
(chip<=S3_PROSAVAGEDDR))
+#define S3_SAVAGE4_SERIES(chip) ((chip>=S3_SAVAGE4) &&
(chip<=S3_PROSAVAGEDDR))
#define S3_SAVAGE_MOBILE_SERIES(chip) ((chip=S3_SAVAGE_MX) ||
(chip=S3_SUPERSAVAGE))
^ 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