summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20190822-core-chatlog
diff options
context:
space:
mode:
authorKuninori Morimoto <kuninori.morimoto.gx@renesas.com>2019-12-09 15:29:52 +0900
committerKuninori Morimoto <kuninori.morimoto.gx@renesas.com>2019-12-09 16:23:07 +0900
commit55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce (patch)
tree6392fd201a51ff0f6dc0e474803e6f3b20919504 /wiki/Chat_log/20190822-core-chatlog
parent5d9e1b983faf7645ddc3d45d28e612d2ac4179c0 (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-chatlog103
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!