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

1 files changed, 136 insertions, 0 deletions

diff --git a/wiki/Chat_log/20160127-io-chatlog b/wiki/Chat_log/20160127-io-chatlog
new file mode 100644
index 0000000..81c78dd
--- /dev/null
+++ b/wiki/Chat_log/20160127-io-chatlog
@@ -0,0 +1,136 @@
+--- Log opened Wed Jan 27 08:56:58 2016
+08:56 -!- wsa_ [~wsa@p4FE25B5E.dip0.t-ipconnect.de] has joined #periperi
+08:56 -!- Irssi: #periperi: Total of 9 nicks [0 ops, 0 halfops, 0 voices, 9 normal]
+08:56 -!- Irssi: Join to #periperi was synced in 1 secs
+08:57 < wsa_> aloha
+08:57 < morimoto> Hi
+08:58 < wsa_> Renesas Vietnam
+08:58 < wsa_> didn't know this branch
+08:58 < wsa_> :)
+08:59 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi
+08:59 -!- horms [~horms@penelope-musen.kanocho.kobe.vergenet.net] has joined #periperi
+08:59 < morimoto> Paper company ;)
+08:59 < morimoto> (joke)
+09:00 < geertu> Any link to Jinzai?
+09:00 < morimoto> geertu: what do you mean ?
+09:00 < geertu> Jinzai is also Vietnamese, IIRC?
+09:01 < morimoto> Ahh, yes, but different.
+09:01 < wsa_> it is?
+09:01 < wsa_> learning a lot of things today
+09:01 < morimoto> Jinzai Vietnam people has no relationship to RVC
+09:03 < wsa_> as long as we are waiting for simon
+09:04 < wsa_> what is the difference between the F_ and FM macro in the pfc driver?
+09:04 < wsa_> when to use F_, when to use FM?
+09:04 -!- horms_ [~horms@reginn.isobedori.kobe.vergenet.net] has joined #periperi
+09:04 -!- horms_ [~horms@reginn.isobedori.kobe.vergenet.net] has quit Remote host closed the connection
+09:04 -!- horms_ [~horms@reginn.isobedori.kobe.vergenet.net] has joined #periperi
+09:04 < horms> wsa_: I am here
+09:05 < morimoto> wsa_: It is case by case
+09:05 < wsa_> so, we are complete
+09:05 < morimoto> You can find many #define F_(), and #define FM() on this driver
+09:05 < geertu>     /*
+09:05 < geertu>      * F_() : just information
+09:05 < geertu>      * FM() : macro for FN_xxx / xxx_MARK
+09:05 < geertu>      */
+09:06 < wsa_> geertu: I saw that, but it didn't help my understanding :/
+09:06 < wsa_> I got the impression that F_ macro wouldn't create *_MARK macros
+09:07 < wsa_> but that doesn't seem to be the case
+09:08 < wsa_> but maybe this is better explained vis-a-vis
+09:09 < wsa_> let's start the meeting
+09:09 < wsa_> thanks for the per-mail updates
+09:09 < wsa_> they should make the meeting really short
+09:09 < wsa_> my updates:
+09:10 < wsa_> +SDHI,v4.6,plan,wolfram,Upstream & improve basic Gen3 SD+MMC support from BSP
+09:10 < wsa_> @@ -34,2 +35 @@ SDHI,v4.6,plan,wolfram,Upstream Gen3 DMA support from BSP
+09:10 < wsa_> -SDHI,?,noplan,?,add UHS-I support
+09:10 < wsa_> -SDHI,?,noplan,?,Upstream Gen3 MMC support from BSP
+09:10 < wsa_> +SDHI,v4.7,plan,wolfram,Upstream UHS-I/HS200 support
+09:10 < wsa_> @@ -51,0 +52 @@ I2C,?,noplan,?,Gen3 can tweak SCL/SDA signals but driver needs support
+09:10 < wsa_> +I2C,?,noplan,?,introduce irqless transfers to issue reboot via PMIC
+09:10 < wsa_> which is basically SDHI rewording and planning features specifically for 4.6 and 4.7
+09:11 < wsa_> and introducing the idea of irqless i2c transactions to properly reboot via PMICs
+09:12 < morimoto> Is it Renesas specific issue ?
+09:12 < geertu> Nice
+09:12 < wsa_> morimoto: not only
+09:12 < morimoto> OK, good
+09:12 < wsa_> morimoto: but all RCar boards need it
+09:13 < shimoda> about sdhi sd_info2 register, i checked it doens't work on M2 channel 2
+09:13 < wsa_> it has been mentioned on the i2c-list already, too
+09:13 < wsa_> shimoda: you mean CBUSY?
+09:13 < geertu> wsa_: Would there be a way to call into this from rcar-gen2-quirks?
+09:14 < geertu> (see also http://www.spinics.net/lists/linux-sh/msg46448.html)
+09:14 < wsa_> geertu: I'd like it to be generic, to limited to the poweroff-case
+09:14 < shimoda> wsa_: yes. according to the data sheet, some channels doesn't have CBSY bit
+09:14 < shimoda> on gen2
+09:14 < wsa_> but I am not sure about the design, because I2C transfers, SMBUS transfers and regmap transfers need to be covered
+09:15 < wsa_> shimoda: that is good to know
+09:15 < wsa_> maybe we should just stick to SCLKDIVEN...
+09:16 < shimoda> wsa_: I agree with you about stick to SCLKDIVEN if gen2
+09:16 < wsa_> morimoto: what do i do with the thermel h3 upstreaming task if Renesas Vietnam is going to do it? Should I delete it from the io group todo?
+09:17 < morimoto> wsa_: we (= Magnus, me, shimoda) and RVC and BSP team will talk about it
+09:18 < morimoto> If RVC do it, maybe it can go to rel/todo from io/todo
+09:18 < morimoto> But we don't know at this point
+09:18 < wsa_> ok, i will wait and keep it until then
+09:19 < morimoto> thanks
+09:19 < wsa_> what is the "rel" group?
+09:19  * wsa_ finds out lots of things today :)
+09:20 < morimoto> REL = Renesas Electronics Corporation
+09:20 < morimoto> This means Renesas itself
+09:21 < wsa_> ah
+09:22 < wsa_> i still can't get mmc 8-bit to work
+09:22 < wsa_> just to make sure: was there any verification of the HW that the pins are routed correctly?
+09:24 < morimoto> now shimoda-san confirm it
+09:25 < wsa_> confirm that it is routed correctly?
+09:27 < morimoto> OK, it seems we have local patch. and it seems voltage issue
+09:28 < morimoto> It seems it will goes to BSP. can you please it if BSP has it ?
+09:29 < morimoto> (maybe it is good path ? BPS -> upport )
+09:29 < wsa_> can you mail me the local patch?
+09:30 < shimoda> wsa_: i will send the patch to you later
+09:31 < wsa_> thank you!
+09:31 < wsa_> anything else left?
+09:32 < shimoda> update from my side
+09:32 < shimoda> @@ -69,6 +69,8 @@ HSUSB,?,noplan,shimoda,IPMMU issues
+09:32 < shimoda>  #USB3 Host
+09:32 < shimoda>  USB3Host,?,noplan,shimoda,suspend problems
+09:32 < shimoda>  #USBPHY
+09:32 < shimoda> +USBPHY,v4.6,prototype,shimoda,add extcon support
+09:32 < shimoda> +USBPHY,?,plan,shimoda,add OTG support
+09:32 < shimoda>  
+09:32 < shimoda>  ### Extra
+09:32 < shimoda>  Watchdog,v4.5,public,wolfram,upstream driver written for Gen3 BSP
+09:33 < wsa_> ok, added to the list
+09:33 < shimoda> thanks!
+09:34 < shimoda> about OTG support, i intend to add it after OTG framework is changed
+09:34 < wsa_> geertu: i could mark your SCIF-DMA task as "prototype"?
+09:35 < geertu> It's working
+09:35 < geertu> Nothing really to be done
+09:35 < geertu> Perhaps the failures before were just a firmware issue?
+09:35 < wsa_> so, "completed"?
+09:35 < geertu> yes
+09:35 < wsa_> \o/
+09:36 < geertu> For the (H)SCIF support, I have to resend the integration patches, now v4.5-rc1 has been released.
+09:36 < geertu> I had to rebase, so it's now cooking in yesterday's renesas-drivers
+09:36 < wsa_> +SCIF,v4.6,completed,geert,DMA support for Gen3 (worked out of the box)
+09:37 < geertu> Please test renesas-drivers on silk, porter, lager, gose ;-)
+09:38 < horms> i can do the last two, is there anything in particular I should look for?
+09:38 < wsa_> i'll be away from my lager for 10 days
+09:39 < horms> I think there is either a porter or silk in kernelci
+09:39 < horms> and iirc team rel has a porter
+09:39 < wsa_> will start my journey to FOSDEM later today
+09:39 < horms> enjoy!
+09:40 < shimoda> magnus-san got 2 porter boards, so i think we use the boards via remote in the future, i guess
+09:41 < geertu> good, thx
+09:41 < horms> excellent
+09:42 < wsa_> so, that was it for today?
+09:43 < horms> nothing more from me
+09:43 < morimoto> ditto
+09:43 < shimoda> nothing from me
+09:44 < geertu> nothing for me
+09:44 < wsa_> so, looking forward to see you soon!
+09:44 < wsa_> have a safe travel
+09:44 < morimoto> See you in Brussels !
+09:44 < shimoda> bye!
+09:44 < geertu> CU soon!
+09:44 < geertu> bye!
+09:45 < wsa_> bye!
+--- Log closed Wed Jan 27 09:46:09 2016