summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20171109-core-chatlog
diff options
context:
space:
mode:
Diffstat (limited to 'wiki/Chat_log/20171109-core-chatlog')
-rw-r--r--wiki/Chat_log/20171109-core-chatlog199
1 files changed, 199 insertions, 0 deletions
diff --git a/wiki/Chat_log/20171109-core-chatlog b/wiki/Chat_log/20171109-core-chatlog
new file mode 100644
index 0000000..4029f0a
--- /dev/null
+++ b/wiki/Chat_log/20171109-core-chatlog
@@ -0,0 +1,199 @@
+Core-chat-meeting-2017-11-09
+
+09:38 < geertu> Welcome to today's core group meeting!
+09:38 < geertu> Agenda:
+09:38 < geertu> 1. Status updates
+09:38 < geertu> 2. Discussion Topics
+09:38 < geertu> Topic 1. Status updates
+09:39 < geertu> I'll just replay (a sometimes shortened version of) the update sent by email
+09:39 < geertu> A) What have I done since last time
+09:39 < geertu> Geert:
+09:39 < geertu> - Sent 2nd pull requests for clk-renesas and sh-pfc,
+09:39 < geertu> - Attendend ELCE and DT Workshop (Thursday),
+09:39 < geertu> - Sent patches to enable SMP on r8a77970/eagle,
+09:39 < geertu> - Sent patches for initial support for Salvator-XS with R-Car M3-W.
+09:39 < geertu> - Looked a bit into initial support for Salvator-X with R-Car M3-N.
+09:39 < geertu> - Fixing genpd for wake-up devices:
+09:39 < geertu> - Sent active_wakeup cleanups,
+09:39 < geertu> - Working on part two (interrupt routing),
+09:39 < geertu> Jacopo:
+09:39 < geertu> - Attended ELCE and multimedia meeting on 26/27 November
+09:39 < geertu> Marek:
+09:39 < geertu> - UBoot: Fixed eMMC data line voltage setting bug in U-Boot DT
+09:39 < geertu> - UBoot: Final testing in preparation for the 2017.11 release
+09:39 < geertu> Morimoto:
+09:39 < geertu> - Posted DMAC TCR/TCRB patch
+09:39 < geertu> Niklas:
+09:39 < geertu> - [PATCH] net: ethtool: remove error check for legacy setting transceiver
+09:39 < geertu> type
+09:39 < geertu> - Received a V3M.
+09:40 < geertu> Shimoda:
+09:40 < geertu> - Prepared test environment for a new feature of M3-N's IPMMU (stage-2
+09:40 < geertu> format).
+09:40 < geertu> - Handle our 3rd party (EPAM) requests for Xen.
+09:40 < geertu> - Handle our kernel test team for testing v4.14.
+09:40 < geertu> - Merged the following patch(es):
+09:40 < geertu> - arm64: dts: renesas: salvator-common: add dr_mode property for USB2.0
+09:40 < geertu> channel 0
+09:40 < geertu> Simon:
+09:40 < geertu> - Posted, changes requested:
+09:40 < geertu> - Gen3 SoC IPMMU DTS patches
+09:40 < geertu> - Posted, now under review:
+09:40 < geertu> - [PATCH 0/2] iommu/ipmmu-vmsa: r8a779(70|95) support
+09:40 < geertu> - Posted, now accepted:
+09:40 < geertu> [PATCH] ARM: dts: koelsch: Move cec_clock to root node
+09:40 < geertu> [pause to let people catch up]
+09:41 < geertu> Any persone I missed?
+09:43 < geertu> B) What I plan to do till next time
+09:43 < geertu> Geert:
+09:43 < geertu> - Finalize genpd for wake-up devices,
+09:43 < geertu> - Initial support for Salvator-X with R-Car M3-N?
+09:43 < geertu> Marek (U-Boot):
+09:43 < geertu> - UBoot: Start converting Gen2 to DM/DT
+09:43 < geertu> Morimoto:
+09:43 < geertu> - Solve DMAC TCR/TCRB issue.
+09:44 < geertu> Niklas:
+09:44 < geertu> - Hook up V3M and make sure I can boot it.
+09:44 < geertu> - Start to look at 'Add support for more than 32-bits IOVA space'
+09:44 < geertu> Shimoda:
+09:44 < geertu> - Add usb3.0 phy device node for r8a779[56].dtsi.
+09:44 < geertu> Simon:
+09:44 < geertu> - Address review of CPUFreq/Z,Z2 Clock patches
+09:44 < geertu> - Address review of Gen3 SoC IPMMU DTS patches
+09:44 < geertu> - Upport lots of BSP pinctrl patches
+09:45 < geertu> My comment here is that several of the patches listed are alrwady upstream ;-)
+09:45 < geertu> s/alrwady/already/
+09:45 < horms> geertu: ok, I thought I had pruned those. I'll prune again.
+09:45 < horms> Unless kaneko-san posts them before I get that far
+09:48 < geertu> C) Problems I have currently
+09:48 < geertu> Morimoto:
+09:48 < geertu> - I still don't understand DMAC TCR/TCRB issue on serial.
+09:48 < geertu> I think problem is in rx_timer_fn().
+09:48 < geertu> According to Geert, "With your patch, the serial driver doesn't know
+09:48 < geertu> about them (residue == 0), and the console doesn't see them." What does
+09:48 < geertu> this mean?
+09:48 < geertu> BTW, about commit e7327c09def48ccf ("serial: sh-sci: Pause DMA engine and
+09:48 < geertu> get DMA status again"), I guess the reason why "transaction completes
+09:48 < geertu> _after_ DMA stopped" is that it used TCR instead of TCRB?
+09:49 < geertu> Perhaps I wasn't very clear in my initial bug report, but serial console input just doesn't work when SCIF DMA is enabled.
+09:50 < morimoto> geertu: thank you for your report, we will check it again.
+09:51 < wsa_> gotta go, cya guys!
+09:51 -!- wsa_ [~wsa@p54B33A46.dip0.t-ipconnect.de] has quit [Quit: ...]
+09:51 < horms> ciao
+09:51 < geertu> horms: Goodbye!
+09:51 < geertu> Oops, wsa_: Goodbye!
+09:52 < geertu> morimoto: Checking the direction again may help.
+09:52 < morimoto> Yeah, it seems we can guarantee data if we can check DE bit
+09:53 < morimoto> geertu: can you agree ?
+09:53 < geertu> morimoto: But DE is not the direction bit?
+09:54 < morimoto> Yes. using TCR vs TCRB is checking direction
+09:54 < morimoto> and guarantee is checking DE bit
+09:54 < geertu> With "guarantee", you mean to be sure the DMA has completed?
+09:54 < morimoto> yes
+09:55 <@pinchartl> geertu: as far as I understand, the DE bit will be cleared the the hardware when the DMA engine finishes draining its buffers
+09:55 < geertu> ok
+09:55 < morimoto> pinchartl: yes
+09:55 <@pinchartl> I'd like to have a clear explanation as to why SCIF doesn't work with the current patch though
+09:56 <@pinchartl> I don't think we should merge anything based on guesswork
+09:56 < morimoto> Current SCIF is maybe, DMAC read data from device
+09:56 < morimoto> then, TCR was updated
+09:56 < morimoto> but, DMAC will buffer it untile transferable
+09:57 < morimoto> thus, this timing, TCRB is not updated
+09:57 < morimoto> Because of this time gap, TCRB indicate 0x20
+09:57 < morimoto> I guess
+09:58 < geertu> OK, it's worth a try.
+09:58 <@pinchartl> that's the thing, I would feel better with a "I'm sure" than a "I guess" :-)
+09:58 < morimoto> :)
+09:58 < morimoto> So, geertu: pinchartl: can you agree using direction and DE bit check ?
+09:59 < morimoto> using direction = TCR vs TCRB
+09:59 < geertu> Yes, it's worth a try. It needs to be tested, though.
+10:00 < morimoto> Thanks.
+10:00 < morimoto> How about pinchartl ?
+10:01 < morimoto> ...
+10:01 < morimoto> BTW, on commit e7327c09def48ccfd204025726f11b57a19a9c24, it seems rcar dmac driver doesn't support dmaengine_pause() ?
+10:02 < geertu> That's correct, AFAIK.
+10:02 <@pinchartl> morimoto: I'm not sure yet, I need to analyze the problem in details. knowing how it works when checking the DE bit would help me understanding
+10:03 < morimoto> pinchartl: OK, so I will create patch, and add [RFC]. can you check it ?
+10:04 <@pinchartl> morimoto: can you run the patch and include the results ? :-)
+10:04 < geertu> morimoto: Please check it doesn't break the serial console before posting ;-)
+10:04 < morimoto> geertu: Hehe OK :)
+10:04 < morimoto> pinchartl: OK, will try
+10:04 < horms> geertu: is "[PATCH 2/3] soc: renesas: Identify R-Car M3-W ES1.1" good to merge? I think so after our discussion with shimida-san on periperi ML.
+10:05 < geertu> Case closed 9for now)?
+10:05 < morimoto> Sound and SCIF are only user of residue ?
+10:05 < geertu> horms: I think it is.
+10:05 < horms> thanks, I'll add it the next time I go through my queue
+10:05 < geertu> Do you want me to update the patch description with future ES info? Or is that considered too confidential for now?
+10:05 < horms> Lets keep it to ourselves
+10:06 < geertu> OK, fine for me.
+10:06 < geertu> s/9now/(now/
+10:06 < horms> I'll just mention that we had some discussion and it seems likely to work for current and future SoCs
+10:06 < geertu> If the hardware people change their mind, we need to change the tests anyway
+10:06 < horms> About "[PATCH v4 0/3] iommu/ipmmu-vmsa: r8a7796 support V4". I suppose this is a question for dammsan. But should I rebase/repost?
+10:06 < horms> geertu: yes, exactly
+10:07 < geertu> horms: dammsan said repost in a recent email
+10:07 < horms> The important bit is that its unlikely there will be a clash
+10:07 < geertu> Indeed.
+10:07 < geertu> Any other topics for
+10:07 < geertu> Topic 2. Discussion Topics
+10:07 < geertu> ?
+10:07 < horms> ok. sorry for missing that. I'll do so
+10:07 < morimoto> dammsan is here, please wait
+10:07 < horms> I will leave very soon, btw
+10:08 < dammsan> horms: i think it is fine to wait with the repost
+10:08 < dammsan> but feel free to post if it helps your integration work
+10:09 < horms> dammsan: what is the motivation for wating. It effects my integration work in the sense that it adds new bindings. and is a dependency for bindings for other SoCs.
+10:09 < dammsan> my gut feeling is that it is good to hold off addting code to avoid potential issueeeees
+10:10 < horms> ok, perhaps just repost the bindings?
+10:10 < dammsan> good idea
+10:10 < horms> ok, will do
+10:10 < dammsan> together with other ones too if you like
+10:10 < dammsan> we have to revisit non-H3 support in the driver anyway
+10:10 < horms> I'll repost all the outstanding bindings but not the driver code. Is that what you have in mind?
+10:10 < dammsan> sure
+10:10 < dammsan> thanks
+10:10 < dammsan> sounds ogod
+10:11 < horms> One last question, I take it that you intentionaly did not post a fallback binding
+10:11 < dammsan> yeah, the IP varies with soc
+10:11 < horms> thanks, got it
+10:11 < dammsan> thanks
+10:12 < horms> I need to go now, sorry for any inconvenience that causes
+10:12 < geertu> I think we're finished with core anyway
+10:12 < geertu> horms: Bye!
+10:12 < horms> perfect
+10:12 < horms> bye
+10:12 -!- horms [~horms@61.40.109.130] has quit [Quit: Leaving]
+10:13 <@pinchartl> one question for core
+10:13 <@pinchartl> (and actually for I/O too, I should have asked earlier)
+10:13 <@pinchartl> what's the status of V3M support ?
+10:15 < geertu> pinchartl: Boots using serial console, NFS root should work
+10:15 <@pinchartl> and while waiting for an answer to that question, let's see who's ready for the multimedia meeting
+10:15 <@pinchartl> hi jmondi2
+10:15 <@pinchartl> hi kbingham[m]
+10:15 <@pinchartl> hi dammsan
+10:15 [Users #periperi]
+10:15 [@pinchartl] [ jmondi2 ] [ Marex ] [ mturquette]
+10:15 [ dammsan ] [ kbingham ] [ marex-cloud] [ neg ]
+10:15 [ geertu ] [ kbingham[m]] [ morimoto ] [ shimoda ]
+10:15 -!- Irssi: #periperi: Total of 12 nicks [1 ops, 0 halfops, 0 voices, 11 normal]
+10:15 <@pinchartl> hi morimoto
+10:15 < kbingham[m]> I'm here
+10:15 < kbingham[m]> Morning
+10:15 <@pinchartl> hi ul[tab]
+10:15 <@pinchartl> no Ulrich today
+10:15 <@pinchartl> hi neg
+10:15 < jmondi2> I'm here too!
+10:15 < neg> pinchartl: I'm not sure about the status, got a V3M yesterday and plan to try and take it for a first spin
+10:16 < kbingham[m]> geertu: . Does i2c work?
+10:16 <@pinchartl> geertu: any idea whether I2C is working ? how about PFC, is that still unmerged ?
+10:16 < geertu> pinchartl: Sergey is working on upstreaming PFC
+10:17 < geertu> Unfortunately he discovered recently he doesn't have the xls files describing pin mappings
+10:17 <@pinchartl> -_-'
+10:17 <@pinchartl> that's a bit of a blocker
+10:18 < geertu> I told him to post the initial version anyway. We typically don't bother reviewing the register definitions, and we can review pin groups
+10:19 <@pinchartl> thanks
+10:19 <@pinchartl> so let's start with the multimedia meeting
+10:19 <@pinchartl> welcome everybody
+10:19 <@pinchartl> (I expect Magnus and Morimoto-san to come back soon)
+10:19 <@pinchartl> first topic, status update
+10:20 < geertu> Let's finish the core meeting: Thanks for joining, and have a nice continued day!