<arokux2>
steev, at the reference, KLIB can be whatever dir I want?
<arokux2>
Turl, I was very glad he picked my mail...
<steev>
arokux2: yes, but if you do make install, it will install the firmware to your host system - personally i do a git clone of the linux-firmware git tree so idgaf about the firmwares
<arokux2>
steev, i do not need firmware anyway, only one file and it hasn't changed.
<steev>
klib should point to your rootfs
brain_ has quit [Ping timeout: 245 seconds]
<steev>
but yeah, it can be anywhere you have write permission
<steev>
you'll have to run depmod -a yourself after you copy them into the rootfs, and you'll need to copy those files yourself as well (why i suggested klib = rootfs)
Seppoz has joined #linux-sunxi
<deasy>
arokux1, English people can't read French ?
* deasy
trolling arokux1
<deasy>
good night :p
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
CoSM0 has quit [Read error: Connection reset by peer]
CoSM0 has joined #linux-sunxi
shineworld has quit [Quit: Leaving]
derethor has joined #linux-sunxi
<leviathanch>
arokux1: hi
leviathanch has left #linux-sunxi ["http://quassel-irc.org - Chat comfortably. Anywhere."]
leviathanch has joined #linux-sunxi
<leviathanch>
mripard: hi, i've got a problem with DMA and MMC... according addresses
<leviathanch>
mripard: obviously the kernel allocates virtual memory with the DMA functions, and then pushes the virtual address into the register of the IDMAC register of the MMC modules
<leviathanch>
mripard: unfortunately the the MMC module then requests this virtual address at the DMA controller, which doesn't know anything about this address since the one holding the table isn't the controller but the CPU
<leviathanch>
mripard: which leads to a time out...
<leviathanch>
-.-
gnufan has joined #linux-sunxi
hramrach has quit [Remote host closed the connection]
CoSM0 has quit []
<arokux1>
leviathanch, hi..
<arokux1>
leviathanch, wow, how you found out all this?!
<arokux1>
leviathanch, I've pinned down my usb problems (the ones I know about) to 230 LOC. today in the evening I'll know the truth.
rellla2 has quit [Ping timeout: 260 seconds]
<hno>
oliv3r, full name even in the agenda.
<oliv3r>
hno: haha, yeah but i allready said i wasn't going ; just asking a question, which brought up a lot of debate, so that's good
<oliv3r>
and important to sunxi's future :)
<nedko>
hno: where can i get the yuq mtd branch?
<hno>
leviathanch, virtaul addresses needs to be mapped to physical addresses before given to DMA controllers.
<leviathanch>
hno: i know, but I think there isn't anything given to the DMA controller in linux-next
<leviathanch>
hno: that's exactly the problem
<arokux1>
leviathanch, how do you know that? it could be my problem too!
<leviathanch>
arokux1: because all the other arches have DMA specific atomics
<leviathanch>
arokux1: sunxi is missing them
<hno>
leviathanch, is there a sunxi dma driver in linux-next?
<arokux1>
leviathanch, this is what is called DMAengine?
<leviathanch>
hno: no
<leviathanch>
yes
<leviathanch>
hno: also there is no device tree entry for a dma controller for sunxi
<leviathanch>
...
<arokux1>
leviathanch, I've thought mmc has an internal one?
Cubear has joined #linux-sunxi
<arokux1>
arch/arm/plat-sunxi/devices.c
<arokux1>
leviathanch, ^
<hno>
right, yes. MMC have an internal DMA controller.
<arokux1>
something about dma
<arokux1>
USB also has internal dma
<hno>
leviathanch, AW mmc driver uses sg_dma_address() to translate buffers to DMA address in the MMC DMA descriptors.
<arokux1>
hno, I'm do not know anything about this DMA stuff.. how do you think, are there something connected to dma that could make usb stack to fail?
<hno>
arokux1, if there is mapping errors then results will be odd..
<arokux1>
hno, this code is known to work: http://sprunge.us/BBPj?c no dma staff here except of masks, which I also set.
<arokux1>
hno, I'm going to put this code into mainline and see what happens.
<arokux1>
hno, as you see only 227 LOC there. bare minimum.
tinti_ has joined #linux-sunxi
<hno>
arokux1, if DMA is not used then there is no need for any physical DMA address mappings.
<hno>
arokux1, is the copyright on that one correct? Kind of would expect your(?) and based on ...
<leviathanch>
arokux1: this doesn't exist in the linux-next revision I'm working on
<leviathanch>
arokux1: are you using the linux-next master?!
<arokux1>
leviathanch, no-no, this is from sunxi-3.4!!!
<arokux1>
hno, this is unpublished and just stripped down version of a usb ehci bus glue driver
<arokux1>
hno, I wanted to have a *bare minimum* that still works with wifi.
<leviathanch>
ok
<arokux1>
hno, "if DMA is not used" <---- how do I know that? well, I do not have any dma calls, but maybe usb stack has them?
<leviathanch>
the problem is
<leviathanch>
I have to tell the DMA controller to map physical scatter list to a virtual address
<leviathanch>
then giving this virtual address to the internal controller of the mmc device
<leviathanch>
if the mmc device now requests access to this address I gave it
<leviathanch>
but the kernel never told the dma controller about the allocation
<leviathanch>
everything is going to crash and burn
<leviathanch>
-.-
<leviathanch>
all the reference code is using DMA
<leviathanch>
the central DMA controller
<leviathanch>
and since there is no documentation about the internal DMA controller available
<arokux1>
leviathanch, one question.. if I do not have dma calls, am I affected by this?
<leviathanch>
yes
<leviathanch>
maybe
<leviathanch>
since it hasn't to be your driver itself which does the calls
<leviathanch>
it may very well be done on a higher level
<arokux1>
leviathanch, good to know... tonight I'll know if those 227 LOC work in mainline. I've ruled out wifi driver already, thanks to steev I was able to try out the rtlwifi from 3.10 in 3.4 and it still worked.
<leviathanch>
hmm
<leviathanch>
arokux1: some addresses you get out of pdev may very well have been allocated by dma calls on a higher abstraction layer
<leviathanch>
and may be bogus
<arokux1>
leviathanch, can I put some printk noise into sunxi-3.4 to see if it uses any dma stuff?
<leviathanch>
uhm
<arokux1>
leviathanch, maybe you can tell where should I put, if yes..
<leviathanch>
yeah
<leviathanch>
wait
<arokux1>
leviathanch, great!
<leviathanch>
dma_map_sg for arm
<leviathanch>
linux/dma-mapping.h includes it
<leviathanch>
for instance
<leviathanch>
if it is being called without an actual DMA engine being informed about the allocation
<leviathanch>
you are fucked
<leviathanch>
>_>
<arokux1>
leviathanch, usb stack calls this func
<leviathanch>
Linux is very well capable to emulate DMA itself in software on platforms where it isn't supported in hardware
<leviathanch>
arokux1: hehe
<leviathanch>
ok, there we have the problem
<leviathanch>
it does scatter gatter
<leviathanch>
given the usb module expects the DMA module to know the virtual address alocating the scattered blocks
<leviathanch>
and tries to access the blocks over this address
<leviathanch>
it will fail
<arokux1>
leviathanch, usb storage works
<arokux1>
leviathanch, so it is subtle
<leviathanch>
arokux1: on sunxi or next?
<arokux1>
leviathanch, the question is where dma_map_sg calls some SoC specific funcs
<arokux1>
leviathanch, both.
<leviathanch>
arokux1: what patches do you have set?
<arokux1>
leviathanch, what?
<leviathanch>
do you have DMA patches for sunxi platform in your next branch?
<leviathanch>
and which version of linux-next are you working on?
<arokux1>
leviathanch, of course not.
<arokux1>
leviathanch, the one from mripard
Soru has quit [Read error: Connection reset by peer]
<arokux1>
leviathanch, are there any DMA patches for sunxi for -next???
Soru has joined #linux-sunxi
<leviathanch>
arokux1: that was the question I tried to ask you! ;-)
<arokux1>
leviathanch, no.. mripard will work on it later..
<leviathanch>
I was under the impression that the A1X-series would be using the default ARM DMA implementation
<leviathanch>
but obviously every single SoC needs his own definition
<leviathanch>
...
<arokux1>
leviathanch, my question is the following.. yes, usb stack calls dma_map_sg , but: does this function then internally need something that is soc specific??
<leviathanch>
obviously it does
<leviathanch>
arch/arm/plat-omap/dma.c
<leviathanch>
in linux-next
<arokux1>
leviathanch, so can I put some printk noise into sunxi-3.4 to verify it actually uses some chinese code?
<leviathanch>
yes
<leviathanch>
look out for any DMA specific code in context with sunxi
<leviathanch>
somthing like
<leviathanch>
git grep dma
<arokux1>
leviathanch, arch/arm/plat-sunxi/dma.c
<leviathanch>
ahh!
<arokux1>
(from sunxi-3.4)
<leviathanch>
this does exist?
<leviathanch>
explains a lot... -.-
<arokux1>
leviathanch, in 3.4!
<leviathanch>
yes
<leviathanch>
that's it
ykchavan has quit [Ping timeout: 256 seconds]
<arokux1>
leviathanch, hm..
<arokux1>
arch/arm/plat-sunxi/dma_route_sun4i.h
<leviathanch>
yes
<arokux1>
leviathanch, and some others *.h
<leviathanch>
if we do not provide a valid DMA controller device
<leviathanch>
the kernel will just do bogus DMA in software
<leviathanch>
in order for staying able to do scatter gatter
<leviathanch>
since they have merged this functionality into the DMA API
<arokux1>
leviathanch, can you mainline arch/arm/plat-sunxi/dma.c ? it is very small and you seem to know the stuf.
<leviathanch>
mainline dma.c won't be enough
<leviathanch>
we have to advertize it
<leviathanch>
and adapt it to device tree
<leviathanch>
"advertize" in the sense that the DMA framework needs to use it
<leviathanch>
as well
<leviathanch>
only being present won't be enough
<leviathanch>
:-)
<leviathanch>
but yeah
<leviathanch>
I can try integrating it into next
<arokux1>
leviathanch, yep, mainline = integrate
wingrime has quit [Ping timeout: 240 seconds]
<arokux1>
leviathanch, it can take some time :(
CoSM0 has joined #linux-sunxi
<arokux1>
leviathanch, how to be 100% sure the mainline needs this dma.c in order usb to work?
<leviathanch>
uhm
<leviathanch>
if it is doing a scattered list allocation
<arokux1>
you can see channels in dma_route_sun4i.h there is nothing about mmc or usb host (only usb otg)
<leviathanch>
and the usb module is doing DMA
<leviathanch>
it is 100% certainty
<leviathanch>
;-)
<leviathanch>
arokux1: it's also the other way around
<leviathanch>
it's hard wired stuff
<leviathanch>
these devices are all DMA clients
<leviathanch>
you only tell the DMA controller: get me some space together, where the usb host can put his data, I'll get it later
<leviathanch>
then the USB says: Hey! I'm done (IRQ)
<arokux1>
leviathanch, I see. and there shouldn't be any "channel" for that?
<leviathanch>
the issue is more
<arokux1>
leviathanch, because some devices have channels, as you see.
<leviathanch>
you can't tell the DMA controller what address you wanna have the USB controller to put his data
<leviathanch>
you just get a random address from the kernel sw layer
<leviathanch>
since there is no driver present
<leviathanch>
so the USB writes _anywhere_ if at all
<arokux1>
leviathanch, so either it is not yet unified or sun7i is different
<leviathanch>
which means we have to platformunspecify it
<arokux1>
leviathanch, I'm showing everything from 3.4
<arokux1>
leviathanch, not necessarily. maybe unification is possible. aw normally just creates new mach-sun7i from scratch and won't care to unify things
<arokux1>
leviathanch, sun4i, sun5i, sun7i -> sunxi is done by us
Soru has quit [Remote host closed the connection]
tinti_ has quit [Remote host closed the connection]
HeHoPMaJIeH has quit [Ping timeout: 248 seconds]
<arokux1>
leviathanch, ah, that is what you've said.
HeHoPMaJIeH has joined #linux-sunxi
<libv>
seems like the cubie guys are busy on rockchip these days
Black_Horseman has quit [Remote host closed the connection]
<n01>
libv: sorry for asking you. Any good resource for writing a fb driver? (OT)
<ssvb>
n01: using the documentation from allwinner and looking at the existing kernel drivers should be enough
<n01>
not for allwinner actually :)
<ssvb>
n01: there are some really simple basic drivers, which could be used as examples
<n01>
yep I'm studying vfb right now
<n01>
howto on fbdev is really outdated, but still useful I think
<oliv3r>
libv: actually, cubietech is working on cubietruck, tom cubie, is working on radxa, a rockchip board
<n01>
ssvb: the problem is that we are trying to fit in 10MB of RAM. So the idea was to use no X with the legacy fbdev.
ganbold_ has joined #linux-sunxi
<ssvb>
n01: maybe have a look at something like simplefb?
<n01>
ssvb: yeah even better than vfb
gnufan has left #linux-sunxi [#linux-sunxi]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<oliv3r>
doesn't simplefb require u-boot to setup the FB properly?
<oliv3r>
well for non-sunxi that's not a big issue
<n01>
oliv3r: I don't think so
Cubear has quit [Quit: Leaving]
notmart has quit [Remote host closed the connection]
notmart has joined #linux-sunxi
ykchavan has joined #linux-sunxi
tzafrir has quit [Ping timeout: 245 seconds]
leowt has joined #linux-sunxi
_enrico_ has joined #linux-sunxi
atiti has quit [Ping timeout: 252 seconds]
atiti has joined #linux-sunxi
hipboi has quit [Quit: Leaving]
<oliv3r>
craperdecrapcrap; didn't do any hacking today; too busy @ $work :(
rz2k has joined #linux-sunxi
<arokux1>
oliv3r, what r u doing at work?
<derethor>
i am afraid of the rockchip.. i seems that now many manufacturers are making devices with that chip
<derethor>
i am afraid on another platform.. .more devel, more bugs, more undocumented stuff, etc
<derethor>
but it is okey, rockchip is really cheap... i think $4 for a quadcore
<derethor>
would be great if allwinner makes a new GPU opensource, that would be fantastic
<mnemoc>
allwinner pays license for mali400 and for the pvr thing in A31 and it's successor
<derethor>
yep, and we must use the mali driver... i said that it would be great to see a new allwinner gpu, with opensource drivers, and people hacking and improving it
<mnemoc>
lima is RE, and ARM will not open source mali
<mnemoc>
hopefully the linux-rk community starts maturing soon
<rz2k>
since there are silence around, let me put a little spam: job offer for linux kernel programmer: fulltime in Moscow, target is BSP for preproduction ARM11 SoC and couple other SoCs (cant talk the details - NDA). Currently 3.8 kernel is ready, but still needs love, so they are hiring. Company is official ARM licensee - SoCs are developed here using ARMs IP cores.
<rz2k>
didnt have time to test everything on a20 though, please help if you have time.
<arokux1>
rz2k, do not have A20 yet, will have a CT soon.
<arokux1>
rz2k, benchmarks are very interesting. I wanted to compare radxa (RK, 4-core) to the allwinner based boards.
<rz2k>
post the results there if you can
<arokux1>
rz2k, I will once I have hw
<rz2k>
maybe we need to convert that page to a table also
<rz2k>
and run a phoronix openbenchmarking suite
<rz2k>
for cool looking graphics
leowt has joined #linux-sunxi
leowt has quit [Client Quit]
<arokux1>
rz2k, not much interested in graphics...
<libv>
rz2k: so far, for the glmark2-es2 tests that run, i hit +6-10% on X11
<arokux1>
libv, +6-10% vs. blob?
<libv>
and that is only like 66% of potential performance (like delivered by limare or the framebuffer drivers)
<libv>
arokux1: yes
<arokux1>
libv, serious??
<libv>
yes
mcbrick has joined #linux-sunxi
<arokux1>
libv, u'll be hired soon, I think :)
<rz2k>
libv: if you have time, please update the GPU section, it was created at sun4i times and r2p4
<rz2k>
so it is outdated like hell, looking at what you can get using display layers
<libv>
it might perform worse when the cpu is not set to performance though, as i think that part of that is due to more aggressive scheduling
<arokux1>
libv, ARM devs cann't be that stupid, can they? o_O
<libv>
might lead to higher battery usage or so
<libv>
arokux1: read my blog entry from june
<libv>
arokux1: ARM management seriously dislikes lima
<libv>
and doesn't care about open source software
<libv>
even though we will be able to get 106% where the binary now gets 66%
<libv>
rz2k: i will, when i have glmark2-es2 running properly on lima
<rz2k>
arokux1: they can, and the most sad part of it is that they are oficially "smartest" pals around. I've been poking Vivante drivers at work lately. They use DRI (the 1 version) and you need to have their DRI1 xf86 extension implementation or Xorg will not work with 3D.
<arokux1>
libv, once lima can be used ARM opinion won't be important, so ppl will either grab your driver or ARM should improve
<arokux1>
libv, you shouldn't be necessarily hired by ARM..
<libv>
arokux1: i have been in this business for a decade
<libv>
arokux1: and i have changed quite a few things, which pissed off quite a lot of people
<libv>
people at intel, redhat and amd, and then there's canonical or linaro which wouldn't touch me with a 10 foot pole
<libv>
and then there's all the companies which require one to relocate...
<libv>
arokux1: plus, i had 2% headroom over the binary at FOSDEM, and 6% in june.
<arokux1>
libv, how do you make your living now? if I may ask.
<arokux1>
libv, you seem to be working 100% on lima
ganbold_ has quit [Remote host closed the connection]
rellla has quit [Ping timeout: 240 seconds]
<libv>
arokux1: not at all, for the time being.
<libv>
arokux1: company culture and human inertia do not reward progress, especially progress gotten against the will of organizations or groups of individuals.
n01 has quit [Remote host closed the connection]
wingrime has joined #linux-sunxi
<arokux1>
libv, can one exploit Mali for computations?
<libv>
only the vertex shader, but that requires quite a lot of work
<libv>
fragment shader is halffloat only
<rz2k>
wingrime: check pm
wingrime has quit [Ping timeout: 256 seconds]
wingrime has joined #linux-sunxi
<mripard>
highlight overflow :)
<Turl>
ohai
wingrime has quit [Ping timeout: 268 seconds]
<mripard>
Turl: hi
wingrime has joined #linux-sunxi
<Turl>
mripard: mailbox overflow :)
<Turl>
mripard: how do you verify if HStimer works?
<mripard>
boot the board
<mripard>
if it boots, it works :)
<Turl>
my board already boots without it? :p
<mripard>
yeah, but it will be better!
<mripard>
and that was not your question, was it ? :)
panda84kde has quit [Quit: Konversation terminated!]
arokux2 has joined #linux-sunxi
<arokux2>
mripard, hey, have you read our dma discussion here? leviathanch has a suspicion DMA bits are needed for some devices to work
<mripard>
Turl: btw, do you know the frequency of AHB ?
<mripard>
I don't have any board at hand to check
<Turl>
mripard: axi/sth usually
<mripard>
arokux2: well, I didn't quite get why the MMC required the DMAengine
<mripard>
since it has its own dma controller.
<mripard>
Turl: yeah, but which rate ?
<Turl>
mripard: my initial set rate had a clk_summary print, rate should be there
<Turl>
initial clock series*
<arokux2>
mripard, usb stack has something like map_urb_to_dma.. do you think there are some bits missing from -next for it to work correctly?
<mripard>
Turl: right, thanks
<mripard>
arokux2: I have no idea what this function does, 2s.
<arokux2>
mripard, I see, the only thing is *dma* in its name
<ssvb>
libv: did you get dri2 working without cpu copy in your tests?
<arokux2>
mripard, it calls dma_map_sg. leviathanch said this one needs to be backed by a driver otherwise kernel will fallback to software emulation which (I do not know why) will fail/not work.
<arokux2>
mripard sorry, I'm learning as I go and try to get usb 100% working.
<mripard>
hmmm, it's actually not doing any dma related command unless you say that your driver can do DMA
<ssvb>
libv: 66% of the hardware capabilities sounds a bit off (too good with the cpu copy overhead and too bad without it), but it of course depends on the benchmark you are using
<arokux2>
mripard, just checked by putting a printk. hcd->self.uses_dma is TRUE
<mripard>
which would need some proper driver to test it in the first place
<mripard>
spi would be a good candidate
<mripard>
and I happen to be working on an spi driver :)
<arokux2>
mripard, it can be tested by usb too? :)
<mripard>
spi is much more easy to debug.
<arokux2>
mripard, I see. last question then. sunxi-3.4/arch/arm/plat-sunxi/dma.c <--- is this a dmaengine?
<mripard>
no
<mripard>
dmaengine is the framework we should put the dma controller support in
<oliv3r>
arokux2: yesterday i was
<arokux2>
mripard, ah, I see. and that one is the driver for the dma controller?
<arokux2>
oliv3r, so you have double logging on 3.4?
<oliv3r>
no, only on the 3.10; but that's 3.10 + android
<arokux2>
oliv3r, ok
<oliv3r>
and i know android does 7logline; 6logline; 7logline
<mripard>
arokux2: yes, indeed
<oliv3r>
and with the earlyprintk on; i get [kernel timestamps] logline; 7logline; [kernel timestamp] logline; 6logline
<oliv3r>
arokux2: but usb doesn' thave its own dma controller like you said earlier, mmc does; but it'st he only defice
<arokux2>
oliv3r, there is double log on 3.4 too. can be avoided by turning of DEBUG_LL
<oliv3r>
arokux2: i haven't seen it on 3.4 that i recall; but haven't run 3.4 much either
<oliv3r>
but 3.4 being an android kernel, i'm not supprised
<oliv3r>
mripard: you know a little more about the androidization of the kernel right?
<arokux2>
oliv3r, as it looks like usb is using dma stuff. do not ask me why...
<oliv3r>
arokux2: i'm not supprised
<oliv3r>
arokux2: to transfer data at high speeds, you wanna use dma to copy it away
<arokux2>
oliv3r, well.. Hans said usb doesn't have dma! remember?!
<arokux2>
oliv3r, and I believed him...
<oliv3r>
arokux2: he probably only looked at the code quickly; it's of course possilbe; let me check the a20 docs
<arokux2>
oliv3r, doesn't need*
<oliv3r>
nothing really 'needs' dma, if your ok with slow speeds
<arokux2>
oliv3r, has != needs
<arokux2>
oliv3r, I see. the point is I've set my usb driver to actually use dma :)
<oliv3r>
all I know about DMA, is that you can either copy data from 'somewhere' to memory using the CPU (like a = readl(addr) would be) or don't invoke the cpu at all, and have the device write code directly to ram
<oliv3r>
USB end point 1 is a dma dest.
<arokux2>
oliv3r, there is alson uses_pio_for_control for a usb hcd.
<oliv3r>
well EP; dunno if its endpoint
<oliv3r>
but there's 5 EP's total
<oliv3r>
aye
<arokux2>
oliv3r, any idea if I can fallback to this one?
<oliv3r>
no clue :) but you have to :)
<oliv3r>
since we have no dma engine yet
<arokux2>
oliv3r, I'd better add dma support....
<arokux2>
oliv3r, the *only* usb driver in the kernel which uses pio is musb
_enrico_ has quit [Quit: Bye]
<arokux2>
oliv3r, should hardware be special to support pio?
<oliv3r>
everything supports pio generally
<oliv3r>
arokux2: you can't 'just add dma support' the dma engine requires quite some work i'm affraid
<oliv3r>
arokux2: and even mainline musb uses only pio? that's crap, as it makes it hella slow for data
<arokux2>
oliv3r, I was't saying i'll do it tonight. :)
<oliv3r>
what is a USB 'end point'
<arokux2>
oliv3r, like a socket
<arokux2>
oliv3r, you write to it and read from it, afaik
<arokux2>
oliv3r, musb uses dma too.... so things are complicated.
massi_ has quit [Quit: Sto andando via]
<oliv3r>
ohh
<oliv3r>
and each host has how many?
<oliv3r>
isn't usb 1.1. officially limitted to 1
<arokux2>
oliv3r, host? each usb device has them. the number depends on device. i do not know more than that. why are you asking?
<oliv3r>
3 reasons, 1 i don't know what it is :)
<oliv3r>
1 dma engine supports 5 EP's so it sounded like it would be endpoints
<oliv3r>
3 I've played with VUSB, software USB drivber for avr
<oliv3r>
and with vusb it is said 'supports several endpoints, violating the spec, as the spec only allows for 1 endpoint' (for usb1.1)
<arokux2>
I wonder why usb storage works without DMA
<arokux2>
and is *fast* too.
<oliv3r>
fast CPU :)
<oliv3r>
you should run 'top' while copying file
<arokux2>
oliv3r, ok.. then why it worked at all?
<oliv3r>
pio mode works; but requires a lot of cpu
<oliv3r>
or is slow
<oliv3r>
or both :)
<arokux2>
oliv3r, no... it is dma mode and works for storage
<oliv3r>
ok so we have NDMA_DEST_DRQ_TYPE; normal dma destination DRQ type; NDMA_SRC_DRQ_TYPE, normal dma source DRQ type
<oliv3r>
and then there's Dedicate DMA destination DRQ type (and source also) which has far far less IRQ's
<oliv3r>
but i know too little about dma to know the difference
<oliv3r>
mripard: ^
<oliv3r>
the tables are quite different int he hardware that it supports; mUSB is listed for example, as is nand, mac, spi* SS, HDMI Audio and MemoryStick
wingrime has quit [Ping timeout: 260 seconds]
<oliv3r>
where's the 'normal' dma has iit almost all
<arokux2>
oliv3r, where do you see the tables?
<arokux2>
mripard, do you know if there is some place in sunxi-3.4's dma.c where I can put a logging so that I see, that usb actually uses it? I've enabled debugging and see only this output: http://sprunge.us/JcRh
<arokux2>
mripard, or is it something where no printk can be put...?
<arokux2>
mripard, (the grep I've shown was performed after successful initialization of the wifi module, which fails in mainline currently)
<oliv3r>
arokux2: DMA engine in the user manual; though I looked at a20 manual as it tends to be more full
<tm512>
why does the hardware clock on the cubieboard keep resetting?
<oliv3r>
tm512: not enough power?
<tm512>
oh, so as soon as it gets unplugged for a second, it loses it?
<oliv3r>
of course
<tm512>
NTP it is then
<oliv3r>
any RTC needs a power supply to keep counting
<oliv3r>
hence, the bios battery
<oliv3r>
so you either connect a battery to keep the time; or change the clock every boot
<tm512>
NTP to do the latter for me
<oliv3r>
that it does :)
<arokux2>
hm.. why rtl driver cannot find firmware although it is there. buildroot is in initramfs
<arokux2>
hm.. the initramfs is probably mounted later
<arokux2>
can I somehow reload built in driver?!
ZetaNeta has joined #linux-sunxi
<oliv3r>
reload built?
<oliv3r>
reload the firmware? or rebuild?
<oliv3r>
build wifi as a module, unload/load forces a firmware re-read
<arokux2>
oliv3r, do not want to mess up with modules. found an option to put firmware into image itself
notmart has quit [Quit: notmart terminated!]
ZetaNeta has quit [Remote host closed the connection]
<arokux2>
mripard, wifi seems to work without dma.c
<arokux2>
:$
<arokux2>
mripard, cannot be 100% sure
<oliv3r>
arokux2: you can even put the firmware into the kerenla faik
<arokux2>
oliv3r, see my prev. msg.
<mripard>
arokux2: I have no idea
<mripard>
but seriously, going after both drivers at the same time seems like a very bad idea
<mripard>
Turl: sorry for the patch bomb, I got bored today, and didn't have any internet access :)
<mripard>
... so far :)
<Turl>
mripard: :)
<Turl>
mripard: people get confused with A10s and A10
<Turl>
mripard: we should use "A10S" so it does not look like a plural
<mripard>
hmmm, ok
<arokux2>
mripard, what do you mean? I just want to find out if usb is really dma dependent
<arokux2>
mripard, so I've removed dma.c from sunxi-3.4 and gaved it a try.
<mripard>
arokux2: and if it still doesn't work after writing the dmaengine stuff, how will you possibly know if it's your USB driver or the DMA one that is not working?
<arokux2>
mripard, there are some problems, but wifi works -- does much more than in mainline
<arokux2>
mripard, hence usb *isn't* dma.c dependent?!
<Turl>
mripard: hm, do we need CONFIG_SERIAL_OF_PLATFORM on the config?
<arokux2>
mripard, although maybe it just happens to work, maybe it works just because the sunxi-3.4 uses static mapping from physical to virtual?
<arokux2>
mripard, (I'm not going to start to work on dmaengine unless i know it is the problem.)
<mripard>
yeah, maybe
<arokux2>
thanks mripard, I know it is annoying to answer my questions.
<mripard>
it's not annoying, it's just that I have no idea
<mripard>
Turl: hmmm, probably not
<mripard>
let me teste]
<mripard>
*test
<arokux2>
mripard, ok. this is not a problem at all!! would be much better if you had, though :)
<mripard>
Turl: hmmm, now I see why you said it was confusing to some :)
<mripard>
arokux2: I agree
<mripard>
this is mostly why I started the mainlining of this.
<mripard>
to get a clearer view on a lot of things in the kernel :)
<mripard>
Turl: you're right, we don't
<mripard>
must be a leftover from multi_v7
<Turl>
mripard: let me compare the config with mine
<Turl>
mripard: IKCONFIG{,_PROC}=y?
<mripard>
?
<mripard>
what do you mean?
<Turl>
mripard: it may be useful for debugging
<mripard>
yeah, probably
<Turl>
mripard: 754322 is an A9 errata apparently :)
<mripard>
but I don't get which option you're reffering to :)
<Turl>
mripard: we also need CONFIG_EEPROM_AT24=y for A10S olinuxino
<mripard>
ack for the errata
<mripard>
nak for the at24
<Turl>
why?
<arokux2>
we will all learn a lot once I find the reason why usb works partially
<mripard>
we don't want to support every single sunxi board out there
rz2k has quit []
<Turl>
mripard: it's a small driver, and it gives sth to actually put the i2c driver to use
<mripard>
what I want, is a kernel config that will boot on all the allwinner boards, that's all.
<mripard>
yeah, but the next person will come and say "hey, look, there's some device specific stuff in there, why don't we support option XXX?"
<Turl>
mripard: might as well turn off emac and leds with that criteria
<mripard>
no, EMAC is an IP embedded within the SoC
<Turl>
leds aren't :p
<mripard>
that's true
<mripard>
let's remove them then :)
<Turl>
<.<
<mripard>
beware of your arguments :)
<mripard>
(and to be fair, pretty much every board I've seen so far has a LED, it's not the case for the AT24)
<oliv3r>
Turl: you working on 3.10 sunxi_defconfig :D
<Turl>
oliv3r: :p
<Turl>
mripard: you're also missing the watchdog driver
FR^2 has joined #linux-sunxi
<Turl>
(and that's in the SoC, no excuses :p)
<mripard>
Turl: ah, indeed
<oliv3r>
Turl: but seriously what are you working on :)
<mripard>
mainline defconfig
<oliv3r>
mripard: oh before i forget, my 3.10 first try defconfig is spewing out double log lines, one prefixed with timestamps, the other with a single digit (4567 mostly)
<mripard>
I took some time to do one today while being offline
<mripard>
like <4> Some random log ?
<oliv3r>
not sure about the <> but yeah
<oliv3r>
is that an androidisation?
<mripard>
the number is the loglevel
<Turl>
mripard: so your patches go HSTimer->kconfig sort->apb2 fix->defconfig right?
<Turl>
I'll add them on sunxi-devel before I forget
<oliv3r>
mripard: but is that caused from building an android kernel? and should I just remove earlyprintk to remove the dupes?
<oliv3r>
or is tthe android log version disableable
<mripard>
I already saw that, I'm not sure about how to solve it
<oliv3r>
Turl: btw, the sunxi_defconfig you can push to 3.10 aswell; even if drivers aren't there yet imo :)
<oliv3r>
mripard: i'm fine with having dual logs; i just wanna know what's causing it
<oliv3r>
but the real curiosity is, that i didn't have serial consol/login prompt
<oliv3r>
the initramfs should be ok; since turl made it :p
<mripard>
oliv3r: I'm not sure anymore, but I'm pretty sure I experienced it without Android patches
<mripard>
Turl: they're pretty much parallel
<mripard>
the apb2 fix will probably be sent to 3.12
<oliv3r>
on mainline?
<mripard>
the others will end up in 3.13, but they shouldn't have any conflicts
tzafrir has joined #linux-sunxi
<mripard>
ah, you might need to apply the kconfig reordering before the hs timers patches though
<oliv3r>
mripard: have you tested cinifr's u-boot patches? they are too complex for me to review; all assembly
<arokux2>
can you tell me how to quickly find a bit that needs to be set for a gpio to output 1?
<arokux2>
if the name of the pin is PH3, for example
<Turl>
mripard: I'd like mike to take the other two fixes too, thoughts?
<Turl>
mripard: isn't it after? i see sun5i_hstimer in it
<mripard>
Turl: ah, right
<mripard>
Turl: yeah, I was going to acked-by'ing it today
<Turl>
mripard: I'm pretty sure I got acks from you already :p
<mripard>
aaah, not these fixes
<mripard>
I thought you were talking about the sebastian hesselbarth patches that are still in my inbox :)
<Turl>
hm?
<Turl>
I don't think I have those
<mripard>
I'm in the middle of a mail, I'll see if you're in CC in just a minute
<Turl>
ok
<oliv3r>
Turl: ping me when you can push sunxi_defconfig
<arokux2>
mripard, plz cc everything to linux-sunxi
<Turl>
oliv3r: push what?
<oliv3r>
sunxi_defconfig
<mripard>
Turl: ah, yes, indeed, you were not CC'ed
<mripard>
I just bounced them to you
<Turl>
mripard: how did you do that? the emails came from sebastian o.O and are dated 18/9
<mripard>
the magical bounce dance :)
<Turl>
I'm not even on CC, yet they arrived somehow :)
<mripard>
look at the smtp headers ;)
<mripard>
you just act as a mta would do, just forwarding the mail without touching the headers to another person
<mripard>
it's also what happens when you set up some mail redirection
<Turl>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID
<alabaster>
deasy: I'm just giving a try with ubuntu
<alabaster>
I'll describe my struggles in copule of minutes
Tsvetan has quit [Ping timeout: 245 seconds]
<Turl>
mripard: not yet
<Turl>
mripard: I'll send just one so you can copy-paste 5 times :p
<mripard>
just send one :)
<Turl>
mripard: hmm my board hung
<Turl>
it may be unrelated, I restarted it, let's see if it dies again
<alabaster>
works like a charm (still building) using ubuntu
<alabaster>
I think, using gentoo for such things might be to hard for me
<alabaster>
even though I'm using it for ~2years
<alabaster>
still so much stuff to learn :)
<alabaster>
for example: english tenses
Tsvetan has joined #linux-sunxi
<arokux2>
mripard, there? how can I workaround a device tree (this is for testing) so that I do not get this: http://sprunge.us/TYgM ?
ykchavan has joined #linux-sunxi
ykchavan has quit [Quit: Leaving]
CoSM0 has quit [Read error: Connection reset by peer]
CoSM0 has joined #linux-sunxi
popolon has quit [Quit: Quitte]
FR^2 has quit [Quit: und weg...]
<Turl>
arokux2: what do you mean by "workaround a dt"?
<arokux2>
Turl, omit the crash.. it is because irq wasn't defined via a dts
<Turl>
then define it?
<arokux2>
Turl, define in dts?
<Turl>
arokux2: yes
<arokux2>
Turl, I wanted something easier, but ended up doing so now.....
atiti has quit [Ping timeout: 240 seconds]
FDCX_ has joined #linux-sunxi
<leviathanch>
mripard, arokux: well, unfortunately, all the chinese code does DMA related to MMC, and the documentation for the registers is non-existent
<arokux2>
leviathanch, hi...
<arokux2>
i'm arokux2
<arokux2>
leviathanch, i'm not sure usb needs dma
<arokux2>
:(
<arokux2>
leviathanch, still there?
<leviathanch>
arokux2: yeah
<leviathanch>
I'm here
<leviathanch>
arokux2: have you disabled the uses_dma flag now? ;-)
<arokux2>
leviathanch, no, it won't work at all like this.
<leviathanch>
have you disabled the register values related to it?
<leviathanch>
:-)
<arokux2>
leviathanch, but....., I've commented out dma.c (sun4i case) and tried it. wifi works somehow
<leviathanch>
uhm
<arokux2>
leviathanch, but not 100%
<arokux2>
yeah
<arokux2>
leviathanch, so i'm back to origins
<leviathanch>
how much code is it?
tinti has quit [Read error: Connection reset by peer]
<arokux2>
leviathanch, but you know what... chinese code uses static mapping from phys to virt mem
<leviathanch>
is it all written from scratch?
<leviathanch>
oh
<leviathanch>
it's not
<leviathanch>
ok
<arokux2>
leviathanch, maybe that is why it worked in sunxi-3.4
<arokux2>
leviathanch, how much is what?
<leviathanch>
first thing I did while porting was to delete 50% of the chinese code
<leviathanch>
now I only have a hand full of functions
<leviathanch>
which are clear to understand
<leviathanch>
so I know where all information is going
<leviathanch>
the only issue is
<leviathanch>
I don't have a documentation on how exactly the mmc module is working
<leviathanch>
... -.-
<arokux2>
leviathanch, but you have the working code?
<leviathanch>
uhm
<leviathanch>
yes
<leviathanch>
for DMA
<leviathanch>
which isn't supported yet by linux next
<arokux2>
leviathanch, have you tried the remaining 50% if they still worked?!
<leviathanch>
they don't even compile or don't get run before I get stuck
<leviathanch>
they are basically irellevant
<leviathanch>
no, it's more the problem: the mmc controller is configured to do DMA
<leviathanch>
but since the kernel doesn't do hw dma
<leviathanch>
i'm fucked
<arokux2>
leviathanch, ah. i see.
<leviathanch>
hmm
<arokux2>
leviathanch, well, maybe you are smart enough to hack on dmaengine?
<arokux2>
leviathanch, I do rather something stupid - I want a piece of code that works in 3.4 and fails in -next. but exact same piece.
derethor has quit [Ping timeout: 240 seconds]
<leviathanch>
uhm
<leviathanch>
I already did a presentation about embedded linux kernel hacking on an easterhegg event in Basel
<leviathanch>
so I know my stuff well
<leviathanch>
I know where the problem is
<leviathanch>
but there is no easy solution
<arokux2>
leviathanch, I've got 230 LOC that work in sunxi-3.4. now I make it so it can be plugged into -next
<arokux2>
leviathanch, no easy solution? you wanted to hack anyway, so what is the difference, try to work on dmaengine now?
<leviathanch>
:-)
<leviathanch>
yeah
<leviathanch>
of course
<leviathanch>
I just wanted to say
<leviathanch>
wasn't there someone already, who is working on DMA for A1X?!
<arokux2>
leviathanch, you could help me to figure out usb stuff till to the end...
<arokux2>
leviathanch, check wiki - mainlining effort
<leviathanch>
hmm
<leviathanch>
matt porter
<leviathanch>
doesn't seem to have published anything on DMA yet
<leviathanch>
at least not that I could see
<arokux2>
leviathanch, yeah, me too
[7] has quit [Read error: Connection reset by peer]
TheSeven has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
Gerwin_J has joined #linux-sunxi
<arokux2>
Turl, chinese code won't work in -next too, although differently than mine :$
<Turl>
arokux2: heh
<Turl>
leviathanch: yeah, mdp hasn't published anything for sunxi so far
<Turl>
leviathanch: I dunno if he actually has some WIP or not
<arokux2>
Turl, any chance it is ok to fail differently??
<Turl>
arokux2: got a log?
<leviathanch>
Turl: got a documentation? :-)
<leviathanch>
I could get the mmc driver working without using the DMA engine
<leviathanch>
but I would need to rewrite most of the code
<leviathanch>
...
<Turl>
leviathanch: I can offer you high quality chinese code ;)
<leviathanch>
Turl: "For special prices, _my friend_!"?
<leviathanch>
;-)
<arokux2>
:D
<Turl>
leviathanch: have you looked around in other mmc drivers for similar registers?
<Turl>
maybe the controller is someone's IP that AW just bought and integrated