[PATCH 00/16] rmk's patch series for fixing OMAP

[PATCH 00/16] rmk's patch series for fixing OMAP

[Russell King - ARM Linux]

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.

[PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c

[Russell King - ARM Linux]

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

Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c

[Tony Lindgren]

* 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>

Re: [PATCH 00/16] rmk's patch series for fixing OMAP

[Tony Lindgren]

* 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

Re: [PATCH 00/16] rmk's patch series for fixing OMAP

[Florian Tobias Schandinat]

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

Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c

[Russell King - ARM Linux]

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.

Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c

[Tony Lindgren]

* 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

Re: [PATCH 00/16] rmk's patch series for fixing OMAP

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 08:31:49PM +0000, Florian Tobias Schandinat wrote:
> 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?

I've no idea when the problem was introduced, that's not the point that
I'm making.  The point that I'm making is that the patch is dated January
17th, it was apparantly committed on the 26th, and it went into mainline
on the 8th February.

For a patch which fixes a _hardware_ _destruction_ issue, three weeks is
_FAR_ too long for it to take to get into mainline.

Moreover, only last Monday did I enable the OMAP2 DSS subsystem on the
4430 SDP platform, _including_ the HDMI code, and looking at the commit
it could be one of those platforms which is affected.

As I don't have a HDMI cable connected to the system, and I ran that
kernel overnight, and I tried opening each /dev/fb* device, what I'm now
wondering is: have I destroyed the HDMI PHY on my 4430SDP?

But that's not really the point.  The point is, for someone to sit on such
a patch for weeks is, in my opinion, as good as saying to your users "I
don't care if you bust your hardware."

However, you raise another point, a much more serious one at that.  Is
this problem also present in 3.2?  The patch seems to apply almost cleanly
to that kernel version, so I guess it is.  It fails to apply to v3.1
because of missing files, so I guess 3.1 is unaffected.

So, why isn't this patch copied to the stable people?

And why is there this seemingly lack of care for hardware destruction bugs?

Please, if it affects v3.2, PLEASE PLEASE PLEASE tell the stable people
who know nothing about this commit until I asked them this evening about
it.

> > 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.

For hardware destruction issues, once the problem has been identified, it
should be shouted about very loudly to get it upstream as quickly as
possible.  I'm sure Linus would've even taken it in patch form.

(You do realise that Linus does apply patches as well as pulling trees?)

Re: [PATCH 00/16] rmk's patch series for fixing OMAP

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

On Thu, 2012-02-09 at 00:53 +0000, Russell King - ARM Linux wrote:

> Moreover, only last Monday did I enable the OMAP2 DSS subsystem on the
> 4430 SDP platform, _including_ the HDMI code, and looking at the commit
> it could be one of those platforms which is affected.
> 
> As I don't have a HDMI cable connected to the system, and I ran that
> kernel overnight, and I tried opening each /dev/fb* device, what I'm now
> wondering is: have I destroyed the HDMI PHY on my 4430SDP?

Probably not. I don't know the exact details of the HW bug (I wrote the
patch as it took too long for the person responsible for it to come up
with a decent patch), but my understanding is that the cable needs to be
plugged in at some point, and then removed.

Thinking about this now, I guess I should've sent queries to get a
proper description of the situation where the bug happens.

> However, you raise another point, a much more serious one at that.  Is
> this problem also present in 3.2?  The patch seems to apply almost cleanly
> to that kernel version, so I guess it is.  It fails to apply to v3.1
> because of missing files, so I guess 3.1 is unaffected.
> 
> So, why isn't this patch copied to the stable people?

Good point, I'll take it to the stable people.

The problem is present in all kernels where we have the HDMI driver, so
2.6.39+.

> For hardware destruction issues, once the problem has been identified, it
> should be shouted about very loudly to get it upstream as quickly as
> possible.  I'm sure Linus would've even taken it in patch form.
> 
> (You do realise that Linus does apply patches as well as pulling trees?)

Yes, I should've taken this directly to Linus.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 00/16] rmk's patch series for fixing OMAP

[Teresa Gamez]

Am Donnerstag, den 09.02.2012, 09:02 +0200 schrieb Tomi Valkeinen:
> On Thu, 2012-02-09 at 00:53 +0000, Russell King - ARM Linux wrote:
> 
> > Moreover, only last Monday did I enable the OMAP2 DSS subsystem on the
> > 4430 SDP platform, _including_ the HDMI code, and looking at the commit
> > it could be one of those platforms which is affected.
> > 
> > As I don't have a HDMI cable connected to the system, and I ran that
> > kernel overnight, and I tried opening each /dev/fb* device, what I'm now
> > wondering is: have I destroyed the HDMI PHY on my 4430SDP?
> 
> Probably not. I don't know the exact details of the HW bug (I wrote the
> patch as it took too long for the person responsible for it to come up
> with a decent patch), but my understanding is that the cable needs to be
> plugged in at some point, and then removed.
> 
> Thinking about this now, I guess I should've sent queries to get a
> proper description of the situation where the bug happens.
> 
> > However, you raise another point, a much more serious one at that.  Is
> > this problem also present in 3.2?  The patch seems to apply almost cleanly
> > to that kernel version, so I guess it is.  It fails to apply to v3.1
> > because of missing files, so I guess 3.1 is unaffected.
> > 
> > So, why isn't this patch copied to the stable people?
> 
> Good point, I'll take it to the stable people.
> 
> The problem is present in all kernels where we have the HDMI driver, so
> 2.6.39+.

Are there already backported patches out there for 3.0/3.1?
We are quite interested in this.

Regards,
Teresa

> 
> > For hardware destruction issues, once the problem has been identified, it
> > should be shouted about very loudly to get it upstream as quickly as
> > possible.  I'm sure Linus would've even taken it in patch form.
> > 
> > (You do realise that Linus does apply patches as well as pulling trees?)
> 
> Yes, I should've taken this directly to Linus.
> 
>  Tomi
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/16] rmk's patch series for fixing OMAP

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

On Thu, 2012-02-09 at 09:30 +0100, Teresa Gamez wrote:
> Am Donnerstag, den 09.02.2012, 09:02 +0200 schrieb Tomi Valkeinen:

> > The problem is present in all kernels where we have the HDMI driver, so
> > 2.6.39+.
> 
> Are there already backported patches out there for 3.0/3.1?
> We are quite interested in this.

I pushed three branches to git://gitorious.org/linux-omap-dss2/linux.git

fixes/for-3.0-stable
fixes/for-3.1-stable
fixes/for-3.2-stable

Which contain the necessary backported patches for each version.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]