http://permalink.gmane.org/gmane.linux.ports.arm.msm hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.ports.arm.msm/4041 <pre>Remove gpiomux-v2 as it's not being used and make way for future improvements. Signed-off-by: Rohit Vaswani &lt;rvaswani&lt; at &gt;codeaurora.org&gt; --- arch/arm/mach-msm/Kconfig | 13 +++----- arch/arm/mach-msm/Makefile | 6 +-- arch/arm/mach-msm/gpiomux-8x60.c | 19 ------------ arch/arm/mach-msm/gpiomux-v2.c | 25 --------------- arch/arm/mach-msm/gpiomux-v2.h | 61 -------------------------------------- arch/arm/mach-msm/gpiomux.c | 15 +++++++++ arch/arm/mach-msm/gpiomux.h | 5 --- drivers/gpio/gpio-msm-v2.c | 5 +-- 8 files changed, 24 insertions(+), 125 deletions(-) delete mode 100644 arch/arm/mach-msm/gpiomux-8x60.c delete mode 100644 arch/arm/mach-msm/gpiomux-v2.c delete mode 100644 arch/arm/mach-msm/gpiomux-v2.h diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index fceb093..614e41e 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig &lt; at &gt;&lt; at &gt; -48,9 +48,7 &lt; at &gt;&lt; at &gt; config ARCH_MSM8X60 select CPU_V7 select GPIO_MSM_V2 select HAV</pre> Rohit Vaswani 2013-05-23T00:29:22 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4040 <pre>Hi Linus, Could this series go through David's tree or is there a better way to do this? It would be great if I can have you ack for the gpio patch. Thanks, Rohit Rohit Vaswani (3): ARM: msm: Remove gpiomux-v2 and re-organize MSM_GPIOMUX configs ARM: msm: Remove unused and unmapped MSM_TLMM_BASE for 8x60 gpio: msm: Add device tree and irqdomain support for gpio-msm-v2 .../devicetree/bindings/gpio/gpio-msm.txt | 26 +++ arch/arm/boot/dts/msm8660-surf.dts | 11 ++ arch/arm/boot/dts/msm8960-cdp.dts | 11 ++ arch/arm/mach-msm/Kconfig | 13 +- arch/arm/mach-msm/Makefile | 6 +- arch/arm/mach-msm/gpiomux-8x60.c | 19 -- arch/arm/mach-msm/gpiomux-v2.c | 25 --- arch/arm/mach-msm/gpiomux-v2.h | 61 ------- arch/arm/mach-msm/gpiomux.c | 15 ++ arch/arm/mach-msm/gpiomux.h | 5 - arch/arm/mach-ms</pre> Rohit Vaswani 2013-05-23T00:29:21 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4039 <pre> See this commit: commit b1608d69cb804e414d0887140ba08a9398e4e638 Author: Grant Likely &lt;grant.likely&lt; at &gt;secretlab.ca&gt; Date: Wed May 18 11:19:24 2011 -0600 drivercore: revert addition of of_match to struct device Commit b826291c, "drivercore/dt: add a match table pointer to struct device" added an of_match pointer to struct device to cache the of_match_table entry discovered at driver match time. This was unsafe because matching is not an atomic operation with probing a driver. If two or more drivers are attempted to be matched to a driver at the same time, then the cached matching entry pointer could get overwritten. This patch reverts the of_match cache pointer and reworks all users to call of_match_device() directly instead. Signed-off-by: Grant Likely &lt;grant.likely&lt; at &gt;secretlab.ca&gt; </pre> Rob Herring 2013-05-22T21:27:55 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4036 <pre>Sending this as an RFC with one driver converted to see what people think. The goal is to avoid having to run the match twice and be similar to how platform_device_id works right now. If people agree I can go through and send out patches for all the drivers doing the duplicate search (~100 files). Stephen Boyd (2): of: Assign of_device_id to matching device_node gpio/omap: Use of_node-&gt;id_entry directly drivers/gpio/gpio-omap.c | 4 +--- drivers/of/device.c | 18 ++++++++++++++++++ include/linux/of.h | 1 + include/linux/of_device.h | 12 ++---------- 4 files changed, 22 insertions(+), 13 deletions(-) </pre> Stephen Boyd 2013-05-22T20:40:15 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4035 <pre> so this feature is nightmare we need to KILL it Best Regards, J. </pre> Jean-Christophe PLAGNIOL-VILLARD 2013-05-22T10:35:25 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4032 <pre>Hi Linus, Could this series go through David's tree or is there a better way to do this? It would be great if I can have you ack for the gpio patch. Thanks, Rohit Rohit Vaswani (3): ARM: msm: Remove gpiomux-v2 and re-organize MSM_GPIOMUX configs ARM: msm: Remove unused and unmapped MSM_TLMM_BASE for 8x60 gpio: msm: Add device tree and irqdomain support for gpio-msm-v2 .../devicetree/bindings/gpio/gpio-msm.txt | 26 ++++ arch/arm/boot/dts/msm8660-surf.dts | 11 ++ arch/arm/boot/dts/msm8960-cdp.dts | 11 ++ arch/arm/mach-msm/Kconfig | 13 +- arch/arm/mach-msm/Makefile | 6 +- arch/arm/mach-msm/gpiomux-8x60.c | 19 --- arch/arm/mach-msm/gpiomux-v2.c | 25 --- arch/arm/mach-msm/gpiomux-v2.h | 61 -------- arch/arm/mach-msm/gpiomux.c | 15 ++ arch/arm/mach-msm/gpiomux.h | 5 - arch/arm/mach</pre> Rohit Vaswani 2013-05-21T18:32:40 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4031 <pre>Some bad copy/paste got in as well as too many zeroes. Fix everything up so that the registers after the &lt; at &gt; sign are consistent with the first reg property. Signed-off-by: Stephen Boyd &lt;sboyd&lt; at &gt;codeaurora.org&gt; --- arch/arm/boot/dts/msm8660-surf.dts | 4 ++-- arch/arm/boot/dts/msm8960-cdp.dts | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/boot/dts/msm8660-surf.dts b/arch/arm/boot/dts/msm8660-surf.dts index 9bf49b3..d347082 100644 --- a/arch/arm/boot/dts/msm8660-surf.dts +++ b/arch/arm/boot/dts/msm8660-surf.dts &lt; at &gt;&lt; at &gt; -15,7 +15,7 &lt; at &gt;&lt; at &gt; &lt; 0x02081000 0x1000 &gt;; }; -timer&lt; at &gt;2000004 { +timer&lt; at &gt;2000000 { compatible = "qcom,scss-timer", "qcom,msm-timer"; interrupts = &lt;1 0 0x301&gt;, &lt;1 1 0x301&gt;, &lt; at &gt;&lt; at &gt; -26,7 +26,7 &lt; at &gt;&lt; at &gt; cpu-offset = &lt;0x40000&gt;; }; -serial&lt; at &gt;19c400000 { +serial&lt; at &gt;19c40000 { compatible = "qcom,msm-hsuart", "qcom,msm-uart"; reg = &lt;0x19c40000 0x1000&gt;, &lt;0x19c00000 0x1000&gt;; diff --git a/arch/arm/boot/dts/msm8960-cdp.dts b/arch/arm/boot/dts/msm896</pre> Stephen Boyd 2013-05-21T00:50:37 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4029 <pre> Russell, can you please ack this patch and patch #11? </pre> Stephen Boyd 2013-05-20T21:55:54 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4028 <pre>Eric Appleman wrote at 04:26 (EDT) on Saturday: As some on these lists likely already know, Conservancy's GPL Compliance Project for Linux Developers [0] is aware of this matter and is considering what actions to take, and how such actions should be ranked in priority given the queue of the hundreds of known GPL violations on Linux occurring every day. We very much appreciate that Eric has brought the matter to our attention and I'm continuing to correspond with Eric privately in the hopes that we can resolve the matter. If anyone wants to join Conservancy's GPL Compliance Project for Linux Developers, please do contact me! [0] More details on Conservancy's GPL Compliance Project for Linux Developers can be found at https://sfconservancy.org/news/2012/may/29/compliance/ Sincerely, </pre> Bradley M. Kuhn 2013-05-20T15:13:00 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4027 <pre>At very high diagchar logging rates (a HSPA+ ftp download with many instantaneous diag log response messages enabled) on quad-core phones, it was observed that after about 2 to 20 minutes (depends on logging rate) - the userspace read to /dev/diag would block, causing a freeze effect to the userspace program - and further attempts to log would randomly freeze at an earlier stage then a phone restart was required to do any meaningful logging. You can test this with "diag_mdlog", use a diag.cfg with high logging rate log_response_messages like 0x4222, 0x4179 and other fast logs. The patched kernel was tested on a "Google Nexus 4 with Android 4.2.2" (mako) phone - and had no more freezes even after 13 Hours of logging diag for over-night ftp tests, an older sister-kernel (essentially the same - but with many more pr_debug() to identify the causes) was also tested sucessfully on two other "Google Nexus 4" phones, one of them logged successfully through about 10 hours of fast ftp downloads - no freezes too. Thi</pre> Kasidit Yusuf 2013-05-20T08:17:39 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4025 <pre>Background on Anthrax Kernels and their GPL violation: http://pastebin.com/X5Cciy03 Would anyone be interested in forming such a pool? I am willing to wait years for this to be resolved through certain organizations, but I believe we can do better. Last I checked, I have 1 long-time poster of the gpl-violations list on board. Would anyone else like to join? Ideally I'd like to get the LKML (which I have CC'd among others) involved so that authors of critical Linux components be a part of this. I'm not sure if my defconfig commits to Android kernel branches count as contributions, so I'm not going to consider myself a Linux contributor unless told otherwise. This pool would be used in the following manner: * Formally requesting source for binaries (means to request source is actively hidden) * Formally requesting removal of critical copyrighted code that Linux cannot function without * Informing interested parties with respect to refusals of the above The CTO of Anthrax's hosting server is very </pre> Eric Appleman 2013-05-18T08:21:13 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4022 <pre> Thanks Mike. I forgot to add the Ack by Ulf. Would be nice if you can put that in. Btw, I did send this email to the list. But looks like this mail is wedged in the series of tubes in the arm mailing list. -Saravana </pre> Saravana Kannan 2013-05-16T21:31:23 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4021 <pre>Quoting Saravana Kannan (2013-05-15 21:07:24) Updated to this version in clk-next. Thanks, Mike </pre> Mike Turquette 2013-05-16T20:44:55 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4020 <pre> No, we are just reordering the steps. -Saravana </pre> Saravana Kannan 2013-05-16T19:23:12 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4019 <pre> Without giving this too much thinking... Will boot time be affected with this change? Kind regards Ulf Hansson </pre> Ulf Hansson 2013-05-16T12:55:46 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4015 <pre> Mike, Thoughts? Picking it up? Removing the existing auto-disable code (I think they are still useful)? -Saravana </pre> Saravana Kannan 2013-05-16T04:34:03 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4013 <pre>Without this patch, the following race condition is possible. * clk-A has two parents - clk-X and clk-Y. * All three are disabled and clk-X is current parent. * Thread A: clk_set_parent(clk-A, clk-Y). * Thread A: &lt;snip execution flow&gt; * Thread A: Grabs enable lock. * Thread A: Sees enable count of clk-A is 0, so doesn't enable clk-Y. * Thread A: Updates clk-A SW parent to clk-Y * Thread A: Releases enable lock. * Thread B: clk_enable(clk-A). * Thread B: clk_enable() enables clk-Y, then enabled clk-A and returns. clk-A is now enabled in software, but not clocking in hardware since the hardware parent is still clk-X. The only way to avoid race conditions between clk_set_parent() and clk_enable/disable() is to ensure that clk_enable/disable() calls don't require changes to hardware enable state between changes to software clock topology and hardware clock topology. The options to achieve the above are: 1. Grab the enable lock before changing software/hardware topology and release it afterwards. 2. Keep th</pre> Saravana Kannan 2013-05-16T04:07:24 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4012 <pre> Ping? </pre> Stephen Boyd 2013-05-15T19:38:12 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4011 <pre> Maybe an additional note about that since CLK_SET_PARENT_GATE is a prerequisite for doing migration of "prepare", we also interpreted this flags as it is acceptable to enable the clock(s) in this context. Really good, that we can remove this awkward error handling! Looks good! Thanks for having another round to fixup this kind of tricky code. :-) Acked-by: Ulf Hansson &lt;ulf.hansson&lt; at &gt;linaro.org&gt; </pre> Ulf Hansson 2013-05-15T19:24:48 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4008 <pre> Maybe there's a project there for someone to remove phys_addr_t or resource_size_t then - but I suspect Linus won't like the churn caused by that... So, let's just go by the one which takes less typing and save our fingers. phys_addr_t. </pre> Russell King - ARM Linux 2013-05-15T16:48:54 http://permalink.gmane.org/gmane.linux.ports.arm.msm/4007 <pre> Looks good to me. I wonder a bit whether resource_size_t or phys_addr_t is the right type here, but they are always defined to the same type these days. FWIW, x86 and tile use resource_size_t, while a couple of other architectures use phys_addr_t. Arnd </pre> Arnd Bergmann 2013-05-15T14:15:39 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.ports.arm.msm