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]
<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?
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]