Merge remote-tracking branch 'gitlab/wiki' into HEAD

1 files changed, 173 insertions, 0 deletions

diff --git a/wiki/Chat_log/20180726-core-chatlog b/wiki/Chat_log/20180726-core-chatlog
new file mode 100644
index 0000000..c880f55
--- /dev/null
+++ b/wiki/Chat_log/20180726-core-chatlog
@@ -0,0 +1,173 @@
+Core-chat-meeting-2018-07-26
+
+09:32 < geertu> Welcome to today's Core Group Chat Meeting!
+09:33 < geertu> Agenda:
+09:33 < geertu> 1. Status Updates
+09:33 < geertu> 2. Discussion Topics
+09:33 < geertu> Topic 1. Status updates
+09:33 < geertu> A) What have we done since last time:
+09:33 < geertu> Marek studied PCIe errate.
+09:33 < geertu> Morimoto-san worked on PeriJect.
+09:33 < geertu> Niklas provided a fix for the V3M PFC crash for the stable tree.
+09:33 < geertu> Shimoda-san investigated and fixed rcar-dmac issues, submmited an R-Car
+09:33 < geertu> E3 USB3 host DTS node patch, and asked the HW team about V3H EXTAL
+09:33 < geertu> value.
+09:33 < geertu> Geert implemented rcar-gpio get_direction(), added author signoff
+09:33 < geertu> checking to checkpatch, got bd9571mwv toggle power switch support
+09:33 < geertu> accepted, made SATA device-passthrough for virtualization work, and
+09:33 < geertu> reworked the R-Car gen3 OSC and RCLK improvements.
+09:34 < geertu> B) What we plan to do till next time:
+09:34 < geertu> Marek will work on U-Boot (SPL-alike replacement for Minimon) and
+09:34 < geertu> OpenOCD for Gen3.
+09:34 < geertu> Morimoto-san will add HTML support to PeriJect.
+09:34 < geertu> Shimoda-san will pave the way forward for IPMMU.
+09:34 < geertu> Geert plans to submit v2 of the R-Car gen3 OSC and RCLK improvements,
+09:34 < geertu> work on LTSI sub-maintainership, and look into GPIO paravirtualization,
+09:34 < geertu> and SYSC and PFC errata.
+09:35 < geertu> C) Problems we have currently:
+09:35 < geertu> Marek is suffering from the European heat wave.
+09:35 < geertu> Morimoto-san wonders if PeriJect is good enough to use, and how to
+09:35 < geertu> migrate from periupport and peripelist.
+09:35 < geertu> Ulrich has been suffering flaky Internet for weeks.
+09:35 < geertu> Anything I missed?
+09:35 < geertu> Ah, Simon just sent his report
+09:36 < geertu> Kaneko-san posted M3-N CPUFreq upport, and will test it.
+09:37 < horms> On the Kaneko-san front. Main task is to get him hooked up to Magnus's lab. Second task is to address missing patches he reported in his backports. I'm assuming these tasks fall to me.
+09:37 < horms> Missing patches are only in backports he hasn't posted :)
+09:38 < horms> Sorry once again for the late report.
+09:39 < geertu> horms: Havw you tried contacting Olof privately?
+09:40 < horms> I am considering it after the most recent wave of feedback.
+09:40 < horms> I think he is conciously or otherwise trying to tweak the realationship between himself and us (and possibly other downstreams too)
+09:40 < horms> It might help to understand why that is happening.
+09:41 < horms> e.g. he is unhappy about something; Linus is unhappy about something; he has assumed more control over ARM SoC, ...
+09:42 < horms> Feedback from the team is of coruse welcome as I see my role mainly as an intermedeary
+09:42 < wsa_> TBH I didn't notice much of that, except his wish to aquash patches more
+09:42 < geertu> Most other pull requests seem to be answered with "Merged, thanks"
+09:42 < wsa_> squash
+09:43 < wsa_> and i do understand that
+09:43 < horms> So the thing is. I don't mind if we tweak our processes and that works better for everyone.
+09:43 < Marex> horms: you think Linus is pushing on Ojn ?
+09:43 < horms> Squashing may be in that category, but its a bit too early to say
+09:44 < Marex> horms: ah, forget what I said ...
+09:44 < horms> But I don't want Renesas to become some sort of punching bag
+09:44 < horms> Marex: I think is possible
+09:44 < horms> Its also possible that I am blowing things out of proportions
+09:44 < wsa_> horms: i surely agree on not being a punching bag :)
+09:44 < Marex> horms: please ask him what's this about, being forced to drop patches is really sad
+09:45 < horms> And his requests can be distilled into 3 categories each of which are reasonable(ish)
+09:45 < horms> 1) sqaush 2) shorter changelogs (Arnd liked longer ones) 3) specific opinions on some specific patches
+09:45 < wsa_> does renesas add more SoCs than other vendors these days?
+09:46 < horms> But perhaps there is little harm in simply asking him privately
+09:46 < horms> wsa_: maybe. It certainly has a lot upstream
+09:46 < kbingham> horms, Is olof changing your tags, and thus breaking your signatures? (/me grabs popcorn to read Olof's replies)
+09:46 < wsa_> yes
+09:47 < geertu> Renesas is pumping out SoCs at 2 SoCs/kernel release these days
+09:47 < geertu> Anyway, let's continue
+09:47 < geertu> Topic 2. Discussion Topics
+09:47 < geertu> RZ/G2 compatible values
+09:47  * wsa_ still recalls Arnd at last ELCE mentioning Renesas at second place when asked about vendors having good upstream support
+09:48 < geertu> Chris Patterson just asked about this, and he would like to join our discussion. Is that OK?
+09:48 < pinchartl> wsa_: who was first ?
+09:48 < wsa_> with Atmel being 1st, but all agreed they have more simple chips in the first place :)
+09:49 < wsa_> I think GPUs were excluded in that discussion :/
+09:49 -!- patersonc [c18ddb24@gateway/web/freenode/ip.193.141.219.36] has joined #periperi
+09:49 < patersonc> Mornin
+09:49 < geertu> Welcome chris
+09:49 < wsa_> Hi Chris!
+09:50 < kbingham> Hola :)
+09:50 < Marex> Hey
+09:50 < geertu> Some of you may have met Chris. He's working on RZ/G.
+09:50 < horms> Hi Chris
+09:50 < uli___> hi
+09:50 < geertu> So the first SoC they're upstreaming support for is RZ/G2M aka R8A774A1
+09:50 < neg> patersonc: hi :-)
+09:51 < geertu> using compatible value "renesas,r8a774a1"
+09:51 < geertu> But more are to follow, cfr. the email I sent to the mailing list.
+09:52 < patersonc> Fun times
+09:52 < geertu> Recently, we started using 5 digits in compatible values, even if the last one is a zero (e.g. r8a77970)
+09:53 < geertu> However, there will also be an RZ/G2M variant R8A774A0
+09:53  * jmondi would bribe patersonc to get an iWave board :p
+09:53 < geertu> AFAIC it would be identical, except for the lack of HDMI
+09:54 < geertu> Of course I'd like to avoid having both "renesas,r8a774a1" and ""renesas,r8a774a0" compatible values.
+09:54 < patersonc> jmondi: depends on what you want to do with it ;)
+09:55 < geertu> We could settle on "renesas,r8a774a", but then there's the risk there will be a comnpletely differeny R8A774A5 later (cfr. M3-W and M3-N)
+09:55 < geertu> s/comnpletely differeny/completely different/
+09:56 < horms> I think that this is not very different to the problem we have faced in the past
+09:56 < geertu> Does anyone have an opinion about this?
+09:56 < wsa_> I gotta run
+09:56 < horms> And the solution has essetntially been that new compat values are cheap
+09:56 < wsa_> cya guys
+09:56 < geertu> wsa_: Bye!
+09:57 -!- wsa_ [~wsa@p5099505f.dip0.t-ipconnect.de] has quit [Quit: ...]
+09:57 < horms> And the cost of finding ourselves painted into a corner would be unbearable
+09:57 < geertu> "cheap" as in lot's of DT binding doc updates?
+09:57 < kbingham> is it bad to have "renesas,r8a774a" and "renesas,r8a774a5" ?
+09:57 < horms> Yes, that has essetntially been the possition for some time now
+09:57 < geertu> patersonc: R8A774A1 and R8A774A0 would really be the same die?
+09:58 < patersonc> I would assume so. Just the HDMI IP disabled
+09:58 < patersonc> For licencing reasons
+09:58 < horms> Ok, so we could have an extra .dsti file that did disabled/removed that node?
+09:58 < geertu> Then using "renesas,r8a774a1" for R8A774A0, too, would be acceptable, as it conforms to the original meaning of compatible values
+09:59 < geertu> horms: The HDMI node would not be instantiated unless someone changes its status to "okay" in the board DTS
+10:00 < horms> ack
+10:00 < horms> Perhaps that is an easy way out in this case
+10:00 < pinchartl> patersonc: does "HDMI IP disabled" really mean disabled ? or will it work if someone tries to use it ?
+10:00 < patersonc> Would we use both r8a774a* compatible strings in r8a774a1.dtsi?
+10:00 < geertu> It would only be an issue if someone plugs an A0 SoC into a board designed for an A1 (assumed they'll be pin compatible)
+10:00 < horms> kbingham: I think that is not bad but at the same time it would be confusing -> not particularly good
+10:01 < patersonc> pinchartl: I would hope they would blow an efuse for HDMI, so it won't be usable
+10:01 < kbingham> horms, Ack.
+10:01 < geertu> patersonc: No, just "renesas,r8a774a1" (and "renesas,*rcar-gen3*" as fallback for individual IP cores where appropriate, cfr. RZ/G1)
+10:01 < patersonc> Okay
+10:02 < horms> geertu: I think that is fine if we are satisfied that these two SoCs really are compatibile. That seems to be the case from what Chris is saying
+10:02 < geertu> horms: Agreed
+10:02 < patersonc> That's the information I have!
+10:02 < horms> A lot of this thining regarding compat values goes back to a time when we could not tell if hw A was really compatibile with B or not
+10:03 < horms> geertu: ok, so assuming that is settled. are there other related compat valeues to discuss
+10:03 < pinchartl> horms: I agree with you
+10:03 < patersonc> Given that they aren't creating a new device anyway (using R-Car), I doubt they are going to create a new device just to remove the HDMI IF ;)
+10:04 < geertu> patersonc: Will they blow eFuses for the other "removed" devices?
+10:04 < patersonc> geertu that would be my assumption
+10:04 < geertu> Did they actually do that on RZ/G1?
+10:04 < patersonc> As far as I understand it, yet
+10:04 < patersonc> yes *
+10:04 < geertu> OK.
+10:04 < patersonc> The whole point was to save on costs
+10:05 < geertu> So let's go for "renesas,r8a774a1".
+10:05 < geertu> patersonc: Thanks for joining, Chris!
+10:05 < patersonc> Thank you all!
+10:05 < horms> This sounds like a good option: It leaves us room to move in future. And solves the curent problem.
+10:06 < patersonc> You can ack Biju's patches now ;)
+10:06 < geertu> patersonc: Sure. Will do.
+10:06 < horms> Are you sure you don't also want to document "renesas,r8a774a2"?
+10:06 < patersonc> horms you mean a0?
+10:06 < horms> I guess there is no point unless its also used in a .dtsi
+10:06 < horms> yes, sorry, my bad
+10:07 < horms> and we seem to now want an extra .dtsi at this point
+10:07 < geertu> Perhaps at the highest SoC level (DT root node)?
+10:07 < horms> I'm just thinking in terms of freedom to move if we need to
+10:07 < horms> But perhaps I need to just accept that the hw is the same
+10:07 < patersonc> We could document a0 (and all the others), but I'm not sure I'll ever actually get hold of an a0 device. They will just go straight to customers. Only a1 will be used on the reference hardware.
+10:07 < geertu> We don't have r8a77951 for H3 ES2+ neither
+10:08 < horms> True. I was pondering the similarities between this problem and R-Car Gen 3 ES versions.
+10:08 < patersonc> At least with RZ/G we shouldn't have lots of ES versions
+10:08 < patersonc> (famous last words)
+10:09 < horms> Ok, so we think the hw is compatible
+10:09 < horms> with good reason.
+10:09 < horms> It might change, f.e. with a new ES versinos
+10:09 < horms> But we don't have a good way to deal with that
+10:09 < horms> And as a bonus we think its unlikely
+10:10 < horms> So the simple solution of just documenting and using "renesas,r8a774a1" seems sufficiently safe
+10:10 < horms> Is that about where we are?
+10:10 < geertu> In hindsight, probably we should have made H3 ES1.0 a different SoC, and thus used r8a77951 for H3 ES2+
+10:10 < patersonc> Sounds good to me horms
+10:11 < geertu> Agreed
+10:11 < horms> geertu: true. I guess my only question is if we should learn from that mistake at this time
+10:11 < geertu> horms: Well, most ES increments are small fixed
+10:12 < patersonc> I'm sorry but I have to go to the doctors. I'll be back in a couple of hours. Thank you all for your time!
+10:12 < geertu> patersonc: Thx, CU, and take care!
+10:12 < geertu> Any other topic to discuss for the regular core meeting?
+10:14 < horms> I also need to leave soon as someone is coming to inspect my current home
+10:14 < horms> patersonc, all: thanks for the good conversation on this topic
+10:14 < geertu> So I think we're done.
+10:14 < geertu> Thanks for joining, and have a nice continued day!