Merge remote-tracking branch 'gitlab/wiki' into HEAD

1 files changed, 244 insertions, 0 deletions

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