| Message ID | 1382993006-27359-3-git-send-email-davidb@codeaurora.org (mailing list archive) |
|---|---|
| State | Rejected, archived |
| Headers | show |
That's not very nice .. You know there is a device connect with this that several of us have.. On Mon, Oct 28, 2013 at 01:43:24PM -0700, David Brown wrote: > Support for the MSM7x00 SoCs was added starting in 2008 based on code > from Google's Android kernels. Platform support is fairly minimal, > and there have primarily been trivial and cleanup changes to this > code. > > This code has not been converted to device tree, and is hindering > supporting multi-platform on ARM. If someone wishes to continue > support for this target, patches that provide devicetree and > multi-platform support can start by re-adding these files. > > Signed-off-by: David Brown <davidb@codeaurora.org> > --- > Note that this patch was made with -D. I can send the full patch on > request, and have also made the tree available at: > > git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git for-3.14/big-cleanup > > arch/arm/mach-msm/Kconfig | 32 +- > arch/arm/mach-msm/Makefile | 4 - > arch/arm/mach-msm/board-halibut.c | 110 ------ > arch/arm/mach-msm/board-trout-gpio.c | 233 ------------ > arch/arm/mach-msm/board-trout-mmc.c | 185 --------- > arch/arm/mach-msm/board-trout-panel.c | 292 -------------- > arch/arm/mach-msm/board-trout.c | 113 ------ > arch/arm/mach-msm/board-trout.h | 162 -------- > arch/arm/mach-msm/devices-msm7x00.c | 480 ------------------------ > arch/arm/mach-msm/include/mach/irqs-7x00.h | 75 ---- > arch/arm/mach-msm/include/mach/msm_iomap-7x00.h | 108 ------ > arch/arm/mach-msm/irq.c | 151 -------- > 12 files changed, 1 insertion(+), 1944 deletions(-) > delete mode 100644 arch/arm/mach-msm/board-halibut.c > delete mode 100644 arch/arm/mach-msm/board-trout-gpio.c > delete mode 100644 arch/arm/mach-msm/board-trout-mmc.c > delete mode 100644 arch/arm/mach-msm/board-trout-panel.c > delete mode 100644 arch/arm/mach-msm/board-trout.c > delete mode 100644 arch/arm/mach-msm/board-trout.h > delete mode 100644 arch/arm/mach-msm/devices-msm7x00.c > delete mode 100644 arch/arm/mach-msm/include/mach/irqs-7x00.h > delete mode 100644 arch/arm/mach-msm/include/mach/msm_iomap-7x00.h > delete mode 100644 arch/arm/mach-msm/irq.c > > diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig > index 2586c28..d43d20c 100644 > --- a/arch/arm/mach-msm/Kconfig > +++ b/arch/arm/mach-msm/Kconfig > @@ -5,19 +5,9 @@ comment "Qualcomm MSM SoC Type" > > choice > prompt "Qualcomm MSM SoC Type" > - default ARCH_MSM7X00A > + default ARCH_MSM7X30 > depends on !ARCH_MSM_DT > > -config ARCH_MSM7X00A > - bool "MSM7x00A / MSM7x01A" > - select ARCH_MSM_ARM11 > - select CPU_V6 > - select GPIO_MSM_V1 > - select MACH_TROUT if !MACH_HALIBUT > - select MSM_PROC_COMM > - select MSM_SMD > - select MSM_SMD_PKG3 > - > config ARCH_MSM7X30 > bool "MSM7x30" > select ARCH_MSM_SCORPION > @@ -70,9 +60,6 @@ config MSM_HAS_DEBUG_UART_HS > config MSM_SOC_REV_A > bool > > -config ARCH_MSM_ARM11 > - bool > - > config ARCH_MSM_SCORPION > bool > > @@ -82,20 +69,6 @@ config MSM_VIC > menu "Qualcomm MSM Board Type" > depends on !ARCH_MSM_DT > > -config MACH_HALIBUT > - depends on ARCH_MSM > - depends on ARCH_MSM7X00A > - bool "Halibut Board (QCT SURF7201A)" > - help > - Support for the Qualcomm SURF7201A eval board. > - > -config MACH_TROUT > - depends on ARCH_MSM > - depends on ARCH_MSM7X00A > - bool "HTC Dream (aka trout)" > - help > - Support for the HTC Dream, T-Mobile G1, Android ADP1 devices. > - > config MACH_MSM7X30_SURF > depends on ARCH_MSM7X30 > bool "MSM7x30 SURF" > @@ -117,9 +90,6 @@ config MACH_QSD8X50A_ST1_5 > > endmenu > > -config MSM_SMD_PKG3 > - bool > - > config MSM_PROC_COMM > bool > > diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile > index 7ed4c1b..c7a5b53 100644 > --- a/arch/arm/mach-msm/Makefile > +++ b/arch/arm/mach-msm/Makefile > @@ -3,7 +3,6 @@ obj-y += clock.o > > obj-$(CONFIG_MSM_VIC) += irq-vic.o > > -obj-$(CONFIG_ARCH_MSM7X00A) += irq.o > obj-$(CONFIG_ARCH_QSD8X50) += sirc.o > > obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o > @@ -21,9 +20,6 @@ CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1) > obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o > obj-$(CONFIG_SMP) += headsmp.o platsmp.o > > -obj-$(CONFIG_MACH_TROUT) += board-trout.o board-trout-gpio.o board-trout-mmc.o devices-msm7x00.o > -obj-$(CONFIG_MACH_TROUT) += board-trout.o board-trout-gpio.o board-trout-mmc.o board-trout-panel.o devices-msm7x00.o > -obj-$(CONFIG_MACH_HALIBUT) += board-halibut.o devices-msm7x00.o > obj-$(CONFIG_ARCH_MSM7X30) += board-msm7x30.o devices-msm7x30.o > obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o devices-qsd8x50.o > obj-$(CONFIG_ARCH_MSM_DT) += board-dt.o > diff --git a/arch/arm/mach-msm/board-halibut.c b/arch/arm/mach-msm/board-halibut.c > deleted file mode 100644 > index a775298..0000000 > diff --git a/arch/arm/mach-msm/board-trout-gpio.c b/arch/arm/mach-msm/board-trout-gpio.c > deleted file mode 100644 > index 87e1d01..0000000 > diff --git a/arch/arm/mach-msm/board-trout-mmc.c b/arch/arm/mach-msm/board-trout-mmc.c > deleted file mode 100644 > index 3723e55..0000000 > diff --git a/arch/arm/mach-msm/board-trout-panel.c b/arch/arm/mach-msm/board-trout-panel.c > deleted file mode 100644 > index 77b0a26..0000000 > diff --git a/arch/arm/mach-msm/board-trout.c b/arch/arm/mach-msm/board-trout.c > deleted file mode 100644 > index ccf6621..0000000 > diff --git a/arch/arm/mach-msm/board-trout.h b/arch/arm/mach-msm/board-trout.h > deleted file mode 100644 > index b2379ed..0000000 > diff --git a/arch/arm/mach-msm/devices-msm7x00.c b/arch/arm/mach-msm/devices-msm7x00.c > deleted file mode 100644 > index d83404d..0000000 > diff --git a/arch/arm/mach-msm/include/mach/irqs-7x00.h b/arch/arm/mach-msm/include/mach/irqs-7x00.h > deleted file mode 100644 > index f1fe706..0000000 > diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-7x00.h b/arch/arm/mach-msm/include/mach/msm_iomap-7x00.h > deleted file mode 100644 > index 67dc0e9..0000000 > diff --git a/arch/arm/mach-msm/irq.c b/arch/arm/mach-msm/irq.c > deleted file mode 100644 > index ea514be..0000000 > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > hosted by The Linux Foundation > -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Daniel, I would be very happy to take more code for the older Qualcomm chipset to enable full functionality for them, but it's been my impression that far from all that is needed to make it a useful platform is in the upstream kernel, and there's been no signs of more of it showing up at least in the last two years. So we have a bit of a stalemate here -- the current Qualcomm team wants to avoid having to deal too much with the legacy platforms -- they are technically quite different from the current platforms and the divergence makes it hard to deal with supporting it all in a modern way without risking regressions. I tend to agree with them. Just like omap split between omap1 and omap2plus, I think it's a time to create a mach-qcom instead, and move the modern (v7, most likely) platforms there -- enable them with device tree, modern framework infrastructure, etc. That way you can keep older platforms in mach-msm without risk of regressions, and they have a clean base to start on with their later platforms. -Olof On Tue, Oct 29, 2013 at 6:21 AM, Daniel Walker <dwalker@fifo99.com> wrote: > > That's not very nice .. You know there is a device connect with this > that several of us have.. > > > On Mon, Oct 28, 2013 at 01:43:24PM -0700, David Brown wrote: >> Support for the MSM7x00 SoCs was added starting in 2008 based on code >> from Google's Android kernels. Platform support is fairly minimal, >> and there have primarily been trivial and cleanup changes to this >> code. >> >> This code has not been converted to device tree, and is hindering >> supporting multi-platform on ARM. If someone wishes to continue >> support for this target, patches that provide devicetree and >> multi-platform support can start by re-adding these files. >> >> Signed-off-by: David Brown <davidb@codeaurora.org> >> --- >> Note that this patch was made with -D. I can send the full patch on >> request, and have also made the tree available at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git for-3.14/big-cleanup >> >> arch/arm/mach-msm/Kconfig | 32 +- >> arch/arm/mach-msm/Makefile | 4 - >> arch/arm/mach-msm/board-halibut.c | 110 ------ >> arch/arm/mach-msm/board-trout-gpio.c | 233 ------------ >> arch/arm/mach-msm/board-trout-mmc.c | 185 --------- >> arch/arm/mach-msm/board-trout-panel.c | 292 -------------- >> arch/arm/mach-msm/board-trout.c | 113 ------ >> arch/arm/mach-msm/board-trout.h | 162 -------- >> arch/arm/mach-msm/devices-msm7x00.c | 480 ------------------------ >> arch/arm/mach-msm/include/mach/irqs-7x00.h | 75 ---- >> arch/arm/mach-msm/include/mach/msm_iomap-7x00.h | 108 ------ >> arch/arm/mach-msm/irq.c | 151 -------- >> 12 files changed, 1 insertion(+), 1944 deletions(-) >> delete mode 100644 arch/arm/mach-msm/board-halibut.c >> delete mode 100644 arch/arm/mach-msm/board-trout-gpio.c >> delete mode 100644 arch/arm/mach-msm/board-trout-mmc.c >> delete mode 100644 arch/arm/mach-msm/board-trout-panel.c >> delete mode 100644 arch/arm/mach-msm/board-trout.c >> delete mode 100644 arch/arm/mach-msm/board-trout.h >> delete mode 100644 arch/arm/mach-msm/devices-msm7x00.c >> delete mode 100644 arch/arm/mach-msm/include/mach/irqs-7x00.h >> delete mode 100644 arch/arm/mach-msm/include/mach/msm_iomap-7x00.h >> delete mode 100644 arch/arm/mach-msm/irq.c >> >> diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig >> index 2586c28..d43d20c 100644 >> --- a/arch/arm/mach-msm/Kconfig >> +++ b/arch/arm/mach-msm/Kconfig >> @@ -5,19 +5,9 @@ comment "Qualcomm MSM SoC Type" >> >> choice >> prompt "Qualcomm MSM SoC Type" >> - default ARCH_MSM7X00A >> + default ARCH_MSM7X30 >> depends on !ARCH_MSM_DT >> >> -config ARCH_MSM7X00A >> - bool "MSM7x00A / MSM7x01A" >> - select ARCH_MSM_ARM11 >> - select CPU_V6 >> - select GPIO_MSM_V1 >> - select MACH_TROUT if !MACH_HALIBUT >> - select MSM_PROC_COMM >> - select MSM_SMD >> - select MSM_SMD_PKG3 >> - >> config ARCH_MSM7X30 >> bool "MSM7x30" >> select ARCH_MSM_SCORPION >> @@ -70,9 +60,6 @@ config MSM_HAS_DEBUG_UART_HS >> config MSM_SOC_REV_A >> bool >> >> -config ARCH_MSM_ARM11 >> - bool >> - >> config ARCH_MSM_SCORPION >> bool >> >> @@ -82,20 +69,6 @@ config MSM_VIC >> menu "Qualcomm MSM Board Type" >> depends on !ARCH_MSM_DT >> >> -config MACH_HALIBUT >> - depends on ARCH_MSM >> - depends on ARCH_MSM7X00A >> - bool "Halibut Board (QCT SURF7201A)" >> - help >> - Support for the Qualcomm SURF7201A eval board. >> - >> -config MACH_TROUT >> - depends on ARCH_MSM >> - depends on ARCH_MSM7X00A >> - bool "HTC Dream (aka trout)" >> - help >> - Support for the HTC Dream, T-Mobile G1, Android ADP1 devices. >> - >> config MACH_MSM7X30_SURF >> depends on ARCH_MSM7X30 >> bool "MSM7x30 SURF" >> @@ -117,9 +90,6 @@ config MACH_QSD8X50A_ST1_5 >> >> endmenu >> >> -config MSM_SMD_PKG3 >> - bool >> - >> config MSM_PROC_COMM >> bool >> >> diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile >> index 7ed4c1b..c7a5b53 100644 >> --- a/arch/arm/mach-msm/Makefile >> +++ b/arch/arm/mach-msm/Makefile >> @@ -3,7 +3,6 @@ obj-y += clock.o >> >> obj-$(CONFIG_MSM_VIC) += irq-vic.o >> >> -obj-$(CONFIG_ARCH_MSM7X00A) += irq.o >> obj-$(CONFIG_ARCH_QSD8X50) += sirc.o >> >> obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o >> @@ -21,9 +20,6 @@ CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1) >> obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o >> obj-$(CONFIG_SMP) += headsmp.o platsmp.o >> >> -obj-$(CONFIG_MACH_TROUT) += board-trout.o board-trout-gpio.o board-trout-mmc.o devices-msm7x00.o >> -obj-$(CONFIG_MACH_TROUT) += board-trout.o board-trout-gpio.o board-trout-mmc.o board-trout-panel.o devices-msm7x00.o >> -obj-$(CONFIG_MACH_HALIBUT) += board-halibut.o devices-msm7x00.o >> obj-$(CONFIG_ARCH_MSM7X30) += board-msm7x30.o devices-msm7x30.o >> obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o devices-qsd8x50.o >> obj-$(CONFIG_ARCH_MSM_DT) += board-dt.o >> diff --git a/arch/arm/mach-msm/board-halibut.c b/arch/arm/mach-msm/board-halibut.c >> deleted file mode 100644 >> index a775298..0000000 >> diff --git a/arch/arm/mach-msm/board-trout-gpio.c b/arch/arm/mach-msm/board-trout-gpio.c >> deleted file mode 100644 >> index 87e1d01..0000000 >> diff --git a/arch/arm/mach-msm/board-trout-mmc.c b/arch/arm/mach-msm/board-trout-mmc.c >> deleted file mode 100644 >> index 3723e55..0000000 >> diff --git a/arch/arm/mach-msm/board-trout-panel.c b/arch/arm/mach-msm/board-trout-panel.c >> deleted file mode 100644 >> index 77b0a26..0000000 >> diff --git a/arch/arm/mach-msm/board-trout.c b/arch/arm/mach-msm/board-trout.c >> deleted file mode 100644 >> index ccf6621..0000000 >> diff --git a/arch/arm/mach-msm/board-trout.h b/arch/arm/mach-msm/board-trout.h >> deleted file mode 100644 >> index b2379ed..0000000 >> diff --git a/arch/arm/mach-msm/devices-msm7x00.c b/arch/arm/mach-msm/devices-msm7x00.c >> deleted file mode 100644 >> index d83404d..0000000 >> diff --git a/arch/arm/mach-msm/include/mach/irqs-7x00.h b/arch/arm/mach-msm/include/mach/irqs-7x00.h >> deleted file mode 100644 >> index f1fe706..0000000 >> diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-7x00.h b/arch/arm/mach-msm/include/mach/msm_iomap-7x00.h >> deleted file mode 100644 >> index 67dc0e9..0000000 >> diff --git a/arch/arm/mach-msm/irq.c b/arch/arm/mach-msm/irq.c >> deleted file mode 100644 >> index ea514be..0000000 >> -- >> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, >> hosted by The Linux Foundation >> -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 29, 2013 at 08:37:28AM -0700, Olof Johansson wrote: > Daniel, > > I would be very happy to take more code for the older Qualcomm chipset > to enable full functionality for them, but it's been my impression > that far from all that is needed to make it a useful platform is in > the upstream kernel, and there's been no signs of more of it showing > up at least in the last two years. Some of the platform code he's removing is not compiled right now. I would have liked to make it compile, but I don't care that much (and they don't either) .. > So we have a bit of a stalemate here -- the current Qualcomm team > wants to avoid having to deal too much with the legacy platforms -- > they are technically quite different from the current platforms and > the divergence makes it hard to deal with supporting it all in a > modern way without risking regressions. I tend to agree with them. Oh what a sob story .. They can't claim to maintain msm except for the parts they don't like that much, thats not how it works. If you have a technical reason why you think hard to maintain code is "hard to deal with", please put that forth . If they want they can start submitting their patches to me, and I can deal with their "hard to deal with" stuff.. > Just like omap split between omap1 and omap2plus, I think it's a time > to create a mach-qcom instead, and move the modern (v7, most likely) > platforms there -- enable them with device tree, modern framework > infrastructure, etc. That way you can keep older platforms in mach-msm > without risk of regressions, and they have a clean base to start on > with their later platforms. Personally I think splitting mach- stuff isn't very useful or interesting.. There's just no technical reason for it, for example x86 and x86_64 was a win from my perspective , there's a lot more reason to keep similar things together than to split things up. The whole risking regressions, do you have proof of why you think that's happening ? The inverse seems more likely.. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 29, 2013 at 10:08 AM, Daniel Walker <dwalker@fifo99.com> wrote: > Personally I think splitting mach- stuff isn't very useful or > interesting.. There's just no technical reason for it, for example x86 > and x86_64 was a win from my perspective , there's a lot more reason to > keep similar things together than to split things up. There are definitely valid technical reasons for it; the old and new platforms share no code, and the legacy platforms are unlikely to be updated to modern infrastructure anytime soon. Other platforms are managed in similar manners, such as OMAP, imx/mxs, etc. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Olof Johansson <olof@lixom.net> [131029 10:40]: > On Tue, Oct 29, 2013 at 10:08 AM, Daniel Walker <dwalker@fifo99.com> wrote: > > > Personally I think splitting mach- stuff isn't very useful or > > interesting.. There's just no technical reason for it, for example x86 > > and x86_64 was a win from my perspective , there's a lot more reason to > > keep similar things together than to split things up. > > There are definitely valid technical reasons for it; the old and new > platforms share no code, and the legacy platforms are unlikely to be > updated to modern infrastructure anytime soon. Other platforms are > managed in similar manners, such as OMAP, imx/mxs, etc. Yeah there are still few valid reasons to have separate mach directories. The main reason why mach-omap2 was originally set up separately from mach-omap1 was because the IO space was different. And we could not properly deal with that until CONFIG_ARM_PATCH_PHYS_VIRT few years ago. So we placed the shared code into plat-omap, which worked OK but is not really needed any longer with device tree. We have only dmtimer and legacy DMA code left in plat-omap pretty much. And those will be moved to live under drivers/. Even with most issues fixed, it still does not not make sense to merge mach-omap1 and mach-omap2. For example, even if somebody wanted to do it as a hobby project, we'd have to compile things with v4 or v5 flags, which won't work properly for SMP cores at least :) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 29, 2013 at 10:39:45AM -0700, Olof Johansson wrote: > On Tue, Oct 29, 2013 at 10:08 AM, Daniel Walker <dwalker@fifo99.com> wrote: > > > Personally I think splitting mach- stuff isn't very useful or > > interesting.. There's just no technical reason for it, for example x86 > > and x86_64 was a win from my perspective , there's a lot more reason to > > keep similar things together than to split things up. > > There are definitely valid technical reasons for it; the old and new > platforms share no code, and the legacy platforms are unlikely to be > updated to modern infrastructure anytime soon. Other platforms are > managed in similar manners, such as OMAP, imx/mxs, etc. Are you speaking from a meta perspective , or you have specific example in msm code ? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Olof Johansson <olof@lixom.net> writes: > I would be very happy to take more code for the older Qualcomm chipset > to enable full functionality for them, but it's been my impression > that far from all that is needed to make it a useful platform is in > the upstream kernel, and there's been no signs of more of it showing > up at least in the last two years. > > So we have a bit of a stalemate here -- the current Qualcomm team > wants to avoid having to deal too much with the legacy platforms -- > they are technically quite different from the current platforms and > the divergence makes it hard to deal with supporting it all in a > modern way without risking regressions. I tend to agree with them. As do I. > Just like omap split between omap1 and omap2plus, I think it's a time > to create a mach-qcom instead, and move the modern (v7, most likely) > platforms there -- enable them with device tree, modern framework > infrastructure, etc. That way you can keep older platforms in mach-msm > without risk of regressions, and they have a clean base to start on > with their later platforms. I think this split approach is a good compromise. If the maintainers of the current older platforms wish to bring them up to modern frameworks, we can consider combining again. If not, they the older platforms will take the same path as the rest of the older platforms that slowly fade away. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 30, 2013 at 04:08:27PM -0700, Kevin Hilman wrote: > Olof Johansson <olof@lixom.net> writes: > > > I would be very happy to take more code for the older Qualcomm chipset > > to enable full functionality for them, but it's been my impression > > that far from all that is needed to make it a useful platform is in > > the upstream kernel, and there's been no signs of more of it showing > > up at least in the last two years. > > > > So we have a bit of a stalemate here -- the current Qualcomm team > > wants to avoid having to deal too much with the legacy platforms -- > > they are technically quite different from the current platforms and > > the divergence makes it hard to deal with supporting it all in a > > modern way without risking regressions. I tend to agree with them. > > As do I. > > > Just like omap split between omap1 and omap2plus, I think it's a time > > to create a mach-qcom instead, and move the modern (v7, most likely) > > platforms there -- enable them with device tree, modern framework > > infrastructure, etc. That way you can keep older platforms in mach-msm > > without risk of regressions, and they have a clean base to start on > > with their later platforms. > > I think this split approach is a good compromise. > > If the maintainers of the current older platforms wish to bring them up > to modern frameworks, we can consider combining again. If not, they the > older platforms will take the same path as the rest of the older > platforms that slowly fade away. > So the current users of those platforms are, what SOL ? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 30, 2013 at 4:25 PM, Daniel Walker <dwalker@fifo99.com> wrote:
> So the current users of those platforms are, what SOL ?
What users? Show me one.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 30, 2013 at 05:36:58PM -0700, Olof Johansson wrote: > On Wed, Oct 30, 2013 at 4:25 PM, Daniel Walker <dwalker@fifo99.com> wrote: > > > So the current users of those platforms are, what SOL ? > > What users? Show me one. > What am I chop liver ? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 30, 2013 at 7:45 PM, Daniel Walker <dwalker@fifo99.com> wrote: > On Wed, Oct 30, 2013 at 05:36:58PM -0700, Olof Johansson wrote: >> On Wed, Oct 30, 2013 at 4:25 PM, Daniel Walker <dwalker@fifo99.com> wrote: >> >> > So the current users of those platforms are, what SOL ? >> >> What users? Show me one. > > What am I chop liver ? Ah, right. So, what platforms do you currently rely on mainline support for? Please be precise so we can figure out what needs to be kept and not. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 30, 2013 at 10:19:30PM -0700, Olof Johansson wrote: > On Wed, Oct 30, 2013 at 7:45 PM, Daniel Walker <dwalker@fifo99.com> wrote: > > On Wed, Oct 30, 2013 at 05:36:58PM -0700, Olof Johansson wrote: > >> On Wed, Oct 30, 2013 at 4:25 PM, Daniel Walker <dwalker@fifo99.com> wrote: > >> > >> > So the current users of those platforms are, what SOL ? > >> > >> What users? Show me one. > > > > What am I chop liver ? > > Ah, right. So, what platforms do you currently rely on mainline > support for? Please be precise so we can figure out what needs to be > kept and not. The only one I don't have is 7x30, as I said in prior emails. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 31, 2013 at 5:07 AM, Daniel Walker <dwalker@fifo99.com> wrote: > On Wed, Oct 30, 2013 at 10:19:30PM -0700, Olof Johansson wrote: >> On Wed, Oct 30, 2013 at 7:45 PM, Daniel Walker <dwalker@fifo99.com> wrote: >> > On Wed, Oct 30, 2013 at 05:36:58PM -0700, Olof Johansson wrote: >> >> On Wed, Oct 30, 2013 at 4:25 PM, Daniel Walker <dwalker@fifo99.com> wrote: >> >> >> >> > So the current users of those platforms are, what SOL ? >> >> >> >> What users? Show me one. >> > >> > What am I chop liver ? >> >> Ah, right. So, what platforms do you currently rely on mainline >> support for? Please be precise so we can figure out what needs to be >> kept and not. > > The only one I don't have is 7x30, as I said in prior emails. That's not actually what I asked. Which ones of them do you rely on mainline support for? -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 31, 2013 at 08:53:58AM -0700, Olof Johansson wrote: > On Thu, Oct 31, 2013 at 5:07 AM, Daniel Walker <dwalker@fifo99.com> wrote: > > On Wed, Oct 30, 2013 at 10:19:30PM -0700, Olof Johansson wrote: > >> On Wed, Oct 30, 2013 at 7:45 PM, Daniel Walker <dwalker@fifo99.com> wrote: > >> > On Wed, Oct 30, 2013 at 05:36:58PM -0700, Olof Johansson wrote: > >> >> On Wed, Oct 30, 2013 at 4:25 PM, Daniel Walker <dwalker@fifo99.com> wrote: > >> >> > >> >> > So the current users of those platforms are, what SOL ? > >> >> > >> >> What users? Show me one. > >> > > >> > What am I chop liver ? > >> > >> Ah, right. So, what platforms do you currently rely on mainline > >> support for? Please be precise so we can figure out what needs to be > >> kept and not. > > > > The only one I don't have is 7x30, as I said in prior emails. > > That's not actually what I asked. Which ones of them do you rely on > mainline support for? I rely on mainline support for 8x50 and G1 trout. This is starting to feel like an interogation .. The only reason I'm tolerating this is because I know you'll make some attempt to accept these patches over my already explicit objections. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Daniel Walker <dwalker@fifo99.com> writes: > On Wed, Oct 30, 2013 at 04:08:27PM -0700, Kevin Hilman wrote: >> Olof Johansson <olof@lixom.net> writes: >> >> > I would be very happy to take more code for the older Qualcomm chipset >> > to enable full functionality for them, but it's been my impression >> > that far from all that is needed to make it a useful platform is in >> > the upstream kernel, and there's been no signs of more of it showing >> > up at least in the last two years. >> > >> > So we have a bit of a stalemate here -- the current Qualcomm team >> > wants to avoid having to deal too much with the legacy platforms -- >> > they are technically quite different from the current platforms and >> > the divergence makes it hard to deal with supporting it all in a >> > modern way without risking regressions. I tend to agree with them. >> >> As do I. >> >> > Just like omap split between omap1 and omap2plus, I think it's a time >> > to create a mach-qcom instead, and move the modern (v7, most likely) >> > platforms there -- enable them with device tree, modern framework >> > infrastructure, etc. That way you can keep older platforms in mach-msm >> > without risk of regressions, and they have a clean base to start on >> > with their later platforms. >> >> I think this split approach is a good compromise. >> >> If the maintainers of the current older platforms wish to bring them up >> to modern frameworks, we can consider combining again. If not, they the >> older platforms will take the same path as the rest of the older >> platforms that slowly fade away. >> > > So the current users of those platforms are, what SOL ? No. The idea behind splitting them is to allow current platforms with active maintainers to progress without being held back. The older platforms can stay and have an opportunity to modernize. The kernel is a moving target, without some minimal effort to keep platforms up to date, the effort to continue to maintain/modernize them can become more of a pain than it's worth. If maintainers of these older platforms are willing to put in the work, nobody will be SOL. If nobody shows interest in modernizing these older platforms (which seems to be the case based on the last couple years), then it is reasonable IMO for them to fade away slowly. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 31, 2013 at 10:12:03AM -0700, Kevin Hilman wrote: > Daniel Walker <dwalker@fifo99.com> writes: > > > No. The idea behind splitting them is to allow current platforms with > active maintainers to progress without being held back. The older > platforms can stay and have an opportunity to modernize. > > The kernel is a moving target, without some minimal effort to keep > platforms up to date, the effort to continue to maintain/modernize them > can become more of a pain than it's worth. If maintainers of these older > platforms are willing to put in the work, nobody will be SOL. If > nobody shows interest in modernizing these older platforms (which seems > to be the case based on the last couple years), then it is reasonable > IMO for them to fade away slowly. According to a prior email Tony suggested that OMAP was split for purely technical reasons.. If code is shared in some way , or has synergies, and there's no technical reason to split a sub-architecture, then to me there's no win in splitting things.. It's just more directories, more confusion etc.. The confusion would come from someone wanting to find the code related to a platform, but woops there's a bunch of directories, or code flow and how the sub-architecture is strung together .. Personally I found OMAP very confusing in that regard. ARM and the sub-architectures is already confusing I don't think we need to start compounding the problem by allowing random whatever-you-want sub-directories from every sub-architecture. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Daniel Walker <dwalker@fifo99.com> writes: > On Thu, Oct 31, 2013 at 10:12:03AM -0700, Kevin Hilman wrote: >> Daniel Walker <dwalker@fifo99.com> writes: >> >> >> No. The idea behind splitting them is to allow current platforms with >> active maintainers to progress without being held back. The older >> platforms can stay and have an opportunity to modernize. >> >> The kernel is a moving target, without some minimal effort to keep >> platforms up to date, the effort to continue to maintain/modernize them >> can become more of a pain than it's worth. If maintainers of these older >> platforms are willing to put in the work, nobody will be SOL. If >> nobody shows interest in modernizing these older platforms (which seems >> to be the case based on the last couple years), then it is reasonable >> IMO for them to fade away slowly. > > > According to a prior email Tony suggested that OMAP was split for purely > technical reasons.. If code is shared in some way , or has synergies, and there's no > technical reason to split a sub-architecture, then to me there's no win in splitting > things.. The wins have already been well described in this thread in terms of maintenance of newer platforms using modern kernel infrastructure. > It's just more directories, more confusion etc.. The confusion > would come from someone wanting to find the code related to a platform, > but woops there's a bunch of directories, or code flow and how the > sub-architecture is strung together .. Personally I found OMAP very > confusing in that regard. > > ARM and the sub-architectures is already confusing I don't think we need > to start compounding the problem by allowing random whatever-you-want > sub-directories from every sub-architecture. Randomness is quite a bit of an exaggeration of what's been proposed here. These decisions are made on a case-by-case basis and is this case is being done for ease of maintainence for newer platforms, which may not be a "technical reason" for you, but is important for overall maintenance of arm-soc. If we do this split, you are more than welcome to demonstrate the commonality by modernizing mach-msm, combining it with mach-qcom, removing mach-msm, and then removing all the "confusion." Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 31, 2013 at 10:35:06AM -0700, Daniel Walker wrote: > ARM and the sub-architectures is already confusing I don't think we need > to start compounding the problem by allowing random whatever-you-want > sub-directories from every sub-architecture. Confusing? I'm not sure about that. It's actually really simple from my perspective: arch/arm - the ARM 32-bit architecture arch/arm/mach-* - support for a single SoC or a group of similar SoCs arch/arm/plat-* - common support for a set of dissimilar SoCs which want to share code between themselves How is that confusing? -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 31, 2013 at 11:51:34AM -0700, Kevin Hilman wrote: > Daniel Walker <dwalker@fifo99.com> writes: > > > On Thu, Oct 31, 2013 at 10:12:03AM -0700, Kevin Hilman wrote: > >> Daniel Walker <dwalker@fifo99.com> writes: > >> > >> > >> No. The idea behind splitting them is to allow current platforms with > >> active maintainers to progress without being held back. The older > >> platforms can stay and have an opportunity to modernize. > >> > >> The kernel is a moving target, without some minimal effort to keep > >> platforms up to date, the effort to continue to maintain/modernize them > >> can become more of a pain than it's worth. If maintainers of these older > >> platforms are willing to put in the work, nobody will be SOL. If > >> nobody shows interest in modernizing these older platforms (which seems > >> to be the case based on the last couple years), then it is reasonable > >> IMO for them to fade away slowly. > > > > > > According to a prior email Tony suggested that OMAP was split for purely > > technical reasons.. If code is shared in some way , or has synergies, and there's no > > technical reason to split a sub-architecture, then to me there's no win in splitting > > things.. > > The wins have already been well described in this thread in terms of > maintenance of newer platforms using modern kernel infrastructure. That's not very concrete .. Can you be specific, and what platforms are we talking about? > > It's just more directories, more confusion etc.. The confusion > > would come from someone wanting to find the code related to a platform, > > but woops there's a bunch of directories, or code flow and how the > > sub-architecture is strung together .. Personally I found OMAP very > > confusing in that regard. > > > > ARM and the sub-architectures is already confusing I don't think we need > > to start compounding the problem by allowing random whatever-you-want > > sub-directories from every sub-architecture. > > Randomness is quite a bit of an exaggeration of what's been proposed > here. No one has proposed anything, as far as I can tell. > These decisions are made on a case-by-case basis and is this case is > being done for ease of maintainence for newer platforms, which may not > be a "technical reason" for you, but is important for overall > maintenance of arm-soc. Who's making this decision ? If there's some reason why maintenance is easier , can you explain it ? That's typically how we make decisions in this community there needs to be a clear reason to do something. > If we do this split, you are more than welcome to demonstrate the > commonality by modernizing mach-msm, combining it with mach-qcom, > removing mach-msm, and then removing all the "confusion." Thanks, why not get it right the first time.. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 31, 2013 at 07:23:30PM +0000, Russell King - ARM Linux wrote: > On Thu, Oct 31, 2013 at 10:35:06AM -0700, Daniel Walker wrote: > > ARM and the sub-architectures is already confusing I don't think we need > > to start compounding the problem by allowing random whatever-you-want > > sub-directories from every sub-architecture. > > Confusing? > > I'm not sure about that. It's actually really simple from my perspective: > > arch/arm - the ARM 32-bit architecture > > arch/arm/mach-* - support for a single SoC or a group of similar SoCs > > arch/arm/plat-* - common support for a set of dissimilar SoCs which want > to share code between themselves > > How is that confusing? > It's the relationship between the arch/arm/mach-* and the arch/arm/plat-* and which ones connect with each other etc, and how the connection was actually done.. For me as a developer I found it confusing vs something that was fully integrated. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index 2586c28..d43d20c 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig @@ -5,19 +5,9 @@ comment "Qualcomm MSM SoC Type" choice prompt "Qualcomm MSM SoC Type" - default ARCH_MSM7X00A + default ARCH_MSM7X30 depends on !ARCH_MSM_DT -config ARCH_MSM7X00A - bool "MSM7x00A / MSM7x01A" - select ARCH_MSM_ARM11 - select CPU_V6 - select GPIO_MSM_V1 - select MACH_TROUT if !MACH_HALIBUT - select MSM_PROC_COMM - select MSM_SMD - select MSM_SMD_PKG3 - config ARCH_MSM7X30 bool "MSM7x30" select ARCH_MSM_SCORPION @@ -70,9 +60,6 @@ config MSM_HAS_DEBUG_UART_HS config MSM_SOC_REV_A bool -config ARCH_MSM_ARM11 - bool - config ARCH_MSM_SCORPION bool @@ -82,20 +69,6 @@ config MSM_VIC menu "Qualcomm MSM Board Type" depends on !ARCH_MSM_DT -config MACH_HALIBUT - depends on ARCH_MSM - depends on ARCH_MSM7X00A - bool "Halibut Board (QCT SURF7201A)" - help - Support for the Qualcomm SURF7201A eval board. - -config MACH_TROUT - depends on ARCH_MSM - depends on ARCH_MSM7X00A - bool "HTC Dream (aka trout)" - help - Support for the HTC Dream, T-Mobile G1, Android ADP1 devices. - config MACH_MSM7X30_SURF depends on ARCH_MSM7X30 bool "MSM7x30 SURF" @@ -117,9 +90,6 @@ config MACH_QSD8X50A_ST1_5 endmenu -config MSM_SMD_PKG3 - bool - config MSM_PROC_COMM bool diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile index 7ed4c1b..c7a5b53 100644 --- a/arch/arm/mach-msm/Makefile +++ b/arch/arm/mach-msm/Makefile @@ -3,7 +3,6 @@ obj-y += clock.o obj-$(CONFIG_MSM_VIC) += irq-vic.o -obj-$(CONFIG_ARCH_MSM7X00A) += irq.o obj-$(CONFIG_ARCH_QSD8X50) += sirc.o obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o @@ -21,9 +20,6 @@ CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1) obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o obj-$(CONFIG_SMP) += headsmp.o platsmp.o -obj-$(CONFIG_MACH_TROUT) += board-trout.o board-trout-gpio.o board-trout-mmc.o devices-msm7x00.o -obj-$(CONFIG_MACH_TROUT) += board-trout.o board-trout-gpio.o board-trout-mmc.o board-trout-panel.o devices-msm7x00.o -obj-$(CONFIG_MACH_HALIBUT) += board-halibut.o devices-msm7x00.o obj-$(CONFIG_ARCH_MSM7X30) += board-msm7x30.o devices-msm7x30.o obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o devices-qsd8x50.o obj-$(CONFIG_ARCH_MSM_DT) += board-dt.o
Support for the MSM7x00 SoCs was added starting in 2008 based on code from Google's Android kernels. Platform support is fairly minimal, and there have primarily been trivial and cleanup changes to this code. This code has not been converted to device tree, and is hindering supporting multi-platform on ARM. If someone wishes to continue support for this target, patches that provide devicetree and multi-platform support can start by re-adding these files. Signed-off-by: David Brown <davidb@codeaurora.org> --- Note that this patch was made with -D. I can send the full patch on request, and have also made the tree available at: git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git for-3.14/big-cleanup arch/arm/mach-msm/Kconfig | 32 +- arch/arm/mach-msm/Makefile | 4 - arch/arm/mach-msm/board-halibut.c | 110 ------ arch/arm/mach-msm/board-trout-gpio.c | 233 ------------ arch/arm/mach-msm/board-trout-mmc.c | 185 --------- arch/arm/mach-msm/board-trout-panel.c | 292 -------------- arch/arm/mach-msm/board-trout.c | 113 ------ arch/arm/mach-msm/board-trout.h | 162 -------- arch/arm/mach-msm/devices-msm7x00.c | 480 ------------------------ arch/arm/mach-msm/include/mach/irqs-7x00.h | 75 ---- arch/arm/mach-msm/include/mach/msm_iomap-7x00.h | 108 ------ arch/arm/mach-msm/irq.c | 151 -------- 12 files changed, 1 insertion(+), 1944 deletions(-) delete mode 100644 arch/arm/mach-msm/board-halibut.c delete mode 100644 arch/arm/mach-msm/board-trout-gpio.c delete mode 100644 arch/arm/mach-msm/board-trout-mmc.c delete mode 100644 arch/arm/mach-msm/board-trout-panel.c delete mode 100644 arch/arm/mach-msm/board-trout.c delete mode 100644 arch/arm/mach-msm/board-trout.h delete mode 100644 arch/arm/mach-msm/devices-msm7x00.c delete mode 100644 arch/arm/mach-msm/include/mach/irqs-7x00.h delete mode 100644 arch/arm/mach-msm/include/mach/msm_iomap-7x00.h delete mode 100644 arch/arm/mach-msm/irq.c diff --git a/arch/arm/mach-msm/board-halibut.c b/arch/arm/mach-msm/board-halibut.c deleted file mode 100644 index a775298..0000000 diff --git a/arch/arm/mach-msm/board-trout-gpio.c b/arch/arm/mach-msm/board-trout-gpio.c deleted file mode 100644 index 87e1d01..0000000 diff --git a/arch/arm/mach-msm/board-trout-mmc.c b/arch/arm/mach-msm/board-trout-mmc.c deleted file mode 100644 index 3723e55..0000000 diff --git a/arch/arm/mach-msm/board-trout-panel.c b/arch/arm/mach-msm/board-trout-panel.c deleted file mode 100644 index 77b0a26..0000000 diff --git a/arch/arm/mach-msm/board-trout.c b/arch/arm/mach-msm/board-trout.c deleted file mode 100644 index ccf6621..0000000 diff --git a/arch/arm/mach-msm/board-trout.h b/arch/arm/mach-msm/board-trout.h deleted file mode 100644 index b2379ed..0000000 diff --git a/arch/arm/mach-msm/devices-msm7x00.c b/arch/arm/mach-msm/devices-msm7x00.c deleted file mode 100644 index d83404d..0000000 diff --git a/arch/arm/mach-msm/include/mach/irqs-7x00.h b/arch/arm/mach-msm/include/mach/irqs-7x00.h deleted file mode 100644 index f1fe706..0000000 diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-7x00.h b/arch/arm/mach-msm/include/mach/msm_iomap-7x00.h deleted file mode 100644 index 67dc0e9..0000000 diff --git a/arch/arm/mach-msm/irq.c b/arch/arm/mach-msm/irq.c deleted file mode 100644 index ea514be..0000000