perf: Fix perf_pmu_migrate_context

While auditing the list_entry usage due to a trinity bug I found that
perf_pmu_migrate_context violates the rules for
perf_event::event_entry.

The problem is that perf_event::event_entry is a RCU list element, and
hence we must wait for a full RCU grace period before re-using the
element after deletion.

Therefore the usage in perf_pmu_migrate_context() which re-uses the
entry immediately is broken. For now introduce another list_head into
perf_event for this specific usage.

This doesn't actually fix the trinity report because that never goes
through this code.

Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/n/tip-mkj72lxagw1z8fvjm648iznw@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
perf/x86: Clean up cap_user_time* setting

Currently the cap_user_time_zero capability has different tests than
cap_user_time; even though they expose the exact same data.

Switch from CONSTANT && NONSTOP to sched_clock_stable to also deal
with multi cabinet machines and drop the tsc_disabled() check.. non of
this will work sanely without tsc anyway.

Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/n/tip-nmgn0j0muo1r4c94vlfh23xy@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
ARM: OMAP3630: Add generic machine descriptor

https://patchwork.kernel.org/patch/2919661/

Add generic machine which can handle inits for omap3630.
Currently beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early

This defeats the purpose of having SoC specific init_early handlers,
example: clock nodes are not the same between 3430 and 3630.

Signed-off-by: Nishanth Menon <nm@ti.com>
perf tools: Add default handler for mmap2 events

Commands that do not implement an mmap2 handler should at least not die
with a segfault when processing files with MMAP2 events.

Signed-off-by: David Ahern <dsahern@gmail.com>
Link: http://lkml.kernel.org/r/1379900700-5186-5-git-send-email-dsahern@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
perf stat: Set child_pid after perf_evlist__prepare_workload()

The commit acf2892270dc ("perf stat: Use perf_evlist__prepare/
start_workload()") converted to use the function but forgot to update
child_pid.  Fix it.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1380531671-28076-1-git-send-email-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
perf tools: Fix libaudit test

In ubuntu systems the libaudit test was always failing due to the
newline in the printf call not being escaped, which somehow didn't
prevented the test from working as expected on other systems, such
as fedora18.

Fix it by removing the newline, as this is just a test, that program is
just a compile test.

The error messages, obtained using 'make V=1':

    CHK libaudit
<stdin>: In function ‘main’:
<stdin>:5:9: error: missing terminating " character [-Werror]
<stdin>:5:2: error: missing terminating " character
<stdin>:6:1: error: missing terminating " character [-Werror]
<stdin>:6:1: error: missing terminating " character
<stdin>:7:2: error: expected expression before ‘return’
<stdin>:8:1: error: expected ‘;’ before ‘}’ token
cc1: all warnings being treated as errors
config/Makefile:241: No libaudit.h found, disables 'trace' tool, please install audit-libs-devel or libaudit-dev

After this change the test works as expected in all systems tested and the
'trace' tool is built when the needed devel packages are installed.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-0trw8qs9hafeopc0vj1sicay@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
perf probe: Fix to find line information for probe list

Fix to find the correct (as much as possible) line information for
listing probes. Without this fix, perf probe --list action will show
incorrect line information as below;

  probe:getname_flags  (on getname_flags@ksrc/linux-3/fs/namei.c)
  probe:getname_flags_1 (on getname:-89@x86/include/asm/current.h)
  probe:getname_flags_2 (on user_path_at_empty:-2054@x86/include/asm/current.h)

The minus line number is obviously wrong, and current.h is not related
to the probe point. Deeper investigation discovered that there were 2
issues related to this bug, and minor typos too.

The 1st issue is the rack of considering about nested inlined functions,
which causes the wrong (relative) line number.

The 2nd issue is that the dwarf line info is not correct at those
points. It points 14th line of current.h.

Since it seems that the line info includes somewhat unreliable
information, this fixes perf to try to find correct line information
from both of debuginfo and line info as below.

1) Probe address is the entry of a function instance

  In this case, the line is set as the function declared line.

2) Probe address is the entry of an expanded inline function block

  In this case, the line is set as the function call-site line.
  This means that the line number is relative from the entry line
  of caller function (which can be an inlined function if nested)

3) Probe address is inside a function instance or an expanded
   inline function block

  In this case, perf probe queries the line number from lineinfo
  and verify the function declared file is same as the file name
  queried from lineinfo.

  If the file name is different, it is a failure case. The probe
  address is shown as symbol+offset.

4) Probe address is not in the any function instance

  This is a failure case, the probe address is shown as
  symbol+offset.

With this fix, perf probe -l shows correct probe lines as below;

  probe:getname_flags  (on getname_flags@ksrc/linux-3/fs/namei.c)
  probe:getname_flags_1 (on getname:2@ksrc/linux-3/fs/namei.c)
  probe:getname_flags_2 (on user_path_at_empty:4@ksrc/linux-3/fs/namei.c)

Changes at v2:
 - Fix typos in the function comments. (Thanks to Namhyung Kim)
 - Use die_find_top_inlinefunc instead of die_find_inlinefunc_next.

Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20130930092144.1693.11058.stgit@udc4-manage.rcp.hitachi.co.jp
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
perf tools: Fix installation of libexec components

Doing a fresh install on a user home directory needs to first make sure
that the ~/libexec/perf-core/ directory is present so that
'perf-archive' like scripts, 'perf test' attr config files and 'perf
script' scripts can be installed.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-z7ryi3r1b9dn9smbfnab0fdc@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
perf session: Fix infinite loop on invalid perf.data file

perf-record updates the header in the perf.data file at termination.
Without this update perf-report (and other processing built-ins) it
caused an infinite loop when perf report (or something like) called.

This is because the algorithm in __perf_session__process_events()
depends on the data_size which is read from file header.  Use file size
directly instead in this case to do the best-effort processing.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: David Ahern <dsahern@gmail.com>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Sonny Rao <sonnyrao@chromium.org>
Link: http://lkml.kernel.org/r/1380529188-27193-1-git-send-email-namhyung@kernel.org
Signed-off-by: David Ahern <dsahern@gmail.com>
[ Reworded warning as per Ingo Molnar suggestion, replaces 'perf.data'
  with session->filename, to precisely identify the data file involved ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Merge branch 'devel/beagle-work' of git://git.ti.com/~nmenon/ti-linux-kernel/platform-linux-feature-tree-nm into platform-ti-linux-3.12.y
ARM: OMAP2+: omap_hwmod: Use mpu_rt_idx instead of default '0' index

commit '74fb9f3474ab52e69151bec241e240363258ec8d' "ARM: OMAP2+: Add support
to parse 'main_clk' info from DT" wrongly removed the use of mpu_rt_idx as the
index and instead used a default '0' index for of_iomap() to map the modules
register address space.

AM33xx devices have a cpgmac module which has the mpu_rt_idx defined as 1 and
hence the above change caused hangs on these devices during suspend resume
as PER domain (to which the cpgmac module belongs) could not transition.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP4+: Fix PRM device instance offsets for OMAP5 and DRA7

The PRM device instance offsets for OMAP5 and DRA7 are different
from that on OMAP4. While this was fixed in the
omap4_prminst_global_warm_sw_reset() function, it was fixed only
partially for the register read part. Fix the offsets in the rest
of the read/wriites done in the function.

Reported-by: Yan Liu <yan-liu@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
powerpc/irq: Don't switch to irq stack from softirq stack

irq_exit() is now called on the irq stack, which can trigger a switch to
the softirq stack from the irq stack.  If an interrupt happens at that
point, we will not properly detect the re-entrancy and clobber the
original return context on the irq stack.

This fixes it.  The side effect is to prevent all nesting from softirq
stack to irq stack even in the "safe" case but it's simpler that way and
matches what x86_64 does.

Reported-by: Cédric Le Goater <clg@fr.ibm.com>
Tested-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Input: pixcir_i2c_ts: fix touch reach logic to read proper touch co-ordinates

With multiple touches also only first finget touch is forwareded to stack,
fixed by reading all the finger touched and passed it to stack.

Also reduced memory size allocation which is not needed as optimisation

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Merge branch 'am437x-bringup' of git://git.ti.com/~mugunthanvnm/ti-linux-kernel/mugunth-connectivity-linux-feature-tree into am437x-bringup
ARM: OMAP2+: Fix the missing braces

Commit "ARM: OMAP2+: Add new bindings for OMAP" introduces
new bindings for OMAP, but missed adding the braces in if
condition for finding these bindings. Adding the same

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent

Pull perf/urgent fixes from Arnaldo Carvalho de Melo:

 * The libaudit test was failing in some systems due to a unescaped newline, fix
   it so that the 'trace' tool can be built in such systems.

 * Fix installation of libexec components.

 * Add default handler for mmap2 events so that tools that don't explicitely
   define an MMAP2 handler don't crash, fix from David Ahern.

 * Fix to find line information for probe list, from Masami Hiramatsu.

 * Set child_pid after perf_evlist__prepare_workload(), fix from Namhyung Kim.

 * Fix infinite loop on invalid perf.data file, from Namhyung Kim.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
regulators: abstract locking out into helper functions

Create locking helpers for the regulator mutex. These helpers will be
needed for the next patch which introduces Regulator chain locking
scheme.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
regulator: introduce regulator chain locking scheme

In some cases the regulators may be organized in a chain like:
 ->regA->regB->regC
where regA is supplier for regB and regB is supplier for regC.

Currently it would be possible to reconfigure regA and regC at same time
form different contexts, because each regulator has it own mutex.
But in some cases, the only the whole chain is allowed be reconfigured
because of dependencies between regulators - to change regB
configuration the regA need to be updated first.

Hence, introduce regulator chain locking scheme to lock whole Regulator
chain in case if any part of it has been accessed from outside. To
achieve this goal the root Regulator (which has no supply defined, like
regA) in chain is used to protect the whole chain.

In addition, such locking scheme allows to have access to the supplier
regulator API from inside child's (consumer) regulator API.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
regulator: introduce TI AVS class 0 driver

    regulator: introduce TI AVS class 0 driver

    OMAP5 technology based processors such as DRA7XX[1] has an simplified AVS
    strategy called SmartReflex[2] Class 0. Texas Instrument's nomenclature for
    this is: Class - 0: Production Test Calibration

    This, in it's simplistic form implies that the voltage value for each OPP
    is now encoded into an efuse location.

    On entering an OPP, the voltage value to be selected is no longer the
    traditional nominal voltage, but the voltage meant from the efuse offset
    encoded in millivolts. Each device will have it's own unique voltage for a
    given OPP. Therefore, it is not possible to encode a range of voltage
    representing an OPP voltage.

    DRA processors may be powered using various PMICs - I2C based ones such
    as TPS659039 or SPI / GPIO controlled ones as well.

    cpufreq/devfreq driver which controls voltage and frequency pairs traditionally
    used:
    cpufreq/devfreq --> PMIC regulator
                    \-> clock framework
    This opens up a few issues:
    a) PMIC regulator is designed for platforms that maynot use SmartReflex class 0
       based SoCs, encoding the efuse offsets into every possible PMIC regulator
       driver is practically in-efficient.
    b) Voltage values are not known a-priori to be encoded into DTB as they are
       device specific.

    Another option might have been to start off with the nominal voltages in
    DT and then fixup the voltage entries in the OPP table by reading the
    eFuse information.

    However, such an approach introduces formidable constraints:
    A) OPP tables once added are not modifiable beyond enable/disable - that
    was the entire design constraint we wanted on OPP tables
    B) We need some indexing value for uniquely identifying what to do for
    an given OPP voltage - if OPP voltage by itself changes, how do we index
    various subsystems? - read abb/avs class 2 based class 1.
    C) We have n voltage domains and m devices per domain. - we no longer
    want to maintain an centralized OPP table.
    D) We also need to support multiple platforms which have "ganged voltage
    rails" each domain with variable voltages.
    E) Modification of the OPP data itself is hard - considering that we do
    not have a centralized OPP repository, architecture independent drivers
    like cpufreq-cpu0 driver does the "adding of OPPs".

    Options:
    a) modify arch generic drivers such as cpufreq-cpu0 driver with an OMAP
    specific an efuse offset and OMAP specific handling is a bad idea.
    b) we are able to overlay OPP table entried *before* cpufreq driver
    comes active
    - I am not sure we have ability to do that in kernel yet
    - I am not even sure we can modify the dtb being loaded by all
    bootloaders we may have (thinking beyond u-boot).

    To simplify this, we introduce:
    cpufreq/devfreq --> SmartReflex Class 0 regulator --> PMIC regulator
                    \-> clock framework

    Class 0 Regulator has information of translating the "nominal voltage" into
    voltage value stored in efuse offset.
    Example encoding:
    uVolts      mVolt   --> stored as 16 bit hex value of mV
    975000      975     --> 0x03CF
    1075000     1075    --> 0x0433
    1200000     1200    --> 0x04B0

    [1] http://www.ti.com/lit/ds/sprt659/sprt659.pdf
    [2] http://www.ti.com/lit/wp/swpy015a/swpy015a.pdf

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>