diff options
Diffstat (limited to 'wiki/Chat_log/20160609-io-chatlog')
| -rw-r--r-- | wiki/Chat_log/20160609-io-chatlog | 286 |
1 files changed, 286 insertions, 0 deletions
diff --git a/wiki/Chat_log/20160609-io-chatlog b/wiki/Chat_log/20160609-io-chatlog new file mode 100644 index 0000000..fdfc144 --- /dev/null +++ b/wiki/Chat_log/20160609-io-chatlog @@ -0,0 +1,286 @@ +--- 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 |