summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20171005-io-chatlog
blob: 05ef52a9ad5f9eca73999c4426413c81dbb81313 (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
10:17 < geertu> Marex: Core related? I should hand over the mic to Wolfram...
10:17 < Marex> shimoda: I sent out the xhci patch I plan to submit to the U-Boot list to the periperi list first, the license grant should be OK, can you double-check please ?
10:18 < Marex> geertu: well it's inbetween, U-Boot is core and xhci is IO
10:18 < shimoda> Marex: sure, I will check it
10:18 < Marex> shimoda: thank you !
10:18 < Marex> shimoda: it'd be convenient if this worked out, since now I can just type "usb reset" and it works :)
10:19 < Marex> shimoda: it's hassle-free
10:19 < shimoda> Marex: nice! :)
10:20 < wsa_> geertu: don't worry, I am fine
10:20 < Marex> shimoda: btw re HS200/400 and SDR104, I am a bit blocked by the SD/MMC maintainer in U-Boot, sorry about that
10:20 < Marex> shimoda: he's not picking patches as fast as I'd like him to
10:20 < Marex> shimoda: I'm looking for ways to ... uh ... expedite that process
10:21 < shimoda> Marex: i got it. thanks!
10:21 < Marex> shimoda: you're welcome, I'll keep you updated
10:22 < wsa_> Marex: is yamada-san working on this, too?
10:22 < Marex> wsa_: Masahiro Yamada-san ?
10:22 < wsa_> hai
10:22 < Marex> wsa_: he works for socionext, although he did implement the uniphier-sd which I now use on RCar Gen3
10:22  * neg brb 2 min
10:22 < Marex> wsa_: their block doesn't support the HS200/400/SDR104 modes though, that's renesas specific
10:23 < Marex> wsa_: so he just reviews my uniphier-sd patches (which is nice) and makes sure they work on both
10:23 < wsa_> I see
10:24 < Marex> wsa_: the blocker really is the SD/MMC subsystem maintainer, he just doesn't respond much
10:24 < Marex> wsa_: some not long time ago I was really tempted to just replace him and start handling the SDMMC stuff myself
10:25 < Marex> wsa_: but then he came back, at like 5 mins to 12 and rolled out a PR ...
10:25 < wsa_> how about co-maintaining?
10:25 < Marex> wsa_: I feel like I'm hoarding functions ;-)
10:26 < wsa_> I see
10:26 < wsa_> that happens easily, yes
10:26 < Marex> wsa_: right
10:26  * neg back
10:26 < Marex> wsa_: and since U-Boot isn't as prestigeous as linux, maintainers don't really queue up to do it
10:27 < wsa_> okay
10:27 < Marex> wsa_: anyway ... maybe we should continue rather than complain about lack of manpower all over the place ? :)
10:27 < wsa_> ack
10:29 < wsa_> geertu: can i take over? or did i already? :)
10:29 < geertu> wsa_: I think you already did
10:30 < jmondi> ETHER is working as well \o/ (sorry to jump in with random messages, is rude, but I'm happy, now the peach is a grown up baby!)
10:30 < wsa_> well, then: welcome to the already started io meeting :D
10:30 < wsa_> jmondi: no problem, but only for success messages ;)
10:31 < jmondi> wsa_: I would be mostly silent then :)
10:31 < wsa_> ok, i collected (and rephrased) the ABC questions
10:31 < wsa_> and added a comment here and there, here they go:
10:31 < wsa_> A)
10:31 < wsa_> 	* Geert worked on RAVB PHY reset to support supsend/resume
10:31 < wsa_> 	* Niklas did SDR104/SDIO tests on Koelsch
10:31 < wsa_> 	* Simon got the RAVB RX checksum offload patch merged
10:31 < wsa_> 	* Uli got the HSCIF HW timeout patch merged and resent the HSCIF sampling point shift patch
10:31 < wsa_> 	  (the latter raised a few comments, though)
10:31 < wsa_> 	* Shimoda-san got f_printer driver merged and fixed quite some USB issues and added quite some
10:31 < wsa_> 	  DT nodes, and added suspense/resume support for USB PHY
10:31 < wsa_> 	* Wolfram discussed add. tasks and upport lists, added I2C to Salvator-XS, resend the eMMC drive
10:31 < wsa_> 	  strength patches, and commented on SDHI SDR104 tests and regulator patches
10:31 < wsa_> B)
10:31 < wsa_> 	* Geert will keep an eye to get RAVB PHY reset working and wants to tackle MSIOF again
10:31 < wsa_> 	  (multiple chip selects, I assume?)
10:31 < wsa_> 	* Simon starts working on HS400
10:31 < wsa_> 	  (nice timing because Marek works on HS400 for U-Boot currently)
10:31 < wsa_> 	* I assume Uli will keep working on the sampling point patch?
10:31 < wsa_> 	* Shimoda-san works on the USBHS driver more if he gets feedback from HW team
10:31 < wsa_> 	* Wolfram wants to finalize the I2C DMA patches, improve the I2C fault injector and start
10:31 < wsa_> 	  preparing the talk & showcase about it for ELCE, debug SDR104 on Gen2, and add. tasks
10:31 < wsa_> 	  plus upport lists, of course.
10:31 < wsa_> C)
10:31 < wsa_> 	* Shimoda-san's patches for USB2.0 phy for r8a77995 got no feedback from PHY maintainer
10:31 < wsa_> 	* Wolfram wonders where all the time since San Sebastian has gone
10:32 < wsa_> please have a look if everything is correct or i missed something
10:33 < geertu> wsa_: German tax rate is how many %? ;-)
10:34 < wsa_> too many :D
10:35 < wsa_> it stops at 42% IIRC
10:35 < wsa_> okay, there don't seem to be any comments
10:35 < wsa_> other than taxes
10:35 < horms> HS400 will be fun, but the fun hasn't started yet. Tax is less fun, we can swap notes another time.
10:36 < Marex> horms: HS400 seems like HS200 DDR, why the worry ?
10:36 < wsa_> I don't really have other topics for now; I'd think the SDR stuff and the upport list discussion are better suited for emails currently
10:36 < wsa_> unless there is something you guys want to discuss right now
10:37 < horms> Marex: thanks for the encoragement :)
10:38 < Marex> horms: well I was serious, it doesn't seem all that different
10:38 < wsa_> at least we won't have "long cable" problems with HS400 :)
10:38 < Marex> ^_^'
10:38 < geertu> wsa_: Why not?
10:38 < wsa_> HS400 is eMMC only
10:38 < horms> eMMC is on the board
10:40 < wsa_> dammsan: do you need anything from me regarding add. tasks?
10:40 < geertu> UHS-III is even faster, and using actual cards?
10:41 < wsa_> looks like it
10:42 < wsa_> maybe microsd only, though
10:42 < Marex> wsa_: they use PCIe-like bus
10:42 < Marex> for UHS3 that is
10:43 < Marex> the full-size UHS3 cards have extra pads for that, differential ones
10:43 < Marex> I think the bus might even be PCIe compatible right away
10:43 < wsa_> heh
10:44 < Marex> well that's where it's all headed anyway
10:44 < wsa_> let's see what comes out of that :)
10:44 < Marex> USB3 and PCIe use the same physical layer, the SD probably joins that too
10:44 < Marex> shimoda: I just received USB3 Totalphase Beagle 5000 V2 :-3
10:44 < wsa_> let's see how this will all end up in some R-Car Generation
10:45 < wsa_> but for now, it is SDR104 and HS400 :)
10:45 < wsa_> so, last call for topics from your side
10:46 < wsa_> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaand we are done!
10:46 < wsa_> Thank you guys!
10:46 < neg> thanks all
10:46 < shimoda> Marex: wow! nice!
10:46 < shimoda> thank you!
10:47 < jmondi> thank you all!
10:47 < Marex> thank you all!
10:47 < jmondi> neg: pinchartl: kbingham: catch you later
10:47 < uli__> see you
10:47 < horms> wsa_: were we going to talk about upporting about now?
10:48 < wsa_> i don't think so
10:48 < wsa_> i mean we can do
10:48 < wsa_> but i think it would be good to have morimoto-san here, too
10:48 < Marex> shimoda: jupp, so many hard-to-debug USB problems are hopefully fixed soon :)
10:48 < horms> Sure. Perhaps we can continue the discussion via email.
10:48 < wsa_> i'd suggest to keep discussing via email until then
10:49 < wsa_> ;D
10:49 < shimoda> Marex: I hope so :)
10:49 < horms> my question for you would be: do you think it would be more useful for Kaneko-san to help with keeping the upport list up to date, or to focus on upporting trivial patches
10:52 < wsa_> hmmm
10:53 -!- horms [~horms@217.111.208.18] has quit Quit: Leaving
10:55 < wsa_> seems this answer also needs to go via email...
t seems difficult 09:32 < morimoto> Blocker is it. 09:33 < morimoto> pinchartl said that V4L2 side is thinking about .query method ? 09:33 < morimoto> but, I still wondering about it. 09:33 < pinchartl> it's a problem that spans multiple subsystems, so it should be implemented at the media controller level in my opinion 09:34 < pinchartl> but we're definitely not there yet and it will require a lot of work 09:34 < morimoto> does your "we" mean PeriMulti ? or V4L2 ? 09:35 < morimoto> or Linux ? 09:35 < pinchartl> Linux :-) 09:35 < morimoto> hehe, OK :) 09:35 < pinchartl> I know how I'd like to see this being implemented 09:35 < pinchartl> and it would require using the media controller framework in DRM/KMS and ALSA 09:36 < pinchartl> which means that we need to solve the MC core issues first 09:36 < morimoto> MC core ? 09:36 < pinchartl> otherwise it will not be possible to convince other subsystems to use it 09:36 < pinchartl> media controller core 09:36 < morimoto> Ahh OK 09:37 < morimoto> From ALSA side point of view, it need to care about non-HDMI and HDMI. So my question is that 09:37 < morimoto> Does your "MC" is related to both non-HDMI and HDMI ? 09:37 < morimoto> or only HDMI ? 09:37 < pinchartl> both 09:37 < morimoto> Hmmm 09:37 < morimoto> This means, existing ALSA itself need to be update ? 09:38 < morimoto> without HDMI support 09:38 < pinchartl> the problem is that we need to know about port types to parse and walk the DT OF graph 09:38 < pinchartl> that information isn't available in DT 09:38 < pinchartl> it is only known to drivers 09:38 < morimoto> Yes. 09:38 < morimoto> But, in existing ALSA, all are sound, no question. 09:38 < pinchartl> so we can't implement generic OF graph parsing and walking code without help from drivers 09:39 < pinchartl> we need a new API for drivers to provide the information 09:39 < morimoto> OK, I see. but I wonder, this means, I can't rework for HDMI sound at this point ? 09:40 < pinchartl> when an OF graph is limited to one of the ALSA, DRM and V4L2 subsystems only, we can implement a subsystem-specific solution 09:40 < pinchartl> but in the general case, we need a solution that is compatible will all three subsystems 09:40 < pinchartl> so we need a common object that can implement this API 09:40 < pinchartl> and at the moment we have none 09:41 < morimoto> My ? is related to here 09:41 < pinchartl> the best candidate in my opinion is the media_entity object, that would need to be used by all three subsystems 09:41 < pinchartl> HDMI sound doesn't involve V4L2 but it involves the two other subsystems 09:41 < morimoto> three = ALSA / DRM / V4L2 ? 09:41 < pinchartl> yes 09:42 < morimoto> If this OF graph is related to only multimedia case, right ? 09:42 < pinchartl> it should be yes 09:42 < morimoto> If non multimedia want to use OF, it will not be "media_entity" 09:42 < morimoto> Hmm... 09:43 < pinchartl> correct, but non-multimedia devices don't involve ALSA :-) 09:43 < pinchartl> I'm open to other proposals, but in any case I believe this will be lots of work 09:43 < morimoto> But can use OF-graph ? 09:44 < morimoto> Is this related to know "which port is what type" ? 09:44 < morimoto> = OF-graph 09:44 < pinchartl> it's related to OF graph parsing 09:44 < pinchartl> not only about port type 09:45 < pinchartl> a DT node has ports that describe its external connections 09:45 < morimoto> OK, if so, naming should use "media" ? 09:45 < morimoto> should not 09:45 < pinchartl> but doesn't include information that describe the internals of the IP core 09:45 < pinchartl> that's the information missing at the moment 09:46 < pinchartl> we could use a different namespace, implement the API at a different level 09:46 < pinchartl> I'm not sure where though 09:46 < morimoto> I understand basic ideas 09:47 < morimoto> I wonder where do you (or other guys ?) discuss this topics ? 09:47 < morimoto> I mean which ML ? 09:47 < morimoto> ALSA side guys need to join it 09:47 < pinchartl> MC discussions usually happen on the linux-media mailing list 09:48 < pinchartl> if we implement the API somewhere else, I don't know 09:48 < morimoto> This is "OF-graph" releated method, right ? 09:48 < morimoto> we can get information from this new API 09:48 < morimoto> not only type, but many information 09:49 < pinchartl> yes, we need more than just the type 09:49 < morimoto> But this OF-graph use is not only V4L2, ALSA. 09:49 < pinchartl> if you have a DT node with 4 ports 09:49 < pinchartl> two inputs and two outputs 09:49 < morimoto> Other device can use it ? 09:50 < morimoto> I don't know who, but not only media I think ? 09:50 < pinchartl> it could be that internally input 1 is connected to output 1 and input 2 to output 2, creating two separate unrelated pipelines 09:50 < pinchartl> when parsing the graph we'd need to know about that 09:50 < pinchartl> possibly, but at the moment only multimedia devices use OF graph 09:51 < morimoto> OK 09:51 < morimoto> So, this means, my HDMI sound can't upstream at this point, right ? 09:52 < morimoto> It will be step 3 or later 09:52 < morimoto> not step 1 09:53 < pinchartl> yes, I think we're blocked at the moment 09:53 < morimoto> OK. can you update multimedia/todo ? 09:53 < morimoto> It is not my fault :P 09:53 < morimoto> It is = delaying 09:54 < pinchartl> obviously another approach would be to use a different style of DT bindings that would be easier to handle. lots of options are possible. we're at a brainstorming stage, someone needs to drive the effort with all the upstream subsystems. it's lots of work :-/ 09:54 < pinchartl> sure, it's not your fault :-) 09:55 < morimoto> Hehe :) thanks 09:55 < pinchartl> I'll remove the target version from the todo list 09:55 < morimoto> So, I will start other tasks. 09:55 < morimoto> Thanks 09:55 < pinchartl> well 09:55 < pinchartl> if you move to other tasks 09:55 < pinchartl> who will solve this problem ? :-) 09:56 < morimoto> Oops, OK 09:56 < morimoto> I am 1 of un-lucky guys :) 09:56 < pinchartl> welcome to my world :-) 09:56 < morimoto> Hehe :) 09:57 < morimoto> I think I want to talk to you in F2F in some day 09:57 < morimoto> Maybe ELC 09:57 < morimoto> ? 09:57 < morimoto> Do you go there ? 09:57 < pinchartl> I will be there 09:57 < morimoto> OK 09:57 < pinchartl> I've submitted a talk proposal, I hope it will be accepted 09:58 < morimoto> OK 09:58 < morimoto> that's it from me 09:58 < pinchartl> it's quite a lot already :-) 09:58 < pinchartl> thank you 09:58 < pinchartl> (now I have to summarize this in the report...) 09:59 < pinchartl> I assume that your plans for the next two weeks is holidays ? :-) 09:59 < pinchartl> (29th to 9th if I remember correctly) 10:00 < morimoto> Me ? yes 10:01 < pinchartl> neg: you're next 10:01 < neg> a) Started to address CSI2 review comments, more work needed. 10:01 < neg> b) Continue addressing CSI2 comments, but don't expect to resend before next meeting due to holidays and vacation. 10:02 < neg> c) None. 10:02 < neg> EOT 10:02 < pinchartl> thank you 10:03 < pinchartl> next topic: next meeting 10:03 < pinchartl> if we keep the current biweekly schedule that would be January the 4th 10:04 < pinchartl> however, Niklas and Morimoto-san will still be on holidays 10:04 < pinchartl> and Ulrich and Kieran will just be back 10:04 < kbingham> pinchartl: Bump it by a week? 10:04 < pinchartl> so I don't expect there will be much to discuss 10:04 < pinchartl> kbingham: that's my proposal, yes 10:04 < kbingham> pinchartl: then seconded :D 10:04 < pinchartl> about about January the 11th at 08:00 GMT / 09:00 10:04 < pinchartl> CET / 10:00 EET / 17:00 JST 10:05 < neg> works for me 10:05 < kbingham> day after my birthday ... I'll bring cake 10:05 < pinchartl> :-) 10:05 < pinchartl> how old will you be ? 10:05 < morimoto> it is OK for me 10:06 < kbingham> 0x21 10:06 < kbingham> :D 10:06 < pinchartl> :-) 10:07 * morimoto I booked Kieran's birthday on my calender 10:07 < kbingham> hehe 10:07 < pinchartl> that's all I had for today 10:08 < pinchartl> I propose adjourning the meeting 10:08 < pinchartl> does anyone second ? 10:08 < kbingham> I 10:08 < pinchartl> meeting adjourned, thank you all for attending 10:08 < morimoto> 2nd ! 10:09 < morimoto> Thank you