path: root/wiki/2017-02-miniperi.wiki

h1. +MiniPeriCon for Core/IO 2017-02+

| Date  | 2017/02/03 (Friday before "FOSDEM":https://fosdem.org/2017/) |
| Place | "PERIPERI BE@Hotel BLOOM!":http://www.hotelbloom.com/en/location/hotel-bloom.html |
|/10. Member | Geert |
| Laurent |
| Niklas |
| Simon |
| Wolfram |
| Kieran |
| Magnus |
| Ito-san |
| Jacopo |
| Marek (afternoon) |

| 09:00-09:30 | Welcome Coffee | Meeting Lounge    |
| 09:30-10:30 | I/O Meeting 1  | Boardroom C       |
| 10:30-11:00 | Coffee Break   | Meeting Lounge    |
| 11:00-12:30 | I/O Meeting 2  | Boardroom C       |
| 12:30-13:30 | Lunch          | Smoods Restaurant |
| 13:30-15:30 | Core Meeting 1 | Boardroom C       |
| 15:30-16:00 | Coffee Break   | Meeting Lounge    |
| 16:00-16:30 | Core Meeting 2 | Boardroom C       |
| 16:30-18:00 | Misc           | Boardroom C       |

!2017-02-miniperi/elc201702.jpg!

h1. +%{color:#0000FF}Core Group%+

h2. Agenda

h3. Early H3 ES2.0 remote access for PFC (+CPG) next batch development this quarter

h3. M3-W integration of Audio/USB/SMP and CPU Hotplug (Simon and maybe Geert)

h3. Remaining M3-W integration for Core (INTC-EX, PMU, cache, memory size) (Geert and maybe Simon)

h3. How to get the M3-W IPMMU DT binding upstream

h3. Integration order of IPMMU devices, workaround needed in IPMMU driver

h3. Gen3 Power Management

* CPU Idle
* CPU Freq
* CPU Hotplug
* Suspend-to-RAM

h3. Future Power Management with DFS/DVFS (probably depends on PMIC driver)

h3. PMIC driver development (Might be something for Marek? How to handle closed docs?)

h3. DMA priority handling (RX needs higher prio than TX)

h3. DMA descriptor mode on-chip RAM support

h3. RZ PFC driver future directions

h3. Renesas-drivers integration procedure and purpose

h2. Restructured Minutes

h3. Additional tasks (preliminary assignment)

* M3-W Audio/USB integration (Simon)
* M3-W SMP bringup (Geert? or part of base?)
** big.LITTLE: postpone LITTLE CPUs, cfr. H3
** Track big.LITTLE patch
* Investigate suspend-to-idle (Geert) (code in BSP?, fails for e.g. DU?)
* Salvator-X PMIC DVFS (Marek)
** DDR backup mode optional, depending on outcome of questions below
* SYS-DMAC slow mode trial (for e.g. SCIF hardening) + priority handling (Niklas)
* Uniform memory/cache handling on H3/M3-W and Salvator-X/ULCB
* CPU Freq (take over from Khiem)
* SYS-DMAC decriptor mode on-chip RAM support

h3. (base) tasks

* ES2.0 basic usage with remote access (hopefully next week?) (Geert)
* IPMMU integration (DT), after review of the (already merged) DT bindings by Rob Herring (Magnus)
** Workarounds in IPMMU need more TBD
* RZ/A1 PFC/GPIO: (Jacopo)
** Compatible value "renesas,r7s72100-ports"
** New driver in drivers/pinctrl/pinctrl-rza1.c
* CPG/MSSR, reset for R-Car Gen2 (Geert)
** Needs DT update, good to combine with the flag day for making APMU (R-Car H2/M2-W) and SYSC (R-Car H1 and Gen2) mandatory in DT.


h3. Future core topics

* DTS sharing:
** H3 ES1.0 and ES2.0
** H3/M3 ULCB aka Starter Kit Premier/Pro
* DEV Freq: in addition to CPU Freq (needed for GPU, as DVFS is shared between CPU and GPU)
* git merge driver to ease merging DTS files?
* Reset Controller debugfs, to reset devices manually (at your own risk)

h3. Questions related to the PMIC on Salvator-X for (tunneling through) Morimoto-san/Shimoda-san

* There's no mutex for PMIC access shared between PSCI and a Linux driver.
**Is there a possibility of conflicts?
* Currently userspace has to make sure to configure DDR backup mode using "i2cset -f -y 7 0x30 0x20 0x0F" before suspending using "echo mem > /sys/power/state", else the system won't resume later.
**Is there a specific reason why the firmware doesn't configure DDR backup mode itself?
**Alternatively, this could be handled in the Linux PMIC driver. 

h3. Questions we had during the meeting

* Does offline cpu0 work on H3? Yes, with firmware v2.16.0.
** cpus=/sys/*/*/cpu/cpu[0-9]*
** for i in $cpus; do echo 0 > $i/online; echo 1 > $i/online; done
** for i in $cpus; do echo 0 > $i/online; done; cat /proc/cpuinfo
** for i in $cpus; do echo 1 > $i/online; done; cat /proc/cpuinfo
* Note that after adding the CA53 nodes to r8a7795.dtsi, CPUs 4-7 are present in sysfs, but fail to come up with -EINVAL.
** So (currently) we would not introduce undeterministic scheduling behavior due to migration between big and LITTLE cores by adding CA53 device nodes to DT.

h1. +%{color:#0000FF}I/O Group%+

h2. next tasks (base and additional)

* Remaining M3-W integration for I/O ((H)SCIF, PWM)
* On-board ADC support (for Jacopo)
* SCIF FIFO upstream status and next step
* SCIF hardening via DMA slow mode (prototype next quarter ?)
* SDHI DMA upstreaming (and further SDHI topic priorization)

h2. Niklas SDHI&IPMMU problem

h2. TDSEL research and maybe discussion about results

h2. I2C IP core switcher for Lager DVFS bus

h2. Reprogram device registers after resume from Suspend-to-RAM

h2. Meeting Minutes

We talked about and clarified some tasks. Current scheduling for base tasks is:

* Jacopo - ADC: add MAX9611 driver
* Niklas - Thermal: add interrupt support
* Ulrich - SCIF: continuation of upstreaming his SCIF series
* Wolfram - I2C: continue upstreaming I2C core switcher patches

Additional tasks are still TBD, but we'll start negotiating right now.

For the SDHI DMA upstreaming tasks, it looks like we need a preparational task beforehand, though, because of "Arnd Bergmann's review":http://www.spinics.net/lists/linux-mmc/msg38004.html, and we agreed that his requests are reasonable.

The "slow DMA" topic is about a feature to enable an additional divider that will make DMA so slow, that it might trigger buffer underruns etc.
While this might be useful to test IO drivers, the feature itself is a core task.

The TDSEL for SDHI topic is probably interesting to research. But to convince other people inside Renesas, we need to proof that with the data we have in an easy to recognize form. Simon wants to start and elinux page about SDR104 and Wolfram will update it with TDSEL info.

In the io/todo list, the SDHI items are now somewhat sorted according to current priorities.

h1. +MiniPeriCon for MultiMedia 2017-02+

| Date  | 2017/02/19 |
| Place | "ELC":http://events.linuxfoundation.org/events/archive/2017/embedded-linux-conference  |
|/5. Member | Laurent |
| Niklas |
| Magnus |
| Morimoto |
| Ito-san |

h2. Process

How to handle continuous multimedia integration

h3. Current situtation:

* Code only released once, at task completion
* No later releases (in the sense of sending a pull request to renesas-drivers, as required by SoWs) during rework (but obviously new versions of patch series get posted).
* In case of Laurent separation between "release" and "light release" is made, where the former includes more broken out topic branches and the latter a combined snapshot release.
* Many work in progress branches due to the nature of multimedia development that often require API or framework changes.
* This results in many merge conflicts in renesas-drivers
* V4L2 upstream moves fast sometimes which requires work to be rebased and updated.

h3. Our team has to deal with two workflows:

* The upstream development workflow aims at developing code that will eventually be merged upstream. This workflow is heavily based on work-in-progress patch series and branches, and don't deal with release management other than trying to finish the work before the next merge window.
* The release workflow aims at providing periodically tested bundles of all the work in progress code from the whole team, through the renesas-drivers tree. Geert handles the release process, updating the tree by pulling from team members' git trees.

The whole team should try to help with the release process as much as possible without having to spend a significant amount of time on release-specific issues. To that end, we propose the following process named "light release":

* When new version of a patch series is posted to a public mailing list, the developer shall create a tag pointing to a branch in his/her git tree that contains the patches.
* The git tree URL and the tag name shall be included in the cover letter.
* When possible tags for different topics shall point to separate topic branches, but they may point to a linear branch that contains multiple patch series posted separately. (Topics in this context can mean driver code vs. DT, as well as different features for a single driver).
* The base point for the branches shall contain only the required dependencies (i.e. branches shall not be based on the latest linux-next).
* The base point shall be based on a merge of public branches and shall not cherry-pick commits unless absolutely necessary.
* A common naming scheme for these tags should be agreed upon to ease consumption and increase value for them in renesas-drivers.
* Geert shall make sure to pull the tags into renesas-drivers to keep track of the history.
* Individual developers can drop branches and tags when the associated patch serie(s) are merged upstream.
* This process will be reevaluated after a few weeks/months/releases to see how often serious merge conflicts have to be handled by Geert, and can be improved if needed.
* The notification that a new topic branch needs to be included in renesas-drivers takes the form of the pull request sent at additional task completion.
* The notification that a new version of a topic branch is available takes the form of pushing a new tag that will then be noticed when Geert pulls from the developers' git trees.
* No notification that a topic branch can be dropped is deemed necessary as that shall be apparent when merging mainline. If a topic branch needs to be dropped without it being merged in mainline, an explicit notification may be necessary.
* Regarding notification, if we handle feature branches or per-driver branches needs more discussion with Geert and the rest of the group.

One common root cause of merge conflicts seem to come from when multiple feature branches are used for the same driver and ordering and/or base is unknown.
For areas with less active development or more simple hardware only single feature branches or a single per-driver branch is used which does not cause any conflicts, so the merge conflicts that we see only seem to occur in areas with multiple features or multiple devices. Multimeida devices are a good example of this.


h3. Acceptance test requirements from Jinso

* above "taging" solves almost all issue on Jinso
* They want to know each member's using distribution to confirm. We could event standardize the rootfs across the team, but there's real value in having diverse rootfs and distribution to widen the test coverage. Kernel features should not be dependent on a particular rootfs, and if Jinso experiences rootfs-related issues debugging them is useful. We would thus like not having to provide rootfs information.
* They want to know how to confirm result. Some of member's report was not enough
* Most items on the requirement list seem like noise, however kernel configuration seems to be one important piece of information.
** When specific configuration symbols need to be enabled and are not obvious for an average kernel developer they should be documented in the test procedure.
** Kernel configuration distrubution should be kept out of public malinglists to reduce noise for the community.
** Copying the .config in the PDF report is not an efficient option.
** Attaching the configuration to the report e-mail could be an option.
* Magnus proposes handling issues on-demand for development testing instead of trying to specify a complete environment (which probably is more suitable for release testing).
* Renesas should help/handle them first

(Related to kernel configuration but not strictly in topic) For Gen2 we have an shmobile defconfig upstream which we can keep up-to-date with all configuration options needed to enable all Renesas-specific features and optimize performances. For Gen3 we can't push a Renesas-specific defconfig upstream. There is however value in maintaining and sharing defconfigs among the team, as well as with Jinso and Renesas. One option could be to keep them in renesas-drivers.


h3. Feedback to hardware designers

We have an open window to provide feedback for the next generation. Komatsu-san is tasked with reporting Linux-related issues to the hardware designers.

* We shall report our issues to Komatsu-san and document them in the wiki. The target is end of February.
* SoC issues and board issues shalle be split.


h2. Current status, issues and plans

h3. Display (Laurent)

h4. Current state of HDMI output

* The patch series is feature-complete.
* Patches have been reviewed quite widely as the IP core is used in SoCs from different vendors.
* Lots of review feedback has been incorporated already, remaining work is estimated to 10 more. ETA is v4.12.
* This covers both H3 ES1.x and M3-W. H3 ES2 will likely not require extensive development for HDMI output, but display core will need work.

h4. H3 ES2.0 support (DU + VSP)

* Rework of the VSP and DU drivers is needed.
* Remote testing will be painful, as many reboot cycles are expected.
* Local testing could be performed around LCJ at end of May.
* This requires dependencies to be available by that time (clocks, PFC, ...)
* H3 ES2 early testing will be performed on the current version of Salvator-X, but the final board will be different.
* We need to target Q2. ASAP is best, but batch one is likely too early.

h4. M3-W Multimedia integration

* Patches are ready.
* They were held off in the hope that we would enable IPMMU first.
* Given that IPMMU support is delayed due to erratas we can enable DU on M3-W now.
* Laurent will resend the patches.

h4. DU and VSP support on Gen2

* The VSPD can be used in combination with the DU on Gen2 as we do on Gen3. However, this is optional on Gen2 and mandatory on Gen3.
* We have received information that the Gen2 DU has bus mastering problems (likely under high load) that makes the DU unreliable.
* Sergei has posted patches to hardcode VSPD + DU usage on Gen2 as done on Gen3. We suspect that this is a response to the bus mastering issues, and that is comes from a Renesas request.
* Changing this would modify the userspace API in two ways: the DU would have less planes than it does now, and the VSPD would become unavailable for other purposes.
* We don't want to hardcode VSPD + DU on Gen2 unless DU bus mastering is so unreliable that it can't be used at all in any product (and some products might even not use the DU at all but use the VSPD for other purposes).
* As we failed to get more information from Renesas, let's wait to see if Sergei applies more pressure.

h4. On-going chrome book staging driver GPU hacking

* The next step is to boot a mainline kernel on the Chromebook
* We have no serial console, so debugging is difficult.
* Multiple options are possible (serial console, netconsole, USB-C SBU, ...)
* We should schedule an additional task to boot mainline on the Chromebook.
* If we achieve this, we'll continue GPU development through this path. Otherwise we'll be blocked.

h4. DU/VSP fence

* DU fence support is working. Patches have been posted.
* Upstreaming depends on 4 patches from Maartne Lankhorst that should be merged in v4.12. If all goes according to the plan, the DU patches will be upstreamed in v4.12 as well.
* On the V4L2 side we're missing a fence API. Collabora is working on it, Laurent will meet with them this week at ELC to check the schedule. We may need to help with development.

h4. Graphics performance issue

* We have a reliability problem that results in flicker due to a VSP + DU race condition.
** An additional task will be scheduled for the second batch of Q1 for Kieran. ETA is 3/M for an upstreamable fix.
* We have performance issues with the display.
** Cache handling is known to be a problem, we're working on it.
** Fences will also help improving performances. Fence support on both the VSP and DU sides is needed, fence support on the DU side only will not help at all.
** Other causes of performance problems could be hunted for if we still don't get good enough performances after solving the cache issues and adding fences support.

h3. Audio (Morimoto-san)

h4. HDMI sound

* Early prototype was based on Ulrich's HDMI video prototype
* Last version is based on top of Laurent's HDMI video patches.
* DT bindings based on OF graph. Rob Herring didn't nack the approach, but hasn't agreed yet either.
* ALSA core OF graph patches were posted which depend on OF graph DT bindings.
* dw-hdmi audio driver was accepted already.
* HDMI sound will be posted if OF graph patch set was accepted

h3. Camera (Niklas)

h4. How to move forward with VIN integration

* The VIN userspace API will behave differently on Gen2 and Gen3.
** On Gen2, everything is controlled through a V4L2 device node.
** On Gen3, the media controller API will be exposed to configure the device.
* Current status
** VIN implements the Gen2 behaviour on Gen3.
** The media controller API is used to configure routing.
* Work needed
** Move to a media controller-based API.
** Possibly split VIN in two drivers for Gen2 and Gen3.
** Rework how subdevices are parsed from DT.
** Provide documentation and userspace scripts to configure the media device graph for streaming.
** Prototype driver for ADV7482 should be made upstreamable.
*** Could be done by another member of the multimedia group.

h4. How to handle on-board codec driver support for VIN/CSI

* Architecture design and APIs have been agreed in the VIN/CSI meeting in Finland on 2017-02-15.
* Most of the work needed is in V4L2 framework changes that are needed for proper Gen3 VIN support anyway.
* The ADV7482 driver itself won't take much time once the framework changes are in place.
* Framework changes and ADV7482 development must be handled together as the latter is needed to test the former.

h4. CSI-2 virtual channel support

* Development will be based on a custom hardware setup connected to the Salvator-X, based on
** A MAX9286 board connected to Salvator-X, with 8 GMSL (Gigabit Multimedia Serial Link) inputs.
** 8x MAX9271 boards with one GMSL output and OV10625 one camera sensor.
* We can also connect the MAX9271 boards to a V2H Blanche board which has an on-board MAX9260 GMSL to parallel receiver.
** This would require developing a MAX9260 driver, as well as extending the VIN Gen2 driver to support chained external subdevs.
* Morimoto will send 1 rental expansion board (1 MAX9286 expansion board + 8 cameras (MAX9271+OV10635) and cables) to Niklas first. It should be back to Renesas in the future.
* Morimoto is buying 2 expand board sets. Camera will be deliveried at May. It will be sent to Niklas and Laurent.
* We need
** V4L2 API extensions to support multiplexed streams for CSI-2 virtual channels.
*** Frame descriptors API
*** Make subdev operations pad-aware
*** .s_stream() extensions to support stream IDs
*** Sakari Ailus has prototype patches for frame descriptors. More work is required, we need to take over.
** Drivers for the MAX9271 and MAX9286 transceivers (code found on TI forum, one patch with 7k LoC with a single driver that covers both chips).
* We have the MAX9286 datasheet under NDA, and the MAX9271 datasheet is public.
** Driver for the OV10635 camera sensor (out-of-tree Android driver found based on soc-camera writtne by Phil Edworthy).
* Morimoto needs to check datasheet availability (likely under NDA).
** Would be nice if Salvator-X on board use-case was acked for upstream before moving with too much VIN multiple channel work ontop to reduce potential wasted effort.

h2. Miscellaneous

h3. Lossy compression support
    
* There's no request from the BSP team (they have a custom solution).
* Would be nice to have, but we have more urgent issues.
* Let's schedule it when we'll have time.
* More research is needed to find out how the feature exactly works.


h2. Long Term Planning

The additional tasks arrangement is not working well for the multimedia group. 
We will discuss the problems, and propose an alternative solution based on a 
long term plan.

* For next unit of time have each member of the Multimedia group take responsebility for some feature already posted and drive that to be merged upstream.
* Keep SoW for base tasks for developers to define the scope and expeced output for each task
** Group leaders repsonsebility to make sure definition exsists, can be outsourced to group memebrs,
** Recored definitions in wiki.
** Fllow up on task progress during bi-weekly meetings.
*** Each member reports on his/her task and if it's following the time plan or if is moving faster/slower. Valid feedback is also that a task is on track but will take more calender time due to delay in review process for example.
*** Each member should know when leavng the meeting what to do next.