diff options
| -rw-r--r-- | wiki/Chat_log/20201217-io-chatlog | 113 |
1 files changed, 113 insertions, 0 deletions
diff --git a/wiki/Chat_log/20201217-io-chatlog b/wiki/Chat_log/20201217-io-chatlog new file mode 100644 index 0000000..3074335 --- /dev/null +++ b/wiki/Chat_log/20201217-io-chatlog @@ -0,0 +1,113 @@ +09:02 < wsa> So, let's start the meeting +09:02 < wsa> welcome :) +09:02 < wsa> here are the status updates +09:03 < wsa> Status updates +09:03 < wsa> ============== +09:03 < wsa> A - what have I done since last time +09:03 < wsa> ------------------------------------ +09:03 < wsa> Geert +09:03 < wsa> : retested MSIOF on Falcon with R-Car V3U pinctrl enabled +09:03 < wsa> Marek +09:03 < wsa> : dealt with feedback from PCIe maintainers on L1 link state fix for Gen2 and 32bit PCIe MSI fix +09:03 < wsa> Niklas +09:03 < wsa> : sent patches to fix locking problems with timers, added CMT and TMU binding descriptions and DTS updates for all Gen3 SoC which were missing it, added thermal support for V3U +09:03 < wsa> Shimoda-san +09:03 < wsa> : attended OSSJ and ALS2020, added pages about eMMC to eLinux, investigated SDHI driver issues with Wolfram (max_busy_timeout, low performance than v4.14 BSP, data timeout, incorrect clock setting on M3 v1.x + HS200, hang when CMD0), sent out patches for SDHI pre_req and post_req +09:03 < wsa> Ulrich +09:03 < wsa> : worked on atomic transfers for R-Car I2C +09:03 < wsa> Wolfram +09:03 < wsa> : worked on isolated CPUs as logic analyzers (kernel + userspace), sent out minor GPIO cleanup patches found on the way, worked with Shimoda-san on SDHI max_busy_timeouts, data timeout handling, and pre/post-req support +09:03 < wsa> B - what I want to do until next time +09:03 < wsa> ------------------------------------- +09:03 < wsa> Geert +09:03 < wsa> : wants to advertise MSIOF min/max speed limits to SPI core, and use MSIOF as a testbed for R-Car V3U SYS-DMAC +09:03 < wsa> Marek +09:03 < wsa> : wants to continue dealing with the PCIe maintainers +09:03 < wsa> Niklas +09:03 < wsa> : wants to figure out numbering of TSC nodes on V3U, wants to take a well-deserved vacation +09:03 < wsa> Shimoda-san +09:03 < wsa> : wants to take a well-deserved vacation, collect more information about R-Car Gen3e, continue to investigate SDHI driver issues, continue to develop R-Car S4 Ethernet driver +09:03 < wsa> Ulrich +09:03 < wsa> : wants to finish atomic transfers for R-Car I2C +09:03 < wsa> Wolfram +09:03 < wsa> : wants to enable and test V3U IO devices, improve logic analyzer, try to enable WAIT_WHILE_BUSY for SDHI, resend WDT patch to fix scheduling while atomic +09:03 < wsa> C - problems I currently have +09:03 < wsa> ----------------------------- +09:03 < wsa> Shimoda-san +09:03 < wsa> : could not retrieve further Gen3e information for now +09:03 < wsa> Wolfram +09:03 < wsa> : is not happy with the performance of the logic analyzer yet (1 channel at 100kHz) +09:04 < wsa> shimoday: I am happy we fixed the CMD0 problem, but which one was that and which patch did fix it? :D +09:04 < wsa> Other than that, we also have the WAIT_WHILE_BUSY topic which is a optimization, though, not a bugfix +09:05 < neg> morning all, sorry I'm a few min late +09:05 < wsa> shimoday, moriperi: was there noteworthy stuff happening at OSSJ? +09:05 < wsa> hi neg! +09:05 < wsa> neg: you had fun with the timers? +09:06 < wsa> neg: about the thermal V3U counting problem: can't you describe it in YAML similar to the interrupt difference? +09:06 < shimoday> wsa: remove hw_reset caused this issue and call ->reset could be fixed, i think :) +09:07 < wsa> shimoday: ah, this one +09:08 < shimoday> wsa: yes about WAIT_WHILE_BUSY +09:08 < neg> I think V3U and YAML is solvable, I think the fault is between datasheet and keyboard ;-) +09:08 < shimoday> wsa: about OSSJ, I didn't think big news happen at OSSJ. +09:08 < wsa> geertu: what is the conclusion of MSIOF and V3U: 300kHz is the max speed due to HW design? +09:08 < shimoday> moriperi: what do you think? +09:09 < geertu> wsa: I don't think it's hardware design. Looks like a property of the external loopback +09:09 < geertu> E.g. long jumper wires. +09:10 < geertu> When looking at the received data at higher speeds, signal transitions may be slightly offset, or missing. +09:11 < wsa> marex: could you give a short summary of the PCIe discussions? The detail level is quite high... +09:11 < geertu> wsa: BTW, you mae sure GPIO chatter prevention is turned of for your logic analyzer? +09:12 < geertu> s/mae/made/, s/of/off/ +09:12 < wsa> neg: timers are done or is there still something to be done +09:12 < marex> wsa: well, after 2 or so months, pcie maintainers woke up and started reviewing the bugfixes +09:13 < neg> wsa: I still need to enable and test timers on V3U +09:13 < wsa> geertu: I had a glimpse and saw no support for chatter prevention in the driver. And the default was 'off', so I didn't investigate further +09:13 < geertu> wsa: You better verify it's really off when the boot loader hands off the system to Linux (cfr. the APE6-EVM CMT1 issue) +09:13 < wsa> geertu: IIRC chatter prevention was only for a few pins anyhow and the ones I used were not affected +09:13 < marex> wsa: the 32bit MSI bugfix is being commented on mostly by Lorenzo, where Lorenzo is trying to change the logic and remove the allocation of page altogether +09:14 < marex> wsa: so far, the argument there was something about LPAE, but when I asked further, the argument was apparently incorrect +09:14 < wsa> geertu: ok, thanks, will do +09:14 < marex> wsa: so now it seems the original patch is gonna work both on LPAE and non-LPAE system all the same, but Lorenzo is still trying to push against the simple bugfix +09:15 < neg> wsa: And the key bugfix patch for deadlocks have had no traction upstream, so I need to repost it as separate patch with $scary subject in Jan once people are back ;-) +09:15 * wsa likes "$scary subject" +09:16 < wsa> marex: sounds like he has no technical reason? +09:16 < wsa> uli__: you saw the diff for the i2c-rcar testcase? +09:16 < marex> wsa: seems like a matter of taste right now +09:17 < uli__> wsa: yes, thanks. that's what i was looking for +09:17 < wsa> marex: I see. So, he asks for an alternative without suggesting one? +09:18 < marex> wsa: as for the L1 link state, there is feedback from Bjorn, he is pointing out some edge cases where this might fail, and Lorenzo is asking whether there might be concurency problem +09:18 < wsa> uli__: I tested it quickly and it gave me the OOPS you wanted ;) +09:18 < uli__> excellent, i guess :) +09:19 < wsa> shimoday: which pages did you add to eLinux, BTWE? +09:19 < wsa> BTW +09:19 < marex> wsa: the alternative Lorenzo is trying to push is "pick an address", but that would require more intrusive change, which I think isn't what we want for stable backport +09:19 < marex> wsa: could be done in a separate patch too +09:19 < shimoday> https://elinux.org/R-Car/Merging-MMC-block-requests +09:20 < shimoday> https://elinux.org/R-Car/Use-MMC-block-as-rootfs-on-v5-10 +09:20 < shimoday> wsa: these pages +09:20 < shimoday> about mmc block order +09:21 < shimoday> about second one, i saw Linus torvals and MMC maintainer talked this topic once +09:21 < shimoday> but, i didn't follow a conclusion +09:21 < wsa> marex: okay, i think with backporting to stable you have a good argument. let's hope he will accept that. I can definately second you on this one. +09:21 < wsa> marex: thanks for the summary! +09:21 < geertu> shimoday: BTW, there's been more discussion, and it looks like mmc aliases will be accepted by Ulf +09:21 < wsa> Linus is interested in MMC? +09:22 < marex> wsa: sure +09:22 < shimoday> let me find a lkml url +09:22 < geertu> https://lore.kernel.org/linux-arm-kernel/CAK8P3a2Habmz95y+J+-4NiT5SGYhO_Fia-SHhapX-3NYRbEMmw@mail.gmail.com/ +09:22 < wsa> ah, because of consistent numbering +09:22 -!- damm [~damm@l193216.ppp.asahi-net.or.jp] has joined #periperi +09:23 < wsa> hi Magnus! +09:23 < geertu> damm: You're late because you were measuring the very long length of the jumper wire? ;) +09:23 < wsa> geertu: I thought he was connecting the CAN interface to his car? +09:23 < wsa> shimoday: thanks for the links! +09:24 < shimoday> https://lkml.org/lkml/2020/11/27/739 +09:24 < marex> shimoday: do you know 'part uuid' u-boot command ? You can use that to determine partition UUID in U-Boot and then pass that to Linux as root=PARTUUID= argument +09:25 < wsa> so, any more questions from your side? +09:25 < shimoday> geertu: oh, i got it. i'll resend a patch later +09:26 < damm> hi guys sorry for being late =) +09:26 < shimoday> marex: i didn't know that. thanks! +09:27 < marex> shimoday: I hope it helps +09:27 < wsa> okay, looks like no more questions +09:27 < wsa> then we can switch to core? +09:27 < wsa> geertu: ready? +09:28 < wsa> thanks for your work, everyone! |