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!