summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20161206-core-chatlog
blob: bcc48dc0750155da8e24b6159790508ade240517 (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
141
142
143
144
145
146
147
148
149
150
151
Core-chat-meeting-2016-12-06

09:07 < geertu> Welcome to today's Core Group Meeting
09:07 < geertu> First, let me introduce a special guest: Jacopo!
09:07 < geertu> (or let him introduce himself ;)
09:07 < jmondi> ahah, hi Geert, thanks :)
09:08 < morimoto> Hi Jacopo !
09:08 < jmondi> hello everyone, I met most of you in Berlin, for anyone else my name's Jacopo, I'm based in Italy, and I'm working on 2 trail tasks with Magnus for this months
09:08 < jmondi> s/trail/trial
09:09 < jmondi> hope to meet you all in person soon ;)
09:09 < geertu> Thanks, Jacopo
09:09 < geertu> Agenda:
09:09 < geertu> 1. Status updates
09:09 < geertu> 2. Proposal from BSP team about PFC I2C ch0, 3 and 5.
09:09 < geertu> 3. FOSDEM+core confirmation: who?
09:09 < geertu> Topic 1. Status updates
09:10 < geertu>   A) What have I done since last time
09:10 < geertu>   B) What I plan to do till next time
09:10 < geertu>   C) Problems I have currently
09:10 < geertu> First (according to sort -r) is Simon
09:10 -!- horms [~horms@217.111.208.18] has quit [Ping timeout: 265 seconds]
09:11 < geertu> Nice try...
09:11 < neg> You scared him away :-)
09:11 < morimoto> :)
09:11 < geertu> Next is Shimoda-san
09:12 < shimoda> A) B) C) is nothing to me
09:12 < shimoda> --- END ---
09:12 -!- horms [~horms@217.111.208.18] has joined #periperi
09:12 < geertu> Thanks, Shimoda-san
09:13 < geertu> (2nd try) Next is Simon
09:13 < horms> sorry about that
09:13 < horms> network troubles as usual
09:13 < horms> Status:
09:13 < horms> A) What have I done since last time
09:13 < horms> * Analysed device tree binding status
09:13 < horms>   - Presence and use of SoC-specific and fallback compatibility strings
09:13 < horms>   - Posted some fixups
09:13 < horms> B) What I plan to do till next time
09:13 < horms> * Continue above
09:13 < horms> * See above
09:13 < horms> C) Problems I have currently
09:13 < horms> * Order of struct of_device_id entries.
09:13 < horms>   - Fallback last seems nice but unnecessary given my reading of
09:13 < horms>     __of_match_node()
09:13 < horms>   - If it is required then a behaviour change is implied for
09:13 < horms>     in-tree users of i2c-sh-mobile, intc-rcar
09:13 < horms> -- end --
09:14 < geertu> You are right, __of_match_node() assigns a higher score to the first compatible value in the node.
09:14 < geertu> So it shouldn't be needed.
09:14 < geertu> Still, I think it's nice to list "fallback" values last.
09:15 < horms> ok, understood
09:15 < horms> i need to repost the pci series anyway
09:15 < horms> i'll reword the changelog
09:15 < horms> and also look to fixing up other caes
09:15 < geertu> Thanks Simon.
09:15 < geertu> Next is Niklas
09:16 < neg> A) Nothing
09:16 < neg> B) Start to work on 'GPIO-RCAR,?,noplan,?,Fix Runtime PM with GPIO interrupts (depends on irqchip PM)
09:16 < neg> C) None
09:16 < neg> EOT
09:17 < geertu> Thanks, Niklas
09:17 < geertu> Next is Morimoto-san
09:17 < morimoto> struct core_task *a = *b = *c = NULL;
09:17 < morimoto> return 0;
09:17 < geertu> Thanks. Morimoto-san
09:18 < geertu> Laurent seems to be away
09:18 < geertu> Next is myself
09:18 < geertu> A) Worked with Simon and Arnd to get our pull requests for arm-soc accepted.
09:18 < geertu> Sent pull requests for soc_device_match() and RZ/G clock definitions
09:18 < geertu> B) Coerce Simon into taking all MODEMR related patches
09:18 < geertu> 2017Q1 additional tasks
09:19 < geertu> C) What's wrong with the IPMMU? (more like a retorical quesiton)
09:19 < geertu> EOT
09:19 < horms> a) thanks!
09:19 < horms> b) happy to negotiate :)
09:19 < geertu> From the emails, looks like the HW team is investigating the IPMMU?
09:20 < geertu> Last (present) is Jacopo
09:21 < jmondi> A) PFC patches for Gyro-ADC: v3 in review
09:21 < jmondi>   Enabled and tested MAX11100 ADC on genmai board. RFC patches sent out
09:22 < jmondi> B) Not sure is a core task, but I should write an IIO driver for that same ADC this week
09:22 < jmondi> C) none
09:22 < jmondi> that's all from me
09:22 < jmondi> -- end --
09:22 < shimoda> geertu: yes, the HW team is investigating the IPMMU now.
09:23 < geertu> IIO drivers are indeed not core, but I/O. I don't know if Wolfram plans an I/O chat later this week.
09:23 < horms> jmondi: please consider patches to enable options in defconfigs if appropriate
09:23 < geertu> Thank Jacopo
09:23 < geertu> horms: The MAX11100 ADC is an add-on, not an on-board device
09:24 < jmondi> horms: for ADC you mean?
09:24 < jmondi> yes, it's temporary connected to one of Genmai's expansion header
09:24 < horms> It was just a general request. I'd need to look at the patches more closely to make a specific request regarding them.
09:25 < jmondi> need to sync with Magnus because we'll use another board, but it will remain connected to some expansion connector I guess
09:25 < horms> Ok
09:25 < horms> understood
09:25 < horms> my comment is probably not relevant in that case
09:25 < jmondi> horms: it may be for future! thanks anyway :)
09:26 < geertu> Topic 2. Proposal from BSP team about PFC I2C ch0, 3 and 5.
09:26 < geertu> Submitted by Shimoda-san
09:27 < shimoda> yes, should i explain?
09:27 < geertu> Yes please.
09:27 < neg> shimoda: yes please
09:28 < shimoda> I sent an email. BSP team would like to set the such pins via PFC driver
09:29 < shimoda> the pins spec differs than other pins. so bsp team think that the PFC driver should have other way
09:29 < geertu> IIUIC, multiple functions can be muxed to the i2c pins, but they cannot be used for GPIO?
09:30 < shimoda> geertu: let me check...
09:30 < geertu> It uses PIN_NUMBER('B', 11)
09:32 < geertu> But it also touches avb, hscif, msiof, pwm, sdhi
09:33 < geertu> Does it mean those functions are mutually exclusive with the i2c function, although they use different pins?
09:33 < geertu> And is this ES1.0 or ES2.0?
09:35 < shimoda> geertu: i don't know this is ro es1.0 or es2.0
09:37 < shimoda> about this mod_sel, as you said, they are muxed pins.
09:39 < shimoda> and these i2c pins cannot bd used for GPIO
09:40 < shimoda> this patch reuses POC/DRVCTRL register setting thing
09:41 < shimoda> BSP team would like to know this policy is good or not
09:41 < geertu> Ah, it's for e.g. "Phisically muxed with AVB_AVTP_MATCH_A" inside some floating comment box in (preliminary)CSD15-676_R-CarH3_pinfunction(Rev0p290)_customer.xlsx, which you cannot search for using LibreOffice
09:44 < geertu> According to that xlsx, it uses the same pin numbers as the "Phisically muxed" pins, but in a different row of the sheet.
09:45 < neg> It's pinmux for none-GPIO pins right?
09:45 < geertu> Can't we just use the corresponding RCAR_GP_PIN()?
09:46 < geertu> E.g. SCL0 is SoC pin AA33, SiP pin C29
09:47 < geertu> But SD1_CD is also AA33 / C29, and GP3_14
09:48 < geertu> so we could use RCAR_GP_PIN(3, 14) instead of PIN_NUMBER('C', 29)?
09:48 < geertu> What am I missing?
09:49 < geertu> I think this needs more clarificiation / investigation, offline.
09:50 < geertu> shimoda-san: Do you agree?
09:51 < shimoda> geertu: about red line in the xlsx file, it seems your comment is match, i will ask hw team or/and bsp team
09:51 < shimoda> and offline, it's nice to me :)
09:51 < shimoda> s/red line/red rectangles/
09:52 < neg> yes, I think if there are a  RCAR_GP_PIN() for that pin it should be used, or I'm also missing something
09:52 < geertu> It depends on what "Phisically muxed" really means
09:54 < geertu> (in gnumeric, it shows a black rectangle. I also cannot search for its contents, but I can move (not edit) it ;-)
09:54 < geertu> Let's continue
09:54 < geertu> Topic 3. FOSDEM+core confirmation: who?
09:55 < geertu> So it seems like Morimoto-san will miss the rabbits, and will go to trump(et)land instead ;-)
09:55 < geertu> Who's still planning to attend FOSDEM, and a core meeting on Friday before?
09:55 < geertu> +1 Geert
09:56 < neg> I will go to FOSDEM but have yet to book my tickets
09:57 < neg> (and attend the core meeting on Friday ofc)
09:57 < horms> If there is a Core meeting then I expect to be there
09:57 < horms> I may also come up with other reasons to be there, but that is the main one at this time
09:57 < jmondi> I'll be at fosdem. Hopefully I'll still have a reason to join these meetings :)
09:59 < morimoto> Please enjoy rabbits in FOSDEM :)
10:00 < geertu> I prepared rabbit two weeks ago
10:01 < geertu> I think we're finished, unless someone has still something to add?
10:01 < neg> are there any periperi plans for ELC timing since Morimoto-san will not join at FOSDEM? I have not made any plans for ELC but if I'm to go I think it's best to book soon :-)
10:02 < geertu> deadline for proposals is this Saturday.
10:02 < geertu> I don't plan to go to ELC this time.
10:03 < neg> ok sorry for proloning the meeting just wanted to check so I don't have to buy expensive tickets later on
10:03 < horms> I am considering going but so far have no plans
10:04 < geertu> neg: the tickets may become cheaper after the inauguration of the next president ;-)
10:06 < neg> geertu: haha yes and his inauguration is at end of Jan so maybe the riots in portland have settled down by ELC
10:08 < geertu> Thanks for joining, and have a nice continued day!