arm/dts: OMAP: Remove bootargs node from board files

Since 3.2, the CONFIG_ARM_ATAG_DTB_COMPAT config allows
an old bootloader to still use ATAG to provide cmdline.

Remove chosen/bootargs from the DTS board files.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP2+: kconfig: Enable devicetree by default for OMAP2+ systems

devicetree will become the mandatory boot method for OMAP2+.
In order to avoid cluttering the OMAP code with #ifdef CONFIG_OF,
select USE_OF by default for every OMAP2+ systems.

Enable PROC_DEVICETREE as well.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP2+: Make cpu_rev static global variable

As part of omap revision code cleanup, make cpu_rev
variable static global to the file (id.c). This is
needed so we can split the SoC detection from SoC
feature detection in the following patch. Also move
omap3_cpuinfo function a bit as that will be shared
by other omap3 like SoCs.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP2+: split omap2/3/4_check_revision function

We need to detect the SoC revision early, but the SoC
feature detection can be done later on. In order to allow
further clean-up later on, this patch separates the SoC
revision check from the SoC feature check.

This patch doesn't change functionality or behavior of the code
execution; it barely cleans up the code and splits into SoC
specific implementation for Rev ID and feature detection.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
perf: Update the mmap control page on mmap()

Apparently we didn't update the mmap control page right after mmap(),
which leads to surprises when userspace wants to use it.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Cc: Arun Sharma <asharma@fb.com>
Link: http://lkml.kernel.org/n/tip-dcpi7164djsexmx6ya7lilrc@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
perf, arch: Rework perf_event_index()

Put the logic to compute the event index into a per pmu method. This
is required because the x86 rules are weird and wonderful and don't
match the capabilities of the current scheme.

AFAIK only powerpc actually has a usable userspace read of the PMCs
but I'm not at all sure anybody actually used that.

ARM is restored to the default since it currently does not support
userspace access at all. And all software events are provided with a
method that reports their index as 0 (disabled).

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Michael Cree <mcree@orcon.net.nz>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Eric B Munson <emunson@mgebm.net>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Richard Kuo <rkuo@codeaurora.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Arun Sharma <asharma@fb.com>
Link: http://lkml.kernel.org/n/tip-dfydxodki16lylkt3gl2j7cw@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
perf: Fix mmap_page::offset computation

There's multiple reason the counter might be unavailable, change the
condition to !->index since perf_event_index() should return 0 for all
those cases.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-1ixr3olci40w8rgv2evv2ldh@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
perf, x86: Implement user-space RDPMC support, to allow fast, user-space access to self-monitoring counters

Implement a correct pmu::event_idx for the x86 counter index rules and
set CR4.PCE on CPU_STARTING.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Cc: Arun Sharma <asharma@fb.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Link: http://lkml.kernel.org/n/tip-mwxab34dibqgzk5zywutfnha@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
perf, x86: Provide means for disabling userspace RDPMC

Allow the disabling of RDPMC via a pmu specific attribute:

  echo 0 > /sys/bus/event_source/devices/cpu/rdpmc

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Cc: Arun Sharma <asharma@fb.com>
Link: http://lkml.kernel.org/n/tip-pqeog465zo5hsimtkfz73f27@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
perf: Extend the mmap control page with time (TSC) fields

Extend the mmap control page with fields so that userspace can compute
time deltas relative to the provided time fields.

Currently only implemented for x86 with constant and nonstop TSC.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Cc: Arun Sharma <asharma@fb.com>
Link: http://lkml.kernel.org/n/tip-3u1jucza77j3wuvs0x2bic0f@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
perf tools: Add x86 RDPMC, RDTSC test

Implement a simple test for the self-monitoring data from the
perf mmap data area control page:

 6: x86 rdpmc test:

             0:           6053
             1:          60053
             2:         600059
             3:        6000059
             4:       60000075
             5:      600000247
    Ok

The counts are expected to increase monotonically - these
are recovered via RDPMC, without calling into the kernel.

It might be nice to add logic to automagically turn these numbers into OK/FAIL.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Arun Sharma <asharma@fb.com>
Link: http://lkml.kernel.org/n/tip-evf5yii88ljdgmaihccbxxw1@git.kernel.org
[ various small improvements ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
ARM: OMAP1: ams-delta: register latch dependent devices later

In preparation to converting Amstrad Delta on-board latches to
basic_mmio_gpio devices, registration of platform devices which depend
on latches and will require initialization of their GPIO pins first,
should be moved out of .machine_init down to late_initcall level, as the
gpio-generic driver is not available until device_initcall time.  The
latch reset operation, which will be replaced with GPIO initialization,
must also be moved to late_initcall for the same reason.

Since there was already another, separate arch_initcall function for
setting up one of those latch dependent devices, the on-board modem
device, reuse that function, i.e., rename it to a name that matches the
new purpose, extend with other device setup relocated from
.machine_init, and move down to the late_initcall level.

While being at it, add missing gpio_free() in case the modem platform
device registration fails.

Thanks to Tony Lindgren <tony@atomide.com> who suggested this approach
instead of shifting up the gpio-generic driver initialization.

In addition, defer registration of the Amstrad Delta ASoC and serio
devices, done from their device driver files, until late_initcall time,
as those drivers will depend on their GPIO pins already requested from
the board late_init() function until updated to register their GPIO pins
themselves.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
UAS: Re-add workqueue items if submission fails.

If the original submission (or allocation) of the URBs for a SCSI
command fails, the UAS driver sticks the command structure in a
workqueue and schedules uas_do_work() to run.  That function removes the
entire queue before walking across it and attempting to resubmit.

Unfortunately, if the second submission fails, we will leak memory
(because an allocated URB was not submitted) and possibly leave the SCSI
command partially enqueued on some of the stream rings.  Fix this by
checking whether the second submission failed and re-queueing the
command to the UAS workqueue and scheduling it.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
UAS: Use unique tags on non-streams devices.

UAS can work with either USB 3.0 devices that support bulk streams, or
USB 2.0 devices that do not support bulk streams.  When we're working
with a non-streams device, we need to be able to uniquely identify a
SCSI command with a tag in the IU.  Devices will barf and abort all
queued commands if they find a duplicate tag.

uas_queuecommand_lck() sets cmdinfo->stream to zero if the device
doesn't support streams, which is later passed into uas_alloc_cmd_urb()
as the variable stream.  This means the UAS driver was setting the tag
in all commands to zero for non-stream devices.  So the UAS driver won't
currently work with USB 2.0 devices.

Use the SCSI command tag instead of the stream ID for the command IU
tag.  We have to add one to the SCSI command tag because SCSI tags are
zero-based, but stream IDs are one-based, and the command tag must match
the stream ID that we're queueing the data IUs for.  Untagged SCSI
commands use stream ID 1.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
UAS: Free status URB when we can't find the SCSI tag.

In the UAS status URB completion handler, we need to free the URB, no
matter what happens.  Fix a bug where we would leak the URB (and its
buffer) if we couldn't find a SCSI command that is associated with this
status phase.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
usb/uas: use unique tags for all LUNs

I observed that on a device with multiple LUNs UAS was re-using the same
tag number for requests which were issued at the same time to both LUNs.
This patch uses scsi_init_shared_tag_map() to use unique tags for all
LUNs. With this patch I haven't seen the same tag number during the init
sequence anymore. Tag 1 is used for devices which do not adverise
command queueing.
This patch initilizes the queue before adding the scsi host like the
other two user in tree.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
usb/uas: use scsi_host_find_tag() to find command from a tag

In "usb/uas: use unique tags for all LUNs" we make sure to create unique
tags across all LUNs. This patch uses scsi_host_find_tag() to obtain the
correct command which is associated with the tag.
The following changes are required:
- don't use sdev->current_cmnd anymore
  Since we can have devices which don't support command queueing we must
  ensure that we can tell the two commands apart. Even if a device
  supports comand queuing we send the INQUIRY command "untagged" for
  LUN1 while we can send a tagged command to LUN0 at the same time.
  devinfo->cmnd is used for stashing the one "untagged" command.
- tag number is altered. If stream support is used then the tag number
  must match the stream number. Therefore we can't use tag 0 and must
  start at tag 1.
  In case we have untagged commands (at least the first command) we must
  be able to distinguish between command tag 0 (which becomes 1) and
  untagged command (which becomes curently also 1).
  The following tag numbers are used:
  0: never
  1: for untagged commands (devinfo->cmnd)
  2+: tagged commands.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
usb/uas: one only one status URB/host on stream-less connection

The status/sense URB is allocated on per-command basis. A read/write
looks the following way on a stream-less connection:

- send cmd tag X, queue status
- receive status, oh it is a read for tag X. queue status & read
- receive read
- receive status, oh I'm done for tag X. Cool call complete and free
  status urb.

This block repeats itself 1:1 for further commands and looks great so
far. Lets take a look now what happens if we do allow multiple commands:

- send cmd tag X, queue statusX (belongs to the command with the X tag)
- send cmd tag Y, queue statusY (belongs to the command with the Y tag)
- receive statusX, oh it is a read for tag X. queue statusX & a read
- receive read
- receive statusY, oh I'm done for tag X. Cool call complete and free statusY.
- receive statusX, oh it is a read for tag Y. queue statusY & before we
  queue the read the the following message can be observed:
  |sd 0:0:0:0: [sda] sense urb submission failure
  followed by a second attempt with the same result.

In order to address this problem we will use only one status URB for
each scsi host in case we don't have stream support (as suggested by
Matthew). This URB is requeued until the device removed. Nothing changes
on stream based endpoints.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio

Once ready, ams-delta specific device drivers currently calling custom
ams_delta_latch[12]_write() functions can be updated to call generic
gpio_set_value() instead, which will make them less platform dependent.
Even more, some custom ams-delta only drivers can perhaps be dropped
from the tree after converting selected ams-delta platform devices to
follow generic GPIO based device models.

The latch_gpios[] table is initially filled with all latch1 and latch2
GPIO pins in order to register and initialize them from the board file
until those are handled by respective existing device drivers (leds,
nand, lcd, serio, asoc, serial). That table will get almost empty after
the transision process is completed, holding only pins not used by any
drivers / connected to unused devices, in order to initialize them from
the board file for power saving purposes.

The new ams_delta_latch_write() function is a unified replacement for
those removed ams_delta_latch[12]_write(), and serves as a temporary
wrapper over gpio_set_value(), providing the old API for those not yet
updated device drivers, and will be removed after all custom drivers are
converted or replaced.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP1: ams-delta: supersede custom led device by leds-gpio

Now that the Amstrad Delta on-board latches have been converted to GPIO
devices, use the generic driver to control on-board LEDs which hang off
those latches.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Tony Lindgren <tony@atomide.com>