From 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Mon, 9 Dec 2019 15:29:52 +0900 Subject: wiki: Porting wiki: Porting Chat Log Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20161110-io-chatlog | 244 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 244 insertions(+) create mode 100644 wiki/Chat_log/20161110-io-chatlog (limited to 'wiki/Chat_log/20161110-io-chatlog') diff --git a/wiki/Chat_log/20161110-io-chatlog b/wiki/Chat_log/20161110-io-chatlog new file mode 100644 index 0000000..c1b2a8d --- /dev/null +++ b/wiki/Chat_log/20161110-io-chatlog @@ -0,0 +1,244 @@ +--- Log opened Thu Nov 10 08:59:02 2016 +08:59 -!- wsa_ [~wsa@p5B38561D.dip0.t-ipconnect.de] has joined #periperi-io +08:59 -!- Irssi: #periperi-io: Total of 5 nicks [1 ops, 0 halfops, 0 voices, 4 normal] +08:59 < wsa_> hi guys +08:59 -!- Irssi: Join to #periperi-io was synced in 7 secs +08:59 -!- shimoda [~shimoda@relprex3.renesas.com] has joined #periperi-io +08:59 < geertu> Mornin' +08:59 < shimoda> hi +08:59 < uli___> hello +09:00 < neg> morning +09:01 -!- Irssi: #periperi-io: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal] +09:01 <@morimoto> Hi +09:05 < wsa_> so, let's start +09:05 < wsa_> (and hope simon will come later) +09:06 < wsa_> well, the updates are on the mailing list, i think no need to repeat them here, or? +09:07 < wsa_> so, in addition to the topics I posted yesterday, there seems to be one more from Shimoda-san about error handling in SDHI +09:07 < wsa_> please feel free to add topics on-the-fly +09:07 < shimoda> i also have one things about serial driver +09:07 < wsa_> ok +09:07 < wsa_> let's start with that :) +09:10 < wsa_> ? +09:10 < shimoda> this mean from me? +09:12 < wsa_> yes, the serial driver thing +09:12 < shimoda> ok +09:12 < shimoda> I got an answer from Geert-san about hardware flow control. +09:12 < shimoda> But I got another question from bsp team. +09:13 < shimoda> after the kernel boot, the kernel accepts to change the baudrate and/or hardware flow control? +09:13 < shimoda> I googled it but i could not any information for now... +09:13 < geertu> shimoda: For the console? +09:13 < shimoda> do you know this? +09:13 < shimoda> yes, on the serial console +09:14 -!- horms [~horms@217.111.208.18] has joined #periperi-io +09:14 < geertu> I don't think you can change the serial console parameters after boot. +09:15 < geertu> Except for difference between earlyprint/earlycon (which should not be enabled for production) and the real serial driver +09:15 < geertu> earlyprint/earlycon depend on bootloader setup +09:16 < wsa_> I can't recall such a feature either +09:16 < geertu> real serial driver depends on console= (incl. speed) and stdout-path (incl. (a possible different) speed) +09:17 < geertu> When userspace starts, init may start a getty, possibly using a different speed +09:19 < shimoda> after started a getty, a linux should not accept to change the parameter? +09:20 < wsa_> if you respin getty? +09:20 < shimoda> if user use stty +09:20 < geertu> Yeah, I was just trying that... +09:21 < geertu> Seems to work +09:21 < geertu> stty speed 38400 < /dev/ttySC0 +09:22 < shimoda> yes, i also tried on salvator-x. set_terimous will be called, but set_mctrl will be not called +09:22 < geertu> After that the serial console (kernel output) and my shell (userspace) use 38400 +09:23 < geertu> You mean when changing flow control? +09:23 < shimoda> geertu: yes +09:23 < geertu> I don't know if you really want flow control on the serial console. +09:24 < geertu> As it will slow down the kernel output even more +09:24 < shimoda> i also don't know. but, bsp team seems such test cases (changing flow control) +09:25 < geertu> For testing, I always did that on a "spare" serial port (lots of SCIF variants on EXIO connectors) +09:25 < geertu> The reason it doesn't work is probably because of the same flow conrol issue in io/todo +09:27 < shimoda> i see. this means if we fix the issue, we can use the flow control on the serial console? +09:28 < geertu> Probably +09:29 < shimoda> i got it. +09:29 < shimoda> BTE +09:29 < shimoda> BTW, +09:29 < geertu> I'd ike to emphasize that using flow control on the serial console allows the terminal program/host to bring the embedded system to a halt, by keeping CTS deasserted +09:30 < shimoda> do you know a use case that hardware flow is changed at runtime? +09:30 < shimoda> geertu: i see. +09:31 < geertu> Not really. Either you have CTS/RTS wired up, or not. +09:32 < geertu> If outputting of kernel messages is disabled, it may be desirable for a userspace application running on the same serial port, though. +09:33 < shimoda> i got it. thanks! +09:34 < wsa_> ok +09:34 < wsa_> next topic? +09:34 < wsa_> would be MSIOF then +09:35 < wsa_> am I still aligned? We won't support H3 1.0 and 1.1 upstream +09:35 < wsa_> Geert will test M3-W soon, and we expect H3 2.0 to be working? +09:36 < geertu> I don't know about ES1.1. Probably it won't work, as it was said that the issue would be fixed in ES2.0 +09:37 < wsa_> and the workaround patch (a25a29f3ccd7d4a0809cf6833c97c9748097b8ac) in the BSP is not suitable for upstream? +09:38 < shimoda> i heard both es1.0 and 1.1 have a bug on MSIOF +09:38 < geertu> I have no idea what that patch is really intended to do, but it didn;t fix the issue for me +09:38 < wsa_> ok :) +09:41 < wsa_> can you update that info in Simon's list? +09:42 < wsa_> about this task: +09:42 < wsa_> MSIOF,v4.10,public,ulrich,Develop MSIOF test case using MMC-over-SPI for Gen2 +09:42 < wsa_> It is still marked as public because of the CS GPIO issue +09:42 < wsa_> I think it makes sense to mark this done and make the CS GPIO issue a seperate task +09:42 < wsa_> ? +09:43 < uli___> i think it would +09:43 < geertu> FYI, a similar issue has been fixed last week for atmel_spi +09:44 < uli___> thanks for forwarding that to me, btw +09:45 < wsa_> can I have a link to that? +09:47 < geertu> [PATCH v2] spi: atmel: use managed resource for gpio chip select +09:47 < wsa_> ok, so I'll change the todo accordingly, seems really a seperate issue +09:47 < wsa_> thanks +09:47 < geertu> Bad lkml.org +09:47 < geertu> commit 9610620078a3900e7fad82de620ce809fd29ba60 +09:48 < geertu> in spi/for-next +09:48 < wsa_> thanks +09:49 < wsa_> can we benefit from that commit? +09:49 < geertu> I think it can be used as an example +09:50 < wsa_> ok, thanks +09:51 < wsa_> next topic would be thermal driver +09:51 < wsa_> but khiem is not here +09:52 < geertu> May I ask about i2c demux? +09:52 < wsa_> sure +09:53 < geertu> Doesn't DVFS use a lower voltage on the i2c bus? +09:53 < geertu> IIRC it has special 1.8v i2c masters +09:53 < geertu> How to multiplex that with iic/i2c on Lager? +09:54 < wsa_> does it? need to check that +09:54 < wsa_> thanks for this input +09:55 < wsa_> will check for sure :) +09:56 < wsa_> so, most fun topic probably: +09:56 < wsa_> meeting at FOSDEM? :) +09:56 < wsa_> I'll be there +09:56 < wsa_> who else? +09:57 < geertu> I will +09:57 < horms> I don't think I _need_ to be there. But I think I can be there if we have a meet-up. +09:57 <@morimoto> Maybe I and magnus will +09:57 < uli___> can't say for sure yet +09:58 < shimoda> maybe I will not be there. if i go, i should update my passport :) +09:58 < wsa_> geertu: how are chances for a core group meeting currently? +09:59 < neg> If there is a meeting I will be there for both FOSDEM and meeting +09:59 < geertu> Haven't received much feedback about that yet. +09:59 < geertu> I know you (nocore) and Laurent (core) will be there +10:00 < wsa_> ok +10:00 < geertu> OK, and neg +10:00 < geertu> And Simon +10:00 < geertu> And Magnus and Morimoto-san +10:00 < geertu> Critical mass reached? +10:01 < wsa_> looks to me like we declare a critical mass if we say there will be a meeting +10:02 < geertu> Ah, chicken and egg +10:02 < wsa_> let's brainstorm further on the mailing list to keep all in the loop +10:02 < geertu> OK, for core we'll have a meeting +10:02 < geertu> :-) +10:02 < geertu> What are your feelings about I/O? +10:03 < geertu> (w.r.t. meeting) +10:03 < wsa_> heh +10:03 < wsa_> i think it would be nice to have one +10:04 < wsa_> maybe half a day IO, half a day core on Friday, and then head for the beer event? :) +10:04 < wsa_> ok, i am brainstorming already :D +10:05 < geertu> Sounds like a good idea +10:05 < wsa_> i'll post a mail +10:06 < wsa_> oh, i forgot one topic +10:06 < horms> fwiw, that plan sounds good to me +10:06 < wsa_> shimoda: there is request for additional error reporting on SDHI autcmd12? +10:06 < wsa_> did i get this right? +10:06 < shimoda> yes +10:08 < shimoda> the mmc/card/block.c has ECC error handling +10:08 < shimoda> just use single read mode instead of multiple read though :) +10:09 < shimoda> but the tmio driver seems that the response of multiple read/write is as autocmd12 things +10:10 -!- horms_ [~horms@217.111.208.18] has joined #periperi-io +10:10 < wsa_> so, I should add a new task about ECC handling for SDHI? +10:10 -!- horms [~horms@217.111.208.18] has quit Ping timeout: 256 seconds +10:10 -!- horms_ is now known as horms +10:11 < shimoda> i think not ecc handling but to be suitable response value should be returned when cmd18/25 with autocmd12 +10:12 < shimoda> so, +10:13 < shimoda> SDHI,?,?,?,fix response when cmd18/25 with autocmd12 +10:13 < shimoda> what do you think? +10:13 < wsa_> ok +10:13 < wsa_> will add +10:14 < shimoda> thanks! +10:14 < wsa_> ok, i have nore more topics except a adv7180 question for neg +10:15 < wsa_> so, if there is something more from your side, fire now :) +10:16 < wsa_> ok, then +10:16 < wsa_> thanks guys +10:17 < wsa_> have a great rest of the week +10:17 < neg> thanks all +10:17 <@morimoto> thanks +10:17 < geertu> byem thx +10:17 -!- morimoto [~user@relprex2.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +10:18 < shimoda> thanks, bye! +10:18 < horms> bye +10:18 < wsa_> neg: you have a minute +10:18 < wsa_> ? +10:18 < uli___> bye +10:18 < neg> sure +10:18 -!- uli___ [~uli___@static.206.203.46.78.clients.your-server.de] has left #periperi-io ["Leaving"] +10:19 < wsa_> i'd just like to know if you know if the adv7180 driver can be re-bound? +10:19 < wsa_> currently it oopses with i2c-demux +10:19 < wsa_> which basically does unbind/bind +10:19 < wsa_> do you know if that should be supported or if there are known issues with that? +10:20 < neg> I don't know if it can be rebound, I saw the oops and want to look in to it but other work got in the way :-( +10:21 < wsa_> ok +10:22 < wsa_> cc me on updates to that issue, please +10:22 < wsa_> and simon probably, too? +10:23 < wsa_> horms: ? +10:23 * horms is reading +10:23 < horms> yes, please keep me in the loop +10:24 < horms> wsa_: I suggest moving forwards with the patches that have no issues +10:24 < wsa_> i agree +10:25 < horms> excellent +10:26 < horms> what is the path forwards there? +10:26 < horms> rebase and repost? +10:26 < wsa_> i'll apply the i2c patch today for 4.9 +10:26 < horms> ok, that is a run-time dependency, right? +10:27 < wsa_> yes +10:27 < wsa_> it makes i2c-gpio work again +10:27 < horms> things blow-up with out it? +10:27 < wsa_> otherwise -ENODEV +10:27 < wsa_> no OOPS, just bailing out +10:28 < horms> hmm, ok. so by default things work +10:28 < horms> but if you try to switch i2c then it fails? +10:28 < wsa_> but I think you could just apply the patches with no issues for 4.10 +10:28 < horms> right v4.10 sounds good +10:28 < wsa_> yes +10:28 < horms> i'm just wondering if i can put them on top of v4.9-rc1 (which is best for me) +10:28 < horms> or if I need some other branch/rc +10:29 < horms> it sounds like I can go with v4.9-rc1 as there is no regression +10:29 < wsa_> yes +10:29 < horms> if so, can you rebase them on renesas-next? +10:29 < wsa_> they are rebased to renesas-drivers? +10:30 < horms> I'm unsure +10:30 < horms> that would probably also be ok +10:31 < wsa_> can you try and tell me if not ok? +10:31 < horms> well some rebasing is required in order to drop the patches we agreed on +10:31 < horms> but I can try doing that if you prefer +10:32 < wsa_> i see +10:33 < horms> how about i try +10:33 < horms> and get back to you if its a bit of a pain +10:33 < horms> will you be hanging around here this morning? +10:33 < wsa_> pfff +10:33 < horms> if not i can email you :) +10:33 < wsa_> until when can you apply the patches? +10:34 < horms> well, i can try doing so now +10:34 < wsa_> "pfff" was about the whole rebasing issue +10:34 < wsa_> no, i mean latest, because maybe neg will have adv7180 updates till then? +10:34 < wsa_> dropping the DVFS patch is super easy +10:34 < horms> ok +10:34 < wsa_> and maybe we can get the HDMI patches into 4.10 as well +10:35 < horms> wednesday next week +10:35 < horms> at the absoloute latest +10:35 < wsa_> would be my favourite since those i2c slave nodes tend to change anyhow +10:35 < wsa_> ouch +10:35 < horms> but I suggest queing up what we can now +10:35 < horms> to try to make things less painful next week +10:36 < horms> even if neg fixes adv7180 there will probably be some sort of depdendency +10:36 < wsa_> agreed +10:37 < neg> a qucik test on Koelsch shows the adv7180 should be able to handle a unbind/bind +10:37 < neg> echo 2-0020 > /sys/bus/i2c/drivers/adv7180/unbind +10:37 < neg> echo 2-0020 > /sys/bus/i2c/drivers/adv7180/bind +10:37 < neg> but the VIN driver have issues after that cycel :-( +10:38 < wsa_> did you use shmobile_defconfig? +10:40 < neg> yes with the following additions CONFIG_CGROUPS=y, CONFIG_CMA=y, CONFIG_SECCOMP=y, CONFIG_DMA_CMA=y, ONFIG_CMA_SIZE_MBYTES=64, CONFIG_VIDEO_ADV7604=y +10:40 < neg> CGROUPS and SECCOMP needed since I use systemd init, CMA needed to use VIN with large frame sizes, and ADV7604 needed for HDMI input +10:44 < wsa_> ok +10:45 < wsa_> need to logout here now +10:45 < wsa_> horms: i am available via mail +10:45 < horms> wsa_: ok. i will proceed with quing up some patches and let you know how it goes +10:47 < wsa_> thanks +10:47 < wsa_> cya guys! +--- Log closed Thu Nov 10 10:47:46 2016 -- cgit v1.2.3