I can check if the sound patches can be put into the sound-2.6 tree instead... that way we'll get them when we rebase later. I can also check if we cherry-pick them into our OpenMoko tree now, too... I think that should be doable. Are we certain that the topic/asoc branch is headed for upstream in 2.6.28? /Jonas
On Wed, Oct 1, 2008 at 6:54 PM, Andy Green <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Somebody in the thread at some point said: > > |> For now I guess we will take Jonas' stuff and rebase it out when Jean's > |> accepted stuff comes in from upstream, it's a headache either way. > | > | TBH I'm not clear what benefit there is from doing these changes in the > | OpenMoko tree is - the net effect of the two registration APIs is the > > It's simply that I can take the patchset and move on. I tried removing > 5/11 but at least 7/11 depends on it and I don't have time to unpick the > intentions. > > | same, it should just be a code cleanup change. If there were an > | immediate benefit from doing the conversion or if it hadn't yet been > | done upstream and could therefore be pushed upstream it'd make sense to > | me but that's not the case here. > | > | Note that this doesn't apply to the reordering of the scenario setup > | which is a straight bugfix independant of the I2C API changes (ASoC got > | better at pointing out when stuff goes wrong). > > Jonas, what do you think about Mark's points? If you can decouple the > later patches from this conflicting stuff it will save headaches later > (and now). > > - -Andy > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkjjqzUACgkQOjLpvpq7dMqA6gCfWvZ78p9h5wMDFEAKocrWEmSs > cpIAn2abMruLJV+MYHjyG4ssurKkDE5J > =TD2W > -----END PGP SIGNATURE----- > -- Jonas Bonn Stockholm, Sweden
