1 files changed, 230 insertions, 0 deletions
diff --git a/wiki/Chat_log/20151015-io-chatlog b/wiki/Chat_log/20151015-io-chatlog
new file mode 100644
index 0000000..6101416
--- /dev/null
+++ b/wiki/Chat_log/20151015-io-chatlog
@@ -0,0 +1,230 @@
+--- Log opened Thu Oct 15 10:58:29 2015
+10:58 -!- wsa_ [~wsa@p4FE25555.dip0.t-ipconnect.de] has joined #periperi
+10:58 -!- Irssi: #periperi: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal]
+10:58 -!- Irssi: Join to #periperi was synced in 1 secs
+10:58 < pinchartl> can I let you handle it internally to book a time and place ?
+10:58 < dammsan> yes
+10:58 < wsa_> hi there!
+10:58 < pinchartl> or do you expect me to do anything ?
+10:58 < pinchartl> hi Wolfram
+10:58 < dammsan> no, it will be on the 4th
+10:58 < dammsan> more details to follow over email
+10:59 < dammsan> bye bye!
+10:59 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has quit Remote host closed the connection
+10:59 < wsa_> bye magnus
+10:59 < pinchartl> bye bye too :-)
+10:59 < wsa_> bye!
+11:00 -!- Irssi: #periperi: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal]
+11:01 -!- horms [~horms@121-80-213-238f1.hyg1.eonet.ne.jp] has joined #periperi
+11:01 < wsa_> \o/
+11:01 < wsa_> hi simon
+11:01 < geertu> Hi Wolfram
+11:01 < wsa_> hi geert
+11:02 < horms> hi!
+11:02 < wsa_> morimoto-san, shimoda-san: you there?
+11:02 < morimoto> hi
+11:02 < shimoda> hi!
+11:02 < wsa_> \o/
+11:02 < geertu> Hi all
+11:03 < morimoto> geertu: about Koelsh, it seems there is ES1.0/ES2.0/ES3.0 in this world
+11:03 < morimoto> but I (and shimoda-san) only have ES1.0 board
+11:03 < wsa_> good starting point
+11:04 < geertu> Good to know.
+11:04 < wsa_> what about having a wiki page stating who has which board with which ES  number
+11:04 < geertu> Let's wait for bug reports ;-)
+11:04 < geertu> Yeah, that's long overdue
+11:06 < wsa_> I would start it, but it might be that I forgot my wiki pwd :/ will try again after this meeting
+11:06 < geertu> My Salvator-X has H3 ES1.0
+11:06 < geertu> Bummer, no access to https://osdr.renesas.com/projects/linux-kernel-development/wiki/Io-todo-list?
+11:08 < wsa_> so, the other topics for today I have: todo list updates, SCIF status, Who does SDHI, Watchdog plans
+11:08 < wsa_> more topics from your side?
+11:09 < horms> i would like to ask shimoda san about etheravb. but i can ask him tomorrow when i visit his office if there is no time here today
+11:09 < wsa_> ok, so we put this to the end of the list
+11:10 < shimoda> horms: i got it :)
+11:10 < wsa_> so, let's start with todo list updates:
+11:10 < wsa_> I have
+11:10 < wsa_> PWM driver upstream \o/
+11:11 < wsa_> Thermal driver still needs the docs
+11:11 < wsa_> PCIE patches appeared on ML, will check them when my board arrives
+11:11 < wsa_> (according to UPS should be today)
+11:11 < wsa_> EtherAVB basic support upstream \o/
+11:12 < wsa_> SATA driver: BSP team works on it
+11:12 < wsa_> I2C: runtime core switch postponed to 4.5. too late in the cycle for DT bindings
+11:12 < wsa_> I2C: DMA task added until End of May
+11:13 < wsa_> not sure about this one:
+11:13 < wsa_> SPI slave support wanted until End of May
+11:13 < wsa_> ?
+11:13 < wsa_> shimoda: is this final? or is it still a request only?
+11:13 < geertu> I'll have to look at the other SPI Ethernet driver, and do some more research for a good use case.
+11:14 < geertu> Shimoda-san: Do you have more info about the customer's use case?
+11:14 < shimoda> geertu: unfortunately I don't have more info
+11:15 < geertu> At ELCE, I talked to Mark Brown (SPI maintainer), and he's open for SPI slave support.
+11:15 < geertu> Shimoda-san: Would it be possible to ask somewhere to obtain more info?
+11:16 < shimoda> geertu: i will try to ask
+11:16 < wsa_> geertu: what is the status of this large SCIF series?
+11:16 < wsa_> needs ping? needs review? already upstream?
+11:17 < shimoda> wsa_: about thermal driver, I heard bsp team is developing it. So, I will get information from them later
+11:17 < geertu> SCIF DMA is in -next
+11:17 < geertu> So it will be in v4.4
+11:17 < wsa_> \o/
+11:18 < wsa_> didn't notice from the mails in linux-sh
+11:18 < wsa_> so i can remove
+11:18 < wsa_> SCIF,4.4,Upstream improved DMA support for R-Car Gen2
+11:18 < wsa_> from the todo list
+11:18 < wsa_> ?
+11:19 < geertu> GregKH's bot didn't CC linux-sh
+11:19 < geertu> Yes (assumed in -next == will be in v4.4)
+11:19 < wsa_> shimoda: ok, will update the info about thermal driver
+11:20 < wsa_> geertu: and you will be working on baudrate generators for 4.5, correct?
+11:20 < geertu> that's correct
+11:20 < geertu> I'm a bit delayed by the Gen3 CPG rework
+11:21 < wsa_> I can imagine
+11:22 < wsa_> geertu: anything else you are planned to work on IO wise?
+11:22 < morimoto> I asked about SPI slave use case to BSP team
+11:22 < wsa_> I have this baudrate generator and random SPI stuff in the list :)
+11:23 < geertu> Yeah, I plan to test MSIOF on Gen3, if possible (read: available on EXIO)
+11:23 < wsa_> same questions to the others
+11:23 < wsa_> shimoda: I assume you will be busy doing USB stuff?
+11:24 < wsa_> morimoto: any IO related task you have assigned? (except using I2C for sound ;))
+11:24 < morimoto> Ahh... no I/O I have
+11:24 < wsa_> simon: I guess you'll work in improving EtherAVB support?
+11:25 < shimoda> wsa_: yes, but bsp team needs USB stuff (expect USB2 host) until end of May
+11:25 < shimoda> so, i have some space
+11:25 < wsa_> oh, that sounds good
+11:25 < morimoto> wsa_: About Thermal driver lacking docs, do you mean 10A.3.1.2 ?
+11:25 < horms> EtherAVB is the only i/o related item i'm working on directly
+11:25 < shimoda> however, sometimes I have a lot of paper works though :)
+11:26 < wsa_> oh, that sounds not good
+11:26 < wsa_> :)
+11:27 < wsa_> horms: anything specific? I have only PTP support until End of November in the list
+11:27 < horms> so my question for shimoda-san is about that
+11:27 < horms> is now a good time?
+11:28 < wsa_> morimoto: yes, and 10.A.3.1.4
+11:30 < shimoda> horms: sorry I don't understand your question
+11:30 < shimoda> you are talking about PTP support?
+11:31 < horms> my quesion is as follows
+11:32 < morimoto> wsa_: OK, according to datasheet team, about 10A.3.1.2, it depends on real measured data.
+11:32 < morimoto> but, there is not such data at this point. So, it will be other explanation in next datasheet
+11:32 < morimoto> if they still doesn't have it
+11:33 < horms> I see some PTP support present in the ravb driver. It looks like it handles timestamps. Is that what is required for r8a7795 by mid-November?
+11:33 < wsa_> morimoto: I assumed so. Anyhow, looks like BSP team took this over. They will probably have better access to such data
+11:36 < shimoda> horms: thank you for the detail. I will ask bsp team about this
+11:36 < horms> shimoda: thanks. if they want to explain things in patches that is fine by me :)
+11:37 < wsa_> good
+11:38 < wsa_> can we move to SDHI topic?
+11:38 < horms> i think so
+11:38 < shimoda> i think so
+11:39 < wsa_> fine
+11:39 < wsa_> It seems that BSP team also wants to do the initial support?
+11:39 < wsa_> And then wants to work on DMA support?
+11:40 < shimoda> I think they want to work on DMA support if possible
+11:40 < wsa_> And they need some assistance from us how to do it
+11:41 < shimoda> I think so
+11:43 < wsa_> do they have patches for initial support already?
+11:43 < shimoda> tmio driver is using dmaengine. but I don't know gen3 SDHI should use it or not
+11:44 < shimoda> wsa_: for PIO, yes
+11:44 < shimoda> let me check some repositories
+11:47 < shimoda> in renesas-bsp.git, 91e3cc719def606e049861d4f9fc02bd90f126be, arm64: dts: salvator-x: Add sdhi-rcar support
+11:48 < shimoda> 09a0662a2b6073bb2237b5d28a354a406b4b640b, arm64: dts: r8a7795: Add sdhi-rcar support
+11:49 < wsa_> got them
+11:50 < wsa_> and some more patches to look at
+11:50 < shimoda> about driver side, they are submitted some local patches...
+11:50 < horms> wsa_: btw renesas-bsp is on kernel.org
+11:52 < wsa_> yes, that's good
+11:53 < wsa_> well, the makefile from mmc/hosts says:
+11:53 < wsa_> tmio_mmc_core-$(subst m,y,$(CONFIG_MMC_SDHI))   += tmio_mmc_dma.o
+11:53 < wsa_> so, the DMA module is only compiled in for SDHI?
+11:54 < wsa_> ah, sure. the todo list only marks "DMA on Gen3" as a todo
+11:55 < shimoda> wsa_: yes, on gen3, DMAC is internal in the SHDI device instead of SYS-DMAC
+11:57 < wsa_> is this internal DMAC reused in other IP cores?
+11:57 < wsa_> it doesn't look SDHI specific to me
+11:58 < shimoda> I don't think this internal DMAC is reused
+12:01 < wsa_> ok
+12:02 < morimoto> About makefile, tmio_mmc_dma.o is used only from CONFIG_MMC_SDHI is correct
+12:02 < morimoto> this is because historical reason
+12:02 < morimoto> About Gen3 internal DMAC, this is Gen3 new feature
+12:02 < morimoto> Gen3 DMAC != tmio_mmc_dma
+12:02 < wsa_> I'd think a new file 'tmio_mmc_dma_gen3.c' or similar would be the way to go, but I need to double check
+12:03 < wsa_> I can investigate
+12:03 < wsa_> Is it "as soon as possible" or will next week be enough?
+12:03 < morimoto> I think it is not "tmio", "sh_mobile_sdhi_dma" is better ?
+12:04 < horms> can we rename tmio_mmc_dma while we are at it?
+12:04 < wsa_> to?
+12:04 < horms> I suspect it doesn't relate to tmio at all
+12:04 < horms> but just to sdhi
+12:05 < horms> i could be wrong
+12:05 < wsa_> i will dig into that and post my findings on the list
+12:05 < morimoto> unfortunately, not good idea
+12:05 < morimoto> because tmio_mmc_pio calls tmio_mmc_dma function
+12:06 < horms> ok
+12:06 < morimoto> But, we can create new sub-framework for DMA?
+12:06 < morimoto> real TMIO doesn't need DMA (?), we need 2type of DMA
+12:07 < morimoto> and tmio_dma naming is not good match now ?
+12:07 < horms> probably that will lead to a nice clean result
+12:07 < horms> but is gen3 dma on the critical path?
+12:08 < horms> If so it would be nice to arrange things so new frameworks come after hw support, imho
+12:08 < wsa_> agreed
+12:08 < shimoda> horms: on the critical path or not, let us ask BSP team tomorrow :)
+12:09 < horms> good plan
+12:09 < wsa_> anything more for SDHI?
+12:09 < wsa_> otherwise let's move on to watchdog
+12:11 < morimoto> ok
+12:11 < wsa_> ok, my idea there is to implement the missing SET_TIMEOUT feature and repost as RFC
+12:12 < wsa_> we can then test this one on Gen2/3 and see if it works with the reset controllers
+12:12 < wsa_> (it obviously doesn't on r8a7790 ES1)
+12:12 < wsa_> if all fails, I could try to add r7s72100 support and get at least the driver upstream vis this path
+12:13 < wsa_> so we don't have to carry around this one
+12:13 < wsa_> OK plan?
+12:13 < shimoda> wsa_: if we use not SMP, watchdog should work even if r8a7790 ES1
+12:14 < geertu> The watchdog is not limited to R-Car Gen2/3 and RZ
+12:15 < wsa_> shimoda: Yes, then it works
+12:15 < wsa_> I can confirm that
+12:15 < geertu> it's also present on older SH-Mobile and R-Mobile
+12:16 < wsa_> geertu: like with r7s or even another register layout?
+12:17 < geertu> BTW, the issue with the syscon driver I mentined in "Re: [RFC 4/5] ARM: shmobile: r8a7790: let rst module allow watchdog resets if desired" (http://www.spinics.net/lists/linux-sh/msg39799.html) is gone
+12:19 < wsa_> how come?
+12:20 < geertu> At that time, you couldn't have both syscon and a regular driver bind to the same device node
+12:20 < geertu> that has been fixed
+12:20 < geertu> the APE6 RWDT looks the same as Gen2
+12:21 < geertu> The RZ one is different
+12:22 < geertu> A1/AG5 uses an 8-bit version of APE6/Gen2
+12:22 < geertu> So there are 3 versions
+12:23 < wsa_> ah, okay, so we still need the "syscon" property somewhen
+12:23 < geertu> But "It's slightly more complicated there, as we already have a driver for the
+12:23 < geertu> SYSC on R-Mobile (rmobile-reset), and a device node can't be bound
+12:23 < geertu> by both the syscon and the rmobile-reset driver.
+12:23 < geertu> " is no longer true
+12:25 < geertu> From a chat with Magnus a long time ago: "
+12:25 < geertu> Looking at datasheets, it seems the RWDT has a long history.
+12:25 < geertu> R-Car Gen2: 32-bit registers, using RST
+12:25 < geertu> R-Mobile APE6: 32-bit registers, using SYSC (APE6 has no RST block)
+12:25 < geertu> SH-Mobile AP4/AG5, R-Mobile A1: 16-bit registers with 8-bit (instead of 16-bit) watchdog counter
+12:25 < geertu> But the core is similar.
+12:25 < geertu> And of course AP4 and A1 are single-core"
+12:25 < geertu> RZ has a different control register layout
+12:26 < wsa_> ok, i have datasheets for all of them
+12:27 < wsa_> well, then, i'll do as I said before
+12:27 < geertu> I can test A1/AG5/APE6
+12:27 < wsa_> since there were no complaints ;)
+12:27 < geertu> and M2 and H3, of course
+12:27 < wsa_> geertu: \o/
+12:28 < wsa_> I ran out of topics
+12:28 < shimoda> About H3, as I wrote periperi ML, we can not write RST
+12:28 < shimoda> :)
+12:28 < wsa_> :)
+12:28 < wsa_> anything from your side left?
+12:30 < morimoto> nope
+12:30 < geertu> nope
+12:30 < horms> not here either
+12:31 < shimoda> no
+12:31 < wsa_> then we are done
+12:31 < wsa_> \o/
+12:31 < wsa_> thanks all!
+12:31 < horms> thanks!
+12:31 < morimoto> thanks
+12:31 < shimoda> thank you!
+12:31 < wsa_> have a great rest of the day
+12:31 < geertu> thx, cu
+12:31 < geertu> bye
+12:31 < shimoda> bye!
+--- Log closed Thu Oct 15 12:34:05 2015