summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20201217-io-chatlog
blob: 30743353431cd8afda129dc28836e7c07534581a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
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!