<Mis012[m]>
it seems that sending a cover letter this time didn't help at least with patchwork...?
<mani_s>
arnd, Regarding the ARM64 memory model. Can we expect mb()==dsb to flush the write buffer of device memory allocated with ioremap()?
<mani_s>
I'm not sure if an additional readl is required to make sure the WB is flushed
<arnd>
In the Linux memory model, mb() is not sufficient to flush a write buffer, you need the extra ready() to be sure
<mani_s>
arnd, okay
<arnd>
You can use ioremap_nb() to get a no buffered mapping, but the effect is machine specific
<mani_s>
arnd, right, but I'm looking into existing subsystems using the ioremap(), so wanted to check
<arnd>
It's very rare that one actually cares about the write buffer, in most cases the driver does not care of the device has already observed the effect or not
<arnd>
Driver only cares that it has observed it by the time of the next readl(), and that is guaranteed. One exception is the case where you have to insert a fixed delay after a write
<mani_s>
arnd, exactly, that's what I'm fixing in couple of places
<mani_s>
there are udelays after a write
<mani_s>
so there is no guarantee that the write has reached the device before udelay
Daanct12 has quit [Quit: Leaving]
<DavidHeidelberg[m]>
robclark: Hey! Sorry to disrupt, can I move forward with skqp bump to Android CTS 11 for Mesa or you wan't to compare results?
lumag__ has joined #linux-msm
jnn is now known as jn
lumag__ has quit [Quit: Leaving]
svarbanov has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
svarbanov has quit [Remote host closed the connection]
Daaanct12 is now known as Danct12
pespin_ has joined #linux-msm
pespin has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
<robclark>
DavidHeidelberg[m]: iirc it was all passing? I think it is safe to merge.. it might be another week or so before I'm at the point of being ready to test android 11 cts without virgl in the picture..
<DavidHeidelberg[m]>
robclark: all PASS
<DavidHeidelberg[m]>
I'll move it from Draft then :)
<robclark>
sounds good
<lumag_>
In case anybody wants old stuff. eBay has notified me that there are several old Intrinsyc devkits with 8074/8084/8994/8996 on sale. Note that the CPU in the description doesn't match the photo.
<konradybcio>
Please link 8994 :)
<konradybcio>
Oh wow it's surprisingly expensive for old ewaste..
<bamse>
certainly so
<Mis012[m]>
bamse: is there something blocking the SSC series from getting merged?
<bamse>
Mis012[m]: taking a look at it
<Mis012[m]>
thx :)
<bamse>
Mis012[m]: looks good to me now, so i've queued it, will run some build tests etc on it
<bamse>
Mis012[m]: seems reasonable to post that as well
<bamse>
Mis012[m]: where you able to figure out how to use the i2c controller btw?
<bamse>
controllers*
<Mis012[m]>
bamse: yeah, there's just one slight issue..
<Mis012[m]>
I can't figure out how to properly control the PLL
<Mis012[m]>
if I leave it alone and tell Linux that it's a fixed clock, the i2c bus works at some unknown frequence
<Mis012[m]>
*frequency
<Mis012[m]>
some places say it's a fabia PLL, one place called it something different
<Mis012[m]>
bamse: I'm not sure if Linux even supports smooth reparenting where the PLL doesn't go down
<Mis012[m]>
and it's probably important for the bus
<bamse>
Mis012[m]: what do you mean with smooth reparenting?
<Mis012[m]>
well... I think you need to set the SSC_100m parent to something like XO, then configure and restart the PLL, and then set the parent back to the PLL
<Mis012[m]>
since accessing the PPL's registers is dependent on the bus being alive, and I think it goes down if SSC_100m dies
<bamse>
i see, so get the children off the pll to avoid propagating glitches
<bamse>
the bus to reach the pll registers are clocked by the same pll?
<Mis012[m]>
I mean, I don't have the docs, you do :P
<Mis012[m]>
but it would seem so from everything I've seen
<Mis012[m]>
the only way I was able to get the i2c clock to work was to lie to Linux so that it doesn't touch anything other than the i2c clock enable bit
<Mis012[m]>
bamse: it is my suspicion that the SSCAON poking starts the PLL in some capacity, and I don't recall what it sets the SSC_100m parent to, but all in all poking that stuff didn't really help me understand it because there's so much "changes only apply after you do X" that it's pretty hard to do anything manually