* [PATCH 00/16] rmk's patch series for fixing OMAP
@ 2012-02-08 16:35 Russell King - ARM Linux
2012-02-08 16:36 ` [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c Russell King - ARM Linux
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
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 [flat|nested] 11+ messages in thread* [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c 2012-02-08 16:35 [PATCH 00/16] rmk's patch series for fixing OMAP Russell King - ARM Linux @ 2012-02-08 16:36 ` Russell King - ARM Linux 2012-02-08 18:36 ` Tony Lindgren 2012-02-08 19:06 ` [PATCH 00/16] rmk's patch series for fixing OMAP Tony Lindgren 2012-02-08 20:31 ` Florian Tobias Schandinat 2 siblings, 1 reply; 11+ messages in thread From: Russell King - ARM Linux @ 2012-02-08 16:36 UTC (permalink / raw) To: linux-omap; +Cc: Tomi Valkeinen, Florian Tobias Schandinat, linux-fbdev 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 [flat|nested] 11+ messages in thread
* Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c 2012-02-08 16:36 ` [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c Russell King - ARM Linux @ 2012-02-08 18:36 ` Tony Lindgren 2012-02-08 22:50 ` Russell King - ARM Linux 0 siblings, 1 reply; 11+ messages in thread 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 * 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 [flat|nested] 11+ messages in thread
* Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c 2012-02-08 18:36 ` Tony Lindgren @ 2012-02-08 22:50 ` Russell King - ARM Linux 2012-02-08 23:32 ` Tony Lindgren 0 siblings, 1 reply; 11+ messages in thread 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 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 [flat|nested] 11+ messages in thread
* Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c 2012-02-08 22:50 ` Russell King - ARM Linux @ 2012-02-08 23:32 ` Tony Lindgren 0 siblings, 0 replies; 11+ messages in thread 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 * 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 [flat|nested] 11+ messages in thread
* Re: [PATCH 00/16] rmk's patch series for fixing OMAP 2012-02-08 16:35 [PATCH 00/16] rmk's patch series for fixing OMAP Russell King - ARM Linux 2012-02-08 16:36 ` [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c Russell King - ARM Linux @ 2012-02-08 19:06 ` Tony Lindgren 2012-02-08 20:31 ` Florian Tobias Schandinat 2 siblings, 0 replies; 11+ messages in thread From: Tony Lindgren @ 2012-02-08 19:06 UTC (permalink / raw) To: linux-arm-kernel * 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 [flat|nested] 11+ messages in thread
* Re: [PATCH 00/16] rmk's patch series for fixing OMAP 2012-02-08 16:35 [PATCH 00/16] rmk's patch series for fixing OMAP Russell King - ARM Linux 2012-02-08 16:36 ` [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c Russell King - ARM Linux 2012-02-08 19:06 ` [PATCH 00/16] rmk's patch series for fixing OMAP Tony Lindgren @ 2012-02-08 20:31 ` Florian Tobias Schandinat 2012-02-09 0:53 ` Russell King - ARM Linux 2 siblings, 1 reply; 11+ messages in thread From: Florian Tobias Schandinat @ 2012-02-08 20:31 UTC (permalink / raw) To: linux-arm-kernel 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 [flat|nested] 11+ messages in thread
* Re: [PATCH 00/16] rmk's patch series for fixing OMAP 2012-02-08 20:31 ` Florian Tobias Schandinat @ 2012-02-09 0:53 ` Russell King - ARM Linux 2012-02-09 7:02 ` Tomi Valkeinen 0 siblings, 1 reply; 11+ messages in thread From: Russell King - ARM Linux @ 2012-02-09 0:53 UTC (permalink / raw) To: linux-arm-kernel 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?) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 00/16] rmk's patch series for fixing OMAP 2012-02-09 0:53 ` Russell King - ARM Linux @ 2012-02-09 7:02 ` Tomi Valkeinen 2012-02-09 8:30 ` Teresa Gamez 0 siblings, 1 reply; 11+ messages in thread From: Tomi Valkeinen @ 2012-02-09 7:02 UTC (permalink / raw) To: linux-arm-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 00/16] rmk's patch series for fixing OMAP 2012-02-09 7:02 ` Tomi Valkeinen @ 2012-02-09 8:30 ` Teresa Gamez 2012-02-09 10:24 ` Tomi Valkeinen 0 siblings, 1 reply; 11+ messages in thread From: Teresa Gamez @ 2012-02-09 8:30 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 00/16] rmk's patch series for fixing OMAP 2012-02-09 8:30 ` Teresa Gamez @ 2012-02-09 10:24 ` Tomi Valkeinen 0 siblings, 0 replies; 11+ messages in thread From: Tomi Valkeinen @ 2012-02-09 10:24 UTC (permalink / raw) To: linux-arm-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-02-09 10:24 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-02-08 16:35 [PATCH 00/16] rmk's patch series for fixing OMAP Russell King - ARM Linux 2012-02-08 16:36 ` [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c Russell King - ARM Linux 2012-02-08 18:36 ` Tony Lindgren 2012-02-08 22:50 ` Russell King - ARM Linux 2012-02-08 23:32 ` Tony Lindgren 2012-02-08 19:06 ` [PATCH 00/16] rmk's patch series for fixing OMAP Tony Lindgren 2012-02-08 20:31 ` Florian Tobias Schandinat 2012-02-09 0:53 ` Russell King - ARM Linux 2012-02-09 7:02 ` Tomi Valkeinen 2012-02-09 8:30 ` Teresa Gamez 2012-02-09 10:24 ` Tomi Valkeinen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).