<oliv3r>
arokux: poke turl, he's the clk maintainer :p but yes
panda84kde has joined #linux-sunxi
<arokux>
oliv3r, ok! thanks
diego has joined #linux-sunxi
<hno>
oliv3r, yes very confusing about EMAC/GMAC.
<arokux>
Turl, can you take a look at it? ---^
diego is now known as Guest349
<arokux>
(at clocks, a bit higher in the messages)
<mripard_>
arokux1: the clock "driver" should be in driver/clk/..., the clock definition, with its parent, rates et al. in the DT
Guest349 has left #linux-sunxi [#linux-sunxi]
<oliv3r>
hno: the intro even lists both seperatly, i haven't looked at the PIO map
<oliv3r>
but maybe mii and rmii (gmac) are on the same pins, but different controllers
<oliv3r>
it's silly really, as rmii can do 100mbit just fine
<arokux>
mripard_, so usbc_phy_gate, ohci_phy_gate and usbc_phy_reset are different from ahb clocks?
<oliv3r>
but if they are seperate pins, dual ethernet :)
<arokux>
mripard_, oh, sorry, the others are also there. so you just haven't added usbc_phy_gate, ohci_phy_gate and usbc_phy_reset, right?
<mripard_>
arokux: it looks that way yes
<mripard_>
yep
<panda84kde>
hi channel guys :)
<hno>
oliv3r, afaik there is only one set of ethernet pins.
<hno>
hi panda84kde
<hno>
oliv3r, yes it's a bit stilly. gmac can do 10/100/1000. emac can barely do 10/100..
<panda84kde>
I've hear from the KDE / PA / Vivaldi guys that A10/A20 are among the most Free Software friendly. I've heard that the only binary part used is the GPU 3D blob, but that even that might be eventually replaceable with lima driver. Are there things more or less true?
<mripard_>
the GMAC and EMAC don't appear to be pin-compatible, that might explain
<oliv3r>
i wonder if the gmac can work with a 100 mbit PHY
stekern has quit [Remote host closed the connection]
<oliv3r>
afaik rmii is backwards compatible with PHY
<oliv3r>
er MII*
stekern has joined #linux-sunxi
<oliv3r>
so a gmac driver, could work with both the old and the new PHY's but uses a differnt networking IP
<oliv3r>
e.g. cubie2 should/could work much better with the new gmac hardware
<oliv3r>
interesting concept :)
<oliv3r>
anyway, editing the memory map wiki page to fill in th eblank
<hno>
oliv3r, there is still many blocks not documented in the manual.
<oliv3r>
yeah :(
<oliv3r>
allready saw :(
<oliv3r>
why, WHY!
<hno>
but they are getting fewer with each release.
<hno>
why? Because they do not have any digestable manuals most likely.
<oliv3r>
yeah i know
<oliv3r>
well some sections they delibertaly remove
<hno>
or because it's not AW blocks.
<oliv3r>
that's most likly the case
<hno>
i.e. GPS block is all third party.
<oliv3r>
how do SPI and USB relate?
<hno>
what do you mean?
<hno>
SPI is a syncronus serial protocol with no standard beond 4 documented & incompatible signalling modes.
<oliv3r>
the wiki says SPI0 (USB OTG)
wingrime has joined #linux-sunxi
<hno>
USB is an asyncronous serial protocol with a standards body documenting every bit.
<hno>
oliv3r, someone made a typo.
<oliv3r>
a big one at that
<oliv3r>
but no relation, what I thought; but maybe I missed something :)
<oliv3r>
it must have been me! history does not lie
<oliv3r>
i guess i added it to the wrong section :S
<hno>
yes
<oliv3r>
but its fixed :)
<oliv3r>
btw, we also have a HDMI1 register, 128kb
<oliv3r>
my guess, it's for the CEC/Networking stuff that's in the 1.4 spec
<hno>
There have always been a HDMI register block.
<arokux>
what ccu and ccmu stand for? clocks unit, clocks management unit? :$
<hno>
but not so large.
<hno>
something like that.
<oliv3r>
hno: the other one still exists
<oliv3r>
i think 1 is for the 'dvi' bit and this one for the additional stuff
marzubus has joined #linux-sunxi
<hno>
it looks like the A20 also have secure boot...
<oliv3r>
arokux: clock control module/unit
<oliv3r>
hno: haven't found that yet, but if they use 'trustzone' for that, figures
<hno>
not trustzone. Only SS and SID.
<oliv3r>
so how do they use secureboot?
<hno>
but a working trustzone requires a working secure boot.
<oliv3r>
i thought secureboot was that the BROM checks the signature of the SPL and only boots that (etc etc)
<hno>
you set store a boot encryption key in SID, and BROM uses SS to decode.
<hno>
and keys locked away from CPU access.
<oliv3r>
ok, maks sense
<oliv3r>
but we can read the SID?
<oliv3r>
so sign our stuff using the sid?
<hno>
not if locked.
<oliv3r>
unless that's the reason we read it back as blank
<oliv3r>
if the BROM can read it, 'so can we'
<oliv3r>
using fel mode at the least i'd hope ;)
<wingrime>
oliv3r: we shold se brom dissasembly
<oliv3r>
wingrime: yeah that's what I mean, if the brom can read it, and we have the brom binary, we should be able to figure out how to unlock the SID and read it back
mcbrick has joined #linux-sunxi
<wingrime>
oliv3r: not simple, for example on intel cpu, some bits can be "locked" writing special bit, after that you can trow but back
<wingrime>
*you can't trow bit back
<oliv3r>
'cpu configuration register' :)
<oliv3r>
wingrime: but if the BROM HAS to read the SID to decrypt the bootloader
<oliv3r>
the BROM needs to be able to read the SID
<oliv3r>
if the BROM can read the sid
<oliv3r>
so can we
<wingrime>
oliv3r: after read and decript brom can set such bit, and it will be unpossible re-activate it latter (except reset glitch)
<oliv3r>
wingrime: but what if we force the chip into FEL mode
<hno>
oliv3r, the BROM can't read it if locked. SS uses it directly from SID: See bottom of page 221.
<oliv3r>
hno: ahhhh, is that new in a20 manual?
<oliv3r>
i'm not that far, doing the wiki dance atm :)
Quarx has quit [Read error: Connection reset by peer]
<oliv3r>
in that case, yeah, we could potentially get fucked :p
<wingrime>
oliv3r: where new man?
<hno>
oliv3r, yes, both SID and SS differs noticeably from sun[45]i.
<wingrime>
hno: SID can something new?
<wingrime>
and SS?
<hno>
it's quite likely possible to read the SID if programming voltage is applied, but unsure if it's possible to get into the execution of locked down CPU.
<hno>
wingrime, SS can do encryption as before. New is that it can use key from SID.
<hno>
SID is larger than before and can be locked so the CPU can't read parts, and BROM supports encrypted boot with locked keys.
jemk has joined #linux-sunxi
<hno>
Haven't looked into the BROM details, only A20 manual.
<wingrime>
hno: are you sure thats new ? I see "1: Select SID_RKEYx from Security ID
<wingrime>
in 13 man
<wingrime>
*a13 man
vi390 has quit [Remote host closed the connection]
arokux has quit [Remote host closed the connection]
<oliv3r>
well our sids on the A20's we have so far are all blank
<oliv3r>
or locked :p
<oliv3r>
wingrime: yep :)
<oliv3r>
wingrime: so SS could use SID in a13 allready?
<oliv3r>
then it's quite likly it could do the same in a10
<oliv3r>
i wonder if we can extract keys using the SS
<wingrime>
oliv3r: a10 have no sid and ss in man so yes
<mripard_>
oliv3r: yeah, I know.
<oliv3r>
oh :(
<oliv3r>
it's used for SMP stuff I take it?
<wingrime>
oliv3r: do you saw Smart Card Reader
<oliv3r>
we had that in A10; it was called SCR :)
tzafrir has quit [Ping timeout: 260 seconds]
<wingrime>
oliv3r: now we have regs in a20 man
<oliv3r>
i also saw that PS/2 is bi-directional, as in it can work as client OR host
<oliv3r>
wingrime: haven't looked that far, filling in the memory map atm
<wingrime>
0_0 PS/2 regs
<oliv3r>
we had those i think
<oliv3r>
or atleast a driver if i'm not mistaken
<oliv3r>
but you can use the a* to emulate a keyboard/mouse :p
<wingrime>
oliv3r: ps/2 mostly useless when you have gpio
<wingrime>
oliv3r: it easy to emulate
<oliv3r>
yeah but if you have it in hardware, might aswell use it
<oliv3r>
saves you from writing a bitbang driver
<oliv3r>
twi3 is new for a20
<oliv3r>
but a10 had the register space
<oliv3r>
it's like they didn't add it to the pinmuxes
<oliv3r>
or, maybe its there but nobody knew about it
<rm>
would be nice to use some old PS/2 mice and keyboards :)
<rm>
and save the few USB ports
<oliv3r>
i agree, i think the cubie even brings out 1 port
<oliv3r>
besides, I find ps/2 far more reliable
<oliv3r>
(if you don't hotplug it)
Kolyan has quit [Remote host closed the connection]
<wingrime>
oliv3r: take a look at new sid
<wingrime>
oliv3r: it now can store more keys
<oliv3r>
nice, but we can't write to it anyway :)
<oliv3r>
but it'll be good to adapt my driver to it :)
Kolyan has joined #linux-sunxi
<wingrime>
When JTAG key read lock flag is off, the 64-bits JKEY value can
<wingrime>
be read out by CPU, else it is undefined.
<oliv3r>
hmm?
<wingrime>
0: HDMI key HDCP value c can keybe read read lock out flag by CPU
<wingrime>
1: key value e can’t be read out by CPU
<oliv3r>
??
<oliv3r>
hdcp uses the SID too?
<oliv3r>
probably via the crypto engine
<wingrime>
oliv3r: we now have more keys in it
<wingrime>
oliv3r: we now have JTAG,BOOT, HDCP keys
<wingrime>
0: Boot key key value read can lock be flag read out by CPU
<wingrime>
l 1: key value can’t be read out by CPU
<wingrime>
oliv3r: I was right it have read lock flags
<hno>
oliv3r, SID writing is documented.
<oliv3r>
hno: oh! ok i will read that first :)
<ganbold>
hm, does same driver for usb ehci work on cubie2/A20?
<oliv3r>
if it's writeable it might be readable the same way; but even so, we can modify it to sign our own stuff if needed (assuming the pins are accesable
<oliv3r>
ganbold: very likly
<hno>
oliv3r, was documented in A13 as well, but looked like A13 manual had wrong register offsets. A20 SID is different.
<hno>
well, not in function but in register offsets, and more functionality.
<oliv3r>
gps is 64k
<oliv3r>
that's one big register
<hno>
GPS is a big black proprietary blob hole.
<oliv3r>
aye
<hno>
but maybe we could get some of the open GPS hackers onboard and do something about that.
<oliv3r>
aye
<oliv3r>
replicant developers should have _some_ expertise there
<oliv3r>
but need a way to connect hardware
<hno>
Need to check if Olimex A20 board have GPS pins routed. I think so.
<wingrime>
Video Engine (Phoenix 3.0)
<oliv3r>
gmac is also 64k register blob?!
<oliv3r>
hno: i think they routed everything
<oliv3r>
wingrime: yeah i posted that: ) we know the name of the VE :)
<hno>
oliv3r, yes I know, but better verify before trying to drag in GPS people.
<hno>
replicant is doing GPS hardware? Most people are only talking to complete GPS modules.
<rellla>
oliv3r, wingrime: isn't there cedarx used in a20?
<oliv3r>
hno: i know they try to reverse the gps on the S2
<oliv3r>
rellla: cedar is called 'phoenix 3.0' in a20
<oliv3r>
so i guess the previous editions are called pheonix 2.0 and 1.0 :)
<oliv3r>
A20 has a high-speed timer
<oliv3r>
maybe a10 has it too
<mripard_>
no
<mripard_>
A10 is the only one that doesn't have it
<hno>
oliv3r, any reference?
<oliv3r>
a13 has it too?
<mripard_>
oliv3r: yep
<wingrime>
why Phoenix 3.0 ?
<wingrime>
it was cedarX
<wingrime>
audio engine still in place
<oliv3r>
sun5i calls it 'sync timer'
<wingrime>
but that we can dts and ac3 undocumented in a20
<oliv3r>
wingrime: maybe that's the name of the IP
<hno>
A10 have at least one high speed timer.
<oliv3r>
hno: the hstimer in a20? 1c6000-1c60fff
<hno>
probably not that.
<mripard_>
hno: you mean the 64 bit counter ?
<hno>
probably. was long since I looked at these things.
<oliv3r>
but interrupt is allready defined as a 1k blok at 1c20400
<oliv3r>
do they have both interrupt controllers in there now?
<hno>
oliv3r, there is never only one interrupt controller...
<oliv3r>
a10 only documented the one, 1k worth of registers ;)
<oliv3r>
this one is huge!
<mripard_>
yeah, the GIC has a lot of features.
<oliv3r>
so it looks like they left the old one inthere too
<oliv3r>
probably doesn't work
<mripard_>
or they just forgot to remove it from the memory mapping
<wingrime>
mripard_: looks like we have normal reset documented in a20 man
<oliv3r>
a20 is resettable?
<oliv3r>
god you people are horrible!
<oliv3r>
defouring the manual like beasts
<prite>
We have a sunxi tablet with an Elan eKTF touchscreen. No official driver source is available, but we found a reverse engineered patch that didn't work too well on Ubuntu.
<prite>
We have now fixed the patch to work on Ubuntu as well as Android. Any considerations before we submit it for merging into sunxi-3.0 tree?
<oliv3r>
port it to sun-3.4 :)
<oliv3r>
we are trying to depreciate the 3.0 tree
<prite>
We would love to use a new(er) kernel! Unfortunately, the patch itself was for 3.0. Will see what we can do.
<oliv3r>
shouldn't be hugly different
<prite>
Btw, when is sun-3.4 slated to be released?
<oliv3r>
prite: who is 'we'?
<oliv3r>
about a year ago?
<mripard_>
wingrime: where ?
<mripard_>
CPU configuration?
<oliv3r>
the reset framework
<oliv3r>
:D
<oliv3r>
oh exciting things
<prite>
oliv3r: 'We' is India's low-cost tablet dev. team. #Aakash
<oliv3r>
prite: ahhh, awesome
<hno>
mripard_, there is one RESET per CPU. Only resets the CPU. Used for hot plug I think.
<wingrime>
mripard_: yes per core
<oliv3r>
must be cpu config then
<oliv3r>
watchdog is probably simpler ;)
<hno>
watchdog resets it all.
<oliv3r>
CPU Build In Selft Test has its register defined at least
<wingrime>
mripard_: read a20 manuak, thre new stuff for smp here
<wingrime>
oliv3r: we have TV encoder registers
prite_ has joined #linux-sunxi
<hno>
wingrime, TV encoder documented now?
<wingrime>
hno: yes
<hno>
that is the TV-out? Or in?
prite has quit [Disconnected by services]
* hno
guesses -out
<wingrime>
out
<wingrime>
as DACs on diagramm
prite_ has quit [Client Quit]
<hno>
Wasn't that documented before? Or only source code?
prite has joined #linux-sunxi
<wingrime>
also usb documented for a20
<oliv3r>
Encoder is is OUT, Decoder is IN
<oliv3r>
wingrime: REALLY?
<oliv3r>
wingrime: we know that there's 4 encoder dacs that are used for VGA (RGB) composite etc etc (see fex guide)
<oliv3r>
anybody have an idea what the AVG modul is? it's the last 128k block beforecoresight debug
<oliv3r>
a13 doesn't seem to have it
<Black_Horseman>
companieros adios
Black_Horseman has quit [Remote host closed the connection]
<oliv3r>
not used in the code however at all
<oliv3r>
it's defined in platform.h; and that's it
<oliv3r>
Automatic Voltage Gain is what makes me think
<wingrime>
oliv3r: most intersting how much undocumented crap we have
<oliv3r>
still yes
<oliv3r>
but ti's getting better
<panda84kde>
hi guys. Has Mali400 binary dirver been tested on A20 or only on A10?
<oliv3r>
i think only a10
<panda84kde>
Is there any blocker on A20 (e.g. missing kernel modules) or should it work the same?
<oliv3r>
no clue afaik
<oliv3r>
but not much imo
eebrah|away is now known as eebrah
painkill3r has quit []
<oliv3r>
ok wiki page has been exapnded
<panda84kde>
BTW I see SATA is not listed for A20, but it's supported. Can I update the main page?
<oliv3r>
there's more counters too, each CPU has its own counter hooked up to the 24M and 32k oscillators
<oliv3r>
a20 manual even has a nice clock tree diagram :)
rellla has quit [Ping timeout: 256 seconds]
mcbrick has quit [Quit: Leaving]
hipboi has quit [Quit: Leaving]
<oliv3r>
i'm telling you, HDMI1 'block' is cec etc, it's probably some microcontroller-like thing that handles CEC and network (i doubt they do networking even though that's in the 1.4 spec)
<arokux1>
oliv3r, can I put a reference to it on the wiki page?
<oliv3r>
Turl: 16 kiB SRAM is split for TX and RX; 3k is for TX, 13k is for RX
<oliv3r>
arokux1: sure :)
<oliv3r>
but it might get decrypted so name might change
<oliv3r>
i'd link to the dl.linux-sunxi.org/A20 generally
<arokux1>
oliv3r, wow, 835 pages. a gift from allwinner?
<oliv3r>
a little bit of emac info, we never had that either, so i really think emac AND gmac IP cores are available
<oliv3r>
arokux1: a10/a13 manuals are bigger :)
<oliv3r>
i lie
<Turl>
oliv3r: no, they're half the size :p
<arokux1>
a10 is much smaller
<arokux1>
if they were half......
<oliv3r>
Turl: the manual says 3k tx; 13k rx; but i wouldn't be supprised you can do it anyway you want
<oliv3r>
arokux1: it is half
<oliv3r>
Turl: ohh the manual
<oliv3r>
Turl: sram! sram! stay on topic
<Turl>
arokux1: 495 for A10 & 409 for A13
<Turl>
oliv3r: what about it? :P we have known that for some time right?
<oliv3r>
which means, a20 can use either/or driver with either/or PHY and thus the emac bugs can be ignored :)
<oliv3r>
Turl: you said sram was for rx only
<Turl>
oliv3r: eh?
<oliv3r>
a few days ago
<oliv3r>
when you where playing with the sram driver
marzubus has joined #linux-sunxi
<Turl>
I can copy code just fine so you can "tx" too :p
<arokux1>
Turl, oliv3r you are right, sorry, I've used data sheet so far!
<oliv3r>
16k jumbo frames support on the gmac
<Turl>
oliv3r: ah, I think you're confusing what I said
<oliv3r>
doesn't say if its connected to sram at all
<Turl>
oliv3r: I was talking about emac, and said dma was used for tx only on the driver we have
<oliv3r>
ohhh possible
<oliv3r>
zero register information on gmac driver
<oliv3r>
:(
<arokux1>
stupid me :(
<oliv3r>
gotta find out which IP they are using
<arokux1>
oliv3r, are the docs a gift from allwinner?
<oliv3r>
but we have sun6i gmac driver :)
<oliv3r>
arokux1: leaked
<arokux1>
oliv3r, :)
<oliv3r>
so dunno how much they are gifted; though a20 manual is via hipboi
<arokux1>
oliv3r, thanks a lot for this pointer. I had only a fraction of this info!
<oliv3r>
woprr: great, i see in the a20 manual that transport stream control and status registers are ... empty.
<oliv3r>
the control register has 2 bits atleast described in the cubieboard a10 doc
<arokux1>
oliv3r, question: is dropping of the code welcomed in sunxi-4.0 if it is unused, or it should stay there just in case it could be useful later?
<oliv3r>
sunxi-3.0 will be depreciated hopefulyl soon
<oliv3r>
hno we have SOME can bus info now too
deasy has joined #linux-sunxi
<oliv3r>
Turl: omg they got their own glassary wrong
<oliv3r>
afaik, AVS for allwiner, is the Audio Video Sync timer
<oliv3r>
they call it 'Audio Video Standard, a compression standard for digital audio and video'
<oliv3r>
lolol
<woprr>
oliv3r, ack
<oliv3r>
ssvb: nice, DEFE contains a de-interlacer
<ssvb>
oliv3r: good :)
<oliv3r>
ssvb: can you use that as a seperate thing?
<oliv3r>
i mean, can I decode some video, have the DEFE de-interlace it?
<oliv3r>
or is it for the enitre output stage
<oliv3r>
e.g. can I deinterlace a single layer
<oliv3r>
it looks like it can take whatever is on the memory bus (mbus) and deinterlace it and offer it to the DEBE
<ssvb>
oliv3r: we are reading the same docs, I guess the writeback feature should allow to do this without sending anything to the display if you mean that
<oliv3r>
ssvb: you reading a20 aswell? :)
<ssvb>
oliv3r: not yet, just remember this from the a13 manual
<oliv3r>
ssvb: well i'm just curious, a lot of braodcast material is still interlaced (god knows) and doing it in software is almost impossible on a10/20
<oliv3r>
i know my htpc has real trouble with most methods
<oliv3r>
so i wanna know if we can offload it
deasy has quit [Ping timeout: 245 seconds]
<oliv3r>
ohhh yes, you can read from memory, make it go through the scaler, the vpp, the csc and then either output it back to memory OR to the DEBE
<ssvb>
oliv3r: the output of cedar is also tiled, which may make it more difficult for post-processing, that's why I looked into it a bit
<ssvb>
oliv3r: having a feature complete vdpau would be nice
<oliv3r>
that's what i'm thinking ;)
<oliv3r>
so while i'm not sure on all the lingo and all possible methods
<oliv3r>
if cedar is tiled, how is that a big problem? won't we have a full frame in memory at some point?
<oliv3r>
and can't we thus de-interlace the full frame?
eebrah|away is now known as eebrah
<oliv3r>
also i always thought the front-end would be the output bits but i see now that its the other way around, the 'backend' is what gets sent to display eventually
<ssvb>
oliv3r: if the output is tiled in memory (32x32 blocks), then it's difficult to do anything with it using g2d
<oliv3r>
ah, so we don't have full frames in memory?
<oliv3r>
ever?
<oliv3r>
anyway, i don't even think we need the write back channel for that
<oliv3r>
the DEFE has an 'output select' which either goes to DEBE OR back to memory
<oliv3r>
(from the block diagram)
<ssvb>
oliv3r: as far as I know, g2d does not support tiled formats natively, this makes it a bit tricky
<oliv3r>
thats stupid :S
<oliv3r>
ok we'll see when we reach that bridge
<ssvb>
oliv3r: we have full frames in memory, but the pixels are just rearranged a bit
<oliv3r>
spent 3 hours going over the manual :) forgot to do tons of stuff now
<ssvb>
oliv3r: it's probably not stupid if g2d is a third-party IP :)
<oliv3r>
ssvb: now, is that upto cedarX the lib, or cedarX the IP
<oliv3r>
e.g. is it fixable in any way?
<ssvb>
oliv3r: defe supports tiled formats as input, cedarx produces tiled format as output, at least there is no problem when these two are working together
<oliv3r>
well for de-interlacing, we don't need debe
<oliv3r>
only defe, as it can put it back into memory
<oliv3r>
i don't know how tiled deinterlacing affects image quality
<oliv3r>
don't think it should be too bad
fredy has quit [Excess Flood]
tinti has joined #linux-sunxi
fredy has joined #linux-sunxi
<ssvb>
libv: ping
<libv>
ssvb: what's up?
<ssvb>
libv: I have pushed dri2 tear free double buffering support
<libv>
ok
<ssvb>
also now it speaks the mali dri2 dialect, which may be incompatible with your lima code
<libv>
right...
<libv>
i already need to tell it to load the lima dri driver
<libv>
i might try it out on my mele, which is currently geared for framebuffer mali binary, whereas my a7hd and odroid are geared for mesa bringup
<ssvb>
I'll try to document all this stuff, just to make it clear how it works
<ssvb>
one of the problems is that the normal xorg dri2 framework and the mali blob don't quite understand each other and this used to cause some issues
<libv>
right
<libv>
it's good that you're doing this work, and it might mean that X11 mali support finally gets somewhat acceptable
<ssvb>
yes, a lot of people showed recently asking about Qt5, that's why this stuff had to be revisited
<ssvb>
now Qt5 should work fine in X, though the framebuffer size has to be increased to allow it use double buffering
<ssvb>
there needs to be enough space for two dri2 buffers in the offscreen area
<panda84kde>
libv: here I am. I'll report to you if A20 works as A10 does as soon as I get my olinuxino A20. BTW, have you got any A20 board incoming?
<libv>
no, but i do not intend to work on a20, i have a mali400mp4 which is fully supported by limare. mali400mp2 will just work
rellla has quit [Ping timeout: 268 seconds]
<libv>
ssvb: i see
<libv>
ssvb: so now you can properly provide a qt5 cinematic experience which beats the libhybris hack hands down?
<ssvb>
libv: almost, we need triple buffering to clearly beat it
<ssvb>
libv: with just double buffering, we are limited to 30fps
<ssvb>
libv: (for 1280x720 fullscreen mode)
<libv>
oh, why is that?
rellla has joined #linux-sunxi
<panda84kde>
libv: oh, nice. Is lima driver still very experimental or is it somehow testable for the brave?
<libv>
is it that heavy an application?
<libv>
that it cannot render a frame between vsync being reported and the new frame address taking effect?
<ssvb>
libv: we have to wait until scanout switches to the next buffer before starting rendering to a new one
<ssvb>
libv: *rendering to the old one
<libv>
right
<libv>
panda84kde: there is only limare, not lima driver.
<ssvb>
libv: so it's ~50fps without vsync, and 30fps (one update per two frames) with vsync
<ssvb>
libv: triple buffering (or even use more buffers) should help because we don't need to wait
<libv>
ah, right, it cannot reach 60fps as is
<ssvb>
libv: there is only one major inconvenience with triple buffering - we would need to suppress the crazy console spam from the mali blob
<panda84kde>
libv: sorry, what do you mean by that? that only limare is testable?
<arokux1>
oliv3r, question: is dropping of the code welcomed in sunxi-4.0 if it is unused, or should it stay there just in case?
<libv>
ssvb: console spam?
<ssvb>
libv: redirecting it to /dev/null kinda helps, but the end users are not going to appreciate this
<ssvb>
libv: the "[EGL-X11] [2274] DETECTED ONLY ONE FRAMEBUFFER - FORCING A RESIZE" bla bla
<oliv3r>
libv didn't you sign up for a cubieboard a20 a while back?
<libv>
panda84kde: like pretty much everyone else who has been asking questions like you have since you joined, you have not been willing to understand that there is not a proper driver yet, and that this is the reason why you have not found any solid information on a proper driver so far
<libv>
oliv3r: i should be focussing on lima, not on disp stuff or bringing up and hacking sunxi-mali
<libv>
so getting an a20 will be a distraction
<arokux1>
oliv3r, are you going to buy a bunch of cubieboards2?
<oliv3r>
arokux1: there is no sunxi-4.0 so not sure what you mean; there's no 4.0 kernel
<oliv3r>
arokux1: i got 1 dev board
<libv>
so it is better to let someone else get one of the community cubieboards
<oliv3r>
libv: nono, lima is good enough ;)
<oliv3r>
but having an mp2 would be 'nice to have' no? :) for testing
<oliv3r>
libv: ah i thoguht you signed up and got a dev board from tom
<panda84kde>
libv: I'll update linux-sunxi wiki, so that becomes clear. This doesn't tell me "there's no driver": http://linux-sunxi.org/Mali400#Lima_driver_.28Open_Source.29
<oliv3r>
no problem then
<oliv3r>
*goes back hacking*
<libv>
panda84kde: "This is a work in progress and not yet ready for general use."
<libv>
panda84kde: seems good enough, for those who wish to read and grasp that sort of information
<libv>
oliv3r: i told cwabbott to get one, not sure whether he actually did ask for one or not
<ssvb>
panda84kde: are you one of the "I want to use Qt5" folks?
<panda84kde>
libv: infact I've asked (kindly) "Is lima driver still very experimental or is it somehow testable for the brave?" 'For the brave' is pretty different from 'not for general use'. However I don't want to waste your time anymore. Have a nice day and good job!
<marzubus>
Hey! so I got my kernel compiled for the MK802 with arduino and webcam support! finally! rover is looking much more complete now: http://tinypic.com/r/znq3bs/5
<ssvb>
panda84kde: you can compile and run lima demo applications and use the mali hardware, it's just not a fully compliant OpenGL ES driver yet
<ssvb>
panda84kde: err, I mean not you, but the "brave ones" :)
<libv>
panda84kde: sorry to burst your bubble like this, but i see your line of thinking/asking questions quite often, and i saw you coming a mile away.
<panda84kde>
ssvb: nope. I'm not. I just wanted to help in testing with A20, but only if that's something you're interested into. If that's too early just ping when I can help you.
<ssvb>
panda84kde: ok, sorry, I thought that you wanted to use Mali on A20 (possibly with the binary drivers) for something practical
<ssvb>
panda84kde: but even if you are only interested in lima, the first step anyway would be to resolve the issues with the mali kernel driver
<oliv3r>
libv: i do hope he did
<oliv3r>
was a simple form to fill in :S
* ssvb
is waiting for the dust to settle and a workable 3.4 kernel on A20 :)
<ssvb>
libv: btw, there is no dri2 support code in the lima repository yet?
<oliv3r>
arokux1: what do you wish to drop from that? If you refine the usb driver, you basically replace it :)
hipboi has quit [Ping timeout: 264 seconds]
<libv>
ssvb: nope
<arokux1>
oliv3r, not much yet, some unused defines etc.
<libv>
ssvb: fbdev has been suiting me quite well for limare
<oliv3r>
arokux1: if you wish to improve usb hci on sunxi-3.4 just hack/add the files you want and send a patch to the ML when the time is ripe :)
<panda84kde>
ssvb: Well. First of all I promise I'm not interested in Qt5 on Mali. :) Second: yes, I understood that lima driver (or "will be lima driver") is not usable, but if I can help with testing (I'm neither a total noob, nor a kernel hacker). Third: yes, I asked if anybody used the binary driver on the A20. As far as I can understand from sources on the internet Mali binary driver can run glmark2-es2. If that's not a question to
<panda84kde>
ask here I'll just shut up.
<libv>
ssvb: besides, i still haven't found out how to tell the windowsystem or dri2 that rendering is done, i know i get told by dri2 to flush rendering in mesa
<arokux1>
oliv3r, ok, thanks
<libv>
but then the return of this flush seems to trigger xcb copy region or a swapbuffers
<ssvb>
libv: I believe it should know automatically that the rendering is done when you swap buffers
<libv>
so i have to explicitly wait on the rendering being complete
<libv>
ssvb: as just said, the only point where i get told to flush out the render, is also the point after which the buffer is displayed
<libv>
i haven't understood how the intel driver would do this any better
<ssvb>
is there any problem with the buffer being displayed?
<libv>
driver->dri2_flush(); xcb_copy_region is the code i am seeing
<libv>
no, but it enforces strict ordering
<libv>
and completely beats the way the mali is built
<libv>
i have a whole load of threaded code for handling job returns in limare
<libv>
you build up a render, and then tell this threaded code to finalize it and then throw it to the kernel
<libv>
as soon as the job is handed over the to jobhandling code, the main thread can continue and start building up the next frame
<libv>
when the job returns, the fbdev driver gets told to flip, by one of the job handling threads
<libv>
i see no possibility of doing something similar with X/dri2/mesa
<ssvb>
r3p2 submits back buffer request for each buffer
<ssvb>
buffer requests and buffer swaps may run out of order to some extent
eebrah is now known as eebrah|away
<libv>
as i would need to be notified that the frame is complete, and i would need a means of telling the windowing system that rendering has completed and that the buffer content is valid
<libv>
and all i have is dri2_flush, which is both of the above in one, which is severely suboptimal
<ssvb>
when the buffer content is valid. you do swap (at least in the "mali dialect of dri2")
<libv>
but perhaps i missed something, mesa is not the most transparent codebases
<ssvb>
when you want to render a new frame, you do dri2 back buffer request
<ssvb>
that said, mali looks rather broken, so this may be not correct for any other drivers
<libv>
ssvb: when you want to start building up the rendering of a new frame, or when you want to finalize the frame you just built up and want to send it off to the hw?
<libv>
"render a new frame" is not precise enough in this context :)
<ssvb>
I'll just try to write something in a wiki page, and then we can discuss it again a bit later :)
<libv>
ok
rellla has quit [Ping timeout: 264 seconds]
hipboi has joined #linux-sunxi
<oliv3r>
hipboi: hey, can you confirm/deny whether eth and uart2 are somehow linked other then pinmuxing?
<oliv3r>
hipboi: e.g. if you configure pa as ethernet, can you still use UART2 via PI? (Uart1 doesn't have an alternative mux, so you loose that)
<arokux1>
oliv3r, any idea why virtual addresses are defined and not used afterwards? (SW_VA_SRAM_BASE etc.)
<ssvb>
panda84kde: the binary driver works on A10 and can run glmark2-es2, A20 is expected to be also fine after the mali kernel driver gets taken care of
<oliv3r>
arokux1: because allwinner code is horribly sloppy?
<arokux1>
oliv3r, :) when those VA become "active" anyway.. from user space?
<oliv3r>
i don't know how the AW code 'works' but it's a big mess, so don't read to much into it
<ssvb>
panda84kde: some people tried to compile the mali kernel driver for A20, but looks like they don't have what it takes to do this job properly
bsdfox_ has joined #linux-sunxi
bsdfox_ has quit [Changing host]
bsdfox_ has joined #linux-sunxi
CaCtus491 has quit [Ping timeout: 245 seconds]
rellla has joined #linux-sunxi
<panda84kde>
ssvb: Thanks. That clears out what I was look for. So if I got it right A10 has the mali and ump kernel module in the https://github.com/linux-sunxi/linux-sunxi sunxi-3.4 brach, while there's not for A20
<panda84kde>
*looking for
CaCtus491 has joined #linux-sunxi
<ssvb>
panda84kde: yes, the sunxi-3.4 branch is evolving to get complete A20 support at the moment, we are just not there yet
<panda84kde>
ssvb: that's because Allwinner released a A20 Android kernel, and not a Linux one? Is the original drop in another branch of the same repository?
<ssvb>
panda84kde: there is also 3.3 kernel from allwinner, with something resembling the mali kernel driver in it, but the ones who tried could not make it work so far
<ssvb>
panda84kde: for the start, we want r3p0 kernel driver to match the version of the available userland mali blob
<hno>
panda84kde, Allwinner 3.3 kernel will work with mali blobs delivered in the same Android SDK. Not sure if there is Linux MALI blobs available for that kernel.
<ssvb>
panda84kde: the sunxi-3.4 branch already has the mali kernel driver, it just needs to be updated to do correct initialization of mali resources for a20
<oliv3r>
who is tekkaman ninja and how is that not hansg's work?
<oliv3r>
Tsvetan: android version 4.2.2
<Tsvetan>
Allwinner promised to send me SDK 2.0 for A20
<Tsvetan>
but I dont know which android version is inside
<oliv3r>
i'm downloading righ tnow, but its ays 9h togo
<oliv3r>
it's about 5G
<Tsvetan>
I open the link seems this is SDK 1.03
<Tsvetan>
what we got first was 1.0
<wingrime>
Tsvetan: where
<Tsvetan>
wingrime where what?
<wingrime>
Tsvetan: link
<hno>
wingrime, see above.
<wingrime>
Tsvetan: I intersted with ACE binaries
<Tsvetan>
ACE?
<wingrime>
Tsvetan: seems we have undocumented ac3 and dts audio hw decoder
<wingrime>
Tsvetan: audio hw decoder
<wingrime>
Tsvetan: on a20
<wingrime>
Tsvetan: I saw only old blobs for sun3i
<Tsvetan>
I will ask rz2k to replace the current A20-SDK 1.0 torrnent with A20-SDK 2.0 as soon as I get it from Allwinner
<Tsvetan>
but this will probably happend after 18/08 as we leave in vacation
<Tsvetan>
and the DVD will come in our office while we are on vacation
deasy has joined #linux-sunxi
<wingrime>
Tsvetan: DVD over mail?
<Tsvetan>
DHL
<wingrime>
why not use ftps
<wingrime>
oliv3r: ^
<Tsvetan>
downloading from ftp in China takes longer than DHL
<wingrime>
Tsvetan: android build system have "repo" tool witch enable use many sources for download, using many git repos
<wingrime>
Tsvetan: better get google stuff form google git
<wingrime>
Tsvetan: overlay must not be big
<deasy>
Turl, usually it's my trollometer who explodes on the web
<Tsvetan>
wingrime android is not our focus, I get these SDKs just to give to you guys so you can see if there is something valuable which could be used in linux-sunxi
<wingrime>
Tsvetan: thanks
<wingrime>
hno: bootloader sources constained something valuable that we don't know?
<hno>
Tsvetan, any plans on shipping devices with Debian/Fedora instead of Android preinstalled?
<hno>
wingrime, yes.
<hno>
well, haven't looked at this release. Only the 1.0 release.
<Tsvetan>
hno do we have GPL NAND packer?
<wingrime>
hno: for example
<hno>
Tsvetan, yes, but untested.
<Tsvetan>
cool
<hno>
Or, no, not the packer. But we do have the driver.
<Tsvetan>
when we made the NAND images with Linux
<Tsvetan>
everything packs fine
<hno>
and Linux tools for packing.
<Tsvetan>
but then there is no free space in the NAND
<Tsvetan>
so you cant install anything new with apt-get
<Tsvetan>
which makes this image useless
<Tsvetan>
as to add something you have to generate new pack
<Tsvetan>
for each new install you want to do
<hno>
Tsvetan, how big did the rootfs get?
<Tsvetan>
if we have Linux which can boot from NAND like from the SD-card we will start shiping with Linux on NAND
<Tsvetan>
I dont remember
<Tsvetan>
but the images are less 2G
<Tsvetan>
so there is at least 2G free
<hno>
images are compressed and mangled...
<Tsvetan>
but when we flash the image with livesuit the NAND is always full after it
<Tsvetan>
and no space for anything else to be add
<Tsvetan>
we didnt dig too much anyway
<hno>
wingrime, for example what?
<Tsvetan>
in this direction
<hno>
Tsvetan, ok.
<wingrime>
hno: something intersting in bootloader drop
<Tsvetan>
hno keep me in the loop if Linux on NAND is working we will immediately replace Android with Debian on the boards with NAND flash
<hno>
wingrime, yes, many explanations to how the Allwinner bootloader is borked, and some more details on the A20 SDRAM controller.
<wingrime>
hno: nice, also driver, are you about nfc driver?
<hno>
the AW team working on the bootloader clearly needs a bit more time to test their changes.
<hno>
wingrime, nfc? nand?
<hno>
nfc is something else entirely..
<wingrime>
hno: Nand Flash Controller
<hno>
I have the AW GPL released A20 sources for the Nand driver for both u-boot and kernel.
<hno>
think both have been pushed to my github.
rellla has quit [Ping timeout: 264 seconds]
<hno>
have not had time to look further into the nand controller, but at least the controller version in A10/A13 is relatively well understood now.
<hno>
just lacking time to implement.
<wingrime>
hno: it need also cache and ramdomization level to code
<wingrime>
hno: but I prefer use kernel frameworks for it
<wingrime>
sigh... ext4 need block device , not mtd
<ssvb>
libv: that's a preliminary draft, but I will try to clarify it
<ssvb>
libv: to me it does not looks like a correct dri2, but we just need to convince the blob to behave the way we want in order to get non-broken buffer swaps
deasy has joined #linux-sunxi
techn_ has joined #linux-sunxi
FR^2 has quit [Quit: Connection reset by peer]
panda84kde has quit [Quit: Konversation terminated!]
leowt has joined #linux-sunxi
nove has joined #linux-sunxi
<wingrime>
mripard_: ping
CaCtus491 has quit [Ping timeout: 264 seconds]
CaCtus491 has joined #linux-sunxi
<leowt>
anyone here familiar with the sunxi nand driver ?
n01 has joined #linux-sunxi
<wingrime>
Turl: ping
<Turl>
wingrime: pong
<wingrime>
Turl: I can't set clock rate in mainline for ir
<wingrime>
Turl: clk_set_rate return -22
<Turl>
wingrime: on what clock?
<wingrime>
Turl: APB0->IR0
<wingrime>
it must be 3 MHz
<Turl>
22 is invalid value
<Turl>
wingrime: the apb0 clock is just a gate isn't it?
<wingrime>
yes
<Turl>
wingrime: you need to set the rate on the other ir clock
<wingrime>
but I need apb_ir0
<Turl>
wingrime: yes but apb_ir0 doesn't need to change rate
<wingrime>
Turl: why?
<wingrime>
Turl: I need set apb_ir0 to 3Mhz like original driver do
<Turl>
wingrime: I doubt original driver does that
<wingrime>
Turl: do
<Turl>
wingrime: see "[PATCH RFC 8/8] ARM: sun4i: mod0 clocks", I think you are looking for ir0 clock there
<arokux>
Turl, let me please ask some basic question. those PLLs are configurable clocks. and depending on the devices you connect to the SoC you configure PLLs to output some frequency. is that right?
<Turl>
arokux: yes, kind of for the most part
<Turl>
arokux: except the devices are inside the SoC :P
<arokux>
Turl, :)
<arokux>
Turl, what will happen with your patch?
<Turl>
arokux: mali and sata feed off the same pll from what I recall, we had issues with that in the past
<Turl>
arokux: I need to complete it a bit, mostly checking docs and writing dt bindings for A10S/A13
<Turl>
and clean some stuff
<Turl>
but I didn't get any major complain on the code so far so it should be ok for merging for the most part
<arokux>
Turl, is there any tree which incorporates all *mostly* reviewed patches?
mcbrick has quit [Remote host closed the connection]
mcbrick has joined #linux-sunxi
<wingrime>
Turl: question how do it with dt
<wingrime>
oh
<arokux>
wingrime, where are you from?
<wingrime>
arokux: russia
<xenoxaos>
speaking of where you're from....random question....anyone from austin, tx?
* xenoxaos
is moving and needs friends
<jelly-home>
to help you move? :-)
<arokux>
what lends in stage/sunxi-3.4? something that will soon come to sunxi-3.4?
<mnemoc>
yes, after some cleanup
<mnemoc>
then a tag, and a jump to the next 3.4.y
<mnemoc>
and a new stage spawned
<ssvb>
mnemoc: what would be the next 3.4.y?
<mnemoc>
3.4.55 iirc
<ssvb>
ok
<mnemoc>
unless there is something against that $y
<libv>
ssvb: if i read your explanation correctly, you are using dri2 copyregion?
<ssvb>
libv: yes
<libv>
the way this one works from the mesa side is that the handler for this first calls the drivers' dri2flush handler, and then this mesa handler calls xcb_copyregion
<libv>
dri2flush is where the render is sent off to the hw
<libv>
and it takes a while for such a thing to return, and i believe that the lot is stalled then, but i am not sure
<ssvb>
I tried to use ScheduleSwap, but it was just adding extra complexity for no good (with the mali binary driver)
<libv>
ok
<Turl>
wingrime: look at how it is done for emac
<ssvb>
libv: but the mali drivers are just weird, too much voodoo magic is need to make them work
<libv>
maybe that is the way to make this less serial
<libv>
we can try to fix this massive slowdown when something is halfway working on my side
<ssvb>
but how do you do it with the framebuffer?
<libv>
i schedule a job, and then the fully threaded job handling runs through the motions and waits for the fragment shader to return, and flips when it does.
<libv>
once i have sent off the job, i can continue building up frames
woprr has joined #linux-sunxi
<libv>
the flip is tied to the return of the fragment shader job, and i do not have to wait in the main thread for it to return and then manually do the flip
<ssvb>
but it does not seem to be very different from dri2
<ssvb>
can you do DRI2SwapBuffers from this thread?
jemk has quit [Remote host closed the connection]
<ssvb>
even with the framebuffer, flip does not happen instantly after the ioctl call returns
Black_Horseman has joined #linux-sunxi
<libv>
the latter is irrelevant, as long as i can continue to build up the next frame without being blocked on the kernel returning
<libv>
dri2swapbuffers is something that is done for me.
<ssvb>
it may be relevant if you don't want to start writing something to the old buffer which is still visible on screen
<libv>
ssvb: this buffer address is fed in right before the fragment job is sent off to the kernel
<libv>
the thing is, i can only send off the _vertex_ job to the kernel when i receive the flush
<wingrime>
function: ir0, groups = [ PB3 PB4 ]
<libv>
i am beating the mali framebuffer driver because i am able to schedule just as aggressively as it does
<wingrime>
Turl: pinmux-functions show "current selected" function?
<oliv3r>
wingrime: pong
<libv>
with what i am using in mesa now, it's going to be a dog
<wingrime>
Turl: or simply avl
<Turl>
wingrime: did not understand your question
<Turl>
what is avl?
<wingrime>
avaliable
<ssvb>
libv: in any case, the mali blob seems to be also threaded (DRI2GetBuffers and DRI2SwapBuffers may be called out of order relative to each other)
<oliv3r>
wingrime: limited bandwith? :)
<Turl>
wingrime: you mean the .h file?
<wingrime>
oliv3r: linux-sunxi IR driver decode NEC protocl by own and use private keymap
<wingrime>
Turl: no, I about debugfs entry
<libv>
ssvb: there seems little way around that imho
<wingrime>
Turl: how I can get current selected gpio function
<libv>
somewhere between gettig the buffer location and layout, and telling the windowing system that the buffer is filled properly, some rendering needs to take place
<wingrime>
using debugfs
<Turl>
wingrime: I don't know, never used pinctrl debugfs
<ssvb>
libv: what if you just request a bunch of buffers via DRI2GetBuffers beforehand and then do DRI2SwapBuffers as the results are ready?
<wingrime>
Turl: I only added pins function to DT
<ssvb>
libv: with many buffers you can really deeply pipeline it without any need to wait for anything
<wingrime>
Turl: emac driver have no any interactions with gpio
<libv>
let's see...
<Turl>
wingrime: emac driver has pinctrl code, look for it
<Turl>
or maybe it is on mdio part
<oliv3r>
Tsvetan: yeah mtd driver should make live beautiful for default images ;)
<ssvb>
libv: the mali style dri2 implementation is a dead end because it is doing stuff in a non-orthodox way (and I'm moving xf86-video-sunxifb in this "wrong" direction)
<ssvb>
libv: it would be interesting to trace the real intel driver
<Turl>
wingrime: I don't think it is 0x34
<oliv3r>
wingrime: i'm almost done unifiying and cleaning it up
<oliv3r>
wingrime: but yeah, sunxi-ir does NEC the hardway
<oliv3r>
so doing a proper kernel driver == win
<wingrime>
Turl: its from oringial driver
<Turl>
wingrime: must be sun3i address
<Turl>
wingrime: correct one is 0xb0
<ssvb>
libv: I have an atom n450 here, maybe it makes sense to give it a try (if this hardware even has some opengl support)
<Turl>
1<<31 on, 0<<24 source 24M, 3<<16 for divisor
<Turl>
wingrime: ^
<ssvb>
libv: but other than the peformance of the buffers handling, is integration of lima into mesa going well?
<ssvb>
libv: it's just that there was this buffers size mismatch bug on window resize in r3p0 and I did not know a usable workaround for it
<wingrime>
oliv3r: it means 100%
<wingrime>
oliv3r: minor changes
<Turl>
arokux: I'm working on clocks, so I don't need i2c or clocksource patches
<oliv3r>
wingrime: yeah it's nearly identical
<arokux>
Turl, I see. I mean who knows what the mripard is doing, but you seem to know it :)
<ssvb>
libv: and there was some hope for maybe mali r3p2 upgrade, which kinda negatively affected the motivation trying to make something usable out of r3p0 :)
<wingrime>
oliv3r: it more stange
<ssvb>
libv: but now it looks like r3p0 can also make it
<wingrime>
oliv3r: uart IP can work in IrDA mode
<wingrime>
oliv3r: so IR mostly useless
<oliv3r>
uart IP? what makes you say that?
<oliv3r>
i wouldn't be supprised if it's somehow related
<oliv3r>
irda and uart are very much alike
<wingrime>
19.4.9. UART Modem Control Register
<wingrime>
1: IrDA SIR Mode enabled
<Turl>
arokux: well, if we didn't know what each one of us is doing it'd be pretty confusing and messed up :p
<wingrime>
oliv3r: witch means IR mostly useless
<Turl>
oliv3r: sid! :p
<wingrime>
oliv3r: as can be on gpio
<Turl>
wingrime: IR can do CIR maybe?
<wingrime>
oliv3r: yes , i think
<wingrime>
MIR and CIR
<arokux>
Turl, then send you patches to linux-sunxi ML too :P