ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
hipboi has quit [Ping timeout: 258 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
chewitt_ has joined #linux-rockchip
chewitt has quit [Ping timeout: 248 seconds]
kevery has joined #linux-rockchip
kevery has quit [Remote host closed the connection]
kevery has joined #linux-rockchip
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 268 seconds]
hipboi has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 268 seconds]
kevery1 is now known as kevery
lurchi__ has joined #linux-rockchip
lurchi_ has quit [Ping timeout: 272 seconds]
indy has quit [Ping timeout: 268 seconds]
indy has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 268 seconds]
kevery1 is now known as kevery
indy has quit [Ping timeout: 240 seconds]
repk has quit [Ping timeout: 240 seconds]
repk has joined #linux-rockchip
indy has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 240 seconds]
kevery1 is now known as kevery
alpernebbi has joined #linux-rockchip
warpme_ has joined #linux-rockchip
archetyp has joined #linux-rockchip
stikonas has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
chewitt_ has quit [Ping timeout: 245 seconds]
chewitt has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
stikonas has quit [Quit: Konversation terminated!]
stikonas has joined #linux-rockchip
hipboi has quit [Remote host closed the connection]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 268 seconds]
hipboi has joined #linux-rockchip
kevery has quit [Quit: kevery]
lurchi__ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-rockchip
hipboi has quit [Remote host closed the connection]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 248 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Remote host closed the connection]
hipboi has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
lurchi__ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
hipboi has quit [Remote host closed the connection]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 258 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 245 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 258 seconds]
hipboi has joined #linux-rockchip
CounterPillow has joined #linux-rockchip
hipboi has quit [Ping timeout: 245 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 248 seconds]
chewitt_ has joined #linux-rockchip
chewitt has quit [Ping timeout: 240 seconds]
superherointj has joined #linux-rockchip
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 245 seconds]
<CounterPillow>
Of course I only notice how very suspect the ad-hoc definition of writeq is in this driver after I submit my series to the mailing list, aaaaaaa
ServerStatsDisco has joined #linux-rockchip
MatrixTravelerbo has joined #linux-rockchip
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
<robmur01>
indeed, I was thinking of commenting on that, but then I tried to make sense of why it's even there in the first place... :/
<CounterPillow>
Yeah that's gonna be removed in v2 and replaced with an include of <linux/io.h>
hipboi has quit [Ping timeout: 240 seconds]
vagrantc has joined #linux-rockchip
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 268 seconds]
hipboi has joined #linux-rockchip
chewitt has joined #linux-rockchip
chewitt_ has quit [Ping timeout: 240 seconds]
<robmur01>
if you still want a writeq() for the sake of code simplicity there's linux/io-64-nonatomic-lo-hi.h (or the hi-lo version)
<robmur01>
but it looked like some pretty sketchy optimisation assuming atomicity which STRD to Device memory doesn't guarantee, and that might be broken for big-endian
<robmur01>
and at that point I decided to get back to what I was supposed to be doing instead :)
hipboi has quit [Ping timeout: 245 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 248 seconds]
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-rockchip
<CounterPillow>
I'm not sure what I want, but mutual exclusion with other threads shouldn't be a problem since that writeq happens while we hold a spinlock. I don't know anything about atomicity of the device reading a half-written q sized reg. Does the writeq from <linux/io.h> not guarantee atomic writes on platforms where this would be used (i.e. ARM/ARM64)?
<CounterPillow>
If I have to do something special and use two writels instead that'd work for me too. I really don't care about the performance optimisation of a device reset, especially considering this precedes a udelay(150) usually lol
hipboi has joined #linux-rockchip
<robmur01>
yes, "proper" writeq() is atomic where it exists - the places where it doesn't (Arm, M68k etc.) are the ones which can't provide that behaviour. Hence why the nonatomic headers are an explicit opt-in for drivers which don't need the atomicity but want portable convenience
<robmur01>
it's certainly not clear what badness might occur if we took an interrupt between toggling the TX and RX resets
<robmur01>
or even if there is a reason, why it's worth all the bother of still trying to avoid masking interrupts sometimes
<CounterPillow>
is masking interrupts the local_irq_save stuff?
hipboi has quit [Ping timeout: 245 seconds]
<robmur01>
yup
<CounterPillow>
So you'd recommend just making the assert/deassert always the default case? That works for me, gets rid of a lot of code that I quite frankly would only understand after consulting the register map some more
<robmur01>
TBH the overhead of all the calculation and branching for all the special cases may well end up being more than that of just firing off two writes, even when they're to the same register
<CounterPillow>
Just to be clear: I didn't leave that code there because I thought it was good, I left it there because I thought it was needed, so if it's really just a pointless optimisation I'm more than happy to get rid of it.
<CounterPillow>
(the checking of the order of the banks made me think it was some special behaviour for certain orderings)
<robmur01>
indeed, at this point the question is how much of it actually matters
<CounterPillow>
One of the issues is that I don't actually have a device where I can try and trigger a synchronous reset of both tx and rx, the device I'm testing with only uses the TX clock so goes down a different code path should it ever need a reset.
<robmur01>
AFAICS that bit is just about detecting two adjacent registers and packing the respective 32-bit words into a 64-bit dword the appropriate way round, which I suspect is broken for big-endian anyway
<CounterPillow>
Yeah okay then that code is a definite candidate for removal in V2, since it just seems to serve to end up using the writeq foot-gun
<robmur01>
I particularly like that that case does all the extra work before even checking whether it's useful, so half the time it'll be an objective deoptimisation :)
<robmur01>
oh, the joy of BSP code!
<CounterPillow>
Yeeep
<CounterPillow>
I removed some if (foo) return bar; if (!foo) return baz; from that driver
hipboi has joined #linux-rockchip
<robmur01>
at least with the more mature drivers you can often dig through the history to infer if something weird-looking was put there in response to a specific issue
hipboi has quit [Ping timeout: 240 seconds]
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-rockchip
<CounterPillow>
Admittedly I probably still need to keep the case where tx_bank == rx_bank, but that's easily handled
hipboi has joined #linux-rockchip
chewitt has quit [Quit: Zzz..]
warpme_ has quit [Quit: Connection closed for inactivity]
chewitt has joined #linux-rockchip
shoragan has quit [*.net *.split]
shoragan has joined #linux-rockchip
hipboi has quit [Ping timeout: 258 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 245 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 248 seconds]
lurchi__ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-rockchip
hipboi has joined #linux-rockchip
alpernebbi has quit [Quit: alpernebbi]
hipboi has quit [Ping timeout: 245 seconds]
archetyp has quit [Quit: Leaving]
hipboi has joined #linux-rockchip
indy has quit [Ping timeout: 258 seconds]
hipboi has quit [Ping timeout: 268 seconds]
hipboi has joined #linux-rockchip
indy has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
lurchi__ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
superherointj has quit [Quit: Leaving]
hipboi has quit [Ping timeout: 258 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
<mmind00>
alyssa: haha, though I can't take credit for that ... that was already in the original dts from Hardkernel
<alyssa>
ah well, it's still quality :)
* alyssa
is trying to resucitate her go advance for mesa
* mmind00
needs to revive his Go for gaming :-)
<pgwipeout[m]>
That is beautiful.
<alyssa>
...how does the go advance boot?
<alyssa>
oh. separate partition. lovely.
hipboi has joined #linux-rockchip
<pgwipeout[m]>
So how is the go advanced's game performance anyways?
<mmind00>
pgwipeout[m]: I'd say usable ... I was playing Sega Master-System and Genesis Games on it ... so enough for childhood memories ;-)
<pgwipeout[m]>
Ah, so the perfect emulator box.
vagrantc has quit [Quit: leaving]
<mmind00>
at some point I caved and used one of those emu-something images based on the vendor kernel ... to be able to "game" a bit
<alyssa>
hm.
<pgwipeout[m]>
Only mainline for me. Waiting for the sources to drop for the rk356x ATF.
<alyssa>
rk3326 mainline is sseeming unhappy
<pgwipeout[m]>
What's not great?
* mmind00
just saw a news article today about the Pine epaper device based on the rk3566 ... sounds definitly great
<alyssa>
pgwipeout[m]: having troubles with my USB, but looking like a me problem
<alyssa>
mmind00: panfrost!
<pgwipeout[m]>
Well not until we get a functional driver for the ePaper controller.
<alyssa>
Aug 17 23:23:58 sweetiebelle kernel: [ 2.138910] W : [File] : drivers/gpu/arm/bifrost_for_linux/platform/rk/mali_kbase_conf
<alyssa>
okay now I know I'm being toyed with.
<mmind00>
hehe
<mmind00>
alyssa: not sure what you built, but the "Go" has an SPI flash containing a bootloader image ... if you have an sd-card with separate uboot, the one in SPI would take precendence
<pgwipeout[m]>
alyssa The phy drivers are quite unpleasant. While porting over rk35 I noticed *it never actually enables the interrupts or does anything with them*
<alyssa>
pgwipeout[m]: oof
<alyssa>
mmind00: oof
<pgwipeout[m]>
Does the go have a way to disable the SPI if needed?
<mmind00>
yeah, there is a button next to the sd-card slot
<mmind00>
the regular "maskrom" switch that disables the SPI in this case
<pgwipeout[m]>
Oh good.
<pgwipeout[m]>
Oh.
hipboi has quit [Ping timeout: 240 seconds]
<pgwipeout[m]>
I don't like maskrom, I find it incredibly unpleasant, but it's better than nothing.
<mmind00>
"maskrom" on Rockchip boards in most cases just means "disable the primary boot device"
<alyssa>
okay. now i'm getting video corruption like crazy in u-boot
<alyssa>
looks pretty gnarly. this can't be good.
<alyssa>
rainbow stripes at the bottom, text becomes progressively worse...
<pgwipeout[m]>
Wrong clock?
<alyssa>
i haven't compiled anything
<pgwipeout[m]>
Yeah but at least downstream uboot has a hard time coping when the kernel changes clocks then reboots.
<alyssa>
oof
<alyssa>
System Failure. ok, is that progress? :-p