diff options
Diffstat (limited to 'wiki/Chat_log/20151201-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20151201-core-chatlog | 349 |
1 files changed, 349 insertions, 0 deletions
diff --git a/wiki/Chat_log/20151201-core-chatlog b/wiki/Chat_log/20151201-core-chatlog new file mode 100644 index 0000000..747dac5 --- /dev/null +++ b/wiki/Chat_log/20151201-core-chatlog @@ -0,0 +1,349 @@ +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 |