From 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Mon, 9 Dec 2019 15:29:52 +0900 Subject: wiki: Porting wiki: Porting Chat Log Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20151030-io-chatlog | 196 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 196 insertions(+) create mode 100644 wiki/Chat_log/20151030-io-chatlog (limited to 'wiki/Chat_log/20151030-io-chatlog') diff --git a/wiki/Chat_log/20151030-io-chatlog b/wiki/Chat_log/20151030-io-chatlog new file mode 100644 index 0000000..8d8a24a --- /dev/null +++ b/wiki/Chat_log/20151030-io-chatlog @@ -0,0 +1,196 @@ +--- Log opened Fri Oct 30 09:45:18 2015 +09:45 -!- wsa_ [~wsa@p4FE255A0.dip0.t-ipconnect.de] has joined #periperi +09:45 -!- Irssi: #periperi: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal] +09:45 -!- Irssi: Join to #periperi was synced in 0 secs +09:45 < wsa_> hi there +09:45 < geertu> Hi Wolfram +09:46 < wsa_> hi geert +09:51 < wsa_> shall we maybe meet somewhere else (#periperi-io) so other people can stay here? +09:54 < geertu> Fine for me +09:55 < wsa_> done +09:55 < wsa_> I can't reproduce any of the issues pinchartl is seeing on Magnus' Koelsch :( +09:56 < wsa_> using his config and renesas-drivers-2015-10-27-v4.3-rc7 +09:56 < geertu> Laurent and I both a version with a U-Boot that keeps MSTP clocks running +09:57 < geertu> I do see i2c failures with recent kernels since I enabled DU and friends +09:57 < wsa_> i should be able to emulate that with some 'mw' magic, or? +09:57 < geertu> I do run patches that disable MSTP clocks early in boot +09:57 < geertu> I'll email them to you +09:58 < wsa_> disable? +09:58 < wsa_> i thought your version keeps them running? +09:58 < geertu> yeah, I'm a bit puzzled, as I'd expect _you_ to see failures, not Laurent/ +09:59 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi +09:59 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi +09:59 < geertu> Ah, the "real cold boot" of Koelsch now fails every day with an interrupt storm due to i2c not working for the regulator quirk +09:59 < wsa_> hmm, i think i'd prefer your uboot binary so can load it second stage to RAM +10:00 < wsa_> hello shimoda-san, morimoto-san +10:00 < shimoda> hello wolfram-san! +10:00 < wsa_> please join #periperi-io for the meeting +10:00 < shimoda> i got it +10:01 < wsa_> geertu: my best guess so far is that because of running clocks (and some weird leftover states from the bootloader) the IP core is an unknown state and not properly reinitialized yet +10:03 < geertu> Morimoto-san's "[PATCH] i2c: rcar: call rcar_i2c_init() after pm_runtime_get_sync()" doesn't fix the regylator interrupt storm at boot :-( +10:04 < geertu> If I keep he kernel running until the IRQ subsystem kills the interrupt, usually next reboot works +10:04 < wsa_> geertu: is that with koelsch, too? +10:04 < geertu> yep +10:04 < wsa_> please send me your .config +10:04 < wsa_> and now for the meeting +10:05 < geertu> It started earlier this week +10:05 < wsa_> :) +10:05 < geertu> Issue only happens if I power the board off for a long enough period (i.e. usually at night) +10:06 < geertu> OK, boot completed +10:06 < geertu> resetting +10:06 < geertu> and still working... +10:08 < wsa_> WTF? +10:48 < geertu> BTW, I will most probably have a day off on Wed and Thu +--- Log closed Fri Oct 30 10:52:49 2015 +--- Log opened Fri Oct 30 09:54:50 2015 +09:54 -!- wsa_ [~wsa@p4FE255A0.dip0.t-ipconnect.de] has joined #periperi-io +09:54 -!- ServerMode/#periperi-io [+ns] by hitchcock.freenode.net +09:54 -!- Irssi: #periperi-io: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal] +09:54 -!- Irssi: Join to #periperi-io was synced in 0 secs +09:55 -!- geertu [~geert@d54C36A7B.access.telenet.be] has joined #periperi-io +10:01 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi-io +10:01 < morimoto> Hi +10:01 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi-io +10:02 <@wsa_> hello +10:02 < shimoda> hello! +10:02 <@wsa_> let's wait one more minute for simon +10:03 <@wsa_> if he doesn't show up, we'll put this topic last +10:05 <@wsa_> so +10:05 <@wsa_> let's get this done fast and concentrated :) +10:05 < shimoda> :) +10:05 -!- horms [~horms@penelope-musen.kanocho.kobe.vergenet.net] has joined #periperi-io +10:06 <@wsa_> SDHI DMA: is the BSP team happy with the suggested workflow? +10:06 <@wsa_> hi simon, just in time +10:06 < horms> Apologies for not being more punctual +10:06 < shimoda> i make some patches of SDHI DMA for BSP team :) +10:07 < shimoda> so this patch set will release in early next month as renesas-bsp +10:07 < shimoda> .git +10:07 <@wsa_> great! +10:07 <@wsa_> then we can have a look about further refactoring +10:08 <@wsa_> how did PTP come along? +10:08 < shimoda> yes, I think we have to refactor the tmio driver somehow :) +10:09 < horms> wsa_: regarding ptp +10:09 < horms> I have looked over the bsp after learning it contains the required functionality +10:09 <@wsa_> shimoda: (yes, i think so, too. but let's talk over the code when it is available in git) +10:10 < horms> it seems to me that the only relevant code that is not upstream is to correct an assubmption that the input clock is running at 130MHz: as was the case on Gen2. +10:11 < horms> On the r8a7795 I believe the situation is that it should run at 133MHz, but due to the extal being 16.6Mhz rather than 33MHz it runs at half that speed. i.e. 66.6Mhz. +10:11 < shimoda> wsa_: agreed +10:11 < horms> I think the answer is to have the driver use the speed of its clock to set the register in question +10:11 < horms> i plan to see about implementing that +10:12 <@wsa_> okay, this sounds like a bit of work, but no major obstacle? +10:12 < horms> yes, i think so +10:12 <@wsa_> knock on wood :) +10:12 < horms> I think the main questin will be if the binding needs changing. to my mind the answer is "hopefully not" +10:13 < horms> in theory other clocks could be relevant +10:13 < horms> but in practice the hw only accepts using the high-speed peripheral clock (or what that was renamed to in gen3) +10:13 < horms> so fingers crossed it should not be too difficult to resolve in an upstreamable manner +10:14 * wsa_ crosses fingers +10:14 <@wsa_> thanks simon +10:14 <@wsa_> about PCIE +10:14 <@wsa_> I tested Phil's patches, and they turned out to go into the right directon, but being unusable for now +10:15 <@wsa_> even introducing a build error +10:15 < horms> :( +10:15 <@wsa_> Bjorn wants to drop the branch which would also be my favourite solution +10:16 < horms> thats fine by me. I'll be more careful with Phil's patches in future +10:16 <@wsa_> but i didn't want to suggest it directly because i wanted to be careful (from a diplomatic point of view) +10:16 < horms> do you need me to respond to the thread? +10:17 <@wsa_> if you want, but i don't think it is needed +10:17 < horms> ok +10:17 < horms> i prefer to take a back-seat with PCIe unless action is required +10:17 < horms> if the wheels fall off I'm happy to step in :) +10:18 <@wsa_> okay, thanks +10:18 <@wsa_> watchdog +10:18 < horms> from my pov phil should know what he is doing. its unfortunate if that isn't the case +10:18 < horms> but i will be more watchful +10:19 <@wsa_> make sure his patches get build tested +10:19 < horms> can do +10:19 <@wsa_> i also think that he knows what he is doing in general +10:19 <@wsa_> but this series wasn't his best one +10:19 <@wsa_> for whatever reason +10:19 < horms> ok +10:19 <@wsa_> watchdog ;) +10:20 <@wsa_> my current plan is to release the next version in the second week of November +10:20 <@wsa_> shimoda: will this be enough? or is it needed before that? +10:21 < shimoda> BSP point of view, they need next Wed. :) +10:22 < shimoda> however, they can use your current patch too +10:22 <@wsa_> i'll se what i can do +10:23 <@wsa_> how are the other deadlines? +10:23 < shimoda> thank you! +10:23 <@wsa_> did something urgent show up I missed so far? +10:24 < shimoda> about i/o group, no other deadlines, i think +10:25 <@wsa_> good +10:26 <@wsa_> so major topic seems to be i2c now :( +10:26 <@wsa_> i'll do some more debugging but if I can't reproduce the issues, I probably have to revert the latest r-car series +10:26 < shimoda> i think so ;) +10:27 < morimoto> About Laurent issue do you mean ? +10:27 <@wsa_> geert has some, too +10:27 <@wsa_> all on koelsch +10:28 < morimoto> OK +10:28 <@wsa_> but it doesn't show on Magnus Koelsch +10:28 <@wsa_> where i have remote access to +10:28 < morimoto> which ES number used ? +10:29 < morimoto> do you know ? +10:29 <@wsa_> I asked geert for his u-boot binary so I can start this second stage from RAM +10:29 < geertu> how do I get the U-Boot binary? +10:29 < geertu> raw QSPI contents +10:29 < geertu> ? +10:29 < geertu> Detected Renesas R-Car M2-W ES1.0 +10:29 <@wsa_> I thought you have patches to u-boot? +10:29 <@wsa_> Laurent reported: +10:29 <@wsa_> RTPORC7791SEB00010S +10:29 <@wsa_> KOELSCH SN.057 +10:30 < geertu> My Koelsch is SN.192, and Laurent's is older,so it should be ES1.0 too +10:30 < geertu> Mine ends with 11S +10:31 < geertu> Aha, different board revision too +10:31 <@wsa_> geertu: are those identification patches some way upstream? +10:31 < geertu> No, old version on periperi +10:31 < shimoda> about u-boot code of gen2: git://git.denx.de/u-boot-sh.git +10:31 < geertu> Can email out a new one, moved to drivers/soc and supporting H3 and M3-W +10:32 < shimoda> origin/renesas/bsp/rcar-gen2-7 branch is the latest +10:32 < geertu> yep, checkout b6af5fc +10:32 < geertu> Probably Wolfram (Magnus) has the latest version, in Dublin we saw it was from spring 2015 +10:32 <@wsa_> geertu: new version sounds good +10:32 < geertu> So I have ver=U-Boot 2013.01.01-gb6af5fc (Nov 12 2013 - 14:33:51) +10:33 < geertu> wsa_: but you don't see the issue on new versions? +10:33 <@wsa_> nope +10:33 <@wsa_> morimoto: can we get a "changelog" for Koelsch board revisions? +10:33 <@wsa_> does something like this exist? +10:34 < morimoto> do you mean "board" changelog ? +10:34 <@wsa_> yes +10:34 < morimoto> let me check +10:35 <@wsa_> okay, i more and more get the impression i should revert the changes +10:35 < geertu> "[PATCH] [LOCAL] ARM: shmobile: Print SoC Product Version" sent to periperi +10:35 <@wsa_> they need more time (and not quick hacks) on some Koelsch boards +10:37 <@wsa_> please note that i am away next week +10:38 <@wsa_> i might be able to respond to emails +10:38 <@wsa_> i think we are done unless one of you has a topic left +10:39 < horms> none from my side +10:40 < morimoto> Can I interrupt ? The issue if for HDMI chip access ? +10:40 < morimoto> /if/is/ +10:40 <@wsa_> yes +10:41 <@wsa_> adv7180 +10:41 < morimoto> Thanks +10:41 < geertu> "Your message to periperi awaits moderator approval" +10:41 < horms> oh! +10:41 < geertu> geert+renesas is not a member ;-) +10:42 < horms> did you post just now? +10:42 < geertu> yes +10:42 < geertu> the patch I mentioned above +10:43 < horms> ok, i'll try and approve the post and whitelist your address +10:43 < geertu> thx! +10:44 <@wsa_> morimoto: can you email me your findings? +10:44 <@wsa_> they are much appreciated +10:45 <@wsa_> then, we could close this meeting +10:45 <@wsa_> and go for weekend :D (sooner or later, depending on TZ) +10:46 < shimoda> yes, thank you for the meeting! +10:46 < morimoto> Now, HW team is not here, I asked to them via email. please wait +10:46 <@wsa_> will do +10:46 <@wsa_> cya all! +10:47 < geertu> bye! +10:47 < morimoto> I will have day off on Mon, and Tue is Holiday in Japan. +10:47 < geertu> Have a nice weekend +10:47 < horms> enjoy +10:47 < morimoto> shimoda-san is OK in Mon, so please care it >> shimoda-san +10:47 < shimoda> have a nice weekend! +10:47 < morimoto> bye +--- Log closed Fri Oct 30 10:52:49 2015 -- cgit v1.2.3