<Fsanches>
It is not clear to me where the upstreaming effort happens
<Fsanches>
is there a branch somewhere (perhaps in some other git repository) where people push commits for the latest upstream development kernel code ?
<Fsanches>
Hmmm... maybe I'm confused. Or maybe I did not express myself clearly. What I am looking for is not Linus' tree, but instead, the tree containing all of the sunxi-specific code that is supposed to be sent to Linus
bsdfox has joined #linux-sunxi
<Fsanches>
the sunxi-3.4 branch looks pretty much quiet, for instance. I suppose the sunxi developers are working on some other branch based on a newer kernel, right?
<mripard_>
there's no such thing then
<Fsanches>
or perhaps the bulk sunxi-related development code happens on personal trees for each developer and such code is not hosted at the https://github.com/linux-sunxi/linux-sunxi repository ?
<Fsanches>
for instance, where is the MUSB patchset from Hans de Geode (that I've seen this week at the mainling list) going to pushed ?
<Fsanches>
*Goede (sorry)
<mripard_>
when it will be merged, in linux-next and sunxi-next
<mripard_>
before that, you'd better ask Hans
<mripard_>
I'm not sure he pushed it somewhere
<Fsanches>
ok, cool
<Fsanches>
I am specifically interested in his patchset since it may be necessary before I get USB Audio Gadget working on the ICnovaA20 Development Board (that uses an A20 coreboard)
<atsampson>
I'm not sure if that's the latest version, though, so check against the mailing list
<Fsanches>
ok, thanks. I'll try that
ricardocrudo has quit [Ping timeout: 244 seconds]
bsdfox has quit [Ping timeout: 246 seconds]
bsdfox has joined #linux-sunxi
bsdfox has quit [Ping timeout: 246 seconds]
<plaes>
ssvb: did you just edit "Linux Kernel" page? :D
<ssvb>
plaes: yes
<plaes>
heh.. I started editing just before you had added the "warning banner" :P
<plaes>
your's is better though..
<ssvb>
hopefully this notice is difficult to miss now :)
<Fsanches>
ssvb: the product I'm working on is a musical instrument that uses an A20 SoC. So, I guess that for me these legacy linux-sunxi kernels are still the way to go, right?
cooper has joined #linux-sunxi
<Fsanches>
the device is headless (requires no video support at all), but requires I2S digital audio support
<ssvb>
you can try to port the necessary code to the mainline
<Fsanches>
that would be cool, for sure
<mripard_>
it would yeah
<atsampson>
cooper: oddly enough, that's one of the questions I need to answer at some point... the main reason I want to replace my Cubieboard router with a Nano is to get baby jumbo frame support
leviathancn has joined #linux-sunxi
<mripard_>
Turl: btw, any plan on submitting your DMA driver?
<Fsanches>
ssvb: regarding a porting effort, how safe is that in terms of license compliance? I've heard some (big) noise on the mailing list about AllWinner violating the (L)GPL licenses
<cooper>
atsampson: I'm getting a 'Device or resource busy' when I try to alter it at runtime (i.e. interface is up)
<Fsanches>
are the repositores at github.com/linux-sunxi clean in terms of copyright/licensing conformance ?
<ssvb>
Fsanches: the intention is to have the primary branches copyright/license clean for sure
<atsampson>
cooper: have you tried taking the interface down first? ;-)
<atsampson>
the stmmac driver does implement _change_mtu, and it should return -EINVAL if you're asking it for a silly value, not -EBUSY
<ssvb>
Fsanches: but some branches may contain the original allwinner code drops with binaries, some repositories contain mali and cedar blobs
bsdfox has quit [Ping timeout: 246 seconds]
<cooper>
I'm considering it. The box has since been tucked away a bit and for reasons unknown (well... I'm sure people can guess) it doesn't do the reboot when asked to.
<cooper>
As in, it shuts down, says it will reboot, but then just sits there.
<Fsanches>
I've seen loads of code comments in chinese
<Fsanches>
which sucks...
<cooper>
I tried with 9000 (what my router supports), 4000 and 2200.
<Fsanches>
would need proper translation into english before being sent upstream
<cooper>
No dice.
<atsampson>
cooper: I'm pretty sure you can't change MTU with the interface up, IIRC
<ssvb>
Fsanches: the code may need a major rework in addition to just translating comments
<cooper>
atsampson: Works just fine on my main machine.
<ssvb>
cooper: are you experimenting with deviating from the defaults again? ;-)
<atsampson>
cooper: it's up to the driver
<cooper>
Defaults are for people unwilling to experiment.
<atsampson>
cooper: ... and, in fact, in stmmac: "if (netif_running(dev)) { pr_err("%s: must be stopped to change its MTU\n", dev->name); return -EBUSY; }"
<ssvb>
cooper: experiments are for the tough people who can take care of themselves :-)
<atsampson>
I like experimenting as a team ;-)
<cooper>
Well, I can, but I'm not such a male chauvinist pig that I'm incapable of asking others.
leviathancn has quit [Ping timeout: 265 seconds]
leviathancn has joined #linux-sunxi
<cooper>
I like the concept of "If you break it, you get to buy the pieces."
froolap has joined #linux-sunxi
<cooper>
And, indeed, I get that error in the logs...
<ssvb>
nove: crap, the "Derailed thread" is already derailed...
<froolap>
lol
<ssvb>
I should have probably commented there yesterday, but I don't feel like getting involved in this legal crap
bsdfox has joined #linux-sunxi
domidumont has joined #linux-sunxi
<cooper>
From the logs: eth0: invalid MTU, max MTU is: 3838
<cooper>
So, there you have it.
<atsampson>
ah, cool -- that means it should do baby jumbos quite happily...
bsdfox has quit [Ping timeout: 246 seconds]
afaerber has quit [Quit: Verlassend]
<cooper>
atsampson: Looks like the good news is you can, the bad news is you shouldn't.
reinforce has quit [Quit: Leaving.]
bsdfox has joined #linux-sunxi
bsdfox has joined #linux-sunxi
<nove>
ssvb: nobody does
Nyuutwo has quit [Ping timeout: 272 seconds]
khuey is now known as khuey|away
bsdfox has quit [Ping timeout: 246 seconds]
cubear has quit [Quit: Leaving]
Nyuutwo has joined #linux-sunxi
<cooper>
atsampson: I'm getting all manner of connection problems with 3838
bsdfox has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
leviathancn has quit [Ping timeout: 256 seconds]
leviathancn has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 246 seconds]
bsdfox has quit [Ping timeout: 246 seconds]
bsdfox has joined #linux-sunxi
bsdfox has joined #linux-sunxi
dack has joined #linux-sunxi
dack has quit [Read error: Connection reset by peer]
<cooper>
atsampson: What I did manage to do was make a cold read of a file via samba move across the network at 61 MB/s with the smb process at about 70% cpu and a hot read at 71 MB/s at under 60% cpu.
<cooper>
Considering I came from 45 MB/s reading off a ramdisk, that makes me very happy.
<jelly>
3838 is a weird number for wired interface max mtu anyway
bsdfox has quit [Ping timeout: 246 seconds]
<cooper>
Should I try something else?
bsdfox has joined #linux-sunxi
bsdfox has quit [Ping timeout: 246 seconds]
reinforce has joined #linux-sunxi
bsdfox has joined #linux-sunxi
bsdfox has joined #linux-sunxi
FR^2 has quit [Quit: Connection reset by peer]
FreezingCold has quit [Ping timeout: 246 seconds]
bsdfox has quit [Ping timeout: 246 seconds]
khuey|away is now known as khuey
bsdfox has joined #linux-sunxi
bsdfox has joined #linux-sunxi
bsdfox has quit [Ping timeout: 246 seconds]
reinforce has quit [Quit: Leaving.]
domidumont has quit [Ping timeout: 246 seconds]
diego71 has quit [Ping timeout: 246 seconds]
bsdfox has joined #linux-sunxi
diego71 has joined #linux-sunxi
bsdfox has quit [Ping timeout: 246 seconds]
FreezingCold has joined #linux-sunxi
destroyedlolo has joined #linux-sunxi
<destroyedlolo>
Hi everybody,
<destroyedlolo>
Can someone help me to configure DirectFB on my BananaPI ?
bsdfox has joined #linux-sunxi
Fsanches has left #linux-sunxi [#linux-sunxi]
leviathancn has quit [Ping timeout: 246 seconds]
leviathancn has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
leviathancn has quit [Ping timeout: 256 seconds]
leviathancn has joined #linux-sunxi
nove has quit [Quit: nove]
ricardocrudo has joined #linux-sunxi
leviathancn has quit [Ping timeout: 256 seconds]
ricardocrudo has quit [Ping timeout: 245 seconds]
domidumont has joined #linux-sunxi
<destroyedlolo>
quit
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 250 seconds]
domidumont has quit [Ping timeout: 246 seconds]
bonbons has quit [Quit: Leaving]
ricardocrudo has joined #linux-sunxi
ricardocrudo_ has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 256 seconds]
ricardocrudo__ has joined #linux-sunxi
Turl has quit [Ping timeout: 276 seconds]
ricardocrudo_ has quit [Ping timeout: 256 seconds]
ricardocrudo__ has quit [Ping timeout: 252 seconds]
jinzo has quit [Quit: Leaving]
ricardocrudo__ has joined #linux-sunxi
Andy-D has joined #linux-sunxi
ricardocrudo_ has joined #linux-sunxi
leviathancn has joined #linux-sunxi
<cooper>
atsampson: Why are you repeating the tests for "JEDEC timings, 648MHz, EMR1=0x04, ZQ=0x29, DCDC3=1.325V (board #2)"? Or are you doing something else that simply isn't reflected by the parameters in that table?
<atsampson>
cooper: I'm doing the same thing on board #1 and board #2 to see how different they are, and also trying board #2 with a tweak to the relative phases of the different lanes
ricardocrudo__ has quit [Ping timeout: 265 seconds]
<cooper>
Ah, so I see.
khuey is now known as khuey|away
<atsampson>
I actually did the lane phase adjustments first; I probably wouldn't have bothered given (a) boards #1/#2 differ in the per-lane errors and (b) now that I have the schematic, the lanes probably aren't routed together anyway
<cooper>
I'm feeling mighty tempted to try one of those configs and see what the real-world impact of that would be on my boards.
<atsampson>
ssvb pointed out that the biggest performance improvement comes from tweaking the MBUS frequency up, which I've not really experimented with yet
<cooper>
That A10 cubieboard1 page of his shows mbus clock at 0...
<cooper>
Is there a relation between the mbus speed and the core's operating frequency?
<ssvb>
cooper: A10 does not have MBUS, or more like the MBUS clock speed is just not configurable but hardcoded in some way
<cooper>
In other words, when you up the mbus speed, would you somehow need to adjust the core frequency or something?
<cooper>
ssvb: Aha. Thanks for clearing that up.
leviathancn has quit [Ping timeout: 252 seconds]
ricardocrudo__ has joined #linux-sunxi
linux_salonica has quit [Ping timeout: 246 seconds]
<ssvb>
atsampson: it is interesting that the ZQ=0x29 setup is unreliable when calibrated to 0x1996900
<ssvb>
atsampson: regarding the MBUS clock increase attempt, it might make sense to verify that dqs_gating_delay=0x07070707 is really good for this board at ~600MHz
linux_salonica has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
ricardocrudo_ has quit [Ping timeout: 265 seconds]
<ssvb>
low MBUS clock speed throttles down the data transfer rate, so it may probably hide certain problems
ricardocrudo__ has quit [Ping timeout: 245 seconds]
<cooper>
Is there an ideal value for a board? Like you had in x86 land a number of years ago when having the memory speed be a multiple of the core speed would aid performance.
<ssvb>
atsampson: I did not get any good results with lane phase adjustments myself, that's why I did not bother to document or make this functionality more user friendly
<ssvb>
atsampson: the length of the traces from all lanes is probably already matched, how can we get this information from the schematic?
<ssvb>
ddr3 allows fly-by topology, where the length of traces may be different for different lanes and the delay compensation is automatically configured via read/write leveling
<ssvb>
so the board manufacturers probably should do the ddr2 style routing, unless the tracks length is already small enough (compared to the desktop PC mainboards) to have a negligible effect either way
paulk-collins has quit [Read error: Connection reset by peer]
<ssvb>
it looks like high MBUS speed is needed for fast transfers in one direction (only read or only write)
<ssvb>
but if reads and writes are done simultaneously (the copy operation), then low MBUS speed is not a problem
premoboss has joined #linux-sunxi
<cooper>
ssvb: Strange. When I look at those numbers I'm getting the feeling that balanced is best and increasing mbus beyond that gains you surprisingly little.
<cooper>
ssvb: Only write performance really gets a kick in the backside from that.
<ssvb>
cooper: that's for A13, it seems to behave a little bit different
<ssvb>
also A13 only has a 16-bit DRAM bus width
<cooper>
Ouch.
<ssvb>
but we are interested in the A20 numbers (the Cubietruck tables)
<ssvb>
also the benchmark programs are different, the A13 tables only use tinymembench numbers (single threaded, CPU only)
leviathancn has joined #linux-sunxi
<ssvb>
but on A20 we want to use both CPU cores for accessing DRAM simultaneously, and also together with the Mali GPU at the same time
<ssvb>
because otherwise the memory bandwidth measurements are limited by how much a single CPU core can consume, and this is a bit artificial
<cooper>
So just a combination of curiosity and the abundant availablity of boards with a more capable chip.
khuey|away is now known as khuey
<cooper>
And here I was expecting something like "Phase 3 in our plan for world domination"...
leviathancn has quit [Ping timeout: 264 seconds]
<ssvb>
with a 32-bit DRAM bus width and 648MHz DRAM clock speed we may expect 648MHz * 32 bits * 2 = 5.2 GB/s theoretical memory bandwidth limit
<cooper>
Nice.
<ssvb>
the benchmark shows that writing to DRAM by both the CPU and GPU at once, we may consume up to ~3.6 GB/s
<ssvb>
which means roughly 70% memory bandwidth utilization at best :)
ganbold_ has quit [Ping timeout: 255 seconds]
<ssvb>
tuning the timing parameters may probably improve this percentage
naobsd has quit [Quit: naobsd]
<cooper>
Thanks for explaning this.
<cooper>
explaining
cooper has quit [Quit: Off to feed the bed bugs.]
nove has quit [Quit: nove]
ksdncv has joined #linux-sunxi
VargaD has quit [Ping timeout: 245 seconds]
<Turl>
moin :)
froolap has quit [Ping timeout: 244 seconds]
VargaD has joined #linux-sunxi
VargaD_ has joined #linux-sunxi
VargaD- has joined #linux-sunxi
VargaD has quit [Ping timeout: 276 seconds]
VargaD- is now known as VargaD
VargaD_ has quit [Ping timeout: 246 seconds]
<atsampson>
ssvb: hmm -- ignore me regarding routing -- I'm being stupid
<atsampson>
I was looking at how the data lines from the A20 correspond to those on the DRAM chips, and they're mixed up more-or-less randomly, but they aren't mixed up between the different lanes (i.e. D0-7 are still D0-7, just in a different order)
<atsampson>
ssvb: do you have any suggestions for dqs_gating_delay values to try? before I fixed it, it would occasionally autodetect values like 0x07070706...
<ssvb>
atsampson: ok, maybe they are already fine
<ssvb>
you could try different values like 0x05050505, 0x06060606, 0x07070707, 0x08080808, check what fails to boot and pick something in the middle
<atsampson>
that's probably a job for the weekend...
<ssvb>
but this probably will not improve anything, and 0x07070707 would be already the best
gianMOD has joined #linux-sunxi
<atsampson>
I had a couple more questions that you probably know the answers to...
<atsampson>
what are sensible limits for DCDC3 voltages? the A20 datasheet says it's OK with up to 1.4V; is there a reason you've used 1.325V in your calibration examples?
<atsampson>
and how is termination for the address lines on the DRAMs configured? I can see the bits for toggling ODT for DQ* and DQS*, but on this board those lines only go to one DRAM chip and the address lines go to both...
<ssvb>
higher DCDC3 voltages did not seem to improve anything for me, and also I tried to be a bit conservative about this stuff
<ssvb>
the DQ and DQS lines should go to both chips (16 lines to one, and 16 more lines to another)
<atsampson>
yes; I mean that each DQ/DQS line goes to one chip, but each A line goes to both chips
<atsampson>
(e.g. A20 SDQ5 goes to DQL0 on one of the DRAMs, but A20 SA0 goes to A0 on DRAM 1 and A0 on DRAM 2...)
<ssvb>
yes, the address is set the same for both chips, additional chips only provide more bits of data
<atsampson>
yeah, but how's the address bus terminated? if it's routed to one chip then the other (fly-by), then you'd only want it terminated by the second chip
<ssvb>
if I understand it correctly, ODT is not used for the address and command lines because they are single directional