ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
stikonas has quit [Remote host closed the connection]
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #linux-rockchip
kevery has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 245 seconds]
kevery1 is now known as kevery
archetyp has quit [Quit: Leaving]
matthias_bgg has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
warpme_ has quit [Quit: Connection closed for inactivity]
cp- has quit [Read error: Connection reset by peer]
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 246 seconds]
lurchi_ is now known as lurchi__
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 245 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 250 seconds]
kevery1 is now known as kevery
urja has quit [Read error: Connection reset by peer]
matthias_bgg has quit [Ping timeout: 265 seconds]
urja has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
stikonas has joined #linux-rockchip
matthias_bgg has quit [Quit: Leaving]
kevery has quit [Ping timeout: 245 seconds]
kevery has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
wens has quit [Ping timeout: 260 seconds]
wens has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 265 seconds]
kevery1 is now known as kevery
matthias_bgg has quit [Ping timeout: 240 seconds]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 265 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 240 seconds]
kevery1 is now known as kevery
matthias_bgg has joined #linux-rockchip
kevery has quit [Quit: kevery]
dvergatal has joined #linux-rockchip
<dvergatal>
hi long time no see:P i haven't noticed that freenode has been hijacked
<dvergatal>
by the way i have a question maybe some one will be able helping in solveing it, i have switched on my firefly-rk3399 board from kernel 4.4.194 to mainline 5.4.18 because of WPA3 support on it from cypress+infenon and now my udc support is not working
<dvergatal>
with kernel 4.4.194 i had this fe800000.dwc in /sys/class/udc but now it's gone
<dvergatal>
and dwc3 support is being turned on in the kernel
archetyp has joined #linux-rockchip
<dvergatal>
sorry should be fe800000.dwc3
<dvergatal>
and i really need it for gadget manipulation
<mmind00>
dvergatal: so you switched from Rockchip's vendor-kernel to mainline, right? fe800000 is a dwc3 and on mainline there is no gadget support right now
<mmind00>
dvergatal: this has to do with the rockchip type-c phys missing the interaction with the fusb302 type-c ics you probably have on the board
<mriesch>
mmind00: but the mainline dwc3 driver is in principle able to serve as gadget, right?
<mmind00>
mriesch: correct
<mmind00>
mriesch: the issue is the fusb302 -> rockchip-typec-phy -> dwc3 part
<mriesch>
OK...this interaction would require some glue driver dwc3-rockchip.c i could imagine?
<mmind00>
mriesch: not at all
<mmind00>
mriesch: on chromeos it's cros-ec -> rockchip-typec-phy -> dwc3 and the ChromeOS people invented a stopgap solution by using an extcon to connect between cros-ec and rockchip-typec-phy
<mmind00>
mriesch: the kernel _does have_ a type-c framework for this, but at the time the rk3399-gru series was conceived that was still really new
<mmind00>
mriesch: from what I gathered, the cros-ec-driver can nowadays hook into the kernel's type-c framework, but nobody looked at this for the rk3399-gru series yet
<mmind00>
mriesch: so in fact the rockchip-typec-phy driver needs to be converted to talk to the kernel's type-c framework
<mriesch>
mmind00: ah ok.. and there has to be a driver for the fusb302, which is on the other end i guess?
<mmind00>
mriesch: the fusb302 has a driver in the kernel for a long time :-)
<mmind00>
mriesch: but it needs to transmit the state to the rockchip-typec-phy (host vs. gadgets, altmodes, etc)
<mriesch>
mmind00: ah OK.. that's convenient :-)
<mmind00>
mriesch: as we don't have this transfer right now, the rockchip-typec-driver always sets itself to host-mode without the extcon
<mmind00>
mriesch: in the rockchip vendor-kernel they hacked that extcon thingy into the fusb302 driver, but that is of course no viable solution for mainline ;-)
<mriesch>
mmind00: ...one wonders why not ;-) thanks for the explanation!
<mmind00>
mriesch: because we have a _real_ type-c framework now in the kernel :-D
<mmind00>
mriesch: essentially it should be possible to do both somehow ... check for extcon presence and otherwise use the type-c framework in the kernel ... but that needs someone with time ;-)
jakllsch has joined #linux-rockchip
<dvergatal>
mmind00: yeah you are right
<dvergatal>
mmind00: so what could i do?
<dvergatal>
could -> can
dsimic has joined #linux-rockchip
<dsimic>
it's already on my TO-DO list to implement that properly :)
<dsimic>
I hope to be able to get that done in the next couple of months
<wens>
mmind00: I'm not sure ChromeOS will deal with this... depends on the hardware design. IIRC gru is somewhat different from the SBCs with regards to type-C stuff
<dsimic>
as a note, my primary motivation is to make the Type-C port on the Pinebook Pro working properly, in an upstreamable fashion
<wens>
also somewhat perplexing to me after reading the datasheets is nobody is using the PD stuff in the SoC?
<wens>
s/PD/type-C CC/
<clarity>
Any idea how to check what bus speed mode an sd card is currently using?
<wens>
cat /sys/kernel/debug/mmc?/ios
<wens>
clarity: ^
<dsimic>
that should be available in the kernel messages produced upon inserting the card
<clarity>
Thank you wens
<clarity>
dsimic: dmesg tells you what the card supports, not what the bus ends up using
<clarity>
I think
<dsimic>
nope, here's an example:
<dsimic>
[27801.603360] mmc1: new ultra high speed SDR104 SDHC card at address 5048
<clarity>
That's what the card supports
<dsimic>
nope, that's what the card ended up running at
<dsimic>
for example, the same cards registers at different speed when the interface speed is limited in the DT
<dsimic>
here's an example:
<dsimic>
[ 1.946439] mmc1: new high speed SDHC card at address 5048
<dsimic>
I really hope to get to the bottom of those microSD card issues, which have plagued all kinds of different SBCs for, well, decades :/
<clarity>
Reminds me of a funny issue.. I got some cards that seem to work just fine after a cold boot but not after reset
<clarity>
I believe those cards are counterfeits though. But they do work on some other boards.
<dsimic>
it could've been caused by the reset not power cycling the cards... once switched to 1.8 V, cards need to be power cycled to become available for negotiation again
<clarity>
You mean 1.8V IO?
<clarity>
Or supply voltage?
<wens>
IO
<urja>
IO (the supply never changes, IIRC)
<clarity>
I recall reading about some cards that can do 1.8v supply too but I'm not sure
<clarity>
(And yes I know there are [UHS-II?] cards that have two supply voltages but that's not what I'm thinking about)
<mmind00>
wens: essentially the cros-ec extcon is somewhat in the way of using the kernel's type-c framework ... from what I gathered on gru its: fusb302 -> cros-ec -> extcon -> rockchip-typec-phy -> dwc3 ... while _all_ other designs do this directly - i.e. fusb302 -> rockchip-type-c phy ... as far as I can tell the cros-ec also now can hook into the kernel's type-c framework
<mmind00>
wens: for PD I guess having the fusb302 enabled alone might be enough for power? ... i.e. some boards do have them declared ... that probably gives them the PD part, but then not the gadget/alt-mode
<dvergatal>
mmind00: i'm sorry but now i am little bit confused
<dvergatal>
mmind00: from what i understood the rockchip-typec-phy drive isn't talking tothe kernel's type-c framework right?
<mmind00>
dvergatal: correct ... while the fusb302 does expect everything to go through the typec framework
<dvergatal>
mmind00: ahhhaaa
<mmind00>
dvergatal: and the vendor-kernel hacked up the fusb302 driver to create a shortcut
Rathann has quit [Ping timeout: 252 seconds]
<dvergatal>
ok now i see
<dvergatal>
because all traffic from fusb302 is being pushed straigth forward to rockchip-typec-phy which in fact should connect with type-c framework
dsimic has quit [Quit: Client closed]
<dvergatal>
mmind00: so basically if i would connect first with cros-ec than i would fix the issue?
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-rockchip
<mmind00>
dvergatal: not sure I understand what you mean ... cros-ec is specific to ChromeOS devices ... and in this case it essentially fullfills the function of the fusb302 on other boards
<dvergatal>
mmind00: aahhh ok i'm not talking about ChromeOS devices let's forget about them for now
<mmind00>
dvergatal: the thing to do would be to modify the rockchip-typec-phy driver to either use the extcon (backwards compatiblity) or the type-c framework
<dvergatal>
ahaa
<dvergatal>
type-c framework i suspect is a new solution?
<mmind00>
dvergatal: "newish" ... 2016 when Gru came, it was under review but was merged around that time as well
<dvergatal>
mmind00: i'm sorry but i dunno what is Gru
<mmind00>
dvergatal: sorry ... Gru is the ChromeOS-device-series based on the rk3399
<dvergatal>
mmind00: i know gru is from this cartoon picture:P
<dvergatal>
mmind00: don't mind :]
<mmind00>
dvergatal: exactly ... Kevin is the Samsung Chromebook Plus for example ... others are Bob and Scarlett ;-)
<dvergatal>
mmind00: hahahahah really?
<mmind00>
dvergatal: yep, ChromeOS has cool (internal) names for their devices
<dvergatal>
i didn't know it i'm not picky
<dvergatal>
mmind00: today i have discovered that freenode was hijacked
<mmind00>
dvergatal: like the rk3288-series from 2014 ... cartoon mice ... mickey, pinky, jerry, etc :-D
<norris>
*Scarlet (not 2 T's) ;)
<norris>
mmind00: sorry, I couldn't resist; people would misspell it here all the time too
<mmind00>
norris: :-D
wens_ has joined #linux-rockchip
dvergata1 has joined #linux-rockchip
indy_ has joined #linux-rockchip
macromorgan has quit [*.net *.split]
matthias_bgg has quit [*.net *.split]
dvergatal has quit [*.net *.split]
wens has quit [*.net *.split]
indy has quit [*.net *.split]
anarsoul has quit [*.net *.split]
lopsided98 has quit [*.net *.split]
kilobyte_ch has quit [*.net *.split]
anarsoul has joined #linux-rockchip
macromorgan has joined #linux-rockchip
lopsided98 has joined #linux-rockchip
kilobyte_ch has joined #linux-rockchip
wens has joined #linux-rockchip
dvergatal has joined #linux-rockchip
sigmaris_ has joined #linux-rockchip
wens_ has quit [Ping timeout: 265 seconds]
shailangsa has quit [Ping timeout: 265 seconds]
dvergata1 has quit [Ping timeout: 265 seconds]
sigmaris has quit [Ping timeout: 265 seconds]
clarity has quit [Ping timeout: 265 seconds]
sigmaris_ is now known as sigmaris
macromorgan has quit [Quit: Leaving]
macromorgan has joined #linux-rockchip
lopsided98 has quit [Ping timeout: 245 seconds]
lopsided98 has joined #linux-rockchip
<amstan>
norris: samueldr is the guy excited about usb gadget on the grus i was telling you about
<amstan>
mmind00: you should see our latest project, we actually managed to convince the PMs to go with herobrine, it's glorious
<samueldr>
in my case it was on "dumo", a scarlet, but the same solution I still need to refresh, rebase on latest master, worked on the Pinebook Pro too... but I didn't do it "right", it assumes there is no way to detect the host/peripheral... orientation(?)... and rather uses the existing framework in Linux to control it through sysfs
<samueldr>
I felt it was incomplete because I didn't know much about detecting this, and didn't touch it since
<samueldr>
but it does work just fine; been using that to "flash" updates to the tablet whenever I broke my custom thing... since I've not looked into supporting chromeos-flavoured A/B yet (in fact, any A/B scheme yet)
vagrantc has joined #linux-rockchip
<mmind00>
amstan: had to google that ... I'm too old to know minecraft details :-D
<dvergatal>
mmind00: i'm back sorry you had to wait for me
<amstan>
samueldr: that's all information the cros_ec driver should have, so i'm optimistic
<mmind00>
dvergatal: I didn't wait for you :-P
<samueldr>
amstan: what is, host/peripheral "orientation" (what's the proper term already?) or A/B?
<dvergatal>
mmind00: :D
<amstan>
samueldr: yeah, i meant the orientation stuff
<samueldr>
A/B is really only a matter of not having looked into it yet; I want it to work through a platform abstraction layer that also handles qualcomm android devices, mediatek android devices, "standard" U-Boot A/B schemes
<amstan>
mmind00: my email copy is probably gone, but you might still have it, i sent a diagram about how usb was implemented on gru chromebooks
<samueldr>
I don't recall for sure if the commits previous to my own were all mainlined since
<dvergatal>
samueldr: so you have it done?
<amstan>
samueldr: yeah, there we go, norris 's link says look for EXTCON_PROP_USB_TYPEC_POLARITY
<dvergatal>
amstan: but from what i understood this is for chrome os not for linux?
<norris>
chrome os is linux :)
<samueldr>
dvergatal: on the caveat that it relies on "user provided" configuration for `dr_mode` through the role switch framework
<dvergatal>
norris: really? didn't know that
<amstan>
dvergatal: there were some downstream patches that made that work (they were submitted back when this was one of the first implementations)
<amstan>
upstream has since made it a lot nicer probably, but now there's functionality deltas
<norris>
dvergatal: but not all linux systems use the Chrome OS EC, obviously, so the extcon-usbc-cros-ec.c driver may or may not be relevant
<dvergatal>
norris: ahhaaa
<samueldr>
dvergatal: I'm using it with Mobile NixOS
<samueldr>
not chromeos
<dvergatal>
samueldr: i'm using buildroot
<dvergatal>
with glibc
<norris>
again, the point isn't the OS (we're all using Linux) -- it's what hardware (and type c controller) you're using
<norris>
the EC is hardware/firmware, present on all systems that shipped with Chrome OS
<samueldr>
and yeah, chromeos is Linux, and an example of a good citizen consumer with an upstream-ASAP policy [that I'd like chromeos people here to better explain if possible]
* mmind00
was about to type the same as norris :-)
<samueldr>
not mainline first; by this I mean they're using slightly vendor-flavoured LTS branches on actual devices [at least historically speaking]
<dvergatal>
ok so shortly speaking the problem is my board
<dvergatal>
which i'm using?
<mmind00>
dvergatal: the board isn't the problem ... it'll follow Rockchips reference design very closely I guess ... the problem is the missing code to handle that route
<mmind00>
dvergatal: no-one ever had the time and energy to implement the missing pieces
<dvergatal>
mhm
<samueldr>
amstan: *This Type-C PHY driver supports normal and flip orientation. The orientation is reported by the EXTCON_PROP_USB_TYPEC_POLARITY property: true is flip orientation, false is normal orientation.*
<samueldr>
sounds like it's more about the cable end being rotated 180° and not the host/peripheral relationship
<samueldr>
oh, yeah, I didn't want to imply sticking to LTS trees is bad :)
<dvergatal>
mmind00: ;] i'm sorry if i'm giving stupid questions but i'm being interrupted by my wife with her work problems:P
<samueldr>
but I'm not sure either, this reads like a vendor-provided blurb, and maybe their terminology is weird
<dvergatal>
and have to be multithreaded which is quit difficult for me....
<samueldr>
dvergatal: sorry if you stated so previously, didn't read carefully all of the backlog, can you succintly state your observations and current problem, in like 2~4 lines?
<mmind00>
dvergatal: darn human design ... only 1-core
<dvergatal>
mmind00: yeah;p
<samueldr>
(I want to make sure I'm not looking at a tangential issue to what you're dealing with)
<dvergatal>
samueldr: i'm dealing with missing peace of code for udc in mainline kernel for rockchip rk3399 platform
<mmind00>
samueldr: there are alot more extcon thingies in the typec-phy-driver ... (tcphy_get_mode() )
<dvergatal>
samueldr: and mmind00 have explained it to me and know i'm thinking how to painlessly solve this issue
<dvergatal>
has:P
<dvergatal>
know -> now
<samueldr>
[I'm multithreading too right now]
<dvergatal>
samueldr: :P your wife is disturbing you too?:P
<samueldr>
with this I am using ADB, and USB mass storage on the gru scarlet device
<dvergatal>
mmind00: correct me if i'm wrong, there are 2 ways to solve the issue, modify rockchip-typec-phy driver to use the extcon driver which will be backward compatible
<dvergatal>
samueldr: eeee you have it already done?
<samueldr>
yes, as I said, with the only caveat that it does not auto-detect the host/peripheral relationship like I think I understand may be possible
<dvergatal>
mhm
<samueldr>
and this implementation is not limited to gru rk3399 devices, but likely to any rk3399 devices, since it also works on the Pinebook Pro [untested on other devices]
<dvergatal>
samueldr: by this auto-detect the host/peripheral relationship you mean what?
<samueldr>
unsure really, this is at the point my domain-specific knowledge is stretched thin
<dvergatal>
mhm
<samueldr>
I believe setting the dr_mode through role switch in userspace is totally unnecessary, and depending on what is connected, the port should know whether it's a peripheral or a host
<dvergatal>
mhm
<samueldr>
"totally unnecessary" when both hardware and software have all the bits implemented
<dvergatal>
samueldr: mhm by the way do you have patches for this changes?
<mmind00>
correct ... similar to how usb2 can detect the OTG state (if a usb-stick is connected, or the port is connected to a host computer)
<mmind00>
type-c can of course detect if the other side is an usb stick or a host computer
<mmind00>
with the additional function that type-c can also support so called alternative modes ... like piping displayport output through it
<dvergatal>
samueldr: ok thx
<samueldr>
mmind00: nice to hear my mental model is accurate
<dvergatal>
samueldr: the 4 last?
<dvergatal>
nope 5
<samueldr>
four of the five for chromeos devices, another combination of four for the pinebook pro
<mmind00>
samueldr: the fusb302 that you probably have in the pinebook pro ... should already be able to detect all of this ;-)
<samueldr>
mmind00: possible! stretched thin!
<mmind00>
samueldr: we're essentially just missing the pathway to the soc
<samueldr>
both in knowledge and time :)
<mmind00>
hehe, all of us
<samueldr>
dvergatal: you **will** need to amend the device tree for your particular gru flavour, unless you happen to also use a scarlet
<dvergatal>
samueldr: nope i'm using firefly
<samueldr>
ah! I was led to understand it was a gru problem
<dvergatal>
samueldr: as u can see not only
<mmind00>
samueldr: not at all ... on Gru this autodetection was working in the past just fine
<samueldr>
then similarly still, it's likely you will need to amend the device tree, look at the last two commits to gauge how
<dvergatal>
samueldr: on my firefly board it is also not working
<samueldr>
mmind00: ¯\_(ツ)_/¯
<dvergatal>
as i said it before with vendor rockchip kernel it is and as mmind00 said: 14:30 < mmind00> mriesch: in the rockchip vendor-kernel they hacked that extcon thingy into the fusb302 driver, but that is of course no viable solution for mainline ;-)
<amstan>
note how the OTG_ID pin is just hanging in the air, someone has to convince dwc3 to take a software hint instead (from extcon/typec, whatever)
<amstan>
and how the CC pins are also unused (unlike maybe the pinebook pro)
<samueldr>
I think the PBP might have a similar issue; I think rockpro64 has something noted somewhere about that
<samueldr>
(it was unclear since it seems all individuals stating things weren't clear either on those details)
<amstan>
yeah, nvm, i heard something about fusb, that would just be an i2c connection to the AP, with a similar style driver (something exposing extcon/typec) as cros_ec
<amstan>
coincidentally, scarlet uses an fusb as that red TCPC block that the EC talks to
<samueldr>
so I guess something like extcon knowing about the existing role switch subsystem could work?
clarity has joined #linux-rockchip
<amstan>
as far as i know cros_ec has all that implemented, so it does publish extcon type things (including gadget/host)
<amstan>
it's the dwc3 part and convincing it to use extcon instead of that special hardware gpio
<amstan>
.. that needs work
<samueldr>
right, so reversing the roles in my guess
<amstan>
the vendor driver (rockchip-4.4?) does something like that, but it was really hacky because it would just take down then reinstantiate the dwc driver depending on the extcon message
<samueldr>
so maybe something similar to what role switch can do, but a DT property like "dr_mode-through-cros_ec`
<amstan>
dr_mode-through-extcon perhaps, no need to hardcode it for cros_ec
<samueldr>
sorry if I do some mixups in terminology :)
<amstan>
see that first diagonal line on the left in my diagram? going between cros_ec and the dwc3?
<samueldr>
and something like `extcon = <&usbc_extcon0>;` to refer to the appropriate node
<amstan>
that's extcon (it's possible these days that is deprecated and typec framework has to be used instead)
<amstan>
the dwc3 side of that line needs work
<samueldr>
I see
<samueldr>
I think
<dvergatal>
ok i'm back had another distractors;p
<amstan>
dvergatal: diagram!
<amstan>
heh
<dvergatal>
?
<dvergatal>
amstan: what diagram?
<amstan>
see scrollback a little above, might help with this
<dvergatal>
with mine problem?
<samueldr>
amstan: I'm led to understand dvergatal is not working on a GRU board though
<amstan>
heh, have one of those and usb gadget was working pretty well with the vendor kernel a few years ago
<dvergatal>
yeah with vendor it is working
<dvergatal>
but vendor is 4.4.194
<amstan>
but it's possible it has a different topology, maybe even that OTG_ID pin connected
<dvergatal>
and i have switched to 5.4.18 because of wpa3 support
<dvergatal>
i think i could use wpa3 with the vendor one too but still it is bloody old rubbish with no mesh and etc.
<amstan>
dvergatal: also, there might be rockchip fork in here, sometimes they very happy to help too
<dvergatal>
fork? you mean folks?
<amstan>
heh, yes
<dvergatal>
:)
<dvergatal>
amstan: mmind00 has already told what i should do but i don't have expierience in modifing kernel drivers
<dvergatal>
experience*
<amstan>
we all started there, honestly idk if i could do it either (tried once, gave up)
<dvergatal>
:]
<amstan>
so here i am drawing diagrams of what i researched and evangelizing the feature on irc instead
<dvergatal>
hehehehehe
<dvergatal>
and someone will write it for you?
shailangsa_ has quit []
<dvergatal>
i'm sorry i have great experience on a security field with ciphers rather than kernel...
<amstan>
i mean, i don't really need it anymore 5 years later, but it's nice to know that others are interested too
<dvergatal>
aaahhh ok
<dvergatal>
for now it is not as much important but it would be nice because i have it configured with systemd
<dvergatal>
the adb daemon
unkraut has quit [Ping timeout: 240 seconds]
manawyrm has quit [Ping timeout: 240 seconds]
CounterPillow has quit [Ping timeout: 240 seconds]
mriesch has quit [Ping timeout: 264 seconds]
mx08 has quit [Ping timeout: 246 seconds]
<dvergatal>
you know in the past i was a huge opponent to the systemd but know i see some advantages in this system
manawyrm has joined #linux-rockchip
mriesch has joined #linux-rockchip
CounterPillow has joined #linux-rockchip
mx08 has joined #linux-rockchip
crabbedhaloablut has quit [Write error: Connection reset by peer]
unkraut has joined #linux-rockchip
crabbedhaloablut has joined #linux-rockchip
<dvergatal>
mmind00: btw. i see that i don't have even PHY_ROCKCHIP_TYPEC in my kernel turned on:P
<dvergatal>
TYPEC_FUSB302 is also turned off
shailangsa has joined #linux-rockchip
<dvergatal>
ok PHY_ROCKCHIP_TYPEC is however on but TYPEC_FUSB302 is off
<amstan>
do you have an fusb on the board?
<amstan>
they're kind of mutually exclusive depending on how the board is made
<dvergatal>
amstan: i don't know
<amstan>
check the schematics
<dvergatal>
I'm in the dark when I read what mmind00 wrote
<dvergatal>
becaue he has written that on on chromeos it's cros-ec -> rockchip-typec-phy -> dwc3 and the ChromeOS people invented a stopgap solution by using an extcon to connect between cros-ec and rockchip-typec-phy
<mmind00>
amstan: PHY_ROCKCHIP_TYPEC is the mode-multiplexer inside the soc
<dvergatal>
this doesn't concern me because i'm not on chromeos
<amstan>
mmind00: yeah, it's the driver that would go on those pins that aren't connected in my diagram
<mmind00>
amstan: and most boards do use the fusb302
<amstan>
my question is: are those pins used on the rockpro, or is it an i2c fusb302?
<dvergatal>
mmind00: yes that is what i wanted to write;p
<amstan>
oh, nvm, i'm wrong, ok
<amstan>
it is the multiplexer
<dvergatal>
mmind00: btw. i do not see fusb302 driver in their old 4.4.194 kernel
<dvergatal>
i see it is in 5.4.18
<mmind00>
dvergatal: drivers/mfd/fusb302.c ?
<mmind00>
for the 4.4
<dvergatal>
so i do not understand this sentence: 18:52 < mmind00> dvergatal: and the vendor-kernel hacked up the fusb302 driver to create a shortcut
<dvergatal>
hmmm
<dvergatal>
gimme a sec
<dvergatal>
ooo you are right
<mmind00>
dvergatal: but I still do have to correct myself ... Rockchip did write an own driver for the fusb302 ... not hacked up the mainline one ;-)
<dvergatal>
ok:P
<dvergatal>
mmind00: btw. it is not in the config file
<dvergatal>
i'm unable to turn it on/off
<mmind00>
check for CONFIG_FUSB_30X
<dvergatal>
ok this one is
<mmind00>
the config symbol is just named strangely
<dvergatal>
mmind00: ok and this is the same as TYPEC_FUSB302?
<mmind00>
dvergatal: it's the same chip ... but the driver implementation is vastly different
<dvergatal>
mhm so the solution for me is to add modifications to this driver so it would inform the PHY_ROCKCHIP_TYPEC
<dvergatal>
mmind00: btw. by saying this: 19:01 < mmind00> dvergatal: the thing to do would be to modify the rockchip-typec-phy driver to either use the extcon (backwards compatiblity) or the type-c framework you meant to either modify PHY_ROCKCHIP_TYPEC with EXTCON or TYPEC_FUSB302 ?
<mmind00>
dvergatal: typec_fusb302 is fine as it is ... phy_rockchip_typec needs modifications to be able to use the real type-c framework in the kernel
<mmind00>
dvergatal: the extcon was a sort of stopgap solution because at the time there wasn't a type-c framework in the kernel yet
<dvergatal>
mmind00: ok i'm sorry for keep asking question but my problem is that i dunno what is type-c framework
<dvergatal>
questions
<mmind00>
dvergatal: while the fusb302 seems to be the most-used ic for this, there are others available as well, which boards may use ... so adding a separate additional extcon hack circumventing the type-c framework to each and everyone of them won't be accepted
<mmind00>
dvergatal: drivers/usb/typec/* :-)
<mmind00>
dvergatal: there is even a subdirectory "mux" ... which is essentially the stuff that the phy_rockchip_typec does on the rk3399
<dvergatal>
ahhaaaaa
<dvergatal>
so typec_fusb302 is type-c framework ?
<dvergatal>
mmind00: one of available and there are others ofcourse but for different hardwares?
<mmind00>
dvergatal: depends on the board-maker ... i.e. phy_rockchip_typec is part of the rk3399 itself ... while the fusb302 is just an i2c-connected chip on the board itself
<mmind00>
dvergatal: so board manufacturers could very well select a different type-c chip
<dvergatal>
mmind00: yeah that is what i meant
<dvergatal>
mmind00: ok so technicaly i will use the type-c framework in phy_rockchip_typec wich will know to use typec_fusb302 to make a call
<dvergatal>
mmind00: to dwc3
<mmind00>
dvergatal: essentially yes ... and you should be able to get inspiration from the other "muxes" on how that works .... there is probably also documentation
<dvergatal>
mmind00: thank you now i understand it all :D
<dvergatal>
mmind00: the reall problem would be to implement this because as i said i have no experience in writting in kernel code
<dvergatal>
mmind00: btw. by muxes i meant different type-c chips?
<dvergatal>
i -> you
<mmind00>
dvergatal: yep ... i.e. the drivers for specific chips in the mux subdirectory provide in theory the same functionality on other hardware that the phy_rockchip_typec does on rk3399 ... so should be good as examples
<mmind00>
at least it looked that way when I looked at it an hour ago :-)
<dvergatal>
ok
<dvergatal>
mmind00: thx for help
<dvergatal>
mmind00: now for somehting completly different, remember when we talked last time about optee? i have a question maybe you know if rockchip supports optee on other platforms than rk3399, px30 and rk322x?