<wens>
Turl: i know, but having everything under soc doesn't play well with dependencies with fixed-clock and fixed-factor clocks
<Turl>
wens: what kind of dependencies?
Nyuutwo has joined #linux-sunxi
<wens>
Turl: of_clk_init checks if the parent clocks are available before adding a clock
<wens>
so it will start adding root clocks, then immediate child clocks, and so on
<wens>
after adding each clock, it sets the defaults if given in the DT
<wens>
that's kind of where it breaks
<wens>
it adds every clock left if it finds it can't satisfy dependencies anymore
<wens>
and if you set defaults for a clock that doesn't have its parents available, determine_rate would have some parent rate = 0
<wens>
fwiw, this only occurs with sun6i pll6 atm, because of the fixed-factor clock in the DT
<wens>
another thing is that the protected clocks stuff might not propogate clk_enable all the way up, if some parent was missing when it was called
<Turl>
wens: so wouldn't fixed factors be added first?
<wens>
Turl: of_clk_init checks parents based on the node matched by OF_CLK_DECLARE
<wens>
which ours happens to be the soc node... hence the problem
Nyuutwo has quit [Ping timeout: 246 seconds]
<wens>
no clocks property in that node, so no depedencies as far as of_clk_init is concerned
<Turl>
wens: I personally opposed all the dependency magic stuff on of_clk_init, we were good without it :)
<Turl>
and it seems inherently broken to try to configure clocks while the tree is settling
<Turl>
(which is probably also even more noticeable because this is configuring the clock from the provider instead of a consumer.. I wonder how would this fare when combined with Tomeu's series
Nyuutwo has joined #linux-sunxi
<Turl>
wens: what are we using the assigned-* stuff for?
<wens>
nothing atm, was testing it for dma on sun6i/sun8i, then realized it wasn't needed
<Turl>
so no actual breakage then?
<wens>
nope
<Turl>
wens: wouldn't it make more sense to move the configure stuff to the disable unused sweep (or another sweep around that point in time)
<Turl>
?
<wens>
i don't know, i suppose it was considered that clk providers play nice
<wens>
if we stick to one clk driver, we're all good
<wens>
as soon as we add another one into the mix, the dependencies go whack
<wens>
it seems the right way to have individual OF_CLK_DECLAREs if we want to split up the clock driver though
<Turl>
wens: yeah, I don't think using individual declares is a bad thing, but it does lend itself to a lot of boilerplate when you're declaring many of the same thing
<wens>
sunxi seems to be the only platform that lists all the clocks in the DT
<Turl>
that's not the issue though, the issue is assuming everything is ready by the time you register something
<wens>
the others just have a clock module node
<Turl>
wens: others seem to have have less clocks than fingers on your hands :) (marvell comes to mind)
<wens>
i agree that the of_clk_set_defaults clock doesn't quite work
<wens>
as for boilerplate... well I used regexps to convert the existing ones
<wens>
we could add a macro for that :p
<Turl>
wens: if you're bored see how much would it take to traverse the tree and run all the set default calls at the end of of_clk_init
<wens>
for us it's actually called in of_clk_add_provider i think
<wens>
(and if it fails, of_clk_del_provider get called...)
<Turl>
pretty redundant to call it in there isn't it?
<wens>
how so?
<Turl>
wens: it's called in of_clk_init too right?
tinti has quit [Quit: Leaving]
<Turl>
so it kicks in, registers the provider, sets it up.. sets it up
<wens>
in of_clk_init, it's called against the node matched by OF_CLK_DECLARE
<wens>
in of_clk_add_provider, it's called against the node you provided
<wens>
in our case, they are not the same
* Turl
scratches head
<Turl>
they're not the same?
<wens>
in our current situation, they're not the same
<mripard>
it's forced to use DMA in every case here
<mripard>
(have I mentionned that I didn't submitted it for a reason ? :))
<oliv3r>
ok this is weird
<oliv3r>
gcc: error: unrecognized argument in option ‘-mabi=aapcs-linux’
<oliv3r>
arm-linux-gnueabihf-gcc -o test test.c -pedantic -Wall -mabi=aapcs-linux
<oliv3r>
that works fine
<oliv3r>
it's from 3.17-rc6 arch/arm/Makefile:99:CFLAGS_ABI :=-mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp
<oliv3r>
ah, it's using gcc instead of CROSS_COMPILE
<oliv3r>
that's odd
dl9pf_ has joined #linux-sunxi
<oliv3r>
mnemoc: bsp very broken :(
<lauri>
Has anyone gotten accelerated video decode working on Cubietruck
<wens>
mripard: so the dma mapping doesn't like tx_buf = NULL
akaizen has quit [Read error: Connection reset by peer]
akaizen_ has joined #linux-sunxi
<wens>
am i wrong to assume i can just dd into it?
<mripard>
it should be fine
<rellla>
libv: outstanding answer from yesterday: been quit cubietech?
<oliv3r>
mripard: if I make a product, based on the lime, with an extension board on the headers (and thus certain pins are preconfigured in a certain way. Do i submit the 'final' dts to the kernel? Or is that a modification always intended to remain locally
<oliv3r>
rellla: yeah benn stopped working for cubietech, he's starting a new company
<mripard>
oliv3r: whatever, if you want to submit it, I'm fine with it, if you want to keep it for yourself, I'm also fine with it :)
<wens>
mripard: no luck :(
<oliv3r>
mripard: nono, i want to, i'm just asking what the procedure is for a situation like this, obviously it would 'inherit' the lime
<rellla>
oliv3r: ok. any info's about this company? any future plans about cubietech? just curious ...
<oliv3r>
mripard: my company is very opensource minded, but i can imagine we may not want 100.000's of dts files of small modifications to existing boards
philippe_fouquet has joined #linux-sunxi
<oliv3r>
rellla: new people for cubietech, less involved with OSS afaik, so who knows what that'll bring
bertrik has joined #linux-sunxi
<oliv3r>
rellla: new company from benn, focusing on mediatec + arduino kind of thing, like the yun, but more powerfull
<mripard>
oliv3r: yeah, include the DTS from the lime, and start from there
<oliv3r>
mripard: ok, so it is common and encouraged to share these dts'es, awesome
<oliv3r>
it'll be a few weeks/months though :p
<oliv3r>
i'll have to write a driver for our printer too (need timers, interrupts and SPI)
alexvf has joined #linux-sunxi
<rellla>
oliv3r: thanks for the info. so let's see if the new people's efforts can stand with tom's and benn's "power"
<rellla>
there are alternatives, though...
<oliv3r>
doubtfull
<oliv3r>
personally, cubietech will pretty much become less interesting to us I expect
<wens>
mripard: i don't get why tx_buf is null when i tell it to send something
<mripard>
wens: I don't know either, I'd expect it to be filled too
<wens>
we could test with uart (with a few patches), but Turl said it was buggy :(
<mripard>
I can test it, I have everything needed
<mripard>
both boards, and the spi devices
<wens>
ok, thanks
<mripard>
just not right here, but if I can go back to my place this weekend, I can test it
<wens>
no rush
<oliv3r>
mripard: the SPI has its own DMA doesn't it? It doesn't rely on turl's DMA work does it?
<mripard>
oliv3r: no, it doesn't have its own DMA controller
<oliv3r>
ah i thought it did; i saw the BROM uses DMA with the SPI driver
philippe_fouquet has quit [Remote host closed the connection]
<oliv3r>
i expected it to be just PIO'ed, since the BROM spi only has to load 64k anyway
<JohnDoe_71Rus>
oliv3r: bsp must be corrected
<wens>
it's using the system dma controller
<oliv3r>
JohnDoe_71Rus: i fixed it allready ;)
<wens>
mripard: i assume you want to hold off on the sun6i-ahb1 series then?
<oliv3r>
was the fdt_high bit needed to correct Uncompressing Kernel Image ... Error: Bad gzipped data?
Nyuutwo has joined #linux-sunxi
philippe_fouquet has joined #linux-sunxi
hypothalamus has quit [Ping timeout: 258 seconds]
popolon has joined #linux-sunxi
dl9pf_ has quit [Read error: Connection reset by peer]
joost_dtn has quit [Quit: leaving]
<mripard>
wens: vinod already merged the critical part of it
<mripard>
which breaks things
<mripard>
so I'd like to hold it off not too long :)
<wens>
that part i didn't expect
<wens>
still, i have no idea how to test sun8i atm
<wens>
good thing is no consumers yet
philippe_fouquet has quit [Remote host closed the connection]
sehraf has joined #linux-sunxi
<mripard>
yep.
<mripard>
that's why we aren't really in a hurry
<mripard>
but what I did was that I bought some cheap AT25, a bread board, and that's it
<mripard>
it doesn't cost much
<mripard>
and it's a rather good setup
<wens>
i could get some spi-based arduino sensor, have to look around
fredy has quit [Ping timeout: 240 seconds]
<wingrime>
Mediatech, with benn....hm, we sunxi only is't it?
fredy has joined #linux-sunxi
<mripard>
wens: just make there's a driver in the kernel already
<mripard>
that way, you're pretty sure that it's reliable, and if an issue arise, it's the controller's fault
<mripard>
(which is precisely why I ended up picking an AT25)
GillesM has joined #linux-sunxi
bengal has joined #linux-sunxi
Andy-D has quit [Ping timeout: 258 seconds]
wingrime1 has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
leviathanch2 has joined #linux-sunxi
bengal has quit [Quit: Leaving]
Nyuutwo has quit [Ping timeout: 246 seconds]
sehraf has quit [Ping timeout: 244 seconds]
philippe_fouquet has joined #linux-sunxi
<oliv3r>
mripard: am I wandering in the land of the dragons again, if my uImage is gzipped, what could cause u-boot to fail on uncompressing it. The only thing I can imagine overwritting of loaded data
<mnemoc>
mkimage also adds it's own layer of compression
<mnemoc>
some times uImages get truncated too
<mnemoc>
when dd-ing
<oliv3r>
mnemoc: well i just did the default kernel compilation, make uImage, with gzip enabled whitin the kernel
<oliv3r>
i used the wiki's starting address of 49000000
<oliv3r>
maybe that's to high?
<oliv3r>
46000000*
<oliv3r>
the dtb is at 490000000
<mnemoc>
it is possible that when loading the dtb you are truncating the uImage
<oliv3r>
yeah
<mnemoc>
in memory
<oliv3r>
S Kernel Image (gzip), 2927480 bytes
notmart has joined #linux-sunxi
<oliv3r>
ohh
<oliv3r>
wait
<oliv3r>
i think i see
<hno>
oliv3r, then it's a zImage in mkimage wrapper, not compressed at all as far as u-boot is concerned.
<oliv3r>
hno: oh hi!
<oliv3r>
hno: yeah the uzipping stage failed
leviathanch2 has quit [Ping timeout: 245 seconds]
<oliv3r>
hno: Uncompressing Kernel Image ... Error: Bad gzipped data
<oliv3r>
GUNZIP: uncompress, out-of-mem or overwrite error - must RESET board to recover
<mnemoc>
printf %0X 2927480
<mnemoc>
2CAB78
<mnemoc>
not that big to be truncated
<mnemoc>
ow
<oliv3r>
yeah it's really small
<oliv3r>
i'll manually load it
<oliv3r>
yeah it's not the size
<oliv3r>
u-boot is very recent sunxi-u-boot
<oliv3r>
i don't recall needing a 'special' u-boot
sehraf has joined #linux-sunxi
<oliv3r>
my old 3.4 uImage bots fine at the same address
philippe_fouquet has quit [Remote host closed the connection]
<oliv3r>
rellla: why do we need IF at all for the bananapi
<oliv3r>
what does the bananapi does differently with the gmac then the cubietruck
<oliv3r>
cubietruck has gmac support doesn't it?
<oliv3r>
rellla: what PHY did the yput on the bananapi?
<oliv3r>
mripard: nvm i was using a kernel image with (wrongfully?) dtb appended
Andy-D has joined #linux-sunxi
Quarx has joined #linux-sunxi
Renard has joined #linux-sunxi
<hno>
oliv3r, odd. that should not happen. u-boot verifies the image before starting it.
<hno>
oliv3r, I guess bad things can happen if you both load a dtb and append one.
<oliv3r>
yeah, very strange
<oliv3r>
but i know that the dtb is wrongfulyl appeneded
<oliv3r>
i think i append the dtb to the zImage, and then call mkimage on it
<hno>
should work I think. But explicitly loaded dtb is better.
<oliv3r>
yeah that should work
<oliv3r>
hno: what about filename length?
<hno>
what filename?
<hno>
it's just blobs loaded into memory.
<hno>
or in mkimage case, blob wrapped in a checksum, loaded into memory and then copied somewhere else.
<oliv3r>
uImage-sun4i-a10-olinuxino-lime
<oliv3r>
that's the only thing i can imagine
<libv>
rellla: yes
<rellla>
oliv3r: RTL8211E - must find out what the code is really for
<oliv3r>
rellla: sounds the same as on the ct; so that patch is bogus; the code is probably usefull to a certain extend
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
<mripard>
=vi2
<mripard>
...
<oliv3r>
you writing vim2? D:
<oliv3r>
hno: working now, dont' ask me what i changed :p
<oliv3r>
ohh, mainline kernel with mmc support, it is so sweet it hurts my nipples
<mripard>
oliv3r: I was aiming at /window 2 :)
<oliv3r>
mripard: if i say, i want to release a product in april, with sunxi-mainline kernel, how crazy do you think I am?
<oliv3r>
mripard: with 3.4 being the alternative
<mripard>
oliv3r: it depensd on what features you need
<oliv3r>
mripard: well uart, usb, CPU
<oliv3r>
mripard: spi is strongly favored, but we can always fallback to uart; the only thing that's trouble is NAND
Gerwin_J has joined #linux-sunxi
<oliv3r>
mripard: but 3.4 is causing me too many worries, so i rather spend time porting libnand to mainline, if mtd isn't an option
<hno>
polishing the mtd support is an option I would say.
<oliv3r>
mripard: reg-fixed-voltage ahci-5v: could not find pctldev for node /soc@01c00000/pinctrl@01c20800/ahci_pwr_pin@1, deferring probe is that bad?
<oliv3r>
hno: well the u-boot bit is iffy atm
<oliv3r>
hno: but bbrezillon's mtd patches are comming along very nicely
<oliv3r>
hno: i'm just slightly worried about stability/reliability
<oliv3r>
hno: but even with 3.4 i'd have to port the libnand patches to u-boot, i'm not going to rely on livesuit/boot0/boot1
<oliv3r>
hno: for one, boot0/boot1 will boot some 'standby' mode etc, powerbutton won't be easily accessible
Gerwin_J has quit [Read error: Connection reset by peer]
Gerwin_J has joined #linux-sunxi
<mripard>
oliv3r: hmmm, given how the maintainer answers, I'd say that expecting the NAND support to be fully merged by february
esperegu has joined #linux-sunxi
<oliv3r>
mripard: but do we know if it'll perform well enough
<oliv3r>
mripard: and then there is the u-boot stuff sitll missing
<oliv3r>
but
<oliv3r>
hno said he wants to put more time into sunxi again ;)
<mripard>
oliv3r: we don't, because no one ever cared to test it
<mripard>
and well enough is subjective I'd say.
<oliv3r>
mripard: well once the patches look good enough; i can setup a few batches
<esperegu>
I want to use hardware acceleration on a banana pi. when I run the test program it saids: libEGL warning: DRI2: failed to open lima (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri)
<oliv3r>
mripard: i'm sure there's plenty of 'tools' to do that, come november, i should have access to 50 a20 lime's
<esperegu>
anyone knows how to fix that?
<oliv3r>
esperegu: better try #bananapi
arokux has joined #linux-sunxi
<esperegu>
oliv3r: thats almost empty ;-)
<oliv3r>
mripard: i'll drop a post on our ML and LAKML for help on setting up a good test 'lab' for that
<mripard>
Cc bbrezillon on that
<oliv3r>
esperegu: well they made the image probably, so they should help you ;)
<oliv3r>
mripard: aye
<mripard>
he's our MTD expert :)
<oliv3r>
mripard: actually i'll do that mail out now, LAKML doens't require subscription does it
<esperegu>
oliv3r: rofl... in that channel: <wigyori> esperegu: you better try #linux-sunxi
<oliv3r>
wigyori: don't tell people to come here with vendor generated images ;)
<oliv3r>
esperegu: anyway, I see the word lima there, and as far as I know, lima isn't ready for 'users'. so if you can't fix problems yourself, don't use lima
<oliv3r>
libv: unless I missed something, in that case, you can slap me :p (^)
<libv>
esperegu: try using our wiki, and nothing else.
sehraf has quit [Ping timeout: 244 seconds]
<libv>
and yet another guy feels the need to dilute the contents of our wiki
<libv>
these banana pi things seems to draw out the worst of the android type users
<libv>
rehashing our wiki, rehashing our packages
<oliv3r>
making a genuin mess out of things
<rellla>
libv: it seems to become a problem, that this bananapi thing doubles and reinvents linux-sunxi wiki and repos atm. everywhere links to linux-sunxi are placed. i never heard of any "official" bpi people to join here, ml or elsewhere to contribute to us
<oliv3r>
is bpi a chinese thing?
<libv>
oliv3r: afaict, yes
<libv>
rellla: their wiki only has had spam for the last 5 months, so that is not an issue atm
Andy-D has quit [Ping timeout: 245 seconds]
<libv>
it's only bpi users atm who assume that we are the official support channel for bpi
<libv>
and that we should support them with bpi specific howtos and stuff
<libv>
rellla: i just looked at that thing going 150 days back
<libv>
spam over the summer, actual content in april, but nothing much back in april
<libv>
oh, i looked at bananapi.org
<libv>
would that really be different?
<libv>
urgh
<rellla>
bpi seems for me like popping up, using the "PI" as a marketing ...
<rellla>
libv: this is the problem, because there are too much scammers, that want to jump on the wave
petr has quit [Remote host closed the connection]
<libv>
"We now have about 30 people in the LeMaker team, some of whom are open source aficionados."
<rellla>
for me it looks like a bit out of control
<libv>
well, there's nothing for it but to remind people that we do not offer support for howtos that are not on our wiki
petr has joined #linux-sunxi
<libv>
(and some random whining about how bad some bpi users are)
<rellla>
recently some guy joined our wiki, that seems to one of lemaker
<libv>
yes, i noticed
leviathanch2 has joined #linux-sunxi
<libv>
i should actually still create his user page.
<libv>
same guy who edits the lemaker wiki
<rellla>
deleted one of the scam-pages...
<rellla>
the story is compareable with cubie imo. with a delay of two years :p
<libv>
not really
<libv>
cubie worked with mnemoc
<libv>
on making sure this the open source/community angle would be covered
<libv>
cubie was never such a direct rip off of raspberry pi, it just was aiming for the same market
<rellla>
libv: yeah, cubie introduced allwinner, bpi just wants to earn the fruits
nabblet has joined #linux-sunxi
<rellla>
i meant compareable with their presentation on the market. internet. own forum, wiki etc. - in a way
<rellla>
what is/ was completely different is the intention and the way they started
* rellla
hopes, that his user page gets never edited by libv :p
naobsd has quit [Quit: Page closed]
Andy-D has joined #linux-sunxi
<esperegu>
libv: the only difference on that page compared with the wiki seems to be the version of the xf86-video-fbturbo. still get the same error ;
<libv>
rellla: i hate _all_ bpi users, especially those that ndhed the thing! ;p
<esperegu>
;-(
<rellla>
libv: bpi users hate _all_ libvs, that prefer ndh'ing to code finishing :p
<wigyori>
oliv3r: yeah, this guy didn't say at all what image he's using ;p
<oliv3r>
wigyori: evnil!
<esperegu>
rellla: whats ndh ?
<rellla>
\o/
<libv>
rellla: wrong :p
<libv>
rellla: s/bpi/all/
<wigyori>
oliv3r: blame zoobab for that channel - i'm not in the bpi team (neither i want to be with all the shit they're doing)
<wigyori>
:)
<libv>
wigyori: yeah, we should play the same trick like we did with marsboard and such
<oliv3r>
wigyori: zoobab? Benjamin from belgium?
Andy-D has quit [Read error: Connection reset by peer]
<libv>
and register it, and set ownership to the linux-sunxi channel owners
<wigyori>
oliv3r: yep :)
<oliv3r>
wigyori: well he should support bpi then!
<wigyori>
he'd love to do i believe
<wigyori>
libv: pointers go to zoobab for that - i'm not against it
<wigyori>
although i got hw from them to put openwrt on to it, i don't like the shit they're doing on their forums
<oliv3r>
wigyori: ah right, your the openwrt dev right?
<oliv3r>
wigyori: do we have sdcard images with BB-r3? i wanted to experiment the other day
<wigyori>
one of the openwrt devs
<wigyori>
oliv3r: bb-rc3 for sunxi?
<oliv3r>
wigyori: how do you handle wifi support? preinstall the usb modules of the common stuff?
<oliv3r>
wigyori: barrier-breaker yeah
<wigyori>
oliv3r: bb is based on 3.10.49 - backporting stuff there is a path which i didn't want to go :)
<oliv3r>
wigyori: yeah that's fine as well
<oliv3r>
wigyori: ohh, you mena they use 3.10 by default, can't you just use mainline kernel instead?
<wigyori>
for the wifi support, it's handled when you select the board profile, the correct wifi module gets selected and installed into the rootfs
<wigyori>
oliv3r: separate bb and trunk
<oliv3r>
wigyori: so only 'trunk' images
<oliv3r>
wigyori: yeah so that means no pre-compiled images
<wigyori>
there are daily snapshots, but that only covers the kernel and a rootfs, no sdcard image generation yet (have to figure out how to trick the buildbot into selecting the profiles and going through them)
Gerwin_J has quit [Quit: Gerwin_J]
<wens>
mripard: turns out the local electronics stores don't have any SPI hardware :(
<oliv3r>
wens: what are you after?
<esperegu>
On the wiki I see references to lima but also the issue 'libEGL warning: failed to create a pipe screen for Mali DRI2'. I get 'libEGL warning: DRI2: failed to open lima' instead. I am using Raspbian_For_BananaPi_v3.1. if anybody can give me a hand it is very much appreciated.
<wens>
oliv3r: anything supported to test SPI
<wens>
you'd think with this arduino craze there'd be something available
<mripard>
wens: :(
<mripard>
wens: you should move to china ;)
<libv>
esperegu: the libegl warning is from the xorg.0.log
<libv>
and that is benign
leviathanch2 has quit [Ping timeout: 246 seconds]
<wens>
mripard: prefer not to :p
<libv>
esperegu: you are just randomly spewing Xorg.0.log errors
<libv>
try running the test and seeing what that says
<esperegu>
libv: sorry. I meant the second line: libEGL warning: DRI2: failed to open Mali DRI2
<libv>
esperegu: i doubt that it says that
<libv>
esperegu: run the test, see what that states.
<wens>
probably have to dig harder
<esperegu>
libv: that is the error on the wiki. mine saids lima
<esperegu>
Purging configuration files for libegl1-mesa:armhf ...
<mripard>
oliv3r: the sysfs gpio interface will mux it automatically for you
<wens>
oliv3r: uh think of pinmux and gpio as separate things
<wens>
they just happen to be intertwined on sunxi
<libv>
ah, stable
naobsd has joined #linux-sunxi
<oliv3r>
mripard: ah okay; so if I want to setup a pin as a regular GPIO, i don't have to define it at all? or can I to guarantee its setup properly?
<libv>
esperegu: that sounds pretty ok
<oliv3r>
wens: well you have to mux a gpio to be either in or out though?
<wens>
oliv3r: iirc it defaults to in after you export it, then you use sysfs to change it to out
<oliv3r>
wens: ah allright
<oliv3r>
so if I want/need a gpio in my final design, wouldn't it make sense to have it defined and claimed in the dts?
<wens>
oliv3r: you need a driver to claim it :p
<oliv3r>
gpio driver? :D
<oliv3r>
ok, so gpio's just stay undefined; go tit
<wens>
if you're just using it from userspace
leviathanch2 has joined #linux-sunxi
<wens>
i mean you could add something to the dt, but without a driver to claim, it does nothing
<oliv3r>
okay, makes sense
<oliv3r>
wens: in a few weeks/months, i'll have to write a driver, that'll work over SPI, needing a pin to generate an interupt (EINT24) so that needs to be defined and a pin as SlaveSelect (regular GPIO) and since the driver then can claim it, i'll have to add it to the dtsi, correct?
<wens>
SPI drivers and board specific pins would be in your board DT
<oliv3r>
exactly
<oliv3r>
well except that you don't put drivers in the DT
<wens>
for the interrupt, you could use gpios or interrupts directly
<oliv3r>
wens: with gpio you mean a poll on a input pin?
<wens>
i don't think we ever tested using EINTs with interrupts though
<oliv3r>
wens: i assumed that we should use EIN mux
<wens>
oliv3r: claim the gpio, then call gpio_to_irq
<oliv3r>
wens: well when i start to write the driver stuff; i'll be testing that ;p
<wens>
the pinctrl/gpio driver then muxes to EINT
<oliv3r>
ah, ok
<esperegu>
# modprobe sunxi_cedar_dev
<esperegu>
FATAL: Module sunxi_cedar_dev not found
<esperegu>
does this mean my kernel does not support it?
<oliv3r>
esperegu: you did not compile in cedarX module into your kernel
<esperegu>
(trying to get vdpau to work)
<esperegu>
oliv3r: that can be done separately? or needs totally new kernel?
afaerber has quit [Quit: Verlassend]
<oliv3r>
esperegu: ask whoever compiled your kernel for you
<oliv3r>
esperegu: really, if you can't fix these very simple things yourself, you really should ask the supplier of your image
<oliv3r>
esperegu: you are going up a steep hill this way ;)
<mripard>
wens: hans did, and it works
<esperegu>
oliv3r: I know. I just need to get this last piece going and then someone else takes over.
<mripard>
(gpio as interrupts, directly)
<oliv3r>
mripard: via the EINT mux?
<mripard>
yep
<wens>
hmm, i thought he used gpio_to_irq for brcmfmac
<oliv3r>
mripard: any reason why not all uart pins are defined for (for example) sun4i-a10.dtsi?
<mripard>
wens: I can't remember for what it was :/
<oliv3r>
mripard: i mean, i can add what I know/am testing now if a patch for that is welcome
<mripard>
oliv3r: no one bothered?
<oliv3r>
mripard: shall I add all pin definitions that are in the datasheet, or only 100% tested and verified ones
leviathanch2 has quit [Ping timeout: 260 seconds]
<oliv3r>
well we have pwm0 and pwm1 pins in the dtsi, and we don't have the driver even merged yet, so i'll go by the datasheet for now ;)
<mripard>
oliv3r: please, don't do all of them
<mripard>
it has some DT size and parsing time cost
<oliv3r>
mripard: so 'becasue noone bothered' isn't the reason then ;)
<oliv3r>
mripard: i'll add the ones i tested and verified to work then?
<wens>
i think we add the ones people actually use :)
<oliv3r>
i would have thought that the pinctrl stuff where only definitions and the dtsi compiler would only include code for what was in the final dts
<wens>
or at least, are clearly available on boards
<oliv3r>
wens: well the devboards such as the lime exposes a lot of pins
<mripard>
wens: exactly
<wens>
oliv3r: the DTC doesn't do pruning :p
<oliv3r>
so those are all in theory some that are clearly available and people could be using
<oliv3r>
we have little users as little people use the mainline kernel
<oliv3r>
wens: it should prune ... :p
<oliv3r>
because now, we don't add pins for available broken out pins simply because the DTC doesn't do pruning
<mripard>
wens: there were some patches to do that, I wonder whether they were merged
<mripard>
oliv3r: no, we don't add pins because no one uses them
<mripard>
oliv3r: it comes at a cost. I'm fine with adding them if they are useful
<oliv3r>
you said a second ago, don't add them because of memory cost
<oliv3r>
or just cost
<mripard>
but if it's just going to be some dead node in the DT, it's not worth it.
<oliv3r>
i doubt many people use lime's with mainline for now
<oliv3r>
but in the future, we'll have to add pretty much all pins anyway
<oliv3r>
but i'll only add the pins i use ;)
<mripard>
that's not very true. All the designs are very similar, and there's just a few options that covers most of the designs
<mripard>
and for the lime, the DT overlays would be more appropriate
hypothalamus has quit [Ping timeout: 246 seconds]
<oliv3r>
mripard: then the dt system is a bit confusing. i would expect that the sun4i-a10.dtsi has all pins etc defined, and each board just says 'okay' to what is has. (and things as ahci-> power bindings etc)
<mripard>
what?
<oliv3r>
it sounds like something to get very messy and much duplication amongst boards
<oliv3r>
well lets take uart5 pins for example
<wens>
oliv3r: think of it as a C file including another C file
<wens>
the dtsi is another C file, not a header
<oliv3r>
wens: yeah
<oliv3r>
exactly
<oliv3r>
so going with uart5 as an example
<oliv3r>
if i put it in the a10-sun4i-lime.dts, as mripard said, appropiate overlay
<oliv3r>
and it's also in the a10-sun4i-lime-v2.dts
<oliv3r>
and also in the marsboard, and also in the cubieboard
<oliv3r>
i would have expected it all in the sun4i-a10.dtsi
<mripard>
cool
<oliv3r>
since we can't change the pins anyway
<mripard>
now, takes uart0
<oliv3r>
yeah uart0 is defined in sun4i-a10.dtsi :)
<mripard>
hmmm, no, uart0 is a bad example....
<mripard>
thing is
<mripard>
the muxing is board specific
<mripard>
it really is.
<mripard>
no matter how common it is
<mripard>
you will *always* have a board wired differently
<oliv3r>
on 'regular' boards i'd agree, but what about dev boards
<wens>
i think the policy(?) is to put the functional pin sets (things tied to hardware block) in the dtsi
<oliv3r>
where there's pinheaders breakout out pins
<mripard>
on dev boards, it's just the same.
<wens>
but you reference the pin sets in the board / end dts
<oliv3r>
damnit, traincatching time
afaerber has joined #linux-sunxi
<mripard>
this information has nothing to do in the SoC part
<oliv3r>
but i'll have to rethink the policy bit :)
<mripard>
because it's not soc specific
<mripard>
it's board specific.
<oliv3r>
well so why is uart0, i2c, spi1 pins defined at the 'soc specific' level?
<mripard>
really.
sehraf has joined #linux-sunxi
<mripard>
because the SoC provides some combinations.
<mripard>
a board use one.
<wens>
oliv3r: the SoC provides the options, the board chooses
<oliv3r>
so really, the uart0 pins should be in the board files, not the soc file
<mripard>
no.
<oliv3r>
wens: yeah but that's exactly what i said earlier
<oliv3r>
im talking about stuff like uart2_pins_a: uart2@0 {
<wens>
oliv3r: what i meant about _board specific_ pins are things like gpios, usb vbus, mmc card detect and stuff
<oliv3r>
just to make sure we're talking about the same thing :)
<mripard>
we do.
<wens>
oliv3r: uart2_pins_a: uart2@0 { this goes in the dtsi
<mripard>
there's a few pins that are routed to uart2
<mripard>
the DTSI list them
<mripard>
and then, the board will use only one of them.
<wens>
and you might get uart2_pins_b: uart2@1 { for a different mux
<mripard>
and hence, the board has to choose it.
<wens>
in the board DTS, under uart@01xxxxxxx { you have pinctrl-0 = &uart2_pins_a; }, which chooses which pinmux it uses
<wens>
so we list the possible combinations in the dtsi _if_ some dts actually uses it
xinj has quit [Ping timeout: 244 seconds]
tomboy65 has quit [Ping timeout: 264 seconds]
leviathanch2 has joined #linux-sunxi
<oliv3r>
wens: you are disagreeing with mripard though
<oliv3r>
ok that _if_ some dts actually uses it makes up for that :p
<oliv3r>
so here is where it gets iffy
<oliv3r>
with athe lime, you have all pins configured as gpio's
<mripard>
oliv3r: no, wens and I are exactly on the same page :)
<oliv3r>
so am I
<oliv3r>
the only thing you are saying though is, don' tput all pins in the dtsi because of resource cost
<wens>
i think mripard meant all pins the soc has
<oliv3r>
so in the case of my project, i define a shield.dts, that includes the board.dts; which includes the soc.dtsi
<oliv3r>
in my shield i say i need uart5, the board doesn't care, and the soc doesn't have it
<oliv3r>
so we now add it to the soc.dtsi
<oliv3r>
but we only add it now, because of resource cost
<oliv3r>
so it all makes sense now :)
<wens>
:)
<wens>
the only pins you do define in your dts are the gpios specific to your board
<oliv3r>
yeah udon't confuse me with gpios now :p
<wens>
like the ahci power and usb vbus pins in the cubietruck
<oliv3r>
but adding that to the mix,only gpio's that a driver claims
<oliv3r>
yeah and those
<oliv3r>
right, in train, changing stations now :)
<wens>
bbl
oliv3r_phone has joined #linux-sunxi
<oliv3r_phone>
and i hate mu laptop for refusing to go into atandby
xavia has joined #linux-sunxi
<oliv3r_phone>
hibernate luckily works ;)
rafaelMOD has joined #linux-sunxi
Andy-D has joined #linux-sunxi
naobsd has quit [Quit: Page closed]
<ganbold_>
wens: did you say that A20 GMAC is Synopsys DesignWare GMAC?
philippe_fouquet has joined #linux-sunxi
hypothalamus has joined #linux-sunxi
oliv3r_phone has quit [Ping timeout: 260 seconds]
Skaag has quit [Quit: Leaving.]
<wens>
ganbold_: that's right
xinj has joined #linux-sunxi
rafaelMOD has quit [Ping timeout: 245 seconds]
oliv3r_phone has joined #linux-sunxi
sehraf has quit [Ping timeout: 246 seconds]
<oliv3r_phone>
i hate our tains
<oliv3r_phone>
first, the one doesnt wait for the other
leviathanch2 has quit [Quit: No Ping reply in 180 seconds.]
<oliv3r_phone>
but that is normal, now the next one is delayed by 15minutes
<oliv3r_phone>
and still it wont wait
tomboy65 has joined #linux-sunxi
hypothalamus has quit [Ping timeout: 244 seconds]
<wens>
wait for the other?
<oliv3r_phone>
thats 30minutes of waiting :(
leviathanch2 has joined #linux-sunxi
<oliv3r_phone>
so i lwft an hour early from work
<oliv3r_phone>
to be homw early
<oliv3r_phone>
just to spend it waiting, may as well have stayed at work and got payed
<wens>
:(
<wens>
afaik our commuter trains are never on time
<wens>
subways are nice, but don't go too far out of town
oliv3r_phone2 has joined #linux-sunxi
oliv3r_phone has quit [Ping timeout: 250 seconds]
<oliv3r_phone2>
ok thebyou are worse off :p
leviathanch2 has quit [Quit: No Ping reply in 180 seconds.]
<oliv3r_phone2>
i guess that is the price to pay for having an awesome job i guess
<wens>
i live 2 subway stops away :p
<oliv3r_phone2>
bitch!
leviathanch2 has joined #linux-sunxi
<oliv3r_phone2>
2 trains a bike ride and a 10 walk
<oliv3r_phone2>
75minutes
<wens>
down side is rent is expensive :/
<wens>
i guess i just dont like spending time commuting
naobsd has joined #linux-sunxi
<oliv3r_phone2>
heh, i live in an okay place, i go to a really small suburb/middle of nowhere town
<oliv3r_phone2>
commuting i dint mind, unplanned delays i hate
nabblet has quit [Quit: leaving]
xinj has quit [Ping timeout: 244 seconds]
sehraf has joined #linux-sunxi
rafaelMOD has joined #linux-sunxi
Andy-D has quit [Ping timeout: 272 seconds]
syeekick has joined #linux-sunxi
Nyuutwo has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 246 seconds]
Nyuutwo has quit [Ping timeout: 246 seconds]
Nyuutwo has joined #linux-sunxi
oliv3r_phone2 has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
Skaag has joined #linux-sunxi
Nyuutwo has quit [Read error: Connection reset by peer]
Skaag has quit [Client Quit]
Nyuutwo has joined #linux-sunxi
syeekick has quit [Ping timeout: 246 seconds]
wingrime has joined #linux-sunxi
wingrime1 has quit [Read error: Connection reset by peer]
wingrime1 has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
Skaag has joined #linux-sunxi
HeHoPMaJIeH has quit [Quit: Konversation terminated!]
wingrime1 has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
Skaag has quit [Client Quit]
paulk-collins has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
Andy-D has quit [Read error: Connection reset by peer]
sehraf has quit [Ping timeout: 246 seconds]
alexvf has quit [Quit: Page closed]
Nyuutwo has quit [Ping timeout: 246 seconds]
Skaag has joined #linux-sunxi
Skaag has quit [Max SendQ exceeded]
Skaag has joined #linux-sunxi
syeekick has quit [Read error: Connection reset by peer]
hypothalamus has quit [Ping timeout: 258 seconds]
sehraf has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
konradoo77 has joined #linux-sunxi
notmart has quit [Quit: notmart terminated!]
_massi has quit [Quit: Leaving]
sehraf has quit [Ping timeout: 244 seconds]
bsdfox_ has joined #linux-sunxi
sehraf has joined #linux-sunxi
diego_r has quit [Read error: Connection reset by peer]
diego_ has joined #linux-sunxi
diego_ is now known as diego_r
arokux has quit [Remote host closed the connection]
arokux has joined #linux-sunxi
diego_r has quit [Read error: Connection reset by peer]
arokux1 has joined #linux-sunxi
arokux has quit [Remote host closed the connection]
arokux1 has quit [Remote host closed the connection]
arokux has joined #linux-sunxi
arokux has quit [Remote host closed the connection]
arokux has joined #linux-sunxi
bengal has joined #linux-sunxi
diego_r has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 260 seconds]
diego_r has quit [Read error: Connection reset by peer]
konradoo77 has joined #linux-sunxi
diego_r has joined #linux-sunxi
ninolein has quit [Ping timeout: 245 seconds]
ninolein has joined #linux-sunxi
sehraf has quit [Ping timeout: 244 seconds]
pwhalen has quit [Quit: Leaving]
pwhalen has joined #linux-sunxi
sehraf has joined #linux-sunxi
afaerber has quit [Quit: Verlassend]
konradoo87 has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 250 seconds]
amitk has quit [Quit: leaving]
paulk-aldrin has joined #linux-sunxi
Getty has joined #linux-sunxi
<Getty>
AH I SEE 8-)
afaerber has joined #linux-sunxi
sehraf has quit [Ping timeout: 246 seconds]
<hno>
Ok, A80 board arrived in good condition, but no sources or any other information at all. Have only board + UART cable + power.
<libv>
hno: ndh :p
<libv>
it's not as much work as you think
<libv>
most work is getting good pictures
<libv>
and i personally tend to do about a third of the work anyway
Nyuutwo has joined #linux-sunxi
sehraf has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
konradoo87 has quit [Ping timeout: 258 seconds]
Nyuutwo has quit [Quit: No Ping reply in 180 seconds.]
Nyuutwo has joined #linux-sunxi
<hno>
libv, will do.
<hno>
And no I do not think it's much work. But I disagree on flaming people who try.
TheSeven has quit [Ping timeout: 272 seconds]
TheSeven has joined #linux-sunxi
<libv>
hno: *sigh* this jason fellow wasn't trying, at least he wasn't trying to work through things, he was however trying hard to not have to do any work himself
<libv>
hno: but thanks, and about the manual build howto section there, refer to the A80_Manual_build_howto
<libv>
at some point that one will gain actual content
Renard has quit [Remote host closed the connection]
bsdfox has joined #linux-sunxi
TheSeven has joined #linux-sunxi
<pistoletov>
or registration of domain ended
TheSeven has quit [Ping timeout: 272 seconds]
TheSeven has joined #linux-sunxi
Renard has joined #linux-sunxi
sehraf has quit [Ping timeout: 246 seconds]
pistoletov has quit [Quit: Ухожу я от вас (xchat 2.4.5 или старше)]
pistoletov has joined #linux-sunxi
esperegu_ has quit [Remote host closed the connection]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
esperegu has joined #linux-sunxi
sehraf has joined #linux-sunxi
Fusing4 has joined #linux-sunxi
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
paulk-aldrin has quit [Quit: Ex-Chat]
<lauri>
Hi guys
<lauri>
anyone interested in bounties? :P
<lauri>
Basically I need to get hardware accelerated video working in Chromium. Even if we would get Chromium to pipe video stream to VDPAU the backend would need some work as currently cedar doesn't support decoding multiple streams simultaneously
<lauri>
(Consider user opening up several videos in multiple tabs)