If extcon cable state is EXTCON_USB_VBUS_EN, it also means
that otg host connected, don't need to do charge detection.
Change-Id: Ie7c97c4cd0cfd2688edbfb3bbff93d2f58e9ef9a
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
Set extcon cable state to EXTCON_USB_VBUS_EN instead of
EXTCON_USB_HOST when enable vbus 5v. Because EXTCON_USB_HOST
state means that fusb302 has detected Type-C mode and the
orientation. However, enable vbus is prior to Type-C mode
and orientation detection. If we set EXTCON_USB_HOST state
when power on vbus, it may cause usb controller driver to
receive the state prematurely, and do tcphy orientation init
improperly.
Change-Id: Id65072dc8235693db44667ee5d2ceac74dc94920
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
In usb3 tcphy init, it will access usb3 module to set
usb3 working on USB3.0 mode or USB2.0 only mode, and
usb3 pd must be enabled before do this operation. So
we add pm runtime control for dwc3 parent in extcon
evt work. If plug in usb device, resume dwc3 parent
first to enable usb3 pd and then do phy init.
Change-Id: I90dd762d7f76e5f1722c95611e440eacd3afcdc9
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
If the buffer alloced from the ion, user can flush
it by ion apis, but if the buffer was alloced by
other apis like malloc, user space is not easy to
flush the data cache. So rga flush the data cache
for cache coherence.
Change-Id: I5fcfc3e00c6a8f6b12ed66043b37b0c7c840e7ee
Signed-off-by: Zikim,Wei <wzq@rock-chips.com>
This reverts commit ccc954ee9f.
In current code, the dwc3 controller will not process notify when it is
in suspend state and this forbid extcon remove hcd before xhci resume, so
we do not need to forbid remove hcd by the hcd runtime flag and it is
difficult to deal with different process when connected with some special
usb storage.
Change-Id: I987862cceb4ffbe8deefb503f6bc4009770e87bd
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
The max output resolution of vopl is 2K, but vopb could support
4K output. For now we need support HDMI 4K display, so let force
VOP Big to HDMI.
Change-Id: Id095d3659554988f7647fb27d415652fbf510b14
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Add EXTCON_USB_VBUS_EN cable and change EXTCON_USB_HOST to
EXTCON_USB_VBUS_EN cable to control vbus.
Change-Id: I2e7c6111f723e425bd4c156e803cb6a1a9f17511
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
When usb device or host reconnect quickly, the dwc3 controller still
in the state of resume and can not resume again after receive connect
notify. So we need to suspend dwc3 controller immediately when
receive the notify of disconnect. This patch fix the bug "set device
address fail" when resume or quick reconnect.
Change-Id: Iaef6363cdece497f8d7be745017674e119fe3529
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
In current code, the dwc3 controller is active when system start
and change to suspend when auto suspend, while the dwc3 controller
will receive connected notify before auto suspend and fail to change
the state of dwc3 controller from active state to resume if dwc3
controller is connected when system start. So we can change async
suspend to sysc suspend to make sure that the dwc3 controller could
finish suspend process before receive connect notify and fix "set
address fail" error when system start.
Change-Id: Ida8760004da06275d667e33b887b8dde87cd9520
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
RK818 will miss the notify of charge type changing because
the charge cable state is init when u2phy probe but rk818 probe after
u2phy. So we need to get the charge cable state when rk818 probe.
Change-Id: I3682d764ae3f9a56a1ba85ba8b81ea7f1aacdf49
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
Id pin interrupt not occur when system start, so we need to check
id pin value when u2phy probe and set cable to host if the value
is high.
Change-Id: I333d5cae2463a159a18b455550a76ebcac704c44
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
Enable dwc3 to be wakeup source in runtime resume callback function
and disable dwc3 to be wake up source in runtime suspend. Change pd
in order to control usb pd base on the connect state of usb controller
and fix the detect fail bug of otg port after suspend and resume.
Change-Id: Ic204a82952eb5dd626945189e18a3d2cc40aa6d9
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
rk3399 Type-C0 USB can support both peripheral mode
and host mode, so we set dr_mode as otg.
Change-Id: Ifb6e64920cecf27e41f801809d560bdd302a880b
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
If DWC3 works as peripheral only mode, XHCI HCD will
not be created and added, so we should only get XHCI
HCD in host mode.
Change-Id: Iefb02431d6a973050986963bbabe0a943283f4b3
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
Since the commit a2be4bc ('FIXUP: UPSTREAM: phy: Add USB
Type-C PHY driver for rk3399') has created 2 PHY devices
separately for tcphy USB3 and DisplyPort, and registered
them under the child node, we should also add the USB3
and DP child nodes to dts.
Change-Id: Iffe5dc961dc96b2b41476b1db2949e95c275e19f
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
This patch aims to make code sync with upstream[1]. And it
can fix the following issues:
1. Introduce the EXTCON_PROP_USB_SS property to support both
DP 2*lanes + USB3.0 and DP 4*lanes + USB2.0 mode;
2. Fix the bug that the USB3 phy power on should not return
err when no USB attached, since the USB3 controller will
power_on phy at probe/resume, even though there is no USB3
super speed device attached. At this case, return 0 and do
nothing is better.
3. Create 2 PHY devices separately for USB3 and DisplyPort,
and registers them under the child node.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
commit <e96be45cb84e29e58f35ed460a859b61e8bf28c5>
Change-Id: Ib388a072f11d80624ec6e16291eab497a3dcb0e1
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
ID dig disconnect interrupt will happen and notify dwc3 controller
to remove hcd as soon as resume, and release root hub, but the hcd
has not resume, so there is a logic error and it may result in NULL
pointer, this patch forbid remove hcd when the state of hcd is suspend.
Change-Id: Ia5673848a23528cd053d75910c0fdbddf0927a40
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
The drm callback ->detect and ->get_modes seems is not power safe,
they may be called when device is power off, do register access on
detect or get_modes will cause system die.
Here is the path call ->detect before analogix_dp power on
[<ffffff800843babc>] analogix_dp_detect+0x44/0xdc
[<ffffff80083fd840>] drm_helper_probe_single_connector_modes_merge_bits+0xe8/0x41c
[<ffffff80083fdb84>] drm_helper_probe_single_connector_modes+0x10/0x18
[<ffffff8008418d24>] drm_mode_getconnector+0xf4/0x304
[<ffffff800840cff0>] drm_ioctl+0x23c/0x390
[<ffffff80081a8adc>] do_vfs_ioctl+0x4b8/0x58c
[<ffffff80081a8c10>] SyS_ioctl+0x60/0x88
Change-Id: Ica3fda1f22f903ee9ba2f0caed40cdae9bdfa32b
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9374135)
AFBC is arm vendor format, it's a compressed format.
The AFBC format is supported by rk3399 vop big.
We know little about AFBC layout, hope to some guys can
fixme about the afbc comment.
Change-Id: I9b3edaeb8cc7ffb792820c2f9a60d91fd0c6c28b
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9324667/)
enable ROCKCHIP_ANALOGIX_DP, ROCKCHIP_INNO_HDMI and ROCKCHIP_LVDS
Change-Id: I2bd0836bdb04b2c560834e8de31b37ce7a4fae79
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
We make sure that get drvdata dwc before register extcon
notifier and schedule otg_work, so we can remove the dwc
NULL pointer handle safely.
Also, change the WARN_ON to dev_warn, and avoid log noise.
Change-Id: Icececf3bb5ad510b91d2c3a50e2126225673605e
Signed-off-by: William wu <wulf@rock-chips.com>
Use a lock to ensure that the extcon callback only runs after probe()
has finished. In suspend() we unregister the extcon handler to prevent
it from being executed when the controller is suspended, which might
lead to crashes or unexpected behavior.
TEST=build and boot on 3399 board; plug in a USB device and verify
whether it is enumerated; suspend the DUT; resume the DUT; unplug
and re-plug the USB device and verify it is enumerated.
Change-Id: I965e66631a2d0f4d6cc53917d6a6e80bf8774fe1
Signed-off-by: William wu <wulf@rock-chips.com>
We need to ensure the dwc controller stay in P2 state prior
to phy init. In order to set dwc controller in P2 state,
there're two methods:
1. Hold dwc controller in reset while initialize phy.
2. Do OTG reset before phy init, one thing to note here is
that we can't reinit dwc controller again prior to phy init.
We choose the second mothod now. Because asserting the OTG
reset may affect dwc chip operation. The reset will clear all
of the dwc controller registers, and there are no synchronization
primitives, meaning the dwc3 core code could at least in theory
access chip registers while the reset is asserted, with unknown
impact. So we need to deassert the OTG reset as soon as possible.
Since phy init may take a long time, we can't hold the reset while
initialize phy.
Also, we add otg reset if dwc controller works as peripheral mode.
Change-Id: I54fec922308f62bfc7ebdde3e07ede9347e8f70a
Signed-off-by: William wu <wulf@rock-chips.com>
The ARM GICv3 #interrupt-cells need 4 cells to encode an interrupt source.
According to Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt,
the 4th cell is a phandle to a node describing a set of CPUs this interrupt
is affine to. The interrupt must be a PPI, and the node pointed must be a
subnode of the "ppi-partitions" subnode. For interrupt types other than PPI
or PPIs that are not partitionned, this cell must be zero. So we just add
0 for the 4th cell of u2phy1_otg interrupts.
Change-Id: I16ff4e4296064716fe4f7ea35946085e0473f049
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
Users of usleep_range() expect that it will _never_ return in less time
than the minimum passed parameter. However, nothing in any of the code
ensures this. Specifically:
usleep_range() => do_usleep_range() => schedule_hrtimeout_range() =>
schedule_hrtimeout_range_clock() just ends up calling schedule() with an
appropriate timeout set using the hrtimer. If someone else happens to
wake up our task then we'll happily return from usleep_range() early.
msleep() already has code to handle this case since it will loop as long
as there was still time left. usleep_range() had no such loop.
The problem is is easily demonstrated with a small bit of test code:
static int usleep_test_task(void *data)
{
atomic_t *done = data;
ktime_t start, end;
start = ktime_get();
usleep_range(50000, 100000);
end = ktime_get();
pr_info("Requested 50000 - 100000 us. Actually slept for %llu us\n",
(unsigned long long)ktime_to_us(ktime_sub(end, start)));
atomic_set(done, 1);
return 0;
}
static void run_usleep_test(void)
{
struct task_struct *t;
atomic_t done;
atomic_set(&done, 0);
t = kthread_run(usleep_test_task, &done, "usleep_test_task");
while (!atomic_read(&done)) {
wake_up_process(t);
udelay(1000);
}
kthread_stop(t);
}
If you run the above code without this patch you get things like:
Requested 50000 - 100000 us. Actually slept for 967 us
If you run the above code _with_ this patch, you get:
Requested 50000 - 100000 us. Actually slept for 50001 us
Presumably this problem was not detected before because:
- It's not terribly common to use wake_up_process() directly.
- Other ways for processes to wake up are not typically mixed with
usleep_range().
- There aren't lots of places that use usleep_range(), since many people
call either msleep() or udelay().
Change-Id: Ibb93ce0dd9fb9688d4a8d10447c098c1dfbd7a1d
Reported-by: Tao Huang <huangtao@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Andreas Mohr <andim2@users.sf.net>
(am from https://patchwork.kernel.org/patch/9369963/)
This adds support no relinquishing port from ehci to ohci.
Change-Id: I153a85df7407b8e546e75018d71e3763c8f41a10
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Add a quirk to cancel relinquishing port from ehci to
abnormal ohci when HS device is not ready connected.
To support this function, the no-relinquish-port property
must be specified in ehci node of dt.
Change-Id: Ief0b24cf9e58dde28f386ea67fe8936e8fd74f2d
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
used to calculate the delay time for change dcdc voltage.
Change-Id: I6bb462ef087b9ce6aa98991a1b961ed5f57bb3c8
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Commit 520bd7a8b4 ("mmc: core: Optimize boot time by detecting cards
simultaneously") causes regressions for some platforms.
These platforms relies on fixed mmcblk device indexes, instead of
deploying the defacto standard with UUID/PARTUUID. In other words their
rootfs needs to be available at hardcoded paths, like /dev/mmcblk0p2.
Such guarantees have never been made by the kernel, but clearly the above
commit changes the behaviour. More precisely, because of that the order
changes of how cards becomes detected, so do their corresponding mmcblk
device indexes.
As the above commit significantly improves boot time for some platforms
(magnitude of seconds), let's avoid reverting this change but instead
restore the behaviour of how mmcblk device indexes becomes picked.
By using the same index for the mmcblk device as for the corresponding mmc
host device, the probe order of mmc host devices decides the index we get
for the mmcblk device.
For those platforms that suffers from a regression, one could expect that
this updated behaviour should be sufficient to meet their expectations of
"fixed" mmcblk device indexes.
Another side effect from this change, is that the same index is used for
the mmc host device, the mmcblk device and the mmc block queue. That
should clarify their relationship.
Reported-by: Peter Hurley <peter@hurleysoftware.com>
Reported-by: Laszlo Fiat <laszlo.fiat@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Fixes: 520bd7a8b4 ("mmc: core: Optimize boot time by detecting cards
simultaneously")
Cc: <stable@vger.kernel.org>
Change-Id: I8fe12a3858f3e2ace8fcc785befbae588108e2db
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: xiaoyao <xiaoyao@rock-chips.com>
(cherry picked from commit 9aaf3437aa)
Practice shows :
The sd cards are easier to be identified after increase delay
Change-Id: I48912e2d184902fab8b27edba70281f0bf19b9ab
Signed-off-by: xiaoyao <xiaoyao@rock-chips.com>
