--- Log opened Fri Apr 08 00:00:11 2016 | ||
shorne | Hello, anyone ever written any part of an ac97 codec? (not controller like in opencores) | 05:27 |
---|---|---|
wallento | shorne: you are going the full path? :-) | 06:34 |
shorne | wallento: front to back, dac/adc(chips) - ac97 codec(verilog) - ac97 controller(opencores) - linux(dma api) | 08:20 |
wallento | nice! | 08:21 |
shorne | I have the dac/adc chips and have written some verilog for them to read/write via their spi interface | 08:21 |
shorne | now I need a ac97 link to spi codec layer | 08:22 |
shorne | I guess I need to write myself, did some quick searching, it seems most people buy $3 ac97 codec chips... | 08:22 |
shorne | I rather just do from scratch | 08:22 |
wallento | stupid people ;) | 08:26 |
stekern | why do you need to add ac97 into the path though? | 08:35 |
wallento | no, I am just curious | 08:42 |
olofk | https://github.com/cambridgehackers/binutils-gdb/commit/d8e766a0717c2895e3dd346d137bacfa72e971ab | 09:16 |
olofk | Nice | 09:16 |
shorne | wallento: ac97 just because there is already good driver support for that. | 10:16 |
shorne | and I dont think there is intel HDA controller core avaiable | 10:17 |
shorne | stekern: meant to write to you that comment, I want to test the dma code in the kernel | 10:38 |
shorne | the ac97 controller in opencores and I think existing drivers support dma pretty well | 10:38 |
shorne | so it would be a good test for the kernel | 10:38 |
stekern | shorne: there is no dma support for the opencores ac97 kernel driver | 15:08 |
stekern | we have tested using https://github.com/olofk/wb_streamer together with a plain i2s chip though | 15:11 |
stekern | and there's a driver for that in the kernel tree | 15:11 |
stekern | olofk: oh ;) | 15:27 |
olofk | wallento: I think it's good that you point the build instructions on the opencores wiki to openrisc.io, but it's damn hard to find the actual instructions now | 16:39 |
olofk | Took me about five minutes of following circular links before I found the way to http://openrisc.io/newlib/building.html | 16:39 |
shorne | stekern: alright, i did see an ac97_dma_if.v file there. Ill see if I can get it working. | 16:56 |
stekern | yeah, it is supposed to be used together baroque dma core that I wouldn't recommend wasting time on | 16:58 |
stekern | I did look into it at some point | 16:58 |
stekern | *together with some | 17:00 |
shorne | I see, does the wb_streamer work with another dma controller? or its doing it itself? | 17:02 |
olofk | shorne: wb_streamer is a half DMA :) | 17:02 |
shorne | Right | 17:03 |
olofk | There are two versions, each with a stream port and a wishbone port | 17:03 |
olofk | So you either read from a stream and write to memory, or vice versa | 17:03 |
olofk | The idea was that it should be possible to connect the stream ports as well to have a memory<->memory DMA | 17:04 |
olofk | But for most peripheral cores you need stream<->memory | 17:04 |
olofk | But stekern knows more about the Linux side of things. I only did the RTL | 17:04 |
shorne | yeah, which is pretty much true for sound too | 17:05 |
olofk | It should be dead simple to use. Just set up a base address, a length and start it. You'll get an interrupt (or can poll a register) to check when it's done | 17:06 |
shorne | Is 'stream' a special protocol? or it just read/write the bus per clock cycle? | 17:07 |
olofk | shorne: It's pretty much AXI stream | 17:07 |
olofk | Master outputs valid whenever it has something. slave outputs ready when it's ready to receive. When both valid and ready are asserted, the word is transferred | 17:08 |
olofk | hmm.. the extended verilog output that I asked for in binutils objcopy works, but I get reversed endianness for OpenRISC elfs | 17:09 |
olofk | It's trivial to swap this back in RTL of course, but it would be nice to have it correct from the beginning | 17:10 |
shorne | yeah, that would confuse people who dont know the background | 17:12 |
olofk | The source code is pretty simple, but I still can't figure out how to do this correctly | 17:14 |
olofk | Ahh now I see | 17:14 |
olofk | Just need to figure out how to get the endianness from the arch | 17:15 |
shorne | I see something called "sys-sr-lee" little endian enabled in opcodes/or1k-desc.c | 17:18 |
olofk | There's a struct called 'bfd' that is passed in to the function, but I can't find the definition of it | 17:19 |
shorne | those looks like registers though... | 17:19 |
shorne | not one of these? bfd/cpu-or1k.c | 17:21 |
shorne | that doesnt have endianness | 17:23 |
shorne | const bfd_arch_info_type * bfd_get_arch_info(bfd *abfd) | 17:24 |
olofk | shorne: If you look at verilog_write_record in bfd/verilog.c, it gets passed a pointer (struct?) called bfd. I suspect that this contains the info I need | 17:25 |
shorne | yeah, I am gussing its in bfd_arch_info_type | 17:28 |
shorne | defined in bfd/cpu-or1k.c | 17:28 |
shorne | which you can get by bassing the bfd *abfd to bfd_get_arch_info(bfd *abfd) | 17:29 |
shorne | not 100% sure endian is in bfd_arch_info_type though | 17:29 |
shorne | sorry... need to go | 17:29 |
olofk | aahh!! This is driving me crazy. Where is the damn struct defined? | 17:36 |
olofk | (Assuming it's a struct) | 17:36 |
--- Log closed Sat Apr 09 00:00:13 2016 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!