flyhorse has quit [Read error: Connection reset by peer]
naobsd has joined #linux-sunxi
cajg has joined #linux-sunxi
Akagi201 has joined #linux-sunxi
Akagi201 has quit [Remote host closed the connection]
Akagi201 has joined #linux-sunxi
FergusL has quit [Read error: Connection reset by peer]
flyhorse_WQTJp has quit [Read error: Connection reset by peer]
flyhorse has joined #linux-sunxi
flyhorse_dCueP has joined #linux-sunxi
FergusL has joined #linux-sunxi
flyhorse has quit [Ping timeout: 272 seconds]
<wens>
who was updating the mainline u-boot progress stuff?
Gerwin_J has quit [Quit: Gerwin_J]
Gerwin_J has joined #linux-sunxi
viccuad has quit [Quit: WeeChat 1.1.1]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
ninolein has joined #linux-sunxi
ninolein_ has quit [Ping timeout: 272 seconds]
flyhorse has joined #linux-sunxi
flyhorse_dCueP has quit [Read error: Connection reset by peer]
indy has quit [Ping timeout: 250 seconds]
cajg has quit [Ping timeout: 276 seconds]
indy has joined #linux-sunxi
DagoRed has quit [Ping timeout: 246 seconds]
kaspter has joined #linux-sunxi
nicksydney has joined #linux-sunxi
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
nicksydney_ has joined #linux-sunxi
nicksydney has quit [Ping timeout: 244 seconds]
kaspter has quit [Read error: Connection reset by peer]
nicksydney has joined #linux-sunxi
nicksydney_ has quit [Ping timeout: 244 seconds]
bobryan has quit [Ping timeout: 250 seconds]
nicksydney_ has joined #linux-sunxi
nicksydney has quit [Ping timeout: 244 seconds]
bobryan has joined #linux-sunxi
physis has quit [Read error: Connection reset by peer]
physis has joined #linux-sunxi
bobryan has quit [Ping timeout: 252 seconds]
nicksydney has joined #linux-sunxi
nicksydney_ has quit [Ping timeout: 244 seconds]
bobryan has joined #linux-sunxi
iflema has joined #linux-sunxi
bobryan has quit [Ping timeout: 276 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
bobryan has joined #linux-sunxi
nicksydney_ has joined #linux-sunxi
nicksydney has quit [Ping timeout: 244 seconds]
iflema has quit [Quit: WeeChat 0.3.8]
JohnDoe_71Rus has joined #linux-sunxi
nicksydney has joined #linux-sunxi
nicksydney_ has quit [Ping timeout: 244 seconds]
flyhorse_XxSRu has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]
cubeast has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
nicksydney has quit [Ping timeout: 244 seconds]
philippe_fouquet has joined #linux-sunxi
domidumont has joined #linux-sunxi
dev1990 has joined #linux-sunxi
dev1990 has quit [Client Quit]
nicksydney has joined #linux-sunxi
simosx has joined #linux-sunxi
sehraf has joined #linux-sunxi
nicksydney_ has joined #linux-sunxi
nicksydney has quit [Ping timeout: 244 seconds]
nicksydney has joined #linux-sunxi
nicksydney_ has quit [Ping timeout: 244 seconds]
nicksydney has quit [Read error: Connection reset by peer]
nicksydney has joined #linux-sunxi
diego_r has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
domidumont has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
enrico_ has joined #linux-sunxi
nicksydney has quit [Ping timeout: 244 seconds]
arete74 has joined #linux-sunxi
nicksydney has joined #linux-sunxi
p1u3sch1 has joined #linux-sunxi
nicksydney_ has joined #linux-sunxi
arossdotme has quit [Ping timeout: 258 seconds]
nicksydney has quit [Ping timeout: 272 seconds]
flyhorse has joined #linux-sunxi
flyhorse_XxSRu has quit [Read error: Connection reset by peer]
naobsd1 has joined #linux-sunxi
naobsd1 has quit [Remote host closed the connection]
nicksydney has joined #linux-sunxi
naobsd has quit [Ping timeout: 256 seconds]
nicksydney_ has quit [Ping timeout: 272 seconds]
arossdotme has joined #linux-sunxi
nicksydney_ has joined #linux-sunxi
marcin_ has quit [Ping timeout: 264 seconds]
nicksydney has quit [Ping timeout: 272 seconds]
prz has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
physis has quit [Ping timeout: 264 seconds]
nicksydney has joined #linux-sunxi
nicksydney has quit [Remote host closed the connection]
physis has joined #linux-sunxi
nicksydney_ has quit [Ping timeout: 272 seconds]
bmk has quit [Ping timeout: 246 seconds]
ninolein has quit [Remote host closed the connection]
ninolein has joined #linux-sunxi
marcin_ has joined #linux-sunxi
physis has quit [Ping timeout: 272 seconds]
awe00 has joined #linux-sunxi
cajg has joined #linux-sunxi
reinforce has joined #linux-sunxi
p1u3sch1_ has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 250 seconds]
hno has quit [Quit: Coyote finally caught me]
awe00 has quit [Ping timeout: 264 seconds]
awe00 has joined #linux-sunxi
trepidaciousMBR2 has joined #linux-sunxi
<trepidaciousMBR2>
Anyone else running bananian on a banana pro and getting really laggy performance of SSH over ethernet? I get maybe 1 second interruptions as I type, before I get the echo back, it makes it really hard to use...
<trepidaciousMBR2>
Running pings gives a reasonable latency, no spikes, transfers across the network seem ok, just SSH is terrible
diego71 has quit [Ping timeout: 246 seconds]
diego71 has joined #linux-sunxi
pmattern has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
trepidaciousMB-1 has joined #linux-sunxi
trepidaciousMBR2 has quit [Ping timeout: 244 seconds]
HeHoPMaJIeH has quit [Ping timeout: 245 seconds]
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
Akagi201 has quit []
trepidaciousMB-1 has quit [Quit: trepidaciousMB-1]
trepidaciousMBR2 has joined #linux-sunxi
flyhorse_iEacw has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]
physis has joined #linux-sunxi
trepidaciousMBR2 has quit [Quit: trepidaciousMBR2]
trepidaciousMBR2 has joined #linux-sunxi
indy has quit [Ping timeout: 265 seconds]
mrl has joined #linux-sunxi
domidumont has joined #linux-sunxi
indy has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
domidumont has quit [Quit: Leaving.]
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 240 seconds]
firnsy has quit [Ping timeout: 258 seconds]
firnsy has joined #linux-sunxi
firnsy has joined #linux-sunxi
iflema has joined #linux-sunxi
<sunxi_fan1>
hello, i'm playing with hansg sunxi-wip mainline with audio codec patch.
<sunxi_fan1>
i'm actually testing on a Cubieboard A10 devboard so i've made my homework and installed the proper DTS links for having the module recognize the HW through DTS
<sunxi_fan1>
so the modules stand up ok AFAIK in dmesg:
<sunxi_fan1>
but i'm wondering if this modules is supposed to be working, i.e. if you can hear some sound out of the earphone jack or if there are still some glitches on the SOC audio config.. because i've read on older mailing list that the "driver" was somewhat still broken..
<sunxi_fan1>
can anyone shed some light?
<mripard>
I haven't look at hans' kernel for a while, but it should be working
<sunxi_fan1>
as far as i can see, the testing (and the patches) has actually been made only on "cubietruck" right?
<sunxi_fan1>
because the codec entry was present only in the sunxi-a20.dtsi ..
<sunxi_fan1>
and i had to retrofit on sun4i-a10.dtsi for it to being available to my sun41-cubieboard.dts
<mripard>
I tested it on a cubie 2, and it works
<sunxi_fan1>
(ps the name could be slighly different, i'm writing from memory but the concept of the dts structure should be similar)
<sunxi_fan1>
ok, so more or less, the audio codec has not been tested on a A10 based board, right?
cubeast has quit [Quit: Leaving]
<mripard>
it has been
<mripard>
on a mele a1000
<mripard>
which has an A10
<sunxi_fan1>
really? because AFAICS the proper binding of the "codec" entry where not present in the A10 DTSI and "enabled" (status='ok') on the DTS (at least for the cubieboard 1; maybe the Mele has a different DTS)
<mripard>
well, just because hans doesn't have that patch doesn't mean the driver doesn't work...
<sunxi_fan1>
yes, sure. i suppose it should work too!
<sunxi_fan1>
it's that i was just testing and i was wondering why the patch for the DTSI entry was missing on A10 DTSI, this one, i mean:
<sunxi_fan1>
i'll try with just 30 and report. thanx..
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<mripard>
sunxi_fan1: yeah, and it works for the A20 and not the A10
trepidaciousMBR2 has joined #linux-sunxi
orly_owl has quit [Read error: Connection reset by peer]
orly_owl has joined #linux-sunxi
flyhorse_iEacw has quit [Ping timeout: 264 seconds]
naobsd has joined #linux-sunxi
trepidaciousMBR2 has quit [Quit: trepidaciousMBR2]
forkit1 has quit [Quit: Leaving.]
<sunxi_fan1>
sorry if i'm going to do questions i could answer myself having a look at the source code and investigating more, but as here there are people willing to answer, the temptation is too high! :-)
<sunxi_fan1>
i had a look both at A10 and A20 user manual, about the "interrupt source". in the a20 manual the "audio codec" has interrupt source SRC=62, on A10 user man, the audio codec is indeed 30 (if it's "Analog Aduio Codec" interrupt, a typo..)
<sunxi_fan1>
so, as the audio codec on Cubietruck is of course working, i'm wondering why it's configured "by default" in the A20 .dtsi as "interrupts = <0 30 4>;", is there some kind of "mapping" between software model and hardware numbers, i should have a look at?
trepidaciousMBR2 has joined #linux-sunxi
<RSpliet>
the ARM GIC defines the first 32 interrupts to be... of a different type than standard interrupts
<RSpliet>
forgive my lack of lingo here
<RSpliet>
the GIC driver offsets numbers defined in the DTS by 32 I think, they might actually be the same thing
<mripard>
sunxi_fan1: the A10 and A20 don't have the same interrupt controller, and not the same representation of the interrupts.
<sunxi_fan1>
i see. as the A20 is more or less a "enhanced version" of A10, i supposed it was just a copycat in some basic modules like INTC, but as you are saying, this is not the case, so i'll going to give a more through look both at manuals and source codes..
<mripard>
you don't need to.
<mripard>
just put interrupts = <30>; instead
<mripard>
and it should work.
<sunxi_fan1>
i've tried with <30> but still aplay is spitting out the "i/o write error" after twenty secs. sorry if i forgot to tell in advance..
<mripard>
did you increase the volume and enable the mixers ?
<sunxi_fan1>
BTW i'm giving a look at the sunxi-codec.c and i see NO pr_debug() calls at all. i'm a bit puzzled because i thought it was an useful tool for debugging when needed (using the compile option -DDEBUG) and no cost (in term of performance..) when not used.. is this "pr_debug()" enrichment not seen as "good practice" on kernel patches?
gzamboni has quit [Ping timeout: 264 seconds]
iamfrankenstein1 has quit [Ping timeout: 264 seconds]
<sunxi_fan1>
mripard: as i started, in the last few days, the task to port the linux-sunxi legacy I2S support to mainline, let me tell you it's been an interesting trip into the "alsa ASoC machinery". after my first survey of the sound/soc/... subtree and some look at the
<sunxi_fan1>
.. source code of a SOC alredy using the UDA1380 codec. (a samsung and a PXA magician tablet/pad/mobile.. don't know ,really.. )
<sunxi_fan1>
i understand the subdivision between three levels:
<sunxi_fan1>
- board/machine/device on one hand (AFAIK this is the high level bind between codec and SOC in my "board")
<sunxi_fan1>
- platform with DAI in the middle (i suppose this could be bound to the A20 Soc+DAI)
<sunxi_fan1>
- codec (this is really the UDA1380.c source code)
Gerwin_J has joined #linux-sunxi
<sunxi_fan1>
so i started from the sunxi-codec.c source code that's putting all these three models together in one source file, and getting out the codec part
mrl has quit [Quit: 离开]
<mripard>
why?
<sunxi_fan1>
then i changed all the init of the DAI from the "audio codec" to the I2S DAI registers. it's not that bad as a process. now i have compiling source code and suppose to start doing debugging with register printouts on real HW, but first i decide to test for real how it's working the "sunxi-codec", and it was useful already as i understood there are already binding to DTS that i need to enable in my code too. and there's the DMA en
trepidaciousMBR2 has quit [Quit: trepidaciousMBR2]
<mripard>
there's a reason why it's all tied together
<mripard>
and you should rather be looking at other DAI drivers for now
trepidaciousMBR2 has joined #linux-sunxi
<mripard>
ideally ones that use the generic dmaengine stuff
<sunxi_fan1>
in the sunxi-codec, as it's a "embedded" and standard codec in every sun4i/sun7i, the reason is clear..
<mripard>
the "codec" in the A10 is actually not a codec
<mripard>
it's a DAI and a codec, tied together in a static way
<mripard>
(if you map that to ASoC)
<mripard>
so there's *really* a reason why we did it that way
<mripard>
and you should really not undo that.
gzamboni has joined #linux-sunxi
trepidaciousMBR2 has quit [Client Quit]
<sunxi_fan1>
i indeed started working with other different approaches, from a ti omap source with dmaengine support and an external codec, and again from the PXA magician with UDA1380 but no DMA engine, but at the end i found there were distracting me a lot, as they were a bit different then sunxi SOC.
<mripard>
it's not different
<mripard>
it's actually very similar.
<sunxi_fan1>
so to make a long story short, i had a look at the many different designs present in sound/soc directory to understand they are all in "different stages" then the actual status of a properly designed and recent alsa ASOC driver.. at least this is my feeling. of course all of them do have support for the basic stuff: registers, DMA and INT, but some with different API still available in the mainline kernel.
<sunxi_fan1>
yes yes, you are right: at high level they are all abstracted on the three level splitted model board - platform - codec..
<sunxi_fan1>
but the underlying machinery for accessing registers (now regmap_update_bits() and similar but older are using different API AFAICS) and DMA (only some are using dmaengine AFAICS) is different.. right?
<mripard>
well, older driver are old
<mripard>
you should use regmap and dma
trepidaciousMBR2 has joined #linux-sunxi
<mripard>
you can have a look at tegra30_i2s if you want.
<sunxi_fan1>
then there's the DTS environment: some drivers do get info from that source (like sunxi-codec is doing..) and some really do have hardcoded values..
<mripard>
DT is only used on some architectures, and for some of them, since not very long ago
<sunxi_fan1>
that's why i decided, after some false starts, to rip away the internal codec stuff from sunxi-codec and use that clearer/recent framework for doing my port of I2S..
<mripard>
why are you doing everything from scratch?
<mripard>
I gave you some nice driver using asoc already?
<mripard>
can't you use that as a starting point instead?
<wens>
seems like allwinner is in town for computex
<sunxi_fan1>
sorry, i suppose it looks like i'm not explaining clearly enough. (or i have not understood anything at all.. it could be really true too..).
<sunxi_fan1>
isn't the sunxi-codec.c a modern and properly designed Alsa ASOC driver (and quite a compact one.. as it's a single source code?)
trepidaciousMBR2 has quit [Ping timeout: 272 seconds]
trepidaciousMBR2 has joined #linux-sunxi
<mripard>
sunxi_fan1: sorry if I don't explain clearly enough. no it's not if you want to do an i2s driver
domidumont has quit [Read error: Connection reset by peer]
<sunxi_fan1>
wait a moment, let me tell you what i have understood "a I2S driver" actually is... so we can agree on the basics..
<sunxi_fan1>
actually a I2S driver is the "platform" driver of the SOC that's dealing with the hardware DAI in the I2S mode (a Sun4i/sun7i could also have a Hdmi-audio and SPDI DAI too, as there are also those hardware modules inside those SOCs and indeed the legacy linux-sunxi 3.4 has drivers for those DAIs too..)
<mripard>
I really fail to understand why would you want to take as an example an overly-complicated and not in proper state driver, while there's some drivers that use the architecture you need to use, and with the right APIs already.
<mripard>
and while you're pointed to them, you just ignore this fact
<sunxi_fan1>
that's all well and good. but in the short term, as all i want is to listen some good music :-) on my Waveshare UDA1380 codec, i need to do also the "machine driver" (i called it snd-soc-a20-waveshare.ko) to bind together platform & codec. is that a workable approach?
<mripard>
in the short term, you'll still have to write your own driver.
<mripard>
and I already told you that, but you should use simple-card and not your own machine driver.
<mripard>
so you really just have to write an i2s driver
JohnDoe_71Rus has joined #linux-sunxi
Netlynx has joined #linux-sunxi
philippe_fouquet has quit [Remote host closed the connection]
flyhorse has joined #linux-sunxi
flyhorse_FKedI has joined #linux-sunxi
flyhorse has quit [Ping timeout: 256 seconds]
flyhorse has joined #linux-sunxi
flyhorse_FKedI has quit [Ping timeout: 245 seconds]
bonbons has joined #linux-sunxi
trepidaciousMBR2 has quit [Quit: trepidaciousMBR2]
trepidaciousMBR2 has joined #linux-sunxi
leviathancn has joined #linux-sunxi
flyhorse_eKCqQ has joined #linux-sunxi
flyhorse_OQsUa has joined #linux-sunxi
prz has quit [Quit: Leaving.]
flyhorse has quit [Ping timeout: 244 seconds]
flyhorse_eKCqQ has quit [Ping timeout: 256 seconds]
flyhorse_OQsUa has quit [Ping timeout: 272 seconds]
trepidaciousMBR2 has quit [Quit: trepidaciousMBR2]
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
enrico_ has quit [Quit: Bye]
khuey|away is now known as khuey
awe00 has quit [Ping timeout: 240 seconds]
flyhorse has joined #linux-sunxi
flyhorse has quit [Ping timeout: 265 seconds]
diego_r has quit [Ping timeout: 272 seconds]
domidumont has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
gzamboni has quit [Ping timeout: 264 seconds]
flyhorse has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]
ricardocrudo has quit [Ping timeout: 245 seconds]
oliv3r has quit [Ping timeout: 244 seconds]
flyhorse has joined #linux-sunxi
gzamboni has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
flyhorse has quit [Ping timeout: 258 seconds]
flyhorse has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]
flyhorse_SYHVC has joined #linux-sunxi
flyhorse_SYHVC has quit [Read error: Connection reset by peer]
flyhorse has joined #linux-sunxi
oliv3r has joined #linux-sunxi
cosm has quit [Ping timeout: 276 seconds]
dev1990 has joined #linux-sunxi
bobryan has quit [Read error: Connection reset by peer]
\\Mr_C\\ has quit [Quit: .]
FDCX_ has joined #linux-sunxi
sunxi_fan has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
trepidaciousMBR2 has joined #linux-sunxi
<sunxi_fan>
mripard: with regard to sunxi-codec on A10 Cubieboard, it turns out you were right; toggling the alsamixer setting, i started listening music, at least from the left earphone.
<sunxi_fan>
i started moving the knobs up and down, but i could just move from mute to left ear and back; when it was written "mute" on alsamixer gui, the audio was playing, so the mixer is not very right on my setup.. moreover when in the position where it was really muted, again on mplayer console, messages of "audio device is stuck" , but "unmuting" the device, the music started again..
<sunxi_fan>
simosx: i'm using buildroot 15.02 with my own config of packages and libraries and i'm using linaro compiler gnueabihf IIRC. do you think it could matter?
<sunxi_fan>
BTW i find buldroot a simpler / better enviroment for embedded root fs, (then full dekstop distro like debian..)
<sunxi_fan>
mripard: i wrote a more extensive report on linux-sunxi ML (or google-group.. i don't understand what is that :-) . anyway i find confusing the alsamixer controls of the sunxi-codec driver.
<sunxi_fan>
i see four controls: DAC output, Left Mixer, PA, Right Mixer.
<sunxi_fan>
i should really check better the audio routing scheme on Allwinner manual to understand what those controls are doing between input(s) (the DACs and the direct route from line-in, i suppose) and output and which routing mixins are possible.
<sunxi_fan>
anyway i suppose everything would clear out if i could ear the left and right channels in their proper earphones. :-) actually the best i could do is to hear both channels mixed together on the left ear only. any hint?
iamfrankenstein has quit [Ping timeout: 250 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
<mripard>
sunxi_fan: yeah, enable the right mixer.
<sunxi_fan>
looks pretty similar and also quite simple on the DAC path from Bus to earphones. i'm wondering how can the L&R mixing can happen along the path (the sound in earphone is smooth, un-distorted and at the right sample rate)
iamfrankenstein has joined #linux-sunxi
trepidaciousMBR2 has quit [Quit: trepidaciousMBR2]