* Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c
From: Tony Lindgren @ 2012-02-08 23:32 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-omap, Tomi Valkeinen, Florian Tobias Schandinat,
linux-fbdev
In-Reply-To: <20120208225012.GA25414@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 14:19]:
> On Wed, Feb 08, 2012 at 10:36:07AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> > > When a PMIC is not found, this driver is unable to obtain its
> > > 'vdds_dsi_reg' regulator. Even through its initialization function
> > > fails, other code still calls its enable function, which fails to
> > > check whether it has this regulator before asking for it to be enabled.
> > >
> > > This fixes the oops, however a better fix would be to sort out the
> > > upper layers to prevent them calling into a module which failed to
> > > initialize.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >
> > Tomi can look into fixing this properly for v3.4:
> >
> > Acked-by: Tony Lindgren <tony@atomide.com>
>
> No, it's a thing for v3.3, because you can still get this oops.
>
> I expect _most_ of these patches will go into v3.3, and anything with
> 'fix' or 'oops' in especially I want to see in v3.3.
I acked your patch for -rc. Then Tomi can work on the "better fix part"
you mention above for v3.4 and that's what I meant by my comment
above.
Or is there something else that needs fixing for the -rc series there?
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c
From: Russell King - ARM Linux @ 2012-02-08 22:50 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, Tomi Valkeinen, Florian Tobias Schandinat,
linux-fbdev
In-Reply-To: <20120208183607.GB29796@atomide.com>
On Wed, Feb 08, 2012 at 10:36:07AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> > When a PMIC is not found, this driver is unable to obtain its
> > 'vdds_dsi_reg' regulator. Even through its initialization function
> > fails, other code still calls its enable function, which fails to
> > check whether it has this regulator before asking for it to be enabled.
> >
> > This fixes the oops, however a better fix would be to sort out the
> > upper layers to prevent them calling into a module which failed to
> > initialize.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> Tomi can look into fixing this properly for v3.4:
>
> Acked-by: Tony Lindgren <tony@atomide.com>
No, it's a thing for v3.3, because you can still get this oops.
I expect _most_ of these patches will go into v3.3, and anything with
'fix' or 'oops' in especially I want to see in v3.3.
^ permalink raw reply
* Re: [PATCH 00/16] rmk's patch series for fixing OMAP
From: Florian Tobias Schandinat @ 2012-02-08 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120208163546.GA15849@n2100.arm.linux.org.uk>
Hi Russell,
On 02/08/2012 04:35 PM, Russell King - ARM Linux wrote:
> commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
> Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Tue Jan 17 11:09:57 2012 +0200
>
> OMAPDSS: HDMI: PHY burnout fix
>
> A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
> if the HDMI PHY is kept powered on when the cable is not connected.
I agree this is a serious issue.
> which now has me wondering if, by trying to boot v3.3-rc2 on this board
> during the past week, I have a destroyed HDMI interface on it.
I am not sure as I don't keep track of all OMAP changes, but you make it sound
like a regression, is there any difference to 3.2 behavior?
> So, a big thanks for sitting on that fix and exposing peoples hardware
> to damage, that shows real professionalism.
Well, I am no professional to begin with, at least in the sense of getting paid
for it. That said I'm quite happy if I manage to find a few hours every weekend
to do the work. Given that the final thing should be tested in -next before I
ask Linus to pull, it is completely usual (and even quite fast) if things take
8-13 days on my end. If this isn't fast enough for Tomi, he'd better ask Linus
to pull directly for such issues.
This one was also somewhat special as I had to learn how to deal with PGP and
signed tags to make Linus happy.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH 00/16] rmk's patch series for fixing OMAP
From: Tony Lindgren @ 2012-02-08 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120208163546.GA15849@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> This is my set of patches for fixing OMAP for v3.3.
>
> This is the complete series of patches I'm currently applying to _my_
> tree to get v3.3-rc2 into a usable and sane state.
I've acked all but two. The if (1) hack must have some better
solution, then I'd like to see Paul's ack on the error formatting
patch.
Other than that go for it. Thanks for the nice series, too bad
these were not found earlier.
> I want to see most of the problems uncovered in this series fixed sooner
> rather than later, and certainly not taking three plus weeks to get into
> mainline like this rather serious looking commit did:
>
> commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
> Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Tue Jan 17 11:09:57 2012 +0200
>
> OMAPDSS: HDMI: PHY burnout fix
>
> A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
> if the HDMI PHY is kept powered on when the cable is not connected.
>
> which now has me wondering if, by trying to boot v3.3-rc2 on this board
> during the past week, I have a destroyed HDMI interface on it.
>
> So, a big thanks for sitting on that fix and exposing peoples hardware
> to damage, that shows real professionalism.
Not good.
Tony
^ permalink raw reply
* Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c
From: Tony Lindgren @ 2012-02-08 18:36 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-omap, Tomi Valkeinen, Florian Tobias Schandinat,
linux-fbdev
In-Reply-To: <E1RvAVQ-0006Gp-Is@rmk-PC.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> When a PMIC is not found, this driver is unable to obtain its
> 'vdds_dsi_reg' regulator. Even through its initialization function
> fails, other code still calls its enable function, which fails to
> check whether it has this regulator before asking for it to be enabled.
>
> This fixes the oops, however a better fix would be to sort out the
> upper layers to prevent them calling into a module which failed to
> initialize.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tomi can look into fixing this properly for v3.4:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c
From: Russell King - ARM Linux @ 2012-02-08 16:36 UTC (permalink / raw)
To: linux-omap; +Cc: Tomi Valkeinen, Florian Tobias Schandinat, linux-fbdev
In-Reply-To: <20120208163546.GA15849@n2100.arm.linux.org.uk>
When a PMIC is not found, this driver is unable to obtain its
'vdds_dsi_reg' regulator. Even through its initialization function
fails, other code still calls its enable function, which fails to
check whether it has this regulator before asking for it to be enabled.
This fixes the oops, however a better fix would be to sort out the
upper layers to prevent them calling into a module which failed to
initialize.
Unable to handle kernel NULL pointer dereference at virtual address 00000038
pgd = c0004000
[00000038] *pgd\0000000
Internal error: Oops: 5 [#1] PREEMPT
Modules linked in:
CPU: 0 Not tainted (3.3.0-rc2+ #228)
PC is at regulator_enable+0x10/0x70
LR is at omapdss_dpi_display_enable+0x54/0x15c
pc : [<c01b9a08>] lr : [<c01af994>] psr: 60000013
sp : c181fd90 ip : c181fdb0 fp : c181fdac
r10: c042eff0 r9 : 00000060 r8 : c044a164
r7 : c042c0e4 r6 : c042bd60 r5 : 00000000 r4 : c042bd60
r3 : c084de48 r2 : c181e000 r1 : c042bd60 r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 80004019 DAC: 00000015
Process swapper (pid: 1, stack limit = 0xc181e2e8)
Stack: (0xc181fd90 to 0xc1820000)
fd80: c001754c c042bd60 00000000 c042bd60
fda0: c181fdcc c181fdb0 c01af994 c01b9a04 c0016104 c042bd60 c042bd60 c044a338
fdc0: c181fdec c181fdd0 c01b5ed0 c01af94c c042bd60 c042bd60 c1aa8000 c1aa8a0c
fde0: c181fe04 c181fdf0 c01b5f54 c01b5ea8 c02fc18c c042bd60 c181fe3c c181fe08
fe00: c01b2a18 c01b5f48 c01aed14 c02fc160 c01df8ec 00000002 c042bd60 00000003
fe20: c042bd60 c1aa8000 c1aa8a0c c042eff8 c181fe84 c181fe40 c01b3874 c01b29fc
fe40: c042eff8 00000000 c042f000 c0449db8 c044ed78 00000000 c181fe74 c042eff8
fe60: c042eff8 c0449db8 c0449db8 c044ed78 00000000 00000000 c181fe94 c181fe88
fe80: c01e452c c01b35e8 c181feb4 c181fe98 c01e2fdc c01e4518 c042eff8 c0449db8
fea0: c0449db8 c181fef0 c181fecc c181feb8 c01e3104 c01e2f48 c042eff8 c042f02c
fec0: c181feec c181fed0 c01e3190 c01e30c0 c01e311c 00000000 c01e311c c0449db8
fee0: c181ff14 c181fef0 c01e1998 c01e3128 c18330a8 c1892290 c04165e8 c0449db8
ff00: c0449db8 c1ab60c0 c181ff24 c181ff18 c01e2e28 c01e194c c181ff54 c181ff28
ff20: c01e2218 c01e2e14 c039afed c181ff38 c04165e8 c041660c c0449db8 00000013
ff40: 00000000 c03ffdb8 c181ff7c c181ff58 c01e384c c01e217c c181ff7c c04165e8
ff60: c041660c c003a37c 00000013 00000000 c181ff8c c181ff80 c01e488c c01e3790
ff80: c181ff9c c181ff90 c03ffdcc c01e484c c181ffdc c181ffa0 c0008798 c03ffdc4
ffa0: c181ffc4 c181ffb0 c0056440 c0187810 c003a37c c04165e8 c041660c c003a37c
ffc0: 00000013 00000000 00000000 00000000 c181fff4 c181ffe0 c03ea284 c0008708
ffe0: 00000000 c03ea208 00000000 c181fff8 c003a37c c03ea214 1073cec0 01f7ee08
Backtrace:
[<c01b99f8>] (regulator_enable+0x0/0x70) from [<c01af994>] (omapdss_dpi_display_enable+0x54/0x15c)
r6:c042bd60 r5:00000000 r4:c042bd60
[<c01af940>] (omapdss_dpi_display_enable+0x0/0x15c) from [<c01b5ed0>] (generic_dpi_panel_power_on+0x34/0x78)
r6:c044a338 r5:c042bd60 r4:c042bd60
[<c01b5e9c>] (generic_dpi_panel_power_on+0x0/0x78) from [<c01b5f54>] (generic_dpi_panel_enable+0x18/0x28)
r7:c1aa8a0c r6:c1aa8000 r5:c042bd60 r4:c042bd60
[<c01b5f3c>] (generic_dpi_panel_enable+0x0/0x28) from [<c01b2a18>] (omapfb_init_display+0x28/0x150)
r4:c042bd60
[<c01b29f0>] (omapfb_init_display+0x0/0x150) from [<c01b3874>] (omapfb_probe+0x298/0x318)
r8:c042eff8 r7:c1aa8a0c r6:c1aa8000 r5:c042bd60 r4:00000003
[<c01b35dc>] (omapfb_probe+0x0/0x318) from [<c01e452c>] (platform_drv_probe+0x20/0x24)
[<c01e450c>] (platform_drv_probe+0x0/0x24) from [<c01e2fdc>] (really_probe+0xa0/0x178)
[<c01e2f3c>] (really_probe+0x0/0x178) from [<c01e3104>] (driver_probe_device+0x50/0x68)
r7:c181fef0 r6:c0449db8 r5:c0449db8 r4:c042eff8
[<c01e30b4>] (driver_probe_device+0x0/0x68) from [<c01e3190>] (__driver_attach+0x74/0x98)
r5:c042f02c r4:c042eff8
[<c01e311c>] (__driver_attach+0x0/0x98) from [<c01e1998>] (bus_for_each_dev+0x58/0x98)
r6:c0449db8 r5:c01e311c r4:00000000
[<c01e1940>] (bus_for_each_dev+0x0/0x98) from [<c01e2e28>] (driver_attach+0x20/0x28)
r7:c1ab60c0 r6:c0449db8 r5:c0449db8 r4:c04165e8
[<c01e2e08>] (driver_attach+0x0/0x28) from [<c01e2218>] (bus_add_driver+0xa8/0x22c)
[<c01e2170>] (bus_add_driver+0x0/0x22c) from [<c01e384c>] (driver_register+0xc8/0x154)
[<c01e3784>] (driver_register+0x0/0x154) from [<c01e488c>] (platform_driver_register+0x4c/0x60)
r8:00000000 r7:00000013 r6:c003a37c r5:c041660c r4:c04165e8
[<c01e4840>] (platform_driver_register+0x0/0x60) from [<c03ffdcc>] (omapfb_init+0x14/0x34)
[<c03ffdb8>] (omapfb_init+0x0/0x34) from [<c0008798>] (do_one_initcall+0x9c/0x164)
[<c00086fc>] (do_one_initcall+0x0/0x164) from [<c03ea284>] (kernel_init+0x7c/0x120)
[<c03ea208>] (kernel_init+0x0/0x120) from [<c003a37c>] (do_exit+0x0/0x2d8)
r5:c03ea208 r4:00000000
Code: e1a0c00d e92dd870 e24cb004 e24dd004 (e5906038)
---[ end trace 9e2474c2e193b223 ]---
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/video/omap2/dss/dpi.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 395d658..faaf305 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -180,6 +180,11 @@ int omapdss_dpi_display_enable(struct omap_dss_device *dssdev)
{
int r;
+ if (cpu_is_omap34xx() && !dpi.vdds_dsi_reg) {
+ DSSERR("no VDSS_DSI regulator\n");
+ return -ENODEV;
+ }
+
if (dssdev->manager = NULL) {
DSSERR("failed to enable display: no manager\n");
return -ENODEV;
--
1.7.4.4
^ permalink raw reply related
* [PATCH 00/16] rmk's patch series for fixing OMAP
From: Russell King - ARM Linux @ 2012-02-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
This is my set of patches for fixing OMAP for v3.3.
This is the complete series of patches I'm currently applying to _my_
tree to get v3.3-rc2 into a usable and sane state.
I want to see most of the problems uncovered in this series fixed sooner
rather than later, and certainly not taking three plus weeks to get into
mainline like this rather serious looking commit did:
commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Tue Jan 17 11:09:57 2012 +0200
OMAPDSS: HDMI: PHY burnout fix
A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
if the HDMI PHY is kept powered on when the cable is not connected.
which now has me wondering if, by trying to boot v3.3-rc2 on this board
during the past week, I have a destroyed HDMI interface on it.
So, a big thanks for sitting on that fix and exposing peoples hardware
to damage, that shows real professionalism.
^ permalink raw reply
* RE: [RESENT][PATCH v2 0/2] fb: add early fb blank feature
From: Inki Dae @ 2012-02-07 5:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <003f01cc8280$7510c5c0$5f325140$%dae@samsung.com>
Hi, Florian and Andrew.
Like below email threads, I had posted this patch last year but there is no
any answer. as Florian mentioned, It seems like Richard does no longer
handle LCD/backlight stuff so Andrew, could you please look into this patch
set? And if there is no problem, please apply it to mainline.
Thanks,
Inki Dae.
> -----Original Message-----
> From: Florian Tobias Schandinat [mailto:FlorianSchandinat@gmx.de]
> Sent: Sunday, October 30, 2011 8:24 PM
> To: Andrew Morton
> Cc: Inki Dae; rpurdie@rpsys.net; linux-fbdev@vger.kernel.org;
> lars@metafoo.de; kyungmin.park@samsung.com
> Subject: Re: [RESENT][PATCH v2 0/2] fb: add early fb blank feature
>
> Hi Andrew,
>
> can you take care of this patch series?
> It seems like Richard does no longer handle LCD/backlight stuff (why is he
> listed as maintainer?) and I really cannot say whether the patch to the
> LCD code
> is correct and therefore I do not intend to carry such a patch without any
> Ack.
> You can add an "Acked-by: Florian Tobias Schandinat
> <FlorianSchandinat@gmx.de>"
> to the fb patch 2/2 (well actually I think the order should be swapped as
> 1 does
> not compile without 2) but I ask you to handle it as well as it is useless
> without the other patch.
>
>
> Thanks,
>
> Florian Tobias Schandinat
>
> On 10/04/2011 10:29 AM, Inki Dae wrote:
> > this patch adds early fb blank feature that a callback of lcd panel
> driver
> > is called prior to specific fb driver's one. in case of MIPI-DSI based
> video
> > mode LCD Panel, for lcd power off, the power off commands should be
> > transferred to lcd panel with display and mipi-dsi controller enabled
> > because the commands is set to lcd panel at vsync porch period. and in
> > opposite case, the callback of fb driver should be called prior to lcd
> panel
> > driver's one because of same issue. and also if fb_blank mode is changed
> to
> > FB_BLANK_POWERDOWN then display controller would be off(clock disable)
> but
> > lcd panel would be still on. at this time, you could see some issue like
> > sparkling on lcd panel because video clock to be delivered to ldi module
> of
> > lcd panel was disabled. this issue could occurs for all lcd panels.
> >
> > the callback order is as the following:
> >
> > at fb_blank function of fbmem.c
> > -> fb_notifier_call_chain(FB_EARLY_EVENT_BLANK)
> > -> lcd panel driver's early_set_power()
> > -> info->fbops->fb_blank()
> > -> spcefic fb driver's fb_blank()
> > -> fb_notifier_call_chain(FB_EVENT_BLANK)
> > -> lcd panel driver's set_power()
> > -> fb_notifier_call_chain(FB_R_EARLY_EVENT_BLANK) if
> > info->fops->fb_blank() was failed.
> >
> > fb_notifier_call_chain(FB_R_EARLY_EVENT_BLANK) would be called to revert
> the
> > effects of previous FB_EARLY_EVENT_BLANK call. and note that if
> > early_set_power() of lcd_ops is NULL then early fb blank callback would
> be
> > ignored.
> >
> > this patch is based on git repository below:
> > git://github.com/schandinat/linux-2.6.git
> > branch: fbdev-next
> > commit-id: 2b7a905dd0d24d14a1099653ba63b7113a82fc54
> >
> > Links to previous versions of the patchset:
> > v1: < http://lkml.indiana.edu/hypermail/linux/kernel/1109.1/00413.html >
> >
> > Changelog v2:
> > fb: add fb early blank event instead of early_blank_mode variable.
> > fb notifier can know whether early blank mode is support or not
> > checking if early_set_power callback is NULL or not.
> >
> > fb: add exception codes at fb_blank().
> > the effects of previous FB_EARLY_EVENT_BLANK call should be
> reverted
> > if info->fbops->fb_blank() was failed.
> >
> > fb: add code clean.
> >
> > Changelog RESEND:
> > fb: fixed condition.
> > this patch changes 'if (early_ret < 0)' to 'if (!early_ret)' of
> > fb_blank function.
> >
> > these patch series are as the following:
> > [RESEND][PATCH v2 0/2] fb: add early fb blank feature.
> > introduce new early fb blank feature.
> > [RESEND][PATCH v2 1/2] lcd: add callbacks for early fb event blank
> support.
> > [RESEND][PATCH v2 2/2] fb: add events for early fb event support.
> >
> > Signed-off-by: Inki Dae <inki.dae@samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> >
> > --
> > 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
* [GIT PULL] fbdev fixes for 3.3
From: Florian Tobias Schandinat @ 2012-02-07 0:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: LKML, linux-fbdev@vger.kernel.org
Hi Linus,
please pull the changes below.
The key has not been signed yet as I didn't have time to take care about it.
Thanks,
Florian Tobias Schandinat
The following changes since commit f787f32e67e00b072f46b2ae3c454d2c0a1fcdb7:
module_param: make bool parameters really bool (drivers/video/i810)
(2012-01-12 23:28:59 +0000)
are available in the git repository at:
git://github.com/schandinat/linux-2.6.git fbdev-fixes-for-3.3-1
for you to fetch changes up to 9f1065032ceb7e86c7c9f16bb86518857e88a172:
atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume (2012-01-28 19:50:22
+0000)
----------------------------------------------------------------
fbdev fixes for 3.3
It includes:
- a compile fix for fsl-diu-fb
- a fix for a suspend/resume issue in atmel_lcdfb
- a fix for a suspend/resume issue in OMAP
- a workaround for a hardware bug to avoid physical damage in OMAP
- a really trivial dead code removal in intelfb
----------------------------------------------------------------
Dan Carpenter (1):
intelfb: remove some dead code
Florian Tobias Schandinat (1):
Merge branch 'for-3.3-rc' of git://gitorious.org/linux-omap-dss2/linux
into fbdev-for-linus
Hubert Feurstein (1):
atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume
Michael Neuling (1):
drivers/video: compile fixes for fsl-diu-fb.c
Tomi Valkeinen (7):
OMAPDSS: use sync versions of pm_runtime_put
OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios
OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD
OMAPDSS: remove wrong HDMI HPD muxing
OMAP: 4430SDP/Panda: setup HDMI GPIO muxes
OMAP: 4430SDP/Panda: add HDMI HPD gpio
OMAPDSS: HDMI: PHY burnout fix
arch/arm/mach-omap2/board-4430sdp.c | 18 ++++++--
arch/arm/mach-omap2/board-omap4panda.c | 18 ++++++--
arch/arm/mach-omap2/display.c | 4 --
drivers/video/atmel_lcdfb.c | 2 +-
drivers/video/fsl-diu-fb.c | 4 +-
drivers/video/intelfb/intelfbdrv.c | 1 -
drivers/video/omap2/dss/dispc.c | 2 +-
drivers/video/omap2/dss/dsi.c | 2 +-
drivers/video/omap2/dss/dss.c | 2 +-
drivers/video/omap2/dss/hdmi.c | 5 ++-
drivers/video/omap2/dss/rfbi.c | 2 +-
drivers/video/omap2/dss/ti_hdmi.h | 4 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 68 +++++++++++++++++++++++++++--
drivers/video/omap2/dss/venc.c | 2 +-
include/video/omapdss.h | 5 ++
15 files changed, 113 insertions(+), 26 deletions(-)
^ permalink raw reply
* [PATCH] OMAP: DSS2: TPO-TD03MTEA1: update default gamma
From: Grazvydas Ignotas @ 2012-02-07 0:13 UTC (permalink / raw)
To: linux-fbdev; +Cc: Tomi Valkeinen, linux-omap, Grazvydas Ignotas
In-Reply-To: <1328573630-7348-1-git-send-email-notasas@gmail.com>
Over time better gamma has been determined and tuned with some
equipment so update the defaults. From subjective point of view
dark shades should be better visible.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
---
.../video/omap2/displays/panel-tpo-td043mtea1.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index 741e9d7..d63e5e5 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -47,7 +47,7 @@
TPO_R03_EN_PRE_CHARGE | TPO_R03_SOFTWARE_CTL)
static const u16 tpo_td043_def_gamma[12] = {
- 106, 200, 289, 375, 460, 543, 625, 705, 785, 864, 942, 1020
+ 105, 315, 381, 431, 490, 537, 579, 686, 780, 837, 880, 1023
};
struct tpo_td043_device {
--
1.7.0.4
^ permalink raw reply related
* [PATCH] OMAP: DSS2: TPO-TD03MTEA1: fix suspend hang
From: Grazvydas Ignotas @ 2012-02-07 0:13 UTC (permalink / raw)
To: linux-fbdev; +Cc: Tomi Valkeinen, linux-omap, Grazvydas Ignotas
During system suspend, at the time DSS is being suspended, SPI is
already suspended and it's clocks are cut. Because of this trying to
communicate with the LCD controller results in a deadlock.
To fix this, split out LCD programming parts of display enable/disable
functions and perform them from SPI PM callbacks instead when system is
being suspended. If the display is just being enabled/disabled, do it
from DSS callbacks as before.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
---
rather invasive so best for upcoming merge window I guess..
.../video/omap2/displays/panel-tpo-td043mtea1.c | 151 ++++++++++++++------
1 files changed, 108 insertions(+), 43 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index e6649aa..741e9d7 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -53,10 +53,14 @@ static const u16 tpo_td043_def_gamma[12] = {
struct tpo_td043_device {
struct spi_device *spi;
struct regulator *vcc_reg;
+ int nreset_gpio;
u16 gamma[12];
u32 mode;
u32 hmirror:1;
u32 vmirror:1;
+ u32 powered_on:1;
+ u32 spi_suspended:1;
+ u32 power_on_resume:1;
};
static int tpo_td043_write(struct spi_device *spi, u8 addr, u8 data)
@@ -265,28 +269,16 @@ static const struct omap_video_timings tpo_td043_timings = {
.vbp = 34,
};
-static int tpo_td043_power_on(struct omap_dss_device *dssdev)
+static int tpo_td043_power_on(struct tpo_td043_device *tpo_td043)
{
- struct tpo_td043_device *tpo_td043 = dev_get_drvdata(&dssdev->dev);
- int nreset_gpio = dssdev->reset_gpio;
- int r;
+ int nreset_gpio = tpo_td043->nreset_gpio;
- if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE)
+ if (tpo_td043->powered_on)
return 0;
- r = omapdss_dpi_display_enable(dssdev);
- if (r)
- goto err0;
-
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
regulator_enable(tpo_td043->vcc_reg);
- /* wait for power up */
+ /* wait for regulator to stabilize */
msleep(160);
if (gpio_is_valid(nreset_gpio))
@@ -301,19 +293,15 @@ static int tpo_td043_power_on(struct omap_dss_device *dssdev)
tpo_td043->vmirror);
tpo_td043_write_gamma(tpo_td043->spi, tpo_td043->gamma);
+ tpo_td043->powered_on = 1;
return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
-err0:
- return r;
}
-static void tpo_td043_power_off(struct omap_dss_device *dssdev)
+static void tpo_td043_power_off(struct tpo_td043_device *tpo_td043)
{
- struct tpo_td043_device *tpo_td043 = dev_get_drvdata(&dssdev->dev);
- int nreset_gpio = dssdev->reset_gpio;
+ int nreset_gpio = tpo_td043->nreset_gpio;
- if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
+ if (!tpo_td043->powered_on)
return;
tpo_td043_write(tpo_td043->spi, 3,
@@ -329,54 +317,94 @@ static void tpo_td043_power_off(struct omap_dss_device *dssdev)
regulator_disable(tpo_td043->vcc_reg);
+ tpo_td043->powered_on = 0;
+}
+
+static int tpo_td043_enable_dss(struct omap_dss_device *dssdev)
+{
+ struct tpo_td043_device *tpo_td043 = dev_get_drvdata(&dssdev->dev);
+ int r;
+
+ if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
+ r = omapdss_dpi_display_enable(dssdev);
+ if (r)
+ goto err0;
+
+ if (dssdev->platform_enable) {
+ r = dssdev->platform_enable(dssdev);
+ if (r)
+ goto err1;
+ }
+
+ /*
+ * If we are resuming from system suspend, SPI clocks might not be
+ * enabled yet, so we'll program the LCD from SPI PM resume callback.
+ */
+ if (!tpo_td043->spi_suspended) {
+ r = tpo_td043_power_on(tpo_td043);
+ if (r)
+ goto err1;
+ }
+
+ dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+
+ return 0;
+err1:
+ omapdss_dpi_display_disable(dssdev);
+err0:
+ return r;
+}
+
+static void tpo_td043_disable_dss(struct omap_dss_device *dssdev)
+{
+ struct tpo_td043_device *tpo_td043 = dev_get_drvdata(&dssdev->dev);
+
+ if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
if (dssdev->platform_disable)
dssdev->platform_disable(dssdev);
omapdss_dpi_display_disable(dssdev);
+
+ if (!tpo_td043->spi_suspended)
+ tpo_td043_power_off(tpo_td043);
}
static int tpo_td043_enable(struct omap_dss_device *dssdev)
{
- int ret;
-
dev_dbg(&dssdev->dev, "enable\n");
- ret = tpo_td043_power_on(dssdev);
- if (ret)
- return ret;
-
- dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
-
- return 0;
+ return tpo_td043_enable_dss(dssdev);
}
static void tpo_td043_disable(struct omap_dss_device *dssdev)
{
dev_dbg(&dssdev->dev, "disable\n");
- tpo_td043_power_off(dssdev);
+ tpo_td043_disable_dss(dssdev);
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
}
static int tpo_td043_suspend(struct omap_dss_device *dssdev)
{
- tpo_td043_power_off(dssdev);
+ dev_dbg(&dssdev->dev, "suspend\n");
+
+ tpo_td043_disable_dss(dssdev);
+
dssdev->state = OMAP_DSS_DISPLAY_SUSPENDED;
+
return 0;
}
static int tpo_td043_resume(struct omap_dss_device *dssdev)
{
- int r = 0;
-
- r = tpo_td043_power_on(dssdev);
- if (r)
- return r;
-
- dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+ dev_dbg(&dssdev->dev, "resume\n");
- return 0;
+ return tpo_td043_enable_dss(dssdev);
}
static int tpo_td043_probe(struct omap_dss_device *dssdev)
@@ -491,6 +519,7 @@ static int tpo_td043_spi_probe(struct spi_device *spi)
return -ENOMEM;
tpo_td043->spi = spi;
+ tpo_td043->nreset_gpio = dssdev->reset_gpio;
dev_set_drvdata(&spi->dev, tpo_td043);
dev_set_drvdata(&dssdev->dev, tpo_td043);
@@ -509,10 +538,46 @@ static int __devexit tpo_td043_spi_remove(struct spi_device *spi)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int tpo_td043_spi_suspend(struct device *dev)
+{
+ struct tpo_td043_device *tpo_td043 = dev_get_drvdata(dev);
+
+ dev_dbg(dev, "tpo_td043_spi_suspend, tpo %p\n", tpo_td043);
+
+ tpo_td043->power_on_resume = tpo_td043->powered_on;
+ tpo_td043_power_off(tpo_td043);
+ tpo_td043->spi_suspended = 1;
+
+ return 0;
+}
+
+static int tpo_td043_spi_resume(struct device *dev)
+{
+ struct tpo_td043_device *tpo_td043 = dev_get_drvdata(dev);
+ int ret;
+
+ dev_dbg(dev, "tpo_td043_spi_resume\n");
+
+ if (tpo_td043->power_on_resume) {
+ ret = tpo_td043_power_on(tpo_td043);
+ if (ret)
+ return ret;
+ }
+ tpo_td043->spi_suspended = 0;
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(tpo_td043_spi_pm,
+ tpo_td043_spi_suspend, tpo_td043_spi_resume);
+
static struct spi_driver tpo_td043_spi_driver = {
.driver = {
.name = "tpo_td043mtea1_panel_spi",
.owner = THIS_MODULE,
+ .pm = &tpo_td043_spi_pm,
},
.probe = tpo_td043_spi_probe,
.remove = __devexit_p(tpo_td043_spi_remove),
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/2] OMAPDSS: Features: Maintain dss_feats as a list
From: Archit Taneja @ 2012-02-06 11:51 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev
In-Reply-To: <1328527692.1997.2.camel@lappy>
On Monday 06 February 2012 04:58 PM, Tomi Valkeinen wrote:
> On Mon, 2012-02-06 at 16:54 +0530, Archit Taneja wrote:
>> On Monday 06 February 2012 04:12 PM, Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> On Mon, 2012-01-30 at 10:52 +0530, Archit Taneja wrote:
>>>> The number of dss_feat_id members has increased to a large value, the current
>>>> way of assigning a subset of these features (for a particular OMAP) as a mask
>>>> is no longer feasible.
>>>>
>>>> Maintain the subset of features supported as lists. Make the function
>>>> dss_has_feature() traverse through this list.
>>>
>>> I think this makes the code easier to maintain, so in that sense it is
>>> good. But I do hesitate a bit, I think many features are checked in
>>> often used code paths (the configuration done on each frame when
>>> swapping/panning), and bit compare versus finding an item in a list
>>> could have performance impact.
>>>
>>> Then again, I'm purely guessing here, as it could well be that compared
>>> to the other code, checking the features is insignificant. Thus, I'm
>>> fine with this patch, and we can optimize it later if need be.
>>>
>>> However, I'm anyway giving a few ideas how this could also be handled:
>>>
>>> - 64 bit mask. Would be simple, but we'd still have a hard limit there.
>>>
>>> - Variable length bitmask, i.e. an int or byte array from which a
>>> particular bit is checked. There could be a ready made datatype for this
>>> in the kernel.
>>>
>>
>> There seems to be a bitmask library:
>>
>> tools/power/cpupower/utils/helpers/bitmask.c
>>
>> I don't know how easy it would be to access this though.
>>
>>> - Lists like in this patch, but in sorted order. Then, if we're looking
>>> for a feat which has, say, number 4 assigned to it, we can stop
>>> iterating the list when we hit a feat> 4 in the list. Quite simple
>>> optimization, but needs extra maintenance to keep the feat lists sorted.
>>
>> This sounds fine. It shouldn't be too much of an effort to maintain
>> sorted lists. We'll just need to ensure that a new feature added has the
>> largest integer value, and is always added at the end of the list(s).
>
> Not necessarily. As we always search the list from index 0 forward, the
> most often needed features could be in the beginning of the list so they
> are found faster. At least some features are clearly needed only in some
> enable/disable paths or similar, and they could clearly be low priority.
Right, it would be harder to maintain sorted lists in this case, and it
wouldn't be always straight forward to decide which feature has more
priority over other :)
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: Features: Maintain dss_feats as a list
From: Archit Taneja @ 2012-02-06 11:36 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev
In-Reply-To: <1328524943.1898.38.camel@deskari>
On Monday 06 February 2012 04:12 PM, Tomi Valkeinen wrote:
> Hi,
>
> On Mon, 2012-01-30 at 10:52 +0530, Archit Taneja wrote:
>> The number of dss_feat_id members has increased to a large value, the current
>> way of assigning a subset of these features (for a particular OMAP) as a mask
>> is no longer feasible.
>>
>> Maintain the subset of features supported as lists. Make the function
>> dss_has_feature() traverse through this list.
>
> I think this makes the code easier to maintain, so in that sense it is
> good. But I do hesitate a bit, I think many features are checked in
> often used code paths (the configuration done on each frame when
> swapping/panning), and bit compare versus finding an item in a list
> could have performance impact.
>
> Then again, I'm purely guessing here, as it could well be that compared
> to the other code, checking the features is insignificant. Thus, I'm
> fine with this patch, and we can optimize it later if need be.
>
> However, I'm anyway giving a few ideas how this could also be handled:
>
> - 64 bit mask. Would be simple, but we'd still have a hard limit there.
>
> - Variable length bitmask, i.e. an int or byte array from which a
> particular bit is checked. There could be a ready made datatype for this
> in the kernel.
>
There seems to be a bitmask library:
tools/power/cpupower/utils/helpers/bitmask.c
I don't know how easy it would be to access this though.
> - Lists like in this patch, but in sorted order. Then, if we're looking
> for a feat which has, say, number 4 assigned to it, we can stop
> iterating the list when we hit a feat> 4 in the list. Quite simple
> optimization, but needs extra maintenance to keep the feat lists sorted.
This sounds fine. It shouldn't be too much of an effort to maintain
sorted lists. We'll just need to ensure that a new feature added has the
largest integer value, and is always added at the end of the list(s).
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: Features: Maintain dss_feats as a list
From: Tomi Valkeinen @ 2012-02-06 11:28 UTC (permalink / raw)
To: Archit Taneja; +Cc: Archit Taneja, linux-omap, linux-fbdev
In-Reply-To: <4F2FB86D.2090205@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]
On Mon, 2012-02-06 at 16:54 +0530, Archit Taneja wrote:
> On Monday 06 February 2012 04:12 PM, Tomi Valkeinen wrote:
> > Hi,
> >
> > On Mon, 2012-01-30 at 10:52 +0530, Archit Taneja wrote:
> >> The number of dss_feat_id members has increased to a large value, the current
> >> way of assigning a subset of these features (for a particular OMAP) as a mask
> >> is no longer feasible.
> >>
> >> Maintain the subset of features supported as lists. Make the function
> >> dss_has_feature() traverse through this list.
> >
> > I think this makes the code easier to maintain, so in that sense it is
> > good. But I do hesitate a bit, I think many features are checked in
> > often used code paths (the configuration done on each frame when
> > swapping/panning), and bit compare versus finding an item in a list
> > could have performance impact.
> >
> > Then again, I'm purely guessing here, as it could well be that compared
> > to the other code, checking the features is insignificant. Thus, I'm
> > fine with this patch, and we can optimize it later if need be.
> >
> > However, I'm anyway giving a few ideas how this could also be handled:
> >
> > - 64 bit mask. Would be simple, but we'd still have a hard limit there.
> >
> > - Variable length bitmask, i.e. an int or byte array from which a
> > particular bit is checked. There could be a ready made datatype for this
> > in the kernel.
> >
>
> There seems to be a bitmask library:
>
> tools/power/cpupower/utils/helpers/bitmask.c
>
> I don't know how easy it would be to access this though.
>
> > - Lists like in this patch, but in sorted order. Then, if we're looking
> > for a feat which has, say, number 4 assigned to it, we can stop
> > iterating the list when we hit a feat> 4 in the list. Quite simple
> > optimization, but needs extra maintenance to keep the feat lists sorted.
>
> This sounds fine. It shouldn't be too much of an effort to maintain
> sorted lists. We'll just need to ensure that a new feature added has the
> largest integer value, and is always added at the end of the list(s).
Not necessarily. As we always search the list from index 0 forward, the
most often needed features could be in the beginning of the list so they
are found faster. At least some features are clearly needed only in some
enable/disable paths or similar, and they could clearly be low priority.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: Features: Maintain dss_feats as a list
From: Tomi Valkeinen @ 2012-02-06 10:42 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1327900959-29198-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]
Hi,
On Mon, 2012-01-30 at 10:52 +0530, Archit Taneja wrote:
> The number of dss_feat_id members has increased to a large value, the current
> way of assigning a subset of these features (for a particular OMAP) as a mask
> is no longer feasible.
>
> Maintain the subset of features supported as lists. Make the function
> dss_has_feature() traverse through this list.
I think this makes the code easier to maintain, so in that sense it is
good. But I do hesitate a bit, I think many features are checked in
often used code paths (the configuration done on each frame when
swapping/panning), and bit compare versus finding an item in a list
could have performance impact.
Then again, I'm purely guessing here, as it could well be that compared
to the other code, checking the features is insignificant. Thus, I'm
fine with this patch, and we can optimize it later if need be.
However, I'm anyway giving a few ideas how this could also be handled:
- 64 bit mask. Would be simple, but we'd still have a hard limit there.
- Variable length bitmask, i.e. an int or byte array from which a
particular bit is checked. There could be a ready made datatype for this
in the kernel.
- Lists like in this patch, but in sorted order. Then, if we're looking
for a feat which has, say, number 4 assigned to it, we can stop
iterating the list when we hit a feat > 4 in the list. Quite simple
optimization, but needs extra maintenance to keep the feat lists sorted.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] MAINTAINERS: add maintainer entry for Exynos DP driver
From: Jingoo Han @ 2012-02-06 2:30 UTC (permalink / raw)
To: linux-fbdev
Add maintainer entry for Exynos DP driver which can be used for
Samsung Exynos SoC series.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
MAINTAINERS | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index ebb1936..f685bfd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2639,6 +2639,12 @@ M: Mimi Zohar <zohar@us.ibm.com>
S: Supported
F: security/integrity/evm/
+EXYNOS DP DRIVER
+M: Jingoo Han <jg1.han@samsung.com>
+L: linux-fbdev@vger.kernel.org
+S: Maintained
+F: drivers/video/exynos/exynos_dp*
+
F71805F HARDWARE MONITORING DRIVER
M: Jean Delvare <khali@linux-fr.org>
L: lm-sensors@lm-sensors.org
--
^ permalink raw reply related
* Re: [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
From: Michael Neuling @ 2012-02-05 22:25 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linuxppc-dev@ozlabs.org, linux-fbdev@vger.kernel.org,
Tabi Timur-B04825
In-Reply-To: <4F26274B.2040401@gmx.de>
In message <4F26274B.2040401@gmx.de> you wrote:
> On 01/16/2012 03:08 AM, Michael Neuling wrote:
> [...]
> > From: Michael Neuling <mikey@neuling.org>
> >
> > [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
> >
> > Fix a compiler errors introduced in:
> > commit ddd3d905436b572ebadc09dcf2d12ca5b37020a0
> > Author: Timur Tabi <timur@freescale.com>
> > drivers/video: fsl-diu-fb: merge all allocated data into one block
> >
> > Signed-off-by: Michael Neuling <mikey@neuling.org>
>
> Applied.
Florian,
I've not seen this appear in mainline as yet.
When do you expect to send a pull request?
Mikey
^ permalink raw reply
* Re: fsl-diu: enable_lcdc() takes a pointer, not struct...
From: Tabi Timur-B04825 @ 2012-02-05 15:12 UTC (permalink / raw)
To: Al Viro
Cc: Tabi Timur-B04825, linux-kernel@vger.kernel.org,
mikey@neuling.org, FlorianSchandinat@gmx.de,
linux-fbdev@vger.kernel.org
In-Reply-To: <20120205062835.GA23916@ZenIV.linux.org.uk>
Al Viro wrote:
> A couple of places missed in commit ddd3d905436b572ebadc09dcf2d12ca5b37020a0...
>
> Signed-off-by: Al Viro<viro@zeniv.linux.org.uk>
This is already fixed in fbdev, although I can't find the patch in the
archives (http://marc.info/?l=linux-fbdev&r=3&b 1201&w=2).
>
> diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
> index acf292b..629ae00 100644
> --- a/drivers/video/fsl-diu-fb.c
> +++ b/drivers/video/fsl-diu-fb.c
> @@ -1432,7 +1432,7 @@ static int fsl_diu_suspend(struct platform_device *ofdev, pm_message_t state)
> struct fsl_diu_data *data;
>
> data = dev_get_drvdata(&ofdev->dev);
> - disable_lcdc(data->fsl_diu_info[0]);
> + disable_lcdc(&data->fsl_diu_info[0]);
>
> return 0;
> }
> @@ -1442,7 +1442,7 @@ static int fsl_diu_resume(struct platform_device *ofdev)
> struct fsl_diu_data *data;
>
> data = dev_get_drvdata(&ofdev->dev);
> - enable_lcdc(data->fsl_diu_info[0]);
> + enable_lcdc(&data->fsl_diu_info[0]);
>
> return 0;
> }
>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] backlight: add support for Pandora backlight
From: Grazvydas Ignotas @ 2012-02-04 20:35 UTC (permalink / raw)
To: linux-fbdev
This patch adds support for pandora (openpandora.org) backlight.
It might look like all this could be done using pwm_bl.c instead,
but there is a need of special programming sequence when turning
on the LED driver chip or else it will misbehave. Doing this using
pwm_bl.c would require to use some register programming and pwm
functions from platform code, and ARM maintainers are allergic to
driver-like code in /arch/arm nowadays. The PMIC PWM driver is
currently missing too, so pwm_bl.c can't be used anyway.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
---
drivers/video/backlight/Kconfig | 7 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/pandora_bl.c | 168 ++++++++++++++++++++++++++++++++++
3 files changed, 176 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/backlight/pandora_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 681b369..3f03954 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -334,6 +334,13 @@ config BACKLIGHT_AAT2870
If you have a AnalogicTech AAT2870 say Y to enable the
backlight driver.
+config BACKLIGHT_PANDORA
+ tristate "Backlight driver for Pandora console"
+ depends on TWL4030_CORE
+ help
+ If you have a Pandora console, say Y to enable the
+ backlight driver.
+
endif # BACKLIGHT_CLASS_DEVICE
endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index af5cf65..c73169c 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -38,4 +38,5 @@ obj-$(CONFIG_BACKLIGHT_ADP8870) += adp8870_bl.o
obj-$(CONFIG_BACKLIGHT_88PM860X) += 88pm860x_bl.o
obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
obj-$(CONFIG_BACKLIGHT_AAT2870) += aat2870_bl.o
+obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
diff --git a/drivers/video/backlight/pandora_bl.c b/drivers/video/backlight/pandora_bl.c
new file mode 100644
index 0000000..63d1c4a
--- /dev/null
+++ b/drivers/video/backlight/pandora_bl.c
@@ -0,0 +1,168 @@
+/*
+ * Backlight driver for Pandora handheld.
+ * Pandora uses TWL4030 PWM0 -> TPS61161 combo for control backlight.
+ * Based on pwm_bl.c
+ *
+ * Copyright 2009,2012 Gražvydas Ignotas <notasas@gmail.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.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/fb.h>
+#include <linux/backlight.h>
+#include <linux/i2c/twl.h>
+#include <linux/err.h>
+
+#define TWL_PWM0_ON 0x00
+#define TWL_PWM0_OFF 0x01
+
+#define TWL_INTBR_GPBR1 0x0c
+#define TWL_INTBR_PMBR1 0x0d
+
+#define TWL_PMBR1_PWM0_MUXMASK 0x0c
+#define TWL_PMBR1_PWM0 0x04
+#define PWM0_CLK_ENABLE BIT(0)
+#define PWM0_ENABLE BIT(2)
+
+/* range accepted by hardware */
+#define MIN_VALUE 9
+#define MAX_VALUE 63
+#define MAX_USER_VALUE (MAX_VALUE - MIN_VALUE)
+
+#define PANDORABL_WAS_OFF BL_CORE_DRIVER1
+
+static int pandora_backlight_update_status(struct backlight_device *bl)
+{
+ int brightness = bl->props.brightness;
+ u8 r;
+
+ if (bl->props.power != FB_BLANK_UNBLANK)
+ brightness = 0;
+ if (bl->props.state & BL_CORE_FBBLANK)
+ brightness = 0;
+ if (bl->props.state & BL_CORE_SUSPENDED)
+ brightness = 0;
+
+ if ((unsigned int)brightness > MAX_USER_VALUE)
+ brightness = MAX_USER_VALUE;
+
+ if (brightness = 0 && !(bl->props.state & PANDORABL_WAS_OFF)) {
+ /* first disable PWM0 output, then clock */
+ twl_i2c_read_u8(TWL4030_MODULE_INTBR, &r, TWL_INTBR_GPBR1);
+ r &= ~PWM0_ENABLE;
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR, r, TWL_INTBR_GPBR1);
+ r &= ~PWM0_CLK_ENABLE;
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR, r, TWL_INTBR_GPBR1);
+
+ goto done;
+ }
+
+ if (bl->props.state & PANDORABL_WAS_OFF) {
+ /*
+ * set PWM duty cycle to max. TPS61161 seems to use this
+ * to calibrate it's PWM sensitivity when it starts.
+ */
+ twl_i2c_write_u8(TWL4030_MODULE_PWM0, MAX_VALUE,
+ TWL_PWM0_OFF);
+
+ /* first enable clock, then PWM0 out */
+ twl_i2c_read_u8(TWL4030_MODULE_INTBR, &r, TWL_INTBR_GPBR1);
+ r &= ~PWM0_ENABLE;
+ r |= PWM0_CLK_ENABLE;
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR, r, TWL_INTBR_GPBR1);
+ r |= PWM0_ENABLE;
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR, r, TWL_INTBR_GPBR1);
+
+ /*
+ * TI made it very easy to enable digital control, so easy that
+ * it often triggers unintentionally and disabes PWM control,
+ * so wait until 1 wire mode detection window ends.
+ */
+ usleep_range(2000, 10000);
+ }
+
+ twl_i2c_write_u8(TWL4030_MODULE_PWM0, MIN_VALUE + brightness,
+ TWL_PWM0_OFF);
+
+done:
+ if (brightness != 0)
+ bl->props.state &= ~PANDORABL_WAS_OFF;
+ else
+ bl->props.state |= PANDORABL_WAS_OFF;
+
+ return 0;
+}
+
+static int pandora_backlight_get_brightness(struct backlight_device *bl)
+{
+ return bl->props.brightness;
+}
+
+static const struct backlight_ops pandora_backlight_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = pandora_backlight_update_status,
+ .get_brightness = pandora_backlight_get_brightness,
+};
+
+static int pandora_backlight_probe(struct platform_device *pdev)
+{
+ struct backlight_properties props;
+ struct backlight_device *bl;
+ u8 r;
+
+ memset(&props, 0, sizeof(props));
+ props.max_brightness = MAX_USER_VALUE;
+ props.type = BACKLIGHT_RAW;
+ bl = backlight_device_register(pdev->name, &pdev->dev,
+ NULL, &pandora_backlight_ops, &props);
+ if (IS_ERR(bl)) {
+ dev_err(&pdev->dev, "failed to register backlight\n");
+ return PTR_ERR(bl);
+ }
+
+ platform_set_drvdata(pdev, bl);
+
+ /* 64 cycle period, ON position 0 */
+ twl_i2c_write_u8(TWL4030_MODULE_PWM0, 0x80, TWL_PWM0_ON);
+
+ bl->props.state |= PANDORABL_WAS_OFF;
+ bl->props.brightness = MAX_USER_VALUE;
+ backlight_update_status(bl);
+
+ /* enable PWM function in pin mux */
+ twl_i2c_read_u8(TWL4030_MODULE_INTBR, &r, TWL_INTBR_PMBR1);
+ r &= ~TWL_PMBR1_PWM0_MUXMASK;
+ r |= TWL_PMBR1_PWM0;
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR, r, TWL_INTBR_PMBR1);
+
+ return 0;
+}
+
+static int pandora_backlight_remove(struct platform_device *pdev)
+{
+ struct backlight_device *bl = platform_get_drvdata(pdev);
+ backlight_device_unregister(bl);
+ return 0;
+}
+
+static struct platform_driver pandora_backlight_driver = {
+ .driver = {
+ .name = "pandora-backlight",
+ .owner = THIS_MODULE,
+ },
+ .probe = pandora_backlight_probe,
+ .remove = pandora_backlight_remove,
+};
+
+module_platform_driver(pandora_backlight_driver);
+
+MODULE_AUTHOR("Gražvydas Ignotas <notasas@gmail.com>");
+MODULE_DESCRIPTION("Pandora Backlight Driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:pandora-backlight");
--
1.7.0.4
^ permalink raw reply related
* [PATCH 13/13] FB: sa11x0: convert shannon display enable accesses to use GPIO subsystem
From: Russell King - ARM Linux @ 2012-02-04 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120204093744.GQ889@n2100.arm.linux.org.uk>
Rather than accessing GPSR and GPCR directly, use the GPIO subsystem
instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/mach-sa1100/include/mach/shannon.h | 2 +-
drivers/video/sa1100fb.c | 24 ++++++++++++++++--------
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-sa1100/include/mach/shannon.h b/arch/arm/mach-sa1100/include/mach/shannon.h
index ec27d6e..a0d1114 100644
--- a/arch/arm/mach-sa1100/include/mach/shannon.h
+++ b/arch/arm/mach-sa1100/include/mach/shannon.h
@@ -21,7 +21,7 @@
#define SHANNON_GPIO_U3_RTS GPIO_GPIO (19) /* ?? */
#define SHANNON_GPIO_U3_CTS GPIO_GPIO (20) /* ?? */
#define SHANNON_GPIO_SENSE_12V GPIO_GPIO (21) /* Input, 12v flash unprotect detected */
-#define SHANNON_GPIO_DISP_EN GPIO_GPIO (22) /* out */
+#define SHANNON_GPIO_DISP_EN 22 /* out */
/* XXX GPIO 23 unaccounted for */
#define SHANNON_GPIO_EJECT_0 GPIO_GPIO (24) /* in */
#define SHANNON_IRQ_GPIO_EJECT_0 IRQ_GPIO24
diff --git a/drivers/video/sa1100fb.c b/drivers/video/sa1100fb.c
index f3f55eb..379b2c5 100644
--- a/drivers/video/sa1100fb.c
+++ b/drivers/video/sa1100fb.c
@@ -173,6 +173,7 @@
#include <linux/init.h>
#include <linux/ioport.h>
#include <linux/cpufreq.h>
+#include <linux/gpio.h>
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/mutex.h>
@@ -796,10 +797,8 @@ static void sa1100fb_enable_controller(struct sa1100fb_info *fbi)
DBAR2 = fbi->dbar2;
LCCR0 |= LCCR0_LEN;
- if (machine_is_shannon()) {
- GPDR |= SHANNON_GPIO_DISP_EN;
- GPSR = SHANNON_GPIO_DISP_EN;
- }
+ if (machine_is_shannon())
+ gpio_set_value(SHANNON_GPIO_DISP_EN, 1);
dev_dbg(fbi->dev, "DBAR1 = 0x%08lx\n", DBAR1);
dev_dbg(fbi->dev, "DBAR2 = 0x%08lx\n", DBAR2);
@@ -815,9 +814,8 @@ static void sa1100fb_disable_controller(struct sa1100fb_info *fbi)
dev_dbg(fbi->dev, "Disabling LCD controller\n");
- if (machine_is_shannon()) {
- GPCR = SHANNON_GPIO_DISP_EN;
- }
+ if (machine_is_shannon())
+ gpio_set_value(SHANNON_GPIO_DISP_EN, 0);
set_current_state(TASK_UNINTERRUPTIBLE);
add_wait_queue(&fbi->ctrlr_wait, &wait);
@@ -1230,6 +1228,13 @@ static int __devinit sa1100fb_probe(struct platform_device *pdev)
goto failed;
}
+ if (machine_is_shannon()) {
+ ret = gpio_request_one(SHANNON_GPIO_DISP_EN,
+ GPIOF_OUT_INIT_LOW, "display enable");
+ if (ret)
+ goto err_free_irq;
+ }
+
/*
* This makes sure that our colour bitfield
* descriptors are correctly initialised.
@@ -1240,7 +1245,7 @@ static int __devinit sa1100fb_probe(struct platform_device *pdev)
ret = register_framebuffer(&fbi->fb);
if (ret < 0)
- goto err_free_irq;
+ goto err_reg_fb;
#ifdef CONFIG_CPU_FREQ
fbi->freq_transition.notifier_call = sa1100fb_freq_transition;
@@ -1252,6 +1257,9 @@ static int __devinit sa1100fb_probe(struct platform_device *pdev)
/* This driver cannot be unloaded at the moment */
return 0;
+ err_reg_fb:
+ if (machine_is_shannon())
+ gpio_free(SHANNON_GPIO_DISP_EN);
err_free_irq:
free_irq(irq, fbi);
failed:
--
1.7.4.4
^ permalink raw reply related
* [PATCH 12/13] FB: sa11x0: fix shannon GPSR/GPCR accesses
From: Russell King - ARM Linux @ 2012-02-04 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120204093744.GQ889@n2100.arm.linux.org.uk>
The GPIO set and clear registers should only be written, rather than
read, modified, and written. A read-modify-write will have undesired
side effects.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/video/sa1100fb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/sa1100fb.c b/drivers/video/sa1100fb.c
index b644f0f..f3f55eb 100644
--- a/drivers/video/sa1100fb.c
+++ b/drivers/video/sa1100fb.c
@@ -798,7 +798,7 @@ static void sa1100fb_enable_controller(struct sa1100fb_info *fbi)
if (machine_is_shannon()) {
GPDR |= SHANNON_GPIO_DISP_EN;
- GPSR |= SHANNON_GPIO_DISP_EN;
+ GPSR = SHANNON_GPIO_DISP_EN;
}
dev_dbg(fbi->dev, "DBAR1 = 0x%08lx\n", DBAR1);
@@ -816,7 +816,7 @@ static void sa1100fb_disable_controller(struct sa1100fb_info *fbi)
dev_dbg(fbi->dev, "Disabling LCD controller\n");
if (machine_is_shannon()) {
- GPCR |= SHANNON_GPIO_DISP_EN;
+ GPCR = SHANNON_GPIO_DISP_EN;
}
set_current_state(TASK_UNINTERRUPTIBLE);
--
1.7.4.4
^ permalink raw reply related
* [PATCH 11/13] FB: sa1100: make GPIO configuration setting safe
From: Russell King - ARM Linux @ 2012-02-04 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120204093744.GQ889@n2100.arm.linux.org.uk>
The sa1100fb driver needs to set the GPIO direction and alternate
function register according to the panel that we're driving. We've
done this in the driver by read-modify-writing the register, which
may cause problems with races. Fix this with a minimal change.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/video/sa1100fb.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/video/sa1100fb.c b/drivers/video/sa1100fb.c
index d1d97ca..b644f0f 100644
--- a/drivers/video/sa1100fb.c
+++ b/drivers/video/sa1100fb.c
@@ -761,8 +761,19 @@ static void sa1100fb_setup_gpio(struct sa1100fb_info *fbi)
}
if (mask) {
+ unsigned long flags;
+
+ /*
+ * SA-1100 requires the GPIO direction register set
+ * appropriately for the alternate function. Hence
+ * we set it here via bitmask rather than excessive
+ * fiddling via the GPIO subsystem - and even then
+ * we'll still have to deal with GAFR.
+ */
+ local_irq_save(flags);
GPDR |= mask;
GAFR |= mask;
+ local_irq_restore(flags);
}
}
--
1.7.4.4
^ permalink raw reply related
* [PATCH 10/13] FB: sa1100: use inf members directly
From: Russell King - ARM Linux @ 2012-02-04 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120204093744.GQ889@n2100.arm.linux.org.uk>
Now that the LCD information is available while the driver is loaded,
we don't need to cache that information into our driver private data
structure. Get rid of it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/video/sa1100fb.c | 31 ++++++++++++-------------------
drivers/video/sa1100fb.h | 10 ----------
2 files changed, 12 insertions(+), 29 deletions(-)
diff --git a/drivers/video/sa1100fb.c b/drivers/video/sa1100fb.c
index f6e27f4..d1d97ca 100644
--- a/drivers/video/sa1100fb.c
+++ b/drivers/video/sa1100fb.c
@@ -298,7 +298,7 @@ sa1100fb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
* is what you poke into the framebuffer to produce the
* colour you requested.
*/
- if (fbi->cmap_inverse) {
+ if (fbi->inf->cmap_inverse) {
red = 0xffff - red;
green = 0xffff - green;
blue = 0xffff - blue;
@@ -372,10 +372,10 @@ sa1100fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
var->xres = MIN_XRES;
if (var->yres < MIN_YRES)
var->yres = MIN_YRES;
- if (var->xres > fbi->max_xres)
- var->xres = fbi->max_xres;
- if (var->yres > fbi->max_yres)
- var->yres = fbi->max_yres;
+ if (var->xres > fbi->inf->xres)
+ var->xres = fbi->inf->xres;
+ if (var->yres > fbi->inf->yres)
+ var->yres = fbi->inf->yres;
var->xres_virtual = max(var->xres_virtual, var->xres);
var->yres_virtual = max(var->yres_virtual, var->yres);
@@ -440,7 +440,7 @@ static int sa1100fb_set_par(struct fb_info *info)
if (var->bits_per_pixel = 16)
fbi->fb.fix.visual = FB_VISUAL_TRUECOLOR;
- else if (!fbi->cmap_static)
+ else if (!fbi->inf->cmap_static)
fbi->fb.fix.visual = FB_VISUAL_PSEUDOCOLOR;
else {
/*
@@ -481,7 +481,7 @@ sa1100fb_set_cmap(struct fb_cmap *cmap, int kspc, int con,
/*
* Make sure the user isn't doing something stupid.
*/
- if (!kspc && (fbi->fb.var.bits_per_pixel = 16 || fbi->cmap_static))
+ if (!kspc && (fbi->fb.var.bits_per_pixel = 16 || fbi->inf->cmap_static))
return -EINVAL;
return gen_set_cmap(cmap, kspc, con, info);
@@ -652,7 +652,7 @@ static int sa1100fb_activate_var(struct fb_var_screeninfo *var, struct sa1100fb_
fbi->fb.fix.id, var->lower_margin);
#endif
- new_regs.lccr0 = fbi->lccr0 |
+ new_regs.lccr0 = fbi->inf->lccr0 |
LCCR0_LEN | LCCR0_LDM | LCCR0_BAM |
LCCR0_ERM | LCCR0_LtlEnd | LCCR0_DMADel(0);
@@ -667,7 +667,7 @@ static int sa1100fb_activate_var(struct fb_var_screeninfo *var, struct sa1100fb_
* the YRES parameter.
*/
yres = var->yres;
- if (fbi->lccr0 & LCCR0_Dual)
+ if (fbi->inf->lccr0 & LCCR0_Dual)
yres /= 2;
new_regs.lccr2 @@ -677,7 +677,7 @@ static int sa1100fb_activate_var(struct fb_var_screeninfo *var, struct sa1100fb_
LCCR2_EndFrmDel(var->lower_margin);
pcd = get_pcd(var->pixclock, cpufreq_get(0));
- new_regs.lccr3 = LCCR3_PixClkDiv(pcd) | fbi->lccr3 |
+ new_regs.lccr3 = LCCR3_PixClkDiv(pcd) | fbi->inf->lccr3 |
(var->sync & FB_SYNC_HOR_HIGH_ACT ? LCCR3_HorSnchH : LCCR3_HorSnchL) |
(var->sync & FB_SYNC_VERT_HIGH_ACT ? LCCR3_VrtSnchH : LCCR3_VrtSnchL);
@@ -1154,13 +1154,10 @@ static struct sa1100fb_info * __devinit sa1100fb_init_fbinfo(struct device *dev)
panic("sa1100fb error: invalid LCCR3 fields set or zero "
"pixclock.");
- fbi->max_xres = inf->xres;
fbi->fb.var.xres = inf->xres;
fbi->fb.var.xres_virtual = inf->xres;
- fbi->max_yres = inf->yres;
fbi->fb.var.yres = inf->yres;
fbi->fb.var.yres_virtual = inf->yres;
- fbi->max_bpp = inf->bpp;
fbi->fb.var.bits_per_pixel = inf->bpp;
fbi->fb.var.pixclock = inf->pixclock;
fbi->fb.var.hsync_len = inf->hsync_len;
@@ -1171,14 +1168,10 @@ static struct sa1100fb_info * __devinit sa1100fb_init_fbinfo(struct device *dev)
fbi->fb.var.lower_margin = inf->lower_margin;
fbi->fb.var.sync = inf->sync;
fbi->fb.var.grayscale = inf->cmap_greyscale;
- fbi->cmap_inverse = inf->cmap_inverse;
- fbi->cmap_static = inf->cmap_static;
- fbi->lccr0 = inf->lccr0;
- fbi->lccr3 = inf->lccr3;
fbi->state = C_STARTUP;
fbi->task_state = (u_char)-1;
- fbi->fb.fix.smem_len = fbi->max_xres * fbi->max_yres *
- fbi->max_bpp / 8;
+ fbi->fb.fix.smem_len = inf->xres * inf->yres *
+ inf->bpp / 8;
fbi->inf = inf;
/* Copy the RGB bitfield overrides */
diff --git a/drivers/video/sa1100fb.h b/drivers/video/sa1100fb.h
index 3a634ab..e968e1d 100644
--- a/drivers/video/sa1100fb.h
+++ b/drivers/video/sa1100fb.h
@@ -23,10 +23,6 @@ struct sa1100fb_info {
struct device *dev;
const struct sa1100fb_rgb *rgb[NR_RGB];
- u_int max_bpp;
- u_int max_xres;
- u_int max_yres;
-
/*
* These are the addresses we mapped
* the framebuffer memory region to.
@@ -44,12 +40,6 @@ struct sa1100fb_info {
dma_addr_t dbar1;
dma_addr_t dbar2;
- u_int lccr0;
- u_int lccr3;
- u_int cmap_inverse:1,
- cmap_static:1,
- unused:30;
-
u_int reg_lccr0;
u_int reg_lccr1;
u_int reg_lccr2;
--
1.7.4.4
^ permalink raw reply related
* [PATCH 09/13] FB: sa1100: remove assabet specific initialization
From: Russell King - ARM Linux @ 2012-02-04 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120204093744.GQ889@n2100.arm.linux.org.uk>
Remove the assabet specific initialization for PAL output mode -
we call the lcd_power function before we enable the LCD controller,
which will disable the LCD panel to prevent it receiving incorrect
timings. Therefore, this setup here is redundant.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/video/sa1100fb.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/video/sa1100fb.c b/drivers/video/sa1100fb.c
index c9f1e7c..f6e27f4 100644
--- a/drivers/video/sa1100fb.c
+++ b/drivers/video/sa1100fb.c
@@ -182,7 +182,6 @@
#include <mach/hardware.h>
#include <asm/mach-types.h>
-#include <mach/assabet.h>
#include <mach/shannon.h>
/*
@@ -190,8 +189,6 @@
*/
#define DEBUG_VAR 1
-#undef ASSABET_PAL_VIDEO
-
#include "sa1100fb.h"
static const struct sa1100fb_rgb rgb_4 = {
@@ -1229,11 +1226,6 @@ static int __devinit sa1100fb_probe(struct platform_device *pdev)
goto failed;
}
-#ifdef ASSABET_PAL_VIDEO
- if (machine_is_assabet())
- ASSABET_BCR_clear(ASSABET_BCR_LCD_ON);
-#endif
-
/*
* This makes sure that our colour bitfield
* descriptors are correctly initialised.
--
1.7.4.4
^ permalink raw reply related
* [PATCH 08/13] FB: sa1100: remove global sa1100fb_.*_power function pointers
From: Russell King - ARM Linux @ 2012-02-04 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120204093744.GQ889@n2100.arm.linux.org.uk>
Now that we have platform data contained within the individual board
code, we can get rid of the global function pointers, placing them
inside the platform data instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/mach-sa1100/assabet.c | 90 ++++++++++++++++++++++++++-------------
arch/arm/mach-sa1100/generic.c | 6 ---
arch/arm/mach-sa1100/generic.h | 3 -
arch/arm/mach-sa1100/h3100.c | 3 +-
arch/arm/mach-sa1100/h3600.c | 3 +-
drivers/video/sa1100fb.c | 32 ++++----------
drivers/video/sa1100fb.h | 2 +
include/video/sa1100fb.h | 4 ++
8 files changed, 79 insertions(+), 64 deletions(-)
diff --git a/arch/arm/mach-sa1100/assabet.c b/arch/arm/mach-sa1100/assabet.c
index 37fb0cd..65b0a9a 100644
--- a/arch/arm/mach-sa1100/assabet.c
+++ b/arch/arm/mach-sa1100/assabet.c
@@ -71,33 +71,6 @@ void ASSABET_BCR_frob(unsigned int mask, unsigned int val)
EXPORT_SYMBOL(ASSABET_BCR_frob);
-static void assabet_backlight_power(int on)
-{
-#ifndef ASSABET_PAL_VIDEO
- if (on)
- ASSABET_BCR_set(ASSABET_BCR_LIGHT_ON);
- else
-#endif
- ASSABET_BCR_clear(ASSABET_BCR_LIGHT_ON);
-}
-
-/*
- * Turn on/off the backlight. When turning the backlight on,
- * we wait 500us after turning it on so we don't cause the
- * supplies to droop when we enable the LCD controller (and
- * cause a hard reset.)
- */
-static void assabet_lcd_power(int on)
-{
-#ifndef ASSABET_PAL_VIDEO
- if (on) {
- ASSABET_BCR_set(ASSABET_BCR_LCD_ON);
- udelay(500);
- } else
-#endif
- ASSABET_BCR_clear(ASSABET_BCR_LCD_ON);
-}
-
/*
* Assabet flash support code.
@@ -206,7 +179,49 @@ static struct mcp_plat_data assabet_mcp_data = {
.sclk_rate = 11981000,
};
+static void assabet_lcd_set_visual(u32 visual)
+{
+ u_int is_true_color = visual = FB_VISUAL_TRUECOLOR;
+
+ if (machine_is_assabet()) {
+#if 1 // phase 4 or newer Assabet's
+ if (is_true_color)
+ ASSABET_BCR_set(ASSABET_BCR_LCD_12RGB);
+ else
+ ASSABET_BCR_clear(ASSABET_BCR_LCD_12RGB);
+#else
+ // older Assabet's
+ if (is_true_color)
+ ASSABET_BCR_clear(ASSABET_BCR_LCD_12RGB);
+ else
+ ASSABET_BCR_set(ASSABET_BCR_LCD_12RGB);
+#endif
+ }
+}
+
#ifndef ASSABET_PAL_VIDEO
+static void assabet_lcd_backlight_power(int on)
+{
+ if (on)
+ ASSABET_BCR_set(ASSABET_BCR_LIGHT_ON);
+ else
+ ASSABET_BCR_clear(ASSABET_BCR_LIGHT_ON);
+}
+
+/*
+ * Turn on/off the backlight. When turning the backlight on, we wait
+ * 500us after turning it on so we don't cause the supplies to droop
+ * when we enable the LCD controller (and cause a hard reset.)
+ */
+static void assabet_lcd_power(int on)
+{
+ if (on) {
+ ASSABET_BCR_set(ASSABET_BCR_LCD_ON);
+ udelay(500);
+ } else
+ ASSABET_BCR_clear(ASSABET_BCR_LCD_ON);
+}
+
/*
* The assabet uses a sharp LQ039Q2DS54 LCD module. It is actually
* takes an RGB666 signal, but we provide it with an RGB565 signal
@@ -224,8 +239,22 @@ static struct sa1100fb_mach_info lq039q2ds54_info = {
.lccr0 = LCCR0_Color | LCCR0_Sngl | LCCR0_Act,
.lccr3 = LCCR3_OutEnH | LCCR3_PixRsEdg | LCCR3_ACBsDiv(2),
+
+ .backlight_power = assabet_lcd_backlight_power,
+ .lcd_power = assabet_lcd_power,
+ .set_visual = assabet_lcd_set_visual,
};
#else
+static void assabet_pal_backlight_power(int on)
+{
+ ASSABET_BCR_clear(ASSABET_BCR_LIGHT_ON);
+}
+
+static void assabet_pal_power(int on)
+{
+ ASSABET_BCR_clear(ASSABET_BCR_LCD_ON);
+}
+
static struct sa1100fb_mach_info pal_info = {
.pixclock = 67797, .bpp = 16,
.xres = 640, .yres = 512,
@@ -236,6 +265,10 @@ static struct sa1100fb_mach_info pal_info = {
.lccr0 = LCCR0_Color | LCCR0_Sngl | LCCR0_Act,
.lccr3 = LCCR3_OutEnH | LCCR3_PixRsEdg | LCCR3_ACBsDiv(512),
+
+ .backlight_power = assabet_pal_backlight_power,
+ .lcd_power = assabet_pal_power,
+ .set_visual = assabet_lcd_set_visual,
};
#endif
@@ -266,9 +299,6 @@ static void __init assabet_init(void)
PPDR |= PPC_TXD3 | PPC_TXD1;
PPSR |= PPC_TXD3 | PPC_TXD1;
- sa1100fb_lcd_power = assabet_lcd_power;
- sa1100fb_backlight_power = assabet_backlight_power;
-
if (machine_has_neponset()) {
/*
* Angel sets this, but other bootloaders may not.
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index f57808f..9cb4062 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -374,12 +374,6 @@ static int __init sa1100_init(void)
arch_initcall(sa1100_init);
-void (*sa1100fb_backlight_power)(int on);
-void (*sa1100fb_lcd_power)(int on);
-
-EXPORT_SYMBOL(sa1100fb_backlight_power);
-EXPORT_SYMBOL(sa1100fb_lcd_power);
-
/*
* Common I/O mapping:
diff --git a/arch/arm/mach-sa1100/generic.h b/arch/arm/mach-sa1100/generic.h
index 3b903f4..5c68be8 100644
--- a/arch/arm/mach-sa1100/generic.h
+++ b/arch/arm/mach-sa1100/generic.h
@@ -16,9 +16,6 @@ extern void sa11x0_restart(char, const char *);
mi->bank[__nr].start = (__start), \
mi->bank[__nr].size = (__size)
-extern void (*sa1100fb_backlight_power)(int on);
-extern void (*sa1100fb_lcd_power)(int on);
-
extern void sa1110_mb_enable(void);
extern void sa1110_mb_disable(void);
diff --git a/arch/arm/mach-sa1100/h3100.c b/arch/arm/mach-sa1100/h3100.c
index 1f8a271..f23e7d0 100644
--- a/arch/arm/mach-sa1100/h3100.c
+++ b/arch/arm/mach-sa1100/h3100.c
@@ -52,6 +52,8 @@ static struct sa1100fb_mach_info h3100_lcd_info = {
.lccr0 = LCCR0_Mono | LCCR0_4PixMono | LCCR0_Sngl | LCCR0_Pas,
.lccr3 = LCCR3_OutEnH | LCCR3_PixRsEdg | LCCR3_ACBsDiv(2),
+
+ .lcd_power = h3100_lcd_power,
};
static void __init h3100_map_io(void)
@@ -96,7 +98,6 @@ static void __init h3100_mach_init(void)
h3xxx_init_gpio(h3100_default_gpio, ARRAY_SIZE(h3100_default_gpio));
h3xxx_mach_init();
- sa1100fb_lcd_power = h3100_lcd_power;
sa11x0_register_lcd(&h3100_lcd_info);
sa11x0_register_irda(&h3100_irda_data);
}
diff --git a/arch/arm/mach-sa1100/h3600.c b/arch/arm/mach-sa1100/h3600.c
index 3dd39bf..2feac56 100644
--- a/arch/arm/mach-sa1100/h3600.c
+++ b/arch/arm/mach-sa1100/h3600.c
@@ -79,6 +79,8 @@ static struct sa1100fb_mach_info h3600_lcd_info = {
.lccr3 = LCCR3_OutEnH | LCCR3_PixRsEdg | LCCR3_ACBsDiv(2),
.rgb[RGB_16] = &h3600_rgb_16,
+
+ .lcd_power = h3600_lcd_power,
};
@@ -146,7 +148,6 @@ static void __init h3600_mach_init(void)
h3xxx_init_gpio(h3600_default_gpio, ARRAY_SIZE(h3600_default_gpio));
h3xxx_mach_init();
- sa1100fb_lcd_power = h3600_lcd_power;
sa11x0_register_lcd(&h3600_lcd_info);
sa11x0_register_irda(&h3600_irda_data);
}
diff --git a/drivers/video/sa1100fb.c b/drivers/video/sa1100fb.c
index d645c6d..c9f1e7c 100644
--- a/drivers/video/sa1100fb.c
+++ b/drivers/video/sa1100fb.c
@@ -194,9 +194,6 @@
#include "sa1100fb.h"
-extern void (*sa1100fb_backlight_power)(int on);
-extern void (*sa1100fb_lcd_power)(int on);
-
static const struct sa1100fb_rgb rgb_4 = {
.red = { .offset = 0, .length = 4, },
.green = { .offset = 0, .length = 4, },
@@ -426,22 +423,10 @@ sa1100fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
return 0;
}
-static inline void sa1100fb_set_truecolor(u_int is_true_color)
+static void sa1100fb_set_visual(struct sa1100fb_info *fbi, u32 visual)
{
- if (machine_is_assabet()) {
-#if 1 // phase 4 or newer Assabet's
- if (is_true_color)
- ASSABET_BCR_set(ASSABET_BCR_LCD_12RGB);
- else
- ASSABET_BCR_clear(ASSABET_BCR_LCD_12RGB);
-#else
- // older Assabet's
- if (is_true_color)
- ASSABET_BCR_clear(ASSABET_BCR_LCD_12RGB);
- else
- ASSABET_BCR_set(ASSABET_BCR_LCD_12RGB);
-#endif
- }
+ if (fbi->inf->set_visual)
+ fbi->inf->set_visual(visual);
}
/*
@@ -483,7 +468,7 @@ static int sa1100fb_set_par(struct fb_info *info)
/*
* Set (any) board control register to handle new color depth
*/
- sa1100fb_set_truecolor(fbi->fb.fix.visual = FB_VISUAL_TRUECOLOR);
+ sa1100fb_set_visual(fbi, fbi->fb.fix.visual);
sa1100fb_activate_var(var, fbi);
return 0;
@@ -740,16 +725,16 @@ static inline void __sa1100fb_backlight_power(struct sa1100fb_info *fbi, int on)
{
dev_dbg(fbi->dev, "backlight o%s\n", on ? "n" : "ff");
- if (sa1100fb_backlight_power)
- sa1100fb_backlight_power(on);
+ if (fbi->inf->backlight_power)
+ fbi->inf->backlight_power(on);
}
static inline void __sa1100fb_lcd_power(struct sa1100fb_info *fbi, int on)
{
dev_dbg(fbi->dev, "LCD power o%s\n", on ? "n" : "ff");
- if (sa1100fb_lcd_power)
- sa1100fb_lcd_power(on);
+ if (fbi->inf->lcd_power)
+ fbi->inf->lcd_power(on);
}
static void sa1100fb_setup_gpio(struct sa1100fb_info *fbi)
@@ -1197,6 +1182,7 @@ static struct sa1100fb_info * __devinit sa1100fb_init_fbinfo(struct device *dev)
fbi->task_state = (u_char)-1;
fbi->fb.fix.smem_len = fbi->max_xres * fbi->max_yres *
fbi->max_bpp / 8;
+ fbi->inf = inf;
/* Copy the RGB bitfield overrides */
for (i = 0; i < NR_RGB; i++)
diff --git a/drivers/video/sa1100fb.h b/drivers/video/sa1100fb.h
index 9ff9ba9..3a634ab 100644
--- a/drivers/video/sa1100fb.h
+++ b/drivers/video/sa1100fb.h
@@ -65,6 +65,8 @@ struct sa1100fb_info {
struct notifier_block freq_transition;
struct notifier_block freq_policy;
#endif
+
+ const struct sa1100fb_mach_info *inf;
};
#define TO_INF(ptr,member) container_of(ptr,struct sa1100fb_info,member)
diff --git a/include/video/sa1100fb.h b/include/video/sa1100fb.h
index e73c813..4ab4096 100644
--- a/include/video/sa1100fb.h
+++ b/include/video/sa1100fb.h
@@ -54,6 +54,10 @@ struct sa1100fb_mach_info {
/* Overrides for the default RGB maps */
const struct sa1100fb_rgb *rgb[NR_RGB];
+
+ void (*backlight_power)(int);
+ void (*lcd_power)(int);
+ void (*set_visual)(u32);
};
#endif
--
1.7.4.4
^ 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