path: root/wiki/Chat_log/20170307-io-chatlog

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