summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20190221-io-chatlog
blob: 67989cbaae91f50df832974b7364e39b90684da2 (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
09:04 < wsa> welcome to today's IO meeting
09:04 < wsa> status reports:
09:04 < wsa> Status updates
09:04 < wsa> ==============
09:04 < wsa> A - what have I done since last time
09:04 < wsa> ------------------------------------
09:04 < wsa> Geert
09:04 < wsa> : tested at25 spimem conversion, replaced spi_master by spi_controller in
09:04 < wsa>   various SPI drivers, and preliminary testing of SCIF5 DMA on R-Car E3
09:04 < wsa> Marek
09:04 < wsa> : worked on various SDHI issues in U-Boot, upported eMMC reset patch for SDHI,
09:04 < wsa>   got thermal patch which adds hwmon interfaces merged
09:04 < wsa> Shimoda-san
09:04 < wsa> :
09:04 < wsa> Simon
09:04 < wsa> : posted fix for AVB phy-mode on Draak, needs testing
09:04 < wsa> Wolfram
09:04 < wsa> : implemented a fault injector to simulate 'arbitration lost' without having a
09:04 < wsa>   multi-master setup, implemented a fault injector which panics during a
09:04 < wsa>   transfer so rebooting with an inconsistent bus state can be tested, converted
09:04 < wsa>   Gen2/3 IIC to use a better formula to calc the freqs, upported SDHI patch for
09:04 < wsa>   HW adjustment depending on speed mode, reviewed a few I2C and SDHI patches,
09:04 < wsa>   converted and pushed first periject data, sent my first glibc patch
09:04 < wsa> B - what I want to do until next time
09:04 < wsa> -------------------------------------
09:04 < wsa> Geert
09:04 < wsa> : wants to do more testing of SCIF5 DMA on R-Car E3
09:04 < wsa> Kaneko-san
09:04 < wsa> : wants to pport temperature calculation fixes for R-Car Gen3 and RZ/G2 SoCs
09:04 < wsa> Niklas
09:04 < wsa> : wants to nbox APE6EVM and make sure it boots and hopefully have a first look
09:04 < wsa>   at the MMC PM imbalance issue
09:04 < wsa> Shimoda-san
09:04 < wsa> : wants to
09:04 < wsa> Simon
09:04 < wsa> : wants to asses RAVB patches in BSP v3.9.2, measure MMC performance across
09:04 < wsa>   various Gen3 boards
09:04 < wsa> Wolfram
09:04 < wsa> : wants to upport I2C patches, continue working on atomic I2C transfers, assist
09:04 < wsa>   with whatever topics JapaPERI brings to the table
09:04 < wsa> C - problems I currently have
09:04 < wsa> -----------------------------
09:04 < wsa> None reported
09:05 < wsa> I am still waiting for Shimoda-san's report, I guess it will come along...
09:05 < wsa> I dropped all "meetings in BE" items because for me the reports should have been since the meetings in BE :)
09:06 < wsa> geertu: any plans for the MSIOF patches in bsp392?
09:06 < wsa> Marex: wasn't there also PCIe link handling in ATF as B)?
09:07 < Marex> PCI link handling in ATF is in submitted PR
09:07 < wsa> neg: can we drop the "hopefully" from the SDHI clk imbalance thing?
09:07 < Marex> since a few hours ago
09:07 < wsa> Marex: cool!
09:07 < Marex> (before I went to bed)
09:08 < wsa> uli___: dunno if you maybe did it already, but could you test the D3 phy patch that Simon mentioned in his report?
09:08 < neg> wsa: Depends on how confident you are that the APE6EVM works :-) Magnus warned me its status is unkown. But yes please remover it form the report
09:08 < uli___> wsa: can do
09:08 < wsa> uli___: thx
09:08 < geertu> wsa: Is there anything non-controversial w.r.t. MSIOF left?
09:09 < wsa> neg: ah, "hopefully" means "if the board works" and not "if I have time"?
09:09 < wsa> geertu: if it is controversial, please add comments to the ticket file, so I know
09:09 < neg> wsa: Yes
09:10 < wsa> neg: ah, good, I misunderstood this. Let me know how the board is doing :)
09:10 < neg> Will do, plan is to try it on Monday
09:11 < wsa> sounds good
09:12 < wsa> what is so special about SCIF5 DMA on Ebisu, BTW?
09:13 < geertu> The DMA documentation about it was wrong, so DT was wrong, too
09:14 < wsa> I see
09:14 < wsa> any questions from your side?
09:15 < geertu> I sort of verified the new one is OK, but am now looking for CP45 on the board, to connect a probe ;-)
09:15 < wsa> oh, we are on that level :)
09:16 < wsa> neg: do you still have that SDIO WIFI card or did you give it to JapaPERI?
09:16 < neg> I still have it
09:17 < neg> I try it from time to time tracking progress in the thread 'Test of EVK-EMMY-W161-A on Koelsch with SDR50 and SDR104' ;-)
09:18 < wsa> can you just check if it works with SDR104 for you? When testing Sergei's patch, I had to reduce it to SDR50 to make it probe :(
09:18 < Marex> geertu: I wonder what else is wrong on E3 Ebisu ... maybe the SDHI performance ?
09:18 < wsa> My test was on M3N
09:19 < geertu> Marex: Have you looked into the meaning of the values written to the QoS registers?
09:20 < neg> wsa: to be clear SDIO + M3N + '[PATCH v3] mmc: tmio_mmc_core: don't claim spurious interrupts' right?
09:21 < Marex> geertu: is there any documentation besides "QoS Level x Threshold y Setting" ?
09:21 < Marex> geertu: besides, we do not know whether it is QoS problem at all
09:21 < wsa> neg: yes. but other Gen3 boards are interesting, too
09:22 < wsa> neg: and the probing should really be independent of Sergei's patch
09:22 < neg> wsa: OK will do
09:22 < wsa> thx!
09:23 < geertu> Marex: From a quick glance, I already read things like "1.95 usec not supported on E3", so it uses 7.80 intead
09:24 < Marex> geertu: both work, changing that doesn't help
09:24 < Marex> geertu: and I think it was using 3.9 , not 7.8
09:25 < Marex> geertu: IIRC you can select either or with a MD switch
09:25 < geertu> ok
09:25 < neg> wsa: for reference did you test on top of mmc/fixes or mmc/next ?
09:25 < Marex> and if not, rebuild ATF for either or ... nonetheless, doesn't help
09:26 < Marex> either the SDHI is somehow underclock, or the bus somewhere between SDHI and DRAM is too narrow , or there's DRAM bottleneck
09:27 < wsa> neg: hmmm, either mmc/next or v5.0-rcX. Need to look this up, code is on another machine...
09:27 < Marex> DRAM bottleneck is unlikely, I did memtester and calculations, it gives more then plenty of bandwidth ... way more than 400 MB/s
09:27 < Marex> s/memtester/lmbench/
09:27 < neg> wsa: OK no worries I figure it out
09:28 < wsa> shall we move to core meeting then?
09:29 < wsa> looks like it
09:29 < wsa> geertu: the stage is yours
09:29 < wsa> thanks for this meeting!