From: Russell King - ARM Linux <hidden> Date: 2012-02-08 16:35:47
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 [off-list ref]
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.
@@ -180,6 +180,11 @@ int omapdss_dpi_display_enable(struct omap_dss_device *dssdev){intr;+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;
From: Tony Lindgren <tony@atomide.com> Date: 2012-02-08 18:36:07
* Russell King - ARM Linux [off-list ref] [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 <redacted>
Tomi can look into fixing this properly for v3.4:
Acked-by: Tony Lindgren <tony@atomide.com>
* Russell King - ARM Linux [off-list ref] [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 [off-list ref]
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.
Hi Russell,
On 02/08/2012 04:35 PM, Russell King - ARM Linux wrote:
commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
Author: Tomi Valkeinen [off-list ref]
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
From: Russell King - ARM Linux <hidden> Date: 2012-02-08 22:50:12
On Wed, Feb 08, 2012 at 10:36:07AM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux [off-list ref] [120208 08:05]:
quoted
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 <redacted>
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.
From: Tony Lindgren <tony@atomide.com> Date: 2012-02-08 23:32:20
* Russell King - ARM Linux [off-list ref] [120208 14:19]:
On Wed, Feb 08, 2012 at 10:36:07AM -0800, Tony Lindgren wrote:
quoted
* Russell King - ARM Linux [off-list ref] [120208 08:05]:
quoted
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 <redacted>
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
From: Russell King - ARM Linux <hidden> Date: 2012-02-09 00:53:34
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:
quoted
commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
Author: Tomi Valkeinen [off-list ref]
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.
quoted
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.
quoted
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?)
From: Tomi Valkeinen <hidden> Date: 2012-02-09 07:02:49
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
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:
quoted
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.
quoted
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
quoted
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?)
From: Tomi Valkeinen <hidden> Date: 2012-02-09 10:24:35
On Thu, 2012-02-09 at 09:30 +0100, Teresa Gamez wrote:
Am Donnerstag, den 09.02.2012, 09:02 +0200 schrieb Tomi Valkeinen:
quoted
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