brads has quit [Read error: Connection reset by peer]
brads has joined #linux-amlogic
_whitelogger has joined #linux-amlogic
Darkmatter66 has joined #linux-amlogic
Darkmatter66_ has quit [Ping timeout: 268 seconds]
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-amlogic
jakogut has quit [Remote host closed the connection]
Barada has quit [Quit: Barada]
<xdarklight>
narmstrong: (AntonioND is gone, maybe you can give him this info later) I think on Odroid-C2 there was a switch in boot.ini which *either* enabled the "arm,armv8-timer" *OR* ISA_TIMER A..D
<xdarklight>
I have never tested it but it seemed to me that both cannot be used at the same time (I may be wrong though)
<mjourdan>
also lowered the min amount of H.264 buffers to 2
return0xe has quit [Read error: Connection reset by peer]
return0e has joined #linux-amlogic
ldevulder_ is now known as ldevulder
vagrantc has joined #linux-amlogic
afaerber_ has joined #linux-amlogic
afaerber_ has quit [Client Quit]
afaerber has quit [Ping timeout: 252 seconds]
ldevulder has quit [Quit: Leaving]
ldevulder has joined #linux-amlogic
AntonioND has joined #linux-amlogic
<xdarklight>
AntonioND: you were offline when I sent this:
<xdarklight>
[07:14:48] <xdarklight> narmstrong: (AntonioND is gone, maybe you can give him this info later) I think on Odroid-C2 there was a switch in boot.ini which *either* enabled the "arm,armv8-timer" *OR* ISA_TIMER A..D
<xdarklight>
[07:15:05] <xdarklight> I have never tested it but it seemed to me that both cannot be used at the same time (I may be wrong though)
<AntonioND>
i am using timer E and A at the same time right now
<AntonioND>
and both of them seem to work, but my interrupt handler for timer A isn't triggered
<AntonioND>
however, regarding that boot ini stuff
<AntonioND>
I've taken a look at the dts, but the architectural timer that I have to use seems to be memory mapped, it's not a per-cpu timer like the ones of the dts
<AntonioND>
I can only use the ISA_TIMERs
<AntonioND>
because as far as I understand they are per soc
<AntonioND>
so
<AntonioND>
I got the counters working
<AntonioND>
timer E always increases, I use that for a generic timestamp
<AntonioND>
timer A always goes down and reloads the initial value, which also works
<AntonioND>
i've been out until a few minutes ago, and right now I'm trying to read the GIC registers to see if there is a pending interrupt at least
<xdarklight>
I believe ISA_TIMER A..E are there, but cannot generate interrupts (not routed, disabled via muxing, etc.)
<xdarklight>
(please read: "I believe" - I can't prove it)
<AntonioND>
really? the datasheets even mentions the interrupt IDs that the GIC has assigned for them
<AntonioND>
I mean, I don't know
<AntonioND>
the datasheet has other typos
<xdarklight>
I've learned not to trust the datasheet. and sometimes the existing code can't be trusted either ;)
<AntonioND>
it says that timer E doesn't generate interrupts
<AntonioND>
but in theory the rest do
<AntonioND>
and yeah, I don't trust it too much either :P
<xdarklight>
:P
<AntonioND>
however, I also don't understand the gic too well, so I'm taking a look at yet another datasheet about the gic
<AntonioND>
well, datasheet...
<AntonioND>
specs
<xdarklight>
if you have a working driver for the ISA_TIMER then it should be easy to switch to a different register address and use another set of IRQs to simply test the interrupts of ISA_TIMER F..I
<AntonioND>
oh shit
<AntonioND>
the numbers in that dts are different
<AntonioND>
for the IRQs
<xdarklight>
that's because there's two instances of ISA_TIMER
<AntonioND>
?
<AntonioND>
timer I: interrupts = <0 63 1>;
<AntonioND>
according to the datasheet it's 92
<AntonioND>
ok, this is bad...
<AntonioND>
the datasheet has a typo in the registers of timer F-I though
<AntonioND>
well
<AntonioND>
a big typo
<AntonioND>
the register is repeated from the one of A-E
<AntonioND>
or something
<AntonioND>
I'll just take the defines from this dts
<xdarklight>
the IRQ numbers in the datasheet are off by 28 btw
<AntonioND>
...
<xdarklight>
uart0_irq = 54, but uart_A in Linux uses IRQ 26
<AntonioND>
...
<AntonioND>
WHY
<AntonioND>
but wait, that can't be right
<AntonioND>
I think that IDs up to 31 are special
<xdarklight>
TimerF = 89, that .dtsi uses 60 though (off by 29) ...
<AntonioND>
yes, SPIs are 32-1019
<xdarklight>
might be the PPI IRQ lines (random guess though)
<AntonioND>
shared interrupts
<AntonioND>
maybe linux adds 32 to all the values there?
<xdarklight>
possible
<AntonioND>
however
<AntonioND>
28?
<AntonioND>
that makes no sense
<AntonioND>
32 fair enough
<AntonioND>
but 28 is certainly weird
<xdarklight>
I've no clue either
<xdarklight>
if you're curious: the 32-bit SoCs actually use timer A..E (at least in theory). IRQ lines are (from Linux perspective): GIC_SPI 10 (A), 11 (B), 6 (C), 29 (D)
<AntonioND>
ok, I'm not going to waste my time with this, if the IRQs are actually being generated they are setting a bit in some gic register. I'm just going to dump them all and see which one is actually being set, if any
<xdarklight>
yep, sounds like a good thing to do
<AntonioND>
GICD_ISPENDRn
<AntonioND>
that's what I was looking for
<xdarklight>
I'll get myself ready for bed now. if you have questions which you want to ask then please do it now ;)
<AntonioND>
nothing in particular, thanks for the help! I didn't know about this mismatch...
<AntonioND>
I'll have to be careful
<xdarklight>
else I'll go dreaming of open source firmware on 64-bit Amlogic chips ;)
<AntonioND>
ahaha
<AntonioND>
you can go :P
<xdarklight>
good luck with the timer and thanks for you work!
<AntonioND>
thanks!
Darkmatter66 has joined #linux-amlogic
<ndufresne>
mjourdan, nice, will give it a try
<ndufresne>
note that I don't yet have SOURCE_CH "optimization" in GStreamer
<ndufresne>
I just reset the decoder and send the headers again, though it didn't always work with amlogic driver
Darkmatter66_ has quit [Ping timeout: 252 seconds]