09:31 <bryanodonoghue> one thing that needs to be fixed is adding opps

09:32 <bryanodonoghue> so that we can have a list of clocks which ramp to different operating points based on the requested pixel clock

09:32 <bryanodonoghue> instead of applying the pixel clock to all clocks

09:32 <bryanodonoghue> which is obviously wrong

09:32 <bryanodonoghue> i.e. you don't request a pixel clock on an interconnect to your DRAM

09:32 <bryanodonoghue> ^ z3ntu

10:15 <z3ntu> bryanodonoghue: one thing I noticed just now is that on v6.17-rc when you're switching between two cams that have pixel clocks that fall into different buckets (e.g. one 380000000, the other 510000000) then when switching through the s_power callbacks the vfe_check_clock_rates returns EBUSY and the other cam fails

10:15 <z3ntu> in dmesg just "qcom-camss acb3000.isp: Failed to power up pipeline: -16" appears without any extra info, added a bunch of dev_err locally now

11:48 <z3ntu> bryanodonoghue: maybe you could try setting pixel clock to 2476800000 in your sensor driver, that should pick the rate 510000000 instead of 380000000, at least on sc7280. But then somehow during the second vfe_get (from vfe_set_power, first is through vfe_parent_dev_ops_get) the rate becomes 380000097 and we fail with EBUSY

12:35 <matt_> ping

12:35 <matt_> I'm running into the issue of USB 2.0 not working on sc7280 when I plug in a pair of NReal Air XR glasses, which are usually showing up with Soundcard/HID on USB 2.0. The displayport functionality works fine, but the USB functionality doesn't. `lsusb` shows nothing more than a root hub without anything on it. https://lore.kernel.org/lkml/c2f2ba36-1a25-450e-99b9-79aa4fd4913d@linaro.org/

12:36 <Guest26383> I've noticed that if I kexec, I can cause it to show up on the USB 2.0, according to lsusb, but display port functionality I believe stops then

13:18 <konradybcio> matt as you can read in that thread, fixing this will require more work which is yet to be done..

14:48 <bryanodonoghue> so you are connecting two different PHYs to the same CSID/VFE chain one-after-the-other ?

14:48 <bryanodonoghue> z3ntu

14:50 <z3ntu> bryanodonoghue: I'm not doing anything on purpose, libcamera seems to choose those. But I think essentially it's keeping the chain, just replacing the phy in the beginning

15:30 <alexeymin> konradybcio: do you remember if this went anywhere? https://lore.kernel.org/all/20240709-topic-smem_speedbin-v5-4-e2146be0c96f@linaro.org/

15:31 <alexeymin> I'm specifically interested in this particular common code to handle speedbins between a5xx and a6xx, not the SMEM ones :)

15:33 <matt-dontrename> konradybcio: I've been stalking the mailing list looking for anything that could relate, I was wondering if you could point me in a direction that allows me to learn more about the topic, and if there's any way to follow it closer

15:33 <matt-dontrename> Specifially in that thread, the participants mention they know nobody with such a device, and that they don't have the necessary adapters to perform testing, so it seems like it's not going to go anywhere

15:36 <matt-dontrename> Is there any guidance or documentation on how to submit a bug report like this to the LKML? I don't want to be annoying, but I can't get all the information I need out of that thread alone, it's not informative enough and doesn't contain enough context. For example there is an incomplete patch inside that suggests it is a workaround, that doesn't contain the struct for the function mode_fn

15:45 <matt-dontrename> I've kind of hit my knowledge limit and want to learn more, I've read the dwc3 usb3 databook and I could continue to read it, but I feel like I need to ask for directions or pointers on how to learn more at least