Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

http://beagleboard.org/Community/Forums?place=msg%2Fbeagleboard%2FU3-4wh9yook%2Fgfc81YXrH6kJ



Signed-off-by: James Johnson <clayshooter811@gmail.com>
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Identify AM335x chip versions, detect and enable chip-specific
features such as the SGX GPU's presence and L2 cache.

Signed-off-by: B. Scott Michel <bscottm@ieee.org>
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Charles Steinkuehler <charles@steinkuehler.net>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Jason Kridner <jdk@ti.com>

Hint from kumar.abhishek.kakkar@gmail.com who also informed me that
Deepak Karki did start the work of doing the integration to the shared
driver at https://github.com/deepakkarki/pruspeak/tree/pru_rproc_ps/src/driver.

Borrowed heavily from BeagleLogic integration, this makes pru_speak
use the same pru_rproc driver. This is a ugly hack that reflects I
don't have much experience with this driver. Several obvious changes
need to be made to expose the right interface to pru_rproc clients
and extracting the features that have been thrown in the main driver
that really belong in another layer.

Based on https://github.com/deepakkarki/pruspeak
commit 1498fb911581eb6c5817c1e7f6c6057195e37646

Signed-off-by: Jason Kridner <jdk@ti.com>

http://arduino.cc/en/Main/ArduinoBoardTre

Signed-off-by: anithamolbenny <anithamolbenny101@gmail.com>
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Michael Musset <mickamusset@gmail.com>

Signed-off-by: Micka <mickamusset@gmail.com>

The pan/tilt absolute control value is signed value. If minimum value
is minus, It will be changed to plus by clamp_t() as commit 64ae9958

.
([media] uvcvideo: Fix control value clamping for unsigned integer controls).
It leads to wrong setting of the control values. For example,
when min and max are -36000 and 36000, the setting value between of this range
is always 36000. So, its data type should be changed to signed.

Signed-off-by: Chanho Min <chanho.min@lge.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>

Commit 1f6b9fa4

 consolidated writes to
the STAT register in one location, moving them from omap_hsmmc_do_irq()
to omap_hsmmc_irq(). This move has the unwanted side effect that the
controller status flags are potentially cleared after a new command has
been started as a consequence of reading the previous status flags.
This means that if the new command changes the status flags before the
IRQ routine returns, those flags may be cleared without handling the
event which asserted them, and thus missing the event.
Move the writing of the STAT register back in omap_hsmmc_do_irq(),
before handling the status flags which generated the interrupt.

Signed-off-by: Francesco Lavra <francescolavra.fl@gmail.com>
Reviewed-and-Tested-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

The TLDR; version:

We've assumed that when a device disconnects after a resume from device
suspend, it was just a cheap, buggy device.  It turns out that the USB
core simply wasn't waiting long enough for the devices to transition
from resume to U0, and it's actually been the USB core's fault all
along...

 * * Please go test this patch with your "buggy" USB devices. * *

Background
----------

The USB 2.0 specification, section 7.1.7.7, says that upon device remote
wakeup signaling, the first active hub (which is often the roothub) must
rebroadcast the resume signaling for at least 20 ms (TDRSMDN).  After
that's done, the hub's suspend status change bit will be set, and system
software must not access the device for at least 10 ms (TRSMRCY).

It turns out that TRSMRCY is a *minimum*, not a *maximum*, according to
Table 7-14.  That means the port can actually take longer than TRSMRCY
to resume.  Any attempt to communicate with the device, or reset the
device, will result in a USB device disconnect.

This discrepancy was found with the Intel xHCI host controller, because
they handle USB 2.0 resume a little differently than EHCI.  See the xHCI
spec, Figure 34: USB2 Root Hub Port Enabled Substate Diagram for
details.

Under EHCI, the host controller driver receives an interrupt when the
port suspend status change bit is set, and the USB core only has to time
the 10ms TRSMRCY value.

Under xHCI, the host receives an interrupt when the device remote wake
is first signaled, and the port goes into the Resume state.  The xHCI
driver kicks khubd, but doesn't allow the suspend state change to be
exposed until 20 ms (TDRSMDN) after the port status change event occurs.

Then, when the USB core calls into get port status, it transitions the
port from the Resume state to the RExit state by changing the port link
state to U0.  The xHCI driver will get a port status change event when
that transition is complete, but that port status change event is
currently ignored.

What actually happens
---------------------

By busy-waiting with xhci_handshake() after the Lynx Point LP host
initiates the transition to U0, and printing out how long it took, it
turns out that roughly 8% of the time, the host takes longer than 10 ms
to transition from RExit to U0.

Out of 227 remote wakeup events from a USB mouse and keyboard:
 - 163 transitions from RExit to U0 were immediate ( < 1 microsecond)
 - 47 transitions from RExit to U0 took under 10 ms
 - 17 transitions were over 10ms

Those 17 transitions (in microseconds) took:

10140
10305
10650
10659
10677
10695
10819
10907
10998
11030
11234
11618
11656
11724
11898
12060
12162
12757

The end result of that is that on 8% of remote wake events, the USB core
would attempt to communicate with the device before it was fully
resumed, causing USB disconnects or transfer errors on the next control
transfer to get the device status.

This bug has been reproduced under ChromeOS, which is very aggressive
about USB power management.  It enables auto-suspend for all internal
USB devices (wifi and bluetooth), and the disconnects wreck havoc on
those devices, causing the ChromeOS GUIs to repeatedly flash the USB
wifi setup screen on user login.  ChromeOS sets the autosuspend_delay_ms
to 100 milliseconds, and disables USB device persist.  I can reproduce
this bug with a vanilla 3.10.7 kernel under ChromeOS.

Possible fixes
--------------

The USB core obviously needs to be changed to check the port status
after the TRSMRCY timeout, and continue to wait if the port is still in
the resuming state.  I will have to study the EHCI port status diagrams
in detail to figure out how the USB core can do this.  I can easily do
this without the USB core being involved, by changing the xHCI driver to
either:

1. Busy wait with xhci_handshake() in the xHCI get port status until
   the port is in U0.

2. Add a completion per xHCI port.  In xHCI get port status, initiate
   U0 entry, and wait on the port's completion for up to 20 ms.  In the
   port status change event code, complete that port's completion when
   the port is in U0 and the bus_state->resuming_ports bit is set.

In the meantime, simply increasing TRSMRCY from 10 ms to 20 ms solves
the resume issue on the Intel xHCI host.  Please test this patch under
other host controllers to see if it helps "fix" your buggy devices.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

When sync does it's WB_SYNC_ALL writeback, it issues data Io and
then immediately waits for IO completion. This is done in the
context of the flusher thread, and hence completely ties up the
flusher thread for the backing device until all the dirty inodes
have been synced. On filesystems that are dirtying inodes constantly
and quickly, this means the flusher thread can be tied up for
minutes per sync call and hence badly affect system level write IO
performance as the page cache cannot be cleaned quickly.

We already have a wait loop for IO completion for sync(2), so cut
this out of the flusher thread and delegate it to wait_sb_inodes().
Hence we can do rapid IO submission, and then wait for it all to
complete.

Effect of sync on fsmark before the patch:

FSUse%        Count         Size    Files/sec     App Overhead
.....
     0       640000         4096      35154.6          1026984
     0       720000         4096      36740.3          1023844
     0       800000         4096      36184.6           916599
     0       880000         4096       1282.7          1054367
     0       960000         4096       3951.3           918773
     0      1040000         4096      40646.2           996448
     0      1120000         4096      43610.1           895647
     0      1200000         4096      40333.1           921048

And a single sync pass took:

  real    0m52.407s
  user    0m0.000s
  sys     0m0.090s

After the patch, there is no impact on fsmark results, and each
individual sync(2) operation run concurrently with the same fsmark
workload takes roughly 7s:

  real    0m6.930s
  user    0m0.000s
  sys     0m0.039s

IOWs, sync is 7-8x faster on a busy filesystem and does not have an
adverse impact on ongoing async data write operations.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>

Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>

Same as Revision 91b9d2b37292eb8cd5f862ad833687002677f95c
in github.com/abhishek-kakkar/BeagleLogic/

Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>

BeagleLogic is implemented as a separate kernel module that
binds and unbinds itself from pru_rproc at runtime.

Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>

Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>

Signed-off-by: Jonathan Piat <piat.jonathan@gmail.com>
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>