Olof Johansson wrote at Thursday, March 03, 2011 6:01 PM: > I can do them (sorry, been out today and was also waiting on the i2c > merge to land). > > I'll take them through my tree with the i2c changes. I'll post the > base i2c board changes either tonight or tomorrow morning, after that > Stephens can easily go on top. Olof, I didn't see any updates in git. Do my changes still need to be in today? I'm assuming you wanted me to rebase my changes on top of your I2C changes one they were published, and mail the patches again... > On Thu, Mar 3, 2011 at 3:47 PM, Colin Cross <ccross@xxxxxxxxxx> wrote: > > On Thu, Mar 3, 2011 at 2:40 PM, Stephen Warren <swarren@xxxxxxxxxx> > wrote: > >> Colin Cross wrote at Thursday, March 03, 2011 3:25 PM: > >>> I pushed the merge of Ben's i2c-tegra as for-next-i2c. I will put any > >>> patches that depend on i2c support in that branch, and keep it rebased > >>> on top of for-next. > >> > >> Previously, Olof said he'd take my board patches through his tree. I > assume > >> that's no longer the plan, and I should just create a patch-set based > on > >> Tegra for-next or for-next-i2c? > >> > >> FYI, I now have 3 patches left not applied, in git log order: > >> > >> ARM: Tegra: Enable Harmony audio support > >> > >> * Set up platform data required by I2C, and ASoC machine & codec > drivers. > >> * Enable required GPIO pins as GPIOs. > >> * Initialize audio-related clocks. > >> * Correctly configure pinmux for audio-related GPIOs. > >> > >> (this can be split to parts before/after picking up latest ASoC, and > >> perhaps also part for for-next, part for for-next-i2c?) > >> > >> ARM: Tegra: Create defines for GPIO names > >> > >> This ensures they're kept in sync between platform_data definitions > and > >> the GPIO table initialization. > >> > >> (Should apply right away, to for-next) > >> > >> ARM: Tegra: Add devices.c entries for audio > >> > >> For I2S, DAS, PCM devices > >> > >> (Should apply right away, to for-next) > >> > >>> On Thu, Mar 3, 2011 at 1:37 PM, Colin Cross <ccross@xxxxxxxxxx> wrote: > >>> > (resending as plain text) > >>> > > >>> > To prevent the merge window from becoming a mess, patches are > supposed > >>> > to be in linux-next by rc6 of the previous release. > >>> > > >>> > Ben never responded to my question about merging i2c-tegra, so I'll > >>> > merge it for now. > >>> > > >>> > On Thu, Mar 3, 2011 at 11:29 AM, Stephen Warren <swarren@xxxxxxxxxx> > >>> wrote: > >>> >> Colin Cross wrote at Thursday, March 03, 2011 12:12 PM: > >>> >>> > >>> >>> On Tue, Feb 22, 2011 at 1:09 PM, Mark Brown > >>> >>> <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > >>> >>> > On Tue, Feb 22, 2011 at 01:01:23PM -0800, Colin Cross wrote: > >>> >>> >> On Tue, Feb 22, 2011 at 12:52 PM, Mark Brown > >>> >>> > > >>> >>> >> > That's the standard way of handling this sort of thing - just > >>> send > >>> >>> the > >>> >>> >> > patch in a second pull request once the dependencies have all > >>> landed. > >>> >>> > > >>> >>> >> You could also put it in the tegra-arch branch and we could > both > >>> re- > >>> >>> merge it. > >>> >>> > > >>> >>> > I basically can't rebase my tree - it's merged into Takashi's > tree > >>> and > >>> >>> > there's lots of cross dependencies with my 2.6.38 fixes branch > which > >>> >>> > would cause bisect breakage. If you want to cherry pick the > >>> relevant > >>> >>> > WM8903 commit over into your tree that'd also be OK by me. > >>> >>> > > >>> >>> > >>> >>> We should be fine with two pull requests. I would still like to > get > >>> >>> all the changes into the for-next branch, without the wm8903 > header > >>> >>> change, but with the harmony file that depends on it. I will > point > >>> >>> the for-linus branch at the last change that compiles without the > >>> >>> wm8903 header change. linux-next should get the ASoC tree and the > >>> >>> Tegra for-next tree, so everything should compile there. > >>> >> > >>> >> OK. I can easily split my patch into two: > >>> >> a) Add basically everything, except for the gpio_base WM8903 > platform > >>> >> data field. (for-linus) > >>> >> b) Add the WM8903 platform data field. (for 2nd pull request) > >>> >> > >>> >> However, my board patches also rely on I2C platform data. There was > >>> >> some discussion that Tegra's for-next would merge in Ben's I2C > Tegra > >>> >> branch and hence pick up the new platform header from that. > >>> >> > >>> >> Olof also mentioned he'd submit a patch through his branch to add > all > >>> >> the I2C bus registrations for all boards once the I2C branch was > >>> >> merged. > >>> >> > >>> >> However, I haven't seen any traction on this. Is this still > happening? > >>> >> If not, I'll have to split my patch slightly differently, to also > pull > >>> >> out the I2C registrations into the second patch. > >>> >> > >>> >>> I'm going to be out of the office next week, so this is probably > the > >>> >>> last chance to get features in 2.6.39. > >>> >> > >>> >> I'm a little out-of-touch here, but this confuses me; 2.6.38 hasn't > >>> >> been released yet, and hence the 2-week merge window isn't open > yet. > >>> >> And even then, I think we can submit small pull requests for stuff > >>> >> like this throughout 2.6.39's rc releases. I'm not why right now is > >>> >> the last chance to get stuff in. > >>> >> > >>> >> -- > >>> >> nvpublic > >> > >> > >> > > > > Olof, are you going to take these or should I? > > -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html