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.
On Thu, Mar 3, 2011 at 1:37 PM, Colin Cross <[email protected]> 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 <[email protected]> wrote: >> Colin Cross wrote at Thursday, March 03, 2011 12:12 PM: >>> >>> On Tue, Feb 22, 2011 at 1:09 PM, Mark Brown >>> <[email protected]> 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 >> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
