mailbox: Don't unnecessarily re-arm the polling timer

poll_txdone() will unconditionally re-arm the polling timer if there was
an active request, even if the active request completed and no other
requests were submitted.  This is fixed by:
 - only re-arming the timer if the controller reported that the current
   transmission has not completed, and,
 - moving the call to poll_txdone() into msg_submit() so that the
   controller gets polled (and the timer re-armed, if necessary) whenever
   a new message is submitted.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
mailbox: add tx_prepare client callback

If the mailbox controller expects the payload is in place before
initiating the transmit, then it's impossible to reuse the list
maintained by core mailbox code currently. Maintaining another list
for sending the message in the controller seems totally unnecessary
as core mailbox library already provides that feature.

This patch introduces tx_prepare callback in mbox_client which
can be used by the core mailbox library before initiating the
transaction through mbox->ops->send_data. The client driver can
implement this callback to ensure the payload is copied to the
shared memory.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
mailbox/omap: adapt to the new mailbox framework

The OMAP mailbox driver and its existing clients (remoteproc
for OMAP4+) are adapted to use the generic mailbox framework.

The main changes for the adaptation are:
  - The tasklet used for Tx is replaced with the state machine from
    the generic mailbox framework. The workqueue used for processing
    the received messages stays intact for minimizing the effects on
    the OMAP mailbox clients.
  - The existing exported client API, omap_mbox_get, omap_mbox_put and
    omap_mbox_send_msg are deleted, as the framework provides equivalent
    functionality. A OMAP-specific omap_mbox_request_channel is added
    though to support non-DT way of requesting mailboxes.
  - The OMAP mailbox driver is integrated with the mailbox framework
    through the proper implementations of mbox_chan_ops, except for
    .last_tx_done and .peek_data. The OMAP mailbox driver does not need
    these ops, as it is completely interrupt driven.
  - The OMAP mailbox driver uses a custom of_xlate controller ops that
    allows phandles for the pargs specifier instead of indexing to avoid
    any channel registration order dependencies.
  - The new framework does not support multiple clients operating on a
    single channel, so the reference counting logic is simplified.
  - The remoteproc driver (current client) is adapted to use the new API.
    The notifier callbacks used within this client is replaced with the
    regular callbacks from the newer framework.
  - The exported OMAP mailbox API are limited to omap_mbox_save_ctx,
    omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq,
    with the signature modified to take in the new mbox_chan handle instead
    of the OMAP specific omap_mbox handle. The first 2 will be removed when
    the OMAP mailbox driver is adapted to runtime_pm. The other exported
    API omap_mbox_request_channel will be removed once existing legacy
    users are converted to DT.

Signed-off-by: Suman Anna <s-anna@ti.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Mailbox: Add support for Platform Communication Channel

ACPI 5.0+ spec defines a generic mode of communication
between the OS and a platform such as the BMC. This medium
(PCC) is typically used by CPPC (ACPI CPU Performance management),
RAS (ACPI reliability protocol) and MPST (ACPI Memory power
states).

This patch adds PCC support as a Mailbox Controller. As of
ACPI v5.1 there is no provision for clients to lookup mailbox
controllers in a way that Linux expects. e.g. in DT the clients
can list the mailboxes they can associate with in the DT binding
and then provide a unique index to lookup a channel within a mailbox.
Since the ACPI spec doesn't have anything similar, we introduce a
mailbox controller specific API so that when the client calls it,
we know to lookup in the context of a specific controller. This
also helps in keeping a consistent interface across DT and ACPI
for such drivers.

This patch implements basic PCC support using the ACPI v5.1
structures. IRQ mode support will be provided as follow up patches.

Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
pinctrl: at91: enhance (debugfs) at91_gpio_dbg_show

When a pin is configured as GPIO, print also direction (input or output).

Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
perf/x86/amd: AMD support for bp_len > HW_BREAKPOINT_LEN_8

Implement hardware breakpoint address mask for AMD Family 16h and
above processors. CPUID feature bit indicates hardware support for
DRn_ADDR_MASK MSRs. These masks further qualify DRn/DR7 hardware
breakpoint addresses to allow matching of larger addresses ranges.

Valuable advice and pseudo code from Oleg Nesterov <oleg@redhat.com>

Signed-off-by: Jacob Shin <jacob.w.shin@gmail.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: xiakaixu <xiakaixu@huawei.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
perf tools: allow user to specify hardware breakpoint bp_len

Currently bp_len is given a default value of 4. Allow user to override it:

  $ perf stat -e mem:0x1000/8
                            ^
                            bp_len

If no value is given, it will default to 4 as it did before.

Signed-off-by: Jacob Shin <jacob.w.shin@gmail.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: xiakaixu <xiakaixu@huawei.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
perf tools: add hardware breakpoint bp_len test cases

Signed-off-by: Jacob Shin <jacob.w.shin@gmail.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: xiakaixu <xiakaixu@huawei.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
perf/x86: Remove get_hbp_len and replace with bp_len

Clean up the logic for determining the breakpoint length

Signed-off-by: Jacob Shin <jacob.w.shin@gmail.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: xiakaixu <xiakaixu@huawei.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
acerhdf: Adding support for "manual mode"

Some Acer models require an additional command to turn off the fan after
bios mode has been enabled.  Adding new section in bios table to allow
support for those models, by writing an extra "manual mode" register.

Cc: platform-driver-x86@vger.kernel.org
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andreas Mohr <andi@lisas.de>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Peter Feuerer <peter@piie.net>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
acerhdf: Adding support for new models

added following new models:
   * Aspire 5755G
   * AO521
   * AO751h
   * Aspire One 753
   * Extensa 5420
   * Aspire 5315
   * Aspire 5739G
   * TravelMate TM8573T

Cc: platform-driver-x86@vger.kernel.org
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andreas Mohr <andi@lisas.de>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Peter Feuerer <peter@piie.net>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
acerhdf: Use bang-bang thermal governor

acerhdf has been doing an on-off fan control using hysteresis by
post-manipulating the outcome of thermal subsystem trip point handling.
This patch enables acerhdf to use the bang-bang governor, which is
intended for on-off controlled fans.

Cc: platform-driver-x86@vger.kernel.org
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
CC: Zhang Rui <rui.zhang@intel.com>
Cc: Andreas Mohr <andi@lisas.de>
Cc: Javi Merino <javi.merino@arm.com>
Acked-and-tested-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Peter Feuerer <peter@piie.net>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
acerhdf: added critical trip point

added critical trip point which represents the temperature limit.
Added return -EINVAL in case wrong trip point is provided.

Cc: platform-driver-x86@vger.kernel.org
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andreas Mohr <andi@lisas.de>
Cc: Borislav Petkov <bp@suse.de>
Cc: Javi Merino <javi.merino@arm.com>
Signed-off-by: Peter Feuerer <peter@piie.net>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
acerhdf: minor clean up

  * renamed bios_settings_t to bios_settings, as it is no typedef
  * replaced "unsigned char" by u8 in bios_settings struct for better
    readability.

Cc: platform-driver-x86@vger.kernel.org
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andreas Mohr <andi@lisas.de>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Peter Feuerer <peter@piie.net>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
thinkpad-acpi: Try to use full software mute control

ThinkPads have hardware volume controls and three buttons to control
them.  (These are separate from the standard mixer.)  By default,
the buttons are:

 - Mute: Mutes the hardware volume control and, on some models,
   generates KEY_MUTE.

 - Up: Unmutes, generates KEY_VOLUMEUP, and increases volume if
   applicable.  (Newer thinkpads only have hardware mute/unmute.)

 - Down: Unmutes, generates KEY_VOLUMEDOWN, and decreases volume
   if applicable.

This behavior is unfortunate, since modern userspace will also
handle the hotkeys and change the other mixer.  If the software
mixer is muted and the hardware mixer is unmuted and you push mute,
hilarity ensues as they both switch state.

Rather than adding a lot of complex ALSA integration to fix this,
just disable the special ThinkPad volume controls when possible.
This turns the mute and volume buttons into regular buttons, and
standard software controls will work as expected.

ALSA already knows about the mute light on models with a mute light,
so everything should just work.

This should also allow us to remove _OSI(Linux) for all ThinkPads.

For future reference: It turns out that we can ask ACPI for one of
three behaviors directly on very new models.  They are "latch" (the
default), "none" (no automatic control), and "toggle" (mute unmutes
when muted).  All of the modes besides "none" seem to be a bit
buggy, though, and there doesn't seem to be a consistent way to get
any notification when the HW mute state is changed.

Signed-off-by: Andy Lutomirski <luto@mit.edu>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
acpi: Remove _OSI(Linux) for ThinkPads

AFAICT the only reason to set _OSI(Linux) on ThinkPads is to get
sensible mute button behavior.  Now that the thinkpad_acpi driver
can do this on is own, there is no reason to keep the ACPI
quirk.

Cc: Len Brown <len.brown@intel.com>
Cc: Jerone Young <jerone.young@canonical.com>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
x86, smpboot: Remove pointless preempt_disable() in native_smp_prepare_cpus()

There is no reason to keep preemption disabled in this function.

We only have two other threads live: kthreadd and idle. Neither of
them is going to preempt. But that preempt_disable forces all the code
inside to do GFP_ATOMIC allocations which is just insane.

Remove it.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20141205084147.153643952@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
iommu, x86: Restructure setup of the irq remapping feature

enable_IR_x2apic() calls setup_irq_remapping_ops() which by default
installs the intel dmar remapping ops and then calls the amd iommu irq
remapping prepare callback to figure out whether we are running on an
AMD machine with irq remapping hardware.

Right after that it calls irq_remapping_prepare() which pointlessly
checks:
	if (!remap_ops || !remap_ops->prepare)
               return -ENODEV;
and then calls

    remap_ops->prepare()

which is silly in the AMD case as it got called from
setup_irq_remapping_ops() already a few microseconds ago.

Simplify this and just collapse everything into
irq_remapping_prepare().

The irq_remapping_prepare() remains still silly as it assigns blindly
the intel ops, but that's not scope of this patch.

The scope here is to move the preperatory work, i.e. memory
allocations out of the atomic section which is required to enable irq
remapping.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Acked-by: Joerg Roedel <joro@8bytes.org>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20141205084147.232633738@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
iommu/vt-d: Move iommu preparatory allocations to irq_remap_ops.prepare

The whole iommu setup for irq remapping is a convoluted mess. The
iommu detect function gets called from mem_init() and the prepare
callback gets called from enable_IR_x2apic() for unknown reasons.

Of course AMD and Intel setup differs in nonsensical ways. Intels
prepare callback is explicit while AMDs prepare callback is implicit
in setup_irq_remapping_ops() just to be called in the prepare call
again.

Because all of this gets called from enable_IR_x2apic() and the dmar
prepare function merily parses the ACPI tables, but does not allocate
memory we end up with memory allocation from irq disabled context
later on.

AMDs iommu code at least allocates the required memory from the
prepare function. That has issues as well, but thats not scope of this
patch.

The goal of this change is to distangle the allocation from the actual
enablement. There is no point to allocate memory from irq disabled
regions with GFP_ATOMIC just because it does not matter at that point
in the boot stage. It matters with physical hotplug later on.

There is another issue with the current setup. Due to the conversion
to stacked irqdomains we end up with a call into the irqdomain
allocation code from irq disabled context, but that code does
GFP_KERNEL allocations rightfully as there is no reason to do
preperatory allocations with GFP_ATOMIC.

That change caused the allocator code to complain about GFP_KERNEL
allocations invoked in atomic context. Boris provided a temporary
hackaround which changed the GFP flags if irq_domain_add() got called
from atomic context. Not pretty and we really dont want to get this
into a mainline release for obvious reasons.

Move the ACPI table parsing and the resulting memory allocations from
the enable to the prepare function. That allows to get rid of the
horrible hackaround in irq_domain_add() later.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Acked-by: Joerg Roedel <joro@8bytes.org>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20141205084147.313026156@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
irqdomain: Revert gfp hackery

Reverts: eda7516e1d428 'irqdomain: Correct early allocation of irq
domains with IRQs off'

Now that we distangled the allocations and the enablement of irq
remapping and removed the pointless preempt disabled region from
native_smp_prepare_cpus() we can remove that hackaround

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20141205084147.393737205@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>