This patch adds grf configs to fix the clk paths
when used in tx/rx only slave mode.
Change-Id: I704687d86f1e8c25181d1e87e00107560c9e36fe
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
When restoring registers during runtime resume, we must not write to
I2S_TXDR which is the transmit FIFO as this queues up a sample to be
output and pushes all of the output channels down by one.
This can be demonstrated with the speaker-test utility:
for i in a b c; do speaker-test -c 2 -s 1; done
which should play a test with through the left speaker three times but if
the I2S hardware starts runtime suspended the first sample will be played
through the right speaker.
Fix this by marking I2S_TXDR as volatile (which also requires marking it
as readable, even though it technically isn't). This seems to be the
most robust fix, the alternative of giving I2S_TXDR a default value is
more fragile since it does not prevent regcache writing to the register
in all circumstances.
While here, also fix the configuration of I2S_RXDR and I2S_FIFOLR; these
are not writable so they do not suffer from the same problem as I2S_TXDR
but reading from I2S_RXDR does suffer from a similar problem.
Change-Id: Id91d3f54f3fda0e9140c9da162b0dff2c3df067b
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
When restoring registers during runtime resume, we must not write to
I2S_TXDR which is the transmit FIFO as this queues up a sample to be
output and pushes all of the output channels down by one.
This can be demonstrated with the speaker-test utility:
for i in a b c; do speaker-test -c 2 -s 1; done
which should play a test through the left speaker three times but if the
I2S hardware starts runtime suspended the first sample will be played
through the right speaker.
Fix this by marking I2S_TXDR as volatile (which also requires marking it
as readable, even though it technically isn't). This seems to be the
most robust fix, the alternative of giving I2S_TXDR a default value is
more fragile since it does not prevent regcache writing to the register
in all circumstances.
While here, also fix the configuration of I2S_RXDR and I2S_FIFOLR; these
are not writable so they do not suffer from the same problem as I2S_TXDR
but reading from I2S_RXDR does suffer from a similar problem.
Change-Id: I47e67b51f8251486bb5e937619fdec89fc055f14
Fixes: f0447f6cbb ("ASoC: rockchip: i2s: restore register during runtime_suspend/resume cycle", 2016-09-07)
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
(cherry picked from commit c66234cfed)
This patch adds the reset property for reset mechanism.
Change-Id: Ia60cc1f140860613b35ec42d703094bff8b46893
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
This patch brings i2s back to normal by resetting i2s m/h
logic if i2s' clear operation is failed.
Change-Id: I2fd47039b522ac89499b4a2912d5ffb7a469e75e
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
This patch brings i2s back to normal by resetting i2s tx/rx
relative logic if i2s' clear operation is failed.
Change-Id: I52e4713d26f781962278802bd1f9bbce3fe4b751
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
On RK3399/RK3399Pro platforms, We found that when USB 3.0
read/write at the same time in the following test case,
it may easily fail to transfer data with unknown problem.
Host transfer: 24B, 4MB, 4MB, 4MB
Device transfer : 24B, 4MB, 4MB, 4MB
Both Host and Device transfer "24B, 4MB, 4MB, 4M" Repeatedly
until transfer fail.
This patch adds 150us between the 24B and 4MB data to work
around the transfer issue. This patch may affect the USB 3.0
transmission performance, so we mark it as a HACK. We can
revert this patch if we find the root cause and fix this
issue with more reasonable patches.
Change-Id: Iff923ff895396a41a87e6a7df2bfa0072a13e2fc
Signed-off-by: William Wu <william.wu@rock-chips.com>
Some hardware need to translate scaling list table address to u32
address in register. The dma_addr_t on 64bit kernel will cause
overwriting to later register file.
Change-Id: Ib01d8e260b3e83dabafc13b3bfac02595faa6d63
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
GPIO0_C4 is used for lcd_en,not for backlight_en.
So fix it.
Change-Id: Id38ea83d65c91e2d7772d79caa6bad84a5d4398c
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
This patch adds a new flag pullups_connected to avoid
set pullup twice. It can help to fix the issue that
usb disconnect and reconnect again if we set pullup on
twice when usb connect to PC.
Change-Id: I756448cee9d2377695681d0394fada51a0c208f4
Signed-off-by: William Wu <william.wu@rock-chips.com>
The rockchip IQ tool uses the data buf of the uvc_request_data
to send vendor specific uvc control data to uvc host, or receive
data from uvc host. The max data payload maybe 4096 bytes, so we
increase the data buf of uvc_request_data to 4096, and also change
the UVC_MAX_REQUEST_SIZE to 4100 correspondingly.
Change-Id: I9820a5f531a655eb53232096fad131ad7a05e349
Signed-off-by: William Wu <william.wu@rock-chips.com>
The rockchip IQ tool sends data via usb uvc. The data buf
of v4l2_event is used for IQ tool userspace on uvc device
side to receive vendor specific data from host, the max
length of data maybe 4096 bytes, so increase the data length
of v4l2_event to 4100.
I have already tested the usb host uvc function, it works
well with this patch.
Note:
The userspace need to update the data length of v4l2_event
to 4100 synchronously.
Change-Id: I1a4673d50137760e190a17c6981740952fac2ca7
Signed-off-by: William Wu <william.wu@rock-chips.com>
When building with the USB_CONFIGFS_F_UVC_ROCKCHIP, set the
default CONFIG_FRAME_WARN to 5120, since Rockchip UVC need
4096 bytes for UVC request data buffer, grow beyond 2048 bytes
stack size.
Change-Id: I2df8892b8e0c930053be0154609ccc1558318b33
Signed-off-by: William Wu <william.wu@rock-chips.com>
This patch adds support to use uvc for Rockchip ISP IQ tool
which needs large data buf of the uvc_request_data to send
vendor special uvc control data to uvc host.
Change-Id: I22b65c4f28d69b50f6bbb41124f3342b8c4c7c19
Signed-off-by: William Wu <william.wu@rock-chips.com>
The average value of dynamic-power-coefficient is about 74.
Change-Id: Id80521440e0cbdb677344bf5becf092e4311c499
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
This reverts commit 4ef2449889.
The description for CRU_EMMC/SDMMC/SDIO_CON[0/1] is jumble on
chapters, make it clear that the correct shift is 1 that from
IC engineer.
Change-Id: I48dce293ec6ef82a5c78db38efc083227776ea99
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
use V4L2_CID_TEST_PATTERN to enable test mode of sensor
Change-Id: I8a27d4ae072baecf62efb39d782bdfee897cc7bf
Signed-off-by: Hu Kejun <william.hu@rock-chips.com>
For rk1808 platform, when system enters deep sleep,
it doesn't need usb3 phy to detect any signals, so
we can disable lane 0 to reduce power consumption.
With this patch, I test the 0.8V and 1.8V power
consumption for USB 3.0 mode while system enters
deep sleep on RK1808-EVB.
- 0.8V : 3.5mA
- 1.8V : 0.3mA
Change-Id: I2c080b2787e5358c7495b9a237d0d2b338cc145e
Signed-off-by: William Wu <william.wu@rock-chips.com>
usbdev_mmap allocates a buffer. The size of the buffer is determined
by a user. So with this code (no need to be root):
int fd = open("/dev/bus/usb/001/001", O_RDONLY);
mmap(NULL, 0x800000, PROT_READ, MAP_SHARED, fd, 0);
we can see a warning:
WARNING: CPU: 0 PID: 21771 at ../mm/page_alloc.c:3563 __alloc_pages_slowpath+0x1036/0x16e0()
...
Call Trace:
[<ffffffff8117a3ae>] ? warn_slowpath_null+0x2e/0x40
[<ffffffff815178b6>] ? __alloc_pages_slowpath+0x1036/0x16e0
[<ffffffff81516880>] ? warn_alloc_failed+0x250/0x250
[<ffffffff8151226b>] ? get_page_from_freelist+0x75b/0x28b0
[<ffffffff815184e3>] ? __alloc_pages_nodemask+0x583/0x6b0
[<ffffffff81517f60>] ? __alloc_pages_slowpath+0x16e0/0x16e0
[<ffffffff810565d4>] ? dma_generic_alloc_coherent+0x104/0x220
[<ffffffffa0269e56>] ? hcd_buffer_alloc+0x1d6/0x3e0 [usbcore]
[<ffffffffa0269c80>] ? hcd_buffer_destroy+0xa0/0xa0 [usbcore]
[<ffffffffa0228f05>] ? usb_alloc_coherent+0x65/0x90 [usbcore]
[<ffffffffa0275c05>] ? usbdev_mmap+0x1a5/0x770 [usbcore]
...
Allocations like this one should be marked as __GFP_NOWARN. So do so.
The size could be also clipped by something like:
if (size >= (1 << (MAX_ORDER + PAGE_SHIFT - 1)))
return -ENOMEM;
But I think the overall limit of 16M (by usbfs_increase_memory_usage)
is enough, so that we only silence the warning here.
Change-Id: I4765cb06f86fc39da83172cf116a63838e2586eb
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Steinar H. Gunderson <sesse@google.com>
Cc: Markus Rechberger <mrechberger@gmail.com>
Fixes: f7d34b445a (USB: Add support for usbfs zerocopy.)
Cc: 4.6+ <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 70f7ca9a02)
Add a new interface for userspace to preallocate memory that can be
used with usbfs. This gives two primary benefits:
- Zerocopy; data no longer needs to be copied between the userspace
and the kernel, but can instead be read directly by the driver from
userspace's buffers. This works for all kinds of transfers (even if
nonsensical for control and interrupt transfers); isochronous also
no longer need to memset() the buffer to zero to avoid leaking kernel data.
- Once the buffers are allocated, USB transfers can no longer fail due to
memory fragmentation; previously, long-running programs could run into
problems finding a large enough contiguous memory chunk, especially on
embedded systems or at high rates.
Memory is allocated by using mmap() against the usbfs file descriptor,
and similarly deallocated by munmap(). Once memory has been allocated,
using it as pointers to a bulk or isochronous operation means you will
automatically get zerocopy behavior. Note that this also means you cannot
modify outgoing data until the transfer is complete. The same holds for
data on the same cache lines as incoming data; DMA modifying them at the
same time could lead to your changes being overwritten.
There's a new capability USBDEVFS_CAP_MMAP that userspace can query to see
if the running kernel supports this functionality, if just trying mmap() is
not acceptable.
Largely based on a patch by Markus Rechberger with some updates. The original
patch can be found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Change-Id: I22f101b6e1a1fb027288f1c345da1750c39396c9
Signed-off-by: Steinar H. Gunderson <sesse@google.com>
Signed-off-by: Markus Rechberger <mrechberger@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit f7d34b445a)
