Message ID | 20141119070306.GF27759@dragon |
---|---|
State | New |
Headers | show |
On Wednesday 19 November 2014, Shawn Guo wrote: > The following changes since commit fc14f9c1272f62c3e8d01300f52467c0d9af50f9: > > Linux 3.18-rc5 (2014-11-16 16:36:20 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-soc-3.19 > > for you to fetch changes up to dc7aaa041842eb40be7ad7bde0a7e37ac1efd79c: > > ARM: configs: imx_v6_v7_defconfig: add power off driver (2014-11-19 11:51:55 +0800) > > ---------------------------------------------------------------- > The i.MX SoC update for 3.19: > - Update i.MX6 suspend code to check DDR instead of CPU type, as the > difference we need to handle is between LPDDR2 and DDR3, not SoCs. > - Set anatop properly for LPDDR2 in DSM mode > - Add support for new SoC LS1021A which integrates dual Cortex-A7 > - Add ENET initialization for i.MX6SX platform > - Add cpufreq support for i.MX53 platform > - Add a SNVS based poweroff driver for i.MX6 platforms > - Use ARM Global Timer as clocksource on VF610 > - Some defconfig updates Hi Shawn, The changes all look good, but could you please send them again based on v3.18-rc1? I'm trying to avoid back-merges from upstream into the next branches. Also, note that we've started splitting out defconfig changes into a separate topic branch. Since you are rebasing anyway, please send the defconfig change as a separate patch or pull request and also update multi_v7_defconfig in the same way. Arnd
Hi Arnd, On Fri, Nov 21, 2014 at 12:30 AM, Arnd Bergmann <arnd@arndb.de> wrote: > The changes all look good, but could you please send them again based on > v3.18-rc1? I'm trying to avoid back-merges from upstream into the next > branches. The imx/cleanup branch can simply be based on v3.18-rc1. But I choose to base imx/soc on a latest -rc to resolve a conflict between commit 410ba8d4a0da (ARM: imx: clk-vf610: get input clocks from assigned clocks) and c72c553249bb (ARM: imx: clk-vf610: define PLL's clock tree). The former one is currently sits on imx/soc branch, and the latter landed on -rc4 as a fix. I think we can handle it in either way of the following two. 1. Drop commit 410ba8d4a0da (ARM: imx: clk-vf610: get input clocks from assigned clocks) from imx/soc branch and send it as a fix for 3.18 right way. 2. Keep 410ba8d4a0da on imx/soc and leave the merge conflict to Linus. What's your preference? > > Also, note that we've started splitting out defconfig changes into > a separate topic branch. Since you are rebasing anyway, please send > the defconfig change as a separate patch or pull request and also > update multi_v7_defconfig in the same way. Okay, to keep it simple, I will squashed the defconfig updates into one patch and send it to you. Shawn
On Friday 21 November 2014 16:37:55 Shawn Guo wrote: > On Fri, Nov 21, 2014 at 12:30 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > The changes all look good, but could you please send them again based on > > v3.18-rc1? I'm trying to avoid back-merges from upstream into the next > > branches. > > The imx/cleanup branch can simply be based on v3.18-rc1. But I choose > to base imx/soc on a latest -rc to resolve a conflict between commit > 410ba8d4a0da (ARM: imx: clk-vf610: get input clocks from assigned > clocks) and c72c553249bb (ARM: imx: clk-vf610: define PLL's clock > tree). The former one is currently sits on imx/soc branch, and the > latter landed on -rc4 as a fix. I think we can handle it in either > way of the following two. > > 1. Drop commit 410ba8d4a0da (ARM: imx: clk-vf610: get input clocks > from assigned clocks) from imx/soc branch and send it as a fix for > 3.18 right way. > > 2. Keep 410ba8d4a0da on imx/soc and leave the merge conflict to Linus. > > What's your preference? I think the best approach in this case would be to rebase your series on top of 410ba8d4a0da. next/soc already contains -rc3 but not -rc4, so this would solve the backmerge problem nicely. > > > > Also, note that we've started splitting out defconfig changes into > > a separate topic branch. Since you are rebasing anyway, please send > > the defconfig change as a separate patch or pull request and also > > update multi_v7_defconfig in the same way. > > Okay, to keep it simple, I will squashed the defconfig updates into > one patch and send it to you. Ok, sounds good, thanks! Arnd