--- 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