Signed-off-by: popcornmix <[email protected]>

Signed-off-by: popcornmix <[email protected]>

Signed-off-by: popcornmix <[email protected]>

Signed-off-by: popcornmix <[email protected]>

Signed-off-by: popcornmix <[email protected]>

Signed-off-by: popcornmix <[email protected]>

    Signed-off-by: popcornmix <[email protected]>

Signed-off-by: popcornmix <[email protected]>

Experiments show that it doesn't really take that long to sync, so we
can reduce the poll interval slightly. Might improve performance a bit.

The custom clock handling code is redundant and buggy. The MMC/SDHCI
subsystem does a better job than it, so remove it for good.

Some additional quirks are needed for correct operation.
There's no SDHCI capabilities register documented, and it always reads
zero, so add SDHCI_QUIRK_MISSING_CAPS. Apparently
SDHCI_QUIRK_NO_HISPD_BIT is needed for many cards to work correctly in
high-speed mode, so add it as well.

Add a parameter to disable high-speed mode for the few cards that
still might have problems. High-speed mode is enabled by default.

80 MHz clock isnt't suited well to be dividable to get SD clocks of 25
MHz (default mode) or 50 MHz (high speed mode). 50 MHz are perfect to
drive the SD interface at ideal frequencies.

Commit d64b84c by accident reduced the maximum overall DMA sync
timeout. The maximum overall timeout was reduced from 100ms to 30ms,
which isn't enough for many cards. Increase it to 150ms, just to be
extra safe. According to commit 872a8ff in the MMC subsystem, some
cards require crazy long timeouts (3s), but as we're busy-waiting,
and shouldn't delay for such a long time, let's hope 150ms will be
enough for most cards.

…we can reliably recover from, so down_interruptable is not a safe call.

The additional FIFO might speed up transfers in some cases.

There are issues with both single block reads (missed completion)
and writes (data loss in some cases!). Just don't do single block
transfers anymore, and treat them like multiblock transfers. This
adds a quirk for this and uses it.

…status=0 may improve interrupt latency

…s a module)

…ble_llm=0. Thanks ddv2005.

…. Should give about 10% more ARM performance.

Thanks to Gordon and Costas

…749 as this is widely used. Disabled older rtlwifi driver

CONFIG_DEVTMPFS_MOUNT, CONFIG_NFS_V4_1=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y, drbd and IPSEC modules

…s ddv2005.

…holdoff_enable=0. Thanks gsh

…arious I2C and SPI RTCs. Tidy of thermal driver.

…be specified on command line with sdhci-bcm2708.cycle_delay

…isabled missing_status and spurious CRC ACMD51 quirks by default (should be fixed by the retrying-mechanishm)

	 memory corruption, escalating to OOPS under high USB load.

The bcm2708 SPI driver's bcm2708_process_transfer() was ignoring the
per-transfer speed_hz value even when it was provided (it always just
used the spi device's max_speed_hz value).  Now, per-transfer speed_hz
values are respected.

Also added debug print to bcm2708_setup_state() to help keep an eye on
the configured SPI parameters.

Signed-off-by: Kamal Mostafa <[email protected]>

mmc0: could read SD Status register (SSR) at the 3th attempt
A more sensible response is now returned.
A typo also fixed in comments.

In dwc_otg_hcd_urb_enqueue during qtd creation, it was possible that the
transaction could complete almost immediately after the qtd was assigned
to a host channel during URB enqueue, which meant the qtd pointer was no
longer valid having been completed and removed. Usually, this resulted in
an OOPS during URB submission. By predetermining whether transactions
need to be queued or not, this unsafe pointer access is avoided.

This bug was only evident on the Pi model A where a device was attached
that had no periodic endpoints (e.g. USB pendrive or some wlan devices).

If the memory allocation for a dwc_otg_urb failed, the kernel would OOPS
because for some reason a member of the *unallocated* struct was set to
zero. Error handling changed to fail correctly.

If a transaction had previously aborted, certain interrupts are
enabled to track error counts and reset where necessary. On IN
endpoints the host generates an ACK interrupt near-simultaneously
with completion of transfer. In the case where this transfer had
previously had an error, this results in a use-after-free on
the QTD memory space with a 1-byte length being overwritten to
0x00.

Previously a data toggle error on packets from a USB1.1 device behind
a TT would result in the Pi locking up as the driver never handled
the associated interrupt. Patch adds basic retry mechanism and
interrupt acknowledgement to cater for either a chance toggle error or
for devices that have a broken initial toggle state (FT8U232/FT232BM).

Allows parasite power to work, uses module option pullup=1

The dwc_otg driver interrupt handler for transfer completion will spend
a very long time with interrupts disabled when a URB is completed -
this is because usb_hcd_giveback_urb is called from within the handler
which for a USB device driver with complicated processing (e.g. webcam)
will take an exorbitant amount of time to complete. This results in
missed completion interrupts for other USB packets which lead to them
being dropped due to microframe overruns.

This patch splits returning the URB to the usb hcd layer into a
high-priority tasklet. This will have most benefit for isochronous IN
transfers but will also have incidental benefit where multiple periodic
devices are active at once.

This corrects a bug where if a single active non-periodic endpoint
had at least one transaction in its qh, on frnum == MAX_FRNUM the qh
would get skipped and never get queued again. This would result in
a silent device until error detection (automatic or otherwise) would
either reset the device or flush and requeue the URBs.

Additionally the NAK holdoff was enabled for all transactions - this
would potentially stall a HS endpoint for 1ms if a previous error state
enabled this interrupt and the next response was a NAK. Fix so that
only split transactions get held off.

add mmap support and some cleanups to bcm2835 ALSA driver

This is designed for quick compiling when developing.
No modules are needed and it includes all Pi specific drivers

…e to boot from alternate partition

…er wifi modules. Thanks UrsusArctos

Especially on platforms with a slower CPU but a relatively high
framebuffer fill bandwidth, like current ARM devices, the existing
console monochrome imageblit function used to draw console text is
suboptimal for common pixel depths such as 16bpp and 32bpp. The existing
code is quite general and can deal with several pixel depths. By creating
special case functions for 16bpp and 32bpp, by far the most common pixel
formats used on modern systems, a significant speed-up is attained
which can be readily felt on ARM-based devices like the Raspberry Pi
and the Allwinner platform, but should help any platform using the
fb layer.

The special case functions allow constant folding, eliminating a number
of instructions including divide operations, and allow the use of an
unrolled loop, eliminating instructions with a variable shift size,
reducing source memory access instructions, and eliminating excessive
branching. These unrolled loops also allow much better code optimization
by the C compiler. The code that selects which optimized variant is used
is also simplified, eliminating integer divide instructions.

The speed-up, measured by timing 'cat file.txt' in the console, varies
between 40% and 70%, when testing on the Raspberry Pi and Allwinner
ARM-based platforms, depending on font size and the pixel depth, with
the greater benefit for 32bpp.

Signed-off-by: Harm Hanemaaijer <[email protected]>

Based on the patch authored by Ali Gholami Rudi at
    https://lkml.org/lkml/2009/7/13/153

Provide an ioctl for userspace applications, but only if this operation
is hardware accelerated (otherwide it does not make any sense).

Signed-off-by: Siarhei Siamashka <[email protected]>

Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425
Also used Simon's dmaer_master module as a reference for tweaking DMA
settings for better performance.

For now busylooping only. IRQ support might be added later.
With non-overclocked Raspberry Pi, the performance is ~360 MB/s
for simple copy or ~260 MB/s for two-pass copy (used when dragging
windows to the right).

In the case of using DMA channel 0, the performance improves
to ~440 MB/s.

For comparison, VFP optimized CPU copy can only do ~114 MB/s in
the same conditions (hindered by reading uncached source buffer).

Signed-off-by: Siarhei Siamashka <[email protected]>

… handler

usb_hcd_unlink_urb_from_ep must be called with the HCD lock held.  Calling it
asynchronously in the tasklet was not safe (regression in
c4564d4).

This change unlinks it from the endpoint prior to queueing it for handling in
the tasklet, and also adds a check to ensure the urb is OK to be unlinked
before doing so.

NULL pointer dereference kernel oopses had been observed in usb_hcd_giveback_urb
when a USB device was unplugged/replugged during data transfer.  This effect
was reproduced using automated USB port power control, hundreds of replug
events were performed during active transfers to confirm that the problem was
eliminated.

This commit adds a FIQ implementaion that schedules
the split transactions using a FIQ so we don't get
held off by the interrupt latency of Linux

This reverts commit 1fdd347.

Fix for deprecated/undefined create_proc_entry in RTL8192cu driver

The current timeout is being hit with some cards that complete successfully with a longer timeout.
The timeout is not handled well, and is believed to be a code path that causes corruption.
872a8ff suggests that crappy cards can take up to 3 seconds to respond

…rd, commenting it out solves the crash