According to xHCI spec v1.1 section 6.4.5 TRB Completion Codes,
the standard XHCI controller provide a TRB Completion Status
'USB Transaction Error' to asserted in the case where the host
did not receive a valid response from the device, it's useful
to handle pending URBs on the endpoint when the USB device is
plugged out.
Unfortunately, some SOCs USB 3.0 modules lose the ability to
assert the 'USB Transaction Error' status when USB 3.0 device
disconnect. This may cause the pending URBs unhandled, even
lead to USB class driver stalled in waiting for URBs complete.
This patch flush pending URBs in usb_disable_device() when
USB 3.0 device disconnect, it will call xhci_urb_dequeue()
-> xhci_queue_stop_endpoint() to cancel pending URBs and
giveback URB status immediately.
Change-Id: If8acac59bc1f2c10a41ee390ccbeb84b2e7743c1
Signed-off-by: Feng Mingli <fml@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Some special SoCs (e.g. rk322xh) USB3 PHY have problem to detect
disconnection, they lose the ability to detect an absence of Rx
termination specified in USB3 spec Table 6-21, fortunately, the
USB3 PHY can detect port link state change when USB3 device is
unplugged, so we can do soft disconnect according to the PLC.
Change-Id: I2cbd62fddc8a1f9c5a264d705db43fb0cf3e035c
Signed-off-by: William Wu <wulf@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Some xHCI controllers (e.g. Rockchip rk3328 SoC) integrated
in DWC3 IP, don't support USB 3.0 autosuspend well, so we
need to disable USB 3.0 HUB autosuspend function with a quirk.
Change-Id: I33d4d2ec86102653bfb043eed12bfb6b5b426823
Signed-off-by: William Wu <william.wu@rock-chips.com>
This patch adds a new property "snps,dis-u3-autosuspend-quirk" for
xHCI integrated in DWC3 IP to disable USB 3.0 root HUB autosuspend.
Change-Id: Ibaf2b8d0e0472b052d3ab46010b7477274f4bb78
Signed-off-by: William Wu <william.wu@rock-chips.com>
Some USB controllers (such as rk3328 SoC DWC3 controller with INNO
USB 3.0 PHY) don't support autosuspend well, when receive remote
wakeup signal from autosuspend, the Port Link State training failed,
the correct PLC is Resume->Recovery->U0, but when the issue happens,
the wrong PLC is Resume->Recovery->Inactive, cause resuming SS port
fail. This issue always occurs when connect with external USB 3.0 HUB.
This patch adds a quirk to disable xHC USB 3.0 root HUB autosuspend
function.
Change-Id: I6afade864235a7669f415d933b7b4983c0d46289
Signed-off-by: William Wu <william.wu@rock-chips.com>
This patch adds a new "usb3-dis-autosuspend" property for some
Rockchip platforms which don't support autosuspend well.
Change-Id: I4d035415456405d47b85b3619fb47eb617fd2303
Signed-off-by: William Wu <william.wu@rock-chips.com>
Some USB host controller seems to have problems with
autosuspend. For example, Rockchip rk3328 SoC USB 3.0
wouldn't handle remote wakeup correctly with external
hub after entered autosuspend, caused to resume SS
port fail.
This patch introduces a new quirk flag for hub that
should remain disabled for autosuspend.
Change-Id: I6d14222b2c5025583fea811a6afd6abd22f41cb9
Signed-off-by: William Wu <wulf@rock-chips.com>
This patch tries to get the USB3 PHY using, and associates
the XHCI shared_hcd device with it.
With this patch, the USB HUB core driver can do USB PHY
operations base on USB PHY framework, e.g. call usb_phy_
notify_connect() or usb_phy_notify_disconnect() to notify
USB PHY driver to do soft connect or soft disconnect.
Change-Id: I3b51181b840a68ae477b764013446f49dbf7ca70
Signed-off-by: William Wu <wulf@rock-chips.com>
This patch doesn't fix any issue but make the code more concise.
Change-Id: I56d9d0e5f13579d2087edc41ca83bdb00e1ebb3f
Signed-off-by: William Wu <william.wu@rock-chips.com>
This patch fixes somme compile errors base on new
xHCI port structure.
Change-Id: Ic9c90b6523e0bebcaeaf1fead23bd0474e85d96a
Signed-off-by: William Wu <william.wu@rock-chips.com>
Fix sparse warning:
drivers/phy/rockchip/phy-rockchip-typec.c:403:16: warning: symbol 'usb3_pll_cfg' was not declared. Should it be static?
drivers/phy/rockchip/phy-rockchip-typec.c:420:16: warning: symbol 'dp_pll_cfg' was not declared. Should it be static?
Change-Id: I5c814f7d62a806deb53331e729008dd35bdfd790
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
(cherry picked from commit f7f6ed925d)
CONFIG_AUDITSYSCALL are enabled by default. This causes the
audit of all system call which impacts performance.
Disable these unused configs to improve performance.
Change-Id: I6487ab4034bd48a183107044be9c127b4bd435b6
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
CONFIG_AUDITSYSCALL are enabled by default. This causes the
audit of all system call which impacts performance.
Disable these unused configs to improve performance.
Change-Id: I7a147989dcaaf5c22d3d6d17e24f16ea38384d85
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
The RNDIS gadget function has USB class of 2 and subclass
of 2, which matches "USB\Class_02&SubClass_02" in the
usbser.inf file in the Windows system, so the device is
initially detected as a COM port instead of RNDIS. This
is why we need to install RNDIS manually.
Refer to Defined Class Codes [1] and rndis_host of Linux [2],
this patch sets the RNDIS gadget with base class of 0xE0h
(Wireless Controller) and subclass of 0x01h and protocol
of 0x03h.
[1] https://www.usb.org/defined-class-codes
[2] http://www.embedded-os.de/en/proto-rndis_host.shtml
Change-Id: Ida366749f378a0ce770d707b4ba56b87f9e188cf
Signed-off-by: William Wu <william.wu@rock-chips.com>
The gmac5.10a configure has_gmac4 with true and has_gmac with false.
Others still stay has_gmac with true.
Change-Id: I0d0d1adef8551d2f7aac6702f963cb23a9861036
Signed-off-by: David Wu <david.wu@rock-chips.com>
(1) before: multiple i2c devices with the same address
registered to the same i2c bus will fail.
(2) after: multiple i2c devices with the same address
registered to the same i2c bus just print
the error log, but will not fail.
Fixes: b97a325b33 ("i2c: Devices which have some i2c addr can work in same i2c bus")
Change-Id: I53a2b5a988d96c32e64b8a426621cf894c9cba20
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
If a PM domain is powered off before system suspend,
we hope do nothing in system runtime suspend noirq phase
and system runtime resume noirq phase.
Change-Id: Id72b1f92e10449c48006aced0d49612637402210
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Unfortunately, it appears our fix in:
commit b5d29843d8 ("drm/atomic_helper: Allow DPMS On<->Off changes
for unregistered connectors")
Which attempted to work around the problems introduced by:
commit 4d80273976 ("drm/atomic_helper: Disallow new modesets on
unregistered connectors")
Is still not the right solution, as modesets can still be triggered
outside of drm_atomic_set_crtc_for_connector().
So in order to fix this, while still being careful that we don't break
modesets that a driver may perform before being registered with
userspace, we replace connector->registered with a tristate member,
connector->registration_state. This allows us to keep track of whether
or not a connector is still initializing and hasn't been exposed to
userspace, is currently registered and exposed to userspace, or has been
legitimately removed from the system after having once been present.
Using this info, we can prevent userspace from performing new modesets
on unregistered connectors while still allowing the driver to perform
modesets on unregistered connectors before the driver has finished being
registered.
Changes since v1:
- Fix WARN_ON() in drm_connector_cleanup() that CI caught with this
patchset in igt@drv_module_reload@basic-reload-inject and
igt@drv_module_reload@basic-reload by checking if the connector is
registered instead of unregistered, as calling drm_connector_cleanup()
on a connector that hasn't been registered with userspace yet should
stay valid.
- Remove unregistered_connector_check(), and just go back to what we
were doing before in commit 4d80273976 ("drm/atomic_helper: Disallow
new modesets on unregistered connectors") except replacing
READ_ONCE(connector->registered) with drm_connector_is_unregistered().
This gets rid of the behavior of allowing DPMS On<->Off, but that should
be fine as it's more consistent with the UAPI we had before - danvet
- s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet
- Update documentation, fix some typos.
Fixes: b5d29843d8 ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Change-Id: I998eb6f5434cf82be881085f5b23e33603b440e4
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit 39b50c6038)
As a second global reset, the GRF is not reset, the iomux and
pull of PWM pin is still keeping, but PWM controller is reset,
PWM pin goes into input mode. However, the pull is still none
changed in kernel, which can cause voltage problems, so should
always keep the PWM pin pull down mode, with 0~50 μA power
increase.
Change-Id: I9f46feca00bdb6e8cad4794342d2936d62206164
Signed-off-by: David Wu <david.wu@rock-chips.com>
As a second global reset, the GRF is not reset, the iomux and
pull of PWM pin is still keeping, but PWM controller is reset,
PWM pin goes into input mode. However, the pull is still none
changed in kernel, which can cause voltage problems, so should
always keep the PWM pin pull down mode, with 0~50 μA power
increase.
Change-Id: Ibb1cbb5f5371d7838783264e23d5160c0757aaa6
Signed-off-by: David Wu <david.wu@rock-chips.com>
If the PWM pinctrl uses default state, the iomux setting will
be done at probe, the PWM may not be enabled at this moment.
It will make PWM into an intermediate state, destroy the default
hardware state, the PWM is not ready for work yet. So it is better
for doing PWM pinctrl setting after PWM enabled.
Change-Id: Iea34a7baf6a4d7df0c631f7f4fdab5b9d61bbd5f
Signed-off-by: David Wu <david.wu@rock-chips.com>
If some PWM enable_conf was configured with different values at
uboot/loader, the enable_conf should be cleaned firstly and
configured them at kernel. It is better to use the same parameters
on both sides to ensure excessive smoothing.
Change-Id: Ib1b7b55e9816639d9915543dadf059ce0e8be103
Signed-off-by: David Wu <david.wu@rock-chips.com>
The write or read request buffers may or may not be a highmem
page highmem or not allocated page, so the page->virtual will be
NULL, kmap it always need.
BUG:
[ 25.928352] Unable to handle kernel paging request at virtual address 0
[ 31.721348] pgd = a13fe17e
[ 31.724062] [0] *pgd=00000000
[ 31.727651] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 31.732966] Modules linked in:
Change-Id: Icdbb052bb488ecc10be1c8a8b0ca954f65c17474
Signed-off-by: Yifeng Zhao <zyf@rock-chips.com>
Since opp-suspend of cpub/l is 216MHz@950000mV, and the max frequency
under 950000mV is 600MHz, so initialize cpub/l freq to 600MHz.
Change-Id: I02d2ac44f4e5d125dfa90796b839c4a733442274
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
the supported multile area win gate only can be closed when area0 is
disabled.
Change-Id: Idd447bb7c2157587456391c1abeeefc9a5d61bbd
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
