<oliv3r>
wens: i'll pull and test that later today
_massi_ has joined #linux-sunxi
<oliv3r>
mnemoc: forget cflow; doxygen should be able to do call_graph and caller_graph
<mnemoc>
:)
<mnemoc>
btw, git. is working now
<oliv3r>
cool
<oliv3r>
and cgit too?
bsdfox has joined #linux-sunxi
<oliv3r>
lxr?
<oliv3r>
i think since lxr requires a checked out tree per thing (doesn' tit?) we can integrate doxygen ontop of that for the graphs
<mnemoc>
not sure how to integrate that yet as it assumes release
<mnemoc>
we want heads
<oliv3r>
maxima.linux-sunxi.org is broken? :p
<mnemoc>
i was actually pondering about writting my own the browser/explorer using luagit2
<mnemoc>
yes. will revive it tonight once fixing the php issue
<wens>
wens
<wens>
oops
<oliv3r>
mnemoc: okay no prob :)
<n01>
oliv3r: how big is the uboot SPL?
<oliv3r>
right now? 23k i think; out of th eallowed 24k
<oliv3r>
n01: why?
<n01>
oliv3r: to have an idea. I have to implement an SPL for another board < 28k
<oliv3r>
ah ok you should have plenty of room then
<oliv3r>
:)
<n01>
hopefully :)
notmart has joined #linux-sunxi
ijc has quit [Excess Flood]
ijc has joined #linux-sunxi
ijc has left #linux-sunxi [#linux-sunxi]
<libv>
gah, vga detect on mele does work... now to find which bits make it work reliably
enrico_ has joined #linux-sunxi
<oliv3r>
libv: did you here from mele about the i2c port? or did you finally find it?
<atiti>
hey guys
<libv>
oliv3r: nothing from mele
<libv>
oliv3r: tom gave me a link to an allwinner reference design
<atiti>
i have a question, I got vdpau working, and the playback is definitely hardware accelerated, I'm using fbdev for X11 though and theres pretty bad tearing
<libv>
oliv3r: and the wires are just floating
<atiti>
should I be using the fbturbo driver?
<libv>
oliv3r: just like they are on the cubieboard expansions boards :(
rellla has joined #linux-sunxi
<libv>
but at least it seems possible to do load detection
<libv>
so now i am off for the next few h trying to reduce the bits to make that work reliably (as i was apparently unable to do so before)
<libv>
i think it might be the DAC2 register, and then setting it to 75Ohms, but it could be more.
<libv>
in any case, when the sunxi disp driver is told to do VGA, you get no load detection
<oliv3r>
libv: really? that is shit :(
<libv>
oliv3r: yeah
<oliv3r>
libv: why would they leave it just floating?
<libv>
oliv3r: because they are chinese and they often don't know any better?
<libv>
cubietruck is much better though
<libv>
but i haven't gotten that far yet :)
<oliv3r>
:)
<libv>
hdmi was easy to bring up btw, as soon as i figured out which bits needed to be set so that the hdmi specific i2c regs could be read
<libv>
if the register space for hdmi was enabled, but the hdmi engine wasn't specifically enabled, and you'd read from the i2c regs, you'd hardlock the a10
<oliv3r>
i know wingrime was trying to get hdmi working, don't know if he ever managed to get it to do so
<oliv3r>
(in u-boot)
<libv>
hwc works, planes work
<oliv3r>
that's actually an interesting bug, nasty too
<libv>
i'm really rather happy to find that load detection can work though
<libv>
this means that we can at least provide a random board with a working vga display, albeit at 640x480 or 1024x768
<libv>
better than nothing
<libv>
oliv3r: this display engine really is rather wellbehaved
ssvb has quit [*.net *.split]
<libv>
oliv3r: for all the overlays, i can throw them wherever i want, they do not have to be visible at all
<libv>
i had a tool left over from some intel work, it throws a 1024x576 tv test image at a kms plane and then moves it around a bit
<libv>
it exposes just how horribly the intel driver is implemented
<oliv3r>
hehe
<libv>
with sunxi, you can pretty much toss it anywhere
<libv>
but...
ssvb has joined #linux-sunxi
<libv>
even negative positions, which is rare for overlays
<libv>
offscreen is also just fine
<libv>
until i set the position to 7168x7616
<libv>
then the overlay would appear on screen again, together with some weird repeats
<libv>
now add that position to the size of the overlay, and you get 8192x8192 :)
<libv>
it's a bug, but such a nice one to work around :)
<libv>
and as long as you use 4k displays and 4k overlays, you should not hit it
<libv>
really well behaved display engine this
<libv>
sadly though, they skimped on some bits...
<libv>
encoders are not muxed
<libv>
afaict, hdmi can only live off the primary
<libv>
and the same will be true for the lcd lines
<libv>
and i need to go figure out how to get h/vblank signals out of the secondary on to the vga connector
AreaScout has quit []
<libv>
as otherwise vga also needs to live on the primary, making the secondary display "pipe" useless for anything but composite
<oliv3r>
cool though that you can get that to work
<notmart>
I have a new fex to add to https://github.com/linux-sunxi/sunxi-boards (eoma68-a20) .. i made a pull request on github, is it enough or should i do something else?
<ssvb>
oliv3r: yeah, everyone suddenly got interested in mainlining disp or its replacement :)
<ssvb>
I guess everything should be working nicely pretty soon
<oliv3r>
ssvb: aye, disp being one of the bigger most extravagant things
<libv>
this one is quite well behaved
Azq2 has joined #linux-sunxi
<ssvb>
oliv3r: we don't even need all the current features of disp, a certain subset is good enough
<libv>
not as nice as the original ati R500
<libv>
but not as horrible as any of the vga extension jobs i have had to deal with
<libv>
r500 had proper encoder muxing though, and was a lot more complicated to set up
<ssvb>
libv: have you tried to use defe for scaling?
<libv>
PLL was also finicky on some r600 versions
<libv>
ssvb: i have taken it out of the equation for now, why?
<libv>
ssvb: it will be necessary for proper cedar integration and video playback, but that can be added afterwards
<ssvb>
libv: it may perhaps add some hw bugs
<libv>
and you cannot properly represent things in kmess anyway
<libv>
ssvb: de_fe has less bugs than de_be has
<libv>
powering up de_be is pretty shaky
<ssvb>
about the kms, this sounds not very promising
<libv>
ssvb: well, kms just is a bad ripoff of randr1.2
<ssvb>
custom ioctls to the rescue?
<libv>
ssvb: and randr1.2 is just a bad ripoff of my ideas, which were implemented by people who had never done any driver development before
<ssvb>
:)
<libv>
kms was some idiot who never did any driver development before who threw some of randr1.2 into a headerfile
<libv>
kms = driver development idiocy ^ 2
panda84kde has joined #linux-sunxi
<libv>
and none of the few additions or fixes made it any better.
<libv>
i would like to know why people like kms so much
rz2k has joined #linux-sunxi
<libv>
and i think it would boil down to "splitting up this huge mess of display engine into workable blocks and connecting them is just the way to do it"
<libv>
ssvb: yeah, i assumed as much, my statements were totally unrelated though
<ssvb>
ok
<ssvb>
sorry, I got it wrong again
<libv>
luckily the script.bin gives some form of identification
<libv>
machine = "s906-v10"
<libv>
and google picks up a lot of MID-S906
<ssvb>
libv: I probably need to talk with #cubox people about how they manage memory allocation for their gpu
<libv>
ssvb: you are right on the mali btw
lioka has joined #linux-sunxi
<libv>
and imho cedar, g2d and disp should share dma space
<libv>
but dma doesn't allow for that, and i am not sure cma will be any better as it is just some layer on top of that
<ssvb>
libv: having rmk (the arm linux maintainer) working on this stuff for cubox increases the chances of having something "mainlinable"
<libv>
ssvb: as said, the mali-400 is just happy with any pages
<libv>
ssvb: i am using dma_alloc_coherent for disp
<libv>
to great success
<libv>
once i got round the stupidity that is gem
<libv>
a locking disaster and probably one of the most inconsistent apis around
<libv>
typically anholt
<libv>
ssvb: i am sure that dma_alloc_coherent will be acceptable upstream
<libv>
ssvb: the fact that our display engine, 2d engine, gpu and vpu are completely distinct blocks...
<libv>
well, none of the drm folks are capable of thinking of such a situation
<libv>
but i ranted enough about that before
<ssvb>
g2d needs some sort of a simple physically contiguous memory heap for small allocations, which can grow and shrink at runtime, etc.
<ssvb>
nothing too fancy, but reinventing wheels may be a bad idea
<libv>
ssvb: i never tend to reinvent anything
<libv>
ssvb: i leave that to the xorg folk
<libv>
ssvb: this is why i am using dma_alloc_coherent
<libv>
ssvb: now, i was about to state that perhaps we can convince this dma allocator to use a single large reserved space
<libv>
instead of per device spaces
<notmart>
oliv3r: ok, sent a new pull request with a single commit
<libv>
dma is sadly only really aimed for "small allocations"
<ssvb>
dma_alloc_coherent is good for allocating a large pool, but not for small allocations inside of it
<oliv3r>
notmart: let me see and merge ;)
<libv>
ssvb: would we really need to go below page size?
<libv>
ssvb: would we want to?
<libv>
ssvb: do you know why mali is that low overhead?
<libv>
ssvb: because it allocates big blocks from the kernel, and then subdivides them as needed in userspace
<ssvb>
and yes, it's good that we have CMA for dma_alloc_coherent in the newer kernels (but at least it works for large allocations)
<libv>
dma_alloc_coherent works for large allocations too
<libv>
if it is given a large enough space to work with
<libv>
as it was intended for small contiguous bits initially
<libv>
as of course, none of the hw for which support was accepted in the kernel, needed huge buffers
<libv>
anyway, let's get this kms driver i am poking at (6.5kloc already - but a pre-publication cleanup should rid 1kloc i think) upstream first
<libv>
and we can worry about a bit contiguous reserved space for disp, g2d and cedar then
<libv>
s/bit/big/
<libv>
i have kept that part real simple on the display side, so it should be easy to fix or extend that
<ssvb>
libv: ok, maybe I can push my kernel side g2d code to some public git soon, so that people can test it already
<libv>
ssvb: i hope to get my bits out before new years, as progress really is very brisk
<ssvb>
having all of this done at least before fosdem would be nice
<libv>
great, i cannot find a good link to this mid-s906 emails from the web.
<libv>
gmame doesn't seem to know about it, and google groups makes it tricky to get a link to individual messages.
<libv>
from now on, anyone who replies to that thread should get shot :p
<libv>
it was started in july and still we get people replying to it
<libv>
is google even indexing the sunxi ml archive on gmame?
<libv>
ah, gmane,
<oliv3r>
notmart: why does the eoma fex file have an active entry for acapactive touch screen (the gls1680 to be specific) connected to i2c port2? Is that per spec?
<oliv3r>
notmart: same goes for camera_list_para, does the eoma spec really support gc0308 and ov5640 camera's?
<oliv3r>
but without the CSI ports (those are both disabled) and are you use there's no GPIO used for the sata power port?
<notmart>
oliv3r: for the touchscreen as far i know yes, that's on one attacheable board
<oliv3r>
notmart: was the hardware bug with the wrong mmc port being wired not fixed for the eoma68-a20? how do you boot it? via nand I assume
<notmart>
for the camera, i don't know (I should ask luke)
<oliv3r>
notmart: yeah but this fex file should be generic for the eoma board, not any attachements as anybody could use anything, so you sure you want to default to 'a' touch screen?
<notmart>
oliv3r: yes, via nand, or via usb
<oliv3r>
also gsensor is set but i bet there is no gsensor on any of the eoma boards :)
<oliv3r>
notmart: you can't boot via USB, you need to have an SPL on either mmc, or nand (or spi-flash)
<oliv3r>
the BROM won't boot from usb
<oliv3r>
the eoma board doesn't have a wifi solderd onto it does it?
<oliv3r>
so wifi probably should be off
<oliv3r>
audio is done via a seperate micro controller; so should be disabled by default I assume?
<notmart>
ok, so i'll redirect those questions to who did the fex..
<oliv3r>
notmart: probably safe yeah :)
<oliv3r>
notmart: but you are hitting an interesting point here
<notmart>
the idea i think was to have one that worked for both the first board and the tablet as well
<oliv3r>
the BOARD needs a fex with certain options for this board
<oliv3r>
but what if you combine this board with accessory A and B
<oliv3r>
each get their own fex file too I assume, based on the EOMA fex file?
<oliv3r>
notmart: That's the wrong approach imo, what if we are down 3 accessories and they have different options enabled? (maybe unlikly but still)
<libv>
heh, no, it's impossible to get VGA working on the second display pipe
<oliv3r>
my personal guess is, you'd need seperate fex files for each platform, with a base fex file for the EOMA68?
<oliv3r>
libv: and hdmi on the second?
<libv>
so you can forget about vga and hdmi with different timing on most devices
<oliv3r>
libv: so you are forced on having VGA as your first piple?
<oliv3r>
ah like that
<oliv3r>
so only if they can be 'mirrored' upto the timings
<libv>
oliv3r: all encoders are hardwired to the lcdc
<libv>
we have 2 lcdcs
<notmart>
perhaps will need a different fex for each feature board, yeah
<libv>
vga depends on h/vsync
<libv>
while tvecs can drive any of the 8 DAC lines
<libv>
the h/vsync come from the lcdc
<libv>
so the second lcdc on most A10 devices is just for composite/s-video/component
<libv>
i still need to fire up my tablet and figure out the lowlevel details there
<libv>
but i think the lcd might be wired to lcdc0 as well
<libv>
yeah, PD :(
<libv>
so lcdc0
<libv>
unless someone knows of android devices driving full hd resolutions on hdmi while using the tablets lcd, i am going to assume that this is out of the question
<libv>
on our hw
<oliv3r>
sounds very plausible
<oliv3r>
i think all fex's I saw use lcdcd0 for the display
<libv>
lcdc1 really is dead silicon
<libv>
if you cannot switch hdmi to it, and all signs i have now seem to point in that direction, then it is pointless
<libv>
and .fex is not describing connectors properly btw :)
<libv>
i need to know which dac line is which colour, i need to know where h/vsync live, and where ddc lives, if any
<libv>
for vga
<libv>
for hdmi, i need to know nothing at all, just that there is a connector there
rwmjones has quit [Excess Flood]
<oliv3r>
so it's DISP -> HDMI or LCDC0
<oliv3r>
and for the second FB there's no LCDC1
<oliv3r>
how sure of this are you? we know the olimex boards even break out the LCDC1 pins
<oliv3r>
we should ask tsvetsan if they ever tried connecting a display to the secondary controller
rwmjones has joined #linux-sunxi
<libv>
oliv3r: hdmi depends on the serialization taking place in the lcdc
<oliv3r>
ah okay
<libv>
oliv3r: it will work if you wire the LCD to lcdc1, yes
<libv>
it will also work if you wire VGA h/vsync to lcdc1
<libv>
but for mele and cubieboard and cubietruck...
<oliv3r>
ah okay
<oliv3r>
you don't happen to have an olimex board do you
<oliv3r>
curious if they done it properly
<notmart>
oliv3r: ok, so i asked if they want in the end just one fex like that, or one with only the features in the eoma itself or whatever
<libv>
a former colleague of mine bought my A13 off of me, as he wanted to demo it to a customer that was using something pvr based at the time
AreaScout has joined #linux-sunxi
<libv>
so i have no olimex hw atm
<libv>
but my range of hw is only lacking in some tablets which do proper full lvds i think
<oliv3r>
notmart: that's a good starting point yeah
<oliv3r>
notmart: also, it's not only about what they want, it's also what is sane to support and future proof(ish)
<libv>
and there is no board with lvds in our sunxi-boards repo
<notmart>
right
bsdfox has quit [Read error: Operation timed out]
<oliv3r>
libv: i was actually just thining of using the LVDS port to connect to an old 19" LCD bypassing the built in display module
<oliv3r>
it FEELS like an interesting hardware project :)
bsdfox has joined #linux-sunxi
<libv>
oliv3r: where will you get the right cable?
<oliv3r>
solder it :p
<libv>
oliv3r: ...
<oliv3r>
i have a few other dead monitors with those twisted cables
<oliv3r>
rip off plug, solder it, done
<libv>
oliv3r: since a year or so, you can buy them premade from china
<oliv3r>
I noticed there's various connectors though
<libv>
oliv3r: i have tons of lvds modules, and a load of panels stolen from dead laptops
<libv>
for VIA hw
<libv>
i never have connected them
<oliv3r>
I've had a DELL 21" that had the LVDS connector actually split in 2
<libv>
even though i know a company here in germany which should make custom cables
<libv>
but i think the cost is going to be rather high
<oliv3r>
but yeah, power + panel, skip the onboard controller PCB
<libv>
and i never bothered with it so far, i just collected the via expansion modules
<oliv3r>
yeah custom cable shops charge a mount
<libv>
oliv3r: check ebay for LVDS
<libv>
oliv3r: cables are available for a few bob from china these days
<libv>
but it wasn't always so
jinzo has joined #linux-sunxi
jinzo has quit [Changing host]
jinzo has joined #linux-sunxi
<oliv3r>
those pcb don't really do much more then hdmi -> lvds right? I do suppose they controll the backlight of course :S
<libv>
yeah
<oliv3r>
hmm, probably keep the controller PCB then :(
<libv>
also do the menu and such
<oliv3r>
or use a GPIO etc
<buZz>
pull apart the lcd, remove backlight and reflectors and put a desklight behind it ;)
<oliv3r>
haha
<buZz>
i have done this :P
<buZz>
actually, with a stroboscope instead of a desklight
<oliv3r>
what's the image quality
<buZz>
then challenged my mates to play quake3 on the display :D
<buZz>
nobody got much points
<oliv3r>
lol
<libv>
buZz: how many epilepsy attacks did you trigger?
<buZz>
none
<buZz>
i have never ever seen someone (even known epileptics) getting a seizure from stroboscopes
<captainigloo>
but as raoulh said it was working before we update the kernel to the latest revision.
<ssvb>
so nothing like "sunxi_no_mali_mem_reserve" there, phew :)
<ssvb>
yeah, fbturbo is pretty much unhappy about something in the kernel if we read the logs
<ssvb>
can you try to build this kernel with sun4i_defconfig/sun7i_defconfig instead of your custom one?
<raoulh>
sure
<captainigloo>
ssvb: we saw you have a linux-sunxi fork with support for r3p2
<ssvb>
for example if some important option got renamed in the new kernel, you might have a problem with stale config
<ssvb>
captainigloo: yes?
<captainigloo>
what's the status of that port ?
<captainigloo>
you gonna merge it with the official repo ?
<captainigloo>
ssvb: we are talking about using the default defconfig in meta-sunxi
<captainigloo>
so it make sense :)
<ssvb>
I'm just reluctant to deal with the possible fallout of bugs which are going to be revealed if we start to "officially" support r3p2
<ssvb>
keep pinging me and this will happen :)
<ssvb>
this=upgrade
<captainigloo>
ok
<captainigloo>
i think that we will add patch in meta-sunx to try it
<ssvb>
for now we need to figure out why you are getting a black window...
<captainigloo>
yes :)
<raoulh>
:)
<raoulh>
one step after the other :)
paulk-collins has quit [Remote host closed the connection]
<captainigloo>
sure :P because last week we walked backward ;)
<wolfy>
ping -i 60 ssvb -p "r3p2" ssvb
<wolfy>
hm, only one destination should suffice
<raoulh>
lol
<raoulh>
ssvb: i found that we have CONFIG_FB_SUNXI_RESERVED_MEM=y in our defconfig
<raoulh>
and it's not in sun4i_defconfig/sun7i_defconfig
<ssvb>
raoulh: it's the default value for this option, and sun7i_defconfig does not list default options
<raoulh>
ok
<raoulh>
:)
<libv>
has anyone ever heard of the AXP223?
<ssvb>
you can get a reduced config yourself if you run something like "make ARCH=arm CROSS_COMPILE=armv7a-hardfloat-linux-gnueabi- savedefconfig" after building the kernel
<libv>
cubietruck uses AXP209
<oliv3r>
axp223? not commonly
<oliv3r>
libv: doesn't A31 use the axp223?
<captainigloo>
ssvb: thanks a lot i was searching this command for months :)