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

1 files changed, 341 insertions, 0 deletions

diff --git a/wiki/Chat_log/20160119-core-chatlog b/wiki/Chat_log/20160119-core-chatlog
new file mode 100644
index 0000000..4bd50be
--- /dev/null
+++ b/wiki/Chat_log/20160119-core-chatlog
@@ -0,0 +1,341 @@
+Core-chat-meeting-2016-01-19
+
+10:08 < geertu> Agenda:
+10:08 < geertu> 1. Upcoming Gen3 development for the Core group,
+10:08 < geertu> 2. Could we change initcall() in some drivers?
+10:08 < geertu> 3. Status check for tasks from last meeting - what is remaining?
+10:08 < geertu> Topic 1. Upcoming Gen3 development for the Core group
+10:10 < dammsan> magnus intends to keep on doing IPMMU stuff and also MSIOF MMC-via-SPI on Koelsch
+10:11 < dammsan> he would like someone to look into the SYS-DMAC errata bits from Gen2 in the rcar-dmac.c driver
+10:11 < geertu> errata bits from Gen2?
+10:12 < dammsan> there are at least two - one related to not using the first channel with IPMMU
+10:12 < dammsan> another one is about re-initializing some register
+10:12 -!- horms_ [~horms@reginn.isobedori.kobe.vergenet.net] has joined #periperi
+10:12 < geertu> I mean, do we have them documented somewhere?
+10:12 < dammsan> i did not write the workarounds myself, so i'm not sure
+10:13 < dammsan> they probably apply to gen2, but maybe not gen3
+10:14 < dammsan> so we may need per-soc compat string matching
+10:15 < geertu> OK, bindings for that have been accepted
+10:15 < dammsan> gr8
+10:15 < dammsan> saw that the cpg-mssr driver also went in
+10:15 < geertu> and adding the compatible values to dtsi is queued in arm-soc/for-next
+10:16 < geertu> (does arm-soc plan to miss the merge window?)
+10:16 < dammsan> maybe they outsource the patch management to same place as vinod
+10:16 < horms> geertu: they seem to like to cut things fine
+10:17 < geertu> horms: btw, do you plan to push out a renesas-devel later today?
+10:17 < dammsan> so someone need to dive into sys-dmac driver details on gen3
+10:17 < horms> geertu: no plan, assuming i actually pushed yesterday
+10:18 < geertu> horms: nope, latest is still renesas-devel-20160111-v4.4
+10:19 < horms> sorry, i'll push now
+10:19 < geertu> dammsan: I'm a bit puzzeled
+10:19 < geertu> dammsan: errate on gen2 vs. driver details on gen3?
+10:19 < dammsan> right now the driver does not differentiate between gen3 and gen2
+10:20 < dammsan> we may not have to deal with all the gen2 errata on gen3
+10:20 < geertu> but it "works" nevertheless
+10:20 < geertu> Ah, IC
+10:20 < geertu> So basically it's testing if the driver still works on gen3 without the errata for gen2?
+10:21 < horms> geertu: sorry about that and thanks for pointing out that I hadn't pushed. The latest should now be renesas-devel-20160118-v4.4
+10:21 < dammsan> yeah, and requesting errata information from renesas if needed
+10:21 < dammsan> we also have CAE/CAIR error management for the rcar-dmac.c driver
+10:22 < dammsan> so it seems that the driver itself needs some attention at some point
+10:22 < geertu> I don't think there was anything SYS-DMAC related in the Gen3 errata we received through Jinzai
+10:22 < geertu> horms: got it
+10:22 < neg> I know about one of the errat fixes in dmac.c about not using the first channel I can lookinto if that is needed on gen3 and if not try to fix it
+10:23 < dammsan> neg: thanks for stepping up
+10:24 < morimoto> dammsan: please let me know if you want to ask it to datasheet guys
+10:24 < geertu> The first channel issue is only with IPMMU enabled, right?
+10:24 < dammsan> i believe so
+10:25 < dammsan> morimoto: thanks
+10:26 < geertu> I've retried SYS-DMAC on Salvator-X with (H)SCIF, and RX DMA is working now, too.
+10:26 < geertu> Strange, as I believe the board I have now is the same I was using remotely before?
+10:26 < dammsan> geertu: thanks, i saw your email
+10:26 < dammsan> i think we should revisit after upgrading firmware =)
+10:26 < geertu> However, I had mixed results with IPMMU enabled
+10:27 < geertu> (ah, now I realzie while the console  still worked with IPMMU: SCIF2 is on DMAC1, where IPMMU wasn't enabled)
+10:27 < geertu> OK, firmware upgrade it'll be
+10:27 < dammsan> i think the current working sample of H3 has some IPMMU hardware issues
+10:28 < dammsan> so M3 may be in better state for serious IPMMU usage
+10:28 < geertu> OK
+10:28 < geertu> Anyway, SYS-DMAC is now declared "working"
+10:28 < geertu> Moving on to PM...
+10:29 < neg> from rcar-dmac.c 'A still unconfirmed hardware bug prevents the IPMMU microTLB 0 to be flushed correctly, resulting in memory corruption.' can we confirm the HW bug somehow?
+10:29 < dammsan> neg: that is on gen2 and we could not get information earlier
+10:30 < neg> ok I see if I can give it a try on gen3
+10:30 < dammsan> neg: please focus on the framework bits since the hardware itself may be unstable
+10:31 < neg> ok
+10:31 < dammsan> geertu: regarding PM, is SYS-DMAC working with PM as well? =)
+10:32 < dammsan> it used to be a can of worms
+10:32 < geertu> dammsan: I think so, at least on Koelsch
+10:33 < geertu> Yeah, we had a few PM-related crashes during its development in Summer 2014
+10:33 < dammsan> good!
+10:35 < dammsan> is core handling thermal sensor?
+10:35 < dammsan> i don't remember
+10:35 < geertu> git grep -i therm
+10:35 < geertu> io/todo
+10:36 < dammsan> if so i would like someone to lookin some errors
+10:36 < dammsan> ok i see
+10:37 < geertu> Anything else to report for Topic 1?
+10:38 < horms> one small thing from the upport world
+10:39 < horms> Kaneko-san says the PWM upport is a bit tricky for him. I'll see about handling it myself else report back here or the periperi ML.
+10:39 < horms> end
+10:40 < shimoda> oh, original pwm driver is made by me
+10:40 < shimoda> so, I'll check the bsp patches later
+10:41 < horms> his difficulty is with the clocks. i assume because the driver is different in mainline. if you want to handle this feel free to do so :)
+10:42 < morimoto> Is this BSP original driver do you mean ?
+10:42 < dammsan> geertu: what are you hacking on from now on?
+10:43 < horms> I assume the CPG dirvers are different. To be honest I haven't looked at the patches yet
+10:43 < morimoto> Ah.. OK thanks
+10:43 < dammsan> geertu: i noticed that a bunch of SCIF code went into mainline recently - thanks for that
+10:44 < geertu> dammsan: I started SYS-DMAC, but that seems to work now
+10:44 < geertu> dammsan: So next will be PM, integrating your CPU bringup for Gen2 with the SYSC PM Domain stuff
+10:45 < dammsan> geertu: in your r8a7795 SYS-DMAC DTS patch you wrote you tested MSIOF - may I ask how?
+10:45 < dammsan> i could not get MSIOF to work well on Gen3 myself
+10:45 < geertu> MSIOF indeed has hardware bugs
+10:45 < dammsan> geertu: ok, PM sounds good
+10:45 < geertu> But it sends out data when DMA is used
+10:46 < dammsan> so _something_ is working =)
+10:47 < geertu> Yeah, it behaved the same for PIO and DMA, which IMHO proves that DMA is working ;-)
+10:47 < dammsan> equally busted =)
+10:48 < dammsan> i'll try to re-verify MSIOF on Gen2 and then revisit Gen3
+10:48 < dammsan> the BSP workaround seems pretty useless
+10:49 < dammsan> or rather - i cannot see how it would help MSIOF
+10:49 < dammsan> but anyway
+10:49 < horms> dammsan: could you verify my sound patches on gose when you have time. They may even work :)
+10:49 < shimoda> horms: sorry for the delayed, the commit 2d63d5d9aa6685d028d254ceb877678c0f19363b in renesas-bsp is merged to linux-pwm (72c16a9f98afad073b4a9c947c1c89bfb886ffcb) by me :)
+10:49 < geertu> Same for me, haven't tried it yet (on my io todo list)
+10:49 < shimoda> so, no need to upport on pwm driver for now
+10:50 < dammsan> horms: my gose whines about thermal errors currently
+10:50 < horms> oh
+10:50 < dammsan> if we could get a loopback test then i'd be happy to connect a cable
+10:52 < geertu> dammsan: just compile and run spidev_test.c
+10:52 < geertu> In the mean time, SPI got an internal loopback test, but I haven't tried it yet.
+10:52 < geertu> Topic 2. Could we change initcall() in some drivers?
+10:53 < dammsan> my test case is to use MMC-over-SPI
+10:53 < dammsan> but anyway, lets move to topic 2
+10:53 < geertu> The short answer is "always use module_init() (except if ...)"
+10:53 < dammsan> this seems to be a per-subsystem thing
+10:53 < geertu> There's a global trend to move to module_init()
+10:54 < geertu> Excessive deferred-probing is being worked on, cfr. the thread "[RFD] Functional dependencies between device"
+10:54 < dammsan> thats nice
+10:54 < geertu> Rafael W. posted some initial patches, but they don't derive dependencies from DT yet
+10:55 < geertu> For the specific case of renesas-cpg-mssr.c, using a different priority than subsys_initcall() caused issues on r8a7791
+10:55 < dammsan> that must be connected to timer init order somehow
+10:56 < geertu> irqc
+10:56 < dammsan> ouch
+10:56 < geertu> and Ethernet
+10:57 < geertu> and R-Car Gen2 regulator quirk (which is actually still a problem, I think)
+10:57 < geertu> So yes, it's a mess, and don't touch ;-)
+10:57 < geertu> until Rafael will fix it (hopefully)
+10:57 < dammsan> hehe
+10:58 < dammsan> would it be possible to use cpg-mssr on Gen2 together with MMCIF?
+10:58 < dammsan> to provide a reference implementation for the BSP people?
+10:58 < dammsan> to get the GPIO regulators and whatnot working as expected
+10:59 < geertu> I think so
+10:59 < dammsan> geertu: the Gen2 regulator quirk is hopefully not needed on Gen3?
+10:59 < geertu> It's board-specific
+11:00 < dammsan> i realize it is a board deisng issue
+11:01 < dammsan> shimoda: what is the correct way to support the BSP people wrt initcall level?
+11:01 < horms> shimoda: thanks, got it
+11:01 < geertu> dammsan: You should know, you're doing irqc :-)
+11:01 < horms> shimoda: (pwm change)
+11:01 < geertu> there are no irqc interrupts shared between devices
+11:02 < dammsan> geertu: yes =)
+11:03 < dammsan> regarding the initcall discussion, it must make sense to use same levels for upstream and BSP
+11:03 < shimoda> dammsan: I sent rcar-gpio things that Morimoto-san mentioned to BSP team
+11:03 < dammsan> to avoid cluser fuck
+11:03 < shimoda> so, I will wait for their reply for now
+11:03 < dammsan> ok thanks!
+11:06 < geertu> [advertising: media-next/master has entered mainline, causing a boot crash on koelsch with vsp1 enabled]
+11:07 < horms> wtf!!!
+11:07 < horms> so it was broken in next for a month
+11:07 < horms> known to be broken
+11:07 < horms> and then moved to mainline
+11:07 < horms> is there more to this story?
+11:08 < dammsan> i would be prepared to take that detail if we can get the arm64 bits merged
+11:08 < geertu> Not to mention Laurent's "doubts" response to the pull request
+11:08 < dammsan> hopefully those are not connected
+11:09 < dammsan> horms: what's your plan with CONFIG_RENESAS btw?
+11:09 < dammsan> now when the mailing list is sorted i mean
+11:09 < horms> geertu: I assume that Laurent is on the case with regards to the media problem. if not perhaps i should speak with him?
+11:10 < horms> dammsan: i suppose the symbol is in mainline now/soon so we/I can start updating the drivers.
+11:10 < dammsan> sweet
+11:10 < horms> is there anything i should focus on there from your pov?
+11:10 < dammsan> nah =)
+11:10 < dammsan> just curious
+11:11 < horms> np. i realised the other day that its about time for some more activity there
+11:11 < geertu> horms: Laurent expressed his feelings, cfr. thread "[GIT PULL for v4.5-rc1] media controller next gen patch series"
+11:12 < geertu> horms: not much we can do now, I'm afraid.
+11:13 < geertu> Either Mauro provides a fix (perhaps after a big rant from Linus), Linus unpulls (unlikely, too many days ago), or nothing happens
+11:13 < dammsan> we need a zeroday machine
+11:14 < horms> well its more like we have one
+11:14 < horms> which is next
+11:14 < dammsan> aka smoke machine
+11:14 < horms> where this problem showed up weeks ago
+11:14 < geertu> I reported the issue more than one month ago
+11:15 < horms> well lets hope for a fix
+11:15 < horms> its not very good to have one of our main platforms broken in mainline
+11:15 < dammsan> very true
+11:15 < geertu> You can disable CONFIG_VIDEO_RENESAS_VSP1
+11:15 < dammsan> how about something more recent - how does this affect gen3?
+11:16 < horms> geertu: of course. but i suppose customers may want to use vsp...
+11:16 < geertu> Hmm, I don't have CONFIG_VIDEO_RENESAS_VSP1 in my Gen3 config yet
+11:16 < dammsan> vsp is crucial for DU output on gen3
+11:17 < dammsan> i will have to ask laurent again about current status
+11:17 < geertu> Probably broken, too
+11:17 < dammsan> this is more worrying to me than gen2
+11:17 < dammsan> but of course it sucks to have breakage
+11:18 < horms> can't we just post a fix. the use of BUG_ON seems completely bogus: is it really an error that should take the system down?
+11:18 < dammsan> maybe we can fix it with a hackfest at peripericon
+11:19 < horms> right, if its still around then it would be a good time to spend some energy on it
+11:19 < dammsan> i think so
+11:19 < horms> or douse our sorrows in local beer :)
+11:19 < dammsan> we can share our time =)
+11:19 < dammsan> may have to test on both alt and lager
+11:20 < horms> there are many options for Gen2
+11:20 < geertu> horms: Please read my report. Before the (old) BUG_ON() started to trigger, there was already a ULL pointer dereference, introduced by an earlier commit in the series
+11:20 < geertu> s/ULL/NULL/
+11:20 < horms> geertu: ok, sorry for jumping to conclusions
+11:20  * geertu no media expert
+11:21 < dammsan> geertu: do you agree that trying to fix this during peripericon may make sense?
+11:21 < geertu> dammsan: do we have all required test peripherals?
+11:21 < dammsan> it must be  one of our major headaches at the moment
+11:22 < dammsan> i don't know how to trigger it i'm afraid
+11:22 < geertu> just boot ;-)
+11:22 < dammsan> but VSP is usually a memory-to-memory device
+11:22 < dammsan> and all Gen2 SoCs have VSP
+11:22 < horms> i would suggest moving before peripericon if its a major headache
+11:22 < geertu> Now, fixing the crash doesn't mean the system will work
+11:23 < dammsan> so can some magician make laurent appear?
+11:23 < geertu> Laurent also mentioned user-space impact
+11:23 < geertu> which may please Linus even less
+11:23 < dammsan> yeah, this has "unpleasant" written all over it
+11:25 < dammsan> do we have any major headache for the core group?
+11:26 < horms> Mauro does seem to have acknowledged there is a problem, perhaps there is hope of a peaceful resolution to the problem
+11:26 < geertu> yeah, he just sent private email to Javier and me. He's on holidays and asks Javier to look into it.
+11:27 < geertu> Topic 3. Status check for tasks from last meeting - what is remaining?
+11:28 < horms> Our old friend mode pins
+11:28 < horms> I guess that is worthy of a slot at peripericon
+11:30 < horms> On the integration coverage side, things are moving forwads slowly and surely. I don't see any major headaches at this time. And I may even be so bold as to say entries are being completed faster than new ones are being added.
+11:30 < horms> The largest patchset is sound for gose. I plan to do something similar for alt.
+11:30 < horms> Thats probably enough on integration imho
+11:32 < dammsan> i have timers and interrupts still on my todo
+11:33 < neg> DMAC+IPMMU on gen2 works but Vinod have not yet made up his mind if the issue should be solved in the DMAC or by the clients
+11:33 < neg> plan to send a v2 tomorrow and see if he have med up his mind
+11:34 < horms> neg: please use the new mailing list :)
+11:34 < dammsan> neg: this all seems to be about making vinod make up his mind
+11:35 < geertu> we need some backing from other ARM IOMMU users
+11:35 < neg> horms: will do, thanks for reminding me :)
+11:35 < dammsan> geertu: yeah
+11:35 < dammsan> the IPMMU+DMAC errata work is not that important compared to getting the framework bits right
+11:36 < dammsan> even if we fixed all the IPMMU+DMAC hardware stuff we would still not able to use it without further fixes..
+11:36 < dammsan> neg: i'm really happy that you are dealing with that
+11:36 < dammsan> we should have done that ages ago IMO
+11:37 < dammsan> geertu: do you know any other SoCs that need the same kind of changes for DMAC+IOMMU?
+11:37 < neg> I'm a bit at a loss on how to get backing from other ARM IOMMU users, all I know how to do is ping Vinod
+11:38 < dammsan> i wonder if it is possible to use SWIOTLB instead of IOMMU to get the same dependency? if so it would be a software-only thing
+11:39 < geertu> dammsan: IIRC, that patch came from Ulf, but he seems to have forgotten about the principle behind it
+11:39 < geertu> dammsan: Arnd?
+11:39 < geertu> BTW, Mauro asks how to get a koelsch
+11:39 < dammsan> yeah
+11:39 < dammsan> i can give him remote access if that would help
+11:40 < dammsan> that may not work to our advantage though
+11:40 < geertu> Should be good enough to fix the boot crash
+11:40 < geertu> Yeah, another cam of worms
+11:40 < geertu> s/cam/can/
+11:40 < dammsan> isn't it better just to revert the stuff until it can be fixed properly?
+11:40 < geertu> The alternative is to wait for Laurent to return from holidays, or someone else dives into it?
+11:41 < dammsan> that must be better for all of us
+11:41 < geertu> Revert the full merge?
+11:41 < dammsan> if that is feasible
+11:41 < dammsan> isn't that how things normally would be solved
+11:41 < dammsan> if it is not working, dont merg it
+11:41 < horms> that is the usual way
+11:41 < horms> but its already merged
+11:42 < dammsan> i feel remote access is a good last resort
+11:42 < horms> and presumably simply reverting it isn't simple
+11:42 < horms> i agree it is a good last resort
+11:43 < dammsan> hm..
+11:43 < horms> getting Laurent to calmly and awesomely fix it sounds good. but when does he get back? and how busy will he be then?
+11:44 < dammsan> geertu: laurent is supposed to spend time on core development this quarter. so he needs to work on that too
+11:46 < dammsan> i have got a good idea
+11:46 < dammsan> how about reproducing this on all the gen2 boards
+11:46 < dammsan> then offer mauro remote access to all of them so he can fix it
+11:46 < horms> i haven't seen it on all boards, fwiw
+11:47 < dammsan> there is not real difference in my mind
+11:47 < geertu> mauro wants to chat. Invite him to #periperi?
+11:47 < dammsan> isn't that a good technique to overwhelm as a policial move?
+11:47 < horms> i guess i wan't clear. the problem doesn't seem to manifiest on all the boards
+11:47 < dammsan> geertu: can we try to reproduce on other boards?
+11:48 < dammsan> horms: but the vsp is a generic piece of IP
+11:48 < geertu> Sure, boot shmobile_defconfig from current Linus' tree
+11:48 < dammsan> so that seems kind of unlikely
+11:48 < horms> dammsan: i'm just saying what i see
+11:48 < dammsan> let me try on lager
+11:48 < dammsan> sure
+11:48 < geertu> commit 77a76b04d2be1c45b8fd746b7ef754525029340c
+11:48 < geertu> is the bad merge
+11:48 < geertu> commit 77a76b04d2be1c45b8fd746b7ef754525029340c^ boots fine
+11:51 < dammsan> currently trying to reproduce on koelsch with a200dcb34693084e56496960d855afdeaaf9578f
+11:51 < horms> fwiw, i only see vsp1 nodes in DT for the r8a7790 and r8a7791 as of the commit that geert mentioned
+11:51 < dammsan> well at least lager should trigger too in such case
+11:52 < horms> i need to give my son a bath. i'll come back after that. but fwiw i see no harm in talking with mauro if he wants to chat with us on irc
+11:52 < geertu> "git revert -m 1 77a76b04d2be1c45b8fd746b7ef754525029340c"
+11:52 < geertu> seems to work
+11:53 < geertu> So i'll do that for today's renesas-drivers
+11:54 < geertu> Also saves me the hassle of fixing the big merge conflict with git://linuxtv.org/pinchartl/media.git#vsp1-kms-20151217~3
+11:54 < horms> two birds, one stone
+11:55 < geertu> vsp1-kms-20151217 is just too old
+11:55 < dammsan> sure
+11:55 < dammsan> i managed to reproduce on koelsch
+11:55 < dammsan> lager is also busted
+11:55 < dammsan> like is suspected
+11:56 < geertu> neg: did you look into media-controller for the multi-media group?
+11:57 < neg> I'm looking in to VIN for media group
+11:57 < geertu> ok
+11:57 < dammsan> gose does not trigger
+11:57 < geertu> no vsp1 in gose dts?
+11:58 < dammsan> that's what simon said yeah
+11:58 < dammsan> it is soc-specific
+11:58 < dammsan> so perhaps some of the low cost boards would trigger for r8a7790 and r8a7791
+11:59 < horms> # grep -l vsp1@ arch/arm/boot/dts/r8a7*.dtsi
+11:59 < horms> arch/arm/boot/dts/r8a7790.dtsi
+11:59 < horms> arch/arm/boot/dts/r8a7791.dtsi
+11:59 < horms> perhaps the other socs would trigger if the nodes were present in DT
+11:59 < dammsan> alt also does not trigger - not so surprising
+11:59 < dammsan> the configuration may be slightly different from r8a7790/1 though
+12:00 < dammsan> but it is likely to trigger regardless
+12:00 < dammsan> does anyone have a lcb?
+12:00 < horms> it wont be triggered in mainline :^)
+12:01 < dammsan> porter or henninger?
+12:01 < dammsan> maybe this is when we play the sergey card =)
+12:01 < geertu> +1
+12:02 < horms> i recommend playing a card that is likely to get the problem resolved
+12:02 -!- horms is now known as horms_away
+12:02 < geertu> It should trigger on porter, as the vsp* nodes do not have 'status "disabled"' in r8a7791.dtsi
+12:02 < dammsan> morimoto: how can we ask sergei to test upstream for us?
+12:02 < geertu> (why are they not disabled?)
+12:03 < morimoto> that's good idea
+12:03 < dammsan> geertu: they are memory-to-memory devices
+12:03 < morimoto> do you want it ?
+12:03 < dammsan> and do not expose themselves to board specific things
+12:03 < dammsan> similar to thermal
+12:04 < dammsan> just self-contained on-chip devices
+12:04 < dammsan> geertu: do you think it hurts to involve sergei? i can only see upside
+12:05 < geertu> Please wait, Javier has just told me he'll look into it
+12:05 < dammsan> is mike turquette around?
+12:05 < dammsan> they may have gen2 boards somewhere too
+12:05 < dammsan> morimoto: please wait
+12:05 < geertu> Aha, mchehab|OOT invites you to ##vsp1
+12:05 < morimoto> OK
+12:12 < dammsan> time to wrap up in a while?
+12:13 < geertu> Yes
+12:13 < geertu> long overdue
+12:13 < geertu> BTW, does anyone have a Porter to verify?
+12:13 < dammsan> i wish i had one
+12:14 < morimoto> geertu: now shimoda-san is checking
+12:14 < morimoto> OK, Renesas office have 1 Porter
+12:18 < geertu> Good to know.
+12:18 < geertu> OK, thanks for joining!
+12:18 < morimoto> Thanks! Let's see on Brussels
+12:19 < neg> thanks
+12:19 < dammsan> thanks, bye bye