/srv/irclogs.linaro.org/2018/01/24/#linaro-meeting.txt

arndhi broonie chunyan09:01
arndit seems everyone else isn't here today09:01
arnd#startmeeting09:02
linarobotMeeting started Wed Jan 24 09:02:52 2018 UTC.  The chair is arnd. Information about MeetBot at http://wiki.debian.org/MeetBot.09:02
linarobotUseful Commands: #action #agreed #help #info #idea #link #topic.09:02
chunyanarnd: Hi, baolin told me just now that he couldn't access to IRC09:02
arndmaybe the others have the same problem09:03
broonieHi09:03
arndlinusw is probably just late, as often09:04
broonieYou need to be registered with nickserv now.09:04
chunyanbroonie: yeah, I also guess so, and told baolin already.09:05
arndchunyan: if Baolin has another problem, he could try using irccloud.com instead of his normal client program (no idea what he uses, but I see his last ip address was not irccloud)09:08
arndxiongfeng also has problems joining this channel, I pointed him to https://freenode.net/kb/answer/registration09:11
chunyanarnd: Ok, sent the link to him just now.09:11
arndI'd say we should just start then, and I'll send a log to the others once they have  managed to join the channel09:12
arndThe last two weeks have been fairly quiet for me, as the merge window got delayed to get some better testing on the security fixes09:13
arndWe still have bugfixes coming in for arm-soc, but not much to do there.09:13
arndI've managed to go through my backlog of old patches (stuff I submitted in 2017 but that did not get merged) and either resubmitted or dropped almost all of it.09:14
arndlooking in to y2038 patches again now, trying to eliminate a couple of the API calls from include/linux/time32.h by changing over the callers to use time64_t09:14
arndthen there was another round of review for the nds32 architecture, which I recommended to go into linux-next after the merge window, the main remaining problem now being its ptrace interface09:16
arndthat's all for me. chunyan, what about you?09:17
arndthe others are now in #linaro-unregistered, and trying to register09:20
chunyanarnd: Ok09:22
chunyanThe patches for supporting regulator suspend were already qualified to be merged, I need to rebase them againt bronnie's topic/suspend and resend them later.09:22
chunyanAlso I spent a lot of time on porting the new clk driver for another Spreadtrum's SoC, this nearly went to the end.09:22
chunyanAlso spent a little time on 96Boards related stuff, and had a few discussion with my colleagues on CoreSight CPU debug module.09:23
baolinarnd: Sorry I am late, finally I joined.09:24
chunyanarnd: That's almost all from me.09:24
arndok, thanks chunyan.09:25
linuswhey it works09:25
arndhttps://www.irccloud.com/pastebin/vYAXyTNp/09:25
* linusw managed to remember his NickServ password09:25
brooniechunyan: Are you still discussing with ulf on the MMC stuff.09:25
arndhi baolin linusw xiongfeng, glad you finally all made it. see above link for the log so far09:25
chunyanbroonie: Not really, recently, I haven't had time to start to look into mmc core driver.09:26
brooniechunyan: OK.09:26
arndbaolin: can you go on with your status then?09:26
baolinarnd: Sure.09:26
baolinI spend most time on developing the persistent clock framework.09:27
baolinGot some comments from John and I send out RFC v3 patch set with addressing his comments.09:28
baolinIn this patchset I also removed the read_persistent_clock64() in arch/arm/kernel/time.c, which is only for ARM arch.09:29
baolinSo in future, we can compensate the suspend time from persistent clock framework and RTC device.09:30
baolinI am waiting for some suggestion before sending them out.09:30
arndbaolin: cleaning up the architecture code that way is really nice, but I'm still not convinced we need a new set of registration functions rather than extending clocksource_register09:30
arndbaolin: on a related note, my y2038 cleanup also brought me to read_persistent_clock() and update_persistent_clock(), which are still used by a couple of architectures09:32
arndI have patches to just remove it from frv and m32r, since those always return constant values09:32
baolinBut the framework can save lots of code and make the OS time compensating a little easier, since we removed NONSTOP_CLOCKSOURCE.09:32
* linusw wasn't even aware that this was an ARM-only thing ...09:33
arndread_persistent_clock{,64} is not architecture specific, but the way that the handlers get registered is09:33
baolinarnd: Yes I noted that functions,  and I will try to remove them too.09:33
arndsh, mips, m68k, arm32 and powerpc each have their own way of doing it09:33
linuswAha what a mess.09:34
arndfor sh, powerpc and mips, I think we can just remove them and instead 'select RTC_CLASS'09:34
baolinarnd: Yes.09:34
arndmaybe m68k, too, I'm still trying to understand that one09:35
baolinarnd: I did not look all ARCHs' implementation, but I think most of them can be changed to RTC or persistent clock framework.09:35
arndat least s390 and x86 cannot, I suspect the same is try for some of the others09:36
arndthese get the current time from a hypervisor interface rather than an RTC09:36
baolinarnd: OK, I will have a look.09:37
arndwe could in theory write RTC drivers for those hypervisors, but that would be as much of a hack as the current read_persistent_clock API09:37
arndthough now I wonder how kvm does it on arm32 and arm6409:37
baolinarnd: OK.09:38
arndbaolin: I'll send you the patches I have, cc:y2038@lists.linaro.org, then we can discuss it further on the list09:38
baolinarnd: OK, great.09:39
baolinThat's all from my side. Hope I can get some suggestion from you or John or other people :)09:39
arndbaolin: the main change I'd like to see from your persistent clock series is an API change to use the regular 'struct clocksource' with the CLOCK_SOURCE_SUSPEND_NONSTOP flag. I think we just need to figure what the correct behavior should be in all cases09:41
arndthanks baolin.09:41
arndxiongfeng: do you want to continue then?09:42
* xiongfeng ok, I sent several another cleanup patches and get some reply. 09:42
xiongfengMark and I discussed another work,  dm-crypt.09:42
baolinarnd: Got it, I will think about your suggestion.09:43
xiongfengI think I will move to that work.  And when I was waiting for the maintainer,  I will carry on with the cleanup work.09:43
arndok, sounds good09:43
xiongfengI know nothing about dm-crypt.  I think I need several weeks to read the code and get familiar with the mechinism.09:45
xiongfengthat's all for me.09:45
arndxiongfeng: ok, feel free to ask on IRC if you think we can provide some background. I only have some limited insight into dm-crypt itself, but have reviewed some of the earlier patches09:46
arndthanks xiongfeng. linusw, you're the last one for today tehn09:46
xiongfengarnd: ok, thanks.09:46
linuswOK09:50
linuswSorry for lag here...09:50
linuswI am working on an SDHCI fix for the remaining fallout of MQ conversion of MMC.09:51
linuswIt is iterated to v7 but I hope (as always) that this will be the silver bullet.09:51
linuswDebugging it was hard because the problems were in the DMA API and my only test system was x86 which is DMA coherent and a bit whatevs about the DMA API calls.09:52
linuswThen I made some advancements on the ARM Pl110/PL111 DRI/KMS conversion.09:52
linuswI will be able to switch all of Realview to DRM in the next cycle hopefully.09:53
linuswNow fixing up Versatile and Integrator, and thinking Vexpress will be smooth as well.09:53
linuswThen there is a slew of GPIO and pin control work and discussions.09:54
arndah nice!09:54
arndlinusw: any idea what we can do about that gpio event interface?09:54
linuswarnd: I haven't had time to catch up with the discussion yet.09:54
arndI think the best two options are either to make compat mode work for x86-32 by adding workarounds, or to create a new ioctl for getting that file descriptor, with a corrected structure09:55
linuswHm I see. I would prefer to get compat to work in that case.09:56
linuswBut I will have to look at the details.09:57
arndok09:57
arndone more thing for everyone:09:57
arndbaolin, chunyan, xiongfeng: have you arranged travel plans for HKG18, or are you still waiting for final approval?09:58
chunyanarnd: waiting for the final approval09:58
xiongfengYes, I will go to the HKG18.09:58
linuswarnd, broonie: do you know why linux-next is not coming out? It is becoming an issue for me. And I bet increasing the risk of an -rc10 as well.09:59
broonielinusw: No, I hadn't noticed it otherwise I'd have been trying to cover...09:59
arndi've been wondered about it too09:59
arndI got an email from sfr about a patch missing a signoff in arm-soc, so I assume he's on it though09:59
broonieAh, it's LCA.09:59
arndah, of course10:00
broonieHe did say on Friday but I don't read his daily announce mails and he said he might try some days.10:00
linuswAha OK10:01
linuswNot the greatest timing I guess.10:02
arndxiongfeng: ok, excellent. Let's hope it goes well for chunyan and baolin too.10:02
arndLet's close the meeting for today, and talk again in two weeks. Thanks everyone for joining10:03
arnd#endmeeting10:03
linarobotMeeting ended Wed Jan 24 10:03:33 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)10:03
linarobotMinutes:        https://irclogs.linaro.org/meeting-logs/linaro-meeting/2018/linaro-meeting.2018-01-24-09.02.html10:03
linarobotMinutes (text): https://irclogs.linaro.org/meeting-logs/linaro-meeting/2018/linaro-meeting.2018-01-24-09.02.txt10:03
linarobotLog:            https://irclogs.linaro.org/meeting-logs/linaro-meeting/2018/linaro-meeting.2018-01-24-09.02.log.html10:03

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!