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
|
09:01 < wsa> welcome everyone!
09:01 < wsa> here are the status updates:
09:01 < wsa> Status updates
09:01 < wsa> ==============
09:01 < wsa> A - what have I done since last time
09:01 < wsa> ------------------------------------
09:01 < wsa> Geert
09:01 < wsa> : sent RFC patch to fix ghost events in gpio-keys with both-edge irqs, cleaned up clock handling in the SCIF driver, tested GPIO sloppy logic analyzer
09:01 < wsa> Kieran
09:01 < wsa> : supported Ulrich with CAN V3U testing
09:01 < wsa> Marek
09:01 < wsa> : debugged PCI "can't change power state from D3hot to D0"
09:01 < wsa> Shimoda-san
09:01 < wsa> : debugged S4 PCIe
09:01 < wsa> Ulrich
09:01 < wsa> : tested and fixed CANFD on Falcon, prepared next version of CANFD for V3U
09:01 < wsa> Wolfram
09:01 < wsa> : investigated faulty SanDisk cards some more, started to guide I2C QoS support, converted I2C and IIC to the new DMAENGINE API, sent RFC to support non-strict GPIO mode for Gen3 PFC, reviewed I2C patches, sent out yet another version of the GPIO sloppy logic analyzer
09:01 < wsa> B - what I want to do until next time
09:01 < wsa> -------------------------------------
09:01 < wsa> Geert
09:01 < wsa> : wants to retest GPIO sloppy logic analyzer and non-strict GPIO mode for PFC
09:01 < wsa> Marek
09:01 < wsa> : wants to continue on the PCI D3hot to D0 problem
09:01 < wsa> Shimoda-san
09:01 < wsa> : wants to do further R-Car S4 support, especially ethernet switch and PCIe
09:01 < wsa> Ulrich
09:01 < wsa> : wants to find out if/why some CANFD channels don't work on the Falcon board, probably send v3 of CANFD for V3U
09:01 < wsa> Wolfram
09:01 < wsa> : wants to send out yet another version of the GPIO sloppy logic analyzer, find out the proper solution for faulty SanDisk cards with SDHI, continue guiding I2C QoS support, upport SDHI and/or TPU patches
09:01 < marex> wsa: gen2/3 pci :-(
09:02 < wsa> C - problems I currently have
09:02 < wsa> -----------------------------
09:02 < wsa> Marek
09:02 < wsa> : Gen2/3 PCIe is full of severe problems
09:02 < wsa> Wolfram
09:02 < wsa> : wants to move to another place and would like to take the January off to do the preparations for that. He would be around for guidance and emergencies, but wants to move regular development time to February / March.
09:03 < wsa> marex: so, the issue is affecting Gen3 as well?
09:03 < marex> wsa: most of them anyway
09:03 < marex> wsa: the ones which have A57
09:04 < wsa> shimoday: I hope I did not shorten your work too much in the summary. It was not entirely clear to me, if you are still chasing bugs or if you found out that everything is ok?
09:04 < marex> the ones which have A53, _probably_ not (to be verified)
09:04 < wsa> marex: okay, it's already bad enough :(
09:04 < wsa> shimoday: also, what is RC21212? Googling around didn't help me much
09:05 < wsa> marex: are we reaching a point where we should just mark it as broken?
09:05 < marex> wsa: it _probably_ has to do with speculation on those bigger cores, where the abort happens only once the read value has been used, not when the actual ldr instruction is called
09:05 < marex> wsa: we passed that point a long time ago, it's just that turning OFF L1 state support in linux pci core for a controller is non-trivial
09:06 < marex> (and pci maintainers provided no suggestions how to do it either)
09:06 < marex> wsa: I have a workaround for this one, I am just looking for a better "fix"
09:06 < wsa> marex: okay, good luck then
09:07 < marex> wsa: hum, thank you
09:07 < shimoday> wsa: RC21212 is a timing generator for PCIe and some devices
09:08 < shimoday> wsa: about the summary, it looks good to me :)
09:08 < marex> shimoday: some post-IDT design ? :)
09:08 < shimoday> marex: I guess so
09:09 < wsa> shimoday, moriperi, damm: any comment about my wish to take the January off?
09:09 < wsa> I'd think the S4 boards won't ship to Europe in January anyhow
09:10 < neg> wsa: Congratulations on the new flat
09:10 < wsa> and even if so, I'd think core stuff has to be done first, so I think it should match
09:10 < marex> shimoday: similar to renesas/idt 8SLVD1212NLGI maybe ?
09:10 < moriperi> wsa: I have no comment about it. please enjoy moving :)
09:10 < marex> maybe not
09:10 < damm> likewise
09:11 < wsa> neg: thanks :) lots of work, but I think it will be a lot better after that
09:11 < geertu> wsa: We'll be having merge window soon, so I think you did great by aligning appartment and kernel schedules ;-)
09:11 < wsa> moriperi: "enjoy", well.. I'd rather enjoy hacking than painting walls ;)
09:12 < shimoday> wsa: I think it's ok to me :)
09:12 < wsa> geertu: yeah, my move was the main reason for Linus doing an rc8 :D
09:12 * geertu likes painting walls (well, there are worse tasks ;-)
09:12 * wsa invites geertu over to paint walls
09:12 < moriperi> wsa: oh, it seems there is big diff between Euro style and Japan style :)
09:12 < wsa> moriperi: I think so :D
09:13 < wsa> geertu: that means, I won't have time to fixup the logic analyzer script because preparing for cgroups v2 is not a trivial step
09:13 < wsa> geertu: could you just rename the filenames manually for your tests meanwhile?
09:14 < wsa> thanks japaperi!
09:14 < geertu> wsa: Yeah, I'll handle fine. Just didn't get to it yet due to holidays.
09:14 < wsa> geertu: great
09:15 < wsa> so, another question for JapaPERI is CAN on V3U where some channels do not work, neither with Ulrich's upstream patches nor with the BSP
09:15 < wsa> shall Ulrich invest time to debug and we pass it to the BSP then?
09:15 < wsa> or shall the BSP team investigate and Ulrich shall upport their findings?
09:16 < wsa> I assume everyone in Japan is busy with S4 now, so maybe it is a good task for Ulrich?
09:16 < uli> i would prefer an opinion from the bsp team first; doing this remotely is poking around in the dark
09:16 < wsa> But it also might be hardware related and uli only has remote access
09:18 < wsa> because japaperi doesn't highlight in chat programs, I'll ask shimoday directly ;)
09:18 < shimoday> wsa: thanks about the highlight :)
09:20 < shimoday> BSP team is working for S4 and V4H. So, V3U is super low prio for now.
09:21 < wsa> uli: maybe we could also upstream only the working channels for V3U/Falcon but still all driver changes?
09:21 < uli> i'd be fine with that
09:21 < shimoday> if some channels cannot work, are we possible to submit usable channel for upstream?
09:22 < wsa> let's agree on that
09:22 < shimoday> wsa: yes :)
09:22 < uli> ok
09:23 < wsa> because the channels do not work with uli's driver and the BSP driver, it is somewhat unlikely that the driver is the problem
09:23 < wsa> and even if so, we can fix it incrementally
09:23 < geertu> uli: You double-checked pinctrl?
09:23 < wsa> but the driver still works on D3 and V3U channels 0-1.
09:23 < uli> geertu: yes, i have (iirc, because i thought that was the problem at first)
09:24 < wsa> any other questions from your side?
09:26 < shimoday> marex: RC21212 is named as "VersaClock".
09:26 < shimoday> so, i guess this is related to the product: https://www.renesas.com/eu/en/products/clocks-timing/versaclock-programmable-clocks
09:26 < wsa> seems the PCIe fun continues with S4 :/
09:27 < geertu> shimoday: And Linux already supports some vc5/vc6
09:27 < marex> shimoday: so post-IDT design, indeed :)
09:27 < shimoday> wsa: yes :)
09:27 < marex> geertu: yes, linux already supports versaclock
09:27 < shimoday> geertu: thanks! I'll check vc5/vc6 code
09:28 < shimoday> marex: I see :)
09:28 < shimoday> wsa: I don't have any question
09:28 < wsa> ok. then, I think we can switch to the core meeting
09:28 < wsa> thank you everyone for your participation
|
