| *** tpb has joined #timvideos | 00:00 | |
| CarlFK | mithro did the atlys stuff in the last few weeks. about the time I put it in my ppa. a week or so later his work got accepted upstream | 00:31 |
|---|---|---|
| mithro | tumbleweed: I assume you are probably asleep now? | 03:34 |
| mithro | tumbleweed: For openocd, you should just package the latest upstream git version | 03:34 |
| mithro | Bertl_zZ: ping? | 06:13 |
| mithro | seaLne: ping? | 06:13 |
| mithro | xfxf: ping? | 06:13 |
| mithro | G33KatWork: ping? | 06:13 |
| xfxf | pong, am out atm tho | 06:23 |
| mithro | xfxf: you going to be around later tonight at all? | 07:03 |
| xfxf | should be but it'll be much later - 150km out from home atm | 07:22 |
| mithro | okay | 07:38 |
| mithro | I'll probably be around till midnight | 07:38 |
| *** rohitksingh has joined #timvideos | 08:10 | |
| *** tvCommitBot has joined #timvideos | 09:32 | |
| tvCommitBot | [dvsource-v4l2-other] stefanor created rationalize-imports (+1 new commit): http://git.io/v8nNG | 09:32 |
| tvCommitBot | dvsource-v4l2-other/rationalize-imports 0ed02c1 Stefano Rivera: Clean up imports... | 09:32 |
| *** tvCommitBot has left #timvideos | 09:32 | |
| *** tvCommitBot has joined #timvideos | 09:32 | |
| tvCommitBot | [dvsource-v4l2-other] stefanor opened pull request #14: Clean up imports (master...rationalize-imports) http://git.io/v8nNn | 09:32 |
| *** tvCommitBot has left #timvideos | 09:32 | |
| *** tvCommitBot has joined #timvideos | 09:37 | |
| tvCommitBot | [dvsource-v4l2-other] stefanor created 43-pal (+1 new commit): http://git.io/v8nA8 | 09:37 |
| tvCommitBot | dvsource-v4l2-other/43-pal 510ce94 Stefano Rivera: In 4:3 PAL, Y41B confuses ffmpeg2theora, and dvswitch PinP | 09:37 |
| *** tvCommitBot has left #timvideos | 09:37 | |
| *** tvCommitBot has joined #timvideos | 09:38 | |
| tvCommitBot | [dvsource-v4l2-other] stefanor opened pull request #15: In 4:3 PAL, Y41B confuses ffmpeg2theora, and dvswitch PinP (master...43-pal) http://git.io/v8nAR | 09:38 |
| *** tvCommitBot has left #timvideos | 09:38 | |
| * tumbleweed must still test those - we are currently using something hackier | 09:39 | |
| *** travis-ci has joined #timvideos | 09:39 | |
| travis-ci | [mithro/HDMI2USB-misoc-firmware/master#48] (4f2aac2): The build passed. (https://travis-ci.org/mithro/HDMI2USB-misoc-firmware/builds/89792313) | 09:39 |
| *** travis-ci has left #timvideos | 09:39 | |
| *** Bertl_zZ is now known as Bertl | 09:41 | |
| Bertl | mithro: pong | 09:41 |
| mithro | Bertl: couple of questions - do you have a shopping list for Digikey for the Dual PMOD, HDMI and PMOD boards? | 09:42 |
| Bertl | nope, not yet | 09:42 |
| mithro | Bertl: what about element14? | 09:43 |
| Bertl | partially, the HDMI plugin should have a BOM | 09:43 |
| Bertl | https://wiki.apertus.org/index.php/Axiom_Beta_Plugin_Module_1x_HDMI_v0.5 | 09:44 |
| tpb | Title: Axiom Beta Plugin Module 1x HDMI v0.5 - apertus° wiki (at wiki.apertus.org) | 09:44 |
| Bertl | check the google doc, I even see some digikey entries | 09:44 |
| Bertl | but the BOM is not checked/corrected yet | 09:45 |
| Bertl | it still contains a lot of bugs/missing fields | 09:45 |
| Bertl | if you do a BOM with digikey parts, please drop us an email with the partlist, we will add them to our BOMs | 09:50 |
| *** se6astian|away is now known as se6astian | 10:00 | |
| ysionneau | mithro ping? | 10:31 |
| mithro | ysionneau: pong | 10:31 |
| mithro | Bertl: okay | 10:32 |
| ysionneau | mithro: I don't know if you read my last email, but I have better news now. | 10:32 |
| mithro | Bertl: I also wanted to ask what your thoughts was on the TOFE->axiom link | 10:32 |
| mithro | Bertl: did you see the stuff I pushed? | 10:32 |
| mithro | Bertl: and the comment that I couldn't count | 10:32 |
| ysionneau | I implemented the i2c slave in hw, and it seems to work pretty well, at least with the arduino master | 10:32 |
| mithro | ysionneau: yes, I've been meaning to reply | 10:33 |
| ysionneau | I didn't push it yet, but I will push it today | 10:33 |
| ysionneau | I bet you have tons of stuff to handle because of the production run? | 10:33 |
| *** tvCommitBot has joined #timvideos | 10:35 | |
| tvCommitBot | [dvsource-v4l2-other] mithro pushed 1 new commit to master: http://git.io/v8cUF | 10:35 |
| tvCommitBot | dvsource-v4l2-other/master 2dd7a73 Tim Ansell: Merge pull request #14 from timvideos/rationalize-imports... | 10:35 |
| *** tvCommitBot has left #timvideos | 10:35 | |
| mithro | ysionneau: More trying to get this USB stuff reliable + understandable at the moment | 10:35 |
| ysionneau | so far I have a working prototype of the arduino fetching the content of some SRAM in the FPGA via I2C, the SRAM being addressable on wishbone bus | 10:38 |
| ysionneau | I could write to the SRAM memory from the BIOS (using mw command) and see the Arduino output change live | 10:38 |
| ysionneau | so we'll only need to do a memcpy() at boot to fill the SRAM with the fw | 10:39 |
| ysionneau | only thing to sort out is ... will the firmware fit in there. | 10:39 |
| ysionneau | if you have some fw somewhere I could need an ls -l on it :) | 10:39 |
| mithro | ysionneau: at the moment the SPI flash has no structure on it | 10:40 |
| ysionneau | what do you mean? | 10:41 |
| ysionneau | fpga bitstream starts at 0x0, then after the fpga bitstream you put the lm32 fw, then you put some room for improvement and put the fx2 fw ? | 10:42 |
| mithro | ysionneau: that is the idea, but we haven't done anything like that yet | 10:42 |
| ysionneau | ok | 10:43 |
| ysionneau | I don't think that would be hard to do :o | 10:43 |
| *** rohitksingh has quit IRC | 10:43 | |
| mithro | Note: Although FX2LP can perform C2 load from EEPROMs as large as 64 KB, code can be downloaded only to onchip RAM (16 KB) by the hardware bootloader. | 10:44 |
| ysionneau | ok so 16 KB is the max code size | 10:45 |
| ysionneau | thx | 10:45 |
| ysionneau | on my test I only use 128 Bytes ram :p | 10:45 |
| ysionneau | I guess you can't do much with 128B of code :' | 10:45 |
| mithro | ysionneau: http://www.cypress.com/file/138911/download | 10:47 |
| ysionneau | thx | 10:48 |
| mithro | ysionneau: see the I2C section | 10:48 |
| mithro | I'm assuing that is 16kilobytes ? | 10:49 |
| ysionneau | 2.18.2 says 16 KB of RAM | 10:50 |
| mithro | I wish everyone was forced to write kilobit or kilobyte | 10:50 |
| ysionneau | oh | 10:51 |
| ysionneau | capital B is supposed to always be byte | 10:51 |
| ysionneau | for me it's not ambiguous, it's 16 kBytes | 10:51 |
| mithro | ysionneau: yes but people arn't perfect :) | 10:51 |
| mithro | ysionneau: and get it wrong all the time | 10:51 |
| ysionneau | Table 7 2.18.1 , max eeprom size here is 16 k bytes (and this time they wrote Bytes entirely) | 10:52 |
| ysionneau | anyway, eeprom accesses are by bytes , not by bit | 10:52 |
| ysionneau | that would not make that much sense I think to speak in bits | 10:52 |
| ysionneau | I think :o | 10:52 |
| ysionneau | so we can pretty safely assume it's 16 k Bytes | 10:52 |
| mithro | yeah | 10:54 |
| ysionneau | mithro: if I send you an fpga bitstream which should upload the fw to the fx2, you could test it on your board? | 10:55 |
| mithro | ysionneau: yes | 10:56 |
| ysionneau | cool | 10:56 |
| mithro | ysionneau: if you want a fx2 firmware to test with, use what is in the HDMI2USB-mode-switch repo | 10:57 |
| mithro | ysionneau: https://github.com/timvideos/HDMI2USB-mode-switch/tree/master/fx2-firmware/opsis | 10:57 |
| tpb | Title: HDMI2USB-mode-switch/fx2-firmware/opsis at master · timvideos/HDMI2USB-mode-switch · GitHub (at github.com) | 10:57 |
| ysionneau | yep got it | 10:58 |
| ysionneau | allright | 10:58 |
| ysionneau | I would probably have to transform it to .bin format then | 10:59 |
| Bertl | mithro: no, didn't see what you pushed | 10:59 |
| *** rohitksingh has joined #timvideos | 10:59 | |
| Bertl | mithro: what's the comment issue? | 10:59 |
| mithro | Bertl: well, it turns out that I didn't push things in the end :P | 11:00 |
| mithro | Bertl: https://github.com/timvideos/HDMI2USB-TOFE-HiLink | 11:00 |
| tpb | Title: timvideos/HDMI2USB-TOFE-HiLink · GitHub (at github.com) | 11:00 |
| Bertl | seems pretty empty :) | 11:00 |
| mithro | Bertl: I ran into the problem that I totally missed a LVDS pair | 11:00 |
| mithro | Bertl: so it doesn't fit nicely like I thought | 11:01 |
| Bertl | okay? | 11:01 |
| mithro | Bertl: so, wanted to understand what the best mapping you thought of | 11:01 |
| mithro | Bertl: https://usercontent.irccloud-cdn.com/file/ALJavW7R/tofe-hilink | 11:05 |
| mithro | Bertl: https://usercontent.irccloud-cdn.com/file/XtGn92Lz/tofe-hilink-axiom-side | 11:06 |
| mithro | Bertl: I also pushed a bunch of stuff to the repository | 11:06 |
| mithro | Need to concentrate on this USB stuff, but also conscious that PCB take time to manufacture :) | 11:07 |
| Bertl | hmm ... I think it would be way better to make that a dual slot plugin | 11:08 |
| Bertl | the problem is, we have 6 LVDS pairs per slot | 11:08 |
| Bertl | that gives a nice 3x4 pairs on the dual slot, for 3 DP links | 11:08 |
| mithro | Bertl: yeah - well, started with one slot + mDP pair | 11:08 |
| Bertl | (which also fits better space wise) | 11:09 |
| mithro | then just replicate it for the south slot | 11:09 |
| Bertl | we can still use medium/low speed I/Os for filling up the config/aux | 11:09 |
| *** rohitksingh has quit IRC | 11:12 | |
| Bertl | but we shouldn't use any of the low speed I/Os for the DP pairs | 11:15 |
| tumbleweed | mithro: bah. One of my patches didn't work. Need to figure out which | 11:16 |
| Bertl | as they won't be able to handle anything beyond 300MHz | 11:16 |
| Bertl | off for now ... bbl | 11:17 |
| *** Bertl is now known as Bertl_oO | 11:17 | |
| Bertl_oO | mithro: anyway, don't worry too much, I'll do the axiom side in the near future | 11:21 |
| xfxf | mithro: i'm sort of around now | 11:42 |
| *** ivodd has joined #timvideos | 11:47 | |
| ysionneau | mithro: code pushed https://github.com/fallen/i2cslave/commit/438053fafd3b1eecf85338ebcc063ac7b8d71f44 | 11:50 |
| tpb | Title: handle i2c slave in gateware · fallen/i2cslave@438053f · GitHub (at github.com) | 11:50 |
| ysionneau | I heavily copy pasted from the edid hdmi in code | 11:52 |
| seaLne | mithro: pong | 11:54 |
| mithro | seaLne: just wondering how things are going | 11:54 |
| mithro | ysionneau: This isn't how I would do this in hardware as it only enables implementing an RAM device? | 11:56 |
| ysionneau | sorry I don't understand | 11:56 |
| ysionneau | what do you mean? | 11:56 |
| mithro | ysionneau: this is a hardware implementation on an EEPROM - I would have done this as creating an i2c UART and then still doing the majority of the work, except the shifting, in software | 11:57 |
| ysionneau | ah I see | 11:58 |
| ysionneau | software driven but hw assisted | 11:58 |
| mithro | ysionneau: yes, that is what I meant from the "start with software then add hardware as needed" | 11:58 |
| ysionneau | ok | 11:58 |
| ysionneau | do you see any issue with doing it the way I did? | 11:59 |
| ysionneau | you can still interface software in front of that, and do uart or ethernet upload of fx2 fw | 11:59 |
| ysionneau | as long as the code ends up writing the fx in the on-chip SRAM | 11:59 |
| ysionneau | -fx+fw | 11:59 |
| ysionneau | it's like a "uart" i2c except the FIFO length is not just 1 byte but has the length of the entire firmware basically | 12:01 |
| mithro | ysionneau: you have a full address / I2C command decode happening in hardware? | 12:02 |
| ysionneau | I tested two ways of reading the eeprom so far | 12:02 |
| seaLne | mithro: life has been getting a bit in the way. with the opsis i still don't get any video. the view script gives up after a while. last tried 3 days ago just noticed there have been some changes by _florent_ so will try again building just now | 12:02 |
| ysionneau | 1°) the arduino only issues reads to the 0x50 slave, no address is asked. So address starts at 0 and auto increments | 12:03 |
| ysionneau | 2°) the arduino issues the address it wants to read | 12:03 |
| ysionneau | both work | 12:03 |
| ysionneau | so yes there is either address "decoding" (latching) or auto increment | 12:03 |
| mithro | ysionneau: yes - all happening in your hardware block, right | 12:04 |
| mithro | ? | 12:04 |
| ysionneau | all happening in the FSM in the gateware yes | 12:04 |
| ysionneau | same as the EDID read in fact | 12:04 |
| ysionneau | except this time you can control the RAM content, since it's attached to the wishbone bus | 12:06 |
| ysionneau | you can upload content in it via whatever protocole you need | 12:07 |
| mithro | ysionneau: for example, you could send a "write" command via I2C which would currently fail because the hardware doesn't understand it, | 12:11 |
| ysionneau | yes, the "byte write" would not work, but the fx2 would not send such a command, would it? | 12:16 |
| mithro | ysionneau: sure - but what I was getting at is that this works for the very specific case, but is very inflexible / hard to extend | 12:18 |
| *** rohitksingh has joined #timvideos | 12:19 | |
| ysionneau | I agree it's less flexible | 12:20 |
| ysionneau | but I don't see what kind of extension you would want to add | 12:20 |
| ysionneau | if this is really an "eeprom emulation" feature | 12:21 |
| mithro | ysionneau: https://plus.google.com/+StephenWarren/posts/7SH3Dn4y4go | 12:22 |
| ysionneau | what he is talking about is supported by my code | 12:23 |
| ysionneau | i2c write != byte write | 12:23 |
| ysionneau | indeed, in order to select the address of the eeprom you want to read, you need to issue an i2c write | 12:23 |
| ysionneau | this write latches the address in the eeprom | 12:23 |
| ysionneau | and this is supported by the i2cslave FSM I pushed on github | 12:23 |
| ysionneau | that's the 2 scenarios I talked about | 12:24 |
| ysionneau | either 1°) the master only issues reads | 12:24 |
| ysionneau | or 2°) the master issues writes to latch the address and then reads | 12:24 |
| seaLne | hmm after updating third_party i don't have a misoc/make.py | 12:25 |
| mithro | seaLne: hrm? | 12:26 |
| ysionneau | third_party is following the misoc upstream? | 12:26 |
| mithro | ysionneau: does your eeprom support double byte and single byte reads? | 12:26 |
| seaLne | i ran update.sh and then tried make clean and which tries to run misoc/make.py which doesn't exist anymore? | 12:26 |
| mithro | seaLne: update.sh? | 12:27 |
| ysionneau | https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/third_party/update.sh | 12:27 |
| mithro | seaLne: why did you run update.sh? | 12:27 |
| tpb | Title: HDMI2USB-misoc-firmware/update.sh at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 12:27 |
| mithro | seaLne: update.sh is to update the submodules to newer upstream | 12:27 |
| seaLne | should i not have been? | 12:27 |
| ysionneau | fyi, upstream misoc/migen changed a LOT those last days | 12:27 |
| ysionneau | so your current code won't work with current upstream misoc/migen | 12:28 |
| mithro | seaLne: not unless you intended on sending a pull request with new submodule references | 12:28 |
| seaLne | oh | 12:28 |
| ysionneau | for instance make.py does not exist anymore upstream indeed | 12:28 |
| ysionneau | now the way to build is to *run* the target file, which is now executable | 12:28 |
| * seaLne deletes and starts again | 12:29 | |
| mithro | ysionneau: so, the idea was to try and keep as much in software as possible because, more people understand C code, it's much quicker to fix / modify / extend | 12:31 |
| ysionneau | mithro: it supports random reads and sequential reads | 12:32 |
| ysionneau | I don't see "double byte" reads in the eeprom datasheet I'm looking at right now | 12:32 |
| mithro | ysionneau: sorry, I mean double width addresses for the reads - IE more then 256 bytes | 12:33 |
| ysionneau | ah ok | 12:33 |
| ysionneau | no it supports only 1 byte width addresses | 12:34 |
| ysionneau | like a small eeprom would | 12:34 |
| mithro | ysionneau: that is needed for 16kilobyte EEPROM support | 12:34 |
| ysionneau | ah right | 12:34 |
| ysionneau | I need to change that, good point | 12:34 |
| ysionneau | ok let me think about some more software based implem then | 12:35 |
| mithro | ysionneau: I think we want hardware which looks like this -> https://usercontent.irccloud-cdn.com/file/Uyi3ddyn/PIC%20I2C%20module | 12:35 |
| mithro | ysionneau: basically a shift register and start/stop bit stuff? | 12:36 |
| ysionneau | yes that's what I was thinking about | 12:37 |
| ysionneau | a read and a write register | 12:37 |
| ysionneau | you would prefill the read register with the data you want the master to get on the next "master read" | 12:37 |
| ysionneau | and when the master issues a write, it fills your "write" register and you get an irq | 12:38 |
| ysionneau | you would also get an irq upon read register being empty | 12:38 |
| ysionneau | so that sw can refill it | 12:38 |
| ysionneau | I hope the sw can go fast enough ... but maybe with some "PAUSE" trick it can work (pause being slave keeping SDA low at the end of the transfer, blocking everything) | 12:39 |
| mithro | ysionneau: https://cdn.sparkfun.com/assets/5/f/5/a/1/51adff65ce395ff71a000000.png | 12:43 |
| ysionneau | well, yes ok | 12:43 |
| ysionneau | I think you need 2 registers in fact for this to work well | 12:44 |
| ysionneau | because you don't know if the next transaction will be a read or a write | 12:44 |
| ysionneau | so you need to be ready for a read anytime, so you need to have some data in a read register | 12:44 |
| ysionneau | well, with the PAUSE trick that could work with just 1 register in fact | 12:45 |
| mithro | ysionneau: doesn't the read/write just determine who is writing onto SDA? | 12:46 |
| ysionneau | yes | 12:46 |
| ysionneau | read means the slave owns SDA, write means master owns SDA | 12:46 |
| mithro | ysionneau: looking at http://www.atmel.com/Images/doc2583.pdf for example SMBUS (I2C derivative) commands | 12:47 |
| ysionneau | yes that's the kind of drawings I had in mind | 12:49 |
| mithro | ysionneau: the problem you where having with your bitbanging was the "acknowledge" ? | 12:49 |
| ysionneau | yes | 12:49 |
| ysionneau | the ACK seemed to be late | 12:50 |
| ysionneau | so it resulted in a NACK :/ | 12:50 |
| mithro | ysionneau: you had a picture of that, right? | 12:50 |
| ysionneau | yes it's linked in my email | 12:50 |
| ysionneau | you want the link? | 12:50 |
| mithro | ysionneau: this one -> https://framapic.org/TPcDnWIl2uuE/Jt3IOGOj | 12:50 |
| ysionneau | yes | 12:51 |
| ysionneau | that's an i2c write, to slave 8 | 12:52 |
| mithro | ysionneau: this the C code? | 12:52 |
| mithro | ysionneau: https://github.com/fallen/i2cslave/blob/master/i2cslave/software/i2c.c | 12:52 |
| tpb | Title: i2cslave/i2c.c at master · fallen/i2cslave · GitHub (at github.com) | 12:52 |
| ysionneau | yes | 12:52 |
| ysionneau | i2c_slave_read_byte() is able to read correctly the 0x8 | 12:53 |
| ysionneau | but it does not seem to send the ACK on time, weirdly | 12:53 |
| ysionneau | as you can see I also tried optimizing the assembly code, with the same result :/ | 12:57 |
| mithro | ysionneau: looking at https://cdn.sparkfun.com/assets/6/4/7/1/e/51ae0000ce395f645d000000.png | 12:57 |
| ysionneau | yep ? | 12:58 |
| *** se6astian is now known as se6astian|away | 12:59 | |
| mithro | ysionneau: you want to read / write the bits when scl is high, right? | 12:59 |
| ysionneau | yes | 12:59 |
| ysionneau | well | 12:59 |
| ysionneau | in want to read when scl is high | 12:59 |
| ysionneau | but I want to setup the bit when scl is low, but so far anyway I only read | 12:59 |
| mithro | ysionneau: have you tried just replicating the SCL signal on a separate pin? | 13:03 |
| mithro | ysionneau: IE every time i2c_r_read() changes, write the value to an IO pin | 13:03 |
| *** se6astian|away is now known as se6astian | 13:03 | |
| mithro | ysionneau: see what your scope shows | 13:03 |
| ysionneau | hmmmm not sure I see where you want to go but I can do that | 13:04 |
| ysionneau | so in my while loops I would just write some register mapped to an IO pin with the SCL pin value? | 13:05 |
| ysionneau | replicate SCL on a separate pin via software | 13:05 |
| mithro | ysionneau: that should let you see what type of delay there is going via software, right? | 13:06 |
| ysionneau | ah ok | 13:07 |
| mithro | ysionneau: I'd also write a some c code which just toggles a pin on/off as fast as it can | 13:07 |
| ysionneau | so I can basically do while(1) { write_to_pin(read_scl()); } | 13:07 |
| ysionneau | and check the width of the IO spikes | 13:08 |
| seaLne | when i've been looking at the specs for video cameras none seem to mention outputing 720p. is it not very common? | 13:08 |
| ysionneau | if it's short it means I don't have much time budget | 13:08 |
| mithro | ysionneau: you should get a SCL which lags behind the real SCL by some amount? | 13:10 |
| ysionneau | yes | 13:10 |
| ysionneau | but possibly with a different width | 13:11 |
| ysionneau | I mean a different frequency | 13:11 |
| ysionneau | depends on the number of samples I can get while SCL is, say, high. and on the time it takes to output those samples to the replicating pin | 13:12 |
| ysionneau | but yes, the latency can give me a hint of the speed of a read/write | 13:13 |
| ysionneau | what's bothering me is that, in the current code, I output the ACK right after sampling the last bit, so while SCL is still high in theory. I don't wait for it to go low | 13:13 |
| ysionneau | so I should have plenty of time... | 13:13 |
| mithro | ysionneau: actually, maybe just ask on #m-labs about manipulating GPIO pins from the lm32 core? | 13:14 |
| ysionneau | I should have some remaining time where SCL is high + the time where scl is low | 13:14 |
| ysionneau | what do you want to ask? I know how to manipulate a GPIO from the lm32 core | 13:15 |
| ysionneau | I can just do a CSRStorage bit tied to an IO | 13:15 |
| mithro | ysionneau: delays in reading/writing to the GPIO pins? | 13:15 |
| ysionneau | I don't think anyone will know that :/ | 13:15 |
| ysionneau | depends on so much things | 13:15 |
| mithro | ysionneau: I | 13:16 |
| ysionneau | if you do XIP or execute from SDRAM, depends on cache size, cache or not, sys clock frequency | 13:16 |
| ysionneau | etc | 13:16 |
| mithro | ysionneau: There should be a constant delay from "write to CSR x" and having the change appear GPIO pin? | 13:17 |
| ysionneau | oh that, yes | 13:17 |
| ysionneau | that's the deterministic part | 13:17 |
| ysionneau | I would say 1 or 2 clock cycles | 13:17 |
| ysionneau | not more | 13:17 |
| ysionneau | I can easily look that up in the code | 13:18 |
| ysionneau | in fact it depends on what you call "write to CSR", if you directly tie the CSR to the IO, then it's less than a clock cycle upon the CSR is actually written to | 13:19 |
| ysionneau | if you want the time between the wishbone write and the IO change then I guess there is one buffer in the way between the wishbone bus and wishbone_to_csr bridge | 13:20 |
| ysionneau | so that would add 1 clock cycle | 13:20 |
| mithro | ysionneau: and reads in the other direction? | 13:20 |
| ysionneau | I would say it's the same | 13:21 |
| mithro | ysionneau: so, something which reads the GPIO value and then writes a GPIO in a tight loop should have that speed, no? | 13:22 |
| ysionneau | well, you need to account for branch misprediction, cache misses, wishbone bus occupation etc | 13:23 |
| ysionneau | but it should be related yes | 13:23 |
| mithro | ysionneau: in a tight loop everything is going to be in cache and shouldn't be any branch misprediction or anything? | 13:23 |
| ysionneau | yes for cache | 13:24 |
| ysionneau | let me check for branch prediction | 13:24 |
| ysionneau | ok, backward pointing branches are predicted taken | 13:29 |
| ysionneau | so that should be OK | 13:29 |
| ysionneau | anyway I can do the test of a tight write loop, and another test of a tight read/write loop | 13:29 |
| *** tvCommitBot has joined #timvideos | 13:37 | |
| tvCommitBot | [dvsource-v4l2-other] stefanor force-pushed 43-pal from 510ce94 to a1a4acf: http://git.io/v8c1P | 13:37 |
| tvCommitBot | dvsource-v4l2-other/43-pal a1a4acf Stefano Rivera: In 4:3 PAL, Y41B confuses ffmpeg2theora, and dvswitch PinP | 13:37 |
| *** tvCommitBot has left #timvideos | 13:37 | |
| ysionneau | so, to sum up, next in my todo list : investigate the sw gpio toggling frequency, then replicate scl to see by how much I lag behind, and then we can make the decision to either spend time debugging this or go the sw controlled more hw assisted way (with shift registers) | 13:41 |
| mithro | ysionneau: I think we do want to go the hw assisted way with shift registers, but it would be good to figure out *why* your bit banging doesn't work | 13:42 |
| ysionneau | ok | 13:43 |
| ysionneau | fair enough | 13:43 |
| ysionneau | AFK fetching some food | 13:51 |
| *** tvCommitBot has joined #timvideos | 14:26 | |
| tvCommitBot | [dvsource-v4l2-other] stefanor pushed 1 new commit to 43-pal: http://git.io/v8cF3 | 14:26 |
| tvCommitBot | dvsource-v4l2-other/43-pal 757a7fc Stefano Rivera: American spelling | 14:26 |
| *** tvCommitBot has left #timvideos | 14:26 | |
| tumbleweed | mithro: btw, we're using this 43-pal branch, now, successfully. | 14:26 |
| mithro | tumbleweed: you are doing PAL right? | 14:27 |
| mithro | tumbleweed: CarlFK normally does NTSC IIRC | 14:27 |
| mithro | tumbleweed: merged! | 14:28 |
| *** tvCommitBot has joined #timvideos | 14:28 | |
| tvCommitBot | [dvsource-v4l2-other] mithro deleted 43-pal at 757a7fc: http://git.io/v8cFF | 14:28 |
| *** tvCommitBot has left #timvideos | 14:28 | |
| tumbleweed | mithro: yeah | 14:30 |
| tumbleweed | no idea why anyone would use NTSC for anything | 14:30 |
| tumbleweed | but yes, he does | 14:30 |
| mithro | tumbleweed: great, I guess that means we have testing with PAL and NTSC on that tool | 14:31 |
| tumbleweed | mithro: so, multiples of 25Hz might be nice to have in the available modes | 14:31 |
| tumbleweed | but we're doing fine now, with 60Hz capture, fed into a 50Hz dvswitch | 14:32 |
| mithro | tumbleweed: They are defined here -> https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/firmware/lm32/processor.c#L63 | 14:32 |
| tpb | Title: HDMI2USB-misoc-firmware/processor.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 14:32 |
| mithro | tumbleweed: I got most of the way through adding support so you could just dump a modeline for a "custom" mode too | 14:33 |
| mithro | tumbleweed: https://github.com/timvideos/HDMI2USB-misoc-firmware/commit/60f49a111650305fa780001d5c836be3305d55e9 | 14:34 |
| tpb | Title: Add support for setting custom EDID mode. · timvideos/HDMI2USB-misoc-firmware@60f49a1 · GitHub (at github.com) | 14:34 |
| mithro | All C code for that :) | 14:34 |
| tumbleweed | mithro: ah, that's fairly simple | 14:35 |
| tumbleweed | assuming I could generate modelines :P | 14:35 |
| mithro | tumbleweed: yeah - super simple :) | 14:35 |
| mithro | ysionneau is going to work on some edid stuff once we get the fx2 eeprom stuff working | 14:36 |
| ysionneau | edid plan on doing it (sorry could not refrain from saying it) | 14:41 |
| ysionneau | pardon the non native speaker jokes :' | 14:41 |
| tumbleweed | heh | 14:41 |
| mithro | _florent_: the bitstream generation is soooo much faster without that giant FIFO on the encoder | 14:47 |
| mithro | _florent_: Total REAL time to PAR completion: 3 mins 47 secs | 14:48 |
| ysionneau | o/ | 14:55 |
| mithro | seaLne: can you try the fx2-refactor branch in a second? | 15:10 |
| mithro | seaLne: https://github.com/mithro/HDMI2USB-misoc-firmware/tree/fx2-refactor | 15:18 |
| tpb | Title: mithro/HDMI2USB-misoc-firmware at fx2-refactor · GitHub (at github.com) | 15:18 |
| mithro | seaLne: well, I think I've finally gotten the fx2 firmware into a place where I can understand what is going on | 15:30 |
| mithro | xfxf: Oh, I can also fix your 30fps issue in the descriptors too! | 15:31 |
| *** kaalia has joined #timvideos | 15:58 | |
| seaLne | mithro: where should linux/ch9.h be coming from? | 16:43 |
| mithro | seaLne: third_party/fx2lib/include/linux | 16:44 |
| mithro | seaLne: The Makefile didn't run "git submodule update --recursive --init" ? | 16:45 |
| seaLne | even running that manually i still don't have third_party/fx2lib/include/linux | 16:45 |
| seaLne | no linux dir | 16:46 |
| mithro | hrm | 16:47 |
| mithro | seaLne: what does "git status" show? | 16:47 |
| seaLne | sorry just noticed there was an error in the submodule update https://paste.kde.org/pp41yjko9 | 16:48 |
| tpb | Title: KDE Paste (at paste.kde.org) | 16:48 |
| mithro | seaLne: oh, I see the problem | 16:50 |
| mithro | seaLne: try submodule update again now | 16:51 |
| seaLne | errors gone | 16:52 |
| seaLne | connect-lm32 not responding though | 16:53 |
| mithro | seaLne: did you rebuild the gateware / fx2 firmware? | 16:53 |
| seaLne | not after the submodule init? | 16:54 |
| seaLne | well i did make load-fx2 which built it | 16:54 |
| seaLne | power cycled and in | 16:55 |
| seaLne | view-hdmi2usb.sh still not getting anything though after enableing/connecting encoder | 16:57 |
| mithro | seaLne: what is dmesg and view-hdmi2usb.sh outputting? | 16:57 |
| mithro | seaLne: you can't run view-hdmi2usb.sh while connected to the lm32 either | 16:57 |
| seaLne | yeah i was killing the connect before trying the view? | 16:58 |
| mithro | seaLne: good | 17:00 |
| mithro | seaLne: but still no view? | 17:00 |
| seaLne | nope https://paste.kde.org/pdblpv2np https://paste.kde.org/p2ly47hro | 17:00 |
| tpb | Title: KDE Paste (at paste.kde.org) | 17:00 |
| seaLne | i was trying that on trusty | 17:00 |
| mithro | seaLne: do you have v4l-info installed? | 17:04 |
| seaLne | https://paste.kde.org/pshcmfkxh | 17:06 |
| tpb | Title: KDE Paste (at paste.kde.org) | 17:06 |
| mithro | seaLne: did you just install it then? | 17:13 |
| seaLne | yes | 17:13 |
| mithro | seaLne: the ./scripts/view-hdmi2usb.sh requires the v4l-info to work... | 17:13 |
| seaLne | oh | 17:13 |
| mithro | seaLne: try running that script now? | 17:13 |
| seaLne | nov video yet but its doing something | 17:14 |
| seaLne | v4l2 select timeout | 17:14 |
| mithro | seaLne: and anything in dmesg now? | 17:14 |
| seaLne | starting load from scratch | 17:15 |
| seaLne | video!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | 17:17 |
| mithro | seaLne: \o/ | 17:17 |
| mithro | seaLne: I think you are the third person in the whole world to get video out of an Opsis board :) | 17:17 |
| mithro | seaLne: myself and florent are the only other people IIRC | 17:17 |
| mithro | seaLne: hamster hasn't played with the HDMI2USB firmware stuff | 17:17 |
| mithro | It's bed time for me | 17:19 |
| mithro | (should have been bed time hours ago :P) | 17:19 |
| seaLne | mithro: thanks | 17:19 |
| mithro | xfxf: the fx2-refactor branch in my repo has the UVC FPS fix | 17:19 |
| mithro | seaLne: Now I understand both UVC stuff and the FX2 stuff a lot better, I'm going to work on making our stuff actually standards compliant :P | 17:20 |
| *** rohitksingh has quit IRC | 17:44 | |
| seaLne | mithro: just to confirm that this also works on my wily desktop | 17:45 |
| tumbleweed | mithro: what's the story of vizzini and upstream linux? bwh is making my life hard :P bugs.debian.org/804350 | 17:49 |
| mithro | tumbleweed: I should be asleep | 17:51 |
| mithro | tumbleweed: but what happened is that the exar guys effectively forked an in tree kernel driver and made it work with their crappy device | 17:52 |
| mithro | tumbleweed: shenki then fixed it to work with modern kernels | 17:52 |
| mithro | tumbleweed: It needs to be rewritten as something that can be merged into the upstream driver. | 17:53 |
| mithro | (The CDC-ACM driver) | 17:54 |
| tumbleweed | mithro: thanks! | 17:54 |
| tumbleweed | I'll paste that at him | 17:54 |
| mithro | That is never going to happen as nobody has the time or will power to do it | 17:55 |
| tumbleweed | go to sleep | 17:55 |
| mithro | Who is bwh? | 17:55 |
| tumbleweed | dvswitch author, and linux kernel maintainer | 17:55 |
| mithro | It won't be needed for the HDMI2USB stuff, even on the Atlys shortly. | 17:55 |
| tumbleweed | oh, ok, so no point packaging | 17:56 |
| tumbleweed | presumably useful for others | 17:56 |
| tumbleweed | but not for me to maintain it :P | 17:56 |
| mithro | If he wants to take a stab at making the driver upstreamable then he is welcome to do it | 17:56 |
| mithro | It's super frustrating they (exar) didn't just implement a real CDC-ACM serial port like sane people | 17:57 |
| *** rohitksingh has joined #timvideos | 17:58 | |
| mithro | I have more useful things for Linux kernel hackers to help with if they want to contribute though :-) | 17:58 |
| mithro | (IE Getting Linux running on the lm32 core) | 17:59 |
| mithro | Anyway really going to sleep now. | 17:59 |
| seaLne | mithro: so i can run connect-lm32 fine after starting view, seems happy changing video_mode during that | 18:02 |
| *** travis-ci has joined #timvideos | 18:02 | |
| travis-ci | [mithro/HDMI2USB-misoc-firmware/fx2-refactor#51] (9bda758): The build passed. (https://travis-ci.org/mithro/HDMI2USB-misoc-firmware/builds/89837352) | 18:02 |
| *** travis-ci has left #timvideos | 18:02 | |
| seaLne | mithro: in fact i can start view while connected | 18:05 |
| *** rohitksingh has quit IRC | 20:05 | |
| *** rohitksingh has joined #timvideos | 21:01 | |
| *** rohitksingh has quit IRC | 21:28 | |
| *** se6astian is now known as se6astian|away | 22:20 | |
| mithro | seaLne: it only seems to be the first view that causes problems. | 23:01 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
