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)
This patch add property 'rockchip,i2s-rx-route' and
'rockchip,i2s-tx-route' for capture/playback data
route mapping.
Change-Id: I8c790bfaf33b8e72c19e0b0ad5115d5d45de1662
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
It's hard to do platform specific initialization in the current pipeline.
This patch convert to generic bridge interface and let it attach to
a platform specific encoder.
CRTC --> Encoder --> Bridge --> Connector --> Panel
(platform)
This patch changed the pipeline to:
CRTC --> Encoder --> Bridge --> Connector --> Panel
(platform) (platform)
Change-Id: I43e0dab05e41965767f55cfe15b3674a71911312
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Right now exynos is exposing DPI as a TMDS encoder and VGA connector,
which seems rather misleading. This isn't just an internal detail,
since xrandr actually exposes "VGA" as the output name. Define some
new enums so that vc4's DPI can have a more informative name.
I considered other names for the connector as well. For VC4, the
Adafruit DPI kippah takes the 28 GPIO pins and routes them to a
standard-ish 40-pin FPC connector, but "40-pin FPC" doesn't uniquely
identify an ordering of pins (apparently some other orderings exist),
doesn't explain things as well for the user (who, if anything, knows
their product is a DPI kippah/panel combo), and actually doesn't have
to exist (one could connect the 28 GPIOs directly to something else).
Simply "DPI" seems like a good compromise name to distinguish from the
HDMI, DSI, and TV connectors .
Change-Id: Ic7b79c2e50f3629f56bc78c432834e2c58938cd9
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
(cherry picked from commit 0b27c02a7f)
when connect to dvp camera, we need grf to config cif data width
Change-Id: I798d841149e1fd9f7c3fb58bd39d1706bf85ee5d
Signed-off-by: Hu Kejun <william.hu@rock-chips.com>
The board is adjusted with pwm regulator for logic and arm voltage.
The regulator sleep mode is notified by the GPIO pin issued by the soc
The pwm regulator has no pin control for sleep switching, and needs to
notify the soc pmu special processing.
Change-Id: Id2c22f26abcdae427a8e30716afbcaab471ea183
Signed-off-by: Zhangbin Tong <zebulun.tong@rock-chips.com>
This adds debugfs consumer for xHCI driver. The debugfs entries
read all host registers, device/endpoint contexts, command ring,
event ring and various endpoint rings. With these entries, users
can check the registers and memory spaces used by a host during
run time, or save all the information with a simple 'cp -r' for
post-mortem programs.
The file hierarchy looks like this.
[root of debugfs]
|__usb
|____[e,u,o]hci <---------[root for other HCIs]
|____xhci <---------------[root for xHCI]
|______0000:00:14.0 <--------------[xHCI host name]
|________reg-cap <--------[capability registers]
|________reg-op <-------[operational registers]
|________reg-runtime <-----------[runtime registers]
|________reg-ext-#cap_name <----[extended capability regs]
|________command-ring <-------[root for command ring]
|__________cycle <------------------[ring cycle]
|__________dequeue <--------[ring dequeue pointer]
|__________enqueue <--------[ring enqueue pointer]
|__________trbs <-------------------[ring trbs]
|________event-ring <---------[root for event ring]
|__________cycle <------------------[ring cycle]
|__________dequeue <--------[ring dequeue pointer]
|__________enqueue <--------[ring enqueue pointer]
|__________trbs <-------------------[ring trbs]
|________devices <------------[root for devices]
|__________#slot_id <-----------[root for a device]
|____________name <-----------------[device name]
|____________slot-context <----------------[slot context]
|____________ep-context <-----------[endpoint contexts]
|____________ep#ep_index <--------[root for an endpoint]
|______________cycle <------------------[ring cycle]
|______________dequeue <--------[ring dequeue pointer]
|______________enqueue <--------[ring enqueue pointer]
|______________trbs <-------------------[ring trbs]
Change-Id: I61b412883e547a257bffc1234ee42fd221b940a6
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 02b6fdc2a1)
Add PORTSC Port status and control register decoder to
show human readable tracing of portsc register
Change-Id: I617493712e58546197748c01eea3f6b33b6dd377
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 2e77a8253d)
Add definitions for all port link states defined in xhci
specification for PORTSC register.
Will be needed for human readable port status tracing
Change-Id: I1de382f7e45c0a6a5481b92eabb2cf3b3fc68419
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 7344ee328c)
