summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20171109-io-chatlog
blob: 1813aa59f6d64db805a3bf83c72ef6803ff23644 (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
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
09:06 < wsa_> welcome to the io meeting
09:07 < wsa_> I didn't have the time to summarize your mail reports, so this time, we will do the good old 'sort -R ' way
09:07 < wsa_> however, I reduced the names to those who actually did work on IO
09:08 < wsa_> so, please post your updates now and we will see if there is something to discuss
09:08 < wsa_> shimoda-san, you are first this time :)
09:08 < shimoda> yes
09:08 < shimoda> A)
09:08 < shimoda>  - handle our customer team requests for i2c-sh_mobile.c driver.
09:08 < shimoda>  - Investigate USB3.0 peripheral issue that cannot use pipe 6 or more and I found the HW issue...
09:08 < shimoda>  - Submitted the following patch(es):
09:08 < shimoda>   - fix the SDHI driver for v4.14 as v2
09:08 < shimoda>  - Merged the following patch(es) into the subsystem:
09:09 < shimoda>   - fix the SDHI driver for v4.14
09:09 < shimoda> B)
09:09 < shimoda>  - Add gpio feature into phy-rcar-gen3-usb2.c for R-Car D3.
09:09 < shimoda>  - Submit changing USB3.0 peripheral spec. patch after management guys accepted for public.
09:09 < shimoda>  - Investigate USB3.0 role swap issue.
09:09 < shimoda>  - Fix USBHS driver more if I got feedback from HW team.
09:09 < shimoda> C)
09:09 < shimoda>  - Maintainer(s) doesn't review the following patch(es) yet...:
09:09 < shimoda>   - Add PWM dt-binding for r8a77995.
09:09 < shimoda> -- EOT --
09:10 < wsa_> Thank you!
09:10 < wsa_> Yes, lots of IIC requests. Is the customer OK with the infos reported back so far?
09:11 -!- horms_ [~horms@61.40.109.130] has joined #periperi
09:11 < shimoda> yes, the customer support team would like to fix the datasheet until end of Nov. So, reports are useful for it
09:11 -!- horms [~horms@61.40.109.130] has quit Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org
09:12 -!- horms_ is now known as horms
09:12 < wsa_> Understood!
09:13 < wsa_> so, I am next:
09:13 < wsa_> A)
09:13 < wsa_>         * gave talk and show case at ELCE
09:13 < wsa_>         * processed various requests about IIC driver
09:13 < wsa_>         * updated & resent I2C DMA series
09:13 < wsa_>         * SDHI naming discussion
09:13 < wsa_>         * assisted in riic clock frequency formula development
09:13 < wsa_> B)
09:13 < wsa_>         * add. tasks about less MMC core busy looping
09:13 < wsa_>         * process IIC requests further
09:13 < wsa_>         * review SDHI patches from Yamada-san
09:13 < wsa_>         * continue SDHI naming discussion
09:13 < wsa_> C)
09:13 < wsa_>         * SDR tasks are on hold currently, because of IIC
09:13 < wsa_> and I found another IIC issue, but I will write a mail about it
09:14 < wsa_> geertu: your turn
09:15 < geertu>   A)
09:15 < geertu>     - Sent v3 of PHY reset patches (originally by Sergey), needed for ravb
09:15 < geertu>       resume on Salvator-XS,
09:15 < geertu>     - Sent patches to enable watchdog on r8a77970 and Eagle,
09:15 < geertu>   B)
09:15 < geertu>     - Rework PHY reset patches according to review comments,
09:15 < geertu>     - MSIOF (add. task + issues reported by Dirk Behme).
09:15 < geertu>   C)
09:15 < geertu>     - Nothing.
09:15 < wsa_> Thank you!
09:16 < wsa_> jmondi2: the reliable testing hero, your turn ;)
09:16 < jmondi2> wsa_,  eheh... just tested your patches on Migo-R
09:16 < jmondi2> no special IO items for me
09:17 < wsa_> but you did that, nothing wrong with exposing it :)
09:17 < wsa_> Marex: your turn
09:18 < jmondi2> wsa_: nothing wrong at all indeed!
09:18 < Marex> wsa_: well, I found the eMMC 1V8 issue on salvator-X, which we discussed in the email
09:18 < Marex> wsa_: plus I submitted the PCIe suspend/resume patches for Gen3
09:18 < Marex> wsa_: V2 / V3 is needed
09:18 < Marex> wsa_: there was feedback from Sergej and geertu
09:19 < wsa_> Marex: thanks for taking over PCIE again.
09:19 < Marex> wsa_: there is still one patch missing which I did not submit, which is the DMA limit for Gen2
09:19 < wsa_> Marex: about the eMMC issue, I'd still like to find that in the spec
09:20 < wsa_> because IIRC SD needs to start with 3.3V and an explicit switch to 1.8V
09:20 < Marex> wsa_: since the Gen2 address space is 32bit while the PCIe address space is 64bit, that needs to be cleaned up
09:20 < wsa_> I'd assume eMMC is different but that should be mentioned somewhere in the specs?
09:20 < Marex> wsa_: ACK
09:21 < Marex> wsa_: I only found the power distribution in the eMMC's datasheet, which would imply the IO always operates at 1V8 on salvator-x
09:21 < wsa_> Marex: and please add phil edworthy to the PCIE patches. He used to look at this driver, too
09:21 < Marex> wsa_: he should be on CC already, will double-check if he's on CC on all
09:21 < wsa_> thanks
09:22 < wsa_> horms: last but not least
09:22 < horms> * IO
09:22 < horms> A)
09:22 < horms>     - Posted, now under review:
09:22 < horms>       [PATCH] spi: sh-msiof: Fix DMA transfer size check
09:22 < horms>       [PATCH] serial: sh-sci: Fix unlocked access to SCSCR register
09:22 < horms>     - Posted, now accepted:
09:22 < horms>       [PATCH] mmc: tmio: Replace msleep() of 20ms or less with usleep_range()
09:22 < horms>     - Posted earlier, now accepted
09:22 < horms>       + Add and use fallback bindings for SDHI and SH-Eth
09:22 < horms>       + Use GPIO fallback bindings
09:22 < horms> B)
09:22 < horms>     - Continue work on enabling HS400
09:22 < horms>     - Try to enable SDR-50 and SRR-104 on porter (patch posted, needs testing)
09:22 < horms>     - Try to enable NFS on ULCB (patch posted, needs testing)
09:22 < horms> C)
09:22 < horms>     - Is the following ready for upstream; should I rebase and repost?
09:22 < horms>       [PATCH v4 0/3] iommu/ipmmu-vmsa: r8a7796 support V4
09:22 < horms>     - No commit access to periupport
09:22 < horms> D)
09:22 < horms>     - None
09:22 < horms> I guess the first half of C is for Core, sorry for the mix up there
09:23 < wsa_> morimoto: can't we give simon access to periupport?
09:23 < morimoto> Oops ?
09:24 < horms> I have read access, but push seemed to fail. Perhaps it was an error on my part
09:24 < morimoto> let me check
09:24 < horms> thanks
09:25 < morimoto> I did
09:25 < morimoto> I think now it is OK
09:25 < horms> thanks
09:25 < wsa_> cool
09:25 < morimoto> (But I don't know this is OK for git policy :)
09:26 < morimoto> (= multi master)
09:26 < wsa_> so simon works now on periupport as well? merging the changes from his excel sheet slowly into the other list? or what is the current status?
09:26 < horms> I was looking over periupport manually
09:26 < horms> And I noticed some minor cleanups
09:27 < horms> No serious work to migrate from the spreadsheet yet
09:28 < horms> One problem I observe is that the spreadsheet tracks different information. F.e. if the patch is trivial, features or local.
09:28 < horms> But we can talk about this separately.
09:28 < wsa_> ok
09:29 < wsa_> did i forget someone / something concerning reports?
09:29 < horms> I only wanted to apply the patches I posted to periperi. I don't mind if someone else applies them.
09:29 < wsa_> well, seems you have write access now
09:29 < horms> ok, i'll push
09:29 < wsa_> I think it makes sense you have write access
09:30 < horms> done
09:30 < wsa_> OK then, another issue we have surely is the SDHI renaming issue, but I think, this is handled nicely by mail so far
09:31 < horms> agreed. I don't really mind much so long as things don't break
09:31 < horms> and we don't keep renaming the same driver endlessly...
09:32 < wsa_> about shimoda-sans request for r8a7795 bindings: I think we agreed that I will add SATA (unless somebody wants to take over), QSPI is not feasible on Linux currently, and CAN should be done by someone who can test.
09:32 < wsa_> D'accord?
09:32 < Marex> wsa_: what's the problem with QSPI ?
09:33 < Marex> wsa_: I plan to add RPC Hyperflash (CFI NOR) to Linux
09:33 < Marex> wsa_: QSPI is the same block, but I wonder how to make this support both CFI NOR and QSPI, that might need some thinking
09:33 < geertu> Marex: There's no "problem" with QSPI. There's just no need to add pinctrl support for it to Linux if there's no Linux driver.
09:34 < Marex> geertu: ah, sure
09:34 < geertu> If you write a driver, we can add pinctrl support (H3 ES1.x already has)
09:34 < Marex> geertu: ACK
09:34 < geertu> (... has pinctrl support)
09:35 < wsa_> that's it from my side. anything left from your side?
09:36 < shimoda> wsa_: about can pinctrl support, I asked Ramesh-san and Ramesh-san will do it.
09:36 < wsa_> Good news, thank you!
09:37 < wsa_> so, core takeover then?
09:38 < geertu> OK, thx