path: root/wiki/Chat_log/20160609-io-chatlog

--- Log opened Thu Jun 09 09:58:45 2016
09:58 -!- wsa_ [~wsa@dslb-178-012-237-128.178.012.pools.vodafone-ip.de] has joined #periperi-io
09:58 -!- Irssi: #periperi-io: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
09:58 -!- Irssi: Join to #periperi-io was synced in 3 secs
10:00 -!- morimoto [~user@relprex3.renesas.com] has joined #periperi-io
10:00 -!- geertu [~geert@d54C36B15.access.telenet.be] has joined #periperi-io
10:00 < geertu> G'day
10:00 <@uli___> good morning
10:01 < morimoto> hi
10:01 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi-io
10:01 < shimoda> hi
10:01 < wsa_> hi all
10:02 -!- Irssi: #periperi-io: Total of 5 nicks [1 ops, 0 halfops, 0 voices, 4 normal]
10:03 < wsa_> geertu: short question before: I assume I don't need to send a pull-request for the H3-PFC-voltage-switching topic branch?
10:03 < wsa_> since you pick it up anyways
10:04 < geertu> wsa_: Nope, it was already included
10:05 -!- neg [~neg@unaffiliated/neg] has joined #periperi-io
10:05 -!- Irssi: #periperi-io: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal]
10:06 < neg> hi I have no IO task but maybe there are some residue from my old tasks so I hope it's OK i pop in?
10:06 < wsa_> so, i pinged simon also by mail, let's start
10:06 < wsa_> neg: you are very welcome here :)
10:07 < wsa_> let's have updates by person, again powered by an honest sort -R
10:07 -!- horms [~horms@reginn.isobedori.kobe.vergenet.net] has joined #periperi-io
10:07 < wsa_> hi simon
10:07 < horms> sorry i am late, thanks for pinging me!
10:07 < wsa_> morimoto: you are first this time
10:07 < wsa_> any news on schedule/requests/tasks?
10:08 < morimoto> not new item from me
10:08 < morimoto> Ahh
10:08 < morimoto> r8a7792 are now OK for upstreaming
10:08 < morimoto> that's it :)
10:08 < wsa_> that was good news in deed
10:08 < horms> thanks for sorting that out :)
10:09 < geertu> Yeah, Sergei is eagerly waiting for his patches to be applied
10:09 < wsa_> morimoto: do you know anything about khiem-san and the thermal driver?
10:09 < morimoto> good question
10:09 < morimoto> no response from him
10:09 < morimoto> I need to ask to him or BSP team
10:10 < wsa_> i can also ask him in the minutes from this meeting
10:11 < morimoto> thanks
10:11 < wsa_> i mean, he is also on the list, no need to bury you with proxy-work
10:11 < wsa_> ok
10:11 < wsa_> so, niklas is next, but as he mentioned already he is not assigned a task currently
10:12 < wsa_> and I heard no other feedback from the I2C DMA patches
10:12 < wsa_> so i think we are good here
10:13 < wsa_> then, it is my turn
10:13 < wsa_> i don't have an additional IO task for this month
10:13 < wsa_> some leftovers from the watchdog pretimeout (upstream discussions)
10:14 < wsa_> and some more playing with SDIO cards
10:14 < wsa_> main thing this month will be to create new additional tasks for next quarter
10:14 < wsa_> i expect this to start in next week
10:15 < wsa_> let's see if this will be a little more fluent than last quarter :)
10:15 < wsa_> that's from my side
10:15 < wsa_> shimoda: do you have any news?
10:16 < shimoda> i tried to debug EHCI + IPMMU on Gen3, but it doesn't work yet
10:17 < wsa_> pity
10:17 < shimoda> also I will do OTG support because some related framework is coming soon and TI guys requests me about it
10:17 < shimoda> usb3 suspend issue, i don't have any update
10:18 < shimoda> that's from my side
10:19 < horms> shimoda: are you planning to resubmit DTS patches for gen3 usb?
10:19 < wsa_> geert recently mentioned that CMA cannot be enabled because of USB
10:19 < wsa_> is this a known issue for you?
10:19 < shimoda> i will resubmit it after phy maintainer applied a bugfix patch
10:20 < wsa_> "OHCI-PCI doesn't seem to work with CONFIG_DMA_CMA=y (ohci-pci 0001:01:01.0: OHCI Unrecoverable Error, scheduling NEC chip restart)"
10:21 < wsa_> i guess we should make a task out of it
10:22 < shimoda> horms: if possible, i would like to resubmit without hsusb enable patch. is it acceptable?
10:23 < horms> Ok, so basically patches 1 - 3, but not patch 4 ?
10:23 < horms> I am referring to: [PATCH v2 0/4] arm64: dts: r8a7795: Add HSUSB device node and enable channel 0 of USB2.0
10:23 < shimoda> horms: yes, but i should test such a case though :)
10:24 < wsa_> the question would be then if you have time for it or if it is okay if someone else has a look?
10:26 < shimoda> wsa_: about CMA issue in gen2, i don't have any information... but I guess this is related to memory range or somethings
10:26 < shimoda> the hardware cannot access 4GB over area
10:26 < horms> shimoda: I think I am ok with that approach
10:27 < wsa_> neg: how's your bandwidth currently? :)
10:28 < shimoda> horms: thanks! after I tested it, i will submit it. maybe tomorrow
10:28 < horms> thanks. no rush from my side :)
10:28 < neg> wsa_: a bit swamped for this month, next month nothing planed yet
10:28 < shimoda> horms: i got it :)
10:28 < wsa_> ok
10:28 < wsa_> looks like this task has to wait for July then
10:29 < wsa_> let's see about capacities then
10:30 < wsa_> ok, simon, your turn now
10:30 < horms> sure
10:31 < horms> I have made some progress on i2c demux
10:31 < horms> so far I have only focused on lager as I'd like to get the requirements sorted before extending to other boards
10:31 < horms> I think that may be close but as per my v2 positing my testing indicates that not all combinations work as i might have expected
10:32 < horms> That angle I'm not so sure how to move forwards on. I was kind of hoping wsa_ might look into it.
10:32 < geertu> horms: Are there bugs in the pfc-r8a7790 driver?
10:32 < horms> I have considered that
10:32 < horms> And I spent quite some time comparing pfc-r8a7790.c to the documentation I have
10:33 < horms> in particular the i2c related portions of both
10:33 < horms> but I have been unable to find anything that looks wrong
10:34 < wsa_> I have to admint I missed the "Discussion of Testing" part of your cover letter :(
10:34 < wsa_> however I managed to do that
10:34 < wsa_> will have a look later
10:35 < horms> No problem. It seems that I now have your attention :)
10:35 < horms> Thanks
10:35 < horms> Moving on
10:35 < wsa_> GPIO fallback worked for me on I2C2
10:35 < geertu> BTW, have you seen Pantelis' DT connector work?
10:35 < horms> Ok. It didn't seem to work for me. Lets try to work out what the difference is.
10:35 < geertu> It's somewhat related
10:35 < horms> No, I have not seen that
10:36 < horms> ---
10:36 < geertu> The connector work abstracts the functionality that can be provided on a set of pins
10:37 < geertu> E.g. 2 pins can be used as 2 GPIOs, a UART, or an i2c bus.
10:37 < geertu> basically DT pinctrl on steroids
10:38 < horms> ok
10:38 < horms> it does sound somehow related
10:38 < geertu> We want to use a set of pins for a fixed functionality, but change the "driver" behind it
10:39 < geertu> It's too early to see how it can be integrated, though, but I wanted you to be aware of it.
10:39 < geertu> Pantelis also gave a presentation about it at ELC2016
10:39 < geertu> perhaps Niklas saw it?
10:40 < neg> hum not that I can recall right now
10:40 < geertu> He wants to describe a connector (expansion port) in term of the functionality it can provide, so the user doesn't have to care about the deep details.
10:40 < geertu> Mostly focussed on BeagleBone series.
10:41 < geertu> That's it
10:41 < horms> Ok, thanks for the info.
10:41 < horms> My other task is Gen 3 SDHI DMA
10:42 < horms> The task is to upstream the Gen 3 SDHI DMA driver, which is different from the non-Gen3 SDHI DMA driver.
10:42 < horms> And in possible preparation for even more DMA drivers, e.g. for different Gen3 SoCs.
10:42 < horms> The approach I am taking so far is as follows.
10:42 < horms> 1. Rename sh_mobile_sdhi.c as renesas_sdhi.c (not strictly related)
10:43 < horms> 2. Refactor the TMIO DMA code so that it is provided by a set of callbacks rather than compiled-in function calls; Refactor the DMA SDHI to use this.
10:44 < horms> 3. Rename tmio_mmc_dma.c as renesas_sdhi_dma.c which reflects more closely what it is is, particularly after step 2. This is why I wanted the rename in step 2: to avoid adding another sh_mobile file when I am separately trying to convert to "renesas"
10:45 < horms> 4. Add Gen3 DMA code as a separate set of callbacks
10:45 < horms> The SDHI code itself knows which callbacks to instantiate based on the compat-string: its in the probe function
10:45 < horms> The two sets of DMA callbacks may be compiled in at the same time. Though there are some caveats:
10:46 < horms> The Gen3 SDHI code doesn't seem to compile on ARM32 so I don't allow that
10:46 < horms> s/SDHI/SDHI DMA/
10:46 < horms> I protected the non-Gen3 SDHI code with COMPILE_TEST on ARM64 as it will never actually be used
10:47 < horms> -- end summary --
10:47 < horms> Oh sorry, one more thing.
10:47 < wsa_> caveats sound OK to me
10:47 < horms> The DMA code moves from the tmio_core to renesas_sdhi kernel module
10:47 < horms> the DMA code is not a separate module either before or after my proposed changes
10:48 < wsa_> general approach sounds good, too
10:48 < wsa_> how many callbacks are needed?
10:48 < horms> The result seems fairly clean within the context of the spagetti arrangement that tmio/sdhi is
10:48 < wsa_> :D
10:48 < horms> I don't recall exactly, but around 1/2 a dozen
10:48 < horms> I made a little structure for them
10:48 < wsa_> good
10:49 < shimoda> about gen3 sdhi, i'm not sure the final decition but I heard later gen3 socs have SYS-DMAC interface
10:49 < horms> ok. so the current arrangement allows us some flexibility on a per-soc basis
10:49 < horms> based on the compat string
10:49 < wsa_> yes, this was a priority for this task
10:49 < shimoda> horms: oh, i see. it's nice!
10:49 < horms> but the implication is that if the DMA code differs then the compat string should also differ. i.e. no generic gen3 fallback
10:50 < horms> possibly I should only enable your Gen3 DMA code for the H3?
10:50 < geertu> Goodbye renesas,rcar-gen3-*?
10:50 < shimoda> I have information about H3 restriction. please don't use multiple sdhi DMAC channels :)
10:51 < horms> ok
10:51 < horms> geertu: that is the implication. but perhaps its not a good choice
10:51 < shimoda> after that, sometimes read data is lost
10:51 < horms> ok, so how might I enable multiple channels?
10:51 < horms> (or not!)
10:51 < shimoda> s/is lost/is delayed/
10:52 < geertu> shimoda: probably this is about concurrent use?
10:52 < horms> geertu: would it be better to have a property of the sdhi node that indicates a flavour of dma to be used on gen3?
10:53 < shimoda> geertu: yes. if we use multime channels at the same time, read data is delayed. so, if driver do unmap soon, the data is lost
10:54 < wsa_> ouch
10:54 < shimoda> this restriction will be fixed in next ES. This issue has H3 ES1.1 and M3-W
10:54 < shimoda> Oops, H3 ES1.1 and M3-W have this issue
10:57 < horms> Ok. Perhaps we can move on. We can come back to this. e.g. when I've posted some patches
10:58 < wsa_> that hurts. given that SDHI also does eMMC on Gen3, only one DMA channel will affect either rootfs or SD card reading :/
10:58 < wsa_> ok
10:58 < wsa_> geertu, how are things? ;)
10:59 < geertu> SCIF,v4.7,public,geert,Extend subsystem with GPIO-based software handling and hardware flow control
10:59 < geertu> v3 posted, no changes except for acks etc
10:59 < geertu> SCIF,?,noplan,?,Add support for hardware assisted modem-control
10:59 < geertu> included in v3 above (was also included in v2)
11:00 < geertu> SCIF,v4.8,plan,geert,SCIF FIFO flushing 
11:00 < geertu> posted, test on elinux wiki
11:00 < geertu> (invoice/report May 31)
11:01 < geertu> SPI,2016-05-31,plan,geert,Implement initial SPI slave prototype support for R-Car Gen2
11:01 < geertu> I'm doing this as a little side job, where time permits
11:02 < wsa_> great
11:02 < geertu> I've verified that the code from the BSP works, and allows to receive/transmit known-size messages, triggered by the SPI master
11:02 < wsa_> i hope it will be one of your additional tasks next quarter
11:02 < geertu> I've fixed the obvious hacks in the code (like redefining HZ :-)
11:03 < geertu> I'm thinking about DT / core changes needed to handle it properly
11:03 < geertu> I hope to post some minimal prototype / RFC around the deadline for ELCE submissions
11:04 < wsa_> wanna talk about it? :)
11:04 < geertu> That's the idea
11:04 < wsa_> cool
11:04 < geertu> Was your i2c slave code accepted before you submitted the presentation?
11:05 < wsa_> uuuuh
11:05 < wsa_> i think so
11:05 < wsa_> very likely
11:05 < geertu> Of course you were the maintainer ;-)
11:05 < wsa_> :)
11:06 < geertu> Well, the Kalray architecture is still not submitted upstream, while it's been presented at ELC2014 and ELCE2014
11:06 < horms> FWIW, I usually present on code that is not yet upstream
11:07 < geertu> Good.
11:07 < wsa_> let's hope you will have some focus time to work on it next quarter. i am positive about that, though
11:07 < geertu> On a related note: Does anyone know what happened to the DRIF driver?
11:08 < horms> Not i
11:08 < wsa_> nope
11:09 < wsa_> okay, thanks geert
11:10 < wsa_> uli___: finally, your turn :)
11:10 <@uli___> i looked at the wiring on the lager board
11:10 <@uli___> for the sd over msiof thing
11:11 <@uli___> looks like magnus's hack should work exactly as on salvator-x
11:11 <@uli___> with some magic numbers exchanged
11:11 <@uli___> and it does need two connectors :)
11:11 <@uli___> that's it so far
11:11 < wsa_> really, cool
11:11 < wsa_> then i missed something when looking at the specs
11:12 < wsa_> did you get a zebax breakout adapter now?
11:12 <@uli___> no, just connectors
11:12 <@uli___> i refuse to pay 95 dollars for an electromechanical adapter :)
11:13 <@uli___> i think i'll solder it, with the hooks it really looks a bit dodgy
11:13 < geertu> Recently I've soldered some wires to a Samtec QTE40 for ape6evm remote control
11:14 < geertu> Glue it on a protoboard, and watch https://www.youtube.com/watch?v=i5MNLTc7YhY
11:15 < geertu> uli___: be ware you need to use cs-gpio to use msiof for mmc
11:15 < geertu> uli___: hardware-cs deasserts cs in between transfers
11:15 <@uli___> that's how it is in the damm hack
11:16 <@uli___> should work
11:16 < geertu> ok
11:16 < geertu> Note that msiof is broken on H3 ES1
11:16 < wsa_> it's gen2 work
11:16 < horms> geertu: Video at URL above is not available in my country :(
11:16 < geertu> You'll have to wait for M3-W
11:17 < geertu> horms: http://www.nicovideo.jp/watch/sm22265444 ?
11:17 < geertu> http://elm-chan.org/docs/wire/wiring_e.html is the maker's site
11:18 < wsa_> uli___: and it seems you triggered a resend for the CANFD driver :)
11:18 <@uli___> yes :)
11:19 < neg> geertu: that is some serious wiring :-)
11:19 < wsa_> nice, let's see how that goes...
11:19 < wsa_> okay, i think we are done?
11:19 < wsa_> anything left?
11:20 < horms> not from my side
11:20 < wsa_> good then
11:20 < wsa_> thank you guys!
11:21 < wsa_> continued happy hacking ;)
11:21 < horms> thanks, and sorry again for being late
11:21 < wsa_> no problem
11:21 < morimoto> thanks
11:21 -!- horms [~horms@reginn.isobedori.kobe.vergenet.net] has quit Quit: Leaving
11:21 < morimoto> have a good weekend, bye
11:22 < neg> thanks all, bye
11:22 < geertu> neg: yeah, real cool video.
11:22 <@uli___> cu
11:22 < geertu> morimoto: Thanks, one more day to go for us :-)
11:22 < geertu> s/one/one + a halve/
11:22 < morimoto> Hehe :) I will take day off tomorrow (^o^)
11:23 < geertu> thx, bye!
11:23 < neg> geertu: everytime I watch something like that I look at my electric junk pile and ask my self how hard can it be :-)
11:23 < shimoda> bye!
11:24 -!- shimoda [~shimoda@relprex2.renesas.com] has quit Quit: WeeChat 0.4.2
11:24 < geertu> neg: I followed his principles to wire a pin header to a Samtec connector, using enameled copper wire salvaged from an old motor.
11:24  * wsa_ prefers to not watch the video then ;)
11:24 -!- morimoto [~user@relprex3.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"]
11:25 < geertu> geertu: Without watching the video, I would have failed.
11:25 < geertu> (or not started at all ;-)
11:26 < neg> geertu: that's a nice source of coated wire, never thought of it. But I'm a bit interessted in the wire "feeding" tool he uses need to get me one
11:27 < neg> soldering is a bit like golf that way, even if you are bad at it you think you will play better with more expensive gear...
11:27 < geertu> neg: I've also built one myself, from a broken propelling pencil ("vulpotlood") with a metal tip
11:27 < geertu> I didn't want to buy one before I could try it ;-)
11:28 < neg> ahh yes that would work, so no work for me today I need to build tools :)
11:29 < geertu> Or buy on http://www.conrad.com/ce/en/product/532630/Wire-wrapping-tool--PB-Fastener-079-001732G-1-pcs
11:31 < neg> when conrad started its swedish branch it was not good for my wallet, lots of nice stuff
11:31 < geertu> They can take a while to deliver...
11:32 < geertu> I received part of my last order May/B.
11:32 < geertu> I've received the last two remainings (one they did have in stock from the beginning!) earlier this week
11:33 < neg> yes if its out of stock it takes ages, bought a desk lamp wiht a magnifyinglass attahced think it was 10 weeks before I recived it
11:35  * geertu is still happy with the soldering station he had to buy to add the capacitors
11:36 < neg> still havent solderd mine, but I'm impressed that you managed it without heating the board first
11:37 < geertu> It doesn't look nice
11:37 < geertu> But the multi-meter agrees everything is soldered
11:38 < geertu> Didn't manage to make my board draw more than 1 A though
11:38 < geertu> Perhaps I have to join the multimedia group for that ;-)
11:39 < geertu> Ground planes are hard
11:39 < geertu> I soldered a 2-pin header for reset to the Raspberry Pi 2 Model B I won at last ELCE
11:39 < geertu> The reset pin was a piece of cake
11:40 < geertu> The GND pin was hard, as the copper circular pad was very small, and even such a small board has a heavy heat sucking ground plane 
11:41 < neg> yes and when you work with replacable HW it's easier since if you mess up you can buy a new one, but breaking my Salvator-X I would say is a bad thing
11:41 < geertu> Interestingly, soldering a 50 pin header to my armadillo with the old 25W iron was easy before.
11:41 < geertu> Let's blame the very small circular pad...
11:42 < geertu> neg: You might get an ES1.1 sooner ;-)
11:42 < neg> ohh so thats how I get first in line
11:43 < neg> anyhow now I need to run to catch my lunch date, talk to you later
11:44 < geertu> Enjoy lunch, time to leave #periperi-io
11:44 -!- geertu [~geert@d54C36B15.access.telenet.be] has left #periperi-io []
--- Log closed Thu Jun 09 12:11:13 2016