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

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