summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20170314-core-chatlog
diff options
context:
space:
mode:
Diffstat (limited to 'wiki/Chat_log/20170314-core-chatlog')
-rw-r--r--wiki/Chat_log/20170314-core-chatlog260
1 files changed, 260 insertions, 0 deletions
diff --git a/wiki/Chat_log/20170314-core-chatlog b/wiki/Chat_log/20170314-core-chatlog
new file mode 100644
index 0000000..0fa0d86
--- /dev/null
+++ b/wiki/Chat_log/20170314-core-chatlog
@@ -0,0 +1,260 @@
+Core-chat-meeting-2017-03-14
+
+09:20 < geertu> Welcome to today's Renesas Core Group Chat (\pi-day Edition)
+09:20 < geertu> Agenda:
+09:20 < geertu> 1. Status updates
+09:20 < geertu> 2. Additional tasks for 2017/Q2 phase 1
+09:20 < geertu> Topic 1. Status updates
+09:20 < geertu> A) What have I done since last time
+09:20 < geertu> B) What I plan to do till next time
+09:20 < geertu> C) Problems I have currently
+09:20 < geertu> D) Posted/Accepted bugfix patches
+09:21 < geertu> Shimoda-san is first
+09:21 < shimoda> yes
+09:21 < shimoda> A)
+09:21 < shimoda> - In last month, I reported about SYS-DMAC descriptor mode on-chip RAM support.
+09:21 < shimoda> But, I should have reported it in detail.
+09:21 < shimoda> - The HW restriction is we cannot use "Built-in memory is used" mode (= DMADPBASE_n.SEL = 0)
+09:21 < shimoda> - We can use its own descriptor memory via DMADPBASE_n.SEL = 1 with DPBASE[31:4].
+09:21 < shimoda> - I tried new IPMMU patch set. And, it could boot correctly. (Magnus-san, Thank you!)
+09:21 < shimoda> - The patch sets seem update later, I will make a workaround patch for SDHI after new patch sets are submitted.
+09:21 < shimoda> B)
+09:21 < shimoda> - After new patch sets of IPMMU are available, I will make a workaround patch.
+09:21 < shimoda> C)
+09:21 < shimoda> - Nothing for core.
+09:21 < shimoda> D)
+09:21 < shimoda> - Nothing for core.
+09:21 < shimoda> -- EOT --
+09:22 < geertu> shimoda: What does "its own descriptor memory" mean? How does it differ from "Built-in memory"?
+09:22 < shimoda> geertu: oops, it mean the same as its own descriptor memory and Built-in memory
+09:24 < shimoda> if we would like to use SYS-DMAC0's built-in memory,
+09:24 < geertu> shimoda: The documentation for DMADPBASE_n.SEL says "0: Setting Prohibited"
+09:25 < geertu> Ah, only for Gen3. For Gen2 the bit chooses betwen Built-in and external memory
+09:25 < shimoda> geertu: ahh, that's correct, I looked old doc (rev.0.50) X(
+09:26 < geertu> s/betwen/between/
+09:26 < shimoda> rev.0.53 is avoiding the restriction :)
+09:27 < shimoda> geertu: For gen2, I heard it has the same issue
+09:27 < shimoda> with gen3
+09:27 < shimoda> Maybe for gen2, hardware team will issue errata info??
+09:28 < shimoda> i will confirm it (for gen2's tu)
+09:28 < geertu> OK, thx
+09:28 < shimoda> s/tu/errata info/
+09:29 < geertu> Thank you, Shimoda-san
+09:29 < geertu> Next is Niklas
+09:29 < neg> A) Nothing for Core
+09:29 < neg> B) Pickup core task(s) as part of base, suggestions on whats needed is welcome. What I can think of at the top of my head
+09:29 < neg> - Pickup work on Magnus 'dmaengine: rcar-dmac: Priority and slow mode prototypes' series, Magnus once told me he might want me to do that not sure about how he feels today.
+09:29 < neg> - Implement synchronize() for rcar-dmac for https://patchwork.kernel.org/patch/9557691/
+09:29 < neg> C) None
+09:29 < neg> D) None
+09:29 < neg> EOT
+09:30 < dammsan> neg: i think we should wait for feedback from Laurent
+09:30 < neg> sounds like a good idea
+09:30 < geertu> Laurent is away for the next 10 days
+09:31 < geertu> synchronize() is definitely a good thing to do
+09:31 < geertu> Thanks Niklas
+09:31 < geertu> Next is Morimoto-san
+09:32 < morimoto> OK
+09:32 < morimoto> A) What have I done since last time:
+09:32 < morimoto> - posted SYS-DMAC 40bit + Descriptor mode patch (no response)
+09:32 < morimoto> - posted video logo init syscall exchange patch (no response)
+09:32 < morimoto> B) What I plan to do till next time:
+09:32 < morimoto> - follow above 2 patches
+09:32 < morimoto> C) Problems I have currently:
+09:32 < morimoto> - No problems
+09:32 < morimoto> D) Posted/Accepted bugfix patches:
+09:32 < morimoto> - No patches
+09:32 < morimoto> X) Question from me
+09:32 < morimoto> - could you receive new 0.51/0.52/0.53 datasheet ?
+09:32 < morimoto> - 0.52 seems have both ES1.x and ES2.0
+09:32 < morimoto>
+09:32 < morimoto> --EOF--
+09:33 < geertu> morimoto: I've downloaded the files, but haven't verified them, or looked at the contents
+09:33 < geertu> morimoto: Thanks a lot!
+09:33 < dammsan> morimoto: i will redistribute later today
+09:33 < morimoto> OK, nice to know !
+09:34 < morimoto> Basically 0.52 is for ES2.0, but it has ES1.x folder
+09:34 < morimoto> I don't know why
+09:36 < geertu> morimoto: Perhaps 0.51 is for H3 ES1.0? And 0.52 is for H3 ES1.x?
+09:36 * geertu sha256sum OK
+09:36 < morimoto> My understanding is that 0.51 is for ES1.x, 0.52 and later is for ES2.0
+09:36 < morimoto> shimoda: my understanding is correct ?
+09:37 < shimoda> morimoto: yes.
+09:38 < geertu> So 0.52 is not useful, as it's superceded for H3 ES2.0 and M3-W ES1.1 by 0.53?
+09:39 < geertu> And which one is for H3 ES1.0? rev. 0.20? ;-)
+09:40 < morimoto> Actually, 0.52 was updated in these days, and we don't know what happen on it :(
+09:41 < morimoto> 1st version to 0.51 was for ES1.x
+09:41 < morimoto> If my understanding was correct
+09:42 < morimoto> geertu: you question is which is for ES1.0, and which is ES1.x ?
+09:42 < morimoto> But in our understanding, datasheet has no difference for ES1.x
+09:42 < geertu> morimoto: yes. OK.
+09:43 < shimoda> according to the manual team's redmine, rev.0.50 is H3 ES1.1. 0.51 is M3. 0.52 is V3M. 0.53 is V3H. and 0.54 (will be released on end of Apr) is M3N, D3 and E3
+09:44 < geertu> OK, thx
+09:45 < geertu> Thank you, Morimoto-san
+09:45 < geertu> Next is Magnus
+09:49 < dammsan> ok, i've been working on IPMMU and DMAC, nothing else to report =)
+09:49 < geertu> Thanks, Magnus
+09:49 < geertu> Next is Jacopo
+09:50 < jmondi> here I am, so..
+09:50 < jmondi> A) Nothing: no core work since last time we met
+09:50 < jmondi> B) I have now received a considerable amount of reviews on RZ/A1 pin controller, I will send v2 possibily this week
+09:51 < jmondi> C) not really a task, but I still have to work on Peach, and I'm waiting for digikey to deliver me some stuff
+09:51 < jmondi> D) none
+09:51 < jmondi> --- eot ---
+09:51 < geertu> Thank you, Jacopo
+09:52 < geertu> Next is Geert
+09:52 < geertu> A) What have I done since last time
+09:52 < geertu> - v2 of R-Car H3 ES2.0 support (clk/pfc/sysc)
+09:52 < geertu> - v2 of INTC-SYS clock addition
+09:52 < geertu> - v2 of R-Car M3-W secondary CPU
+09:52 < geertu> - v5 of DMA_ATTR_FORCE_CONTIGUOUS
+09:52 < geertu> - DT binding update to add resets to rcar-du
+09:52 < geertu> - DT binding and identification of RZ/G1H and RZ/G1N
+09:52 < geertu> - Posted "long story" summary for Suspend-to-Idle to periperi
+09:52 < geertu> - DT cleanups
+09:52 < geertu> B) What I plan to do till next time
+09:52 < geertu> - v2 of resets for R-Car H3 and M3-W DTS
+09:52 < geertu> C) Problems I have currently
+09:52 < geertu> - None
+09:52 < geertu> D) Posted/Accepted bugfix patches
+09:52 < geertu> - Nothing important
+09:52 < geertu> EOT
+09:53 < geertu> laurent and Marek are excused, Ulrich and Simon are absent, so no updates from them
+09:53 < geertu> Topic 2. Additional tasks for 2017/Q2 phase 1
+09:54 < geertu> What's important? What do we want to do next?
+09:54 < geertu> Who's interested in doing some core work?
+09:55 < neg> I'm interested in core work :-)
+09:55 < geertu> So far I haven't received new requests from other groups (I/O, MultiMedia)
+09:55 < jmondi> I will defintely need some core work after April, yes
+09:55 < dammsan> geertu: i think we should continue to improve the SYS-DMAC driver with priority support and such
+09:55 < dammsan> it may require more deeper investigation to make sure RX is prioritized over TX
+09:56 < dammsan> and then there is PM for a whole bunch of drivers
+09:56 < geertu> neg: Want to do "RCAR-DMAC,?,noplan,?,Add transfer termination synchronization"
+09:56 < geertu> ?
+09:56 -!- horms [~horms@penelope.horms.nl] has joined #periperi
+09:56 < geertu> Hi SImon
+09:57 < geertu> I guess I confused you with my silly CEST email?
+09:57 < horms> Sorry, I got the updated time. But I had shuffled another appointment into the 9am slot (to free up 10am)
+09:57 < neg> geertu: I need to lookin to exactly what that is, but sure I be more than happy to look into it
+09:58 < horms> I should also have realised we are not in CEST for another 12 days :)
+09:58 < dammsan> geertu: the versaclock driver that marek wrote may need an update
+09:58 < horms> and i see my email is stuck on my laptop
+09:58 < geertu> dammsan: Ah, what's missing?
+09:58 < dammsan> geertu: apparently the versaclock part number is changing when salvator-xs board will be introduced
+09:59 < geertu> dammsan: Do you know the new part number?
+09:59 < dammsan> geertu: no, but I think Morimoto-san and/or Shimoda-san knows
+10:00 < dammsan> never mind i found it in an old weekly report
+10:01 < dammsan> apparently current board is using 5P49V5923A
+10:01 < dammsan> new board will be using 5P49V6901A
+10:02 < dammsan> so we want to make sure the driver supports that chip
+10:03 < geertu> Ah, that's a VersaClock 6
+10:03 < dammsan> oh...
+10:03 < dammsan> good that we start early then
+10:03 < geertu> To be seen how much different that is
+10:04 < dammsan> for sure
+10:04 < dammsan> then there is PMIC with all that means
+10:04 < geertu> Could be just a two line change, or a completely new and different driver
+10:04 < dammsan> indeed
+10:05 < dammsan> do we have upstream driver support for PMIC on Gen2 boards?
+10:06 < dammsan> if not then we can perhaps do that in parallel with PMIC on Gen3
+10:07 < shimoda> about PMIC on Gen2 board, I think it already finished
+10:08 < shimoda> commit ids = 46dd8a809effdc7ebe6ec760e3e421d5ac2a40f1 and a6b422664597d7b9ca6cf441bc48cfe1a707cd3a
+10:08 < geertu> There are upstream drivers for da9063 and da9210, but we only have regulator properties in DT for da9210
+10:09 < geertu> Those commits are the da9063 nodes, used for system restart only
+10:10 < geertu> commit 1d41f36a68c0f4e9b01d563ce33bab5201858b54 is for da9210 with dvfs
+10:10 < dammsan> i highly doubt that all gen2 boards have the same status
+10:11 < dammsan> including gose/alt/blanche
+10:11 < geertu> Only Lager and Koelsch have the da9210 in DT
+10:12 < dammsan> seems we have some stuff to do then =)
+10:12 < shimoda> how about DTS sharing?
+10:12 < dammsan> also perhaps internal watchdog workaround is needed
+10:13 < dammsan> shimoda: good idea
+10:13 < geertu> Like "generic,?,noplan,?,DTS sharing on H3 ES1.x/ES2.0, Salvator-X/ULCB
+10:13 < geertu> "?
+10:13 < shimoda> geertu: i meant yes
+10:14 < geertu> "internal watchdog workaround"?
+10:14 < dammsan> geertu: eventually i think we should consider virtualisation and perhaps extend virtio with dmaengine support
+10:15 * geertu added "generic,?,noplan,?,VersaClock 5P49V6901A clock generator driver"
+10:15 * geertu added "Gen2,?,noplan,?,Uniform PMIC support on all boards"
+10:15 < dammsan> geertu: yeah about internal watchdog, i've heard some gen2 use case for soc without external pmic reset exists
+10:16 < dammsan> so it may be time to start untangling the mess also known as gen2 reset handling
+10:16 < geertu> DTS sharing means we'll become less conservative: when adding new features to one board/SoC combo, it'll appear on other combos, too
+10:16 < shimoda> about gen2 watchdog to reset, just bsp team has a trouble :)
+10:16 < geertu> dammsan: I can imagine the use case exists ;-)
+10:17 < dammsan> shimoda: but last time i checked watchdog reset on gen2 is filled with errata issues
+10:17 < shimoda> gen2 has CA15BAR and it doesn't reset by WDT X(
+10:17 < dammsan> right there you go
+10:18 < shimoda> dammsan: i don't know about the errata. I will ask BSP team
+10:18 < dammsan> another topic for virtualization can be getting KVM going with a paravirtualized guest
+10:18 < shimoda> later
+10:18 < dammsan> shimoda: thanks
+10:20 < dammsan> geertu: if anyone want to hack PSCI code then fixing the high power consumption in the firmware would be great
+10:21 < dammsan> geertu: for the power off case that you kindly pointed out
+10:22 < geertu> 5P49V6901A looks very similar to 5P49V5923A
+10:24 < geertu> dammsan: According to the latest list of areas covered by the Core group, PSCI is not on the list ;-)
+10:24 < dammsan> geertu: ok lets wait and see what marek says
+10:24 < geertu> Anyway, someone may like to play with it ...
+10:24 < dammsan> geertu: the psci stuff needs to be coordinated with internal renesas team to avoid duplication
+10:25 * geertu added PSCI,?,noplan,?,Reduce power consumption in suspend/poweroff states
+10:25 < geertu> Surew
+10:25 < geertu> s/Surew/Sure/
+10:25 < dammsan> thanks
+10:26 < geertu> horms: So we skipped your status update, but you did send it to the list. Want to duplicate it here?
+10:27 < horms> Sure
+10:27 < horms> Task update: none
+10:27 < horms> A) No activity (no core tasks)
+10:27 < horms> B) None
+10:27 < horms> B) No problems
+10:27 < horms> D) No fixes posted/queued up
+10:27 < horms> Fwiw, I have been working on LTSI-4.9 backports (an add-on task for this quarter I asked to be canceled due to illness)
+10:28 < horms> I also plan to address the integration tasks which were similarly cancelled
+10:28 < horms> but perhaps not until next month
+10:29 < geertu> Thanks Simon
+10:31 < geertu> http://www.digikey.be/product-detail/en/idt-integrated-device-technology-inc/EVKVC6-6901ALL/800-3138-ND/5419197
+10:31 < geertu> bit more expensive (175€) than the VC5 counterpart
+10:31 < geertu> I guess we can sort out the (wild list of) additional tasks on periperi ML?
+10:32 < geertu> Is there anything else you want to discuss, tell, ask?
+10:32 < horms> I'd day the hexagonal form factor is worth the extra money
+10:32 < dammsan> nothing from me!
+10:33 < geertu> It's a rare item: out-of-stock, lead time 18 weeks...
+10:33 < horms> octagonal even!
+10:34 < geertu> What's the lead time of Salvator-XS?
+10:34 < shimoda> maybe mid May...
+10:34 < geertu> That's less than 18 weeks
+10:35 < geertu> Let's finish.
+10:35 < geertu> Oh, one thing.
+10:35 < geertu> Shall we reduce core group chat frequency to 1/month, like for I/O?
+10:36 < geertu> Or keep 1/fortnight?
+10:36 < neg> I like the 1/fortnight
+10:37 < neg> but if it creates much overhead for you I'm open to change it :-)
+10:37 < geertu> I don't mind. It just depends on the amount of work that's done/todo
+10:38 < geertu> Let's keep next meeting at March 28, OK?
+10:38 < neg> Yes
+10:38 < geertu> Thanks for joining, and have a nice continued day!
+10:38 < shimoda> yes. i booked it
+10:39 < neg> thanks all
+10:39 < morimoto> I have MultiMedia cat meeting on March 28
+10:39 < morimoto> I'm soory
+10:39 < morimoto> s/soory/sorry
+10:39 < geertu> Really?
+10:40 < geertu> Ah, Laurent will have the meeting in Winter Time
+10:40 < neg> Ahh me too, I thought we would do the two meetings one day thing :-)
+10:40 < dammsan> right, collides with m/m
+10:40 < geertu> So we can have it in Summer Time, i.e. one hour later ;-)
+10:41 < geertu> Unfortunately the Tokyo side will have two parallel meetings, as they don't do Daylight Savings Time ;-)
+10:41 < dammsan> geertu: at that time, shall we aim at having titles for the additional tasks fixed?
+10:41 < geertu> dammsan: Yes
+10:41 < dammsan> good thanks
+10:41 < geertu> Would Wed March 29 fit?
+10:42 < jmondi> works for me...
+10:42 < neg> also works for me
+10:42 < dammsan> me too
+10:42 < shimoda> works for me
+10:43 < geertu> So for people in a DST zone, it will be one hour later. JST time slot doesn't change.
+10:43 < morimoto> works for me
+10:43 < geertu> OK, thanks!
+10:44 < geertu> Have a nice continued day!
+10:44 < morimoto> Thanks all
+10:44 < shimoda> Thanks! bye!
+10:44 < jmondi> thank you.. will talk soon on periperi list then... bye
+10:45 < dammsan> thanks!!