rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 252 seconds]
specing_ is now known as specing
apritzel has quit [Ping timeout: 240 seconds]
gaston1980 has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 252 seconds]
jstefanop has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 240 seconds]
victhor has quit [Ping timeout: 265 seconds]
buzzmarshall has quit [Remote host closed the connection]
brkiddo has joined #linux-sunxi
azend has quit [Ping timeout: 252 seconds]
azend has joined #linux-sunxi
gediz0x539 has joined #linux-sunxi
brkiddo has quit [Ping timeout: 240 seconds]
brkiddo has joined #linux-sunxi
gnarface has quit [Ping timeout: 240 seconds]
gnarface has joined #linux-sunxi
daregap has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
camus has joined #linux-sunxi
camus is now known as kaspter
cmeerw has joined #linux-sunxi
jstefanop has joined #linux-sunxi
cmeerw has quit [Ping timeout: 260 seconds]
jstefanop has quit [Ping timeout: 240 seconds]
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-sunxi
apritzel has quit [Ping timeout: 246 seconds]
matthias_bgg has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
hlauer has joined #linux-sunxi
tnovotny has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
camus is now known as kaspter
apritzel has joined #linux-sunxi
<apritzel> jernej: I think I found the H616 USB issue - again ;-)
<apritzel> as smaeul hinted the BROM de-asserts the HCI2 reset line
<apritzel> when booting via FEL, that is, and in this case it keeps it de-asserted
<apritzel> so that's RST_BUS_EHCI2 in mainline CCU lingo
<apritzel> on top of that we also need RST_USB_PHY2 and CLK_USB_PHY2
<apritzel> so when I boot via FEL, then it tends to work with just the normal setup, which explains why I saw it working before
<apritzel> I played a bit with those reset and clock gates, and it looks like it it's exactly those three bits (and all of them) that make it work
tnovotny has quit [Read error: Connection reset by peer]
<apritzel> so what works today is to add RST_BUS_EHCI2 to the resets property and also use "phys = <&usbphy 1>, <&usbphy 2>;", the latter taking care of the two other bits
tnovotny_ has joined #linux-sunxi
<apritzel> adding RST_USB_PHY2 to resets didn't work: it triggered a warning: WARNING: CPU: 3 PID: 35 at drivers/reset/core.c:765 __reset_control_get_internal+0x74/0x170
tnovotny__ has joined #linux-sunxi
tnovotny_ has quit [Ping timeout: 240 seconds]
<apritzel> that is about this reset line not being share-able, but interestingly that approach works for the RST_BUS_OHCIx lines (we use that for ages already, to share between OHCI and EHCI)
yann has quit [Remote host closed the connection]
<apritzel> mripard, wens: any idea why this reset line sharing ^^^^ works for RST_BUS_OHCIx, but not for RST_USB_PHY2?
<apritzel> I thought the "shared" in devm_reset_control_array_get_optional_shared() (in ehci-platform.c) allows this?
<MoeIcenowy> apritzel: I think all reset users need to be shared
<apritzel> MoeIcenowy: ah, you mean it's the PHY code requesting it non-shared?
<MoeIcenowy> maybe
<apritzel> good hint, will give it a try
<MoeIcenowy> yes, it's devm_reset_control_get
chewitt has quit [Read error: Connection reset by peer]
chewitt_ has joined #linux-sunxi
specing has quit [Ping timeout: 252 seconds]
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-sunxi
yann has joined #linux-sunxi
specing has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 5.0.1, revision: 5.0.1+git-7433-0df9f22f2, build type: debug, sources date: 20160102, built on: 2019-12-08 19:19:20 UTC 5.0.1+git-7433-0df9f22f2 http://www.kvirc.net/]
<apritzel> MoeIcenowy: as usual you were spot on: it works now, and is the least hackish solution I have so far ;-)
Mangy_Dog has joined #linux-sunxi
Mangy_Dog has quit [Changing host]
Mangy_Dog has joined #linux-sunxi
chewitt_ is now known as chewitt
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
victhor has joined #linux-sunxi
tnovotny__ has quit [Quit: Leaving]
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 246 seconds]
specing_ is now known as specing
\\Mr_C\\ has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
jstein has joined #linux-sunxi
choozy has joined #linux-sunxi
sunshavi has quit [Read error: Connection reset by peer]
jstefanop has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 240 seconds]
jstefanop has quit [Ping timeout: 240 seconds]
uis has quit [Quit: ZNC 1.7.5 - https://znc.in]
uis has joined #linux-sunxi
random_yanek has quit [Ping timeout: 260 seconds]
random_yanek has joined #linux-sunxi
shailangsa has quit [Ping timeout: 252 seconds]
matthias_bgg has joined #linux-sunxi
<MoeIcenowy> apritzel: the clock framework is different to the reset one: when you get a clock, by default it's shared, but when you get a reset by default it's exclusive; and people tend to use the default value unless some change required
<MoeIcenowy> (we are now facing the "some change required" situation
<MoeIcenowy> BTW the regulator framework have another interesting default behavior: it's optional by default
<MoeIcenowy> (when it's not present, a "dummy regulator" is generated and returned back
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
<apritzel> MoeIcenowy: nice summary, thanks!
<apritzel> so what I have works nicely with the host controllers, but the MUSB is not covered yet
<apritzel> that is not a problem in practice, since we typically have at least one HCI activated, so the controller 2 resets are de-asserted
<apritzel> but if you would just use the OTG alone, this wouldn't happen
<apritzel> and the binding and code only allow for one reset and clock gate
<apritzel> I might just change that to the "bulk" version, does that sound reasonable?
tnovotny has joined #linux-sunxi
shailangsa has joined #linux-sunxi
sunshavi has joined #linux-sunxi
hlauer has quit [Ping timeout: 252 seconds]
matthias_bgg has quit [Ping timeout: 252 seconds]
JohnDoe0 has joined #linux-sunxi
choozy has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
JohnDoe9 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 240 seconds]
JohnDoe0 has quit [Ping timeout: 240 seconds]
<MoeIcenowy> apritzel: bulk seems to be only a helper for multiple independent ones
<apritzel> well, yeah, it would just work with one or more resets
<apritzel> in this case for MUSB to work we need the MUSB reset + the EHCI2 reset, so just changing the MUSB code to use bulk would cover both the existing users and the H616
<apritzel> I mean we *could* check the H616 compatible, and ask for a second and third reset in this case, but this might just work until the next AW hiccup
<apritzel> using bulk would give us some freedom to just cover future cases via the DT
sunilmohan has quit [Ping timeout: 252 seconds]
<mripard> not really though, we would have to change the bindings every time anyway
<mripard> and you would lose the ability to check whether all the reset lines for that particular controller are actually there
<apritzel> mripard: I knew you would say that ...
atsampson has quit [Ping timeout: 276 seconds]
<apritzel> was worth a shot anyway ;-)
atsampson has joined #linux-sunxi
<mripard> my pleasure :)
sunshavi has quit [Read error: Connection reset by peer]
Mangy_Dog has quit [Remote host closed the connection]
tnovotny has quit [Quit: Leaving]
sunshavi has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
cmeerw has joined #linux-sunxi
jstefanop has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
Mangy_Dog has quit [Remote host closed the connection]
choozy has joined #linux-sunxi
nashpa has quit [Ping timeout: 252 seconds]
nashpa has joined #linux-sunxi
nashpa has quit [Ping timeout: 240 seconds]
<jernej> apritzel: nice finding
<jernej> so with this board becomes somewhat usable
<apritzel> well, I hope that this is actually true ;-)
nashpa has joined #linux-sunxi
<jernej> didn't you test it alteady
<apritzel> but yeah, port 1 now seems to work for me
<jernej> *already?
<apritzel> I am fairly confident that port 1 works, but I though this the last times as well, so became a bit cautious
<apritzel> for instance I figured that booting via FEL is different compared to booting via SD card
<jernej> how many USB ports is on X96?
<jernej> I have 2 on T95
<apritzel> just two
<apritzel> the Tanix TX6s seems to have three
<apritzel> on the X96 it's port 0 (for OTG/FEL) and port 2 (which is the only sane one that works out of the box)
camus has joined #linux-sunxi
<apritzel> so I will do some final experiments tonight, to confirm that this is all working, and then send what I have
<apritzel> for instance I need to wire something up to USB3 on the OrangePi, and see how this behaves
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
gaston1980 has quit [Quit: Konversation terminated!]
<jernej> yeah, this bug is strange, but nothing catastrophic
gaston1980 has joined #linux-sunxi
<jernej> such bug is already present in other socs, like mixer0 and mixer1 or CSI and deinterlace core
<apritzel> do we know how close the A100 and A133 are?
<jernej> I'm not sure anyone has any experience with these two
<apritzel> from the mainline submissions it seems like the A100 shares a lot with the H616 (USB PHY, MMC DMA in words, etc.)
<apritzel> the differences seem more like target market differentiations, A100: only 2 USB, no HDMI; H616: 4 USB, no LCD (not connected))
sunilmohan has joined #linux-sunxi
sunilmohan has joined #linux-sunxi
sunilmohan has quit [Changing host]
azend_ has joined #linux-sunxi
azend has quit [Ping timeout: 252 seconds]
sunshavi has quit [Remote host closed the connection]
elros1 has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
elros1 has quit [Remote host closed the connection]
Ntemis has joined #linux-sunxi
vagrantc has joined #linux-sunxi
sunshavi has joined #linux-sunxi
hlauer has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
JohnDoe9 has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
brkiddo has quit [Remote host closed the connection]
brkiddo has joined #linux-sunxi
brkiddo has quit [Remote host closed the connection]
brkiddo has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 246 seconds]
brkiddo has quit [Ping timeout: 240 seconds]
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #linux-sunxi
elros1 has joined #linux-sunxi
abelvesa_ has quit [Quit: leaving]
abelvesa has joined #linux-sunxi
choozy has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
cmeerw has quit [Ping timeout: 250 seconds]
Mangy_Dog has quit [Ping timeout: 268 seconds]
Mangy_Dog has joined #linux-sunxi
Mangy_Dog has quit [Changing host]
Mangy_Dog has joined #linux-sunxi
megi has quit [Ping timeout: 260 seconds]
megi has joined #linux-sunxi
buzzmarshall has joined #linux-sunxi
hlauer has quit [Ping timeout: 240 seconds]
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-sunxi
<apritzel> dammit, was almost there with the USB on the H616 (every port worked with FEL booting), but booting from SD card breaks it again :-(
<anarsoul|2> sounds like something's up with clocks
Ntemis has quit [Read error: Connection reset by peer]
swiftgeek has quit [Changing host]
swiftgeek has joined #linux-sunxi
<apritzel> so I gated all PHY and HCI clocks, and also asserted all resets before booting Linux
<apritzel> when I boot from FEL, that works (meaning Linux enables everything needed), but when I boot from SD it doesn't work
<apritzel> so I assume the BROM must set up something else
<apritzel> which is somewhat weird, since all affected IP should be in reset in any case
<apritzel> smaeul: you mentioned the BROM setting something up USB related, do you have an address where I could start looking/disassembling?