Jump to content

mjhammel

Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by mjhammel

  1. I think so, but I'm not experienced with the callback/notification methods enough to be clear on that. It uses pm_runtime_*() functions to deal with it, I believe. I did that this morning and, while dwc3-rockchip.c in both are very similar, there are many differences that are not just kernel version related. The processing in various functions is different. I'm going to try to port Ayufan's dwc3-rockchip.c to 5.15.14 and see if that works better - there are only a few API changes I think. The drivers/mfd/fusb302.c is also similar, but very different. These all have the same copyright block at the top but it doesn't tell me which is newer or where they might have a common ancestor. You could manage that in software with a UI that swaps a DT overlay. But it's basically just a software solution to the hardware switch. Also, with kexec, you could reboot with a new DT without a hardware reset, but it's still a kernel reboot. I'm able to switch modes (not that the modes work, but I can switch them) using debugfs instead of sysfs. It's unclear to me how bad it would be to have debugfs mounted on a production system. Might expose things you don't want exposed. I suspose you could move the mode debugfs file to sysfs - you're basically just exposing a function call but it would probably be the same (or the same with a different wrapper for the API) for both.
  2. First, thanks for the tips. It's good to have someone to boune ideas off of. The extcon is the physical port (re: "external connection"), in this case a Typc-C connector on our board. It notifies the phy core that then initiates the callback to the workqueue in the dwc3-rockchip driver. At least that's my understanding. You have to reference the extcon in the usbdrd3 proprerty, which is the rockchip dwc3 driver (the dwc3-simple driver doesn't directly reference an extcon), so it can attach the extcon to the phy. But apparently you also need to attach it to the tcphy0 property, or so it seems based on some other DTS examples. It's very confusing. The extcon driver in this case is fusb302. There is one of those under drivers/usb/typec/tcpm that comes from Google. But that doesn't seem to work no matter what I do with its dts config. So I forward ported the fusb302 driver from the BSP, which comes from rockchip. With some added debug I can see connection events and the callback to the workqueue function. Turns out my version of that patch came later and does not have the call to dwc3_phy_setup() - which is why my port compiled without the core.c/h patch. Of course, that may also be the reason it doesn't work. I ported it from a 4.4 kernel. The ayufan-rock64 kernel is not something I can drop on this device. We're bumped to 5.15.14 (upstream release + custom patches, most if not all are from the net) at the moment and it's tied to the specific u-boot we have. It also probably wouldn't support our display, though I have a serial console so maybe that doesn't matter. My changes are simple, really. They consist of choosing a fusb302 driver: Google's (CONFIG_TYPEC_FUSB302, plus some other typec drivers which I think are required) or Rockchips (CONFIG_FUSB_30X, which is part of my port and is standalone) a dwc3-* driver: dwc3-of-simple (aka CONFIG_USB_DWC3_OF_SIMPLE) or dwc3-rockchip (CONFIG_USB_DWC3_ROCKCHIP, which I've added to the Kconfig). We run as an embedded board so nearly everything is statically compiled, but I make the fusb driver a module and manually load it after boot. This way if any of the drivers lock up it won't happen until the fusb is loaded and I plug something in (or left something plugged in from the last test). Then the DTS is updated to match those selections. There are a few places that this matters. Note that what follows is what I have, but it obviously isn't working. When using the stock drivers (Google fusb302, dwc3-of-simple), it looks like this: &i2c4 { status = "okay"; fusb0: fusb30x@22 { // Google fusb compatible = "fcs,fusb302"; fcs,int_n = <&gpio1 2 GPIO_ACTIVE_HIGH>; interrupt-parent = <&gpio1>; interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>; pinctrl-names = "default"; pinctrl-0 = <&fusb0_int>; vbus-supply = <&vcc5v0_typec0>; status = "okay"; connector { compatible = "usb-c-connector"; data-role = "dual"; label = "USB-C"; op-sink-microwatt = <1000000>; power-role = "dual"; sink-pdos = <PDO_FIXED(5000, 2500, PDO_FIXED_USB_COMM)>; source-pdos = <PDO_FIXED(5000, 1400, PDO_FIXED_USB_COMM)>; try-power-role = "sink"; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; usbc_hs: endpoint { remote-endpoint = <&u2phy0_typec_hs>; }; }; port@1 { reg = <1>; usbc_ss: endpoint { remote-endpoint = <&tcphy0_typec_ss>; }; }; }; }; }; }; &u2phy0 { status = "okay"; extcon = <&fusb0>; // otg-vbus-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>; u2phy0_otg: otg-port { // phy-supply = <&vcc5v0_typec0>; status = "okay"; }; u2phy0_host: host-port { phy-supply = <&vcc5v0_typec0>; status = "okay"; }; port { u2phy0_typec_hs: endpoint { remote-endpoint = <&usbc_hs>; }; }; }; &usbdrd3_0 { status = "okay"; }; &usbdrd_dwc3_0 { status = "okay"; dr_mode = "peripheral"; }; &tcphy0 { status = "okay"; extcon = <&fusb0>; }; &tcphy0_usb3 { status = "okay"; extcon = <&fusb0>; port { tcphy0_typec_ss: endpoint { remote-endpoint = <&usbc_ss>; }; }; }; When using the Rockchip fusb302 and dwc3 driver it looks like this: &i2c4 { status = "okay"; fusb0: fusb30x@22 { compatible = "fairchild,fusb302"; vbus-5v-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>; int-n-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; fusb302,role = "ROLE_MODE_DRP"; fusb302,try_role = "ROLE_MODE_DRP"; reg = <0x22>; pinctrl-names = "default"; pinctrl-0 = <&fusb0_int>; status = "okay"; }; }; &u2phy0 { status = "okay"; otg-vbus-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>; u2phy0_otg: otg-port { status = "okay"; }; u2phy0_host: host-port { phy-supply = <&vcc5v0_typec0>; status = "disabled"; }; }; &usbdrd3_0 { status = "okay"; extcon = <&fusb0>; }; &usbdrd_dwc3_0 { status = "okay"; extcon = <&fusb0>; dr_mode = "otg"; /* USB 3.0 */ maximum-speed = "super-speed"; phys = <&tcphy0_usb3>; phy-names = "usb3-phy"; }; &tcphy0 { status = "okay"; extcon = <&fusb0>; resets = <&cru SRST_UPHY0>, <&cru SRST_UPHY0_PIPE_L00>, <&cru SRST_P_UPHY0_TCPHY>, <&cru SRST_A_USB3_OTG0>; reset-names = "uphy", "uphy-pipe", "uphy-tcphy", "usb3-otg"; }; &tcphy0_usb3 { status = "okay"; }; I'll try adding that dwc3_phy_setup() call just for grins to see what happens. But I'm not sure it matters if I try to boot in peripheral mode to start with. I think it only matters if I'm trying to use OTG. I'm trying to use peripheral mode only right now just to get device mode working in any way possible (but preferrably at least at HS).
  3. The one I found is here: https://patchwork.kernel.org/project/linux-rockchip/patch/1471251284-1804-1-git-send-email-william.wu@rock-chips.com/ I can probably handle the data sheets but I don't have them, nor do I have the understanding of how the usb upstream expects drivers to be written. The GPIO ISR you mention might use a debugfs/sysfs interface to switch modes. I don't know of a way to do it via sysfs, but the dwc3 drivers have some debugfs mode files that allow it. That said, when I tried using those the system locked and/or rebooted. The issue seems to be with the workqueue item (from the ported BSP driver) that handles the switching - it needs to reset the dwc3 controller and (I think) restart everything. But that seems not to work or maybe it works partly but takes too long while trying to run in a workqueue item. I can tell roughly where the problem is but not why it's happening. The stock dwc3 driver (dwc3-of-simple) doesn't do any of that and thus doesn't seem to support dynamic mode switching. At least as far as I can tell. I'm still experimenting with it. Right now I'm just trying to get back to USB2 HS gadget-devices working. It's a magic incantation of DTS and driver selection whose page is missing from my book of spells. Oh, one thing I do seem to remember from when it worked was: don't over use the DTS. There are lots of possible configurations you can add to the tcphy0 and usbdrd properties but, if I recall correctly, it was best not to use them. So that's what I'm working on now.
  4. I've been working this problem for quite some time for an rk3399 based board we're developing. I need peripheral mode at SS for video/audio gadgets but also need Host mode (probably at any speed) for factory work though we can probably live without host mode. The fix you have above appears to be just a slight variation of what already exists for default rk3399.dtsi. Only the "snps,xhci-slow-suspend-quirk" seems to be new. It didn't have an affect on my testing. My use case requires USB3 OTG or peripheral mode over Type-C. The existing type-c driver, fusb302, does not work at all, as far as I can tell. I've have had no luck getting it to work with either the stock dwc3-of-simple driver of a the (see below) ported rockchip dwc driver. I forward ported both the fusb302.c driver and the associated dwc3-rockchip.c driver from Rockchip's BSP to 5.15.14.. These act better but still don't work. More importantly, you can't set the mode to OTG in the DTS and then try to switch between host and peripheral modes. There are bugs in the dwc3-rockhip.c driver that cause the workqueue to timeout and the system to reboot. I haven't figured out why that is - possibly the workqueue takes too long or, more likely, there is some kind of memory stomping going on. The best you can do is set the mode to peripheral and just stay there. But even that doesn't seem to work to allow the rk3399 to act as a storage device (which is what I use to test this because it's the easiest to setup). At least not consistently. I have seen the ported drivers work in USB2 HS mode and at one point I managed to get the storage device to be seen at SS, but I don't know how I did it, it didn't stay stable on the host side, and I have not been able to repeat it. The BSP driver was rejected by the upstream USB developers back in 2016, so this path is just to make it work. It would never make into the upstream. I've noticed there is a hw switch on the RockPi4 for OTG vs Host mode. I suspect they use that to load a different overlay at boot time. It's a neat trick. I don't know what drivers or DTS config they're using. If anyone has additional information that might help getting the stock drivers or the ported drivers working, at a minimum as a peripheral at SS speed, let me know. Thanks.
  5. mjhammel

    Mainline VPU

    I've been following @xmixahlx work on pbp-tools. I have an rk3399 board we're developing in house (kind of) and I'm tasked with seeing what it takes to get the VPU working. Our build system won't work with the pbp scripts but I extraced the useful bits (urls, patches, etc.) from them to get a build working with the following components. I also wrote a BASH test script for doing validation (see link below) up to and including attempting to decode and encode to the NULL device with ffmpeg. I'm not getting the output I'm expecting and was wondering if I've missed a step. This is what I have now. This is the order I build them as well. 1. Linux 5.8.5 w/local config plus pbp patch a. url: https://github.com/xmixahlx/pbp-tools/tree/master/resources/linux/5.8 b. linux-5.8-rc4-hwaccel_20200709.diff 2. v4l2-utils 1.20.0 (no patches) 3. libva (git master) with patches a. url: https://patch-diff.githubusercontent.com/raw/intel/libva/pull/ b. 332.patch c. 340.patch d. patches edited based on https://github.com/xmixahlx/pbp-tools/blob/master/pbp-install-libva 4. libva-v4l2-request (git master) with patches a. url: https://patch-diff.githubusercontent.com/raw/bootlin/libva-v4l2-request/pull/ b. 30.patch c. 32.patch d. Why not 28, 29 too? (31 doesn't exist: https://github.com/bootlin/libva-v4l2-request/pulls) - I think I found these may not be needed after all, but can't remember now why I left them out. 5. libva-utils (git master, no patches) 6. ffmpeg n4.3.1 with patches a. url: https://raw.githubusercontent.com/xmixahlx/pbp-tools/master/resources/ffmpeg/4.3/ b. ffmpeg-4.3-v4l2request-rkvdec_20200709.diff 7. v4l2-request-test (git master, no patches) The test script, which I linked at the bottom of this post, is mostly just printing out what my setup looks like and responses to various v4l2, va and ffmpeg commands suggested here, the pbp forum and for ffmpeg. I run it like this: I can also run it without the -t option to enable decode/encode tests but those don't work and I think that's because of what the rest of the tests are telling me. Most important is that vainfo is not showing any profile or entrypoints. One important fact for my build: drm is not enabled yet. We have it working on a 4.4.179 kernel and are working on a port to 5.4, but I have to wait for that before I port again to 5.8.5. Not sure if that's going to be a show stopper for testing the VPU or not. I thought with the va interface I wouldn't need that. Any tips on what to try next would be appreciated. Here is the output from the test. VPU TESTS ==== CHECK FOR DRIVERS Drivers: hantro-vpu rkvdec ==== LIST DEVICES Video Devices: /dev/video1 /dev/video2 /dev/video0 Media Devices: /dev/media1 /dev/media0 ==== DUMP FORMATS AND CONTROLS ++++ /dev/video1: |---------------------------------------------------- JPEG Compression Controls compression_quality 0x009d0903 (int) : min=5 max=100 step=1 default=50 value=50 ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [0]: 'JPEG' (JFIF JPEG, compressed) |---------------------------------------------------- ++++ /dev/video2: |---------------------------------------------------- mpeg_2_slice_parameters 0x009909fa (unknown): type=103 flags=has-payload mpeg_2_quantization_matrices 0x009909fb (unknown): type=104 flags=has-payload vp8_frame_header 0x009910d0 (unknown): type=301 flags=has-payload ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [0]: 'NV12' (Y/CbCr 4:2:0) |---------------------------------------------------- ++++ /dev/video0: |---------------------------------------------------- Codec Controls h264_level 0x00990a67 (menu) : min=0 max=15 default=0 value=0 h264_profile 0x00990a6b (menu) : min=0 max=6 default=2 value=2 vp9_profile 0x00990b00 (menu) : min=0 max=0 default=0 value=0 hevc_profile 0x00990b67 (menu) : min=0 max=2 default=0 value=0 hevc_level 0x00990b68 (menu) : min=0 max=8 default=0 value=0 h264_sequence_parameter_set 0x00990ce8 (unknown): type=110 flags=has-payload h264_picture_parameter_set 0x00990ce9 (unknown): type=111 flags=has-payload h264_scaling_matrix 0x00990cea (unknown): type=112 flags=has-payload h264_slice_parameters 0x00990ceb (unknown): type=113 flags=has-payload h264_decode_parameters 0x00990cec (unknown): type=114 flags=has-payload h264_decode_mode 0x00990ced (menu) : min=1 max=1 default=1 value=1 h264_start_code 0x00990cee (menu) : min=1 max=1 default=1 value=1 hevc_sequence_parameter_set 0x00990cf0 (unknown): type=120 flags=has-payload hevc_picture_parameter_set 0x00990cf1 (unknown): type=121 flags=has-payload hevc_slice_parameters 0x00990cf2 (unknown): type=122 [16] flags=has-payload hevc_scaling_matrix 0x00990cf3 (unknown): type=123 flags=has-payload hevc_decode_mode 0x00990cf7 (menu) : min=1 max=1 default=1 value=1 hevc_start_code 0x00990cf8 (menu) : min=1 max=1 default=1 value=1 vp9_frame_context_0 0x009918a0 (unknown): type=400 flags=has-payload vp9_frame_context_1 0x009918a1 (unknown): type=400 flags=has-payload vp9_frame_context_2 0x009918a2 (unknown): type=400 flags=has-payload vp9_frame_context_3 0x009918a3 (unknown): type=400 flags=has-payload vp9_frame_decode_parameters 0x009918a4 (unknown): type=404 flags=has-payload ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [0]: 'NV12' (Y/CbCr 4:2:0) [1]: 'NV15' (10-bit Y/CbCr 4:2:0 (Packed)) [2]: 'NV16' (Y/CbCr 4:2:2) [3]: 'NV20' (10-bit Y/CbCr 4:2:2 (Packed)) |---------------------------------------------------- ==== SHOW HW ACCELS ffmpeg version n4.3.1-Kodi Copyright (c) 2000-2020 the FFmpeg developers built with gcc 7.5.0 (GCC) configuration: --prefix=/usr --arch=arm64 --target-os=linux --cross-prefix=aarch64-linux-gnu- --enable-cross-compile --sysr oot=/home2/qsys3/src/os/../aarch64-linux-gnu/install --pkg-config=aarch64-linux-gnu-pkg-config --enable-shared --disable-doc --enable-v4l2-request --enable-libdrm --enable-libudev --enable-pic --enable-avfilter --enable-postproc --enable-pthreads --e nable-gpl --enable-nonfree --enable-version3 --toolchain=hardened --enable-avfilter --enable-libfontconfig --enable-libfreety pe --enable-libxml2 --enable-openssl --enable-protocol=file --enable-protocol=pipe --enable-hwaccel=h264_vaapi --enable-hwacc el=hevc_vaapi --enable-hwaccel=mjpeg_vaapi --enable-hwaccel=mpeg2_vaapi --enable-hwaccel=mpeg4_vaapi --enable-hwaccel=vp9_vaa pi --enable-muxer=h264 --enable-muxer=mjpeg --enable-muxer=mpeg2video --enable-muxer=mp2 --enable-muxer=mp4 --enable-muxer=mo v --enable-muxer=null --enable-demuxer=mpegvideo --enable-demuxer=h264 --enable-demuxer=hevc --enable-demuxer=mov --enable-en coder=mjpeg_vaapi --enable-encoder=vp9_vaapi --enable-encoder=vp8_v4l2m2m --enable-encoder=vp8_vp8_vaapi --enable-encoder=hev c_vaapi --enable-encoder=hevc_v4l2m2m --enable-encoder=mpeg2_vaapi --enable-encoder=h264_vaapi --enable-encoder=h264_v4l2m2m --enable-encoder=wrapped_avframe --enable-encoder=pcm_s16le --enable-decoder=mjpeg --enable-decoder=vp9 --enable-decoder=vp8 --enable-decoder=vp8_v4l2m2m --enable-decoder=vp9_v4l2m2m --enable-decoder=hevc --enable-decoder=hevc_v4l2m2m --enable-decode r=h264 --enable-decoder=webp --enable-decoder=mpeg2video --enable-decoder=mpeg2_v4l2m2m --enable-decoder=mpeg4 --enable-decod er=mpeg4_v4l2m2m --enable-rpath --extra-ldflags=-ludev --libdir=/usr/lib --shlibdir=/usr/lib libavutil 56. 51.100 / 56. 51.100 libavcodec 58. 91.100 / 58. 91.100 libavformat 58. 45.100 / 58. 45.100 libavdevice 58. 10.100 / 58. 10.100 libavfilter 7. 85.100 / 7. 85.100 libswscale 5. 7.100 / 5. 7.100 libswresample 3. 7.100 / 3. 7.100 libpostproc 55. 7.100 / 55. 7.100 Hardware acceleration methods: vaapi drm |---------------------------------------------------- ==== SHOW VAINFO ++++ /dev/video1: |---------------------------------------------------- libva info: VA-API version 1.9.0 libva info: User environment variable requested driver 'v4l2_request' libva info: Trying to open /usr/lib/dri/v4l2_request_drv_video.so libva info: Found init function __vaDriverInit_1_9 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.9 (libva 2.9.0.pre1) vainfo: Driver version: v4l2-request vainfo: Supported profile and entrypoints |---------------------------------------------------- ++++ /dev/video2: |---------------------------------------------------- libva info: VA-API version 1.9.0 libva info: User environment variable requested driver 'v4l2_request' libva info: Trying to open /usr/lib/dri/v4l2_request_drv_video.so libva info: Found init function __vaDriverInit_1_9 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.9 (libva 2.9.0.pre1) vainfo: Driver version: v4l2-request vainfo: Supported profile and entrypoints |---------------------------------------------------- ++++ /dev/video0: |---------------------------------------------------- libva info: VA-API version 1.9.0 libva info: User environment variable requested driver 'v4l2_request' libva info: Trying to open /usr/lib/dri/v4l2_request_drv_video.so libva info: Found init function __vaDriverInit_1_9 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.9 (libva 2.9.0.pre1) vainfo: Driver version: v4l2-request vainfo: Supported profile and entrypoints |---------------------------------------------------- Tests completed. Here is the test script.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines