* Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration
From: Tomi Valkeinen @ 2011-04-01 7:50 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org
In-Reply-To: <4D958407.1080505@ti.com>
On Fri, 2011-04-01 at 13:21 +0530, Archit Taneja wrote:
> On Friday 01 April 2011 12:37 PM, Valkeinen, Tomi wrote:
> > On Fri, 2011-04-01 at 12:35 +0530, Archit Taneja wrote:
> >> On Thursday 31 March 2011 03:40 PM, Valkeinen, Tomi wrote:
> >>> Clock configuration was defined inside dssdev.phy.dsi struct. The clock
> >>> config doesn't really belong there, and so it's moved to dssdev.clock
> >>> struct.
> >>>
> >>> Now the explicit clock configuration could also be used for other
> >>> interfaces than DSI, although there's no support for it currently.
> >>>
> >>> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> >>> ---
> >>> arch/arm/mach-omap2/board-4430sdp.c | 14 +++++++++-----
> >>> arch/arm/plat-omap/include/plat/display.h | 28 ++++++++++++++++------------
> >>> drivers/video/omap2/dss/dsi.c | 14 +++++++-------
> >>> 3 files changed, 32 insertions(+), 24 deletions(-)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> >>> index 05288c9..626b16b 100644
> >>> --- a/arch/arm/mach-omap2/board-4430sdp.c
> >>> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> >
> > <snip>
> >
> >>> @@ -424,6 +412,22 @@ struct omap_dss_device {
> >>> } phy;
> >>>
> >>> struct {
> >>> + struct {
> >>> + u16 lck_div;
> >>> + u16 pck_div;
> >>
> >> Is it possible to wrap these members around a channel member? The board
> >> file can then fill up the lck_div and ppck_div based on what channel it
> >> is using.
> >
> > Hmm. What do you mean "wrap around"? The channel is defined a bit below
> > there.
> >
>
> I meant something like:
>
> ...
> struct {
> struct {
> struct {
> u16 lck_div;
> u16 pck_div;
> } channel[MAX_CHANNELS];
> } dispc;
>
> ...
>
> struct {
>
> } dsi;
>
> } clocks;
> ...
>
> Or something equivalent to the thing above, like using a pointer to an
> array.
What would be the benefit of that? A dss device can be connected only to
one channel. Now we have the dividers and the channel defined, and
omapdss can use this info to configure the dividers for that channel
properly.
Tomi
^ permalink raw reply
* Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration
From: Archit Taneja @ 2011-04-01 7:47 UTC (permalink / raw)
To: Valkeinen, Tomi; +Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org
In-Reply-To: <1301641628.3393.5.camel@deskari>
On Friday 01 April 2011 12:37 PM, Valkeinen, Tomi wrote:
> On Fri, 2011-04-01 at 12:35 +0530, Archit Taneja wrote:
>> On Thursday 31 March 2011 03:40 PM, Valkeinen, Tomi wrote:
>>> Clock configuration was defined inside dssdev.phy.dsi struct. The clock
>>> config doesn't really belong there, and so it's moved to dssdev.clock
>>> struct.
>>>
>>> Now the explicit clock configuration could also be used for other
>>> interfaces than DSI, although there's no support for it currently.
>>>
>>> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
>>> ---
>>> arch/arm/mach-omap2/board-4430sdp.c | 14 +++++++++-----
>>> arch/arm/plat-omap/include/plat/display.h | 28 ++++++++++++++++------------
>>> drivers/video/omap2/dss/dsi.c | 14 +++++++-------
>>> 3 files changed, 32 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
>>> index 05288c9..626b16b 100644
>>> --- a/arch/arm/mach-omap2/board-4430sdp.c
>>> +++ b/arch/arm/mach-omap2/board-4430sdp.c
>
> <snip>
>
>>> @@ -424,6 +412,22 @@ struct omap_dss_device {
>>> } phy;
>>>
>>> struct {
>>> + struct {
>>> + u16 lck_div;
>>> + u16 pck_div;
>>
>> Is it possible to wrap these members around a channel member? The board
>> file can then fill up the lck_div and ppck_div based on what channel it
>> is using.
>
> Hmm. What do you mean "wrap around"? The channel is defined a bit below
> there.
>
I meant something like:
...
struct {
struct {
struct {
u16 lck_div;
u16 pck_div;
} channel[MAX_CHANNELS];
} dispc;
...
struct {
} dsi;
} clocks;
...
Or something equivalent to the thing above, like using a pointer to an
array.
Archit
^ permalink raw reply
* [PATCH] video: s3c-fb: fix checkpatch errors and warning
From: Jingoo Han @ 2011-04-01 7:17 UTC (permalink / raw)
To: linux-fbdev
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>
---
drivers/video/s3c-fb.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 6817d18..3b6cdca 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -48,7 +48,7 @@
#undef writel
#define writel(v, r) do { \
printk(KERN_DEBUG "%s: %08x => %p\n", __func__, (unsigned int)v, r); \
- __raw_writel(v, r); } while(0)
+ __raw_writel(v, r); } while (0)
#endif /* FB_S3C_DEBUG_REGWRITE */
/* irq_flags bits */
@@ -518,7 +518,7 @@ static int s3c_fb_set_par(struct fb_info *info)
data = VIDTCON2_LINEVAL(var->yres - 1) |
VIDTCON2_HOZVAL(var->xres - 1);
- writel(data, regs +sfb->variant.vidtcon + 8 );
+ writel(data, regs + sfb->variant.vidtcon + 8);
}
/* write the buffer address */
@@ -1304,6 +1304,7 @@ static void s3c_fb_clear_win(struct s3c_fb *sfb, int win)
static int __devinit s3c_fb_probe(struct platform_device *pdev)
{
+ const struct platform_device_id *platid;
struct s3c_fb_driverdata *fbdrv;
struct device *dev = &pdev->dev;
struct s3c_fb_platdata *pd;
@@ -1312,7 +1313,8 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
int win;
int ret = 0;
- fbdrv = (struct s3c_fb_driverdata *)platform_get_device_id(pdev)->driver_data;
+ platid = platform_get_device_id(pdev);
+ fbdrv = (struct s3c_fb_driverdata *)platid->driver_data;
if (fbdrv->variant.nr_windows > S3C_FB_MAX_WIN) {
dev_err(dev, "too many windows, cannot attach\n");
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration
From: Archit Taneja @ 2011-04-01 7:17 UTC (permalink / raw)
To: Valkeinen, Tomi; +Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org
In-Reply-To: <1301566266-11187-2-git-send-email-tomi.valkeinen@ti.com>
On Thursday 31 March 2011 03:40 PM, Valkeinen, Tomi wrote:
> Clock configuration was defined inside dssdev.phy.dsi struct. The clock
> config doesn't really belong there, and so it's moved to dssdev.clock
> struct.
>
> Now the explicit clock configuration could also be used for other
> interfaces than DSI, although there's no support for it currently.
>
> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> ---
> arch/arm/mach-omap2/board-4430sdp.c | 14 +++++++++-----
> arch/arm/plat-omap/include/plat/display.h | 28 ++++++++++++++++------------
> drivers/video/omap2/dss/dsi.c | 14 +++++++-------
> 3 files changed, 32 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> index 05288c9..626b16b 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -766,17 +766,21 @@ static struct omap_dss_device sdp4430_lcd_device = {
> .data1_pol = 0,
> .data2_lane = 3,
> .data2_pol = 0,
> - .div = {
> + },
> +
> + .clocks = {
> + .dispc = {
> + .lck_div = 1, /* Logic Clock = 172.8 MHz */
> + .pck_div = 5, /* Pixel Clock = 34.56 MHz */
> + },
> +
> + .dsi = {
> .regn = 16, /* Fint = 2.4 MHz */
> .regm = 180, /* DDR Clock = 216 MHz */
> .regm_dispc = 5, /* PLL1_CLK1 = 172.8 MHz */
> .regm_dsi = 5, /* PLL1_CLK2 = 172.8 MHz */
>
> .lp_clk_div = 10, /* LP Clock = 8.64 MHz */
> -
> - .lck_div = 1, /* Logic Clock = 172.8 MHz */
> - .pck_div = 5, /* Pixel Clock = 34.56 MHz */
> -
> },
> },
> .channel = OMAP_DSS_CHANNEL_LCD,
> diff --git a/arch/arm/plat-omap/include/plat/display.h b/arch/arm/plat-omap/include/plat/display.h
> index 5e04ddc..e10cfe2 100644
> --- a/arch/arm/plat-omap/include/plat/display.h
> +++ b/arch/arm/plat-omap/include/plat/display.h
> @@ -401,18 +401,6 @@ struct omap_dss_device {
> u8 data2_lane;
> u8 data2_pol;
>
> - struct {
> - u16 regn;
> - u16 regm;
> - u16 regm_dispc;
> - u16 regm_dsi;
> -
> - u16 lp_clk_div;
> -
> - u16 lck_div;
> - u16 pck_div;
> - } div;
> -
> bool ext_te;
> u8 ext_te_gpio;
> } dsi;
> @@ -424,6 +412,22 @@ struct omap_dss_device {
> } phy;
>
> struct {
> + struct {
> + u16 lck_div;
> + u16 pck_div;
Is it possible to wrap these members around a channel member? The board
file can then fill up the lck_div and ppck_div based on what channel it
is using.
Archit
> + } dispc;
> +
> + struct {
> + u16 regn;
> + u16 regm;
> + u16 regm_dispc;
> + u16 regm_dsi;
> +
> + u16 lp_clk_div;
> + } dsi;
> + } clocks;
> +
> + struct {
> struct omap_video_timings timings;
>
> int acbi; /* ac-bias pin transitions per interrupt */
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index 23d9bbe..7304c87 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -1026,7 +1026,7 @@ static int dsi_set_lp_clk_divisor(struct omap_dss_device *dssdev)
> unsigned lp_clk_div;
> unsigned long lp_clk;
>
> - lp_clk_div = dssdev->phy.dsi.div.lp_clk_div;
> + lp_clk_div = dssdev->clocks.dsi.lp_clk_div;
>
> if (lp_clk_div = 0 || lp_clk_div> dsi.lpdiv_max)
> return -EINVAL;
> @@ -3388,10 +3388,10 @@ static int dsi_configure_dsi_clocks(struct omap_dss_device *dssdev)
>
> /* we always use DSS_CLK_SYSCK as input clock */
> cinfo.use_sys_clk = true;
> - cinfo.regn = dssdev->phy.dsi.div.regn;
> - cinfo.regm = dssdev->phy.dsi.div.regm;
> - cinfo.regm_dispc = dssdev->phy.dsi.div.regm_dispc;
> - cinfo.regm_dsi = dssdev->phy.dsi.div.regm_dsi;
> + cinfo.regn = dssdev->clocks.dsi.regn;
> + cinfo.regm = dssdev->clocks.dsi.regm;
> + cinfo.regm_dispc = dssdev->clocks.dsi.regm_dispc;
> + cinfo.regm_dsi = dssdev->clocks.dsi.regm_dsi;
> r = dsi_calc_clock_rates(dssdev,&cinfo);
> if (r) {
> DSSERR("Failed to calc dsi clocks\n");
> @@ -3415,8 +3415,8 @@ static int dsi_configure_dispc_clocks(struct omap_dss_device *dssdev)
>
> fck = dsi_get_pll_hsdiv_dispc_rate();
>
> - dispc_cinfo.lck_div = dssdev->phy.dsi.div.lck_div;
> - dispc_cinfo.pck_div = dssdev->phy.dsi.div.pck_div;
> + dispc_cinfo.lck_div = dssdev->clocks.dispc.lck_div;
> + dispc_cinfo.pck_div = dssdev->clocks.dispc.pck_div;
>
> r = dispc_calc_clock_rates(fck,&dispc_cinfo);
> if (r) {
^ permalink raw reply
* Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration
From: Tomi Valkeinen @ 2011-04-01 7:07 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org
In-Reply-To: <4D957923.2030902@ti.com>
On Fri, 2011-04-01 at 12:35 +0530, Archit Taneja wrote:
> On Thursday 31 March 2011 03:40 PM, Valkeinen, Tomi wrote:
> > Clock configuration was defined inside dssdev.phy.dsi struct. The clock
> > config doesn't really belong there, and so it's moved to dssdev.clock
> > struct.
> >
> > Now the explicit clock configuration could also be used for other
> > interfaces than DSI, although there's no support for it currently.
> >
> > Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> > ---
> > arch/arm/mach-omap2/board-4430sdp.c | 14 +++++++++-----
> > arch/arm/plat-omap/include/plat/display.h | 28 ++++++++++++++++------------
> > drivers/video/omap2/dss/dsi.c | 14 +++++++-------
> > 3 files changed, 32 insertions(+), 24 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> > index 05288c9..626b16b 100644
> > --- a/arch/arm/mach-omap2/board-4430sdp.c
> > +++ b/arch/arm/mach-omap2/board-4430sdp.c
<snip>
> > @@ -424,6 +412,22 @@ struct omap_dss_device {
> > } phy;
> >
> > struct {
> > + struct {
> > + u16 lck_div;
> > + u16 pck_div;
>
> Is it possible to wrap these members around a channel member? The board
> file can then fill up the lck_div and ppck_div based on what channel it
> is using.
Hmm. What do you mean "wrap around"? The channel is defined a bit below
there.
Tomi
^ permalink raw reply
* [PATCH 2/2] efifb: Add override for 11" Macbook Air 3,1
From: Peter Jones @ 2011-03-31 14:33 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-03-31 14:33 UTC (permalink / raw)
To: linux-fbdev
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(-)
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
* [PATCH 0/2] Support incorrect UEFI Graphics Output Protocol fields.
From: Peter Jones @ 2011-03-31 14:33 UTC (permalink / raw)
To: linux-fbdev
This patchset allows us to handle UEFI machines that have fields which
have partially incorrect data in the GOP mode line by overriding individual
fields with our DMI table.
^ permalink raw reply
* [PATCH 9/9] OMAP: DSS2: VENC: Add missing start/stop_device calls
From: Tomi Valkeinen @ 2011-03-31 10:11 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1301566266-11187-1-git-send-email-tomi.valkeinen@ti.com>
VENC code was missing omap_dss_start/stop_device calls. This didn't
cause any problems as VENC could not be compiled as a module, but
nevertheless it's better to add the calls.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/venc.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index fe18800..b845c56 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -476,6 +476,12 @@ static int venc_panel_enable(struct omap_dss_device *dssdev)
mutex_lock(&venc.venc_lock);
+ r = omap_dss_start_device(dssdev);
+ if (r) {
+ DSSERR("failed to start device\n");
+ goto err0;
+ }
+
if (dssdev->state != OMAP_DSS_DISPLAY_DISABLED) {
r = -EINVAL;
goto err1;
@@ -487,7 +493,11 @@ static int venc_panel_enable(struct omap_dss_device *dssdev)
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+ mutex_unlock(&venc.venc_lock);
+ return 0;
err1:
+ omap_dss_stop_device(dssdev);
+err0:
mutex_unlock(&venc.venc_lock);
return r;
@@ -511,6 +521,8 @@ static void venc_panel_disable(struct omap_dss_device *dssdev)
venc_power_off(dssdev);
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
+
+ omap_dss_stop_device(dssdev);
end:
mutex_unlock(&venc.venc_lock);
}
--
1.7.1
^ permalink raw reply related
* [PATCH 8/9] OMAP: DSS2: OMAPFB: Remove implicit display update on unblank
From: Tomi Valkeinen @ 2011-03-31 10:11 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Jani Nikula, Tomi Valkeinen
In-Reply-To: <1301566266-11187-1-git-send-email-tomi.valkeinen@ti.com>
From: Jani Nikula <ext-jani.1.nikula@nokia.com>
Currently omapfb does an implicit display update (for manual update
displays) on unblank.
There is no guarantee that the framebuffer contains a valid image when
unblank is called. When using manual update displays it is the
responsibility of the user space to update the display, and so it should
be in this case also.
This patch removes the implicit display update on unblank.
Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
[tomi.valkeinen@ti.com: improved description]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 13 -------------
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 1b89e28..1f9cb3a 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1271,7 +1271,6 @@ static int omapfb_blank(int blank, struct fb_info *fbi)
struct omapfb_info *ofbi = FB2OFB(fbi);
struct omapfb2_device *fbdev = ofbi->fbdev;
struct omap_dss_device *display = fb2display(fbi);
- int do_update = 0;
int r = 0;
if (!display)
@@ -1287,11 +1286,6 @@ static int omapfb_blank(int blank, struct fb_info *fbi)
if (display->driver->resume)
r = display->driver->resume(display);
- if (r = 0 && display->driver->get_update_mode &&
- display->driver->get_update_mode(display) =
- OMAP_DSS_UPDATE_MANUAL)
- do_update = 1;
-
break;
case FB_BLANK_NORMAL:
@@ -1315,13 +1309,6 @@ static int omapfb_blank(int blank, struct fb_info *fbi)
exit:
omapfb_unlock(fbdev);
- if (r = 0 && do_update && display->driver->update) {
- u16 w, h;
- display->driver->get_resolution(display, &w, &h);
-
- r = display->driver->update(display, 0, 0, w, h);
- }
-
return r;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 7/9] OMAP: DSS2: OMAPFB: Handle errors when initializing panel
From: Tomi Valkeinen @ 2011-03-31 10:11 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1301566266-11187-1-git-send-email-tomi.valkeinen@ti.com>
Errors from the panel driver were ignored during panel initialization.
Handle the errors and fail accordingly.
Also move the display initialization to a separate function to make it
cleaner.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 80 ++++++++++++++++++++++--------
1 files changed, 59 insertions(+), 21 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 163fb8b..1b89e28 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2193,6 +2193,61 @@ static int omapfb_parse_def_modes(struct omapfb2_device *fbdev)
return r;
}
+static int omapfb_init_display(struct omapfb2_device *fbdev,
+ struct omap_dss_device *dssdev)
+{
+ struct omap_dss_driver *dssdrv = dssdev->driver;
+ int r;
+
+ r = dssdrv->enable(dssdev);
+ if (r) {
+ dev_warn(fbdev->dev, "Failed to enable display '%s'\n",
+ dssdev->name);
+ return r;
+ }
+
+ if (dssdev->caps & OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) {
+ u16 w, h;
+ if (dssdrv->enable_te) {
+ r = dssdrv->enable_te(dssdev, 1);
+ if (r) {
+ dev_err(fbdev->dev, "Failed to set TE\n");
+ return r;
+ }
+ }
+
+ if (dssdrv->set_update_mode) {
+ r = dssdrv->set_update_mode(dssdev,
+ OMAP_DSS_UPDATE_MANUAL);
+ if (r) {
+ dev_err(fbdev->dev,
+ "Failed to set update mode\n");
+ return r;
+ }
+ }
+
+ dssdrv->get_resolution(dssdev, &w, &h);
+ r = dssdrv->update(dssdev, 0, 0, w, h);
+ if (r) {
+ dev_err(fbdev->dev,
+ "Failed to update display\n");
+ return r;
+ }
+ } else {
+ if (dssdrv->set_update_mode) {
+ r = dssdrv->set_update_mode(dssdev,
+ OMAP_DSS_UPDATE_AUTO);
+ if (r) {
+ dev_err(fbdev->dev,
+ "Failed to set update mode\n");
+ return r;
+ }
+ }
+ }
+
+ return 0;
+}
+
static int omapfb_probe(struct platform_device *pdev)
{
struct omapfb2_device *fbdev = NULL;
@@ -2292,30 +2347,13 @@ static int omapfb_probe(struct platform_device *pdev)
}
if (def_display) {
- struct omap_dss_driver *dssdrv = def_display->driver;
-
- r = def_display->driver->enable(def_display);
+ r = omapfb_init_display(fbdev, def_display);
if (r) {
- dev_warn(fbdev->dev, "Failed to enable display '%s'\n",
- def_display->name);
+ dev_err(fbdev->dev,
+ "failed to initialize default "
+ "display\n");
goto cleanup;
}
-
- if (def_display->caps & OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) {
- u16 w, h;
- if (dssdrv->enable_te)
- dssdrv->enable_te(def_display, 1);
- if (dssdrv->set_update_mode)
- dssdrv->set_update_mode(def_display,
- OMAP_DSS_UPDATE_MANUAL);
-
- dssdrv->get_resolution(def_display, &w, &h);
- def_display->driver->update(def_display, 0, 0, w, h);
- } else {
- if (dssdrv->set_update_mode)
- dssdrv->set_update_mode(def_display,
- OMAP_DSS_UPDATE_AUTO);
- }
}
DBG("create sysfs for fbs\n");
--
1.7.1
^ permalink raw reply related
* [PATCH 6/9] OMAP: DSS2: Add method for querying display dimensions from DSS drivers
From: Tomi Valkeinen @ 2011-03-31 10:11 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Jani Nikula, Tomi Valkeinen
In-Reply-To: <1301566266-11187-1-git-send-email-tomi.valkeinen@ti.com>
From: Jani Nikula <ext-jani.1.nikula@nokia.com>
Add get_dimensions() to struct omap_dss_driver. Use the call, if supported
by the driver, in OMAPFB.
Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/plat-omap/include/plat/display.h | 2 ++
drivers/video/omap2/omapfb/omapfb-ioctl.c | 12 ++++++++++--
drivers/video/omap2/omapfb/omapfb-main.c | 12 ++++++++++--
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h b/arch/arm/plat-omap/include/plat/display.h
index e10cfe2..f6e4b87 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -507,6 +507,8 @@ struct omap_dss_driver {
void (*get_resolution)(struct omap_dss_device *dssdev,
u16 *xres, u16 *yres);
+ void (*get_dimensions)(struct omap_dss_device *dssdev,
+ u32 *width, u32 *height);
int (*get_recommended_bpp)(struct omap_dss_device *dssdev);
int (*check_timings)(struct omap_dss_device *dssdev,
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 6f43545..b4636b1 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -895,8 +895,16 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd, unsigned long arg)
p.display_info.xres = xres;
p.display_info.yres = yres;
- p.display_info.width = 0;
- p.display_info.height = 0;
+
+ if (display->driver->get_dimensions) {
+ u32 w, h;
+ display->driver->get_dimensions(display, &w, &h);
+ p.display_info.width = w;
+ p.display_info.height = h;
+ } else {
+ p.display_info.width = 0;
+ p.display_info.height = 0;
+ }
if (copy_to_user((void __user *)arg, &p.display_info,
sizeof(p.display_info)))
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 505ec66..163fb8b 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -702,8 +702,16 @@ int check_fb_var(struct fb_info *fbi, struct fb_var_screeninfo *var)
var->xres, var->yres,
var->xres_virtual, var->yres_virtual);
- var->height = -1;
- var->width = -1;
+ if (display && display->driver->get_dimensions) {
+ u32 w, h;
+ display->driver->get_dimensions(display, &w, &h);
+ var->width = DIV_ROUND_CLOSEST(w, 1000);
+ var->height = DIV_ROUND_CLOSEST(h, 1000);
+ } else {
+ var->height = -1;
+ var->width = -1;
+ }
+
var->grayscale = 0;
if (display && display->driver->get_timings) {
--
1.7.1
^ permalink raw reply related
* [PATCH 5/9] OMAP: DSS2: VENC: Remove sleeps at venc enable/disable
From: Tomi Valkeinen @ 2011-03-31 10:11 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1301566266-11187-1-git-send-email-tomi.valkeinen@ti.com>
VENC code had 50ms sleep after enabling the output and 100ms sleep after
disabling the output. I don't see any reason for these sleeps.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/venc.c | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 8c7af90..fe18800 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -487,9 +487,6 @@ static int venc_panel_enable(struct omap_dss_device *dssdev)
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
- /* wait couple of vsyncs until enabling the LCD */
- msleep(50);
-
err1:
mutex_unlock(&venc.venc_lock);
@@ -513,9 +510,6 @@ static void venc_panel_disable(struct omap_dss_device *dssdev)
venc_power_off(dssdev);
- /* wait at least 5 vsyncs after disabling the LCD */
- msleep(100);
-
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
end:
mutex_unlock(&venc.venc_lock);
--
1.7.1
^ permalink raw reply related
* [PATCH 4/9] OMAP: DSS2: VENC: make 20ms venc bug-fix sleep optional
From: Tomi Valkeinen @ 2011-03-31 10:11 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1301566266-11187-1-git-send-email-tomi.valkeinen@ti.com>
There's a 20ms sleep after VENC reset. It's unknown what bug this
circumvents and on what platforms. Add a Kconfig option to disable the
sleep.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/Kconfig | 12 ++++++++++++
drivers/video/omap2/dss/venc.c | 3 +++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 458cfe1..5b45c0c 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -136,4 +136,16 @@ config OMAP2_DSS_SLEEP_BEFORE_RESET
However, 50ms is quite long time to sleep, and with some
configurations the SYNC_LOST may never happen, so the sleep can
be disabled here.
+
+config OMAP2_DSS_SLEEP_AFTER_VENC_RESET
+ bool "Sleep 20ms after VENC reset"
+ default y
+ help
+ There is a 20ms sleep after VENC reset which seemed to fix the
+ reset. The reason for the bug is unclear, and it's also unclear
+ on what platforms this happens.
+
+ This option enables the sleep, and is enabled by default. You can
+ disable the sleep if it doesn't cause problems on your platform.
+
endif
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 8e35a5b..8c7af90 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -373,8 +373,11 @@ static void venc_reset(void)
}
}
+#ifdef CONFIG_OMAP2_DSS_SLEEP_AFTER_VENC_RESET
/* the magical sleep that makes things work */
+ /* XXX more info? What bug this circumvents? */
msleep(20);
+#endif
}
static void venc_enable_clocks(int enable)
--
1.7.1
^ permalink raw reply related
* [PATCH 3/9] OMAP: DSS2: make 50ms bug-fix sleep optional
From: Tomi Valkeinen @ 2011-03-31 10:11 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1301566266-11187-1-git-send-email-tomi.valkeinen@ti.com>
For some unknown reason we may get SYNC_LOST errors from the display
subsystem at initialization time if we don't sleep before resetting the
DSS. See the source (dss.c) for more comments.
However, 50ms is quite long time to sleep, and with some configurations
the SYNC_LOST may never happen, so this patch creates a Kconfig option
to disable the sleep.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/Kconfig | 11 +++++++++++
drivers/video/omap2/dss/dss.c | 5 +++++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index bfc5da0..458cfe1 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -125,4 +125,15 @@ config OMAP2_DSS_MIN_FCK_PER_PCK
Max FCK is 173MHz, so this doesn't work if your PCK
is very high.
+config OMAP2_DSS_SLEEP_BEFORE_RESET
+ bool "Sleep 50ms before DSS reset"
+ default y
+ help
+ For some unknown reason we may get SYNC_LOST errors from the display
+ subsystem at initialization time if we don't sleep before resetting
+ the DSS. See the source (dss.c) for more comments.
+
+ However, 50ms is quite long time to sleep, and with some
+ configurations the SYNC_LOST may never happen, so the sleep can
+ be disabled here.
endif
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 3f1fee6..688947f 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -659,13 +659,18 @@ static int dss_init(void)
* the kernel resets it */
omap_writel(omap_readl(0x48050440) & ~0x3, 0x48050440);
+#ifdef CONFIG_OMAP2_DSS_SLEEP_BEFORE_RESET
/* We need to wait here a bit, otherwise we sometimes start to
* get synclost errors, and after that only power cycle will
* restore DSS functionality. I have no idea why this happens.
* And we have to wait _before_ resetting the DSS, but after
* enabling clocks.
+ *
+ * This bug was at least present on OMAP3430. It's unknown
+ * if it happens on OMAP2 or OMAP3630.
*/
msleep(50);
+#endif
_omap_dss_reset();
--
1.7.1
^ permalink raw reply related
* [PATCH 2/9] OMAP: DSS2: remove non-working msleep(40) workaround
From: Tomi Valkeinen @ 2011-03-31 10:10 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1301566266-11187-1-git-send-email-tomi.valkeinen@ti.com>
The sleep workaround for the problem described in the comment doesn't
really work. This patch removes the workaround, and improves the comment
about the bug, and proposes an userspace workaround.
omap_dss_set_manager() is called 6 times when loading omapdss and
omapfb, which means that 40ms * 6 = 240ms was spent sleeping when
booting up.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/overlay.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/dss/overlay.c b/drivers/video/omap2/dss/overlay.c
index f1aca6d..fcde51b 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -491,13 +491,18 @@ static int omap_dss_set_manager(struct omap_overlay *ovl,
ovl->manager = mgr;
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK);
- /* XXX: on manual update display, in auto update mode, a bug happens
- * here. When an overlay is first enabled on LCD, then it's disabled,
- * and the manager is changed to TV, we sometimes get SYNC_LOST_DIGIT
- * errors. Waiting before changing the channel_out fixes it. I'm
- * guessing that the overlay is still somehow being used for the LCD,
- * but I don't understand how or why. */
- msleep(40);
+ /* XXX: When there is an overlay on a DSI manual update display, and
+ * the overlay is first disabled, then moved to tv, and enabled, we
+ * seem to get SYNC_LOST_DIGIT error.
+ *
+ * Waiting doesn't seem to help, but updating the manual update display
+ * after disabling the overlay seems to fix this. This hints that the
+ * overlay is perhaps somehow tied to the LCD output until the output
+ * is updated.
+ *
+ * Userspace workaround for this is to update the LCD after disabling
+ * the overlay, but before moving the overlay to TV.
+ */
dispc_set_channel_out(ovl->id, mgr->id);
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK);
--
1.7.1
^ permalink raw reply related
* [PATCH 1/9] OMAP: DSS2: move dss device clock configuration
From: Tomi Valkeinen @ 2011-03-31 10:10 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1301566266-11187-1-git-send-email-tomi.valkeinen@ti.com>
Clock configuration was defined inside dssdev.phy.dsi struct. The clock
config doesn't really belong there, and so it's moved to dssdev.clock
struct.
Now the explicit clock configuration could also be used for other
interfaces than DSI, although there's no support for it currently.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 14 +++++++++-----
arch/arm/plat-omap/include/plat/display.h | 28 ++++++++++++++++------------
drivers/video/omap2/dss/dsi.c | 14 +++++++-------
3 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 05288c9..626b16b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -766,17 +766,21 @@ static struct omap_dss_device sdp4430_lcd_device = {
.data1_pol = 0,
.data2_lane = 3,
.data2_pol = 0,
- .div = {
+ },
+
+ .clocks = {
+ .dispc = {
+ .lck_div = 1, /* Logic Clock = 172.8 MHz */
+ .pck_div = 5, /* Pixel Clock = 34.56 MHz */
+ },
+
+ .dsi = {
.regn = 16, /* Fint = 2.4 MHz */
.regm = 180, /* DDR Clock = 216 MHz */
.regm_dispc = 5, /* PLL1_CLK1 = 172.8 MHz */
.regm_dsi = 5, /* PLL1_CLK2 = 172.8 MHz */
.lp_clk_div = 10, /* LP Clock = 8.64 MHz */
-
- .lck_div = 1, /* Logic Clock = 172.8 MHz */
- .pck_div = 5, /* Pixel Clock = 34.56 MHz */
-
},
},
.channel = OMAP_DSS_CHANNEL_LCD,
diff --git a/arch/arm/plat-omap/include/plat/display.h b/arch/arm/plat-omap/include/plat/display.h
index 5e04ddc..e10cfe2 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -401,18 +401,6 @@ struct omap_dss_device {
u8 data2_lane;
u8 data2_pol;
- struct {
- u16 regn;
- u16 regm;
- u16 regm_dispc;
- u16 regm_dsi;
-
- u16 lp_clk_div;
-
- u16 lck_div;
- u16 pck_div;
- } div;
-
bool ext_te;
u8 ext_te_gpio;
} dsi;
@@ -424,6 +412,22 @@ struct omap_dss_device {
} phy;
struct {
+ struct {
+ u16 lck_div;
+ u16 pck_div;
+ } dispc;
+
+ struct {
+ u16 regn;
+ u16 regm;
+ u16 regm_dispc;
+ u16 regm_dsi;
+
+ u16 lp_clk_div;
+ } dsi;
+ } clocks;
+
+ struct {
struct omap_video_timings timings;
int acbi; /* ac-bias pin transitions per interrupt */
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 23d9bbe..7304c87 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1026,7 +1026,7 @@ static int dsi_set_lp_clk_divisor(struct omap_dss_device *dssdev)
unsigned lp_clk_div;
unsigned long lp_clk;
- lp_clk_div = dssdev->phy.dsi.div.lp_clk_div;
+ lp_clk_div = dssdev->clocks.dsi.lp_clk_div;
if (lp_clk_div = 0 || lp_clk_div > dsi.lpdiv_max)
return -EINVAL;
@@ -3388,10 +3388,10 @@ static int dsi_configure_dsi_clocks(struct omap_dss_device *dssdev)
/* we always use DSS_CLK_SYSCK as input clock */
cinfo.use_sys_clk = true;
- cinfo.regn = dssdev->phy.dsi.div.regn;
- cinfo.regm = dssdev->phy.dsi.div.regm;
- cinfo.regm_dispc = dssdev->phy.dsi.div.regm_dispc;
- cinfo.regm_dsi = dssdev->phy.dsi.div.regm_dsi;
+ cinfo.regn = dssdev->clocks.dsi.regn;
+ cinfo.regm = dssdev->clocks.dsi.regm;
+ cinfo.regm_dispc = dssdev->clocks.dsi.regm_dispc;
+ cinfo.regm_dsi = dssdev->clocks.dsi.regm_dsi;
r = dsi_calc_clock_rates(dssdev, &cinfo);
if (r) {
DSSERR("Failed to calc dsi clocks\n");
@@ -3415,8 +3415,8 @@ static int dsi_configure_dispc_clocks(struct omap_dss_device *dssdev)
fck = dsi_get_pll_hsdiv_dispc_rate();
- dispc_cinfo.lck_div = dssdev->phy.dsi.div.lck_div;
- dispc_cinfo.pck_div = dssdev->phy.dsi.div.pck_div;
+ dispc_cinfo.lck_div = dssdev->clocks.dispc.lck_div;
+ dispc_cinfo.pck_div = dssdev->clocks.dispc.pck_div;
r = dispc_calc_clock_rates(fck, &dispc_cinfo);
if (r) {
--
1.7.1
^ permalink raw reply related
* [PATCH 0/9] Miscellaneous OMAP DSS patches
From: Tomi Valkeinen @ 2011-03-31 10:10 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
Some miscellaneous DSS patches. Quite minor fixes/cleanups, except "Remove
implicit display update on unblank" which does have some functional impact.
Jani Nikula (2):
OMAP: DSS2: Add method for querying display dimensions from DSS
drivers
OMAP: DSS2: OMAPFB: Remove implicit display update on unblank
Tomi Valkeinen (7):
OMAP: DSS2: move dss device clock configuration
OMAP: DSS2: remove non-working msleep(40) workaround
OMAP: DSS2: make 50ms bug-fix sleep optional
OMAP: DSS2: VENC: make 20ms venc bug-fix sleep optional
OMAP: DSS2: VENC: Remove sleeps at venc enable/disable
OMAP: DSS2: OMAPFB: Handle errors when initializing panel
OMAP: DSS2: VENC: Add missing start/stop_device calls
arch/arm/mach-omap2/board-4430sdp.c | 14 +++--
arch/arm/plat-omap/include/plat/display.h | 30 +++++---
drivers/video/omap2/dss/Kconfig | 23 ++++++
drivers/video/omap2/dss/dsi.c | 14 ++--
drivers/video/omap2/dss/dss.c | 5 ++
drivers/video/omap2/dss/overlay.c | 19 +++--
drivers/video/omap2/dss/venc.c | 21 ++++--
drivers/video/omap2/omapfb/omapfb-ioctl.c | 12 +++-
drivers/video/omap2/omapfb/omapfb-main.c | 105 +++++++++++++++++++----------
9 files changed, 168 insertions(+), 75 deletions(-)
^ permalink raw reply
* Re: [PATCH] efifb: support AMD Radeon HD 6490
From: Paul Mundt @ 2011-03-31 4:54 UTC (permalink / raw)
To: Davidlohr Bueso; +Cc: Peter Jones, linux-fbdev, LKML, zeus
In-Reply-To: <1301530342.2140.2.camel@offworld>
On Wed, Mar 30, 2011 at 09:12:22PM -0300, Davidlohr Bueso wrote:
> This patch enables the framebuffer for the AMD Radeon 6490 found in the new MacBook Pro 8,2 generation.
> The framebuffer's base is located at 0x90010000, the method for obtaining it was found in the same way mentioned in https://patchwork.kernel.org/patch/91704/
>
> Signed-off-by: Davidlohr Bueso <dave@gnu.org>
> Signed-off-by: Jonathan Gonzalez <zeus@gnu.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] s3fb: fix Virge/GX2
From: Paul Mundt @ 2011-03-31 4:52 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Ondrej Zajicek, linux-fbdev, Kernel development list
In-Reply-To: <201103292107.11969.linux@rainbow-software.org>
On Tue, Mar 29, 2011 at 09:07:08PM +0200, Ondrej Zary wrote:
> Fix Virge/GX2 support in s3fb:
> - fix IDs: 86C357 is GX2, 86C359 is GX2+, 86C356 probably does not exist
> - add memory size detection
> - drive it the same way as Trio3D/2X
>
> The original IDs most likely came from S3 website which claims that:
> - 356 is Virge/GX2 with IDŠ10, driver included in Windows 2K, XP
> - 357 is Virge/GX2+ with IDŠ11, driver included in Windows ME
> - 359 is Virge/GX2+ with IDŠ12, driver included in Windows ME
> but:
> - google search for 86C356 only reveals references to Trio3D (probably
> because of a typo - Trio3D is 86C365)
> - my card is clearly marked as 86C357, Virge/GX2 and has IDŠ10
> - there is no driver for IDs 8A11 and 8A12 in Windows ME
> - there is a driver for ID 8A10 in Windows ME that says it's GX2 (357)
>
> Tested with #9 Reality 334 (86C357 Virge/GX2, ID=0x8A10).
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
>
Applied, thanks.
^ permalink raw reply
* [PATCH] efifb: support AMD Radeon HD 6490
From: Davidlohr Bueso @ 2011-03-31 0:12 UTC (permalink / raw)
To: Peter Jones, linux-fbdev; +Cc: LKML, zeus
This patch enables the framebuffer for the AMD Radeon 6490 found in the new MacBook Pro 8,2 generation.
The framebuffer's base is located at 0x90010000, the method for obtaining it was found in the same way mentioned in https://patchwork.kernel.org/patch/91704/
Signed-off-by: Davidlohr Bueso <dave@gnu.org>
Signed-off-by: Jonathan Gonzalez <zeus@gnu.org>
---
drivers/video/efifb.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index 70477c2..a9645b8 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -64,6 +64,7 @@ enum {
M_MBP_6_1, /* MacBook Pro, 6,1th gen */
M_MBP_6_2, /* MacBook Pro, 6,2th gen */
M_MBP_7_1, /* MacBook Pro, 7,1th gen */
+ M_MBP_8_2, /* MacBook Pro, 8,2nd gen */
M_UNKNOWN /* placeholder */
};
@@ -100,6 +101,7 @@ static struct efifb_dmi_info {
[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 }
};
@@ -151,6 +153,7 @@ static const struct dmi_system_id dmi_system_table[] __initconst = {
EFIFB_DMI_SYSTEM_ID("Apple Inc.", "MacBookPro6,1", M_MBP_6_1),
EFIFB_DMI_SYSTEM_ID("Apple Inc.", "MacBookPro6,2", M_MBP_6_2),
EFIFB_DMI_SYSTEM_ID("Apple Inc.", "MacBookPro7,1", M_MBP_7_1),
+ EFIFB_DMI_SYSTEM_ID("Apple Inc.", "MacBookPro8,2", M_MBP_8_2),
{},
};
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] unicore32 framebuffer driver fix: make videomemory kmalloc-ed and floatable
From: Arnd Bergmann @ 2011-03-30 10:55 UTC (permalink / raw)
To: Guan Xuetao; +Cc: 'Paul Mundt', linux-kernel, linux-fbdev
In-Reply-To: <01ea01cbeeb6$99bb5240$cd31f6c0$@mprc.pku.edu.cn>
On Wednesday 30 March 2011, Guan Xuetao wrote:
> Is it appropriate to using __get_free_pages in framebuffer driver?
Yes, it is appropriate, and it is also more efficient than using
kmalloc.
> And both SLAB and SLUB allocators support 4MB request.
Ok, I did not know that, but I see now how the maximum size is computed.
The limit was 128 KB for a long time, but has apparently changed.
Arnd
^ permalink raw reply
* RE: [PATCH] unicore32 framebuffer driver fix: make videomemory kmalloc-ed and floatable
From: Guan Xuetao @ 2011-03-30 8:43 UTC (permalink / raw)
To: 'Arnd Bergmann'; +Cc: 'Paul Mundt', linux-kernel, linux-fbdev
In-Reply-To: <201103300854.05366.arnd@arndb.de>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Wednesday, March 30, 2011 2:54 PM
> To: Guan Xuetao
> Cc: 'Paul Mundt'; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org
> Subject: Re: [PATCH] unicore32 framebuffer driver fix: make videomemory kmalloc-ed and floatable
>
> On Wednesday 30 March 2011 03:39:26 Guan Xuetao wrote:
> > > How does this work? UNIFB_MEMSIZE seems to be 4 MB, much more than the
> > > maximum of 128 KB that kmalloc can allocate.
> > >
> > > Shouldn't this use get_free_pages() instead of kmalloc?
> > >
> >
> > When using SLUB allocator, if required memory size is larger
> > than 2*PAGE_SIZE, kmalloc_large is called,
> > and eventually __get_free_pages will be called.
> > So, it would be the same as __get_free_pages.
>
> Ok, I see. It's probably still better to use __get_free_pages directly,
> because it's possible to select a different allocator that does not
> do this itself.
>
> Arnd
Is it appropriate to using __get_free_pages in framebuffer driver?
And both SLAB and SLUB allocators support 4MB request.
Thanks & Regards.
Guan Xuetao
^ permalink raw reply
* Re: [PATCH] unicore32 framebuffer driver fix: make videomemory kmalloc-ed and floatable
From: Arnd Bergmann @ 2011-03-30 6:54 UTC (permalink / raw)
To: Guan Xuetao; +Cc: 'Paul Mundt', linux-kernel, linux-fbdev
In-Reply-To: <01ca01cbee7b$4f790370$ee6b0a50$@mprc.pku.edu.cn>
On Wednesday 30 March 2011 03:39:26 Guan Xuetao wrote:
> > How does this work? UNIFB_MEMSIZE seems to be 4 MB, much more than the
> > maximum of 128 KB that kmalloc can allocate.
> >
> > Shouldn't this use get_free_pages() instead of kmalloc?
> >
>
> When using SLUB allocator, if required memory size is larger
> than 2*PAGE_SIZE, kmalloc_large is called,
> and eventually __get_free_pages will be called.
> So, it would be the same as __get_free_pages.
Ok, I see. It's probably still better to use __get_free_pages directly,
because it's possible to select a different allocator that does not
do this itself.
Arnd
^ permalink raw reply
* RE: [PATCH] unicore32 framebuffer driver fix: make videomemory kmalloc-ed and floatable
From: Guan Xuetao @ 2011-03-30 1:39 UTC (permalink / raw)
To: 'Arnd Bergmann'; +Cc: 'Paul Mundt', linux-kernel, linux-fbdev
In-Reply-To: <201103291642.49555.arnd@arndb.de>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Tuesday, March 29, 2011 10:43 PM
> To: Guan Xuetao
> Cc: Paul Mundt; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org
> Subject: Re: [PATCH] unicore32 framebuffer driver fix: make videomemory kmalloc-ed and floatable
>
> On Tuesday 29 March 2011, Guan Xuetao wrote:
> >
> > 1. make videomemory kmalloc-ed in fb-puv3.c
> > 2. remove resource reservation for old fixed UNIGFX_MMAP & UVC_MMAP space
> > 3. remove unused PKUNTIY_UNIGFX_MMAP_BASE, PKUNITY_UNIGFX_MMAP_SIZE,
> > PKUNITY_UVC_MMAP_BASE, PKUNITY_UVC_MMAP_SIZE and KUSER_UNIGFX_BASE
> > 4. remove unused header linux/vmalloc.h in fb-puv3.c
> >
> > Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
>
> How does this work? UNIFB_MEMSIZE seems to be 4 MB, much more than the
> maximum of 128 KB that kmalloc can allocate.
>
> Shouldn't this use get_free_pages() instead of kmalloc?
>
> Arnd
When using SLUB allocator, if required memory size is larger than 2*PAGE_SIZE, kmalloc_large is called,
and eventually __get_free_pages will be called.
So, it would be the same as __get_free_pages.
^ 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