path: root/wiki/2016-10-miniperi.wiki

h1. +MiniPeriCon 2016-10+

| Date  | 2016/10/09, 2016/10/10 |
|/2. Place | Day1 : "Hecker's Hotel":http://www.heckers-hotel.de/tagungen.html?&L=1 |
| Day2 : "eBuero / Dussmann":https://www.google.com/maps/place/Dussmann+Office/@52.5045155,13.335647,17z/data=!3m1!4b1!4m5!3m4!1s0x47a850551ccb2f01:0xe493fe0c56374f45!8m2!3d52.5045155!4d13.3378357 |
|/9. Member | Geert |
| Laurent |
| Morimoto |
| Niklas |
| Simon |
| Wolfram |
| Ulrich |
| Kieran |
| Magnus |

!2016-10-miniperi/out_0145.jpg! !2016-10-miniperi/out_0146.jpg! !2016-10-miniperi/out_0147.jpg! !2016-10-miniperi/out_0153.jpg! !2016-10-miniperi/out_1.jpg! 
!2016-10-miniperi/out_0164.jpg! !2016-10-miniperi/out_0167.jpg! !2016-10-miniperi/out_0172.jpg! !2016-10-miniperi/out_2.jpg!    !2016-10-miniperi/out_3.jpg!
!2016-10-miniperi/out_4.jpg!    !2016-10-miniperi/out_5.jpg!    !2016-10-miniperi/out_6.jpg!    !2016-10-miniperi/outg_1.jpg!
!2016-10-miniperi/out_0171.jpg! !2016-10-miniperi/out_0163.jpg! !2016-10-miniperi/out_0170.jpg!
!2016-10-miniperi/out_0174.jpg! !2016-10-miniperi/out_0152.jpg! !2016-10-miniperi/out_0154.jpg!
!2016-10-miniperi/out_0155.jpg! !2016-10-miniperi/out_0156.jpg! !2016-10-miniperi/out_0158.jpg!
!2016-10-miniperi/out_0160.jpg! !2016-10-miniperi/out_0161.jpg! !2016-10-miniperi/out_0162.jpg!
!2016-10-miniperi/out_0175.jpg! !2016-10-miniperi/out_0179.jpg! !2016-10-miniperi/outg_3.jpg!
!2016-10-miniperi/outg_4.jpg!   !2016-10-miniperi/outg_5.jpg!   !2016-10-miniperi/outg_2.jpg!

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

h2. How to handle ES1.x / ES2.0

* New prototype:
** DT fixup ("-es" additional compatible string) dropped
** soc_bus and soc_device_match()
** CPG/MSSR support for R-Car H3 ES2.0
** Proof-of-Concept of PFC support for R-Car H3 ES2.0
** HDMI driver can just use soc_device_match() instead of checking PRR
** => Proceed with soc_device_match() for ESx.y
** => Alternative: r8a7795-es1 (es1.0 and es1.1?) compatibility strings?
* How to deal with ES1.x/ES2.0 big difference device? (USB/VSP/DU/VIN/CSI)
** Needs separate dtsi:
*** r8a7795.dtsi
*** r8a7795-es1.dtsi
*** r8a7795-es2.dtsi
* SoC number is changed fromR-Car H3 ES1.x to ES2.0 (ES2.0 is r8a77951. ES1.x is r8a77950)
* Board team will make a new board "Salvator-XS" (Salvator-X 2nd version) for R-Car H3 ES2.0
** r8a7795-salvator-x.dts includes r8a7795.dtsi and r8a7795-es1.dtsi
** r8a7795-salvator-xs.dts includes r8a7795.dtsi and r8a7795-es2.dtsi

* SoC numbers
** R8A774?0 : RZ/G1H
** R8A77430 : RZ/G1M
** R8A774?0 : RZ/G1N
** R8A77450 : RZ/G1E
** R8A77950 : R-Car H3
** R8A77951 : R-Car H3 (ES2)
** R8A77960 : R-Car M3
** R8A77965 : R-Car M3N
*** Change policy and add a digit for r8a77965?
*** Can we detect at runtime (different Product ID or ESx.y version)?
** R8A77990 : R-Car E3
** R8A77995 : R-Car D3

h2. How to handle kernel size ?

* arm64 defconfig and arm32 multi_v7_defconfig are getting too large
* U-Boot is overwritten
* Boot a "small" kernel and kexec into the "large" kernel
* BSP team is working on it

h2. PM suspend/resume

* It needs v2.12.0 firmware, cfr. [[M3W_Salvator-X]]
* 4 steps:
** i2cset from userspace: Shouldn't this be done by the kernel?
** SW23 off: Can't be done purely from software?
** Echo into sysfs -> suspend
** SW23 on -> resume
* Other wake-up sources?
* What happens without SW23 toggling?
* What does PSCI does?
* Do registers really have to be saved?
* => Needs more investigation

h2. Proliferation of ...

h3. Compatible values:

* SoC-specific: renesas,r8a774x-foo
** Use soc_device_match() instead soon? => Talk to Arnd about acceptance/schedule
* Family-specific: renesas,rz-g-foo
** RZ/G is "compatible" with R-Car Gen2
* When do we really use SoC-specific compatible values?
** For quirks, we can use soc_device_match()
** What other compatible value can we use? Generic ones?
* When can we update the kernel, but not the DTB?

* There are many inconsistencies:
** Some IP blocks have SoC-Specific compatible values
** Some IP blocks have generic compatible values
** Some IP blocks have both
*** => Document the state

* CMT: Multiple different instances

h3. Drivers:

* r8a7791-cpg-mssr ~= r8a7743-cpg-mssr
** Any chance any of the following clocks ever end up in a newer version of the RZ/G datasheet?
*** I (SH-4A)
*** ADSP
*** SSP
*** SSPRS
* r8a7791-cpg-mssr ~= r8a7793-cpg-mssr (except for ZG divider?)
* r8a7794-cpg-mssr ~= r8a7745-cpg-mssr
* r8a7791-sysc == r8a7793-sysc ~= r8a7743-sysc (lacks SH-4A)
* r8a7794-sysc ~= r8a7745-sysc (lacks SH-4A)

h3. Board code under arch/arm/mach-shmobile/

Laurent is consolidating

h3. Sharing .dtsi?

* Cfr. iMX6
* SoC-specific: compatible values, core clocks, module clocks (not CPG/MSSR), power areas (although identical numbers per family)
* Plain numbers in DT: IRQs, DMAs, module clocks (CPG/MSSR)

h2. Should we keep DT backwards compatibility?

* Or DT fixup?
* How far do we go? => Keep compatibility for a while
* Affected devices:
** APMU (For H2/M2-W SMP) => Only hit v4.8
** RST (for MODEMR)
** CPG/MSSR
** CCCR/PRR
** Others?

h2. When BSP team can use IPMMU / DU on M3 ?

Request Cc to tomoharu.fukawa.eb@renesas.com

* Code to be rebased
* Blocking factor is DT binding
* After that, it can be integrated, but left disabled
* To be enabled later?

h2. (Remote) Access to more boards:

* Blanche and Wheat (R-Car V2H)
* Porter (R-Car M2-W)
* Silk (R-Car E2)
* H3ULCB (R-Car Gen3)
* RSKRZA1 (RZ/A1H)
* RZ/G
* ...

h2. renesas-drivers between v4.9-rc1 and v4.9

* BSP will be based on v4.9
* v4.9 will be the next LTS/LTSI
* Drop -next branches unless absolutely needed
* Only include topic branches that will survive
* Drop test and prototype code (e.g. SCIF/HSCIF external loopback)
* General: 
** Be conservative!
** Update your topic branches when (some) commits have been accepted!
* Risk:
** Uncaught regressions that will enter v4.10-rc1

* renesas-drivers-2016-10-04-v4.8 has:
| v4.9   | renesas/topic/i2c_sdhi_maintenance                                           |
| v4.9   | renesas/topic/pretimeout                                                     |
| v4.9   | [RFC] tty: serial_core: Move uart_console() check after console registration |
| v4.10  | clk-renesas-for-v4.10                                                        |     
| v4.10  | renesas/topic/sdhi-8bit-emmc                                                 |
| v4.10  | sh-pfc-for-v4.10                                                             |
| v4.10  | topic/r8a7796-dmac-driver-v1-rebased1                                        |
| v4.10  | topic/r8a7796-dmac-dts-v1-rebased1                                           |
| v4.10  | topic/r8a7796-ravb-v1                                                        |
| v4.10  | topic/rcar-secondary-booting-in-debug-mode-v1                                |
| v4.10  | topic/renesas-soc-id-v1                                                      |
| v4.10  | topic/sdr104-driver-v7                                                       |
| v4.10  | topic/sdr104-integration-v7                                                  |
| v4.10  | topic/sdr104-v7                                                              |
| v4.10  | topic/vin-gen2-driver-v1-rebased1                                            |
| v4.10? | histogram                                                                    |
| v4.10? | iommu/devel/du                                                               |
| v4.10? | topic/fcpf-v1-rebased7                                                       |
| v4.10+ | topic/ipmmu-multi-arch-v5                                                    |
| v4.10+ | topic/r8a7795-ipmmu-v2-rebased2                                              |
| v4.10+ | topic/r8a7796-ipmmu-v1-rebased2                                              |
| v4.11  | topic/vin-gen2-dts-v1-rebased1                                               |
| LTSI   | topic/r8a7795-es2-v1                                                         |
| SPLIT  | topic/salvator-x-ipmmu-rfc-v3-rebased4                                       |
| DROP   | topic/sdr104-v7+sdhi-dma-v3                                                  |
| DROP   | topic/spi-slave-v2                                                           |

h2. 12/M additional tasks

[WIP]
* Clean up DT bindings
* LTSI Execution (Simon)
* PM
* IOMMU
* Requests from I/O?
* Requests from MultiMedia?
* ...

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

h2. SCIF timeout handling

Rough schedule to handle timeout:

# get FIFO with PIO to work
# get HW-Timeout & FIFO with PIO to work
# get HW-Timeout & DMA to to work

Ulrich showed interest. Wolfram and Ulrich will work on formulating apropriate additional tasks out of this.

h2. SDHI DMA

* it is not clear if a new DMA interface is coming and how it might look like
* the current DMA interface has a serious limitation, only one DMA instance can be used simultaneously
* result: don't upstream current DMA code, even remove from renesas-drivers
* OK to use for internal testing like UHS speeds

h2. Additional tasks Q4 batch2

Candidates:

* SCIF timeout, first step (Ulrich)
* SDHI eMMC HS200 (Wolfram)
* WakeOnLan prototyping on Gen2 (Niklas, as part of base task)

Candidates for later

* SDHI PM - needs to be split up into smaller tasks by Wolfram
* SPI slave - need more info about use case -> ping Morimoto-san
* irqless I2C transfers
* and whatever comes of out the BSP analysis

h2. Do we need regular IRC meetings?

Let's switch to mail reports every 2 weeks and IRC meetings every 4 weeks first.

h2. double check todo list

* Wolfram send DTS changes for 8 bit eMMC again for v4.10
* Wolfram reworks I2C IP core switch DTS changes and Simon will test, aiming for v4.10
* Geert/Ulrich talk to broonie about the MSIOF GPIO CS issue
* Wolfram talks to linusw about current MMC/block layer work

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

h2. Status update

* 12/M additional tasks
* Plans for next quarter
* Regular bi-weekly status update

see "here":../../wiki/Chat_log/20161009-mm-chatlog

h2. Coordination of BSP up-porting

Team leaders have been tasked with mining the BSP for patches and classifying them based on the subsystem/device/feature they're related to, with a proposed upstreaming plan for each of them. Morimoto-san has already posted a list to the Renesas wiki, and Simon got his own list too.

To avoid work duplication, we will use "Simon's spreadsheet":https://docs.google.com/spreadsheets/d/1-8N55DcpS4qqx4LcWQpFfTVbqCCF2fdwUUVqZyinvxU as the canonical list of BSP patches, and update the status as patches are merged in mainline.

h2. BSP team request

h3. What is the current status of "Cache management on V4L2":../../wiki/2016-10-miniperi/20160712_renesascom-v3.pdf ?

* BSP team measurement: "__dma_map_area()":https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/mm/cache.S?id=refs/tags/v4.8-rc8#n186 takes long term.
* Can BSP team use it on LTSI v4.9 ?
** BSP team want to use it Jan, 2017 v4.9 or July 2017 Final
** Backport is OK

The problem is well known but no mainline solution has been developed yet. 
There is however interest in this topic from various companies.

This can be handled as additional task(s), the schedule needs to be discussed.


h3. What is the current status of "Rotation + ImagePartition" ?

Image partitioning has been implemented and merged in mainline for v4.9.
Rotation support has been implemented as well but currently blocked on review.
The upstream target is v4.10 at this point.

h3. What is the current status of "request API" ?

The API will be discussed tomorrow (= 10th Oct) during a whole day V4L2 meeting with Hans Verkuil and Sakari Ailus among others. More information about the upstreaming schedule will be available then.

h3. "VSP1 state bug":../../wiki/2016-10-miniperi/vsp_state_bug.xlsx

* User call STREAM_ON
** state = RUNNING.
* IRQ happen.
** vsp1_video_pipeline_frame_end() was called from vsp1_irq_handler() (*1)
** state = STOPPED
* User call STREAM_OFF
** vsp1_pipeline_stop() was called
** wait_event_timeout() checkes state STOPPED or not

If user call QBUF on (*1) timing (STREAM_ON -> QBUF -> STREAM_OFF), QBUF tried state = RUNNING, and its data was not yet finished, but state will be STOPPED after that. wait_event_timeout() doensn't wait for it, and all pointer will be NULL. BSP team has "patch":../../wiki/2016-10-miniperi/vsp2_running_count.patch

Two race conditions have been found recently. One of them has already been fixed in mainline "v4.9":https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bfb4d5be9e1d5a70d0710e815d15a4245eaaafc4

Work is in progress on a second one. Whether the issue found by the BSP team is identical isn't known yet. It would be helpful if the BSP could retest with the above commit. We can schedule an additional task for this quarter to solve the problem if it still occurs.

h3. DU/VIN DT style difference ES1.x/ES2.0 ?

The DU and attached VSPs have changed significantly between ES1.x and ES2.0. 
This will require different compatible strings. The "renesas,vsps" property will still be used, referencing 3 VSPs instead of 4. There should be no other change needed to the DU DT bindings.

For VIN, differences between ES versions are limited to CSI2 routing. This is hardcoded in the driver at the moment. As VIN has no IP core version register, routing selection has to be done through different compatible strings at the minimum. Another option would be to express full routing in DT, but that would be more complex and isn't considered as a good solution.

h3. Is it possible to have VIN on renesas-drivers in 11/M ? (M3/H3)

VIN on Gen3 requires the external HDMI to CSI2 ADV7482 driver. At the moment the existing driver is a prototype that hardcodes input selection due to missing V4L2 APIs upstream (this topic will be discussed face to face with Hans Verkuil this week). Whether the code can be merged in renesas-drivers depends if the renesas-drivers tree is a Renesas -next staging area or a BSP staging area. We expect the core group to discuss this topic and provide an answer.

h3. Is it possible to have M3 DU on renesas-drivers in 11/M ?

Yes

h3. rcar-du + dma-buf + fence

The DU driver supports buffer sharing with dma-buf, but doesn't implement fence support. Support for the upstream API can be implemented, but can't be tested at this time with the GPU due to the GPU driver not being publicly available. We can thus schedule fence support as an additional task, but without any guarantee that it will work out of the box with the SGX driver stack.

h3. horizontal lines appears in the plane.

<pre>
# modetest -M rcar-du -s 66@64:800x600@NV16 -P 64:300x300@XR24
</pre>

The BSP team noticed a display corruption issue with renesas-drivers-2016-09-20-v4.8-rc7 with the following patches applied:

<pre>
 - gen3_du_ipmmu.config
 - 0001-linux-v4.8-rc-fcp-get-device-20160901.patch
 - 0002-arm64-dtsi-r8a7795-Enable-IPMMU-node-for-DU0-1-2-3.patch
 - 0003-v4l-vsp1-Add-underrun-hung-up-workaround.patch
</pre>

If we can get those four patches we will investigate and provide a fix or, if the problem is complex, a plan.

h3. runtime SRC connection on R-Car sound

The customer would like to use the SRC several times in the audio pipeline. This can't easily be handled with the current driver design. The exact use case behind the request isn't known, Morimoto-san asked for details. If the use case is valid, implementation would require major changes to the driver.

h1. +%{color:#0000FF}Upporting/Backporting%+

h2. Patch Classification Lists

* Google sheet maintained by upstream-focused development team
** https://docs.google.com/spreadsheets/d/1-8N55DcpS4qqx4LcWQpFfTVbqCCF2fdwUUVqZyinvxU
* Spread sheet provided by BSP team to indicate their preferences for up-porting activities
** "bsp_patch_list":../../wiki/2016-10-miniperi/bsp_patch_list_20160930.xlsx

h2. "Upport request from BSP":../../wiki/2016-10-miniperi/bsp_patch_list_20160930.xlsx

* Backport HI priority: DU/VIN
* Upport HI priority: M3 integration