Tuesday, 2021-03-09

*** tpb has joined #litex00:00
*** rozpruwacz has quit IRC00:05
*** really2 has joined #litex00:48
*** really2 has quit IRC00:50
*** lf_ has quit IRC00:54
*** lf has joined #litex00:55
*** really21 has joined #litex00:57
*** Bertl is now known as Bertl_zZ01:02
*** Degi_ has joined #litex03:03
*** Degi has quit IRC03:04
*** Degi_ is now known as Degi03:04
*** peeps[zen] has joined #litex03:50
*** captain_morgan0 has joined #litex03:51
*** flammit_ has joined #litex03:52
*** rektide_ has joined #litex03:54
*** keesj_ has joined #litex03:55
*** vup2 has joined #litex03:55
*** acathlaway has joined #litex03:57
*** rektide has quit IRC03:59
*** really21 has quit IRC03:59
*** peepsalot has quit IRC03:59
*** keesj has quit IRC03:59
*** geertu has quit IRC03:59
*** vup has quit IRC03:59
*** flammit has quit IRC03:59
*** acathla has quit IRC03:59
*** captain_morgan has quit IRC03:59
*** captain_morgan0 is now known as captain_morgan03:59
*** flammit_ is now known as flammit03:59
*** geertu has joined #litex04:02
*** really2 has joined #litex04:15
*** Emantor has quit IRC05:23
*** Emantor has joined #litex05:24
st-gourichon-fid_florent_, thank you for your answer.06:21
*** rozpruwacz has joined #litex06:22
*** lkcl_ has quit IRC06:45
*** rozpruwacz has quit IRC06:48
*** rozpruwacz has joined #litex06:49
*** lkcl_ has joined #litex06:57
*** really2 has quit IRC07:00
*** proteusguy has quit IRC07:33
*** proteusguy has joined #litex07:47
_florent_st-gourichon-fid: This should fix your issue: https://github.com/enjoy-digital/litex/commit/ece90059493f820b0a3a6693d1df9e7b869f4a8d08:12
_florent_st-gourichon-fid: Also with FPGA designs, it's generally better to keep a bit of margin on resources to avoid too much troubles while maintaining a project and allow adding features (even small ones) or integrating bug fixes (that can sometimes use resources)08:20
_florent_st-gourichon-fid: This is also useful to be able to integrate some debug probes.08:21
_florent_st-gourichon-fid: I would not recommend using more than 75% on a project that will continue to evolve08:23
_florent_st-gourichon-fid: Also saying that since it relaxes things for open source project maintainers: We generally try to do the best, but sometimes there can be variations dues to bug fixes, portability, etc... and having some margin is always nice :)08:25
geerturozpruwacz: 8d885998822bb625aa854b52e6627ab42f03bfb9 looks good to me09:02
rozpruwaczgeertu: thanks, and what about https://github.com/mczerski/litex (commit c234d1b54ce73950614e270b26e29b5e84f4c7cf) ? changes in kernel driver depend on it.09:13
geerturozpruwacz: For 444d3dae2e78f8e89ed9c1788f30d2cf574aebe3, do you need litex_irq_domain_translate() and the chained_irq_*() stuff?09:13
geertu(I'm comparing with drivers/gpio/gpio-rcar.c as a reference)09:13
geerturozpruwacz: Sorry, I have to defer to the experts for the litex change09:14
rozpruwaczgeertu: I think that litex_irq_domain_translate is required because if it is not supplied then it defaults to litex_irq_domain_tranirq_domain_translate_twocellslate which in turn call irq_domain_translate_twocell which requires two cells in device tree part that describes gpio interrupt pin (pin number and IRQ_TYPE). In litex-gpio the IRQ_TYPE is fixed by the gpio controller (GPIOIn) so allowing to specify IRQ_TYPE would be misleading in09:31
rozpruwaczmy opinion. If GPIOIn would allow to controll the IRQ_TYPE then litex_irq_domain_translate would be not needed09:31
rozpruwacztypo: litex_irq_domain_tranirq_domain_translate_twocellslate -> irq_domain_translate_twocellslate09:31
rozpruwaczehh, litex_irq_domain_tranirq_domain_translate_twocellslate -> gpiochip_hierarchy_irq_domain_translate09:32
rozpruwaczand I based my implementation on gpio/gpio-tegra186.c09:33
geerturozpruwacz: So you cannot specify the interrupt polarity when using the GPIOs as IRQs?09:34
rozpruwaczGeertu: the polarity is defined at HDL level look at: litex/soc/cores/gpio.py. And I just remembered one other thing. The driver works only with falling edge, because rising edge causes the GPIOIn interrupt lines works as level trigger instead of edge trigger.09:36
rozpruwaczSo with rising edge trigger adter gpio goes high the interrupt is called over and over until gpio line goes low.09:38
*** rozpruwacz has left #litex09:38
*** rozpruwacz has joined #litex09:38
rozpruwaczgeertu: and regarding the chained_irq_enter/chained_irq_exit. As mentioned, I based my changes on gpio/gpio-tegra186.c, and to my understanding litex_gpio_irq is attached as chained interrupt in gpio/gpiolib.c using irq_set_chained_handler_and_data call. So to my understanding if it is chained interrupt it mus use  chained_irq_* - but I'm not an expert in linux drivers :) I wrote only few in my life.09:44
geerturozpruwacz: OK, let's see what the other reviewers will say when you submit it or upstream inclusion09:47
rozpruwaczgeertu: is https://github.com/litex-hub/linux the correct place to do pull request ?09:53
*** TMM has quit IRC10:14
*** TMM has joined #litex10:14
st-gourichon-fid_florent_, oh yes I fully agree with you. We often include only part of the design, to have a quick and easy build cycle.  Sometimes, we have to test the whole design, though.  We also strive to help reduce unnecessary weight (I've heard there's some room for improvement in the UART implementation in LiteX, we used to have 6 of them and they appear to consume much more resources than expected.)10:23
_florent_rozpruwacz: We should fix the rising edge IRQ generation, I could look at that10:24
geerturozpruwacz: rozpruwacz: I think the correct process is documented in Documentation/process/submitting-patches.rst10:25
geertuunless litex-hub wants to accept PRs? But who'll be in charge to get them upstream?10:25
geertu_florent_: ^10:25
_florent_rozpruwacz: We could also make the polarity configurable by a register, but in this case we should probably remove the polarity parameter at the SoC level10:25
_florent_rozpruwacz: And maybe just have a with_irq parameter to GPIOIn that would add IRQ capability to all the Input pins of this GPIO + a register to configure the level10:26
geertu_florent_: That sounds like the better option.  You don't always know what will be the use case for the GPIO.10:26
_florent_geertu: Indeed, I just merged rozpruwacz's initial IRQ support, but this is indeed maybe not generic enough10:27
geertuIn particular, I'm thinking about adding support for plugging in random FeatherWings on the OrangeCrab.10:27
_florent_And this would in fact simplify the code in the SoC10:28
geertu(which is what I'm working on)10:28
rozpruwacz_florent_: Agree to all. I did not wanted to change the HDL behaviour so I match the driver to suite the HDL. But I think that Your suggestions for HDL changes are perfectly reasonable.10:28
_florent_rozpruwacz: Good, I was going to ask you if it was OK that I do the changes to go in this direction10:29
geertuAdafruit 0.54" Quad Alphanumeric FeatherWing Display (https://www.adafruit.com/product/3130) is working fine, scrolling messages. need to clean up the rather large code changes before submitting them upstream.10:31
tpbTitle: Adafruit 0.54 Quad Alphanumeric FeatherWing Display - Red ID: 3130 - $9.95 : Adafruit Industries, Unique & fun DIY electronics and kits (at www.adafruit.com)10:31
_florent_Otherwise for the Linux drivers, this can probably be discussed here, somlo is maintaining a branch in https://github.com/litex-hub/linux  (litex-rebase) with all the recent work10:31
geertutpb: yep, that one ;-)10:31
_florent_This allow us to test the drivers with the different Linux projects (VexRiscv, Rocket, Mor1kx mostly)10:32
geertuFor Adafruit FeatherWing OLED - 128x32 OLED (https://www.adafruit.com/product/2900), the display works, but I'll have to look into GPIOs for the buttons.10:33
tpbTitle: Adafruit FeatherWing OLED - 128x32 OLED Add-on For Feather ID: 2900 - $14.95 : Adafruit Industries, Unique & fun DIY electronics and kits (at www.adafruit.com)10:33
_florent_And when the drivers are validated, Antmicro/shorne/shenki try to push the drivers upstream through the mor1kx port10:34
_florent_geertu, rozpruwacz: https://github.com/enjoy-digital/litex/issues/842, I'll try to look at this today10:39
geertu_florent_: thx10:40
_florent_geertu: For you case where various featherwing are plugged, this indeed makes sense to be able to configure interrupt polarity dynamically10:41
_florent_geertu: this would also make sense to add it to GPIOTristate, this way you could just create a GPIOTristate on all featherwing IO and dynamically reconfigure them as Input/Output and use IRQs on Inputs10:43
geertu_florent_: And the next step will be adding pinmuxing, as some wings may want to use e.g. the RX/TX pins as GPIOs ;-)10:48
*** Bertl_zZ is now known as Bertl11:10
*** Bertl is now known as Bertl_oO12:16
_florent_rozpruwacz, geertu: The GPIOIn IRQ rework should be done with https://github.com/enjoy-digital/litex/commit/0d8b6f8fbbedca5e3e2a84bfaf15684e825cca08 and https://github.com/enjoy-digital/litex/commit/0e7d8219ead8226013b75f3e15116e7e43fa5c7113:01
*** keesj_ has quit IRC13:04
*** keesj has joined #litex13:04
rozpruwacz_florent_: ok, I test it when I have time (not so much lately ... :()13:05
geertu_franck_: thx, that was quick13:06
*** vup2 is now known as vup13:06
_florent_rozpruwacz: ok no problem,  just took the time to did it while waiting for a design to compile :) (I think it should be ok, but I only verified the compilation and produced .h/.v, haven't tested it on sim or hardware)13:09
somlo_florent_, rozpruwacz: let me know when the dust settles on the gpio irq linux driver updates, and we can certainly add a few extra patches to the litex-rebase branch for testing. (I haven't had a chance yet to come up to speed on Linux IRQ handling in general, although I'll probably have to do that once we figure out the current litesdcard bug -- I think adding IRQ support *there* could be one way to make it faster)14:52
*** rj has joined #litex15:09
*** lkcl_ has quit IRC15:27
*** rj has quit IRC15:35
*** lkcl_ has joined #litex15:39
*** rj has joined #litex15:39
*** lkcl_ has quit IRC15:51
*** rozpruwacz has quit IRC16:00
*** lkcl_ has joined #litex16:04
*** rozpruwacz has joined #litex16:15
*** rj has quit IRC16:18
*** rj has joined #litex16:20
*** rj has quit IRC17:03
*** rozpruwacz has quit IRC17:03
*** rj has joined #litex17:07
*** rozpruwacz has joined #litex17:08
*** rj has quit IRC17:20
*** rj has joined #litex17:23
*** rj has quit IRC17:47
*** rozpruwacz has quit IRC17:51
*** rj has joined #litex17:52
*** rj has quit IRC18:30
*** rozpruwacz has joined #litex18:33
*** rj has joined #litex18:34
nats`Finally I have time to send the code that doesn't generate clock constraint in UCF, Spoiler Alert: I certainly do something stupid18:47
nats`https://pastebin.com/Z6GjDVUV18:47
tpbTitle: LiteX no clock constraint - Pastebin.com (at pastebin.com)18:47
nats`And second link is the resulting UCF18:47
nats`https://pastebin.com/CWuwiHF418:47
tpbTitle: LiteX generated constraint - Pastebin.com (at pastebin.com)18:47
*** rj has quit IRC19:15
*** rj has joined #litex19:19
*** rj has quit IRC20:00
*** rj has joined #litex20:03
*** Stary is now known as stary-but-differ20:09
*** stary-but-differ is now known as Stary20:14
*** TMM has quit IRC20:38
*** TMM has joined #litex20:38
*** rj has quit IRC20:44
*** rj has joined #litex20:47
*** rozpruwacz has quit IRC21:27
*** rj has quit IRC21:27
*** rj has joined #litex21:30
*** rozpruwacz has joined #litex21:33
*** rj has quit IRC22:13
*** rj has joined #litex22:16
*** rj has quit IRC22:44
*** pftbest has quit IRC22:45
*** rj has joined #litex22:46
*** pftbest has joined #litex22:57
*** pftbest has quit IRC23:20
*** pftbest has joined #litex23:27
*** rj has quit IRC23:28
*** rj has joined #litex23:31
*** pftbest has quit IRC23:31
*** rozpruwacz has quit IRC23:59

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!