<rellla>
second part is a complete redo of sun7i_defconfig. it was completely messed up. now it's a 1-1 copy of sun4i_defconfig with ARCH set to sun7i. it's working here as expected.
<libv>
MY123: i have a blog entry in the works
<libv>
and i am now on a project which uses the rogue
<libv>
since i was burned on pvr with the nokia n9 already (and powervr is the only thing i am burnt on), this is fine, and it will be interesting to see to which extent imagination has been up to its old tricks again
<libv>
_BTU_
<libv>
_BUT_ even
<libv>
the isa is where all the optimizations are
<libv>
the command stream is much less ip sensitive
<libv>
but...
<libv>
img should take responsibility of freeing that themselves
<libv>
the way they use that hardware means that every customer, even every device, has a different microcode, different kernel and different userspace
<libv>
so loads of REing would have to happen for just every device
<MY123>
libv: I already coded an ASM opencl sample (bin) which works well
akaizen has joined #linux-sunxi
<MY123>
in several devices
<libv>
again, this is the shaders
<ijc>
wens: Great, thanks. Sorry for the delay's in my replies.
<libv>
it tells you very little about how to actually get the hardware working
<libv>
it's a big chunk of the work that we no longer need to do
<libv>
but... the basic problem of powervr persists
FR^2 has joined #linux-sunxi
hehopmajieh__ has joined #linux-sunxi
HeHoPMaJIeH has quit [Read error: Connection reset by peer]
joost_dtn has joined #linux-sunxi
notmart has joined #linux-sunxi
Quarx has joined #linux-sunxi
_ccube has quit [Remote host closed the connection]
ccube has joined #linux-sunxi
hehopmajieh__ has quit [Read error: Connection reset by peer]
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has quit [Client Quit]
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
wickwire has joined #linux-sunxi
bertrik has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
akaizen_ has joined #linux-sunxi
akaizen has quit [Ping timeout: 265 seconds]
popolon has joined #linux-sunxi
HeHoPMaJIeH has quit [Ping timeout: 260 seconds]
HeHoPMaJIeH has joined #linux-sunxi
<wens>
ijc: just sent out v2
<ijc>
wens: smashing, thanks!
<ijc>
Does the new series incorporate the sun6i/8i watchdog/timer stuff (the separate 3 patch series)?
HeHoPMaJIeH has quit [Ping timeout: 272 seconds]
HeHoPMaJIeH has joined #linux-sunxi
<wens>
nope
<wens>
i'll send those out later
<ijc>
wens: I could just drop the while loop in the third one(the only problem) as I commit if you like.
<wens>
that would do :)
Zboonet has joined #linux-sunxi
Zboonet has quit [Client Quit]
hehopmajieh__ has joined #linux-sunxi
HeHoPMaJIeH has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
<afaerber>
wens, FEL> don't see such a notice on either FEL or FEL/USBBoot - do you know which sizes should work?
<afaerber>
my kernel is around 30MB and worked okay
<afaerber>
oops, 3MB ;)
<wens>
30mb... is that an allyes config? :p
<afaerber>
no, just me still being tired after a night of hacking :P
<afaerber>
300MB not working, 3MB working
<afaerber>
it looks as if the fel command has not support for transferring part of a file, so I assume I need to copy parts via dd into new files and then transfer those?
deasy has joined #linux-sunxi
<afaerber>
or use just some busybox or so
Faisal has quit [Ping timeout: 258 seconds]
_massi has joined #linux-sunxi
physis has quit []
hamma has joined #linux-sunxi
<hamma>
Hi guys
<hamma>
anyone managed to make the mcp3008 work on the olinuxino lime?
bengal has joined #linux-sunxi
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
melonipoika_ has joined #linux-sunxi
rmax has joined #linux-sunxi
Faisal has joined #linux-sunxi
Faisal has quit [Read error: Connection reset by peer]
Faisal has joined #linux-sunxi
MY123 has quit [Quit: Connection closed for inactivity]
_massi has quit [Remote host closed the connection]
<Turl>
mripard: puns don't travel well over the intertubes it seems
<mripard>
aaaaah :)
<ijc>
indy: Your 3.5" hdd probably needs 5V+12V, whereas 2.5" sometimes only need 5V. The cubie only provides 5V
<indy>
ijc, i know, but question is why ssd drive is not detected while 2.5" drive is? ssd i can power when cubieboard is even on usb only and kernel it detects and can work with it
EGM has joined #linux-sunxi
<oliv3r>
ijc: sometimes? pff you are the only one i ever heard of :p
captainigloo is now known as captainigloo2
captainigloo2 is now known as captainigloo
<oliv3r>
ijc: negate that :p yours the only 2'5" disk that needs more then 5V
<oliv3r>
mripard: 3.18-rc1 does the same; i'll bisect properly tomorrow; i'll do a 3.17 tag (again) first to verify that one really does still work
hehopmajieh__ has quit [Quit: Konversation terminated!]
jemk has joined #linux-sunxi
<jemk>
rellla: I tested deinterlacer on VGA, it works pretty well except some flickering because of setting the new framebuffer twice
<jemk>
rellla: in layer_set_para and in video_set_fb, if the vblank happens inbetween the interlaced frame is shown for a short time
EGM has quit [Quit: Page closed]
<rellla>
jemk: what does initiate the deinterlacing process? is it DE_SCAL_Vpp_Enable via video_enhancement_start? and
<rellla>
waht does set the parameters dit_enable? imo it's Hal_Set_Frame <- Video_Operation_In_Vblanking <- LCD_vbi_event_proc
<jemk>
rellla: I didn't look at the disp code, so no idea how it works exactly, I only tried to set __disp_video_fb_t.interlace=1 and it worked somehow
<rellla>
jemk: i assume, that vga is somewhat internally connected to lcd, so that could be the reason, why it may work for you. do you have the chance to try hdmi?
leviathanch has joined #linux-sunxi
gzamboni has quit [Ping timeout: 265 seconds]
dack has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
gzamboni has joined #linux-sunxi
philippe_fouquet has quit [Remote host closed the connection]
<jemk>
rellla: looks like hdmi doesn't work... But don't ask me why
leviathanch has quit [Ping timeout: 244 seconds]
libv_ has joined #linux-sunxi
<rmax>
Does installing and activating a manipulated script.bin take more than copying it to the /dev/nanda partition on the device?
<libv>
it looks pretty complete, but it lost its ndh status a while ago, no?
<Turl>
libv: just asking, I've got one with the stock sw still
<Turl>
if you need anything from it just let me know
<libv>
ah, i see
<libv>
you collected the meminfo, right?
<libv>
and the script.bin?
<Turl>
libv: I haven't collected anything so far, I only booted it once to try it out
<Turl>
libv: do you want me to run through ndh then?
<rmax>
libv: seen my patch for nandc? Is it OK this way, as I am not so familiar with submitting patches through git?
<rmax>
s/nandc/fexc/
<libv>
rmax: i haven't and i am not in a position to do much there
<libv>
Turl: just script.bin and the meminfo should do
<rmax>
libv: who is maintaining those git repos?
<libv>
several of us, me, mnemoc, Turl, hno
<dack>
If A20 supports GMAC and EMAC, shouldn't both drivers work? Would it be restricted by which PHY you're using?
<Turl>
dack: yeah, it depends on how the phy is connected
<dack>
Turl: ah.. okay. Thanks
<rmax>
What's the usual procedure? Will I get notified when a patch has been accepted or denied?
<Turl>
dack: I believe you can use gmac on all current 100 and GbE boards with A20
<Turl>
rmax: did you send it by mail?
<dack>
libv: any change on the libnand front? It still seems to be included in the sun7i_defconf... I think it should be removed until it's at least not wiping NANDs. ;)
<libv>
dack: no, sorry
<libv>
dack: send a patch :)
<rmax>
Turl: yes, as described in the Wiki.
<libv>
dack: i kind of lost the overview in the last week or so
<dack>
libv: are patches even considered when they're github pull requests? It seems to be mailing list only, right?
<libv>
dack: yeah, our workflow does not seem to take pull requests into account atm
<Turl>
rmax: we usually reply something like "applied, thanks" when it gets in
<Turl>
rmax: otherwise you may get some comments on how to do things better or so from people
<dack>
Turl: hmm.. I have ICplus IP101A and I can't seem to get the sunxi_gmac driver working
<Turl>
libv: I got some github spam about some pull request on a lima/mali repo to add .pc files or something, take a look when you get a chance
<libv>
Turl: i know
<rmax>
I don't mean to push, just want to make sure I didn't make a mistake.
<dack>
also, if I include both sunxi_emac and sunxi_gmac as modules the kernel won't automatically select either for loading
<libv>
i just haven't gotten round to setting up mali binaries on a system for like 10 months or so
bonbons has joined #linux-sunxi
<libv>
it's terrible to leave these guys dangling like that
<libv>
but there are so many things todo
<Turl>
rmax: I'm not really familiar with that parsing code to say, but patch wise it looks ok
<libv>
nobody is familiar with that code anymore :)
<Turl>
maybe you could've included a signoff, not sure if we're enforcing that on those tools, mnemoc should know :)
Akagi201 has joined #linux-sunxi
<libv>
mnemoc quickly wrote it like 2 years ago iirc
<rmax>
After applying this patch, converting my script0.bin to fex and back results in a binary identical file to the original.
<Turl>
dack: yeah, mmio hardware is not autodiscoverable :) load one of them
<Turl>
and check your fex configs
<Turl>
libv: rewriting it in haskell may be a nice summer exercise :p
<dack>
Turl: k.. I'll double check the fex settings. The eth0 is messed up and constantly thinks it's connected when nothing is connected. I thought I'd fixed it with the PHY driver, but it's still a problem
<libv>
Turl: are you above or below the equator?
<Turl>
libv: below
<libv>
Turl: start writing now :p
<Turl>
libv: you need some geography classes? :P
<libv>
:)
<Turl>
libv: 29C now :(
<dack>
isn't it still spring in the southern hemisphere?
<rmax>
Turl: Please send us some of that heat. Over here the temperature dropped well below 10C last night. :(
<Turl>
dack: yep it is
<Turl>
rmax: I'd love those temps :)
<rmax>
Turl: I am sure you won't as they come with wind and rain for free.
<Turl>
rmax: even better :)
<Turl>
cold you can fix, but you can't get rid of heat that easily
<rmax>
wens is the go-to person regarding A23 and q8h, right? Or is there anyone else?
<rafaelMOD>
GUYS!!! I finaly made the i2s work! Capture and playback! And you cant imagine the real problem, sunxi-i2s.h WAS WRONG aff!! 1 week debugging the capture to find that #define SUNXI_IISINT_RXDRQEN is wrong in the .h
<rafaelMOD>
#define SUNXI_IISINT_RXDRQEN(1<<2) should be #define SUNXI_IISINT_RXDRQEN(1<<3)
<rafaelMOD>
!!!!
<Turl>
rafaelMOD: heh, something wrong on their code, what a shock :P
<Turl>
rafaelMOD: glad you got it going :)
<rafaelMOD>
Turl thanks, i will pull request soon
<libv>
rafaelMOD: great catch :)
<libv>
rafaelMOD: email!
<rafaelMOD>
I made major changes on i2s and i2s dma on sunxi-3.4
<rafaelMOD>
But works perfectly now
<libv>
rafaelMOD: how did the kickstarter work out?
<rafaelMOD>
And the last thing i would ever think was wrong was the .h! 1 week debbugging got me crazy, as last resource i started checking all the .h registers with the datasheet and couldn't belive this was the problem
<rafaelMOD>
libv: we got funded!!!!
<libv>
congrats!
<rafaelMOD>
thanks!!!
<libv>
ooh, 17k surplus
<libv>
well done :)
<rafaelMOD>
we are developing that open hardware board right now, A23/A33 and an open hardware base board focused on sound, with 1/4 connectors and external i2s codec
<rafaelMOD>
I would like to discuss this board with you guys
nicksydney_ has joined #linux-sunxi
<rafaelMOD>
what do you think is the minimal requisites for that board
<libv>
rafaelMOD: space thrusters
<rmax>
sounds like board vendors son't use the i2s very often, so that the mistake wasn't detected before.
nicksydney has quit [Ping timeout: 244 seconds]
<rafaelMOD>
the sound requisites i already have, i will extern the i2s, i will put an i2s codec, i will extern the spdif and the internal codec
<libv>
rafaelMOD: nah, as much memory as you can cram on it, uart, and a connector for a display
<rafaelMOD>
for display, vga is enough?
<libv>
will it do that?
<libv>
i was thinking like an olimex lcd
<rmax>
rafaelMOD: sounds interesting. What price are you targetting? And does that mean that you will get access to parts of the A23 specs that are not public yet?
<rafaelMOD>
the problem with olimex like lcd is that there are to many pins! vga is way less complex for layout!
<libv>
rafaelMOD: it has dacs? or would you provide dacs yourself like the olimex a13?
<rafaelMOD>
For the coreboard we are targeting a production cost od USD30
<rafaelMOD>
libv: for the sound conversion we will use and external CODEC with HI-FI ADC and DAC
<rafaelMOD>
and with some AMPOP buffering-filtering
<rafaelMOD>
A simplified MOD-Duo
<rafaelMOD>
But it will extern all the audio of A23/A33, I2S SPDIF and Internal Codec
<libv>
rafaelMOD: does a23/a33 have the tv encoder block, and are the pins exposed?
<rafaelMOD>
libv: i dont know, let me check. I never paid attention on that
nicksydney has joined #linux-sunxi
<rafaelMOD>
rmax: i already have some hardware docs of A23, but we had to sign a NDA to get them, and my CEO doesn't want to break it, as we are reeeally small here. But to get around that we will publish all the project as open hardware, even with KiCad project files
nicksydney_ has quit [Ping timeout: 244 seconds]
<rafaelMOD>
So we will do a shematic based on their Eval Board of A23 and release it. And the only important document that we got our hands on was this A23 Eval
<rmax>
rafaelMOD: I was just curious and of course don't want you to break NDAs.
<rmax>
But do you have access to SDRAM setup details of the A23, and if so, is that also covered by the NDA? AFAIU DRAM initialisation is one of the biggest issues for getting proper A23 support into linux-sunxi.
<rmax>
But then, I am fairly new to the project.
<rafaelMOD>
The only document is the "Allwinner A23 SDRAM Support List"
<rafaelMOD>
in which are listed only 2 Hynix memories
<rafaelMOD>
H5TQ4G83AFR-xxC AND HTQ4G63AFR-xxC
<rmax>
I don't want to build new hardware, I want to run Linux on existing hardware. ;)
<rafaelMOD>
In my case i need both!
<rafaelMOD>
New hardware with linux running
<rafaelMOD>
libv: i didn't find anything about tv encoder block, but i dont really know what is that! there is a Display Engine with encoding/decoding, a Video Input and a Video Output
<libv>
rafaelMOD: then the hw does not have dacs to drive vga
<libv>
rafaelMOD: olimex did a workaround
<libv>
used the lcd lines to drive the dacs and the sync
<libv>
so they used like 3*6 + 2
<libv>
lines
<rafaelMOD>
Ahn, now i got it.
<rafaelMOD>
So considering the pin count, its better to put a regular display, i didn't worked on this part yet
<libv>
well, olimex ended up using all the pins anyway
<libv>
the ones that would be used for lcd that is
pwhalen has quit [Ping timeout: 240 seconds]
<rafaelMOD>
libv: witch display is more common, RGB MIPI or LVDs?
<libv>
rgb is very common
MY123 has quit []
<rafaelMOD>
so i shall put a rgb connector
<libv>
if possible :)
nabblet has quit [Quit: leaving]
pwhalen has joined #linux-sunxi
akaizen_ has quit [Remote host closed the connection]
Faisal has quit [Read error: Connection reset by peer]
Faisal has joined #linux-sunxi
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 260 seconds]
notmart has quit [Quit: notmart terminated!]
_massi has quit [Remote host closed the connection]
wickwire has quit [Read error: Connection reset by peer]
<rmax>
libv: do you have a moment to answer a few more questions to improve my basic understanding of how things work togeter?
<dack>
Turl: does the sunxi_gmac driver supplant the emac one? or do you need both when doing gigabit connections?
<Turl>
dack: they're different hw blocks, you just need the gmac one
<dack>
Turl: k.. I think my device only supports emac, so I'll stick with that.
<Turl>
dack: if emac works then in theory gmac should too
<dack>
Turl: I looked at the fex and see that emac is turned on... I have no idea how to test if the pin configurations are correct, though. Is there even a way?
Andy-D has quit [Ping timeout: 272 seconds]
<dack>
Turl: oh.. well, I think sunxi_gmac is not loading because it sees emac is enabled in the fex
<rafaelMOD>
Turl: about sunxi-3.4 for A20, do you know if there is a way to work with dma buffers without the callback, enqeue functions? do you know if dma_config_t->bconti_mode = true does that trick?
<Turl>
dack: compare to the user manual? :p not that many other ways to check
<Turl>
rafaelMOD: what do you want to achieve?
<rafaelMOD>
i hate to have buffdone callbacks and enqueue on my audio buffer transfers
<dack>
Turl: ah.. k.. good call. I'll see if I can find it
<rafaelMOD>
i would like a more elegant way, and i know ALSA does that alone
<Turl>
rafaelMOD: when you use dmaengine with alsa, you're using circular transfers
<rafaelMOD>
i think all this callbacks on the sound buffers is probably the cause of some alsa underuns
<Turl>
rafaelMOD: but the dma block is pretty dumb and it doesn't even support lists
<rafaelMOD>
mripard told me he think A20 dma on sunxi doesnt have dmaengine, i am still not sure
<rafaelMOD>
but i know you cant use slave dma standard config
<Turl>
3.4 doesn't use dmaengine, indeed
<rafaelMOD>
which i think are needed for alsa taking care of this buffer pointers
<Turl>
it has some random api AW invented
<rafaelMOD>
it really seems invented! inthe A23 latest sunxi3.4 kernel released on allwinner github, it seems that the new DMA does use dmaengine
<rafaelMOD>
as there are calls for slave dma functions
<rafaelMOD>
but i grepped every file of dma on A20 sunxi-3.4 and got nothing for slave configuration
<rafaelMOD>
so i am putting my cards on dma_config_t->bconti_mode, but i dont know how to configure for that and i haven't tested neither coded that
<rafaelMOD>
have you ever used this bconti_mode on dma_config_t on A20?
<Turl>
rafaelMOD: anyway, on mainline I implemented it using dmaengine, but the hardware is really simplistic
<Turl>
rafaelMOD: it doesn't support dma lists
<Turl>
you need to program every buffer you want to copy
<rafaelMOD>
Jhon Smirl told me that the normal dma on the mainline driver still does only one transfer, i need two, one for I2S_TX and one for I2S_RX, actually this is keeping me (plus the lack o time) from migrating to mainline
<Turl>
and as far as I could see, the bcont thing is just like a repeat button
<rafaelMOD>
I was wondering how does the DMA_CONTI_MODE_EN (NDMA_CTRL_REG) works
<rafaelMOD>
on A20
<Turl>
rafaelMOD: that can be revisited I suppose :) I'll rework the driver a bit now that we got some more info from aw
<rafaelMOD>
and how to configure them on the invented A20 dma API
zeRez has joined #linux-sunxi
<Turl>
rafaelMOD: as far as I can see, the continuous mode is like a repeat button, I don't think there'd be any use for it
wingrime1 has joined #linux-sunxi
<Turl>
unless you program a huge buffer and have some way to estimate and tell alsa
<rafaelMOD>
Turl: doesn't it rearrange the buffer pointers based on NDMA_DEST_DATA_WIDTH and DMA_DEST_BST_LEN?
<Turl>
rafaelMOD: rearrange?
<rafaelMOD>
sorry, typo, enqueue and reconfigure the end and start position pointers
<Turl>
those two are the bus width and burst size (ie, how many bits and how many times in a burst)
<rafaelMOD>
the problem i see here is that for every DMA buffer transmition there is a callback call to a bufdone function, and that in sequency calls an enqueue function that reconfigure the dma_end and dma_start pointers
<Turl>
yeah, because the hw doesn't support lists
<rafaelMOD>
that i recall in the first time i programmed a Cortex-M3 ARM was solved in a way that the pointers were auto-reconfigured and you could work without callbacks
<Turl>
if you don't do that, when the buffer is finished nothing happens
<Turl>
other hardware lets you write a list of buffers and their sizes on memory on some format
<Turl>
and pass it to the hw
<Turl>
and the hw takes care of it
<rafaelMOD>
so that bconti_mode will use the same end and start pointers? oh no!
<Turl>
yeah, that'd be my best guess
<Turl>
you should try it, it'd probably make some awful noise :)
<rafaelMOD>
:) i made some AWFULL noises here while implementing the aSoC drivers for our sound card
<rafaelMOD>
but now it hears and sings perfectly
<Turl>
:)
<Turl>
rafaelMOD: so what is your worry with the callbacks?
<Turl>
you just dislike them or do you have issues?
<rafaelMOD>
Do you think i should give a try on that continuos mode? Or thats a no-go?
<Turl>
rafaelMOD: well, sure, you can try :) the aw docs don't say much
<rafaelMOD>
I have some issues with audio transfers, i think all this callbacks are generating some underuns on alsa
<Turl>
rafaelMOD: but I wouldn't have much hope
<rmax>
I have a question regarding DRAM settings:
<rafaelMOD>
i am starting to change priorities now, so i should stop getting this underuns, they are rare, what is worst for findinig the cause! so i am blaming it on callbacks
<rafaelMOD>
and a dma based on callbacks and only using bursts of 8 maximum is crap
<rafaelMOD>
at least for audio!
<rmax>
As long as no details of the A23's DRAM controller are known, shouldn't it be enough to write back the settings gathered by meminfo or am I missing something?
<Turl>
rafaelMOD: the fifos weren't that much bigger, were they?
<rafaelMOD>
124 on rx and 64 on tx
<Turl>
rmax: you need to do some funny dances to initialize memory, it's not a matter of having 1:1 settings I think
<rafaelMOD>
i want to work on alsa with 64 samples transfers, so it would be great to have the same size on dma transfers
<rafaelMOD>
that would be great for audio plugin processig
<rmax>
Turl: I see. And when booting U-Boot from SD, SPL plays the roll of boot0, right?
<wingrime1>
Hmm allwinner fixed some issues towards gpl
<rmax>
... or does SPL run after boot0 from the nand flash?
<rafaelMOD>
wingrime1: which issues and where are them?!
<Turl>
rmax: when using SPL, that's what the ROM on the chip executes after itself
<wingrime1>
In theyir new repo with docs and kernel
<Turl>
rafaelMOD: yeah, max 8 :/
<rmax>
Turl: and after itself means instead of boot0?
<Turl>
rmax: yes, BROM->SPL
<Turl>
on nand it is (used to be?) BROM->BOOT0->BOOT1->U-Boot
<rmax>
Except for A23 AFAIU where there is no BOOT1.
<rafaelMOD>
Turl: what do you think of using DMA_CONTI_MODE_EN with NDMA_DEST_ADDR_TYPE = increment and NDMA_SRC_ADDR_TYPE = No Change for a I2S RX transfer? maybe it just reconfigure the pointers on the destinaton?!
<rafaelMOD>
Plus burst
<Turl>
rafaelMOD: increment sounds wrong there, isn't the destination a fifo?
<Turl>
ah, rx, nevermind
<rafaelMOD>
that would be TX case
<Turl>
rafaelMOD: that'd probably give you a circular audio buffer
<wingrime1>
libv: are you saw new aw repo?
Wes- has quit [Ping timeout: 260 seconds]
<Turl>
rafaelMOD: what are you receiving, stereo 32b?
<dack>
Turl: k.. I found specs on the ICplus IP101A . Wouldn't confirming the configuration requiring following tracings on the board to the AW chip?
amitk has quit [Quit: leaving]
Wes- has joined #linux-sunxi
<rafaelMOD>
i know alsa takes care pf dma pointers, but from my initial studies it need dmaengine and some dma_slave configurations that A20 sunxi-34 doesnt have! DOH!
<hno>
rmax, there is no boot1 on A80 either.
<rafaelMOD>
The audio is 24, but the buffer size is 32
<rafaelMOD>
stereo
<hno>
Turl ^
<dack>
Turl: since the only issue seems to be that I can't properly detect when the cable is disconnected, I think I only need to confirm the emac_crs setting
<Turl>
rafaelMOD: given ndma's 128k size limit that'd give you like 16000 samples of a circular buffer
konradoo77 has quit [Ping timeout: 255 seconds]
<Turl>
dack: what's that?
<dack>
Turl: from the wiki "emac_crs: Carrier Status of GPIO configuration"
<Turl>
dack: ah, phy
konradoo77 has joined #linux-sunxi
<rafaelMOD>
Turl: that should be enough, as long as alsa can handle the dest pointers. I will have to check how alsa feeds from the sdram buffers
<Turl>
dack: did the hw ever work? :) you can start there
<dack>
Turl: yes! It works fine when a cable is plugged in. The problem is it never triggers anything in the kernel when the cable isn't there.
<Turl>
rafaelMOD: that'd be like 1/3rd of a second worth of audio right?
<Turl>
dack: heh
<Turl>
dack: nothing on dmesg?
<dack>
Turl: I thought I had it fixed when I added the Phy driver, but it still seems to be an issue...
<dack>
Turl: when removing/adding the cable?
<Turl>
yeah
<Turl>
sth like
<Turl>
[632088.370798] sunxi_emac sunxi_emac.0: eth0: link down
<rafaelMOD>
Turl: thats right and thats enought! As long as alsa knows how to feed from it. But anyway, when configuring snd_pcm_hardware you set this maximum on snd_pcm_hardware->buffer_bytes_max, and i think alsa does the job on the buffer
Gerwin_J has joined #linux-sunxi
<rafaelMOD>
Turl: how is ndma working on mainline, i was told that you cant have 2 simultaneous ndmas, is that right?
<dack>
Turl: so, on start up with no cable in, I get "sunxi_emac.0: eth0: link up"
<hno>
dack, then the PHY is not properly set up / configured.
<Turl>
rafaelMOD: you can, just not two circular ones currently
<Turl>
rafaelMOD: but it should be fixable, I'm going to work on that
<Turl>
dack: did the link status detection work on android or whatever?
<dack>
hno: I've "built in" the ICplus PHY into the kernel
<Turl>
the factory stuff
<dack>
Turl: yes, it works in Android
<Turl>
dack: I wouldn't be surprised if they had hardcoded something on their kernel
<hno>
dack, It's the PHY that does all link negotiation. The MAC have no impact on it.
<rafaelMOD>
Turl: so for two i2s, tx and rx, it would not work? I think that both buffers are circular in this case, am i right?
<Turl>
rafaelMOD: yes, given how it is currently implemented in the driver, one of the transfers would keep running and the other would never be programmed
<dack>
hno: Turl: dmesg says "sunxi_emac Using mii phy on PortA"... I'm guessing that means it's not using my PHY driver?
<Turl>
rafaelMOD: because it was implemented on the assumption that only one transfer could only be run at a time
<Turl>
rafaelMOD: but that turned out to not be true based on what AW told us now
<hno>
dack, what does mii-tool say about the phy?
<libv>
rmax: just ask in this channel :)
<libv>
wingrime1: what new aw repo?
<rafaelMOD>
Turl: NDMA has that 8 pos fifo. The hardware does the fifo+priority control?
<dack>
hno: I'm not familiar with mii-tool... I tried "mii-tool eth0" and got "No MII transceiver present!."
<rafaelMOD>
I recall that from a mailing thread with Jhon Smirl. But does the hardware control the ndma fifo+priority?
<rafaelMOD>
Turl: thats exactly the thread i recall.
pwhalen has quit [Ping timeout: 246 seconds]
<rafaelMOD>
Turl: i saw your codec driver for mainline, how did you solved this dma issue there? playback and capture doesnt work simultaneously?
<libv>
hno: "a bit"?
<libv>
that's quite an understatement
<Turl>
rafaelMOD: probably not, I haven't tried
<dack>
hno: I'll try making the PHY driver a module and loading it manually... see if I get any more messages
<libv>
hno: also, allwinner is very much aware of how their move is perceived
<libv>
and this issue report is bullshit
<libv>
any changes they make in future to this repository are going to change those bits which are there now already
<libv>
this tree there is not going to be what allwinner engineers base their future work on
<libv>
this is a carrot.
Faisal has quit [Read error: Connection reset by peer]
<Turl>
libv: I like how their solution is to clean stuff a la rm
<Turl>
so much for compliance
<dack>
libv: Is the repo just their kernel with the binary blobs ripped out (ie not replaced with anything useful)
<libv>
Turl: as i said yesterday, this is their way of not owning up to the fact that they are big gpl violators
<Turl>
bbiab
<dack>
^_^ I guess that's a "yes"
<libv>
if they had created a repo with any binary themselves, that would remove the last vestige of doubt
<libv>
that it is Allwinner that is the big GPL violator and not the device makers
<rafaelMOD>
Anyone tryed the A23 sunxi-3.4 from this aw repo?
<libv>
rafaelMOD: there isn't even a disp driver
<libv>
so who knows what other essential stuff has been shortsightedly culled?
<rafaelMOD>
libv: the dma seems more decent then A20's, it seems to have dmaengine
<hno>
libv, not everyone here is interested in a disp driver.
<libv>
hno: did you try running this kernel?
<libv>
hno: or do you see that as a pointless endeavour given the state of things, like i do?
<libv>
if the latter, you just argued about something you do not even believe in yourzelf
<dack>
maybe this is a dumb question, but why is there no "gmac" section in the fex?
leviathanch has joined #linux-sunxi
<libv>
dack: in the fex guide or in your fex for your a20 device?
<dack>
libv: eh.. well, do some devices have a gmac section?
<libv>
i don't know :)
<libv>
i just know that allwinner treats fex as their own little sandbox
<libv>
and that both content and usage change all the time
pwhalen has joined #linux-sunxi
<rafaelMOD>
i just created a new fex session for some parameters of mod-duo, is trivial
<libv>
perhaps a bit too trivial :)
<rafaelMOD>
totaly! just call script_parse on your module and it will read the fex
deasy has joined #linux-sunxi
<dack>
libv: merrii fex has gmac section... the fex on my device seems to be poorly modified from the "template" so I assumed if it wasn't in there it didn't exist... but maybe they were using an older template
<libv>
dack: well, we probably are not using it in our kernel
<rafaelMOD>
dack: grep the fex parameter name on your source
<libv>
but perhaps it is present in newer kernels from some SDK
<hno>
I haven't yet tried to, but I will.
<dack>
:( okay, so what do I do to get the MII transceiver working?
<hramrach_>
rafaelMOD: I tried a23 kernel from the sunxi SDK
<hramrach_>
it does not boot for me
<dack>
I tried making icplus a module. it doesn't load automatically, but I can load it manually with no messages.. it doesn't seem to make any difference.
<hramrach_>
I did not look thoroughly because there seems to be little interest in 3.4 and the more problematic part is the dram initialization
<hramrach_>
I have some magic fes1 from wens which happens to initialize my tablet allright but there is no way to obtain one for random device or for SD
<rafaelMOD>
hramrach_: so its better to stick with mainline for a23
<rafaelMOD>
hramrach_: the a23 sdram works on mainline? and the NAND boot?
melonipoika_ has quit [Remote host closed the connection]
<hramrach_>
no. the dram initialization is in boot0. You can presumably replace the kernel and u-boot in nand with your own .. until the boot0 in your nand bitrots
<hno>
if you have an firmware file for the device then both boot0 (both nand & sd) and fes binaries are in there and maybe even with usable DRAM parameters.
zeRez has quit []
rmax has left #linux-sunxi [#linux-sunxi]
<dack>
hno: Turl: Is there any way to get more logging messages to figure out why the PHY/MII isn't working properly?
<Turl>
dack: no idea, see if you can enable debug on the emac driver
<dack>
Turl: I don't think that'll help... the emac driver is blissfully unaware when the cable is not there.. it seems to think it's always connected, so it'll likely not report an error.
<dack>
everything works when the cable is present, too.
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
konradoo77 has quit [Ping timeout: 240 seconds]
<Turl>
dack: isn't that what you're trying to debug? :)
<Turl>
you said it worked on android, was it using emac or gmac?
<dack>
Turl: I'm trying to debug why it doesn't detect the cable not being there. I suspect it won't have any error like "error: I didn't see that thing that I couldn't see"
<Turl>
dack: heh
<dack>
Turl: I'm not sure how to test, but I think the PHY only supports emac
<dack>
Turl: also, emac works fine when it's connected. everything I've read points to an issue with the PHY not the MAC
<Turl>
dack: you could print when it reads the hw status on boot, see why it thinks the cable is plugged in
<Turl>
dack: to test gmac.. not sure what the status of 100M phy support on 3.4 is, wens?
<Turl>
dack: on the best case scenario you'd need to add the fex section and load the driver
<dack>
Turl: well, I've tried using sunxi_gmac and it doesn't seem to load. I don't have any gmac settings in the fex so I think Android is using emac
<dack>
;)
konradoo77 has joined #linux-sunxi
<dack>
hno: libv: the issue I'm having is purely with the PHY, right? the MAC should be fine, no?
deasy has joined #linux-sunxi
deasy has quit [Remote host closed the connection]
jinzo has joined #linux-sunxi
deasy has joined #linux-sunxi
<dack>
Is the MII stuff handled by the AW SoC or do I need a separate driver for that?
deasy has quit [Remote host closed the connection]
deasy has joined #linux-sunxi
<dack>
... I found some bug fixes in the mainline kernel for the icplus driver, trying those out now.
mmarker has quit [Read error: Connection reset by peer]
mmarker has joined #linux-sunxi
diego_r has joined #linux-sunxi
<hno>
dack, it a bit blurred bug responsibilities.. MAC driver talks to PHY driver and registers the PHY. But generally yes, if Ethernet works with cable plugged at boot then MAC is likely OK and only PHY is the issue.
deasy has quit [Remote host closed the connection]
<hno>
The MAC driver also provides the MII interface for talking to the PHY.
<dack>
I want to back-port patches from the kernel mainline into the 3.4 one... is there a "proper" way of doing that to retain the commit logs?
deasy has joined #linux-sunxi
<hno>
git cherry-pick if you have clean patches.
<hno>
if there is other stuff in the same changes then more hadwawing is needed.
<dack>
hno: I think it's clean... all one .c file
Wes- has quit [Ping timeout: 258 seconds]
imcsk8 has quit [Quit: Reconnecting]
imcsk8 has joined #linux-sunxi
Wes- has joined #linux-sunxi
<dack>
what's the proper way to request backported cherry-pick'ns into the sunxi-3.4 branch? Should I just post something to the mailing list with the hashes for the commits I want added?
<hno>
normal mailing of patches is fine. Even github pull requests works.
<hno>
dack, did the patch solve your problem?
<dack>
hno: still compiling... :)
mturquette has quit [Quit: 2 legit 2 /quit]
<dack>
I've found that github PR's are largely ignored... I had one simple one in there and I was asked to send the patch to the mailing list.
jinzo has quit [Quit: Leaving]
<dack>
OT... Anyone know what the scam is here: http://www.ebay.ca/itm/171511295007 ? It's the third listing like it I've seen and each one is shut down. It's a $200 unit for $25.
<dack>
payments are made through paypal, so the buyer protection means you always get your money back... how can the scammer get anything here?
diego_r has quit [Ping timeout: 255 seconds]
<hno>
dack, is it a scam or simply wrong price? Looks like an established seller.
<dack>
hno: scam. I've ordered 2 already from other established sellers and their accounts suddenly dissappeared and the listing removed. I just got a refund for the one a few minutes ago.
<dack>
hno: I'm wondering if they're hacked accounts... I don't know. Seems really weird.
ricardocrudo has quit [Remote host closed the connection]
<hno>
wingrime1, yes, I view them as such. It's running on a separate CPU, in separate memory, with partially separate I/O controllers. Not really much different from the firmware you download on a GPU or the like.
<wingrime1>
It's blob still, you can consider tablet software as firmware too...
<wingrime1>
hno: it have separated memory?
<hno>
From a GPL perspective all that is needed is to move them out of the kernel.
<hno>
Yes, it has a dedicated and quite large SRAM area.
<wingrime1>
Can it use ddr memory?
<hno>
probably.
<hno>
(so can the GPU btw)
<wingrime1>
Cortex m3 as i know is pretty powerfull...
<hno>
it is.
<wingrime1>
But it can be in different variants
<hno>
apparently it's used as a audio codec among one of it's functions.
<wingrime1>
Mmu unit, float point
FunkyPenguin has quit [Ping timeout: 250 seconds]
<wingrime1>
If it can float point oprrations it defenetly can decode any audio codec
<hno>
I don't think it has an MMU. Not sure about floating point.
FunkyPenguin has joined #linux-sunxi
<wingrime1>
And I don' t know why they not load firmware by bootloader
<wingrime1>
As it usualy does
<wingrime1>
If it have mmu, it can run linux easyly
<hno>
there is a very large arisc blob for bootloader use. Not sure what it contains.
<wingrime1>
Hno better have source off it
<wingrime1>
*of it
petr has quit [Ping timeout: 244 seconds]
<hno>
have also not seen any bootloader use of it, so somewhat confused on it's purpose.
<wingrime1>
It probably should stay awaked in standby
rafaelMOD has joined #linux-sunxi
<hno>
the kernel do not reference that blob at all.
petr has joined #linux-sunxi
<hno>
and I haven't seen any reference to it in the u-boot sources. And not likely to be referenced by boot0.
<wingrime1>
Hm
<hno>
But it is packaged into firmware files as "arisc.fex" / "1234567890ARISC"
FunkyPenguin has quit [Ping timeout: 272 seconds]
FunkyPenguin has joined #linux-sunxi
bertrik has quit [Remote host closed the connection]
xavia has quit [Remote host closed the connection]
<afaerber>
wingrime1, Cortex-M3 does not have an MMU, it's ARMv7-M; floating point support usually means Cortex-M4F