neggles / linux-quartz64

Development kernel for QuartzPro64
Other
17 stars 13 forks source link

Contributing back to Collabora's upstreaming effort #1

Open Googulator opened 1 year ago

Googulator commented 1 year ago

Hi,

In my fork of this repo, I have successfully ported the USB-DP PHY driver from the vendor kernel - for now, it works with the 2nd USB 3.x type-A port on the Rock 5B. (There is still some issue with the Type-C port, probably related to orientation sensing, so it doesn't work at the moment.)

Unfortunately I haven't been able to find the actual repository where ported code is being staged before it is sent upstream as patches, so I'm posting here: if you (or anyone else reading this post) know where I can submit this code to the Collabora folks, please let me know.

Note that my goal with the fork (as the name "midstream" implies) is not to get code into an immediately upstreamable patch series form, but rather to get the board working with a recent, mainline-derived (i.e. non-Android) kernel, so the development history might be a little messy; I apologize for that.

alyssarosenzweig commented 1 year ago

Cc @sre

neggles commented 1 year ago

Hey! Sorry it's taken me so long to get to this, I've been all over the place lately 😓 (and thanks for the CC, Alyssa!)

I know Sebastian's been irregularly updating a tree at git.kernel.org with his patch set, and that's what my tree here is based off; otherwise I've just been keeping an eye on linux-rockchip and grabbing things from patchwork as they're posted.

I wouldn't worry too much about dotting your Is and crossing your Ts, so to speak - my own patches on top of sre's are not particularly pretty, heh. Code that functions is a massive improvement over no code at all, even if it needs some cleanup to meet upstream standards!

As for getting in contact with sre et al - assuming he doesn't drop in here - your best bet would probably be to drop him an email or reply to one of the RK3588 threads on linux-rockchip? To be quite honest I'm fairly new to the whole upstreaming process & have been trying to avoid stepping on anyone's toes, so not really sure myself.

(I really need to rebase this on upstream and sre's latest patch versions again, send out some updated versions of the PCIe controller/PHY/COMBPHY patches, ask some questions about devicetree things... I'm a little bit opinionated when it comes to DTs and it seems sre & I don't necessarily agree on how some things should be structured 😅. Hopefully will have some time for that this week...)

sre commented 1 year ago

Feel free to drop me a mail. While I do agree that having something working is useful, it is definitely not the same as having something upstream ready.

The more complex hardware blocks are a bit tricky to support, because the upstream clock controller handling is "missing" some bits downstream has. Specifically that is clocks with two parents. Figuring out a proper upstream solution for that will become interesting. rk356x already needed that for HDMI and for that the HDMI block is just referencing the extra parent clock directly. Right now the solution I upstreamed basically follows this way. It just handled the first parent for these clocks and ignores the second one. Unfortunately the TRM does not describe the clock tree at all :(

There's also some parts missing in the upstream power-domain controller, that I have not yet looked into and that seem to be required for USB2 and HDMI at least.