gmane.linux.ports.arm.msm

Re: [PATCH v2 1/2] clk: Disable unused clocks after deferred probing is done

Jean-Christophe PLAGNIOL-VILLARD — 2013-05-22T10:35:25

so this feature is nightmare we need to KILL it

Best Regards,
J.

[PATCH 0/3] Cleanup MSM_GPIOMUX and add device-tree support for

Rohit Vaswani — 2013-05-21T18:32:40

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

[PATCH] ARM: dts: msm: Fix bad register addresses

Stephen Boyd — 2013-05-21T00:50:37

Some bad copy/paste got in as well as too many zeroes. Fix
everything up so that the registers after the < at > sign are
consistent with the first reg property.

Signed-off-by: Stephen Boyd <sboyd< at >codeaurora.org>
---
 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
< at >< at > -15,7 +15,7 < at >< at >
       < 0x02081000 0x1000 >;
 };
 
-timer< at >2000004 {
+timer< at >2000000 {
 compatible = "qcom,scss-timer", "qcom,msm-timer";
 interrupts = <1 0 0x301>,
      <1 1 0x301>,
< at >< at > -26,7 +26,7 < at >< at >
 cpu-offset = <0x40000>;
 };
 
-serial< at >19c400000 {
+serial< at >19c40000 {
 compatible = "qcom,msm-hsuart", "qcom,msm-uart";
 reg = <0x19c40000 0x1000>,
       <0x19c00000 0x1000>;
diff --git a/arch/arm/boot/dts/msm8960-cdp.dts b/arch/arm/boot/dts/msm896

Re: [PATCHv6 03/11] ARM: smp: Remove duplicate dummy timer implementation

Stephen Boyd — 2013-05-20T21:55:54

Russell, can you please ack this patch and patch #11?

Re: Would like to form a pool of Linux copyright holders for faster GPL enforcement against Anthrax Kernels

Bradley M. Kuhn — 2013-05-20T15:13:00

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,

[PATCH 1/1] diag: fix userspace read-write freeze during high logging rates

Kasidit Yusuf — 2013-05-20T08:17:39

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

Would like to form a pool of Linux copyright holders for faster GPL enforcement against Anthrax Kernels

Eric Appleman — 2013-05-18T08:21:13

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

Re: [PATCH v2] clk: Fix race condition between clk_set_parent and clk_enable()

Saravana Kannan — 2013-05-16T21:31:23

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

Re: [PATCH v2] clk: Fix race condition between clk_set_parent and clk_enable()

Mike Turquette — 2013-05-16T20:44:55

Quoting Saravana Kannan (2013-05-15 21:07:24)

Updated to this version in clk-next.

Thanks,
Mike

Re: [PATCH v2 1/2] clk: Disable unused clocks after deferred probing is done

Saravana Kannan — 2013-05-16T19:23:12

No, we are just reordering the steps.

-Saravana

Re: [PATCH v2 1/2] clk: Disable unused clocks after deferred probing is done

Ulf Hansson — 2013-05-16T12:55:46

Without giving this too much thinking... Will boot time be affected
with this change?

Kind regards
Ulf Hansson

Re: [PATCH v2 1/2] clk: Disable unused clocks after deferred probing is done

Saravana Kannan — 2013-05-16T04:34:03

Mike,

Thoughts? Picking it up? Removing the existing auto-disable code (I 
think they are still useful)?

-Saravana

[PATCH v2] clk: Fix race condition between clk_set_parent and clk_enable()

Saravana Kannan — 2013-05-16T04:07:24

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: <snip execution flow>
* 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

Re: [PATCH] ARM: avoid mis-detecting some V7 cores in the decompressor

Stephen Boyd — 2013-05-15T19:38:12

Ping?

Re: [PATCH] clk: Fix race condition between clk_set_parent and clk_enable()

Ulf Hansson — 2013-05-15T19:24:48

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 <ulf.hansson< at >linaro.org>

Re: [PATCHv2] arm: mm: Use phys_addr_t properly for ioremapfunctions

Russell King - ARM Linux — 2013-05-15T16:48:54

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.

Re: [PATCHv2] arm: mm: Use phys_addr_t properly for ioremap functions

Arnd Bergmann — 2013-05-15T14:15:39

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

Re: [PATCH 11/20] ARM: shmobile: sh73a0: Remove init_irq declaration in machine description

Simon Horman — 2013-05-15T01:48:42

Queued up for v3.11 in the soc-sh73a0 branch of my renesas tree
on kernel.org. It is included in the renesas-next-20130515 tag of
that tree and should appear in linux-next in the not to distant future.

Re: [PATCH 05/20] ARM: shmobile: ape6evm: Remove init_irq declaration in machine description

Simon Horman — 2013-05-15T00:59:07

Signed-off-by: Simon Horman <horms+renesas< at >verge.net.au>

Re: [PATCH] clk: Fix race condition between clk_set_parent and clk_enable()

Tomasz Figa — 2013-05-15T00:10:10

This is not exactly what I meant. I was just giving an example problem of 
turning a clock on, if it's not set up correctly yet.

AFAIK most (if not all) of current code either does necessary reparenting 
and initial rate setting early, before clk_prepare(), so it is not a 
problem or already after clk_enable() (in case of reparenting dynamically 
at runtime), so there shouldn't be any problem.

Best regards,
Tomasz

Re: [PATCH] clk: Fix race condition between clk_set_parent and clk_enable()

Saravana Kannan — 2013-05-14T22:46:33

Reasonable request. I can update the documentation of clk_set_parent() 
to indicate that the clock might get turned on for the duration of the 
call and if they need a guarantee the GATE flag should be used.


I don't think this is really a problem with this patch. It's present 
even without this patch.

The patch doesn't switch to some other unspecified parent. It only 
switches between the new/old parent. Even without this patch, if a clock 
is prepared while you reparent it, clk_enable() could be called at 
anytime between the parent switch and the future clock API calls to set 
up the new parent correctly. I think that's just crappy driver code to 
switch to a new parent before setting it up correctly. There's 
absolutely no good reason to do it that way.

-Saravana