path: root/wiki/Chat_log/20151201-core-chatlog

Core-chat-meeting-2015-12-01

10:02 < geertu> Today's Agenda:
10:02 < geertu> 1. Upcoming Gen3 development for the Core group,
10:02 < geertu> 2. control driving abilities of pins on PFC for SDHI,
10:02 < geertu> 3. Status check for tasks from last meeting - what is remaining?
10:02 < geertu> Topic 1. Upcoming Gen3 development for the Core group,
10:02 < uli___> 4. introduce neg, maybe?
10:03 < geertu> make it 0. Magnus?
10:03 < dammsan> right
10:03 < dammsan> what shall I say? =)
10:03 < dammsan> i'm very happy that a fellow Swede will work with us =)
10:04 < dammsan> Niklas will join our activity related to Core and Multimedia
10:04 < dammsan> doing some stuff this year, but full time from January
10:04 < dammsan> hopefully we can continue
10:04 < dammsan> oops, not full time by the way
10:04 < dammsan> that's what i wanted but could not get budget for
10:04 < dammsan> but anyway
10:04 < dammsan> i hope to be able to continue from April
10:05 < horms> Welcome Niklas!
10:05 < neg> thanks
10:05 < neg> and thank you magnus for the nice introduction
10:05 < dammsan> haha
10:05 < dammsan> so neg will share time between multimedia and core
10:06 < dammsan> can anyone teach him what core is all about?
10:06 < neg> if there is anything else feel free to ask, I think I meet some of you at ELCE
10:06 < dammsan> i think it is written in the SoW
10:07 < dammsan> so perhaps no need =)
10:07 < geertu> The goal
10:07 < geertu> for the Core group is to provide SoC enablement support to the customer and
10:07 < geertu> maintain the full range of already supported SoC features in the upstream Linux
10:07 < geertu> kernel in a coherent fashion. The Core group developer is expected to
10:07 < geertu> collaborate with group members on a best effort basis to develop and upstream
10:07 < geertu> Linux kernel modifications for frameworks, device drivers and SoC specific
10:07 < geertu> code. The Core group developer is asked to work with the group leader to
10:07 < geertu> iterate on yet-to-be-implemented feature lists as well as reference
10:07 < geertu> implementations. Hardware devices and areas expected to be covered by the Core
10:07 < geertu> group are:
10:07 < geertu> \begin{enumerate} \item ARM CPU clusters including SMP, caches and CCI / AXI \item Power control, clocks and reset such as APMU, SYSC, CPG, MSTP, RST \item Interrupts including GIC and IRQC and Timers \item Debugging hardware such as ARM core sight \item DMA controllers and IOMMU devices \item Pincontrol PFC and GPIO
10:07 < geertu> \end{enumerate}
10:07 < geertu> The group may select target platforms for reference implementations freely from
10:07 < geertu> the range of available boards with upstream support from Renesas. In case of
10:07 < geertu> R-Car Gen3 it may be necessary to use FPGA based target platforms. Remote
10:07 < geertu> access to development boards may be required depending on hardware platform.
10:07 < geertu> Care should be taken to simplify integration and ease back porting to LTSI
10:07 < geertu> kernels. Patches shall be posted to community mailing lists for upstream merge.
10:08  * geertu hopes it helps
10:08 < pinchartl> we can probably drop the FPGA mention nowadays
10:08 < dammsan> thanks mighty core group leader
10:08 < dammsan> there is always gen4 =)
10:09 < neg> thanks geertu, i think I got the gist of it from the SoW, but I have not been been able yet (due to the NDA situation) to read the tasks at osdr
10:10 < dammsan> maybe geertu can share the task information via mail to work around that
10:10 < dammsan> its not that the task information is secret or anything
10:12 < dammsan> about hardware, Niklas you have EMEV2 physical access, right?
10:12 < dammsan> with open docs
10:12 < neg> yes
10:12  * geertu sent task list to neg
10:12 < dammsan> we will deal with that and the NDA during December
10:13 < morimoto> I will accelerate R-Car H3 physical access for neg
10:13 < geertu> It's good to see i2c slave support proliferation
10:13 < dammsan> yeah
10:14 < neg> thanks for task list geertu
10:15 < geertu> Topic 1. Upcoming Gen3 development for the Core group,
10:17 < geertu> (Usually this is when Shimoda-san chimes in, but he's ill)
10:17 < dammsan> well, no need to micro manage
10:17 < dammsan> what is on the list from geertu? =)
10:17 < geertu> morimoto-san: Anything new from the Tokyo side?
10:18 < morimoto> It is listed as 2., otherwise nothing from me
10:18 < geertu> ok
10:18 < dammsan> i have one thing
10:18 < dammsan> which is SYS-DMAC support
10:19 < dammsan> it is somehow requested by customers
10:19 < dammsan> and we need to consider how to enable that at some point
10:19 < dammsan> it may be on the TODO already though
10:20 < geertu> SYS-DMAC seems to be highly device-dependant on Gen3
10:20 < geertu> e.g. MSIOF "works" with DMAC
10:20 < geertu> (modulo MSIOF bugs)
10:20 < dammsan> hehe
10:21 < geertu> dammsan: You had it working for SCIF TX and RX, right?
10:21 < dammsan> how do we enable it? via integration? v
10:21 < dammsan> ia defconfig?
10:21 < dammsan> yes
10:21 < geertu> Integration
10:21 < dammsan> nothing else than just integration
10:21 < dammsan> but that is one big switch
10:21 < geertu> I think it's already in the defconfig for audio
10:22 < dammsan> makes sense
10:22 < geertu> which means that integration will break things if it doesn't work everywhere
10:22 < dammsan> yeah
10:23 < dammsan> better break sooner than later =)
10:23 < geertu> I will retry for (H)SCIF
10:23 < dammsan> thanks!!
10:23 < dammsan> I intend to tackle IPMMU and SYS-DMAC in march some time
10:24 < dammsan> so it would be nice to have SYS-DMAC enabled by then if possible
10:24 < dammsan> or is that too rushed timing?
10:24 < geertu> Sure
10:25 < geertu> Sounds OK
10:25 < dammsan> great
10:25 < geertu> We don't have that many devices yet in dtsi that can break ;-)
10:25 < geertu> But SCIF is critical there
10:26 < dammsan> more than 1 wire = increased risk of breakage =)
10:26 < dammsan> i agree
10:26 < dammsan> how is that timed to the integration merge i wonder?
10:27 < horms> ?
10:27 < dammsan> i guess v4.5 without SYS-DMAC makes sense?
10:27 < geertu> E/February is v4.6-rc7
10:27 < dammsan> and SYS-DMAC in v4.6?
10:27 < geertu> yep
10:28 < horms> dammsan: that sounds reasonable. though if it works with the devices that are queued up then it could come in earlier imho
10:28 < geertu> indeed
10:28 < dammsan> yeah
10:28 < dammsan> sounds good
10:28 < horms> regarding merge. most of what is in next has been sent to Arm SoC (along with unrelated Gen2 changes)
10:28 < horms> they have been their usual silent selves at this part of the merge cycle
10:29 < dammsan> thanks for your efforts there
10:29 < horms> so i have so insight regarding how they feel about gen3
10:29 < horms> basicaly as expected
10:29 < dammsan> better keep the initial shot rather simple then
10:29 < geertu> yeah, it's never funny when your receive a late nack
10:29 < dammsan> at least that is my feeling
10:29 < horms> we will just have to handle it as best we can if it arrives
10:29 < dammsan> yeah
10:30 < geertu> Let's hope the clk people don't nack the new cpg/mssr driver...
10:30 < horms> probably during my chrismas dinner or something like that...
10:30 < dammsan> when does the SHMOBILE -> RENESAS move start?
10:30 < dammsan> yeah...
10:30 < dammsan> haha
10:30 < horms> ok
10:30 < geertu> I pinged Mike last week, he replied "thx"
10:30 < dammsan> just curious
10:30 < horms> so i put the Kconfig bit into next, the new symbol
10:30 < horms> so hopefully it ends up in v4.6-rc1
10:31 < horms> sorry, v4.5-rc1
10:31 < horms> so we can prepare driver changes to go in after that
10:31 < horms> i think
10:31 < dammsan> sweet
10:31 < geertu> Topic 2. control driving abilities of pins on PFC for SDHI,
10:31 < dammsan> geertu: can we help you with the cpg/mssr driver bits somehow?
10:31 < horms> if there is some urgency we can try to expidiate things somehow
10:31 < dammsan> not from my side
10:32 < geertu> dammsan: not really. Turning what we have in a pull request takes 10 minutes.
10:32 < geertu> Perhaps I should just send it now. without feed back ;-)
10:33 < dammsan> ok cool
10:33 < dammsan> thats fine with me =)
10:33 < geertu> Topic 2 is related to http://thread.gmane.org/gmane.linux.kernel.mmc/32684
10:34 < dammsan> high speed SD requires all sorts of things
10:35 < morimoto> Actually, I'm not sure it is related to this thread. Shimoda-san said "drive ability" on PFC for SDHI
10:35 < dammsan> maybe we can begin with bit bang SPI MMC? =)
10:37 < morimoto> Shimoda-san want to know who can do this
10:37 < pinchartl> I've reread the mail thread
10:37 < pinchartl> there was no disagreement about using the pinconf API
10:37 < pinchartl> but no real agreement either
10:38 < pinchartl> it's the most standard option we have no, it should be at least tried
10:38 < dammsan> this seems tightly connected to SDHI driver development
10:38 < dammsan> difficult to test without driver
10:39 < dammsan> and the driver cannot do high speed without the special clock handling (at least on gen2)
10:39 < dammsan> seems a bit tricky from my side
10:39 < dammsan> perhaps someone has some fresh ideas
10:41 < pinchartl> can't we just check the signals with a scope ?
10:43 < pinchartl> I don't think we need to test much beside the voltage
10:43 < geertu> I assume the SD cards itselves are +1.8v-toleratn?
10:43 < dammsan> hm, untested code is broken code
10:45 < pinchartl> geertu: you don't even need to connect an SD card, just making sure the SoC drives the MMC signals at 1.8V should be enough
10:45 < pinchartl> dammsan: it won't be untested
10:46 < dammsan> according to wikipedia UHS-II is 0.4V
10:46 < pinchartl> I thought the patch series only introduced 1.8V driving capability ?
10:47 < dammsan> yes
10:47 < dammsan> the SDHI hardware supports UHS-II as well
10:47 < geertu> pinchartl: I'm more worried about accidentally driving a too-high voltage
10:47 < dammsan> but the series only does UHS-I
10:47 < dammsan> but this can be verified by the device driver people, no?
10:48 < dammsan> they have tons of other stuff to verify anyway
10:48 < dammsan> not sure i see the merit of breaking out a single thing like this
10:48 < dammsan> or am i thinking backwards?
10:48 < horms> who are the device driver people?
10:48 < pinchartl> geertu: the cards shouldn't mind
10:48 < dammsan> i guess BSP people
10:49 < pinchartl> and you don't even need to insert a card to measure the voltages anyway
10:49 < horms> dammsan: ok
10:49 < geertu> How does the SoC know it should switch to 1.8v? Card detection pins?
10:50 < dammsan> by reading out data structure from the SD card
10:50 < dammsan> it is sort of like PCMCIA or any other bus
10:50 < horms> does it read the structure using v1.8?
10:50 < dammsan> the MMC subsystem and the driver ramp up the speed and decrease voltage during detection
10:51 < geertu> So you can't just measure the pins without a card
10:51 < dammsan> i don't know the details except that it varies based on capability of each card
10:51 < dammsan> well you can write a mock-up that somehow controls the PFC
10:51 < dammsan> and then verify the pin output or something
10:52 < dammsan> but PFC support without driver is not very useful anyway
10:52 < pinchartl> dammsan: no but PFC is a dependency for the driver
10:52 < dammsan> well, SDHI is not any different from any otehr driver
10:52 < dammsan> exept it has some more advanced PFC toggling to do
10:53 < dammsan> it all ties to the driver IMO
10:53 < dammsan> or how would you guys do it?
10:54 < dammsan> PFC tick-box? =)
10:54 < pinchartl> I'd implement it on the PFC side and test it using a scope or multimeter
10:54 < pinchartl> and then implement it on the SDHI side
10:55 < dammsan> in the non-existing driver? =)
10:55 < dammsan> or part of upstreaming process i guess
10:55 < dammsan> SDHI on Gen3 has on-device DMAC engine
10:55 < dammsan> different from Gen2
10:56 < uli___> horms: https://www.sdcard.org/downloads/pls/part1_410.pdf, page 17
10:56 < dammsan> Gen2 did not get UHS-I and UHS-II working upstream
10:56 < dammsan> we are way behind
10:56 < pinchartl> dammsan: frankly I don't see where the problem is. SDHI depends on PFC, if we want UHS in SDHI we just need to implement drive voltage selection on PFC
10:57 < horms> uli___: thanks
10:57 < dammsan> that solves part of the problem yes, but seems difficult to test without basic SDHI support
10:58 < geertu> As we have SDHI on Gen2, and SDHI on Gen3 needs more DMA work first, I think it makes sense to have working UHS on Gen2 first
10:58 < dammsan> i think so too
11:00 < dammsan> prediction: SDHI will bounce back and forth between I/O and core forever
11:01 < horms> fwiw p23 of the document uli___ posted above indicates 0.4v for USH-II in its super speedy modes
11:01 < dammsan> pinchartl: one initial step could be to add PFC SDHI support for low speed modes
11:01 < pinchartl> if that's the case then it shows that the core/io split is inefficient
11:02 < dammsan> i think we need resources on both sides
11:02 < dammsan> and most of all, a coherent plan about upstream support for SDHI
11:02 < horms> dammsan: ideally between the same person who is on both teams
11:03 < dammsan> no shit
11:04 < dammsan> i don't think we can do minor task juggling and assume SDHI will solve itself
11:04 < dammsan> IMO it needs dedicated resources that understand MMC
11:04 < horms> so is this a techincal problem, a resource problem, both, or something else?
11:05 < dammsan> all of the above =)
11:05 < dammsan> we are starved resource wise and not too many of us understand mmc. and this makes me grumpy. =)
11:06 < dammsan> i will now be silent
11:06 < pinchartl> dammsan: would you be less grumpy if Guennadi was still working on MMC ? :-)
11:07 < dammsan> i bet a 24-pack of beer that we would not have UHS support anyway
11:07 < dammsan> i would like to get vitaly wool to work on MMC for us
11:08 < dammsan> someone that cares about MMC needs to do the job
11:08 < pinchartl> I agree
11:09 < dammsan> until then SPI bitbang support is more than enough for upstream =)
11:10 < geertu> I wrote down:
11:10 < geertu>   1. PFC 1.8V switching first,
11:10 < geertu>   2. Then SDHI UHS support on R-Car Gen2,
11:10 < geertu>   3. Later SDHI UHS support on R-Car Gen3, which needs DMA rework, too
11:10 < geertu>      (DMA rework can be done in parallel).
11:10 < geertu>      
11:10 < geertu>   Last two topics are for the I/O Group.
11:10 < dammsan> about 1. - is that for Gen2?
11:11 < dammsan> your notes look fine to me
11:11 < dammsan> thanks.
11:11 < geertu> 1. can be Gen2 and/or Gen3
11:11 < geertu> Gen2 as dependency for 2.
11:11 < geertu> Gen3 as dependency for 3.
11:11 < dammsan> yeah
11:11 < dammsan> makes sense
11:12 < dammsan> how about SDHI PFC support for Gen3 w/o UHS?
11:12 < dammsan> there must be something in the BSP?
11:13 < dammsan> to give a base for initial Gen3 development I mean
11:13 < dammsan> perhaps the BSP can be used for that
11:13 < geertu> Typically the driver enabler and integrator makes sure the basic pfc support is there
11:13 < dammsan> i agree
11:14 < dammsan> so no need to track then i suppose
11:15 < horms> I see this in the Gen3 bsp
11:15 < horms> f51b11c pinctrl: sh-pfc: r8a7795: Add SDHI support
11:17 < horms> and on the driver side
11:18 < horms> 5b8dd5dff00f mmc: sh_mobile_sdhi: Add eMMC support for r8a7795
11:18 < horms> 683cb4320a67 mmc: tmio: Add eMMC support for r8a7795
11:18 < horms> cb59cb82692e mmc: sh_mobile_sdhi: Add UHS-I mode support for r8a7795
11:18 < horms> 473a624e3440 mmc: tmio: Add UHS-I mode support for r8a7795
11:18 < horms> 66b27d5cbe7b mmc: sh_mobile_sdhi: Add r8a7795 support
11:18 < horms> 96c02b056fb3 mmc: tmio: Add r8a7795 support
11:18 < horms> 785f4628444f Revert "mmc: sdhi/tmio: rcar: Add r8a7795 support"
11:18 < horms> efd45f6ea410 mmc: tmio: Add status error check
11:18 < horms> 4e519381d10d Revert "mmc: tmio: Add UHS-I mode support"
11:18 < horms> 5bbe19aea122 mmc: sh_mobile_sdhi: Fix SD_BUF width for R-Car Gen3
11:18 < horms> 0d8f78ab3cdc mmc: tmio: fix disabling tmio dma for R-Car Gen3
11:18 < horms> b96537bff2c2 mmc: tmio: add support for R-Car Gen3 SDHI DMAC
11:18 < horms> b425728e221f mmc: sh_mobile_sdhi: add some SoC specific data for R-Car Gen3
11:18 < horms> 584fc6070900 mmc: tmio: add max_segs and max_blk_count in tmio_mmc_data
11:18 < horms> 4c38cc2e4fcd mmc: sdhi/tmio: rcar: Add r8a7795 support
11:18 < horms> 47755b706ba8 mmc: tmio: Add error check for data access end
11:18 < horms> 46d20a281a1a mmc: tmio: Add UHS-I mode support
11:18 < horms> 6ee75f7dcc90 mmc: tmio: Add SD clock start/stop wait pass option
11:18 < horms> 4ce1fa499997 mmc: sh_mobile_sdhi: Add UHS-I mode support
11:18 < horms> d6c4f144238b mmc: tmio: Add SDCLK enable after reset
11:18 < horms> bf72c2b9b270 mmc: sh_mobile_sdhi: Add EXT_ACC register busy check
11:18 < horms> 0df9d2eae5e1 mmc: tmio: Fix timeout value for command request
11:18 < horms> so there seems to be something there
11:18 < horms> i have not looked inside
11:19 < dammsan> thanks
11:20 < dammsan> So either that PFC commmit contains 1.8V switching or the UHS-I mode is broken
11:20 < horms> i suspect the later
11:20 < horms> after glancing over the code
11:21 < dammsan> maybe zero chance
11:21 < dammsan> perhaps the correct approach is to develop a test method
11:22 < horms> https://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git/commit/?id=f51b11c
11:23 < dammsan> this looks sane enough to me
11:23 < dammsan> at least the data bus was split into 1/4/8 which shows some consideration
11:23 < morimoto> 802218c1d6c3b91151ba086bda916b90a54bd35e :: sh_mobile_sdhi_set_ioctrl ?
11:24 < geertu> PINMUX_IPSR_MODS -EINVAL
11:25 < geertu> Any other PFC SDHI UHS?
11:26 < geertu> Topic 3. Status check for tasks from last meeting - what is remaining?
11:26 < dammsan> everything for me =)
11:26 < geertu> "pfc: Improve documentation" is WIP
11:26 < horms> morimoto: which tree is that commit in?
11:26 < dammsan> i got IPMMU + DMAC + SCIF working btw
11:26 < geertu> "r8a7795: Add full (H)SCIF nodes to DT" is done
11:27 < dammsan> thanks for that
11:27 < morimoto> horms: git log backport/bsp/v3.10.31-ltsi/rcar-gen2-1.9.6 drivers/mmc
11:27 < horms> thanks
11:27 < geertu> "r8a779[0-4]: Fix earlycon support on R-Car Gen2 etc." has patches
11:28  * geertu will switch to v2 tasklist later today
11:28 < geertu> "Propose API to obtain mode pin values in a generic way"?
11:29 < horms> i need to pick that up again
11:29 < horms> sorry for the delay
11:30 < dammsan> horms: did you get stuck about the color of the shed?
11:30 < dammsan> =)
11:30 < horms> yes
11:30 < horms> we are going to taks a wider audience for ideas
11:30 < horms> probably overyone has one
11:30 < dammsan> lovely
11:31 < horms> probably everyone has one
11:31 < dammsan> i'm glad you are dealing with it =)
11:31 < dammsan> (and not i)
11:33 < dammsan> can this be tied into EMEV2 i wonder?
11:33 < horms> i am prototyping with koelsch but my working assumption is that the possibilities are endless
11:33 < dammsan> maybe no boot mode consumer, i don't remember
11:34 < dammsan> probably
11:35 < neg> there is a bootmode dip-switch on the EMEV2 but I never touched it
11:35 < horms> my EMEV2 moved to Tokyo
11:36 < horms> I guess it wanted to be closer to home
11:36 < dammsan> horms: if you need help pls let us know
11:37 < horms> will do
11:38 < dammsan> geertu: what is your biggest headache at this point as core group leader?
11:39 < geertu> sending spare time to people listed in MAINTAINERS?
11:39 < horms> lol
11:40 < horms> perhaps we shuld prepare some time-parcels as christmas presents
11:40 < pinchartl> I'd love that !
11:43 < dammsan> what a great idea
11:45 < geertu> Any other topics?
11:48 < dammsan> only next meeting time =)
11:48 < geertu> What about Tue Dec 15, same time?
11:49 < geertu> and same place, of course
11:50 < pinchartl> I'll be in the wrong time zone then
11:50 < pinchartl> (PST)
11:51 < geertu> Then please ignore
11:52 < dammsan> 15th is fine with me
11:52 < uli___> me, too
11:52 < pinchartl> I won't ignore it but I'll skip it, with the deepest sorrow of course :-)
11:53 < horms> that time is good for me
11:53 < neg> should work for me
11:55 < horms> Thanks everyone for their time, i must away now
11:55 < dammsan> thanks!
11:55 < geertu> Thanks, and CU
11:55 < uli___> bye
11:56 < neg> thanks, bye
11:56 < pinchartl> thank you Geert
11:56 < pinchartl> bye bye
11:58 < morimoto> geertu: sorry for my delay. I'm OK on Dec 15
11:58 < morimoto> and bye