path: root/wiki/Chat_log/20160913-core-chatlog

Core-chat-meeting-2016-09-13

10:03 < geertu> Welcome to the 25th edition of the Renesas Core Group Chat!
10:05 < morimoto> hi
10:05 < geertu> pinchartl will be a few minutes late
10:06 < geertu> dammsan may prefer improving his Japanese?
10:06 < geertu> Today's Agenda:
10:06 < geertu> 1. Status updates
10:06 < geertu> 2. Handling differences between R-Car H3 ES1.x and ES2.0
10:07 < geertu> Topic 1. Status updates
10:07 < geertu>   A) What have I done since last time
10:07 < geertu>   B) What I plan to do till next time
10:07 < geertu>   C) Problems I have currently
10:07 < dammsan> geertu: i'm here!
10:07 < geertu> dammsan: great!
10:07 < geertu> "sort -R" ... (virtual dices are rolling) ...
10:07 < geertu> Niklas!
10:08 < neg> a) implemented drive strength for non-I/O pins on a pin level and it works
10:08 < neg> b) post the patches for drive strength
10:08 < neg> c) Some trouble getting none I/O poins to work on a group level, sh-pfc assumes the pin can be muxed but when that fails for the none I/O pins it bails-out and the configuration is not applied to the group. Is This something we wish to change or should drive-strength for example only be able to set on a pin basis? Looking at the state u-boot leaves the AVB pins not all pins are set to the same
10:08 < neg> drive-strength level.
10:10 < geertu> I don't know. Any RAVB experts around?
10:10 < horms> i have dabbled in ravb but I am not sure about that question
10:11 < horms> you may get some value from talking with sergei, he seems to take particular interest in ravb
10:11 < horms> And he seems to like a quick chat on #renesas-soc
10:12 < geertu> Adding to that, posting a first version as an RFC never hurts, and may attract comments.
10:14 < geertu> Anything else?
10:14 < neg> no I will post a RFC and take it from there, thanks
10:14 < geertu> Thanks Niklas!
10:14 < geertu> Next is me, myself, and I:
10:15 < geertu> A)       - Received and lightly tested M3-W/Salvator-X board, thanks!
10:15 < geertu>       - Reviewed lots of patches to add (DT) support for new boards
10:15 < geertu> B)       - Continue RST, MODEMR, ES-handling, ...
10:15 < geertu>       - 64-bit memory with M3-W Ethernet
10:15 < geertu> C) Nothing
10:15 < geertu> (or perhaps more time and deduplication into Me, Myself, and I)
10:16 < pinchartl> what's the status of MODEMR ?
10:16 < khiemnguyen> good question.
10:16 < geertu> pinchartl: No change
10:17 < geertu> and Stephen Boyd came with the suggestion to use the shiny new nvmem API instead
10:17 < pinchartl> I've seen that
10:17 < pinchartl> I don't like it much
10:17 < geertu> OK, that makes two of us.
10:17 < geertu> Feel free to chime in ;-)
10:17 < pinchartl> especially due to the fact that we have to reference the nvmem DT node around
10:18 < geertu> Even syscon sounded better ;-)
10:19 < geertu> Next is Shimoda-san:
10:19 < shimoda> yes
10:20 < shimoda> A) What have I done since last time
10:20 < shimoda> I'm continue to investigate on Gen3 USB EHCI + IPMMU issue. So, nothing for core.
10:20 < shimoda> B) What I plan to do till next time
10:20 < shimoda> I should describe an explanation of "Lossy" into eLinux...
10:20 < shimoda> C) Problems I have currently
10:20 < shimoda> About core tasks, nothing for now.
10:20 < shimoda> end
10:20 < geertu> Thanks Shimoda-san!
10:20 < geertu> Next is pinchartl:
10:22 < pinchartl> no core task for me
10:22 < pinchartl> and nothing planned
10:22 < geertu> Thanks Laurent!
10:22 < geertu> Next is Simon:
10:22 < pinchartl> I'll need h3 ES2.0 support at some point to develop multimedia-specific features
10:22 < dammsan> pinchartl: can you hook up via google chat and discuss things with me
10:22 < pinchartl> but let's discuss that as part of the second topic
10:23 < pinchartl> dammsan: done
10:23 < pinchartl> (not the discussion, just the connection)
10:23 < dammsan> thanks
10:26 < pinchartl> horms: the stage is yours
10:26 < horms> A) What have I done since last time
10:26 < horms> * Verified Kexec on M3-W
10:26 < horms>   - works fine with v4.8-rc2
10:26 < horms>   - user-space patches edging towards merge
10:26 < horms>   - http://www.elinux.org/Tests:r-car-gen3-kexec
10:26 < horms> * Received and lightly tested M3-W/Salvator-X board, thanks!
10:26 < horms> B) What I plan to do till next time
10:26 < horms> * Finalise Kexec-to-RAM work by documenting hw/sw stack, writing report, etc...
10:26 < horms> C) Problems I have currently
10:27 < horms> * Ethernet integration plan
10:27 < geertu> For C, I think that'll be assigned to me soon, as an additional task incl. 64-bit memory
10:28 < horms> great
10:28 < horms> one more:
10:28 < horms> * SDR50 on Gose SDHI1 - may relate to voltage switching???
10:28 < horms> --- end ---
10:28 < pinchartl> geertu: as far as I know RAVB doesn't have support for 64-bit memory
10:29 < geertu> pinchartl: Cool, so that part is gonna fail. But in the end it should work anyway...
10:30 < horms> my research indicated that almost none of the ip blocks have 64bit support as such
10:30 < horms> so i suppose the ipmmu will become central
10:30 < pinchartl> horms: agreed
10:31 < pinchartl> geertu: it will work with the IPMMU but won't without
10:31 < pinchartl> (after we enable 64-bit memory)
10:31 < geertu> pinchartl: or with bounce buffers...
10:31 < horms> so hopefully the imppu works :^)
10:31 < horms> so hopefully the ipmmu works :^)
10:32 < geertu> Let's see...
10:32 < pinchartl> geertu: ouch. indeed. let's try not to :-)
10:33 < dammsan> geertu: you got my update via email
10:33 < dammsan> basically IPMMU stuff for A) and B)
10:33 < dammsan> need to update the bootloader so that may turn into C) worst case
10:34 < pinchartl> dammsan: have you had time to check the IOMMU patches posted by Sricharan ?
10:34 < geertu> dammsan: How did you know you were next (yes yoy are!), after Simon?
10:35 < geertu> s/yoy/you/
10:35 < geertu> Thanks Simon
10:35 < geertu> Thanks Magnus ;-)
10:36 < geertu> Next is Ul(r)i(ch):
10:36 < uli___> A) Integrated SYS-DMAC on M3-W
10:36 < uli___> B) Test SYS-DMAC integration and post the patches
10:36 < uli___> C) See agenda 2.
10:36 < uli___> plus, for a) m3-w boards works for me, too
10:37 < uli___> for c) the growing stack of boards obscures my view on the monitor
10:37 < uli___> cannot move it because the ethernet cable is too short
10:37 < uli___> i also lost my glasses
10:37 < uli___> life is miserable
10:37 < uli___> that's it
10:37 < geertu> Sorry to hear about your glasses
10:37 < geertu> I can understand you can't extend the Ethernet cable now ;-)
10:38 < uli___> if the sign says, "don't use the water slide with glasses", i recommend to listen :)
10:38 < horms> haha
10:38 < horms> i can send you some ethernet cables if that would cheer you up
10:38 < uli___> thanks, but i'll find something, i'm sure :)
10:38  * geertu has strong glasses, all Ethernet cables are too long
10:40 < geertu> uli: For agenda 2, I guess you mean ES2.0?
10:40 < uli___> i was thinking about distinguishing between ES revisions
10:40 < uli___> is that what this is about?
10:40 < geertu> That's one part of it.
10:41 < geertu> Thanks Ulrich!
10:41 < geertu> next is Morimoto-san:
10:41 < morimoto> A) No Core Task. But Coming out myself to Geert
10:41 < morimoto> B) No plan
10:41 < morimoto> C) No issue
10:41 < morimoto> --end--
10:42 < geertu> morimoto: You were wondering about
10:42 < geertu> Reset,2016-12-31,request,?,Upstreaming and Test
10:42 < geertu> PM,2017-03-31,request,Simon,Upstreaming and Test
10:42 < geertu> ?
10:42 < morimoto> Yes
10:42 < pinchartl> morimoto: congratulataions for your new son :-)
10:42 < geertu> For the former:
10:42 < geertu>   - System reset is handled by PSCI, and works (try typing "reboot")
10:42 < geertu>   - Watchdog reset also works
10:42 < geertu>   - Did you have anything else in mind?
10:42 < morimoto> Is it already upstreamed ?
10:43 < morimoto> pinchartl: thanks. bit son :)
10:43 < morimoto> s/bit/big/
10:44 < geertu> morimoto: Watchdog is in -next, for both h3 and m3-w
10:44 < geertu> morimoto: The rest is standard PSCI, nothing to upstream
10:45 < morimoto> OK, sounds nice. So I will remove "Reset" line from reqest
10:45 < morimoto> How about PM ?
10:45 < geertu> That's s2ram? Simon?
10:46 < khiemnguyen> PM = ?
10:46 < morimoto> s2ram
10:46 < horms> Sorry, what is the question?
10:46 < horms> s2ram status on gen3?
10:47 < morimoto> Yes
10:47 < morimoto> Ahh, this ?generic,2016-08-15,plan,simon,r8a7796 s2ram prototype
10:47 < horms> Suspend and resume seems to function, there are some caveats
10:47 < horms> Magnus describes them as meaning it doesn't work
10:47 < horms> 1. ethavb resume was broken. I believe that has been fixed. neg?
10:48 < horms> 2. The big problem: firmware work around for ddr training causes the system to resume in < 1s
10:48 < khiemnguyen> morimoto: you are mentioned about latest S2RAM in Yocto v2.12.0 ?
10:48 < geertu> horms: yes, ravb resume has been fixed
10:48 < horms> ok, good
10:48 < horms> one less problem
10:48 < horms> i'm unsure what the timeframe is for resolving #2
10:48 < morimoto> OK, I wounder is it listed on "todo" file ?
10:49 < morimoto> as task
10:49 < geertu> morimoto: No, the todo file contains kernel tasks only
10:49 < morimoto> Ahh, OK
10:49 < horms> i think the task would be to co-ordiante with firmware team to get a fix.
10:50 < morimoto> OK, thanks
10:50 < dammsan> horms: yes, thanks!
10:51 < morimoto> horms: should I do something for it ?
10:51 < morimoto> I mean I need to ask to firmware team ?
10:51 < horms> I think we should talk to the firmware team
10:51 < horms> and yes, if you could do that I think that would be great
10:52 < horms> perhaps there is a way to get s2ram working without breaking ddr
10:52 < horms> or perhaps I missunderstand the situation somehow
10:52 < horms> or perhaps magicaally everyething will be prefect somehow :)
10:53 < morimoto> Oops, I remember we need new firmware for it ? I'm not sure
10:53 < morimoto> v2.12.0 I mean
10:53 < horms> Is that a firmware version I could test. e.g. on my shiny m3-w board?
10:54 < horms> Or perhaps its installed on a board that could be used to test
10:54 < horms> really its very easy to reproduce
10:54 < horms> 1. boot stock kernel
10:54 < horms> 2.  echo mem > /sys/power/state
10:54 < horms> 3. wait < 1s
10:55 < horms> If the system wakes up, probably the problem is still there
10:55 < morimoto> Maybe v2.12.0 firmware is needed, but we don't have it at this point
10:55 < horms> ok
10:55 < horms> lets discuss with the firmware team
10:55 < horms> can you do that?
10:55 < morimoto> OK, will do
10:55 < horms> thanks!
10:55 < morimoto> For H3 ? M3 ? both ?
10:56 < horms> both
10:56 < morimoto> OK,
10:58 < khiemnguyen> horms: each driver need to be updated, to backup register context. Otherwise, resume will fail.
10:59 < horms> ok. even drivers that can resume on gen2?
10:59 < geertu> khiemnguyen: Wait, so it is a deeper sleeper than s2ram on Gen2?
11:00 < khiemnguyen> geertu: yes
11:01 < khiemnguyen> at suspended state, the board will shutdown, only power of DDR region will be kept.
11:01 < shimoda> khiemnguyen: is it gen3? not gen2.
11:01 < khiemnguyen> and you need one I2C command to set DDR backup mode, before calling S2RAM.
11:02 < khiemnguyen> It's Gen3.
11:02 < khiemnguyen> ....are we talking about Gen3 ?
11:02 < geertu> khiemnguyen: What does suspend to RAM do now? I thought it did the real suspend, but woke up early due to the need to do something with DDR?
11:03 < horms> thats what i thought
11:03 < geertu> "and you need one I2C command to set DDR backup mode, before calling S2RAM." may be an issue, as AFAIK everything is "handled" in core arm64 code by calling into PSCI.
11:03 < morimoto> khiemnguyen: does your comment based on BSP local implementetion ?
11:04 < khiemnguyen> morimoto: yeah
11:06 < dammsan> [1;5Cit's like upstream first, but not
11:08 < khiemnguyen> morimoto: so, for S2RAM, will we support similar S2RAM mechanism, like in Yocto v2.12.0 ?
11:10 < khiemnguyen> or we just enable S2RAM and fix drivers issues, if any
11:10 < pinchartl> (just FYI, I have to leave at 12:30 EEST sharp)
11:10 < geertu> Ok, let's handle this offline (on periperi ML)
11:10 < geertu> Thanks Morimoto-san!
11:11 < morimoto> geertu: thanks
11:11 < geertu> Next (and final) is Khiem:
11:13 < khiemnguyen> a) No update.
11:13 < khiemnguyen> b) Gen3 CPUFreq (Z clk changing)
11:13 < khiemnguyen> I missed v4.9. Will try v4.10.
11:13 < khiemnguyen> Please comment if any.
11:14 < khiemnguyen> c) My current mail client is Outlook. It's not able to use other email clients for now. under discussion with IT members.
11:14 < khiemnguyen> My last Thermal patches got problem when sending out. Could not see it in patchwork...
11:14 < khiemnguyen> That's all.
11:14 < pinchartl> khiemnguyen: to send patches I recommend git-send-email :-)
11:15 < geertu> khiemnguyen: Can you let git send-email talk to the Exchange server directly through SMTP?
11:15 < pinchartl> geertu: exchange might still rewrite the mail though and replace tabs with spaces
11:15 < khiemnguyen> pinchartl: I will try to discuss with IT. I still have some restrictions in my company. Will try to solve it.
11:16 < khiemnguyen> morimoto: you are using git-send-email, right ?
11:16 < geertu> pinchartl: yes it might (it did at Sony Europe, not Sony US)
11:16 < shimoda> khiemnguyen: i have git-send-email setting. so if you need it, please let me know :)
11:17 < khiemnguyen> shimoda: thanks. Will contact you offline.
11:17 < geertu> Thanks Khiem!
11:17 < shimoda> khiemnguyen: i got it.
11:17 < geertu> Topic 2. Handling differences between R-Car H3 ES1.x and ES2.0
11:18 < morimoto> khiemnguyen: I never use git-send-email: I'm using Emacs+Wounderlust
11:19 < geertu> The plan has been (for a while) to use "-es1" in the compatible value, cfr. "renesas,sata-r8a7790-es1"
11:19 < geertu> Ideally, these would be added automatically to the DTB, by DT fixup code (which is WIP).
11:20 < geertu> For "renesas,sata-r8a7790-es1", this was added manually, I assume?
11:20 < pinchartl> I assume you mean r8a7795-es1 ?
11:20 < geertu> Now, it seems there are several differences between R-Car H3 ES1.x and ES2.0
11:20 < dammsan> geertu: yes, it was an earlier trial for ES handling
11:20 < geertu> pinchartl: We don't have any r8a7795-es1 string yet.
11:21 < geertu> We started with DU and VSP
11:21 < khiemnguyen> geertu: will it be long-term solution ?
11:21 < geertu> Now we start to see differences in CPG/MSSR, PFC, ...
11:22 < geertu> khiemnguyen: In the long term, there will be ES2.0 only?
11:22 < geertu> khiemnguyen: But we may want to keep on using our ES1.x boards
11:23 < geertu> The approach we wanted to take was to focus on the most recent ES ("production") only.
11:23 < pinchartl> on the VSP and DU side there will be non-trivial differences between ES1 and ES2 and we'll need to manually update DT
11:23 < geertu> And try to fixup (preferably at runtime) for running on ES1.x.
11:24 < geertu> So for PFC, it looks like the current pfc-r8a7795 is for ES1.x only
11:24 < geertu> Due to the sheer amount of differences, I think the driver should be renamed to pfc-r8a7795-es1.c
11:25 < geertu> and a new pfc-r8a7795.c for ES2 should be added.
11:25 < neg> for PFC I think that is a good idea
11:25 < geertu> For CPG/MSSR, it's the same.
11:25 < horms> Naming convention asside, i think so too
11:25 < horms> but what if any path is there for forwards compatibility
11:26 < pinchartl> is there any estimate regarding the availability of H3 ES2.0 boards ?
11:26 < geertu> horms: if we have DT fixup, it will automatically be forweard compatible, as the DTS will only have "r8a7795" compatible values.
11:27 < horms> ok
11:27 < horms> got it
11:27 < shimoda> i have a question, how to handle if the number of channels differs between ES1 and ES2?
11:27 < geertu> horms: Only at run-time the "r8a7795-es1" would be added (or changed, for PFC and CPG/MSSR)
11:28 < geertu> shimoda: That was going to be my next point :-)
11:28 < geertu> For Multimedia, the differences seem to be in number of channels (DU) or instances (VSP), and their wiring.
11:28 < pinchartl> yes
11:28 < pinchartl> that will need to be manually changed in DT
11:28 < pinchartl> so if we need an -es1 .dtsi anyway
11:28 < geertu> _Adding_ device nodes in DT fixup code is more difficult than _removing_.
11:29 < pinchartl> is there a point in trying to fixup DT automatically at runtime ?
11:29 < geertu> So having r8a7795.dtsi match the latest revision is problematic.
11:29 < geertu> pinchartl: If it's just the number of channels, it's doable.
11:30 < geertu> If the DU<->VSP topology is too complex, it's different...
11:30 < pinchartl> geertu: it's the DU<->VSP topology that changes
11:30 < pinchartl> the number of DU channels in the same
11:30 < pinchartl> but two of them are served by the same VSP instance
11:30 < dammsan> we can also simply deprecate  ES1.x DU support
11:30 < geertu> pinchartl: oh, the change in the number of DU channels is for H3<->M3-W?
11:31 < geertu> pinchartl: Can you serve the two DU channels by one VSP on ES1 too?
11:31 < geertu> (pinchartl: You have to go?)
11:33 < pinchartl> yes it's for M3
11:33 < pinchartl> and no I can't
11:33 < pinchartl> and yes I have to go :-)
11:33 < pinchartl> sorry
11:33 < pinchartl> I'll read the log later
11:34 < geertu> Is there a document that lists the differences between H3 ES1.0, ES1.x (x > 0), and ES2.0?
11:34 < morimoto> It is difficult to understand pinchartl's yes/no, but it is not my English skill ;P
11:34 < geertu> morimoto: Yes, M3-W has less DU channels than H3
11:35 < morimoto> geertu: let me check
11:35 < horms> s/less/fewer/
11:35 < geertu> morimoto: No, you cannot serve the two DU channels on ES1 using one VSP
11:35 < geertu> horms: Dankuwel
11:36 < morimoto> geertu: thank you for your translation :)
11:36 < horms> geertu: sorry, that correction is hard wired into my brain through bitter experience
11:37 < geertu> uli___: You need ES checks for HDMI?
11:38 < uli___> yes
11:38 < geertu> uli___: Can it be solved through an "es1" compatible value?
11:38 < uli___> i also need to distinguish between 1.0 and 1.1...
11:38 < geertu> ... "es1.0" and "es1.1" compatible values?
11:39 < uli___> that should do
11:39 < geertu> OK, good to know.
11:39 < geertu> So I think dynamic DT fixup can work for most cases, except for DU/VSP topology
11:39 < geertu> Then, Dirk Behme is worried about boot up performance.
11:40 < morimoto> geertu: I think I can get ES diff sheet. I will send it
11:40 < geertu> Fixing DT takes time (to be measured)
11:41 < geertu> Dirk prefers an API to read PRR, and handle upon that
11:42 < geertu> Or we can use soc_device_register() (see include/linux/sys_soc.h)
11:43 < geertu> Arnd posted a patch to add soc_device_match(), which can match against SoC-specific revision wildcards.
11:44 < geertu> But I take it all of you are slowing falling asleep? ;-)
11:44 < uli___> to me, that sounds better than the other approaches discussed so far
11:45 < geertu> Which one sounds better? PRR API? soc_device_match()?
11:45 < uli___> the latter
11:46 < geertu> We may still need DT fixup for backwards compatibility (add RST and APMU device nodes)
11:46 < shimoda> i didn't know the drivers/base/soc.c, and it seems very simple
11:46 < geertu> and I had a wild idea of using DT fixup to add all SoC-specific compatible values, so we can share more .dtsi
11:47 < uli___> as for the boot-up delay, what order of magnitude are we talking here?
11:48 < geertu> To be measured...
11:49 < uli___> ah, ok
11:49 < geertu> It also depends at which phase of the boot we do it.
11:49 < dammsan> i just don't want to add a new special API that we are the only users of
11:49 < geertu> For APMU devices nodes, it needs to be done right after unflatten, which is before we have kmalloc() :-(
11:51 < dammsan> soc_device_match() may not be so bad
11:51 < geertu> dammsan: So you also like nvmem API for MODEMR?
11:51 < dammsan> not so much
11:51 < dammsan> i just dislike the PRR proposal by Dirk
11:51 < dammsan> it is like looking at vxworks code
11:52 < dammsan> it also goes against being standard
11:52 < neg> I'm a bit scared of DT fixups, but trust your judgemnt that it won't eat my dog :-)
11:52 < dammsan> and following simple accepted APIs
11:52 < geertu> Bonus is you will get the ES version somewhere in /proc or /sys ;-)
11:52 < dammsan> also, if DT is so slow, why don't we have any numbers yet?
11:52 < dammsan> hehe
11:53 < geertu> dammsan: Nobody does DT fixup
11:53 < dammsan> i know
11:53 < dammsan> but at least proposing a general purpose way of doing things
11:53 < dammsan> is much better than cooking up your local API just to be used by a couple hidden away drivers
11:54 < geertu> OK, will try the soc_device_match() thingy
11:54 < dammsan> so i think it is great that you are proposing the DT fixups
11:54 < dammsan> or whichever new standard you are proposing
11:54 < dammsan> as long it is not specific to our SoC
11:55 < dammsan> looking forward to see your proposal
11:56 < geertu> If we don't do DT fixup for ESx.y, we will keep single pfc-r8a7795 and r8a7795-cpg-mssr drivers that do their own ES check through soc_device_match()?
11:59 < horms> I'm unclear on what soc_device_match() would match on
12:00 < geertu> On the revision string in include/linux/sys_soc.h:soc_device_attribute
12:01 < shimoda> I'm afraid again but how to handle the number of channels differs by soc_device_match() API?
12:02 < shimoda> for example, es1.1: usb3 2ch, usb2 3ch --> es2.0: usb3 1ch, usb2 4ch
12:02 < geertu> shimoda: For those things we need a different solution
12:02 < geertu> H3 ES2.0 is really a different SoC
12:03 < shimoda> geertu: i understood it. thanks!
12:05 < geertu> Guys, I'm not gonna hold you from whatever any more.
12:05 < geertu> Thanks for joining the 25th edition!
12:05 < horms> thanks, look forward to the 26th!
12:05 < neg> thanks all
12:06 < uli___> bye
12:06 < neg> geertu: I was a bit confused by this meeting inviation. Do you want a summary of the A), B) and C) items in the mail or just updates to periperi lit items?
12:07 -!- horms [~horms@217.111.208.18] has quit [Read error: Connection reset by peer]
12:07 < geertu> neg: Just updates to the todos, like Wolfram commented a while ago ;)
12:07 -!- horms [~horms@217.111.208.18] has joined #periperi
12:11 < shimoda> thanks all! bye!
12:11 -!- shimoda [~shimoda@relprex1.renesas.com] has quit [Quit: WeeChat 0.4.2]
12:12 < morimoto> geertu: Can we have this discussion (= how to handle ES version) on ELCE timing ?
12:13 < geertu> morimoto: Sure
12:13 < morimoto> Thanks
12:13 < morimoto> I added its page on
12:13 < morimoto> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Miniperi-2016-10
12:13 < geertu> Thanks
12:14 < morimoto> Bye