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
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
09:03 < wsa> Welcome everyone to the IO meeting
09:03 < wsa> No surprises today, status updates, and topics
09:03 < wsa> Here are the status updates:
09:03 < wsa> A - what have I done since last time
09:03 < wsa> ------------------------------------
09:03 < wsa> Kaneko-san
09:03 < wsa> : added MSIOF to D3 PFC
09:03 < wsa> Marek
09:03 < wsa> : continued to deeply investigate the PCIE L1 link state handling
09:03 < wsa> Shimoda-san
09:03 < wsa> : sent add reset_control and multiple clocks support for USBHS, and made patches
09:03 < wsa> for USB2.0 (host and peripheral) support for R-Car E3/D3.
09:03 < wsa> Simon
09:03 < wsa> : sent out RAVB patches on not writing reserved bits and removing an alignment
09:03 < wsa> restriction for Gen3, and helped tracking down a RAVB PHY link regression
09:03 < wsa> Ulrich
09:03 < wsa> : revisited patches about SCIF RPM improvements
09:03 < wsa> Wolfram
09:03 < wsa> : sent prototypes to handle dangling pointers in the DMA subsystem, sent
09:03 < wsa> patches to set dma_parms for some R-Car DMA controllers, implemented core
09:03 < wsa> part of irqless I2C transfer prototype, update new bsp370 ticket file with
09:03 < wsa> comments from old ticket file and so far overlooked already upstream commits,
09:03 < wsa> and did reviews of SDHI patches
09:03 < wsa> B - what I want to do until next time
09:03 < wsa> -------------------------------------
09:03 < wsa> Kaneko-san
09:03 < wsa> : wants to enable SYS-DMAC support for E3 MSIOF
09:03 < wsa> Marek
09:03 < wsa> : wants to continue to investigate the PCIE L1 link state handling and revisit
09:03 < wsa> a new upstream patch series dealing with the 32-bit bus limitation
09:03 < wsa> Niklas
09:03 < wsa> : wants to work on the SDHI reset patch series and on the handling of '4TAP
09:03 < wsa> only' devices
09:03 < wsa> Shimoda-san
09:03 < wsa> : wants to update patches renesas_usbhs and phy-rcar-gen3-usb2 for R-Car E3/D3,
09:03 < wsa> continue to investigate the eMMC suspend issue, and continue with KVM on Gen3
09:03 < wsa> and document findings on the elinux wiki.
09:03 < wsa> Simon
09:03 < wsa> : wants to follow up on the link regression and alignment patches as well as
09:03 < wsa> checking the BSP for more RAVB patches
09:03 < wsa> Ulrich
09:03 < wsa> : wants to continue with SCIF RPM upporting
09:03 < wsa> Wolfram
09:03 < wsa> : wants to find and backport patches to fix suspend with SDHI, work on I2C
09:03 < wsa> core PM improvements, and upport I2C/SDHI patches from new BSP release
09:03 < wsa> C - problems I currently have
09:03 < wsa> -----------------------------
09:03 < wsa> Marek
09:03 < wsa> : with the limitations of the PCIE controller
09:03 < wsa> Niklas
09:03 < wsa> : might have less time assigned for SDHI work
09:04 < wsa> please fire away questions you have
09:04 < wsa> I have the following ones:
09:04 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi
09:05 < wsa> shimoda: I guess the usb-dmac driver could also benefit from the dma_parms update I did for the SYS-DMAC?
09:05 < wsa> shimoda: do you want to have a look at this or shall I add it for USB-DMAC, too?
09:05 < wsa> any other DMACs I missed?
09:07 < wsa> shimoda: should I pause with finding the SDHI commits which make resume on eMMC possible because you and Renesas Vietnam are working on it?
09:07 < geertu> usb-dmac is a separate driver, audio-dmac is just rcar-dmac
09:07 < shimoda> wsa: i think so, but I'd like to confirm first the usb-dmac also has the same issue :)
09:07 < wsa> or does it make sense working on that in parallel?
09:08 < geertu> We should find that commit by Sep 28, to get the fix in v4.14-ltsi-rc2
09:09 < wsa> shimoda: ok, sure, then I will wait
09:09 < shimoda> wsa: about SDHI/eMMC suspend/resume issue, since Renesas vietnam is focusing on LTSI testing, they cannot find the commits until 28th Sep.
09:09 < wsa> neg:
09:10 < wsa> shimoda: understood, I'll give it a priority boost then to make it until sep, 28th
09:10 < shimoda> wsa: thanks!
09:11 < neg> wsa: ?
09:11 < wsa> neg: (sorry, I hit enter to early, real question coming up)
09:12 < neg> :-)
09:12 < wsa> neg: I wonder a bit about no A) being NULL for the last two weeks although I thought this was the month with more SDHI time reserved?
09:13 < horms> On the subject of LTSI-4.14. I have one fix that is more or less ready to post. I'm unsure if its best to do so or wait, say until early next week, to see if any more fixes emerge.
09:13 < wsa> were there unforseen issues? or do you need assistance?
09:14 < wsa> or urgent m/m stuff?
09:15 < wsa> I don't want to blame you, I just wonder if we as groupleaders can do better planning
09:15 < neg> wsa: no it was mor or less planed as I spent most of the the previous two weeks segment on IO. 5.5 days/month on base is thin to spread around sometime
09:15 < wsa> I see
09:15 < wsa> Sorry, I thought you had more time assigned
09:16 < neg> wsa: I try to focus on one IP at a time to not waste time context switching :-)
09:16 < wsa> That sounds good
09:17 < wsa> OK, I learn from this that we (as groupleaders) maybe should talk more about absolute numbers
09:17 < neg> wsa: I do it's 6.6 not 5.5 days :-P
09:18 < wsa> can I cheer for you getting more days? :D
09:18 < wsa> you are probably fine as is this way, I assume
09:19 < wsa> ok, but with you having less time for SDHI in the future, I need to add another C) item for myself
09:19 < wsa> C)
09:20 < wsa> * developer time for SDHI is scarce
09:21 < wsa> (with developer time being scarce is nothing new :/)
09:21 < wsa> okay, other questions?
09:23 < wsa> well, seems core can have an early start today?
09:23 < wsa> geertu: are you up for it?
09:24 < Marex> wsa: besides the news that I finally managed to extract all the relevant info out of Lorenzo ...
09:24 < Marex> wsa: yet still, there's one last bit which he didn't answer fully and I have to read the PCIe spec for that
09:24 < Marex> wsa: that is, can a register other than PMCSR put a card into D3hot and thus link into L1 ?
09:24 < geertu> Marex: PCIe is core?
09:24 < Marex> wsa: and if so, is that PCIe compliant configuration
09:25 < Marex> geertu: PCIe is a bus :-)
09:25 < geertu> wsa: I'll wait 5 more minutes?
09:26 < wsa> Marex: I see. Thanks for keeping at it and diving into it.
09:26 < wsa> geertu: ok
09:26 < Marex> thing is, if PMCSR is the only register which can put a card into D3hot state, we can intercept such accesses in the PCIe code
09:26 < Marex> if not, we're doomed and need the ATF fixup
09:26 < wsa> understood
09:26 < Marex> I am afraid it's the later ...
09:26 < Marex> I mean, I can cook such a setup in an FPGA
09:27 < Marex> the question really is, does PCIe spec permit this
09:27 < Marex> and that neither me nor Lorenzo know ... and thus I need to read the spec again
09:27 < wsa> and what does hardware in reality really do
09:28 < Marex> wsa: what do you mean ? you can use setpci to write any register you want pretty much :)
09:28 < Marex> wsa: I don't know if such a card with custom register to enter D3hot exists, but I know it can be created with relative ease ...
09:28 < wsa> i mean specs are one thing, reality is another
09:28 < wsa> not more than that...
09:29 < Marex> wsa: there's too much hardware to know whether PMCSR is the only reg ever used to enter D3hot
09:30 < Marex> wsa: but if the spec says it is, then the certification checks it and we only support certified PCIe hardware
09:31 < wsa> we can do that
09:31 < Marex> wsa: ... and we can ignore hardware which doesn't use PMCSR to enter the D3hot as non-compliant
09:32 < damm> maybe non-compliant + non-compliant = success?
09:32 < damm> its like xor
09:32 < wsa> we only support non-compliant HW :D
09:32 < damm> =)
09:32 < geertu> damm: nah, it's like a CMOS gate with a floating input ;-)
09:33 < Marex> damm: isn't that more multiplicative operation ?
09:33 < wsa> Well, our HW semms broken, so if this is the best we can do, then OK
09:34 < wsa> but once we got more information about what to do (ATF or not), we should report again to the HW team
09:34 < damm> geertu: reminds me of sh7751 PCI power management
09:34 < damm> Marex: you are right
09:34 < wsa> ok, so now we are 5 minutes over time again :D
|
