path: root/wiki/2016-02-periperi.wiki

h1. +PeriPeriCon 2016/02+

| Date  | 2016/02/01 - 2016/02/04 |
| Place | Brussels, "Bergestraat 60, 3220 Holsbeek":http://www.vakantiehageland.be/wegbeschrijving |
|/8. Member | Geert |
| Laurent |
| Magnus |
| Morimoto |
| Niklas |
| Simon |
| Wolfram |
| Ulrich |

!2016-02-periperi/periperi1.jpg! !2016-02-periperi/periperi2.jpg!
!2016-02-periperi/periperi3.jpg! !2016-02-periperi/periperi4.jpg!

h1. +iot.bzh meeting+


Fulup has requested a chart that describes the organization of our team with a short description of responsibilities for each team member.

h2. Bug tracking system

What does it target ?
Munakata-san seems to want to open a BTS to key customers Public or private ? If public, bugzilla.kernel.org ?

If the BTS becomes public, we can't pull the plug all of a sudden as customers will depend on it, even if the BTS ends up not being very useful for us.

If we use a BTS outside of Renesas infrastructure customers will more likely see it as separate from the commercial support -> less impact on Renesas image, less pressure to deal with bugs ASAP.

Requirements on what we accept as bugs ?

-> Only if it applies to code in linux-next
-> Reporter responsible for testing on latest mainline, we can reject bugs filed against older versions if we want to (but we don't have to)

This requires documentation to enable developers to run the latest mainline version on their boards. Published on the e-linux wiki.

h3. Conclusion

Explore options on kernel.org for issue tracker

h2. Security

- Secure boot
- Secure memory

Check what the hardware can do, decide on the architecture, find out missing pieces from the documentation.

Come up with a plan regarding how to deal with the existing security team(s).
Need approval from high up in the food chain.

h2. Memory

Enable more than 4GB of memory space.

Must come with a plan, requires investigation first.

Simon will coordinate.

h1. +Core Group+

h2. IPMMU

h3. IPMMU with DU

Memory <- FCP <- VSP <- DU

The IPMMU should be referenced by the FCP DT node. The DU driver needs to use the FCP struct device for the DMA mapping API.
*Issue*: there's a single DU device for all DU channels, backed by multiple VSP instances, FCP instances, and thus IPMMU channels. However, when we allocate a buffer we don't know which DU channel it will be used with.

h3. IPMMU vs DMAC framework changes

* Action plan
# 2/B: Soft approach to Vinod by Geert, Laurent and Wolfram
# 3/B: Escalate. Most likely to AKPM
# 3/M: Submit workaround
* We integrate disabled IPMMU and SYS-DMAC support after DT binding is stable.

h3. IPMMU Gen2 integration

* Enable DU IPMMU on Gen2 for v4.6

h3. IPMMU multi-context:

* Too many hardware devices and limited number of contexts
* Laurent recommends round robin assignment for 8 contexts

h3. IPMMU ARM32 dma-mapping conversion

* Laurent agrees that this conversion is lower priority than r8a7795 enablement

h2. +Cache coherency support+

how does our hardware and software compare to other vendors?

h2. +new CPG/MSSR driver for other SoCs+

* Dependencies: mode pins

h3. Conversion benefits

* Consistency
* Reset support
* More test coverage for new architecture
* Saves memory (DT storage in RAM)

DT backward compat maintained for a couple of stable release, ~1 year, then removed. Can be disabled through a Kconfig option.

h3. General: CONFIG_PM=y

We have a workaround for systems compiled with CONFIG_PM=n (in drivers/sh/pm_runtime.c). Should we mandate CONFIG_PM=y and remove the code ?

The only known drawback is increase in memory footprint. This only affects RZ/A1H as other SoCs have more than enough memory. Geert will measure the impact.

<pre>
Comparing kernel size for a kernel .config with CONFIG_PM disabled, and
making ARCH_R7S72100 select PM and PM_GENERIC_DOMAINS,
bloat-o-meter says:

    add/remove: 237/4 grow/shrink: 128/8 up/down: 28614/-728 (27886)

which looks like a modest increases.
This can probably be more than offset by converting RZ to CPG/MSSR later.
</pre>

h2. +PFC need more support+

h3. PFC

* pull up and pull down DT binding and reference implementation exists
* pull up/down exists as "bias" but we do not specify ohm value
* voltage setting DT binding accepted upstream as power source
* voltage setting DT binding should specify a numerical mV value
* drive strength DT property is specified as "drive-strength"
* current setting DT binding should specify a numerical mA value
* capacitance DT binding does not currently exist
* gen2 PFC SDHI support is most straightforward and needs to be made into reference implementation
* r8a7795 USB 2.0 ch1 OVC pin pull-up shall be handled via "bias" DT binding.
* DU drive control can be handled as static setting.

h3. SYS-DMAC

* rcar-dmac.c driver fixes from visteon will be handled by Laurent

h3. Pull-up/down for USB2.0

* Using "bias-disable", "bias-pull-up", "bias-pull-down" properties
** boolean, specified by driver-specific pinctrl bindings
* Reference implementation exists for r8a7778/bock-w
* Does this need runtime-control?

h3. SD-IO-control for SD UHS-I

* Using "power-source" property, specifying the voltage in mV (specified by driver-specific pinctrl bindings).
* Controlled at run-time
* Patch series for Gen2 is available ("[PATCH v4 0/8] UHS-I support for sh_mobile_sdh" from Ben Hutchings), with some review comments.
* Gen2 first, Gen3 later.
* SDHI clock control on Gen3 also has capacitance control (10/20/30/40 pF, TDSEL).
** Do we need this? Probably not ("The value of these bit must be 00.")
** To implement it, we would have to extend the pinctrl core.

h3. DRV for DU

* Using "drive-strength" property, specifying the current in mA
** specified by generic pinctrl bindings
* Probably no need to be controlled at run-time

h3. IO cell control for IICDVFS

* Probably not needed ("IOCTRL controls the debug function.").

h2. Power Management

The BSP team wants to enable suspend to RAM by end of May and is wondering why many of our drivers don't have .suspend/.resume support.

There's no specific reason for the lack of .suspend/.resume in drivers, this is only due to suspend/resume never having been a priority in development.
This should be resolved for all drivers individually, based on priority and availability of resources.

Datasheets don't clearly document what happens when device power domains are turned off, and where device registers are retained. It is believed that registers are not retained but this needs to be investigated. Devices part of the "always on" power domain might retain their register contents.

Even if registers are retained drivers are responsible for putting devices in a quiescent state in the .suspend handler to ensure that no interrupts will be generated. This is driver-specific, some of them can rely on infrastructure provided by the subsystem they belong to.

Implementing suspend/resume support in all drivers is not a small effort and will require more resources. To request budget, we first need to create a tasks list to justify the request. Groups leader will analyze the drivers they're responsible for.

h1. +I/O Group+

h2. PFC support for SDHI (voltage switching)

Has been discussed in the CoreGroup part already.

h2. Watchdog integration

Is also a mix of IO group and Core group tasks. Needs more info if/how it works on Gen3 before making further plans, i.e. what belongs to the WDT driver and what to a possible RESET driver. Wolfram investigates.

h2. Thermal driver

Discussed the major refactoring needed to upstream this driver. Agreed with Morimoto-san about making a separate driver for Gen3. To be discussed if he does it or Khiem-san.


h1. +Multimedia Group+

h2. +Gen3 DU and VSPD device sharing and IPMMU handling+

h2. +VIN development schedule+

soc_camera conversion, board devices

h2. +HDMI and ALSA framework+

DT bindings have been proposed on the ALSA mailing list

* http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/102605.html
* http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/102654.html
* http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103240.html

We will follow-up on those mail threads and push the discussions in a direction suitable for us.

h2. +FDP schedule+

BSP team want to know at least API until Jun 2016

h2. +Issues with the V4L2 maintainer and plans for future developments+

h2. +How to test v4l2 request API+

h2. +FDP/VSP interface for V4L2+

for compatibility of VSP/FDP driver between V4l2-vsp1 and VSP-Manager, we want to know V4l2 Interface (as IOCTL/ some structure, etc).

So, if it is possible for laurent-san that he would decide "I/F specification for FDP and HGO(VSP)", we would like to want to early drop them.

h2. +VSP support and test coverage (VSPBD/BC/I)+

h1. +Integration Group+

h2. +Mainline Kernel Per-Version Feature Plan & Bootloader Requirements+

Each mainline kernel version could come with requirements regarding boot loader stack (U-Boot and earlier boot loader stages) versions (for instance enabling >4GB memory support on Gen3 could require support in the boot loaders). This, and other similar requirements on other 3rd party components, needs to be documented on the e-linux wiki.


h2. +Kernel size limitations+

Kernels are getting bigger over time (ARM multi-v7 kernel, .text ro alignment to 128kB, ...). This causes problems on some boards that stopped booting, possibly due to U-Boot issues.

We should investigate what happens in U-Boot when the kernel starts overwriting the DTB. Feedback should then be provided to the Renesas U-Boot developers to ensure the problem can be fixed in future U-Boot releases.

Documentation should also be added to the e-linux wiki to explain how to boot each board, including U-Boot environment variables.


h2. +patch upport schedule+

BSP team has some patches, and want to upport these.
Simon checks these list and kaneko-san picks up if he could as first step.
And Simon report missing patches to PeriPeri Member. 

Simon has posted tasks in periperi/peripelist.git, they will be handled by groups.

VIN patches clashes with ongoing work from Niklas to move away from soc-camera. The conflict is easy to resolve, but we should avoid such issues in the future by improving communication. Developers should read all team
group chat reports, even from teams they're not part of. A tl;dr summary at the top can be helpful too.


h1. +General+

h2. +SuperH maintainership resurrection casualties.+

* In the mean time, the issues have been resolved.

h2. +Salvator board+

* Capacitor solder fest
* Boot loader update fest

h2. +How to handle WS1.x, ES2.0 ?+

* Some IP have different channel number between WS1.1 <-> ES2.0
* BSP team want to keep old code, but don't care about test it.
* use -ws1.1 or -es2.0 on DT / use chip revision register

Different sample versions can have different feature sets (number of DMA channels, ...).

The policy is to only support the latest version and make the .dtsi evolve over time.

How do we deal with possible breakages when upgrading mainline ? It hasn't been an issue so far, let's deal with it only if a real problem occurs.

Socket vs Soldered is 50% - 50%, based on priority

h2. +Next WS1.x, ES2.0, M3 board for EuroPeri ?+

H3 (and next M3) has 2 type boards, Socket version vs Soldered version.
* We can exchange SoC if Socket version (for WS1.x, ES2.0, M3...)
* H3 vs M3 will be same board (the difference is only SoC)
* Current EuroPeri has Soldered version
* We selected Soldered version for EuroPeri because we afraid board break.
* What is your opinion for next SoC (WS1.x, ES2.0, M3) ?


h2. +Discussion about potentially adding one more guy from Renesas+

h2. +Each group leader to share information+

* Future work
* Ongoing issues
* Missing features in device drivers