Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2023.07 is OUT / Merge Window is OPEN, next branch is CLOSED / Release v2023.10 is scheduled for 02 October 2023 / Channel archives at https://libera.irclog.whitequark.org/u-boot
qschulz has quit [Remote host closed the connection]
vvn has quit [Quit: WeeChat 4.0.0]
qschulz has joined #u-boot
_whitelogger has quit [Ping timeout: 246 seconds]
_whitelogger has joined #u-boot
Manouchehri has joined #u-boot
mmu_man has quit [Ping timeout: 245 seconds]
thopiekar has quit [Ping timeout: 245 seconds]
thopiekar has joined #u-boot
jclsn has quit [Ping timeout: 244 seconds]
jclsn has joined #u-boot
vagrantc has quit [Quit: leaving]
persmule has quit [Remote host closed the connection]
alpernebbi has quit []
alpernebbi has joined #u-boot
alpernebbi has quit [Read error: Connection reset by peer]
alpernebbi has joined #u-boot
naoki has joined #u-boot
naoki has quit [Quit: naoki]
Clamor has joined #u-boot
camus has quit [Quit: camus]
camus has joined #u-boot
sng has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
sng has quit [Ping timeout: 245 seconds]
urja has quit [Read error: Connection reset by peer]
cbmuser has quit [Quit: WeeChat 3.0]
cbmuser has joined #u-boot
urja has joined #u-boot
dossalab has joined #u-boot
sng has joined #u-boot
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
sng_ has joined #u-boot
sng has quit [Ping timeout: 244 seconds]
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
mmu_man has joined #u-boot
naoki has joined #u-boot
naoki has quit [Client Quit]
sng_ has quit [Remote host closed the connection]
sng has joined #u-boot
sylensky[m] has quit [Remote host closed the connection]
sng_ has joined #u-boot
sng has quit [Ping timeout: 260 seconds]
slobodan has joined #u-boot
sng_ has quit [Remote host closed the connection]
sng has joined #u-boot
sng_ has joined #u-boot
sng has quit [Ping timeout: 245 seconds]
Clamor has quit [Ping timeout: 252 seconds]
alpernebbi has quit [Ping timeout: 250 seconds]
Leopold has quit [Remote host closed the connection]
Leopold has joined #u-boot
slobodan has quit [Ping timeout: 240 seconds]
sng_ has quit [Remote host closed the connection]
sauce has quit [Ping timeout: 246 seconds]
sng has joined #u-boot
naoki has joined #u-boot
sng_ has joined #u-boot
sng has quit [Ping timeout: 260 seconds]
naoki has quit [Quit: naoki]
vulpes2[m] has joined #u-boot
dossalab has quit [Quit: dossalab]
sng_ has quit [Remote host closed the connection]
sng has joined #u-boot
goliath has joined #u-boot
mmu_man has quit [Ping timeout: 240 seconds]
sng has quit [Ping timeout: 252 seconds]
persmule has joined #u-boot
mmu_man has joined #u-boot
swiftgeek has quit [Ping timeout: 264 seconds]
sng has joined #u-boot
sng has quit [Ping timeout: 260 seconds]
sng has joined #u-boot
mmu_man has quit [Ping timeout: 245 seconds]
vagrantc has joined #u-boot
sng has quit [Remote host closed the connection]
slobodan has joined #u-boot
swiftgeek has joined #u-boot
sng has joined #u-boot
mmu_man has joined #u-boot
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot
vagrantc has quit [Quit: leaving]
sng has quit [Remote host closed the connection]
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
rainbyte[m] has joined #u-boot
Clamor has joined #u-boot
mmu_man has quit [Quit: reboot]
sng has joined #u-boot
<Clamor> sjg1: as you asked
<Clamor> I have some interesting effects with pmic gpios and fixed-regulators which use pmic gpio.
<Clamor> Layout is next: I use palmas pmic for the test. The pmic itself has GPIO cell so I have written gpio uclass driver for this cell and it works as expected when my device boots (I can toggle gpios and they react and respond). It has its own node inside pmic node and it is correctly bound. But as soon as I set one of these gpios into a fixed regulator it fails with ENODEV.
<Clamor> I thought that maybe pmic children are not probed but no, they are! I have tracked probe and regulator calls and the probe is earlier + at the time the fixed regulator is called (it is not always-on or boot-on) pmic regulator is called as well (they are called by the same device). Maybe you have any clues how to handle this?
<sjg1> Clamor: The first thing to mention is that valid devices should never return -ENODEV because that means that there is no device. Sometimes you can enable CONFIG_LOG_ERROR_RETURN and see the calls which are failing
<sjg1> Clamor: I'm not an expert on the pmic subsystem...I think the maintainer is at Samsung
<sjg1> 17
<sjg1> Clamor: git grep -l ENODEV drivers/power/ |wc -l
<sjg1> Not a good sign...
<sjg1> Clamor: What call are you using to enable/disable the regulator?
<Clamor> regulator_set_enable_if_allowed
<sjg1> Clamor: which calls regulator_set_enable() so that must be returning -ENODEV
<Clamor> Regulator is failing due to failing gpio
<sjg1> Clamor: in regulator_common_set_enable() ?
<Clamor> I have tracked it to gpio uclass
<sjg1> Clamor: Which GPIO driver is it?
<Clamor> Palmas gpio driver
sng has quit [Remote host closed the connection]
<sjg1> Clamor: I can't see that...which file?
<Clamor> It is not mainlined yet
mmu_man has joined #u-boot
<Clamor> Basically gpio driver as a child of pmic
<sjg1> Clamor: Is the GPIO driver for the GPIO pins of the pmic?
<Clamor> Correct
<Clamor> The Palmas pmic I use has 8 gpios.
<sjg1> OK so you are trying to use the regulator API on one of those pins?
<Clamor> Correct
<sjg1> Can you point the output of 'dm tree' ?
<Clamor> Sure, one min
alpernebbi has joined #u-boot
<sjg1> Clamor: That looks OK...can you pinpoint where the -ENODEV is being returned?
Clamor has quit [Ping timeout: 244 seconds]
Clamor has joined #u-boot
<Clamor> I need more specific description of what log type you refer to
<sjg1> Clamor: Well, is dm_gpio_set_value() returning -ENODEV when you call regulator_set_enable() ?
<Clamor> Yes, it cannot get gpio dev
<sjg1> Does palmas_gpio_direction_output() get called? What is priv->chip2 ?
<sjg1> Can you post the console log? I assume there it no error message?
<Clamor> Palmas is multichip pmic, gpio regs are on chip2
<sjg1> Clamor: Do you have a tree I could look at?
<Clamor> It is in pmic driver
<sjg1> Clamor: Which branch on github?
<Clamor> t114
<Clamor> Console log
dossalab has joined #u-boot
sauce has joined #u-boot
<sjg1> Clamor: Hmmm, well palmas_probe() is wrong...you should probably add both chips to the DT..but calling i2c_get_chip() is not good
sng has joined #u-boot
<sjg1> Clamor: Since the pmic is not an i2c bus...it is odd
<sjg1> See " i2c_generi 0 [ + ] i2c_generic_chip_drv | `-- generic_59"
<sjg1> If that is the pmic bus it should be a child of the pmic
<Clamor> Linux uses dummy i2c chip iirc to handle this
<Clamor> But basically this should not matter since it is not exposed and referred in tree. If pmic is probed, chip should be got as well
<Clamor> Pmic bus? Tegra has power i2c bus, but it is not exclusive to pmic. And if pmic has 4 chips within itself? What to do
<sjg1> Clamor: We need a better way of modeling this, since at present there is only one address supported per chip
<sjg1> It looks like gpio_request_tail() is calling uclass_get_device_by_ofnode() in the case where !desc-dev ?
<sjg1> That code looks bogus to me
<Clamor> Yes
<sjg1> I don't see how desc->dev can not be set up. That is only used for legacy GPIOs
<sjg1> For driver model, everything needs to request a GPIO with things like gio_dev_request_index(), etc., i.e. they receive a gpio_desc struct
<Clamor> sjg1: modelling is fine I was able to link one more chip without major issues
<Clamor> About gpio stuff yes, you are correct. Device should be there at time of call but it does not work for some reason
<sjg1> Clamor: I think you need to figure out what GPIO call is resulting in the bad gpio_request_tail() call...quite apart from what looks like a bug or a workaround in gpio_request_tail()
<Clamor> Alright
Clamor has quit [Quit: Quit]
swiftgeek has quit [Ping timeout: 260 seconds]
___nick___ has quit [Ping timeout: 260 seconds]
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot
<johang> looks like booting from QEMU drive is broken on master. worked 1-2 week ago.
vagrantc has joined #u-boot
<johang> at least on i386
vagrantc has quit [Client Quit]
vagrantc has joined #u-boot
vagrantc has quit [Quit: leaving]
vagrantc has joined #u-boot
slobodan has quit [Ping timeout: 244 seconds]
slobodan has joined #u-boot
<sjg1> johang: Is this qemu-x86 ?
dossalab has quit [Quit: dossalab]
sng has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
<johang> sjg1: yes
<sjg1> johang: Try this?
<johang> I'll give it a shot
soxrok2212 has quit [Read error: Connection reset by peer]
soxrok2212 has joined #u-boot
<johang> sjg1: same problem. working: https://pastebin.com/tu4tPdiq, not working: https://pastebin.com/0FAaLZqY
<sjg1> johang: OK that looks like something wrong with USB, so I don't have any ideas there. Perhaps email a bug report and cc usb: ?
slobodan has quit [Ping timeout: 245 seconds]
naoki has joined #u-boot
soxrok2212 has quit [Read error: Connection reset by peer]
swiftgeek has joined #u-boot
soxrok2212 has joined #u-boot
umbramalison has quit [Remote host closed the connection]
umbramalison has joined #u-boot
umbramalison_alt has joined #u-boot
umbramalison has quit [Ping timeout: 252 seconds]
swiftgeek has quit [Quit: swiftgeek]
swiftgeek has joined #u-boot