s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
andy25225 has quit [Ping timeout: 256 seconds]
DrFrankensteinUK has quit [Ping timeout: 265 seconds]
mmarc__ has joined #linux-sunxi
andy25225 has joined #linux-sunxi
DrFrankensteinUK has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 272 seconds]
warpme_ has quit [Quit: Connection closed for inactivity]
asdf28 has quit [Ping timeout: 240 seconds]
NekoMay has quit [Ping timeout: 260 seconds]
NekoMay has joined #linux-sunxi
bshah has quit [Excess Flood]
bshah has joined #linux-sunxi
victhor has quit [Quit: Leaving]
mmarc__ has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
mmarc__ has quit [Ping timeout: 272 seconds]
Mangy_Dog has quit [Ping timeout: 240 seconds]
apritzel has quit [Ping timeout: 246 seconds]
lkcl has quit [Ping timeout: 246 seconds]
BluesBoy has quit [Ping timeout: 256 seconds]
mripard has quit [Ping timeout: 256 seconds]
mripard has joined #linux-sunxi
lkcl has joined #linux-sunxi
zhovner has quit [Quit: bye]
zhovner has joined #linux-sunxi
<smaeul>
apritzel: implementing .get_sys_suspend_power_state causes the PSCI_SYSTEM_SUSPEND_AARCH64 capability to be reported, so Linux exposes "deep" mem_sleep
<smaeul>
when entered, TF-A calls .pwr_domain_suspend with whavever state you return from .get_sys_suspend_power_state
<smaeul>
that's about it. right now .pwr_domain_suspend does nothing for CLUSTER/SYSTEM_PWR_LVL, so it has the exact same power consumption as all cores idle
<smaeul>
it will never be quite as deep as crust, because you have to keep the GIC powered and clocked to be able to wake up
<smaeul>
a logical next step would be to add DRAM self-refresh and bus clock reparenting in .pwr_domain_suspend/.pwr_domain_suspend_finish
<smaeul>
well, except that H616 being that it runs from DRAM, can't do anything that would break DRAM access (can A53s do cache-as-RAM?)
BluesBoy has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 272 seconds]
buzzmarshall has quit [Remote host closed the connection]
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
gediz539 has joined #linux-sunxi
gediz0x539 has quit [Ping timeout: 240 seconds]
faruk has joined #linux-sunxi
<gediz539>
MoeIcenowy: is there a newer A33 BSP SDK? which kernel version?
<apritzel>
mripard: AFAIK the (external) Cortex-A9 L2 cache controller was the last one to support cache lockdown, all the later cores, including the A7, cannot do this anymore
matthias_bgg has quit [Quit: Leaving]
matthias_bgg has joined #linux-sunxi
kayterina has joined #linux-sunxi
victhor has joined #linux-sunxi
bauen1 has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
TheSeven has joined #linux-sunxi
scherazada has joined #linux-sunxi
scherazada has quit [Client Quit]
mmarc__ has joined #linux-sunxi
netlynx has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
<prefixcactus>
apritzel: I'm starting to split up the DT between the SoM and the devboard. How much do you suggest I move out?
<apritzel>
prefixcactus: everything that is on the SoM should be in the SoM .dtsi
TheSeven has quit [Remote host closed the connection]
<apritzel>
prefixcactus: so the PMIC/AXP node, the eMMC, the pio power supplies
<apritzel>
for the actual regulator node (®_dldo4 & friends), I would put them where they are used, which is most likely the devboard
<prefixcactus>
apritzel: how about the gmac node? it should belong to the SoM, right?
alexxy[home] has joined #linux-sunxi
alexxy has quit [Ping timeout: 264 seconds]
<prefixcactus>
also: the regulators mentioned under the pio node have names like "vcc-wifi-io" and "vdd2v5-sata". Which is probably irrelevant on the SoM. Should I rename them?
<prefixcactus>
or just never bring them in and expect any future SoM users to add those to their board .dts?
alexxy[home] has quit [Ping timeout: 264 seconds]
alexxy has joined #linux-sunxi
alexxy has quit [Client Quit]
ganbold has quit [Quit: Leaving]
alexxy has joined #linux-sunxi
alexxy has quit [Client Quit]
<apritzel>
prefixcactus: hard to say from here, that depends on the pinout of the SoM and the PIO port
<apritzel>
for instance if all pins of a certain port are routed to the SoM connector, but not used on the SoM itself, then it should not be in the SoM .dtsi
alexxy has joined #linux-sunxi
<apritzel>
don't worry too much, it's not trivial, and we will spot and fix this in the review
<prefixcactus>
OK.
<prefixcactus>
I'll put them in the dtsi for now then
<prefixcactus>
apritzel: what about the gmac node?
alexxy has quit [Ping timeout: 264 seconds]
alexxy[home] has joined #linux-sunxi
alexxy[home] has quit [Client Quit]
alexxy has joined #linux-sunxi
jbrown has joined #linux-sunxi
<prefixcactus>
also, the uarts are labeled as such on the SoM pinout, but I suppose the pins can be used as GPIOs as well. Does that mean they should stay on the board dts?
alexxy has quit [Ping timeout: 240 seconds]
victhor has quit [Ping timeout: 260 seconds]
victhor has joined #linux-sunxi
alexxy has joined #linux-sunxi
alexxy has quit [Ping timeout: 240 seconds]
sunshavi has joined #linux-sunxi
alexxy has joined #linux-sunxi
alexxy has quit [Excess Flood]
alexxy has joined #linux-sunxi
alexxy has quit [Excess Flood]
alexxy has joined #linux-sunxi
alexxy has quit [Excess Flood]
<apritzel>
prefixcactus: everything that goes just to the SoM connector should not be in the .dtsi
<apritzel>
prefixcactus: I think that applies to the GMAC as well
alexxy has joined #linux-sunxi
alexxy has quit [Excess Flood]
alexxy has joined #linux-sunxi
alexxy has quit [Excess Flood]
alexxy has joined #linux-sunxi
alexxy has quit [Excess Flood]
alexxy has joined #linux-sunxi
victhor_ has joined #linux-sunxi
alexxy has quit [Ping timeout: 240 seconds]
alexxy has joined #linux-sunxi
victhor has quit [Disconnected by services]
victhor_ is now known as victhor
alexxy has quit [Ping timeout: 264 seconds]
juri_ has quit [Ping timeout: 265 seconds]
alexxy has joined #linux-sunxi
alexxy[home] has joined #linux-sunxi
alexxy has quit [Ping timeout: 256 seconds]
alexxy[home] has quit [Excess Flood]
juri_ has joined #linux-sunxi
Guest16774 has joined #linux-sunxi
Guest16774 has quit [Ping timeout: 240 seconds]
alexxy[home] has joined #linux-sunxi
alexxy[home] has quit [Excess Flood]
mmarc__ has quit [Remote host closed the connection]
alexxy[home] has joined #linux-sunxi
alexxy[home] has quit [Excess Flood]
alexxy[home] has joined #linux-sunxi
alexxy[home] has quit [Excess Flood]
mmarc__ has joined #linux-sunxi
alexxy[home] has joined #linux-sunxi
alexxy[home] has quit [Excess Flood]
alexxy[home] has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
JohnDoe_71Rus has joined #linux-sunxi
alexxy[home] has quit [Quit: No Ping reply in 180 seconds.]
mmarc__ has quit [Remote host closed the connection]
alexxy[home] has joined #linux-sunxi
alexxy[home] has quit [Read error: Connection reset by peer]
mmarc__ has joined #linux-sunxi
alexxy[home] has joined #linux-sunxi
alexxy[home] has quit [Ping timeout: 256 seconds]
alexxy[home] has joined #linux-sunxi
BluesBoy has quit [Quit: leaving]
alexxy[home] has quit [Client Quit]
alexxy has joined #linux-sunxi
alexxy has quit [Read error: Connection reset by peer]
<mirko>
on my H6 powered opi3, i'm abusing SPI for timing critical LED addressing (SK6812), however still have occasional glichtes which can't be much more anymore than SPI timing. since the opi3 doesn't have I2S exposed (which I'd have tried/used otherwise), is there any peripheral which I might achieve tigher timings with (e.g. UART) or is there sth. I can do about the SPI offs?
<prefixcactus>
apritzel: No, but I will tomorrow, thanks for pointing them out :)
alexxy has joined #linux-sunxi
alexxy has quit [Ping timeout: 240 seconds]
cmeerw has joined #linux-sunxi
alexxy has joined #linux-sunxi
alexxy has quit [Ping timeout: 264 seconds]
<apritzel>
mirko: so you are fabricating SPI transfers, that happen to contain the RGB data for your LEDs?
mmarc__ has quit [Remote host closed the connection]
<mirko>
apritzel: correct
<mirko>
apritzel: it's quite a long strip, hence lot's of data, so i'm fearing that it get chunked and there's delays happening in between them
<apritzel>
mirko: and you send messages for each LED back to back?
<mirko>
apritzel: no, i prepare the payload and dump it onto /dev/spidevX.Y
<apritzel>
mirko: IIRC there was some maximum transfer length in the controller?
<apritzel>
mirko: which might break up your message
<mirko>
apritzel: yeah, that's what i'm fearing. i already had to increase the max xfer size within the driver
<mirko>
well, that was for spidev, nothing HW specific, though - but still indicates it's quite some amount of data
<apritzel>
mirko: and if you break your message down into smaller chunks, and send them one after another to spidev? So that the driver only ever sees smaller transfers?
<apritzel>
mirko: you could also check if the driver uses DMA or not, and play around with this
<MoeIcenowy>
prefixcactus: well this patch should be one that works on both BPi M2U and your board
alexxy has joined #linux-sunxi
<mirko>
apritzel: i'm referencing the HW SPI bus within the spidev dts overlay, so whouldn't this imply DMA?
<apritzel>
the driver enables DMA only if the transfer size is bigger than the FIFO
<mirko>
apritzel: will check for proper chunking within the SW which writes to spidev, yeah
<apritzel>
mirko: I don't know if DMA is good or bad in your case, could be either way
<mirko>
understood
<apritzel>
DMA spoiling continuous bitstreams for some reason, or no DMA generating a small hiccup
alexxy has quit [Excess Flood]
<apritzel>
mirko: so do you see the wrong colours at some point? Can you deduce how many bits went through correctly?
<mirko>
apritzel: it's some occasional flashing of single LEDs, can't tell more than that at the very moment
prefixcactus has quit [Remote host closed the connection]
<mirko>
signal looks very smooth though (verified by scope), even have a schmitt trigger in between because i figured the blur on the tops might be an issue
mmarc__ has joined #linux-sunxi
<apritzel>
so you constantly push bits through, and rely on every bit to be precise and correct?
<mirko>
i rely on them being output at given baudrate, yes
<apritzel>
mirko: the 800 KHz from the datasheet?
<mirko>
which also seems to be the case according scope, my suspicion though now is messages being broken up
<mirko>
apritzel: i never read 800khz re sk6812 ics
<mirko>
but at the baudrate recommended, yes (played around a lot, but mentioned glitches happen with whatever baudrate i set)
<mirko>
obviously the baudrate i set in the dts overlay for spidev is higher than how i configure /dev/spidev from userspace
alexxy has joined #linux-sunxi
alexxy has quit [Excess Flood]
<mirko>
"Transfer size is limited to 64 bytes on sun4i and 128 bytes on sun6i. You have to loop over longer messages in your code. Some SPI devices may require that you prefix each message fragment with a header, other may not. YMMV." - ok, will try to fragment appropriately then
alexxy has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
<apritzel>
mirko: so do you work with bit slots of 0.3us, then send '1000' to encode a 0, and '1100' to encode a 1?
alexxy has quit [Excess Flood]
<mirko>
apritzel: i'm using a hacky-patched version of hyperion-ng currently, not entirely sure about the timings they specify, but will check
Guest60101 has joined #linux-sunxi
<mirko>
but they were wrong about sk6812 specifics before, so it's a good pointer
Guest60101 has quit [Excess Flood]
alexxy[away] has joined #linux-sunxi
alexxy[away] has quit [Excess Flood]
alexxy[home] has joined #linux-sunxi
alexxy[home] has quit [Ping timeout: 264 seconds]
alexxy[home] has joined #linux-sunxi
alexxy[home] has quit [Excess Flood]
alexxy[home] has joined #linux-sunxi
alexxy[home] has quit [Excess Flood]
alexxy[home] has joined #linux-sunxi
alexxy[home] has quit [Excess Flood]
alexxy[home] has joined #linux-sunxi
alexxy[home] has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #linux-sunxi
alexxy has quit [Excess Flood]
alexxy has joined #linux-sunxi
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #linux-sunxi
alexxy has quit [Excess Flood]
alexxy has joined #linux-sunxi
alexxy has quit [Excess Flood]
alexxy has joined #linux-sunxi
alexxy has quit [Excess Flood]
alexxy has joined #linux-sunxi
sunshavi has quit [Read error: Connection reset by peer]
alexxy has quit [Excess Flood]
sunshavi has joined #linux-sunxi
alexxy has joined #linux-sunxi
alexxy has quit [Ping timeout: 256 seconds]
alexxy has joined #linux-sunxi
alexxy has quit [Excess Flood]
alexxy has joined #linux-sunxi
alexxy has quit [Ping timeout: 240 seconds]
alexxy has joined #linux-sunxi
alexxy has quit [Ping timeout: 256 seconds]
alexxy[home] has joined #linux-sunxi
alexxy[home] has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #linux-sunxi
alexxy has quit [Quit: No Ping reply in 180 seconds.]