Message ID | 1348750146-6839-1-git-send-email-david.henningsson@canonical.com |
---|---|
State | New |
Headers | show |
On 09/27/2012 06:49 AM, David Henningsson wrote: > From: Wang Xingchao <xingchao.wang@intel.com> > > This is a backport of several upstream commits: > e926f2c850c472f813f9bab486c68a3fe0b03ae4 > 1c76684d2752b3a24bb7da183cc18e5d126dbcc9 > bdbe34dece4942f4d8df9865dba7785bb813366a > d279fae8a41690ec1b20c07be8c6f42f8af27a17 > > ...which all are trivial and just add PCI and Codec IDs > to the relevant tables. > Don't combine the patches. d279fae8a41690ec1b20c07be8c6f42f8af27a17 is not a valid object from Linus' repo. All of these patches need a bug number.
On 09/27/2012 03:13 PM, Tim Gardner wrote:
> Don't combine the patches.
Why not?
On 09/27/2012 06:37 AM, David Henningsson wrote: > On 09/27/2012 03:13 PM, Tim Gardner wrote: >> Don't combine the patches. > > Why not? > > We want a 1-to-1 correspondence between the original, upstream commit and the backported commit. This allows anyone looking at the backport to easily see where it originated from. These are the rules we require of anyone requesting patches to the Ubuntu kernel sources. Our rules are almost exactly the same as upstream. Brad
On 09/27/2012 06:13 AM, Tim Gardner wrote: > On 09/27/2012 06:49 AM, David Henningsson wrote: >> From: Wang Xingchao <xingchao.wang@intel.com> >> >> This is a backport of several upstream commits: >> e926f2c850c472f813f9bab486c68a3fe0b03ae4 >> 1c76684d2752b3a24bb7da183cc18e5d126dbcc9 >> bdbe34dece4942f4d8df9865dba7785bb813366a >> d279fae8a41690ec1b20c07be8c6f42f8af27a17 >> >> ...which all are trivial and just add PCI and Codec IDs >> to the relevant tables. >> > Don't combine the patches. d279fae8a41690ec1b20c07be8c6f42f8af27a17 is > not a valid object from Linus' repo. All of these patches need a bug number. Hi David, Indeed it is better for us maintenance wise to be able to have a 1-1 mapping of upstream commits when we apply them to our tree. As such, I took the liberty to go ahead and individually cherry-pick these into our Quantal repo. That last commit, d279fae8, I found in takashi's tree so I picked it up from there. I also took the liberty to open a tracking bug for this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1057698 Please review the quantal repo and make sure what I've done looks correct as e926f2c8 wasn't a clean cherry-pick. Thanks, Leann
On 09/27/2012 12:49 PM, Leann Ogasawara wrote: > On 09/27/2012 06:13 AM, Tim Gardner wrote: >> On 09/27/2012 06:49 AM, David Henningsson wrote: >>> From: Wang Xingchao <xingchao.wang@intel.com> >>> >>> This is a backport of several upstream commits: >>> e926f2c850c472f813f9bab486c68a3fe0b03ae4 >>> 1c76684d2752b3a24bb7da183cc18e5d126dbcc9 >>> bdbe34dece4942f4d8df9865dba7785bb813366a >>> d279fae8a41690ec1b20c07be8c6f42f8af27a17 >>> >>> ...which all are trivial and just add PCI and Codec IDs >>> to the relevant tables. >>> >> Don't combine the patches. d279fae8a41690ec1b20c07be8c6f42f8af27a17 is >> not a valid object from Linus' repo. All of these patches need a bug number. > Hi David, > > Indeed it is better for us maintenance wise to be able to have a 1-1 > mapping of upstream commits when we apply them to our tree. As such, I > took the liberty to go ahead and individually cherry-pick these into our > Quantal repo. That last commit, d279fae8, I found in takashi's tree so > I picked it up from there. I also took the liberty to open a tracking > bug for this: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1057698 > > Please review the quantal repo and make sure what I've done looks > correct as e926f2c8 wasn't a clean cherry-pick. I also decided to cherry-pick 144dad99 from upstream while I was at it. Thanks, Leann commit 144dad99ef6ad10c8c8ebe787d08157c4a94201f Author: James Ralston <james.d.ralston@intel.com> Date: Thu Aug 9 09:38:59 2012 -0700 ALSA: hda_intel: Add Device IDs for Intel Lynx Point-LP PCH
On 09/27/2012 09:49 PM, Leann Ogasawara wrote: > On 09/27/2012 06:13 AM, Tim Gardner wrote: >> On 09/27/2012 06:49 AM, David Henningsson wrote: >>> From: Wang Xingchao <xingchao.wang@intel.com> >>> >>> This is a backport of several upstream commits: >>> e926f2c850c472f813f9bab486c68a3fe0b03ae4 >>> 1c76684d2752b3a24bb7da183cc18e5d126dbcc9 >>> bdbe34dece4942f4d8df9865dba7785bb813366a >>> d279fae8a41690ec1b20c07be8c6f42f8af27a17 >>> >>> ...which all are trivial and just add PCI and Codec IDs >>> to the relevant tables. >>> >> Don't combine the patches. d279fae8a41690ec1b20c07be8c6f42f8af27a17 is >> not a valid object from Linus' repo. All of these patches need a bug number. > > Hi David, Hi Leann, and first of all, thanks a lot for walking the extra mile for me :-) > Indeed it is better for us maintenance wise to be able to have a 1-1 > mapping of upstream commits when we apply them to our tree. As such, I > took the liberty to go ahead and individually cherry-pick these into our > Quantal repo. That last commit, d279fae8, I found in takashi's tree so Yeah, I thought I checked that they were all in Linus' tree, but git can be bewildering sometimes, especially when you start adding remotes (to be able to to cherrypicking), and then it suddenly finds things from those other remotes which you didn't consider...or something. > I picked it up from there. I also took the liberty to open a tracking > bug for this: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1057698 > > Please review the quantal repo and make sure what I've done looks > correct as e926f2c8 wasn't a clean cherry-pick. I did have a look at the current master-next branch. The haswell ones looked correct to me - you had correctly replaced posfix_combo with posfix_lpib. I'm a little more hesitant to whether we should have LPIB on the lynx point-LP patch: the combo mode uses posbuf for recording and lpib for playback. This is why it works for haswell, which is HDMI and playback only - but for this one, we could just pick either one and see if we get in trouble (in this case, that would typically be non-functional or strange noises in recordings), we might have to switch, i e, remove the POSFIX_LPIB for Lynx Point LP, just as done for the already present Lynx Point.
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 7757536..7063389 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -151,6 +151,7 @@ MODULE_SUPPORTED_DEVICE("{{Intel, ICH6}," "{Intel, CPT}," "{Intel, PPT}," "{Intel, LPT}," + "{Intel, HPT}," "{Intel, PBG}," "{Intel, SCH}," "{ATI, SB450}," @@ -3256,6 +3257,13 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = { { PCI_DEVICE(0x8086, 0x8c20), .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP | AZX_DCAPS_BUFSIZE}, + /* Haswell */ + { PCI_DEVICE(0x8086, 0x0c0c), + .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_SCH_SNOOP | + AZX_DCAPS_BUFSIZE | AZX_DCAPS_POSFIX_LPIB}, + { PCI_DEVICE(0x8086, 0x0d0c), + .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_SCH_SNOOP | + AZX_DCAPS_BUFSIZE | AZX_DCAPS_POSFIX_LPIB}, /* SCH */ { PCI_DEVICE(0x8086, 0x811b), .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_SCH_SNOOP | diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 5d52332..dc249b2 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1911,6 +1911,7 @@ static const struct hda_codec_preset snd_hda_preset_hdmi[] = { { .id = 0x80862804, .name = "IbexPeak HDMI", .patch = patch_generic_hdmi }, { .id = 0x80862805, .name = "CougarPoint HDMI", .patch = patch_generic_hdmi }, { .id = 0x80862806, .name = "PantherPoint HDMI", .patch = patch_generic_hdmi }, +{ .id = 0x80862807, .name = "Haswell HDMI", .patch = patch_generic_hdmi }, { .id = 0x80862880, .name = "CedarTrail HDMI", .patch = patch_generic_hdmi }, { .id = 0x808629fb, .name = "Crestline HDMI", .patch = patch_generic_hdmi }, {} /* terminator */ @@ -1958,6 +1959,7 @@ MODULE_ALIAS("snd-hda-codec-id:80862803"); MODULE_ALIAS("snd-hda-codec-id:80862804"); MODULE_ALIAS("snd-hda-codec-id:80862805"); MODULE_ALIAS("snd-hda-codec-id:80862806"); +MODULE_ALIAS("snd-hda-codec-id:80862807"); MODULE_ALIAS("snd-hda-codec-id:80862880"); MODULE_ALIAS("snd-hda-codec-id:808629fb");