- Sep 18, 2014
-
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
clayshooter811@gmail.com authored
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>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
B. Scott Michel authored
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>
-
Bas van den Berg authored
-
Bas van den Berg authored
-
Bas van den Berg authored
-
Charles Steinkuehler authored
Signed-off-by:
Charles Steinkuehler <charles@steinkuehler.net>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Jason Kridner authored
Signed-off-by:
Jason Kridner <jdk@ti.com>
-
Jason Kridner authored
-
-
anithamolbenny authored
Signed-off-by:
anithamolbenny <anithamolbenny101@gmail.com> Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Michael Musset authored
Signed-off-by:
Michael Musset <mickamusset@gmail.com>
-
Micka authored
Signed-off-by:
Micka <mickamusset@gmail.com>
-
Chanho Min authored
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>
-
Francesco Lavra authored
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>
-
Koen Kooi authored
Signed-off-by:
Koen Kooi <koen@dominion.thruhere.net>
-
Sarah Sharp authored
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
-
Dave Chinner authored
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 ...
-
Kumar Abhishek authored
Signed-off-by:
Kumar Abhishek <abhishek@theembeddedkitchen.net>
-
Kumar Abhishek authored
Signed-off-by:
Kumar Abhishek <abhishek@theembeddedkitchen.net>
-
Kumar Abhishek authored
Same as Revision 91b9d2b37292eb8cd5f862ad833687002677f95c in github.com/abhishek-kakkar/BeagleLogic/ Signed-off-by:
Kumar Abhishek <abhishek@theembeddedkitchen.net>
-
Kumar Abhishek authored
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>
-
Kumar Abhishek authored
Signed-off-by:
Kumar Abhishek <abhishek@theembeddedkitchen.net>
-
Jonathan Piat authored
-
Jonathan Piat authored
-
Jonathan Piat authored
Signed-off-by:
Jonathan Piat <piat.jonathan@gmail.com> Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Jonathan Piat authored
-
Robert Nelson authored
http://elinux.org/CircuitCo:Basic_Proto_Cape load: echo "cape-bone-proto" > /sys/devices/bone_capemgr.*/slots Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Tyler Baker authored
Signed-off-by:
Tyler Baker <tyler.baker@linaro.org>
-
Dennie de Groot authored
Signed-off-by:
Dennie de Groot <mail@denniedegroot.nl>
-
Jason Kridner authored
It looks like one of the entries was missed. Signed-off-by:
Jason Kridner <github@hangerhead.com> Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-