<naobsd>
is there any missing driver for A20 to use libvdpau-sunxi? I can't find any detail about it
<naobsd>
(it was mentioned on cubieboard google groups)
<naobsd>
I guess they are talking about 3.4 kernel, I'm not sure
<naobsd>
I'm not sure missing == not ported yet, or == only binary blobs for 3.3 are available
<naobsd>
I think there is no binary blob in 3.3 kernel...
popolon has quit [Quit: Quitte]
jlj has joined #linux-sunxi
akaizen_ has quit [Remote host closed the connection]
<hno>
naobsd, there is plenty of blobs in the 3.3 kernel, but none that is relevant to CedarX.
<naobsd>
hno: thanks
<hno>
but I am not sure if the CedarX driver in 3.3 kernel is compatible, or if the A20 and A10 CedarX is identical.
<naobsd>
ah, I see
akaizen has joined #linux-sunxi
<hno>
The hardware quite likely is the same, just not sure. Not actively working on those parts.
<naobsd>
if software is incompatible, driver or library need to be fixed. if hardware is incompatible, need more RE. from message on google groups, it sounds something need to be provided from allwinner, I felt strangeness
egbert has quit [Disconnected by services]
egbert_ has joined #linux-sunxi
<naobsd>
is u-boot built with thumb(2)?
<naobsd>
oops, where is my working dir...
<hno>
u-boot is not build with thumb. Alla arm32.
<naobsd>
did you try CONFIG_SYS_THUMB_BUILD?
<hno>
No.
<hno>
which message indicated something needs to be provided by allwinner?
<hno>
that's with latest linaro gcc 4.8 which can't otherwise fit the spl if falcon mode is enabled.
<naobsd>
oops, I'm still on sunxi-current
<naobsd>
grr
<naobsd>
retrying with sunxi...
<hno>
naobsd, what board do you have?
<naobsd>
cb2
<hno>
Cubieboard2_Falcon_T arm armv7 sunxi - sunxi sun7i:CUBIEBOARD2,SPL,SPL_OS_BOOT,SUNXI_EMAC,STATUSLED=244,SYS_THUMB_BUILD
<hno>
in boards.cfg dfines a thumbs build with falcon.
<naobsd>
thanks, I added CONFIG_SYS_THUMB_BUILD in include/configs/sunxi-common.h :)
Soru has quit [Read error: Connection reset by peer]
<hno>
You also need SPL_OS_BOOT for falcon.
<hno>
CONFIG_... if set by #define
<naobsd>
I see, there is Cubieboard2_Falcon in boards.cfg
<hno>
yes
<naobsd>
I did git pull on sunxi :)
Soru has joined #linux-sunxi
<hno>
Looks very promising. But haven't tried to load a kernel yet.
<naobsd>
-rwxr-xr-x 1 fun fun 18340 2013-09-01 10:34 u-boot-spl.bin (with linaro gcc 4.7)
<naobsd>
I guess there is some optimization which is enabled only on non-thumb mode...
<naobsd>
on 4.8
<naobsd>
I also not tried to load yet
<naobsd>
I have to open my gadget box to try
<hno>
please test what you can test. Time for bed here. Have a meeing in some hours..
<naobsd>
... and clean my desk...
<naobsd>
hno: I see, good night
\\Mr_C\\ has quit []
<naobsd>
hmm, I have to go out, see you later...
naobsd has quit [Quit: Page closed]
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
massi has joined #linux-sunxi
massi has quit [Quit: Leaving]
wingrime has joined #linux-sunxi
<wingrime>
jukivili: ping
<wingrime>
ssvb: ping
<wingrime>
ssvb: are you tested small patch?
robb83 has joined #linux-sunxi
sud0x3 has quit [Ping timeout: 256 seconds]
<wingrime>
Tsvetan: ping
<wingrime>
oliv3r: for such things like history we have versioning system - git
<wingrime>
oliv3r: we much not have #if 0 code
<jukivili>
wingrime: ping
<wingrime>
jukivili: you broke a13 usb
<wingrime>
jukivili: ((
<wingrime>
jukivili: there something different in a13 usb that not handled by current code
<jukivili>
hm.. which commit?
<wingrime>
jukivili: have no idea,
<wingrime>
jukivili: my older kernel was before unification
<wingrime>
jukivili: I tryed remove sunxi_is_sun5i() or invert but useless
<wingrime>
jukivili: so there something you lost during unification
<jukivili>
which kernel you are using?
<wingrime>
3.4
<wingrime>
stage
<jukivili>
are you sure it's the unification that went wrong? .. there has been alot of patches to clean up usb host drivers lately
<wingrime>
jukivili: don't know
<wingrime>
jukivili: but I tested same code with a10 and a13
<wingrime>
jukivili: on a13 usb have no any thign of life
deasy has joined #linux-sunxi
naobsd has joined #linux-sunxi
<oliv3r>
wingrime: yeha but if i'd start porting/writing a new disp driver i'd look at the current code, not at the history; btw, it doesn't happen to be that #if 0; #if 1 etc should have been ARCH_SUN4I; ARCH_SUN5I? You know how allwinner is, fork code, and change it for the platform
<oliv3r>
wingrime: jukivili arokux1 did a lot with USB too
<jukivili>
wingrime: can you test the non-stage sunxi-3.4? It does not appear to have those clean-up patches yet.
<wingrime>
jukivili: I will try
<wingrime>
oliv3r: git for that
<oliv3r>
wingrime: ok you voulenteerd to rewrite disp :D
<oliv3r>
i kid i kid
<wingrime>
oliv3r: you can comparea any file in any branch with GIT
<wingrime>
oliv3r: we have firstly drop all non used code
RaYmAn_ is now known as RaYmAn
<leviathanch>
Turl: hi
<wingrime>
jukivili: unfortunly current sunxi-3.4 even not builds
<mnemoc>
o_O
<leviathanch>
I'm working on the sunxi-mci driver for linux-next right now
<leviathanch>
unfortunately I don't know how to cleanly access the registers of the mod0 clock
* leviathanch
still trying to figure it out
<leviathanch>
wingrime: my branch is building allthough it's not doing anything useful yet
<oliv3r>
leviathanch: you are not supposed to touch the mod0 registers, you use the clock framework to set/get a clock
<oliv3r>
leviathanch: have you been in touch with mripard as he also did a mmc/SDIO driver or is working on one
wingrime has quit [Ping timeout: 264 seconds]
<mripard>
leviathanch: this is exactly what Emilio's patches I've pointed you to are doing.
<mripard>
hno: ping?
<leviathanch>
mripard: uh?
<leviathanch>
I'm working on emilio's branch right now
<leviathanch>
ok
<mripard>
(basically, you don't touch the mod0 registers directly, you just use the clock framework functions)
<leviathanch>
mripard: how do I choose the clock source?
<leviathanch>
set_parent?
<leviathanch>
mripard: you know that ahb is basically only a clock multiplexer
<leviathanch>
so the question is how do I tell it which clock source to use?
<mripard>
i think you don't need to worry about this, and clk_set_rate will take care of reparenting the clock if it needs to, but I'm not sure
<mripard>
Turl: ?
<leviathanch>
mripard: if so, I could delete a whole bunch of code
<mripard>
that's the plan, yes.
<oliv3r>
leviathanch: if your working in porting the current mmc code; most probably, it's a huge pile of mess that dates back to the sun3i days, probably even from before that
<oliv3r>
it might be worth exploring if there's other mmc drivers that are almost the same? its not unlikely they've used some IP for the mmc :)
<mripard>
drachensun: ping?
wingrime has joined #linux-sunxi
<oliv3r>
mripard: today a good day to resubmit the cleaned up version? or wait a little more for comments?
atiti has joined #linux-sunxi
<leviathanch>
oliv3r: I've got u-boot-sunxi in front of me as well
<leviathanch>
as well as the A20 user manual
<leviathanch>
but it's no good
<leviathanch>
all the same hackish approaches
<oliv3r>
oh that's even a bigger pile of shit
<oliv3r>
:)
<mripard>
oliv3r: yeah, just send the patch
<leviathanch>
mripard: nope, it's not doing it right
<leviathanch>
maybe someone can ping Turl when he is around that he might try out my branch and fix this issue
<leviathanch>
:-)
<oliv3r>
mripard: if i understand you right, you prefer having all 3 patches labeld as [PATCHv6 x/n] ARM: sunxi: (dt: for dt patch)? how do I do that with send-email? i know --subject-prefix='v6' is probably the thing for the [PATCH] bit, but after that i draw a blank
<wingrime>
oliv3r: also I will remove AVS driver - thats not used by any cedar blocb
<oliv3r>
wingrime: Audio Video sync
<wingrime>
oliv3r: sun7i also have no
<oliv3r>
it's just a timer isn't it
<mripard>
Turl: hi :)
<wingrime>
oliv3r: current cedar use hres timer
<wingrime>
oliv3r: also this is cedar - only driver
<oliv3r>
wingrime: isn't the hres timer used by the kernel?
<oliv3r>
wingrime: i thought in mainline mripard used it for that
<wingrime>
oliv3r: yes, any player will use hres
<Turl>
hi mripard
<wingrime>
oliv3r: avs from sun3i times
<oliv3r>
wingrime: a20 still has the AVS counter
<oliv3r>
wingrime: so we could just rename it and make it CNTR0
<Turl>
mripard: I see a lot of highlights about clocks but I didn't get where's the issue fully
<oliv3r>
since that's all it does, it's a counter, probably with its timings in sync, but still a counter only anyway
<oliv3r>
Turl: leviathanch is missing mmc clocks
<Turl>
oliv3r: which one? I think I implemented them already
<wingrime>
oliv3r: sun4i_avs was broken untill hramrach fixed it
<wingrime>
oliv3r: sun4i stock never have it build in
<oliv3r>
wingrime: so yeah, we don't have an AVS, we have a counter0 :)
<wingrime>
oliv3r: but this is private api /dev/avsdev
<wingrime>
oliv3r: also sun4i_cedar have own ioctrl to it
<oliv3r>
yeah but if you say it's not needed and software has a much more accurate timer, then why would we need it
<wingrime>
oliv3r: I will unify cedar soon, also I want clean it
<oliv3r>
wingrime: didn't you unify it a while ago? i thought those patches landed allready
<wingrime>
oliv3r: still no
<oliv3r>
atleast we have an up-to-date staging tree again
<hno>
techn_, not that I know of. Script been called usb-boot for a very very loing time
<wingrime>
mnemoc: ping
<mripard>
oliv3r: I'm using what for what?
<mouchon>
hello
<mripard>
Turl: the issue leviathanch seems to have is that the mod0 clocks don't change their source clock when you actually call an impossible set_rate for the current clock it uses
<mouchon>
i made some test to change i2c freq to 50khz and seem to work :-)
<Turl>
mripard: well, the clocks don't have "upstream" knowledge
<Turl>
mripard: they do their best effort to round and that's it right?
<mripard>
leviathanch: btw, 400kHz ? for a SDIO driver? it seems way too low
<jukivili>
oliv3r: the thing is that UsbPhyInit() modifies register space of the otg controller, and at least on sun4i omitting that function from usb-host driver has no adverse effect
<mripard>
Turl: the weird thing is that it asks for 400kHz, and gets 10MHz
<oliv3r>
mripard: hi-res timer source for the kernels timer
<mripard>
at what frequency are the mod0 clocks running?
<mripard>
oliv3r: no, I'm not using it currently
<mripard>
I have patches working on all SoCs but the A31, I'd like to get why before sending the patches
fredy has quit [Excess Flood]
<oliv3r>
jukivili: maybe people are using the wrong USB port! :D
fredy has joined #linux-sunxi
<Turl>
mripard: on which parent?
<jukivili>
oliv3r: if reverting patch fixes the issue, then I think correct place for UsbPhyInit() is outside usb-host and otg driver.. move phy initialization to arch/arm/plat-sunxi/
<mripard>
Turl: hosc, pll5 and pll6
<Turl>
mripard: yeah but which one was active for it? :)
<Turl>
mripard: pasting /d/clk/clk_summary would be nice ;)
<mripard>
don't know, ask him :)
<mripard>
leviathanch: ^
<Turl>
(/d/ is debugfs, and you need to enable CLK_DEBUG)
<mripard>
you're such an Android guy :)
<Turl>
mripard: /d/ is just so more convenient than punching /sys/kernel/debug/ on a keyboard each time :)
<wingrime>
oliv3r: take a look to ML
robb83 has joined #linux-sunxi
<oliv3r>
what'st that #UNUSEd table for?
<oliv3r>
looks almost like firmware
<wingrime>
oliv3r: Fir
<wingrime>
oliv3r: do you know what it means?
<oliv3r>
fir is?
<oliv3r>
FIrmware? :op
<wingrime>
oliv3r: no
<oliv3r>
could even relate ti infraread
<wingrime>
oliv3r: ni,no
<Turl>
mripard: if you need a 400kHz clock, parent can't be higher than ~50Mhz
<wingrime>
oliv3r: looks like AW add special table for video playback , but newer used it
<oliv3r>
wingrime: ohh yeah i've heard of that I think
<oliv3r>
wingrime: i've done some FIR filters in FPGA once
<wingrime>
oliv3r: it very simple thing
<wingrime>
oliv3r: also ther many soft that can generate such table
shineworld has joined #linux-sunxi
<Turl>
mturquette: ping
Dreadlish is now known as Lotysz
Lotysz is now known as Dreadlish
<mouchon>
still have a question regarding A20 i2c. Does 7bit or 10bit address is used ?
<oliv3r>
mouchon: i doubt we know by heart, best is to check documentation :)
<oliv3r>
we do know the i2c IP isn't from AW; the good news is, in the mainline kernel we are re-using the existing driver :)
<mouchon>
oliv3r thanks for the info. But which doc you are talking about ? kernel, olimex , aw ? sorry for this silly question
<oliv3r>
the A20 usermanual
<oliv3r>
the 'datasheet' for the A20 :)
<oliv3r>
it's on dl.linux-sunxi.org/A20
<mouchon>
ok thanks i will dl it
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
rz2k has joined #linux-sunxi
<mouchon>
found my answer seem to be 10bits
<shineworld>
mouchon, are you trying to use i2c with cb2 ?
<mouchon>
no with olimex A20
<shineworld>
I don't know a lot Olimex A20... is better than cb2 how hardware combo ?
<mouchon>
can not really compare, i don't have cb2. But olimex a20 has many GPIO
<buZz>
cb2 has 96 pins
<shineworld>
for eg: can olimex A20 power the RTC circuit so I can lost every time the timer ?
<shineworld>
can't
<Turl>
shineworld: olimex publishes schematics, you can take a look :)
<mouchon>
shineworld: no on board battery, but you can connect lipo
<oliv3r>
cb2 is nice and compact; olimex is big but has tons of pins connected
<oliv3r>
olimex is opensource hardware
<shineworld>
I will purchase it ... so I will try
<shineworld>
thanks
<oliv3r>
shineworld: olimex has a battery connection, but not specifically only for RTC; cubietruck will have that though
<shineworld>
cubietruck isn't available yet
<oliv3r>
:)
<oliv3r>
olimex a20 is the same board as A10 with different chip; so not much change there yet
<shineworld>
actually I've 10 cb1 and 2 cb2 running and one cb2 on my desk for development
<oliv3r>
i'd expect the next itteration to possibly have it
<oliv3r>
Tsvetan: ^
<shineworld>
cb1 are running in a 24/24 7/7 plant without problems
<shineworld>
cb2 sometime restart or crashes
<shineworld>
all with android OS (for HMI interface)
<shineworld>
cb1 is enough robust hardware and software
<oliv3r>
cb1 and cb2 use same pcb
<oliv3r>
so if there's crashes, eitehr bad chip or bad software :)
kaspter has joined #linux-sunxi
<shineworld>
I guess is a software question... or something with dram speed
<shineworld>
I don't know really
<shineworld>
because happens only in plant
<shineworld>
at home all works fine ... perhaps a temperature question ? boh ...
<shineworld>
or a power issue with board load
<shineworld>
what customer say is that system reboot
<Turl>
shineworld: A20 uses more power, maybe a psu issue?
<shineworld>
could be ... the temperature on plant is high so I need to check all variables of equation ... but are prototypes so customer is not strict on that
<shineworld>
and I've filled boards of tropicalization product so...
<shineworld>
*tropicalised varnish
<buZz>
you are varnishing plants?
<buZz>
poor plants
<shineworld>
ha ha ha ... I mean industrial plant :)
<shineworld>
sorry for my very bad english
vicenteH has quit [Read error: Connection reset by peer]
<wingrime>
oliv3r: I making patch that makes disp works with fully sun5i/sun4i detection
vicenteH has joined #linux-sunxi
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
shineworld has quit [Remote host closed the connection]
<buZz>
:)
ZetaNeta has quit [Ping timeout: 245 seconds]
<Turl>
oliv3r: found a typo on your patch
<Turl>
oliv3r: 'very rarly probed'
<Turl>
oliv3r: also I think the sunxi_sid_of_match can be __initconst
<Turl>
mripard: ^ thoughts?
<mripard>
Turl: nope
<mripard>
you'll have a section mismatch
<mripard>
since it's referenced by both probe and the platform_driver structure that aren't __init
<Turl>
probe is __init
<mripard>
it shouldn't
<Turl>
why? :)
<mripard>
because the kernel might need probe after having freed the init section
<mripard>
it even causes a warning
<Turl>
isn't the free ran after everything is set up?
<mripard>
not necessarily
<mripard>
what if you have a USB driver, and that the device is plugged later on?
<mripard>
=> boom
<Turl>
mripard: a USB driver won't run the sid probe code :)
popolon has joined #linux-sunxi
<mripard>
I'm talking about a generic case, you're talking about a specific case :)
<Turl>
mripard: SID is non-hotpluggable
<Turl>
USB is
<mripard>
yes, I'm talking about "all the drivers", you're talking about "the non-hotpluggable ones"
<Turl>
so? :)
<mripard>
in this case, yep, the kernel won't use it
<mripard>
yet, probe shouldn't be __init.
<mripard>
in *any* case
<mripard>
for all you know, it could become somewhat hotpluggable.
<mripard>
think about the DT overlays mechanism, that allows to inject later on in the system dt chunks
<Turl>
mripard: it should move to module_platform_driver_probe(..) then?
<mripard>
probably, or drop the __init from probe
<mripard>
anyway, the of_match table will never be __initconst
<Turl>
I'm a fan of saving bytes as you can see :)
ykchavan has joined #linux-sunxi
<mripard>
:)
n01 has quit [Ping timeout: 260 seconds]
<mnemoc>
Turl: around?
<Turl>
mnemoc: yep
<mouchon>
yes finaly got uart.6 and uart.7 working. seem that fex file from olimex is not correct and i forgeted to disabled hardware flow conrol in minicom
* Turl
is now intrigued
vicenteH has quit [Read error: Connection reset by peer]
rings_IIV has quit [Read error: Connection reset by peer]
rings_IIV has joined #linux-sunxi
<mnemoc>
Turl: I would like to merge the current stage in 3.4 to non-stage. currently both pass my defconfig build tests, but I still haven't been able to get back into the ML
<mnemoc>
Turl: is there any known issue or important outstanding patchset?
<wingrime>
mnemoc: a13 usb not works
<Turl>
mnemoc: I've not been following it much, but there's that
<Turl>
and I think mali had build problems on anything but sun7i, probably got addressed already
<mnemoc>
wingrime: defconfig issue or pending patch?
<mnemoc>
Turl: I fixed the mali compilation issue tthe 28th after merging hansg's for-amery
<Turl>
oliv3r: I got confused by the "10 days ago"
<oliv3r>
yeah, i don't know how it figures that
<Turl>
it's the commit date
<oliv3r>
yeah
<Turl>
but each time I rebase (and therefore rewrite them) it gets updated
<oliv3r>
i should rebase shouldn't I :p
<Turl>
dunno why yours say 10d ago :p
<Turl>
what do you do?
<oliv3r>
rebasing tends to make a horible mess
<Turl>
as long as you rebase over the same commit, it's np :p
<oliv3r>
i had to cherry-pick a few times to a 'clean' tree because rebasing failed somewhere inbetween
<Turl>
git rebase --interactive HEAD^^^
<Turl>
so you don't need to remember which branch you based your stuff on :)
<oliv3r>
well once we have the 'basics' in place more, it should all be upstream anyway
<oliv3r>
and writing a new driver is just that
<oliv3r>
but now i needed stuff from mripards tree
<Turl>
yeah, deps are a pain
<oliv3r>
thing is,t he stuff that was giving conflicts, was from old commits that we both hadn't touched i would have guessed
<rz2k>
region `.sram' overflowed by 20 bytes
<rz2k>
hmm
<rz2k>
seems like I'm unlucky with linaro gcc latest
<oliv3r>
bin getting to big :90
<oliv3r>
i really hoped we could do a 30k binary :S
<rz2k>
i probably should not ask if we can throw some printf's like "u-boot spl %version" and have that 20 bytes free, right?
<rz2k>
s/throw/throw away/
<Turl>
rz2k: is uboot built with -Os?
n01 has joined #linux-sunxi
<rz2k>
I redirect that question to hno
<rz2k>
:p
<Turl>
rz2k: hno was playing with thumb mode the other day, that'd make it smaller too
<rz2k>
I'm trying to build Falcon binary for A20 olinuxino
<rz2k>
yes thumb binaries is known to be smaller
wingrime_ has joined #linux-sunxi
<Turl>
the real question is why is linaro making toolchains that produce fatter binaries :P
<oliv3r>
Turl: yes it is
<rz2k>
no idea, but I guess because they care about back compat
<oliv3r>
falcon mode gobbles up quite some space
<rz2k>
like if they change something hardcorely, ton of old code will die
<oliv3r>
i guess when we really start to save some bytes we'd have to move the printing stuff to u-boot entirly and make spl silent, which makes it horrible to debug
<Turl>
oliv3r: thumb would be a decent alternative :)
<hno>
Cubieboard2_Falcon_T arm armv7 sunxi - sunxi sun7i:CUBIEBOARD2,SPL,SPL_OS_BOOT,SUNXI_EMAC,STATUSLED=244,SYS_THUMB_BUILD
<hno>
show what is needed for Cubieboard2. Maps 1-1 to A20 OLinuXIno.
<oliv3r>
u-boot should be nearly interchangeable onthose two
<oliv3r>
hno: how much smaller does the thumb build get?
<hno>
25% iirc.
<oliv3r>
oh wow, so 18k?
<hno>
-rwxrwxr-x. 1 henrik henrik 18412 1 sep 03.18 build/Cubieboard2_Falcon_T-4.8/spl/u-boot-spl.bin
<hno>
-rwxrwxr-x. 1 henrik henrik 17636 1 sep 03.12 build/Cubieboard2_Falcon_T/spl/u-boot-spl.bin
<hno>
the -4.8 is with latest Linaro 4.8 toolchain.
<oliv3r>
very nice indeed
<oliv3r>
so thumb mode is coming up as next big change?
<hno>
Just need to look into if there is any disadvantages from it. But does seem to load fine. Have not tried loading a kernel yet, but I see no obvious reasons why that would not work.
<jukivili>
techn_: well.. I have only tested g_ether gadget myself
<techn_>
yeah.. there is differences between gadgets :(
<jukivili>
wingrime: ok.. problem is with otg-host driver, not ehci/ohci. Your micro-to-usb cable is OTG-host cable
<wingrime_>
jukivili: are you find witch wrong
rings_VII has quit [Ping timeout: 268 seconds]
<jukivili>
wingrime_: sun[45]i_usb unification changes names of kernel config knobs.. maybe it's config problem. Can you give your stage/sunxi-3.4 config?
<wingrime_>
jukivili: cp arch/arm/configs/sun5i_defconfig -- something like
<techn_>
wingrime_: that may not be the real config
<techn_>
find .config
<hramrach>
you use that config by make sun5i_defconfig
<hramrach>
it does not have defautls so does not work as .config
<wingrime_>
techn_: I used that config , all otherthings are default
<techn_>
it might be broken after some bisecting.. if cleanup wasnt done
Soru has quit [Read error: No route to host]
Soru_ has joined #linux-sunxi
gnufan has quit [Ping timeout: 240 seconds]
<techn_>
wingrime_: are you using pure host or otg mode?
<wingrime_>
techn_: otg
<wingrime_>
techn_: but there is no much differnece between
<techn_>
wingrime_: no other differences that config changes..
<techn_>
and one change which seems to be slipped trough
<techn_>
msleep(3000); in static int usb_hardware_scan_thread(void * pArg)
<techn_>
usb_manager.c
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
Black_Horseman has joined #linux-sunxi
<hramrach>
hmm, when I use the vdpau cedar lib I get a crash in /usr/lib/arm-linux-gnueabihf/neon/vfp/libavcodec.so.53
<hramrach>
hmm, also when not using the module
<hramrach>
I guess there is some general problem with vdpau
<hramrach>
actually there's no other module to use so I guess it gets used regardless
<hramrach>
ii libvdpau1:armhf 0.6-2
<hramrach>
wingrime_: on what system is the libvdpau sunxi module supposed to work?
<wingrime_>
hramrach: a10
<wingrime_>
hramrach: a13 need fix for display
<hramrach>
it crashes before it even displays anything for me