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

1 files changed, 196 insertions, 0 deletions

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