diff options
author | Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> | 2019-12-09 15:29:52 +0900 |
---|---|---|
committer | Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> | 2019-12-09 16:23:07 +0900 |
commit | 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce (patch) | |
tree | 6392fd201a51ff0f6dc0e474803e6f3b20919504 /wiki/Chat_log/20190822-core-chatlog | |
parent | 5d9e1b983faf7645ddc3d45d28e612d2ac4179c0 (diff) |
wiki: Porting wiki: Porting Chat Log
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Diffstat (limited to 'wiki/Chat_log/20190822-core-chatlog')
-rw-r--r-- | wiki/Chat_log/20190822-core-chatlog | 103 |
1 files changed, 103 insertions, 0 deletions
diff --git a/wiki/Chat_log/20190822-core-chatlog b/wiki/Chat_log/20190822-core-chatlog new file mode 100644 index 0000000..ee0387b --- /dev/null +++ b/wiki/Chat_log/20190822-core-chatlog @@ -0,0 +1,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! |