diff options
Diffstat (limited to 'wiki/Chat_log/20160119-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20160119-core-chatlog | 341 |
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 |