| Message ID | 1301072400-4036-1-git-send-email-nsekhar@ti.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
Hi Russell, SubArch team, This series of 4 patches added SATA support on DaVinci DA850 platform. This was ready for last merge window, but was not queued because of the negative diffstat rule. Is there a possibility of queuing this for the v3.1 merge? Here is the archive link of this posting: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-March/022473.html Here is the summary diffstat: arch/arm/mach-davinci/board-da850-evm.c | 7 ++ arch/arm/mach-davinci/clock.c | 8 +- arch/arm/mach-davinci/clock.h | 1 + arch/arm/mach-davinci/da850.c | 9 ++ arch/arm/mach-davinci/devices-da8xx.c | 122 ++++++++++++++++++++++ arch/arm/mach-davinci/include/mach/da8xx.h | 2 + arch/arm/mach-davinci/include/mach/psc.h | 151 ++++++++++++++-------------- arch/arm/mach-davinci/psc.c | 4 +- 8 files changed, 225 insertions(+), 79 deletions(-) Thanks, Sekhar
On Friday 24 June 2011, Nori, Sekhar wrote: > This series of 4 patches added SATA support on DaVinci > DA850 platform. This was ready for last merge window, > but was not queued because of the negative diffstat > rule. > > Is there a possibility of queuing this for the v3.1 merge? > > Here is the archive link of this posting: > > http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-March/022473.html My general idea is to have multiple branches per subarchitecture, and I started merging stuff into the tree now. Your series contains both cleanups and support for additional features, and I'd like to see those split into separate branches. Please make sure the patches apply on top of 2.6.39 and resubmit them, separating out the first cleanup patch from the others. We can definitely forward all cleanups and bug fixes in the each merge window. For new features, it mostly depends on how much code gets added that should not really be needed in a perfect world, relative to the amount of cleanups that is actually going into the platform in order to get there. In case of the SATA support, the feature is relatively small and requires little board-specific code, which is good. However, if you are planning to push a lot of small additions like this, I would expect you spend much more effort on consolidation within davinci and migration towards device tree probing first. What else do you have pending for davinci in 3.1? Can you send pull requests for cleanups/fixes/device-tree/features? Arnd
Hi Arnd, On Sat, Jun 25, 2011 at 23:18:19, Arnd Bergmann wrote: > On Friday 24 June 2011, Nori, Sekhar wrote: > > This series of 4 patches added SATA support on DaVinci > > DA850 platform. This was ready for last merge window, > > but was not queued because of the negative diffstat > > rule. > > > > Is there a possibility of queuing this for the v3.1 merge? > > > > Here is the archive link of this posting: > > > > http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-March/022473.html > > My general idea is to have multiple branches per subarchitecture, > and I started merging stuff into the tree now. > > Your series contains both cleanups and support for additional > features, and I'd like to see those split into separate branches. Okay. > > Please make sure the patches apply on top of 2.6.39 and resubmit > them, separating out the first cleanup patch from the others. Is it 2.6.39 or v3.0-rc? Linux-next is currently at v3.0-rc4. I can create a branch with just the clean-up stuff and another branch with the features (and its dependencies from fixes/clean-up). By "resubmit" I assume you are not asking for a re-send of the patches to the mailing list (I can do that if you want). > We can definitely forward all cleanups and bug fixes in the each > merge window. For new features, it mostly depends on how much > code gets added that should not really be needed in a perfect > world, relative to the amount of cleanups that is actually > going into the platform in order to get there. Okay. > In case of the SATA support, the feature is relatively small > and requires little board-specific code, which is good. > However, if you are planning to push a lot of small additions > like this, I would expect you spend much more effort on > consolidation within davinci and migration towards device > tree probing first. I don't see new SoCs/boards getting added to the DaVinci tree in the near term but there are some features of existing platforms (like USB on DM365 or SATA on DA850) which are missing in mainline for which there are patches being sent. To my knowledge, there isn't any ongoing work on moving DaVinci to device tree. I am working on getting the low(er) hanging things like GPIO movement to drivers/gpio done. DaVinci will eventually move to device-tree, but may be not as soon as OMAP where there is a lot more active work ongoing. > What else do you have pending for davinci in 3.1? Can you > send pull requests for cleanups/fixes/device-tree/features? Actually not quite a lot at the moment, but there are some patches which are waiting for acks/dependencies and some pending re-work. I will send a pull request with what has been reviewed and accepted already. I guess I also need to ask Stephen Rothwell to remove the DaVinci next branch from the list of branches he is merging for linux-next. Thanks, Sekhar
On Monday 27 June 2011, Nori, Sekhar wrote: > On Sat, Jun 25, 2011 at 23:18:19, Arnd Bergmann wrote: > > On Friday 24 June 2011, Nori, Sekhar wrote: > > Please make sure the patches apply on top of 2.6.39 and resubmit > > them, separating out the first cleanup patch from the others. > > Is it 2.6.39 or v3.0-rc? Linux-next is currently at v3.0-rc4. If there are no conflicts with 3.0-rc changes, submitting based on the previous release (2.6.39) is ok, otherwise just pick the most recent -rc release. Best avoid basing on top of an arbitrary commit between two -rc though. > I can create a branch with just the clean-up stuff and > another branch with the features (and its dependencies > from fixes/clean-up). > > By "resubmit" I assume you are not asking for a re-send > of the patches to the mailing list (I can do that if you > want). I'd prefer submission in form of a git-pull request in this case, but sending to the mailing list is ok, too. > > In case of the SATA support, the feature is relatively small > > and requires little board-specific code, which is good. > > However, if you are planning to push a lot of small additions > > like this, I would expect you spend much more effort on > > consolidation within davinci and migration towards device > > tree probing first. > > I don't see new SoCs/boards getting added to the DaVinci > tree in the near term but there are some features of existing > platforms (like USB on DM365 or SATA on DA850) which are missing > in mainline for which there are patches being sent. > > To my knowledge, there isn't any ongoing work on moving DaVinci > to device tree. I am working on getting the low(er) hanging things > like GPIO movement to drivers/gpio done. DaVinci will eventually > move to device-tree, but may be not as soon as OMAP where > there is a lot more active work ongoing. Yes, makes sense since you are working on both. > > What else do you have pending for davinci in 3.1? Can you > > send pull requests for cleanups/fixes/device-tree/features? > > Actually not quite a lot at the moment, but there are some > patches which are waiting for acks/dependencies and some > pending re-work. > > I will send a pull request with what has been reviewed and > accepted already. Ok. Do you also have a public tree with all the patches that you would hope to get merged eventually? I'd just like to get an impression of what's to come. > I guess I also need to ask Stephen Rothwell to remove the > DaVinci next branch from the list of branches he is merging > for linux-next. Yes, that would be good, but we might need to do that in a more coordinated way for all the ARM platforms once they are reasonably merged into my tree. Arnd
Hi Arnd, On Mon, Jun 27, 2011 at 20:55:14, Arnd Bergmann wrote: > Ok. Do you also have a public tree with all the patches that > you would hope to get merged eventually? I'd just like to > get an impression of what's to come. You can have a look at the git tree: git://gitorious.org/linux-davinci/linux-davinci.git The branch "davinci-next-2" is where the accepted patches have been committed. I have deliberately kept them in a branch not included in linux-next. Thanks, Sekhar
diff --git a/arch/arm/mach-davinci/include/mach/psc.h b/arch/arm/mach-davinci/include/mach/psc.h index a47e6f2..1110fdd 100644 --- a/arch/arm/mach-davinci/include/mach/psc.h +++ b/arch/arm/mach-davinci/include/mach/psc.h @@ -30,47 +30,47 @@ #define DAVINCI_PWR_SLEEP_CNTRL_BASE 0x01C41000 /* Power and Sleep Controller (PSC) Domains */ -#define DAVINCI_GPSC_ARMDOMAIN 0 -#define DAVINCI_GPSC_DSPDOMAIN 1 +#define DAVINCI_GPSC_ARMDOMAIN 0 +#define DAVINCI_GPSC_DSPDOMAIN 1 -#define DAVINCI_LPSC_VPSSMSTR 0 -#define DAVINCI_LPSC_VPSSSLV 1 -#define DAVINCI_LPSC_TPCC 2 -#define DAVINCI_LPSC_TPTC0 3 -#define DAVINCI_LPSC_TPTC1 4 -#define DAVINCI_LPSC_EMAC 5 -#define DAVINCI_LPSC_EMAC_WRAPPER 6 -#define DAVINCI_LPSC_USB 9 -#define DAVINCI_LPSC_ATA 10 -#define DAVINCI_LPSC_VLYNQ 11 -#define DAVINCI_LPSC_UHPI 12 -#define DAVINCI_LPSC_DDR_EMIF 13 -#define DAVINCI_LPSC_AEMIF 14 -#define DAVINCI_LPSC_MMC_SD 15 -#define DAVINCI_LPSC_McBSP 17 -#define DAVINCI_LPSC_I2C 18 -#define DAVINCI_LPSC_UART0 19 -#define DAVINCI_LPSC_UART1 20 -#define DAVINCI_LPSC_UART2 21 -#define DAVINCI_LPSC_SPI 22 -#define DAVINCI_LPSC_PWM0 23 -#define DAVINCI_LPSC_PWM1 24 -#define DAVINCI_LPSC_PWM2 25 -#define DAVINCI_LPSC_GPIO 26 -#define DAVINCI_LPSC_TIMER0 27 -#define DAVINCI_LPSC_TIMER1 28 -#define DAVINCI_LPSC_TIMER2 29 -#define DAVINCI_LPSC_SYSTEM_SUBSYS 30 -#define DAVINCI_LPSC_ARM 31 -#define DAVINCI_LPSC_SCR2 32 -#define DAVINCI_LPSC_SCR3 33 -#define DAVINCI_LPSC_SCR4 34 -#define DAVINCI_LPSC_CROSSBAR 35 -#define DAVINCI_LPSC_CFG27 36 -#define DAVINCI_LPSC_CFG3 37 -#define DAVINCI_LPSC_CFG5 38 -#define DAVINCI_LPSC_GEM 39 -#define DAVINCI_LPSC_IMCOP 40 +#define DAVINCI_LPSC_VPSSMSTR 0 +#define DAVINCI_LPSC_VPSSSLV 1 +#define DAVINCI_LPSC_TPCC 2 +#define DAVINCI_LPSC_TPTC0 3 +#define DAVINCI_LPSC_TPTC1 4 +#define DAVINCI_LPSC_EMAC 5 +#define DAVINCI_LPSC_EMAC_WRAPPER 6 +#define DAVINCI_LPSC_USB 9 +#define DAVINCI_LPSC_ATA 10 +#define DAVINCI_LPSC_VLYNQ 11 +#define DAVINCI_LPSC_UHPI 12 +#define DAVINCI_LPSC_DDR_EMIF 13 +#define DAVINCI_LPSC_AEMIF 14 +#define DAVINCI_LPSC_MMC_SD 15 +#define DAVINCI_LPSC_McBSP 17 +#define DAVINCI_LPSC_I2C 18 +#define DAVINCI_LPSC_UART0 19 +#define DAVINCI_LPSC_UART1 20 +#define DAVINCI_LPSC_UART2 21 +#define DAVINCI_LPSC_SPI 22 +#define DAVINCI_LPSC_PWM0 23 +#define DAVINCI_LPSC_PWM1 24 +#define DAVINCI_LPSC_PWM2 25 +#define DAVINCI_LPSC_GPIO 26 +#define DAVINCI_LPSC_TIMER0 27 +#define DAVINCI_LPSC_TIMER1 28 +#define DAVINCI_LPSC_TIMER2 29 +#define DAVINCI_LPSC_SYSTEM_SUBSYS 30 +#define DAVINCI_LPSC_ARM 31 +#define DAVINCI_LPSC_SCR2 32 +#define DAVINCI_LPSC_SCR3 33 +#define DAVINCI_LPSC_SCR4 34 +#define DAVINCI_LPSC_CROSSBAR 35 +#define DAVINCI_LPSC_CFG27 36 +#define DAVINCI_LPSC_CFG3 37 +#define DAVINCI_LPSC_CFG5 38 +#define DAVINCI_LPSC_GEM 39 +#define DAVINCI_LPSC_IMCOP 40 #define DM355_LPSC_TIMER3 5 #define DM355_LPSC_SPI1 6 @@ -102,39 +102,39 @@ /* * LPSC Assignments */ -#define DM646X_LPSC_ARM 0 -#define DM646X_LPSC_C64X_CPU 1 -#define DM646X_LPSC_HDVICP0 2 -#define DM646X_LPSC_HDVICP1 3 -#define DM646X_LPSC_TPCC 4 -#define DM646X_LPSC_TPTC0 5 -#define DM646X_LPSC_TPTC1 6 -#define DM646X_LPSC_TPTC2 7 -#define DM646X_LPSC_TPTC3 8 -#define DM646X_LPSC_PCI 13 -#define DM646X_LPSC_EMAC 14 -#define DM646X_LPSC_VDCE 15 -#define DM646X_LPSC_VPSSMSTR 16 -#define DM646X_LPSC_VPSSSLV 17 -#define DM646X_LPSC_TSIF0 18 -#define DM646X_LPSC_TSIF1 19 -#define DM646X_LPSC_DDR_EMIF 20 -#define DM646X_LPSC_AEMIF 21 -#define DM646X_LPSC_McASP0 22 -#define DM646X_LPSC_McASP1 23 -#define DM646X_LPSC_CRGEN0 24 -#define DM646X_LPSC_CRGEN1 25 -#define DM646X_LPSC_UART0 26 -#define DM646X_LPSC_UART1 27 -#define DM646X_LPSC_UART2 28 -#define DM646X_LPSC_PWM0 29 -#define DM646X_LPSC_PWM1 30 -#define DM646X_LPSC_I2C 31 -#define DM646X_LPSC_SPI 32 -#define DM646X_LPSC_GPIO 33 -#define DM646X_LPSC_TIMER0 34 -#define DM646X_LPSC_TIMER1 35 -#define DM646X_LPSC_ARM_INTC 45 +#define DM646X_LPSC_ARM 0 +#define DM646X_LPSC_C64X_CPU 1 +#define DM646X_LPSC_HDVICP0 2 +#define DM646X_LPSC_HDVICP1 3 +#define DM646X_LPSC_TPCC 4 +#define DM646X_LPSC_TPTC0 5 +#define DM646X_LPSC_TPTC1 6 +#define DM646X_LPSC_TPTC2 7 +#define DM646X_LPSC_TPTC3 8 +#define DM646X_LPSC_PCI 13 +#define DM646X_LPSC_EMAC 14 +#define DM646X_LPSC_VDCE 15 +#define DM646X_LPSC_VPSSMSTR 16 +#define DM646X_LPSC_VPSSSLV 17 +#define DM646X_LPSC_TSIF0 18 +#define DM646X_LPSC_TSIF1 19 +#define DM646X_LPSC_DDR_EMIF 20 +#define DM646X_LPSC_AEMIF 21 +#define DM646X_LPSC_McASP0 22 +#define DM646X_LPSC_McASP1 23 +#define DM646X_LPSC_CRGEN0 24 +#define DM646X_LPSC_CRGEN1 25 +#define DM646X_LPSC_UART0 26 +#define DM646X_LPSC_UART1 27 +#define DM646X_LPSC_UART2 28 +#define DM646X_LPSC_PWM0 29 +#define DM646X_LPSC_PWM1 30 +#define DM646X_LPSC_I2C 31 +#define DM646X_LPSC_SPI 32 +#define DM646X_LPSC_GPIO 33 +#define DM646X_LPSC_TIMER0 34 +#define DM646X_LPSC_TIMER1 35 +#define DM646X_LPSC_ARM_INTC 45 /* PSC0 defines */ #define DA8XX_LPSC0_TPCC 0 @@ -243,7 +243,7 @@ #define PSC_STATE_DISABLE 2 #define PSC_STATE_ENABLE 3 -#define MDSTAT_STATE_MASK 0x1f +#define MDSTAT_STATE_MASK 0x1f #ifndef __ASSEMBLER__