akaizen has quit [Remote host closed the connection]
levd has quit [Ping timeout: 240 seconds]
levd has joined #linux-rockchip
<maz_>
rperier: that's a fair restriction. /dev/mem should have died a long time ago, and there is enough ways to workaround this patch so that people using devmem and co can still debug their HW the way they are used to.
<rperier>
fortunately, there is an option to disable it, otherwise it could have been problematic. (devmem is very useful to dump IP registers in RO while a device driver is bound, only to check if your IP is correctly configured for example)
* sjoerd
finds regmap very useful for that
<sjoerd>
that has a sysfs interface to dump the registers as well
<maz_>
rperier: the main problem is that on a number of IPs, some register reads do have side effects...
<maz_>
rperier: so devmem is never really safe.
Ueno_Otoko has quit [Ping timeout: 260 seconds]
<rperier>
sjoerd: and you can really dump everything as devmem does ?
<sjoerd>
rperier: well it's regmaps view of the world ofcourse (and it assumes the driver uses regmap)
<rperier>
I see
<sjoerd>
devmem is far more low-level/heavy hammer type, but as maz_ mentions that in itself can cause issues
<rperier>
maz_: /dev/mem is for debugging purposes, so it assumes that the developers really knows what he does :)
<rperier>
developer*
<rperier>
maz_: it is not safe at all, I completly agree
<rperier>
and should not enabled by default, but when you develop a kernel for a new board it is very very useful. For example, few days ago we use devmem in order to check if a bit what set in the hw clk tree, this bit is needed to mux the parent of a clk gate
<rperier>
(on zynq)
<rperier>
I don't say that this is the unique tool to dump IP registers or to do these kinds of debugging tasks, I just say that it is very useful as a developer tool when you know what you do :)
nighty^ has joined #linux-rockchip
<sjoerd>
rperier: in that case you can also reboot with iomem=relaxed and then check :)
czerny has joined #linux-rockchip
czerny has quit [Quit: Leaving]
czerny has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 264 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
nighty^ has quit [Quit: Disappears in a puff of smoke]
levd has quit [Ping timeout: 276 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 265 seconds]
levd1 is now known as levd
levd has quit [Remote host closed the connection]
Astralix has joined #linux-rockchip
levd has joined #linux-rockchip
hipboi has quit [Quit: This computer has gone to sleep]
czerny has quit [Ping timeout: 240 seconds]
nighty^ has joined #linux-rockchip
levd has quit [Ping timeout: 245 seconds]
<rperier>
sjoerd: yep, this is what is explained in the commit message, that's useful :)
ssvb has joined #linux-rockchip
<sjoerd>
this wireless thing is going to drive me mad
<sjoerd>
hack the sytem up to test so it would load the broadcom driver ~5 seconds after boot.. 100 successful reboots yesterday, first boot today => fail
Ueno_Otoko has joined #linux-rockchip
Ueno_Otoko has quit [Ping timeout: 250 seconds]
cnxsoft has quit [Quit: cnxsoft]
naobsd has joined #linux-rockchip
Ueno_Otoko has joined #linux-rockchip
wadim_ has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-rockchip
Ueno_Otoko has quit [Ping timeout: 245 seconds]
<sjoerd>
mmind00: ooi do you know of issues with the mmc/sdio controller where it could stall for a bit ?
<mmind00>
sjoerd: not that I know off ... check drive-strength?
<mmind00>
sjoerd: i.e. veyron are running with 8mA
<sjoerd>
pushed up the 11
<sjoerd>
i mean 12 :)
<sjoerd>
didn't help
<sjoerd>
Quite a few twists and turns on this one :(
<sjoerd>
I bumped a timeout in the broadcom driver and it _seems_ to be better now but need to do more testing
Astralix has quit [Remote host closed the connection]
<sjoerd>
So I'm wondering if my extra delaying yesterday just meant the system happend to be less loaded such that the root cause occured more often
<sjoerd>
Though i am a bit surprised as looking at the vendor tree the timeout seems the same there
<sjoerd>
(the apaprently issue seems to be that it takes the chip too long (> 2 seconds) to respond)
<sjoerd>
though looking at the logs, when it was previously successful it would respond very quickly
<sjoerd>
so i'm confused, hence the question :)
<sjoerd>
Well confused, wondering if it's actually the chip that's being slow or something else funky going on :)
<sjoerd>
hah
<sjoerd>
looks like chromiumos has a simpler tweak
<sjoerd>
So maybe everything else was just bad luck then.. fun fun
<sjoerd>
dianders: as you seem to have reviewed that one ^, do you happen to know any background of why this might happen?
matthias_bgg has left #linux-rockchip ["Leaving"]
<dianders>
sjored: Where are you seeing the timeout. During normal operation or at bootup?
<sjoerd>
dianders: bootup
<sjoerd>
well really initialisation
<dianders>
sjoerd: I think that's where we were seeing it as well in that case of that particular change. I think Paul did most of the work digging into that particular problem...
<dianders>
I seem to recall some of our init problems had to do with specifying "broken cd" and not specifying "non-removable", but I don't quite remember if this was related
<dianders>
AKA the driver was unhappy if you happened to probe for the card (because of broken cd and removable) while it was initting
<sjoerd>
Right i already had it as non-removable
<dianders>
OK, so not that
<dianders>
Not sure why it takes so long. The broadcom firmware is a bit funny I think. I know for certain that if you put the WiFi in power saving mode that some SDIO transfer errors are expected. Also there are cases where it's expected that the Broadcom SDIO chip will hold the SDIO bus busy while it's doing stuff.
<dianders>
...so in this particular case, I'd say probably the firmware is just busy at the time we tried to talk to it and it takes it's sweet time responding.
<sjoerd>
I guess so
<sjoerd>
I did hack up the system last night while trying things to load the driver a few seconds after boot, which survived a 100 boots at first but then failed again this morning.. which was fun
<dianders>
You think there's some other root cause? If so, it's not one I'm aware of but mostly I've just been involved in picking down random problems here and there--I don't have a 1000 foot view of Broadcom WiFi
<dianders>
You can see that Paul made a few revisions of his CL
<sjoerd>
dianders: I'm really not sure.. I just spent the lsat day or so double-checking if i got the clocks and regulators all aligned just right until i decided to dig more into the driver and noticed that sometimes it took just over the 2 seconds to respond (iotw just after thedefualt timeout)
<dianders>
That seems to match what Paul saw and match the fix in our kernel
<sjoerd>
Nod
<dianders>
So seems like maybe the right fix is to increase the timeout in the upstream kernel, too?
<sjoerd>
I just happened to google for the variable i changed and ran into your fix :)
<sjoerd>
yup think so
<sjoerd>
dianders: was this on a rockchip chromebook where the issue came up btw ?
<dianders>
Yes
<sjoerd>
fwiw the kernel from radxa has: #define IOCTL_RESP_TIMEOUT 2000 /* In milli second default value for Production FW */
<sjoerd>
So i guess if the FW itself has 2 seconds as a timeout, that doesn't take into account submit/receive time.. which might explain it going just slightly over
<sjoerd>
dianders: Nod, i'll submit a patch upstream with the value Paul worked out and see what the broadcom guys say
rory096 has quit [Read error: Connection reset by peer]