the future of qualcomm SoC in linux
David, Bryan, In general this community wants all code maintained. Your intentions seem to be that you want to push code, but you want to orphan it fairly quickly after you push the code. I know this is true having worked with both of you and many of your developers, and recent events seem to prove it. It's fine if you don't want to maintain the code you push, but it's better for us as a community if some one does maintains the code long term (10-15 years). Linux also fosters community development so that people with devices can submit patches or add extensions to existing code. It's my believe that you don't want that, and have no intentions of supporting it for any of your platforms or for any device that is created with your chips. Since both of you seem un-willing to do these things, I suggesting this compromise. I maintain the code long term for all Qualcomm platforms new and old, you submit patches to me. If you don't want me to do this, or don't trust me to do it, that's fine too just find someone else willing to maintain all the code long term. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: msm: Remove 7x00 support
On Thu, Oct 31, 2013 at 07:23:30PM +, 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: msm: Remove 7x00 support
On Thu, Oct 31, 2013 at 11:51:34AM -0700, Kevin Hilman wrote: > Daniel Walker writes: > > > On Thu, Oct 31, 2013 at 10:12:03AM -0700, Kevin Hilman wrote: > >> Daniel Walker 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: msm: Remove 7x00 support
On Thu, Oct 31, 2013 at 10:12:03AM -0700, Kevin Hilman wrote: > Daniel Walker 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: msm: Remove 7x00 support
On Thu, Oct 31, 2013 at 08:53:58AM -0700, Olof Johansson wrote: > On Thu, Oct 31, 2013 at 5:07 AM, Daniel Walker 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 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 > >> >> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: msm: Remove 7x00 support
On Wed, Oct 30, 2013 at 10:19:30PM -0700, Olof Johansson wrote: > On Wed, Oct 30, 2013 at 7:45 PM, Daniel Walker 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 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: msm: Remove 7x00 support
On Wed, Oct 30, 2013 at 05:36:58PM -0700, Olof Johansson wrote: > On Wed, Oct 30, 2013 at 4:25 PM, Daniel Walker 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: msm: Remove 7x00 support
On Wed, Oct 30, 2013 at 04:08:27PM -0700, Kevin Hilman wrote: > Olof Johansson 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: msm: Remove 8x50 support
On Wed, Oct 30, 2013 at 02:30:23PM +0100, Arnd Bergmann wrote: > On Tuesday 29 October 2013, Daniel Walker wrote: > > Isn't this the Nexus one platform ? Same as the last one , why don't you > > just update it to use the device tree? This doesn't seem like it would > > be all that difficult. > > Please don't top-post. Seriously ? I was responding to the whole comment, don't be so pedantic .. > > > On Mon, Oct 28, 2013 at 01:43:26PM -0700, David Brown wrote: > > > > > > This code has not been converted to device tree, and is hindering > > > support for the multi-platform kernel 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. > > ^ Here is your answer. > > > While I'd definitely love to see support for the Nexus One upstream, > it is evident that nobody has been working on this for a long time. I have a device with this chip in it .. I would like that device not to disappear from Linux .. Doing this puts an un-do burden on users who would like to see this support go in, but if it's removed like this that will never happen. No one has an much information on these chips as Qualcomm .. It's not realistic that any user would be able to do a lot without their support.. By allowing them to remove code for these device it effectively ends and chance of them have more code support added.. Yet the devices exist in mass amounts. To be honest your not an MSM maintainer, are there are political issue related to this.. This isn't particularly technical because converting these relatively simple platform to the device tree shouldn't be all that difficult. To me Your involvement is puzzling .. Myself and my co-maintainers need to be the ones discussing this.. G1 code is also getting removed in this series, and the code for this creates a usable device .. The problem here is that you really can't start randomly removing support for platforms that people have and want them to continue working. We have a process for that, and typically user objections weight heavily in that process (read, feature-removal-schedule.txt) Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: msm: Remove 8x50 support
Isn't this the Nexus one platform ? Same as the last one , why don't you just update it to use the device tree? This doesn't seem like it would be all that difficult. On Mon, Oct 28, 2013 at 01:43:26PM -0700, David Brown wrote: > The MSM8x50 SoC support was added in 2010 based on code from Google's > Android kernels. Platform support is fairly minimal, and the only > changes that have been made have been trivial and cleanup changes. > > This code has not been converted to device tree, and is hindering > support for the multi-platform kernel 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 > --- > 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 | 57 -- > arch/arm/mach-msm/Makefile | 14 - > arch/arm/mach-msm/board-qsd8x50.c | 213 - > arch/arm/mach-msm/clock-pcom.c | 177 > arch/arm/mach-msm/clock-pcom.h | 145 > arch/arm/mach-msm/devices-qsd8x50.c | 388 - > arch/arm/mach-msm/devices.h | 53 -- > arch/arm/mach-msm/dma.c | 295 --- > arch/arm/mach-msm/gpiomux-8x50.c| 51 -- > arch/arm/mach-msm/gpiomux-v1.h | 67 -- > arch/arm/mach-msm/gpiomux.c | 111 --- > arch/arm/mach-msm/gpiomux.h | 84 -- > arch/arm/mach-msm/include/mach/entry-macro.S| 36 - > arch/arm/mach-msm/include/mach/hardware.h | 18 - > arch/arm/mach-msm/include/mach/irqs-8x50.h | 88 -- > arch/arm/mach-msm/include/mach/irqs.h | 37 - > arch/arm/mach-msm/include/mach/msm_gpiomux.h| 38 - > arch/arm/mach-msm/include/mach/msm_iomap-8x50.h | 125 --- > arch/arm/mach-msm/include/mach/msm_iomap.h | 53 -- > arch/arm/mach-msm/include/mach/msm_smd.h| 109 --- > arch/arm/mach-msm/include/mach/sirc.h | 98 --- > arch/arm/mach-msm/include/mach/vreg.h | 29 - > arch/arm/mach-msm/io.c | 161 > arch/arm/mach-msm/irq-vic.c | 363 > arch/arm/mach-msm/last_radio_log.c | 71 -- > arch/arm/mach-msm/proc_comm.c | 129 --- > arch/arm/mach-msm/proc_comm.h | 258 -- > arch/arm/mach-msm/sirc.c| 172 > arch/arm/mach-msm/smd.c | 1035 > --- > arch/arm/mach-msm/smd_debug.c | 311 --- > arch/arm/mach-msm/smd_private.h | 403 - > arch/arm/mach-msm/vreg.c| 220 - > 32 files changed, 5409 deletions(-) > delete mode 100644 arch/arm/mach-msm/board-qsd8x50.c > delete mode 100644 arch/arm/mach-msm/clock-pcom.c > delete mode 100644 arch/arm/mach-msm/clock-pcom.h > delete mode 100644 arch/arm/mach-msm/devices-qsd8x50.c > delete mode 100644 arch/arm/mach-msm/devices.h > delete mode 100644 arch/arm/mach-msm/dma.c > delete mode 100644 arch/arm/mach-msm/gpiomux-8x50.c > delete mode 100644 arch/arm/mach-msm/gpiomux-v1.h > delete mode 100644 arch/arm/mach-msm/gpiomux.c > delete mode 100644 arch/arm/mach-msm/gpiomux.h > delete mode 100644 arch/arm/mach-msm/include/mach/entry-macro.S > delete mode 100644 arch/arm/mach-msm/include/mach/hardware.h > delete mode 100644 arch/arm/mach-msm/include/mach/irqs-8x50.h > delete mode 100644 arch/arm/mach-msm/include/mach/irqs.h > delete mode 100644 arch/arm/mach-msm/include/mach/msm_gpiomux.h > delete mode 100644 arch/arm/mach-msm/include/mach/msm_iomap-8x50.h > delete mode 100644 arch/arm/mach-msm/include/mach/msm_iomap.h > delete mode 100644 arch/arm/mach-msm/include/mach/msm_smd.h > delete mode 100644 arch/arm/mach-msm/include/mach/sirc.h > delete mode 100644 arch/arm/mach-msm/include/mach/vreg.h > delete mode 100644 arch/arm/mach-msm/io.c > delete mode 100644 arch/arm/mach-msm/irq-vic.c > delete mode 100644 arch/arm/mach-msm/last_radio_log.c > delete mode 100644 arch/arm/mach-msm/proc_comm.c > delete mode 100644 arch/arm/mach-msm/proc_comm.h > delete mode 100644 arch/arm/mach-msm/sirc.c > delete mode 100644 arch/arm/mach-msm/smd.c > delete mode 100644 arch/arm/mach-msm/smd_debug.c > delete mode 100644 arch/arm/mach-msm/smd_private.h > delete mode 100644 arch/arm/mach-msm/vreg.c > > diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig > index c9c113d..cb239ca 100644 > --- a/arch/arm/mach-msm/Kconfig > +++ b/arch/arm/mach-msm/Kconfig > @@ -3,24 +3,6 @@ if ARCH_MSM > comment "Qualcomm MSM SoC Type" > depends on ARCH_MSM_DT > > -choice > -
Re: [PATCH 3/4] ARM: msm: Remove 7x30 supporty
Why wouldn't you just update it to use the device tree ? There are lots of phones our there using 7x30 .. This is one that Qualcomm specifically upstreamed, so what was the point of upstreaming it ? On Mon, Oct 28, 2013 at 01:43:25PM -0700, David Brown wrote: > The MSM7x30 SoC support was added in 2009 based on code from Google's > Android kernels. Platform support is fairly minimal, and the only > changes that have been made have been trivial and cleanup changes. > > This code has not been converted to device tree, and is hindering > supporting multiple-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 > --- > 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 | 19 +- > arch/arm/mach-msm/Makefile | 2 - > arch/arm/mach-msm/board-msm7x30.c | 157 --- > arch/arm/mach-msm/devices-msm7x30.c | 246 > > arch/arm/mach-msm/include/mach/irqs-7x30.h | 153 --- > arch/arm/mach-msm/include/mach/msm_iomap-7x30.h | 103 -- > 6 files changed, 1 insertion(+), 679 deletions(-) > delete mode 100644 arch/arm/mach-msm/board-msm7x30.c > delete mode 100644 arch/arm/mach-msm/devices-msm7x30.c > delete mode 100644 arch/arm/mach-msm/include/mach/irqs-7x30.h > delete mode 100644 arch/arm/mach-msm/include/mach/msm_iomap-7x30.h > > diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig > index d43d20c..c9c113d 100644 > --- a/arch/arm/mach-msm/Kconfig > +++ b/arch/arm/mach-msm/Kconfig > @@ -5,20 +5,9 @@ comment "Qualcomm MSM SoC Type" > > choice > prompt "Qualcomm MSM SoC Type" > - default ARCH_MSM7X30 > + default ARCH_QSD8X50 > depends on !ARCH_MSM_DT > > -config ARCH_MSM7X30 > - bool "MSM7x30" > - select ARCH_MSM_SCORPION > - select CPU_V7 > - select GPIO_MSM_V1 > - select MACH_MSM7X30_SURF # if ! > - select MSM_GPIOMUX > - select MSM_PROC_COMM > - select MSM_SMD > - select MSM_VIC > - > config ARCH_QSD8X50 > bool "QSD8X50" > select ARCH_MSM_SCORPION > @@ -69,12 +58,6 @@ config MSM_VIC > menu "Qualcomm MSM Board Type" > depends on !ARCH_MSM_DT > > -config MACH_MSM7X30_SURF > - depends on ARCH_MSM7X30 > - bool "MSM7x30 SURF" > - help > - Support for the Qualcomm MSM7x30 SURF eval board. > - > config MACH_QSD8X50_SURF > depends on ARCH_QSD8X50 > bool "QSD8x50 SURF" > diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile > index c7a5b53..4bc7ee4 100644 > --- a/arch/arm/mach-msm/Makefile > +++ b/arch/arm/mach-msm/Makefile > @@ -8,7 +8,6 @@ obj-$(CONFIG_ARCH_QSD8X50) += sirc.o > obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o > > obj-$(CONFIG_ARCH_MSM7X00A) += dma.o io.o > -obj-$(CONFIG_ARCH_MSM7X30) += dma.o io.o > obj-$(CONFIG_ARCH_QSD8X50) += dma.o io.o > > obj-$(CONFIG_MSM_SMD) += smd.o smd_debug.o > @@ -20,7 +19,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_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 > obj-$(CONFIG_MSM_GPIOMUX) += gpiomux.o > diff --git a/arch/arm/mach-msm/board-msm7x30.c > b/arch/arm/mach-msm/board-msm7x30.c > deleted file mode 100644 > index f9af5a4..000 > diff --git a/arch/arm/mach-msm/devices-msm7x30.c > b/arch/arm/mach-msm/devices-msm7x30.c > deleted file mode 100644 > index c15ea8a..000 > diff --git a/arch/arm/mach-msm/include/mach/irqs-7x30.h > b/arch/arm/mach-msm/include/mach/irqs-7x30.h > deleted file mode 100644 > index 1f15902..000 > diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-7x30.h > b/arch/arm/mach-msm/include/mach/msm_iomap-7x30.h > deleted file mode 100644 > index 198202c..000 > -- > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: msm: Remove 7x00 support
On Tue, Oct 29, 2013 at 10:39:45AM -0700, Olof Johansson wrote: > On Tue, Oct 29, 2013 at 10:08 AM, Daniel Walker 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: msm: Remove 7x00 support
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: msm: Remove 7x00 support
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 > --- > 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
Re: [PATCH v2] arm: msm: fix up very basic HTC Sapphire support
What you did wasn't what I was suggesting you do...
Keep your pull request available as it originally was and ill comment on the
thread..
Daniel
David Brown wrote:
>On Fri, May 11, 2012 at 10:45:52PM -0700, Olof Johansson wrote:
>
>> Sorry, I should have found the below items on the first review and not
>> now on the second one, but see below.
>
>Daniel, I don't mind fixing up minor things, but can you take care of
>the other issues that Olof has brought up.
>
>Thanks,
>David
>
>> On Fri, May 11, 2012 at 5:15 PM, David Brown wrote:
>> > From: Daniel Walker
>> >
>> > Adds sapphire into the make file, and fixes all the code problems that
>> > prevented it from building (including adding board-sapphire.h)
>> >
>> > [dav...@codeaurora.org: Move MACH_TROUT selection back under
>> > ARCH_MSM7X00A]
>> >
>> > Signed-off-by: Daniel Walker
>> > Signed-off-by: David Brown
>> > ---
>> > v2 - Moved MACH_TROUT selection back under the ARCH config target
>> >
>> > arch/arm/mach-msm/Kconfig | 9 +-
>> > arch/arm/mach-msm/Makefile | 1 +
>> > arch/arm/mach-msm/board-sapphire.c | 18 +--
>> > arch/arm/mach-msm/board-sapphire.h | 224
>> >
>> > 4 files changed, 234 insertions(+), 18 deletions(-)
>> > create mode 100644 arch/arm/mach-msm/board-sapphire.h
>> >
>> > diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
>> > index 1cd40ad..70eae63 100644
>> > --- a/arch/arm/mach-msm/Kconfig
>> > +++ b/arch/arm/mach-msm/Kconfig
>> > @@ -6,7 +6,7 @@ choice
>> >
>> > config ARCH_MSM7X00A
>> > bool "MSM7x00A / MSM7x01A"
>> > - select MACH_TROUT if !MACH_HALIBUT
>> > + select MACH_TROUT if (!MACH_HALIBUT && !MACH_SAPPHIRE)
>>
>> Better, thanks!
>>
>>
>> > diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
>> > index 4ad3969..aff4e5c 100644
>> > --- a/arch/arm/mach-msm/Makefile
>> > +++ b/arch/arm/mach-msm/Makefile
>> > @@ -20,6 +20,7 @@ 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_SAPPHIRE) += board-sapphire.o devices-msm7x00.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
>>
>> Unrelated to this change per se, but it seems like devices-msm7x00.o
>> should be on an obj-$(CONFIG_ARCH_MSM7X00A) statement instead of
>> duplicated for all boards.
>>
>> Also, the trout line is mostly duplicated, only delta is panel. Looks
>> broken. Both of these things is material for a separate patch though.
>>
>> > diff --git a/arch/arm/mach-msm/board-sapphire.h
>> > b/arch/arm/mach-msm/board-sapphire.h
>> > new file mode 100644
>> > index 000..70f925e
>> > --- /dev/null
>> > +++ b/arch/arm/mach-msm/board-sapphire.h
>> > @@ -0,0 +1,224 @@
>> [..]
>> > +void config_sapphire_camera_on_gpios(void);
>> > +void config_sapphire_camera_off_gpios(void);
>> > +int sapphire_get_smi_size(void);
>> > +unsigned int sapphire_get_hwid(void);
>> > +unsigned int sapphire_get_skuid(void);
>> > +unsigned int is_12pin_camera(void);
>> > +int sapphire_is_5M_camera(void);
>> > +int sapphire_gpio_write(struct gpio_chip *chip, unsigned n, unsigned on);
>>
>> Many (all?) of these functions are not to be found in the code. Please
>> don't add prototypes for code that isn't there.
>>
>>
>> -Olof
>
>--
>Sent by an employee of the Qualcomm Innovation Center, Inc.
>The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>
N�r��yb�X��ǧv�^�){.n�+{�j���h����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf
Re: [PATCH] arm: msm: trout: fix compile failure
On Thu, Apr 12, 2012 at 08:45:37AM -0700, Daniel Walker wrote: > Fixes the following warnings, > > arch/arm/mach-msm/board-trout.c: In function 'trout_init': > arch/arm/mach-msm/board-trout.c:71: error: 'system_rev' undeclared (first use > in this function) > arch/arm/mach-msm/board-trout.c:71: error: (Each undeclared identifier is > reported only once > arch/arm/mach-msm/board-trout.c:71: error: for each function it appears in.) > > and > > arch/arm/mach-msm/board-trout-panel.c: In function 'trout_init_panel': > arch/arm/mach-msm/board-trout-panel.c:267: error: 'system_rev' undeclared > (first use in this function) > arch/arm/mach-msm/board-trout-panel.c:267: error: (Each undeclared identifier > is reported only once > arch/arm/mach-msm/board-trout-panel.c:267: error: for each function it > appears in.) > This needs to go upstream ASAP .. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: msm: trout: fix compile failure
Fixes the following warnings, arch/arm/mach-msm/board-trout.c: In function 'trout_init': arch/arm/mach-msm/board-trout.c:71: error: 'system_rev' undeclared (first use in this function) arch/arm/mach-msm/board-trout.c:71: error: (Each undeclared identifier is reported only once arch/arm/mach-msm/board-trout.c:71: error: for each function it appears in.) and arch/arm/mach-msm/board-trout-panel.c: In function 'trout_init_panel': arch/arm/mach-msm/board-trout-panel.c:267: error: 'system_rev' undeclared (first use in this function) arch/arm/mach-msm/board-trout-panel.c:267: error: (Each undeclared identifier is reported only once arch/arm/mach-msm/board-trout-panel.c:267: error: for each function it appears in.) This came in with the following commit 9f97da78bf018206fb623cd351d454af2f105fe0 which removes asm/system.h Signed-off-by: Daniel Walker cc: David Howells cc: Bryan Huntsman cc: linux-arm-msm@vger.kernel.org cc: linux-arm-ker...@lists.infradead.org --- arch/arm/mach-msm/board-trout-panel.c |1 + arch/arm/mach-msm/board-trout.c |1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm/mach-msm/board-trout-panel.c b/arch/arm/mach-msm/board-trout-panel.c index 25105c1..89bf6b4 100644 --- a/arch/arm/mach-msm/board-trout-panel.c +++ b/arch/arm/mach-msm/board-trout-panel.c @@ -12,6 +12,7 @@ #include #include +#include #include #include diff --git a/arch/arm/mach-msm/board-trout.c b/arch/arm/mach-msm/board-trout.c index 5414f76..d4060a3 100644 --- a/arch/arm/mach-msm/board-trout.c +++ b/arch/arm/mach-msm/board-trout.c @@ -19,6 +19,7 @@ #include #include +#include #include #include #include -- 1.7.10.130.g36e6c -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: msm: remove unused MSM boards
On Wed, Apr 11, 2012 at 11:04:09AM -0700, David Brown wrote: > On Wed, Apr 11, 2012 at 10:55:50AM -0700, Daniel Walker wrote: > > On Wed, Apr 11, 2012 at 10:37:50AM -0700, David Brown wrote: > > > The "mahimahi" and "sapphire" were never finished, and have never been > > > built. > > > > > > The "halibut" target was a dev board that hasn't ever been widely > > > available (MSM7201 "SURF"). > > > > I don't mind if you remove halibut, but the others are just incomplete > > phone support which someone may want to add to.. I'd prefer to fix those > > two.. > > Why, though? It's obvious that nobody is using them, since they've > never worked. https://lkml.org/lkml/2011/1/20/367 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: msm: remove unused MSM boards
On Wed, Apr 11, 2012 at 11:04:09AM -0700, David Brown wrote: > On Wed, Apr 11, 2012 at 10:55:50AM -0700, Daniel Walker wrote: > > On Wed, Apr 11, 2012 at 10:37:50AM -0700, David Brown wrote: > > > The "mahimahi" and "sapphire" were never finished, and have never been > > > built. > > > > > > The "halibut" target was a dev board that hasn't ever been widely > > > available (MSM7201 "SURF"). > > > > I don't mind if you remove halibut, but the others are just incomplete > > phone support which someone may want to add to.. I'd prefer to fix those > > two.. > > Why, though? It's obvious that nobody is using them, since they've > never worked. Didn't I submit patches to make mahimahi build, and boot? So someone has at least used mahimahi .. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU
On Wed, Apr 11, 2012 at 06:40:24PM +0100, Russell King - ARM Linux wrote: > On Wed, Apr 11, 2012 at 10:38:50AM -0700, Daniel Walker wrote: > > On Wed, Apr 11, 2012 at 05:27:30PM +0100, Russell King - ARM Linux wrote: > > > While here, I propose to delete these: > > > > > > arch/arm/mach-msm/board-mahimahi.c: mi->bank[0].start = PHYS_OFFSET; > > > arch/arm/mach-msm/board-mahimahi.c: mi->bank[0].node = > > > PHYS_TO_NID(PHYS_OFFSET); > > > arch/arm/mach-msm/board-mahimahi.c: mi->bank[0].size = > > > (219*1024*1024); > > > arch/arm/mach-msm/board-mahimahi.c: mi->bank[1].start = > > > MSM_HIGHMEM_BASE; > > > arch/arm/mach-msm/board-mahimahi.c: mi->bank[1].node = > > > PHYS_TO_NID(MSM_HIGHMEM_BASE); > > > arch/arm/mach-msm/board-mahimahi.c: mi->bank[1].size = > > > MSM_HIGHMEM_SIZE; > > > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].start = PHYS_OFFSET; > > > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].node = > > > PHYS_TO_NID(PHYS_OFFSET); > > > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].size = > > > (84*1024*1024); > > > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].size = > > > (101*1024*1024); > > > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].size = > > > (101*1024*1024); > > > > > > because they haven't been buildable since 7th May 2010 (that's 23 months > > > ago), and no one has reported any build errors with them. They're only > > > receiving updates from other sweeps and nothing more. This all means no > > > one is even attempting to build this code. It's pointless having > > > unbuildable code in the kernel, and it's nothing more than a useless > > > maintanence burden. > > > > > > It can't be that hard to fix.. I'll look into cleaning it up. > > What's the point of fixing code which isn't being used by anyone? As I > said above, it's a maintanence burden and if its not being used it needs > to be removed. > Aren't there whole are sub-architectures that don't even build ? I think something that's a work in progress is fine, as long as someone (i.e. me) plans to get back to it at some point. I also said that _I_ would make it build .. So someone is going to use it, and it is going to build. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: msm: remove unused MSM boards
On Wed, Apr 11, 2012 at 10:37:50AM -0700, David Brown wrote: > The "mahimahi" and "sapphire" were never finished, and have never been > built. > > The "halibut" target was a dev board that hasn't ever been widely > available (MSM7201 "SURF"). I don't mind if you remove halibut, but the others are just incomplete phone support which someone may want to add to.. I'd prefer to fix those two.. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU
On Wed, Apr 11, 2012 at 05:27:30PM +0100, Russell King - ARM Linux wrote: > Of course, what prevents us doing that conversion sanely is all the > shite platform code doing crap stuff like this: > > arch/arm/mach-msm/board-halibut.c: mi->bank[0].start = PHYS_OFFSET; > arch/arm/mach-msm/board-halibut.c: mi->bank[0].size = (101*1024*1024); > > which I went through everything a few years ago and eliminated all this > crap. It's back now. Sod it, we'll stick with the current 4GiB limited > way as long as we have platform maintainers who do this kind of crappy > hack. > > While here, I propose to delete these: > > arch/arm/mach-msm/board-mahimahi.c: mi->bank[0].start = PHYS_OFFSET; > arch/arm/mach-msm/board-mahimahi.c: mi->bank[0].node = > PHYS_TO_NID(PHYS_OFFSET); > arch/arm/mach-msm/board-mahimahi.c: mi->bank[0].size = (219*1024*1024); > arch/arm/mach-msm/board-mahimahi.c: mi->bank[1].start = MSM_HIGHMEM_BASE; > arch/arm/mach-msm/board-mahimahi.c: mi->bank[1].node = > PHYS_TO_NID(MSM_HIGHMEM_BASE); > arch/arm/mach-msm/board-mahimahi.c: mi->bank[1].size = MSM_HIGHMEM_SIZE; > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].start = PHYS_OFFSET; > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].node = > PHYS_TO_NID(PHYS_OFFSET); > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].size = > (84*1024*1024); > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].size = > (101*1024*1024); > arch/arm/mach-msm/board-sapphire.c: mi->bank[0].size = > (101*1024*1024); > > because they haven't been buildable since 7th May 2010 (that's 23 months > ago), and no one has reported any build errors with them. They're only > receiving updates from other sweeps and nothing more. This all means no > one is even attempting to build this code. It's pointless having > unbuildable code in the kernel, and it's nothing more than a useless > maintanence burden. It can't be that hard to fix.. I'll look into cleaning it up. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] DMAEngine: Add DMAEngine driver based on old MSM DMA APIs
On Tue, Mar 13, 2012 at 06:16:39PM +0530, Ravi Kumar V wrote: > On 3/13/2012 1:44 AM, Daniel Walker wrote: > >On Mon, Mar 12, 2012 at 04:02:44PM +0530, Ravi Kumar V wrote: > >>Add DMAEngine based driver using the old MSM DMA APIs internally. > > > >What do you mean by this? > > > There is a MSM DMA driver in arch/arm/mach-msm/ which is not in > dmaengine framework standards, but that driver is been used by > client drivers nand, eMMC and serial drivers. Now if we implement > the whole dma driver using dmaengine framework then nand, eMMC like > drivers will be failed as they are using old dma driver API's, so > instead of implementing new driver from scratch we are keeping the > old dma API's as it is and using those API's in new dmaengine > framework.So that we can convert clients drivers to use dma engine > framework. Did you investigate converting the drivers (nand, eMMC, serial) ? It seems like there would be a 1:1 mapping between the API's , so it might only be a find->replace operation. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] DMAEngine: Add DMAEngine driver based on old MSM DMA APIs
On Mon, Mar 12, 2012 at 04:02:44PM +0530, Ravi Kumar V wrote: > Add DMAEngine based driver using the old MSM DMA APIs internally. What do you mean by this? > The benefit of this approach is that not all the drivers > have to get converted to DMAEngine APIs simultaneosly while > both the drivers can stay enabled in the kernel. The client > drivers using the old MSM APIs directly can now convert to > DMAEngine one by one. Which drivers? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] msm: DMAEngine: Add DMAEngine driver based on old MSM DMA APIs
On Sat, 2012-01-07 at 19:21 +, Russell King - ARM Linux wrote:
> On Sat, Jan 07, 2012 at 10:54:43AM -0800, David Brown wrote:
> > On Fri, Jan 06, 2012 at 05:59:29PM -0800, Daniel Walker wrote:
> >
> > > > diff --git a/drivers/dma/msm-dma.c b/drivers/dma/msm-dma.c
> > > > new file mode 100644
> > > > index 000..51d9a2b
> > > > --- /dev/null
> > > > +++ b/drivers/dma/msm-dma.c
> > > > ...
> > > > +static void msm_chan_desc_cleanup(struct msm_dma_chan *chan)
> > > > +{
> > > > + struct msm_dma_desc_sw *desc, *_desc;
> > > > + unsigned long flags;
> > > > +
> > > > + dev_dbg(chan->dev, "Cleaning completed descriptor of channel
> > > > %d\n",
> > > > + chan->chan_id);
> > > > + spin_lock_irqsave(&chan->lock, flags);
> > > > +
> > > > + list_for_each_entry_safe(desc, _desc, &chan->active_list, node)
> > > > {
> > > > + dma_async_tx_callback callback;
> > > > + void *callback_param;
> > > > +
> > > > + if (msm_dma_desc_status(chan, desc) == DMA_IN_PROGRESS)
> > > > + break;
> > > > +
> > > > + /* Remove from the list of running transactions */
> > > > + list_del(&desc->node);
> > > > +
> > > > + /* Run the link descriptor callback function */
> > > > + callback = desc->async_tx.callback;
> > > > + callback_param = desc->async_tx.callback_param;
> > > > + if (callback) {
> > > > + spin_unlock_irqrestore(&chan->lock, flags);
> > > > + callback(callback_param);
> > >
> > > Are you sure unlocking here is safe? at_hdmac.c holds the lock the
> > > entire time, and fsldma.c deletes the entire list, then runs the
> > > operations.
> >
> > Good catch.
> >
> > According to a comment in at_hdmac.c, it is safe to hold the lock
> > while calling the callbacks, so that's probably the easiest solution.
> > I suspect that you've got something in another driver expecting the
> > lock to be released, and that might have to be changed.
>
> It is _not_ safe to hold the lock while calling callbacks.
>
> Please refer to the DMA engine documentation, found here:
>
> Documentation/dmaengine.txt
>
> section 3:
>
>Note:
> Although the async_tx API specifies that completion callback
> routines cannot submit any new operations, this is not the
> case for slave/cyclic DMA.
>
> For slave DMA, the subsequent transaction may not be available
> for submission prior to callback function being invoked, so
> slave DMA callbacks are permitted to prepare and submit a new
> transaction.
>
> For cyclic DMA, a callback function may wish to terminate the
> DMA via dmaengine_terminate_all().
>
> * Therefore, it is important that DMA engine drivers drop any
> * locks before calling the callback function which may cause a
> * deadlock.
Here's the comment from at_hdmac.c .
/*
* The API requires that no submissions are done from a
* callback, so we don't need to drop the lock here
*/
if (callback)
callback(param);
I don't know much about the DMA engine, but maybe there is some special
case here that makes this ok.. (CC'ed Nicolas Ferre)
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] msm: DMAEngine: Add DMAEngine driver based on old MSM DMA APIs
On Fri, 2012-01-06 at 18:17 +0530, Ravi Kumar V wrote:
> Add DMAEngine based driver using the old MSM DMA APIs internally.
> The benefit of this approach is that not all the drivers
> have to get converted to DMAEngine APIs simultaneosly while
> both the drivers can stay enabled in the kernel. The client
> drivers using the old MSM APIs directly can now convert to
> DMAEngine one by one.
>
> Change-Id: I3647ed7b8c73b3078dfa8877a3560db3cb0a2373
> Signed-off-by: Ravi Kumar V
> ---
> arch/arm/mach-msm/include/mach/dma.h | 33 ++
> drivers/dma/Kconfig | 12 +
> drivers/dma/Makefile |1 +
> drivers/dma/msm-dma.c| 764
> ++
> 4 files changed, 810 insertions(+), 0 deletions(-)
> create mode 100644 drivers/dma/msm-dma.c
>
> diff --git a/arch/arm/mach-msm/include/mach/dma.h
> b/arch/arm/mach-msm/include/mach/dma.h
> index 05583f5..34f4dac 100644
> --- a/arch/arm/mach-msm/include/mach/dma.h
> +++ b/arch/arm/mach-msm/include/mach/dma.h
> @@ -18,6 +18,39 @@
> #include
> #include
>
> +#define msm_dma_set_crci(sg, crci) (((sg)->private_data) = \
> + (((sg)->private_data) & ~(0x7F8)) | \
> + crci)
> +#define msm_dma_set_endian(sg, en) (((sg)->private_data) = \
> + (((sg)->private_data) & ~(0x1F800)) | \
> + en)
> +#define msm_dma_set_tcb(sg, tcb) (((sg)->private_data) = \
> + (((sg)->private_data) & ~(0x8)) | \
> + tcb)
> +#define sg_dma_offset(sg) ((sg)->offset)
> +#define sg_dma_private_data(sg) ((sg)->private_data)
> +#define box_dma_row_address(box)((box)->dma_row_address)
> +#define box_dma_row_len(box)((box)->dma_row_len)
> +#define box_dma_row_num(box)((box)->dma_row_num)
> +#define box_dma_row_offset(box) ((box)->dma_row_offset)
> +#define box_dma_private_data(box) ((box)->private_data)
> +
> +#define MSM_DMA_CMD_MASK 0x9FFF8
> +#define MSM_DMA_CMD_SHIFT0
> +#define MSM_BOX_SRC_RLEN_MASK0x
> +#define MSM_BOX_SRC_RLEN_SHIFT 16
> +#define MSM_BOX_SRC_RNUM_MASK0x
> +#define MSM_BOX_SRC_RNUM_SHIFT 16
> +#define MSM_BOX_SRC_ROFFSET_MASK 0x
> +#define MSM_BOX_SRC_ROFFSET_SHIFT16
> +#define MSM_BOX_DST_RLEN_MASK0x
> +#define MSM_BOX_DST_RNUM_MASK0x
> +#define MSM_BOX_DST_ROFFSET_MASK 0x
> +#define MSM_BOX_MODE_CMD 0x3
> +
> +#define FORCED_FLUSH 0
> +#define GRACEFUL_FLUSH 1
Could be an enum ..
> struct msm_dmov_errdata {
> uint32_t flush[6];
> };
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index ab8f469..3e69f42 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -245,6 +245,18 @@ config EP93XX_DMA
> help
> Enable support for the Cirrus Logic EP93xx M2P/M2M DMA controller.
>
> +config MSM_DMA
> + tristate "Qualcomm MSM DMA support"
> + depends on ARCH_MSM
> + select DMA_ENGINE
> + help
> + Support the Qualcomm DMA engine. This engine is integrated into
> + Qualcomm chips.
> +
> + Say Y here if you have such a chipset.
> +
> + If unsure, say N.
> +
> config DMA_ENGINE
> bool
>
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index 30cf3b1..56593f0 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
> obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
> obj-$(CONFIG_IMX_SDMA) += imx-sdma.o
> obj-$(CONFIG_IMX_DMA) += imx-dma.o
> +obj-$(CONFIG_MSM_DMA) += msm-dma.o
> obj-$(CONFIG_MXS_DMA) += mxs-dma.o
> obj-$(CONFIG_TIMB_DMA) += timb_dma.o
> obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
> diff --git a/drivers/dma/msm-dma.c b/drivers/dma/msm-dma.c
> new file mode 100644
> index 000..51d9a2b
> --- /dev/null
> +++ b/drivers/dma/msm-dma.c
> @@ -0,0 +1,764 @@
> +/* Copyright (c) 2011, Code Aurora Forum. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define SD3_CHAN_START 0
> +#define MSM_D
Re: [PATCH 1/3] ARM: msm: Remove MSM7x00 support
On Thu, 2011-12-01 at 21:03 +, Russell King - ARM Linux wrote: > On Thu, Dec 01, 2011 at 12:49:58PM -0800, Daniel Walker wrote: > > On Thu, 2011-12-01 at 20:35 +, Russell King - ARM Linux wrote: > > > On Thu, Dec 01, 2011 at 12:25:47PM -0800, Daniel Walker wrote: > > > > On Thu, 2011-12-01 at 20:19 +, Russell King - ARM Linux wrote: > > > > > Now, the obvious question to ask now is this: as you sent your > > > > > question, > > > > > and Daniel obviously objects, was Daniel one of your respondants? If > > > > > not, then he carries some of the blame for this patch being created > > > > > in the first place by having missed the email/not replied/etc. > > > > > > > > > > > > > What if the people using the hardware aren't even on the list ? It's not > > > > their fault is it? > > > > > > Did you notice I mentioned six months? > > > > Yeah I did notice.. > > > > > The way to remove non-broken code is: > > > 1. to ask. If no one responds, then > > > 2. submit a patch to put an entry in feature-removal-schedule.txt giving a > > >description of what will be removed and when - and then flag it > > >with a patch to remove it. If no one responds to that, then > > > 3. the patch to remove it re-posted, and if no one objects it gets > > >merged. > > > > > > So, if people care about bits of code _and_ they're not on the relevant > > > subsystem mailing lists, they need to keep an eye on the feature removal > > > file - otherwise they're in for nasty surprises. > > > > I agree with the steps, but I'm not sure David knows about (or would be > > following) those steps. Not to mention these devices are still readily > > available used .. I wouldn't expect anyone to even remotely ponder > > removing this code for at least another 10 years.. In order to even > > start the process above there has to be some good probability that no > > has the device or cares at all about the device.. > > Actually... no. We've removed entire SoCs which have lost their > maintainers well under this '10 years'. In this case we have a maintainer (3 of them even).. > One of the key decisions for removing code is the cost of keeping it > in a buildable state when there's no one actively looking after it. > If it has a high cost it'll get deleted much earlier... I'm not trying to suggest rules for the entire ARM architecture .. In this particular case it's totally uncalled for to even try to remove the code.. I don't know the details of the case which your bringing up, but it doesn't seem (from what you've said) similar to this one. These devices are widely available, lots of developers and non-developers have them, the devices are widely available for purchase (with kernels on them), we have maintainers for the area where the code lives.. In the case your bringing up I could argue with you, but I really don't know the circumstances.. To me I think it should be hard to remove code for devices you can easily get a hold of.. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: msm: Remove MSM7x00 support
On Thu, 2011-12-01 at 20:35 +, Russell King - ARM Linux wrote: > On Thu, Dec 01, 2011 at 12:25:47PM -0800, Daniel Walker wrote: > > On Thu, 2011-12-01 at 20:19 +, Russell King - ARM Linux wrote: > > > Now, the obvious question to ask now is this: as you sent your question, > > > and Daniel obviously objects, was Daniel one of your respondants? If > > > not, then he carries some of the blame for this patch being created > > > in the first place by having missed the email/not replied/etc. > > > > > > > What if the people using the hardware aren't even on the list ? It's not > > their fault is it? > > Did you notice I mentioned six months? Yeah I did notice.. > The way to remove non-broken code is: > 1. to ask. If no one responds, then > 2. submit a patch to put an entry in feature-removal-schedule.txt giving a >description of what will be removed and when - and then flag it >with a patch to remove it. If no one responds to that, then > 3. the patch to remove it re-posted, and if no one objects it gets >merged. > > So, if people care about bits of code _and_ they're not on the relevant > subsystem mailing lists, they need to keep an eye on the feature removal > file - otherwise they're in for nasty surprises. I agree with the steps, but I'm not sure David knows about (or would be following) those steps. Not to mention these devices are still readily available used .. I wouldn't expect anyone to even remotely ponder removing this code for at least another 10 years.. In order to even start the process above there has to be some good probability that no has the device or cares at all about the device.. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: msm: Remove MSM7x00 support
On Thu, 2011-12-01 at 12:26 -0800, David Brown wrote: > On Thu, Dec 01, 2011 at 08:19:50PM +, Russell King - ARM Linux wrote: > > On Thu, Dec 01, 2011 at 11:43:53AM -0800, David Brown wrote: > > > On Thu, Dec 01, 2011 at 11:33:12AM -0800, Daniel Walker wrote: > > > > On Thu, 2011-12-01 at 11:27 -0800, David Brown wrote: > > > > > On Thu, Dec 01, 2011 at 10:39:05AM -0800, Daniel Walker wrote: > > > > > > > > > > > > If someone is willing to step up and make it work, then we can > > > > > > > keep it > > > > > > > around. My only G1 is fried, so I have no way to do anything > > > > > > > other > > > > > > > than keep it compiling. > > > > > > > > > > > > Unfortunately, You can't remove it regardless of whether or not you > > > > > > have > > > > > > one to test on.. Your job is to do the best you can to keep it > > > > > > working > > > > > > and maintained. If you don't have one then you can't boot test but > > > > > > you > > > > > > still have to your best to keep it as close to working as possible. > > > > > > > > > > I was trying to get an idea if anyone uses the target. If people > > > > > want the target around, we can just ignore my patches to remove it. > > > > > > > > Please don't ever do this again. > > > > > > That's awfully harsh. I sent an email a few weeks back asking about > > > removing the target, and I only got one positive response. Sometimes > > > sending a patch is the best way to get a reaction. > > > > That's pretty normal for just 'asking' about doing something. > > > > You've done the right thing - if you ask, people treat your message as > > low priority and don't bother replying in the hope that nothing will > > happen. > > > > However, if you send a patch to delete a platform, people treat it as > > most urgent because if they care they need to speak up to actually stop > > it happening. (Even if you intend to only actually submit it in 6 > > months time or so - but don't mention that in the initial posting!) > > > > Now, the obvious question to ask now is this: as you sent your question, > > and Daniel obviously objects, was Daniel one of your respondants? If > > not, then he carries some of the blame for this patch being created > > in the first place by having missed the email/not replied/etc. > > Yeah, my mistake was forgetting to CC Daniel on the original question > about removing the target. > > And I've learned what I needed to now: someone does still care about > the target. I just went on cragslist and found 7 of these phones for sell used .. If you can still buy the things clearly we want it supported .. My point is that this patch and even you asking to remove the code was pointless.. You should know that code can't be removed. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: msm: Remove MSM7x00 support
On Thu, 2011-12-01 at 20:19 +, Russell King - ARM Linux wrote: > Now, the obvious question to ask now is this: as you sent your question, > and Daniel obviously objects, was Daniel one of your respondants? If > not, then he carries some of the blame for this patch being created > in the first place by having missed the email/not replied/etc. > What if the people using the hardware aren't even on the list ? It's not their fault is it? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: msm: Remove MSM7x00 support
On Thu, 2011-12-01 at 11:43 -0800, David Brown wrote: > On Thu, Dec 01, 2011 at 11:33:12AM -0800, Daniel Walker wrote: > > On Thu, 2011-12-01 at 11:27 -0800, David Brown wrote: > > > On Thu, Dec 01, 2011 at 10:39:05AM -0800, Daniel Walker wrote: > > > > > > > > If someone is willing to step up and make it work, then we can keep it > > > > > around. My only G1 is fried, so I have no way to do anything other > > > > > than keep it compiling. > > > > > > > > Unfortunately, You can't remove it regardless of whether or not you have > > > > one to test on.. Your job is to do the best you can to keep it working > > > > and maintained. If you don't have one then you can't boot test but you > > > > still have to your best to keep it as close to working as possible. > > > > > > I was trying to get an idea if anyone uses the target. If people > > > want the target around, we can just ignore my patches to remove it. > > > > Please don't ever do this again. > > That's awfully harsh. I sent an email a few weeks back asking about > removing the target, and I only got one positive response. Sometimes > sending a patch is the best way to get a reaction. You didn't CC me on that (or I didn't see it) .. You know who supports the G1 target and who has the target (i.e. me) .. It also goes against the philosophy of this community to arbitrarily remove hardware support. Am I trying to be harsh? No I'm not, but you really shouldn't be doing this kind of stuff. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: msm: Remove MSM7x00 support
On Thu, 2011-12-01 at 11:27 -0800, David Brown wrote: > On Thu, Dec 01, 2011 at 10:39:05AM -0800, Daniel Walker wrote: > > > > If someone is willing to step up and make it work, then we can keep it > > > around. My only G1 is fried, so I have no way to do anything other > > > than keep it compiling. > > > > Unfortunately, You can't remove it regardless of whether or not you have > > one to test on.. Your job is to do the best you can to keep it working > > and maintained. If you don't have one then you can't boot test but you > > still have to your best to keep it as close to working as possible. > > I was trying to get an idea if anyone uses the target. If people > want the target around, we can just ignore my patches to remove it. Please don't ever do this again. > Remember, though, it is a tradeoff. The msm7201 is fairly different > than the other MSM targets, and adds some effort to the consolidation > work across all of ARM. I think it would be better, overall, to drop > support for it, if there are no users. To me that would be a failure in design of the consolidation.. If we removed all the targets that are "different" we might not have many targets. > I'm pretty sure that the chips themselves are past end-of-life, so > there isn't going to be any new hardware based on the msm7201. There's still plenty of them floating around. > I'm curious what kinds of uses people have for their G1s. > > Speaking of old targets, it doesn't look like the mahimahi (Nexus One) > ever made it to the point of building. I have a dev board board on > the msm8650, and the chip support does work. It'd be nice to get > patches to get the Nexus One target to work as well. (the > board-mahimahi.c includes a board-mahimahi.h that isn't present). I'd love to have it working too. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: msm: Remove MSM7x00 support
On Thu, 2011-12-01 at 10:17 -0800, David Brown wrote: > On Thu, Dec 01, 2011 at 07:17:37AM -0800, Daniel Walker wrote: > > On Wed, 2011-11-30 at 16:29 -0800, David Brown wrote: > > > - default ARCH_MSM7X00A > > > - > > > -config ARCH_MSM7X00A > > > - bool "MSM7x00A / MSM7x01A" > > > - select MACH_TROUT if !MACH_HALIBUT > > > - select ARCH_MSM_ARM11 > > > - select MSM_SMD > > > - select MSM_SMD_PKG3 > > > - select CPU_V6 > > > - select GPIO_MSM_V1 > > > - select MSM_PROC_COMM > > > - select HAS_MSM_DEBUG_UART_PHYS > > > > > > Your trying to drop G1 support ? I have a G1 sitting on my desk, and I > > know many other people working on the kernel have G1's .. > > If someone is willing to step up and make it work, then we can keep it > around. My only G1 is fried, so I have no way to do anything other > than keep it compiling. Unfortunately, You can't remove it regardless of whether or not you have one to test on.. Your job is to do the best you can to keep it working and maintained. If you don't have one then you can't boot test but you still have to your best to keep it as close to working as possible. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: msm: Remove MSM7x00 support
On Wed, 2011-11-30 at 16:29 -0800, David Brown wrote: > - default ARCH_MSM7X00A > - > -config ARCH_MSM7X00A > - bool "MSM7x00A / MSM7x01A" > - select MACH_TROUT if !MACH_HALIBUT > - select ARCH_MSM_ARM11 > - select MSM_SMD > - select MSM_SMD_PKG3 > - select CPU_V6 > - select GPIO_MSM_V1 > - select MSM_PROC_COMM > - select HAS_MSM_DEBUG_UART_PHYS Your trying to drop G1 support ? I have a G1 sitting on my desk, and I know many other people working on the kernel have G1's .. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] msm: timer: compensate for timer shift in msm_read_timer_count
On Wed, 2011-06-08 at 20:44 -0700, Jeff Ohlstein wrote:
> Some msm targets have timers whose lower bits are unreliable. So, we
> present our timers as lower frequency than they actually are, and ignore
> the bottom 5 bits on such targets. This compensation was erroneously
> removed from the msm_read_timer_count function, so restore it.
>
> This was broken by 94790ec25 "msm: timer: SMP timer support for msm".
>
> Change-Id: I8c56bdf82629638748ccf352118ea664f967b87d
Drop this Change-ID ..
> Signed-off-by: Jeff Ohlstein
> ---
> arch/arm/mach-msm/timer.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
> index 38b95e9..b3579fe 100644
> --- a/arch/arm/mach-msm/timer.c
> +++ b/arch/arm/mach-msm/timer.c
> @@ -100,7 +100,7 @@ static cycle_t msm_read_timer_count(struct clocksource
> *cs)
> {
> struct msm_clock *clk = container_of(cs, struct msm_clock, clocksource);
>
> - return readl(clk->global_counter);
> + return readl(clk->global_counter) >> clk->shift;
> }
Could you comment in the code with something explaining what the shift
is doing.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] msm: watchdog: support watchdog on 8x60 and 8960
On Tue, 2011-03-29 at 21:40 -0700, Jeff Ohlstein wrote: > Daniel Walker wrote: > > Are you saying this is mostly a debugging facility ? The interrupts off > > thing I can see as just debugging, but I don't understand the bus > > lockups part. > > > > It isn't just a debugging facility. It is still beneficial to the end user > in that it restarts the system if there is a bus lockup or a faulty > interrupt > handler in a rarely used codepath. This is better than the alternative > of draining > the battery and turning off. We want this to be turned on independent of > what userspace > one is using, unless they explicitly turn it off themselves. It doesn't sound too different that all the other watchdogs in drivers/watchdog/ .. Your just detecting lockups right? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] msm: watchdog: support watchdog on 8x60 and 8960
On Fri, 2011-03-25 at 19:18 -0700, Jeff Ohlstein wrote: > The msm watchdog driver is present in kernel only. It does not use the > built-in Linux watchdog api. This is because the primary function of > our watchdog is detecting bus lockups and interrupts being turned off > for long periods of time. We wanted this functionality to be present > regardless of the userspace the kernel is running beneath. Userspace > is > free to have its own watchdog implemented in software. Are you saying this is mostly a debugging facility ? The interrupts off thing I can see as just debugging, but I don't understand the bus lockups part. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] msm: Add gpio support for 8960
On Wed, 2011-03-23 at 16:56 -0700, Rohit Vaswani wrote: > >> > >> - set_irq_chained_handler(TLMM_SCSS_SUMMARY_IRQ, > >> + set_irq_chained_handler(TLMM_MSM_SUMMARY_IRQ, > >>msm_summary_irq_handler); > > Ok, so looks like a rename. Can you add this to the commit text along > > with descriptions of everything else your doing? > Daniel, > Adding support for 8960 includes making sure that Gpio support remains > meaningful and at the same time uniform across different boards. Should > we enumerate the specific changes ? Should let everyone know exactly what your doing, even breaking up the changes into specific patches. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Git pull] MSM for v2.6.39
On Thu, 2011-03-17 at 08:59 -0700, David Brown wrote: > David Brown (16): > msm: Add CPU queries > msm: Generalize timer register mappings > msm: Generalize QGIC registers > msm: Add MSM 8960 cpu_is check > Merge branch 'msm-uart' into for-next > Merge branch 'msm-8960' into for-next > Merge branch 'msm-sdcc' into for-next > Merge branch 'msm-fb' into for-next > Merge branch 'msm-8960' into msm-core > msm: Remove broken register definition from trout > msm: Warning fix in trout gpio board file > Merge branch 'msm-core' into for-next > Merge branch 'msm-core' into for-next > Merge branch 'msm-core' into for-next > msm: Use explicit GPLv2 licenses > Merge remote branch 'rmk/for-linus' into for-linus Could you change the "for-next" name to something more interesting like msm-for-linus .. I think it would be acceptable to just create msm-for-linus during the merge window and merge all the sub-tree's into that. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/20] video: msm: Split out MDP2.2 HW specific code.
On Fri, 2011-03-18 at 14:57 -0700, Carl Vanderlip wrote: > index df9d74e..d6e75c3 100644 > --- a/arch/arm/mach-msm/Kconfig > +++ b/arch/arm/mach-msm/Kconfig > @@ -76,6 +76,11 @@ config HAS_MSM_DEBUG_UART_PHYS > config MSM_VIC > bool > > +config MSM_MDP22 > + bool > + depends on ARCH_MSM7X00A > + default y > + You should remove the "default y" and this should be moved to a Kconfig under video (shouldn't be added into mach-msm). Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mmc: msm_sdcc: Use SPS BAM as DMA engine
On Fri, 2011-03-18 at 18:54 +0530, Subhash Jadavani wrote: > On recent MSMs, ADM (Data Mover) HW is not present > which means existing SDCC driver can perform data > transfer in PIO (peripheral IO) mode only. > But PIO mode requires lot of CPU attention which > would mean consuming extra CPU MIPS. > > As a replacement on these recent MSMs, there is > a new DMA HW engine named SPS-BAM (as part of > Smart Peripheral System of MSM) is added for > data movement between SDCC core and system memory. > > This patch has done changes in existing MSM SDCC > driver for using SPS-BAM as DMA engine. 1300+ lines of code might warrant more of a description .. In the subject you say "DMA engine" but does this use drivers/dma/dmaengine.c ? > Signed-off-by: Subhash Jadavani > --- > drivers/mmc/host/Kconfig| 10 + > drivers/mmc/host/Makefile |1 + > drivers/mmc/host/msm_sdcc.c | 929 > +-- > drivers/mmc/host/msm_sdcc.h | 47 ++ > drivers/mmc/host/msm_sdcc_dml.c | 303 + > drivers/mmc/host/msm_sdcc_dml.h | 120 + > 6 files changed, 1374 insertions(+), 36 deletions(-) > create mode 100644 drivers/mmc/host/msm_sdcc_dml.c > create mode 100644 drivers/mmc/host/msm_sdcc_dml.h I'd do at least two patches. One that adds msm_sdcc_dml.[ch] and one that modifies msm_sdcc.[ch] and the Kconfig and Makefile. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] msm: Add gpio support for 8960
On Thu, 2011-03-17 at 15:57 -0700, Rohit Vaswani wrote:
> This patch adds GPIO support for 8960. The board file includes the
> gpiomux configs and we now use gpio-v2 for 8960.
>
> Signed-off-by: Rohit Vaswani
> ---
> arch/arm/mach-msm/Makefile |4 +--
> arch/arm/mach-msm/board-msm8960.c | 21
> arch/arm/mach-msm/gpio-v2.c | 13 ---
> arch/arm/mach-msm/include/mach/irqs-8960.h | 38 +++---
> arch/arm/mach-msm/include/mach/irqs-8x60.h | 24 +++---
> arch/arm/mach-msm/include/mach/msm_iomap-8960.h |3 ++
> arch/arm/mach-msm/include/mach/msm_iomap-8x60.h |5 +--
> arch/arm/mach-msm/include/mach/msm_iomap.h |1 +
> arch/arm/mach-msm/io.c |2 +
> 9 files changed, 68 insertions(+), 43 deletions(-)
>
> diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
> index 5ab09a1..a4f55ec 100644
> --- a/arch/arm/mach-msm/Makefile
> +++ b/arch/arm/mach-msm/Makefile
> @@ -30,11 +30,9 @@ obj-$(CONFIG_ARCH_MSM8960) += board-msm8960.o
> devices-msm8960.o
> obj-$(CONFIG_ARCH_MSM7X30) += gpiomux-v1.o gpiomux.o
> obj-$(CONFIG_ARCH_QSD8X50) += gpiomux-v1.o gpiomux.o
> obj-$(CONFIG_ARCH_MSM8X60) += gpiomux-v2.o gpiomux.o
> +obj-$(CONFIG_ARCH_MSM8960) += gpiomux-v2.o gpiomux.o
> ifdef CONFIG_MSM_V2_TLMM
> -ifndef CONFIG_ARCH_MSM8960
> -# TODO: TLMM Mapping issues need to be resolved
> obj-y+= gpio-v2.o
> -endif
> else
> obj-y+= gpio.o
> endif
> diff --git a/arch/arm/mach-msm/board-msm8960.c
> b/arch/arm/mach-msm/board-msm8960.c
> index 052cb35..1f003ba 100644
> --- a/arch/arm/mach-msm/board-msm8960.c
> +++ b/arch/arm/mach-msm/board-msm8960.c
> @@ -29,6 +29,25 @@
> #include
>
> #include "devices.h"
> +#include "gpiomux.h"
> +
> +static struct msm_gpiomux_config msm8960_gpiomux_configs[NR_GPIO_IRQS] = {};
> +
> +static int __init gpiomux_init(void)
> +{
> + int rc;
> +
> + rc = msm_gpiomux_init(NR_GPIO_IRQS);
> + if (rc) {
> + printk(KERN_ERR "msm_gpiomux_init failed %d\n", rc);
> + return rc;
> + }
> +
> + msm_gpiomux_install(msm8960_gpiomux_configs,
> + ARRAY_SIZE(msm8960_gpiomux_configs));
> +
> + return 0;
> +}
>
> static void __init msm8960_map_io(void)
> {
> @@ -68,12 +87,14 @@ static struct platform_device *rumi3_devices[] __initdata
> = {
> static void __init msm8960_sim_init(void)
> {
> msm_clock_init(msm_clocks_8960, msm_num_clocks_8960);
> + gpiomux_init();
> platform_add_devices(sim_devices, ARRAY_SIZE(sim_devices));
> }
>
> static void __init msm8960_rumi3_init(void)
> {
> msm_clock_init(msm_clocks_8960, msm_num_clocks_8960);
> + gpiomux_init();
> platform_add_devices(rumi3_devices, ARRAY_SIZE(rumi3_devices));
> }
>
> diff --git a/arch/arm/mach-msm/gpio-v2.c b/arch/arm/mach-msm/gpio-v2.c
> index fb52d6d..6a37695 100644
> --- a/arch/arm/mach-msm/gpio-v2.c
> +++ b/arch/arm/mach-msm/gpio-v2.c
> @@ -1,4 +1,4 @@
> -/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
> +/* Copyright (c) 2010-2011 Code Aurora Forum. All rights reserved.
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 and
> @@ -326,6 +326,7 @@ static int msm_gpio_irq_set_type(unsigned int irq,
> unsigned int flow_type)
> static void msm_summary_irq_handler(unsigned int irq, struct irq_desc *desc)
> {
> unsigned long i;
> + struct irq_chip *chip = get_irq_desc_chip(desc);
>
> for (i = find_first_bit(msm_gpio.enabled_irqs, NR_GPIO_IRQS);
>i < NR_GPIO_IRQS;
> @@ -334,7 +335,7 @@ static void msm_summary_irq_handler(unsigned int irq,
> struct irq_desc *desc)
> generic_handle_irq(msm_gpio_to_irq(&msm_gpio.gpio_chip,
> i));
> }
> - desc->chip->ack(irq);
> + chip->irq_ack(&desc->irq_data);
> }
It looks like your fixing something above, but you've not spelled out
what your doing in the commit text.
> static int msm_gpio_irq_set_wake(unsigned int irq, unsigned int on)
> @@ -343,12 +344,12 @@ static int msm_gpio_irq_set_wake(unsigned int irq,
> unsigned int on)
>
> if (on) {
> if (bitmap_empty(msm_gpio.wake_irqs, NR_GPIO_IRQS))
> - set_irq_wake(TLMM_SCSS_SUMMARY_IRQ, 1);
> + set_irq_wake(TLMM_MSM_SUMMARY_IRQ, 1);
> set_bit(gpio, msm_gpio.wake_irqs);
> } else {
> clear_bit(gpio, msm_gpio.wake_irqs);
> if (bitmap_empty(msm_gpio.wake_irqs, NR_GPIO_IRQS))
> - set_irq_wake(TLMM_SCSS_SUMMARY_IRQ, 0);
> + set_irq_wake(TLMM_MSM_SUMMARY_IRQ, 0);
> }
Again looks like another fix, but your not telling us what your doing.
> return 0;
> @@ -382,7 +383,7 @@ static
Re: [PATCH] msm: iommu: Use relaxed register access functions
On Thu, 2011-03-17 at 13:01 -0700, Stepan Moskovchenko wrote: > Use the relaxed versions of readl/writel for IOMMU register > access, inserting barriers where appropriate. Could you provide comments on why you need barriers in the various places you've placed them. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] msm: Peripheral Image Loader (PIL) driver
On Wed, 2011-03-16 at 11:40 -0700, David Brown wrote: > On Wed, Mar 16 2011, Daniel Walker wrote: > > > On Wed, 2011-03-09 at 20:44 -0800, Stephen Boyd wrote: > >> On 8660, the modem, dsp, and sensors peripherals require their > >> firmware to be loaded into memory before they can be properly > >> taken out of reset. > >> > >> Drivers are expected to call pil_get() when they wish to load a > >> peripheral. This will initiate multiple firmware_request()s for > >> the metadata and image blobs for a peripheral. Once the image has > >> been loaded into memory, it is validated and brought out of reset > >> via the peripheral reset driver. > > > > Why can't this be part of the generic firmware request API ? > > Can you clarify what you mean by this? The firmware request API is used > to get the firmware itself, which this code uses. This code is what > manages making those calls for the various MSM peripherals that require > firmware. I'm suggesting that you make this part of a generic set of API's . > >> diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig > >> index 997c5bd..25b73b0 100644 > >> --- a/arch/arm/mach-msm/Kconfig > >> +++ b/arch/arm/mach-msm/Kconfig > >> @@ -210,4 +210,17 @@ config IOMMU_API > >> > >> config MSM_SCM > >> bool > >> + > >> +config MSM_PIL > >> + bool "Peripheral image loading (PIL)" > >> + select FW_LOADER > >> + select MSM_SCM > >> + depends on ARCH_MSM8X60 > >> + help > >> + Some peripherals need to be loaded into memory before they > >> can be > >> + brought out of reset. > >> + > >> + Say yes to support these devices. > >> + > >> + > > > > You shouldn't be adding anything like this to the Kconfig. To me if you > > add stuff like this it's a big red flag. > > Can you clarify what you mean "stuff like this". I was commenting on a Kconfig option so "stuff like this" is a Kconfig option like the one I was commenting on. > It seems to me that this option should be selected by the drivers that > need it, since it doesn't make sense to have this if there are no > drivers that need it, and it is required when those drivers are > included. You want as few selectable Kconfig options in the mach-msm Kconfig as possible. Danil -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] msm: Peripheral Image Loader (PIL) driver
On Wed, 2011-03-16 at 11:48 -0700, Saravana Kannan wrote: > On 03/16/2011 11:40 AM, David Brown wrote: > > On Wed, Mar 16 2011, Daniel Walker wrote: > > > >> On Wed, 2011-03-09 at 20:44 -0800, Stephen Boyd wrote: > >>> On 8660, the modem, dsp, and sensors peripherals require their > >>> firmware to be loaded into memory before they can be properly > >>> taken out of reset. > >>> > >>> Drivers are expected to call pil_get() when they wish to load a > >>> peripheral. This will initiate multiple firmware_request()s for > >>> the metadata and image blobs for a peripheral. Once the image has > >>> been loaded into memory, it is validated and brought out of reset > >>> via the peripheral reset driver. > >> > >> Why can't this be part of the generic firmware request API ? > > > > Can you clarify what you mean by this? The firmware request API is used > > to get the firmware itself, which this code uses. This code is what > > manages making those calls for the various MSM peripherals that require > > firmware. > > > >>> diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig > >>> index 997c5bd..25b73b0 100644 > >>> --- a/arch/arm/mach-msm/Kconfig > >>> +++ b/arch/arm/mach-msm/Kconfig > >>> @@ -210,4 +210,17 @@ config IOMMU_API > >>> > >>> config MSM_SCM > >>> bool > >>> + > >>> +config MSM_PIL > >>> + bool "Peripheral image loading (PIL)" > >>> + select FW_LOADER > >>> + select MSM_SCM > >>> + depends on ARCH_MSM8X60 > >>> + help > >>> + Some peripherals need to be loaded into memory before they > >>> can be > >>> + brought out of reset. > >>> + > >>> + Say yes to support these devices. > >>> + > >>> + > >> > >> You shouldn't be adding anything like this to the Kconfig. To me if you > >> add stuff like this it's a big red flag. > > > > Can you clarify what you mean "stuff like this". > > > > It seems to me that this option should be selected by the drivers that > > need it, since it doesn't make sense to have this if there are no > > drivers that need it, and it is required when those drivers are > > included. > > > > I do think there are valid hardware configurations that don't have any > > peripherals needing firmware, and would think that those should be able > > to avoid requiring the code to manage that. Saravana/Stephen can > > clarify that, though. > > Correct. There are plenty of Qualcomm SoCs that don't need this driver. > There are also valid 8660 configurations that would not need this. Being a driver it shouldn't be in mach-msm. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] msm: Peripheral Image Loader (PIL) driver
On Wed, 2011-03-09 at 20:44 -0800, Stephen Boyd wrote: > On 8660, the modem, dsp, and sensors peripherals require their > firmware to be loaded into memory before they can be properly > taken out of reset. > > Drivers are expected to call pil_get() when they wish to load a > peripheral. This will initiate multiple firmware_request()s for > the metadata and image blobs for a peripheral. Once the image has > been loaded into memory, it is validated and brought out of reset > via the peripheral reset driver. Why can't this be part of the generic firmware request API ? > Change-Id: I041139464bbd3b646b82370ab540f40b0ac9af6b Can't have Change-Id's .. > Reviewed-by: Saravana Kannan > Signed-off-by: Stephen Boyd > --- > arch/arm/mach-msm/Kconfig | 13 + > arch/arm/mach-msm/Makefile |2 + > arch/arm/mach-msm/include/mach/peripheral-loader.h | 23 + > arch/arm/mach-msm/peripheral-loader.c | 402 > +++ > arch/arm/mach-msm/peripheral-loader.h | 38 ++ > arch/arm/mach-msm/peripheral-reset.c | 528 > > 6 files changed, 1006 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/mach-msm/include/mach/peripheral-loader.h > create mode 100644 arch/arm/mach-msm/peripheral-loader.c > create mode 100644 arch/arm/mach-msm/peripheral-loader.h > create mode 100644 arch/arm/mach-msm/peripheral-reset.c > > diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig > index 997c5bd..25b73b0 100644 > --- a/arch/arm/mach-msm/Kconfig > +++ b/arch/arm/mach-msm/Kconfig > @@ -210,4 +210,17 @@ config IOMMU_API > > config MSM_SCM > bool > + > +config MSM_PIL > + bool "Peripheral image loading (PIL)" > + select FW_LOADER > + select MSM_SCM > + depends on ARCH_MSM8X60 > + help > + Some peripherals need to be loaded into memory before they > can be > + brought out of reset. > + > + Say yes to support these devices. > + > + You shouldn't be adding anything like this to the Kconfig. To me if you add stuff like this it's a big red flag. I didn't review the rest sign it might be wasted effort on my part.. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] msm: add single-wire serial bus interface (SSBI) driver
On Thu, 2011-02-24 at 18:31 -0800, David Brown wrote: > On Thu, Feb 24 2011, Daniel Walker wrote: > > > You have some submission problems. one is that the subject should be > > "drivers: msm: ..." , this patch also shouldn't go to David. > > Subject needs to be fixed. Patch to add drivers/msm to the maintainers > file has been Acked, so this should be sent to the MSM maintainers. It was only acked by Nico, he's just the one who suggested it. I think Greg needs to be involved at some level .. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] msm: add single-wire serial bus interface (SSBI) driver
You have some submission problems. one is that the subject should be "drivers: msm: ..." , this patch also shouldn't go to David. On Thu, 2011-02-24 at 15:19 -0700, Kenneth Heitke wrote: > SSBI is the Qualcomm single-wire serial bus interface used to connect > the MSM devices to the PMIC and other devices. > > Since SSBI only supports a single slave, the driver gets the name of the > slave device passed in from the board file through the master device's > platform data. > > SSBI registers pretty early (postcore), so that the PMIC can come up > before the board init. This is useful if the board init requires the > use of gpios that are connected through the PMIC. > > Based on a patch by Dima Zavin that can be found at: > http://android.git.kernel.org/?p=kernel/msm.git;a=commitdiff;h=eb060bac4 I don't really like links in the commit text, cause as soon as Google deletes this tree the link is worthless. > This patch adds PMIC Arbiter support for the MSM8660. The PMIC Arbiter > is a hardware wrapper around the SSBI 2.0 controller that is designed to > overcome concurrency issues and security limitations. A controller_type > field is added to the platform data to specify the type of the SSBI > controller (1.0, 2.0, or PMIC Arbiter). > > Signed-off-by: Kenneth Heitke > --- > drivers/Kconfig |2 + > drivers/Makefile |1 + > drivers/msm/Kconfig | 13 ++ > drivers/msm/Makefile |4 + > drivers/msm/ssbi.c | 376 > ++ > include/linux/msm_ssbi.h | 49 ++ > 6 files changed, 445 insertions(+), 0 deletions(-) > create mode 100644 drivers/msm/Kconfig > create mode 100644 drivers/msm/Makefile > create mode 100644 drivers/msm/ssbi.c > create mode 100644 include/linux/msm_ssbi.h > > diff --git a/drivers/Kconfig b/drivers/Kconfig > index 9bfb71f..fceeb20 100644 > --- a/drivers/Kconfig > +++ b/drivers/Kconfig > @@ -117,4 +117,6 @@ source "drivers/staging/Kconfig" > source "drivers/platform/Kconfig" > > source "drivers/clk/Kconfig" > + > +source "drivers/msm/Kconfig" > endmenu > diff --git a/drivers/Makefile b/drivers/Makefile > index b423bb1..14cb94b 100644 > --- a/drivers/Makefile > +++ b/drivers/Makefile > @@ -117,3 +117,4 @@ obj-y += platform/ > obj-y+= ieee802154/ > #common clk code > obj-y+= clk/ > +obj-y+= msm/ > diff --git a/drivers/msm/Kconfig b/drivers/msm/Kconfig > new file mode 100644 > index 000..413bb65 > --- /dev/null > +++ b/drivers/msm/Kconfig > @@ -0,0 +1,13 @@ > +menu "Qualcomm MSM specific device drivers" > + depends on ARCH_MSM > + > +config MSM_SSBI > + bool "Qualcomm Single-wire Serial Bus Interface (SSBI)" > + help > + If you say yes to this option, support will be included for the > + built-in SSBI interface on Qualcomm MSM family processors. > + > + This is required for communicating with Qualcomm PMICs and > + other devices that have the SSBI interface. > + > +endmenu > diff --git a/drivers/msm/Makefile b/drivers/msm/Makefile > new file mode 100644 > index 000..ea8c1e4 > --- /dev/null > +++ b/drivers/msm/Makefile > @@ -0,0 +1,4 @@ > +# > +# Makefile for the MSM specific device drivers. > +# > +obj-$(CONFIG_MSM_SSBI) += ssbi.o > diff --git a/drivers/msm/ssbi.c b/drivers/msm/ssbi.c > new file mode 100644 > index 000..1fae443 > --- /dev/null > +++ b/drivers/msm/ssbi.c > @@ -0,0 +1,376 @@ > +/* Copyright (c) 2009-2011, Code Aurora Forum. All rights reserved. > + * Copyright (c) 2010, Google Inc. > + * > + * Original authors: Code Aurura Forum Spelling problem. > + * Author: Dima Zavin > + * - Largely rewritten from original to not be an i2c driver. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 and > + * only version 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* SSBI 2.0 controller registers */ > +#define SSBI2_CMD0x0008 > +#define SSBI2_RD 0x0010 > +#define SSBI2_STATUS 0x0014 > +#define SSBI2_MODE2 0x001C > + > +/* SSBI_CMD fields */ > +#define SSBI_CMD_RDWRN (1 << 24) > + > +/* SSBI_STATUS fields */ > +#define SSBI_STATUS_RD_READY (1 << 2) > +#define SSBI_STATUS_READY(1 << 1) > +#define SSBI_STATUS_MCHN_BUSY(1 << 0) > + > +/* SSBI_MODE2 fields */ > +#define SSBI_MODE2_REG_ADDR_15_8_SHFT0x04 > +#define
Re: [PATCH] MAINTAINERS: Update MSM maintainers
On Wed, 2011-02-23 at 13:26 -0800, Bryan Huntsman wrote: > On 02/22/2011 05:12 PM, Linus Torvalds wrote: > > On Tue, Feb 22, 2011 at 4:19 PM, Daniel Walker wrote: > >> On Tue, 2011-02-22 at 16:03 -0800, David Brown wrote: > >>> Remove Bryan Huntsman and Daniel Walker from the MSM maintainer list. > >>> > >> > >> No.. I don't sign off on this.. Please ignore this Linus. > > > > Guys, you need to sort out your differences here.. > > > > Linus > > Daniel, let's do what Linus is asking and figure this out. What is your > intention here? Going forward, David Brown is in the best position to > handle MSM maintenance since he has direct access to all past, current, > and future MSM devices as well as all the HW and SW experts at Qualcomm. > In that spirit, I think it's entirely appropriate for both you and I to > step back and let David handle this role so that there is one consistent > and clear voice for MSM. There's nothing really to figure out. I don't feel like you and David can do the job alone. My intentions are just to make sure that you don't mess with my targets, and that you do the right thing by the community. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] msm: add single-wire serial bus interface (SSBI) driver
On Tue, 2011-02-22 at 16:17 -0800, David Brown wrote: > On Tue, Feb 22 2011, Daniel Walker wrote: > > > On Tue, 2011-02-22 at 12:47 -0800, Dima Zavin wrote: > > > >> What is the problem leaving it under arch/arm/mach-msm? > > > > Because it's a driver. > > There are a lot of other drivers currently under various arch > subsystems. I'm not sure if a driver that is specific to only one arch > has a strong reason to be elsewhere in the kernel. If there was a > possibility of there being other devices that used SSBI, it might make > sense to put it elsewhere. But, as far as I know, this device is only > found on MSM chips. There are lots of arch specific drivers under drivers/ . In fact I'm sure there are more arch specific drivers under drivers/ than anyplace else. That's how we organize things in Linux. > It seems kind of unusual to create an entirely new directory under > drivers to hold what will only ever be a single driver. Then put it under another directory. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: Update MSM maintainers
On Tue, 2011-02-22 at 16:03 -0800, David Brown wrote: > Remove Bryan Huntsman and Daniel Walker from the MSM maintainer list. > No.. I don't sign off on this.. Please ignore this Linus. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] msm: add single-wire serial bus interface (SSBI) driver
On Tue, 2011-02-22 at 12:47 -0800, Dima Zavin wrote: > What is the problem leaving it under arch/arm/mach-msm? Because it's a driver. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] msm: headsmp.S: Fix section mismatch
On Fri, 2011-02-18 at 19:14 -0800, Stephen Boyd wrote: > WARNING: vmlinux.o(.cpuinit.text+0xc80): Section mismatch in > reference from the function boot_secondary() to the variable > .init.text:msm_secondary_startup > The function __cpuinit boot_secondary() references a variable > __init msm_secondary_startup. If msm_secondary_startup is only > used by boot_secondary then annotate msm_secondary_startup with > a matching annotation. Description is pretty gross.. Can you just explain how the section mismatch is happening. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] msm: add single-wire serial bus interface (SSBI) driver
On Thu, 2011-02-17 at 16:51 -0800, Bryan Huntsman wrote: > On 02/17/2011 04:37 PM, Daniel Walker wrote: > > Can you put this in drivers/ this doesn't looks like it need to be here. > > Where would you suggest? The initial attempt to model SSBI as an I2C > bus didn't go anywhere. See http://lkml.org/lkml/2010/7/21/400. This > functionality is specific to MSM. Plus, we're trying to maintain > similarity to the Android MSM tree. That may not matter to people who > don't use MSM, but is matters to us. Given these considerations, the > current location seems as good a place as any. I don't know the driver well enough to be more detailed than suggesting drivers/ . In the thread you quoted Pavel (who I added to the CC line) suggested drivers/ssbi/ . Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] msm: add single-wire serial bus interface (SSBI) driver
On Thu, 2011-02-17 at 17:34 -0700, Kenneth Heitke wrote: > SSBI is the Qualcomm single-wire serial bus interface used to connect > the MSM devices to the PMIC and other devices. > > Since SSBI only supports a single slave, the driver gets the name of the > slave device passed in from the board file through the master device's > platform data. > > SSBI registers pretty early (postcore), so that the PMIC can come up > before the board init. This is useful if the board init requires the > use of gpios that are connected through the PMIC. > > Based on a patch by Dima Zavin that can be found at: > http://android.git.kernel.org/?p=kernel/msm.git;a=commitdiff;h=eb060bac4 > > This patch adds PMIC Arbiter support for the MSM8660. The PMIC Arbiter > is a hardware wrapper around the SSBI 2.0 controller that is designed to > overcome concurrency issues and security limitations. A controller_type > field is added to the platform data to specify the type of the SSBI > controller (1.0, 2.0, or PMIC Arbiter). > > Signed-off-by: Kenneth Heitke > --- > arch/arm/mach-msm/Kconfig | 16 ++ > arch/arm/mach-msm/Makefile|1 + > arch/arm/mach-msm/include/mach/msm_ssbi.h | 38 +++ > arch/arm/mach-msm/ssbi.c | 376 > + > 4 files changed, 431 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/mach-msm/include/mach/msm_ssbi.h > create mode 100644 arch/arm/mach-msm/ssbi.c > > diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig > index 997c5bd..f35c3d9 100644 > --- a/arch/arm/mach-msm/Kconfig > +++ b/arch/arm/mach-msm/Kconfig > @@ -24,6 +24,7 @@ config ARCH_MSM7X30 > select MSM_GPIOMUX > select MSM_PROC_COMM > select HAS_MSM_DEBUG_UART_PHYS > + select HAS_MSM_SSBI > > config ARCH_QSD8X50 > bool "QSD8X50" > @@ -46,6 +47,7 @@ config ARCH_MSM8X60 > select MSM_V2_TLMM > select MSM_GPIOMUX > select MSM_SCM if SMP > + select HAS_MSM_SSBI > > config ARCH_MSM8960 > bool "MSM8960" > @@ -56,6 +58,7 @@ config ARCH_MSM8960 > select MSM_V2_TLMM > select MSM_GPIOMUX > select MSM_SCM if SMP > + select HAS_MSM_SSBI > > endchoice > > @@ -190,6 +193,16 @@ choice > endchoice > endif > > +config MSM_SSBI > + bool "Qualcomm Single-wire Serial Bus Interface (SSBI)" > + depends on HAS_MSM_SSBI > + help > + If you say yes to this option, support will be included for the > + built-in SSBI interface on Qualcomm MSM family processors. > + > + This is required for communicating with Qualcomm PMICs and > + other devices that have the SSBI interface. > + Can you put this in drivers/ this doesn't looks like it need to be here. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] msm: iommu: Create a Kconfig item for the IOMMU driver
On Tue, 2011-02-15 at 11:35 -0800, David Brown wrote: > On Fri, Feb 11 2011, Daniel Walker wrote: > > > On Fri, 2011-02-11 at 12:28 -0800, Stepan Moskovchenko wrote: > >> +config MSM_IOMMU > >> + bool "MSM IOMMU Support" > >> + depends on ARCH_MSM8X60 > >> + select IOMMU_API > >> + default n > >> + help > >> + Support for the IOMMUs found on certain Qualcomm SOCs. > >> + These IOMMUs allow virtualization of the address space used by > >> most > >> + cores within the multimedia subsystem. > >> + > >> + If unsure, say N here. > > > > I think you should just make this a hidden option, unless there is a > > good reason why any given users might want to turn this off. > > In this particular case, the driver is optional, even devices that use > it will be able to work both with and without it. It makes sense to be > able to decide whether to have it or not. This driver doesn't belong under mach-msm. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] msm: iommu: Create a Kconfig item for the IOMMU driver
On Tue, 2011-02-15 at 11:35 -0800, David Brown wrote: > On Fri, Feb 11 2011, Daniel Walker wrote: > > > On Fri, 2011-02-11 at 12:28 -0800, Stepan Moskovchenko wrote: > >> +config MSM_IOMMU > >> + bool "MSM IOMMU Support" > >> + depends on ARCH_MSM8X60 > >> + select IOMMU_API > >> + default n > >> + help > >> + Support for the IOMMUs found on certain Qualcomm SOCs. > >> + These IOMMUs allow virtualization of the address space used by > >> most > >> + cores within the multimedia subsystem. > >> + > >> + If unsure, say N here. > > > > I think you should just make this a hidden option, unless there is a > > good reason why any given users might want to turn this off. > > In this particular case, the driver is optional, even devices that use > it will be able to work both with and without it. It makes sense to be > able to decide whether to have it or not. Typically we include everything the SoC has regardless of if drivers use the hardware or not . For instance there could be modules that use the hardware .. Regardless of this point, I've nacked the whole series. It looks like there was very little thought put into this. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
On Fri, 2011-02-11 at 15:16 -0800, David Brown wrote: > On Fri, Feb 11 2011, Daniel Walker wrote: > > > On Fri, 2011-02-11 at 14:37 -0800, David Brown wrote: > > >> It is functionality that will be shared across multiple socs. Putting > >> the name of a specific soc would just be misleading. Currently, it's > >> our only iommu. Support for another family that uses a different iommu > >> could perhaps call it iommu2. > > > > Your missing my point. I'm saying it doesn't look flexible enough to > > allow support for multiple SoCs .. Is everything going to be identical > > across all the supported socs ? > > It wouldn't help, though. If the addresses differ across targets, we > don't want defines that are conditionally defined, so we would need > multiple tables, giving the address for specific targets. Still no > reason to have an indirection on the names. I'm talking about the whole deal here, this whole patch series. It doesn't seem like this has been thought out too well. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
On Fri, 2011-02-11 at 14:37 -0800, David Brown wrote:
> On Fri, Feb 11 2011, Daniel Walker wrote:
>
> > On Fri, 2011-02-11 at 12:28 -0800, Stepan Moskovchenko wrote:
> >> Make the IOMMU platform data target-independent in
> >> preparation for adding MSM8960 IOMMU support. The IOMMU
> >> configuration on MSM8x60 and MSM8960 is identical and the
> >> same platform data can be used for both.
> >>
> >> Signed-off-by: Stepan Moskovchenko
> >> ---
> >> arch/arm/mach-msm/Makefile |4 +-
> >> .../{devices-msm8x60-iommu.c => devices-iommu.c} | 54
> >> +--
> >> arch/arm/mach-msm/include/mach/msm_iomap-8x60.h| 36 -
> >> 3 files changed, 28 insertions(+), 66 deletions(-)
> >> rename arch/arm/mach-msm/{devices-msm8x60-iommu.c => devices-iommu.c}
> >> (93%)
> >
> > If it's like what you and David are suggesting I think you would need a
> > SoC designation in the filename ..
>
> It is functionality that will be shared across multiple socs. Putting
> the name of a specific soc would just be misleading. Currently, it's
> our only iommu. Support for another family that uses a different iommu
> could perhaps call it iommu2.
Your missing my point. I'm saying it doesn't look flexible enough to
allow support for multiple SoCs .. Is everything going to be identical
across all the supported socs ?
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
On Fri, 2011-02-11 at 12:28 -0800, Stepan Moskovchenko wrote:
> Make the IOMMU platform data target-independent in
> preparation for adding MSM8960 IOMMU support. The IOMMU
> configuration on MSM8x60 and MSM8960 is identical and the
> same platform data can be used for both.
>
> Signed-off-by: Stepan Moskovchenko
> ---
> arch/arm/mach-msm/Makefile |4 +-
> .../{devices-msm8x60-iommu.c => devices-iommu.c} | 54 +--
> arch/arm/mach-msm/include/mach/msm_iomap-8x60.h| 36 -
> 3 files changed, 28 insertions(+), 66 deletions(-)
> rename arch/arm/mach-msm/{devices-msm8x60-iommu.c => devices-iommu.c} (93%)
If it's like what you and David are suggesting I think you would need a
SoC designation in the filename ..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
On Fri, 2011-02-11 at 13:53 -0800, David Brown wrote: > On Fri, Feb 11 2011, Daniel Walker wrote: > > > On Fri, 2011-02-11 at 13:03 -0800, David Brown wrote: > >> On Fri, Feb 11 2011, Steve Muckle wrote: > > >> If they were used in more than one place, we could justify the > >> definition, but in this case, the definition just obscures the code > >> slightly. > > Someone debugging it will look at the constant. In fact, in general, > the only person looking at this structure will want to know the value in > the table. Indirecting it through a pointer only serves to hide it from > the person who wants to know the value. Like I said in my example, people looking at the code won't always be debugging. > > A good example might be if all these constants are enumerated in a > > header file, but aren't all used. In that case it would be fairly easy > > to add a new resource without even know what the constant is just by > > following the pattern. > > This I definitely want to avoid. I have seen header files with hundreds > of thousands of register definitions, where only a few were used. I think your thinking of stuff that's not properly grouped. > > I think in general this series just makes this iommu code very much > > 8660/8960 only code, but what about the potential next iteration of SoC > > that uses very similar code to this with all new constants. So this > > doesn't seem forward thinking to me. > > The table would have the different addresses in it. My point is that > the resource table _is_ the definition of the addres. Nothing is gained > by inventing yet another name and putting that somewhere else. In my example I showed you there is something to be gained by doing this. As you said already there isn't must lost in doing it this way. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
On Fri, 2011-02-11 at 13:03 -0800, David Brown wrote:
> On Fri, Feb 11 2011, Steve Muckle wrote:
>
> > On 02/11/11 12:42, Daniel Walker wrote:
> >>> static struct resource msm_iommu_jpegd_resources[] = {
> >>> {
> >>> - .start = MSM_IOMMU_JPEGD_PHYS,
> >>> - .end = MSM_IOMMU_JPEGD_PHYS + MSM_IOMMU_JPEGD_SIZE - 1,
> >>> + .start = 0x0730,
> >>> + .end = 0x0730 + SZ_1M - 1,
> >>
> >> Looks worse .. Just put the macros into a static header file for both.
> >
> > Why bother defining macros for these if they only appear here? I don't
> > think that adds any value or readability - these addresses are clearly
> > the physical area for the msm_iommu_jpegd. It just makes it more
> > annoying to have to look up the values in a separate file if you are
> > wondering what they are.
>
> I want to chime in with a second on this. Defining names for constants
> serves several purposes:
>
> - It gives meaning to the constants.
>
> - It allows the definition to be centralized if the value is used in
> one place.
>
> If the constants are initializers in a table, it satisfies both of these
> reasons. Adding #defines for these constants does nothing other than
> cause an extra indirection that the reader of the code has to make.
>
> If they were used in more than one place, we could justify the
> definition, but in this case, the definition just obscures the code
> slightly.
It only obscures the constant, which no one really looks at anyway. in
general it's better design to hide constant like this, because people
don't work naturally with numbers like this.
A good example might be if all these constants are enumerated in a
header file, but aren't all used. In that case it would be fairly easy
to add a new resource without even know what the constant is just by
following the pattern.
I think in general this series just makes this iommu code very much
8660/8960 only code, but what about the potential next iteration of SoC
that uses very similar code to this with all new constants. So this
doesn't seem forward thinking to me.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
On Fri, 2011-02-11 at 13:00 -0800, Steve Muckle wrote:
> On 02/11/11 12:58, Daniel Walker wrote:
> > On Fri, 2011-02-11 at 12:51 -0800, Steve Muckle wrote:
> >> On 02/11/11 12:42, Daniel Walker wrote:
> >>>> static struct resource msm_iommu_jpegd_resources[] = {
> >>>> {
> >>>> -.start = MSM_IOMMU_JPEGD_PHYS,
> >>>> -.end = MSM_IOMMU_JPEGD_PHYS + MSM_IOMMU_JPEGD_SIZE -
> >>>> 1,
> >>>> +.start = 0x0730,
> >>>> +.end = 0x0730 + SZ_1M - 1,
> >>>
> >>> Looks worse .. Just put the macros into a static header file for both.
> >>
> >> Why bother defining macros for these if they only appear here? I don't
> >> think that adds any value or readability - these addresses are clearly
> >> the physical area for the msm_iommu_jpegd. It just makes it more
> >> annoying to have to look up the values in a separate file if you are
> >> wondering what they are.
> >
> > So your saying if you look at the number 0x0730 you instantly know
> > that this JPEGD?
>
> Yes, because it's the start address for the msm_iommu_jpegd resource.
Yeah I guess that's true .. I still think it's better design not to do
it this way.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
On Fri, 2011-02-11 at 12:51 -0800, Steve Muckle wrote:
> On 02/11/11 12:42, Daniel Walker wrote:
> >> static struct resource msm_iommu_jpegd_resources[] = {
> >>{
> >> - .start = MSM_IOMMU_JPEGD_PHYS,
> >> - .end = MSM_IOMMU_JPEGD_PHYS + MSM_IOMMU_JPEGD_SIZE - 1,
> >> + .start = 0x0730,
> >> + .end = 0x0730 + SZ_1M - 1,
> >
> > Looks worse .. Just put the macros into a static header file for both.
>
> Why bother defining macros for these if they only appear here? I don't
> think that adds any value or readability - these addresses are clearly
> the physical area for the msm_iommu_jpegd. It just makes it more
> annoying to have to look up the values in a separate file if you are
> wondering what they are.
So your saying if you look at the number 0x0730 you instantly know
that this JPEGD? What if I pick a random other kernel developer do you
think they would instantly know that? I have no idea what 0x0730 is.
Also if it's in a header you could ifdef them with out touching the C
file, which is just forward looking.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
On Fri, 2011-02-11 at 12:28 -0800, Stepan Moskovchenko wrote:
> Make the IOMMU platform data target-independent in
> preparation for adding MSM8960 IOMMU support. The IOMMU
> configuration on MSM8x60 and MSM8960 is identical and the
> same platform data can be used for both.
>
> Signed-off-by: Stepan Moskovchenko
> ---
> arch/arm/mach-msm/Makefile |4 +-
> .../{devices-msm8x60-iommu.c => devices-iommu.c} | 54 +--
> arch/arm/mach-msm/include/mach/msm_iomap-8x60.h| 36 -
> 3 files changed, 28 insertions(+), 66 deletions(-)
> rename arch/arm/mach-msm/{devices-msm8x60-iommu.c => devices-iommu.c} (93%)
>
> diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
> index 81f4811..2099c97 100644
> --- a/arch/arm/mach-msm/Makefile
> +++ b/arch/arm/mach-msm/Makefile
> @@ -4,12 +4,12 @@ obj-$(CONFIG_DEBUG_FS) += clock-debug.o
> endif
>
> obj-$(CONFIG_MSM_VIC) += irq-vic.o
> -obj-$(CONFIG_MSM_IOMMU) += iommu.o iommu_dev.o
> +obj-$(CONFIG_MSM_IOMMU) += iommu.o iommu_dev.o devices-iommu.o
>
> obj-$(CONFIG_ARCH_MSM7X00A) += dma.o irq.o acpuclock-arm11.o
> obj-$(CONFIG_ARCH_MSM7X30) += dma.o
> obj-$(CONFIG_ARCH_QSD8X50) += dma.o sirc.o
> -obj-$(CONFIG_ARCH_MSM8X60) += clock-dummy.o devices-msm8x60-iommu.o
> +obj-$(CONFIG_ARCH_MSM8X60) += clock-dummy.o
> obj-$(CONFIG_ARCH_MSM8960) += clock-dummy.o
>
> obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o
> diff --git a/arch/arm/mach-msm/devices-msm8x60-iommu.c
> b/arch/arm/mach-msm/devices-iommu.c
> similarity index 93%
> rename from arch/arm/mach-msm/devices-msm8x60-iommu.c
> rename to arch/arm/mach-msm/devices-iommu.c
> index f9e7bd3..c0206b7 100644
> --- a/arch/arm/mach-msm/devices-msm8x60-iommu.c
> +++ b/arch/arm/mach-msm/devices-iommu.c
> @@ -1,4 +1,4 @@
> -/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
> +/* Copyright (c) 2010-2011, Code Aurora Forum. All rights reserved.
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 and
> @@ -18,15 +18,13 @@
> #include
> #include
> #include
> -
> -#include
> -#include
> +#include
> #include
>
> static struct resource msm_iommu_jpegd_resources[] = {
> {
> - .start = MSM_IOMMU_JPEGD_PHYS,
> - .end = MSM_IOMMU_JPEGD_PHYS + MSM_IOMMU_JPEGD_SIZE - 1,
> + .start = 0x0730,
> + .end = 0x0730 + SZ_1M - 1,
Looks worse .. Just put the macros into a static header file for both.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] msm: iommu: Create a Kconfig item for the IOMMU driver
On Fri, 2011-02-11 at 12:28 -0800, Stepan Moskovchenko wrote: > +config MSM_IOMMU > + bool "MSM IOMMU Support" > + depends on ARCH_MSM8X60 > + select IOMMU_API > + default n > + help > + Support for the IOMMUs found on certain Qualcomm SOCs. > + These IOMMUs allow virtualization of the address space used by most > + cores within the multimedia subsystem. > + > + If unsure, say N here. I think you should just make this a hidden option, unless there is a good reason why any given users might want to turn this off. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Nexus One Support
On Fri, 2011-02-04 at 14:36 +0100, Pavel Machek wrote: > On Thu 2011-01-20 12:32:38, Daniel Walker wrote: > > This series adds basic Nexus One support which includes a booting > > kernel, and functional MMC . > > > > Most people won't be able to use this yet unfortunately because > > you need a serial cable to get any output. However, it's a start. > > > msm: mahimahi: add mahimahi board file > > msm: mahimahi: add in mmc support code > > msm: mahimahi: add gpio pin muxing code > > msm: mahimahi: initialize mmc at start up > > Even you call the machine Nexus One... can you be a tiny bit more > consistent with it? I tried to call it Nexus One in this release note cause no one knows what a "mahimahi" is .. I would like to call it Nexus One all over, but I can't because Google uses the name mahimahi.. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: Fix trout build failure with ci13xxx_msm gadget
On Fri, 2011-02-04 at 10:08 +0530, Pavankumar Kondeti wrote: > + This driver is not supported on boards like trout which > + has an external PHY. > What is an external PHY? Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the msm tree with the arm tree
On Fri, 2011-02-04 at 17:42 +, Russell King wrote: > So you tell me - do I take the p2v stuff out of public view tonight > because it's not stable, and therefore you don't even know about the > conflict? > > Or do I continue publishing the unstable changes so that people have > the ability to see what's going on in my tree and find potential > conflicts? > > I really don't care which - but I'll warn you that keeping changes > hidden will result in a reduction of patch quality, and much much > much less testing of those changes. And I won't care at all when you > complain that MSM's broken because of one of my patches. > > Exactly what would you prefer? I'm not really opposed to any of your objectives. What it sounds like is that you have a "stable" branch, and an "unstable" branch. Both branches are in linux-next , and we're seeing conflicts from the unstable one. Is that accurate? I think we can deal with the issues as long as you have one branch that you don't rebase, and things eventually move into that branch. So if we have a conflict then we can base our tree on your stable branch , and have confidence that your not rebasing it, or merge that into our tree. I think the problem is that when you say your rebase it's not clear if your rebasing all your branches, or if you only rebasing one unstable branch.. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the msm tree with the arm tree
On Wed, 2011-02-02 at 16:47 -0500, Nicolas Pitre wrote: > The actual problem here is that some people, notably the msm folks, > are > bypassing the maintainer hierarchy and going straight to Linus for > their > pull requests instead of asking RMK to pull. We once debated this at I don't think it's fair to single out MSM here. Going straight to Linus was discussed at one point, as I recall, and Russell didn't oppose it at the time. There are a number of ARM sub-architecture maintainers that do this.. None of that is related to the rejects created here, those would happen no matter who we submitted pull requests to. I think the issue is more that MSM is actively being cleanup , and Russell is touching code that we're working on also. So we need a way to work together .. In this case the collision is so simple that either Linus or Russell would just fix it up while pulling, and both would likely be fine with that. In the past I've tried to fix up these issues, but now I think maybe it's doesn't matter. In terms of Russell rebasing, I don't really like that. I've based MSM trees on Russell's stable branch and it's worked in the past. If Russell's rebasing then we can't really do that, so one tool to fix these problems is gone. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: msm gadget compilation failure with trout
On Fri, 2011-01-28 at 12:31 +0530, Pavan Kondeti wrote: > Hi Denis, > > On 1/28/2011 2:56 AM, Daniel Walker wrote: > > On Thu, 2011-01-27 at 22:12 +0100, Denis 'GNUtoo' Carikli wrote: > >> Hi, > >> > >> I've that: > >> drivers/usb/gadget/ci13xxx_msm.c: In function > >> 'ci13xxx_msm_notify_event': > >> drivers/usb/gadget/ci13xxx_msm.c:42:3: error: 'USB_AHBBURST' undeclared > >> (first use in this function) > >> drivers/usb/gadget/ci13xxx_msm.c:42:3: note: each undeclared identifier > >> is reported only once for each function it appears in > >> drivers/usb/gadget/ci13xxx_msm.c:43:3: error: 'USB_AHBMODE' undeclared > >> (first use in this function) > >> make[2]: *** [drivers/usb/gadget/ci13xxx_msm.o] Error 1 > >> make[1]: *** [drivers/usb/gadget] Error 2 > >> make[1]: *** Waiting for unfinished jobs > >> > >> here's my setup: > >> * linux-next/master > >> ( git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git ) at > >> 47db3d1b0b3d69c6e977158ac354a972b81677bd > >> * trout(also known as htc dream or G1) board > >> > >> Should I include my defconfig? > >> Should I include more details? > >> Am I using the gadget wrong driver? > >> > > AHBMODE register offset is different for trout and AHBBURST register is > not present in trout. > > MSM gadget driver is supported only for QSD8x50 and MSM7x30 boards. USB > support is not added for trout which uses an external PHY unlike the > other targets. Please disable USB support in your defconfig. If it's not supported don't allow it to be compiled, but you need to make some sort of fix for this. btw, if it's not support why is there a 7X01 define used in the header ? Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: msm gadget compilation failure with trout
On Thu, 2011-01-27 at 22:12 +0100, Denis 'GNUtoo' Carikli wrote: > Hi, > > I've that: > drivers/usb/gadget/ci13xxx_msm.c: In function > 'ci13xxx_msm_notify_event': > drivers/usb/gadget/ci13xxx_msm.c:42:3: error: 'USB_AHBBURST' undeclared > (first use in this function) > drivers/usb/gadget/ci13xxx_msm.c:42:3: note: each undeclared identifier > is reported only once for each function it appears in > drivers/usb/gadget/ci13xxx_msm.c:43:3: error: 'USB_AHBMODE' undeclared > (first use in this function) > make[2]: *** [drivers/usb/gadget/ci13xxx_msm.o] Error 1 > make[1]: *** [drivers/usb/gadget] Error 2 > make[1]: *** Waiting for unfinished jobs > > here's my setup: > * linux-next/master > ( git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git ) at > 47db3d1b0b3d69c6e977158ac354a972b81677bd > * trout(also known as htc dream or G1) board > > Should I include my defconfig? > Should I include more details? > Am I using the gadget wrong driver? > > Denis. Looks like it was cause by this commit, commit e0c201f339fe7fc38d1b0f6f4755ff627686c7e0 Author: Pavankumar Kondeti Date: Tue Dec 7 17:53:55 2010 +0530 USB: Add MSM OTG Controller driver This driver implements PHY initialization, clock management, ULPI IO ops and simple OTG state machine to kick host/peripheral based on Id/VBUS line status. VBUS/Id lines are tied to a reference voltage on some boards. Hence provide debugfs interface to select host/peripheral mode. Signed-off-by: Pavankumar Kondeti Signed-off-by: Greg Kroah-Hartman I CC'd the people in the commit.. I have no idea what those values are support to be. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] msm: Clean up useless ifdefs
On Thu, 2011-01-27 at 12:13 -0800, Stepan Moskovchenko wrote: > Remove ifdefs that do nothing, either from having the code > between them previously removed, or from having been > accidentally added to the wrong file. > > Change-Id: I94aac2cb24e23ba7f8b4b158ce6653dc3b786989 > Signed-off-by: Stepan Moskovchenko You need to drop the Change-Id: .. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] msm: smd: Add smd_pkt driver
On Wed, 2011-01-26 at 15:32 -0800, Andrew Morton wrote: > On Tue, 25 Jan 2011 11:20:51 -0800 > David Brown wrote: > > > On Wed, Dec 15 2010, Niranjana Vishwanathapura wrote: > > > > > Add smd_pkt driver which provides device interface > > > to smd packet ports. > > > > > > Signed-off-by: Niranjana Vishwanathapura > > > --- > > > drivers/char/Kconfig |8 + > > > drivers/char/Makefile |2 + > > > drivers/char/msm_smd_pkt.c | 466 > > > > > > 3 files changed, 476 insertions(+), 0 deletions(-) > > > create mode 100644 drivers/char/msm_smd_pkt.c > > > > Andrew, what's the proper destination for this change? Should this go > > into your tree? Is there anything you want me to do with this change? > > > > Looks OK, I grabbed it. > > I read the entire email trying to work out what an "SMD" is. Failed. > Oh well. + bool "MSM Shared Memory Driver (SMD)" + help + Support for the shared memory interface between the apps + processor and the baseband processor. Provides access to + the "shared heap", as well as virtual serial channels + used to communicate with various services on the baseband + processor. It's an an interface from the cpu running Linux, and the other processor that co-exists with the one running Linux. They need to communicate for certain reasons .. I _think_ something like sending a text message is sent by communicating over this interface, or getting the phone to dial a number, along with many other things. Thats my take on it anyway. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] msm: clock: Add support for more proc_comm clocks
On Wed, 2011-01-26 at 14:03 -0800, David Brown wrote: > On Tue, Jan 25 2011, Daniel Walker wrote: > > > On Mon, 2011-01-24 at 19:45 -0800, Stephen Boyd wrote: > >> Support the CE_CLK and CODEC_SSBI_CLK. Also add support for uart, > >> and i2c clocks on targets which support proc_comm clocks. > > > > Basically when you catch yourself writing "also" in the commit text you > > need to re-evaluate making two patches.. In this case it looks > > appropriate.. > > Or it is just an argument to not use the word also in the commit text. > I don't think it's really necessary to split up a patch that adds a few > clocks to the clock table. This one it actually makes a lot of sense to break it up. He's doing some very different things here all in the same patch .. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] msm: clock: Remove unused code and definitions
On Wed, 2011-01-26 at 14:01 -0800, David Brown wrote: > On Tue, Jan 25 2011, Daniel Walker wrote: > > > On Tue, 2011-01-25 at 13:52 -0800, Saravana Kannan wrote: > >> On 01/25/2011 01:38 PM, Daniel Walker wrote: > >> > On Mon, 2011-01-24 at 19:45 -0800, Stephen Boyd wrote: > >> >> Remove dead code and push out clock-7x30.h and clock-pcom.h to > >> >> where they are actually used. > >> >> > >> > > >> > I'd do two patches for this. The stuff your doing is too disconnected. > >> > > >> > Daniel > >> > > >> There is a whole bunch of unused code in the clock files and it's being > >> deleted. I don't see a point of splitting it up per file. > > > > It's easier to review when changes aren't merged that don't related to > > each other. > > In this particular case, the patch is a bunch of removal of dead code, > and kind of makes sense to keep it together. I'm fine with it as is. He's adding stuff too .. So it's not _just_ removal which is what I was getting at. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] msm: clock: Remove unused code and definitions
On Tue, 2011-01-25 at 13:52 -0800, Saravana Kannan wrote: > On 01/25/2011 01:38 PM, Daniel Walker wrote: > > On Mon, 2011-01-24 at 19:45 -0800, Stephen Boyd wrote: > >> Remove dead code and push out clock-7x30.h and clock-pcom.h to > >> where they are actually used. > >> > > > > I'd do two patches for this. The stuff your doing is too disconnected. > > > > Daniel > > > There is a whole bunch of unused code in the clock files and it's being > deleted. I don't see a point of splitting it up per file. It's easier to review when changes aren't merged that don't related to each other. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] msm: clock: Add support for more proc_comm clocks
On Mon, 2011-01-24 at 19:45 -0800, Stephen Boyd wrote: > Support the CE_CLK and CODEC_SSBI_CLK. Also add support for uart, > and i2c clocks on targets which support proc_comm clocks. Basically when you catch yourself writing "also" in the commit text you need to re-evaluate making two patches.. In this case it looks appropriate.. I'd do CE_CLK and CODEC_SSBI_CLK in one, with the increment for the number of clocks, and adding those two clocks. Then the rest of it I'm not sure. If it was me I'd break out uart and i2c in different patches but that might be overkill. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] msm: clock: Remove unused code and definitions
On Mon, 2011-01-24 at 19:45 -0800, Stephen Boyd wrote: > Remove dead code and push out clock-7x30.h and clock-pcom.h to > where they are actually used. > I'd do two patches for this. The stuff your doing is too disconnected. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/11] msm: Add CPU queries
On Tue, 2011-01-25 at 11:45 -0800, David Brown wrote: > On Tue, Jan 25 2011, Daniel Walker wrote: > > > On Tue, 2011-01-25 at 11:17 -0800, David Brown wrote: > > > I suggesting we do it across the board because consistency is a good > > thing .. It also allows us to use 8x60 when 8660 and 8960 are actually > > similar .. You can't deny that 8960 is similar to 8660 because your > > patches show some duplication due to it. > > You're completely missing the point of these tests. If _anything_ is > different, the macros need to be different. I don't care if they're > similar, I need to know when they are different. That is the point of > the macros. I said you would have macros specifically for 8660 and 8960, so if you need to know when they're different then you have macro's to do that. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/11] msm: Add CPU queries
On Tue, 2011-01-25 at 11:17 -0800, David Brown wrote: > On Tue, Jan 25 2011, Daniel Walker wrote: > > > On Mon, 2011-01-24 at 16:57 -0800, David Brown wrote: > >> MSM7201 and MSM7601 are identical as far as Linux is concerned. Same > >> goes for MSM8250 and MSM8650. Our dev boards are a somewhat random mix > >> of the two, and it doesn't matter which one you use. > >> > >> MSM8960 is a completely different chip, it just shares a similar name, > >> to other chips. > > > > If you break it down without the "x" then you can recreate the "x" > > variant with the actual numerical identifier .. For 8660/8960 you just > > would do as much of a unification as with the others.. You could still > > use 8x60 to identify those two, you just wouldn't use it as often. > > There isn't any unification to do here. There are two issues. We make > some chips in groups where we have _identical_ silicon on the Linux > side, but happen to have different numbers. That's what the X is > about. There are other cases where we have completely different silicon > that happen to have similar numbers. > > The whole point of the cpu_is tests is to tell us exactly which chip we > are on. If there is _anything_ different between two chips, that query > needs to be different. If there is any kind of unification, it can be > done at a higher level. Otherwise, you have no way of making the > distinction that needs to be made. I suggesting we do it across the board because consistency is a good thing .. It also allows us to use 8x60 when 8660 and 8960 are actually similar .. You can't deny that 8960 is similar to 8660 because your patches show some duplication due to it. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 20/32] video/msm_fb: use system_wq instead of dedicated workqueues
On Tue, 2011-01-25 at 11:14 -0800, David Brown wrote: > On Tue, Jan 25 2011, Daniel Walker wrote: > > > On Tue, 2011-01-25 at 14:45 +0100, Tejun Heo wrote: > >> On Mon, Jan 03, 2011 at 10:10:45AM -0800, Daniel Walker wrote: > >> > On Mon, 2011-01-03 at 18:06 +0100, Stanislaw Gruszka wrote: > >> > > On Mon, Jan 03, 2011 at 02:49:43PM +0100, Tejun Heo wrote: > >> > > > With cmwq, there's no reason to use separate workqueues. Drop > >> > > > msmfb_info->resume_workqueue and use system_wq instead. > >> > > > > >> > > > Signed-off-by: Tejun Heo > >> > > > Cc: Stanislaw Gruszka > >> > > I'm not the right person, CC according to MAINTAINERS > >> > > >> > ARM/QUALCOMM MSM MACHINE SUPPORT > >> > M: David Brown > >> > M: Daniel Walker > >> > M: Bryan Huntsman > >> > >> Oops, sorry about that. So how does the patch look? Are you gonna > >> take it through msm tree or shall I take it? > > > > David ? > > > > Daniel > > Is it difficult for you to test this change, Daniel? I can pull it in > once we verify it still works. Carl V. can test it, and review it I think .. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 20/32] video/msm_fb: use system_wq instead of dedicated workqueues
On Tue, 2011-01-25 at 14:45 +0100, Tejun Heo wrote: > On Mon, Jan 03, 2011 at 10:10:45AM -0800, Daniel Walker wrote: > > On Mon, 2011-01-03 at 18:06 +0100, Stanislaw Gruszka wrote: > > > On Mon, Jan 03, 2011 at 02:49:43PM +0100, Tejun Heo wrote: > > > > With cmwq, there's no reason to use separate workqueues. Drop > > > > msmfb_info->resume_workqueue and use system_wq instead. > > > > > > > > Signed-off-by: Tejun Heo > > > > Cc: Stanislaw Gruszka > > > I'm not the right person, CC according to MAINTAINERS > > > > ARM/QUALCOMM MSM MACHINE SUPPORT > > M: David Brown > > M: Daniel Walker > > M: Bryan Huntsman > > Oops, sorry about that. So how does the patch look? Are you gonna > take it through msm tree or shall I take it? David ? Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/11] msm: Add CPU queries
On Mon, 2011-01-24 at 16:57 -0800, David Brown wrote: > On Mon, Jan 24 2011, Daniel Walker wrote: > > > On Mon, 2011-01-24 at 16:20 -0800, David Brown wrote: > >> On Mon, Jan 24 2011, Daniel Walker wrote: > >> > >> > On Wed, 2011-01-19 at 12:25 -0800, David Brown wrote: > >> >> +#define cpu_is_msm7x01() 0 > >> >> +#define cpu_is_msm7x30() 0 > >> >> +#define cpu_is_qsd8x50() 0 > >> >> +#define cpu_is_msm8x60() 0 > >> > > >> > Now that I look at this again, why not drop the "x" all together ? > >> > >> That might be better for the 8x60. The complexity is that most of the > >> MSM chips have some variants, where the CPU running Linux isn't changed, > >> but the modem CPU is different (think CDMA/UMTS). Until 8960, that was > >> distinguished by the second letter. > >> > >> Either way doesn't quite match reality, unfortunately. There are > >> devices using a MSM7201 and others using a MSM7601. As far as Linux is > >> concerned, there isn't any difference between them. If someone wanted > >> to try and identify the device they have with the code, it could be > >> confusing for either name chosen. > >> > >> I was planning on turning msm8x60 into msm8660, since that seems to be > >> the most common one. Perhaps the decoder ring should be put into the > >> help text for the options so people can at least figure out which is > >> which. > > > > Are there any of those which do , right now, have Linux support for more > > than one variant ? > > All of them, in fact. > > MSM7201 and MSM7601 are identical as far as Linux is concerned. Same > goes for MSM8250 and MSM8650. Our dev boards are a somewhat random mix > of the two, and it doesn't matter which one you use. > > MSM8960 is a completely different chip, it just shares a similar name, > to other chips. If you break it down without the "x" then you can recreate the "x" variant with the actual numerical identifier .. For 8660/8960 you just would do as much of a unification as with the others.. You could still use 8x60 to identify those two, you just wouldn't use it as often. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/11] msm: Add CPU queries
On Mon, 2011-01-24 at 16:20 -0800, David Brown wrote: > On Mon, Jan 24 2011, Daniel Walker wrote: > > > On Wed, 2011-01-19 at 12:25 -0800, David Brown wrote: > >> +#define cpu_is_msm7x01() 0 > >> +#define cpu_is_msm7x30() 0 > >> +#define cpu_is_qsd8x50() 0 > >> +#define cpu_is_msm8x60() 0 > > > > Now that I look at this again, why not drop the "x" all together ? > > That might be better for the 8x60. The complexity is that most of the > MSM chips have some variants, where the CPU running Linux isn't changed, > but the modem CPU is different (think CDMA/UMTS). Until 8960, that was > distinguished by the second letter. > > Either way doesn't quite match reality, unfortunately. There are > devices using a MSM7201 and others using a MSM7601. As far as Linux is > concerned, there isn't any difference between them. If someone wanted > to try and identify the device they have with the code, it could be > confusing for either name chosen. > > I was planning on turning msm8x60 into msm8660, since that seems to be > the most common one. Perhaps the decoder ring should be put into the > help text for the options so people can at least figure out which is > which. Are there any of those which do , right now, have Linux support for more than one variant ? Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/11] msm: Add CPU queries
On Wed, 2011-01-19 at 12:25 -0800, David Brown wrote: > +#define cpu_is_msm7x01() 0 > +#define cpu_is_msm7x30() 0 > +#define cpu_is_qsd8x50() 0 > +#define cpu_is_msm8x60() 0 Now that I look at this again, why not drop the "x" all together ? Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/11] msm: Generalize timer register mappings
On Mon, 2011-01-24 at 14:44 -0800, David Brown wrote:
> On Mon, Jan 24 2011, Daniel Walker wrote:
>
> > On Wed, 2011-01-19 at 12:25 -0800, David Brown wrote:
> >> + int global_offset = 0;
> >> +
> >> + if (cpu_is_msm7x01()) {
> >> + msm_clocks[MSM_CLOCK_GPT].regbase = MSM_CSR_BASE;
> >> + msm_clocks[MSM_CLOCK_DGT].regbase = MSM_CSR_BASE + 0x10;
> >> + } else if (cpu_is_msm7x30()) {
> >> + msm_clocks[MSM_CLOCK_GPT].regbase = MSM_CSR_BASE + 0x04;
> >> + msm_clocks[MSM_CLOCK_DGT].regbase = MSM_CSR_BASE + 0x24;
> >> + } else if (cpu_is_qsd8x50()) {
> >> + msm_clocks[MSM_CLOCK_GPT].regbase = MSM_CSR_BASE;
> >> + msm_clocks[MSM_CLOCK_DGT].regbase = MSM_CSR_BASE + 0x10;
> >> + } else if (cpu_is_msm8x60()) {
> >> + msm_clocks[MSM_CLOCK_GPT].regbase = MSM_TMR_BASE + 0x04;
> >> + msm_clocks[MSM_CLOCK_DGT].regbase = MSM_TMR_BASE + 0x24;
> >> +
> >> + /* Use CPU0's timer as the global timer. */
> >> + global_offset = MSM_TMR0_BASE - MSM_TMR_BASE;
> >> + } else
> >> + BUG();
> >
> > Ifdef's here would be OK I think, your already using the "runtime"
> > checks ..
>
> The point of the change is to get rid of the ifdefs so that we can
> dynamically detect which target we are on. Yes, there are other places
> where it doesn't work, but we'll get there gradually.
I'm not suggesting you do something you can't do right now ..
For instance you could make,
#define MSM_MSM7XXX_DGT_BASE (MSM_TMR_BASE + 0x10)
and use that instead of what you have above.
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/11] msm: irqs-8960: Interrupt map for MSM8960
On Wed, 2011-01-19 at 12:25 -0800, David Brown wrote: > +#define INT_VGIC (GIC_PPI_START + 0) > +#define INT_DEBUG_TIMER_EXP(GIC_PPI_START + 1) > +#define INT_GP_TIMER_EXP (GIC_PPI_START + 2) > +#define INT_GP_TIMER2_EXP (GIC_PPI_START + 3) > +#define WDT0_ACCSCSSNBARK_INT (GIC_PPI_START + 4) > +#define WDT1_ACCSCSSNBARK_INT (GIC_PPI_START + 5) > +#define AVS_SVICINT(GIC_PPI_START + 6) > +#define AVS_SVICINTSWDONE (GIC_PPI_START + 7) > +#define CPU_DBGCPUXCOMMRXFULL (GIC_PPI_START + 8) > +#define CPU_DBGCPUXCOMMTXEMPTY (GIC_PPI_START + 9) > +#define CPU_SICCPUXPERFMONIRPTREQ (GIC_PPI_START + 10) > +#define SC_AVSCPUXDOWN (GIC_PPI_START + 11) > +#define SC_AVSCPUXUP (GIC_PPI_START + 12) > +#define SC_SICCPUXACGIRPTREQ (GIC_PPI_START + 13) > +#define SC_SICCPUXEXTFAULTIRPTREQ (GIC_PPI_START + 14) > +/* PPI 15 is unused */ How are you handling this at runtime? Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/11] msm: Generalize timer register mappings
On Wed, 2011-01-19 at 12:25 -0800, David Brown wrote:
> + int global_offset = 0;
> +
> + if (cpu_is_msm7x01()) {
> + msm_clocks[MSM_CLOCK_GPT].regbase = MSM_CSR_BASE;
> + msm_clocks[MSM_CLOCK_DGT].regbase = MSM_CSR_BASE + 0x10;
> + } else if (cpu_is_msm7x30()) {
> + msm_clocks[MSM_CLOCK_GPT].regbase = MSM_CSR_BASE + 0x04;
> + msm_clocks[MSM_CLOCK_DGT].regbase = MSM_CSR_BASE + 0x24;
> + } else if (cpu_is_qsd8x50()) {
> + msm_clocks[MSM_CLOCK_GPT].regbase = MSM_CSR_BASE;
> + msm_clocks[MSM_CLOCK_DGT].regbase = MSM_CSR_BASE + 0x10;
> + } else if (cpu_is_msm8x60()) {
> + msm_clocks[MSM_CLOCK_GPT].regbase = MSM_TMR_BASE + 0x04;
> + msm_clocks[MSM_CLOCK_DGT].regbase = MSM_TMR_BASE + 0x24;
> +
> + /* Use CPU0's timer as the global timer. */
> + global_offset = MSM_TMR0_BASE - MSM_TMR_BASE;
> + } else
> + BUG();
Ifdef's here would be OK I think, your already using the "runtime"
checks ..
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/11] msm: Add MSM 8960 cpu_is check
On Mon, 2011-01-24 at 14:13 -0800, David Brown wrote: > On Mon, Jan 24 2011, Daniel Walker wrote: > > >> What do you want me to call it? > >> > >> #define cpu_is_97d0c886-3768-4998-8925-16f36209d0d1() > > > > I want you to call it msm8x60 .. > > msm8960 is not a subset of msm8x60. It's just a misleading name. It's > a very different device, and needs it's own identifier. Can you site reason why it's different .. My impression is that it's not as different as you think it is. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/11] msm: io: I/O register definitions for MSM8960
On Mon, 2011-01-24 at 13:31 -0800, David Brown wrote: > On Mon, Jan 24 2011, Daniel Walker wrote: > > > On Wed, 2011-01-19 at 12:25 -0800, David Brown wrote: > >> +/* > >> + * Copyright (C) 2007 Google, Inc. > >> + * Copyright (c) 2008-2011, Code Aurora Forum. All rights reserved. > >> + * Author: Brian Swetland > > > > Brian didn't really write this did he? > > He wrote the code it is based off of. The author line could probably be > removed. I think it's kind of like a total re-write.. So I'd assume removing him is acceptable, besides he likely doesn't want to get email asking questions about this thing he's never seen. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/11] msm: Add MSM 8960 cpu_is check
On Mon, 2011-01-24 at 13:30 -0800, David Brown wrote: > On Mon, Jan 24 2011, Daniel Walker wrote: > > > On Wed, 2011-01-19 at 12:25 -0800, David Brown wrote: > >> diff --git a/arch/arm/mach-msm/include/mach/cpu.h > >> b/arch/arm/mach-msm/include/mach/cpu.h > >> index e1ba9db..a9481b0 100644 > >> --- a/arch/arm/mach-msm/include/mach/cpu.h > >> +++ b/arch/arm/mach-msm/include/mach/cpu.h > >> @@ -24,6 +24,7 @@ > >> #define cpu_is_msm7x30() 0 > >> #define cpu_is_qsd8x50() 0 > >> #define cpu_is_msm8x60() 0 > >> +#define cpu_is_msm8960() 0 > > > > The naming is just perverted even more here.. > > What do you want me to call it? > > #define cpu_is_97d0c886-3768-4998-8925-16f36209d0d1() I want you to call it msm8x60 .. > It's the name of the chip. We've already been through this. The names > are unfortunate, but it is what the devices are called. I think you can re-org things to mask all this.. I've been suggesting is that we look into that .. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/11] msm: io: I/O register definitions for MSM8960
On Wed, 2011-01-19 at 12:25 -0800, David Brown wrote: > +/* > + * Copyright (C) 2007 Google, Inc. > + * Copyright (c) 2008-2011, Code Aurora Forum. All rights reserved. > + * Author: Brian Swetland Brian didn't really write this did he? Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/11] msm: Add MSM 8960 cpu_is check
On Wed, 2011-01-19 at 12:25 -0800, David Brown wrote: > diff --git a/arch/arm/mach-msm/include/mach/cpu.h > b/arch/arm/mach-msm/include/mach/cpu.h > index e1ba9db..a9481b0 100644 > --- a/arch/arm/mach-msm/include/mach/cpu.h > +++ b/arch/arm/mach-msm/include/mach/cpu.h > @@ -24,6 +24,7 @@ > #define cpu_is_msm7x30() 0 > #define cpu_is_qsd8x50() 0 > #define cpu_is_msm8x60() 0 > +#define cpu_is_msm8960() 0 The naming is just perverted even more here.. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Nexus One Support
On Fri, 2011-01-21 at 20:58 -0500, Steven Rostedt wrote: > On Fri, Jan 21, 2011 at 04:03:13PM -0800, Daniel Walker wrote: > > > > right, but it wasn't a cherrypick which was explain in the thread. So > > there's no wrongs here .. > > I'm sorry Daniel, but you are absolutely wrong! This thread is getting way out of hand .. I think you really don't understand what has happened here.. That's fine tho, if you don't like what I've done then NAK, I'm not going to argue with any you. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Nexus One Support
On Fri, 2011-01-21 at 18:49 -0500, Ted Ts'o wrote: > On Fri, Jan 21, 2011 at 11:05:54PM +0200, Pekka Enberg wrote: > > > > On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker > > wrote: > > > I'll add this list into the commit text .. > > > > So why is everyone bitching at Daniel when he's doing something the > > Android folks should have done themselves a long time ago? > > Two wrongs don't make a right. And it's not like not submitting > changes is wrong, although granted it's not ideal. (I'd say removing > attribution from a git commit is even worse. If you're doing the > equivalent of a cherry pick, you should preserve the Author field. right, but it wasn't a cherrypick which was explain in the thread. So there's no wrongs here .. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Nexus One Support
On Fri, 2011-01-21 at 13:01 -0800, Jesse Barnes wrote: > On Fri, 21 Jan 2011 12:49:55 -0800 > Daniel Walker wrote: > > > On Fri, 2011-01-21 at 12:44 -0800, Dima Zavin wrote: > > > Really though? Let's look at one of them: > > > > > > > > 2 Arve Hjønnevåg > > > 6 Brian Swetland > > > 14 Dima Zavin > > > 2 Haley Teng > > > 1 Iliyan Malchev > > > 5 Mike Chan > > > > I'll add this list into the commit text .. > > Sounds like a good example of a patch where you should preserve the > author field as well. preserve it as who ? Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Nexus One Support
On Fri, 2011-01-21 at 13:02 -0800, Joe Perches wrote: > On Fri, 2011-01-21 at 12:49 -0800, Daniel Walker wrote: > > On Fri, 2011-01-21 at 12:44 -0800, Dima Zavin wrote: > > > Really though? Let's look at one of them: > > > 2 Arve Hjønnevåg > > > 6 Brian Swetland > > > 14 Dima Zavin > > > 2 Haley Teng > > > 1 Iliyan Malchev > > > 5 Mike Chan > > I'll add this list into the commit text .. > > I think it'd be better if you pull them into a > git repository, then use either: > git format-patch > git send-email > or > git request-pull > > That way no author history is lost. The history isn't upstreamable .. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Nexus One Support
On Fri, 2011-01-21 at 12:44 -0800, Dima Zavin wrote: > Really though? Let's look at one of them: > > 2 Arve Hjønnevåg > 6 Brian Swetland > 14 Dima Zavin > 2 Haley Teng > 1 Iliyan Malchev > 5 Mike Chan I'll add this list into the commit text .. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: msm: fix dma usage not to use internal APIs
On Fri, 2011-01-21 at 19:28 +, Russell King - ARM Linux wrote: > Again, why don't you talk about these problems on the architecture > list > rather than keeping it to your self. > > This is one of the *biggest* problems I have with people setting up > per- > platform mailing lists. It hides information from the rest of the > community > and causes idiotic practices and abuses such as has happened here. I don't think this was discussed on any list .. It was done prior to QuiC involvement in the community .. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
