Re: OMAP4 HDMI PHY bug work-around for stable

Re: OMAP4 HDMI PHY bug work-around for stable

[Tomi Valkeinen]

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

Hi,

I haven't seen these merged nor any comment for these. Perhaps
stable@kernel.org was wrong address, so adding stable@vger.kernel.org
too.

I have added one additional fix into for-3.2-stable branch, which fixes
a problem with panel detection that the GPIO changes brought.

 Tomi

On Thu, 2012-02-09 at 13:44 +0200, Tomi Valkeinen wrote:
> Hi,
> 
> There is a hardware bug on OMAP4, which may cause the HDMI output to
> break irreversibly. A work-around for the bug has been merged into
> mainline, but is missing from stable.
> 
> I've backported the necessary patches on top of 3.0, 3.1 and 3.2 stable
> trees, and pushed the following 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
> 
> 3.0 and 3.1 branches additionally contain a patch "OMAP: DSS2: HDMI: use
> default dividers", which fixes a problem with the HDMI clock divider.
> Without that the HDMI output won't start at all on those versions.
> 
> The branches contain the following backported patches:
> 
>       OMAP: DSS2: HDMI: use default dividers
>       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
> 
> Of those, the actual fix is in the last one, but as the GPIOs for HDMI
> were a mess, they needed some cleanup patches before the fix could be
> made.
> 
> I'm not familiar with the process with stable kernels, so are the
> branches above fine to get them merged? Or should I send the patches
> with git-send-email?
> 
>  Tomi
> 


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

Re: OMAP4 HDMI PHY bug work-around for stable

[Greg KH]

On Tue, Feb 28, 2012 at 10:03:13AM +0200, Tomi Valkeinen wrote:
> Hi,
> 
> I haven't seen these merged nor any comment for these. Perhaps
> stable@kernel.org was wrong address, so adding stable@vger.kernel.org
> too.

Yes, stable@kernel.org has been "dead" since last October.

> I have added one additional fix into for-3.2-stable branch, which fixes
> a problem with panel detection that the GPIO changes brought.

Sorry, but I don't accept pull requests.  I need patches in email form,
as described in the file, Documentation/stable_kernel_rules.txt.  Please
feel free to send them from your git tree that way.

> On Thu, 2012-02-09 at 13:44 +0200, Tomi Valkeinen wrote:
> > Hi,
> > 
> > There is a hardware bug on OMAP4, which may cause the HDMI output to
> > break irreversibly. A work-around for the bug has been merged into
> > mainline, but is missing from stable.
> > 
> > I've backported the necessary patches on top of 3.0, 3.1 and 3.2 stable
> > trees, and pushed the following branches to:

3.1 is long dead, so I can't do anything with those patches, sorry.

> > git://gitorious.org/linux-omap-dss2/linux.git
> > 
> > fixes/for-3.0-stable
> > fixes/for-3.1-stable
> > fixes/for-3.2-stable
> > 
> > 3.0 and 3.1 branches additionally contain a patch "OMAP: DSS2: HDMI: use
> > default dividers", which fixes a problem with the HDMI clock divider.
> > Without that the HDMI output won't start at all on those versions.
> > 
> > The branches contain the following backported patches:
> > 
> >       OMAP: DSS2: HDMI: use default dividers
> >       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
> > 
> > Of those, the actual fix is in the last one, but as the GPIOs for HDMI
> > were a mess, they needed some cleanup patches before the fix could be
> > made.

That seems like a lot of backporting for a single fix, but I'll be glad
to review them when you send them.

> > I'm not familiar with the process with stable kernels, so are the
> > branches above fine to get them merged? Or should I send the patches
> > with git-send-email?

Again, please read Documentation/stable_kernel_rules.txt, it explains
how this all works.

thanks,

greg k-h

Re: OMAP4 HDMI PHY bug work-around for stable

[Tomi Valkeinen]

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

On Tue, 2012-02-28 at 08:47 -0800, Greg KH wrote:

> Sorry, but I don't accept pull requests.  I need patches in email form,
> as described in the file, Documentation/stable_kernel_rules.txt.  Please
> feel free to send them from your git tree that way.

Ah, I somehow missed that txt when googling about the stable kernel.
Thanks for pointing it out.

> That seems like a lot of backporting for a single fix, but I'll be glad
> to review them when you send them.

This is something that is not quite clear to me:

Should I strive for keeping the patches for stable as close as possible
to the ones in mainline, and thus possibly being forced to take other
extra patches with the actual fix as I did here

or

should I just rather cook up a new patch which just fixes the problem
without caring about any cleanups etc. that are in the mainline, and
thus possibly creating a rather different patch compared to mainline's
version?

 Tomi


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

Re: OMAP4 HDMI PHY bug work-around for stable

[Greg KH]

On Wed, Feb 29, 2012 at 11:07:24AM +0200, Tomi Valkeinen wrote:
> On Tue, 2012-02-28 at 08:47 -0800, Greg KH wrote:
> 
> > Sorry, but I don't accept pull requests.  I need patches in email form,
> > as described in the file, Documentation/stable_kernel_rules.txt.  Please
> > feel free to send them from your git tree that way.
> 
> Ah, I somehow missed that txt when googling about the stable kernel.
> Thanks for pointing it out.
> 
> > That seems like a lot of backporting for a single fix, but I'll be glad
> > to review them when you send them.
> 
> This is something that is not quite clear to me:
> 
> Should I strive for keeping the patches for stable as close as possible
> to the ones in mainline, and thus possibly being forced to take other
> extra patches with the actual fix as I did here

Yes.  If that is what is happening here, that's fine, just tell me.

> or
> 
> should I just rather cook up a new patch which just fixes the problem
> without caring about any cleanups etc. that are in the mainline, and
> thus possibly creating a rather different patch compared to mainline's
> version?

No, the first one.

thanks,

greg k-h