--- 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