* Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI
From: Alex Buell @ 2011-01-12 1:30 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111.154846.233419170.davem@davemloft.net>
On Tue, 2011-01-11 at 16:22 -0800, David Miller wrote:
> From: Alex Buell <alex.buell@munted.org.uk>
> Date: Wed, 12 Jan 2011 00:20:50 +0000
>
> > On Tue, 2011-01-11 at 15:48 -0800, David Miller wrote:
> >
> >> This patch set makes sure that FB drivers for PCI devices utilizing
> >> the svgalib interfaces work on multi-domain PCI architectures.
> >>
> >> Basically this amounts to making sure that the vgastate->vgabase
> >> __iomem pointer makes it way into every interfaces and gets used
> >> by all of the I/O access calls.
> >
> > jeez, that was fast work! I'd already done the changes in s3fb.c but
> > didn't get as far as you did with this.
> >
> > I'm now testing your patches right now.
>
> Thanks a lot in advance for testing Alex.
With your patches, this happens:
Jan 12 01:24:20 sodium kernel: fb1: S3 Virge/GX on 0000:00:03.0, 6 MB RAM, 14 MHz MCLK
Jan 12 01:24:24 sodium kernel: eth0: Link down, cable problem?
Jan 12 01:24:36 sodium kernel: eth0: Auto-Negotiation unsuccessful, trying force link mode
Jan 12 01:24:45 sodium kernel: eth0: Link down, cable problem?
Jan 12 01:24:47 sodium kernel: ERROR(1): Cheetah error trap taken afsr[0010100000000000] afar[00000000000a0000] TL1(0)
Jan 12 01:24:47 sodium kernel: ERROR(1): TPC[1057490c] TNPC[10574910] O7[80] TSTATE[9911001600]
Jan 12 01:24:47 sodium kernel: ERROR(1): TPC<restore_vga+0x8c0/0x1068 [vgastate]>
Jan 12 01:24:47 sodium kernel: ERROR(1): M_SYND(0), E_SYND(0), Privileged
Jan 12 01:24:47 sodium kernel: ERROR(1): Highest priority error (0000100000000000) "Unmapped error from system bus"
Jan 12 01:24:47 sodium kernel: ERROR(1): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
Jan 12 01:24:47 sodium kernel: ERROR(1): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
Jan 12 01:24:47 sodium kernel: ERROR(1): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[0000000000000000]
Jan 12 01:24:47 sodium kernel: ERROR(1): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
Jan 12 01:24:47 sodium kernel: ERROR(1): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
Jan 12 01:24:47 sodium kernel: ERROR(1): E-cache idx[a0000] tag[0000000001000049]
Jan 12 01:24:47 sodium kernel: ERROR(1): E-cache data0[82006c3080a08001] data1[1268001b03001c87] data2[25002050f05c24d0] data3[230021f8e65861e0]
Jan 12 01:24:47 sodium kernel: Kernel panic - not syncing: Irrecoverable deferred error trap.
Jan 12 01:24:47 sodium kernel:
Jan 12 01:24:47 sodium kernel: sym0: SCSI BUS reset detected.
Jan 12 01:24:47 sodium kernel: sym0: SCSI BUS has been reset.
Jan 12 01:24:47 sodium kernel: Call Trace:
Jan 12 01:24:47 sodium kernel: [00000000004292d0] cheetah_deferred_handler+0x494/0x4cc
Jan 12 01:24:47 sodium kernel: [0000000000405e70] c_deferred+0x18/0x24
Jan 12 01:24:47 sodium kernel: [000000001057490c] restore_vga+0x8c0/0x1068 [vgastate]
Jan 12 01:24:47 sodium kernel: [00000000105b0840] s3fb_release+0x40/0x6c [s3fb]
Jan 12 01:24:47 sodium kernel: [00000000005ca0fc] fb_release+0x24/0x4c
Jan 12 01:24:47 sodium kernel: [00000000004bb8a0] fput+0x118/0x1e0
Jan 12 01:24:47 sodium kernel: [00000000004b9100] filp_close+0x64/0x78
Jan 12 01:24:47 sodium kernel: [00000000004b91a0] SyS_close+0x8c/0xe4
Jan 12 01:24:47 sodium kernel: [0000000000406154] linux_sparc_syscall32+0x34/0x40
--
Tactical Nuclear Kittens
^ permalink raw reply
* Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI
From: Alex Buell @ 2011-01-12 2:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111.154846.233419170.davem@davemloft.net>
On Wed, 2011-01-12 at 01:30 +0000, Alex Buell wrote:
> On Tue, 2011-01-11 at 16:22 -0800, David Miller wrote:
> > From: Alex Buell <alex.buell@munted.org.uk>
> > Date: Wed, 12 Jan 2011 00:20:50 +0000
> >
> > > On Tue, 2011-01-11 at 15:48 -0800, David Miller wrote:
> > >
> > >> This patch set makes sure that FB drivers for PCI devices utilizing
> > >> the svgalib interfaces work on multi-domain PCI architectures.
> > >>
> > >> Basically this amounts to making sure that the vgastate->vgabase
> > >> __iomem pointer makes it way into every interfaces and gets used
> > >> by all of the I/O access calls.
> > >
> > > jeez, that was fast work! I'd already done the changes in s3fb.c but
> > > didn't get as far as you did with this.
> > >
> > > I'm now testing your patches right now.
> >
> > Thanks a lot in advance for testing Alex.
>
> With your patches, this happens:
>
> Jan 12 01:24:20 sodium kernel: fb1: S3 Virge/GX on 0000:00:03.0, 6 MB RAM, 14 MHz MCLK
> Jan 12 01:24:24 sodium kernel: eth0: Link down, cable problem?
> Jan 12 01:24:36 sodium kernel: eth0: Auto-Negotiation unsuccessful, trying force link mode
> Jan 12 01:24:45 sodium kernel: eth0: Link down, cable problem?
> Jan 12 01:24:47 sodium kernel: ERROR(1): Cheetah error trap taken afsr[0010100000000000] afar[00000000000a0000] TL1(0)
> Jan 12 01:24:47 sodium kernel: ERROR(1): TPC[1057490c] TNPC[10574910] O7[80] TSTATE[9911001600]
> Jan 12 01:24:47 sodium kernel: ERROR(1): TPC<restore_vga+0x8c0/0x1068 [vgastate]>
> Jan 12 01:24:47 sodium kernel: ERROR(1): M_SYND(0), E_SYND(0), Privileged
> Jan 12 01:24:47 sodium kernel: ERROR(1): Highest priority error (0000100000000000) "Unmapped error from system bus"
> Jan 12 01:24:47 sodium kernel: ERROR(1): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
> Jan 12 01:24:47 sodium kernel: ERROR(1): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
> Jan 12 01:24:47 sodium kernel: ERROR(1): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[0000000000000000]
> Jan 12 01:24:47 sodium kernel: ERROR(1): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
> Jan 12 01:24:47 sodium kernel: ERROR(1): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
> Jan 12 01:24:47 sodium kernel: ERROR(1): E-cache idx[a0000] tag[0000000001000049]
> Jan 12 01:24:47 sodium kernel: ERROR(1): E-cache data0[82006c3080a08001] data1[1268001b03001c87] data2[25002050f05c24d0] data3[230021f8e65861e0]
> Jan 12 01:24:47 sodium kernel: Kernel panic - not syncing: Irrecoverable deferred error trap.
> Jan 12 01:24:47 sodium kernel:
> Jan 12 01:24:47 sodium kernel: sym0: SCSI BUS reset detected.
> Jan 12 01:24:47 sodium kernel: sym0: SCSI BUS has been reset.
> Jan 12 01:24:47 sodium kernel: Call Trace:
> Jan 12 01:24:47 sodium kernel: [00000000004292d0] cheetah_deferred_handler+0x494/0x4cc
> Jan 12 01:24:47 sodium kernel: [0000000000405e70] c_deferred+0x18/0x24
> Jan 12 01:24:47 sodium kernel: [000000001057490c] restore_vga+0x8c0/0x1068 [vgastate]
> Jan 12 01:24:47 sodium kernel: [00000000105b0840] s3fb_release+0x40/0x6c [s3fb]
> Jan 12 01:24:47 sodium kernel: [00000000005ca0fc] fb_release+0x24/0x4c
> Jan 12 01:24:47 sodium kernel: [00000000004bb8a0] fput+0x118/0x1e0
> Jan 12 01:24:47 sodium kernel: [00000000004b9100] filp_close+0x64/0x78
> Jan 12 01:24:47 sodium kernel: [00000000004b91a0] SyS_close+0x8c/0xe4
> Jan 12 01:24:47 sodium kernel: [0000000000406154] linux_sparc_syscall32+0x34/0x40
>
>
I just found the problem. Here's a patch that makes the s3fb driver
work. Haven't seen any output on the device yet that's to come later.
Here's a quick patch:
--- s3fb.c.orig 2011-01-12 02:09:47.339553002 +0000
+++ s3fb.c 2011-01-12 02:10:01.411553002 +0000
@@ -383,7 +383,7 @@
memset(&(par->state), 0, sizeof(struct vgastate));
par->state.vgabase = vgabase;
- par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS |
VGA_SAVE_CMAP;
+ par->state.flags = VGA_SAVE_MODE | VGA_SAVE_CMAP;
par->state.num_crtc = 0x70;
par->state.num_seq = 0x20;
save_vga(&(par->state));
# fbset -i -fb /dev/fb1
mode "640x480-60"
# D: 25.176 MHz, H: 31.469 kHz, V: 59.942 Hz
geometry 640 480 640 480 8
timings 39721 40 24 32 11 96 2
rgba 8/0,8/0,8/0,0/0
endmode
Frame buffer device information:
Name : S3 Virge/GX
Address : 0x14000000
Size : 6291456
Type : PACKED PIXELS
Visual : PSEUDOCOLOR
XPanStep : 0
YPanStep : 0
YWrapStep : 0
LineLength : 0
Accelerator : No
To get the driver to use /dev/fb1, I had to comment out some code as
well:
/*
if (! svga_primary_device(dev)) {
dev_info(&(dev->dev), "ignoring secondary device\n");
return -ENODEV;
}
*/
--
Tactical Nuclear Kittens
^ permalink raw reply
* Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI
From: David Miller @ 2011-01-12 2:29 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111.154846.233419170.davem@davemloft.net>
From: Alex Buell <alex.buell@munted.org.uk>
Date: Wed, 12 Jan 2011 02:14:59 +0000
> I just found the problem. Here's a patch that makes the s3fb driver
> work. Haven't seen any output on the device yet that's to come later.
> Here's a quick patch:
>
> --- s3fb.c.orig 2011-01-12 02:09:47.339553002 +0000
> +++ s3fb.c 2011-01-12 02:10:01.411553002 +0000
> @@ -383,7 +383,7 @@
>
> memset(&(par->state), 0, sizeof(struct vgastate));
> par->state.vgabase = vgabase;
> - par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS |
> VGA_SAVE_CMAP;
> + par->state.flags = VGA_SAVE_MODE | VGA_SAVE_CMAP;
> par->state.num_crtc = 0x70;
> par->state.num_seq = 0x20;
> save_vga(&(par->state));
Hmmm, while this change is correct, restore_vga() should skip VGA_SAVE_FONTS
if state->membase is zero, which it ought ot be here. If state->membase
is zero, then ioremap() will return NULL. If ioremap() returns NULL then
restore_vga() should cleanup and return 1.
Oh... I see what is happening. save_vga() sets this value using it's
own heuristics, when VGA_SAVE_FONTS is set, but in a way that won't
work in multi-domain PCI situations.
So we need to set this up in the drivers just like we do for the
'vgabase' member.
I'll work on some patches to fix this.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI
From: David Miller @ 2011-01-12 4:27 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111.154846.233419170.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 11 Jan 2011 18:29:45 -0800 (PST)
> Oh... I see what is happening. save_vga() sets this value using it's
> own heuristics, when VGA_SAVE_FONTS is set, but in a way that won't
> work in multi-domain PCI situations.
>
> So we need to set this up in the drivers just like we do for the
> 'vgabase' member.
>
> I'll work on some patches to fix this.
Alex, give this a try.
^ permalink raw reply
* Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI
From: David Miller @ 2011-01-12 4:51 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111.154846.233419170.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 11 Jan 2011 20:27:19 -0800 (PST)
> From: David Miller <davem@davemloft.net>
> Date: Tue, 11 Jan 2011 18:29:45 -0800 (PST)
>
>> Oh... I see what is happening. save_vga() sets this value using it's
>> own heuristics, when VGA_SAVE_FONTS is set, but in a way that won't
>> work in multi-domain PCI situations.
>>
>> So we need to set this up in the drivers just like we do for the
>> 'vgabase' member.
>>
>> I'll work on some patches to fix this.
>
> Alex, give this a try.
Sorry, forgot the patch, here it is :-)
diff --git a/drivers/video/arkfb.c b/drivers/video/arkfb.c
index f63fdf7..3b2f6f5 100644
--- a/drivers/video/arkfb.c
+++ b/drivers/video/arkfb.c
@@ -535,13 +535,13 @@ static int arkfb_open(struct fb_info *info, int user)
mutex_lock(&(par->open_lock));
if (par->ref_count = 0) {
- void __iomem *vgabase = par->state.vgabase;
-
- memset(&(par->state), 0, sizeof(struct vgastate));
- par->state.vgabase = vgabase;
par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS | VGA_SAVE_CMAP;
+ par->state.depth = 0;
+ par->state.num_attr = 0;
par->state.num_crtc = 0x60;
+ par->state.num_gfx = 0;
par->state.num_seq = 0x30;
+ par->state.vidstate = NULL;
save_vga(&(par->state));
}
@@ -947,12 +947,36 @@ static struct fb_ops arkfb_ops = {
/* ------------------------------------------------------------------------- */
+static void __devinit ark_init_vgastate(struct pci_dev *dev, struct vgastate *state)
+{
+ struct pci_bus_region bus_reg;
+ struct resource vga_res;
+
+ bus_reg.start = 0;
+ bus_reg.end = 64 * 1024;
+
+ memset(&vga_res, 0, sizeof(vga_res));
+ vga_res.flags = IORESOURCE_IO;
+
+ pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+
+ state->vgabase = (void __iomem *) vga_res.start;
+
+ bus_reg.start = 0xa0000;
+ bus_reg.end = bus_reg.start + (8 * 8192);
+
+ memset(&vga_res, 0, sizeof(vga_res));
+ vga_res.flags = IORESOURCE_MEM;
+
+ pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+
+ state->membase = vga_res.start;
+ state->memsize = 8 * 8192;
+}
/* PCI probe */
static int __devinit ark_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
- struct pci_bus_region bus_reg;
- struct resource vga_res;
struct fb_info *info;
struct arkfb_info *par;
int rc;
@@ -1008,14 +1032,7 @@ static int __devinit ark_pci_probe(struct pci_dev *dev, const struct pci_device_
goto err_iomap;
}
- bus_reg.start = 0;
- bus_reg.end = 64 * 1024;
-
- vga_res.flags = IORESOURCE_IO;
-
- pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
-
- par->state.vgabase = (void __iomem *) vga_res.start;
+ ark_init_vgastate(dev, &par->state);
/* FIXME get memsize */
regval = vga_rseq(par->state.vgabase, 0x10);
diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c
index 64ef7b3..4b8f215 100644
--- a/drivers/video/s3fb.c
+++ b/drivers/video/s3fb.c
@@ -379,13 +379,13 @@ static int s3fb_open(struct fb_info *info, int user)
mutex_lock(&(par->open_lock));
if (par->ref_count = 0) {
- void __iomem *vgabase = par->state.vgabase;
-
- memset(&(par->state), 0, sizeof(struct vgastate));
- par->state.vgabase = vgabase;
par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS | VGA_SAVE_CMAP;
+ par->state.depth = 0;
+ par->state.num_attr = 0;
par->state.num_crtc = 0x70;
+ par->state.num_gfx = 0;
par->state.num_seq = 0x20;
+ par->state.vidstate = NULL;
save_vga(&(par->state));
}
@@ -929,13 +929,37 @@ static int __devinit s3_identification(struct s3fb_info *par)
return CHIP_UNKNOWN;
}
+static void __devinit s3fb_init_vgastate(struct pci_dev *dev, struct vgastate *state)
+{
+ struct pci_bus_region bus_reg;
+ struct resource vga_res;
+
+ bus_reg.start = 0;
+ bus_reg.end = 64 * 1024;
+
+ memset(&vga_res, 0, sizeof(vga_res));
+ vga_res.flags = IORESOURCE_IO;
+
+ pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+
+ state->vgabase = (void __iomem *) vga_res.start;
+
+ bus_reg.start = 0xa0000;
+ bus_reg.end = bus_reg.start + (8 * 8192);
+
+ memset(&vga_res, 0, sizeof(vga_res));
+ vga_res.flags = IORESOURCE_MEM;
+
+ pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+
+ state->membase = vga_res.start;
+ state->memsize = 8 * 8192;
+}
/* PCI probe */
static int __devinit s3_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
- struct pci_bus_region bus_reg;
- struct resource vga_res;
struct fb_info *info;
struct s3fb_info *par;
int rc;
@@ -985,14 +1009,7 @@ static int __devinit s3_pci_probe(struct pci_dev *dev, const struct pci_device_i
goto err_iomap;
}
- bus_reg.start = 0;
- bus_reg.end = 64 * 1024;
-
- vga_res.flags = IORESOURCE_IO;
-
- pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
-
- par->state.vgabase = (void __iomem *) vga_res.start;
+ s3fb_init_vgastate(dev, &par->state);
/* Unlock regs */
cr38 = vga_rcrt(par->state.vgabase, 0x38);
diff --git a/drivers/video/vt8623fb.c b/drivers/video/vt8623fb.c
index 74df7a8..be70c14 100644
--- a/drivers/video/vt8623fb.c
+++ b/drivers/video/vt8623fb.c
@@ -292,13 +292,13 @@ static int vt8623fb_open(struct fb_info *info, int user)
mutex_lock(&(par->open_lock));
if (par->ref_count = 0) {
- void __iomem *vgabase = par->state.vgabase;
-
- memset(&(par->state), 0, sizeof(struct vgastate));
- par->state.vgabase = vgabase;
par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS | VGA_SAVE_CMAP;
+ par->state.depth = 0;
+ par->state.num_attr = 0;
par->state.num_crtc = 0xA2;
+ par->state.num_gfx = 0;
par->state.num_seq = 0x50;
+ par->state.vidstate = NULL;
save_vga(&(par->state));
}
@@ -656,13 +656,37 @@ static struct fb_ops vt8623fb_ops = {
.fb_get_caps = svga_get_caps,
};
+static void __devinit vt8623_init_vgastate(struct pci_dev *dev, struct vgastate *state)
+{
+ struct pci_bus_region bus_reg;
+ struct resource vga_res;
+
+ bus_reg.start = 0;
+ bus_reg.end = 64 * 1024;
+
+ memset(&vga_res, 0, sizeof(vga_res));
+ vga_res.flags = IORESOURCE_IO;
+
+ pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+
+ state->vgabase = (void __iomem *) vga_res.start;
+
+ bus_reg.start = 0xa0000;
+ bus_reg.end = bus_reg.start + (8 * 8192);
+
+ memset(&vga_res, 0, sizeof(vga_res));
+ vga_res.flags = IORESOURCE_MEM;
+
+ pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+
+ state->membase = vga_res.start;
+ state->memsize = 8 * 8192;
+}
/* PCI probe */
static int __devinit vt8623_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
- struct pci_bus_region bus_reg;
- struct resource vga_res;
struct fb_info *info;
struct vt8623fb_info *par;
unsigned int memsize1, memsize2;
@@ -721,14 +745,7 @@ static int __devinit vt8623_pci_probe(struct pci_dev *dev, const struct pci_devi
goto err_iomap_2;
}
- bus_reg.start = 0;
- bus_reg.end = 64 * 1024;
-
- vga_res.flags = IORESOURCE_IO;
-
- pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
-
- par->state.vgabase = (void __iomem *) vga_res.start;
+ vt8623_init_vgastate(dev, &par->state);
/* Find how many physical memory there is on card */
memsize1 = (vga_rseq(par->state.vgabase, 0x34) + 1) >> 1;
^ permalink raw reply related
* Re: [PATCH 05/16] s3c2410fb: don't treat NULL clk as an error
From: Paul Mundt @ 2011-01-12 6:00 UTC (permalink / raw)
To: Jamie Iles; +Cc: linux-kernel, Vincent Sanders, linux-fbdev
In-Reply-To: <1294749833-32019-6-git-send-email-jamie@jamieiles.com>
On Tue, Jan 11, 2011 at 12:43:42PM +0000, Jamie Iles wrote:
> clk_get() returns a struct clk cookie to the driver and some platforms
> may return NULL if they only support a single clock. clk_get() has only
> failed if it returns a ERR_PTR() encoded pointer.
>
> Cc: Vincent Sanders <support@simtec.co.uk>
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 06/16] nuc900fb: don't treat NULL clk as an error
From: Paul Mundt @ 2011-01-12 6:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTingg+wm8jy4kRL=ubLFrCDXq17jZQkD3v3M4h+Y@mail.gmail.com>
On Wed, Jan 12, 2011 at 09:24:47AM +0800, Wan ZongShun wrote:
> 2011/1/11 Jamie Iles <jamie@jamieiles.com>:
> > clk_get() returns a struct clk cookie to the driver and some platforms
> > may return NULL if they only support a single clock. ??clk_get() has only
> > failed if it returns a ERR_PTR() encoded pointer.
> >
> > Cc: Wan ZongShun <mcuos.com@gmail.com>
> > Cc: linux-fbdev@vger.kernel.org
> > Signed-off-by: Jamie Iles <jamie@jamieiles.com>
>
> Thanks for your patch.
>
> Acked-by: Wan ZongShun <mcuos.com@gmail.com>
>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2 v2] Cleaning up modedb file
From: Paul Mundt @ 2011-01-12 6:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB032340206C@dbde02.ent.ti.com>
On Tue, Jan 11, 2011 at 07:56:32PM +0530, Janorkar, Mayuresh wrote:
> From dc070372a63c83b579259938edbed6307dfd7613 Mon Sep 17 00:00:00 2001
> From: Mayuresh Janorkar <mayur@ti.com>
> Date: Tue, 11 Jan 2011 19:54:03 +0530
> Subject: [PATCH 1/2 v2] Cleaning up modedb file
>
> A part of file: drivers/video/modedb.c was not as per the coding guidelines.
>
> The cleanup includes:
> 1) Converting spcaes to tabs
> 2) Adding spaces on either sides of "|" operator
>
> Signed-off-by: Mayuresh Janorkar <mayur@ti.com>
I'm still not sure I really see the point, but it doesn't really hurt
anything, so I've applied it.
^ permalink raw reply
* Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI
From: Ondrej Zary @ 2011-01-12 7:17 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111.154846.233419170.davem@davemloft.net>
On Wednesday 12 January 2011, David Miller wrote:
> This patch set makes sure that FB drivers for PCI devices utilizing
> the svgalib interfaces work on multi-domain PCI architectures.
>
> Basically this amounts to making sure that the vgastate->vgabase
> __iomem pointer makes it way into every interfaces and gets used
> by all of the I/O access calls.
>
> All of arkfb, s3fb, and vt8623fb have been converted.
Great, I was thinking about something like this when looking at s3fb code and
wondering how it can be extended to work with secondary cards (not
initialized by BIOS). I'll test this with arkfb and s3fb.
--
Ondrej Zary
^ permalink raw reply
* [PATCH] video: move SH_MIPI_DSI/SH_LCD_MIPI_DSI to the top of menu
From: Dmitry Eremin-Solenikov @ 2011-01-12 15:19 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel
Kconfig entries SH_MIPI_DSI and SH_LCD_MIPI_DSI while being invisible to
the user, broke the FrameBuffer menu (at least in menuconfig), as they
aren't depending on respective menuconfig item (FB). In result several
items got moved to the main "Graphics support" menu. Move these two
problematic items to the top of drivers/video/Kbuild to restore nice
display of FB menu.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/video/Kconfig | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 27c1fb4..055e1a7 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -11,6 +11,13 @@ config HAVE_FB_ATMEL
config HAVE_FB_IMX
bool
+config SH_MIPI_DSI
+ tristate
+ depends on (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
+
+config SH_LCD_MIPI_DSI
+ bool
+
source "drivers/char/agp/Kconfig"
source "drivers/gpu/vga/Kconfig"
@@ -1898,13 +1905,6 @@ config FB_W100
If unsure, say N.
-config SH_MIPI_DSI
- tristate
- depends on (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
-
-config SH_LCD_MIPI_DSI
- bool
-
config FB_SH_MOBILE_LCDC
tristate "SuperH Mobile LCDC framebuffer support"
depends on FB && (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
--
1.7.2.3
^ permalink raw reply related
* [PATCH] fbdev: Implement simple blanking in pseudocolor modes for
From: Alexey Charkov @ 2011-01-12 22:14 UTC (permalink / raw)
To: Paul Mundt; +Cc: linux-fbdev, linux-kernel, vt8500-wm8505-linux-kernel
Implement simple blanking in pseudocolor modes for vt8500lcdfb
This follows the style of some other in-tree drivers by just setting
the hardware palette colors to all black. True Color modes are not
affected, but this at least allows to run xf86-video-fbdev without
errors due to blanking being unimplemented.
Signed-off-by: Alexey Charkov <alchark@gmail.com>
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 7617f12..0e120d6 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -215,6 +215,33 @@ static int vt8500lcd_pan_display(struct fb_var_screeninfo *var,
return 0;
}
+/*
+ * vt8500lcd_blank():
+ * Blank the display by setting all palette values to zero. Note,
+ * True Color modes do not really use the palette, so this will not
+ * blank the display in all modes.
+ */
+static int vt8500lcd_blank(int blank, struct fb_info *info)
+{
+ int i;
+
+ switch (blank) {
+ case FB_BLANK_POWERDOWN:
+ case FB_BLANK_VSYNC_SUSPEND:
+ case FB_BLANK_HSYNC_SUSPEND:
+ case FB_BLANK_NORMAL:
+ if (info->fix.visual = FB_VISUAL_PSEUDOCOLOR ||
+ info->fix.visual = FB_VISUAL_STATIC_PSEUDOCOLOR)
+ for (i = 0; i < 256; i++)
+ vt8500lcd_setcolreg(i, 0, 0, 0, 0, info);
+ case FB_BLANK_UNBLANK:
+ if (info->fix.visual = FB_VISUAL_PSEUDOCOLOR ||
+ info->fix.visual = FB_VISUAL_STATIC_PSEUDOCOLOR)
+ fb_set_cmap(&info->cmap, info);
+ }
+ return 0;
+}
+
static struct fb_ops vt8500lcd_ops = {
.owner = THIS_MODULE,
.fb_set_par = vt8500lcd_set_par,
@@ -225,6 +252,7 @@ static struct fb_ops vt8500lcd_ops = {
.fb_sync = wmt_ge_sync,
.fb_ioctl = vt8500lcd_ioctl,
.fb_pan_display = vt8500lcd_pan_display,
+ .fb_blank = vt8500lcd_blank,
};
static irqreturn_t vt8500lcd_handle_irq(int irq, void *dev_id)
^ permalink raw reply related
* Re: [PATCH 0/22] Make SVGA oriented FBs work on multi-domain PCI
From: Alex Buell @ 2011-01-12 23:43 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111.154846.233419170.davem@davemloft.net>
On Tue, 2011-01-11 at 20:51 -0800, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 11 Jan 2011 20:27:19 -0800 (PST)
>
> > From: David Miller <davem@davemloft.net>
> > Date: Tue, 11 Jan 2011 18:29:45 -0800 (PST)
> >
> >> Oh... I see what is happening. save_vga() sets this value using it's
> >> own heuristics, when VGA_SAVE_FONTS is set, but in a way that won't
> >> work in multi-domain PCI situations.
> >>
> >> So we need to set this up in the drivers just like we do for the
> >> 'vgabase' member.
> >>
> >> I'll work on some patches to fix this.
> >
> > Alex, give this a try.
>
> Sorry, forgot the patch, here it is :-)
>
> diff --git a/drivers/video/arkfb.c b/drivers/video/arkfb.c
[ snip ]
> /* Find how many physical memory there is on card */
> memsize1 = (vga_rseq(par->state.vgabase, 0x34) + 1) >> 1;
It's a step in the right direction. With this patch added to the
svgalib/vgastate modules, it doesn't crash as bad as it used to. The
errors in the logs looks like it's accessing the PCI registers, don't
really understand what it's complaining about though:
Jan 12 21:53:10 sodium kernel: fb1: S3 Virge/GX on 0000:00:03.0, 6 MB RAM, 14 MHz MCLK
Jan 12 21:53:18 sodium kernel: eth0: Link down, cable problem?
Jan 12 21:53:27 sodium pci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700pci@8,pci@8,700000: PCter Aborpci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0080] was_block(0) space(Memory)
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI AFAR [00000000000a00a8]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Secondary errors [(Master Abort)]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0040] was_block(0) space(Memory)
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI AFAR [00000000000a00b8]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Secondary errors [(Master Abort)]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0008] was_block(0) space(Memory)
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI AFAR [00000000000a00c8]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Secondary errors [(Master Abort)]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0004] was_block(0) space(Memory)
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI AFAR [00000000000a00d8]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Secondary errors [(Master Abort)]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0002] was_block(0) space(Memory)
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI AFAR [00000000000a00e8]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Secondary errors [(Master Abort)]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0080] was_block(0) space(Memory)
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI AFAR [00000000000a00f0]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Secondary errors [(Master Abort)]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: PCI Error, primary error type[Master Abort]
Jan 12 21:53:27 sodium kernel: /pci@8,700000: bytemask[0010] was_block(0) space(Memory)
I simply did the following:
fbset -i -fb /dev/fb1 (which correctly printed the mode information)
fbset -fb /dev/fb1 -g 1024 768 1024 768 8
at this point it crashed, nothing in the logs, not even a
CTRL-ALT-SYSRQ-S/B could get it out of the deep hole it'd dug for
itself.
--
Tactical Nuclear Kittens
^ permalink raw reply
* Re: [PATCH] fbdev: Implement simple blanking in pseudocolor modes for vt8500lcdfb
From: Paul Mundt @ 2011-01-13 4:09 UTC (permalink / raw)
To: Alexey Charkov; +Cc: linux-fbdev, linux-kernel, vt8500-wm8505-linux-kernel
In-Reply-To: <20110112221443.GA574@alchark-u3s>
On Thu, Jan 13, 2011 at 01:14:44AM +0300, Alexey Charkov wrote:
> Implement simple blanking in pseudocolor modes for vt8500lcdfb
>
> This follows the style of some other in-tree drivers by just setting
> the hardware palette colors to all black. True Color modes are not
> affected, but this at least allows to run xf86-video-fbdev without
> errors due to blanking being unimplemented.
>
> Signed-off-by: Alexey Charkov <alchark@gmail.com>
>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] video: move SH_MIPI_DSI/SH_LCD_MIPI_DSI to the top of menu
From: Paul Mundt @ 2011-01-13 4:10 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <1294845575-4508-1-git-send-email-dbaryshkov@gmail.com>
On Wed, Jan 12, 2011 at 06:19:35PM +0300, Dmitry Eremin-Solenikov wrote:
> Kconfig entries SH_MIPI_DSI and SH_LCD_MIPI_DSI while being invisible to
> the user, broke the FrameBuffer menu (at least in menuconfig), as they
> aren't depending on respective menuconfig item (FB). In result several
> items got moved to the main "Graphics support" menu. Move these two
> problematic items to the top of drivers/video/Kbuild to restore nice
> display of FB menu.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] radeonfb: Let hwmon driver probe the "monid" I2C bus
From: Paul Mundt @ 2011-01-13 4:11 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111162352.5a634e9e@endymion.delvare>
On Tue, Jan 11, 2011 at 04:23:52PM +0100, Jean Delvare wrote:
> Some Radeon cards have an I2C-based thermal sensor chip connected to
> the "monid" I2C bus. Set the I2C probing class of this bus properly so
> that hwmon drivers can detect devices on it and bind to them.
>
> This closes kernel.org bug #26172.
>
> Reported-by: Alexander Goomenyuk <emerg.reanimator@gmail.com>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> Ben, please let me know if you have any objection, and if you don't,
> please let me know if you want to pick this patch or if you prefer that
> I push it through my hwmon tree.
>
I can take this through the fbdev tree if Ben's happy with it.
^ permalink raw reply
* [PATCH] drivers: ld9040 amoled driver support
From: Donghwa Lee @ 2011-01-13 4:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1292826187-17758-1-git-send-email-dh09.lee@samsung.com>
This patch is ld9040 amoled panel driver.
I resend because there was no comment.
It is similar to s6e63m0 panel driver and use spi gpio to send panel
information.
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
---
drivers/video/backlight/Kconfig | 8 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/ld9040.c | 927 ++++++++++++++++++++++++++++++++
drivers/video/backlight/ld9040_gamma.h | 203 +++++++
4 files changed, 1139 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/backlight/ld9040.c
create mode 100644 drivers/video/backlight/ld9040_gamma.h
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index e54a337..db3d123 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -109,6 +109,14 @@ config LCD_S6E63M0
If you have an S6E63M0 LCD Panel, say Y to enable its
LCD control driver.
+config LCD_LD9040
+ tristate "LD9040 AMOLED LCD Driver"
+ depends on SPI && BACKLIGHT_CLASS_DEVICE
+ default n
+ help
+ If you have an LD9040 Panel, say Y to enable its
+ control driver.
+
endif # LCD_CLASS_DEVICE
#
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 44c0f81..457996c 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_LCD_VGG2432A4) += vgg2432a4.o
obj-$(CONFIG_LCD_TDO24M) += tdo24m.o
obj-$(CONFIG_LCD_TOSA) += tosa_lcd.o
obj-$(CONFIG_LCD_S6E63M0) += s6e63m0.o
+obj-$(CONFIG_LCD_LD9040) += ld9040.o
obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE) += backlight.o
obj-$(CONFIG_BACKLIGHT_ATMEL_PWM) += atmel-pwm-bl.o
diff --git a/drivers/video/backlight/ld9040.c b/drivers/video/backlight/ld9040.c
new file mode 100644
index 0000000..248f42f
--- /dev/null
+++ b/drivers/video/backlight/ld9040.c
@@ -0,0 +1,927 @@
+/*
+ * ld9040 AMOLED LCD panel driver.
+ *
+ * Author: Donghwa Lee <dh09.lee@samsung.com>
+ *
+ * Derived from drivers/video/backlight/s6e63m0.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include <linux/wait.h>
+#include <linux/fb.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/spi/spi.h>
+#include <linux/irq.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/lcd.h>
+#include <linux/backlight.h>
+
+#include "ld9040_gamma.h"
+
+#define SLEEPMSEC 0x1000
+#define ENDDEF 0x2000
+#define DEFMASK 0xFF00
+#define COMMAND_ONLY 0xFE
+#define DATA_ONLY 0xFF
+
+#define MIN_BRIGHTNESS 0
+#define MAX_BRIGHTNESS 24
+#define POWER_IS_ON(pwr) ((pwr) <= FB_BLANK_NORMAL)
+
+struct ld9040 {
+ struct device *dev;
+ struct spi_device *spi;
+ unsigned int power;
+ unsigned int gamma_mode;
+ unsigned int current_brightness;
+ unsigned int gamma_table_count;
+
+ struct lcd_device *ld;
+ struct backlight_device *bd;
+ struct lcd_platform_data *lcd_pd;
+};
+
+static const unsigned short SEQ_SWRESET[] = {
+ 0x01, COMMAND_ONLY,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_USER_SETTING[] = {
+ 0xF0, 0x5A,
+
+ DATA_ONLY, 0x5A,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_ELVSS_ON[] = {
+ 0xB1, 0x0D,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x16,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_GTCON[] = {
+ 0xF7, 0x09,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_PANEL_CONDITION[] = {
+ 0xF8, 0x05,
+
+ DATA_ONLY, 0x65,
+ DATA_ONLY, 0x96,
+ DATA_ONLY, 0x71,
+ DATA_ONLY, 0x7D,
+ DATA_ONLY, 0x19,
+ DATA_ONLY, 0x3B,
+ DATA_ONLY, 0x0D,
+ DATA_ONLY, 0x19,
+ DATA_ONLY, 0x7E,
+ DATA_ONLY, 0x0D,
+ DATA_ONLY, 0xE2,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x7E,
+ DATA_ONLY, 0x7D,
+ DATA_ONLY, 0x07,
+ DATA_ONLY, 0x07,
+ DATA_ONLY, 0x20,
+ DATA_ONLY, 0x20,
+ DATA_ONLY, 0x20,
+ DATA_ONLY, 0x02,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_GAMMA_SET1[] = {
+ 0xF9, 0x00,
+
+ DATA_ONLY, 0xA7,
+ DATA_ONLY, 0xB4,
+ DATA_ONLY, 0xAE,
+ DATA_ONLY, 0xBF,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x91,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0xB2,
+ DATA_ONLY, 0xB4,
+ DATA_ONLY, 0xAA,
+ DATA_ONLY, 0xBB,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0xAC,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0xB3,
+ DATA_ONLY, 0xB1,
+ DATA_ONLY, 0xAA,
+ DATA_ONLY, 0xBC,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0xB3,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_GAMMA_CTRL[] = {
+ 0xFB, 0x02,
+
+ DATA_ONLY, 0x5A,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_GAMMA_START[] = {
+ 0xF9, COMMAND_ONLY,
+
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_APON[] = {
+ 0xF3, 0x00,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x0A,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_DISPCTL[] = {
+ 0xF2, 0x02,
+
+ DATA_ONLY, 0x08,
+ DATA_ONLY, 0x08,
+ DATA_ONLY, 0x10,
+ DATA_ONLY, 0x10,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_MANPWR[] = {
+ 0xB0, 0x04,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_PWR_CTRL[] = {
+ 0xF4, 0x0A,
+
+ DATA_ONLY, 0x87,
+ DATA_ONLY, 0x25,
+ DATA_ONLY, 0x6A,
+ DATA_ONLY, 0x44,
+ DATA_ONLY, 0x02,
+ DATA_ONLY, 0x88,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_SLPOUT[] = {
+ 0x11, COMMAND_ONLY,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_SLPIN[] = {
+ 0x10, COMMAND_ONLY,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_DISPON[] = {
+ 0x29, COMMAND_ONLY,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_DISPOFF[] = {
+ 0x28, COMMAND_ONLY,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VCI1_1ST_EN[] = {
+ 0xF3, 0x10,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VL1_EN[] = {
+ 0xF3, 0x11,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VL2_EN[] = {
+ 0xF3, 0x13,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VCI1_2ND_EN[] = {
+ 0xF3, 0x33,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VL3_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VREG1_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0x01,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VGH_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0x11,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VGL_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0x31,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VMOS_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xB1,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VINT_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xF1,
+ /* DATA_ONLY, 0x71, VMOS/VBL/VBH not used */
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VBH_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xF9,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VBL_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xFD,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_GAM_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xFF,
+ /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_SD_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xFF,
+ /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
+ DATA_ONLY, 0x80,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_GLS_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xFF,
+ /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
+ DATA_ONLY, 0x81,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_ELS_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xFF,
+ /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
+ DATA_ONLY, 0x83,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_EL_ON[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xFF,
+ /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
+ DATA_ONLY, 0x87,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
+ ENDDEF, 0x00
+};
+
+static int ld9040_spi_write_byte(struct ld9040 *lcd, int addr, int data)
+{
+ u16 buf[1];
+ struct spi_message msg;
+
+ struct spi_transfer xfer = {
+ .len = 2,
+ .tx_buf = buf,
+ };
+
+ buf[0] = (addr << 8) | data;
+
+ spi_message_init(&msg);
+ spi_message_add_tail(&xfer, &msg);
+
+ return spi_sync(lcd->spi, &msg);
+}
+
+static int ld9040_spi_write(struct ld9040 *lcd, unsigned char address,
+ unsigned char command)
+{
+ int ret = 0;
+
+ if (address != DATA_ONLY)
+ ret = ld9040_spi_write_byte(lcd, 0x0, address);
+ if (command != COMMAND_ONLY)
+ ret = ld9040_spi_write_byte(lcd, 0x1, command);
+
+ return ret;
+}
+
+static int ld9040_panel_send_sequence(struct ld9040 *lcd,
+ const unsigned short *wbuf)
+{
+ int ret = 0, i = 0;
+
+ while ((wbuf[i] & DEFMASK) != ENDDEF) {
+ if ((wbuf[i] & DEFMASK) != SLEEPMSEC) {
+ ret = ld9040_spi_write(lcd, wbuf[i], wbuf[i+1]);
+ if (ret)
+ break;
+ } else
+ udelay(wbuf[i+1]*1000);
+ i += 2;
+ }
+
+ return ret;
+}
+
+static int _ld9040_gamma_ctl(struct ld9040 *lcd, const unsigned int *gamma)
+{
+ unsigned int i = 0;
+ int ret = 0;
+
+ /* start gamma table updating. */
+ ret = ld9040_panel_send_sequence(lcd, SEQ_GAMMA_START);
+ if (ret) {
+ dev_err(lcd->dev, "failed to disable gamma table updating.\n");
+ goto gamma_err;
+ }
+
+ for (i = 0 ; i < GAMMA_TABLE_COUNT; i++) {
+ ret = ld9040_spi_write(lcd, DATA_ONLY, gamma[i]);
+ if (ret) {
+ dev_err(lcd->dev, "failed to set gamma table.\n");
+ goto gamma_err;
+ }
+ }
+
+ /* update gamma table. */
+ ret = ld9040_panel_send_sequence(lcd, SEQ_GAMMA_CTRL);
+ if (ret)
+ dev_err(lcd->dev, "failed to update gamma table.\n");
+
+gamma_err:
+ return ret;
+}
+
+static int ld9040_gamma_ctl(struct ld9040 *lcd, int gamma)
+{
+ int ret = 0;
+
+ ret = _ld9040_gamma_ctl(lcd, gamma_table.gamma_22_table[gamma]);
+
+ return ret;
+}
+
+
+static int ld9040_ldi_init(struct ld9040 *lcd)
+{
+ int ret, i;
+ const unsigned short *init_seq[] = {
+ SEQ_USER_SETTING,
+ SEQ_PANEL_CONDITION,
+ SEQ_DISPCTL,
+ SEQ_MANPWR,
+ SEQ_PWR_CTRL,
+ SEQ_ELVSS_ON,
+ SEQ_GTCON,
+ SEQ_GAMMA_SET1,
+ SEQ_GAMMA_CTRL,
+ SEQ_SLPOUT,
+ };
+
+ for (i = 0; i < ARRAY_SIZE(init_seq); i++) {
+ ret = ld9040_panel_send_sequence(lcd, init_seq[i]);
+ /* workaround: minimum delay time for transferring CMD */
+ udelay(300);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+static int ld9040_ldi_enable(struct ld9040 *lcd)
+{
+ int ret = 0;
+
+ ret = ld9040_panel_send_sequence(lcd, SEQ_DISPON);
+
+ return ret;
+}
+
+static int ld9040_ldi_disable(struct ld9040 *lcd)
+{
+ int ret;
+
+ ret = ld9040_panel_send_sequence(lcd, SEQ_DISPOFF);
+ ret = ld9040_panel_send_sequence(lcd, SEQ_SLPIN);
+
+ return ret;
+}
+
+static int ld9040_power_on(struct ld9040 *lcd)
+{
+ int ret = 0;
+ struct lcd_platform_data *pd = NULL;
+ pd = lcd->lcd_pd;
+ if (!pd) {
+ dev_err(lcd->dev, "platform data is NULL.\n");
+ return -EFAULT;
+ }
+
+ if (!pd->power_on) {
+ dev_err(lcd->dev, "power_on is NULL.\n");
+ return -EFAULT;
+ } else {
+ pd->power_on(lcd->ld, 1);
+ mdelay(pd->power_on_delay);
+ }
+
+ if (!pd->reset) {
+ dev_err(lcd->dev, "reset is NULL.\n");
+ return -EFAULT;
+ } else {
+ pd->reset(lcd->ld);
+ mdelay(pd->reset_delay);
+ }
+
+ ret = ld9040_ldi_init(lcd);
+ if (ret) {
+ dev_err(lcd->dev, "failed to initialize ldi.\n");
+ return ret;
+ }
+
+ ret = ld9040_ldi_enable(lcd);
+ if (ret) {
+ dev_err(lcd->dev, "failed to enable ldi.\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ld9040_power_off(struct ld9040 *lcd)
+{
+ int ret = 0;
+ struct lcd_platform_data *pd = NULL;
+
+ pd = lcd->lcd_pd;
+ if (!pd) {
+ dev_err(lcd->dev, "platform data is NULL.\n");
+ return -EFAULT;
+ }
+
+ ret = ld9040_ldi_disable(lcd);
+ if (ret) {
+ dev_err(lcd->dev, "lcd setting failed.\n");
+ return -EIO;
+ }
+
+ mdelay(pd->power_off_delay);
+
+ if (!pd->power_on) {
+ dev_err(lcd->dev, "power_on is NULL.\n");
+ return -EFAULT;
+ } else
+ pd->power_on(lcd->ld, 0);
+
+ return 0;
+}
+
+static int ld9040_power(struct ld9040 *lcd, int power)
+{
+ int ret = 0;
+
+ if (POWER_IS_ON(power) && !POWER_IS_ON(lcd->power))
+ ret = ld9040_power_on(lcd);
+ else if (!POWER_IS_ON(power) && POWER_IS_ON(lcd->power))
+ ret = ld9040_power_off(lcd);
+
+ if (!ret)
+ lcd->power = power;
+
+ return ret;
+}
+
+static int ld9040_set_power(struct lcd_device *ld, int power)
+{
+ struct ld9040 *lcd = lcd_get_data(ld);
+
+ if (power != FB_BLANK_UNBLANK && power != FB_BLANK_POWERDOWN &&
+ power != FB_BLANK_NORMAL) {
+ dev_err(lcd->dev, "power value should be 0, 1 or 4.\n");
+ return -EINVAL;
+ }
+
+ return ld9040_power(lcd, power);
+}
+
+static int ld9040_get_power(struct lcd_device *ld)
+{
+ struct ld9040 *lcd = lcd_get_data(ld);
+
+ return lcd->power;
+}
+
+static int ld9040_get_brightness(struct backlight_device *bd)
+{
+ return bd->props.brightness;
+}
+
+static int ld9040_set_brightness(struct backlight_device *bd)
+{
+ int ret = 0, brightness = bd->props.brightness;
+ struct ld9040 *lcd = bl_get_data(bd);
+
+ if (brightness < MIN_BRIGHTNESS ||
+ brightness > bd->props.max_brightness) {
+ dev_err(&bd->dev, "lcd brightness should be %d to %d.\n",
+ MIN_BRIGHTNESS, MAX_BRIGHTNESS);
+ return -EINVAL;
+ }
+
+ ret = ld9040_gamma_ctl(lcd, bd->props.brightness);
+ if (ret) {
+ dev_err(&bd->dev, "lcd brightness setting failed.\n");
+ return -EIO;
+ }
+
+ return ret;
+}
+
+static struct lcd_ops ld9040_lcd_ops = {
+ .set_power = ld9040_set_power,
+ .get_power = ld9040_get_power,
+};
+
+static const struct backlight_ops ld9040_backlight_ops = {
+ .get_brightness = ld9040_get_brightness,
+ .update_status = ld9040_set_brightness,
+};
+
+static ssize_t ld9040_sysfs_show_gamma_mode(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct ld9040 *lcd = dev_get_drvdata(dev);
+ char temp[10];
+
+ switch (lcd->gamma_mode) {
+ case 0:
+ sprintf(temp, "2.2 mode\n");
+ strcat(buf, temp);
+ break;
+ default:
+ dev_info(dev, "gamma mode could be 0:2.2\n");
+ break;
+ }
+
+ return strlen(buf);
+}
+
+static ssize_t ld9040_sysfs_store_gamma_mode(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct ld9040 *lcd = dev_get_drvdata(dev);
+ struct backlight_device *bd = NULL;
+ int brightness, rc;
+
+ rc = strict_strtoul(buf, 0, (unsigned long *)&lcd->gamma_mode);
+ if (rc < 0)
+ return rc;
+
+ bd = lcd->bd;
+
+ brightness = bd->props.brightness;
+
+ switch (lcd->gamma_mode) {
+ case 0:
+ _ld9040_gamma_ctl(lcd, gamma_table.gamma_22_table[brightness]);
+ break;
+ default:
+ dev_info(dev, "gamma mode could be 0:2.2\n");
+ _ld9040_gamma_ctl(lcd, gamma_table.gamma_22_table[brightness]);
+ break;
+ }
+ return len;
+}
+
+static DEVICE_ATTR(gamma_mode, 0644,
+ ld9040_sysfs_show_gamma_mode, ld9040_sysfs_store_gamma_mode);
+
+static ssize_t ld9040_sysfs_show_gamma_table(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct ld9040 *lcd = dev_get_drvdata(dev);
+ char temp[3];
+
+ sprintf(temp, "%d\n", lcd->gamma_table_count);
+ strcpy(buf, temp);
+
+ return strlen(buf);
+}
+
+static DEVICE_ATTR(gamma_table, 0644,
+ ld9040_sysfs_show_gamma_table, NULL);
+
+static int ld9040_probe(struct spi_device *spi)
+{
+ int ret = 0;
+ struct ld9040 *lcd = NULL;
+ struct lcd_device *ld = NULL;
+ struct backlight_device *bd = NULL;
+
+ lcd = kzalloc(sizeof(struct ld9040), GFP_KERNEL);
+ if (!lcd)
+ return -ENOMEM;
+
+ /* ld9040 lcd panel uses 3-wire 9bits SPI Mode. */
+ spi->bits_per_word = 9;
+
+ ret = spi_setup(spi);
+ if (ret < 0) {
+ dev_err(&spi->dev, "spi setup failed.\n");
+ goto out_free_lcd;
+ }
+
+ lcd->spi = spi;
+ lcd->dev = &spi->dev;
+
+ lcd->lcd_pd = (struct lcd_platform_data *)spi->dev.platform_data;
+ if (!lcd->lcd_pd) {
+ dev_err(&spi->dev, "platform data is NULL.\n");
+ goto out_free_lcd;
+ }
+
+ ld = lcd_device_register("ld9040", &spi->dev, lcd, &ld9040_lcd_ops);
+ if (IS_ERR(ld)) {
+ ret = PTR_ERR(ld);
+ goto out_free_lcd;
+ }
+
+ lcd->ld = ld;
+
+ bd = backlight_device_register("ld9040-bl", &spi->dev,
+ lcd, &ld9040_backlight_ops, NULL);
+ if (IS_ERR(ld)) {
+ ret = PTR_ERR(ld);
+ goto out_free_lcd;
+ }
+
+ bd->props.max_brightness = MAX_BRIGHTNESS;
+ bd->props.brightness = MAX_BRIGHTNESS;
+ lcd->bd = bd;
+
+ /*
+ * it gets gamma table count available so it gets user
+ * know that.
+ */
+ lcd->gamma_table_count + sizeof(gamma_table) / (MAX_GAMMA_LEVEL * sizeof(int));
+
+ ret = device_create_file(&(spi->dev), &dev_attr_gamma_mode);
+ if (ret < 0)
+ dev_err(&(spi->dev), "failed to add sysfs entries\n");
+
+ ret = device_create_file(&(spi->dev), &dev_attr_gamma_table);
+ if (ret < 0)
+ dev_err(&(spi->dev), "failed to add sysfs entries\n");
+
+ /*
+ * if lcd panel was on from bootloader like u-boot then
+ * do not lcd on.
+ */
+ if (!lcd->lcd_pd->lcd_enabled) {
+ /*
+ * if lcd panel was off from bootloader then
+ * current lcd status is powerdown and then
+ * it enables lcd panel.
+ */
+ lcd->power = FB_BLANK_POWERDOWN;
+
+ ld9040_power(lcd, FB_BLANK_UNBLANK);
+ } else
+ lcd->power = FB_BLANK_UNBLANK;
+
+ dev_set_drvdata(&spi->dev, lcd);
+
+ dev_info(&spi->dev, "ld9040 panel driver has been probed.\n");
+ return 0;
+
+out_free_lcd:
+ kfree(lcd);
+ return ret;
+}
+
+static int __devexit ld9040_remove(struct spi_device *spi)
+{
+ struct ld9040 *lcd = dev_get_drvdata(&spi->dev);
+
+ ld9040_power(lcd, FB_BLANK_POWERDOWN);
+ lcd_device_unregister(lcd->ld);
+ kfree(lcd);
+
+ return 0;
+}
+
+#if defined(CONFIG_PM)
+unsigned int beforepower;
+
+static int ld9040_suspend(struct spi_device *spi, pm_message_t mesg)
+{
+ int ret = 0;
+ struct ld9040 *lcd = dev_get_drvdata(&spi->dev);
+
+ dev_dbg(&spi->dev, "lcd->power = %d\n", lcd->power);
+
+ beforepower = lcd->power;
+
+ /*
+ * when lcd panel is suspend, lcd panel becomes off
+ * regardless of status.
+ */
+ ret = ld9040_power(lcd, FB_BLANK_POWERDOWN);
+
+ return ret;
+}
+
+static int ld9040_resume(struct spi_device *spi)
+{
+ int ret = 0;
+ struct ld9040 *lcd = dev_get_drvdata(&spi->dev);
+
+ /*
+ * after suspended, if lcd panel status is FB_BLANK_UNBLANK
+ * (at that time, power is FB_BLANK_UNBLANK) then
+ * it changes that status to FB_BLANK_POWERDOWN to get lcd on.
+ */
+ if (beforepower = FB_BLANK_UNBLANK)
+ lcd->power = FB_BLANK_POWERDOWN;
+
+ dev_dbg(&spi->dev, "power = %d\n", beforepower);
+
+ ret = ld9040_power(lcd, beforepower);
+
+ return ret;
+}
+#else
+#define ld9040_suspend NULL
+#define ld9040_resume NULL
+#endif
+
+/* Power down all displays on reboot, poweroff or halt. */
+static void ld9040_shutdown(struct spi_device *spi)
+{
+ struct ld9040 *lcd = dev_get_drvdata(&spi->dev);
+
+ ld9040_power(lcd, FB_BLANK_POWERDOWN);
+}
+
+static struct spi_driver ld9040_driver = {
+ .driver = {
+ .name = "ld9040",
+ .bus = &spi_bus_type,
+ .owner = THIS_MODULE,
+ },
+ .probe = ld9040_probe,
+ .remove = __devexit_p(ld9040_remove),
+ .shutdown = ld9040_shutdown,
+ .suspend = ld9040_suspend,
+ .resume = ld9040_resume,
+};
+
+static int __init ld9040_init(void)
+{
+ return spi_register_driver(&ld9040_driver);
+}
+
+static void __exit ld9040_exit(void)
+{
+ spi_unregister_driver(&ld9040_driver);
+}
+
+module_init(ld9040_init);
+module_exit(ld9040_exit);
+
+MODULE_AUTHOR("Donghwa Lee <dh09.lee@samsung.com>");
+MODULE_DESCRIPTION("ld9040 LCD Driver");
+MODULE_LICENSE("GPL");
+
diff --git a/drivers/video/backlight/ld9040_gamma.h b/drivers/video/backlight/ld9040_gamma.h
new file mode 100644
index 0000000..f199133
--- /dev/null
+++ b/drivers/video/backlight/ld9040_gamma.h
@@ -0,0 +1,203 @@
+/* linux/drivers/video/samsung/ld9040_brightness.h
+ *
+ * Gamma level definitions.
+ *
+ * Copyright (c) 2009 Samsung Electronics
+ * InKi Dae <inki.dae@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#ifndef _ld9040_BRIGHTNESS_H
+#define _ld9040_BRIGHTNESS_H
+
+#define MAX_GAMMA_LEVEL 25
+#define GAMMA_TABLE_COUNT 21
+
+/* gamma value: 2.2 */
+static const unsigned int ld9040_22_300[] = {
+ 0x00, 0xa7, 0xb4, 0xae, 0xbf, 0x00, 0x91,
+ 0x00, 0xb2, 0xb4, 0xaa, 0xbb, 0x00, 0xac,
+ 0x00, 0xb3, 0xb1, 0xaa, 0xbc, 0x00, 0xb3
+};
+
+static const unsigned int ld9040_22_290[] = {
+ 0x00, 0xa9, 0xb7, 0xae, 0xbd, 0x00, 0x89,
+ 0x00, 0xb7, 0xb6, 0xa8, 0xba, 0x00, 0xa4,
+ 0x00, 0xb1, 0xb4, 0xaa, 0xbb, 0x00, 0xaa
+};
+
+static const unsigned int ld9040_22_280[] = {
+ 0x00, 0xa9, 0xb6, 0xad, 0xbf, 0x00, 0x86,
+ 0x00, 0xb8, 0xb5, 0xa8, 0xbc, 0x00, 0xa0,
+ 0x00, 0xb3, 0xb3, 0xa9, 0xbc, 0x00, 0xa7
+};
+
+static const unsigned int ld9040_22_270[] = {
+ 0x00, 0xa8, 0xb8, 0xae, 0xbe, 0x00, 0x84,
+ 0x00, 0xb9, 0xb7, 0xa8, 0xbc, 0x00, 0x9d,
+ 0x00, 0xb2, 0xb5, 0xaa, 0xbc, 0x00, 0xa4
+
+};
+static const unsigned int ld9040_22_260[] = {
+ 0x00, 0xa4, 0xb8, 0xb0, 0xbf, 0x00, 0x80,
+ 0x00, 0xb8, 0xb6, 0xaa, 0xbc, 0x00, 0x9a,
+ 0x00, 0xb0, 0xb5, 0xab, 0xbd, 0x00, 0xa0
+};
+
+static const unsigned int ld9040_22_250[] = {
+ 0x00, 0xa4, 0xb9, 0xaf, 0xc1, 0x00, 0x7d,
+ 0x00, 0xb9, 0xb6, 0xaa, 0xbb, 0x00, 0x97,
+ 0x00, 0xb1, 0xb5, 0xaa, 0xbf, 0x00, 0x9d
+};
+
+static const unsigned int ld9040_22_240[] = {
+ 0x00, 0xa2, 0xb9, 0xaf, 0xc2, 0x00, 0x7a,
+ 0x00, 0xb9, 0xb7, 0xaa, 0xbd, 0x00, 0x94,
+ 0x00, 0xb0, 0xb5, 0xab, 0xbf, 0x00, 0x9a
+};
+
+static const unsigned int ld9040_22_230[] = {
+ 0x00, 0xa0, 0xb9, 0xaf, 0xc3, 0x00, 0x77,
+ 0x00, 0xb9, 0xb7, 0xab, 0xbe, 0x00, 0x90,
+ 0x00, 0xb0, 0xb6, 0xab, 0xbf, 0x00, 0x97
+};
+
+static const unsigned int ld9040_22_220[] = {
+ 0x00, 0x9e, 0xba, 0xb0, 0xc2, 0x00, 0x75,
+ 0x00, 0xb9, 0xb8, 0xab, 0xbe, 0x00, 0x8e,
+ 0x00, 0xb0, 0xb6, 0xac, 0xbf, 0x00, 0x94
+};
+
+static const unsigned int ld9040_22_210[] = {
+ 0x00, 0x9c, 0xb9, 0xb0, 0xc4, 0x00, 0x72,
+ 0x00, 0xb8, 0xb8, 0xac, 0xbf, 0x00, 0x8a,
+ 0x00, 0xb0, 0xb6, 0xac, 0xc0, 0x00, 0x91
+};
+
+static const unsigned int ld9040_22_200[] = {
+ 0x00, 0x9a, 0xba, 0xb1, 0xc4, 0x00, 0x6f,
+ 0x00, 0xb8, 0xb8, 0xad, 0xc0, 0x00, 0x86,
+ 0x00, 0xb0, 0xb7, 0xad, 0xc0, 0x00, 0x8d
+};
+
+static const unsigned int ld9040_22_190[] = {
+ 0x00, 0x97, 0xba, 0xb2, 0xc5, 0x00, 0x6c,
+ 0x00, 0xb8, 0xb8, 0xae, 0xc1, 0x00, 0x82,
+ 0x00, 0xb0, 0xb6, 0xae, 0xc2, 0x00, 0x89
+};
+
+static const unsigned int ld9040_22_180[] = {
+ 0x00, 0x93, 0xba, 0xb3, 0xc5, 0x00, 0x69,
+ 0x00, 0xb8, 0xb9, 0xae, 0xc1, 0x00, 0x7f,
+ 0x00, 0xb0, 0xb6, 0xae, 0xc3, 0x00, 0x85
+};
+
+static const unsigned int ld9040_22_170[] = {
+ 0x00, 0x8b, 0xb9, 0xb3, 0xc7, 0x00, 0x65,
+ 0x00, 0xb7, 0xb8, 0xaf, 0xc3, 0x00, 0x7a,
+ 0x00, 0x80, 0xb6, 0xae, 0xc4, 0x00, 0x81
+};
+
+static const unsigned int ld9040_22_160[] = {
+ 0x00, 0x89, 0xba, 0xb3, 0xc8, 0x00, 0x62,
+ 0x00, 0xb6, 0xba, 0xaf, 0xc3, 0x00, 0x76,
+ 0x00, 0xaf, 0xb7, 0xae, 0xc4, 0x00, 0x7e
+};
+
+static const unsigned int ld9040_22_150[] = {
+ 0x00, 0x82, 0xba, 0xb4, 0xc7, 0x00, 0x5f,
+ 0x00, 0xb5, 0xba, 0xb0, 0xc3, 0x00, 0x72,
+ 0x00, 0xae, 0xb8, 0xb0, 0xc3, 0x00, 0x7a
+};
+
+static const unsigned int ld9040_22_140[] = {
+ 0x00, 0x7b, 0xbb, 0xb4, 0xc8, 0x00, 0x5b,
+ 0x00, 0xb5, 0xba, 0xb1, 0xc4, 0x00, 0x6e,
+ 0x00, 0xae, 0xb9, 0xb0, 0xc5, 0x00, 0x75
+};
+
+static const unsigned int ld9040_22_130[] = {
+ 0x00, 0x71, 0xbb, 0xb5, 0xc8, 0x00, 0x57,
+ 0x00, 0xb5, 0xbb, 0xb0, 0xc5, 0x00, 0x6a,
+ 0x00, 0xae, 0xb9, 0xb1, 0xc6, 0x00, 0x70
+};
+
+static const unsigned int ld9040_22_120[] = {
+ 0x00, 0x47, 0xba, 0xb6, 0xca, 0x00, 0x53,
+ 0x00, 0xb5, 0xbb, 0xb3, 0xc6, 0x00, 0x65,
+ 0x00, 0xae, 0xb8, 0xb3, 0xc7, 0x00, 0x6c
+};
+
+static const unsigned int ld9040_22_110[] = {
+ 0x00, 0x13, 0xbb, 0xb7, 0xca, 0x00, 0x4f,
+ 0x00, 0xb4, 0xbb, 0xb3, 0xc7, 0x00, 0x60,
+ 0x00, 0xad, 0xb8, 0xb4, 0xc7, 0x00, 0x67
+};
+
+static const unsigned int ld9040_22_100[] = {
+ 0x00, 0x13, 0xba, 0xb8, 0xcb, 0x00, 0x4b,
+ 0x00, 0xb3, 0xbc, 0xb4, 0xc7, 0x00, 0x5c,
+ 0x00, 0xac, 0xb8, 0xb4, 0xc8, 0x00, 0x62
+};
+
+static const unsigned int ld9040_22_90[] = {
+ 0x00, 0x13, 0xb9, 0xb8, 0xcd, 0x00, 0x46,
+ 0x00, 0xb1, 0xbc, 0xb5, 0xc8, 0x00, 0x56,
+ 0x00, 0xaa, 0xb8, 0xb4, 0xc9, 0x00, 0x5d
+};
+
+static const unsigned int ld9040_22_80[] = {
+ 0x00, 0x13, 0xba, 0xb9, 0xcd, 0x00, 0x41,
+ 0x00, 0xb0, 0xbe, 0xb5, 0xc9, 0x00, 0x51,
+ 0x00, 0xa9, 0xb9, 0xb5, 0xca, 0x00, 0x57
+};
+
+static const unsigned int ld9040_22_70[] = {
+ 0x00, 0x13, 0xb9, 0xb9, 0xd0, 0x00, 0x3c,
+ 0x00, 0xaf, 0xbf, 0xb6, 0xcb, 0x00, 0x4b,
+ 0x00, 0xa8, 0xb9, 0xb5, 0xcc, 0x00, 0x52
+};
+
+static const unsigned int ld9040_22_50[] = {
+ 0x00, 0x13, 0xb2, 0xba, 0xd2, 0x00, 0x30,
+ 0x00, 0xaf, 0xc0, 0xb8, 0xcd, 0x00, 0x3d,
+ 0x00, 0xa8, 0xb8, 0xb7, 0xcd, 0x00, 0x44
+};
+
+struct ld9040_gamma {
+ unsigned int *gamma_22_table[MAX_GAMMA_LEVEL];
+};
+
+static struct ld9040_gamma gamma_table = {
+ .gamma_22_table[0] = (unsigned int *)&ld9040_22_50,
+ .gamma_22_table[1] = (unsigned int *)&ld9040_22_70,
+ .gamma_22_table[2] = (unsigned int *)&ld9040_22_80,
+ .gamma_22_table[3] = (unsigned int *)&ld9040_22_90,
+ .gamma_22_table[4] = (unsigned int *)&ld9040_22_100,
+ .gamma_22_table[5] = (unsigned int *)&ld9040_22_110,
+ .gamma_22_table[6] = (unsigned int *)&ld9040_22_120,
+ .gamma_22_table[7] = (unsigned int *)&ld9040_22_130,
+ .gamma_22_table[8] = (unsigned int *)&ld9040_22_140,
+ .gamma_22_table[9] = (unsigned int *)&ld9040_22_150,
+ .gamma_22_table[10] = (unsigned int *)&ld9040_22_160,
+ .gamma_22_table[11] = (unsigned int *)&ld9040_22_170,
+ .gamma_22_table[12] = (unsigned int *)&ld9040_22_180,
+ .gamma_22_table[13] = (unsigned int *)&ld9040_22_190,
+ .gamma_22_table[14] = (unsigned int *)&ld9040_22_200,
+ .gamma_22_table[15] = (unsigned int *)&ld9040_22_210,
+ .gamma_22_table[16] = (unsigned int *)&ld9040_22_220,
+ .gamma_22_table[17] = (unsigned int *)&ld9040_22_230,
+ .gamma_22_table[18] = (unsigned int *)&ld9040_22_240,
+ .gamma_22_table[19] = (unsigned int *)&ld9040_22_250,
+ .gamma_22_table[20] = (unsigned int *)&ld9040_22_260,
+ .gamma_22_table[21] = (unsigned int *)&ld9040_22_270,
+ .gamma_22_table[22] = (unsigned int *)&ld9040_22_280,
+ .gamma_22_table[23] = (unsigned int *)&ld9040_22_290,
+ .gamma_22_table[24] = (unsigned int *)&ld9040_22_300,
+};
+
+#endif
+
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] radeonfb: Let hwmon driver probe the "monid" I2C bus
From: Dave Airlie @ 2011-01-13 4:44 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111162352.5a634e9e@endymion.delvare>
On Thu, Jan 13, 2011 at 2:11 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Tue, Jan 11, 2011 at 04:23:52PM +0100, Jean Delvare wrote:
>> Some Radeon cards have an I2C-based thermal sensor chip connected to
>> the "monid" I2C bus. Set the I2C probing class of this bus properly so
>> that hwmon drivers can detect devices on it and bind to them.
>>
>> This closes kernel.org bug #26172.
>>
The radeon BIOS actually contains a table to tell us what chip is on the bus,
in the KMS driver we read this table and load the appropriate hwmon device,
There could possibly be other things on this bus than hw monitor devices.
Though radeonfb should be considered mostly dead.
Dave.
^ permalink raw reply
* Re: [PATCH] radeonfb: Let hwmon driver probe the "monid" I2C bus
From: Benjamin Herrenschmidt @ 2011-01-13 4:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111162352.5a634e9e@endymion.delvare>
On Thu, 2011-01-13 at 14:44 +1000, Dave Airlie wrote:
> The radeon BIOS actually contains a table to tell us what chip is on
> the bus,
> in the KMS driver we read this table and load the appropriate hwmon
> device,
>
> There could possibly be other things on this bus than hw monitor
> devices.
>
> Though radeonfb should be considered mostly dead.
I want to test that on a few powermacs first. "probing" i2c can be
destructive and f* knows what Apple put on those busses on some
machines.
Haven't had a chance to look much yet.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] fbdev: Implement simple blanking in pseudocolor modes for vt8500lcdfb
From: Geert Uytterhoeven @ 2011-01-13 6:03 UTC (permalink / raw)
To: Alexey Charkov
Cc: Paul Mundt, linux-fbdev, linux-kernel, vt8500-wm8505-linux-kernel
In-Reply-To: <20110112221443.GA574@alchark-u3s>
On Wed, Jan 12, 2011 at 23:14, Alexey Charkov <alchark@gmail.com> wrote:
> Implement simple blanking in pseudocolor modes for vt8500lcdfb
>
> This follows the style of some other in-tree drivers by just setting
> the hardware palette colors to all black. True Color modes are not
> affected, but this at least allows to run xf86-video-fbdev without
> errors due to blanking being unimplemented.
Hmm, I seemed to remember this was handled at the generic level if no .fb_blank
implementation was present? That's why e.g. vesafb and macfb don't
have an fb_blank
implementation, while people run/ran X on them for sure.
[ looking in the code and its history ]
According to full-history-linux, it was removed by:
ommit ca2efeeb715e9fc0f12e57b54ba43ee1e1e50524
Author: Antonino Daplas <adaplas@hotpop.com>
Date: Sun Nov 7 04:05:04 2004 -0800
[PATCH] fbcon: "Do not touch hardware if vc_mode != KD_TEXT: fix
Sigh, this patch uncovered a can of worms. I tested different combinations,
those with/without xxxfb_blank implementation, framebuffers in directcolor
or truecolor, etc. I find that there is a problem unblanking if the hardware
has no xxxfb_blank() implementation, and also that the generic fb_blank() in
fbmem.c is problematic with drivers in directcolor or pseudocolor mode when
called by an fb application such as X.
Display blanking is implemented in three ways:
1. using the drivers blanking implementation - info->fbops->fb_blank()
2. clearing the screen with the console erase character - fbcon_blank()
3. setting the color map to all black - fb_blank()
The third method is problematic for these reasons:
- Setting the colormap to all black will not work in truecolor mode
- In directcolor or pseudocolor, it will overwrite the fb application's
color map, producing wrong colors.
So, remove the generic implementation in fb_blank() and just return -EINVAL
if there is no hardware implementation. This will be only used by apps doin
an FBIO_BLANK ioctl, and is a more robust approach.
Other changes:
- Consolidated all tests and created an inlined helper function to check if
the framebuffer console is inactive or not.
- fix unblanking if driver has no xxxfb_blank() hook.
I'm probably missing a few more things, but this patch should be generally
correct. Please apply after the entire patch series to avoid rejects.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] fbdev: Implement simple blanking in pseudocolor modes for vt8500lcdfb
From: Paul Mundt @ 2011-01-13 6:17 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Alexey Charkov, linux-fbdev, linux-kernel,
vt8500-wm8505-linux-kernel
In-Reply-To: <AANLkTimRVSB13X67vz_qg_CpTg1J2fNz5A0Oweq3MZp1@mail.gmail.com>
On Thu, Jan 13, 2011 at 07:03:43AM +0100, Geert Uytterhoeven wrote:
> The third method is problematic for these reasons:
>
> - Setting the colormap to all black will not work in truecolor mode
> - In directcolor or pseudocolor, it will overwrite the fb application's
> color map, producing wrong colors.
>
> So, remove the generic implementation in fb_blank() and just return -EINVAL
> if there is no hardware implementation. This will be only used by apps doin
> an FBIO_BLANK ioctl, and is a more robust approach.
>
The in-tree drivers that implement the blacking out also don't really
seem to agree on the implementation, with some having more complex
requirements for prodding their controllers than others (such as pxafb).
I'm fairly ambivalent about it however. If people are actively testing X
on their drivers with these configurations and are willing to deal with
the potential issues and restrictions it comes along with, then I don't
mind plugging it in to individual drivers that wish to opt in.
Having a default -EINVAL remains the safest bet in terms of general
correctness, but if this results in an X fbdev driver that is unusable
for most people, then we're still going to have to come up with an
alternative solution.
^ permalink raw reply
* Re: [PATCH] radeonfb: Let hwmon driver probe the "monid" I2C bus
From: Jean Delvare @ 2011-01-13 8:22 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111162352.5a634e9e@endymion.delvare>
On Thu, 13 Jan 2011 14:44:53 +1000, Dave Airlie wrote:
> On Thu, Jan 13, 2011 at 2:11 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> > On Tue, Jan 11, 2011 at 04:23:52PM +0100, Jean Delvare wrote:
> >> Some Radeon cards have an I2C-based thermal sensor chip connected to
> >> the "monid" I2C bus. Set the I2C probing class of this bus properly so
> >> that hwmon drivers can detect devices on it and bind to them.
> >>
> >> This closes kernel.org bug #26172.
> >>
>
> The radeon BIOS actually contains a table to tell us what chip is on the bus,
> in the KMS driver we read this table and load the appropriate hwmon device,
>
> There could possibly be other things on this bus than hw monitor devices.
I know that, but...
> Though radeonfb should be considered mostly dead.
... I doubt anybody is interested in investing that much worktime in
radeonfb any longer.
--
Jean Delvare
^ permalink raw reply
* RE: Memory sharing issue by application on V4L2 based device driver
From: Jonghun Han @ 2011-01-13 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111173509.GB14017@dumpdata.com>
Sorry for late reply.
Samsung SoC C210 has many multimedia IPs.
Each IP has its own MMU named SYSTEM MMU like CPU's MMU.
So it can handle discontiguous memory using device own virtual address.
What Inki Dae wants to discuss is how to allocate the memory and how to
share it with other multimedia IPs.
Thank you for interesting.
Best regards,
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Wednesday, January 12, 2011 2:35 AM
> To: Jonghun Han
> Cc: 'InKi Dae'; linux-media@vger.kernel.org;
linux-arm-kernel@lists.infradead.org;
> 'linux-fbdev'; kyungmin.park@samsung.com
> Subject: Re: Memory sharing issue by application on V4L2 based device
driver
> with system mmu.
>
>
> .. snip..
> > But 64KB or 1MB physically contiguous memory is better than 4KB page
> > in the point of performance.
>
> Could you explain that in more details please? I presume you are talking
about a
> CPU that has a MMU unit, right?
> --
> 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
* Re: [PATCH] radeonfb: Let hwmon driver probe the "monid" I2C bus
From: Jean Delvare @ 2011-01-13 8:56 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110111162352.5a634e9e@endymion.delvare>
Hi Ben,
On Thu, 13 Jan 2011 15:50:10 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2011-01-13 at 14:44 +1000, Dave Airlie wrote:
> > The radeon BIOS actually contains a table to tell us what chip is on
> > the bus,
> > in the KMS driver we read this table and load the appropriate hwmon
> > device,
> >
> > There could possibly be other things on this bus than hw monitor
> > devices.
> >
> > Though radeonfb should be considered mostly dead.
>
> I want to test that on a few powermacs first. "probing" i2c can be
> destructive and f* knows what Apple put on those busses on some
> machines.
If this is a concern to you, I'd be fine excluding CONFIG_PPC from the
change. Or are you worried about Intel Mac machines too? If there's an
easy way to spot all powermac machines, we can use that too, just let
me know how.
> Haven't had a chance to look much yet.
Thanks,
--
Jean Delvare
^ permalink raw reply
* [GIT PULL] fbdev updates for 2.6.38-rc1, part 2.
From: Paul Mundt @ 2011-01-13 9:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-fbdev, linux-kernel
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/lethal/fbdev-2.6.git
Which contains:
Alexey Charkov (1):
fbdev: Implement simple blanking in pseudocolor modes for vt8500lcdfb
Archit Taneja (4):
OMAP: DSS2: Fix: Read correct bit in dispc_enable_alpha_blending()
OMAP: DSS2: Clean up DISPC color mode validation checks
OMAP: DSS2: Add dss_features for omap4 and overlay manager related features
OMAP: DSS2: Use dss_features to handle DISPC bits removed on OMAP4
Bryan Wu (4):
OMAP: DSS2: Add generic DPI panel display driver
OMAP: use generic DPI panel driver in board files
OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers
OMAP: DSS2: Add back authors of panel-generic.c based drivers
Dmitry Eremin-Solenikov (1):
video: move SH_MIPI_DSI/SH_LCD_MIPI_DSI to the top of menu
Erik Gilling (1):
OMAP: DSS2: Add NEC NL8048HL11-01B display panel
Fabio Estevam (1):
video: imx: Update the manufacturer's name
Guennadi Liakhovetski (3):
fbdev: sh_mobile_hdmi: add command line option to use the preferred EDID mode
fbdev: sh_mobile_hdmi: framebuffer notifiers have to be registered
fbdev: sh_mobile_hdmi: simplify pointer handling
Jamie Iles (2):
s3c2410fb: don't treat NULL clk as an error
nuc900fb: don't treat NULL clk as an error
Kishore Y (2):
OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3
OMAP3: Enable display on ZOOM2/3/3630SDP
Mayuresh Janorkar (1):
video: tidy up modedb formatting.
Rajkumar N (1):
OMAP3630: DSS2: Enable Pre-Multiplied Alpha Support
Samreen (2):
OMAP3: DSS2: Split OMAP3 has feature for 3430 & 3630
OMAP: DSS2: OMAPFB: Add null pointer check
Sumit Semwal (5):
OMAP: DSS2: Represent DISPC register defines with channel as parameter
OMAP: DSS2: Introduce omap_channel argument to DISPC functions used by interface drivers
OMAP: DSS2: Change remaining DISPC functions for new omap_channel argument
OMAP: DSS2: LCD2 Channel Changes for DISPC
OMAP: DSS2: Introduce omap_channel as an omap_dss_device parameter, add new overlay manager.
Vicente Jiménez (1):
video: matroxfb: Correct video option in comments and kernel config help.
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/board-3430sdp.c | 12 +-
arch/arm/mach-omap2/board-3630sdp.c | 1 +
arch/arm/mach-omap2/board-am3517evm.c | 23 +-
arch/arm/mach-omap2/board-cm-t35.c | 23 +-
arch/arm/mach-omap2/board-devkit8000.c | 26 +-
arch/arm/mach-omap2/board-igep0020.c | 12 +-
arch/arm/mach-omap2/board-omap3beagle.c | 12 +-
arch/arm/mach-omap2/board-omap3evm.c | 12 +-
arch/arm/mach-omap2/board-omap3stalker.c | 23 +-
arch/arm/mach-omap2/board-zoom-display.c | 168 +++++
arch/arm/mach-omap2/board-zoom-peripherals.c | 49 ++-
arch/arm/mach-omap2/board-zoom.c | 1 +
arch/arm/mach-omap2/include/mach/board-zoom.h | 3 +
arch/arm/plat-omap/include/plat/display.h | 9 +
.../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 ++
drivers/video/Kconfig | 18 +-
drivers/video/imxfb.c | 2 +-
drivers/video/matrox/matroxfb_base.c | 70 ++--
drivers/video/modedb.c | 420 +++++++------
drivers/video/nuc900fb.c | 5 +-
drivers/video/omap2/displays/Kconfig | 27 +-
drivers/video/omap2/displays/Makefile | 5 +-
drivers/video/omap2/displays/panel-generic-dpi.c | 365 +++++++++++
drivers/video/omap2/displays/panel-generic.c | 174 ------
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 325 ++++++++++
.../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 -----
.../video/omap2/displays/panel-toppoly-tdo35s.c | 164 -----
drivers/video/omap2/dss/dispc.c | 636 +++++++++++++-------
drivers/video/omap2/dss/dpi.c | 40 +-
drivers/video/omap2/dss/dsi.c | 27 +-
drivers/video/omap2/dss/dss.h | 35 +-
drivers/video/omap2/dss/dss_features.c | 66 ++-
drivers/video/omap2/dss/dss_features.h | 10 +-
drivers/video/omap2/dss/manager.c | 80 ++-
drivers/video/omap2/dss/overlay.c | 55 ++-
drivers/video/omap2/dss/rfbi.c | 20 +-
drivers/video/omap2/dss/sdi.c | 24 +-
drivers/video/omap2/omapfb/omapfb-main.c | 5 +-
drivers/video/s3c2410fb.c | 5 +-
drivers/video/sh_mobile_hdmi.c | 97 ++--
drivers/video/vt8500lcdfb.c | 28 +
42 files changed, 2112 insertions(+), 1170 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-display.c
create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
delete mode 100644 drivers/video/omap2/displays/panel-generic.c
create mode 100644 drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c
^ permalink raw reply
* [PATCH] OMAP: DSS2: Fix def_disp module param description
From: Jani Nikula @ 2011-01-13 12:42 UTC (permalink / raw)
To: linux-fbdev
MODULE_PARM_DESC() takes the name of the actual module parameter, not the
name of the variable, as input. Fix the module parameter description for
def_disp.
Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
---
drivers/video/omap2/dss/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 8e89f60..cad73b1 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -62,7 +62,7 @@ static void dss_clk_disable_no_ctx(enum dss_clock clks);
static char *def_disp_name;
module_param_named(def_disp, def_disp_name, charp, 0);
-MODULE_PARM_DESC(def_disp_name, "default display name");
+MODULE_PARM_DESC(def_disp, "default display name");
#ifdef DEBUG
unsigned int dss_debug;
--
1.7.3.2
^ permalink raw reply related
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