rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? - Don't ask to ask. Just ask and wait! - - Logs at - *only registered users can talk*
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 246 seconds]
specing_ is now known as specing
<tuxd3v> I keeprebooting, if I dount that it works, I will post a working case :)
<tuxd3v> dount-> know...I need my glasses on :)
pnill has joined #linux-sunxi
ganbold has joined #linux-sunxi
<apritzel> I had a working case before, but I need one now, with my debug prints in
<tuxd3v> ho.. so you need to reboot too :/
<apritzel> yeah, tried some times, now finally got a working case
<tuxd3v> when its working, the kernel per see, shows the patch, that was uploaded to the bluetooth device its version and the name and such in dmesg
<tuxd3v> then you just need as root to run:
<tuxd3v> bluetoothctl show
<tuxd3v> and it will print to you all the information, etc
jernej has joined #linux-sunxi
<tuxd3v> the problem is, that majority of times it doesn't work and you receive "No default controller available"
<tuxd3v> you can try to force powering it up, but it still doesn't show in the bluetooth deamon :(
<pnill> apritzel: somewhere along the line I broke my normal USB and can't fix it now -_-
<pnill> lol
<tuxd3v> hciconfig hci0 up
<apritzel> tuxd3v: yes, I understand all that, and that's not the problem
<tuxd3v> it takes some time to load the firmware patch to bluetooth, then you see the log messages in kernel , But bluetoothctl will continue to show you "No default controller available"
<apritzel> the device doesn't work early, and the reset command times out
<tuxd3v> indeed
<apritzel> the rest you see are all fall outs from this very problem
<tuxd3v> yup
<pnill> Since I was playing with the OTG gadget stuff I haven't really messed with this, I recall you saying disabling the OCHI devices and such you were able to get gadget working but I can't get normal USB working with a normal configuration now and everything should be how it was before... outside of maybe config changes to kernel but I can't see anything that would cause this musb is in dual mode... boot log: dts:
<pnill> I do see this now though: [ 0.165991] sun4i-usb-phy 5100400.phy: failed to get clock usb0_phy
<pnill> I don't recall seeing that before.
<pnill> and: [ 1.815896] usb_phy_generic supply vcc not found, using dummy regulator
<pnill> been messing with dts/menuconfig for a good hour or so playing with stuff trying to get it working again lol
<pnill> guess I should check if there's power going to the port, previously when that wasn't happening that's when you'd recommended adding the usb0_id_det-gpios line
qschulz has quit [Quit: qschulz]
<apritzel> pnill: but what board is this again? Do you actually have a micro-USB port on controller 0?
<pnill> I believe so, it's that board for that arcade.
qschulz has joined #linux-sunxi
<pnill> but the dts I gave is from the tanix h6 (it's an allwinner h6 soc)
<pnill> just modified for the pinout found on this board/information gathered before
<apritzel> yeah, I was confused about that Tanix in there
<apritzel> because those TV boxes don't have micro USB
<pnill> yeah... I just recalled using the tanix config before when I was messing with it
<pnill> have .bash_history that shows as much as well lol
<pnill> been about a week since I touched it
<pnill> You and I both had been trying to get the OTG stuff working, I think you ultimately determined that the OCHI controller had to be disabled to get it
<apritzel> pnill: what is this reg_usb1_vbus? Where is this defined
<pnill> but I ended up using a USB network adapter at some point
<apritzel> pnill: well, the question is whether you want to have true OTG or not
<apritzel> true OTG requires the ID pin *and* switchable VBUS on that port
<pnill> at the moment was just trying to get my network adapter working again lol
<apritzel> if you want to force it to host, that should be easy
<pnill> dr_mode in otg, and dual mode on the musb configuration in the kernel worked as far as I recall
<pnill> but it's not feeding power to the micro usb atm.
<apritzel> just set dr_mode = "host" (and enable EHCI0/OHCI0, of course)
<apritzel> pnill: at the moment I wonder how this DT compiled for you
<pnill> I actually dunno where &reg_usb1_vbus is defined
<apritzel> exactly, it's only in some board .dts files
<apritzel> they all define it and use it later
<pnill> yeah now wondering myself how it was compiling lol
<apritzel> pnill: how did you learn about the ID pin GPIO (PL5)?
<pnill> the original dts off the board
<pnill> you're actually the one who pointed it out afaik
<apritzel> is there any hint about a VBUS switch in there?
<apritzel> and I learned that those DTs are highly unreliable
<pnill> not that I've seen
<pnill> that was the original dumped/decompiled
<apritzel> on some TV box it said PL5 is the power key (the box doesn't have one), and also it controlling VBUS (which is always on)
<apritzel> so there seems to be a lot of wrong copy&paste from some template DT in those ones
<pnill> it looks like I've some how lost the reg_usb1_vbus line that was in here I wonder if when I lost power to my whole system the VM didn't sync to disk or something.
<pnill> Apr 27 15:27:36 <apritzel>but at least you found the USB issue now, didn't you? You need to copy the reg_usb1_vbus node from sun50i-a64-orangepi-win.dts (for instance)
<pnill> as that was something you'd told me to copy before
<apritzel> yes, you need the *node* and the *reference* to it
<pnill> yeah
<apritzel> PC6 is mentioned as the VBUS switch in this DT
<pnill> you'd mentioned both before
<pnill> I'm honestly not sure how it got removed, or how it compiled with out it.
<apritzel> but you did have eMMC on that board, didn't you?
<pnill> yeah
<apritzel> because PC6 is SDC2-D0
<apritzel> which means it's an essential line for eMMC operation
<apritzel> wasn't it that you found some GPIO that switches power to the USB port?
<pnill> yeah, I think that's where r_pio 0 5 GPIO_ACTIVE_HIGH came from
<apritzel> PL5 is apparently the ID pin input
<apritzel> you should be able to verify this, by plugging in a host and a device cable
<pnill> nah, I copied and pasted that in the wrong place.
<apritzel> the GPIO should read a different level then
<pnill> basically you'd said something about it
<pnill> but you'd said it right after mentioning reg_usb1_vbus
<pnill> so I'm assuming it went inside that block as the pin to enable USB
<pnill> (power wise)
<apritzel> well, this can't be the one pin to rule them all ;-)
<apritzel> you'd need one for the ID pin and one to switch power (if that switch actually exists)
<apritzel> that's what I meant with the DT being unreliable: PC6 can't be USB power and eMMC D0 at the same time
<pnill> This is what we'd said before
<apritzel> yeah, but PC6 is apparently wrong
<apritzel> for peripheral mode to work you need to disabled OHCI0/EHCI0
<apritzel> I realised that it was actually me breaking this lately
<pnill> which could be why it was unstable in switching between gadget and host?
<pnill> yeah, that's what you'd said before too
<pnill> lol
<pnill> but I'm not trying to do the peripheral atm
<pnill> was just trying to get the port working again
<pnill> and I think it was that vbus stuff missing
<pnill> because the port has power now
<apritzel> if that's the case, then just set dr_mode to "host", and enable OHCI0/EHCI0
<apritzel> that should work
<apritzel> you can reference the reg_vcc5v for the supply, but don't need to
<pnill> "I realised that it was actually me breaking this lately"
<pnill> something you contributed code wise?
<apritzel> yes
<pnill> ouch
<pnill> lol
<pnill> I don't trust committing code to anything as large as this
<apritzel> putting phys = <&usbphy 0>; to the EHCI0/OHCI0 nodes
<pnill> because I know my code sucks
<pnill> not saying yours does but yeah..
<apritzel> which now makes the MUSB OTG controller fight with the EHCI/OHCI controller over the port
<pnill> so what would be the solution then?
<apritzel> that is arguable a bug in the USB PHY
<pnill> I don't really know how usb works at the kernel level tbh
<apritzel> the solution (more a workaround) is to disable the HCI controllers
<apritzel> you don't need them (and never will) in peripheral mode anyway
<apritzel> well, the actual solution is to teach the USB PHY to deal with this properly
<apritzel> it does make the right decision in OTG mode, and has extra code to deal with this
<apritzel> but if it sees peripheral, it doesn't take that extra case
<apritzel> care*
<apritzel> and if the HCI0 controller are enabled, they request PHY0 (*before* the OTG controller does), and the PHY give it to them, enabling host mode
<apritzel> but it shouldn't do this, when "peripheral" is selected
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
<apritzel> tuxd3v: so far comparing dmesg between working and failing didn't give any clues, that all looked the same
<tuxd3v> yeah except for the loaded firmware
<apritzel> again, red herring
<apritzel> it fails already before loading the firmware
<apritzel> I was checking power supplies and the UART as well
<apritzel> so power sounds promising, but in your case it's the system 3.3V
<apritzel> so can't be it
<apritzel> it could be some timing issue, but that's harder to debug
<apritzel> except for maybe putting some delay in probe() and see if that fixes the problem
<tuxd3v> some timing, yeah it could be
<pnill> apritzel: : so yeah, adding the vbus made it work again
<pnill> guess that was missing just amazed it was compiling with that missing
apritzel has quit [Ping timeout: 240 seconds]
<vagrantc> anyone heard of issues with ethernet not working on H3 with linux 5.10.x ?
<vagrantc> apparently in the devicetree it needs:
<vagrantc> - phy-mode = "rgmii";
<vagrantc> + phy-mode = "rgmii-id";
<vagrantc> similar to a900cac3750b9f0b8f5ed0503d9c6359532f644d ARM: dts: sun7i: a20: bananapro: Fix ethernet phy-mode
victhor has quit [Ping timeout: 240 seconds]
gaston1980 has quit [Ping timeout: 240 seconds]
suniel has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
<wens> we tried to patch all the device trees, though some errors may have slipped through
<vagrantc> it would seem sun8i-h3-orangepi-plus needs it too
<vagrantc> at least as of 5.10
<tuxd3v> Bluetooth: hci0: BCM: Reset failed (-110)
<tuxd3v> the reset pins are correct :/
<tuxd3v> reset-gpios = <&pio 6 13 GPIO_ACTIVE_HIGH>; /* PG13 */
<tuxd3v> alwinner h3
hlauer has joined #linux-sunxi
pnill has quit [Read error: Connection reset by peer]
suniel has quit [Ping timeout: 240 seconds]
pnill has joined #linux-sunxi
buzzmarshall has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 260 seconds]
vagrantc has quit [Quit: leaving]
apritzel has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
chewitt has quit [Quit: Adios!]
cnxsoft has joined #linux-sunxi
cnxsoft1 has quit [Ping timeout: 240 seconds]
jstefanop has joined #linux-sunxi
suniel has joined #linux-sunxi
cmeerw has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
ganbold has quit [Ping timeout: 268 seconds]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 260 seconds]
mmarc__ has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
mmarc___ has joined #linux-sunxi
<hexdump01> i hope it is ok to ask a not directly sunxi question here (as i think someone here can for sure answer it quickly)?
mmarc____ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 260 seconds]
suniel has quit [Ping timeout: 240 seconds]
<apritzel> hexdump01: as the topic says: don't ask to ask. Just ask ...
<hexdump01> how to interpret /sys/kernel/debug/devices_deferred - does the order have any meaning in there and what would an entry like '7-0008' in there mean? any pointer to some info or doc about devices_deferred would be welcome too - i did not yet find anything which helped me further ...
mmarc___ has quit [Ping timeout: 252 seconds]
mmarc____ has quit [Ping timeout: 246 seconds]
<apritzel> hexdump01: I am afraid is all the doc you will find ;-)
<apritzel> it shows the content of the deferred pending list, with the device name first, then a reason (which might be empty) after a tab
<apritzel> for the meaning of pending list, see the comment at the top of this file
Mangy_Dog has joined #linux-sunxi
<hexdump01> apritzel: the basic idea is clear to me - its just i'm trying to make sense of the content and try to understand what to make out of '7-0008' there :)
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
<hexdump01> apritzel: i guess its some id but have no idea what it might be - there are other entries with names i have an idea what they are
mmarc__ has quit [Remote host closed the connection]
<apritzel> well, it's what dev_name(dev) returned for a device, I guess?
<apritzel> and my understanding is that this list should be empty after boot
<apritzel> if not, it means some devices are still missing resources
<hexdump01> apritzel: ok - thx a lot
cnxsoft has quit [Remote host closed the connection]
<apritzel> hexdump01: but tbh I haven't heard to this file before, so thanks for the heads up ;-)
<hexdump01> apritzel: :)
mmarc__ has joined #linux-sunxi
victhor has joined #linux-sunxi
<smaeul> why of course that refers to the device at address 8 on bus number 7 ;)
<smaeul> hexdump01: `find /sys/devices -name 7-0008` would give you a bus path
<smaeul> and booting with initcall_debug will tell you the name of the function that returned -EPROBE_DEFER, which will lead you to a driver
<hexdump01> smaeul: cool - this tells me what it actually is - thanks a lot
putti_ has quit [Ping timeout: 265 seconds]
<apritzel> smaeul, jernej: dumping my H616 USB progress so far:
Putti has joined #linux-sunxi
<apritzel> - the DT from my h616-v6-WIP branch works - with all USB ports enabled in isolation - WHEN booted via FEL
<apritzel> - when booting from SD card, only port 2 works
<apritzel> (when just this is enabled)
<apritzel> - when booting from SD card and enabling *all* USB ports, they all work (!)
<apritzel> - with that DT and SD card boot, adding all the other PHYS and the other RST_BUS_EHCIx, RST_USB_PHYx, CLK_USB_PHYx references does NOT help (to enable port1)
<apritzel> jernej: your PRCM bits from the BROM were already set the same in both SD and FEL boot
<apritzel> jernej: since from U-Boot on it's the same between SD and FEL, I didn't try to disable/enable or follow a sequence
mmarc__ has quit [Remote host closed the connection]
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 240 seconds]
specing_ is now known as specing
<apritzel> smaeul: how long did you test to see those 10 bit failures?
<apritzel> smaeul: you mention "_extremely_" rare, in 1 out of 8 boards?
<apritzel> I wonder how long I would need to run a test before trying another board
mmarc__ has joined #linux-sunxi
choozy has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 252 seconds]
JohnDoe_71Rus has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 245 seconds]
jstein has joined #linux-sunxi
xes has quit [Ping timeout: 252 seconds]
buzzmarshall has joined #linux-sunxi
xes has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi_ has quit [Client Quit]
mmarc__ has quit [Ping timeout: 268 seconds]
jbrown has quit [Ping timeout: 260 seconds]
Kooda has quit [Quit: issued !quit command]
Kooda has joined #linux-sunxi
jbrown has joined #linux-sunxi
gsz has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
lucascastro has joined #linux-sunxi
gaston1980 has quit [Remote host closed the connection]
gaston1980 has joined #linux-sunxi
cnxsoft has quit [Client Quit]
choozy has quit [Ping timeout: 240 seconds]
uis has quit [Quit: ZNC 1.7.5 -]
uis has joined #linux-sunxi
jbrown has quit [Ping timeout: 260 seconds]
jbrown has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 240 seconds]
vagrantc has joined #linux-sunxi
uis has quit [Quit: ZNC 1.7.5 -]
uis has joined #linux-sunxi
popolon has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
jstefanop has quit [Remote host closed the connection]
Daanct12 has joined #linux-sunxi
Naka has joined #linux-sunxi
Nakaori has quit [Read error: Connection reset by peer]
Danct12 has quit [Read error: Connection reset by peer]
buzzmarshall has quit [Remote host closed the connection]
<megi> so I figured what's wrong with probing on 5.13-rc1
<megi> hdmi probe is blocked, because hdmi-phy is not probed yet, but hdmi-phy probe is implemented by hdmi probe :)
juri_ has quit [Ping timeout: 268 seconds]
<megi> so fw_devlink code never probes hdmi
<megi> it expects the phys property in hdmi node to link to a real device
<megi> but looking at drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
<megi> hdmi-phy node is implemented by the same device as hdmi
<megi> so none of hdmi probes, and the whole display pipeline fails to probe
<megi> not sure how to fix that
<megi> breaking that fwnode_link between hdmi and hdmi-phy would fix it
<megi> or implementing hdmi-phy as a real, separate device
<megi> I guess someone will fix it, because HDMI out will not work on any of the newer alwwiner soc with 5.13 :)
<apritzel> megi: many thanks for the research, can you please report your findings on the mailing list?
<megi> fw_devlink author doesn't seem to like special casing these situations in fw_devlink code, so I guess this needs to be fixed in drm driver
<megi> apritzel: yes
<megi> which one?
<megi> just linux-sunxi?
iamfrankenstein has quit [Quit: iamfrankenstein]
choozy has joined #linux-sunxi
<apritzel> megi: &
<apritzel> this seems to be more a Linux driver model problem, so a wider audience is probably helpful
<megi> it's a known category of problems for fw_devlink
<megi> it's supposed to be solved by drivers
vagrantc has quit [Quit: leaving]
<apritzel> then the people output here might be useful as well: $ scripts/ -f drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
<megi> good idea
<megi> I'll also include fw_devlink author
<apritzel> megi: many thanks!
<megi> no problem, I also want this fixed properly :)
buzzmarshall has joined #linux-sunxi
juri_ has joined #linux-sunxi
<megi> mail sent
jbrown has quit [Quit: Leaving]
<megi> looks like not adding the phys property and patching the hdmi driver to not look for it and just probe the phy regardless woudl also fix it
<megi> avoiding the whole situation
<megi> though DT is probably not supposed to be changed
<megi> not sure if there are any other phys than the internal one ever used
<megi> probably not
<smaeul> apritzel: did you see my earlier messages explaining what BROM does? it disables HCI 2 PMU SIDDQ to get USB 0 working, so you need an actual <&usbphy 2> reference from each controller, not just the clocks/resets
<megi> jernej: do you remember the reason for why hdmi phy is not implemented as a separate platform device?
warpme_ has joined #linux-sunxi
<smaeul> apritzel: on my PinePhone 1.0 (that 1/8 device), I got errors past the kernel on 5 runs out of 32 consecutive runs of the test tool
<smaeul> they never seem to happen once "warmed up", only when first running the tool, or when running the single-threaded test (which hops CPUs)
<smaeul> so if you're using your bare-metal tool, I'd suggest adding some random occasional WFEs or something
choozy has quit [Ping timeout: 245 seconds]
mmarc__ has joined #linux-sunxi
jstefanop has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 265 seconds]
jstefanop has quit [Ping timeout: 252 seconds]
shailangsa has quit [Ping timeout: 240 seconds]
choozy has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
<pnill> apritzel: So, usb gadgets did work after disabling OCHI/etc... as you'd said just further confirming it.
buzzmarshall has quit [Remote host closed the connection]
mmarc__ has quit [Remote host closed the connection]
<apritzel> pnill: good, thanks! and fixing this properly is on my list, but there are some higher priority items on there
<pnill> yeah had some weird issues with stability that I think may've been related to my VM, as when I moved to my mac they were completely gone
<pnill> but beyond that worked great.
<apritzel> smaeul: yes, I saw your comments on the BROM, many thanks! I started digging into the BROM, but haven't finished that yet.
<apritzel> smaeul: I was hoping for something easy to integrate into the existing PHY code, so need to check what clearing other PHY's SIDDQ would take
netlynx has quit [Quit: Ex-Chat]
victhor has quit [Read error: Connection reset by peer]
mmarc__ has joined #linux-sunxi
shailangsa has joined #linux-sunxi
dev1990 has joined #linux-sunxi
<jernej> megi: you can't avoid phys property - that part is tightly connected with controller
<jernej> like you must observe some specific power up sequence
mmarc__ has quit [Remote host closed the connection]
<megi> the driver seems to just call the phy probe directly after reading the phy property anyway
<jernej> and PHY implements callbacks which are used by controller setup code
<megi> the wholed DT thing seems a bit superfluous
<jernej> megi: right, it must be after, not before
<jernej> wait
<megi> right, so if it would be a separate device the order would be reversed
<jernej> anyway, one must not probe before other
<megi> core would init the phy first
<jernej> we can't rely on that
<megi> rely on what?
<jernej> probe order by Linux
<megi> that's the point of fw_devlink though
<megi> it enforces a specific probe order
<megi> suppliers before providers
<megi> and phys is a supplier in this case
uis has quit [Quit: ZNC 1.7.5 -]
uis has joined #linux-sunxi
<jernej> but anyway, PHY driver must not setup clocks and resets before controller
<megi> anyway, hw requires that phy_probe is done after hdmi device probe?
<jernej> yes
<megi> ok
<megi> good to know :)
<jernej> and it must provide set of callbacks
<megi> we'll get some feedback soon from fw_devlink/core maintainers so this is important to know
<jernej> it can be implemented by PHY subsystem, but it's more clunky
<jernej> because standalone driver must provide some methods, which needs to be exported and special header file needs to be put in include/ folder
<jernej> and I doubt we would do that in RC phase
<megi> it's possible to just break the fwnode_link, because it doesn't make sense in this case... one way to do it would be to get ridof the phys property
<jernej> no, phandle to phy node is needed
<megi> it's only parsed by the hdmi driver anyway
<megi> ah, right
<megi> so rename it?
<megi> allwinner,phys :)
<megi> anyway, daydreaming since DT change probably would not be accepted
<jernej> there is a thing called DT rules :)
<megi> but it will work in my tree until a proper upstream solution is found
<megi> ;)
<megi> there are other fw_devlink issues in sunxi code, so I can at least workaround this one to get to see the others :)
<megi> eh, I have to rename it in all the dtsi files... bah
<megi> yeah, rename fixed the display
<apritzel> megi: please don't mess with compatible strings, not even in "your" tree
<megi> i didn't change compatibles
<megi> just phys property
<megi> I can even do it in a backwards compatible way by making the driver check both names
<apritzel> but not forward compatible, I guess?
<tuxd3v> apritzel, I didn't give up yet on bluetooth
<apritzel> tuxd3v: me neither ;-)
<tuxd3v> I still continue testing, and trying to get paterns , to see were they lead me..
<megi> that depends on what lays forward :)
<megi> but probably no
<apritzel> megi: meaning the most recent DTs work on older kernels
<apritzel> megi: in general I doubt that a DT change to fix some Linux driver model issue is the right answer
<megi> we agree on that
<megi> I just need the kernel to boot to test other things
<megi> I'm not proposing this as final solution :)
<apritzel> megi: good, just wanted to make sure
<apritzel> tuxd3v: I wanted to test some older kernels, which version are you using?
<tuxd3v> I am on 5.10.36
<apritzel> that's sad!
<tuxd3v> do you think messing with uboot will improve our chances to get that working?
<tuxd3v> next time you try, try later a reset
<megi> looks like kernel should be able to infer that some devices can't be probed and re-order the probe sequence already, but it probably doesn't do it for "toplevel" platform devices
<tuxd3v> you see a reset timout in the dmesg
<apritzel> tuxd3v: U-Boot should have no role in this at all
<megi> there's still a bunch of deferals early on
<tuxd3v> but doing a 'hcicongih hci0 reset', resets the device and loads the firmarwae too
<tuxd3v> apritzel, yeah, my guess too
<megi> I guess this is not done during of_platform_populate yet
<megi> later on it hits the probe dependencies perfectly
<megi> but it looks like an improvement already :)
<apritzel> megi: sometimes I get the impression that we now probe in exactly the opposite order ;-)
<megi> pinctrl <-> pmic dependency kinda makes things compilcated I guess
<megi> pinctrl, clocks, rsb, pmic and the rest would be ideal
<megi> in that order
<apritzel> yes, exactly
<megi> but pinctrl needs pmic and that may throw some things off
<apritzel> but how is this solved at the moment?
<megi> just ignore PL port regulator
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria]
<smaeul> jernej: so it sounds like the root issue is that the PHY probe function shouldn't be enabling clocks/resets. those should be moved to a phy ->init or ->power_on callback
<megi> smaeul: it doesn't use phy subsystem at all
<smaeul> yes, that's the problem :)
<megi> :D
<megi> hmm fw_devlink may deal with that circular dependency, it has some code for that
<megi> I'll try :)
<jernej> smaeul: true, but one custom function would still be needed
<jernej> for retrieving callbacks
<megi> hmm that didn't work out very well :)
<megi> no boot
vagrantc has joined #linux-sunxi
<vagrantc> hah. so ... the issue with borked ethernet on orange pi plus was reposted and submitted ... but blocked on signed-off-by:
<vagrantc> er, reported ...
vagrantc has quit [Ping timeout: 260 seconds]
gsz has quit [Ping timeout: 245 seconds]
atsampson has joined #linux-sunxi
ats_ has quit [Ping timeout: 260 seconds]
cmeerw has quit [Ping timeout: 250 seconds]
<tuxd3v> apritzel, after boot, do 'bluetoothctl show'
<tuxd3v> if it doesn't work, reset hci0 device 'hciconfig hci0 reset'
<tuxd3v> then test bluetooth 'bluetoothctl show'
<tuxd3v> if it doesn't work, remove and insert hci_uart module:
<tuxd3v> modprobe -r hci_uart;
<tuxd3v> modprobe hci_uart;
<tuxd3v> check bluetooth again :)
<tuxd3v> nope forget.. :/
hramrach has quit [Ping timeout: 252 seconds]
hexdump01 has left #linux-sunxi ["WeeChat 1.9.1"]
hramrach has joined #linux-sunxi
luke-jr has quit [Read error: Connection reset by peer]
luke-jr has joined #linux-sunxi
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
hlauer has quit [Ping timeout: 252 seconds]
ganbold__ has joined #linux-sunxi
ganbold_ has quit [Ping timeout: 268 seconds]
<apritzel> tuxd3v: I don't understand: we don't need some weird way to get BT to work, we need to find the root cause why it doesn't work in the first place
warpme_ has quit [Quit: Connection closed for inactivity]
<apritzel> smaeul: jernej: when I reboot a H616 board from the kernel, I see "Failed to set core voltage! Can't set CPU frequency" in the SPL
<apritzel> this is because the SPL speaks only I2C to the PMIC, but the kernel left the AXP in RSB mode
<apritzel> and while the RSB got reset by the watchdog, the AXP didn't
<apritzel> so shall we put the AXP back into I2C mode in the kernel, for instance in drivers/mfd/axp20x-rsb.c:axp20x_rsb_remove()?
<smaeul> then how would TF-A communicate with it?
<smaeul> you'll have to update u-boot to use RSB
<apritzel> meh, that's in the SPL, and we just use the existing I2C SPL driver
<apritzel> but yeah, TF-A is really the last one to use the AXP
popolon has quit [Quit: WeeChat 3.1]
<apritzel> or actually, it doesn't *use* it in the case of reset
<apritzel> but it could send this one command to set it back into I2C?
<apritzel> smaeul: didn't we do something similar before, for some other SoC?
<smaeul> we set it back to I2C during boot
<smaeul> but you can't communicate with it after you do that, so you lose the ability to do a PMIC reset instead of a watchdog reset
<apritzel> so that the kernel can go through the original init sequence, right?
<smaeul> yeah
<apritzel> PMIC reset? I thought we always reset via the watchdog?
<smaeul> TF-A does, yes, so there's no regression -- but it would prevent you from doing so in the future
<smaeul> also you can't do it in the kernel because that would break crust
<apritzel> smaeul: do you rely on the AXP being in RSB mode in crust? (I know, doesn't apply to the H616, just in general)
<apritzel> ;-)
<smaeul> I rely on it being in the same mode during both sleep and shutdown/reboot
<smaeul> whether that's I2C or RSB is configurable at build time
<apritzel> I see
<smaeul> and there's definitely not space for both drivers :)
<smaeul> what's the problem with using RSB in SPL? there's already a driver
<apritzel> that's for some old SoC only, IIRC? Need to check whether that works with the H616?
<smaeul> you'll have to do that anyway when we move to using the DT in SPL, since that's what's in the DT ;-)
<smaeul> it looks like it would work. it's not like the RSB controller has changed since it was added
<apritzel> DT in SPL? begone evil spirit!
<smaeul> (on the other hand, things that have changed recently: the GPIO register layout, which will be a massive pain for u-boot)
<apritzel> smaeul: OK, thanks for your input, will have a think about it
<apritzel> it doesn't seem to be critical, interestingly, the CPU clock is set up correctly anyway, regardless of this message
<smaeul> maybe the frequency it is setting is what's already set up by the BROM?
<smaeul> the voltage will be whatever was used by the OPP at reboot (which is probably high) so it works out
<apritzel> yeah, the voltage is definitely correct in this case, also for the DRAM (which would be more critical to set up, really)
<apritzel> the value of CPUX_PLL is 0xba001100, which is 432 MHz
<apritzel> is that what the BROM uses?
<smaeul> I don't know offhand
<apritzel> anyway, the CPU really runs at 432 MHz after a reset, that's a bit annoying
<apritzel> mmh, the BROM seems to use 408 MHz
<apritzel> anyway, back to the actual showstopper: USB ...
<apritzel> smaeul: ... and of course clearing SIDDQ in PMU2 does the trick
<apritzel> interestingly even across a PHY2/EHCI2 reset