summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20190822-core-chatlog
blob: ee0387bc4a51c7554a4514fbba586a1041dc8cbf (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
09:36 < geertu> Welcome to today's core group chat
09:36 < geertu> Agenda:
09:36 < geertu> 1. Status Updates
09:36 < geertu> 2. Discussion Topics
09:37 < geertu> Topic 1. Status updates
09:37 < geertu> A) What have we done since last time:
09:37 < geertu> Kaneko-san sorted more nodes in arm64 DTS.
09:37 < geertu> Marek worked on ATF (Condor, DDR B, BSP upport), U-Boot (ULCB CPLD
09:37 < geertu> control tool, R8A66597 DM/DT), Linux (PCIe 32bit limitation and DMA
09:37 < geertu> range handling).
09:37 < geertu> Shimoda-san submitted PFC fixes.
09:37 < geertu> Simon cleant up DT binding doc filenames.
09:37 < geertu> Ulrich reviewed R-Car H1 DTS fixes.
09:37 < geertu> Geert reviewed the pwm-rcar/pfc/gpio patches, sent pull requests for
09:37 < geertu> v5.4 (arm-soc/pfc), submitted OSTM unique device names and always-on PM
09:37 < geertu> Domain fixes, did periject housekeeping, and improved ARM Cortex-A7/A9
09:37 < geertu> Errata selection.
09:38 < geertu> B) What we plan to do till next time:
09:38 < geertu> Marek plans to work on U-Boot (limited USB sticks, Migo-R and R2D
09:38 < geertu> DM/DT).
09:38 < geertu> Shimoda-san plans to ping the BSDL files, and continue preparing
09:38 < geertu> rcar-dmac patches for V3U.
09:38 < geertu> Simon plans to continue cleaning up DT binding doc filenames.
09:38 < geertu> Geert plans to send more pull requests for v5.4 for clk/pfc/arm-soc, and
09:38 < geertu> rework always-on PM Domain fixes, determine_rate() patches, and the GPIO
09:38 < geertu> aggregator.
09:38 < geertu> C) Problems we have currently:
09:38 < geertu> Geert wonders how to treat R-Car M3-W ES3.0 aka M3-W+.
09:38 < geertu> ---EOL---
09:38 < geertu> Anything I missed?
09:39 < geertu> shimoda: About "Switching multiplexed LSI pins during operation is not guaranteed"
09:39 < geertu> I think this means that it cannot guarantee that there are no glitches
09:40 < geertu> For PWM output, glitches shouldn't harm much
09:41 < geertu> As the PWM hardware doesn't seem to finish the current cycle when changing PWM parameters, glitches cannot be avoided anyway.
09:45 < shimoda> geertu: sorry I cannot understand your last comment. is this related to gpio thing? or just PWM hardware?
09:46 < geertu> shimoda: My last comment was related to the rcar-pwm hardware
09:47 < geertu> IIRC, you replied that to a question from Uwe about finishing cycles?
09:49 < geertu> Oops, looks like I misread: "the hardware will complete the currently running period"
09:49 < shimoda> geertu: Yes, I replied to Uwe. this is a violation between PWM subsystem vs the rcar-pwm hardware.
09:49 < geertu> but not when disabling it.
09:51 < shimoda> pwm itself is no problem about glitches point of view, I think.
09:51 < shimoda> s/pwm/rcar-pwm hardware/
09:51 < geertu> So the question for continuing with PWM/GPIO is: can we live with the glitches
09:54 < shimoda> geertu: I don't think we can live for now. Especially, any customer don's ask us about this topic for now. If customer wants such a feature, our hardware team will start to investigate how to achieve it :)
09:54 < geertu> OK
09:54 < geertu> case closed ;-)
09:54 < shimoda> :)
09:55 < geertu> I think that already counted as a Topic 2. Discussion Topics
09:55 < geertu> B) R-Car M3-W ES3.0 aka M3-W+
09:56 < geertu> Eugeniu nicely summarized the possible approaches
09:56 < geertu> He did miss H3 ES2.0 cam with a new part number, too (r8a77951)
09:56 < geertu> s/cam/came/
09:59 < geertu> For H3 ES2.0, it turned out to be a different SoC than ES1.x (H3 ES2.0 is more similar to M3-W ES1.0 than to H3 ES1.x)
10:00 < geertu> It was mentioned before that in hindsight, we should have gone for separate compatible values for H3 ES2.0
10:00 < geertu> So I'm leaning towards doing that for R-Car M3-W+
10:01 < geertu> In the mean time, we did become used to five digit part numbers.
10:02 < geertu> My questions:
10:02 < geertu> 1) What do you think?
10:02 < geertu> 2) Do we have hardware access (e.g. in Magnus' farm)?
10:05 < shimoda> about M3-W and M3-W+, we can keep both dts files? (Unfortunately) this is because both SoCs will be mass production.
10:06 < geertu> If both will be mass-production, that's another reason to treat them different
10:06 < shimoda> about 2), I will bring one of M3-W+ board to Magnus' farm.
10:06 < geertu> shimoda: 2) thx!
10:06 < geertu> I guess H3 ES1.x is no longer produced
10:07 < geertu> BTW, if hardware bugs need to be fixed, will M3-W have both ES 2.1 (without +) and ES4.0 (with +)? ;-)
10:07 < shimoda> geertu: yes. H3 ES1.x will not be mass-production
10:08 < wsa> geertu: please stop, my head is already spinning :)
10:08 < shimoda> geertu: i think so. maybe ES1.4 and ES3.1 though :)
10:09 < geertu> Ah yes, they cannot have ES2 due to the PRID screwup ;-)
10:10 < geertu> For H3, we always said the upstream default should be the production version
10:11 < geertu> For M3-W, there will be two, so that warrants having both r8a7796 and r8a77961
10:12 < geertu> Let's stop spinning heads for now...
10:12 < geertu> 3) ELC-E: Do we need/want/have a periperi meeting?
10:13 < wsa> who will be at plumbers?
10:13 < morimoto> no JaPeri
10:13 < uli_> i will
10:13 < pinchartl> I will be at LPC and ELCE
10:13 < jmondi> me 2
10:14 < geertu> I won't be at LPC, bit I will at ER and ELCE
10:14 < pinchartl> Niklas will attend both too, Kieran will only attend ELCE
10:14 < wsa> I'll be at LPC, the recipes, and ELCE
10:15 < wsa> my gut feeling says, let's have email-only reports in three weeks
10:15 < pinchartl> I think that's best
10:15 < morimoto> +1
10:15 < wsa> the alternative might be an IRC meeting in 2 weeks
10:15 < pinchartl> for ELCE, do we have topics that require face to face discussions ? on the multimedia side, I don't think we do
10:16 < geertu> pinchartl: same for core, I think, unless I'm missing something
10:16 < wsa> pinchartl: i don't know yet
10:16 < geertu> email-only reports in three weeks is fine for me
10:17 < wsa> okay, email-reports in 3 weeks is it then
10:17 < pinchartl> then we should certainly meet at ELCE, but I don't think we need to reserve a day for full-time meetings :-)
10:17 < pinchartl> a dinner meeting may be more appropriate
10:17 < wsa> pinchartl: same impression here
10:19 < geertu> Monday evening is partner reception (some of us?)
10:19 < wsa> yup
10:19 < geertu> Tuesday evening is attendee reception (all of us?)
10:19 < pinchartl> I won't be free on Tuesday
10:19 < geertu> So that makes Wednesday evening, after the closing game?
10:20 < pinchartl> for preference would be Wednesday indeed
10:20 < geertu> (and I can rail back home on Thursday ;)
10:20 < pinchartl> there may be V4L2 discussions on Thursday, but I don't suppose you'll want to attend :-)
10:23 < geertu> Anything else to discuss (besides multimedia)?
10:24 < geertu> Thanks for joining, and have a nice continued day!
issue [17:43] <kbingham> ?? <kbingham> Have I just walked into a meeting that I didn't know was happening ? <jmondi> uli___: and it actually did, this morning I re-based on v4.16, first boot was ok, but now I still need to power cycle to have capture working <neg> jmondi: have you nailed it down to know if s_stream() have been called or if it's the set_fmt() that is the last v4l2 callback? [17:44] <morimoto> kbingham: meeting is almost ending stage now :) <kbingham> morimoto: Oh my ... I'm sorry ! I thought meetings were thursdays! <jmondi> neg: with strace I see g_fmt being called and that's it <neg> kbingham: :-) <jmondi> but I would not trust strace too much to debug these kind of issues <morimoto> kbingham: :) [17:45] <neg> jmondi: i think some trace printouts in rcar-vin/rcar-dma.c would be usefull to know if it's s_stream() or something else cousing the lockup [17:46] <jmondi> neg: you see, it is freaking 'random'.. I've been capturing images for a good 2 hours, rebooted the board, no kernel updates, now it hangs <kbingham> neg: M3-N DU should be in renesas-drivers already. [17:47] <jmondi> neg: I was not correct, I changed the pixel clock polarity between 2 reboots, I hardly think that can hang the CPU [17:48] <neg> jmondi: ouch that is bad, I had the impression it always failed on the second capture attempt by bad <jmondi> btw, let's tak it offline, I have nothing else for the meeting <jmondi> neg: no, I made several captures in a row, until I have rebooted the board [17:49] <neg> Yes lets keep talking about that later to not hold everyone up :-) <kbingham> So Shall I post my ABC ... and then that covers the status' :D <neg> kbingham: please do so if you have it handy :-) [17:50] <kbingham> Thursday 10th May <kbingham> <kbingham> A) What I have done since last time <kbingham> - M3-N DU Enablement <kbingham> - Got JTAG working with OpenOCD and Salvator-XS <kbingham> - TLB-Opimise v7,8,9 <kbingham> - DU/Interlaced v3, v4 <kbingham> B) What I will do next <kbingham> - DMA Virtualisation <kbingham> C) Any issues I have currently <kbingham> - None <kbingham> Ahem ... ignore the first line ... [17:51] <kbingham> I'll post that to the ML as a late addition <neg> thanks, I think the last item on the agenda is to pick who will record the MM log into the format pinchartl usually do and make sure it's sent out and recorded in the wiki and what else normaly happens with it [17:52] <kbingham> neg: I think that was supposed to be me - but I'm not certain I have all the scrollback ... [17:53] *** horms (~horms@a80-127-179-77.adsl.xs4all.nl) has quit: Ping timeout: 264 seconds <morimoto> neg: I can put it to wiki [17:54] <morimoto> kbingham: can you create it by using wiki ? <kbingham> morimoto: Sure :) <neg> kbingham: I can email you the full scrollback if you need it [17:55] <kbingham> neg: morimoto: - An e-mail is probably easier thanks