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

1 files changed, 194 insertions, 0 deletions

diff --git a/wiki/Chat_log/20170307-io-chatlog b/wiki/Chat_log/20170307-io-chatlog
new file mode 100644
index 0000000..59d1389
--- /dev/null
+++ b/wiki/Chat_log/20170307-io-chatlog
@@ -0,0 +1,194 @@
+--- Log opened Tue Mar 07 08:57:01 2017
+08:57 -!- wsa_ [~wsa@p54B33CD0.dip0.t-ipconnect.de] has joined #periperi-io
+08:57 -!- Irssi: #periperi-io: Total of 4 nicks [1 ops, 0 halfops, 0 voices, 3 normal]
+08:57 < wsa_> hiya
+08:57 -!- Irssi: Join to #periperi-io was synced in 10 secs
+08:58 -!- jmondi [~USR123@250.ip-164-132-57.eu] has joined #periperi-io
+08:58 -!- horms [~horms@penelope.horms.nl] has joined #periperi-io
+08:58 < geertu> Hi
+08:59 < jmondi> Hello!
+09:02 < wsa_> so, let's start...
+09:02 -!- Irssi: #periperi-io: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal]
+09:02 < wsa_> glad you guys could make it
+09:02 < wsa_> simon, I hope it was not a big problem for you
+09:03 <@morimoto> Hi
+09:03 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi-io
+09:03 < wsa_> i have a time limit and need to leave in around 75 minutes
+09:04 < wsa_> I hope we will be done then by far, though
+09:04 < wsa_> i have a few topics but would like to ask you guys first if there is something on your mind?
+09:04 < neg> :-)
+09:06 < neg> bad time to post in wrong window, I have nothing on my mind
+09:06 < wsa_> doesn't look like it for now...
+09:07 < wsa_> neg: I hope it wasn't the window where your gf asked you what to do this evening ;)
+09:07 < neg> if only
+09:08 < wsa_> so, are there any news from Ulrich?
+09:08 < wsa_> has he been to core meetings?
+09:08 < geertu> wsa_: Haven't heard from him for quite a while
+09:08 < wsa_> seems I have to ask privately for status updates again
+09:09 < wsa_> dammsan: did you have contact with him recently?
+09:09 < geertu> Last mailing list post was Feb 8
+09:09 < horms> I was not present at the most recent core meeting and I have been mostly offline for several weeks. However, I do not recall seeing any patches from him for some time.
+09:09 < dammsan> we managed to finalise his additional tasks yesterday
+09:09 < dammsan> i saw that he responded to jinzai then
+09:09 < horms> at least we know he is alive :)
+09:10 < dammsan> yeah
+09:10 < dammsan> that's good
+09:10 < wsa_> add. tasks for Q2 already?
+09:10 < dammsan> nope, this was this quarter 3/M due date
+09:11 < dammsan> from now on i will submit group leader tasks as final step for each batch =)
+09:12 < wsa_> okay, so I will try to get status updates from him personally and ask him to do this on periperi in the future again
+09:12 < dammsan> regarding next quarter additional tasks
+09:12 < wsa_> yes, this was one topic for today
+09:13 < dammsan> i would like to ask all of you to ponder about proposals and discuss with wolfram how to improve various I/O device drivers
+09:14 < neg> 1. PM suspend/resume test suite :-)
+09:14  * morimoto do Renesas work now
+09:14 < neg> 2. WoL for Gen3
+09:15 < wsa_> PM is a bigger topic for most drivers, but the base is not considered stable yet
+09:15 < wsa_> or?
+09:16 < dammsan> good question
+09:17 < dammsan> if we are able to support wakeups from devices somehow, then i think it might be stable enough
+09:17 < geertu> Which base is not stable?
+09:17 < wsa_> geertu: suspend/resume?
+09:18 < geertu> echo s2idle > /sys/power/mem_sleep
+09:18 < geertu> and after that you can play at will
+09:19 < neg> Never the less, having a group effort for a single repo with a test tool/scripts to test PM the issues could be found and documentet per dirver also work could start on Gen2
+09:20 < geertu> And without the above echo command, you can still test suspend/resume for all drivers, but only with SW23 wake-up
+09:20 < geertu> Please upgrade to firmware 2.16
+09:20 < geertu> Gen2 doesn't power down the SoC, so drivers still work if they fail to restore registers
+09:21 < dammsan> geertu: i think the e2x board (not upstream unfortunately) supports SoC power down on Gen2
+09:21 < dammsan> so it is a board property
+09:22 < wsa_> ok, so with fw 2.16 we can now try out PM in drivers? that would be good news...
+09:22 < geertu> dammsan: OK OK, if we don't know about boards, they don't exist ;-)
+09:22 < dammsan> =)
+09:22 < geertu> wsa_: Even with older firmware, but then you need M3-W
+09:23 < geertu> as the older firmware supports suspend/resume on H3 ES1.1+ only
+09:23 < wsa_> yeah, still I wanted to try with H3 and M3-W here
+09:24 < wsa_> otherwise too much room for unexpected behaviour which I cannot reproduce
+09:25 < geertu> Then please upgrade to firmware 2.16 on both boards.
+09:25 < wsa_> will do
+09:25 < wsa_> that opens a path for quite some tasks, I assume
+09:25 < dammsan> geertu: we can have that as requirement in the additional tasks related to PM
+09:27 < wsa_> geertu: you mentioned that you want to pick up SPI slave again? Nice
+09:27 < geertu> wsa_: yes, I hope to find some time for that (talked to Matt Porter and Mark Brown @ FOSDEM)
+09:27 < wsa_> do you have room for an add. task covering that?
+09:28 < wsa_> or all busy with core?
+09:28 < geertu> wsa_: No space for extra add. task now
+09:28 < geertu> Or do you mean Q2?
+09:28 < wsa_> Q2
+09:28 < wsa_> Q2B1
+09:28 < geertu> IC
+09:29 < wsa_> or Q2B2 if that suits you better...
+09:30 < wsa_> horms: are you still interested in the SDHI DMA refactoring task in Q2B1?
+09:31 < wsa_> horms: and are you getting better?
+09:31 < wsa_> that should have been the first question :)
+09:31 < horms> perhaps: as I had to cancel my tasks for the current period I think they should get first dibs on my time in the next period
+09:31 < horms> horms: i am improving slowly but surely and expect to be back to full strength next Q
+09:32 < horms> As of this week I am well enough to be back at work :)
+09:32 < horms> It is "just the flu" but my immune system seems very weak for some reason
+09:33 < horms> so it is taking a long time to recover
+09:33 < wsa_> I wonder if SDHI refactoring is bad for an immune system... ;)
+09:33 < horms> haha; maybe
+09:34 < wsa_> the only thing I noticed is a few more grey hairs, though...
+09:34 < wsa_> :D
+09:34 -!- horms [~horms@penelope.horms.nl] has left #periperi-io ["Leaving"]
+09:34 -!- horms [~horms@penelope.horms.nl] has joined #periperi-io
+09:34 < wsa_> okay, we need to keep an eye on that: SDHI DMA seems to be important for Q2
+09:35 < horms> ok, i would say its possible if there it is high priority
+09:36 < horms> i plan to make a start on my non-tasks for the current period sooner than later as I already know what the tasks are even if they are in a no-paperwork state at this time
+09:36 < horms> that should give me a bit more time to play with next Q
+09:36 < wsa_> cool
+09:37 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi-io
+09:37 < wsa_> geertu: this task
+09:37 < wsa_> SCIF,v4.10,public,geert,difference in behavior between hardware-assisted flow control and GPIO flow control
+09:37 < wsa_> is it fixed with
+09:38 < wsa_> e8de8e1c28560795 serial: sh-sci: Fix early deassertion of dedicated RTS
+09:38 < wsa_> ?
+09:38 < wsa_> hi shimoda-san
+09:39 < geertu> wsa_: Yes, but Laurent wanted me to fix the pin initialization at the same time, so the maintainer hasn't picked up that patch, and I need to implement his comment first :-(
+09:39 < wsa_> neg: did i get this right. Since Hans asked you to drop some patches of the VIN series, this effectively means that the IP core switcher series is postponed until some heavy restructuring in the V4L2 core?
+09:39 < wsa_> geertu: 
+09:39 < wsa_> geertu: i see
+09:40 < shimoda> hi wolfram-san!
+09:40 < wsa_> geertu: so, this is v4.12 now?
+09:40 < geertu> probably
+09:41 < wsa_> ok
+09:41 < dammsan> wsa_: will you have time for IP core switch development for I2C?
+09:41 < neg> wsa_: yes and no, the over all problem needs V4L2 work for the problem we have in VIN i have a new patch I hope he will accept and plan to post as part of my current multimedia additonal task
+09:41 < dammsan> wsa_: in the next quarter regarding additional tasks i mean
+09:42 < wsa_> dammsan: there is a dependency on parts of the VIN series, so unclear for now
+09:43 < dammsan> wsa_: ok thanks
+09:44 < wsa_> it wouldn't like to schedule an add. task which only causes regressions everywhere :)
+09:46 < wsa_> neg: please keep me CCed on the VIN patches that might be relevant for me
+09:46  * morimoto back from happy paper work
+09:46 < wsa_> morimoto: paperwork makes you happy?
+09:47 < neg> wsa_: will do
+09:48 -!- Irssi: #periperi-io: Total of 8 nicks [1 ops, 0 halfops, 0 voices, 7 normal]
+09:48 < wsa_> jmondi: are you all good?
+09:49 < jmondi> wsa_: yes I am
+09:50 < jmondi> I would like to discuss briefly about the max9611 driver progress
+09:50 < wsa_> sure
+09:51 < jmondi> well, basically Jonathan has reviewed the driver, some comments here and there, but we'll get there
+09:51 < jmondi> what I would like to have clarified is the usage model of the userspace interface
+09:52 < jmondi> because it makes a great difference knowing what would ideally be the polling frequency, to decide if driver should implement buffered reads or just chrdev interface is enough
+09:52 <@morimoto> wsa: I'm supper happy now :)
+09:53 < jmondi> that chip will be used to implement DVFS policies, right?
+09:56 < wsa_> what would be the effort to implement caching?
+09:56 < wsa_> i'd think let's wait with caching until we know we need it?
+09:57 < jmondi> ok, I know we don't have to reason for just one specific use case, but given the many functions of that chip, I feel like we should define a use case for that on Renesas platforms
+09:59 < jmondi> also, there are some constraints due to the HW design (eg. driver does not support some functions like op-amp and comparator, because they're not wired on Salvator-X design)
+10:00 < wsa_> i see
+10:00 < wsa_> is that documented somewhere?
+10:01 < wsa_> i think this is fairly standard linux driver evolution, but it is always helpful to document what is implemented and what not
+10:02 < jmondi> yes, in the driver there are many comments about non-supported functionalities...
+10:02 < jmondi> but that's not big deal, last question about Jonathan was more about what polling frequency should the driver support
+10:03 < jmondi> that makes implementation quite different
+10:03 < jmondi> we can take that privately later, if I'm flooding the channel and the meeting with this, sorry
+10:03 < wsa_> geert may correct me, but as I see it we are currently missing the details like this?
+10:04 < wsa_> jmondi: all fine, this is one place to discuss such things
+10:04 < geertu> The MAX9611 is used to monitor power consumption on the DVFS and VDD0.8 rails
+10:04 < jmondi> ok then, I won't feel bad talking too much then
+10:04 < geertu> I don't know what's the typical timing granularity needed for that
+10:05 < wsa_> maybe jonathan has an idea?
+10:05 < jmondi> seems like he's undecided as well... The real issue here is auto-gain configuration
+10:05 < wsa_> is there a "most flexible" solution?
+10:06 < jmondi> eh, I wish I know what that would be... supporting most uses cases implies creating a quite sluggish interface in sysfs, where userspace is required to take care of auto-gain settings
+10:07 < jmondi> a sort of calibration process
+10:08 < jmondi> on the other side, we can present the "processed" values from a single attribute, performing auto-gain setting in kernel space, but that would not support buffered reads, and will make complex implementing it in future
+10:09 < jmondi> and that's where my question come from: Do we have any idea what would be a plausible sampling frequency on that device (if we do have defined use-cases for that chip specific to our platforms)
+10:09 < wsa_> i see
+10:10 < geertu> jmondi: You could ask BayLibre (Neil Armstrong) what sampling frequency they find useful for ACME with their tools
+10:10 < wsa_> things I can think of:
+10:10 < wsa_> a) ask on linux-pm if they have an idea what frequency is needed
+10:11 < wsa_> or BayLibre ;)
+10:11 < wsa_> and b) I don't think implementing complex userspace configuration without a clear use-case is benefitial
+10:11 < geertu> jmondi: I never use the GUI tools that draw graphs
+10:12 < geertu> w.r.t. b) yes, KISS
+10:12 < wsa_> exactly
+10:13 < jmondi> geertu: I didn't even know it existed. Mostly, I don't know what tools are out there that polls on a device like this, that's why I don't have idea about typical use cases
+10:13 < wsa_> which would lead to chosing the "simpler" method unless we can create the use case
+10:14 < wsa_> jmondi: does it help you a little?
+10:14 < jmondi> geertu: wsa_: Ok, I'll ask a bit around, if I'm not pointed to any monitoring tool with strict time requriements out there, I'll go for the simple solution
+10:15 < jmondi> wsa_: yes, thank. Sometimes is easy for me to get lost, and need some directions to find out where to ask informations or where to look at :)
+10:15 < wsa_> sounds good to me for now
+10:15 < geertu> jmondi: http://baylibre.com/acme/ shows some screenshots. One of them says "100 S/s"
+10:15 < wsa_> jmondi: this is true for all of us
+10:16 < wsa_> and where working in a team is really benefitial :)
+10:16 < jmondi> wsa_: it's a big world out there :)
+10:16 < jmondi> geertu: thanks
+10:16 < wsa_> please post your findings to renesas-soc or periperi, I think we are all interested in the outcome
+10:16 < geertu> wsa: And esp. with FLOSS, the team (and its knowledge) is big
+10:17 < wsa_> yes :D
+10:17 < wsa_> so, I'd like to close the meeting soon
+10:17 < wsa_> so, if there is anything unsaid left, now would be the time
+10:18 <@morimoto> OK, thanks boys & girls !!
+10:19 < shimoda> thanks! bye!
+10:19 < geertu> Thx, bye!
+10:19 < jmondi> thank you all, bye!
+10:20 < horms> bye
+10:20 < wsa_> Good then, have a great week all!
+10:20 < neg> thanks all
+10:21 < wsa_> neg: I'll try to review your thermal patches later today
+10:21 < wsa_> bye
+10:22 < neg> wsa_: thanks
+10:24 -!- shimoda [~shimoda@relprex2.renesas.com] has quit Quit: WeeChat 0.4.2
+--- Log closed Tue Mar 07 10:25:27 2017