The previous names and descriptions of L2 cache events on SpacemiT X60
are incorrect, now fix them.
Change-Id: I847eac354dc493f195d2f02bc1598bffb13ff74d
Signed-off-by: linjunyan <junyan.lin@spacemit.com>
1. Dtb memory is allocated by grub/uboot and passed to the kernel
Change-Id: I411c1b9b9c4cbf4f3afdf078321d2bd094b087fa
Signed-off-by: lijuan <juan.li@spacemit.com>
write DLH-->read DLH-->write DLL may cause set baudrate failed
such as: switch baud from 9600 to 115200,real baud still 9600
Fix the usage to "write DLL-->read DLL-->write DLM"
Change-Id: I766b4c2cafcf79668a9324c970ff653420cf076c
Signed-off-by: yanhaodong <haodong.yan@spacemit.com>
When the PHY has entered suspend mode, accessing PHY registers will
cause a system hang.
Change-Id: I45a1196c2d45489278f4cbbb650f44129deed86a
Signed-off-by: huzhen <george.hu@spacemit.com>
Some hid device requires custom userspace drivers to control
their device.
Change-Id: I8d07932960d6e325b99f62114c3b82a563dc7c64
Signed-off-by: Junzhong Pan <junzhong.pan@spacemit.com>
Tests shows Sandisk Ultra Flair USB3.0 (CZ series) udisk have issue with
VL817.
According to VL817 vendor, the Sandisk udisk have fast boot time, once
vbus is on, it will immediate fails SuperSpeed handshake and enter
HighSpeed mode because VL817's internal SS circuit isn't ready, after a
while, the SS reset is performed.
Since we didn't ultilize USBPE function of VL817 in the harware which
could control VBUS output to fit VL817's power sequence requirements,
this could varies from chip version and firmware. We suggest setting all
vbus_delay_ms of VL817 to 200ms, it could increase 200ms boot time delay
and resume delay of usb, but it's async and acceptable if 200ms is less
than current bottleneck.
Change-Id: Ie93c4be8ed09b4b0ed8e5924c461587ec70f51e3
Signed-off-by: Junzhong Pan <junzhong.pan@spacemit.com>
Tests shows Sandisk Ultra Flair USB3.0 (CZ series) udisk have issue with
VL817.
According to VL817 vendor, the Sandisk udisk have fast boot time, once
vbus is on, it will immediate fails SuperSpeed handshake and enter
HighSpeed mode because VL817's internal SS circuit isn't ready, after a
while, the SS reset is performed.
Since we didn't ultilize USBPE function of VL817 in the harware which
could control VBUS output to fit VL817's power sequence requirements,
this could varies from chip version and firmware. We suggest setting all
vbus_delay_ms of VL817 to 200ms, it could increase 200ms boot time delay
and resume delay of usb, but it's async and acceptable if 200ms is less
than current bottleneck.
Change-Id: I66236316804944b496523875aa5641221a4f93e4
Signed-off-by: Junzhong Pan <junzhong.pan@spacemit.com>
Tests shows Sandisk Ultra Flair USB3.0 (CZ series) udisk have issue with
VL817.
According to VL817 vendor, the Sandisk udisk have fast boot time, once
vbus is on, it will immediate fails SuperSpeed handshake and enter
HighSpeed mode because VL817's internal SS circuit isn't ready, after a
while, the SS reset is performed.
Since we didn't ultilize USBPE function of VL817 in the harware which
could control VBUS output to fit VL817's power sequence requirements,
this could varies from chip version and firmware. We suggest setting all
vbus_delay_ms of VL817 to 200ms, it could increase 200ms boot time delay
and resume delay of usb, but it's async and acceptable if 200ms is less
than current bottleneck.
Signed-off-by: Junzhong Pan <junzhong.pan@spacemit.com>
Change-Id: Ib34dc4c35efd48188ae335583b799557ca1a52fa
Tests shows Sandisk Ultra Flair USB3.0 (CZ series) udisk have issue with
VL817.
According to VL817 vendor, the Sandisk udisk have fast boot time, once
vbus is on, it will immediate fails SuperSpeed handshake and enter
HighSpeed mode because VL817's internal SS circuit isn't ready, after a
while, the SS reset is performed.
Since we didn't ultilize USBPE function of VL817 in the harware which
could control VBUS output to fit VL817's power sequence requirements,
this could varies from chip version and firmware. We suggest setting all
vbus_delay_ms of VL817 to 200ms, it could increase 200ms boot time delay
and resume delay of usb, but it's async and acceptable if 200ms is less
than current bottleneck.
Change-Id: I7cb9e4d12736db166dd8c69396a1da4742312f6c
Signed-off-by: Junzhong Pan <junzhong.pan@spacemit.com>
Tests shows Sandisk Ultra Flair USB3.0 (CZ series) udisk have issue with
VL817.
According to VL817 vendor, the Sandisk udisk have fast boot time, once
vbus is on, it will immediate fails SuperSpeed handshake and enter
HighSpeed mode because VL817's internal SS circuit isn't ready, after a
while, the SS reset is performed.
Since we didn't ultilize USBPE function of VL817 in the harware which
could control VBUS output to fit VL817's power sequence requirements,
this could varies from chip version and firmware. We suggest setting all
vbus_delay_ms of VL817 to 200ms, it could increase 200ms boot time delay
and resume delay of usb, but it's async and acceptable if 200ms is less
than current bottleneck.
Change-Id: I08f23c9183fa56891763626495c4e8dc7cc91171
Signed-off-by: Junzhong Pan <junzhong.pan@spacemit.com>
Make sure hub is initialized after usb async suspend and before usb
async resume.
Change-Id: I5de39b09fe18ba7c8b30ff49c6309babfec833ed
Signed-off-by: Junzhong Pan <junzhong.pan@spacemit.com>
It's observed large bMaxBurst on spacemit k1 cause some XHCI host
having issue when doing iperf3 test.
An Error scene of epin on bus trace looks like this:
Host TP ACK SeqN=22 NumP=8 Retry=N
Dev DP SeqN=23 Data=1024B **(Not Acked DP)**
Host TP ACK SeqN=23 NumP=7 (Asked for DP SeqN=23)
Dev DP SeqN=24 Data=600B **(Aborted DPP)**
Host TP ACK SeqN=23 NumP=7 Retry=Y (Asked for DP SeqN=23 Again)
Dev TP NRDY
Dev TP ERDY NumP=16
ITPs ...
And epout looks like this:
Dev ERDY, Host DP, Dev TP ACK, Host DP, Dev TP ACK, ITPs...
It seems the host fails to send ACK again on the epin and fails to
send more data on the epout. Setting bMaxBurst=0 could mitigate the
issue, host error is not excluded. More investigation will be
performed, for better compatibility, disable bursting for now.
The networking throughput is not decreasing compared to bMaxBurst=15.
Change-Id: I16f5adba4871874a56932a705772ec35a088c344
Signed-off-by: Junzhong Pan <junzhong.pan@spacemit.com>
The Windows 10 ncm host make us keep printing these every
serveral seconds when doing iperf3 test:
[ 174] configfs-gadget.0: Wrong NTH SIGN, skblen 14768
[ 174] HEAD:00000000b1a72bfc: 3f 98 a6 8e 17 f8 bb 29 07 b8 da 13 7f 20 80 8e 77 ca 32 07 ac 71 b8 8d 84 03 d7 1b 96 9b c4 fa
It's observed that Windows 10 ncm driver won't send ZLP when the
OUT transfer size is less than dwNtbOutMaxSize. Then when we have
two 16K usb_requst in the queue, when the requests giveback to us,
there are chances that two NTB are separated across two requests
like this:
USB_REQUEST #1
------------------------from OUT Transfer #1:-------------------
[Offset 0x0000] A **NTH32 Header** with wSequence=5765, dwNdpIndex=0x3D90
[Offset 0x0012] Datagram blocks
[Offset 0x3D90] A **NDP32** describing 10 Datagram blocks plus one zero length item and padding, len = 112 Bytes.
--------------------from OUT Transfer #2:-------------------
[Offset 0x3E00/15872] A **NTH32 Header** with wSequence=5766, dwNdpIndex=0x3B48
[Offset 0x3E00+???] Datagram block piece from next NDP (wSequence=5766)
USB_REQUEST #2
--------------------from OUT Transfer #2:-------------------
[Offset 0x0000] Datagram block piece from NTB of wSequence=5766
3f 98 a6 8e 17 f8 bb 29 07 b8 da 13 7f 20 80 8e 77 ca 32 07 ac 71 b8 8d 84 03 d7 1b 96 9b c4 fa
[Offset 0x????] A **NDP32** describing Datagram blocks
Workaround it by introducing a temporary buffer to merge two request
then do the unwrap job.
Change-Id: I30edb0039489a82b9cdc0b9894c8fdd12ef695c8
Signed-off-by: Junzhong Pan <junzhong.pan@spacemit.com>
