* [PATCH] drivers, video: Add a check for strict_strtoul()
From: Liu Yuan @ 2011-04-07 9:06 UTC (permalink / raw)
To: linux-fbdev
From: Liu Yuan <tailai.ly@taobao.com>
It should check if strict_strtoul() succeeds.This
patch fixes it.
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
---
drivers/video/backlight/adp5520_bl.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/video/backlight/adp5520_bl.c b/drivers/video/backlight/adp5520_bl.c
index af31197..fdef632 100644
--- a/drivers/video/backlight/adp5520_bl.c
+++ b/drivers/video/backlight/adp5520_bl.c
@@ -212,7 +212,9 @@ static ssize_t adp5520_bl_daylight_max_store(struct device *dev,
{
struct adp5520_bl *data = dev_get_drvdata(dev);
- strict_strtoul(buf, 10, &data->cached_daylight_max);
+ if (strict_strtoul(buf, 10, &data->cached_daylight_max) < 0)
+ return -EINVAL;
+
return adp5520_store(dev, buf, count, ADP5520_DAYLIGHT_MAX);
}
static DEVICE_ATTR(daylight_max, 0664, adp5520_bl_daylight_max_show,
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] video: imx-fb: just depend on IMX_HAVE_PLATFORM_IMX_FB
From: Baruch Siach @ 2011-04-07 4:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110406184022.GI13963@pengutronix.de>
Hi Uwe,
On Wed, Apr 06, 2011 at 08:40:22PM +0200, Uwe Kleine-König wrote:
> I currently collect imx patches for Sascha because he is busy doing
> other stuff.
Can you take the following one then? I need this to enable multiple NAND chips
on i.MX25.
http://article.gmane.org/gmane.linux.ports.arm.kernel/110313
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{ - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: fix checkpatch errors and warning
From: Tormod Volden @ 2011-04-06 20:13 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1301642247-20926-1-git-send-email-jg1.han@samsung.com>
> On Fri, Apr 01, 2011 at 04:17:27PM +0900, Jingoo Han wrote:
>>
>> Also, following warning is fixed by adding 'platid' variable
>> which can reduce number of lines exceeding 80 characters.
>>
>> WARNING: line over 80 characters
Hi, wouldn't it be better to just break the line somewhere instead of
introducing an extra variable to be used in a single place? Although
the variable will probably be optimized away by the compiler, it adds
unnecessary complexity (and slight confusion) to the code.
Sorry for not commenting on this earlier, I just subscribed to the list.
Best regards,
Tormod
^ permalink raw reply
* Re: [PATCH] video: imx-fb: just depend on IMX_HAVE_PLATFORM_IMX_FB
From: Paul Mundt @ 2011-04-06 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110406184022.GI13963@pengutronix.de>
On Wed, Apr 06, 2011 at 08:40:22PM +0200, Uwe Kleine-K?nig wrote:
> On Thu, Apr 07, 2011 at 01:38:13AM +0900, Paul Mundt wrote:
> > On Wed, Apr 06, 2011 at 04:29:04PM +0200, Uwe Kleine-K??nig wrote:
> > > All machines having a imx-fb device now select IMX_HAVE_PLATFORM_IMX_FB,
> > > so HAVE_FB_IMX can go away and there is no need anymore to explicitly
> > > depend on ARCH_MX1 or ARCH_MX2.
> > >
> > > Signed-off-by: Uwe Kleine-K??nig <u.kleine-koenig@pengutronix.de>
> > > ---
> > > Hello,
> > >
> > > should this go via Sascha's or Paul's tree?
> > >
> > There shouldn't be anything it conflicts with in my tree, so it can go
> > via either. Most of the imx changes have bypassed the fbdev tree, so I'm
> > unaware if there are outstanding patches in Sascha's tree at the moment
> > or not. I can of course take it though.
> I currently collect imx patches for Sascha because he is busy doing
> other stuff. Can I have your ack for the patch that Baruch pointed out?
> Then I'd take it for the imx tree.
>
That's fine for this, but in the future it would be nice to have changes
that impact the fb driver go through the fb tree. In cases like this
where you have clear interdependencies in Kconfig language it obviously
doesn't make much sense to split things up, but it's something to keep in
mind for the things that can be.
Acked-by: Paul Mundt <lethal@linux-sh.org>
^ permalink raw reply
* Re: [PATCH] video: imx-fb: just depend on IMX_HAVE_PLATFORM_IMX_FB
From: @ 2011-04-06 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110406163805.GA11820@linux-sh.org>
On Thu, Apr 07, 2011 at 01:38:13AM +0900, Paul Mundt wrote:
> On Wed, Apr 06, 2011 at 04:29:04PM +0200, Uwe Kleine-K??nig wrote:
> > All machines having a imx-fb device now select IMX_HAVE_PLATFORM_IMX_FB,
> > so HAVE_FB_IMX can go away and there is no need anymore to explicitly
> > depend on ARCH_MX1 or ARCH_MX2.
> >
> > Signed-off-by: Uwe Kleine-K??nig <u.kleine-koenig@pengutronix.de>
> > ---
> > Hello,
> >
> > should this go via Sascha's or Paul's tree?
> >
> There shouldn't be anything it conflicts with in my tree, so it can go
> via either. Most of the imx changes have bypassed the fbdev tree, so I'm
> unaware if there are outstanding patches in Sascha's tree at the moment
> or not. I can of course take it though.
I currently collect imx patches for Sascha because he is busy doing
other stuff. Can I have your ack for the patch that Baruch pointed out?
Then I'd take it for the imx tree.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH] video: imx-fb: just depend on IMX_HAVE_PLATFORM_IMX_FB
From: @ 2011-04-06 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110406173151.GA7592@nataf.siach.name>
On Wed, Apr 06, 2011 at 08:31:51PM +0300, Baruch Siach wrote:
> Hi Uwe,
>
> On Wed, Apr 06, 2011 at 04:29:04PM +0200, Uwe Kleine-König wrote:
> > All machines having a imx-fb device now select IMX_HAVE_PLATFORM_IMX_FB,
> > so HAVE_FB_IMX can go away and there is no need anymore to explicitly
> > depend on ARCH_MX1 or ARCH_MX2.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
>
> Sascha has already sent a patch for this. See
> http://article.gmane.org/gmane.linux.ports.arm.kernel/109067.
yeah, this looks more complete. Thanks for pointing that out.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 1/2] Support overriding fields FW tells us with the DMI data.
From: Paul Mundt @ 2011-04-06 17:59 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1301582030-10607-2-git-send-email-pjones@redhat.com>
On Wed, Apr 06, 2011 at 01:31:03PM -0400, Peter Jones wrote:
> On 04/06/2011 12:42 PM, Paul Mundt wrote:
> >On Thu, Mar 31, 2011 at 10:33:49AM -0400, Peter Jones wrote:
> >>Some machines apparently give us bogus linelength/stride/pitch data, so
> >>we need to support letting the DMI table override the supplied data.
> >>
> >>I bet you can't guess whose machines I'm talking about.
> >>---
> >> drivers/video/efifb.c | 149
> >> +++++++++++++++++++++++++++++--------------------
> >> 1 files changed, 88 insertions(+), 61 deletions(-)
> >>
> >You're missing a signed-off-by here but have one on 2/2, was this
> >intended as an RFC?
>
> No, I meant to include it on each of them. I'll resend with those fixed.
>
Ok, I've applied them now, thanks.
^ permalink raw reply
* [PATCH 2/2] efifb: Add override for 11" Macbook Air 3,1
From: Peter Jones @ 2011-04-06 17:34 UTC (permalink / raw)
To: linux-fbdev
From: Matthew Garrett <mjg@redhat.com>
The 11" Macbook Air appears to claim that its stride is 1366, when it's
actually 2048. Override it.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
---
drivers/video/efifb.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index 2359b64..4eb38db 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -53,6 +53,7 @@ enum {
M_MB_7_1, /* MacBook, 7th rev. */
M_MB_SR, /* MacBook, 2nd gen, (Santa Rosa) */
M_MBA, /* MacBook Air */
+ M_MBA_3, /* Macbook Air, 3rd rev */
M_MBP, /* MacBook Pro */
M_MBP_2, /* MacBook Pro 2nd gen */
M_MBP_2_2, /* MacBook Pro 2,2nd gen */
@@ -97,6 +98,8 @@ static struct efifb_dmi_info {
[M_MB_6_1] = { "macbook61", 0x80010000, 2048 * 4, 1280, 800, OVERRIDE_NONE },
[M_MB_7_1] = { "macbook71", 0x80010000, 2048 * 4, 1280, 800, OVERRIDE_NONE },
[M_MBA] = { "mba", 0x80000000, 2048 * 4, 1280, 800, OVERRIDE_NONE },
+ /* 11" Macbook Air 3,1 passes the wrong stride */
+ [M_MBA_3] = { "mba3", 0, 2048 * 4, 0, 0, OVERRIDE_STRIDE },
[M_MBP] = { "mbp", 0x80010000, 1472 * 4, 1440, 900, OVERRIDE_NONE },
[M_MBP_2] = { "mbp2", 0, 0, 0, 0, OVERRIDE_NONE }, /* placeholder */
[M_MBP_2_2] = { "mbp22", 0x80010000, 1472 * 4, 1440, 900, OVERRIDE_NONE },
@@ -147,6 +150,7 @@ static const struct dmi_system_id dmi_system_table[] __initconst = {
EFIFB_DMI_SYSTEM_ID("Apple Inc.", "MacBook6,1", M_MB_6_1),
EFIFB_DMI_SYSTEM_ID("Apple Inc.", "MacBook7,1", M_MB_7_1),
EFIFB_DMI_SYSTEM_ID("Apple Inc.", "MacBookAir1,1", M_MBA),
+ EFIFB_DMI_SYSTEM_ID("Apple Inc.", "MacBookAir3,1", M_MBA_3),
EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBookPro1,1", M_MBP),
EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBookPro2,1", M_MBP_2),
EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBookPro2,2", M_MBP_2_2),
--
1.7.4
^ permalink raw reply related
* [PATCH 1/2] Support overriding fields FW tells us with the DMI data.
From: Peter Jones @ 2011-04-06 17:34 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1301582030-10607-2-git-send-email-pjones@redhat.com>
Some machines apparently give us bogus linelength/stride/pitch data, so
we need to support letting the DMI table override the supplied data.
I bet you can't guess whose machines I'm talking about.
Signed-off-by: Peter Jones <pjones@redhat.com>
---
drivers/video/efifb.c | 149 +++++++++++++++++++++++++++++--------------------
1 files changed, 88 insertions(+), 61 deletions(-)
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index a9645b8..2359b64 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -68,41 +68,48 @@ enum {
M_UNKNOWN /* placeholder */
};
+#define OVERRIDE_NONE 0x0
+#define OVERRIDE_BASE 0x1
+#define OVERRIDE_STRIDE 0x2
+#define OVERRIDE_HEIGHT 0x4
+#define OVERRIDE_WIDTH 0x8
+
static struct efifb_dmi_info {
char *optname;
unsigned long base;
int stride;
int width;
int height;
+ int flags;
} dmi_list[] __initdata = {
- [M_I17] = { "i17", 0x80010000, 1472 * 4, 1440, 900 },
- [M_I20] = { "i20", 0x80010000, 1728 * 4, 1680, 1050 }, /* guess */
- [M_I20_SR] = { "imac7", 0x40010000, 1728 * 4, 1680, 1050 },
- [M_I24] = { "i24", 0x80010000, 2048 * 4, 1920, 1200 }, /* guess */
- [M_I24_8_1] = { "imac8", 0xc0060000, 2048 * 4, 1920, 1200 },
- [M_I24_10_1] = { "imac10", 0xc0010000, 2048 * 4, 1920, 1080 },
- [M_I27_11_1] = { "imac11", 0xc0010000, 2560 * 4, 2560, 1440 },
- [M_MINI]= { "mini", 0x80000000, 2048 * 4, 1024, 768 },
- [M_MINI_3_1] = { "mini31", 0x40010000, 1024 * 4, 1024, 768 },
- [M_MINI_4_1] = { "mini41", 0xc0010000, 2048 * 4, 1920, 1200 },
- [M_MB] = { "macbook", 0x80000000, 2048 * 4, 1280, 800 },
- [M_MB_5_1] = { "macbook51", 0x80010000, 2048 * 4, 1280, 800 },
- [M_MB_6_1] = { "macbook61", 0x80010000, 2048 * 4, 1280, 800 },
- [M_MB_7_1] = { "macbook71", 0x80010000, 2048 * 4, 1280, 800 },
- [M_MBA] = { "mba", 0x80000000, 2048 * 4, 1280, 800 },
- [M_MBP] = { "mbp", 0x80010000, 1472 * 4, 1440, 900 },
- [M_MBP_2] = { "mbp2", 0, 0, 0, 0 }, /* placeholder */
- [M_MBP_2_2] = { "mbp22", 0x80010000, 1472 * 4, 1440, 900 },
- [M_MBP_SR] = { "mbp3", 0x80030000, 2048 * 4, 1440, 900 },
- [M_MBP_4] = { "mbp4", 0xc0060000, 2048 * 4, 1920, 1200 },
- [M_MBP_5_1] = { "mbp51", 0xc0010000, 2048 * 4, 1440, 900 },
- [M_MBP_5_2] = { "mbp52", 0xc0010000, 2048 * 4, 1920, 1200 },
- [M_MBP_5_3] = { "mbp53", 0xd0010000, 2048 * 4, 1440, 900 },
- [M_MBP_6_1] = { "mbp61", 0x90030000, 2048 * 4, 1920, 1200 },
- [M_MBP_6_2] = { "mbp62", 0x90030000, 2048 * 4, 1680, 1050 },
- [M_MBP_7_1] = { "mbp71", 0xc0010000, 2048 * 4, 1280, 800 },
- [M_MBP_8_2] = { "mbp82", 0x90010000, 1472 * 4, 1440, 900 },
- [M_UNKNOWN] = { NULL, 0, 0, 0, 0 }
+ [M_I17] = { "i17", 0x80010000, 1472 * 4, 1440, 900, OVERRIDE_NONE },
+ [M_I20] = { "i20", 0x80010000, 1728 * 4, 1680, 1050, OVERRIDE_NONE }, /* guess */
+ [M_I20_SR] = { "imac7", 0x40010000, 1728 * 4, 1680, 1050, OVERRIDE_NONE },
+ [M_I24] = { "i24", 0x80010000, 2048 * 4, 1920, 1200, OVERRIDE_NONE }, /* guess */
+ [M_I24_8_1] = { "imac8", 0xc0060000, 2048 * 4, 1920, 1200, OVERRIDE_NONE },
+ [M_I24_10_1] = { "imac10", 0xc0010000, 2048 * 4, 1920, 1080, OVERRIDE_NONE },
+ [M_I27_11_1] = { "imac11", 0xc0010000, 2560 * 4, 2560, 1440, OVERRIDE_NONE },
+ [M_MINI]= { "mini", 0x80000000, 2048 * 4, 1024, 768, OVERRIDE_NONE },
+ [M_MINI_3_1] = { "mini31", 0x40010000, 1024 * 4, 1024, 768, OVERRIDE_NONE },
+ [M_MINI_4_1] = { "mini41", 0xc0010000, 2048 * 4, 1920, 1200, OVERRIDE_NONE },
+ [M_MB] = { "macbook", 0x80000000, 2048 * 4, 1280, 800, OVERRIDE_NONE },
+ [M_MB_5_1] = { "macbook51", 0x80010000, 2048 * 4, 1280, 800, OVERRIDE_NONE },
+ [M_MB_6_1] = { "macbook61", 0x80010000, 2048 * 4, 1280, 800, OVERRIDE_NONE },
+ [M_MB_7_1] = { "macbook71", 0x80010000, 2048 * 4, 1280, 800, OVERRIDE_NONE },
+ [M_MBA] = { "mba", 0x80000000, 2048 * 4, 1280, 800, OVERRIDE_NONE },
+ [M_MBP] = { "mbp", 0x80010000, 1472 * 4, 1440, 900, OVERRIDE_NONE },
+ [M_MBP_2] = { "mbp2", 0, 0, 0, 0, OVERRIDE_NONE }, /* placeholder */
+ [M_MBP_2_2] = { "mbp22", 0x80010000, 1472 * 4, 1440, 900, OVERRIDE_NONE },
+ [M_MBP_SR] = { "mbp3", 0x80030000, 2048 * 4, 1440, 900, OVERRIDE_NONE },
+ [M_MBP_4] = { "mbp4", 0xc0060000, 2048 * 4, 1920, 1200, OVERRIDE_NONE },
+ [M_MBP_5_1] = { "mbp51", 0xc0010000, 2048 * 4, 1440, 900, OVERRIDE_NONE },
+ [M_MBP_5_2] = { "mbp52", 0xc0010000, 2048 * 4, 1920, 1200, OVERRIDE_NONE },
+ [M_MBP_5_3] = { "mbp53", 0xd0010000, 2048 * 4, 1440, 900, OVERRIDE_NONE },
+ [M_MBP_6_1] = { "mbp61", 0x90030000, 2048 * 4, 1920, 1200, OVERRIDE_NONE },
+ [M_MBP_6_2] = { "mbp62", 0x90030000, 2048 * 4, 1680, 1050, OVERRIDE_NONE },
+ [M_MBP_7_1] = { "mbp71", 0xc0010000, 2048 * 4, 1280, 800, OVERRIDE_NONE },
+ [M_MBP_8_2] = { "mbp82", 0x90010000, 1472 * 4, 1440, 900, OVERRIDE_NONE },
+ [M_UNKNOWN] = { NULL, 0, 0, 0, 0, OVERRIDE_NONE }
};
static int set_system(const struct dmi_system_id *id);
@@ -157,16 +164,22 @@ static const struct dmi_system_id dmi_system_table[] __initconst = {
{},
};
+#define choose_value(dmivalue, fwvalue, field, flags) ({ \
+ typeof(fwvalue) _ret_ = fwvalue; \
+ if ((flags) & (field)) \
+ _ret_ = dmivalue; \
+ else if ((fwvalue) = 0) \
+ _ret_ = dmivalue; \
+ _ret_; \
+ })
+
static int set_system(const struct dmi_system_id *id)
{
struct efifb_dmi_info *info = id->driver_data;
- if (info->base = 0)
- return 0;
- printk(KERN_INFO "efifb: dmi detected %s - framebuffer at %p "
- "(%dx%d, stride %d)\n", id->ident,
- (void *)info->base, info->width, info->height,
- info->stride);
+ if (info->base = 0 && info->height = 0 && info->width = 0
+ && info->stride = 0)
+ return 0;
/* Trust the bootloader over the DMI tables */
if (screen_info.lfb_base = 0) {
@@ -174,40 +187,47 @@ static int set_system(const struct dmi_system_id *id)
struct pci_dev *dev = NULL;
int found_bar = 0;
#endif
- screen_info.lfb_base = info->base;
+ if (info->base) {
+ screen_info.lfb_base = choose_value(info->base,
+ screen_info.lfb_base, OVERRIDE_BASE,
+ info->flags);
#if defined(CONFIG_PCI)
- /* make sure that the address in the table is actually on a
- * VGA device's PCI BAR */
-
- for_each_pci_dev(dev) {
- int i;
- if ((dev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
- continue;
- for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
- resource_size_t start, end;
-
- start = pci_resource_start(dev, i);
- if (start = 0)
- break;
- end = pci_resource_end(dev, i);
- if (screen_info.lfb_base >= start &&
- screen_info.lfb_base < end) {
- found_bar = 1;
+ /* make sure that the address in the table is actually
+ * on a VGA device's PCI BAR */
+
+ for_each_pci_dev(dev) {
+ int i;
+ if ((dev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
+ continue;
+ for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+ resource_size_t start, end;
+
+ start = pci_resource_start(dev, i);
+ if (start = 0)
+ break;
+ end = pci_resource_end(dev, i);
+ if (screen_info.lfb_base >= start &&
+ screen_info.lfb_base < end) {
+ found_bar = 1;
+ }
}
}
- }
- if (!found_bar)
- screen_info.lfb_base = 0;
+ if (!found_bar)
+ screen_info.lfb_base = 0;
#endif
+ }
}
if (screen_info.lfb_base) {
- if (screen_info.lfb_linelength = 0)
- screen_info.lfb_linelength = info->stride;
- if (screen_info.lfb_width = 0)
- screen_info.lfb_width = info->width;
- if (screen_info.lfb_height = 0)
- screen_info.lfb_height = info->height;
+ screen_info.lfb_linelength = choose_value(info->stride,
+ screen_info.lfb_linelength, OVERRIDE_STRIDE,
+ info->flags);
+ screen_info.lfb_width = choose_value(info->width,
+ screen_info.lfb_width, OVERRIDE_WIDTH,
+ info->flags);
+ screen_info.lfb_height = choose_value(info->height,
+ screen_info.lfb_height, OVERRIDE_HEIGHT,
+ info->flags);
if (screen_info.orig_video_isVGA = 0)
screen_info.orig_video_isVGA = VIDEO_TYPE_EFI;
} else {
@@ -217,6 +237,13 @@ static int set_system(const struct dmi_system_id *id)
screen_info.orig_video_isVGA = 0;
return 0;
}
+
+ printk(KERN_INFO "efifb: dmi detected %s - framebuffer at %p "
+ "(%dx%d, stride %d)\n", id->ident,
+ (void *)screen_info.lfb_base, screen_info.lfb_width,
+ screen_info.lfb_height, screen_info.lfb_linelength);
+
+
return 1;
}
--
1.7.4
^ permalink raw reply related
* Re: [PATCH] video: imx-fb: just depend on IMX_HAVE_PLATFORM_IMX_FB
From: Baruch Siach @ 2011-04-06 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1302100144-17176-1-git-send-email-u.kleine-koenig@pengutronix.de>
Hi Uwe,
On Wed, Apr 06, 2011 at 04:29:04PM +0200, Uwe Kleine-König wrote:
> All machines having a imx-fb device now select IMX_HAVE_PLATFORM_IMX_FB,
> so HAVE_FB_IMX can go away and there is no need anymore to explicitly
> depend on ARCH_MX1 or ARCH_MX2.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
Sascha has already sent a patch for this. See
http://article.gmane.org/gmane.linux.ports.arm.kernel/109067.
baruch
> Hello,
>
> should this go via Sascha's or Paul's tree?
>
> Best regards
> Uwe
>
> arch/arm/plat-mxc/devices/Kconfig | 1 -
> drivers/video/Kconfig | 5 +----
> 2 files changed, 1 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/plat-mxc/devices/Kconfig b/arch/arm/plat-mxc/devices/Kconfig
> index b9ab1d5..e4dcf49 100644
> --- a/arch/arm/plat-mxc/devices/Kconfig
> +++ b/arch/arm/plat-mxc/devices/Kconfig
> @@ -24,7 +24,6 @@ config IMX_HAVE_PLATFORM_IMXDI_RTC
>
> config IMX_HAVE_PLATFORM_IMX_FB
> bool
> - select HAVE_FB_IMX
>
> config IMX_HAVE_PLATFORM_IMX_I2C
> bool
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index e6a8d8c..62f337a 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -8,9 +8,6 @@ menu "Graphics support"
> config HAVE_FB_ATMEL
> bool
>
> -config HAVE_FB_IMX
> - bool
> -
> config SH_MIPI_DSI
> tristate
> depends on (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
> @@ -359,7 +356,7 @@ config FB_SA1100
>
> config FB_IMX
> tristate "Freescale i.MX LCD support"
> - depends on FB && (HAVE_FB_IMX || ARCH_MX1 || ARCH_MX2)
> + depends on FB && IMX_HAVE_PLATFORM_IMX_FB
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> --
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{ - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH 1/2] Support overriding fields FW tells us with the DMI
From: Peter Jones @ 2011-04-06 17:31 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1301582030-10607-2-git-send-email-pjones@redhat.com>
On 04/06/2011 12:42 PM, Paul Mundt wrote:
> On Thu, Mar 31, 2011 at 10:33:49AM -0400, Peter Jones wrote:
>> Some machines apparently give us bogus linelength/stride/pitch data, so
>> we need to support letting the DMI table override the supplied data.
>>
>> I bet you can't guess whose machines I'm talking about.
>> ---
>> drivers/video/efifb.c | 149 +++++++++++++++++++++++++++++--------------------
>> 1 files changed, 88 insertions(+), 61 deletions(-)
>>
> You're missing a signed-off-by here but have one on 2/2, was this
> intended as an RFC?
No, I meant to include it on each of them. I'll resend with those fixed.
--
Peter
^ permalink raw reply
* Re: [PATCH] fb: Reduce priority of resource conflict message
From: Paul Mundt @ 2011-04-06 17:05 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1301953194-6706-1-git-send-email-mjg@redhat.com>
On Wed, Apr 06, 2011 at 10:50:04AM +1000, Dave Airlie wrote:
> On Tue, Apr 5, 2011 at 7:39 AM, Matthew Garrett <mjg@redhat.com> wrote:
> > It's expected that efifb will conflict with a native driver, so the
> > handover message should be informational rather than an error.
> >
> > Signed-off-by: Matthew Garrett <mjg@redhat.com>
>
> Acked-by: Dave Airlie <airlied@redhat.com>
>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3] s3fb: add DDC support
From: Paul Mundt @ 2011-04-06 17:01 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Ondrej Zajicek, linux-fbdev, Kernel development list
In-Reply-To: <201104041125.36404.linux@rainbow-software.org>
On Mon, Apr 04, 2011 at 11:25:36AM +0200, Ondrej Zary wrote:
> On Monday 04 April 2011, Paul Mundt wrote:
> > On Mon, Apr 04, 2011 at 10:33:16AM +0200, Ondrej Zajicek wrote:
> > > On Sun, Apr 03, 2011 at 10:36:15PM +0200, Ondrej Zary wrote:
> > > > Add I2C support for the DDC bus and also default mode initialization by
> > > > reading monitor EDID to the s3fb driver.
> > > >
> > > > Tested on Trio64V+ (2 cards), Trio64V2/DX, Virge (3 cards),
> > > > Virge/DX (3 cards), Virge/GX2, Trio3D/2X (4 cards), Trio3D.
> > > >
> > > > Will probably not work on Trio32 - my 2 cards have DDC support in BIOS
> > > > that looks different from the other cards but the DDC pins on the VGA
> > > > connector are not connected.
> > > >
> > > > Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
> > >
> > > Acked-by: Ondrej Zajicek <santiago@crfreenet.org>
> >
> > Is there much reason to leave this optional? Or are you simply waiting
> > for testing feedback from Trio32 users before default-enabling it?
> >
> > It would generally be nice to avoid these sorts of config options for a
> > specific driver if it already is quite capable of handling the
> > unsupported cases and has a reasonable fallback on defaults via the error
> > path.
>
> If the config option is not desired, I'll remove it, I don't like it either.
> Just did it like some other fb drivers do. The only reason why someone would
> want to disable DDC is probably to have I2C-less kernel.
>
Oh, that's right, i2c is one of those pain in the ass subsystems that
refuses to provide a stubbed implementation of the API for i2c disabled
systems. Lets just stick with the first version for now.
^ permalink raw reply
* Re: [PATCH 1/2] savagefb: Replace magic register address with define
From: Paul Mundt @ 2011-04-06 16:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1301835246-6520-1-git-send-email-lists.tormod@gmail.com>
On Sun, Apr 03, 2011 at 02:54:04PM +0200, Tormod Volden wrote:
> MM_SERIAL1 was already defined, but not used.
>
> Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
On Sun, Apr 03, 2011 at 02:54:05PM +0200, Tormod Volden wrote:
> In practice this means enabling I2C (for DDC2) on all prosavage cards,
> like the xorg ddx does. The savage4 and savage2000 families have only
> one member each, so there is no change for those.
>
> Tested on TwisterK.
>
> Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
On Sun, Apr 03, 2011 at 02:54:06PM +0200, Tormod Volden wrote:
> The else clause was not needed after the cleanup in commit
> b8901b091db260b0f0101d6395ce5c6016835a47
>
> Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
These all look fine. All applied, thanks.
^ permalink raw reply
* Re: [PATCH 6/6] drivers/video/bfin-lq035q1-fb.c: introduce missing kfree
From: Paul Mundt @ 2011-04-06 16:46 UTC (permalink / raw)
To: Mike Frysinger; +Cc: Julia Lawall, kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <BANLkTinF-Z_1J8UiPJ0wnaDLxgHRv0MsPw@mail.gmail.com>
On Sat, Apr 02, 2011 at 01:05:57AM -0400, Mike Frysinger wrote:
> On Fri, Apr 1, 2011 at 10:23, Julia Lawall wrote:
> > Error handling code following a kmalloc should free the allocated data.
>
> Acked-by: Mike Frysinger <vapier@gentoo.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: fix checkpatch errors and warning
From: Paul Mundt @ 2011-04-06 16:45 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1301642247-20926-1-git-send-email-jg1.han@samsung.com>
On Fri, Apr 01, 2011 at 04:17:27PM +0900, Jingoo Han wrote:
> This patch fixes the checkpatch errors listed below:
>
> ERROR: space required before the open parenthesis '('
> ERROR: need consistent spacing around '+' (ctx:WxV)
> ERROR: space prohibited before that close parenthesis ')'
>
> Also, following warning is fixed by adding 'platid' variable
> which can reduce number of lines exceeding 80 characters.
>
> WARNING: line over 80 characters
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] Support overriding fields FW tells us with the DMI data.
From: Paul Mundt @ 2011-04-06 16:42 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1301582030-10607-2-git-send-email-pjones@redhat.com>
On Thu, Mar 31, 2011 at 10:33:49AM -0400, Peter Jones wrote:
> Some machines apparently give us bogus linelength/stride/pitch data, so
> we need to support letting the DMI table override the supplied data.
>
> I bet you can't guess whose machines I'm talking about.
> ---
> drivers/video/efifb.c | 149 +++++++++++++++++++++++++++++--------------------
> 1 files changed, 88 insertions(+), 61 deletions(-)
>
You're missing a signed-off-by here but have one on 2/2, was this
intended as an RFC?
^ permalink raw reply
* Re: [PATCH] video: imx-fb: just depend on IMX_HAVE_PLATFORM_IMX_FB
From: Paul Mundt @ 2011-04-06 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1302100144-17176-1-git-send-email-u.kleine-koenig@pengutronix.de>
On Wed, Apr 06, 2011 at 04:29:04PM +0200, Uwe Kleine-K??nig wrote:
> All machines having a imx-fb device now select IMX_HAVE_PLATFORM_IMX_FB,
> so HAVE_FB_IMX can go away and there is no need anymore to explicitly
> depend on ARCH_MX1 or ARCH_MX2.
>
> Signed-off-by: Uwe Kleine-K??nig <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> should this go via Sascha's or Paul's tree?
>
There shouldn't be anything it conflicts with in my tree, so it can go
via either. Most of the imx changes have bypassed the fbdev tree, so I'm
unaware if there are outstanding patches in Sascha's tree at the moment
or not. I can of course take it though.
^ permalink raw reply
* [PATCH] video: imx-fb: just depend on IMX_HAVE_PLATFORM_IMX_FB
From: @ 2011-04-06 14:29 UTC (permalink / raw)
To: linux-arm-kernel
All machines having a imx-fb device now select IMX_HAVE_PLATFORM_IMX_FB,
so HAVE_FB_IMX can go away and there is no need anymore to explicitly
depend on ARCH_MX1 or ARCH_MX2.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,
should this go via Sascha's or Paul's tree?
Best regards
Uwe
arch/arm/plat-mxc/devices/Kconfig | 1 -
drivers/video/Kconfig | 5 +----
2 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-mxc/devices/Kconfig b/arch/arm/plat-mxc/devices/Kconfig
index b9ab1d5..e4dcf49 100644
--- a/arch/arm/plat-mxc/devices/Kconfig
+++ b/arch/arm/plat-mxc/devices/Kconfig
@@ -24,7 +24,6 @@ config IMX_HAVE_PLATFORM_IMXDI_RTC
config IMX_HAVE_PLATFORM_IMX_FB
bool
- select HAVE_FB_IMX
config IMX_HAVE_PLATFORM_IMX_I2C
bool
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index e6a8d8c..62f337a 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -8,9 +8,6 @@ menu "Graphics support"
config HAVE_FB_ATMEL
bool
-config HAVE_FB_IMX
- bool
-
config SH_MIPI_DSI
tristate
depends on (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
@@ -359,7 +356,7 @@ config FB_SA1100
config FB_IMX
tristate "Freescale i.MX LCD support"
- depends on FB && (HAVE_FB_IMX || ARCH_MX1 || ARCH_MX2)
+ depends on FB && IMX_HAVE_PLATFORM_IMX_FB
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] fb: Reduce priority of resource conflict message
From: Dave Airlie @ 2011-04-06 0:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1301953194-6706-1-git-send-email-mjg@redhat.com>
On Tue, Apr 5, 2011 at 7:39 AM, Matthew Garrett <mjg@redhat.com> wrote:
> It's expected that efifb will conflict with a native driver, so the
> handover message should be informational rather than an error.
>
> Signed-off-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Dave.
> ---
> drivers/video/fbmem.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index e2bf953..e0c2284 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1507,7 +1507,7 @@ void remove_conflicting_framebuffers(struct apertures_struct *a,
> (primary && gen_aper && gen_aper->count &&
> gen_aper->ranges[0].base = VGA_FB_PHYS)) {
>
> - printk(KERN_ERR "fb: conflicting fb hw usage "
> + printk(KERN_INFO "fb: conflicting fb hw usage "
> "%s vs %s - removing generic driver\n",
> name, registered_fb[i]->fix.id);
> unregister_framebuffer(registered_fb[i]);
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] udlfb.c dlfb_ops_ioctl - missing copy_from_user's - NEEDS
From: Dr. David Alan Gilbert @ 2011-04-05 0:02 UTC (permalink / raw)
To: linux-fbdev
Fix __user casting in dlfb_ops_ioctl and a missing copy_from_user, and a missing &
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
---
NOTE! I don't have the hardware to test this; but Bernie suggested I put the
patch together anyway; build and Sparse tested only -** don't **
merge without a test by a udl dev
Patch is against ecb78ab6f30106ab72a575a25b1cdfd1633b7ca2 on Linus's tree
a few days after 39-rc1
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 2c8364e..ef7801a 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -751,14 +751,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;
@@ -766,6 +765,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"
@@ -777,21 +781,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);
}
@@ -839,7 +841,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 */
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ gro.gilbert @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply related
* [PATCH] fb: Reduce priority of resource conflict message
From: Matthew Garrett @ 2011-04-04 21:39 UTC (permalink / raw)
To: linux-fbdev
It's expected that efifb will conflict with a native driver, so the
handover message should be informational rather than an error.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
drivers/video/fbmem.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index e2bf953..e0c2284 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1507,7 +1507,7 @@ void remove_conflicting_framebuffers(struct apertures_struct *a,
(primary && gen_aper && gen_aper->count &&
gen_aper->ranges[0].base = VGA_FB_PHYS)) {
- printk(KERN_ERR "fb: conflicting fb hw usage "
+ printk(KERN_INFO "fb: conflicting fb hw usage "
"%s vs %s - removing generic driver\n",
name, registered_fb[i]->fix.id);
unregister_framebuffer(registered_fb[i]);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH v3] s3fb: add DDC support
From: Ondrej Zary @ 2011-04-04 20:44 UTC (permalink / raw)
To: Paul Mundt; +Cc: Ondrej Zajicek, linux-fbdev, Kernel development list
In-Reply-To: <20110404084200.GD28208@linux-sh.org>
Add I2C support for the DDC bus and also default mode initialization by
reading monitor EDID to the s3fb driver.
Tested on Trio64V+ (2 cards), Trio64V2/DX, Virge (3 cards),
Virge/DX (3 cards), Virge/GX2, Trio3D/2X (4 cards), Trio3D.
Will probably not work on Trio32 - my 2 cards have DDC support in BIOS that
looks different from the other cards but the DDC pins on the VGA connector
are not connected.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
This is the CONFIG-less version.
--- linux-2.6.38-rc4-/drivers/video/s3fb.c 2011-03-31 20:57:57.000000000 +0200
+++ linux-2.6.38-rc4/drivers/video/s3fb.c 2011-04-04 22:22:11.000000000 +0200
@@ -25,6 +25,10 @@
#include <linux/console.h> /* Why should fb driver call console functions? because console_lock() */
#include <video/vga.h>
+#include <linux/i2c.h>
+#include <linux/i2c-id.h>
+#include <linux/i2c-algo-bit.h>
+
#ifdef CONFIG_MTRR
#include <asm/mtrr.h>
#endif
@@ -36,6 +40,10 @@ struct s3fb_info {
struct mutex open_lock;
unsigned int ref_count;
u32 pseudo_palette[16];
+ u8 __iomem *mmio;
+ bool ddc_registered;
+ struct i2c_adapter ddc_adapter;
+ struct i2c_algo_bit_data ddc_algo;
};
@@ -105,6 +113,9 @@ static const char * const s3_names[] = {
#define CHIP_UNDECIDED_FLAG 0x80
#define CHIP_MASK 0xFF
+#define MMIO_OFFSET 0x1000000
+#define MMIO_SIZE 0x10000
+
/* CRT timing register sets */
static const struct vga_regset s3_h_total_regs[] = {{0x00, 0, 7}, {0x5D, 0, 0}, VGA_REGSET_END};
@@ -140,7 +151,7 @@ static const struct svga_timing_regs s3_
/* Module parameters */
-static char *mode_option __devinitdata = "640x480-8@60";
+static char *mode_option __devinitdata;
#ifdef CONFIG_MTRR
static int mtrr __devinitdata = 1;
@@ -169,6 +180,116 @@ MODULE_PARM_DESC(fasttext, "Enable S3 fa
/* ------------------------------------------------------------------------- */
+#define DDC_REG 0xaa /* Trio 3D/1X/2X */
+#define DDC_MMIO_REG 0xff20 /* all other chips */
+#define DDC_SCL_OUT (1 << 0)
+#define DDC_SDA_OUT (1 << 1)
+#define DDC_SCL_IN (1 << 2)
+#define DDC_SDA_IN (1 << 3)
+#define DDC_DRIVE_EN (1 << 4)
+
+static bool s3fb_ddc_needs_mmio(int chip)
+{
+ return !(chip = CHIP_360_TRIO3D_1X ||
+ chip = CHIP_362_TRIO3D_2X ||
+ chip = CHIP_368_TRIO3D_2X);
+}
+
+static u8 s3fb_ddc_read(struct s3fb_info *par)
+{
+ if (s3fb_ddc_needs_mmio(par->chip))
+ return readb(par->mmio + DDC_MMIO_REG);
+ else
+ return vga_rcrt(par->state.vgabase, DDC_REG);
+}
+
+static void s3fb_ddc_write(struct s3fb_info *par, u8 val)
+{
+ if (s3fb_ddc_needs_mmio(par->chip))
+ writeb(val, par->mmio + DDC_MMIO_REG);
+ else
+ vga_wcrt(par->state.vgabase, DDC_REG, val);
+}
+
+static void s3fb_ddc_setscl(void *data, int val)
+{
+ struct s3fb_info *par = data;
+ unsigned char reg;
+
+ reg = s3fb_ddc_read(par) | DDC_DRIVE_EN;
+ if (val)
+ reg |= DDC_SCL_OUT;
+ else
+ reg &= ~DDC_SCL_OUT;
+ s3fb_ddc_write(par, reg);
+}
+
+static void s3fb_ddc_setsda(void *data, int val)
+{
+ struct s3fb_info *par = data;
+ unsigned char reg;
+
+ reg = s3fb_ddc_read(par) | DDC_DRIVE_EN;
+ if (val)
+ reg |= DDC_SDA_OUT;
+ else
+ reg &= ~DDC_SDA_OUT;
+ s3fb_ddc_write(par, reg);
+}
+
+static int s3fb_ddc_getscl(void *data)
+{
+ struct s3fb_info *par = data;
+
+ return !!(s3fb_ddc_read(par) & DDC_SCL_IN);
+}
+
+static int s3fb_ddc_getsda(void *data)
+{
+ struct s3fb_info *par = data;
+
+ return !!(s3fb_ddc_read(par) & DDC_SDA_IN);
+}
+
+static int __devinit s3fb_setup_ddc_bus(struct fb_info *info)
+{
+ struct s3fb_info *par = info->par;
+
+ strlcpy(par->ddc_adapter.name, info->fix.id,
+ sizeof(par->ddc_adapter.name));
+ par->ddc_adapter.owner = THIS_MODULE;
+ par->ddc_adapter.class = I2C_CLASS_DDC;
+ par->ddc_adapter.algo_data = &par->ddc_algo;
+ par->ddc_adapter.dev.parent = info->device;
+ par->ddc_algo.setsda = s3fb_ddc_setsda;
+ par->ddc_algo.setscl = s3fb_ddc_setscl;
+ par->ddc_algo.getsda = s3fb_ddc_getsda;
+ par->ddc_algo.getscl = s3fb_ddc_getscl;
+ par->ddc_algo.udelay = 10;
+ par->ddc_algo.timeout = 20;
+ par->ddc_algo.data = par;
+
+ i2c_set_adapdata(&par->ddc_adapter, par);
+
+ /*
+ * some Virge cards have external MUX to switch chip I2C bus between
+ * DDC and extension pins - switch it do DDC
+ */
+/* vga_wseq(par->state.vgabase, 0x08, 0x06); - not needed, already unlocked */
+ if (par->chip = CHIP_357_VIRGE_GX2 ||
+ par->chip = CHIP_359_VIRGE_GX2P)
+ svga_wseq_mask(par->state.vgabase, 0x0d, 0x01, 0x03);
+ else
+ svga_wseq_mask(par->state.vgabase, 0x0d, 0x00, 0x03);
+ /* some Virge need this or the DDC is ignored */
+ svga_wcrt_mask(par->state.vgabase, 0x5c, 0x03, 0x03);
+
+ return i2c_bit_add_bus(&par->ddc_adapter);
+}
+
+
+/* ------------------------------------------------------------------------- */
+
/* Set font in S3 fast text mode */
static void s3fb_settile_fast(struct fb_info *info, struct fb_tilemap *map)
@@ -994,6 +1115,7 @@ static int __devinit s3_pci_probe(struct
struct s3fb_info *par;
int rc;
u8 regval, cr38, cr39;
+ bool found = false;
/* Ignore secondary VGA device because there is no VGA arbitration */
if (! svga_primary_device(dev)) {
@@ -1117,15 +1239,63 @@ static int __devinit s3_pci_probe(struct
info->fix.ypanstep = 0;
info->fix.accel = FB_ACCEL_NONE;
info->pseudo_palette = (void*) (par->pseudo_palette);
+ info->var.bits_per_pixel = 8;
+
+ /* Enable MMIO if needed */
+ if (s3fb_ddc_needs_mmio(par->chip)) {
+ par->mmio = ioremap(info->fix.smem_start + MMIO_OFFSET, MMIO_SIZE);
+ if (par->mmio)
+ svga_wcrt_mask(par->state.vgabase, 0x53, 0x08, 0x08); /* enable MMIO */
+ else
+ dev_err(info->device, "unable to map MMIO at 0x%lx, disabling DDC",
+ info->fix.smem_start + MMIO_OFFSET);
+ }
+ if (!s3fb_ddc_needs_mmio(par->chip) || par->mmio)
+ if (s3fb_setup_ddc_bus(info) = 0) {
+ u8 *edid = fb_ddc_read(&par->ddc_adapter);
+ par->ddc_registered = true;
+ if (edid) {
+ fb_edid_to_monspecs(edid, &info->monspecs);
+ kfree(edid);
+ if (!info->monspecs.modedb)
+ dev_err(info->device, "error getting mode database\n");
+ else {
+ const struct fb_videomode *m;
+
+ fb_videomode_to_modelist(info->monspecs.modedb,
+ info->monspecs.modedb_len,
+ &info->modelist);
+ m = fb_find_best_display(&info->monspecs, &info->modelist);
+ if (m) {
+ fb_videomode_to_var(&info->var, m);
+ /* fill all other info->var's fields */
+ if (s3fb_check_var(&info->var, info) = 0)
+ found = true;
+ }
+ }
+ }
+ }
+
+ if (!mode_option && !found)
+ mode_option = "640x480-8@60";
/* Prepare startup mode */
- rc = fb_find_mode(&(info->var), info, mode_option, NULL, 0, NULL, 8);
- if (! ((rc = 1) || (rc = 2))) {
- rc = -EINVAL;
- dev_err(info->device, "mode %s not found\n", mode_option);
- goto err_find_mode;
+ if (mode_option) {
+ rc = fb_find_mode(&info->var, info, mode_option,
+ info->monspecs.modedb, info->monspecs.modedb_len,
+ NULL, info->var.bits_per_pixel);
+ if (!rc || rc = 4) {
+ rc = -EINVAL;
+ dev_err(info->device, "mode %s not found\n", mode_option);
+ fb_destroy_modedb(info->monspecs.modedb);
+ info->monspecs.modedb = NULL;
+ goto err_find_mode;
+ }
}
+ fb_destroy_modedb(info->monspecs.modedb);
+ info->monspecs.modedb = NULL;
+
/* maximize virtual vertical size for fast scrolling */
info->var.yres_virtual = info->fix.smem_len * 8 /
(info->var.bits_per_pixel * info->var.xres_virtual);
@@ -1171,6 +1341,10 @@ err_reg_fb:
fb_dealloc_cmap(&info->cmap);
err_alloc_cmap:
err_find_mode:
+ if (par->ddc_registered)
+ i2c_del_adapter(&par->ddc_adapter);
+ if (par->mmio)
+ iounmap(par->mmio);
pci_iounmap(dev, info->screen_base);
err_iomap:
pci_release_regions(dev);
@@ -1202,6 +1376,11 @@ static void __devexit s3_pci_remove(stru
unregister_framebuffer(info);
fb_dealloc_cmap(&info->cmap);
+ if (par->ddc_registered)
+ i2c_del_adapter(&par->ddc_adapter);
+ if (par->mmio)
+ iounmap(par->mmio);
+
pci_iounmap(dev, info->screen_base);
pci_release_regions(dev);
/* pci_disable_device(dev); */
--
Ondrej Zary
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Alan Cox @ 2011-04-04 9:40 UTC (permalink / raw)
To: Matt Turner
Cc: Fbdev development list, dri-devel, wayland-devel,
Geert Uytterhoeven, Linux, timofonic timofonic
In-Reply-To: <AANLkTikAQ1ZLy6aoCPSQdJ8F9-D172uypff+-4+_WXPz@mail.gmail.com>
> It's nothing fantastic, but I've had a number of people tell me that
> it was useful for them.
It does document some stuff nicely - not alas the bits I need to figure
out at the moment but its definitely a nice reference to the basic setup.
(ponders Voodoo2 DRI)
^ permalink raw reply
* Re: [PATCH v3] s3fb: add DDC support
From: Ondrej Zary @ 2011-04-04 9:25 UTC (permalink / raw)
To: Paul Mundt; +Cc: Ondrej Zajicek, linux-fbdev, Kernel development list
In-Reply-To: <20110404084200.GD28208@linux-sh.org>
On Monday 04 April 2011, Paul Mundt wrote:
> On Mon, Apr 04, 2011 at 10:33:16AM +0200, Ondrej Zajicek wrote:
> > On Sun, Apr 03, 2011 at 10:36:15PM +0200, Ondrej Zary wrote:
> > > Add I2C support for the DDC bus and also default mode initialization by
> > > reading monitor EDID to the s3fb driver.
> > >
> > > Tested on Trio64V+ (2 cards), Trio64V2/DX, Virge (3 cards),
> > > Virge/DX (3 cards), Virge/GX2, Trio3D/2X (4 cards), Trio3D.
> > >
> > > Will probably not work on Trio32 - my 2 cards have DDC support in BIOS
> > > that looks different from the other cards but the DDC pins on the VGA
> > > connector are not connected.
> > >
> > > Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
> >
> > Acked-by: Ondrej Zajicek <santiago@crfreenet.org>
>
> Is there much reason to leave this optional? Or are you simply waiting
> for testing feedback from Trio32 users before default-enabling it?
>
> It would generally be nice to avoid these sorts of config options for a
> specific driver if it already is quite capable of handling the
> unsupported cases and has a reasonable fallback on defaults via the error
> path.
If the config option is not desired, I'll remove it, I don't like it either.
Just did it like some other fb drivers do. The only reason why someone would
want to disable DDC is probably to have I2C-less kernel.
If the EDID cannot be read (old monitor connected or DDC pins not connected
like on Trio32 cards) or the card does not have enough memory (1280x1024 LCD
on a 1MB card), the driver falls back to 640x480-8@60.
--
Ondrej Zary
^ 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