movedon5b2z4xywybidzannet[m] has joined #linux-sunxi
warpme has joined #linux-sunxi
ungeskriptet is now known as Guest912
ungeskriptet has joined #linux-sunxi
Guest912 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
warpme has quit []
bauen1 has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
KREYREN_oftc has joined #linux-sunxi
hlauer has quit []
apritzel has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
apritzel has joined #linux-sunxi
<KREYREN_oftc>
gamiee, Is it cool if i release an alternative PCB for the pinephone and release it under copyleft license? (I will be forking OLIMEX and BeagleDev designs without using the pinephone schematics)
* KREYREN_oftc
figured out that trying to use the Nokia N900 for the SOM development is more pain than it's worth it in this stage and having just a tiny PCB that connects to the display is better for the development
warpme has joined #linux-sunxi
warpme has quit []
dsimic is now known as Guest922
dsimic has joined #linux-sunxi
Guest922 has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Ping timeout: 480 seconds]
<dok>
Jookia: dfu has a max packet size of 64 bytes so that might be why it is slower that fastboot, but it is should still be fast
<Jookia>
it's very strange
<Jookia>
i see a packet size of 4096
<dok>
maybe not in dfu
<dok>
i think dfu transfer speed should be around 512kB/s
<dok>
but my knowledge of dfu is decaying
<dok>
iirc the 64 bytes limitation comes from the fact that dfu only uses the endpoint 0
Schimsalabim has quit [Read error: Connection reset by peer]
<ity>
KREYREN_oftc: since when are you back on copyleft?
warpme has joined #linux-sunxi
wingrime1 has quit [Ping timeout: 480 seconds]
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit []
kilobyte1 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
kilobyte1 has joined #linux-sunxi
warpme has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
warpme has quit [Read error: Connection reset by peer]
<macromorgan>
apritzel: Do we know the GIC_SPI interrupt for the NMI? I'm seeing 135 for the H616, but in the device tree from that 4.9 branch kernel I'm looking at (as well as the BSP) they have it as 103...
<apritzel>
the GIC interrupt ID is 135, which translates into SPI 103 in the DT, since the first SPI (shared peripheral interrupt) has interrupt ID 32
<acmeplus>
Thanks, I was looking at the sonic pad os bsp and realized that it had almost the same configuration and references as the trimui smart pro kernel config.
<macromorgan>
okay, checking the nmi controller and thinking I have everything right, I get the following errors (but I think stuff works otherwise?): `axp20x-i2c 0-0034: Failed to ack 0x48: -5`
<macromorgan>
power button causes it to go nuts acking the interrupt too it seems
<macromorgan>
axp20x-i2c 0-0034: Failed to ack 0x49: -5
vagrantc has joined #linux-sunxi
<apritzel>
interesting. May be worth to double check the interrupt description in the AXP717 driver
<macromorgan>
yeah, i see a rising edge, falling edge, short press, and long press
<macromorgan>
I'm going to disable the power button so I can see what i2cdump shows, maybe it's trying to clear an IRQ it's not aware of?
acmeplus has quit [Ping timeout: 480 seconds]
<macromorgan>
it looks like by default a fair number of IRQs are unmasked. Do we need to mask them or update the driver to note they're unmasked?
<macromorgan>
or maybe not, looks like the only IRQs really unmaksed are the power button ones (PEK)
apritzel has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
<macromorgan>
hmm... if I renumber the clocks in sun50i-h616-ccu.h how badly will I break stuff? Looks like the GPADC clock I need is missing...
chewitt has quit [Quit: Zzz..]
bauen1 has joined #linux-sunxi
AntoniAloyTorrens[m]1 has quit []
MatrixTravelerbot[m] has quit []
psydroid[m] has quit []
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Quasar 5.2.2, revision: 5.2.0+git-7571-8c8adf27c, build type: debug, sources date: 20160102, built on: 2024-03-24 18:03:42 UTC 5.2.0+git-7571-]
aedancullen has quit []
flyback has quit []
flyback has joined #linux-sunxi
KREYREN_oftc has joined #linux-sunxi
hentai has quit [Quit: SIGTERM]
apritzel has joined #linux-sunxi
<apritzel>
macromorgan: you cannot renumber, that would break older DTs. This isn't explicitly stated anywhere, but the clock numbers are part of the DT binding.
<apritzel>
but that's not a problem, just add the clock at the end, wouldn't be the first time we do this
<apritzel>
the numbers are arbitrary anyway, they just become ABI once they are out
<macromorgan>
gotcha, thanks
<macromorgan>
I'll need to add a clock so I can add the gpadc
<macromorgan>
it looks like it just uses the system's 24MHz clock but it's behind a gate
<apritzel>
0x9ec?
<macromorgan>
I think so, I closed my tabs for the weekend :-p
<apritzel>
macromorgan: do you look at the T5 series manual? I guess the T507 is a super set of the H616 and H700
<macromorgan>
I don't have anything except the H616 manual
<apritzel>
that shows the GPADC clock, and there is probably more in there
cmeerw[m] has quit []
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<tokyovigilante>
thanks acmeplus
<tokyovigilante>
question about the compatible string, should we be using "allwinner,sun50i-h616", "allwinner,sun50i-h700", or both? the cpufreq driver will match either but presumably not any other driver looking for the h616?
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Ping timeout: 480 seconds]
cyrevolt has quit []
<apritzel>
there should be no other driver looking for the board compatible string. cpufreq-dt doing so is an unfortunate situation, but that should not happen again
<apritzel>
besides, we have precedence with the H616/H618 situation
<apritzel>
so I'd say we go with just -h700
<tokyovigilante>
ok cool, thanks. Also any issue with pushing this without the corresponding u-boot DRAM patches?