diff options
author | Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> | 2019-12-09 15:29:52 +0900 |
---|---|---|
committer | Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> | 2019-12-09 16:23:07 +0900 |
commit | 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce (patch) | |
tree | 6392fd201a51ff0f6dc0e474803e6f3b20919504 /wiki/Chat_log/20180301-io-chatlog | |
parent | 5d9e1b983faf7645ddc3d45d28e612d2ac4179c0 (diff) |
wiki: Porting wiki: Porting Chat Log
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Diffstat (limited to 'wiki/Chat_log/20180301-io-chatlog')
-rw-r--r-- | wiki/Chat_log/20180301-io-chatlog | 144 |
1 files changed, 144 insertions, 0 deletions
diff --git a/wiki/Chat_log/20180301-io-chatlog b/wiki/Chat_log/20180301-io-chatlog new file mode 100644 index 0000000..40d9f69 --- /dev/null +++ b/wiki/Chat_log/20180301-io-chatlog @@ -0,0 +1,144 @@ +09:03 < wsa_> so, simon is excused i think we can start the meeting +09:03 < pinchartl> hi Vaishali +09:04 < vthakkar> Hi Laurent +09:04 < morimoto> Japan becaming hot :) +09:04 < wsa_> and Vaishali also rejoined successfully, welcome! +09:04 < vthakkar> Yes, my network went off for a minute. Thanks +09:06 < wsa_> so, I'd like to start with the status updates, then officially welcome Vaishali (maybe with some words from her about her), and then have a few open questions, mostly about SDHI +09:06 < wsa_> let's see how much we can talk about with Simon not being here +09:07 < wsa_> Any complaints about that? +09:07 < vthakkar> sounds good. +09:07 < wsa_> nice :) +09:08 < wsa_> so, here are the collected and slightly reworded status updates +09:08 < wsa_> A) +09:08 < wsa_> Simon took part in the HS400 patch discussion and did performance testing of +09:08 < wsa_> host/guest networking with x86 QEMU. Kaneko-san prototyped support for D3 +09:08 < wsa_> thermal. Geert fixed alias usage for serial drivers and enabled IIC on M3N. +09:08 < wsa_> Niklas got his resizable MTU patch merged (what about David's remark?). +09:08 < wsa_> Shimoda-san added USB support for M3N. Wolfram finished his generic +09:08 < wsa_> virtualization task and is now evaluating I2C passthrough, reviewed HS400 +09:08 < wsa_> patches and assorted SDHI clock dividing, and worked on watchdog requests. +09:08 < wsa_> Uli got his SCIF patches merged. +09:08 < wsa_> B) +09:08 < wsa_> Simon wants to test HS400 on M3M and continue with his QEMU task. Kaneko-san +09:08 < wsa_> wants to send out support for D3 thermal. Geert wants to remove hard dependency +09:08 < wsa_> of serial aliases (needed for I2C as well?). If time allows, Niklas wants to +09:08 < wsa_> recheck the SDHI issue workaround patch he once created. Shimoda-san has +09:08 < wsa_> multiple USB issues to work on (role swap for SS, GPIO support for USB PHY, +09:08 < wsa_> resume issue) and also learns about USB virtualization. Wolfram wants to finish +09:08 < wsa_> his virtualization task, give HW team feedback about I2C IP core, pick up more +09:08 < wsa_> SDHI work, write a talk proposal for AGL, and still wants to talk with Kieran +09:08 < wsa_> about I2C addresses. +09:08 < wsa_> C) +09:08 < wsa_> Simon checked that SDR104 on Porter still fails (test Niklas patch maybe?). +09:08 < wsa_> Wolfram so far depends on gmane NNTP for reporting, but it has become +09:08 < wsa_> unreliable in the last days. +09:08 < wsa_> so, one question to neg +09:08 < wsa_> neg: can something be done about David's comment about the MTU patch? +09:09 < wsa_> he said most users would want to have interfaces enabled when they resize MTU? +09:09 < wsa_> and a question to geertu +09:10 < neg> wsa_: I'm sure it can be done, but if we choose to do so I also think we should apply a simlar work to sh_eth +09:10 < wsa_> geertu: I don't think we need to remove hard dependencies on I2C busses, because they match the schematics. Am I correct? +09:10 < wsa_> neg: for sure. I just wondered if it can be done at all and if it was feasible to do so +09:11 < geertu> wsa_: The issue is not related to matching buses with schematics. +09:11 < wsa_> neg: I don't know the HW in enough detail to unterstand if it can be done at all with reasonable effort +09:11 < geertu> The sh-sci driver has a hard dependency on th presence of the serialN aliases. Without them, the driver won't probe. +09:12 < wsa_> geertu: Ah! +09:12 < geertu> This is mostly a relic from the serial core working with a fixed array of ports. +09:12 < neg> wsa_: Sure it's feasible but I think it will take some work as we would have to resize the rings while the nic is up. I have no plan to address this at this time, but if you think it's a good idea I can look at it as part of base +09:12 < geertu> It makes DT overlays more difficult (need to update /aliases) +09:12 < wsa_> geertu: i see. that definately should be removed. +09:12 < neg> wsa_: I think in it self it would be a usefull change for both our network drivers +09:13 < geertu> Note that on SPI the aliases are already optional, as the SPI subsystem handles dynamic bus numbers. +09:13 < geertu> I think I2C is similar to SPI w.r.t. this +09:13 < wsa_> geertu: yes +09:14 < wsa_> neg: well, if David says "most users would want this" and you also say it would be useful, I think we should target that +09:14 < geertu> wsa_: (checked) yes, see i2c_add_adapter() +09:14 < geertu> I think I can do something similar in sh-sci. I won't touch core serial, though ;-) +09:15 < wsa_> geertu: dragons live there +09:15 < wsa_> neg: I will add a todo item for it +09:15 < wsa_> neg: and you want to do it as part of a base task? +09:16 < neg> wsa_: I would be fine to do that in base but are open to other arangements +09:17 < wsa_> okay +09:17 < wsa_> we will see about that when the next round of add. tasks is due +09:18 < wsa_> if you happen to have free base time (yeah, right) until then, please have a go +09:18 < wsa_> so, simon is not here, we will handle my remark then by mail +09:19 < wsa_> status updates done, if there are no remarks from your side? +09:19 < wsa_> Then +09:20 < wsa_> Vaishali, nice to have you here. Really looking forward to working with you. Do you want to introduce yourself to the group? +09:21 < vthakkar> Wolfram, Sure. thanks. +09:22 < vthakkar> Hi, everyone. I'm Vaishali Thakkar and I started my journey with Linux Kernel via Outreachy. And later worked on security and mm related stuff at Oracle. +09:22 < kbingham> Hello Vaishali :-) (I'm somewhat amused by the coincidence of finding you on twitter as kernel_girl - then the next day being told you were joining the team!) +09:23 < vthakkar> kbingham: Ah, I assumed that you knew that before following me. :) +09:23 < vthakkar> Nice to meet you here. +09:24 < jmondi> vthakkar: Nice to meet you (we have been introduced in Prague if I'm not wrong). Welcome! +09:24 < jmondi> (and good morning to everyone else) +09:25 < vthakkar> jmondi: Yes, you're right. Nice to meet you too. +09:25 < kbingham> vthakkar: Nope :-) - You came up in some post from either google+ or twitter +09:25 < vthakkar> kbingham: Cool. :) +09:25 < kbingham> vthakkar: Sounds like I missed you in Prague - (I couldn't attend as we were having our first baby here) +09:26 < pinchartl> kbingham: that's just an excuse. lots of people have babies in Prague :-) +09:26 < wsa_> vthakkar: out of interest, did you do some device driver work so far? +09:26 < kbingham> pinchartl: I'm not sure Keri would agree :) +09:27 < vthakkar> wsa_: I've experience working on microcontrollers [Arduino, Tessel etc] for small projects but not for kernel drivers. +09:27 < wsa_> vthakkar: nice! well, that connection can be easily made ;) +09:28 < vthakkar> And this is exactly why I wanted join because so far I had worked on mm and security related stuff only. :) +09:28 < vthakkar> specifically in mainline. +09:28 < vthakkar> wsa_: Sure +09:29 < geertu> vthakkar: We met in Prague, but I believe you were at ELCE in Dublin, too, right? +09:29 < wsa_> I think you found a good spot to do this :) Again, welcome to our team! +09:29 < neg> vthakkar: welcome +09:29 < vthakkar> geertu: I wasn't in Dublin. My visa was rejected ;) Julia presented my work. +09:30 < vthakkar> neg: thanks +09:30 < vthakkar> geertu: But yes, we met in Prague. +09:30 < vthakkar> wsa_: Thanks :) +09:30 < uli___> vthakkar: hi and welcome! may i ask how you got roped into this job specifically? +09:31 < geertu> vthakkar: Oops. But I did attend Julia's session, so that must be how I remembered. +09:32 < wsa_> okay, so for the remaining issues +09:32 < vthakkar> uli__: Magnus contacted me when Julia presented my work at Dublin one. Then for some reason, I had to take up a job at Oracle and then I met Magnus at 2-3 other conferences in last 2 years and we talked about the work your groups are doing. +09:33 < wsa_> morimoto: shimoda: what is your take on maybe not enabling eMMC HS400 mode on H3 ES1.0? +09:33 < wsa_> as far as I can see, we have no "recommended HW setting" for CPG for ES1.0 +09:34 < wsa_> and the one I tried on my own didn't work for writing data +09:34 < shimoda> wsa_: I don't remember about eMMC HS400 mode on H3 ES1.0 +09:34 < wsa_> or we could ask the HW guys if there is some recommended HW setting for ES1.0 maybe? +09:34 < shimoda> but, H3 ES1.0 is not good, especially clock thing +09:36 < shimoda> wsa_: hmm, I guess hw guys said you should not use ES1.0, but I'll ask anyway :) +09:36 < wsa_> shimoda: thank you. I agree that makes most sense, if they say "don't do it", then we won't do it +09:37 < wsa_> it = HS400 +09:37 < shimoda> wsa_: i got it +09:37 < wsa_> dammsan: are you here? +09:37 < wsa_> Marex: and you? +09:38 < dammsan> yep im here +09:38 < geertu> wsa_: Marex is excused (@EmbeddedWorld) +09:39 < wsa_> I see +09:39 < wsa_> dammsan: did you read the mail from Shimoda-san about listing the revisions in the SDHI driver? +09:41 < dammsan> yeah, I discussed this with him in the office today, and i only care about disabling disallowed combos from use, ie early ES versions. +09:41 < dammsan> one way to solve this could be a black list of those ES versions +09:41 < dammsan> but i have no strong feeling really +09:42 < wsa_> like blacklisting HS400 on ES1.0? ;) +09:42 < wsa_> I see +09:42 < wsa_> thanks for the heads up! +09:43 < dammsan> s/on ES1.0//g =) +09:43 < dammsan> thanks +09:43 < wsa_> okay, this was it from my side +09:43 < kbingham> wsa_: What topics would you like to discuss regarding I2C addresses, and when would you like to do so - I'm assuming it's related to us talking when we were in Brussels - but my memory has now faded. We do have an issue in core where we might need to be able to mark an address as 'unusable' without actually using it ourselves... (unless we use it in which case it's - "in use" ...) +09:44 < wsa_> kbingham: I wanted to talk about how to encode "reprogammable addresses" +09:44 -!- horms [~horms@penelope-musen.horms.nl] has joined #periperi +09:44 < wsa_> and how to handle them (including power-on default addresses) +09:44 < kbingham> Ah yes - handle it better at the core +09:44 < wsa_> That seemed to me like the first step +09:45 < kbingham> We do have a lot of reprogrammable addresses now. +09:45 < kbingham> Ok - now I understand the context - we can schedule outside of this meeting :) +09:45 < wsa_> all the other stuff we talked in Brussels seem to either depend on it or at least would be considerable easier when we have that +09:46 < wsa_> we should have a seperate meeting/thread about that +09:46 < wsa_> can't really predict when, though :( +09:46 < kbingham> wsa_: Ok - understood :) +09:46 < wsa_> hi simon +09:46 < pinchartl> I'd like to participate to that discussion too +09:47 < wsa_> pinchartl: sure, you are welcome +09:47 < horms> hi, sorry I am late +09:47 < wsa_> hope you enjoyed the performance at the school :) +09:47 < horms> I did, thanks +09:47 < wsa_> okay, any more issues? +09:49 < wsa_> okay, then I'll hand over to Geert (sorry for the delay!) +09:49 < geertu> np |