<NoobPinguim>
I'm trying to compile a driver module for my A10 3.0.8+ kernel based tablet. I've been able to cross compile the correct kernel version but the symbol links differ when trying to insmod. I've located the tablet's Module.symvers file, where do I put it in my cross-compiling machine (ubuntu)?
<NoobPinguim>
In my /linux-sunxi git clone only a subfolder of /modules/mali/ has such a file
<Turl>
arokux: no, why would an mdelay after it make any difference?
<Turl>
arokux: no, but you can probably find him on the lists :)
<arokux>
Turl, because harware need some time to react?
<Turl>
NoobPinguim: you'll need exactly matching sources, compiler and config
<Turl>
arokux: the enable routine should take care of any waiting needed to eg. stabilize the clock
<arokux>
Turl, hm.. i'll test more. the point is I was doing clk_prepare_enable then dumped memory and the bit wasn't set yet.
<arokux>
it was set if I added a delay.
<arokux>
Turl, but how the routine can know if the clock is stable?!
<Turl>
arokux: because docs say the clock takes N time to stabilize or so
<Turl>
arokux: of course AW docs don't say it :) but you can get the info from the code sometimes
<Turl>
NoobPinguim: I dunno, ask the tablet vendor to give you the code :)
<arokux>
Turl, hm.. have you seen something like this in allwinner code?
<Turl>
arokux: the pll code has a wait
<NoobPinguim>
I doubt the tablet vendor knows anything about coding :) it's just a whitebranded generic A10 with 3.0.8+ kernel, 4.0.3 android.
<Turl>
you can try using that tag, but there's no guarantee it's matching source
<arokux>
NoobPinguim, recently somebody tried to do the same as you and failed.
<arokux>
NoobPinguim, you may search in the irc log (see topic) and ask him
<arokux>
Turl, ok, found it, but there is no wait for PLL6
<arokux>
Turl, allwinner code actually has mdelays in clock enabling
<Turl>
arokux: just had a look at patch 1/3 replace usbc_readl (...), is the u32 cast really needed?
<NoobPinguim>
So my best chance is to install the image made from this kernel? I think lots of things will probably not work
<Turl>
arokux: yeah that's the wait I was refering to
<arokux>
Turl, u32: do know know, I just deleted usbc_readl, so replaced it with readl
<arokux>
do not know*
<NoobPinguim>
I'll try copying the Module.symvers into the to be compiled modules dir to see if that helps
<arokux>
Turl, you're right, readl returns u32
<arokux>
Turl, can you please test my patches btw, after Hans merges them? I'm curious if the code drop will work.
<arokux>
Turl, you have a cb right?
<Turl>
you aren't testing them? :P
mcbrick has quit [Ping timeout: 246 seconds]
<arokux>
Turl, I am..
<arokux>
Turl, but I will have more confidence if the others test it too :P
rings_IIV has quit []
rings_IIV has joined #linux-sunxi
<arokux>
Turl, hm.. it seems usb has an internal DMA!
<arokux>
Turl, good night!
arokux has quit [Remote host closed the connection]
mcbrick has joined #linux-sunxi
vinifr has joined #linux-sunxi
<vinifr>
Can sunxi LRADC use two channels simultaneously?
egbert has quit [Disconnected by services]
egbert_ has joined #linux-sunxi
mcbrick has quit [Quit: Leaving]
<vinifr>
arokux1, hi
BJfreeman has quit [Quit: had a good time]
navlrac has joined #linux-sunxi
akaizen_ has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
bsdfox has quit [Ping timeout: 276 seconds]
akaizen_ has joined #linux-sunxi
akaizen has quit [Read error: Connection reset by peer]
naobsd has quit [Quit: Page closed]
NoobPinguim has quit [Ping timeout: 250 seconds]
ZetaNeta has quit [Ping timeout: 256 seconds]
vinifr has quit [Ping timeout: 246 seconds]
bsdfox\ has quit [Ping timeout: 240 seconds]
ZetaNeta has joined #linux-sunxi
ZetaNeta has quit [Ping timeout: 240 seconds]
akaizen_ has quit [Remote host closed the connection]
ZetaNeta has joined #linux-sunxi
bsdfox\ has joined #linux-sunxi
akaizen has joined #linux-sunxi
ZetaNeta has quit [Ping timeout: 240 seconds]
ZetaNeta has joined #linux-sunxi
akaizen has quit []
akaizen has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
rz2k has joined #linux-sunxi
bsdfox\ has quit [Ping timeout: 240 seconds]
ZetaNeta has quit [Ping timeout: 248 seconds]
bsdfox\ has joined #linux-sunxi
bsdfox\ has quit [Ping timeout: 260 seconds]
bsdfox\ has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
bsdfox\ has quit [Ping timeout: 260 seconds]
techn__ has quit [Ping timeout: 245 seconds]
rellla has joined #linux-sunxi
rellla2 has joined #linux-sunxi
rellla has quit [Ping timeout: 264 seconds]
wrdoo has joined #linux-sunxi
<wrdoo>
Hello all! Was able to compile and cubieboard2 kernel (http://www.cubieforums.com/index.php?topic=472.0). But seems have problem of using both cores. Load avg. on idle system is steady 2.0
<wrdoo>
and cat /proc/interrupts shows zeros for CPU1 except arch_timer and Rescheduling interrupts
<wrdoo>
otherwise system is more responsive than cubieboard A10 previously used
<wrdoo>
Is this normal?
<rm>
yes
<rm>
there's some bug, maybe USB related
<rm>
that the load is shown as 1.0 on CB1
<rm>
and probably 2.0 on CB2
<rm>
for some people changing script.bin fixed it
<wrdoo>
I am using USB serial cable on both systems
<wrdoo>
Thanks
navlrac has quit [Ping timeout: 264 seconds]
panda84kde has joined #linux-sunxi
\\Mr_C\\ has quit [Ping timeout: 240 seconds]
vicenteH has quit [Ping timeout: 260 seconds]
Ehsand has joined #linux-sunxi
deasy has joined #linux-sunxi
drachensun has quit [Ping timeout: 264 seconds]
drachensun has joined #linux-sunxi
Ehsand has quit [Read error: Connection reset by peer]
notmart has joined #linux-sunxi
Ehsand has joined #linux-sunxi
Ehsand has quit [Read error: Connection reset by peer]
Ehsand has joined #linux-sunxi
gzamboni has quit [Read error: Operation timed out]
FR^2 has joined #linux-sunxi
<arokux1>
Tsvetan3, ping
gzamboni has joined #linux-sunxi
<arokux1>
jukivili, ping
arete74 has quit [Ping timeout: 276 seconds]
drachensun has quit [Ping timeout: 240 seconds]
drachensun has joined #linux-sunxi
fredy has quit [Excess Flood]
<arokux1>
oliv3r, so you're up to hacking now?
fredy has joined #linux-sunxi
benny has joined #linux-sunxi
benny is now known as Guest75885
Guest75885 has quit [Client Quit]
massi_ has joined #linux-sunxi
vicenteH has joined #linux-sunxi
arete74 has joined #linux-sunxi
drachensun has quit [Ping timeout: 248 seconds]
drachensun has joined #linux-sunxi
<oliv3r>
arokux1: no, 1 more eek of vacation :p will try to catchup meanwhile
<jukivili>
arokux1: hello
<arokux1>
jukivili, hi! do you know what UsbPhyInit does?
<jukivili>
arokux1: it's magic
<jukivili>
arokux1: so, no, I don't know
<arokux1>
jukivili, remember, I've told you usb host has similarities. so UsbPhyInit was this similarity which appear to be copy pasted from sun4i_usb. usb host works actually without it.
<arokux1>
jukivili, you could take a look at the commit message to one of my patches
<arokux1>
jukivili, [PATCH 3/3] sunxi-hci: Remove code believed to be no-op
<arokux1>
jukivili, I'd be grateful if you can test it. what hardware do you have? (I forgot)
Ehsand1 has joined #linux-sunxi
<arokux1>
jukivili, I've ordered a usb adapter it should arrive today, so I will test your code too :)
<jukivili>
I have A10 cubieboard
<arokux1>
jukivili, to test it, you can just comment out the line with UsbPhyInit in drivers/usb/host/sw_hci_sunxi.c
<arokux1>
jukivili, no need to mess with applying of the patch
<arokux1>
jukivili, so what do you think about it?
drachensun has quit [*.net *.split]
massi_ has quit [*.net *.split]
vicenteH has quit [*.net *.split]
FR^2 has quit [*.net *.split]
Ehsand has quit [*.net *.split]
ssvb has quit [*.net *.split]
jlj has quit [*.net *.split]
<jukivili>
arokux1: yes, UsbPhyInit seems wrong for ehci/ohci since it's operating on first controller/musb
<arokux1>
jukivili, yep. and they cannot be interconnected in some way?
<arokux1>
jukivili, what is more probable is that USBC_Phy_GetCsr is buggy...
<arokux1>
jukivili, but everything works without it...
ssvb has joined #linux-sunxi
massi_ has joined #linux-sunxi
vicenteH has joined #linux-sunxi
FR^2 has joined #linux-sunxi
jlj has joined #linux-sunxi
drachensun has joined #linux-sunxi
jlj has quit [Ping timeout: 248 seconds]
jlj has joined #linux-sunxi
<arokux1>
jukivili, another thing is, ehci/ohci can actually cause some side effect to your musb driver :)
<jukivili>
arokux1: If I remember right, I did test fixing USBC_Phy_GetCsr (return different register base for ehci/ohci) and that broke usb
massi_ has quit [Remote host closed the connection]
<jukivili>
but I didn't test removing UsbPhyInit completely
<arokux1>
jukivili, ok, so it would be nice if you could...
<jukivili>
arokux1: I'm on it
<arokux1>
jukivili, thanks!
<rz2k>
Benn posted r3p2 libs for Mali from Allwinner without license attached
<rz2k>
we can move now!
<mnemoc>
:o
<rellla2>
:)
<rellla2>
uahh. fb and x11! time to stage a r3p2 ...
<rellla2>
at least hardfloat binaries dated on 2013-07-24. are these new ones?
<arokux1>
rz2k, who's Benn?
<mnemoc>
arokux1: former hipboi's boss at allwinner
<rz2k>
dude from AW
<rz2k>
yes
<mnemoc>
now at cubietech
<arokux1>
rz2k, r3p2?
<rz2k>
arokux1: what?
<arokux1>
rz2k, Benn posted r3p2 libs
<rz2k>
read two words after word "libs"
<rz2k>
:p
<rz2k>
we need userspace libraries to run Mali-400 right, these are tied to updates from ARM
<rz2k>
last one was for r3p0 kernel driver version
<rz2k>
there were 6 or 7 releases after that
<rz2k>
so now we recieved latest one from allwinner
<jukivili>
arokux1: ehci/ohci work with UsbPhyInit disabled
<arokux1>
jukivili, how have you tested?
<arokux1>
rz2k, so this latest one (r3p2) can run with the latest kernel module which is for the kernel of version X. question: what is X?
<jukivili>
booted with usb2 device connected => ok; plug usb1.1 device to another port => ok; unplug both and replug usb2 device to port where usb1.1 device was => ok
<jukivili>
arokux1: works with musb loaded and unloaded
<jukivili>
so no bad interaction from there
<arokux1>
jukivili, this is something unrelated, but did you try to compile with OHCI support only?
<jukivili>
arokux1: with both ehci and ohci
<arokux1>
jukivili, there will be some errors and enumeration will fail in my case. it has nothing to do with my cleanups, i've tested old code.
hansg has joined #linux-sunxi
hansg has quit [Client Quit]
navlrac has joined #linux-sunxi
wrdoo has quit [Quit: Leaving]
<arokux1>
jukivili, how do I know which of usb1.1 or usb 2.0 is my device?
<arokux1>
rz2k, so why everybody is happy to have r3p2? :)
<jukivili>
arokux1: hm?
<arokux1>
jukivili, hm about what?
<jukivili>
arokux1: do you mean, how I know which ports are controlled by ehci/ohci driver?
<arokux1>
jukivili, yes
<arokux1>
jukivili, you said you inserted usb1.1 device, how do you know it was usb1.1?
<arokux1>
bbl
<jukivili>
arokux1: I have two regular A-ports that are connected to ehci/ohci
<rz2k>
arokux1: because r3p2 has many bugs fixed with DRI2 interaction and each update for kernel driver provides bugfixes and new features (latest one IIRC introduced some improvements to profiling)
<jukivili>
[ 33.470323] ehci_irq: port change detect
<jukivili>
[ 33.530417] The port change to OHCI now!
vinifr has joined #linux-sunxi
<jukivili>
arokux1: ah, your board has integraded usb-hub
atiti has joined #linux-sunxi
<deasy>
can someone give me the link for the compiled uboot?
<ssvb>
arokux1: at least I assume that Benn is authorized to distribute these blobs from that site, but re-distributing them by other people is the real problem
<arokux1>
ssvb, from where those cubietech guys got them? :)
<ssvb>
arokux1: a proper license notice would clarify this, that's the point :)
<arokux1>
I've got this one.
<arokux1>
but where from does Benn have them?
<arokux1>
from ARM?
<mnemoc>
allwinner gets the DDK
<mnemoc>
and benn gets someone within allwinner to compile a driver for armhf using it
<mnemoc>
he can't have access to the sources, but he can invite someone to lunch in exchange
<mnemoc>
that's also how "we" got the cedarx armhf blob
<mnemoc>
allwinner can distrbute all blobs they want, but not code
<arokux1>
mnemoc, so Benn can be in a dubious situation also. how he can give a license to something he has got as a favor?
<mnemoc>
so it's only about begging the right person
<mnemoc>
arokux1: allwinner produced the blob, which was built from a DDK licensed for allwinner SoCs
<arokux1>
aha..
<arokux1>
so allwinner can give blobs to Benn and allwinner has actually the right to do so. but the question remains if Benn has right to give blobs to others.
<mnemoc>
Benn role is in getting the right person within allwinner "waste" time buidling a blob for a platform they don't officially support
<mnemoc>
i think he is. because it's just like any vendor distributing an android driver made with the same DDK
<mnemoc>
he is a cubieboard vendor distributing a driver compiled by allwinner to run a allwinner based products
<mnemoc>
sounds pretty fair to me
<rellla>
life would be much more easy, if an "official" aw would come here and talk directly ...
<mnemoc>
rellla: poke eva
<rellla>
service@allwinnertech.com is definitely not the right address
<rellla>
i think that is eva ;)
<mnemoc>
everything is eva
<mnemoc>
unless it's a personal address
<arokux1>
mnemoc, what are the official kernels for allwinner except of android ones?
<rellla>
i asked for cedar-libs a last time last week an she forwarded my mail to tom begging for help ;)
ZetaNeta has joined #linux-sunxi
<rellla>
funny
<mnemoc>
arokux1: official kernels from allwinner come in the SDKs, and those are android-only
<mnemoc>
and usually GPL violating
<arokux1>
mnemoc, no way! they aren't even supporting linux?!
<mnemoc>
rellla: the good thing on that is that it shows there is a implicit partnership between cubietech (tom+benn) and allwinner tech
<mnemoc>
rellla: which makes the blob more.... official
<mnemoc>
arokux1: android-only
<ssvb>
it's just silly that ARM itself is not building/distributing the Mali blobs, this could have solved so many problems
Ehsand1 has quit [Read error: Connection reset by peer]
<arokux1>
fortunately this is GPU issue only (at least from what I know)
<rellla>
mnemoc: thats why i'm looking forward in getting something newer from benn.
<arokux1>
ssvb, vendors probably modify IP, so the sources should be adjusted?
<mnemoc>
if you see the commits in their kernel trees you'll see benn was a pretty important developer there
<arokux1>
mnemoc, where can I see commits?
<arokux1>
mnemoc, which branch, I mean
<mnemoc>
lichee/ and lichee-3.3/ in my github
Ehsand has joined #linux-sunxi
* woprr
is back (gone 85:51:09)
<ssvb>
arokux1: these blobs happen to be compatible with sunxi, rockchip and odroid hardware as reported by some people
<woprr>
lo
<arokux1>
ssvb, oh, I see
<mnemoc>
libv should lead a demostration to ARM's HQ
<mnemoc>
free mali!
<mnemoc>
free mali!
<arokux1>
I thought ARM was developing hardware and not doing this shit
<mnemoc>
free mali!
<ssvb>
arokux1: the problem does not seem to be technical, the resources description for Mali hardware variants is handled in the kernel driver anyway
<woprr>
Can access to some A20 registers be blocked by board manufacturer's "system code" in the A20 "BROM" (PROM)?
<arokux1>
woprr, yes.. or at leas I've seen something
Ehsand has quit [Ping timeout: 245 seconds]
navlrac has quit [Ping timeout: 250 seconds]
<arokux1>
woprr, there was something for USB in SDRAM
<arokux1>
hno, I'm reading our chat from two weeks ago and suddenly it makes much more sense now
<woprr>
If anybody interested in DVB/TSC functionality on A10/A20 can confirm wrong/other base addresses of TSC registers, or knows what claims 0x01C04000 MMIO base, please highlight me, driver and FEX patch is on the mailing list, the last 2 msg with topic "Add support for Allwinner (DVB/ATSC) Transport Stream", thx
<vinifr>
wigyori, I updated the code, could you open the link again?
<Turl>
arokux: the purpose is so then on the driver you can tell pinctrl "yo, configure my pins pl0x"
<Turl>
or maybe pinctrl does it automagically, not sure, need to read a driver to confirm :)
<arokux>
Turl, but the pin is actually configured just before it is used. the other driver could use the same pin for some different stuff, right?
<Turl>
arokux: I believe that's the case indeed
<arokux>
Turl, and so I fail to understand "when" the pin is configured based on pinctrl entries.
<Turl>
arokux: I think we can agree it will be done before you need it :p
<Turl>
mripard: ping, can you clarify?
\\Mr_C\\ has quit []
<mripard>
Turl: pinctrl configures the pin automatically just before driver's probe
<Turl>
arokux: ^ :)
<mripard>
and no, two driver can't use the same pin
<Turl>
mripard: thanks for the info
<Turl>
mripard: enjoying the holidays so far? :)
<arokux>
mripard, but if there is muxing?
<arokux>
I thought muxing is just for that: to allow several driver to use a pin, they just need to specify different mux functions just before using the pin.
<oliv3r>
so while i back-read; what did I miss? :)
<arokux>
oliv3r, jukivili got musb working in host mode
<Turl>
arokux: no, that's not it
<Turl>
arokux: muxing is to have more functions than pins, let's say
<arokux>
oliv3r, I hope I can add support for usb hosts to mainline soon
<Turl>
arokux: so your soc can have 5 pins and be able to USB and i2c - you won't be able to use both simultaneously, but your chip can do both tasks depending on how it's configured
<arokux>
Turl, right, more functions than pins, so you need to say which func you want just befor using it.
<mripard>
arokux: no muxing is not for several drivers to use the same pin.
<mripard>
yeah, just like Turl is saying
<mripard>
Turl: yeah, a bit too hot here, but great otherwise :)
<Turl>
mripard: I'm kind of freezing over here, 7C :p
<arokux>
Turl, where are you?????
<mripard>
~35 here :)
<Turl>
arokux: argentina
<mripard>
And I'm going to linus' country in like a month or so, I'll be freezing as well :)
<Turl>
mripard: :)
<vinifr>
Turl, my neighbor :)
<Turl>
vinifr: :)
<arokux>
Turl, @pinctrl ...oh.. that changes everything.
<oliv3r>
mripard: its still hot in FR?
<mripard>
oliv3r: yep, I'm closer to the sea now, so it's a bit colder, but yeah, still hot :)
<oliv3r>
it's 14C outside now here :)
<arokux>
Turl, just to make sure I got it right. let's take a look at http://linux-sunxi.org/A10/PIO#PH00 if it is configured to be ATAA00, then I cannot have a third UART?
<oliv3r>
it's 20-22 usually during the day here now
<oliv3r>
i was in austria for the past week, and they had the hottest day ever recorded at 40.6 C
<mripard>
arokux: usually, you don't have the choice at the driver's level
<oliv3r>
arokux: unless some onther pin can also be UART3, no
<oliv3r>
arokux: but tehre's 7 uarts on the a10, if not 8
<mripard>
you have to use whatever the board designer told you to use, because the board is wired that way
<mripard>
it's mostly for EE flexibility, not software flexibility
<arokux>
mripard, so a SoC could be basically used only to 50% or so?!
<oliv3r>
arokux: no, the SOC offers you 500% in features :p
<oliv3r>
a SoC allows itself to be used in various designs, from Set-top-box, to tablet
<oliv3r>
while a tablet will need a LCD pinout, a set-top-box has no use for those pins, so those pins could be used for other features, like an LCD and IR transceiver
<arokux>
ok, this was somehow counter intuitive
<oliv3r>
by being able to multiplex pins, whoever uses the chip can be very flexible
<oliv3r>
use the same chip, on different designs
<oliv3r>
or, one designer wants to use an A10 but only needs ethernet and UART so he can make some ethernet -> uart bridge
<arokux>
and it's not actually cheaper to produce A10_tablet, A10_settopbox etc?
<Turl>
mripard: you can use UART3 through PG06 & friends too if you use ATA* on PH*
<oliv3r>
arokux: do you know how much it costs to make 1 chip?
<Turl>
err, arokux ^
<Turl>
sorry mripard :)
<oliv3r>
arokux: it's much much cheaper, to design 1 chip, that does 2 things, then to make 2 chips that do 1 thing each
<arokux>
i know how much does it cost to buy one :)
<oliv3r>
makeing 1 chip costs millions
<oliv3r>
or hundrerds of thousands
<arokux>
oliv3r, where do you know? :P
<oliv3r>
(manufacturing it, not designing the soc even)
<mripard>
and almost any SoC nowadays have pinmuxing, so it's pretty common for everyone :)
<oliv3r>
mripard: nowadays? pfft :p even AVR's and PIC's from the 80's do pinmuxing :)
<mripard>
Turl: now that I reviewed your patch, care to review mine ? :)
<oliv3r>
it's nothing new at all
<mripard>
oliv3r: yeah, it's not really what I meant, but yeah, it's nothing new.
<oliv3r>
arokux: the A10 has a few dedicated pins of course, for tasks that can't be pinmuxed, like ram is dedicated I think (though optional, you could run an entire OS from sram only if you wanted to). touchpad, lradc, USB are all on fixed pins
<Turl>
mripard: :P
<oliv3r>
mripard: so second holliday in finiland?
<Turl>
mripard: I used the hogs because hackberry used the hogs :)
<Turl>
mripard: if they're not needed anymore, that should be cleaned too
<Turl>
mripard: I thought the hogs were using to make the gpio muxing explicit
<arokux>
oliv3r, you see, if there is a pinmuxed design it means you can have several designs of a soc just by throwing out things. then it boils down to manufacturing really.
<Turl>
were used*
<oliv3r>
i should swap out my RTL PHY's on my cb1 now
<oliv3r>
arokux: exactly, and manufacturing costs a huge huge fortune
<oliv3r>
arokux: not only that, stocking, offering, choosing different soc's is horrible
<oliv3r>
'sir, do you want SoCA or SoCB for you design?'
<arokux>
oliv3r, I thought it's like 3D printing, print what ever the design is.
<mripard>
oliv3r: no, finland for work :)
<oliv3r>
oh well we odn't offer that option, sorry :p
<Turl>
mripard: re 10mA, no idea :) we had it that way on the other dt too
<oliv3r>
arokux: it sort of is
<oliv3r>
arokux: only it costs millions :)
<oliv3r>
arokux: and pinmuxing is really really cheap
<mripard>
Turl: no, they were used back in the days where the code I pasted you earlier wasn't there
<oliv3r>
arokux: you basically have a 'switch' between all of the ports on the inside of the chip, and the pins on the outside
<mripard>
and that every driver had to call pinctrl functions explicitly
<arokux>
oliv3r, what exactly costs millions, to "upload a 3D file" to a printer?
<oliv3r>
arokux: the only other option is to add a lot more pins for every feature
<oliv3r>
arokux: everything
<mripard>
so, for drivers that didn't have pinctrl support yet, you just were putting a hog pins node to grab all the relevant pins
<arokux>
I get that. I just cannot believe I'm actually using only 50% (or less!) of my SoC!!!!
hramrach has quit [Remote host closed the connection]
<oliv3r>
arokux: first, you have to have several designs. fix an issue in soc A, and you have to check all your soc designs for a specific bug, but ignore the VHDL side of things
<Turl>
mripard: so who takes care of muxing it to gpio mode explicitely if I drop the hog?
<mripard>
regulator-fixed iirc
<oliv3r>
arokux: once your VHDL design is done and tested, you have to send it off to do a test spin at a factory, (sometimest hey don't even do that) which can take weeks (lots of time/money wasted)
<arokux>
ok, thanks a lot oliv3r
<mripard>
Turl: on a general basis, every node should be grabbing the pins it needs
<oliv3r>
then, getting your design produced on mass by TMSC for example, costs millions and takes forever, you have to get 'slotted' (e.g. you make an appointment to print your design) months if not years ahead
hramrach has joined #linux-sunxi
<oliv3r>
arokux: dead silicon is far cheaper then 10 different socs that might not get sold :)
<mripard>
oliv3r: no, working for free electrons in finland :)
<mripard>
I'll give a training there
<arokux>
I have one last question..
<oliv3r>
mripard: very cool; android?
<oliv3r>
arokux: shoot :)
<mripard>
oliv3r: nope, Linux sysdev
<arokux>
so if pinctrl is there, why do I need to add gpios entry?!
<mripard>
oliv3r: how to build a toolchain, how to compile a kernel, bootloader, a rootfs, etc.
<Turl>
mripard: so I would rename the hog to emac_phy_power_pins and using it with pinctrl-0 on the regulator node?
<mripard>
arokux: hmmmm, the interaction between pinctrl and gpio is kind of messy
<mripard>
but basically, pinctrl says that you want one pin to be muxed to one function
<oliv3r>
mripard: ah, cool stuff :)
<oliv3r>
mripard: sunxi_bsp ;)
<techn_>
mripard: which city?
<mripard>
for all it knows, it can be anything. Including GPIO. But basically, it doesn't care
<vinifr>
mripard, I have written a driver based on at91_adc... should I keep you as an author, correct?
<oliv3r>
arokux: depends on what you mean, but GPIO (general purpose I/O) is just a function like any other
<oliv3r>
arokux: so a UART3_TX pin, is just a special GPIO pin
<mripard>
now, gpio is just one function of that pin, so then, you need to say that you use in your driver a particular GPIO
<oliv3r>
arokux: ^ said it better
<mripard>
arokux: pushing a bit further the concept, even though I never saw it in real life, would be to have several GPIOs on the same pin
<mripard>
say you have pin 1, with the functions gpios 0, 1 and 2
<mripard>
in your driver
<mripard>
you have to mux the given pin to one of these
<mripard>
plus, the driver has to know which one to actually use
bsdfox\ has joined #linux-sunxi
<mripard>
the messy thing here, is that since the gpio input and output can be different functions on a given pin
<mripard>
like it's the case on suniki
<mripard>
*sunxi
<mripard>
so the gpio core actually play a bit with the muxing to set that up nicely when you change the gpio direction
<arokux>
mripard, "plus, the driver has to know which one to actually use" >> but this is set up by pinctrl
<mripard>
so, basically, you could very well use the gpio definition without setting it up in pinctrl
<mripard>
but it would be dangerous, because then, every other driver could come and play with your muxing without any problem.
<arokux>
that is clear.
<oliv3r>
pinmuxing is especially interesting in development boards like the cubie or the olimexino
<mripard>
oliv3r: nah, we use real stuff. Buildroot :)
<oliv3r>
mripard: real men do it by hand.
<Turl>
oliv3r: LFS guy eh? :)
<oliv3r>
Turl: gentoo ;)
<arokux>
I have this concrete question. http://pastebin.com/izEmiYLe in usb_pins_a I've already specified a pin and it's function. why should it be duplicated in gpios entry?
<oliv3r>
but i ran slackware for 3? years, packagemanagemnt was unknown to me, i learned lots, but regretted not using debian or LFS back then ;)
<oliv3r>
arokux: USB doesn't get pinmuxed afaik, USB pins are set in stone so to say
<mripard>
Turl: yep
<oliv3r>
arokux: BUT usb could use some pins for special functions (e.g. power on/off the wifi module)
<mripard>
vinifr: nah, you don't need to
<arokux>
if the answer is "because it is done so" it is ok, but I just need to know if there was a reason to do so.
<mripard>
vinifr: you can say in the copyright notice that you based your driver on mine, but that's all, really
<Turl>
mripard: btw, which patch did you needed reviewed?
<mripard>
arokux: this is the way that have been chosen for the TI stuff to specify that a given pin is a gpio
<arokux>
Turl, I mean the last version of dts you send me hasn't changed?
<mripard>
arokux: so basically the same setup that the one you have
<Turl>
arokux: http://sprunge.us/RKUD is the latest, it has changed compared to the email
<oliv3r>
arokux: but that's 'allwinner (softwinner-> sw) code, do you really want to use that as proper reference?
<mripard>
arokux: look at how it doesn't mean anything useful :)
<Turl>
arokux: if you test emac & leds and it works ok I'll send v2 to the lists
<mripard>
Turl: all my clocks one!
mcbrick has joined #linux-sunxi
<Turl>
mripard: didn't I already send you enough reviewed-by's? :p
<Turl>
what did I miss? :)
<mripard>
Turl: and yeah, their memory window stuff is crazy
<arokux>
oliv3r, what else should I use as a reference? USB port should be up, so this is what should be done, or?
<mripard>
you have an IP that you can use to setup the memory address at which a given IP will be based at
<oliv3r>
arokux: well you are enabeling and disabeling the power to the USB port, where it should be exactly, I don't know :) ask mripard :p
<Turl>
mripard: yeah, it's crazy :)
<mripard>
and you can even setup the base address of this IP :)
<mripard>
see the chicken and the egg ? :)
<Turl>
mripard: and different bl's have it at different addresses ;)
<mripard>
Turl: about the patches, you had some comments about some stuff I didn't remember
<mripard>
like the rounding in the A31 clocks
<mripard>
you never commented on the following versions
<Turl>
I'll go over all the 3 series again then and leave my tags on them :)
<Turl>
but if you fixed the issues I mentioned they should be good to go
<mripard>
Patch 3 of the A31 stuff, patch 2 of the A10s one
<arokux>
oliv3r, ok, so you do not know the answer myself and look at me with surprised eyes that i've done something wrong. there will be an RFC session and we'll correct everything, do not worry, for now I want to have clean code and it should *work*
<Turl>
mripard: we just need mturquette to start merging stuff :)
<oliv3r>
arokux: i was only saying that you had chosen a strange name, as if you where muxing USB pins ;)
<oliv3r>
arokux: to the SoC, USB is only 2 pins, D+ and D-; there's GND and 5V, but those aren't needed for USB operation at all. The slave device may need those 5V though ;)
<mripard>
arokux: get it to work, then worry about clean code :)
atiti has quit [Ping timeout: 256 seconds]
<Turl>
mripard: mturquette often reads this channel when we're talking about clocks :p
<arokux>
mripard, it works now. only dma part should be added, but this is copy paste.
<arokux>
oliv3r, exactly.
<mripard>
Turl: yeah, and he's speaking right now on another channel :)
<arokux>
oliv3r, so you want to say powering the port doesn't belong into ehci-sunxi.c?
<oliv3r>
mturquette: ^^
<arokux>
oliv3r, I can follow you. but then if you say so, tell me where it belongs :P
<oliv3r>
arokux: it might, but might not, i'm not sure. it sounds reasonable in ehci-sunxi, but the name needs to be clear in your dts ;)
<oliv3r>
e.g. usb_bus_pwr_en maybe?
<mripard>
arokux: it should probably be a regulator
<oliv3r>
or that!
<mripard>
arokux: but don't worry about it too much right now
<Turl>
brb
<arokux>
mripard, yes, good idea
<arokux>
arokux, ok, I'd try to post the code for RFC asap!
<arokux>
mripard, ^
* mturquette
coughs.
<mripard>
don't forget to put me in Cc when you send patches about mainline :)
<oliv3r>
Turl: see! you where right! :p
<arokux>
mripard, ok!
heffer_ has joined #linux-sunxi
heffer_ has quit [Changing host]
heffer_ has joined #linux-sunxi
heffer has quit [Ping timeout: 246 seconds]
<arokux>
mripard, should I post one big chunk, or should I split it in clocks, ehci etc?
<mripard>
Turl: your invocation skills are quite impressive :)
<Turl>
mripard: :)
<mripard>
mturquette: hi!
<mripard>
mturquette: it would be great if you could give a round of review/merging for the A10s and A31 clock patches sometime soon :)
<mripard>
so that if we need some extra versions, I can still do it before the merge window opens
<mturquette>
mripard: they are next in the fifo
<mturquette>
mripard: well, there are relatively close to the head of the fifo, given the overall length of the queue
<mturquette>
due to my slow review for this merge window i'll be taking reworked patches pretty late to make up for it, so don't woryr.
<mripard>
mturquette: ok, great then :)
<drachensun>
mripard: I've noticed on the A31 a nand process seems to constantly pull 10% of the CPU under Linux. I'm working with the allwinner kernel. Is your mainline kernel running? Do you see this kind of nand processor usage?
<mripard>
drachensun: yeah, I have mainline running on it, and didn't notice
<mripard>
but since we don't have anything related to nand yet, that doesn't seem to be a significant comparison :)
<mripard>
I'll try to reflash my A31 with your images, and boot it to see if I get the same behaviour
<drachensun>
yeah, damn closed nand driver
<oliv3r>
drachensun: but we have source drops for the nand driver
<oliv3r>
the closed blob was a 'mistake' afaik
<drachensun>
seems like there was talk of the A20 nand driver being released, did that happen? might they do the same for the A31?
<drachensun>
ahhhh
<drachensun>
cool, where is the source?
<oliv3r>
not sure what the exact status is, rhombus git might have it, or ask lkcl_ otherwise
<drachensun>
ok
<oliv3r>
he managed that bit iirc
<drachensun>
mripard: I've tried on a few devices, I'm assuming its just something badly done in that nand driver
<drachensun>
doesn't seem to happen with the same kernel under Android though
<drachensun>
mripard: Yeah, I'll get you a test image though if you are interested
<mripard>
drachensun: I downloaded them from you already quite some time ago
<mripard>
I just didn't take the time to flash them yet
<drachensun>
ah ok, I think that was just the Android image
<mripard>
ah, probably, let me check
<drachensun>
but so you aren't running on nand
<drachensun>
did you get it booting from an SD?
<mripard>
yes, they are Android images
<mripard>
yep, booting from SD, with mainline
<mripard>
I don't have much support right now, but it does boot
<drachensun>
so what was wrong the boot0/boot1 to work from an SD?
<mripard>
a lot of things on my side :)
<mripard>
I couldn't compile a viable boot0/boot1 bootloaders first
bsdfox has quit [Ping timeout: 264 seconds]
<mripard>
so I got one from Allwinner, and then I had to fight with the offsets to put it in the partitions, plus some magic.
<mripard>
what took me most of the time though is that I had hangs in the boot process that I didn't understand at the time
<mripard>
and that was because the CPU was running with its cache disabled, because the bootloader was failing to setup properly the CPU before starting linux
<Turl>
mturquette: a second review on my RFC series would be great too; with a bit of luck I'll be sending v2 this week in hopes it can land in 3.12
<drachensun>
ok, yeah I saw that email about it
<Turl>
mripard: I saw a patch fixing that on the ML the other day from hansg I think
<mripard>
Turl: yeah, for u-boot, that should fix it for the A20
<mripard>
but not yet for the A31 :)
<Turl>
mripard: would the same not fix it?
<mripard>
Turl: yeah, it should
<mripard>
except that we don't have any A31 support in u-boot yet :)
<mripard>
oliv3r's working on it, but we're not quite there
<Turl>
mripard: you can add it to aw's tree in the meantime right?
<mripard>
If I could compile a working bootloader, sure :)
<Turl>
it doesn't build? :/
<drachensun>
well could you add it at the u-boot stage like for the a20?
<Turl>
quality aw code :)
<mripard>
I should test with allwinner's compiler though
<mripard>
Turl: it does, it just doesn't work
<drachensun>
ok
<drachensun>
yeah I was going to say " I can build, it just doesn't seem to work" :)
<drachensun>
you too, ok
<Turl>
mripard: gcc 4.8?
<mripard>
Linaro flavored gcc 4.7
<Turl>
it may be the memset or such bug then that hit linux too
<drachensun>
I see, the a20 fix happens in the SPL
<mripard>
it's the toolchain I'm using for my daily builds of the kernel, so I don't think so
<Turl>
arokux: ping
<arokux>
Turl, yes?
<Turl>
mripard: the kernel got it fixed recently
<Turl>
arokux: did you get a chance to test the new dts? :)
<arokux>
not yet, are you leaving?
<Turl>
no, just wondering :)
<oliv3r>
mripard: yeah i'll start looking at that again in a few weeks; vacation this week, some catching up and a20 working next week
<drachensun>
mripard: is any of the info you have about the fixes to boot0/1 online? I might try and take a shot at building it is as well, its a lot faster to test SD images that reflashing, especially if I am just testing boot0
<Turl>
I need to run a few errands but I'll be back soonish
<mripard>
anyway, off to bed now :)
<mripard>
drachensun: I can try to get back what I did, and write something about it to you or even better on the wiki
<mripard>
oliv3r: yeah, don't worry about it, enjoy your holidays :)
<arokux>
Turl, ok. will do it a bit later
<drachensun>
mripard: Thanks, I would appreciate it, if you just have some rough notes or anything I can wikify it
deasy has quit [Quit: Quitte]
<mripard>
drachensun: I'm on holidays this week, so I don't think I have this here
<mripard>
just remind it to me next week
<drachensun>
mripard: sounds like the updated boot0/1 files are the most critical thing, if they actually fixed something
<drachensun>
ok sure
<drachensun>
oh man, hate to ask for it when you are on vacation, well enjoy your holiday
drachenphone has joined #linux-sunxi
<oliv3r>
mripard: and without any A31 hardware, it's just writing and hoping someone can test it at some point ;) i allready noticed quite some booboo's :)
<zerodamage>
cya all
zerodamage has quit [Quit: Page closed]
Seppoz has quit [Remote host closed the connection]
Seppoz has joined #linux-sunxi
xtofury has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
<arokux>
Turl, how about I add regulator to mele dts?
<arokux>
Turl, why it is not a patch this time? ((((
drachenphone has quit [Ping timeout: 245 seconds]
drachenphone has joined #linux-sunxi
<arokux>
Turl, and why have you created it with windows style EOLs?
<oliv3r>
heretics!
<Turl>
arokux: regulator?
<Turl>
arokux: I just copied and pasted from my editor to the site's textarea this time, I suppose that changed it to winstyle line endings :(
<arokux>
Turl, it is better you send it in patch form as you did first time
<arokux>
as e-mail
<arokux>
Turl, regulator for a USB port VBUS
<Turl>
arokux: can you test with the windows line copy or do you want me to refresh the patch for you to test?
<Turl>
arokux: it should be something like the gpio regulator we have for emac on there
<arokux>
Turl, refresh plz
drachenphone has quit [Ping timeout: 256 seconds]
<arokux>
Turl, yes, i'm just asking if I can add it now
<Turl>
arokux: what do you get as commandline then when chosen is ommited?
<xtofury>
ahhh ok so I should do a build without it, if it works, toss it in, then it should work? (sweet)... seems almost too easy... (aside from the waiting part for it to compile).
<arokux>
Turl, an EOL
<arokux>
Turl, and I have bootm 0x46000000 - 0x49000000 cmdline earlyprintk console=ttyS0,115200
<Turl>
arokux: try setting bootargs instead of using that bootm syntax
<xtofury>
oh nevermind, that one doesn't work I've followed the instructions and compiled a little test adk and it has the same problem as arduino commander...
<Turl>
arokux: env set bootargs earlyprintk console=ttyS0,115200
<Turl>
xtofury: make sure the kernel has the usb serial driver compiled in
<arokux>
Turl, yep
<Turl>
arokux: does it boot that way?
<arokux>
Turl, yes... i hate uboot
<Turl>
:)
<oliv3r>
wh hate you boot :(
<Turl>
arokux: ok, v2 sent; for a tested-by tag, you need to reply to it with the tag
<arokux>
Turl, oops
<arokux>
reg-fixed-voltage emac-3v3.2: could not find pctldev for node /soc@01c20000/pinctrl@01c20800/emac_power_pin@0, deferring probe
<arokux>
Turl, just spotted this
<Turl>
arokux: I believe deferring is not bad as long as it doesn't fail later on
mcbrick has quit [Quit: Leaving]
<xtofury>
which usb serial driver, the only one I can find is not kernel mode, and there appears to be issues with usb host over android, also seems like the software one might only be working via otg connector, but this is a problem because on cubieboard the otg is routed through one of the usb ports because of power issues for the sata.
<arokux>
Turl, yes, it seem to wokr
<Turl>
arokux: can you paste the full log?
<arokux>
well, some shit happened and not all log messages can be seen
<Turl>
xtofury: one of CONFIG_USB_SERIAL_*, I don't know exactly which one though
<Turl>
xtofury: you can find rather easily however, just plug to your desktop and observe which one got loaded
<Turl>
arokux: not even on dmesg?
<arokux>
Turl, never mind
<arokux>
Turl, how do I copy paste so much out put from a shity serial window?
<xtofury>
looks like this might work: /system/etc/permission/android.hardware.usb.host.xml and ensure you have give permission to all USB devices by having this line in ueventd.rc file "/dev/bus/usb/* root usb".
<Turl>
arokux: a bit hacky but it can do the trick
<xtofury>
since it detects it using the usb utility, but doesn't work with the software even though the VID and PID are correct, it could just be something simple like a permissions issue...
<Turl>
arokux: pinctrl seems to kick in later on, and judging by the "emac-3v3: 3300 mV" near the end it seems to be fine
<arokux>
Turl, ok
<Turl>
arokux: the ultimate confirmation would be shutting down the pin and seeing if linux brings it up fine, like you did earlier today