<oliv3r>
since the compaitble and the ID are different strings
<wens>
indeed
Gerwin_J has quit [Quit: Gerwin_J]
ykchavan has joined #linux-sunxi
f0xx has joined #linux-sunxi
<oliv3r>
i know the dt aims to be backwards/forwards compatible, is the same to be said about the i2c id strings?
<oliv3r>
because then i'll send in a rename patch
<oliv3r>
(even though there are zero users in arch of said compatible)
<wens>
you should ask the i2c maintainer
reinforce has joined #linux-sunxi
<oliv3r>
yeah but usually they prefer to be asked with a patch :)
<oliv3r>
so renaming the ID and asking the I2C maintainer sounds reasonable, whereas renaming the DT nodes is not really accepted (even there's no current users in the kernel)
<oliv3r>
but thanks :) i'll send an e-mail to the i2c list with the patch
leviathanch has joined #linux-sunxi
f0xx has quit [Ping timeout: 252 seconds]
aidin has quit [Remote host closed the connection]
f0xx has joined #linux-sunxi
aidin has joined #linux-sunxi
GPenguin has joined #linux-sunxi
aidin has quit [Ping timeout: 260 seconds]
<oliv3r>
wens: that was indeed the key component, renaming the table id makes the driver now autoload
<wens>
there was some discussion about this on the mailing lists, though I can't remember any keywords now
<oliv3r>
about general id <--> of matching? or specific to this driver?
<oliv3r>
i'm guessing the former, as specifc to this driver would have atleast one good keyboard :)
<ElBarto>
but 2GB of ram (iirc the nes mini had only 256M)
<wens>
it might even be the same board? :p
rpd_ has quit [Quit: leaving]
<ElBarto>
yes probably :)
rpd_ has joined #linux-sunxi
<ElBarto>
yeah doesn't look that different
<ElBarto>
will see tonight when I pick up mine
chomwitt has joined #linux-sunxi
msimpson has joined #linux-sunxi
rpd_ has quit [Ping timeout: 255 seconds]
<oliv3r>
how are the i2c-id and spi-id used within the kernel/userspace? e.g. what is the effect when renaming these items?
<oliv3r>
the alternative solution instead of renaming is to add them, but that sounds like duplication
<oliv3r>
if I register a clock via devm_clk_register(), and I don't have the returned clock, can I still enable/disable it? E.g. can I share clocks between 2 reasonably unrelated drivers?
<oliv3r>
i do know the name the clock was registered with (init.name) but obviously i can't get that via devm_clk_get, as far as I understand, this only searches the dt?
rpd_ has joined #linux-sunxi
aidin has joined #linux-sunxi
<wens>
why don't you have the returned clk?
<wens>
export it via DT from one device to the other
<oliv3r>
wens: do we have an example that i can follow for that?
<wens>
the clock drivers :)
yann has joined #linux-sunxi
aidin has quit [Ping timeout: 240 seconds]
<oliv3r>
:p fiar enoguh
\\Mr_C\\ has quit [Quit: .]
<oliv3r>
wens: what I meant is, do we have a device that does this already I can learn from?
argulp has joined #linux-sunxi
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
rpd_ has quit [Quit: leaving]
BenG83 has quit [Remote host closed the connection]
<wens>
clock or rtc
<oliv3r>
ok i'll look into the rtc then
<oliv3r>
i was peeking at the tmds clock, but i think it doesn't do what you suggest?
popolon has joined #linux-sunxi
<oliv3r>
e.g. tmds is fed by the pll-0 and pll-1 clocks, but the hdmi driver keeps the tmds clock to itself
nOOb__ has joined #linux-sunxi
<oliv3r>
hmm, rtc doesn't have any clk notion for sunxi
LargePrime has quit [Ping timeout: 240 seconds]
lioka has joined #linux-sunxi
<oliv3r>
ok i think that's where i missunderstand, the tmds clock should be exposed via sunxi-ng basically i guess, and then one could do devm_clk_get()
aidin has quit [Remote host closed the connection]
jstein has quit [Read error: Connection reset by peer]
f0xx has quit [Ping timeout: 248 seconds]
enrico_ has joined #linux-sunxi
<Net147>
apparently unloading/unbinding musb-sunxi results in kernel oops...
<wens>
lol
<Net147>
wens: NULL pointer deference in usb_put_phy. x->dev->driver is NULL (calling usb_phy_generic_unregister makes it NULL and usb_put_phy is called afterwards as a result of detaching the device)
<Net147>
wens: so I can either check if x->dev->driver is NULL before using it in usb_put_phy or I can add a call to devm_usb_put_phy at the end of sunxi_musb_exit...
<Net147>
wens: any suggestions on which is the right way to fix it? =)
<lioka>
2017.07 boots, but no video, 2017.05 ok. oh well
<wens>
oliv3r: you got it wrong
<wens>
oliv3r: the tmds clock is part of the hdmi block. it's just implemented and registered with the clock subsystem because it uses clocks from the subsystem, and doing it that way is easier
<wens>
oliv3r: check sun6i-rtc, which exports clocks
ykchavan has quit [Remote host closed the connection]
<oliv3r>
wens: rgr
<oliv3r>
Net147: isn't that a really old bug related to host only mode or something?
kaspter has quit [Quit: kaspter]
<Net147>
oliv3r: is it? it's the first time I have tried to unload/unbind musb-sunxi
<oliv3r>
it was 1 1/2 - 2 years ago
<Net147>
oliv3r: do you have a reference to it?
<Net147>
I have always had issues with musb
<Net147>
oliv3r: the oops also occurs in otg mode, not just host-only mode
<Net147>
to reproduce oops unbinding musb-sunxi (warning: don't try this unless can physically reboot the device as reboot will hang): echo 1c13000.usb > /sys/bus/platform/drivers/musb-sunxi/unbind
f0xx has joined #linux-sunxi
<wens>
Net147: sounds like you should do devm_usb_put_phy at the end of sunxi_musb_exit (and also in the probe error path)
<wens>
so you can even drop devm_, since it provides no benefit anymore
<Net147>
wens: it won't do a double free?
<wens>
drop devm_ from devm_usb_get_phy as well
<wens>
and also leave a comment about why the sequence of usb phy related calls is needed in this order
<Net147>
okay. so adding a null check in usb_put_phy actually breaks other things?
<wens>
I don't know, but since the driver is registering the generic phy as well, it stands to reason it should do proper lifetime management and drop references to it before unregistering it?
<Net147>
okay
<wens>
I don't know how the code is implemented, but if someone were to take a reference on a device, you shouldn't be able to remove it
<wens>
so the check in usb_put_phy might be needed, or something else
<wens>
but that's the more generic case
<wens>
you could bring it up when submitting the musb-sunxi specific patch?
<Net147>
wens: will do. thanks for the help.
<Net147>
the other issue I have with musb is "Could not flush host TX2 fifo: csr: 2003"...
<Net147>
which requires resetting the MUSB controller or reboot to get USB working again
dave0x6d has joined #linux-sunxi
libv_ is now known as libv
clemens3 has joined #linux-sunxi
lerc has quit [Ping timeout: 260 seconds]
techping has joined #linux-sunxi
lerc has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 240 seconds]
lerc has quit [Read error: Connection reset by peer]
lerc has joined #linux-sunxi
fkluknav has quit [Ping timeout: 240 seconds]
techping has quit [Remote host closed the connection]
yann-kaelig has joined #linux-sunxi
<oliv3r>
Net147: i was kinda bummed out, that unbinding the usb host controller, was the only way to actually turn off the power on the host
kaspter has joined #linux-sunxi
<Net147>
oliv3r: or poking the registers...
chomwitt has quit [Ping timeout: 252 seconds]
<oliv3r>
yeah, of course
<oliv3r>
or just use the gpio pin :p
<oliv3r>
but the gpio is set as a power pin right now on the lime boards
<oliv3r>
and having a power toggle' ala rfkill would be nice
<oliv3r>
i know it doesn't work as easy, as all the usb hosts children would be powered down
<oliv3r>
still
<Net147>
I don't think you can export pins that are in use?
anarsoul|2 has quit [Remote host closed the connection]
anarsoul|2 has joined #linux-sunxi
f0xx has quit [Ping timeout: 252 seconds]
bonbons has quit [Quit: Leaving]
Ntemis has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
argulp has joined #linux-sunxi
aalm has joined #linux-sunxi
chomwitt has joined #linux-sunxi
<aalm>
hi, would someone please take a look at this: https://marc.info/?l=openbsd-arm&m=150645653511890&w=2 ? in short, two i2c nodes in sunxi-h3-h5.dtsi are sharing the same address, guessing it's just a copy-paste gone wrong.
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 260 seconds]
libv_ has quit [Read error: Connection reset by peer]