| Message ID | 018801ccca70$25f01260$71d03720$%kim@samsung.com |
|---|---|
| State | New |
| Headers | show |
On Tue, Jan 3, 2012 at 3:33 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > Hi Arnd, > > Please pull Samsung devel for v3.3 from: > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > next-samsung-devel-samsung > > It is including s3c64xx cpuidle and development for Cragganmore, ORIGEN and > some boards. > > If any problems, please let me know. Thanks. I've pulled this into late/devel, based on earlier email from Arnd we might end up sending this in towards the end of the merge window, but there's also a chance it will wait for 3.4. -Olof
Olof Johansson wrote: > > On Tue, Jan 3, 2012 at 3:33 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > > Hi Arnd, > > > > Please pull Samsung devel for v3.3 from: > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > > next-samsung-devel-samsung > > > > It is including s3c64xx cpuidle and development for Cragganmore, ORIGEN > and > > some boards. > > > > If any problems, please let me know. > > Thanks. I've pulled this into late/devel, based on earlier email from > Arnd we might end up sending this in towards the end of the merge > window, but there's also a chance it will wait for 3.4. > OK, but I hope we can see them on 3.3-rc1 and actually, they were queuing in my devel branch for a long time. Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
On Fri, Jan 06, 2012 at 01:58:29PM -0800, Olof Johansson wrote: > > Please pull Samsung devel for v3.3 from: > > ?git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > > next-samsung-devel-samsung > Thanks. I've pulled this into late/devel, based on earlier email from > Arnd we might end up sending this in towards the end of the merge > window, but there's also a chance it will wait for 3.4. That'd be extremely disappointing, especially given that there's some bug fixes in there for updates going in this merge window without which mainline is going to have problems on s3c64xx (mostly the GPIO stuff).
On Sun, Jan 8, 2012 at 12:49 PM, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Fri, Jan 06, 2012 at 01:58:29PM -0800, Olof Johansson wrote: > >> > Please pull Samsung devel for v3.3 from: >> > ?git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git >> > next-samsung-devel-samsung > >> Thanks. I've pulled this into late/devel, based on earlier email from >> Arnd we might end up sending this in towards the end of the merge >> window, but there's also a chance it will wait for 3.4. > > That'd be extremely disappointing, especially given that there's some > bug fixes in there for updates going in this merge window without which > mainline is going to have problems on s3c64xx (mostly the GPIO stuff). Of course bug fixes should go in. Mark, Kukjin, can either of you split out the fixes in a separate branch? Thanks, -Olof
Olof Johansson wrote: > > On Sun, Jan 8, 2012 at 12:49 PM, Mark Brown > <broonie@opensource.wolfsonmicro.com> wrote: > > On Fri, Jan 06, 2012 at 01:58:29PM -0800, Olof Johansson wrote: > > > >> > Please pull Samsung devel for v3.3 from: > >> > ?git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > >> > next-samsung-devel-samsung > > > >> Thanks. I've pulled this into late/devel, based on earlier email from > >> Arnd we might end up sending this in towards the end of the merge > >> window, but there's also a chance it will wait for 3.4. > > > > That'd be extremely disappointing, especially given that there's some > > bug fixes in there for updates going in this merge window without which > > mainline is going to have problems on s3c64xx (mostly the GPIO stuff). > > Of course bug fixes should go in. > > Mark, Kukjin, can either of you split out the fixes in a separate branch? > Hi Olof, In my opinion, as you know, it would be better to us if you could send this in this merge window. Actually, it does not have any dependency with others, in addition, for a long time this has been included in linux-next for this merge window. If this can be missed from sending list to Linus, please kindly let me know. Let me send this to Linus at the end of this merge window. Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
On Sun, Jan 8, 2012 at 5:40 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > Olof Johansson wrote: >> >> On Sun, Jan 8, 2012 at 12:49 PM, Mark Brown >> <broonie@opensource.wolfsonmicro.com> wrote: >> > On Fri, Jan 06, 2012 at 01:58:29PM -0800, Olof Johansson wrote: >> > >> >> > Please pull Samsung devel for v3.3 from: >> >> > ?git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git >> >> > next-samsung-devel-samsung >> > >> >> Thanks. I've pulled this into late/devel, based on earlier email from >> >> Arnd we might end up sending this in towards the end of the merge >> >> window, but there's also a chance it will wait for 3.4. >> > >> > That'd be extremely disappointing, especially given that there's some >> > bug fixes in there for updates going in this merge window without which >> > mainline is going to have problems on s3c64xx (mostly the GPIO stuff). >> >> Of course bug fixes should go in. >> >> Mark, Kukjin, can either of you split out the fixes in a separate branch? >> > Hi Olof, > > In my opinion, as you know, it would be better to us if you could send this in this merge window. > Actually, it does not have any dependency with others, in addition, for a long time this has been included in linux-next for this > merge window. > If this can be missed from sending list to Linus, please kindly let me know. Let me send this to Linus at the end of this merge > window. We've been pretty clear on this: Everything that came in after Arnd's email (that wasn't obvious fixes) would be queued as late/* and, if there is time, go in towards the end of the merge window. There's plenty of time left in the window so right now it looks likely to happen, especially since the branch lacks dependencies and applies relatively cleanly. -Olof
On Sun, Jan 08, 2012 at 08:49:53PM +0000, Mark Brown wrote: > On Fri, Jan 06, 2012 at 01:58:29PM -0800, Olof Johansson wrote: > > > > Please pull Samsung devel for v3.3 from: > > > ?git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > > > next-samsung-devel-samsung > > > Thanks. I've pulled this into late/devel, based on earlier email from > > Arnd we might end up sending this in towards the end of the merge > > window, but there's also a chance it will wait for 3.4. > > That'd be extremely disappointing, especially given that there's some > bug fixes in there for updates going in this merge window without which > mainline is going to have problems on s3c64xx (mostly the GPIO stuff). Here we go again with sucky work practices. This sucky behaviour has been around for a long time, I've long since given up complaining about it as it's exactly like talking to a bloody brick wall. People just continue mixing development and fixes together. They then wonder why their fixes don't make it into mainline in a timely fashion. Maybe delaying the whole lot will make people change their behaviour: it's a behaviour that needs to change at the submitters end. There's nothing which Olof or Arnd can reasonably do to expedite the fixes. So, please direct your complaints to the submitter for not having a work practice which ensures that fixes receive a higher submission priority. Note: Linus _has_ taken a copy of linux-next (read the 3.2 release email), and _is_ checking whether development stuff was in linux-next prior to the merge window opening. It would be very unwise to send new development which wasn't already there.
On Monday 09 January 2012, Kukjin Kim wrote: > In my opinion, as you know, it would be better to us if you could send this in > this merge window. > Actually, it does not have any dependency with others, in addition, for a long > time this has been included in linux-next for this > merge window. Your patches have caused too much problems already so far, with many complex merges (multiple files combined into new files in the restart branch, but modified in multiple other conflicting branches), and I would rather not see *anything* besides fixes from you for late 3.3 patches. If it hadn't been for the conflicts I mentioned, everything else from arm-soc could have been sent last Saturday already, but this way I spent a national holiday and a weekend day, both during my vacation, mostly trying to understand what you were trying to do and get it into shape for upstream submission, giving up in the end. I don't consider it enough to have patches in linux-next before the merge window, and I thought I had made it clear enough that everything has to be in arm-soc before the merge window. I realize that sometimes there is stuff that gets done last minute and really has to get merged, but since you have had it in your own tree for so long, that certainly doesn't apply here. > If this can be missed from sending list to Linus, please kindly let me know. Sorry, but the chances are pretty slim this time. > Let me send this to Linus at the end of this merge window. No, if you do this, I will NAK that pull request. Of course we will take all bug fixes. Just rebase the rest on top of 3.3-rc1 and we can take it right away for 3.4. Arnd
On Mon, Jan 09, 2012 at 03:56:34PM +0000, Arnd Bergmann wrote: > Of course we will take all bug fixes. Just rebase the rest on top of 3.3-rc1 > and we can take it right away for 3.4. I've sent a pull request earlier in the thread for the main ones I'm aware of (which are mostly fixes for things introduced in this cycle) - the others I'm aware of are all specific to Cragganmore and given that we can't get any of the features for that merged the fixes aren't going to have any practical effect until we can manage to get the feature stuff merged so it's not really worth the effort. This really is very disappointing.
On Mon, Jan 09, 2012 at 09:58:39AM +0000, Russell King - ARM Linux wrote: > On Sun, Jan 08, 2012 at 08:49:53PM +0000, Mark Brown wrote: > > That'd be extremely disappointing, especially given that there's some > > bug fixes in there for updates going in this merge window without which > > mainline is going to have problems on s3c64xx (mostly the GPIO stuff). > Here we go again with sucky work practices. > This sucky behaviour has been around for a long time, I've long since > given up complaining about it as it's exactly like talking to a bloody > brick wall. People just continue mixing development and fixes together. Actually in this case the issue is slightly different - the fixes are mostly fixes for issues introduced by other development going in during this merge window, what's gone wrong is that they've been applied to a different branch to that which had the problem. Still an issue of course, just a different one. That said there's also an issue if pure development gets delayed - it makes it harder to do further work based on top of the work that got delayed, especially if any cross tree issues come into play. > Note: Linus _has_ taken a copy of linux-next (read the 3.2 release email), > and _is_ checking whether development stuff was in linux-next prior to > the merge window opening. It would be very unwise to send new development > which wasn't already there. That's not an issue here, all the stuff that's being discussed is in -next but not sent to the arm-soc tree.
On Mon, Jan 09, 2012 at 08:11:54AM -0800, Mark Brown wrote: > On Mon, Jan 09, 2012 at 03:56:34PM +0000, Arnd Bergmann wrote: > > > Of course we will take all bug fixes. Just rebase the rest on top of 3.3-rc1 > > and we can take it right away for 3.4. > > I've sent a pull request earlier in the thread for the main ones I'm > aware of (which are mostly fixes for things introduced in this cycle) - > the others I'm aware of are all specific to Cragganmore and given that > we can't get any of the features for that merged the fixes aren't going > to have any practical effect until we can manage to get the feature > stuff merged so it's not really worth the effort. > > This really is very disappointing. No it isn't. What is really disappointing is the lack of responsive maintainers for the Samsung stuff. It took _two_ bloody months to get the Samsung platforms sorted for the restart changes in spite of reminding, and a last minute rush over the course of a couple of days (one _in_ the merge window) to get it properly merged into my tree. The only reason something happened was because I stuck a #error into the Samsung code in linux-next and people started reporting that Samsung had broken. This is not the worst of it - Nicolas took _three_ months to get a response from the shmobile maintainers. I never got a response from the shmobile maintainers for the restart changes - so congratulations to the shmobile maintainers, shmobile is now broken. The alternative was basically Samsung ending up like shmobile is today. Maybe that's what should have happened to save folk like Arnd such a horrible job now. So, I support Arnd's view: the Samsung stuff is just too late. Even the restart updates (which is what has caused this) were too late. Anything which causes new merge conflicts in the Samsung code is not acceptable at this point, even if it's a 'fix' patch. We've wasted far too much time trying to get Samsung stuff sorted far too late in the cycle. Let this be an object lesson in what happens if you leave stuff until the last minute.
On Tue, Jan 10, 2012 at 09:06:35AM +0000, Russell King - ARM Linux wrote: > On Mon, Jan 09, 2012 at 08:11:54AM -0800, Mark Brown wrote: > > This really is very disappointing. > No it isn't. I think we're talking at cross purposes here - I'm saying that this whole situation is disappointing, not a specific decision. > What is really disappointing is the lack of responsive maintainers for the > Samsung stuff. It took _two_ bloody months to get the Samsung platforms This is pretty much what I'm saying is disappointing - in this case the whole fact that we're not managing to get stuff actually merged. It's very frustrating that we're ending up in a situation where getting things applied to the maintainer's tree and into -next (which is usually the end of what you need to do as a patch submitter) isn't enough to actually get the changes pushed upstream. > The only reason something happened was because I stuck a #error into > the Samsung code in linux-next and people started reporting that Samsung > had broken. Yeah, me included. Like I said I'd probably have sent a fix if I'd been able to figure out what the changes the error referred to were. > The alternative was basically Samsung ending up like shmobile is today. > Maybe that's what should have happened to save folk like Arnd such a > horrible job now. So, is there anything that people like me who are contributing to rather than maintaining things can do to help here beyond chasing maintainers? Generally my process is roughly to monitor what goes into -next and chase people if things don't make it in there but that's not working well here as things are appearing in -next.
On Tue, 10 Jan 2012, Mark Brown wrote: > So, is there anything that people like me who are contributing to rather > than maintaining things can do to help here beyond chasing maintainers? > > Generally my process is roughly to monitor what goes into -next and > chase people if things don't make it in there but that's not working > well here as things are appearing in -next. Maybe the Samsung maintainer(s) should target early merge into the arm-soc tree instead of going straight to linux-next only. The former ends up in the later anyway. Nicolas
On Tue, Jan 10, 2012 at 01:44:54PM -0500, Nicolas Pitre wrote: > On Tue, 10 Jan 2012, Mark Brown wrote: > > So, is there anything that people like me who are contributing to rather > > than maintaining things can do to help here beyond chasing maintainers? > Maybe the Samsung maintainer(s) should target early merge into the > arm-soc tree instead of going straight to linux-next only. The former > ends up in the later anyway. That sounds like it'd be helpful overall but it's something that has to be sorted out at the maintainer level. I'm guessing there's not really much that contributors can do here?
On Tue, 10 Jan 2012, Mark Brown wrote: > On Tue, Jan 10, 2012 at 01:44:54PM -0500, Nicolas Pitre wrote: > > On Tue, 10 Jan 2012, Mark Brown wrote: > > > > So, is there anything that people like me who are contributing to rather > > > than maintaining things can do to help here beyond chasing maintainers? > > > Maybe the Samsung maintainer(s) should target early merge into the > > arm-soc tree instead of going straight to linux-next only. The former > > ends up in the later anyway. > > That sounds like it'd be helpful overall but it's something that has to > be sorted out at the maintainer level. I'm guessing there's not really > much that contributors can do here? Maybe if enough contributor pressure builds up something will change... Nicolas
On Tuesday 10 January 2012, Mark Brown wrote: > > On Tue, Jan 10, 2012 at 01:44:54PM -0500, Nicolas Pitre wrote: > > On Tue, 10 Jan 2012, Mark Brown wrote: > > > > So, is there anything that people like me who are contributing to rather > > > than maintaining things can do to help here beyond chasing maintainers? > > > Maybe the Samsung maintainer(s) should target early merge into the > > arm-soc tree instead of going straight to linux-next only. The former > > ends up in the later anyway. > > That sounds like it'd be helpful overall but it's something that has to > be sorted out at the maintainer level. I'm guessing there's not really > much that contributors can do here? I think you did everything as good as you could, we just need to routinely call for everyone to submit stuff in time. A number of maintainers sent stuff after Christmas (which I expected to start the merge window) and were mostly lucky because Linus gave us an extra 10 days to sort things out. The most reliable way improve things is pressure from upstream. We used to have a lot of problems with omap until Linus complained loudly and the omap merges are working completely flawless now process-wise. In the last few releases I pushed back on substandard at91 patches and that also turned out really well for 3.3. This time, the samsung and pxa patches were sticking out as being worse than the others, so that's where the pushback went and I'm sure it will work better in the future. PXA made it in in the end, samsung also did for the most part but not entirely and you were unfortunate to be the contributor of the patches that missed out. Note that we're also constantly raising the bar with our expectations here, and we have to, in order to keep up with increasing complexity and increasing numbers of patches getting submitted. I think overall we're doing fine, and occasionally letting good patches get delayed by one release is the price we have to pay, even when it hurts an individual contributor. Arnd
On Tue, Jan 10, 2012 at 08:13:54PM +0000, Arnd Bergmann wrote: > On Tuesday 10 January 2012, Mark Brown wrote: > > That sounds like it'd be helpful overall but it's something that has to > > be sorted out at the maintainer level. I'm guessing there's not really > > much that contributors can do here? > I think you did everything as good as you could, we just need to routinely > call for everyone to submit stuff in time. A number of maintainers sent stuff > after Christmas (which I expected to start the merge window) and were mostly > lucky because Linus gave us an extra 10 days to sort things out. I guess it would also be useful to have some way to compare what's in -next with what's in the arm-soc tree and chase people if that diff gets big. I do also wonder if it's worth letting people push stuff to you more aggressively - right now you seem to be asking people to batch things up and I wonder if that's making it a it easier for things to end up dropping on the floor if a time based routine isn't working well for people. > end, samsung also did for the most part but not entirely and you were > unfortunate to be the contributor of the patches that missed out. It's not just me, I'm just vocal and perhaps more to the point spend a reasonable amount of time chasing stuff into various trees so want to figure out if I need to change what I'm doing with that.
On Tue, Jan 10, 2012 at 2:37 PM, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Tue, Jan 10, 2012 at 08:13:54PM +0000, Arnd Bergmann wrote: >> On Tuesday 10 January 2012, Mark Brown wrote: > >> > That sounds like it'd be helpful overall but it's something that has to >> > be sorted out at the maintainer level. I'm guessing there's not really >> > much that contributors can do here? > >> I think you did everything as good as you could, we just need to routinely >> call for everyone to submit stuff in time. A number of maintainers sent stuff >> after Christmas (which I expected to start the merge window) and were mostly >> lucky because Linus gave us an extra 10 days to sort things out. > > I guess it would also be useful to have some way to compare what's in > -next with what's in the arm-soc tree and chase people if that diff gets > big. I do also wonder if it's worth letting people push stuff to you > more aggressively - right now you seem to be asking people to batch > things up and I wonder if that's making it a it easier for things to end > up dropping on the floor if a time based routine isn't working well for > people. I actually did just this today based on this discussion, and I'll do it through the next staging cycle to keep a track of the "arm backlog" of how much is sitting in maintainer trees vs what has already been merged into Russell's tree or arm-soc. We can include these stats in next rounds "last call for patches" email to help catch forgotten branches. I merged rmk's for-next branch with the arm-soc one, merged that on top of mainline and diffed arch/arm with what is in linux-next. Right now, plus or minus some sloppy merge conflict resolutions on my part, the statistics are: git diff --stat next/master -- arch/arm [..] 113 files changed, 670 insertions(+), 810 deletions(-) (this diffstat does not include late/* branches since they got included in the arm-soc side of the diff) Most of these are rightfully still there; some changes are going through other trees such as some PCI changes, ASoC, PM, a few fixes that haven't been sent up to arm-soc yet, etc. A couple of patches seem to have been queued in for-3.4 branches a bit early (Stephen doesn't generally want people to start queueing new stuff until the merge window is over), but that's just a couple of them. So, it looks like there's no major backlog left for any specific vendor subtree. >> end, samsung also did for the most part but not entirely and you were >> unfortunate to be the contributor of the patches that missed out. > > It's not just me, I'm just vocal and perhaps more to the point spend a > reasonable amount of time chasing stuff into various trees so want to > figure out if I need to change what I'm doing with that. What I would do myself is that if I hadn't seen the patches land in the topmost staging tree by -rc6 or -rc7, I would ping the owner of the tree that the patches are sitting in to make sure they go up. Hopefully this kind of thing will be a rare scenario. -Olof
Russell King - ARM Linux wrote: > > On Mon, Jan 09, 2012 at 08:11:54AM -0800, Mark Brown wrote: [...] > > This really is very disappointing. > > No it isn't. > > What is really disappointing is the lack of responsive maintainers for the > Samsung stuff. It took _two_ bloody months to get the Samsung platforms > sorted for the restart changes in spite of reminding, and a last minute > rush over the course of a couple of days (one _in_ the merge window) to > get it properly merged into my tree. > Yeah, I had to do earlier and it's true that many conflicts caused from my late ARM restart working for Samsung stuff. [...] > So, I support Arnd's view: the Samsung stuff is just too late. Even the > restart updates (which is what has caused this) were too late. Anything > which causes new merge conflicts in the Samsung code is not acceptable at > this point, even if it's a 'fix' patch. We've wasted far too much time > trying to get Samsung stuff sorted far too late in the cycle. > > Let this be an object lesson in what happens if you leave stuff until the > last minute. I will do more carefully next time and of course not too late. Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
Olof Johansson wrote: > [...] > What I would do myself is that if I hadn't seen the patches land in > the topmost staging tree by -rc6 or -rc7, I would ping the owner of > the tree that the patches are sitting in to make sure they go up. Would be helpful to us. > Hopefully this kind of thing will be a rare scenario. > Yes, and Samsung's topic branch will be sent to arm-soc as soon as possible when it's ready from me. Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
On Tuesday 10 January 2012, Mark Brown wrote: > I do also wonder if it's worth letting people push stuff to you > more aggressively - right now you seem to be asking people to batch > things up and I wonder if that's making it a it easier for things to end > up dropping on the floor if a time based routine isn't working well for > people. I really wish people would push stuff into arm-soc more aggressively, and I certainly didn't want to give the impression that maintainers should let their stuff sit in linux-next before sending it to us. It's absolutely fine to send multiple updates per branch for arm-soc as stuff comes in, as long as we can keep track of the dependencies and we don't have to rebase the stuff that's already merged. I would also prefer if people stopped having their own trees included in next, but I know that I'm sometimes slow to pick up patches that were submitted to arm-soc and that it helps people if they can get earlier integration testing that way. Hopefully we're also getting better at dealing with pull requests quickly so that there is no need for the other tree in linux-next any more. Arnd
Hi, On Wed, Jan 11, 2012 at 8:19 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Tuesday 10 January 2012, Mark Brown wrote: > >> I do also wonder if it's worth letting people push stuff to you >> more aggressively - right now you seem to be asking people to batch >> things up and I wonder if that's making it a it easier for things to end >> up dropping on the floor if a time based routine isn't working well for >> people. > > I really wish people would push stuff into arm-soc more aggressively, > and I certainly didn't want to give the impression that maintainers > should let their stuff sit in linux-next before sending it to us. > > It's absolutely fine to send multiple updates per branch for arm-soc > as stuff comes in, as long as we can keep track of the dependencies > and we don't have to rebase the stuff that's already merged. > > I would also prefer if people stopped having their own trees included > in next, but I know that I'm sometimes slow to pick up patches that > were submitted to arm-soc and that it helps people if they can get > earlier integration testing that way. Hopefully we're also getting > better at dealing with pull requests quickly so that there is no > need for the other tree in linux-next any more. There's value in having the vendor trees in linux-next, and the main reason is that it's actually possible for us to see what the backlog is. As mentioned yesterday, I'll try to diff rmk+arm-soc trees with linux-next this upcoming staging cycle to keep track of how much is sitting in vendor trees yet. The alternative is that they sit in a repo somewhere that we don't even know about yet. I also have to admit, as tegra maintainer, that it is convenient to have my tree in linux-next, and have things show up in linux-next as soon as I pick it up, and then send arm-soc pull requests about once a week or so. While we should reduce latency to pull into arm-soc, getting pull requests daily will be a bit on the heavy side. -Olof
On Wed, Jan 11, 2012 at 08:50:54AM -0800, Olof Johansson wrote: > On Wed, Jan 11, 2012 at 8:19 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > I would also prefer if people stopped having their own trees included > > in next, but I know that I'm sometimes slow to pick up patches that > I also have to admit, as tegra maintainer, that it is convenient to > have my tree in linux-next, and have things show up in linux-next as > soon as I pick it up, and then send arm-soc pull requests about once a > week or so. While we should reduce latency to pull into arm-soc, > getting pull requests daily will be a bit on the heavy side. Plus it also means that if there are problems you can resolve it directly rather than having to get the fixes included in a separate tree which helps cut down on latencies.
Hi Arnd, Please pull Samsung devel for v3.3 from: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git next-samsung-devel-samsung It is including s3c64xx cpuidle and development for Cragganmore, ORIGEN and some boards. If any problems, please let me know. Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit 5f0a6e2d503896062f641639dacfe5055c2f593b: Linux 3.2-rc7 (2011-12-23 21:51:06 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git next-samsung-devel-samsung Denis Kuzmenko (1): ARM: S3C2440: Add new LCD (W35i) support for Mini2440 board Jingoo Han (1): ARM: SAMSUNG: Add a callback 'notify_after' for PWM backlight control Kamil Debski (3): ARM: SAMSUNG: add G2D to plat-s5p and mach-exynos ARM: EXYNOS: add G2D to mach-nuri ARM: EXYNOS: add G2D to mach-universal Mark Brown (26): ARM: S3C64XX: Update for conversion to SAMSUNG_GPIO_EXTRA ARM: SAMSUNG: Fix GPIO space reservation for S3C64xx platforms ARM: S3C64XX: Correct reservation of GPIOs for CPU module on Cragganmore ARM: S3C64XX: Raise the frequency of the second I2C bus on Cragganmore ARM: S3C64XX: Use software initiated powerdown for Cragganmore ARM: S3C64XX: Configure WM1250 EV1 GPIOs on Cragganmore ARM: S3C64XX: Improve logging of unknown Cragganmore module types ARM: S3C64XX: Run Tobermory interrupts in the default mode ARM: S3C64XX: Hook up platform data for Kilchomin module on Cragganmore ARM: S3C64XX: Hook up Littlemill audio card on Cragganmore ARM: S3C64XX: Power gate unused domains ARM: S3C64XX: Hook up VDDINT on Cragganmore ARM: S3C64XX: Add basic cpuidle driver ARM: S3C64XX: Gate some more clocks by default ARM: SAMSUNG: Guard against multiple inclusion of plat/dma.h ARM: SAMSUNG: dma-ops.h needs mach/dma.h ARM: S3C64XX: Remove unconditional power domain disables ARM: S3C64XX: Remove hsmmc1 from Cragganmore ARM: SAMSUNG: Declare struct platform_device in plat/s3c64xx-spi.h ARM: S3C64XX: Fix the memory mapped GPIOs on Cragganmore ARM: S3C64XX: Support GPIO LEDs on Cragganmore ARM: S3C64XX: Reduce residency requirement for cpuidle WFI mode ARM: S3C64XX: Fix interrupt configuration for PCA935x on Cragganmore ARM: S3C64XX: Fix build of Cragganmore after SPI changes ARM: S3C64XX: Enable power management for disk on Cragganmore ARM: S3C64XX: Enable power management for WiFi on Cragganmore MyungJoo Ham (3): ARM: EXYNOS: Add DMC1 and allow PPMU access for DMC ARM: EXYNOS: Add clock register addresses for EXYNOS4X12 bus devfreq driver ARM: EXYNOS: Add support EXYNOS4210-bus Devfreq driver on Nuri board Sachin Kamat (1): ARM: EXYNOS: Enable G2D on ORIGEN Sangwook Lee (1): ARM: EXYNOS: Enable Bluetooth on ORIGEN Tushar Behera (1): ARM: EXYNOS: Invert VCLK polarity for framebuffer on ORIGEN arch/arm/mach-exynos/Kconfig | 3 + arch/arm/mach-exynos/cpu.c | 7 +- arch/arm/mach-exynos/include/mach/map.h | 4 + arch/arm/mach-exynos/include/mach/regs-clock.h | 42 +++++++++ arch/arm/mach-exynos/mach-nuri.c | 12 ++- arch/arm/mach-exynos/mach-origen.c | 38 ++++++++- arch/arm/mach-exynos/mach-universal_c210.c | 1 + arch/arm/mach-s3c2440/mach-mini2440.c | 18 ++++ arch/arm/mach-s3c64xx/Kconfig | 7 +- arch/arm/mach-s3c64xx/Makefile | 1 + arch/arm/mach-s3c64xx/clock.c | 21 ++-- arch/arm/mach-s3c64xx/cpuidle.c | 91 ++++++++++++++++++ arch/arm/mach-s3c64xx/include/mach/crag6410.h | 7 +- arch/arm/mach-s3c64xx/include/mach/gpio.h | 2 +- arch/arm/mach-s3c64xx/include/mach/irqs.h | 2 +- arch/arm/mach-s3c64xx/mach-crag6410-module.c | 56 +++++++++++- arch/arm/mach-s3c64xx/mach-crag6410.c | 107 +++++++++++++++++++--- arch/arm/mach-s3c64xx/pm.c | 2 + arch/arm/plat-s5p/Kconfig | 5 + arch/arm/plat-samsung/Kconfig | 8 ++ arch/arm/plat-samsung/dev-backlight.c | 2 + arch/arm/plat-samsung/devs.c | 28 ++++++ arch/arm/plat-samsung/include/plat/devs.h | 1 + arch/arm/plat-samsung/include/plat/dma-ops.h | 1 + arch/arm/plat-samsung/include/plat/dma.h | 6 +- arch/arm/plat-samsung/include/plat/s3c64xx-spi.h | 2 + 26 files changed, 434 insertions(+), 40 deletions(-) create mode 100644 arch/arm/mach-s3c64xx/cpuidle.c