[alsa-devel] [PATCH - 1/1] patch_nvhdmi.c: Add missing codec IDs, unify names
tiwai at suse.de
Fri Sep 10 18:23:19 CEST 2010
At Fri, 10 Sep 2010 08:56:59 -0700,
Stephen Warren wrote:
> Takashi Iwai wrote:
> > At Tue, 31 Aug 2010 11:22:38 -0700,
> > Stephen Warren wrote:
> > >
> > > Takashi Iwai wrote:
> > > >
> > > > At Mon, 9 Aug 2010 22:41:40 -0600,
> > > > Stephen Warren wrote:
> > > > >
> > > > > * Add missing codec IDs.
> > > > > * Modify some existing codec names for discrete GPUs to match newly
> > > > > added IDs. Note: existing names were a mixture of marketing and
> > > > > engineering GPU names. Equally, there's no reason that codec IDs
> > > > > have to be specific to a particular GPU or board, so identify
> > > > > codecs in a less marketing-oriented fashion.
> > > > > * Reformat codec ID table so it's easier to read, for me at least.
> > > > >
> > > > > Signed-off-by: Stephen Warren <swarren at nvidia.com>
> > > >
> > > > Applied now as is. It doesn't exceed too much over 80 columns ;)
> > >
> > > Does such a change automatically go into previous stable kernels as well as the
> > > current development kernel?
> > If the patch contains Cc to stable at kernel.org, it'll be fed to stable
> > kernel automatically. See Documentation/stable_kernel_rules.txt.
> > > Or, do I/you need to specifically request this?
> > If you think it's mandatory for stable kernel, go ahead.
> > > I'm
> > > hoping to get the patches for this and the previous old_pin_detect fix widely
> > > distributed to solve the issues some end-users are seeing.
> > Honestly, If you wanted to put to stable kernel tree, you shouldn't
> > have mixed the changes for codec id strings but simply added the new
> > id numbers. This would have made the changes much simpler and easier
> > to apply, so I could have put a CC to stable kernel tree by myself.
> > But, merging several things into a single patch hesitated me for
> > doing it.
> Thinking about this some more, I'd like to see this patch in the stable
> kernels; together with the "old_pin_detect" fix that's already there, it'll
> solve the most pressing of current end-user issues, and provide an easy
> widespread distribution of the fix.
> Would it help if I resubmitted a patch intended just for the stable kernels
> that simply adds the new entries and doesn't touch existing ones? If so,
> which kernel should I base this off; 18.104.22.168?
Well, renaming is mostly harmless, so I don't think it'd be a problem,
as long as the patch can be applied cleanly to old kernels.
Feel free to submit by yourself :)
More information about the Alsa-devel