09:04 < wsa_> ah, simon is excused
09:04 < wsa_> in which timezone is he now?
09:05 < wsa_> anyhow, let's start
09:05 < wsa_> welcome to this IO meeting
09:05 < wsa_> 1) status updates 2) topics
09:05 < geertu> wsa_: AFAIK, he's in California
09:05 < wsa_> Status updates
09:05 < wsa_> ==============
09:05 < wsa_> A - what have I done since last time
09:05 < wsa_> ------------------------------------
09:05 < wsa_> Kaneko-san
09:05 < wsa_> : got I2C SYS-DMAC enablement for E3 merged
09:05 < wsa_> Marek
09:05 < wsa_> : improved the PCA953x driver to handle suspend/resume for SATA properly,
09:05 < wsa_>   tested CAN on M3N using homemade CAN transceived, and bisected an upstream
09:05 < wsa_>   network breakage
09:05 < wsa_> Niklas
09:05 < wsa_> : resent HS400 patch series about reset operation, ES revision handling, and
09:05 < wsa_>   clock driver updates
09:05 < wsa_> Shimoda-san
09:05 < wsa_> : created patch and discussed proper upstream handling of some ethernet PHY
09:05 < wsa_>   behaviour, handled the Q-Tag VLAN frame issue requested by the BSP team,
09:05 < wsa_>   discussed SCIF flowchart issues, improved Gen3 USB2 phy handling, and
09:05 < wsa_>   prepared a elinux page about USB virtualization
09:05 < wsa_> Simon
09:05 < wsa_> : got E3 IIC patches merged, sent patch for no-link property on Ebisu, and
09:05 < wsa_>   provided feedback for the Q-Tag VLAN frame issue
09:05 < wsa_> Ulrich
09:05 < wsa_> : sent D3 CAN binding patches
09:05 < wsa_> Wolfram
09:05 < wsa_> : picked up I2C core PM work again, implemented patch and discussed about
09:05 < wsa_>   WDT timer value during suspend, sent new version of MMC RPMB core fix and
09:05 < wsa_>   improved some more smaller RPMB issues, answered GMSL questions from Jacopo,
09:05 < wsa_>   reviewed IIC enablement, Niklas latest HS400 patches, and orchestrated
09:05 < wsa_>   periupport some more
09:05 < wsa_> B - what I want to do until next time
09:05 < wsa_> -------------------------------------
09:05 < wsa_> Geert
09:05 < wsa_> : wants to resubmit fixes for fallback to PIO in the sh-sci driver
09:05 < wsa_> Kaneko-san
09:05 < wsa_> : wants to enable PWM pn E3
09:05 < wsa_> Niklas
09:05 < wsa_> : wants to keep tracking HS400 patches
09:05 < geertu> UTC-8?
09:06 < wsa_> Shimoda-san
09:06 < wsa_> : wants to continue to investigate USB2.0 host/peripheral resets behavior on
09:06 < wsa_>   mainline, submit the USB virtualization page for eLinux, and wants to
09:06 < wsa_>   investigate VFIO usage for Gen3
09:06 < wsa_> Simon
09:06 < wsa_> : wants to follow up on the Q-Tag VLAN frame issue
09:06 < wsa_> Ulrich
09:06 < wsa_> : wants to send D3 CAN DT patches and do more patch review
09:06 < wsa_> Wolfram
09:06 < wsa_> : wants to submit I2C core PM work, check upstream SDHI bug report about
09:06 < wsa_>   accessing large files, keep at watchdog and (older and revived) thermal
09:06 < wsa_>   discussions, work on known IIC issues, more GMSL discussion
09:06 < wsa_> C - problems I currently have
09:06 < wsa_> -----------------------------
09:06 < wsa_> Simon
09:06 < wsa_> : is waiting on various feedback about patches
09:07 < wsa_> so, my questions:
09:07 < wsa_> Marex: shimoda: are you in sync with upstreaming the PCIe ATF code?
09:08 < pinchartl> C - The pwm-rcar driver is broken with the PWM atomic API
09:08 < Marex> wsa_: I hope so, I need to rebase the PCI patch on top of upstream ATF, since they added all of the exception handling boilerplate and the patch doesn't apply anymore, but besides that, it should be doable
09:09 < wsa_> also, (not super much IO but upporting): who has a D3 board? According to the list, jmondi and Uli. Sound support needs to be upported...
09:09 < pinchartl> wsa_: I have Jacopo's D3 board, we exchanged the D3 and E3
09:10 < shimoda> wsa_: about D3, I also have a board
09:10 < pinchartl> I thought I had updated the wiki, does it still show the D3 as being with Jacopo ?
09:10 < wsa_> pinchartl: will add the PWM issue to C), thanks!
09:10 < geertu> General comment: please update https://osdr.renesas.com/projects/linux-kernel-development/wiki/Hardware
09:11 < wsa_> pinchartl: you have. that was a race condition :D
09:11 < jmondi> ups, forgot to update this ^
09:11 < jmondi> but somebody did already :)
09:12 < wsa_> so, if somebody is interested in that, there are some Jinso-patches for that on the list...
09:14 < wsa_> with simon not being here, that were all of my questions, I guess
09:14 < wsa_> are there some more from you, guys?
09:15 < pinchartl> if there's nothing else to discuss, I'd like to know if someone would like to address the PWM issue
09:15 < Marex> wsa_: speaking of D3/E3, I'm still curious about the HS400 performance on E3, it's lower than on M3N (with the same controller and same eMMC), both on BSP and mainline U-Boot
09:15 < geertu> Shimoda-san enquired about using VFIO.
09:15 < wsa_> shimoda: pinchartl: I assume you are linked now concerning the PWM issue?
09:15 < Marex> wsa_: I wonder if that's a QoS thing (if I fiddle with the QoS settings in ATF, it does affect that a bit) or something else
09:16 < neg> a cross IO/core question, do you think it's possible for us to aim to enable HS400 for 4.21 or are we a tad to late?
09:16 < pinchartl> shimoda: do you have time to work on pwm-rcar, or should I try to fix the problem ?
09:16 < wsa_> neg: I would very much hope so
09:17 < shimoda> pinchartl: i have time to work on pwm-rcar
09:17 < wsa_> neg: we could ask geertu if he is happy with the clock patches :)
09:17 < wsa_> neg: from the reviews, only minor stuff needs to be changed
09:18 < geertu> I plan to apply the clock patches, with the two nits fixed.
09:18 < shimoda> pinchartl: so I'd like to know how to reproduce the issue.
09:18 < geertu> And send a PR tomorrow.
09:18 < pinchartl> shimoda: great :-) I noticed the issue with backlight on E3, but I think it can be reproduced on any board. the problem comes from using the PWM atomic API. as the pwm-rcar driver doesn't suport it natively, the PWM core translates the calls to the legacy PWM API (set config, enable). the sequence of calls doesn't work well
09:18 < wsa_> geertu: one nit was not in the commit message but only in the changelog
09:19 < neg> wsa_: Yes even so I noticed Simon closed the renesas tree yesterday for 4.21 but maybe he can take it anyhow. Will ask him once he is awake
09:19 < geertu> wsa_: Which one?
09:19 < wsa_> s/rete/rate/
09:19 < pinchartl> rcar_pwm_config() returns immediately because pwm->state.duty_cycle = 0
09:20 < pinchartl> and then rcar_pwm_enable() will return an error because RCAR_PWMCNT_CYC0 == 0 and RCAR_PWMCNT_PH0 == 0
09:20 < wsa_> neg: can you resend the other patch ASAP?
09:20  * geertu has a PWM déjà vue
09:20 < geertu> s/vue/vu/
09:21 < pinchartl> so I think we need rcar_pwm_config() first compute the config parameters and store them, and then return if the PWM is not enabled, or program the hardware if it is
09:21 < wsa_> then let's hope simon will make an exception for the final HS400 DTS enablement patch
09:21 < pinchartl> then rcar_pwm_enable() should always proceed with the stored config
09:21 < pinchartl> and program the hardware if it's not programmed yet
09:21 < shimoda> pinchartl: I didn't know about the PWM atomic API. I'll check that. as you said, the driver prevents to enable it with CYC0 == 0 and PH0 == 0.
09:21 < geertu> Simon is still applying patches.
09:22 < neg> wsa_: I talked to geertu about the patches yesterday and he has generously agreed to fix the nit commetns when applying them. My question was more about if it was to late for the HS400 DT patch
09:22 < wsa_> neg: I don't think so :)
09:22 < neg> good :-)
09:23 < pinchartl> shimoda: it's a chicken and egg problem. rcar_pwm_config() doesn't program RCAR_PWMCNT because the channel is disabled, and then rcar_pwm_enable() errors out because RCAR_PWMCNT isn't programmed :-)
09:24 < geertu> Is this a recent PWM issue?
09:24 < pinchartl> one option to test this is to use my git://linuxtv.org/pinchartl/media.git drm/du/d3e3 branch
09:25 < pinchartl> make sure to compile the pwm-backlight driver
09:25 < pinchartl> then you can control the backlight from sysfs
09:25 < pinchartl> in /sys/class/backlight
09:25 < pinchartl> pwm-backlight now uses the PWM atomic API
09:25 < pinchartl> geertu: I don't think it's new, what has changed is the way client drivers use the PWM API
09:26 < pinchartl> the call sequence was always valid
09:26 < pinchartl> but never tested
09:26 < wsa_> eeeks, my thunderbird crashes badly...(?) so I can't look now... is there somebody at the ethernet breakage that Marex bisected?
09:26 < shimoda> pinchartl: :) so, i added a trickly code at line 157 of pwm-rcar.c. But, I think I should support .apply ops instead of legacy ops
09:27 < pinchartl> that would of course be a good option too :-)
09:27 < geertu> wsa_: It's hch's DMA cleanup
09:27 < geertu> Marex pointed to https://patchwork.kernel.org/patch/10668093/
09:27 < wsa_> geertu: i see. thanks
09:28 < geertu> Aboiut Shimoda-san's VFIO question
09:28 < geertu> The answer is "yes, you can".  SATA is the most mature example.  You still need to apply out-of-tree kernel and qemu patches, cfr. https://elinux.org/R-Car/Virtualization/VFIO
09:28 < pinchartl> shimoda: the apply operation should be easier to implement for the driver, and should fix the probleem
09:29 < pinchartl> that's all on my side for pwm-rcar
09:29 < Marex> wsa_: the link also contains a patch , which fixes the breakage
09:29 < wsa_> cool
09:29 < pinchartl> on a different, common topic, I would like to talk about peripericon @FOSDEM2019. we can do that now or later as part of core or multimedia
09:30 < shimoda> pinchartl: thank you for the detailed information! I'll try to implement the apply operation.
09:30 < wsa_> Yeah, I'd like to talk about that if there are no more IO related questions?
09:30 < Marex> wsa_: speaking of D3/E3, I'm still curious about the HS400 performance on E3, it's lower than on M3N (with the same controller and same eMMC), both on BSP and mainline U-Boot
09:30 < Marex> wsa_: I wonder if that's a QoS thing (if I fiddle with the QoS settings in ATF, it does affect that a bit) or something else
09:30 < wsa_> shimoda: cool, thanks for taking care of that.
09:31 < shimoda> geertu: thank you aboit VFIO. I didn't check the eLinux page. I'll check it after I made a patch for pwm-rcar :)
09:31 < wsa_> Marex: did you try using the BSP also?
09:31 < geertu> shimoda: You're welcome. If you have issues, please ping me!
09:32 < Marex> wsa_: yes, that's why I wrote it happens both on BSP and mainline U-Boot
09:32 < Marex> wsa_: BSP Linux that is
09:32 < shimoda> geertu: sure!
09:33 < wsa_> Marex: ah linux, too, okay
09:34 < wsa_> Marex: If it happens the same on BSP and upstream, this is usually the point where I would ask BSP team or HW team...
09:34 < Marex> wsa_: I brought it up in the periperi list, but that discussion died out
09:34 < Marex> wsa_: I'll restart it
09:35 < wsa_> Marex: please do
09:36 < wsa_> okay
09:36 < wsa_> FOSDEM talk?
09:37 < wsa_> geertu: are you okay with that?
09:37 < geertu> Sure