diff options
| author | Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> | 2019-12-23 14:27:52 +0900 |
|---|---|---|
| committer | Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> | 2019-12-23 14:27:52 +0900 |
| commit | dc71f3518c95f8d9d306e8a4e53bc9bd2e9928e3 (patch) | |
| tree | 54552f6ba6cec40e16cef5c22043d9f510087e00 /wiki | |
| parent | bb506a3f4c5441ecb212874077ad8b1bf335c936 (diff) | |
| parent | 05040a728026b28ce7c6183d2adfa80218b306cb (diff) | |
Merge remote-tracking branch 'gitlab/wiki' into HEAD
Diffstat (limited to 'wiki')
422 files changed, 68046 insertions, 0 deletions
diff --git a/wiki/2016-02-periperi.wiki b/wiki/2016-02-periperi.wiki new file mode 100644 index 0000000..59fa87e --- /dev/null +++ b/wiki/2016-02-periperi.wiki @@ -0,0 +1,303 @@ +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 diff --git a/wiki/2016-02-periperi/periperi1.jpg b/wiki/2016-02-periperi/periperi1.jpg Binary files differnew file mode 100644 index 0000000..0f3ccd1 --- /dev/null +++ b/wiki/2016-02-periperi/periperi1.jpg diff --git a/wiki/2016-02-periperi/periperi2.jpg b/wiki/2016-02-periperi/periperi2.jpg Binary files differnew file mode 100644 index 0000000..943a17f --- /dev/null +++ b/wiki/2016-02-periperi/periperi2.jpg diff --git a/wiki/2016-02-periperi/periperi3.jpg b/wiki/2016-02-periperi/periperi3.jpg Binary files differnew file mode 100644 index 0000000..d7ca1fd --- /dev/null +++ b/wiki/2016-02-periperi/periperi3.jpg diff --git a/wiki/2016-02-periperi/periperi4.jpg b/wiki/2016-02-periperi/periperi4.jpg Binary files differnew file mode 100644 index 0000000..7c0da58 --- /dev/null +++ b/wiki/2016-02-periperi/periperi4.jpg diff --git a/wiki/2016-07-miniperi.wiki b/wiki/2016-07-miniperi.wiki new file mode 100644 index 0000000..8d39aef --- /dev/null +++ b/wiki/2016-07-miniperi.wiki @@ -0,0 +1,176 @@ +h1. +MiniPeriCon 2016-07+ + +| Date | 2016/07/11 | +| Place | Tokyo | +|/8. Member | Geert | +| Laurent | +| Morimoto | +| Niklas | +| Simon | +| Wolfram | +| Shimoda | +| Khiem | + +!2016-07-miniperi/linuxcon2016.png! !2016-07-miniperi/wsa2016.png! + +!2016-07-miniperi/wolf.png! !2016-07-miniperi/lcj.png! + +h1. +I/O meeting+ + +h2. Chat meetings + +* members send todo updates by mail before meeting starts +* short focussed meetings. everyone answers +** what have I worked on since last time +** what will I work on until next time +** I have the following problems (or not) +* once every two weeks + +h2. Additional tasks for 8/M + +* We just wait + +h2. Base tasks + +* Wolfram: ask for reports +* Niklas is okay doing base tasks occasionally + +h2. Additional tasks + +* priorities of tasks need to be clear for developers to decide +* especially across groups + +h3. batch 1 + +* SDHI: fix SDR104 issues and enable on Gen3 - Simon (5d) +* I2C & SDHI maintenance - Wolfram (5d) + +h3. batch 2 + +* SDR integration for all boards and/or PFC SDHI voltage for all our SoCs - Simon (5d) +* SPI: implement slave prototype - Geert (5d) +* SDHI with UHS - Wolfram (5d) + +h3. todo + +* Ethernet: 64bit memory support for Gen3 - ? (5d) +* HSCIF HW timeout - Geert (10d?) +* 8bit eMMC supprt for SDHI +* HS200/400 support for eMMC after that + + +h1. "Core meeting":../../wiki/2016-07-miniperi/2016-07-11_MiniPeriPeriCon_Handouts.pdf + +h2. Additional task + +h3. for 8/M + +* Geert : R-Car H3 MSOIF Parent Clock Control Prototype +* Simon : R-Car M3-W Suspend-to-RAM Prototype +* Ulrich : R-Car M3-W SYS-DMAC Integration +* Laurent/Kieran : R-Car H3 Pin Function Controller Drive Strength of Non-I/O pins Upstream Development (TBC) + +h3. for 9/M + +* Geert : Renesas-drivers Git Repository Maintenance +* Simon : R-Car M3-W Kexec Prototype + +h3. noplan/noschedule + +* M3-W 64bit memory support +* Prototype for DT fixup (first RFC sent) +* M3-W more suspend-to-ram +* M3-W PFC enhancements +** IPSR17 is strange +** http://www.spinics.net/lists/linux-renesas-soc/msg05211.html +* Migrate to CPG/MSSR +* Start adding dmas pointing to SYS-DMAC2 (needs secure firmware 2.8.0) + +h2. Dirk's topic + +h3. ESx.y + +* API to access Product Register (PRR), used by drivers +* Fixup DT (change compatible value) +** May need both? Lattter is needed to e.g. change number of device instances + +h3. Sharing clock definitions + +h3. Sharing dtsi + +* Cfr. iMX6 +* SoC-specific: compatible value, core clocks, module clock (not CPG/MSSR), power area (although identical numbers per family) +* Plain numbers in DT: IRQs, DMAs, module clocks + +h1. +MultiMedia meeting+ + +h2. OF graph for ALSA (Morimoto-san) + +ALSA will use OF graph base DT. + +http://thread.gmane.org/gmane.linux.kernel/2252365/focus=156164 +which is better from HDMI video point of view ? + +This is good for HDMI vidoe / sound +<pre> +port@0 { + type = "video"; + endpoint { + remote-endpoint = <&xxx>; + }; +}; +port@1 { + type = "sound"; + endpoint { + remote-endpoint = <&xxx>; + }; +}; +</pre> + +This is good for multi-connection +<pre> +port { + type = "sound"; + endpoint { + remote-endpoint = <&xxx>; + }; + endpoint { + remote-endpoint = <&xxx>; + }; +}; +</pre> + +h2. V4L2 support for subdevices with more than one output pipeline (Niklas) + +HDMI input (and output) is of no interest to the BSP team at the moment. We thus don't need to upstream the ADV7482 driver, and can develop a simplified driver for testing purpose that hardcodes the data path. CVBS input would be simpler than the HDMI input, but on the other hand HDMI input is useful to use for HDMI loopback testing. Unless implementing support for the HDMI path (including EDID programming) turns out to be significantly more complex than currently thought, let's do that. + +No extension to V4L2 to make several operations pad-aware (s_stream, *std, ...) is thus needed as we will hardcode one path in the ADV7482 driver. + +In Gen3 VIN instances share UDS and CSI selectors, as well as possibly an ISP on V3H. The hardware is reaching the level of complexity that requires exposing the MC API to userspace. Link configuration will then be used to control UDS sharing. + +For CSI routing, the hardware is peculiar and complex, and link configuration might not be a good match. Exposing the CSI selectors as entities with an API (either at the V4L2 or MC level) to configure internal routing in the entity +(identical or similar to the set routing ioctl that I proposed) is probably a better solution. Whether that API should be implemented as a V4L2 or an MC ioctl is an open question, as the feature isn't V4L2-specific. Whether that +API should allow enumerating the supported routing options is also an open question, the hardware is so peculiar that a device-specific userspace will likely be needed anyway. Another problem that needs to be solved is how to +handle locking routes, as we shouldn't allow messing up an active stream, and configuring unrelated links could impact other routes due to the way the hardware is implemented. + +h2. Second batch of additional tasks for Q3 (Laurent) + +* Niklas: Lots of work on VIN + MC. Base contract would cover upstreaming, including getting API extensions accepted. Additional tasks can cover preparation for upstreaming, and ADV7482 work (including EDID programming). + +* Ulrich, Laurent, Kieran: Let's discuss this again after RenesasCon where the BSP team will likely request additional features. + +h2. What are we doing right or wrong, and how can we improve (Laurent) + +A largely unexplored area for improvements is automated testing, we should invest more in regression tests that could be run either in board farms or by developers as part of the patch submission process. + +h2. Long-term roadmap (Laurent) + +The industry is moving to V4L2 for video codecs, with Android being influenced by ChromeOS in that regard. Several SoC vendors are posting open-source kernel drivers for codecs, but Renesas is lagging in that area. There is currently no plan for Renesas to change this. Codec support is provided to customers through a GStreamer element, the underlying API isn't relevant and no request for V4L2 support has been received so far. However, if we could provide convincing business reasons to move to V4L2, the position could be reconsidered. One possible benefit would be to reuse generic GStreamer video codec code instead of having to maintain a separate GStreamer element. + +h2. UDS sharing for VIN devices on Gen3. + +Time to add MC support to rcar-vin and/or other ides to reduce resource sharing complexity. + +h2. Possible new task, Gen3 datasheet (rev0.52e) adds one new possible video input source ISP (Image Signal Processor) for R-CarV3M. + +The block is not documented other then with a list of features and a block diagram. diff --git a/wiki/2016-07-miniperi/2016-07-11_MiniPeriPeriCon_Handouts.pdf b/wiki/2016-07-miniperi/2016-07-11_MiniPeriPeriCon_Handouts.pdf Binary files differnew file mode 100644 index 0000000..734d16c --- /dev/null +++ b/wiki/2016-07-miniperi/2016-07-11_MiniPeriPeriCon_Handouts.pdf diff --git a/wiki/2016-07-miniperi/lcj.png b/wiki/2016-07-miniperi/lcj.png Binary files differnew file mode 100644 index 0000000..6b266fb --- /dev/null +++ b/wiki/2016-07-miniperi/lcj.png diff --git a/wiki/2016-07-miniperi/linuxcon2016.png b/wiki/2016-07-miniperi/linuxcon2016.png Binary files differnew file mode 100644 index 0000000..200ef96 --- /dev/null +++ b/wiki/2016-07-miniperi/linuxcon2016.png diff --git a/wiki/2016-07-miniperi/wolf.png b/wiki/2016-07-miniperi/wolf.png Binary files differnew file mode 100644 index 0000000..54842d5 --- /dev/null +++ b/wiki/2016-07-miniperi/wolf.png diff --git a/wiki/2016-07-miniperi/wsa2016.png b/wiki/2016-07-miniperi/wsa2016.png Binary files differnew file mode 100644 index 0000000..ad8e7d1 --- /dev/null +++ b/wiki/2016-07-miniperi/wsa2016.png diff --git a/wiki/2016-07-renesas.wiki b/wiki/2016-07-renesas.wiki new file mode 100644 index 0000000..905dc6e --- /dev/null +++ b/wiki/2016-07-renesas.wiki @@ -0,0 +1,41 @@ +h1. +RenesasCon 2016-07+ + +| Date | 2016/07/12 | +| Place | "Renesas Japan Musashi":http://maps.google.co.jp/maps?q=35.712666,139.477776 | +|/10. Member | Geert | +| Laurent | +| Magnus | +| Morimoto | +| Niklas | +| Simon | +| Wolfram | +| Shimoda | +| Khiem | +| Renesas BSP team | + +!2016-07-renesas/renesascon2016.png! !2016-07-renesas/laurent2016.png! + +h1. Current activity presentation + +* "Geert":../../wiki/2016-07-renesas/2016-07-12_RenesasCon_Presentation-geert.pdf +* "Wolfram":../../wiki/2016-07-renesas/RenesasCon_wsa.pdf +* "Simon":../../wiki/2016-07-renesas/horms_solutions.en.pdf +* "Laurent":../../wiki/2016-07-renesas/laurent.pdf +* "Niklas":../../wiki/2016-07-renesas/niklas.pdf + +h1. "Introduction of R-Car Linux business related member / team":../../wiki/2016-07-renesas/rcar-linux-business_20160712a.pdf + +h1. Introduction of R-Car Linux business plan / overview + +h1. Introduction of BSP plan / overview + +h1. Introduction of BSP local patches, request for upstreaming + +h1. Latest DRM/KMS upstream situation + +h1. "About DU/VSP/Request API/Z-order/FDP etc":../../wiki/2016-07-renesas/20160712_renesascom-v3.pdf + +h1. "Jinso test team activity":../../wiki/2016-07-renesas/Linux-Driver-Test-Introduction_v1.0_20160712.pdf + +h1. "About Renesas Vietnam upstream activity":../../wiki/2016-07-renesas/160712_Renesas_Vietnam_Upstream_Activity.pdf + diff --git a/wiki/2016-07-renesas/160712_Renesas_Vietnam_Upstream_Activity.pdf b/wiki/2016-07-renesas/160712_Renesas_Vietnam_Upstream_Activity.pdf Binary files differnew file mode 100644 index 0000000..37933cd --- /dev/null +++ b/wiki/2016-07-renesas/160712_Renesas_Vietnam_Upstream_Activity.pdf diff --git a/wiki/2016-07-renesas/2016-07-12_RenesasCon_Presentation-geert.pdf b/wiki/2016-07-renesas/2016-07-12_RenesasCon_Presentation-geert.pdf Binary files differnew file mode 100644 index 0000000..112e1b9 --- /dev/null +++ b/wiki/2016-07-renesas/2016-07-12_RenesasCon_Presentation-geert.pdf diff --git a/wiki/2016-07-renesas/20160712_renesascom-v3.pdf b/wiki/2016-07-renesas/20160712_renesascom-v3.pdf Binary files differnew file mode 100644 index 0000000..1a1efd7 --- /dev/null +++ b/wiki/2016-07-renesas/20160712_renesascom-v3.pdf diff --git a/wiki/2016-07-renesas/Linux-Driver-Test-Introduction_v1.0_20160712.pdf b/wiki/2016-07-renesas/Linux-Driver-Test-Introduction_v1.0_20160712.pdf Binary files differnew file mode 100644 index 0000000..f3e5e40 --- /dev/null +++ b/wiki/2016-07-renesas/Linux-Driver-Test-Introduction_v1.0_20160712.pdf diff --git a/wiki/2016-07-renesas/RenesasCon_wsa.pdf b/wiki/2016-07-renesas/RenesasCon_wsa.pdf Binary files differnew file mode 100644 index 0000000..feb2ef4 --- /dev/null +++ b/wiki/2016-07-renesas/RenesasCon_wsa.pdf diff --git a/wiki/2016-07-renesas/horms_solutions.en.pdf b/wiki/2016-07-renesas/horms_solutions.en.pdf Binary files differnew file mode 100644 index 0000000..fa397be --- /dev/null +++ b/wiki/2016-07-renesas/horms_solutions.en.pdf diff --git a/wiki/2016-07-renesas/laurent.pdf b/wiki/2016-07-renesas/laurent.pdf Binary files differnew file mode 100644 index 0000000..45a7adb --- /dev/null +++ b/wiki/2016-07-renesas/laurent.pdf diff --git a/wiki/2016-07-renesas/laurent2016.png b/wiki/2016-07-renesas/laurent2016.png Binary files differnew file mode 100644 index 0000000..ffdc3e5 --- /dev/null +++ b/wiki/2016-07-renesas/laurent2016.png diff --git a/wiki/2016-07-renesas/niklas.pdf b/wiki/2016-07-renesas/niklas.pdf Binary files differnew file mode 100644 index 0000000..a250e76 --- /dev/null +++ b/wiki/2016-07-renesas/niklas.pdf diff --git a/wiki/2016-07-renesas/rcar-linux-business_20160712a.pdf b/wiki/2016-07-renesas/rcar-linux-business_20160712a.pdf Binary files differnew file mode 100644 index 0000000..dd86c9b --- /dev/null +++ b/wiki/2016-07-renesas/rcar-linux-business_20160712a.pdf diff --git a/wiki/2016-07-renesas/renesascon2016.png b/wiki/2016-07-renesas/renesascon2016.png Binary files differnew file mode 100644 index 0000000..e19d00a --- /dev/null +++ b/wiki/2016-07-renesas/renesascon2016.png diff --git a/wiki/2016-10-miniperi.wiki b/wiki/2016-10-miniperi.wiki new file mode 100644 index 0000000..6cd5bab --- /dev/null +++ b/wiki/2016-10-miniperi.wiki @@ -0,0 +1,362 @@ +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
\ No newline at end of file diff --git a/wiki/2016-10-miniperi/20160712_renesascom-v3.pdf b/wiki/2016-10-miniperi/20160712_renesascom-v3.pdf Binary files differnew file mode 100644 index 0000000..1a1efd7 --- /dev/null +++ b/wiki/2016-10-miniperi/20160712_renesascom-v3.pdf diff --git a/wiki/2016-10-miniperi/bsp_patch_list_20160930.xlsx b/wiki/2016-10-miniperi/bsp_patch_list_20160930.xlsx Binary files differnew file mode 100644 index 0000000..1f44649 --- /dev/null +++ b/wiki/2016-10-miniperi/bsp_patch_list_20160930.xlsx diff --git a/wiki/2016-10-miniperi/out_0145.jpg b/wiki/2016-10-miniperi/out_0145.jpg Binary files differnew file mode 100644 index 0000000..60312e8 --- /dev/null +++ b/wiki/2016-10-miniperi/out_0145.jpg diff --git a/wiki/2016-10-miniperi/out_0146.jpg b/wiki/2016-10-miniperi/out_0146.jpg Binary files differnew file mode 100644 index 0000000..41948fa --- /dev/null +++ b/wiki/2016-10-miniperi/out_0146.jpg diff --git a/wiki/2016-10-miniperi/out_0147.jpg b/wiki/2016-10-miniperi/out_0147.jpg Binary files differnew file mode 100644 index 0000000..0bf4bf7 --- /dev/null +++ b/wiki/2016-10-miniperi/out_0147.jpg diff --git a/wiki/2016-10-miniperi/out_0152.jpg b/wiki/2016-10-miniperi/out_0152.jpg Binary files differnew file mode 100644 index 0000000..01f76c8 --- /dev/null +++ b/wiki/2016-10-miniperi/out_0152.jpg diff --git a/wiki/2016-10-miniperi/out_0153.jpg b/wiki/2016-10-miniperi/out_0153.jpg Binary files differnew file mode 100644 index 0000000..acabf2c --- /dev/null +++ b/wiki/2016-10-miniperi/out_0153.jpg diff --git a/wiki/2016-10-miniperi/out_0154.jpg b/wiki/2016-10-miniperi/out_0154.jpg Binary files differnew file mode 100644 index 0000000..8d3674d --- /dev/null +++ b/wiki/2016-10-miniperi/out_0154.jpg diff --git a/wiki/2016-10-miniperi/out_0155.jpg b/wiki/2016-10-miniperi/out_0155.jpg Binary files differnew file mode 100644 index 0000000..520ca63 --- /dev/null +++ b/wiki/2016-10-miniperi/out_0155.jpg diff --git a/wiki/2016-10-miniperi/out_0156.jpg b/wiki/2016-10-miniperi/out_0156.jpg Binary files differnew file mode 100644 index 0000000..63bc355 --- /dev/null +++ b/wiki/2016-10-miniperi/out_0156.jpg diff --git a/wiki/2016-10-miniperi/out_0158.jpg b/wiki/2016-10-miniperi/out_0158.jpg Binary files differnew file mode 100644 index 0000000..f071d5f --- /dev/null +++ b/wiki/2016-10-miniperi/out_0158.jpg diff --git a/wiki/2016-10-miniperi/out_0160.jpg b/wiki/2016-10-miniperi/out_0160.jpg Binary files differnew file mode 100644 index 0000000..4bc1c90 --- /dev/null +++ b/wiki/2016-10-miniperi/out_0160.jpg diff --git a/wiki/2016-10-miniperi/out_0161.jpg b/wiki/2016-10-miniperi/out_0161.jpg Binary files differnew file mode 100644 index 0000000..68ff096 --- /dev/null +++ b/wiki/2016-10-miniperi/out_0161.jpg diff --git a/wiki/2016-10-miniperi/out_0162.jpg b/wiki/2016-10-miniperi/out_0162.jpg Binary files differnew file mode 100644 index 0000000..89692fc --- /dev/null +++ b/wiki/2016-10-miniperi/out_0162.jpg diff --git a/wiki/2016-10-miniperi/out_0163.jpg b/wiki/2016-10-miniperi/out_0163.jpg Binary files differnew file mode 100644 index 0000000..05ea99b --- /dev/null +++ b/wiki/2016-10-miniperi/out_0163.jpg diff --git a/wiki/2016-10-miniperi/out_0164.jpg b/wiki/2016-10-miniperi/out_0164.jpg Binary files differnew file mode 100644 index 0000000..975bbbf --- /dev/null +++ b/wiki/2016-10-miniperi/out_0164.jpg diff --git a/wiki/2016-10-miniperi/out_0167.jpg b/wiki/2016-10-miniperi/out_0167.jpg Binary files differnew file mode 100644 index 0000000..af229ea --- /dev/null +++ b/wiki/2016-10-miniperi/out_0167.jpg diff --git a/wiki/2016-10-miniperi/out_0170.jpg b/wiki/2016-10-miniperi/out_0170.jpg Binary files differnew file mode 100644 index 0000000..fe10407 --- /dev/null +++ b/wiki/2016-10-miniperi/out_0170.jpg diff --git a/wiki/2016-10-miniperi/out_0171.jpg b/wiki/2016-10-miniperi/out_0171.jpg Binary files differnew file mode 100644 index 0000000..0feb7c4 --- /dev/null +++ b/wiki/2016-10-miniperi/out_0171.jpg diff --git a/wiki/2016-10-miniperi/out_0172.jpg b/wiki/2016-10-miniperi/out_0172.jpg Binary files differnew file mode 100644 index 0000000..18e7285 --- /dev/null +++ b/wiki/2016-10-miniperi/out_0172.jpg diff --git a/wiki/2016-10-miniperi/out_0174.jpg b/wiki/2016-10-miniperi/out_0174.jpg Binary files differnew file mode 100644 index 0000000..91549a9 --- /dev/null +++ b/wiki/2016-10-miniperi/out_0174.jpg diff --git a/wiki/2016-10-miniperi/out_0175.jpg b/wiki/2016-10-miniperi/out_0175.jpg Binary files differnew file mode 100644 index 0000000..0089d71 --- /dev/null +++ b/wiki/2016-10-miniperi/out_0175.jpg diff --git a/wiki/2016-10-miniperi/out_0179.jpg b/wiki/2016-10-miniperi/out_0179.jpg Binary files differnew file mode 100644 index 0000000..8306ad5 --- /dev/null +++ b/wiki/2016-10-miniperi/out_0179.jpg diff --git a/wiki/2016-10-miniperi/out_1.jpg b/wiki/2016-10-miniperi/out_1.jpg Binary files differnew file mode 100644 index 0000000..6c6275e --- /dev/null +++ b/wiki/2016-10-miniperi/out_1.jpg diff --git a/wiki/2016-10-miniperi/out_2.jpg b/wiki/2016-10-miniperi/out_2.jpg Binary files differnew file mode 100644 index 0000000..2ac5d57 --- /dev/null +++ b/wiki/2016-10-miniperi/out_2.jpg diff --git a/wiki/2016-10-miniperi/out_3.jpg b/wiki/2016-10-miniperi/out_3.jpg Binary files differnew file mode 100644 index 0000000..498dc02 --- /dev/null +++ b/wiki/2016-10-miniperi/out_3.jpg diff --git a/wiki/2016-10-miniperi/out_4.jpg b/wiki/2016-10-miniperi/out_4.jpg Binary files differnew file mode 100644 index 0000000..cd85e55 --- /dev/null +++ b/wiki/2016-10-miniperi/out_4.jpg diff --git a/wiki/2016-10-miniperi/out_5.jpg b/wiki/2016-10-miniperi/out_5.jpg Binary files differnew file mode 100644 index 0000000..86c6071 --- /dev/null +++ b/wiki/2016-10-miniperi/out_5.jpg diff --git a/wiki/2016-10-miniperi/out_6.jpg b/wiki/2016-10-miniperi/out_6.jpg Binary files differnew file mode 100644 index 0000000..c8b070b --- /dev/null +++ b/wiki/2016-10-miniperi/out_6.jpg diff --git a/wiki/2016-10-miniperi/outg_1.jpg b/wiki/2016-10-miniperi/outg_1.jpg Binary files differnew file mode 100644 index 0000000..710cd35 --- /dev/null +++ b/wiki/2016-10-miniperi/outg_1.jpg diff --git a/wiki/2016-10-miniperi/outg_2.jpg b/wiki/2016-10-miniperi/outg_2.jpg Binary files differnew file mode 100644 index 0000000..6c26f41 --- /dev/null +++ b/wiki/2016-10-miniperi/outg_2.jpg diff --git a/wiki/2016-10-miniperi/outg_3.jpg b/wiki/2016-10-miniperi/outg_3.jpg Binary files differnew file mode 100644 index 0000000..729e37e --- /dev/null +++ b/wiki/2016-10-miniperi/outg_3.jpg diff --git a/wiki/2016-10-miniperi/outg_4.jpg b/wiki/2016-10-miniperi/outg_4.jpg Binary files differnew file mode 100644 index 0000000..2fc9b83 --- /dev/null +++ b/wiki/2016-10-miniperi/outg_4.jpg diff --git a/wiki/2016-10-miniperi/outg_5.jpg b/wiki/2016-10-miniperi/outg_5.jpg Binary files differnew file mode 100644 index 0000000..641446c --- /dev/null +++ b/wiki/2016-10-miniperi/outg_5.jpg diff --git a/wiki/2016-10-miniperi/vsp2_running_count.patch b/wiki/2016-10-miniperi/vsp2_running_count.patch new file mode 100644 index 0000000..f6b0003 --- /dev/null +++ b/wiki/2016-10-miniperi/vsp2_running_count.patch @@ -0,0 +1,52 @@ +diff --git a/drv/vsp2_video.c b/drv/vsp2_video.c +index 2946088..eacbb83 100755 +--- a/drv/vsp2_video.c ++++ b/drv/vsp2_video.c +@@ -442,6 +442,7 @@ static void __vsp2_pipeline_cleanup(struct vsp2_pipeline *pipe) + + INIT_LIST_HEAD(&pipe->entities); + pipe->state = VSP2_PIPELINE_STOPPED; ++ pipe->running_count = 0; + pipe->buffers_ready = 0; + pipe->num_video = 0; + pipe->num_inputs = 0; +@@ -556,6 +557,7 @@ static void vsp2_pipeline_run(struct vsp2_pipeline *pipe) + vsp2_vspm_drv_entry(vsp2); + + pipe->state = VSP2_PIPELINE_RUNNING; ++ pipe->running_count++; + pipe->buffers_ready = 0; + } + +@@ -675,7 +677,9 @@ void vsp2_pipeline_frame_end(struct vsp2_pipeline *pipe) + spin_lock_irqsave(&pipe->irqlock, flags); + + state = pipe->state; +- pipe->state = VSP2_PIPELINE_STOPPED; ++ ++ if (--pipe->running_count == 0) ++ pipe->state = VSP2_PIPELINE_STOPPED; + + /* If a stop has been requested, mark the pipeline as stopped and + * return. +@@ -981,7 +985,7 @@ static int vsp2_video_stop_streaming(struct vb2_queue *vq) + int ret; + + mutex_lock(&pipe->lock); +- if (--pipe->stream_count == 0) { ++ if (--pipe->stream_count == pipe->num_inputs) { + /* Stop the pipeline. */ + ret = vsp2_pipeline_stop(pipe); + if (ret == -ETIMEDOUT) +diff --git a/drv/vsp2_video.h b/drv/vsp2_video.h +index 90c3478..db67e66 100755 +--- a/drv/vsp2_video.h ++++ b/drv/vsp2_video.h +@@ -120,6 +120,7 @@ struct vsp2_pipeline { + struct mutex lock; + unsigned int use_count; + unsigned int stream_count; ++ unsigned int running_count; + unsigned int buffers_ready; + + unsigned int num_video; diff --git a/wiki/2016-10-miniperi/vsp_state_bug.xlsx b/wiki/2016-10-miniperi/vsp_state_bug.xlsx Binary files differnew file mode 100644 index 0000000..32ed21e --- /dev/null +++ b/wiki/2016-10-miniperi/vsp_state_bug.xlsx diff --git a/wiki/2017-02-miniperi.wiki b/wiki/2017-02-miniperi.wiki new file mode 100644 index 0000000..5107e2b --- /dev/null +++ b/wiki/2017-02-miniperi.wiki @@ -0,0 +1,364 @@ +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.
\ No newline at end of file diff --git a/wiki/2017-02-miniperi/elc201702.jpg b/wiki/2017-02-miniperi/elc201702.jpg Binary files differnew file mode 100644 index 0000000..08d82db --- /dev/null +++ b/wiki/2017-02-miniperi/elc201702.jpg diff --git a/wiki/2017-05-miniperi.wiki b/wiki/2017-05-miniperi.wiki new file mode 100644 index 0000000..dba86da --- /dev/null +++ b/wiki/2017-05-miniperi.wiki @@ -0,0 +1,50 @@ +h1. MiniPeriCon for MultiMedia 2017-05 + +| Date | 2017/05/29, 30 (before "OSS Japan":http://events.linuxfoundation.org/events/open-source-summit-japan/) | +| Place | "YUYUTEI":https://www.airbnb.com/rooms/17013981 | +| Member | Laurent, Kieran, Niklas, Magnus, Jacopo, Marek, Morimoto | + +!2017-05-miniperi/IMG_201705_1.JPG! !2017-05-miniperi/IMG_201705_2.JPG! !2017-05-miniperi/IMG_20170530_150006.jpg! !2017-05-miniperi/IMG_20170530_150016.jpg! +!2017-05-miniperi/IMG_20170603_114023.jpg! !2017-05-miniperi/IMG_20170603_104743.jpg! !2017-05-miniperi/IMG_20170603_105242.jpg! +!2017-05-miniperi/IMG_20170603_105902.jpg! !2017-05-miniperi/IMG_20170603_110553.jpg! !2017-05-miniperi/IMG_20170603_110603.jpg! !2017-05-miniperi/IMG_20170603_105328.jpg! !2017-05-miniperi/IMG_20170603_110713.jpg! +!2017-05-miniperi/IMG_20170603_110723.jpg! !2017-05-miniperi/IMG_20170603_111049.jpg! !2017-05-miniperi/IMG_20170603_113205.jpg! !2017-05-miniperi/IMG_20170603_111821.jpg! !2017-05-miniperi/IMG_20170603_111826.jpg! +!2017-05-miniperi/IMG_20170603_113214.jpg! !2017-05-miniperi/IMG_20170603_124831.jpg! !2017-05-miniperi/IMG_20170603_132350.jpg! !2017-05-miniperi/IMG_20170603_133957.jpg! !2017-05-miniperi/IMG_20170603_134012.jpg! +!2017-05-miniperi/IMG_20170603_134122.jpg! !2017-05-miniperi/IMG_20170603_161227.jpg! !2017-05-miniperi/IMG_20170603_161211.jpg! !2017-05-miniperi/IMG_20170603_134244.jpg! !2017-05-miniperi/IMG_20170603_161406.jpg! + +PeriPeri Tokyo Meeting - 2017-05-29 + +h1. V4L2 community status + +h2. Maintainership evolutions + +Laurent has explained the current maintainership issues in the V4L2 community. No notes have been taken to avoid leaking the content of the conversation, as the topic is very sensitive. + +h2. API reboot in 2018 + +V4L2 grew organically over 15 years. We're now reaching a point where the API is bloated and unclear. We need to rework it extensively, building upon good ideas and mistakes we've done in the past. A 3 days multimedia summit will be proposed for beginning of 2018 to discuss that work. + +h2. Community involvement to multimedia team members + +V4L2 lacks core developers who can review APIs and drivers. We would like the multimedia team to take a more leading role there, reviewing code posted by other developers (including drivers for non-Renesas platforms). This is useful for Renesas for two main reasons. From a PR point of view, being recognized as a reference for everything multimedia-related in Linux would benefit Renesas (although the effect on attracting customers might be more important for the RZ platforms than the R-Car platforms). From a technical point of view, becoming core developers builds knowledge in the team that can then be put to use for our own development. + +The easiest way to expand our community contributions is to handle them as part of base contracts. This implies that less base contract time will be spent on Renesas-related development, so we need Renesas to back us up on that decision. In practice, review of non-Renesas drivers should become acceptable deliverables for base contracts. + +We will experiment with adding "ongoing community development of interest" topic in the bi-weekly multimedia meeting during which every team member can report patches they noticed on mailing lists that they find is of interest to the team. + +We should also get more involved in the following tasks. + +# Contribute to V4L2 documentation. The API reference documentation is pretty extensive, but it lacks walk-through documentation. We should write that using one of the Renesas boards as an example. Unlike existing similar document that just list steps without explaining the rationale behind them, this tutorial-like documentation should be a V4L2 walk-through document that uses a particular board as an example only. Do this at elinux for a start and later it can be made more generic and moved to the kernel documentation. +# Give talks in conferences to share multimedia knowledge. This also expands our visibility towards the community and contributes to positioning ourselves as a reference for Linux mutlimedia development. +# Improve user tooling + +It would be helpful to create one or more "reference platforms" with good V4L2 device coverage. Using R-Car Gen3 hardware for this purpose makes sense, for instance cost effective ULCB boards. So we would need to get the out-of-tree V4L2 subsystem and device driver changes into mainline, and document how to use them in some sort of basic fashion. This could for instance be some simple example on how to set up media controller nodes to route video in certain ways on this particular reference platform. Then in detail workshops or talks can be given to show how to make use of various more advanced features of the hardware platform. The state of these probably needs to be continuously updated once the various incremental framework changes get accepted. + +h1. Multimedia plan & Additional tasks + +We have discussed the multimedia development plan for the next quarter, and drafted additional tasks candidates. Laurent will finalise the plan and additional tasks for end of June. + +h1. Video Codecs + +Possibly suitable for Q4. Magnus will provide more information/documentation related to use cases if he gets pinged by e-mail. + +h1. How to handle "periupport":https://osdg.renesas.com/periperi/periupport on MultiMedia group diff --git a/wiki/2017-05-miniperi/IMG_20170530_150006.jpg b/wiki/2017-05-miniperi/IMG_20170530_150006.jpg Binary files differnew file mode 100644 index 0000000..3052129 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170530_150006.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170530_150016.jpg b/wiki/2017-05-miniperi/IMG_20170530_150016.jpg Binary files differnew file mode 100644 index 0000000..91dea15 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170530_150016.jpg diff --git a/wiki/2017-05-miniperi/IMG_201705_1.JPG b/wiki/2017-05-miniperi/IMG_201705_1.JPG Binary files differnew file mode 100644 index 0000000..f9ccb8b --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_201705_1.JPG diff --git a/wiki/2017-05-miniperi/IMG_201705_2.JPG b/wiki/2017-05-miniperi/IMG_201705_2.JPG Binary files differnew file mode 100644 index 0000000..2862a18 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_201705_2.JPG diff --git a/wiki/2017-05-miniperi/IMG_20170603_104743.jpg b/wiki/2017-05-miniperi/IMG_20170603_104743.jpg Binary files differnew file mode 100644 index 0000000..e277d56 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_104743.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_105242.jpg b/wiki/2017-05-miniperi/IMG_20170603_105242.jpg Binary files differnew file mode 100644 index 0000000..3f2fad1 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_105242.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_105328.jpg b/wiki/2017-05-miniperi/IMG_20170603_105328.jpg Binary files differnew file mode 100644 index 0000000..dce6f86 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_105328.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_105902.jpg b/wiki/2017-05-miniperi/IMG_20170603_105902.jpg Binary files differnew file mode 100644 index 0000000..318cdc9 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_105902.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_110553.jpg b/wiki/2017-05-miniperi/IMG_20170603_110553.jpg Binary files differnew file mode 100644 index 0000000..5f3a451 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_110553.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_110603.jpg b/wiki/2017-05-miniperi/IMG_20170603_110603.jpg Binary files differnew file mode 100644 index 0000000..594b436 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_110603.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_110713.jpg b/wiki/2017-05-miniperi/IMG_20170603_110713.jpg Binary files differnew file mode 100644 index 0000000..ee0cecc --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_110713.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_110723.jpg b/wiki/2017-05-miniperi/IMG_20170603_110723.jpg Binary files differnew file mode 100644 index 0000000..4e6f3ce --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_110723.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_111049.jpg b/wiki/2017-05-miniperi/IMG_20170603_111049.jpg Binary files differnew file mode 100644 index 0000000..0c5ca63 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_111049.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_111821.jpg b/wiki/2017-05-miniperi/IMG_20170603_111821.jpg Binary files differnew file mode 100644 index 0000000..ce5ead5 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_111821.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_111826.jpg b/wiki/2017-05-miniperi/IMG_20170603_111826.jpg Binary files differnew file mode 100644 index 0000000..04331ba --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_111826.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_113205.jpg b/wiki/2017-05-miniperi/IMG_20170603_113205.jpg Binary files differnew file mode 100644 index 0000000..387232a --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_113205.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_113214.jpg b/wiki/2017-05-miniperi/IMG_20170603_113214.jpg Binary files differnew file mode 100644 index 0000000..f0b096e --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_113214.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_114023.jpg b/wiki/2017-05-miniperi/IMG_20170603_114023.jpg Binary files differnew file mode 100644 index 0000000..b887a7a --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_114023.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_124831.jpg b/wiki/2017-05-miniperi/IMG_20170603_124831.jpg Binary files differnew file mode 100644 index 0000000..66403ef --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_124831.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_132350.jpg b/wiki/2017-05-miniperi/IMG_20170603_132350.jpg Binary files differnew file mode 100644 index 0000000..cb4b0d8 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_132350.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_133957.jpg b/wiki/2017-05-miniperi/IMG_20170603_133957.jpg Binary files differnew file mode 100644 index 0000000..25773d1 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_133957.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_134012.jpg b/wiki/2017-05-miniperi/IMG_20170603_134012.jpg Binary files differnew file mode 100644 index 0000000..9e80007 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_134012.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_134122.jpg b/wiki/2017-05-miniperi/IMG_20170603_134122.jpg Binary files differnew file mode 100644 index 0000000..1a61fd8 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_134122.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_134244.jpg b/wiki/2017-05-miniperi/IMG_20170603_134244.jpg Binary files differnew file mode 100644 index 0000000..15af93e --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_134244.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_161211.jpg b/wiki/2017-05-miniperi/IMG_20170603_161211.jpg Binary files differnew file mode 100644 index 0000000..ecc0cb4 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_161211.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_161227.jpg b/wiki/2017-05-miniperi/IMG_20170603_161227.jpg Binary files differnew file mode 100644 index 0000000..0c14f7e --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_161227.jpg diff --git a/wiki/2017-05-miniperi/IMG_20170603_161406.jpg b/wiki/2017-05-miniperi/IMG_20170603_161406.jpg Binary files differnew file mode 100644 index 0000000..754e517 --- /dev/null +++ b/wiki/2017-05-miniperi/IMG_20170603_161406.jpg diff --git a/wiki/2017-09-periperi.wiki b/wiki/2017-09-periperi.wiki new file mode 100644 index 0000000..3205561 --- /dev/null +++ b/wiki/2017-09-periperi.wiki @@ -0,0 +1,141 @@ +h1. PeriPeriCon 2017-09 + +| Dates | 2017/09/04 - 2017/09/08 | | +| Place | San Sebastian, Spain | | +|/13. Member | Geert | 2017/09/03 - 2017/09/08 | II | +| Jacopo | 2017/09/04 - 2017/09/08 | AA | +| Kieran | 2017/09/03 - 2017/09/08 | II | +| Laurent | 2017/09/01 - 2017/09/09 | II | +| Magnus | 2017/09/02 - 2017/09/08 (and 2017/08/31 - 2017/09/02 in Bilbao) | UBA | +| Marek | 2017/09/03 - 2017/09/08 | II | +| Morimoto |/3. 2017/09/02 - 2017/09/08 | UBA | +| Shimoda | UBA | +| Ito | UBA | +| Niklas | 2017/09/03 - 2017/09/09 | AA | +| Simon | 2017/09/04 - 2017/09/08 (and 2017/09/08 - 2017/09/09 in Bilbao) | AA | +| Ulrich | 2017/09/02 - 2017/09/07 (2017/09/08 in Bilbao) | AK | +| Wolfram | 2017/09/03 - 2017/09/10 | AA | + +h2. Accommodation + +| Where | Dates | #Bedrooms, beds, bathrooms | Members | +| "Urban Beach Apartment (Hernani Kalea 2-1ª, Donostia, Euskadi 20004, Spain)":https://www.airbnb.com/rooms/14161535 | 2017/09/02 - 2017/09/08 | 4/8/3 | Ito, Morimoto, Shimoda, Magnus (+ alpha?) | +| "Alameda Apartment (Boulevard Zumardia 23, 20002 San Sebastián, Spain)":https://www.booking.com/hotel/es/alamedaapartment-by-feelfree-rentals.html | 2017/09/03 - 2017/09/09 | 3/6/2 | Wolfram, Simon, Jacopo, Niklas | +| Aldakonea Kalea, 20 2º dcha, Donostia, Euskadi 20012 | 2017/09/02 - 2017/09/07 | | Uli | +| "Palace II (Calle de Idiakez, 13 - 4º B, Donostia-San Sebastián)":https://www.airbnb.co.uk/rooms/3417691 | 2017/09/01 - 2017/09/08 | 4/8/2 | Kieran, Laurent, Geert, Marek | + +h2. Social Events + +h3. Culinary Experience + +| Date | 2017/09/06 20:30 | +| Place | "Mugaritz":https://www.mugaritz.com/ | +|/5. Members | Kieran | +| Laurent | +| Magnus | +| Morimoto | +| Simon | + +h3. Scuba Diving + +| Date | 2017/09/04 morning (tentative) | +| Place | http://www.buceodonosti.com/ (subject to change) | +|/3. Members | Kieran | +| Laurent | +| Niklas (If no licence or previous experience with diving is required) | + +h1. "All":http://muistio.tieke.fi/p/periperi-20170904 + +h2. base time distribution of developers amongst groups + +How much is there and how is it spread? Are we still aligned? + +h2. Patchwork maintenance + +* Currently managed by Simon (DT, arch/arm/mach-shmobile/, drivers/soc/renesas/) and Geert (drivers) +* Cleanup obsolete patches by individual members? +** Niklas is already doing that for his patches +* Offload MM patches to someone from MM? + +h2. Defconfigs + +* arm32: upstream shmobile_defconfig (ok), multi_v7_defconfig (huge) +* arm64: upstream defconfig (large) +* R-Car Gen3 defconfig? +* RZ/A1 XIP? + +h2. Remote access areas for improvement + +h1. "Core":http://muistio.tieke.fi/p/periperi-20170906 + +h2. Request from other team (for KVM) + +h3. IPMMU features + +* Support for more than 32-bits IOVA space +** GSX needs it. +* Support for multiple guests +** The current IPMMU implementation on Gen3 BSP, second guest OS cannot use GSX. (#3448, #3486) +* Support "16.5.2 IPMMU configuration for FCP-CS". +** IPMMU-PVn also need such handling (Rev.0.55 doesn't mention it though). + +h2. How to add support R-Car D3? + +Let's discuss about a tentative plan ("todo":../../wiki/2017-09-periperi/todo-for-R-Car-D3.txt). + +h2. How to add support R-Car H3N? + +* Management guys would like to reduce budget to support it somehow. +* For development, it is SiP on Salvator-X. But, for product, it will be SoC only. +* SoC is the same as the H3 ES3.0. +** So, PRR value is the same with H3... +* Pin assignment seems M3-W. +** So, some channels (e.g. USB host) are removed. + +h2. R-Car Gen2 DTS Update Flag Day + +| Component | DT bindings | Driver | DTS | +| APMU | OK | OK | OK | +| CMT | OK | TODO | TODO | +| CPG/MSSR | OK | OK | clock part OK, resets TODO | +| ICRAM | OK | OK | OK | +| RST | OK | OK | OK | +| SYSC | OK | OK | OK | + +* RZ/G1 already OK, except for CMT +* resets for DU are postponed +* SYSC is also used on R-Car H1, but backwards compatibility with old DT can just be dropped, too + +h1. "MultiMedia":http://muistio.tieke.fi/p/periperi-20170905 + +h2. Request from BSP team + +h3. Color Key support + +Local patch which was created by ADIT/REE (mentor?) is already exist ("patch1":../../wiki/2017-09-periperi/0001-v4l-vsp1-Add-support-for-colorkey-alpha-blending.patch, "patch2":../../wiki/2017-09-periperi/0002-drm-rcar-du-Add-support-for-colorkey-alpha-blending.patch). Thus this is "upport request". + +h3. 8ch Camera current status ? + +when it can be finished ? + +h2. How to add support R-Car D3? + +Let's discuss about a tentative plan ("todo":../../wiki/2017-09-periperi/todo-for-R-Car-D3.txt). + +h2. VSP YUV444M Test Hangs on BRS use cases. + +Brief discussion on what we can do to investigate and resolve this issue. Especially as it is now affecting Jinsai directly. + +h1. "I/O":http://muistio.tieke.fi/p/periperi-20170907 + +h2. How to add support R-Car D3? + +Let's discuss about a tentative plan ("todo":../../wiki/2017-09-periperi/todo-for-R-Car-D3.txt). + +h2. I2C IP core switching at runtime? + +Wolfram will present the status quo of the I2C IP core switcher and then we can discuss how to continue from there + +h2. SDR104 and HS400 + +Discuss upstream plans for the highest speed modes for SD and eMMC diff --git a/wiki/2017-09-periperi/0001-v4l-vsp1-Add-support-for-colorkey-alpha-blending.patch b/wiki/2017-09-periperi/0001-v4l-vsp1-Add-support-for-colorkey-alpha-blending.patch new file mode 100644 index 0000000..d95c662 --- /dev/null +++ b/wiki/2017-09-periperi/0001-v4l-vsp1-Add-support-for-colorkey-alpha-blending.patch @@ -0,0 +1,86 @@ +From 41b782c5d67bfaf7d61e27e7fcb7cedf1f1eea0b Mon Sep 17 00:00:00 2001 +From: Alexandru Gheorghe <Alexandru_Gheorghe@mentor.com> +Date: Wed, 15 Feb 2017 14:27:21 +0200 +Subject: [PATCH 1/2] v4l: vsp1: Add support for colorkey alpha blending + +The vsp2 hw supports changing of the alpha of pixels that match a color +key, this patch adds support for this feature in order to be used by +the rcar-du driver. +The colorkey is interpreted different depending of the pixel format: + * RGB - all color components have to match. + * YCbCr - only the Y component has to match. + +Signed-off-by: Alexandru Gheorghe <Alexandru_Gheorghe@mentor.com> +--- + drivers/media/platform/vsp1/vsp1_drm.c | 3 +++ + drivers/media/platform/vsp1/vsp1_rpf.c | 10 ++++++++-- + drivers/media/platform/vsp1/vsp1_rwpf.h | 3 +++ + include/media/vsp1.h | 3 +++ + 4 files changed, 17 insertions(+), 2 deletions(-) + +diff --git a/drivers/media/platform/vsp1/vsp1_drm.c b/drivers/media/platform/vsp1/vsp1_drm.c +index 3627f08..a4d0aee 100644 +--- a/drivers/media/platform/vsp1/vsp1_drm.c ++++ b/drivers/media/platform/vsp1/vsp1_drm.c +@@ -393,6 +393,9 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int rpf_index, + else + rpf->format.plane_fmt[1].bytesperline = cfg->pitch; + rpf->alpha = cfg->alpha; ++ rpf->colorkey = cfg->colorkey; ++ rpf->colorkey_en = cfg->colorkey_en; ++ rpf->colorkey_alpha = cfg->colorkey_alpha; + rpf->interlaced = cfg->interlaced; + + if (soc_device_match(r8a7795es1) && rpf->interlaced) { +diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c b/drivers/media/platform/vsp1/vsp1_rpf.c +index a12d6f9..91f2a9f 100644 +--- a/drivers/media/platform/vsp1/vsp1_rpf.c ++++ b/drivers/media/platform/vsp1/vsp1_rpf.c +@@ -356,8 +356,14 @@ static void rpf_configure(struct vsp1_entity *entity, + } + + vsp1_rpf_write(rpf, dl, VI6_RPF_MSK_CTRL, 0); +- vsp1_rpf_write(rpf, dl, VI6_RPF_CKEY_CTRL, 0); +- ++ if (rpf->colorkey_en) { ++ vsp1_rpf_write(rpf, dl, VI6_RPF_CKEY_SET0, ++ (rpf->colorkey_alpha << 24) | rpf->colorkey); ++ vsp1_rpf_write(rpf, dl, VI6_RPF_CKEY_CTRL, ++ VI6_RPF_CKEY_CTRL_SAPE0); ++ } else { ++ vsp1_rpf_write(rpf, dl, VI6_RPF_CKEY_CTRL, 0); ++ } + } + + static const struct vsp1_entity_operations rpf_entity_ops = { +diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h b/drivers/media/platform/vsp1/vsp1_rwpf.h +index fbe6aa6..2d7f4b9 100644 +--- a/drivers/media/platform/vsp1/vsp1_rwpf.h ++++ b/drivers/media/platform/vsp1/vsp1_rwpf.h +@@ -51,6 +51,9 @@ struct vsp1_rwpf { + unsigned int brs_input; + + unsigned int alpha; ++ u32 colorkey; ++ bool colorkey_en; ++ u32 colorkey_alpha; + + u32 mult_alpha; + u32 outfmt; +diff --git a/include/media/vsp1.h b/include/media/vsp1.h +index 97265f7..65e3934 100644 +--- a/include/media/vsp1.h ++++ b/include/media/vsp1.h +@@ -32,6 +32,9 @@ struct vsp1_du_atomic_config { + struct v4l2_rect dst; + unsigned int alpha; + unsigned int zpos; ++ u32 colorkey; ++ u32 colorkey_alpha; ++ bool colorkey_en; + bool interlaced; + }; + +-- +1.9.1 + diff --git a/wiki/2017-09-periperi/0002-drm-rcar-du-Add-support-for-colorkey-alpha-blending.patch b/wiki/2017-09-periperi/0002-drm-rcar-du-Add-support-for-colorkey-alpha-blending.patch new file mode 100644 index 0000000..bda2fd1 --- /dev/null +++ b/wiki/2017-09-periperi/0002-drm-rcar-du-Add-support-for-colorkey-alpha-blending.patch @@ -0,0 +1,176 @@ +From 9baeb4544b5f03c118c89156555d956b250f6174 Mon Sep 17 00:00:00 2001 +From: Alexandru Gheorghe <Alexandru_Gheorghe@mentor.com> +Date: Wed, 15 Feb 2017 14:50:28 +0200 +Subject: [PATCH 2/2] drm: rcar-du: Add support for colorkey alpha blending + +Add two new plane properties colorkey and colorkey_alpha for rcar gen3. +* colorkey: + - used for specifying the color on which the filtering is done. + - bits 0 to 23 are interpreted as RGB888 format, in case we are + dealing with an YCbCr format, only the Y componenet is + compared and it is represented by the G bits from RGB888 + format. + - bit 24 tells if it is enabled or not. +* colorkey_alpha: + - the alpha to be set for matching pixels, in case it is + missing the pixels will be made transparent + +Signed-off-by: Alexandru Gheorghe <Alexandru_Gheorghe@mentor.com> +--- + drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 + + drivers/gpu/drm/rcar-du/rcar_du_kms.c | 8 ++++++++ + drivers/gpu/drm/rcar-du/rcar_du_plane.c | 3 --- + drivers/gpu/drm/rcar-du/rcar_du_plane.h | 6 ++++++ + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 22 ++++++++++++++++++++++ + drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 5 +++++ + 6 files changed, 42 insertions(+), 3 deletions(-) + +diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h b/drivers/gpu/drm/rcar-du/rcar_du_drv.h +index 91e8fc5..1cb92e3 100644 +--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h ++++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h +@@ -98,6 +98,7 @@ struct rcar_du_device { + struct { + struct drm_property *alpha; + struct drm_property *colorkey; ++ struct drm_property *colorkey_alpha; + } props; + + unsigned int dpad0_source; +diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c +index 1cc88ed..a733fa2 100644 +--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c ++++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c +@@ -630,6 +630,14 @@ static int rcar_du_properties_init(struct rcar_du_device *rcdu) + if (rcdu->props.colorkey == NULL) + return -ENOMEM; + ++ if (rcdu->info->gen == 3) { ++ rcdu->props.colorkey_alpha = ++ drm_property_create_range(rcdu->ddev, 0, ++ "colorkey_alpha", 0, 255); ++ if (!rcdu->props.colorkey_alpha) ++ return -ENOMEM; ++ } ++ + return 0; + } + +diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c b/drivers/gpu/drm/rcar-du/rcar_du_plane.c +index e408aa3..df689c4 100644 +--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c ++++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c +@@ -307,9 +307,6 @@ int rcar_du_atomic_check_planes(struct drm_device *dev, + * Plane Setup + */ + +-#define RCAR_DU_COLORKEY_NONE (0 << 24) +-#define RCAR_DU_COLORKEY_SOURCE (1 << 24) +-#define RCAR_DU_COLORKEY_MASK (1 << 24) + + static void rcar_du_plane_write(struct rcar_du_group *rgrp, + unsigned int index, u32 reg, u32 data) +diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h b/drivers/gpu/drm/rcar-du/rcar_du_plane.h +index c1de338..9e7c3b6 100644 +--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h ++++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h +@@ -49,6 +49,12 @@ static inline struct rcar_du_plane *to_rcar_plane(struct drm_plane *plane) + return container_of(plane, struct rcar_du_plane, plane); + } + ++#define RCAR_DU_COLORKEY_NONE (0 << 24) ++#define RCAR_DU_COLORKEY_MASK BIT(24) ++#define RCAR_DU_COLORKEY_EN_MASK RCAR_DU_COLORKEY_MASK ++#define RCAR_DU_COLORKEY_COLOR_MASK 0xFFFFFF ++#define RCAR_DU_COLORKEY_ALPHA_MASK 0xFF ++ + /** + * struct rcar_du_plane_state - Driver-specific plane state + * @state: base DRM plane state +diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c +index 4b460d4..b223be1 100644 +--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c ++++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c +@@ -180,6 +180,11 @@ static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane) + .pitch = fb->pitches[0], + .alpha = state->alpha, + .zpos = state->state.zpos, ++ .colorkey = state->colorkey & RCAR_DU_COLORKEY_COLOR_MASK, ++ .colorkey_en = ++ ((state->colorkey & RCAR_DU_COLORKEY_EN_MASK) != 0), ++ .colorkey_alpha = ++ (state->colorkey_alpha & RCAR_DU_COLORKEY_ALPHA_MASK), + }; + unsigned int i; + +@@ -379,6 +384,8 @@ static void rcar_du_vsp_plane_reset(struct drm_plane *plane) + return; + + state->alpha = 255; ++ state->colorkey = RCAR_DU_COLORKEY_NONE; ++ state->colorkey_alpha = 0; + state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1; + + plane->state = &state->state; +@@ -394,6 +401,10 @@ static int rcar_du_vsp_plane_atomic_set_property(struct drm_plane *plane, + + if (property == rcdu->props.alpha) + rstate->alpha = val; ++ else if (property == rcdu->props.colorkey) ++ rstate->colorkey = val; ++ else if (property == rcdu->props.colorkey_alpha) ++ rstate->colorkey_alpha = val; + else + return -EINVAL; + +@@ -410,6 +421,10 @@ static int rcar_du_vsp_plane_atomic_get_property(struct drm_plane *plane, + + if (property == rcdu->props.alpha) + *val = rstate->alpha; ++ else if (property == rcdu->props.colorkey) ++ *val = rstate->colorkey; ++ else if (property == rcdu->props.colorkey_alpha) ++ *val = rstate->colorkey_alpha; + else + return -EINVAL; + +@@ -633,6 +648,13 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp) + + drm_object_attach_property(&plane->plane.base, + rcdu->props.alpha, 255); ++ drm_object_attach_property(&plane->plane.base, ++ rcdu->props.colorkey, ++ RCAR_DU_COLORKEY_NONE); ++ if (rcdu->props.colorkey_alpha) ++ drm_object_attach_property(&plane->plane.base, ++ rcdu->props.colorkey_alpha, ++ 0); + drm_plane_create_zpos_property(&plane->plane, 1, 1, + vsp->num_planes - 1); + } +diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h +index 3fd9cef..1543503 100644 +--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h ++++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h +@@ -47,6 +47,9 @@ static inline struct rcar_du_vsp_plane *to_rcar_vsp_plane(struct drm_plane *p) + * @sg_tables: scatter-gather tables for the frame buffer memory + * @alpha: value of the plane alpha property + * @zpos: value of the plane zpos property ++ * @colorkey: value of the color for which to apply colorkey_alpha, bit 24 ++ * tells if it is enabled or not ++ * @colorkey_alpha: alpha to be used for pixels with color equal to colorkey + */ + struct rcar_du_vsp_plane_state { + struct drm_plane_state state; +@@ -56,6 +59,8 @@ struct rcar_du_vsp_plane_state { + + unsigned int alpha; + unsigned int zpos; ++ u32 colorkey; ++ u32 colorkey_alpha; + }; + + static inline struct rcar_du_vsp_plane_state * +-- +1.9.1 + diff --git a/wiki/2017-09-periperi/todo-for-R-Car-D3.txt b/wiki/2017-09-periperi/todo-for-R-Car-D3.txt new file mode 100644 index 0000000..6ba4f82 --- /dev/null +++ b/wiki/2017-09-periperi/todo-for-R-Car-D3.txt @@ -0,0 +1,52 @@ +# core +r8a77995,v4.14,merged,geert,add binging SoC/Draak +CLK,v4.14,merged,geert,CLK support +SYSC,v4.14,merged,geert,SYSC support +PFC,v4.14,merged,shimoda, Initial/SCIF/I2C/EthernetAVB/USB2H/MMC/VoltageSwith +GPIO,v4.15,plan,shimoda, add D3 binding +SYS-DMAC,v4.15,plan,?, add D3 binding +IPMMU,v4.16,plan,?, add D3 binding + +# integration +r8a77995,v4.14,merged,geert, Initial integration (CPU/SYSC/CLK/RWDT/SCIF2) +r8a77995,v4.14,merged,shimoda, integration for PFC +r8a77995,v4.15,plan,shimoda, integration for GPIO +r8a77995,v4.15,plan,shimoda, integration for EthernetAVB +r8a77995,v4.15,plan,shimoda, integration for USBPHY/USB2-Host +r8a77995,v4.15,plan,?, integration for eMMC +r8a77995,v4.15,plan,?, integration for I2C/IIC +r8a77995,v4.15,plan,?, integration for {SYS,Audio}-DMAC +r8a77995,v4.16,plan,?, integration for IPMMUs +r8a77995,v4.16,plan,?, integration for RSND +r8a77995,v4.16,plan,?, integration for DU +r8a77995,v4.16,plan,?, integration for VIN + +# Multimedia +DU,v4.15,plan,?, add D3 binding +DU,?,plan,?, add LVDS support for D3 +VIN,?,plan,?, add D3 binding +RSND,?,plan,?, add D3 binding + +# I/O +SCIF,v4.14,merged,geert, add D3 binding +watchdog,v4.14,merged,geert, add D3 binding +EtherAVB,v4.15,plan,shimoda, add D3 binding +I2C,v4.15,plan,?, add D3 binding +IIC,v4.15,plan,?, add D3 binding + +USBPHY,v4.15,plan,shimoda, change spec of irq = otg +USBPHY,v4.15,plan,shimoda, separate spec (D3/E3 don't have some bits/regs on UCOM regs) +USBPHY,v4.15,plan,shimoda, add D3 binding +USBPHY,v4.15,plan,shimoda, add gpio support for D3/E3 +USBPHY,v4.15,plan,shimoda, add debugfs support for forced b-device mode +HSUSB,v4.15,plan,shimoda, add D3 binding + +SDHI,v4.15,plan,?, add D3 binding +SDHI,v4.16,plan,?, improve performance using IPMMU (change max_segs and removes WARN_ON) + +MSIOF,?,plan,?, add D3 binding +Thermal,?,plan,?, add D3 binding? or, need to prepare it before? + +PWM,?,plan,?, add D3 binding +CAN,?,noplan,?, add D3 binding + diff --git a/wiki/2017-10-miniperi.wiki b/wiki/2017-10-miniperi.wiki new file mode 100644 index 0000000..5e633c0 --- /dev/null +++ b/wiki/2017-10-miniperi.wiki @@ -0,0 +1,14 @@ +h1. MiniPeri-2017-10 + +| Dates | 2017/10/23 - 2017/10/27 | Availability | Lodging | +| Place | Prague, Czech Republic | +|/10. Member | Geert | 2017/10/22 - 2017/10/27 | Hilton (conference hotel) | + | Jacopo | 2017/10/23 - 2017/10/27 | + | Laurent | 2017/10/21 - 2017/10/29 | + | Magnus | 2017/10/21 - 2017/10/27 | Domus Henrici | + | Marek | I live in Prague | + | Morimoto | + | Niklas | 2017/10/22 - 2017/10/30 | EA Hotel Embassy Prague | + | Simon | Not attending | + | Ulrich | 2017/10/24 - 2017/10/25 | B&B Hotel Prague City | + | Wolfram | 2017/10/22 - 2017/10/30 | diff --git a/wiki/2018-02-periperi.wiki b/wiki/2018-02-periperi.wiki new file mode 100644 index 0000000..22314d8 --- /dev/null +++ b/wiki/2018-02-periperi.wiki @@ -0,0 +1,227 @@ +h1. PeriPeri-2018-02 + +http://muistio.tieke.fi/p/periperi-20180202 + +| Dates | 2018/02/01 - 2018/02/02 | +| Place | see 'Activities' below | +|/12. Member | Geert | 02/02 - 04/02 (night @Home) | +| Jacopo | 28/01 - 05/02 | +| Kieran | 28/01 - 05/02 | +| Laurent | 28/01 - 05/02 | +| -Magnus- | +| Marek | +| -Morimoto- | +| -Ito- | +| Niklas | 28/01 - 05/02 | +| Simon | 02/02 - 04/02 | +| Ulrich | 01/02 - 05/02 | +| Wolfram | 01/02 - 05/02 | + +h2. Activities in Brussels + +| Date | Time | Activity | Location | +| Monday 2018-01-29 | 09:00 - 18:00 | GMSL Code Camp | Antoine Dansaert 24, 1000 Brussels | +| Tuesday 2018-01-30 | 09:00 - 18:00 | GMSL Code Camp | Antoine Dansaert 24, 1000 Brussels | +| | 19:00 - 21:00 | San Sablon | | +| Wednesday 2018-01-31 | 09:00 - 13:00 | GMSL Code Camp | Antoine Dansaert 24, 1000 Brussels | +| Thursday 2018-02-01 | 14:30 - 18:00 | Multimedia Meeting | Antoine Dansaert 24, 1000 Brussels | +| Thursday 2018-02-01 | 19:00 | Dinner | https://www.bonsoirclara.com/en/ | +| Friday 2018-02-02 | 09:00 - 19:00 | Core, I/O Group, Virtualization BOF? | http://www.hotelbloom.com/ | +| Friday 2018-02-02 | 19:30 | Dinner | http://www.kokob.be/ | +| Saturday 2018-02-03 | 09:30 - 19:00 | FOSDEM | https://fosdem.org/2018/ | +| Sunday 2018-02-04 | 09:00 - 18:00 | FOSDEM | https://fosdem.org/2018/ | + +h2. List of material for Multimedia code camp + +|Who | What | +|/4. Jacopo | Scope (with probes) | +| Multimeter | +| Network switch | +| Power strip | +|/3. Kieran | Salvator-X H3 + Expansion board | +| 8x RDACM20 | +| 8x RDACM21 | +|/3. Laurent | Kingfisher (including H3SK and MAX9286 add-on boards) | +| Multimeter | +| Power strip | +|/3. Niklas | V3M + Expansion board | +| 8x RDACM20 | +| 8x RDACM21 | + +h2. Agenda for Friday Meeting + +| 09:00 - 09:30 | Welcome Coffee | +|/2. 09:30 - 10:30 | I/O Group Meeting (incl. future tasks) | +| - i2c mux | +| 10:30 - 11:00 | Coffee Break | +|/3. 11:00 - 12:30 | Core Group Meeting (incl. future tasks) (60') | +| - R-Car Gen2 Watchdog Timer | +| Improving renesas-drivers (30') | +| 12:30 - 13:30 | Lunch | +|/4. 13:30 - 15:30 | Virtualization BoF (120') | +| - Status reports | +| - Issues | +| - Next steps | +| 15:30 - 16:00 | Coffee Break | +|/2. 16:00 - 19:00 | Board Farm, Test automation, Remote access (60') | +| Hacking (Eagle, Draak, ...)? (120') | + +h2. Meeting minutes (thanks Kieran!) + +h1. I/O Group meeting + +h2. RAVB : 2K Header limits + +* Niklas has an idea to increase this limit. +* Difference between transmitting and receiving. + + +h2. SPECTRE + +* Wolfram raised that he is Interested in SPECTRE +* 3 Variants of SPECTRE, v2 is the worst - and it's unknown if we can fix it. +* Needs updated kernel (not available for ARM yet) and userspace rebuild. +* Userspace rebuilds (retpoline) may have a performance penalty. +* RMK has reportedly got PoC's which are even more effective at utilising the vulnerabilities. +* Meltdown (PTI) should be an easier fix. + + +h2. Handling Security Issues in a broad context: + +* Laurent raised that a bug in linux-media to read and write kernel memory. + +h2. SDHI + +* Rasied by Simon in absence +* Next steps for HS400 +* Driver and H3/M3-W enablement patches are pending review +* Second upport attempt seemed much easier than first as BSP seems closer to upstream now +* Would like to review other SDHI patches in BSP v3.6.0 with Wolfram, possibly on IRC some time in February +** Yes. WSA, SH to review. + +h2. I2C demux + +* Raised by Simon in absence +* Understands that consensus from San Sebastian meeting was to accept changes despite OOpses in some subsystems when switching cores. Not entirely happy but willing to accept that consensus. +* Would appreciate a rebast/repost of the dts patches +** Wolfram will repost patches. Ack, thanks! +* Any other issues + +h2. MAX9286 GPIO Controller Regulator Loop + +* Circular dependency on GPIO regulator for cameras on Eagle-V3M +* MFD is a lot of over head - but it the only 'correct' solution. + +h2. IO Group: General Status + +* Short meeting style is good for all. (and taken on by other groups) +* Wolfram reprhases summary to make sure he understands it in his own words. +* Wolfram likes Quarterly scheduling of tasks. +* IO tasks agreed by mid-january +** raised externally that this agreement is at least 1 month late however +** high confidence by end of December + +h2. I2C Mux + +* Can we leave mux channels open to improve performance (reduce 'deselect' calls) +* We can have multiple devices with the same 'default' address, and there must be a negotiation stage to re-configure each address on the child bus +** Currently handled by the device driver +* Should core be more involved in this? +* WSA to think about mux topic :-D + +h1. Core Group Meeting + +* Status updates round the table +* We're expecting a new Salvator-XS M3-N board potentially sometime in February ? +* Stout board (H2) getting improved support ... +* Can we add elinux-wiki links to cover letters when we send relevant patch sets for additional tasks. + +h2. RCar Gen2 Watchdog Timer + +* We have a patchset (with 25 patches) from Fabrizio Casteu, and we need to test them. +* Geert to try on Goelsch +* WSA to try on Lager +* Marek to try on Stout. + +h2. Future Tasks + +* With the upcoming complex Virtualised use cases, adding support for JTAG debuggers would assist in debugging complex issues of the virtualised environments at the core level. +* Function enablement on boards as we get them. +* New platforms share lots of support, and with the shared dtsi infrastructure board bringup should be rapid. +* Expand IPMMU IO Vspace to more than 32 bits (neg) +* Blocked on work from Magnus + +h3. Renesas Drivers + +* Improving Integration for multimedia +* Magnus would like a central place for latest multimedia work. +* it easier to use especially from a developer's point of view + +h3. Goals + +* "Renesas-next" but with WIP +* Testing -> Continuous testing +* Shouldn't be a development base +* Doing development on renesas-drivers, means you have to rebase on main before submission. +* Consumption by the BSP +** Releasing a custom kernel -> But we are not a distribution with the resources to test each release. +* Can we have a 'latest topic' branch to continue automatic integration into renesas-drivers +* standardise the feature branches and tag naming scheme +* Dependency handling +* mainline +* subsystem.next +* topic branch +* If you have complex / stale dependencies - then it's fine to leave them out of Renesas-Drivers + +h3. Topic naming scheme bikeshedding: + +* topic/name-version +* subsystem/next/drivers/feature/ +* subsystem/next/core/feature/ +* topic/subsystems/?/feature/ +* subsystem/topic/? + +h3. Preference: + +* Still to be considered ... + +h3. Update for magnus: + +* Standardize on a naming scheme, to define the topic prefix. From there Geert will integrate the latest version based on that prefix. + +h1. Virtualisation + +h2. QEMU running on an arm64 guest + +* Plain QEMU if host is amd64 or arm64 +* KVM if host is arm64 (R-CAR H3 or M3-W) +* KVM needs ARM trusted firmware with HYP support +** https://elinux.org/R-Car/Virtualization + +h2. Libvirt + +* virsh (on amd64, or arm64) +* virt-manager (on amd64) +** https://elinux.org/R-Car/Virtualization/Libvirt +* Provides an abstracted interface common description for multiple virtualisation options. + +h3. Virtualisation Status + +* Walk trhough of GPIO pass through from Geert +* Configuration of host to enable GPIO passthrough + +h3. Guest side (QEMU) + +* vfio-platform support not yet supported but patches were posted + +h2. Next Steps + +* Reset driver, using CPG/MSSR +* Interrupts +* IOMMU groups + +h1. Board Farms + +* BayLibre ACME is sold out. Can we make or obtain alternatives? +* Prototyping with a Teensy 3.2 (freescale cortex-M4) +* Kit: (Search aliexpress for 'travel router usb') diff --git a/wiki/2018-10-periperi.wiki b/wiki/2018-10-periperi.wiki new file mode 100644 index 0000000..ff51b18 --- /dev/null +++ b/wiki/2018-10-periperi.wiki @@ -0,0 +1,59 @@ +h1. PeriPeri-2018-10 + +|_. Dates | 2018-10-22 - 2018-10-28 | +|_. Place | Edinburgh, Dunbar | + +|_. Member |_. Availability |_. Lodging | +| Geert | 21.10. - 27.10.| "Leonardo Royal Hotel Edinburgh Haymarket":https://www.google.be/maps/place/Leonardo+Royal+Hotel+Edinburgh+Haymarket/@55.945548,-3.2162,17z/data=!3m1!4b1!4m7!3m6!1s0x4887c7a4724c032d:0x472325fac3192d05!5m1!1s2018-10-05!8m2!3d55.945545!4d-3.214006 | +| Marek | 21.10. - 29.10.| "Leonardo Royal Hotel Edinburgh Haymarket":https://www.google.be/maps/place/Leonardo+Royal+Hotel+Edinburgh+Haymarket/@55.945548,-3.2162,17z/data=!3m1!4b1!4m7!3m6!1s0x4887c7a4724c032d:0x472325fac3192d05!5m1!1s2018-10-05!8m2!3d55.945545!4d-3.214006, SDHI hackfest | +| Jacopo | 21.10. - 29.10.| "Castle Street/Hill Street":https://goo.gl/maps/zQoFgoYKJ642 | +| Kieran | 21.10. - 29.10.| "Castle Street/Hill Street":https://goo.gl/maps/zQoFgoYKJ642 | +| Laurent | 21.10. - 29.10.| "Castle Street/Hill Street":https://goo.gl/maps/zQoFgoYKJ642 | +| Niklas | 21.10. - 30.10.| "Picture House Apartment":https://www.google.de/maps/place/The+Picture+House+Apartment/@55.945446,-3.2079451,17z/data=!3m1!4b1!4m8!3m7!1s0x4887c798a0c9d019:0x799a3255300c5f1a!5m2!1s2018-10-29!2i2!8m2!3d55.945446!4d-3.2057564, SDHI hackfest,Somewhere in the city | +| Wolfram | 21.10. - 29.10.| "Picture House Apartment":https://www.google.de/maps/place/The+Picture+House+Apartment/@55.945446,-3.2079451,17z/data=!3m1!4b1!4m8!3m7!1s0x4887c798a0c9d019:0x799a3255300c5f1a!5m2!1s2018-10-29!2i2!8m2!3d55.945446!4d-3.2057564, SDHI hackfest | +| Morimoto | 20.10. - 27.10 | "Hampton by Hilton":https://maps.google.com/?q=166%20Fountainbridge%20Edinburgh,%20Eh3%209rx,%20GB| +| Simon | 26.10 | | + +h2. Activities in Edinburgh + +|_. Date |_. Time |_. Activity |_. Location | +| Monday 2018-10-22 | 09:00 - 18:00 |/3. ELCE |/3. EICC | +| Tuesday 2018-10-23 | 09:00 - 18:00 | +| Wednesday 2018-10-24 | 09:00 - 18:00 | +|/2. Thursday 2018-10-25 | 09:00 - 17:00 | "Automated Testing Summit":https://elinux.org/Automated_Testing_Summit | EICC, Ochil Suite 1-3, Level 1BA | + | 09:00 - 17:00 | Media Summit | EICC, Tinto | +|/2. Friday 2018-10-26 | 09:00 - 18:00 | PeriPeriCon | "The Melting Pot":https://www.google.de/maps/place/The+Melting+Pot/@55.953138,-3.1970548,17z/data=!4m12!1m6!3m5!1s0x4887c791006c418b:0x7426a0a05178e539!2sThe+Melting+Pot!8m2!3d55.953135!4d-3.194866!3m4!1s0x4887c791006c418b:0x7426a0a05178e539!8m2!3d55.953135!4d-3.194866 | + | 19:30 | Dinner after PeriPeriCon | "Kyloe":https://www.google.de/maps/place/Kyloe/@55.949952,-3.2100054,17z/data=!3m1!4b1!4m5!3m4!1s0x4887c7bd4cf1e80b:0xe5d60a2df04161b!8m2!3d55.949949!4d-3.2078167 | +| Saturday 2018-10-27 | as we want :) | SDHI hackfest | "The Royal Mackintosh Hotel":https://www.google.de/maps/place/Royal+Mackintosh+Hotel/@56.000057,-2.5156857,17z/data=!3m1!4b1!4m8!3m7!1s0x4887055ff2b8306b:0x932bf93b13cf7658!5m2!1s2018-10-29!2i2!8m2!3d56.000054!4d-2.513497, Dunbar | +| Sunday 2018-10-28 | as we want :) | SDHI hackfest | "The Royal Mackintosh Hotel":https://www.google.de/maps/place/Royal+Mackintosh+Hotel/@56.000057,-2.5156857,17z/data=!3m1!4b1!4m8!3m7!1s0x4887055ff2b8306b:0x932bf93b13cf7658!5m2!1s2018-10-29!2i2!8m2!3d56.000054!4d-2.513497, Dunbar | + +h2. Timetable for Friday Meeting at "The Melting Pot" + +| 09:00 | Room available | +| 11:00 | Bisquit break | +| 13:00 | Lunch break | +| 16:00 | Coffee break | +| 18:00 | Room must be left | +| 19:30 | Dinner (at Kyloe) | + +h2. Agenda for Friday Meeting + +|_. Who |_. What | +|/2. Geert | Core Group Status | + | Virtualization Status | +|/2. Morimoto | Renesas vs PeriPeri process topic | + | periupport/peripelist vs periject | + +h2. Meeting minutes + +http://muistio.tieke.fi/p/ppcedi18 + +h2. Picture :) + +!2018-10-periperi/peripeople-small.jpg! + +h1. Files + +"pdf: Status of Core":../../wiki/2018-10-periperi/PERIPERI_EDI.pdf +"pdf: Status of IO":../../wiki/2018-10-periperi/PeriPeriEdi-IO_Report.pdf +"pdf: PeriJect process":../../wiki/2018-10-periperi/process.pdf diff --git a/wiki/2018-10-periperi/PERIPERI_EDI.pdf b/wiki/2018-10-periperi/PERIPERI_EDI.pdf Binary files differnew file mode 100644 index 0000000..7f23851 --- /dev/null +++ b/wiki/2018-10-periperi/PERIPERI_EDI.pdf diff --git a/wiki/2018-10-periperi/PeriPeriEdi-IO_Report.pdf b/wiki/2018-10-periperi/PeriPeriEdi-IO_Report.pdf Binary files differnew file mode 100644 index 0000000..72b2ea7 --- /dev/null +++ b/wiki/2018-10-periperi/PeriPeriEdi-IO_Report.pdf diff --git a/wiki/2018-10-periperi/peripeople-small.jpg b/wiki/2018-10-periperi/peripeople-small.jpg Binary files differnew file mode 100644 index 0000000..37c086c --- /dev/null +++ b/wiki/2018-10-periperi/peripeople-small.jpg diff --git a/wiki/2018-10-periperi/process.pdf b/wiki/2018-10-periperi/process.pdf Binary files differnew file mode 100644 index 0000000..1084c75 --- /dev/null +++ b/wiki/2018-10-periperi/process.pdf diff --git a/wiki/2019-02-periperi.wiki b/wiki/2019-02-periperi.wiki new file mode 100644 index 0000000..0b2e946 --- /dev/null +++ b/wiki/2019-02-periperi.wiki @@ -0,0 +1,123 @@ +h1. PeriPeri-2019-02 + +| Dates | 2019-02-02 - 2019-02-03 | | +| Place | see 'Activities' below | | +|/10. Member | Geert | 2019-02-01 - 2019-02-03 | + | Jacopo | 2019-01-31 - 2019-02-05+| + | Kieran | 2019-02-01 - 2019-02-05+| + | Laurent | 2019-02-03 - 2019-02-05+| + | Magnus | mostly 2019-02-02 + 2019-02-03 | + | Marek | (wants to attend Fri+Sun meetings) | + | Niklas | 2019-01-31 - 2019-02-05+| + | Simon | 2019-01-31 - 2019-02-04 | + | Ulrich | 2019-01-31 - 2019-02-04 | + | Wolfram | 2019-02-01 - 2019-02-05 | + +h2. Activities in Brussels + +| Date | Time | Activity | Location | +| Friday 2019-02-01 | 09:00 - 17:00 | Core, I/O Group | http://www.bbl2meet.be/ (Penthouse) | +| Friday 2019-02-01 | 19:00 | Dinner | http://www.kokob.be/ | +| Saturday 2019-02-02 | 10:00 - 19:00 | FOSDEM | https://fosdem.org/2019/ | +| Sunday 2019-02-03 | 09:00 - 17:00 | FOSDEM | https://fosdem.org/2019/ | +| Sunday 2019-02-03 | 19:00 - ? | Global Dinner Meeting | https://www.winebarsablon.be/eng/ (Salon) | +| Tuesday 2019-02-05 | 09:00 - 12:00 | MM Group | ? | + +h2. Hardware wishlist + +| Hardware | Requested by | Brought by | Comment | +| Ebisu board | Wolfram | Geert | IIC_DVFS testing on Gen3 (hopefully an hour will do) | + +!2019-02-periperi/fosdem.png! + +h2. Agenda for Friday Meeting (Core + IO) + +h3. Core + +* ATF: +** Document installation procedure at elinux.org wiki +** Configure from DTS +** UBoot and ATF could be built through CI and tested. +*** e.g. https://travis-ci.org/marex/arm-trusted-firmware-1/builds/485750085 +*** https://docs.travis-ci.com/user/uploading-artifacts/ for prebuilt binaries ? + +* U-Boot: MMC HS200/HS400 and SD SDR104 issues. +** Playing whack-a-mole with bug fixes. +** Testing identified bugs in core U-Boot MMC code which is being explored and fixed. + +* OpenOCD +** Kernel awareness patches for GDB are progressing *SLOWLY*. +** A Latest RFC is posted by Linaro: +*** https://sourceware.org/ml/gdb-patches/2019-01/msg00596.html + +* BSP +** List is reducing for two reasons +*** We've got stuff done +*** BSP is filtered to priorities. + +* Upstream + Maintainers are happy. Renesas is seen as the 'second' best upstreaming ARM-SoC. + The first is ATMEL which is so small it's incomparable - they have less work to do :) + +* CPUidle: +** Get clarification of real issues (SYSC CPU/GSX concurrency?) +** Enable when we get newer SoC revisions where the hardware has been fixed + +* IPMMU +** Unusable on H3 before ES3.x.. +** E3/M3 might be OK (because they are newer) +** 32-bits IOVA space status? Discuss at Sundays IPMMU chat + +* TEE +** Coordinate between optee os and Linux -> Marek? + +* 32-bit DMA limitation on arm64 fixed upstream? + +* Gen3 TDSEL: +** Assumption: (1) reset state or (2) value programmed by bootloader is OK +** (2) => Add register to list of registers to save/restore during suspend/resume +** Describe TDSEL value in DT? + +* Patchwork and automatic status updates. +** Patchwork now has automatic filters to delegate to Geert / Horms / Kbingham +** A few false positives on the rules, but otherwise helpful. +** New rules to catch missing corners. +** Horms to suggest any extra rules to match maintained files +** KB to request automatic patchwork update tool against linux-next. + + +h3. IO + +* plan next tasks +* sync SDHI experiences (esp. Linux / U-Boot) +* [[upstream design for complex GMSLish I2C setups]] + +http://muistio.tieke.fi/p/PeriPeriBE + +h2. Agenda for Sunday Meeting (global & casual) + +* IPMMU (moved to Global due to Magnus' availability) +** What is the performance impact of enabling the IPMMU? +*** Needs benchmarking +*** IPMMU may not be useful for boards with less than 4 GiB of RAM + +* Periject +# Missing feature is automatic ID generation +*** To be implemented (on client) +# Run scripts to populate database from older data +# Go life +# Profit! ;-) + +* Discussion about future plans +** R-Car H3-N: No new information +** Virtualization: No feedback from Renesas + +h2. Agenda for Tuesday Meeting (MM) + + +h1. Files + +* "pdf: Core + Global":../../wiki/2019-02-periperi/PERIPERI_BE.pdf +* "pdf: IO":../../wiki/2019-02-periperi/PeriPeriBE-State_of_the_IO.pdf +* "jpg: Sunday Meeting 1":../../wiki/2019-02-periperi/195838.jpg +* "jpg: Sunday Meeting 2":../../wiki/2019-02-periperi/195912.jpg diff --git a/wiki/2019-02-periperi/195838.jpg b/wiki/2019-02-periperi/195838.jpg Binary files differnew file mode 100644 index 0000000..7b17c85 --- /dev/null +++ b/wiki/2019-02-periperi/195838.jpg diff --git a/wiki/2019-02-periperi/195912.jpg b/wiki/2019-02-periperi/195912.jpg Binary files differnew file mode 100644 index 0000000..8ddcc3b --- /dev/null +++ b/wiki/2019-02-periperi/195912.jpg diff --git a/wiki/2019-02-periperi/PERIPERI_BE.pdf b/wiki/2019-02-periperi/PERIPERI_BE.pdf Binary files differnew file mode 100644 index 0000000..1a5f83e --- /dev/null +++ b/wiki/2019-02-periperi/PERIPERI_BE.pdf diff --git a/wiki/2019-02-periperi/PeriPeriBE-State_of_the_IO.pdf b/wiki/2019-02-periperi/PeriPeriBE-State_of_the_IO.pdf Binary files differnew file mode 100644 index 0000000..b3702e2 --- /dev/null +++ b/wiki/2019-02-periperi/PeriPeriBE-State_of_the_IO.pdf diff --git a/wiki/2019-02-periperi/fosdem.png b/wiki/2019-02-periperi/fosdem.png Binary files differnew file mode 100644 index 0000000..8c673a0 --- /dev/null +++ b/wiki/2019-02-periperi/fosdem.png diff --git a/wiki/Chat_log.wiki b/wiki/Chat_log.wiki new file mode 100644 index 0000000..5cef64a --- /dev/null +++ b/wiki/Chat_log.wiki @@ -0,0 +1,97 @@ +h1. Chat Log + +|2019-12-19| core |"io":../../wiki/Chat_log/20191219-io-chatlog|mm| +|2019-11-28|"core":../../wiki/Chat_log/20191128-core-chatlog|"io":../../wiki/Chat_log/20191128-io-chatlog|mm| +|2019-11-07|"core":../../wiki/Chat_log/20191107-core-chatlog|"io":../../wiki/Chat_log/20191107-io-chatlog|mm| +|2019-10-10|"core":../../wiki/Chat_log/20191010-core-chatlog|"io":../../wiki/Chat_log/20191010-io-chatlog|"mm":../../wiki/Chat_log/20191010-mm-chatlog| +|2019-08-22|"core":../../wiki/Chat_log/20190822-core-chatlog|"io":../../wiki/Chat_log/20190822-io-chatlog|"mm":../../wiki/Chat_log/20190822-mm-chatlog| +|2019-08-01|"core":../../wiki/Chat_log/20190801-core-chatlog|"io":../../wiki/Chat_log/20190801-io-chatlog|mm| +|2019-06-20|"core":../../wiki/Chat_log/20190620-core-chatlog|"io":../../wiki/Chat_log/20190620-io-chatlog|"mm":../../wiki/Chat_log/20190618-mm-chatlog| +|2019-06-06|"core":../../wiki/Chat_log/20190606-core-chatlog|"io":../../wiki/Chat_log/20190606-io-chatlog|"mm":../../wiki/Chat_log/20190606-mm-chatlog| +|2019-05-23|"core":../../wiki/Chat_log/20190523-core-chatlog|"io":../../wiki/Chat_log/20190523-io-chatlog|"mm":../../wiki/Chat_log/20190523-mm-chatlog| +|2019-05-09|"core":../../wiki/Chat_log/20190509-core-chatlog|"io":../../wiki/Chat_log/20190509-io-chatlog|"mm":../../wiki/Chat_log/20190509-mm-chatlog| +|2019-04-18| core |"io":../../wiki/Chat_log/20190418-io-chatlog|"mm":../../wiki/Chat_log/20190418-mm-chatlog| +|2019-04-04|"core":../../wiki/Chat_log/20190404-core-chatlog|"io":../../wiki/Chat_log/20190404-io-chatlog|"mm":../../wiki/Chat_log/20190404-mm-chatlog| +|2019-03-07|"core":../../wiki/Chat_log/20190307-core-chatlog|"io":../../wiki/Chat_log/20190307-io-chatlog|"mm":../../wiki/Chat_log/20190307-mm-chatlog| +|2019-02-21|"core":../../wiki/Chat_log/20190221-core-chatlog|"io":../../wiki/Chat_log/20190221-io-chatlog|"mm":../../wiki/Chat_log/20190221-mm-chatlog| +|2019-01-24|"core":../../wiki/Chat_log/20190124-core-chatlog|"io":../../wiki/Chat_log/20190124-io-chatlog|"mm":../../wiki/Chat_log/20190124-mm-chatlog| +|2019-01-10|"core":../../wiki/Chat_log/20190110-core-chatlog| io |"mm":../../wiki/Chat_log/20190110-mm-chatlog| +|2018-12-20|"core":../../wiki/Chat_log/20181220-core-chatlog|"io":../../wiki/Chat_log/20181220-io-chatlog|"mm":../../wiki/Chat_log/20181220-mm-chatlog| +|2018-12-06|"core":../../wiki/Chat_log/20181206-core-chatlog|"io":../../wiki/Chat_log/20181206-io-chatlog|"mm":../../wiki/Chat_log/20181206-mm-chatlog| +|2018-11-22|"core":../../wiki/Chat_log/20181122-core-chatlog| io |"mm":../../wiki/Chat_log/20181122-mm-chatlog| +|2018-11-08|"core":../../wiki/Chat_log/20181108-core-chatlog|"io":../../wiki/Chat_log/20181108-io-chatlog|"mm":../../wiki/Chat_log/20181108-mm-chatlog| +|2018-10-18|"core":../../wiki/Chat_log/20181018-core-chatlog|"io":../../wiki/Chat_log/20181018-io-chatlog|"mm":../../wiki/Chat_log/20181018-mm-chatlog| +|2018-10-04|"core":../../wiki/Chat_log/20181004-core-chatlog|"io":../../wiki/Chat_log/20181004-io-chatlog|"mm":../../wiki/Chat_log/20181004-mm-chatlog| +|2018-09-20|"core":../../wiki/Chat_log/20180920-core-chatlog|"io":../../wiki/Chat_log/20180920-io-chatlog|"mm":../../wiki/Chat_log/20180920-mm-chatlog| +|2018-09-06|"core":../../wiki/Chat_log/20180906-core-chatlog|"io":../../wiki/Chat_log/20180906-io-chatlog|"mm":../../wiki/Chat_log/20180906-mm-chatlog| +|2018-08-23|"core":../../wiki/Chat_log/20180823-core-chatlog|"io":../../wiki/Chat_log/20180823-io-chatlog|"mm":../../wiki/Chat_log/20180823-mm-chatlog| +|2018-08-09|"core":../../wiki/Chat_log/20180809-core-chatlog|"io":../../wiki/Chat_log/20180809-io-chatlog|"mm":../../wiki/Chat_log/20180809-mm-chatlog| +|2018-07-26|"core":../../wiki/Chat_log/20180726-core-chatlog|"io":../../wiki/Chat_log/20180726-io-chatlog|"mm":../../wiki/Chat_log/20180726-mm-chatlog| +|2018-07-12|"core":../../wiki/Chat_log/20180712-core-chatlog|"io":../../wiki/Chat_log/20180712-io-chatlog|"mm":../../wiki/Chat_log/20180712-mm-chatlog| +|2018-06-07|"core":../../wiki/Chat_log/20180607-core-chatlog|"io":../../wiki/Chat_log/20180607-io-chatlog|"mm":../../wiki/Chat_log/20180607-mm-chatlog| +|2018-05-24|"core":../../wiki/Chat_log/20180524-core-chatlog|"io":../../wiki/Chat_log/20180524-io-chatlog|"mm":../../wiki/Chat_log/20180524-mm-chatlog| +|2018-05-09|"core":../../wiki/Chat_log/20180509-core-chatlog|"io":../../wiki/Chat_log/20180509-io-chatlog|"mm":../../wiki/Chat_log/20180509-mm-chatlog| +|2018-04-19|"core":../../wiki/Chat_log/20180419-core-chatlog|"io":../../wiki/Chat_log/20180419-io-chatlog|"mm":../../wiki/Chat_log/20180419-mm-chatlog| +|2018-04-05|"core":../../wiki/Chat_log/20180405-core-chatlog|"io":../../wiki/Chat_log/20180405-io-chatlog|"mm":../../wiki/Chat_log/20180405-mm-chatlog| +|2018-03-22|"core":../../wiki/Chat_log/20180322-core-chatlog|"io":../../wiki/Chat_log/20180322-io-chatlog|"mm":../../wiki/Chat_log/20180322-mm-chatlog| +|2018-03-01|"core":../../wiki/Chat_log/20180301-core-chatlog|"io":../../wiki/Chat_log/20180301-io-chatlog|"mm":../../wiki/Chat_log/20180301-mm-chatlog| +|2018-02-15|"core":../../wiki/Chat_log/20180215-core-chatlog|"io":../../wiki/Chat_log/20180215-io-chatlog|"mm":../../wiki/Chat_log/20180215-mm-chatlog| +|2018-01-25|"core":../../wiki/Chat_log/20180125-core-chatlog| io |"mm":../../wiki/Chat_log/20180125-mm-chatlog| +|2018-01-09|"core":../../wiki/Chat_log/20180109-core-chatlog|"io":../../wiki/Chat_log/20180109-io-chatlog|"mm":../../wiki/Chat_log/20180109-mm-chatlog| +|2017-12-14|"core":../../wiki/Chat_log/20171214-core-chatlog|"io":../../wiki/Chat_log/20171214-io-chatlog|"mm":../../wiki/Chat_log/20171214-mm-chatlog| +|2017-11-30|"core":../../wiki/Chat_log/20171130-core-chatlog|"io":../../wiki/Chat_log/20171130-io-chatlog|"mm":../../wiki/Chat_log/20171123-mm-chatlog| +|2017-11-09|"core":../../wiki/Chat_log/20171109-core-chatlog|"io":../../wiki/Chat_log/20171109-io-chatlog|"mm":../../wiki/Chat_log/20171109-mm-chatlog| +|2017-10-19|"core":../../wiki/Chat_log/20171019-core-chatlog|"io":../../wiki/Chat_log/20171019-io-chatlog|"mm":../../wiki/Chat_log/20171019-mm-chatlog| +|2017-10-05|"core":../../wiki/Chat_log/20171005-core-chatlog|"io":../../wiki/Chat_log/20171005-io-chatlog|"mm":../../wiki/Chat_log/20171005-mm-chatlog| +|2017-09-21|"core":../../wiki/Chat_log/20170921-core-chatlog|"io":../../wiki/Chat_log/20170921-io-chatlog|"mm":../../wiki/Chat_log/20170921-mm-chatlog| +|2017-09-06|"core":../../wiki/Chat_log/20170906-core-chatlog| io | mm| +|2017-08-17|"core":../../wiki/Chat_log/20170817-core-chatlog|"io":../../wiki/Chat_log/20170817-io-chatlog|"mm":../../wiki/Chat_log/20170817-mm-chatlog| +|2017-08-03| core |"io":../../wiki/Chat_log/20170803-io-chatlog|"mm":../../wiki/Chat_log/20170803-mm-chatlog| +|2017-07-20|"core":../../wiki/Chat_log/20170720-core-chatlog| io | mm| +|2017-07-06|"core":../../wiki/Chat_log/20170706-core-chatlog|"io":../../wiki/Chat_log/20170706-io-chatlog|"mm":../../wiki/Chat_log/20170706-mm-chatlog| +|2017-06-1x|"core":../../wiki/Chat_log/20170620-core-chatlog|"io":../../wiki/Chat_log/20170613-io-chatlog|"mm":../../wiki/Chat_log/20170621-mm-chatlog| +|2017-06-0x|"core":../../wiki/Chat_log/20170606-core-chatlog| io | mm| +|2017-05-1x|"core":../../wiki/Chat_log/20170523-core-chatlog|"io":../../wiki/Chat_log/20170516-io-chatlog|"mm":../../wiki/Chat_log/20170524-mm-chatlog| +|2017-05-0x|"core":../../wiki/Chat_log/20170509-core-chatlog| io |"mm":../../wiki/Chat_log/20170510-mm-chatlog| +|2017-04-1x|"core":../../wiki/Chat_log/20170425-core-chatlog|"io":../../wiki/Chat_log/20170418-io-chatlog|"mm":../../wiki/Chat_log/20170426-mm-chatlog| +|2017-04-1x|"core":../../wiki/Chat_log/20170411-core-chatlog| io |"mm":../../wiki/Chat_log/20170412-mm-chatlog| +|2017-03-2x|"core":../../wiki/Chat_log/20170329-core-chatlog| io |"mm":../../wiki/Chat_log/20170328-mm-chatlog| +|2017-03-0x|"core":../../wiki/Chat_log/20170314-core-chatlog|"io":../../wiki/Chat_log/20170307-io-chatlog|"mm":../../wiki/Chat_log/20170309-mm-chatlog| +|2017-02-2x|"core":../../wiki/Chat_log/20170228-core-chatlog| io |"mm":../../wiki/Chat_log/20170201-mm-chatlog| +|2017-01-1x|"core":../../wiki/Chat_log/20170117-core-chatlog|"io":../../wiki/Chat_log/20170116-io-chatlog|"mm":../../wiki/Chat_log/20170111-mm-chatlog| +|2016-12-2x|"core":../../wiki/Chat_log/20161220-core-chatlog| io |"mm":../../wiki/Chat_log/20161222-mm-chatlog| +|2016-12-1x|"core":../../wiki/Chat_log/20161206-core-chatlog|"io":../../wiki/Chat_log/20161214-io-chatlog|"mm":../../wiki/Chat_log/20161207-mm-chatlog| +|2016-11-2x|"core":../../wiki/Chat_log/20161122-core-chatlog| io |"mm":../../wiki/Chat_log/20161123-mm-chatlog| +|2016-11-1x|"core":../../wiki/Chat_log/20161108-core-chatlog|"io":../../wiki/Chat_log/20161110-io-chatlog|"mm":../../wiki/Chat_log/20161109-mm-chatlog| +|2016-10-2x|"core":../../wiki/Chat_log/20161025-core-chatlog| io |"mm":../../wiki/Chat_log/20161025-mm-chatlog| +|2016-10-0x| core | io |"mm":../../wiki/Chat_log/20161009-mm-chatlog| +|2016-09-2x|"core":../../wiki/Chat_log/20160927-core-chatlog|"io":../../wiki/Chat_log/20160921-io-chatlog|"mm":../../wiki/Chat_log/20160927-mm-chatlog| +|2016-09-1x|"core":../../wiki/Chat_log/20160913-core-chatlog| io |"mm":../../wiki/Chat_log/20160914-mm-chatlog| +|2016-09-0x|"core":../../wiki/Chat_log/20160830-core-chatlog|"io":../../wiki/Chat_log/20160901-io-chatlog|"mm":../../wiki/Chat_log/20160831-mm-chatlog| +|2016-08-1x|"core":../../wiki/Chat_log/20160809-core-chatlog|"io":../../wiki/Chat_log/20160811-io-chatlog|"mm":../../wiki/Chat_log/20160803-mm-chatlog| +|2016-07-2x| core |"io":../../wiki/Chat_log/20160726-io-chatlog| mm| +|2016-07-1x MiniPeriCon|core |"io":../../wiki/Chat_log/20160711-io-MiniPeriPeriCon-log|mm| +|2016-07-0x| core | io |"mm":../../wiki/Chat_log/20160706-mm-chatlog| +|2016-06-2x|"core":../../wiki/Chat_log/20160618-core-chatlog|"io":../../wiki/Chat_log/20160627-io-chatlog|"mm":../../wiki/Chat_log/20160622-mm-chatlog| +|2016-06-0x|"core":../../wiki/Chat_log/20160614-core-chatlog|"io":../../wiki/Chat_log/20160609-io-chatlog|"mm":../../wiki/Chat_log/20160608-mm-chatlog| +|2016-05-1x|"core":../../wiki/Chat_log/20160524-core-chatlog|"io":../../wiki/Chat_log/20160519-io-chatlog|"mm":../../wiki/Chat_log/20160525-mm-chatlog| +|2016-05-1x|"core":../../wiki/Chat_log/20160510-core-chatlog| io |"mm":../../wiki/Chat_log/20160511-mm-chatlog| +|2016-04-2x|"core":../../wiki/Chat_log/20160426-core-chatlog|"io":../../wiki/Chat_log/20160425-io-chatlog| mm| +|2016-04-1x|"core":../../wiki/Chat_log/20160412-core-chatlog|"io":../../wiki/Chat_log/20160411-io-chatlog|"mm":../../wiki/Chat_log/20160419-mm-chatlog| +|2016-03-1x|"core":../../wiki/Chat_log/20160315-core-chatlog|"io":../../wiki/Chat_log/20160314-io-chatlog|"mm":../../wiki/Chat_log/20160322-mm-chatlog| +|2016-03-0x|"core":../../wiki/Chat_log/20160301-core-chatlog| io |mm| +|2016-02-2x|"core":../../wiki/Chat_log/20160216-core-chatlog|"io":../../wiki/Chat_log/20160223-io-chatlog|mm| +|2016-01-2x|"core":../../wiki/Chat_log/20160119-core-chatlog|"io":../../wiki/Chat_log/20160127-io-chatlog|mm| +|2016-01-0x|"core":../../wiki/Chat_log/20160106-core-chatlog|"io":../../wiki/Chat_log/20160108-io-chatlog|mm| +|2015-12-2x|"core":../../wiki/Chat_log/20151215-core-chatlog|"io":../../wiki/Chat_log/20151221-io-chatlog|mm| +|2015-12-0x|"core":../../wiki/Chat_log/20151201-core-chatlog|"io":../../wiki/Chat_log/20151207-io-chatlog|mm| +|2015-11-1x|"core":../../wiki/Chat_log/20151117-core-chatlog|"io":../../wiki/Chat_log/20151119-io-chatlog|mm| +|2015-10-3x|"core":../../wiki/Chat_log/20191106-core-chatlog|"io":../../wiki/Chat_log/20151030-io-chatlog|mm| +|2015-10-1x| core |"io":../../wiki/Chat_log/20151015-io-chatlog|mm| +|2015-09-2x|"core":../../wiki/Chat_log/20150929-core-chatlog| io |mm| +|2015-09-1x|"core":../../wiki/Chat_log/20150914-core-chatlog|"io":../../wiki/Chat_log/20150915-io-chatlog|mm| +|2015-09-0x|"core":../../wiki/Chat_log/20150901-core-chatlog| io |mm| +|2015-08-2x| core |"io":../../wiki/Chat_log/20150826-io-chatlog|mm| +|2015-08-1x|"core":../../wiki/Chat_log/20150819-core-chatlog| io |mm| +|2015-08-0x|"core":../../wiki/Chat_log/20150805-core-chatlog|"io":../../wiki/Chat_log/20150804-io-chatlog|mm| +|2015-07-0x|"core":../../wiki/Chat_log/20150708-core-chatlog| io |mm|
\ No newline at end of file diff --git a/wiki/Chat_log/20150708-core-chatlog b/wiki/Chat_log/20150708-core-chatlog new file mode 100644 index 0000000..68014b1 --- /dev/null +++ b/wiki/Chat_log/20150708-core-chatlog @@ -0,0 +1,862 @@ +Geert Uytterhoeven 11:01 AM +Good morning/afternoon! +Magnus Damm 11:01 AM +Hey Geert! +Simon Horman 11:01 AM +Hi +Yoshihiro Shimoda 11:01 AM +Good afternoon! Geertsan! +Kuninori Morimoto 11:01 AM +Hi +Ulrich Hecht 11:01 AM +hello +Laurent Pinchart 11:02 AM +hello +Geert Uytterhoeven 11:02 AM +Cool, looks like it's working +Some people need pictures +Laurent Pinchart 11:03 AM +Are we having an audio conference ? +or just text ? +Geert Uytterhoeven 11:03 AM +Just text +Laurent Pinchart 11:03 AM +then why not irc ??? +Geert Uytterhoeven 11:04 AM +Good question... +Ulrich Hecht 11:04 AM +i was, in fact, even prepared for video +Geert Uytterhoeven 11:04 AM +Google Hangout is good for chat archival +Laurent Pinchart 11:04 AM +so is IRC, logs are easy +and there's more screen real estate +Geert Uytterhoeven 11:04 AM +Maybe next time on irc +Laurent Pinchart 11:04 AM +GH is a toy for text chat +Geert Uytterhoeven 11:05 AM +Well, this is a first try. +Agenda for first session: +1. IPMMU, +2. SMP DT, +3. Legacy board phase out. +A. Magnus' todo list format? +Magnus Damm 11:05 AM +Oh right +Geert Uytterhoeven 11:06 AM +I'd like to limit this to 1h30, so 20' per item? +Let's start with IPMMU. +Laurent Pinchart 11:06 AM +speaking of IRC, I believe it would be interesting to create a channel for our team. can we add that to the +agenda ? +it won't take long +Simon Horman 11:07 AM +Perhaps we can tackle that last if we have time +I agree it shouldn't take long +Geert Uytterhoeven 11:08 AM +I think IPMMU is (mostly) Laurent's kettle of fish? +Laurent Pinchart 11:08 AM +yes +what would you like to know about it ? +Magnus Damm 11:09 AM +we want to define tasks +Geert Uytterhoeven 11:09 AM +Apparently there's an issue with using IPMMU with (some) devices, cfr. Shimodasan's email +Magnus Damm 11:09 AM +and some back ground would be nice too +Geert Uytterhoeven 11:09 AM +What devices do we know IPMMU works with? +Laurent Pinchart 11:10 AM +it's not an IPMMU issue +it's a DMAC issue +we know about one IPMMU issue +Geert Uytterhoeven 11:10 AM +What devices do we know IPMMU doesn't work with? +Laurent Pinchart 11:10 AM +or rather one DMAC + IPMMU issue +Geert Uytterhoeven 11:10 AM +So I should have written IPMMU/DMAC +Laurent Pinchart 11:10 AM +in that DMAC channel 0 doesn't work properly with the IPMMU +I've raised that a long time ago +and got no feedback +Geert Uytterhoeven 11:11 AM +But we have a workaround for that, right? +Laurent Pinchart 11:11 AM +we don't know whether it has been fixed on Gen3 +the workaround is to not use channel 0 +so we're losing hardware +the second issue that Shimodasan raised is not caused by the IPMMU itself +Geert Uytterhoeven 11:12 AM +It's integration DMAC/IPMMU? +Laurent Pinchart 11:12 AM +but by the DMAC driver configuring the DMAC to issue bus master requests to a physical address even when +the accesses are translated by the IPMMU +it's a DMAC driver issue +or possibly a DMA slave driver issue +Geert Uytterhoeven 11:13 AM +Do you know how other DMAC drivers handle this? I'd assume IPMMU or not should be transparent. +Apparently all DMA slave drivers use the physical address when accessing device registers. +Laurent Pinchart 11:14 AM +as far as I can see, they don't, they're all broken +Magnus Damm 11:14 AM +From my side it looks like none of our DMA Engine slave drivers can work with IPMMU asis today, right? +But it may "only" be an issue of fixing the DMAC driver +Laurent Pinchart 11:14 AM +correct +Magnus Damm 11:15 AM +thanks for confirming my suspicion +Laurent Pinchart 11:15 AM +the DMA engine API passes the slave address as a dma_addr_t +but our drivers pass a physical address +so either we map the physical address to a DMA address in the slave drivers +or we modify the DMA engine API to pass a phys_addr_t and map the address in the DMAC driver +Geert Uytterhoeven 11:16 AM +yes, dma_slave_config uses dma_addr_t. but the docs say it's a physical address. And it's been like that since +its introduction +Magnus Damm 11:17 AM +it looks to me like the DMA Engine slave drivers are supposed to perform something similar to ioremap() to get +a virtual bus address +I think PCI device drivers tend to do something like that +but not for DMA Engine purpose +Laurent Pinchart 11:18 AM +the API documentation is incoherent +we first need to define what API we need +and then to fix the side that is broken +Magnus Damm 11:19 AM +sounds like a good plan +Geert Uytterhoeven 11:19 AM +I'm wondering why nobody else has that problem. +Magnus Damm 11:19 AM +we may want to cook up a prototype too so we can check if we can get it working at all +Geert Uytterhoeven 11:20 AM +At least on PowerPC/Cell, the IOMMU is mandatory. +Magnus Damm 11:20 AM +No one is using DMA Engine with IOMMU? +Geert Uytterhoeven 11:20 AM +On PS3, that was hidden by the hypervisor. +But on other Cell platorms, it should apply. +Magnus Damm 11:20 AM +Onchip devices with bus mastering capability is kind of common, right? +Geert Uytterhoeven 11:21 AM +spidernet doesn't use dma engine config (only dma to ring buffers) +Laurent Pinchart 11:21 AM +it could be that on some systems the DMA engine can bypass the IOMMU when it accesses slave devices, I +don't know +Geert Uytterhoeven 11:21 AM +Looking for other cell drivers... +Yoshihiro Shimoda 11:21 AM +I'm not sure but IOMMU ML is discussing PCI enviromnet +http://lists.linuxfoundation.org/pipermail/iommu/2015May/013052.html +Magnus Damm 11:22 AM +dma_map_resource() +Geert Uytterhoeven 11:22 AM +yep +Magnus Damm 11:22 AM +maybe similar to ioremap() but for devices? +Laurent Pinchart 11:22 AM +we don't need to map the whole resource, just part of it in our case +Magnus Damm 11:22 AM +right +Laurent Pinchart 11:23 AM +but in practice we can't map areas smaller than a page anyway +Geert Uytterhoeven 11:23 AM +indeed +Laurent Pinchart 11:23 AM +which, from an isolation point of view, is an issue +if we want to isolate devices, especially in virtual environment, we need to use PIO +Magnus Damm 11:23 AM +we will get a whole ton of these issues with security and virtualization +but lets save those for later +Geert Uytterhoeven 11:24 AM +I don't see any devices where we need a granularity smaller than 4 KiB? +Laurent Pinchart 11:24 AM +all of them ? +we're talking about DMA access to a hardware register +Magnus Damm 11:25 AM +i thought we sort of assigned one side at a time for the DMA API +so the CPU and the IOMMU should not be able to map at the same time +Geert Uytterhoeven 11:26 AM +Yes. What's the problem with accessing the other registers in the register block? It's the same device. +Magnus Damm 11:26 AM +writecombining? +Laurent Pinchart 11:26 AM +can you guarantee that the 4kB around the hardware register will always belong to the same device ? +Magnus Damm 11:26 AM +perhaps depends on the topology? +i think we can assume that +Geert Uytterhoeven 11:26 AM +I had a quick look at r8a7791.dtsi +(before I said "I don't see any devices where we need a granularity smaller than 4 KiB?") +CPU uses the plain MMU +DMA uses the IOMMU +Magnus Damm 11:27 AM +I think we can assume they are pagealigned +Geert Uytterhoeven 11:27 AM +Both can map the same register block ("4 KiB") at the same time +If a VM can use e.g. QSPI, it can map the registers using both MMU and IOMMU. +That's the idea, right? +Laurent Pinchart 11:28 AM +anyway, that's not an API issue, it's a hardware design issue +if multiple devices share the same 4kB page there's nothing we can do +Magnus Damm 11:28 AM +right +Laurent Pinchart 11:28 AM +and we don't need to take that into account in the API +Geert Uytterhoeven 11:28 AM +If the OS implementer is too stupid to DMA to other QSPI registers, that's his problem. He can write to these +registers using PIO too +Laurent Pinchart 11:29 AM +any other question regarding the IPMMU isssue ? +Magnus Damm 11:29 AM +i have one about the API +not about stupid users in virtualized environments +but the DMA API where I believe the "user" of a certain device is passed around and can either be the CPU or +the device +not both at the same time +so if we have a device using IOMMU with DMAC to access the hardware then is it OK to access other control +registers from the CPU? +Laurent Pinchart 11:31 AM +all the mappings will be noncacheable, so that's fine +Magnus Damm 11:32 AM +but the API described by Documentation/DMAAPI.txt allows more detailed control than that +but yes, we can treat it in a simple way for now, and more advanced usage may require different 4K pages for +different I/O areas within the save device +and in such case our hardware design may not be good enough +but shall we leave that for later? +Laurent Pinchart 11:34 AM +I'm not sure to see where the problem is +so let's leave it for later +Magnus Damm 11:34 AM +good +Laurent Pinchart 11:35 AM +no other question ? +Magnus Damm 11:35 AM +what needs to be done? +Laurent Pinchart 11:36 AM +I was going to mention that +action points for this item ? +Magnus Damm 11:36 AM +I think we need to cook up some prototype code +Laurent Pinchart 11:36 AM +1. finally get feedback from the hardware developers regarding the IPMMU + DMAC channel 0 issue +Magnus Damm 11:36 AM +to see if we can get _anything_ working at all +(haha, good luck) +Laurent Pinchart 11:37 AM +2. discuss API changes on the dmaengine mailing list +3. fix the code +1. is for Magnus +Magnus Damm 11:37 AM +I don't think so +if for anyone it would be the "Renesas interface person" +Geert Uytterhoeven 11:37 AM +Morimotosan? +Simon Horman 11:37 AM +I thought we agreed not to assign people to taks +Laurent Pinchart 11:38 AM +congratulations, you've just been appointed as the Renesas interface person ! +Yoshihiro Shimoda 11:38 AM +I will do the 1. +Geert Uytterhoeven 11:38 AM +Right +Laurent Pinchart 11:38 AM +Simon: did we ? ok +so, 3 actions points +Magnus Damm 11:38 AM +I expect both Shimodasan and Morimotosan to help out as Renesas interface for the core group +Simon Horman 11:38 AM +I may be mistaken +Laurent Pinchart 11:38 AM +1 is standalone, 3 depends on 2 +Magnus Damm 11:38 AM +thanks for stepping up, shimodasan +prototype is standalone too +Geert, can you collect these please? +Geert Uytterhoeven 11:39 AM +Sure, 3 is prototype? +Magnus Damm 11:40 AM +i thought 3 was proper implementation? +after determining the proper API +without knowing if the hardware works we can't do anything IMO +Geert Uytterhoeven 11:40 AM +Ah, so 0 is prototype +1.5 is prototype? +Magnus Damm 11:41 AM +that's better! (for me at least) +Geert Uytterhoeven 11:41 AM +BTW http://lists.infradead.org/pipermail/linuxarmkernel/2013April/165411.html +Laurent Pinchart 11:41 AM +I don't see a need for a prototype +Geert Uytterhoeven 11:41 AM +Arnd: The dma engine driver must know the address in its dma space, while the +slave driver has it available in physical space. These two are often the +same, but there is no generic way to convert between the two, especially +if the dma engine resides behind an IOMMU. +The best assumption we can make is that the dma engine driver knows +how to convert between the two. Interestingly the documentation for +dma_slave_config talks about "physical address", while the structure +itself uses a dma_addr_t. Linus Walleij introduced the structure in +c156d0a5b0 "DMAENGINE: generic slave channel control v3", so I assume +he can shed some light on what he was thinking. I assume the documentation +is right but the structure is not and should be converted to use +phys_add_t or resource_size_t. +Simon Horman 11:41 AM +I think it is likely some kind of loop between discuss and implement may emerge +Magnus Damm 11:42 AM +Laurent: have you tried DMA Slave API with IOMMU? +Laurent Pinchart 11:42 AM +Simon: agreed +Geert Uytterhoeven 11:42 AM +(Arnd should know, as he did PowerPC/Cell before, where the IOMMU is mandatory. Some scanning in the +sources makes me think it was al handled by the (real) Open Firmware on Cell) +Laurent Pinchart 11:42 AM +Magnus: no, and I'm not worried about it. it's an API issue +Magnus Damm 11:43 AM +I'm worried that we found it out at this timing. +I thought it was tested and ready to integrate +Geert Uytterhoeven 11:43 AM +Yes +Magnus Damm 11:44 AM +I agree that a proper API is needed +Geert Uytterhoeven 11:44 AM +Hence my question " +What devices do we know IPMMU works with?" in the beginning +But we're running out of time for this topic? +Laurent Pinchart 11:44 AM +ok, there's a discussion of the issue in that email thread +Magnus Damm 11:44 AM +I've tested the IPMMU with the DU +Geert Uytterhoeven 11:44 AM +s/we're running/we ran/ +Laurent Pinchart 11:44 AM +we need to study it and revive it +Yoshihiro Shimoda 11:45 AM +I have tested the IPMMU with xhci +Laurent Pinchart 11:45 AM +DU, VSP1 and DMAC (in mem to mem mode) have been tested +Magnus Damm 11:45 AM +I also tested USBHS +with some prototype patches +Simon Horman 11:45 AM +by tested, is the implication that they work? +Magnus Damm 11:45 AM +at least it may work +I believe USBHS needs more work +Yoshihiro Shimoda 11:46 AM +xhci works, I think +Magnus Damm 11:46 AM +but it is separate from the DMAC issue that sort of holds back a whole range of devices +But with USBHS I've seen that the hardware seems to work +I never seen anything like that for DMAC and IPMMU combo with DMA Engine slave +so may I add a prototype task just to test the hardware? +Laurent Pinchart 11:48 AM +Magnus: I think that's overkill +the DMA engine API needs to be fixed anyway +Magnus Damm 11:49 AM +Well, I don't want to flame, but I expected you to do this for your MMCIF work last summer after the IOMMU +and DMAC work +sure +Im not arguing against fixing the API +Laurent Pinchart 11:49 AM +that's interesting, because I'm pretty sure I've tested MMCIF +Magnus Damm 11:50 AM +So i thought it was tested +but it seems to not work at all +I should have tested on my side +so no blame on you +Laurent Pinchart 11:50 AM +I clearly remember running into issues with channel 0 + IOMMU with MMCIF +and not with channel 1 +Magnus Damm 11:50 AM +But looking at it now it seems that it couldn't ever work +Geert Uytterhoeven 11:50 AM +cfg.src_addr = res>start + MMCIF_CE_DATA; +Magnus Damm 11:51 AM +laurent: i'm not trying to get you to write a prototype +just saying that we need to do it +actual assignment is a different matter +Geert Uytterhoeven 11:51 AM +We just ran out of time for topic 2 +Magnus Damm 11:52 AM +haha +Geert Uytterhoeven 11:52 AM +Topic 2. SMP DT, +Magnus Damm 11:52 AM +So what does the Core Group leader say about prototyping? +Geert Uytterhoeven 11:52 AM +I wrote down: +Magnus Damm 11:52 AM +I will follow our leader penguin +Geert Uytterhoeven 11:52 AM +1. finally get feedback from the hardware developers regarding the IPMMU + DMAC channel 0 issue +2. implement prototype +3. discuss API changes on the dmaengine mailing list +4. implement proper solution +Kuninori Morimoto 11:52 AM +About quetion to HW team, +I can ask to HW team any quetion, but then I need "original question mail" from you guys. +It is difficult to create it by myself, since I don't know detail of this issue/background/problem. +Then, please send question email to my or shimodasan. +We can convert it English > Japanese, and ask to HW team. then feedback to you guys. +Is that OK ? +Magnus Damm 11:53 AM +Morimotosan, I think you can get history from Shimodasan +or me +Geert Uytterhoeven 11:53 AM +If the original answer is VHDL, please don't translate VHDL > Japanese > English +Topic 2. SMP DT +Magnus Damm 11:53 AM +ok +Geert Uytterhoeven 11:55 AM +This is about properly handling this with DT support, which is not backwards compatible with old DT +And it hinders topic 3. Legacy board phase out. +Magnus, you had patches to move forward? +Magnus Damm 11:55 AM +(Only if we want to) +Yeah, I think it is fine to disconnect the DT SMP enablement from the board phaseout +Simon Horman 11:56 AM +From my point of view the key is to undersand how we can move forward with the new DT SMP properties. +Magnus Damm 11:56 AM +This because DT SMP is likely to take quite a bit of time +Simon Horman 11:56 AM +While handling backwards compatibility in some controlled fashion +Magnus Damm 11:56 AM +Especially if we are going to open the can of worms with challenging the current API +Geert Uytterhoeven 11:57 AM +Yes +Magnus Damm 11:57 AM +s/API/DT style/g +Simon Horman 11:57 AM +And from my point of view r8a7779/marzen is a particularly interesting/difficult case +Magnus Damm 11:58 AM +I think it is a silly case, because we have nothing to share code with for r8a7779 +at least for RCar Gen2 we can use a new DT format to enable SMP on remaining SoCs +r8a7779 is breakage only without upside. complete wank +Geert Uytterhoeven 11:59 AM +And we don't care about DT backward compatibility for RCar Gen1 +Magnus Damm 11:59 AM +Well.. +We have some freedom +Simon Horman 12:00 PM +[to summarise the interesting/difficult big] we have an SoC (r8a7779) compat string which does not support +SMP while we have board (marzen, marzenreference) compat strings which do support SMP. And the default +configuration gives the latter. +s/big/bit/ +Magnus Damm 12:01 PM +What's the upside of doing SMP DT first? +(or doing it at all) +I mean compared to phasing out board support first +Geert Uytterhoeven 12:02 PM +For Gen1 or Gen2? +Magnus Damm 12:02 PM +r8a7779 +Geert Uytterhoeven 12:02 PM +We don't break SMP +Magnus Damm 12:02 PM +We do require DTB update for the existing boards, no? +which equals breakage +Geert Uytterhoeven 12:03 PM +Yes. So we have to update the DTB to keep SMP. +Magnus Damm 12:03 PM +if we do SMP DT first +Simon Horman 12:03 PM +taking a step back +Geert Uytterhoeven 12:04 PM +I understand there will be only one mandatory DT upgrade instead of two? +Simon Horman 12:04 PM +I believe we already support SMP for marzen using multiplatform +Magnus Damm 12:04 PM +simon: correct SMP is already supported by boardmarzenreference.c +Geert: I don't see the number of required updates? +Geert Uytterhoeven 12:06 PM +Forget about it, I think I'm mixing up with something else +Magnus Damm 12:06 PM +So adding a DT SMP dependency just delays things from my point of view +and by "things" i mean board cleanup +Laurent: Can you explain your concern? +Laurent Pinchart 12:07 PM +if we add SMP support through the machine description first +Simon Horman 12:07 PM +and by cleanup, your mean removal, right? +Geert Uytterhoeven 12:07 PM +For r8a7779 we may do without SMP DT. What prevents us from adding .smp = +smp_ops(r8a7779_smp_ops), to setupr88a7770.c? +Laurent Pinchart 12:07 PM +and then later move to DTbased SMP support +we'll have a regression +Magnus Damm 12:08 PM +laurent: we only have a regression when we decide to remove backwardsupport +Geert Uytterhoeven 12:08 PM +(setupr8a7779.c, of course) +Laurent Pinchart 12:08 PM +Magnus: of course +and I'd like to remove that +or, rather, not introduce it in the first place +Magnus Damm 12:08 PM +simon: cleanup = removal, yes +but we already have that for the board case, no? +so it is a matter of when to remove it? +Laurent Pinchart 12:09 PM +it's bad enough when we only have to deal with backward compat for unforeseen issues +if we already know that bindings will become deprecated before using them, it's even worse +Magnus Damm 12:10 PM +i thought we already were using them? +Laurent Pinchart 12:10 PM +on some platforms yes +my point is about new platforms +Magnus Damm 12:10 PM +on all r8a7779 systems +new platforms of course +but r8a7779 is not new +Geert Uytterhoeven 12:11 PM +I think ignoring DT SMP for r8a7779 makes sense. We already have enough to do for Gen2 +(and Gen3) +Magnus Damm 12:11 PM +We can perhaps keep an incremental DT SMP for r8a7779 task around? +But not let that block board phase out +Geert Uytterhoeven 12:11 PM +yes +task added +What about Gen2? +Magnus Damm 12:12 PM +We should add SMP DT before adding SMP support for new SoCs +Simon Horman 12:12 PM +magnus: would that retain the current beaviour where multiplatform supports SMP for marzen? +Magnus Damm 12:12 PM +but before adding SMP DT I want to discuss the DT format with ARM SoC maintainers +Geert Uytterhoeven 12:12 PM +Yes, else we're "too late", and stuck with more backward compatibility +Magnus Damm 12:13 PM +simon and geert: i'm confused with mix of marzen and Gen2, please rephrase +Simon Horman 12:13 PM +perhaps I am confused. Geert, did you have a proposal? +Geert Uytterhoeven 12:14 PM +If we add SMP support for new SoCs before adding SMP DT, we're "too late", and stuck with more backward +compatibility +Magnus Damm 12:14 PM +Geert: we will not +we have the "old way" for r8a7790 and r8a7791 +Geert Uytterhoeven 12:14 PM +not add support? Not be late? +Laurent Pinchart 12:14 PM +if we go strought for SMP DT for new SoCs I'll be happy, I don't need more +s/strought/straight/ +Magnus Damm 12:15 PM +Laurent: of course, i thought that's what we're doing +perhaps I'm wrong, but I thought newer SoCs don't include SMP support at this point +Simon Horman 12:15 PM +I think that is the nub of the issue +Magnus Damm 12:15 PM +Ulrich: do you know hte current state? +Geert Uytterhoeven 12:15 PM +Does that include the option to use new SMP DT (with a new DT of course) on '90/'91? +Simon Horman 12:15 PM +We should use the latest way to handle new SoCs. +Magnus Damm 12:15 PM +yes of course +Ulrich Hecht 12:16 PM +of what? +Magnus Damm 12:16 PM +if newer kernel suport for SoCs include SMP support or not? I don't remember latest state, but i believe you +hacked on it +My series "[PATCH 00/04] ARM: shmobile: APMU DT support via SMP Enable method" is intended to upgrade +SMP DT on r8a7790 and r8a7791, and be the only format for newer SoCs +Laurent Pinchart 12:17 PM +Geert: for 90 and 91, I'd like to add support for SMP DT and deprecate smp_ops. we'll have to keep them for +backward compatibility of course, and hopefully phase them out at some point +Ulrich Hecht 12:17 PM +no, i'm not aware +Geert Uytterhoeven 12:17 PM +OK +Magnus Damm 12:18 PM +ulrich: ok +Laurent Pinchart 12:18 PM +it looks like we all agree, don't we ? +Magnus Damm 12:18 PM +i think so +good +Simon Horman 12:18 PM +can we clafiry what we agreed on +? +Magnus Damm 12:18 PM +but i still want to discuss with ARM SoC maintainers about the existing format +Laurent Pinchart 12:18 PM +action points ? discuss SMP DT bindings with ARM SoC maintainers ? +Magnus Damm 12:18 PM +yeah +Geert Uytterhoeven 12:18 PM +Running out of time +Magnus Damm 12:18 PM +that is one task for sure +another task is APMU DT support +Simon Horman 12:19 PM +ok, geert, perhaps you could summarise things in an email +Geert Uytterhoeven 12:19 PM +My task list is +1. discuss SMP DT bindings with ARM SoC maintainers +2. Add DT SMP support for new SoCs (r8a7793/r8a7794) +A. Plan phaseout of old smp_ops for r8a7790/r8a7791 +B. DT SMP for r8a7779 +Magnus Damm 12:19 PM +sweet, thanks!! +Geert Uytterhoeven 12:19 PM +Isn't APMU DT included? +Magnus Damm 12:19 PM +it is part of 2 +Geert Uytterhoeven 12:20 PM +I mean, needed for seconary bringup? +Magnus Damm 12:20 PM +currently C structures encode the base address of the APMU +DT is on the way +Geert Uytterhoeven 12:20 PM +yes, that needs to move to DT +Magnus Damm 12:20 PM +but I rather handle it together with the silly "enablemethod" or whatnot +Geert Uytterhoeven 12:21 PM +yep +Topic 3. Legacy board phase out. +r8a7740 and sh73a0 are gone +r8a7778 and r8a7779 are next +Simon Horman 12:22 PM +is anything blocking the Gen1 boards? +Geert Uytterhoeven 12:22 PM +(esp. r8a7779 would make SYSC PM domains less work) +Kuninori Morimoto 12:22 PM +Can we remove r8a7778/r8a7779 support from driver then ? if so it is very good for me +Simon Horman 12:22 PM +I know we just talked about SMP for the 79. But anying else? +Magnus Damm 12:22 PM +Now when r8a7779 SMP DT has been agreed then we can fix that +I will resubmit patches +Geert Uytterhoeven 12:23 PM +we still need '78/'79 support in drivers, but only DT based +bockw mostly needs vin etc? +Simon Horman 12:23 PM +morimotosan: we are talking about removing legacy (nonmultiplatform) support. Not all support. +Kuninori Morimoto 12:24 PM +sorry +Simon Horman 12:24 PM +Ok, so some vin bindings are a dependency for removing bockw legacy? +Magnus Damm 12:24 PM +can anyone volunteer to get rid of r8a7778 legacy? +and finalize the conversion? +Geert Uytterhoeven 12:25 PM +The pins are in the dts, but not the vin enablement +Magnus Damm 12:25 PM +in reverse order? +How many BockW boards do we have? +Laurent Pinchart 12:25 PM +what are the missing pieces beyond vin ? +Magnus Damm 12:25 PM +I have one +Simon Horman 12:25 PM +I could look into that +Geert Uytterhoeven 12:25 PM +usb is missing +Simon Horman 12:26 PM +ok, so its enabled in board code but not in DT? +Geert Uytterhoeven 12:26 PM +yep +Simon Horman 12:26 PM +ok +Geert Uytterhoeven 12:26 PM +(was the same on armadillo, there it was known borken) +Laurent Pinchart 12:26 PM +are we missing USB DT support completely, or is it just a matter of enabling it ? +Simon Horman 12:26 PM +how about I start by looking at exactly what is missing: so far the list is vin and usb DT enablement +Laurent Pinchart 12:26 PM +how about the FPGA IRQ controller ? +Geert Uytterhoeven 12:27 PM +task added +Simon Horman 12:27 PM +i have (remote) access to the hw. so that is a start +Magnus Damm 12:27 PM +simon: ok, but pretty useless for USB and VIN +Simon Horman 12:27 PM +i also suspect ethernet is broken all over the place for gen1. that could be another task. +Magnus Damm 12:27 PM +and real physical hardware seems like a waste of time +in general r8a7778 seems like a waste of time to me +but that's just me +Simon Horman 12:28 PM +ok +shold we jsut remove it from mainline entirely? +Magnus Damm 12:28 PM +add a task: give magnus coffee to make him less grumpy +Simon Horman 12:28 PM +or leave it there without usb and vin enabled? +Magnus Damm 12:28 PM +Simon, you are interested in fixing it up? +is it possible to do so remotely? +Geert Uytterhoeven 12:29 PM +fpga is in both boardbockw.c and boardbockwreference.c +Magnus Damm 12:29 PM +and is that our only board? +Geert Uytterhoeven 12:29 PM +needed for sound and ethernet? +Simon Horman 12:29 PM +usb sounds possible to me +vin, perhaps not +Magnus Damm 12:30 PM +so perhaps USB and VIN shall be moved to I/O and Multimedia discussions? +and we can decide to either wait for those or just remove regardless +Simon Horman 12:30 PM +good idea +I'm interested in getting bockw fixd to whatever level we agree is sane. +Magnus Damm 12:30 PM +Maybe we can vote on what level is sane? +Simon Horman 12:31 PM +I would not object +Geert Uytterhoeven 12:31 PM +Before we can vote, we need +Simon Horman 12:31 PM +anyway, i will look at what is missing +Geert Uytterhoeven 12:31 PM +1. Identify missing support in multiplatform r8a7778 +(VIN, USB, FPGA IRQ?) +2. Identify missing support in multiplatform r8a7779 +Then +3. Add support for valuable devices to multiplatform r8a7778 +4. Add support for valuable devices to multiplatform r8a7779 +sorry, 2b vote +Simon Horman 12:32 PM +sounds good +Magnus Damm 12:32 PM +Geert: Sure, that is true, but there are cleanups needed before 1 too +Geert Uytterhoeven 12:32 PM +6. Drop legacy r8a7778/bockw +7. Drop legacy r8a7779/marzen +Simon Horman 12:32 PM +shall I take 1 and 2(a) ? +Magnus Damm 12:32 PM +for instance, for r8a7779 we can remove the boardmarzenreference.c +and for r8a7778 I think we have split DTSI still? +Simon Horman 12:32 PM +cleanups required to identify what is incomplete? +Magnus Damm 12:33 PM +no my 0 cleaups are independent +i'll fix r8a7779 +Geert Uytterhoeven 12:33 PM +Yes r8a7778bockw.dts and r8a7778bockwreference.dts +Magnus Damm 12:33 PM +but someone needs to fix r8a7778 +who had r8a7779 multiplatform as task? +Simon Horman 12:33 PM +it should not be as difficule at 79 +Magnus Damm 12:33 PM +i mean r8a7778 multiplat +Simon Horman 12:33 PM +as its UP, right? +Laurent Pinchart 12:34 PM +Magnus: don't we also miss r8a7779_init_irq_extpin ? +Magnus Damm 12:34 PM +laurent: it has been fixed already +Laurent Pinchart 12:34 PM +it's called from boardmarznreference.c +ah ok +Magnus Damm 12:34 PM +quite recently +so the boardmzref.c is ready to go after some minor SMP bit +but r8a7778 is more messy +Laurent Pinchart 12:35 PM +where's the fix ? +Magnus Damm 12:35 PM +it should have been picked up by simon +it was in the same series as where you questioned the SMP DT order for r8a7779. +let me find it +Laurent Pinchart 12:36 PM +"[PATCH v2 01/06] ARM: shmobile: r8a7779: Configure IRLM mode via DT" ? +Magnus Damm 12:36 PM +yes +Geert Uytterhoeven 12:36 PM +We ran out of time +Laurent Pinchart 12:36 PM +ok, I didn't realize it was about that +Magnus Damm 12:36 PM +once all contents of "[PATCH v2 00/06] ARM: shmobile: r8a7779 IRQ update and Marzen cleanup V2" are in i +intend to remove legacy code too +Laurent Pinchart 12:37 PM +by the way the commit message says "Adjust the r8a7779 SoC DTS and the Marzen Reference +C board code to use DTS only for INTCIRQPIN IRLM setup." +Magnus Damm 12:37 PM +but step by step +Laurent Pinchart 12:37 PM +but the patch doesn't touch C board code +Magnus Damm 12:37 PM +the board removal patch takes care of that i think +Laurent Pinchart 12:37 PM +yes it does +Magnus Damm 12:38 PM +so who can do r8a7778? +who did it initially? +Ulrich Hecht 12:38 PM +r8a7778 MP was me +but i don't have a board, making usb and vin difficult +Geert Uytterhoeven 12:38 PM +We found a winner +Magnus Damm 12:38 PM +you have a core developer task, right? +Ulrich Hecht 12:39 PM +me? yes, i do +Magnus Damm 12:39 PM +if so, can you move the multiplatform support forward? +like getting rid of that duplicated DTS setup +and things that do not depend on vin and usb +Geert Uytterhoeven 12:40 PM +Guys, we're running late. And my daughters want me to join lunch +Ulrich Hecht 12:40 PM +i just checked, and i think the list of missing stuff is conclusive. so apart from usb and vin, there's the fpga +Magnus Damm 12:40 PM +ok ok +Geert Uytterhoeven 12:40 PM +I will send the task list to periperi for final review +Magnus Damm 12:40 PM +thanks a lot everyone +Geert Uytterhoeven 12:40 PM +yes, thanks a lot. +Magnus Damm 12:40 PM +and thanks for preparing the task list geert!! +and arranging this meeting +Simon Horman 12:40 PM +Likewise, thanks everyine +Geert Uytterhoeven 12:41 PM +Will send out an invitation and RFC for topics for next chat +Magnus Damm 12:41 PM +wonderful +Laurent Pinchart 12:41 PM +what about the todo list format ? next time ? +Ulrich Hecht 12:41 PM +thanks, too. and if someone can give me a hint as to how to handle the fpga, i'd appreciate it +Magnus Damm 12:41 PM +ulrich: you can probably merge DTS independently of FPGA +Geert Uytterhoeven 12:41 PM +the fpga seems to be needed for Ethernet +Laurent Pinchart 12:41 PM +Ulrich: you might need to write a driver for the FPGA I'm afraid +Ulrich Hecht 12:41 PM +yes, of course +Laurent Pinchart 12:41 PM +I can assist with that +Ulrich Hecht 12:42 PM +that would be helpful. i couldn't find anything similar on other platforms +Laurent Pinchart 12:42 PM +we can discuss it later. on IRC maybe ? +Geert Uytterhoeven 12:42 PM +bye! (I'll keep the chat window open, though) +Magnus Damm 12:42 PM +bye bye! +Ulrich Hecht 12:43 PM +i'd prefer something more asynchronous, like email +Simon Horman 12:43 PM +I also need to attend to family matters, but will leave this window open. I expect to be back in 20min or so +Laurent Pinchart 12:43 PM +Ulrich: that works too +Ulrich Hecht 12:43 PM +ok, thanks a lot +Kuninori Morimoto 12:47 PM +Bye, I go back to my home +Yoshihiro Shimoda 12:50 PM +Bye! I also go back to my home diff --git a/wiki/Chat_log/20150804-io-chatlog b/wiki/Chat_log/20150804-io-chatlog new file mode 100644 index 0000000..39f0222 --- /dev/null +++ b/wiki/Chat_log/20150804-io-chatlog @@ -0,0 +1,382 @@ +--- Log opened Tue Aug 04 10:42:04 2015 +10:42 -!- wsa_ [~wsa@p4FE2576E.dip0.t-ipconnect.de] has joined #periperi +10:42 -!- Irssi: #periperi: Total of 4 nicks [0 ops, 0 halfops, 0 voices, 4 normal] +10:42 -!- Irssi: Join to #periperi was synced in 1 secs +10:43 < wsa_> konnichi wa +10:45 < morimoto> konnichi wa +10:46 < wsa_> hiya morimoto-san +10:46 < wsa_> how is copy/pasting windows code? ;) +10:47 < morimoto> Hehe :) it works very well for me (at this point) +10:48 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi +10:48 < wsa_> hello shimoda-san +10:48 < shimoda> hello wolfram-san! +10:49 -!- geertu [~geert@188.188.25.36] has joined #periperi +10:50 < geertu> Woops, I lost all networking (Internet/TV) at home ca, 30 minutes ago. +10:51 < geertu> Back online through 3G and Wifi-hotspot, but 3G coverage inside the house is really bad (and too much rain outside) +10:51 < wsa_> hi geert +10:52 < wsa_> i'll send some of the sunshine here towards you +10:52 < geertu> thx! +10:52 < geertu> Don't forget to keep some sunshine for your holidays next week ;-) +10:52 < wsa_> (and the plants could need a bit of rain, too) +10:52 < wsa_> :) +10:53 < wsa_> luckily, i am not so weather-dependent +10:53 < wsa_> the area is nice in any case +10:56 < morimoto> In these days, Japan is super very hot days. you can bring it +10:57 < geertu> yesterday it was super very hot in Belgium too. +10:57 < geertu> Today it's 10 degrees colder, and rainy +10:57 < wsa_> 33 degrees here, today +10:58 < morimoto> not so different ? Japan-Tokyo is 34 - 35 degrees +10:59 < wsa_> but probably a lot more humid +10:59 < morimoto> YES !! +10:59 < wsa_> :))) +10:59 < geertu> yeah... but not sufficiently humid to enjoy it (-> swimming pool) +11:00 -!- horms [~horms@121-80-222-183f1.hyg1.eonet.ne.jp] has joined #periperi +11:00 < wsa_> hello simon +11:00 < horms> wsa_: are we having an I/O group meeting about now? +11:00 < wsa_> yes, you got perfect timing +11:00 -!- geertu_ [~geert@d54C15D57.access.telenet.be] has joined #periperi +11:01 < horms> excellent +11:01 < wsa_> geert has lagging problems? +11:02 < geertu> Yeah, dah Internet is back +11:02 * geertu switches back to broadband +11:02 -!- geertu [~geert@188.188.25.36] has quit Quit: leaving +11:02 < wsa_> \o/ +11:02 < geertu_> hi +11:02 -!- geertu_ is now known as geertu +11:03 < wsa_> so, i guess we can start now +11:03 < geertu> Doh, and the 3G just managed to pull in drm/du/vsp1-kms... +11:03 < wsa_> thanks for coming to this very first IO Group IRC Chat Meeting +11:03 < wsa_> let's make history! +11:03 < wsa_> ahem +11:03 < wsa_> :) +11:04 < wsa_> the topics and order i'd propose are: +11:04 < wsa_> 1) Needed steps for Gen3 (should be easily dealt with) +11:05 < wsa_> 2) status of SCIF (DMA...) +11:05 < wsa_> 3) discuss the current list of tasks +11:05 < wsa_> the last one will probably evolve into questions like "tracking the BSP" and "reproducing issues" +11:06 < geertu> git log +11:06 * geertu sorry wrong window +11:06 < wsa_> any comments to that? any additions? +11:06 < horms> I have one more, small item: scif patches in Rcar-Gen2 BSP 1.9.5 +11:07 < horms> if we have time +11:07 < geertu> Doesn't that fall under 2)? +11:07 < horms> probably :) +11:07 < wsa_> I'd think so, too +11:07 < horms> ok, that is fine by me +11:08 < wsa_> so, let's start with 1) +11:09 < wsa_> by mail, shimoda-san said that I2C enablement patches for Gen3 are needed, prototypes will do +11:09 < wsa_> I can do this before I go on vacation +11:09 < morimoto> very good ! +11:09 < wsa_> the cores have additions, but should be (tm) backwards compatible +11:09 < horms> ok, iirc that was around the 11th +11:10 < wsa_> it will be a matter of adding compatibles, I can do this today +11:10 < horms> ok, sounds good from my pv +11:11 < horms> ok, sounds good from my pov +11:11 < wsa_> anything else for Gen3? +11:11 < wsa_> some news since yesterday? :) +11:11 < shimoda> about etheravb +11:11 < shimoda> it needs until 25th august +11:12 < shimoda> yesterday? +11:13 < horms> is driver work required for etheravb, over what is queued up for v4.3 in net-next +11:13 < horms> ? +11:13 < wsa_> shimoda: sorry, not yesterday, but since your mail +11:14 < morimoto> horms: do you mean for Gen3 BSP ? +11:14 < horms> yes +11:14 < wsa_> horms: have you checked the Gen3 docs if EtherAVB is the same as Gen2? +11:15 < horms> wsa_: ah, not as much as i should have +11:15 < horms> is that an ai for me? +11:15 < wsa_> can you do this please? +11:15 < horms> sure +11:16 < morimoto> for BSP, we need EtherAVB but no one is listed inhouse Renesas. +11:16 < horms> ok, i guess it defaults to cogent +11:17 < wsa_> still, will be nice to know if the IP cores are the same or how they differ +11:17 < morimoto> I guess integration is not a big deal (if it has compatible) +11:17 < horms> wsa_: agreed +11:17 < morimoto> If it needs driver update, then Cogent ? +11:18 < horms> morimoto: I don't know. But they have handled the driver so far. +11:18 < morimoto> yes +11:18 < wsa_> hmmm, who knows this answer? +11:18 < horms> If we have to rely on Cogent for driver updates for the Gen3 BSP then I think we have a problem +11:19 < horms> wsa_: probably Munakata-san, but my feeling is it would be best to talk to Magnus. +11:19 < wsa_> okay +11:19 < horms> in any case, i don't think we can resolve it here +11:20 < wsa_> yes +11:20 < wsa_> I'd think, let's check the IP cores, find out responsibilities and let's see from there... +11:20 < shimoda> at the moment, bsp team is debugging etheravb +11:20 < horms> good plan +11:21 < horms> shimoda: on gen2 hw? +11:21 < wsa_> shimoda: gen2 or gen3? +11:21 < wsa_> :D +11:21 < shimoda> sorry, on gen3 +11:22 < wsa_> so, it might even be a moving target +11:22 < shimoda> according to his email, gen3 needs some additional setting in avb and phy +11:23 < shimoda> so, for upstreaming, we need his help +11:23 < horms> komatsu-san? +11:24 < shimoda> His name is Nagai-san, sometimes he sent email to net ML +11:24 < horms> oh ok +11:25 < horms> should I/we talk to him? +11:25 < horms> He may be aware of some issues that are outside of what is described in the documentation we have +11:26 < shimoda> yes, i\I will talk to him about gen3 avb +11:26 < horms> excellent, thanks +11:26 < wsa_> thank you +11:26 < wsa_> i will talk to magnus about the responsibility +11:27 < wsa_> and simon will have a look at the docs +11:27 < wsa_> so, last call for Gen3 topics +11:28 < morimoto> 1 question about I2C +11:28 < morimoto> I guess Gen3 has 2 type of I2C ? +11:28 < wsa_> yes, 7x I2C and 1x IIC +11:28 < morimoto> which I2C do you enable before your vacation ? +11:29 < wsa_> both +11:29 < morimoto> Cool !! Thanks +11:29 < wsa_> it is just compatibles +11:29 < wsa_> :) +11:29 < shimoda> for gen3, we need some code of "SPI" until 1st Sept. +11:30 < shimoda> maybe MSIOF +11:30 < geertu> The real MSIOF or the "slave-only" MSIOF? +11:30 < shimoda> it is the real MSIOF +11:32 < geertu> (from "Gen3 work") MSIOF: Looks identical to Gen2 +11:32 < geertu> (from "Gen3 work" email) MSIOF: Looks identical to Gen2 +11:32 < wsa_> okay, so another compatible update +11:32 < wsa_> geert: can you do this till Sep, 1st? ;) +11:32 < geertu> RPC (2x QSPI) needs a new driver +11:32 < geertu> Sure, but currently I cannot test it +11:33 < wsa_> i know +11:33 < wsa_> let's see how the hardware status is 3 weeks +11:34 < wsa_> if there is no HW, then we do the prototypes again +11:34 < wsa_> OK, I'd like to move on to the next topic +11:34 < horms> i would guess it wiil be similar to now :^) +11:35 < wsa_> i wouldn't bet much against it ;) +11:35 < geertu> I guess they will produce hardware during the Renesas Summer Holiday Week? +11:35 * geertu wonders if that needs a smiley or not... +11:35 < morimoto> In our plan we will have 1 H3 board tomorrow +11:35 < wsa_> so, SCIF +11:36 < geertu> Great! +11:36 < morimoto> and Magnus will setup it on his remote access machine +11:36 < wsa_> WOW! +11:36 < geertu> Great! (x2) +11:36 < morimoto> (If we can have board) +11:36 < shimoda> sorry, about RPC, I'm not sure but BSP team doesn't support it because secure +11:36 < geertu> Just before I left for holidays, I posted a big patch series for SCIF DMA +11:37 < wsa_> (so, I will wait a few days before posting the I2C Gen3 patches, maybe i can test after all) +11:37 < geertu> It's sort of working now +11:37 < geertu> But it needs more rework and cleanup +11:37 < horms> excellent +11:37 < wsa_> great +11:37 < morimoto> cool +11:37 < horms> I believe the state of scif in the gen2 BSP is a point of concern +11:38 < wsa_> does the rework need DMA framework changes? +11:38 < geertu> I think half of the patches in that series can be sent out for integration, but I didn't have time to do the split when I sent the whole series. +11:38 < geertu> Good question! +11:39 < geertu> It relies on "modern" residu handling, which the shdmac driver doesn't provide (do we care? I posted an RFC patch) +11:40 < geertu> And I had to change the SCIF driver to not resubmit DMA descriptors, as rcar-dmac doesn't support that +11:40 < geertu> Still waiting for Laurent's response to my rcar-dmac emails... +11:40 < horms> which hardware do we use shdma on? +11:41 < geertu> "sh-dma-engine" (sh, legacy shmobile) +11:41 < geertu> "renesas,shdma-r8a73a4" (r8a73a4) +11:41 < geertu> "hpb-dma-engine" (legacy r8a777x) +11:41 < geertu> "sudmac" (unused, referred to by r8a66597_udc on ecovec24/kfr2r09/se) +11:42 < geertu> That was the long answer +11:42 < horms> ok +11:42 < geertu> The short answer is: nothing that uses DT and multi-platform +11:42 < horms> so my feeling is that if we aren't using it on multiplatform gen2 (or 3) then its not so important +11:42 < geertu> "renesas,shdma-r8a73a4" is not really used +11:43 < wsa_> does the BSP use rcar-dmac meanwhile? +11:43 < horms> good question +11:43 < horms> they are using multiplatform (i believe) +11:43 < horms> and they only care about gen2 +11:43 < horms> so it seems likely +11:43 < horms> but i don't know for sure +11:44 < geertu> renesas-backports/bsp/v3.10.31-ltsi/rcar-gen2-1.9.5:drivers/tty/serial/sh-sci.c still has +11:44 < horms> my feeling about the relationship between this work and the bsp is +11:44 < geertu> struct shdma_desc *sh_desc = container_of(desc, +11:44 < geertu> struct shdma_desc, async_tx); +11:44 < horms> that they have been doing some work to try to stablalise sh-sci +11:44 < geertu> Now, you can still do the container_of() on an rcar-dmac dma_desc object, and get bogus results :-) +11:45 < horms> and i see they have some fixes in the latest v1.9.5 bsp +11:45 < geertu> So I don't think they use rcar-dmac. +11:45 < horms> now, if we can provide them a nice set of fixes to solve their problems then that would be great +11:45 < wsa_> horms: they seem to do, there is even a patch for it in the BSP (which is already upstream, too) +11:45 < horms> but if its invasive, touching all sorts of code, then its not really appropriate for the gen2 bsp +11:46 < shimoda> they use rcar-dmac for audio and some customers uses it for sdhi/mmc +11:46 < shimoda> they = BSP team +11:46 < geertu> #define r8a7791_register_sys_dmac(id) \ +11:46 < geertu> platform_device_register_resndata( \ +11:46 < geertu> &platform_bus, "sh-dma-engine", 2 + id, \ +11:46 < geertu> &r8a7791_sys_dmac_resources[id * 3], id * 1 + 3, \ +11:46 < geertu> &r8a7791_sys_dmac_platform_data, \ +11:46 < geertu> sizeof(r8a7791_sys_dmac_platform_data)) +11:47 < geertu> So they use shdmac with hardcoded chabnnels in board code +11:47 < horms> with multiplatform boots? +11:47 < wsa_> so, if they use rcar-dmac already, it would be a technically wise decision if they would use rcar-dmac for serial, too, no? +11:48 < horms> it might be wise +11:48 < shimoda> sorry, they use both rcar-dmac and shdmac +11:48 < horms> but feature-wise the tree is frozen +11:48 < geertu> I once asked Kaneko-san explicitly with which dmac driver his sh-sci patches were tested, as IMHO the patch couldn't work with rcar-dmac (don't remember why, though) +11:48 < horms> geertu: just to clarify, those would be BSP-team patches, he isn't on the team +11:49 < wsa_> horms: is switching to rcar-dmac a feature or a bugfix? +11:49 < horms> i guess it might be either +11:49 < wsa_> if it was a feature, then the bugfix would be to keep on hacking on shdma +11:50 < wsa_> which is not what we really want being the upstram focused team, or? +11:50 < wsa_> (I might be wrong, but I recall Laurent not being very happy with shdma) +11:50 < horms> well, i think that this is one area where there has been some divergence between upstream and the BSP +11:50 < horms> and in my opinion that is not ideal +11:51 < horms> but i wonder what the best way forwards is +11:51 < geertu> r8a7791.dtsi has no "dmas" properties, except in the rcar_sound node +11:51 < horms> i beliwve we have trouble in both mainline and bsp +11:51 < geertu> yes +11:51 < horms> and obviously we wish to fix the former properly +11:51 < geertu> sh-sci needs more care. +11:52 < horms> and ideally take that to the bsp, but i think the devil is in the details +11:52 < horms> regarding how risky the bsp changes might be in terms of stability +11:52 < horms> an unfortunate side effect of this situation is that +11:52 < wsa_> if we would be able to fix it upstream by largely modifying the serial driver only, my hope would be that we could then convince the BSP team to switch over? +11:52 < geertu> the SCIF DNA code is still so complex that there are no obvious deficiencies (I prefer: so simple that there are obviously no deficiencies) +11:52 < horms> its not entirely obvious when a fix for mainline or the BSP is applicable to the other +11:53 < wsa_> horms: true +11:53 < wsa_> there might be side effects +11:53 < geertu> The BSP has several fixes for race conditions, but I don't think they fix the root cause. +11:54 < horms> that would not surprise me +11:54 < geertu> (The same is true for my last RFC series, though) +11:54 < wsa_> but if those side effects come from bugs, then fixing them obviously will change behaviour of the driver +11:54 < horms> they could be positive behavoural changes :^) +11:55 < wsa_> so far, geert's series is completely self contained to the scif driver +11:55 < geertu> Most changes don't look like real behavior changes. Just fixes for rcae conditions. +11:56 < geertu> wsa_: yes +11:56 < shimoda> by the way, I tested geert-san's scif-dma-v2 patch set last week +11:56 < shimoda> and I sent some patches to the ML :) +11:56 < geertu> Thanks for testing, and for the patches. +11:57 < geertu> Which SCI variant(s) did you test? +11:57 < shimoda> i tested on Lager (SCIFA) and koelsch (SCIF) +11:58 < geertu> Good, thanks! +11:58 < horms> ok, i guess we could look at providing some fixes to the bsp team +11:58 < wsa_> my feeling is that it would be worthwhile fixing the remaining issues until we understand what was going wrong and then "sell" our fixes to the BSP team +11:58 < horms> if so i'd like some co-ordination between your changes (and mainine in general) and what is in BSP 1.9.5 +11:58 < geertu> I think it's too early for that +11:59 < horms> i guess you and i could co-ordinate that when the timing is right +11:59 < geertu> Yes, I want to fix the remaining issues first +11:59 < horms> ok, no problem regarding waiting +11:59 < geertu> Ater that I can created a "nicer" series. +11:59 < horms> could you take a look at the new bsp (i pushed it on Saturday) on the off chance any of the scif patches there are of use to you +11:59 < geertu> The current one has too many fixes here, fixes there, ... some of them may not be needed inthe end +11:59 < wsa_> that would hopefully also reduce the gap between BSP & mainline +12:00 < horms> i think you only need to look back as far as v1.9.4 as kaneko-san has already fed the older ones to the ml +12:00 < geertu> I already had a quick look, and none of them looked that exciting +12:00 < horms> thanks +12:00 < horms> that was my expectation +12:00 < horms> I will tell Kaneko-san not to bother posting them to the ml +12:02 < wsa_> ok +12:02 < wsa_> so, geert will push out a nicer series +12:02 < geertu> horms: Thanks, sometimes I'm afraid Greg would apply them ;-) +12:02 < horms> haha +12:02 < wsa_> that can happen +12:02 < wsa_> :) +12:03 < horms> as a precaution i already told him not to post them unless he hears otherwise from me :^) +12:03 < wsa_> and hopefully after the new series, we know a bit more how to deal with the issues +12:04 < horms> sounds reasonable to me +12:04 < wsa_> and then we can have a look what would be best for BSP +12:04 < horms> yes, that can come last +12:04 < horms> imho +12:05 < geertu> I hope scif work will become a bit easier now it's at least working a bit +12:05 < horms> hopefully... +12:05 < geertu> Before it was really frustrating, as any small failure somewhere would lead to one out of many possible crashes due to race conditions +12:05 < horms> ouch +12:05 < geertu> On every retry, I had a different crash ;-) +12:06 < wsa_> yes, working on old serial drivers always deserves a "braveness medal" +12:06 < geertu> I'm wondering how SCIF DMA ever worked. I guess SMP=n helped a lot... +12:07 < wsa_> ok, so much about scif? +12:07 < geertu> Does SCIF DMA work on e.g. Ecovec? +12:07 < horms> i may have one if you really want to find out +12:08 < shimoda> geert-san: I don't know +12:08 < geertu> we never wired up scif dma on e.g. armadillo and kzm9g legacy +12:09 < geertu> wsa_ scif EOF +12:09 < wsa_> :) +12:10 < wsa_> so 3) task list +12:10 < wsa_> I sent it around by mail +12:10 < wsa_> I guess you would have replied if you really missed an item there +12:10 < geertu> Sorry, one more SCIF DMA thing +12:10 < wsa_> ok +12:11 < geertu> The people from Visteon contacted me, as they're interested in it for their product. +12:11 < geertu> For a 4 Mbps link to Bluetooth on SCIFA +12:12 < geertu> Just wanted to let you know... +12:12 < wsa_> set them up for testing ;) +12:13 < wsa_> ok, other comments regarding the io group todo list? +12:13 < geertu> the list looks fine to me +12:14 < morimoto> Sorry, is this "todo list" this ? https://osdr.renesas.com/projects/linux-kernel-development/wiki/Io-todo-list +12:14 < wsa_> yes +12:16 < wsa_> so, when looking for further tasks to keep an eye on, I tried to scan through the BSP +12:16 < wsa_> I concentrated on I2C and MMC for starters +12:17 < wsa_> Conclusion: most patches would already need some investigation to simply understand the problem :) +12:18 < wsa_> and in most cases it is very difficult because there is not enough information to reproduce the issue +12:18 < wsa_> so while "scanning the BSP" sounds good in general +12:18 < wsa_> I am afraid we won't have the bandwidth to do it in general +12:19 < horms> i can get the BSP scanned if you like +12:19 < horms> but my feeling is that its already been scanned up until v1.9.4 (and v1.9.5 but not posted yet) +12:21 < horms> of course you are also welcome to look over it as much as you like +12:22 < wsa_> who scans it? +12:22 < wsa_> kaneko-san? +12:22 < horms> Kaneko-san and I +12:22 < wsa_> ok +12:23 < horms> To be honest I think we got all the fat last year +12:23 < wsa_> I wondered about some MMC related patches +12:24 < wsa_> but my suggestion was anyhow: we bring it to this table here +12:24 < horms> anything in particular +12:24 < horms> i recall some relating to timeouts +12:24 < horms> ok +12:25 < wsa_> if there is something easy, we just pick it +12:25 < horms> as i mentioned earlier the BSP is sort of frozen now +12:25 < wsa_> if there is something "interesting", we can discuss it here or by mail +12:25 < horms> so the reate of patches being added has dropped of significantly since... i guess the begninnging of the year +12:25 < wsa_> ok +12:25 < horms> so there isn't such a large crop of changes to pick from +12:25 < wsa_> "bugfix only" mode? +12:26 < horms> something like that +12:26 < horms> i'm not sure of their exact criteria +12:26 < horms> but its mostly if not exclusively bug fixes from my observations +12:27 < horms> there are a few changes waiting feedback from the BSP team +12:27 < horms> i can try chasing them up +12:27 < horms> which may yeild a few more fixes for mainline +12:27 < wsa_> do you know if there will be another "major version" somewhen or is that "the" BSP foreverß +12:27 < wsa_> ? +12:27 < horms> of course for gen3, yes +12:28 < horms> and probably that will support gen2 in some way (perhaps not officually, but it should boot the boards) +12:28 < wsa_> i understand +12:28 < horms> but for gen2 bsp, i believe the plan is no more major updates +12:28 < horms> actually, i think the plan was no more updates at all: but then some bugs turned up... +12:29 < wsa_> damn software ;) +12:29 < horms> yeah, its like that sometimes +12:31 < wsa_> okay, I think we are done with the planned topics +12:31 < wsa_> anything else which needs to be said now? +12:31 < horms> right on time! +12:32 < shimoda> I have no topic at the moment :) +12:33 < wsa_> cool +12:33 < wsa_> so, next meeting probably the week after my holiday +12:33 < wsa_> I will send out a mail +12:33 < horms> enjoy your break +12:34 < wsa_> oh, i will +12:34 < wsa_> but until then, there is another week of work left +12:34 < wsa_> ;) +12:34 < wsa_> thank you guys! +12:34 < morimoto> BTW, Renesas will have summer vacation 10th - 14th Aug +12:34 < shimoda> thank you! +12:34 < wsa_> have a great day/evening! +12:34 < wsa_> morimoto: thanks, noted +12:35 < morimoto> Please let me know if you need something. this week is good for me +12:35 < geertu> Bye! +12:35 < horms> BTW, I will have vacation 10th, 11th (but i can release topic branches as required) +12:35 < shimoda> byebye! +12:35 < morimoto> horms: ok +12:36 < morimoto> bye ! thank you +12:36 -!- morimoto [~user@relprex3.renesas.com] has left #periperi ["ERC Version 5.3 (IRC client for Emacs)"] +12:36 -!- shimoda [~shimoda@relprex1.renesas.com] has quit Quit: WeeChat 0.4.2 +12:36 < horms> geertu: will you be sending v4 a little later? +12:37 < horms> if not i won't poll for it :) +12:37 < geertu> horms: yes, I was a bit delayed by the Internet link breakdown +12:37 < horms> understandable +12:38 * geertu has released renesas-drivers-2015-08-04-v4.2-rc5 +12:38 < horms> anyway no particular rush here +12:38 < horms> i'll check my email a bit later +12:38 < geertu> will do v4 after lunch +12:38 < horms> good plan +12:38 < horms> i'll disappear for a bit +12:42 < wsa_> me too +--- Log closed Tue Aug 04 12:42:40 2015 diff --git a/wiki/Chat_log/20150805-core-chatlog b/wiki/Chat_log/20150805-core-chatlog new file mode 100644 index 0000000..7a06f48 --- /dev/null +++ b/wiki/Chat_log/20150805-core-chatlog @@ -0,0 +1,562 @@ +11:00 #periperi: < geertu> Agenda: 1. CPG/MSTP Domain 2. Consider enabling CMA as default in the shmobile_defconfig 3. Topic versioning +11:00 #periperi: < geertu> 4. Status check for tasks from last meeting - what is remaining? +11:01 #periperi: < geertu> 5. Upcoming Gen3 development for the Core group +11:01 #periperi: < geertu> 6. SoC Bus topology in DT +11:01 #periperi: < geertu> Topic 1. CPG/MSTP Domain +11:02 #periperi: < geertu> It seems this has been resolved by using the arm-soc deadline hammer? +11:02 #periperi: < horms> maybe! +11:02 #periperi: < dammsan> geertu: does this affect gen3? +11:03 #periperi: < geertu> Not yet, but I think gen3 should follow suit +11:03 #periperi: < horms> geertu: let me know if you want me to give the stauts of the patches queued up +11:03 #periperi: < dammsan> ok +11:04 #periperi: < geertu> horms: good idea. I don't think everyone follows your branches that closely. +11:05 #periperi: < horms> sure +11:05 #periperi: < horms> I have euqued up the base clk driver changes and the dtsi changes that go on top of them for v4.3 +11:05 #periperi: < horms> these are on top of the dt branch, as they change nodes added there +11:06 #periperi: < horms> wihch is not ideal because generally its not good to add stuff on the dt branch +11:06 #periperi: < horms> but we will see how it goes +11:06 #periperi: < geertu> Hence all new nodes with mstp clocks should have power-domains properties +11:06 #periperi: < horms> the next few patches touch sh-drivers and i have queued them up to send directly to linux +11:06 #periperi: < horms> the next few patches touch sh-drivers and i have queued them up to send directly to linus +11:07 #periperi: < horms> after the clk driver and abovementioned dt changes hit his tree +11:07 #periperi: < horms> that should be around v4.2-rc2 +11:07 #periperi: < horms> and so all the above shold make it into v4.3 (or be rejected!) +11:07 #periperi: < horms> then there are a few trailing cleanup patches which i have queued up for v4.4. +11:08 #periperi: < horms> Basically the patches for v4.3 should be in the next branch and the ones for v4.4 should be in the devel branch +11:08 #periperi: < horms> though thinking about it I might have only added the sh-driver patches to devel, i'll check that later +11:08 #periperi: < horms> --- end --- +11:09 #periperi: < geertu> No, everything seems to be in renesas-devel-20150805-v4.2-rc5 +11:10 #periperi: < geertu> git cherry -v base renesas-devel-20150805-v4.2-rc5 linus/master +11:10 #periperi: < horms> ok, but some should also be in renesas-next-20150805-v4.2-rc1 +11:10 #periperi: < geertu> (with base being my base, i.e. renesas-drivers) +11:10 #periperi: < horms> i wasn't as clear as i might have been +11:10 #periperi: < horms> everything should be in renesas-devel +11:11 #periperi: < horms> and the bits for v4.3 should also be in renesas-next +11:11 #periperi: < geertu> (this show all new commits in renesas-devel-20150805-v4.2-rc5 since base, ignoring things already in upstream = linus/master) +11:12 #periperi: < horms> i checked, the sh-driver bits are in renesas-next-20150805-v4.2-rc1 +11:12 #periperi: < horms> I plan to send my pull requests on Friday +11:12 #periperi: < geertu> yes, everything looks fine. thx +11:13 #periperi: < horms> we can then see what Olof has to say +11:13 #periperi: < geertu> BTW, as Linus said something about needing an extra -rc, arm-soc may relax, too +11:13 #periperi: < horms> ok +11:13 #periperi: < horms> i think they usually allow a respin +11:13 #periperi: < horms> but we'll see +11:14 #periperi: < horms> but good to know there will be an extra rc +11:14 #periperi: < horms> should i be expecing any more work in this area in the near term (e.g. for v4.4) ? +11:15 #periperi: < geertu> Not for CPG/MSTP clock domain (except for H3) +11:15 #periperi: < horms> ok, great +11:15 #periperi: < geertu> Next PM Domain will be R-Car SYSC +11:15 #periperi: < geertu> and we'll see what Lina is doing with CPU PM Domains +11:16 #periperi: < geertu> BTW, did anyone test this on Gen1 or RZ? +11:16 #periperi: < horms> i tested that the boards still boot to a userspace prompt +11:16 #periperi: < geertu> OK, thx +11:16 #periperi: < horms> i can do more detailed testing if needed +11:17 #periperi: < geertu> Should be Good Enough (TM) +11:17 #periperi: < dammsan> geertu: did not do any testing myself, but can give you remote access to marzen +11:18 -!- Irssi: Starting query in freenode with dammsan +11:18 <geertu> That could be useful for L2 DT cache +11:18 #periperi: < horms> excellent +11:18 #periperi: < geertu> Next topic? +11:18 #periperi: < horms> fine by me +11:18 #periperi: < geertu> Topic 2. Consider enabling CMA as default in the shmobile_defconfig +11:19 #periperi: < horms> What is the motivation for this? +11:19 #periperi: < geertu> dammsan? IOMMU with highmem? +11:20 #periperi: < dammsan> right, CMA +11:20 #periperi: < dammsan> the motivation is to do the first step to get turnkey support for HDMI +11:20 #periperi: < dammsan> in the defconfig +11:20 #periperi: < horms> sounds like a good reason +11:21 #periperi: < dammsan> today there are various bits missing, including DU and HDMI specific bits +11:21 #periperi: < geertu> What does CMA have to do with HDMI? +11:21 #periperi: < horms> what are the complicatinos? +11:21 #periperi: < dammsan> but to support large HD resultion frames +11:21 #periperi: < geertu> ok +11:21 #periperi: < horms> i.e. what fall out might we see? +11:21 #periperi: < dammsan> the non-CMA allocator does not provide enough +11:21 #periperi: < dammsan> memory +11:21 #periperi: < dammsan> oh anything is possible +11:21 #periperi: < horms> ok +11:21 #periperi: < horms> so how about we queue it up for v4.4 now, in devel +11:21 #periperi: < dammsan> the entire internal DMA API memory allocator path is changed +11:21 #periperi: < horms> so it can get lots of exposure +11:22 #periperi: < dammsan> good plan +11:22 #periperi: < horms> seeing as everyone uses that defconfig :^) +11:22 #periperi: < dammsan> we can mitigate the risk by comparing with say some common ARM v7 defconfig and see what they use +11:22 #periperi: < dammsan> I think using CMA makes sense either way +11:22 #periperi: * geertu almost never uses shmobile_defconfig for booting +11:22 #periperi: < horms> geertu: I was being facetious +11:22 #periperi: < dammsan> but enabling it in a controlled manner makes sense +11:23 #periperi: < geertu> multi_v7_defconfig already has CONFIG_CMA=y +11:23 #periperi: < dammsan> ok great +11:23 #periperi: < dammsan> can we add a task for this? +11:23 #periperi: < horms> do you use that config often? +11:24 #periperi: < geertu> horms: not really, it's broken a lot +11:24 #periperi: < horms> ok +11:24 #periperi: < geertu> horms: and fails to boot on anything but Gen2 due to (assumed) kernel image size limits in various boot loaders +11:24 #periperi: < horms> awesome +11:25 #periperi: < dammsan> geertu: we should really fix the size limitations +11:25 #periperi: < geertu> dammsan: task for enabling CONFIG_CMA=y and verifying that it doesn't break anything? +11:25 #periperi: < dammsan> i guess one by one +11:25 #periperi: < dammsan> geertu: i think simply enabling it is fine +11:25 #periperi: < dammsan> we will notice if something goes wrong +11:25 #periperi: < geertu> horms: multi_v7 is also incomaptible with kzm9g for anothe reason (have to dig it up) +11:26 #periperi: < dammsan> geertu: isn't that fixed by your removal of the reserved memory space? +11:26 #periperi: < horms> geertu: kevin hilman probaly knows +11:26 #periperi: < dammsan> horms: kevin has kzm9d not g +11:26 #periperi: < horms> oops +11:26 #periperi: < horms> i fall for that one every time +11:26 #periperi: < dammsan> but close enough =) +11:27 #periperi: < geertu> Yeah, "D" stands for "dual", but the "G" is dual-core too ;-) +11:27 #periperi: < geertu> "G" stands for? +11:27 #periperi: < horms> GT +11:27 #periperi: < geertu> Gran Turismo +11:27 #periperi: < dammsan> Maybe related to "genesis" code name +11:28 #periperi: < geertu> Ah, I love git history ;-) +11:28 #periperi: < geertu> - sh73a0/kzm9g: +11:28 #periperi: < geertu> - zImage+DTB from U-Boot needs CONFIG_ARM_ATAG_DTB_COMPAT=n, +11:28 #periperi: < dammsan> used for ARM based SoCs targeting mobile devices +11:28 #periperi: < geertu> multi_v7 has CONFIG_ARM_ATAG_DTB_COMPAT=y +11:29 #periperi: < dammsan> i see, they assume that the boot loader will pass something that makes sense +11:29 #periperi: < geertu> Task "shmobile_defconfig,v4.4,Enable CONFIG_CMA=y" added +11:29 #periperi: < dammsan> must be different corporate culture +11:29 #periperi: < dammsan> geertu: thanks! +11:29 #periperi: < geertu> Next topic? +11:29 #periperi: < horms> yes! +11:30 #periperi: * geertu likes the perfect timing +11:30 #periperi: < geertu> Topic 3. Topic versioning +11:30 #periperi: < geertu> Simon uses topic/... +11:30 #periperi: < geertu> E.g. topic/arm64-rcar-gen3-v3 +11:31 #periperi: < horms> the reason being to make it different from branches targeted at mainline +11:31 #periperi: < geertu> I had used before (in renesas-drivers-2015-07-14-v4.2-rc2) arm64-rcar-gen3-v2 +11:31 #periperi: < horms> though it could be different in other ways +11:31 #periperi: < geertu> But adding the topic indeed makes sense +11:32 #periperi: < geertu> For branches merged through git I depend on the creator of the branch +11:32 #periperi: < geertu> E.g. drm/du/vsp1-kms didn't have any versioning information (and changed) +11:32 #periperi: < geertu> In the mean time it has changed again... +11:32 #periperi: < dammsan> (multiple times, and seems to keep on changing) +11:33 #periperi: < geertu> Now, we do have versioning due to the exact version being available in renesas-drivers-2015-08-04-v4.2-rc5 git history +11:33 #periperi: < dammsan> accorting to laurent he will start versioning when it is stable +11:33 #periperi: < geertu> So personally I don't mind much (for now) +11:33 #periperi: < dammsan> s/stable/working/g +11:34 #periperi: < dammsan> geertu: did you notice the build error? +11:34 #periperi: < geertu> No +11:34 #periperi: < horms> from my pov if we have a version on the merge branch +11:35 #periperi: < horms> then we have enough to work with +11:35 #periperi: < dammsan> geertu: the shmobile_defconfig does not build, but we can chat about that later +11:35 #periperi: < geertu> So the broken code was not enabled in my own configs, nor in shmobile_defconfig, nor in multi_v7_defconfig? +11:35 #periperi: < geertu> zero-day build also didn't complain +11:37 #periperi: < horms> other than adding errors is there a way to find out what is being checked by zero-day? +11:37 #periperi: < geertu> Yes +11:37 #periperi: < dammsan> geertu: i'm using shmobile_defconfig without any modifications +11:37 #periperi: < geertu> You can ask Fengguang for receiving reports when he has build your repo +11:38 #periperi: < horms> thanks +11:38 #periperi: < dammsan> geertu: i get "drivers/media/platform/vsp1/vsp1_drv.c:26:22: fatal error: vsp1_drm.h: No such f +11:38 #periperi: < dammsan> ile or directory +11:38 #periperi: < geertu> Quoting Fengguang on ksummit-discuss +11:38 -!- Irssi: Pasting 6 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +11:38 #periperi: < geertu> Just send me an email and say something like +11:38 #periperi: < geertu> I'd like to get build completion notification for git URLs +11:38 #periperi: < geertu> git://neil.brown.name/md +11:38 #periperi: < geertu> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git +11:39 #periperi: < dammsan> sorry for going into offtopic and with compile errors +11:39 #periperi: < dammsan> lets deal with those later +11:39 #periperi: < geertu> (Interesting) +11:39 #periperi: < geertu> Full list of 0-day is at https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/repo/linux +11:42 #periperi: < geertu> Oops, I do have the same build error, but missed it. Oops +11:42 #periperi: < geertu> Which brings me to another issue: +11:42 #periperi: < geertu> renesas-drivers is no longer suitable for upstream development, as it contains code that is not ready for submission yet +11:42 #periperi: < geertu> I.e. you can no longer base your work for submission on that +11:43 #periperi: < shimoda> now i fetched laurent-san repo, it has vsp1_drm.h +11:43 #periperi: < dammsan> geertu: this is why i sort of wanted you to have two separate releases =) +11:43 #periperi: < geertu> Yeah, I'll have to keep the "unstable" stuff on a separate branch +11:43 #periperi: < geertu> It does mean it will receive less testing +11:44 #periperi: < horms> fwiw, its also why i left the topic branch out of devel +11:44 #periperi: < geertu> yeah yeah, I know ;-) +11:44 #periperi: < geertu> So now we have a collection of rotten patches no one dares to use ;-) +11:44 #periperi: < dammsan> geertu: how difficult is it to make a new release? +11:45 #periperi: < dammsan> according to laurent he fixed the build error +11:45 #periperi: < geertu> If nothing new was broken, less than one hour +11:46 #periperi: < dammsan> geertu: can you add a simple test with shmobile_defconfig build? +11:46 #periperi: < geertu> Shall I make a new renesas-drivers + separate "snapshot1b" for today? +11:46 #periperi: < geertu> I was supposed to build shmobile_defconfig +11:47 #periperi: < dammsan> i would simply make a new snapshot release without any special suffix +11:47 #periperi: < geertu> But too many windows, and I though it was multi_v7_defconfig (which had a known issue) i.s.o. shmobile_defconfig that failed +11:48 #periperi: < dammsan> if you dont mind then including unstable code for a little while seems our only choice +11:48 #periperi: < dammsan> changing our process may confuse the internal customer +11:48 #periperi: < geertu> Sure, but submitters have to learn how to rebase from "snapshotX" --onto renesas-drivers-Y +11:49 #periperi: < dammsan> from my side, if we find some issue then unless it is too much trouble then doing a new release makes sense +11:49 #periperi: < geertu> agreed +11:49 #periperi: < dammsan> geertu: if your condern is to create a stable base for upstream development +11:49 #periperi: < dammsan> and now when renesas-drivers is not +11:50 #periperi: < dammsan> then i think the correct approach for people is to do initial development on a recent renesas-drivers release +11:50 #periperi: < geertu> renesas-drivers is not 100% stable, as it is rebased +11:50 #periperi: < dammsan> and then move to the subsystem -next tree for the final adjustment +11:50 #periperi: < dammsan> sure +11:50 #periperi: < geertu> the subsystem -next tree should already be included in rensas-drivers +11:51 #periperi: < dammsan> i'm trying to get internal teams to rebase on a weekly basis +11:51 #periperi: < dammsan> yeah +11:51 #periperi: < geertu> It's e.g. i2c hacks in dtsi. I couldn't base the cpg/mstp clock domain patches on that +11:51 #periperi: < dammsan> when you say "base" do you mean for upstream submission? +11:52 #periperi: < geertu> yes +11:52 #periperi: < dammsan> fsure, so you should use the subsystem tree for that +11:52 #periperi: < dammsan> but for integration i think renesas-drivers makes sense +11:52 #periperi: < dammsan> ideally any hacks should be excluded +11:52 #periperi: < dammsan> in my opinion +11:53 #periperi: < geertu> So I will create a new renesas-drivers-2015-08-05-v4.2-rc5 today +11:54 #periperi: < geertu> and a separate renesas-snapshot-1 containing the topic/* stuff? +11:56 #periperi: < dammsan> i think creating a new renesas-drivers release makes sense - but including laruents stuff +11:56 #periperi: < dammsan> and i think we should also ask him to separate his hacks from the more stable bits +11:56 #periperi: < geertu> Hence one release +11:57 #periperi: < dammsan> and the hack portion has to be dealt with somehow +11:57 #periperi: < dammsan> but your proposal sounds quite fine too +11:57 #periperi: < dammsan> with the two releases +11:58 #periperi: < dammsan> i guess it boils down to what the purpose of renesas-drivers is +11:58 #periperi: < geertu> Usually it doesn't matter if there's one realease +11:58 #periperi: < dammsan> right exactly +11:58 #periperi: < dammsan> one release is simple and good +11:58 #periperi: < geertu> as long as people are not stepping on each other's toes +11:59 #periperi: < dammsan> so how about doing one more of them now +11:59 #periperi: < geertu> but I always seem to attract the work that e.g. touches all device nodes in dt ;-) +11:59 #periperi: < dammsan> and we need to discuss with laurent how to handle his hacks +11:59 #periperi: < dammsan> geertu: yes =) +11:59 #periperi: < pinchartl> what hacks ? :-) +11:59 #periperi: < geertu> .. and the work that involves lockstepping dt and c code +12:00 #periperi: < pinchartl> (sorry, I've missed the beginning of the conversation) +12:00 #periperi: < geertu> #ifdefs in dtsi +12:00 #periperi: < dammsan> pinchartl: please split upstream-targetting code from local DT changes and other short term hacks +12:01 #periperi: < pinchartl> are you referring to any local DT change in particular ? +12:01 #periperi: < dammsan> this is probably the same reason why ARM-SoC guys asks for several split out branches +12:02 #periperi: < dammsan> pinchartl: we need to simplify integration somehow i think, but i have no detail. maybe geert has +12:02 #periperi: < dammsan> geertu: can you describe hte issue? +12:03 #periperi: < geertu> pinchartl: as renesas-drivers now contains code that is not ready for submission yet +12:04 #periperi: < geertu> you can no longer use it for upstream development and for preparing patches for upstream submission +12:04 #periperi: < pinchartl> right +12:04 #periperi: < geertu> however, as long as people are not stepping on each other's toes, it's still fine +12:05 #periperi: < dammsan> geertu: so we shall keep out the koelsch-specific I2C prototype patch for HDMI enablement? +12:06 #periperi: < dammsan> if we want to be able to develop DTS changes for Koelsch I2C portion? +12:06 #periperi: < geertu> dammsan: You will teach the gen3 developers how to rebase ("git rebase --onto renesas-drivers-$new renesas-drivers-$old master")? +12:06 #periperi: < horms> geertu: that is the general idea +12:06 #periperi: < dammsan> geertu: yes, that's the idea +12:07 #periperi: < geertu> For now, let's keep the hack in +12:07 #periperi: < geertu> I'll try to stop touching all device nodes for a while :-) +12:07 #periperi: < dammsan> pinchart: would it be possible for you to adjust to keep more unstable stuff in a separate topic branch later? +12:08 #periperi: < dammsan> perhaps this is only an issue during early development phase too +12:08 #periperi: < geertu> We're running out of time +12:09 #periperi: < dammsan> so can we break out the topic branch discussion to later? +12:09 #periperi: < dammsan> and move on? +12:09 #periperi: < dammsan> when are we supposed to end again? +12:09 #periperi: < horms> 21 min +12:10 #periperi: < horms> in 21 min, iirc +12:10 #periperi: < geertu> 3 more topics +12:10 #periperi: < geertu> 21 / 3 = 7 +12:10 #periperi: < geertu> Topic 4. Status check for tasks from last meeting - what is remaining? +12:10 #periperi: < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list +12:10 #periperi: < pinchartl> dammsan: I keep the I2C hack in a separate branch, I've only merged it into the vsp-du-kms branch because it's a prototype +12:10 #periperi: < geertu> magnus: You received coffee? +12:10 #periperi: < dammsan> pinchartl: gotcha +12:10 #periperi: < dammsan> yes, thanks a lot! +12:11 #periperi: < dammsan> and i did fix up r8a7779 and Marzen, not sure if all is done yet due to merge order issues +12:11 #periperi: < geertu> pinchartl: when will you kick it out, so I can create another release? +12:11 #periperi: < horms> geertu: i did some analysis of marzen, then dammsan removed it. so that seems to be case-closed +12:11 #periperi: < horms> geertu: i belive the bockw situation has moved forwards but needs more work. ulrich is handling that i believe +12:11 #periperi: < geertu> BTW, what do we do with closed tasks? Just remove? +12:11 #periperi: < dammsan> is ulrich around? +12:12 #periperi: < uli___> i think an ack on the SD pull-up stuff by laurent and/or geert would help to move this forward +12:12 #periperi: < dammsan> geertu: i think removing them is fine +12:12 #periperi: < geertu> IPMMU+DMAC prototype was done, using identity mapping? +12:12 #periperi: < dammsan> uli___: what is blocking your progress on consolidating DTS files? +12:12 #periperi: < dammsan> geertu: yes, i believe so +12:13 #periperi: < pinchartl> geertu: end of the day^H^H^Hnight today :-) +12:13 #periperi: < uli___> the sd stuff; if it's not in, functionality is lost until it is. not sure how much of a problem that is... +12:13 #periperi: < dammsan> i say no problem +12:13 #periperi: < uli___> well then... +12:14 #periperi: < geertu> Identify missing support is done for both '78 and '79, right? +12:14 #periperi: < dammsan> we can have a vote: all people with bock-w hardware in front of them gets to vote: +12:14 #periperi: < dammsan> i vote no +12:14 #periperi: < uli___> vote on what? +12:14 #periperi: < dammsan> if we need to keep it stable =) +12:14 #periperi: < geertu> r8a7778 r8a7779,v4.2,Vote which missing support is valuable +12:14 #periperi: < horms> i vote that we don't make bockw unstable +12:14 #periperi: < dammsan> geertu: right, i think it would make sense to fix up the USB bits +12:15 #periperi: < horms> and that we move forwards with removing legacy asap +12:15 #periperi: < horms> both would make my life beter immediately +12:15 #periperi: < dammsan> horms: why dont you and ulrich make it happen? +12:15 #periperi: < uli___> horms: aren't those conflicting? +12:16 #periperi: < horms> perhaps not +12:16 #periperi: < geertu> Is anything valuable still missing on r8a779/marzen? +12:16 #periperi: < dammsan> USB +12:17 #periperi: < dammsan> (but without access to real hardware development is difficult) +12:17 #periperi: < geertu> USB on bockw or marzen? +12:17 #periperi: < dammsan> I only care about Marzen +12:17 #periperi: < dammsan> I think the creators of Bock-W has to care about them +12:17 #periperi: < horms> uli___: right now bockw-multiplatform seems to work, for some limited feature set. I'd like it to stay working even if that means it gets features slower (or never) +12:17 #periperi: < dammsan> if they don't then we can slowly phase them out +12:18 #periperi: < uli___> horms: that should be possible +12:18 #periperi: < horms> dammsan: I'd like to avoid silos in gen-1 land +12:19 #periperi: < dammsan> silos? +12:19 #periperi: < horms> i mean, i think we should work togeher on both boards because surely they must have a lot of commonality +12:19 #periperi: < geertu> Milan, Geuze, and Silverstone? +12:20 #periperi: < dammsan> horms: no, gen1 has little common sense +12:20 #periperi: < horms> i do agree that we should remove boards that it is no long appropriate for us to support +12:20 #periperi: < dammsan> i mean commonality +12:20 #periperi: < geertu> Blanche, Stout? +12:20 #periperi: < horms> ok +12:20 #periperi: < dammsan> horms: it is not difficult to support, someone just has to do it +12:20 #periperi: < dammsan> horms: so please work with ulrich and make sure it moves forward +12:20 #periperi: < horms> ok +12:21 #periperi: < geertu> So we can drop bockw-{legacy,reference}? +12:21 #periperi: < dammsan> if i can fix up marzen on my spare time then the two of you must be able to move if forward too +12:21 #periperi: < geertu> next topic? +12:21 #periperi: < dammsan> geertu: i think keeping the reference +12:21 #periperi: < uli___> why that? +12:21 #periperi: < dammsan> but same state as current marzen - ie DT-only board support +12:22 #periperi: < dammsan> i don't want to whine, but i fail to see what the real problem is? +12:22 #periperi: < geertu> all bockw-reference has is the fpga +12:22 #periperi: < geertu> pinctrl" +12:22 #periperi: < uli___> throwing out the c code makes reference pretty much equivalent with MP +12:22 #periperi: < dammsan> and that is blocking merging of DT files? +12:22 #periperi: < geertu> Topic 5. Upcoming Gen3 development for the Core group +12:23 #periperi: < dammsan> geertu: right +12:23 #periperi: < geertu> (I think we can live with a fake pinctrl abstraction in dt) +12:23 #periperi: < dammsan> does shimoda-san or morimoto-san have anything to share with us? +12:23 #periperi: < geertu> Are they here? ;-) +12:24 #periperi: < dammsan> geertu: we can also drop some features and re-develop later if needed +12:24 #periperi: < horms> at least shimoda-san was here +12:24 #periperi: < dammsan> shimoda: hellou? +12:25 #periperi: < shimoda> sorry +12:25 #periperi: < morimoto> hi +12:26 #periperi: < morimoto> sorry, I'm working for Gen3 right now +12:26 #periperi: < dammsan> hi guys, can you please let us know a bit more about the Core poriton about gen3 development this month? +12:26 #periperi: < morimoto> I'm creating bootable kernel patch set +12:26 #periperi: < morimoto> but, today, BSP team used Geert's latest release for it +12:26 #periperi: < morimoto> and it doesn't work on H3 +12:27 #periperi: < morimoto> (it works previous release) +12:27 #periperi: < dammsan> morimoto: it seems that it does not compile, and it is not ready for gen2 either +12:27 #periperi: < dammsan> morimoto: so internal guys should wait a bit it seems +12:27 #periperi: < morimoto> OK +12:28 #periperi: < morimoto> I don't know detail (because I don't have board) +12:28 #periperi: < dammsan> so, we need to explain about the gen3 development plan +12:28 #periperi: < geertu> arm64_defconfig definitely compiles +12:28 #periperi: < morimoto> but, it seems they could compile +12:28 #periperi: < shimoda> until 11th, we need IRQC. +12:28 #periperi: < dammsan> this plan assumed we had hardware access +12:28 #periperi: < shimoda> until 18th, we need PFC and GPIO +12:29 #periperi: < dammsan> ok, so we need 3 new tasks it seems +12:29 #periperi: < dammsan> 1. IRQC +12:29 #periperi: < geertu> IRQC (INTC-EX): Looks identical to Gen2 +12:29 #periperi: < dammsan> 2.GPIO +12:29 #periperi: < dammsan> 3. PFC +12:29 #periperi: < geertu> GPIO: Looks identical to Gen2 +12:29 #periperi: < geertu> PFC: New driver support (at least the pin/groups/function tables) +12:29 #periperi: < dammsan> geertu: sure, needs DT compat string changes nevertheless +12:29 #periperi: < geertu> (quoting from email "Gen3 work") +12:29 #periperi: < geertu> dammsan: of course +12:30 #periperi: < dammsan> so ulrich posted PFC earlier? +12:31 #periperi: < geertu> no, gpio +12:31 #periperi: < uli___> gpio has been picked up +12:31 #periperi: < geertu> Tasks "gpio,v4.2,Add r8a7795 support" not added +12:32 #periperi: < geertu> Task "irqc,v4.2,Add r8a7795 support" added +12:32 #periperi: < dammsan> ok, thanks for the clarification =) +12:32 #periperi: < geertu> Task "pfc,v4.2,Add r8a7795 support" added +12:32 #periperi: < dammsan> thanks! +12:32 #periperi: < geertu> (v4.2 is due to the internal target date) +12:33 #periperi: < dammsan> geertu: i don't understand the internal target i'm afraid +12:33 #periperi: < dammsan> i thought we tracked when we thought it would be merged upstream +12:33 #periperi: < geertu> "11th" and "18th"? +12:33 #periperi: < geertu> v4.4 +12:33 #periperi: < geertu> updated +12:33 #periperi: < dammsan> thanks +12:34 #periperi: < geertu> I think "Topic 6. SoC Bus topology in DT" is related? +12:34 #periperi: < dammsan> those dates are the upcoming snapshot dates +12:34 #periperi: < geertu> and can be handled together in the last -4 minutes? +12:34 #periperi: < dammsan> i think so, but will take forever i think? +12:34 #periperi: < dammsan> geertu and horms: i asked morimoto-san to fix up some CPG related bits in the Gen3 series and resent V4 +12:35 #periperi: < dammsan> this without dealing with the topology +12:35 #periperi: < horms> so there will be a v5 soon? +12:35 #periperi: < pinchartl> speaking of bus topology, I haven't seen a block diagram that shows the bus topology in the Gen3 datasheet. have I just missed it ? +12:35 #periperi: < dammsan> i doubt we can reach some concensus soon on the topology +12:36 #periperi: < dammsan> if you can tie in the CCI, GIC and CPU clusters with the rest of the topology let me know +12:36 #periperi: < geertu> pinchartl: You need acid and an electron microscope +12:36 #periperi: < dammsan> especially with not so much documentation +12:36 #periperi: < dammsan> i think we need to deal with it bus-by-bus somehow +12:36 #periperi: < pinchartl> I have a bottle of vinegar and a couple of lemons in my fridge. will it do ? +12:36 #periperi: < pinchartl> I think we can start with just one bus, that should be enough +12:37 #periperi: < pinchartl> ideally it should be an AMBA bus +12:37 #periperi: < dammsan> but blocking the series on it seems a bit slow moving, no? +12:37 #periperi: < geertu> indeed +12:37 #periperi: < geertu> just continue +12:37 #periperi: < dammsan> is there any reason why we can't deal with that incrementally? +12:37 #periperi: < shimoda> pinchartl: section 5 AXI-bus is mentioned some diagram +12:38 #periperi: < dammsan> pinchartl: in the end it seems to boil down to trying to describe a non-tree topology as a tree +12:39 #periperi: < shimoda> oops, section 15, not 5 +12:39 #periperi: < pinchartl> some diagrams mention AXI4, others mention APB +12:39 #periperi: < pinchartl> I expect the real bus topology to be quite complex +12:39 #periperi: < dammsan> how about we fix Gen2 first? =) +12:39 #periperi: < pinchartl> and I don't think we really need to describe it fully in DT +12:39 #periperi: < dammsan> at least we have a some chance due to half-stable documentation +12:40 #periperi: < dammsan> as opposed to gen3 +12:40 #periperi: < pinchartl> I'd be fine with just a single bus +12:40 #periperi: < geertu> dammsan And make it not backwards-compatible with the bsp? +12:40 #periperi: < dammsan> geertu: do you mean on a source code level? +12:41 #periperi: < dammsan> geertu: the DT ABI is unaffected, no? +12:41 #periperi: < pinchartl> it would be great if it could be an "arm,amba-bus" but that will require changes to drivers I believe +12:41 #periperi: < dammsan> pinchartl: why don't we begin with a single bus for now then +12:41 #periperi: < pinchartl> dammsan: yes, a single bus is fine +12:41 #periperi: < dammsan> like today? +12:41 #periperi: < pinchartl> what bothered me was the nodes directly under the DT root node +12:42 #periperi: < dammsan> is that different compared to Gen2? +12:42 #periperi: < pinchartl> if we group them in a simple-bus that should be fine +12:42 #periperi: < pinchartl> gen2 has everything at the root +12:42 #periperi: < dammsan> morimoto: did you get that? +12:42 #periperi: < pinchartl> I'd like to avoid repeating that mistake +12:42 #periperi: < pinchartl> it should be very easy to fix +12:42 #periperi: < dammsan> what makes it difficult to move? +12:43 #periperi: < pinchartl> just create a node compatible with simple-bux +12:43 #periperi: < pinchartl> move all memory-mapped IPs there +12:43 #periperi: < pinchartl> and that's it +12:43 #periperi: < dammsan> sure +12:43 #periperi: < geertu> s/simple-bux/simple-bus/ +12:43 #periperi: < pinchartl> simple-bug :-) +12:43 #periperi: < dammsan> but that should be doable for gen2 as well without any odd side effects, no? +12:43 #periperi: < pinchartl> yes it should be doable +12:43 #periperi: < dammsan> you speak bruxells lingo =) +12:44 #periperi: < pinchartl> :-) +12:44 #periperi: < pinchartl> moving to an amba bus would be correct, bus also more complex +12:44 #periperi: < dammsan> sure, but we better be sure what we want at that point +12:44 #periperi: < pinchartl> so let's start with simple bus now +12:45 #periperi: < dammsan> geertu: can we add a task to add simple-bux for Gen3 =) +12:45 #periperi: < geertu> agreed +12:46 #periperi: < geertu> Added "r8a7795,v4.4,Group on-SoC devices under a simple-bus node on r8a7795" +12:46 #periperi: < dammsan> wondeful, thanks! +12:47 #periperi: < geertu> Finished? +12:47 #periperi: < geertu> I mean "any other things to discuss?" :-) +12:47 #periperi: < dammsan> i'm ok for overall stuff, but if people have time left then do we need to bang our head against the topic-branch somehow? +12:47 #periperi: < dammsan> what was the conclusion there again? +12:48 #periperi: < geertu> renesas-drivers will contain the "unstable" stuff, too. +12:48 #periperi: < geertu> But Laurent will remove the hacks for next week's release +12:49 #periperi: < dammsan> as for this week, what will happen? +12:49 #periperi: < geertu> I will create a new unified release using current drm/du/vsp1-kms +12:49 #periperi: < geertu> (after lunch) +12:49 #periperi: < pinchartl> if I remove the hacks (I2C hack and #include of the panel .dtsi), Renesas will need to add them for testing. are they aware of that ? +12:49 #periperi: < dammsan> i think we can manage on this side +12:50 #periperi: < dammsan> especially if you have a local topic branch with that stuff somewhere =) +12:50 #periperi: < dammsan> i mean not local, but separate +12:50 #periperi: < dammsan> we will manage regardless +12:50 #periperi: < dammsan> but it would be nice to see those things somewhere +12:51 #periperi: < dammsan> geertu: sounds good about the release after lunch! thank you! +12:52 #periperi: < dammsan> pinchartl: if you prefer not to publish the hacks separately then thats fine too +12:52 #periperi: < pinchartl> I can push two branches, that's fine +12:52 #periperi: < dammsan> thanks, that's great! +12:53 #periperi: < dammsan> can you drop me an mail once you've gone over to two-branch mode? +12:53 #periperi: < dammsan> i'll inform people +12:54 #periperi: < dammsan> also +12:54 #periperi: < horms> dammsan: can we come back to m1, either here or privately? I'd like to clarify some things. +12:54 #periperi: < dammsan> once we get real gen3 hardware working in the remote access i'll notify the periperi mailing list +12:55 #periperi: < dammsan> horms: sure! +12:55 #periperi: < dammsan> any time +12:55 #periperi: < horms> how about now? :) +12:55 #periperi: < dammsan> sure! =) +12:55 #periperi: < horms> great +12:55 #periperi: < geertu> I'm out for lunch. Bye! +12:55 #periperi: < horms> so i think we almost agreed to remove legacy +12:55 #periperi: < dammsan> geertu: thanks +12:55 #periperi: < dammsan> bon apetit +12:56 #periperi: < horms> but i'm unsure what you want to happen to reference in the short term +12:56 #periperi: < horms> geertu: enjoy +12:56 #periperi: < dammsan> ok i see +12:56 #periperi: < dammsan> i may misunderstand things +12:56 #periperi: < horms> from my pov it should go too +12:56 #periperi: < horms> i.e. be deleted +12:56 #periperi: < dammsan> but the only thing i see at this point is a lot of blocking and not so many patches +12:56 #periperi: < horms> right, that we need to change +12:57 #periperi: < dammsan> i mean, i can do it myself but then what is the point of all this? +12:58 #periperi: < horms> i think i have a clear picture now +12:58 #periperi: < horms> i'll work with uli___ to move things forwards +12:58 #periperi: < dammsan> so is it possible to move forward with the conversion? +12:58 #periperi: < dammsan> i mean, you guys saw my Bock-W patches +12:58 #periperi: < dammsan> i mean Marzen +12:58 #periperi: < dammsan> brain fart +12:58 #periperi: < uli___> since we have come to the conclusion that missing features are not that important, we can go ahead, i guess +12:59 #periperi: < horms> uli___: agreed +12:59 #periperi: < dammsan> auli___: sure that's one important thing +12:59 #periperi: < dammsan> but from my side it looks like you can move forward more without blocking too... +12:59 #periperi: < dammsan> why can't you merge the board DTS files for instance? +12:59 #periperi: < dammsan> is it lack of focus or time +13:00 #periperi: < dammsan> or a technical reason to block it? +13:00 #periperi: < uli___> no, it's just that there is nothing to merge. everything worth keeping is in the other file already. +13:00 #periperi: < uli___> the difference is only in c code +13:00 #periperi: < horms> ok, so we can remove one of the dt files? +13:00 #periperi: < dammsan> so why do we still have two files? +13:01 #periperi: < uli___> because reference needs it. +13:01 #periperi: < dammsan> this portion i don't understand. =) +13:01 #periperi: < dammsan> why can't a single file work? +13:01 #periperi: < dammsan> it did for all other platforms +13:01 #periperi: < dammsan> during transition +13:02 #periperi: < uli___> what for? let's just dump reference altogether. +13:02 #periperi: < dammsan> i realize you have that FPGA thing +13:02 #periperi: < dammsan> uli: but that's wha you are doing if you are merging the DTS files into a single one +13:03 #periperi: < uli___> well, there are a few other things that need to be touched up, but i didn't do this because i considered the missing features to be blockers +13:03 #periperi: < dammsan> everytime i look at the xxx-reference file in arch/arm/boot/dts i wonder why we still have two files for bock-w +13:03 #periperi: < dammsan> ok +13:03 #periperi: < dammsan> but i think we discussed this before, and i pointed out that you can move forward regardless +13:04 #periperi: < dammsan> but anyway +13:04 #periperi: < dammsan> so would it be possible for you to work with simon and finalize the Bock-W bits? +13:05 #periperi: < uli___> sure thing, i have all the patches here. only need to reorder them to "dump first, add features later" +13:05 #periperi: < horms> excellent +13:05 #periperi: < dammsan> uli___: but merging the DTS does not result in any dumping, does it? +13:05 #periperi: < horms> the begining of a merge cycle is an excellent time for remving code. and that means now because i've already started taking patches for v4.4 +13:06 #periperi: < dammsan> uli___: but i understand you mean removing legacy before having equivalent feature support in multiplatform, right? +13:06 #periperi: < uli___> legacy and reference +13:07 #periperi: < uli___> i'd start with reference, it's smaller. but that's just a matter of taste, i guess +13:07 #periperi: < dammsan> horms: so which order do you want stuff? +13:07 #periperi: < dammsan> i probably did the wrong order with the r8a7779 and marzen bits +13:07 #periperi: < dammsan> i did cleanup of -reference first +13:07 #periperi: < dammsan> followed by a legacy removal +13:07 #periperi: < uli___> that's what i thought to do as well +13:08 #periperi: < dammsan> uli___: so i thought you could do a similar series for the -reference cleanup +13:08 #periperi: < dammsan> but without causing any degradation of the multiplatform feature support +13:08 #periperi: < dammsan> (this is the bit i don't understand why it has not happened, but never mind) +13:09 #periperi: < horms> i think that makes sense +13:09 #periperi: < uli___> yes +13:09 #periperi: < horms> its not ideal from a merge pov, but we don't want multiplatform to go backwards +13:10 #periperi: < horms> so i think it is the way to go +13:11 #periperi: < horms> uli___: can you make it so? +13:11 #periperi: < uli___> can do. +13:12 #periperi: < horms> excellent +13:12 #periperi: < horms> please let me know if you hit any snags +13:12 #periperi: < dammsan> uli___: do you have a local board? +13:12 #periperi: < dammsan> (bock-w i mean) +13:12 #periperi: < uli___> nope, i'm using yours. but for removal, that should not be strictly necessary. :) +13:13 #periperi: < dammsan> ok, will remember that you are still using that! +13:13 #periperi: < horms> well, multiplatform will still need to be tested +13:13 #periperi: < horms> btw, i am also using that board +13:13 #periperi: < dammsan> sure +13:13 #periperi: < horms> lets try not to step on each others toes :) +13:13 #periperi: < uli___> unlikely, given the time zone difference, i'd say :) +13:14 #periperi: < horms> yes, agreed +13:14 #periperi: < dammsan> so will you fix it up until next meeting? +13:14 #periperi: < dammsan> i fixed up r8a7779 and the IPMMU prototype last time +13:15 #periperi: < uli___> which is when, btw? +13:15 #periperi: < dammsan> i suppose geert will announce that +13:15 #periperi: < dammsan> my guess would be 2 weeks +13:15 #periperi: < horms> that is my guess too +13:15 #periperi: < uli___> sure +13:16 #periperi: < dammsan> great - that means in 2 weeks i can look forward to no more legacy! +13:16 #periperi: < uli___> whatever makes you happy ;) +13:17 #periperi: < dammsan> reduced whining from ARM-SoC is always a good thing +13:17 #periperi: < dammsan> and reduced whining from me must be nice too =) +13:18 #periperi: < uli___> i'm not going to comment :) +13:18 #periperi: < dammsan> hahah +13:18 #periperi: < uli___> but i will go and have lunch now +13:18 #periperi: < dammsan> sure, have a nice one +13:18 #periperi: < horms> yes +13:18 #periperi: < horms> lets close this for now +13:18 #periperi: < horms> i'm looking forward to seeing some patches +13:19 #periperi: < dammsan> horms: lets continue the remote access discussion tomorrow or friday +13:19 #periperi: < horms> dammsan: i'll be coming and going tomorrow +13:19 #periperi: < horms> friday is probably better for me +13:19 #periperi: < dammsan> sure no worries +13:19 #periperi: < dammsan> have a nice evening and a pleasant tomorrow then =) +13:20 #periperi: < dammsan> see ya later +13:20 #periperi: < horms> thanks you too +13:20 #periperi: < uli___> good night +13:20 #periperi: < dammsan> bye! diff --git a/wiki/Chat_log/20150819-core-chatlog b/wiki/Chat_log/20150819-core-chatlog new file mode 100644 index 0000000..a0273c5 --- /dev/null +++ b/wiki/Chat_log/20150819-core-chatlog @@ -0,0 +1,250 @@ +11:03 #periperi: < geertu> Two more missing? +11:03 #periperi: < geertu> I mean inactive +11:03 #periperi: < dammsan> hello +11:03 #periperi: < geertu> Simon and Laurent are in Seattle, so they won't join +11:04 #periperi: < morimoto> hello +11:04 #periperi: < geertu> Good, looks lijke we are complete +11:05 -!- Irssi: Pasting 5 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +11:05 #periperi: < geertu> Agenda: +11:05 #periperi: < geertu> 1. Upcoming Gen3 development for the Core group +11:05 #periperi: < geertu> a. PFC +11:05 #periperi: < geertu> b. DMAC (e.g. "dmas" for (H)SCIF) +11:05 #periperi: < geertu> 2. SoC Bus topology in DT +11:05 #periperi: < geertu> 1. Upcoming Gen3 development for the Core group +11:06 #periperi: < geertu> Sorry, I missed 3. Status check for tasks from last meeting - what is remaining? +11:06 #periperi: < geertu> Any update from the Tokyo side on Gen3? +11:07 #periperi: < dammsan> geertu: i've got a board now, currently installing it +11:07 #periperi: < geertu> great! +11:08 #periperi: < morimoto> I guess we need to have IRQC as core +11:08 #periperi: < morimoto> Maybe magnus will do it (?) +11:08 #periperi: < geertu> We have a task for that, right? +11:08 #periperi: < morimoto> I guess so +11:09 #periperi: < dammsan> my plan is to develop that portion yes +11:09 #periperi: < geertu> And magnus is the creator of irq-renesas-irqc.c ;-) +11:09 #periperi: < dammsan> yay! +11:09 #periperi: < dammsan> where is the latest TODO list for the core group? on a wiki? +11:09 #periperi: < geertu> Is the "new" board identical to the "old" one? +11:10 #periperi: < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list +11:10 #periperi: < dammsan> sweet +11:10 #periperi: < geertu> Going over that list is Topic 3. Or do you think it should be topic 0? +11:10 #periperi: < dammsan> nah, just wasn't sure where it was +11:11 #periperi: < dammsan> sorry, please continue +11:11 #periperi: < geertu> Is the "new" board identical to the "old" one? +11:11 #periperi: < geertu> Also U-Boot wise? +11:11 #periperi: < dammsan> the u-boot has been improved i've been told +11:11 #periperi: < dammsan> hardware is supposed to be the same +11:12 #periperi: < geertu> "improved" means Ether-AVB support? +11:12 #periperi: < dammsan> we'll see +11:13 #periperi: < dammsan> I got code for u-boot Ether-AVB one week ago but nothing worked at that point +11:13 #periperi: < dammsan> Maybe things are better this time +11:13 #periperi: < geertu> Does it have smsc Ethernet, too? +11:13 #periperi: < dammsan> nope +11:13 #periperi: < dammsan> that would be good +11:14 #periperi: < geertu> Is there any documentation about the board (schematics?)? +11:15 #periperi: < dammsan> morimoto: any comment? +11:16 #periperi: < morimoto> Now, we are under paper work for export it +11:16 #periperi: < morimoto> please wait +11:16 #periperi: < geertu> Perhaps Magnus can send a higher-resolution picture of the board to periperi? +11:18 #periperi: < dammsan> perhaps magnus can send a high resolution picture of his screen if someone asks nicely =) +11:19 #periperi: < geertu> hehe +11:19 #periperi: < geertu> a. PFC +11:19 #periperi: < geertu> I understand there's a preliminary driver? +11:20 #periperi: < morimoto> Yes +11:20 #periperi: < morimoto> I think we should (?) reuse it ? +11:20 #periperi: < morimoto> No one want to re-create over 5000line driver +11:20 #periperi: < geertu> IIRC, Laurent wanted to move more to DT? +11:21 #periperi: < geertu> (i.e. write script to convert 5000 lines?) +11:21 #periperi: < morimoto> I don't know, but BSP team is using this driver +11:21 #periperi: < geertu> But without something concrete, that's more like a wild idea... +11:22 #periperi: < geertu> So I'd say let's post the driver +11:22 #periperi: < geertu> Any objections to that? +11:22 #periperi: < dammsan> sounds like a perfect plan to me +11:22 #periperi: < morimoto> me too +11:23 #periperi: < dammsan> is it possible to post it early tomorrow? +11:23 #periperi: < morimoto> I can do it today +11:23 #periperi: < dammsan> i want to use it with IRQC +11:23 #periperi: < geertu> Great! +11:23 #periperi: < dammsan> thanks! +11:23 #periperi: < shimoda> Nice! +11:24 #periperi: < geertu> b. DMAC (e.g. "dmas" for (H)SCIF) +11:24 #periperi: < geertu> Actually this is more about having core infrastructure pointed to by all device nodes in DT +11:25 #periperi: < geertu> - interrupts +11:25 #periperi: < geertu> - clocks +11:25 #periperi: < geertu> - power-domains = <&cpg_clocks>; +11:25 #periperi: < geertu> - dmas +11:25 #periperi: < geertu> To avoid lots of churn, I think we should try to get the core blocks in ASAP. +11:25 #periperi: < dammsan> sounds good to me +11:26 #periperi: < dammsan> would it be possible for someone to make a first example? +11:26 #periperi: < dammsan> (IRQC has no DMA =) +11:27 #periperi: < geertu> I was thinking about adding all (H)SCIF nodes if I find a spare moment +11:27 #periperi: < geertu> interrupts we already have (GIC node is there, IRQC will be soon) +11:27 #periperi: < geertu> (does anything use IRQC on the board?) +11:27 #periperi: < geertu> clocks we have some parts (exact location in the tree still TBD) +11:28 #periperi: < geertu> For power-domains I already posted the CPG/MSTP Clock Domain patches +11:28 #periperi: < geertu> dmas is lacking, but according to Laurent it's compatible with rcar-dmac, and I think a dummy node can do for now. +11:29 #periperi: < geertu> (have to test that on Koelsch, to see if scif still works with a dummy dmac node) +11:30 #periperi: < dammsan> sounds good. PMIC is hooked up to IRQ0. No quirk is needed. +11:30 #periperi: < geertu> Only PMIC? +11:30 #periperi: < dammsan> yes, a single one +11:30 #periperi: < dammsan> that's it +11:31 #periperi: < geertu> Nice +11:31 #periperi: < morimoto> and I have its document. I can send it with schematics +11:31 #periperi: < geertu> Cool +11:31 #periperi: < dammsan> the rest is availabile on expansion connectors +11:31 #periperi: < geertu> Are these the same Samtec connectors like on Gen2? +11:32 #periperi: < dammsan> some of them are the same +11:32 #periperi: < dammsan> some are wider i think +11:32 #periperi: < dammsan> you'll see once you get the schematics +11:32 #periperi: < geertu> It's mostly the pitch that matters. +11:32 #periperi: < geertu> OK +11:33 #periperi: < geertu> I'll add a task for adding all (H)SCIF nodes +11:33 #periperi: < dammsan> thanks +11:33 #periperi: < dammsan> will you work with Simon to get the pm domains stuff merged too? +11:34 #periperi: < geertu> Yes +11:34 #periperi: < dammsan> sweet +11:34 #periperi: < geertu> (in the mean time it's in arm-soc for pre-Gen3) +11:34 #periperi: < geertu> Morimoto-san had a problem with it related to sound? +11:36 #periperi: < shimoda> morimoto: "its document" means PMIC's one? if so, we have to do paper work :) +11:36 #periperi: < geertu> PDF work? +11:37 #periperi: < morimoto> Yes it is PMIC document +11:37 #periperi: < dammsan> we need at least 3 different hankos +11:37 #periperi: < dammsan> to stamp both virtual and real papers +11:38 #periperi: < geertu> http://factsanddetails.com/media/2/20090801-customizedtitle6jun.gif +11:39 #periperi: < dammsan> i've started to greatly appreciate the popular software that makes gif images for stamps for inclusion in excel sheet +11:40 #periperi: < dammsan> now when i see an excel sheet without a stamp i somehow feel empty +11:40 #periperi: < geertu> Like the "please send me your digital signature" requests, where they actually want you to send a GIF instead of running gpg? +11:41 #periperi: < geertu> Any more "Upcoming Gen3 development for the Core group"? +11:42 #periperi: < dammsan> lets see +11:42 #periperi: < dammsan> IRQC SCIF PFC +11:43 #periperi: < dammsan> how about GPIO? +11:43 #periperi: < dammsan> do we have a task for that? +11:43 #periperi: < geertu> Linus W: "Patch applied with the ACKs. +11:44 #periperi: < dammsan> right, but does that include the integration stuff? +11:44 #periperi: < geertu> No, dtsi update seems missing +11:44 #periperi: < uli___> should i do that then? +11:45 #periperi: < dammsan> that would be great if so +11:45 #periperi: < uli___> ok +11:45 #periperi: < dammsan> btw: the new Gen3 board gives me random exceptions +11:46 #periperi: < geertu> r8a7795,v4.4,Add gpio nodes to DT +11:46 #periperi: < geertu> oops +11:46 #periperi: < geertu> It's a different board? +11:46 #periperi: < geertu> Different firmware? +11:48 #periperi: < shimoda> dammsan: it's different board than last week +11:48 #periperi: < shimoda> oops, also different firmware +11:49 #periperi: < shimoda> especially "bl2.srec". so please write old one if possible? +11:49 #periperi: < dammsan> shimoda: can i update early software using the SCIF mask rom loader +11:49 #periperi: < dammsan> ok, will try to use the old "bl2.srec" +11:49 #periperi: < dammsan> thanks +11:50 #periperi: < shimoda> thanks +11:50 #periperi: < dammsan> good news is that ether-avb seems to half-work - until i get exceptions +11:50 #periperi: < dammsan> i also get exception when i boot the kernel so... +11:50 #periperi: < dammsan> will downgrade bl2.srec +11:50 #periperi: < dammsan> end-of-gen3-board-stuff +11:51 #periperi: < geertu> Topic 2. SoC Bus topology in DT +11:52 #periperi: < geertu> I guess nothing has changed, so just a single bus +11:52 #periperi: < shimoda> I got one other Gen3 board now. I will try to boot kernel after i wrote some firmware +11:52 #periperi: < dammsan> shimoda: thanks, please do and let me know how it goes +11:53 #periperi: < dammsan> geertu: i think nothing has changed yes +11:53 -!- Irssi: Closing query with morimoto +11:53 -!- Irssi: Closing query with dammsan +11:53 #periperi: < geertu> Topic 3. Status check for tasks from last meeting - what is remaining? +11:53 #periperi: < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list +11:53 #periperi: < geertu> Device: IPMMU +11:53 #periperi: < geertu> Finally get feedback from the hardware developers regarding the IPMMU + DMAC channel 0 issue +11:54 #periperi: < geertu> Any news? +11:54 #periperi: < dammsan> I don't think so +11:54 #periperi: < geertu> Device: r8a777x +11:54 #periperi: < geertu> Vote which missing support is valuable +11:54 #periperi: < geertu> I guess this can be marked completed? +11:55 #periperi: < dammsan> i guess so. if someone has a board locally and want to hack then that's great +11:55 #periperi: < dammsan> but i think adding USB support over remote access is too difficult to be worth dealing with +11:55 #periperi: < dammsan> especially for Gen1 +11:55 #periperi: < dammsan> so yes, mark as completed +11:55 #periperi: < geertu> Device: IPMMU+DMAC +11:55 #periperi: < geertu> Discuss API changes on the dma-engine mailing list +11:55 #periperi: < geertu> Implement proper solution +11:56 #periperi: < geertu> Our DMAC expert is absent and busy? +11:56 #periperi: < dammsan> yes and yes =) +11:56 #periperi: < geertu> Device: SMP +11:56 #periperi: < geertu> Discuss SMP DT bindings with ARM SoC maintainers +11:56 #periperi: < geertu> No progress +11:56 #periperi: < dammsan> Nothing doe +11:56 #periperi: < geertu> Device: r8a7778 +11:56 #periperi: < geertu> Add support for valuable devices to multi-platform r8a7778 +11:56 #periperi: < geertu> Drop legacy (-legacy and -reference) r8a7778/bockw +11:56 #periperi: < shimoda> Oops, about IPMMU, I didn't ask hardware guys yet because I didn't explain the detail to the guys +11:56 #periperi: < dammsan> s/doe/done +11:56 #periperi: < geertu> I think this can be marked completed, too? +11:57 #periperi: < dammsan> yeah, thanks to hard work from ulrich we are in a much better state with bock-w and r8a7778 now! +11:57 #periperi: < geertu> Device: r8a7779 +11:57 #periperi: < geertu> Add support for valuable devices to multi-platform r8a7779 +11:57 #periperi: < geertu> And that's the USB one, which is still open +11:57 #periperi: < dammsan> shimoda-san, can we discuss IPMMU face-to-face next week? +11:58 #periperi: < dammsan> geertu: about USB, that's for r8a7779 right? +11:58 #periperi: < geertu> I think so +11:58 #periperi: < dammsan> i think we are limited by physcial access to hardware +11:58 #periperi: < shimoda> magnus-san, thank you! +11:59 #periperi: < dammsan> but if someone wants to hack then we should perhaps rearrange things +11:59 #periperi: < geertu> Sorry, that seems to be valid for both '78 and '79 +11:59 #periperi: < geertu> So the valuable devices for '78 is still open, too +11:59 #periperi: < dammsan> geertu: i don't know if the IP is the same +11:59 #periperi: < dammsan> Gen1 seems rather different within the same family +12:00 #periperi: < dammsan> but anyway, keeping open seems good too +12:00 #periperi: < geertu> The remaining tasks are all open +12:00 #periperi: < geertu> Sorry, except for +12:00 #periperi: < geertu> Device: r8a7795 +12:00 #periperi: < geertu> Group on-SoC devices under a simple-bus node on r8a7795 +12:00 #periperi: < dammsan> shimoda: meeting on friday the 28th about IPMMU clarification? +12:01 #periperi: < dammsan> geertu: i thought the latest version from morimoto-san did this already? +12:01 #periperi: < geertu> Yes, cfr. the "Sorry" above +12:01 #periperi: < shimoda> dammsan: sure! thank you! +12:03 #periperi: < dammsan> ok! +12:04 #periperi: < morimoto> http://thread.gmane.org/gmane.linux.ports.sh.devel/47755 +12:07 #periperi: < dammsan> this version is included in the latest renesas-drivers snapshot, right? +12:07 #periperi: < morimoto> I think so +12:08 #periperi: < geertu> morimoto: Thanks for PFC email! +12:10 #periperi: < morimoto> It seems SH-ARM ML didn't accept it. I guess it is too large ? +12:10 #periperi: < geertu> Possibly +12:10 #periperi: < morimoto> (This is always happen on SH-ARM ML...) +12:10 #periperi: < geertu> BTW, gmail started thinking Uli's emails are spam +12:11 #periperi: < uli___> gmail thinks everything is spam... :( +12:12 #periperi: < morimoto> This is prepare for alphabet.com ? +12:13 #periperi: < geertu> morimoto: You didn't CC LinusW? +12:13 #periperi: < morimoto> Oops, I didn't Cc to him +12:15 #periperi: < morimoto> Should I resend it ? or wait Laurent's opinion ? +12:15 #periperi: < geertu> Perhaps better wait for Laurent +12:16 #periperi: < geertu> Let's hope his mail server didn't crash due to the large patch while he's in Seattle ;-) +12:16 #periperi: < dammsan> geertu: if it crashes then perhaps he at least can have a silent vacation =) +12:17 #periperi: < morimoto> Hehe :) +12:18 #periperi: < dammsan> btw, the u-boot says "Salvator-X" for board name but we use "salvatorx", what's up with that? +12:19 #periperi: < geertu> Is that actually a beer? +12:19 #periperi: < dammsan> seems more like a spelling mistake to me =) +12:20 #periperi: < morimoto> According to HW team (they named it), it is standard beer name +12:20 #periperi: < morimoto> s/standard/public/ +12:20 #periperi: < dammsan> salva-torx +12:20 #periperi: < morimoto> (This is the reason why we didn't need paper work for it when I sen patch to ML) +12:22 #periperi: < dammsan> just virtual hanko needed? =) +12:22 #periperi: < morimoto> it need no paper work if it is public name +12:23 #periperi: < morimoto> otherwise, we need to check all (?) names +12:23 #periperi: < dammsan> so if "google i'm feeling lucky" gives you a web page then it is fine? =) +12:23 #periperi: < morimoto> to avoid using same name +12:24 #periperi: < dammsan> i understand some uniqueness is needed +12:24 #periperi: < geertu> So it's not about the secrets in the .dts file, just about the name of the board? +12:25 #periperi: < morimoto> uniqueness is one reason. we need to avoid "pirate the trademark" +12:25 #periperi: < morimoto> (? correct English ??) +12:25 #periperi: < dammsan> how about trade the pirate? =) +12:26 #periperi: < dammsan> i think you want to avoid trademark violation +12:26 #periperi: < dammsan> which makes sense +12:27 #periperi: < dammsan> https://en.wikipedia.org/wiki/Torx +12:27 #periperi: < dammsan> apparently torx is trademarked +12:27 -!- Irssi: Starting query in freenode with dammsan +12:27 <geertu> http://events.linuxfoundation.org/sites/events/files/slides/stable.pdf doesn't list 3.10 under LTS +12:27 #periperi: < dammsan> but i will now stop to make everyone worried +12:28 #periperi: < dammsan> geertu: but that's from oracle +12:29 #periperi: < geertu> I think we're ready anyway, right? +12:29 #periperi: < geertu> Anything we missed? +12:29 #periperi: < dammsan> nothing from my side +12:30 #periperi: < geertu> OK, thanks, and have a nice day/evening/night/... +12:31 #periperi: < morimoto> thanks +12:31 #periperi: < dammsan> thank you guys! +12:31 #periperi: < shimoda> thank you! diff --git a/wiki/Chat_log/20150826-io-chatlog b/wiki/Chat_log/20150826-io-chatlog new file mode 100644 index 0000000..cf64c17 --- /dev/null +++ b/wiki/Chat_log/20150826-io-chatlog @@ -0,0 +1,267 @@ +--- Log opened Wed Aug 26 10:55:12 2015 +10:55 -!- wsa_ [~wsa@p4FE25F24.dip0.t-ipconnect.de] has joined #periperi +10:55 -!- Irssi: #periperi: Total of 8 nicks [0 ops, 0 halfops, 0 voices, 8 normal] +10:55 -!- Irssi: Join to #periperi was synced in 0 secs +10:55 < geertu> Hi Wolfram +10:55 < wsa_> heyho! +10:55 < shimoda> Hi Wolfram-san! +10:55 < horms> Hi + Bye Wolfram +10:56 < wsa_> bye? +10:56 < wsa_> No IO Meeting for you Simon? +10:56 * horms goes home +10:56 < horms> oh we have a meeting? +10:57 < horms> sorry i missed that +10:57 < horms> i'll run home and log back in +10:57 < wsa_> ok +10:57 < wsa_> :9 +10:57 < wsa_> :) +10:57 < wsa_> hi geert, shimoda-san! +10:59 < shimoda> hi! +11:01 < geertu> hi all +11:01 -!- horms [~horms@reginn.isobedori.kobe.vergenet.net] has quit Ping timeout: 244 seconds +11:01 < wsa_> so, simon will come back soon +11:01 < wsa_> is morimoto-san around? +11:02 < morimoto> Hi +11:02 < geertu> His bot is alive ;-) +11:02 < wsa_> :) +11:02 < shimoda> :) +11:03 < wsa_> a meeting bot +11:03 < wsa_> i guess that's a way to make $$$ +11:03 < wsa_> ;) +11:04 < geertu> My former project manager was once convinced I was in a phone conf call and said things, while I wasn't there ;-) +11:05 < geertu> With IRC it's even easier... +11:05 -!- horms [~horms@121-80-213-238f1.hyg1.eonet.ne.jp] has joined #periperi +11:05 < geertu> welcome back +11:05 < horms> sorry about that. for some reason i hadn't added this meeting to my schedule +11:05 < wsa_> geertu: I hope you said good things while you weren't there +11:06 < horms> i said "I have a meeting" ! +11:06 < horms> + hello to someone in the elevator +11:06 < wsa_> well, you are here nonetheless +11:06 < wsa_> so fine +11:07 < wsa_> and I will make sure I get confirmations for the meeting dates from all of you explicitly ;) +11:07 < wsa_> so, let's start I'd say +11:07 < wsa_> I see two topics +11:08 < wsa_> 1) Gen3 status update +11:08 < wsa_> 2) SCIF +11:08 < wsa_> and miscellaneous +11:08 < wsa_> any other topics from you? +11:09 < horms> not from me +11:10 < wsa_> then let's start with Gen3 +11:10 < wsa_> we can add new topics as they come +11:11 < wsa_> is there an update to the timeline when which devices need to be enabled when? +11:11 < horms> i can give an etheravb update of sorts; when you are ready +11:12 < wsa_> i did not get any feedback to my I2C patches, I guess everyone was busy doing core bringup... +11:12 < shimoda> The current plan is, SPI needs by 1th Sep. but, i don't know it can be used on gen3 board +11:12 < morimoto> This is different topics, but now I could use GPIO and I2C on Gen3 board. it is not included on v7, but I can add it on v8 +11:13 < geertu> That's MSIOF? +11:13 < shimoda> geertu: yes +11:13 < geertu> The only usable point so far is SoftSW +11:13 < geertu> Haven't checked pinctrl and EXIO yet +11:13 < geertu> BTW, the pintrl part in the datasheet is "difficult" +11:13 < wsa_> morimoto-san: you mean I2C native or I2C using GPIO? +11:14 < geertu> There are no tables like on Gen2 (I want to add HSCIF pinctrl) +11:14 < geertu> Or am I missing something> +11:14 < geertu> Still, SoftSW would require soldering +11:15 < geertu> Or the CP[1-4] test points. +11:15 < shimoda> usb2 host needs by 25th August, and renesas-drivers-2015-08-25-v4.2-rc8 works correctly +11:15 < morimoto> geertu: Gen3 datasheet was exchanged. yes it is difficult to read +11:16 < wsa_> so I2C is closed case now? +11:17 < wsa_> and GPIO? (which is requirement for EtherAVB) +11:17 < morimoto> wsa_: I'm using renesas,i2c-r8a7795 for i2c. i2c driver seems working. I could chance to use gpio-i2c too +11:17 < wsa_> well, i am fine with renesas,i2c-r8a7795. that's enough for me. +11:17 < wsa_> nice +11:18 < morimoto> wsa_: please keep i2c/gpio + 1week. I need to check it on new board. (I used old and broken board) +11:18 < wsa_> ok +11:19 < shimoda> HSCIF and USB func need by 22th Sep. +11:20 < geertu> Working on HSCIF, now I have a serial link to DEBUG SERIAL-1 +11:20 < geertu> SCIF1 on those pins works +11:21 < shimoda> nice! +11:21 < geertu> shimoda: Or is MSIOF the slave-only DRIF? +11:21 < wsa_> so, the next work items would be: SPI (but we don't have proper HW setup currently) and testing I2C/GPIO with the new board (morimoto-san) +11:21 < wsa_> usb works +11:22 < morimoto> I didn't try ii2 +11:22 < morimoto> but i2 +11:22 < morimoto> i2c +11:22 < morimoto> please care ii2 +11:23 < morimoto> s/ii2/iic/g +11:23 < shimoda> geertu: just MSIOF, not DRIF +11:24 < wsa_> morimoto: what do you mean by care? +11:25 < morimoto> Gen3 has I2C/IIC. I can try I2C, but I don't try IIC +11:25 < horms> care -> please look after it +11:25 < wsa_> by the way, does magnus have a "new board" or an "old broken board" in his lab? +11:26 < morimoto> His one is OK board +11:26 < morimoto> but he is using old uboot +11:26 < wsa_> good +11:26 < morimoto> Ah, but 1 note. +11:26 < wsa_> morimoto: do you have a patch for adding all i2c to the r8a7795 dtsi or shall I make one? +11:27 < morimoto> His one has 16.000Mhz as extal clock. +11:27 < morimoto> new board has 16.666HMhz +11:27 < morimoto> First plan was 33.333MHz, but... +11:28 < morimoto> wsa_: I have it, I can send it in v8 +11:28 < wsa_> ok +11:28 < morimoto> wsa_: it is including PFC / MSTP too +11:28 < wsa_> great +11:28 < geertu> Before someone starts writing the SCIF/HSCIF dtsi patch, I have it +11:29 < morimoto> Mine has only SCIF2, can I update it to your one? or do you send it as incremental patch ? +11:29 < morimoto> in v8 +11:29 < geertu> I will send an incremental patch +11:29 < wsa_> is there some schedule when to use magnus gen3 board? +11:29 < morimoto> OK +11:30 < wsa_> i assume core group needs it a lot? +11:30 < wsa_> or first come first serve? :) +11:30 < geertu> It's mutex is kept on #periperi +11:30 < geertu> Currently I have it ;-) +11:30 < wsa_> ok +11:31 < wsa_> anything else related to gen3? +11:32 < horms> yes +11:32 < horms> the bsp team have an etheravb patchset, which i now also have +11:33 < horms> it depends on gpio which ulrich is handling; there were patches for that too which he now has +11:33 < horms> i plan to test the patchset in the near future +11:33 < horms> a blocking item is that it has some non-trivial driver changes that we would like to check for regresssions on 32bit +11:33 < horms> which requires testing +11:33 < wsa_> i see +11:33 < horms> i believe shimoda-san will handle that when he has time +11:34 < wsa_> are the changes needed for basic support or for the extended feature set? +11:34 < horms> in the short term we may be able to get 100Mbit working and on a ML +11:34 < shimoda> horms: yes, i will try that on alt + expantion board +11:34 < horms> there is some special sauce required for futher support; a documentation update is a dependency there +11:34 < shimoda> s/expantion/expansion/ +11:35 < horms> wsa_: for basic support, i believe +11:35 < horms> i'll double check that +11:35 < horms> basucically i think we are talking about crash-bugs on 64bit +11:35 < wsa_> i see +11:36 < horms> probably the best things is for me to test things on 64bit, polish things up and post an rfc +11:36 < horms> with no special sauce +11:36 < horms> so i nominate that as my near term goal +11:36 < wsa_> sounds reasonable +11:37 < horms> one question i have; i assume the main use of this to us is nfs root. but that also seems not very useful to the people in europe +11:37 < horms> which is a good portion of us +11:37 < horms> am I reading things right? +11:37 < horms> shimoda: thanks +11:38 < geertu> At least NFS would allow to import/export files in the initrd +11:38 < wsa_> I mainly use initramfs, but my userspace needs are not very high... +11:38 < horms> geertu: good point +11:38 < geertu> But from my experience, just mounting NFS and writing a small file takes a minute +11:38 < horms> anyway, i'll work on it +11:39 < geertu> Right now I'd like to copy my HSCIF1 overlay dtbo to my initrd ;-) +11:39 < geertu> I could modify the initrd +11:39 < geertu> But for exporting, that doesn't work +11:39 < horms> so you tftp things once you are in usespace; in an ideal situation +11:39 < geertu> Probably we can set up an NFS root on the management VM, too? +11:40 < horms> probably +11:40 < geertu> AH, TFTP is an alternative +11:40 < geertu> Probably faster +11:40 < horms> i believe that is magnus's preferred method for himself +11:40 < wsa_> Yup, TFTP does it for me. Also, less to setup +11:40 < horms> but i agree a more local nfs server would be useful +11:41 < geertu> And we already have tftp setup on the management vm +11:41 < horms> but i think its somewhat off topic for this meeting +11:41 < geertu> yep +11:41 < horms> i think thats all for etheravb from me +11:41 < wsa_> thanks, simon +11:42 < wsa_> so, let's move to SCIF +11:42 < geertu> I submitted a new patch series last week +11:42 < wsa_> geertu has sent an awesome new series (actually two) which make DMA work now +11:42 < wsa_> so \o/ +11:43 < horms> yay indeed +11:43 < geertu> Major change is submitting the RX DMA request from the RX interrupt, which is what many other serial drivers do +11:43 < geertu> + lots of cleanups, and reordering of the patches to make more sense +11:44 < wsa_> did that give you any more insights about how all this affects non-Rcar SCIF and how/what could be backported to the BSP? +11:44 < geertu> I have to do more testing, though, as you may receive bogus data during overrunrs +11:45 < geertu> Non-R-Car SCIF* may be an issue +11:46 < geertu> We don't have DT-based DMA on any other ARM platform +11:46 < shimoda> wsa_: I think we don't need backport to the R-Car Gen2 BSP because it's maintenance mode +11:46 < geertu> kzm9g/armadillo/ape6evm use SCIFA for console, though +11:47 < geertu> in -legacy they had some DMA support, but it was not enabled for SCIFA (and didn't work when I tried to enable it on Armadillo) +11:47 < horms> do you have access to any of those boards? +11:47 < geertu> I have kzm9g/armadillo/ape6evm +11:47 < horms> a flush! +11:47 < geertu> So PIO SCIFA keeps on working +11:49 < geertu> I could try SCIFA DMA on e.g. Armadillo if I (1) revive -legacy and (2) try to fix the legacy shdma driver for modern residue handling (untested RFC patch posted) +11:49 < geertu> But in the long term, that's insignificant +11:49 < wsa_> i agree +11:49 < geertu> SCIF DMA was originally written for SH (sh7724?) +11:50 < geertu> hut never wired up in the sh platform code, so there are no users. +11:50 < geertu> s/hut/but/ +11:50 < geertu> So for now R-Car Gen2 (M2/koelsch) is what we have to work with +11:51 < wsa_> I think we are fine as long as PIO keeps working +11:51 < geertu> And Gen3 soon +11:51 < wsa_> on the old platforms +11:51 < wsa_> yes +11:51 < wsa_> is there any gain if I test them on lager? +11:51 < geertu> I think Shimoda-san already did, at least with the previous version +11:51 < wsa_> except that more testing is always a gain ;) +11:52 < geertu> On Koelsch, I test SCIF/SCIFA/SCIFB/HSCIF on EXIO +11:52 < shimoda> geertu: yes, I tested v2 version on lager. but i don't test v3 yet. +11:53 < geertu> BTW, SCIFB receive doesn't seem to work on one of the EXIOs. It may be a bug in pinctrl (code/doc) +11:53 < wsa_> so, gen2 bsp is in maintenance mode and gen3 bsp could pick up geert's patches as is? +11:54 < wsa_> or do we still have a version gap? +11:54 < wsa_> we talked last time about it +11:54 < geertu> I think Magnus would like the BSP team to switch over once my series is "finished" +11:54 < wsa_> yes, we would all like that, I assume :) +11:55 < horms> that makes sense to me unless there is a pressing need for it in the gen3 bsp in the near term +11:56 < wsa_> sounds good, i don't see any obstacles in how to go forward... +11:56 < shimoda> wsa_: about gen3 bsp plan, it uses upstream version (renesas-driver.git) until end of next year +11:57 < wsa_> next year? wow! +11:58 < wsa_> and yay! +11:58 < wsa_> so, that's it for SCIF? +11:58 < shimoda> oops, gen3 bsp target is "LTSI-2017". so, this might mean mid of next year +11:59 < geertu> I have one more question +11:59 < shimoda> anyway, bsp team looks upstream in this year +11:59 < geertu> What's up with the IRDA MSTP clock and SCIF2? +11:59 < wsa_> mid-2016 is still good IMO +12:00 < morimoto> IrDA on Gen3 is secret feature. +12:00 < morimoto> It will be removed from datasheet +12:00 < morimoto> and, please don't ask it on ML :) +12:01 < geertu> So there's a hole in the SCIFx MSTP2 range, and SCIF2 uses a clock from MSTP3 +12:01 < morimoto> About MSTP, IrDA and SCIF2 is using same one +12:02 < morimoto> Yes +12:06 < wsa_> ok +12:07 < wsa_> misc +12:07 < wsa_> i pulled in my i2c-slave updates +12:08 < wsa_> and I am currently scoping the rcar-i2c core to understand all the repeated start/NACK/auto retransmission issues we were seeing +12:09 < horms> shimoda san sent me a Kconfig fix for our ethernet drivers which has been merged +12:09 < wsa_> shimoda-san also got his PWM driver accepted \o/ +12:10 < horms> https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=83bc805bff89854e4c81c67633a52ce1015b1502 +12:11 < wsa_> that was my misc part +12:11 < shimoda> wsa_: about PWM, yes, the PWM driver seems accepted but i cannot find the pwm maintainer git :) +12:12 < wsa_> yes, he said he will do the final changes but it is not clear if he actually did them +12:12 < geertu> git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git +12:12 < geertu> it's part of renesas-drivers +12:14 < shimoda> oops, i meant that i could not find the PWM driver commit in his repo +12:16 < wsa_> so, final question would be when to meet next time +12:17 < wsa_> to be honest, I don't think we need the next meeting in two weeks. what about three weeks? +12:18 < wsa_> sorry, just found one thing +12:18 < wsa_> shimoda: what is the status about USB+IPMMU issues? +12:18 < horms> so far my evening schedule is open in both 2 and 3 weeks +12:18 < geertu> shimoda: It's indeed not included yet, probably because it's meant for v4.4 +12:19 < geertu> My schedule is open in both 2 and 3 weeks, except on Wednesdays +12:20 < shimoda> wsa_: no update for now +12:20 < shimoda> geertu: thank you for the checking +12:21 < geertu> shimoda: we have to have a bit more patience, as not many patches will be accepted between now and v4.3-rc1 +12:22 < geertu> (this also applies to the Gen3 patch stack!) +12:22 < morimoto> About next meeting, I don't want 16th Sep, other days are OK +12:22 < morimoto> 16th and 23th Sep +12:23 < wsa_> geertu: well, thierry could apply the new-driver-rule. but it is his choice, of course... +12:23 < horms> btw, 21, 22, 23 are holidays in the land of the rising sun +12:23 < wsa_> i suggest Sep 15th +12:23 < wsa_> same time +12:23 < morimoto> 15th Sep is OK for me +12:24 < horms> This time its in my schedule properly :) +12:24 < shimoda> geertu: I got it +12:24 < wsa_> \o/ +12:24 < shimoda> wsa_: 15th is OK to me +12:26 < geertu> booked +12:26 < morimoto> same here +12:26 < wsa_> great +12:27 < wsa_> that's it I assume +12:27 < wsa_> thank you! +12:27 < horms> wsa_: thanks +12:27 < geertu> thx +12:27 < morimoto> Thanks +12:27 < morimoto> Bye x2 +12:27 < wsa_> have a great evening/rest of day! +12:28 < shimoda> thank you, bye! +12:28 -!- shimoda [~shimoda@relprex2.renesas.com] has quit Quit: WeeChat 0.4.2 +12:28 < geertu> bye +--- Log closed Wed Aug 26 12:30:04 2015 diff --git a/wiki/Chat_log/20150901-core-chatlog b/wiki/Chat_log/20150901-core-chatlog new file mode 100644 index 0000000..9dfc6a6 --- /dev/null +++ b/wiki/Chat_log/20150901-core-chatlog @@ -0,0 +1,454 @@ +11:02 #periperi: < geertu> Welcome to the Core Group Chat Session! +11:02 #periperi: < uli___> good morning +11:02 #periperi: < horms> Thanks, nice to be back +11:02 #periperi: < geertu> Today's agenda: +11:02 -!- Irssi: Pasting 5 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +11:02 #periperi: < geertu> 1. Upcoming Gen3 development for the Core group, +11:02 #periperi: < geertu> 2. Topic/branch/merge organization of Gen3 work, +11:02 #periperi: < geertu> 3. DMA topology, +11:02 #periperi: < geertu> 4. CPG and boot mode via syscon (or not), +11:02 #periperi: < geertu> 5. Status check for tasks from last meeting - what is remaining? +11:03 #periperi: < morimoto> dammsan: which port is bock-w ? +11:04 #periperi: < dammsan> morimoto: 8004 +11:04 #periperi: < morimoto> # this is not core topic, but now we have 2 board, and I will send it to Europe engineer +11:05 #periperi: < morimoto> # but because of papwer work, it will be next week +11:05 #periperi: < morimoto> dammsan: thanks +11:06 #periperi: < horms> morimoto: i use bockw sometimes, so lets co-ordinate here if you want to use the board +11:06 #periperi: < horms> uli___: +11:06 #periperi: < horms> uli___ also uses it, but usually while we are ase +11:06 #periperi: < horms> uli___ also uses it, but usually while we are ase +11:06 #periperi: < horms> uli___ also uses it, but usually while we are asleep +11:06 #periperi: < uli___> indeed +11:06 #periperi: < horms> (typing disaster!) +11:06 #periperi: < geertu> Topic 1. Upcoming Gen3 development for the Core group, +11:07 #periperi: < dammsan> geertu: right +11:07 #periperi: < dammsan> i intend to update the cpg series and the integration series +11:08 #periperi: < dammsan> and also work on irqc +11:08 #periperi: < dammsan> but i hope to keep the integration series small until we can stabilize the cpg and the pfc +11:08 #periperi: < dammsan> so focus must be on stabilizing pfc and cpg +11:09 #periperi: < geertu> Integration is the hardest w.r.t. merge conflicts (but that's actually topic 2) +11:09 #periperi: < horms> I plan to put integration series's into topic branches as they appear; only addrssing apply and build time dependencies +11:09 #periperi: < horms> (sorry, lets talk about that in topic2) +11:10 #periperi: < dammsan> (yeah, sorry, so what shall we talk about for topic1?) +11:10 #periperi: < geertu> Stabilize CPG and PFC +11:10 #periperi: < dammsan> ok =) +11:10 #periperi: < geertu> It seems dropping clock-output-names was not such a good idea... +11:10 #periperi: < dammsan> i did it because it seemed that mike turquette wanted us to do so +11:10 #periperi: < dammsan> but perhaps i misunderstood +11:11 #periperi: < geertu> No respnse from Mike yet (although he's alive, sent pull request, and replied to me in other personal email) +11:11 #periperi: < horms> I saw him last week; he was also alive then! +11:11 #periperi: < dammsan> i think we can work around things by registering names using in-driver generated names +11:11 #periperi: < dammsan> not exposing names in DT seems like a fine idea to me +11:12 #periperi: < geertu> Nope, all fixed-factor-clocks rely on clock-output-names in the parent clocks +11:12 #periperi: < dammsan> geertu: sure +11:12 #periperi: < dammsan> but can't we work around that somehow? +11:12 #periperi: < dammsan> by providing clock-output-name equivalent but from the driver? +11:12 #periperi: < geertu> the scif driver "works" (for scif2) as it assumes 115200 baud and doesn't program registers +11:13 #periperi: < dammsan> sure, i think that is the state of the entire CPG series +11:13 #periperi: < geertu> clk_of_get_parent_clock_name() looks in DT, it doesn't follow in-kernel clock topology +11:13 #periperi: < dammsan> maybe it should? +11:13 #periperi: < geertu> That's one option. +11:14 #periperi: < dammsan> so say it would work, then isn't omitting that parameter from DT a good idea? +11:14 #periperi: < geertu> I think "no clock-output-names" is meant for clocks with a single output, where the node name can be used instead +11:14 #periperi: < dammsan> ok i see +11:14 #periperi: < dammsan> so we could have one node per clock instead +11:14 #periperi: < geertu> It may be a good idea if the driver knows (like cpg) +11:14 #periperi: < dammsan> or perhaps we should extend the core to support index? +11:15 #periperi: < geertu> For mstp the driver doesn't know, so it comes up with mstp3.10 +11:15 #periperi: < geertu> I'd like to wait for the clock people's response +11:15 #periperi: < dammsan> the cpg driver could do the same +11:15 #periperi: < dammsan> since we have the strings there anyway +11:15 #periperi: < geertu> Clocks work again just by re-adding clock-output-names to the dtsi only (no driver update needed) +11:16 #periperi: < dammsan> waiting for maintainer feedback is of course a good plan +11:16 #periperi: < dammsan> but is there something we could do in the meantime? +11:16 #periperi: < dammsan> we could re-add clock-output-names like you say +11:16 #periperi: < dammsan> or just fix the code in the cpg driver +11:16 #periperi: < geertu> It's not a problem in the cpg driver +11:16 #periperi: < geertu> and it can't be fixed there +11:17 #periperi: < geertu> only in core clock code +11:17 #periperi: < dammsan> oh, but this only triggers in the case of CPG and not in MSTP, right? +11:17 #periperi: < geertu> It doesn't trigger in mstp, because the only users of mstp clocks are devices, where clk_get() will do the right thing. +11:18 #periperi: < geertu> If you register e.g. a fixed-factor-clock as a child of an mstp clock, it will fail, too +11:18 #periperi: < dammsan> ok then consider me convinced =) +11:18 #periperi: < horms> +1 +11:19 #periperi: < geertu> Basically it fails for every clock in DT where the parent has multiple clock outputs +11:19 #periperi: < dammsan> so we should wait for feedback? +11:20 #periperi: < dammsan> or does anyone feel like cooking up some core CCF code? =) +11:20 #periperi: < dammsan> maybe i simply misunderstood mike turquette +11:20 #periperi: < geertu> Not me, because I think the "no clock-output-names rule" is flawed +11:22 #periperi: < geertu> Any other upcoming gen3 work (irqc is already in the task list)? +11:22 #periperi: < shimoda> we should prepare thermal driver in Sep. +11:22 #periperi: < dammsan> does it make sense to pick up the GPIO stuff? +11:23 #periperi: < geertu> I have it included in today's renesas-drivers +11:23 #periperi: < dammsan> i think i prefer to keep the integration patch set small (and that's topic2 sorry) +11:23 #periperi: < shimoda> gen3 thermal seems not compatible with gen2 :) +11:23 #periperi: < geertu> Indeed, but thermal is I/O, not Core? +11:25 #periperi: < dammsan> geertu: how shall we split the core work then? +11:25 #periperi: < horms> possibly but the next I/O group meeting is not for 2 weeks, there won't be much September left then +11:25 #periperi: < horms> perhaps it is a topic for email? +11:25 #periperi: < shimoda> oops, my sheet is written as core +11:25 #periperi: < geertu> gpio lacks power-domains properties, but for now that works due to an obsolete CONFIG_ARCH_SHMOBILE_MULTI check in drivers/sh/pm_runtime.c +11:26 #periperi: < geertu> dammsan: what do you mean with "how shall we split the core work then?" +11:27 #periperi: < shimoda> horms: I will send thermal topic to periperi ml +11:27 #periperi: < geertu> I have PFC and CPG in renesas-drivers#topic/... +11:27 #periperi: < dammsan> i can deal with igeertu: i meant how to handle development of PFC and CPG +11:28 #periperi: < dammsan> morimoto: are you doing ok with PFC? +11:28 #periperi: < dammsan> do you need any help? +11:28 #periperi: < geertu> Simon has integration in renesas#topic/... +11:28 #periperi: < morimoto> I think I can send next version of PFC tommorrow +11:28 #periperi: < morimoto> I need to check PFC macro on BockW +11:28 #periperi: < dammsan> morimoto: why don't you reorder things to add your cleanup as incremental patch? +11:29 #periperi: < dammsan> or does the code become better if you make the cleanup first? +11:29 #periperi: < geertu> TOpic 2. Topic/branch/merge organization of Gen3 work, +11:29 #periperi: < dammsan> i guess i don't understand the need for the dependency +11:29 #periperi: < dammsan> geertu: can we discuss CPG development later? +11:29 #periperi: < geertu> The cleanup changes the name of a macro +11:30 #periperi: < geertu> sure +11:30 #periperi: < geertu> (in topic 4?) +11:30 #periperi: < dammsan> sure, sorry!! +11:31 #periperi: < dammsan> it is of course up to morimoto-san to decide about his cleanups +11:31 #periperi: < geertu> Apart from the macro cleanup, I think PFC should switch to an incremental model, at least for inclusion in renesas-drivers +11:31 #periperi: < geertu> same for integration +11:32 #periperi: < horms> geertu: can you clarify what you mean by incremental? +11:32 #periperi: < dammsan> geertu: from when? +11:32 #periperi: < geertu> What's ultimately submitted would be an interactive rebase result of the initial patches and the incrementals +11:32 #periperi: < dammsan> that means you consider it stable enough soon? +11:32 #periperi: < geertu> It doesn't make sense to keep on resubmitting (almost) the same series to the list, with a few pingroup entries (pfc) or device nodes (dtsi) added +11:33 #periperi: < horms> true +11:33 #periperi: < geertu> No one's gonna take patches before rc1 is released +11:33 #periperi: < horms> from my pov a small(ish) base patch is a good start that can be reviewed +11:33 #periperi: < geertu> while we want to keep developing, not rebasing and resubmitting +11:33 #periperi: < horms> as can any incremental patches that add needed support +11:34 #periperi: < horms> that way we review what we are using (which is probably smaller than everything) +11:34 #periperi: < horms> and by implication deffer reviewing the rest +11:34 #periperi: < geertu> So I'm happy seeing e.g. topic/gen3-cpg-v5 +11:34 #periperi: < horms> in my opinion that makes sense particularly at this busy time +11:35 #periperi: < dammsan> i'm confused +11:35 #periperi: < dammsan> =) +11:35 #periperi: < dammsan> so what would you prefer? can you repeat please? +11:35 #periperi: < geertu> Of course we must make sure to have the base (refferred to by device nodes) covered, which is interrupts, clocks, and dmas +11:36 #periperi: < dammsan> geertu: but the base is not yet stable right? +11:36 #periperi: < geertu> It more or less is. +11:36 #periperi: < geertu> Except for the pesky clock-output-names +11:36 #periperi: < dammsan> yes, and that is used by every node =) +11:36 #periperi: < geertu> if we have to re-add them to the mstp nodes, that means it affects many patches +11:37 #periperi: < dammsan> right +11:37 #periperi: < dammsan> PFC seems much close at this point +11:37 #periperi: < geertu> indeed +11:38 #periperi: < geertu> For supporting other devices, there are usually two parts: +11:38 #periperi: < geertu> a. driver update (can be just a new DT compatible value added to the bindings) +11:38 #periperi: < geertu> b. integration (dtsi and defconfig) +11:38 #periperi: < geertu> a. is fairly independent, and I can take that in renesas-drivers#topic/... +11:39 #periperi: < geertu> b. is for Simon's renesas#topic/... +11:39 #periperi: < dammsan> b probably needs to be ordered right? +11:39 #periperi: < geertu> but usually each new patch depends contextually on the previous one +11:39 #periperi: < horms> yes, that seems likely +11:39 #periperi: < geertu> which means it must be "correct" when Simon applies it. +11:40 #periperi: < geertu> While a. I can easily update/replace +11:41 #periperi: < dammsan> we need to expose both a and b to a larger audience IMO +11:41 #periperi: < geertu> Right now the b.'s are stuck on clock-output-names +11:41 #periperi: < dammsan> yes +11:41 #periperi: < geertu> so all of them may need rework +11:41 #periperi: < dammsan> i agree with that observation +11:42 #periperi: < dammsan> but upstreaming of "a" can happen independently anyway +11:42 #periperi: < geertu> The a.'s can follow the standard patch submission rules to maintainers when deemed stable +11:42 #periperi: < geertu> yep +11:42 #periperi: < dammsan> so where are we with the core driver bits ("a")? +11:42 #periperi: < geertu> The b.'s have to go in through Simon's tree, right +11:43 #periperi: < horms> that is their upstream path +11:43 #periperi: < horms> for topic branches things are less fixed imho +11:43 #periperi: < geertu> scif just needs a vinding update +11:43 #periperi: < geertu> s/vinding/binding/ +11:43 #periperi: < geertu> so that can go upstream after rc1 +11:43 #periperi: < dammsan> geertu: the silliness of SCIF2 is that included in that summary? =) +11:44 #periperi: < geertu> same for gpio +11:44 #periperi: < shimoda> dammsan: some timers and dmaengnie? +11:44 #periperi: < dammsan> shimoda: sure +11:44 #periperi: < horms> is scif2 secret; if so should it be omitted from mainline? +11:44 #periperi: < dammsan> secred irda, haha, what is this, 1984? +11:44 #periperi: < geertu> it's the console. So we have a secret black box the user is interacting with :-) +11:45 #periperi: < horms> figures +11:45 #periperi: < dammsan> but seriously, how do we handle DT in case of SCIF2? +11:45 #periperi: < dammsan> is that a I/O group problem perhaps? =) +11:45 #periperi: < geertu> We have the missing interrupt from an older datasheet, and the driver needs it +11:46 #periperi: < geertu> DT is integration, not I/O ;-) +11:46 #periperi: < geertu> so byebye secrecy +11:46 #periperi: < horms> sounds awkward +11:46 #periperi: < dammsan> hm, i thought every per-driver DT binding doc was part of driver development +11:47 #periperi: < dammsan> i was also hoping geert to make sure the r8a7795 SCIF DT binding doc went upstream +11:47 #periperi: < dammsan> together with the DMA bits +11:47 #periperi: < geertu> sure, after rc1 +11:47 #periperi: < dammsan> sure, no stress +11:47 #periperi: < geertu> GregKH may already take scif-misc-v3, but only after rc1 +11:48 #periperi: < dammsan> ok +11:48 #periperi: < horms> so this secreat irq, would be described in dt +11:48 #periperi: < geertu> What special DT binding is there for SCIF2? +11:48 #periperi: < geertu> The driver needs an IRQ +11:48 #periperi: < dammsan> so we don't have any particular devices to focus on now except the CPG and PFC? +11:48 #periperi: < horms> was that circulated publicly before we found out it was secret? +11:48 #periperi: < horms> (we can punt this topic if you like) +11:48 #periperi: < dammsan> geertu: i meant that we may have to special case it +11:49 #periperi: < dammsan> in the DT binding doc +11:49 #periperi: < dammsan> if it is special somehow +11:49 #periperi: < dammsan> (reminds me that i have to resend that CMT series) +11:49 #periperi: < geertu> v0.50 is from end of July, right? +11:49 #periperi: < horms> yes, iirc +11:49 #periperi: < horms> 21st July iirc +11:50 #periperi: < geertu> First public scif2 in r8a7795.dtsi is from Aug 6 +11:50 #periperi: < dammsan> isn't it easy just to omit SCIF2? +11:50 #periperi: < geertu> So Morimoto-san should have known ;-) +11:50 #periperi: < dammsan> we can use HSCIF instead? +11:50 #periperi: < geertu> It's the console +11:50 #periperi: < dammsan> sometimes we can use other SCIF block on same pins +11:51 #periperi: < geertu> No, serial-0 only does scif2, I think +11:51 #periperi: < dammsan> wtf +11:51 #periperi: < dammsan> so shall we aim for DEBUG1 then? =) +11:52 #periperi: < dammsan> but seriously, what a mess +11:52 #periperi: < geertu> we can bitbang SDHI2 WP/CD on those lines +11:52 #periperi: < geertu> or GPIO ;-) +11:52 #periperi: < geertu> U-boot uses scif2 +11:52 #periperi: < dammsan> hehe, must be better +11:52 #periperi: < dammsan> but u-boot is not interrupt driven =) +11:53 #periperi: < geertu> Obviously the interrupt is working +11:53 #periperi: < horms> if a patch can already be found by google then it ain't no secret anymore +11:53 #periperi: < dammsan> maybe we should just ask for update for the SCIF2 interrupt +11:53 #periperi: < dammsan> update for the deocumentation +11:53 #periperi: < dammsan> shimoda: morimoto: can we request update? +11:53 #periperi: < dammsan> this is silly +11:54 #periperi: < geertu> Are we actually using scif2, or are we using irda? +11:54 #periperi: < geertu> The MSTP clock indicates irda +11:54 #periperi: < geertu> and irda usually is scif-compatible +11:54 #periperi: < dammsan> we have non-SCIF compatible IRDA as well +11:54 #periperi: < shimoda> dammsan: sure, I or Morimoto-san request it +11:55 #periperi: < dammsan> shimoda: thanks please check about SCIF2 interrupt +11:55 #periperi: < dammsan> so it seems that the integration series is blocked on both CPG and SCIF2 +11:56 #periperi: < geertu> hurray +11:56 #periperi: < geertu> Hence incrementals for now +11:56 #periperi: < dammsan> at least we have hardware now +11:56 #periperi: < geertu> BTW, who's "Europe engineer"? +11:56 #periperi: < dammsan> geertu: i think i should do one major resend in v9 +11:57 #periperi: < dammsan> to fix up the things you requested +11:57 #periperi: < horms> we just meed sw to complete the set +11:57 #periperi: < dammsan> or do you prefer to get individual patches? +11:57 #periperi: < dammsan> i mean incremental ones? +11:58 #periperi: < geertu> v9 is integration, so that's up to Simon ;-) +11:58 #periperi: < dammsan> ok, about CPG you prefer incremental then? +11:58 #periperi: < horms> i prefer a fresh patchset if existing patches need updating +11:58 #periperi: < dammsan> ok, fresh patchset it will be then +11:58 #periperi: < horms> incremental is fine for new stuff +11:59 #periperi: < horms> thanks +11:59 #periperi: < geertu> For CPG, you would only update 2/5 clk: shmobile: Add Renesas R-Car Gen3 CPG support? +11:59 #periperi: < geertu> I don't mind if you just send that one +11:59 #periperi: < dammsan> sure, but i think i also missed your comment about 4/5 or something +11:59 #periperi: < dammsan> so > 1 patch -> resend series +12:00 #periperi: < geertu> yep +12:00 #periperi: < geertu> sounds fine +12:00 #periperi: < geertu> Next topic? +12:00 #periperi: < dammsan> if <=1 patch - resend individual patch +12:01 #periperi: < dammsan> sure +12:01 #periperi: < geertu> Topic 3. DMA topology, +12:02 #periperi: < geertu> we have dummy dma nodes now, so "dmas" can be added (albeit untested) +12:02 -!- Irssi: Pasting 8 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +12:02 #periperi: < geertu> R-Car Gen2 had two DMA controllers, which were equivalent. +12:02 #periperi: < geertu> As we dropped the shdma dma-multiplexer when implementing rcar-dmac, +12:02 #periperi: < geertu> DMA slaves were tied to a single DMA controller in .dtsi only. +12:02 #periperi: < geertu> On R-Car Gen3 the three DMA controllers are not equivalent: some DMA slaves +12:02 #periperi: < geertu> can be tied to channels 0-15 (the first instance) only, others can be tied to +12:02 #periperi: < geertu> channels 16-47 (i.e. the second or third instance) only. +12:02 #periperi: < geertu> For the latter, I used the second instance in .dtsi. +12:03 #periperi: < geertu> Do we have a plan to use the third dmac (on Gen3), or the second dmac (on Gen2) +12:03 #periperi: < geertu> ? +12:03 #periperi: < geertu> Is Laurent here? +12:03 #periperi: < dammsan> i have no special policy setting plan, but i'd like to describe the hardware via DT +12:04 #periperi: < geertu> Which means "dmas" should link to all relevant dmac nodes +12:04 #periperi: < geertu> and not just the first one +12:04 #periperi: < dammsan> yes, isn't that what we said during the montpellier peripericon? +12:04 #periperi: < dammsan> hurray for another unstable DTS bit! =) +12:05 #periperi: < geertu> In Montpellier, we said we'd start with links to one dmac, and see how to resolve the rest later +12:05 #periperi: < dammsan> now seems like a great time then +12:06 #periperi: < dammsan> adding more links to DT without driver support does not hurt, does it? +12:06 #periperi: < geertu> How? +12:06 #periperi: < geertu> Now we have +12:06 #periperi: < geertu> dmas = <&dmac1 0x31>, <&dmac1 0x30>; +12:06 #periperi: < geertu> dma-names = "tx", "rx"; +12:07 #periperi: < geertu> We can't easily extend that +12:07 #periperi: < geertu> Would this actually work? +12:07 #periperi: < dammsan> we can not have multiple identical dma-names? +12:07 #periperi: < geertu> dmas = <&dmac1 0x31>, <&dmac1 0x30>, <&dmac2 0x31>, <&dmac2 0x30>; +12:07 #periperi: < geertu> dma-names = "tx", "rx", "tx", "rx"; +12:07 #periperi: < geertu> I'm afraid not +12:07 #periperi: < dammsan> that's how i pictured it +12:08 #periperi: < geertu> It's also related to DMA load balancing +12:08 #periperi: < geertu> And the third dmac may be secret on Gen3 ;-) +12:08 #periperi: < dammsan> we could add some "dma-peer" property to the dma controller to point to the peers +12:08 #periperi: < geertu> Yes, that was one of the options we discussed in Montpellier +12:09 #periperi: < geertu> Perhaps the only sane one +12:09 #periperi: < geertu> Let's hope there are no "evil" DMA slaves that can be tied to the first and second dmac on gen3 +12:09 #periperi: < geertu> while all others tie to second and third +12:10 #periperi: < geertu> or the the first exclusively +12:10 #periperi: < geertu> Anyway, without Laurent I think we should postpone this? +12:10 #periperi: < dammsan> the identical-dma-name proposal would support anything, right? +12:10 #periperi: < geertu> Yes +12:11 #periperi: < geertu> Probably needs updates the core DMA framework +12:11 #periperi: < dammsan> probably yes +12:12 #periperi: < geertu> Topic 4. CPG and boot mode via syscon (or not), +12:12 #periperi: < geertu> Laurent wanted to have a generic (also for non-shmobile) framework to obtain a boot mode value +12:13 #periperi: < geertu> instead +12:14 #periperi: < dammsan> that could perhaps be in gen4 if we have done that upfront +12:14 #periperi: < geertu> yeah +12:14 #periperi: < dammsan> i thought your syscon idea was great +12:15 #periperi: < geertu> The major disadvantage of the syscon idea is that we don't know yet how else we'll use the RST module +12:15 #periperi: < dammsan> but this may slightly overlap with the ES revision bits +12:15 #periperi: < geertu> w.r.t. CPU core management +12:15 #periperi: < dammsan> right +12:15 #periperi: < geertu> THE es bits in a different register on Gen3? +12:15 #periperi: < dammsan> i'm also concerned about RST of I/O devices +12:16 #periperi: < geertu> That's in the MSTP module? +12:16 #periperi: < dammsan> maybe so +12:16 #periperi: < geertu> i.e. more registers for each MSTP node +12:16 #periperi: < dammsan> but how do we perform actual reset? +12:17 #periperi: < dammsan> it is more of a question about how to perform reset instead of DT hardware description +12:17 #periperi: < dammsan> and i think that is similar to the boot mode discussion +12:17 #periperi: < dammsan> we need to figure out how to let the driver get the information +12:17 #periperi: < dammsan> and separate from that +12:17 #periperi: < dammsan> also need to figure out how to describe the hardware in DT +12:17 #periperi: < geertu> You mean resetting individual I/O devices, not the whole system? +12:17 #periperi: < dammsan> yes +12:18 #periperi: < geertu> What's the use case for that? +12:18 #periperi: < dammsan> similar to power domain, but without power savings +12:18 #periperi: < dammsan> it may be nice to get a clean start before probe() =) +12:19 #periperi: < dammsan> no special use case apart from that +12:19 #periperi: < geertu> So each device would have a power-domains property linking to the (generalized) MSTPx.y, not only for clock, but also for reset handling? +12:19 #periperi: < dammsan> at least for boot mode we have a need =) +12:19 #periperi: < dammsan> reset-domains +12:20 #periperi: < geertu> Actually we can have that in power-domains +12:20 #periperi: < dammsan> there is certainly overlap +12:20 #periperi: < geertu> Actually each MSTP clock has a corresponding module reset bit +12:20 #periperi: < dammsan> maybe the MSTP driver an hook up a notifier if there are reset registers present +12:21 #periperi: < geertu> perhaps +12:21 #periperi: < geertu> Sounds like for Gen-4 +12:21 #periperi: < dammsan> and do stuff on BIND and UNBIND or similar +12:21 #periperi: < dammsan> sure +12:21 #periperi: < dammsan> but not _that_ difficult +12:21 #periperi: < dammsan> so about boot mode +12:21 #periperi: < dammsan> what do we do? +12:22 #periperi: < geertu> We can do the syscon way now. +12:22 #periperi: < geertu> Patches are available, need a small update for Gen3 +12:22 #periperi: < geertu> It's easy to decide, in the absence of Laurent +12:22 #periperi: < geertu> ;-) +12:22 #periperi: < dammsan> so with the ES version we decided to go with DT compat string suffix +12:22 #periperi: < dammsan> to handle workarounds for special ES versions +12:23 #periperi: < dammsan> we never got around to runtime modify the DT bits based on ES version though +12:23 #periperi: < geertu> We haven't implemented changing the DT compat string based on probed ES version yet +12:23 #periperi: < dammsan> bingo +12:23 #periperi: < dammsan> =) +12:23 #periperi: < geertu> Do we have a need for ES now? +12:24 #periperi: < dammsan> so if we do that, then can we just deal with the boot mode there instead? +12:24 #periperi: < dammsan> but using syscon may be better +12:24 #periperi: < dammsan> no need for ES handling right now, but it may come up +12:25 #periperi: < dammsan> i'm totally fine with syscon, especially if we use SoC specific compat strings +12:25 #periperi: < geertu> "boot mode there" means purely in C, no DT update needed? +12:25 #periperi: < dammsan> yeah, detecting boot mode from C and stashing it in DT while modifying for ES anyway +12:25 #periperi: < geertu> I can update my syscon patch for Gen3, and resend? +12:26 #periperi: < dammsan> sounds good! +12:26 #periperi: < dammsan> so what is the risk for going the syscon route? +12:26 #periperi: < dammsan> apart from ticking off laurent =) +12:26 #periperi: < dammsan> you mentioned CPU reset +12:27 #periperi: < geertu> + rst: reset-controller@e616000 { +12:27 #periperi: < geertu> + compatible = "renesas,rst-r8a7790", "syscon"; +12:27 #periperi: < geertu> + reg = <0 0xe6160000 0 0x0100>; +12:27 #periperi: < geertu> + }; +12:27 #periperi: < dammsan> looking good!! +12:27 #periperi: < geertu> Does that pose a risk? +12:27 #periperi: < geertu> for future RST use? +12:28 #periperi: < dammsan> not what i can tell +12:28 #periperi: < geertu> cpg node needs +12:28 #periperi: < geertu> renesas,modemr = <&rst 0x60>; +12:29 #periperi: < geertu> Will cook up an incremental patch +12:29 #periperi: < dammsan> seems good to me +12:29 #periperi: < dammsan> thanks! +12:30 #periperi: < geertu> One minute left for +12:30 #periperi: < geertu> Topic 5. Status check for tasks from last meeting - what is remaining? +12:30 #periperi: < dammsan> thanks for uli___ and horms help with GPIO +12:30 #periperi: < horms> i did little +12:30 #periperi: < geertu> Add full (H)SCIF nodes to DT is partially done (need to re-add HSCIF pfc bits to make it work again) +12:30 #periperi: < horms> but its nice to see it moving forwards +12:30 #periperi: < geertu> Add gpio nodes to DT is done, modulo power-domains +12:31 #periperi: < uli___> should i resend that with clock-output-names restored now? :) +12:31 #periperi: < geertu> pfc Add r8a7795 support is wip +12:31 #periperi: < geertu> uli___: please wait, unless you want to game mailing list statistics +12:31 #periperi: < geertu> No changes for other tasks? +12:32 #periperi: < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list +12:33 #periperi: < dammsan> not from me +12:34 #periperi: < shimoda> no update from me +12:36 #periperi: < geertu> OK, thanks for joining! +12:36 #periperi: < morimoto> geertu: my "Europe engineer" was 1st attack : for Laurent, Geert. 2nd attack Ulirch Wolfram +12:36 #periperi: < morimoto> We can send one board to Simon, but there is no paper work for him :) +12:37 #periperi: < dammsan> geertu: about CPG, i wonder what the next step really is +12:37 #periperi: < geertu> No paperwork means no fun, less earned value ;-) +12:37 #periperi: < geertu> dammsan: submit to clock maintainers? +12:38 #periperi: < morimoto> No paperwork No life :P +12:38 #periperi: < geertu> morimoto So Simon can just take a board on a plane? +12:38 #periperi: < dammsan> geertu: about the clks array handling, i think a static array is just fine +12:38 #periperi: < dammsan> in my mind apart from removing a spinlock +12:39 #periperi: < dammsan> it is just about figuring out how to deal with(out) clock-output-names +12:39 #periperi: < geertu> yeah, initially I though it was an array of "struct clk", not pointers +12:39 #periperi: < geertu> s/though/thought/ +12:39 #periperi: < geertu> Wasting a few pointers isn't that important. +12:39 #periperi: < dammsan> we will expand NR if needed on new SoCs ight? +12:39 #periperi: < geertu> I also thought about dropping clock-indices, like Laurent suggested. +12:39 #periperi: < dammsan> and may use a subset of the indices +12:40 #periperi: < geertu> But the reason for them is future expansion, right? +12:40 #periperi: < dammsan> i like having them there +12:40 #periperi: < dammsan> yes +12:40 #periperi: < geertu> Time for lunch here... +12:40 #periperi: < geertu> Bye! +12:40 #periperi: < dammsan> and i also like being able to search in DT files to figure out how things are connected +12:40 #periperi: < dammsan> ok bye bye +12:41 #periperi: < morimoto> geertu: Simon can get board from delivery car +12:41 #periperi: < shimoda> bye! +12:41 #periperi: < morimoto> bye +12:41 -!- morimoto [~user@relprex2.renesas.com] has left #periperi ["ERC Version 5.3 (IRC client for Emacs)"] +12:41 #periperi: < uli___> bye +12:54 #periperi: < horms> sorry to miss the last few minutes of the meeting: i had a minor baby crisis to attend to +13:46 -!- horms [~horms@121-80-213-238f1.hyg1.eonet.ne.jp] has quit [Quit: Leaving] +13:58 #periperi: < pinchartl> geertu: what bothers me with syscon for boot mode handling is that the register isn't part of the syscon IP core +13:59 #periperi: * pinchartl is back in Finland now +14:17 #periperi: < geertu> Welcome back (sort of)! +14:22 #periperi: < pinchartl> sorry for missing today's meeting +14:36 #periperi: < geertu> pinchartl: It is according to Figure 11.1 Block Diagram of RST (Gen3) +14:36 #periperi: < geertu> And 11.1.1 11.1.1 Features +14:36 #periperi: < geertu> The following functions are implemented by RST. +14:36 #periperi: < geertu> Latching of the levels on mode pins when PRESET# is negated +14:36 #periperi: < geertu> Mode monitoring register +14:40 #periperi: * geertu mutex_lock(salvator-x) +14:42 -!- shimoda [~shimoda@relprex3.renesas.com] has quit [Quit: WeeChat 0.4.2] +14:49 #periperi: < pinchartl> geertu: is RST a "syscon" ? +14:49 #periperi: < pinchartl> we have a SYSC IP core +14:49 #periperi: < pinchartl> that one is documented as system controller :-) +14:50 #periperi: < pinchartl> although it looks like a power controller +14:51 #periperi: < pinchartl> syscon is really a mean to stuff all kind of miscellaneous stuff in a catch-all API when standardizing an API would be difficult due to very system-specific features +14:51 #periperi: < geertu> Documentation/devicetree/bindings/mfd/syscon.txt +14:51 -!- Irssi: Pasting 8 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +14:51 #periperi: < geertu> System controller node represents a register region containing a set +14:51 #periperi: < geertu> of miscellaneous registers. The registers are not cohesive enough to +14:51 #periperi: < geertu> represent as any specific type of device. The typical use-case is for +14:51 #periperi: < geertu> some other node's driver, or platform-specific code, to acquire a +14:51 #periperi: < geertu> reference to the syscon node (e.g. by phandle, node path, or search +14:51 #periperi: < geertu> using a specific compatible value), interrogate the node (or associated +14:51 #periperi: < geertu> OS driver) to determine the location of the registers, and access the +14:51 #periperi: < geertu> registers directly. +14:51 #periperi: < pinchartl> the boot mode pins, on the other hand, seems like a quite well-defined function to me +14:51 #periperi: < pinchartl> yes, exactly +14:51 #periperi: < geertu> The watchdog will need alink to one of the RST registers, too +14:52 #periperi: < pinchartl> syscon is really a hack to access registers in unrelated IP cores when creating an API isn't worth it +14:53 #periperi: < pinchartl> by the way +14:53 #periperi: < pinchartl> the syscon driver is registered as a postcore_initcall() +14:54 #periperi: < pinchartl> and the CPG driver uses CLK_OF_DECLARE() +14:54 #periperi: < pinchartl> have you checked the ordering ? +14:55 #periperi: < geertu> The syscon driver is not instantiated +14:56 #periperi: < pinchartl> on ARM64, start_kernel() -> time_init() -> of_clk_init() -> CLK_OF_DECLARE callbacks +14:56 #periperi: < geertu> See syscon_regmap_lookup_by_phandle +14:57 #periperi: < pinchartl> indeed +14:57 #periperi: < geertu> And the node will still bind to a future renesas,rst-r8a7795 driver +14:58 #periperi: < pinchartl> there should be a big red flashing HACK sign in front of that code :-) diff --git a/wiki/Chat_log/20150914-core-chatlog b/wiki/Chat_log/20150914-core-chatlog new file mode 100644 index 0000000..f0242cd --- /dev/null +++ b/wiki/Chat_log/20150914-core-chatlog @@ -0,0 +1,464 @@ +11:03 #periperi: < geertu> Welcome to the Core Group Chat! +11:03 -!- Irssi: Pasting 6 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +11:03 #periperi: < geertu> Agenda: +11:03 #periperi: < geertu> 1. Upcoming Gen3 development for the Core group, +11:03 #periperi: < geertu> 2. Pinctrl submaintenance, +11:03 #periperi: < geertu> 3. DMA topology, +11:03 #periperi: < geertu> 4. CPG and boot mode via syscon (or not), +11:03 #periperi: < geertu> 5. Status check for tasks from last meeting - what is remaining? +11:03 #periperi: < geertu> Topic 1: Upcoming Gen3 development for the Core group, +11:04 #periperi: < dammsan> for myself on my immediate todo i have CPG and IRQC +11:05 #periperi: < geertu> About CPG, I talked to mturquette on IRC +11:05 #periperi: < geertu> He's not on holodays, but "ignoring mailing lists during the merge window" +11:05 #periperi: < geertu> He promised to look into our patches and emails this week. +11:05 #periperi: < dammsan> sweet +11:05 #periperi: < dammsan> thanks +11:05 #periperi: < geertu> s/holodays/holidays/ +11:06 #periperi: < pinchartl> I can get hold of him next week at Linaro Connect if needed +11:06 #periperi: < geertu> Next week is Japanese holidays, too? +11:06 #periperi: < dammsan> yep +11:06 #periperi: < dammsan> i intend to bang my head against CPG later today +11:06 #periperi: < dammsan> have some ideas about how to improve the situation +11:07 #periperi: < dammsan> i will try to avoid updating the integration series this week +11:07 #periperi: < dammsan> unless it turns out to be necessary due to CPG dependencies +11:07 #periperi: < dammsan> seems ok? +11:08 #periperi: < geertu> looks fine, thanks +11:08 #periperi: < dammsan> pinchartl: checking with him face-to-face sounds good +11:08 #periperi: < dammsan> some sort of IRL prod +11:08 #periperi: < geertu> IRQC is used for PMIC only? +11:08 #periperi: < pinchartl> please update me at the end of the week and I'll make sure to check with him next week +11:09 #periperi: < dammsan> pincharl: will put "notify laurent about CPG" in my calendar +11:09 #periperi: < geertu> PMIC is BD9571MWV-M, no driver yet. +11:09 #periperi: < pinchartl> and no datasheet yet ? +11:09 #periperi: < dammsan> i've seen the cover page of the data sheet at some guys desk +11:09 #periperi: < dammsan> it says "PMIC for R-Car Gen3" =) +11:09 #periperi: < geertu> IRQ1n is available on EXIO-D though (QSE 8mm, cfr. Koelsch) +11:09 #periperi: < dammsan> seems like a custom chip +11:10 #periperi: < dammsan> right +11:10 #periperi: < dammsan> i've been wanting to get a bunch of those +11:10 #periperi: < dammsan> sorry for not managing that so far +11:11 #periperi: < dammsan> will put QSE adapter into my calendar on the 28th +11:11 #periperi: < dammsan> before that it is paper work hell including new task lists +11:11 #periperi: < shimoda> about PMIC datasheet, since ROHM needs an export control, we cannot send the datasheet for now +11:12 #periperi: < dammsan> another paper work hell =) +11:12 #periperi: < pinchartl> any estimate regarding when the datasheet will be available ? +11:12 #periperi: < geertu> But our IRQC developer who needs a way to trigger an IRQ is in Japan, right? +11:13 #periperi: < dammsan> yes i think so +11:13 #periperi: < shimoda> pinchartl: sorry I don't know when +11:13 #periperi: < dammsan> also, i'm not 100% sure if it makes sense for linux to support the PMIC +11:13 #periperi: < dammsan> with secure mode, trusted firmware, PSCI and virtualization +11:14 #periperi: < dammsan> but we need external interrupts for sure =) +11:15 #periperi: < dammsan> i intend to play with IPMMU early next month too +11:15 #periperi: < dammsan> but we most likely have a core group meeting before that +11:16 #periperi: < dammsan> everyone else is blocked on lack of physical hardware? +11:16 #periperi: < geertu> or confirmation of datasheets +11:17 #periperi: < geertu> E.g. SCIF DMA RX MID/RID don't work. +11:17 #periperi: < dammsan> right +11:17 #periperi: < pinchartl> no real blocker on my side for now +11:17 #periperi: < dammsan> i would like us to describe the SCIF clocks in more detail in DT if possible +11:17 #periperi: < pinchartl> (it's multimedia only this month as far as I'm concerned anyway) +11:17 #periperi: < dammsan> are we blocked on docs for that too? +11:17 #periperi: < geertu> Like the SCIF_CLK for the BRG? +11:17 #periperi: < geertu> No, not blocked. +11:18 #periperi: < dammsan> yeah, and i'm not sure if there are more clocks too +11:18 #periperi: < geertu> On my list, after SCIF DMA, which I'm working on again/ +11:18 #periperi: < dammsan> excellent +11:18 #periperi: < dammsan> thanks +11:18 #periperi: < pinchartl> SCIF clocks are a bit messed up in DT +11:18 #periperi: < pinchartl> the sci_ick name isn't right +11:18 #periperi: < dammsan> i recall an external SCIF clock on salvator-x +11:18 #periperi: < geertu> Yes, that's for external BRG +11:19 #periperi: < geertu> Same on Koelsch +11:19 #periperi: < pinchartl> I think I have patches for that, let me check +11:19 #periperi: < pinchartl> no, not for the external clock +11:20 #periperi: < pinchartl> but I have a patch that drops the interface clock from the driver +11:20 #periperi: < geertu> THat's a cleanup +11:20 #periperi: < pinchartl> yes +11:20 #periperi: < pinchartl> it breaks DT though as it renames the clock +11:20 #periperi: < pinchartl> but it won't be difficult to add backward compatibility code +11:21 #periperi: < dammsan> maybe we should try to do Gen3 correctly from the start? +11:21 #periperi: < dammsan> whatever that is =) +11:21 #periperi: < pinchartl> yes :-) +11:21 #periperi: < pinchartl> should I rebase the patches and send them ? +11:22 #periperi: < geertu> Yes please +11:22 #periperi: < pinchartl> and let someone take care of backward compatibility ? :-) +11:22 #periperi: < dammsan> can we handle that per-SoC? +11:22 #periperi: < geertu> That complicates the driver +11:22 #periperi: < dammsan> yes, so does DT =) +11:22 #periperi: < geertu> Backwards compatibility is already enough code +11:23 #periperi: < pinchartl> I don't see a need to handle that per-soc +11:23 #periperi: < geertu> Actually this is I/O Group work. right? ;-) +11:23 #periperi: < dammsan> ok, if we can avoid breakage +11:23 #periperi: < dammsan> yes +11:23 #periperi: < pinchartl> indeed +11:23 #periperi: < geertu> Any other upcoming core work? +11:24 #periperi: < dammsan> not from my side +11:24 #periperi: < geertu> THat's a cleanupTopic 2: Pinctrl submaintenance +11:24 #periperi: < horms> perhaps pfc for avb is core work +11:24 #periperi: < geertu> Topic 2: Pinctrl submaintenance +11:24 #periperi: < horms> it seems trivial enough +11:24 #periperi: < horms> i'll try an spin a patch this week +11:24 #periperi: < geertu> the initial pfc patch may have support for it. +11:24 #periperi: < horms> i certainly have a patch that includes it +11:25 #periperi: < geertu> easy +11:25 #periperi: < horms> probably the original public version did too +11:25 #periperi: < horms> i expect the only challange to be my own familiarity with the code +11:25 #periperi: < dammsan> so did you guys figure out who will funnel the code to linusw? +11:25 #periperi: < horms> lets move to topic 2 +11:26 #periperi: < horms> i thought we decided to decide that here :) +11:26 #periperi: < dammsan> right, and i thought we were on 2 already =) +11:26 #periperi: < geertu> As I have topic/r8a7795-pfc-v2, I can take care of that +11:26 #periperi: < geertu> It would be good to have some acks from the maintainer, though +11:26 #periperi: < dammsan> do you need review help? +11:27 #periperi: < dammsan> anything in particular that needs attention i mean? +11:27 #periperi: < geertu> I reviewed most of the incremental patches +11:27 #periperi: < pinchartl> I won't have time to review the data table patches in the near future I'm afraid +11:27 #periperi: < geertu> The initial set seems to work. +11:28 #periperi: < geertu> So I would focus on the incrementals +11:28 #periperi: < pinchartl> in order of decreasing importance, we need to pay attention during review to +11:28 #periperi: < pinchartl> 1. core PFC changes +11:28 #periperi: < geertu> And on questions about macro use (PINMUX_IPSR_NOGP()?) +11:28 #periperi: < pinchartl> 2. functions and groups lists +11:28 #periperi: < pinchartl> 3. data tables +11:28 #periperi: < pinchartl> the second one is part of the DT ABI +11:29 #periperi: < geertu> yep +11:29 #periperi: < dammsan> but we have local acks for most bits right? +11:30 #periperi: < horms> are there also non-gen3 patches floating around. e.g. from Sergei? +11:30 #periperi: < geertu> yes +11:30 #periperi: < geertu> and two bug fixes from me +11:30 #periperi: < horms> ok +11:31 #periperi: < horms> so are you proposing as acting as a submaintainer for all of sh-pfc? (that would be quite fine imho) +11:31 #periperi: < geertu> I can collect gen3 patches and send a PR later, but I would prefer for non-gen3 patches to go through LinusW directly +11:31 #periperi: < dammsan> so schedule wise for the CPG, when do we predict merge to happen? +11:31 #periperi: < dammsan> err s/CPG/PFC/g +11:31 #periperi: < dammsan> PFC for H3 seems quite stable to me +11:32 #periperi: < geertu> Let's say in two weeks (-rc3)? +11:32 #periperi: < dammsan> but i may be way off +11:32 #periperi: < geertu> directly => ack from Laurent, though +11:32 #periperi: < horms> geertu: that would be fine from my pov if Linus is happy with that. But he seemed to ask for a single point of contact for all renesas pfc work +11:32 #periperi: < pinchartl> I think Linus would like us to submaintain all PFC-related patches +11:32 #periperi: < pinchartl> not just the Gen3 patches +11:32 #periperi: < dammsan> geertu: -rc3 or so sounds good +11:33 #periperi: < geertu> OK, then I'll take all +11:33 #periperi: < dammsan> thanks Geert!! +11:33 #periperi: < horms> thanks! +11:34 #periperi: < shimoda> thanks! +11:34 #periperi: < horms> I think it would be best if you explained that to Linus, so he knows what is going on: And Sergei does too +11:34 #periperi: < dammsan> feel free to delegate review work! +11:34 #periperi: < geertu> pinchartl: Is this temporary, or should we update MAINTAINTERS? +11:35 #periperi: < pinchartl> it can be temporary +11:35 #periperi: < pinchartl> depending on what Magnus decides to put on my plate for the future :-) +11:35 #periperi: < morimoto> geertu: what does your "two bug fixes" mean? I know v1 lack 0xF IPSRx macro, but what is 2nd ? +11:36 #periperi: < geertu> bug fixes for non-gen3 +11:36 #periperi: < geertu> [PATCH] pinctrl: sh-pfc: r8a7791/r8a7793: Correct SCIFB1_B SCK MOD_SEL value +11:37 #periperi: < geertu> [PATCH] pinctrl: sh-pfc: r8a7794: Remove bogus SCIF0 SCK pin data +11:37 #periperi: < morimoto> Ahh, OK thanks +11:37 #periperi: < geertu> For gen3 there's also [PATCH 1/2] [RFC] pinctrl: sh-pfc: r8a7795: Add pinmux data for single-function pins +11:37 #periperi: < geertu> waiting for PINMUX_IPSR_NOGP() feedback +11:38 #periperi: < dammsan> pinchartl: i believe future PFC work will go though the core group +11:39 #periperi: < pinchartl> dammsan: I'm part of the core group. it depends on whether you'd like me to work on PFC or not +11:39 #periperi: < morimoto> geertu: waiting feedback from whom ? +11:39 #periperi: < geertu> E.g. the shmobile pintrl maintainer? ;-) +11:39 #periperi: < morimoto> OK, I see +11:40 #periperi: < pinchartl> :-) +11:40 #periperi: < pinchartl> which patch in particular ? +11:40 #periperi: < geertu> r8a7795: Add pinmux data for single-function pins +11:40 #periperi: < geertu> thx! +11:41 #periperi: < dammsan> pinchartl: it seems that your main focus in on multimedia these days, but we of course want some low-bandwidth help with the core stuff too +11:41 #periperi: < dammsan> in the end it much depends on what you like doing +11:41 #periperi: < dammsan> but we can discuss that some other time =) +11:42 #periperi: < pinchartl> dammsan: I'm fine maintaining the PFC driver if you're fine allocating time for the task :-) +11:42 #periperi: < pinchartl> sure +11:42 #periperi: < pinchartl> so let's not modify MAINTAINERS right now +11:42 #periperi: < pinchartl> "Adding some comments to the PINMUX_*() macros would be helpful..." +11:42 #periperi: < pinchartl> I agree with that +11:43 #periperi: < pinchartl> how about documenting the macros first, then it should be straightforward to know which one to use +11:43 #periperi: < pinchartl> _NOGP is used on r8a7778 only +11:44 #periperi: < dammsan> so who can help out with the documentation then? +11:46 #periperi: < pinchartl> (same for _NOGM) +11:46 #periperi: < pinchartl> I don't even remember what _NOGM means :-) +11:46 #periperi: * geertu thought it was just him... +11:47 #periperi: < geertu> Authored by Morimoto-san? +11:47 #periperi: < pinchartl> I'm sure we have pins without a GPIO function on other SoCs than R8A7778 +11:47 #periperi: < geertu> Task added: pfc,v4.4,Improvement documentation +11:47 #periperi: < geertu> Next topic? +11:48 #periperi: < geertu> Topic 3: DMA topology +11:48 #periperi: < geertu> We wanted to discuss this before, but Laurent was not available. +11:48 #periperi: < geertu> This is mostly about having multiple DMACs +11:49 #periperi: < geertu> On Gen2, all SYS-DMAC slaves can use both DMAC0 or DMAC1, but currently DT links them to a single instance only. +11:49 #periperi: < geertu> On Gen3, some SYS-DMAC slaves can work with DMAC0, others with DMAC1 or DMAC2. +11:49 #periperi: < geertu> So far we linked the ones from the second group to DMAC1 only. +11:50 #periperi: < pinchartl> right +11:50 #periperi: < geertu> I tried multiple dmas and dma-names for both "tx" and "rx", and it seems to work (it uses the first DMAC that's available). +11:50 #periperi: < geertu> That was on Gen2 though. +11:51 #periperi: < geertu> On Gen3, MSIOF doesn't seem to work with DMAC2 +11:51 #periperi: < pinchartl> there's a problem in the DMA engine API +11:51 #periperi: < pinchartl> drivers allocate channels too early +11:51 #periperi: < pinchartl> there's no efficient management of DMA channels at runtime +11:52 #periperi: < geertu> E.g. SCIF allocates channels at device (/dev/ttySC*) open time. +11:52 #periperi: < pinchartl> one option would be to allocate the channel only when starting transfers, but that would add an overhead +11:52 #periperi: < geertu> E.g. RSPI and MSIOF allocate them at probe time. +11:52 #periperi: < pinchartl> probe time is early +11:53 #periperi: < geertu> So SCIF supports some dynamic behavior. +11:53 #periperi: < pinchartl> but most drivers don't have a concept of open/close +11:53 #periperi: < pinchartl> especially I2C and SPI +11:53 #periperi: < pinchartl> so that's a core issue we'll need to tackle +11:54 #periperi: < pinchartl> it should be, in theory, independent from DMA description in DT +11:54 #periperi: < geertu> When I added "DMA topology" on the agenda originally, I didn't know yet that MSIOF doesn't work with DMAC2 on Gen3. +11:54 #periperi: < dammsan> geertu: that may be a hardware bug +11:54 #periperi: < geertu> So it may be premature. +11:55 #periperi: < pinchartl> listing all usable channels is one way to go +11:55 #periperi: < pinchartl> it makes DT quite verbose +11:55 #periperi: < pinchartl> but it shouldn't be too bad for Gen2 and Gen3 +11:55 #periperi: < dammsan> pinchartl: you mean in each DMAC DT node? +11:55 #periperi: < geertu> Is DMAC2 "special"? +11:55 #periperi: < geertu> In each slave node +11:55 #periperi: < pinchartl> no I mean in the DMA slave DT nodes +11:56 #periperi: < pinchartl> SCIF, RSPI, MSIOF, ... +11:56 #periperi: < geertu> That would describe the hardware. +11:56 #periperi: < geertu> Especially on Gen3, where you have pairing limits +11:56 #periperi: < geertu> How the software handles that is a different thing, and the complexity seems to lie in the software. +11:57 #periperi: < dammsan> geertu: your DMAC2 issues (or pairing issues) come from real life experience, or from the docs? +11:57 #periperi: < geertu> The DMAC2 issue with MSIOF was on Salvator-X +11:57 #periperi: < geertu> But the doc states which slaves work with DMAC0 (ch 0-15), and which with DMAC1/2 (ch 16-47) +11:57 #periperi: < dammsan> right, but that is a mismatch with the data sheet? +11:58 #periperi: < geertu> With "pairing limits", I meant the line above. +11:58 #periperi: < dammsan> so do we need to feedback something to the hardware guys? +11:58 #periperi: < geertu> I don't know, I haven't tried other DMA slaves. +11:59 #periperi: < geertu> with DMAC2, I mean +11:59 #periperi: < dammsan> ok, perhaps we need to tackle DMA on Gen3 as a separate topic later on +11:59 #periperi: < dammsan> independently of the DMA topology discussion +11:59 #periperi: < geertu> Yes, cfr. "[PATCH] [RFC] arm64: renesas: r8a7795: Complete SYS-DMAC nodes" continuation on periperi mailing list +11:59 #periperi: < dammsan> my assumption has been that Gen3 is not very different from Gen2 +12:00 #periperi: < geertu> Shall we add dmas for all DMACs from now on? +12:00 #periperi: < geertu> And also on Gen2? +12:00 #periperi: < geertu> Or be conservative? +12:01 #periperi: < dammsan> i think starting with Gen3 makes sense +12:01 #periperi: < dammsan> and waiting with Gen2 +12:01 #periperi: < geertu> On Gen2, we have some slaves pointing to DMAC0, and others to DMAC1 +12:01 #periperi: < dammsan> in case we run into issues then we can most likely get support for Gen3 +12:01 #periperi: < geertu> but that's completely arbitrary +12:01 #periperi: < dammsan> I dont think we can get same support level on Gen2 +12:01 #periperi: < dammsan> morimoto: what do you think? +12:02 #periperi: < dammsan> shimoda: what do you think? +12:02 #periperi: < geertu> morimoto-san is too busy with cs2000 ;-) +12:02 #periperi: < dammsan> can we get good support from the hardware guys for Gen2? +12:02 #periperi: < morimoto> about DMAC ? +12:02 #periperi: < dammsan> yeah +12:03 #periperi: < dammsan> i got the impression that everyone was focused on gen3 now so no one cares about gen2 +12:05 #periperi: < morimoto> Oops, do you want HW guys support ? +12:05 #periperi: < morimoto> Sorry what is your request now ? +12:05 #periperi: < dammsan> i want to ask you if you think we have good chance to get Gen2 support +12:06 #periperi: < dammsan> or if you think Gen3 has better chance for support from hardware guys? +12:07 #periperi: < geertu> Do we have Gen2 DMA issues, besides IPMMU? +12:07 #periperi: < shimoda> sorry I don't understand yet. who is the hardware guys? +12:08 #periperi: < dammsan> shimoda: people inside renesas that can answer our questions about DMA hardware for Gen2/Gen3 +12:08 #periperi: < dammsan> geertu: not that i am aware of +12:08 #periperi: < morimoto> I need to check DMA HW guy, but maybe we can ask them (?) +12:08 #periperi: < dammsan> morimoto: so Gen3 and Gen2 is same status? +12:09 #periperi: < morimoto> I don't know at this point +12:09 #periperi: < dammsan> ok, so it is not the same as MSIOF where hardware developer had quit =) +12:09 #periperi: < dammsan> anyway +12:10 #periperi: < dammsan> geertu: what do you think about DMAC DT nodes on Gen2 and/or Gen3? +12:10 #periperi: < geertu> I'd like to link slaves to all DMA engines that can handle it. +12:10 #periperi: < dammsan> i like that +12:11 #periperi: < geertu> As that descrives the hardware. +12:11 #periperi: < dammsan> right +12:11 #periperi: < pinchartl> I'm fine with that +12:11 #periperi: < geertu> My only issue there is DMAC2 +12:11 #periperi: < dammsan> why don't you begin on a board that you have physical access to? +12:11 #periperi: < pinchartl> we have at most two DMACs used by a peripheral, so it's not too bad +12:11 #periperi: < pinchartl> if we had 10 RIDs * 10 DMACs I'd start getting worried +12:12 #periperi: < dammsan> geertu: so what is the latest status about that DMAC2 issue? +12:12 #periperi: < geertu> Isn't that the audio DT? ;-) +12:12 #periperi: < dammsan> we may have to ping something...? +12:12 #periperi: < geertu> I'm afraid DMAC2 is "special", but not documented that way +12:12 #periperi: < geertu> dmac0: dma-controller@e6700000 +12:12 #periperi: < geertu> dmac1: dma-controller@e7300000 +12:12 #periperi: < geertu> dmac2: dma-controller@e7310000 +12:12 #periperi: < geertu> Weird addresses... +12:13 #periperi: < geertu> + DMAC2 didn't work with MSIOF +12:13 #periperi: < dammsan> right +12:13 #periperi: < pinchartl> does DMAC2 work with other peripherals ? +12:13 #periperi: < dammsan> i saw that you sent an email +12:13 #periperi: < geertu> I'll try hscif1 transmit with DMAC2 +12:13 #periperi: < dammsan> but we need to make sure it gets reported +12:13 #periperi: < dammsan> can you forward the report email to periperi once more? +12:14 #periperi: < geertu> Will do, after I've tried hscif2 +12:14 #periperi: < dammsan> thanks! +12:14 #periperi: < dammsan> can you add a task for DMAC2 on Gen3? +12:14 #periperi: < geertu> Will do +12:15 #periperi: < dammsan> thanks!! +12:15 #periperi: < geertu> r8a779[0-4],v4.5,Start adding dmas for all SYS-DMAC engines +12:15 #periperi: < geertu> r8a7795,v4.4,Investigate SYS-DMAC2 +12:16 #periperi: < dammsan> wunderschon +12:16 #periperi: < geertu> Next topic? +12:16 #periperi: < geertu> Topic 4: CPG and boot mode via syscon (or not) +12:16 #periperi: < morimoto> about DMAC we got request from customer +12:16 #periperi: < morimoto> previous BSP used sh-dmac, and customer got many issues. +12:16 #periperi: < dammsan> really? =) +12:17 #periperi: < morimoto> Current BSP is using rcar-dmac, but customer still have issues. +12:17 #periperi: < morimoto> So, customer requesting to us to re-review about rcar-dmac +12:17 #periperi: < dammsan> morimoto: Current BSP = 3.10 ? +12:17 #periperi: < morimoto> it seems 3.10 +12:17 #periperi: < dammsan> no chance +12:17 #periperi: < geertu> Which DMA slaves? SCIF? +12:17 #periperi: < dammsan> ask them to try latest upstream +12:18 #periperi: < morimoto> The issue happen in SDIO/SD +12:18 #periperi: < dammsan> haha +12:18 #periperi: < dammsan> no chance again +12:18 #periperi: < dammsan> tell them to build an open reference implemeentation +12:19 #periperi: < dammsan> (sorry for being harsh morimoto-san) +12:19 #periperi: < morimoto> I know 3.10 is no chance, but we can't tell it to customer +12:19 #periperi: < horms> we can talk to Komatsu-san in a less frank manner :) +12:20 #periperi: < pinchartl> morimoto: that's related to the e-mail you have sent me, right ? +12:20 #periperi: < pinchartl> "R-CarGen2 sdhi/rcar-dmac 不具合報告" +12:20 #periperi: < morimoto> Yes, it is one of them +12:21 #periperi: < morimoto> I don't know who should handle this (in Renesas, in upstream) +12:21 #periperi: < morimoto> This is just information for Core group +12:22 #periperi: < dammsan> morimoto: we need dedicated SD/MMC resource +12:22 #periperi: < dammsan> and 1 year of development +12:22 #periperi: < dammsan> after that we can talk again +12:22 #periperi: < dammsan> think gen4 =) +12:24 #periperi: < dammsan> morimoto: do we know any other DMAC issue? +12:24 #periperi: < morimoto> Sakato-san has details. +12:26 #periperi: < dammsan> morimoto: ok, thanks, i'll ask him during dinner next month +12:26 #periperi: < morimoto> thanks +12:26 #periperi: < geertu> We're running out of time... +12:26 #periperi: < geertu> Topic 4: CPG and boot mode via syscon (or not) +12:26 #periperi: < geertu> Do we proceed? +12:27 #periperi: < dammsan> i think the DT binding for the reset controller is a good thing without doubt +12:27 #periperi: < geertu> I think we can postpone the #reset-cells until we want to make use of it +12:28 #periperi: < dammsan> yeah +12:28 #periperi: < dammsan> using syscon would allow us to use DT for something relatively soon +12:28 #periperi: < dammsan> a special new API would take more time +12:28 #periperi: < dammsan> and would require us to either postpone stuff or do it incrementally +12:29 #periperi: < pinchartl> could we propose an API and see how that goes ? +12:29 #periperi: < dammsan> pinchartl: do you have time to work on a new API? +12:29 #periperi: < dammsan> i assume you are starved for time =) +12:30 #periperi: < pinchartl> have you seen at what time I've sent the DU+VSP release yesterday ? :-) +12:30 #periperi: < dammsan> i know i know +12:30 #periperi: < dammsan> thanks for that +12:30 #periperi: < geertu> Laurent only works during weekends ;-) +12:30 #periperi: < dammsan> so i feel that both you, geert and horms are pulling your weight as-is with Gen3 +12:30 #periperi: < pinchartl> oh, yes, and it was a Sunday +12:30 #periperi: < pinchartl> I tend to forget about days of the week :-) +12:31 #periperi: < dammsan> if we have some idle hands then perhaps those could help with that API? +12:31 #periperi: < geertu> You need kids to introduce structure and stability into your life ;-) +12:31 #periperi: < pinchartl> and sleep deprivation +12:31 #periperi: < horms> i have some cycles to donate to the cause +12:31 #periperi: < pinchartl> ah, wait, I have that already :-) +12:31 #periperi: < geertu> Don't drop the kids at school on Sunday morning ;-) +12:32 #periperi: < geertu> Topic 5: Status check for tasks from last meeting - what is remaining? +12:32 #periperi: < pinchartl> I think I'd rather fetch them from school on Sunday evening ;-) +12:32 #periperi: < geertu> I don't think there's any task we can really close. +12:32 #periperi: < pinchartl> so regarding the CPG, can someone propose an API ? +12:32 #periperi: < dammsan> geertu: i agree +12:32 #periperi: < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list +12:32 #periperi: < dammsan> i will cook up an updated CPG series today +12:33 #periperi: < geertu> Many tasks are at 99%, but blocked by clock-output-names +12:33 #periperi: < dammsan> no shit +12:33 #periperi: < geertu> I'm a bit reluctant to resend patch series with just removed/added clock-output-names +12:34 #periperi: < geertu> before we have a conclusion +12:34 #periperi: < dammsan> me too +12:34 #periperi: < dammsan> i think it is fine to keep things as-is +12:34 #periperi: < dammsan> geertu: can you incorporate the patch series from laurent into your next release? +12:34 #periperi: < geertu> VSP I can +12:35 #periperi: < geertu> DU has an unknown base +12:35 #periperi: < geertu> Cfr. my email response +12:35 #periperi: < pinchartl> it's the 20150913 tag base :-) +12:35 #periperi: < pinchartl> I think it's the drm-next branch from Dave Airlie's tree +12:35 #periperi: < dammsan> hehe +12:35 #periperi: < geertu> Thanks, I'll include vsp1-kms-gen3-20150913 +12:35 #periperi: < pinchartl> I'll double-check that +12:35 #periperi: < geertu> drm-misc, but some patches from your previous vsp1-kms branch +12:36 #periperi: < pinchartl> there are two DRM core fixes in vsp1-kms-gen3-20150913 not part of the DU patch series sent to the mailing list +12:36 #periperi: < geertu> OK, I'll just take vsp1-kms-gen3-20150913 +12:36 #periperi: < geertu> dammsan: I'll do that after your CPG update? +12:36 #periperi: < pinchartl> would you like me to rebase everything on top of the latest upstream branches and tag vsp1-kms-gen3-20150914 ? +12:37 #periperi: < dammsan> geertu: give me until tomorrow +12:37 #periperi: < geertu> Then I'll update topic/gen3-latest with Laurent's vsp-kms first +12:37 #periperi: < dammsan> if i didn't manage to produce anything useful then please proceed without me =) +12:37 #periperi: < dammsan> sure +12:37 #periperi: < dammsan> sounds good +12:37 #periperi: < geertu> I guess vsp1-kms-gen3-20150913 is OK +12:39 #periperi: < dammsan> so what is the conclusion about CPG and boot mode? +12:40 #periperi: < geertu> Proceed +12:41 #periperi: < pinchartl> proceed with what ? :-) +12:41 #periperi: < geertu> syscon/rst +12:41 #periperi: < geertu> It's what syscon was invented for +12:42 #periperi: < geertu> I don't want to propose an API we can use next year +12:42 #periperi: < dammsan> so simon said he has some hands to lend +12:42 #periperi: < dammsan> it seems to me that syscon is short term +12:42 #periperi: < dammsan> and "the other API" is more long term +12:42 #periperi: < geertu> Oops, seems I missed that +12:43 #periperi: < pinchartl> nobody wants an API we can use in a year +12:43 #periperi: < pinchartl> but if we never propose one we'll never know when we can use it +12:43 #periperi: < pinchartl> it might be that it will go smoothly and quickly +12:43 #periperi: < dammsan> pinchartl: i agree +12:43 #periperi: < pinchartl> I'd like to at least try +12:43 #periperi: < dammsan> so pinchartl and horms can give it a go? +12:43 #periperi: < dammsan> and in the mean time? +12:43 #periperi: < pinchartl> if it ends up taking ages to solve the bikeshedding issues, sure, we can then go for plan B +12:44 #periperi: < horms> dammsan: sure +12:44 #periperi: < dammsan> so when is the cutoff date? +12:44 #periperi: < pinchartl> horms: if you can send an RFC and CC me I can follow up on it and assist during review. would that be ok ? +12:45 #periperi: < horms> sure, I'll see what i can do +12:45 #periperi: < geertu> OK, let's see +12:45 #periperi: < dammsan> so we are still aiming PFC at v4.4, right? +12:45 #periperi: < dammsan> and same for CPG i think? +12:46 #periperi: < geertu> yes +12:46 #periperi: < dammsan> does that mean that this new API needs to have some sort of agreement before that? +12:46 #periperi: < geertu> yes +12:47 #periperi: < geertu> else we'll have code for both on gen3 +12:47 #periperi: < dammsan> geertu: but your reset controller can be done in parallel with this, right? +12:47 #periperi: < geertu> and gen4 will be legacy-free +12:47 #periperi: < dammsan> geertu: i mean the DT bits +12:47 #periperi: < geertu> The rst node is OK +12:47 #periperi: < geertu> It's the syscon,modemr property we'll have to support in parallel +12:48 #periperi: < dammsan> that's plan B +12:48 #periperi: < dammsan> does this result in some tasks? =) +12:48 #periperi: < geertu> You want tasks? +12:48 #periperi: < dammsan> seems like a sane way to store our agreement? +12:48 #periperi: < pinchartl> I'm totally fine with using syscon internally for now, but I'd like to avoid pushing that upstream if we can come up with a proper API in a reasonable time frame +12:49 #periperi: < dammsan> pinchartl: so what is reasonable to you? +12:50 #periperi: < pinchartl> what is our current target ? v4.4 or v4.5 ? +12:50 #periperi: < geertu> "generic,v4.4,Propose API to obtain mode pin values in a a generic way" task added +12:50 #periperi: < geertu> v4.4 +12:50 #periperi: < pinchartl> let's see if it's possible for v4.4. the discussion needs to be started sooner than later then +12:51 #periperi: < pinchartl> and then let's decide based on the feedback +12:51 #periperi: < dammsan> oh yeah +12:51 #periperi: < geertu> ok +12:51 #periperi: < dammsan> we can agree that syscon is a good plan B? +12:52 #periperi: < pinchartl> well, it's the only backup plan I see :-) +12:52 #periperi: < dammsan> we have the built-in register access in the CPG right now +12:52 #periperi: < dammsan> which is ultra-short-term +12:53 #periperi: < dammsan> pinchartl: for the new API, can you target Gen2? +12:53 #periperi: < dammsan> the CPG there is also using the boot mode +12:53 #periperi: < pinchartl> built-in register access has the advantage of not creating DT backward compatibility problems +12:53 #periperi: < dammsan> i agree +12:53 #periperi: < pinchartl> in my opinion that would be better than syscon +12:54 #periperi: < pinchartl> if, for instance, the API can be merged for v4.5 +12:54 #periperi: < pinchartl> we could merge built-in register access for v4.4 and replace it in v4.5 +12:54 #periperi: < dammsan> it all depends on when the API is avaliable +12:54 #periperi: < pinchartl> if it's v4.20 then it's another story of course +12:54 #periperi: < pinchartl> sure, we can target Gen2 +12:54 #periperi: < dammsan> great! +12:54 #periperi: < dammsan> thanks +12:54 #periperi: < geertu> The original "[PATCH/RFC 00/11] ARM: shmobile: Let CPG use syscon for MD pin values" has backwards compatibilty on Gen2 +12:55 #periperi: < geertu> Time to terminate the meeting? +12:56 #periperi: < dammsan> you're getting hungry? =) +12:56 #periperi: < geertu> How do you gues that? +12:56 #periperi: < dammsan> hihi +12:56 #periperi: < geertu> The brain needs sugar to function ;-) +12:56 #periperi: < dammsan> well thanks for today +12:56 #periperi: < geertu> yes, thanks all for joining! +12:56 #periperi: < dammsan> enjoy your lunch +12:56 #periperi: < dammsan> bye bye +12:56 #periperi: < geertu> Enjoy your evening! +12:56 #periperi: < horms> dammsan: can we talk tomorrow? +12:57 #periperi: < shimoda> bye! +12:57 #periperi: < morimoto> bye +12:57 #periperi: < uli___> bye +12:57 #periperi: < pinchartl> morimoto: I'll send you a tentative (untested) fix for the rcar-dmac issue +12:57 #periperi: < morimoto> Thank you diff --git a/wiki/Chat_log/20150915-io-chatlog b/wiki/Chat_log/20150915-io-chatlog new file mode 100644 index 0000000..46d120a --- /dev/null +++ b/wiki/Chat_log/20150915-io-chatlog @@ -0,0 +1,146 @@ +--- Log opened Tue Sep 15 10:53:24 2015 +10:53 -!- wsa_ [~wsa@p4FE2521C.dip0.t-ipconnect.de] has joined #periperi +10:53 -!- Irssi: #periperi: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal] +10:53 -!- Irssi: Join to #periperi was synced in 0 secs +10:53 < wsa_> hi there! +10:54 < geertu> hi +10:54 < shimoda> hi! +10:57 < geertu> horms: The runtime dependencies in me/r8a7795-ravb-driver-and-integration-v2.runtime are now in -next +11:00 -!- horms [~horms@121-80-213-238f1.hyg1.eonet.ne.jp] has joined #periperi +11:00 < wsa_> horms: perfect timing :) +11:00 < wsa_> morimoto: you there? +11:00 < horms> hi +11:00 < morimoto> yes +11:00 < wsa_> \o/ +11:00 < geertu> horms: The runtime dependencies in me/r8a7795-ravb-driver-and-integration-v2.runtime are now in -next +11:01 < horms> nice +11:02 < wsa_> so, let's start, shall we? +11:02 < wsa_> mostly Gen3 related topics on the list, what a surprise +11:03 < wsa_> as i understand, the SPI patches are around but not fully tested due to not connected HW, right? +11:03 < geertu> Correct +11:04 < wsa_> and HSCIF and USB func patches are due next week according to our todo-list. is that still true? +11:04 < geertu> I ran spidev_test on MSIOF +11:04 < geertu> it seems to work, as far as I can tell from this limited test, both with and without DMA +11:04 < geertu> HSCIF works, but I haven't resend the patches as all of this depends on the clock-output-names +11:05 < geertu> (to be or not to be, that is) +11:05 < wsa_> yes +11:07 < wsa_> shimoda-san: what about the thermal driver for Gen3? When is it expected? +11:08 < shimoda> wsa_: this needs end of Nov. in the Gen3 BSP +11:08 < wsa_> And related: Does somebody know of an updated documentation somewhen soon maybe perhaps? :) +11:08 < wsa_> end of November, noted +11:08 < geertu> Newer than 0.50E? +11:09 < wsa_> yes +11:09 < wsa_> like with the converstion table for the thermal unit :) +11:09 < horms> i believe he is specifically referring to thermal documentation +11:10 < wsa_> I recall morimoto-san said somewhen something about v0.8 being in the making, but I may be wrong there... +11:11 < morimoto> Now datasheet team is creating v0.8, but I don't know when we can get it +11:11 < wsa_> ok +11:12 < wsa_> I'm cheering for them ;) +11:12 < morimoto> Of course I will forward it to you guys ASAP +11:12 < wsa_> End of November is also the deadline for the PCIe driver, right? +11:13 < wsa_> which needs ARM64 updates +11:13 < shimoda> wsa_: about PCIe, yes +11:14 < shimoda> BSP team are investigating the PCIe driver to use it on gen3 +11:14 < geertu> I think there are other examples of PCI drivers converted from arm32 to arm32+arm64 +11:15 < shimoda> at the moment, it doesn't work (pcie device (giga nic) is not enumerated ) +11:16 < shimoda> geertu: i think so +11:17 < wsa_> yes, iproc-driver at least +11:18 < wsa_> so, BSP team currently researches +11:18 < wsa_> is there anything we can do right now? +11:19 < wsa_> regarding PCIe +11:20 < wsa_> I'd think it makes sense to wait until our boards arrive +11:20 < wsa_> or is that too late? +11:20 < horms> it would be nice to have a plan B in place, IMHO +11:21 < morimoto> About boards, it is under export paper work dark side. +11:21 < geertu> If Magnus plugs in a PCIe card, it can be done remotely? +11:21 < morimoto> This is secret, but who goes to ELCE ? +11:21 * wsa_ goes +11:21 < morimoto> Our last plan is ELCE +11:21 * geertu goes +11:21 < horms> not strictly relevant, but i am not planning to attend in person +11:22 < geertu> by proxy? +11:22 < morimoto> Hand Carry is not allowed, but... +11:22 < horms> geertu: i may phone in if you guys have a meeting +11:22 < wsa_> i did some enumeration debugging remotely once +11:22 < geertu> s/if/when/ +11:22 < morimoto> Simon is no problem, beacuse you are in Japan :) +11:23 < wsa_> so we could ask Magnus about adding a PCIe card +11:23 < wsa_> I will do this +11:23 < geertu> wsa_: Do you have a PCIe analyzer? +11:23 < shimoda> wsa_: thanks! +11:24 < wsa_> geertu: nope, just a logic analyzer (OpenLogicSniffer) +11:24 < wsa_> dunno how fast it can go +11:25 < wsa_> shimoda-san: what would you say has higher priority? pcie or thermal? +11:26 < shimoda> IMO, thermal is higher priority because it is a new driver +11:27 < shimoda> Gen3 PCIe is similar with gen2, but gen3 thermal is not similar with gen2 +11:27 < wsa_> yes, makes sense +11:29 < wsa_> i will probably have time for this in october +11:29 < horms> for thermal or ePCI or both? +11:29 < wsa_> i assume most of you are busy with core stuff, multimedia stuff, paperwork... +11:31 < morimoto> paperwork... +11:31 < wsa_> i hope for both +11:31 < horms> nice +11:32 < wsa_> are there any other things which need to be working by end of november? +11:34 < shimoda> let me see... +11:36 < shimoda> sd/emmc, sata, pwm, hscif +11:37 < shimoda> and etheravb with ptp driver +11:38 < geertu> etheravb works +11:38 < geertu> thanks to Simon +11:39 < horms> yes, but I suspect ptp is a bit of a can of worms +11:40 < wsa_> SATA seems to be backwards compatible +11:41 < wsa_> SD needs some features, from the task list: "SDHI/Gen3,?,Add support for DMA, MMC, MMC-HS200/400 speeds" +11:41 < shimoda> wsa_: yes, bsp team also works gen3 sata +11:44 -!- geertu [~geert@d54C36A7B.access.telenet.be] has quit Ping timeout: 264 seconds +11:46 < wsa_> shimoda-san: speaking of PWM, could you ping Thierry about your driver? Maybe he forgot... +11:46 < wsa_> i need to do the same for my IP core switching patches +11:47 < shimoda> wsa_: yes, i will ping Thierry +11:47 < wsa_> thanks! +11:48 < wsa_> ok, that were all points I know of +11:48 < wsa_> is there something more? +11:48 < horms> EtherAVB, basic, support is moving forwards slowly +11:49 < horms> the main wildcard is Sergei +11:49 < horms> I am still aiming for 4.4 for the driver changes +11:50 < horms> And I plan to post the missing PFC update for EtherAVB very soon now +11:51 < wsa_> great +11:51 < horms> -- end -- +11:51 < shimoda> nice! +11:51 < wsa_> and sergei will make sure your patches will have proper whitespacing :/ +11:51 < horms> thats right +11:51 < horms> even if they are just moving code around +11:52 -!- geertu_ [~geert@188.189.10.202] has joined #periperi +11:52 < wsa_> welcome back, geert +11:53 < geertu_> Sorry, ISP total failure (Internet/TV/Dadio) +11:53 < geertu_> Did I miss much? +11:54 < geertu_> Last thing I saw was SATA +11:54 < wsa_> not much +11:55 < wsa_> Simon reported shortly on EtherAVB; aims for driver changes in 4.4, will add PFC soon +11:55 < geertu_> ok +11:55 < wsa_> and then we have basic support \o/ +11:55 < wsa_> geertu_: what is the status of your SCIF patch series? +11:56 < geertu_> Working on it. I received a few patches from Visteon to improve it. +11:56 < geertu_> With that, DMA is much more stable. +11:56 < geertu_> Have to do some more tests to find out which patches are critical. +11:57 < geertu_> My plan is to submit a scif-dma-v4 later this week. +11:57 < geertu_> After that, I'll tackle the external baud generator. +11:58 < wsa_> interesting +11:59 < wsa_> will be nice to see what improves DMA stability +12:00 < wsa_> is there a deadline for the baud generator? +12:00 < geertu_> not that I'm aware of +12:01 < geertu_> It's part of the general SCIF improvements +12:01 < wsa_> ok +12:02 < wsa_> i'll mark it as v4.5 just to get rid of the '?' +12:02 < wsa_> so we know it is a requested feature +12:03 < wsa_> thanks, geert +12:03 < wsa_> are we done then? +12:03 < horms> nothing more from me +12:04 < geertu_> same here +12:04 < morimoto> same here +12:04 < shimoda> same here +12:04 < wsa_> then, let's call it a day +12:05 < wsa_> thanks everyone! +12:05 < horms> thanks +12:05 < geertu_> thx, bye! +12:06 < morimoto> bye +12:06 < shimoda> bye! +12:06 -!- morimoto [~user@relprex1.renesas.com] has left #periperi ["ERC Version 5.3 (IRC client for Emacs)"] +--- Log closed Tue Sep 15 12:10:39 2015 diff --git a/wiki/Chat_log/20150929-core-chatlog b/wiki/Chat_log/20150929-core-chatlog new file mode 100644 index 0000000..73b2a81 --- /dev/null +++ b/wiki/Chat_log/20150929-core-chatlog @@ -0,0 +1,456 @@ +11:04 < geertu> Agenda: +11:04 < geertu> 1. Upcoming Gen3 development for the Core group, +11:04 < geertu> 2. "clock-output-names", +11:04 < geertu> 3. [PATCH/RFC v2 0/4] Renesas CPG/MSTP DT Binding Proposal, +11:04 < geertu> 4. sh-pfc, +11:04 < geertu> 5. Status check for tasks from last meeting - what is remaining? +11:04 < geertu> Topic 1. Upcoming Gen3 development for the Core group +11:05 < dammsan> I'm poking around with IPMMU +11:05 < geertu> Good to hear +11:05 < geertu> Is it fun? +11:05 < dammsan> well... +11:05 < dammsan> there is some external patch series that enabled IOMMU for arm64 +11:06 < dammsan> so we have a dependency there +11:06 < dammsan> and on gen3 there is FCPVD +11:06 < dammsan> together with VSPD +11:06 < dammsan> and i noticed that on Gen2 the DU is tied to two micro-tlbs +11:07 < dammsan> on R-Car H2 +11:07 < dammsan> so we may need to rework the driver slightly to support that +11:07 < dammsan> anyway, i intend to post some prototype patches later on this weekk +11:09 < horms> what is the origin of the "external patch series" and what it its status? +11:10 < dammsan> [PATCH v5 0/3] arm64: IOMMU-backed DMA mapping +11:10 < dammsan> by Robin Murphy from ARM +11:10 < dammsan> at this point I am mainly interested in testing the hardware +11:11 < dammsan> and adjusting the driver on a prototype basis if needed +11:11 < dammsan> but over time we may have to step up and contribute to fix the architecture and subsystem perhaps +11:11 < horms> ok, seems likely +11:12 < dammsan> but mr conspiracy-theory thinks this must be highly political +11:12 < dammsan> and a perfect way to block progress +11:12 < horms> why else whould something exist? +11:12 < dammsan> right =) +11:13 < dammsan> this may give us some time to fix up Gen2 though +11:14 < horms> no problems; only opportunities +11:15 < dammsan> so IPMMU and the IOMMU subsystem needs some attention for sure at least +11:15 < dammsan> together with that DMA Engine with IOMMU issue +11:15 < geertu> Any feedback about that from the hardware team? +11:15 < dammsan> not yet +11:15 < dammsan> i have not pinged them yet +11:16 < dammsan> but i did not trigger any issue once i implemented that identity mapping hack +11:16 < dammsan> so we likely have a mix of both hardware and software issues +11:16 < dammsan> and now lacking architecture support as well +11:16 < dammsan> =) +11:16 < geertu> software we can fix +11:17 < dammsan> so we should fix up the IOMMU and DMAC framework issue somehow +11:17 < dammsan> and in case of hardware issues on Gen2 +11:17 < dammsan> it is most likely too late to fix anything there anyway +11:18 < dammsan> in hardware i mean +11:18 < dammsan> so i think we should focus on fixing the software +11:19 < dammsan> once we've gotten the CPG in a better state then i would like to spend most of my time on IPMMU +11:19 < dammsan> hopefully that would move things forward +11:20 < dammsan> btw, +11:20 < dammsan> i have now received a package with a bunch of QSE/QTE adapters +11:20 < dammsan> and i'd like to distribute one unit per person +11:20 < geertu> Do they fit? ;-) +11:20 < dammsan> not opened the package yet =) +11:21 < dammsan> i ordered same product as you +11:21 < dammsan> but with bent connectors +11:21 < dammsan> with those adapters I/O development and things like IRQC should be easier to move forward on +11:21 < geertu> So you have to raise the boars more, as they're usually at the bottom +11:22 < geertu> Indeed. Thanks a lot! +11:22 < geertu> s/boars/boards/ +11:22 < dammsan> lets see if they work first =) +11:23 < dammsan> i have no other things related to upcoming development +11:23 < geertu> Anyone else +11:23 < geertu> ? +11:23 < horms> my only item is avb ptp, but that is probably a topic for the i/o group +11:23 < dammsan> oh, if someone could help with the CPG stuff that would of course be nice +11:24 < dammsan> i intend to refresh the series later this week +11:24 < horms> i think that has its own agenda item +11:24 < dammsan> but if someone could offload me then that would be nice +11:24 < dammsan> yeah "clock-output-names" +11:24 < geertu> Topic 2. "clock-output-names" +11:24 < geertu> i.e. CPG +11:25 < geertu> I guess everybody saw the email from Mike Turquette +11:25 < horms> aye +11:25 < dammsan> yeah +11:25 < uli___> mhm +11:25 < dammsan> and the conclusion is? +11:25 < horms> I deffer to dammsan's conspiracy theory +11:25 < dammsan> haha +11:26 < dammsan> at least we can move forward now by using clock-output-names to begin with, right? +11:26 < horms> yes +11:26 < horms> that is my understanding +11:26 < dammsan> or did i misunderstood things? +11:26 < geertu> As I don't think Mike's rework will be in v4.4 (too late), I think we should (re)add clock-putput-names +11:26 < dammsan> good +11:26 < horms> and mike can futs around with his ideas +11:26 < dammsan> yeah, i think so too +11:27 < horms> assuming we do that, what are the next steps, e.g. for v4.4? +11:27 < dammsan> seems pretty clear to me +11:27 < geertu> So people have to resend their integration patches, preferably in the right order to make Simon's work easier +11:27 < horms> yes, ideallt +11:27 < horms> yes, ideally +11:27 < dammsan> may i suggest aligning this update with the new data sheet? +11:27 < horms> though i'm trying a hub-and-spoke appraoach +11:27 < geertu> futs is not in my dictionary, nor in "dict fut"? +11:28 < dammsan> morimoto: when is the new updated datasheet coming? +11:28 < geertu> new data sheet? +11:28 < horms> futs ~= play around with +11:28 < dammsan> yourself? +11:28 < dammsan> =) +11:28 < morimoto> dammsan: there is still no information about datasheet +11:28 < horms> though i'm trying a hub-and-spoke appraoach; so dependencies may not be as bad as you may think +11:29 < geertu> As long as you're adding a new mstp register, it's OK +11:29 < horms> yes +11:29 < geertu> But some patches touch existing MSTP registers, so they may conflict +11:29 < horms> yes +11:29 < horms> that is the hard part +11:29 < dammsan> horms: so what is your plan regards to merging? +11:29 < horms> likewise with dt nodes +11:30 < horms> upstream? +11:30 < dammsan> yeah +11:30 < horms> i think we can start to push things into next +11:30 < horms> and thus towards arnd & the gang +11:30 < dammsan> something in parallel with the PFC and CPGbits? +11:30 < horms> i think that would be idea +11:30 < horms> what do you think? +11:30 < dammsan> sure, just keep it small +11:30 < horms> ok +11:30 < dammsan> i suppose you will get some feedback =) +11:31 < horms> i was thinking of using separate branches for the arm64 work +11:31 < horms> so it can be comented on separeately to the 32bit work +11:31 < dammsan> sounds good +11:31 < geertu> For integration? +11:31 < horms> I will also stock up on various colours of paint +11:31 < geertu> Or for drivers? +11:32 < horms> I was reffering to integration +11:32 < geertu> Since that's arm64, it's indeed best to use a separate branch +11:32 < horms> indeed +11:32 < geertu> or is that not how arm-soc works for mixed arm32/arm64 SoC manufacturers? +11:33 < horms> we will soon find out! +11:33 < geertu> :-) +11:33 < dammsan> geertu: we should focus on cache topology in the not so distant future too +11:33 < horms> I'm pretty sure I will need to make a trip to Google to chat to Olof at some point; thats what it took to get the 32bit stuff flowing nicely +11:33 < geertu> Let's hope they give earlier feedback then for your now-pending pull requests +11:33 < dammsan> i guess that is topic 1 more, sorry for late addition +11:34 < horms> geertu: i am skeptical +11:34 < geertu> (added task "r8a7795,v4.5,Cache topology") +11:35 < horms> dammsan: how about you start by reposting a patchset that you think is appropriate for v4.4? +11:35 < geertu> horms: I have lots of platform_data removal patches waiting for the arm-soc pull completion +11:35 < horms> in relation to that mess +11:35 < geertu> horms: Trip to ELCE? +11:35 < dammsan> horms: i think my latest patchset covers a minimal base pretty well +11:35 < horms> i plan to repost the dt/fixes separately soon +11:36 < dammsan> and i may not have time to resend until after ELCE +11:36 < horms> but i don't know when olof et al.. will actually pull anything +11:36 < horms> dammsan: does it need updating? +11:36 < dammsan> horms: how about i update the CPG series +11:36 < geertu> they seem to be busy with pulling various for-v4.3 stuff +11:36 < geertu> Topic 3. [PATCH/RFC v2 0/4] Renesas CPG/MSTP DT Binding Proposal +11:36 < dammsan> and then add some incremental patch that perhaps you can fold in? +11:37 < geertu> Has anyone read that? +11:37 < horms> geertu: thats nice, seeing that closed about a month ago +11:37 < geertu> I know it may be a bit late, but I was triggered again by some RST discussion +11:38 < geertu> R-Car Gen3 gained many more module stop/status/reset/... registers, now we have up to 10(!) sets +11:38 < horms> is this related to the mode pin (driver) discussion (with Luarent)? +11:38 < dammsan> geertu: i got a bit confused by MSSR? +11:38 < geertu> horms: no +11:39 < dammsan> this is how things are called for Gen2 or Gen3? +11:39 < geertu> 8A. Module Standby, Software Reset +11:39 < horms> ok, could you add that to the agenda, possibly for next time when he is here +11:39 < horms> ? +11:40 < geertu> 8A. Module Standby, Software Reset (Gen3) +11:40 < geertu> 7A. Module Standby and Software Reset (Gen2) +11:40 < dammsan> geertu: but isnt 7. and 8. CPG? +11:41 < geertu> Section 2. Module Standby, Software Reset (APE6) +11:41 < dammsan> I see +11:42 < geertu> yes, 7 and 8 are CPG +11:42 < dammsan> I've never seen MSSR before so I got a bit surprised +11:42 < dammsan> wasn't sure what it was +11:42 < dammsan> but now i understand +11:42 < geertu> The abbreviation is never used in the datasheet +11:42 < dammsan> were you planning on using that for DT compat strings? +11:43 < geertu> Yes, as it must be different from the existing +11:43 < dammsan> i think that was included in your proposal +11:43 < dammsan> geertu: you can match on soc-specific string too, right? +11:44 < geertu> and there would be a single mssr block, not individual blocks for the individual registers (which was the biggest problem for the 10 register sets) +11:44 < geertu> compatible = "renesas,r8a7791-cpg-mssr"; +11:44 < geertu> compatible = "renesas,r8a7795-cpg-mssr"; +11:44 < pinchartl> geertu: I'm in Belgium right now and totally jetlagged, sorry for not joining earlier +11:44 < geertu> Welcome! +11:46 < dammsan> geertu: you remedy the MSTP bit index issue in your proposal, right? +11:46 < dammsan> with split <&mstp5 R8A7790_DU0> +11:46 < geertu> You mean using register and bit index that don't match? +11:46 < dammsan> yeah +11:46 < dammsan> exactly +11:46 < geertu> Yes. +11:46 < dammsan> good. +11:47 < geertu> #define MSTP(n) (n / 100 * 32 + n % 100) +11:47 < geertu> Originally I wanted to use just e.g. " +11:47 < geertu> 318" +11:47 < geertu> Until I realized what kind of sparse arrays that would give +11:48 < geertu> So it;s translated to 3 * 32 + 18 +11:48 < dammsan> do we have issues with sparsely populated arrays? +11:48 < dammsan> i thought the DT map callback takes care of that +11:48 < horms> so its ~3 times more densely populated? +11:48 < geertu> clks = kmalloc(MSTP_MAX_CLOCKS * sizeof(*clks), GFP_KERNEL); +11:49 < geertu> For 12 registers of 32 bits, that would be 1200 instead of 12 * 32 entries +11:50 < dammsan> ok, i thought you were talking about DT size +11:50 < geertu> of xlate onecell needs a non-sparse array +11:50 < geertu> No, in DT clocks/clock-indices/clock-output-names contain the used entries only +11:50 < dammsan> ok, so DT does not use the MSTP() macro? +11:51 < geertu> They become large though, so you have to be careful to insert new entries at the right position +11:51 < geertu> include/dt-bindings/clock/r8a7791-clock.h has e.g. +11:51 < geertu> #define R8A7791_CLK_MSIOF2 MSTP(205) +11:51 < geertu> and the dtsi just uses R8A7791_CLK_MSIOF2, which is expanded to 2 * 32 + 5 +11:51 < dammsan> oh, that looks good +11:52 < geertu> And we avoid the "CCF doesn't support clock-cells = <2>" by Laurent +11:52 < dammsan> the in-driver management for clock arrays is an interneal implementation detail +11:53 < horms> is it possible to teach of xlate oncell how to handle a sparse array? +11:53 < pinchartl> geertu: that looks good to me +11:54 < geertu> See of_clk_src_onecell_get() +11:55 < geertu> horms: we can provide our own xlate method in +11:55 < geertu> of_clk_add_provider(np, of_clk_src_onecell_get, &group->data); +11:55 < dammsan> geertu: so how do we combine that and the current CPG series? +11:56 < geertu> Then we can get rid of the MSTP() macro, I think +11:56 < dammsan> horms: geertu: it would be elegant to use xlate if that would solve the issue +11:57 < geertu> pinchartl: which part? +11:57 < geertu> horms: yes +11:57 < horms> great :) +11:58 < pinchartl> geertu: the DT bindings with a single node +11:58 < geertu> dammsan: the clk-mssr driver must be added, and the call to cpg_mstp_add_clk_domain() has to be changed to cpg_mssr_add_clk_domain(), and the Makefile updated to use clk-mssr.o +11:58 < pinchartl> I haven't reviewed the implementation in detail +11:59 < geertu> pinchartl: I should have sent a git-style diff, so you could see more easily how clk-mssr.c differs from clk-mstp.c +11:59 < pinchartl> no worries +11:59 < pinchartl> implementations can always be adjusted later if needed anyway +12:00 < geertu> My biggest worry is the long clocks/clock-indices/clock-output-names arrays +12:00 < geertu> They're still error-prone +12:01 < dammsan> geertu: are those arrays per-32bit-word? +12:01 < dammsan> or one global? +12:01 < geertu> dammsan: no, they cover all MSSR moule bits +12:01 < geertu> s/moule/module/ +12:01 < dammsan> oh i see +12:02 < dammsan> would it be difficult to do it per-32bit-word? +12:02 < dammsan> that would make it easier to review and less error prone, no? +12:02 < geertu> So we need subnodes per 32-bit register (set)? +12:03 < geertu> mssr@0 { ... } +12:03 < dammsan> that sounds logical to me +12:03 < geertu> mssr@1 { ...} +12:03 < geertu> Can be done, more parsing code +12:04 < geertu> And people may still stick the wrong clocks in the wrong subnode +12:04 < dammsan> i guess we're one step away from a single plink per clock? +12:04 < geertu> it woukd avoid the "/* MSTPx */" comments +12:04 < geertu> That was my previous proposal ;-) +12:05 < geertu> For the subnodes, we need some more #address/size-cells and reg glue +12:05 < dammsan> one big array seems a bit suboptimal to me... +12:05 < dammsan> i like the single plink +12:06 < dammsan> but other people may not =) +12:06 < geertu> Yeah, Gen2 doesn't have register set 6 +12:06 < dammsan> geertu: do you need reg glue? +12:06 < geertu> so says the datasheet +12:06 < geertu> but there are bits I can toggle from U-Boot, and the status registers follow suit ;-) +12:06 < dammsan> hehe +12:07 < geertu> THe mssr main node needs #address-cells is 1, #size-cells = 0 +12:07 < geertu> The mssr@x subnodes need reg = <x> +12:07 < dammsan> i see +12:08 < geertu> In theory, the subnodes also need #clock-cells = <1> +12:08 < geertu> but dtc won't complain about that +12:08 < geertu> ah, CCF needs the #clock-cells = <1> in the subnodes +12:08 < geertu> That would be the penalties for getting rid of the "/* MSTP x */" comments in the arrays +12:09 < geertu> But I think we're running out of time... +12:09 < dammsan> i'm fine either way myself +12:09 < geertu> Please reply with your comments to the emails +12:09 < geertu> Topic 4. sh-pfc +12:09 < dammsan> lets discuss face-to-face how to combine these things +12:10 < dammsan> but i'll reply any technical feedback via email +12:10 < dammsan> yes +12:10 < dammsan> nice with the pfc bits +12:10 < geertu> So I queued up the pfc patches +12:10 < geertu> both Gen3 and non-Gen3 +12:11 < geertu> Most have been acked by LinusW +12:11 < geertu> some by Laurent +12:11 < geertu> I have more PFC patches to go out (resend) +12:12 < pinchartl> geertu: if there are core PFC patches I haven't acked could you please ping me ? +12:12 < horms> Excellent, thanks for getting that under control +12:12 < geertu> But MSIOF (and USB (Shimoda-san?)) depends on review comments for "[PATCH] [RFC] pinctrl: sh-pfc: Improve pinmux macros documentation" +12:12 < pinchartl> I won't have time to review the "pin number" patches this week +12:12 < pinchartl> but I can take a look at the core +12:12 < pinchartl> ok, that one I should review I guess :-) +12:12 < geertu> pinchartl: OK; yes ;-) +12:14 < geertu> shimoda: Ignore me, USB on Gen3 doesn't need it (Gen2 did) +12:14 < morimoto> geertu: thank you about this patch. I guess it was my task +12:15 < geertu> morimoto: you're welcome. There's still opportunity for improvement +12:15 < shimoda> geertu: sorry, and I don't understand about the pfc topic +12:15 < geertu> shimoda: pfc-r8a7791.c has "PINMUX_DATA(USB0_PWEN_MARK, FN_USB0_PWEN)" +12:15 < geertu> which uses the "raw +12:16 < geertu> which uses the "raw" PINMUX_DATA() macro +12:18 < pinchartl> (lunch time) +12:18 < geertu> Topic 5. Status check for tasks from last meeting - what is remaining +12:18 < shimoda> Umm, I don't still understand it, so I will ask Morimoto-san or Magnus-san later :) +12:18 < dammsan> shimoda: sure +12:19 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list +12:19 < geertu> No status changes? +12:19 < horms> I did some work on Lauren't pin mode driver idea, however I'm struggling to initialise the module(s) early enough for them to be useful to CPG on Gen2 which is used from the init_timer callback +12:20 < dammsan> horms: i wonder if some -EPROBE_DEFER changes would be useful for the CPG and/or CCF? +12:20 < pinchartl> horms: could init be performed on the first call to the get mode operation and the value then cached ? +12:20 < pinchartl> (now I really have to run, sorry) +12:20 < dammsan> and move it to later during boot +12:20 < geertu> pinchartl: bye! +12:21 < dammsan> pichartl: enjoy lunch +12:21 < horms> pinchartl: the trouble is knowing which implementer (module) to call +12:21 < horms> it needs to register itself for your idea to work +12:21 < horms> dammsan: that may work out, the devil would be in the details +12:21 < dammsan> horms: can't you use a different earlier initcall? +12:22 < horms> esp what needs a cpg to be functional at that point +12:22 < dammsan> earlier than the timer callback +12:22 < horms> i tried early +12:22 < horms> and even pure +12:22 < horms> they are both too late +12:22 < dammsan> hm.. +12:22 < geertu> machine_desc.init_early()? +12:22 < dammsan> we have the delay stuff there i think +12:22 < horms> geertu: that would work, i suppose +12:23 < horms> but it would need to call the implementor directly +12:23 < horms> rather than the higher-level wrapper; which imho is most of the point of the idea +12:23 < horms> none the less it might make it fly for gen2 +12:23 < horms> and perhaps for gen3 an initcall is early enough +12:24 < geertu> machine_desc.init_early() can set up the accessor? +12:24 < dammsan> horms: clocks and timers are a can a worms regardless of architecture +12:24 < geertu> dammsan: you don't want -EPROBE_DEFER in CCF nor CPG, as it won't be retried +12:24 < horms> geertu: yes, it could set up the accessor or cache the value; your idea is growing on me +12:25 < horms> i'll see if I can make it fly +12:25 * geertu should shut up, as he wants renesas,modemr to succeed +12:25 < horms> and if so post a prototype +12:25 < horms> fwiw, i am currently neutal regarding wich solution i would like to succeed +12:25 < horms> my aim is merely to flesh out laurent's idea so we can see what it looks like in practice +12:26 < horms> thanks for the idea +12:26 < dammsan> geertu: i guess moving CPG and CCF to later on will require some serious changes then +12:26 < horms> i think we can close that sub-topic for noe +12:27 < horms> i'm skeptical that such a rework is warranted for this particular cause +12:27 < dammsan> geertu: what is your plan regards upstreaming of the PFC bits? +12:27 < dammsan> you said sending something at -rc i recall? +12:27 < dammsan> horms: sure +12:27 < dammsan> horms: just plan b if all else fails +12:27 < horms> sure +12:27 < horms> no argument there +12:28 < geertu> dammsan: send pull request to LinusW later this week, or perhaps next week (hmm, Dublin) +12:28 < geertu> Are there many pending PFC bits? +12:28 < geertu> I have HSCIF and MSIOF +12:28 < geertu> Shimoda-san has USB? +12:29 < dammsan> does linusw like several incremental pull requests, or one single? +12:29 < horms> you have avb, right? +12:29 < geertu> damsan: no ides. I may find out ;-) +12:29 < shimoda> geertu: yes, I have USB (and PWM) +12:29 < geertu> avb is in +12:29 < horms> great +12:29 < morimoto> I guess I posted Sound and I2C +12:29 < dammsan> i think if we can get in what we have then that would be wonderful +12:30 < horms> agreed +12:30 < geertu> sh-pfc-for-v4.4 has scif, i2c, audio clock, audio ssi, avb +12:30 < dammsan> maybe we can consider the DT bindings semi-stable once things hit next? +12:31 < geertu> dammsan: which DT bindings? +12:31 < dammsan> geertu: that sounds more than is needed by the current integration series +12:31 < dammsan> r8a7795 pfc +12:31 < geertu> dammsan: that matches integration +12:31 < horms> dammsan: r.e. semi-stable: i think so +12:32 < dammsan> so it must be better to have a small set of devices agreed on early +12:32 < dammsan> compared to larger late +12:32 < geertu> Don't know whether I should postpone MSIOF PFC until I have hardware? +12:32 < dammsan> i think that is fine +12:33 < horms> its not as if it will regress any existing support +12:33 < geertu> Yeah, we had small bugs in various PFC bits for years +12:33 < horms> exactly +12:33 < geertu> They will be fixed when/if someone encounters them +12:33 < dammsan> untested most certainly means broken +12:34 < horms> yes +12:34 * geertu is actually surprised about how much of the PFC bits were correct +12:34 < dammsan> yeah +12:34 < dammsan> good with review from you guys +12:35 < dammsan> and nice that morimoto-san broke out the mega-patch +12:35 < morimoto> I hope 7795 is more readable than other pfc +12:35 < dammsan> i wonder if linusw will be at ELCE +12:35 < dammsan> if so i should bring some whiskey +12:36 < geertu> "bring some whiskey to Ireland"? +12:36 < dammsan> haha +12:36 < dammsan> well +12:36 < dammsan> sand to the beach +12:36 < horms> dammsan: I heard that Dublin is a dry county +12:37 < dammsan> as long as my coffee comes with medicin i'm happy +12:38 < dammsan> geert: would it be possible for you to prioritize sending out the PFC bits to linusw before ELCE? +12:38 < dammsan> i will do my best to update CPG on thursday +12:39 < geertu> dammsan: sure +12:39 < dammsan> thanks! +12:39 < dammsan> horms: and after ELCE i hope to hand over the integration stuff to you +12:39 < horms> dammsan: excellent +12:40 < horms> i guess there wont be a whole lot of time between then and rc5 +12:40 < dammsan> i guess so +12:40 < dammsan> alternatively i can hand it over earlier +12:41 < horms> earlier is better if its ready :) +12:41 < dammsan> i need to sync the CPG and integration bits +12:41 < horms> but do we need bindings to hit next first? +12:41 < dammsan> i think review can happen in parallel +12:41 < horms> ok +12:41 < horms> that is of course fine +12:41 < dammsan> will you be busy next week? +12:41 * horms checks +12:42 < dammsan> or if i could hand over integration stuff to you earlier +12:42 < dammsan> perhaps that may improve our chances +12:42 < horms> I don't expect to be busy next week +12:42 < dammsan> ok, so i should really send out both CPG and integration this week +12:42 < dammsan> geert: will you be online on thursday? +12:43 < horms> or the week after other than friday when i am shceduled to visit musashi works +12:43 < dammsan> but the earlier the better +12:43 < horms> the last week of October will be busy for me +12:43 < dammsan> geertu: i was hoping to chat with you how to integrate your CPG/MSSR proposal +12:43 < dammsan> will thursday be ok? +12:44 < horms> dammsan: probably its best if you handle both of those series as you are most familiar with them. but if it makes sense I could try to offload you a bit somehow +12:44 < geertu> dammsan: Thrusday is fine +12:45 < dammsan> horms: i agree, but i may ask you to do some folding yourself +12:45 < dammsan> horms: when will your new board arrive? +12:46 < horms> it was scheduled to arrive today, but didn't +12:46 < dammsan> geertu: thanks, lets chat more thursday then +12:46 < dammsan> ok +12:46 < dammsan> i will install two new boards in the remote rack tomorrow btw +12:46 < horms> is there anything special i need to know about hooking it up? +12:47 < dammsan> horms: nope +12:47 < dammsan> it is noisy +12:47 < shimoda> horms: I'm sorry I sent the board today, so it should arrive tomorrow +12:47 < horms> ok +12:47 < horms> shimoda: no problem! +12:47 < geertu> BTW, does anyone have a kzm9d? +12:47 < horms> yes +12:48 < horms> though its semi-broken these days; the kernel for it that is +12:48 < dammsan> horms: if you are not using it, can i hook it up for remote access? +12:48 < geertu> horms: I don't need a running kernel ;-) +12:48 < horms> i'm only semi-using it to test kernels +12:48 < horms> that don't boot +12:48 < horms> perhaps i could send it to dammsan ? +12:48 < geertu> horms: Can you please run "md 0xe0028008 1" from U-Boot and tell me the reported value? +12:48 < horms> oh sure +12:48 < horms> can do +12:49 < dammsan> horms: no stress, feel free to send with takkyubin or simply bring next time we meet +12:49 < horms> thanks, i'll sort something out +12:49 < dammsan> thanks +12:49 < dammsan> i intend to take the salvator-x down in the remote access rack tonight +12:50 < dammsan> i will lock you out +12:50 < dammsan> it will come back again tomorrow JST +12:50 < horms> geertu: +12:50 < horms> KZM-A9-Dual# md 0xe0028008 1 +12:50 < horms> e0028008: 0000043b ;... +12:51 < horms> dammsan: you are taking it to a club? +12:51 < geertu> horms: Thanks (GIC PL390) +12:51 < horms> geertu: any time +12:51 < dammsan> horms: i wish +12:52 < geertu> horms: So it's a dual-core, but doesn't have the CA9 MPCore GIC +12:52 < horms> interesting +12:52 < dammsan> geertu: EMEV2 was a very early CA9 implementation I've heard +12:52 < dammsan> the TWD seems quite special too +12:53 < dammsan> anyway, i should probably wrap up now +12:53 < horms> unless there are any more pressing topics i might move on +12:53 < dammsan> will see if my lager DU IPMMU hack outputs anything over VGA +12:54 < dammsan> thanks for your time guys +12:54 < horms> bye +12:54 < geertu> time for lunch... +12:54 < dammsan> bye bye +12:54 < uli___> cu +12:54 < geertu> Thanks, for joining! Bye! diff --git a/wiki/Chat_log/20151015-io-chatlog b/wiki/Chat_log/20151015-io-chatlog new file mode 100644 index 0000000..6101416 --- /dev/null +++ b/wiki/Chat_log/20151015-io-chatlog @@ -0,0 +1,230 @@ +--- Log opened Thu Oct 15 10:58:29 2015 +10:58 -!- wsa_ [~wsa@p4FE25555.dip0.t-ipconnect.de] has joined #periperi +10:58 -!- Irssi: #periperi: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal] +10:58 -!- Irssi: Join to #periperi was synced in 1 secs +10:58 < pinchartl> can I let you handle it internally to book a time and place ? +10:58 < dammsan> yes +10:58 < wsa_> hi there! +10:58 < pinchartl> or do you expect me to do anything ? +10:58 < pinchartl> hi Wolfram +10:58 < dammsan> no, it will be on the 4th +10:58 < dammsan> more details to follow over email +10:59 < dammsan> bye bye! +10:59 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has quit Remote host closed the connection +10:59 < wsa_> bye magnus +10:59 < pinchartl> bye bye too :-) +10:59 < wsa_> bye! +11:00 -!- Irssi: #periperi: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal] +11:01 -!- horms [~horms@121-80-213-238f1.hyg1.eonet.ne.jp] has joined #periperi +11:01 < wsa_> \o/ +11:01 < wsa_> hi simon +11:01 < geertu> Hi Wolfram +11:01 < wsa_> hi geert +11:02 < horms> hi! +11:02 < wsa_> morimoto-san, shimoda-san: you there? +11:02 < morimoto> hi +11:02 < shimoda> hi! +11:02 < wsa_> \o/ +11:02 < geertu> Hi all +11:03 < morimoto> geertu: about Koelsh, it seems there is ES1.0/ES2.0/ES3.0 in this world +11:03 < morimoto> but I (and shimoda-san) only have ES1.0 board +11:03 < wsa_> good starting point +11:04 < geertu> Good to know. +11:04 < wsa_> what about having a wiki page stating who has which board with which ES number +11:04 < geertu> Let's wait for bug reports ;-) +11:04 < geertu> Yeah, that's long overdue +11:06 < wsa_> I would start it, but it might be that I forgot my wiki pwd :/ will try again after this meeting +11:06 < geertu> My Salvator-X has H3 ES1.0 +11:06 < geertu> Bummer, no access to https://osdr.renesas.com/projects/linux-kernel-development/wiki/Io-todo-list? +11:08 < wsa_> so, the other topics for today I have: todo list updates, SCIF status, Who does SDHI, Watchdog plans +11:08 < wsa_> more topics from your side? +11:09 < horms> i would like to ask shimoda san about etheravb. but i can ask him tomorrow when i visit his office if there is no time here today +11:09 < wsa_> ok, so we put this to the end of the list +11:10 < shimoda> horms: i got it :) +11:10 < wsa_> so, let's start with todo list updates: +11:10 < wsa_> I have +11:10 < wsa_> PWM driver upstream \o/ +11:11 < wsa_> Thermal driver still needs the docs +11:11 < wsa_> PCIE patches appeared on ML, will check them when my board arrives +11:11 < wsa_> (according to UPS should be today) +11:11 < wsa_> EtherAVB basic support upstream \o/ +11:12 < wsa_> SATA driver: BSP team works on it +11:12 < wsa_> I2C: runtime core switch postponed to 4.5. too late in the cycle for DT bindings +11:12 < wsa_> I2C: DMA task added until End of May +11:13 < wsa_> not sure about this one: +11:13 < wsa_> SPI slave support wanted until End of May +11:13 < wsa_> ? +11:13 < wsa_> shimoda: is this final? or is it still a request only? +11:13 < geertu> I'll have to look at the other SPI Ethernet driver, and do some more research for a good use case. +11:14 < geertu> Shimoda-san: Do you have more info about the customer's use case? +11:14 < shimoda> geertu: unfortunately I don't have more info +11:15 < geertu> At ELCE, I talked to Mark Brown (SPI maintainer), and he's open for SPI slave support. +11:15 < geertu> Shimoda-san: Would it be possible to ask somewhere to obtain more info? +11:16 < shimoda> geertu: i will try to ask +11:16 < wsa_> geertu: what is the status of this large SCIF series? +11:16 < wsa_> needs ping? needs review? already upstream? +11:17 < shimoda> wsa_: about thermal driver, I heard bsp team is developing it. So, I will get information from them later +11:17 < geertu> SCIF DMA is in -next +11:17 < geertu> So it will be in v4.4 +11:17 < wsa_> \o/ +11:18 < wsa_> didn't notice from the mails in linux-sh +11:18 < wsa_> so i can remove +11:18 < wsa_> SCIF,4.4,Upstream improved DMA support for R-Car Gen2 +11:18 < wsa_> from the todo list +11:18 < wsa_> ? +11:19 < geertu> GregKH's bot didn't CC linux-sh +11:19 < geertu> Yes (assumed in -next == will be in v4.4) +11:19 < wsa_> shimoda: ok, will update the info about thermal driver +11:20 < wsa_> geertu: and you will be working on baudrate generators for 4.5, correct? +11:20 < geertu> that's correct +11:20 < geertu> I'm a bit delayed by the Gen3 CPG rework +11:21 < wsa_> I can imagine +11:22 < wsa_> geertu: anything else you are planned to work on IO wise? +11:22 < morimoto> I asked about SPI slave use case to BSP team +11:22 < wsa_> I have this baudrate generator and random SPI stuff in the list :) +11:23 < geertu> Yeah, I plan to test MSIOF on Gen3, if possible (read: available on EXIO) +11:23 < wsa_> same questions to the others +11:23 < wsa_> shimoda: I assume you will be busy doing USB stuff? +11:24 < wsa_> morimoto: any IO related task you have assigned? (except using I2C for sound ;)) +11:24 < morimoto> Ahh... no I/O I have +11:24 < wsa_> simon: I guess you'll work in improving EtherAVB support? +11:25 < shimoda> wsa_: yes, but bsp team needs USB stuff (expect USB2 host) until end of May +11:25 < shimoda> so, i have some space +11:25 < wsa_> oh, that sounds good +11:25 < morimoto> wsa_: About Thermal driver lacking docs, do you mean 10A.3.1.2 ? +11:25 < horms> EtherAVB is the only i/o related item i'm working on directly +11:25 < shimoda> however, sometimes I have a lot of paper works though :) +11:26 < wsa_> oh, that sounds not good +11:26 < wsa_> :) +11:27 < wsa_> horms: anything specific? I have only PTP support until End of November in the list +11:27 < horms> so my question for shimoda-san is about that +11:27 < horms> is now a good time? +11:28 < wsa_> morimoto: yes, and 10.A.3.1.4 +11:30 < shimoda> horms: sorry I don't understand your question +11:30 < shimoda> you are talking about PTP support? +11:31 < horms> my quesion is as follows +11:32 < morimoto> wsa_: OK, according to datasheet team, about 10A.3.1.2, it depends on real measured data. +11:32 < morimoto> but, there is not such data at this point. So, it will be other explanation in next datasheet +11:32 < morimoto> if they still doesn't have it +11:33 < horms> I see some PTP support present in the ravb driver. It looks like it handles timestamps. Is that what is required for r8a7795 by mid-November? +11:33 < wsa_> morimoto: I assumed so. Anyhow, looks like BSP team took this over. They will probably have better access to such data +11:36 < shimoda> horms: thank you for the detail. I will ask bsp team about this +11:36 < horms> shimoda: thanks. if they want to explain things in patches that is fine by me :) +11:37 < wsa_> good +11:38 < wsa_> can we move to SDHI topic? +11:38 < horms> i think so +11:38 < shimoda> i think so +11:39 < wsa_> fine +11:39 < wsa_> It seems that BSP team also wants to do the initial support? +11:39 < wsa_> And then wants to work on DMA support? +11:40 < shimoda> I think they want to work on DMA support if possible +11:40 < wsa_> And they need some assistance from us how to do it +11:41 < shimoda> I think so +11:43 < wsa_> do they have patches for initial support already? +11:43 < shimoda> tmio driver is using dmaengine. but I don't know gen3 SDHI should use it or not +11:44 < shimoda> wsa_: for PIO, yes +11:44 < shimoda> let me check some repositories +11:47 < shimoda> in renesas-bsp.git, 91e3cc719def606e049861d4f9fc02bd90f126be, arm64: dts: salvator-x: Add sdhi-rcar support +11:48 < shimoda> 09a0662a2b6073bb2237b5d28a354a406b4b640b, arm64: dts: r8a7795: Add sdhi-rcar support +11:49 < wsa_> got them +11:50 < wsa_> and some more patches to look at +11:50 < shimoda> about driver side, they are submitted some local patches... +11:50 < horms> wsa_: btw renesas-bsp is on kernel.org +11:52 < wsa_> yes, that's good +11:53 < wsa_> well, the makefile from mmc/hosts says: +11:53 < wsa_> tmio_mmc_core-$(subst m,y,$(CONFIG_MMC_SDHI)) += tmio_mmc_dma.o +11:53 < wsa_> so, the DMA module is only compiled in for SDHI? +11:54 < wsa_> ah, sure. the todo list only marks "DMA on Gen3" as a todo +11:55 < shimoda> wsa_: yes, on gen3, DMAC is internal in the SHDI device instead of SYS-DMAC +11:57 < wsa_> is this internal DMAC reused in other IP cores? +11:57 < wsa_> it doesn't look SDHI specific to me +11:58 < shimoda> I don't think this internal DMAC is reused +12:01 < wsa_> ok +12:02 < morimoto> About makefile, tmio_mmc_dma.o is used only from CONFIG_MMC_SDHI is correct +12:02 < morimoto> this is because historical reason +12:02 < morimoto> About Gen3 internal DMAC, this is Gen3 new feature +12:02 < morimoto> Gen3 DMAC != tmio_mmc_dma +12:02 < wsa_> I'd think a new file 'tmio_mmc_dma_gen3.c' or similar would be the way to go, but I need to double check +12:03 < wsa_> I can investigate +12:03 < wsa_> Is it "as soon as possible" or will next week be enough? +12:03 < morimoto> I think it is not "tmio", "sh_mobile_sdhi_dma" is better ? +12:04 < horms> can we rename tmio_mmc_dma while we are at it? +12:04 < wsa_> to? +12:04 < horms> I suspect it doesn't relate to tmio at all +12:04 < horms> but just to sdhi +12:05 < horms> i could be wrong +12:05 < wsa_> i will dig into that and post my findings on the list +12:05 < morimoto> unfortunately, not good idea +12:05 < morimoto> because tmio_mmc_pio calls tmio_mmc_dma function +12:06 < horms> ok +12:06 < morimoto> But, we can create new sub-framework for DMA? +12:06 < morimoto> real TMIO doesn't need DMA (?), we need 2type of DMA +12:07 < morimoto> and tmio_dma naming is not good match now ? +12:07 < horms> probably that will lead to a nice clean result +12:07 < horms> but is gen3 dma on the critical path? +12:08 < horms> If so it would be nice to arrange things so new frameworks come after hw support, imho +12:08 < wsa_> agreed +12:08 < shimoda> horms: on the critical path or not, let us ask BSP team tomorrow :) +12:09 < horms> good plan +12:09 < wsa_> anything more for SDHI? +12:09 < wsa_> otherwise let's move on to watchdog +12:11 < morimoto> ok +12:11 < wsa_> ok, my idea there is to implement the missing SET_TIMEOUT feature and repost as RFC +12:12 < wsa_> we can then test this one on Gen2/3 and see if it works with the reset controllers +12:12 < wsa_> (it obviously doesn't on r8a7790 ES1) +12:12 < wsa_> if all fails, I could try to add r7s72100 support and get at least the driver upstream vis this path +12:13 < wsa_> so we don't have to carry around this one +12:13 < wsa_> OK plan? +12:13 < shimoda> wsa_: if we use not SMP, watchdog should work even if r8a7790 ES1 +12:14 < geertu> The watchdog is not limited to R-Car Gen2/3 and RZ +12:15 < wsa_> shimoda: Yes, then it works +12:15 < wsa_> I can confirm that +12:15 < geertu> it's also present on older SH-Mobile and R-Mobile +12:16 < wsa_> geertu: like with r7s or even another register layout? +12:17 < geertu> BTW, the issue with the syscon driver I mentined in "Re: [RFC 4/5] ARM: shmobile: r8a7790: let rst module allow watchdog resets if desired" (http://www.spinics.net/lists/linux-sh/msg39799.html) is gone +12:19 < wsa_> how come? +12:20 < geertu> At that time, you couldn't have both syscon and a regular driver bind to the same device node +12:20 < geertu> that has been fixed +12:20 < geertu> the APE6 RWDT looks the same as Gen2 +12:21 < geertu> The RZ one is different +12:22 < geertu> A1/AG5 uses an 8-bit version of APE6/Gen2 +12:22 < geertu> So there are 3 versions +12:23 < wsa_> ah, okay, so we still need the "syscon" property somewhen +12:23 < geertu> But "It's slightly more complicated there, as we already have a driver for the +12:23 < geertu> SYSC on R-Mobile (rmobile-reset), and a device node can't be bound +12:23 < geertu> by both the syscon and the rmobile-reset driver. +12:23 < geertu> " is no longer true +12:25 < geertu> From a chat with Magnus a long time ago: " +12:25 < geertu> Looking at datasheets, it seems the RWDT has a long history. +12:25 < geertu> R-Car Gen2: 32-bit registers, using RST +12:25 < geertu> R-Mobile APE6: 32-bit registers, using SYSC (APE6 has no RST block) +12:25 < geertu> SH-Mobile AP4/AG5, R-Mobile A1: 16-bit registers with 8-bit (instead of 16-bit) watchdog counter +12:25 < geertu> But the core is similar. +12:25 < geertu> And of course AP4 and A1 are single-core" +12:25 < geertu> RZ has a different control register layout +12:26 < wsa_> ok, i have datasheets for all of them +12:27 < wsa_> well, then, i'll do as I said before +12:27 < geertu> I can test A1/AG5/APE6 +12:27 < wsa_> since there were no complaints ;) +12:27 < geertu> and M2 and H3, of course +12:27 < wsa_> geertu: \o/ +12:28 < wsa_> I ran out of topics +12:28 < shimoda> About H3, as I wrote periperi ML, we can not write RST +12:28 < shimoda> :) +12:28 < wsa_> :) +12:28 < wsa_> anything from your side left? +12:30 < morimoto> nope +12:30 < geertu> nope +12:30 < horms> not here either +12:31 < shimoda> no +12:31 < wsa_> then we are done +12:31 < wsa_> \o/ +12:31 < wsa_> thanks all! +12:31 < horms> thanks! +12:31 < morimoto> thanks +12:31 < shimoda> thank you! +12:31 < wsa_> have a great rest of the day +12:31 < geertu> thx, cu +12:31 < geertu> bye +12:31 < shimoda> bye! +--- Log closed Thu Oct 15 12:34:05 2015 diff --git a/wiki/Chat_log/20151020-core-chatlog b/wiki/Chat_log/20151020-core-chatlog new file mode 100644 index 0000000..dcbf573 --- /dev/null +++ b/wiki/Chat_log/20151020-core-chatlog @@ -0,0 +1,291 @@ +11:02 < geertu> Welcome to today's Renesas Core Group Chat +11:03 < geertu> Today we have a special guest: Mike Turquette (thx!) +11:03 < dammsan> \O/ +11:03 < mturquette> My pleasure to attend! +11:03 < mturquette> Thank you for the invitation. +11:04 < geertu> Agenda: +11:04 < geertu> 1. Upcoming Gen3 development for the Core group, +11:04 < geertu> 2. New CPG/MSSR Driver, +11:04 < geertu> 3. rcar-dmac: pick up the patches, fix the DMA engine API and save the world, +11:04 < geertu> 4. Status check for tasks from last meeting - what is remaining? +11:04 < dammsan> mturquette: thanks for joining +11:04 < geertu> Given Mike's presence, I think we should start with Topic 2. +11:04 < mturquette> dammsan: :-) +11:05 < dammsan> geertu: your proposal looks all good to me - the only nit i have is the compat string +11:05 < geertu> Mike: I hope the bindings (and driver) I posted are in-line with your remaps? +11:05 < mturquette> geertu: yes. I've reviewed the binding it looks great. +11:05 < geertu> s/remaps/remarks/ +11:05 < mturquette> I'm still going through the driver changes, but the binding perfectly fits our discussion from ELC-E +11:06 < geertu> dammsan: What's your nit? +11:06 < dammsan> i feel that the "mssr" bit is something unknown +11:07 < dammsan> but i guess the mssr portion is outside the cpg? +11:07 < dammsan> s/bit/part of the name/g +11:08 < mturquette> Follow on question to dammsan: are the descriptions of the "mssr" bit fields in the same chapter/section as the cpg register descriptions in your internal documentation? +11:08 < mturquette> if so, it might be easier to just name the whole thing "cpg" +11:08 < geertu> Datasheet (for Gen2) says: +11:08 < geertu> 7. Clock Pulse Generator (CPG) +11:08 < geertu> 7A. Module Standby and Software Reset +11:08 < geertu> 7B. Advanced Power Management Unit for AP-System Core (APMU) +11:09 < mturquette> ah +11:09 < geertu> The registers in 7A are inside the same 4 KiB block of the CPG registers +11:09 < geertu> The registers in 7B are in a separate 4 KiB block +11:09 < dammsan> mturquette: i think so +11:11 < dammsan> I guess 7B needs to be managed by PSCI firmware +11:11 < geertu> Same for Gen3 (chapters 8/8A/8B) +11:11 < dammsan> geertu: do you have any strong feelings about the compat string name? +11:12 < geertu> The CPG and MSSR registers are really mixed, so you cannot separate them +11:13 < dammsan> right, so this is a good match for the single DT node approach +11:13 < geertu> dammsan: I just came up with a name that describes the block "renesas,r8a7795-cpg-mssr" +11:14 < geertu> Do you have a better suggestion? +11:14 < dammsan> geertu: i'm ok with that, but i would simply go with "r8a7795-cpg" +11:14 < geertu> (the old bindings for CPG only use e.g. ""renesas,r8a7790-cpg-clocks", and +11:14 < dammsan> and keep the mssr abstraction in C +11:14 < mturquette> I'm fine with either compat string name. Hopefully future chips will call the IP block something like Clock And Reset (CAR) or Reset and Clock Manager (RCM) or something :-) +11:14 < geertu> "renesas,rcar-gen2-cpg-clocks" +11:15 < dammsan> so our only concern at this point is the compat string? =) +11:15 < mturquette> I did have one other quick question +11:15 < mturquette> Do you plan to introduce reset framework bits into drivers/clk/shmobile/ ? +11:15 < geertu> If the technical side is OK, we can start bikeshedding +11:15 < geertu> mturquette: Yes, that's the plan +11:15 < mturquette> geertu: OK, great. +11:16 < geertu> tegra does it that way, too, IIRC +11:16 < mturquette> geertu: for the binding I'm very happy with it. +11:16 < geertu> I'm running the code here on r8a7795 and r8a7791, so that part works, too. +11:16 < mturquette> geertu: I don't have any review comments for the driver implementation at this time, so I'll post them later today on the list if I have anything, otherwise I can merge the series. +11:16 < dammsan> good! +11:16 < geertu> For the resets, it's still to be seen how good that works, and how it is to be used +11:17 < mturquette> geertu: or, do you plan to package things up in a PR? +11:17 < geertu> (resets have to be used explicitly by each individual driver?) +11:18 < dammsan> if everyone is happy - when can we see it in -next? +11:18 < dammsan> (i mainly care about the binding) +11:18 < geertu> Does anyone have any comment w.r.t. #defining all clocks in include/dt-bindings/clock/r8a7795-cpg-mssr.h upfront, or only having the ones we curently need? +11:19 < dammsan> geertu: as long as error handling is sane anything is fine with me +11:19 < dammsan> (running new DTB on old kernel) +11:20 < geertu> dammsan: new DTB on old kernel won't work +11:20 < geertu> dammsan: old DTB on new kernel should work if you include the old driver +11:20 < dammsan> geertu: but when you add clocks you increase support level in the driver, right? +11:21 < geertu> dammsan: another question is how complex we want the logic in drivers/sh/pm_runtime.c for the legacy clock domain to be +11:21 < mturquette> RE: defining all clocks, I'm of course fine with that, but the header is part of the "stable" binding. +11:21 < geertu> dammsan: yes, the cpg-mssr driver so far only implements the clocks we use +11:21 < mturquette> geertu: so it might be a safer approach to only add clocks as you need them. removing clocks breaks backwards compatibility. +11:21 < geertu> mturquette: of course. So it's append only. +11:21 < mturquette> geertu: but the choice is yours. i'm fine either way. +11:22 < dammsan> geertu: so say you add clocks to upstream +11:22 < dammsan> geertu: and people use the latest DTB with an old kernel +11:22 < dammsan> geertu: then the new clocks should fail to register, but shall the system halt? +11:23 < dammsan> geertu: in my mind it makes sense to keep the system working +11:23 < geertu> mturquette: My main thinking there is to switch over Gen2 (so far there's a single SoC in Gen3 only): do we (try to) keep numbers in sync between different SoCs of the same family? Syncing means we will have gaps in the numbering, but it may make the C code simpler. +11:23 < mturquette> geertu: i don't see why keeping the numbers the same is important +11:24 < mturquette> geertu: you're using preprocessor macros/defines for the numbers, right? +11:24 < mturquette> geertu: the symbols are the only thing that need to be sync'd between Linux kernel and the binding +11:24 < geertu> dammsan: It will print an error message that it can't handle the clock (cfr. the "default" switch case) +11:24 < dammsan> geertu: thats fine if the rest of the system works +11:24 < geertu> mturquette: For the CPG core clock outputs we use #defines. +11:25 < geertu> dammsan: and it will continue +11:25 < dammsan> geertu: wondershon +11:25 < geertu> mturquette: For the module clocks (and future resets) we use hardcoded numbers +11:25 < geertu> as these match the datasheet +11:26 < geertu> The CPG core clock numbers are numbers we come up with ourselves. +11:26 < mturquette> geertu: OK. the only problem there is if you have a NR_CLKS or NR_RESETS value that changes as new entries are added. +11:26 < dammsan> geertu: those hard coded numbers match the documentation 100%, right? +11:26 < geertu> dammsan: yes, they're the old "MSTP numbers" +11:27 < geertu> mturquette: NR_CLOCKS is only in the driver (C code) +11:27 < dammsan> geertu: right, and they are kind of sparsely populated I think +11:27 < mturquette> geertu: sounds good to me. +11:27 < geertu> mturquette: About numbering for different SoCs +11:27 < mturquette> geertu: i prefer a non-sparse list for "fake" numbers, but of course it makes sense to use a sparse list if you are matching the hardware. +11:28 < geertu> E.g. r8a7790 has more CPG core clocks than r8a7791. +11:28 < geertu> But both have QSPI. So R8A7790_CLK_QSPI may be different from R8A7791_CLK_QSPI +11:29 < geertu> Currently I use the CLK_TYPE_GEN2_QSPI clock type (internal to the C driver) to handle that. +11:30 < dammsan> geertu: on gen2 with mssr, will you use a generic compat string, or break out per SoC? +11:30 < mturquette> Hmm, I'll take a look at that. +11:30 < geertu> dammsan: yes, module clocks are sparsely populated. and more may show up or disappear with a revision of the datasheet :-) +11:30 < mturquette> On other implementations I see typically a big list of clocks in the driver which are common. And then various other smaller lists which break out the SoC-specific bits. +11:31 < dammsan> geertu: right. so matching the data sheet directly makes sense +11:31 < geertu> dammsan: per SoC, as the core clock registers are different (mainly about existence vs. non-existence) +11:31 < dammsan> geertu: sounds ggggggggood +11:32 < dammsan> mturquette: this is how to split the common code and soc-specific in C, right? +11:32 < dammsan> or does it affect the DT ABI? +11:32 < mturquette> dammsan: correct. It prevents from having to register two qspi clocks by accident +11:32 < dammsan> makes sense +11:32 < mturquette> dammsan: and thus it does not matter if the DT binding uses the same number for the qspi clocks on different SoCs +11:33 < dammsan> mturquette: so you have one name space per SoC? +11:33 < mturquette> and since you are using per-SoC compat strings, its easy to match on this +11:33 < mturquette> dammsan: right. +11:33 < dammsan> the numbers may or may not be shared +11:33 < geertu> On problem is we don't know in advance which clocks are common and which are SoC-specific (or become SoC-specific once a new derived SoC is released which lacks a hardware block) +11:33 < dammsan> between SoCs +11:33 < mturquette> but, generally you can describe 90% of your clocks in one big array which are shared by all the SoCs in the same family +11:34 < mturquette> and even if a new SoC comes out and changes this, you don't break DT compat, since its just an internal driver change to migrate a clock out of the "common" array into soc-specific arrays +11:34 < mturquette> geertu: ^^^ I think the point above addresses that. +11:34 < dammsan> mturquette: sure, sounds good +11:35 < mturquette> as long as the shuffling happens in the C driver and doesn't break compat, then its fine. +11:35 < mturquette> new kernels with different tables of per-soc clocks should still work with old DTBs +11:35 < geertu> So having the (intermediate) CLK_TYPE_GEN2_* defines is good, as it allows to isolate different SoCs +11:36 < geertu> And the SoC-specific numbers can be contiguous +11:36 < dammsan> mturquette: so you dont care how the DT ABI numbers are allocated? +11:36 < dammsan> as long as they are kept working +11:36 < dammsan> ? +11:37 < geertu> dammsan: Mike said before he prefers a non-sparse list +11:37 < dammsan> geertu: ok thanks, sorry for being slow +11:37 < mturquette> geertu: dammsan: I won't NAK a patch based on the list type. its really your choice. +11:38 < mturquette> geertu: I searched for CLK_TYPE_GEN2 in the v4 series and I don't see it? +11:38 < dammsan> so the current gen2 approach, is it good or bad? +11:38 < dammsan> (i mean the old upstream way with separate CPG and MSTP) +11:39 < dammsan> (the CPG clocks are virtual and non-sparse) +11:39 < geertu> mturquette: I didn't post the Gen2 driver, only the Gen3 one +11:39 < mturquette> geertu: ah, I see. Thanks. +11:39 < geertu> so you want to look for CLK_TYPE_GEN3\ +11:40 < geertu> For Gen3 we support a single SoC only +11:40 < geertu> I mainly did the Gen2 version (for r8a7791 only) to validate the approach, as we have more hardware support there +11:41 < geertu> To support SoC-family and SoC-specific tables, I just need to split cpg_mssr_info.core_clks[] into two arrays +11:41 < mturquette> geertu: I see. Thanks. +11:42 < geertu> and call the SoC-family cpg_clk_register() from the SoC-specific .cpg_clk_register() callback +11:42 < mturquette> geertu: using an enum/flag or splitting it per-clock/per-soc tables, either way is fine with me. +11:42 < dammsan> geertu: i think your code looks clean and easy to read +11:42 < mturquette> ack. +11:43 < mturquette> and it looks like the array of clock data follows the hierarchy? that's always nice. +11:43 < mturquette> (at least for cpg) +11:43 < geertu> mturquette: yes, each entry has a parent clock +11:43 < geertu> (div6 clocks with multiple parents are not yet supported) +11:44 < geertu> (but support can be added, of course) +11:44 < dammsan> geertu: it looks like your V4 series is based on the old Gen3 driver? +11:44 < dammsan> clk-rcar-gen3.o +11:45 < dammsan> i mean the code base includes the old driver, but it is not used +11:46 < dammsan> or am i misunderstanding? +11:47 < geertu> dammsan: you mean in renesas-drivers.git? +11:48 < dammsan> i suppose you simply based your tree on the old implementation +11:48 < geertu> yes +11:48 < dammsan> i mean the V4 series +11:48 < dammsan> The [5/5] Makefile hunk gives you away =) +11:49 < geertu> one moment please, there's a delivery here... +11:53 < dammsan> mturquette: so on your side, with the DT binding, when do you think it can end up in -next? +11:53 < dammsan> (we tend to treat it as semi-stable once it hits -next) +11:53 < dammsan> maybe semifreddo is a better word =) +11:55 < mturquette> geertu: are you planning to send a PR? +11:55 < mturquette> dammsan: I have answered your question with a question. +11:59 < dammsan> mturquette: a question to me, or to geertu? =) +11:59 < dammsan> (i can't seem to locate the answer/question in my history) +12:00 < geertu> mturquette: it's just patches 1 and 2 of the series, right? +12:01 < geertu> Is it worth sending a pull request for that? +12:01 < mturquette> geertu: I'm confused. I will finish reviewing all 5 patches later today. I can either merge them directly (if there are no problems) or you can send me a PR with any other outstanding renesas clk patches. +12:02 < mturquette> geertu: but I'm confused by your comment about "just patches 1 and 2" +12:02 < geertu> mturquette: bindings are patches 1 (binding doc) and 2 (clock defines) +12:02 < dammsan> geertu: do you feel the driver bits need more time to stabilize before merging upstream? +12:02 < geertu> mturquette: 3-5 are implementation, which can use some review and need a bit of rework +12:03 < geertu> dammsan: there are FIXMEs and too many debug prints +12:03 < mturquette> geertu: Then lets keep all 5 together. No reason to merge "dead code" +12:03 < dammsan> geertu: ok, no problem +12:03 < geertu> Does that mean we postpone everything to v4.5? +12:04 < geertu> I thought the plan was to get the bindings accepted in v4.4 +12:04 < geertu> so we know what we're working against (binding-wise) for v4.5 +12:04 < dammsan> that would be very nice yes +12:04 < mturquette> geertu: that's fine, i can merge them if you would like. +12:05 < dammsan> so a separate PR with patch 1 + 2? +12:05 < mturquette> geertu: but once a Linux release is made they considered somewhat stable +12:05 < mturquette> No PR necessary. I was only asking if geertu planned to send a PR already. +12:05 < dammsan> ok sweet +12:06 < geertu> yes, thx +12:06 < dammsan> geertu: so i looked through patch 1 + 2 +12:06 < mturquette> (I prefer PRs because I invariably miss something when it is left up to me to pick patches ;-) +12:06 < dammsan> and they look good +12:06 < geertu> Has anyone reviewed include/dt-bindings/clock/r8a7795-cpg-mssr.h? +12:06 < dammsan> geertu: do you need anything from me? +12:06 < geertu> OK, will send a PR later today +12:06 < geertu> for patches 1 and 2 +12:07 < geertu> dammsan: Reviewed-by? +12:07 < dammsan> sure, i will go through once more tonight and reply to public space +12:07 < mturquette> geertu: feel free to add my Ack to both patches +12:08 < geertu> The defines are based on Table 8.2a +12:08 < geertu> ("List of Clocks [R-Car H3]") +12:08 < dammsan> thanks, will check +12:09 < dammsan> will get back to you later tonight JST +12:10 < geertu> mturquette: ok, thx +12:13 < geertu> BTW, the bindings mention r8a7791 too. I guess I better leave that out for now. +12:16 < geertu> Any other clock related topics? +12:16 < mturquette> geertu: None from me. +12:16 < geertu> OK, next topic +12:16 < geertu> 1. Upcoming Gen3 development for the Core group, +12:17 < geertu> shimoda-san/morimoto-san? +12:17 < shimoda> yes, please wait.. +12:20 < shimoda> ipmmu, and rcar-dmac is needed by end of Nov. +12:20 < shimoda> dammsan is working for ipmmu now +12:21 < shimoda> who is working for rcar-dmac? but, it is not needed for gen3 binding? +12:21 < geertu> No one is working on rcar-dmac. +12:21 < shimoda> about ipmmu, it is a prototype code +12:21 < dammsan> shimoda: yes, and i have not managed to get the ipmmu working yet +12:22 < geertu> If ipmmu and rcar-dmac are the only items, and ipmmu is being worked on, I guess we should move to Topic 3. rcar-dmac: pick up the patches, fix the DMA engine API and save the world +12:22 < shimoda> geertu: yes, let's move to topic 3 +12:23 < geertu> So several patches have been sent by Hamza from Visteon, who is using SCIFA on H2 to talk to Bluetooth +12:24 < geertu> Laurent is the most knowledgeable about the rcar-dmac driber, but he has no time/no mandate to work on it +12:24 < geertu> Several issues can be traced back to core DMA engine API issues +12:25 < geertu> Lars-Peter Clausen has planned to work on DMA engine issues +12:25 < dammsan> geertu: to reproduce these issues, would it make sense to create a loopback SCIF setup for everyone? +12:25 < geertu> None of the above is Gen3-specific though +12:26 < geertu> dammsan: That's one option. +12:26 < dammsan> do we have any better test target? +12:27 < geertu> dammsan: Better would be one SCIF(A) to another SCIF(A) +12:27 < dammsan> (i have much faith in the current state of the SCIF driver, as opposed to other drivers) +12:27 < dammsan> sure +12:27 < geertu> Plain SCIF doesn't work well with "high" (read: medium) speeds +12:27 < dammsan> ideally we would like to test both, right? +12:27 < geertu> Note that Gen3 doesn't have SCIFA, but HSCIF +12:27 < dammsan> ah, right +12:27 < geertu> My breadboard wiring setup doesn't work well for multi-Mbps +12:28 < dammsan> is that on gen2? +12:28 < geertu> If you use loopback, the same spinlock is taken for RX and TX paths +12:28 < geertu> dammsan: yes, koelsch +12:29 < geertu> dammsan: haven't done much with the Salvator-X yet +12:29 < dammsan> loopback = external loopback circuit, or in-uart config? +12:29 < geertu> (except for CPG ;-) +12:29 < dammsan> right, no stress =) +12:29 < geertu> dammsan: I was thinking about external loopback, but SCIF indeed has internal loopback, too +12:29 < geertu> dammsan: no pinctrl nor EXIO connectors needed for internal loopback ;-) +12:30 < dammsan> right, but SCIF only +12:30 < dammsan> or how about HSCIF? +12:30 < geertu> same for HSCIF +12:30 < geertu> (HSCIF is SCIF on steroids) +12:30 < geertu> (SCIFA is SCIF on different steroids) +12:31 < geertu> (SCIFB is SCIFA on more steroids) +12:31 < geertu> What do we do with rcar-dmac? +12:33 < shimoda> How about loopback test of HSCIF? +12:33 < pinchartl> (hello) +12:34 < shimoda> hello! +12:35 < geertu> (Lars-Peter Clausen is already posting DMA engine API patches, cool) +12:36 < geertu> pinchartl: Right on time ;-) +12:36 < pinchartl> give or take an hour and a half, yes. sorry about that +12:37 < geertu> For now I'll add a task to start caring for rcar-dmac +12:37 < pinchartl> regarding rcar-dmac +12:37 < pinchartl> I don't have much time to spend on it +12:37 < pinchartl> but I can find time to review patches +12:37 < pinchartl> including dma engine core patches +12:38 < geertu> good to hear that! +12:38 < pinchartl> I believe a discussion with Lars, Vinod and possibly others would be useful to draft a future for the dma engine API +12:38 < pinchartl> it's growing in an uncontrolled fashion today +12:39 < geertu> Both were at ELCE. Will they be at Kernel Summit? +12:39 < pinchartl> unfortunately not +12:40 < geertu> As we're running (ran) out of time... +12:40 < geertu> 4. Status check for tasks from last meeting - what is remaining? +12:40 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list +12:41 < geertu> Not much has happened here +12:41 < geertu> Except for "Propose API to obtain mode pin values in a generic way" +12:41 < geertu> which Magnus wanted to discuss, but horms is not here? +12:42 < dammsan> right +12:42 < dammsan> CMA is not yet enabled I think +12:42 < dammsan> but it can wait a bit longer +12:42 < dammsan> (same as other stuff) +12:42 < dammsan> maybe simon will join next time +12:43 < dammsan> and we can discuss the boot mode API then +12:43 < geertu> ok +12:44 < geertu> Anything else to discuss in the -14 minutes we have left? +12:44 < dammsan> not from my side =) +12:44 < pinchartl> speaking of next time, geertu, could you please CC me when you'll send the next invitation ? I'll then add it to my calendar immediately. I had missed this one +12:45 < geertu> pinchartl: sorry, aren't you on periperi? +12:45 < pinchartl> yes I am +12:45 < pinchartl> but mails on CC have less chance to slip through the cracks +12:46 < pinchartl> I read periperi +12:46 < pinchartl> but I've missed that mail for some reason +12:46 < geertu> oops +12:46 < geertu> Thanks for joining, CU next time! +12:46 < geertu> Bye +12:47 < dammsan> thanks, see you in 2 weeks =) diff --git a/wiki/Chat_log/20151030-io-chatlog b/wiki/Chat_log/20151030-io-chatlog new file mode 100644 index 0000000..8d8a24a --- /dev/null +++ b/wiki/Chat_log/20151030-io-chatlog @@ -0,0 +1,196 @@ +--- Log opened Fri Oct 30 09:45:18 2015 +09:45 -!- wsa_ [~wsa@p4FE255A0.dip0.t-ipconnect.de] has joined #periperi +09:45 -!- Irssi: #periperi: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal] +09:45 -!- Irssi: Join to #periperi was synced in 0 secs +09:45 < wsa_> hi there +09:45 < geertu> Hi Wolfram +09:46 < wsa_> hi geert +09:51 < wsa_> shall we maybe meet somewhere else (#periperi-io) so other people can stay here? +09:54 < geertu> Fine for me +09:55 < wsa_> done +09:55 < wsa_> I can't reproduce any of the issues pinchartl is seeing on Magnus' Koelsch :( +09:56 < wsa_> using his config and renesas-drivers-2015-10-27-v4.3-rc7 +09:56 < geertu> Laurent and I both a version with a U-Boot that keeps MSTP clocks running +09:57 < geertu> I do see i2c failures with recent kernels since I enabled DU and friends +09:57 < wsa_> i should be able to emulate that with some 'mw' magic, or? +09:57 < geertu> I do run patches that disable MSTP clocks early in boot +09:57 < geertu> I'll email them to you +09:58 < wsa_> disable? +09:58 < wsa_> i thought your version keeps them running? +09:58 < geertu> yeah, I'm a bit puzzled, as I'd expect _you_ to see failures, not Laurent/ +09:59 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi +09:59 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi +09:59 < geertu> Ah, the "real cold boot" of Koelsch now fails every day with an interrupt storm due to i2c not working for the regulator quirk +09:59 < wsa_> hmm, i think i'd prefer your uboot binary so can load it second stage to RAM +10:00 < wsa_> hello shimoda-san, morimoto-san +10:00 < shimoda> hello wolfram-san! +10:00 < wsa_> please join #periperi-io for the meeting +10:00 < shimoda> i got it +10:01 < wsa_> geertu: my best guess so far is that because of running clocks (and some weird leftover states from the bootloader) the IP core is an unknown state and not properly reinitialized yet +10:03 < geertu> Morimoto-san's "[PATCH] i2c: rcar: call rcar_i2c_init() after pm_runtime_get_sync()" doesn't fix the regylator interrupt storm at boot :-( +10:04 < geertu> If I keep he kernel running until the IRQ subsystem kills the interrupt, usually next reboot works +10:04 < wsa_> geertu: is that with koelsch, too? +10:04 < geertu> yep +10:04 < wsa_> please send me your .config +10:04 < wsa_> and now for the meeting +10:05 < geertu> It started earlier this week +10:05 < wsa_> :) +10:05 < geertu> Issue only happens if I power the board off for a long enough period (i.e. usually at night) +10:06 < geertu> OK, boot completed +10:06 < geertu> resetting +10:06 < geertu> and still working... +10:08 < wsa_> WTF? +10:48 < geertu> BTW, I will most probably have a day off on Wed and Thu +--- Log closed Fri Oct 30 10:52:49 2015 +--- Log opened Fri Oct 30 09:54:50 2015 +09:54 -!- wsa_ [~wsa@p4FE255A0.dip0.t-ipconnect.de] has joined #periperi-io +09:54 -!- ServerMode/#periperi-io [+ns] by hitchcock.freenode.net +09:54 -!- Irssi: #periperi-io: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal] +09:54 -!- Irssi: Join to #periperi-io was synced in 0 secs +09:55 -!- geertu [~geert@d54C36A7B.access.telenet.be] has joined #periperi-io +10:01 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi-io +10:01 < morimoto> Hi +10:01 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi-io +10:02 <@wsa_> hello +10:02 < shimoda> hello! +10:02 <@wsa_> let's wait one more minute for simon +10:03 <@wsa_> if he doesn't show up, we'll put this topic last +10:05 <@wsa_> so +10:05 <@wsa_> let's get this done fast and concentrated :) +10:05 < shimoda> :) +10:05 -!- horms [~horms@penelope-musen.kanocho.kobe.vergenet.net] has joined #periperi-io +10:06 <@wsa_> SDHI DMA: is the BSP team happy with the suggested workflow? +10:06 <@wsa_> hi simon, just in time +10:06 < horms> Apologies for not being more punctual +10:06 < shimoda> i make some patches of SDHI DMA for BSP team :) +10:07 < shimoda> so this patch set will release in early next month as renesas-bsp +10:07 < shimoda> .git +10:07 <@wsa_> great! +10:07 <@wsa_> then we can have a look about further refactoring +10:08 <@wsa_> how did PTP come along? +10:08 < shimoda> yes, I think we have to refactor the tmio driver somehow :) +10:09 < horms> wsa_: regarding ptp +10:09 < horms> I have looked over the bsp after learning it contains the required functionality +10:09 <@wsa_> shimoda: (yes, i think so, too. but let's talk over the code when it is available in git) +10:10 < horms> it seems to me that the only relevant code that is not upstream is to correct an assubmption that the input clock is running at 130MHz: as was the case on Gen2. +10:11 < horms> On the r8a7795 I believe the situation is that it should run at 133MHz, but due to the extal being 16.6Mhz rather than 33MHz it runs at half that speed. i.e. 66.6Mhz. +10:11 < shimoda> wsa_: agreed +10:11 < horms> I think the answer is to have the driver use the speed of its clock to set the register in question +10:11 < horms> i plan to see about implementing that +10:12 <@wsa_> okay, this sounds like a bit of work, but no major obstacle? +10:12 < horms> yes, i think so +10:12 <@wsa_> knock on wood :) +10:12 < horms> I think the main questin will be if the binding needs changing. to my mind the answer is "hopefully not" +10:13 < horms> in theory other clocks could be relevant +10:13 < horms> but in practice the hw only accepts using the high-speed peripheral clock (or what that was renamed to in gen3) +10:13 < horms> so fingers crossed it should not be too difficult to resolve in an upstreamable manner +10:14 * wsa_ crosses fingers +10:14 <@wsa_> thanks simon +10:14 <@wsa_> about PCIE +10:14 <@wsa_> I tested Phil's patches, and they turned out to go into the right directon, but being unusable for now +10:15 <@wsa_> even introducing a build error +10:15 < horms> :( +10:15 <@wsa_> Bjorn wants to drop the branch which would also be my favourite solution +10:16 < horms> thats fine by me. I'll be more careful with Phil's patches in future +10:16 <@wsa_> but i didn't want to suggest it directly because i wanted to be careful (from a diplomatic point of view) +10:16 < horms> do you need me to respond to the thread? +10:17 <@wsa_> if you want, but i don't think it is needed +10:17 < horms> ok +10:17 < horms> i prefer to take a back-seat with PCIe unless action is required +10:17 < horms> if the wheels fall off I'm happy to step in :) +10:18 <@wsa_> okay, thanks +10:18 <@wsa_> watchdog +10:18 < horms> from my pov phil should know what he is doing. its unfortunate if that isn't the case +10:18 < horms> but i will be more watchful +10:19 <@wsa_> make sure his patches get build tested +10:19 < horms> can do +10:19 <@wsa_> i also think that he knows what he is doing in general +10:19 <@wsa_> but this series wasn't his best one +10:19 <@wsa_> for whatever reason +10:19 < horms> ok +10:19 <@wsa_> watchdog ;) +10:20 <@wsa_> my current plan is to release the next version in the second week of November +10:20 <@wsa_> shimoda: will this be enough? or is it needed before that? +10:21 < shimoda> BSP point of view, they need next Wed. :) +10:22 < shimoda> however, they can use your current patch too +10:22 <@wsa_> i'll se what i can do +10:23 <@wsa_> how are the other deadlines? +10:23 < shimoda> thank you! +10:23 <@wsa_> did something urgent show up I missed so far? +10:24 < shimoda> about i/o group, no other deadlines, i think +10:25 <@wsa_> good +10:26 <@wsa_> so major topic seems to be i2c now :( +10:26 <@wsa_> i'll do some more debugging but if I can't reproduce the issues, I probably have to revert the latest r-car series +10:26 < shimoda> i think so ;) +10:27 < morimoto> About Laurent issue do you mean ? +10:27 <@wsa_> geert has some, too +10:27 <@wsa_> all on koelsch +10:28 < morimoto> OK +10:28 <@wsa_> but it doesn't show on Magnus Koelsch +10:28 <@wsa_> where i have remote access to +10:28 < morimoto> which ES number used ? +10:29 < morimoto> do you know ? +10:29 <@wsa_> I asked geert for his u-boot binary so I can start this second stage from RAM +10:29 < geertu> how do I get the U-Boot binary? +10:29 < geertu> raw QSPI contents +10:29 < geertu> ? +10:29 < geertu> Detected Renesas R-Car M2-W ES1.0 +10:29 <@wsa_> I thought you have patches to u-boot? +10:29 <@wsa_> Laurent reported: +10:29 <@wsa_> RTPORC7791SEB00010S +10:29 <@wsa_> KOELSCH SN.057 +10:30 < geertu> My Koelsch is SN.192, and Laurent's is older,so it should be ES1.0 too +10:30 < geertu> Mine ends with 11S +10:31 < geertu> Aha, different board revision too +10:31 <@wsa_> geertu: are those identification patches some way upstream? +10:31 < geertu> No, old version on periperi +10:31 < shimoda> about u-boot code of gen2: git://git.denx.de/u-boot-sh.git +10:31 < geertu> Can email out a new one, moved to drivers/soc and supporting H3 and M3-W +10:32 < shimoda> origin/renesas/bsp/rcar-gen2-7 branch is the latest +10:32 < geertu> yep, checkout b6af5fc +10:32 < geertu> Probably Wolfram (Magnus) has the latest version, in Dublin we saw it was from spring 2015 +10:32 <@wsa_> geertu: new version sounds good +10:32 < geertu> So I have ver=U-Boot 2013.01.01-gb6af5fc (Nov 12 2013 - 14:33:51) +10:33 < geertu> wsa_: but you don't see the issue on new versions? +10:33 <@wsa_> nope +10:33 <@wsa_> morimoto: can we get a "changelog" for Koelsch board revisions? +10:33 <@wsa_> does something like this exist? +10:34 < morimoto> do you mean "board" changelog ? +10:34 <@wsa_> yes +10:34 < morimoto> let me check +10:35 <@wsa_> okay, i more and more get the impression i should revert the changes +10:35 < geertu> "[PATCH] [LOCAL] ARM: shmobile: Print SoC Product Version" sent to periperi +10:35 <@wsa_> they need more time (and not quick hacks) on some Koelsch boards +10:37 <@wsa_> please note that i am away next week +10:38 <@wsa_> i might be able to respond to emails +10:38 <@wsa_> i think we are done unless one of you has a topic left +10:39 < horms> none from my side +10:40 < morimoto> Can I interrupt ? The issue if for HDMI chip access ? +10:40 < morimoto> /if/is/ +10:40 <@wsa_> yes +10:41 <@wsa_> adv7180 +10:41 < morimoto> Thanks +10:41 < geertu> "Your message to periperi awaits moderator approval" +10:41 < horms> oh! +10:41 < geertu> geert+renesas is not a member ;-) +10:42 < horms> did you post just now? +10:42 < geertu> yes +10:42 < geertu> the patch I mentioned above +10:43 < horms> ok, i'll try and approve the post and whitelist your address +10:43 < geertu> thx! +10:44 <@wsa_> morimoto: can you email me your findings? +10:44 <@wsa_> they are much appreciated +10:45 <@wsa_> then, we could close this meeting +10:45 <@wsa_> and go for weekend :D (sooner or later, depending on TZ) +10:46 < shimoda> yes, thank you for the meeting! +10:46 < morimoto> Now, HW team is not here, I asked to them via email. please wait +10:46 <@wsa_> will do +10:46 <@wsa_> cya all! +10:47 < geertu> bye! +10:47 < morimoto> I will have day off on Mon, and Tue is Holiday in Japan. +10:47 < geertu> Have a nice weekend +10:47 < horms> enjoy +10:47 < morimoto> shimoda-san is OK in Mon, so please care it >> shimoda-san +10:47 < shimoda> have a nice weekend! +10:47 < morimoto> bye +--- Log closed Fri Oct 30 10:52:49 2015 diff --git a/wiki/Chat_log/20151106-core-chatlog b/wiki/Chat_log/20151106-core-chatlog new file mode 100644 index 0000000..d3ad5ad --- /dev/null +++ b/wiki/Chat_log/20151106-core-chatlog @@ -0,0 +1,389 @@ +Core-chat-meeting-2015-11-06 + +10:04 < geertu> Agenda: +10:04 < geertu> 1. Upcoming Gen3 development for the Core group, +10:04 < geertu> 2. Gen3 integration - ARCH_R8A7795 / ARCH_RENESAS - serial0:115200n8 - GIC/GICH/GICV +10:04 < geertu> 3. Status check for tasks from last meeting - what is remaining? +10:04 < geertu> Topic 1: Upcoming Gen3 development for the Core group +10:04 < horms> I can also speak to some gen2 ingegration work if there is time +10:05 < geertu> OK, let's cover that with Topic 2. +10:05 < horms> With regards to topic 1, Morimiti-san, do you want to talk about sound? +10:05 < horms> wow, super bad typing. I meant morimoto` +10:06 * geertu thought it was modern Greek where all vowels became 'i' +10:06 < morimoto`> I posted sound patch-set to SH/ARM ML +10:06 < horms> ok, just now? +10:06 < morimoto`> It might have compile issue +10:06 < horms> ok, we can handle that on the ML. thanks for your emails earlier today +10:07 < morimoto`> But it seems nothing happen on latest ARM branch (?) +10:07 < morimoto`> np +10:07 < morimoto`> My issue is that there is DMA_OF wrong dependency issue +10:07 < morimoto`> I already posted fixup patches to DMA ML +10:07 < horms> i think the summary for the gruop is that sound for gen3 is moving forwards, but we have some tedious dependencies in the short term +10:08 < morimoto`> Vinod accepted it, but he decided it goes to topic branch instead of fixup branch +10:08 < horms> bother +10:08 < horms> can we ask him to reconsider? +10:09 < morimoto`> Him = Vinod ? +10:09 < geertu> It causes build errors, right? +10:09 < horms> Yes, Vinod. +10:09 < morimoto`> build error will happen if +10:09 < morimoto`> 1) .config has CONFIG_OF, but doesn't have DMA_OF +10:09 < morimoto`> but it seems latest branch defconfig have both. +10:10 < morimoto`> So, no build error I think +10:10 < morimoto`> But, I don't know which branch goes to Linus/master +10:10 < horms> not for the defconfig at least +10:10 < geertu> Is this topic branch queued for v4.4 or for v4.5? +10:10 < horms> probably randconfig can find something +10:11 < morimoto`> I believe it goes to v4.4 +10:11 < horms> ok, so the breakage was added in v4.4 (pre-rc1) and the fix will probably make it to v4.4? +10:11 < geertu> So it will be upstream RSN? +10:12 < morimoto`> I believe so +10:13 < horms> It sounds to me that we can make a working system using defconfig and the non-defconfig case should be resolved in the not to distant future. So I think we are in good shape. +10:13 < geertu> So what's the problem? A small time window for a possible build failure of randconfig? +10:14 < dammsan> so it seems +10:15 < horms> I think we can move on +10:15 < geertu> yep. +10:15 < geertu> No more upcoming Gen3 development? +10:16 < geertu> s/more/other/ +10:16 < dammsan> i'm dealing with IPMMU at the moment +10:16 < pinchartl> geertu: not for core on my side. plenty of multimedia development though :-) +10:17 < dammsan> FYI, to use the IPMMU the boot loader stack needs to be updated =\ +10:18 < dammsan> i'll tackle IRQC some time in the not so distant future +10:18 < geertu> hooray +10:18 < pinchartl> dammsan: what's wrong with the boot loader ? +10:18 < dammsan> it may be easier to phrase the question the other way around +10:18 < geertu> what's wrong with the ipmmu? +10:19 < dammsan> for the IPMMU case, some piece of software is not letting through MMU interrupts +10:19 < dammsan> PMB interrupts are let through though +10:19 < geertu> (secure) firmware? +10:19 < dammsan> that's my bet +10:19 < pinchartl> nice... +10:19 < dammsan> i now have some code that can get interrupts +10:19 < dammsan> using more recent boot software +10:20 < dammsan> in such case DEBUG1 stops working too +10:20 < dammsan> so i've poked around with the loop back adapter as a plan C +10:20 < dammsan> it is a bit messy +10:20 < dammsan> expect IPMMU to take some time +10:21 < geertu> So that explains your interest in EXIO (H)SCIF ;-) +10:21 < horms> dammsan: do you have a fire extinguisher in your lab? +10:21 < dammsan> in case the printer is on fire? =) +10:21 < dammsan> the fans from the 2 salvator-x board should boost the fire well =) +10:21 < horms> thats not the use case i had in mind, but yes, in case of that too +10:22 < dammsan> if you have trouble with some hardware consider upgrading the boot loader software +10:22 < dammsan> but it is a PITA so i don't recommend it unless it is absolutely necessary +10:23 < dammsan> you will notice if you are blocked on that +10:23 < dammsan> let me know if so +10:24 < dammsan> no other activities planned here +10:25 < shimoda> dammsan: I guess if we have to use memory more (more 1GB), we have to upgrade the boot loader +10:25 < dammsan> yeah +10:25 < dammsan> SMP may need some help too +10:26 < shimoda> I think so +10:26 < dammsan> we should consider how to handle caches +10:26 < dammsan> both on gen2 and gen3 +10:27 < dammsan> ideally before enabling SMP in my opinion +10:27 < dammsan> what does the mighty core group leader say? +10:27 < geertu> I have patches to describe the caches, as part of the SYSC PM Domain work +10:28 < geertu> That was a bit put aside due to the CPG rework +10:28 < dammsan> completely understandable +10:28 < dammsan> seems the bindings are in now +10:28 < geertu> Yes, CPG/MSSR bindings are in. +10:28 < geertu> Which brings us to Topic. Gen3 integration +10:28 < dammsan> very nice! +10:29 < horms> ok, so there are a few outstanding questions from the postings of v11 and v12 of the basic patchset; which I have been handling since ELCE +10:29 < geertu> Simon wanted to discuss 4 integration things +10:30 < geertu> a. ARCH_R8A7795 (and ARCH_RENESAS?) +10:30 < horms> overall I'm tempted to label them as bikeshedding. But none the less I7d like to get some consensus amongst us before moving +10:30 < dammsan> i agree and i agree =) +10:30 < geertu> Summarized: Catalin wants to get rid of SoC-specific Kconfig options. "Use SoC+driver0specific Kconfig options +10:31 < horms> See: http://www.spinics.net/lists/arm-kernel/msg457009.html +10:31 < horms> my reading is that he asked if we need ARCH_R8A7795 +10:31 < geertu> Personally, ... ah, your link covers that +10:31 < horms> and given the way pfc and cpg work +10:31 < horms> i think the answer is yes, we need it +10:32 < geertu> Perhaps they like it more if we call it CONFIG_QUIRK_R8A7795? ;-) +10:32 < pinchartl> we only need it if we want to keep the kernel size reasonable +10:32 < geertu> yes +10:32 < horms> yes +10:32 < pinchartl> and that's a reasonable thing to do :-) +10:32 < dammsan> the newer boot loader has reduced the amount of memory =) +10:32 < geertu> So I like hiding it under CONFIG_EXPERT +10:32 < dammsan> geertu: i like that too +10:32 < horms> sure, that sounds fine to me +10:33 < horms> will you replay to Catalin or should I (next week)? +10:33 < dammsan> horms: i prefer if you can come to an agreement with him +10:34 < horms> sure, will do +10:34 < dammsan> thanks +10:34 < horms> shall we move to b.? +10:34 < geertu> I'd ike to ask about ARCH_RENESAS +10:34 < horms> sure +10:34 < horms> this serves two purposes. +10:34 < geertu> So the patch description mentioned it may also apply to SH +10:35 < horms> the technical one I tried to describe on the ML +10:35 < horms> and also a non-techincal one: a red-herring for the ARM-SoC maintainers desire to see cleanups +10:35 < horms> yes, it did mention that +10:35 < geertu> There's lots of overlap between arm64 and arm32 +10:35 < geertu> less between arm32 and SH +10:35 < horms> yes +10:35 < horms> the reason i mentioned it is to cover that overlap +10:36 < geertu> even less between SH and H8 (e.g. SCI) +10:36 < horms> but perhaps it not needed +10:36 < geertu> any overlap with m32r? +10:36 < horms> ideally I'd like to see SHMOBILE disapear from drivers used by arm socs +10:36 < horms> i didn't investigate deeply, but grep didn't show any +10:36 < horms> the thing is that r-car, which is the focus for renesas, is neither SH nor mobile +10:37 < geertu> So for now the "RENESAS" flag would cover Renesas arm32 and arm64 SoCs +10:37 < horms> yes +10:37 < horms> and if that is sufficient that SHMOBILE is not used by those SoCs then the work can stop there +10:37 < horms> or it can keep going if there is some reason to +10:37 < geertu> Fine for me. But please drop the reference to SH? +10:38 < horms> Sure, can do +10:38 < horms> sorry for the confusion that generated +10:38 < geertu> NP +10:38 < horms> shall we move to c.? +10:39 < geertu> Subtopic b. serial0:115200n8 +10:39 < horms> See: http://www.spinics.net/lists/linux-sh/msg46481.html +10:39 < horms> I'm inclinded to not add :115200n8. But I'd value your opinion. +10:40 < geertu> As DT describes "the hardware" (chosen describes configuration), I don't mind adding it. +10:40 < geertu> There's plenty of opportunity to fix this for v4.5 +10:40 < horms> sure, that sounds reasonable +10:40 < horms> but what about earlycon. do we care? can it be compatibile? +10:41 < geertu> As the standard console parses stdout-patch correctly, I think earlycon should follow suit +10:41 < horms> ok, thats reasonable +10:41 < dammsan> sounds reasonable +10:41 < geertu> I'm still a bit puzzled by earlycon on arm32. +10:41 < geertu> Apparently it works on some platforms. +10:41 < horms> i'll see about adding :115200n8 to v13 +10:41 < horms> what about gen2. do you want to talk about that? +10:41 < geertu> yes +10:41 < horms> s/gen2/32-bit arm/ +10:42 < geertu> Earlycon is very valuable: it's intended to replace debug_ll ,which does not exist anymore on arm64 +10:42 < horms> so i'm ok with updating our 32-bit SoCs. but is there a backwards compatibility issue? +10:42 < geertu> It helped me a lot debugging the L1_CACHE_BYTES issue on Salvator-X +10:42 < dammsan> i agree that early output is very valuable +10:42 < horms> i definately don't want to stand in the way of making useful tools work :) +10:42 < geertu> I don't see a backwards compatibility issue +10:43 < horms> ok, shall we move forwards on the 32-bit side too? +10:43 < geertu> For arm32, I think we need a "JTAG expert" to look into it +10:43 < horms> earlycon? +10:43 < geertu> yes +10:43 < horms> ok, but that is orthogonal to your proposed dts change, right? +10:44 < geertu> yes. +10:44 < horms> ok, got it. feel free to send that patch any time. if its rough i can clean it up. +10:44 < geertu> earlycon does an early mapping of the serial port. Apparently it maps something (no crash), but nothing is output on the serial potty +10:44 < geertu> s/potty/poty/ +10:44 < geertu> s/potty/port/ +10:44 < horms> with regards to jtag, perhaps morimoto-san could help out? +10:44 < geertu> or Ulrich? +10:45 < uli___> what exactly is the issue there? +10:46 < geertu> earlycon doesn't output anything on R-Car Gen2 (and other "shmobile", IIRC) +10:46 < dammsan> we had a different implementation for non-multiplatform earlier +10:46 < geertu> Until recently, it didn't work at all, as arm32 didn't have early fixmap support +10:46 < geertu> earlyprintk? +10:46 < dammsan> yeah +10:47 < uli___> ah, i see. i remember using that, so i was wondering... +10:47 < uli___> which platforms are known to be broken? +10:47 < uli___> boards, i mean +10:47 < dammsan> all? +10:47 < pinchartl> do we need earlycon or is earlyprintk enough ? +10:47 < geertu> earlycon is platform-agnostic +10:48 < dammsan> earlyprintk used to be compatibile with SH +10:48 < geertu> and The Way Forward(tm) +10:48 < geertu> I think it's also "more early" than earlyprintk +10:48 < dammsan> but then earlycon came around =) +10:48 < horms> why use something that works when you can invent something new to spend years fixing? +10:48 < geertu> On last renesas-drivers, applying Sata-san's SCIF EARLYCON patch should give you working earlycon on Salvator-X +10:48 < geertu> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/364178.html +10:49 < pinchartl> which of the two is the one that requires the assembly header with a couple of serial port functions ? +10:49 < geertu> debug_ll, which is something different +10:49 < geertu> no more debug_ll in arm64 +10:49 < geertu> earlycon uses chosen/stdout-path +10:49 < geertu> so it's compatible with real multi-platform kernels and multi-plaform debugging +10:50 < dammsan> good +10:50 < geertu> So you have debug_ll, earlyprintk, and and earlycon +10:50 < pinchartl> ok +10:50 < pinchartl> sounds so simple :-) +10:50 < geertu> Going from most-platform dependent to platform-agnostic +10:50 < geertu> s/Sata-san/Sato-san/ (forgive today's typing) +10:51 < geertu> Just add "earlycon" to the kernel command line, and you get early debugging output on about everything +10:52 < dammsan> nice +10:52 < geertu> well, that's the idea +10:52 < dammsan> i suppose we need clocks relatively earl then +10:52 < dammsan> or maybe we can make assumptions +10:52 < horms> Nice, we can add it to dt and be back to where we were with earlyprintk on our 32-bit SoCs before DT came along :) +10:52 < geertu> No, it still depends on the bootloader to set up the serial port +10:53 < dammsan> gotcha +10:53 < geertu> But selection of the serial port is now done in "the same way" as the regular serial console +10:53 < geertu> i.e. chosen/stdout-path +10:54 < pinchartl> geertu: how is the serial port driver involved in earlycon ? +10:54 < morimoto`> (dammsan goes to other Renesas meeting) +10:54 < pinchartl> tell me there's no early platform device... +10:55 < geertu> OF_EARLYCON_DECLARE +10:55 < pinchartl> I should have guessed that :-/ +10:55 < geertu> https://progressive-comp.com/?l=linux-sh&m=143366932126892&w=2 +10:57 < geertu> Subtopic c. GIC/GICH/GICV +10:57 < horms> BTW, do you know who Sato-san is? +10:58 < geertu> The h8300 guy +10:58 < horms> c. is here http://www.spinics.net/lists/arm-kernel/msg457615.html +10:58 < horms> ok, makes sense +10:58 < geertu> who's using earlycon on h8 ;-) +10:58 < geertu> back where it all started? +10:58 < horms> so regarding GIC +10:58 < horms> do we need to do anything? +10:59 < geertu> Are the virtualiation regs documented in later versions (>0.5) of the datasheet? +10:59 < horms> I'm unsure. Shall we speculate and check later? +11:00 < horms> perhaps morimoto-san` or shimoda-san know +11:01 < shimoda> i greped the datasheet of rev0.5, "virtualization" is only in overview section +11:01 < shimoda> it is a function of CA57 +11:02 < shimoda> so, i guess it is described in a documentation of ARM +11:02 < geertu> But the actual addresses of the register banks of the GIC are SoC-specific, right? +11:02 < geertu> And the Gen3 datasheet only describes banks 1 and 2 +11:05 < shimoda> which page does it described? +11:05 < shimoda> about the bank +11:05 < geertu> 12A3 +11:06 < geertu> 533 +11:07 < geertu> INTC-AP H'F102 0000 √ √ +11:07 < geertu> H'F101 0000 √ √ +11:07 < geertu> CPU-IF +11:07 < geertu> INTC-AP +11:07 < geertu> ar +11:07 < geertu> Distributor-IF +11:07 < geertu> Someone edited the table, so Copy-'n-paste no longer grabs the cells in the "normal" order +11:08 < shimoda> thank you, I found it +11:10 < shimoda> and these CPU-IF and Distributor-IF are written into r8a7795.dtsi +11:11 < morimoto`> geertu: sorry what is your question/concern ? it should have more information ? +11:11 -!- shimoda [~shimoda@relprex2.renesas.com] has quit [Quit: WeeChat 0.4.2] +11:11 < geertu> Documentation/devicetree/bindings/arm/gic.txt +11:12 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi +11:12 < geertu> GIC virtualization extensions (VGIC) means 2 more register bankds +11:12 < geertu> s/bankds/banks/ +11:12 < geertu> Documentation/devicetree/bindings/arm/gic.txt +11:15 < morimoto`> Does your question is that it should have bank 3, and 4 ? +11:17 < geertu> Yes, according to Mark Rutland +11:17 < geertu> Unless the H3 GIC doesn't have virtualization extensions, of course ;-) +11:18 < horms> do we also need to know the maintenance irq? +11:18 < geertu> I think so +11:19 < morimoto`> Actually, today we got errata sheet, and I checked it now. but it doesn't include this. +11:19 < morimoto`> So, I will ask to HW/Manual guys +11:19 < horms> thanks +11:20 < horms> it seems to me that we re blocking on this one +11:20 < geertu> yes +11:20 < horms> geertu is that your understanding? +11:20 < geertu> thanks for asking +11:20 < horms> ok +11:20 < morimoto`> Can I confirm ? bank 3/4 are because of 4 cpu ? +11:20 < geertu> so let's leave the dtsi like it is for now +11:20 < horms> i will likely not post v13 in the near future +11:20 < geertu> morimoto: no, because of virtualization extensions +11:20 < horms> unless there is a pressing need for it +11:21 < geertu> subtopic d. Gen2 integration +11:21 < morimoto`> OK, I see. thanks +11:21 < horms> ok, this i think we sould not spend much time on +11:21 < horms> I expect that in general it will be a topic that would be well named after a book I recently purchased "Argument Without End". +11:22 < horms> The quick summary is that Magnus has asked me to make sure we have more uniform coverage on the integration side for our various (32-bit) socs +11:22 < horms> I have started by focusing on R-Car Gen 2 +11:22 < horms> and the thermal patch I sent earlier today is the first cab of the rank +11:23 < horms> in short lager and koelsch seem to be in pretty good shape +11:23 < horms> but it gets much thinner on the ground when looking at the other SoCs and boards +11:23 < geertu> It would be good if we could "share" more dtsis +11:24 < horms> yes, its quite repeditive +11:25 < horms> but the current dts files distinguish between the different socs in terms of defines (easy to resolve I suppose) and per-soc bindings (see title of book above!) +11:25 < horms> perhaps the dts files can be generated some how +11:26 < horms> anyway, i just wanted to mention i'm putting some energy into that +11:26 < geertu> Having more docs (incl. schematics) could help, too. +11:26 < pinchartl> horms: I'll refrain to comment on that last point :-) +11:27 < geertu> I can just guess that e.g. goose is similar to koelsch +11:27 < horms> i managed to get docs from morimoto-san earlier today +11:27 < horms> so i am guessing less now +11:27 < horms> there is also the gen2 bsp +11:28 < geertu> OK +11:28 < horms> in any case, i suggest we move on and come back to this another time: its likely to be around for a while and its very non-urgent +11:28 < geertu> We're running out of time. Can we continue +11:28 < geertu> ok +11:28 < geertu> Topic 3. Status check for tasks from last meeting - what is remaining? +11:29 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list +11:29 < geertu> Done: +11:29 < geertu> pfc,v4.4,Add r8a7795 support +11:29 < geertu> r8a7795,v4.4,Add gpio nodes to DT +11:29 < geertu> Ack's wanted: +11:29 < geertu> pfc,v4.4,Improve documentation +11:29 < geertu> (and a few more pfc patches) +11:30 < geertu> Now Simon is here: generic,v4.4,Propose API to obtain mode pin values in a generic way +11:31 < horms> yes, i think the main issue there is how to handle initcalls (or not) +11:34 < horms> http://www.spinics.net/lists/linux-sh/msg46246.html +11:34 < horms> From my pov the *_OF_DECLARE approach seems to give the cleanest code +11:34 < pinchartl> horms: I agree with you +11:35 < pinchartl> I dislike *_OF_DECLARE though +11:35 < pinchartl> as it's an initcall-like hack +11:35 < pinchartl> but I don't have a better solution at the moment +11:35 < geertu> And the person who encounters dependency issues has to fix it herself? +11:35 < horms> right, it seems to be faustian pact +11:36 < horms> the other approach was to allow users to directly initialse things if they are running before initcalls would have kicked in +11:36 < horms> its not so clean code +11:36 < horms> but its probably harder to get wrong +11:36 < horms> for gen2 the initcall bit might be omitted entirely +11:37 < horms> unless we figure out a way that it doesn't need the modepin before initcalls +11:37 < horms> are run +11:38 < geertu> OK, let's post it to a broader audience for discussion +11:38 < geertu> Or is that a bad idea during the merge window? +11:38 < horms> i don't see any problem with posting RFCs during the merge window +11:38 < horms> do you mean that I should see linux-arm-kernel? +11:39 < geertu> And if we delay, it may be too late for v4.5 +11:39 < geertu> linux-arm-kernel and linux-kernel +11:39 < horms> ok +11:39 < geertu> perhaps Jon Corbet too, so it ends up on lwn.net? +11:39 < horms> i'll fix up the obvious problems with v1 but not convert it to *_OF_DECLARE +11:40 < horms> and probably add some text about *_OF_DECLARE being a possibility +11:40 < horms> perhaps if its going to lkml then wating for rc1 would be prudent +11:40 < horms> we don't want it to get shot down before is even been thought about +11:40 < geertu> Clearly mark it RFC +11:41 < horms> ok +11:41 < geertu> People don't (ordinarily) read lkml anyway +11:41 < horms> true +11:41 < horms> pinchartl: is the above reasonable from your pov? +11:42 < horms> I guess if its not he can ping me :) +11:43 < pinchartl> yes it's fine +11:43 < horms> thanks +11:43 < pinchartl> maybe you could mention *_OF_DECLARE as an option in the cover letter ? +11:43 < horms> btw, I would not be upset if you wanted to take your baby back under your wing :) +11:43 < horms> yes, that is what I had in mind +11:43 < pinchartl> I wish I had time to do that :-) +11:44 < horms> (does anyone read cover letters?) +11:44 < horms> understood. its an open offer +11:44 < pinchartl> thanks :-) +11:44 < horms> ok, i think we can move on +11:44 < horms> sorry for pushing things over time +11:44 < geertu> Any other topics? +11:45 < horms> not from me +11:45 < geertu> I have: [Linux Kernel development - Feature #XX] emails +11:45 < geertu> So yes, I'm receiving them +11:46 < horms> Was ist das? +11:46 < shimoda> geertu: not from me +11:46 * uli___ checks the universal translator switches +11:47 < geertu> uli: Don't speak German anymore? +11:47 < geertu> They are sent by oss-admin@lm.renesas.com +11:48 < horms> ok. do they relate to the todo lists, redmine, or something else? +11:48 < geertu> From Redmine. Am I the only one who's receiving them? +11:48 < horms> (obviously I haven't seen one) +11:48 < uli___> me neither +11:48 < pinchartl> neither have I +11:48 < geertu> OK, will forward one to periperi +11:49 < horms> good idea +11:49 < horms> i tweaked periperi so mainlan no longer enforces a message size limit +11:50 < horms> As magnus kept hitting it. +11:50 < horms> But the mail server istelf still has a limit, somwhere between 10 & 20Mb iirc +11:50 < horms> fwiw, gmail has a similar message size limit +11:53 < geertu> I guess that's why I haven't received new datasheets? ;-) +11:53 < geertu> No more topics? +11:53 < horms> I don't think it is related +11:53 < morimoto`> I got errata sheet form manual guys. do you want to have it ? +11:54 < morimoto`> for v0.5 datasheet +11:54 < geertu> yes please +11:54 < pinchartl> yes please ! +11:54 < shimoda> I heard new datasheet will come at early next year, I'm surprized +11:54 < morimoto`> OK. I will Me -> Jinso -> EuroPeri +11:54 < morimoto`> s/I/It/g +11:55 < morimoto`> and it will happen next week. +11:56 < geertu> thx! +11:56 < horms> likewise +11:57 < morimoto`> No more topic from me +11:57 < geertu> ok, then we're finished. +11:57 < geertu> Thanks for joining! diff --git a/wiki/Chat_log/20151117-core-chatlog b/wiki/Chat_log/20151117-core-chatlog new file mode 100644 index 0000000..3371d14 --- /dev/null +++ b/wiki/Chat_log/20151117-core-chatlog @@ -0,0 +1,60 @@ +Core-chat-meeting-2015-11-17 + +10:07 < geertu> Today's topics: +10:07 < morimoto> Hehe :) +10:07 < geertu> 1. Upcoming Gen3 development for the Core group, +10:07 < geertu> 2. Status check for tasks from last meeting - what is remaining? +10:07 < geertu> Topic 1. Upcoming Gen3 development for the Core group, +10:08 < geertu> (Magnus is stuck in traffic) +10:10 < geertu> Any upcoming Gen3 development for the Core group? +10:11 < shimoda> IPMMU? +10:11 < pinchartl> Magnus is still working on IPMMU as far as I know +10:11 < geertu> indeed +10:11 < pinchartl> his target was DU on Gen3 +10:12 < pinchartl> but that will require some multimedia-specific infrastructure first +10:12 < pinchartl> so I believe that particular work is stalled +10:13 < geertu> OK +10:13 < geertu> Anything else? +10:13 < shimoda> how about SYS-DMAC? +10:14 < geertu> There are a few pending patches, and some discussion +10:14 < pinchartl> what's the status of the CPG implementation for Gen3 ? +10:14 < geertu> No real development, AFAIK +10:15 < geertu> Patches submitted (v5 and v6) +10:15 < geertu> no fedback +10:15 < geertu> but the clock maintainers typically don't read email during the merge window +10:16 < pinchartl> I think we have a clock maintainer on this channel :-) +10:16 < pinchartl> but he's probably asleep +10:16 < geertu> Changes in v6 were a small bugfix and datasheet errata +10:16 < geertu> No fundamental things, so the approach still sounds sane ;-) +10:18 < pinchartl> good +10:18 < pinchartl> you had an implementation of the same approach for r8a7791, right ? +10:18 < geertu> MODEMR is also quiet, but Simon is in US +10:19 < geertu> yes, running that on Koelsch all the time +10:19 < geertu> You want to convert Gen2 now, too? +10:20 < pinchartl> it doesn't have to be now +10:20 < pinchartl> but it's important to know that it works there too +10:21 < geertu> I think that's something for v4.6. +10:22 < pinchartl> it's good enough for me +10:23 < geertu> Anything else for Topic 1? +10:24 < pinchartl> not for me, but I have to say I haven't followed development too closely +10:24 < shimoda> not for me +10:25 < geertu> Topic 2. Status check for tasks from last meeting - what is remaining? +10:25 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list +10:26 < geertu> earlycon support is being fixed (thx!) +10:27 < geertu> earlycon support is being fixed (thx uli___!) +10:27 < uli___> don't worry, i'm still awake :) +10:27 < uli___> welcome +10:27 < geertu> pfc can still use some acks (hint...) +10:27 < pinchartl> geertu: I know +10:28 < pinchartl> sorry about the delay +10:28 < pinchartl> I've been rushing full speed on multimedia +10:31 < geertu> Any other status updates? +10:32 < shimoda> about VGIC, we don't have any update for now, sorry +10:33 < geertu> ok +10:34 < morimoto> about INTC address, there is still no response from datasheet/hw guys +10:35 < morimoto> And S1Dx / S0Dx address too (from Magnus). +10:38 < geertu> Then I think we're finished. +10:38 < shimoda> I think so +10:39 < pinchartl> it was a short one +10:39 < geertu> no dammsan ;-) +10:40 < geertu> Thanks for attending, CU! diff --git a/wiki/Chat_log/20151119-io-chatlog b/wiki/Chat_log/20151119-io-chatlog new file mode 100644 index 0000000..0d06431 --- /dev/null +++ b/wiki/Chat_log/20151119-io-chatlog @@ -0,0 +1,203 @@ +--- Log opened Thu Nov 19 09:52:39 2015 +09:52 -!- wsa_ [~wsa@p4FE2557F.dip0.t-ipconnect.de] has joined #periperi-io +09:52 -!- Irssi: #periperi-io: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal] +09:52 -!- Irssi: Join to #periperi-io was synced in 0 secs +10:11 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi-io +10:11 < morimoto> Hi +10:11 <@geertu> hi +10:11 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi-io +10:12 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi-io +10:12 < wsa_> great +10:12 < wsa_> everyone's here... +10:13 < wsa_> so, let's get started +10:13 < wsa_> i assume people in Japan want to go home soon ;) +10:14 < shimoda> :) +10:14 < wsa_> my topics as mentioned: +10:14 < wsa_> 1) gen3 updates +10:14 < wsa_> 2) clocks-off as default? +10:14 < wsa_> are there topics from your side? +10:15 < shimoda> none from me +10:15 < morimoto> Did you get email from shimoda-san about I2C macro issue ? +10:16 < wsa_> morimoto-san: yes, i even replied +10:16 < wsa_> morimoto: laurent and i found the same issue yesterday +10:16 < shimoda> wsa_: thank you for the information. this is useful to me +10:17 < morimoto> Oops I got email from you just during Renesas network issue time :) +10:17 < shimoda> so, i will forward this information to the customer +10:17 < wsa_> yes, and it was useful confirmation for me, too +10:17 < wsa_> as we are talking I2C already +10:18 < wsa_> any estimation when the HW team answers the "what is low drive only LVTTL" question? +10:19 < shimoda> wsa_: i am asking this and they returned something, but I don't get useful information yet for now +10:20 <@geertu> I think it's just the lower half of a regular push-pull output +10:20 < wsa_> i was thinking the same +10:20 <@geertu> I.e. similar like open drain, but with smaller transistors supporting only LVTLL voltage levels +10:20 < wsa_> but that would mean those busses are not multi-master capable +10:20 <@geertu> Typically open drain supports much higher voltage levels +10:21 <@geertu> Why not multi-master? +10:21 <@geertu> (higher voltage levels = much higher than vdd) +10:21 <@geertu> s/LVTLL/LVTTL/ +10:23 < wsa_> to be precise, they might not be multi-master compatible +10:23 < wsa_> it depends how it is done +10:23 <@geertu> lower half of a regular push-pull output == open drain +10:24 < wsa_> then why is not everyone doing it when it is so much faster? +10:25 < wsa_> that i wonder and why i'd like some details +10:25 <@geertu> Isn't it faster because of LVTTL levels? The lower voltage the pull-up, the faster it is (regular i2c is 5v, right) +10:25 < wsa_> yes, but rcar does only 3v3 at max +10:26 < wsa_> hmmm +10:26 < wsa_> makes sense +10:26 < wsa_> need to think about it +10:26 < wsa_> not now ;) +10:26 < wsa_> i saw the watchdog driver made it to the bsp +10:26 < wsa_> so bsp team was happy with it? +10:26 < wsa_> and we can continue upstreaming i guess +10:27 < shimoda> wsa_: i think so because bsp team doesn't ask me about it for now :) +10:28 < wsa_> :) +10:28 < wsa_> the PCIE driver works here for me +10:29 < wsa_> the interrupt issue found attention by Marc Zygnier, so I guess he and Phil will work it out +10:29 < shimoda> nice! +10:30 < wsa_> i can also scan the new bsp for sata patches. should be low-hanging fruit to upstream +10:31 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has quit Remote host closed the connection +10:31 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi-io +10:32 < wsa_> then we wanted to find an upstream path for SDHI DMA +10:32 < wsa_> shimoda-san: is this still valid? +10:32 < wsa_> or did something other urgent show up? +10:32 < shimoda> i think so about sata. about porting from bsp to upstream, kaneko san of horms can do it, i guess +10:33 < wsa_> ok +10:33 < dammsan> guys +10:33 < shimoda> wsa_: yes, it is still valid, i think noone care about SDHI DMA for upstreamining +10:33 < dammsan> may i simply ask you to prioritize the I2C stuff over other leaf node devices? +10:33 < dammsan> that will be my only request =) +10:34 < wsa_> dammsan: i will send out v3 of my refactoring series today +10:34 < wsa_> this has all known issues addressed; needs thorough testing, of course +10:35 < dammsan> good - thanks a lot +10:35 < wsa_> and people do test currently which is great! +10:36 < dammsan> wsa_: you can use my remote access system anytime +10:36 < wsa_> dammsan: i will +10:36 < dammsan> ideally to test stuff on a wide range of boards before you queue it up +10:36 < wsa_> and i will run the continous edid read test +10:36 < dammsan> thanks +10:36 < dammsan> i cannot guarantee that the TV will be there forever +10:37 < dammsan> but looping HDMI back to the VIN may be good +10:37 < dammsan> but anyway, i will try not to steal your time with this anymore +10:37 < dammsan> =) +10:38 < wsa_> dammsan: sure thing. i always tested your koelsch. yet, all kernels were build with a toolchain that "worked" :/ +10:38 < wsa_> but this time laurent tested even before v3 is released ;) +10:40 < wsa_> but i understand this long standing issue is worrying +10:40 < dammsan> great, thanks! +10:41 < wsa_> shimoda: so kaneko-san will do SATA, nice. I noted it +10:41 < shimoda> i will ask simon-san about this later though :) +10:42 < wsa_> ok +10:43 < wsa_> there is a thermal driver now in the bsp \o/ +10:44 < wsa_> not in an upstreamable condition, though +10:44 < wsa_> i guess this needs to be done somewhen but it is not urgent? +10:45 < shimoda> I think so (it is not urgent) because they have a code +10:46 < shimoda> however, i will ask bsp team when it needs to upstream +10:47 < wsa_> so what is USB status? I see USB3 support will be pulled in soon? +10:47 < shimoda> yes, xhci maintainer mentioned about it +10:48 < shimoda> about USB2.0 host (usb2.0 phy), I should ping to kishon later +10:50 < wsa_> nice +10:50 < shimoda> about USB3.0 peri, I am developing it now +10:50 < shimoda> about USB2.0 peri, it should work after usb2.0 phy patch is merged +10:50 < wsa_> great +10:51 < wsa_> shimoda-san == USB hero +10:51 < wsa_> :) +10:51 < shimoda> :) +10:51 < wsa_> geertu: did you have any time left for SCIF or SPI development? +10:52 <@geertu> Expect SCK and full BRG support for (H)SCIF later today +10:53 < dammsan> how to handle the fifo drain issue? +10:53 < dammsan> i guess we need to fix that eventually +10:53 < wsa_> geertu: nice +10:54 <@geertu> I don't know enough about the tty/serial layer innards to answer that question +10:54 < dammsan> sure, no worries +10:54 < dammsan> it would be good to keep track of the task though, to show this to high level people +10:55 < dammsan> or maybe it will cause fire =) +10:56 < wsa_> noted +10:56 < dammsan> thanks! +10:58 < wsa_> so, can we go over to the clocks-off discussion? +10:58 < shimoda> yes +11:00 < wsa_> proposal: I'd like to make them mandatory for io-group upstream development +11:01 < wsa_> that would mean that 7791 has to be added +11:01 < wsa_> but their usefulness justify that IMO +11:01 < wsa_> comments? +11:02 <@geertu> 7791? +11:02 < wsa_> 7790 +11:02 < wsa_> sorry +11:03 < wsa_> ideally they would be in some branch, so that we developers can merge it into our codebase when we start hacking +11:04 < dammsan> [1;5Dwhy not including it in upstream by default? +11:06 < dammsan> perhaps you already have a good answer to that from a different thread? +11:06 <@geertu> It's ugly +11:06 < dammsan> ok but so is life +11:07 < dammsan> if you prefer not to then if it of course fine +11:07 < dammsan> just seems like a handy feature +11:07 <@geertu> with the new cpg-mssr driver, we could disable all clocks early in that driver +11:07 <@geertu> but then we have to list all of them +11:07 < dammsan> ok, self-contained ugliness =) +11:07 <@geertu> and I really mean all of them +11:08 <@geertu> thus including the non-documented ones ;-) +11:08 < dammsan> sure +11:08 <@geertu> or live with the hex numbers, alternatively +11:08 < dammsan> but it is easy to start doing that early compared to later in the process, no? +11:08 <@geertu> actually the hex numbers is probably the best way +11:08 < wsa_> the debug interface is also nice but also doesn't seem upstreamable to me +11:09 <@geertu> indeed +11:09 < wsa_> /proc \o/ +11:10 < wsa_> geertu: can you provide a branch? +11:10 < wsa_> or keep them integrated in renesas-drivers? +11:10 < wsa_> or is the latter too much work? +11:11 <@geertu> I can provide a branch +11:12 <@geertu> There's no classified information in there? E.g. clocks marked "secure" +11:12 < wsa_> that i don't know +11:12 < dammsan> you may find bugs =) +11:13 < dammsan> if so we shall really report them +11:13 < dammsan> not sure how secret it is +11:13 < dammsan> but should be fine unless you violate copyright +11:15 < wsa_> shimoda: morimoto: if geert provides a "clocks-off" branch, would you be OK using it? +11:15 < morimoto> sure of course +11:15 < dammsan> wsa_: including it in renesas-drivers may be a bit difficult for bsp people +11:15 < shimoda> wsa_: yes +11:16 < dammsan> i think that needs to be coordinated +11:16 < dammsan> if so +11:16 < dammsan> just a topic branch is something else +11:16 < wsa_> dammsan: i agree +11:17 < wsa_> the first thought was to reduce merge conflict resolutions, but on second thought it is too invasive +11:18 <@geertu> Do you need the full thing with debug interface, or just writing the hardcoded hex numbers to the mstpcr registers? +11:19 < wsa_> is it much work to keep the debug interface? +11:20 < wsa_> or maybe we start small +11:20 < wsa_> and port the debug interface when needed +11:24 < wsa_> ok? +11:25 <@geertu> ok +11:26 <@geertu> wsa_: can you extend the current "full" version to r8a7790? +11:27 < wsa_> i'll try +11:27 < wsa_> i'll come back to you if i have questions +11:27 <@geertu> ok, thx +11:28 < wsa_> anything more? +11:28 < wsa_> i think we are done +11:29 < shimoda> i think so +11:29 <@geertu> I have a small note +11:29 <@geertu> I added gpio-leds and gpio-keys to Salvator-X dts +11:30 <@geertu> Either of them work on their own, but not combined, as the LEDs and keys share GPIOs +11:30 < dammsan> GPIOF_SHARED? +11:30 < dammsan> like for IRQs? =) +11:30 <@geertu> This is an "interesting" DT issue, as both hardware descriptions are correct :-) +11:31 < dammsan> similar to our pinmux policy setting +11:31 < dammsan> with a single uart described but in reality the pinmux is what is limiting +11:31 <@geertu> I have some ideas for a proof-of-convept driver combining gpio-leds and gpio-keys-polled +11:31 < dammsan> gool +11:31 < dammsan> i mean cool =) +11:32 <@geertu> A while ago I had asked LinusW if something like that already existed, and he was interested in it. +11:32 <@geertu> Sharing a GPIO for both key and LED is a classic microcontroller trick +11:33 <@geertu> If I find some time, I'll implement it. Probably it will trigger an interesting DT discussion, so stay tuned :-) +11:34 * wsa_ orders some popcorn +11:34 <@geertu> Nothing else from my side for now +11:34 < wsa_> first time i hear someone starts a DT discussion for fun... ;) +11:35 < wsa_> ok +11:36 < wsa_> we are done +11:36 < wsa_> thank you! +11:36 < morimoto> gool, thx +11:36 < wsa_> and have a great rest of the day +11:37 <@geertu> cu, bye! +11:37 < wsa_> very gool! +11:37 < shimoda> bye! :) +11:37 < dammsan> cya +11:37 -!- shimoda [~shimoda@relprex2.renesas.com] has quit Quit: WeeChat 0.4.2 +11:38 -!- morimoto [~user@relprex2.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +--- Log closed Thu Nov 19 11:41:26 2015 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 diff --git a/wiki/Chat_log/20151207-io-chatlog b/wiki/Chat_log/20151207-io-chatlog new file mode 100644 index 0000000..5d6d732 --- /dev/null +++ b/wiki/Chat_log/20151207-io-chatlog @@ -0,0 +1,131 @@ +--- Log opened Mon Dec 07 08:53:46 2015 +08:53 -!- wsa_ [~wsa@p4FE25C23.dip0.t-ipconnect.de] has joined #periperi +08:53 -!- Irssi: #periperi: Total of 8 nicks [0 ops, 0 halfops, 0 voices, 8 normal] +08:53 -!- Irssi: Join to #periperi was synced in 0 secs +08:54 < wsa_> hello! +08:54 < geertu> Hi Wolfram +09:02 < horms> hi +09:02 < wsa_> hey guys! +09:02 < wsa_> so, only morimoto-san missing... +09:05 < wsa_> simon, is your upport-todo-list only for your planning or is it also used to generate reports to Renesas? +09:06 < horms> Generally the reports I generate are based on a slightly different take on the data +09:07 < horms> but I am hoping to re-use the todo-list for part of my report writing +09:07 < horms> does that answer the question? +09:07 < wsa_> so, from a reporting POV, it doesn't make sense if I copy the IO related entries into my list? +09:08 < horms> ok, I understand the question +09:08 < horms> with the upporting todo list you can assume that I will be reporting on those items in some form, so they won't be unreported +09:08 < wsa_> ok +09:08 < horms> but if you also wish to report on them I personally don't see a problem with that +09:09 < wsa_> i didn't want things to be unreported, but I also don't want stale data +09:09 < horms> agreed +09:09 < horms> i also plan to report on the integration todo list +09:09 < horms> so those items shouldn't be left unreported either +09:10 < wsa_> great! +09:10 < horms> i think there is quite some overlap between those two lists and the work of other teams +09:10 < horms> but i don't see much of a problem with that at this time +09:10 < wsa_> i agree +09:11 < wsa_> like with SPI slave; there is a patch in the BSP, but I think the upstream solution will look quite different +09:11 < wsa_> so, two action items make sense +09:11 < horms> that is fine +09:11 < horms> i usually report on that too :) +09:11 < horms> the bsp team know we don't just automatically take their work into upstream +09:13 < wsa_> :) +09:13 < wsa_> other than that, any updates from your side regarding the IO group todo list? +09:13 < horms> kaneko san and i have made a bit of progress on etheravb, which is what i usually report on here +09:14 < horms> but that is included in the todo lists i posted +09:14 < horms> sergei also got all excited about not maintaining ether avb +09:14 < horms> he is s funny fellow +09:14 < horms> not much else on my side +09:15 < wsa_> OK +09:15 < wsa_> geert? +09:15 < geertu> SCIF BRG is public +09:15 < geertu> I have to do some rework and add support for more SoCs +09:16 < geertu> (in progress) +09:16 < geertu> Has anyone else tried this? +09:16 < geertu> I'm seeing some mangled data on the serial console when both the kernel and userspace output at the same time +09:16 < geertu> Have to investigate what's the reason for that +09:17 < wsa_> sorry, haven't tried it +09:17 < geertu> About MSIOF +09:18 < geertu> There are indeed issues with it on Gen3. The BSP claims to have solutions for some, still have to try them +09:19 < geertu> The BSP commit messages are a bit confusing. +09:19 < wsa_> is this a seperate AI fo us? +09:19 < wsa_> Yes, they are :) +09:19 < wsa_> sometomes +09:19 < wsa_> sometimes +09:19 < geertu> Also the report from Tokyo we got about MSIOF working for RX, but not for TX +09:19 < geertu> Perhaps it becomes clearer after trying the patches from BSP +09:20 < geertu> I do think we need an entry in to TODO list for MSIOF on Gen3 +09:20 < geertu> s/to/the/ +09:21 < wsa_> +MSIOF,v4.5,plan,geert,Investigate issues on Gen3 +09:21 < wsa_> ? +09:21 < geertu> ok +09:21 < wsa_> What about: +09:21 < wsa_> SCIF,?,noplan,?,FIFO drain issue +09:21 < wsa_> is this really noplan? +09:22 < geertu> No, Magnus asked to look into it after New Year +09:22 < geertu> s/asked/asked me/ +09:22 < wsa_> and is the description descriptive enough? +09:22 < geertu> It's about bytes stuck in the FIFO and/or serial layer +09:22 < geertu> Should the input FIFO be flushed on device open +09:22 < geertu> ? +09:23 < wsa_> ok +09:23 < geertu> Perhaps someone around here just knows ;-) +09:23 < wsa_> I'd go for asking Alan Cox +09:23 < geertu> Currently if you run data transfer integrity tests between serial ports, the test may fail because there's still data in the input FIFO (or tty subsystem, don't know for sure) from previous use +09:24 < wsa_> he used to know details from "the old days" when I had a question about the TTY layer :) +09:24 < wsa_> btw simon: +09:24 < wsa_> gpio-rcar,v4.5,merged,kaneko,Upstream BSP v3.0.3 patch: sata_rcar: Add compatible string for r8a7795 +09:25 < wsa_> the above line looks strange to me because of the combination of gpio-rcar and SATA +09:26 < geertu> s/gpio-rcar/sata_rcar/ +09:26 < wsa_> that would make sense to me, yes +09:27 < geertu> renesas,gpio-r8a7795 is upstream +09:27 < horms> i think its a typo as geert suggests +09:27 < horms> i'll fix it if its on one of my lists +09:27 < wsa_> your upport list +09:27 < horms> ok, will fix +09:28 < horms> about usb3.0. it is present on lager but not porter (or any other gen2 board i think) +09:28 < horms> perhaps adding support to lager is a job for the i/o team. or perhaps nothing is needed? +09:29 < horms> there seems to be something relevant in the v1.9.6 BSP, so I guess it could be upported +09:29 < wsa_> not sure; I just noted the blue USB connector on my Lager and wondered if it could be easily integrated if integration was done for Koelsch already +09:30 < horms> &xhci { +09:30 < horms> status = "okay"; +09:30 < horms> }; +09:30 < horms> maybe :^) +09:30 < wsa_> the integration list was so huge, I thought another item wouldn't hurt ;))) +09:30 < horms> ok, i am bind +09:30 < horms> i see it for laer now +09:30 < horms> lager now +09:31 < horms> but i don't think its wired up for koelsch +09:31 < horms> sore +09:31 < horms> sure the more items the merrier! +09:31 < wsa_> ok, next steps: +09:32 < wsa_> buisness as usual, I'd assume +09:32 < wsa_> simon does EtherAVB +09:32 < wsa_> wolfram does planned I2C items scheduled for 4.5 +09:32 < wsa_> geert continues hacking BRG and MSIOF? +09:33 < geertu> yes +09:33 < geertu> There's also (H)SCIF DMA on Gen3 +09:33 < geertu> There's (sort of) a task for that in Core +09:34 < wsa_> ok +09:34 < geertu> Doesn't hurt to have a task for that in IO +09:35 < wsa_> SCIF,v4.5,plan,geert,DMA support for Gen3 +09:35 < wsa_> ? +09:36 < horms> if it is compatible with gen2 you can ship it off to integration/upporting. but if its a priority you may want to keep it +09:36 < geertu> Last time I tried, TX DMA works, RX doesn't +09:37 < horms> ok +09:37 < geertu> Magnus claims RX works for him with IPMMU, but he has different firmware +09:37 < horms> sounds like you need to keep that one for yourself then +09:37 < geertu> Yep ;_) +09:39 < wsa_> i think we are done, or? +09:39 < geertu> I think so +09:41 < wsa_> ok, then +09:41 < wsa_> thanks for your input! +09:42 < wsa_> i think it makes sense to have one more meeting this year +09:42 < wsa_> a short one like today +09:42 < wsa_> i'll suggest something in the report mail +09:42 < geertu> ok +09:43 < wsa_> so, have a great day! +09:43 < horms> likewise +09:43 < geertu> bye! +09:43 < horms> bye +--- Log closed Mon Dec 07 09:43:58 2015 diff --git a/wiki/Chat_log/20151215-core-chatlog b/wiki/Chat_log/20151215-core-chatlog new file mode 100644 index 0000000..6e76672 --- /dev/null +++ b/wiki/Chat_log/20151215-core-chatlog @@ -0,0 +1,492 @@ +Core-chat-meeting-2015-12-15 + +10:03 < geertu> Agenda: +10:03 < geertu> 1. Upcoming Gen3 development for the Core group, +10:03 < geertu> 2. Status check for tasks from last meeting - what is remaining? +10:03 < geertu> 3. SMP enablement on Gen3 +10:03 < geertu> 4. Cache enablement on Gen3 +10:03 < geertu> 5. DMA-Engine framework development and SYS-DMAC on Gen3 +10:03 < geertu> Topic 1. Upcoming Gen3 development for the Core group +10:05 < geertu> Nothing new, good ;-) +10:05 < dammsan> FYI, my plan is to push out a bunch of IPMMU patches for r8a7795 soon +10:05 < geertu> Nice! +10:06 < dammsan> Apart from that, I'd like to test them with the DU - but it was dropped in a recent renesas-devel release +10:06 < geertu> Yeah, too many issues with the media tree +10:07 < dammsan> understandable!! +10:07 < geertu> As I dropped media-next, perhaps you can just "git fetch git://linuxtv.org/pinchartl/media.git vsp1-kms-20151206 && git merge FETCH_HEAD~3" yourself? +10:08 < dammsan> i may simply not move forwards +10:08 < dammsan> for this test case +10:08 < geertu> That's another solution ;-) +10:08 * geertu shuffles agenda topics +10:08 < dammsan> i'm yet to poke with the external interrupt pins +10:08 < geertu> BUG_ON and NULL pointer dereference after merging media-next +10:08 < dammsan> yum +10:09 < geertu> and another one after merging in vsp1-kms-20151206 and solving the (many) conflicts +10:09 < dammsan> wolfram was talking about some lack of runtime pm in the gpio driver, do you know about that? +10:09 < dammsan> (sorry for not putting htat on the agenda) +10:09 < horms> dammsan: do you plan to follow up on "ARM: shmobile: IPMMU compat string SoC part number" > +10:09 < horms> ? +10:10 < dammsan> horms: i was actually not sure what the current state was - the DT binding was accepted I think? +10:10 < horms> i see an email from myself saying that i queued them up +10:11 < horms> i'll check +10:11 < geertu> dammsan: it's more a lack of runtime PM handling in the irq subsystem +10:11 < geertu> irq-renesas-irqc just does pm_runtime_get_sync() for its whole lifetime +10:11 < dammsan> geertu: sure - is it worth adding a task for that? +10:11 < dammsan> horms: thanks +10:12 < dammsan> geertu: yeah, irq-renesas-irqc is good and simple =) +10:12 < geertu> we can do the same in rcar-gpio, but then we loose al saving we did before +10:13 < geertu> AFAIK the Tegar people are working on it +10:13 < geertu> s/Tegar/Tegra/ +10:13 < dammsan> yeah, that seems a step in the wrong direction +10:13 < dammsan> we need some sort of handling for this +10:13 < horms> dammsan: ok, i see, i deffered them pending the driver update +10:13 < dammsan> eventually +10:13 < horms> has that happened? +10:14 < dammsan> the DT binding has been appied +10:14 < horms> ok +10:14 < horms> i was waiting on that +10:14 < dammsan> according to the maintainer +10:14 < dammsan> i'm not sure if it is in next or not +10:14 < horms> sorry if my email wasn't clear about me waiting on that +10:14 < dammsan> horms: sorry for not testing your gose GPIO yet +10:14 < geertu> Unfortunately the core ARM irqchip people don't seem to have much graps for Runtime PM and PM (power and clock) Domains +10:14 < dammsan> no worries +10:15 < horms> no problem! +10:15 < geertu> s/graps/grasp/ +10:15 < dammsan> s/for Runtime PM and PM/g +10:15 < dammsan> oh, and i found out that some of the IPMMU instances are located in power domains =) +10:16 < geertu> next-20151214 only has "renesas,ipmmu-vmsa" +10:16 < dammsan> so we need multiple IPMMUs with bindings together +10:16 < dammsan> it may take someeeeeeeeeeee time +10:17 < dammsan> geertu: how is the cpg-mssr driver merge looking? +10:17 < geertu> dammsan: Mike is hiding somewhere +10:17 < geertu> No review, no response to pull request +10:18 < geertu> (he's on #periperi now, so he may read everything we write ;-) +10:19 < uli___> morning. sorry, overslept... +10:20 * geertu added task "gpio-rcar,v4.6,noplan,?,Fix Runtime PM with GPIO interrupts +10:21 < dammsan> geertu: i ran into mike the other day, and he said he had looked over the code +10:21 < dammsan> lets see what happens +10:21 < geertu> dammsan: He's in Tokyo? +10:22 < dammsan> he was for a brief moment +10:22 < geertu> We should reduce his travel budget ;-) +10:22 < horms> dammsan: [off-topic] do you plan to revisit "[PATCH 00/08] clocksource: sh_cmt: DT binding rework"? +10:22 < dammsan> yes, eventually =) +10:23 < horms> thanks +10:23 < dammsan> and do the same for TMU +10:23 < dammsan> some of the DT bindings got acked +10:23 < horms> ok, for some reason TMU isn't on my radar +10:24 < dammsan> it may be low priority stuff +10:24 < horms> it would be moderately helpful if the series also covered r8a7793 and 92 +10:24 < dammsan> i should really deal with that when i resend +10:24 < dammsan> oh, +10:24 < dammsan> that reminds me +10:24 < dammsan> do we need soc-part-number for the DMAC devices in DT? +10:25 < dammsan> i recall that they were missing +10:25 < horms> what do you mean? +10:25 < horms> if you are talking about compat strings +10:25 < horms> they are either done, in progress or on my list +10:25 < horms> i can check on a case by case basis if you need the information +10:25 < geertu> [PATCH] dmaengine: rcar-dmac: Document SoC specific bindings +10:26 < dammsan> yeah, but thing have improved +10:26 < dammsan> thanks!! +10:26 < horms> slowly the gaps are being filled in +10:26 < dammsan> please ignore my comment about DT DMAC +10:26 < dammsan> very nice +10:27 < horms> with cmt, the r8a7793 appears to be using an undocmented per-soc binding. i was going to fix it but noticed you are planning to change the world +10:27 < dammsan> yeah, that's the idea +10:27 < horms> ... and i finally got around to asking you about it +10:27 * geertu still has Magnus' CMT series in his local tree +10:28 < dammsan> yes +10:28 < dammsan> will fix +10:30 < dammsan> geertu: is it possible to work around the GPIO issue in the CPG-MSSR driver somehow? +10:30 < dammsan> for short term +10:30 < dammsan> keeping the clock enabled or something +10:30 < geertu> Yes, but that only helps r8a7795 +10:30 < dammsan> i'm mainly concerned about that one for the short term +10:31 < dammsan> it is not super important +10:31 < dammsan> but i'd like the r8a7795 code to be rock solid +10:31 < geertu> Oops, next doesn't have CLK_ENABLE_HAND_OFF yet +10:32 < geertu> So if you add the GPIO clocks to r8a7795_crit_mod_clks[], they won't be registered +10:32 < geertu> and rcar-gpio won't work at all +10:33 < dammsan> ok, i was hoping on just increasing their use count temporarily +10:33 < dammsan> but no big deal +10:34 < geertu> yeah, that's what renesas-cpg-mssr.c really should do if CLK_ENABLE_HAND_OFF is not enabled, but I took a shortcut, as it doesn't matter for intc-ap +10:34 < geertu> Topic 2. SMP enablement on Gen3 +10:34 < geertu> Seems we have it ;-) +10:35 < geertu> It works for the CA57s +10:35 < geertu> Haven't tried Dirk's newer patch for CA53 yet +10:35 < horms> ok, gerat +10:35 < geertu> (does anyone know who Dirk Behme is?) +10:35 < dammsan> so i'd like to order the enablement here somehow +10:35 < horms> no +10:36 < dammsan> because the cache, dmac and smp tie together +10:36 < dammsan> also, for SMP, if we enable CA53 then the system will become strange +10:36 < horms> i was kind of expecting some feedback to be given to dirk... +10:37 < geertu> big.LITTLE is strange? :-) +10:37 < dammsan> unless the big little patch stack has been merged +10:37 < dammsan> is the scheduler aware yet? +10:37 < dammsan> last time i bother checking ARM assigned summer interns to the scheduler work +10:37 < geertu> I don't know. There should be zillions of big.LITTLE SoCs in use by now +10:38 < dammsan> running upstream? +10:38 < dammsan> on r8a7790 we worked around it by only enabling the Big cores +10:38 < dammsan> by default +10:38 < dammsan> and if little boot mode was selected we used little only +10:38 < dammsan> this may not be needed with the current scheduler +10:39 < dammsan> but we should check before enabling both big + little +10:39 < geertu> Does it matter much that the scheduler is aware? +10:39 < geertu> I guess 4xCA57 + 4xCA53 is better than 1xCA57 +10:39 < dammsan> if you execute something and it is not deterministic +10:39 < dammsan> and the tasks do not migrate +10:39 < dammsan> then it turns to poo IMO +10:40 < dammsan> I think the end goal should be 4 + 4 +10:40 < dammsan> or whatever is on other Gen3 SoCs +10:40 < dammsan> so i feel we need to control the enablement somehow +10:41 < dammsan> but maybe you guys are already doing that, and i'm lost as usual? =) +10:41 < dammsan> what is the opinion? +10:41 < horms> I was hoping for feedback from you +10:41 < dammsan> i see +10:42 < horms> my opinion is, as yours, that we should be careful +10:42 < dammsan> i've been overfocusin on IPMMU due to sudden customer demand... +10:42 < dammsan> and i think i shared some "long term" plan for our upstream development +10:42 < horms> but that we should communicate our plan/concerns to dirk +10:42 < dammsan> and SMP is not happening until next year +10:42 < horms> i did queue up the CA57 patches +10:43 < horms> i can (quickly) drop them for v4.5 if needed +10:43 < dammsan> i don't see any reason to rush +10:43 < dammsan> i think we need a plan =) +10:43 < dammsan> thanks for queuing up things btw +10:43 < horms> i was planning to queue up the CA53 patches for v4.6 unless there was some feedback +10:43 < horms> so i also agree that there is no rush +10:43 < horms> but o think we need to communicate a bit with dirk +10:44 < horms> possibly refocussing his energy elewhere +10:44 < dammsan> i would like to ask someone to check SMP and big.little +10:44 < geertu> dammsan: Do you know a simple test to check if the scheduler is aware? +10:45 < dammsan> geertu: no turn-key, but say spawning off twice the number of benchmark jobs as number of cpus, and see how it behaves? +10:45 < dammsan> if you run with two cores - one big and one little, and spawn off one benchmark job, if it gets stuck on the little one you are screwed +10:46 < dammsan> busy tasks should migrate to the faster cores +10:46 < horms> because it will be slow? +10:46 < geertu> ok, will try something +10:46 < dammsan> yes, and the other big core will be fast and idle +10:46 < horms> ok +10:46 < horms> so how about someone (e.g. me) communicates this with dirk +10:47 < dammsan> that's of course fine with me +10:47 < dammsan> but i think we still need a plan +10:47 < horms> we can deffer his patches until we get a better idea of what their implicatinos are +10:47 < geertu> horms: Please let me try it first +10:47 < horms> geertu: sure, no problem +10:47 < horms> I'm also quite ok with you responding to him +10:47 < dammsan> so one idea can be to get SMP support working as first step +10:48 < dammsan> on big cores +10:48 < horms> isn't that what we now have? +10:48 < dammsan> in a perfect world +10:48 < dammsan> but there are dependencies on timers +10:48 < dammsan> on firware +10:48 < dammsan> cpu hotplug +10:48 < dammsan> kexec +10:48 < dammsan> kernel command line parameters +10:48 < dammsan> ... +10:49 < dammsan> i highly doubt that everything is working +10:49 < dammsan> unless it is a x86 system +10:49 < horms> ok +10:49 < horms> so perhaps we partially have it +10:49 < dammsan> more testing is needed for sure +10:49 < dammsan> either merge (like you did) or topic branch +10:49 < dammsan> and then combine with some testing +10:50 < horms> the point is the merge is done +10:50 < dammsan> right +10:50 < horms> and we have a small window to change our mind +10:50 < dammsan> twhat is your opinion? +10:50 < horms> of course we can revert later +10:51 < dammsan> if you are ok with depending more on teh boot loader stack then i'm fine +10:51 < geertu> How do we know which boot loader stack we have? +10:51 < dammsan> good question +10:51 < geertu> horms: You said you saw one CPU only? +10:51 < dammsan> i kept my various versions in different directories +10:51 < horms> yes i did +10:51 < geertu> I was using my own tree, with my own config +10:51 < dammsan> but lately they seem to be aligned to yocto releases inside renesas +10:51 < horms> but i was using devel + cpg+mssr, not renesas-drivers +10:52 < dammsan> i think we should use the same boot loader stack ideally +10:52 < dammsan> so we may need to coordinate that as well +10:52 < dammsan> so what is a good plan i wonder...? +10:53 < dammsan> I think we should do a joint effort to update our boards after new year +10:53 < horms> is the implication that geert and I may be using different boot loaders? +10:54 < dammsan> i've used 3 different versions +10:54 < dammsan> one worked with IPMMU +10:54 < dammsan> i have not yet used SMP +10:54 < geertu> horms: that's what I'm wondering about, too +10:54 < horms> about the merge, i'm inclined to leave it unless we feel it will be harmful e.g. in terms of updates, in future +10:54 < horms> but i am happy to be convinced otherwise +10:55 < dammsan> horms: i think it is fine to include it if "maxcpus=1" works as on other architectures +10:55 < dammsan> so we have a simple way to boot with a single CPU only +10:55 < dammsan> if we end up with random crashes +10:55 < dammsan> on certain boards +10:56 < dammsan> or we can merge it regardless +10:56 < dammsan> if you are willing to deal with the potential trouble... +10:56 < dammsan> its up to you really +10:56 < dammsan> geert? +10:56 < geertu> I'd be surprised if "maxcpus=1" wouldn't work, but let's try +10:56 < dammsan> do you have any idea how to order SMP + cache + DMAC +10:56 < geertu> cache first +10:57 < geertu> (needed for SYSC PM Domains too) +10:57 < dammsan> ok, lets do that +10:57 < horms> geertu: could you try; i only see one CPU regardless +10:57 < geertu> which brings us to +10:57 < geertu> Topic 3. Cache enablement on Gen3 +10:57 < geertu> The cache is enabled automatically, I think +10:58 < dammsan> i listed it because it ties in with both the DMAC and the CPUs +10:58 < dammsan> apparently the IPMMU has some cache coherent support for page tables +10:58 < geertu> Presence in DT is just dressing up (ARM core viewpoint?), or hard requirement for SYSC PM Domains +10:58 < dammsan> otherwise the other devices require cache management by the CPU +10:59 < geertu> I don't follow that part +10:59 < geertu> There's already cache managment without an IPMMU? +10:59 < dammsan> each bus master device on the system +10:59 < dammsan> well +10:59 < dammsan> i mean, if we use say SYS-DMAC without IPMMU +11:00 < dammsan> we still need to manage the cache since the SYS-DMAC is behind the caches +11:00 < dammsan> that is true for most bus master devices +11:00 < dammsan> the only exception that i am aware of is the IPMMU page tables, but i think there is an errata =) +11:01 < dammsan> so my point is that there is a per-bus-master device coherent/non-coherent view +11:01 < dammsan> and maybe gray zone with different inner sharable / outer sharable domains +11:02 < dammsan> i think the only sane way to handle things for now is to assume that all devices are non-coherent +11:02 < dammsan> and opt-in if needed +11:03 < dammsan> geertu: about the PM domain and caches, why do you need the DT binding? +11:03 < dammsan> to restore state? +11:04 < geertu> dammsan: I don't need a binding, just a power-domains property pointing to the SYSC PM Domain +11:04 < dammsan> ok! +11:04 < dammsan> so caches first? +11:05 < dammsan> in the same way as SMP needs testing, I think we want some benchmarking with/without caches +11:05 < geertu> cfr. http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348750.html +11:05 < geertu> Aren't the caches automatically enabled? +11:06 < dammsan> neat! +11:07 < dammsan> it depends on boot loader version +11:07 < dammsan> but i guess it should +11:07 < dammsan> for Gen2 we need to handle caches when doing CPU hotplug +11:07 < geertu> For gen3, we have arm,psci +11:07 < dammsan> on Gen3 i guess the PSCI bits do something magic for us +11:08 < dammsan> geertu: so your plan is to enable caches first? +11:09 < dammsan> or somehow hook them in according to your patch +11:09 < geertu> Without the caches in DT, my debug prints on Salvator-X still print +11:09 < dammsan> above +11:09 < geertu> L1-D: CCSIDR = 0x701fe00a: 32 KiB, 256 sets, 2 ways, 64 bytes/line, WB, RA, WA +11:09 < geertu> L1-I: CCSIDR = 0x201fe012: 48 KiB, 256 sets, 3 ways, 64 bytes/line, RA +11:09 < geertu> L2-U: CCSIDR = 0x70ffe07a: 2048 KiB, 2048 sets, 16 ways, 64 bytes/line, WB, RA, WA +11:09 < dammsan> i see +11:09 < dammsan> i don't recall if we are able to disable caches in the Kconfig for ARM64 +11:10 < geertu> and +11:10 < geertu> Detected PIPT I-cache on CPU0 +11:10 < geertu> Detected PIPT I-cache on CPU1 +11:10 < geertu> CPU1: Booted secondary processor [411fd073] +11:10 < geertu> Detected PIPT I-cache on CPU2 +11:10 < geertu> CPU2: Booted secondary processor [411fd073] +11:10 < geertu> Detected PIPT I-cache on CPU3 +11:10 < geertu> CPU3: Booted secondary processor [411fd073] +11:10 < geertu> Brought up 4 CPUs +11:10 < geertu> SMP: Total of 4 processors activated. +11:10 < geertu> CPU: All CPU(s) started at EL1 +11:10 < geertu> but +11:10 < geertu> Unable to detect cache hierarchy from DT for CPU 0 +11:11 < dammsan> hm +11:11 < dammsan> i wonder what juno says +11:11 < geertu> I'll run my memory speed benchmark... +11:13 * geertu notices that "maxcpus=1" works as expected +11:13 < horms> geertu: thanks! +11:13 < dammsan> yeah, thank you! +11:13 < horms> lets leave those patches in and revert them if the wheels fall off +11:14 < geertu> ok +11:14 < dammsan> horms: but wait with ca53? +11:14 < horms> yes +11:14 < horms> i have no plan to add them to v4.5 +11:15 < horms> and i will wait for some testing before considering them for v4.6 +11:15 < horms> of course our plan will evolve... +11:15 < horms> (or die!) +11:15 < dammsan> goooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooosounds good - thanks! +11:16 < dammsan> (darn my VM environment gets key stuck sometimes) +11:16 < horms> it got stuck in a goood place! +11:16 < dammsan> indeeed +11:17 < horms> btw, i am hoping to finish up at 19:30 +11:17 < dammsan> so what do we do about firmware update? +11:17 < dammsan> any idea? +11:18 < dammsan> horms: i want to discuss the DMAC framework bits too, but you may not care so much +11:18 < horms> well, presumably there is a procedure. perhaps morimoto-san can get us the new images etc... +11:18 < horms> dammsan: perhaps i can go away and come back +11:18 < horms> i only plan to give my son a bath +11:19 < dammsan> anything is fine with me really +11:19 < horms> ok +11:19 * geertu notices his MemSpeed test (which read/writes/copies increasing blocks of memory) shows no difference between L2 cache nodes present in DT or not +11:20 < dammsan> how much memory do you have on your system geert? +11:20 * geertu notices MemSpeed shows performance drops near the documented L1 and L2 cache sizes => L1 and L2 caches are enabled +11:20 < geertu> 1 GiB +11:20 < morimoto> horms: we have procedure for it +11:20 < dammsan> ok i see +11:20 < dammsan> you want to update the boot loader at some point +11:21 < dammsan> to enable 4 GiB and probably a different configuration for the interleave mode +11:21 < dammsan> which may affect the bandwidth +11:21 < horms> (i will wander off for a bit an come back) +11:21 < shimoda> i think we cannot use more than 1GiB on old boot loader +11:22 < geertu> RAM is ca 50% faster than on koelsch +11:22 < dammsan> 50% less? =) +11:22 < dammsan> good old half empty vs half full +11:23 < dammsan> on CA9 systems i noticed quite different speed for Single-core vs SMP +11:23 < shimoda> also ddr speed setting is slow (DDR1600?) +11:23 < horms> (phht; failed to wander off) +11:23 < dammsan> i suspect the coherency logic slowed things down, but i don't know for sure +11:24 < geertu> of course +11:24 < geertu> shared-override? ;-) +11:24 < dammsan> hehe +11:24 < dammsan> so boot loader update early 2016? =) +11:24 < dammsan> joint effort? +11:25 < dammsan> to keep coherent environemnt +11:25 < horms> how about +11:25 < horms> we stage it a bit +11:25 < geertu> and if it breaks, we send the boards to Japan for adding capacitors ;-) +11:25 < horms> in case it goes to poo +11:26 < geertu> Plus we may have regressions on different versions +11:26 < dammsan> s/may/will/g +11:26 < horms> also, if the EU people upgraded in Feb then they may have more immediate options for servicing +11:26 < horms> i agree we should get in sync +11:26 < horms> i just think its a bit dangerous if we all move at once +11:27 < dammsan> i agree +11:27 < horms> probably thouse in Tokyo should go first :) +11:27 < dammsan> i have updated files, but no time yet =) +11:28 < dammsan> you can add a task for me for next time =) +11:28 < horms> time,2015,magnus,plan,get some! +11:29 * geertu is waiting for the move to prototype +11:29 < geertu> next-20151215 has renesas,ipmmu-r8a7* +11:30 < horms> thanks +11:30 < horms> i pushed the integration changes +11:30 < dammsan> thanks!! +11:32 < dammsan> geertu: so whats the conclusion for the cache? need to figure out how to handle the DT topology? +11:32 < geertu> horms; will you disappear? +11:32 < horms> i will try +11:32 < geertu> dammsan: just add it? +11:32 < horms> and if so i will come back +11:33 -!- horms is now known as horms_away +11:33 < dammsan> geertu: sure, sounds good +11:34 < dammsan> so about the DMAC, i was wondering if we can ask neg for help +11:34 < dammsan> geertu: is it ok to move over to the DMAC topic? +11:34 < geertu> Topic 4. DMA-Engine framework development and SYS-DMAC on Gen3 +11:35 < dammsan> ok, so i noticed that we still have that IPMMU + DMAC framework limitation +11:35 < neg> I'm willing to help out here +11:36 < dammsan> i also hope that laurent can help us +11:36 < dammsan> i basically want us to focus on SYS-DMAC in the first quarter to improve the state +11:37 < dammsan> geertu: do you have any ideas for us? +11:37 < dammsan> more detailed plan or similar +11:38 < geertu> nfortunately not +11:39 < dammsan> in parallel i'd to focus on SCIF as well +11:39 < dammsan> so by the end of the quarter i'd like to run SCIF + DMAC + IPMMU with the loopback adapter +11:39 < dammsan> geertu: do you think that is feasible? +11:40 < dammsan> i'm about to post my IPMMU bits + prototypes for integration and DMAC +11:40 < geertu> yesm, if the hardware supports ot +11:40 < geertu> yes, if the hardware supports it +11:41 < dammsan> at least some part of the hardware will support it =) +11:44 < geertu> ok +11:44 < dammsan> feel free to search the linuxsh-dev list for "[PATCH] ARM: shmobile: IPMMU and DMAC prototype" +11:44 < dammsan> there is a reply from Laurent there +11:44 < dammsan> listing the issues we are having +11:45 < dammsan> geertu: i would like us to figure out which steps that are needed for DMAC + IPMMU support on a framework level +11:46 < dammsan> neg: can you find that patch and the reply? +11:46 < neg> sure +11:47 < dammsan> so the issue exists on older platforms too, so we can use gen2 boards too for this development +11:47 < neg> I can start to lookinto the issues Laurent brings up in that thread +11:47 < dammsan> the framework portion +11:47 < dammsan> that would be great +11:47 < geertu> Will ping Vinod... +11:48 < geertu> done +11:48 < dammsan> thanks! +11:48 < dammsan> did some visteon guy produce dmac changes too? +11:49 < dammsan> i wonder if we have any outstanding issue that neg can look into +11:50 < geertu> yes +11:50 < geertu> they are included in renesas-drivers +11:50 < geertu> topic/rcar-dmac-hamza-v3 +11:51 < dammsan> neg: congrats - more stuff! +11:51 < geertu> Of course "[PATCH] dmaengine: use phys_addr_t for slave configuration" is only the first step +11:51 < geertu> currently all drivers store virtual addresses there +11:52 < neg> ok I will start to dig in to it +11:53 < dammsan> thanks!! +11:54 < dammsan> that's all from my side +11:55 < geertu> Topic 5. Status check for tasks from last meeting - what is remaining? +11:56 < dammsan> everything for me =) +11:56 < geertu> I don't think anything has changed in the list +11:56 < neg> NDA papers for me :) +11:56 < geertu> So we're finished. Unless someone has something else to say (I have)? +11:57 < dammsan> yes, thats on me =) +11:57 < dammsan> i'm fine +11:57 < geertu> LinusW asked me to become official sh-pfc co-maintainer +11:57 < geertu> Laurent isn't here, and I don't know what will be in his next SoW +11:57 < dammsan> how do you feel about that? +11:57 < geertu> I feel fine about that +11:58 < dammsan> geertu: the idea is that he will have some core group task +11:58 < geertu> I'll do everything to get more pfc patches in ;-) +11:58 < dammsan> but it is up to you to assign +11:58 < dammsan> good idea =) +11:58 < dammsan> i guess M3 is on the horizon +11:58 < dammsan> with PFC +12:00 < geertu> good! +12:01 -!- horms_away is now known as horms +12:01 < geertu> Any other topics? (right on time, horms) +12:02 < dammsan> not from me +12:02 < horms> i looked over our old friend boot mode register +12:02 < horms> laurent has an idea to eliminate the idea for it being needed early for arch timer on gen2, that part seems ok +12:02 < horms> but its still needed early for cpg +12:03 < horms> i sent an email about it +12:03 < horms> I have also reworked things to use a binding etc... but there seems not much point in posting it if the "early" bit needs more discussion +12:03 < horms> i would also not be at all upset if someone had a burning desire to take over this task :^) +12:04 < dammsan> horms: haha +12:04 < dammsan> next core meeting why don't your bring laurent and we can hash it out? +12:04 < horms> iirc that and dirk were the topics i wanted to bring up +12:04 < horms> and we spoke about mr. dirk already +12:04 < geertu> I think next core meeting will be after v4.4? +12:04 < horms> i have no urgency :) +12:05 < horms> yes, i think laurent needs to be involved +12:05 < horms> either over email or a a chat meeting +12:05 < horms> geertu: perhaps you could invite him to the next one if its still haning in the air at that time +12:05 < dammsan> geertu: did we need any activity for CPG-MSSR driver merge again? +12:06 < geertu> dammsan: I can send a ping. Not more I can do, I'm afraid +12:06 < dammsan> geertu: if you ask him off list, please CC me +12:06 < geertu> him = Laurent? or Dirk? +12:06 < geertu> invite him = Laurent? or Dirk? +12:06 < dammsan> i can forward to my superiors +12:06 < dammsan> Mike +12:06 < horms> geertu: invite Laurent +12:07 < horms> geertu: I'm not suggesting inviting Dirk at this time +12:07 < horms> though it is an interesting idea for the future, now you mention it +12:07 < geertu> :aurent was invited, but he's in ca.us +12:07 < geertu> s/:/L/ +12:07 < horms> ok +12:07 < horms> he is a busy man +12:07 < geertu> Nah, he's asleep now ;-) +12:08 < horms> dammsan: do we have some sort of business relationship with Mike? +12:08 < dammsan> my superiors may have such a setup with his superiors +12:08 < horms> ok, i understand +12:08 < dammsan> so if we are blocked we should involve them +12:08 < horms> good to know +12:10 < dammsan> ok guys, i'm task switching now +12:10 < dammsan> see ya later +12:10 < geertu> For next core group chat, does Tuesday, January 5 sound OK? +12:10 < horms> jya ne +12:10 < neg> works for me +12:10 < shimoda> oops, at Jun 5, i will take day off +12:10 < horms> let me check +12:11 < geertu> Monday 4? +12:11 < horms> yes +12:11 < shimoda> at 4th is also day off, Im afraid +12:11 < dammsan> that is in the middle of japanese holidays +12:11 < horms> i will be on a plane on the evening of the 7th +12:12 < geertu> Sorry, didn't know that +12:12 < horms> pahapnese holidays aer most likely from the 29th - 3rd +12:12 < horms> Renesas may have their own schedule +12:12 < horms> wow, nice typo +12:12 < dammsan> heheh +12:12 < horms> Japanese holidays are... +12:13 < geertu> dammsan said in an email: In early 2016 I think we should resume meetings on or after January 6. +12:13 < dammsan> may i suggest the 6th? +12:13 < geertu> 6th is fine for me (actually all days of that week are fine for me) +12:14 < uli___> that's a holiday here, but i'm willing to make an exception :) +12:14 < horms> uli___: you can build up your appetite for your holiday lunch :) +12:14 < geertu> Epiphany is a legal holiday in the following provinces of germany: +12:15 < geertu> Baden Wuerttemberg, Bavaria, Saxony Anhalt +12:15 < uli___> aka the good ones :) +12:15 < neg> and in Sweden, but it works for me anyway +12:15 < geertu> Thanks for joining! +12:16 < geertu> Have a nice evening/day/night diff --git a/wiki/Chat_log/20151221-io-chatlog b/wiki/Chat_log/20151221-io-chatlog new file mode 100644 index 0000000..1a160bc --- /dev/null +++ b/wiki/Chat_log/20151221-io-chatlog @@ -0,0 +1,176 @@ +--- Log opened Mon Dec 21 08:56:55 2015 +08:56 -!- wsa_ [~wsa@p4FE25308.dip0.t-ipconnect.de] has joined #periperi +08:56 -!- Irssi: #periperi: Total of 9 nicks [0 ops, 0 halfops, 0 voices, 9 normal] +08:56 -!- Irssi: Join to #periperi was synced in 2 secs +08:57 < wsa_> hiya +08:57 < horms> hi +09:00 < wsa_> hi simon +09:00 < geertu> Hi +09:01 < morimoto> hi +09:01 < wsa_> Geert, Morimoto-san :) +09:03 < wsa_> Does somebody know about Shimoda-san? Will he be able to join? +09:03 -!- shimoda [~shimoda@relprex3.renesas.com] has joined #periperi +09:03 < wsa_> There he is :) +09:03 < wsa_> hello shimoda-san! +09:03 < shimoda> sorry for the late +09:03 < shimoda> hello wolfram-san! +09:04 < wsa_> no problem +09:04 < wsa_> then let's start +09:04 < wsa_> only topic I have for today is syncing todo list +09:05 < wsa_> i'd think we should start with that one +09:05 < wsa_> and then see, if there are topics left +09:05 < horms> (i sense the todo lists may end up being the primary task of team leaders!) +09:05 < wsa_> yes +09:06 < wsa_> so, my diff since last meeting looks like this: +09:06 < wsa_> @@ -6 +5,0 @@ ADC,?,noplan,?,Unsupported currently; needs driver +09:06 < wsa_> -r8a7795,?,noplan,?,Upstream PWM enablement patches from BSP +09:06 < wsa_> @@ -9,0 +9 @@ SpeedPulse,?,noplan,?,Unsupported currently; needs driver +09:06 < wsa_> +Thermal,v4.5,public,morimoto,add thermal-zone support for Gen2 +09:06 < wsa_> @@ -33 +33 @@ MMCIF,?,noplan,?,improve error reporting +09:06 < wsa_> -r8a7795,?,plan,?,upstream enablement patches from BSP (Kaneko-san?) +09:06 < wsa_> +SATA,?,plan,?,upstream Gen3 enablement patches from BSP +09:06 < wsa_> @@ -55,2 +55 @@ I2C,?,noplan,?,Gen3 can tweak SCL/SDA signals but driver needs support +09:06 < wsa_> -I2C,v4.5,plan,wolfram,rework PM for the multi master case +09:06 < wsa_> -I2C,v4.5,public,wolfram,fix clock calculation (LVTTL vs. OpenDrain) +09:06 < wsa_> +I2C,v4.5,public,wolfram,rework PM for the multi master case +09:06 < wsa_> @@ -78 +76,0 @@ USB3Host,?,noplan,shimoda,suspend problems +09:06 < wsa_> -USBPHY/Gen3,v4.5,public,shimoda,Upstream driver +09:06 < wsa_> @@ -86 +84 @@ Clocks,?,plan,wolfram,clock-off debug patches for r8a7790 +09:06 < wsa_> -I2C,v4.3,merged,Wolfram,continue to improve slave support for Gen2 +09:06 < wsa_> +I2C,v4.3,merged,wolfram,continue to improve slave support for Gen2 +09:06 < wsa_> @@ -93,0 +92,2 @@ EtherAVB,v4.5,merged,kaneko,Upstream patches from BSP v3.0.2 +09:06 < wsa_> +I2C,v4.5,merged,wolfram,fix clock calculation (LVTTL vs. OpenDrain) +09:06 < wsa_> +USBPHY,v4.5,merged,shimoda,Upstream driver for Gen3 +09:06 < wsa_> @@ -33 +32,0 @@ MMCIF,?,noplan,?,improve error reporting +09:06 < wsa_> -SATA,?,plan,?,upstream Gen3 enablement patches from BSP +09:06 < wsa_> which basically means +09:06 < wsa_> PWM und SATA bindings went upstream +09:07 < wsa_> I2C clock calculation and USBPHY went upstream +09:07 < horms> SATA integration is also in mainline (the dts/dtsi bits) +09:07 < wsa_> I2C multi master handling went public +09:07 < wsa_> yes +09:07 < wsa_> typo, s/bindings/enablement/ +09:08 < horms> the bindings are also in mainline +09:08 < wsa_> and I added the thermal-zone task for thermal which morimoto-san currently works on +09:09 < wsa_> so, quite some stuff which went upstream or public +09:09 < wsa_> which is nice :) +09:09 < wsa_> I do have a question about the 'request' file +09:09 < horms> from my side i see we are making steady progress, which is good +09:10 < wsa_> In my todo-list, the I2C-DMA task is planned for 2016-05-31 +09:10 < morimoto> wsa_: thank you for adding me about thermal_zone +09:11 < wsa_> in the request file, ",Upstreaming and Test with DMA v1" is planned for 2016-09-30 +09:11 < wsa_> So, it looks to me the task has been rescheduled? +09:11 < wsa_> Is my assumption correct? +09:12 < wsa_> A similar case for USB3Func +09:12 < morimoto> This "request" was indicated on previous PeriPeriCon. and not well synced :P +09:13 < morimoto> We are happy if we can have it until 2016-09-30 +09:13 < wsa_> so, i keep the dates from my todo-file? +09:14 < morimoto> We want to sync todo <-> request somehow +09:15 < morimoto> I think each leader updates "todo", and Renesas updates "request". +09:15 < wsa_> ok, this seems like work-in-progress, I'll keep the dates and keep an eye on what's happening there +09:16 < wsa_> 'request' says: +09:16 < wsa_> Thermal,2016-03-31,request,?,Upstreaming For H3 +09:16 < wsa_> I'll add an item to the todo-list, because this is "kind of soon" and the task doesn't look trivial to me +09:18 < wsa_> what about Gen2 MMCIF items? Does it make sense to keep them? +09:18 < wsa_> 29 MMCIF,?,noplan,?,DMA support +09:18 < wsa_> 30 MMCIF,?,noplan,?,PM support +09:18 < wsa_> 31 MMCIF,?,noplan,?,improve error reporting +09:18 < geertu> There's also a known crash in mmcif during suspend on lager +09:19 < wsa_> and one when you turn lockdep on +09:20 < wsa_> I'd think OOPSes are always worth an action item :) +09:20 < wsa_> but stuff like PM or DMA support? Dunno +09:20 < horms> fwiw, i see trouble on koelsch and lager on recent linux-next trees. I am yet to investigate (I was hoping the problem would go away!) +09:20 < wsa_> I can keep them, but I wonder their value when doing the reports ;) +09:21 < geertu> horms: lost SPI FLASH partitions? +09:22 < horms> let me try a boot +09:22 < wsa_> morimoto: what do you think about the MMCIF items? +09:22 < wsa_> geert: the task "SCIF,v4.6,plan,geert,SCIF FIFO flushing", is it the same as "SCIF,?,noplan,?,FIFO drain issue"? +09:23 < morimoto> do you mean keep or delete ? +09:23 < wsa_> morimoto: what would be your choice? :) +09:24 < morimoto> We want to fix issue, but no resource, and Gen3 doesn't need it +09:24 < geertu> Oh, ot's already there? So the wiki is not up to date? +09:25 < morimoto> wsa_: is this the point ? +09:25 < geertu> (ah, the wiki doesn't show noplan ;-) +09:25 < wsa_> morimoto: yes, thanks. I'll keep it for the record then +09:26 < morimoto> geertu: yes it doesn't indicate some of them (depend on schedule/person/status) +09:27 < wsa_> geertu: "SCIF,v4.5,plan,geert,DMA support for Gen3": is it v4.5 or v4.6 material? +09:27 < morimoto> Now, I'm planing to update more about peripelist +09:27 < morimoto> person = ?, and status = "plan" mean "no resource" +09:28 < geertu> It's too later for v4.5 +09:28 < morimoto> it can be indicate as "red and bold" +09:28 < horms> geertu: boot log http://pastebin.com/ewvThT4Y +09:28 < wsa_> geertu: That's what I thought, too, I'll change to v4.6 +09:29 < horms> geertu: looks like something for Laurent +09:29 < geertu> horms: Known issue in media-next +09:29 < wsa_> same for the IP core switcher :/ +09:29 < horms> geertu: excellent, thanks +09:29 < geertu> horms: That's why I dropped media-next for last renesas-drivers +09:29 < horms> haha +09:30 < horms> shall we ask stephen to drop it too? +09:30 < geertu> horms: Looks like I'll have to drop it for tomorrow, too +09:32 < wsa_> I also added "I2C,v4.6,plan,wolfram,improve runtime power management" +09:33 < wsa_> i think we can improve by using auto-suspend +09:33 < wsa_> shouldn't be a lot of work, but should be covered +09:35 < wsa_> that's all items I have for today +09:35 < shimoda> I would like to update todo about usb +09:35 < shimoda> -USB3Func,2016-05-31,plan,shimoda,Unsupported on Gen3 currently; needs driver +09:35 < shimoda> +USB3Func,2016-05-31,public,shimoda,develop the driver +09:36 < shimoda> +USB3Host,v4.5,merged,shimoda,add support for Gen3 +09:36 < wsa_> oh, you published the func driver already? i missed that, sorry +09:37 < wsa_> Happily added these items :) +09:38 < shimoda> thanks! :) +09:38 < horms> shimoda: I responded to your "renesas,usb3-peri-r8a7795" email to periperi +09:39 < wsa_> horms: ho is PTP going? do we need another item besides "EtherAVB,v4.5,public,simon,initial PTP support"? +09:39 < wsa_> how +09:39 < horms> good question, let me check real quick +09:40 < geertu> wsa_: The other SCIF task +09:40 < geertu> wsa_: The other "new" SCIF task is also a dupe +09:40 < wsa_> geertu: yes, fixed that already +09:41 < wsa_> i now have: +09:41 < shimoda> horms: thank you! but, we have to keep "renesas,usb3-peri-r8a7795" because the style of other drivers style are peripheral-soc? +09:41 < wsa_> 46 SCIF/HSCIF,v4.5,public,geert,Baud Rate Generator for external clock +09:41 < wsa_> 47 SCIF,v4.6,plan,geert,DMA support for Gen3 +09:41 < wsa_> 48 SCIF,v4.6,plan,geert,Extend subsystem with GPIO-based software handling and hardware flow control +09:41 < wsa_> 49 SCIF,v4.6,plan,geert,SCIF FIFO flushing +09:42 < horms> shimoda: rob has requested that we make new bindings use the new driver. I think its reasonable though it looks a build untidy as we end up with mixed styles for similar drivers. My advice is to follow is request. But if you don't want to then I recommend explaining to him why. Of course its really up to you and I doubt that Rob will argue much. +09:44 < shimoda> horms: thank you for the advice. I don't have any requeirement about the string order, I will follow him +09:44 < horms> wsa_: I think the PTP specific tasks for EtherAVB are done. There is some fallout that is being resolved, but I don't expect any resulting patches to change the funtionality. There are also non-PTP patches both merged and prototype for EtherAVB. I am managing them through the Upport todo list. SO I think you can change the above EtherAVB task to "merged" and leave it at that. +09:45 < wsa_> horms: good news +09:46 < horms> It seems the more patches for EtherAVB we push the more inclined Sergei is to send patches for EtherAVB or sh-eth. So its like a 2 for the price of one deal. Though Sergei is a rather noisy fellow. +09:47 < wsa_> I agree with all what you said :) +09:48 < wsa_> anything else? +09:48 < horms> Just tap the floor twice if you agree and once if you don't. +09:48 < geertu> horms: Especially when he wants to return to the old days of text justification for daisy wheel printers ;-) +09:49 < horms> :) +09:49 < horms> Lets say there is a certain irony when his patches fail checkpatch.pl +09:50 < wsa_> :D +09:50 < geertu> RENESAS ETHERNET DRIVERS +09:50 < geertu> R: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> +09:51 < horms> that was one of the results of kaneko-san posting patches for ethernet +09:51 < horms> it was not exactly what i had hopped for +09:52 < horms> but if he actually was to step up and maintain the drivers then personally i would think it was a positive thing. others may have other opinions on that +09:52 < geertu> It may be justificatin for Sergei against his management to spend time on it. +09:54 < horms> Indeed, that is possible +09:57 < wsa_> i think we are done +09:58 < wsa_> i will push the updated todo to the repo +09:58 < wsa_> and write a short report +09:58 < horms> great, thanks +09:58 < wsa_> so, guys, thanks for all your work in 2015! +09:58 < shimoda> thank you! +09:58 < horms> likewise. +09:59 < wsa_> it is a really great experience for me to work with you! +09:59 < geertu> you're welcome +09:59 < wsa_> i hope you and your families arrive fine in 2016 +10:00 < wsa_> and that we continue then where we left off :) +10:00 < wsa_> hacking upstream the right way (tm) +10:00 < wsa_> ;) +10:01 < geertu> +1 +10:02 < horms> nice, best wishes to you too. looking forward to more in 2016. +10:03 < morimoto> Thanks you guys. have a nice Christmas, and new year. bye +10:03 < shimoda> see you next year! +10:04 < geertu> thx / cu / bye! +10:04 < wsa_> yes, bye! see you! +10:04 -!- morimoto [~user@relprex3.renesas.com] has left #periperi ["ERC Version 5.3 (IRC client for Emacs)"] +10:04 -!- horms [~horms@59-100-149-82.cust.static-ipl.aapt.com.au] has quit Quit: Leaving +10:06 -!- shimoda [~shimoda@relprex3.renesas.com] has quit Quit: WeeChat 0.4.2 +--- Log closed Mon Dec 21 10:06:55 2015 diff --git a/wiki/Chat_log/20160106-core-chatlog b/wiki/Chat_log/20160106-core-chatlog new file mode 100644 index 0000000..eac8ad4 --- /dev/null +++ b/wiki/Chat_log/20160106-core-chatlog @@ -0,0 +1,293 @@ +Core-chat-meeting-2016-01-06 + +10:03 < geertu> Today's Agenda: +10:03 < geertu> 1. Upcoming Gen3 development for the Core group, +10:03 < geertu> 2. Status check for tasks from last meeting - what is remaining? +10:03 < geertu> Topic 1. Upcoming Gen3 development for the Core group +10:04 < dammsan> i'm working on the IPMMU +10:04 < dammsan> i've updated the boot loader and 4GiB of RAM is supposed to be available +10:05 < geertu> "supposed to be" +10:05 < dammsan> need to test that, and try to use IPMMU with the DU/VSP +10:05 < dammsan> i'd like to sync the boot loader update with other people as well +10:05 < pinchartl> dammsan: I was going to mention that +10:06 < dammsan> morimoto: shimoda: how can we share boot loader binaries with all the members? +10:06 < pinchartl> should we make sure we all use the same bootloader ? +10:06 < dammsan> i think so +10:06 < pinchartl> or should we make sure we test our kernel on a variety of bootloaders ? +10:06 < geertu> Both are valuable options +10:06 < dammsan> there are too many combos +10:06 < morimoto> dammsan: do you mean export problem ? +10:06 < dammsan> if you mix and match +10:07 < dammsan> morimoto: that could be some issue. i was more thinking of how to provide the information +10:07 < geertu> We mix toolchains, kernel configs, userland, ... too +10:07 < dammsan> morimoto: is it under NDA? +10:07 < dammsan> geertu: that is true +10:08 < pinchartl> I believe it depends on whether we can expect customers to use a recent boot loader +10:08 < morimoto> dammsan: it is difficult question... +10:08 < geertu> The bad thing (compared to toolchains, kernel configs, userland) is that the firmware is a black box +10:08 < pinchartl> there's no point in testing a boot loader that is not used +10:08 < dammsan> table.txt describes six different components at this point +10:08 < dammsan> just to get to u-boot +10:09 < dammsan> i recommend using complete releases, instead of mixing and matching +10:09 < dammsan> morimoto: can you ask ito-san about how to share boot loader stuff? +10:09 < morimoto> dammsan: OK but tomorrow +10:09 < dammsan> morimoto: i think other guys like baylibre also need new boot loader +10:09 < dammsan> sure +10:10 < dammsan> maybe we can have boot loader upgrade fest at peripericon +10:10 < dammsan> anyway, i'm poking around with those things +10:10 < dammsan> other people? +10:11 < neg> working on SYS-DMAC, making slow progress :) +10:11 < dammsan> neg: i can share my older gen2 bits with you +10:11 < dammsan> not sure if i made them public +10:12 < dammsan> i probably did +10:12 < neg> '[PATCH] ARM: shmobile: IPMMU and DMAC prototype' ? +10:12 < pinchartl> dammsan: table.txt ? do you mean table.html ? +10:13 < geertu> dammsan: How many boards will survive the boot loader upgrade and capacitor soldering fest? ;-) +10:13 < dammsan> neg: need to look into detail, lets chat more later after this meeting +10:13 < neg> geertu: did you evere here back from Vinod Koul for on '[PATCH] dmaengine: use phys_addr_t for slave configuration' ? +10:13 < neg> dammsan: ok +10:13 < geertu> neg: 2015-12-15: "I should be able to do this in next few days... +10:14 < geertu> " +10:14 < dammsan> pinchartl: table.txt is from SCIF D/L mode boot loader update script sent yesterday +10:14 < dammsan> geertu: prediction - zero =) +10:14 < pinchartl> dammsan: ah ok +10:15 < shimoda> about boot loader, yocto team releases it at github, but it is a few old +10:15 < shimoda> https://github.com/renesas-rcar/meta-renesas/tree/fido/meta-rcar-gen3/recipes-bsp +10:15 < geertu> How many of these 6 parts contain GPLed code? +10:18 < pinchartl> I see 3 boot loaders, one (un)trusted OS, a certificate and boot parameters +10:19 < pinchartl> do we know how the pieces fit together exactly ? +10:20 < pinchartl> it looks like source code is available for everything but the boot parameters and the certificate +10:20 -!- shimoda [~shimoda@relprex1.renesas.com] has quit [Ping timeout: 240 seconds] +10:20 -!- morimoto [~user@relprex1.renesas.com] has quit [Ping timeout: 260 seconds] +10:21 < pinchartl> will dammsan be next ? +10:21 < dammsan> shimoda: indeed looks a bit old +10:21 < dammsan> geertu: fortunately i don't have to look inside the box +10:22 < dammsan> if you find something fishy let us know and we will try to improve the situation +10:22 < dammsan> neg: i sent you my more recent gen2 experiment via email +10:23 < dammsan> pinchartl: you only have to care about running the script that i sent you +10:23 < neg> dammsan: thanks +10:23 < dammsan> good thing is that the SoC has Mask ROM SCIF D/L support so it is difficult to brick +10:23 < pinchartl> dammsan: with the binaries +10:24 < pinchartl> difficult or impossible ? :-) +10:24 < dammsan> pinchartl: if you have time then i can think of many more important things to do =) +10:24 < pinchartl> :-) +10:25 < dammsan> pinchartl: i build my own u-boot and omitted some secure code when i received the board during summer vacation +10:25 < dammsan> but there is enough bugs as-is without trying to poke around +10:25 < dammsan> for instance, to get IPMMU working update is needed +10:25 < dammsan> i am also pretty sure that SMP will need more work +10:26 < pinchartl> do we need to update before february ? +10:26 < dammsan> anyway, i think we should consider upgrading rather soon +10:27 < dammsan> so we can enable more memory upstream +10:27 < pinchartl> ok +10:27 < dammsan> lets see what morimoto-san and shimoda-san says +10:27 < dammsan> what are other people hacking on? +10:28 < geertu> I want to look into SYSC PM Domains and integrate it with your DT CPU bringup series +10:28 < dammsan> cool +10:29 < dammsan> when i hear PM i am also thinking of making sure Suspend-to-RAM works +10:29 < dammsan> ideally i wanted to get that going before enabling SMP +10:29 < geertu> SMP is already enabled ;-) +10:30 < geertu> And I want to fix suspend with CONFIG_DEBUG_RODATA=y +10:30 < dammsan> yeah, so now we need to consider SMP as well +10:30 < dammsan> which drags in the boot loader dependency +10:30 < dammsan> geertu: we were talking about SCIF hardening with DMAC +10:31 < dammsan> part of DMAC enablement i guess +10:31 < geertu> "ARM: mm: flip priority of CONFIG_DEBUG_RODATA" revealed a big in the shmobile asm suspend code. The patch was reverted, but will come back in next merge window +10:31 < geertu> Yeah, another thing I plan to do +10:32 < geertu> s/big/bug/ +10:32 < dammsan> geertu: may i ask about ordering +10:32 < dammsan> with SYS-DMAC enablement and also PM +10:32 < geertu> Sure +10:32 < geertu> What's your preferred order? +10:32 < dammsan> does it make sense to enable some initial support before updating the boot loader? +10:33 < dammsan> geertu: did SMP work for you or not - i don't remember +10:33 < geertu> Yes, SMP works (all 8 cores) +10:33 < geertu> If it doesn't work, try SW10 +10:33 < dammsan> good! +10:33 < dammsan> i've spent quite some time with SW10 updating boot loaders thanks =) +10:34 < dammsan> so i guess enabling DMAC is a rather good activity +10:34 < dammsan> doing that this month, does that make sense? +10:35 < geertu> Sure +10:35 < dammsan> and later on roll in IPMMU +10:35 < dammsan> how about the PM bits +10:35 < dammsan> doing Suspend-to-RAM before or after or parallel? +10:36 < dammsan> i think the timer needs some work too +10:36 < geertu> after / parallel (if the other becomes blocked)? +10:37 < dammsan> sounds good +10:37 < dammsan> it would be neat to get kexec working too +10:37 < geertu> Is it working now on arm64 in general? +10:37 < dammsan> i would assume no +10:38 < dammsan> so geertu: for SCIF hardening and DMAC enablement, what is needed apart from DTS? +10:39 < dammsan> i saw your recent BRG patches, shall Mbps setting over loopback work? +10:39 < geertu> It should +10:40 < dammsan> great!! +10:40 < geertu> dammsan: Fixing the hardware (perhaps)? +10:40 < dammsan> obviously with b0rk timer nothing works well +10:41 < dammsan> geertu: what pending issue are you thinking of? +10:41 < geertu> last time I tried, RX SCIF DMA didn't work at all +10:41 < geertu> (Yes, I have to retry) +10:41 < geertu> on r8a7795 +10:42 < dammsan> geertu: maybe we can revisit after data sheet update and boot loader update +10:42 < dammsan> how about other people? +10:43 < dammsan> pinchartl: you were proposing to conver the IOMMU driver to be more modern for ARM32? =) +10:43 < geertu> dammsan: Speaking about datasheet update, I have to look into the recent errata for CPG +10:43 < pinchartl> dammsan: yes +10:44 < dammsan> geertu: yeah, errata.. also we were talking about keeping the GPIO MSTP bit enabled +10:44 < pinchartl> if we want to use the same IOMMU driver on ARM32 and ARM64 we'll need that +10:45 < dammsan> pinchartl: i was hoping that you could work with neg for the framework bit for IPMMU + DMAC +10:45 < pinchartl> do you mean guiding Niklas or writing the code myself ? :-) +10:45 < dammsan> pinchartl: i was never opposed to that change, but i did not want to block r8a7795 prototype support on that +10:46 < dammsan> pinchartl: how about you work together and figure out the details by yourself? =) +10:46 < pinchartl> I won't have time to do the work in January, but I can guide Niklas +10:46 < dammsan> geertu: what do we have on the todo list that need attention from pinchartl? +10:47 < dammsan> i want renesas-drivers to have working DU VGA-out on Salvator-X +10:47 < dammsan> so i can poke around with IPMMU on top of that +10:48 < pinchartl> that is on my to-do list +10:48 < geertu> dammsan: pinctrl documentation acked-by ;-) +10:48 < dammsan> pinchartl: guiding neg sounds good +10:48 < pinchartl> speaking of DU VGA out +10:48 < pinchartl> that involves the VSP1 +10:48 < pinchartl> and thus V4L2 +10:48 < geertu> dammsan: a patch fixing the vsp1 BUG() with media-next? +10:48 < pinchartl> I'm not in best terms with the V4L2 maintainer at the moment +10:48 < pinchartl> which could introduce delays in getting patches upstream +10:49 < pinchartl> geertu: that's an open issue +10:49 < pinchartl> media-next is broken +10:49 < dammsan> pinchartl: thats fine +10:49 < pinchartl> and if it comes to the worst I'll nack the pull request to Linus +10:49 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi +10:49 < geertu> shimoda-san: Welcome back! +10:50 < dammsan> pinchartl: we need to have something working for use by ourselves and the BSP team +10:50 < pinchartl> dammsan: internally or upstream ? +10:50 < dammsan> in renesas-drivers to begin with +10:50 < dammsan> upstream too, but i understand it may be difficult to control that timing +10:50 < pinchartl> it's very difficult at the moment +10:50 < geertu> Does vsp1 work with current renesas-drivers (i.e. excl. current media-next)? +10:51 < pinchartl> it should but I haven't updated renesas-drivers for about a month +10:51 < pinchartl> I'll test it +10:51 < dammsan> gpinchartl: please do =) +10:51 < pinchartl> for upstream I'm not sure what I can do +10:52 < pinchartl> neither now nor in the future +10:52 < dammsan> please guide morimoto with HDMI audio +10:52 < pinchartl> HDMI audio on Gen3 ? +10:52 < shimoda> geertu: hi :) +10:52 < dammsan> gen2 to begin with +10:52 < pinchartl> that should be fine +10:53 < pinchartl> but isn't this a core meeting, not a multimedia meeting ? :-) +10:53 < dammsan> aright +10:53 < pinchartl> I'm fine discussing multimedia +10:53 < pinchartl> but we have a multimedia meeting tomorrow +10:53 < pinchartl> I don't want to hijack today's meeting +10:53 < dammsan> yes lets do that then +10:53 < dammsan> but i need to make sure we can consume your stuff +10:53 < dammsan> and it goes through geerts tree +10:54 < dammsan> DU+VSP is starting to become a bottleneck +10:54 < dammsan> thanks for looking into that +10:54 < pinchartl> I'll make sure it works with renesas-drivers excluding media-next +10:54 < geertu> git rerere is my friend +10:54 < dammsan> please work with geert to sort it out +10:54 < pinchartl> but for upstream I have no idea how things will turn out +10:54 < pinchartl> if I nack the media-next pull request my ability to get anything merged in media will be diminished +10:54 < dammsan> pinchartl: please talk with hayama-san about that too +10:55 < geertu> For now I can keep excluding media-next, but as soon as Linus has pulled it, we're in trouble +10:55 < pinchartl> if I don't nack it, all kind of crap will end up in mainline +10:55 < geertu> Good, Linus doesn't like crap +10:56 < pinchartl> Linus knows about this already, I know that Mauro has personally contacted him to complain about me +10:56 < pinchartl> I don't know what the outcome of their discussion was though +10:56 < geertu> oops +10:58 < dammsan> regarding upstream merge, i guess we're waiting for the CPG and integration code to hit mainline? +10:58 < pinchartl> upstream merge of what ? +10:58 < geertu> They're in next +10:58 < dammsan> yeah +10:58 < dammsan> a lot of integration code is built but not yet merged upstream +10:59 < dammsan> not sure if any V4L2 explosion will affect ARM64 merge? +10:59 < pinchartl> dammsan: regarding the upstream merge of what ? +10:59 < dammsan> pinchartl: basic initial soc support +11:00 < pinchartl> ok +11:00 < dammsan> i keep my fingers crossed +11:01 < dammsan> neg: do you have any short term "easy stuff" on your todo? +11:01 < dammsan> you may be busy with what you have, but if you need something simple to switch to then please check with geert +11:01 < neg> will do thanks +11:02 < pinchartl> by the way, this is off-topic fore core, but if anyone has advices regarding nacking the media-next pull request vs. not doing it and resigning from V4L2 development, I'll be happy to hear them. we can discuss that later +11:02 < dammsan> i suggest expressing your disagrement lightly in a public space and then take some vacation +11:03 < dammsan> vacation is underrated +11:04 < pinchartl> I wish I could take vacations now :-) +11:05 < dammsan> speaking of which, we need to find some sight seeing spot for peripericon and the nice weather +11:06 < dammsan> pinchartl: let me know how i can help you +11:06 < geertu> FOSDEM is the coldest period of the year in Belgium +11:06 < geertu> Still hot for the Finnish +11:06 < pinchartl> dammsan: if I know how you could, I'd have asked you already :-) +11:09 < dammsan> geertu: we can perhaps browse the local town +11:10 < dammsan> while wearing snow board gear +11:10 < geertu> http://www.oudemarktleuven.be/ +11:10 < geertu> Longest bar in the world ;-) +11:11 < geertu> Any other Upcoming Gen3 development for the Core group? +11:12 < dammsan> geertu: you cant go wrong with that +11:13 < dammsan> geertu: maybe not development, but did anyone plan on building loopback adapters following my plan (or something else?) +11:13 < dammsan> i wanted to do MSIOF loopback but that did not work, need to redo on Gen2 for testing purpose +11:13 < geertu> MSIOF is broken on Gen3 +11:14 < geertu> All my (3) adapters are in-use on Koelsch +11:14 < geertu> Will try your setup for SCIF DMA on Salvator-X +11:15 < dammsan> neg: my plan is to give you a break out adapter at peripericon +11:16 < dammsan> geertu: sounds good +11:16 < dammsan> pinchartl: just one final note about IPMMU on Gen3 - some errata exists so i need to keep on doing prototype code with workaround +11:17 < neg> nice, break out adapter for what interface? +11:17 < dammsan> a general purpose thing located by geert, you can use it for many different things +11:17 < dammsan> for instance serial port loopback +11:17 < pinchartl> dammsan: other than the errata I've already received ? +11:17 < neg> ahh ok +11:17 < dammsan> geertu: can you look into using the DT overlays then? +11:18 < dammsan> pinchartl: there is no public information available yet +11:18 < geertu> dammsan: Sure, using overlays all over the place +11:18 < dammsan> or even closed one +11:18 < geertu> dammsan: topic/overlays and topic/renesas/overlays +11:18 < dammsan> geertu: great +11:18 < dammsan> so expect slow IPMMU progress +11:19 < dammsan> thats all from my side +11:19 < geertu> neg: http://www.zebax.com/doc/ZX1/ZX145QTE-020.pdf +11:19 < pinchartl> dammsan: I have received +11:19 < pinchartl> R-CarGen3_HardWare_Manual_Errata_for_Rev050_Oct_31.xlsx +11:19 < pinchartl> R-CarGen3_HardWare_Manual_Errata_for_Rev050_Nov_30.xlsx +11:19 < pinchartl> R-CarGen3_HardWare_Manual_Errata_for_Rev050_Dec_31.xlsx +11:19 * geertu too +11:21 < shimoda> oops, I also have Aug and Sep versions, so I will send them to you later via jinso +11:21 < pinchartl> shimoda: thank you +11:21 < geertu> Would be great, thanks! +11:25 < geertu> Topic 2. Status check for tasks from last meeting - what is remaining? +11:25 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list +11:25 < geertu> Is Simon still in the US? +11:25 < dammsan> AU +11:25 < dammsan> i think he arrived in japan on friday +11:25 < dammsan> arrives +11:26 < dammsan> so yes +11:26 < geertu> But still living in a US timezone ;-) +11:26 < dammsan> somehow +11:26 < geertu> I think I have to s/v4.4/v4.6/g and s/v4.5/v4.6/g? +11:27 < geertu> Except for CPG/MSSR +11:27 < dammsan> most likely +11:29 < geertu> dammsan: What happened to adding renesas,intc-ex-r8a7795 to the driver? +11:30 < dammsan> geertu: nothing yet, IRQC and timers are still on my todo. currently overwhelmed by IPMMU workaround stuff +11:31 < dammsan> geertu: i got as far as cooking up a loop back adapter for IRQ pins, but not yet tested +11:34 < geertu> Anything else? +11:35 < dammsan> not from me +11:35 < geertu> For next meeting, I propose Tuesday, January 19, 18h00-19h30 JST / 10h00-11h30 CET +11:36 < pinchartl> geertu: I'll be away that week +11:36 < pinchartl> (on vacation actually, but with e-mail access) +11:36 < shimoda> I'm OK at 19th +11:37 < geertu> pinchartl: Probably we can do without you for once? +11:37 < pinchartl> geertu: you've managed so far, so I think you'll be fine :-) +11:37 < geertu> I'd like not to postpone by one week, as two weeks later we have PeriPeriCon anyway +11:38 < dammsan> 19th sounds good +11:38 < uli___> same here +11:38 < neg> works for me +11:39 < pinchartl> geertu: no worries at all +11:39 < pinchartl> I wasn't asking you to postpone :-) +11:40 < geertu> I just wanted to make you feel more important ;-) +11:40 < pinchartl> :-) +11:40 < dammsan> i think the renesas network is down, but we can assume shimoda-san and morimoto-san are ok +11:41 < geertu> I do see Shimoda-san talking... +11:41 < shimoda> I'm here :) +11:42 < shimoda> however, Morimoto-san already went to home +11:42 < dammsan> geertu: good - that makes one of us +11:42 < dammsan> or two when i look a bit closer +11:43 < geertu> OK, Time to go home ;-) +11:44 < geertu> Thanks for joining diff --git a/wiki/Chat_log/20160108-io-chatlog b/wiki/Chat_log/20160108-io-chatlog new file mode 100644 index 0000000..852a67e --- /dev/null +++ b/wiki/Chat_log/20160108-io-chatlog @@ -0,0 +1,145 @@ +--- Log opened Fri Jan 08 08:54:18 2016 +08:54 -!- wsa_ [~wsa@p4FE25271.dip0.t-ipconnect.de] has joined #periperi +08:54 -!- Irssi: #periperi: Total of 10 nicks [0 ops, 0 halfops, 0 voices, 10 normal] +08:54 -!- Irssi: Join to #periperi was synced in 2 secs +08:54 < wsa_> hiya! +08:55 < horms> hi +08:55 -!- horms_ [~horms@reginn.isobedori.kobe.vergenet.net] has joined #periperi +08:57 < morimoto> Hi +08:59 < geertu> Hi +09:01 < wsa_> horms_: is your son better now? +09:03 < horms> yes, thanks for asking +09:03 < horms> he seems to be recovering well +09:03 < wsa_> \o/ +09:03 < geertu> horms: Glad to hear that +09:03 < horms> so am i :) +09:04 < wsa_> here, a flu is also wandering around, but I decided to skip it :) +09:04 < horms> good plan +09:04 < wsa_> okay, shimoda-san will come later, let's start +09:04 < wsa_> welcome in 2016 again :) +09:04 < geertu> Here it's trying to invade my family (wife and 1 daughter complaining) +09:05 < geertu> Everybody at work/school still +09:05 * wsa_ sends some vitamin C to geertu +09:05 < wsa_> today's schedule is todo updates AFAICS +09:06 < wsa_> horms_: any news from your side? +09:06 * geertu Virtual C received, thx! +09:07 < horms> i have been keeping my integration todo list up to date and indeed that poject rolling. there is some overlap with that work and this group. but i don't recall anything particularly exciting to report. +09:08 < wsa_> yes +09:08 < wsa_> I'll pull the eeprom binding changes in for 4.5 +09:08 < horms> thanks +09:09 < wsa_> morimoto: any news from your side? +09:09 < horms> i already qeued up the change that uses them :) +09:09 < wsa_> :) +09:09 < morimoto> I sent Thermal patch to ML, but not yet responce +09:09 < wsa_> pity +09:10 < geertu> GregKH finally pulled the SCIF BRG work +09:10 < morimoto> I have no other update +09:10 < wsa_> I have a question about this task: +09:10 < wsa_> Thermal,2016-03-31,plan,?,Upstreaming For H3 +09:11 < wsa_> morimoto: you have been working a lot on thermal drivers, so you might want to do this as well. However, you also might be busy with other stuff and I seem to have resources for that task. +09:11 < wsa_> so, what would you think who should do the task? +09:12 < wsa_> geertu: great, will happily mark the task as merged :) +09:12 < morimoto> This is not supper heavy task I think +09:12 < morimoto> I can do it :) +09:13 < morimoto> only last 1 patch +09:13 < wsa_> okay, will assign it to you +09:13 < morimoto> Oops, what do you mean ? +09:13 < horms> were we missing some documentation to allow the thermal driver work to occur? +09:13 < geertu> "merged" means "Feature merged in mainline", so shouldn't we wait for Linus to pull it in? +09:13 < morimoto> Thermal it self is already working anyway. My doint is that use OF style thermal +09:14 < wsa_> the BSP has one driver for Gen2 and Gen3, but I'd think seperate drivers would make more sense there? +09:14 < morimoto> s/doint/doing/ +09:14 < wsa_> from a glimpse, pretty much all they share is the probe function? :) +09:15 < wsa_> geertu: Oh, I assumed "merged" means "as soon as it shows up in linux-next"... and then in renesas-drivers +09:15 < horms> i did too +09:15 < morimoto> wsa_: is this question to me ? +09:15 < wsa_> horms_: no docs, yes, but driver in latest BSP +09:15 < horms> ah ok +09:16 < wsa_> morimoto: which question? :) +09:16 < morimoto> your "from a glimpse..." +09:17 < wsa_> morimoto: well, i wondered if you share this view... +09:18 < wsa_> morimoto: but this question is not super-urgent +09:18 < wsa_> geertu: any other news from your side? +09:18 < morimoto> ok +09:20 < geertu> I've posted more baud rate improvements (for SCIFA/SCIFB) +09:21 < geertu> and a patch to remove the bogus cpufreq notifier which can cause lock ups +09:21 < geertu> Nothing more to report +09:21 < geertu> Did anyone test the cpufreq notifier removal? There were no comments, and Greg took it +09:22 < wsa_> will test once it is in renesas drivers ;) +09:22 < geertu> Has anyone tested recent renesas-drivers on silk/porter/lager/gose/alt? +09:23 < wsa_> so, this task should probably be moved to v4.6? +09:23 < geertu> More specifically: is SCIF still working? +09:23 < wsa_> MSIOF,v4.5,plan,geert,Investigate issues on Gen3 +09:23 < geertu> yes +09:24 < wsa_> I use renesas-drivers quite regularly on Lager +09:24 < wsa_> although I haven't done this year +09:24 < wsa_> will catch up and report if I see issues +09:25 < geertu> recent >= renesas-drivers-2015-12-14-v4.4-rc5 +09:25 < wsa_> I'm quite sure I have done that +09:26 < wsa_> I noted that I lost early boot messages, and only see messages after the clock of the serial clock gets activated +09:26 < wsa_> that used to be different +09:26 < geertu> Ah? +09:27 < geertu> Don't see that on koelsch +09:27 < geertu> koelsch/lager/alt have identical SCIF setups, according to schematics +09:28 < wsa_> ok, i'll have a closer look when this changed and report back to you +09:28 < geertu> The SCIF clock of the console isn't disabled early +09:29 < wsa_> nice to know +09:30 < wsa_> i'll check today or on Monday, latest +09:30 < wsa_> so, my news: +09:30 < wsa_> two items merged +09:30 < wsa_> +PCIE,v4.5,merged,wolfram,test enablement patches for Gen3 +09:30 < wsa_> +I2C,v4.5,merged,wolfram,rework PM for the multi master case +09:30 < wsa_> one assigned to 4.6: +09:30 < wsa_> +SDHI,v4.6,plan,wolfram,Upstream Gen3 DMA support from BSP +09:31 < wsa_> and reposted the IP core switch patches +09:31 < wsa_> and got a nice pointer from Rob that there are patches around which expose more of_dynamic functionality, so I can drop the patch exporting the of_mutex +09:32 < wsa_> which makes the patch series i2c self-contained :) +09:32 < wsa_> the tricky parts will still be the dt bindings +09:34 < wsa_> i think that's all for today? +09:34 < wsa_> except planning the next chat meeting +09:36 < horms> How about we meet at PeriPeriCon? +09:36 < wsa_> what about a short meeting shortly before peripericon, so we are all up to date? I'd propose the 27th, same time +09:36 < horms> fine by me +09:36 < geertu> fine by me, too +09:36 < morimoto> fine by me, too +09:37 < wsa_> cool +09:37 < horms> great, see you all then if not before :) +09:37 < wsa_> yes, thanks guys! +09:37 < morimoto> thanks +09:37 < wsa_> have a great day! +09:38 < geertu> u2 +09:38 < geertu> thx, bye! +09:40 < morimoto> I would like to ask you each peripeleader. do you think you want to have "done" or "finished" file on peripelist ? +09:40 < morimoto> because "todo" file will be filled by "merged" or "complete" status items in the future. +09:40 < morimoto> "todo" file -> current tasks +09:40 < morimoto> "done" file -> finished tasks +09:40 < morimoto> +09:41 < morimoto> Or don't mind about it ? +09:41 < morimoto> I mean don't mind only "todo" file ? +09:43 < wsa_> My preferred thing would be a done file which I only update like once a year or so... +09:43 < wsa_> so i can still see the recent tasks in a todo file +09:43 < wsa_> but only move the real old ones to the done file +09:43 < wsa_> you know what i mean? +09:44 < wsa_> i think you'd only need to read in the 'todo' and 'done' file into one buffer anyhow? +09:45 < wsa_> i've got another question, too +09:45 < morimoto> Yes. final list will be created from "todo + request + done" +09:46 < morimoto> I don't want to create detail rule about "done" file, but I can create it if each leader want it. +09:46 < wsa_> maybe make it optional? if it is there, use it; if not, then not :) +09:46 < wsa_> i got this file "R-Car-Gen3-rev050.tar.bz2" +09:47 < wsa_> but the files in it are the same I already have +09:47 < wsa_> is this intended? +09:47 < morimoto> I think you have +2 new file +09:47 < morimoto> Oct and Sep ? +09:47 < wsa_> aah, errata aug+sep +09:47 < wsa_> understood +09:47 < morimoto> Oops, yes +09:47 < geertu> Yeah, the errata are not incremental +09:48 < geertu> s/not// +09:48 < geertu> I.e. I mean the new errata file doesn't contain the old errata +09:49 < morimoto> Yes. It is not useful... +09:50 < morimoto> About "done" file, I will add it, but it is optional. Each leader can control it by themselves. It is OK ? +09:50 < wsa_> sounds good to me +09:50 < morimoto> Cool +09:52 < wsa_> okay, then, happy hacking, I'll be off +09:52 < wsa_> cya +--- Log closed Fri Jan 08 09:52:09 2016 diff --git a/wiki/Chat_log/20160119-core-chatlog b/wiki/Chat_log/20160119-core-chatlog new file mode 100644 index 0000000..4bd50be --- /dev/null +++ b/wiki/Chat_log/20160119-core-chatlog @@ -0,0 +1,341 @@ +Core-chat-meeting-2016-01-19 + +10:08 < geertu> Agenda: +10:08 < geertu> 1. Upcoming Gen3 development for the Core group, +10:08 < geertu> 2. Could we change initcall() in some drivers? +10:08 < geertu> 3. Status check for tasks from last meeting - what is remaining? +10:08 < geertu> Topic 1. Upcoming Gen3 development for the Core group +10:10 < dammsan> magnus intends to keep on doing IPMMU stuff and also MSIOF MMC-via-SPI on Koelsch +10:11 < dammsan> he would like someone to look into the SYS-DMAC errata bits from Gen2 in the rcar-dmac.c driver +10:11 < geertu> errata bits from Gen2? +10:12 < dammsan> there are at least two - one related to not using the first channel with IPMMU +10:12 < dammsan> another one is about re-initializing some register +10:12 -!- horms_ [~horms@reginn.isobedori.kobe.vergenet.net] has joined #periperi +10:12 < geertu> I mean, do we have them documented somewhere? +10:12 < dammsan> i did not write the workarounds myself, so i'm not sure +10:13 < dammsan> they probably apply to gen2, but maybe not gen3 +10:14 < dammsan> so we may need per-soc compat string matching +10:15 < geertu> OK, bindings for that have been accepted +10:15 < dammsan> gr8 +10:15 < dammsan> saw that the cpg-mssr driver also went in +10:15 < geertu> and adding the compatible values to dtsi is queued in arm-soc/for-next +10:16 < geertu> (does arm-soc plan to miss the merge window?) +10:16 < dammsan> maybe they outsource the patch management to same place as vinod +10:16 < horms> geertu: they seem to like to cut things fine +10:17 < geertu> horms: btw, do you plan to push out a renesas-devel later today? +10:17 < dammsan> so someone need to dive into sys-dmac driver details on gen3 +10:17 < horms> geertu: no plan, assuming i actually pushed yesterday +10:18 < geertu> horms: nope, latest is still renesas-devel-20160111-v4.4 +10:19 < horms> sorry, i'll push now +10:19 < geertu> dammsan: I'm a bit puzzeled +10:19 < geertu> dammsan: errate on gen2 vs. driver details on gen3? +10:19 < dammsan> right now the driver does not differentiate between gen3 and gen2 +10:20 < dammsan> we may not have to deal with all the gen2 errata on gen3 +10:20 < geertu> but it "works" nevertheless +10:20 < geertu> Ah, IC +10:20 < geertu> So basically it's testing if the driver still works on gen3 without the errata for gen2? +10:21 < horms> geertu: sorry about that and thanks for pointing out that I hadn't pushed. The latest should now be renesas-devel-20160118-v4.4 +10:21 < dammsan> yeah, and requesting errata information from renesas if needed +10:21 < dammsan> we also have CAE/CAIR error management for the rcar-dmac.c driver +10:22 < dammsan> so it seems that the driver itself needs some attention at some point +10:22 < geertu> I don't think there was anything SYS-DMAC related in the Gen3 errata we received through Jinzai +10:22 < geertu> horms: got it +10:22 < neg> I know about one of the errat fixes in dmac.c about not using the first channel I can lookinto if that is needed on gen3 and if not try to fix it +10:23 < dammsan> neg: thanks for stepping up +10:24 < morimoto> dammsan: please let me know if you want to ask it to datasheet guys +10:24 < geertu> The first channel issue is only with IPMMU enabled, right? +10:24 < dammsan> i believe so +10:25 < dammsan> morimoto: thanks +10:26 < geertu> I've retried SYS-DMAC on Salvator-X with (H)SCIF, and RX DMA is working now, too. +10:26 < geertu> Strange, as I believe the board I have now is the same I was using remotely before? +10:26 < dammsan> geertu: thanks, i saw your email +10:26 < dammsan> i think we should revisit after upgrading firmware =) +10:26 < geertu> However, I had mixed results with IPMMU enabled +10:27 < geertu> (ah, now I realzie while the console still worked with IPMMU: SCIF2 is on DMAC1, where IPMMU wasn't enabled) +10:27 < geertu> OK, firmware upgrade it'll be +10:27 < dammsan> i think the current working sample of H3 has some IPMMU hardware issues +10:28 < dammsan> so M3 may be in better state for serious IPMMU usage +10:28 < geertu> OK +10:28 < geertu> Anyway, SYS-DMAC is now declared "working" +10:28 < geertu> Moving on to PM... +10:29 < neg> from rcar-dmac.c 'A still unconfirmed hardware bug prevents the IPMMU microTLB 0 to be flushed correctly, resulting in memory corruption.' can we confirm the HW bug somehow? +10:29 < dammsan> neg: that is on gen2 and we could not get information earlier +10:30 < neg> ok I see if I can give it a try on gen3 +10:30 < dammsan> neg: please focus on the framework bits since the hardware itself may be unstable +10:31 < neg> ok +10:31 < dammsan> geertu: regarding PM, is SYS-DMAC working with PM as well? =) +10:32 < dammsan> it used to be a can of worms +10:32 < geertu> dammsan: I think so, at least on Koelsch +10:33 < geertu> Yeah, we had a few PM-related crashes during its development in Summer 2014 +10:33 < dammsan> good! +10:35 < dammsan> is core handling thermal sensor? +10:35 < dammsan> i don't remember +10:35 < geertu> git grep -i therm +10:35 < geertu> io/todo +10:36 < dammsan> if so i would like someone to lookin some errors +10:36 < dammsan> ok i see +10:37 < geertu> Anything else to report for Topic 1? +10:38 < horms> one small thing from the upport world +10:39 < horms> Kaneko-san says the PWM upport is a bit tricky for him. I'll see about handling it myself else report back here or the periperi ML. +10:39 < horms> end +10:40 < shimoda> oh, original pwm driver is made by me +10:40 < shimoda> so, I'll check the bsp patches later +10:41 < horms> his difficulty is with the clocks. i assume because the driver is different in mainline. if you want to handle this feel free to do so :) +10:42 < morimoto> Is this BSP original driver do you mean ? +10:42 < dammsan> geertu: what are you hacking on from now on? +10:43 < horms> I assume the CPG dirvers are different. To be honest I haven't looked at the patches yet +10:43 < morimoto> Ah.. OK thanks +10:43 < dammsan> geertu: i noticed that a bunch of SCIF code went into mainline recently - thanks for that +10:44 < geertu> dammsan: I started SYS-DMAC, but that seems to work now +10:44 < geertu> dammsan: So next will be PM, integrating your CPU bringup for Gen2 with the SYSC PM Domain stuff +10:45 < dammsan> geertu: in your r8a7795 SYS-DMAC DTS patch you wrote you tested MSIOF - may I ask how? +10:45 < dammsan> i could not get MSIOF to work well on Gen3 myself +10:45 < geertu> MSIOF indeed has hardware bugs +10:45 < dammsan> geertu: ok, PM sounds good +10:45 < geertu> But it sends out data when DMA is used +10:46 < dammsan> so _something_ is working =) +10:47 < geertu> Yeah, it behaved the same for PIO and DMA, which IMHO proves that DMA is working ;-) +10:47 < dammsan> equally busted =) +10:48 < dammsan> i'll try to re-verify MSIOF on Gen2 and then revisit Gen3 +10:48 < dammsan> the BSP workaround seems pretty useless +10:49 < dammsan> or rather - i cannot see how it would help MSIOF +10:49 < dammsan> but anyway +10:49 < horms> dammsan: could you verify my sound patches on gose when you have time. They may even work :) +10:49 < shimoda> horms: sorry for the delayed, the commit 2d63d5d9aa6685d028d254ceb877678c0f19363b in renesas-bsp is merged to linux-pwm (72c16a9f98afad073b4a9c947c1c89bfb886ffcb) by me :) +10:49 < geertu> Same for me, haven't tried it yet (on my io todo list) +10:49 < shimoda> so, no need to upport on pwm driver for now +10:50 < dammsan> horms: my gose whines about thermal errors currently +10:50 < horms> oh +10:50 < dammsan> if we could get a loopback test then i'd be happy to connect a cable +10:52 < geertu> dammsan: just compile and run spidev_test.c +10:52 < geertu> In the mean time, SPI got an internal loopback test, but I haven't tried it yet. +10:52 < geertu> Topic 2. Could we change initcall() in some drivers? +10:53 < dammsan> my test case is to use MMC-over-SPI +10:53 < dammsan> but anyway, lets move to topic 2 +10:53 < geertu> The short answer is "always use module_init() (except if ...)" +10:53 < dammsan> this seems to be a per-subsystem thing +10:53 < geertu> There's a global trend to move to module_init() +10:54 < geertu> Excessive deferred-probing is being worked on, cfr. the thread "[RFD] Functional dependencies between device" +10:54 < dammsan> thats nice +10:54 < geertu> Rafael W. posted some initial patches, but they don't derive dependencies from DT yet +10:55 < geertu> For the specific case of renesas-cpg-mssr.c, using a different priority than subsys_initcall() caused issues on r8a7791 +10:55 < dammsan> that must be connected to timer init order somehow +10:56 < geertu> irqc +10:56 < dammsan> ouch +10:56 < geertu> and Ethernet +10:57 < geertu> and R-Car Gen2 regulator quirk (which is actually still a problem, I think) +10:57 < geertu> So yes, it's a mess, and don't touch ;-) +10:57 < geertu> until Rafael will fix it (hopefully) +10:57 < dammsan> hehe +10:58 < dammsan> would it be possible to use cpg-mssr on Gen2 together with MMCIF? +10:58 < dammsan> to provide a reference implementation for the BSP people? +10:58 < dammsan> to get the GPIO regulators and whatnot working as expected +10:59 < geertu> I think so +10:59 < dammsan> geertu: the Gen2 regulator quirk is hopefully not needed on Gen3? +10:59 < geertu> It's board-specific +11:00 < dammsan> i realize it is a board deisng issue +11:01 < dammsan> shimoda: what is the correct way to support the BSP people wrt initcall level? +11:01 < horms> shimoda: thanks, got it +11:01 < geertu> dammsan: You should know, you're doing irqc :-) +11:01 < horms> shimoda: (pwm change) +11:01 < geertu> there are no irqc interrupts shared between devices +11:02 < dammsan> geertu: yes =) +11:03 < dammsan> regarding the initcall discussion, it must make sense to use same levels for upstream and BSP +11:03 < shimoda> dammsan: I sent rcar-gpio things that Morimoto-san mentioned to BSP team +11:03 < dammsan> to avoid cluser fuck +11:03 < shimoda> so, I will wait for their reply for now +11:03 < dammsan> ok thanks! +11:06 < geertu> [advertising: media-next/master has entered mainline, causing a boot crash on koelsch with vsp1 enabled] +11:07 < horms> wtf!!! +11:07 < horms> so it was broken in next for a month +11:07 < horms> known to be broken +11:07 < horms> and then moved to mainline +11:07 < horms> is there more to this story? +11:08 < dammsan> i would be prepared to take that detail if we can get the arm64 bits merged +11:08 < geertu> Not to mention Laurent's "doubts" response to the pull request +11:08 < dammsan> hopefully those are not connected +11:09 < dammsan> horms: what's your plan with CONFIG_RENESAS btw? +11:09 < dammsan> now when the mailing list is sorted i mean +11:09 < horms> geertu: I assume that Laurent is on the case with regards to the media problem. if not perhaps i should speak with him? +11:10 < horms> dammsan: i suppose the symbol is in mainline now/soon so we/I can start updating the drivers. +11:10 < dammsan> sweet +11:10 < horms> is there anything i should focus on there from your pov? +11:10 < dammsan> nah =) +11:10 < dammsan> just curious +11:11 < horms> np. i realised the other day that its about time for some more activity there +11:11 < geertu> horms: Laurent expressed his feelings, cfr. thread "[GIT PULL for v4.5-rc1] media controller next gen patch series" +11:12 < geertu> horms: not much we can do now, I'm afraid. +11:13 < geertu> Either Mauro provides a fix (perhaps after a big rant from Linus), Linus unpulls (unlikely, too many days ago), or nothing happens +11:13 < dammsan> we need a zeroday machine +11:14 < horms> well its more like we have one +11:14 < horms> which is next +11:14 < dammsan> aka smoke machine +11:14 < horms> where this problem showed up weeks ago +11:14 < geertu> I reported the issue more than one month ago +11:15 < horms> well lets hope for a fix +11:15 < horms> its not very good to have one of our main platforms broken in mainline +11:15 < dammsan> very true +11:15 < geertu> You can disable CONFIG_VIDEO_RENESAS_VSP1 +11:15 < dammsan> how about something more recent - how does this affect gen3? +11:16 < horms> geertu: of course. but i suppose customers may want to use vsp... +11:16 < geertu> Hmm, I don't have CONFIG_VIDEO_RENESAS_VSP1 in my Gen3 config yet +11:16 < dammsan> vsp is crucial for DU output on gen3 +11:17 < dammsan> i will have to ask laurent again about current status +11:17 < geertu> Probably broken, too +11:17 < dammsan> this is more worrying to me than gen2 +11:17 < dammsan> but of course it sucks to have breakage +11:18 < horms> can't we just post a fix. the use of BUG_ON seems completely bogus: is it really an error that should take the system down? +11:18 < dammsan> maybe we can fix it with a hackfest at peripericon +11:19 < horms> right, if its still around then it would be a good time to spend some energy on it +11:19 < dammsan> i think so +11:19 < horms> or douse our sorrows in local beer :) +11:19 < dammsan> we can share our time =) +11:19 < dammsan> may have to test on both alt and lager +11:20 < horms> there are many options for Gen2 +11:20 < geertu> horms: Please read my report. Before the (old) BUG_ON() started to trigger, there was already a ULL pointer dereference, introduced by an earlier commit in the series +11:20 < geertu> s/ULL/NULL/ +11:20 < horms> geertu: ok, sorry for jumping to conclusions +11:20 * geertu no media expert +11:21 < dammsan> geertu: do you agree that trying to fix this during peripericon may make sense? +11:21 < geertu> dammsan: do we have all required test peripherals? +11:21 < dammsan> it must be one of our major headaches at the moment +11:22 < dammsan> i don't know how to trigger it i'm afraid +11:22 < geertu> just boot ;-) +11:22 < dammsan> but VSP is usually a memory-to-memory device +11:22 < dammsan> and all Gen2 SoCs have VSP +11:22 < horms> i would suggest moving before peripericon if its a major headache +11:22 < geertu> Now, fixing the crash doesn't mean the system will work +11:23 < dammsan> so can some magician make laurent appear? +11:23 < geertu> Laurent also mentioned user-space impact +11:23 < geertu> which may please Linus even less +11:23 < dammsan> yeah, this has "unpleasant" written all over it +11:25 < dammsan> do we have any major headache for the core group? +11:26 < horms> Mauro does seem to have acknowledged there is a problem, perhaps there is hope of a peaceful resolution to the problem +11:26 < geertu> yeah, he just sent private email to Javier and me. He's on holidays and asks Javier to look into it. +11:27 < geertu> Topic 3. Status check for tasks from last meeting - what is remaining? +11:28 < horms> Our old friend mode pins +11:28 < horms> I guess that is worthy of a slot at peripericon +11:30 < horms> On the integration coverage side, things are moving forwads slowly and surely. I don't see any major headaches at this time. And I may even be so bold as to say entries are being completed faster than new ones are being added. +11:30 < horms> The largest patchset is sound for gose. I plan to do something similar for alt. +11:30 < horms> Thats probably enough on integration imho +11:32 < dammsan> i have timers and interrupts still on my todo +11:33 < neg> DMAC+IPMMU on gen2 works but Vinod have not yet made up his mind if the issue should be solved in the DMAC or by the clients +11:33 < neg> plan to send a v2 tomorrow and see if he have med up his mind +11:34 < horms> neg: please use the new mailing list :) +11:34 < dammsan> neg: this all seems to be about making vinod make up his mind +11:35 < geertu> we need some backing from other ARM IOMMU users +11:35 < neg> horms: will do, thanks for reminding me :) +11:35 < dammsan> geertu: yeah +11:35 < dammsan> the IPMMU+DMAC errata work is not that important compared to getting the framework bits right +11:36 < dammsan> even if we fixed all the IPMMU+DMAC hardware stuff we would still not able to use it without further fixes.. +11:36 < dammsan> neg: i'm really happy that you are dealing with that +11:36 < dammsan> we should have done that ages ago IMO +11:37 < dammsan> geertu: do you know any other SoCs that need the same kind of changes for DMAC+IOMMU? +11:37 < neg> I'm a bit at a loss on how to get backing from other ARM IOMMU users, all I know how to do is ping Vinod +11:38 < dammsan> i wonder if it is possible to use SWIOTLB instead of IOMMU to get the same dependency? if so it would be a software-only thing +11:39 < geertu> dammsan: IIRC, that patch came from Ulf, but he seems to have forgotten about the principle behind it +11:39 < geertu> dammsan: Arnd? +11:39 < geertu> BTW, Mauro asks how to get a koelsch +11:39 < dammsan> yeah +11:39 < dammsan> i can give him remote access if that would help +11:40 < dammsan> that may not work to our advantage though +11:40 < geertu> Should be good enough to fix the boot crash +11:40 < geertu> Yeah, another cam of worms +11:40 < geertu> s/cam/can/ +11:40 < dammsan> isn't it better just to revert the stuff until it can be fixed properly? +11:40 < geertu> The alternative is to wait for Laurent to return from holidays, or someone else dives into it? +11:41 < dammsan> that must be better for all of us +11:41 < geertu> Revert the full merge? +11:41 < dammsan> if that is feasible +11:41 < dammsan> isn't that how things normally would be solved +11:41 < dammsan> if it is not working, dont merg it +11:41 < horms> that is the usual way +11:41 < horms> but its already merged +11:42 < dammsan> i feel remote access is a good last resort +11:42 < horms> and presumably simply reverting it isn't simple +11:42 < horms> i agree it is a good last resort +11:43 < dammsan> hm.. +11:43 < horms> getting Laurent to calmly and awesomely fix it sounds good. but when does he get back? and how busy will he be then? +11:44 < dammsan> geertu: laurent is supposed to spend time on core development this quarter. so he needs to work on that too +11:46 < dammsan> i have got a good idea +11:46 < dammsan> how about reproducing this on all the gen2 boards +11:46 < dammsan> then offer mauro remote access to all of them so he can fix it +11:46 < horms> i haven't seen it on all boards, fwiw +11:47 < dammsan> there is not real difference in my mind +11:47 < geertu> mauro wants to chat. Invite him to #periperi? +11:47 < dammsan> isn't that a good technique to overwhelm as a policial move? +11:47 < horms> i guess i wan't clear. the problem doesn't seem to manifiest on all the boards +11:47 < dammsan> geertu: can we try to reproduce on other boards? +11:48 < dammsan> horms: but the vsp is a generic piece of IP +11:48 < geertu> Sure, boot shmobile_defconfig from current Linus' tree +11:48 < dammsan> so that seems kind of unlikely +11:48 < horms> dammsan: i'm just saying what i see +11:48 < dammsan> let me try on lager +11:48 < dammsan> sure +11:48 < geertu> commit 77a76b04d2be1c45b8fd746b7ef754525029340c +11:48 < geertu> is the bad merge +11:48 < geertu> commit 77a76b04d2be1c45b8fd746b7ef754525029340c^ boots fine +11:51 < dammsan> currently trying to reproduce on koelsch with a200dcb34693084e56496960d855afdeaaf9578f +11:51 < horms> fwiw, i only see vsp1 nodes in DT for the r8a7790 and r8a7791 as of the commit that geert mentioned +11:51 < dammsan> well at least lager should trigger too in such case +11:52 < horms> i need to give my son a bath. i'll come back after that. but fwiw i see no harm in talking with mauro if he wants to chat with us on irc +11:52 < geertu> "git revert -m 1 77a76b04d2be1c45b8fd746b7ef754525029340c" +11:52 < geertu> seems to work +11:53 < geertu> So i'll do that for today's renesas-drivers +11:54 < geertu> Also saves me the hassle of fixing the big merge conflict with git://linuxtv.org/pinchartl/media.git#vsp1-kms-20151217~3 +11:54 < horms> two birds, one stone +11:55 < geertu> vsp1-kms-20151217 is just too old +11:55 < dammsan> sure +11:55 < dammsan> i managed to reproduce on koelsch +11:55 < dammsan> lager is also busted +11:55 < dammsan> like is suspected +11:56 < geertu> neg: did you look into media-controller for the multi-media group? +11:57 < neg> I'm looking in to VIN for media group +11:57 < geertu> ok +11:57 < dammsan> gose does not trigger +11:57 < geertu> no vsp1 in gose dts? +11:58 < dammsan> that's what simon said yeah +11:58 < dammsan> it is soc-specific +11:58 < dammsan> so perhaps some of the low cost boards would trigger for r8a7790 and r8a7791 +11:59 < horms> # grep -l vsp1@ arch/arm/boot/dts/r8a7*.dtsi +11:59 < horms> arch/arm/boot/dts/r8a7790.dtsi +11:59 < horms> arch/arm/boot/dts/r8a7791.dtsi +11:59 < horms> perhaps the other socs would trigger if the nodes were present in DT +11:59 < dammsan> alt also does not trigger - not so surprising +11:59 < dammsan> the configuration may be slightly different from r8a7790/1 though +12:00 < dammsan> but it is likely to trigger regardless +12:00 < dammsan> does anyone have a lcb? +12:00 < horms> it wont be triggered in mainline :^) +12:01 < dammsan> porter or henninger? +12:01 < dammsan> maybe this is when we play the sergey card =) +12:01 < geertu> +1 +12:02 < horms> i recommend playing a card that is likely to get the problem resolved +12:02 -!- horms is now known as horms_away +12:02 < geertu> It should trigger on porter, as the vsp* nodes do not have 'status "disabled"' in r8a7791.dtsi +12:02 < dammsan> morimoto: how can we ask sergei to test upstream for us? +12:02 < geertu> (why are they not disabled?) +12:03 < morimoto> that's good idea +12:03 < dammsan> geertu: they are memory-to-memory devices +12:03 < morimoto> do you want it ? +12:03 < dammsan> and do not expose themselves to board specific things +12:03 < dammsan> similar to thermal +12:04 < dammsan> just self-contained on-chip devices +12:04 < dammsan> geertu: do you think it hurts to involve sergei? i can only see upside +12:05 < geertu> Please wait, Javier has just told me he'll look into it +12:05 < dammsan> is mike turquette around? +12:05 < dammsan> they may have gen2 boards somewhere too +12:05 < dammsan> morimoto: please wait +12:05 < geertu> Aha, mchehab|OOT invites you to ##vsp1 +12:05 < morimoto> OK +12:12 < dammsan> time to wrap up in a while? +12:13 < geertu> Yes +12:13 < geertu> long overdue +12:13 < geertu> BTW, does anyone have a Porter to verify? +12:13 < dammsan> i wish i had one +12:14 < morimoto> geertu: now shimoda-san is checking +12:14 < morimoto> OK, Renesas office have 1 Porter +12:18 < geertu> Good to know. +12:18 < geertu> OK, thanks for joining! +12:18 < morimoto> Thanks! Let's see on Brussels +12:19 < neg> thanks +12:19 < dammsan> thanks, bye bye diff --git a/wiki/Chat_log/20160127-io-chatlog b/wiki/Chat_log/20160127-io-chatlog new file mode 100644 index 0000000..81c78dd --- /dev/null +++ b/wiki/Chat_log/20160127-io-chatlog @@ -0,0 +1,136 @@ +--- Log opened Wed Jan 27 08:56:58 2016 +08:56 -!- wsa_ [~wsa@p4FE25B5E.dip0.t-ipconnect.de] has joined #periperi +08:56 -!- Irssi: #periperi: Total of 9 nicks [0 ops, 0 halfops, 0 voices, 9 normal] +08:56 -!- Irssi: Join to #periperi was synced in 1 secs +08:57 < wsa_> aloha +08:57 < morimoto> Hi +08:58 < wsa_> Renesas Vietnam +08:58 < wsa_> didn't know this branch +08:58 < wsa_> :) +08:59 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi +08:59 -!- horms [~horms@penelope-musen.kanocho.kobe.vergenet.net] has joined #periperi +08:59 < morimoto> Paper company ;) +08:59 < morimoto> (joke) +09:00 < geertu> Any link to Jinzai? +09:00 < morimoto> geertu: what do you mean ? +09:00 < geertu> Jinzai is also Vietnamese, IIRC? +09:01 < morimoto> Ahh, yes, but different. +09:01 < wsa_> it is? +09:01 < wsa_> learning a lot of things today +09:01 < morimoto> Jinzai Vietnam people has no relationship to RVC +09:03 < wsa_> as long as we are waiting for simon +09:04 < wsa_> what is the difference between the F_ and FM macro in the pfc driver? +09:04 < wsa_> when to use F_, when to use FM? +09:04 -!- horms_ [~horms@reginn.isobedori.kobe.vergenet.net] has joined #periperi +09:04 -!- horms_ [~horms@reginn.isobedori.kobe.vergenet.net] has quit Remote host closed the connection +09:04 -!- horms_ [~horms@reginn.isobedori.kobe.vergenet.net] has joined #periperi +09:04 < horms> wsa_: I am here +09:05 < morimoto> wsa_: It is case by case +09:05 < wsa_> so, we are complete +09:05 < morimoto> You can find many #define F_(), and #define FM() on this driver +09:05 < geertu> /* +09:05 < geertu> * F_() : just information +09:05 < geertu> * FM() : macro for FN_xxx / xxx_MARK +09:05 < geertu> */ +09:06 < wsa_> geertu: I saw that, but it didn't help my understanding :/ +09:06 < wsa_> I got the impression that F_ macro wouldn't create *_MARK macros +09:07 < wsa_> but that doesn't seem to be the case +09:08 < wsa_> but maybe this is better explained vis-a-vis +09:09 < wsa_> let's start the meeting +09:09 < wsa_> thanks for the per-mail updates +09:09 < wsa_> they should make the meeting really short +09:09 < wsa_> my updates: +09:10 < wsa_> +SDHI,v4.6,plan,wolfram,Upstream & improve basic Gen3 SD+MMC support from BSP +09:10 < wsa_> @@ -34,2 +35 @@ SDHI,v4.6,plan,wolfram,Upstream Gen3 DMA support from BSP +09:10 < wsa_> -SDHI,?,noplan,?,add UHS-I support +09:10 < wsa_> -SDHI,?,noplan,?,Upstream Gen3 MMC support from BSP +09:10 < wsa_> +SDHI,v4.7,plan,wolfram,Upstream UHS-I/HS200 support +09:10 < wsa_> @@ -51,0 +52 @@ I2C,?,noplan,?,Gen3 can tweak SCL/SDA signals but driver needs support +09:10 < wsa_> +I2C,?,noplan,?,introduce irqless transfers to issue reboot via PMIC +09:10 < wsa_> which is basically SDHI rewording and planning features specifically for 4.6 and 4.7 +09:11 < wsa_> and introducing the idea of irqless i2c transactions to properly reboot via PMICs +09:12 < morimoto> Is it Renesas specific issue ? +09:12 < geertu> Nice +09:12 < wsa_> morimoto: not only +09:12 < morimoto> OK, good +09:12 < wsa_> morimoto: but all RCar boards need it +09:13 < shimoda> about sdhi sd_info2 register, i checked it doens't work on M2 channel 2 +09:13 < wsa_> it has been mentioned on the i2c-list already, too +09:13 < wsa_> shimoda: you mean CBUSY? +09:13 < geertu> wsa_: Would there be a way to call into this from rcar-gen2-quirks? +09:14 < geertu> (see also http://www.spinics.net/lists/linux-sh/msg46448.html) +09:14 < wsa_> geertu: I'd like it to be generic, to limited to the poweroff-case +09:14 < shimoda> wsa_: yes. according to the data sheet, some channels doesn't have CBSY bit +09:14 < shimoda> on gen2 +09:14 < wsa_> but I am not sure about the design, because I2C transfers, SMBUS transfers and regmap transfers need to be covered +09:15 < wsa_> shimoda: that is good to know +09:15 < wsa_> maybe we should just stick to SCLKDIVEN... +09:16 < shimoda> wsa_: I agree with you about stick to SCLKDIVEN if gen2 +09:16 < wsa_> morimoto: what do i do with the thermel h3 upstreaming task if Renesas Vietnam is going to do it? Should I delete it from the io group todo? +09:17 < morimoto> wsa_: we (= Magnus, me, shimoda) and RVC and BSP team will talk about it +09:18 < morimoto> If RVC do it, maybe it can go to rel/todo from io/todo +09:18 < morimoto> But we don't know at this point +09:18 < wsa_> ok, i will wait and keep it until then +09:19 < morimoto> thanks +09:19 < wsa_> what is the "rel" group? +09:19 * wsa_ finds out lots of things today :) +09:20 < morimoto> REL = Renesas Electronics Corporation +09:20 < morimoto> This means Renesas itself +09:21 < wsa_> ah +09:22 < wsa_> i still can't get mmc 8-bit to work +09:22 < wsa_> just to make sure: was there any verification of the HW that the pins are routed correctly? +09:24 < morimoto> now shimoda-san confirm it +09:25 < wsa_> confirm that it is routed correctly? +09:27 < morimoto> OK, it seems we have local patch. and it seems voltage issue +09:28 < morimoto> It seems it will goes to BSP. can you please it if BSP has it ? +09:29 < morimoto> (maybe it is good path ? BPS -> upport ) +09:29 < wsa_> can you mail me the local patch? +09:30 < shimoda> wsa_: i will send the patch to you later +09:31 < wsa_> thank you! +09:31 < wsa_> anything else left? +09:32 < shimoda> update from my side +09:32 < shimoda> @@ -69,6 +69,8 @@ HSUSB,?,noplan,shimoda,IPMMU issues +09:32 < shimoda> #USB3 Host +09:32 < shimoda> USB3Host,?,noplan,shimoda,suspend problems +09:32 < shimoda> #USBPHY +09:32 < shimoda> +USBPHY,v4.6,prototype,shimoda,add extcon support +09:32 < shimoda> +USBPHY,?,plan,shimoda,add OTG support +09:32 < shimoda> +09:32 < shimoda> ### Extra +09:32 < shimoda> Watchdog,v4.5,public,wolfram,upstream driver written for Gen3 BSP +09:33 < wsa_> ok, added to the list +09:33 < shimoda> thanks! +09:34 < shimoda> about OTG support, i intend to add it after OTG framework is changed +09:34 < wsa_> geertu: i could mark your SCIF-DMA task as "prototype"? +09:35 < geertu> It's working +09:35 < geertu> Nothing really to be done +09:35 < geertu> Perhaps the failures before were just a firmware issue? +09:35 < wsa_> so, "completed"? +09:35 < geertu> yes +09:35 < wsa_> \o/ +09:36 < geertu> For the (H)SCIF support, I have to resend the integration patches, now v4.5-rc1 has been released. +09:36 < geertu> I had to rebase, so it's now cooking in yesterday's renesas-drivers +09:36 < wsa_> +SCIF,v4.6,completed,geert,DMA support for Gen3 (worked out of the box) +09:37 < geertu> Please test renesas-drivers on silk, porter, lager, gose ;-) +09:38 < horms> i can do the last two, is there anything in particular I should look for? +09:38 < wsa_> i'll be away from my lager for 10 days +09:39 < horms> I think there is either a porter or silk in kernelci +09:39 < horms> and iirc team rel has a porter +09:39 < wsa_> will start my journey to FOSDEM later today +09:39 < horms> enjoy! +09:40 < shimoda> magnus-san got 2 porter boards, so i think we use the boards via remote in the future, i guess +09:41 < geertu> good, thx +09:41 < horms> excellent +09:42 < wsa_> so, that was it for today? +09:43 < horms> nothing more from me +09:43 < morimoto> ditto +09:43 < shimoda> nothing from me +09:44 < geertu> nothing for me +09:44 < wsa_> so, looking forward to see you soon! +09:44 < wsa_> have a safe travel +09:44 < morimoto> See you in Brussels ! +09:44 < shimoda> bye! +09:44 < geertu> CU soon! +09:44 < geertu> bye! +09:45 < wsa_> bye! +--- Log closed Wed Jan 27 09:46:09 2016 diff --git a/wiki/Chat_log/20160216-core-chatlog b/wiki/Chat_log/20160216-core-chatlog new file mode 100644 index 0000000..2634bf2 --- /dev/null +++ b/wiki/Chat_log/20160216-core-chatlog @@ -0,0 +1,195 @@ +Core-chat-meeting-2016-02-16 + +10:02 < geertu> I think we are complete (Magnus is excuted by paperwork^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hsed) +10:03 < horms> can we add a topic about ravb to the agenda if there is time? +10:03 < geertu> Sure +10:03 < horms> thanks +10:03 < geertu> ravb or gpio? ;-) +10:04 < geertu> Topic 1. Upcoming Gen3 development for the Core group +10:04 < horms> either way :) +10:04 < geertu> Magnus posted his INTC-EX series, and reposted CMT +10:05 < geertu> I got sucked into SYSC PM Domains agai +10:05 < geertu> s/agai/again/ +10:05 < geertu> as this became a blocker for media +10:06 < pinchartl> sorry about that :-) +10:06 < pinchartl> your patch series seems to work fine +10:06 < pinchartl> I can read the VSP version registers +10:06 < geertu> Great! +10:06 < morimoto> Great ! +10:06 < pinchartl> haven't been able to test video processing yet though (and thus haven't tested the FCP) due to an unrelated problem in the media controller core +10:07 < pinchartl> (I'll refrain from blaming Mauro) +10:07 < geertu> So the PM domains are working. +10:07 < pinchartl> (ah, wait, I did, damn :-)) +10:07 < pinchartl> at least for the VSP, yes +10:07 < geertu> Before it was tested by (not) crashing when turning off CPU cores ;) +10:07 < pinchartl> how do they interact with runtime PM btw ? the vsp1 driver doesn't support runtime PM, I assume that will make the power domain always on ? +10:08 < geertu> Interesting, then the PM domain shold be turned off +10:08 < geertu> What does /sys/kernel/debug/pm_genpd/pm_genpd_summary say? +10:08 < pinchartl> I'll tell you in a minute +10:10 < shimoda> i have a question about core/todo. it has the following todo, but I forget it :) +10:10 < pinchartl> let's go on with the rest of the topics in the meantime +10:10 < shimoda> SMP,v4.6,public,shimoda,Discuss SMP DT bindings with ARM SoC maintainers +10:12 < geertu> On which mailing list was this discussed? +10:13 < geertu> Ah, this is for Magnus' "[PATCH v3 00/09] ARM: shmobile: APMU DT support via SMP Enable method V3"? +10:14 < pinchartl> (recompiling with CONFIG_PM_DEBUG enabled) +10:15 < geertu> CONFIG_PM_ADVANCED_DEBUG=y +10:16 < shimoda> geertu: sorry I don't know.. This topic was discussed at 2015-12-01, but I don't have the weechat log... +10:17 < pinchartl> (recompiling with CONFIG_PM_ADVANCED_DEBUG enabled) +10:18 < geertu> Can't find it in my 2015-12-01.log +10:19 < horms> I have a log +10:20 < pinchartl> https://paste.kde.org/pwe40pq96 +10:20 < pinchartl> the power domain is on +10:20 < geertu> Cool, so it's indeed on if Runtime PM is not enabled in a driver, great +10:21 < pinchartl> I'll enable runtime PM anyway +10:22 < geertu> OK, thx +10:25 < horms> I don't see any discussion of SMP in my log of the 2015-12-01 meeting. But there is some discussion in the 2015-12-15 meeting. +10:27 < geertu> That involves PSCI for arm64. +10:27 < geertu> The task was for Gen2 +10:28 < horms> ok +10:28 < shimoda> thanks for the confirm +10:28 < geertu> Originally it was targeted for v4.3. +10:31 < geertu> I guess it's not super-urgent +10:31 < geertu> shimoda: will you handle this? +10:33 < shimoda> geertu: sorry i don't know about the detail. so, if possible, someone handles it. +10:34 < geertu> It's about the bindings in "[PATCH v3 01/09] devicetree: bindings: Renesas APMU and SMP Enable method" +10:35 < geertu> Personally, I don't think there's much to discuss. +10:35 < geertu> Magnus just doesn't like the enable-method ;-) +10:37 < geertu> Any other Upcoming Gen3 development for the Core group +10:37 < geertu> ? +10:37 < shimoda> geertu: thanks for the information, I will ask Magnus about it later F2F :) +10:37 < horms> Was any progress made on the dmaengine issues we discussed in Holsbeek? +10:38 < horms> Or is that a media topic? +10:38 < geertu> OK, he'll be in the office tomorrow, IIRC +10:38 < geertu> Vinod said he will accept the phys_addr_t patch +10:38 < neg> Vinod move forward with dma slave config so I will push forward there +10:38 < geertu> Not yet in his -next, though +10:38 < pinchartl> it's still good news +10:39 < pinchartl> neg: are you going to reply to his e-mail ? +10:39 < geertu> Definitely +10:39 < neg> pinchartl: yes +10:40 < pinchartl> thanks +10:40 < horms> ok so the status is: maybe good soon ? +10:41 < horms> were we waiting on Vinod for other changes too? +10:41 < neg> I'd say it looks good now that Vinod have accepted the approch +10:41 < horms> ok +10:41 < horms> Lets try and keep things going now the ball seems to be rolling in the right direction :) +10:42 < neg> will post a new seris today and hope he picks up on it +10:42 < horms> great +10:43 < neg> horms: question, should I keep including the DT updates or have you queued them up? +10:43 < horms> I have not queued them up; please keep including them +10:43 < neg> ok +10:44 < horms> I'd like to hold off on accepting them until the bindings are accepted. I take it that is not yet the case. +10:45 < neg> ofc, I was unsure you told me you tentative queued them up :) +10:45 < horms> oh, ok. +10:45 < horms> what were the patch subjects? +10:46 < neg> [PATCH v3 7/8] ARM: dts: r8a7790: add iommus to dmac0 and dmac1 +10:46 < neg> and I'm sorry you wrote deferred not tentative my bad +10:46 < horms> ok, at least we agree :) +10:47 < neg> other than that I hade a first go at the DMAC errta, got Laurents dmatest to work on gen2 but it fails for all channels on gen3 need to do more work there +10:47 < pinchartl> all channels ? nice :-) +10:48 < neg> I guess it's someting else that mess stuff up ;) +10:51 < shimoda> for gen3 no SYS-DMAC + IPMMU, I think we have to use magnus' patches +10:51 < shimoda> it is already into topic branch? +10:52 < pinchartl> in which power domains are the iommus ? +10:52 < geertu> topic/ipmmu-multi-arch-v1 +10:52 < geertu> topic/r8a7795-ipmmu-rfc +10:54 < neg> IIRC I did my initial test based on renesas-drivers-2016-02-09-v4.5-rc9 +10:54 < neg> s/rc9/rc3 +10:55 < shimoda> geertu: thanks for the info. +10:55 < neg> but I did not try as much as I wanted so I would like another go +10:57 < pinchartl> next topic ? or has everybody fallen asleep ? +10:58 < geertu> Topic 2. Status check for tasks from last meeting - what is remaining? +10:58 < horms> lets move on +10:58 < geertu> earlycon is in +10:58 < geertu> irqc ra7795 is half-completed, according to Magnus +10:59 < horms> is the rfc half ready or is the whole thing half way to being merged? +10:59 < geertu> pfc improve documentation is queued for pull request +10:59 * geertu checks chat with Magnus +11:00 < geertu> Remaining INTC-EX issue is the unknown parent clock, which Morimoto-san and Shimoda-san will check? +11:01 < horms> ok, sounds simple enough +11:01 < geertu> r8a7795 SYS-DMAC integration is queued by Simon +11:02 < morimoto> geertu: I got same request from Magnus +11:02 < geertu> r8a7795 Cache topology is halfway +11:02 < morimoto> I will ask it to HW guy tomorrow +11:02 < geertu> morimoto: I know ;-) +11:02 < geertu> morimoto: Thx! +11:03 < geertu> Any other task status updates? +11:03 < horms> l2c patches? +11:04 < horms> fwiw, they look good to me and i plan to merge them +11:04 < geertu> == r8a7795 (+ other :-) Cache topology +11:04 < geertu> thx +11:05 < horms> yes. not stricktly on topic +11:05 < shimoda> how about PFC,v4.6,plan,?,PFC 1.8v switching +11:05 < shimoda> ? +11:06 < geertu> That's not assigned yet. +11:07 < geertu> But if I'm not mistaken, Wolfram was going to look into it for his SDHI work? +11:08 < shimoda> i see, so I will ask Wolfram-san on next I/O meeting +11:10 < geertu> Simon: do you plan to queue the fixes for writing to .text for v4.5? +11:10 < horms> Yes +11:11 < geertu> OK, thx +11:11 < horms> I thought I did so this morning +11:11 < geertu> I think it's queued for v4.6 +11:11 < horms> oh ok +11:11 < horms> yes, that would be right +11:11 < horms> are they fixes for v4.5? +11:12 < geertu> Not having them will cause a crash on suspend as soon as Linus will merge rmk's branch for v4.6. +11:12 < geertu> Which may happen before arm-soc is merged. +11:12 < geertu> So I think it's safer to fast track them to v4.5. +11:13 < horms> ok, it seems that it wouldn't hurt to ask the ARM SoC maintainers +11:13 < horms> it would help me to make my case if i knew which patch(es) in RMK's branch you are referring to. +11:13 < geertu> BTW, you can already trigger the crash if you enable CONFIG_DEBUG_RODATA=y now +11:14 < geertu> That was in the cover letter +11:14 < horms> of course :) +11:14 < horms> i'll see about sending them to v4.5 +11:14 < geertu> 25362dc496edaf17f714c0fecd8b3eb79670207b +11:14 < geertu> ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA +11:15 < horms> I sent myself an email about it to read tomorrow morning +11:16 < geertu> OK, thanks +11:16 < geertu> Topic 3. RAVB / GPIO +11:17 < geertu> Waiting up to 110 more seconds for network. +11:17 < geertu> Seen in v4.5-rc3 and later +11:17 < pinchartl> could it be related to the nfsroot issues I'm seeing ? +11:18 < pinchartl> [ 65.247123] nfs: server 192.168.1.47 not responding, still trying +11:18 < pinchartl> [ 65.261947] nfs: server 192.168.1.47 OK +11:18 < horms> probably not +11:18 < horms> or at least that is a different manifestation +11:18 < geertu> Last week's renesas-drivers already had the RFC fix for rcar-gpio +11:18 < horms> i don't even get an address via DHCP +11:18 < geertu> The PHY interrupt doesn't come through because the rcar-gpio instance is suspended +11:19 < horms> right. so your patches address this. but I wonder if they have any chance of making it into v4.5. +11:19 < horms> If not I supose we have to live with broken ethernet +11:19 < geertu> Before v4.5-rc3, the PHY driver accidentally kept on polling. When that was fixed, it broke ravb on salvator-x +11:20 < geertu> Probably not a chance. +11:20 < horms> which i guess is better than living with no cpg as we did in v4.4 +11:20 < geertu> ;-) +11:20 < geertu> Does it work if you comment out the phy interrupt in the dts? +11:20 < horms> Ok, at least I'll have something to talk about in Tokyo next week +11:20 < geertu> (haven't tried myself, busy fixing bugs in -next) +11:20 < horms> I can try +11:23 < geertu> Lemme try myself +11:23 < horms> fwiw i'm trying +11:24 < geertu> works! +11:24 < horms> excellent +11:24 < horms> i guess we have found our work-around +11:24 < geertu> Yeah, DT describes the hardware ;-) +11:25 < geertu> Shall we add a quirk that removes the interrupt if present? +11:25 < geertu> Would be a good exercise to prepare for ESx.y DT fixups +11:25 < pinchartl> geertu: shall we fix the root cause ? :-) +11:26 < horms> i think we know the root cause +11:26 < geertu> In the Linux kernel, we never fix root causes ;-) +11:26 < horms> and i agree any work around should go into .c not dt +11:28 < geertu> We can get a workaround in v4.5-rc7 if needed, can't we? +11:28 < horms> we can try +11:30 < geertu> Should we stick a pm_runtime_get_sync() in rcar_gpio_probe() instead? +11:30 < geertu> That would help HDMI, too +11:31 < horms> its a posibility +11:31 < horms> do we expect HDMI to be effected: i.e. for it go go into mainline before the root cause is fixed? +11:32 < geertu> HDMI on Koelsch has been broken due to this for a while. +11:33 < horms> ok, then it does seem like a good idea from my armchair point of view +11:34 < geertu> OK, will go that way for today's renesas-drivers +11:34 < horms> great +11:34 < horms> Hopefully Florian reads your email before he spends any time on the problem +11:35 < geertu> ;-) +11:37 < pinchartl> anything else for today or can I have lunch ? +11:37 < geertu> I think we're finished +11:37 < geertu> Thanks for joining! diff --git a/wiki/Chat_log/20160223-io-chatlog b/wiki/Chat_log/20160223-io-chatlog new file mode 100644 index 0000000..b6c74ba --- /dev/null +++ b/wiki/Chat_log/20160223-io-chatlog @@ -0,0 +1,234 @@ +--- Log opened Tue Feb 23 08:56:22 2016 +08:56 -!- wsa_ [~wsa@79.226.92.116] has joined #periperi-io +08:56 -!- Irssi: #periperi-io: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal] +08:56 -!- Irssi: Join to #periperi-io was synced in 0 secs +09:00 -!- geertu [~geert@84.195.106.123] has joined #periperi-io +09:01 < geertu> Hi +09:01 <@horms> hi geertu +09:02 < wsa_> hi geert +09:02 < wsa_> hi simon +09:02 <@horms> hi wsa_ +09:03 -!- morimoto [~user@relprex1.renesas.com] has joined #periperi-io +09:03 < morimoto> Hi +09:03 < wsa_> hi morimoto-san +09:03 < morimoto> shimoda-san will be here +09:03 < morimoto> soon +09:04 < wsa_> good +09:04 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi-io +09:04 < shimoda> hi +09:04 < wsa_> hi shimoda-san +09:04 < shimoda> I'm sorry for late +09:05 < wsa_> no worries +09:05 < wsa_> but let's get started +09:05 < wsa_> any questions to the updates I did to the todo file? any further updates? +09:06 <@horms> none from my side +09:06 * geertu checks git +09:07 < wsa_> horms: I will apply your ARCH_RENESAS patch for I2C today or tomorrow +09:08 <@horms> thanks. I hope to roll out the remaining dozen or so patches for ARCH_RENESAS (not I2C!) soonish +09:08 < geertu> I think the SCIF tasks should be postponed to v4.7. +09:09 < geertu> For MSIOF, I tested the fix in the BSP, but it doesn't work for me. +09:09 < geertu> Perhaps it only works for other SPI modes than mode 0? +09:09 < geertu> The fix modifies some timing parameters. I have a deeper look with the logic analyzer to see if I can tune the parameters to make it work. +09:09 < wsa_> geertu: ok, moved SCIF tasks to v4.7 +09:10 < geertu> For SPI slave, I noticed something interesting on the mailing list. +09:11 < geertu> Apparently some devices have an SPI_READY pin, so the slave can indicate it's ready to provide data. +09:11 < wsa_> geertu: so, it is mode0 that doesn't work? does it work on gen2? +09:11 < geertu> msiof works on Koelsch with my test board (2 HC595 shift registers and LEDs) +09:12 < geertu> Cfr. the pictures in thread "r8a7795 SYS-DMAC issues (was: Re: [PATCH] [RFC] arm64: renesas: r8a7795: Complete SYS-DMAC nodes)" on periperi-ml +09:13 < geertu> I emailed the SPI_READY guy to ask for SPI slave hardware supporting this. He couldn't say more than it's "for automotive", and CCed our friend Dirk Behme. +09:13 < geertu> So perhaps I have found the requestor of the feature ;-) +09:14 < wsa_> :) +09:15 < wsa_> Nice detective work ;) +09:15 < geertu> I'll check with Dirk +09:15 < wsa_> so, i'll leave the MSIOF issues for 4.6 and wish you good luck +09:15 < geertu> Thx! ;-) +09:16 < wsa_> shimoda-san: any news on the USB side? +09:17 < shimoda> wsa_: today usb phy patch was merged to allow cpg driver of gen3 +09:17 < shimoda> so +09:17 < shimoda> so, i would like to send some integration patches. +09:18 < shimoda> however, for ehci ch 0 patch is "RFC", I will not send such patch. +09:18 < shimoda> horms: is it acceptable for v4.6? +09:18 <@horms> shimoda: if you are very quick +09:19 <@horms> I'd like to finalise my branches tomorrow +09:19 < shimoda> horms: i got it, i will try it today +09:20 < wsa_> great +09:20 < shimoda> and I have other topic from BSP team +09:20 < shimoda> they would like to support DRIF module for gen3 +09:21 <@horms> shimoda: thanks +09:21 < shimoda> and i got a datasheet of DRIF +09:21 < geertu> DRIF used to be in older versions of the datasheet +09:22 < shimoda> I heard REE/Phil is developing it +09:22 < geertu> It's "just" 2x MSIOF slave, right? +09:22 < geertu> Older R-CarH3_01_U12_DRIF_0010_e.doc says: +09:22 < geertu> "This LSI includes two sets of DRIF (Digital Radio Interface). Each of DRIF is composed of two MSIOF modules, which supports Slave Receive Mode only." +09:22 < geertu> But latest 0.5E datasheet has only some DRIF remainings (pfc/mstp/dmac) +09:23 < shimoda> on gen3 manual of DRIF, "This LSI includes four sets of DRIF" +09:25 < wsa_> Hmm, so is this basically the same as this task? +09:25 < wsa_> "SPI,2016-05-31,plan,geert,Implement initial SPI slave prototype support for R-Car Gen2" +09:25 < morimoto> geert: latest DRIF says +09:25 < wsa_> we haven't specified which SPI-core to use for that, have we? +09:25 < morimoto> +09:25 < morimoto> This LSI includes four sets of DRIF (Digital Radio Interface). Each of DRIF is composed by two sub modules. In this +09:25 < morimoto> module, S3D2φ is used as module clock, clock input from LSI is used as serial clock for reception. +09:25 < geertu> wsa_: MSIOF slave +09:26 < geertu> Yeah, besides working MSIOF slave, another difficulty may be in tying the two instances together +09:28 < geertu> Do we know what (dual SPI master) hardware is connected to DRIF? +09:28 < geertu> Can we get test hardware? +09:29 < wsa_> shimoda: so, the task looks to me to watch for Phil's DRIF patches and test them when they come along? +09:29 < shimoda> geertu: i will ask someone +09:30 < shimoda> wsa_: i think so if possible +09:30 < wsa_> shimoda: was there a deadline mentioned? +09:32 < shimoda> wsa_: i don't know, so I will ask bsp team +09:32 < geertu> FWIW, SPI (MSIOF) slave has 2016-05-31 +09:32 < wsa_> geertu: I'm inclined to assign this task to you? ;) +09:33 < geertu> Let's wait and see... +09:34 < wsa_> OK, so I added this task: +09:34 < wsa_> "DRIF,?,plan,?,Assist Phil in developing the driver" +09:34 < shimoda> wsa_: this task is good to me +09:35 < wsa_> morimoto: any news on the Gen3-Thermal driver? +09:35 < wsa_> shimoda: good +09:35 < morimoto> We will have meeting about that with RVC next month +09:35 < morimoto> (I think I can create this driver before that :) +09:36 < wsa_> :) +09:36 < wsa_> so, the deadline "2016-03-31" is still valid? +09:36 < morimoto> I think postpone is good for me +09:38 < wsa_> 2016-06-31? +09:38 < morimoto> good ! +09:38 < morimoto> And I think it will be RVC task +09:39 < wsa_> khim-san? +09:39 < morimoto> I think so +09:39 < wsa_> I was about to ask about him anyway +09:40 < wsa_> I assume you would ask on the periperi-list if khim-san needs additional tasks to be assigend? +09:40 < wsa_> Or how is it handled? +09:41 < morimoto> Umm +09:41 < morimoto> I don't know. Do we need track his task in periperi-list ? +09:43 < wsa_> Either him, or the person petting him :) +09:43 < wsa_> we will see +09:43 < wsa_> for now, I leave the thermal task to you, morimoto-san. OK? +09:43 < morimoto> OK. +09:43 < morimoto> I will report the result +09:44 < wsa_> thanks +09:46 < wsa_> shimoda, morimoto: can one of you ask about this strange bit in SDHI? +09:47 < wsa_> this thread on periperi: "[periperi] Q: ACC_REG in Gen2 SDHI Docs?" +09:47 < morimoto> OK, I can ask it to HW guys +09:48 < wsa_> and is my knowledge accurate that the next Gen3-BSP release is end of February? +09:48 < wsa_> morimoto: Thanks! +09:48 <@horms> wsa_: i expect to get an update on that on Friday +09:49 < wsa_> horms: urgent BSP release? +09:50 <@horms> wsa_: there is a BSP meeting on friday. I expect the timing of the forthcoming releases to be discussed there. +09:51 < wsa_> ah, okay +09:51 < wsa_> horms: can you post the result for the next release on periperi? +09:52 <@horms> sure +09:52 < wsa_> thanks +09:52 <@horms> be aware that there are internal and external releases +09:53 <@horms> its the external ones that go in kernel.org, to customers, etc... +09:53 < wsa_> i am interested in the next update I can have access to +09:53 <@horms> understood +09:53 <@horms> me too! +09:53 < wsa_> :D +09:54 < shimoda> wsa_: next Gen3 BSP release is end of March +09:54 <@horms> I can see the internal ones, but its not so interesting afik +09:54 < wsa_> end of march, okay thanks +09:54 < wsa_> I ask because I couldn't get 8-bit eMMC to work +09:55 < wsa_> it is planned for the next BSP, so I wanted to check if there is some gory detail i am missing +09:55 < wsa_> shimoda-san kindly sent me some patches but the gory detail was not in there +09:55 < wsa_> so I was interested in building the BSP and check if/how it works +09:56 < wsa_> that's the full story +09:56 < shimoda> wsa_: thanks for the full story +09:57 < shimoda> I have internal patch set of the current internal bsp +09:57 < wsa_> one more info from my side: i have now access to the Coverity-reports for the upstream kernel. I tried some patterns finding renesas-specific files and there were some hits. +09:58 < wsa_> i'll investigate if they are not false positives and fix them along if there are not too many +09:58 < wsa_> if there is a bunch, it may be worth to make a task out of it +09:59 < wsa_> but we can discuss that later +09:59 < wsa_> that's all from my side +09:59 < wsa_> are we done? +09:59 < geertu> I have another question +10:00 < geertu> Anyone who knows what's the rationale behind the private review of the CANFD driver? +10:00 <@horms> not i +10:01 < morimoto> I don't know background, but Munakata-san and REE had meeting about it +10:01 < morimoto> and it seems it was REE's challenge +10:01 < morimoto> REE want to send it to ML +10:01 < geertu> Good ;-) +10:01 < morimoto> but they want private review as 1st step +10:02 < morimoto> So, we need to tell him to send it to ML :) +10:02 < wsa_> wearing my maintainer's hat, I appreciate if companies do the first rounds of review internally :) +10:02 < morimoto> :) +10:03 < wsa_> looks like we are done now +10:03 < geertu> wsa_: And wearing your company-internal hat? ;-) +10:04 < wsa_> geertu: that hat tells me it is benefitial to be nice to maintainers :D +10:06 < wsa_> and, it looks more professional to have proper patches sent out +10:06 < wsa_> and the first version really had some way to go +10:06 < wsa_> OK, let's call it a day +10:06 < wsa_> thank you guys! +10:06 < morimoto> thanks +10:07 < shimoda> thank you! +10:07 < morimoto> wsa_: I would like to confirm +10:07 < geertu> thx +10:07 < geertu> bye +10:07 < morimoto> bye +10:07 < morimoto> wsa_: about your question about SDHI +10:07 < wsa_> yes +10:08 < morimoto> Are you checking sh_mobile_sdhi_sdbuf_width() ?? +10:08 < morimoto> I'm missing point +10:09 < wsa_> yes, i mean this function +10:09 < wsa_> for version 0x490c, it always uses 0x0001 for 32-bit +10:10 < morimoto> yes +10:10 < wsa_> now, this document for channels 0+1 +10:10 < wsa_> R8A7790(R-CarH2) SD Host Interface CH0,CH1 Hardware Manual(V00R01E).pdf +10:10 < wsa_> chapter 1.2.23 +10:11 < morimoto> verion = 0x490c = CH2,3 +10:11 < wsa_> 0: 32-bit access +10:11 < wsa_> and in 1.2.22 +10:11 < morimoto> for CH0,1 ? +10:11 < wsa_> 16’h490C +10:12 < morimoto> ? +10:12 < wsa_> the filename of the document says channel 0+1, yes +10:12 < wsa_> shall i send you the document I am referring to? +10:13 < wsa_> (i got this from the renesas-ftp once) +10:13 < morimoto> please wait +10:14 < morimoto> ver = 0x490c = CH2,3 = 0: 16bit, 1:32bit +10:14 < morimoto> ver = 0xCB0D = CH0,1 = 0: 32bit, 1:16bit +10:15 < morimoto> Is this correct for you? +10:16 < wsa_> that would be nice +10:16 < wsa_> so, the document i have has an error? +10:17 < morimoto> does you document is not same as above ? +10:17 < wsa_> because it says in 1.2.22 initial value is "16’h490C" +10:17 < morimoto> if so, your document was wrong version +10:18 < morimoto> I ping-pong:ed this with SDHI guys before +10:18 < morimoto> (I forgot detail...) +10:18 < wsa_> can i have access to the latest version? +10:18 < morimoto> What is your document version ? +10:18 < morimoto> I have is +10:19 < morimoto> CH2,3 = V00R03E +10:19 < wsa_> i have this +10:19 < wsa_> R8A7790(R-CarH2) SD Host Interface CH0,CH1 Hardware Manual(V00R01E).pdf +10:19 < morimoto> CH0,1 = V00R05E +10:19 < morimoto> oops, too old :) +10:19 < wsa_> and R8A7790(R-CarH2) SD Host Interface CH2,CH3 Hardware Manual(V00R01E).pdf +10:20 < wsa_> yes, looks like it :) +10:20 < morimoto> OK, we now find the bug :) +10:20 < morimoto> I wounder how did you get it ? +10:20 < morimoto> Ah, from FTP +10:20 < wsa_> i was SO hoping for a documentation error :) +10:21 <@horms> I think I'll depart now unless there is anything more (non SDHI) to discuss +10:21 < morimoto> Oops, sorry Simon +10:22 < morimoto> Yes, IO meeting was finished I think +10:22 <@horms> No problem +10:22 -!- horms [~horms@reginn.isobedori.kobe.vergenet.net] has left #periperi-io ["Leaving"] +10:22 < morimoto> OK, I will ask to Jinso to send latest SDHI version to you +10:22 < wsa_> thanks! +10:22 < morimoto> was_: do you think your issue will be solved by it ? +10:22 < morimoto> s/was_/wsa_/ +10:23 < wsa_> yes, I will add comments to the upstream driver to make things clear +10:23 < wsa_> luckily, no code changes are needed +10:23 < morimoto> I hope so :) +10:23 < morimoto> Thank you for your hard work +10:24 < morimoto> I will ask it tomorrow. (because of time-zone issue :) +10:24 < wsa_> very welcome +10:24 < morimoto> OK, thanks. bye +10:24 < wsa_> thanks for all your assistance +10:24 < wsa_> tommorow is fine, cya! +10:25 < shimoda> bye! +10:26 -!- shimoda [~shimoda@relprex1.renesas.com] has quit Quit: WeeChat 0.4.2 +10:27 -!- Irssi: #periperi-io: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal] +--- Log closed Tue Feb 23 10:27:25 2016 diff --git a/wiki/Chat_log/20160301-core-chatlog b/wiki/Chat_log/20160301-core-chatlog new file mode 100644 index 0000000..62ab441 --- /dev/null +++ b/wiki/Chat_log/20160301-core-chatlog @@ -0,0 +1,164 @@ +Core-chat-meeting-2016-03-01 + +10:01 < geertu> Hi all +10:02 < geertu> Welcome to the wonderful world of Renesas Core SoC development +10:02 < geertu> All set, Shimoda-san and Mr. Magnus are excused. +10:02 < geertu> Agenda: +10:02 < geertu> 1. Upcoming Gen3 development for the Core group, +10:02 < geertu> 2. Status check for tasks from last meeting - what is remaining? +10:02 < geertu> Topic 1. Upcoming Gen3 development for the Core group +10:03 < morimoto> Hi +10:03 < pinchartl> before we start, I'll have to leave in an hour, I'm sorry aobut that +10:03 < pinchartl> so if there are topics you would like to keep secret for me, the last half hour of the meeting is the right time to discuss them +10:04 < geertu> OK, we'll discuss the secret SH4 pwower area at the end fo the meeting ;-) +10:05 < pinchartl> :-) +10:05 < geertu> I'm working on massaging the SYSC power domain driver into shape +10:05 < geertu> s/SYSC/R-Car SYSC/ +10:06 < pinchartl> thank you for that +10:06 < pinchartl> it's a dependency for upstreaming VSP and FCP support on H3 +10:06 < geertu> horms: I assume (new) drivers/soc/renesas/ will go to arm-soc via your tree? +10:07 < horms> I would assume it needs to not go via arm-soc. Can we arrange so either you or I send it directly to Linus? +10:07 < geertu> Well... +10:08 < horms> ok, perhaps i take that back +10:08 < geertu> For SYSC power domains, there will be a hard dependency of the DT part on the driver part. +10:08 < geertu> I think it's easier to order if both do to arm-soc via you. +10:08 < geertu> s/do/go/ +10:09 < horms> sure, in that case it makes perfect sense +10:09 < horms> to do as you suggest +10:10 < geertu> Sorry, it seems I'm always the one who creates patch series with complex dependencies +10:10 < horms> Thanks for dealing with the complexity :) +10:10 < geertu> That's it from my side for now +10:11 < pinchartl> not much to report on my side +10:11 < geertu> Sorry, forgot one thing. +10:11 < pinchartl> I'll review Niklas' DMA patches as I already mentioned +10:12 < horms> From my side I need to get on to analusing IPMMU as Magnus requested in Lueven. +10:12 < geertu> There are three pull-request from me waiting for action (pfc and clk) +10:12 < neg> I would like to have a bit more to do for core. There is not much happening whith slave IOMMU+DMAC and not mutch to do with the DMAC erratas since the IPMMU issues on Gen3. Still need to check DMADAR setup on Gen3 however. +10:12 < horms> Are we stuck on Vinod for DMAE again? I.e. what Magnus was worring about in Holsbeek? +10:13 < geertu> horms: Vinod took the improtant patch +10:13 < horms> superb! +10:14 < geertu> neg: Anything in core/todo you're interested in? +10:16 < pinchartl> neg: if you're bored there's something useful that could be done for IPMMU with Gen2 +10:16 < pinchartl> although it might be difficult +10:16 < pinchartl> the datasheet mentions two register banks +10:16 < pinchartl> for secure/non-secure modes +10:17 < pinchartl> and we don't really know how they work +10:17 * horms needs to change locations. I'll leave this client running and check the scrollback in about 5min when I get to the other end. Sorry about this, time got away from me. +10:17 < neg> geertu: I do not understand all bullets but I would love to do some small PM or clock stuff to learn more +10:17 < pinchartl> I tried booting H2 and M2 in both secure and non-secure mode (but might have failed doing so) and it didn't make a difference from an IPMMU driver point of view +10:18 < pinchartl> understanding what's going on would be useful, I expect it will come and bite us back at the worst possible moment +10:19 < neg> I could look at that +10:20 < pinchartl> it's just an idea, if there's anything more important/interresting feel free to ignore me :-) +10:20 < neg> But I would also like something that could give me a patch to put in my next report :) +10:20 < geertu> neg: r8a779[0-4],v4.6,plan,?,Start adding dmas pointing to all SYS-DMAC engines +10:21 < geertu> neg: lots of patches :-) +10:21 < neg> geertu: sounds good :) +10:23 < neg> I can also have a go at the secure/non-secure IPMMU modes and see if I can understand them +10:26 -!- horms_ [~horms@penelope-musen.kanocho.kobe.vergenet.net] has joined #periperi +10:28 < horms_> I'm on the other side now. +10:30 < geertu> Dark side of the force? +10:31 < morimoto> geertu: Quick question +10:31 < morimoto> BSP team want to have PFC "Driving Ability" and "Pull UP" feature. Are these under control ? +10:31 < horms_> geertu: yes! +10:33 < geertu> PFC,v4.6,plan,ulrich,add r8a7795 bias support +10:33 < geertu> There's no task for "Driving Ability" yet. +10:34 < geertu> Any status update? +10:34 < morimoto> No, but BSP team want to have it +10:34 < morimoto> Not urgent, but +10:34 < geertu> uli___: ? +10:35 < uli___> no update there +10:36 < morimoto> OK, thanks. No stress +10:36 < geertu> neg: https://lists.vergenet.net/private/periperi/2015-September/000784.html provides context for that task +10:37 < geertu> Added PFC,v4.7,plan,?,add r8a7795 drive-strength support +10:37 < geertu> Any takers? +10:38 < geertu> Seems we forgot to add that task at PeriPeriCon +10:38 < pinchartl> I'll see if I can give it a go +10:38 < geertu> OK, thx +10:38 < neg> geertu: thanks +10:39 < geertu> Let's hope people don't step in each other's toes with 1.8v, bias, and drive strength +10:39 < geertu> s/in/on/ +10:41 < pinchartl> I might need help testing it thought +10:41 < pinchartl> s/thought/though/ +10:42 < pinchartl> as I'll try to submit a patch set for the 17th of March +10:42 < pinchartl> but will leave for Linaro Connect this Friday and will likely not take any Renesas board with me +10:44 < pinchartl> this leads me to the next topic I wanted to discuss +10:45 < pinchartl> I'll be at Connect next week. there will be quite a few ARM core developers there, is there anything I should bring up with them ? +10:46 < geertu> Not from my side +10:49 < geertu> Anyone else with topics for LC? +10:50 < pinchartl> I already plan to try and talk to Arnd about the dma mapping API +10:50 < horms_> not at this moment, the interaction with the ARM SoC maintainers is going pretty smoothly at this time +10:50 < neg> speak well of my {map,unmap}_resource :) +10:50 < horms_> If I met Arnd or Olof I'd ask them what they'd like us to be doing that we aren't doing +10:50 < geertu> I don't think Vinod will be there, will he? +10:52 < pinchartl> horms_: I'll try to do that +10:52 < pinchartl> geertu: not that I know of +10:54 < horms_> pinchartl: thanks +10:54 < geertu> morimoto: Laurent and I have a question about r8a7795 +10:54 < geertu> morimoto: Does it have SH4, or not? +10:55 < pinchartl> horms_: you're welcome +10:55 < geertu> morimoto: It has mostly disappeared from the datasheet in 0.5 (but e.g. RT-DMAC is still there) +10:55 < pinchartl> morimoto: and does it have an A3SH power domain ? +10:56 < pinchartl> geertu: even if the SH4 is still there, could we leave the A3SH power domain out for now, or do you consider that blocking for your SYSC patch series on H3 ? +10:57 < geertu> pinchartl: We can leave it out. The SH4 is not in DT, and A3SH would be in C (or not) after the rework. +10:57 < pinchartl> sounds good to me +10:58 < morimoto> geertu: about SH4, it seems option. But we don't know what does this "option" mean +10:59 < geertu> morimoto: And you cannot check for its presence in the Product Register (PRR), as that contains ARM cores only (CA57/CA53/CR7) +10:59 < geertu> pinchartl: I'm also wondering if the SH4 got disabled by the firmware update we did at PeriPeriCon. +11:00 < pinchartl> geertu: good question +11:01 < geertu> pinchartl: Anyway, you have to leave now, right? +11:01 < morimoto> geertu: do you need to use it ? +11:01 < pinchartl> geertu: yes, sorry about that +11:01 < geertu> morimoto: No, we don't need to use it. +11:02 < pinchartl> morimoto: we don't, but while testing Geert's SYSC patch series, I found out the system would freeze due to the driver trying to disable the A3SH power domain +11:02 < pinchartl> geertu: could be useful to check the boot loader sources to see if it touches that power domain +11:02 < geertu> morimoto: But Laurent found out the A3VC power area (which he needs for multimedia) fails to power up if the A3SH power area was touched before. +11:03 < morimoto> Hmm... So you want to know detail of it to HW team ? +11:03 < geertu> morimoto: yes please +11:04 * pinchartl is gone +11:04 < pinchartl> have a nice day/evening +11:04 < geertu> thx, bye! +11:06 < morimoto> geertu: can you please send me detail mail about that ? It can help me to ask HW team +11:07 < geertu> morimoto: Sure, I'll send an email to you +11:07 < morimoto> thank you +11:08 < geertu> Topic 2. Status check for tasks from last meeting - what is remaining? +11:09 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list +11:09 < geertu> I did some updates yesterday, cfr. the invitation email +11:10 < geertu> Any other updates? +11:11 < geertu> I guess I can start postponing unfinished tasks for v4.6 to v4.7? +11:11 < neg> I don't have much to tell since last meeting, no feedback yet on slave IOMMU+DMAC and running tests on DMAC errata +11:14 < morimoto> geertu: does upstream already have "Reset" ? +11:15 < geertu> morimoto: No, AFAIK no work has been done on that +11:15 < morimoto> OK, thanks +11:15 < horms_> geertu: anything for my tree should be moved to v4.7 +11:15 < geertu> morimoto: Is this system reset (reboot)? +11:15 < morimoto> I think so +11:16 < geertu> Perhaps Wolfram's watchdog timer works for that (perhaps UP only)? +11:16 < geertu> I don't know he has tried on H3 +11:17 < morimoto> geertu: OK thanks +11:19 < geertu> Anything else to report +11:19 < geertu> Anything else to report? +11:19 < morimoto> nothing from me +11:19 < horms_> nor me +11:19 < geertu> Sorry, one more thing from me. +11:20 < geertu> It seems shmobile_defconfig now always triggers the (RCU related?) lock-up on Koelsch. +11:21 < horms_> using which branch/tag ? +11:21 < geertu> It may not (always) happen with Simon's tree, but as soon as you add more stuff from -next it fails. +11:21 < geertu> Today's renesas-drivers (to be released soon) +11:21 < horms_> ok +11:22 < horms_> sounds painful +11:23 < geertu> It doesn't happen with my usual config, which has more debugging options. +11:23 < geertu> Wolfram saw it, too, on Lager +11:23 < neg> I can test it on my koelsch once you release renesas-drivers +11:24 < horms_> I guess its a bit tricky to bisect if its not always reliably triggered +11:25 < geertu> I bisected it to an innocent RCU change +11:25 < geertu> Reverting that did fix the issue +11:25 < horms_> Ok, but is it the root cause, or just uncovering a deeper problem? +11:25 < geertu> But it shouldn't. +11:26 < geertu> Magnus thinks it's an issue with our timers. +11:26 < horms_> He usually deos :) +11:27 < geertu> If it would happen relibably on kzm9g, I could use JTAG +11:30 < horms_> Ok, it sounds like we need some more data +11:30 < horms_> I'll also try testing renesas-drivers on my Koelsch (and other boards) +11:31 < horms_> I need to depart shortly. Was there anything more to discuss? +11:31 < geertu> No, we're finished. +11:32 < geertu> Thanks for joining! diff --git a/wiki/Chat_log/20160314-io-chatlog b/wiki/Chat_log/20160314-io-chatlog new file mode 100644 index 0000000..d3c20ad --- /dev/null +++ b/wiki/Chat_log/20160314-io-chatlog @@ -0,0 +1,146 @@ +--- Log opened Mon Mar 14 08:55:30 2016 +08:55 -!- wsa_ [~wsa@p4FE25CE7.dip0.t-ipconnect.de] has joined #periperi-io +08:55 -!- Irssi: #periperi-io: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal] +08:55 -!- Irssi: Join to #periperi-io was synced in 1 secs +08:56 <@horms> hi wsa_ +08:59 < wsa_> hi simon +08:59 <@horms> how are things? +09:02 < wsa_> windy :D +09:02 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi-io +09:03 < wsa_> lots of things are changing currently +09:03 < wsa_> this is nothing bad per se, but needs lot of attention +09:03 <@horms> good luck :) +09:03 -!- geertu [~geert@d54c36a7b.access.telenet.be] has joined #periperi-io +09:03 < wsa_> thanks! +09:03 < wsa_> hello shimoda-san +09:04 < shimoda> hello wolfram-san +09:04 < geertu> (sorry, i was in the wrong channel) +09:06 < wsa_> geertu: no worries, i'll be in both channels and point to this one if necessary +09:06 -!- morimoto [~user@relprex1.renesas.com] has joined #periperi-io +09:06 < morimoto> Hi +09:07 <@horms> Hi Morimoto-san, hi Geert +09:07 < geertu> {Mor,Eve}nin' again ;-) +09:08 < wsa_> Hi Morimoto-san +09:08 < wsa_> so, we are all here +09:08 < wsa_> let's start +09:09 < wsa_> looking at the patches in renesas-soc, I didn't see much updates to the todo. +09:09 < wsa_> Please update me if I missed something +09:09 < geertu> MSIOF,v4.6,plan,geert,Investigate issues on Gen3 => complete +09:10 < wsa_> I wonder though, if we should add some tasks which are happening but haven't been formalized yet? +09:10 < wsa_> like the review support for the CAN driver? +09:11 < wsa_> or the DMA support for ravb (by Kaneko-san)? +09:11 < wsa_> opinions on this? +09:11 <@horms> Kaneko-san's work is covered by tasks in the upporting portion of the wiki etc... +09:11 < geertu> IMHO review is part of the job +09:11 <@horms> I don't object to you adding tasks too, but just so you know that I am tracking his work +09:12 < wsa_> ok, so this is considered upporting because it comes from the BSP. fair enough +09:12 <@horms> I would be more inclined to add a can task and assign it to whoever is working on it, even if they are outside the group. But I have no strong opinions here +09:13 <@horms> wsa_: yes, its coming from the bsp. obviously it also overlaps with this group +09:14 < wsa_> geertu: that was a HW issue with MSIOF, right? +09:14 < geertu> I aree it's a good idea to add can dev to the task list +09:14 <@horms> on the subject of can: i think we should at some point discuss if we want to merge r8a779[34] support even though no board exposes the hw +09:14 < geertu> wsa_: yes +09:14 < geertu> wsa_: and bsp workaround is not sufficient +09:15 < wsa_> horms: that would be applying untested patches to the dtsi? +09:15 <@horms> wsa_: yes +09:16 <@horms> as it stands i have posted the (untested) patches +09:16 < wsa_> i am not strong on this one, but i don't like +09:16 <@horms> so they exist in the archives and people can fish them out +09:16 < wsa_> that's great +09:16 <@horms> i'm inclined to leave them in that state until we can test them: probably forever +09:17 < wsa_> or someone else can test them +09:17 <@horms> right +09:17 * wsa_ stops daydreaming +09:17 < wsa_> so what do you envision for the CAN task? +09:17 <@horms> the other alternative is to merge them. someone can still test them in future. but they may also assume they have already been tested which is (likely) false +09:18 <@horms> well, the above discussion asside. i see two areas of real can work going on +09:18 <@horms> supporting can on r8a7795. and supporting canfd +09:18 < geertu> I guess we already have many device nodes that haven't been tested? +09:18 <@horms> yes, that is the other side of the coin +09:19 <@horms> perhaps not many but surely there are some +09:19 < geertu> Like SCIFs, MSIOFs, MMCs? +09:19 <@horms> perhaps some that we can more reasonably expect to be tested than others +09:19 <@horms> right +09:20 < geertu> At least we try to review additions to .dtsi +09:20 < geertu> which is harder for e.g. all the pinctrl data. +09:20 <@horms> yes, i agree there +09:20 < geertu> (not the pins, but the bits in registers) +09:20 < wsa_> isn't adding r8a7795 support an integration task? +09:21 <@horms> in general the changes are based on similar nodes that are known to work. e.g. for another soc which is documented to work the same way. or other ports on the same soc that are documented to work the same way +09:21 < wsa_> canfd is surely an io task +09:21 <@horms> seems pretty io to me :) +09:22 < wsa_> as a maintainer, I hardly accept untested patches +09:22 <@horms> As far as I can tell Ramesh hopes to get his work merged soon. He was asking me privately about merging his dtsi changes recently +09:22 < geertu> horms: Indeed. Following that logic, adding can nodes for r8a779[34] should be OK +09:22 < wsa_> but I encourage people to send them nonetheless +09:23 < wsa_> which is exactly what happened here +09:23 < wsa_> :) +09:23 <@horms> geertu: yes, i agree with that line of thinking. to be honest i could flip a coin on this one +09:24 < wsa_> morimoto: any news about khim-san? +09:24 < geertu> khim-san = khiem-san? +09:24 < wsa_> oh, sorry +09:24 <@horms> wsa_: there is an argument to be made that the dtsi nodes document the hw. we can see the pdf documentation but most people can't +09:24 < shimoda> wsa_: about thermal or power management things? +09:24 < wsa_> thermal +09:25 < wsa_> there was this idea that he should do the H3 thermal driver? +09:26 < shimoda> morimoto-san and I have a F2F meeting in 25th March. so, we have no update about thermal +09:27 < wsa_> ok, i'll just wait then until you have some news about the task +09:27 < wsa_> until then it keeps assigned to morimoto-san +09:27 < shimoda> thanks +09:28 < wsa_> shimoda: we have the I2C DMA task scheduled for 2016-05-31. Is the date still up-to-date? +09:29 < shimoda> this date is related to the bsp schedule. and i guess it can be changed at 2016-06-30 because +09:30 < shimoda> the bsp schedule is changed :) +09:30 < wsa_> i will do that +09:31 < shimoda> thanks +09:31 < wsa_> i also updated your extcon entry, just saw the public patches: +09:31 < wsa_> USBPHY,v4.7,public,shimoda,add extcon support +09:32 < shimoda> wsa_: yes +09:33 < shimoda> and i will also try to make a prototype of OTG (actually role-swithing) support in this month. +09:33 < wsa_> cool +09:34 < wsa_> I dunno if this makes sense, but IMO this patch could be pointed to the BSP team: +09:34 < wsa_> [PATCH 06/10] mmc: tmio: stop clock when 0Hz is requested +09:34 < wsa_> I couldn't find anything like this in the Gen2/3 BSP +09:35 < wsa_> and it really makes a difference for me. Without, I can't access SanDisk and Samsung cards in UHS modes +09:35 < shimoda> thank you! i will forward this information to the BSP team +09:35 < wsa_> (I have to admit I didn't build the Gen2-BSP kernel yet to actually check) +09:36 < shimoda> wsa_: ahh, if gen3, i guess you should change the DRV value for some UHS cards +09:37 < wsa_> so far, UHS support is Gen2 only +09:37 < wsa_> Gen3 is missing DMA still. But this will be next. +09:37 < wsa_> but I'll keep that in mind! +09:38 < shimoda> wsa_: i see about UHS support. +09:38 < shimoda> about gen3 DMA. I found a hw issue :) +09:39 < wsa_> uh +09:39 < shimoda> i will send an email about the detail to periperi later +09:39 < wsa_> ok +09:39 < wsa_> thanks +09:40 < shimoda> oops, "gen3 DMA" means just SDHI-DMAC, not sys-dmac +09:40 < wsa_> i am definately interested in that one ;) +09:40 < wsa_> so, that's all the points I have +09:40 < wsa_> any more news from your side? +09:41 < morimoto> nothing from Renesas +09:41 < geertu> Not really. Just working with my good ol' friend SCIF again. +09:42 < wsa_> geertu: FIFO or flow control? +09:43 < geertu> wsa_: I'm starting wuith flow control. Will continue with FIFO/ +09:44 < wsa_> ok +09:45 < geertu> wsa_: The former implies DT binding updates, so better do that early. +09:45 < wsa_> yes +09:45 < wsa_> let's call it done then +09:46 < wsa_> thanks guys! +09:46 <@horms> thanks! +09:46 < shimoda> thank you! +09:46 < morimoto> wsa_: 1 question. +09:46 < wsa_> sure +09:47 < morimoto> Do you want invite khiem-san to chat meeting ? +09:47 < morimoto> (not #periperi, but #periperi-io or #renesas-something) +09:48 < wsa_> if he does io-related work, sure +09:48 < morimoto> OK, thanks +09:48 <@horms> fwiw I registered #renesas-soc +09:48 < morimoto> horms: cool ! thanks +09:48 <@horms> feel free to use it as you see fit +09:49 < morimoto> Thanks! +09:49 < morimoto> Thank you IO chat meeting. see you +09:50 -!- morimoto [~user@relprex1.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +09:50 < geertu> bye +09:50 -!- geertu [~geert@d54c36a7b.access.telenet.be] has left #periperi-io [] +09:52 -!- shimoda [~shimoda@relprex2.renesas.com] has quit Quit: WeeChat 0.4.2 +--- Log closed Mon Mar 14 09:56:31 2016 diff --git a/wiki/Chat_log/20160315-core-chatlog b/wiki/Chat_log/20160315-core-chatlog new file mode 100644 index 0000000..70768e3 --- /dev/null +++ b/wiki/Chat_log/20160315-core-chatlog @@ -0,0 +1,328 @@ +Core-chat-meeting-2016-03-15 + +2016-03-15 18:00:36 --> shimoda (~shimoda@relprex1.renesas.com) has joined #periperi +2016-03-15 18:00:36 -- Topic for #periperi is "marzen lock holder = none / managed in-channel rather than in-topic" +2016-03-15 18:00:36 -- Topic set by geertu on Thu, 01 Oct 2015 23:19:22 +2016-03-15 18:00:36 -- Nicks #periperi: [dammsan geertu morimoto mturquette narmstrong_ neg pinchart1 shimoda uli___] +2016-03-15 18:00:36 -- Channel #periperi: 9 nicks (0 ops, 0 voices, 9 normals) +2016-03-15 18:00:39 -- Mode #periperi [+cnt] +2016-03-15 18:00:39 -- Channel created on Wed, 08 Jul 2015 19:41:24 +2016-03-15 18:02:11 geertu Welcome to the Core Group Chat +2016-03-15 18:03:06 geertu Let's answer Magnus' question first +2016-03-15 18:03:09 geertu Magnus: What is current state and next step of the IPMMU + SYS-DMAC framework bits? +2016-03-15 18:03:31 geertu Vinod merged the patch to use phys_addr_t instead of dma_addr_t +2016-03-15 18:03:41 geertu So everything's on track again +2016-03-15 18:03:47 geertu No need to escalate +2016-03-15 18:04:04 neg sort of +2016-03-15 18:04:06 geertu dammsan: Does that answer your question? +2016-03-15 18:04:32 dammsan geertu: sort of, but i got the impression that more framework changes are needed... +2016-03-15 18:04:51 dammsan thanks for helping out to get that piece of the puzzle worked out though +2016-03-15 18:05:46 dammsan i think a first nice goal could be to get IPMMU + SYS-DMAC working on R-Car Gen2 +2016-03-15 18:06:16 dammsan i'd love to kill off my dirty workaround patch =) +2016-03-15 18:06:41 neg Now the isse have hit its next roadblock where the idea seems to be something new/else is needed then the dmamapping api since the assumtion there is that it's backed by a physical page +2016-03-15 18:09:25 neg I'm talking with Christoph Hellwig but have yet to figure out a good way forward +2016-03-15 18:11:00 dammsan thanks +2016-03-15 18:12:31 --> horms (~horms@penelope-musen.kanocho.kobe.vergenet.net) has joined #periperi +2016-03-15 18:12:39 <-- horms (~horms@penelope-musen.kanocho.kobe.vergenet.net) has left #periperi +2016-03-15 18:12:39 neg I was hoping pinchart1 would review the series to put some weight behind it. He prommised he look at it last core meeting +2016-03-15 18:13:05 --> horms (~horms@penelope-musen.kanocho.kobe.vergenet.net) has joined #periperi +2016-03-15 18:13:10 geertu Welcome Simon +2016-03-15 18:13:17 horms sorry to be late (again!) +2016-03-15 18:13:57 horms The Gen2 documentation is too exciting for me to take my eyes off it! +2016-03-15 18:14:17 dammsan neg: so the case w/o IPMMU, we currently assume we do not need to map anything? +2016-03-15 18:14:58 dammsan i'm trying to understand what is so special about our situation =) +2016-03-15 18:15:34 geertu Yeah, the x86 and PPC guys have used IOMMUs for ages +2016-03-15 18:15:40 neg yes w/o a IPMMU the dma_addr_t is the same as phys_addr_t +2016-03-15 18:15:51 geertu x86 IO is always special, but PPC should be similar +2016-03-15 18:17:08 dammsan so we need to use the DMA API for this i guess +2016-03-15 18:17:23 dammsan and no one else is doing that in a similar way i wonder? +2016-03-15 18:17:47 dammsan stuck between DMA Engine and DMA API =) +2016-03-15 18:19:53 dammsan so pinchartl is not attending? +2016-03-15 18:20:03 geertu No, he's without network access today +2016-03-15 18:20:13 horms i believe he is at linaro connect +2016-03-15 18:20:24 geertu LC was last week, IIRC +2016-03-15 18:20:28 horms ok +2016-03-15 18:20:34 dammsan meh +2016-03-15 18:20:42 horms in that case hopefully is is not at lc (any more!) +2016-03-15 18:21:27 dammsan ok i guess we are blocked on him +2016-03-15 18:21:49 dammsan shall we move to next? +2016-03-15 18:21:51 neg not that I know of and there have been patches from Robin Murphy where he talk about toying with the same solution see http://article.gmane.org/gmane.linux.kernel.renesas-soc/404 +2016-03-15 18:22:44 geertu Topic 1. Upcoming Gen3 development for the Core group +2016-03-15 18:24:02 geertu I posted a v3 of the PM Domain patch series last week, switching from a DT hierarchy to a C hierarchy again +2016-03-15 18:24:08 geertu s/again// +2016-03-15 18:24:11 geertu ;-) +2016-03-15 18:24:16 dammsan hehe +2016-03-15 18:24:35 horms shimoda-san: I'm wondering about PWM. Is it on your-list, done, or should I be looking at it? +2016-03-15 18:24:38 geertu There are some details to resolve w.r.t. SH4 power areas +2016-03-15 18:25:02 geertu After that I'll repost a v4. +2016-03-15 18:25:13 horms :) +2016-03-15 18:25:38 horms geertu: are you waiting on me for anything (e.g. to queue up any of your patches that are ready)? +2016-03-15 18:25:42 geertu I have a few more cleanups in the pipeline for SoC-specific PM code under arch/arm/mach-shmobile/, those depend on DT PM Domains +2016-03-15 18:25:47 geertu horms: Not yet +2016-03-15 18:26:05 horms ok +2016-03-15 18:26:23 geertu The code is in today's renesas-drivers, so it can be used by VSP users +2016-03-15 18:26:48 geertu (and it was in an integration topic branch last week) +2016-03-15 18:27:16 dammsan geertu: with the power domains, how do you work together with PSCI? +2016-03-15 18:27:40 dammsan just assume the firmware are handling the cpu power domains? +2016-03-15 18:27:52 geertu dammsan: The CPU power areas cannot be controlled from SYC for Gen2 and Gen3 +2016-03-15 18:28:02 geertu That's done through APMU. +2016-03-15 18:28:08 geertu On Gen2 the C code does that +2016-03-15 18:28:15 geertu On Gen3 PSCI does that +2016-03-15 18:28:43 geertu However, the SYSC status bits don't indicate that the CPU power areas are powered down after CPU hot-unplug on Gen3 +2016-03-15 18:29:03 horms Is that a bug or a feature? +2016-03-15 18:29:06 shimoda simon-san: sorry for the delayed response. about PWM integration for r8a7795, it seems ulrich-san sent upporting patches to the ML +2016-03-15 18:29:11 geertu Replugging the CPU doesn't work on Salvator-X, perhaps related to the above. +2016-03-15 18:29:42 horms shimoda-san: thanks, got it. I suppose we need to prod him a bit. +2016-03-15 18:30:09 dammsan geertu: how about the snoop controller, i guess on gen2 it needs manual setup +2016-03-15 18:30:17 geertu The link with controlling the Linux-view on the CPU PM Domains is not there. Lina Iyer is working on generic CPU PM Domain stuff +2016-03-15 18:30:18 horms geert: ok, so this is related to a thread with morimoto-san on the periperi ML? +2016-03-15 18:30:50 geertu dammsan: You mean the SCU power area? +2016-03-15 18:30:55 dammsan yeah +2016-03-15 18:31:07 dammsan psci is assumed to be in control i guess +2016-03-15 18:31:15 geertu dammsan: It's already running when booting Linux +2016-03-15 18:31:36 geertu and we never power down the first CPU core. +2016-03-15 18:31:51 dammsan good. on gen2 it depended on boot loader version and if it the cores were booted in big or little mode +2016-03-15 18:31:52 geertu H2 also doesn't have big.LITTLE enabled. +2016-03-15 18:32:13 geertu There are no changes to CPU bring-up introduced by my series. +2016-03-15 18:32:30 dammsan you csure, just curious about the assumptions +2016-03-15 18:32:31 geertu The later cleanups have, and I have it running locally with your old APMU DT series. +2016-03-15 18:32:40 dammsan ouch =) +2016-03-15 18:33:07 geertu horms: Yes, discussing SH4 on various SoCs with Morimoto-san +2016-03-15 18:33:48 dammsan so who is handling the non-working SMP CPU Hotplug bits? +2016-03-15 18:34:07 geertu I sent an email to periperi about it last week. +2016-03-15 18:34:08 dammsan hate to ask =) +2016-03-15 18:34:23 geertu Secondary core bringup works once +2016-03-15 18:34:37 geertu So after boot you have 4 x CA57 +2016-03-15 18:34:51 geertu If you power down a Ca57, you loose it forever (until next reboot) +2016-03-15 18:35:17 geertu It seems India has a newer firmware? +2016-03-15 18:35:28 dammsan of course it is up to you guys how you want to roll +2016-03-15 18:35:29 geertu No idea if that helps. Firmware is black box to us ;-) +2016-03-15 18:35:40 dammsan i would not merge any code unless it is working myself +2016-03-15 18:36:07 horms is the code in question merged or not? +2016-03-15 18:36:10 geertu There is no new non-working SMP code added. +2016-03-15 18:36:38 dammsan is SMP including or excluding CPU Hotplug in your view? =) +2016-03-15 18:36:51 dammsan it my mind CPU Hotplug is the only sane test bed for SMP =) +2016-03-15 18:37:00 geertu Then it is broken. +2016-03-15 18:37:03 dammsan otherwise how would you test power down? +2016-03-15 18:37:13 dammsan ok +2016-03-15 18:37:17 geertu It broke when adding the secondary CPU cores to DT, with enable-method = "psci" +2016-03-15 18:37:19 dammsan so how can we fix this? +2016-03-15 18:37:29 geertu Fix PSCI? +2016-03-15 18:37:30 dammsan yes i assumed so +2016-03-15 18:37:42 dammsan well, we need to fix it somehow +2016-03-15 18:37:54 dammsan the rest of the organization is busy flippin burgers +2016-03-15 18:37:55 geertu Who's developing PSCI? +2016-03-15 18:38:18 dammsan i don't know to be sure +2016-03-15 18:38:21 horms we can remove the dt nodes pending a working psci implementation +2016-03-15 18:38:28 dammsan but i would check before i merged it if i had the chance +2016-03-15 18:38:39 dammsan that would be my preferred way forward +2016-03-15 18:38:44 dammsan not sure what you guys are thinking +2016-03-15 18:39:02 geertu Well, adding the CPU nodes to DT did allow to use them after booting. +2016-03-15 18:39:03 shimoda geertu: bootloader team develops the psci (arm-trasted-firmware) for gen3 +2016-03-15 18:39:35 dammsan geertu: then we have same support level as emev2 =) +2016-03-15 18:39:36 shimoda it is a problem that i also don't know the detail of the psci firmware versioning +2016-03-15 18:40:00 dammsan i propose that we don't enable upstream until we have something working +2016-03-15 18:40:12 dammsan and put pressure on local people based on that +2016-03-15 18:40:26 geertu In this case, the "something" was 4 running CPU cores. +2016-03-15 18:40:27 dammsan i'm open to other suggestions though +2016-03-15 18:40:37 shimoda i heard end of this month, a new version of the firmware released on the git hub +2016-03-15 18:40:43 shimoda public git hub +2016-03-15 18:40:44 geertu Actually we had 8 running, but it broke by upgrading firmware. +2016-03-15 18:40:47 horms can i clarify if we are talking about 1) code that is already merged 2) code that posted but not merged or 3) code that is neither posted nor merged? +2016-03-15 18:41:00 geertu 1 = 4 x CA57 +2016-03-15 18:41:05 geertu 2 = 8 x CA57 +2016-03-15 18:41:10 geertu 3 = PSCI ;-) +2016-03-15 18:41:25 geertu s/8x CA57/4 x CA57 + 4 x CA53/ +2016-03-15 18:41:54 dammsan you can see that the release procedure of binaries is working well +2016-03-15 18:42:04 dammsan at least we can generate some entropy +2016-03-15 18:42:14 dammsan =) +2016-03-15 18:42:21 dammsan so what shall we do? +2016-03-15 18:43:36 geertu In the kernel, we revert something if it causes regressions. +2016-03-15 18:43:54 shimoda I heard the current psci blocks CA53, however if we changes the boot mode we can use 8 core as the cpu0 as CA53 :) +2016-03-15 18:43:58 dammsan this did not cause a regression really, but CPU hotplug did not work +2016-03-15 18:43:59 geertu With firmware, it's more complicated +2016-03-15 18:44:39 dammsan i think on 32-bit arm it became possible to block cpu hotplug at some point i think +2016-03-15 18:44:47 horms does it cause a regression in the sense that reset no longer works? +2016-03-15 18:44:51 geertu dammsan: Actually I do not know if CPU hotplug worked with the previous firmware. I never tried unplug/replug +2016-03-15 18:45:06 dammsan same here +2016-03-15 18:45:19 dammsan but previous firmware version does not matter really +2016-03-15 18:45:24 dammsan it is too early to care +2016-03-15 18:45:27 dammsan imo +2016-03-15 18:45:29 geertu Reset doesn't work. We don't have reboot support. +2016-03-15 18:45:56 dammsan but ordering wise, getting SMP and CPU hotplug working before system reset is one option +2016-03-15 18:46:05 dammsan we can also change things around +2016-03-15 18:46:29 dammsan i like that we test stuff before we merge though +2016-03-15 18:47:00 horms ok, so perhaps its not a regression. but with the current firmware - which is all we support - SMP does not function as required because hotplug is broken. Correct? +2016-03-15 18:47:23 geertu Correct. +2016-03-15 18:47:33 horms If so it was an error (by me) to add the extra CPU nodes to DT. And I think we should revert the change until we have a good solution. +2016-03-15 18:47:43 geertu dammsan: It was tested by checking if we have 4 CPU cores running after bootup. +2016-03-15 18:48:03 dammsan right. next time please check with me that have been doing this for a while =) +2016-03-15 18:48:16 horms The main down side is that Dirk @ Bosch will not be happy. But the code is still around if he wants to use it locally. +2016-03-15 18:49:04 dammsan but he cant be the main motivator for us moving forward, can he? +2016-03-15 18:49:29 dammsan must be more important to feed back issues to renesas and get them to fix the PSCI firmware +2016-03-15 18:49:49 dammsan ideally satisfy both +2016-03-15 18:49:52 geertu What has the biggest use case: habing 4 CPU cores running? Or being able to unplug and replug CPU cores after boot up? +2016-03-15 18:50:00 horms He posted the patch. It was reviewed and accepted. Subsequently an issue came up. I think we should move on. +2016-03-15 18:50:20 geertu Indeed. +2016-03-15 18:51:27 dammsan i guess it depends on what our role is +2016-03-15 18:51:40 dammsan just being integrator and push issues different ways +2016-03-15 18:51:56 dammsan or try to tackle technical issues a bit more +2016-03-15 18:52:04 dammsan i prefer to focus on the technical bits +2016-03-15 18:52:10 dammsan but sure, lets move on +2016-03-15 18:52:54 horms sure, we could have done a better job on this one. +2016-03-15 18:53:41 dammsan no biggie, lets just fix it +2016-03-15 18:53:49 horms agreed +2016-03-15 18:55:08 dammsan shimoda: morimoto: can we report to renesas about PSCI failure somehow? +2016-03-15 18:55:26 dammsan and then we need to push hard +2016-03-15 18:55:38 shimoda dammsan: sure, i will ask bsp team or/and bootloader team about it +2016-03-15 18:55:38 dammsan we hinted a couple of times already +2016-03-15 18:55:44 dammsan thanks! +2016-03-15 18:56:21 dammsan imagine hypervisors and virtualization on top of this swiss cheese =) +2016-03-15 18:56:32 dammsan so it is good to push a bit more +2016-03-15 18:57:10 dammsan geertu: can you include boot loader version in the commit log for the power domain bits? +2016-03-15 18:57:27 geertu dammsan: Sure +2016-03-15 18:57:29 dammsan (you may have already) +2016-03-15 18:57:30 geertu v230 +2016-03-15 18:57:30 dammsan thanks +2016-03-15 18:57:49 dammsan excellent +2016-03-15 18:59:02 dammsan horms: is it possible to get information from the bosch guy about his environment and if cpu hotplug is working for him? +2016-03-15 18:59:30 dammsan or maybe that is too detailed +2016-03-15 19:00:07 dammsan horms: sorry for being slow, but what was the plan forward with the SMP and CPU Hotplug? Revert or wait for new firmware version? +2016-03-15 19:00:29 dammsan im ok with anything +2016-03-15 19:00:36 dammsan we just need to make sure it becomes better +2016-03-15 19:00:57 horms dammsan: sure, i will try and get that information from Dirk +2016-03-15 19:01:09 geertu Making it better implies not reverting basic SMP support... +2016-03-15 19:01:12 horms my plan, which I am happy to change is as follows: +2016-03-15 19:01:22 dammsan geertu: that is fine with me +2016-03-15 19:01:26 dammsan as long as we can fix it +2016-03-15 19:01:32 dammsan _somehow_ +2016-03-15 19:01:34 horms 1. post patch to revert the patch that added the extra cpu nodes to dt. +2016-03-15 19:01:51 horms 2. queue it up for v4.6 and possibly v4.5-stable after suitable discussion on the ML +2016-03-15 19:02:17 horms 3. discuss internally how a working psci implementation can be achieved +2016-03-15 19:02:34 dammsan seems like a lot of work to me +2016-03-15 19:02:53 horms how so? +2016-03-15 19:03:06 geertu What about skipping steps 1 and 2? +2016-03-15 19:03:13 dammsan like geert said, it does not really help anything for people just booting +2016-03-15 19:03:39 horms personally i am comfortable with skipping 1 and 2 +2016-03-15 19:04:13 dammsan i dont think 1 and 2 helps us much at this point +2016-03-15 19:04:32 dammsan but i think despite that we need to agree about a plan how to improve things +2016-03-15 19:05:06 dammsan can we get some jinso members to test for us? +2016-03-15 19:05:58 horms fwiw i just tested it on my board +2016-03-15 19:06:09 horms which i suppose has the same fw revision as geert +2016-03-15 19:06:20 horms we can ask dirk if he has seen hotplug working +2016-03-15 19:06:30 horms and if we are lucky he may have a firmware version that works +2016-03-15 19:06:47 dammsan we can perhaps use dirk to put customer pressure at renesas =) +2016-03-15 19:06:53 horms which is information that might help the firmware developers to make it work in a future version +2016-03-15 19:06:58 horms right +2016-03-15 19:07:02 horms its clearly important to dirk +2016-03-15 19:07:17 horms and dirk's employer is important to renesas (I imagine) +2016-03-15 19:07:18 shimoda dammsan: of cause we can get some jinso members to test +2016-03-15 19:07:19 geertu Given he added the CA53 nodes too, he's probably still using the older firmware +2016-03-15 19:07:36 dammsan shimoda: it may be good to make a test case that can be reused on new SoCs +2016-03-15 19:08:20 horms fwiw, this is my test case so far: +2016-03-15 19:08:36 horms # echo 0 > /sys/bus/cpu/devices/cpu1/online +2016-03-15 19:08:37 horms [ 42.358400] CPU1: shutdown +2016-03-15 19:08:37 horms [ 42.359758] psci: CPU1 killed. +2016-03-15 19:08:37 horms # cat /sys/bus/cpu/devices/cpu1/online +2016-03-15 19:08:37 horms 0 +2016-03-15 19:08:37 horms # echo 1 > /sys/bus/cpu/devices/cpu1/online +2016-03-15 19:08:39 horms [ 47.870239] CPU1: failed to come online +2016-03-15 19:08:41 horms -bash: echo: write error: Input/output error +2016-03-15 19:08:48 geertu Yep, that's it +2016-03-15 19:09:09 dammsan i used to run these in a tight loop to test some older platforms +2016-03-15 19:09:16 geertu Note that renesas-bsp/v4.2/rcar-3.0.x:arch/arm64/boot/dts/renesas/r8a7795.dtsi also has 8 CPU cores, with enable-method = "psci" +2016-03-15 19:09:44 dammsan "tick-box: SMP working" +2016-03-15 19:09:45 shimoda horms: thank you for the detail, i will ask bsp team or someone +2016-03-15 19:10:21 horms ok, so far we seem to have: +2016-03-15 19:10:26 horms * collect information from Dirk +2016-03-15 19:10:27 geertu FWIW, the same sequence was in my email "CPU hotplug on Salvator-X" +2016-03-15 19:10:33 horms * Get Jinso to test (their board?) +2016-03-15 19:10:45 horms * Talk with Renesas about how important this is +2016-03-15 19:11:49 shimoda geertu: oops, i missed your email... +2016-03-15 19:12:42 dammsan geertu: thanks for pushing +2016-03-15 19:12:53 dammsan horms: sounds good to me +2016-03-15 19:13:49 horms Ok, i can talk to Dirk unless someone else wishes to. Perhaps Shimoda-san could take the other two items for now? +2016-03-15 19:14:44 shimoda horms: yes, i will ask jinso and bsp team about 2 items +2016-03-15 19:15:01 horms excellent +2016-03-15 19:15:28 horms feel free to pass the Jinso guys on to me if you feel the need +2016-03-15 19:17:43 shimoda horms: thanks +2016-03-15 19:19:04 geertu Any other core things people are working on? +2016-03-15 19:19:23 dammsan Trying to get the CMT DT bits over the edge +2016-03-15 19:19:39 dammsan but thats about it +2016-03-15 19:19:59 horms I have made a little progress on the dmac/bus mastering/32-bit+ support analysis as requested by Magnus in Lueven +2016-03-15 19:20:30 horms Hopefully it will be complete enough to circulate something soon +2016-03-15 19:20:57 dammsan thanks +2016-03-15 19:21:00 neg going to post v2 of dmas pointing to all SYS-DMAC engines after this meeting +2016-03-15 19:21:19 horms in a nutshell so far things seem very similar in gen3 to that of gen2 +2016-03-15 19:21:19 neg geertu: is it OK for me to add your Ack to the DT patch for i2c[6-8] on r8a7793 in this series? This patch was needed after rebasing on top of renesas-devel-20160315-v4.5 as you stated it would. +2016-03-15 19:21:58 geertu neg: if the patch is correct, yes ;-) +2016-03-15 19:22:26 geertu neg: Just email me the new hunk, and I'll have a look +2016-03-15 19:22:51 neg ok +2016-03-15 19:24:28 dammsan geertu: i'm also poking around with the gen3 ipmmu +2016-03-15 19:24:30 geertu dammsan: BTW, I wanted to include your v2 of ipmmu-multi-arch in today;s renesas-drivers, but r8a7795-ipmmu-rfc no longer applies +2016-03-15 19:24:45 dammsan geertu: thanks, yeah i know +2016-03-15 19:24:56 dammsan i will make a new version of the r8a7795 patches +2016-03-15 19:25:22 geertu dammsan: the CMT series didn't include the driver changes? +2016-03-15 19:25:24 dammsan you gave me some feedback about bitfields and features, anything you feel strongly about? +2016-03-15 19:25:32 dammsan geertu: that is correct +2016-03-15 19:25:39 geertu dammsan: I think that was Laurent. +2016-03-15 19:25:42 dammsan thought we would agree on DT bindigns first +2016-03-15 19:25:54 geertu dammsan: you can also use a plain int or long. and ffs() and ffz() +2016-03-15 19:26:39 geertu dammsan: OK, but you remove properties. Shouldn't that be done afer the driver supports the new stuff? +2016-03-15 19:26:41 dammsan geertu: unless laurent is using your email address it was you =) +2016-03-15 19:27:02 dammsan geertu: let me check +2016-03-15 19:28:02 dammsan geertu: i believe i only remove stuff that is unused +2016-03-15 19:28:21 geertu ok +2016-03-15 19:28:26 dammsan regarding the compat strings at least +2016-03-15 19:28:53 geertu Anyway, I'm still running with your previous version of the CMT series, so consider it tested +2016-03-15 19:30:07 geertu Topic 2. Status check for tasks from last meeting - what is remaining? +2016-03-15 19:30:27 dammsan geertu: thanks +2016-03-15 19:31:23 dammsan eventually i need to get to r8a7795 CMT +2016-03-15 19:31:46 dammsan not sure about other people +2016-03-15 19:32:42 geertu Any plan about SMP,v4.6,public,magnus,Discuss SMP DT bindings with ARM SoC maintainers +2016-03-15 19:33:04 dammsan not so much i'm afraid +2016-03-15 19:33:48 dammsan perhaps that is not a battle i can win +2016-03-15 19:34:35 shimoda no progress about "Investigate SYS-DMAC2" of my task, i'm afraid +2016-03-15 19:35:04 horms dammsan: in that case perhaps we should consider a fall back position? +2016-03-15 19:36:26 dammsan horms: sure +2016-03-15 19:37:01 geertu enable-method = "renesas,apmu" is working fine here (and on remote Lager) +2016-03-15 19:37:42 dammsan it is not so much a techincal problem, more that DT is used to describe software (PSCI) and overly verbose when not needed +2016-03-15 19:38:23 geertu That happens when you put critical functionality in firmware +2016-03-15 19:38:28 dammsan and we need to keep our existing support for some time instead of breaking DT ABI with non-enable method +2016-03-15 19:38:53 geertu Actually I have an idea to handle backwards-compatbility there. +2016-03-15 19:39:16 dammsan good, why dont you implement it? +2016-03-15 19:39:24 geertu All we have to do is match on r8a779x, add apmu device nodes, and enable-method properties, right? +2016-03-15 19:39:34 geertu dammsan: Time time time... +2016-03-15 19:39:46 dammsan yeah i know +2016-03-15 19:39:48 geertu it's on my list... +2016-03-15 19:40:03 dammsan in my mind we dont need the enable-method at all +2016-03-15 19:40:13 dammsan since we can use the apmu nodes by themselves +2016-03-15 19:40:29 geertu True. +2016-03-15 19:40:29 dammsan but that seems to the the "standard way" to do things +2016-03-15 19:40:35 geertu But the PSCI fans don't have PSCI nodes +2016-03-15 19:40:38 dammsan and thats what i wanted to discuss +2016-03-15 19:40:42 dammsan right +2016-03-15 19:40:50 geertu I'm afraid it's already too late for that +2016-03-15 19:41:02 dammsan regarding PSCI for sure +2016-03-15 19:41:15 dammsan but i wonder how it helps us to change the DT ABI? +2016-03-15 19:41:25 dammsan seems like no big win with the enable method +2016-03-15 19:41:31 dammsan i can see the point of the APMU bits +2016-03-15 19:42:12 dammsan anyway, it is possible to do something +2016-03-15 19:42:18 dammsan but feels like rather low priority IMO +2016-03-15 19:42:33 dammsan it is along there with the JTAG SMP support =) +2016-03-15 19:42:56 geertu That has a real use case ;-) +2016-03-15 19:43:02 dammsan also question is how to handle APMU on Gen3 +2016-03-15 19:43:05 dammsan the hardware is there +2016-03-15 19:43:14 dammsan just not accessible perhaps +2016-03-15 19:44:10 geertu Hidden behind the PSCI curtain +2016-03-15 19:44:28 dammsan it is supposed to be hidden at least =) +2016-03-15 19:45:00 dammsan ParaSiteComputerInterface +2016-03-15 19:45:20 geertu Anything else to discuss (without a beer/wine/cocktail)? +2016-03-15 19:45:32 dammsan not from me +2016-03-15 19:46:56 shimoda not from me +2016-03-15 19:47:13 geertu ok +2016-03-15 19:47:17 geertu thx for joining! +2016-03-15 19:47:19 geertu bye! +2016-03-15 19:47:24 neg thanks bye +2016-03-15 19:47:34 shimoda thanks! bye! +2016-03-15 19:47:45 dammsan thanks diff --git a/wiki/Chat_log/20160322-mm-chatlog b/wiki/Chat_log/20160322-mm-chatlog new file mode 100644 index 0000000..321be0a --- /dev/null +++ b/wiki/Chat_log/20160322-mm-chatlog @@ -0,0 +1,513 @@ +Multimedia-chat-meeting-2016-03-22 + +<pinchartl> hello [16:55] +<morimoto> Hi +<neg> morning +<pinchartl> let's give Ulrich and Magnus a few more minutes to join [16:57] +<pinchartl> or maybe they're here already ? +<pinchartl> dammsan: hello +<pinchartl> uli___: hello +<morimoto> I couldn't get any response from Magnus during today [16:58] +<morimoto> Maybe he is super busy +<pinchartl> let me try to ping him [16:59] +<dammsan> hi [17:00] +<dammsan> sorry for being late +<pinchartl> hello ! +<pinchartl> no worries +<dammsan> i have more details for the questions +<pinchartl> let's get started [17:01] +<pinchartl> topics for today +<pinchartl> - tasks status update +<pinchartl> - VSP questions from Magnus +<pinchartl> - next meeting / ELC +<pinchartl> anything else ? +<dammsan> nope, not from me +<pinchartl> ok [17:02] +<morimoto> I sent request mail +<pinchartl> morimoto: about vsp suspend/resume ? +<morimoto> Yes, and I would like to 100% for v4.5 on peripelist :) +<pinchartl> good point [17:03] +<morimoto> Ahh, and from BSP +<morimoto> - request API (delayed) +<pinchartl> 4. How will the 50% contract affect development +<morimoto> - plane-alpha, pixel-alp +<pinchartl> added to the agenda [17:05] +<pinchartl> let's get started then +<morimoto> thanks +<pinchartl> let's try to be quick on the tasks status update +<pinchartl> I'll try to handle it per developer this time [17:06] +<pinchartl> ADV7482,v4.7,plan,niklas,Prototype on Gen3 +<pinchartl> ADV7482,v4.8,plan,niklas,Gen3 support upstream +<pinchartl> ADV7482,v4.8,plan,niklas,Interlace support upstream +<pinchartl> VIN+CSI2,v4.7,noplan,niklas,Prototype on Gen3 +<pinchartl> VIN+CSI2,v4.8,noplan,niklas,Gen3 support upstream +<pinchartl> VIN+CSI2,v4.8,noplan,niklas,Interlace support upstream +<pinchartl> VIN,v4.8,noplan,niklas,Gen3 support upstream (without CSI-2) +<pinchartl> neg: what's your status ? +<morimoto> ? noplan ? [17:07] +<neg> Bit of downtime since last meeting waiting for new contract. Working on + VIN+adv7180 hope to be done with VIN for gen2 before ELC +<pinchartl> morimoto: I think we have a plan, that's a mistake [17:08] +<morimoto> OK thanks +<pinchartl> neg: what's left to be done for VIN+ADV7180 ? +<neg> minior shuffeling of code between files per review comments and extra + check for NV16 alignment, nothing big [17:09] +<pinchartl> so you think the next version will be merged ? [17:10] +<neg> yes +<pinchartl> ok +<pinchartl> I'll add a task for that in the list +<neg> thanks +<pinchartl> VIN,v4.7,public,niklas,New VIN driver without soc-camera (tested + on Gen2) [17:11] +<neg> But I was wondering if we should try to get the false gen3 support out + of soc_camera +<pinchartl> we can, it's just a simple patch [17:12] +<pinchartl> does the above schedule still holds for you ? [17:13] +<neg> depending on if I can get the same ammount of time for multimedia as + before, yes [17:14] +<dammsan> neg: you will, but the time may come in boosts +<dammsan> lets discuss more f2f at ELC [17:15] +<pinchartl> let's discuss that as part of topic 3 +<pinchartl> then we have +<pinchartl> - DU+HDMI,v4.7,plan,ulrich,HDMI output on Gen3 prototype +<pinchartl> - DU+HDMI,v4.8,plan,ulrich,HDMI output on Gen3 upstream +<pinchartl> - DU+HDMI,v4.7,prototype,ulrich,Test setup with HDMI output to + HDMI input loopback (without EDID) +<pinchartl> - DU+HDMI,v4.7,public,ulrich,EDID generation support for the HDMI + loopback test setup +<pinchartl> - VIN,v4.7,public,ulrich,Add DV timings support to rcar-vin +<pinchartl> - VIN,v4.7,public,ulrich,Upstream Lager HDMI input bug fixes +<pinchartl> Ulrich isn't here to update us on the status +<dammsan> also +<pinchartl> I'll ask him to do so by e-mail in a reply to the meeting report +<dammsan> my feeling is that we may want a HDMI video out prototype for Gen3 + earlier [17:16] +<dammsan> if possible +<pinchartl> earlier than v4.7 ? +<dammsan> well, the earlier the better =) +<dammsan> since it is a prototype it does not need to be aligned to upstream + schedule +<dammsan> perhaps something for ulrich to focus on sometime soon if possible + [17:17] +<pinchartl> ok +<pinchartl> I'll write it down +<dammsan> othanks!! +<pinchartl> then [17:18] +<pinchartl> HDMI+sound+output,2016-03-31,plan,morimoto,Prototype on Gen3 +<pinchartl> HDMI+sound+output,2016-03-31,plan,morimoto,Upstream support + without hotplug on Gen2 +<pinchartl> HDMI+sound+output,2016-06-30,plan,morimoto,Hotplug support + upstream +<pinchartl> RSND,2016-06-30,plan,morimoto,Hotplug support upstream on Gen3 +<pinchartl> morimoto: that's for you +<morimoto> I have no update for these +<morimoto> I think I need +3 month for these ? [17:19] +<pinchartl> should we try to align that with upstream kernel versions then ? +<pinchartl> instead of dates +<morimoto> I don't care details :) [17:20] +<pinchartl> we should still set milestones [17:21] +<morimoto> I means version vs date +<pinchartl> just +3 months for all four tasks then ? [17:22] +<morimoto> Because these are based on HDMI+output [17:23] +<morimoto> and not yet supported ? +<pinchartl> correct +<pinchartl> ok, I've recorded that [17:24] +<pinchartl> next +<pinchartl> - VIN,v4.7,plan,magnus,Investigate if/how parallel VIN can be used + on Salvator-X +<dammsan> i did figure that out +<dammsan> it is possible +<dammsan> but we decided to go with it as backup in case CSI gets too hairy +<pinchartl> I'll remove the task then as investigation is done [17:25] +<dammsan> good thanks +<pinchartl> DU+VSPD,2016-03-31,plan,laurent,Z-order support prototype [17:26] +<pinchartl> DU+VSPD,v4.7,plan,laurent,Z-order support upstream +<pinchartl> VSP,v4.8,public,laurent,V4L2 request API upstream +<pinchartl> VSP,v4.7,public,laurent,CLU/LUT support submitted upstream on Gen3 +<pinchartl> VSP,v4.7,prototype,laurent,HGO support upstream on Gen3 +<pinchartl> the plan for z-order support still holds, I'll try to complete it + this week [17:27] +<pinchartl> regarding the request API, I'll try to post the next version + before ELC [17:28] +<pinchartl> as I'll present it in my ELC talk :-) +<morimoto> thanks! +<morimoto> do you have Display-List plan ? [17:29] +<pinchartl> display list support is upstream [17:30] +<morimoto> already do you mean ? +<pinchartl> yes +<morimoto> thanks ! +<pinchartl> it has been merged in Linus' tree +<pinchartl> there are still enhancements that will be merged in v4.7 +<pinchartl> I couldn't get everything upstreamed in one go +<pinchartl> there shouldn't be any delay, the code is ready +<dammsan> how about request API status? [17:31] +<dammsan> is it ready to go, or shall we expect more updates? +<pinchartl> as you probably know I've had a bit of a conflictual relationship + lately with the V4L2 maintainer [17:32] +<pinchartl> it resulted in delays +<dammsan> sure, that's fine +<pinchartl> Mauro said he wouldn't merge (and didn't even review) any media + controller patch before his rework could be merged +<dammsan> internal renesas guys needed to make some workaround to use the + request API in your latest code +<pinchartl> and we're still handling the fallout +<pinchartl> so there will be a new version of the request API +<pinchartl> I hope to post it before ELC [17:33] +<dammsan> can you make sure we can consume it in renesas-drivers? +<pinchartl> I will +<dammsan> thanks. +<morimoto> pinchartl: can you add "Display-List" with "complete" status ? +<morimoto> s/complete/merged/ [17:34] +<morimoto> we would like to know when it was merged +<pinchartl> yes +<morimoto> thanks +<pinchartl> done +<pinchartl> next, [17:35] +<pinchartl> - DU,?,noplan,?,HDMI output support on Alt +<pinchartl> - DU,?,noplan,?,LVDS output support on Gose +<pinchartl> - DU,?,noplan,?,LVDS output support on Alt +<pinchartl> - FDP,2016,noplan,?,Upstream driver +<pinchartl> we still have no plan +<pinchartl> although, for FDP, I have someone who could start working on it + right after ELC +<pinchartl> but we'll need to sort out the budget +<dammsan> the Gen2 DU bits can be slow going IMO, not very important ones +<morimoto> pinchartl: can you send his cost ? I send this mail before to you + [17:36] +<morimoto> s/send/sent/ +<pinchartl> morimoto: sure. I'll reply to your e-mail +<morimoto> thanks +<pinchartl> ok, that's it for the tasks status update [17:38] +<pinchartl> topic 2 - VSP development +<pinchartl> Magnus mentioned that +<pinchartl> 1) request API is not working. +<pinchartl> 2) multiple input is not working. +<pinchartl> 3) UDS (both scale up/down) is not correct result. +<pinchartl> and Morimoto-san, that suspend/resume crashes +<pinchartl> is there anything else ? [17:39] +<dammsan> no, those are the ones i know about +<pinchartl> it's enough for me :-) +<dammsan> i bet =) +<morimoto> hehe :) +<pinchartl> do you have more information about 2 and 3 ? +<dammsan> can we begin by 1) ? [17:40] +<dammsan> we covered it already perhaps +<dammsan> but there is some patch on some internal mail thread to fix + something +<pinchartl> I think we did. there will be a new version for ELC +<pinchartl> now you're being very precise :-D +<pinchartl> could you send them my way ? +<dammsan> morimoto: can you make sure pinchartl: gets the patch related to + request API? +<morimoto> OK, will try [17:41] +<pinchartl> thanks [17:42] +<dammsan> morimoto: please hook up to me via google chat if you need details +<dammsan> pinchartl: while morimoto digs through his email, can we move to 2? +<pinchartl> yes +<pinchartl> do you have more information about 2 and 3 ? [17:43] +<dammsan> yes [17:44] +<dammsan> apparently RPF -> BRU -> WPF is working [17:45] +<dammsan> however in case RPF.1 is connected to BRU.1 there is trouble +<pinchartl> RPF.0 -> BRU.0 + RPF.1 -> BRU.1 ? +<dammsan> sink->source [17:46] +<dammsan> is filled somehow +<pinchartl> it used to work, but might have got broken in recent patches. I'll + investigate that +<morimoto> pinchartl: I send 0001-media-vsp1-workaroud-request-API.patch to + you +<pinchartl> morimoto: thanks +<pinchartl> dammsan: I'd like to create automated test scripts for the vsp + driver [17:48] +<pinchartl> but haven't had time to work on that yes +<dammsan> pinchartl: thanks +<dammsan> i've asked morimoto-san to send a patch related to 2) as well +<pinchartl> ok :-) +<pinchartl> how about 3 ? [17:49] +<dammsan> right +<dammsan> result of UDS is not correct +<dammsan> we don't know much detail about it +<dammsan> but perhaps you can show us your test case? [17:50] +<dammsan> that is known to work? =) +<pinchartl> it could also be a regression +<pinchartl> I've tested it before +<pinchartl> I'll retest it +<dammsan> thanks +<dammsan> the multimedia guys say they want to add more feature requests +<morimoto> pinchartl: sending done [17:51] +<pinchartl> because we don't have enough work ? :-) +<dammsan> but prefer to get the basic features finished first +<pinchartl> morimoto: thanks +<dammsan> i guess they may not be aware of the delay invovled +<pinchartl> when do the multimedia guys want all that to be fixed ? [17:52] +<dammsan> then theralready +<dammsan> err +<dammsan> already +<dammsan> they said they requested to have it in february, but got it + semi-working in march [17:53] +<dammsan> they seem to be concerned about plane-alpha and pixel-alpha ass well +<pinchartl> the request API, or the multiple inputs + UDS ? [17:54] +<pinchartl> multiple inputs + UDS is definitely a regression +<pinchartl> I've successfully tested it when the features were merged +<pinchartl> I'll add plane-alpha + pixel-alpha to the todo list +<pinchartl> target is v4.7 +<dammsan> thanks +<dammsan> how about we confirm priority of the current list when we meet these + guys f2f tomorrow [17:55] +<pinchartl> that's a good idea [17:56] +* uli___ sneaks in +<pinchartl> hi Ulrich [17:57] +<pinchartl> last item is suspend/resume crashes +<pinchartl> I haven't tested that on Gen3 as we don't have propery + suspend/resume support +<pinchartl> however I expect the crash to happen on Gen2 as well +<dammsan> fix gen2 first? +<pinchartl> of course [17:59] +<pinchartl> I'll add it to the todo list too +<pinchartl> which gets quite full for v4.7 +<pinchartl> I'll mark it for v4.8, but I'll let you confirm priorities in your + meeting tomorrow +<dammsan> thanks [18:01] +<pinchartl> anything else for the vsp ? +<dammsan> we will bring information from that meeting to f2f meet up at ELC +<dammsan> not that i am aware of +<pinchartl> ok, thank you +<morimoto> Does datasheet for VSP was OK for you ? [18:02] +<pinchartl> topic 3 +<pinchartl> morimoto: I think so +<morimoto> good +<pinchartl> how will the 50% contract affect multimedia development ? [18:03] +<pinchartl> we have no shortage of work +<pinchartl> and everything is urgent +<pinchartl> yet, the contracts will be reduced to 50% for April +<pinchartl> how do we deal with that ? +<dammsan> i doubt it will be very visible from the outside [18:04] +<dammsan> if one month drops and two other months increases +<dammsan> but that is not your concern perhaps? =) +<pinchartl> does that mean May and June could be covered by contracts at 125% + then ? +<morimoto> I think Base 50% + Additional 25% + Additional 25% [18:05] +<dammsan> the total amount of cash remains unchanged +<pinchartl> if we have 50 in April, 100 in May and 100 in June, that's 250 + instead of 300 +<pinchartl> (I'm talking about development time, no cash) +<dammsan> but we never have that amount of time anyway +<dammsan> with other customers and paperwork due dates [18:06] +<pinchartl> let's put it another way +<dammsan> so first month is always short before invoice? +<dammsan> sure, i'll be silent =) +<pinchartl> when I have to send a report by the 17th of the first month, I + still work from the 17th to the end of the month [18:07] +<dammsan> uli___: please chat with me using google chat about tasks +<uli___> ok +<dammsan> pinchartl: sure +<pinchartl> are we expected to work less during April compared to what we've + done so far ? +<dammsan> you may include the second half of your patches in the second + report? +<pinchartl> less = 50% of a normal month +<dammsan> it is up to you really [18:08] +<pinchartl> dammsan: I might, but I still work during the second half of the + last month of the contract +<dammsan> since you only have the base contract +<dammsan> you will not be sure how much you can adjust your work later on +<pinchartl> my point is that, if we reduce the contract scope to 50% for April + and leave it to 100% in May and June, that's 250 work time points + instead of the usual 300 +<pinchartl> meaning development will be slowed down [18:09] +<dammsan> so may and june may get more busy +<dammsan> so if you want to reduce your burden then work a bit more for base + in april to make room for may and june? +<pinchartl> so, to put it another way, is Renesas asking us to work for free + half of April because we might get more work later ? +<dammsan> no? +<dammsan> renesas is asking you to do what is written in the contract. [18:10] +<dammsan> period. +<pinchartl> but at the same time they're asking us to deliver features faster + than what we've done so far +<dammsan> hm..? +<pinchartl> "please deliver faster, but work only 50% to do so" +<pinchartl> doesn't make too much sense to me :-) +<dammsan> that portion that i don't understand +<dammsan> who asks you to deliver sooner? +<pinchartl> you mentioned earlier that HDMI output for Gen3 should be done + before v4.7 if possible [18:11] +<pinchartl> and that the VSP1 issues are expected to be fixed already +<pinchartl> that means we're considered to be too slow +<dammsan> i think you are right [18:12] +<dammsan> sorry about that feeling +<dammsan> but it is related to too much work and too little resources +<dammsan> about that HDMI Gen3 drop it is just from my side that we should aim + for something sooner IMO +<dammsan> but we need to look at the big picture [18:13] +<pinchartl> so, what are we expected to do ? +<dammsan> with reduced amount of time in April it sure looks like April will + move slower +<dammsan> we do what we can do with the amount of time we have? +<dammsan> following priority? +<pinchartl> I can certainly leave the option to all developers in the team to + work 100% in April while being paid 50% +<pinchartl> but I won't request anyone to do so +<dammsan> of course spreading out work evenly over 3 months makes sense + [18:14] +<dammsan> but we need time to finalize the additional tasks +<dammsan> so there will unfortunately be a delay +<pinchartl> the additional tasks for May and June will cover 50%, right ? + [18:15] +<pinchartl> so that's 250 instead of 300 in total for Q2, correct ? +<dammsan> in my mind they may be more fixed-price than time based +<dammsan> but we need to discuss more +<dammsan> 250 has never been the goal [18:16] +<dammsan> it has always been 300 +<dammsan> so we need to find a good balance for the amount of work in the last + two months of the quarter +<pinchartl> could it be that the additional tasks will cover more than 50%, + resulting in ~300 for Q2 in total ? [18:17] +<dammsan> it depends on how much time each individual has +<dammsan> but yes, if the total should be 300 then it must become like that +<pinchartl> of course, but do you think it could be so ? +<dammsan> it could be how? [18:18] +<pinchartl> because in that case it could make sense to work more than what + the contract covers in April and deliver the result in May and + June +<pinchartl> (but again it would be a personal decision, I won't request anyone + to do so) +<dammsan> yes, working more earlier would be excellent +<dammsan> but no papers yet i'm afraid [18:19] +<pinchartl> I'm sure Renesas won't complain if we work more than we're paid + :-) +<dammsan> so it is difficult to say what to work on =) +<pinchartl> the question is whether there's a reasonable chance that that + "overtime" could be covered by additional tasks in May and June +<dammsan> define overtime =) +<pinchartl> working 100% in April instead of 50% [18:20] +<pinchartl> obviously guessing what would be requested in May and June +<pinchartl> but we can have a reasonable guess +<pinchartl> I'm pretty sure HDMI output will be requested for instance +<pinchartl> if you tell me now that, if I can prepare already in April, + there's a 90% chance Renesas will want to request more from me in + May and June, there's an incentive [18:22] +<pinchartl> if the chance is 5%, less so :-) +<pinchartl> I'm trying to understand what will happen +<dammsan> ifok i see [18:23] +<dammsan> (sorry, got kicked out from my VM) +<pinchartl> and with the multiple hops between our team and the decision + makers in Renesas, plus the language barrier and the business + culture differences, it's hard for me to be confident about my + understanding of the situation +<dammsan> if people are willing to work more w/o papers +<dammsan> then i propose that we simply list one major task for each member + that can be focused on in april and we think will be included as + additional task [18:24] +<pinchartl> ok +<pinchartl> I believe we can keep our current focus in April [18:25] +<pinchartl> on HDMI, VIN and VSP +<pinchartl> each will require more than 10 days (50%) to complete +<pinchartl> they might be covered by the base contract or additional tasks in + May and June +<pinchartl> but in both cases I believe they will be covered [18:26] +<dammsan> yes, good plan +<pinchartl> we need to make sure we only include 50% of the deliverables in + the April report though +<dammsan> no need to play too many paper games IMO +<dammsan> but it is up to you how you want to roll +<dammsan> if code is queued up and working then report contents are not + important [18:27] +<dammsan> just a formality +<pinchartl> I personally won't change my work pace for April (well, except + that I won't code much during ELC) +<dammsan> same here +<pinchartl> ok [18:28] +<pinchartl> should I record this in the meeting report or should I leave it + out ? +<neg> same here if it's ok for me to post patches based on datasheets while I + do not have a contract [18:29] +<pinchartl> I don't think your NDA expires at the end of the SoW +<dammsan> it is up to you +<pinchartl> so that shouldn't be a problem +<pinchartl> I'll leave it out of the meeting minutes, I'm not sure how I + should phrase it [18:30] +<pinchartl> last topic +<dammsan> my only additional comment about this is +<pinchartl> yes ? +<dammsan> if you are planning vacation, feel free to do so in april instead of + may/june =) [18:31] +<pinchartl> good point :-) +<pinchartl> I'll write that down +<dammsan> thanks +<neg> ok thanks, it was the NDA part that gave me the most grief :) +<pinchartl> neg: please read your NDA in details though [18:32] +<pinchartl> I'm not a lawyer +<pinchartl> topic 4 [18:33] +<pinchartl> next meeting +<pinchartl> the next meeting would be in 2 weeks +<pinchartl> which is ELC time +<pinchartl> who will attend ELC ? [18:34] +<pinchartl> Magnus, you said you will be there +<dammsan> yes +<pinchartl> Niklas as well ? +<neg> yes +<pinchartl> Ulrich, you don't plan to attend if I remember correctly ? +<pinchartl> how about Morimoto-san ? +<uli___> correct +<pinchartl> is Morimoto-san stuck in an interrupt storm again ? [18:36] +<dammsan> maybe [18:37] +<dammsan> he is coming +<dammsan> i know it =) +<pinchartl> :-) [18:38] +<morimoto> I was ked-napped by Magnus, so yes I will got to ELC +<pinchartl> :-D +<pinchartl> very nice +<pinchartl> we'll have the next meeting there +<morimoto> F2F meeting :) +<pinchartl> I think that's it for today then +<pinchartl> thank you everybody for joining [18:39] +<morimoto> thanks +<neg> pinchartl: do you have any more information about the mini multimedia + meeting? +<pinchartl> it will be held on Thursday +<dammsan> pinchartl: is this meeting including members outside this group? + [18:40] +<pinchartl> that's all I know for now +<dammsan> or is it for our group? +<pinchartl> that's the linux media mini-summit +<dammsan> ok cool +<pinchartl> we'll have another meeting for our group during the week +<dammsan> any ideas when to meet? +<morimoto> My departure time is 8th April +<dammsan> for me meeting with you guys is top prio [18:41] +<dammsan> it may make sense to decide right away if possible +<neg> ok I got a mail from Hans telling me to let Maruo know if I wanted to + attend, I drop him a mail and see if I can find out more +<pinchartl> let me see if the conference schedule has been published +<morimoto> Do I need something for this mini-summit ? [18:42] +<neg> I have nothing else planed during ELC so anytime works for periperi + meetup +<pinchartl> ok, my talk is on Tuesday morning [18:43] +<pinchartl> morimoto: if you want to join the mini-summit you just have to be + there and listen. and possibly talk too :-) +<pinchartl> I've sent a mail and CC'ed the three of you to ask if we have + seats [18:44] +<pinchartl> I think we will +<pinchartl> I'd prefer the F2F meeting to be on Tuesday afternoon or on + Wednesday +<morimoto> pinchartl: OK, no ticket, no register are needed +<morimoto> Thanks [18:45] +<dammsan> i'm fine either Tuesday or Wednesday +<pinchartl> let's go for Tuesday right after lunch ? +<pinchartl> or maybe starting at lunch time ? [18:46] +<morimoto> pinchartl: every time is OK for me during 4th - 8th (morning) + [18:47] +<dammsan> start at lunch time must be good +<pinchartl> I'll see if I can find a nice place to have a team lunch away from + the crowd [18:48] +<pinchartl> on Tuesday +<neg> works for me +<pinchartl> ok, I think we're done +<pinchartl> and I have to go +<pinchartl> good timing :-) +<pinchartl> thank you all for attending +<pinchartl> and see you in San Diego ! +<dammsan> thank you!! +<neg> thanks +<dammsan> see ya in CA +<morimoto> Thanks [18:49] diff --git a/wiki/Chat_log/20160411-io-chatlog b/wiki/Chat_log/20160411-io-chatlog new file mode 100644 index 0000000..cea2140 --- /dev/null +++ b/wiki/Chat_log/20160411-io-chatlog @@ -0,0 +1,195 @@ +--- Log opened Mon Apr 11 09:55:04 2016 +09:55 -!- wsa_ [~wsa@p4FE259C0.dip0.t-ipconnect.de] has joined #periperi-io +09:55 -!- Irssi: #periperi-io: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal] +09:55 -!- Irssi: Join to #periperi-io was synced in 0 secs +09:55 < wsa_> hiya +09:55 < wsa_> wow +09:55 < horms> Hi wsa_ +09:56 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi-io +09:56 < wsa_> hi guys +09:56 < shimoda> hi +09:56 < morimoto> hi +09:56 < neg> morning +09:56 < uli___> hi +09:56 < wsa_> nice to see you again! +09:57 < wsa_> so, ELC was good? +09:57 < neg> yes it was nice +09:58 < neg> good for me who are new to meet people in the flesh +09:58 < morimoto> yes I think so +09:58 < wsa_> neg: yes, hallway track is usually my fav, too :) +09:59 < wsa_> okay, then, let's get started +10:00 < wsa_> I didn't notice updates for the todo file, please tell me if I missed something +10:00 < wsa_> from my side, SDHI support for UHS-I/SDR50 was merged +10:00 < wsa_> and WDT support should show up in linux-next any day +10:01 < wsa_> SDHI probably needs DMA updates to achieve full speed +10:01 <@geertu> wsa: Have you tried Günter's restart series? +10:01 < shimoda> oh, it's nice! I (or Jinso) will test the UHS-I/SDR50 :) +10:01 < wsa_> I guess this is why we have this in the todo file: +10:01 < wsa_> SDHI,?,noplan,?,Confirm & check + tune up DMA transport speed on Gen2 +10:02 < wsa_> geertu: not yet, but will surely do today or tomorrow. It looks great to me. +10:03 < wsa_> shimoda: I get transfer rates of about 35MB/s while the card should do 90MB/s. It does 75MB/s on a Tegra-board. +10:03 <@geertu> wsa: Then the remaining question is when (if ever) to make the RWDT restart priority lower than the PSCI priority ;-) +10:04 < wsa_> geertu: yes +10:04 < wsa_> and how to activate the SWDT, because I still don't know how/where/when to change a register in secure-mode +10:05 < wsa_> oh, how impolite of me. I missed something! +10:05 < shimoda> wsa_: i see. I guess PIO is impossible to be 90MB/s on Gen3. +10:05 < wsa_> let's welcome Niklas to our group who is contracted to do IO work in Q2. +10:05 < wsa_> I didn't know until today :) +10:05 <@geertu> neg: Welcome to I/O! +10:06 < neg> thank you +10:06 < wsa_> uli___: are you also contracted for IO work or are you just interested? :) +10:06 < uli___> i'm in +10:06 < uli___> contractually, that is +10:07 < wsa_> shimoda: I agree. I first want to add eMMC support and then port the Gen3 DMA driver. +10:07 < wsa_> uli___: then welcome, too! +10:07 * geertu is not contracted for I/O work +10:07 * horms neither +10:07 < wsa_> geertu: then, bye ;))))) +10:08 < wsa_> okay, we need to talk about this contracting soon +10:08 < wsa_> in a second +10:08 <@geertu> My I/O status: Not much happened on the SCIF front due to SYSC and Easter +10:08 <@geertu> Will resume SCIF this week +10:09 < horms> geertu: quick question. am I right in thinking there is no QSPI present in Gen 3? +10:09 < shimoda> wsa_: add eMMC support first and then DMA support are good to me +10:09 < wsa_> the not surprising thing about SDHI: it sometimes really needs refactoring before adding something new to it. +10:09 < wsa_> shimoda: good +10:09 <@geertu> horms: There is. But It's for secure mode only. +10:09 < wsa_> then we will see how Gen3 DMA performs and where the bottlenecks are +10:10 < horms> geertu: ok. is it called something else in the data sheet? or absent? +10:11 < horms> wsa_: the sdhi driver has a long and cheqquered history +10:11 <@geertu> horms: It's called RPC +10:11 < horms> geertu: ok, i saw that one. thanks. +10:11 < wsa_> horms: i noticed :D +10:12 < wsa_> but i found an old TMIO datasheet which was not detailed but helped in understanding the "history" +10:12 < wsa_> and the different names for bits +10:13 < wsa_> okay, if there are no more updates to the todo, then let's talk about the situation with the contracts +10:14 < wsa_> so, i learned a lot of things today who is contracted and who is not +10:15 < wsa_> and, to be honest, i am a bit surprised to find ulrich and niklas here because they did great work for the multimedia group which is not short of tasks, is it? +10:16 < neg> my situation is that I got 5 days each for i/o, core, and multimedia (15 in total) during Q2 and ontop of that there will be additional contracts mainly for multimedia during Q2 as it looks now +10:16 < uli___> same here +10:17 < wsa_> ah, okay +10:17 < wsa_> geertu: and you are officially not contracted for IO? +10:18 < wsa_> horms: and you? +10:18 <@geertu> wsa: Indeed. Just Core Group Lead and Development +10:18 < wsa_> geertu: similar here, just with IO group, by the way +10:19 < horms> presently i am primarily working on maintainance and secondarily with Kaneko-san on upporting +10:20 < wsa_> horms: doing ethernet as a side-project hobby ;) +10:20 < horms> that has been an ongoing side project but of late its mainly been handled by Kaneko-san via the upporting work. +10:20 < wsa_> okay +10:21 < wsa_> so we need to find tasks for Uli and Niklas +10:21 < horms> iirc the main outstanding issue there is reducing dma descriptor usage for the aligned case +10:21 < horms> also Sergei sort of stepped up at some point, which imho is better than bad +10:22 < wsa_> technically, i think it would be nuts to move SCIF tasks away from Geert +10:22 < wsa_> horms: nice to hear that +10:23 < wsa_> at the the baud generator stuff is public and WIP anyhow +10:23 < wsa_> geertu: is this FIFO issue something which can be done by someone else +10:23 < wsa_> i mean reasonably +10:24 <@geertu> wsa: I assume there will be an "additional contract" in the future +10:24 <@geertu> so I don't expect to retire from I/O ;-) +10:24 < wsa_> \o/ +10:24 <@geertu> BTW, what do you mean by "WIP"? +10:24 < wsa_> ah, not baud generator +10:24 < wsa_> flow control pins +10:25 <@geertu> because BRG is in +10:25 <@geertu> There are some flushing patches in the BSP. and in Hamza's git tree +10:26 < wsa_> so, tasks I see for uli___ and neg I see from our todo-list: +10:26 < wsa_> Thermal,2016-06-30,plan,morimoto,Upstreaming For H3 +10:26 < wsa_> I2C,2016-06-30,plan,wolfram,Gen3 I2C DMA support +10:26 < wsa_> SPI,2016-05-31,plan,geert,Implement initial SPI slave prototype support for R-Car Gen2 +10:26 < wsa_> which all need reassignment +10:27 < wsa_> looks OK? did i miss something? +10:28 < morimoto> wsa_: RVC Khiem want to do Thermal for Gen3 +10:28 < morimoto> s/Khiem/Khiem-san/ +10:28 < wsa_> I see +10:28 < neg> I can start by looking at I2C DMA since I poke around with DMA anyhow +10:28 < horms> Not wanting to go around in circles, but is there any application of the SPI task to Gen 3? If not, I'm curious to know its motivation. +10:29 < wsa_> IIRC think it was a customer request? shimoda-san, do you recall more? +10:29 <@geertu> The other SPI on Gen3 is MSIOF, which has hardware issues that are supposed to be fixed in ES2, or in M3-W +10:30 < horms> Ok, so it might be used in the context of MSIOF on Gen 3? +10:30 <@geertu> And DRIF, which is sort-of half-duplex SPI slave +10:30 < wsa_> could we use Gen2 for the prototype? +10:30 <@geertu> That's what it says: "... for R-Car Gen2" +10:30 < wsa_> morimoto: can i add khiem-san to the todo file as "khiem"? +10:30 < horms> wsa_: no argument about prototyping on Gen 2 +10:30 < horms> I was just wondering what the end game was +10:30 < wsa_> geertu: got me there :D +10:31 < horms> neg: my notes tell me SYS-DMAC Supports I2C 0 to 6 and IIC-DVFS. v0.51e 17.1.1 +10:31 < morimoto> wsa_: that is good idea for me :) +10:31 < horms> neg: in case that is of any help +10:32 < neg> horms: thanks +10:33 < wsa_> uli___: how does implementing SPI slave support sound to you? that's a new thing for linux... +10:33 < horms> neg: i think the implication is that you can do dma to/from 40 bit addresses using the SYS-DMAC. I don't have notes of any other dma capabilities for I2C +10:33 < wsa_> geertu: would you be ok to reassign the task? +10:34 < uli___> i have no clue about spi, so i might as well as well have a look at it... +10:34 <@geertu> wsa: SPI? I think it may be a bit premature +10:35 < wsa_> geertu: what do you mean? +10:36 <@geertu> wsa: There will be additional contracts, right? +10:36 <@geertu> I already spent lots of investigation about SPI slave +10:36 < wsa_> shimoda: how is USB going? is there a place where you could need help? +10:38 < neg> horms: nice, the manual even have flow-charts for DMA operation :) +10:38 < horms> :) +10:39 < wsa_> geertu: i see +10:39 < shimoda> i am doing USB3-host, USB-PHY tasks. But, I forgot the "USB2-Func,?,noplan,shimoda,IPMMU issues" :) +10:42 < shimoda> and i have a problem about usb2 host with IPMMU (that is not listed the todo list yet) +10:42 < wsa_> shimoda: so, could the IPMMU tasks be done by someone else? +10:42 < wsa_> uli___: how does USB & IPMMU sound? +10:42 < shimoda> and I sent a question about it to Magnus-san +10:42 < shimoda> wsa_: it is nice idea +10:43 < uli___> i can look at that +10:43 < wsa_> \o/ +10:44 < shimoda> uli___: thanks! +10:45 < shimoda> Oh, i have a note about IPMMU of Gen3. +10:45 < wsa_> so, I'll assign usb2-func & IPMMU task to uli +10:45 < wsa_> and wait for shimoda-san if i should add a task about usb2-host & IPMMU +10:46 < shimoda> we need a new firmware which will be released on this month if we use Gen3 +10:46 < horms> v2.8.0? +10:47 < shimoda> horms: yes +10:48 < shimoda> the default setting of IPMMU is not suitable for linux and the register can be modified on secure-mode :) +10:48 < wsa_> I want a u-boot command to change registers in secure-mode :) +10:49 < wsa_> shimoda: can i set the usb3-host task to planned for v4.8? +10:49 < shimoda> wsa_: about usb2-host & IPMMU, I would like to get Magnus-san's reply +10:50 < wsa_> yes, i agree +10:51 < wsa_> i meant this one: +10:51 < wsa_> USB3-Host,?,noplan,shimoda,suspend problems +10:51 < wsa_> since you said you currently work on usb3-host tasks +10:51 < wsa_> or is it something else? +10:51 < shimoda> I see, i'm working the task now because Gen3 also has such an issue :) +10:52 < shimoda> I would like to ask HW team why this issue happen +10:53 < shimoda> so now i'm trying to get register dump and then pass it to hw team +10:54 < wsa_> i see +10:54 < shimoda> about workabout is simple, we just add XHCI_SLOW_SUSPEND quirk on Gen3, but we need a reason for upstreaming +10:55 < shimoda> s/workabout/workaround/ +10:57 < wsa_> ok +10:57 < horms> shimoda: we need to know which hw is effected and why? +10:58 < wsa_> uli___: I set the the milestone to v4.8. let me know if this is realistic after you get an overview of the problem +10:58 < shimoda> horms: yes, i will try to get such information +10:59 < horms> shimoda: thanks. fwiw that makes sense to me +10:59 < uli___> will do +10:59 < wsa_> shimoda: can you mail uli a description of the problem? +10:59 < wsa_> neg: I will give some introduction to the I2C DMA topic as well +11:00 < wsa_> OK, I think we are done then? +11:00 < shimoda> wsa_: sure +11:00 < neg> wsa_: thanks +11:01 < uli___> shimoda: thank you +11:01 < wsa_> we included three new members today! +11:01 < wsa_> the new contracts really shuffle things around ;) +11:02 < wsa_> last chance for news from your side +11:02 < horms> nothing from my side +11:03 < wsa_> Then, thank you all! It seems we found suitable tasks for everyone in the end. I hope everyone is happy. +11:03 < shimoda> nothing from me +11:04 < wsa_> then, see you next time :) +11:05 < uli___> see you +11:05 < neg> thanks all, see you all next time +11:05 < horms> likewise +11:05 < morimoto> wsa_: can you add this meeting log to Redmine ? +11:05 <@geertu> Thx, CU +11:06 < wsa_> morimoto: sure thing +11:06 < morimoto> Thanks. and bye +11:06 -!- horms [~horms@reginn.isobedori.kobe.vergenet.net] has quit Quit: Leaving +11:06 < shimoda> thank you, bye! +11:06 -!- morimoto [~user@relprex2.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +11:06 -!- shimoda [~shimoda@relprex1.renesas.com] has quit Quit: WeeChat 0.4.2 +11:12 -!- neg [~neg@unaffiliated/neg] has left #periperi-io [] +11:15 -!- geertu [~geert@d54C36A7B.access.telenet.be] has left #periperi-io [] +11:20 -!- Irssi: #periperi-io: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal] +--- Log closed Mon Apr 11 11:36:19 2016 diff --git a/wiki/Chat_log/20160412-core-chatlog b/wiki/Chat_log/20160412-core-chatlog new file mode 100644 index 0000000..1ad0e29 --- /dev/null +++ b/wiki/Chat_log/20160412-core-chatlog @@ -0,0 +1,204 @@ +Core-chat-meeting-2016-04-12 + +10:10 < geertu> Agenda: +10:10 < geertu> 1. Upcoming Gen3 development for the Core group, +10:10 < geertu> 2. Firmware upgrade and consequences (hotplug, DDR, ...) +10:10 < geertu> 3. Does it make sense to have "renesas,cpg = <&cpg_clocks>;" in the SYSC device node? Or do we want to avoid that at all cost? +10:10 < geertu> 4. Status check for tasks from last meeting - what is remaining? +10:10 < geertu> horms: So that would mostly by Topics 1 and 2? +10:10 < geertu> s/1 and 2/2 and 3/? +10:10 < geertu> Topic 2. Firmware upgrade and consequences (hotplug, DDR, ...) +10:10 < geertu> horms: You've already tried v2.7.0? +10:10 < horms> geertu: yes, i lightly tested it +10:11 < horms> hotplug appears to work as per my email +10:11 < khiemnguyen> For topic 2, what is current version that all are using ? Yocto v2.3.0 ? +10:11 < horms> so that seems positive +10:11 < geertu> v2.5.0, IIRC +10:11 < geertu> Any known regressions? +10:11 < khiemnguyen> yes, hotplug has been able to work from Yocto v2.4.0 +10:11 < horms> n.b. firmware version != yocto version +10:12 < horms> I think geert was referring to the former +10:12 < geertu> khiemnguyen: Only the first time. After hot-unplug, hot-plug no longer works in v2.5.0 +10:12 < horms> _I_ am not aware of any regressions +10:12 < khiemnguyen> you tried with CPU0, right ? +10:12 < horms> let me check +10:12 < khiemnguyen> CPU0 has a limitation for CPU Hotplug, since the secure side will run some secure services in CPU0 all the time. +10:13 < khiemnguyen> Please try CPU Hotplug with CPU1/2/3 only. +10:13 < horms> I only tried CPU1 +10:13 < horms> What happens on CPU0? +10:14 < khiemnguyen> the secure side will run some secure services in CPU0 all the time. +10:14 < khiemnguyen> CPU0 should not be hotplug. +10:14 < horms> ok +10:15 < horms> so if it is unplugged we might see some problems? like undefinded behaviour? +10:15 < khiemnguyen> so if it is unplugged we might see some problems? like undefinded behaviour? --> yes. +10:16 < geertu> Hmm... +10:16 < geertu> It would be better if the operation just failed with an error code +10:16 < horms> yes, i think we should disallow it somehow +10:16 < geertu> Else we have to explicitly have a check to prevent the user from doing that +10:17 < horms> oh, you mean the fimrware should return an error? +10:17 < khiemnguyen> Yes. But the firmware has not supported that feature yet. +10:18 < geertu> horms: Yes, I mean the firmware +10:18 < khiemnguyen> Therefore, in in-house BSP, I have created a work-around patch to disable CPUHotplug request in CPU0. +10:18 < pinchartl> as it's a firmware requirement that CPU0 can't be unplugged, it would make sense for the firmware to implement the check +10:18 < horms> khiemnguyen: ok. good to know. do you know if that is planned? +10:19 < khiemnguyen> as it's a firmware requirement that CPU0 can't be unplugged, it would make sense for the firmware to implement the check ---> but they put it as low-priority now. since we also has a work-round patch in Linux kernel. +10:19 < horms> ok. but from an upstream point of view it seems like a priority. could you pass that information on? +10:19 < geertu> khiemnguyen: if we include the workaround in upstream, ideally it should check for the firmware version, to know when to apply it or not. +10:20 < geertu> And the question remains where in the code to put the check (no board code) +10:20 < khiemnguyen> do you know if that is planned? ---> official support in firmware might be available by E/this year, I heard. +10:20 < pinchartl> geertu: I'd keep the workaround away from upstream +10:21 < pinchartl> upstreaming CPU hotplug would then require a firmware that supports hotplug properly +10:21 < pinchartl> putting some pressure to implement that :-) +10:21 < khiemnguyen> And the question remains where in the code to put the check (no board code) ---> huhm..., to check firmware version, we need more than that, need optee linux driver to communicate with secure side. +10:21 < geertu> pinchartl: Even better. Except that we alrady have hotplug in upstream/ +10:21 < horms> pinchartl: fwiw, CPU hotplug is already upstream +10:22 < pinchartl> well, fixing it upstream then I suppose :-) +10:22 < khiemnguyen> yeah, CPU Hotplug is already supported in usptream, for CPU1/2/3, given that the firmware is taken from Yocto v2.4.0 or later. +10:24 < geertu> Things like CPU hotplug are enabled automagically once you have a PSCI platform. +10:24 < geertu> Whether they work or not is a different issue... +10:24 < shimoda> FYI, khiem-san's workaround is 9c910ad5a1e60b302e88ef394bcff84018e69adc in renesas-bsp.git +10:25 < horms> khiemnguyen: is there any possibility we could ask for the feature to be in firmware sooner than later. it would really help things on the upstream side. +10:26 < geertu> BTW, what's "DDR training"? +10:26 < khiemnguyen> Let me know the feature, will try to confirm with secure team. +10:27 < horms> khiemnguyen: thanks. I think the feature request is to return an error for a request to take CPU0 down. +10:27 < horms> so long as doing so causes problems. +10:27 < khiemnguyen> DDR training is rountine activity to check SDRAM operation and adjust SDRAM parameters for best performance. +10:27 < pinchartl> geertu: it's automatic detection (and configuration) of the DDR memory controller to take into account board design +10:27 < pinchartl> including traces length for instance +10:28 < geertu> OK, thx +10:28 < geertu> Another issue with the firmware upgrade was "secret" DDR clock frequency +10:29 < geertu> which requires public changes in the r8a7795 CPG/MSSR driver. +10:29 < pinchartl> "Typically, a data training sequence is performed at startup to find the optimum position for the DQS input buffer enable signal. This can be accomplished by performing reads with deterministic patterns while sweeping through the possible system latency values." +10:29 < pinchartl> (http://www.design-reuse.com/articles/13805/the-love-hate-relationship-with-ddr-sdram-controllers.html) +10:30 < khiemnguyen> "secret" DDR clock frequency --> 2400 ? +10:30 < horms> geertu: my understanding is that there are some hw bugs relating to DDR. and that a resolution is not at hand at this time. iirc only 2400 works at this time. (my memory may be entirely faulty on this topic) +10:32 < geertu> khiemnguyen:yes, 2400, cfr. +10:32 < geertu> BSP kernel +10:32 < geertu> MD19 MD17 : PLL3 mult +10:32 < geertu> ------------------------------- +10:32 < geertu> 1 0 : x144 (for DDR2400) +10:32 < geertu> 1 1 : x192 (for DDR1600) +10:32 < khiemnguyen> Currently, let's keep using DDR1600. +10:32 < geertu> khiemnguyen: That's an option? Morimoto-san said 1600 didn't work with v2.7.0 +10:33 < khiemnguyen> geertu: I have no issues here. +10:34 < geertu> OK +10:34 < geertu> So we should upgrade to v2.7.0 now? +10:34 < khiemnguyen> geertu: I think so. Any issues, please let me know, I will support. +10:36 < khiemnguyen> Here, the boards are set with DDR1600, and we have already did many development in v2.7.0. Just to make sure to re-write all IPL, u-boot and rootfs from Yocto v2.7.0 +10:37 < geertu> update_salvator_bootloader_v270-4core.tar.bz2 or update_salvator_bootloader_v270-8core.tar.bz2? +10:37 < horms> fwiw I used the 4core variant +10:37 < horms> as i was unsure +10:37 < khiemnguyen> 4core +10:38 < geertu> what happens with 8core? +10:38 < khiemnguyen> 8core support is in-progress. still need more work to stabilize 8core... +10:38 < geertu> OK +10:38 < geertu> Let's move on... +10:38 < geertu> Topic 3. Does it make sense to have "renesas,cpg = <&cpg_clocks>;" in the SYSC device node? Or do we want to avoid that at all cost? +10:39 < geertu> This is about getting the SYSC driver in ASAP, as it's a dependency for DU/VSP +10:39 < pinchartl> geertu: as mentioned yesterday, I'd prefer not having it +10:39 < geertu> pinchartl: The night brought me some advice. +10:40 < geertu> BSP kernel +10:40 < geertu> MD19 MD17 : PLL3 mult +10:40 < geertu> ------------------------------- +10:40 < geertu> 1 0 : x144 (for DDR2400) +10:40 < geertu> oops, wrong paste +10:40 < geertu> - compile-time: +10:40 < geertu> - #define cpg_mstp_attach_dev NULL if CPG/MSTP driver is not included +10:40 < geertu> - #define cpg_mssr_attach_dev NULL if CPG/MSSR driver is not included +10:40 < geertu> Either by: +10:40 < geertu> - #ifdef on all SoCs +10:40 < geertu> - introduce Kconfig symbol that's selected by all SoCs that use it +10:40 < geertu> - run-time: Check for presence of "renesas,cpg-mstp-clocks" to select between +10:40 < geertu> cpg_mstp_attach_dev and cpg_mssr_attach_dev +10:41 < geertu> That would more or less be the way it was done in v3 of my series +10:41 < geertu> And it's backwards-compatible. +10:41 < pinchartl> sounds good to me +10:41 < geertu> It does require exporting cpg_mssr_attach_dev, like in v3 +10:42 < pinchartl> I'm fine with that +10:43 < geertu> I would prefer not to introduce Kconfig symbols for MSTP and MSSR (currently it's handled in the Makefile), but as I'll have to duplicate the logic in both Makefile and header file, I think that's the best option +10:44 < pinchartl> it would be internal Kconfig options only, right ? +10:44 < pinchartl> nothing directly user-selectable ? +10:45 < geertu> And with the -EPROBE_DEFER trick in cpg_mssr_attach_dev (cfr. v3), there can be a single point of initialization again, and I think we won't loose sound and SPI DMA due to wrong initialization order anymore. +10:45 < geertu> Yes, internal symbols (default y if CONFIG_ARCH_<soc>) +10:46 < geertu> OK, will go for it. Won't be in today's renesas-drivers, but I'll provide an integration branch including it +10:47 < geertu> Topic 1. Upcoming Gen3 development for the Core group +10:47 < pinchartl> thank you +10:48 < geertu> Any updates for the discussion topics targeted at v4.6? +10:48 < morimoto> BTW, geertu, thank you for your help about peripelist +10:49 < geertu> morimoto: You're welcome +10:52 < khiemnguyen> Any upcoming Power Management feature, beside CPUHotplug and RuntimePM ? +10:54 < geertu> khiemnguyen: Is PSCI reboot supported/planned? +10:54 < khiemnguyen> geertu: already supported. +10:54 < khiemnguyen> Please try with Yocto v2.7.0 +10:54 < geertu> khiemnguyen: Do you know as of which version? +10:54 < geertu> OK +10:55 < khiemnguyen> Maybe, reboot has already able to work from Yocto v2.5.0. +10:57 < geertu> Any other upcoming development? +10:57 < pinchartl> I'll post a small rcar-dmac fix, nothing big +10:57 < khiemnguyen> I prefer CPUFreq, changing CPU0/1/2/3 frequency. +10:58 < morimoto> pinchartl: is it suspend/resume issue ? or list_add issue ? +10:58 < geertu> OK +11:00 < pinchartl> morimoto: list_add +11:01 < pinchartl> morimoto: is there a suspend/resume issue with rcar-dmac ? +11:03 < morimoto> pinchartl: I reported it to you before ;) +11:03 < morimoto> let me check +11:05 < morimoto> anyway pinchartl, geertu, can you add this issue to peripelist ? +11:05 < morimoto> this issue -> list_add +11:06 < geertu> morimoto: Do you have a better description than "rcar-dmac list_add issue"? +11:07 < morimoto> pinchartl: can you do it ? +11:07 < morimoto> it is related to rcar-dmac memory control +11:07 < pinchartl> geertu: there's an atomic DMA memory pool exhaustion due to how DMA descriptors are reused +11:08 < pinchartl> every DMA descriptor needs DMA memory for hardware descriptors +11:08 < pinchartl> and the driver keeps that memory allocated until the channel is release for performance reason +11:09 < pinchartl> when recycling a completed DMA descriptor, the driver puts it back at the end of the list of the free descriptors +11:09 < pinchartl> and will thus end up allocating DMA memory for all of them, even if only a few are in flight at the same time +11:10 < pinchartl> adding the descriptor to the front of the list will make it better +11:10 < geertu> Adding "RCAR-DMAC,v4.7,plan,laurent,Fix atomic DMA memory pool exhaustion +11:10 < morimoto> pinchartl: but it is for quick-hack verion, not formal fix ? +11:10 -!- horms2 [~horms@g1-27-253-251-6.bmobile.ne.jp] has joined #periperi +11:11 < horms> I have to wander off now. horms2 is me on my mobile. I may or may not be able to track the rest of the meeting there. +11:12 < morimoto> pinchartl: sorry suspend/resume was vsp1 side issue +11:12 < morimoto> geertu: thank you +11:12 -!- horms [~horms@pd2fa4006.osaknt01.ap.so-net.ne.jp] has quit [Quit: Leaving] +11:12 < geertu> horms2: OK, have a nice flight! +11:13 < pinchartl> morimoto: it's a quick hack indeed, but I don't expect a long-term solution before, well, long :-) +11:13 < pinchartl> morimoto: thought so about the suspend/resume issue :-) +11:14 < geertu> Topic 4. Status check for tasks from last meeting - what is remaining? +11:14 < geertu> "add r8a7795 drive-strength support" is public (and queued in sh-pfc-for-v4.7) +11:16 < geertu> "Investigate SYS-DMAC2" is apparently a bootloader issue. +11:16 < geertu> shimoda: Do you know if this is fixed in v2.7.0? +11:16 < shimoda> about "r8a7795,v4.7,prototype,shimoda,Investigate SYS-DMAC2", this will be fixed if we use the v2.8.0 firmware +11:16 < geertu> OK (ah, typing concurrently ;-) +11:16 < shimoda> v2.8.0 will be released by end of this month +11:17 < shimoda> geertu: yes :) +11:17 < geertu> Can we drop the " +11:18 < geertu> Can we drop the "Add support for valuable devices to multi-platform r8a7778/9" tasks? +11:18 < geertu> Any items left? +11:18 < neg> thanks to a good talk with Laurent during ELC I have a way forward for DMAC+IPMMU +11:18 < geertu> (i.e. mark as completed) +11:19 < geertu> uli: I remember a pinctrl-single patch for BOCK-W FPGA that Laurent objected against but that was needed for Ethernet? Ethernet still works without it though? +11:20 < uli___> i have not actually tried that, i think +11:20 < shimoda> about Gen3 IPMMU, we also should use v2.8.0 because the default setting is not good for linux environment +11:20 < shimoda> s/use v2.8.0/use v2.8.0 firmware/ +11:22 < neg> silly question, where can I find v2.8.0 firmware? Looked in the yocto repo I know of but that states BSP version 1.9.7 +11:22 < geertu> "< shimoda> v2.8.0 will be released by end of this month" +11:22 < neg> ahh ok :) +11:23 -!- khiemnguyen [d2a0fca9@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.169] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] +11:24 -!- khiemnguyen [d2a0fca9@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.169] has joined #periperi +11:25 < horms2> geertu: I think they are also covered by some integration tasks. depending on your definition of interestingly they are not finished afaik +11:27 < geertu> horms2: s/interestingly/valuable/, I assume? +11:27 < horms2> yes, that is what I meant :) +11:27 < morimoto> neg: not yet v2.8.0 +11:27 < geertu> Never trust spelling autocorrect on a mobile device ;-) +11:28 < geertu> I think we're done? Anything I missed? +11:28 < horms2> or my typing skills! +11:29 < horms2> not from me. is dammsan still online? +11:30 < geertu> He is, but he's quiet +11:30 < horms2> ok. I will be quite too +11:31 < geertu> Thanks for joining, and have a nice continued day/evening/morning! +11:31 < geertu> or flight... +11:31 < dammsan> thanks guys +11:31 < neg> thanks all, bye +11:32 < shimoda> thank you!, bye +11:32 < uli___> bye +11:32 < morimoto> bye diff --git a/wiki/Chat_log/20160419-mm-chatlog b/wiki/Chat_log/20160419-mm-chatlog new file mode 100644 index 0000000..b509629 --- /dev/null +++ b/wiki/Chat_log/20160419-mm-chatlog @@ -0,0 +1,663 @@ +Multimedia-chat-meeting-2016-04-19 + +<pinchartl> goooooood morning ! [15:54] +<neg> morning +<pinchartl> or afternoon +<uli___> hello [15:55] +<dammsan> hi guys +<morimoto> hi +<pinchartl> we have everybody, perfect [15:57] +<pinchartl> let's get started +<pinchartl> (sorry, I was opening the tasks list) +<pinchartl> agenda for today +<pinchartl> Topic 1. Status check for the multimedia tasks [15:58] +<pinchartl> Topic 2. Additional '50%' tasks +<pinchartl> Topic 3. Next meeting +<pinchartl> anything else ? +<pinchartl> I'll take that as a no [15:59] +<pinchartl> Topic 1. Status check for the multimedia tasks +<pinchartl> let's handle that in alphabetical order [16:00] +<pinchartl> we have, for Magnus +<pinchartl> VIN,?,plan,magnus,IPMMU integration on Gen2 +<pinchartl> VIN,?,plan,magnus,IPMMU integration on Gen3 +<pinchartl> VIN,?,plan,magnus,IPMMU support on Gen2 +<pinchartl> VIN,?,plan,magnus,IPMMU support on Gen3 +<dammsan> no progress so far =) +<pinchartl> ok, that's an easy one :-) [16:01] +<pinchartl> now, for Morimoto-san +<pinchartl> RSND,2016-06-30,plan,morimoto,HDMI sound Prototype on Gen3 +<pinchartl> RSND,2016-06-30,plan,morimoto,HDMI sound Upstream support without + hotplug on Gen2 +<pinchartl> RSND,2016-09-30,plan,morimoto,Hotplug support upstream on Gen3 +<morimoto> I'm fighting with them +<morimoto> I noticed it can be 3 step +<morimoto> 1. DT graph [16:02] +<morimoto> 2. HDMI + ASoC +<morimoto> 3. RSND support +<morimoto> I sent prototype patch for 1. +<morimoto> and got any response +<pinchartl> I've seen that. would you like me to review it ? +<morimoto> Thanks, but it seems OK now [16:03] +<morimoto> I think I understand graph concept +<morimoto> but, not yet understand motivation +*** horms_ (~horms@124-171-1-229.dyn.iinet.net.au) has joined channel + #periperi +<pinchartl> that I can explain +<morimoto> please [16:04] +<pinchartl> it came from V4L2 +<morimoto> Yeah, I know. my motivation means +<pinchartl> complex camera devices are made of multiple hardware devices +<pinchartl> camera sensor, CSI receiver, ISP, lens controller, flash + controller, ... +<pinchartl> those devices can be inside the SoC or on-board [16:05] +<pinchartl> and they can be mixed and matched on different SoCs/boards +<pinchartl> so we have, in V4L2, a framework to support them using multiple + drivers +<pinchartl> it's a bit similar to ASoC +<pinchartl> when we had to create DT bindings +<pinchartl> we needed a way to express how the devices were connected together + from a data flow point of view +<pinchartl> like saying that the camera sensor output is connected to the + input of CSI-2 receiver 2 [16:06] +<pinchartl> or that the output of CSI-2 receiver 0 is connected to input 3 of + the ISP +<pinchartl> essentially, that's expressing a graph of data flow connections +<pinchartl> hence the OF graph bindings [16:07] +<pinchartl> a device represented in DT can have multiple ports +<pinchartl> those are connection points through which data flows +<pinchartl> and to represent connections between ports, we use endpoints +<pinchartl> and endpoint repreent one end of a connection [16:08] +<pinchartl> we need the endpoints because a port on one DT node can be + connected to ports of multiple other DT nodes +<pinchartl> is that clearer ? +<morimoto> 80% [16:09] +<morimoto> I understand that the connection is very complex. +<morimoto> but my question is +<dammsan> pinchartl: do the ports map directly to hardware? +<pinchartl> yes they do +<pinchartl> so do the connections +<dammsan> morimoto-san was saying? [16:10] +<morimoto> my question is +<morimoto> 1) we can happy to find-out its connection when probing timing ? +<morimoto> 2) does graph supports runtime switching ?? +<morimoto> do we would like to find its connection on probe timing ?? +<morimoto> we can use phandle for connection itself ? [16:11] +<morimoto> (for 1. question) +<pinchartl> I'm not sure to understand the first question +<morimoto> I think phandle can do that ? [16:12] +<morimoto> if we would like to know "connection" +<pinchartl> we use phandles to describe connections +<pinchartl> a connection is a link between two ports +<pinchartl> it's represented as a phandle to an endpoint [16:13] +<pinchartl> the endpoint on one side of the connection references the endpoint + on the other side through a phandle, with the remote-endpoint + property +<morimoto> Is this means, driver want to know who is connected, on probe time + ? [16:14] +<morimoto> or which channel is used ? +<pinchartl> that's what drivers usually do +<pinchartl> note that the connections in DT describe the possible hardware + connections [16:15] +<pinchartl> not the active connections at a given point of time +<pinchartl> DT will tell that device A and device B are connected at the + hardware level +<pinchartl> it will not tell whether the connection is currently in use +<pinchartl> so DT will show all possible connections +<morimoto> "all possible connections" [16:16] +<morimoto> is this the purpose of graph ? +<pinchartl> the purpose of the graph is to describe how the hardware pieces + are connected together +<pinchartl> that's all +<morimoto> Hmm... +<morimoto> OK, and it indicate connection only [16:17] +<morimoto> can't do runtime switch +<pinchartl> it certainly doesn't handle that, no +<pinchartl> you can't modify connections at runtime [16:18] +<morimoto> OK +<dammsan> pinchartl: if you want to perform a run time switch, what do you + use? +<pinchartl> unless you solder new wires to the board to create new connections +<pinchartl> but I think that's out of scope :-) +<pinchartl> runtime activation or deactivation of a connection is left for the + driver to handle, it doesn't involve DT +<pinchartl> DT describes the hardware +* geertu is dreaming of DT overlays... [16:19] +<dammsan> sure, i understand +<pinchartl> it describes how the data signals are routed on the board or in + the SoC +<dammsan> but how does the typical driver perform activation/deactivtation? +<pinchartl> it's subsystem-specific [16:21] +<dammsan> ok i see +<dammsan> thanks +<pinchartl> even the concept of connection activation/deactivtation? is + subsystem-specific +<morimoto> my patch was super quick hack for ASoC, not good for full-graph. +<morimoto> my patch reviewer said that current ASoC style is not good match to + graph style +<pinchartl> it's not defined by the DT bindings +<pinchartl> who reviewed it ? +<morimoto> Jean-Francois Moine [16:22] +<pinchartl> did +<morimoto> it seems he is working for this graph + ASoC from last year +<pinchartl> did Lars comment too ? +<morimoto> No comment from Lars +<morimoto> graph + ASoC patch was posted last year, but not accepted [16:23] +<morimoto> and he said (if my understanding was correct) +<morimoto> it need different style [16:24] +<morimoto> total +<morimoto> in total +<morimoto> I couldn't understand what is the next step for graph + ASoC + [16:25] +<pinchartl> did he explain what different style ? +<morimoto> Current ASoC is using CPU driver + Codec driver + Card driver +<morimoto> but (if my understanding was correct) [16:26] +<morimoto> graph + ASoC doens't need Card driver +<morimoto> And CPU driver needs update +<morimoto> in my understand +<pinchartl> that's correct I believe [16:27] +<morimoto> I need more investigate this topic +<morimoto> DT point <-> Code point +<morimoto> I think this is the reason why ASoC had Card driver... [16:28] +<morimoto> OK, this is current my DT issue +<pinchartl> yes, the card driver is similar in purpose to the OF graph DT + bindings [16:29] +<morimoto> Ahh, OK, this is understandable comment for me +<morimoto> :) +<morimoto> I couldn't 100% understand why graph is needed, because ASoC + already had Card :) [16:30] +<morimoto> And, next 2. HDMI + ASoC +<pinchartl> the idea is that video uses the OF graph DT bindings +<pinchartl> and alsa has the ASoC DT bindings +<pinchartl> and now that we have a connector that can carry both video and + audio, we need to connect the two +<pinchartl> that's the issue +<pinchartl> two totally different DT binding concepts that need to be + connected together [16:31] +<morimoto> I think it is not easy +<morimoto> above Jean-Francois had tring this issue +<morimoto> but not yet accepted [16:32] +<morimoto> and next HDMI sound + ASoC, I know Russel added dw-hdmi-ahb-audio + driver [16:34] +<morimoto> I think DU is using dw-hdmi-bind() function +<morimoto> above is related to it. +<morimoto> I think this driver seems have compatible [16:35] +<morimoto> but, +<morimoto> the data flows is not same as our chip +<morimoto> and our datasheet doesn't indicate detail +<morimoto> dw-hdmi-ahb-audio is using mem -> DMA -> chip [16:36] +<pinchartl> there's no proper upstream solution at this point. Russell + sometimes has, let's say, very personal and peculiar ideas when it + comes to DT bindings or driver framework designs +<morimoto> our case, mem -> SSI -> chip +<pinchartl> by DMA do you mean DMA engine ? +<morimoto> not DMAEngine, it seems this chip has DMA inside [16:37] +<pinchartl> as in the Linux DMA engine API +<pinchartl> ok +<pinchartl> dw-hdmi-ahb-audio might need to be reworked +<morimoto> but our datasheet doesn't show it +<pinchartl> I haven't looked at it, I don't know how it works +<morimoto> it seems this chip is supporting many data transfer style +<morimoto> anyway, I'm asking detail to HW team [16:38] +<pinchartl> ok +<pinchartl> regarding the OF graph DT bindings +<pinchartl> we need to solve the problem of two separate DT bindings existing + for video and audio +<pinchartl> I don't know what will be accepted upstream [16:39] +<pinchartl> it's an open issue, nobody has solved it upstream yet +<morimoto> yeah +<morimoto> I think it is not easy ? +<pinchartl> so I'm afraid this needs new designs, new ideas, and lots of + discussion to agree on a solution with everybody +<pinchartl> it's certainly not easy, no [16:40] +<morimoto> Do you think this is 1st priority ? +<morimoto> Or should I create prototype as 1st step ? +<pinchartl> DT bindings are a stable ABI, so they are a prerequisite for + upstream merge +<morimoto> prototype = HDMI can use sound somehow +<pinchartl> you can certainly create a prototype [16:41] +<pinchartl> if we want to convince people about a given DT bindings scheme we + have to show that it works, and how it works +<pinchartl> so an implementation is needed +<morimoto> Sorry, my prototype means skip DT at this point, and work to HDMI + sound output as 1st [16:42] +<pinchartl> you can do that, but it can't be merged upstream without DT + bindings +<morimoto> Yes, prototype is needed to discussion +<morimoto> Yes. +<morimoto> So, this DT issue is my 1st priority [16:43] +<pinchartl> DT bindings take time to be discussed and agreed on +<pinchartl> so it makes sense to start early +*** wsa_ (~wsa@p4FE25DE7.dip0.t-ipconnect.de) has joined channel #periperi +<morimoto> OK, will try +<pinchartl> but while discussions are ongoing, a prototype of sound support + can certainly be written [16:44] +<pinchartl> the runtime side doesn't depend on DT +<pinchartl> only probind does +<morimoto> I think DT is big issu [16:45] +<morimoto> issue +<morimoto> HDMI + ASoC is big issue +<morimoto> SSI HDMI supoort is not a big issue +<pinchartl> I think I agree, although changes to the dw-hdmi-ahb-audio driver + might not be very easy to get past Russell [16:46] +<morimoto> OK, thanks [16:47] +<morimoto> this is current my headache, oops, progress +<pinchartl> :-) +<pinchartl> so what's your plan ? create a prototype in parallel to the DT + bindings discussions ? [16:48] +<morimoto> parallel ? +<morimoto> Yah yes +<pinchartl> at the same time +<morimoto> DT bindings discussions + HDMI sound prototype code, do you mean ? + [16:49] +<pinchartl> yes +<morimoto> yes +<morimoto> Can you separate todo list for me ? [16:51] +<morimoto> DT + dw-hdmi-ahb-audio + SSI +<pinchartl> split "RSND,2016-06-30,plan,morimoto,HDMI sound Prototype on Gen3" + in three ? +<morimoto> Yes [16:52] +<pinchartl> ow about +<pinchartl> RSND,2016-06-30,plan,morimoto,DT bindings for HDMI sound +<pinchartl> RSND,2016-06-30,plan,morimoto,dw-hdmi-ahb-audio prototype on Gen3 +<pinchartl> RSND,2016-06-30,plan,morimoto,SSI prototype on Gen3 +<pinchartl> (s/ow/how/) +<morimoto> SSI prototype -> SSI + HDMI support prototype [16:53] +<morimoto> is understandable. +<morimoto> other 2 are nice for me +<pinchartl> ok +<pinchartl> I'll do that +<morimoto> thanks +<pinchartl> anything else for audio ? +<morimoto> nothing +<pinchartl> ok [16:54] +<pinchartl> next, Niklas +<pinchartl> ADV7482,v4.7,plan,niklas,Prototype on Gen3 +<pinchartl> ADV7482,v4.8,plan,niklas,Gen3 support upstream +<pinchartl> ADV7482,v4.8,plan,niklas,Interlace support upstream +<pinchartl> VIN,?,plan,niklas,Gen3 support +<pinchartl> VIN,?,plan,niklas,Scaler support (on Gen3) +<pinchartl> VIN,v4.7,plan,niklas,CSI2 prototype (Gen3) +<pinchartl> VIN,v4.7,public,niklas,New VIN driver without soc-camera (tested + on Gen2) +<pinchartl> VIN,v4.8,plan,niklas,CSI2 interlace support upstream (Gen3) +<pinchartl> VIN,v4.8,plan,niklas,CSI2 support upstream (Gen3) +<pinchartl> VIN,v4.8,plan,niklas,Gen3 support upstream (without CSI-2) +<neg> VIN on Gen2 on track, will need another patch Hans extended the test + suite so minior work left [16:55] +<pinchartl> :-) +<neg> started on VIN on Gen3, prorted the adv7482 and csi2 from BSP and it + compiles [16:56] +<neg> had a fight with cpg but think I understand it now +<neg> so next is to fix up DT and update rcar-vin to support multiple subdevs + [16:57] +<pinchartl> ok +<pinchartl> do you know how you will do that, or do you need guidance ? + [16:58] +<neg> current problem is to figure out for which subdevice calls i need to use + v4l2_device_call_until_err instead of v4l2_subdev_call but I have not + yet read the code so it might be obvious then +<pinchartl> as you're limited to two subdevices, v4l2_device_call_until_err() + might not be the best choice [16:59] +<pinchartl> at least not for all operations +<pinchartl> some of them will likely need to be called manually +<pinchartl> for things like s_stream you will likely want to control the order + [17:00] +<pinchartl> call s_stream(1) on the CSI-2 receiver first, and then on the + ADV7482 +<pinchartl> as you're limited to two subdevs, and one of them is internal to + the SoC, custom code might be a better option than trying to be + too generic [17:01] +<neg> ok so you think its best not to use a list for subdevs but instead make + explicit struct variables for them since I'm limited to only two? +<pinchartl> I think so, yes [17:02] +<pinchartl> we can revisit that later if needed, if we need to support more + than two subdevices +<neg> ok good input, I was looking at the xilinx driver but I can agree to + that it's a bit over complex for only two subdevs [17:03] +<pinchartl> but I can almost guarantee that any generic code you write now + with two subdevices as the only test case won't be generic enough + :-) +<neg> :) +<pinchartl> it's a very complex problem, let's not try to solve it now +<pinchartl> or even ever, at least until we need to +<neg> ok then I feel I'm on track. Will focus on Gen3 VIN first then CSI2 and + last ADV7482 [17:04] +<pinchartl> perfect +<pinchartl> anything else ? +<neg> nope I think I'm good +<pinchartl> great +<neg> thanks +<pinchartl> next, me [17:05] +<pinchartl> DU,?,plan,laurent,DU+VSPD Integration in Renesas drivers (Gen3) +<pinchartl> DU,?,plan,laurent,IPMMU integration on Gen3 +<pinchartl> DU,?,plan,laurent,IPMMU support on Gen3 (through VSPD+FCP) +<pinchartl> DU,v4.7,public,laurent,VSPD Z-order support upstream (Gen3) +<pinchartl> a large patch series for the VSP driver, needed for DU support, + was accepted upstream [17:06] +<pinchartl> I'll rebase the integration patches and resubmit them +<pinchartl> geertu: if you're here, is the power domain patch on track ? when + do you expect it to be merged ? +<pinchartl> anyway, I'll rebase and resubmit [17:08] +<geertu> pinchartl: I have to integrate the small comments from Ulf, push out + a stable branch for the clock people (who didn't comment so far) that + Simon can pull, too +<pinchartl> geertu: thanks +<pinchartl> when do you expect it to be merged ? +<geertu> pinchartl: After that Simon can apply all of it. I'll do the branch + tomorrow +<geertu> pincahrtl: If everything goes well, the end of the week? (depends on + clock people) [17:09] +<pinchartl> \o/ +<pinchartl> that would be very nice +<pinchartl> regarding IPMMU integration, no progress +<pinchartl> Z-order support is public, I'll send a pull request [17:10] +<morimoto> pinchartl: BSP team is very waiting Request API Test Program. when + can we receive it ? +<pinchartl> morimoto: let me continue going through the list, I'll address + that [17:11] +<pinchartl> VSP,?,plan,laurent,Fixed alpha support (VI6_DPR_*_ROUTE.FXA) +<pinchartl> VSP,?,plan,laurent,UDS regression fix +<pinchartl> VSP,v4.8,plan,laurent,Fix suspend/resume crash +<pinchartl> VSP,?,plan,laurent,CLU WARN_ON fix +<pinchartl> VSP,?,plan,laurent,CLU 2D and 3D mode support +<pinchartl> VSP,?,plan,laurent,CLU/LUT test application +<pinchartl> VSP,?,plan,laurent,CLU/LUT upstream API +<morimoto> ok +<pinchartl> none of that has been started. suspend/resume and CLU are covered + by additional tasks [17:12] +<pinchartl> there's +<pinchartl> VSP,v4.7,public,laurent,CLU/LUT support submitted upstream on Gen3 +<pinchartl> too +<pinchartl> that's also covered by an additional task for June, so it will be + in v4.8, not v4.7 +<pinchartl> VSP,v4.7,public,laurent,Plane alpha + pixel alpha (on Gen3) + [17:13] +<pinchartl> I think that one has been merged, let me check [17:14] +<pinchartl> yes it has [17:15] +<pinchartl> VSP,v4.8,plan,laurent,HGO operation mode selection +<pinchartl> VSP,v4.8,plan,laurent,HGO support upstream on Gen3 +<pinchartl> VSP,v4.8,plan,laurent,HGO test application +<pinchartl> covered by an additional task too, on track +<pinchartl> it could possibly make it early to v4.7, but no guarantee yet at + this point, it will depend on the review process [17:16] +<pinchartl> VSP,?,prototype,laurent,V4L2 request API upstream +<pinchartl> VSP,v4.8,public,laurent,V4L2 request API usable prototype +<pinchartl> the test application I'm using now has already been provided to + Renesas [17:17] +<pinchartl> there's another one in development by Intel +<morimoto> provided to whom ? [17:18] +<pinchartl> they plan to release it but the timing is unclear. it's currently + blocked by paper work, and is expected to be released either at + the end of this month or at mid-May +<pinchartl> let me check who I sent it to +<morimoto> thanks [17:19] +<pinchartl> instructions were sent to +<pinchartl> HARUNOBU KUROKAWA <harunobu.kurokawa.dn@renesas.com> [17:20] +<pinchartl> CC: Takanari Hayama <taki@igel.co.jp>, TOSHIAKI KOMATSU + <toshiaki.komatsu.ud@renesas.com>, Hisao Munakata + <hisao.munakata.vt@renesas.com>, Magnus Damm + <magnus.damm@gmail.com>, Ryu Nagasawa + <ryu.nagasawa.wg@renesas.com>, TOMOHIRO KOMAGATA + <tomohiro.komagata.aj@renesas.com>, Tadahiro Takahashi + <tadahiro.takahashi.jz@renesas.com>, KOJI MATSUOKA + <koji.matsuoka.xm@renesas.com>, KOUEI ABE + <kouei.abe.cp@renesas.com>, NAOYA SHIIBA <naoya.shiiba.nx@ +<pinchartl> "Re: VSP performance enhancements - Documentation" +<pinchartl> 11/02/2016 01:22 +<pinchartl> that uses a modified version of the media-ctl application +<pinchartl> and a modified version of the yavta application +<morimoto> OK, KUROKAWA-san is using this +<morimoto> (He is here now :) +<morimoto> But not yet working correctly [17:21] +<morimoto> (on renesas-driver branch) +<pinchartl> I've rebased all the patches locally +<pinchartl> and will resubmit them to renesas-drivers +<morimoto> thanks +<pinchartl> and of course test them with the procedure I've explained in that + e-mail +<pinchartl> I don't expect a new test application to be used at this point + [17:22] +<pinchartl> I'll fix any issue I find +<pinchartl> kernel side and user space side if needed +<pinchartl> we'll switch to the new test application when it will be available +<pinchartl> but there's no urgency for that +<morimoto> OK, we would like to test it [17:23] +<pinchartl> of course [17:24] +<pinchartl> as soon as it's available I'll try it +<pinchartl> and will then send instructions +<morimoto> thanks +<pinchartl> that's it on my side. any other question ? +<morimoto> when it happen ? +<pinchartl> the release is expected for end of this month or mid-May [17:25] +<pinchartl> (14th of May I believe) +<pinchartl> it depends on the internal paperwork at Intel +<pinchartl> developers need to ask permission to release tools publicly +<morimoto> How about existing test program (?) -> non Intel application ? + [17:26] +<morimoto> can it be more early ? +<pinchartl> the program exists already +<pinchartl> and has been provided, in the e-mail mentioned above [17:27] +<morimoto> Yes. +<pinchartl> as I said, I've rebased the patches, will make sure my test cases + work, and submit them to renesas-drivers +<pinchartl> I don't expect fixes to be needed in user space +<pinchartl> my target is end of this week for that, weekend at the latest + [17:28] +<morimoto> Thanks (from KUROKAWA-san :) [17:29] +<morimoto> Thanks (from me :) +<pinchartl> you're welcome +<pinchartl> apologies for the delay +<pinchartl> (from me :-)) +<morimoto> np +<pinchartl> any other question ? +<morimoto> nothing from me +<pinchartl> ok +<pinchartl> I realized I messed up the alphabetical order by the way, I was + supposed to go before Niklas [17:30] +<pinchartl> sorry about that :-) +<pinchartl> uli___: you're next +<uli___> i thought it was per nick +<uli___> anyway :) +<pinchartl> DU,?,plan,ulrich,Atomic API test program +<pinchartl> DU,v4.7,plan,ulrich,HDMI output on Gen3 prototype +<pinchartl> DU,v4.7,prototype,ulrich,Test setup with HDMI output to HDMI input + loopback (without EDID) +<pinchartl> DU,v4.7,public,ulrich,EDID generation support for the HDMI + loopback test setup +<pinchartl> DU,v4.8,plan,ulrich,HDMI output on Gen3 upstream +<pinchartl> VIN,v4.7,public,ulrich,Add DV timings support to rcar-vin +<pinchartl> VIN,v4.7,public,ulrich,Upstream Lager HDMI input bug fixe [17:31] +<uli___> on vin, i have trouble understanding hans's comment: +<uli___> "this just overwrites the adv7180 input with an HDMI input." +<uli___> https://www.spinics.net/lists/linux-media/msg99554.html +<uli___> i just don't know what he is referring to [17:32] +<pinchartl> I think Hans incorrectly assumes that VIN as both an analog TV + input (through ADV7180) and an HDMI input [17:33] +<pinchartl> can you ask him what he means ? [17:34] +<uli___> just wanted to check if i missed something obvious there +<uli___> can do +<pinchartl> nothing obvious to me at least [17:35] +<uli___> apart from that, i'm currently working on converting adv7511 and + rcar-du to the bridge api +<uli___> for hdmi out on gen3 +<pinchartl> that has been done already +<neg> no I agree with pinchartl it looks like he assumes one VIN instance can + do both +<pinchartl> (not by me) +<pinchartl> see "[PATCH v3 0/7] drm/i2c: adv7511: ADV7533 support" +<pinchartl> I'll try to test it today [17:36] +<pinchartl> http://www.spinics.net/lists/linux-arm-msm/msg19839.html +*** horms_ (~horms@124-171-1-229.dyn.iinet.net.au) has quit: Quit: Leaving +<uli___> good to know... +<pinchartl> I should have told you earlier, sorry [17:37] +<uli___> how about the du side, is there anything public? [17:38] +<pinchartl> "[RFC] drm: rcar-du: Remove i2c slave encoder interface for hdmi + encoder" [17:39] +<pinchartl> I'll rebase that one too +<uli___> iirc, you have mentioned before that the dw-hdmi driver does stuff + that is the reponsibility of the du driver [17:40] +<uli___> is that still the case? +<pinchartl> it's about creation of the connector [17:41] +<pinchartl> I need to check, I don't remember the details, sorry [17:42] +<uli___> ok [17:43] +<uli___> that'd be the next thing on the to-do list +<pinchartl> the idea is that the du driver should create the connector +<pinchartl> but the adv7511 driver, converted to drm_bridge, creates it +<pinchartl> and so does the dw-hdmi driver +<pinchartl> I don't like that +<pinchartl> and have discussed the problem with Archit previously +<pinchartl> I'll need to check what we agreed on [17:44] +<uli___> apart from those, no updates from me +<pinchartl> ok +<pinchartl> that's it for topic 1 then [17:45] +<pinchartl> topic 2, additional tasks +<pinchartl> dammsan: would you like to comment on that ? +<dammsan> uhm, not sure what to say except that stuff has been submitted + [17:49] +<pinchartl> that's already good :-) +<dammsan> i trust that pinchartl has discussed with the members about the + details +<pinchartl> yes we have +<dammsan> for neg and uli we probably need to wait on I/O group tasks +<pinchartl> well, not with Morimoto-san obviously, as he's free from + additional contracts, but with Niklas and Ulrich +<pinchartl> when do you expect that ? [17:50] +<dammsan> i expect wsa to talk to uli and neg about additional i/o tasks +<dammsan> this will happen this week +<dammsan> and we will know more next week +<uli___> dammsan: wsa_ and i have agreed on a task just before +<wsa_> it happens currently :D +<dammsan> my take on all this is that eaach member can chose how much time to + spend on tasks for the various groups [17:51] +<dammsan> i/o and multimedia gets two chances this quarter +<dammsan> while core gets one +<pinchartl> I can see that becoming complex pretty soon +<dammsan> so uli and neg should talk to the different group leaders about how + they want to spend their time [17:52] +<wsa_> may I ask something about that? +<dammsan> sure +<wsa_> the additional contracts have stricter requirements about deliverables + (like the test-setup and the wiki page) +<wsa_> which I understand +<wsa_> that makes choosing how much to work for this or that group not really + flexible, does it? [17:53] +<wsa_> or am I mixing up things? +<dammsan> a bit [17:54] +<dammsan> so each group leader has to figure out what task to allocate + depending on the available amount of time for each guy +<wsa_> yes [17:55] +<dammsan> we have very little time at this point, and with wikis and whatnot +<dammsan> amount of development time is limited +<dammsan> but amount of development time for each guy +<dammsan> is kind of spread out over the groups +<dammsan> for the leaders i assume they spend the majority of the time on + their own group activity [17:56] +<dammsan> but for members like uli and neg +<dammsan> they have tasks for all the groups +<dammsan> which means also additional tasks for all the groups +<dammsan> and how to split the time between the groups is something that i + think each guy can control +<dammsan> by talking with the group leaders +<dammsan> and each group leader needs to encourage people to join his group + too =) [17:57] +<dammsan> neg: pong? +<pinchartl> stupid question, why does base task for all groups imply + additional tasks for all groups ? +<dammsan> pinchartl: for additional task i think we can follow the base + contract to begin with [17:58] +<dammsan> if needed group leaders can extend beyond their own group [17:59] +<dammsan> i think pinchartl is needed in the core group +<dammsan> and i also think that geert is needed by the i/o group +<dammsan> neg: you can chose how you spend your weeks between the groups for + additional tasks [18:00] +<wsa_> he definately is +<dammsan> does that clarify? +<wsa_> for now, i think so [18:01] +<neg> dammsan: ok, but then I might have missunderstod something. I have + talked to pinchartl about additional multimeda tasks that would fill my + allocated time for additnal tasks. Should I have spread the additonal + work also over core and I/O ? +<pinchartl> dammsan: maybe I'm being thick today, but now that additional + tasks for multimedia have been drafted, with an estimation of the + time required to complete them, how can developers choose how to + allocate their time [18:02] +<dammsan> so each guy knows how many weeks in total that are in their current + base task +<dammsan> this is supposed to be 50% of the total time +<wsa_> i think by doing that neg already chose 100% multimedia group :) + [18:03] +<dammsan> the same amount of time as the base task is supposed to be assigned + to the additional tasks +<wsa_> 100% of the additional tasks that is +<geertu> dammsan: aha? +<dammsan> in my understanding neg is only pinned down to 1/3 of his total time + this quarter [18:04] +<dammsan> of course pinchartl wants him to do more stuff there +<dammsan> and i think he is doing good work for multimedia +<dammsan> neg: if you want to spend 100% of your time with multimedia then you + should do that [18:05] +<dammsan> but i advice you to keep good relationship with all group leaders =) +<dammsan> geertu: you and i have not gotten to talk about the core tasks so + much yet +<dammsan> next week [18:06] +<dammsan> still completely unclear? +<dammsan> =) +<pinchartl> dammsan: it sounds a bit like a big matsuri to me :-) +<neg> ofc, I can do work where it is most needed. I only assumed after the + last multimedia meeting during ELC that my additonal tasks for this + quarter was most needed for multimedia +<wsa_> neg: okay, you go work 100% for multimedia, but buy me a drink at the + next conference ;)))) +<pinchartl> neg: that was my assumption too +<neg> wsa_: ofc :-) +<pinchartl> to be honest I really don't like the idea of internal competition + for time allocation +<wsa_> that is even my assumption +<wsa_> i like working with neg, but I don't really have a task for him [18:07] +<dammsan> pinchartl: there is no competition +<dammsan> it is similar to before, each guy gets to tell which group he wants + to work with +<pinchartl> let's see how it will work for this quarter then [18:08] +<dammsan> yes +<dammsan> pinchartl: please note that only the 5/E task for neg is pinned down +<dammsan> i realise more work is needed, but that's always the casee for all + groups when we are resource starved [18:09] +<dammsan> jinzai will contact each member with additional contracts later this + month +<dammsan> if there are more questions then please bring em on [18:10] +<pinchartl> not from me [18:11] +<pinchartl> we should close the meeting. any additional comment anyone ? + [18:12] +<pinchartl> I'll take that as a no [18:13] +<pinchartl> last topic, next meeting [18:14] +<pinchartl> keeping the current schedule, that should be on the 3rd of May +<pinchartl> however, I will be travelling +<dammsan> can we do + or - 1h offset? +<dammsan> my schedule tends to collide with this [18:15] +<dammsan> but you guys seem ok by yourself, so me being semi-present may not + be such a bad idea +<pinchartl> three options: one week early, one week late, or without me +<pinchartl> (I'm sorry about that) +<dammsan> i think you should be present +<dammsan> i'm ok with the other proposals [18:16] +<pinchartl> any preference anyone ? +<uli___> 9am collides with my sleeping schedule, so i'd vote for +1h :) +<uli___> i'm not particular with the date +<neg> +/- 1 Week will collied with the core meeting [18:17] +<pinchartl> we can do another day +<pinchartl> Wednesday for instance +<neg> works for me +<uli___> i would actually prefer to have all meetings in one week as well +<uli___> i mean in the same week +<pinchartl> I don't think we'll have a lot to talk about in a week [18:18] +<pinchartl> so I propose in three weeks +<pinchartl> I'll send an invitation [18:19] +<pinchartl> that's it for today +<pinchartl> thank you everybody +<pinchartl> and have a nice day/evening +<neg> thanks all +<dammsan> thanks [18:20] +<morimoto> bye [18:22] +<uli___> bye +<morimoto> pinchartl: I will put today's log to Redmine, please update + peripelist [18:23] diff --git a/wiki/Chat_log/20160425-io-chatlog b/wiki/Chat_log/20160425-io-chatlog new file mode 100644 index 0000000..bf88336 --- /dev/null +++ b/wiki/Chat_log/20160425-io-chatlog @@ -0,0 +1,256 @@ +--- Log opened Mon Apr 25 09:56:14 2016 +09:56 -!- wsa_ [~wsa@p4FE25E13.dip0.t-ipconnect.de] has joined #periperi-io +09:56 -!- Irssi: #periperi-io: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal] +09:56 -!- Irssi: Join to #periperi-io was synced in 1 secs +09:58 -!- neg [~neg@unaffiliated/neg] has joined #periperi-io +09:58 -!- shimoda [~shimoda@relprex3.renesas.com] has joined #periperi-io +09:59 < shimoda> hi +10:00 -!- horms [~horms@124-171-1-229.dyn.iinet.net.au] has joined #periperi-io +10:00 -!- geertu [~geert@d54C36DF3.access.telenet.be] has joined #periperi-io +10:01 -!- Irssi: #periperi-io: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal] +10:02 < wsa_> hi guys again +10:03 < shimoda> hi +10:03 <@uli___> hi +10:03 < wsa_> i'd like to recap tasks today to see if all is settled after the "additional tasks" change +10:04 < wsa_> and i'd like to do that in alphabetical order +10:04 < wsa_> geert is first +10:04 -!- horms [~horms@124-171-1-229.dyn.iinet.net.au] has left #periperi-io ["Leaving"] +10:04 -!- horms [~horms@124-171-1-229.dyn.iinet.net.au] has joined #periperi-io +10:05 < geertu> I've got SCIF RTS/CTS hardware assisted flow control working. +10:05 < wsa_> so, no io base contract for you but additional task SCIF FIFO flushing for May +10:05 < wsa_> cool +10:06 < wsa_> wasn't that scheduled for June? :) +10:06 < geertu> So far tested on Koelsch with HSCIF and SCIFB. Have to test SCIF on Salvator-X etc. +10:06 < geertu> No, for v4.7 +10:07 < geertu> Yes, June if I wasn't lucky ;-) +10:07 < geertu> Soon after I talked to you last week, I managed to make it work. +10:07 < wsa_> Ah, okay +10:07 < wsa_> so it is this task? +10:07 < wsa_> SCIF,v4.7,public,geert,Extend subsystem with GPIO-based software handling and hardware flow control +10:07 < geertu> Yes +10:08 < geertu> More testing, cleaning up the code, and then it can go out. +10:08 < wsa_> Awesome! +10:08 < wsa_> Then I can remove this: +10:08 < wsa_> SCIF,?,noplan,?,Add support for hardware assisted modem-control +10:08 < geertu> Ah, you did add that one. I've just pulled peripelist, and it wasn't there +10:09 < wsa_> I wanted to wait after this chat before updating +10:09 < geertu> Perhaps keep it as a separate task, it will be the last half of my patch series +10:10 < geertu> In case the serial people have too many comments, the first half (GPIO) can go in separately. +10:10 < wsa_> I see +10:12 < wsa_> but seems we are clear with the tasks assigned? +10:12 -!- Irssi: #periperi-io: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal] +10:13 < geertu> Yes +10:13 < wsa_> good +10:13 < wsa_> next one would be morimoto-san, but he is not here yet +10:14 < wsa_> his main work for IO currently is being one of the Renesas contact guys and supplying documentation :) +10:14 < shimoda> i call morimoto-san now :) +10:14 < wsa_> thanks! +10:14 -!- morimoto [~user@relprex1.renesas.com] has joined #periperi-io +10:14 < wsa_> hi morimoto-san! +10:15 < morimoto> Hi +10:15 < morimoto> sorry for my late +10:15 < wsa_> we are talking about assignments for IO group currently +10:15 < wsa_> and I just said about you: +10:15 < wsa_> his main work for IO currently is being one of the Renesas contact guys and supplying documentation :) +10:15 < wsa_> no worries +10:15 < morimoto> hehe :) +10:16 < wsa_> no seperate tasks assigned currently, right? +10:16 < wsa_> but simon needs SDHI documentation +10:16 < wsa_> I once got a nice ZIP with all Gen2 SDHI docs collected +10:16 < wsa_> it would be great if he could have that, too +10:17 < morimoto> OK, will check +10:17 < morimoto> for Simon +10:17 < wsa_> thanks! +10:18 < wsa_> any news from you? +10:18 < horms> thanks. in particular SCC documentation for gen2 +10:18 < morimoto> Hmm. it seems I already sent SDHI zip file to Simon ? +10:18 < morimoto> 2016/02/25 +10:18 < horms> yes, i have that file +10:19 < morimoto> gr8 +10:19 < horms> but I don't seem to have any SCC documentation in there +10:19 < horms> I can tell you what files are in there if it helps, perhaps via email +10:19 < morimoto> OK, thanks +10:19 < horms> thanks, I'll send you an email +10:20 < wsa_> good +10:20 < wsa_> morimoto: khiem-san is aware of the thermal driver until end of june? +10:21 < morimoto> it seems, but maybe we didn't decided dead-line +10:21 < morimoto> And we will have meeting July timing (= LinuxConJapan) +10:22 < horms> morimoto: email sent +10:22 < morimoto> Thanks +10:22 < wsa_> morimoto: the deadline came from Renesas, if it was changed, please let me know, so i can update my todo +10:25 < wsa_> okay, next one is neg +10:25 < wsa_> you have base contract with 5 days per quarter and will do I2C DMA for this quarter there, right? +10:25 < neg> yes +10:26 < wsa_> and currently no additional tasks for IO but working a lot for multimedia +10:26 < neg> got your mail describing the issue, thanks. Will start to look into it +10:26 < wsa_> good +10:27 < neg> and yes, only additional contracts for multimedia are planed +10:27 < wsa_> so we are clear here, too? +10:28 < wsa_> i guess so +10:29 < wsa_> shimoda-san is next +10:29 < wsa_> Still being our USB hero and also one of the Renesas contact guys, right? :) +10:30 < shimoda> yes :) +10:30 < wsa_> any news with the USB tasks? +10:30 < shimoda> fixing xhci probing issue now +10:31 < shimoda> and I'm working for new OTG framework that made by Roger +10:31 < wsa_> is that planned for 4.8? +10:32 < shimoda> about xhci kconfig, i could make a patch that Geert-san suggested +10:32 < shimoda> wsa_: about OTG, yes, it is for 4.8 +10:33 < wsa_> i'll add this to the todo +10:33 < shimoda> OTG SUBSYS maintainer sent Acked-by in last week. +10:34 < wsa_> ah, so it is already "public"? +10:34 < wsa_> i missed that +10:35 < shimoda> wsa_: not yet, i didn't sent OTG patch for rcar yet +10:35 < wsa_> i see +10:35 < wsa_> prototypeß +10:35 < wsa_> ? +10:35 < shimoda> yes +10:35 < wsa_> good +10:36 < wsa_> thanks +10:37 < wsa_> any more news? +10:37 < wsa_> otherwise simon would be next +10:38 < horms> sounds like its my turn +10:38 < wsa_> yes, so, no base contract for simon, but working on SDR104 for SDHI in May as additional task +10:38 < wsa_> (SDHI task priorities have been quite reshuffled due to the additional tasks) +10:39 < horms> yes, thats right. I hope to make an early start on that one. So far I'm planning to prototype on Gen2 assuming I can get documentation for a Gen2 Soc. +10:39 < horms> There is support for this feature in the BSP, including enabling the SCC which seems to be the core of the task. +10:39 < wsa_> Yes, Gen2 should be prototyped, we still don't have Gen3 DMA support yet +10:39 < wsa_> upstream that is +10:39 < horms> My basic plan is to rework the BSP code and see how far that gets us. +10:40 < horms> I have not looked in enough detail to have any problems yet :) +10:40 < wsa_> i saw some custom DT bindings in there IIRC +10:41 < wsa_> i would wonder if they are really needed or if the mmc core doesn't have a solution for them already somewhere +10:41 < horms> I would also like to mention that Kaneko-san has been working on isolating which BSP v3.2.0 patches look good for upstream. I am encouraging him to discuss individial patches on the periperi ML. Presumably some will relate to IO. +10:41 < horms> thanks. obviously custom bindings are a red flashing light. +10:41 < wsa_> :) +10:42 < horms> possibly the base addr for the SCC needs to be specified in DT +10:42 < wsa_> OK, awaiting Kaneko-sans patches then +10:42 < horms> again, I haven't looked very far yet +10:43 < horms> If there are any priorities for upporting let me know. But more likely we'll be feeding features into your todo list +10:43 < wsa_> yes, i think so, too +10:43 < horms> ok, that was all i had in mind to say +10:43 < horms> perhaps we can move on? +10:44 < wsa_> when is the next BSP release planned BTW? +10:44 < wsa_> would be nice to know +10:44 < horms> there was a release, 3.2.1 very recently +10:44 < horms> like a last week +10:44 < horms> morimoto-san or shimoda-san likely have more insight into the timing of the next release than I +10:44 < neg> there where new code ind the bsp from ~friday I think +10:45 < wsa_> thanks, will check +10:45 < horms> The 3.2.1 release, at a glance, seems to have a lot of M3 related changes +10:45 < geertu> Yeah, CPG and PFC +10:45 < wsa_> uli___ is next +10:45 < geertu> (noticed that earlier this week) +10:47 <@uli___> no additional i/o tasks for me so far +10:47 < wsa_> he has a 5 days/quarter base contract for IO and does CANFD driver review and r8a7740 clock driver refactoring to fix an SDHI regression. The latter one most probably in June. +10:47 < wsa_> and no IO additional tasks in May +10:47 < wsa_> correct? +10:47 <@uli___> yes +10:48 < wsa_> but most likely additional tasks in June (like with geertu and simon, too; not sure about niklas, we will see then) +10:49 < wsa_> uli___: did you have time to check the CANFD driver yet? +10:49 < horms> fwiw i have no insight into my bonus plans in June :) +10:49 <@uli___> on screen now, but haven't looked closely yet +10:49 < wsa_> horms: from what I know, 1 week for IO is planned +10:50 < horms> thanks, good to know :) +10:51 < wsa_> the CANFD driver seems stuck; I hope that additional comments or simply "reviewed-by" tags will get it rolling again +10:51 < wsa_> i don't think it is that bad, it has a few iterations done already +10:52 <@uli___> ramesh asked whether to send a new version 2 weeks ago, to no response +10:52 < horms> possibly the person responsible got re-tasked +10:53 < wsa_> "I can send a next version of patch if we have a closure on current set of comments. +10:53 < horms> ok then perhaps he just needs some feedback +10:53 < wsa_> " +10:53 < wsa_> he said +10:53 < horms> Is there closure? +10:53 < wsa_> uli___: maybe you can agree/disagree to his comments to re-start the procedure +10:54 <@uli___> i can say "please send it, i'd like to have a look"... +10:54 < wsa_> that might work, too +10:54 < wsa_> :) +10:55 < wsa_> unless you see something worth fixing already +10:56 < wsa_> ok, but you are at it +10:56 <@uli___> i am +10:56 < wsa_> so, it is my turn now +10:57 < wsa_> i have a base contract of 5 days/month for IO currently +10:57 < wsa_> this month was nearly completely eaten up by the new task/contract procedures +10:57 < wsa_> i hope this will become better once things settled down +10:58 < geertu> :-) +10:58 < wsa_> my plan is to keep this time for a) group leading and b) spontaneous, important, emergency tasks in the IO sector +10:59 < wsa_> my additional tasks for May are "pre-timeout support for watchdog" and "SDIO support on Gen3 for SDHI" +11:00 < horms> wsa_: do you have any SDIO cards? +11:00 < wsa_> yes +11:00 < horms> great! +11:01 < wsa_> Bluetooth, and serial (GPS) and a wireless one +11:01 < wsa_> sadly the latter is not supported by Linux :( +11:01 < horms> I have one SDIO wifi card that is known to work (in the past at least) with renesas hw. I can lend it to you / let you know the model if that would help. +11:01 < wsa_> i ordered a 802.11ac card to test UHS throughput with SDIO +11:02 < wsa_> but this card is still in prototype stage and I dunno when I'll get it :/ +11:02 < wsa_> horms: that would in deed help +11:03 < horms> ok, great. I probably can't get my hands on the card for about 10 days (because I am not in Japan). Would waiting that long + postage be a problem? +11:03 < wsa_> nope +11:03 < horms> great +11:03 < horms> can you ping me on about the 4th? +11:03 < wsa_> will do +11:03 < horms> great +11:04 < wsa_> so, SDHI tasks about DMA for Gen3 and eMMC support got moved to the back because of the new tasks coming in +11:04 < wsa_> i hope the DMA task for Gen3 can be done in June +11:04 < wsa_> it might become a bottleneck otherwise +11:05 < wsa_> so, that was that +11:06 < wsa_> there seem to be no surprises, so we did well last week, I think :) +11:07 < wsa_> anything else which needs to be shared? +11:08 < neg> I have a question about firmware upgrade, have you all updated your Salvator-X boards? +11:08 < geertu> Not yet +11:08 < geertu> I should +11:08 < wsa_> I haven't +11:09 < horms> I have +11:09 <@uli___> not me +11:09 < wsa_> haha +11:09 < horms> to test cpuhotplug +11:09 < neg> ok, then I hold out a bit longer then untill there is a happy repport that the board won't catch fire :-) +11:09 < horms> it did not catch fire +11:09 < horms> but i am not pushing anyone to upgrade +11:10 < wsa_> so, let's call it a meeting then +11:11 < wsa_> thank you! +11:11 < horms> thanks, have a nice day +11:11 < wsa_> and have a good week +11:11 < neg> also morimoto-san said something about meeting time arund LinuxConJapan is that set? I'm thinking about tickets and other summer planing +11:11 < wsa_> I'll be at LCJ most likely +11:11 < wsa_> I dunno about a meeting +11:11 < wsa_> but would be very interested :) +11:11 < morimoto> Yes, now we are thinking LinuxConJapan + Renesas Meeting + mini-PeriPeriCon +11:12 < morimoto> not yet decidec +11:12 < morimoto> decided +11:12 < geertu> Which parts? I think LinuxConJapan will definitely happen ;-) +11:13 < morimoto> I will send invite email soon. Renesas Meeting is gray +11:13 < morimoto> Maybe 1day mini-PeriPeriCon, 1day Renesas Meeting (if we have) +11:13 < morimoto> And Magnus plan is we will have full PeriPeriCon on Sep (?) +11:14 < neg> morimoto: ok thanks then I hold of buying tickets and other summer planing around LCJ timing +11:14 < morimoto> gr8 +11:14 < wsa_> I'll be in Japan before LCJ +11:14 < wsa_> and fly back directly after LCJ +11:15 < morimoto> Oops, do you already have ticket ? +11:15 < wsa_> yes +11:15 < morimoto> OK +11:15 < wsa_> I need to go to LCJ anyhow because of giving a talk there +11:16 < geertu> Brussels Airport is open again, and the direct flight to/from Narita is no longer diverted to Düsseldorf +11:16 < geertu> wsa_: That's a good reason +11:16 < wsa_> Yes, I need to present the results of a LinuxFoundation contract +11:17 < geertu> IC, as the CFP is still open +11:17 < wsa_> so, no travel costs for Renesas this time, sorry ;) +11:17 < morimoto> wsa_: OK :) +11:18 < geertu> More budget for sake and kobe-beef ;-) +11:18 < wsa_> \o/ +11:18 < wsa_> ok, gotta leave now +11:19 < morimoto> very important budget :) +11:19 < wsa_> i'll update redmine soon +11:19 < morimoto> thanks +11:19 < geertu> bye, thx +11:19 < neg> thanks all +11:19 < shimoda> thanks +11:20 <@uli___> bye +11:20 < morimoto> wsa_: please Redmine log + Redmine IO schedule + PeriPelist git +11:20 <@uli___> morimoto: hardass! :) +11:20 < morimoto> ;P +11:20 < morimoto> Thanks +11:20 < morimoto> bye +11:20 -!- morimoto [~user@relprex1.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +11:20 -!- shimoda [~shimoda@relprex3.renesas.com] has quit Quit: WeeChat 0.4.2 +--- Log closed Mon Apr 25 11:22:32 2016 diff --git a/wiki/Chat_log/20160426-core-chatlog b/wiki/Chat_log/20160426-core-chatlog new file mode 100644 index 0000000..4c81fe5 --- /dev/null +++ b/wiki/Chat_log/20160426-core-chatlog @@ -0,0 +1,254 @@ +Core-chat-meeting-2016-04-26 + +10:05 < geertu> Welcome all to today's Renesas Core Group Chat +10:05 < geertu> Agenda: +10:05 < geertu> 1. Upcoming Gen3 development for the Core group, +10:05 < geertu> 2. Reserved memory for AXI decompression area, +10:05 < geertu> 3. Status check for tasks from last meeting - what is remaining? +10:05 < geertu> Topic 1. Upcoming Gen3 development for the Core group +10:06 < geertu> My R-Car SYSC series has been applied by Simon +10:06 < geertu> I have a few more related commits in my local tree that I'm gonna clean up and send out. +10:08 < khiemnguyen> geertu: any restriction with current SYSC series ? I saw that Morimoto-san reported an issue of Audio driver. +10:09 < geertu> khiem: That was an issue with v4 of the series, which caused probe deferral of the DMA controllers +10:09 < morimoto> does it be solved on v5 ? +10:10 < geertu> Yes, v6 (which was applied) doesn't have this problem +10:10 < morimoto> OK, nice ! +10:10 < horms> I have queued up the changes. We are yet to see if the arm-soc team accepts them. But Arnd seems to be in a good mood this week. So hopefully things will progress smoothly. +10:11 < geertu> Good. +10:11 < geertu> Isn't Arnd ususally in a good mood w.r.t. merging? +10:12 < geertu> I guess Niklas is still waiting for Olof... +10:12 < khiemnguyen> geertu:: have you tested with some drivers using power domain like A3VP ? +10:12 < horms> My feeling is that Olof can be a bit more prickly with regards to merging. +10:12 < geertu> khiem: A3VP is turned on when e.g. reading from /dev/video0 +10:12 < neg> Yes I have not heard anything back from Olof, anyone have a feel of what he is thinking? +10:12 < horms> geertu: it is possible that I worry too much :) +10:12 < pinchartl> khiemnguyen: I've tested power domains with the VSP driver +10:13 < geertu> Probably he doesn't have an answer... +10:13 < geertu> Arnd is much more familiar with DMA +10:13 < horms> neg: perhaps you could ping Arnd somehow? +10:14 < geertu> Arnd definitely knows how the function to retrieve dmas from DT works. +10:14 < neg> horms: sure, I can send a ping to Arnd and ask his opinion on the patches +10:14 < horms> neg: that would be great, thanks +10:15 < neg> There where some comments that it was a bit silly to do it in so many patches, maybe i can squash them as one per SoC and resend and at the same time ask Arnd for his input? +10:15 < horms> Personally I'm fine with many patches. But squashing them as you suggest may make things a bit more managable. +10:16 < neg> I'm fine anyway, I only did lots of patches since it seemed like it was the way it was done in the past +10:17 < horms> possibly that was because patches were done over time. though possibly all applied in a bunch +10:17 < horms> anyway, i don't think the number of patches is the core issue +10:17 < geertu> Maintainer preference about granularity of patches may differ a lot... +10:17 < neg> OK, I will squash and resend +10:18 < horms> this maintainer is ok with that :) +10:18 < geertu> Best ask Arnd first, before squashing and resending +10:19 < neg> OK then I will ping Arnd asking his opinin and if he wants it reposted squashed +10:20 < geertu> Good, thx! +10:23 < neg> I also might have to rethink part of my IPMMU+DMAC parches, Christoph Hellwig have a point I use dma_mapping_error() which uses the debug_dma_* so I might need another way of signaling mapping error +10:23 < pinchartl> or maybe we could make debug_dma_* safe with resource DMA mappings ? +10:24 < neg> That would be a good solution yes +10:25 < neg> Will look into it +10:27 < neg> I was thinkig maybe to add a using check pfn_valid(pfn) and not call debug_dma_* from dma_mapping_error, or is that a bad idea? +10:28 < pinchartl> that seems like a bit of a hack +10:28 < pinchartl> but I don't know what else would be possible +10:30 < pinchartl> how about starting by checking the debug_dma_* call paths, and see which calls can be problematic with resources ? +10:30 < pinchartl> obviously ignoring the ones that can't be used with resources +10:31 < pinchartl> it looks like the core issue is the phys_addr() function +10:32 < pinchartl> if you add a dma_debug_resource type, you could special-case phys_addr() +10:32 < neg> that would be a better solution yes, I will have a look and se if I can figure it out +10:32 < pinchartl> and possibly return (entry->pfn << PAGE_SHIFT) + entry->offset +10:33 < pinchartl> it's just a very rough first analysis, there could be other issues +10:33 < pinchartl> but I think that's at least a good path to investigate +10:34 < neg> I agree, will do +10:36 < pinchartl> geertu: are you asleep ? :-) +10:36 < geertu> No +10:37 < geertu> Just waiting for your discussion to finish +10:37 < geertu> Any other Upcoming Gen3 development? +10:37 < horms> M3 +10:37 < horms> I plan to add basic support for M3, most likely based on what is in BSP v3.2.1, by the end of June. I am yet to make a start on this. +10:37 < geertu> dammsan should have M3 in his board farm soon, IIUC? +10:37 < dammsan> later this week +10:38 < geertu> And I'm gonna do CPG/MSSR and SYSC +10:38 < horms> superb +10:38 < horms> ok, it sounds like we will have to tag-team a bit +10:38 < horms> both for board access +10:38 < horms> and dependencies on each other +10:40 < geertu> Sure. We managed to do that before +10:40 * geertu notices the marzen semaphore in the topic line +10:41 < horms> yes, that may be a stale lock +10:41 < geertu> It's been a while I used the lock. Usually I just look at the marzen power state... +10:42 < geertu> But for M3 we'll have to be more strict again +10:43 < geertu> Any other Upcoming Gen3 development? +10:46 < geertu> Topic 2. Reserved memory for AXI decompression area +10:46 < geertu> shimoda-san: Can you explain a bit, please? +10:46 < shimoda> yes +10:47 < shimoda> Gen3 has specific HW IP in "14. AXI-BUS" +10:48 < shimoda> the IP will decompress memory when software writes data +10:49 < shimoda> So, if a software start the IP, other software (e.g. linux) must not use such area +10:49 < shimoda> about the detail, please look at an email that I sent :) +10:50 < shimoda> and then, I would like to discuss how to manage this on linux kernel +10:50 < geertu> All of this is determined by the firmware, right? +10:50 < shimoda> geertu: right +10:51 < geertu> Then I think the firmware should reserve the memory in the DTB it passes to the kernel +10:52 < shimoda> I see. The latest Gen3 BSP will do so. however, morimoto-san and magnus-san don't prefer it :) +10:53 < geertu> Does the BSP have the reserved area in the DTS, or does the bootloader modify the DTB? +10:53 < shimoda> oops, BSP has a specific DTS, no bootloader modify the DTB +10:53 < shimoda> sorry, I misunderstood your suggestion +10:54 < geertu> I think it's similar to how the bootloader modifies the DTB to pass the bootargs +10:54 < pinchartl> geertu: I agree, if the bootloader reserves memory for firmware usage, it should modify the DTB +10:55 < dammsan> i suspect that different firmware components are responsible for different things +10:55 < dammsan> so IPL may program the AXI +10:55 < dammsan> while U-boot is supposed to modify the DTB if I understand you guys correctly +10:55 < geertu> Yes +10:56 < dammsan> so the problem how to pass base registers between components still exists +10:56 < geertu> True. +10:56 < dammsan> i mean memory window parameters +10:57 < khiemnguyen> so, for upstream kernel, we should disable that feature ? +10:57 < geertu> Well, DT is supposed to describe the hardware +10:57 < geertu> Hence if some memory is unusable, it should say so. +10:57 < khiemnguyen> that feature is optional. +10:58 < geertu> "Non-Secure software (U-Boot/Linux) cannot access these registers" +10:58 < geertu> So as soon as the IPL implements protection, U-Boot/Linux cano no longer find out where the reserved area is? +10:59 < geertu> s/cano/can/ +10:59 < khiemnguyen> in future, we can get the information via OP-TEE call. But it has not been implemented yet. Just planning. +11:00 < morimoto> geertu: can I confirm ? +11:00 < shimoda> khiemnguyen: i see. +11:00 < morimoto> it will be implemented from v2.8.0 firmware. it is not yet implemented on v2.7.0. +11:01 < dammsan> i think we should ask IPL people to program version number in a specific location for read-only use +11:01 -!- khiemnguyen [d2a0fca9@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.169] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] +11:01 < morimoto> Do you mean it can be controlled by u-boot ? +11:01 -!- khiemnguyen [d2a0fca9@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.169] has joined #periperi +11:01 < dammsan> like for instance MFIBTSTSR register +11:01 < geertu> morimoto: confirm what? +11:01 < morimoto> dammsan: it can be 1 solution +11:02 < dammsan> morimoto: yes +11:02 < morimoto> geertu: your opinion is uboot can control it ? (v2.7.0 / v2.8.0 etc) +11:03 < geertu> morimoto: That sounds like the logical place to me. +11:04 < geertu> How uboot obtains the knowledge is another question... +11:04 < morimoto> I wounder does it mean we need updated uboot ? +11:05 < geertu> I think so +11:06 < khiemnguyen> geertu: You want updated uboot to control memory decompress, right ? +11:06 < morimoto> This means, if people has old uboot, but use new kernel, it will... ? +11:06 < geertu> Go bang +11:07 < morimoto> This v2.8.0 firmware will sets its start address and size on specific area. Can kernel use it and reserve ? +11:07 < morimoto> inside kernel. +11:07 < geertu> khiemnguyen: No, if memory decompress is enabled, U-boot should tell the kernel by adding the reserved area to the DTB +11:07 < morimoto> then, old uboot is no issue +11:08 < geertu> If there's a reliable way for the kernel to find out, yes. +11:08 < dammsan> seems we need a short term and a long term solution really +11:08 < dammsan> regardless IPL need to be able to expose functionality +11:09 < dammsan> which may be the same reliable way as geertu is aksing about +11:09 < geertu> Yes. Cfr. " +11:09 < geertu> - Non-Secure software (U-Boot/Linux) cannot access these registers. +11:09 < geertu> - For now, these registers can be accessed from non-secure. (In other words, in the future, an IPL will prevent the registers' access.) +11:09 < geertu> " +11:09 < dammsan> just hoping the components will work together may not be suitable +11:10 < geertu> :-) +11:10 < dammsan> ok that's good +11:10 < geertu> So the BSP has +11:10 < geertu> reserved-memory { +11:10 < geertu> #address-cells = <2>; +11:10 < geertu> #size-cells = <2>; +11:10 < geertu> ranges; +11:10 < geertu> /* device specific region for Lossy Decompression */ +11:10 < geertu> linux,lossy_decompress { +11:10 < geertu> compatible = "shared-dma-pool"; +11:10 < geertu> reusable; +11:10 < geertu> reg = <0x00000000 0x54000000 0x0 0x03000000>; +11:10 < geertu> }; +11:10 < geertu> [...] +11:10 < geertu> }; +11:12 < geertu> Don't know if the "reusable" property is appropriate, as Linux doesn't control the AXI controller? +11:12 < shimoda> also about the default v2.8.0 said: +11:12 < shimoda> NOTICE: BL2: Lossy Decomp areas +11:12 < shimoda> NOTICE: Entry 0: DCMPAREACRAx:0x80000540 DCMPAREACRBx:0x570 +11:12 < shimoda> NOTICE: Entry 1: DCMPAREACRAx:0x40000000 DCMPAREACRBx:0x0 +11:12 < shimoda> NOTICE: Entry 2: DCMPAREACRAx:0x20000000 DCMPAREACRBx:0x0 +11:12 < khiemnguyen> geertu: This is fixed address, IPL v2.8.0 also set memory decompress for that phys address +11:13 < pinchartl> I'm curious though, how/why is the decompression feature used by the secure firmware ? +11:13 < khiemnguyen> shimoda: Currently, only Entry 0 is valid, other Entry are invalid. +11:14 < dammsan> pinchartl: good question +11:14 < shimoda> pinchartl: If my understanding is correct, a reason is "in the future, an IPL will prevent the registers' access" +11:14 < shimoda> by non-secure software. it seems hw design issue :) +11:15 < khiemnguyen> Currently, almost System-level registers are controlled by secure firmware. +11:15 < pinchartl> shimoda: right, but why is image decompression used as a security feature ? +11:16 < pinchartl> the system RAM protection feature is understandably related to security +11:16 < shimoda> pinchartl: no. some "multimedia software" will use it on linux +11:16 < dammsan> pinchartl: i guess no one has figured out how to virtualise the interface +11:16 < pinchartl> ok +11:16 < pinchartl> so the IPL will program it and disable access to the registers +11:16 < pinchartl> but the feature will be used by Linux +11:17 < pinchartl> it's just that the memory area won't be selectable by Linux as the IPL will disable access to the registers +11:17 < pinchartl> correct ? +11:18 < shimoda> pinchartl: correct +11:18 < dammsan> pinchartl: and the area may move in the future +11:19 < geertu> dammsan: If it may move, and that's controlled by The Firmware, The Firmware should inform the kernel. +11:19 < shimoda> by the way, the IPL will writes a magic in some DDR area +11:19 < shimoda> out of linux memory +11:20 < dammsan> geertu: as long as we can handle things during runtime somehow we will be fine +11:21 < geertu> dammsan: Sure, "informing" can be done in several ways. But the means should be fixed rather sooner than later. +11:21 < dammsan> but 3 different components with hard coded windows and DTB dependency seems the wrong way +11:21 < dammsan> geertu: i agree +11:25 < geertu> So more design work to do? +11:25 < geertu> Topic 3. Status check for tasks from last meeting - what is remaining? +11:26 < geertu> "SYSC,v4.7,prototype,geert,R-Car SYSC PM Domain support" is public +11:26 < geertu> I'm re-adding "GPIO-RCAR,?,?,?,Fix Runtime PM with GPIO interrupts (depends on irqchip PM)" +11:26 < geertu> as the previous solution had issues and was reverted +11:27 < khiemnguyen> CPUFreq, I'm composing the patches now. Will try to send early next week. +11:28 < shimoda> about "r8a7795,v4.7,prototype,shimoda,Investigate SYS-DMAC2", it is fixed by IPL v2.8.0 :) +11:28 < horms> khiemnguyen: did you have a chance to ask the fw team about the cpu0 hotplug issue we discussed in the previous edition of this meeting? +11:29 < khiemnguyen> horms: they are very busy with other tasks, follow customer requests. And they put low priority on this item. +11:30 < horms> khiemnguyen: thanks, got it +11:30 < khiemnguyen> In the meantime, I think they focus on M3 support and implement new System Suspend-to-RAM operation mode. +11:31 < geertu> With v270, s2ram no longer fails with an error, but the system suspends, immediately resumes, and afterwards NFS fails (no more interrupts?). +11:32 < geertu> So that's actually a regression, as before trying s2ram didn't make the system unusable. +11:32 < dammsan> i would prefer if bugs were fixed before features were added +11:32 < geertu> True. +11:32 < dammsan> but i'm just a grumpy old man +11:33 < geertu> The same for trying to unplug CPU0: before it failed with an error, now it locks up the system. +11:33 < khiemnguyen> geertu: NFS fails, it seems ethernet driver has not handle s2ram well. +11:33 < geertu> khiemnguyen: That's another possibility. +11:34 < khiemnguyen> I meant suspend/resume callbacks in ethernet driver. +11:34 < dammsan> khiemnguyen: are you aware of any roadmap for firmware features? +11:34 * pinchartl has to run +11:34 < pinchartl> I'm late for my lunch time meeting +11:35 < geertu> pinchartl: Bye, thx for joining! +11:35 < khiemnguyen> dammsan: the roadmap is changing rapidly... +11:36 < dammsan> khiemnguyen: that may cause problems for everyone +11:36 < pinchartl> ping me this afternoon if you have any question for me +11:36 < dammsan> it would be nice to improve the situation somehow +11:37 < khiemnguyen> I think so too. Sometimes, the bottleneck is in secure firmware support. +11:38 < khiemnguyen> We have not encountered this in Gen2, but Gen3 use secure firmware, as universal solution for ARMv8. +11:38 < khiemnguyen> I guess developers for other SoC platform also have same issues. +11:38 < dammsan> must be +11:39 < khiemnguyen> we have to accept it, right ? :) +11:39 < dammsan> i think we have to improve the situation =) +11:39 < dammsan> i wonder if we can arrange some f2f meeting inside renesas to request more clear feature prediction? +11:41 < horms> +1 +11:41 < dammsan> anyway, scope is outside this meeting space +11:41 < dammsan> i think we can build leverage by not merging soem features in upstream and request help from superiors +11:42 < dammsan> so lets keep upstream M3 support minimal please +11:42 < horms> dammsan: lets have a f2f meeting about that :) +11:42 < dammsan> sure +11:43 < geertu> dammsan: One problem is that we didn't do anything for e.g. s2ram. +11:43 < geertu> dammsan: If the firmware advertises it's available, it can be used/ +11:43 < dammsan> geertu: that's fine, its an incremental thing +11:44 < dammsan> we can't opt-out by default? +11:44 < geertu> dammsan: If hot-unplugging cpu0 suddenly locks the system instead of reporting an error, there's nothing we can do in the kernel. +11:44 < geertu> I don't think so. +11:44 < dammsan> that's why we should only enable it when we know it is working +11:44 < geertu> PSCI is enabled by default on arm64. +11:44 < dammsan> right +11:45 < dammsan> if we could retrieve firmware version somehow we could disable certain things during run time +11:46 < geertu> The good news is that restart works now (with v270). +11:47 < geertu> We got flamed by Mark Rutland that it didn't work in v230, as that version was not PSCI-compliant. +11:47 < geertu> But there's nothing the kernel did to make that work or not work. +11:48 < dammsan> it is just the cpu node integration order +11:48 < geertu> "trusted" means "it's something you have to trust" (because you have no choice) +11:48 < dammsan> apart from that nothing i agree +11:49 < dammsan> it would be good to have certain features documented though +11:49 < geertu> Time to conclude? +11:49 < dammsan> sure +11:49 < geertu> Thanks for joining, and CU! +11:50 < horms> bye +11:50 < shimoda> thanks, bye! +11:50 < uli___> bye +11:50 < neg> bye all, thanks +11:50 < dammsan> thanks +11:50 < khiemnguyen> bye diff --git a/wiki/Chat_log/20160510-core-chatlog b/wiki/Chat_log/20160510-core-chatlog new file mode 100644 index 0000000..8199e5c --- /dev/null +++ b/wiki/Chat_log/20160510-core-chatlog @@ -0,0 +1,238 @@ +Core-chat-meeting-2016-05-10 + +10:07 < geertu> Agenda: +10:07 < geertu> 1. Upcoming Gen3 development for the Core group, +10:07 < geertu> 2. Increasing the size of GIC-400 mapped registers +10:07 < geertu> 3. Face-2-face meeting during LinuxCon Japan +10:07 < geertu> 4. Status check for tasks from last meeting - what is remaining? +10:08 < geertu> Topic 1. Upcoming Gen3 development for the Core group +10:08 < geertu> I've posted patches for initial CPG/MSSR support and SYSC PM Domains for r8a7796 +10:08 < geertu> Runs fine on M3-W. +10:09 < geertu> And on H3 ES1.1, FWIW +10:09 < horms> Thanks. I plan to use them as the base for my basic M3-W support. Unfortunately the patches I have put together don't seem to give me a console yet. +10:09 < horms> How did you test the cpg/mssr patch set? +10:09 < geertu> horms: Did you try my topic/gen3-latest branch? +10:09 < horms> No +10:10 < geertu> I have a single patch there that adds the glue to make it work. +10:10 < horms> supurb. thanks! +10:10 < horms> one last question. does earlycon work out of the box or does it need to be enabled somehow? +10:11 < geertu> I assume you can cook basic M3-W patches by extracting pieces from that. +10:11 < geertu> You have to add "earlycon" on the kernel command line +10:11 < horms> ok, thanks. got it +10:11 < geertu> And unfortunately it's not that early as DEBUG_LL on arm32. +10:12 < geertu> Unfortunately we don't have anything better on arm64. +10:12 < horms> i suspected as much (x2~ +10:12 < horms> i'll compare your glue patch to what I have and see what i did wrong +10:12 < geertu> From my first experience with M3-W, things are working smoothly. PSCI is even able to reboot ;-) +10:13 < horms> I guess the hw design is a bit more mature than when we first got H3 +10:13 < geertu> That is without PFC, which may cause us (Uli?) some headaches due to the bus access issue. +10:13 < horms> I was hoping to include PFC support. But probably its best to do that as a second step. +10:14 < geertu> Yeah, I can't send out the HSCIF r8a7796 binding update without PFC and without local access. +10:16 < geertu> I was also happy to see H3ES1.1 works fine with my normal H3 kernel. +10:16 < horms> I got a message from dammsan. He had another appointment which is now finished. He should be here soon. +10:17 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi +10:17 < horms> voila! +10:17 < geertu> Welcome dammsan +10:17 < dammsan> thanks, sorry about the delay. +10:18 < geertu> We've just discussed the noise in your house ;-) +10:18 < dammsan> also, sorry for trouble with the remote access - the cat shut down my house +10:18 < dammsan> but it is up and running now again +10:18 < geertu> You use the cat for remote access (flipping switches and pressing buttons)? Cool! +10:19 < morimoto> Ohh loo-chan ! +10:19 < dammsan> it manages things by itself somehow =) +10:20 < dammsan> 20 vms got powered off =) +10:20 < geertu> Oops. that includes the locally installed tftp servers? +10:20 < dammsan> geertu: so your local tftp setup is probably gone +10:20 < dammsan> yeah - sorry!! +10:20 < dammsan> i restarted but lost state +10:20 < geertu> NP, time to automate the install from my side +10:21 < dammsan> thanks for covering +10:22 < geertu> Any other upcoming Gen3 development for the Core group? +10:23 < dammsan> i guess PFC paper work for ulrich needs to be finalised +10:24 < dammsan> apart from that nothing from my side +10:24 < neg> I would like to do something for the core group within the next month or so :-) +10:24 < uli___> dammsan: from my side, there is no rush, i'll soon be gone, back on the 23rd +10:25 < geertu> neg: DMA? +10:25 < dammsan> uli___: ok, thanks for letting me know. we should finalise all your tasks rather soon then to wrap up 6/E tasks +10:25 < horms> dammsan: uli___: what is the nature of the pfc work? +10:26 < neg> geertu: I sent out refreshed IPMMU+DMAC patches yesterday so I have no task in the pipeline to work on +10:26 < dammsan> uli___: can you talk to the group leaders and decide how to split your remaining time between the groups? +10:26 < uli___> horms: r8a7795 bias support and minimal r8a7796 support +10:26 < uli___> dammsan: i have two core and one multimedia task, so i'm left with one slot +10:27 < uli___> which is supposed to be i/o, i guess +10:27 < horms> uli___: thanks. i will skip doing pfc as part of my basic r8a7796 support +10:29 < dammsan> uli___: can you send an email to me and the group leaders with a list of the additional tasks you have signed for and what is planned as well as what is left? +10:29 < uli___> ok +10:30 < dammsan> thanks +10:30 < dammsan> geertu: do you feel satisfied with the amount of additional slots you got for the core group? +10:30 < geertu> ;-) +10:31 < dammsan> geertu: or would you like to try to steal some time if something is urgent? =) +10:31 < horms> fwiw, i think i have one free slot +10:31 < dammsan> in my mind core group assignment is more or less done (with the exception of uli) +10:31 < dammsan> so the remainer of the slots go to i/o and multimedia +10:32 < dammsan> but we can adjust depending on the need +10:32 < dammsan> horms: i think you have more than one slot left +10:33 < horms> ok, lets talk about that some time +10:33 < dammsan> sure +10:36 < khiemnguyen> up up +10:37 < geertu> Topic 2. Increasing the size of GIC-400 mapped registers +10:37 < geertu> I had a look at the actual register contents earlier this morning +10:37 < geertu> and increasing region 1 and 3 to 128 KiB doesn't make much sense to me (64 KiB is OK). +10:38 < geertu> Region 0 is 1 4 KiB page (16 times aliased in the full 64 KiB block) +10:38 < pinchartl> geertu: didn't Marc explain that the register block is aliased multiple times over a 128kB region ? +10:38 < horms> yes +10:38 < geertu> pinchartl: That's true for region 2 +10:38 < dammsan> geertu: shouldn't xen do whatever magic is needed to make it fit? +10:38 < dammsan> and we are just describing the hardware in DT? +10:39 < horms> dammsan: that is my basic feeling too +10:39 < horms> but it seems that Mark Zyngnier has taken the kernel implementation in a different direction +10:39 < geertu> Region 1 is currently 2 identical 4 KiB pages +10:39 < geertu> Dirk wants to expand it to 128 KiB. +10:40 < geertu> However, the first 64 KiB is just 16 aliases of the first (and second) 4 KiB page +10:40 < geertu> While the second 64 KiB is all zeroes +10:40 < geertu> Region 2 is already 128 KiB, which makes sense, as it's 16 aliased pages + 16 different aliased pages +10:41 < geertu> For region 3, the other one Dirk wants to increase, the situatin is identical to region 1 +10:42 < dammsan> geertu: i recall the gic behaving differently depending on if secure mode is used or not +10:42 < dammsan> there is some bit that can be used to determine which mode is used +10:42 < dammsan> (at least in some version of the gic) +10:42 < horms> It seems to me that at some level ARM decided that this aliasing approach is the solution to allowing hypervisors with 64Kb pages to trap the areas in question +10:42 < geertu> So region 1 and region 2 have 2 all-zero blocks due to non-secure mode? +10:43 < dammsan> geertu: not sure, but it could be so +10:43 < dammsan> feel free to try to convince me to install the old secure mode environment +10:44 < geertu> Then 128 KiB for region 1 and 3 make sense. +10:44 < geertu> And the question is more like why we had 8 KiB there before (copied from Gen2?) +10:45 < geertu> I'll respond to the email thread +10:45 < dammsan> i think it is possible to use the SCIF download mode and enter via JTAG to access secure mode +10:45 < horms> Presumably it was copied either from Gen2 or from the BSP (which may be the same thing) +10:45 < geertu> But if the patch was OK in the first place, why didn't Marc just provide his Acked-by? +10:45 < horms> I think Mark came into the thread pretty lated +10:45 < horms> and the patch itself had disappeared from view by then +10:46 < horms> s/lated/late/ +10:46 < geertu> I checked, and it was still quoted +10:46 < dammsan> so may i ask, the base addresses remain unchanged +10:46 < dammsan> this is just about the size? +10:46 < horms> yes +10:46 < dammsan> ok thanks +10:46 < geertu> dammsan: The driver will adjust the size +10:46 < geertu> dammsan: The driver will adjust the base address +10:47 < dammsan> that would make sense +10:47 < horms> I don't think it would be unreasonable to ask Mark for an Ack. It does seem to be an area he is knoledgable about +10:47 < geertu> The driver needs 2 contiguous 4 KiB blocks +10:47 < geertu> So if 2 64 KiB blocks are given, it uses register base = block base + 60 KiB +10:47 < dammsan> but it could be optimized with 64 KiB blocks +10:48 < geertu> optimized? +10:48 < dammsan> fewer entries in the TLB? +10:48 < geertu> The idea is that the 2 4 KiB register blocks are in different pages +10:48 < geertu> so they can have different protection +10:48 < dammsan> ok ok gotcha, cpu interface and distributor +10:48 < dammsan> never mind me +10:49 < dammsan> makes sense +10:49 < horms> geertu: can you talk to dirk/mark a bit about this? basically I feel it is ok to apply the patch. but I'd rather not live to regret it. +10:50 < geertu> horms: yes, that's what I said I will do +10:50 < horms> excellent, thanks! +10:50 < geertu> Topic 3. Face-2-face meeting during LinuxCon Japan +10:52 < morimoto> Now I'm collecting topics from Renesas member +10:52 < morimoto> Oops, sorry it is for RenesasCon +10:54 < morimoto> I think we can have Mini-PeriCon on 11th, and RenesasCon 12th +10:54 < geertu> I think the topic is about all meetings during that week +10:56 < morimoto> I wounder does Ulich come to Japan ? +10:57 < horms> uli___: ↑ +10:57 < uli___> no, i won't :( +10:58 < morimoto> OK +10:59 < morimoto> I will post collected Renesas side topic to PeriPeriML +10:59 < geertu> OK +11:00 < morimoto> Your side would like to know R-Car business, and each member/group +11:00 < morimoto> is this correct ? +11:01 < geertu> I think so +11:01 < neg> At least I would like that +11:01 < khiemnguyen> Where will we have the meeting ? +11:01 < morimoto> About RenesasCon, I'm planing on Renesas office +11:02 < morimoto> but the conference room is not yet decided +11:02 < pinchartl> on what day would that be ? +11:02 < morimoto> RenesasCon = 12th +11:02 < horms> morimoto: that would be the Musashi-works near Kokubunji? +11:02 < morimoto> Yes +11:03 < horms> Got it +11:03 < morimoto> Because Renesas member will join +11:03 < pinchartl> ok +11:03 < morimoto> We can have different place for MiniPeriCon (?) +11:04 < morimoto> Then, we (= Renesas) would like to know your side current tasks/issue/headache +11:04 < horms> I mainly ask because althouth I know where it is other may not. Its a bit of a distance from e.g. where LinuxCon is being held. They probably need to plan for that. +11:04 < morimoto> Please create something of presentation :) +11:05 < khiemnguyen> each group leader will make presentation ? +11:05 < morimoto> horms: Yes, it is my headache too +11:05 < geertu> It's about one hour from LinuxCon? +11:06 < horms> I am happy to help people find the venue :) +11:06 < horms> geertu: perhaps a little more. +11:07 < horms> google says about an hour, you were right +11:08 * geertu used Google +11:08 < horms> :) +11:08 < neg> have anyone booked hotell? My knowledge about Toky is nil and I don't want to live on the wrong side of the tracks :-) +11:09 < horms> google can help you :) +11:09 < morimoto> Or I can :) +11:09 < morimoto> dammsan: do you have any plan for MiniPeriCon room ? +11:10 < pinchartl> neg: I've booked at the conference hotel +11:10 < horms> morimoto: (off topic) do you know if the BSP meeting on friday is still on? +11:10 < neg> horms: I tried google for Brussels and ended up in a hotel where they probobly are used to charge you by the hour +11:11 < morimoto> horms: for this week 13th? then yes, still ON +11:11 < horms> haha. i can help too +11:11 < horms> morimoto: 了解です +11:11 < dammsan> morimoto: no plan, the library actually just called me and said I owed the the double about of money due to a no-show meeting room =) +11:12 < geertu> pinchartl: it seems to be fully booked by now +11:13 < geertu> neg: Good for you! Usually people don't stay an integer number of 24h-days +11:14 < neg> geertu: :-) +11:15 < horms> fwiw, i usually stay either at the monteray n +11:15 < horms> hanzomon or somewhere in kudanshita for linuxcon +11:15 < horms> partly because that is in between linuxcon and the old renesas office +11:15 < horms> and i'm not affraid of the subway system :) +11:16 < dammsan> i recommend the "la festa kichijouji" hotel for everyone =) +11:17 < morimoto> closed to your home +11:18 < dammsan> you can probably both rest and stay if you want +11:18 < geertu> Doesn't look like it's close to LinuxCon? +11:18 < horms> its close to renesas :) +11:18 < dammsan> its not, i'm not serious +11:19 < horms> Somewhere on the Tozai line might be a good choice. As that can be used to get both to LinuxCon and part way to Renesas +11:19 < geertu> Be careful with such jokes, or we'll all end up in little tubes near Fukushima ;-) +11:19 < dammsan> =) +11:19 < horms> Or Idabashi which is within walking distance of LinuxCon and should connect to the Sobu/Chuo line to head out to Renesas +11:20 < geertu> Idabashi is not a hotel? +11:20 < horms> its an area +11:21 < horms> presumably there are hotels there +11:21 < geertu> horms: OK, I'll ask neg to find a good one over there ;-) +11:21 < horms> i'm unsure if my family will join me or not +11:21 < horms> so i will be holding off on a booking for now +11:22 < neg> geertu: I will find a nice one, how many hours do you need :-) +11:23 < horms> Probably geertu only needs a rest every second day +11:24 < geertu> Topic 4. Status check for tasks from last meeting - what is remaining? +11:25 < geertu> r8a7796 CPG/MSSR and SYSC is public +11:25 < neg> I have pinged Arnd in the thread for the multiple DT DMACs but no reply so far, plan to wait a few more days and ping again +11:26 < geertu> r8a7795 drive-strength support is merged +11:26 < khiemnguyen> I sent out CPUfreq patches. Need feedback. :) +11:26 < geertu> PFC 1.8v switching (for r8a7790) is merged +11:26 < geertu> R-Car SYSC PM Domain support is merged +11:27 < geertu> khiemnguyen: I've sent some feedback +11:27 < horms> geertu: it looks like the above item made it into arm-soc smoothly :) +11:28 < horms> neg: how is the effort to use more than one dma controller going. I'm referring to the patches Olof took exception to +11:29 < neg> horms: as we talked about during last meeting I would try to get Arnds feedback on the same patches but I have failed to get his attention +11:30 < horms> ok +11:30 < pinchartl> I have to go I'm afraid +11:30 < horms> bye +11:30 < morimoto> pinchartl: quick request +11:31 < morimoto> pinchartl: Kurokawa-san is waiting your resonse +11:31 < morimoto> s/resonse/response/ +11:31 < dammsan> morimoto: lets discuss this f2f tomororw +11:31 < morimoto> OK +11:32 < pinchartl> morimoto: I'll reply this afternoon +11:32 < pinchartl> I was away last week +11:32 < morimoto> Thanks +11:32 < pinchartl> and catching up with my e-mails +11:33 < pinchartl> have a nice afternoon/evening +11:34 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] +11:34 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi +11:35 < geertu> I think all topics have been covered. +11:35 < geertu> Or did I miss anything? +11:35 < geertu> pinchartl: Bye! +11:35 < dammsan> geertu: thanks for your help +11:36 < horms> nothing from my side +11:36 < geertu> pinchartl: What happened to git.linuxtv.org? (for todays renesas-drivers)? +11:37 < geertu> OK, thanks for joining, and have a nice day/evening/morning! diff --git a/wiki/Chat_log/20160511-mm-chatlog b/wiki/Chat_log/20160511-mm-chatlog new file mode 100644 index 0000000..2730dfe --- /dev/null +++ b/wiki/Chat_log/20160511-mm-chatlog @@ -0,0 +1,395 @@ +Multimedia-chat-meeting-2016-05-11 + +<neg> morning/evening all [16:54] +<pinchartl> it feels like night +<morimoto> it is 17:00 in Japan [16:55] +<pinchartl> night is when I haven't had enough sleep yet :-) +<neg> with your definition of afternoon I can relate :-) +<uli___> good morning +<pinchartl> :-) +<pinchartl> good morning everybody [16:56] +<pinchartl> Magnus is excused for today +<pinchartl> so we can start +<pinchartl> topics for today [16:57] +<pinchartl> - Topic 1. Status check for the multimedia tasks +<morimoto> 1 question. is it 10:00 CEST in Europe ?? +<pinchartl> yes it is [16:58] +<pinchartl> - Topic 2. Next meeting +<pinchartl> we can also discuss additional tasks for June +<morimoto> OK, pinchartl invite was "10:00 CEST / 18:00 JST" but, "17:00 JST" + seems is correct +<pinchartl> but I believe I've already discussed those tasks with you + individually (well, only with Ulrich and Niklas obviously) +<pinchartl> oops, sorry about that [16:59] +<pinchartl> I'll fix it for the next meeting +<morimoto> No problem :) +<pinchartl> anything else for the agenda ? +<morimoto> About RenesasCon [17:01] +<morimoto> very short topic +<pinchartl> we've briefly discussed that during the core meeting yesterday, if + you have additional information we can talk about it, sure +<morimoto> About multimedia topic [17:02] +<pinchartl> ok +<pinchartl> let's start with Magnus as he's not here :-) +<pinchartl> VIN,?,plan,magnus,IPMMU integration on Gen2 [17:03] +<pinchartl> VIN,?,plan,magnus,IPMMU integration on Gen3 +<pinchartl> VIN,?,plan,magnus,IPMMU support on Gen2 +<pinchartl> VIN,?,plan,magnus,IPMMU support on Gen3 +<pinchartl> I don't believe there has been any progress in that area +<pinchartl> that was easy +<pinchartl> now, in alphabetical order, Morimoto-san +<pinchartl> RSND,2016-06-30,plan,morimoto,DT bindings for HDMI sound +<pinchartl> RSND,2016-06-30,plan,morimoto,dw-hdmi-ahb-audio prototype on Gen3 +<pinchartl> RSND,2016-06-30,plan,morimoto,HDMI SSI prototype on Gen3 +<pinchartl> RSND,2016-06-30,plan,morimoto,HDMI sound Upstream support without + hotplug on Gen2 +<pinchartl> RSND,2016-09-30,plan,morimoto,Hotplug support upstream on Gen3 + [17:04] +<pinchartl> anything to report there ? +<morimoto> OK, I created prototype HDMI sound output +<morimoto> it start works ! +<pinchartl> nice ! +<morimoto> but, it is using existing DT binding +<morimoto> and super local HDMI sound coding +<morimoto> My headacke is that how to solve DT things [17:05] +<morimoto> And +<pinchartl> (DT is a pretty popular headache) +<morimoto> yes +<morimoto> this is based on Ulrich's HDMI out prototype +<morimoto> but his prototype is maybe based on BSP (?) [17:06] +<morimoto> becasuse of this +<morimoto> my sound is prototype of prototype +<pinchartl> :-) +<morimoto> HDMI DT itself is very specical +<pinchartl> that's understandable +<morimoto> this is current my status [17:07] +<pinchartl> does that cover "HDMI sound Upstream support without hotplug on + Gen2" too ? +<morimoto> not Gen2 [17:08] +<morimoto> only Gen3 +<morimoto> HDMI Gen2 was working, and some other guy posted its driver +<morimoto> driver patch +<morimoto> sorry, again +<morimoto> HDMI Gen2 was working on my dest, but I didn't posted it to ML +<morimoto> because of DT +<pinchartl> ok [17:09] +<morimoto> but some other guy posted its driver patch to ML +<morimoto> but it is not yet accepted, because of DT +<morimoto> Yes, DT is bottleneck +<pinchartl> that's ADV7511, right ? +<morimoto> I forgot detail number but yes, ADV7xxx [17:10] +<pinchartl> ok +<pinchartl> then, Niklas +<pinchartl> let's start with the v4.7 tasks [17:11] +<pinchartl> ADV7482,v4.7,plan,niklas,Prototype on Gen3 +<pinchartl> VIN,v4.7,plan,niklas,CSI2 prototype (Gen3) +<pinchartl> VIN,v4.7,public,niklas,New VIN driver without soc-camera (tested + on Gen2) +<pinchartl> and then we'll have +<pinchartl> ADV7482,v4.8,plan,niklas,Gen3 support upstream +<pinchartl> ADV7482,v4.8,plan,niklas,Interlace support upstream +<pinchartl> VIN,v4.8,plan,niklas,CSI2 interlace support upstream (Gen3) +<pinchartl> VIN,v4.8,plan,niklas,CSI2 support upstream (Gen3) +<pinchartl> VIN,v4.8,plan,niklas,Gen3 support upstream (without CSI-2) +<pinchartl> and finally +<pinchartl> VIN,?,plan,niklas,Gen3 support +<pinchartl> VIN,?,plan,niklas,Scaler support (on Gen3) +<pinchartl> anything to report ? +<neg> Gen2 driver is accepted by Hans and pull request is sent for media_tree + but I have not yet seen it picked up there [17:12] +<neg> basic prototype of VIN on Gen3 with CSI2 and ADV7482 from BSP is working +<pinchartl> good news ! [17:13] +<pinchartl> Mauro usually takes a couple of days to handle pull requests +<neg> now that we have agreed an a design plan for VIN on Gen3 I can start + focusing on that +<neg> plan is to have that done by end of may [17:14] +<pinchartl> have you posted the prototype code ? +<neg> no and there I have a question, what repository should I try to target + for the full prototype that migh contiain some local hacks for CSI2 and + ADV7482 ? [17:15] +<pinchartl> (it doesn't have to be patches, a mail to linux-renesas-soc with a + link to a git branch is fine) +<pinchartl> I'm not sure to understand the question [17:16] +<pinchartl> do you mean what you should use as a base ? +<neg> the additional contract for VIN on Gen3 stats code should be avaliable + for easy testing from a repository, since parts of the prototype will + need not yeat ready BSP code I'm not sure where I should try to get it + public [17:17] +<pinchartl> it should be publicly available, but it doesn't have to be merged + in an upstream repository +<pinchartl> do you have a personal git tree somewhere ? [17:18] +<neg> yes, is that good enough? [17:19] +<pinchartl> for prototype code, sure +<pinchartl> but make sure you keep the branch there until the code is merged + upstream +<neg> then I'm happy, will make the hack prototye availabe there and keep it + updated with my progress [17:20] +<pinchartl> please let me know when you post the code, I'll update the tasks + status [17:21] +<neg> will do, keep in mind that the prototype is a hack not contaning the + design we talked about in our mail thread [17:22] +<pinchartl> sure +<pinchartl> so next step is VIN Gen3 for end of May, right ? +<neg> yes +<pinchartl> remind me, that includes CSI-2 but not ADV7482 ? [17:23] +<neg> No CSI2 is not mandatory but yes it will requier me to work on the CSI2 + parts anyhow [17:24] +<pinchartl> ok +<neg> I think csi2 would be a separat task just like adv7482 +<pinchartl> it makes sense [17:25] +<pinchartl> so [17:26] +<pinchartl> the existing tasks are +<pinchartl> ADV7482,v4.8,plan,niklas,Gen3 support upstream +<pinchartl> ADV7482,v4.8,plan,niklas,Interlace support upstream +<pinchartl> VIN,v4.8,plan,niklas,CSI2 interlace support upstream (Gen3) +<pinchartl> VIN,v4.8,plan,niklas,CSI2 support upstream (Gen3) +<pinchartl> VIN,v4.8,plan,niklas,Gen3 support upstream (without CSI-2) +<pinchartl> VIN,?,plan,niklas,Gen3 support +<pinchartl> VIN,?,plan,niklas,Scaler support (on Gen3) +<pinchartl> we need to adjust that +<pinchartl> "VIN Gen3 support" is for end of May +<pinchartl> I'll set it to v4.7 as it doesn't have to be merged upstream + [17:27] +<neg> sounds about right yes +<pinchartl> scaler support isn't scheduled yet +<pinchartl> but that's support to be part of the base contract [17:28] +<neg> no and I don't think it will requier so much work so I'm hoping to do + that in my base contract during Q3 +<pinchartl> should I tentatively schedule it for v4.8 ? +<neg> sure [17:29] +<pinchartl> do you think the schedule will hold for the v4.8 tasks ? [17:30] +<neg> not sure about the problem set for interlace but other then that yes + [17:31] +<pinchartl> they're all about upstream [17:32] +<pinchartl> so v4.8 means merged in Mauro's tree at the end of the v4.7 + development cycle +<pinchartl> which is end of this quarter +<neg> hum then no it might be a bit steap giving the phase VIN for Gen2 moved +<pinchartl> I'll move them all to v4.9 [17:33] +<neg> yes I think that is better [17:34] +<pinchartl> next, Ulrich +<pinchartl> DU,?,plan,ulrich,Atomic API test program +<pinchartl> DU,v4.7,plan,ulrich,HDMI output on Gen3 prototype +<pinchartl> DU,v4.7,prototype,ulrich,Test setup with HDMI output to HDMI input + loopback (without EDID) +<pinchartl> DU,v4.7,public,ulrich,EDID generation support for the HDMI + loopback test setup +<pinchartl> DU,v4.8,plan,ulrich,HDMI output on Gen3 upstream +<pinchartl> VIN,v4.7,public,ulrich,Add DV timings support to rcar-vin +<pinchartl> VIN,v4.7,public,ulrich,Upstream Lager HDMI input bug fixes +<uli___> for dv timings for rcar-vin, i have a new series to post today + [17:35] +<uli___> adapted to rcar-vin v6 +<pinchartl> for Niklas' new rcar-vin driver ? +<uli___> yes +<pinchartl> nice +<uli___> and i have a 12-hour old prototype of hdmi out on gen3 +<uli___> that works +<pinchartl> :-) [17:36] +<uli___> but takes a few shortcuts :) +<pinchartl> congratulations +<uli___> it's based on the bridge-API-converted du driver +<pinchartl> I'll move dv-timings to v4.8 then, as the v4.7 merge window is + about to open. if we can make it to v4.7 it would be nice so + please try if possible +<uli___> i'll do my best [17:37] +<pinchartl> thank you +<pinchartl> have you posted the HDMI output prototype already ? +<uli___> not yet. i can send whatever i have right now to periperi, it may + help morimoto-san +<pinchartl> please do [17:38] +<uli___> i'll be on vacation in another 12 hours or so :) +<pinchartl> and let me know when it will be done, I'll update the task +<pinchartl> :-) +<pinchartl> when will you come back ? +<uli___> i'll be back in full force on the 23rd +<morimoto> uli___: does it measn it have no issue on HDMI1-OUT ? +<uli___> moment +<uli___> no, i'm using hdmi1 :) [17:39] +<morimoto> OK, nice. and base on which branch ? +<uli___> i have to look that up, i'll tell you [17:40] +<morimoto> OK, thanks ! +<morimoto> I need to update HDMI sound :) +<pinchartl> no progress yet on the test program I suppose ? +<uli___> none yet +<pinchartl> ok [17:41] +<pinchartl> regarding Gen3 HDMI support upstream, do you think v4.8 is + feasible ? +<uli___> that would be end of the quarter? +<pinchartl> yes +<pinchartl> or will you need more time to clean up the local hacks used in the + prototype ? [17:42] +<uli___> _might_ work +<pinchartl> ok +<pinchartl> and about +<pinchartl> - DU,v4.7,prototype,ulrich,Test setup with HDMI output to HDMI + input loopback (without EDID) +<pinchartl> - DU,v4.7,public,ulrich,EDID generation support for the HDMI + loopback test setup +<pinchartl> please document the setup in the elinux wiki [17:43] +<uli___> ok +<pinchartl> I want to mark those tasks as complete, they've been there for + quite some time and there isn't too much left to do +<uli___> the edid generation actually works, it's part of the patch series + [17:44] +<uli___> even though hans has a mild dislike for it +<pinchartl> the series you will repost today rebased on rcar-vin v6 ? +<uli___> yes +<pinchartl> ok, I'll then have a look at it [17:45] +<pinchartl> and finally, what about +<pinchartl> - VIN,v4.7,public,ulrich,Upstream Lager HDMI input bug fixes +<geertu> uli___: If you post the HDMI output prototype to periperi, I can + include it in next renesas-drivers (that's gonna be next week, v4.6) +<neg> me too, I got a new setup just to test hdmi in :) +<uli___> pinchartl: i have trouble remembering what this is about... +<pinchartl> (geertu: on a side note, I'll also have vsp1 code for the next + renesas-drivers) [17:46] +<pinchartl> I think that was the adv7604 driver fixes +<uli___> that has made it upstream, i think [17:47] +<uli___> "[media] adv7604: fix SPA register location for ADV7612" +<geertu> (pinchartl: If you add it to drm/du/vsp1-kms/boards, it'll be in) +<pinchartl> uli___: perfect, thanks [17:48] +<pinchartl> (geertu: I'll split it in topic branches as you requested :-) and + will let you know) +<pinchartl> now it's my turn [17:49] +<pinchartl> DU,?,plan,laurent,DU+VSPD Integration in Renesas drivers (Gen3) +<pinchartl> DU,?,plan,laurent,IPMMU integration on Gen3 +<pinchartl> DU,?,plan,laurent,IPMMU support on Gen3 (through VSPD+FCP) +<pinchartl> DU,v4.7,public,laurent,VSPD Z-order support upstream (Gen3) +<geertu> (pinchartl: Even better ;-) +<pinchartl> VSPD Z-order support is ready, I'll send a pull request today + [17:51] +<pinchartl> DU+VSPD integration should already be in renesas-drivers +<pinchartl> no progress on IPMMU integration +<pinchartl> then, on the VSP side [17:53] +<pinchartl> - VSP,v4.8,plan,laurent,HGO operation mode selection [17:54] +<pinchartl> - VSP,v4.8,plan,laurent,HGO support upstream on Gen3 +<pinchartl> - VSP,v4.8,plan,laurent,HGO test application +<pinchartl> patches will be posted today +<pinchartl> the schedule holds +<pinchartl> although discussions about the API showed some disagreements + [17:55] +<pinchartl> but nothing too big so far +<pinchartl> - VSP,v4.8,plan,laurent,Fix suspend/resume crash [17:56] +<pinchartl> - VSP,v4.8,public,laurent,CLU/LUT support submitted upstream on + Gen3 +<pinchartl> no progress so far +<pinchartl> - VSP,?,plan,laurent,Fixed alpha support (VI6_DPR_*_ROUTE.FXA) +<pinchartl> - VSP,?,plan,laurent,CLU WARN_ON fix +<pinchartl> - VSP,?,plan,laurent,CLU 2D and 3D mode support +<pinchartl> - VSP,?,plan,laurent,CLU/LUT test application +<pinchartl> - VSP,?,plan,laurent,CLU/LUT upstream API +<pinchartl> - VSP,?,plan,laurent,UDS regression fix +<pinchartl> no progress so far either +<pinchartl> - VSP,v4.8,public,laurent,V4L2 request API usable prototype + [17:57] +<pinchartl> this is becoming the hot topic for VSP development +<pinchartl> now that I've completed HGO I can focus on it again +<pinchartl> other developers started showing interest, in particular Sakari + Ailus posted a new version of my patch series last week with + additional improvements [17:58] +<pinchartl> I plan to post a new version myself over the weekend +<pinchartl> the scheduled date to finalize this is end of this month +<horms> geertu: I'm finished with the M3 board now. Sorry for not letting you + know I was using it earlier +<pinchartl> morimoto: you were interested in additional information about the + request API, does this answer your questions ? [18:00] +<morimoto> our side would like to test it, not additional information :) +<morimoto> of course it is very nice information for us [18:01] +*** khiemnguyen (d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168) + has quit: Quit: http://www.kiwiirc.com/ - A hand crafted IRC client +<pinchartl> :-) +*** khiemnguyen (d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168) + has joined channel #periperi +<pinchartl> that's it for the existing tasks then +<pinchartl> ah no [18:02] +<pinchartl> FDP,v4.8,plan,laurent,Develop and upstream driver +<pinchartl> Kieran is working on this +<kbingham> Ack! +<pinchartl> I've received the new salvator-x board yesterday, DHL should pick + it up today +<pinchartl> v4.8 might be a bit tight, but it can still be doable [18:03] +<pinchartl> depending on the amount of changes requested during review +<morimoto> salvator-x yesterday ? very delay... +<kbingham> indeed I am currently 'virtually' working on it :) +<pinchartl> as it's a mem-to-mem driver I don't expect lots of push back +<pinchartl> morimoto: they wanted to deliver it on the first day after I left + Finland :-/ +<pinchartl> I only came back home last Saturday [18:04] +<morimoto> Ahh, OK +<pinchartl> and for some reason they didn't try to deliver it on Monday +*** horms (~horms@reginn.isobedori.kobe.vergenet.net) has quit: Ping timeout: + 276 seconds +<morimoto> It seems Europe has GW too :) +<pinchartl> the board arrived in Helsinki on the 22nd, I left Finland on the + 27th +<pinchartl> so, that's it for the tasks [18:05] +<pinchartl> Topic 2. Additional '50%' tasks [18:06] +<pinchartl> we've discussed the tasks for June previously +<pinchartl> I'll submit them to Magnus today +<pinchartl> unchanged compared to our last discussions on the topic +<pinchartl> any question or comment about that ? +<uli___> go right ahead [18:07] +<neg> not from me +<pinchartl> easy :-) +<pinchartl> Topic 3. RenesasCon +<pinchartl> morimoto: would you like to talk about that ? +<morimoto> Renesas side would like to discuss, and share information about + MultiMedia things. +<morimoto> BSP team who need to deliver MultiMedia items to customer will have + presentation about their plan. [18:08] +<morimoto> I guess Laurent/Kieran/Niklas related to this ? +<morimoto> not sure +<morimoto> if you have any comment, question, etc. please prepare about it +<pinchartl> uli___: you won't be in Japan, right ? +<uli___> no +<pinchartl> neg: will you be there ? +<pinchartl> kbingham: how about you, any plan to attend LinuxCon Japan ? :-) + [18:09] +* kbingham checks when LinuxCon Japan is... +<morimoto> kbingham: July 13th - 15th +<pinchartl> the meeting with Renesas will be on the 12th +<neg> yes I booked the trip yesterday will arive the 10th and stay untill the + 16th +<kbingham> pinchartl: morimoto: I would love to - but it is rather close to my + wedding, and I may find my self in trouble if I'm the other side of + the world ;) [18:10] +<pinchartl> kbingham: we will celebrate your wedding drinking nihonshu then + :-) [18:11] +<morimoto> kbingham: congratulation about wedding ! +<kbingham> pinchartl: I hope so :) [18:12] +<kbingham> morimoto: Thankyou :) +<morimoto> OK, pinchartl and neg can be Japan +<pinchartl> ok, I'll prepare a presentation about our status, short term and + longer term plans for the meeting in Japan then. I'll submit it as + a discussion topic for one of the renesas multimedia group chats + before LCJ +<morimoto> pinchartl: Thanks +<pinchartl> last topic, next meeting [18:13] +<neg> I also booked all nights at the LCJ hotell, hope it is possible to get + to Renesas from there? +<pinchartl> I propose two weeks from now +<pinchartl> 25th of May +<pinchartl> same place, same time +<pinchartl> neg: it's a bit of a commute, but it's possible :-) +<morimoto> same time means 17:00 JST ? :) [18:14] +<pinchartl> morimoto: yes +<pinchartl> 10 CEST +<morimoto> OK +<morimoto> I'm OK [18:15] +<pinchartl> uli___ and neg ? +<uli___> ok for me +<pinchartl> and kbingham ? +<neg> OK +<kbingham> pinchartl: Ok by me! [18:16] +<pinchartl> kbingham: it will be a good occasion to report your progress on + the FDP driver, and congratulate the Renesas hardware engineers + for the amazing hardware design (or share your frustration and + find a shoulder to cry on) :-) +<pinchartl> ok, that's it for today then [18:17] +<pinchartl> thank you all for attending +<pinchartl> and keep the good work +<pinchartl> looking forward to more patch bombs in my inbox +<morimoto> Hehe :) thank you. bye [18:18] +<uli___> have a good day +<neg> thanks all, bye diff --git a/wiki/Chat_log/20160519-io-chatlog b/wiki/Chat_log/20160519-io-chatlog new file mode 100644 index 0000000..4e181a4 --- /dev/null +++ b/wiki/Chat_log/20160519-io-chatlog @@ -0,0 +1,207 @@ +--- Log opened Thu May 19 09:59:57 2016 +09:59 -!- wsa_ [~wsa@dslb-178-008-079-154.178.008.pools.vodafone-ip.de] has joined #periperi-io +09:59 -!- Irssi: #periperi-io: Total of 5 nicks [1 ops, 0 halfops, 0 voices, 4 normal] +09:59 -!- Irssi: Join to #periperi-io was synced in 1 secs +10:00 < wsa_> hiya +10:00 < shimoda> hi +10:00 <@neg> hello +10:00 < wsa_> nice to see you all despite having forgotten the reminder mail +10:00 < wsa_> :) +10:01 < horms> hi +10:01 < geertu> hi +10:02 < wsa_> so, let's start the meeting +10:02 < wsa_> i'd like to start with status updates per person +10:02 < wsa_> driven by an honest sort -R (random) +10:03 < wsa_> ;) +10:03 < wsa_> shimoda: you are first +10:03 < wsa_> what is new on your side? +10:03 < shimoda> wsa_: yes +10:04 < shimoda> about USBPHY,v4.7,public,shimoda,add extcon support, it is merged +10:04 < wsa_> great! +10:05 < shimoda> into linux-phy , next branch +10:05 < shimoda> so, perhaps it is merged in v4.7 linus branch +10:06 < wsa_> let's hope so +10:06 < shimoda> about other 2 tasks (usb3-host and USBPHY OTG support), no update +10:07 < wsa_> ok +10:07 < shimoda> and now, I'm investigate IPMMU + USB2.0 issue +10:07 < shimoda> on Gen3 +10:07 < shimoda> other devices (xhci and ohci) seem work correctly, but ehci doesn't work... +10:08 < wsa_> is this a new task? +10:08 < shimoda> yes, it is a new task +10:08 < wsa_> USB2-Host,v4.8,plan,shimoda,IPMMU issues on Gen +10:09 < wsa_> USB2-Host,v4.8,plan,shimoda,IPMMU issues on Gen3 +10:09 < shimoda> yes, thanks! +10:09 < shimoda> about i/o, these are my current status +10:10 < wsa_> thank you! +10:10 < wsa_> I'm next +10:10 < wsa_> about the SDIO task: +10:10 < wsa_> somehow done since I got the KS7010 card working here +10:11 < wsa_> however, without the card this cannot be reproduced in Japan :( +10:11 < shimoda> great! +10:11 < wsa_> Magnus has set up 2 other cards remotely for me +10:11 < wsa_> i will check them +10:12 < shimoda> yes... but to avoid export paper work, i don't want to get the card from you :) +10:12 < shimoda> sorry. I forgot to reply on your email +10:12 < wsa_> however, if there are WLAN driver issues, there is no time to debug those... +10:13 < wsa_> OK. I will bring one in July and then we can talk what to do with it +10:13 < wsa_> skipping paperwork +10:13 < shimoda> I also tried to a sdio card that Magnus-san has (mwifiex / 88W8887), it doesn't work correctly. +10:14 < wsa_> there might be a follow-up task SDIO+UHS, but we need to discuss that +10:14 < shimoda> JFYI, the card also doesn't work correctly on gen2 bsp :) +10:14 < wsa_> and we should have one WIFI card specified for that, surely +10:14 < wsa_> shimoda: thanks, that is interesting +10:14 < wsa_> BTW the KS7010 cards do NOT work on Gen2 :( +10:15 < wsa_> looks like interrupt delivery problems +10:15 < horms> i think the gen2 bsp or at least the ltsi it is based on was tested with the sdio card that I have at some point. But it was a long time ago so I don't recall the details. +10:16 < wsa_> i think we should play some SDIO card game in Japan +10:16 < horms> ok +10:16 < horms> i'm happy to loan my card to the cause +10:16 < horms> Jinso have or at least had the same card +10:16 < wsa_> thanks +10:16 < wsa_> that sounds likely ;) +10:16 < horms> I'm pretty sure I arranged for them to order some +10:17 < horms> back in the day +10:17 < horms> ... +10:17 < wsa_> they are hard to get today +10:17 < horms> probably +10:18 < wsa_> so, despite the KS7010 working fine on Gen3, I guess SDIO topics will be around for some more time +10:18 < wsa_> my other task is watchdog pretimeout support +10:18 < wsa_> I picked up the old patches +10:18 < wsa_> and am currently simplifying them +10:19 < horms> n.b. possibly one of the cards magnus has made available to you is the same as the one I have +10:19 < wsa_> watchdog core has significantly changed, so they don't work as is +10:19 < wsa_> horms: i think so +10:20 < wsa_> horms: but for debugging, a real card may be the solution +10:20 < horms> i can post mine if the need arises, just let me know :) +10:20 < wsa_> so i remove the IMO over-engineered parts from the pretimeout patches +10:21 < wsa_> i hope it makes them easier to be applied upstream +10:21 < wsa_> horms: thanks +10:22 < wsa_> other than that: basic SDHI maintenance +10:22 < wsa_> not much more +10:22 < wsa_> lots of time spending on designing additional tasks and doing additional reviews +10:22 < wsa_> that's from my side +10:23 < wsa_> geertu: your turn now +10:23 < horms> wsa_: I send you an email about task:i2c did you see it? If its pending thats fine. +10:23 < geertu> SCIF,v4.7,public,geert,Extend subsystem with GPIO-based software handling and hardware flow control +10:23 < geertu> I've sent v2 +10:23 < geertu> which received some acks +10:23 < geertu> and a question, which I refuted. +10:23 < geertu> Will resend with the acks after the merge window has closed. +10:24 < geertu> SCIF,v4.8,plan,geert,SCIF FIFO flushing +10:24 < geertu> I'm currently working on that one +10:24 < wsa_> any new insights? +10:25 < wsa_> or still data collection phase? +10:25 < geertu> Data collection phase ;-) +10:26 < geertu> That's it from my side +10:27 < wsa_> ok, thanks +10:27 < wsa_> horms: your updates? +10:28 < horms> sure +10:28 < horms> I have been working on adding sdr104 support to sdhi +10:28 < horms> I posted an initial patch set, based on what is present in the BSP +10:28 < horms> It recieved review from many of the people present here: thanks for that +10:29 < horms> I've significantly reworked things accordingly +10:29 < horms> And things look better +10:29 < wsa_> cool +10:29 < horms> Currently I'm seeing some timeouts which may be related somehow +10:29 < horms> I'm also unsure of how exactly to handle that different sdhi blocks present support different speeds +10:30 < horms> Probably that can bet discussed after i post v2 +10:30 < horms> Lastly, I'm not entirely convinced that the tuning actually does anything with regards to improving throughput +10:30 < horms> this may be because its not being performed correctly. +10:30 < wsa_> did you get more information about this undocumented SCC clock? +10:30 < horms> e.g. the BSP implementation does not seem to reflect the spec with respect to selecting a tap +10:31 < horms> no, that slipped my mind +10:31 < horms> In short, I'm working towards v2 but there are a few loose ends +10:32 < wsa_> do you have time left for this task after v2? +10:32 < horms> I expect to have time for v3 :) +10:32 < wsa_> great +10:32 < horms> But perhaps not the DMA investigation you were hoping for +10:32 < wsa_> i anticipated that +10:32 < wsa_> let's make sure to get the prototype proper +10:33 < horms> I anticipate v3 may spill over into next month, techincally after the deadline +10:33 < wsa_> the issue about selecting tap sounds interesting +10:33 < horms> hopefully that won't be a problem +10:33 < horms> Right +10:33 < horms> so if you look at the SCC document (which you have iirc) +10:33 < horms> it says to select the tap when 3 successive tests succede +10:33 < horms> not so complex +10:34 < horms> I implemented that +10:34 < wsa_> well, I assume V2 will qualify as prototype for the report +10:34 < horms> the BSP does something else +10:34 < horms> wsa_: yes, that is my assumption too +10:35 < wsa_> and besides that I still think we have DMA throughput problems :) +10:35 < horms> I believe there will be several unsolved issues :) +10:35 < wsa_> SDR50 doesn't need tuning and is already not as fast as I'd like +10:35 < horms> Or loose ends if you prefer +10:35 < horms> Fyi I think tuning has to not be done on the sdhi for SDR50 +10:36 < wsa_> so I don't expect SDR104 to have huge gains because of that +10:36 < horms> right +10:36 < wsa_> but SDR104 was a priority for this month +10:36 < horms> as i mentioned to you elsewhere I can get 40Mbit/s +10:36 < horms> or slightly less +10:36 < horms> I tried a few different cards +10:36 < horms> their speeds vary +10:36 < horms> but that is the best one, the sandisk one +10:37 < wsa_> same here +10:37 < horms> (I boght some more cards after the last time we spoke about this) +10:37 < wsa_> should complain to samsung somewhen +10:37 < horms> I can +10:37 < horms> but perhaps there are better things to spend time on +10:37 < wsa_> that may be true +10:37 < horms> the most expensive card performed the worst, btw +10:37 < wsa_> ;) +10:38 < wsa_> ok, looking forward to v2 +10:38 < horms> thats probably all from my side +10:38 < horms> I hoped to have it out for this meeting +10:38 < horms> but no such luck +10:39 < wsa_> horms: can we chat a little after this meeting about the next additional tasks? +10:39 < horms> sure +10:39 < wsa_> thanks +10:40 < wsa_> so, neg is next +10:40 <@neg> Gen3 I2C DMA support is public +10:40 < horms> neg: is that the patch I applied? +10:40 <@neg> yes thats the DT part of it +10:41 < horms> ok +10:41 <@neg> and I think wsa_ have picked up the driver patch +10:41 < wsa_> yes +10:41 <@neg> and I just sentout a incremental patch adressing Arnds comment on the driver +10:41 < wsa_> it is marked "merged" in the todo file :) +10:42 <@neg> so I hope that is it for that task :-) +10:42 < wsa_> thanks for the work! +10:42 <@neg> and that is all for me I have no other i/o task +10:42 < wsa_> any time left for IO base task? +10:43 < wsa_> not that i have something now +10:43 <@neg> hum in base no, rest of time is for core work. But if you have something small need doing I can try to squeeze it in +10:44 < wsa_> ok +10:44 < wsa_> yeah, i asked because of distribution of small things (if there is one) +10:44 < wsa_> wanted to know where we are +10:45 < wsa_> but since we fixed the r8a7740 SDHI regression, I don't see anything left there +10:45 <@neg> ofc, if you think of something let me know and I see what I can do +10:45 < wsa_> please speak up if i am wrong +10:46 < wsa_> so, neg is basically done with IO for Q2 and will (probably) have some more days in Q3 +10:47 < wsa_> so, ulrich is not here and will do the CAN driver review once he is back +10:47 < wsa_> morimoto-san is also not here but doesn't have any tasks assigned anyhow +10:48 < wsa_> so, in general i think we are on track +10:48 < wsa_> thanks guys! +10:48 < wsa_> it would be nice to have more IO time for geert, though +10:48 < shimoda> thank you! +10:50 < wsa_> ok, anything more to discuss? +10:50 <@neg> If task list is done I have a IO question +10:50 < wsa_> sure +10:51 <@neg> during boot of Salvator-X it is deleayed for ~20 sec and then i get this 'xhci-hcd ee000000.usb: can't setup: -110' +10:51 <@neg> i use the arm64_defconfig and was just wondering if this is known +10:51 < shimoda> oh, sorry it's xhci driver problem +10:52 < wsa_> there are mails about it on renesas-soc +10:52 <@neg> ok thanks +10:53 < wsa_> in short: a Kconfig dependecy needs to be set up +10:53 < shimoda> in v4.6, it should be fixed by f879fc32aa0c96fbac261b3d857a1239d554ad01 +10:54 <@neg> shimoda: great, thanks +10:55 < shimoda> neg: you're welcome! +11:04 < wsa_> ok, if no more questions... +11:04 < wsa_> ...then thanks for this meeting! +11:05 < shimoda> thank you! bye! +11:05 <@neg> thanks all +11:05 -!- shimoda [~shimoda@relprex3.renesas.com] has quit Quit: WeeChat 0.4.2 +11:06 < geertu> Data collection phase ;-)bye +11:06 < wsa_> good luck geertu ! +11:06 < geertu> Seems I have a problem with my IRC FIFO, too ;-) +--- Log closed Thu May 19 11:16:26 2016 diff --git a/wiki/Chat_log/20160524-core-chatlog b/wiki/Chat_log/20160524-core-chatlog new file mode 100644 index 0000000..de77a2c --- /dev/null +++ b/wiki/Chat_log/20160524-core-chatlog @@ -0,0 +1,255 @@ +Core-chat-meeting-2016-05-24 + +10:02 < geertu> Welcome to today's Core Group Chat Meeting +10:02 < geertu> Laurent will join later +10:02 < geertu> Magnus will have a fluctuating presence +10:03 < morimoto> I will quit 1hour later +10:03 < geertu> Agenda: +10:03 < geertu> 1. Upcoming Gen3 development for the Core group, +10:03 < geertu> 2. Revisiting the mode pins +10:03 < geertu> 3. Status check for tasks from last meeting - what is remaining? +10:03 < geertu> Topic 1. Upcoming Gen3 development for the Core group +10:04 < geertu> Any takers? +10:04 < horms> I have a few things to mention +10:05 < geertu> Please go ahead +10:06 < horms> Kaneko-san has been working on classifing the patches present in the v3.2.x BSP. v3.2.1 is mostly done. I can share what we have so far if it is of interest to the group. Mainly it covers r8a7795. And probaly we can tease some new tasks out of that. +10:06 < geertu> ok +10:06 < horms> I have asked him to start looking over the v3.2.3 BSP. I expect that to include rather a lot of r8a7796 code when compared to v3.2.1 +10:07 < horms> I mainly raise this because I'm not entirely sure how to make the information available here. Or indeed if it is of much interest at all. +10:08 < geertu> As this affects all groups, perhaps it should be emailed to periperi instead? +10:08 < horms> That is all I have to raise for this topic. +10:08 < shimoda> horms: perhaps, you mean v3.2.2 BSP, not v3.2.3 :) +10:09 < horms> Sorry, I mixed up the versions. +10:09 < horms> We have looked over v3.2.0. +10:09 < horms> We are starting to look over v3.2.2. +10:10 < horms> There is also a v3.2.1 but we are planning to skip from v3.2.0 to v3.2.2. +10:10 < horms> geertu: sure, good suggestion. +10:11 < shimoda> I agree with geert-san. this topic is related to all groups. and I would like to share information about bsp sdhi driver later :) +10:12 < shimoda> because the bsp sdhi driver has some workaround code, and i don't think we upport it +10:13 < horms> Ok. I'll make the raw information I have available on periperi ML. And we can decide what are some good next steps there. +10:14 < shimoda> thanks! +10:14 < horms> off topic. but I would value any insights/testing of timeouts during tuning in my sdr104 patch set. +10:14 < khiemnguyen> horms: Please add me to periperi ML. +10:15 < horms> khiemnguyen: I will send the BSP analys there. Is that what you were requesting? +10:15 < khiemnguyen> horms: I just wonder whether my email address is included or not :) +10:16 < horms> I can fix that. Lets discuss in private. +10:16 < horms> geertu: I think we cam move on +10:17 < geertu> Yes. any more upcoming development? +10:17 < geertu> I'm mostly fighting^H^H^H^H^H^H^H^Hbusy with my IO task right now +10:18 < horms> Oh, sorry. There is one more thing I thought of. +10:18 < horms> Sharing DT betweek Gen3 SoCs. Dirk raised this on the ML. +10:18 < horms> It seems like a good idea in principle. +10:19 < horms> But it doesn't seem to work well with our per-soc compatibility strings. +10:19 < geertu> Indeed +10:19 < horms> So I wonder if the number of nodes that can be shared via an #include scheme is quite small +10:19 < geertu> But nothing some smart (obfuscated?) cpp macros can't solve... +10:19 < horms> I was thinking of responding along those lines. +10:19 < horms> Basically if we can come up with a scheme that is great. +10:20 < horms> But I'm inclined to think that is an effort to be done in parallel +10:20 < horms> rather than a dependency for adding M3-W +10:20 < geertu> Yes, in parallel, not as a dependency +10:20 < horms> Ok, I'll respond unless you wish to (I won't get to it until at least tomorrow) +10:21 < geertu> OK, will see whether I find some time to write a reply. +10:22 < horms> Thanks +10:22 < horms> khiemnguyen: you are now subscribed to the periperi ML +10:25 < horms> geertu: shall we move on? +10:25 < geertu> yes please +10:26 < horms> I guess its mode pin time :) +10:26 < geertu> Yeah, again! +10:26 < horms> But perhaps we should defer that to after Laurent arrives_ +10:26 < horms> ? +10:26 < geertu> Indeed. Unless Morimoto-san has a srong opnion? +10:27 < geertu> s/srong opnion/strong opinion/ +10:28 < morimoto> sorry, what was "mode pin" ? +10:28 < geertu> morimoto: Read the MODEMR register to obtain the status of the mode pins. +10:29 < geertu> Needed for CPG on Gen2/3 +10:30 < morimoto> I have no opinion about that (at this point) +10:30 < geertu> OK +10:30 < geertu> Let's continue when Laurent has (re)arrived. +10:30 < geertu> 3. Status check for tasks from last meeting - what is remaining? +10:30 < geertu> We have a few tasks with deadline v4.6 in core/todo +10:31 < geertu> IPMMU,v4.6,plan,niklas,Discuss API changes on the dma-engine mailing list +10:31 < geertu> neg: I assume this is now completed? +10:32 < neg> yes +10:32 < neg> or sorry. no +10:33 < geertu> I'll uodate it for v4.7? +10:33 < geertu> s/uodate/update/ +10:34 < neg> thanks. I have sent out a patch addresig Hellwigs concerns 2 weeks ago but have not yeat heard back from him about it +10:35 < geertu> ok +10:35 < geertu> IPMMU,v4.6,noplan,?,Finally get feedback from the hardware developers regarding the IPMMU + DMAC channel 0 issue +10:35 < geertu> Did we hear anything back? +10:35 < geertu> If not, I'll change it to v4.x +10:36 < geertu> (or is "?" accepted as a version?) +10:37 < shimoda> i have no update, so lets ? as a version +10:37 < geertu> ok +10:37 < geertu> SMP,v4.6,public,magnus,Discuss SMP DT bindings with ARM SoC maintainers +10:37 < geertu> dammsan: there? +10:41 < geertu> OK, let's check when he's back +10:41 < geertu> r8a7795,v4.7,prototype,shimoda,Investigate SYS-DMAC2 +10:41 < geertu> shimoda: Do you know if the firmware fixing this has been released? +10:42 < morimoto> (he is now talikng with our boss, please wait) +10:46 < khiemnguyen> geertu: shimoda: FYI, I saw that secure firmware of 2.8.0 has some updated for SYS-DMAC2. Any test cases to confirm SYS-DMAC2 ? +10:49 < geertu> khiemnguyen: If you change (both) dmac1 to dmac2 for the scif1 node in r8a7795.dtsi, does debug serial 1 still work? +10:50 < khiemnguyen> geertu: OK. Let me try it and inform you the result. +10:50 < shimoda> sorry for the late. as khiem-san mentioned, the firmware 2.8.0 has update for SYS-DMAC2. and bsp team confirmed the dmac work correctly. +10:50 < geertu> khiemnguyen: thx +10:51 < geertu> shimoda: Great! +10:51 < geertu> So we can start adding dmas pointing to dmac2 where appropriate +10:52 < geertu> I'll add a task for that +10:52 < dammsan> geertu: no update from my side +10:53 < geertu> dammsan: Do you plan to have more discussions (and I will s/v4.6/v4.7/), or are we finished discussing SMP DT bindings (and I will mark it completed)? +10:54 < dammsan> good question +10:54 < shimoda> by the way, v2.8.0 also enables data conversion feature though :) as we discussed before, for short term, we should disable the feature +10:54 < morimoto> (unfortunately, I will go to next meeting) +10:55 < dammsan> i think keeping it for a while is good +10:55 < geertu> morimoto: thanks, and have a nice continued day! +10:57 < geertu> W.r.t. SYS-DMAC2, the wiki doesn't have boot loader v280 yet (latest is v270) +10:58 < geertu> Which brings us to another interesting question. +10:58 < geertu> When do we update the DTS with features that depend on firmware versions? +11:00 < horms> I gather the issue here is about backwards copmatibility. I.e. new DT with old FW. +11:01 < geertu> Yes +11:01 < geertu> Which is also relvant for "compatible = "arm,psci-1.0"; +11:01 < geertu> s/relvant/relevant/ +11:01 < geertu> whicb BTW, can be detected at run-time... +11:02 < horms> ok, if it can be detected at run time then perhaps it should be :) +11:02 < dammsan> run-time detection must be best if possible +11:02 < geertu> Yeah, DT describes the hardware bla bla bla +11:02 < horms> but I guess in the general case we may have to document minumum FW revisions +11:03 < geertu> Yes, add a comment at the top of r8a7795.dtsi? +11:03 < horms> That might be a good start. +11:05 < khiemnguyen> geertu: horms: psci-1.0 can be detected at runtime. I have replied the thread. +11:05 < horms> excellent, thanks +11:07 < geertu> OK, let's move on +11:07 < geertu> DMAEngine,v4.7,prototype,?,Implement proper solution with IPMMU +11:08 < geertu> Should the "?" be "magnus"? +11:08 < geertu> Update to v4.8? +11:09 < neg> how is this task different from 'Discuss API changes on the dma-engine mailing list' ? +11:09 < geertu> discuss vs. implement? +11:11 < neg> hum OK, the patches I try to get Hellwigs attentinon on have one implementation for this, if it is proper or not I do not know :-) +11:12 < geertu> OK, I'll keep the "?" for now +11:12 < horms> I wonder how we can get Christoph's attention +11:12 < geertu> Beer? +11:12 < horms> Probably +11:13 < horms> If I see him I will give him some. But perhaps that shouldn't be our plan A :) +11:13 < geertu> Will he be at LCJ? The LCJ schedule hasn't been announced yet +11:13 < neg> My plan is to resend the patch later this week, I got feedback from Robin Murphy so I need to fix onething in it +11:15 * pinchartl is back +11:15 < geertu> Ok. It's still the merge window, so people may be busy with that +11:15 < geertu> pinchartl: Welcome! +11:16 < geertu> Back to the mode pins... +11:16 < geertu> So Dirk Behme is more or less pushing us to pick a solution +11:16 < pinchartl> (quick comment about sharing DT sources between H3 and M3: maybe we shouldn't have per-soc compat strings ;-)) +11:16 < horms> pinchartl: i knew you would say that :^) +11:17 < geertu> pinchartl: We can add them dynamically with an early DT fixup? +11:17 < geertu> Oh well... +11:18 < geertu> Back to the mode pins... +11:18 < pinchartl> yes +11:18 < pinchartl> so what's the status there ? +11:18 < geertu> Dirk has posted updated versions of both Simon's and my proposals +11:19 < geertu> I.e. rebased and extended to r8a7796 +11:19 < pinchartl> nice +11:19 < pinchartl> do they both work ? +11:19 < horms> FWIW I felt that geert's approach was cleaner. +11:19 < geertu> He claims they do, and I don't see a reason why not. +11:20 < pinchartl> horms: that's using syscon, right ? +11:21 < horms> yes +11:23 < pinchartl> I still don't like it. not such much because of the C implementation, but because referencing modemr in DT isn't a hardware description +11:25 < pinchartl> feel free to voice your disagreement with that opinion :-) +11:25 < geertu> The CPG hardware must have a link to the mode pins though +11:27 < pinchartl> yes +11:27 < pinchartl> that's for sure +11:27 < pinchartl> both the CPG and RST chapters of the datasheet list the MD pins in their external pins section +11:28 < geertu> But the RST is responsible for latching them ("Latching of the levels on mode pins when PRESET# is negated") +11:31 < pinchartl> yes, but that's not related to the modemr register per-se +11:32 < pinchartl> if the values of the MD pins were scattered across several registers +11:32 < pinchartl> or made accessible in an even more complex way to software +11:32 < pinchartl> would you still put the access logic in each driver that needs to know the value of the modemr pins ? +11:33 < pinchartl> that's what bothers me, boot mode configuration should be a system service, not something that is hacked by each driver +11:33 < pinchartl> of course in this case accessing the register is simple +11:33 < geertu> No, we'd provide an API. +11:33 < horms> So the way that I see things is this: On the one hand pushing things out to DT seems to lead to a cleaner implementation in software. But on the other hand it might be cleaner from a design point of view not to have this information in DT at all. +11:33 < pinchartl> but what if you needed to enable clocks to access that register ? +11:33 < pinchartl> or power domains ? +11:34 < pinchartl> we could argue that accessing the information is simple and that we don't need an API now +11:34 < pinchartl> we could implement an API later +11:34 < pinchartl> but we'd be stuck with the syscon method for all existing socs +11:34 < geertu> Let's stick the API in include/linux/soc/renesas/rcar-rst.h for now? +11:35 < pinchartl> horms: yes, for our current use cases, it's easier to use rst,modemr than designing a new API +11:35 < geertu> And the driver in drivers/soc/renesas/rcar-rst.c? +11:35 < pinchartl> geertu: I'd be fine with that +11:35 < pinchartl> that can be changed later if needed without any DT ABi breakage +11:36 < geertu> A generic API for all SoCs and architectures can still be done on top of that later +11:37 < pinchartl> if that's fine with everybody it's fine with me +11:38 < horms> I think I am fine with it +11:38 < geertu> Yep +11:38 < pinchartl> we would (at least temporarly) lose the ability to use the CPG on a non-Renesas platform, but I doubt that's a problem :-) +11:38 < geertu> I'll write it down in the meeting minutes, and we can let the idea cook for a few more days +11:39 < horms> good plan +11:39 < horms> pinchartl: i don't think that is a problem either :) +11:39 < geertu> OK, case closed... Finally... +11:40 < pinchartl> :-) +11:40 < geertu> pinchartl: I have a few more questions about core tasks +11:41 < geertu> RCAR-DMAC,v4.7,plan,laurent,Fix atomic DMA memory pool exhaustion +11:41 < geertu> RCAR-DMAC,v4.7,plan,laurent,Pick up the patches, fix the DMA engine API and save the world +11:42 < geertu> Given you don't have a core task this quarter, that's gonna be v4.8/v4.9? +11:42 < pinchartl> let me check +11:44 < pinchartl> for the first task, Vinod has picked the patch +11:44 < pinchartl> it hasn't been merged in mainline yet though but I assume it will before the end of the merge window +11:44 < pinchartl> let me check linux-next +11:45 < pinchartl> it's not in linux-next either :-/ +11:45 < geertu> pinchartl: Indeed, that's what I thought too +11:46 < horms> Vinodっぽい +11:46 < geertu> And, wasn't this an improvement, not a complete fix? +11:47 < pinchartl> I can't see the patch in Vinod's tree either +11:48 < pinchartl> it depends what you mean by complete fix +11:48 < geertu> Vinod did say "applied" +11:49 < pinchartl> I'd still like to improve the DMA engine API to allow reusing requests +11:49 < pinchartl> but that's a major change +11:49 < pinchartl> without changing the API, that patch is the best we can do +11:49 < pinchartl> yes, Vinod said applied +11:51 < geertu> ok +11:51 < geertu> Will you kick him, or shall I do? +11:51 < pinchartl> I've just did +11:51 < geertu> OK +11:52 < pinchartl> for the second task, please move it to v4.8/v4.9 +11:52 < geertu> ok +11:52 < geertu> shmobile_defconfig,v4.7,public,laurent,Enable CONFIG_CMA=y +11:52 < geertu> This one is interesting, it started for v4.4, and I can't seem to find it was ever sent? +11:53 < pinchartl> I had completely forgotten about it +11:54 < pinchartl> I can't even remember I've posted a patch for that :-) +11:54 < geertu> It entered with status "public" in peripelist +11:54 < geertu> However, OHCI-PCI doesn't seem to work with CONFIG_DMA_CMA=y +11:55 < horms> "CMA" draws a blank in patchwork +11:56 < geertu> I'll change it to shmobile_defconfig,v4.8,plan,laurent,Enable CONFIG_CMA=y +11:56 < geertu> SMP,v4.7,documented,laurent,Add DT SMP/APMU support for new SoCs (r8a7793/r8a7794) +11:57 < geertu> Shall I take this over? Magnus posted patches for that, and I have updated versions in my local tree. +11:57 < pinchartl> please do +11:57 < geertu> OK +11:58 < pinchartl> for CONFIG_CMA, can you point me to the e-mail thread ? +11:58 < geertu> which e-mail thread? +11:59 < geertu> "[Bug]:Koelsch: DU, Could not show an image or picture on HDMI display."? +11:59 < pinchartl> well, you said I've submitted a patch ? +12:00 < geertu> IIRC this was originally an action item from the meeting in Dublin after ELCE +12:00 < geertu> No, peripelist says "public", but I think that was a mistake during the initial peripelist creation +12:00 < pinchartl> ah ok +12:01 < pinchartl> that makes more sense +12:01 < pinchartl> so the only issue is that OHCI-PCI breaks with CMA ? +12:01 < geertu> That's what I noticed when looking into Hiep-san's report +12:03 < pinchartl> ok +12:03 < pinchartl> isn't that an I/O task then ? :-) +12:03 < geertu> Yep, will kick Wolfram +12:05 < geertu> I think we're done (and overdue)? +12:06 < pinchartl> yes +12:06 < horms> Only update from my side is that basic M3-W support is progressing. I expect to accept my own patches soon. +12:06 < shimoda> yes +12:07 < geertu> Thanks for your attention span! +12:07 < geertu> Have a nice continued day! +12:07 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] +12:07 < horms> bye +12:07 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi +12:08 < uli___> bye +12:08 < shimoda> bye! +12:09 < khiemnguyen> nice day. bye. +12:09 -!- shimoda [~shimoda@relprex2.renesas.com] has quit [Quit: WeeChat 0.4.2] +12:09 < neg> thanks, bye + diff --git a/wiki/Chat_log/20160525-mm-chatlog b/wiki/Chat_log/20160525-mm-chatlog new file mode 100644 index 0000000..f0e3cd3 --- /dev/null +++ b/wiki/Chat_log/20160525-mm-chatlog @@ -0,0 +1,478 @@ +Multimedia-chat-meeting-2016-05-25 + +<pinchartl> hello Morimoto-san +<morimoto> Hi +<morimoto> sorry for my late +<pinchartl> we've just started +<pinchartl> no worries, you're excused +<pinchartl> I've posted the topics for the day +<pinchartl> Topic 1. Status check for the multimedia tasks +<pinchartl> Topic 2. Additional '50%' tasks +<pinchartl> Topic 3. New upstream DRM/KMS rules +<pinchartl> Topic 4. Next meeting +<pinchartl> would anyone like to add another topic ? [17:02] +<morimoto> I added Renesas request to peripelist +<dammsan> hi guys, sorry about the delay +<morimoto> (it was already requested by email to each member, but not listed) +<pinchartl> in multimedia/request ? [17:03] +<morimoto> Yes +<pinchartl> (kbingham: for your information, the lists of pending and + requested tasks are maintained in text format in a git tree called + peripelist) [17:04] +<kbingham> pinchartl: I see :) +<pinchartl> I have a question about that, let's add it as a topic [17:05] +<pinchartl> Topic 4. Renesas requests +<morimoto> thanks [17:06] +<pinchartl> let's get started with the status, and let's try to keep it short +<morimoto> :) +<pinchartl> in alphabetical order [17:07] +<pinchartl> FDP,v4.8,plan,laurent,Develop and upstream driver +<pinchartl> (which is handled by Kieran, otherwise I wouldn't be first in + alphabetical order) +<pinchartl> kbingham: what's the status ? [17:08] +<kbingham> FDP1: M2M driver can handle frames, and support MPLANE/MPIX + api. Now working with getting the hardware to do + 'something'. IPBlock is powered up, (using RuntimePM) and + interrupts are firing. Not currently getting 'successful' FrameEnd + status yet though. +<kbingham> Switched to using OPMODE_INTERRUPT with a VPERIOD setting, and that + fires regular VSyncs +<pinchartl> do you have ideas regarding what to explore or are you getting + blocked ? [17:09] +<kbingham> Starting to feel blocked. I've gone through most of the register + settings, and the programming sequence and I'm running out of + ideas. My next plan is to try moving away from Progressive mode and + try de-int mode to see if there is a difference there but I fear + that is complicating things rather than simplifying. The only other + thing I have thought needs checking is the FCP [17:10] +<pinchartl> have you linked the FDP to the FCP in DT ? [17:11] +<kbingham> No! [17:12] +<kbingham> That sounds like a step I've missed :) +<pinchartl> and do you call rcar_fcp_enable() and rcar_fcp_disabled() in your + driver ? +<kbingham> Ok - I'm unblocked :) +<pinchartl> at least temporarily :-) +<pinchartl> the FCP driver isn't upstream yet +<pinchartl> you need to get it from my git tree at + git://linuxtv.org/pinchartl/media.git [17:13] +<kbingham> I do have a pending action to confirm the CPG clock parents + though. morimoto - are you able to look into that for me? +<pinchartl> branches drm/next/dt and vsp1/next +<kbingham> pinchartl: Ok - thanks. I'll get on that next. +<morimoto> kbingham: can you send question email to me or periperil ML ? + [17:14] +<morimoto> kbingham: I can send it to HW / datasheet guys +<kbingham> morimoto: Sure. I'll send a dedicated mail. thanks :) +<morimoto> kbingham: np +<pinchartl> next, Magnus [17:15] +<pinchartl> VIN,?,plan,magnus,IPMMU integration on Gen2 +<pinchartl> VIN,?,plan,magnus,IPMMU integration on Gen3 +<pinchartl> VIN,?,plan,magnus,IPMMU support on Gen2 +<pinchartl> VIN,?,plan,magnus,IPMMU support on Gen3 +<pinchartl> no progress on that I assume ? +<dammsan> nothing done yet, but i intend to try Gen3 early next month +<dammsan> with VIN in mean +<pinchartl> but not with the IPMMU, right ? [17:16] +<dammsan> s/in/i/g +<dammsan> test with the IPMMU +<dammsan> just to figure out what is needed +<pinchartl> so we're not blocked by the IPMMU hardware bug anymore ? +<morimoto> kbingham: for your information: I asked to BSP team about FDP + sample code / test code now. I'm not sure it exists or not. please + wait :) +<dammsan> it is probably flakey on H3 +<dammsan> but worth looking into to see what our limitations are [17:17] +<dammsan> M3 may work better +<kbingham> morimoto: Thanks. Will be useful reference if it exists. +<dammsan> same situation as DU +<pinchartl> morimoto: thank you ! +<pinchartl> morimoto: there's a 'fdpm-driver.tar.bz2' archive mentioned in the + yocto recipes, but that file is nowhere to be found [17:18] +<pinchartl> so I assume code exists +<pinchartl> dammsan: thanks +<dammsan> np +<pinchartl> next, morimoto +<pinchartl> RSND,2016-06-30,plan,morimoto,DT bindings for HDMI sound +<pinchartl> RSND,2016-06-30,plan,morimoto,dw-hdmi-ahb-audio prototype on Gen3 +<pinchartl> RSND,2016-06-30,plan,morimoto,HDMI SSI prototype on Gen3 +<pinchartl> RSND,2016-06-30,plan,morimoto,HDMI sound Upstream support without + hotplug on Gen2 +<pinchartl> RSND,2016-09-30,plan,morimoto,Hotplug support upstream on Gen3 +<morimoto> graph base HDMI sound needs hack. [17:19] +<morimoto> I posted its 1st step patches to ALSA and Renesas ML +<morimoto> It is under reviewing now +<morimoto> And now, I'm hacking of prototype of graph base sound card +<morimoto> not yet finished. +<morimoto> over [17:20] +<dammsan> (and i bothered morimoto-san by asking about HDMI-in audio-input) +<pinchartl> as you've posted patches, which of the tasks should now be + 'public' [17:21] +<morimoto> I'm bothering it, yes +<morimoto> well... +<morimoto> RSND,2016-06-30,plan,morimoto,DT bindings for HDMI sound +<morimoto> but, 30% for it +<morimoto> 30% of it [17:22] +<pinchartl> I wonder how to report the 30% in the tasks list :-) +<pinchartl> should I leave it as 'plan' for now until we reach 50% ? [17:23] +<morimoto> can you separate it into more small tasks ? +<morimoto> split ? separate ? +<pinchartl> sure [17:24] +<pinchartl> how would you like me to split it ? +<morimoto> 1. clean up simle-card [17:25] +<morimoto> 2. create simple-card core +<morimoto> 3. share simple-card core with DPCM +<morimoto> 4. share simple-card core with graph +<morimoto> 5. use graph simple-card on ASoC +<morimoto> 6. use graph simple-card on Gen2 +<morimoto> 7. use graph simple-card on Gen3 +<morimoto> +<morimoto> Maybe these are enough +<morimoto> 1, 2, 3 are posted +<morimoto> I mean public +<pinchartl> that's very fine-grained. do we really need to go to that level of + details in the tasks list, or can I just list that in the meeting + report ? [17:27] +<morimoto> OK, please wait +<morimoto> I will clean up again +<pinchartl> thanks [17:28] +<pinchartl> I'll include that in the report anyway +<pinchartl> I'll move on to Niklas' tasks in the meantime +<pinchartl> ADV7482,v4.7,plan,niklas,Prototype on Gen3 +<pinchartl> ADV7482,v4.9,plan,niklas,Gen3 support upstream +<pinchartl> ADV7482,v4.9,plan,niklas,Interlace support upstream +<pinchartl> VIN,v4.7,plan,niklas,CSI2 prototype (Gen3) [17:29] +<pinchartl> VIN,v4.8,plan,niklas,Gen3 support +<pinchartl> VIN,v4.8,plan,niklas,Scaler support (on Gen3) +<pinchartl> VIN,v4.8,public,niklas,New VIN driver without soc-camera (tested + on Gen2) +<pinchartl> VIN,v4.9,plan,niklas,CSI2 interlace support upstream (Gen3) +<pinchartl> VIN,v4.9,plan,niklas,CSI2 support upstream (Gen3) +<pinchartl> VIN,v4.9,plan,niklas,Gen3 support upstream (without CSI-2) +<neg> I will post the Gen3 VIN patches today +<pinchartl> including CSI ? [17:30] +<neg> yes it will include the CSI2 and ADV7482 prototypes from BSP with some + small fixes ontop +<pinchartl> so that covers +<pinchartl> - ADV7482,v4.7,plan,niklas,Prototype on Gen3 +<pinchartl> - VIN,v4.7,plan,niklas,CSI2 prototype (Gen3) +<pinchartl> - VIN,v4.8,plan,niklas,Gen3 support [17:31] +<pinchartl> right ? +<neg> yes, but I will not include the CSI2 and ADV in the patch sereis but + make them avaliable in a topic branch for testing +<neg> so I don't think they should be marked public +<pinchartl> for prototype patches that's fine, and I think it's enough to + consider them as public [17:32] +<neg> OK +<pinchartl> are the Gen3 support patches in a good enough shape to be reviewed + ? +<pinchartl> or are they prototype code ? +<neg> yes I hope they are ready for review, they use s_input for input + selection which we might not want to commit to. But I think it worked + out OK [17:33] +<pinchartl> ok, thanks +<morimoto> pinchartl: hmm.. then, current task list is enough ;) [17:34] +<morimoto> pinchartl: can you set "DT bindings for HDMI sound" as "public" ? +<morimoto> +<pinchartl> morimoto: sure +<morimoto> kbingham: we got FDP sample code from BSP team. I will send it to + you +<pinchartl> morimoto: great ! +<kbingham> morimoto: Thanks! +<pinchartl> neg: no progress on the other tasks I assume [17:35] +<neg> at lest you can grab frame from both HDMI and CVBS sources on both Gen2 + and Gen3 +<neg> pinchartl: yes no progress on the rest +<pinchartl> ok +<pinchartl> are we still on track with the targets ? [17:36] +<pinchartl> - VIN,v4.8,plan,niklas,Scaler support (on Gen3) +<pinchartl> - VIN,v4.8,public,niklas,New VIN driver without soc-camera (tested + on Gen2) +<pinchartl> and the rest is for v4.9 +<pinchartl> I think we are +<neg> yes I think so +<pinchartl> so do I, good :-) +<pinchartl> next, uli___ [17:37] +<pinchartl> DU,v4.7,plan,ulrich,Atomic API test program +<pinchartl> DU,v4.7,public,ulrich,HDMI output on Gen3 prototype +<pinchartl> DU,v4.7,prototype,ulrich,Test setup with HDMI output to HDMI input + loopback (without EDID) +<pinchartl> DU,v4.7,public,ulrich,EDID generation support for the HDMI + loopback test setup +<pinchartl> DU,v4.8,plan,ulrich,HDMI output on Gen3 upstream +<pinchartl> VIN,v4.8,public,ulrich,Add DV timings support to rcar-vin +<uli___> api test is in progress right now +<uli___> hdmi output i will brush up and make public as an rfc before the end + of the month [17:38] +<uli___> gen3 i mean +<uli___> dv for r-car vin is at v4 now +<uli___> hans's complaints are limited to the fixed edid blob +<uli___> gotta implement s_edid/g_edid instead +<uli___> that's about it for now [17:39] +<morimoto> uli___: Is renesas-driver including your latest HDMI out code ? I + still have HDMI1_OUT issue on latest renesas-driver +<uli___> there is a topic branch, iirc [17:40] +<morimoto> OK +<pinchartl> as the HDMI out prototype is an additional task please make sure + with Geert that the topic branch is merged in the renesas-drivers + tree +<uli___> topic/salvator-x-hdmi-prototype-v2 +<pinchartl> thanks [17:41] +<morimoto> thanks, +<pinchartl> I'll keep HDMI loopback targetted at v4.7 as it's due for end of + June [17:42] +<uli___> yes +<pinchartl> I don't think 'DU,v4.8,plan,ulrich,HDMI output on Gen3 upstream' + will make it to v4.8 [17:43] +<uli___> probably not +<pinchartl> I'll push it back to v4.9 +<pinchartl> next, me [17:44] +<uli___> (what happened to the alphabetical order, anyway?) +<uli___> scnr +<pinchartl> good question :-) +<pinchartl> DU,?,plan,laurent,IPMMU integration on Gen3 [17:45] +<pinchartl> DU,?,plan,laurent,IPMMU support on Gen3 (through VSPD+FCP) +<pinchartl> no progress +<pinchartl> DU,v4.8,public,laurent,VSPD Z-order support upstream (Gen3) +<pinchartl> still public :-) [17:46] +<pinchartl> the patches missed the v4.7 merge window, they will make it to + v4.8 [17:47] +<pinchartl> VSP,?,plan,laurent,Fixed alpha support (VI6_DPR_*_ROUTE.FXA) +<pinchartl> VSP,?,plan,laurent,CLU WARN_ON fix +<pinchartl> VSP,?,plan,laurent,CLU 2D and 3D mode support +<pinchartl> VSP,?,plan,laurent,CLU/LUT test application +<pinchartl> VSP,?,plan,laurent,CLU/LUT upstream API +<pinchartl> no progress +<pinchartl> CLU support is an additional task for June [17:48] +<pinchartl> I'll mark it for v4.8 +<pinchartl> VSP,?,plan,laurent,UDS regression fix [17:49] +<pinchartl> no progrss +<pinchartl> I plan to have a look at it in June, v4.8 as well +<pinchartl> VSP,v4.8,plan,laurent,Fix suspend/resume crash [17:50] +<pinchartl> no progress +<pinchartl> VSP,v4.8,public,laurent,CLU/LUT support submitted upstream on Gen3 +<pinchartl> no progress either, still on track for v4.8 with the rest of the + CLU tasks [17:51] +<pinchartl> VSP,v4.8,p,laurent,HGO operation mode selection +<pinchartl> VSP,v4.8,plan,laurent,HGO support upstream on Gen3 +<pinchartl> VSP,v4.8,plan,laurent,HGO test application +<pinchartl> patches are now public +<pinchartl> on track for v4.8 +<pinchartl> testing doesn't require a new test application [17:52] +<pinchartl> patches to yavta test tool have been pushed to the repository in a + topic branch until the API changes get accepted upstream +<pinchartl> and test scripts have been pushed to a new project [17:53] +<pinchartl> git://git.ideasonboard.com/renesas/vsp-tests.git +<pinchartl> this is an initial attempt at creating unit tests for the vsp + driver +<pinchartl> if anyone is interested I can elaborate on that [17:55] +<uli___> i would be... +<pinchartl> ok, let's address that as a separate topic +<pinchartl> VSP,v4.8,public,laurent,V4L2 request API usable prototype [17:56] +<pinchartl> VSP,?,prototype,laurent,V4L2 request API upstream +<pinchartl> progress :-) +<pinchartl> but not posted yet, I will for the end of the month, which means + the end of the week +<pinchartl> that's it for the tasks +<pinchartl> Topic 2. Additional '50%' tasks +<pinchartl> has everybody received their additional tasks for June ? [17:57] +<pinchartl> ('everybody' being Niklas and Ulrich) +<uli___> you have sent something to magnus, not sure what became of that :) + [17:58] +<neg> yes I got task descriptions from Magnus today +<pinchartl> dammsan: what's the status ? [17:59] +<pinchartl> anything needed on our side, or is everything in the pipeline ? +<pinchartl> while waiting for Magnus to reply +<pinchartl> is everybody on track with their additional tasks for May ? + [18:00] +<morimoto> (dammsan is talking to Renesas guy now, please wait) +<pinchartl> the report needs to be a bit more detailed than what we are used + to +<pinchartl> and should really not miss the deadline +<pinchartl> neg: uli___: are you all good ? +<uli___> i am [18:01] +<neg> yes, I'm fine +<pinchartl> great +<pinchartl> I am as well +<dammsan> pinchartl: need to finalize one bit with wolfram to cover uli___ +<neg> Only outstading issue I have is to ping geert for a topic branch in + renesas-drivers but I think that is OK to contain prototype code right? + [18:02] +<dammsan> but i hope to do so today or tomorrow +<dammsan> to have final review on friday +<pinchartl> neg: it is, yes. if you push your patches to a git tree and send a + pull request to Geert for renesas-drivers that's enough for the + report +<pinchartl> dammsan: thanks +<neg> pinchartl: great thanks +<pinchartl> Topic 3. New upstream DRM/KMS rules [18:04] +<pinchartl> this one is a rather bad one +<pinchartl> DRM/KMS has long required GPU kernel drivers to have an + open-source userspace implementation in order to get merged +<pinchartl> that's at least how the rule was communicated interpreted [18:05] +<pinchartl> they're now changing, if not their base rule, at least how they + apply it +<pinchartl> and require open-source userspace upstream code for any new kernel + API +<pinchartl> including driver-specific properties +<pinchartl> z-order and alpha support got accepted right before they decided + to enforce that rule [18:06] +*** horms (~horms@reginn.isobedori.kobe.vergenet.net) has quit: Quit: Leaving +<pinchartl> but from now on, an implementation in Android hardware composer, + wayland or X11 will be required for any API extension +<pinchartl> this is a major issue for us +<pinchartl> as our team works on the kernel side only [18:07] +<pinchartl> not only don't we have the bandwidth to cover the userspace side +<pinchartl> but userspace is the responsibility of other teams within Renesas, + and we can't claim ownership of those areas +<pinchartl> the new rule will be announced shortly [18:08] +<pinchartl> there will likely be a grace period +<pinchartl> but we'll have to adjust +<pinchartl> I've learnt about that yesterday and don't have a plan yet +<pinchartl> any comment ? +<uli___> so does the userspace part only have to exist somewhere, or does it + really have to be upstream? [18:09] +<pinchartl> it has to be acked by upstream developers +<pinchartl> not merged obviously, as it can't be merged before the kernel API + is available [18:10] +<morimoto> does z-order and alpha support will be updated ? +<pinchartl> they will be merged in v4.8 as they have been accepted right + before the change of rule [18:11] +<pinchartl> but if they hadn't been +<pinchartl> we would have had to submit patches to android hwcomposer, weston + or X11 to use Z-order and alpha +<pinchartl> so this might mean we'll have to collaborate with the Renesas + upstream developers [18:14] +<pinchartl> s/upstream/userspace/ +<pinchartl> I'll bring that topic up during the meeting in Japan +<pinchartl> any suggestion regarding what to do in the meantime will be + welcome [18:15] +<pinchartl> while this sinks in +<pinchartl> Topic 4. Renesas requests +<pinchartl> Morimoto-san, you've updated multimedia/request [18:16] +<pinchartl> how are we supposed to handle that list ? +<pinchartl> is it just there to keep track of the request, and let us propose + additional tasks (or handle them as part of the base contract), or + do we need to be more proactive ? [18:17] +<morimoto> It is not a big deal, just for my / Renesas information +<morimoto> I sometimes requests something, and clean forgot :) [18:18] +<pinchartl> ok, so no action required from me, apart from looking at it and + using it as a source of inspiration to propose tasks ? +<morimoto> I would like to track what is requested, and current status +<morimoto> something like that [18:19] +<pinchartl> thanks [18:20] +<pinchartl> Topic 5. VSP unit tests +<pinchartl> as I mentioned earlier, we now have a vsp unit tests framework +<pinchartl> it's implemented as a set of shell scripts using the yavta and + media-ctl test tools +<pinchartl> as well as the compare utility from ImageMagick [18:21] +<pinchartl> on the host side python is also needed to generate test data +<pinchartl> there are 8 tests so far, and they already allowed me to catch two + bugs in the vsp driver, for which I've submitted patches +<pinchartl> I plan to add more test script in the future +<pinchartl> and will also need to work on creating a new test tool to generate + test data (both input reference frames and excepted output frames + for comparison) at runtime instead of build time [18:22] +<pinchartl> as there's already 230MB of test frames, and that won't scale +<pinchartl> new test scripts will be added as I develop driver features +<pinchartl> and I'll propose an additional task for work on the test framework + core, as that will need quite a bit of time [18:23] +<pinchartl> I encourage you all to start thinking about unit test scripts for + the driver(s) you work on +<kbingham> pinchartl: I'd been looking at gstreamer as a potential for testing + my M2M driver - as the Videotestsrc element will enable me to + create many types of frames consistently - dynamically. +<pinchartl> feel free to use vsp-tests as a base and provide feedback +<pinchartl> for the FDP I think that's an option [18:24] +<pinchartl> it would depend on gstreamer obviously, but that shouldn't be a + too big deal +<pinchartl> on the other hand [18:25] +<pinchartl> gstreamer will only exercise the API as it's meant to be used +<pinchartl> if you want to unit-test the error paths then you'll need + something at a lower level +<kbingham> yes. that's true. +<pinchartl> but you can have diffrent unit test scripts that use different + tools [18:26] +<pinchartl> I'm fine with gstreamer, but if you realize that you could perform + the exact same tests easily with less dependencies, then I'd + prefer avoiding gstreamer +<pinchartl> if it brings added value, then no worries +<kbingham> Ok - I'll bear that in mind :) [18:27] +<pinchartl> regarding the test scripts themselves, we should standardize on + naming, output and other technical details to make sure they could + all be run from a single test runner, and generate a coherent + report +<pinchartl> I haven't given that much thoughts yet on my side +<pinchartl> if you start writing unit test scripts please get in touch with me + to discuss those points [18:28] +<pinchartl> that's all I have on this topic [18:29] +<pinchartl> Topic 5. Next meeting +<pinchartl> I propose Wednesday in two weeks (8th of June), same time as today +<kbingham> Ok for me. [18:30] +<uli___> me too +<neg> OK for me +<morimoto> OK for me too +<pinchartl> dammsan: ? +<morimoto> (Mr Magnus is still taling to Renesas guy) +<pinchartl> ok :-) +<pinchartl> I assume he will voice his concerns over e-mail if there's any + issue +<pinchartl> we're done with the agenda, any last remark or question ? [18:31] +<morimoto> pinchartl: thank you for your new topic for RenesasCon +<pinchartl> you're welcome +<pinchartl> it's two new topics actually [18:32] +<pinchartl> I plan to talk about the test framework too +<pinchartl> in addition to the DRM/KMS rule change +<pinchartl> but regarding the test framework +<pinchartl> we should discuss it internally first before adding the topic to + the RenesasCon agenda +<pinchartl> we can talk about it during the next multimedia meeting, I will + hopefully have a bit more information by then [18:33] +<pinchartl> and others will hopefully have time to give it a look too :-) +<pinchartl> I propose adjourning for today. does everybody second ? [18:34] +<kbingham> Seconded :) +<pinchartl> thank you for joining everybody [18:35] +<pinchartl> have a nice day +<uli___> cu +<neg> thanks all [18:36] +<kbingham> Thanks :) +<morimoto> pinchartl: it seems we need Kurokawa-san to next meeting ? +<morimoto> for DRM/KMS topis [18:37] +<morimoto> topis/topics +<pinchartl> morimoto: that could be useful +<morimoto> OK +<morimoto> thanks +<pinchartl> I'd like to think about it for a couple of days and then discuss + it with you and Magnus +<morimoto> OK. by chat ? [18:38] +<pinchartl> or e-mail [18:40] +<pinchartl> both are fine with me +<pinchartl> I'll likely chat with Magnus about this when he won't be busy with + "the Renesas guy" :-) [18:41] +<morimoto> OK :) +<morimoto> I can ask it to him, after kicking Renesas guy :) [18:42] +<morimoto> kbingham: can I ask you ? +<morimoto> kbingham: are you still there ? +<kbingham> morimoto: I'm here :) +<morimoto> thanks. does your question about FDP parent clock [18:43] +<kbingham> morimoto: How can I help ? +<morimoto> does it just parent clock for CPG ? +<morimoto> or do you have some issue on it ? [18:44] +<kbingham> morimoto: Thats correct. +<morimoto> OK, so you have no big issue now +<kbingham> morimoto: I don't think there is an issue currently. I can read and + write to the registers - so I assume we have it right, but I don't + have a datasheet clock diagram to confirm it is correct (and not + that I'm just lucky and something else has actually turned the + clock on for me) +<pinchartl> morimoto: it's the usual "what is the correct parent for the MSTP + clock" question. the FDP doesn't care about the clock rate so it's + no big deal, it's just about correctness [18:45] +<pinchartl> (I'll be back in 20 minutes) +<morimoto> Yeah, same here. +<morimoto> According to HW / datasheet guys, they decided to indicate it in + block diagram [18:46] +<morimoto> but, not yet completed +<morimoto> OK, thanks. I asked it to HW / datasheet guys. please wait [18:47] +<kbingham> morimoto: Ok - so just waiting on them finishing the document. +<morimoto> Thanks +<kbingham> morimoto: Thankyou :) diff --git a/wiki/Chat_log/20160608-mm-chatlog b/wiki/Chat_log/20160608-mm-chatlog new file mode 100644 index 0000000..4371ce8 --- /dev/null +++ b/wiki/Chat_log/20160608-mm-chatlog @@ -0,0 +1,441 @@ +Multimedia-chat-meeting-2016-06-08 + +<neg> hi all [16:52] +<morimoto> hi [16:53] +<uli___> hello +*** dammsan (~dammsan@s214090.ppp.asahi-net.or.jp) has joined channel + #periperi [16:55] +<morimoto> hi mag-mag +<dammsan> hi mori-mori +<kbingham> Morning' +<morimoto> Hi kbingham [16:56] +<dammsan> hi! +<kbingham> I guess it's 'good afternoon' for morimoto + dammsan :) [17:01] +<morimoto> Yes :) [17:02] +<pinchartl> sorry, I'm late +<pinchartl> hello everybody +<morimoto> hi +<kbingham> Hola! [17:03] +<pinchartl> I don't know if it's a good sign or not, but last night I was + dreaming we were having this meeting :-) +<kbingham> pinchartl: Well it was accurate ? +<kbingham> were any lottery numbers mentioned? [17:04] +<pinchartl> it involved people crashing at my place and three different IRC + clients, so hopefully not +<morimoto> It is called as "nightmare" in Japan :) +<pinchartl> :-) [17:05] +<pinchartl> so, topics for today +<pinchartl> Topic 1. Status check for the multimedia tasks [17:06] +<pinchartl> Topic 2. Additional '50%' tasks (both May and June) +<pinchartl> Topic 3. Next meeting +<pinchartl> anything else ? +<dammsan> i have one [17:07] +<dammsan> ideas for upcoming additional tasks for next quarter +<pinchartl> OK [17:08] +<pinchartl> let's start with the status update [17:09] +<pinchartl> in alphabetical order again, which I'll try not to mess up this + time +<pinchartl> kbingham: you're first +<pinchartl> FDP,v4.8,plan,kieran,Develop and upstream driver +<kbingham> I have the FDP1 powered up and successfully performing streaming + format conversion from all my tested inputs to all my tested + outputs. [17:10] +<kbingham> It is not de-interlacing yet - as that is the next step +<kbingham> but as we now have driver which is functional and performs 'a job' + I intend to post this as V1 to commence overall reviews, and while + that goes on, I will finish off the de-interlacing parts. + [17:11] +<kbingham> Any questions or more detail desired? [17:12] +<pinchartl> when do you plan to post the driver ? +<kbingham> I hope either end of today or tomorrow morning [17:13] +<kbingham> so .. imminently :) +<pinchartl> nice :-) +<pinchartl> and your target for de-interlacing ? +<kbingham> I'll be starting to push buffers through with both fields, and I + hope to have some basic functionality by the end of the week + [17:15] +<pinchartl> perfect +<pinchartl> so we're on track [17:16] +<kbingham> but that will be only 2d de-int, only supporting interleaved + buffers containing a top and a bottom field to start with to keep + it simple. +<kbingham> Yes, I hope so :) +<pinchartl> next, me +<pinchartl> DU,?,plan,laurent,IPMMU integration on Gen3 +<pinchartl> DU,?,plan,laurent,IPMMU support on Gen3 (through VSPD+FCP) +<pinchartl> no work done [17:17] +<pinchartl> DU,v4.8,public,laurent,VSPD Z-order support upstream (Gen3) +<pinchartl> I've pinged Mauro to get this merged, without success so far + [17:18] +<pinchartl> I'll keep trying +<pinchartl> VSP,?,plan,laurent,Fixed alpha support (VI6_DPR_*_ROUTE.FXA) + [17:19] +<pinchartl> no progress +<pinchartl> VSP,?,plan,laurent,CLU WARN_ON fix +<pinchartl> VSP,?,plan,laurent,CLU 2D and 3D mode support +<pinchartl> VSP,?,plan,laurent,CLU/LUT test application +<pinchartl> VSP,?,plan,laurent,CLU/LUT upstream API +<pinchartl> I've implemented and tested this [17:20] +<pinchartl> I will post the patches today +<morimoto> nice ! +<pinchartl> the target is v4.8 +<morimoto> "?" -> "v4.8" ? [17:21] +<pinchartl> yes +<pinchartl> VSP,?,plan,laurent,UDS regression fix +<pinchartl> I've reproduced the problem but haven't been able to fix it yet +<morimoto> Do you have any plan for it ? +<pinchartl> yes, I plan to continue working on it next week [17:22] +<morimoto> nice ! +<pinchartl> I'm not sure when a fix will be available as I don't know the root + cause yet [17:23] +<pinchartl> VSP,v4.8,plan,laurent,Fix suspend/resume crash +<pinchartl> no progress +<pinchartl> this will likely be delayed as it hasn't been included in the 50% + tasks for June +<pinchartl> VSP,v4.8,public,laurent,HGO operation mode selection [17:24] +<pinchartl> VSP,v4.8,public,laurent,HGO support upstream on Gen3 +<pinchartl> VSP,v4.8,public,laurent,HGO test application +<pinchartl> I've incorporated all review comments and will post a pull request + as soon as I can get Mauro to pull the other pending patches + [17:25] +<pinchartl> VSP,v4.8,public,laurent,V4L2 request API usable prototype [17:26] +<pinchartl> I have a new test application +<pinchartl> the latest code and test application will be posted by the end of + the week +<morimoto> How about this ? [17:27] +<morimoto> VSP,2016-06-30,request,laurent,update request API on renesas-driver +<morimoto> +<morimoto> do you have this plan ? +<pinchartl> I'll ask Geert to merge my working branches [17:28] +<morimoto> OK, I love you +<pinchartl> :-) +<pinchartl> that's it for me [17:29] +<pinchartl> dammsan: your turn +<pinchartl> VIN,?,plan,magnus,IPMMU integration on Gen2 +<pinchartl> VIN,?,plan,magnus,IPMMU integration on Gen3 +<pinchartl> VIN,?,plan,magnus,IPMMU support on Gen2 +<pinchartl> VIN,?,plan,magnus,IPMMU support on Gen3 +<pinchartl> no update I assume ? +<dammsan> yes, no progress +<morimoto> nice ! +<dammsan> except i fixed Gen2 IPMMU support a little while ago +<dammsan> will poke around with VIN next week +<pinchartl> was it broken ? [17:30] +<dammsan> i broke it in my multiarch v3 series +<dammsan> so i posted a v4 +<pinchartl> ok :-) +<dammsan> v3 and v4 include grouping of devices +<dammsan> based on their parent IPMMU instance +<pinchartl> I've seen the patches, I'll try to review them [17:31] +<dammsan> however i'd like to add tasks for audio-dmac and IPMMU =) +<dammsan> thanks! +<dammsan> it would be nice to get the multi-arch code accepted at some point +<pinchartl> would you like to add the tasks now ? +<dammsan> i'll try to keep my focus on this +<dammsan> yes, that would be nice +<pinchartl> go ahead, I'm all ears [17:32] +<dammsan> morimoto: how do you describe IPMMU integration for sound? +<dammsan> what is the device called? Audio-DMAC? +<morimoto> yes, but it using "SYS-DMAC". [17:33] +<dammsan> i propose copy-paste the VIN IPMMU tasks and use Audio-DMAC instead +<morimoto> I mean driver +<pinchartl> right, it's not audio-dmac, but sys-dmac [17:34] +<dammsan> ? +<dammsan> it is a separate DMAC for audio, right? +<morimoto> it is AUDIO-DMAC +<morimoto> Yes, defferent DMAC, but using same driver, I mean [17:35] +<pinchartl> sorry, rcar-dmac +<pinchartl> and the driver already has IPMMU support, doesn't it ? +<morimoto> (many local talk happen in Renesas, sorry) [17:36] +<dammsan> maybe so +<dammsan> but simply enabling it does not work +<dammsan> either issue with the IPMMU driver +<dammsan> or the DMA Engine slave side +<neg> I'm still trying to get the MMIO slave + IPMMU stuff merged [17:37] +<dammsan> neg: thanks +<dammsan> AUDIO-DMAC,?,plan,magnus,IPMMU integration on Gen2 +<dammsan> AUDIO-DMAC,?,plan,magnus,IPMMU integration on Gen3 +<dammsan> AUDIO-DMAC,?,plan,magnus,IPMMU support on Gen2 +<dammsan> AUDIO-DMAC,?,plan,magnus,IPMMU support on Gen3 +<dammsan> it needs more effort anyway =) +<pinchartl> ok +<dammsan> that's it from my side [17:38] +<pinchartl> morimoto: your turn [17:39] +<pinchartl> RSND,2016-06-30,public,morimoto,DT bindings for HDMI sound +<pinchartl> RSND,2016-06-30,plan,morimoto,dw-hdmi-ahb-audio prototype on Gen3 +<pinchartl> RSND,2016-06-30,plan,morimoto,HDMI SSI prototype on Gen3 +<pinchartl> RSND,2016-06-30,plan,morimoto,HDMI sound Upstream support without + hotplug on Gen2 +<pinchartl> RSND,2016-09-30,plan,morimoto,Hotplug support upstream on Gen3 +<morimoto> for graph DT support on ALSA side, as 1st step, I posted sound card + cleanup patches to ML +<morimoto> I posted v2 now, but no responce at this point [17:40] +<morimoto> It it was accepted, next step is I will post graph DT support for + ALSA SoC +<morimoto> it is already working in my local PC +<morimoto> but it is based on above cleanup patches, so, I'm now waiting. + [17:41] +<morimoto> And, after that, I can post HDMI sound support patches to ML +<morimoto> this is localy working, but have same background. So I'm waiting +<pinchartl> some background ? +<morimoto> About graph DT on ALSA, I have 1 concern +<morimoto> If video/sound both use graph DT, ALSA side want to know which port + is sound-endpoint [17:42] +<morimoto> pinchartl: sorry /some/same/ +<pinchartl> sorry, I misread :-) +<morimoto> I don't know how to solve this video/sound endpoint issue +<morimoto> 1 idea is adds new .type property. [17:43] +<morimoto> like .type = sound +<morimoto> or, use new endpoint, like sound-endpoint +<morimoto> But I don't know. no response, no review [17:44] +<morimoto> that's it from me +<pinchartl> shouldn't the type be a property of the port, not of the endpoint + ? +<morimoto> port/endpoint anything is OK. +<morimoto> just idea [17:45] +<pinchartl> ok +<morimoto> I think CC:ed you +<pinchartl> yes you did [17:46] +<pinchartl> I haven't had time to review the patches I'm afraid +<pinchartl> I'll see what I can do +<morimoto> no problem +<morimoto> basically, current sound is using "simple" card. and my cleanup is + for it. +<pinchartl> ok [17:47] +<morimoto> graph support will be on "simple" card + graph feature +<pinchartl> neg: you're next [17:48] +<pinchartl> ADV7482,v4.7,plan,niklas,Prototype on Gen3 +<pinchartl> ADV7482,v4.9,plan,niklas,Gen3 support upstream +<pinchartl> ADV7482,v4.9,plan,niklas,Interlace support upstream +<pinchartl> VIN,v4.7,plan,niklas,CSI2 prototype (Gen3) +<pinchartl> VIN,v4.8,plan,niklas,Gen3 support +<pinchartl> VIN,v4.8,plan,niklas,Scaler support (on Gen3) +<pinchartl> VIN,v4.8,public,niklas,New VIN driver without soc-camera (tested + on Gen2) +<pinchartl> VIN,v4.9,plan,niklas,CSI2 interlace support upstream (Gen3) +<pinchartl> VIN,v4.9,plan,niklas,CSI2 support upstream (Gen3) +<pinchartl> VIN,v4.9,plan,niklas,Gen3 support upstream (without CSI-2) +<neg> VIN Gen3 is public, but no review comments so far which is not so good + since it was a rather large series [17:49] +<neg> CSI-2 are almost done and no work started on ADV7482 other then make it + compile outside BSP [17:50] +<pinchartl> regarding CSI-2, does that include interlace support ? [17:51] +<neg> will hold of a bit on scaler and interlace support until I get some Ack + that the driver itself looks ok with regard to the new group concept + introduced for Gen3 +<pinchartl> ok +<neg> yes CSI-2 includes interlace support as far as I can test it. It is only + needed to figure out the bus speed AFIK [17:52] +<pinchartl> when you say almost done, is that prototype code, or code ready to + be submitted upstream ? [17:53] +<neg> I really would like to get some reviews on the VIN driver before I say + CSI-2 is upstream ready since they are quiet interconnected +<neg> but the code itself for CSI-2 I'd say is ready for upstream [17:54] +<pinchartl> ok +<pinchartl> can you ping me on VIN review at the beginning of next week ? +<neg> will do +<pinchartl> thanks [17:55] +<dammsan> about the "New VIN driver" task, is v4.8 still likely? +<pinchartl> I believe so, it nearly made it to v4.7 [17:56] +<neg> yes I think so, Hans sent the pull request to mauro for v4.7 but we + missed it. Have not seen anything sayng it wont be accepted for v4.8 + (that is for the Gen2 driver) +<dammsan> good, thanks!! +<pinchartl> how about "VIN,v4.7,plan,niklas,CSI2 prototype (Gen3)" ? [17:57] +<neg> I hope to post the prototype early next week and if the reviews are OK I + think it is ready for upstream [17:58] +<dammsan> we are waiting for paperwork, i'm the reason for slow handling +<dammsan> will finalise tonight +<dammsan> just need to be able to leave the renesas office +*** horms (~horms@reginn.isobedori.kobe.vergenet.net) has quit: Quit: Leaving +<neg> but as I state above CSI-2 might need more work if the VIN Gen3 driver + group concept gets rejected [17:59] +<pinchartl> ok +<pinchartl> uli___: you're next [18:00] +<pinchartl> DU,v4.7,plan,ulrich,Atomic API test program +<pinchartl> DU,v4.7,public,ulrich,HDMI output on Gen3 prototype +<pinchartl> DU,v4.7,prototype,ulrich,Test setup with HDMI output to HDMI input + loopback (without EDID) +<pinchartl> DU,v4.7,public,ulrich,EDID generation support for the HDMI + loopback test setup +<pinchartl> DU,v4.9,plan,ulrich,HDMI output on Gen3 upstream +<pinchartl> VIN,v4.8,public,ulrich,Add DV timings support to rcar-vin +<uli___> api test is public +<uli___> as is the new hdmi out prototype +<uli___> no progress on the rest [18:01] +<pinchartl> I don't think I've been CC'ed, where have you posted them ? +<uli___> the soc mailing list +<uli___> yes, no cc's, sorry about that [18:02] +<neg> I included all your VIN work for the Gen3 driver except the EDID parts +<pinchartl> no worries +<uli___> neg: saw that, thanks +<morimoto> do you have plan to update HDMI out for ES1.1 ? +<morimoto> I sent it on periperi ML [18:03] +<uli___> yes, but not this month +<uli___> we postponed that +<uli___> the loopback test goes first +<morimoto> OK +<pinchartl> are we still on track with +<pinchartl> DU,v4.7,prototype,ulrich,Test setup with HDMI output to HDMI input + loopback (without EDID) +<pinchartl> DU,v4.7,public,ulrich,EDID generation support for the HDMI + loopback test setup [18:04] +<pinchartl> will they be complete by the end of this month ? +<uli___> should be ok +<pinchartl> ok, thanks +<pinchartl> that's it then +<pinchartl> next topic +<pinchartl> Topic 2. Additional '50%' tasks (May & June) +<pinchartl> let's start with May [18:05] +<kbingham> sorry laurent +<pinchartl> yes ? +<kbingham> Could I ask one more Q on status :) - What is the status of the FCP + patches ? +<pinchartl> sure +<pinchartl> do you mean the ones you've posted ? [18:06] +<kbingham> pinchartl: No - the ones you posted :) +<kbingham> Are they already en route to ML? +<pinchartl> I've sent a pull request for v4.7, it got rejected on the grounds + of being sent too late, and I'm trying to get it in v4.8 + [18:07] +<kbingham> Ok. That clears that up for me :) +<pinchartl> so, additional tasks for May [18:08] +<pinchartl> has everybody sent their report ? +<neg> yes, report is sent and test procedure on elinux.org +<pinchartl> great [18:09] +<uli___> report and invoice sent :) also, instructions on elinux.org +<pinchartl> where on elinux.org by the way ? +<neg> http://elinux.org/R-Car/Tests:rcar-vin [18:10] +<uli___> http://elinux.org/User:Uli/Tests:KMS [18:11] +<dammsan> uli___: about resending the HDMI prototype, can you please try to do + it before the end of this month? +<dammsan> i'm asking because we want to check the result [18:12] +<uli___> i'll try to squeeze it in then +<dammsan> and timing wise if it happens next month it is too late to decide + next quarter additional task +<dammsan> thanks, please do!! +<pinchartl> uli___: could you move http://elinux.org/User:Uli/Tests:KMS to + http://elinux.org/R-Car/Tests:KMS ? [18:13] +<pinchartl> and add a link to http://elinux.org/R-Car/Devices ? +<dammsan> pinchartl: please keep the URLs half-stable, I've forwarded these to + people inside renesas for checking +<morimoto> dammsan: uli___: I believe it is for "HDMI-OUT for ES1.1" ? +<pinchartl> dammsan: we can add a redirection +<dammsan> pinchartl: sounds good, thanks! [18:14] +<pinchartl> neg: could you add a link to the VIN tests to + http://elinux.org/R-Car/Devices ? +<uli___> will do +<neg> pinchartl: sure +<pinchartl> thank you +<pinchartl> you can add sections for VIN and DU in + http://elinux.org/User:Uli/Tests:KMS [18:15] +<pinchartl> oops, I mean in http://elinux.org/R-Car/Devices +<pinchartl> no need for a long device description for now +<dammsan> uli__: can you please include the ES1.1 support in your HDMI out + prototype update? +<pinchartl> just create Tests section that link to the test pages +<neg> for future reference should we use 'R-Car/Tests:foo' ? There are also + for example 'Tests:SCIF-FIFO' +<uli___> dammsan: yes, that's the one thing [18:16] +<dammsan> great, thank you! +<pinchartl> neg: that sounds good to me +<pinchartl> now, about additional tasks for June [18:17] +<pinchartl> are we on track ? +<pinchartl> any issue ? +<uli___> i'm ok so far [18:18] +<neg> I'm a bit scared of doing both HDMI and i2c secondary device in one go + for ADV7482 but have not yet started so maybe the i2c part is easy :-) + Will let you know if I run into trouble [18:19] +<pinchartl> ok. please let me know as early as possible +<neg> will do, thanks [18:20] +<pinchartl> the I2C part should be easy +<pinchartl> Topic 3. Additional tasks for next quarter [18:21] +<neg> good, then I feel I'm on track +<pinchartl> dammsan: do you want to drive this ? +<dammsan> thanks +<dammsan> i'd like to specify tasks in two batches +<dammsan> one i'd like decide in the middle of this month +<dammsan> the next around meeting time in July +<dammsan> the deadlines for the two batches are supposed to be 8/M and 9/M + [18:22] +<dammsan> we may be able to do remote access for M3-W for the 8/M tasks +<dammsan> but real physical hardware access will not be possible for 8/M + target [18:23] +<dammsan> so instead of focusing on the entire quarter i'd like to begin with + focusing on the 8/M target that we should decide this month +<pinchartl> will it be possible for 9/M ? +<dammsan> maybe +<dammsan> kind of unlikely to be honest +<dammsan> we will know more during the meeting in japan [18:24] +<dammsan> as for what kind of tasks to deal with +<dammsan> i'd like to get a bunch of proposals +<pinchartl> ok +<dammsan> both from you guys +<dammsan> and also ask internal renesas if they have something for us [18:25] +<dammsan> we will meet f2f with multimedia people next week +<dammsan> hopefully that will result in an updated list +<pinchartl> ok +<pinchartl> should we start now, or would you like to get them by e-mail ? + [18:26] +<dammsan> i'l like you to start the process in your head +<dammsan> but after that email would be good =) +<dammsan> also agreeing on a schedule for fixing tasks would be good [18:27] +<dammsan> when do you intend to hold next chat meeting? +<pinchartl> in two weeks +<pinchartl> 22nd of June +<dammsan> thanks [18:28] +<pinchartl> is that fine for everybody by the way ? +<pinchartl> same time as today +<dammsan> so can we have title proposals done by the 17th? +<pinchartl> (morimoto: thanks for your e-mail with the status update, I've + incorporated it) +<dammsan> for some overview +<neg> pinchartl: time and date works for me [18:29] +<morimoto> pinchartl: thanks +<dammsan> pinchartl: scrap the 17th +<dammsan> pinchartl: i think we should provide you a list of requests from + renesas on the 17th +<dammsan> can we have the titles done by the 22nd then? [18:30] +<pinchartl> that's fine with me +<dammsan> thanks +<dammsan> so the time around 20th and later is needed to fix some tasks + [18:31] +<neg> Hum are there any information about schematics for M3-W? To look for + tasks it would help me to be able to look at how VIN is setup +<pinchartl> neg: uli___: kbingham: could you start thinking about tasks + proposals for Q3 in parallel ? I'd like to hear your ideas on what + is needed for multimedia support in the areas you're responsible + for (and possibly other areas as well) [18:32] +<pinchartl> dammsan: as we've discussed previously, video codecs, video test + framework (extension of the VSP test framework to cover other + devices and more features) and suspend/resume support for the VSP + driver are possible candidates for Q3 [18:33] +<kbingham> pinchartl: Ack. I'll have an explore around to see what's what :) + [18:34] +<pinchartl> kbingham: thanks +<morimoto> neg: basically H3 Salvator <-> M3 Salvator are same board. I can + say "Basically" :) +<morimoto> pinchartl: now I got VSP1 bug-report from BSP team. I will report + it to you tomorrow [18:36] +<pinchartl> morimoto: thank you. how many dozens of pages are there ? :-) + [18:37] +<neg> morimoto: ok thanks, so its the same utilisation of CSI-2 and no digital + video source for VIN? +<morimoto> neg: if it was so in H3, basically yes [18:38] +<morimoto> pinchartl: let me check +<pinchartl> we've covered all the topics for today. any last comment/question + from anyone ? +<dammsan> nope, thanks for your help! +<neg> I'm happy, thanks all [18:39] +<morimoto> pinchartl: it seems that BSP team already found issue +<morimoto> only 100 dozens [18:40] +<pinchartl> :-) +<pinchartl> I'll try not to have nightmares about them tonight +<pinchartl> thank you for attending everybody +<pinchartl> have a nice evening or day +<morimoto> Thanks, bye +<pinchartl> (report sent) +<morimoto> have a nice nightmares :) [18:41] +<dammsan> thanks guys +<kbingham> Cheers! +<uli___> cu [18:42] diff --git a/wiki/Chat_log/20160609-io-chatlog b/wiki/Chat_log/20160609-io-chatlog new file mode 100644 index 0000000..fdfc144 --- /dev/null +++ b/wiki/Chat_log/20160609-io-chatlog @@ -0,0 +1,286 @@ +--- Log opened Thu Jun 09 09:58:45 2016 +09:58 -!- wsa_ [~wsa@dslb-178-012-237-128.178.012.pools.vodafone-ip.de] has joined #periperi-io +09:58 -!- Irssi: #periperi-io: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal] +09:58 -!- Irssi: Join to #periperi-io was synced in 3 secs +10:00 -!- morimoto [~user@relprex3.renesas.com] has joined #periperi-io +10:00 -!- geertu [~geert@d54C36B15.access.telenet.be] has joined #periperi-io +10:00 < geertu> G'day +10:00 <@uli___> good morning +10:01 < morimoto> hi +10:01 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi-io +10:01 < shimoda> hi +10:01 < wsa_> hi all +10:02 -!- Irssi: #periperi-io: Total of 5 nicks [1 ops, 0 halfops, 0 voices, 4 normal] +10:03 < wsa_> geertu: short question before: I assume I don't need to send a pull-request for the H3-PFC-voltage-switching topic branch? +10:03 < wsa_> since you pick it up anyways +10:04 < geertu> wsa_: Nope, it was already included +10:05 -!- neg [~neg@unaffiliated/neg] has joined #periperi-io +10:05 -!- Irssi: #periperi-io: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal] +10:06 < neg> hi I have no IO task but maybe there are some residue from my old tasks so I hope it's OK i pop in? +10:06 < wsa_> so, i pinged simon also by mail, let's start +10:06 < wsa_> neg: you are very welcome here :) +10:07 < wsa_> let's have updates by person, again powered by an honest sort -R +10:07 -!- horms [~horms@reginn.isobedori.kobe.vergenet.net] has joined #periperi-io +10:07 < wsa_> hi simon +10:07 < horms> sorry i am late, thanks for pinging me! +10:07 < wsa_> morimoto: you are first this time +10:07 < wsa_> any news on schedule/requests/tasks? +10:08 < morimoto> not new item from me +10:08 < morimoto> Ahh +10:08 < morimoto> r8a7792 are now OK for upstreaming +10:08 < morimoto> that's it :) +10:08 < wsa_> that was good news in deed +10:08 < horms> thanks for sorting that out :) +10:09 < geertu> Yeah, Sergei is eagerly waiting for his patches to be applied +10:09 < wsa_> morimoto: do you know anything about khiem-san and the thermal driver? +10:09 < morimoto> good question +10:09 < morimoto> no response from him +10:09 < morimoto> I need to ask to him or BSP team +10:10 < wsa_> i can also ask him in the minutes from this meeting +10:11 < morimoto> thanks +10:11 < wsa_> i mean, he is also on the list, no need to bury you with proxy-work +10:11 < wsa_> ok +10:11 < wsa_> so, niklas is next, but as he mentioned already he is not assigned a task currently +10:12 < wsa_> and I heard no other feedback from the I2C DMA patches +10:12 < wsa_> so i think we are good here +10:13 < wsa_> then, it is my turn +10:13 < wsa_> i don't have an additional IO task for this month +10:13 < wsa_> some leftovers from the watchdog pretimeout (upstream discussions) +10:14 < wsa_> and some more playing with SDIO cards +10:14 < wsa_> main thing this month will be to create new additional tasks for next quarter +10:14 < wsa_> i expect this to start in next week +10:15 < wsa_> let's see if this will be a little more fluent than last quarter :) +10:15 < wsa_> that's from my side +10:15 < wsa_> shimoda: do you have any news? +10:16 < shimoda> i tried to debug EHCI + IPMMU on Gen3, but it doesn't work yet +10:17 < wsa_> pity +10:17 < shimoda> also I will do OTG support because some related framework is coming soon and TI guys requests me about it +10:17 < shimoda> usb3 suspend issue, i don't have any update +10:18 < shimoda> that's from my side +10:19 < horms> shimoda: are you planning to resubmit DTS patches for gen3 usb? +10:19 < wsa_> geert recently mentioned that CMA cannot be enabled because of USB +10:19 < wsa_> is this a known issue for you? +10:19 < shimoda> i will resubmit it after phy maintainer applied a bugfix patch +10:20 < wsa_> "OHCI-PCI doesn't seem to work with CONFIG_DMA_CMA=y (ohci-pci 0001:01:01.0: OHCI Unrecoverable Error, scheduling NEC chip restart)" +10:21 < wsa_> i guess we should make a task out of it +10:22 < shimoda> horms: if possible, i would like to resubmit without hsusb enable patch. is it acceptable? +10:23 < horms> Ok, so basically patches 1 - 3, but not patch 4 ? +10:23 < horms> I am referring to: [PATCH v2 0/4] arm64: dts: r8a7795: Add HSUSB device node and enable channel 0 of USB2.0 +10:23 < shimoda> horms: yes, but i should test such a case though :) +10:24 < wsa_> the question would be then if you have time for it or if it is okay if someone else has a look? +10:26 < shimoda> wsa_: about CMA issue in gen2, i don't have any information... but I guess this is related to memory range or somethings +10:26 < shimoda> the hardware cannot access 4GB over area +10:26 < horms> shimoda: I think I am ok with that approach +10:27 < wsa_> neg: how's your bandwidth currently? :) +10:28 < shimoda> horms: thanks! after I tested it, i will submit it. maybe tomorrow +10:28 < horms> thanks. no rush from my side :) +10:28 < neg> wsa_: a bit swamped for this month, next month nothing planed yet +10:28 < shimoda> horms: i got it :) +10:28 < wsa_> ok +10:28 < wsa_> looks like this task has to wait for July then +10:29 < wsa_> let's see about capacities then +10:30 < wsa_> ok, simon, your turn now +10:30 < horms> sure +10:31 < horms> I have made some progress on i2c demux +10:31 < horms> so far I have only focused on lager as I'd like to get the requirements sorted before extending to other boards +10:31 < horms> I think that may be close but as per my v2 positing my testing indicates that not all combinations work as i might have expected +10:32 < horms> That angle I'm not so sure how to move forwards on. I was kind of hoping wsa_ might look into it. +10:32 < geertu> horms: Are there bugs in the pfc-r8a7790 driver? +10:32 < horms> I have considered that +10:32 < horms> And I spent quite some time comparing pfc-r8a7790.c to the documentation I have +10:33 < horms> in particular the i2c related portions of both +10:33 < horms> but I have been unable to find anything that looks wrong +10:34 < wsa_> I have to admint I missed the "Discussion of Testing" part of your cover letter :( +10:34 < wsa_> however I managed to do that +10:34 < wsa_> will have a look later +10:35 < horms> No problem. It seems that I now have your attention :) +10:35 < horms> Thanks +10:35 < horms> Moving on +10:35 < wsa_> GPIO fallback worked for me on I2C2 +10:35 < geertu> BTW, have you seen Pantelis' DT connector work? +10:35 < horms> Ok. It didn't seem to work for me. Lets try to work out what the difference is. +10:35 < geertu> It's somewhat related +10:35 < horms> No, I have not seen that +10:36 < horms> --- +10:36 < geertu> The connector work abstracts the functionality that can be provided on a set of pins +10:37 < geertu> E.g. 2 pins can be used as 2 GPIOs, a UART, or an i2c bus. +10:37 < geertu> basically DT pinctrl on steroids +10:38 < horms> ok +10:38 < horms> it does sound somehow related +10:38 < geertu> We want to use a set of pins for a fixed functionality, but change the "driver" behind it +10:39 < geertu> It's too early to see how it can be integrated, though, but I wanted you to be aware of it. +10:39 < geertu> Pantelis also gave a presentation about it at ELC2016 +10:39 < geertu> perhaps Niklas saw it? +10:40 < neg> hum not that I can recall right now +10:40 < geertu> He wants to describe a connector (expansion port) in term of the functionality it can provide, so the user doesn't have to care about the deep details. +10:40 < geertu> Mostly focussed on BeagleBone series. +10:41 < geertu> That's it +10:41 < horms> Ok, thanks for the info. +10:41 < horms> My other task is Gen 3 SDHI DMA +10:42 < horms> The task is to upstream the Gen 3 SDHI DMA driver, which is different from the non-Gen3 SDHI DMA driver. +10:42 < horms> And in possible preparation for even more DMA drivers, e.g. for different Gen3 SoCs. +10:42 < horms> The approach I am taking so far is as follows. +10:42 < horms> 1. Rename sh_mobile_sdhi.c as renesas_sdhi.c (not strictly related) +10:43 < horms> 2. Refactor the TMIO DMA code so that it is provided by a set of callbacks rather than compiled-in function calls; Refactor the DMA SDHI to use this. +10:44 < horms> 3. Rename tmio_mmc_dma.c as renesas_sdhi_dma.c which reflects more closely what it is is, particularly after step 2. This is why I wanted the rename in step 2: to avoid adding another sh_mobile file when I am separately trying to convert to "renesas" +10:45 < horms> 4. Add Gen3 DMA code as a separate set of callbacks +10:45 < horms> The SDHI code itself knows which callbacks to instantiate based on the compat-string: its in the probe function +10:45 < horms> The two sets of DMA callbacks may be compiled in at the same time. Though there are some caveats: +10:46 < horms> The Gen3 SDHI code doesn't seem to compile on ARM32 so I don't allow that +10:46 < horms> s/SDHI/SDHI DMA/ +10:46 < horms> I protected the non-Gen3 SDHI code with COMPILE_TEST on ARM64 as it will never actually be used +10:47 < horms> -- end summary -- +10:47 < horms> Oh sorry, one more thing. +10:47 < wsa_> caveats sound OK to me +10:47 < horms> The DMA code moves from the tmio_core to renesas_sdhi kernel module +10:47 < horms> the DMA code is not a separate module either before or after my proposed changes +10:48 < wsa_> general approach sounds good, too +10:48 < wsa_> how many callbacks are needed? +10:48 < horms> The result seems fairly clean within the context of the spagetti arrangement that tmio/sdhi is +10:48 < wsa_> :D +10:48 < horms> I don't recall exactly, but around 1/2 a dozen +10:48 < horms> I made a little structure for them +10:48 < wsa_> good +10:49 < shimoda> about gen3 sdhi, i'm not sure the final decition but I heard later gen3 socs have SYS-DMAC interface +10:49 < horms> ok. so the current arrangement allows us some flexibility on a per-soc basis +10:49 < horms> based on the compat string +10:49 < wsa_> yes, this was a priority for this task +10:49 < shimoda> horms: oh, i see. it's nice! +10:49 < horms> but the implication is that if the DMA code differs then the compat string should also differ. i.e. no generic gen3 fallback +10:50 < horms> possibly I should only enable your Gen3 DMA code for the H3? +10:50 < geertu> Goodbye renesas,rcar-gen3-*? +10:50 < shimoda> I have information about H3 restriction. please don't use multiple sdhi DMAC channels :) +10:51 < horms> ok +10:51 < horms> geertu: that is the implication. but perhaps its not a good choice +10:51 < shimoda> after that, sometimes read data is lost +10:51 < horms> ok, so how might I enable multiple channels? +10:51 < horms> (or not!) +10:51 < shimoda> s/is lost/is delayed/ +10:52 < geertu> shimoda: probably this is about concurrent use? +10:52 < horms> geertu: would it be better to have a property of the sdhi node that indicates a flavour of dma to be used on gen3? +10:53 < shimoda> geertu: yes. if we use multime channels at the same time, read data is delayed. so, if driver do unmap soon, the data is lost +10:54 < wsa_> ouch +10:54 < shimoda> this restriction will be fixed in next ES. This issue has H3 ES1.1 and M3-W +10:54 < shimoda> Oops, H3 ES1.1 and M3-W have this issue +10:57 < horms> Ok. Perhaps we can move on. We can come back to this. e.g. when I've posted some patches +10:58 < wsa_> that hurts. given that SDHI also does eMMC on Gen3, only one DMA channel will affect either rootfs or SD card reading :/ +10:58 < wsa_> ok +10:58 < wsa_> geertu, how are things? ;) +10:59 < geertu> SCIF,v4.7,public,geert,Extend subsystem with GPIO-based software handling and hardware flow control +10:59 < geertu> v3 posted, no changes except for acks etc +10:59 < geertu> SCIF,?,noplan,?,Add support for hardware assisted modem-control +10:59 < geertu> included in v3 above (was also included in v2) +11:00 < geertu> SCIF,v4.8,plan,geert,SCIF FIFO flushing +11:00 < geertu> posted, test on elinux wiki +11:00 < geertu> (invoice/report May 31) +11:01 < geertu> SPI,2016-05-31,plan,geert,Implement initial SPI slave prototype support for R-Car Gen2 +11:01 < geertu> I'm doing this as a little side job, where time permits +11:02 < wsa_> great +11:02 < geertu> I've verified that the code from the BSP works, and allows to receive/transmit known-size messages, triggered by the SPI master +11:02 < wsa_> i hope it will be one of your additional tasks next quarter +11:02 < geertu> I've fixed the obvious hacks in the code (like redefining HZ :-) +11:03 < geertu> I'm thinking about DT / core changes needed to handle it properly +11:03 < geertu> I hope to post some minimal prototype / RFC around the deadline for ELCE submissions +11:04 < wsa_> wanna talk about it? :) +11:04 < geertu> That's the idea +11:04 < wsa_> cool +11:04 < geertu> Was your i2c slave code accepted before you submitted the presentation? +11:05 < wsa_> uuuuh +11:05 < wsa_> i think so +11:05 < wsa_> very likely +11:05 < geertu> Of course you were the maintainer ;-) +11:05 < wsa_> :) +11:06 < geertu> Well, the Kalray architecture is still not submitted upstream, while it's been presented at ELC2014 and ELCE2014 +11:06 < horms> FWIW, I usually present on code that is not yet upstream +11:07 < geertu> Good. +11:07 < wsa_> let's hope you will have some focus time to work on it next quarter. i am positive about that, though +11:07 < geertu> On a related note: Does anyone know what happened to the DRIF driver? +11:08 < horms> Not i +11:08 < wsa_> nope +11:09 < wsa_> okay, thanks geert +11:10 < wsa_> uli___: finally, your turn :) +11:10 <@uli___> i looked at the wiring on the lager board +11:10 <@uli___> for the sd over msiof thing +11:11 <@uli___> looks like magnus's hack should work exactly as on salvator-x +11:11 <@uli___> with some magic numbers exchanged +11:11 <@uli___> and it does need two connectors :) +11:11 <@uli___> that's it so far +11:11 < wsa_> really, cool +11:11 < wsa_> then i missed something when looking at the specs +11:12 < wsa_> did you get a zebax breakout adapter now? +11:12 <@uli___> no, just connectors +11:12 <@uli___> i refuse to pay 95 dollars for an electromechanical adapter :) +11:13 <@uli___> i think i'll solder it, with the hooks it really looks a bit dodgy +11:13 < geertu> Recently I've soldered some wires to a Samtec QTE40 for ape6evm remote control +11:14 < geertu> Glue it on a protoboard, and watch https://www.youtube.com/watch?v=i5MNLTc7YhY +11:15 < geertu> uli___: be ware you need to use cs-gpio to use msiof for mmc +11:15 < geertu> uli___: hardware-cs deasserts cs in between transfers +11:15 <@uli___> that's how it is in the damm hack +11:16 <@uli___> should work +11:16 < geertu> ok +11:16 < geertu> Note that msiof is broken on H3 ES1 +11:16 < wsa_> it's gen2 work +11:16 < horms> geertu: Video at URL above is not available in my country :( +11:16 < geertu> You'll have to wait for M3-W +11:17 < geertu> horms: http://www.nicovideo.jp/watch/sm22265444 ? +11:17 < geertu> http://elm-chan.org/docs/wire/wiring_e.html is the maker's site +11:18 < wsa_> uli___: and it seems you triggered a resend for the CANFD driver :) +11:18 <@uli___> yes :) +11:19 < neg> geertu: that is some serious wiring :-) +11:19 < wsa_> nice, let's see how that goes... +11:19 < wsa_> okay, i think we are done? +11:19 < wsa_> anything left? +11:20 < horms> not from my side +11:20 < wsa_> good then +11:20 < wsa_> thank you guys! +11:21 < wsa_> continued happy hacking ;) +11:21 < horms> thanks, and sorry again for being late +11:21 < wsa_> no problem +11:21 < morimoto> thanks +11:21 -!- horms [~horms@reginn.isobedori.kobe.vergenet.net] has quit Quit: Leaving +11:21 < morimoto> have a good weekend, bye +11:22 < neg> thanks all, bye +11:22 < geertu> neg: yeah, real cool video. +11:22 <@uli___> cu +11:22 < geertu> morimoto: Thanks, one more day to go for us :-) +11:22 < geertu> s/one/one + a halve/ +11:22 < morimoto> Hehe :) I will take day off tomorrow (^o^) +11:23 < geertu> thx, bye! +11:23 < neg> geertu: everytime I watch something like that I look at my electric junk pile and ask my self how hard can it be :-) +11:23 < shimoda> bye! +11:24 -!- shimoda [~shimoda@relprex2.renesas.com] has quit Quit: WeeChat 0.4.2 +11:24 < geertu> neg: I followed his principles to wire a pin header to a Samtec connector, using enameled copper wire salvaged from an old motor. +11:24 * wsa_ prefers to not watch the video then ;) +11:24 -!- morimoto [~user@relprex3.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +11:25 < geertu> geertu: Without watching the video, I would have failed. +11:25 < geertu> (or not started at all ;-) +11:26 < neg> geertu: that's a nice source of coated wire, never thought of it. But I'm a bit interessted in the wire "feeding" tool he uses need to get me one +11:27 < neg> soldering is a bit like golf that way, even if you are bad at it you think you will play better with more expensive gear... +11:27 < geertu> neg: I've also built one myself, from a broken propelling pencil ("vulpotlood") with a metal tip +11:27 < geertu> I didn't want to buy one before I could try it ;-) +11:28 < neg> ahh yes that would work, so no work for me today I need to build tools :) +11:29 < geertu> Or buy on http://www.conrad.com/ce/en/product/532630/Wire-wrapping-tool--PB-Fastener-079-001732G-1-pcs +11:31 < neg> when conrad started its swedish branch it was not good for my wallet, lots of nice stuff +11:31 < geertu> They can take a while to deliver... +11:32 < geertu> I received part of my last order May/B. +11:32 < geertu> I've received the last two remainings (one they did have in stock from the beginning!) earlier this week +11:33 < neg> yes if its out of stock it takes ages, bought a desk lamp wiht a magnifyinglass attahced think it was 10 weeks before I recived it +11:35 * geertu is still happy with the soldering station he had to buy to add the capacitors +11:36 < neg> still havent solderd mine, but I'm impressed that you managed it without heating the board first +11:37 < geertu> It doesn't look nice +11:37 < geertu> But the multi-meter agrees everything is soldered +11:38 < geertu> Didn't manage to make my board draw more than 1 A though +11:38 < geertu> Perhaps I have to join the multimedia group for that ;-) +11:39 < geertu> Ground planes are hard +11:39 < geertu> I soldered a 2-pin header for reset to the Raspberry Pi 2 Model B I won at last ELCE +11:39 < geertu> The reset pin was a piece of cake +11:40 < geertu> The GND pin was hard, as the copper circular pad was very small, and even such a small board has a heavy heat sucking ground plane +11:41 < neg> yes and when you work with replacable HW it's easier since if you mess up you can buy a new one, but breaking my Salvator-X I would say is a bad thing +11:41 < geertu> Interestingly, soldering a 50 pin header to my armadillo with the old 25W iron was easy before. +11:41 < geertu> Let's blame the very small circular pad... +11:42 < geertu> neg: You might get an ES1.1 sooner ;-) +11:42 < neg> ohh so thats how I get first in line +11:43 < neg> anyhow now I need to run to catch my lunch date, talk to you later +11:44 < geertu> Enjoy lunch, time to leave #periperi-io +11:44 -!- geertu [~geert@d54C36B15.access.telenet.be] has left #periperi-io [] +--- Log closed Thu Jun 09 12:11:13 2016 diff --git a/wiki/Chat_log/20160614-core-chatlog b/wiki/Chat_log/20160614-core-chatlog new file mode 100644 index 0000000..c60a3d4 --- /dev/null +++ b/wiki/Chat_log/20160614-core-chatlog @@ -0,0 +1,293 @@ +Core-chat-meeting-2016-06-14 + +10:03 < geertu> (filled) Agenda: +10:03 < geertu> 1. Upcoming Gen3 development for the Core group, +10:03 < geertu> 2. Control of CPG parent clocks, +10:03 < geertu> 3. CPG DTS clean up ("clock-output-names", CPG/MSSR, ...) +10:03 < geertu> 4. Gen3 firmware plan for special memory allocation control +10:03 < geertu> 5. Additional tasks for Q3 +10:03 < geertu> 6. Status check for tasks from last meeting - what is remaining? +10:04 < neg> I might drop out for a while during the meeting, got a water leak from the flat above and plumber on the way. So if I stop responding I be back as soon as I can. +10:04 < geertu> Topic 1. Upcoming Gen3 development for the Core group +10:05 < geertu> I will look into DT SMP/APMU support for new SoCs (r8a7793/r8a7794), as Sergei needs this too +10:06 < geertu> Anything else important going on? +10:08 < geertu> OK, nothing +10:08 < geertu> Topic 2. Control of CPG parent clocks +10:09 < horms> sorry, i was slow +10:09 < horms> about r8a7792 +10:09 < geertu> yes +10:09 < horms> it seems his patchset is getting very close +10:09 < horms> and SMP even works +10:09 < horms> but we did get burnt with SMP on the r8a7795 +10:09 < horms> (my fingers are still in bandages) +10:09 < geertu> using the deprecated smp ops +10:09 < horms> do you have any opinion on the smp aspects of his patchset? +10:10 < geertu> r8a7792 SMP is different. It should be similar to other Gen2. While r8a7795 depends on PSCI +10:10 < geertu> We should not merge his SMP patch/ +10:10 < geertu> as we decided to no longer add new per-SoC platform code for that +10:11 < horms> Ah! +10:11 < geertu> cfr. r8a7793 still lacking SMP support +10:11 < horms> ok +10:11 < geertu> Magnus did post patches for using that a while ago, which I have been rebasing and keeping around locally. +10:11 < horms> have you brought this to Sergei's attention? +10:11 < geertu> I'll rework that and post them to the mailing list. +10:11 < horms> ok +10:11 < geertu> After that, r8a7792 support shouldn't need any platform code for SMP. +10:12 < horms> so if Sergei wants his patches to go in quickly he should drop SMP support +10:12 < geertu> The complication here is that doing it without any platform code needs a SYSC device node in DT. +10:12 < geertu> Which we have for r8a7792 (and r8a7793 now). +10:13 < geertu> Hence the major mess is that some SoCs have it, others don't. +10:13 < horms> Don't tell Dirk :^) +10:13 < geertu> I'll have to look into that again to untangle the mess and create a patch set that moves us forward. +10:13 < horms> Is the way forwards to define a reference platform, get that working, then spread the love out to other SoCs? +10:14 < geertu> Yes, that's what Magnus already did. +10:14 < horms> Ok, and you are planning to revisit this? +10:14 < geertu> Yes. +10:14 < horms> Ok, got it. +10:14 < geertu> I had it locally (incl. for r8a7791) running for a long time. +10:14 < horms> I won't merge r8a7792 SMP without it +10:15 < horms> which from my pov should mean r8a7792 UP gets merged first +10:15 < geertu> If only we could drop backwards compatibility with old DT ;-) +10:15 < pinchartl> geertu: I won't oppose to that :-) +10:15 < horms> but Sergei can decide how fast he wants to move +10:15 < horms> geertu: it can be discussed with the BSP team if it is sufficiently important +10:17 < geertu> OK, so Sergei can continue, if he drops SMP for now. +10:17 < horms> agreed +10:18 < geertu> Next topic? +10:18 < geertu> Topic 2. Control of CPG parent clocks +10:19 < geertu> 1. How to set initial value. by DT? by C code? +10:19 < geertu> 2. We want to have max frequency? +10:19 < geertu> 3. We want to save power/frequency if no user? +10:19 < geertu> 4. Schedule? +10:19 < geertu> 5. Use cases from BSP team? +10:19 < geertu> a. MSIOF hi speed (?) need hi frequency +10:19 < geertu> Currently we just read the current values from the divider config registers +10:19 < geertu> For SDHI we have control of the parent clock (on R-Car Gen2) +10:20 < geertu> That is handled purely in the SDHI driver. +10:21 < geertu> My worries there are (a) that this is similar code that will end up in every single driver, and (b) that these drivers may run on platforms where they shouldn't touch the parent clock (cfr. SDHI changing the main peripheral clock on R-Mobile A1) +10:22 < geertu> Apparently the use case is increases the frequency of the MSIOF parent clock for faster SPI +10:22 < geertu> Morimoto-san: Is that correct? +10:23 < morimoto> Yes, it is +10:23 < morimoto> (at this point) +10:24 < pinchartl> regarding the initial value +10:24 < geertu> A quick solution would be to add similar code to the msiof driver like we did for sdhi +10:24 < pinchartl> we should read the value set by the boot loader(s) from the config registers to initialize the parent +10:25 < pinchartl> then there's the assigned-* DT clock properties that we can use +10:25 < pinchartl> it's not an ideal solution as it's more configuration data than a hardware description +10:25 < geertu> pinchartl: AFAIK we do read the initial value from the registers +10:25 < pinchartl> but it seems to be the upstream way of doing it +10:25 < geertu> pinchartl: Indeed, I don't like assigned-* at all +10:25 < geertu> pinchartl: Plus, for MSIOF you don't want to force this value. +10:25 < pinchartl> of course if there's a single consumer of the clock, then it would make sense for the driver to select the parent instead +10:26 < geertu> pinchartl: There are multiple MSIOFs +10:26 < pinchartl> the difficult case would be multiple consumers without assigned-* +10:26 < geertu> pinchartl: Some SPI slaves may be high-speed, others low-speed +10:26 < pinchartl> in that case the consumers would need to collaborate if you don't want to use assigned-* +10:26 < geertu> pinchartl: So it has to change dynamically +10:28 < geertu> I think MSIOF is also more complicated than SDHI as MSIOF has its own divider inside the module. +10:28 < geertu> So now you have two parameters: parent clock freq and per-device divider +10:29 < geertu> To get the wanted clock frequency, you can change one or both. +10:29 < geertu> Plus some other device may change the parent frequency behind your back, so you have to adapt the per-device divider +10:29 < geertu> if at all possible (and not out-of-range) +10:30 < geertu> And what if the parent frequency is changed while a transfer is in progress? +10:32 < pinchartl> that shouldn't be allowed +10:32 < horms> Are we expecting changes to occur at probe time or any time the driver feels like it? +10:32 < pinchartl> when you sya that some other device can change the frequency behind your back, to you mean another MSIOF device, or a completely unrelated device ? +10:32 < pinchartl> horms: at runtime unfortunately +10:33 < geertu> pinchartl: another MSIOF device (MSIOF parent is shared between MSIOF instances on Gen3) +10:34 < geertu> On Gen3, MSIOF parent is R8A7795_CLK_MSO +10:34 < horms> is it reasonable to wait for transfers to complete and then change the frequency? +10:34 < geertu> On Gen2, it's the shared MP clock +10:34 < geertu> horms: Sure +10:34 < pinchartl> geertu: then you need the drivers to collaborate +10:34 < geertu> but how to know? +10:35 < geertu> and how does the clock subsystem know a transfer is in progress? +10:35 < pinchartl> it doesn't +10:36 < pinchartl> that's for the driver to figure it out +10:36 < geertu> Ugh. +10:36 < geertu> So on Gen3, the msiof driver needs to know it shares a parent clock with other msiof instances? +10:37 < horms> do the instances use the same driver? +10:37 < geertu> On Gen2, it needs to know the parent clock is fixed (already handled ;-) +10:37 < pinchartl> some code might be moved to the ccf core if it's generic enough +10:37 < pinchartl> but there will be driver-specific code +10:37 < geertu> horms: Yes, spi-sh-msiof (assumed they use it for SPI, not for I2S) +10:37 < pinchartl> for instance you could extend the ccf api to add the ability to lock a clock +10:38 < pinchartl> while locked the frequency couldn't be changed by other drivers +10:38 < pinchartl> you'd have to decide what to do at unlock time though, whether frequency changes attempted while the clock is locked should be applied then +10:38 < pinchartl> or possibly use an unlock notifier +10:38 < geertu> I guess on some R-Mobile the MSIOF parent clock is shared with all other devices, and not fixed? +10:38 < pinchartl> but I'm not sure it would be useful in the ccf core +10:39 < pinchartl> as the msiof driver would need specific code to allow instances to collaborate to choose the frequency +10:39 < pinchartl> so it could as well handle the locking there too +10:40 < geertu> In the exterme case, the other instance has to wait until the first one releases the lock? +10:40 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi +10:40 < shimoda> hi +10:40 < geertu> Well, this definitely needs more thought... +10:40 < morimoto> In R-Mobile generation, if my memory was correct, we setuped parent clock in boot time as fixed rate. +10:40 < geertu> BTW, what do we do with SDHI, w.r.t. collaboration? +10:41 < horms> geertu: that was my first thought; and my second one (1. wait for lock 2. more thought) +10:41 < geertu> IIRC there are multiple SDHI parent clocks, but some are shared between two SDHI devices? +10:41 < morimoto> It doesn't have runtime exchange case +10:41 < geertu> morimoto: it = SDHI? +10:41 < morimoto> it = parent clock +10:42 < pinchartl> geertu: I'm not sure we need more thought, at this point I believe we need a prototype +10:42 < horms> I think it makes sense to handle this in the driver if it can be handled there. Once the implementation is all sorted out it could migrate into the core, if that makes sense. +10:42 < geertu> OK +10:42 < morimoto> We didn't expect that runtime parent clock exchange +10:42 < horms> I agree we need a prototype +10:42 < geertu> Sounds like an additional tasks for Q3 ;-) +10:43 < horms> morimoto: you mean that runtime clock exchange isn't a requirement at this point? +10:43 < geertu> " 3. We want to save power/frequency if no user? +10:43 < geertu> " +10:43 < morimoto> In R-Mobile generation ? Yes, it is not requirement. +10:44 < pinchartl> geertu: agreed regarding additional task. it might be more of a I/O task though +10:44 < morimoto> And it is not requirement on Gen3 too :) BSP team want to change initial rate only +10:44 < geertu> OK, so it's like SDHI, where we limited fiddling with the parent to Gen2 +10:44 < geertu> pinchartl: core + I/O +10:44 -!- horms2 [~horms@g1-27-253-251-9.bmobile.ne.jp] has joined #periperi +10:45 < geertu> "want to" != requirement? +10:45 < geertu> (Da evil twin brother has arrived?) +10:45 < morimoto> geertu: ? what is different ? +10:45 < horms> I'm trying to relocate. My twin is on my mobile. +10:46 < geertu> morimoto: OK, IC +10:46 < horms> morimoto: 1. Is it sufficient to do probe-time clock changes? 2. Is there an objection to run-time clock changes (as well) ? +10:46 < geertu> If it's just the initial value, it can be handled by assigned-rates +10:46 -!- horms [~horms@reginn.isobedori.kobe.vergenet.net] has quit [Quit: Leaving] +10:47 < morimoto> horms: 1. I think probe-time clock changes is very enough for BSP. +10:47 < geertu> But assigned-rates that has to take into account the whole system, which is complicated when someone uses DT overlays ;-) +10:47 < morimoto> horms: 2. I have no objection for run-time clock changes, but it is over-kill in my feeling +10:49 < geertu> In an SPI driver, you don't know the wanted frequencies during probe time +10:49 < geertu> Only when the SPI core calls .setup() +10:49 < geertu> When does DT assigned-rates kicks in? +10:50 < geertu> I assume it would not affect the MSIOF driver itself at all? +10:51 < horms2> I thought I saw that sdhi uses assigned-rates at probe time, but I could be mistaken +10:52 < morimoto> BSP team issue is that current MSIOF parent clock (= setuped by firmware ?) is not enough for hi speed. it is enough if CPG setup timing setups parent clocks more hi frequencies. +10:53 < geertu> horms2: It's parsed only in drivers/clk/clk-conf.c +10:53 < morimoto> .setup() can divide on each channels +10:53 < geertu> morimoto: Yes, it runs at 12.5 MHz instead of 66 MHz. +10:53 < pinchartl> geertu: MSIOF might want to change the parent clock frequency for two reasons, either because it's too low for the requested SPI frequency, or to achieve a more accurate SPI frequency +10:53 < geertu> pinchartl: Indeed +10:53 < pinchartl> in both cases a locked parent clock rate due to another transfer in progress wouldn't need to be treated as a fatal issue +10:54 < geertu> pinchartl: Yep +10:54 < pinchartl> the transfer could be performed at a lower than requested speed or at a less accurate speed +10:54 < pinchartl> but it also means that two identical transfer requests for the same device could lead to different speeds +10:54 < pinchartl> depending on the other transfers in progress +10:54 < geertu> pinchartl: Indeed. But the second instance should be able to lock the parent, too. So we need a R/W lock +10:54 < pinchartl> I wonder if that could be an issue for drivers +10:55 < pinchartl> the resulting speed wouldn't be deterministic +10:55 < geertu> pinchartl: Not for drivers, but for devices that have strict frequency requirements. +10:55 < pinchartl> at least from SPI drivers point of view +10:55 < geertu> I can imagine some device require to be driven at a specific frequency? Currently there's only max-frequency, and you usually get that +10:55 < pinchartl> although there's no guarantee in the SPI API that the requested speed will be honoured exactly (or with a certain accuracy) +10:56 < geertu> pinchartl: true +10:56 < pinchartl> what we guarantee today (at least in practice if not in theory) is that the speed will be the same for all transfers requested with the same speed +10:56 < pinchartl> that might change in the future +10:57 < pinchartl> I just wanted to mention the issue, it might not be a problem in practice +10:57 < geertu> Even if we don't support dynamic speed change, MSIOF instances are instantiated sequentially. +10:58 < geertu> So the first one decides? +10:59 < pinchartl> that's an open question +10:59 < geertu> OK, let's continue... +10:59 < geertu> Topic 3. CPG DTS clean up ("clock-output-names", CPG/MSSR, ...) +11:00 < geertu> This is a topic from Magnus +11:00 < geertu> 1. Can we do something to clean up the 32-bit ARM SoCs? +11:00 < geertu> 2. Can we make new SoC support slightly cleaner? +11:00 < geertu> 3. Shall we jump directly to CPG-MSSR for new SoCs and clean up the rest of the R-Car Gen2 +11:00 < geertu> family? +11:00 < geertu> But as he's not here, perhaps we should skip it? +11:01 < geertu> Or postpone till the end, if time permits? +11:01 < horms2> Probably a good idea +11:01 < geertu> Topic 4. Gen3 firmware plan for special memory allocation control +11:01 < morimoto> geertu: 1 question about parent clock. Does it become next quarter's SoW for someone ? +11:01 < geertu> morimoto: Probably +11:01 < morimoto> geertu: OK +11:02 < morimoto> geertu: Can you please add it to peripelist ? +11:02 < geertu> morimoto: It needs coordination with I/O +11:02 < morimoto> Ohh OK I see +11:03 < geertu> Morimoto-san: The mike (microphone) is yours, for topic 4 +11:03 < morimoto> OK, As I mentioned in periperi ML, our latest firmware is v2.8.0 +11:03 < morimoto> but, because of memory allocation control, it is custom version +11:04 < morimoto> Unfortunately, v2.9.0 has same feature +11:04 < morimoto> v2.10.0 will doesn't have it. +11:04 < morimoto> So, +11:04 < morimoto> I guess we need to indicate this issue on upsteam code somewhere ? +11:04 < geertu> The latest firmware we have (https://osdr.renesas.com/projects/linux-kernel-development/wiki/Periperi-2016-02) is v270 +11:05 < morimoto> Oops ? +11:05 < geertu> And I'm quite sure most people aren't even running that version yet ;-) +11:05 < morimoto> Indeed. So, because of this reason, I didn't uploaded v2.8.0 +11:06 < morimoto> Our customer already have v2.8.0 +11:06 < morimoto> So, if customer uses BSP only, there is no problem +11:06 < morimoto> If customer uses BSP firmware (= v2.8.0 or v2.9.0) and uses upsteam kernel +11:06 < morimoto> it doesn't work +11:07 < morimoto> (BSP kernel already has this solution) +11:07 < morimoto> If customer uses v2.8.0 or v2.9.0 firmware, but custom version, and uses upsteam, then no problem. +11:08 < morimoto> v2.10.0 + upsteam has no problem again +11:09 < morimoto> v2.8.0 and v2.9.0 has special memory allocation as default +11:10 < morimoto> So, we need to indicate it on somewhere ? +11:10 < geertu> Well, this is a temporary issue only, right? +11:11 < horms2> do you mean should we document this? +11:11 < morimoto> geertu: Yes, I think so. BSP team will explain this issue to customer +11:11 < morimoto> horms2: I'm not sure. but we will have confusion ?? +11:12 < horms2> probably +11:12 < geertu> We don't really have a place to document it, +11:12 < geertu> except by adding the section to the DTS +11:13 < morimoto> quick explain is enough ? how about comment area on r8a7795-salvator-x.dts ? +11:13 < morimoto> Not sure what should we do +11:14 < horms2> what about the elinux wiki? documenting it somehow in dt seems ok to me too +11:14 < morimoto> super big issue is that our firmware doesn't indicate its version. +11:15 < horms2> ew +11:17 < shimoda> if the function is enabled, the firmware mention somethings :) +11:17 < shimoda> NOTICE: BL2: Lossy Decomp areas +11:17 < shimoda> NOTICE: Entry 0: DCMPAREACRAx:0x80000000 DCMPAREACRBx:0x0 +11:17 < shimoda> NOTICE: Entry 1: DCMPAREACRAx:0x40000000 DCMPAREACRBx:0x0 +11:17 < shimoda> NOTICE: Entry 2: DCMPAREACRAx:0x20000000 DCMPAREACRBx:0x0 +11:17 < shimoda> this is disabled though +11:18 < shimoda> but, if enabled, DCMPAREACRBx value is not zero and the DCMPAREACRAx value is related to the memory area +11:19 < shimoda> but of course a software cannot understand it :) +11:20 < morimoto> If this feature was enabled, firmware setup its memory area on fixed location. So 2nd solution is that upsteam kernel support it +11:20 < morimoto> Opps firmware indicates its memory area on fixed location +11:21 < horms2> so it's difficult to detect at runtime? +11:22 < geertu> IIRC it's a register that can be read from secure mode only +11:23 < geertu> I would document it on the elinux wiki +11:23 < morimoto> If firmware uses it, it setups memory and indicates its area on fixed memory location. +11:23 < morimoto> I forgot detail, but for example, if firmware uses 0xAAAA0000 for indication +11:24 < geertu> Or will you send the DTS update straight to Linux, to prevent it being out of date? +11:24 < geertu> And what about -stable? +11:24 < morimoto> it will be 0xffffffff if disabled, and it will be 0xXXXXXXXX (= we can't use this area) if enabled +11:25 < shimoda> geertu: I prefer just document on the elinux wiki +11:25 < geertu> OK +11:25 < morimoto> It is easy solution +11:26 < shimoda> but I don't know morimoto-san's thinking about :) +11:26 < morimoto> My favorite is of course easy solution. +11:26 < morimoto> above is 2nd solution, but very PITA for us +11:27 < morimoto> that's it from me +11:28 * pinchartl has to go +11:28 < horms2> let's document it for now +11:28 < geertu> We also ran out of time +11:29 < morimoto> I will give you v2.10.0 of course. But do you want to have v2.8.0 or v2.9.0 custom verion ? +11:30 < morimoto> You can ask me via email :) +11:30 < horms2> good plan +11:32 < geertu> Who will document it on the elinux wiki? +11:33 < shimoda> renesas guys will document it (maybe me? :) ) +11:34 < geertu> Topic 5. Additional tasks for Q3 +11:34 < geertu> - M3 support (physical boards too late :-( +11:34 < geertu> - 64-bit memory handling +11:34 < geertu> I'm afraid we don't have time for this today +11:34 < geertu> Please submit your ideas to the mailing list +11:34 < geertu> Topic 6. Status check for tasks from last meeting - what is remaining? +11:35 < geertu> Any updates? +11:36 < neg> I hope to post a summary of the dmac branches I have looked in to today or tomorrow, following some patches I have extracted form them which I think are worth to keep +11:37 < horms2> geertu: how are r8a7796 clocks going merge wise? +11:37 < geertu> horms2: No response from the clock team to my pull request so far +11:37 < geertu> will ping them +11:37 < horms2> ok +11:37 < horms2> thanks +11:38 * geertu got crippled by gnome-terminal. Only two terminal windows are still working. +11:39 < horms2> boo +11:39 < geertu> Fixing that will kill my irc session... so... +11:39 < geertu> Time to conclude! +11:40 < horms2> good plan! +11:40 < geertu> Thanks for joining, have a nice continued day! +11:41 < geertu> (woow, the issue has fixed itself) +11:41 < geertu> Bye! +11:41 < shimoda> bye! +11:41 < morimoto> Thank you, bye diff --git a/wiki/Chat_log/20160622-mm-chatlog b/wiki/Chat_log/20160622-mm-chatlog new file mode 100644 index 0000000..76e039e --- /dev/null +++ b/wiki/Chat_log/20160622-mm-chatlog @@ -0,0 +1,605 @@ +h1. chat report 2016-06-22 + +Attendees: + +- Kieran +- Laurent +- Magnus +- Morimoto-san +- Niklas +- Ulrich + + +Topic 1. Status check for the multimedia tasks +---------------------------------------------- + +- FDP,v4.8,prototype,kieran,Develop and upstream driver + +A first version has been posted to the linux-media mailing list. Since then, +the driver is now adapted to using a job queueing system to allow abstracting +fields from v4l2 buffers, and de-interlacing tested with PREVFIELD, NEXTFIELD, +FIXED2D. 3D deinterlacing is in progress, it requires tracking video buffers +between m2m job runs. + +Gstreamer does not (yet) support asynchronous input/output which means testing +is not as elegant as for the earlier stages. V4l2-compliance tests pass +without failure. + +A new version of the patches is expected for this weekend. + +- DU,?,plan,laurent,IPMMU integration on Gen3 +- DU,?,plan,laurent,IPMMU support on Gen3 (through VSPD+FCP) + +No progress. + +- VSP,v4.7,merged,laurent,Plane alpha + pixel alpha (on Gen3) + +Patches have been merged in the linux-media tree. + +- VSP,?,plan,laurent,Fixed alpha support (VI6_DPR_*_ROUTE.FXA) +- VSP,?,plan,laurent,UDS regression fix +- VSP,v4.8,plan,laurent,Fix suspend/resume crash + +No progress. The latter will not make it to v4.8. Setting the target back to ? +as the job hasn't been scheduled yet. + +- VSP,v4.8,public,laurent,CLU 2D and 3D mode support +- VSP,v4.8,public,laurent,CLU WARN_ON fix +- VSP,v4.8,public,laurent,CLU/LUT upstream API +- VSP,v4.8,public,laurent,CLU/LUT support submitted upstream on Gen3 +- VSP,v4.8,public,laurent,HGO operation mode selection +- VSP,v4.8,public,laurent,HGO support upstream on Gen3 +- VSP,v4.8,public,laurent,HGO test application + +Patches are public, waiting a few more days for review before sending a pull +request for upstream merge. A pull request has been sent for renesas-drivers +already. + +- VSP,v4.8,public,laurent,HGO test application + +HGO tests are included in http://git.ideasonboard.com/renesas/vsp-tests.git. +They currently require to use a special branch of yavta which will be merge +into master once the HGO kernel patches are accepted. + +The same apply to the LUT/CLU tests. Every new feature added to the VSP driver +now comes with related test cases. + +- VSP,v4.8,public,laurent,Horizontal/vertical flip support + +New task. The patches are public, waiting a few more days for review before +sending a pull request for upstream merge. A pull request has been sent for +renesas-drivers already. + +- VSP,v4.8,prototype,laurent,Rotation support + +New task. A prototype exists, will be cleaned up and posted, hopefully today. +Rotation doesn't work properly, it corrupts the output image. I will send a +report describing the issue in detail and Morimoto-san will share it with the +BSP and/or HW team. + +- VSP,?,prototype,laurent,V4L2 request API upstream +- VSP,v4.8,public,laurent,V4L2 request API usable prototype + +An updated patch series is currently being tested with the new MC test tool +developed by Intel. Test instructions are being written. The patches will be +posted along with test scripts and test instructions, the target is Monday. + +Both Intel and Google have expressed interest for the request API, I expect +them to help pushing for the request API to be accepted upstream. + +- DU,v4.9,plan,laurent,Fix 3 planes formats + +New request from the BSP team. Support for formats with 3 planes is broken. +Setting the target to v4.9, but the fix might come earlier. + +- AUDIO-DMAC,?,plan,magnus,IPMMU integration on Gen2 +- AUDIO-DMAC,?,plan,magnus,IPMMU integration on Gen3 +- AUDIO-DMAC,?,plan,magnus,IPMMU support on Gen2 +- AUDIO-DMAC,?,plan,magnus,IPMMU support on Gen3 + +No progress + +- VIN,?,plan,magnus,IPMMU integration on Gen2 +- VIN,?,plan,magnus,IPMMU integration on Gen3 +- VIN,?,plan,magnus,IPMMU support on Gen2 +- VIN,?,plan,magnus,IPMMU support on Gen3 + +A local prototype exists, setting the status to prototype. It should be posted +in the not too distant future. + +- RSND,2016-06-30,public,morimoto,DT bindings for graph sound +- RSND,2016-06-30,prototype,morimoto,dw-hdmi-ahb-audio prototype on Gen3 +- RSND,2016-06-30,prototype,morimoto,HDMI SSI prototype on Gen3 +- RSND,2016-06-30,plan,morimoto,HDMI sound Upstream support without hotplug on +Gen2 + +The clean up patches needed to develop OF graph sound support are still under +review. The maintainer has been pinged but hasn't replied yet. + +Work is now focused on the next step of OF graph support. Simple OF graph for +ALSA is fine, but the complex features are more challenging. + +Updating the target to v4.10. + +- RSND,2016-09-30,plan,morimoto,Hotplug support upstream on Gen3 + +No progress. + +- ADV7482,v4.7,plan,niklas,Prototype on Gen3 + +It turns out work was needed in the V4L2 framework to support the ADV7482. +Patches have been posted for that, and the rcar-vin driver is being updated +accordingly. + +The ADV7482 prototype should be posted on Monday and the updated rcar-vin +driver soon after that. The prototype won't support controls in the first +version as that will require more work in the V4L2 framework. + +- VIN,v4.7,plan,niklas,CSI2 prototype (Gen3) + +The CSI-2 prototype is done and should be posted on Monday (pending possible +modifications needed by the rework of the ADV7482). + +- VIN,v4.8,plan,niklas,Gen3 support + +The code has been posted publicly. + +- VIN,v4.8,plan,niklas,Scaler support (on Gen3) +- ADV7482,v4.9,plan,niklas,Gen3 support upstream +- ADV7482,v4.9,plan,niklas,Interlace support upstream +- VIN,v4.9,plan,niklas,CSI2 interlace support upstream (Gen3) +- VIN,v4.9,plan,niklas,CSI2 support upstream (Gen3) +- VIN,v4.9,plan,niklas,Gen3 support upstream (without CSI-2) + +No progress. + +- DU,v4.7,plan,ulrich,Atomic API test program + +The task is complete. The elinux.org wiki will be updated today. + +- DU,v4.7,public,ulrich,HDMI output on Gen3 prototype + +The task is complete. An updated version with a fix for ES1.1 will be posted. + +- DU,v4.7,prototype,ulrich,Test setup with HDMI output to HDMI input loopback +(without EDID) + +The task is complete. + +- DU,v4.7,public,ulrich,EDID generation support for the HDMI loopback test +setup + +No progress, documentation will be written before end of June. + +- VIN,v4.8,public,ulrich,Add DV timings support to rcar-vin +- DU,v4.9,plan,ulrich,HDMI output on Gen3 upstream + +No progress. + + +h1. chat log + + +<neg> morning [16:54] +<morimoto> hi +<uli___> good morning +<neg> or evening depending on where you are :-) +<morimoto> Yes, here is evening :) [16:55] +<pinchartl> sorry I'm a bit late [16:57] +<pinchartl> hello everybody [16:58] +<pinchartl> will Magnus join us today ? +<morimoto> hi, Magnus is here +<pinchartl> perfect, let's start +<pinchartl> (taking my notes) +<pinchartl> topics for today [16:59] +<pinchartl> Topic 1. Status check for the multimedia tasks +<pinchartl> Topic 2. Additional '50%' tasks (June) +<pinchartl> Topic 3. Additional '50%' tasks (Q3) +<pinchartl> Topic 4. Next meeting [17:00] +<pinchartl> anything else ? +<morimoto> nothing from me :) +<pinchartl> ok [17:01] +<pinchartl> let's go for the alphabetical order again [17:02] +<pinchartl> Kieran told me he might not be able to join today +<pinchartl> kbingham: are you there ? +<pinchartl> FDP,v4.8,prototype,kieran,Develop and upstream drive [17:03] +<pinchartl> r +<pinchartl> a first version of the driver is public +<pinchartl> more work has gone into supporting the different deinterlacing + modes +<pinchartl> including some internal refactoring related to that +<kbingham> almost here - but on a very dodgy connection :( [17:04] +<pinchartl> no worries +<pinchartl> when do you expect to post a v2 ? +<kbingham> FDP1 - driver now adapted to using a job queueing system to allow + abstracting fields from v4l2 buffers, and de-interlacing tested + with PREVFIELD, NEXTFIELD, FIXED2D. +<kbingham> Need to track VB痴 between m2m job runs to finish the 3d + deinterlacing. +<kbingham> Gstreamer does not (yet) support asynchronous input/output which + means testing is not as elegant as for the earlier stages. +<kbingham> V4l2-compliance tests pass without failure. [17:05] +<kbingham> but yes - what laurent said :) +<pinchartl> when do you expect to post a v2 ? [17:07] +<kbingham> I'm hoping at the weekend (although now that is going to be the end + of the weekend :) ) +<pinchartl> ok :-) [17:08] +<pinchartl> my turn then +<pinchartl> DU,?,plan,laurent,IPMMU integration on Gen3 +<pinchartl> DU,?,plan,laurent,IPMMU support on Gen3 (through VSPD+FCP) +<pinchartl> no progress +<pinchartl> VSP,?,plan,laurent,Fixed alpha support (VI6_DPR_*_ROUTE.FXA) + [17:09] +<pinchartl> VSP,?,plan,laurent,UDS regression fix +<pinchartl> VSP,v4.8,plan,laurent,Fix suspend/resume crash +<pinchartl> no progress +<pinchartl> the latter will not be ready for v4.8 +<pinchartl> I'll set the target version back to ? as the job hasn't been + scheduled yet [17:10] +<pinchartl> VSP,v4.8,public,laurent,CLU 2D and 3D mode support +<pinchartl> VSP,v4.8,public,laurent,CLU WARN_ON fix +<pinchartl> VSP,v4.8,public,laurent,CLU/LUT upstream API +<pinchartl> VSP,v4.8,public,laurent,CLU/LUT support submitted upstream on Gen3 +<pinchartl> VSP,v4.8,public,laurent,HGO operation mode selection [17:11] +<pinchartl> VSP,v4.8,public,laurent,HGO support upstream on Gen3 +<pinchartl> patches are public, I'll wait a few more days for review and send + a pull request [17:12] +<morimoto> 1 request from BSP +<morimoto> they want to have CLU 2D/3D mode on renesas-driver +<pinchartl> I've sent a pull request to Geert for renesas-drivers +<morimoto> OK, nice [17:13] +<pinchartl> VSP,v4.8,public,laurent,HGO test application +<pinchartl> HGO tests are included in + http://git.ideasonboard.com/renesas/vsp-tests.git [17:14] +<pinchartl> they currently require to use a special branch of yavta +<pinchartl> I will merge that branch back to master once the HGO kernel + patches are accepted +<pinchartl> same for the LUT/CLUT tests [17:15] +<pinchartl> every new feature I add to the VSP driver now includes + corresponding test cases +<pinchartl> VSP,v4.8,public,laurent,Horizontal/vertical flip support [17:16] +<pinchartl> that's a new task +<pinchartl> the patches have been posted as well and are included in the + renesas-drivers pull request [17:17] +<pinchartl> VSP,v4.8,public,laurent,Rotation support +<pinchartl> new task as well [17:18] +<pinchartl> I haven't published the patch yet +<pinchartl> (the status should be prototype, not public) +<pinchartl> I'll try to do so today +<pinchartl> but it doesn't work properly :-/ +<pinchartl> http://www.ideasonboard.org/vsp-rotation.png [17:19] +<pinchartl> that's what I get after rotation +<pinchartl> http://www.ideasonboard.org/vsp-rotation-expected.png [17:20] +<pinchartl> is the expected result +<pinchartl> I'm stuck at this point and suspect a hardware problem +<pinchartl> morimoto: I'll send you a mail with a description of the problem + after posting the patch +<pinchartl> could you forward it to the BSP team ? [17:21] +<morimoto> OK, I will ask it to BSP/HW team +<pinchartl> I'd like to know if they have tested rotation on H3 +<pinchartl> thank you +<pinchartl> VSP,?,prototype,laurent,V4L2 request API upstream [17:23] +<pinchartl> VSP,v4.8,public,laurent,V4L2 request API usable prototype +<pinchartl> after rotation that's the only task I have left for this month +<pinchartl> I have an updated patch series +<pinchartl> I'm testing it with the new MC test tool developed by Intel + [17:24] +<pinchartl> I'm also writing down the test instructions +<pinchartl> and will post the patch series with the instructions and test + scripts +<pinchartl> my target is Monday +<pinchartl> that's all for me [17:25] +<pinchartl> morimoto: any other request from the BSP team ? +<morimoto> they want to know about request API status [17:26] +<morimoto> Ahh, and we got pixsel format request from BSP team +<pinchartl> I think I've just addressed that question. another note on this + topic, both Intel and Google are interested in the request API, so + I expect to be pushed by them too +<morimoto> I posted it to this Multimedia meeting invitation [17:27] +<morimoto> You addressed which one ? +<morimoto> request API ? pixsel format ? +<pinchartl> request API. the target for the new patch series with the test + scripts and test instructions is Monday [17:28] +<pinchartl> let me check my e-mails [17:29] +<morimoto> OK, thanks +<pinchartl> when did you post it ? [17:30] +<pinchartl> right now ? +<pinchartl> ah no +<pinchartl> on Friday +<morimoto> Yes, Friday +<morimoto> it includes 2 request [17:31] +<morimoto> not a big deal, but we can get BSP team smile :) +<pinchartl> I'll fix that [17:32] +<morimoto> gr8 +<morimoto> And we got request from BSP team, but it is very big topic +<pinchartl> when do they need it ? [17:33] +<morimoto> it can be next PeriPeriCon (!= MiniPeriCon) topic +<pinchartl> (the 3 planes formats) +<morimoto> They already have patch on locally, so whenever is OK +<pinchartl> ok +<pinchartl> I'll see if I can fix that for v4.8 but it might be too short, + there's only a few weeks left [17:34] +<morimoto> ok, no problem +<pinchartl> what's the new very big topic ? +<morimoto> They want to use VSP without cache [17:35] +<morimoto> -> no copy +<pinchartl> where is there a copy ? +ERC> /no copy/zero copy/ +*** no: Unknown command +<pinchartl> and where does the VSP use case ? +<morimoto> s/no copy/zero copy/ +<pinchartl> buffers are mapped with uncached mappings +<pinchartl> and video frames are not copied +<morimoto> I forget detail, but they have something. [17:36] +<morimoto> Anyway, it can be PeriPeriCon topic +<pinchartl> can you find out what this is about and send an e-mail with more + information ? +<morimoto> OK, will do [17:37] +<pinchartl> thank you +<pinchartl> next, dammsan +<pinchartl> AUDIO-DMAC,?,plan,magnus,IPMMU integration on Gen2 +<pinchartl> AUDIO-DMAC,?,plan,magnus,IPMMU integration on Gen3 +<pinchartl> AUDIO-DMAC,?,plan,magnus,IPMMU support on Gen2 +<pinchartl> AUDIO-DMAC,?,plan,magnus,IPMMU support on Gen3 +<pinchartl> VIN,?,plan,magnus,IPMMU integration on Gen2 +<pinchartl> VIN,?,plan,magnus,IPMMU integration on Gen3 +<pinchartl> VIN,?,plan,magnus,IPMMU support on Gen2 +<pinchartl> VIN,?,plan,magnus,IPMMU support on Gen3 +<pinchartl> no progress ? [17:38] +<morimoto> Please wait. MagPeri is fighting his headache +<dammsan> hey guys [17:39] +<pinchartl> hi Magnus +<dammsan> FYI, i've prototyped VIN bits with local code now +<dammsan> on Gen2 and Gen3 +<dammsan> so they can maybe move from plan to local if there is such thing? + [17:40] +<dammsan> no progress about AUDIO-DMAC +<pinchartl> nice, thanks +<pinchartl> there's no such thing as local, maybe prototype ? [17:41] +<dammsan> yeah, sure +<dammsan> the code is not public yet [17:42] +<dammsan> but i intend to send it out in the not so distant future +<dammsan> i saw that the IOMMU maintainer pinged about how to merge +<dammsan> so i need to act on that +<dammsan> anything else? if not i'll head back into paper work land =) +<pinchartl> that's all, good luck with the paperwork [17:43] +<pinchartl> oh, I forget about this task +<pinchartl> VSP,v4.7,merged,laurent,Plane alpha + pixel alpha (on Gen3) +<pinchartl> patches have been merged +<pinchartl> (in the linux-media tree) [17:44] +<pinchartl> next, morimoto +<pinchartl> RSND,2016-06-30,public,morimoto,DT bindings for graph sound + [17:45] +<pinchartl> RSND,2016-06-30,prototype,morimoto,dw-hdmi-ahb-audio prototype on + Gen3 +<pinchartl> RSND,2016-06-30,prototype,morimoto,HDMI SSI prototype on Gen3 +<pinchartl> RSND,2016-06-30,plan,morimoto,HDMI sound Upstream support without + hotplug on Gen2 +<pinchartl> RSND,2016-09-30,plan,morimoto,Hotplug support upstream on Gen3 +<morimoto> I posted clean up patch which is 1st step for OF graph sound + support +<morimoto> it is still under review +<morimoto> I sent ping mail to maintainer, but no response yet [17:46] +<morimoto> Now, I'm development next step +<morimoto> ALSA sound have many features. +<morimoto> I'm working for this "many features" with OF graph +<morimoto> simple OF graph + sound is already OK [17:47] +<morimoto> I'm fighting with "complex features" + OF graph now +<morimoto> ALSA need to more of_graph_xxx() function/macro :) +<morimoto> over from me +<pinchartl> thank you [17:48] +<pinchartl> the first 4 tasks have 2016-06-30 as their target date +<pinchartl> should we update that ? +<morimoto> I think so +<morimoto> If you don't give me penalty :) [17:49] +<pinchartl> I'll let you sort that out with the BSP team :-) +<pinchartl> what should be the new target ? +<pinchartl> maybe a kernel version instead of a date, to match the other tasks + ? [17:50] +<morimoto> It seems this clean up patch-set itself (= 1st step) taks long + term... +<morimoto> s/taks/takes/ +<morimoto> and OF graph patch will taks more time... [17:51] +<morimoto> +3 month ? +<pinchartl> that's fine with me +<morimoto> Thanks +<pinchartl> v4.10 then ? [17:52] +<morimoto> Could you add above "pixel" tasks to peripelist ? +<morimoto> pinchartl: Yes nice +<pinchartl> I've added "DU,v4.9,plan,laurent,Fix 3 planes formats" [17:53] +<morimoto> OK, nice +<morimoto> BTW, you can use "make ver" on peripelist if you want to have + version base output +<pinchartl> thanks [17:54] +<pinchartl> neg: your turn +<pinchartl> ADV7482,v4.7,plan,niklas,Prototype on Gen3 +<pinchartl> ADV7482,v4.9,plan,niklas,Gen3 support upstream +<pinchartl> ADV7482,v4.9,plan,niklas,Interlace support upstream +<pinchartl> VIN,v4.7,plan,niklas,CSI2 prototype (Gen3) +<pinchartl> VIN,v4.8,plan,niklas,Gen3 support +<pinchartl> VIN,v4.8,plan,niklas,Scaler support (on Gen3) +<pinchartl> VIN,v4.9,plan,niklas,CSI2 interlace support upstream (Gen3) +<pinchartl> VIN,v4.9,plan,niklas,CSI2 support upstream (Gen3) +<pinchartl> VIN,v4.9,plan,niklas,Gen3 support upstream (without CSI-2) +<neg> CSI2 is done I hope, but have not posted it yet if something comesup + with the rework for adv7482 but will post it soon [17:55] +<neg> adv7482 is started but it turnd out work was needed on the v4l + framework, I have posted patches for that [17:56] +<neg> right now I'm updating the rcar-vin driver to use the new v4l feature + needed to use adv7482 and after that I will repost the rcar-vin driver + also addressing your review comments [17:57] +<neg> plan is to post csi-2 and adv7482 prottypes on monday and the updated + rcar-vin soon after that [17:58] +<neg> I plan to not support controlls for the adv7482 in the prototype since + more work is needed in v4l to support that for our use case +<neg> VIN,v4.8,plan,niklas,Gen3 support is public [17:59] +<pinchartl> do you think it will make it to v4.8 ? [18:00] +<pinchartl> (Gen3 support for VIN, not ADV7482 and CSI-2- +<neg> I think I can get the patches updated in time but I think review is + going to drag out due to the complexity needed to support the runtime + input selection [18:01] +<neg> so I do not feel confident about that [18:02] +<pinchartl> ok, v4.9 then [18:03] +<pinchartl> same for scaler support ? +<pinchartl> ah wait +<pinchartl> "VIN,v4.8,plan,niklas,Gen3 support" isn't for upstream +<pinchartl> so v4.8 is fine +<neg> yes same for scaler, I really would like reviews on the group concept + before I add scalers to the mix making it even more complex [18:04] +<pinchartl> ok [18:06] +<pinchartl> regarding controls for ADV7482 +<pinchartl> have you seen Hans' proposal ? +<neg> only what he posted in #v4l +<pinchartl> that's what I was referring to [18:07] +<pinchartl> ok, thanks for the report +<pinchartl> next, uli___ +<pinchartl> DU,v4.7,plan,ulrich,Atomic API test program +<pinchartl> DU,v4.7,public,ulrich,HDMI output on Gen3 prototype +<pinchartl> DU,v4.7,prototype,ulrich,Test setup with HDMI output to HDMI input + loopback (without EDID) +<pinchartl> DU,v4.7,public,ulrich,EDID generation support for the HDMI + loopback test setup +<pinchartl> VIN,v4.8,public,ulrich,Add DV timings support to rcar-vin [18:08] +<pinchartl> DU,v4.9,plan,ulrich,HDMI output on Gen3 upstream +<uli___> no progress, basically +<uli___> nothing for public consumption, at any rate +<pinchartl> how about "DU,v4.7,plan,ulrich,Atomic API test program" ? [18:09] +<uli___> same as last time, i.e. it's out +<uli___> i didn't move the wiki pages, though :) +<uli___> sorry about that +<pinchartl> could you please do so today, and link to the page from + http://elinux.org/R-Car/Devices ? [18:10] +<uli___> ok +<pinchartl> thank you +<pinchartl> regarding "DU,v4.7,public,ulrich,HDMI output on Gen3 prototype" + [18:13] +<pinchartl> what's the status of the latest code ? +<pinchartl> and do you plan to send an update ? +<uli___> yes, a small one, with the fix for es1.1 +<morimoto> that's nice for me +<pinchartl> thanks [18:14] +<pinchartl> I'll mark the task as complete +<morimoto> We will have other solution for this kind of ESx support. it can be + MiniPeriCon topic +<uli___> i won't be able to attend; please keep me up-to-date on that [18:15] +<morimoto> Oops, indeed +<morimoto> I created MiniPeriCon / RenesasCon wiki page [18:16] +<pinchartl> about "DU,v4.7,prototype,ulrich,Test setup with HDMI output to + HDMI input loopback (without EDID)", is there documentation + available in the elinux.org wiki ? +<morimoto> you can check log +<uli___> pinchartl: none yet [18:17] +<pinchartl> do you plan to add that this quarter ? +<pinchartl> (meaning in the next 8 days :-)) [18:18] +<uli___> yes, i consider it part of the add. task +<pinchartl> thank you +<pinchartl> that's it for the tasks check [18:19] +<pinchartl> Topic 2. Additional '50%' tasks (June) +<pinchartl> we have +<pinchartl> - VIN CSI-2 Support Prototype +<pinchartl> - - ADV7482 Driver Prototype +<pinchartl> - VSP CLU Improvements +<pinchartl> - VSP Rotation Support +<pinchartl> - HDMI Input/Output Loopback for R-Car Gen2 [18:20] +<neg> VIN CSI-2 on track will be posted latest on monday +<pinchartl> (scratch the last one, bad copy & paste) [18:21] +<neg> ADV7482 have local prototype but want to do more work to only have one + device for both the 1-lane and 4-lane outputs hope to be done and post + it on Monday +<pinchartl> (no, don't scratch it, it was the right copy & paste :-)) [18:22] +<neg> if I find that more work is needed in the v4l framework to support this + I will post my local prototype +<pinchartl> - FDP Support on Gen3 [18:23] +<pinchartl> neg: thanks +<pinchartl> I see that both prototypes will be posted for the end of the + month, that's enough for me +<pinchartl> on my side VSP CLU is ready and VSP rotation partially implemented + as explained before [18:24] +<pinchartl> h/v flip works, rotation doesn't +<pinchartl> we've already discussed HDMI loopback and FDP support +<pinchartl> so we seem to be on track +<pinchartl> Topic 3. Additional '50%' tasks (Q3) [18:25] +<pinchartl> Q3 will be split in two batches +<pinchartl> we need to agree on the first batch before the end of this month +<pinchartl> and we'll discuss the second batch during peripericon [18:26] +<pinchartl> we have proposed tasks for the first batch +<pinchartl> I've already discussed them with neg +<pinchartl> uli___: what's your opinion about working on the following ? +<pinchartl> - VIN HDMI input EDID on Gen2 (1 week) +<pinchartl> - Gen2 VIN integration (1 week) [18:27] +<pinchartl> the first one is about replacing the hardcoded EDID that Hans + complained about with something fit for upstream +<pinchartl> the second one is quite light and is about integrating VIN in DT + for all the Gen2 boards +<uli___> for what period of time would that be? +<pinchartl> both are upstream-focussed [18:28] +<pinchartl> they are due for mid-August +<pinchartl> you can start whenever you want :-) +<uli___> i see +<uli___> i'll have to check with geert and wolfram first, but generally i'd be + fine with that +<pinchartl> so you have 6 weeks allocated for additional tasks in Q3 [18:29] +<uli___> yes +<pinchartl> 3 weeks per batch +<pinchartl> those two tasks cover two weeks, there would be one week for core + or I/O +<pinchartl> if Geert or Wolfram need you for more than a week we can possibly + trim it down a bit on the multimedia side [18:30] +<pinchartl> I'd like to keep VIN HDMI input on Gen2 +<pinchartl> but dammsan might have a different opinion +<uli___> yes, i'd prefer that, too +<pinchartl> so, assuming there's no issue with time allocation between groups, + the above seems ok to you ? [18:31] +<uli___> i'm ok with the tasks, yes +<pinchartl> thank you +<pinchartl> kbingham: are you still there ? +<kbingham> pinchartl: yes, I'm here +<dammsan> pinchartl: different opinion? =) [18:32] +<pinchartl> dammsan: on what you think is more important in case Ulrich needs + to spend more time on core or I/O and less on multimedia +<pinchartl> kbingham: I've started discussing tasks and budget for Q3 for you + with Magnus, this is still ongoing, I'll get back to you ASAP + about that [18:33] +<dammsan> pinchartl: i just think that simon is good at doing integration, and + ulrich has good hacking skill +<dammsan> but you'll figure it out =) +<dammsan> i'm fine with current setup [18:34] +<pinchartl> dammsan: so we have the same opinion, perfect +<dammsan> yes +<kbingham> pinchartl:. ok +<pinchartl> Topic 4. Next meeting [18:35] +<pinchartl> keeping the current bi-weekly schedule, that would be the 6th of + July +<pinchartl> same time as today +<pinchartl> would that work for everybody ? +<neg> works for me [18:36] +<kbingham> works for me. And I won't be on the end of a piece of string either + :) +<uli___> me, too +<pinchartl> :-) [18:37] +<pinchartl> kbingham: let me know when your internet connection will allow you + to discuss new tasks +<morimoto> it works for me too +<pinchartl> dammsan: for you too ? [18:38] +<pinchartl> I'll assume that's a yes [18:39] +<pinchartl> that's all for today +<kbingham> pinchartl: Ack. +<pinchartl> thank you everybody for attending +<pinchartl> don't forget the reports for this month +<pinchartl> I know you all love them +<uli___> it always goes with an invoice; that works for me :) [18:40] +<neg> pinchartl: do you want copies of our reports so you too can enjoy them + :-) +<pinchartl> neg: I'll pass this time, thank you :-) +<pinchartl> neg: I'll pass this time, thank you :-) [18:41] +<pinchartl> (oops) +<morimoto> pinchartl: unfortunately I can't report to you :) +<pinchartl> I'll enjoy the elinux.org wiki only +<pinchartl> morimoto: you can if you really insist, and I promise I won't read + the report in that case :-) +<pinchartl> (report and invitation for next meeting sent) [18:42] +<morimoto> pinchartl: hehe OK [18:43] +<morimoto> So, can I go back to home ? [18:53] +<pinchartl> you can go wherever you want :-) [18:54] +<morimoto> Hehe, OK. Thank you for chat meeting. [18:55] +<morimoto> Bye Bye diff --git a/wiki/Chat_log/20160627-io-chatlog b/wiki/Chat_log/20160627-io-chatlog new file mode 100644 index 0000000..d28d5d4 --- /dev/null +++ b/wiki/Chat_log/20160627-io-chatlog @@ -0,0 +1,124 @@ +--- Log opened Mon Jun 27 09:59:23 2016 +09:59 -!- wsa_ [~wsa@dslb-178-008-249-215.178.008.pools.vodafone-ip.de] has joined #periperi-io +09:59 -!- ServerMode/#periperi-io [+ns] by morgan.freenode.net +09:59 -!- Irssi: #periperi-io: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal] +09:59 -!- Irssi: Join to #periperi-io was synced in 0 secs +10:01 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi-io +10:02 -!- geertu [~geert@d54C36B15.access.telenet.be] has joined #periperi-io +10:02 < geertu> Oops, I was in #renesas-io ;-) +10:02 <@wsa_> :) +10:02 < shimoda> :) +10:03 <@wsa_> hello shimoda-san +10:03 < shimoda> hello wolfram-san +10:04 <@wsa_> in japan is rainy season now, or? +10:04 <@wsa_> (i need to pack my stuff for Japan today) +10:04 < geertu> Not only in Japan :-( +10:04 <@wsa_> haha +10:04 -!- uli___ [~uli@81.17.25.194] has joined #periperi-io +10:06 <@wsa_> hi uli +10:06 < uli___> hello +10:07 < shimoda> wsa_: yes, japan is rainy season now. but, in tokyo area not so much +10:08 -!- khiemnguyen_ [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi-io +10:09 <@wsa_> hi khiem +10:10 <@wsa_> so, let's start +10:10 <@wsa_> simon wanted to skip +10:11 <@wsa_> News from your side (order created by sort -R again) +10:11 <@wsa_> uli___: you are the first one today +10:12 <@wsa_> how are things? +10:12 < uli___> i'll test the sd via msiof thing today; let's hope it doesn't blow anything up +10:12 < uli___> nothing else yet +10:13 <@wsa_> i saw the canfd driver hit linux-next which is good news +10:13 < uli___> indeed +10:13 <@wsa_> so your plans about the SDHI Gen2 DMA task? +10:14 < uli___> rsn, but not necessarily before the end of the month... +10:15 <@wsa_> i see +10:16 <@wsa_> thanks +10:16 <@wsa_> geertu: your turn now +10:16 < geertu> SCIF,v4.8,public,geert,Extend subsystem with GPIO-based software handling and hardware flow control +10:16 < geertu> SCIF,v4.8,public,geert,Add support for hardware assisted modem-control +10:17 < geertu> Are now in tty-next +10:17 < geertu> SCIF,v4.8,public,geert,SCIF FIFO flushing +10:17 < geertu> SPI,v4.9,plan,geert,Implement initial SPI slave prototype support for R-Car Gen2 +10:17 < geertu> First RFC sent. So far only one comment about the DT binding. +10:18 <@wsa_> nice +10:18 < geertu> In addition, I submitted a presentation about it for ELC-E +10:19 <@wsa_> i'll keep the SPI slave state to planned though until you got an additional task for it. OK? +10:19 <@wsa_> (which we planned for 9/m) +10:20 < geertu> There will be more work to implement review comments and polish it +10:20 <@wsa_> sure thing +10:21 <@wsa_> lot's of good news, geert. thanks! +10:21 <@wsa_> shimoda: you are next +10:23 <@wsa_> shimoda: ? +10:23 < shimoda> about IPMMU issues on Gen3, no update +10:23 < shimoda> about suspend problems, no update +10:23 < shimoda> about add OTG support, I got some feedback from some ones, I trid to fix some is +10:23 < shimoda> sues first before I send the support +10:23 < shimoda> oops the last line +10:23 < shimoda> to fix some issues first before I send the support +10:23 < shimoda> done +10:24 <@wsa_> i see +10:25 <@wsa_> so, OTG target is probably v4.9 then? +10:25 < shimoda> @wsa_: I think so +10:25 <@wsa_> ok +10:26 <@wsa_> shimoda: any updates what DMA engine the SDHI will have on H3 ES2.0? +10:28 < shimoda> I heard that SDHI with SYS-DMAC support will have on H3 ES2.0, but it is as secret... +10:29 <@wsa_> OK, I'll treat is as such +10:29 <@wsa_> at least a pointer :) +10:29 <@wsa_> thank you, shimoda-san +10:30 <@wsa_> khiemnguyen_: any news from you? +10:32 < khiemnguyen_> I will send v2 to fix Morimoto-san comments & Geert comments today or tomorrow. +10:32 <@wsa_> nice +10:33 < khiemnguyen_> Then, by E/June, I hope it can be merged into renesas-drivers if there's no other comments. +10:34 <@wsa_> so, good chances it can make it into v4.8 then, I'd think +10:36 <@wsa_> BTW are you interested in further IO tasks? if so, what topics are you interested in/familiar with? +10:38 < khiemnguyen_> wsa_: yes. I hope Thermal sensor will go to v4.8. +10:39 < khiemnguyen_> About IO tasks, I prefer working with Watchdog. +10:40 <@wsa_> ok, thanks +10:40 <@wsa_> i currently don't have a task there, though +10:40 < geertu> I think Magnus considers watchdog to be part of core +10:41 <@wsa_> fine with me +10:41 <@wsa_> okay, /me is last +10:41 <@wsa_> not much hacking here +10:42 <@wsa_> mainly creating/reviewing additional tasks :/ +10:42 <@wsa_> we will have 2.5 of them next month due to other priorities +10:43 <@wsa_> simon will be finishing SDR104 for SDHI +10:43 <@wsa_> I will do maintenance all over the place +10:43 <@wsa_> and Geert will fix clocks for MSIOF (combined IO/core task) +10:44 <@wsa_> so, that's that +10:44 <@wsa_> I noticed M3 will have a NAND controller +10:45 <@wsa_> so, who has NAND experiences here? :) +10:45 < geertu> 7400? +10:45 <@wsa_> heh +10:45 < shimoda> :) +10:46 <@wsa_> more like ONFI NAND flashes +10:46 < shimoda> in some sh micon, I has an experience about NAND controller +10:46 <@wsa_> i also worked on NAND controllers during my Pengutronix times +10:47 <@wsa_> uli___: what about you low level hacker? ;) +10:47 < geertu> shimoda: micon = unmarried? +10:47 < uli___> nand flash is of the devil :) +10:47 < uli___> i stay away from it +10:48 < geertu> uli___: So what's inside the SD card you're playing with? +10:48 < shimoda> oops, sh4 CPU or something, I meant :) +10:48 <@wsa_> uli___: i see you do have experience :D +10:50 <@wsa_> any other topics from your side? +10:50 < shimoda> about gen3 NAND controller, I'm not sure BSP team intend to support it or not +10:50 < shimoda> should i confirm it? +10:51 <@wsa_> shimoda: would be interesting to know, yes +10:51 < shimoda> wsa_: I got it. I will confirm it. +10:51 <@wsa_> shimoda: so far, there is no request for an upstream driver, right? +10:54 < shimoda> @wsa_: sorry for the late response. yes, I think so. +10:55 <@wsa_> ok then +10:55 <@wsa_> let's close this meeting for today +10:56 <@wsa_> it was a bit slow today, maybe we need to change the style a little? +10:56 <@wsa_> like with sending status updates previously by mail +10:56 <@wsa_> and then only talk about issues showing up? +10:57 < shimoda> I think that's a good idea +10:58 <@wsa_> let's talk about this in japan further +10:58 <@wsa_> until then, have a good time all +10:58 <@wsa_> and see you +10:59 < shimoda> bye! +10:59 < geertu> thx, bye +10:59 < khiemnguyen_> bye +10:59 < uli___> bye +10:59 -!- shimoda [~shimoda@relprex1.renesas.com] has quit Quit: WeeChat 0.4.2 +--- Log closed Mon Jun 27 11:14:38 2016 diff --git a/wiki/Chat_log/20160628-core-chatlog b/wiki/Chat_log/20160628-core-chatlog new file mode 100644 index 0000000..68be471 --- /dev/null +++ b/wiki/Chat_log/20160628-core-chatlog @@ -0,0 +1,287 @@ +Core-chat-meeting-report 2016-06-28 + +----------------------------------------- +Topic 1. Upcoming Gen3 development for the Core group + + - Geert: + - Updated APMU patch series + - r8a7796 SYSC has been pulled by Simon + - r8a7796 CPG/MSSR is still in clk limbo + - Simon: Basic integration for r8a7796 is done + - Ulrich will test his r8a7796 patches on hardware soon + - Khiem will send v2 of the CPUFreq patches in early July + + +----------------------------------------- +Topic 2. CPG DTS clean up ("clock-output-names", CPG/MSSR, ...) + + 1. Can we do something to clean up the 32-bit ARM SoCs? + 2. Can we make new SoC support slightly cleaner? + 3. Shall we jump directly to CPG-MSSR for new SoCs and clean up the rest of + the R-Car Gen2 family? + + Moving to CPG-MSSR is an option, but needs cleanup of MODEMR handking first. + Related questions from Morimoto-san, with discussed answers: + 1. How to handle MODEMR register on rcar-gen3-cpg.c ? + It has fixed address on C code. + We would like to know its plan + + [PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for obtaining + mode pin state + (http://www.spinics.net/lists/linux-renesas-soc/msg04289.html) + + 2. ESx.y handling. + Some device needs to care about its ESx.y number, and (unfortunately) + we need it on upstream. + We already agreed about this handling by using "compatible" string + on DT in previous (?) PeriPeriCon. + And according to Magnus, Geert already has a patch to expend + "compatible" strings when boot time automatically ? + We would like to know its plan + + [PATCH/RFC 0/1] soc: renesas: Add DT fixup code for backwards + compatibility (https://lkml.org/lkml/2016/6/1/742) + + Development of those two patch series will continue... + + +----------------------------------------- +Topic 3. Status check for tasks from last meeting - what is remaining? + + - Simoda-san will document Gen3 firmware requirements on the eLinux wiki + - Niklas sent out v8 of DMAC+IPMMU, waiting for ack from Russell + +----------------------------------------- +Core-chat-meeting-2016-06-28 +----------------------------------------- + + +10:01 < geertu> Welcome to today's Renesas Core Group Meeting +10:02 < horms> I need to take a break from ~11:00 - ~11:15 as I'm at a conference. Apologies for any inconvenience that may cause. +10:02 < geertu> I'm also at a remote place, due to planned work on the powerline infrastructure in my street. +10:02 < geertu> Agenda: +10:02 < geertu> 1. Upcoming Gen3 development for the Core group, +10:02 < geertu> 2. CPG DTS clean up ("clock-output-names", CPG/MSSR, ...) +10:02 < geertu> 3. Status check for tasks from last meeting - what is remaining? +10:03 < geertu> I want to repost the slightly updated APMU series. +10:03 < geertu> I wanted to give the ARM people one more day to ack the enable method binding, but in the mean time Simon closed his tree :-( +10:04 < geertu> horms: Can you still make an exception, or does it have to wait for v4.9? +10:04 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi +10:04 < horms> actually i announced I will close it tomorrow +10:05 < horms> and this seems to be a worthy exception in any case +10:05 < horms> If you could finalise the patches today that would be great +10:05 < horms> Is that possible? +10:05 < geertu> horms: Oh cool, right you are in my time zone ;-) +10:05 < horms> sorry for not making that clearer +10:05 < horms> yes, i'm in your zone this week and next +10:05 < geertu> I'll do my best (once the power is back etc.) +10:06 < horms> will there be soc changes that are dependencies for DT changes (sorry, its a while since I looked over the patches) +10:06 < morimoto> horms: can you send email to us about your new address / phone ? +10:07 < geertu> horms: Of course, there are always such dependencies when moving functionality from C to DT :-( +10:07 < geertu> horms: BTW, any feedback on "[PATCH v2 0/5] ARM: dts: renesas: Update console parameters"? +10:07 < horms> morimoto: sure, i have an address now. I assume you want both the address in Amsterdam and the one in Kobe +10:07 < horms> geertu: sorry for sitting on those console changes +10:07 < morimoto> horms: Yes please +10:08 < horms> basically I am ok with them because they don't touch any important SoCs from a BSP/customer PoV +10:08 < geertu> horms: And we made the same change for the important SoCs anyway +10:08 < horms> I will see about queuing them up unless there are objections - e.g. right now +10:08 < geertu> OK, thx. +10:09 < horms> geertu: yes, I know. Those changes were more carefully planned than is obvious from examining git log +10:09 < horms> with regards to SoC->DT changes. Thanks, I will mentally prepare for that. +10:10 < geertu> Any other Upcoming Gen3 development for the Core group? +10:11 < horms> Is r8a7796 PFC core? +10:11 < geertu> (shall I write a script for random interrogation, like Wolfram did?) +10:11 < geertu> Yes, PFC is core +10:12 < horms> From me the Basic integration I had scheduled seems to be done. I anticipate more integration in the near future. But the details are under discussion (with you :) +10:12 < horms> uli___: are you handling PFC for r8a7796 these days? +10:12 < uli___> yes +10:12 < geertu> I'm afraid it's gonna miss today's renesas-drivers +10:13 < uli___> i have to wait to get remote access to m3-w to try it, at least once :) +10:14 < horms> ok, what is the hold-up there? +10:14 < uli___> i only asked for it an hour ago :( +10:14 < horms> ok +10:15 < dammsan> actually 25 minutes ago according to my email +10:15 < geertu> r8a7796 SYSC has been pulled by Simon +10:15 < geertu> r8a7796 CPG/MSSR is still in clk limbo +10:16 < geertu> dammsan: Are you travelling close to light speed? ;-) +10:17 < dammsan> well, i usually track days and not minutes =) +10:19 < geertu> Any other Upcoming Gen3 development for the Core group? +10:20 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] +10:20 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi +10:21 < dammsan> I wonder what happened with that timer issue simon was debugging with the JTAG +10:22 < dammsan> and if it is the same thing that Geert is chasing RCU with? +10:22 < horms> I reached a dead end with my investigation there +10:22 < geertu> Was that emev2/kzm9d? +10:22 < horms> At this point I still have the JTAG (2) but no board. +10:22 < horms> yes, it was +10:22 < geertu> neg: Do you have JTAG? +10:24 < neg> I have a cheep clone not sure how good it is +10:24 < geertu> sheep or cheap? +10:24 < neg> used it for Cortex-M3 work so not sure if it works for Renesas boards, but if there is work I will buy one that works +10:24 < dammsan> neg: i can bring one to you if you happen to be in sweden +10:25 < dammsan> or you may as well get a new one +10:25 < geertu> Paul had some more suggestions to try, but I haven't found time for that yet. +10:25 < dammsan> geertu: can it be related to shared-override cache handling? +10:25 < geertu> And for me the board is remote. And doesn't do earlycon. +10:25 < neg> dammsan: yes I'm in Stockholm until it's time to go to Tokyo +10:26 < dammsan> neg: i'll bring one then +10:26 < dammsan> i'm leaving here on thursday +10:26 < geertu> dammsan: There's no pl310 cache controller +10:26 < geertu> But you do remind me that I should try with more errata config options enabled. +10:27 < dammsan> only l1? +10:27 < geertu> I think so. There's no L2 in DT. +10:27 < dammsan> hm... +10:27 < dammsan> but it should only affect things if we have bus mastering drivers +10:28 < dammsan> which we dont i think +10:28 < dammsan> only PIO +10:28 < geertu> Yes +10:28 < neg> dammsan: sure name a time and place and I can come and pick it up +10:28 < dammsan> adding earlycon may be rather simple +10:28 < dammsan> neg: thanks will do +10:29 < geertu> Next topic? +10:29 < geertu> Topic 2. CPG DTS clean up ("clock-output-names", CPG/MSSR, ...) +10:29 < geertu> 1. Can we do something to clean up the 32-bit ARM SoCs? +10:29 < geertu> 2. Can we make new SoC support slightly cleaner? +10:29 < geertu> 3. Shall we jump directly to CPG-MSSR for new SoCs and clean up the rest of +10:29 < geertu> the R-Car Gen2 family? +10:30 < geertu> This was proposed by Magnus for last meeting, but we didn't cover it due to lack of time, and lack of Magnus +10:30 < dammsan> =) +10:31 < geertu> We can definitely move to CPG-MSSR. The conversion is not that difficult, and easy to verify using /sys/kernel/debug/clk/clk_summary +10:31 < geertu> It does depend on sorting out the MODEMR accesses. +10:31 < geertu> One of them (arch timer frequency) has been removed. +10:32 < dammsan> geertu: we can keep old CPG + MSTP drivers around too for DT compatibility, right? +10:32 < geertu> dammsan: Yes we can. +10:33 < geertu> It's just that the current scheme of calling into the CPG driver from arch/arm/mach-shmobile to pass the mode pin state doesn't fly when you have two possible drivers to call into. +10:33 < dammsan> yeah +10:33 < dammsan> i never liked that one +10:33 < dammsan> and i tried to encourage people to do something else +10:33 < geertu> Yeah, we should have called into platform code from the clk driver instead. +10:34 < geertu> The second user of the mode pins is MD21 checking for SMP bringup. +10:34 < dammsan> yeah +10:34 < geertu> Which we should be able to remove soon too, thanks to Sergei diving into BSP codde. +10:34 < dammsan> uhm... +10:34 < geertu> According to the datasheet, these bits can be written to regardless of debug mode, so there's no need to check M21 +10:35 < geertu> (in theory) +10:35 < dammsan> this kind of discussion would take some time i think +10:35 < dammsan> for the SMP bits +10:35 < dammsan> but i wish sergey the best of luck +10:35 < geertu> morimoto-san: Do you know why the BSP writes into the undocumented bits of CA7DBGRCR? +10:35 < dammsan> but regardless +10:36 < dammsan> we do need some mode pin handling, no? +10:36 < geertu> Sure. +10:36 < geertu> [PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for obtaining mode pin state +10:36 < dammsan> what's the latest state with that? +10:36 < geertu> http://www.spinics.net/lists/linux-renesas-soc/msg04289.html +10:36 < morimoto> geertu: I'm not sure. Do you want me to ask BSP team ? +10:36 < geertu> Got some acks from people (all renesas-soc related only) +10:37 < geertu> morimoto: Yes, BSP and hardware people. +10:37 < dammsan> does it cover the product register too? +10:37 < dammsan> or will that be a different driver? +10:38 < geertu> ESx.y is something different. Albeit related, as it involves modifying the passed device tree. +10:38 < horms> geertu: is the missing piece and Ack from Mark Rutland +10:38 < dammsan> geertu: sure, just wonderig if the ESx.y detection register is in the RST range +10:38 < dammsan> hopefully not +10:38 < geertu> horms: No, from the reset maintainer. Which probably doesn't feel much involved, as the driver doesn't implement reset functionality +10:39 < geertu> dammsan: No, PRR is a completely different register. +10:39 < dammsan> geertu: ok good +10:39 < horms> ok. should we try to get that ack +10:39 < horms> or do we need more discussion +10:39 < horms> this issue seems to have been going around for a while +10:39 < horms> I for one had a go at it +10:39 < horms> I think this is your second attempt +10:40 < geertu> To make backward compatibility easier, I want to modify the device tree and add RST, SYSC, and APMU nodes if they're missing. +10:40 < geertu> Which brings us to +10:40 < geertu> [PATCH/RFC 0/1] soc: renesas: Add DT fixup code for backwards compatibility +10:40 < geertu> https://lkml.org/lkml/2016/6/1/742 +10:40 < geertu> That one implements adding the RST node only, but it can be extended for ESx.y handling. +10:40 < dammsan> geertu: can't you merge those in -staging to begin with? +10:40 < geertu> Then the PRR is hidden there. +10:41 < dammsan> geertu: thanks, i understand +10:42 < geertu> dammsan: staging? Lately Greg refused adding a new driver to staging, as he was wondering about a plan to get it out of staging +10:42 < dammsan> geertu: then plan would be to get it out once the reset maintainer agrees +10:42 < dammsan> or something =) +10:42 < geertu> Yes. Unless someone disagrees. +10:42 < dammsan> so do we need to add more reset functionality ? +10:43 < geertu> I don't think so. +10:44 < dammsan> ok fine with me =) +10:44 < geertu> It's called "reset controller", but it seems to differ from what Linux expects. +10:44 < morimoto> geertu: can I confirm ? what is your question about CA7DBGRCR ? +10:44 < horms> I'd vote for trying to get it merged not in staging unless we see a difficulty in achieving that +10:45 < geertu> renesas-backports/bsp/v3.10.31-ltsi/rcar-gen2-1.9.7:arch/arm/mach-shmobile/:smp-r8a7790.c: writel_relaxed((val | 0x01f83330), p + CA7DBGRCR); +10:45 < geertu> renesas-backports/bsp/v3.10.31-ltsi/rcar-gen2-1.9.7:arch/arm/mach-shmobile/:smp-r8a7794.c: writel_relaxed((val | 0x01f83330), p + CA7DBGRCR); +10:45 < geertu> morimoto: The 0x3330 part writes to undocumented bits +10:47 < morimoto> geertu: OK thanks. will ask +10:47 < geertu> morimoto: Thank you +10:48 < geertu> OK, I will refresh the RST series and resend (for v4.9) +10:48 < geertu> For the DT fixup, there were some review comments. +10:48 < dammsan> geertu: does it make sense to change the "old" CPG driver to use the new RST driver? +10:48 < geertu> And it will need changes to modify the DT before SMP bringup. +10:49 < dammsan> or is it better to jump to CPG-MSSR directly? +10:49 < geertu> dammsan: If we want to support old DT, the old CPG driver has to stay alive. +10:49 < dammsan> yes +10:50 < dammsan> but adding more dependencies to the old code may be just pure pain +10:50 < geertu> dammsan: Either it has to absorb the code to read MODEMR itself, or call into the RST driver. +10:50 < dammsan> (regarding adding some plink to the reset controller) +10:50 < geertu> There won't be a plink. +10:50 < geertu> plink = phandle? +10:50 < dammsan> gotcha +10:50 < dammsan> yeah +10:51 < dammsan> i meant phandle +10:51 < geertu> It calls rcar_rst_read_mode_pins() +10:51 < geertu> which either uses the RST node in DT, or falls back to hardcoded MODEM for backward compatbility code. +10:51 < geertu> The latter can be dropped again once we do DT fixup. +10:52 < geertu> s/MODEM/MODEMR/ +10:52 < dammsan> makes sense. reducing cross-tree symbol dependencies is always nice if possible +10:53 < dammsan> in my old mode pin hack i tried to store the mode pin setting in DT +10:53 < dammsan> by modifying it duringggggggg runtime +10:53 < dammsan> but it is a bit unholy +10:53 < dammsan> at the same time bordering to your run time patching +10:53 < geertu> Ah, you just added a property with the value? +10:53 < dammsan> yep +10:54 < dammsan> no special symbols needed +10:54 < geertu> Did you add it to the FDT or the unflatted one? +10:54 < geertu> s/unflatted/unflattened/ +10:56 < dammsan> don't recall, but i used of_property_read_u32(node, "cpg-mode", &cpg_mode) in my prototype +10:57 < dammsan> see "[PATCH/RFC] clk: shmobile: DT property SoC <-> CCF interface prototype" +10:58 < dammsan> the idea was to use of_update_property() +10:58 < dammsan> not sure if that applies anymore +10:58 < dammsan> much has changed in 3 years i guess +10:59 < geertu> I think it will work +10:59 < geertu> morimoto: As you coined the MODEMR and ESx.y handling topics, do you have more questions? +11:00 < dammsan> i like removing symbol dependencies myself +11:01 < morimoto> geertu: thanks. it was not urgent. but something process happen, that is enough for me +11:02 < geertu> morimoto-san: Thanks +11:02 < geertu> Topic 3. Status check for tasks from last meeting - what is remaining? +11:03 < geertu> About "Gen3 firmware plan for special memory allocation control" +11:03 < geertu> has this been documented on the eLinux wiki? +11:04 < morimoto> Who has its ball ? +11:04 < shimoda> it's me +11:05 < shimoda> but sorry i don't write it yet +11:05 < shimoda> I will try to do it by next week... +11:06 < geertu> ok, thx +11:06 < neg> I sent out v8 of DMAC+IPMMU 3 weeks ago after Russell King had a good review comment about v7. Pinged Russell ~2 weeks ago but still no response from him. I he still have not responded early next week I will ping him again. Anyone got tips on how to get his attention? I need his Ack on the ARM part of the series to take the series to the dmaengine tree. +11:07 < neg> Vinod spoke in favor of the dmanegine bits so I'm hoping with Russells Ack this can finaly be taken upstream +11:10 < geertu> neg: Did you get any feedback on the other rcar-dmac series? +11:12 < neg> yes Russell had feedback on v7 +11:14 < geertu> neg: I mean the other series, which I collected in topic/rcar-dmac-niklas +11:14 < neg> or are you talking abut the dmac cleanups? If so Laurent Acked all with a cosmetic missing blank line +11:14 < geertu> OK +11:15 < neg> is on my list to send a v2 collecting his Acks and adding the missing blank line for tomorrow, been focusing to get other work done +11:21 < horms> neg: In general the procedure with Russell is to get his approval then, if the patch is for him to accept, put it in his patch tracker +11:22 < horms> But in general I would suggest politely reposting the series and asking him to help move it forwards +11:22 < geertu> horms: In this case it's for approval, as the patch should go in through vinod +11:22 < horms> ok +11:23 < horms> I think Russell is genearlly quite busy, but reasonable when handled with care +11:23 < neg> horms: so it's better to repost the series then to send a ping to the old thread? +11:23 < horms> I guess its up to you. +11:23 < horms> But I feel a repost might be more likely to get his attention +11:24 < horms> I merged some kexec-tools patches of his recently +11:24 < horms> so hopefully we are in his good books at this time +11:24 < neg> ok thanks then I will repost the series early next week if no response by then +11:28 < geertu> Anything else to report, ask or discuss? +11:28 < horms> Not from here +11:29 < khiemnguyen> About CPUFreq patchset, I will try to send v2 in early July. Sorry for delay... +11:29 < horms> Ok, will that be targeted at v4.9? (its too late for v4.8) +11:30 < khiemnguyen> Yeah, v4.9 is good for me, if no objections. +11:31 < geertu> OK +11:32 < geertu> Thanks for joining, and C (most of) U in Tokyo diff --git a/wiki/Chat_log/20160706-mm-chatlog b/wiki/Chat_log/20160706-mm-chatlog new file mode 100644 index 0000000..5d1544a --- /dev/null +++ b/wiki/Chat_log/20160706-mm-chatlog @@ -0,0 +1,581 @@ +Chat Report 2016-07-06 + +We had a multimedia group meeting on 2016-07-06. Here's a summary of the +discussions. Please correct any mistake you would notice. + +Attendees: + +- Kieran +- Laurent +- Morimoto-san +- Niklas +- Ulrich + +Magnus was excused. + + +Topic 1. Status check for the multimedia tasks +---------------------------------------------- + +- FDP,v4.8,prototype,kieran,Develop and upstream driver + +Patches have been posted for public review, DT bindings have been acked. +Development itself is complete, the task will be split in two with only the +upstreaming part remaining. The upstreaming target is v4.9. + +- AUDIO-DMAC,?,plan,magnus,IPMMU integration on Gen2 +- AUDIO-DMAC,?,plan,magnus,IPMMU integration on Gen3 +- AUDIO-DMAC,?,plan,magnus,IPMMU support on Gen2 +- AUDIO-DMAC,?,plan,magnus,IPMMU support on Gen3 +- VIN,?,prototype,magnus,IPMMU integration on Gen2 +- VIN,?,prototype,magnus,IPMMU integration on Gen3 +- VIN,?,prototype,magnus,IPMMU support on Gen2 +- VIN,?,prototype,magnus,IPMMU support on Gen3 + +No progress. + +- RSND,v4.10,public,morimoto,DT bindings for graph sound +- RSND,v4.10,public,morimoto,dw-hdmi-i2s-audio prototype on Gen3 +- RSND,v4.10,prototype,morimoto,HDMI SSI prototype on Gen3 +- RSND,v4.10,plan,morimoto,HDMI sound Upstream support without hotplug on Gen2 +- RSND,2016-09-30,plan,morimoto,Hotplug support upstream on Gen3 + +The ALSA + HDMI patches are organized as follows. + +1. Cleanup +2. OF graph +3. OF graph-based new sound card +4. HDMI sound driver + +Patches for 1. and 2. have been posted. Cleanup is progressing slowly. OF +graph DT bindings (2) have passed maintainer's review, but the implementation +(3) is required before the patches can be merged. + +DT bindings will also be discussed during PeriPeriCon. + +- ADV7482,v4.7,public,niklas,Prototype on Gen3 +- VIN,v4.7,public,niklas,CSI2 prototype (Gen3) + +The tasks are complete. + +- ADV7482,v4.9,plan,niklas,Gen3 support upstream +- ADV7482,v4.9,plan,niklas,Interlace support upstream +- VIN,v4.9,plan,niklas,CSI2 interlace support upstream (Gen3) +- VIN,v4.9,plan,niklas,CSI2 support upstream (Gen3) +- VIN,v4.9,plan,niklas,Gen3 support upstream (without CSI-2) + +No progress. + +- VIN,v4.8,public,niklas,Gen3 support + +No progress. Upstreaming requires deciding how to handle the ADV7482, moving +the task to v4.9 as a result. + +- VIN,v4.8,plan,niklas,Scaler support (on Gen3) + +No progress. A prototype will hopefully be implemented before PeriPeriCon. +Moving to v4.9 for upstreaming. + +- DU,v4.7,plan,ulrich,Atomic API test program +- DU,v4.7,prototype,ulrich,Test setup with HDMI output to HDMI input loopback +(without EDID) + +The test application and setup are public, marking as complete. + +- DU,v4.7,public,ulrich,HDMI output on Gen3 prototype + +The prototype is public, marking as complete. + +- DU,v4.7,public,ulrich,EDID generation support for the HDMI loopback test +setup + +Patches will be posted today. + +- DU,v4.9,plan,ulrich,HDMI output on Gen3 upstream + +No progress. + +- VIN,v4.8,public,ulrich,Add DV timings support to rcar-vin + +The patches have been merged to the linux-media tree, they should end up in +v4.8. Marking as complete. + +- DU,?,plan,laurent,IPMMU integration on Gen3 +- DU,?,plan,laurent,IPMMU support on Gen3 (through VSPD+FCP) +- DU,v4.9,plan,laurent,Fix 3 planes formats +- VSP,?,plan,laurent,Fixed alpha support (VI6_DPR_*_ROUTE.FXA) + +No progress. + +- VSP,?,plan,laurent,UDS regression fix + +UDS on Gen3 can scale images wider than 128 or 256 pixels. It requires slicing +(partitioning) input images in software and running the VSP pipeline for each +slice. Renaming the task to "Image partitioning support". This will require a +significant amount of work. There's no completion estimate as the task hasn't +been scheduled yet. + +- VSP,v4.8,plan,laurent,Fix suspend/resume crash + +No progress. The task isn't scheduled, removing the target version. + +- VSP,v4.8,public,laurent,HGO operation mode selection +- VSP,v4.8,public,laurent,HGO support upstream on Gen3 +- VSP,v4.8,public,laurent,HGO test application + +No progress. A pull request will hopefully be sent this week, but this will be +too late for v4.8. Moving to v4.9 as a result. + +- VSP,v4.8,prototype,laurent,Rotation support + +Rotation itself is implemented, but requires image partitioning support for +images wider than 256 pixels. Removing the target version due to the +dependency. + +- VSP,v4.8,public,laurent,V4L2 request API usable prototype + +Patches should go out today. + +- VSP,?,prototype,laurent,V4L2 request API upstream + +No progress. + + +Topic 2. Additional '50%' tasks (June) +-------------------------------------- + +The additional tasks are + +- VIN CSI-2 Support Prototype +- ADV7482 Driver Prototype +- VSP CLU Improvements +- VSP Rotation Support +- HDMI Input/Output Loopback for R-Car Gen2 +- FDP Support on Gen3 + +All tasks are complete, with a caveat for rotation support that requires image +partitioning for images wider than 256 pixels. Rotation will automatically +work for wider images once image partitioning is implemented. + + +Topic 3. Additional '50%' tasks (Q3) +------------------------------------ + +Due to unforeseen and sad circumstances that required Magnus to travel to +Sweden negotiation of the tasks got delayed. + +The two tasks currently planned for Ulrich are + +- VIN HDMI input EDID +- VIN integration on Gen2 + +For Niklas we have initially discussed the UDS regression fix, but as it turns +out it will require more work than expected it wasn't a good match. The +current plan is to implement support for one of the currently unimplemented +VSP modules. The SHP (sharpener) was mentioned but the hardware isn't fully +documented and the available source code just programs registers with +parameters passed by upper software layers that are not available to us. +We will thus likely switch to a different module. + + +Topic 4. PeriPeriCon & RenesasCon preparation +--------------------------------------------- + +Topics proposed for PeriPeriCon are + +- OF graph for ALSA (Morimoto-san) +- V4L2 support for subdevices with more than one output pipeline (Niklas) +- Second batch of additional tasks for Q3 (Laurent) +- What are we doing right or wrong, and how can we improve (Laurent) +- Long-term roadmap (Laurent) + +The topic owners should prepare a very short presentation when appropriate to +quickstart the discussion and get everybody on the same page. + +The https://osdr.renesas.com/projects/linux-kernel-development/wiki#PeriPeriCon wiki page contains more information about the +PeriPeriCon schedule. + + +Topic 5. Next meeting +--------------------- + +The next meeting will be held at PeriPeriCon on Monday the 11th of July. The +next IRC meeting will be held on 2016-07-27 at 09:00 BST / 10:00 CEST / 11:00 +EEST / 17:00 JST. + + +h1. Multimedia-chat-meeting-2016-07-06 + + +<neg> hi all [16:54] +<morimoto> hi [16:55] +<pinchartl> hello [16:56] +<uli___> hi +<pinchartl> I assume Magnus will not joing us +<kbingham> Morning all! +<pinchartl> let's get started [16:58] +<pinchartl> agenda for today +<pinchartl> Topic 1. Status check for the multimedia tasks +<pinchartl> Topic 2. Additional '50%' tasks (June) +<pinchartl> Topic 3. Additional '50%' tasks (Q3) [16:59] +<pinchartl> Topic 4. PeriPeriCon & RenesasCon preparation +<pinchartl> Topic 5. Next meeting +<pinchartl> anything else ? +<morimoto> nothing from me ;P [17:00] +<pinchartl> ok +<pinchartl> let me take the tasks list +<pinchartl> in alphabetical order [17:02] +<pinchartl> FDP,v4.8,prototype,kieran,Develop and upstream driver +<pinchartl> I believe the driver was posted for public review +<kbingham> Patches all out for review. +<kbingham> Yes, the dt-bindings look like they've been acked, and simon has + acknowledged and will pick those I believe. [17:03] +<pinchartl> I've reviewed a previous version of the patches and they look + pretty good to me +<kbingham> For the FDP1 driver, I would say we're just waiting for some review + to happen on the linux-media lists. +<pinchartl> I'll review the public version too +<pinchartl> the corresponding task didn't include upstreaming, so it's + complete [17:04] +<pinchartl> I propose splitting this item in two +<pinchartl> development and upstreaming +<pinchartl> and marking development as complete [17:05] +<kbingham> Ok. Sounds good to me. +<pinchartl> v4.8 will be a bit tight for upstreaming [17:06] +<pinchartl> I'll schedule it for v4.9 +<kbingham> yes, that sounds more feasible. +<pinchartl> next, Magnus [17:08] +<pinchartl> who's not available +<pinchartl> AUDIO-DMAC,?,plan,magnus,IPMMU integration on Gen2 +<pinchartl> AUDIO-DMAC,?,plan,magnus,IPMMU integration on Gen3 +<pinchartl> AUDIO-DMAC,?,plan,magnus,IPMMU support on Gen2 +<pinchartl> AUDIO-DMAC,?,plan,magnus,IPMMU support on Gen3 +<pinchartl> VIN,?,prototype,magnus,IPMMU integration on Gen2 +<pinchartl> VIN,?,prototype,magnus,IPMMU integration on Gen3 +<pinchartl> VIN,?,prototype,magnus,IPMMU support on Gen2 +<pinchartl> VIN,?,prototype,magnus,IPMMU support on Gen3 +<pinchartl> is anyone aware of any progress there ? +<pinchartl> I'll take that as a no :-) [17:09] +<neg> I know he started to look at VIN+IPMMU not sure how far he got [17:10] +<pinchartl> we don't have a "started looking at but not sure" status, I'll + leave it as-is :-) +<pinchartl> next, Morimoto-san [17:11] +<pinchartl> RSND,v4.10,public,morimoto,DT bindings for graph sound +<pinchartl> RSND,v4.10,public,morimoto,dw-hdmi-i2s-audio prototype on Gen3 +<pinchartl> RSND,v4.10,prototype,morimoto,HDMI SSI prototype on Gen3 +<pinchartl> RSND,v4.10,plan,morimoto,HDMI sound Upstream support without + hotplug on Gen2 +<pinchartl> RSND,2016-09-30,plan,morimoto,Hotplug support upstream on Gen3 +<morimoto> My ALSA + HDMI patch-set are +<morimoto> 1) cleanup patches [17:12] +<morimoto> 2) OF graph patches +<morimoto> 3) OF graph base new sound card patches +<morimoto> 4) HDMI sound driver patches +<morimoto> I posted 1) and 2) +<morimoto> 1) is slow progress +<morimoto> Maintainer said 2) is OK for him, but he want to see 3) [17:13] +<morimoto> So, 2) and 3) will be merged and posted in next time +<pinchartl> nice +<morimoto> But, I don't know how to handle it on each Maintainer [17:14] +<morimoto> I'm asking it now +<pinchartl> ok +<morimoto> I asked about 2) to you pinchartl :) +<morimoto> about port vs endpoint on video/sound +<morimoto> not a big deal, but DT change after formal is difficult ? [17:15] +<pinchartl> I know +<pinchartl> I haven't had time to review the patches yet +<pinchartl> I'll try to do it this week but I can't promise +<morimoto> OK +<morimoto> that's it from me [17:16] +<morimoto> Maybe we can talk about it on MiniPeriCon ? +<pinchartl> that's a good idea [17:17] +<morimoto> Thanks +<pinchartl> next, Niklas +<pinchartl> ADV7482,v4.7,public,niklas,Prototype on Gen3 [17:18] +<pinchartl> ADV7482,v4.9,plan,niklas,Gen3 support upstream +<pinchartl> ADV7482,v4.9,plan,niklas,Interlace support upstream +<pinchartl> VIN,v4.7,public,niklas,CSI2 prototype (Gen3) +<pinchartl> VIN,v4.8,public,niklas,Gen3 support +<pinchartl> VIN,v4.8,plan,niklas,Scaler support (on Gen3 +<pinchartl> VIN,v4.9,plan,niklas,CSI2 interlace support upstream (Gen3) +<pinchartl> VIN,v4.9,plan,niklas,CSI2 support upstream (Gen3) +<pinchartl> VIN,v4.9,plan,niklas,Gen3 support upstream (without CSI-2) +<neg> easy this time, no progress so far. Hope to have a new VIN patchset with + UDS support done before I leave for Tokyo [17:19] +<pinchartl> ok [17:21] +<pinchartl> for VIN,v4.8,public,niklas,Gen3 support +<pinchartl> should that be moved to v4.9 ? +<neg> yes since I think we need to figure out what/if to extend v4l2 to + support the ADV7482 first [17:22] +<pinchartl> and regarding No progress, will hopefully be implemented before + PeriPeriCon. [17:23] +<pinchartl> oops +<pinchartl> ADV7482,v4.7,public,niklas,Prototype on Gen3 +<pinchartl> VIN,v4.7,public,niklas,CSI2 prototype (Gen3) +<neg> or do you think there is value to try and get driver up as soon as + possible that only works with a 1 output version of the adv7482? +<pinchartl> as those are prototype tasks +<pinchartl> they''re complete, right ? +<neg> yes [17:24] +<pinchartl> thanks [17:25] +<pinchartl> for Gen3 support I don't think we need to rush the merge +<pinchartl> it's likely too late for v4.8 already anyway [17:26] +<pinchartl> I'll move the scaler to v4.9 too [17:27] +<pinchartl> next, Ulrich +<neg> thanks +<pinchartl> DU,v4.7,plan,ulrich,Atomic API test program +<pinchartl> DU,v4.7,public,ulrich,HDMI output on Gen3 prototype +<pinchartl> DU,v4.7,prototype,ulrich,Test setup with HDMI output to HDMI input + loopback (without EDID) +<pinchartl> DU,v4.7,public,ulrich,EDID generation support for the HDMI + loopback test setup +<pinchartl> DU,v4.9,plan,ulrich,HDMI output on Gen3 upstream +<uli___> the test setup is up on elinux/github [17:28] +<uli___> edid generation will go out today +<uli___> that's it +<pinchartl> do you mean the HDMI loopback test setup ? [17:30] +<uli___> yes +<pinchartl> how about DU,v4.7,plan,ulrich,Atomic API test program ? +<uli___> i moved the wiki pages +<uli___> that's what was missing, iirc +<pinchartl> thanks [17:31] +<pinchartl> and DU,v4.7,public,ulrich,HDMI output on Gen3 prototype [17:32] +<pinchartl> is that considered as complete ? +<uli___> let's consider it as such. [17:33] +<pinchartl> there was also [17:34] +<pinchartl> VIN,v4.8,public,ulrich,Add DV timings support to rcar-vin +<uli___> that has been picked up recently +<pinchartl> nice [17:35] +<pinchartl> by Hans ? +<uli___> i just saw the auto-generated e-mail for the media tree +<pinchartl> then they have been applied by Mauro, perfect +<pinchartl> next, me, messing up the alphabetical order again [17:37] +<pinchartl> DU,?,plan,laurent,IPMMU integration on Gen3 +<pinchartl> DU,?,plan,laurent,IPMMU support on Gen3 (through VSPD+FCP) +<pinchartl> DU,v4.9,plan,laurent,Fix 3 planes formats +<pinchartl> no progress +<pinchartl> VSP,?,plan,laurent,Fixed alpha support (VI6_DPR_*_ROUTE.FXA) +<pinchartl> no progress +<pinchartl> VSP,?,plan,laurent,UDS regression fix [17:38] +<pinchartl> it turns out that this requires implementing image partitioning + support in the VSP driver +<pinchartl> as, unlike the VSP1 in Gen2, the VSP2 in Gen3 can't scale images + wider than 128 or 256 pixels (I have to check for the exact + number) +<pinchartl> so the images must be sliced by software, and the VSP run for each + slice [17:39] +<pinchartl> I'll thus rename the task to "Image partitioning support" [17:40] +<pinchartl> UDS will work out of the box then +<morimoto> pinchartl: about UDS regression, it was VSP driver side issue do + you mean ? [17:41] +<pinchartl> it wasn't a regression [17:42] +<pinchartl> or rather +<pinchartl> it's a hardware regression +<morimoto> Ahh, OK +<pinchartl> that requires significant additional work in the VSP driver +<pinchartl> VSP,v4.8,plan,laurent,Fix suspend/resume crash [17:43] +<pinchartl> this isn't scheduled, I'll remove the target version +<pinchartl> VSP,v4.8,public,laurent,HGO operation mode selection [17:44] +<pinchartl> VSP,v4.8,public,laurent,HGO support upstream on Gen3 +<pinchartl> VSP,v4.8,public,laurent,HGO test application +<pinchartl> no progress +<pinchartl> I hope to send a pull request this week +<pinchartl> but it might be too late for v4.8 +<pinchartl> I'll move it to v4.9 [17:45] +<pinchartl> VSP,v4.8,prototype,laurent,Rotation support +<pinchartl> rotation itself is implemented +<pinchartl> but it also requires image partitioning support for images wider + than 256 pixels [17:46] +<pinchartl> this is a dependency that I wasn't aware of +<pinchartl> I'll thus remove the target version due to the dependency on image + partitioning that hasn't been scheduled yet [17:47] +<pinchartl> VSP,v4.8,public,laurent,V4L2 request API usable prototype [17:48] +<pinchartl> I was hoping to send the latest version Monday last week but got + delayed, partly by the preparation of additional tasks for the + multimedia team for Q3 [17:49] +<pinchartl> and then by being unavailable from Friday to Tuesday +<pinchartl> I'll resume now, the patches should go out today +<morimoto> BSP team want to use latest verion on renesas-driver. [17:50] +<pinchartl> as soon as the patches are out I'll of course send a pull request + to Geert [17:51] +<morimoto> sound gr8 +<pinchartl> that's it for the tasks [17:53] +<pinchartl> Topic 2. Additional '50%' tasks (June) +<morimoto> pinchartl: what is current status of CLU/LUT ? +<pinchartl> merged +<morimoto> nice ! +<pinchartl> - VIN CSI-2 Support Prototype [17:54] +<pinchartl> - ADV7482 Driver Prototype +<pinchartl> - VSP CLU Improvements +<pinchartl> - VSP Rotation Support +<pinchartl> - HDMI Input/Output Loopback for R-Car Gen2 +<pinchartl> - FDP Support on Gen3 +<pinchartl> I believe everything is complete +<pinchartl> except for VSP rotation support +<pinchartl> that is complete for images not wider than 256 pixels +<pinchartl> Topic 3. Additional '50%' tasks (Q3) [17:55] +<morimoto> uli___: what is latest status of HDMI out for ES1.1 issue ? +<pinchartl> (go ahead, we'll move to topic 3 after) [17:56] +<morimoto> pinchartl: sorry +<uli___> still todo... +<morimoto> OK. +<pinchartl> creation of the 50% tasks for Q3 has been delayed [17:57] +<pinchartl> I've submitted the tasks for Ulrich, all others are still under + discussion with Magnus +<pinchartl> due to unforeseen and sad circumstances it didn't go as expected +<pinchartl> uli___: have you received an SoW from Jinzai ? +<uli___> not yet [17:58] +<uli___> for the 50% tasks, that is +<pinchartl> ok +<pinchartl> the two tasks currently planned for Ulrich are [17:59] +<pinchartl> VIN HDMI input EDID +<pinchartl> VIN integration on Gen2 +<pinchartl> for Niklas we have initially discussed the UDS regression fix + [18:00] +<pinchartl> but as it turns out it will require more work than expected it + wasn't a good match +<pinchartl> the current plan is to implement support for one of the currently + unimplemented VSP modules +<pinchartl> the SHP (sharpener) was mentioned [18:01] +<pinchartl> but the hardware isn't fully documented +<pinchartl> and the available source code just programs registers with + parameters passed by upper software layers that are not available + to us +<pinchartl> so we'll likely switch to a different module +<pinchartl> for Kieran and me the situation isn't clear either, I expected + feedback from Magnus today [18:02] +<pinchartl> we'll try to fix this asap [18:03] +<kbingham> Understandable if magnus is away. +<pinchartl> Topic 4. PeriPeriCon & RenesasCon preparation [18:04] +<pinchartl> unless there are questions about the additional tasks for Q3 ? +<neg> I'm good for now :-) [18:05] +<pinchartl> for, for peripericon [18:06] +<pinchartl> s/for/so/ +<pinchartl> we'll discuss multimedia topics on Monday afternoon +<pinchartl> there's no fixed agenda yet +<pinchartl> now is the time to propose topics :-) +<morimoto> I would like to talk about OF graph [18:07] +<neg> extensions to v4l2 to support subdevices with more then one output + pipeline +<pinchartl> anything else ? uli___ and kbingham I know you won't be there, but + are there topics you would like us to discuss ? [18:09] +<uli___> can't think of anything [18:10] +<pinchartl> I'd like to discuss the following topics +<pinchartl> - Second batch of additional tasks for Q3 +<pinchartl> - What are we doing right or wrong, and how can we improve +<pinchartl> - Long-term roadmap +<neg> hum I don't know if this is on the roadmap but if there is plans to + support audio in or CEC from VIN HDMI how that would work. But maybe + that is covered in morimoto topic about OF graph? [18:11] +<kbingham> the current m2m design is limited and seems to prevent pipelined + usage of hw ... but I think that's possibly a topic for linux-media + . But that's the only thing I can think of on my future discussion + lists. +<pinchartl> neg: I might be mistaken but I don't think we have hardware + support for CEC [18:12] +<pinchartl> the target market for Renesas devices isn't exactly consumer + electronics :-) [18:13] +<pinchartl> kbingham: yes, I think that's a topic for linux-media +<pinchartl> I'll write it down as a potential task for the future +<neg> pinchartl: hum ofc CEC is terminated in the adv7482 so it might not be + high on the agenda [18:14] +<pinchartl> ah, ADV7482 has CEC support ? +<pinchartl> good to know +<pinchartl> I'm sure Hans would be interested +<pinchartl> but I don't think Renesas would. we should of course ask +<pinchartl> same for audio input. Morimoto-san, do you know if there's an + interest in HDMI audio input ? [18:15] +<morimoto> Yeah, of course +<morimoto> Oops, +<morimoto> Do you mean BSP request ? +<morimoto> BSP team doesn't have such request at this point. [18:16] +<pinchartl> either an existing BSP request, or something that would be of + interest to them in the future +<pinchartl> same for HDMI CEC support, is there an interest ? +<morimoto> but it seems they are starting about HDMI support for customer +<morimoto> I can say BSP team is stating about "HDMI" only, they don't know + detail of it :) [18:17] +<pinchartl> ok +<morimoto> So yes, in the future, they will request such detail feature +<pinchartl> we can discuss that during RenesasCon [18:18] +<pinchartl> I'll send out the list of topics for PeriPeriCon in the meeting + report, if anyone wants to add topics to the agenda it will still + be possible until the end of the week +<pinchartl> Morimoto-san and Niklas, could you each prepare a very brief + presentation for the topic you proposed for the meeting ? + [18:19] +<pinchartl> it should be 5 minutes long at most +<pinchartl> just to get everybody on the same page to start discussions +<morimoto> on email ? or here ? +<pinchartl> no, for PeriPeriCon [18:20] +<neg> will do +<morimoto> OK, will do +<pinchartl> thank you +<pinchartl> regarding RenesasCon +<pinchartl> I propose finalizing the preparation for it during PeriPeriCon +<pinchartl> Renesas is driving the agenda there [18:21] +<pinchartl> but it will be a good occasion to ask questions +<pinchartl> for instance regarding HDMI audio input and CEC +<pinchartl> I will also prepare a presentation of the multimedia group + activities [18:22] +<pinchartl> neg: I've seen the slides you've sent, thank you +<pinchartl> morimoto: do you think we need a detailed presentation from each + developer, or a single summary presentation of our activities ? + [18:23] +<neg> I hope they are on the right level for the event. Thanks morimoto for + your comments! +<morimoto> pinchartl: it up to you :) I can say it is free style [18:24] +<morimoto> neg: no problem :P +<morimoto> basically, 1 person has 10min. style is free [18:25] +<morimoto> BTW, I created Wiki page for MiniPeriCon and RenesasCon [18:26] +<morimoto> + https://osdr.renesas.com/projects/linux-kernel-development/wiki#PeriPeriCon +<morimoto> We can use it +<morimoto> +<pinchartl> thank you +<pinchartl> I think that's it then [18:27] +<pinchartl> the next multimedia meeting will be during PeriPeriCon +<morimoto> sounds nice :) +<pinchartl> and the one after that will be on Wednesday two weeks later, I'll + send an invite +* kbingham wishes he was going to Japan :) [18:28] +<pinchartl> kbingham: it's not too late to book a plane ticket ;-) +<neg> I have a practical question for peripericon and renesascon, do anyone + plan to bring a HDMI->VGA adapter incase we find an old beamer :-) +<morimoto> kbingham: can we meet on Oct ELCE ? +<kbingham> morimoto: Of course :) I'll be at ELCE +<kbingham> pinchartl: It's not the ticket preventing me from going to japan + next week :) [18:29] +<morimoto> Oops, we need projector on MiniPeriCon ? I need to prepare +<pinchartl> morimoto: yes, that would be useful +<pinchartl> neg: I don't have one [18:30] +<neg> me neither, so I will buy one then so we have if needed [18:31] +<pinchartl> I propose adjourning the meeting. does anyone second ? [18:32] +<neg> seconded [18:33] +<pinchartl> thank you +<pinchartl> the meeting is adjourned, talk to you in Tōkyō for the ones who + will be there [18:34] +<neg> thanks all +<morimoto> thanks +<kbingham> Cheers and Enjoy! [18:35] +<morimoto> pinchartl: when you arrive to Jinbotyo station A4 exit, you can + email me by "kuninori.morimoto.gx@renesas.com" or + "dr.mk.gemini@gmail.com" [18:36] +<pinchartl> morimoto: I don't think I'll have an internet connection +<morimoto> Maybe it can be good lunch time :) +<morimoto> Oops, from Hotel ? +<pinchartl> I can probably send you an e-mail when I leave the hotel [18:37] +<pinchartl> and call you when I get to the station +<pinchartl> I can also send a text message to Niklas +<pinchartl> or Geert or Wolfram +<morimoto> OK, sound nice !! +<morimoto> Have a nice trip you guys !! [18:38] +<pinchartl> thank you +<morimoto> note that, unfortunately, Japan in rainy season now. +<neg> another Q, can I fit my US power plug into a JP socket physicly? (yes I + know the voltages are different) the internet gives me different awnsers + [18:39] +<morimoto> I always using Japan plug on US without exchanger [18:40] +<morimoto> I'm always using Japanese plug in US without exchanger +<neg> nice thx +<morimoto> OK, thanks you guys, I will quit [18:42] diff --git a/wiki/Chat_log/20160711-io-MiniPeriPeriCon-log b/wiki/Chat_log/20160711-io-MiniPeriPeriCon-log new file mode 100644 index 0000000..d167fe3 --- /dev/null +++ b/wiki/Chat_log/20160711-io-MiniPeriPeriCon-log @@ -0,0 +1,27 @@ +Chat meetings: + - we agreed to introduce a new style to save time and energy + - members send todo updates by mail before meeting starts + - short focussed meetings. Everyone answers: + a) what have I worked on since last time + b) what will I work on until next time + c) I have the following problems (or not) + - problems can be discussed ad-hoc if the energy is there, + otherwise interested parties do this separately + - once every two weeks + - should be doable in 15 minutes if no special problems are + to be discussed + +Additional tasks for 8/m: + - only tasks for Simon & Wolfram in the queue + - both agreed to wait until Magnus is back + +Base tasks: + - Wolfram: ask for developer's reports to ensure alignment + - Niklas is okay doing small base tasks occasionally instead of en-block + +Additional tasks: + - priorities of tasks need to be clear for developers to decide + - especially across groups + - same is true for group leaders, actually + - discuss this internally beforehand by mail? + diff --git a/wiki/Chat_log/20160726-io-chatlog b/wiki/Chat_log/20160726-io-chatlog new file mode 100644 index 0000000..4f0eca3 --- /dev/null +++ b/wiki/Chat_log/20160726-io-chatlog @@ -0,0 +1,151 @@ +--- Log opened Tue Jul 26 10:02:26 2016 +10:02 -!- wsa_ [~wsa@p5099505f.dip0.t-ipconnect.de] has joined #periperi-io +10:02 -!- Irssi: #periperi-io: Total of 3 nicks [1 ops, 0 halfops, 0 voices, 2 normal] +10:02 -!- Irssi: Join to #periperi-io was synced in 0 secs +10:02 < wsa_> hiya +10:02 <@horms> hi +10:02 < uli___> hello +10:04 -!- neg [~neg@unaffiliated/neg] has joined #periperi-io +10:04 -!- morimoto [~user@relprex3.renesas.com] has joined #periperi-io +10:04 < morimoto> Hi +10:06 -!- shimoda [~shimoda@210.160.252.169] has joined #periperi-io +10:06 < wsa_> hello +10:06 -!- Irssi: #periperi-io: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal] +10:06 < shimoda> i'm sorry for delay +10:07 < wsa_> all fine +10:07 < wsa_> i was also a bit late because my internet at home was broken +10:08 -!- Irssi: #periperi-io: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal] +10:08 < morimoto> It seems your donations was not enough ? +10:08 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi-io +10:08 < khiemnguyen> Hello everyone. +10:08 <@horms> hi +10:08 < wsa_> i thought the kami for internet was at the kanda temple near akihabara? +10:09 <@horms> good to know +10:09 < wsa_> so, let's start +10:09 < wsa_> a few of you already send the todo updates by mail +10:09 < wsa_> thanks for that +10:09 < wsa_> who has not done so, please do +10:10 < wsa_> and now let's try the condensed meeting +10:10 < wsa_> a) what have i done since last time +10:10 < morimoto> wsa_: I didn't, but I don't have +10:10 < neg> if I have no updates, do you wan't an email stating that? :-) +10:10 < wsa_> b) what i plan to do till next time +10:10 < wsa_> c) problems i have currently +10:10 < wsa_> yes, i like those, too +10:11 < wsa_> just to align that we both think there are no tasks pending ;) +10:11 < neg> ok, my bad then. Will do so in future +10:11 < wsa_> or so i know neg didn't have time yet to work on the CMA issue +10:12 < wsa_> ok, first one today: simon +10:12 <@horms> sure +10:12 <@horms> i have been working on tracking down timeouts during srd104 tuning +10:13 <@horms> that was a) +10:13 <@horms> b) I will continue doing the same as the cause seems elusive: i found a new lead in the past hour so perhaps i have it now! +10:13 <@horms> c) none +10:13 < wsa_> b) YAY! +10:14 < wsa_> shimoda-san, your turn +10:15 < shimoda> yes +10:15 < shimoda> 1) update renesas_usbhs driver for m3w and some bugfix +10:16 < shimoda> 2) i will submit some patches for renesas_usbhs, phy, usb-dmac that are related to bugfix after v4.8-rc1 was released +10:16 < shimoda> oops 1) is a), 2) is b) +10:17 < wsa_> :) I translated that +10:17 < shimoda> :) +10:18 < shimoda> c) i still have a problem about usb2 + ipmmu and usb3 host suspend, but i have no update for now +10:18 < shimoda> s/a problem/problems/ +10:18 < wsa_> good to know nonetheless +10:18 < wsa_> thank you +10:19 < wsa_> morimoto: your full report now ;) +10:19 < morimoto> I think I have no task for I/O +10:20 < morimoto> I worked but for multimedia +10:20 < wsa_> yes, you are our paperwork hero currently +10:20 < morimoto> Hehe :) +10:20 < wsa_> :) +10:21 < wsa_> uli___: your turn +10:21 < uli___> for a) +10:21 < uli___> i checked out sdhi performance on lager, but it seems ok, and i have found no way to improve it +10:21 < uli___> for sd-over-msiof, i have found a bug in the msiof driver that keeps the cs-gpio from working +10:21 < uli___> but with that fixed, it still doesn't work :( +10:21 < uli___> b) +10:21 < wsa_> :( +10:22 < uli___> i'll check why it still doesn't work. +10:22 < uli___> geertu gave me hint about something that might be the culprit, i'll check that out +10:22 < uli___> c) see b) +10:22 <@horms> can i ask a question of uli__? later? +10:22 < uli___> sure +10:22 <@horms> I take it you were focusing on DMA performance, is that correct? +10:22 < uli___> yes +10:23 <@horms> Did you try the SDR104 patches? +10:23 < uli___> are they in renesas-drivers yet? +10:23 <@horms> I think so. +10:23 < uli___> then i have :) +10:23 <@horms> Lastly, what was the maximum transfer rate you observed (approximately)? +10:23 < uli___> 34,7 with sdr50 +10:24 < uli___> but that's a limitation of the card, i think +10:24 < uli___> if i halve the sdhi frequency, we're at 22,something mb/s +10:24 < uli___> which is as close to maximum as you can get +10:24 <@horms> ok, thank. I have observed slightly higher than that but not much. +10:24 < wsa_> thanks +10:24 < wsa_> i am next +10:24 <@horms> we can compare notes on cards offline if its helpful (i will be quiet now) +10:25 < wsa_> or maybe we schedule such discussion after the reporting part? +10:25 <@horms> that is fine too +10:25 < wsa_> i wanted to ask simon something after that, too :) +10:26 < wsa_> a) i worked on Gen3 SDHI last week. I couldn't get DMA to work before going to Japan, but it works now +10:26 < wsa_> there was a patch missing to set the max frequency, which i sent +10:27 < wsa_> b) i will keep on evaluating/testing all recent sdhi patches +10:27 < wsa_> and keep on working on additional tasks +10:28 < wsa_> and handle the things that are caused by current delays +10:28 < wsa_> c) my gen3 dma tests suggested 70mb/s while 50mb/s is the theoretical limit :D +10:28 < wsa_> i have to recheck my measurement it seems +10:29 <@horms> did you use dd ... iflag=direct? +10:29 < wsa_> don't have my test setup here +10:29 < wsa_> i definately dropped all caches before +10:29 <@horms> it probably doesn't explain 50 vs 70, but its also probably worth checking +10:30 < wsa_> khiem, you are next +10:30 < khiemnguyen> a) not much. I'm looking into in-house BSP to collect some points to update my patchset. +10:31 < khiemnguyen> b) Will send v2 next week. +10:31 < khiemnguyen> Also, if any tasks related to Suspend-to-RAM, I'm happy to support. +10:31 < khiemnguyen> c) none. +10:32 < khiemnguyen> a) and b) are about R-Car Gen3 Thermal driver. +10:33 < wsa_> shimoda: do you think khiemnguyen could assist you with suspend problems? +10:34 < khiemnguyen> wsa_: : shimoda: any emails about the issues have been sent ? +10:34 < shimoda> wsa_: does this mean about my usb3 host problem? +10:35 < shimoda> khiemnguyen: maybe no. but, i can explain it. +10:35 < shimoda> so, i will send an email later +10:35 < wsa_> cool +10:35 < wsa_> neg: last but not least +10:36 < neg> a) Started to look into ohci-pci CONFIG_DMA_CMA issue, no progress so far +10:36 < neg> b) Successfully trigger the issue described on v4.7 +10:36 < neg> c) Summer hit Stockholm :-) +10:37 < uli___> what precisely does "summer" mean in swedish terms? +10:37 < wsa_> neg working from the public bath ;) +10:37 < wsa_> thank you! +10:37 < neg> I was not able to trigger the issue on v4.3-rc3 (version used where issue was found) nor on v4.7 but need to spend more time on it +10:38 < neg> wsa_: yes, do you know if Koelsch is water proof? :) +10:38 < wsa_> I'd like to ask Simon if he could describe his new findings in a sentence +10:38 < wsa_> but I'd think this is already the optional part of the meeting +10:39 < wsa_> neg: the c64 is, why shouldn't koelsch? ;) +10:39 <@horms> wsa_: I found several bugs/omissions in my reworking of the SDR code. Collectvely they seem to resolve the timeout problem. But I've thought that before so lets see how it looks in a day or so. (3 sentances, sorry) +10:40 < wsa_> neg: https://www.youtube.com/watch?v=5pb9yzfnbT0 (c64 runs 1 hour under water) +10:40 < wsa_> horms: thanks +10:41 < wsa_> btw my talks for LinuxCon Europe and ELCE in Berlin were both accepted +10:41 < wsa_> so see you guys there +10:42 < neg> wsa_: nice, grats +10:42 <@horms> congrats +10:42 < morimoto> congratulation +10:42 < uli___> what are they about? +10:44 < wsa_> LinuxCon: https://linuxconcontainerconeurope2016.sched.org/event/7oA4/kernel-development-i-still-think-we-have-a-scaling-problem-wolfram-sang-consultant +10:44 < wsa_> ELCE: making transparent how i work/decide as a maintainer +10:45 < wsa_> and how it differs from random developer expectations ;) +10:45 < wsa_> and ideas how to align all that +10:46 < wsa_> so, i gotta run now +10:46 < wsa_> thanks guys! +10:46 < neg> thanks all +10:46 <@horms> bye +10:46 < uli___> see you +10:47 < morimoto> wsa_: Actually, I'm sending Thermal patch to ML, but there is still no response from maintainer during 1 or 1.5 month +10:47 < shimoda> bye! +10:48 < morimoto> bye-cha! +10:48 < khiemnguyen> bye +10:52 < wsa_> morimoto: tickle him with chopstick katana ;) +10:52 < wsa_> cya! +--- Log closed Tue Jul 26 10:52:56 2016 diff --git a/wiki/Chat_log/20160803-mm-chatlog b/wiki/Chat_log/20160803-mm-chatlog new file mode 100644 index 0000000..d26a6ab --- /dev/null +++ b/wiki/Chat_log/20160803-mm-chatlog @@ -0,0 +1,277 @@ +Multimedia-chat-meeting-2016-08-03 + +<neg> hi all [16:22] +<pinchartl> hello +<uli___> hello +<pinchartl> I don't think Kieran or Magnus will join us today [16:24] +<pinchartl> so everybody is here +<pinchartl> let's thus get started [16:25] +<morimoto> hi +<pinchartl> I've asked you all to send task status by e-mail before the + meeting, and you have all done so +<pinchartl> thank you :-) +<pinchartl> let's see if we can speed this up, we'll cap the meeting to one + hour max [16:26] +<pinchartl> we also don't have to go through task status in details +<pinchartl> we can try the scrum-style meeting and just report work done, work + planned, and blockers/issues [16:27] +<neg> really sorry I need to let the postman in at the door, brb please go + head without me +<pinchartl> an announcement first +<pinchartl> I've submitted additional tasks for Q3 to Morimoto-san [16:28] +<pinchartl> we have exchanged a few e-mails about them, hopefully everything + is on track now +<pinchartl> morimoto: do you still need more information from me ? is there + anything I can do to help ? +<morimoto> Now, shimoda-san and our boss is checking it. +<pinchartl> or is everything fine ? +<pinchartl> is that a good sign ? :-) [16:29] +<morimoto> pinchartl: please wait. please start meeting first [16:30] +<pinchartl> well, I'll assume it's not a bad sign :-) +<pinchartl> that's all I wanted to announce on this topic +<pinchartl> I've also noticed that Salvator-X M3 boards have started shipping + [16:31] +<pinchartl> so let's get ready for integration work and testing on M3 +<morimoto> pinchartl: starting "paper work", not shipping ;P [16:32] +<morimoto> pinchartl: I send question mail to you. please check it +<pinchartl> well, paperwork is the first step for shipping :-) +<pinchartl> I will right after the meeting +<neg> back, sorry about that +<pinchartl> neg: no worries +<pinchartl> I'll give you a minute to read the log. any question ? [16:33] +<neg> thx, I'm good +<pinchartl> ok, let's go round the (virtual) table then [16:34] +<pinchartl> in alphabetical order as usual +<pinchartl> using the real alphabetical order this time, I'll start +<pinchartl> since last meeting in Japan three weeks ago +<pinchartl> - there was RenesasCon and LinuxCon Japan [16:35] +<pinchartl> followed by a week of holidays +<pinchartl> leaving a week and a half of work +<pinchartl> - I've continued working on the request API. Hans Verkuil is back + from holidays, I've discussed contention points with him and + Sakari Ailus [16:36] +<pinchartl> in the end there was no more disagreement with my proposal, so + I've continued working on the implementation [16:37] +<pinchartl> - I've also started IPMMU + DU integration, targetting Gen3 +<pinchartl> the result can't be tested properly on H3 as the IPMMU is known to + be faulty +<pinchartl> partial tests will be performed on Gen2 by hooking the VSP1 to the + DU the same way as we do on Gen3 [16:38] +<pinchartl> - last but not least, I acted as Magnus' deputy for additional + tasks negotiation +<pinchartl> during the next two weeks, I will [16:39] +<pinchartl> - continue working on IPMMU + DU and the request API +<pinchartl> - continue Kieran's work on the VSP image partitioning + implementation +<pinchartl> (Kieran has left for his honeymoon and will be back at the end of + the month) [16:40] +<pinchartl> issues and blockers: +<pinchartl> - the IPMMU is faulty on H3, blocking full testing of the IPMMU + + DU integration, but that's a known problem and not a blocker as + explained above [16:41] +<pinchartl> no other issue for me +<pinchartl> ah, I will also during the next two weeks try to get the VSP HGO + support upstreamed [16:42] +<pinchartl> a new iteration of the patch series might be needed with minor + changes, I don't expect any problem +<pinchartl> that's it for me +<pinchartl> Morimoto-san, you're next in the alphabetical order [16:43] +<morimoto> OK, +<morimoto> I have posted cleanup patches which is needed for OF graph. [16:44] +<morimoto> but still no responce from maintainer. I wonder is Europe under + summer vacation now ?? +<morimoto> 1 - 1.5 month, no responce +<pinchartl> some people must be [16:45] +<morimoto> OK +<pinchartl> who is the maintainer ? +<pinchartl> Mark Brown ? +<morimoto> Yes +<morimoto> Do you know his situation ?? +<pinchartl> he has been quite active on the kernel summit mailing list lately, + so he's definitely alive +<morimoto> OK alive. but no responce... [16:46] +<morimoto> Anyway, because of this, I started to solve other headache +<pinchartl> he doesn't seem to be on vacation +<pinchartl> you can ping him +<morimoto> Sometimes, he post his mail, but he doesn't accept patches, not + only me. [16:47] +<morimoto> So now, I started to solve other headache which is "unload" issue + on ALSA SoC [16:48] +<pinchartl> ah +<pinchartl> a big one +<pinchartl> I've seen your e-mails on that +<pinchartl> the topic was also mentioned by Lars in the kernel summit mailing + list +<morimoto> Yes. ALSA SoC has same issue [16:49] +<pinchartl> that's related to hotplug support, right ? +<morimoto> Yes. +<morimoto> especially, hot-unplug [16:50] +<pinchartl> ok +<morimoto> I'm not sure how to solve this issue, but I started to investigate + ALSA SoC framework, and I noticed that it has many duplicate + implementation. +<morimoto> It makes hotplug support difficult I think [16:51] +<morimoto> So, I would like to cleanup ALSA SoC +<pinchartl> I think you can discuss it with Lars if needed, he seems quite + interested in this topic as well +<morimoto> Now, I'm asking about it ot ML. +<morimoto> Nice idea. [16:52] +<morimoto> I think I can have a chance to talk him on next ELCE ? +<pinchartl> I would expect so, yes +<pinchartl> Mark Brown should hopefully be there too +<morimoto> I hope so +<pinchartl> maybe you should schedule a meeting with them at ELCE +<pinchartl> I would be interested in joining +<morimoto> sounds nice for me [16:53] +<morimoto> with beer ? +<morimoto> Anyway, this is current my status. +<pinchartl> :-) +<morimoto> I think this "hotplug" is requested for HDMI ? [16:54] +<pinchartl> yes +<pinchartl> well, I don't know how HDMI audio is implemented in ALSA +<pinchartl> and whether unplugging the cable will remove the device or not +<morimoto> In my understand, "unplugging cable" and "unload driver" are + different problem. [16:55] +<morimoto> But, some of them can be related ? +<morimoto> no sure +<pinchartl> they can be, but that depends on how ALSA handles it. I don't know +<pinchartl> is that something you can investigate ? +<morimoto> I think so. [16:56] +<pinchartl> thanks +<pinchartl> what is your plan for the next two weeks ? +<morimoto> For this purpose, my 1st step is cleanup framework. It is now tasty + spaghetti +<morimoto> 1) continue OF graph related patch work [16:57] +<morimoto> 2) investigate and cleanup ALSA SoC +<morimoto> It is related Mark's situation +<pinchartl> any issue or blocker, apart from Mark being unresponsive ? [16:58] +<morimoto> no blocker. +<pinchartl> thank you [16:59] +<morimoto> Oops, export paper work sometimes block me :) +<pinchartl> :-) +<pinchartl> neg: you're next +<neg> since last time: Working on addaptions to rcar-vin to keep up with + patches posted for adv7180 and help out Sergie with his problem. Added + ALTERNATE field support to rcar-vin +<neg> plan: Keep pushig for those patches and once they are picked up start to + break out patches from my Gen3 VIN series and post them in smaller + chunks to try and get some tracktion on them +<neg> issues: No reviews on the VIN Gen3 and CSI-2 patches and unclear how to + handle ADV7482 tasks. +<pinchartl> I suppose the "no review" is a hint for me ? :-) [17:00] +<neg> :-) +<pinchartl> I'll get to that [17:01] +<pinchartl> regarding ADV7482, would you like to discuss it at some point ? +<neg> np, if you are super swamped maybe you can hold off abit untill I start + sending out break out parts of the Gen3 series and review them +<pinchartl> early next week would work best for me if that's fine with you + [17:02] +<pinchartl> Monday or Tuesday +<neg> yes I would like to discuss ADV7482, just let me know when you have some + time +<pinchartl> (I'll be unavailable next Wednesday) +<pinchartl> ok [17:03] +<neg> sure, Monday morning and between 15-17 I will have builders starting + construction but other than that just ping me when you have time +<pinchartl> Monday 13:00 your time ? +<neg> works +<pinchartl> ok [17:04] +<pinchartl> uli___: you're next +<uli___> for work done, see the status update +<uli___> planned is to start on the additional tasks, plus deal with this: +<uli___> issue: +<uli___> the hdmi gen3 output needs to read the product register to handle + es1.1 [17:05] +<pinchartl> ouch +<uli___> right now, that is a hardcoded register access +<uli___> which people dislike +<uli___> in response, dirk behme wrote a driver +<uli___> which people consider overkill, i guess :) +<uli___> the last alternative is to code that in the DT, which i consider a + technical fail, considering it can be autodetected +<uli___> any opinions on how to tackle this? [17:06] +<pinchartl> why does the hdmi code need the product register value ? +<pinchartl> what is handled differently ? +<uli___> i must admit i have not looked into what it exactly does :) maybe + morimoto knows? +<morimoto> about ES1.1 ? [17:07] +<uli___> yes +<morimoto> Unfortunately, ES1.0 and ES1.1 have different behavior [17:08] +<morimoto> on HDMI +<pinchartl> is the code that handles the ES1.0/ES1.1 differences public ? +<uli___> it's from the bsp [17:09] +<pinchartl> where I can get it from ? +<uli___> morimoto-san sent an email about that to periperi [17:10] +<uli___> as a response to a group meeting summary +<uli___> Then, apply this new version of DPLL support patch from BSP. +<uli___> But, you will get conflict, but it is not difficult to fix. +<uli___> 01b4818ac558f17f7c74505003c5cca2fc149de1 +<uli___> (drm: rcar-du: Add DPLL support) +<uli___> Above DPLL support needs new header from BSP. +<uli___> 9c4c8fb9e6c11fb9594e3edaccc1c73976e0cfe6 +<uli___> (soc: renesas: Add product register helpers) +<pinchartl> what's the mail's subject ? +<uli___> "Renesas Multimedia Group Meeting" :) [17:11] +<morimoto> Re: [periperi] Renesas Multimedia Group Meeting +<uli___> it's from june 2 +<morimoto> Date: Thu, 2 Jun 2016 01:17:13 +0000 +<morimoto> +<pinchartl> got it +<pinchartl> I will have a look +<morimoto> It came from BSP +<pinchartl> uli___: when do you plan to address that ? [17:12] +<pinchartl> (to know what my deadline is to look at the issue) +<uli___> in the not too distant future, if possible +<uli___> i actually wanted to send it out yesterday, then i remembered that + this isn't addressed yet [17:13] +<pinchartl> could you be slightly more precise ? :-) +<uli___> in a week? +<uli___> or two? [17:14] +<pinchartl> ok, I'll try to check that on Monday too [17:15] +<pinchartl> is that fine ? +<uli___> yes, perfectly fine. thanks. +<pinchartl> you're welcome +<morimoto> I and Magnus had discussed about that, we can use Geert's DT + compatible magic ? I believe it will add es version on compatible. +<morimoto> "r8a7795-salvator" -> "r8a7795-salvator-es1.1" "r8a7795-salvator" +<uli___> that's the option i'd like to avoid if at all possible +<morimoto> OK [17:16] +<uli___> but i can deal with it, if necessary +<pinchartl> I also wonder how much work we should put into that, given that es + 1.0 is meant to disappear +<pinchartl> whatever solution we come up with, it must not make es 1.1 support + too complex or dirty +<pinchartl> anyway, I'll have a look [17:18] +<uli___> ok, thank you +<pinchartl> any last comment from anyone ? +<pinchartl> I'll take that as a no [17:19] +<neg> thanks for steping up as Magnus deputy :-) +<pinchartl> you're welcome +<pinchartl> I propose scheduling the next meeting in two weeks, Wednesday the + 17th, at the usual time (half an hour later than today) +<pinchartl> would that be fine for everybody ? +<neg> OK for me [17:20] +<uli___> fine for me +<morimoto> Not OK for me +<pinchartl> :-/ +<morimoto> it is under summer vacation +<pinchartl> when are your summer vacation ? +<morimoto> 13 - 21 +<morimoto> 13th Aug to 21th Aug I mean [17:21] +<pinchartl> I give you permission to skip the meeting then :-) +<morimoto> :) +<pinchartl> if you could send a status report either before leaving for + vacation, or after coming back, it would be appreciated +<neg> I will be in Berlin from tomorrow to sunday, so I might be slow in + responding during that time [17:22] +<morimoto> pinchartl: OK, I will try +<pinchartl> morimoto: thank you +<pinchartl> neg: ok, thanks for the information +<pinchartl> on the same topic, I will be on vacation from Saturday the 20th to + Sunday the 28th [17:23] +<pinchartl> we've reached the one hour limit +<pinchartl> and we're done with the meeting, so it's a good timing +<pinchartl> thank you everybody, and have a nice day in Europe or evening in + Japan [17:24] +<neg> thanks all +<morimoto> Thanks ! diff --git a/wiki/Chat_log/20160809-core-chatlog b/wiki/Chat_log/20160809-core-chatlog new file mode 100644 index 0000000..d6e4cc4 --- /dev/null +++ b/wiki/Chat_log/20160809-core-chatlog @@ -0,0 +1,217 @@ +Core-chat-meeting-2016-08-09 + +10:01 < geertu> Welcome to today's Core Group Chat +10:02 < geertu> It seems everybody is online (whatever that may mean), except for dammsan. +10:02 < khiemnguyen> hi +10:04 < geertu> So let's start with the status updates. I'll go first +10:04 < geertu> A) What have I done since last time +10:04 < geertu> Meetings, conferences, holidays +10:04 < geertu> B) What I plan to do till next time +10:04 < geertu> - MSIOF parent clock prototype, +10:04 < geertu> - Resume RST, MODEMR, ... +10:04 < geertu> C) Problems I have currently +10:04 < geertu> Nothing +10:04 < geertu> If you have questions/comments, feel free to interrupt ;-) +10:06 < geertu> "sort -R < members" tells me the next person is Shimoda-san +10:06 < shimoda> yes +10:07 < geertu> Shall I quote what you emailed? Or will you? +10:07 < shimoda> i will do +10:07 < geertu> OK, thx +10:07 < shimoda> A) What have I done since last time +10:07 < shimoda> I have no tasks for core group. But, +10:07 < shimoda> - I found an issue in usb-dmac driver. So, I sent a patch and Vinod applied this. +10:07 < shimoda> - I got a question about bias function from the BSP team. +10:07 < shimoda> And, I got information from Laurent-san and forwarded to the BSP team. +10:07 < shimoda> B) What I plan to do till next time +10:07 < shimoda> I will describe the lossy function to eLinux this time... +10:07 < shimoda> C) Problems I have currently +10:07 < shimoda> On Gen3, USB EHCI + IPMMU doesn't work correctly. +10:07 < shimoda> (But, this depends on data size. (Small data (within 4KB) can be transferred.)) +10:07 < shimoda> So, I'm investigating this with HW guy. +10:08 < pinchartl> is this related to the known IPMMU hardware bug on H3 ? +10:08 < shimoda> please let me know if you have any questions :) +10:09 < khiemnguyen> shimoda: USB XHCI + IPMMU does not have same issue, right ? +10:10 < shimoda> khiemnguyen: correct. this issue is just EHCI +10:10 -!- neg [~neg@unaffiliated/neg] has quit [Read error: Connection reset by peer] +10:10 -!- neg [~neg@unaffiliated/neg] has joined #periperi +10:10 < pinchartl> have you tested this on H3 or M3 ? +10:12 < shimoda> pinchartl: about EHCI? +10:12 < pinchartl> yes +10:12 < shimoda> yes, I tested EHCI on both H3 and M3 +10:12 < pinchartl> thanks +10:14 < geertu> shimoda: Thank you. +10:14 < geertu> Next person is Ulrich. +10:15 < uli___> a) and b), nothing +10:15 < uli___> c) my m3-w sys-dmac task is not included in my additional task sow +10:15 < uli___> i guess that will be worked out once magnus is back +10:16 < morimoto> uli___: I'm waiting reply from you about M3 board export +10:16 < uli___> sent it a minute ago, sorry for the delay +10:16 < morimoto> Oh thanks +10:17 < geertu> uli___: The m3-w sys-dmac task was planned for Q3 phase 1, and sent to Magnus. +10:18 < horms> (my connection is a bit flakey; if I drop off that will be why) +10:19 < geertu> uli___: Do you plan to send a v2 for the r8a7796 PFC support? +10:19 < uli___> yes, i will +10:20 < geertu> OK +10:20 < geertu> So I'll add that to B) :-) +10:20 < uli___> please :) +10:21 < geertu> uli___: Thank you +10:21 < geertu> Next person is Simon +10:21 < horms> A) What have I done since last time +10:21 < horms> Verified Suspend-to-RAM appears to work as well on M3-3/Salvator-X as +10:21 < horms> on H3/Salvator-X. That is suspend seems to work but resume occurs +10:21 < horms> immediately due to side effects of work arounds in firmware for hardware +10:21 < horms> problems with DDR timing. +10:21 < horms> Summer vacation, moved to the Netherlands. +10:21 < horms> B) What I plan to do till next time +10:21 < horms> Finalise Suspend-to-RAM work by writing report, test procedure, etc... +10:21 < horms> Begin work on kexec for M3-W. +10:21 < horms> C) Problems I have currently +10:21 < horms> What to do about H3ULCB board patches from Cogent. +10:21 < horms> Lets discuss this in this meeting if there is time. +10:21 < horms> +10:21 < horms> Any and all questions about above welcome. +10:22 < geertu> horms: OK, we can discuess H3ULCB after the status updates +10:22 < horms> great +10:23 < geertu> (that gives some time to Morimoto-san to dig up the documentation ;-) +10:23 < geertu> horms: Thank you +10:23 < geertu> Next person is Magnus, but he's not here +10:23 < geertu> Next person is Morimoto-san +10:24 < morimoto> OK, but Unfortunately, I have no Core task today. So I have nothing for a) b) c) +10:24 < geertu> I do have from you for A) +10:24 < geertu> - I started export paper work for M3 board for you guys +10:24 < geertu> - I had worked for Multimedia, no task for Core +10:24 < geertu> B) +10:24 < geertu> - I need to continue export paper work, and ship it ASAP if possible +10:24 < geertu> - No plan for Core +10:24 < geertu> C) +10:24 < geertu> - I don't like paper work +10:24 < geertu> - Decision of Summer Vacation plan +10:24 < morimoto> Thanks. C) is very big issue for me :) +10:25 < geertu> First or last subtopic? +10:25 < morimoto> both +10:25 < geertu> It seems the M3-W shipping is on track? +10:25 < morimoto> I'm working for export paper work for M3 +10:25 < morimoto> But under paper work +10:26 < morimoto> Niklas and Kilan's board goes through Magnu/Laurent +10:26 < morimoto> s/Magnu/Magnus/ +10:26 < morimoto> Because of Japanese Summer Vacation timing, shipping might be after Summer Vacation +10:27 < horms> I see the two items in C) are related to each other :) +10:27 < morimoto> I would like to shipping immediately, but... +10:27 < morimoto> geertu: that's it from me +10:28 < geertu> morimoto: Thank you +10:28 < geertu> Next person is Niklas +10:28 < neg> a: Nothing for core +10:28 < neg> b: Find a core task and start to work on it +10:29 < neg> c: no core task +10:29 < neg> I also have a question but we can save it to after the status part of the meeting. +10:29 < geertu> OK +10:29 < geertu> neg: Thank you! +10:29 < geertu> Next person is Khiem +10:30 < khiemnguyen> > A) What have I done since last time +10:30 < khiemnguyen> Tracking the update of CPUFreq in in-house BSP v3.3.2. +10:30 < khiemnguyen> BTW, I found that Kaneko-san has sent 2 patches to update Z-clock calculation for H3. +10:30 < khiemnguyen> However, it seems that the patches applied to wrong source file (clk-rcar-gen2.c) +10:30 < khiemnguyen> I will try to look into that patches and reply the emails. +10:30 < khiemnguyen> I will try to look into that patches and reply the emails. +10:30 < khiemnguyen> > B) What I plan to do till next time +10:30 < khiemnguyen> Complete Gen3 CPUFreq patchset. +10:30 < khiemnguyen> > C) Problems I have currently +10:30 < khiemnguyen> Time flies but nothing complete. +10:30 < khiemnguyen> Will need to check my to-do list again. +10:31 < khiemnguyen> that's all from me. +10:32 < horms> About those patches +10:32 < horms> they are from the BSP +10:32 < horms> I assumed Kaneko-san would rebase them to use the correct source file +10:33 < horms> sorry that he didn't but if you could look into them anyway I would be grateful +10:33 < khiemnguyen> horms: yes, I will reply his email. +10:34 < horms> great, thanks! +10:37 < pinchartl> morimoto: regarding the M3 boards, you mentioned shipment could get delayed after summer vacation, when would that be, roughly ? +10:37 < geertu> khiemnguyen: Thank you! +10:37 < morimoto> pinchartl: we don't know at this point. I'm tring hard for it now +10:38 < morimoto> If I can do *before* summer vacation, we can ship end of this week +10:38 < pinchartl> ok +10:38 < morimoto> If I couldn't, It will be after summer vacation, it will be 22th's week +10:38 < pinchartl> I will be away from home from the 18th to the 30 of August +10:39 < morimoto> Ohh.. +10:39 < geertu> Ship it to Toronto ;-) +10:40 < pinchartl> geertu: given that I'll be in Belgium and France, I don't think that would help +10:40 < horms> Probably it is not helpful, but if it is I'm happy to act as an intermediary +10:40 < geertu> pinchartl: Oh, you're skipping LinuxCon +10:41 < geertu> I'm in Belgium between 18th and 30th of August anyway +10:41 < pinchartl> :-) +10:42 < pinchartl> morimoto: so, there's no urgency for me. Kieran will also be back at the end of the month only +10:42 < pinchartl> you can thus ship the boards at end of August +10:42 < pinchartl> no need to rush, enjoy your summer vacation :-) +10:43 < shimoda> morimoto-san is now calling to someone +10:44 < shimoda> this seems related to the peper work :) +10:46 < morimoto> Sorry, it was shipment guy. +10:46 < morimoto> We try to ship board 11th from Renesas, but it seems shipment side is busy +10:46 < geertu> Last person is Laurent +10:47 < pinchartl> nothing to report for core +10:47 < pinchartl> no work done, no work to do, no issue :-) +10:48 < morimoto> Perfect !! +10:48 < geertu> pinchartl: Thank you! +10:49 < pinchartl> nyt on lounasaika ! +10:49 < pinchartl> (now is lunch time) +10:49 < geertu> Let's eat H3ULCB +10:49 < geertu> pinchartl: enjoy your lunch! +10:49 < morimoto> :P +10:49 < pinchartl> talk to you later +10:50 < neg> I have a question if it would be bad to send a patch to enable CONFIG_CGROUPS in shmobile_defconfig? +10:50 < geertu> So it seems Renesas/Cogent have a low-cost H3 board called H3ULCB +10:50 < neg> ohh my bad please go ahead with H3ULCB talk +10:50 < geertu> neg: No objection. It's what makes shmobile_defconfig boot on my koelsch +10:50 < horms> neg: I'm ok with that if there is a reason for it +10:51 < geertu> Although my personal koelsch config doesn' +10:51 < geertu> t hav it set +10:51 < horms> MY position on the H3ULCB patches is this: +10:51 < neg> horms: is i need it for systemd init and I keep forgeting to enable it and it bugs me a good reason? Other then that I have no real technical reason to wish to enable it :) +10:51 < horms> 1) I'm mostly ok with adding a board we can't test as its for an SoC that is already in mainline +10:51 < geertu> So in shmobile_defconfig, it seems to avoid the strange lock ups during boot, which I could also avoid by adding the right number of nop()s +10:52 < horms> neg: sounds good. systemd is standard on Debian these days. I would probably have the same problem if I updated userspace. And Debian is the defacto user-space test imho +10:52 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] +10:53 < neg> OK thanks I will send a patch enableing it then +10:53 < horms> 2) I'd like them to split up the patch to enable IP blocks one by one +10:53 < horms> 3) I'd prefer if any IP blocks not enabled on H3/Salvator-X were at the end of the patch-set +10:53 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi +10:54 < horms> 4) I would value input from the group, especially Morimoto-san and Shimoda-san -> I think Renesas should be aware of this +10:54 < horms> --- thats about it from my side --- +10:54 < geertu> I agree with all four points +10:54 < geertu> 5) Can we get documentation? +10:55 < geertu> 6) Can we get access to a board (e.g. in Magnus' farm)? +10:56 < shimoda> geertu: at the moment, i don't have the board. +10:57 < morimoto> shimoda: we can have 1 or 2 boards. +10:57 < horms> shimoda: do you think some kind of discussion with e.g. Munakata-san would be best before adding the board to mainline? +10:57 < morimoto> Maybe we will ask to Magnus about remove-access ? +10:59 < horms> I think that would be ideal +11:00 < morimoto> horms: about discussion with Munakata-san, maybe no discussion is needed, but we will re-check +11:00 < horms> Thanks! +11:01 < geertu> That's good to hear. +11:01 < geertu> I assume documentation will follow, too? +11:02 < morimoto> depends on which documentation. "board" documentation ? +11:02 < morimoto> you can get it from elinux on some board. (I don't know which board...) +11:02 < geertu> morimoto: Yes, e.g. schematics, so we can review the DTS +11:03 < geertu> morimoto: Not for H3ULCB AFAIK (porter and silk you can) +11:03 < morimoto> schematics is a little bit difficult. +11:03 < morimoto> I can say case-by-case +11:04 < horms> well, probably anything for the H3ULCB would be helpful +11:05 < horms> but if there is nothing available +11:05 < horms> we can just trust Cogent +11:05 < morimoto> hmm... +11:07 < khiemnguyen> for Porter or Silk, if we buy the boards, I think the schematics files are available in the CD. +11:10 < geertu> khiemnguyen: For porter and silk, there are links to the schematics on the eLinux wiki. You need to register with Renesas to access the links, though. +11:11 < khiemnguyen> I think H3ULCB will be the same, but we need to wait till next year ? +11:14 < horms> Ok, sounds like we should wait +11:15 < shimoda> about the documentation of H3ULCB, i will ask Munakata-san or Ito-san +11:15 < shimoda> if no doc, we should wait +11:17 < geertu> shimoda: ok, thx! +11:23 < morimoto> Is meeting finished ?? +11:24 < uli___> not sure :) +11:24 < geertu> Sorry, too distracted by SoW paperwork issues... +11:25 < geertu> Yes, unless someone has something to add, I think the meeting is finished +11:25 < neg> I would like to know if there is any core task I can start to work on, but maybe we can take that my mail :-) +11:26 < morimoto> OK, thanks. +11:26 < morimoto> geertu: please enjoy your paperwork :) +11:29 -!- morimoto [~user@relprex2.renesas.com] has left #periperi ["ERC Version 5.3 (IRC client for Emacs)"] +11:31 < geertu> neg: yes, email please +11:31 < geertu> Thanks for joining! diff --git a/wiki/Chat_log/20160811-io-chatlog b/wiki/Chat_log/20160811-io-chatlog new file mode 100644 index 0000000..64f1b0f --- /dev/null +++ b/wiki/Chat_log/20160811-io-chatlog @@ -0,0 +1,243 @@ +--- Log opened Thu Aug 11 10:00:02 2016 +10:00 -!- wsa_ [~wsa@dslb-178-008-085-090.178.008.pools.vodafone-ip.de] has joined #periperi-io +10:00 -!- Irssi: #periperi-io: Total of 3 nicks [1 ops, 0 halfops, 0 voices, 2 normal] +10:00 -!- Irssi: Join to #periperi-io was synced in 1 secs +10:00 < wsa_> hi guys! +10:00 < morimoto> Hi +10:00 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi-io +10:00 -!- neg [~neg@unaffiliated/neg] has joined #periperi-io +10:00 < neg> morning +10:00 < shimoda> hello +10:00 < wsa_> good morning +10:00 -!- geertu [~geert@d54c189fd.access.telenet.be] has joined #periperi-io +10:00 < morimoto> Kon-ni-chi-wa +10:01 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi-io +10:01 < geertu> Mornin' +10:01 < wsa_> Guten Morgen! +10:01 -!- horms [~horms@217.111.208.18] has joined #periperi-io +10:01 -!- Irssi: #periperi-io: Total of 8 nicks [1 ops, 0 halfops, 0 voices, 7 normal] +10:02 < geertu> Goeiemorgen Simon +10:02 < horms> Goed Morgen +10:03 < wsa_> okay, let's start +10:03 < wsa_> sort -R did some magic again +10:04 < wsa_> shimoda: you are first today +10:04 < shimoda> yes +10:04 < shimoda> should i talk about a) b) c)? +10:04 < wsa_> please do +10:05 < shimoda> A) What have I done since last time +10:05 < shimoda> I sent some bugfix patches of usbhs driver +10:05 < shimoda> B) What I plan to do till next time +10:05 < shimoda> I will send performance improvement patch for usbhs + g_ncm +10:05 < shimoda> I will send OTG support for gen3 usbhs driver +10:05 < shimoda> C) Problems I have currently +10:05 < shimoda> investigate an issue that M3-W USB3 doesn't work if high speed device is connected with HW guys +10:05 < shimoda> done +10:05 < wsa_> thanks +10:06 < wsa_> from last time: can you send the email about the suspend problem? khiem wanted to have a look at it, I think +10:06 < wsa_> for usb3-host +10:07 < shimoda> oops, maybe i don't do that +10:09 < khiemnguyen> shimoda: please send the email. +10:09 -!- neg [~neg@unaffiliated/neg] has quit Read error: Connection reset by peer +10:09 < wsa_> ah, so you want to work on the problem yourself? +10:09 < wsa_> or do you say you just forgot it? +10:09 * geertu is called bu the door bell +10:10 -!- neg [~neg@unaffiliated/neg] has joined #periperi-io +10:10 < shimoda> sorry, just forgot it... +10:10 < wsa_> okay +10:10 < shimoda> khiemnguyen: yes, i will send it +10:10 < wsa_> great +10:10 < wsa_> horms: you are next +10:10 < horms> sure +10:11 < horms> a) what have I worked on since last time +10:11 < horms> * Resolved timeouts during tuning which is related to UHS-I/SDR104 +10:11 < horms> support; reposted sdr104 patchset; awaiting review +10:11 < horms> * Posted patches to enable SDHI0, 1 and MMCIF on r8a7794/Alt, +10:11 < horms> Modeled on r8a7794/Silk; lightly tested; awaiting review +10:11 < horms> b) what will I work on until next time +10:11 < horms> * Work on merge of above +10:11 < horms> * Extend SDR104 coverage to other boards +10:11 < horms> c) I have the following problems (or not) +10:11 < horms> * SD cards in Magnus's board farm, maybe +10:11 < horms> end +10:11 * geertu back (sort of) +10:11 < wsa_> so, no timeouts with SDR104 anymore? +10:13 < horms> I have not seen them with the latest patchset +10:13 < horms> They may still be lurking +10:13 < wsa_> awesome +10:13 < horms> Possibly something will show up when I extend support to other Boards +10:13 < horms> Or try other SD cards +10:13 < horms> but I did try the usual-suspect SD cards +10:13 < horms> in particlar one that liked to timeout a lot was my main test case +10:13 < wsa_> as i said in my review, i think we can work incrementally from where we are and merge the patches +10:14 < horms> I can give details on the cards tested etc... +10:14 < wsa_> let's hope ulf agrees :) +10:14 < horms> actually its on the e-linux wiki +10:14 < horms> ok +10:14 < wsa_> uli___: you are next +10:14 < horms> do you think you could respond to the latest patchset with an ack or something? +10:15 <@uli___> a) nothing i/o-related; b) check sdr104 performance (card's in the mail); c) nothing i'm aware of +10:15 <@uli___> horms: could you send a link to that e-linux page? +10:15 < horms> one moment +10:15 < geertu> uli___: Did my MSIOF patch help for mmc-over-msiof? +10:15 < wsa_> horms: I send a Tested-by just yesterday +10:16 < wsa_> sent +10:16 < horms> wsa_: thans! +10:16 <@uli___> geertu: didn't have time to check that yet +10:16 < horms> uli___: http://elinux.org/Tests:SD-SDHI-SDR104 +10:16 <@uli___> thanks +10:17 < horms> uli___: Samsung Card 2 is the one that liked to timeout the most. But to be fair there were bugs in the code. +10:17 <@uli___> are these sdr50 or sdr104? +10:18 < wsa_> uli___: you think you can work on MSIOF this month? +10:18 <@uli___> i think i can fit that in +10:18 < wsa_> good +10:19 < wsa_> wsa_: you are next +10:19 < wsa_> with pleasure +10:19 < wsa_> a) i reviewed and tested simons patchset +10:19 < wsa_> i tried to find the i2c-demux regression but no luck so far +10:20 < wsa_> b) I will find this i2c-demux regression +10:20 < wsa_> a) worked on additional tasks, I hope you got the contracts today? +10:20 < geertu> wsa_: Got the draft SoW today +10:21 < wsa_> c) the problem with the i2c-demux issue is that a pointer within the devicetree seems to change although it should be constant +10:21 < wsa_> (but we are talking OF_DYNAMIC here, so a bit more tricky) +10:22 < horms> uli___: the test numbers are sdr104 +10:22 < wsa_> and Magnus being totally gone +10:22 < wsa_> like for some negotiations or changes to his lab +10:22 < horms> uli___: which is only available on one slot on the r8a7790/Lager +10:23 <@uli___> horms: ok, thanks +10:23 < wsa_> that's it +10:23 < horms> wsa_: thanks, my SoW arrived +10:23 <@uli___> [off-topic] geertu: i got my core draft today as well +10:23 < wsa_> has someone any news from Magnus? +10:23 < horms> wsa_: your pointer findings match my earlier inestigation +10:24 < morimoto> wsa_: nothing to Renesas +10:24 < neg> wsa_: I tried to contact him a few days back to get a copy of my SoW still no response +10:24 < horms> wsa_: you may want to look at the presentation by Frank Rowland at LCJ. The tool he discussed there for dumping and diffing kernel DT may be useful somehow +10:24 < horms> wsa_: no, I have not heard from M +10:24 < horms> not for about a month now +10:24 < horms> hopefully he is still alive +10:24 < geertu> I talked to him before I went on holidays. He planned to be back in Tokyo August/M +10:25 < wsa_> horms: oh, that tool could be interesting, thanks +10:25 < wsa_> so, maybe just a few more days +10:25 < horms> wsa_: i specifially asked if it was possible to diff between kernel DT states over time. He said yes. +10:25 < wsa_> nice! +10:25 < horms> Its probably in the recording of the presentation near the end if such a thing exists +10:26 < wsa_> If all fails, I will mail him ;) +10:26 < wsa_> geertu: your turn now +10:26 < horms> Yes, he seemed quite happy to share his knowledge +10:27 < geertu> A) What have I done since last time +10:27 < geertu> Fixed invalid clock generator parameters with MSIOF +10:27 < geertu> B) What I plan to do till next time +10:27 < geertu> r8a7795 MSIOF parent clock control prototype (core) +10:27 < geertu> Implement initial SPI slave prototype support for R-Car Gen2 +10:27 < geertu> C) Problems I have currently +10:27 < geertu> None +10:28 < geertu> From my current state, I think static configuration in DT of the MSIOF parent clock frequency is the way to go, though +10:29 < wsa_> ok, let's see how it goes +10:29 < wsa_> neg: your turn +10:30 < neg> a) EtherAVB suspend/resume patches posted and picked up in net-next, still trying to reproduce 'OHCI-PCI doesn't seem to work with CONFIG_DMA_CMA=y' problem. +10:30 < neg> b) Update U-Boot on my Koelsch and see if I can reproduce the CONFIG_DMA_CMA=y problem then +10:30 < neg> c) My toolchain complains when I try to build new u-boot image, need to get older version and procedure to upgrade u-boot seems tricky, hope I wont brick by Koelsch in the process :-) +10:31 < geertu> neg: Have you tried Magnus' Lager instead? +10:32 < wsa_> can't you just use geert's binary? +10:32 < neg> geertu: no, I will try it parallel to trying to update my u-boot +10:33 <@uli___> you could compile u-boot to a different address and chain-load it from the old version +10:33 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has quit Quit: http://www.kiwiirc.com/ - A hand crafted IRC client +10:33 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi-io +10:34 < geertu> uli___: If you do that, you'll have side-effects of hardware initialization of the first one, right? +10:34 < neg> uli___: thanks I will try that +10:34 <@uli___> possible. but it might just work. :) +10:34 <@uli___> i.e., break, in this case +10:35 < neg> flash update, I managed to build u-boot using the toolchain from kbuild so I think I should be fine :) +10:35 < wsa_> good luck then! +10:35 < wsa_> :) +10:35 < neg> so thats about it from me +10:35 < wsa_> khiemnguyen: your turn +10:37 < wsa_> knock knock +10:37 < khiemnguyen> yes. +10:37 < khiemnguyen> A) What have I done since last time +10:38 < khiemnguyen> No update +10:38 < khiemnguyen> It meant that I have not sent any updates into ML yet. +10:38 < khiemnguyen> I have tracked R-Car Gen3 Thermal driver in in-house BSP (v3.3.2), if there's any hints to update my patchset. +10:38 < khiemnguyen> B) What I plan to do till next time +10:38 < khiemnguyen> Complete Gen3 Thermal driver +10:38 < khiemnguyen> C) Problems I have currenty +10:38 < khiemnguyen> (same as for Core group) +10:38 < khiemnguyen> - Time flies but nothing complete. +10:38 < khiemnguyen> - Will need to check my to-do list again. +10:39 < khiemnguyen> As Laurent information, v4.9 might be next LTS. +10:39 < khiemnguyen> I think I will try to complete R-Car Gen3 Thermal for v4.9. +10:39 < wsa_> and does the BSP indicate updates to the thermal driver? +10:40 < khiemnguyen> yes, we did have some updates in BSP v3.3.2 +10:41 < khiemnguyen> one of the consideration points is difference of the thermal initialization processing in H3 WS1.0/WS1.1 and 2.0 +10:41 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has quit Read error: Connection timed out +10:41 < wsa_> i see +10:42 < wsa_> morimoto: your turn now +10:42 < morimoto> A) I asked about my posted thermal driver patch to maintainer. thermal maintenance system seems confusable. 1 of them was accepted. +10:42 < morimoto> B) I will keep ask and wait for it, and will post next bug fix patch. +10:42 < morimoto> C) no headache +10:42 < morimoto> Here, my thermal is for Gen2, khiemnguyen's one is for Gen3 +10:42 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi-io +10:42 < morimoto> EOF +10:43 < khiemnguyen> that's all of my status. +10:44 < morimoto> wsa_: that's all of my status, too :) +10:44 < khiemnguyen> geert: how about the status of SoC revision checking ? Dirk patchset +10:46 < geertu> khiemnguyen: No updates. That's core work, for after August 15 +10:46 < wsa_> any other questions from your side? +10:46 < wsa_> i have none +10:47 < horms> no io questions from me +10:47 < wsa_> only the inofficial question what the "H3ULCB" board is? Some custom board? Some (semi-)official Renesas board? +10:47 < shimoda> i have no questions, but I got some SCIF driver's requests from our front team +10:48 < wsa_> shimoda: what are they? +10:48 < geertu> wsa_: Have you read the Core Group Meeting Minutes? +10:48 < shimoda> they needs to improve timeout interval for highspeed (1Mbps or more) +10:49 < shimoda> the current driver uses normal timer API +10:49 < horms> wsa_: yes, i would like to follow up with morimoto on H3ULCB. I can talk to you about it i you like but as Geert mentions its detailed in the core group minutes. afik there are no io issues relating to it at this time. +10:49 < shimoda> they suggest highres timer +10:50 < wsa_> geertu: I have; it doesn't answer my question, though +10:50 < wsa_> Is it a Renesas board? +10:50 < horms> what is your question? +10:50 < geertu> wsa_: I don't know more. "low-cost" means it's the silk/porter equivalent for H3 +10:50 < horms> I think so. Morimoto-san, Shimoda-san? +10:50 < geertu> wsa_: According to Sergei, it's Renesas +10:51 < wsa_> thanks +10:51 < morimoto> LCB = Low Cost Board +10:51 < wsa_> shimoda: so i add a task like: +10:52 < shimoda> horms: yes, it is like silk/porter, but I heard our customers is possible to use many the ULCB instead of salvator +10:52 < shimoda> wsa_: thanks for adding +10:53 < horms> morimoto: shimoda: are we ok to proceed with upstreaming. Sergei has been pinging Geert and I on #renesas-soc +10:53 < wsa_> SCIF,?,noplan,?,use highres timers for timeouts with speeds >1MBps +10:53 < shimoda> so, Munakata-san is thinking upstream team should support it as well, not like silk/porter +10:53 < wsa_> geertu: does this task make sense to you? +10:54 < geertu> wsa_: I think so (which highres timer do we have, that we can use? ARM arch timer?) +10:54 < morimoto> H3ULCB board will to e-linux page on Oct. I know horms/geertu want to have schematic soon. So, our other team is now doing export paper work for it. So, hopefuly, you can get schematic 8/E +10:55 < horms> Thanks. In the mean time is it ok from a Renesas pov for us to take patches from Cogent into mainline? From my pov it is ok. +10:55 < geertu> morimoto: Thanks, looking forward to it. +10:56 < shimoda> horms: Goda-san hope the dts is merged into v4.9 for LTS(I) +10:56 < horms> got it +10:56 < horms> I will give Cogent the green light +10:57 < shimoda> horms: thanks for it! +10:57 < wsa_> ok +10:58 < wsa_> i think we are done now with the official part +10:58 < wsa_> H3ULCB is not really IO topic anymore ;) +10:58 < wsa_> thanks guys! +10:58 < shimoda> thank you! +10:58 < neg> thanks all +10:59 < horms> thanks! +10:59 < morimoto> Thanks. Renesas Japan will have Summer Vacation from 13th to 21th. +10:59 < khiemnguyen> thanks. +10:59 < geertu> thx, bye, enjoy the holidays! +10:59 < wsa_> yes, have great holidays +11:00 < morimoto> geertu/wsa_: Thanks ! +11:00 < wsa_> i'll be mostly away 15th-21st as well +11:01 < morimoto> I want to ship M3 board to you, but because of time-limit, it is 50% +11:03 < wsa_> for me, no hurry +11:04 < wsa_> IIRC the only one from IO group having a M3 related task is Simon +11:04 < wsa_> which is optional task, even +11:06 < morimoto> OK, but unfortunately, I could confirm that the chance of M3 board before summer vacation is now 0% +11:06 < morimoto> today was shipping time-limit +11:07 < morimoto> So, I will ship it on 22th or later +11:07 < wsa_> ok +11:07 < morimoto> thanks, and bye +11:07 -!- morimoto [~user@relprex1.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +11:11 < wsa_> cya! +--- Log closed Thu Aug 11 11:11:03 2016 diff --git a/wiki/Chat_log/20160830-core-chatlog b/wiki/Chat_log/20160830-core-chatlog new file mode 100644 index 0000000..93e61f0 --- /dev/null +++ b/wiki/Chat_log/20160830-core-chatlog @@ -0,0 +1,351 @@ +Core-chat-meeting-2016-08-30 + +10:08 < geertu> Welcome to today's Core Group Chat +10:08 < geertu> Agenda: +10:08 < geertu> 1. Status updates +10:08 < geertu> 2. r8a7792/Wheat board is being/has been added to mainline +10:08 < geertu> 3. r8a7795/H3ULCB board is pending: Cogent seems to have prioritised Wheat +10:08 < geertu> 4. Renesas would like to know the kernel size issue on upstream. +10:08 < geertu> Topic 1. Status updates +10:08 < geertu> A) What have I done since last time +10:08 < geertu> B) What I plan to do till next time +10:08 < geertu> C) Problems I have currently +10:08 < geertu> sort -R wants Simon to talk first +10:11 < horms> Ok. +10:11 < horms> A) +10:11 < horms> * Verified Suspend-to-RAM appears to work the same with both UP and SMP +10:11 < horms> on H3/Salvator-X (M3-W/Salvator-X is UP in mainline) +10:11 < horms> Added test procedure +10:11 < horms> http://elinux.org/Tests:R-CAR-GEN3-Suspend-to-RAM +10:11 < horms> B) +10:11 < horms> * Finalise Suspend-to-RAM work by documenting hw/sw stack, writing report, +10:11 < horms> etc... +10:11 < horms> * Begin work on kexec for M3-W. +10:11 < horms> C) Problems I have currently +10:11 < horms> +10:12 < horms> * Kernel image size +10:12 < horms> And some late breaking news: +10:12 < horms> I have merged initial RSKRZA1 support +10:12 < horms> And preliminarily verified that kexec functions on h3/salvator-x +10:12 < horms> --- end --- +10:13 < geertu> That's good news! No need to kick Geoff? +10:13 < horms> Well, his userspace patches still haven't been merged (by me) +10:13 < horms> because they are still recieving review +10:14 < horms> but thats not a blocker for my work +10:14 < horms> And I am also unsure if his patches do/should support running in a 32bit userspace +10:14 < horms> Probably they should +10:14 < horms> I will check that +10:14 < horms> and engage with him if needed +10:14 < horms> Then onwards to m3-w +10:14 < horms> which is a little more tricky +10:14 < horms> due to needing to use initrd +10:14 < horms> but the board has sd cards in it now +10:15 < horms> so i can probably make use of that somehow +10:15 < horms> actually, the tricky part is no network +10:15 < horms> so its a bit fun to transfer the second kernel image and kexec binary +10:15 < horms> but I'm sure it can be done somehow +10:16 < horms> --- enough on kexec? --- +10:16 < geertu> Ravb should work on M3-W with a compatible update +10:16 < horms> ok, that is also an option +10:16 < horms> nicely moves m3-w integration forwards at the same time +10:16 < geertu> Alternatively, you can ask Magnus to connect the second serial port. +10:17 < horms> and use it for bulk transfers somehow? +10:17 < geertu> Keep 64-bit RAM and IOMMU in mind before pushing it out ;-) +10:17 < geertu> I used gzip and uuencode to transfer DT overlays to H3 before I had physical access +10:17 < horms> yeah, i'm not convinced about the ordering we have decided on for integration. but given that we have decided on an order I'll try not to break it +10:18 < horms> right, that could work too +10:18 < geertu> (Magnus initrd does have uudecode) +10:18 < horms> probably firing up ravb is nicer :) +10:18 < horms> magnus inired is 32bit +10:18 < geertu> yeah, then you can tftp the files from the management host +10:19 < horms> if i have network, right? +10:19 < horms> i.e. ravb +10:19 < geertu> 32-bit userspace should work. +10:19 < horms> as i mntioned above +10:19 < geertu> But you're worried about the kexec binary? +10:19 < horms> i'm unsure if kexec-tools works +10:19 < horms> ys +10:19 < horms> yes +10:19 < horms> probably copiling for armel +10:19 < horms> makes a binary that wants to operate on 32bit hosts +10:19 < horms> just guessing +10:19 < horms> as I mentioned above I plan to look into that +10:20 < horms> but in any case I'd like to test 64bit userspace +10:20 < geertu> You need to compile your own kexec-tools anyway, so just link it statically. The rest of the initrd can stay 32-bit. +10:20 < horms> ok, i was wondering about that +10:20 < horms> thanks for the info +10:22 < geertu> Thanks Simon. +10:23 < geertu> Next is Lurking Laurent (sounds like an Ubuntu release :-)? Anything to say? +10:23 < pinchartl> nope, nothing to report +10:24 < pinchartl> or maybe +10:24 < pinchartl> I've been working before going on holidays on IPMMU + DU integration +10:24 < pinchartl> (tested on Gen2 only as the H3 IPMMU is known to be buggy) +10:24 < pinchartl> I've posted a patch series +10:25 < pinchartl> which touches multimedia drivers and DT only, no change to the IPMMU driver or the IOMMU or DMA mapping layers +10:25 < pinchartl> I'd appreciate feedback on them, but that might be a multimedia topic more than a core topic +10:25 < pinchartl> although the issue at hand is quite generic +10:25 < pinchartl> that's it for me +10:26 < horms> pinchartl: Magnus may be looking into that +10:26 < geertu> Thanks Laurent. +10:26 < geertu> Next is myself +10:26 < geertu> A) - completed MSIOF parent clock prototype, +10:27 < geertu> - Resumed MODEMR (APMU debug resource reset for secondary CPU boot), ... +10:27 < geertu> B) Continue RST, MODEMR, ES-handling, ... +10:27 < geertu> C) Nothing +10:28 < geertu> So I posted a patch series to do APMU debug resource reset for secondary CPU boot +10:28 < geertu> So far I didn't see any ill effects (running Koelsch with SW8-4 is off all the time) +10:28 < geertu> Haven't tried JTAG yet +10:29 < geertu> Unfortunately the issue it fixes is very hard to trigger. +10:29 < geertu> But from a source code management point of view, one check less of the MODEMR pins. +10:30 < geertu> EOT +10:32 < geertu> Next is Shimoda-san +10:32 < shimoda> yes +10:32 < shimoda> A) +10:32 < shimoda> I'm focus on Gen3 USB EHCI + IPMMU issue. +10:32 < shimoda> So, nothing for core. +10:32 < shimoda> B) +10:32 < shimoda> I should describe an explanation of "Lossy" into eLinux... +10:32 < shimoda> C) +10:32 < shimoda> I would like to know whether the PFC bias setting I made for USB is correct or not. +10:32 < shimoda> Please see the email of "RE: [periperi] About splitting the USB pins in r8a7795". +10:33 < shimoda> The sent date is "Monday, August 22, 2016 10:48 AM" (JST). +10:33 < geertu> I think it is (I did reply, right?) +10:33 < geertu> My only comment was naming of the nodes +10:34 < shimoda> oops, i missed your email... +10:34 < shimoda> let me check... +10:36 < shimoda> i found your email and i got it! thank you for comment! +10:39 < geertu> Thanks Shimoda-san. +10:39 < geertu> Next is Magnus, who hasn't reappeared on irc +10:39 < geertu> Next is Ulrich. +10:39 < uli___> a) resent m3-w pfc to universal approval +10:40 < uli___> did a hardcore copy-and-paste job of sys-dmac integration on m3-w +10:40 < uli___> b) test sys-dmac with my new board scheduled to arrive today +10:40 < uli___> c) none +10:40 < uli___> re-sent, not resent :) +10:40 < uli___> that's it +10:42 < geertu> I sent a pull request incl. your r8a7796 pfc changes +10:42 < geertu> Unfortunately LinusW hasn't pulled it yet. +10:42 < morimoto> Is it for v4.9 ? or v4.8 ? +10:42 < geertu> v4.9 +10:42 < morimoto> OK, thanks +10:43 < khiemnguyen> geertu: how much time is remained for v4.9 ? +10:43 < geertu> As soon as LinusW has pulled it, Simom can pull it too, and start applying PFC patches to r8a7796-salvator-x.dts +10:43 < geertu> We're at -rc4 +10:43 < geertu> s/Simom/Simon/ +10:43 < khiemnguyen> 3 weeks ? +10:43 < geertu> Depending on the maintainer, you can submit patches for v4.9 until ca. -rc6 +10:45 < horms> I would like to finalise our submissions next week +10:45 < horms> submissions to arm-soc that is +10:45 < horms> so they arrive in their inbox before rc6 +10:45 < horms> which is their requirement +10:46 < geertu> Thanks Ulrich. +10:46 < geertu> Next is Morimoto-san +10:46 < morimoto> OK +10:46 < morimoto> Basically I have no special Core tasks. +10:46 < morimoto> But, I have shipped M3 board to you guys, except Simon. +10:46 < morimoto> I hope each EuroPeri's VAT number will works well on Europe side. +10:46 < morimoto> I pushed M3's firmware on new page of our Wiki. And moved H3's firmware to it. +10:46 < morimoto> Please check it if you have interresting +10:47 < morimoto> horms: I'm waiting your feedback for it. +10:47 < morimoto> I noticed that BSP's (?) CMT patch breaks NFS boot on latest renesas-drivers. +10:47 < morimoto> I think it works correctly on previous kernel version. +10:47 < morimoto> BSP team want to know kernel size issue, but this is next topics (?). +10:47 < morimoto> that's all from me +10:47 < geertu> FYI, my board is also scheduled to arrive today. +10:47 < geertu> Hence a big thanks (or is that too early ;-) +10:47 < horms> morimoto: thanks and sorry for the delay. I think there has been some progress. I will let you know when I know with some more certainty. +10:48 < morimoto> horms: thanks. no problem. +10:48 < horms> Oh, wiki feedback? +10:48 < geertu> s/CMT/CMA/? +10:48 < horms> or eori feedback? +10:48 < morimoto> geertu: I hope your VAT number works well +10:48 < morimoto> Oops CMA +10:48 < geertu> morimoto: I think so, it's printed on the PDF docs I already received by email. +10:49 < geertu> Those documents also mention 2.6% custom duty and 21% VAT, but it's not clear I'll have to pay that +10:50 < morimoto> Oops ? you need to pay something ? +10:50 < geertu> morimoto: I don't know. Last year I didn't. But Laurent had to? +10:51 < morimoto> Shipping payment was controlled by Renesas side paper work. I think your side no need to pay +10:51 < morimoto> I don't know Europe's tax pay... +10:52 < morimoto> geertu: please let me know if you pay something +10:53 < geertu> morimoto: The M3-W arrived 30 seconds ago, thanks! +10:53 < geertu> So far nothing to pay... +10:53 < morimoto> Wow ! +10:54 < morimoto> EuroPeri side have new world ! +10:55 < geertu> Thanks Morimoto-san. +10:55 < geertu> Next is Niklas +10:55 < neg> Easy for me this time, a) and b) Nothing for core c) Still waiting for RMK to review the IOMMU+DMAC patchset +10:56 < morimoto> horms: sorry for late response. I need EORI or VAR number +10:57 < geertu> RMK can be a PITA... +10:57 < horms> morimoto: ok. i am on the case +10:57 < geertu> morimoto: You didn't need an EORI for me? +10:57 < morimoto> geertu: simon was special case +10:58 < morimoto> According to shipping guy, basically VAT number is enough +10:59 < geertu> AFAIK EORI is for the person who performs customs handling, i.e. the shipping company at the receiving end. +10:59 < morimoto> But I'm happy if I can get your EORI number next time +10:59 < geertu> I don't have one, and according to the Belgian government website, I only need if I want to do customs handling myself. +11:00 < morimoto> The reason why simon need EORI is his VAT number was not yet registered (?) +11:01 < horms> no +11:01 < horms> the reason is a mystery +11:01 < horms> I have a VAT number, which I supplied +11:01 < horms> but I was told I also need an EORI number +11:01 < horms> I asked, "really?". The answer was yet. +11:01 < geertu> It can take a while for VAT numbers to appear in all databases... +11:01 < horms> I asked, "really?". The answer was yes. +11:02 < horms> right, that seems like the most likely explanation +11:02 < horms> the magic web site now says my eori number is valid +11:02 < horms> which is new +11:02 < horms> so perhaps that is enough +11:02 < horms> I am trying to confirm that +11:03 < morimoto> horms: my email which from shipping guys said +11:03 < morimoto> you didn't have "VAT deferment license", but if you have EORI you can receive +11:03 < horms> ok +11:04 < morimoto> Hmm.. mystery +11:04 < morimoto> neg: sorry for interrupt your report +11:05 < neg> morimoto: np, I did not have much to repoert anyhow and feel I got that out :-) +11:06 < morimoto> your one will be forwarded from magnus +11:06 < geertu> Thanks Niklas. +11:07 < geertu> Finally, Khiem. +11:07 < khiemnguyen> A) Nothing yet. +11:07 < khiemnguyen> B) Try to catch the kernel v4.9 for CPUFreq. +11:07 < khiemnguyen> I wonder how much time is remained, 2 weeks ? +11:07 < khiemnguyen> C) +11:08 < khiemnguyen> Some additional work are assigned. +11:08 < khiemnguyen> I'm struggling to find time for upstream work. +11:08 < khiemnguyen> That's all for now. +11:09 < khiemnguyen> Please advice how much time is remained :) +11:09 < geertu> Less than two weeks. +11:09 < geertu> One week for changes to the dts(i) +11:10 < khiemnguyen> geertu: I see. Let's me try to push the patches this week or early next week. It's my last chance, I think. +11:10 < khiemnguyen> s/Let's/Let +11:14 < horms> good plan +11:15 < geertu> Yep. +11:15 < geertu> Thanks Khiem! +11:15 < geertu> Topic 2. r8a7792/Wheat board is being/has been added to mainline +11:15 < geertu> I guess the recurring issue is board documentation? +11:15 < geertu> and board access +11:17 < geertu> horms: Anything particular you wanted to discuss? +11:17 < horms> we have the boot size issue, but perhaps that is best discussed on the periperi ml +11:17 < geertu> I mean about r8a7792/wheat +11:18 < horms> no, not that i can think of +11:18 < geertu> Topic 3. r8a7795/H3ULCB board is pending: Cogent seems to have prioritised +11:18 < horms> documentation is always nice :) +11:18 < geertu> Topic 3. r8a7795/H3ULCB board is pending: Cogent seems to have prioritised Wheat +11:19 < horms> I guess thats their call +11:19 < horms> they were on my case to move h3ulcb +11:19 < horms> but about the same time that I got the green light from Renesas they moved onto something else +11:20 < horms> so i guess its not going to appear in v4.9 +11:20 < morimoto> I think I sent ulcb info to EuroPeri ? +11:20 < morimoto> I think we can have few ulcb board 9/E. +11:21 < geertu> morimoto: Yes, I got the docs, thanks for that! +11:21 < morimoto> geertu: np +11:21 < morimoto> I will ask to Magnus for remove access. +11:21 < morimoto> s/remove/remote/ +11:21 < geertu> Magnus said a while ago he already has a Blanche. +11:22 < geertu> And I believe he also has an RSK? +11:22 < morimoto> geertu: I don't know about his RSK +11:23 < shimoda> horms: about h3ulcb, if renesas japan needs to merge it into v4.9, what we should do? +11:24 < horms> shimoda: ok, if its important I think we have two options +11:24 < horms> 1) rework the patches a bit ourselves +11:24 < horms> 2) put some pressure on cogent, perhaps via artemi +11:24 < horms> I have tried to encourage Sergei to do something but he is quite resistant to encouragement from me +11:25 < horms> option 1 implies someone has access to a board for testing +11:25 < shimoda> horms: ok. goda-san consider about this board to upstream. so, 3) goda-san (and munakata-san?) put some pressure on cogent too :) +11:26 < morimoto> From munakata-san can be nice pressure :) +11:26 < horms> Yes, that is what I meant by 2) +11:26 < horms> I'm sure Cogent can do something if pressure is applied in the right place +11:27 < horms> to be clear all I would like is for the patches to be split up (and of course re-tested) +11:27 < horms> And I would like to merge the patches by next Wednesday. So probably they need to be posted a bit earlier than that to allow some review etc... +11:28 < shimoda> horms: i got it. i prefer 2). so I will forward this infor to goda-san. +11:28 < horms> ok. let me know if you need any support. +11:29 < shimoda> horms: ok. thanks! +11:29 < geertu> Topic 4. Renesas would like to know the kernel size issue on upstream. +11:29 < geertu> You think this is best suited for the ML? +11:31 < horms> We can cha here if you prefer +11:31 < horms> But really I think we need a way to allow the mainline defconfig to keep working so we can test it +11:31 < horms> That can be without inird if necessary, so we still have some space to play with +11:32 < horms> But probably it will keep growing +11:32 < horms> And unless other vendors, who actually use mainline, have a 16MB limit we will be carring a very heavy burden to try to keep the defconfig below that limit. e.g. using modules +11:32 < horms> So I would like to know if it is practical to boot the kernel at a different location +11:33 < geertu> If it's just about testing arm64 defconfig, to catch issues caused by the presence of foreign drivers, you can always boot using a smaller kernel, and kexec into the large one +11:33 < horms> hmmm, good point +11:34 < horms> but really is it too much to ask for things to work out of the box? +11:34 < horms> perhaps it is +11:34 < horms> kexec may be a good work-around +11:34 < horms> as i understand things the limitatino we have is +11:34 < horms> that the kernel is unpacked at 0x4800 0000 +11:35 < horms> and uboot us at 0x4900 0000 +11:35 < horms> so if the kernel is too big it overwrites u-boot +11:35 < horms> presumably that is not a problem when kexecing as uboot is long out of the picture +11:35 < horms> is that correct? +11:36 < geertu> Yes +11:36 < geertu> I've used kexec to boot multi_v7_defconfig on e.g. armadillo +11:36 < horms> Ok, probably Magnus needs to be involved in this discussion. +11:36 < horms> But it may be a good option. +11:37 < geertu> Still, our downstream users will not use arm64 defconfig for products +11:37 < geertu> So providing a renesas64_defconfig somewhere makes sense +11:38 < geertu> A disadvantage is that it needs to be maintained +11:38 < horms> I understand that +11:38 < horms> but yes, i see the downside too +11:38 < horms> and frankly its 1/2 a step away from upstream first +11:38 < horms> Perhaps I am overreacting +11:39 < geertu> Well, upstream first usually does't apply to defconfigs +11:39 < geertu> Esp. not for embedded. +11:40 < horms> ok, I'll just say that I think its nicer if it does. But perhaps its not practical if arm64 only has one defconfig. And I need to just move on. +11:40 < horms> Certainly I think kexec could be a solution for testing the defconfig +11:40 < horms> And we could consider maintaining renesas64_defconfig out of tree +11:41 < horms> e.g. in the renesas tree but not mainline itself +11:41 < horms> shimoda: how do you feel about this? +11:42 < shimoda> horms: renesas64_defconfig is good to me +11:42 < horms> ok, lets raise this with Magnus then +11:43 < shimoda> but about kexec, it is complex to me :) +11:44 < horms> yes, that is the down side +11:44 < horms> and as a bonus booting will take evern longer remotely +11:45 < horms> but I think the gernal idea would be to bake two kernels +11:45 < horms> 1 small one, possibly with an initrd certainly with kexec +11:45 < horms> boot into it, transfer the second image, say using tftp of something tcp based when operating remotely +11:46 < horms> then kexec -l Image --dtb xyz.dtb; kexec -e +11:46 < horms> More moving parts +11:46 < horms> more things to go wrong +11:46 < horms> but probably it could be made to work +11:47 < geertu> For normal development, you can still use the small config +11:47 < horms> for me my normal work is mostly testing mainline defconfig is still working +11:47 < geertu> I usually use a per-board config anyway +11:47 < geertu> But regularly test shmobile_defconfig on koelsch, and arm64 defconfig on salvator-x +11:48 < horms> ok, i take your point +11:48 < geertu> multi_v7_defconfig is just too big to boot on anything these days +11:48 < horms> for actually development work that makes sense +11:48 < horms> i regard that config as being of theoretical use to Arnd rather than practical use to anyone +11:49 < horms> Anyway, I will see about looking into this as part of my existing work on kexec +11:49 < horms> because I need to do something like this for that work anyway +11:49 < geertu> And on arm64 we only have the config for theoretical use ;-) +11:49 < horms> right, sadly I think I will have to agree with you there +11:50 < horms> which would remove my main objection +11:50 < geertu> BTW, do you need the --dtb option of kexec? +11:50 < geertu> root@koelsch:~# cat $(type -p tftp-kexec ) +11:50 < geertu> #!/bin/bash +11:50 < geertu> IMAGE=zImage +11:50 < geertu> set -e +11:50 < geertu> ( echo verbose; echo get $(hostname)/$IMAGE /tmp/$IMAGE ) | tftp ayla +11:50 < geertu> kexec -l /tmp/$IMAGE --append="$(cat /proc/cmdline)" +11:50 < geertu> kexec -e +11:50 < geertu> root@koelsch:~# +11:51 < geertu> That's what I use +11:51 < horms> Ok, good to know that works +11:52 < horms> I'll see if it can be done on arm64 too +11:52 < horms> does your image have the dtb appended? +11:52 < geertu> No +11:52 < horms> if not I guess its extracted from the running kernel somehow +11:52 < geertu> Yes, that's what I thought, too +11:53 < horms> I do see some value to explictly providing a dtb +11:53 < horms> but I'll look into why what you have above works +11:54 < geertu> IIRC, it doesn't work with the kexec binary in Magnus' initrd. +11:54 < geertu> My userland is Debian NFS root +11:54 < horms> me too +11:54 < horms> i'm unsurprise that kexec binary doesn't work +11:54 < horms> it must be ancient by now +11:55 < geertu> I think it's time to conclude +11:56 < geertu> (and unpack the M3-W ;-) +11:56 < morimoto> :) +11:56 < shimoda> good luck! :) +11:57 < horms> enjoy + bye +11:57 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20160831-mm-chatlog b/wiki/Chat_log/20160831-mm-chatlog new file mode 100644 index 0000000..01be483 --- /dev/null +++ b/wiki/Chat_log/20160831-mm-chatlog @@ -0,0 +1,384 @@ +Multimedia-chat-meeting-2016-08-31 + +10:05 < pinchartl> topics for the day +10:05 < pinchartl> 1. Status check for the multimedia tasks +10:06 < dammsan> pinchartl: please connect to me via google chat at some point today so we can briefly talk about some paper stuff? +10:06 < pinchartl> sure +10:06 < pinchartl> does anyone want to add another topic ? +10:07 < dammsan> i have an idea: +10:07 < dammsan> additional task proposals for next quarter +10:08 < dammsan> at least something to start thinking about +10:08 < pinchartl> it's a good time to start thinking about it, yes +10:08 < dammsan> nothing apart from that from my side +10:09 < pinchartl> Topic 1. Status check for the multimedia tasks +10:09 < pinchartl> ---------------------------------------------- +10:09 < pinchartl> in sort -R order +10:09 -!- Irssi: Pasting 5 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +10:09 < pinchartl> - Ulrich +10:09 < pinchartl> - Magnus +10:09 < pinchartl> - Niklas +10:09 < pinchartl> - Kieran +10:09 < pinchartl> - Morimoto-san +10:09 < pinchartl> - Laurent +10:09 < pinchartl> uli___: your turn +10:10 * geertu stops using gose +10:10 < uli___> see the e-mail i sent; i think task statusses are not affected by any stuff i have done since last time +10:10 < uli___> we would have to talk about how to proceed with hdmi out +10:11 < pinchartl> let me copy it here for reference +10:11 < pinchartl> A) Since last time +10:11 < pinchartl> - Refreshed HDMI out series for Gen3 +10:11 < pinchartl> Updated for 4.8-rc2. (See also C.). Some of the larger patches (e.g. bridge API conversion) have been upstreamed and could be dropped. +10:11 < pinchartl> B) Until next time +10:11 < pinchartl> - Gen2 VIN integration +10:11 < pinchartl> C) Problems +10:11 < pinchartl> - HDMI out doesn't work on Morimoto-san's Salvator-X board. +10:12 < pinchartl> The CMA reservation patch that is part of the HDMI out series breaks the kernel. This patch is required, so we'll have to find out why it doesn't work. An issue with firmware 2.8.0 is the prime suspect ATM. +10:12 < pinchartl> - Product register access unresolved +10:12 < pinchartl> The HDMI out series requires access to the product register. How to implement that the right way is part of a discussion ("[PATCH 0/4] ARM: Renesas: R-Car3: Add product register support") that ended without conclusion. +10:12 < uli___> thanks +10:12 < dammsan> i sort of thought we had a plan about PRR +10:12 < dammsan> but that's a topic for core i think +10:12 < geertu> Yes, ES handling +10:12 < pinchartl> regarding the HDMI output series for Gen3, are there patches you think could be upstreamed sooner than latter ? +10:13 < pinchartl> s/latter/later/ +10:13 < uli___> it consists of a lot of bit parts that should not bother anybody if they get merged +10:13 < uli___> the big issues are prr and (i guess) binding the dw-hdmi driver +10:14 < uli___> nobody has commented on the latter yet +10:14 < pinchartl> to ask it differently, are there patches you'd like to fast-track now, or should everything be merged together ? +10:14 < uli___> those things have already been picked up (bridge API etc.) +10:14 < uli___> the rest makes more sense together +10:14 < pinchartl> I agree +10:15 < dammsan> May I ask why the CMA reservation patch is required? +10:15 < pinchartl> what's the plan for the CMA issue ? +10:17 < uli___> without it, the du driver fails to initialize +10:17 < uli___> i get the same result as morimoto-san in that case +10:17 < uli___> (panic) +10:17 < pinchartl> do you know why ? +10:17 < uli___> no +10:18 < dammsan> it is usually possible to increase the default CMA area with other standard methods +10:18 < morimoto> This patch was created by Fukawa-san, and I can ask to him. But he is talking to other guy now +10:18 < dammsan> morimoto: Fukawa-san is adding that patch for the MMP +10:18 < dammsan> see the patch commit message +10:19 < dammsan> it is way of dealing with memory management for the inhouse multimedia package +10:19 < dammsan> it is not the same as what upstream is supposed to do +10:19 < dammsan> just applying it blindly seems a bit short sighted IMO +10:19 < pinchartl> I'll have a look at that +10:20 < dammsan> uli___: what happens if you increase the default CMA size? +10:20 < uli___> haven't tried that. now that i think about it, i had a similar issue on lager where that helped... +10:20 < uli___> i'll check it out +10:20 < pinchartl> the DU driver could fail with the default CMA area, but the kernel should not panic in any case +10:21 < dammsan> yeah, same thing existed on older generation as well +10:21 < dammsan> pinchartl: agree that panic is not supposed to happen +10:21 < morimoto> Mine doesn't *panic*, but DU do nothing. +10:22 < neg> (My M3 carrier just arrived, need to run down and fetch it) +10:23 < dammsan> pinchartl: any idea how much work there is to enable HDMI on M3-W? +10:23 < pinchartl> dammsan: once it works on H3 it should be pretty straightforward +10:24 < pinchartl> (after enabling DU on M3-W of course) +10:24 < dammsan> i wonder if DU on r8a7796 differs from r8a7795 +10:24 < dammsan> the driver development portion for that would be useful to get done sooner than later +10:24 < pinchartl> it differs but not in a way that should cause any issue +10:24 < dammsan> please note that i would like to control the integration order on r8a7796 to coordinate with IPMMU +10:25 < dammsan> but some prototyping w/o IPMMU would be useful for sure +10:26 * neg is back with a big box of 'High Reliabibility Parts of Electronics' +10:26 < geertu> Christmas is early this year... +10:27 < pinchartl> uli___: what's the status of 'VIN HDMI input EDID' ? +10:28 < uli___> i guess hans needs a nudge there, i was asking if the series should be split up into code and DT +10:28 < uli___> i though he was just going to review niklas's patches first +10:29 < pinchartl> please remember to send the description of the test environment to Jinzai by the end of the weekend (September the 4th) +10:29 < uli___> will do +10:30 < pinchartl> thans +10:30 < pinchartl> thanks +10:30 < pinchartl> next, dammsan +10:31 < dammsan> nothing to report here really +10:31 < dammsan> currently poking around with IPMMU and DU, about to test the code from pinchartl =) +10:32 < pinchartl> any issue or blocker ? +10:33 < dammsan> not so far, i suspect some display list code may need more attention +10:33 < dammsan> but i will know for sure later today +10:34 < pinchartl> ok +10:34 < pinchartl> next, neg +10:34 < neg> a) VSP HGT driver almost done, evrything works just some documentation missing. Hans picked up a patch sereis for VIN so one step closer to Gen3 support upstream +10:34 < neg> b) Post HGT driver and onther VIN patch which Hans hopefully will pickup for v4.9 +10:34 < neg> c) HGT test program to emulate HST (RGB->HSV) do not match HW perfectly. No review on VIN GEN3 patches I don't think they will make it to v4.9 :-( +10:35 < pinchartl> regarding HGT +10:36 < pinchartl> I had a look at the RGB to HSV transformation +10:36 < pinchartl> the test application that generate frames is able to compute S and V exactly +10:36 < pinchartl> but for H it differs from the hardware values by 1 at most, in ~8% of the cases +10:37 < pinchartl> you've asked Morimoto-san to check if we can get information about how the hardware performs the transformation +10:37 < morimoto> About your question about RGB <-> HSV, I think I replyed answer. Does it OK for you ? +10:37 < pinchartl> and he replied that the BSP team has no information about it +10:37 < pinchartl> I'm not surprised, as it's a hardware-related question :-) +10:38 < pinchartl> do you think we could get information from the hardware team ? +10:39 < morimoto> The Document issue S vs V is under HW team control now. +10:39 < pinchartl> S and V are fine. it's H that we have trouble with +10:40 < neg> morimoto: yes I understand that precision is lost in RGB->HSV->RGB as the manual states but this is for RGB->HSV which is deterministic. If I use a lookup table for the 8% of values I can not compute the HW is emulated perfectly +10:41 < pinchartl> there's a division by 3 in the equation used to compute H, and I'm pretty sure the hardware approximates that by a multiplication followed by a shift (probably *341/1024 or *683/2048) +10:41 < pinchartl> but even with that we haven't been able to achieve a perfect match +10:41 < neg> so it's the way I calculate RGB->H that is wrong and if possible I would like input on +10:42 < pinchartl> neg: I wouldn't say it's wrong. the issue is that the hardware performs approximations and rounding in a way we don't know +10:44 < geertu> neg: How big are the absolute errors? E.g. can't you just allow -1/+1 differences? +10:44 < pinchartl> geertu: when comparing images, sure, but when computing histograms it can cause an unknown amount of pixels to fall into another bucket +10:45 < neg> geertu: the error is in the range +/- 1 but it's used to generate a histogram with buckets and that error results in a value being counted in the wrong bucket unfortunatly +10:46 < neg> alsa this is only for the test application, so one workaround is to only test it using 1 out of 6 buckets +10:46 < geertu> Can multiple values end up in the same bucket? or is it one-to-one? +10:46 < neg> multiple values can go in the same bucket +10:47 < pinchartl> the histogram generator puts pixels in buckets and reports the number of pixels in each bucket (roughly) +10:47 < neg> there are in total 6 buckets wich can be spread out over a value range of 0-255 +10:48 < geertu> If the test software uses one-to-one buckets, it can calculate upper and lower bounds for each hardware bucket, assuming a max error of -1/+1 +10:48 < pinchartl> geertu: I don't see how that would help +10:49 < pinchartl> a -1/+1 error can cause a pixel to fall in the next bucket +10:49 < geertu> i.e. sum (sw_bucket[first..last]) <= hw_bucket <= sum(sw_bucket[first-1..last+1]) +10:49 < geertu> And the total sum must match +10:49 < pinchartl> in the worst case all pixels could fall in another bucket +10:50 < pinchartl> the purpose of the test is to verify that the driver works correctly. if we have to accept 100% errors, it's quite pointless +10:50 < geertu> Sure, but only due to a -1/+1 difference, right? +10:51 < pinchartl> still +10:51 < pinchartl> we want to catch things like an off-by-one write to registers +10:51 < pinchartl> which would result in pixels falling the another bucket the same way than the H computation error would +10:52 < geertu> In that case you do need to know exactly how the hardware works +10:52 < pinchartl> that's my point, yes +10:52 < pinchartl> anyway, Morimoto-san, if we can get information from the hardware team about how the hardware computes the H value from the R,G,B values, then we'll be able to test the HGT +10:53 < neg> geertu: we know how the HW works for S and V only H still eludes me :-) +10:53 < pinchartl> otherwise we won't be able to catch HGT regressions in the test suite +10:54 < pinchartl> neg: regarding the deadlines +10:54 < pinchartl> you mentioned that tests should be done tomorrow +10:54 < pinchartl> but, first of all, the due date is September the 4th +10:54 < pinchartl> and it's only the description of the test environment that's needed +10:55 < pinchartl> not the full test suite +10:55 < morimoto> OK, I will find HW guy, and will ask. +10:55 < pinchartl> i.e. the list of the test tools +10:55 < morimoto> I can say it will be long term. +10:55 < pinchartl> so that Jinzai can cross-compile them already +10:55 < neg> pinchartl: ohh I thought the entier test suite should be done +10:56 < pinchartl> morimoto: thank you. if we can get the verilog code corresponding to the H computation, I can find out how the hardware works myself ;-) +10:56 < morimoto> pinchartl: OK +10:56 < pinchartl> neg: test scripts can still be modified until the final due date +10:56 < neg> but if they need to compile the tools now this still needs to be done since this is in the gen-image test tool of vsp-tests +10:57 < pinchartl> they can recompile the test tools when performing tests +10:57 < neg> ahh great +10:57 < pinchartl> what they want to avoid is running into cross-compilation issues at the last minute +10:57 < pinchartl> a git pull && make, if there's no additional dependency, is fine +10:58 < neg> I take it from this discussion that it's better for me to submit a vsp-tests that only uses 1 bucket over bundeling the 54M lookup table and use all 6 buckets? Atlest untill we figure out how the HW works +10:59 < pinchartl> yes, please +10:59 < neg> good +11:00 < pinchartl> kbingham: you're next +11:00 < neg> About VIN Gen3, please find time to review it :-) +11:00 < kbingham> VSP-Partitioning Status +11:00 < kbingham> Initial prototype for partition algorithm implemented, work in progress to debug some issues, and get some real testing going. +11:00 < kbingham> Ongoing Plan: +11:00 < kbingham> After a little bit of catch up from being on holiday, my plan is to work on progressing the VSP partitioning, and get some viable tests going. Then of course solve all the bugs that will inevitably pop up. +11:02 < kbingham> If you need me to look at FDP1 stuff anytime - let me know, as I'll focus on VSP for the moment. +11:02 < pinchartl> thanks +11:02 < pinchartl> let's focus on the VSP, yes +11:02 < pinchartl> I'll post my current version of the FDP patches +11:03 < pinchartl> no issue or blocker ? +11:04 < morimoto> pinchartl: could you get M3 board ? and forwarded it to kbingham ? I would like to know +11:04 < kbingham> none at the moment - as I've not got very far yet with being back. Various accountant things and email catch up took up most of yesterday. but I can actually boot a board today :D +11:05 < pinchartl> morimoto: not yet, it's currently in a plane from Tokyo to Helsinki according to the shipment tracking page. it should land in the afternoon +11:05 < morimoto> Ahh, OK. Thank you +11:06 < pinchartl> morimoto: your turn :-) +11:06 < morimoto> OK +11:06 < morimoto> RSND,v4.10,public,morimoto,DT bindings for graph sound +11:06 < morimoto> +11:06 < morimoto> this is on going. it need many steps. +11:07 < morimoto> but it have small steps now. +11:07 < morimoto> RSND,v4.10,public,morimoto,dw-hdmi-i2s-audio prototype on Gen3 +11:07 < morimoto> I posted this patch to ML, and I think it is OK +11:07 < morimoto> but maintainer had summer vacation, and it seems forgot about this +11:07 < morimoto> RSND,v4.10,prototype,morimoto,HDMI SSI prototype on Gen3 +11:08 < morimoto> This works in my local envilonment on old kernel. +11:08 < morimoto> It doesn't work on latest geert's branch, because of above HDMI out issue. +11:08 < morimoto> HDMI sound is based on HDMI video +11:09 < morimoto> RSND,v4.10,plan,morimoto,HDMI sound Upstream support without hotplug on Gen2 +11:09 < morimoto> RSND,2016-09-30,plan,morimoto,Hotplug support upstream on Gen3 +11:09 < morimoto> Is is big topic +11:09 < morimoto> ALSA SoC framework should be cleanup/update +11:09 < morimoto> This is related to unbind issue too +11:10 < morimoto> I posted this topic to ML, and we had discussion +11:10 < morimoto> And I posted cleanup patches. +11:10 < morimoto> 1 series was accepted. but other was NACK:ed by Lars +11:11 < morimoto> I think I and Lars and maintainer (= Mark) want to talk F2F (?) +11:11 < morimoto> EOT +11:11 < pinchartl> thank you +11:11 < pinchartl> regarding the HDMI output issue with the latest renesas drivers tree +11:12 < pinchartl> you mentioned in your e-mail that you would like to know the plan +11:12 < morimoto> Yes, is this Ulrich's task ? +11:12 < pinchartl> we've discussed this earlier, Ulrich will check if we can just increase the default CMA area size without requiring the DT patch +11:12 < pinchartl> uli___: is my understanding correct ? +11:12 < uli___> yes +11:13 < pinchartl> thanks +11:13 < morimoto> OK, nice. I thought it (= prototype) was his task, but after that it is Laurent's task. +11:13 < morimoto> OK, uli___ has this handle +11:15 < morimoto> no more comment form me +11:15 < morimoto> s/form/from/ +11:15 < pinchartl> morimoto: will you attend ELCE ? +11:16 < morimoto> Yes +11:16 < morimoto> Lars has presentation about this topics +11:16 < pinchartl> it would be good to schedule a face to face discussion with Lars +11:16 < morimoto> I think so +11:16 < pinchartl> I'm not sure if his presentation will address this specifically +11:17 < pinchartl> I think he will talk, among other things, about the current mess with the Intel audio hardware +11:17 < pinchartl> (i.e. no Linux support for audio on latest Intel platforms) +11:18 < morimoto> interesting +11:18 < pinchartl> could you contact Lars to schedule a meeting ? +11:19 < morimoto> no. I think I can find him on ECLE ? or should I ask to him ? +11:19 < pinchartl> please ask him beforehand, everybody is busy during ELCE, and this is important enough to make sure we can allocate enough time for the discussion +11:20 < morimoto> OK, will do +11:20 < pinchartl> thank you +11:21 < pinchartl> next, me +11:21 < pinchartl> since last meeting +11:21 < pinchartl> vacation :-) +11:22 < pinchartl> I've submitted IPMMU + DU integration patches +11:22 < pinchartl> they have been tested on Gen2 only due to the IPMMU being broken on H3 +11:22 < dammsan> pinchartl: on ES1 =) +11:22 < pinchartl> the patches include DT integration and changes to the FCP, VSP and DU drivers to make it all work +11:22 < pinchartl> dammsan: yes, ES1.0 :-) +11:23 < pinchartl> I've also reworked Kieran's FDP driver and will post a v2 +11:23 < dammsan> pinchartl: it seems the integration stuff is somewhat experimental, is that correct? +11:23 < pinchartl> which fixes several issues but breaks overalll operation :-) +11:23 < pinchartl> yes, it's experimental +11:23 < dammsan> cool, thanks +11:23 < pinchartl> the DT part should be quite stable +11:24 < pinchartl> changes to the FCP, VSP and DU drivers is experimental +11:24 < pinchartl> I'd really appreciate a careful review +11:24 < pinchartl> not so much for the implementation itself, but for the APIs between the drivers +11:24 < dammsan> right +11:26 < pinchartl> for the next two weeks +11:26 < dammsan> the DT part does not seem to change so much =) +11:26 < pinchartl> no, the DT part is quite stable I think +11:26 < dammsan> hehe +11:26 < pinchartl> there's no new Dt binding +11:26 < dammsan> that's a good thing +11:27 < dammsan> but we do want a stable implementation too =) +11:27 < dammsan> but it begins with a review +11:27 < pinchartl> definitely :-) +11:27 < pinchartl> for the next two weeks +11:27 < pinchartl> - Continue working on the FDP driver to get it merged upstream +11:27 < pinchartl> - VSP image partitioning support +11:27 < pinchartl> - DU and VSP integration on H3 +11:27 < pinchartl> - VIN and HDMI output patch review +11:28 < pinchartl> blockers and issues +11:29 < pinchartl> Geert pointed out, when reviewing the DU and VSP DT integration patches, that the latest Gen3 errata removed VSPD3 +11:29 < pinchartl> the DU3 channel is now fed by VSPD0, as is the DU0 channel +11:30 < dammsan> this is true for both H3 and M3-W? +11:30 < pinchartl> no, only for H3, M3-W has 3 DU channels only (DU0 to DU2) +11:30 < pinchartl> not only does this not match my experience with H3 ES1.0 on which I've used VSPD3 with DU3 successfully +11:30 < pinchartl> but it would also completely break the whole VSP + DU software model +11:31 < pinchartl> I think I've politely mentioned "brain-dead design" when replying to the e-mail +11:31 < pinchartl> I'd like to get more information about this +11:31 < dammsan> that's very polite of you =) +11:31 < pinchartl> and how it's supposed to work +11:33 < dammsan> there may be some sort of reason behind all this +11:33 < pinchartl> morimoto: do you think I could bother you to get more information about this ? +11:33 < dammsan> if it makes sense or not is a different question +11:34 < pinchartl> first of all, whether the errata is correct or not +11:34 < pinchartl> whether it applies to H3 ES1.1 only or ES1.0 too +11:34 < pinchartl> and how DU0 and DU3 are supposed to be operated if they use the same VSPD +11:35 < dammsan> right +11:35 < morimoto> Can you email it me ? I can ask to HW guys. +11:36 < pinchartl> sure, thanks +11:36 < pinchartl> I'll explain that in the meeting report +11:36 < pinchartl> would you like a separate e-mail ? +11:36 < morimoto> meeting report is OK +11:36 < morimoto> Is this for HW team ? or BSP team ? +11:36 < pinchartl> thank you +11:36 < pinchartl> that's all for me +11:36 < pinchartl> Topic 2. Additional tasks for Q3 2016 +11:36 < pinchartl> ------------------------------------- +11:37 < pinchartl> we need to start thinking about additional tasks +11:37 < pinchartl> obviously specific requests from Renesas should be taken into account +11:37 < pinchartl> but we can also be proactive and propose tasks for areas that we have identified as needing love +11:37 < pinchartl> I would thus like feedback from all of you about this +11:38 < pinchartl> if you already have ideas please mention them now +11:38 < pinchartl> otherwise, please think about it this week and propose them by e-mail +11:38 < pinchartl> and just talk to me on IRC +11:38 < dammsan> M3-W DU prototype +11:39 < dammsan> M3-W VIN prototype +11:39 < pinchartl> I'll double-check the details, but I think we can skip the prototype stage and go directly to an upstream-ready patch series for M3-W DU +11:39 < pinchartl> for VIN I'll let neg check what makes sense +11:40 < neg> Will check and get back to you +11:40 < dammsan> that sounds nice, but perhaps we can do prototype for first batch and upstream for next +11:40 < dammsan> we don't know what kind of issues that may be lurking +11:40 < dammsan> if you can do upstream-ready directly then that's fine too +11:41 < dammsan> we need HDMI video out support too eventually +11:41 < pinchartl> let me get my M3-W board and then I'll check what makes the most sense +11:41 < pinchartl> but in any case an M3-W DU task makes sense +11:41 < pinchartl> yes +11:41 < dammsan> sounds good +11:42 < dammsan> are we ready for a dma_buf zero copy user space test program? +11:42 < dammsan> from vin via vsp to du +11:42 < pinchartl> I think we're ready to start working on that, yes +11:43 < pinchartl> we still haven't addressed cache management +11:43 < dammsan> how about audio test program, for loopback testing of kHz setting and L-R issues +11:44 < dammsan> i think the cache management requirement actually means that they want to improve performance +11:44 < pinchartl> yes +11:44 < dammsan> and they have some sort of proposal +11:44 < dammsan> which may or may not make so much sense +11:44 < dammsan> but we probably need some base line to begin with +11:45 < pinchartl> we need to come up with a proposal to achieve proper performances +11:45 < pinchartl> whether it requires special cache management is more of an implementation detail +11:45 < dammsan> yes exactly +11:46 < dammsan> it depends on what user space does too +11:46 < dammsan> i think it makes sense to cook up a zero copy test app as counter-proposal +11:47 < dammsan> but perhaps i need to listen to their requirement more +11:47 < pinchartl> :-) +11:47 < dammsan> how long time would a zero copy test app take to implement? +11:47 < dammsan> would it be possible in one "slot" of additional tasks? +11:48 < pinchartl> I think so +11:48 < dammsan> in two weeks something should be doable IMO +11:48 < dammsan> so i hope to figure out some additional task for all memebers sometime soon this month +11:49 < dammsan> this for the first slot of next quarter +11:49 < dammsan> the second slot content can be discussed in Berlin +11:49 < dammsan> i hope to fix the first slot content in middle of September +11:50 < pinchartl> sounds good to me. I propose letting everybody think about additional tasks until the end of the week and discussing them early next week +11:50 < dammsan> good idea +11:50 < pinchartl> everybody, please think about what you believe is needed and let me know by the end of the weekend +11:52 < pinchartl> I propose holding the next meeting in two weeks from now +11:52 < pinchartl> 2016-09-14 at 09:00 BST / 10:00 CEST / 11:00 +11:52 < pinchartl> EEST / 17:00 JST +11:53 < neg> time works for me +11:53 < uli___> +1 +11:53 < dammsan> me too +11:54 < dammsan> we should have finalised the first slot of additional tasks by then +11:54 < dammsan> the due for first slot is 11/M and second slot is 12/M +11:54 < dammsan> same pattern as current quarter +11:55 < pinchartl> ELCE and LPC will fall in the first slot +11:55 < pinchartl> who will not attend ELCE ? and who will attend LPC (I will) ? +11:55 < morimoto> LPC is what ? +11:55 < morimoto> +11:56 < pinchartl> Linux Plumbers Conference +11:56 < dammsan> did not consider LPC yet +11:56 < pinchartl> in Santa Fe https://www.linuxplumbersconf.org/2016/ +11:56 < pinchartl> (November 1-4) +11:56 < dammsan> intend to attend ELCE and also Linuxcon +11:56 < pinchartl> it will be collocated with the kernel summit +11:56 < pinchartl> anyone plans to attend the kernel summit by the way ? +11:57 < pinchartl> (I will) +11:57 < morimoto> Kobayashi will attend to LPC from OSD2 :) +11:57 < morimoto> I wil attend ELCE +11:57 < pinchartl> :-) +11:57 < pinchartl> neg: uli___: kbingham: how about you ? +11:57 < uli___> elce only. +11:58 < kbingham> ELCE only here ... +11:58 < neg> ELCE and if there is periperi stuff before LinuxCon I will also attend it +11:58 < morimoto> Oh, we can meet kbingham this time !! +11:58 < kbingham> I haven't booked flights yet - so Ican extend if needed. +11:58 < kbingham> but I'm booked in the Conference hotel. +11:59 < pinchartl> we need to decide whether to have a peripericon in Berlin sooner than later, but that's not a multimedia topic +11:59 < morimoto> I will go to Berlin 10/3 - 10/14 +11:59 < dammsan> i'll also be there those days +12:00 < pinchartl> I currently don't plan on attending LinuxCon but I can change my plans to some extent if needed +12:01 < dammsan> there is a deadline for cheaper conference tickets on 3rd btw +12:01 < morimoto> Maybe we can have MiniPeriCon if needed ? not FullPeriCon +12:01 < pinchartl> that's an option too, yes +12:02 < pinchartl> I think we're done for today +12:02 < pinchartl> I propose adjourning this meeting +12:02 < pinchartl> does anyone second ? +12:02 < neg> I'm happy to go also go 10/3 - 10/14 if there is meeting or stuff to be done (drinking beer is stuff) +12:03 < neg> seconded +12:04 < pinchartl> thank you +12:04 < pinchartl> have a nice day/evening everybody +12:04 < pinchartl> thank you for attending +12:04 < dammsan> thanks, you too +12:04 < morimoto> Thanks. +12:04 < neg> thanks all +12:04 < uli___> thank you diff --git a/wiki/Chat_log/20160901-io-chatlog b/wiki/Chat_log/20160901-io-chatlog new file mode 100644 index 0000000..5623d34 --- /dev/null +++ b/wiki/Chat_log/20160901-io-chatlog @@ -0,0 +1,371 @@ +--- Log opened Thu Sep 01 09:57:26 2016 +09:57 -!- wsa_ [~wsa@dslb-178-008-071-018.178.008.pools.vodafone-ip.de] has joined #periperi-io +09:57 -!- Irssi: #periperi-io: Total of 3 nicks [1 ops, 0 halfops, 0 voices, 2 normal] +09:57 -!- Irssi: Join to #periperi-io was synced in 0 secs +09:58 -!- khiemnguyen_ [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi-io +09:58 -!- neg_ [~neg@unaffiliated/neg] has joined #periperi-io +09:58 < neg_> morning all +09:58 -!- neg_ is now known as neg +09:59 < wsa_> hi! +09:59 <@uli___> hello +09:59 < khiemnguyen_> hello +10:00 < geertu> Hi all +10:00 < wsa_> simon said he has another meeting right now +10:00 < wsa_> let's wait a little for our japanese fellows +10:01 -!- horms [~horms@217.111.208.18] has joined #periperi-io +10:01 -!- morimoto [~user@relprex1.renesas.com] has joined #periperi-io +10:02 < wsa_> hi +10:02 < morimoto> hi +10:02 < horms> wsa_: I am able to attend this meeting after all. But I need to leave at 11 +10:03 < wsa_> horms: great +10:03 < wsa_> so i might need to tweak 'sort -R' a bit +10:03 < horms> sorry for the mix up. my life is crazy-special-busy at the moment +10:03 < horms> I can just go last if it helps +10:03 < horms> (assuming we don't go for too long) +10:04 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi-io +10:04 < wsa_> horms: if you have to leave at 11, i think you should be first? +10:04 < horms> sure +10:05 < wsa_> hi magnus +10:05 < dammsan> hi guys +10:05 < dammsan> i just want to hijack this space and briefly mention about next quarter additional task timing +10:05 < wsa_> ok, let's start then +10:05 -!- shimoda [~shimoda@relprex3.renesas.com] has joined #periperi-io +10:06 < dammsan> let me know when is good for you +10:06 < shimoda> hi, sorry for late joinning +10:06 < wsa_> dammsan: let's start with that, now all people are here (simon has to leave at 11) +10:07 < wsa_> shimoda: hi, no problem +10:07 < wsa_> and then simon +10:07 < wsa_> and then sort -R +10:07 < dammsan> ok thanks +10:08 < dammsan> the upcoming quarter schedule is going to resemble this one +10:08 < dammsan> however we are going to be more firm when creating the additional tasks +10:08 < dammsan> this to make the due dates follow same pattern for everyone +10:08 < dammsan> so, the due dates will be 11/M for first batch and 12/M for the second batch +10:09 < dammsan> the first batch needs to be decided in the middle of this month at 9/M +10:09 < dammsan> while the second batch can be decided after meeting f2f in berlin at 10/M +10:10 < dammsan> i would like the mighty group leader to come with a proposal for the first batch +10:10 < dammsan> please discuss among yourselves =) +10:10 < wsa_> base task assignments are also like this quarter? +10:10 < dammsan> yep +10:11 < dammsan> some things like invoice frequency might change +10:11 < horms> will there be any other "firmness" adjustments other than aligning the dates as you describe above? +10:11 < dammsan> but it should be about the same +10:11 < dammsan> good question +10:11 < dammsan> there is no plan to implement anything special for next quarter +10:12 < horms> ok. +10:12 < dammsan> we may however refuse payment if some particular task is not finished +10:12 < horms> Are tests etc... due with the reports at the dates described above: there was some talk of chaning that +10:12 < dammsan> not sure what that was +10:12 < horms> ok, in that case, probably not +10:12 < horms> thanks for answering my questions +10:13 < dammsan> maybe we can go through those ideas in berlin? +10:13 < dammsan> and work to improve first quarter next year? +10:13 < horms> ok, berlin is going ahead? I am at best confused about that plan +10:13 < dammsan> we are running late for the upcoming quarter i think +10:13 < dammsan> i am also confuse +10:13 < horms> time is always against us :^) +10:13 < dammsan> d +10:13 < horms> ok +10:13 < dammsan> but both morimoto-san and i will be there +10:14 < dammsan> in between the conferences +10:14 < dammsan> i hope we can arrange something +10:14 < horms> i will try to be there: as I mentinoed I have visa fun. But I'd say its about 80% that it will be ok +10:14 < wsa_> are you both there for LinuxCon, too? Or just ELC-E? +10:14 < wsa_> both = Magnus & Morimoto +10:14 < dammsan> we will be on both conferences +10:14 < wsa_> cool +10:14 < dammsan> both = LC and ELC =) +10:15 < dammsan> before handing over +10:15 < dammsan> i'd just like to clarify one pattern of handling failure to deliver when it comes to additional tasks +10:15 < dammsan> in case a certain feature is lagging behind +10:16 < dammsan> or say it does not implement all the features described in the task description +10:16 < dammsan> then we may softly refuse to pay, and instead ask to schedule a new task +10:16 < dammsan> the new task should cover the time spent plus new time needed to complete the task +10:17 < dammsan> so payment will be delayed +10:18 < dammsan> to avoid such situation please work to come up with accurate time estimates =) +10:18 < dammsan> if you have any questions please let me know +10:18 < wsa_> how do I (as a group leader) if that happened? from the developer? +10:18 < dammsan> otherwise we can deal with it when it happens +10:19 < dammsan> yeah, i believe the deverloper is going to tell you about the slip +10:19 < dammsan> so you can adjust your TODO list +10:20 < wsa_> because I don't know what has been reported to you +10:20 < dammsan> and then a new-but-similar-and-longer additional task will come up +10:21 < wsa_> i see +10:21 < dammsan> when sending reports and invoices you will get feedback if something needs more work +10:21 < dammsan> that's how the individual engineer notices this +10:22 < wsa_> ok +10:22 < dammsan> does it make sense? +10:23 < wsa_> let's find out :) +10:23 < dammsan> yes! +10:23 < dammsan> thanks for your efforts +10:23 < dammsan> i'll leave you to the meeting now =) +10:24 < dammsan> geertu: yes +10:24 < wsa_> thanks magnus! +10:24 < dammsan> i recommend you to draw and think about it +10:24 < dammsan> thanks guys +10:25 < dammsan> lets talk more and clarify in berlin +10:25 < dammsan> wsa_: can we chat next week about the new tasks for slot 1? +10:25 < wsa_> dammsan: sure +10:25 < dammsan> please get back to me over email +10:25 < wsa_> will do +10:25 < dammsan> i wish you a nice continued day and evening =) +10:25 < dammsan> bye bye +10:25 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has quit Remote host closed the connection +10:26 < wsa_> off he goes +10:26 < wsa_> simon, your turn now +10:26 < horms> a) what have I worked on since last time +10:26 < horms> * SDR104 +10:26 < horms> - Addressed Ulf's review of v4 +10:26 < horms> - Enabled H3 in v5 +10:26 < horms> b) what will I work on until next time +10:26 < horms> * Work on merge of above +10:26 < horms> - Need to add code to used saved tap values as per Ulf's request: +10:26 < horms> but I am unsure how to exercise it +10:26 < horms> * Extend SDR104 coverage to other boards +10:26 < horms> * Follow up on timeout problem on H2 reported by Magnus +10:26 < horms> * Update test wiki patge as suggested by Magnus +10:26 < horms> - Test 512Mb rather than 64Mb transfers +10:26 < horms> - Include CID info of cards tested +10:26 < horms> - Make present control data more clearly +10:26 < horms> c) I have the following problems (or not) +10:26 < horms> * SDR104 timeout reported by Magnus on H2 +10:27 < horms> * susspend resume seems unreliable: +10:27 < horms> - need to investigate +10:27 < horms> - may not be related to SDR104 work +10:27 < horms> -- end prepared statement -- +10:27 < wsa_> what card did Magnus have doing the timeouts? +10:28 < horms> I am confirming that +10:28 < khiemnguyen_> horms: susspend resume seems unreliable <--- what is the problem ? +10:28 < wsa_> he didn't write his test results publicly, did he? +10:28 < horms> khiemnguyen_: sometimes I get an error (-84) from the mmc subsystem on resume +10:29 < horms> my test results are public +10:29 < horms> magnus's result was in a private email: he reported sdr104 is not working on h3 due to timeouts +10:29 < wsa_> and as I wrote a few minutes ago, ejecting a SDR104 card on H3 stall the interface +10:29 < horms> It did work when I tested it in my environment. I will re-test +10:30 < horms> ok, how does a stall manifiest? +10:31 < wsa_> if i insert a new card, nothing happens +10:31 < horms> ok +10:31 < wsa_> not even card detection triggers +10:31 < horms> that is a bit hard for me to test :( +10:32 < horms> With regards to Ulf's suspsend/resume rquest +10:32 < horms> I do not undertand how to exersise using saved tap values +10:32 < horms> as the condition he suggests for using them is always false on resume +10:32 < wsa_> ask him? +10:32 < khiemnguyen_> horms: before your new patches for SDR104, did you see same phenomenon ? +10:33 < horms> khiemnguyen_: its hard to say because it doesn't always occur +10:33 < horms> no I haven't observed it +10:33 < horms> but I'm not sure that means anything +10:33 < wsa_> suspend/resume issues might be a seperate task? +10:34 < khiemnguyen_> -84 = EILSEQ error, illegal byte sequence. +10:34 < wsa_> if not caused by a SDR104 regression +10:36 < horms> that is my feeling +10:36 < horms> I will try harder to reproduce the problem in a way that we can see where the cause is: or at least if it is in SDR104 or not +10:37 < wsa_> i wonder if you should focus on the timeout problems? +10:38 < wsa_> maybe we can ask someone (niklas?) to research if the problem exists with/without SDR104 patches? +10:38 < horms> can do if that is your recommendation +10:38 < horms> I would be very happy for someone else to look into that problem +10:38 < horms> I am observing it on H3 +10:39 < wsa_> neg: have any free time for a base task for IO? +10:39 < neg> not for this Q +10:39 < wsa_> :( +10:40 < wsa_> uli___: ? +10:40 <@uli___> not if it's urgent. :) around end of the month? +10:40 < neg> but next Q is just around the corner, so after the 15/9 I have time +10:40 < wsa_> ok +10:41 < wsa_> I'll think about it +10:41 < wsa_> for now, i think the priority should be the timeouts +10:41 < horms> ok +10:41 < horms> but for now i can't reproduce the problem +10:42 < wsa_> i mean this is even in the header of your task description +10:43 < wsa_> try some more cards? +10:44 < horms> ok, i feel like the temmprature is turning up on me here +10:44 < horms> I want to clarify that I had some test cases where timeouts where a big problem. +10:44 < horms> And I worked to resolve those. +10:44 < horms> Which is the case. +10:44 < horms> This morning I found that Magnus has found a new case which I will investigate. +10:44 < wsa_> uli___: did you try SDR104 with the DMA bottleneck task? +10:45 <@uli___> i checked the performance, but that is about as far as i got +10:45 < wsa_> horms: don't want to heat up, really +10:45 <@uli___> i get some 51 mb/s +10:45 <@uli___> with sandisk ultra 32gb +10:45 < wsa_> uli___: so SDR104 worked for you +10:45 <@uli___> yes +10:46 < wsa_> horms: just wanted to explain why I choose "timeout" over "suspend/resume" as prioritized +10:47 < wsa_> uli___: good +10:47 < horms> wsa_: ok, understood +10:48 < horms> I think i may know which card magnus used: SDSDQXP-032G-G46A +10:48 < horms> this is not a card I have tested +10:48 < horms> I will try to confirm that is the card and test it +10:49 < wsa_> great +10:49 < wsa_> sorry about my misleading communication before +10:50 < wsa_> let's move on, shall we? +10:50 < wsa_> morimoto: you are next +10:51 < wsa_> horms: and thanks for the work! +10:53 < wsa_> am I lagging? +10:54 < horms> wsa_: sorry about this unexpected developmen with sdr104 +10:54 <@uli___> [CTCP] Received CTCP-PING reply from wsa_: 1 second. +10:55 < wsa_> okay, until morimoto reacts... +10:55 < wsa_> khiemnguyen_: can you go next +10:55 < khiemnguyen_> ok +10:56 < khiemnguyen_> a) nothing yet. +10:56 < khiemnguyen_> b) try to catch v4.9 for R-Car Gen3 Thermal +10:56 < khiemnguyen_> I will push the updated patches within today. +10:56 < khiemnguyen_> It seems I still have this week and next week. It's my last chance. +10:57 < khiemnguyen_> c) I have been assigned some additional tasks. +10:57 < khiemnguyen_> Now, I'm struggling to find time for upstream work +10:57 < khiemnguyen_> September will be easier for me. I try to catch up now. +10:57 < khiemnguyen_> That's all for my current status. +10:58 < wsa_> are you still waiting for data for the thermal driver? +10:58 < morimoto> wsa_: sorry I was busy. +10:58 * horms drops off +10:58 -!- Netsplit *.net <-> *.split quits: shimoda +10:58 < khiemnguyen_> I think it's enough for 1st version of Gen3 thermal driver. +10:59 <@uli___> horms: bye +10:59 -!- Netsplit over, joins: shimoda +11:00 < wsa_> good +11:00 < wsa_> will you be in berlin for ELCE? +11:01 < khiemnguyen_> nope. I have not planned for this. So, my manager could not accept it. +11:01 < khiemnguyen_> I will plan for next year. +11:01 < wsa_> ok +11:02 < wsa_> would be really great to have the driver in 4.9 +11:02 < wsa_> good luck! :) +11:03 < wsa_> thanks! +11:03 -!- horms [~horms@217.111.208.18] has quit Ping timeout: 252 seconds +11:03 < wsa_> morimoto: your turn now +11:03 < khiemnguyen_> yeah, will try my best with Morimoto-san support :) +11:03 < morimoto> OK, +11:03 < morimoto> But I have no I/O task :) +11:03 < morimoto> I shipped M3 board for you guys +11:04 < wsa_> and it looks like you support khiem :) +11:04 < wsa_> i will test my M3 today +11:04 < shimoda> oh, morimoto-san is calling with someone now +11:05 < wsa_> ok +11:05 < wsa_> neg: your turn +11:05 < morimoto> I'm back, sorry +11:05 < morimoto> that's it from me. nothing for report +11:06 < neg> a) Found the problem with OHCI-PCI + CONFIG_DMA_CMA=y +11:06 < neg> b) Noting, no IO tasks for me +11:06 < neg> c) None +11:06 < neg> geertu: do you feel happy about the solution to OHCI-PCI + CONFIG_DMA_CMA=y ? +11:06 < wsa_> i think that should be: +11:07 < wsa_> c) not enough base time task for IO ;) +11:07 < neg> there is never enough time :-) +11:07 < geertu> neg: Yes. Still have to update my U-Boot. Don't want to risk bricking my Koelsch now (add. task due soon :-) +11:08 < neg> should I send a patch enabiling CMA in shmobilde_defconfig? +11:09 < geertu> neg: I'll happily reassign that task (from Laurent) to you ;-) +11:09 < neg> ohh I do not want to steal his tasks :-) +11:09 < geertu> Yes, we need CMA for graphics +11:11 < wsa_> play junkenpon for this task :D +11:11 < wsa_> okay, i am next +11:12 < geertu> "Google says: Did you mean: jankenpon?" +11:12 < wsa_> yes +11:12 < wsa_> A) since last time: +11:12 < wsa_> * fixed IP core switcher issue +11:12 < wsa_> * fixed flaw in DA9xxx interrupt storm handling on Gen2 +11:12 < wsa_> * re-animated pretimeout topic upstream and reviewed new patches +11:12 < wsa_> * fixed SDHI regression on r8a73a4 +11:12 < wsa_> * fixed DMA-API warning in Renesas i2c drivers (thanks Geert for the pointer!) +11:12 < wsa_> B) until next time: +11:12 < wsa_> * enable 8 bit eMMC mode on Gen3 +11:12 < wsa_> * test new SDR104 series +11:12 < wsa_> C) problems I have: +11:12 < wsa_> * getting results of tasks +11:13 < wsa_> with C) I mean +11:13 < wsa_> i got to know about magnus sdr104 problems from simon +11:13 < wsa_> that should have been public +11:14 < wsa_> or at least me cc'ed, I'd think +11:14 < wsa_> or I just got to know here that uli___ did test DMA with SDR104 already +11:15 < wsa_> I'd like to know such things asap +11:15 < wsa_> because this affects planning additional tasks etc +11:15 < wsa_> need to communicate this better +11:15 < wsa_> first step just taken :) +11:15 < geertu> If you test something, either provide a Tested-by on success, or a (public, if not confidential) email on failure +11:16 < geertu> There's still value in providing a Tested-By after a patch was applied (googleable mailing list archive) +11:16 < wsa_> yup +11:17 < wsa_> that's all from my side +11:17 < wsa_> shimoda: you are next +11:17 < shimoda> a) what have I worked on since last time +11:17 < shimoda> - investigate USB EHCI + IPMMU issue with hardware guy. +11:17 < shimoda> - merged my patch about avoiding skb_reserved() in u_ether for USB-DMAC. +11:17 < shimoda> b) what will I work on until next time +11:17 < shimoda> - continue to investigate USB EHCI + IPMMU issue +11:17 < shimoda> c) I have the following problems (or not) +11:17 < shimoda> - about USB EHCI + IPMMU issue +11:17 < shimoda> EOF +11:17 < shimoda> s/EOF/EOT/ +11:20 < wsa_> so could the HW guy say if it also could be a HW issue? +11:20 < wsa_> or is it definately a software issue? +11:20 < wsa_> or are you still investigating that? +11:20 < wsa_> :) +11:21 < shimoda> HW guy didn't say this is a HW issue because non-IPPMU environment doesn't have any issue +11:21 < shimoda> so I should investigate this more +11:24 < wsa_> ok +11:24 < wsa_> good luck! +11:24 < wsa_> nasty one +11:24 < wsa_> nasty issue i mean +11:24 < wsa_> thank you! +11:24 < wsa_> uli___: your turn please +11:25 <@uli___> a) +11:25 <@uli___> sdr 104 performance: see above +11:25 <@uli___> sd over msiof: see below, after c) :) +11:25 < shimoda> wsa_: i think so. and thank you! +11:25 <@uli___> b) i2c integration for m3-w (need that for my core task) +11:25 <@uli___> c) none +11:25 <@uli___> so about msiof: +11:26 <@uli___> i was going to check if geertu's invalid clock patch fixes anything +11:26 <@uli___> so i recreated the test setup that did not work before +11:26 <@uli___> same kernel, same config, same DT +11:26 <@uli___> same board, same firmware +11:26 <@uli___> same connectors with the same wires soldered to the same pins +11:26 <@uli___> i turn it on, and it works +11:26 <@uli___> consistently +11:26 <@uli___> without explanation or apology +11:26 <@uli___> mind that before +11:27 <@uli___> it did not work consistently with msiof, but it did work consistently with gpio +11:27 <@uli___> now it always works for both +11:27 <@uli___> no idea +11:27 <@uli___> i'll just remove the paragraph on elinux that says it fails, and call it a day :) +11:27 <@uli___> end of story +11:27 < geertu> Great to hear it works! +11:28 < wsa_> so, it can now be marked as complete, cool +11:28 < wsa_> when did you find that out? +11:28 <@uli___> yesterday +11:28 < wsa_> heh +11:29 < wsa_> good, both tasks cleared, thanks! +11:29 < wsa_> geertu: last but not least +11:30 < geertu> A) Nothing +11:30 < geertu> B) SPI slave prototype +11:30 < geertu> C) Visteon reported a difference in behavior between hardware-assisted flow control and GPIO flow control. This may either be due to a bug in the sh-sci driver, or a bug in the serial core, or perhaps both. To be investigated... Cfr. the thread "[PATCH] sh-sci: fix transition from noflow to HW flow control". +11:31 < wsa_> i made a new task out of the last one +11:31 < geertu> OK +11:31 < wsa_> SCIF,?,noplan,?,difference in behavior between hardware-assisted flow control and GPIO flow control +11:32 < geertu> Thx! +11:33 < wsa_> thanks geert, looking forward to the spi slave implementation +11:33 < wsa_> any other news? +11:33 < geertu> Not from my side +11:34 < wsa_> then, thank you guys! +11:35 < geertu> thx & bye +11:35 < shimoda> thank you! +11:35 < neg> thanks all +11:35 < wsa_> have a great rest of the week! +11:35 < morimoto> wsa_: I remembered that I'm asking SDHI datasheet to HW guys, It has 1) finding HW guys, 2) export paper work +11:35 < khiemnguyen_> thx. bye. :) +11:35 < morimoto> So, it will takes more time +11:35 <@uli___> bye +11:35 < morimoto> sorry for late +11:40 -!- shimoda [~shimoda@relprex3.renesas.com] has quit Quit: WeeChat 0.4.2 +11:43 < wsa_> morimoto: it is not super urgent +11:43 < wsa_> morimoto: we solved the current issue +11:43 < wsa_> morimoto: but we never know if something else comes up +11:44 < morimoto> Yes, anyway I will continue to asking +11:44 < wsa_> thank you! +11:44 < morimoto> np +11:45 < wsa_> I am happy to invite my paper-work-hero for a curry-sausage in Berlin :D +11:47 < morimoto> Hehehe :) +11:48 < morimoto> I think he will be happy for it :) +11:48 < morimoto> I will go there 10/3 - 10/14 +11:54 < wsa_> cool +11:56 < wsa_> let's explore Berlin :D +11:56 < wsa_> now gotta go +11:56 < wsa_> cya! +--- Log closed Thu Sep 01 11:56:42 2016 diff --git a/wiki/Chat_log/20160913-core-chatlog b/wiki/Chat_log/20160913-core-chatlog new file mode 100644 index 0000000..b33fee4 --- /dev/null +++ b/wiki/Chat_log/20160913-core-chatlog @@ -0,0 +1,368 @@ +Core-chat-meeting-2016-09-13 + +10:03 < geertu> Welcome to the 25th edition of the Renesas Core Group Chat! +10:05 < morimoto> hi +10:05 < geertu> pinchartl will be a few minutes late +10:06 < geertu> dammsan may prefer improving his Japanese? +10:06 < geertu> Today's Agenda: +10:06 < geertu> 1. Status updates +10:06 < geertu> 2. Handling differences between R-Car H3 ES1.x and ES2.0 +10:07 < geertu> Topic 1. Status updates +10:07 < geertu> A) What have I done since last time +10:07 < geertu> B) What I plan to do till next time +10:07 < geertu> C) Problems I have currently +10:07 < dammsan> geertu: i'm here! +10:07 < geertu> dammsan: great! +10:07 < geertu> "sort -R" ... (virtual dices are rolling) ... +10:07 < geertu> Niklas! +10:08 < neg> a) implemented drive strength for non-I/O pins on a pin level and it works +10:08 < neg> b) post the patches for drive strength +10:08 < neg> c) Some trouble getting none I/O poins to work on a group level, sh-pfc assumes the pin can be muxed but when that fails for the none I/O pins it bails-out and the configuration is not applied to the group. Is This something we wish to change or should drive-strength for example only be able to set on a pin basis? Looking at the state u-boot leaves the AVB pins not all pins are set to the same +10:08 < neg> drive-strength level. +10:10 < geertu> I don't know. Any RAVB experts around? +10:10 < horms> i have dabbled in ravb but I am not sure about that question +10:11 < horms> you may get some value from talking with sergei, he seems to take particular interest in ravb +10:11 < horms> And he seems to like a quick chat on #renesas-soc +10:12 < geertu> Adding to that, posting a first version as an RFC never hurts, and may attract comments. +10:14 < geertu> Anything else? +10:14 < neg> no I will post a RFC and take it from there, thanks +10:14 < geertu> Thanks Niklas! +10:14 < geertu> Next is me, myself, and I: +10:15 < geertu> A) - Received and lightly tested M3-W/Salvator-X board, thanks! +10:15 < geertu> - Reviewed lots of patches to add (DT) support for new boards +10:15 < geertu> B) - Continue RST, MODEMR, ES-handling, ... +10:15 < geertu> - 64-bit memory with M3-W Ethernet +10:15 < geertu> C) Nothing +10:15 < geertu> (or perhaps more time and deduplication into Me, Myself, and I) +10:16 < pinchartl> what's the status of MODEMR ? +10:16 < khiemnguyen> good question. +10:16 < geertu> pinchartl: No change +10:17 < geertu> and Stephen Boyd came with the suggestion to use the shiny new nvmem API instead +10:17 < pinchartl> I've seen that +10:17 < pinchartl> I don't like it much +10:17 < geertu> OK, that makes two of us. +10:17 < geertu> Feel free to chime in ;-) +10:17 < pinchartl> especially due to the fact that we have to reference the nvmem DT node around +10:18 < geertu> Even syscon sounded better ;-) +10:19 < geertu> Next is Shimoda-san: +10:19 < shimoda> yes +10:20 < shimoda> A) What have I done since last time +10:20 < shimoda> I'm continue to investigate on Gen3 USB EHCI + IPMMU issue. So, nothing for core. +10:20 < shimoda> B) What I plan to do till next time +10:20 < shimoda> I should describe an explanation of "Lossy" into eLinux... +10:20 < shimoda> C) Problems I have currently +10:20 < shimoda> About core tasks, nothing for now. +10:20 < shimoda> end +10:20 < geertu> Thanks Shimoda-san! +10:20 < geertu> Next is pinchartl: +10:22 < pinchartl> no core task for me +10:22 < pinchartl> and nothing planned +10:22 < geertu> Thanks Laurent! +10:22 < geertu> Next is Simon: +10:22 < pinchartl> I'll need h3 ES2.0 support at some point to develop multimedia-specific features +10:22 < dammsan> pinchartl: can you hook up via google chat and discuss things with me +10:22 < pinchartl> but let's discuss that as part of the second topic +10:23 < pinchartl> dammsan: done +10:23 < pinchartl> (not the discussion, just the connection) +10:23 < dammsan> thanks +10:26 < pinchartl> horms: the stage is yours +10:26 < horms> A) What have I done since last time +10:26 < horms> * Verified Kexec on M3-W +10:26 < horms> - works fine with v4.8-rc2 +10:26 < horms> - user-space patches edging towards merge +10:26 < horms> - http://www.elinux.org/Tests:r-car-gen3-kexec +10:26 < horms> * Received and lightly tested M3-W/Salvator-X board, thanks! +10:26 < horms> B) What I plan to do till next time +10:26 < horms> * Finalise Kexec-to-RAM work by documenting hw/sw stack, writing report, etc... +10:26 < horms> C) Problems I have currently +10:27 < horms> * Ethernet integration plan +10:27 < geertu> For C, I think that'll be assigned to me soon, as an additional task incl. 64-bit memory +10:28 < horms> great +10:28 < horms> one more: +10:28 < horms> * SDR50 on Gose SDHI1 - may relate to voltage switching??? +10:28 < horms> --- end --- +10:28 < pinchartl> geertu: as far as I know RAVB doesn't have support for 64-bit memory +10:29 < geertu> pinchartl: Cool, so that part is gonna fail. But in the end it should work anyway... +10:30 < horms> my research indicated that almost none of the ip blocks have 64bit support as such +10:30 < horms> so i suppose the ipmmu will become central +10:30 < pinchartl> horms: agreed +10:31 < pinchartl> geertu: it will work with the IPMMU but won't without +10:31 < pinchartl> (after we enable 64-bit memory) +10:31 < geertu> pinchartl: or with bounce buffers... +10:31 < horms> so hopefully the imppu works :^) +10:31 < horms> so hopefully the ipmmu works :^) +10:32 < geertu> Let's see... +10:32 < pinchartl> geertu: ouch. indeed. let's try not to :-) +10:33 < dammsan> geertu: you got my update via email +10:33 < dammsan> basically IPMMU stuff for A) and B) +10:33 < dammsan> need to update the bootloader so that may turn into C) worst case +10:34 < pinchartl> dammsan: have you had time to check the IOMMU patches posted by Sricharan ? +10:34 < geertu> dammsan: How did you know you were next (yes yoy are!), after Simon? +10:35 < geertu> s/yoy/you/ +10:35 < geertu> Thanks Simon +10:35 < geertu> Thanks Magnus ;-) +10:36 < geertu> Next is Ul(r)i(ch): +10:36 < uli___> A) Integrated SYS-DMAC on M3-W +10:36 < uli___> B) Test SYS-DMAC integration and post the patches +10:36 < uli___> C) See agenda 2. +10:36 < uli___> plus, for a) m3-w boards works for me, too +10:37 < uli___> for c) the growing stack of boards obscures my view on the monitor +10:37 < uli___> cannot move it because the ethernet cable is too short +10:37 < uli___> i also lost my glasses +10:37 < uli___> life is miserable +10:37 < uli___> that's it +10:37 < geertu> Sorry to hear about your glasses +10:37 < geertu> I can understand you can't extend the Ethernet cable now ;-) +10:38 < uli___> if the sign says, "don't use the water slide with glasses", i recommend to listen :) +10:38 < horms> haha +10:38 < horms> i can send you some ethernet cables if that would cheer you up +10:38 < uli___> thanks, but i'll find something, i'm sure :) +10:38 * geertu has strong glasses, all Ethernet cables are too long +10:40 < geertu> uli: For agenda 2, I guess you mean ES2.0? +10:40 < uli___> i was thinking about distinguishing between ES revisions +10:40 < uli___> is that what this is about? +10:40 < geertu> That's one part of it. +10:41 < geertu> Thanks Ulrich! +10:41 < geertu> next is Morimoto-san: +10:41 < morimoto> A) No Core Task. But Coming out myself to Geert +10:41 < morimoto> B) No plan +10:41 < morimoto> C) No issue +10:41 < morimoto> --end-- +10:42 < geertu> morimoto: You were wondering about +10:42 < geertu> Reset,2016-12-31,request,?,Upstreaming and Test +10:42 < geertu> PM,2017-03-31,request,Simon,Upstreaming and Test +10:42 < geertu> ? +10:42 < morimoto> Yes +10:42 < pinchartl> morimoto: congratulataions for your new son :-) +10:42 < geertu> For the former: +10:42 < geertu> - System reset is handled by PSCI, and works (try typing "reboot") +10:42 < geertu> - Watchdog reset also works +10:42 < geertu> - Did you have anything else in mind? +10:42 < morimoto> Is it already upstreamed ? +10:43 < morimoto> pinchartl: thanks. bit son :) +10:43 < morimoto> s/bit/big/ +10:44 < geertu> morimoto: Watchdog is in -next, for both h3 and m3-w +10:44 < geertu> morimoto: The rest is standard PSCI, nothing to upstream +10:45 < morimoto> OK, sounds nice. So I will remove "Reset" line from reqest +10:45 < morimoto> How about PM ? +10:45 < geertu> That's s2ram? Simon? +10:46 < khiemnguyen> PM = ? +10:46 < morimoto> s2ram +10:46 < horms> Sorry, what is the question? +10:46 < horms> s2ram status on gen3? +10:47 < morimoto> Yes +10:47 < morimoto> Ahh, this ?generic,2016-08-15,plan,simon,r8a7796 s2ram prototype +10:47 < horms> Suspend and resume seems to function, there are some caveats +10:47 < horms> Magnus describes them as meaning it doesn't work +10:47 < horms> 1. ethavb resume was broken. I believe that has been fixed. neg? +10:48 < horms> 2. The big problem: firmware work around for ddr training causes the system to resume in < 1s +10:48 < khiemnguyen> morimoto: you are mentioned about latest S2RAM in Yocto v2.12.0 ? +10:48 < geertu> horms: yes, ravb resume has been fixed +10:48 < horms> ok, good +10:48 < horms> one less problem +10:48 < horms> i'm unsure what the timeframe is for resolving #2 +10:48 < morimoto> OK, I wounder is it listed on "todo" file ? +10:49 < morimoto> as task +10:49 < geertu> morimoto: No, the todo file contains kernel tasks only +10:49 < morimoto> Ahh, OK +10:49 < horms> i think the task would be to co-ordiante with firmware team to get a fix. +10:50 < morimoto> OK, thanks +10:50 < dammsan> horms: yes, thanks! +10:51 < morimoto> horms: should I do something for it ? +10:51 < morimoto> I mean I need to ask to firmware team ? +10:51 < horms> I think we should talk to the firmware team +10:51 < horms> and yes, if you could do that I think that would be great +10:52 < horms> perhaps there is a way to get s2ram working without breaking ddr +10:52 < horms> or perhaps I missunderstand the situation somehow +10:52 < horms> or perhaps magicaally everyething will be prefect somehow :) +10:53 < morimoto> Oops, I remember we need new firmware for it ? I'm not sure +10:53 < morimoto> v2.12.0 I mean +10:53 < horms> Is that a firmware version I could test. e.g. on my shiny m3-w board? +10:54 < horms> Or perhaps its installed on a board that could be used to test +10:54 < horms> really its very easy to reproduce +10:54 < horms> 1. boot stock kernel +10:54 < horms> 2. echo mem > /sys/power/state +10:54 < horms> 3. wait < 1s +10:55 < horms> If the system wakes up, probably the problem is still there +10:55 < morimoto> Maybe v2.12.0 firmware is needed, but we don't have it at this point +10:55 < horms> ok +10:55 < horms> lets discuss with the firmware team +10:55 < horms> can you do that? +10:55 < morimoto> OK, will do +10:55 < horms> thanks! +10:55 < morimoto> For H3 ? M3 ? both ? +10:56 < horms> both +10:56 < morimoto> OK, +10:58 < khiemnguyen> horms: each driver need to be updated, to backup register context. Otherwise, resume will fail. +10:59 < horms> ok. even drivers that can resume on gen2? +10:59 < geertu> khiemnguyen: Wait, so it is a deeper sleeper than s2ram on Gen2? +11:00 < khiemnguyen> geertu: yes +11:01 < khiemnguyen> at suspended state, the board will shutdown, only power of DDR region will be kept. +11:01 < shimoda> khiemnguyen: is it gen3? not gen2. +11:01 < khiemnguyen> and you need one I2C command to set DDR backup mode, before calling S2RAM. +11:02 < khiemnguyen> It's Gen3. +11:02 < khiemnguyen> ....are we talking about Gen3 ? +11:02 < geertu> khiemnguyen: What does suspend to RAM do now? I thought it did the real suspend, but woke up early due to the need to do something with DDR? +11:03 < horms> thats what i thought +11:03 < geertu> "and you need one I2C command to set DDR backup mode, before calling S2RAM." may be an issue, as AFAIK everything is "handled" in core arm64 code by calling into PSCI. +11:03 < morimoto> khiemnguyen: does your comment based on BSP local implementetion ? +11:04 < khiemnguyen> morimoto: yeah +11:06 < dammsan> [1;5Cit's like upstream first, but not +11:08 < khiemnguyen> morimoto: so, for S2RAM, will we support similar S2RAM mechanism, like in Yocto v2.12.0 ? +11:10 < khiemnguyen> or we just enable S2RAM and fix drivers issues, if any +11:10 < pinchartl> (just FYI, I have to leave at 12:30 EEST sharp) +11:10 < geertu> Ok, let's handle this offline (on periperi ML) +11:10 < geertu> Thanks Morimoto-san! +11:11 < morimoto> geertu: thanks +11:11 < geertu> Next (and final) is Khiem: +11:13 < khiemnguyen> a) No update. +11:13 < khiemnguyen> b) Gen3 CPUFreq (Z clk changing) +11:13 < khiemnguyen> I missed v4.9. Will try v4.10. +11:13 < khiemnguyen> Please comment if any. +11:14 < khiemnguyen> c) My current mail client is Outlook. It's not able to use other email clients for now. under discussion with IT members. +11:14 < khiemnguyen> My last Thermal patches got problem when sending out. Could not see it in patchwork... +11:14 < khiemnguyen> That's all. +11:14 < pinchartl> khiemnguyen: to send patches I recommend git-send-email :-) +11:15 < geertu> khiemnguyen: Can you let git send-email talk to the Exchange server directly through SMTP? +11:15 < pinchartl> geertu: exchange might still rewrite the mail though and replace tabs with spaces +11:15 < khiemnguyen> pinchartl: I will try to discuss with IT. I still have some restrictions in my company. Will try to solve it. +11:16 < khiemnguyen> morimoto: you are using git-send-email, right ? +11:16 < geertu> pinchartl: yes it might (it did at Sony Europe, not Sony US) +11:16 < shimoda> khiemnguyen: i have git-send-email setting. so if you need it, please let me know :) +11:17 < khiemnguyen> shimoda: thanks. Will contact you offline. +11:17 < geertu> Thanks Khiem! +11:17 < shimoda> khiemnguyen: i got it. +11:17 < geertu> Topic 2. Handling differences between R-Car H3 ES1.x and ES2.0 +11:18 < morimoto> khiemnguyen: I never use git-send-email: I'm using Emacs+Wounderlust +11:19 < geertu> The plan has been (for a while) to use "-es1" in the compatible value, cfr. "renesas,sata-r8a7790-es1" +11:19 < geertu> Ideally, these would be added automatically to the DTB, by DT fixup code (which is WIP). +11:20 < geertu> For "renesas,sata-r8a7790-es1", this was added manually, I assume? +11:20 < pinchartl> I assume you mean r8a7795-es1 ? +11:20 < geertu> Now, it seems there are several differences between R-Car H3 ES1.x and ES2.0 +11:20 < dammsan> geertu: yes, it was an earlier trial for ES handling +11:20 < geertu> pinchartl: We don't have any r8a7795-es1 string yet. +11:21 < geertu> We started with DU and VSP +11:21 < khiemnguyen> geertu: will it be long-term solution ? +11:21 < geertu> Now we start to see differences in CPG/MSSR, PFC, ... +11:22 < geertu> khiemnguyen: In the long term, there will be ES2.0 only? +11:22 < geertu> khiemnguyen: But we may want to keep on using our ES1.x boards +11:23 < geertu> The approach we wanted to take was to focus on the most recent ES ("production") only. +11:23 < pinchartl> on the VSP and DU side there will be non-trivial differences between ES1 and ES2 and we'll need to manually update DT +11:23 < geertu> And try to fixup (preferably at runtime) for running on ES1.x. +11:24 < geertu> So for PFC, it looks like the current pfc-r8a7795 is for ES1.x only +11:24 < geertu> Due to the sheer amount of differences, I think the driver should be renamed to pfc-r8a7795-es1.c +11:25 < geertu> and a new pfc-r8a7795.c for ES2 should be added. +11:25 < neg> for PFC I think that is a good idea +11:25 < geertu> For CPG/MSSR, it's the same. +11:25 < horms> Naming convention asside, i think so too +11:25 < horms> but what if any path is there for forwards compatibility +11:26 < pinchartl> is there any estimate regarding the availability of H3 ES2.0 boards ? +11:26 < geertu> horms: if we have DT fixup, it will automatically be forweard compatible, as the DTS will only have "r8a7795" compatible values. +11:27 < horms> ok +11:27 < horms> got it +11:27 < shimoda> i have a question, how to handle if the number of channels differs between ES1 and ES2? +11:27 < geertu> horms: Only at run-time the "r8a7795-es1" would be added (or changed, for PFC and CPG/MSSR) +11:28 < geertu> shimoda: That was going to be my next point :-) +11:28 < geertu> For Multimedia, the differences seem to be in number of channels (DU) or instances (VSP), and their wiring. +11:28 < pinchartl> yes +11:28 < pinchartl> that will need to be manually changed in DT +11:28 < pinchartl> so if we need an -es1 .dtsi anyway +11:28 < geertu> _Adding_ device nodes in DT fixup code is more difficult than _removing_. +11:29 < pinchartl> is there a point in trying to fixup DT automatically at runtime ? +11:29 < geertu> So having r8a7795.dtsi match the latest revision is problematic. +11:29 < geertu> pinchartl: If it's just the number of channels, it's doable. +11:30 < geertu> If the DU<->VSP topology is too complex, it's different... +11:30 < pinchartl> geertu: it's the DU<->VSP topology that changes +11:30 < pinchartl> the number of DU channels in the same +11:30 < pinchartl> but two of them are served by the same VSP instance +11:30 < dammsan> we can also simply deprecate ES1.x DU support +11:30 < geertu> pinchartl: oh, the change in the number of DU channels is for H3<->M3-W? +11:31 < geertu> pinchartl: Can you serve the two DU channels by one VSP on ES1 too? +11:31 < geertu> (pinchartl: You have to go?) +11:33 < pinchartl> yes it's for M3 +11:33 < pinchartl> and no I can't +11:33 < pinchartl> and yes I have to go :-) +11:33 < pinchartl> sorry +11:33 < pinchartl> I'll read the log later +11:34 < geertu> Is there a document that lists the differences between H3 ES1.0, ES1.x (x > 0), and ES2.0? +11:34 < morimoto> It is difficult to understand pinchartl's yes/no, but it is not my English skill ;P +11:34 < geertu> morimoto: Yes, M3-W has less DU channels than H3 +11:35 < morimoto> geertu: let me check +11:35 < horms> s/less/fewer/ +11:35 < geertu> morimoto: No, you cannot serve the two DU channels on ES1 using one VSP +11:35 < geertu> horms: Dankuwel +11:36 < morimoto> geertu: thank you for your translation :) +11:36 < horms> geertu: sorry, that correction is hard wired into my brain through bitter experience +11:37 < geertu> uli___: You need ES checks for HDMI? +11:38 < uli___> yes +11:38 < geertu> uli___: Can it be solved through an "es1" compatible value? +11:38 < uli___> i also need to distinguish between 1.0 and 1.1... +11:38 < geertu> ... "es1.0" and "es1.1" compatible values? +11:39 < uli___> that should do +11:39 < geertu> OK, good to know. +11:39 < geertu> So I think dynamic DT fixup can work for most cases, except for DU/VSP topology +11:39 < geertu> Then, Dirk Behme is worried about boot up performance. +11:40 < morimoto> geertu: I think I can get ES diff sheet. I will send it +11:40 < geertu> Fixing DT takes time (to be measured) +11:41 < geertu> Dirk prefers an API to read PRR, and handle upon that +11:42 < geertu> Or we can use soc_device_register() (see include/linux/sys_soc.h) +11:43 < geertu> Arnd posted a patch to add soc_device_match(), which can match against SoC-specific revision wildcards. +11:44 < geertu> But I take it all of you are slowing falling asleep? ;-) +11:44 < uli___> to me, that sounds better than the other approaches discussed so far +11:45 < geertu> Which one sounds better? PRR API? soc_device_match()? +11:45 < uli___> the latter +11:46 < geertu> We may still need DT fixup for backwards compatibility (add RST and APMU device nodes) +11:46 < shimoda> i didn't know the drivers/base/soc.c, and it seems very simple +11:46 < geertu> and I had a wild idea of using DT fixup to add all SoC-specific compatible values, so we can share more .dtsi +11:47 < uli___> as for the boot-up delay, what order of magnitude are we talking here? +11:48 < geertu> To be measured... +11:49 < uli___> ah, ok +11:49 < geertu> It also depends at which phase of the boot we do it. +11:49 < dammsan> i just don't want to add a new special API that we are the only users of +11:49 < geertu> For APMU devices nodes, it needs to be done right after unflatten, which is before we have kmalloc() :-( +11:51 < dammsan> soc_device_match() may not be so bad +11:51 < geertu> dammsan: So you also like nvmem API for MODEMR? +11:51 < dammsan> not so much +11:51 < dammsan> i just dislike the PRR proposal by Dirk +11:51 < dammsan> it is like looking at vxworks code +11:52 < dammsan> it also goes against being standard +11:52 < neg> I'm a bit scared of DT fixups, but trust your judgemnt that it won't eat my dog :-) +11:52 < dammsan> and following simple accepted APIs +11:52 < geertu> Bonus is you will get the ES version somewhere in /proc or /sys ;-) +11:52 < dammsan> also, if DT is so slow, why don't we have any numbers yet? +11:52 < dammsan> hehe +11:53 < geertu> dammsan: Nobody does DT fixup +11:53 < dammsan> i know +11:53 < dammsan> but at least proposing a general purpose way of doing things +11:53 < dammsan> is much better than cooking up your local API just to be used by a couple hidden away drivers +11:54 < geertu> OK, will try the soc_device_match() thingy +11:54 < dammsan> so i think it is great that you are proposing the DT fixups +11:54 < dammsan> or whichever new standard you are proposing +11:54 < dammsan> as long it is not specific to our SoC +11:55 < dammsan> looking forward to see your proposal +11:56 < geertu> If we don't do DT fixup for ESx.y, we will keep single pfc-r8a7795 and r8a7795-cpg-mssr drivers that do their own ES check through soc_device_match()? +11:59 < horms> I'm unclear on what soc_device_match() would match on +12:00 < geertu> On the revision string in include/linux/sys_soc.h:soc_device_attribute +12:01 < shimoda> I'm afraid again but how to handle the number of channels differs by soc_device_match() API? +12:02 < shimoda> for example, es1.1: usb3 2ch, usb2 3ch --> es2.0: usb3 1ch, usb2 4ch +12:02 < geertu> shimoda: For those things we need a different solution +12:02 < geertu> H3 ES2.0 is really a different SoC +12:03 < shimoda> geertu: i understood it. thanks! +12:05 < geertu> Guys, I'm not gonna hold you from whatever any more. +12:05 < geertu> Thanks for joining the 25th edition! +12:05 < horms> thanks, look forward to the 26th! +12:05 < neg> thanks all +12:06 < uli___> bye +12:06 < neg> geertu: I was a bit confused by this meeting inviation. Do you want a summary of the A), B) and C) items in the mail or just updates to periperi lit items? +12:07 -!- horms [~horms@217.111.208.18] has quit [Read error: Connection reset by peer] +12:07 < geertu> neg: Just updates to the todos, like Wolfram commented a while ago ;) +12:07 -!- horms [~horms@217.111.208.18] has joined #periperi +12:11 < shimoda> thanks all! bye! +12:11 -!- shimoda [~shimoda@relprex1.renesas.com] has quit [Quit: WeeChat 0.4.2] +12:12 < morimoto> geertu: Can we have this discussion (= how to handle ES version) on ELCE timing ? +12:13 < geertu> morimoto: Sure +12:13 < morimoto> Thanks +12:13 < morimoto> I added its page on +12:13 < morimoto> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Miniperi-2016-10 +12:13 < geertu> Thanks +12:14 < morimoto> Bye diff --git a/wiki/Chat_log/20160914-mm-chatlog b/wiki/Chat_log/20160914-mm-chatlog new file mode 100644 index 0000000..c8ce095 --- /dev/null +++ b/wiki/Chat_log/20160914-mm-chatlog @@ -0,0 +1,358 @@ +Multimedia-chat-meeting-2016-09-14 + +10:08 < pinchartl> topics for the day +10:08 < pinchartl> Topic 1. Status check for the multimedia tasks +10:08 < pinchartl> Topic 2. Additional tasks for Q4 2016 +10:08 < pinchartl> Topic 3. Status update for Renesas on the multimedia todo list +10:08 < pinchartl> anything else ? +10:09 < pinchartl> maybe +10:09 < neg> yes a quick question about what work to aim to include for renesas-drivers releases +10:09 < pinchartl> Topic 4. Agenda for the multimedia face to face meeting in Berlin +10:09 < pinchartl> ok +10:10 < pinchartl> - Topic 1. Status check for the multimedia tasks +10:11 < pinchartl> in real alphabetical order today +10:11 < pinchartl> Kieran, you're first +10:11 < kbingham> hehe I feel privilidged :D +10:11 < pinchartl> (in the usual "what did I do, what do I plan to do, what problems do I have" format) +10:13 < kbingham> Since last meetinng, I have worked on VSP Partitioning Algorithm, now submitted and next plan a short task to assist geertu, as he has had to drop FDP1 from his tree. No particular problems at the moment. +10:14 < kbingham> Oh - actually - I do have a small problem. +10:14 < kbingham> Current tests still aren't running clean for me on the VSP. - So I'll see what that is first. +10:15 < pinchartl> nice work on the VSP +10:15 < pinchartl> regarding the FDP, I've posted a v3 of the patches which you have reviewed (thanks for that) +10:15 < pinchartl> now that everything is in order I'll push my branch and will ask Geert to merge it +10:16 < pinchartl> so there's no need for you to get bothered with that +10:16 < kbingham> That's a good solution to assist Geert :D +10:16 < pinchartl> if you're now bored I have new tasks for you for Q4 which you could get started with :-) +10:16 < pinchartl> let's discuss them as part of the second topic +10:16 < kbingham> ;) +10:17 < pinchartl> regarding the VSP tests, which one(s) are failing for you ? +10:17 -!- morimoto [~user@relprex3.renesas.com] has joined #periperi +10:17 < pinchartl> hello Morimoto-san ! +10:17 < kbingham> Test 1, 2, "yuv_to_rgbpnm: bad format" +10:17 < pinchartl> Geert was wondering if you were busy working on a new son :-D +10:18 < morimoto> sorry for my late +10:18 < morimoto> pinchartl: hehe :) +10:19 < pinchartl> kbingham: could you try to update raw2rgbpnm to the latest version ? +10:19 < kbingham> pinchartl: did something change there? +10:20 < pinchartl> "Add support for missing YUV 4:1:1, 4:2:0, 4:2:2 and 4:4:4 planar formats" +10:20 < pinchartl> that's not very recent though +10:20 < pinchartl> we can discuss this after the meeting +10:21 < kbingham> Yes, I dno't think this is topic for this meeting. +10:21 < pinchartl> and regarding your plan for the next two weeks, I assume you'll also write the VSP image partitioning task report for Jinzai, right ? :-) +10:21 < kbingham> Ah yes :) +10:21 * kbingham whistles loudly pretending he hadn't forgotten about that. +10:22 < pinchartl> thanks for the report +10:22 < pinchartl> next, me +10:22 < pinchartl> Since last meeting: +10:22 < pinchartl> - Posted v3 of the FDP driver +10:22 < pinchartl> - VSP image partitioning support +10:22 < pinchartl> - DU and VSP integration on H3 +10:23 < pinchartl> For the next two weeks: +10:23 < pinchartl> - Continue working on the FDP driver to get it merged upstream +10:23 < pinchartl> - VIN and HDMI output patch review +10:23 < pinchartl> ah, I forgot to mention, I've also worked on +10:23 < pinchartl> - Rebased VSP HGO and HGT support +10:24 < kbingham> And ROT/FLIP +10:24 < pinchartl> yes, that's part of image partitioning, but it's worth mentioning it explicitly +10:25 < pinchartl> and, just for the fun of it, reverse-engineered the VSP RGB to HSV transformation to include emulation code in the test suite :-) +10:26 < pinchartl> morimoto: I forgot to reply to your e-mail, but less than 24h after you've told Niklas and me that the hardware team couldn't share the information because it was confidential, we managed to understand how it worked +10:26 < morimoto> pinchartl: we are sorry about that +10:27 < morimoto> Is it needed for test program, correct ? +10:28 < pinchartl> yes +10:28 < pinchartl> but it's fine now +10:28 < morimoto> OK +10:28 < pinchartl> we have fixed the problem, we know how it works +10:28 < pinchartl> we will have a similar issue with the UDS though: +10:28 < pinchartl> Issues and Blockers: +10:28 < pinchartl> - VSP test suite generates false positives in UDS testing +10:28 < pinchartl> This is caused by the emulation code scaling images with a method very different from the one used by the UDS, resulting in a need for a fuzzy comparison between the hardware output and the expected results with a too high threshold. +10:30 < pinchartl> in the next two weeks, I will also continue working on VSP HGO and HGT, as Mauro isn't convinced by the API proposal +10:30 < morimoto> About your "Issues and Blockers", do you need HW team help ? +10:31 < pinchartl> it would be nice to get more information about how the scaler operates, but I expect the same "this is confidential" answer :-/ +10:31 < pinchartl> but it's worth asking +10:31 < pinchartl> this will likely be a task for the second half of Q4 +10:31 < morimoto> OK, I will try, no expectation +10:32 < pinchartl> arigatō gozaimasu +10:32 < morimoto> Can you please add detail background on meeting report ? +10:32 < pinchartl> yes I will +10:32 < pinchartl> next, Morimoto-san +10:32 < morimoto> arigato +10:32 < morimoto> OK +10:33 < morimoto> I'm posting ALSA SoC patches to ML, but it seems Maintenor is focus to next kernel ? +10:33 < morimoto> so, nothing happen on my patches +10:33 < morimoto> I negotiated to Lars and Mark to discuss about ALSA SoC framework cleanup +10:34 < morimoto> and for new style ALSA SoC. I can talk it on ELCE timing +10:34 < morimoto> And BSP team is now focusing about Audio-DMAC power +10:34 < morimoto> As I asked on PeriPeriML, it is related to DMAEngine behavior +10:35 < pinchartl> please let me know if you would like me to join the discussion during ELCE +10:35 < morimoto> Thank. I'm happy if you can join to it. +10:35 < morimoto> it will be 2nd day, lunch timing +10:35 < morimoto> after Lars's presentation +10:36 < pinchartl> that works for me +10:36 < morimoto> About DMAEngine, rcar-dmac will power ON for Audio-DMAC when sound driver requests DMA channel +10:36 < morimoto> and power OFF when sound driver release it. +10:36 < morimoto> In my driver, it requests channel when .probe timing +10:37 < morimoto> this means, Audio DMAC is always ON +10:37 < pinchartl> right, I've seen your e-mail +10:37 < morimoto> which is correct approach +10:37 < morimoto> ? +10:37 < pinchartl> that's more of a core topic +10:37 < morimoto> Oops +10:37 < pinchartl> but in a nutshell, I think it would be good to optimize power consumption +10:37 < pinchartl> and only keep the hardware powered on when needed +10:38 < pinchartl> the issue there is that you need to call pm_runtime_get_sync() to power the hardware on +10:38 < pinchartl> which can't be called in atomic context +10:38 < pinchartl> and dma_async_issue_pending() needs to be callable in atomic context +10:38 < pinchartl> so to fix this we would likely need to extend the DMA engine API +10:39 < pinchartl> but to get sucha change accepted +10:39 < pinchartl> we need to provide power consumption numbers +10:39 < morimoto> It is not Renesas specific issue, correct ? +10:39 < pinchartl> so we need to measure the extra power consumption caused by keeping the DMA engine powered on while not in use +10:39 < pinchartl> correct +10:40 < morimoto> Actually, I already created above patches. it request/release each times +10:40 < pinchartl> is that changes for the DMA engine driver or for the ALSA driver ? +10:40 < morimoto> Do you think I should post it to ML ? or keep it in my pocket ? +10:40 < morimoto> ALSA driver side only +10:40 < pinchartl> that's the second idea I was going to propose +10:41 < pinchartl> keep powering the DMA engine on in dma_request_channel() +10:41 < pinchartl> (or rather device_alloc_chan_resources()) +10:41 < pinchartl> but move the dma_request_channel() from ALSA driver .probe() to a later point +10:41 < pinchartl> I think those patches would be sense to be posted +10:42 < morimoto> OK +10:42 < morimoto> This means, request/release happen many times. is this correct ? +10:43 < pinchartl> yes +10:43 < pinchartl> well, more than currently at leas +10:43 < pinchartl> t +10:43 < morimoto> OK. nice to know. I can be your father if you want :) +10:43 < pinchartl> I don't think my current father would be happy about that :-) +10:43 < morimoto> hehe :) +10:43 < morimoto> That's it from me +10:44 < pinchartl> what's your plan for the next two weeks ? +10:45 < morimoto> About patches, it is based on Maintenor. +10:45 < morimoto> I need to post more patches, but these are based on current patches. +10:45 < morimoto> If no update on ML, I will do Renesas side task +10:45 < pinchartl> ok +10:46 < pinchartl> thank you +10:46 < pinchartl> next, Niklas +10:46 < neg> a) Posted HGT patches, I see minimal work left to keep them up to date until they can be picked up +10:46 < neg> b) Start to work on VIN for M3 and rebase VIN Gen3 patches +10:46 < neg> c) No review on VIN Gen3 patches +10:47 < neg> also if there is time update the vsp-tests tool to take overlaping HGT hue areas in to account +10:47 < pinchartl> for the HGT, let's sync up on that after the meeting, I'll take your patches in my tree +10:47 < neg> ok +10:47 < pinchartl> I have done so already, probably a slightly different version, that's why we need to sync up +10:48 < pinchartl> regarding the VIN Gen3 patches, they were on my todo list after last meeting, but I had to focus on the VSP :-/ +10:48 < pinchartl> I'll really try to get to them ASAP +10:48 < pinchartl> you had a quick question about what work to aim to include for renesas-drivers releases ? +10:49 < neg> np :-) +10:49 < neg> I have tried to keep the VIN Gen3 patches ready for renesas-drivers but have not always sucseeded in keeping them up to date. And since they seems to be a long way from beeing pickedup I was wondering if I should drop them from the patches I try to get in to renesas-drivers so Geert don't have to deal with any conflicts that series cause. If you see value in having them in renesas-drivers I will rejuvenate +10:49 < neg> my effort to keep them up to date at all times. +10:50 < pinchartl> geertu: any opinion on that ? +10:53 < pinchartl> renesas-drivers is a -next tree that is a bit more agressive than -next. it serves as a way to catch integration (as in merging multiple development branches) issues early +10:53 < pinchartl> including Gen3 VIN support in renesas-drivers is thus useful when you post a new version of the patch series +10:53 < pinchartl> but after that, if it starts generating painful conflicts, it likely means a new version of the series will be needed anyway +10:54 < pinchartl> so I wouldn't insist in keeping the code in renesas-drivers at all times +10:55 < neg> ok, I will continue to try and keep them up to date and included in renesas-drivers then +10:55 < pinchartl> please submit them for inclusion when you post a new version of the patches +10:55 < pinchartl> but don't spend an unnecessary large amount of time keeping them up-to-date between two versions +10:56 < neg> make sens +10:57 < pinchartl> thanks +10:57 < pinchartl> next, uli___ +10:58 < uli___> a) +10:58 < uli___> - kept the salvator hdmi out alive (build failure; want to convert it to soc_device_match() before sending a new revision) +10:59 < uli___> - checked if it works without the funky cma reservation patch (it does, it's sufficient to increase the cma size) +10:59 < uli___> - started looking into gen2 vin integration in earnest (see c) ) +10:59 < uli___> b) finish gen2 vin integration +10:59 < uli___> c) i don't have hardware docs for the gose board +10:59 < uli___> can somebody set me up with those? +10:59 < uli___> [that's it] +11:00 < pinchartl> do you regarding Gen2 VIN integration, that's due for the 18th, so I assume you'll finish it before two weeks ? :-) +11:00 < pinchartl> s/do you // +11:00 < uli___> yes +11:01 < pinchartl> thanks +11:02 < pinchartl> what's the status of DU,v4.9,public,ulrich,EDID generation support for the HDMI loopback test setup ? +11:02 < uli___> that's part of the hdmi in series, i'll send that out with gose support added before the due date +11:03 < pinchartl> perfect, thanks +11:03 < uli___> provided somebody can get me the docs... +11:03 < uli___> morimoto: HINT +11:03 < pinchartl> do you mean the schematics ? +11:03 < uli___> yes +11:03 < pinchartl> do you have a GPG key ? +11:03 < uli___> afraid not +11:04 < pinchartl> can you create one ? :-) +11:04 < uli___> is there an alternative? [i have no clue about that] +11:04 < pinchartl> morimoto: can I send the Gose schematics to Ulrich by e-mail without encryption ? +11:05 < morimoto> Hmm.. +11:05 < morimoto> Now, it is under your NDA or export side issue +11:05 < morimoto> (I wonder why you have it ?) +11:05 < pinchartl> let's assume I don't have it :-) +11:05 < morimoto> Hehe :) +11:05 < morimoto> uli___: I will ask to Renesas guy +11:06 < uli___> thank you +11:06 < morimoto> but few availability +11:06 < pinchartl> availability of the schematics ? +11:07 < morimoto> maybe +11:07 < pinchartl> we're not asking for a board to be sent, just a document :-) +11:07 < morimoto> Hehe, OK +11:08 < pinchartl> thanks +11:08 < pinchartl> that's it for the status update +11:08 < pinchartl> Topic 2. Additional tasks for Q4 2016 +11:09 < pinchartl> here are the additional tasks that will very likely be assigned to all of you for Q4 +11:09 -!- Irssi: Pasting 7 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +11:09 < pinchartl> Laurent: +11:09 < pinchartl> - M3-W DU support (5 days) +11:09 < pinchartl> - LVDS mode selection for DU (5 days) +11:09 < pinchartl> Kieran: +11:09 < pinchartl> - DU write-back V4L2 prototype (10 days) +11:09 < pinchartl> - VSP image partitioning performance optimization (5 days) +11:10 -!- Irssi: Pasting 6 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +11:10 < pinchartl> Niklas: +11:10 < pinchartl> - M3-W VIN prototype support (5 days) +11:10 < pinchartl> Ulrich: +11:10 < pinchartl> - Audio loopback test program to test sampling rate and L-R issues (10 days) +11:10 < pinchartl> - DU Gen3 HDMI output upstream preparation (Channel 0 only) (5 days) +11:10 < pinchartl> I'll reach out to everybody with more detailed descriptions +11:10 < pinchartl> but if you already have questions, please go ahead +11:10 < morimoto> Is it updated version from Magnus ? +11:10 < pinchartl> (that's for the first half of Q4 only, the second half will follow later) +11:11 < morimoto> (I talked it with him, this morning) +11:11 < pinchartl> yes, that's from the e-mail he sent me a few hours ago +11:11 < morimoto> OK, nice to know +11:12 < morimoto> pinchartl: can you please add these tasks into peripelist todo list ? +11:12 < pinchartl> I will first write the detailed descriptions and get them approved, and I'll then add them to the todo list, sure +11:13 < morimoto> Thanks. +11:13 < pinchartl> Topic 3. Status update for Renesas on the multimedia todo list +11:14 < pinchartl> Morimoto-san told me that Renesas would like a status update on the following +11:14 -!- Irssi: Pasting 8 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +11:14 < pinchartl> DU,2016-12-31,request,?,M3 +11:14 < pinchartl> DU,2016-06-30,request,ulrich,HDMI out ES1.1 support +11:14 < pinchartl> VSP,2016-06-30,request,laurent,solve UDS scaling regression for Gen3 +11:14 < pinchartl> VSP,2016-06-30,request,laurent,give information to Renesas about rotation status +11:14 < pinchartl> VSP,2016-06-30,request,laurent,give information to Renesas about write-back feature plan +11:14 < pinchartl> VSP,2016-06-30,request,laurent,ES2.0 / M3 update +11:14 < pinchartl> VSP,2016-06-30,request,laurent,update request API on renesas-driver +11:14 < pinchartl> VSP,2016-06-30,request,laurent,vsp1_pm_suspend() bugfix +11:14 < pinchartl> VSP,2016-10-30,request,laurent,VSP cache less support for BSP team +11:15 < morimoto> Yes, thanks. I will remove these if it was in todo list +11:15 < pinchartl> - DU,2016-12-31,request,?,M3 +11:15 < pinchartl> there's an additional task for the first half of Q4 +11:15 < pinchartl> - DU,2016-06-30,request,ulrich,HDMI out ES1.1 support +11:16 < pinchartl> Ulrich, any information about that ? +11:16 < uli___> not really. morimoto gave me info on how to implement that quite a while ago, but it does not seem to help +11:16 < uli___> morimoto: right? +11:16 < morimoto> Oops ? +11:17 < uli___> i mean, it still doesn't work on es1.1, right? +11:17 < morimoto> Ah, sorry, it was different story +11:17 < morimoto> My issue which was few weeks ago was my side fault +11:17 < morimoto> It was firmware issue. +11:18 < morimoto> So please forget it. +11:18 < uli___> that's good news :) +11:18 < morimoto> So, missing is only ES1.1 handling +11:18 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] +11:19 < morimoto> But it is related to Geert's ES handling magic ? +11:19 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi +11:19 < uli___> yes, i'll look into that +11:19 < morimoto> OK. I will keep it under request file until next step +11:20 < pinchartl> uli___: do you think you can address that as part of either your base contract or the new "DU Gen3 HDMI output upstream preparation" task for Q4 ? +11:20 < uli___> yes, i think so +11:20 < morimoto> Nice to know ! +11:20 < pinchartl> thank you +11:20 < pinchartl> - VSP,2016-06-30,request,laurent,solve UDS scaling regression for Gen3 +11:21 < pinchartl> - VSP,2016-06-30,request,laurent,give information to Renesas about rotation status +11:21 < pinchartl> this depends on image partitioning support that is now public +11:21 < pinchartl> both have been tested and are working +11:21 < pinchartl> - VSP,2016-06-30,request,laurent,give information to Renesas about write-back feature plan +11:21 < morimoto> OK. nice. I will remove these. But I can't find "UDS" word on todo list +11:22 < pinchartl> that's because there was nothing UDS-specific that had to be done +11:22 < pinchartl> implementing image partitioning fixed it +11:22 < morimoto> OK +11:22 < pinchartl> - VSP,2016-06-30,request,laurent,give information to Renesas about write-back feature plan +11:22 < pinchartl> will be assigned to Kieran as an additional task for the first half of Q4 +11:23 < pinchartl> - VSP,2016-06-30,request,laurent,ES2.0 / M3 update +11:23 < pinchartl> will be handled as part of the DU M3 integration, assigned to me as an additional task for the first half of Q4 +11:23 < pinchartl> - VSP,2016-06-30,request,laurent,update request API on renesas-driver +11:23 < morimoto> About, Write-back, it is next Kieran's task ? +11:23 < morimoto> I can remove it if todo list has it +11:23 < morimoto> correct ? +11:24 < pinchartl> please wait until the task get officially approved :-) +11:24 < morimoto> :) OK +11:24 < pinchartl> I'll then move it from the request file to the todo file +11:24 < pinchartl> - VSP,2016-06-30,request,laurent,update request API on renesas-driver +11:25 < pinchartl> I'll update the patch series before ELCE and send a pull request to Geert for renesas-drivers +11:25 < morimoto> you can handle only todo list, Renesas side will update request file +11:25 < pinchartl> (ok) +11:25 < pinchartl> my plan is to do so before kernel recipes, which is in two weeks in Paris +11:26 < pinchartl> but it might overflow to the week before ELCE +11:26 < pinchartl> at the latest it will be done before ELCE +11:26 < pinchartl> - VSP,2016-06-30,request,laurent,vsp1_pm_suspend() bugfix +11:26 < morimoto> Request API do you mean ? +11:26 < pinchartl> (yes) +11:26 < pinchartl> this has been proposed as an additional task for Q4, but Magnus told me that it needs to be discussed internally in Renesas first +11:26 < pinchartl> - VSP,2016-10-30,request,laurent,VSP cache less support for BSP team +11:27 < pinchartl> this has also been proposed as an additional task for Q4, and will possibly be accepted for the second batch +11:27 < pinchartl> it will be discussed face to face in Berlin first +11:27 < pinchartl> as it's not clear yet how to proceed +11:27 < morimoto> What is the problem about VSP1 PM suspen d? +11:27 < pinchartl> it doesn't work :-) +11:27 < pinchartl> suspend/resume is broken +11:27 < morimoto> Ahh OK +11:28 < pinchartl> it might even crash the kernel, I don't remember exactly +11:28 < morimoto> OK, thanks +11:28 < morimoto> And, I think I sent request about mising format something. +11:28 < morimoto> BSP team created local patch, do you remember ? +11:29 < pinchartl> here's the description of the problem I sent to Magnus +11:29 < pinchartl> The VSP suspend/resume code is known to be broken and needs to be fixed. This is further complicated by the fact that the VSP memory accesses are served by the FCP on Gen3, creating a suspend/resume dependency between the two devices. +11:29 < pinchartl> The VSP suspend/resume problem should be self-contained, but the FCP dependency would require dependencies support in the PM core. Work is ongoing in that area, and I believe we should take a more active role there. This isn't very suitable for additional tasks as they exist today as no deliverable can be guaranteed in a fixed amount of time. +11:29 < pinchartl> It might be possible to work around the problem by using the early/late suspend/resume handlers in the VSP and FCP drivers. I can't guarantee this at the moment without a more detailed and thus time-consuming analysis, hence the prototype status of this task. +11:30 < pinchartl> regarding the missing format +11:30 < pinchartl> was it the tri-planar formats for the DU ? +11:30 < morimoto> Maybe, I forgot detail +11:30 < pinchartl> so did I :-) +11:31 < pinchartl> but triplanar formats support has been merged +11:31 < morimoto> OK, nice +11:31 < pinchartl> any other question regarding the requests ? +11:32 < morimoto> nothing from me. Thanks +11:32 < pinchartl> you're welcome +11:32 < pinchartl> Topic 4. Agenda for the multimedia face to face meeting in Berlin +11:32 < pinchartl> we need to start drafting the agenda +11:32 < pinchartl> I'd like everybody to propose topics by e-mail in response to the chat report I will send +11:32 < pinchartl> and you can start now if you already have ideas in mind +11:33 < morimoto> I created Wiki page. +11:33 < morimoto> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Miniperi-2016-10 +11:33 < pinchartl> thank you +11:33 < kbingham> morimoto: Could I get an account to OSDR please? +11:34 < morimoto> Oopd, I will try. Please wait +11:34 < kbingham> np. +11:34 < morimoto> Maybe it will be after tomorrow +11:34 < pinchartl> morimoto: I think you can remove "What is the current status of "Rotation + ImagePertition" ?" and "Z-order" from the wiki page +11:34 < pinchartl> Z-order has been merged +11:34 < pinchartl> and patches for rotation + image partition have been posted yesterday +11:34 < morimoto> OK, but BSP team want to check it. keep it and set "finish" is help for me +11:35 < pinchartl> ok +11:35 < morimoto> s/help/helpful +11:35 < pinchartl> Topic 5. Next meeting +11:35 < neg> If possible I would like to talk about more pad aware v4l2 operations to you and Hans duinrg the mini multimedia summit (and to whom ever else is interessted ofc), but for periperi multimedia I think we talked about it in Tokyo +11:36 < pinchartl> neg: that's a good idea. could you propose that by e-mail to Hans ? +11:36 < neg> will do +11:37 < pinchartl> thanks +11:37 < pinchartl> I will attend Kernel Recipes in Paris in two weeks +11:37 < pinchartl> so I won't be available Wednesday-Friday +11:37 < pinchartl> and neither will I be available on Monday that week +11:38 < pinchartl> we could move the meeting to Tuesday, but that would conflict with the core meeting +11:38 < pinchartl> unless we move it one hour earlier, and keep it short +11:38 < pinchartl> another option is to hold the meeting on Wednesday without me +11:38 < pinchartl> thoughts ? +11:39 < morimoto> Wednesday = 28th ? +11:39 < pinchartl> yes +11:39 < neg> short meeting before core works for me, I think you should be in the meeting if possible +11:40 < pinchartl> given that it will be the last one before Berlin, I'd like to attend it, yes +11:40 < pinchartl> we'll keep the status update very short +11:40 < pinchartl> and focus on the agenda for the Berlin meeting +11:41 < pinchartl> so that would be 2016-09-27 at 08:00 BST / 09:00 CEST / 10:00 +11:41 < pinchartl> EEST / 16:00 JST +11:42 < neg> works for me +11:42 < morimoto> I booked +11:42 < uli___> ok +11:44 < pinchartl> thank you +11:44 < pinchartl> that's it for today +11:44 < pinchartl> thank you all for joinin diff --git a/wiki/Chat_log/20160921-io-chatlog b/wiki/Chat_log/20160921-io-chatlog new file mode 100644 index 0000000..3b210f8 --- /dev/null +++ b/wiki/Chat_log/20160921-io-chatlog @@ -0,0 +1,337 @@ +--- Log opened Wed Sep 21 09:27:21 2016 +09:27 -!- wsa_ [~wsa@p5B384463.dip0.t-ipconnect.de] has joined #periperi-io +09:27 -!- Irssi: #periperi-io: Total of 4 nicks [0 ops, 0 halfops, 0 voices, 4 normal] +09:27 -!- Irssi: Join to #periperi-io was synced in 0 secs +09:27 < wsa_> hi guys! +09:29 < khiemnguyen_> hello +09:30 -!- shimoda [~shimoda@relprex3.renesas.com] has joined #periperi-io +09:30 -!- horms [~horms@217.111.208.18] has quit Quit: Leaving +09:30 -!- horms [~horms@217.111.208.18] has joined #periperi-io +09:31 -!- neg [~neg@unaffiliated/neg] has joined #periperi-io +09:32 < morimoto> hi +09:32 < neg> hello everyone +09:32 < shimoda> hi +09:33 < wsa_> morimoto: before we start, can you also keep an eye that either Magnus or you bring me a ZComex AC-180M SDIO card to Berlin? +09:34 < wsa_> I need it for an additional task +09:34 < wsa_> I think Shimoda-san used it for testing +09:35 < wsa_> I already asked Magnus. He recommended to ask you as well, so it will be less likely forgotten ;) +09:35 < morimoto> Magnus recommended to me ? +09:35 < morimoto> OK, will check +09:36 < morimoto> I will bring it to you on Berlin +09:36 < wsa_> well, if two people know about it, they can remind each other ;) +09:36 < wsa_> so, let's start +09:36 * wsa_ runs sort -R +09:37 -!- geertu [~geert@d54c189fd.access.telenet.be] has joined #periperi-io +09:37 < geertu> Hi +09:38 < wsa_> hi geert +09:38 < horms> nice to see you +09:38 < wsa_> shimoda: you won first place this time :) +09:39 < shimoda> yes +09:39 < shimoda> A) What have I done since last time: +09:39 < shimoda> - IPMMU issue on USB EHCI + Gen3. +09:39 < shimoda> B) What I plan to do till next time: +09:39 < shimoda> - IPMMU issue on USB EHCI + Gen3. +09:39 < shimoda> C) Problems I have currently: +09:39 < shimoda> - Nothing except the IPMMU issue. +09:39 < shimoda> i have trouble about the IPMMU :) +09:39 < shimoda> done +09:40 < wsa_> Yeah, that looks like a major one +09:40 < wsa_> any news from HW guys? +09:42 < wsa_> ah, i think you said last time that he didn't find anything +09:42 < shimoda> I got a little. but, they said it seems strorange behavior by usb EHCI hw. so, i would like to investigate EHCI SW or IPMMU HW/SW more +09:43 < wsa_> good luck with that!! +09:43 < wsa_> I am next +09:43 < wsa_> A) +09:43 < wsa_> added 8 bit eMMC bus width support for SDHI +09:43 < wsa_> tested SDR104 & enablement patches +09:43 < wsa_> worked on additional tasks and todo-lists +09:43 < wsa_> B) +09:43 < wsa_> organize meeting room in Berlin & IO meeting +09:43 < wsa_> some more SDR104 testing +09:43 < wsa_> start evaluating the BSP for IO patches +09:43 < wsa_> start playing with UHS SDIO cards +09:43 < wsa_> C) +09:43 < wsa_> (SDR104 is nasty) +09:43 < wsa_> c) is not really my part +09:43 < horms> I have an update on that +09:44 < wsa_> yeah, i read that :) +09:44 < horms> yes, SDR104 is a headache +09:45 < wsa_> but first morimoto +09:45 < horms> lets discuss it a bit later. either here of back on #periperi after this meeting +09:45 < wsa_> horms: sure +09:46 < wsa_> although, morimoto said he has nothing going for IO +09:46 < wsa_> khiemnguyen_: you are next +09:47 < wsa_> how is your load? do you have more time for upstreaming again? +09:47 < khiemnguyen_> wsa_: I have time for upstream, I think. +09:47 < khiemnguyen_> a) Sent updated patches for R-Car Gen3 Thermal +09:48 < khiemnguyen_> Got review from Morimoto-san and Geert. +09:48 < khiemnguyen_> Still, some comments have not been fixed yet. And failed to catch v4.9. +09:48 < khiemnguyen_> b) Continue R-Car Gen3 Thermal. It will be available before ELCE, I believe. +09:48 < khiemnguyen_> c) Still try to solve issue of my email account. Trying to use git-send-emails instead of MS Outlook email client. +09:48 < khiemnguyen_> that's all. +09:49 < wsa_> good news. i updated the todo and upstreaming thermal is now scheduled for v4.10 +09:49 < khiemnguyen_> wsa_: thanks +09:49 < morimoto> this is out-of-IO-topics. horms: can you update peripelist ? +09:50 < wsa_> good luck and I hope you can get git-send-email to run. will be much more convenient! +09:50 < wsa_> horms: you are next anyhow ;) +09:50 < horms> morimoto: I am confused. What would you like me to update? +09:50 < horms> --- start --- +09:51 < horms> A) What have I done since last time: +09:51 < horms> - Posted updated SDR104 Driver patches +09:51 < horms> - Posted updated SDR50/SDR104 enablement patches +09:51 < horms> - merged non-SDR104 portions +09:51 < horms> - Support patches for pfc, gpio, clks have been merged +09:51 < horms> B) What I plan to do till next time: +09:51 < horms> - Continue working on "Samsung SDR104 initialisation problem" +09:51 < horms> - Locally I seem to have a stack that resolves this problem, +09:51 < horms> I need to: +09:51 < horms> + Verify this and if it is so +09:51 < horms> + clean it up and isolate what needs to go upstream. +09:51 < horms> - Investigate why SDR50 can't be initialised on Gose SDHI1 +09:51 < horms> C) Problems I have currently: +09:51 < horms> - SDR headaches, see B) +09:51 < horms> --- end --- +09:51 < morimoto> horms: can you check email from me ? +09:51 < morimoto> Subject: Re: [periperi] PeriPelist fixup request 2016-09-13 for integration/upport +09:51 < morimoto> Date: Tue, 13 Sep 2016 01:54:57 +0000 +09:51 < morimoto> +09:52 < horms> sure, i will look at that +09:52 < wsa_> horms: yeah, let's talk about the technical details after this meeting here? +09:52 < horms> good plan +09:52 < wsa_> and maybe about Gose, this is a new issue, or? +09:53 < wsa_> I can't recall it at least +09:54 < geertu> Perhaps SDHI is wired differently on Gose? +09:54 < horms> i think we can regard it as a minor issue +09:54 < horms> its not so new to me +09:54 < geertu> We don't seem to have schematics... +09:54 < horms> but i may not have raised it to you before +09:54 < horms> I believe I do have them +09:54 < horms> The problem is that SDR%0 is not initialised on SDHI1 +09:54 < horms> I had magnus move the card to SDHI2 and it seems fine there +09:55 < horms> I think it is most likely there is an error in the code somewhere +09:55 < morimoto> geertu: I will send Gose schematics soon +09:55 < morimoto> It is under export paper work +09:55 < horms> Also, I wasn't entirely sure on some of the GPIOs, so a second pair of eyes on the schematic would help +09:55 < geertu> horms: it's not due to some silly SDHIx naming issue? Indices are different on H2 and M2-W. +09:55 < geertu> IIRC, we did it slightly different on M2-N? +09:55 < horms> I am aware of that +09:56 < horms> no I don't think that is the problem here +09:56 < geertu> morimoto: Thank you +09:56 < horms> the documentation is a little inconsistent with its usage of sd1/sd2 +09:56 < horms> but I think its clear enough given some context +09:57 < wsa_> ok? +09:58 < horms> I'm ok +09:58 < wsa_> good :) +09:58 < wsa_> neg: I know you don't have anyhthing IO related, but can you tell me if you have time for base task assignments in the near future? +09:59 < neg> I think I should have time for that +09:59 < neg> I do not yet have a base contract for Q4 but other than that it should be fine :-) +09:59 < wsa_> same here:D +10:00 < wsa_> ok, so then let's move on to Geert +10:00 < neg> any particular task you think I should get started on? +10:00 < wsa_> neg: I'll ask Geert in a second ;) +10:01 < wsa_> geertu: your turn +10:01 < geertu> A) What have I done since last time: - SPI slave support v2, http://elinux.org/Tests:MSIOF-SPI-Slave +10:01 < wsa_> (let's see if the alerting for irssi I sent him recently works ;)) +10:01 < geertu> B) What I plan to do till next time: +10:01 < geertu> - No I/O tasks scheduled, but core 64-bit Memory and Ethernet without +10:01 < geertu> Bounce Buffers Prototype, +10:01 < geertu> - Awaiting SPI slave feedback, +10:01 < geertu> - Verify MSIOF SPI functionality on M3-W, if time permits. +10:01 < geertu> C) Problems I have currently: - Nothing I/O related. +10:02 < geertu> First SPI slave feedback is from RobH, who seem to want to revert partly to v1, while I made the changes due to his request ;-) +10:02 < wsa_> heh +10:03 < wsa_> this task: +10:03 < wsa_> SCIF,?,noplan,?,difference in behavior between hardware-assisted flow control and GPIO flow control # Cfr. the thread "[PATCH] sh-sci: fix transition from noflow to HW flow control" +10:03 < wsa_> do you think this could be a investigation suited for a base task +10:03 < wsa_> or is it rather an additional task on its own? +10:03 < geertu> Perhaps I can look into that in the context of the (not yet confirmed) base task +10:04 < wsa_> if you have time... +10:04 < wsa_> ... this is the one where I wondered if neg could have a look if he had interest. +10:04 < geertu> I think it's to be investigated first, whether it's a bug in the driver, on in the serial core. +10:05 -!- horms [~horms@217.111.208.18] has quit Read error: Connection reset by peer +10:05 < geertu> s/on/or/ +10:05 -!- horms [~horms@217.111.208.18] has joined #periperi-io +10:06 < geertu> I have a hardware setup to test it, so perhaps I should just fine some time to bite the bullet +10:06 < geertu> s/fine/find/ +10:06 < wsa_> i see +10:06 < wsa_> makes sense +10:08 < wsa_> i think we are done now? +10:08 < wsa_> anything from you? +10:08 < wsa_> next meeting will be in Berlin +10:09 < wsa_> if you have topics for that please let me know +10:09 < wsa_> additional tasks will be an obvious one +10:10 < horms> Have we fixed the meeting schedule for Berlin? +10:10 < wsa_> i think so +10:11 < horms> Excellent +10:11 < wsa_> now that the core group decided to have their meeting in two parts... +10:11 < horms> I want to be sure to be there at the right time :) +10:11 < horms> Shall we talk SDR? +10:11 < wsa_> yes, I am very curious on that topic +10:12 < wsa_> but before +10:12 < wsa_> Thanks guys for the meeting! +10:12 < wsa_> Have a safe trip to Berlin! +10:12 < neg> thanks all +10:12 < khiemnguyen_> Please take a photo, as well. +10:13 < morimoto> thanks. +10:13 < shimoda> thanks. +10:13 < geertu> Has anyone found the big group photo taken at the closing of LCJ? +10:13 < horms> thanks +10:14 < morimoto> geertu: like this one ? +10:14 < morimoto> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Miniperi-2016-07 +10:14 < khiemnguyen_> geertu: https://osdr.renesas.com/projects/linux-kernel-development/wiki/Miniperi-2016-07 +10:15 < morimoto> It is shrink version, I have original photo +10:15 < geertu> morimoto: No, the big one with +100 persons +10:15 < morimoto> Ahh, I don't have it. +10:16 < horms> wsa_: I think I am making some progress on the "Samsung problem" +10:16 < horms> as I mentioned in my email +10:16 < horms> but there have been so many false dawns on sdr104 I'd rather not push out v8 in a hurry, even though v4.9 is closing soon +10:17 < horms> what I was hoping was to get something clean toghether in the next day or so for you to test. +10:17 < wsa_> morimoto: haha, haven't seen those pictures before +10:17 < horms> or alternatively find out its not working after all (not unlikely given my experiences so far) +10:18 < wsa_> horms: yes, I agree we should test more internally before sending out a new version +10:18 < wsa_> horms: I'd also test unclean stuff ;) just to see if I can reproduce your findings +10:18 < horms> I at least have physical access to a system where I can reprocuce the current problem (The Samsung one) +10:18 < wsa_> anyway, I'm happy that you at least have a pointer +10:19 < horms> thanks, I'll see if I can get something semi-clean together +10:19 < horms> there is quite a bit of noise in my current stack +10:19 < wsa_> any high-level description of the suspect? +10:19 < horms> but one thing that stood out was the NO_SLEEP handling in the BSP +10:19 < horms> which skips sleeping for 10ms on GEN3 +10:20 < horms> Assuming we need such a thing, which at this point seems likely +10:20 < horms> I wonder how it should be handled +10:20 < horms> * Using a NO_SLEEP cap as per the BSP +10:20 < horms> * Using a (new) GEN3 cap (like the GEN2 cap in mainline - which is actually GEN2/3) +10:20 < horms> * Some other way +10:21 < wsa_> NO_SLEEP? gotta check +10:22 < horms> I also noticed that SH_MOBILE_SDHI_SCC_RVSCNTL_RVSEN should be BIT(0) rather than BIT(1). Which clearly should be fixed. But its not clear if it relates to the problem under discussion. +10:22 < horms> I also flagged the following as interesting but have not yet been able to confirm if they related to the problem in question: +10:23 < horms> * mmc: tmio: Add SDCLK enable after reset +10:24 < horms> * clk: renesas: rcar-gen3: Replace SD divider setting +10:24 < horms> From the BSP +10:24 < horms> The first patch seems like a mainline candidate +10:24 < horms> the second I am rather unsure about +10:25 < horms> Other than that my strategy has been to try to reduce differences between the BSP and mainline+sdr topic branch. +10:25 < horms> That seems to be working, I need to work out which of those changes, which are rather verbose, are of consequence +10:25 < wsa_> that's what I did to fix 8 bit eMMC support as well +10:25 < horms> thats the bit I'D like to clean up a bit +10:25 < horms> really its too noisy to give you right now +10:26 < wsa_> I think we have the same NO_SLEEP behaviour upstream as in the BSP? +10:26 < wsa_> that was at least my intention, let me double check +10:26 < horms> It didn't seem to be in the branch I was working against +10:26 < horms> I did see some differentiation between GEN2 and non-GEN2 for one of the timeouts +10:26 < horms> but nothing for others +10:27 < wsa_> bsp does: +10:27 < wsa_> 172 if (!(host->pdata->flags & TMIO_MMC_CLK_NO_SLEEP)) +10:27 < wsa_> 173 msleep(10); +10:28 < wsa_> upstream does +10:28 < wsa_> 160 msleep(host->pdata->flags & TMIO_MMC_MIN_RCAR2 ? 1 : 10); +10:28 < horms> ok, but the BSP does it in several places +10:28 < wsa_> so, the timeout is reduced from 10 to 1 ms +10:29 < wsa_> and bsp for gen3 does 0 +10:29 < horms> in any case, i can do some more testing of this +10:30 < horms> btw, which samsung card do you have. I have a "Pro+" 32Gb. I can look up the product id if you like. +10:31 < wsa_> let me check +10:33 < wsa_> it is labelled "32 pro" +10:33 < horms> http://www.samsung.com/de/consumer/memory-storage/memory-storage/memory-cards/MB-SD32D/EU +10:33 < horms> Is it grey and white? +10:34 < horms> A bit like this? https://www.amazon.co.jp/Samsung-SDXC%E3%82%AB%E3%83%BC%E3%83%89-SAMSUNG-Class10-%E6%9C%80%E5%A4%A7%E8%AA%AD%E5%87%BA%E9%80%9F%E5%BA%A690MB/dp/B019FKR6QQ +10:35 < wsa_> so, no "+" for me +10:35 < wsa_> http://www.samsung.com/de/consumer/memory-storage/memory-storage/memory-cards/MB-MG32E/EU +10:35 < wsa_> it is grey and white +10:35 < horms> Ok +10:35 < horms> I have some of them in Japan +10:36 < horms> I thought I sent one to my new home too, but I can't locate it +10:36 < horms> I noticed these things seem to be much more expsnsive here than in Japan +10:36 < horms> I might just post some to myself :) +10:37 < horms> But I digress +10:37 < horms> its good to know you have a different card +10:37 < horms> but I think for now we are seeing the same problem +10:37 < wsa_> so, the gen2 bsp does not use msleep as well +10:38 < wsa_> i decided to use 1 ms because the datasheet has +10:38 < wsa_> "After waiting for at least 1 ms since the SD clock supply was started , check that the DAT0 bit in +10:38 < wsa_> SD_INFO2 is 1." +10:38 < wsa_> in the Gen2 docs +10:38 < wsa_> checking gen3 docs +10:39 < horms> I just noticed that the NO_SLEEP change was added to the Gen3 BSP specifically for r8a7795 support (presumably r8a7796 was not on the todo list at the time) +10:39 < horms> Possibly 1ms is ok, possibly it is not +10:39 < horms> Lets try to get some sort of semi clean patch stack together that wrosk +10:39 < horms> works +10:39 < wsa_> yeah +10:39 < horms> and then we can invistigate this in more depth +10:40 < wsa_> but it is nice to know that this is a difference to the BSP +10:40 < wsa_> I wasn't aware of that +10:40 < horms> at this point I think we may have several issues to discuss +10:40 < wsa_> unlike this patch I am aware of: +10:41 < wsa_> mmc: tmio: Add SDCLK enable after reset +10:41 < horms> What is your thoguths on that one? +10:41 < horms> What are your thoughts on that one? +10:41 < wsa_> but I haven't seen making any difference on any issue I have seen so far +10:41 < wsa_> I don't know if this a angst-patch or a real one +10:41 < morimoto> bye +10:41 -!- morimoto [~user@relprex2.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +10:42 < wsa_> it is a good candidate to tell about the importance of commit messages +10:42 < wsa_> "not so much what but especially why" +10:43 < horms> ok +10:43 < horms> we/I can raise this with the bsp team +10:43 < horms> I'll check if it helps or not +10:43 < horms> it is in my stack at the moment +10:44 < horms> possibly we would get better commit messages if there was a policy to allow them to be partially in Japanese +10:44 < horms> but that could also backfire +10:45 < wsa_> stuff like +10:45 < wsa_> "fixes customer issue" vs "is more correct" already helps IMO +10:45 < horms> Ok, so this actually relates to the upporting tasks +10:45 < wsa_> or "do as described in docs" +10:45 < horms> which Magnus was discussing with us +10:46 < wsa_> yes +10:46 < horms> We could produce some guidelines to help get better information +10:46 < horms> probably part of the problem is who is the audience for the changelog +10:46 < horms> * The BSP team? +10:46 < horms> * The upstream team? +10:46 < horms> * Mainline iself? +10:46 < horms> * Customers? +10:47 < horms> * Other? +10:47 < horms> I would be interesting to see what the intended audience is: if any +10:47 < horms> but i think regardless it would be good to provide some guidance +10:47 < shimoda> sorry, time to go. bye! +10:47 -!- shimoda [~shimoda@relprex3.renesas.com] has quit Quit: WeeChat 0.4.2 +10:47 < wsa_> I dunno about customers, but BSP team and upporting team for sure +10:48 < wsa_> mainline not so much +10:48 < horms> I think they are the most important +10:48 < wsa_> I'd say +10:48 < wsa_> but for all of the groups, I'd think the "why" is pretty important +10:49 < horms> true +10:49 < wsa_> and the patch we just mentioned is a good example for that +10:49 < horms> ok +10:49 < horms> I think we can query specific patches by contactng their author +10:50 < horms> but in terms of a general request I'd shy away from specific examples: we don't want anyone in the BSP team to give less information for fear or being made an example of +10:50 < wsa_> i agree +10:50 < geertu> The "why" is very important. For several commits in the BSP, I'm completely puzzled by the rationale behind them. +10:50 < horms> i agree +10:51 < wsa_> luckily, it is pretty easy to cook an artifical example +10:51 -!- uli___ [~uli@gateway/vpn/privateinternetaccess/uli/x-17929268] has joined #periperi-io +10:51 < horms> So how about I try to bring this up with the BSP team at the meeting they invite me to sometimes. +10:51 < wsa_> hi uli___ +10:51 < uli___> hello +10:51 < wsa_> got internet again? :) +10:51 < uli___> figured out why my desktop keeps locking up +10:51 < uli___> turns out you can't turn off displayport devices in linux... +10:52 < uli___> switched to dvi -> works +10:52 < horms> good to know +10:52 < wsa_> horms: gotta run now +10:53 < horms> likewise +10:53 < wsa_> looking forward to your semi-cleaned up stack +10:53 < horms> thanks for your time +10:53 < wsa_> to test +10:53 < wsa_> you're welcome +10:53 < horms> i'll get that too you in the coming days: or some disapointed email explaining that its not working +10:53 < wsa_> oh, and I'll bring all my cards to Berlin, of course +10:53 < horms> oh. great +10:53 < wsa_> Magnus shall do the same +10:54 < wsa_> so, cya all! +10:54 < horms> bye +10:55 < uli___> bye +10:57 < wsa_> uli___: BTW can you respin the MSIOF chipselect patch? +10:58 < uli___> yes, that's on the todo +10:58 -!- horms [~horms@217.111.208.18] has quit Ping timeout: 244 seconds +11:05 < wsa_> cool +--- Log closed Wed Sep 21 11:05:52 2016 diff --git a/wiki/Chat_log/20160927-core-chatlog b/wiki/Chat_log/20160927-core-chatlog new file mode 100644 index 0000000..7164c8b --- /dev/null +++ b/wiki/Chat_log/20160927-core-chatlog @@ -0,0 +1,341 @@ +2016-09-27 Renesas Core Group Chat Invitation + +Time: Tuesday, September 27, 17h00-18h30 JST / 10h00-11h30 CEST +Location: #periperi @ chat.freenode.net + +Agenda: +1. Status updates +2. PFC and CPG codes of R-Car H3 ES2.0. +3. R-Car hwspinlock driver + +-------------------------------------------------------------------------------- + +Topic 1. Status updates + + A) What have I done since last time + + Geert: + - Resumed SoC identification and ESx.y handling + Khiem: + - Nothing yet + Still struggle to solve issue of git-send-emails via company proxy. + Magnus: + - Updated boot loader, IPMMU and audio hacking, accidentally boot tested + IPMMU and EtherAVB with new boot loader. Updated IPMMU patches. + Morimoto: + - Basically no Core task. + - Checking V3 patch permission. + - Checking about RZ/G ID + Niklas: + - Solved my issue for PFC drive strength on H3 and posted the patches + Ulrich: + - Submitted SYS-DMAC enablement for M3-W, plus I2C and (H)SCIF to + actually have something to enable it for... + + + B) What I plan to do till next time + + Geert: + - Review Niklas' drive strength patches + - Continue RST, MODEMR, ES-handling, ... + - 64-bit memory with M3-W Ethernet + Khiem: + - Complete CPUFreq (Z-clock change) + I will make sure the patches are available and send out during this weekend. + Magnus: + - Focus on upstreaming of IPMMU code. + Morimoto: + - Clarify V3 patch permission + - Clarify RZ/G ID + Niklas: + - Fix Sergei's minor comment on PFC and wait for more comments/Acks + - Post v2, if there is time start on PFC work for M3-W + Shimoda: + - Describe lossy infor into eLinux... + Simon: + - Verify Suspend-to-RAM on M3-W using 2.12 firmware + + + C) Problems I have currently + + Magnus: + - Lack of time. + Morimoto: + - Berlin trip wrapping + +-------------------------------------------------------------------------------- + +Topic 2. PFC and CPG codes of R-Car H3 ES2.0. + +The BSP team asked me about PFC and CPG codes of R-Car H3 ES2.0. +They would like to know the policy of upstream team until mid of October +because they will start ES2.0 development from this timing. + + - How to create the R-Car H3 ES2.0's PFC and CPG codes? + - Do we add the ES2.0 code to pfc-r8a7795.c and r8a7795-cpg-mssr.c? + Or, do we make new files for the ES2.0? + - Or, other ideas? + + a. CPG/MSSR + - Add ES2.0 clocks to end of + include/dt-bindings/clock/r8a7795-cpg-mssr.h + - Use soc_device_match() to detect r8a7795 ES1.* and + - select r8a7795_es1 tables instead of r8a7795 (= latest) tables, + - OR modify r8a7795 tables (TBD). + b. PFC + - r8a7795 ES2.0 PFC is (almost) identical to r8a7796 PFC. + Can it be merged? + - Similar to CPG/MSSR: + - sh_pfc_soc_operations.init() uses soc_device_match() to detect + r8a7795 ES1.* and select r8a7795_es1 or r8a7795 tables + - Needs ordering change. Current ordering is: + 1. soc_bus_register is core_initcall + 2. sh_pfc_init is postcore_initcall + (drivers/pinctrl < drivers/soc) + 3. renesas_soc_init is postcore_initcall + (cannot be core_initcall because drivers/soc < drivers/base) + + Note: Do we want to make ES1.x support configurable? + If yes, it may make sense to use separate source files. + +-------------------------------------------------------------------------------- + +Topic 3. R-car hwspinlock driver + +BSP team would like to do upstream about the hwspinlock driver for R-Car. +The driver is already merged into the latest Gen3 BSP: +https://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git/commit/drivers/hwspinlock?h=rcar-3.3.2&id=22d88d4eddb5a0fec485e717a65f218275f6b26b + +I don't know the spec of this driver. But, they have concerns about the driver. + - The driver uses "core_initcall" to control PFC driver. + Is it acceptable in Upstream? + - This topic is not related to upstreaming, but the driver cannot handle the + CPG driver because this driver also need the CPG. + +Do you think we can upport this driver as well? +Or, do we need an additional task for it anyway? + +I checked this BSP patch roughly, and the patch should have a DT doc. +(commit e4d2c3213280a6985395970cbf26e7ef381dd1d5) + + - The driver uses platform_driver_register() from a core_initcall(). + As the CPG/MSSR driver uses subsys_initcall(), the hwspinlock driver + probe will be deferred. + - No current users of hwspin? What's the plan? + - Shimoda-san will ask the BSP team + - Used for synchronisation with CR7 core + + +-------------------------------------------------------------------------------- +Core-chat-meeting-2016-09-27 +-------------------------------------------------------------------------------- + +10:03 < geertu> Welcome to today's Core Group Chat! +10:04 < geertu> Magnus is excused (Japanese > Core Work) +10:04 < geertu> Khiem seems to be stuck in Outlook without IRC capability? +10:05 * geertu sort -R members +10:05 < geertu> Oops, first is Khiem +10:05 < geertu> Next is Simon +10:06 < horms> --- start --- +10:06 < horms> A) What have I done since last time +10:06 < horms> * No core tasks at this time +10:06 < horms> B) What I plan to do till next time +10:06 < horms> * Verify Suspend-to-RAM on M3-W using 2.12 firmware +10:06 < horms> C) Problems I have currently +10:06 < horms> * None +10:06 < horms> --- end --- +10:06 < geertu> Thanks Simon +10:06 < geertu> Next is Morimoto-san +10:06 < morimoto> Basically I have no Core task. About RZ/G series, it is mass production version of R-Car chip. The reason why it has different naming is business paper work reason (R-Car consortium, etc). So, basically, R-Car and RZ/G can have same ID, but I'm confirming about this. +10:06 < morimoto> About "V3". +10:06 < morimoto> H3/M3 are under AIS team's (= our main group) product chip. This means WE can control H3/M3. Now we already have "M3" on upstream, even though, M3 press release was not yet happen. But "V3" is not our (= AIS team) product chip. And V3 might not use Linux on it. Don't know detail at this point. So now, we don't know how we control it. Now Munakata-san is considering about it. +10:06 < morimoto> --end-- +10:07 < geertu> Oops, forgot the agenda +10:07 < geertu> Agenda: +10:07 < geertu> 1. Status updates +10:07 < geertu> 2. PFC and CPG codes of R-Car H3 ES2.0. +10:07 < geertu> 3. R-Car hwspinlock driver +10:07 < geertu> ;-) +10:07 < geertu> Thanks, Morimoto-san +10:08 < horms> thanks Moriomoto-san, can I ask what "same id" means? +10:08 < geertu> Next is Ulrich +10:08 < geertu> Same ID in PRR register +10:08 < uli___> A) Submitted SYS-DMAC enablement for M3-W, plus I2C and (H)SCIF to +10:08 < geertu> I.e. we cannot distinguish between RZ/G and R-Car Gen2 at runtime +10:08 < uli___> actually have something to enable it for... +10:08 < horms> thanks +10:08 < uli___> B) Nothing so far. +10:08 < uli___> C) None. +10:09 < geertu> Thanks Ulrich +10:09 < geertu> Next is Laurent +10:09 < morimoto> horms: it means, form Product ID point of view, RZ/G and R-Car are same. (and maybe HW is same) +10:09 < pinchartl> nothing for me, no core task +10:09 < horms> 承知致します。 +10:09 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi +10:10 < geertu> Thanks Laurent +10:10 < geertu> Welcome Khiem! +10:10 < khiemnguyen> Hello all +10:10 < geertu> khiem: We're into status updates. +10:10 < geertu> Next is Khiem +10:11 < khiemnguyen> ok +10:11 < khiemnguyen> a) Nothing yet. +10:11 < khiemnguyen> Still struggle to solve issue of git-send-emails via company proxy. +10:11 < khiemnguyen> b) Complete CPUFreq (Z-clock change) +10:11 < khiemnguyen> I will make sure the patches are available and send out during this weekend. +10:11 < khiemnguyen> c) None. +10:12 < geertu> Thanks Khiem +10:12 < geertu> Next is Shimoda-san +10:12 < shimoda> A) What have I done since last time: +10:12 < shimoda> - Nothing for core group task. +10:12 < shimoda> B) What I plan to do till next time: +10:12 < shimoda> - describe lossy infor into eLinux... +10:12 < shimoda> C) Problems I have currently: +10:12 < shimoda> - Nothing for core group task. +10:12 < shimoda> --- end --- +10:13 < geertu> Thanks Shimoda-san +10:13 < geertu> Next is Geert +10:13 < geertu> A) - Resumed SoC identification and ESx.y handling +10:13 < geertu> B) - Review Niklas' drive strength patches +10:13 < geertu> - Continue RST, MODEMR, ES-handling, ... +10:13 < geertu> - 64-bit memory with M3-W Ethernet +10:13 < geertu> C) - Nothing +10:13 < geertu> --- end --- +10:14 < geertu> Next is Niklas +10:14 < neg> a) Solved my issue for PFC drive strength on H3 and posted the patches +10:14 < neg> b) Fix Sergis minor comment on PFC and wait for more comments/Acks post v2, if there is time start on PFC work for M3-W +10:14 < neg> c) None +10:14 < neg> --- end --- +10:15 < geertu> Thanks Niklas +10:15 < geertu> Topic 2. PFC and CPG codes of R-Car H3 ES2.0. +10:15 < geertu> From Shimoda-san: +10:15 < geertu> The BSP team asked me about PFC and CPG codes of R-Car H3 ES2.0. +10:15 < geertu> They would like to know the policy of upstream team until mid of October +10:15 < geertu> because they will start ES2.0 development from this timing. +10:15 < geertu> - How to create the R-Car H3 ES2.0's PFC and CPG codes? +10:15 < geertu> - Do we add the ES2.0 code to pfc-r8a7795.c and r8a7795-cpg-mssr.c? +10:15 < geertu> Or, do we make new files for the ES2.0? +10:15 < geertu> - Or, other ideas? +10:15 < geertu> ---end--- +10:16 < geertu> I had already given this some thought +10:16 < geertu> a. CPG/MSSR +10:16 < geertu> - Add ES2.0 clocks to end of include/dt-bindings/clock/r8a7795-cpg-mssr.h +10:16 < geertu> - Use soc_device_match() to detect r8a7795 ES1.* and +10:16 < geertu> - select r8a7795_es1 tables instead of r8a7795 (= latest) tables, +10:16 < geertu> - OR modify r8a7795 tables (TBD). +10:16 < geertu> Does that make sense? +10:17 < pinchartl> that sounds good to me +10:17 < pinchartl> how big is the diff between ES1.* and ES2.0 when it comes to CPG ? +10:18 < geertu> I haven't gone through all changes, but for CPG, I think it's just a few additional clocks +10:18 < geertu> For MSTP, some modules changed their parent clocks +10:18 < geertu> Other modules disappeared (e.g. VSP) +10:19 -!- horms [~horms@217.111.208.18] has quit [Read error: Connection reset by peer] +10:19 < geertu> For CPG, it may even become identical to r8a7796. But as the defines are different, we can't just reuse the table. +10:20 < pinchartl> ok +10:20 -!- horms [~horms@217.111.208.18] has joined #periperi +10:21 < geertu> b. PFC +10:21 < geertu> - r8a7795 ES2.0 PFC is (almost) identical to r8a7796 PFC. +10:21 < geertu> Can it be merged? +10:21 < geertu> - Similar to CPG/MSSR: +10:21 < geertu> - sh_pfc_soc_operations.init() uses soc_device_match() to detect +10:21 < geertu> r8a7795 ES1.* and select r8a7795_es1 or r8a7795 tables +10:21 < geertu> - Needs ordering change. Current ordering is: +10:21 < geertu> 1. soc_bus_register is core_initcall +10:21 < geertu> 2. sh_pfc_init is postcore_initcall +10:21 < geertu> (drivers/pinctrl < drivers/soc) +10:21 < geertu> 3. renesas_soc_init is postcore_initcall +10:21 < geertu> (cannot be core_initcall because drivers/soc < drivers/base) +10:22 < geertu> Does that make sense? +10:23 < pinchartl> what are the new initcalls you're proposing there ? +10:23 < horms> Sorry, could you repost what came before b? I am suffering from post-brexit wifi trauma +10:24 < morimoto> horms: I will send it by email, OK ? +10:24 < horms> morimoto: I got it from geert, thanks +10:24 < morimoto> OK +10:25 < morimoto> Is it possible to exchange initcall order ? I got NAK from maintainer before... +10:26 < geertu> As changing initcalls and order in drivers/Makefile is always very complicated, I'm thinking of making renesas_soc_init() a core_initcall anyway, and letting soc_device_register() initialize the soc_bus if that hasn't been done yet. +10:27 < pinchartl> anything that touches initcall ordering seems hacky to me, but I'll let others complain this time :-) +10:27 < geertu> If you just call soc_device_register() before soc_bus_register() has happened, it crashes with a nice NULL pointer dereference +10:28 < geertu> Does it still sound reasonable? +10:29 < pinchartl> I've seen worse :-) +10:29 < geertu> One other thing: Do we want to make ES1.x support configurable? +10:30 < geertu> If yes, it may make sense to use separate source files. +10:30 < shimoda> geertu: BSP team wants to be single binary +10:31 < morimoto> single binary, but support ES1.x and ES2.0. correct ? +10:31 < shimoda> if separate source files, we can build a single binary to support both es1 and 2? +10:31 < geertu> shimoda: of course +10:31 < shimoda> morimoto: yes +10:31 < horms> Single binary is a hard requirement from my pov :) +10:31 < geertu> shimoda: I meant, do we want CONFIG_ARCH_R8A7795_ES1? +10:31 < pinchartl> geertu: I believe our long term goal should be to remove it, so I'd like to see the code developed in a way that wouldn't make that too difficult. it doesn't need to be in seperate files for me though +10:32 < geertu> pinchartl: I agree +10:32 < pinchartl> and I'd actually like to consider the opposite of your question as well: do we want to remove CONFIG_ARCH_R8A7795 at some point ? +10:32 < pinchartl> but that's another topic +10:33 < horms> what would be the motivation for removing it? +10:33 < geertu> pinchartl: You mean make it unconditional, hence enabling CONFIG_ARCH_RENESAS enables all Renesas arm64 SoCs? +10:34 < pinchartl> geertu: correct +10:34 < geertu> pinchartl: That's what the arm64 maintainers would like, right? +10:34 < pinchartl> yes +10:34 < horms> probably the current arrangment is partly due to historical reasons +10:34 < horms> i wonder if there is an advantage to keeping the current arrangment +10:34 < pinchartl> I'm not advocating for that, but I believe we should at least consider the option +10:35 < horms> e.g. to allow not carring so many pfc tables in the kernel binary if desired +10:35 < geertu> So your kernel will always include full PFC tables for r8a7795_es1, r8a7795, r8a7796, r8a7797 (I predict that'll be the name of V3M ;-)? +10:35 < pinchartl> kernel bloat is my concern too +10:38 < geertu> OK, let's see later +10:39 < geertu> shimoda: Are H3 ES2.0 boards already available? +10:39 < shimoda> shimoda: not yet, perhaps end of this year or ealry next year +10:40 < morimoto> It will goes to Magnus's remote machine. +10:40 < geertu> shimoda: You said the BSP team will start working on it Oct/M +10:40 < morimoto> Your available board will be next Feb or later ? +10:40 < geertu> So by then we should have something basic ready? But we can't test it? +10:41 < shimoda> geertu: yes. they will start it without actual board :) +10:41 < morimoto> Renesas magic! +10:42 < horms> Do they also code with their eyes shut? +10:43 < geertu> touch typing +10:43 < horms> of course +10:45 < geertu> shimoda: Are you happy with the answer so far? +10:46 < shimoda> geertu: about CPG, i understood it, but about PFC, i don't understand yet +10:47 < shimoda> separate file or into the exist file? +10:48 < shimoda> or we need more discusstion? +10:48 < geertu> shimoda: As the PFC data is quite big, I think separate files are OK +10:48 < geertu> Except if we can actually just use the r8a7796 tables. I have to check if that would cause ill effects. +10:49 < shimoda> geertu: OK. I also think of that. So, I will fowared this infor to the BSP team. Thanks! +10:49 < geertu> Thanks! +10:49 < geertu> Topic 3. R-car hwspinlock driver +10:49 < geertu> Also from Shimoda-san: +10:50 < geertu> BSP team would like to do upstream about the hwspinlock driver for R-Car. +10:50 < geertu> The driver is already merged into the latest Gen3 BSP: +10:50 < geertu> https://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git/commit/drivers/hwspinlock?h=rcar-3.3.2&id=22d88d4eddb5a0fec485e717a65f218275f6b26b +10:50 < geertu> I don't know the spec of this driver. But, they have concerns about the driver. +10:50 < geertu> - The driver uses "core_initcall" to control PFC driver. +10:50 < geertu> Is it acceptable in Upstream? +10:50 < geertu> - This topic is not related to upstreaming, but the driver cannot handle the CPG driver +10:50 < geertu> because this driver also need the CPG. +10:50 < geertu> Do you think we can upport this driver as well? +10:50 < geertu> Or, do we need an additional task for it anyway? +10:50 < geertu> I checked this BSP patch roughly, and the patch should have a DT doc. +10:50 < geertu> ---end--- +10:50 < geertu> DT doc is commit e4d2c3213280a6985395970cbf26e7ef381dd1d5 +10:50 < geertu> I have two comments here: +10:50 < geertu> 1. The driver uses platform_driver_register() from a core_initcall(). +10:50 < geertu> As the CPG/MSSR driver uses subsys_initcall(), the hwspinlock driver probe will be deferred. +10:51 < geertu> So it will probably be initialized earlier (without deferred probe), if it would use another initcall +10:51 < geertu> it = hwspinlock driver +10:52 < geertu> 2. There are no current users of hwspin in the BSP? What's the plan? +10:53 < shimoda> geertu: about the plan, i don't know. So, I will ask the BSP team later +10:54 < geertu> "the driver cannot handle the CPG driver because this driver also need the CPG/" +10:54 < geertu> Does that mean they woild like to use hwspinlock in the CPG driver? +10:55 < geertu> s/woild/would/ +10:56 -!- horms [~horms@217.111.208.18] has quit [Ping timeout: 244 seconds] +10:58 < shimoda> geertu: this means the hwspin driver calls pm_runtime APIs +10:58 < shimoda> about the driver, I asked BSP team now +10:59 < geertu> OK, thanks! +10:59 < shimoda> this driver will be used if other CPU core (CR7) also runs +10:59 < geertu> IC +11:00 < geertu> Any other topics people want to discuss? +11:00 < shimoda> but, a plan is not clear, they would like to skip upporting of this driver for now +11:02 < geertu> Next meeting will be in Berlin +11:02 < geertu> If you have topics for the meeting, please let me (and periperi) now! +11:02 -!- horms [~horms@217.111.208.18] has joined #periperi +11:02 < geertu> There are already some topics listed at https://osdr.renesas.com/projects/linux-kernel-development/wiki/Miniperi-2016-10 +11:05 < geertu> Nothing to add? +11:06 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20160927-mm-chatlog b/wiki/Chat_log/20160927-mm-chatlog new file mode 100644 index 0000000..803ac12 --- /dev/null +++ b/wiki/Chat_log/20160927-mm-chatlog @@ -0,0 +1,411 @@ +2016-09-27 Multimedia group chat report + +We had a multimedia group meeting on 2016-09-27. Here's a summary of the +discussions. Please correct any mistake you would notice. + +Attendees: + +- Kieran +- Laurent +- Morimoto-san +- Niklas +- Ulrich + +Magnus was excused. + + +Topic 1. Status check for the multimedia tasks +---------------------------------------------- + +* Kieran + +Since last meeting: + +- Patch generated to apply restrictions for UDS/SRU pipeline configuration +with Partition Algorithm + - Still needs testing/review. + +- Stress-testing - segfault investigation + - Identified race in vsp1_video_start_streaming() for multiple inputs + +- Prototype writeback support + - vsp1_video v4l2 device node connected to a single WPF entity + - ‘Empty’ frames flowing to userspace. + +For the next two weeks: + +- Attend Kernel Recipes +- Continue on VSP1-WPF Writeback prototype. + +Issues and Blockers: + +- WPF is locking up when writeback enabled. + - Debug in progress + + +* Laurent + +Since last meeting: + +- Completed M3-W DU support prototype, still needs a bit of polishing + +- Progressing in LVDS mode selection for DU. + +The hard part is finding the relevant standards to create proper DT bindings. + +For the next two weeks: + +- Attending kernel recipes this week +- Working on the V4L2 request API next week to post the next version before +ELCE +- Reviewing Gen3 VIN patches + + +Issues and Blockers: + +None. + + +* Morimoto-san + +Since last meeting: + +- Modified ALSA sound driver DMA channel get/release timing for MSTP power +save. + +Now the driver acquires a channel when starting playback, and releases it when +stopping. Patches should be posted to the mailing list, but they depend on +previous series that still need to be posted. + +- Added IPMMU support on ALSA sound driver with Magnus. + +This requires a workaround patch (= for sound register), but it works well. +Patches should be posted, with same dependency as above. + +- Fixed ALSA sound suspend/resume. + +Jinso reported that ALSA sound is broken when resuming from suspend on v4.8- +rc2. The issue was that the sound framework called status SUSPEND when +suspending, but called START when resuming. The sound driver has START/STOP +status support, but doesn't have SUSPEND/RESUME. Adding SUSPEND/RESUME to the +driver fixed this. Patches should be posted, with same dependency as above. + +For the next two weeks: + +- Continuing work on ALSA +- Attending LinuxCon EU next week + +Issues and Blockers: + +None + + +* Niklas + +Since last meeting: + +- Update HGT testcase to work with all hue area configurations + +For the next two weeks: + +- Refresh the current VIN Gen3 work on top of media_tree +- Start M3-W VIN support work + +Issues and Blockers: + +- Still no review on VIN Gen3 patches + +At this point reviewers should however wait a few days for the refreshed +version of the patch series. + + +* Ulrich + +Since last meeting: + +- Finished Gen2 VIN integration + +A trivial fix is needed, next version will be sent soon. + +For the next two weeks: + +- Update Gen3 HDMI output to use soc_device_match() + +Issues and Blockers: + +None + + +Topic 2. Test reports from Jinzai +--------------------------------- + +We have received testing reports from Jinzai for the 9/M tasks. They noticed +quite a few failures, due to two issues: + +- Missing patches + +Jinzai tested the latest renesas-drivers release, and not all patches were +merged in the tree. Please make sure you get your patches merged in renesas- +drivers when you send the task report. + +- Missing kernel config options + +Jinzai used the ARM64 defconfig, which is missing support for several of the +our drivers. To avoid such test failures, a proposal to include the kernel +config options required for testing of each task in the report has been +approved. + +A minimal diff against defconfig can be generated with + +make ARCH=arm64 savedefconfig + +and can then be manually filtered to remove unrelated options. + + +Topic 3. Agenda for the multimedia face to face meeting in Berlin +----------------------------------------------------------------- + +The meeting is scheduled for Sunday morning before ELCE. A draft agenda will +be sent next weekend, based on the Miniperi-2016-10 wiki page available at +https://osdr.renesas.com/projects/linux-kernel-development/wiki/Miniperi-2016-10. + +Please propose additional topics in reply to this e-mail. + +We will also discuss additional 12/M tasks in Berlin, as well as plans for the +next quarter. Again, if you have identified areas that you think need some +love, please speak out by e-mail. + + +Topic 4. Additional tasks for 11/M +---------------------------------- + +Detailed task descriptions have been submitted to Magnus. They should follow +the usual process and the SoWs should hopefully come soon. +</pre> + +h1. Multimedia-chat-meeting-2016-09-27 + +<pre> +<pinchartl> hyvää huomenta for the Europeans, and hyvää iltaa for the Japanese + [15:51] +<neg> morning all [15:52] +<kbingham-> Morning :) +<uli___> good morning +*** horms (~horms@217.111.208.18) has quit: Ping timeout: 244 seconds +<morimoto> hi +<morimoto> Ohayo-gozaimasu [15:53] +<pinchartl> let's wait a minute for Magnus to join +* kbingham- gets tea while waiting :D +<pinchartl> and then get started, as we have a bit less than one hour before + the core meeting +<morimoto> Magnus is preparing Berlin trip now ? He go tomorrow [15:54] +<morimoto> I'm not sure +<pinchartl> he just told me he won't be able to join, so let's get started + [15:55] +<pinchartl> first topic, tasks status update +<pinchartl> let's use the real alphabetical order today +<pinchartl> Kieran, you're first +*** horms (~horms@217.111.208.18) has joined channel #periperi +<pinchartl> (as usual, Since last meeting: +<pinchartl> For the next two weeks: +<pinchartl> Issues and Blockers:) +<kbingham-> As sent in a mail for ease, but pasted here [15:56] +<kbingham-> * Since last meeting +<kbingham-> - Patch generated to apply restrictions for UDS/SRU pipeline + configuration with Partition Algorithm Needs testing +<kbingham-> - Stress-testing - segfault investigation +<kbingham-> = Identified race in vsp1_video_start_streaming() for + multiple inputs +<kbingham-> - Prototype writeback support +<kbingham-> = vsp1_video v4l2 device node connected to a single WPF + entity +<kbingham-> = Empty frames flowing to userspace. +<kbingham-> * For the next two weeks +<kbingham-> - Attend Kernel Recipes +<kbingham-> - Continue on VSP1-WPF Writeback prototype. +<kbingham-> * Blockers / Issues +<kbingham-> - WPF is locking up when writeback enabled. Debug in progress + [15:57] +<kbingham-> Need to work through getting the WPF to writeback to memory + successfully, but that will be next week now. +<pinchartl> thanks +<pinchartl> do you need help with WPF writeback ? [15:58] +<kbingham-> I've only had a few hours of playing / debugging so far - so not + 'yet' +<pinchartl> ok [15:59] +<kbingham-> s/few/couple/ +<pinchartl> I believe I'm next +<pinchartl> since last meeting I've started work on the 11/M tasks [16:00] +<pinchartl> M3-W DU support is in good shape and just needs a bit of polishing +<pinchartl> and I'm progressing in LVDS mode selection +<pinchartl> the hard part is finding the relevant standards to create proper + DT bindings +*** horms (~horms@217.111.208.18) has quit: Ping timeout: 252 seconds [16:01] +<pinchartl> in the next two weeks I'll attend kernel recipes this week +<pinchartl> and then work on the V4L2 request API next week to post the next + version before ELCE +<pinchartl> no issue or blocker so far +<pinchartl> next, Morimoto-san [16:02] +<morimoto> Since Last Week +<morimoto> 1st, I modified ALSA sound driver DMA channel get/release timing + for MSTP power save. Now It get channel when it start playback, and + release it when it stopped. I would like to post this patch to ML, + but I need to post previous patches first. +<morimoto> 2nd, I added IPMMU support on ALSA sound driver with Magnus. It + needs workaround patch (= for sound register), but it works well. I + would like to post this patch too, but ... +<morimoto> 3rd, Jinso reported that ALSA sound has damage when resume on + v4.8-rc2. The issue was sound framework called status SUSPEND when + suspend, but called START when resume. My sound driver has + START/STOP status support, but doesn't have SUSPEND/RESUME. It + solved if I added SUSPEND/RESUME. I would like to post this patch + too, but.. +<morimoto> --end-- [16:03] +<morimoto> I'm looking forward to meet you in Berlin +<pinchartl> so am I :-) [16:04] +<pinchartl> any particular plan for the next two weeks, or just continuing the + work in progress ? [16:05] +<morimoto> I will meet ALSA SoC people on ELCE timing, I have no other plan + for next 2 weeks +<morimoto> And pinchartl can join to it ? [16:06] +*** horms (~horms@217.111.208.18) has joined channel #periperi +<pinchartl> yes I'll join, it's in my calendar +<pinchartl> note that ELCE is in more than two weeks ;-) +<morimoto> Nice to know +<morimoto> I will goto LinuxCon Euro too +<morimoto> I'm in Berlin from 3rd to 14th Oct [16:07] +<pinchartl> ah right +<pinchartl> have fun there :-) +<pinchartl> any blocker or issue ? +<morimoto> I will :) +<geertu> pinchartl: Exactly two weeks +<morimoto> I don't know how to ride plane +<morimoto> (joke :) [16:08] +<kbingham-> morimoto: Just make sure you get business class and you'll be fine + :D +<morimoto> Hehe :) +<pinchartl> :-) +<pinchartl> next, Niklas +<neg> a) Update HGT testcase to work with all hue area configurations [16:09] +<neg> b) Refresh the current VIN Gen3 work ontop of media_tree and start M3-W + work +<neg> c) Still no review on VIN Gen3 patches +<neg> thats about it [16:10] +<pinchartl> by M3-W work, do you mean VIN support ? +<neg> ohh yes, sorry was a bit unclear [16:11] +*** horms (~horms@217.111.208.18) has quit: Ping timeout: 255 seconds +<pinchartl> for the Gen3 VIN patches I'm very sorry for the delay :-/ +<pinchartl> I'll try to address it this week but it's a bit unlikely as I'm + attending kernel recipes [16:12] +<pinchartl> but I will review them before ELCE in any case +<kbingham-> I have a lot of 'train time' today - so I can cast my eye through + the VIN patches if it helps. Perhaps won't be as good an eye as + pinchartl - but it might help. +<pinchartl> kbingham-: that would certainly be appreciated +<neg> np, at this time maybe it's best if you hold off a few days so I can + resend the refreshed patches on top of media_tree, we got a lot of good + stuff for the VIN driver merged \o/ [16:13] +<neg> kbingham-: thanks I will CC you when I resend the H3 version of the VIN + Gen3 patches +<kbingham-> neg :D [16:14] +<pinchartl> next, uli___ +<uli___> 1) finished up gen2 vin integration [16:15] +<uli___> 2) try and fit soc_device_match() into gen3 hdmi out +<uli___> 3) nothing +<uli___> (i just noticed that 1) needs a trivial fix, gonna resend that rsn) + [16:16] +<pinchartl> thanks +<pinchartl> on a general note +<pinchartl> we've received testing reports from Jinzai for the 9/M tasks + [16:17] +<pinchartl> they noticed quite a few failures, due to two issues +<pinchartl> the first one was missing patches +<pinchartl> Jinzai tested the latest renesas-drivers release +<pinchartl> so please make sure you get your patches merged in renesas-drivers + when you send the task report +<pinchartl> the second issue was due to missing config options in the kernel + [16:18] +<pinchartl> they used the ARM64 defconfig +<pinchartl> to avoid test failures, I propose including in future test reports + the kernel config options required for testing of each task + [16:19] +<pinchartl> does anyone have any objection there ? +<pinchartl> or any concern ? +<kbingham-> sounds reasonable to specify required kernel config + parameters. Just have to remember them when we add them - or diff + our local configs against arm64defconfig. [16:20] +<pinchartl> you can +<pinchartl> make ARCH=arm64 defconfig [16:21] +<pinchartl> sorry +<pinchartl> make ARCH=arm64 savedefconfig +<pinchartl> that will generate a minimal diff +<kbingham-> Aha - that's new to me! [16:22] +<pinchartl> and you can manually filter out anything related to your setup +* kbingham- tests locally. +<pinchartl> next topic, schedule for the multimedia meeting in Berlin [16:25] +<pinchartl> the meeting is scheduled on Sunday morning +<pinchartl> I want to send a draft of the agenda next weekend [16:26] +<pinchartl> so please make sure to e-mail proposals for topics you want to + discuss by then +<pinchartl> or add them directly to the wiki page [16:27] +<pinchartl> + https://osdr.renesas.com/projects/linux-kernel-development/wiki/Miniperi-2016-10 +<pinchartl> so far, we have four topics +<pinchartl> three of them are status reports for tasks +<pinchartl> I'll group them as a single status report topic [16:28] +<pinchartl> the last one is "DU/VIN DT style difference ES1.x/ES2.0" +*** horms (~horms@217.111.208.18) has joined channel #periperi +* kbingham- gets a 403 -ENOAUTH on the wiki :( +<morimoto> kbingham-: oops, please wait +<pinchartl> kbingham-: I assume you now have an account for osdr.renesas.com ? + [16:29] +<kbingham-> pinchartl: I have an account- but no permissions :D +<pinchartl> ah, and there's a fifth topic proposed by Niklas, I'll add it to + the wiki +<pinchartl> regarding V4L2 pad-aware subdev operations +<morimoto> kbingham-: you are "Kieran Bingham" correct ? +<kbingham-> morimoto: Yes :) +<pinchartl> scratch that, it's for the V4L2 meeting on Monday +<morimoto> kbingham-: can you now ? +<kbingham-> morimoto: Ack :) Yes thanks [16:30] +<morimoto> nice :) +<pinchartl> we will also discuss additional 12/M tasks in Berlin, as well as + plans for the next quarter +<pinchartl> again, if you have identified areas that you think need some love, + please speak out now or by e-mail [16:31] +<pinchartl> next topic, 11/M tasks [16:32] +<pinchartl> I've submitted the detailed descriptions of all tasks to Magnus +<pinchartl> they should follow the usual process [16:33] +<pinchartl> and I hope to see SoWs coming soon +<pinchartl> I believe that it's safe to start working on them at this point, + but you're free to wait for the SoW +<pinchartl> that's all for me. does someone have additional topic proposals ? + [16:35] +<morimoto> Do you know where we can meet for MiniPeriCon ? +<morimoto> Wolfram control ? [16:36] +<pinchartl> that's a good question, I don't know +<morimoto> OK, no one knows :) +<pinchartl> that seems to be a central problem, not specific to multimedia + [16:37] +<pinchartl> isn't it the job of the core group to handle that kind of issues ? + ;-) +<morimoto> Hehe :) +<neg> also not related to periperi multimedia, but do you know any time or + location for the V4L2 meeting on Monday? +<pinchartl> I assume it will start at 9:00 [16:38] +<pinchartl> as for the location, Hans said he got a room from the Linux + Foundation +<pinchartl> I suppose he will announce it +<kbingham-> pinchartl: He has announced it on linux-media [16:39] +<kbingham-> I presume it is : '[ANN] Codec & Request API Brainstorm meeting + Oct 10 & 11' +<kbingham-> in room 'Salon 13 Paris' on level 1 of the Maritim Berlin +<neg> nice, thanks (I need to read linux-media more carefull) [16:41] +<pinchartl> the next meeting will be held in Berlin on Sunday the 9th [16:42] +<pinchartl> with this said, I propose adjourning this meeting. does anyone + second ? +<neg> second +<morimoto> second [16:43] +<neg> (so I have time to brew coffy before core meeting :-) +<kbingham-> no time for more tea for me. I have to pack and head to a train + station :) diff --git a/wiki/Chat_log/20161009-mm-chatlog b/wiki/Chat_log/20161009-mm-chatlog new file mode 100644 index 0000000..b1d66c5 --- /dev/null +++ b/wiki/Chat_log/20161009-mm-chatlog @@ -0,0 +1,300 @@ +h1. Multimedia-chat-meeting-2016-10-09 + +Hello, + +We had a multimedia group meeting on 2016-10-09. Here's a summary of the discussions. Please correct any mistake you would notice. + +Attendees: + +- Kieran +- Laurent +- Morimoto-san +- Niklas +- Ulrich + +Magnus was excused due to being in a plane. + + +Topic 1. Status check for the multimedia tasks +---------------------------------------------- + +* Kieran + +Since last meeting: + +- Attended Kernel Recipes in Paris + +There were a few multimedia presentations given, in particular about colourspace and DRM. + +- Display writeback implementation + +This is targeted at Gen3, based on VSP1 writeback. Need a few changes to the VSP driver in the frame end processing to handle writeback and display update races. + +For the next two weeks: + +- ELC-E +- Display writeback + +Issues and Blockers: + +- WPF Lockup I was experiencing is likely invalid until I get timings fixed up for a better test. +- Changes to VSP1 timings atomic_flush() must be verified. + + +* Laurent + +Since last meeting: + +- Attended Kernel Recipes in Paris + +- LVDS mode selection for the DU driver + +Patches have been posted, the DT bindings have just been reviewed today. A new +version will be needed. + +- DU support for M3-W + +Code tested, works with VGA output. Will post patches after ELC-E. + +- DU encoders clean up + +Use the drm_bridge framework to handle all external encoders, including the +VGA DAC with the driver recently submitted by Maxime Ripard. This allows +deleting the hardcoded list of encoders from the DU driver. + +For the next two weeks: + +- ELC-E +- New version of the LVDS mode selection patches +- Post M3-W DU support patches +- Continue with the DU encoders clean up +- Post proposal for rotation & histogram API + +Issues and Blockers: + +None. + + +* Niklas + +Since last meeting: + +- VSP1 HGT tests + +Extended the tests to cover overlapping hue areas. Patches posted, will be +merged by Laurent in a separate branch until the corresponding kernel code +lands upstream. + +- VIN Gen3 rework + +Make use of the media controller framework instead of V4L2 input selection. + +For the next two weeks: + +- ELC-E +- VIN support for M3-W proof of concept +- Continue working on media controller-based input selection in VIN +- Discuss ADV7482 upstreaming face to face with Hans + +Issues and Blockers: + +None. + + +* Morimoto-san + +Since last meeting: + +- Handled BSP team multimedia requests +- LinuxCon Europe +- Bunch of audio patches accepted + +The other pending patches will be posted after the merge window closes. + +For the next two weeks: + +- ELC-E +- Meeting with ALSA SoC maintainer at ELC-E + +Need to discuss framework historical issues that require cleanup. Due to +timezone differences progress on that was slow on the mailing list, hope to +move forward face-to-face. + +Issues include + + - old architecture, needs cleanup + - unbind problem (races, crashes) + +Issues and Blockers: + +None. + +* Ulrich + +Since last meeting: + +- Reposted Gen2 VIN integration + +Updates to the ADV7180 DT bindings are needed to add ports, this won't be +trivial. + +For the next two weeks: + +- ELC-E +- Face to face discussions about the ADV7180 DT bindings with Hans Verkuil + +Issues and Blockers: + +Non-trivial changes to the ADV7180 DT bindings. + + +Topic 2. BSP patch mining coordination +-------------------------------------- + +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 as the canonical +list of BSP patches, and update the status as patches are merged in mainline. + + +Topic 3. BSP team requests +-------------------------- + +- Cache management on V4L2 + +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. + +- Rotation and image partitioning + +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. + +- V4L2 Request API + +The API will be discussed tomorrow during a whole day V4L2 meeting with Hans +Verkuil and Sakari Ailus among others. More information about the upstreaming +schedule will be available then. + +- VSP1 state bug + +Two race conditions have been found recently. One of them has already been +fixed in mainline (v4.9): + +commit bfb4d5be9e1d5a70d0710e815d15a4245eaaafc4 +Author: Kieran Bingham <kieran+renesas@bingham.xyz> +Date: Tue Sep 6 14:07:09 2016 -0300 + + [media] v4l: vsp1: Repair race between frame end and qbuf handle + +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. + +- DU/VIN DT style difference between ES1.x and 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. + +- 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. + +- Is it possible to have M3 DU on renesas-drivers in 11/M ? + +Yes. + +- 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. + +- horizontal lines appears in the plane + +The BSP team noticed a display corruption issue with renesas- +drivers-2016-09-20-v4.8-rc7 with the following patches applied: + + - 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 + +If we can get those four patches we will investigate and provide a fix or, if +the problem is complex, a plan. + +- Runtime SRC (Sampling Rate Converter) 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. + + +Topic 4. Additional tasks for 12/M +---------------------------------- + +We drafted the following list of candidates for additional tasks. + +* Can be addressed immediately + +- GStreamer V4L2 deinterlacer element +- VSP test suite improvements +- VSP image partitioning quality optimization +- Cache management in V4L2 +- Fix VSP1 race conditions +- R-Car DU fence support +- Fix Display corruption (horizontal lines) with IPMMU +- Suspend/resume test suite +- Gen3 HDMI output upstreaming + +* Needs coordination with Renesas + +- VSP suspend/resume support prototype +- Wayland V4L2 compositor performance assessment +- FCP near-lossless compression (FCNL) prototype + +* Blocked by hardware availability + +- VSP ES2.0 BRS support prototype +- H3 ES2.0 DU support prototype + +* Not wanted by Renesas at the moment + +- Video codecs support + + +Topic 5. Next meeting +--------------------- + +The next meeting will be held on Tuesday 2016-10-25 at 08:00 BST / 09:00 CEST +/ 10:00 EEST / 14:00 JST. + +-- +Regards, + +Laurent Pinchart diff --git a/wiki/Chat_log/20161025-core-chatlog b/wiki/Chat_log/20161025-core-chatlog new file mode 100644 index 0000000..2cec93e --- /dev/null +++ b/wiki/Chat_log/20161025-core-chatlog @@ -0,0 +1,240 @@ +Core-chat-meeting-2016-10-25 + +10:05 < geertu> Welcome to todays Core Group Meeting +10:05 < geertu> Agenda: +10:05 < geertu> 1. Status updates +10:05 < geertu> 2. Inquiries from Tokyo +10:06 < geertu> Topic 1. Status updates +10:06 < geertu> A) What have I done since last time +10:06 < geertu> B) What I plan to do till next time +10:06 < geertu> C) Problems I have currently +10:06 < geertu> First is Uli +10:06 < uli___> a) sent sys-dmac, i2c, and scif for r8a7796 +10:07 < uli___> b) fix up sys-dmac, i2c, and scif as far as people have considered it offensive :) +10:07 < uli___> c) none +10:07 < geertu> Thank you Uli +10:07 < geertu> Next is Simon +10:07 < horms> A) What have I done since last time +10:07 < horms> * No core tasks at this time +10:07 < horms> B) What I plan to do till next time +10:07 < horms> * See above +10:07 < horms> C) Problems I have currently +10:07 < horms> * 16Mbyte kernels: Is a solution being worked on by Renesas? +10:07 < horms> * Gen2 Suspend 2 Ram: What are the next steps +10:08 -!- shimoda [~shimoda@relprex3.renesas.com] has joined #periperi +10:08 < geertu> Mronin' Shimoda-san +10:08 < geertu> horms: Gen2, right? +10:08 < shimoda> sorry for the delayed! +10:09 < horms> silly me. I mean Gen3 +10:10 < geertu> horms: The current implementation (with SW23 and PMIC) doesn't really keep in mind how suspend works on Linux +10:10 < geertu> I've tried on H3, where we do have bias support, and GPIO wake-up doesn't work +10:11 < geertu> So the only wake-up source we have is SW23? +10:11 < horms> Did you also test on M3-W? +10:11 < khiemnguyen> yes, in suspended state, the board are powered down. +10:11 < geertu> M3-W doesn't have bias support yet +10:11 < khiemnguyen> only SW23 can signal to PMIC and trigger the resume. +10:11 < horms> My assumption is that the SW23 situation is a work around. +10:11 < geertu> khiemnguyen: What if the user wants a different wake-up source? +10:12 < horms> Can we confirm what the plans of the firmware team are in this regards? +10:12 < geertu> E.g. wake-on-LAN? +10:12 < khiemnguyen> geertu: we will need different board ;) +10:13 < geertu> Alternative, if extra wake-up sources are enabled, can we do it like on Gen2? +10:14 < geertu> I.e. keep the SoC powered, so it will receive and act on interrupts? +10:14 < khiemnguyen> for Gen3, it's target to not only SoC, but board power down. +10:15 < khiemnguyen> if SoC is power down only, like Core-Standby, L2 shutdown, we can use other wakeup sources, like interrupts. +10:16 < horms> I wonder how this aligns with customer expectations. +10:16 < geertu> khiemnguyen: It depends on the use case. Some users may want Wake-on-LAN or Wake-on-GPIO +10:18 < khiemnguyen> geertu: so, we can let them use SoC power down only. We can able to achieve it. +10:18 < horms> I think that would be more in keeping with how S2RAM works on Gen2. +10:19 < geertu> khiemnguyen: OK. +10:19 < horms> Which may also me aligned with users's expectations +10:19 < geertu> khiemnguyen: I was also considering future use cases (cfr. RZ/G) +10:19 < horms> But I assume that this would involve more power consumption. +10:20 < khiemnguyen> geertu: RZ/G is similar to Gen2. +10:20 < geertu> horms: One question is if we can do this in the kernel without touching arm64 core code, which may be hardwired to call into PSCI anyway +10:20 < horms> true +10:20 < khiemnguyen> geertu: for armv8, we need to use PSCI. +10:21 < geertu> khiemnguyen: I know. And RZ/G targets a different market than cars, which may have different requirements w.r.t. wake-up sources +10:21 < khiemnguyen> ARM maintainer will reject all code which do not use PSCI, AFAIK. +10:21 * pinchartl wonder how long it will take before support for bypassing PSCI will be merged in the kernel +10:21 < geertu> khiemnguyen: I don't know much about the PSCI API. Can Linux pass parameters to specify suspend mode? +10:22 < khiemnguyen> in the history, Qualcomm or other companies submitted the code, and all have been rejected. +10:23 < khiemnguyen> they want a unified solution in arm64 arch. +10:23 < geertu> Let's see... More investigation needed... +10:23 < geertu> Next? +10:23 < geertu> Next is Shimoda-san +10:24 < shimoda> yes +10:24 < shimoda> a) nothing for core group +10:24 < shimoda> b) need lossy info into eLinux... +10:24 < shimoda> c) nothing for core group +10:24 < shimoda> --- end --- +10:24 < geertu> Thanks you, Shimoda-san +10:24 < geertu> Next is Niklas +10:25 < neg> A) Noting for core (multimedia consumed all my time with feedback from ELCE) +10:25 < neg> B) Fix review comments on H3 PFC drive-strengh patches and start on M3-W PFC work. +10:25 < neg> C) None. +10:25 < neg> EOT +10:26 < geertu> Thank you +10:26 < geertu> Next is Morimoto-san +10:26 < morimoto> A) No Core Task +10:26 < morimoto> B) No Core Task (but have 2 questions) +10:26 < morimoto> C) None +10:27 < morimoto> Questions are Next Topics +10:27 < morimoto> EOT +10:27 < geertu> Thank you, Morimoto-san +10:27 < geertu> Next is Magnus +10:27 < geertu> (AWOL) +10:27 < geertu> Next is Laurent +10:28 * pinchartl is just a lurker here +10:29 < geertu> Thanks for lurking +10:29 < geertu> Next is Khiem +10:29 < pinchartl> you're welcome +10:29 < pinchartl> (I've just checked, the PSCI system suspend call doesn't take a mode argument. suspend to ram is suspend to ram, the same way wine is wine) +10:30 < khiemnguyen> a) no progress. +10:30 < khiemnguyen> b) to complete Z-clk changing (for CPUFreq) +10:30 < khiemnguyen> c) to solve issue of my email account. Then, come back to Z-clk changing. +10:30 < geertu> pinchartl: Thanks for checking. So no way to pass wake-up-source information +10:30 < khiemnguyen> perhaps, I will send the email to periperi list for review first. +10:31 < khiemnguyen> that's all. +10:31 < geertu> Thanks, Khiem! +10:31 < geertu> Next is Geert +10:31 < pinchartl> geertu: no. the firmware could check whether peripherals have been configured as a wake up source, but that's really a heuristic and is error-prone +10:31 < geertu> A)- Investigated serial console issue in v4.9-rc1 +10:31 < geertu> - Reviewed Niklas' drive strength patches +10:31 < geertu> - Reviewed lots of RZ/G patches +10:31 < geertu> - Sent out v1 of SoC identifaction and ESx.y handling +10:31 < geertu> - Sent out R-Car H3 ES2.0 CPG/MSSR prototype and PFC proof-of-concept +10:31 < geertu> - Coerced Sergei into using CPG/MSSR for RZ/G1M, which we can reuse for +10:31 < geertu> R-Car Gen2 later, +10:31 < geertu> - Sent out v4 of R-Car RST driver +10:31 < geertu> - Started 64-bit memory with M3-W Ethernet +10:32 < geertu> pinchartl: How does the firmware check that? +10:32 < geertu> B)- Prepare v2 of SoC identifaction and ESx.y handling +10:32 < geertu> - I think soc_device_match() itself needs to be in v4.9 +10:32 < geertu> - 1G support for RAVB depends on it, too (only H3 ES1.0 is limited +10:32 < geertu> too 100M) +10:32 < geertu> - Coerce Simon into taking all MODEMR related patches +10:32 < pinchartl> geertu: by reading hardware registers :-) +10:32 < pinchartl> PSCI explicitly states that it does *not* cover peripherals, only CPU cores +10:33 < horms> I'm happy to take patches if there is consensus on them +10:33 < geertu> C)- Too many dependencies between patches and patch series +10:34 < geertu> pinchartl: Aha, that means the kernel is not allowed to call PSCI suspend if peripherals are wake-up sources +10:34 < geertu> Anyone who recently ran renesas-drivers on R-Car H2 ES1.0, with SW4-8 toggling? +10:34 < pinchartl> it means it's a badly defined interface like all firmware interfaces ;-) +10:36 < geertu> EOT +10:36 < geertu> horms: Have to ping Mike/Stephen, so allow Sergei to repost R-car Gen2 CPG/MSSR support using a proper MODEMR API +10:37 < geertu> s/so/to/ +10:37 < horms> perfect. If I need to be involved in coordinating things just let me know +10:38 < geertu> Topic 2. Inquiries from Tokyo +10:38 < geertu> horms: thx! +10:38 < geertu> A. Subject: [periperi] SH-SCI spin/mutex lock issue +10:38 < geertu> - Fixed in v4.5 with commit ff1cab374ad98f4b ("serial: sh-sci: Remove cpufreq +10:38 < geertu> notifier to fix crash/deadlock") +10:38 < geertu> - Backported to v3.2.80, v3.12.60, v3.14.68, v3.16.35, and v4.4.9. +10:39 < geertu> morimoto: Does that answer your question? +10:39 < morimoto> let me check +10:40 < morimoto> Thanks. I will report it ot BSP team +10:40 < geertu> OK +10:41 < geertu> B) "Re: [periperi] 2016-03-15 Renesas Core Group Chat Invitation" (2016-03-22) +10:41 < geertu> This is about the patch "[PATCH 119/124] arm64: dts: Add multi-cluster to r8a7795 dtsi" (from the BSP? It's not present in any of rcar-3.0.0..rcar-3.3.3.rc2?) +10:41 < geertu> Cfr. Documentation/devicetree/bindings/arm/topology.txt +10:42 < geertu> Example 2 is basically what's added +10:42 < geertu> However, this depends on the presence of the CA53 nodes, which we haven't added yet deliberately +10:43 < morimoto> Does this mean upsteam still can't have it, right ? +10:44 < geertu> Indeed. +10:44 < morimoto> Do you have some plan ? +10:45 < geertu> Note that our firmware (at least H3 latest from wiki) enables the CA57 cores only +10:46 < horms> There are other versions of the firmware, right? +10:46 < geertu> The plan was to add support for CA53 as soon as the scheduler is big.LITTLE aware +10:46 < horms> oh, that would be... never, right? +10:47 < geertu> Good question... +10:48 < horms> I mean. big.LITTLE has been floating around for some time now. As have out-of-tree solutions. But is in-tree support going anywhere? +10:48 < geertu> horms: No idea. +10:48 < horms> It remember having this exact conversation at Linux Con in New Orleans, whenever that was. +10:49 < horms> So I must say that I am very skeptical +10:49 < horms> Not that I want to bring down the mood of the conversation. +10:50 < geertu> I have the same feeling (wasn't in New Orleans) +10:51 < geertu> morimoto: If the BSP team wants the patch, I think they can just add it to the BSP. +10:52 < morimoto> geertu: Thanks. I (and shimoda-san) will explain it to BSP team +10:52 < geertu> morimoto: There's no issue with the patch itself, so when upstream is ready, it can be submitted as-is +10:53 < geertu> morimoto: Does the BSP team use an out-of-tree big.LITTLE patch? +10:55 < morimoto> geertu: It seems big.LITTLE team (= not BSP team) want this patch +10:55 < morimoto> But I don't know detail of their situation. shimoda-san do you know ? +10:56 < horms> morimoto: I think the point is that its hard to have partial support for big.LITTLE in mainline and so a more holistic approach is required. +10:56 < shimoda> morimoto: i also don't know the detail but the big.LITTLE team wants to use it and suggest it to out customer somewhat +10:57 < shimoda> s/somewhat/something/ +10:58 < morimoto> horms: thank +10:59 < morimoto> geertu: thanks, I will explain above +10:59 < geertu> shimoda: It would be good to know what other big.LITTLE patches they suggest to the customer +11:00 < horms> And what customers's use cases are +11:01 < geertu> THanks all +11:01 < geertu> C) __alloc_iova()??? +11:01 < geertu> THis was more a question for Magnus? +11:02 < shimoda> I am asking Magnus-san about the API for Gen3 SDHI+DMAC+IPMMU +11:03 < pinchartl> what's the problem with __alloc_iova ? +11:03 < shimoda> in dma-iommu.c, the __alloc_iova() calls alloc_iova() as size-alligned +11:04 < shimoda> however I would like to avoid the size-alligned for Gen3 SDHI-DMAC + IPMMU because the DMAC doesn't have descripter mode +11:05 < pinchartl> there's a comment in the __alloc_iova() function that states +11:06 < pinchartl> * Enforce size-alignment to be safe - there could perhaps be an +11:06 < pinchartl> * attribute to control this per-device, or at least per-domain... +11:06 < shimoda> yes, so I asked Magnus-san how to improve this frameword somehow +11:06 < shimoda> s/frameword/framework/ +11:07 < pinchartl> adding a DMA mapping attribute could be one option +11:07 < pinchartl> it should be discussed with the author of the code +11:08 < shimoda> and Magnus-san will do it somehow +11:08 < shimoda> pinchartl: thank you for the suggestion! +11:09 -!- horms [~horms@91.126.38.165] has quit [Ping timeout: 252 seconds] +11:12 < geertu> OK, let Magnus handle that ;-) +11:12 < geertu> Any other topics? +11:12 -!- horms [~horms@cli-5b7e26a5.wholesale.adamo.es] has joined #periperi +11:13 < geertu> shimoda-san: Do your have more information about the R-car hwspinlock driver? +11:14 < shimoda> geertu: no more information from BSP team +11:14 < shimoda> i'll ask him +11:15 < geertu> shimoda: OK, thx +11:15 < geertu> No more topics? +11:15 < khiemnguyen> geertu: we don't know the user of R-car hwspinlock driver ? +11:16 < horms> shimoda-san: do you have any idea if there is activity going on regarding kernels larger than 16Mb? +11:17 < shimoda> horms: bsp team has a plan for it. +11:17 < horms> ok, perhaps we can disucss that some time? +11:17 < shimoda> now 0x49000000, in near the future 0x50000000 +11:17 < geertu> shimoda: Does it also apply to Gen2? +11:17 < geertu> Or RZ/G? +11:18 < shimoda> geertu: i don't know the plan for Gen2. I will ask BSP team. do you also need to be large on gen2? +11:18 < horms> From my pov it should be much less of an issue on Gen2 as we have defconfig_shmobile in mainline +11:19 < geertu> But CONFIG_PROVE_LOCKING=y no longer boots on Gen2 +11:19 < shimoda> oops, the addresses means the u-boot text base address +11:19 < shimoda> s/means/mean/ +11:19 < horms> shimoda: is the idea to use a different region. If so, does that involve a uboot update? +11:20 < geertu> CONFIG_PROVE_LOCKING still works for me on ape6evm, armadillo, bock-w, kzm9g, and marzen (I use separate .configs for each board) +11:21 < shimoda> horms: on gen3, we need to update both IPL (firmware) and uboot +11:21 < horms> ok. how large is the new reagion? and when might we expect to be able to use these updates on our boards? +11:23 < shimoda> horms: maybe we can use up to 128Mb imange and i heard the bsp comes in 11/E but maybe I can modify v2.12.0 IPL base if needed :) +11:23 < horms> ok, 128Mb sounds good to me. And I think the group that met in Berlin also thought so. +11:24 < horms> 11/E should be fine for me +11:24 < horms> Currently arm64/defconfig + (small) initrd is still small enough to boot +11:24 < horms> Corrently = v4.9-rc2 +11:25 < horms> Thanks for the update +11:25 < geertu> Thanks all, I think we're finished? +11:25 < horms> Nothing more from me +11:25 < geertu> s/Mb/MiB?? +11:25 < horms> I think we are talking about bytes +11:26 < horms> and M being 1024^2 - alpha +11:26 < horms> and M being 1024^2 +11:26 < geertu> Nah, M = 1E6 +11:26 < horms> ok! +11:26 < geertu> Mi = 2^20 +11:27 < geertu> Ah, about next meeting +11:27 < geertu> We go for 09:00 GMT / 10:00 CET / 11:00 EET / 18:00 JST, like Multimedia, too? +11:28 < geertu> Or 08:00 GMT / 09:00 CET / 10:00 EET / 17:00 JST? +11:28 < horms> which day? +11:28 < geertu> Tue Nov 8 +11:29 < geertu> I'm mainly asking because of CEST - DST = CET +11:29 < horms> Yes, I understand +11:29 < horms> I suggest the Tokyo based members prefernce counts here +11:29 < geertu> horms: So you get to sleep one more hour on Sunday morning ;-) +11:29 < horms> Yes +11:29 < geertu> Agreeed +11:30 < horms> Perhaps confirm over email? +11:30 < horms> I need to drop off now +11:31 < geertu> OK, let's use email +11:31 < geertu> Thanks for joining! diff --git a/wiki/Chat_log/20161025-mm-chatlog b/wiki/Chat_log/20161025-mm-chatlog new file mode 100644 index 0000000..8013ba4 --- /dev/null +++ b/wiki/Chat_log/20161025-mm-chatlog @@ -0,0 +1,175 @@ +Multimedia-chat-meeting-2016-10-25 + +<pinchartl> hello [15:50] +<neg> hi all, everyone made it back from Berlin in one piece? +<morimoto> hi +<uli___> hello +* geertu did [15:51] +<pinchartl> I haven't counted the pieces +<pinchartl> we're missing Magnus and Kieran [15:52] +<kbingham> morning +* kbingham appears from a cloud like magic :D +* uli___ hides under the desk [15:53] +<pinchartl> we're not missing Kieran :-) +<pinchartl> let's wait a few minutes for Magnus +* kbingham thought this meeting was tomorrow :D +<pinchartl> didn't you receive the invite ? +<morimoto> 1 question during waiting. How to do above "* kbingham xxx" on IRC + ? [15:54] +<geertu> morimoto: /me xxx +<morimoto> OK, let's use it +* morimoto hoge +<morimoto> Ohh !! +<kbingham> Yes, - it was in my calendar - hence I'm here. Just had it stuck in + my head that meetings were on a wednesday for some reason. + [15:55] +<pinchartl> morimoto: you're now an IRC master :-) +* kbingham applauds +<neg> I wonder who tought of that feature and what the rational was for + implementing it, MUD:s over IRC ? :-) [15:57] +<pinchartl> looks like Magnus won't make it, let's get started +<pinchartl> topics for today +<pinchartl> - Status check for the multimedia tasks +<pinchartl> - Additional tasks for Q4/2 2016 +<pinchartl> - Next meeting +<pinchartl> anything else ? +<morimoto> I posted 2 questions to you guys [15:58] +<pinchartl> I've just seen that [15:59] +<pinchartl> let's address them as part of the status report +<morimoto> thanks +<pinchartl> Topic 1. Status check for the multimedia tasks [16:00] +<pinchartl> the alphabetical order points to... Kieran! +<pinchartl> Since last meeting: +* kbingham would like reverse alphabetical status checks this week :D +<pinchartl> For the next two weeks: +<pinchartl> Issues and Blockers: +<pinchartl> request granted +<pinchartl> uli___: you're first :-) +<uli___> what a ripoff! [16:01] +<uli___> anyway +<uli___> since last time: sent v2 of the VIN series for lager/koelsch/gose +<uli___> for the next two weeks: prepare HDMI out gen3 for upstream, and/or +<uli___> audio loopback test tool [16:02] +<uli___> dunno which i will do first +<pinchartl> regarding the VIN series, have you seen my latest comment about + the adv7180 DT bindings ? +<uli___> yes, i have +<uli___> no blockers i'm aware of +<pinchartl> do you plan to work on a v3 ? [16:03] +<uli___> i do, though i don't know if that will be within the next two weeks +<uli___> that's it from me [16:04] +<pinchartl> unless there's something I'm missing, it's "just" a matter of + updating the DT bindings and the DT. an agreement has been reached + at least with Hans regarding how the DT bindings should look like +<pinchartl> so I'd advise starting early for the bindings part, as it usually + takes time to go through review +<uli___> ok, i'll take that into account [16:05] +<pinchartl> thanks [16:06] +<pinchartl> next, neg +<neg> A) Started to rewrtie the VIN Gen3 driver to use media control instead + of s_input. MC part is done now the rest of the driver just needs to use + it. Rewrite is the reason the old VIN patches was not resent like I + talked about last IRC multimedia meeting. +<neg> B) Finish the VIN Gen3 MC rewrite. +<neg> C) None. +<neg> On a side not I'm much happier with a MC implementation than s_input, + lets see how it do in review :-) [16:07] +<neg> EOT [16:08] +<pinchartl> will you attend the IRC meeting on #v4l at 11:30 UTC regarding + v4l2_async ? +<neg> yes +<pinchartl> great, thanks [16:09] +<pinchartl> next, Morimoto-san +<morimoto> A) +<morimoto> I posted ALSA SoC cleanup patch, It is under reviewing. +<morimoto> I posted OF graph base sound card patchset to ALSA / DT ML, +<morimoto> I got comment from Rob, and discussed, but no return from him. +<morimoto> I'm considering BSP sound issue. +<morimoto> B) +<morimoto> continue ALSA SoC cleanup patch +<morimoto> Wait Rob's comment for OF graph patch [16:10] +<morimoto> C) +<morimoto> No response from Rob +<morimoto> EOT +<pinchartl> thank you [16:11] +<morimoto> A+) I posted Sound IOMMU support patch, too +<pinchartl> by considering BSP sound issue, do you mean you're investigating + it ? +<morimoto> We already know the issue, but we don't know how to solve it :( + [16:12] +<morimoto> It is not good match to ALSA SoC style +<pinchartl> ok +<pinchartl> so you're trying to see how it could be solved in the BSP without + having to rewrite everything ? [16:13] +<morimoto> BSP issue is very Salvator-X specific issue at this point +<morimoto> Maybe BSP team will try local-patch 1st [16:14] +<pinchartl> ok, thanks [16:15] +<pinchartl> next, me +<pinchartl> since last meeting, I've reworked the DU encoder and connector + initialization to use the DRM bridge framework [16:16] +<pinchartl> the Du driver doesn't hardcode encoder compatible strings anymore +<pinchartl> only the internal LVDS encoder is still implemented without DRM + bridge, I might change that at a later point [16:17] +<pinchartl> this change will impact HDMI support on Gen3, it should hopefully + make it easier +<pinchartl> I've also been through the BSP multimedia patches to see what we + need to upport, and upported a few of the simple ones [16:18] +<pinchartl> I'll post them later today or tomorrow +<pinchartl> until the next meeting I plan to follow up on the LVDS mode + selection patches +<pinchartl> I'm waiting for a reply from Rob Herring, I'll ping him +<pinchartl> I also plan to post a proposal for the rotation and histogram + APIs, I haven't had time to address it yet [16:19] +<pinchartl> and, last but not least, I'll attend the kernel summit and the + linux plumbers conference next week, so I'll have reduced + availabilities [16:20] +<pinchartl> (and will be in a different time zone) +<pinchartl> I'll take off tomorrow +<pinchartl> and I forgot to mention that I've also posted M3-W DU patches +<pinchartl> now, regarding Morimoto-san's question +<morimoto> OK [16:21] +<pinchartl> "VSP,?,plan,laurent,Fix suspend/resume crash" +<pinchartl> this will likely be fixed by Kieran as an additional task for the + second half of Q4 +<morimoto> Q4 = 12/M ? +<pinchartl> "likely" because the SoW is still a draft +<pinchartl> yes, 12/M +<morimoto> OK, sounds nice [16:22] +<pinchartl> assuming the task gets accepted +<pinchartl> Magnus told me it had been selected, so there's a high chance it + will be formally accepted +* morimoto d(^-^)b +<morimoto> Last question is that kbingham's 2nd fixup patch for race condition + [16:23] +<morimoto> kbingham said that he will post it soon in Berlin +<kbingham> Ahh - I haven't had chance to finish that investigation yet. +<morimoto> BSP team want to test it +<pinchartl> good transition, let's move to Kieran :-) +* kbingham adds to task list +<kbingham> Since last meeting: VSP1 write-back worked on - but currently + capturing *partial* frames (see blockers in a moment) and also + worked on VSP1 partition algorithm performance task [16:25] +<morimoto> pinchartl: can you please add it on multimedia/todo file ? +<morimoto> otherwise, I will forget :P [16:26] +<kbingham> For the next two weeks - I *want* to see both of those completed, + and I've also picked up a FDP1 hang on G2 to look at, and I've just + added the 2nd race condition to my list. +<pinchartl> morimoto: sure +<pinchartl> the FDP1 hang on Gen2 is very low priority at this moment +<pinchartl> please only address it if you have nothing else to do [16:27] +<kbingham> Blockers.: Writeback output has chunks missing in the middle. I get + variable outputs, which is confusing - so I plan to mail Koji for + his advice again. +<pinchartl> which seems a bit unlikely to me :-) +<kbingham> ack on the FDP1 hang. +<kbingham> (above mailed in bulletpoints for copy/paste) +<kbingham> morimoto: Did the BSP team report on if the first patch solved + their existing race/hang? [16:28] +<morimoto> I didn't ask them. Let's ask +<pinchartl> morimoto: we believe that the first patch should solve the race + they reported [16:29] +<pinchartl> the second patch still needs more investigation +<morimoto> OK, thanks +<morimoto> I will report this to BSP team +<pinchartl> thanks +<pinchartl> that's it for the first topic [16:30] diff --git a/wiki/Chat_log/20161108-core-chatlog b/wiki/Chat_log/20161108-core-chatlog new file mode 100644 index 0000000..756c914 --- /dev/null +++ b/wiki/Chat_log/20161108-core-chatlog @@ -0,0 +1,223 @@ +Core-chat-meeting-2016-11-08 + +09:07 < geertu> Welcome to today's Core Group Chat +09:07 < geertu> ... and try to keep it short ;-) +09:07 < geertu> Agenda: +09:07 < geertu> 1. Status updates +09:07 < geertu> 2. Inquiries from Tokyo +09:08 < geertu> Topic 1. Status updates +09:08 < geertu> First is Simon +09:08 < horms> TODO Update is NULL for me +09:08 < horms> Status: +09:08 < horms> A) What have I done since last time +09:08 < horms> * No core tasks at this time +09:08 < horms> B) What I plan to do till next time +09:08 < horms> * Land Geert's RST patches in reness tree +09:08 < horms> C) Problems I have currently +09:08 < horms> * 16Mbyte kernels: Do we have a timeframe for firmware upgrade? +09:08 < horms> * Gen2 Suspend 2 Ram: What are the next steps (same as last time) +09:08 < horms> * Access to [MH]ULCB documentation and hw +09:08 < horms> -- end -- +09:08 < geertu> s/Gen2/Gen3/? +09:09 < geertu> 16Mbyte kernels: any takers? +09:09 < horms> Same error as last time; yes, gen3 +09:09 < horms> Probably Khiem or Shimoda-san are the best bet there +09:10 < shimoda> about 16Mbyte kernel, coming soon +09:10 < horms> superb +09:11 < shimoda> https://github.com/renesas-rcar/u-boot/commits/v2015.04/rcar-3.4.x +09:11 < shimoda> https://github.com/renesas-rcar/arm-trusted-firmware/commit/c2f9fc9f1324d429decd2b2810fd0c0bde577fd7 +09:11 < shimoda> they seem -rc +09:12 < shimoda> but +09:12 < horms> Ok, so we might see this by the end of the year? +09:12 < shimoda> horms: yes. perhaps -rc is removed in end of this month I guess +09:12 < horms> ok, great. thanks for the update +09:13 < geertu> Shimoda: Does that firmware enable Lossy Decomp? +09:14 < shimoda> geertu: this should be counfigureble +09:14 < shimoda> so we can disable it +09:14 < morimoto> Basically, Lossy will be enable if we selected MultiMedia package on Yocto +09:14 < morimoto> And I don't select it :P +09:14 < geertu> OK +09:16 < geertu> Suspend 2 Ram: I guess we should try Suspend to Idle? +09:16 < geertu> https://www.linaro.org/blog/suspend-to-idle/ +09:16 < geertu> See also Laurent's write-up of his discussion about this topic at LPC +09:16 < horms> ok, i saw pinchartl's email +09:18 < geertu> Access to [MH]ULCB documentation and hw: Morimoto-san? +09:18 < geertu> H3ULCB docs we already have +09:19 < horms> ok, i seem to be missing them for some reason +09:19 < horms> but not to worry +09:19 < morimoto> ulcb hw access will be remote +09:19 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/H3_ULCB +09:21 < horms> thanks +09:21 < geertu> Morimoto-san: Can we have docs for M3ULCB, too? +09:21 < morimoto> No, at this point +09:21 < morimoto> but will send to you ASAP +09:22 < horms> thanks +09:22 < geertu> thx +09:22 < geertu> Next is Shimoda-san +09:23 < shimoda> a) wrote Lossy infor in eLinux +09:23 < shimoda> b) and c) nothing core tasks to me +09:23 < shimoda> -- end -- +09:23 < geertu> Thanks, Shimoda-san +09:23 < geertu> Next is Niklas +09:24 < neg> A) +09:24 < neg> - Fixed review comments on H3 PFC drive-strengh +09:24 < neg> - PFC fixups in regard to bias handling +09:24 < neg> - Started to work on drive-strength and bias handling for r8a7796 +09:24 < neg> B) +09:24 < neg> - Finish r8a7796 PFC work +09:24 < neg> - Send v2 of PFC bias fixups +09:24 < neg> C) None +09:24 < neg> EOT +09:25 < geertu> Thanks Niklas +09:25 < geertu> Next is Morimoto-san +09:25 < morimoto> geertu: (There is no difference between H3/M3 ulcb board. The difference is only SoC) +09:25 < morimoto> A) What I have done since last time +09:25 < morimoto> I'm preparing board export paper work for new guys +09:25 < morimoto> B) What I plan to do till next time +09:25 < morimoto> No Core task +09:26 < morimoto> C) Problems I have currently +09:26 < morimoto> Our team's server HDD has gone (= not relateed to PeriPeri :) +09:26 < morimoto> +09:26 < morimoto> please ignore C) +09:26 < geertu> morimoto: Thanks for confirming (we already assumed that was the case ;-) +09:26 < horms> did someone leave the HDD on the bus? +09:26 < geertu> I hope there using LVM-CRYPT +09:26 < morimoto> This HDD is very local server :) no problem +09:27 < horms> :) +09:27 < geertu> s/there/they're/ +09:27 < geertu> Thanks Morimoto-san +09:27 < geertu> Next is Geert +09:27 < geertu> A) What have I done since last time +09:28 < geertu> - Sent out v2 of SoC identifaction and ESx.y handling +09:28 < geertu> - Waiting for response from Arnd to create shared branch with +09:28 < geertu> soc_device_match() +09:28 < geertu> - Sent out v1 of 64-bit memory with M3-W Ethernet +09:28 < geertu> - 64-bit memory is silently enabled and already working +09:28 < geertu> - Added swiotlb=nobounce to debug +09:28 < geertu> - SYS-DMAC needs 40-bit DMA mask => works +09:28 < geertu> - RAVB DMAC supports 32-bit memory only, needs IPMMU => works +09:28 < geertu> initially, then fails +09:28 < geertu> - Sent clock and pinctrl pull requests for v4.10 +09:28 < geertu> B) What I plan to do till next time +09:28 < geertu> - Get SoC identifaction and ESx.y handling accepted +09:28 < geertu> - Queue up RZ/G1M and RZ/G1E clock drivers +09:28 < geertu> - Coerce Simon into taking all MODEMR related patches +09:28 < geertu> C) Problems I have currently +09:28 < geertu> - Too many dependencies between patches and patch series +09:28 < geertu> (but it's getting better, slowly) +09:28 < geertu> --- EOT --- +09:29 < horms> geertu: let me know if/when/how i cn help with C) +09:29 < geertu> So IPMMU for RAVB seems to work a bit. +09:29 < geertu> Unfortunately the IPMMU expert is missing (JP lessons?) +09:30 < geertu> As Uli, Magnus, Laurent, and Khiem are missing, Topic 1 is finished +09:30 < geertu> Topic 2. Inquiries from Tokyo +09:30 < geertu> A) H3 PFC from BSP team. +09:30 < geertu> Some definitions will be conflict between H3 ES1.x and ES2.0 +09:30 < geertu> BSP team would like to know how to handle this (if we use single pfc-r8a7795.c). +09:31 < geertu> IIUC, H3 ES2.0 PFC is almost identical to M3-W PFC. +09:31 < geertu> So can't we use pfc-r8a7796.c for both (with some runtime table patching)? +09:33 < morimoto> And I got 2 request from BSP team for renesas-drivers + v4.9 +09:33 < morimoto> 1) HDMI out plan (= Geert ?) +09:33 < morimoto> 2) m3ulcb plan (= Simon ?) +09:33 < morimoto> +09:33 < geertu> Any comments on H3 ES2 PFC? +09:34 < geertu> Does it make sense? +09:35 < geertu> 1) HDMI out plan +09:35 < neg> I think so, so far I have only discoverd veary small diffs when looking at drive-strength and bias settings +09:35 < morimoto> geertu: Does this "runtime table patching" means compatible with "-esxx" ? +09:35 < shimoda> geertu: thank you for the comment about the PFC +09:35 < geertu> Isn't this something for MultiMedia? If I receive a pull request, I can include it +09:36 < shimoda> BSP team are also think about it (use pfc-r8a7796 or separate files for es1.x and es2.0) +09:36 < horms> 2) m3ulcb plan +09:36 < geertu> No, soc_device_match(r8a7795es1) +09:36 < horms> I merged most of the patches from Vladimir yesterday +09:36 < geertu> Cfr. "[RFC] pinctrl: sh-pfc: r8a7795: Add PoC support for R-Car H3 ES2.0" +09:36 < horms> so they should appear in renesas-drivers soon +09:37 < horms> I did not merge the SDHI enablement patches but I expect to do so soon as the update requested is small at this time +09:37 < morimoto> geertu: Ahh OK. make sense. But can use "-esxx" compatible too, right ? +09:38 < morimoto> horms: thanks ! +09:38 < geertu> morimoto: yes, we could use renesas,pfc-r8a7795-es2 too, as we need a separate DTS anyway +09:39 < geertu> Recently Mark Rutland said: +09:39 < geertu> "If it affects the programming model +09:39 < geertu> of the device, it should be described in the compatible string, or in +09:39 < geertu> properties on the device node." +09:40 < horms> what does "programming model" mean? +09:40 < geertu> But we can't add renesas,pfc-r8a7795-es1 retroactively +09:40 < geertu> = how you talk to the module +09:41 < geertu> For CPG/MSSR the differences between ES versios are just additions and removals of registers and bits +09:41 < geertu> for PFC I think it's slightly different, so "different programming model" may apply +09:42 < geertu> warranting a compatible change +09:43 < geertu> Any other comments about PFC? +09:44 < shimoda> sorry i don't understand yet.. +09:44 < geertu> Shimoda: What should I explain better? +09:44 < shimoda> bsp team have concern about the #define +09:45 < shimoda> it will be conflict if we follow the datasheet +09:46 < shimoda> or, any #defines is not useful after boot? +09:48 < shimoda> this means the #define (e.g. IP9_7_4) is for just a programmer? +09:49 < geertu> If we use pfc-r8a7796.c for H3 ES2, the definition of IP9_7_4 is correct, right? +09:49 < shimoda> yes +09:50 < geertu> If the only differeences between H3ES2 and M3-W are differences in pinmux_data[], we can use runtime patching +09:51 < geertu> Of course we can start using a separate pfc-r8a7795-es2.c, and see if/what can be merged with pfc-r8a7796.c later +09:53 < horms> Is it possible to do the reverse with a pfc-r8a7795-es1.c? +09:53 < geertu> Yes we can +09:54 < geertu> But I think pfc-r8a7795-es1.c still has to match against existing renesas,pfc-r8a7795 +09:54 < horms> That would seem slighly better in terms of future clean up imho +09:54 < geertu> while new pfc-r8a7795.c would match against new renesas,pfc-r8a7795-es2 +09:54 < horms> well, unless its acceptable to make a hard incompatibility +09:54 < geertu> unless we decide the "programming model" doesn't differ, and soc_device_match() is OK +09:55 < geertu> for this purpose +09:55 < horms> yes, i wonder what "programming model" means +09:55 < geertu> "does it work with an unmodified driver" +09:55 < horms> I think that in the long run renesas,pfc-r8a7795 should match what (first) goes into mass production +09:56 < horms> which seems unlikely to be es1 +09:57 < geertu> Then we have no choice but to go for soc_device_match() +09:58 < horms> I see your point that using soc_device_match() would make that goal easier +09:58 < horms> goal = using renesas,pfc-r8a7795 with mass production chops +09:58 < horms> well, my goal :^) +09:59 < horms> what do you think is the best way forwards +09:59 < horms> iirc you advocated using soc_device_match() in Berlin but a consensus was not reached in the group +09:59 < geertu> If that is the goal, we have to go for soc_device_match() +10:00 < horms> ok +10:00 < geertu> which is fine for me (the "programming model" is IMHO a gray array for PFC) +10:00 < horms> i think we need to continue this discussion with Magnus in the room as I'm sure he has an opinion on this +10:01 < horms> tbh i'm kind of disturbed if Mark Rutland is setting policy we have to follow +10:01 < horms> but if its grey then i have few complaints +10:01 < geertu> This is not really a new policy +10:01 < horms> ok, he was just stating the existing best practice? +10:02 < shimoda> I have a question for ES2.0 support of PFC +10:02 < shimoda> RFC patch of pfc-r8a7795.c said +10:02 < shimoda> } else { +10:02 < shimoda> pr_info("%s: R-Car H3 >= ES2.0\n", __func__); +10:02 < shimoda> // FIXME Fixup r8a7795_pinmux_info for ES2.0 +10:02 < shimoda> } +10:03 < shimoda> what will be appear at FIXME line? +10:03 < shimoda> i cannot image it yet.. +10:03 < geertu> Code to modify struct sh_pfc_soc_info r8a7795_pinmux_info +10:04 < geertu> e.g. to point to the r8a7796 tables instead, and patch them where needed +10:06 < geertu> Does that explanation help? +10:06 < shimoda> i see. the r8a7796 tables is in pfc-r8a7796.c? or copy & paste it into pfc-r8a7795.c? +10:06 -!- horms2 [~horms@217.111.208.18] has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org] +10:07 < geertu> shimoda: The r8a7796 tables are indeed in pfc-r8a7796.c +10:07 < geertu> If we start with separate full tables, the code would make r8a7795_pinmux_info point either to the ES1.x or the ES2 tables +10:09 < shimoda> i got it. for now some tables are "static". so should we modify the "static" for it? +10:10 < geertu> If needed, we ahve to drop the static and/or const +10:10 < shimoda> Thank you! I understood it! +10:11 < geertu> Good. +10:11 < geertu> Anyone who's also in MultiMedia who knows about "HDMI out" state? +10:12 < morimoto> Maybe Ulich +10:13 < horms> morimoto: maybe he is absent +10:14 < morimoto> He has such additional task I think (prototype) +10:14 < morimoto> After that Laurent will work for upstreaming +10:15 < neg> I got some reports from Fukawa-san at Renesas who was testing VIN+DU on both VGA and HDMI out on H3 (i think) so something seems to work +10:17 < geertu> So it's WIP +10:18 < geertu> If it's working, I can add it to renesas-drivers +10:18 < pinchartl> geertu: the plane was late, I'm in the train back home, and my luggage is sill in JFK +10:18 < geertu> pinchartl: Oops +10:19 < horms> at least you arrived on the scheduled day :) +10:19 < geertu> pinchartl: The crew had to vote first? ;-) +10:19 < pinchartl> please proceed without me today :-) +10:20 < geertu> I think we're almost finished. +10:21 < geertu> Unless someone has something to add (subtract, multiply, divide, ...)? +10:22 < horms> nothing from my side +10:22 < shimoda> nothing from me +10:24 < geertu> Thanks for joining, and have a nice continued day diff --git a/wiki/Chat_log/20161109-mm-chatlog b/wiki/Chat_log/20161109-mm-chatlog new file mode 100644 index 0000000..edecba3 --- /dev/null +++ b/wiki/Chat_log/20161109-mm-chatlog @@ -0,0 +1,390 @@ +2016-11-09 Multimedia group chat report + +We had a multimedia group meeting on 2016-11-09. Here's a summary of the +discussions. Please correct any mistake you would notice. + +Attendees: + +- Kieran +- Laurent +- Morimoto-san +- Niklas + +Magnus and Ulrich were absent. + + +Topic 1. Status check for the multimedia tasks +---------------------------------------------- + +* Kieran + +Since last meeting: + +- VSP1 writeback prototype submitted + +Frames can be successfully grabbed from the V4L2 video node. Awaiting reviews +on DRI/media lists. + +- Partition Algorithm improvements posted + +Still need to see if/how display list objects can be reused. + +For the next two weeks: + +- Start on Q4/2 tasks +and/or +- Try to reuse display lists for VSP partitions + +Issues and Blockers: None + + +* Laurent + +Since last meeting: + +- Attended Kernel Summit and Linux Plumbers Conference + +Posted a few reports on the periperi mailing list on topics of interest for +the upstreaming team. No more report planned, but please feel free to ask +questions. + +For the next two weeks: + +- Follow up on the LVDS mode selection patches. +- Post a proposal for the rotation and histogram APIs. +- Post a few misc DU and VSP patches forward-ported from the BSP. + +Issues and Blockers: + + +* Morimoto-san + +Since last meeting: + +- Posted HDMI+sound patch. +- Posted ALSA SoC OF-graph base patch-set. +- Posted ALSA SoC framework cleanup patch-set. + +All the above are under review. + +- Worked on BSP team sound issue +- M3 board export paper work for new guys + +For the next two weeks: + +- Follow up on the posted patches + +Issues and Blockers: + +- American people seem to have selected Mr. Trump. + + +* Niklas + +Since last meeting: + +- Posted new rewritten VIN Gen3 driver (uses media controller +framework) with M3-W support and a refreshed CSI2 driver. + +- Got a VIN->DU test-case working on Gen2 and Gen3 + +A VIN tests repository has been created at https://git.ragnatech.se/vin-tests/. Jacopo is also working on a buffer sharing test application that will +support VIN, VSP and DU, we'll likely merge both. + +HDMI loopback should be used for more automated testing, but it's too early +for Gen3. We'll revisit the topic later. + +For the next two weeks: + +- Address the review comments on the VIN and CSI2 driver. + +Issues and Blockers: None + + +Topic 2. Additional tasks for Q4/2 2016 +--------------------------------------- + +SoWs haven't been finalized yet, but should hopefully be by the end of the +week. At this time it looks like we'll have the following tasks. + +- VSP1 race conditions fixes, VSP suspend/resume (Gen2 only, Gen3 requires +more work due to FCP dependency) and Gen3 HDMI output for Kieran + +- Gen3 HDMI output and V4L2 cache management API (upstream discussions only, +actual implementation likely in 2017/Q1) for Laurent + +- Nothing for Niklas as all his time will be consumed by other groups) + +- IPMMU multimedia development (including DU horizontal lines issue) for +Ulrich. Help from the hardware team might be needed, we don't know whether the +issue is caused by software or hardware. + +In parallel Jacopo is working as a trial task on a test application to measure +performances issues, and performance improvements when patches will be ready. + +Fences support isn't planned for Q4 at this time, but will be built on top of +V4L2 fences support that Collabora is working on, likely in 2017/Q1. + + +Topic 3. Next meeting +--------------------- + +The next meeting will be held on 2016-11-23 at 08:00 GMT / 09:00 CET / 10:00 +EET / 17:00 JST. + +h1. Multimedia-chat-meeting-2016-11-09 + +<neg> morning [16:59] +<pinchartl> hello +<horms> hi pinchartl, i will be lurking this morning if you don't mind [17:00] +<pinchartl> no worries [17:01] +<morimoto> hi +<kbingham> Morning all. +<pinchartl> Magnus told me 15 minutes ago he was going back home so I assume + he won't join [17:02] +<pinchartl> let's wait a few minutes for Ulrich +<pinchartl> neg: you thus have a few minutes to send your report by e-mail + [17:03] +<neg> :-) [17:05] +<pinchartl> let's get started [17:06] +<pinchartl> topics for today +<pinchartl> - Status check for the multimedia tasks +<pinchartl> - Additional tasks for Q4/2 2016 +<pinchartl> anything else ? [17:07] +<neg> not that I can think of +<pinchartl> kbingham: you can start [17:08] +<pinchartl> kbingham: it was both a permission and a request :-) [17:09] +<kbingham> A) - I've posted a series for review to implement a prototype + writeback extension to VSP1. Frames can successfully be grabbed + using V4L2 interfaces from the established video node. +<kbingham> hehe +<kbingham> I've also posted a couple of changes to the partition-algorithm to + move some of the calculations to stream on - rather than on every + frame - and provide better restrictions to match the hw + restrictions for the partition-algorithm [17:10] +<kbingham> I've also been playing with ways to try to re-use DL objects - but + that's still a WIP set ... [17:11] +<kbingham> B) - whilst lacking in budget - I will either start on Q4/2 tasks - + or carry on playing with DL's - or continue working to convert my + garage office :) [17:12] +<kbingham> C) No particular blockers currently. +<pinchartl> I think starting with Q4/2 tasks makes sense, let's discuss that + together after this meeting +<kbingham> Ack :) [17:13] +<kbingham> That's me done then ! :-) +<pinchartl> thank you +<pinchartl> my turn +<pinchartl> I've attended the kernel summit and the Linux Plumbers Conference + [17:14] +<pinchartl> I've posted a few reports on the periperi mailing list on topics + of interest for us +<horms> pinchartl: thanks for your report on s2ram +<pinchartl> I don't plan to post any additional report, but if you have + specific questions, please ask +<pinchartl> horms: you're welcome +*** neg_ (~neg@unaffiliated/neg) has joined channel #periperi [17:15] +*** neg (~neg@unaffiliated/neg) has quit: Quit: Reconnecting +*** neg_ (~neg@unaffiliated/neg) is now known as neg +<pinchartl> for the next two weeks I plan to follow up on LVDS mode selection + (I've received a few replies) [17:16] +<pinchartl> post a proposal to the V4L2 mailing list to try and move forward + on VSP rotation and histogram API +<pinchartl> and post a few misc patches ported from the BSP for the VSP and DU + drivers +<pinchartl> no issue or blocker [17:17] +<pinchartl> morimoto: you're next +<morimoto> I'm very glad to start, my lord ! +<morimoto> A) What have I done since last time [17:18] +<morimoto> 1) I posted HDMI+sound patch to ML. +<morimoto> 2) I posted ALSA SoC OF-graph base patch-set. +<morimoto> 3) I posted ALSA SoC framework cleanup patch-set. +<morimoto> these are all under review now +<morimoto> +<morimoto> a) I worked for BSP team sound issue +<morimoto> b) M3 board export paper work for new guys +<morimoto> B) What I plan to do till next time +<morimoto> - continue to post patches +<morimoto> C) Problems I have currently +<morimoto> - American people seems selected Mr.Trump. +<morimoto> --end-- +* horms falls of chair +<pinchartl> regarded the OF-graph implementation, I think you've replied to + John Stulz about his ADV7511 HDMI sound patch series, right ? + [17:19] +<pinchartl> s/regarded/regarding/ +<morimoto> Yes, I think so (I forgot his name, though) +<pinchartl> I briefly talked to him at LPC [17:20] +<pinchartl> you're the expert on OF graph for sound :-) +<pinchartl> but please let me know if I should try to spend more time on those + patches +<morimoto> for DT review ? [17:21] +<pinchartl> yes +<morimoto> If he can follow my OF-graph base HDMI sound DT, he should wait + [17:22] +<morimoto> because my patch-set is not yet accepted. +<morimoto> there is no responce form OF maintainer (= Rob) +<morimoto> s/form/from/ +<pinchartl> do you think he should wait, or use non OF-graph DT bindings ? + [17:23] +<morimoto> I think HDMI should use OF-graph DT, and this is your opinion, + right ? +<pinchartl> yes [17:24] +<pinchartl> thanks for the confirmation +<pinchartl> neg: your turn [17:25] +<neg> A) +<neg> - Posted new rewritten VIN Gen3 driver (uses the media controller + framework) with M3-W support and a refreshed CSI2 driver +<neg> - Got a VIN->DU test-case working on Gen2 and Gne3 \o/ +<morimoto> pinchartl: your welcome +<neg> B) Address the review comments on the VIN and CSI2 driver +<neg> C) None +<pinchartl> nice work for VIN -> DU [17:26] +<pinchartl> it would make sense to add that to a test suite +<pinchartl> I wonder which one though +<pinchartl> maybe a new one ? +<pinchartl> Jacopo is working on a test application for buffer sharing that + will also support the VSP +<pinchartl> so merging the two would make sense [17:27] +<neg> yes I have started on a vin-tests repo at + https://git.ragnatech.se/vin-tests/ +<pinchartl> what do you think ? +<neg> but it's quiet inmature and could use a lot more work +<neg> yes I spoken a bit with Jacopo and I hope it could be a good fit for + incorperating the VIN->DU test case [17:28] +<pinchartl> VSP tests were easier as they're self-contained +<pinchartl> but VIN unit tests would definitely be useful +<pinchartl> let's keep this in mind for now, it's a bit too early to decide + what to do there [17:29] +<pinchartl> especially for Gen3 +<neg> yes, maybe down the road a HDMI loopback could be used for some + automated testing +<neg> it would be usefull so yes lets keep that in mind [17:30] +<pinchartl> that's what I was thinking about +<pinchartl> next topic, additional tasks for Q4/2 [17:31] +<pinchartl> SoWs have still not been finalized, but we're getting close + (hopefully by the end of this week) [17:32] +<pinchartl> in addition to what has already been proposed, Renesas requested + Kieran to help with the HDMI output upstreaming for Gen3 + [17:33] +<morimoto> for next additional ? +<pinchartl> for second half of Q4 +<morimoto> OK +<kbingham> pinchartl: OK. [17:34] +<pinchartl> does anyone have anything they would like to discuss ? +<kbingham> pinchartl: Is there an existing branch/patchset somewhere? +<pinchartl> kbingham: yes, let's sync up after the meeting [17:35] +<kbingham> Ok. +<morimoto> pinchartl: can I confirm (?) +<morimoto> this is not related to additional, but will be additional +<pinchartl> I'm not sure to understand the difference :-) [17:36] +<morimoto> do you have plan for "cache less" task ? +<pinchartl> yes, I'll start discussions on V4L2 API extensions for that + [17:37] +<pinchartl> in parallel Jacopo is working on a test application to measure + performances issues +<pinchartl> and performance improvements, when patches will be ready +<pinchartl> that's all for Q4/2 [17:38] +<pinchartl> note that only API discussions are planned for Q4/2, the actual + implementation will likely be in 2017/Q1 +<morimoto> OK, nice to know. and how about "Fence" ? +<pinchartl> fences support isn't planned yet, it will likely be for 2017/Q1 +<morimoto> OK [17:39] +<pinchartl> Collabora will likely post patches to add fence support in V4L2 in + the next few months +<pinchartl> so the plan is to do something else until they have posted those + patches, and add fence support to the VSP driver on top of them +<pinchartl> to avoid duplicating the work +<morimoto> OK, nice plan [17:40] +<morimoto> How about "horizontal bug" ? +<pinchartl> the IPMMU issue ? +<morimoto> Maybe +<pinchartl> Ulrich will look at that, again for Q4/2 +<morimoto> I wonder does he need Renesas HW guy's help ? [17:41] +<morimoto> is it HW issue ? or SW issue ? +<pinchartl> that's a good question +<pinchartl> I don't know at this point +<morimoto> OK, I will talk with BSP team about it. [17:42] +<pinchartl> thanks +<morimoto> and last question. do you have plan about suspend/resume bug fix ? +<morimoto> vsp1_pm_suspend() +<morimoto> Oops, it need normal suspend/resume base. maybe next year ? [17:43] +<horms> pinchartl: i have two questions if there is time at the end [17:44] +<pinchartl> Kieran will look at that for Q4/2 on Gen2. for Gen3 we neeed + additional suspend/resume core work, that will be for 2017/Q1 +<kbingham> pinchartl: You know I don't have any G2 hardware right :D [17:45] +<pinchartl> kbingham: good point :-) it can be emulated on Gen3 though, with a + small hack to make sure the FCP won't be suspended at the wrong + time [17:46] +<pinchartl> the point isn't so much to work on Gen2 but to fix the issues + internal to the VSP driver +<kbingham> Ok! +<pinchartl> the suspend/resume issues caused by the dependency on FCP are out + of scope at this time [17:47] +<pinchartl> horms: go ahead [17:48] +<horms> 1. How does Jacopo fit into things? Is he working with us these days? +<pinchartl> he's working on a trial task +<horms> ok, thanks. [17:49] +<pinchartl> his task is to write a buffer sharing application +<pinchartl> and we'll use it to measure performance issues and improvements + related to cache management +<horms> 2. I am wondering what the status of your upporting from BSP work + is. Mainly because as you know its reporting season and I'd like to be + sure I have any pending updates in my report. +<pinchartl> I have to send a report about that by 11/M [17:50] +<horms> ok, I got a patch from him last week. I wasn't aware he was on our + team. Its good to know. +<pinchartl> I'll submit the simple patches +<pinchartl> and will list areas that need more work +<pinchartl> based on the spreadsheet that you provided +<horms> superb, thanks +<horms> fwiw kaneko san will start analysing the 3.4.0.rc1 BSP [17:51] +<pinchartl> by the way, the spreadsheets hosted on google docs and attached in + the osdr wiki are different +<pinchartl> that's a bit confusing +<horms> which iirc was released last week +<horms> ok +<horms> i'll look into that +<horms> probably best to delete the copy in the wiki as the google one keeps + changing +<pinchartl> sounds good to me [17:52] +<morimoto> According to Renesas guys, you can buy ULCB board by AMAZON (Now + Gen2, Gen3 soon). I didn't check yet +<horms> thanks, that is also good to know [17:53] +<morimoto> pinchartl: +1 question. Is HDMI out upstreaming for long-term ? + [17:54] +<morimoto> I mean it takes long-term ? +<pinchartl> the idea is to post a patch series for upstreaming before the end + of the year +<pinchartl> it might not contain all features +<pinchartl> but it should be an upstream candidate, with no known local hacks + [17:55] +<morimoto> what is the difference between Ulrich's prototype ? +<horms> pinchartl: which link are you referring to on the wiki? +<pinchartl> the prototype contains hacks +<pinchartl> I'll clean that up to make it all upstreamable +<morimoto> Ahh, OK. +<pinchartl> horms: + https://osdr.renesas.com/projects/linux-kernel-development/wiki/Miniperi-2016-10 + [17:56] +<pinchartl> there's a bsp_patch_list_20160930.xlsx file attached there +<horms> ok, i see +<horms> that is the list generated by the BSP team [17:57] +<pinchartl> ok [17:58] +<pinchartl> I've used that as a starting point [17:59] +<pinchartl> next topic: next meeting +<pinchartl> I proposed two weeks from now +<pinchartl> at the same time +<pinchartl> 2016-11-23 at 08:00 GMT / 09:00 CET / 10:00 [18:00] +<pinchartl> EET / 17:00 JST +<neg> that works for me +<kbingham> should be fine here. [18:01] +<pinchartl> approved :-) +<pinchartl> I propose adjourning this meeting +<pinchartl> does anyone second ? +<neg> second [18:02] +<pinchartl> thank you everybody for attending +<kbingham> Have a good day all! +<neg> thanks all, bye +<pinchartl> :q [18:04] +<pinchartl> oops :-) +<morimoto> bye diff --git a/wiki/Chat_log/20161110-io-chatlog b/wiki/Chat_log/20161110-io-chatlog new file mode 100644 index 0000000..c1b2a8d --- /dev/null +++ b/wiki/Chat_log/20161110-io-chatlog @@ -0,0 +1,244 @@ +--- Log opened Thu Nov 10 08:59:02 2016 +08:59 -!- wsa_ [~wsa@p5B38561D.dip0.t-ipconnect.de] has joined #periperi-io +08:59 -!- Irssi: #periperi-io: Total of 5 nicks [1 ops, 0 halfops, 0 voices, 4 normal] +08:59 < wsa_> hi guys +08:59 -!- Irssi: Join to #periperi-io was synced in 7 secs +08:59 -!- shimoda [~shimoda@relprex3.renesas.com] has joined #periperi-io +08:59 < geertu> Mornin' +08:59 < shimoda> hi +08:59 < uli___> hello +09:00 < neg> morning +09:01 -!- Irssi: #periperi-io: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal] +09:01 <@morimoto> Hi +09:05 < wsa_> so, let's start +09:05 < wsa_> (and hope simon will come later) +09:06 < wsa_> well, the updates are on the mailing list, i think no need to repeat them here, or? +09:07 < wsa_> so, in addition to the topics I posted yesterday, there seems to be one more from Shimoda-san about error handling in SDHI +09:07 < wsa_> please feel free to add topics on-the-fly +09:07 < shimoda> i also have one things about serial driver +09:07 < wsa_> ok +09:07 < wsa_> let's start with that :) +09:10 < wsa_> ? +09:10 < shimoda> this mean from me? +09:12 < wsa_> yes, the serial driver thing +09:12 < shimoda> ok +09:12 < shimoda> I got an answer from Geert-san about hardware flow control. +09:12 < shimoda> But I got another question from bsp team. +09:13 < shimoda> after the kernel boot, the kernel accepts to change the baudrate and/or hardware flow control? +09:13 < shimoda> I googled it but i could not any information for now... +09:13 < geertu> shimoda: For the console? +09:13 < shimoda> do you know this? +09:13 < shimoda> yes, on the serial console +09:14 -!- horms [~horms@217.111.208.18] has joined #periperi-io +09:14 < geertu> I don't think you can change the serial console parameters after boot. +09:15 < geertu> Except for difference between earlyprint/earlycon (which should not be enabled for production) and the real serial driver +09:15 < geertu> earlyprint/earlycon depend on bootloader setup +09:16 < wsa_> I can't recall such a feature either +09:16 < geertu> real serial driver depends on console= (incl. speed) and stdout-path (incl. (a possible different) speed) +09:17 < geertu> When userspace starts, init may start a getty, possibly using a different speed +09:19 < shimoda> after started a getty, a linux should not accept to change the parameter? +09:20 < wsa_> if you respin getty? +09:20 < shimoda> if user use stty +09:20 < geertu> Yeah, I was just trying that... +09:21 < geertu> Seems to work +09:21 < geertu> stty speed 38400 < /dev/ttySC0 +09:22 < shimoda> yes, i also tried on salvator-x. set_terimous will be called, but set_mctrl will be not called +09:22 < geertu> After that the serial console (kernel output) and my shell (userspace) use 38400 +09:23 < geertu> You mean when changing flow control? +09:23 < shimoda> geertu: yes +09:23 < geertu> I don't know if you really want flow control on the serial console. +09:24 < geertu> As it will slow down the kernel output even more +09:24 < shimoda> i also don't know. but, bsp team seems such test cases (changing flow control) +09:25 < geertu> For testing, I always did that on a "spare" serial port (lots of SCIF variants on EXIO connectors) +09:25 < geertu> The reason it doesn't work is probably because of the same flow conrol issue in io/todo +09:27 < shimoda> i see. this means if we fix the issue, we can use the flow control on the serial console? +09:28 < geertu> Probably +09:29 < shimoda> i got it. +09:29 < shimoda> BTE +09:29 < shimoda> BTW, +09:29 < geertu> I'd ike to emphasize that using flow control on the serial console allows the terminal program/host to bring the embedded system to a halt, by keeping CTS deasserted +09:30 < shimoda> do you know a use case that hardware flow is changed at runtime? +09:30 < shimoda> geertu: i see. +09:31 < geertu> Not really. Either you have CTS/RTS wired up, or not. +09:32 < geertu> If outputting of kernel messages is disabled, it may be desirable for a userspace application running on the same serial port, though. +09:33 < shimoda> i got it. thanks! +09:34 < wsa_> ok +09:34 < wsa_> next topic? +09:34 < wsa_> would be MSIOF then +09:35 < wsa_> am I still aligned? We won't support H3 1.0 and 1.1 upstream +09:35 < wsa_> Geert will test M3-W soon, and we expect H3 2.0 to be working? +09:36 < geertu> I don't know about ES1.1. Probably it won't work, as it was said that the issue would be fixed in ES2.0 +09:37 < wsa_> and the workaround patch (a25a29f3ccd7d4a0809cf6833c97c9748097b8ac) in the BSP is not suitable for upstream? +09:38 < shimoda> i heard both es1.0 and 1.1 have a bug on MSIOF +09:38 < geertu> I have no idea what that patch is really intended to do, but it didn;t fix the issue for me +09:38 < wsa_> ok :) +09:41 < wsa_> can you update that info in Simon's list? +09:42 < wsa_> about this task: +09:42 < wsa_> MSIOF,v4.10,public,ulrich,Develop MSIOF test case using MMC-over-SPI for Gen2 +09:42 < wsa_> It is still marked as public because of the CS GPIO issue +09:42 < wsa_> I think it makes sense to mark this done and make the CS GPIO issue a seperate task +09:42 < wsa_> ? +09:43 < uli___> i think it would +09:43 < geertu> FYI, a similar issue has been fixed last week for atmel_spi +09:44 < uli___> thanks for forwarding that to me, btw +09:45 < wsa_> can I have a link to that? +09:47 < geertu> [PATCH v2] spi: atmel: use managed resource for gpio chip select +09:47 < wsa_> ok, so I'll change the todo accordingly, seems really a seperate issue +09:47 < wsa_> thanks +09:47 < geertu> Bad lkml.org +09:47 < geertu> commit 9610620078a3900e7fad82de620ce809fd29ba60 +09:48 < geertu> in spi/for-next +09:48 < wsa_> thanks +09:49 < wsa_> can we benefit from that commit? +09:49 < geertu> I think it can be used as an example +09:50 < wsa_> ok, thanks +09:51 < wsa_> next topic would be thermal driver +09:51 < wsa_> but khiem is not here +09:52 < geertu> May I ask about i2c demux? +09:52 < wsa_> sure +09:53 < geertu> Doesn't DVFS use a lower voltage on the i2c bus? +09:53 < geertu> IIRC it has special 1.8v i2c masters +09:53 < geertu> How to multiplex that with iic/i2c on Lager? +09:54 < wsa_> does it? need to check that +09:54 < wsa_> thanks for this input +09:55 < wsa_> will check for sure :) +09:56 < wsa_> so, most fun topic probably: +09:56 < wsa_> meeting at FOSDEM? :) +09:56 < wsa_> I'll be there +09:56 < wsa_> who else? +09:57 < geertu> I will +09:57 < horms> I don't think I _need_ to be there. But I think I can be there if we have a meet-up. +09:57 <@morimoto> Maybe I and magnus will +09:57 < uli___> can't say for sure yet +09:58 < shimoda> maybe I will not be there. if i go, i should update my passport :) +09:58 < wsa_> geertu: how are chances for a core group meeting currently? +09:59 < neg> If there is a meeting I will be there for both FOSDEM and meeting +09:59 < geertu> Haven't received much feedback about that yet. +09:59 < geertu> I know you (nocore) and Laurent (core) will be there +10:00 < wsa_> ok +10:00 < geertu> OK, and neg +10:00 < geertu> And Simon +10:00 < geertu> And Magnus and Morimoto-san +10:00 < geertu> Critical mass reached? +10:01 < wsa_> looks to me like we declare a critical mass if we say there will be a meeting +10:02 < geertu> Ah, chicken and egg +10:02 < wsa_> let's brainstorm further on the mailing list to keep all in the loop +10:02 < geertu> OK, for core we'll have a meeting +10:02 < geertu> :-) +10:02 < geertu> What are your feelings about I/O? +10:03 < geertu> (w.r.t. meeting) +10:03 < wsa_> heh +10:03 < wsa_> i think it would be nice to have one +10:04 < wsa_> maybe half a day IO, half a day core on Friday, and then head for the beer event? :) +10:04 < wsa_> ok, i am brainstorming already :D +10:05 < geertu> Sounds like a good idea +10:05 < wsa_> i'll post a mail +10:06 < wsa_> oh, i forgot one topic +10:06 < horms> fwiw, that plan sounds good to me +10:06 < wsa_> shimoda: there is request for additional error reporting on SDHI autcmd12? +10:06 < wsa_> did i get this right? +10:06 < shimoda> yes +10:08 < shimoda> the mmc/card/block.c has ECC error handling +10:08 < shimoda> just use single read mode instead of multiple read though :) +10:09 < shimoda> but the tmio driver seems that the response of multiple read/write is as autocmd12 things +10:10 -!- horms_ [~horms@217.111.208.18] has joined #periperi-io +10:10 < wsa_> so, I should add a new task about ECC handling for SDHI? +10:10 -!- horms [~horms@217.111.208.18] has quit Ping timeout: 256 seconds +10:10 -!- horms_ is now known as horms +10:11 < shimoda> i think not ecc handling but to be suitable response value should be returned when cmd18/25 with autocmd12 +10:12 < shimoda> so, +10:13 < shimoda> SDHI,?,?,?,fix response when cmd18/25 with autocmd12 +10:13 < shimoda> what do you think? +10:13 < wsa_> ok +10:13 < wsa_> will add +10:14 < shimoda> thanks! +10:14 < wsa_> ok, i have nore more topics except a adv7180 question for neg +10:15 < wsa_> so, if there is something more from your side, fire now :) +10:16 < wsa_> ok, then +10:16 < wsa_> thanks guys +10:17 < wsa_> have a great rest of the week +10:17 < neg> thanks all +10:17 <@morimoto> thanks +10:17 < geertu> byem thx +10:17 -!- morimoto [~user@relprex2.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +10:18 < shimoda> thanks, bye! +10:18 < horms> bye +10:18 < wsa_> neg: you have a minute +10:18 < wsa_> ? +10:18 < uli___> bye +10:18 < neg> sure +10:18 -!- uli___ [~uli___@static.206.203.46.78.clients.your-server.de] has left #periperi-io ["Leaving"] +10:19 < wsa_> i'd just like to know if you know if the adv7180 driver can be re-bound? +10:19 < wsa_> currently it oopses with i2c-demux +10:19 < wsa_> which basically does unbind/bind +10:19 < wsa_> do you know if that should be supported or if there are known issues with that? +10:20 < neg> I don't know if it can be rebound, I saw the oops and want to look in to it but other work got in the way :-( +10:21 < wsa_> ok +10:22 < wsa_> cc me on updates to that issue, please +10:22 < wsa_> and simon probably, too? +10:23 < wsa_> horms: ? +10:23 * horms is reading +10:23 < horms> yes, please keep me in the loop +10:24 < horms> wsa_: I suggest moving forwards with the patches that have no issues +10:24 < wsa_> i agree +10:25 < horms> excellent +10:26 < horms> what is the path forwards there? +10:26 < horms> rebase and repost? +10:26 < wsa_> i'll apply the i2c patch today for 4.9 +10:26 < horms> ok, that is a run-time dependency, right? +10:27 < wsa_> yes +10:27 < wsa_> it makes i2c-gpio work again +10:27 < horms> things blow-up with out it? +10:27 < wsa_> otherwise -ENODEV +10:27 < wsa_> no OOPS, just bailing out +10:28 < horms> hmm, ok. so by default things work +10:28 < horms> but if you try to switch i2c then it fails? +10:28 < wsa_> but I think you could just apply the patches with no issues for 4.10 +10:28 < horms> right v4.10 sounds good +10:28 < wsa_> yes +10:28 < horms> i'm just wondering if i can put them on top of v4.9-rc1 (which is best for me) +10:28 < horms> or if I need some other branch/rc +10:29 < horms> it sounds like I can go with v4.9-rc1 as there is no regression +10:29 < wsa_> yes +10:29 < horms> if so, can you rebase them on renesas-next? +10:29 < wsa_> they are rebased to renesas-drivers? +10:30 < horms> I'm unsure +10:30 < horms> that would probably also be ok +10:31 < wsa_> can you try and tell me if not ok? +10:31 < horms> well some rebasing is required in order to drop the patches we agreed on +10:31 < horms> but I can try doing that if you prefer +10:32 < wsa_> i see +10:33 < horms> how about i try +10:33 < horms> and get back to you if its a bit of a pain +10:33 < horms> will you be hanging around here this morning? +10:33 < wsa_> pfff +10:33 < horms> if not i can email you :) +10:33 < wsa_> until when can you apply the patches? +10:34 < horms> well, i can try doing so now +10:34 < wsa_> "pfff" was about the whole rebasing issue +10:34 < wsa_> no, i mean latest, because maybe neg will have adv7180 updates till then? +10:34 < wsa_> dropping the DVFS patch is super easy +10:34 < horms> ok +10:34 < wsa_> and maybe we can get the HDMI patches into 4.10 as well +10:35 < horms> wednesday next week +10:35 < horms> at the absoloute latest +10:35 < wsa_> would be my favourite since those i2c slave nodes tend to change anyhow +10:35 < wsa_> ouch +10:35 < horms> but I suggest queing up what we can now +10:35 < horms> to try to make things less painful next week +10:36 < horms> even if neg fixes adv7180 there will probably be some sort of depdendency +10:36 < wsa_> agreed +10:37 < neg> a qucik test on Koelsch shows the adv7180 should be able to handle a unbind/bind +10:37 < neg> echo 2-0020 > /sys/bus/i2c/drivers/adv7180/unbind +10:37 < neg> echo 2-0020 > /sys/bus/i2c/drivers/adv7180/bind +10:37 < neg> but the VIN driver have issues after that cycel :-( +10:38 < wsa_> did you use shmobile_defconfig? +10:40 < neg> yes with the following additions CONFIG_CGROUPS=y, CONFIG_CMA=y, CONFIG_SECCOMP=y, CONFIG_DMA_CMA=y, ONFIG_CMA_SIZE_MBYTES=64, CONFIG_VIDEO_ADV7604=y +10:40 < neg> CGROUPS and SECCOMP needed since I use systemd init, CMA needed to use VIN with large frame sizes, and ADV7604 needed for HDMI input +10:44 < wsa_> ok +10:45 < wsa_> need to logout here now +10:45 < wsa_> horms: i am available via mail +10:45 < horms> wsa_: ok. i will proceed with quing up some patches and let you know how it goes +10:47 < wsa_> thanks +10:47 < wsa_> cya guys! +--- Log closed Thu Nov 10 10:47:46 2016 diff --git a/wiki/Chat_log/20161122-core-chatlog b/wiki/Chat_log/20161122-core-chatlog new file mode 100644 index 0000000..60c25b8 --- /dev/null +++ b/wiki/Chat_log/20161122-core-chatlog @@ -0,0 +1,286 @@ +Core-chat-meeting-2016-11-22 + +09:05 < geertu> Welcome to today's Core Group Meeting! +09:05 < geertu> Agenda: +09:05 < geertu> 1. Status updates +09:05 < geertu> 2. CPG/MSSR reset support +09:05 < geertu> 3. R-Car DMAC transfer termination synchronization support +09:05 < geertu> 4. Shared GPIOs +09:05 < geertu> 5. BSP GPIO question +09:05 < geertu> Topic 1. Status updates +09:05 < geertu> A) What have I done since last time +09:05 < geertu> B) What I plan to do till next time +09:06 < geertu> C) Problems I have currently +09:06 < geertu> First is Ulrich. +09:06 < geertu> -ENODEV +09:06 < geertu> Second is Simon +09:07 < horms> Status: +09:07 < horms> A) What have I done since last time +09:07 < horms> * No core task at this time +09:07 < horms> B) What I plan to do till next time +09:07 < horms> * See above +09:07 < horms> C) Problems I have currently +09:07 < horms> * Push back from Olof on pull-requests: under discussion with him +09:07 < horms> * Gen3 Suspend-to-RAM: What are the next steps (same as last time) +09:07 < horms> -- end -- +09:07 < geertu> I think the next step is +09:07 < geertu> r8a7796,?,noplan,?,Investigate suspend-to-idle +09:07 < horms> got it +09:08 < geertu> About Olof, looks like he was not very responsive yesterday? +09:08 < horms> yes +09:09 < horms> i am concerned that he may continue to be unresponsive +09:09 < horms> and drivers + arm32 will simply not be included in v4.10 +09:09 < horms> to be frank, not responsinve is the normal mode of operation +09:09 < geertu> And every user who wants to use soc_device_match() in v4.11 will have to import an immutable branch? +09:10 < geertu> Let's wait and see? +09:10 < horms> I think wating a little is resonable +09:10 < horms> but I also think we need to consider what plan B should look like +09:10 < horms> that doesn't need to be discussed in this meeting +09:11 < geertu> Looks like there will be an -rc8, so more time left +09:11 < geertu> Thanks Simon. +09:11 < geertu> Next is Shimoda-san +09:11 < shimoda> yes +09:11 < shimoda> A) B) nothing +09:12 < shimoda> C) I would like to use soc_device_match() for xhci-rcar to supprt H3 ES2.0 +09:12 < shimoda> EOT +09:12 < shimoda> s/supprt/support/ +09:12 < geertu> According to the latest updates to rel/todo, H3 ES2.0 is expected to arrive on 2017-02-31? +09:13 < shimoda> geertu: yes +09:13 < geertu> Or is that the target date of the working software support? +09:13 < pinchartl> geertu: if the hardware really arrives on 2017-02-31 then we'll have to wait a looooong time +09:14 < shimoda> it is arrive date of the hardware +09:14 < shimoda> pinchartl: indeed... +09:15 < geertu> I understand Tokyo is already writing support for it? +09:15 < pinchartl> any chance it could arrive on 2017-02-28, or 2017-03-03 instead ? :-) +09:16 < horms> pinchartl: its timeless hardware +09:16 * geertu hadn't noticed the invalid date ;-) +09:16 < morimoto> or un-exist hardware ? +09:17 < geertu> Ok, we'll handle it as soon as it arrives, i.e. on Feb. 32. +09:17 < geertu> Thanks Shimoda-san. +09:17 < geertu> Next is Niklas +09:17 < neg> A) PFC drive-strength and bias setting for none-GPIO pins on r8a7795 and r8a7796 posted +09:17 < neg> B) Nothing planed yet, keep talking to Geert and try to find a suitable core task :-) +09:17 < neg> C) None +09:17 < neg> EOT +09:18 < horms> neg: what if any issues are there with drive strength on Gen3? +09:19 < geertu> We still have to enable drive strength for ravb in the .dts, right? +09:20 < neg> horms: I have not seen any issues, on r8a7795 there where none GPIO pins missing in the driver +09:20 < neg> geertu: yes +09:20 < horms> neg: thanks +09:21 < geertu> neg: Will you handle the .dts part? +09:22 < geertu> Probably it'll have a hard dependency on the pfc driver updates (hi Olof ;-) +09:22 < neg> geertu: yes, I was waiting for all PFC parts to be picked up first but then I will +09:23 < horms> any chance the PFC (driver) parts can be included in v4.10? +09:23 < geertu> neg: It wouldn't hurt to have it in renesas-drivers (not today, though) +09:23 < geertu> horms: For r8a7795, it will (cfr. pinctrl/for-next) +09:24 < geertu> I don't plan to send any more clk/pinctrl pull request for v4.10, though. +09:24 < horms> ok, thenk the DT portion could go into v4.11, right? +09:24 < geertu> Yep. +09:24 < horms> a related question. how late in the cycle does LinusW take (PFC) patches? +09:25 < geertu> Or late v4.10 (as in: example for a bug fix needed for people doing their own boards and boot loaders) +09:25 < neg> geertu: yes, I will have it ready for next weeks renesas-drivers, you and Laurent have reviewd the PFC driver so it should be OK for .dts now +09:25 < geertu> horms: I'm not so sure. Quite late, I think. +09:25 < horms> ok. of course if its a bug fix then we can submit dt changes for v4.10. +09:26 < geertu> horms: You're thinking about having drive strength for r8a7796 in v4.10, too? +09:26 < horms> I have no particular thoughts +09:26 < horms> other than that if driver changes are in version n then its easy to add dt changes to version n+1 +09:27 < geertu> Yep, it's easy. The issue is if you want it earlier ;-) +09:27 < horms> s/easy/easier/ +09:27 < horms> I am in no rush +09:27 < geertu> ok +09:27 < horms> sorry for giving the impression that I was +09:27 < geertu> Thanks Niklas +09:27 < geertu> Next is Morimoto-san +09:28 < morimoto> int a, b, c; +09:28 < morimoto> +09:28 < morimoto> a = b = c = -ENOTASK; +09:28 < morimoto> +09:28 < morimoto> return 0; +09:28 < morimoto> +09:28 < geertu> return -EPROBE_DEFER? +09:28 < morimoto> no idea :) +09:29 < geertu> morimoto: you found the hard drive? +09:29 < morimoto> But I need to know BSP team's question answer :) +09:29 < geertu> Sure, that's a separate topic. +09:29 < morimoto> hard drive ? +09:29 < geertu> "Our team's server HDD has gone" (HDD != hard disk drive?) +09:30 < morimoto> Ahh, yes ! +09:30 < morimoto> I re-start works for us :) +09:30 < geertu> Good. +09:30 < morimoto> Thanks +09:30 < geertu> morimoto: About TDSEL: Sure there must be documented HDL source code for R-Car Gen2? +09:31 < morimoto> Maybe, but I don't know +09:31 < pinchartl> geertu: s/documented // +09:31 < morimoto> HW team is busy +09:32 < geertu> OK +09:32 < pinchartl> morimoto: if we can get the HDL source we can have a look and find out :-) +09:32 < geertu> Can I include it in renesas-drivers? +09:32 < morimoto> 1) Maybe HW team doesn't give it to me +09:32 < morimoto> 2) It can't export to you guys +09:33 < morimoto> I can't export +09:33 < horms> morimoto: i think they were joking :) +09:33 < morimoto> :( +09:33 * geertu was +09:33 < geertu> THanks, Morimoto-san +09:33 < morimoto> geertu: what is "it" mean ? +09:33 < geertu> Next is Magnus +09:34 < geertu> it == HDL source +09:34 < geertu> -EJAPANESE_LESSON? +09:34 < morimoto> Ahh, of course not +09:34 < geertu> Next is Laurent +09:34 < morimoto> -EDRINKING +09:35 < pinchartl> nothing to report +09:36 < geertu> Thanks Laurent +09:36 < geertu> Next is Khiem +09:36 < geertu> -EINTR? +09:37 < geertu> Next (last) is Geert +09:37 < geertu> A) What have I done since last time - Completed SoC identifaction - Queued up RZ/G1M and RZ/G1E clock drivers, - Sent more clock and pinctrl pull requests, +09:37 < geertu> B) What I plan to do till next time - Coerce Simon into taking all MODEMR related patches, - Investigate IPMMU and Ethernet +09:37 < geertu> C) Problems I have currently - What's wrong with the IPMMU and Ethernet? +09:37 < geertu> (hm, bad formatting. should switch to .rst?) +09:38 < geertu> Anyone else who tried IPMMU and had mixed results? +09:38 < horms> For B, we need to to take into account our recent interation with Mr. Olof. Probably after the current round of bother blows over. +09:38 < pinchartl> geertu: there's "a bit" of corruption on the screen when IPMMU is enabled for the VSP/DU +09:39 < geertu> B depends on the RST series, which is going in through clk +09:39 < shimoda> pinchartl: about VSP/DU with IPMMU, did you try on M3? +09:40 < geertu> pinchartl: Corruption could explain it. I haven't dug deeper into it, but NFS root works initially, then the network stops working (on M3) +09:40 < pinchartl> shimoda: not personally, no +09:41 < neg> I have problem on H3 and VIN+IPMMU, corruption on VIN1 but not on VIN0 if I look at the video using applications but works fine in VIN->DU +09:42 < shimoda> pinchartl: i see. H3 ES1.x has an issue about ipmmu. if multiple request happens from hw, the IPMMU TLBs will currupt +09:43 < pinchartl> shimoda: that could explain it +09:43 < pinchartl> we should retest everything on M3 +09:43 < shimoda> pinchartl: I think so +09:43 < geertu> Any known issues on M3? +09:45 < shimoda> geertu: about IPMMU? if so, no serious issue on M3, but some performance issues exist +09:46 < geertu> OK +09:46 < geertu> Let' +09:46 < geertu> s continue +09:46 < geertu> Topic 2. CPG/MSSR reset support +09:46 < geertu> From morimoto-san +09:46 < geertu> We would like to have MSTP::Reset feature for each devices, +09:46 < geertu> it is requested on HW user manual (maybe we don't have it ?). +09:46 < geertu> This Reset is necessary on initial time. +09:46 < geertu> First of all, who should handle it ? by Linux ? by IPL ? +09:46 < geertu> If answer was "IPL", we will ask it to BSP guys. +09:46 < geertu> If answer was linux, it can be Core topics. +09:46 < geertu> I guess it should be handled by pm_runtime_xxx() ? +09:46 < geertu> EOT +09:47 < geertu> To me, it looks like this should be handled by the CPG/MSSR driver (the old MSTP driver cannot easily be extended for that) +09:48 < pinchartl> I agree. there's a reset controller API in the kernel that can be used for this purpose +09:48 < geertu> I'm a bit puzzled by the conflicting "This Reset is necessary on initial time." and "I guess it should be handled by pm_runtime_xxx()" +09:48 < morimoto> please drop last comment +09:48 < geertu> It's still a bit unclear how this is supposed to be used. +09:48 < morimoto> it is just my opinion +09:48 < geertu> OK +09:49 < geertu> From a quick look, drivers call into the reset controller API when they want to reset a module? +09:49 < geertu> But that means the driver for the module is in control, why we need reset for all modules on initial time? +09:49 < geertu> Also, what does the "HW user manual" say? +09:50 < pinchartl> could "initial time" mean "probe time" ? +09:51 < geertu> Possibly. +09:52 < geertu> Or "resume" time? (with "DDR backup" in the BSP) +09:52 < morimoto> Above my comment (= pm_runtime_xxx) was based on every "use time" +09:52 < geertu> If this is a common requirement, it would be good to handle it in common infrastructure, and not in each individual driver (cfr. PM domains) +09:53 < geertu> morimoto: Note that each time you reset the module, all registers are changed to their reset values +09:54 < morimoto> Yes, I know. Each driver shouldn't assume it can keep register settings IMO +09:56 < geertu> If you reset the module on every pm_runtime_get_sync(), you have to restore all registers all the time, which will kill performance +09:57 < morimoto> But it is necessary if you want to support Suspend/Resume. +09:57 < morimoto> Suspend will kill Power, and all register value will gone +09:57 < geertu> If "reset on initial time" is the only thing we need, then the CPG/MSSR driver could reset each module the first time its clock is enabled. +09:58 < geertu> morimoto: Sure, but that doesn't mean we have to do it in every pm_runtime_get_sync(), only when resuming. +09:58 < morimoto> Current R-Car doesn't have PowerDomain, so maybe yes. But if SoC has PowerDomain, it needs +09:59 < geertu> If Suspend kills power, we have to reset the module after resume, too? +09:59 < morimoto> If SoC has PowerDomain, and if no user exist, module power will be killed +10:01 < pinchartl> Gen3 has power domains +10:01 < geertu> Yes, and we already have to handle that in drivers shared with SH/R-Mobile, which does have power domaains +10:02 < geertu> Still, it would be good to know what the "HW user manual" says... Is that document available? +10:02 < morimoto> About Reset, maybe it is needed on Probe time, and resume time. +10:02 < morimoto> My pm_runtime_xxx is related a little bit different topic +10:02 < pinchartl> one concern I have with resetting modules is that the secure firmware might poke with some (possibly undocumented) registers after resume. if we then reset the modules, things might start breaking +10:03 < geertu> Can't the secure firmware prevent us from resetting some modules? +10:05 < pinchartl> indeed it can +10:06 < geertu> I think we need to know more of the "why" behind this request. We've been living without resetting modules for many years. +10:07 < pinchartl> for some modules, though, it would be useful, if only as a workaround +10:07 < pinchartl> for instance the VSP sometimes fail to stop +10:07 < pinchartl> that's most likely cause by a driver bug +10:07 < geertu> OK. That reset under driver control. +10:07 < geertu> Not "This Reset is necessary on initial time" +10:07 < pinchartl> but the failure can be detected, and a module reset could potentially be helpful +10:07 < geertu> s/That/That's/ +10:08 < pinchartl> correct, although I wouldn't mind being able to reset moduls at probe time, to wipe off crazy configurations applied by the boot loader :-) +10:08 < pinchartl> that problem should of course ideally be fixed in the boot loader, which shouldn't apply crazy configurations in the first place +10:08 < geertu> Well, drivers should not make assumptions about the boot loader, and initialize all registers anyway? +10:10 < morimoto> geertu: not all, but some deivce was indicated on datasheet. +10:10 < pinchartl> it's easily to overlook a register whose reset default value is fine +10:10 < morimoto> For example SATA, can you see v0.52 manual, 72.3.10 ? +10:12 < pinchartl> morimoto: I think that what we'd like to know is whether some modules require a reset (as in the module will fail in more or less subtle ways if it's not reset) or if it's more of a good practice rule that would make the BSP team sleep better at night +10:13 < pinchartl> or, to put it differently, what are the problems that will be fixed by resetting modules ? +10:14 < geertu> Exactly. +10:14 < morimoto> SATA, Thermal are indicated on datasheet, Sound was indicated on Application manual +10:14 < geertu> The flow chart in 72.3.10 is indeed interesting +10:14 < morimoto> The reason why BSP team needs it is because it is indicated on datasheet :( +10:15 < geertu> 1. It refers to SASRSTECR (unfortunately in graphical form, so a text search won't find it) +10:15 < geertu> 2. The corresponding CPG/MSSR sections says: This register is functional safety use only. Keep initial value +10:15 < geertu> ??? +10:16 < horms> morimoto: I understand that the BSP team wants to comply with the documentation. But in my experience some kind of run-time behaviour enhancment/fix/... helps to motivate changes in mainline +10:18 < morimoto> horms: do you mean, "because it was indicated on datasheet" is not good reason ? +10:18 < horms> i mean it would be easier from a mainline point of view if that was not the only reason +10:21 < geertu> I think we should move on to the next topic... +10:21 < geertu> Topic 3. R-Car DMAC transfer termination synchronization support +10:21 < geertu> From Morimoto-san: +10:22 < geertu> BSP team has rcar-dmac issue. Laurent posted its patch last year, but it was +10:22 < geertu> canceled. because it needed new frame-work. +10:22 < geertu> https://patchwork.kernel.org/patch/7175381/ +10:22 < geertu> Now, upstream has it. It can be next Core group Task ? +10:22 < geertu> b36f09c3c441a6e59eab9315032e7d546571de3f +10:22 < geertu> ("dmaengine: Add transfer termination synchronization support") +10:22 < geertu> EOT +10:22 < geertu> Is there anything to discuss, or just a task to add? +10:22 < morimoto> pinchartl: can you explain ? +10:23 < pinchartl> the BSP patch was waiting for the hardware to complete all transactions when terminating them +10:24 < pinchartl> but the termination function was sometimes called from non-sleepable contexts, so I nacked the patch +10:24 < pinchartl> now the DMA engine API has support for synchronous and asynchronous termination +10:24 < pinchartl> so we can implement the feature +10:25 < morimoto> it can be 17Q1 task ? +10:26 < geertu> I think so +10:27 < morimoto> Nice. BSP team (or customer) needs it +10:27 < geertu> Topic 4. Shared GPIOs +10:27 < geertu> From Laurent: For key + LED operation +10:27 < pinchartl> Linus isn't against the idea +10:28 < pinchartl> all we need is someone to implement it +10:28 < pinchartl> neg: did you say you were looking for a core task ? :-) +10:28 < geertu> I think he already has an option on "GPIO-RCAR,?,noplan,?,Fix Runtime PM with GPIO interrupts (depends on irqchip PM) +10:29 < pinchartl> shared GPIOs might not be the most urgent one though, but it's nice for our upstream PR to drive API and framework changes +10:29 < geertu> Well said ;-) +10:30 < geertu> I'll add a task to core/todo +10:30 < geertu> Topic 5. BSP GPIO question +10:30 < horms> fwiw, i am for such activities +10:30 < geertu> shimoda: Any last minute info? +10:30 < neg> I happy to work on either of them :-) +10:32 < shimoda> unfotunately, i don't receive the detail so we can skip it :) +10:32 < shimoda> i'll forward it by email laster +10:32 < geertu> OK, thanks +10:32 < shimoda> s/laster/later/ +10:32 < geertu> Anything else to add? +10:34 < neg> Have we settled on next face to face core meeting to be at FOSDEM timing? +10:34 < geertu> Well, looks like Magnus wants to evade by arriving late? ;-) +10:35 < geertu> Probably it'll happen on Friday (half a day shared with I/O) +10:35 < horms> geertu: any thoughts on Olof's idea regarding pfc/Kconfig? +10:36 < geertu> horms: I still have to reply why it's a bad idea +10:36 < horms> ok +10:36 < horms> fwiw, i think its a can of worms +10:37 < pinchartl> geertu: Friday before the FOSDEM ? +10:37 < geertu> pinchartl: yep +10:37 < pinchartl> I'll be there +10:37 < geertu> OK +10:37 < geertu> Thanks for joining, and have a nice continued day! +10:38 < pinchartl> I mean, at least in Belgium :-) +10:38 < neg> I only asked so i can buy tickets before my financial year ends :-) I will be there +10:38 < geertu> horms: Bummer, forgot to email sfr yesterday +10:38 < horms> I also expect to be there +10:39 < horms> geertu: I for one was distracted +10:57 < morimoto> I guess chat meeting was finished ? +10:57 < horms> I guess so too +10:59 < neg> next meeting in 2 weeks, same time? +10:59 < geertu> Yes, that's the plan. Will send the report later +10:59 < morimoto> Today is started on EuroPeri side, but Today will finish on Japan side. So, please finalize meeting if it was finished. Otherwise we can't go back :P +11:00 < geertu> (repeat) Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20161123-mm-chatlog b/wiki/Chat_log/20161123-mm-chatlog new file mode 100644 index 0000000..96c9423 --- /dev/null +++ b/wiki/Chat_log/20161123-mm-chatlog @@ -0,0 +1,220 @@ +Multimedia-chat-meeting-2016-11-23 + +09:03 < pinchartl> Magnus and Morimoto-san are excused +09:03 < pinchartl> it's a public holiday in Japan +09:03 < pinchartl> so let's get started +09:04 < pinchartl> first of all +09:04 < pinchartl> neither of you have reported anything by e-mail +09:04 < horms> Workers day iirc +09:04 < pinchartl> I could somehow see that coming as the time between the e-mails and the start of the meeting got shorter every time +09:05 < pinchartl> please fix that for next +09:05 < pinchartl> time +09:06 < kbingham> pinchartl: Just went out :D +09:06 < pinchartl> now that we're done with the scolding of the scoundrels, let's get really started :-) +09:07 < pinchartl> the only topic I have for today is status check for tasks +09:07 < pinchartl> does anyone want to add something to the agenda ? +09:08 < kbingham> Nope - perhaps today will be a quick meeting :D +09:08 < pinchartl> let's see +09:08 < pinchartl> you can start :-) +09:08 * kbingham walked into that one +09:08 < pinchartl> :-D +09:10 < kbingham> OK -A) so I'm happy to say the BRU multiple input race has a fix - which makes me happy. tested over 1500 iterations, when normally it will occur in under 150. - I've also had a play with uli's HDMI patches ... just so I can actually see something out of the HDMI port at last. ... I found and fixed a small bug in raw2rgbpnm, and I've created tests for suspend resume using automated pm test framework. +09:11 < kbingham> And the best thing I've done this fortnight is my student loan is now clear \o/ +09:11 < horms> hooray! +09:11 < pinchartl> congratulations :-) +09:11 < neg> :-) +09:11 < pinchartl> and good job +09:11 < kbingham> B) Next I will try to work through the VSP suspend resume issues, and do some final work on race's to see if I can find any more. +09:12 < kbingham> C) Nothing much holding me back - except for the hardware is hung and I have to figure out why. Probably getting itself misconfigured as a race waking up or clocks not being enabled in the right order ... +09:12 * kbingham wishes for a register that tells you why the hardware is hung :D +09:13 < geertu> kbingham: JTAG? +09:13 < kbingham> geertu: Aha - Yes - I did start to look at that too - but I haven't progressed as far as hooking up the blaster to the board :D (I was lacking in jumper cable connectors) +09:13 < pinchartl> geertu: it's not the system being hung, just the VSP +09:13 < pinchartl> kbingham: right ? +09:14 < pinchartl> or is it the full system ? +09:14 < kbingham> pinchartl: geertu: Yes - it's the hardware that is hung ... not the CPU. +09:14 < pinchartl> so just the VSP ? +09:14 < kbingham> - /hardware/VSP hardware/ : ;D yes +09:14 < pinchartl> ok +09:14 < pinchartl> I don't think JTAG would be very helpful then +09:15 < neg> kbingham: if you get JTAG running on Gen3, I'm interessted to hear about it :-) +09:15 < pinchartl> to get the HDMI output working, did you have to do anything else than applying the latest patch series ? +09:15 < kbingham> pinchartl: I agree - not in this instance ... Sorry - I thought geertu was asking as I had been talking with him about JTAG :D +09:16 < kbingham> pinchartl: No - I believe HDMI worked once I managed to get the patches applied correctly. +09:16 < pinchartl> ok, thank you +09:16 < pinchartl> next in alphabetical order, more +09:17 < pinchartl> since last meeting, I've followed up on the LVDS mode selection patches and posted a new version of the patch series +09:17 < pinchartl> or the two patch series I should say, covering both LVDS panel and LVDS encoder +09:18 < pinchartl> the feedback I got from Rob on the DT bindings was much more positive +09:18 < pinchartl> but Thierry Redding now chimed in and wasn't thrilled, to say the least +09:18 < pinchartl> we have very different opinions +09:19 < pinchartl> more work is needed to fix some issues +09:19 < pinchartl> and to either convince Thierry, or exhaust him until he stops caring +09:20 < pinchartl> a v3 is under preparation +09:20 < pinchartl> the LVDS encoder support series makes the DU driver cleaner by removing manual handling of bridges +09:21 < pinchartl> so I plan to make it a base for HDMI output upstreaming on Gen3 +09:22 < pinchartl> I've also posted a few misc DU patches forward-ported from the BSP +09:22 < pinchartl> and they have been merged by Dave +09:22 < pinchartl> along with a bunch of other pending DU patches +09:23 < pinchartl> I've finished classifying the BSP patches +09:24 < pinchartl> I need to follow-up with the BSP team as it wasn't clear for some of them if they fixed real issues +09:24 < pinchartl> a few tasks have also been identified +09:24 < pinchartl> they will be candidate for additional tasks +09:25 < pinchartl> for the next two weeks +09:25 < horms> feel free to let me know if you want me to help contact the BSP team +09:25 < pinchartl> I still plan to post a proposal for the rotation and histogram API (haven't had time to address it yet) +09:25 < pinchartl> horms: thanks +09:26 < pinchartl> my plan is to ask Matsuoka-san, CC'ing the periperi mailing list +09:27 < horms> ok, that sounds like a good plan +09:27 < pinchartl> I will also start discussing V4L2 cache handling with upstream developer +09:28 < pinchartl> and upstream basic support for HDMI output on Gen3 +09:29 < pinchartl> and, as I've already mentioned, still work on LVS panel and encoder support +09:29 < pinchartl> my main issues right now are Mauro doing his bad maintainer play again +09:30 < pinchartl> and Thierry not liking the LVDS panel DT bindings (and driver) +09:30 < pinchartl> that's it for me +09:30 * kbingham gets the popcorn to watch #v4l +09:31 < pinchartl> kbingham: it was quite surreal yesterday +09:31 < pinchartl> you need to know quite a bit about the technical problems being discussed to follow +09:31 < pinchartl> but I really felt I was in a parallel universe where the known rules of software architecture didn't apply +09:32 < kbingham> :) +09:32 < pinchartl> by the way the three new tasks I've identified from the BSP are +09:32 < pinchartl> - DU suspend/resume +09:33 < pinchartl> - Gen3 DU dot clock rate optimization (with DPLL) +09:33 < pinchartl> - Display interlace support +09:33 < pinchartl> the second one is part of Ulrich's HDMI output patches +09:33 < pinchartl> I might get it done as part of the HDMI output upstreaming, but might also leave it out +09:33 < pinchartl> depending on how much time it takes +09:33 < horms> Thanks, I'll try to add that to the google sheet if you haven't done so already +09:34 < pinchartl> do we have tasks in that spreadsheet ? +09:35 < horms> not as such. +09:35 < pinchartl> ok :-) +09:35 < horms> but we have "Features" +09:36 < pinchartl> I've added them to the multimedia todo list (will push after this meeting) +09:36 < horms> And I think it makes sense to map the Features to tasks where possible +09:36 < pinchartl> I'm done +09:36 < pinchartl> neg: you're next +09:36 < neg> a) Nothing +09:36 < neg> b) Address CSI2 review comments +09:36 < neg> c) None +09:36 < neg> EOT +09:38 < pinchartl> I assume you're busy with I/O and/or core tasks at the moment ? +09:39 < neg> Not super busy, trying to start a new core task and finish up my IO task so if yout got something that needs to be done I might have time +09:39 < pinchartl> I'm looking at the todo list +09:40 < pinchartl> we have a bunch of tasks planned for v4.10 that need to be pushed back +09:40 < pinchartl> for you that's +09:40 < pinchartl> ADV7482,v4.10,plan,niklas,Gen3 support upstream +09:40 < pinchartl> ADV7482,v4.10,plan,niklas,Interlace support upstream +09:40 < pinchartl> VIN,v4.10,public,niklas,Gen3 support +09:40 < pinchartl> VIN,v4.10,plan,niklas,Scaler support (on Gen3) +09:40 < pinchartl> VIN,v4.10,public,niklas,CSI2 interlace support upstream (Gen3) +09:40 < pinchartl> VIN,v4.10,public,niklas,CSI2 support upstream (Gen3) +09:40 < pinchartl> VIN,v4.10,plan,niklas,Gen3 support upstream (without CSI-2) +09:40 < pinchartl> should I push them back to v4.11 or directly to v4.12 ? +09:41 < neg> I don't think we can move forward with CSI2 without VIN and so far there have not been much review on the series which is huge so I assume it will miss v4.11, or how do you feel about it? +09:42 < pinchartl> I agree with you +09:42 < pinchartl> unless we decide it's a high priority and put lots of effort on that +09:42 < pinchartl> but that doesn't seem to be the case at the moment +09:42 < pinchartl> so v4.12 seems more realistic to me +09:43 < neg> for ADV7482 I have mixed feelings about having it in periperillist, is that something we still feel is a task to bring to upstrem since there are a huge effort to do so? +09:43 < pinchartl> I don't think so at the moment. I'll mark it as noplan +09:43 < pinchartl> but keep it there as it would be nice to have +09:45 < neg> yes I would love to get it upstream one day, I will keep to work on the driver so I can test VIN but the big push to make it ready for upstream I feel is a low prio thing +09:45 < pinchartl> thanks +09:45 < pinchartl> next, uli___ +09:45 < uli___> as mentioned above, i have pushed out a base for upstreaming hdmi out on gen3 +09:46 < uli___> and a tool for testing analog audio remotely with a loopback cable +09:46 < uli___> https://github.com/uli/atest +09:46 < uli___> for interested parties +09:46 < uli___> mixer settings are tricky, but the readme contains a few hints +09:46 < kbingham> uli___: I like atest - that's neat :D +09:46 < uli___> thank you :) +09:47 < uli___> next, i will upport/test/fix ipmmu patches for du, vsp and fcp +09:47 < uli___> haven't looked into that yet +09:47 < uli___> no issues +09:47 < uli___> that's it from me +09:48 < pinchartl> what's the status of VIN,v4.10,public,ulrich,Gen2 VIN integration ? have the patches been merged ? +09:48 < uli___> i'm not sure, actually +09:48 < pinchartl> horms might know ? +09:49 < uli___> or neg +09:49 < pinchartl> those are DT patches +09:49 < horms> I don't believe so +09:49 < horms> I can look up but most likely I was expecting some Acks and then it fell off my radar +09:50 < pinchartl> I see the following patches in your tree +09:50 < pinchartl> 06b64afa6e98 ARM: dts: r8a7793: Enable VIN0-VIN2 +09:50 < pinchartl> 84e3a74664c5 ARM: dts: koelsch: add HDMI input +09:50 < pinchartl> 56548d0c5aea ARM: dts: lager: Add entries for VIN HDMI input support +09:50 < pinchartl> uli___: were there more ? +09:50 < uli___> for gose, i think there was an issue +09:50 < uli___> it's missing the enablement for analog and hdmi in the dts file +09:51 < uli___> i'll look into that +09:51 < pinchartl> thanks +09:51 < horms> yes, i think those things are missing from gose +09:51 < horms> i'm entirely usnure why +09:51 < pinchartl> I'll update the target to v4.11 then +09:52 < horms> please feel free to ping me any time if dt patches seem stuck +09:53 < pinchartl> "[PATCH v2 2/3] ARM: dts: gose: add HDMI input" is ready to be merged with a small fix that I requested +09:53 < pinchartl> "[PATCH v2 3/3] ARM: dts: gose: add composite video input" will require a bit more work +09:54 < uli___> yes, i think i'll resend the hdmi part individually, so it won't me tainted by disparaging comments :) +09:54 < uli___> s/me/be/ +09:55 < pinchartl> you can also start to update the ADV7180 DT bindings already +09:55 < pinchartl> the only open item is what compatible strings to use +09:55 < pinchartl> the rest can already be fixed +09:56 < uli___> i'll have a look +09:57 < pinchartl> thanks +09:58 < pinchartl> next meeting +09:58 < pinchartl> I propose 2016-12-07 at the same time as today +09:58 < pinchartl> 08:00 GMT / 09:00 CET / 10:00 EET / 17:00 JST +09:58 < neg> uli___: thanks for all your work for VIN, I'm looking forward to v4.10 and out of the box HDMI VIN for gen2 :-) +09:59 < neg> Meeting time works for me +09:59 < uli___> you are welcome :) +09:59 < kbingham> uli___: Then you can write a vtest to do a video loopback with embedded data verification too :D +10:00 < horms> FWIIW that is not a holiday in Japan +10:00 < uli___> kbingham: don't give anybody ideas +10:00 < pinchartl> horms: I'm sure they'll find another excuse ;-) +10:00 < pinchartl> (it's the day after the Finnish independence day) +10:00 < horms> no comment +10:00 < neg> vtest +1 :D +10:00 < pinchartl> does anyone have anything to add ? +10:00 < kbingham> uli___: Should be possible to do straight byte comparisons - but encoding the bytes sounds more fun :D +10:00 < horms> Indepemdence from Sweeden_ +10:00 < horms> _ +10:00 < horms> ? +10:01 < pinchartl> from Russia I believe +10:01 < horms> Ok. I think they may bave become independent a few times. But I could easily be wrong. +10:02 < pinchartl> :-) +10:02 < pinchartl> if there's no more comment I propose adjourning this meeting. does anyone second ? +10:02 < neg> Any multimedia meeting plan for FOSDEM timing I should keep in mind when bookig my trip? +10:02 < pinchartl> neg: good point +10:02 < kbingham> Ah yes- I'll be at FOSDEM too - would probably like to book flights early +10:02 < pinchartl> it looks like there will be a core and I/O day on Friday before the FOSDEM +10:03 < pinchartl> it's not clear yet whether we'll need a multimedia meeting, but it will likely be useful to discuss additional tasks at least +10:03 < pinchartl> so I propose reserving time for that on Thursday +10:04 < pinchartl> I'll be in Belgium anyway :-) +10:04 < pinchartl> so it's easy for me +10:05 < pinchartl> but if any of you don't want to spend an extra day in Brussels needlessly, we need to decide whether to organize a meeting or not +10:05 < pinchartl> I assume everybody would arrive on Thursday at the latest anyway, to be there for the core and I/O meetings on Friday +10:06 < pinchartl> so if you book a flight that doesn't arrive too late and we host the meeting in the afternoon then we should be good +10:06 < pinchartl> any thoughts on that plan ? +10:06 < neg> For me Thursday is fine, maybe have a afternoon meeting so ppl can arive that day and still not be late for meeting? +10:06 < pinchartl> yes, that's the idea +10:07 < kbingham> Looks like my light will get in at 12:50 local time ... +10:07 < kbingham> how long does it take to get fro m the airport to the centre. +10:07 < pinchartl> the train takes a bit less than 20 minutes +10:08 < pinchartl> but you also need to get out of the plane and to the train station :-) +10:08 < pinchartl> you might be a bit late for lunch, but for an afternoon meeting it's definitely fine +10:08 < pinchartl> uli___: how about you, what are you travel plans ? +10:08 < uli___> i can't confirm that i will be at fosdem at all yet... +10:08 < uli___> so don't consider me when planning any meetings +10:09 < uli___> judging from the train schedule +10:09 < uli___> i'd be there at 5 something +10:10 < pinchartl> 5pm I assume +10:10 < uli___> yes +10:11 < pinchartl> ok, so we should decide as soon as possible whether to organize a meeting on Thursday then +10:12 < pinchartl> I'll ask Magnus and Morimoto-san about their opinion in the meeting report and we'll then decide +10:12 < kbingham> at the very least we could do dinner on thursday evening +10:12 < horms> that sounds like a fine idea to me :) +10:12 < pinchartl> yes dinner is certainly a must :-) +10:13 < pinchartl> if there's no more comment I propose adjourning this meeting. does anyone second ? +10:14 < neg> second +10:14 < pinchartl> thank you +10:14 < pinchartl> the meeting is adjourned, thank you everybody for attending diff --git a/wiki/Chat_log/20161206-core-chatlog b/wiki/Chat_log/20161206-core-chatlog new file mode 100644 index 0000000..bcc48dc --- /dev/null +++ b/wiki/Chat_log/20161206-core-chatlog @@ -0,0 +1,151 @@ +Core-chat-meeting-2016-12-06 + +09:07 < geertu> Welcome to today's Core Group Meeting +09:07 < geertu> First, let me introduce a special guest: Jacopo! +09:07 < geertu> (or let him introduce himself ;) +09:07 < jmondi> ahah, hi Geert, thanks :) +09:08 < morimoto> Hi Jacopo ! +09:08 < jmondi> hello everyone, I met most of you in Berlin, for anyone else my name's Jacopo, I'm based in Italy, and I'm working on 2 trail tasks with Magnus for this months +09:08 < jmondi> s/trail/trial +09:09 < jmondi> hope to meet you all in person soon ;) +09:09 < geertu> Thanks, Jacopo +09:09 < geertu> Agenda: +09:09 < geertu> 1. Status updates +09:09 < geertu> 2. Proposal from BSP team about PFC I2C ch0, 3 and 5. +09:09 < geertu> 3. FOSDEM+core confirmation: who? +09:09 < geertu> Topic 1. Status updates +09:10 < geertu> A) What have I done since last time +09:10 < geertu> B) What I plan to do till next time +09:10 < geertu> C) Problems I have currently +09:10 < geertu> First (according to sort -r) is Simon +09:10 -!- horms [~horms@217.111.208.18] has quit [Ping timeout: 265 seconds] +09:11 < geertu> Nice try... +09:11 < neg> You scared him away :-) +09:11 < morimoto> :) +09:11 < geertu> Next is Shimoda-san +09:12 < shimoda> A) B) C) is nothing to me +09:12 < shimoda> --- END --- +09:12 -!- horms [~horms@217.111.208.18] has joined #periperi +09:12 < geertu> Thanks, Shimoda-san +09:13 < geertu> (2nd try) Next is Simon +09:13 < horms> sorry about that +09:13 < horms> network troubles as usual +09:13 < horms> Status: +09:13 < horms> A) What have I done since last time +09:13 < horms> * Analysed device tree binding status +09:13 < horms> - Presence and use of SoC-specific and fallback compatibility strings +09:13 < horms> - Posted some fixups +09:13 < horms> B) What I plan to do till next time +09:13 < horms> * Continue above +09:13 < horms> * See above +09:13 < horms> C) Problems I have currently +09:13 < horms> * Order of struct of_device_id entries. +09:13 < horms> - Fallback last seems nice but unnecessary given my reading of +09:13 < horms> __of_match_node() +09:13 < horms> - If it is required then a behaviour change is implied for +09:13 < horms> in-tree users of i2c-sh-mobile, intc-rcar +09:13 < horms> -- end -- +09:14 < geertu> You are right, __of_match_node() assigns a higher score to the first compatible value in the node. +09:14 < geertu> So it shouldn't be needed. +09:14 < geertu> Still, I think it's nice to list "fallback" values last. +09:15 < horms> ok, understood +09:15 < horms> i need to repost the pci series anyway +09:15 < horms> i'll reword the changelog +09:15 < horms> and also look to fixing up other caes +09:15 < geertu> Thanks Simon. +09:15 < geertu> Next is Niklas +09:16 < neg> A) Nothing +09:16 < neg> B) Start to work on 'GPIO-RCAR,?,noplan,?,Fix Runtime PM with GPIO interrupts (depends on irqchip PM) +09:16 < neg> C) None +09:16 < neg> EOT +09:17 < geertu> Thanks, Niklas +09:17 < geertu> Next is Morimoto-san +09:17 < morimoto> struct core_task *a = *b = *c = NULL; +09:17 < morimoto> return 0; +09:17 < geertu> Thanks. Morimoto-san +09:18 < geertu> Laurent seems to be away +09:18 < geertu> Next is myself +09:18 < geertu> A) Worked with Simon and Arnd to get our pull requests for arm-soc accepted. +09:18 < geertu> Sent pull requests for soc_device_match() and RZ/G clock definitions +09:18 < geertu> B) Coerce Simon into taking all MODEMR related patches +09:18 < geertu> 2017Q1 additional tasks +09:19 < geertu> C) What's wrong with the IPMMU? (more like a retorical quesiton) +09:19 < geertu> EOT +09:19 < horms> a) thanks! +09:19 < horms> b) happy to negotiate :) +09:19 < geertu> From the emails, looks like the HW team is investigating the IPMMU? +09:20 < geertu> Last (present) is Jacopo +09:21 < jmondi> A) PFC patches for Gyro-ADC: v3 in review +09:21 < jmondi> Enabled and tested MAX11100 ADC on genmai board. RFC patches sent out +09:22 < jmondi> B) Not sure is a core task, but I should write an IIO driver for that same ADC this week +09:22 < jmondi> C) none +09:22 < jmondi> that's all from me +09:22 < jmondi> -- end -- +09:22 < shimoda> geertu: yes, the HW team is investigating the IPMMU now. +09:23 < geertu> IIO drivers are indeed not core, but I/O. I don't know if Wolfram plans an I/O chat later this week. +09:23 < horms> jmondi: please consider patches to enable options in defconfigs if appropriate +09:23 < geertu> Thank Jacopo +09:23 < geertu> horms: The MAX11100 ADC is an add-on, not an on-board device +09:24 < jmondi> horms: for ADC you mean? +09:24 < jmondi> yes, it's temporary connected to one of Genmai's expansion header +09:24 < horms> It was just a general request. I'd need to look at the patches more closely to make a specific request regarding them. +09:25 < jmondi> need to sync with Magnus because we'll use another board, but it will remain connected to some expansion connector I guess +09:25 < horms> Ok +09:25 < horms> understood +09:25 < horms> my comment is probably not relevant in that case +09:25 < jmondi> horms: it may be for future! thanks anyway :) +09:26 < geertu> Topic 2. Proposal from BSP team about PFC I2C ch0, 3 and 5. +09:26 < geertu> Submitted by Shimoda-san +09:27 < shimoda> yes, should i explain? +09:27 < geertu> Yes please. +09:27 < neg> shimoda: yes please +09:28 < shimoda> I sent an email. BSP team would like to set the such pins via PFC driver +09:29 < shimoda> the pins spec differs than other pins. so bsp team think that the PFC driver should have other way +09:29 < geertu> IIUIC, multiple functions can be muxed to the i2c pins, but they cannot be used for GPIO? +09:30 < shimoda> geertu: let me check... +09:30 < geertu> It uses PIN_NUMBER('B', 11) +09:32 < geertu> But it also touches avb, hscif, msiof, pwm, sdhi +09:33 < geertu> Does it mean those functions are mutually exclusive with the i2c function, although they use different pins? +09:33 < geertu> And is this ES1.0 or ES2.0? +09:35 < shimoda> geertu: i don't know this is ro es1.0 or es2.0 +09:37 < shimoda> about this mod_sel, as you said, they are muxed pins. +09:39 < shimoda> and these i2c pins cannot bd used for GPIO +09:40 < shimoda> this patch reuses POC/DRVCTRL register setting thing +09:41 < shimoda> BSP team would like to know this policy is good or not +09:41 < geertu> Ah, it's for e.g. "Phisically muxed with AVB_AVTP_MATCH_A" inside some floating comment box in (preliminary)CSD15-676_R-CarH3_pinfunction(Rev0p290)_customer.xlsx, which you cannot search for using LibreOffice +09:44 < geertu> According to that xlsx, it uses the same pin numbers as the "Phisically muxed" pins, but in a different row of the sheet. +09:45 < neg> It's pinmux for none-GPIO pins right? +09:45 < geertu> Can't we just use the corresponding RCAR_GP_PIN()? +09:46 < geertu> E.g. SCL0 is SoC pin AA33, SiP pin C29 +09:47 < geertu> But SD1_CD is also AA33 / C29, and GP3_14 +09:48 < geertu> so we could use RCAR_GP_PIN(3, 14) instead of PIN_NUMBER('C', 29)? +09:48 < geertu> What am I missing? +09:49 < geertu> I think this needs more clarificiation / investigation, offline. +09:50 < geertu> shimoda-san: Do you agree? +09:51 < shimoda> geertu: about red line in the xlsx file, it seems your comment is match, i will ask hw team or/and bsp team +09:51 < shimoda> and offline, it's nice to me :) +09:51 < shimoda> s/red line/red rectangles/ +09:52 < neg> yes, I think if there are a RCAR_GP_PIN() for that pin it should be used, or I'm also missing something +09:52 < geertu> It depends on what "Phisically muxed" really means +09:54 < geertu> (in gnumeric, it shows a black rectangle. I also cannot search for its contents, but I can move (not edit) it ;-) +09:54 < geertu> Let's continue +09:54 < geertu> Topic 3. FOSDEM+core confirmation: who? +09:55 < geertu> So it seems like Morimoto-san will miss the rabbits, and will go to trump(et)land instead ;-) +09:55 < geertu> Who's still planning to attend FOSDEM, and a core meeting on Friday before? +09:55 < geertu> +1 Geert +09:56 < neg> I will go to FOSDEM but have yet to book my tickets +09:57 < neg> (and attend the core meeting on Friday ofc) +09:57 < horms> If there is a Core meeting then I expect to be there +09:57 < horms> I may also come up with other reasons to be there, but that is the main one at this time +09:57 < jmondi> I'll be at fosdem. Hopefully I'll still have a reason to join these meetings :) +09:59 < morimoto> Please enjoy rabbits in FOSDEM :) +10:00 < geertu> I prepared rabbit two weeks ago +10:01 < geertu> I think we're finished, unless someone has still something to add? +10:01 < neg> are there any periperi plans for ELC timing since Morimoto-san will not join at FOSDEM? I have not made any plans for ELC but if I'm to go I think it's best to book soon :-) +10:02 < geertu> deadline for proposals is this Saturday. +10:02 < geertu> I don't plan to go to ELC this time. +10:03 < neg> ok sorry for proloning the meeting just wanted to check so I don't have to buy expensive tickets later on +10:03 < horms> I am considering going but so far have no plans +10:04 < geertu> neg: the tickets may become cheaper after the inauguration of the next president ;-) +10:06 < neg> geertu: haha yes and his inauguration is at end of Jan so maybe the riots in portland have settled down by ELC +10:08 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20161207-mm-chatlog b/wiki/Chat_log/20161207-mm-chatlog new file mode 100644 index 0000000..a584795 --- /dev/null +++ b/wiki/Chat_log/20161207-mm-chatlog @@ -0,0 +1,395 @@ +Multimedia-chat-meeting-2016-12-07 + +<morimoto> Hi [16:59] +<pinchartl> hello +<neg> hi all +<morimoto> Hyvaa huomenta [17:00] +* morimoto I can't pronunciation +*** uli___ (~uli___@static.206.203.46.78.clients.your-server.de) has joined + channel #periperi [17:01] +<pinchartl> morimoto: even writing it is difficult on your keyboard :-) +<pinchartl> do you have a key for ä ? +<morimoto> Unfortunately, No. +<morimoto> :P +<pinchartl> kbingham said he might not be able to attend the meeting today + [17:03] +<kbingham> pinchartl: Terribly sorry to say I managed to make it (just) +<pinchartl> :-) +<pinchartl> welcome ! +<pinchartl> and Magnus seems to be missing +<kbingham> Morning all :D +<morimoto> Morning kbingham [17:04] +<uli___> morning +<pinchartl> so let's get started +<pinchartl> topics for today +<pinchartl> - Status check for the multimedia tasks [17:05] +<pinchartl> - Next meeting +<pinchartl> anything else ? +<morimoto> FOSDEM ? +<morimoto> (I don't go though) +<pinchartl> the rabbits will miss you [17:06] +<morimoto> Hehe :) me to +<morimoto> too +<pinchartl> so [17:07] +<pinchartl> Topic 1. Status check for the multimedia tasks +<pinchartl> kbingham: do you mind starting ? +<kbingham> pinchartl: I'd actaully like to go last so I can upload something + :D [17:08] +<kbingham> (which will show why I was skiiving of work yesterday to work on a + personal project :D) +<pinchartl> ok, let's reverse the order then +<pinchartl> uli___: your turn +<uli___> ok +<uli___> so i collected a bunch of patches and checked if the vsp-tests run + with ipmmu enabled [17:09] +<uli___> on gen3 +<uli___> with a little fix, they do +<uli___> although i had a few issues on m3-w +<pinchartl> what kind of issues ? +<uli___> where the system gets sluggish when running vsp-tests, with or + without ipmmu enabled +<uli___> sometimes it freezes +<uli___> but the tests pass [17:10] +<uli___> haven't found out what that could be +<pinchartl> I haven't noticed that +<pinchartl> but I mostly use H3 +<uli___> no issues on h3 [17:11] +<pinchartl> ok, we'll need to investigate that +<pinchartl> I'm a bit surprised that IPMMU works given that it's supposed to + be broken at the hardware level [17:12] +<uli___> :) +<pinchartl> issues and blockers ? [17:13] +<uli___> pressed for time. other than that, none +<pinchartl> I see you'll be on vacation from next Monday to the 3rd of January + ? [17:14] +<uli___> yes +<morimoto> Wow! winter vacation ? +<pinchartl> have fun, both finishing all your tasks before that, and during + your vacation :-) +<uli___> :) [17:15] +<pinchartl> next, neg +<neg> A) Nothing +<neg> B) Address CSI2 review comments [17:16] +<neg> C) None +<pinchartl> easy :-) +<pinchartl> thanks +<neg> Will also have a shorter vacation trip then uli___ from 27 Dec -- 6 Jan + :-) +<pinchartl> I'll wish you a good vacation during the next meeting then :-) + [17:17] +<pinchartl> next, Morimoto-san +<morimoto> OK +<morimoto> A) [17:18] +<morimoto> I got review from Rob about OF-graph HDMI sound. He don't like + current style. Now I'm discussing about it. +<morimoto> +<morimoto> B) +<morimoto> DU side DT will have HDMI video and sound. ALSA SoC side needs to + know total how many HDMI sound port exist. +<morimoto> but, Rob rejected "type=" property. So, I can't know. +<morimoto> ---- from Rob ---------------- +<morimoto> I still don't think this is necessary. Simply define which port + number +<morimoto> is which for each HDMI chip. +<morimoto> If this is necessary, then the types, video and sound, are too + generic. +<morimoto> ------------------------------ +<morimoto> What does it mean ?? How to get this information from ALSA side ?? +<morimoto> I think I need to corroborate with HDMI video ? +<morimoto> s/corroborate/collaborate [17:19] +<morimoto> C) [17:20] +<morimoto> I need to re-create OF-graph patches. +<morimoto> Can I use Laurent version ? I'm using Ulrich version +<morimoto> -- EOT -- +<pinchartl> regarding the type property +<pinchartl> the DT bindings for each HDMI encoder define the number and type + of each port +<pinchartl> Rob's point is that, instead of adding a generic type property, + you should query the HDMI encoder driver at runtime to know the + number of audio ports [17:21] +<pinchartl> I'm not sure if that's feasible though, I haven't checked how it + works on ALSA"s side +<morimoto> but in runtime query, how the driver know total size ? [17:22] +<morimoto> fixed size, does it mean ? +<pinchartl> the driver knows because the driver knows the hardware +<pinchartl> it's hardcoded in the driver [17:23] +<morimoto> OK, I see. +<pinchartl> for instance let's say we have an HDMI encoder with two sound + inputs, one video input and one HDMI output +<pinchartl> that's 4 ports +<pinchartl> the DT bindings would document something like +<pinchartl> port 0: video in +<pinchartl> port 1: audio 0 in +<pinchartl> port 2: audio 1 in +<pinchartl> port 3: hdmi output [17:24] +<pinchartl> then let's imagine that the board has audio 1 in connected +<pinchartl> and audio 0 not connected +<pinchartl> DT would have port 2 connected with an endpoint +<pinchartl> and port 1 not connected, with no endpoint +<pinchartl> the driver would parse the DT node +<pinchartl> see that port 1 is not connected and port 2 is connected [17:25] +<pinchartl> and conclude that there's one audio input in use among the two + possible audio inputs +<pinchartl> there's no need for a type property there +<pinchartl> the type property would only be needed if you need geenric code to + parse the DT node, code that has no knowledge of the device + [17:26] +<morimoto> So this mean we need new "query" function for it ? +<morimoto> it tell "for video port" "for sound port" or "connected", something + like that [17:27] +<pinchartl> that would be the idea. again, as I'm not too familiar with ALSA's + internals I don't know if that would be easy, or even good +<pinchartl> but Rob's point is that code that parses the OF graph in a + completely generic way is usually a bad idea [17:28] +<morimoto> OK +<pinchartl> because DT properties are defined by DT bindings in relationship + with the compatible strings +<pinchartl> so a generic function that walks through the OF graph, from node + to node, trying to collect information about each node, can't know + for sure what a property means [17:29] +<morimoto> +1 question is that this mean, DU driver will have this "query" + function, righ ? +<pinchartl> I'm not as opposed to that as he is, but I understand his point +<pinchartl> do you mean the dw-hdmi driver ? +<morimoto> I don't know. DU has port, right ? [17:30] +<morimoto> not dw-hdmi +*** horms (~horms@217.111.208.18) has joined channel #periperi +<pinchartl> the DU has a DT node, yes +<pinchartl> but DU doesn't handle sound +<pinchartl> the HDMI encoder DT node does [17:31] +<morimoto> Yes, yes. DU driver only handle video side, but will have + video/sound port in DT. +<morimoto> This means, DU driver need to care about video/sound port, too +<pinchartl> + https://git.linuxtv.org/pinchartl/media.git/commit/?h=drm/du/hdmi&id=3d12f1ed444c7d38e4006d51155dfebca0bb3d22 + [17:32] +<pinchartl> those are the DT nodes that will have audio ports +<pinchartl> they're handled by the new rcar-dw-hdmi driver +<pinchartl> + https://git.linuxtv.org/pinchartl/media.git/commit/?h=drm/du/hdmi&id=59115b56b8156a60b5e1d3e0077611ed403b6154 +<pinchartl> which is the platform glue layer for the dw-hdmi core code [17:33] +<morimoto> Oops, I need to rebase to it [17:34] +<morimoto> Does renesas-driver has it ? +<pinchartl> it should, yes +<morimoto> OK. +<pinchartl> Geert told me yesterday he would merge it +<morimoto> And it is almost upstream version ? +<pinchartl> yes +<morimoto> OK [17:35] +<pinchartl> I've posted v1 already +<pinchartl> and will post v2 soon +<pinchartl> (more about that when it will be my turn) +<morimoto> OK, I will rebase to it, and consider about query function. +<morimoto> But, +<morimoto> HDMI will have "sound" port anyway. So video side need to care it, + right ? [17:36] +<morimoto> (avoid sound port, etc..) +<pinchartl> yes it will +<morimoto> Or HDMI video/sound can share same port ? [17:37] +<pinchartl> it should be two different ports +<morimoto> OK, nice to know +<morimoto> I will investigate it next week. thanks +<pinchartl> so we would need an API to walk the DT graph with assistance from + drivers +<pinchartl> you're welcome +<morimoto> I will ask about query to Rob [17:38] +<pinchartl> I think I've answered your question about which version of the + HDMI patches you should use +<pinchartl> so now it's my turn :-) +<pinchartl> since last meeting [17:39] +<pinchartl> as I said, I've posted the HDMI output on Gen3 patches +<pinchartl> Kieran and I have been working together on that +<pinchartl> we got rid of all hacks [17:40] +<pinchartl> one of the good news is that ES1.x / ES2.0 don't need special + handling anymore +<morimoto> Nice +<pinchartl> the series cleans up and enhances the dw-hdmi driver +<pinchartl> I've received a few comments about that +<pinchartl> and reworked the patches accordingly [17:41] +<pinchartl> based on information I managed to gather about the Synopsys DWC + HDMI TX IP core +<pinchartl> it's not easy, as there's no public datasheet from Synopsys +<pinchartl> speaking of which, I talked to one of their engineers in private +<pinchartl> he said he wasn't allowed to give me information +<pinchartl> but that, if I needed support, I should be able to get it through + Renesas [17:42] +<pinchartl> he said that if Renesas contacted Synopsys' support, the question + would be routed to him, and he could then talk to me in direct :-) +<pinchartl> so far I managed to solve most of the problems withotu needing + that +<pinchartl> I've also done review, there was quite a bit of discussion about + the DRIF DT bindings [17:44] +<pinchartl> no time to post a proposal for the rotation and histogram APIs yet + I'm afraid [17:45] +<pinchartl> I'll try to address that in the next two weeks +<pinchartl> aV4L2 cache +<pinchartl> oops +<pinchartl> as well as starting the V4L2 cache discussion +<pinchartl> no real issue or blocker, I've been slowed down by the lack of + public dwc hdmi documentation, but I found a leaked datasheet and + gathered more information from several developers [17:46] +<pinchartl> so at the moment it's not an issue +<pinchartl> that's it for me [17:47] +<pinchartl> kbingham: your turn now +<kbingham> Ok :D +<kbingham> So - as per the mail I sent - I've fixed suspend resume on m2m + pipelines, and incorporated the fix for the BRU race I discovered + into this as well. [17:48] +<kbingham> I've also written a couple of automated tests for suspend resume + which should make their way into vsp-tests. - It's quite neat, as + it uses a PM debug tool in the kernel to suspend, and then + automatically resume after 5 seconds. [17:49] +<pinchartl> (bit of context for the reader, M2M pipeline refers to the VSP) + [17:50] +<kbingham> Ah yes - sorry - I was lacking context there :D - There are still + issues in the display pipeline but that is more complicated as we + are then dealing with making sure multiple cells suspend resume + cleanly I believe. [17:51] +<pinchartl> yes, DU suspend/resume still needs work +<kbingham> Aside from that - I've done some work on HDMI with Laurent, and + I've been supporting Duc@Jinso to help him get a set up for testing + the writeback prototype I posted last month. +<kbingham> My B) section is a little 'fuzzy' at the moment, so I'll leave that + section blank for now :D [17:52] +<kbingham> C) - There was a lot of time spent looking after Jinso :( [17:53] +<kbingham> D) Show(off) and tell - +<kbingham> - I've made an LED Christmas Tree Hat (for Xmas parties) +<kbingham> - https://goo.gl/photos/PRyXXbpJdJbokBQ56 +<pinchartl> :-D +<neg> nice +<kbingham> Speak of the devil - Duc@Jinso has just mailed me again :D [17:54] +<pinchartl> Morimoto-san: I've sent you an e-mail regarding the support we + have to provide to Jinso +<morimoto> Nice hat ! [17:55] +<pinchartl> Magnus told me he would discuss it with you, tomorrow if I + remember correctly +<morimoto> OK, I will talk to him. +<morimoto> Renesas side needs discuss about that ;P +<pinchartl> kbingham: what's your vacation schedule for the end of the year ? + [17:57] +<kbingham> ... +<kbingham> That's just what I was writing next :D +<kbingham> Or rather was going to ask about :D +<kbingham> Keri is on holiday from school from the 19th to the 3rd. [17:58] +<kbingham> I don't necessarily need all that time as holiday - but I don't + think I have much work planned at the moment ... +<pinchartl> ok [17:59] +<pinchartl> speaking of which +<kbingham> Certainly - I won't be working 23rd to 3rd probably [18:00] +<pinchartl> Morimoto-san, you mentioned a VSP/DU performance problem reported + by a customer +<pinchartl> has there been any feedback on that ? +<pinchartl> it sounded quite urgent, is it something that we need to start + working on before January ? +<morimoto> There is no response from BSP team, at this point [18:01] +<morimoto> let me check +<pinchartl> ok, we'll wait and see then +<kbingham> Ok - well I have plenty of work to continue getting my garage + office conversion :D [18:02] +<pinchartl> :-) +<pinchartl> and speaking of winter holidays, will Renesas be operating between + christmas and new year ? +<kbingham> so that will keep me busy in the meanwhile. +<kbingham> pinchartl: Are you going to take a break anytime ? [18:03] +<pinchartl> I'll be in Belgium from the 21st to the 29th [18:04] +<pinchartl> I'll still be available 21st-23rd (minus time stuck in transport + on the 21st) +<pinchartl> and will take 24th-29th off [18:05] +<morimoto> Renesas side will have winter vacation from 29th Dec - 9th Jan +<morimoto> BSP team want to know VSP/DU plan, at this point. [18:06] +<pinchartl> the plan to fix the issue they've reported ? +<morimoto> They will explain current situation to customer, but customer want + to know its plan +<morimoto> Yes +<pinchartl> we can either start working on it in 2017/Q1 [18:07] +<pinchartl> or, if it's urgent, Kieran could start investigating it in + December already +<horms> morimoto: are those dates inclusive or exclusive? +<pinchartl> but we'll need an additional task for him +<morimoto> horms: sorry, what do you mean ? [18:08] +<horms> do you start holiday on Friday or Saturday? +<horms> Do you finish holiday on Sunday or Monday? +<pinchartl> horms: the 29th is actually a Thursday +<horms> ok, sorry [18:09] +<horms> its not so important in any case +<pinchartl> no worries, calendars are confusing :-) +<morimoto> BSP team is thinkingl [18:10] +<morimoto> oops +<morimoto> BSP team is thinking that they can get some kind of result from + upstream January - March [18:11] +<morimoto> Is it possible, do you think ? +<pinchartl> that works for me +<morimoto> OK, so Kieran can spend relax Christmas :) [18:12] +<pinchartl> :-) +<kbingham> morimoto: I'm not sure the words 'relax' and 'christmas' go + together anymore :S +<kbingham> but yes :D +<morimoto> sorry for my English [18:13] +<neg> kbingham: that's why I go to the caribbeans and drink rum, I will be + relaxed :-) +<kbingham> morimoto: No your english was fine :D +<kbingham> neg: Got any room in your luggage to pack me ? +<morimoto> horms: Renesas last working day is 28th, and holiday started from + 29th +<horms> thanks [18:14] +<morimoto> horms: last holiday is 9th, start works from 10th. Is this clear ? +<pinchartl> morimoto: very clear, thanks +<pinchartl> next topic, FOSDEM +<horms> very clear, thanks +<pinchartl> Morimoto-san will unfortunately not be able to join us [18:15] +<morimoto> horms: np +<pinchartl> has there been a confirmation that a core meeting will be held on + Friday the 3rd of February ? +<horms> I think that is more or less confirmed +<pinchartl> ok +<horms> geertu: ? +<geertu> horms: yes? [18:16] +<horms> geertu: is f2f core meeting on 3rd Feb confirmed? +<geertu> horms: If Laurent and Magnus join, we are 6 persons. [18:17] +<geertu> which is critical mass, I believe? So yes +<pinchartl> I'll be there +<morimoto> Magnus said he arrive at Feb 3th [18:18] +<morimoto> Feb 3rd afternoon +<pinchartl> ok +<morimoto> afternoon = 16:05 [18:19] +<geertu> Hmmm... +<geertu> He also said he might change his plane +<kbingham> geertu: I'll likely be there by then regardless - so I might join + you for somewhere to keep warm :D +<kbingham> If I'm not wanted - I'll explore brussels :) [18:20] +<geertu> Will there be an MM meeting on Thursday? +<pinchartl> at this point there's no formal plan for a multimedia meeting, but + I've booked the afternoon of February the 2nd nonetheless +<kbingham> Brussels? +<geertu> Or will it just ve I/O and Core on Friday? +<pinchartl> if you're in Brussels, I'm sure we won't run out of multimedia + topics to discuss +<pinchartl> next topic, next meeting [18:22] +<pinchartl> I propose two weeks from now +<pinchartl> on the 21st +<pinchartl> Ulrich is already excused as he will be on holidays +<neg> 21st works for me +<pinchartl> uli___: but please report your progress by e-mail before leaving + [18:23] +<morimoto> 21st doesn't works for me :( +<uli___> ok +<pinchartl> morimoto: we can move it to Tuesday or Thursday +<morimoto> 20th, 22th are OK +<geertu> Core meeting on Dec 20th? [18:24] +<geertu> (still have to complete the report and mail it out) +<pinchartl> there's the core meeting on Tuesday already. we can have the + multimedia meeting after core, but it will be late for you +<pinchartl> so maybe 22nd then ? +<morimoto> 22nd is OK for me [18:25] +<pinchartl> 22nd then. same time, 08:00 GMT / 09:00 CET / 10:00 EET / 17:00 + JST +<morimoto> Thanks. I booked [18:26] +<pinchartl> and that's all we have on the agenda for today. I propose + adjourning the meeting, does anyone second ? +<kbingham> I'll skip to thirded :D +<uli___> fourthed +<pinchartl> thank you all for attending [18:27] +<pinchartl> and have a nice day or evening +<kbingham> Cheers all ! +<neg> thanks all +<morimoto> Thanks! diff --git a/wiki/Chat_log/20161214-io-chatlog b/wiki/Chat_log/20161214-io-chatlog new file mode 100644 index 0000000..7dec763 --- /dev/null +++ b/wiki/Chat_log/20161214-io-chatlog @@ -0,0 +1,135 @@ +--- Log opened Wed Dec 14 08:57:55 2016 +08:57 -!- wsa_ [~wsa@p54B33B2F.dip0.t-ipconnect.de] has joined #periperi-io +08:57 -!- ServerMode/#periperi-io [+ns] by leguin.freenode.net +08:57 -!- Irssi: #periperi-io: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal] +08:57 -!- Irssi: Join to #periperi-io was synced in 0 secs +08:58 -!- geertu [~geert@d54C189FD.access.telenet.be] has joined #periperi-io +08:58 < geertu> Mornin' +08:58 -!- neg [~neg@unaffiliated/neg] has joined #periperi-io +08:59 <@wsa_> good morning +09:00 < neg> morning +09:02 <@wsa_> i think we convinced Eduardo to soc_device_match +09:02 < neg> yes :-) +09:03 < geertu> Good +09:03 < neg> I had a chat with Geert yesterday and I think I will switch to binary scaling instead of decimal scaling in next version to increase accuracy, I think it's better Renesas test that version then the deciaml one. Do you agree? +09:03 <@wsa_> yes, i do +09:03 <@wsa_> i wondered why it didn't work for you before +09:04 <@wsa_> On C64, we always do binary scaling ;) +09:04 < neg> it worked but the diff with the orignal algo which used deciaml scaling was greater so I stuck with the one which where closer to the orignal one +09:05 <@wsa_> it's a pity neither morimoto nor shimoda are here; i wanted to discuss testing this driver inside Renesas +09:05 < geertu> neg: it's strange the diff was greather. I can imagine it's greather for some specific values, but on average it should be smaller. +09:05 <@wsa_> neg: given that the precision is higher, this was "non-working" in my book :) +09:06 <@wsa_> it is also a pity that Ulrich is not here, I wonder about Geert's question, too +09:06 < geertu> Perhaps a silly programming error? +09:06 <@wsa_> "BTW, if DR already indicates timeout, what is the added value of TO?" +09:07 * geertu still has to review Uli's SCIF series +09:07 < geertu> The various "feature bits" on SCIF are a collection of wild ideas that came up through multiple brainstorm sessions? +09:08 <@wsa_> heh +09:09 <@wsa_> geertu: any news about the hotel in Brusseles for the pre-FOSDEM meetings? +09:09 < geertu> No, haven't booked anything yet. +09:09 < geertu> I'm trying to find out how many persons will attend ;-) +09:10 <@wsa_> I'll arrive on Thursday and leave on Monday +09:10 < geertu> For Core, we'll have Niklas, Jacopo, Simon, Laurent, and Me. +09:10 < geertu> No recent response from Magnus or Uli +09:11 < geertu> So that makes 5-7 +09:11 < geertu> What about I/O? +09:11 <@wsa_> I recall that Magnus wanted to come? +09:12 < geertu> His current (last I heard from Morimoto-san) plan is to arrive on Fri at 16h +09:12 < geertu> ... which is in-time for the beer event, but nof the meeting, I guess ;-) +09:13 <@wsa_> well, from the last chat meeting, I know of: +09:13 <@wsa_> you, neg, simon, and me +09:13 <@wsa_> probably uli +09:13 <@wsa_> maybe +09:14 <@wsa_> didn't know about Jacopo but he is welcome of course +09:14 < geertu> So incl. J., that's also 5-7 +09:14 <@wsa_> pretty much the same group :) +09:15 <@wsa_> i am likely interested in the core meeting as well +09:16 <@wsa_> we might have cross over tasks anyhow +09:16 <@wsa_> (TDSEL) +09:16 < geertu> ok, 6-8 +09:16 <@wsa_> speaking of, what to do with the TDSEL patch for r8a7790? +09:17 < geertu> That's the one with the hardcoded register values? I don't think we can use it as-is. +09:19 < geertu> There doesn't seem to be a PIN_CONFIG_* for capacitance in enum pin_config_param yet. +09:19 <@wsa_> well +09:19 <@wsa_> the docs don't really allow configuration +09:19 < geertu> (about the hardcoded values) Or don't we need explicit configuration, and should we also use the same value? +09:20 <@wsa_> yes +09:20 < geertu> The docs are conflicting. +09:20 <@wsa_> for H2, they say bits "should be 01" +09:20 <@wsa_> which is not the reset value +09:21 <@wsa_> it even says "must be 01" +09:21 < geertu> Isn't there another doc that says "must be 00"? +09:21 < geertu> While the HW engineers responded that it's the same hardware block everywhere. +09:23 <@wsa_> Yes, M2-W says "must be 00" +09:23 < geertu> If we don't need configuration, doing it in .init() is fine for me. +09:24 <@wsa_> That's a good item for the FOSDEM meeting: +09:25 <@wsa_> if somebody could bring a koelsch, then we could check if the same SDR104 problem with TDSEL=00 exists +09:25 <@wsa_> or any other Gen2 board +09:26 <@wsa_> okay, that was all the topics I had +09:26 <@wsa_> anything left from your side? +09:27 < neg> I have question is this BUG http://pastebin.com/wycYBEyF which can be triggerd on Koelsch by 'reboot' using shmobile_defconfig + CONFIG_DEBUG_ATOMIC_SLEEP known? +09:27 < geertu> Is this card SDR-104? http://www.conrad.be/ce/nl/product/1388580/SanDisk-Ultra-SDHC-kaart-32-GB-Class-10-UHS-I +09:27 < geertu> "systemd-shutdow Not tainted"? Shouldn't systemd taint the system? ;-) +09:28 < geertu> I recently enabled CONFIG_DEBUG_ATOMIC_SLEEP in my .config, but haven't seen that message on my Koelsch. Usually not using shmobile_defconfig, though. +09:28 < neg> I need to switch to init for my NFS, can't boot properly without CONFIG_CGROUPS and CONFIG_SECCOMP :-) +09:29 < neg> the BUG is triggerd by running reboot and hits all the time for me +09:30 <@wsa_> geertu: it should be. it has uhs-1 and i've never seen cards which only support SDR50 but not SDR104 +09:30 <@wsa_> geertu: but shouldn't you play safe and go for micro-sd? +09:30 <@wsa_> I don't know about other Gen2 boards, but Lager has micro-sd only +09:30 < geertu> wsa_: OK. I used my Koelsch a few weeks ago to copy music to that card, to be used in my car. +09:31 <@wsa_> ah, you already have it +09:31 < geertu> Yes. +09:31 <@wsa_> well, the kernel log will tell you which mode was used +09:32 < geertu> I also have a similar smaller uSD card http://www.conrad.be/ce/nl/product/1381015/SanDisk-Ultra-16-GB-microSDHC-kaart-Class-10-UHS-I-incl-SD-adapter +09:32 < geertu> Also used koelsch to init that one ;-) +09:32 <@wsa_> and if the problem is the same, then you will get timeouts after a second or so after removing the card +09:32 < geertu> In SDHI0, of course (SDHI1 is slower) +09:33 <@wsa_> cool +09:33 <@wsa_> because it is only the san-disk card which causes the problem for me +09:33 < geertu> Lemme look in kern.log +09:33 <@wsa_> the samsung card works fine +09:33 <@wsa_> (mine is 64gb, though) +09:36 < geertu> mmc0: new ultra high speed SDR104 SDHC card at address 0007 +09:37 < geertu> mmcblk0: mmc0:0007 SL32G 29.0 GiB +09:37 < geertu> and in SDHI1: +09:37 < geertu> mmc1: new ultra high speed SDR50 SDHC card at address 0007 +09:37 < geertu> mmcblk1: mmc1:0007 SL32G 29.0 GiB +09:37 < geertu> The other one: +09:37 < geertu> mmc0: new ultra high speed SDR104 SDHC card at address aaaa +09:37 < geertu> mmcblk0: mmc0:aaaa SL16G 14.8 GiB +09:38 < geertu> According to the log, I removed and reinserted the second one, and that worked +09:38 <@wsa_> nice to know +09:38 < geertu> If there's anything else I can test +09:39 <@wsa_> don't think so +09:39 <@wsa_> re-inserting is the test to do +09:39 < geertu> You need my TDSEL values? +09:40 <@wsa_> ah, yes +09:40 <@wsa_> i assumed they were 0, but there is firmware involved +09:43 < geertu> => md.l 0xe6060084 2 +09:43 < geertu> e6060084: 00000000 00000000 ........ +09:46 <@wsa_> ok +09:46 <@wsa_> thanks! +09:46 <@wsa_> i'll bring my "magic card" to Brussels nonetheless :) +09:46 < geertu> If you need anything else to be tested, the cards are in my car resp. NanoPi +09:48 <@wsa_> neg: this issue is known. i2c transactions want irqs but they are disabled already that late +09:49 <@wsa_> neg: this is why we have a task for 'irqless i2c communication' in the io todo +09:49 < neg> wsa_: ahh I see, good then I know :-) +09:49 -!- horms [~horms@217.111.208.18] has joined #periperi-io +09:50 <@wsa_> seems i should always mention in the invitation letter that we meet in #periperi-io +09:50 <@wsa_> sorry simon +09:51 < horms> No, the problem is entirely mine. I forgot to add the meeting to my schedule. +09:51 < horms> Appologies for missing the meeting +09:51 < neg> wsa_: could you in the report put a small remark that we would like Morimot-san or Khiem help to test the thermal driver? +09:52 <@wsa_> yes +09:52 <@wsa_> not only a small one :) +09:53 < neg> thanks :-) +09:54 <@wsa_> no prob, simon. i'll upload the log later today +09:54 <@wsa_> so, i have another appointment soon +09:54 <@wsa_> and i think we are done? +09:55 <@wsa_> i'll ask the remaining questions in the summary mail +09:55 <@wsa_> to uli and morimoto +09:55 <@wsa_> until then, have a nice week +09:56 < neg> I have nothing more, thanks all +09:58 <@wsa_> cya! +09:59 < geertu> thx, bye +--- Log closed Wed Dec 14 10:03:36 2016 diff --git a/wiki/Chat_log/20161220-core-chatlog b/wiki/Chat_log/20161220-core-chatlog new file mode 100644 index 0000000..160030d --- /dev/null +++ b/wiki/Chat_log/20161220-core-chatlog @@ -0,0 +1,191 @@ +Core-chat-meeting-2016-12-20 + +09:05 < geertu> Welcome to today's core group chat! +09:06 < geertu> I had hoped for the meeting to be short, but Shimoda-san seems to have a different idea ;-) +09:07 < shimoda> oops ;) +09:08 < shimoda> about the power management discusstion, japan side should discus internally I think. +09:08 < geertu> AH, just looked at the URLs, they're not that controversial. Good. +09:08 < shimoda> especially, magnus-san doesn't know this for now +09:08 < geertu> I guess Magnus is learning Japanese now? +09:09 < shimoda> geertu: i guess so +09:09 < morimoto> He learned how to escape chat meeting +09:09 < geertu> Let's start +09:09 < geertu> Agenda: +09:09 < geertu> 1. Status updates +09:09 < geertu> 2. Power Management implementation on Upstream for R-Car (especially Gen3) +09:09 < geertu> 3. Holidays +09:10 < geertu> Topic 1. Status updates +09:10 < geertu> A) What have I done since last time +09:10 < geertu> B) What I plan to do till next time +09:10 < geertu> C) Problems I have currently +09:10 < geertu> Simon is first +09:11 < horms> --- start --- +09:11 < horms> todo file update is NULL for me +09:11 < horms> Status: +09:11 < horms> A) What have I done since last time +09:11 < horms> * Analysed device tree binding status +09:11 < horms> - Presence and use of SoC-specific and fallback compatibility strings +09:11 < horms> - Posted some fixups +09:11 < horms> - Posted analysis here: http://elinux.org/Bindings:Renesas +09:11 < horms> B) What I plan to do till next time +09:11 < horms> * Continue above +09:11 < horms> C) Problems I have currently +09:11 < horms> * None +09:11 < horms> --- end --- +09:12 < horms> Sorry one Q for later: >4G mem on M3-W +09:12 < geertu> OK. Noted down +09:13 < geertu> Thank you, Simon +09:13 < geertu> Next is Shimoda-san +09:13 < shimoda> yes +09:13 < shimoda> A) +09:13 < shimoda> The core/todo doesn't have such a task but I am thinking of the workaround of IPMMU issue on Gen3 with Magnus-san. +09:13 < shimoda> - I will make complex patches +09:14 < shimoda> - Magnus-san will make simple patches. +09:14 < shimoda> B) +09:14 < shimoda> Continue to make the workaround of IPMMU issue with Magnus-san. +09:14 < shimoda> C) +09:14 < shimoda> None. +09:14 < shimoda> -- end -- +09:14 < geertu> Having a workaround is definitely good to have, thanks! +09:14 < geertu> Next is Niklas +09:15 < neg> a) Posted patches for Fix Runtime PM with GPIO interrupts (depends on irqchip PM). +09:15 < neg> b) Vacation and recreate my for-renesas-drivers branch on top of v4.10-rc1 to ease integration. +09:15 < neg> c) I won't bring any Renesas hardware to the caribbean so will have a hard time testing patches. +09:15 < neg> EOT +09:16 < geertu> neg: Remote access is not fully set up yet? ;-) +09:16 < geertu> Thanks Niklas! +09:16 < geertu> Next is Morimoto-san +09:17 < neg> geertu: it's I can trun on power but not always off :-( +09:17 < morimoto> I have now asked about sound + IPMMU from BSP (?) team on Virtual OS. +09:17 < morimoto> But, not related to upsteam/ (I think) +09:17 < morimoto> A) = B) = C) = NULL +09:17 < morimoto> s/upsteam/upsteam+PeriPeri/ +09:18 < morimoto> --END-- +09:19 < geertu> Thank you, Morimoto-san +09:19 < geertu> Next is Geert +09:19 < geertu> --- start --- +09:19 < geertu> A) +09:19 < geertu> - Resent memory enablement and RAVB for r8a7796/salvator-x +09:19 < geertu> - Sent v2 of swiotlb=noforce, to disable the use of bounce buffers for +09:19 < geertu> debugging +09:19 < geertu> - Prepared 2017Q1 phase1 Core Additional Tasks +09:19 < geertu> - Fix Runtime PM with GPIO interrupts (Niklas) +09:19 < geertu> - ARM64 DMA attributes (Geert) +09:19 < geertu> - MSTP Reset feature (Geert) +09:19 < geertu> - Reviewed http://elinux.org/Bindings:Renesas +09:19 < geertu> B) +09:19 < geertu> - Provide feedback about http://elinux.org/Bindings:Renesas (paper review +09:19 < geertu> -> email conversion) +09:19 < geertu> - Book meeting room Friday before FOSDEM +09:19 < geertu> - ARM64 DMA attributes +09:19 < geertu> - MSTP Reset feature +09:20 < geertu> C) None +09:20 < horms> geertu: sorry, I had not noticed that email +09:20 < geertu> --- end --- +09:20 < geertu> horms: You missed B) ;-) +09:20 < horms> oh, ok +09:20 < horms> silly me +09:21 < geertu> Sorry, it was confusing +09:22 < geertu> All other core members are absent... +09:22 < geertu> Topic 2. Power Management implementation on Upstream for R-Car (especially Gen3) +09:23 < geertu> From Shimoda-san: +09:23 < geertu> --- start --- +09:23 < geertu> I would like to make a plan about Power Management implementation on +09:23 < geertu> Upstream for R-Car (especially Gen3). I didn't know the detail but BSP +09:23 < geertu> power management team has 130 local patches (wow!) to support power +09:23 < geertu> management for Gen3 BSP. So, I would like to do upstreaming about power +09:23 < geertu> management related code as well to reduce the local patches somehow. +09:23 < geertu> Morimoto-san suggested me that we have to integrate i2c_dvfs node at first. +09:23 < geertu> And then, we can implement each driver to support suspend/resume. +09:23 < geertu> --- +09:24 < geertu> (Ah, Khiem is replying to the email) +09:24 < geertu> If my memory serves me well, most patches for suspend are about saving/restoring register contents in each driver. +09:25 < shimoda> geertu: yes, the local patches have such code +09:25 < geertu> I'm afraid the way it's done in the BSP (hardcoded lists of devices in each driver) are not suitable for upstream. +09:26 < shimoda> geertu: i agree with you. +09:26 < morimoto> Yeah, no sense +09:26 < geertu> However, drivers that are also used on older (SH/SH-Mobile) SoCs may already have code upstream to save/restore or reinit registers during resume. +09:27 < geertu> E.g. sh-sci.c reinits registers, which is needed on SH/R-Mobile (removing the reinit breaks the port, I checked that a while ago) +09:29 < geertu> horms: Do you know if the BSP upport task classification project covered the suspend/resume patches in the BSP? +09:30 < horms> it does to the extent that I have tried to consistently mark them as the "Gen3 suspend to RAM" feature +09:30 < horms> I'm happy to refine that if it would be helpful +09:30 < geertu> Right, and they're called "Support DDR backup" +09:30 < horms> many are, yes +09:31 < shimoda> I asked Ito-san of a maneger about power management about this, he would like to do upstream some power management related code. thermal driver, cpu freq, cpu idle and cpu hotplug +09:31 < horms> I could provide a list in .csv file of just those patches. e.g. here or via email. it should be a single grep command away +09:32 < geertu> shimoda: According to Khiem's comments cpu freq, cpu idle, and cpu hotplug should be easy to complete. +09:32 < shimoda> and he are thinking that baylibre can do such upstreaming as well or not +09:32 < geertu> And Niklas is handling thermal +09:32 < shimoda> geertu: oh, i didn't read khiem san's email yet +09:33 < geertu> So the biggest hurdle is suspend to RAM. And we may want to try suspend-to-idle, too. +09:33 < geertu> s/suspend to RAM/non-standard suspend to RAM/ +09:34 < horms> Are Batlibre doing upstream work for us these days? +09:34 < neg> FWIW I plan to post v6 themral tomorrow +09:34 < horms> neg: does the thermal work include ESR? Yet? +09:35 < shimoda> neg: good news to me! thank you for this. +09:35 < neg> horms: ESR? +09:35 < horms> Emergency Shutdown +09:35 < shimoda> horms: yes, i think. (about Baylibre) +09:36 < horms> shimoda: thanks +09:36 < neg> horms: no, don't we need interrupt support first to support that? (new to thermal framework) +09:36 < morimoto> horms: We can forward some taks to Baylibre if PeriPeri can indicate it +09:37 < horms> neg: ok. EMS is the correct acronym. I only as as I see code for it in the BSP. +09:37 < horms> morimoto: ok, great! +09:38 < neg> I have nothing planed or in the pipeline for my base contract Q1 so if approprite I can help out here +09:39 < neg> horms: cool did not know about EMS and that it was in BSP, will have a look +09:39 < horms> neg: drivers/soc/renesas/rcar_ems_ctrl.c might be a good place to start looking +09:39 < horms> I have not inspected its contents +09:43 < geertu> I guess we cann hanle the remainder offline, cfr. the email thread? +09:44 < horms> sounds reasonable as Khiem-san is not present +09:44 < shimoda> I think so +09:45 < geertu> OK, thx +09:45 < geertu> Topic 3. >4G mem on M3-W +09:46 < horms> This seems to be going around in circles. +09:46 < horms> from my pov +09:46 < horms> We tried to manage things nicely +09:47 < horms> but due to unforseen circimatances we are no longer in control +09:47 < horms> i.e. the firmware enables the memory anyway +09:47 < geertu> Correct +09:47 < horms> Can we get closure on this by simply enabling things in DT - which should introduce no run-time change? +09:47 < geertu> Indeed. It behaves the same before and after +09:48 < horms> All currently enabled devices work, or at least have not been reported to be broken, right? +09:48 < geertu> (Linux handles the duplicates, as we add a second memory node, while u-boot adds a second reg set to the first memory node) +09:48 < geertu> Correct. +09:49 < geertu> DMA is impacted by swiotlb, using bounce buffers as rcar-dmac doesn't set the 40-bit DMA mask yet +09:49 < geertu> But that's the case with and without the >4G mem enablement patch, as it's enabled anyway +09:49 < horms> ok, so there is no change +09:50 < horms> do we have a channel where we can discuss this with Magnus? He has shown a paricular interest in this issue. +09:50 < geertu> Email? +09:50 < horms> sounds reasonable +09:50 < horms> do you wish to handle this? +09:52 < geertu> We already discussed this before with him. +09:52 < geertu> Can't find the email thread... +09:54 < horms> ok, perhaps we can follow up on this latter. +09:54 < horms> It would be nice to get some closure on this one +09:54 < geertu> OK, thread was "[PATCH 3/4] arm64: dts: renesas: r8a7796: Add DU device to DT" (sic) +09:54 < geertu> Let's just apply ;-) +09:55 < geertu> Topic 4. Holidays +09:55 < geertu> I'll be going in "quiet mode" soon, until Jan 8. But I will make a renesas-drivers release shortly after v4.10-rc1. +09:56 < pinchartl> should we post out holiday schedule somewhere ? in the wiki ? +09:57 < geertu> Hi Laurent ;-) +09:57 < geertu> Good idea! +09:57 < geertu> (I mean the wiki) +09:57 < shimoda> geertu: i got it. so about the power management discusstion we can restart after Jan 8? +09:58 < geertu> Yes, I think so +09:58 < neg> I will be out of the country 27 Dec -- 7 Jan will have email at house but might spend more time at the beach then the house... +09:59 < horms> I plan to be in quiet mode from the 23rd - 2nd (inclisive) +09:59 < horms> geertu: do you need any renesas-devel releases from me in that timeframe: if so I can make it so +10:00 < geertu> horms: It's not really needed. If none of the for-next branches already have v4.10-rc1 (usually net-next does), I'll just merge it in myself. +10:00 < horms> ok, thanks +10:01 < horms> in that case I'll make releases on a best-effort basis +10:04 < geertu> I think we have everything covered? +10:05 < geertu> Any other topics? +10:05 < geertu> For the people wondering about Berlin: it happened on the place in front of the building where we met for the meeting on Monday. +10:06 < horms> lovely +10:06 < horms> Fortunately my excursion to German Christmas markets yesterday was in a different city. +10:06 < horms> Has anyone heard from Wolfram? +10:07 < geertu> He sent a pull request 5 minutes ago +10:07 < horms> A healthy sign :) +10:07 < geertu> I guess he's not using "at" +10:09 < geertu> I think we can conclude. +10:09 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20161222-mm-chatlog b/wiki/Chat_log/20161222-mm-chatlog new file mode 100644 index 0000000..11b2ea6 --- /dev/null +++ b/wiki/Chat_log/20161222-mm-chatlog @@ -0,0 +1,212 @@ +Multimedia-chat-meeting-2016-12-22 + +09:05 < pinchartl> topics for today +09:06 < pinchartl> - status check as usual +09:06 < pinchartl> anything else for anyone ? +09:07 < pinchartl> I'll take that as a no +09:07 < pinchartl> kbingham: as you're here you can start :-) +09:07 * kbingham should get a name change to zebra +09:08 < pinchartl> be careful what nickname you wish for, they tend to stick around +09:09 * wsa_ used 'sort -R' to generate the speaking order in IO meetings ;) +09:09 < kbingham> So, in the last two weeks, A), I've submitted vsp1 suspend resume patches, and they have been reviewed, and I've done some ftrace measurements on the performance impacts of the changes to where partitions are calculated, (out of interest, and because they are useful to know the numbers/process) +09:10 < kbingham> Externally (but still sort of related), i've spent the majority of this week on my garage office conversion with the Father In Law +09:11 < kbingham> B) - I still intend to follow up on the review comments from the suspend resume patches, and of course we have Christmas holidays here. +09:11 * morimoto start chat in Renesas +09:12 < kbingham> - That will probably be the most I'll achieve in the next two weeks - so the 2016/q1 work will likely start in 2016/q1 :D +09:12 < pinchartl> sounds fair :-) +09:13 < kbingham> C) - I may have sprained my wrist, doing DIY work in the garage. +09:13 * kbingham EOF +09:13 < pinchartl> thank you +09:14 < pinchartl> seems it's time to take a bit of time off the computer to let your wrist rest then +09:14 * kbingham ponders the meaning of 'rest' +09:15 < pinchartl> don't ask me +09:15 < pinchartl> I'm next in alphabetical order +09:15 < pinchartl> over the past two weeks +09:16 < pinchartl> I've started V4L2 cache API analysis and discussions with the V4L2 community +09:16 < pinchartl> I revived a patch series that has been posted a year ago and submitted a new version +09:16 < pinchartl> which has been acked by Hans Verkuil already +09:16 < pinchartl> bus still requires a few changes +09:17 < pinchartl> the code covers V4L2 native buffers, but not buffers imported by V4L2 from dmabuf +09:17 < pinchartl> so I'll still need to address that part +09:17 < pinchartl> and it will require broadening the discussion to include the dmabuf and DRM developers +09:18 < pinchartl> I've also posted a new version of the HDMI output on Gen3 patches +09:19 < pinchartl> the dw-hdmi code has been significantly reworked compared to the previous version and now handles different versions of the IP core in a much cleaner way +09:19 < pinchartl> I've already received a few comments from review, a third version will likely be needed +09:20 < pinchartl> and finally I've spent time fighting with the V4L2 maintainer as usual +09:20 < kbingham> I'm sure synopsis are happy that the underlying hardware abstractions are now less obfuscated :D +09:20 < pinchartl> kbingham: they actually acked a few of the patches, so I think they're happy, yes +09:21 < pinchartl> we have issues in the media controller core that need to be addressed. they've been there from the start, but have been made worse by the maintainer +09:21 < pinchartl> this will require a face-to-face meeting, and one has been proposed at ELC time +09:22 < pinchartl> however, I've decided to organize another one sooner, at mid-January in Oslo +09:22 < pinchartl> Sakari Ailus, Hans Verkuil and myself will attend +09:22 * morimoto back from chat +09:23 < pinchartl> my hope is to come to an agreement with Hans first, without involving other V4L2 maintainers +09:24 < pinchartl> during the next two week I'll continue reviewing, reworking and resubmitting patches that haven't been accepted yet +09:24 < morimoto> Is this issue related to HDMI output ? or just media controller ? +09:25 < pinchartl> media controller only +09:25 < pinchartl> it's not related to any of my additional tasks in particular +09:25 < pinchartl> and it's taking more time from my base contract that I would like :-/ +09:26 < pinchartl> which brings me to the issues and blockers +09:26 < pinchartl> no blocker as such, but an issue +09:26 < morimoto> OK, I understand. +09:26 < pinchartl> I have too much work for my base contract +09:26 < morimoto> :) +09:26 < pinchartl> with all the maintainership and involvement in the V4L2 and DRM/KMS core +09:27 < pinchartl> they're not covered by any additional task, and they take a large amount of time +09:28 < pinchartl> given the current 50/50 split there isn't really room to handle the problem +09:28 < pinchartl> but I hope to be able to offload some of the work to Kieran if we can get budget +09:29 < pinchartl> kbingham: don't worry, I'll still handle the fights, you would mostly need to handle driver maintainership :-) +09:31 < kbingham> pinchartl: will I need more popcorn in that case :D +09:31 < pinchartl> :-) +09:31 < pinchartl> that's all for me +09:31 < pinchartl> morimoto: you're next +09:31 < morimoto> OK +09:31 < morimoto> I asked about ALSA SoC + HDMI + DT things to pinchartl, but couldn't get answer in time +09:32 < morimoto> so I worked other things this week +09:32 < morimoto> I posted few patches to ALSA ML for cleanup etc +09:32 < morimoto> I would like to solve HDMI sound things, but it seems difficult +09:32 < morimoto> Blocker is it. +09:33 < morimoto> pinchartl said that V4L2 side is thinking about .query method ? +09:33 < morimoto> but, I still wondering about it. +09:33 < pinchartl> it's a problem that spans multiple subsystems, so it should be implemented at the media controller level in my opinion +09:34 < pinchartl> but we're definitely not there yet and it will require a lot of work +09:34 < morimoto> does your "we" mean PeriMulti ? or V4L2 ? +09:35 < morimoto> or Linux ? +09:35 < pinchartl> Linux :-) +09:35 < morimoto> hehe, OK :) +09:35 < pinchartl> I know how I'd like to see this being implemented +09:35 < pinchartl> and it would require using the media controller framework in DRM/KMS and ALSA +09:36 < pinchartl> which means that we need to solve the MC core issues first +09:36 < morimoto> MC core ? +09:36 < pinchartl> otherwise it will not be possible to convince other subsystems to use it +09:36 < pinchartl> media controller core +09:36 < morimoto> Ahh OK +09:37 < morimoto> From ALSA side point of view, it need to care about non-HDMI and HDMI. So my question is that +09:37 < morimoto> Does your "MC" is related to both non-HDMI and HDMI ? +09:37 < morimoto> or only HDMI ? +09:37 < pinchartl> both +09:37 < morimoto> Hmmm +09:37 < morimoto> This means, existing ALSA itself need to be update ? +09:38 < morimoto> without HDMI support +09:38 < pinchartl> the problem is that we need to know about port types to parse and walk the DT OF graph +09:38 < pinchartl> that information isn't available in DT +09:38 < pinchartl> it is only known to drivers +09:38 < morimoto> Yes. +09:38 < morimoto> But, in existing ALSA, all are sound, no question. +09:38 < pinchartl> so we can't implement generic OF graph parsing and walking code without help from drivers +09:39 < pinchartl> we need a new API for drivers to provide the information +09:39 < morimoto> OK, I see. but I wonder, this means, I can't rework for HDMI sound at this point ? +09:40 < pinchartl> when an OF graph is limited to one of the ALSA, DRM and V4L2 subsystems only, we can implement a subsystem-specific solution +09:40 < pinchartl> but in the general case, we need a solution that is compatible will all three subsystems +09:40 < pinchartl> so we need a common object that can implement this API +09:40 < pinchartl> and at the moment we have none +09:41 < morimoto> My ? is related to here +09:41 < pinchartl> the best candidate in my opinion is the media_entity object, that would need to be used by all three subsystems +09:41 < pinchartl> HDMI sound doesn't involve V4L2 but it involves the two other subsystems +09:41 < morimoto> three = ALSA / DRM / V4L2 ? +09:41 < pinchartl> yes +09:42 < morimoto> If this OF graph is related to only multimedia case, right ? +09:42 < pinchartl> it should be yes +09:42 < morimoto> If non multimedia want to use OF, it will not be "media_entity" +09:42 < morimoto> Hmm... +09:43 < pinchartl> correct, but non-multimedia devices don't involve ALSA :-) +09:43 < pinchartl> I'm open to other proposals, but in any case I believe this will be lots of work +09:43 < morimoto> But can use OF-graph ? +09:44 < morimoto> Is this related to know "which port is what type" ? +09:44 < morimoto> = OF-graph +09:44 < pinchartl> it's related to OF graph parsing +09:44 < pinchartl> not only about port type +09:45 < pinchartl> a DT node has ports that describe its external connections +09:45 < morimoto> OK, if so, naming should use "media" ? +09:45 < morimoto> should not +09:45 < pinchartl> but doesn't include information that describe the internals of the IP core +09:45 < pinchartl> that's the information missing at the moment +09:46 < pinchartl> we could use a different namespace, implement the API at a different level +09:46 < pinchartl> I'm not sure where though +09:46 < morimoto> I understand basic ideas +09:47 < morimoto> I wonder where do you (or other guys ?) discuss this topics ? +09:47 < morimoto> I mean which ML ? +09:47 < morimoto> ALSA side guys need to join it +09:47 < pinchartl> MC discussions usually happen on the linux-media mailing list +09:48 < pinchartl> if we implement the API somewhere else, I don't know +09:48 < morimoto> This is "OF-graph" releated method, right ? +09:48 < morimoto> we can get information from this new API +09:48 < morimoto> not only type, but many information +09:49 < pinchartl> yes, we need more than just the type +09:49 < morimoto> But this OF-graph use is not only V4L2, ALSA. +09:49 < pinchartl> if you have a DT node with 4 ports +09:49 < pinchartl> two inputs and two outputs +09:49 < morimoto> Other device can use it ? +09:50 < morimoto> I don't know who, but not only media I think ? +09:50 < pinchartl> it could be that internally input 1 is connected to output 1 and input 2 to output 2, creating two separate unrelated pipelines +09:50 < pinchartl> when parsing the graph we'd need to know about that +09:50 < pinchartl> possibly, but at the moment only multimedia devices use OF graph +09:51 < morimoto> OK +09:51 < morimoto> So, this means, my HDMI sound can't upstream at this point, right ? +09:52 < morimoto> It will be step 3 or later +09:52 < morimoto> not step 1 +09:53 < pinchartl> yes, I think we're blocked at the moment +09:53 < morimoto> OK. can you update multimedia/todo ? +09:53 < morimoto> It is not my fault :P +09:53 < morimoto> It is = delaying +09:54 < pinchartl> obviously another approach would be to use a different style of DT bindings that would be easier to handle. lots of options are possible. we're at a brainstorming stage, someone needs to drive the effort with all the upstream subsystems. it's lots of work :-/ +09:54 < pinchartl> sure, it's not your fault :-) +09:55 < morimoto> Hehe :) thanks +09:55 < pinchartl> I'll remove the target version from the todo list +09:55 < morimoto> So, I will start other tasks. +09:55 < morimoto> Thanks +09:55 < pinchartl> well +09:55 < pinchartl> if you move to other tasks +09:55 < pinchartl> who will solve this problem ? :-) +09:56 < morimoto> Oops, OK +09:56 < morimoto> I am 1 of un-lucky guys :) +09:56 < pinchartl> welcome to my world :-) +09:56 < morimoto> Hehe :) +09:57 < morimoto> I think I want to talk to you in F2F in some day +09:57 < morimoto> Maybe ELC +09:57 < morimoto> ? +09:57 < morimoto> Do you go there ? +09:57 < pinchartl> I will be there +09:57 < morimoto> OK +09:57 < pinchartl> I've submitted a talk proposal, I hope it will be accepted +09:58 < morimoto> OK +09:58 < morimoto> that's it from me +09:58 < pinchartl> it's quite a lot already :-) +09:58 < pinchartl> thank you +09:58 < pinchartl> (now I have to summarize this in the report...) +09:59 < pinchartl> I assume that your plans for the next two weeks is holidays ? :-) +09:59 < pinchartl> (29th to 9th if I remember correctly) +10:00 < morimoto> Me ? yes +10:01 < pinchartl> neg: you're next +10:01 < neg> a) Started to address CSI2 review comments, more work needed. +10:01 < neg> b) Continue addressing CSI2 comments, but don't expect to resend before next meeting due to holidays and vacation. +10:02 < neg> c) None. +10:02 < neg> EOT +10:02 < pinchartl> thank you +10:03 < pinchartl> next topic: next meeting +10:03 < pinchartl> if we keep the current biweekly schedule that would be January the 4th +10:04 < pinchartl> however, Niklas and Morimoto-san will still be on holidays +10:04 < pinchartl> and Ulrich and Kieran will just be back +10:04 < kbingham> pinchartl: Bump it by a week? +10:04 < pinchartl> so I don't expect there will be much to discuss +10:04 < pinchartl> kbingham: that's my proposal, yes +10:04 < kbingham> pinchartl: then seconded :D +10:04 < pinchartl> about about January the 11th at 08:00 GMT / 09:00 +10:04 < pinchartl> CET / 10:00 EET / 17:00 JST +10:05 < neg> works for me +10:05 < kbingham> day after my birthday ... I'll bring cake +10:05 < pinchartl> :-) +10:05 < pinchartl> how old will you be ? +10:05 < morimoto> it is OK for me +10:06 < kbingham> 0x21 +10:06 < kbingham> :D +10:06 < pinchartl> :-) +10:07 * morimoto I booked Kieran's birthday on my calender +10:07 < kbingham> hehe +10:07 < pinchartl> that's all I had for today +10:08 < pinchartl> I propose adjourning the meeting +10:08 < pinchartl> does anyone second ? +10:08 < kbingham> I +10:08 < pinchartl> meeting adjourned, thank you all for attending +10:08 < morimoto> 2nd ! +10:09 < morimoto> Thank you diff --git a/wiki/Chat_log/20170111-mm-chatlog b/wiki/Chat_log/20170111-mm-chatlog new file mode 100644 index 0000000..3088275 --- /dev/null +++ b/wiki/Chat_log/20170111-mm-chatlog @@ -0,0 +1,274 @@ +Multimedia-chat-meeting-2017-01-11 + +<pinchartl> good morning [16:58] +<morimoto> morning +<uli___> morning +<neg> morning [16:59] +<pinchartl> Kieran seems to have left the channel during the night. perhaps as + a consequence of too much birthday partying :-) +<pinchartl> any chance Magnus would join today ? [17:00] +<morimoto> I have no idea about him :) [17:01] +<pinchartl> I think I'll stop expecting him to join :-) +<morimoto> :) [17:02] +<pinchartl> let's start then. I expect the meeting to be short today +*** kbingham (~kbingham@core.do.nakedgeek.co.uk) has joined channel #periperi +<pinchartl> hi Kieran ! +<pinchartl> we were about to start +<pinchartl> Topic 1. Status check for the multimedia tasks +<kbingham> sorry for being late - my IRC bouncer crashed :( +<pinchartl> Topic 2. Additional tasks for Q1 2017 +<pinchartl> Topic 3. FOSDEM [17:03] +<pinchartl> Topic 4. Next meeting +<pinchartl> anything else for the agenda ? +<pinchartl> no worries +<morimoto> ELC meeting plan I want to know +<pinchartl> ok, FOSDEM & ELC then +<pinchartl> let's get started with Topic 1. Status check for the multimedia + tasks [17:05] +<pinchartl> Kieran, will you do the honours ? +<kbingham> pinchartl: I thought you might say that :D +<kbingham> So - to start, since last meeting: +<kbingham> - Holidays [17:06] +<kbingham> - Had my birthday +<kbingham> - Suspend resume patches reposted +<kbingham> - Rebased all my topic branches +<kbingham> And I'm currently working on the image partitioning overlap topic +<kbingham> So B) Plan until next meeting: [17:07] +<kbingham> - At two weeks away, I hope I will have made most of the headway + to getting the image partitioning task complete, possibly mixed in + with some of the work on the vsp-test improvements - but with no + confirmation from renesas, I guess those topics could stop at any + time. [17:08] +<kbingham> leaving C) +<kbingham> - current work still pending contract from Renesas [17:09] +<kbingham> - Experiencing some issues on vsp-unit-test-0003.sh +<kbingham> : EOT : Sorry - Would normally prepare the text for this in + advance - but finished early due to my birthday yesterday :D + [17:10] +<pinchartl> thank you [17:11] +<kbingham> pinchartl: Is there anything you'd like me to do on the pending + topic branches? [17:12] +<pinchartl> could you push them to your public tree ? I'll review the patches + you posted +<kbingham> Ok - I'll push my rebased updates. +<kbingham> Should they be re-emailed? [17:13] +<pinchartl> not if it's just a rebase, I'll review them first [17:14] +<pinchartl> if they have otherwise changed, please resend them +<kbingham> Ok. [17:15] +<pinchartl> next in alphabetical order, me +<pinchartl> Since last meeting: +<pinchartl> - Holidays [17:16] +<pinchartl> - New version of the Gen3 HDMI output patches (split in topic + branches) +<pinchartl> - Started experimenting with fences in the DU driver +<pinchartl> - DRM/KMS community discussions to get the LVDS mode select, LVDS + encoder and HDMI output merged (or at least closer to be merged) +<pinchartl> - Helped Jinzai to test HDMI output +<pinchartl> For the next two weeks: +<pinchartl> - Pending VSP patch review +<pinchartl> - Continue advancing Gen3 HDMI output towards merging +<pinchartl> - V4L2 & media controller race conditions meeting in Oslo with + Hans Verkuil & Sakari Ailus +<pinchartl> (that's this Friday) +<pinchartl> Issues and blockers: +<pinchartl> - No additional task yet for 2017/Q1 [17:17] +<pinchartl> and I will be on holidays from the 20th to the 28th +<kbingham> pinchartl: Of january? [17:18] +<pinchartl> yes +<kbingham> pinchartl: Ok :D +<pinchartl> skiing in the French Alps +<pinchartl> I'll have e-mail access +<neg> pinchartl: will you also discusss Media Device Allocator API in Oslo + (that is if it's to be pushed or dropped)? [17:19] +<pinchartl> morimoto: that's a topic we've discussed already, but I had to + hand-hold Jinzai because they seemed not to be able to select the + HDMI driver in the kernel config by themselves... +<pinchartl> neg: not as such. we'll discuss what needs to be fixed in order to + get that API merged +<pinchartl> I want to fix the current code base before building anything new + on top of it +<neg> ok thanks for the update [17:20] +<pinchartl> next, Morimoto-san [17:21] +<morimoto> OK +<morimoto> A) - Enjoyed New Year +<morimoto> - I posted ALSA SoC framework fixup patches +<morimoto> - Helped BSP team about sound [17:22] +<morimoto> B) I will rebase my HDMI sound on pinchartl's latest branch +<morimoto> - I will book ELC hotel / flight etc +<morimoto> C) nothing +<morimoto> --EOT-- +<pinchartl> thank you +<pinchartl> neg: your turn [17:23] +<neg> A) Noting (rebasaed all my topic branches on v4.10-rc1 and test them) + [17:24] +<neg> B) Fix review comments and repost CSI-2 and breakout fixup patches from + VIN Gen3 series and repost as seperat series (needad as to not block + Wolframs work) and pray that series is reviewd/picked up :-) +<neg> C) None +<neg> EOT +<pinchartl> is it OK with you if I start by reviewing the CSI-2 driver, + followed by the VIN driver ? [17:25] +<neg> yes, but maybe we can fast track the break out fixup VIN patches as to + not block Wolfram? [17:26] +<neg> those patches will be small and only deal with Gen2 concepts +<pinchartl> oh yes sure [17:27] +<neg> thanks +<pinchartl> I meant CSI-2 before VIN Gen3, but obviously other VIN patches can + go in first +<neg> would you prefer I try to get CIS-2 merged before Gen3 VIN patches? +<neg> s/CIS/CSI/ [17:28] +<pinchartl> it might be easier +<pinchartl> but it also makes sense to merge everything anyway +<pinchartl> so I have no big preference at the moment +<neg> ok then I will stop trying to hold CSI-2 back to be merged after VIN + Gen3 and which ever is picked up first is OK +<pinchartl> next, uli___ [17:29] +<uli___> a) +<uli___> - vacation +<uli___> - investigated what it takes to get gpu going with binary blobs on + gen3 [17:30] +<uli___> b) +<uli___> - trying not to succumb to the infection that has incapacitated my + wife for a week... +<uli___> c) +<uli___> - add. tasks not finalized yet +<uli___> that's it +<pinchartl> thank you [17:31] +<pinchartl> before going to the next topic +<pinchartl> I'd like to thank Morimoto-san for sending his report over e-mail +<pinchartl> given that we're just out of the winter holidays, without much to + report, I'll ignore the fact that nobody else has +<pinchartl> but please remember to post a summary before next meeting [17:32] +<pinchartl> Topic 2. Additional tasks for 2017/Q1 +<pinchartl> as you all know, we have no additional tasks finalized for 2017/Q1 +<pinchartl> there were discussions at the end of last year +<pinchartl> and before a conclusion could be reached the winter holidays + started and Magnus disappeared [17:33] +<pinchartl> I haven't heard anything from him since then +<pinchartl> which starts worrying me +<morimoto> Magnus disappeared... +<pinchartl> morimoto: do you have any information ? +<morimoto> I will meet him tomorrow. +<morimoto> I will kick him [17:34] +<pinchartl> thank you +<morimoto> for you guys :) +<pinchartl> I've already started working on tasks that will likely be selected + for 2017/Q1 +<kbingham> wear heavy boots :D +<pinchartl> so has Kieran, and from what I've heard today from Ulrich, he did + as well +<pinchartl> but there's no contract signed yet +<pinchartl> so this is really a gesture of good faith +<pinchartl> not a situation that I want to experience again in the future +<pinchartl> it shows that the task negotiation process doesn't work [17:35] +<pinchartl> it's the second time we're late, albeit last time the delay was + shorter +<pinchartl> so I will request to move back to a single batch per quarter +<uli___> i think i would prefer that as well [17:37] +<pinchartl> as there seems to be no comment about this, +<pinchartl> (oops, except for that comment :-)) +<pinchartl> Topic 3. FOSDEM & ELC +<pinchartl> we have reserved time for a multimedia meeting on the Thursday + before FOSDEM, but given the lack of contracts, and thus the lack + of topics to discuss, I don't plan to organize such a meeting + [17:38] +<pinchartl> I will be in Brussels the whole week before the FOSDEM, so if any + of you happens to be there and wants to schedule an ad-hoc + meeting, I'll be available [17:39] +<pinchartl> I believe Kieran will be there from Wednesday as well [17:40] +<kbingham> ACK. +<neg> Was not Q2 contract proposals a topic for that meeting? [17:41] +<pinchartl> neg: it was, but Magnus won't be there, and we don't have Q1 + contracts yet +<neg> Ahh I though Magnus would be there, my mistake [17:42] +<pinchartl> when will everybody be available in Brussels ? Kieran, you'll be + there from Feb the 1st to the 6th, right ? how about Niklas and + Ulrich ? +<uli___> i won't be there. i've fallen ill every single time i have attended + fosdem, and this time i just won't go. no kidding at all. + [17:43] +<uli___> come back when it's in june +<neg> I was planing to arrive on Wed evening to be aviable for Multimedia + meeting, but if that is off I think I move my arrival date to Thu + evening +<pinchartl> ok [17:44] +<pinchartl> Morimoto-san wanted to know more about our ELC plans [17:45] +<morimoto> Yes. Do we have MM meeting ? +<neg> and yes also leving in the morning the 6th. But if there are plans or + suspicions of plans for meetings please let me know and I can adjust my + schedule +<pinchartl> nothing has currently been scheduled, as everything regarding + multimedia planning has been on hold since end of December and the + lack of contracts [17:46] +<pinchartl> officially, right now there's no multimedia team anymore +<pinchartl> so before scheduling a meeting, we should sort that out +<morimoto> pinchartl: scheduling a meeting = ELC meeting ? or FOSDEM meeting ? + [17:47] +<pinchartl> both +<morimoto> OK +<morimoto> and MagPeri is the Key guys ? +<pinchartl> he seems to be +<morimoto> OK [17:48] +<neg> morimoto: which dates do you plan to be at ELC? I think I change my mind + and intend to go if I can find a good flight :-) +<morimoto> at this point, maybe 20th - 24th +<neg> so that would leave the 20th and 24th for possible meeting days ? + [17:49] +<morimoto> that the reason why I'm asking about meeting :) [17:50] +<morimoto> If we have meeting, the plan will be changed +<pinchartl> I will arrive on the 18th and leave on the 25th +<pinchartl> the 19th (Sunday), 20th and 24th are currently free +<pinchartl> but I expect a V4L2 meeting to be scheduled, likely on the 20th +<morimoto> pinchartl: Do you think "media-layer" will be discussed on V4L2 + meeting ? [17:52] +<pinchartl> what do you mean by media-layer ? +<morimoto> V4L2 + ALSA need media-layer for OF-graph ? +<pinchartl> probably not [17:53] +<pinchartl> it will likely be focussed on core media controller problems +<neg> OK, in order to be able to book flights maybe we can aim to keep the + 24th open for a possible meeting if the contract situation is sorted + out? My understanding is that nither Geert nor Wolfram will attend ELC + so MM is the only possible meeting at that time? [17:54] +<pinchartl> the 24th would be nice +<pinchartl> if you can be there on both the 20th and the 24th it would give us + some flexibility +<pinchartl> and you could join the V4L2 meeting when it will be scheduled :-) + [17:55] +<neg> cool then I try to book flight to arrive 19 and leave 25 +<morimoto> cool. I will re-schedule for ELC +<neg> yes if possible I would like to attend the V4L2 meeting, without + periperi scheduling collision :-) +<pinchartl> last topic [17:56] +<pinchartl> Topic 4. Next meeting +<pinchartl> I will be on holidays in two weeks from now +<pinchartl> so we can schedule a meeting in a week +<pinchartl> or in three weeks +<pinchartl> one week is likely too short as we have no contract at the moment +<pinchartl> 3 weeks seems better +<pinchartl> but that might collide with Kieran's travel plans for the FOSDEM + [17:57] +<pinchartl> (which would give Kieran a good excuse to not attend the meeting + :-)) +<pinchartl> would wednesday 2017-02-01 at 08:00 GMT / 09:00 CET / 10:00 EET / + 17:00 JST work ? +<kbingham> it does cut it close ... but its actually probably just about + do-able ... as long as I book my taxi to pick me up at the end of + the meeting :D [17:58] +<pinchartl> :-) +<kbingham> So yes, fine by me. +<pinchartl> if you have to skip it's not an issue +<pinchartl> does it work for everybody else ? +<uli___> ok for me +<neg> OK for me [17:59] +<morimoto> OK for me too +<pinchartl> perfect, it's agreed then +<pinchartl> I propose adjourning this meeting [18:00] +<pinchartl> does anyone second ? +<kbingham> seconded and running downstairs to make tea :D +<pinchartl> :-) +<pinchartl> meeting adjourned +<pinchartl> thank you everybody for attending +<pinchartl> have a nice day/evening [18:01] +<morimoto> Thanks +<uli___> see you +<neg> thanks all diff --git a/wiki/Chat_log/20170116-io-chatlog b/wiki/Chat_log/20170116-io-chatlog new file mode 100644 index 0000000..3cf4ad2 --- /dev/null +++ b/wiki/Chat_log/20170116-io-chatlog @@ -0,0 +1,148 @@ +--- Log opened Mon Jan 16 08:59:32 2017 +08:59 -!- wsa_ [~wsa@p54B33FFD.dip0.t-ipconnect.de] has joined #periperi-io +08:59 -!- Irssi: #periperi-io: Total of 5 nicks [1 ops, 0 halfops, 0 voices, 4 normal] +08:59 -!- Irssi: Join to #periperi-io was synced in 1 secs +09:00 < wsa_> hey guys! +09:00 <@morimoto> hi +09:00 -!- shimoda [~shimoda@relprex3.renesas.com] has joined #periperi-io +09:00 < neg> horms: I accidently sent my ABC awnsers from my private email address to periperi, I have now resent the anwsers but feel free to delete and not to add my private email to the periperi whitelist :-) +09:00 -!- morimoto [~user@relprex3.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +09:00 < neg> wsa_: hi +09:00 < horms> neg: ok, will do +09:01 < neg> horms: thanks +09:01 -!- geertu [~geert@d54C189FD.access.telenet.be] has joined #periperi-io +09:01 < wsa_> that reminds me, simon you can remove the wsa-dev address from periperi as well +09:01 < geertu> Bummer, I was in #peripero-io +09:01 < horms> wsa_: sure +09:01 < wsa_> wsa@the-dreams.de seems to be back at full strength +09:02 < wsa_> geertu: "we are the popular front" +09:02 < wsa_> :D +09:03 -!- Irssi: #periperi-io: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal] +09:04 < wsa_> ok, let's start +09:04 < wsa_> thanks for all the updates +09:04 < wsa_> despite holidays, there were some things going on :) +09:05 < wsa_> i have a few questions +09:05 < wsa_> first one about USB & IPMMU, I lost track a little of it +09:05 < wsa_> shimoda: does a workaround exist meanwhile? +09:06 < shimoda> wsa_: a workaround exist for some devices +09:07 < wsa_> and the SD workaround is basically the same issue +09:07 < wsa_> IPMMU issue +09:07 < wsa_> ? +09:08 < shimoda> wsa_: no. SDHI's restriction differs with IPMMU restriction... +09:09 < wsa_> OK, then I need to reread about that +09:10 < shimoda> wsa_: OK. But, I forgot that I wrote the SD restriction on periperi ML or not +09:10 < shimoda> so, i will summarize them later +09:10 < neg> is this be related to the IPMMU warnings seen on Gen2 while tuning SD or is it unrelated? +09:11 < wsa_> shimoda: thank you +09:11 < shimoda> neg: i'm not sure, but gen2 SYS-DMAC with IPMMU also has a problem +09:12 < geertu> There's also ipmmu-vmsa e67b0000.mmu: DMA-API: device driver tries to sync DMA memory it has not allocated +09:13 < neg> shimoda: ok thank you, I will read your upcoming summary on periperi and take it from there :-) +09:14 < wsa_> sounds good +09:14 < wsa_> i'm also looking forward to the desc :) +09:15 < wsa_> next question I have is about thermal driver testing +09:15 < wsa_> just so I know how to handle upstreaming +09:16 < wsa_> how likely is it that we can get Renesas testing from Gomi-san like this week or next week? +09:16 < shimoda> geertu: sorry I don't understand this "DMA-API" things +09:17 < geertu> shimoda: It means the ipmmu driver does something on a wrong pointer +09:17 < geertu> which may lead to corruption. +09:18 < wsa_> and would it be OK for Renesas if we upstream the driver without internal testing to get into v4.11 and fix issues (if any) with incremental patches? +09:18 < shimoda> wsa_: about thermel driver, Gomi-san and RVC are checking the v6 patch. and maybe i will get some feedack in this week . +09:18 < wsa_> \\o// +09:18 < wsa_> awesome! +09:19 < wsa_> still, the answer to the above question would be nice to know (to have a "Plan B") +09:21 < horms> wsa_: i would think the answer is yes unless there has been special requests made with regards to thermal from Renesas +09:22 < wsa_> there are no special requests +09:22 < shimoda> geertu: it's interesting. Is this easy to reproduce? +09:23 < geertu> shimoda: Yes, it happens during ipmmu init. Just enable CONFIG_DMA_API_DEBUG=y +09:23 < wsa_> special is that we can do very limited testing on this one +09:23 < horms> wsa_: then I think you should do whatever is best from an upstream pov +09:24 < geertu> Sorry, during ravb_probe(), but I think it happens during init of the first user +09:24 < horms> wsa_: right, obviously we don't want things catching fire :) +09:24 < shimoda> geertu: thank you. i will try the config later +09:24 * wsa_ sings "relight my fire..." +09:25 < horms> haha: lets not have that be the theme for a patchset +09:25 < wsa_> :) +09:26 < wsa_> ok, so we'll try to get it into 4.11 anyhow, but hope that Gomi-san will be able to test this week +09:26 < wsa_> which would be awesome +09:28 < wsa_> is uli back from the holidays? +09:29 < wsa_> well, he has been on the multimedia meeting +09:29 < wsa_> would like to have had an update for his series -> will ask by mail +09:29 < wsa_> any questions from your side? +09:30 < horms> nothing in particular, other than that he should consider resending any outstanding patches +09:31 < neg> wsa_: you got time to talk about IO task after meeting? +09:32 < wsa_> yup +09:32 < wsa_> it's about emergency shutdown right? +09:33 < neg> yes +09:33 < horms> you probably know, but there is code in the BSP for that +09:33 < wsa_> well, there goes the last chance of really creating fire... +09:34 < neg> horms: I had a quick look at it, but I only found it by luck so thanks for pointing it out :-) +09:35 < horms> neg: any time +09:35 < wsa_> ok, if there are no other questions, let's talk about further hacking thermal/emergency +09:36 < wsa_> people not interested are free to leave, but everyone is welcome to stay, of course :) +09:36 < horms> i had one question, sorry +09:36 < wsa_> sure +09:36 < horms> meeting next month in .be +09:36 < horms> any firm plans? +09:37 < shimoda> about emergency shutdown, this is also handled by Gomi-san and/or related member. so, i can ask him about this +09:37 < wsa_> there will be an io meeting on friday +09:37 < wsa_> when exactly depends on when we have the room +09:37 < wsa_> geertu: ? +09:38 < horms> ok, do we have a location: I only ask so I can arrange some accomodation for myself +09:38 < geertu> horms: Yes, see "Meeting around FOSDEM" +09:39 < geertu> on periperi-ML +09:39 < horms> ok, thanks +09:39 < geertu> wsa_: I don't have hours, it's booked for the full day +09:39 < horms> I see it now +09:39 < neg> shimoda: thanks for telling me Gomi-san is working with emergency shutdown +09:40 < geertu> As I have to get their by train, I think I can be their at 9 or 9h30 +09:40 < geertu> Of course you can start earlier ;-) +09:41 < geertu> s/be their/be there/ +09:41 < wsa_> i don't think i can make it earlier than 9 as well +09:41 < horms> fwiw, i will likely arrive the day before +09:42 < wsa_> 9-13 first meeting, lunch, 14-18 second meeting ? +09:42 < geertu> Please reply to "Meeting around FOSDEM" to confirm your (un)attendence by Wednesday morning, thanks +09:42 < neg> I think 9:30 is a fine time, I need to navigate the local public transport system which if last year was any indication of my skill will take some time :-) +09:42 < geertu> BTW, Magnus just told me Ito-san may want to join the meetings +09:43 < wsa_> i'll be likely in brussels on thursday as well, but just "likely" yet... +09:43 < geertu> neg: I believe there's a direct subway from your hotel +09:43 < wsa_> neg: ok +09:43 < wsa_> 9:30-13:30 first meeting, lunch, 15-19 second meeting ? +09:44 < geertu> 13:30 may be a bit late for lunch +09:44 < neg> geertu: ahh thanks, will look it up +09:45 < wsa_> 9:30-13:00 first meeting, lunch, 14:30-18 second meeting, then open_end hacking ? +09:45 < geertu> What about 9:30-12:30 (I/O), 13:30-16:30 (Core), 16:30-18:00 (misc) +09:45 < wsa_> also fine +09:46 < wsa_> although, 1:30 for lunch might be more relaxing +09:46 < geertu> Note that we have to think about Dinner, and FOSDEM Beer Event starts at 16:00 :-) +09:47 < wsa_> even if it is lurking in the room for 30 minutes or having a short walk or something +09:48 < wsa_> can't tell that yet, i have not made all FOSDEM appointments +09:49 < wsa_> might be I'm busy on Friday evening meeting some ppl +09:49 < wsa_> hopefully not +09:49 < wsa_> :) +09:50 < wsa_> ok, back to thermal? +09:52 < wsa_> neg: fire away +09:52 < neg> So my question is more or less if you think "Thermal,?,noplan,?,add emergency shutdown support" could be a base or additonal task for me duing Q1 or if you rather see me working on something else. At the moment I have no IO tasks planed for Q1 +09:53 < wsa_> i was rather thinking about "Thermal,?,noplan,?,add interrupt support" as your next task :) +09:54 < wsa_> which might be a prerequisite for shutdown anyhow +09:54 < wsa_> haven't checked +09:54 < neg> OK that also sounds like a suitable task for me +09:55 < wsa_> i have some drafts on my hdd somewhere, but it needs to be heavily refactored +09:55 < wsa_> if not redesigned +09:56 < wsa_> but at least we got the bindings in shape already +09:56 < wsa_> so we have freedom to redesign +09:57 < neg> OK that is fine, there is no rush we can hammer it out with email maybe before FOSDEM. My primary cencern where that there where some IO work for me to do :-) +09:57 < wsa_> interrupts were the reason why I went from three DT nodes to one and to introduce the #thermal-sensor-cells to be 1 +09:58 < wsa_> you won't be bored with us +09:58 < wsa_> if all fails, there is SDHI ;) +09:59 < wsa_> but i think thermal might be your friend in the next time +10:00 < neg> nice :-) Then maybe you can send me the draft you made and think about if you wish me to do this as part of base or if we should try to get some of the work as an additinal contract and we take it from there? +10:00 < wsa_> exactly +10:01 < neg> thank you +10:03 < wsa_> i think we are done then +10:03 < wsa_> thank you all! +10:03 < wsa_> have a great week +10:03 < neg> I have nothing more, thanks all +10:04 < shimoda> thank you! +10:05 < geertu> thx +10:10 -!- shimoda [~shimoda@relprex3.renesas.com] has quit Quit: WeeChat 0.4.2 +--- Log closed Mon Jan 16 10:16:36 2017 diff --git a/wiki/Chat_log/20170117-core-chatlog b/wiki/Chat_log/20170117-core-chatlog new file mode 100644 index 0000000..5f9794d --- /dev/null +++ b/wiki/Chat_log/20170117-core-chatlog @@ -0,0 +1,210 @@ +Core-chat-meeting-2017-01-17 + +09:05 < geertu> Welcome to today's Core Group Chat! +09:05 < geertu> Agenda: +09:05 < geertu> 1. Status updates +09:05 < geertu> 2. IPMMU +09:05 < geertu> 3. PFC/GPIO entanglement on RZ/A1H +09:06 < geertu> Topic 1. Status updates +09:06 < geertu> A) What have I done since last time +09:06 < geertu> B) What I plan to do till next time +09:06 < geertu> C) Problems I have currently +09:06 < geertu> $(sort -r) says first is Simon +09:06 < horms> --- begin --- +09:06 < horms> a) What have I done? +09:06 < horms> No core tasks +09:06 < horms> b) What do I plan to do next? +09:06 < horms> Address review of compatibility string analysis. +09:06 < horms> c) What problems do I have? +09:06 < horms> None +09:06 < horms> --- end --- +09:07 < geertu> Thank you, Simon! +09:07 < geertu> Next is Shimoda-san +09:07 < shimoda> --- begin --- +09:07 < shimoda> A) What have I done? +09:07 < shimoda> - Make/test a workaround for Gen3 IPMMU issue with Magnus-san. +09:07 < shimoda> B) What do I plan to do next? +09:07 < shimoda> - Continue to test the IPMMU workaround patch on Gen3 and submit it. +09:07 < shimoda> C) What problems do I have? +09:07 < shimoda> - How to start Power Management things again. Maybe I should start it on email? +09:07 < shimoda> --- end --- +09:08 < geertu> I think email is a good way +09:08 < shimoda> geertu: i got it. i will start it by email +09:09 < geertu> Thank you, Shimoda-san +09:09 < geertu> Next is Niklas +09:09 < neg> A) Posted patch to add support for negative divisors to DIV_ROUND_CLOSEST (needed by Gen3 thermal) +09:10 < neg> B) Do more tests on Runtime PM with GPIO interrupts patches and find a new sutable Core task to start work on (or maybe do that at FOSDEM which is after next IRC meeting) +09:10 < neg> C) None +09:10 < neg> EOT +09:10 < geertu> Thank you Niklas +09:10 < geertu> Next is Morimoto-san +09:11 < morimoto> A) = B) = C) = NULL +09:11 < morimoto> EOT +09:11 < geertu> Thank you Morimoto-san +09:11 < geertu> Next is Marek, who I forgot to introduce (sorry about that). Can you please introduce yourself? +09:12 < Marex> Hi, I'm Marek Vasut, I'm new here, I've been doing kernel work for a while though, thank you for having me +09:12 < Marex> A) I sent the R-Car gyroadc driver to IIO list +09:13 < Marex> B) Waiting for potential further feedback or acceptance into linux-iio +09:13 < Marex> C) None +09:13 < Marex> EOT +09:13 < geertu> Thank you Marek, and welcome to the team! +09:14 < geertu> Next is Laurent +09:14 < pinchartl> I'm just lurking :-) +09:15 < geertu> Thank you Laurent ;-) +09:15 -!- horms2 [~horms@52D9BC73.cm-11-1c.dynamic.ziggo.nl] has joined #periperi +09:15 < geertu> Next is Jacopo +09:15 < jmondi> sure! +09:15 < jmondi> A) I sent out v3 of PFC + GPIO for RZ SoC +09:15 < jmondi> B) I already received some feedback on how it would be better to unify those drivers +09:16 < jmondi> C) Still not sure if it is worth continue developing those driver and not start a new pin-based one for all SoCs with an RZ-like PFC +09:16 < jmondi> but I guess we're going to talk about this later, according to the agenda +09:16 < jmondi> EOF +09:17 < geertu> Thank you Jacopo +09:17 -!- horms [~horms@52D9BC73.cm-11-1c.dynamic.ziggo.nl] has quit [Ping timeout: 248 seconds] +09:17 < geertu> Next is Geert +09:17 < geertu> A) What have I done since last time - Xmas and NY holidays - Prepared meeting Friday before FOSDEM - Posted first version of ARM64 DMA attributes - Sent first pull requests for v4.11 for clk and pfc - Started MSTP Reset feature +09:17 < geertu> B) What I plan to do till next time - Continue MSTP Reset feature - Update ARM64 DMA attributes according to review comments +09:17 < geertu> C) Problems I have currently - None +09:17 < geertu> EOF +09:18 < geertu> (doh, bullet alignment didn't come out that well) +09:18 -!- horms [~horms@penelope.horms.nl] has joined #periperi +09:18 -!- horms2 [~horms@52D9BC73.cm-11-1c.dynamic.ziggo.nl] has quit [Client Quit] +09:18 < geertu> Topic 2. IOMMU +09:19 < neg> When I read Shimoda-sans email I started to think my effort to enable IPMMU in DT for dmac0 and dmac1 on Gen2 is a bit premature whit all the hardware issues. Do I understand that correctly? Should pause my work here until we know if there is a hardware fix? +09:20 < shimoda> neg: i think so (wait until a hardware fix) for now +09:21 < neg> shimoda: OK thanks I will do so +09:21 < shimoda> however, i don't know hardware is fixed (especially gen2) +09:22 < shimoda> neg: yes, please wait anyway +09:22 < pinchartl> neg: do you mean Gen3 ? +09:22 < horms> neg: (off topic) regarding gpio interupts. I see one in the BSP for EtherAVB. I plan to try this as I believe it is a dependency for gigabit speed which is a task for me at this time. +09:22 < geertu> Perhaps in RZ/G? Sergei's RZ/G1M is ES3.0 +09:23 < geertu> horms: Gigabit speed is already working for me after "ravb: Support 1Gbps on R-Car H3 ES1.1+ and R-Car M3-W" +09:24 < neg> pinchartl: no Gen2, the IPMMU on Gen3 on ES 1.0 I was told did not work for this so I have done most testing on Gen2 +09:24 < horms> geertu: yes, I am aware of that. but the BSP has other bits too. Perhaps it makes it more reliable? +09:24 < shimoda> pinchartl: i hope gen3 fixes this issue. but for now hw team doesn't say so. +09:24 < neg> pinchartl: but with Simons tuninge patchset I started to see odd errors so this is why I ask +09:24 < horms> geertu: in any case I plan to resubmit that patch of yours +09:25 < neg> horms: I have posted patches for Runtime PM with GPIO interrupts so if you test please is those :-) +09:26 < horms> neg: thanks, i will look into them +09:26 < geertu> Speaking about tuning, with renesas-devel-20170116-v4.10-rc4 the M3-W boot takes a long time, due to "sh_mobile_sdhi ee140000.sd: timeout waiting for hardware interrupt (CMD12)" +09:26 < pinchartl> neg: sorry for the confusion. I thought only Gen3 had IPMMU hardware issues +09:26 < geertu> pinchartl: ;-) +09:27 < horms> ok, these mmc problem seem to get worse not better :( +09:27 < geertu> "dmaengine: rcar-dmac: Always disable channel 0" +09:27 < horms> which slot is that? +09:27 < horms> eMMC or a card? +09:27 < horms> in case of the latter which card are you using? +09:27 < geertu> sdhi2 +09:28 < horms> ok, can you give me some details of the card at some point? +09:28 < horms> that may or may not be a factor +09:28 < geertu> eMMC (no cards present). Same (arm64 defconfig based) kernel doesn't show the issue on H3 +09:28 < horms> ok +09:28 < pinchartl> geertu: yes, I know about that one, I meant hardware issues that we have no workaround for at the moment :-) +09:28 < horms> got it +09:29 < geertu> pinchartl: "dmaengine: rcar-dmac: Always disable channel 0" is not upstream +09:30 < geertu> That's it for IPMMU? +09:32 < pinchartl> shimoda: when you say that the hardware team didn't tell about a fix, do you mean that we don't know when it will be fixed, or we don't know whether it will be fixed at all ? +09:32 < shimoda> geertu: about eMMC on salvator-x, we have 2 types (samsung or SMI) +09:34 < shimoda> pinchartl: i meant hw team doens't decide to fix the issue for now. i guess after our customers complint the issue, they will decide it :) +09:35 < pinchartl> shimoda: do they know that the IPMMU is completely unusable ? +09:36 < shimoda> geertu: about eMMC, I'm afraid but I (and board team) don't track which eMMC chip is mounted. would you check it? +09:36 < geertu> shimoda: H3 has BGSD3R 29.1 GiB, M3-W has eMMC 28.8 GiB +09:38 < geertu> Is that sufficient, or should I look at the physical ICs? +09:39 < shimoda> shimoda: I don't think so because they suggest software workaround... +09:40 < shimoda> geertu: thank you, it is enough to me. H3 is samsung, M3 is SMI +09:41 < shimoda> oops. at 17:37:46, this is for pinchartl :) +09:42 < geertu> That's 09:39 here ;-) +09:42 < pinchartl> shimoda: let's try to then make sure that the software workarounds they suggest can't be implemented :-) +09:42 < shimoda> geertu: :) +09:43 < geertu> pinchartl: The workaround is called swiotlb +09:44 < neg> geertu: will not swiotlb kill preformence like there is no tomorrow? +09:45 < shimoda> geertu: yes. almost all drivers are ok, i think. (performance is down though) +09:45 < geertu> neg: It depends. And it's a workaounrd ;) +09:45 < pinchartl> neg: yes it will +09:45 < shimoda> however, sdhi-dmac doesn't have descripter mode, i would like to use IPMMU somehow to improve performance +09:45 < pinchartl> swiotlb is unusable for DU, VSP or VIN +09:46 < geertu> pinchartl: So you need pinned buffers in <4G mem +09:46 < neg> I see, I just noticed swiotlb so have been trying to read up +09:49 < geertu> Time to move on. +09:49 < geertu> Topic 3. PFC/GPIO entanglement on RZ/A1H +09:49 < jmondi> yup... +09:49 < jmondi> so I have prepared a sum-up of the discussions on mailing lists: https://nopaste.me/view/raw/ee7a1180 +09:50 < jmondi> I guess the final question, even before deciding if PFC and GPIO should be merged in a single driver is: do we want to continue pushing this group-based implementation for PFC? +09:51 < pinchartl> jmondi: I wouldn't for RZ/A +09:51 < pinchartl> we have to for R-Car, as the hardware has the concept of groups +09:51 < jmondi> I have received many feedbacks (from Chris and Laurent mainly) on how it would be better to start with a new pin-based pinctrl implementation... Of course this has to be planned, so I would like to discuss this with you all... +09:52 < jmondi> pinchartl: sorry, go on please... +09:52 < pinchartl> I'm done :-) +09:53 < geertu> I have two comments +09:53 < geertu> 1) For R-Car, we have to keep on using groups, as Laurent says +09:54 < geertu> 2) I believe RZ/A is low-priority work for us. So going for the full "rz-pfc/ driver infrastructure" may be going to far, for now. +09:54 < geertu> It would be good to have a simple RZ/A driver upstream, though. +09:55 < geertu> If more users show it, that simple driver can be turned into a "rz-pfc/ driver infrastructure" +09:55 < jmondi> geertu: 1) I never wanted to touch the existing code-base for r-car devices :) +09:55 < geertu> (but it needs a different name than "rz", due to RZ/A vs RZ/G vs RZ/T ;-) +09:55 < horms> rza seems useful from my pov +09:56 < geertu> About memory, RZ/A SoCs are available with 3 or 9 MiB of builtin SRAM, and that may be all on some boards. +09:57 < geertu> Cfr. build you own Cortex A9 board with an SoC in QFP package and 5 external components ;-) +09:57 < jmondi> geertu: according to Chris yes, that's why a run-time creation of groups and functions, as pinctrl-single is doing, may be problematic +09:58 < pinchartl> jmondi: do we have to create all groups and functions at init time ? could we create them on-demand, just for the ones referenced in the device tree ? +09:59 < geertu> jmondi: I haven't looked at the RZ/A PFC driver in the BSP yet... +09:59 < jmondi> pinchartl: that's what happens... the (now moved to core) functions to parse the dts and create groups and functions creates groups only for pins configured in the device tree +09:59 < pinchartl> ok +10:00 < pinchartl> how much memory is that ? +10:00 < pinchartl> compared to the memory allocated by the sh-pfc driver ? +10:00 < jmondi> geertu: there are many of them. Chris has a 3.14 one which does not use device tree yet. Some customer ported it to use DTS and the result is the ABI reported in the file I shared +10:01 < geertu> jmondi: OK +10:01 < jmondi> pinchartl: I guess problem here is that it is run-time memory, compared to huge tables that increases the kernel image size +10:01 < geertu> jmondi: About "tweak pinctrl-single to remove hw specificities: not sure what pinctrl-single maintainer think". Usually maintainers are happy to see that happen +10:02 < geertu> jmondi: Well, the run-time tables will be smaller. The static cables can't be freed anyway. +10:02 < jmondi> geertu: that may be an attempt that ends up in nothing though... Before even trying wouldn't it be better to ask Tony/Linus if this is acceptable? +10:04 < pinchartl> jmondi: and I assume the memory-constrained RZ/A use cases use XIP +10:04 < pinchartl> but sh-pfc also allocates memory at runtime +10:04 < pinchartl> it would be useful to check how much +10:04 < pinchartl> I don't think we can reuse the pinctrl-single driver +10:05 < pinchartl> as it is based on the assumption that one pin will be controlled by a single register +10:05 < pinchartl> we can, however, implement a driver that uses a similar concept +10:06 < jmondi> pinchartl: that's why I thought about having a platform-specific part to hook into pinctrl-single: something like "give mode and configuration and I take care of setting register opportunely for my platform" +10:06 < jmondi> but I understand there's a lot of overhead there +10:07 < pinchartl> many options are possible +10:07 < pinchartl> I'd start with a custom driver, to evaluate the memory impact +10:07 < pinchartl> if it's acceptable, then we could try to reuse code from pinctrl-single +10:08 < pinchartl> if it's not, there's no point :-) +10:08 < jmondi> and I must say I would prefer a smaller driver, with maybe some generated tables at least for validation (ie. not all ports support all 8 modes) +10:09 < jmondi> pinchartl: would that custom driver be a (PFC + GPIO) driver in you opinion, right? +10:09 < pinchartl> I think it should be, given how the hardware is architectured +10:10 < jmondi> pinchartl: the interleaved registers thing is a pain :( +10:11 < pinchartl> only if you want one DT node per bank +10:11 < pinchartl> with a single DT node, it's no big deal +10:12 < jmondi> pinchartl: right.. +10:12 < geertu> A simple combined PFC and GPIO driver makes sense +10:14 < jmondi> geertu: not using sh-pfc/, right? +10:14 < geertu> jmondi: Yep +10:14 < geertu> drivers/pinctrl/renesas-rza1.c +10:15 < jmondi> geertu: ok, let me report these feedbacks to Magnus and see how/when I could work on this... +10:16 < geertu> OK. Time to move on? +10:16 < jmondi> also, I am doing this on a remote board, which is a bit painful... are there other boards with RZ/A SoC, as I understood genmai is available in Japan only +10:17 < jmondi> yeah, sorry... go on, I'll sort this out with Magnus +10:17 < geertu> GR-PEACH +10:18 < geertu> It has the internal 10 MiB only though, unlike Genmai +10:18 < geertu> DigiKey says 117 EUR +10:19 < geertu> (and 409 for the LCD panel shield :-( +10:19 < geertu> I believe Wolfram has a Genmai, too +10:19 < jmondi> geertu: thanks! let's see if I can get one... +10:20 < jmondi> without the LCD panel :) +10:20 < geertu> Doh... +10:21 < geertu> Next meeting will be in real life in Brussels, the Friday before FOSDEM +10:22 < geertu> If you haven't already done so, please confirm your (un)attendence by the morning of Wednesday, January 18th. +10:23 < jmondi> geertu: where should we confirm that? Is there a form or a "I'll be there" is enough? +10:24 < geertu> jmondi: Just let me know. The older timers are already on our mailing list. +10:24 < geertu> s/older/old/ +10:24 < geertu> jmondi, marex: I'll talk to you after the meeting, OK? +10:24 < jmondi> geertu: sure! +10:25 < Marex> yes +10:25 < geertu> So that was the final topic, unless someone has anotheer topic to discuss? +10:25 < horms> geertu: shall we add any new faces to the ML? +10:25 < Marex> geertu: just to confirm, I'll be at fosdem +10:30 < morimoto> ... finished ... ? +10:31 < geertu> Yes, finished :-) +10:31 < morimoto> OK, thanks +10:31 < geertu> Thanks for joining, goodbye! diff --git a/wiki/Chat_log/20170201-mm-chatlog b/wiki/Chat_log/20170201-mm-chatlog new file mode 100644 index 0000000..55ccf83 --- /dev/null +++ b/wiki/Chat_log/20170201-mm-chatlog @@ -0,0 +1,309 @@ +Multimedia-chat-meeting-2017-02-01 + +09:07 < pinchartl> topics for today +09:07 < pinchartl> - status update +09:07 < geertu> pinchartl: I think Magnus is in a train (with WiFi ;-) +09:07 < pinchartl> - ELC meeting +09:07 < pinchartl> - VIN plans +09:07 < pinchartl> anything else ? +09:07 < neg> not from me +09:08 < pinchartl> (there's also "breakfast at le pain quotidien in brussels" but I think that's just for me today :-)) +09:08 < kbingham> pinchartl: We'll add that to tomorrows agenda +09:08 < kbingham> :D +09:09 < pinchartl> :-) +09:09 < pinchartl> Topic 1. Status check for the multimedia tasks +09:09 < pinchartl> Kieran, as you're time constrained, you can start +09:09 < kbingham> Things I've done: +09:09 < kbingham> I've been working on the scaler partition algorithm, and spent some time better understanding the scaler algorithms. I've also worked through the 'pseudo code' from Renesas, and made this compile so I could better understand each of it's actions. +09:09 < kbingham> From this I've added phase calculation into the UDS entity, and I'm trying to rework the algorithm so that each entity "controls it's own fate" and performs it's part of the algorithm. (WPF determines output windows, UDS determines scaling factors, RPF determines source chroma recovery). To achieve needs per partition cropping on each entity - something to talk about F2F later today/tomorrow :D +09:10 < kbingham> Next: FOSDEM, and I'm hoping to get a last minute snowboarding holiday in the school half-term with Keri (13-17th), and more work on PA, and VSP-tests. +09:10 < kbingham> Blockers - only that I want to go through partition algorithm design with Laurent, which is conveniently possible in the next couple of days. +09:10 < kbingham> (pre-written due to time constraints :D ) +09:11 < kbingham> EOT +09:11 -!- morimoto [~user@relprex1.renesas.com] has joined #periperi +09:11 < pinchartl> thank you +09:11 < pinchartl> hello Morimoto-san +09:11 < morimoto> Hi +09:11 < pinchartl> we have just started with Kieran's update +09:11 < morimoto> Oops ? already started ?? +09:12 < kbingham> morimoto: my fault- I have a plane to catch :D +09:12 < pinchartl> has Japan moved its time zone by 15 minutes without any notice ? :-) +09:13 < morimoto> I'm booking today's meeting started from 17:30, now Japan is 17:10 +09:13 < pinchartl> I think I've sent the invitation starting from 17:00 +09:13 < pinchartl> but no worries, you're here :-) +09:13 < pinchartl> I'll go next to give you a bit of time to prepare +09:13 < morimoto> Grr, sorry about that +09:13 < pinchartl> since last meeting +09:14 < pinchartl> I've continued advancing the HDMI output driver towards merging +09:14 < pinchartl> there's few blockers left +09:14 < pinchartl> Neil Armstrong from BayLibre has submitted a patch series to prepare the dw-hdmi driver to be used in Amlogic SoCs. Discussions on how to integrate both patch series are complete. +09:14 < pinchartl> but it means a bit more work for me as they need to decouple PHy handling completely +09:14 < pinchartl> (because they use an external PHY) +09:15 < pinchartl> I mean a vendor PHY +09:15 < pinchartl> I've also had a meeting in Oslo with Hans Verkuil and Sakari Ailus about V4L2 and media controller race conditions +09:16 < pinchartl> with a whole day preparation meeting in Helsinki with Sakari the day before +09:16 < pinchartl> the meetings went well, we agreed on the way forward, and Sakari has posted a summary to the linux-media mailing list +09:16 < pinchartl> (http://www.spinics.net/lists/linux-media/msg110310.html) +09:16 < pinchartl> the next step is to convince Mauro +09:16 < pinchartl> it looks pretty good so far +09:17 < pinchartl> he has pushed back a bit oon a few points +09:17 < pinchartl> but nothing too bad +09:17 < pinchartl> and Hans is on our side +09:17 < pinchartl> and finally I had holidays last week +09:17 < morimoto> Enjoyed sky ? +09:17 < pinchartl> very much :-) +09:18 < morimoto> good :) +09:18 < pinchartl> oh, I also had a long discussion about how to move forward with the V4L2 metadata API, needed for histogram support in the VSP driver +09:18 < pinchartl> for the next two weeks +09:18 < pinchartl> - FOSDEM +09:18 < pinchartl> - ELC preparation +09:19 < pinchartl> - Gen3 HDMI output +09:19 < pinchartl> - patch review +09:19 < pinchartl> no issue or blocker +09:19 < pinchartl> that's it for me +09:19 < pinchartl> neg: can you go next ? +09:19 < neg> sure +09:19 < neg> A) Posted a few VIN and CSI-2 series (see status mail for list) and partaken in discussions about adding multiple subchannels for VIN/CSI-2 on Gen3 +09:20 < neg> B) Attend FOSDEM and talk about VIN issues with Laurent and monitor feed back to patches posted in A as one of the blocks work for IO group +09:20 < neg> C) Wishihg to get feedback on how to speed up VIN/CSI-2 patch acceptence rate :-) +09:20 < neg> EOT +09:21 < pinchartl> morimoto: VIN is a topic of this meeting, we'll get to it right after you +09:21 < pinchartl> neg: thank you +09:21 < morimoto> pinchartl: thanks +09:22 < pinchartl> morimoto: your turn +09:22 < morimoto> A. Since last time +09:22 < morimoto> I talked with Rob (= OF-graph maintainer) and ML people about ALSA SoC OF-graph DT bindings, and almost OK I believe. +09:22 < morimoto> I posted OF-graph ALSA SoC support patch-set this week. +09:22 < morimoto> I noticed we can solve HDMI sound port detection issue of OF-graph if we have new ALSA SoC function (before I produced "type=sound" property for it. Laurent indicated media-controller for it). I implemented it, and it works. +09:22 < morimoto> I got few BSP team request for you guys ;) +09:22 < morimoto> B. Until next time +09:23 < morimoto> I will post HDMI sound patch-set if OF-graph patch-set was accepted. +09:23 < morimoto> And paper work for MAX Camera +09:23 < morimoto> C. Blockers +09:23 < morimoto> There is no response from Rob +09:23 < morimoto> CSI2 camera export needs Happy lovely paper work +09:23 < morimoto> --EOF-- +09:23 < morimoto> About MAX Camera, BSP team want to have this support until 3/E, maybe this is not realistic ? +09:23 < morimoto> Export paper work takes more time, and no develop time for you guys :( +09:23 < morimoto> And this MAX Camera will be rental, we need to back it to BSP team. +09:23 < morimoto> So, my plan is we will buy it. +09:24 < morimoto> But, it seems buying will takes time +09:24 < morimoto> some plan we have +09:24 < morimoto> 1) +09:24 < morimoto> send rental camera to you guys +09:25 < morimoto> and Renesas buy it in parallel +09:25 < morimoto> And someday, we will switch +09:25 < morimoto> or +09:25 < morimoto> 2) +09:25 < morimoto> I will ask you guys to buy it from Europa +09:25 < pinchartl> thank youcan it be bought easily ? do you know what the lead time is ? +09:25 < morimoto> but, 2) is not good for time limit +09:26 < morimoto> Acorrding to HW guys, if you buy it today, you can get it 3/E +09:26 < pinchartl> :-) +09:26 < morimoto> Now we are considering about it +09:26 < morimoto> Ahh +09:27 < pinchartl> I'm fine with that, but I suppose the BSP team iisn't :-) +09:27 < morimoto> about MAX chip datasheet, it is under NDA +09:27 < morimoto> We are solving export paper work +09:28 < pinchartl> can we get the MAX9286 datasheet under NDA ? +09:28 < morimoto> pinchartl: if we can avoid BSP team's time limit, can I ask you buy it from Europe ? +09:28 < morimoto> We will get more detail. URL, cost, serial number etc... +09:29 < pinchartl> morimoto: sure, assuming that Maxim will sell it to us (as the documentation is under NDA there could also be restrictions on buying the hardware) +09:29 < morimoto> pinchartl: about MAX datasheet, yes, we can get it nunder NDA. we need more detail infromation from HW guys. +09:30 < morimoto> It needs additional board + camera. camera is very generic. no problem +09:30 < pinchartl> if you tell us what to buy we can certainly buy it, no problem with that +09:31 < morimoto> but, board is R-Car special. We need special interface guy (?) +09:31 < morimoto> pinchartl: yes, thanks +09:31 < morimoto> We are now planing how to solve this issue. +09:31 < morimoto> thats it from me +09:32 < pinchartl> the interface board is a custom PCB from Renesas, right ? +09:32 < morimoto> maybe, I don't know detail yet +09:33 < pinchartl> I would assume so +09:33 < pinchartl> we will need that PCB +09:33 < pinchartl> when do you expect to have information on what is needed ? +09:34 < morimoto> Now, HW guys is collecting information +09:34 < morimoto> BSP team -> HW guys -> ??? +09:34 < morimoto> I don't know how long +09:35 < pinchartl> ok +09:35 < pinchartl> we *could* try to get different hardware to work on +09:35 < pinchartl> but I think it will take longer +09:35 < pinchartl> as we would likely have to develop an interface PCB anyway +09:35 < morimoto> I guess is this related to 2nd Q1 SoW ? +09:36 < neg> If there is a upstream driver for a CSI-2 transmitter that supports multiple channels that might still be less time to develop a interface PCB +09:36 < morimoto> If so, when do you need it for Q1 2nd SoW ? +09:37 < morimoto> I guess, we can collect many information this and next week (?) +09:37 < morimoto> And start export paper work +1 or +2 weeks +09:38 < morimoto> And ship it to Europe, it take 1 week ? +09:38 < morimoto> this is *BEST* case +09:38 < pinchartl> this brings us to the next topic, VIN/CSI-2 planning :-) +09:38 < pinchartl> I don't think 3/E is a reasonable target +09:38 < morimoto> Hmm.. yes +09:38 < pinchartl> as Niklas explained in his last e-mail, there is lots of work needed +09:38 < morimoto> Yes, yes, I know +09:38 < pinchartl> we could possibly produce a prototype by 3/E +09:38 < pinchartl> *if* we can assign enough developers on this +09:39 < morimoto> without HW ? +09:39 < pinchartl> Niklas (unless that has changed) works 50% for Renesas +09:39 < pinchartl> (25% for the base contract and 25% for the additional tasks) +09:39 < pinchartl> that's now enough time until 3/E to implement a solution +09:39 < pinchartl> no, with hardware +09:39 < morimoto> OK +09:39 < pinchartl> hardware isn't needed at the very beginning +09:39 < pinchartl> but we'll need it for testing +09:40 < morimoto> and remote machine is not enough ? +09:40 < pinchartl> it depends on the hardware, whether it can be controlled remotely +09:40 < pinchartl> I don't expect things to work out of the box +09:40 < pinchartl> remote access has a high latency +09:40 < morimoto> OK +09:41 < pinchartl> 5 minutes to boot a new kernel +09:41 < morimoto> Ahh, not good +09:41 < pinchartl> as we'll need lots of tests to debug the code, that would slow things up +09:41 < morimoto> I will do my best for you guy ;) +09:41 < pinchartl> I mean slow things down :-) +09:41 < pinchartl> thank you +09:41 < pinchartl> another thing +09:41 < neg> thank you :-) +09:42 < pinchartl> as I said, producing a prototype for 3/E requires lots of work +09:42 < pinchartl> Niklas won't have enough time alone +09:42 < pinchartl> so we'll need to work together +09:42 < pinchartl> Kieran and I can help +09:42 < pinchartl> but then we won't have enough time to solve the VSP/DU flicker issues +09:42 < morimoto> I think BSP team's planning is already broken. So I can tell it to them +09:43 < pinchartl> they have to pick the priority +09:43 < pinchartl> the second half of Q2 is one month +09:43 < pinchartl> 20 days +09:43 < pinchartl> as Niklas is assigned to Renesas at 50%, that's 10 days for him +09:43 < pinchartl> 5 days of base task, 5 days of additional task +09:44 < pinchartl> it makes no sense to split that between VIN and something else +09:44 < pinchartl> so if we need to focus on VIN, I'd like Niklas to spend all his time on VIN in the second batch of Q1, and in Q2 +09:44 < pinchartl> otherwise we won't move forward if we split this in 5 days tasks here and there +09:45 < pinchartl> another thing +09:45 < pinchartl> if we assign enough developers to this 3/E might be possible for a prototype +09:45 < pinchartl> *but* +09:45 < pinchartl> it really means 3/E +09:45 < pinchartl> we can't do it for 3/M +09:45 < pinchartl> which is when Jinzai expects reports +09:46 < pinchartl> in that case I'll want to send reports at 3/E +09:46 < pinchartl> as spending time on reports for 3/M while we rush to finish the code for 3/E makes absolutely no sense +09:47 < morimoto> I guess we can avoid 3/E limitation for VIN for now. And I think I need to talk to my Boss about Niklas time ? +09:47 < pinchartl> and to Niklas and Magnus too I assume :-) +09:47 < morimoto> Ahh yes. ELC is good time for it ? +09:47 < morimoto> Oops, too late ? +09:47 < pinchartl> it depends on the priorities :-) +09:48 < pinchartl> if the BSP team thinks this is the highest priority and we need to start working on it immediately, then ELC is late +09:48 < pinchartl> if we can have a delay, it's fine +09:49 < pinchartl> my point is that, if Niklas has 15 days of base task and and 15 days or additional tasks per quarter, it makes no sense to split that between multiple tasks for multiple groups if VIN is the focus +09:49 < pinchartl> otherwise the task scheduler overhead will be too high :-) +09:49 < pinchartl> neg: please feel free to chime in as we're talking about you :-) +09:49 < neg> :-) +09:49 < morimoto> BSP team 3/E request today is Fence, DU init order fixup, suspend/resume bug fix +09:50 < morimoto> VIN was requested, but it is too late +09:50 < pinchartl> given the amount of work for VIN, splitting the work in 5 or 10 days tasks spread over 6 months doesn't make sense to me. it should be grouped +09:50 < pinchartl> morimoto: I think that's a more reasonable plan +09:50 < neg> I agree with what you are saygin, I can't do this by my self we need to coalaborate and it make sens for me to focus mor then 1/3 of my time on this as I do now for multimedia tasks +09:51 < morimoto> OK, I hope we can talk this F2F on ELC. I will correct information etc for it +09:52 < morimoto> BSP plan, budgetcl +09:52 < neg> pinchartl: do you know if Sakari will be at FOSDEM or ELC? +09:52 < pinchartl> sure, we'll certainly talk about it at ELC +09:52 < pinchartl> neg: he will unfortunately not attend either :-( +09:53 < pinchartl> neg: how about spending a day or two in Helsinki ? +09:53 < neg> Hum maybe it would make sens for me to fly to Helsinki and meet both of you and talk F2F about his current work on subchannels and if we can colaborate forward? +09:53 < pinchartl> :-) +09:54 < pinchartl> morimoto: do you think we could get budget for Niklas to spend two days in Helsinki ? Stockholm-Helsinki is a very short flight, it will be cheap +09:54 < morimoto> for FOSDEM ? or meeting ? +09:54 < pinchartl> for meeting with me and Sakari Ialus in Helsinki +09:54 < pinchartl> Sakari works for Intel +09:55 < morimoto> OK, please wait +09:55 < pinchartl> and has started working on a V4L2 API for multiple virtual channels +09:55 < pinchartl> if we can spend one or two days with him face to face it would help a lot +09:55 < pinchartl> but he won't attend the FOSDEM or ELC +09:55 < pinchartl> so Niklas could fly to Helsinki, that's very close +09:56 < pinchartl> and Sakari can likely host a meeting at the Intel office there +09:56 < morimoto> pinchartl: neg: we can get OK from our boss v(^-^)v +09:56 < pinchartl> we're talking about a few hundred euros to save weeks of e-mail discussions, I think it's worth it :-) +09:57 < pinchartl> that will be after the FOSDEM anyway, so we have a bit of time +09:58 < morimoto> FOSDEM -> Helsinki -> ELC. business-man !! +09:58 < neg> It's a hard life :-) +09:59 < pinchartl> neg: seriously, spending all your time in planes *is* a hard life +09:59 < pinchartl> I think that's it for the VIN discussion for today, we'll talk more about it face to face in Brussels +09:59 < pinchartl> and this brings us to the next topic, FOSDEM preparation +09:59 < pinchartl> neg: you will arrive on Thursday evening, right ? +09:59 < neg> yes +10:00 < pinchartl> I wonder when we should schedule time for face to face dicussions +10:00 < pinchartl> Friday will be busy with core and I/O +10:00 < pinchartl> maybe Thursday evening ? +10:00 < neg> arrive 17:20 and hope I can make it to my hotell by 18:30 I think it should be doable +10:01 < pinchartl> we can either have a late dinner, or talk during/after dinner +10:01 < neg> so any time between that and sunday evening works for me except ofc for periperi meetings during Friday +10:02 < neg> Thursday evening works, maybe it's good to have it before/after dinner so I can make notes +10:02 < pinchartl> how about having dinner at 19:00 and discuss after that ? +10:02 < pinchartl> we can talk about planning and other less technical topics during dinner +10:02 < neg> yes sounds like a good plan +10:02 < pinchartl> and move the technical parts after dinner +10:03 < pinchartl> OK, I'll book a table for 19:00 then +10:03 < pinchartl> for 5 of us +10:03 < neg> nice, at what location? +10:04 < pinchartl> I don't know yet, I'll sort it out today +10:04 < neg> ahh nice, thanks for arraigning it +10:05 < pinchartl> you're welcome +10:05 < pinchartl> next topics, ELC +10:05 < pinchartl> there will be no V4L2 meeting at ELC +10:06 < pinchartl> so Monday and Friday are free +10:06 < pinchartl> I this propose having a multimedia meeting on Monday +10:06 < morimoto> Nice for me +10:06 < neg> works for me +10:07 < pinchartl> I assume it will owrk for Magnus too +10:07 < morimoto> I and Magnus will arrive there at 17th +10:07 < pinchartl> Ulrich and Kieran don't plan to attend ELC as far as I know +10:07 < pinchartl> but it could be possible to change their minds +10:07 < pinchartl> (assuming we can get budget) +10:08 < morimoto> about budget, maybe no problem. +10:10 < pinchartl> :-) +10:10 < pinchartl> last topic then, next meeting +10:10 < pinchartl> I propose two weeks from now +10:10 < pinchartl> February the 15th +10:10 < pinchartl> same time as today (that's 17:00 JST ;-)) +10:10 < morimoto> Oops, Feb 15th doesn't work for me +10:11 < pinchartl> how about the 14th or the 16th ? +10:11 < morimoto> both 14th, 16th are OK +10:11 < neg> both works for me +10:11 < pinchartl> when is the next core group chat planned ? +10:12 < geertu> pinchartl: Feb 14th? +10:12 < geertu> Feb21 is ELC +10:13 < geertu> Or we can skip directly to Feb 28 :-) +10:13 < morimoto> 28 is OK for me :) +10:13 < pinchartl> it doesn't make much sense to have a multimedia meeting on the 16th and another one at ELC on the 20th +10:13 < pinchartl> should we skip to the 20th directly ? +10:14 < neg> works for me, how do that allign for kbingham and uli time zone wise? +10:14 < morimoto> Do you mean skip 20th meeting on America ? +10:14 < pinchartl> morimoto: yes +10:15 < morimoto> Oops, it is not good for me. I need to report about it :( +10:15 < geertu> "skip to" != "skip" +10:15 < pinchartl> morimoto: no sorry +10:15 < pinchartl> I meant skipping the meeting on the 16th +10:15 < geertu> neg: same time difference as JP vs EU +10:15 < morimoto> Ah, next meeting *is* 20th ? +10:15 < pinchartl> skipping to the 20th means skipping the 16th and going directly to the 20th +10:16 < pinchartl> there will be one face to face meeting on the 20th +10:16 < morimoto> OK, thanks. it is very good for me :) +10:16 < pinchartl> so I propose skipping the one on the 16th, it makes little sense to have two meetings just a few days apart +10:16 < pinchartl> let's do that then +10:17 < pinchartl> morimoto: you will arrive on the 17th, right ? +10:17 < morimoto> Yes +10:17 < pinchartl> neg: how about you ? +10:17 < pinchartl> morimoto: and when will you leave ? +10:17 < neg> 19th +10:17 < morimoto> 24th +10:17 < morimoto> with Magnus +10:18 < pinchartl> neg: same question, when will you leave ? +10:18 < neg> 25th :-) +10:18 < pinchartl> morimoto: does Magnus arrive on the 17th too ? +10:18 < morimoto> Yes. same plane +10:18 < pinchartl> :-) +10:19 < pinchartl> I think that's it for today +10:19 < pinchartl> I propose adjourning the meeting +10:19 < pinchartl> does anyone second ? +10:19 < neg> seconded +10:19 < morimoto> 2nd ! +10:20 < pinchartl> meeting adjourned +10:20 < pinchartl> thank you all for attending diff --git a/wiki/Chat_log/20170228-core-chatlog b/wiki/Chat_log/20170228-core-chatlog new file mode 100644 index 0000000..95e79a3 --- /dev/null +++ b/wiki/Chat_log/20170228-core-chatlog @@ -0,0 +1,201 @@ +Core-chat-meeting-2017-02-28 + +09:07 < geertu> Welcome to today's Core Group Meeting! +09:07 < geertu> Agenda: +09:07 < geertu> 1. Status updates +09:07 < geertu> Let's give the new format a try +09:07 < geertu> A) What have I done since last time +09:07 < geertu> B) What I plan to do till next time +09:07 < geertu> C) Problems I have currently +09:07 < geertu> D) Posted/Accepted bugfix patches +09:08 < geertu> First is Shimoda-san +09:08 < shimoda> yes +09:08 < shimoda> A) +09:08 < shimoda> - prepare IPMMU workaround patch +09:08 < shimoda> - but I found the IPMMU driver on latest iommu repo could not work correctly +09:08 < shimoda> (even if the workaround patch is not applied). +09:08 < shimoda> B) +09:08 < shimoda> - I will submit a workaround patch after the IPMMU issue is resolved by Magnus-san +09:08 < shimoda> C) +09:08 < shimoda> - How to handle the following task? BSP team would like to add such a code +09:08 < shimoda> because they have an issue that is related to this feature. +09:08 < shimoda> https://patchwork.kernel.org/patch/9557691/ +09:09 < shimoda> D) fix sh-sci patch about race condition between serial console and dma +09:09 < shimoda> fix usb1.1 suspend resume issue +09:09 < geertu> BTW, thanks for the patch, I could reproduce the issue on Koelsch +09:09 < shimoda> -- EOT -- +09:10 < geertu> Thank you, Shimoda-san +09:10 < geertu> Next is Niklas +09:11 < neg> A) Nothing - No Core task +09:11 < neg> B) Nothing - No Core task +09:11 < neg> C) Figure out how/when to handle core task 'Renesas R-Car SYS-DMAC Slow Mode and Priority Handling Prototyp' +09:11 < neg> D) None +09:12 < neg> eot +09:13 < geertu> neg: If you find time for C, perhaps it's more worthwhile to look into Shimoda-san's C? +09:14 < neg> geertu: sure if that is higer prio I be happy to look in to that when I get time +09:14 < geertu> ok, thx... +09:14 < geertu> Thank you Niklas +09:14 < geertu> Next is Morimoto-san +09:14 < morimoto> OK +09:15 < morimoto> A = B = C (= D) = NULL +09:15 < morimoto> EOT +09:15 < geertu> Thank you Morimoto-san +09:15 < geertu> Next is Marek +09:16 < Marex> A = B = C = D = NULL +09:17 < geertu> Thank you Marek +09:17 < geertu> Next is Magnus +09:17 < Marex> there was one external bugfix for GyroADC driver +09:17 < dammsan> [5~I'm also mainly NULL +09:17 < Marex> oops +09:17 < dammsan> however for C I wonder how to proceed with the r8a7796 DT binding +09:18 < dammsan> for IPMMU +09:18 < dammsan> regarding B I hope to have an IPMMU patch stack refresh ready tomorrow +09:18 < dammsan> EOF +09:19 < geertu> dammsan: As Rob reviewed the r8a7795 upon Laurent's request, we should ping Jörg Rödel +09:20 < geertu> s/sr8a7795/accepted r8a7795 binding/ +09:21 < dammsan> ok will do +09:21 < geertu> Thank you Magnus +09:21 < dammsan> thanks +09:21 < geertu> Next is Laurent +09:22 < geertu> pinchartl is away: Gone +09:22 < geertu> Next is Jacopo +09:23 < jmondi> here I am +09:23 < jmondi> A) - Posted RZ/A1 PFC and GPIO controller patches +09:23 < jmondi> B) - Resend after reviews and have that driver merged +09:23 < jmondi> C) = D) = None +09:23 < jmondi> --- eof --- +09:24 < jmondi> Chris wrote me offline he's going to test the pincontroller patch for RZ/A1 in these days +09:24 < jmondi> I hope to have his tested-by before sending v2 +09:25 < jmondi> that's all! +09:25 < geertu> Thank you Jacopo +09:25 < geertu> Next is Geert +09:26 < geertu> A) +09:26 < geertu> - Organized PERIPERI BE +09:26 < geertu> - Additional tasks for 2017Q1 phase 2 +09:26 < geertu> - Submitted MSTP Reset feature +09:26 < geertu> - Core code upstream (for v4.11) +09:26 < geertu> - Preliminary DT updates +09:26 < geertu> - Sent second pull requests for v4.11 for clk and pfc +09:26 < geertu> - Updated ARM64 DMA attributes according to review comments +09:26 < geertu> - DMA_ATTR_SKIP_CPU_SYNC is in +09:26 < geertu> - I expect DMA_ATTR_FORCE_CONTIGUOUS to go in soon (unless the +09:26 < geertu> ARM64 maintainers want an upstream user first) +09:26 < geertu> - Related IOMMU and DMAC fixes +09:26 < geertu> - Suspend-to-Idle RFC patches: +09:26 < geertu> - Everything NAKed +09:26 < geertu> - Short story: use "echo s2idle > /sys/power/mem_sleep" if you +09:26 < geertu> want to use other wake-up sources +09:26 < geertu> - Sent patches to enable more CPU cores on R-Car H3 and M3-W +09:26 < geertu> - Resumed R-Car H3 ES2.0 work +09:26 < geertu> B) +09:26 < geertu> - Suspend-to-Idle RFC: +09:26 < geertu> - Will post "long story" summary to periperi +09:26 < geertu> - MSTP Reset feature: +09:26 < geertu> - Submit DT updates after v4.11-rc1 +09:26 < geertu> - Complete R-Car H3 ES2.0 work +09:26 < geertu> - Update patches to enable more CPU cores on R-Car H3 and M3-W +09:27 < geertu> C) +09:27 < geertu> - Had to drop IPMMU support from last renesas-drivers release +09:27 < geertu> D) +09:27 < geertu> clk: renesas: cpg-mssr: Migrate to CLK_IS_CRITICAL (v4.11) +09:27 < geertu> arm64: Use __pa_symbol for empty_zero_page (v4.11) +09:27 < geertu> drivers: firmware: psci: Use __pa_symbol for cpu_resume (v4.11) +09:27 < geertu> net: phy: leds: Clear phy_num_led_triggers on failure (v4.10) +09:27 < geertu> net: phy: leds: Fix truncated LED trigger names (v4.10) +09:27 < geertu> arm64: dts: r8a7795: Mark EthernetAVB device node (v4.11) +09:27 < geertu> arm64: dts: r8a7796: Mark EthernetAVB device node (v4.11) +09:27 < geertu> ARM: dts: r8a7743: Fix SCIFB0 dmas indentation (v4.12) +09:27 < geertu> ARM: dts: r8a7745: Fix SCIFB0 dmas indentation (v4.12) +09:27 < geertu> PM / sleep: Fix test_suspend after sleep state rework (v4.11) +09:27 < geertu> arm64: kernel: Update kerneldoc for cpu_suspend() rename +09:27 < geertu> EOT +09:28 < neg> fwiw, I think your 'Suspend-to-Idle RFC patches' where nice and sorry about it beeing NAKed +09:28 < dammsan> yeah same here +09:28 < dammsan> ARM ppl are not being very forward thinking there IMO +09:29 < dammsan> but hey +09:29 < geertu> Yeah, it was a bit disappointing... +09:29 < dammsan> yeah.. +09:30 < geertu> At least people can keep on using "echo mem > /sys/power/state", if they did "echo s2idle > /sys/power/mem_sleep" before +09:30 < geertu> Which also means that we can start working on Wake-on-LAN for RAVB ;-) +09:31 < neg> :-) +09:31 < geertu> There's also some work to be done in our PSCI implementation. SYSTEM_OFF should save much more power +09:32 < dammsan> Prediction: Constant need for improvement +09:33 < geertu> From skimming through the "C" items, we need some resource to care for RCAR-DMAC? +09:34 < dammsan> unless someone else wants to do it +09:34 < dammsan> i can add it to my todo list +09:34 < dammsan> need to cover for simon for some back porting anyway +09:35 < dammsan> nice with something semi-techinical aside from the IPMMU +09:35 < geertu> That would be great! (but please make IPMMU "work" again first ;-) +09:35 < dammsan> yep, that's prio #1 +09:35 < neg> If nothing else starting 20th of march (probobly a bit erlier) I got an intense base contract perido where I can do Core work +09:35 < geertu> That went smooth... Do we have anything else to discuss? +09:36 < jmondi> I also need a task for Core after the RZ pinctrl +09:36 < dammsan> jmondi: did you manage to run Linux on the pink RZ board? +09:36 < jmondi> I need a JTAG programmer first +09:36 < dammsan> buy a flyswatter or similar +09:37 < dammsan> ulrich would know what to get +09:37 < jmondi> and chris suggested me to substitute the flash chip on the board +09:37 < jmondi> whith involves un-soldering/soldering SMD chips +09:37 < Marex> jmondi: or replace the flash chip with an FPGA emulator :) +09:37 < Marex> (did that ... worked) +09:37 < jmondi> Marex: like what? +09:37 < dammsan> jmondi: do you have schematics? +09:38 < jmondi> only the public available ones +09:38 < jmondi> so no +09:38 < geertu> jmondi: FWIW, I have a Flyswatter2 +09:38 < jmondi> :) +09:38 < jmondi> I was looking at some J-Link +09:38 < pinchartl> geertu: /me is back +09:38 < Marex> jmondi: flyswatter2 is great +09:38 < jmondi> mainly for open-ocd compatibility +09:38 < Marex> jmondi: and it works with openocd real well +09:38 < jmondi> that's great then +09:39 < dammsan> geertu: did ulrich exclude himself from core? if not then upstream openocd support would be good +09:39 < geertu> jmondi: This is GR-PEACH, right? I do have schematics +09:39 < jmondi> ah nice! http://tincantools.com/wiki/Flyswatter2 +09:39 < dammsan> geertu: can you share the schematics? +09:39 < jmondi> it's GR-PEACH, yeah +09:40 < jmondi> $ls +09:40 < jmondi> GR-Peach-Schematics.pdf +09:40 < geertu> I've ordered mine from http://www.watterott.com/de/Flyswatter2 (in stock again!) +09:40 < jmondi> so I have them as well, I wonder where I got them from :/ +09:40 < geertu> https://www.core.co.jp/product/m2m/gr-peach/pdf/history/gr-peach_circuit_e.pdf +09:41 < geertu> pinchartl: Any A/B/C/D to contribute to the meeting? +09:41 < dammsan> excellent thanks +09:42 < jmondi> I'm buying that flyswatter right away then ;) +09:43 < pinchartl> geertu: no core task, so no :-) +09:45 < dammsan> pinchartl: did you discuss the PMIC bits with Marex? +09:45 < dammsan> i mean regarding the documentation +09:47 < Marex> dammsan: I saw some rudimentary driver link posted by geertu +09:47 < dammsan> in the same nice way that the versaclk driver is upstream now +09:47 < dammsan> it would be great with a pmic driver upstream +09:47 < pinchartl> dammsan: no, I haven't. if there's a need for documentation I think it can be found in a dark corner somewhere. I'll check that +09:48 < dammsan> thanks +09:48 < Marex> hehe +09:48 < geertu> morimoto: you have the PMIC docs? +09:48 < morimoto> Yes. I have. +09:48 < morimoto> But we can't send it to non-Renesas +09:49 < morimoto> Because of special NDA +09:49 < dammsan> so if we can't do Gen3 PMIC then begin with Gen2 PMIC makes sense? +09:52 -!- geertu [~geert@d54C189FD.access.telenet.be] has joined #periperi +09:52 -!- Topic for #periperi: marzen lock holder = none / managed in-channel rather than in-topic +09:52 -!- Topic set by geertu [] [Thu Oct 1 16:19:22 2015] +09:52 [Users #periperi] +09:52 [ dammsan] [ kbingham ] [ morimoto ] [ pinchartl] +09:52 [ geertu ] [ Marex ] [ mturquette] [ shimoda ] +09:52 [ jmondi ] [ marex-cloud] [ neg ] [ yoshi_ito] +09:52 -!- Irssi: #periperi: Total of 12 nicks [0 ops, 0 halfops, 0 voices, 12 normal] +09:52 -!- Channel #periperi created Wed Jul 8 12:41:24 2015 +09:52 -!- Irssi: Join to #periperi was synced in 9 secs +09:53 < pinchartl> Marex: do you receive private messages on IRC ? +09:55 < geertu> Shimoda-san has another meeting in 4 minutes +09:56 < Marex> pinchartl: I can +09:56 < geertu> For next meeting, I propose \pi-day: Tuesday, March 14, 08:00 GMT / 09:00 CET / 10:00 EET / 17:00 JST +09:57 < neg> 14th works for me +09:57 < shimoda> 14th is ok to me +09:57 < jmondi> fine with me +09:58 < dammsan> same here +09:58 < pinchartl> geertu: I'll be on holidays that week +09:59 < geertu> Let's finish. +09:59 < shimoda> thank you! bye! +09:59 < geertu> Thanks for joining, and have a nice continued day diff --git a/wiki/Chat_log/20170307-io-chatlog b/wiki/Chat_log/20170307-io-chatlog new file mode 100644 index 0000000..59d1389 --- /dev/null +++ b/wiki/Chat_log/20170307-io-chatlog @@ -0,0 +1,194 @@ +--- Log opened Tue Mar 07 08:57:01 2017 +08:57 -!- wsa_ [~wsa@p54B33CD0.dip0.t-ipconnect.de] has joined #periperi-io +08:57 -!- Irssi: #periperi-io: Total of 4 nicks [1 ops, 0 halfops, 0 voices, 3 normal] +08:57 < wsa_> hiya +08:57 -!- Irssi: Join to #periperi-io was synced in 10 secs +08:58 -!- jmondi [~USR123@250.ip-164-132-57.eu] has joined #periperi-io +08:58 -!- horms [~horms@penelope.horms.nl] has joined #periperi-io +08:58 < geertu> Hi +08:59 < jmondi> Hello! +09:02 < wsa_> so, let's start... +09:02 -!- Irssi: #periperi-io: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal] +09:02 < wsa_> glad you guys could make it +09:02 < wsa_> simon, I hope it was not a big problem for you +09:03 <@morimoto> Hi +09:03 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi-io +09:03 < wsa_> i have a time limit and need to leave in around 75 minutes +09:04 < wsa_> I hope we will be done then by far, though +09:04 < wsa_> i have a few topics but would like to ask you guys first if there is something on your mind? +09:04 < neg> :-) +09:06 < neg> bad time to post in wrong window, I have nothing on my mind +09:06 < wsa_> doesn't look like it for now... +09:07 < wsa_> neg: I hope it wasn't the window where your gf asked you what to do this evening ;) +09:07 < neg> if only +09:08 < wsa_> so, are there any news from Ulrich? +09:08 < wsa_> has he been to core meetings? +09:08 < geertu> wsa_: Haven't heard from him for quite a while +09:08 < wsa_> seems I have to ask privately for status updates again +09:09 < wsa_> dammsan: did you have contact with him recently? +09:09 < geertu> Last mailing list post was Feb 8 +09:09 < horms> I was not present at the most recent core meeting and I have been mostly offline for several weeks. However, I do not recall seeing any patches from him for some time. +09:09 < dammsan> we managed to finalise his additional tasks yesterday +09:09 < dammsan> i saw that he responded to jinzai then +09:09 < horms> at least we know he is alive :) +09:10 < dammsan> yeah +09:10 < dammsan> that's good +09:10 < wsa_> add. tasks for Q2 already? +09:10 < dammsan> nope, this was this quarter 3/M due date +09:11 < dammsan> from now on i will submit group leader tasks as final step for each batch =) +09:12 < wsa_> okay, so I will try to get status updates from him personally and ask him to do this on periperi in the future again +09:12 < dammsan> regarding next quarter additional tasks +09:12 < wsa_> yes, this was one topic for today +09:13 < dammsan> i would like to ask all of you to ponder about proposals and discuss with wolfram how to improve various I/O device drivers +09:14 < neg> 1. PM suspend/resume test suite :-) +09:14 * morimoto do Renesas work now +09:14 < neg> 2. WoL for Gen3 +09:15 < wsa_> PM is a bigger topic for most drivers, but the base is not considered stable yet +09:15 < wsa_> or? +09:16 < dammsan> good question +09:17 < dammsan> if we are able to support wakeups from devices somehow, then i think it might be stable enough +09:17 < geertu> Which base is not stable? +09:17 < wsa_> geertu: suspend/resume? +09:18 < geertu> echo s2idle > /sys/power/mem_sleep +09:18 < geertu> and after that you can play at will +09:19 < neg> Never the less, having a group effort for a single repo with a test tool/scripts to test PM the issues could be found and documentet per dirver also work could start on Gen2 +09:20 < geertu> And without the above echo command, you can still test suspend/resume for all drivers, but only with SW23 wake-up +09:20 < geertu> Please upgrade to firmware 2.16 +09:20 < geertu> Gen2 doesn't power down the SoC, so drivers still work if they fail to restore registers +09:21 < dammsan> geertu: i think the e2x board (not upstream unfortunately) supports SoC power down on Gen2 +09:21 < dammsan> so it is a board property +09:22 < wsa_> ok, so with fw 2.16 we can now try out PM in drivers? that would be good news... +09:22 < geertu> dammsan: OK OK, if we don't know about boards, they don't exist ;-) +09:22 < dammsan> =) +09:22 < geertu> wsa_: Even with older firmware, but then you need M3-W +09:23 < geertu> as the older firmware supports suspend/resume on H3 ES1.1+ only +09:23 < wsa_> yeah, still I wanted to try with H3 and M3-W here +09:24 < wsa_> otherwise too much room for unexpected behaviour which I cannot reproduce +09:25 < geertu> Then please upgrade to firmware 2.16 on both boards. +09:25 < wsa_> will do +09:25 < wsa_> that opens a path for quite some tasks, I assume +09:25 < dammsan> geertu: we can have that as requirement in the additional tasks related to PM +09:27 < wsa_> geertu: you mentioned that you want to pick up SPI slave again? Nice +09:27 < geertu> wsa_: yes, I hope to find some time for that (talked to Matt Porter and Mark Brown @ FOSDEM) +09:27 < wsa_> do you have room for an add. task covering that? +09:28 < wsa_> or all busy with core? +09:28 < geertu> wsa_: No space for extra add. task now +09:28 < geertu> Or do you mean Q2? +09:28 < wsa_> Q2 +09:28 < wsa_> Q2B1 +09:28 < geertu> IC +09:29 < wsa_> or Q2B2 if that suits you better... +09:30 < wsa_> horms: are you still interested in the SDHI DMA refactoring task in Q2B1? +09:31 < wsa_> horms: and are you getting better? +09:31 < wsa_> that should have been the first question :) +09:31 < horms> perhaps: as I had to cancel my tasks for the current period I think they should get first dibs on my time in the next period +09:31 < horms> horms: i am improving slowly but surely and expect to be back to full strength next Q +09:32 < horms> As of this week I am well enough to be back at work :) +09:32 < horms> It is "just the flu" but my immune system seems very weak for some reason +09:33 < horms> so it is taking a long time to recover +09:33 < wsa_> I wonder if SDHI refactoring is bad for an immune system... ;) +09:33 < horms> haha; maybe +09:34 < wsa_> the only thing I noticed is a few more grey hairs, though... +09:34 < wsa_> :D +09:34 -!- horms [~horms@penelope.horms.nl] has left #periperi-io ["Leaving"] +09:34 -!- horms [~horms@penelope.horms.nl] has joined #periperi-io +09:34 < wsa_> okay, we need to keep an eye on that: SDHI DMA seems to be important for Q2 +09:35 < horms> ok, i would say its possible if there it is high priority +09:36 < horms> i plan to make a start on my non-tasks for the current period sooner than later as I already know what the tasks are even if they are in a no-paperwork state at this time +09:36 < horms> that should give me a bit more time to play with next Q +09:36 < wsa_> cool +09:37 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi-io +09:37 < wsa_> geertu: this task +09:37 < wsa_> SCIF,v4.10,public,geert,difference in behavior between hardware-assisted flow control and GPIO flow control +09:37 < wsa_> is it fixed with +09:38 < wsa_> e8de8e1c28560795 serial: sh-sci: Fix early deassertion of dedicated RTS +09:38 < wsa_> ? +09:38 < wsa_> hi shimoda-san +09:39 < geertu> wsa_: Yes, but Laurent wanted me to fix the pin initialization at the same time, so the maintainer hasn't picked up that patch, and I need to implement his comment first :-( +09:39 < wsa_> neg: did i get this right. Since Hans asked you to drop some patches of the VIN series, this effectively means that the IP core switcher series is postponed until some heavy restructuring in the V4L2 core? +09:39 < wsa_> geertu: +09:39 < wsa_> geertu: i see +09:40 < shimoda> hi wolfram-san! +09:40 < wsa_> geertu: so, this is v4.12 now? +09:40 < geertu> probably +09:41 < wsa_> ok +09:41 < dammsan> wsa_: will you have time for IP core switch development for I2C? +09:41 < neg> wsa_: yes and no, the over all problem needs V4L2 work for the problem we have in VIN i have a new patch I hope he will accept and plan to post as part of my current multimedia additonal task +09:41 < dammsan> wsa_: in the next quarter regarding additional tasks i mean +09:42 < wsa_> dammsan: there is a dependency on parts of the VIN series, so unclear for now +09:43 < dammsan> wsa_: ok thanks +09:44 < wsa_> it wouldn't like to schedule an add. task which only causes regressions everywhere :) +09:46 < wsa_> neg: please keep me CCed on the VIN patches that might be relevant for me +09:46 * morimoto back from happy paper work +09:46 < wsa_> morimoto: paperwork makes you happy? +09:47 < neg> wsa_: will do +09:48 -!- Irssi: #periperi-io: Total of 8 nicks [1 ops, 0 halfops, 0 voices, 7 normal] +09:48 < wsa_> jmondi: are you all good? +09:49 < jmondi> wsa_: yes I am +09:50 < jmondi> I would like to discuss briefly about the max9611 driver progress +09:50 < wsa_> sure +09:51 < jmondi> well, basically Jonathan has reviewed the driver, some comments here and there, but we'll get there +09:51 < jmondi> what I would like to have clarified is the usage model of the userspace interface +09:52 < jmondi> because it makes a great difference knowing what would ideally be the polling frequency, to decide if driver should implement buffered reads or just chrdev interface is enough +09:52 <@morimoto> wsa: I'm supper happy now :) +09:53 < jmondi> that chip will be used to implement DVFS policies, right? +09:56 < wsa_> what would be the effort to implement caching? +09:56 < wsa_> i'd think let's wait with caching until we know we need it? +09:57 < jmondi> ok, I know we don't have to reason for just one specific use case, but given the many functions of that chip, I feel like we should define a use case for that on Renesas platforms +09:59 < jmondi> also, there are some constraints due to the HW design (eg. driver does not support some functions like op-amp and comparator, because they're not wired on Salvator-X design) +10:00 < wsa_> i see +10:00 < wsa_> is that documented somewhere? +10:01 < wsa_> i think this is fairly standard linux driver evolution, but it is always helpful to document what is implemented and what not +10:02 < jmondi> yes, in the driver there are many comments about non-supported functionalities... +10:02 < jmondi> but that's not big deal, last question about Jonathan was more about what polling frequency should the driver support +10:03 < jmondi> that makes implementation quite different +10:03 < jmondi> we can take that privately later, if I'm flooding the channel and the meeting with this, sorry +10:03 < wsa_> geert may correct me, but as I see it we are currently missing the details like this? +10:04 < wsa_> jmondi: all fine, this is one place to discuss such things +10:04 < geertu> The MAX9611 is used to monitor power consumption on the DVFS and VDD0.8 rails +10:04 < jmondi> ok then, I won't feel bad talking too much then +10:04 < geertu> I don't know what's the typical timing granularity needed for that +10:05 < wsa_> maybe jonathan has an idea? +10:05 < jmondi> seems like he's undecided as well... The real issue here is auto-gain configuration +10:05 < wsa_> is there a "most flexible" solution? +10:06 < jmondi> eh, I wish I know what that would be... supporting most uses cases implies creating a quite sluggish interface in sysfs, where userspace is required to take care of auto-gain settings +10:07 < jmondi> a sort of calibration process +10:08 < jmondi> on the other side, we can present the "processed" values from a single attribute, performing auto-gain setting in kernel space, but that would not support buffered reads, and will make complex implementing it in future +10:09 < jmondi> and that's where my question come from: Do we have any idea what would be a plausible sampling frequency on that device (if we do have defined use-cases for that chip specific to our platforms) +10:09 < wsa_> i see +10:10 < geertu> jmondi: You could ask BayLibre (Neil Armstrong) what sampling frequency they find useful for ACME with their tools +10:10 < wsa_> things I can think of: +10:10 < wsa_> a) ask on linux-pm if they have an idea what frequency is needed +10:11 < wsa_> or BayLibre ;) +10:11 < wsa_> and b) I don't think implementing complex userspace configuration without a clear use-case is benefitial +10:11 < geertu> jmondi: I never use the GUI tools that draw graphs +10:12 < geertu> w.r.t. b) yes, KISS +10:12 < wsa_> exactly +10:13 < jmondi> geertu: I didn't even know it existed. Mostly, I don't know what tools are out there that polls on a device like this, that's why I don't have idea about typical use cases +10:13 < wsa_> which would lead to chosing the "simpler" method unless we can create the use case +10:14 < wsa_> jmondi: does it help you a little? +10:14 < jmondi> geertu: wsa_: Ok, I'll ask a bit around, if I'm not pointed to any monitoring tool with strict time requriements out there, I'll go for the simple solution +10:15 < jmondi> wsa_: yes, thank. Sometimes is easy for me to get lost, and need some directions to find out where to ask informations or where to look at :) +10:15 < wsa_> sounds good to me for now +10:15 < geertu> jmondi: http://baylibre.com/acme/ shows some screenshots. One of them says "100 S/s" +10:15 < wsa_> jmondi: this is true for all of us +10:16 < wsa_> and where working in a team is really benefitial :) +10:16 < jmondi> wsa_: it's a big world out there :) +10:16 < jmondi> geertu: thanks +10:16 < wsa_> please post your findings to renesas-soc or periperi, I think we are all interested in the outcome +10:16 < geertu> wsa: And esp. with FLOSS, the team (and its knowledge) is big +10:17 < wsa_> yes :D +10:17 < wsa_> so, I'd like to close the meeting soon +10:17 < wsa_> so, if there is anything unsaid left, now would be the time +10:18 <@morimoto> OK, thanks boys & girls !! +10:19 < shimoda> thanks! bye! +10:19 < geertu> Thx, bye! +10:19 < jmondi> thank you all, bye! +10:20 < horms> bye +10:20 < wsa_> Good then, have a great week all! +10:20 < neg> thanks all +10:21 < wsa_> neg: I'll try to review your thermal patches later today +10:21 < wsa_> bye +10:22 < neg> wsa_: thanks +10:24 -!- shimoda [~shimoda@relprex2.renesas.com] has quit Quit: WeeChat 0.4.2 +--- Log closed Tue Mar 07 10:25:27 2017 diff --git a/wiki/Chat_log/20170309-mm-chatlog b/wiki/Chat_log/20170309-mm-chatlog new file mode 100644 index 0000000..e1c695e --- /dev/null +++ b/wiki/Chat_log/20170309-mm-chatlog @@ -0,0 +1,481 @@ +Multimedia-chat-meeting-2017-03-09 + +Day changed to 08 mar 2017 +08:56 < pinchartl> I see everyone gathering here. good morning/afternoon +08:56 < morimoto> Hi +08:57 < jmondi> Good morning +08:57 < uli___> hi +08:58 < pinchartl> Kieran won't be able to attend +08:58 < pinchartl> and I assume Niklas is on his way +08:59 < pinchartl> so let's wait just a few minutes +08:59 < pinchartl> and who knows, Magnus could even show up :-) +09:00 < neg> morning +09:00 < pinchartl> hi Niklas +09:00 < neg> hello +09:01 < pinchartl> hi Magnus ! +09:01 < pinchartl> wow, it will be a busy meeting today :-) +09:02 < pinchartl> let's get started +09:02 < pinchartl> agenda for today +09:02 < dammsan> hi pinchartl +09:02 < pinchartl> - Tasks status update +09:02 < pinchartl> - Graphics Performance issue reported by the BSP team +09:02 < pinchartl> - Multimedia plan +09:02 < pinchartl> - Additional tasks for Q2 +09:02 < pinchartl> - Meeting around LinuxCon Japan +09:03 < pinchartl> anything else ? +09:03 < morimoto> - sightseeing plan on LinuxCon Japan (joke) :P +09:04 < pinchartl> that's also for core and I/O :-) +09:04 < pinchartl> Topic 1. Status check for the multimedia tasks +09:04 < pinchartl> jmondi: you're first in alphabetical order I'm afraid. would you like to do the honours ? +09:05 < jmondi> of course +09:05 < jmondi> my pleasure +09:05 < jmondi> also because it will be quite fast +09:06 < jmondi> A) STarted working again on DMABUF test application. Took ~week to port it to Gen3, basically because I gave a loooot of things for granted, but they were + board specific +09:06 < jmondi> dammsan: I still would like to have the remote ALT board accessible, to make sure it works on Gen2 as well +09:07 < jmondi> B) Implement the event loop interface and other review issues +09:07 < jmondi> C) = D) = NULL +09:07 < dammsan> jmondi: it is on my TODO list, sorry to keep you waiting +09:07 < jmondi> dammsan: it should be enough to restart that VM... or restart ssh server there +09:08 < jmondi> --eot-- +09:08 * morimoto Renesas chat now +09:08 < pinchartl> jmondi: thank you +09:09 < pinchartl> next, Kieran +09:09 < pinchartl> who is not here + +09:09 * morimoto back from Renesas chat +09:09 < pinchartl> he has submitted his status update by e-mail +09:10 < pinchartl> Since last meeting: +09:10 < dammsan> jmondi: the VM is dead, first time that happened. i have a pile of high priority stuff on my TODO before i will attend +09:10 < pinchartl> - FOSDEM +09:10 < pinchartl> - Holiday +09:10 < dammsan> jmondi: please use gen3 for now +09:10 < pinchartl> - VSP-DU race fix (display flicker issue) +09:11 < pinchartl> - Patches developed, and tested quite intensively. +09:11 < pinchartl> - Fairly high confidence that they should be robust +09:11 < pinchartl> - (Renesas to test under Wayland environment) +09:11 < pinchartl> For the next two weeks: +09:11 < pinchartl> - Partition algorithm restrictions analysis (Now have updated datasheet) +09:11 < pinchartl> - Rebase, and follow up on outstanding reviewed patches +09:11 < pinchartl> Blockers: +09:11 < pinchartl> - No budget until beginning of April +09:11 < pinchartl> so the "for the next two weeks" section will likely need to be postponed +09:12 < jmondi> dammsan: sure! +09:13 < pinchartl> I will take care of submitting pull requests for the patches that are ready for upstream +09:14 < pinchartl> next, me +09:14 < pinchartl> since Portland +09:14 < pinchartl> I've rebased the HDMI output patches +09:14 < pinchartl> some of them got merged already +09:15 < pinchartl> the dw-hdmi rework is pending +09:15 < pinchartl> I have been told it would be merged in the next few days +09:15 < pinchartl> I'll then submit a pull request for the DU patches on top of it +09:16 < pinchartl> which should make it to v4.12 +09:16 < pinchartl> (where's the round of applause ? :-)) +09:16 < pinchartl> then, I've also reworked and rebased the VSP rotation and histogram support +09:17 < pinchartl> the largest part of that was to document interaction between formats and controls in V4L2 +09:17 < pinchartl> my documentation patch got approved by Hans, Mauro seemed OK too +09:17 < pinchartl> I'll submit a pull request as well, but Mauro still has to review some of the patches, so it might not be accepted right away +09:18 < pinchartl> apart from that, it's been lots and lots of review and discussions +09:19 < pinchartl> for the next two weeks, holidays :-) +09:19 < pinchartl> I'll be back on the 26th +09:19 < uli___> _that_ deserves a round of applause, IMO :) +09:19 < uli___> laurent not working. who would have thought? :) +09:19 < pinchartl> :-D +09:20 < morimoto> Sky holidays ? +09:20 < pinchartl> no, South African holidays +09:20 < pinchartl> I will be offline for two weeks +09:20 < neg> uli___: are you happy for Laurent having a holiday or that he will be off grid for a while ;-) +09:21 < pinchartl> no articular issue or blocker for me +09:21 < pinchartl> dammsan: you're next +09:21 < morimoto> Wait +09:21 < morimoto> About HDMI video out, actually, HDMI video out is still unstable here. almost OK, but sometimes doesn't work +09:21 < morimoto> If it became NG, never OK again. HDMI Monitor say "No signal" +09:21 < dammsan> pinchart: nothing to report here +09:21 < pinchartl> morimoto: that will need to be debugged and fixed +09:22 < pinchartl> morimoto: I never claimed that the code is bug-free :-) +09:22 < morimoto> Laurent side can't reproduce this, right ? +09:22 < pinchartl> so far I haven't been able to +09:22 < morimoto> OK, it will be never-endding-story +09:22 < pinchartl> but I can try again if someone gives me a clear test procedure +09:22 < dammsan> morimoto: maybe we can revisit next quarter? +09:22 < morimoto> By SoW do you mena ? +09:23 < morimoto> s/mena/mean/ +09:23 < pinchartl> note that the latest patch series should improve the hotplug use cases, so maybe the problem has been fixed +09:23 < pinchartl> (maybe...) +09:23 < dammsan> morimoto: no, when pincharl is back from vacation +09:23 < morimoto> Ahh, OK, np +09:23 < morimoto> not urgent, but I wanted to tell +09:24 < pinchartl> thank you +09:24 < dammsan> morimoto: thanks for sharing +09:24 < pinchartl> morimoto: your turn +09:24 < morimoto> OK +09:24 < morimoto> Before my ABC, I have request to Laurent (before vacation :) +09:25 < pinchartl> go ahead +09:25 < morimoto> BSP team is waiting answer from you, about +09:25 < morimoto> Subject: About Graphics Performance +09:25 < morimoto> Date: Wed, 8 Feb 2017 10:04:54 +0900 +09:25 < morimoto> Please makes BSP team happy :P +09:25 < pinchartl> that's the second topic for today, as I mentioned when we started the meeting :) +09:25 < morimoto> OK +09:25 < morimoto> A) What have I done since last time: +09:25 < morimoto> - I posted OF-graph patch again. +09:26 < morimoto> - I created 40bit Descriptor Mode on Audio DMAC +09:26 < morimoto> - Forwarded BSP team question to Multimedia member +09:26 < morimoto> B) What I plan to do till next time: +09:26 < morimoto> - Missing 8ch support on Audio (not urgent) + +09:26 < morimoto> - Consider Tx/Rx interrupt sharing (not urgent) +09:26 < morimoto> last one was I reported by email, but finished :P +09:26 < morimoto> C) Problems I have currently: +09:26 < pinchartl> :-) +09:26 < morimoto> - I want to post HDMI sound patch-set which is based on +09:26 < morimoto> posted OF-graph patch-set. Rob's response is... +09:27 < morimoto> D) Posted/Accepted bugfix patches: +09:27 < morimoto> Subject: [PATCH] ASoC: rsnd: fix sound route path when using SRC6/SRC9 +09:27 < morimoto> Subject: [PATCH] ASoC: rcar: avoid SSI_MODEx settings for SSI8 +09:27 < morimoto> --EOF-- +09:27 < pinchartl> do I need to list those patches or will they be picked up by your script ? +09:28 < morimoto> my script is very clever, more than me :) +09:28 < morimoto> so, D) is no longer needed on meeting, actually +09:28 < pinchartl> :) +09:28 < pinchartl> so Rob said "..." ? +09:29 < morimoto> no response from him +09:29 < morimoto> Am I mistaken +09:29 < morimoto> ? +09:29 < morimoto> Rob is no maintener ? +09:29 < morimoto> s/no/not/ +09:29 < pinchartl> he's a DT maintainer +09:29 < pinchartl> I expect him to be busy this week +09:29 < pinchartl> with Linaro Connect in Budapest +09:30 < morimoto> Ahh... +09:30 < pinchartl> so maybe you should try to ping him next week ? +09:30 < morimoto> OK, will do. thanks +09:31 < pinchartl> you're welcome +09:31 < pinchartl> next, neg +09:31 < neg> a) Started to rework VIN driver for Gen3 to only use media graph and let userspace handle subdevice configuration and supported BSP team with investigation + regarding the VIN. +09:31 < neg> b) Complete the VIN Gen3 rewrite. +09:32 < neg> c) None +09:32 < neg> d) None +09:32 < neg> -- EOT of short version, see reply to meeting invatation for more details -- +09:32 < morimoto> Ahh, neg and pinchartl, I sent camera board check request +09:32 < morimoto> please check it +09:32 < pinchartl> should I ignore the issue reported in the e-mail then ? +09:33 < neg> morimoto: I checked and replied to it :-) +09:33 < morimoto> thanks +09:33 < pinchartl> next, uli___ + +09:34 < uli___> i tried to get a mainline kernel to run on the acer chromebook r13 +09:34 < uli___> to give us a model organism for gpu development +09:34 < uli___> see my status update on how that has failed so far... +09:34 < uli___> the next thing i'm going to do is put together a prototype for a OV10365/MAX9271/MAX9286 camera setup +09:35 < uli___> that's it for now +09:35 < uli___> driver prototype, that is +09:35 < uli___> i'm not completely awake yet :) +09:35 < pinchartl> :-) +09:35 < neg> for the chromebook lack of serial console, is netconsole an option? +09:36 < pinchartl> neg: nope, we have no network +09:36 < pinchartl> the problem at hand is to get a kernel to boot at all +09:36 < pinchartl> it certainly doesn't boot to UI +09:36 < neg> I see than I'm out of ideas :-( +09:36 < pinchartl> and doesn't boot to the network either +09:36 < pinchartl> I still thing our best option is to get this think opened and locate a serial port +09:37 < pinchartl> dammsan: any other idea ? +09:38 < geertu> uli___: "blinky LEDs are behind the embedded controller" +09:38 < uli___> yes +09:38 < geertu> uli___: Can you talk to them through the EC? +09:39 < geertu> (on FOSDEM, there was a presentation about the EC) +09:39 < dammsan> i just asked same thing as geertu over email +09:39 < dammsan> getting an LED to blink would be very nice +09:39 < dammsan> i can take it from there +09:40 < uli___> might work +09:40 < uli___> but the ec driver isn't trivial either +09:41 < pinchartl> why don't anyone listen when I say we should crack the case open ? :-) +09:41 < dammsan> perhaps it is possible to scale it down somehow? +09:41 < uli___> i think writing custom code that talks to the ec is more likely to succeed +09:41 < dammsan> uli___: what do you think about opening it up? +09:42 < pinchartl> there might even be a jtag port inside +09:43 < uli___> i don't know. i'm afraid it might end up open forever, with an unpredictable degree of functionality :) +09:43 < pinchartl> open forever isn't a big issue +09:43 < dammsan> you need to press a key to boot +09:44 < pinchartl> the unpredictable degree of functionality is a bit more annoying +09:46 < pinchartl> so what's the plan there ? +09:46 < uli___> i can look into getting the ec leds to blink +09:47 < dammsan> my hope is that ulrich will hand over his result to me including LED blink code +09:48 < pinchartl> so do you want to go for one more round and try to talk to the EC from a mainline kernel ? +09:49 < dammsan> i can port it +09:49 < dammsan> i've done things like that before +09:49 < dammsan> no biggie +09:49 < pinchartl> I don't have high hopes there, but if you think it's useful, it's your choice :) +09:49 < dammsan> seems our best choice right now +09:49 < pinchartl> I *still* believe the best choice is to open it up +09:49 < dammsan> but please note that next quarter additional batch 1 will not cover the GPU +09:50 < dammsan> to give some time to figure things out +09:50 < geertu> Do we know what's expected to be found inside? +09:50 < dammsan> pinchartl: how about we compete about it in parallel once you are back from vacation? +09:51 < dammsan> =) +09:51 < pinchartl> dammsan: no, thanks, I have lots of work on DU, VSP and VIN already :) +09:51 < dammsan> i'll take a blinky LED over unknown hardware any day +09:51 < dammsan> there you go =) +09:51 < dammsan> answer is pretty clear +09:52 < pinchartl> ok, let's put that on hold then +09:52 < pinchartl> this finishes the status update portion of this meeting +09:53 < pinchartl> Topic 2. Graphics Performance issue +09:53 < pinchartl> this was reported by the BSP team +09:54 < pinchartl> who noticed a performance regression between v4.6 and v4.9 +09:54 < pinchartl> due to commit f1f0197796a61e5548af32606f15bcf8cf353267 +09:54 < pinchartl> drm: rcar-du: Map memory through the VSP device +09:54 < pinchartl> and commit 60facdbd4d62b863917263bb1ad77bbb4a4a9369 +09:54 < pinchartl> v4l: vsp1: Add API to map and unmap DRM buffers through the VSP +09:55 < pinchartl> those two patches ensure proper operation of the DU + VSP on Gen3 when the VSP is behind an IOMMU +09:55 < pinchartl> this is required, but leads to an additional cache flush +09:55 < pinchartl> which in turn degrades performances +09:56 < pinchartl> (~300µs per frame) +09:56 < pinchartl> the cache flush is needed +09:57 < pinchartl> in the sense that, in the general case, the CPU will render to the buffer +09:57 < pinchartl> (of course optimizations are possible when the CPU doesn't touch the buffer, but that's a separate topic) +09:57 < pinchartl> *but* +09:58 < pinchartl> the memory is currently mapped uncached to the CPU +09:58 < pinchartl> so as long as this doesn't change, we could skip the cache handling operations +09:59 < pinchartl> the DMA mapping API supports skipping cache management +09:59 < pinchartl> when the DMA_ATTR_SKIP_CPU_SYNC flag is set +09:59 < pinchartl> s/flag/attribute flag/ +10:00 < pinchartl> we should experiment with that +10:00 < pinchartl> I can give it a try after coming back from vacation +10:00 < pinchartl> and I'll reply to the BSP team's e-mail today with this information +10:00 < pinchartl> morimoto: does this answer your question ? +10:01 < morimoto> Yes, maybe + +10:01 < morimoto> something feedback to BSP team makes them happy at this point +10:01 < morimoto> I don't know how urgent it is +10:02 < morimoto> do you think it will be long-term problem ? +10:02 < pinchartl> note that those two commits are not upstream +10:02 < pinchartl> they're part of the IOMMU support work for DU+VSP +10:02 < pinchartl> but haven't been merged yet +10:03 < pinchartl> hopefully it won't be a long-term issue +10:03 < pinchartl> setting the DMA_ATTR_SKIP_CPU_SYNC attribute might be all we need +10:03 < pinchartl> but it has to be analyzed in more details, maybe there's more behind it +10:03 < morimoto> OK, thanks +10:05 < pinchartl> next topic, +10:05 < pinchartl> Topic 3. Multimedia plan +10:05 < pinchartl> which is related to +10:05 < pinchartl> Topic 4. Additional tasks for Q2 +10:05 < pinchartl> additional tasks for Q1 are due mid-March +10:05 < pinchartl> so ideally we should already have started negotiating additional tasks for Q2 +10:06 < pinchartl> which isn't the case +10:06 < pinchartl> and it realistically can't be finalized before I leave at the end of this week +10:06 < pinchartl> which means we would need to delay additional tasks once again +10:07 < pinchartl> we have, however, started drafting a plan for multimedia development in Q2 and beyond when we were in Portland +10:08 < pinchartl> with task proposals for Q2 +10:08 < pinchartl> I thus propose trying more losely-defined additional tasks for the first batch of Q2, with the details shifted from the SoW to the overall multimedia + development plan and schedule +10:09 < pinchartl> in practice this means that SoWs could be negotiated faster +10:09 < pinchartl> but the deliverables and milestones will be as clearly defined as before +10:09 < dammsan> sure, we just need a plan =) +10:09 < pinchartl> dammsan: did I send you the spreadsheet we wrote during the meeting ? +10:10 < dammsan> i don't think so +10:10 < pinchartl> I thought I did but couldn't find that in my mailbox +10:10 < pinchartl> ok +10:10 < pinchartl> that's fixed now +10:10 < dammsan> thanks!! +10:11 < neg> if possible I would also like a copy of the portland spreadsheet :-) +10:11 < uli___> same here +10:11 < dammsan> pinchartl: would it be possible for you to extract loose additional tasks for each member from the spread sheet? +10:12 < pinchartl> neg: uli___: done +10:12 < neg> thanks +10:12 < pinchartl> dammsan: the focus is VIN for all team members for the first half of Q2 +10:12 < dammsan> pinchartl: or i can do it if you are busy +10:12 < pinchartl> (except for me I suppose, as VSP and DU still need maintenance) +10:13 < pinchartl> so I propose the same additional task for everybody + +10:13 < pinchartl> so I propose the same additional task for everybody +10:13 < pinchartl> along the lines of "VIN CSI-2 multiple virtual channels development for Gen3" +10:13 < dammsan> ok, so what is the deliverable then? +10:14 < pinchartl> the type of deliverables is still kernel code, tests, documentation, as usual. posted to the same mailing lists and wikis +10:14 < pinchartl> and the exact tasks are then defined in a plan +10:15 < pinchartl> we had +10:15 < pinchartl> ADV7482 Gen3 support upstream +10:15 < pinchartl> MAX9260 driver prototype (Blanche) +10:15 < pinchartl> MAX9271 driver prototype (Camera) +10:15 < pinchartl> MAX9286 driver prototype with a single channel (Gen3) +10:15 < pinchartl> V4L2 multiplexed stream support (.s_stream(), frame descriptors) +10:15 < pinchartl> V4L2 pad-aware async subdev support +10:15 < pinchartl> we need to revisit the details a bit as MAX9260 + Blanche might not make too much sense at this point +10:16 < pinchartl> (as our PCB development plans got cancelled things may need to be adapted) +10:16 < dammsan> sure +10:17 < dammsan> so based on the spread sheet +10:17 < dammsan> it looks like it is possible to deliver a bunch of prototypes for the first batch +10:18 < dammsan> that would be 5/M as due date +10:19 < pinchartl> yes +10:19 < pinchartl> but there are many dependencies +10:19 < pinchartl> so we'll need to adjust the goals dynamically if some parts get delayed +10:20 < pinchartl> the OV10635 + MAX9271 + MAX9286 prototype is very important in that regard +10:20 < pinchartl> uli___: we all count on you :-) +10:20 < uli___> omg... +10:20 < dammsan> so all tasks marked with Q2/1 can be baked into a single task then? +10:20 < pinchartl> that's my proposal +10:21 < pinchartl> same additional task wording for everybody +10:21 < pinchartl> still with clearly defined goals internally, which can be communicated to Renesas +10:21 < dammsan> sure +10:21 < pinchartl> and we'll follow progress at least bi-weekly during the multimedia meetings +10:21 < dammsan> can you communicate this plan with all members? +10:22 < dammsan> so people not present in portland knows whatis going on +10:22 < pinchartl> I would like to add to the SoWs that team members are responsible for reporting any current or foreseen issue or blocker ASAP to make it possible for the + plan to be maintained dynamically +10:22 < pinchartl> let me send the spreadsheet to the periperi list +10:23 < dammsan> so how do we make the task description? +10:23 < pinchartl> or actually I'll attach it to the meeting report +10:23 < dammsan> wait until you're back? +10:23 < pinchartl> do you mean the SoW description or the tasks ? +10:24 < dammsan> i mean the SoW description +10:24 < dammsan> i guess we all want the papers in our hand +10:25 < pinchartl> I would call them something along the line of "VIN CSI-2 multiple virtual channels development for Gen3" +10:25 < pinchartl> all the boilerplate text can be copied from previous SoWs +10:25 < pinchartl> with an additional paragraph asking to report issues and blockers proactively +10:25 < pinchartl> and then a small description of the goal +10:26 < dammsan> okhow about including the list of device drivers? +10:26 < pinchartl> with short-term goals being communicated as part of the multimedia team management +10:26 < pinchartl> yes, I'd include VIN, CSI-2, MAX*, ADV*, ... +10:26 < pinchartl> we should list all of them +10:26 < pinchartl> I can try to send you a draft before I leave +10:26 < dammsan> can we have prototype driver support included as delvierable? +10:27 < pinchartl> yes +10:27 < dammsan> good +10:27 < dammsan> sure, if you can manage before you leave that would be great +10:28 < pinchartl> regarding the work itself and the detailed tasks +10:28 < pinchartl> there's a proposal in the spreadsheet +10:28 < pinchartl> but it will depend on the work Ulrich is doing +10:29 < pinchartl> so we'll still need a few weeks before we can start the work on those external components +10:29 < pinchartl> that's not an issue for Niklas (who will work on the VIN driver itself), Kieran (who will work on ADV7482) or me (who will be away for two weeks anyway) +10:30 < pinchartl> for Jacopo and Ulrich, I think continuing the work on the OV10635 and MAX* is still the next logical step +10:30 < dammsan> sounds good to me +10:31 < pinchartl> jmondi: how long will you still be busy with your current tasks, when will you need new ones ? +10:31 < pinchartl> dammsan: maybe you can help answering that question +10:32 < jmondi> for multimedia only: let's say I can fill this week with test application +10:32 < dammsan> pinchartl: i'm sure jacopo is happy to follow your plan as top priority +10:33 < jmondi> I can buy some time with IO and Core tasks (hopefully some feedback will arrive on both now that 4.12 merge window has closed) +10:33 < jmondi> I can live with what I have been tasked with until the end of March... +10:33 < pinchartl> I'll be back on the 26th of March +10:34 < pinchartl> if you need more work before I come back, there's the OV10635 driver +10:34 < pinchartl> morimoto: I think you mentioned during the Portland meeting that you could get a datasheet (under NDA) for that sensor +10:34 < pinchartl> do you know when we could get it ? +10:34 < jmondi> I can start looking into that, sure... Maybe not deliver that much, but studying it yes +10:35 < jmondi> If my understanding is correct, uli___ has some bsp code I can look at for that driver, right? +10:35 < pinchartl> correct +10:35 < pinchartl> the goal is to turn that into a proper V4L2 subdev driver +10:35 < pinchartl> with the help of the datasheet +10:36 < pinchartl> I think you'll have at least a week of work you can do before having to test anything +10:36 < morimoto> pinchartl: I'm sorry, but which sensor ? +10:36 < pinchartl> OV10635 +10:37 < morimoto> ? you didn't get it from Jinso ? +10:37 < pinchartl> let me verify that +10:37 < pinchartl> I got the schematics of the MAX9286 board +10:37 < pinchartl> and the MAX9286 datasheet +10:37 < pinchartl> the MAX9271 datasheet is publicly available so that's fine +10:38 < pinchartl> but I haven't received the OV10635 datasheet +10:38 < morimoto> OK, will check +10:38 < pinchartl> thank you +10:39 < pinchartl> could you please also provide it to Magnus (through Jinso if needed) ? +10:39 < pinchartl> dammsan: and could you then forward it to Jacopo ? +10:39 < pinchartl> or can Jinso provide it to Jacopo directly ? +10:40 < morimoto> pinchartl: will do +10:41 < pinchartl> thank you +10:42 < pinchartl> I think that's all for the plan/additional tasks topic, unless someone has more questions +10:42 < dammsan> sounds good +10:43 < pinchartl> this actually leaves me without additional tasks ;-) +10:43 < jmondi> I'll sync with uli___ to have that bsp driver shared +10:43 < pinchartl> but I'm ok until end of March this time, so we can negotiate them when I'll be back +10:44 < pinchartl> dammsan: is that ok with you ? do you think we can proceed fast at end of March ? +10:44 < jmondi> and wait for that datasheet to land in my inbox from morimoto or dammsan +10:45 < pinchartl> jmondi: it's here +https://github.com/CogentEmbedded/meta-rcar/blob/v2.12.0/meta-rcar-gen3/recipes-kernel/linux/linux-renesas/0040-H3-MAX9286-TI964-support-add-10635-10640-cameras.patch +10:46 < jmondi> pinchartl: oh, thanks... +10:46 < jmondi> ov10635.h 1159 lines... loving it already +10:46 < neg> :-) +10:46 < pinchartl> and it combines 3 drivers... it's quite messy +10:47 < pinchartl> there's also https://patchwork.linuxtv.org/patch/18768/ +10:47 < dammsan> pinchartl: i'm flexible +10:47 < jmondi> is this saner? +10:48 < pinchartl> jmondi: in the sense that it's a driver for the ov10635 alone, yes. it has to be ported away from soc-camera +10:48 < pinchartl> dammsan: ok, let's do that then +10:49 < pinchartl> morimoto: as I'll propose additional tasks for me at end of this month, please let me know if there's any particular request from the BSP team +10:49 < morimoto> jmondi, you can find ov10635 (local) driver here +10:49 < morimoto> http://git.ti.com/android-sdk/kernel-omap/blobs/eb15176df1e988393d12a2b8c2becd30078edbd8/drivers/media/i2c/ov10635.c +10:50 < pinchartl> it's the same driver. possibly slightly modified though +10:50 < pinchartl> jmondi: you'll have to consolidate all the code available I think +10:50 < morimoto> pinchartl: will do, with Magnus +10:51 < pinchartl> morimoto: thank you +10:51 < pinchartl> there are also base contracts that need to be renewed +10:51 < pinchartl> dammsan: any news about that ? +10:51 < jmondi> morimoto: pinchartl: thanks both... I'll save these and study +10:52 < morimoto> jmondi: worst case, you can create driver without datasheet :) +10:52 < pinchartl> jmondi: thank you. feel free to first focus on your other tasks, I could then be back when you'll start on the ov10635 to answer questions +10:53 < dammsan> pinchart: base tasks are higher priority than additional +10:53 < dammsan> i think they will be similar to before +10:53 < jmondi> morimoto: and if I know OV datasheet a bit, that would not make a big difference. pinchartl: that's the plan, right! +10:54 < pinchartl> dammsan: ok. I don't really expect anything new there indeed, but if you need any information from me, please let me know +10:54 < dammsan> however the "developer" task might go from per-group to a unified description for all groups +10:54 < pinchartl> I'm fine with that +10:54 < dammsan> the group leader tasks will still be separate +10:54 < pinchartl> it's a base contract anyway, it has to be losely defined +10:54 < pinchartl> thanks. I don't want to start leading other groups, we already have leaders who handle that fine :-) +10:55 < pinchartl> jmondi: the OV datasheets are not perfect, but they can still help +10:55 < pinchartl> dammsan: there's also a 25% base contract for Kieran in the pipe, right ? +10:55 < dammsan> i believee so +10:56 < dammsan> need to double check in the renesas office later this week +10:56 < pinchartl> great, thanks +10:57 < pinchartl> next topics then +10:57 < pinchartl> (let's finish this meeting...) +10:57 < pinchartl> Topic 5. Meeting around LinuxCon Japan +10:57 < pinchartl> uli___: could you please provide your availabilities ? +10:58 < uli___> for linuxcon japan? +10:59 < pinchartl> yes +10:59 < pinchartl> see "[periperi] Meeting around LinuxCon Japan" +10:59 < uli___> not available, i'm afraid +11:00 < pinchartl> not at all ? +11:00 < uli___> no, sorry. +11:00 < pinchartl> ok +11:00 < pinchartl> that's a shame +11:01 < pinchartl> but at least you don't have difficult requirements :-) +11:01 < uli___> always happy to help :) +11:01 < pinchartl> then +11:02 < pinchartl> the result is +11:02 < pinchartl> 66-77-788-77-76 +11:02 < pinchartl> (rounded) +11:03 < pinchartl> it's nearly a tie between before LCJ (77) and after (76) +11:04 < pinchartl> I'm tempted to go for 77 in that case +11:04 < pinchartl> but Niklas had a 11 score for that +11:04 < pinchartl> while Kieran and Jacopo have a 43 and 55 score respectively for the two days after the conference +11:05 < pinchartl> neg: how bad would it be for you before LCJ ? +11:05 < neg> managable +11:06 < jmondi> if for Niklas is not that pressing, I would encourage meeting before LCJ :) +11:06 < neg> at this point I'm more focused on setting the date and then I can work around it :-) +11:07 < pinchartl> then I'd rather go for monday-tuesday before the conference, as it has the highest score +11:07 < pinchartl> (nothing personal, it's all 99 for me) +11:08 < neg> works for me +11:08 < pinchartl> thank you +11:08 < pinchartl> then it's settled +11:09 < pinchartl> and I'll propose social events on the weekend after the conference (at least on Saturday) as that's 77 +11:09 < pinchartl> I'll be happy to hang out with anyone during the first or second weekend +11:09 < pinchartl> final topic +11:10 < pinchartl> Topic 6. Next meeting +11:10 < pinchartl> as I'll be away for two weeks, we'll have to postpone until end of March +11:10 < pinchartl> I propose the 28th or 29th, same time as today +11:10 < jmondi> works for me (both meeting and conference dates) +11:11 < neg> both ok for me +11:11 < dammsan> same here +11:11 < uli___> slight preference for the 28th +11:12 < pinchartl> then let's go for the 28th. the sooner the better as it will already be late +11:12 < pinchartl> that's all for today +11:12 < pinchartl> sorry for the long meeting +11:13 < neg> thanks all cu next time and pinchartl enjoy africa +11:13 < jmondi> pinchartl: is winter there right? how bad is climate down there? +11:14 < pinchartl> thank you +11:14 < pinchartl> no, it's summer +11:14 < geertu> pinchartl: Enjoy the holidays! +11:14 < morimoto> thanks all, pinchartl: enjoy your holidays +11:15 * jmondi confused on what season is now in his emisphere +11:15 < jmondi> thank you all +11:15 < geertu> jmondi: Winter ;-) +11:17 < dammsan> thanks bye bye +11:17 < uli___> bye, everyone diff --git a/wiki/Chat_log/20170314-core-chatlog b/wiki/Chat_log/20170314-core-chatlog new file mode 100644 index 0000000..0fa0d86 --- /dev/null +++ b/wiki/Chat_log/20170314-core-chatlog @@ -0,0 +1,260 @@ +Core-chat-meeting-2017-03-14 + +09:20 < geertu> Welcome to today's Renesas Core Group Chat (\pi-day Edition) +09:20 < geertu> Agenda: +09:20 < geertu> 1. Status updates +09:20 < geertu> 2. Additional tasks for 2017/Q2 phase 1 +09:20 < geertu> Topic 1. Status updates +09:20 < geertu> A) What have I done since last time +09:20 < geertu> B) What I plan to do till next time +09:20 < geertu> C) Problems I have currently +09:20 < geertu> D) Posted/Accepted bugfix patches +09:21 < geertu> Shimoda-san is first +09:21 < shimoda> yes +09:21 < shimoda> A) +09:21 < shimoda> - In last month, I reported about SYS-DMAC descriptor mode on-chip RAM support. +09:21 < shimoda> But, I should have reported it in detail. +09:21 < shimoda> - The HW restriction is we cannot use "Built-in memory is used" mode (= DMADPBASE_n.SEL = 0) +09:21 < shimoda> - We can use its own descriptor memory via DMADPBASE_n.SEL = 1 with DPBASE[31:4]. +09:21 < shimoda> - I tried new IPMMU patch set. And, it could boot correctly. (Magnus-san, Thank you!) +09:21 < shimoda> - The patch sets seem update later, I will make a workaround patch for SDHI after new patch sets are submitted. +09:21 < shimoda> B) +09:21 < shimoda> - After new patch sets of IPMMU are available, I will make a workaround patch. +09:21 < shimoda> C) +09:21 < shimoda> - Nothing for core. +09:21 < shimoda> D) +09:21 < shimoda> - Nothing for core. +09:21 < shimoda> -- EOT -- +09:22 < geertu> shimoda: What does "its own descriptor memory" mean? How does it differ from "Built-in memory"? +09:22 < shimoda> geertu: oops, it mean the same as its own descriptor memory and Built-in memory +09:24 < shimoda> if we would like to use SYS-DMAC0's built-in memory, +09:24 < geertu> shimoda: The documentation for DMADPBASE_n.SEL says "0: Setting Prohibited" +09:25 < geertu> Ah, only for Gen3. For Gen2 the bit chooses betwen Built-in and external memory +09:25 < shimoda> geertu: ahh, that's correct, I looked old doc (rev.0.50) X( +09:26 < geertu> s/betwen/between/ +09:26 < shimoda> rev.0.53 is avoiding the restriction :) +09:27 < shimoda> geertu: For gen2, I heard it has the same issue +09:27 < shimoda> with gen3 +09:27 < shimoda> Maybe for gen2, hardware team will issue errata info?? +09:28 < shimoda> i will confirm it (for gen2's tu) +09:28 < geertu> OK, thx +09:28 < shimoda> s/tu/errata info/ +09:29 < geertu> Thank you, Shimoda-san +09:29 < geertu> Next is Niklas +09:29 < neg> A) Nothing for Core +09:29 < neg> B) Pickup core task(s) as part of base, suggestions on whats needed is welcome. What I can think of at the top of my head +09:29 < neg> - Pickup work on Magnus 'dmaengine: rcar-dmac: Priority and slow mode prototypes' series, Magnus once told me he might want me to do that not sure about how he feels today. +09:29 < neg> - Implement synchronize() for rcar-dmac for https://patchwork.kernel.org/patch/9557691/ +09:29 < neg> C) None +09:29 < neg> D) None +09:29 < neg> EOT +09:30 < dammsan> neg: i think we should wait for feedback from Laurent +09:30 < neg> sounds like a good idea +09:30 < geertu> Laurent is away for the next 10 days +09:31 < geertu> synchronize() is definitely a good thing to do +09:31 < geertu> Thanks Niklas +09:31 < geertu> Next is Morimoto-san +09:32 < morimoto> OK +09:32 < morimoto> A) What have I done since last time: +09:32 < morimoto> - posted SYS-DMAC 40bit + Descriptor mode patch (no response) +09:32 < morimoto> - posted video logo init syscall exchange patch (no response) +09:32 < morimoto> B) What I plan to do till next time: +09:32 < morimoto> - follow above 2 patches +09:32 < morimoto> C) Problems I have currently: +09:32 < morimoto> - No problems +09:32 < morimoto> D) Posted/Accepted bugfix patches: +09:32 < morimoto> - No patches +09:32 < morimoto> X) Question from me +09:32 < morimoto> - could you receive new 0.51/0.52/0.53 datasheet ? +09:32 < morimoto> - 0.52 seems have both ES1.x and ES2.0 +09:32 < morimoto> +09:32 < morimoto> --EOF-- +09:33 < geertu> morimoto: I've downloaded the files, but haven't verified them, or looked at the contents +09:33 < geertu> morimoto: Thanks a lot! +09:33 < dammsan> morimoto: i will redistribute later today +09:33 < morimoto> OK, nice to know ! +09:34 < morimoto> Basically 0.52 is for ES2.0, but it has ES1.x folder +09:34 < morimoto> I don't know why +09:36 < geertu> morimoto: Perhaps 0.51 is for H3 ES1.0? And 0.52 is for H3 ES1.x? +09:36 * geertu sha256sum OK +09:36 < morimoto> My understanding is that 0.51 is for ES1.x, 0.52 and later is for ES2.0 +09:36 < morimoto> shimoda: my understanding is correct ? +09:37 < shimoda> morimoto: yes. +09:38 < geertu> So 0.52 is not useful, as it's superceded for H3 ES2.0 and M3-W ES1.1 by 0.53? +09:39 < geertu> And which one is for H3 ES1.0? rev. 0.20? ;-) +09:40 < morimoto> Actually, 0.52 was updated in these days, and we don't know what happen on it :( +09:41 < morimoto> 1st version to 0.51 was for ES1.x +09:41 < morimoto> If my understanding was correct +09:42 < morimoto> geertu: you question is which is for ES1.0, and which is ES1.x ? +09:42 < morimoto> But in our understanding, datasheet has no difference for ES1.x +09:42 < geertu> morimoto: yes. OK. +09:43 < shimoda> according to the manual team's redmine, rev.0.50 is H3 ES1.1. 0.51 is M3. 0.52 is V3M. 0.53 is V3H. and 0.54 (will be released on end of Apr) is M3N, D3 and E3 +09:44 < geertu> OK, thx +09:45 < geertu> Thank you, Morimoto-san +09:45 < geertu> Next is Magnus +09:49 < dammsan> ok, i've been working on IPMMU and DMAC, nothing else to report =) +09:49 < geertu> Thanks, Magnus +09:49 < geertu> Next is Jacopo +09:50 < jmondi> here I am, so.. +09:50 < jmondi> A) Nothing: no core work since last time we met +09:50 < jmondi> B) I have now received a considerable amount of reviews on RZ/A1 pin controller, I will send v2 possibily this week +09:51 < jmondi> C) not really a task, but I still have to work on Peach, and I'm waiting for digikey to deliver me some stuff +09:51 < jmondi> D) none +09:51 < jmondi> --- eot --- +09:51 < geertu> Thank you, Jacopo +09:52 < geertu> Next is Geert +09:52 < geertu> A) What have I done since last time +09:52 < geertu> - v2 of R-Car H3 ES2.0 support (clk/pfc/sysc) +09:52 < geertu> - v2 of INTC-SYS clock addition +09:52 < geertu> - v2 of R-Car M3-W secondary CPU +09:52 < geertu> - v5 of DMA_ATTR_FORCE_CONTIGUOUS +09:52 < geertu> - DT binding update to add resets to rcar-du +09:52 < geertu> - DT binding and identification of RZ/G1H and RZ/G1N +09:52 < geertu> - Posted "long story" summary for Suspend-to-Idle to periperi +09:52 < geertu> - DT cleanups +09:52 < geertu> B) What I plan to do till next time +09:52 < geertu> - v2 of resets for R-Car H3 and M3-W DTS +09:52 < geertu> C) Problems I have currently +09:52 < geertu> - None +09:52 < geertu> D) Posted/Accepted bugfix patches +09:52 < geertu> - Nothing important +09:52 < geertu> EOT +09:53 < geertu> laurent and Marek are excused, Ulrich and Simon are absent, so no updates from them +09:53 < geertu> Topic 2. Additional tasks for 2017/Q2 phase 1 +09:54 < geertu> What's important? What do we want to do next? +09:54 < geertu> Who's interested in doing some core work? +09:55 < neg> I'm interested in core work :-) +09:55 < geertu> So far I haven't received new requests from other groups (I/O, MultiMedia) +09:55 < jmondi> I will defintely need some core work after April, yes +09:55 < dammsan> geertu: i think we should continue to improve the SYS-DMAC driver with priority support and such +09:55 < dammsan> it may require more deeper investigation to make sure RX is prioritized over TX +09:56 < dammsan> and then there is PM for a whole bunch of drivers +09:56 < geertu> neg: Want to do "RCAR-DMAC,?,noplan,?,Add transfer termination synchronization" +09:56 < geertu> ? +09:56 -!- horms [~horms@penelope.horms.nl] has joined #periperi +09:56 < geertu> Hi SImon +09:57 < geertu> I guess I confused you with my silly CEST email? +09:57 < horms> Sorry, I got the updated time. But I had shuffled another appointment into the 9am slot (to free up 10am) +09:57 < neg> geertu: I need to lookin to exactly what that is, but sure I be more than happy to look into it +09:58 < horms> I should also have realised we are not in CEST for another 12 days :) +09:58 < dammsan> geertu: the versaclock driver that marek wrote may need an update +09:58 < horms> and i see my email is stuck on my laptop +09:58 < geertu> dammsan: Ah, what's missing? +09:58 < dammsan> geertu: apparently the versaclock part number is changing when salvator-xs board will be introduced +09:59 < geertu> dammsan: Do you know the new part number? +09:59 < dammsan> geertu: no, but I think Morimoto-san and/or Shimoda-san knows +10:00 < dammsan> never mind i found it in an old weekly report +10:01 < dammsan> apparently current board is using 5P49V5923A +10:01 < dammsan> new board will be using 5P49V6901A +10:02 < dammsan> so we want to make sure the driver supports that chip +10:03 < geertu> Ah, that's a VersaClock 6 +10:03 < dammsan> oh... +10:03 < dammsan> good that we start early then +10:03 < geertu> To be seen how much different that is +10:04 < dammsan> for sure +10:04 < dammsan> then there is PMIC with all that means +10:04 < geertu> Could be just a two line change, or a completely new and different driver +10:04 < dammsan> indeed +10:05 < dammsan> do we have upstream driver support for PMIC on Gen2 boards? +10:06 < dammsan> if not then we can perhaps do that in parallel with PMIC on Gen3 +10:07 < shimoda> about PMIC on Gen2 board, I think it already finished +10:08 < shimoda> commit ids = 46dd8a809effdc7ebe6ec760e3e421d5ac2a40f1 and a6b422664597d7b9ca6cf441bc48cfe1a707cd3a +10:08 < geertu> There are upstream drivers for da9063 and da9210, but we only have regulator properties in DT for da9210 +10:09 < geertu> Those commits are the da9063 nodes, used for system restart only +10:10 < geertu> commit 1d41f36a68c0f4e9b01d563ce33bab5201858b54 is for da9210 with dvfs +10:10 < dammsan> i highly doubt that all gen2 boards have the same status +10:11 < dammsan> including gose/alt/blanche +10:11 < geertu> Only Lager and Koelsch have the da9210 in DT +10:12 < dammsan> seems we have some stuff to do then =) +10:12 < shimoda> how about DTS sharing? +10:12 < dammsan> also perhaps internal watchdog workaround is needed +10:13 < dammsan> shimoda: good idea +10:13 < geertu> Like "generic,?,noplan,?,DTS sharing on H3 ES1.x/ES2.0, Salvator-X/ULCB +10:13 < geertu> "? +10:13 < shimoda> geertu: i meant yes +10:14 < geertu> "internal watchdog workaround"? +10:14 < dammsan> geertu: eventually i think we should consider virtualisation and perhaps extend virtio with dmaengine support +10:15 * geertu added "generic,?,noplan,?,VersaClock 5P49V6901A clock generator driver" +10:15 * geertu added "Gen2,?,noplan,?,Uniform PMIC support on all boards" +10:15 < dammsan> geertu: yeah about internal watchdog, i've heard some gen2 use case for soc without external pmic reset exists +10:16 < dammsan> so it may be time to start untangling the mess also known as gen2 reset handling +10:16 < geertu> DTS sharing means we'll become less conservative: when adding new features to one board/SoC combo, it'll appear on other combos, too +10:16 < shimoda> about gen2 watchdog to reset, just bsp team has a trouble :) +10:16 < geertu> dammsan: I can imagine the use case exists ;-) +10:17 < dammsan> shimoda: but last time i checked watchdog reset on gen2 is filled with errata issues +10:17 < shimoda> gen2 has CA15BAR and it doesn't reset by WDT X( +10:17 < dammsan> right there you go +10:18 < shimoda> dammsan: i don't know about the errata. I will ask BSP team +10:18 < dammsan> another topic for virtualization can be getting KVM going with a paravirtualized guest +10:18 < shimoda> later +10:18 < dammsan> shimoda: thanks +10:20 < dammsan> geertu: if anyone want to hack PSCI code then fixing the high power consumption in the firmware would be great +10:21 < dammsan> geertu: for the power off case that you kindly pointed out +10:22 < geertu> 5P49V6901A looks very similar to 5P49V5923A +10:24 < geertu> dammsan: According to the latest list of areas covered by the Core group, PSCI is not on the list ;-) +10:24 < dammsan> geertu: ok lets wait and see what marek says +10:24 < geertu> Anyway, someone may like to play with it ... +10:24 < dammsan> geertu: the psci stuff needs to be coordinated with internal renesas team to avoid duplication +10:25 * geertu added PSCI,?,noplan,?,Reduce power consumption in suspend/poweroff states +10:25 < geertu> Surew +10:25 < geertu> s/Surew/Sure/ +10:25 < dammsan> thanks +10:26 < geertu> horms: So we skipped your status update, but you did send it to the list. Want to duplicate it here? +10:27 < horms> Sure +10:27 < horms> Task update: none +10:27 < horms> A) No activity (no core tasks) +10:27 < horms> B) None +10:27 < horms> B) No problems +10:27 < horms> D) No fixes posted/queued up +10:27 < horms> Fwiw, I have been working on LTSI-4.9 backports (an add-on task for this quarter I asked to be canceled due to illness) +10:28 < horms> I also plan to address the integration tasks which were similarly cancelled +10:28 < horms> but perhaps not until next month +10:29 < geertu> Thanks Simon +10:31 < geertu> http://www.digikey.be/product-detail/en/idt-integrated-device-technology-inc/EVKVC6-6901ALL/800-3138-ND/5419197 +10:31 < geertu> bit more expensive (175€) than the VC5 counterpart +10:31 < geertu> I guess we can sort out the (wild list of) additional tasks on periperi ML? +10:32 < geertu> Is there anything else you want to discuss, tell, ask? +10:32 < horms> I'd day the hexagonal form factor is worth the extra money +10:32 < dammsan> nothing from me! +10:33 < geertu> It's a rare item: out-of-stock, lead time 18 weeks... +10:33 < horms> octagonal even! +10:34 < geertu> What's the lead time of Salvator-XS? +10:34 < shimoda> maybe mid May... +10:34 < geertu> That's less than 18 weeks +10:35 < geertu> Let's finish. +10:35 < geertu> Oh, one thing. +10:35 < geertu> Shall we reduce core group chat frequency to 1/month, like for I/O? +10:36 < geertu> Or keep 1/fortnight? +10:36 < neg> I like the 1/fortnight +10:37 < neg> but if it creates much overhead for you I'm open to change it :-) +10:37 < geertu> I don't mind. It just depends on the amount of work that's done/todo +10:38 < geertu> Let's keep next meeting at March 28, OK? +10:38 < neg> Yes +10:38 < geertu> Thanks for joining, and have a nice continued day! +10:38 < shimoda> yes. i booked it +10:39 < neg> thanks all +10:39 < morimoto> I have MultiMedia cat meeting on March 28 +10:39 < morimoto> I'm soory +10:39 < morimoto> s/soory/sorry +10:39 < geertu> Really? +10:40 < geertu> Ah, Laurent will have the meeting in Winter Time +10:40 < neg> Ahh me too, I thought we would do the two meetings one day thing :-) +10:40 < dammsan> right, collides with m/m +10:40 < geertu> So we can have it in Summer Time, i.e. one hour later ;-) +10:41 < geertu> Unfortunately the Tokyo side will have two parallel meetings, as they don't do Daylight Savings Time ;-) +10:41 < dammsan> geertu: at that time, shall we aim at having titles for the additional tasks fixed? +10:41 < geertu> dammsan: Yes +10:41 < dammsan> good thanks +10:41 < geertu> Would Wed March 29 fit? +10:42 < jmondi> works for me... +10:42 < neg> also works for me +10:42 < dammsan> me too +10:42 < shimoda> works for me +10:43 < geertu> So for people in a DST zone, it will be one hour later. JST time slot doesn't change. +10:43 < morimoto> works for me +10:43 < geertu> OK, thanks! +10:44 < geertu> Have a nice continued day! +10:44 < morimoto> Thanks all +10:44 < shimoda> Thanks! bye! +10:44 < jmondi> thank you.. will talk soon on periperi list then... bye +10:45 < dammsan> thanks!! diff --git a/wiki/Chat_log/20170328-mm-chatlog b/wiki/Chat_log/20170328-mm-chatlog new file mode 100644 index 0000000..5e8fcbd --- /dev/null +++ b/wiki/Chat_log/20170328-mm-chatlog @@ -0,0 +1,500 @@ +Multimedia-chat-meeting-2017-03-28 + +<morimoto> Hi +<morimoto> sorry for my late +<pinchartl> hi Morimoto-san [16:02] +<pinchartl> no worries +<morimoto> (I will post my list soon by email) +<pinchartl> it's my fault, I should have thought about DST when we scheduled + this meeting [16:03] +<pinchartl> so let's get started and hope that Jacopo will show up +<pinchartl> topics for today are [16:04] +<pinchartl> Topic 1. Status check for the multimedia tasks +<pinchartl> Topic 2. Multimedia plan (related to VIN development) +<pinchartl> Topic 3. Meeting around LinuxCon Japan [16:05] +<pinchartl> Topic 4. Next meeting +<pinchartl> anything else ? +<jmondi> pinchartl: yes I am... got confused with time zone switch [16:06] +<pinchartl> no worries +<pinchartl> Topic 1. Status check for the multimedia tasks [16:07] +<pinchartl> let's go in reverse alphabetical order to give Jacopo a few + minutes to wake up [16:08] +<pinchartl> uli___: you're first +* kbingham back +<uli___> so i have a max9286/9271/ov10635 driver combo that has a chance of + actually doing something +<uli___> not yet checked if it actually does +<uli___> and the mt8137 chromebook embedded controller is connected to the soc + via spi [16:09] +<uli___> not trivial to set up without a kernel +<uli___> that's a); nothing to report for b) c) d) [16:10] +<pinchartl> you don't plan to do any work for the next two weeks ? :-) +<uli___> well, tbd +<uli___> no concrete plans yet +<uli___> i might test the driver works, i guess :) [16:11] +<dammsan> we sort of depend on the outcome of the max/ov combo prototype... +<pinchartl> a bit more than *sort of* actually +<dammsan> =) +<pinchartl> it's very high priority +<pinchartl> so could you please elaborate on what has been done and what is + left to be done ? [16:12] +<pinchartl> and why the code couldn't be tested yet ? +<uli___> like i wrote in the e-mail, it probes, media-ctl says everything is + fine +<uli___> it's not tested yet because i finished it yesterday +<dammsan> uli___: i think the power controller bits should be sorted since + some time ago [16:13] +<dammsan> can you access devices over I2C? +<pinchartl> the power controller bits ? +<dammsan> apparently a second power adapter was needed for the board [16:14] +<dammsan> it was not provided with the board from the beginning +<uli___> the devices are there +* morimoto Renesas inside talk +<dammsan> present devices is an improvement i think +<pinchartl> dammsan: do you mean the MAX9286 board ? +<dammsan> i don't even know the name of the board +<dammsan> the hardware i received from morimoto-san [16:15] +<dammsan> the daughter board for salvator-x +<dammsan> with tons of camera connections +<pinchartl> yes +<pinchartl> so now you have hooked up a power supply to that board ? +<dammsan> since some time ago +<dammsan> maybe about 2 weeks ago +<dammsan> the hardware should be fine now at least [16:16] +<dammsan> (what i can tell) +<dammsan> so if the I2C devices are present +<dammsan> then there is no need for the r8a7792 blanche backup plan? [16:17] +<pinchartl> I see power connectors in the schematics indeed +<uli___> dammsan: not for my point of view. but what exactly is the r8a7792 + backup plan? +<dammsan> i hooked up an unknown camera to the r8a7792 blanche board some time + ago [16:18] +* morimoto back +<dammsan> i kind of wanted to see if some devices showed up on I2C there too +<pinchartl> uli___: you mentioned in your e-mail that you ported two drivers, + one from Cogent, one from the BSP [16:19] +<uli___> yes +<pinchartl> and that our hardware is quite different from what the first + driver support +<pinchartl> how so ? +<uli___> our hardware is connected like so: +<uli___> soc <=i2c= max9286 <=i2c= max9271 <=i2c= ov10635 [16:20] +<uli___> they support various boards, but they all have more than one chip + connected directly to the soc +<uli___> some have an i2c multiplexer [16:21] +<uli___> but none are in a straight line like ours +<pinchartl> they don't support that hardware setup ? what kind of hardware + setup do they support ? +<uli___> i think somewhere in their pile of patches there is the code from the + renesas bsp as well [16:22] +<uli___> they support boards called "kingfisher" and "view", and an unnamed + board i think +<pinchartl> so they have no direct support for our hardware platform, and + while it might not be too difficult to fix that, you decided to + use the BSP code instead ? [16:23] +<uli___> i was a bit pressed for time, and the bsp code is written for this + platform... [16:24] +<neg> where do they have the i2c multiplexer in ther setup, between the SoC + and MAX9286 chip(s)? +<pinchartl> I'm not complaining :) I'm just trying to make sure I understand + the situation correctly +<uli___> neg: i don't remember, i would have to look up the DT [16:25] +<neg> Me too, I think it's awesome you got that code working with the VIN + dirver. When I looked at that code I felt sick :-) +<neg> uli___: OK np I was just curious how it differd +<uli___> it's a pca9somethingsomething, and it's connected to the soc +<uli___> i guess they packed everything in one driver because a proper + implementation would need two additional i2c host drivers... + [16:26] +<pinchartl> yes +<pinchartl> uli___: so, when do you think you'll be able to test the code ? +<pinchartl> and, more importantly, get it to work :-) [16:27] +<uli___> test, today or tomorrow i guess. get it to work, hmmm... :) +<pinchartl> I would really appreciate if you could provide the first test + results today [16:28] +<pinchartl> I'll sleep better (or worse...) tonight +<uli___> i'll see what it does later [16:29] +<pinchartl> thank you +<pinchartl> you can send a quick e-mail to update us +<uli___> ok +<pinchartl> if everything works I'll be very happy +<pinchartl> if that's not the case, please try to describe what the problem(s) + are with as much information as possible [16:30] +<pinchartl> I'm sure Niklas can assist you with any VIN issue +<neg> sure can +<pinchartl> neg: you're next :-) [16:32] +<neg> a) Posted two VIN series '[PATCH 00/16] rcar-vin: fix issues with format + and capturing' and '[PATCH v3 00/27] rcar-vin: Add Gen3 with media + controller support' +<neg> b) Act on reviews on the posted series and try to take a stab at + extending the of graph framework to be able to iterate over all DT nodes + in a graph connected by endpoints. +<neg> c) None +<neg> d) None +<neg> if someone got review time please look at the first series as it should + be simpler to review and fixes real issues and the second one depends on + it. Also it would feel good to finaly get some VIN work merged :-) + [16:33] +<neg> ooh also in b) I will fixupo a few things for the CSI-2 driver and + repost it [16:34] +<neg> --EOT-- +<pinchartl> thank you +<pinchartl> do you feel you're on track schedule-wise ? +<neg> Yes I hope so, there are still some work to be done in the are to be + able to find, and then use the async framework to create all media + controller links for arbitrary long device chains which needs to be + sorted [16:36] +<pinchartl> ok [16:37] +<neg> problem is as we talked shortly about your holiday is how to best relay + information about pads from DT to MC +<neg> but I imagine some work is needed there in the task to fix ADV7482 + multiple subdevices [16:38] +<pinchartl> yes +<pinchartl> that's one of the nasty missing pieces +<pinchartl> have you discussed that with anyone while I was away ? +<neg> so I currently focus on exteding of graph to provied helpers to find all + DT nodes since this will be needed however the port->pad thing is solved + and it would also be used later by the device allocator API [16:39] +<neg> no I have not presude it further as the discussion with Russel King + about MC in general I feelt safer to let it cool of a bit before trying + to attack that issue +<pinchartl> I'll add the port->pad mapping to your list of issues [16:40] +<neg> thanks +<pinchartl> morimoto: you're next [16:42] +<neg> I know you must have a huge mail backlog but maybe sometime next week + you and I (and anyone else interessed ofc) can have a short chat about + it, I feel a bit lost on how to best think about the problem +<morimoto> OK +<pinchartl> neg: sure. early next week would be best for me +<kbingham> There is rumour I will be looking at some ADV7482 work based on the + chat log from the last meeting - so let me know when you have the + chat :) +<neg> thanks, I can ping you and kbingham monday then and see when would be + convinient, thanks [16:43] +* morimoto let me know if I can start ;P +<pinchartl> morimoto: please go ahead :-) +<morimoto> Hehe :O +<morimoto> s/:O/:)/ +<morimoto> A) +<morimoto> o I posted OF-graph patchset again, no response [16:44] +<morimoto> o Hacking for Sound driver bug fix +<morimoto> o Hacking for bind/unbind issue for ALSA SoC +<morimoto> o I could contact to OV guys, and discuss about OV camera + datasheet. +<morimoto> I sent you that you can receive datasheet from OmniVision, but you + can call me liar. +<morimoto> Final conclusion is that I need to export it to you. and it will + takes not short term. +<morimoto> o I asked you guys about camera board power cable, on +<morimoto> Subject: Re: CSI2 multiple subdevices development +<morimoto> Date: Wed, 22 Mar 2017 09:18:44 +0900 +<morimoto> B) [16:45] +<morimoto> o DT maintainer response is too slow +<morimoto> o I'm very x10 sad (;_;), because no response from MultiMedia group + leader (= holiday guy) for camera board cable ;P +<morimoto> C) +<morimoto> o Continue hacking for sound driver/framework +<pinchartl> :-) +<morimoto> o OV camera export paper work +<morimoto> --EOF-- +<pinchartl> thank you [16:46] +<pinchartl> so what's the situation with the OV datasheet ? do you have it ? +<morimoto> Now I have it +<morimoto> But I need to export paper work +<morimoto> (In secret, Maybe I can put it on Redmine) [16:47] +<morimoto> + https://osdr.renesas.com/projects/linux-kernel-development/wiki/Salvator-X_MAXIM_camera_board +<morimoto> (not yet) +<pinchartl> regardless of how we transfer the datasheet, it will be covered by + our NDA, so that part is fine +<morimoto> Yes [16:48] +<pinchartl> regarding the camera board cable [16:49] +<pinchartl> what's the issue ? :-) +<morimoto> issue is that whether you can use existing power cable or not + [16:51] +<morimoto> if not, I need to export power cable, but it needs more paper work +<pinchartl> let me quickly check +<morimoto> You can use Lager/Koelsh/Salvator power cable +<pinchartl> is that a regular 12V power supply with a barrel connector ? + [16:52] +<morimoto> Do you mean Lager/Koelsh/Salvator power cable ? then yes +<geertu> (2.1/5.5mm center positive) [16:53] +<pinchartl> that's easy to source +<pinchartl> no need to send them from Japan +<morimoto> Nice !! +<pinchartl> we can order power supply pretty much anywhere if needed, that + will be much faster [16:54] +<morimoto> You saved me !! +<neg> In the email you also state two power cables could be used right? One to + Salvator-X and one to the Camera board and as long as you already have + two Gen2/Gen3 power cables you are ok +<morimoto> neg: Yes +<morimoto> 1 note is that camera board doesn't have reset button [16:55] +<morimoto> You need to plug out/in for reset camera board :P +<morimoto> I think above url has such explanation +<pinchartl> do you know if the salvator-x and camera boards can be powered up + in any order, or is a specific order required to avoid damaging + the hardware ? [16:56] +<morimoto> Yes, it has special order. you can check it on above URL +<morimoto> see. Power ON order [16:57] +<pinchartl> thanks +<morimoto> And special know-how for jumper pin, too +<pinchartl> thank you [16:58] +<pinchartl> dammsan: you're next +<dammsan> nothing to report here really +<dammsan> just sent out an email regarding V2H and serial multiplexing [16:59] +<dammsan> not sure if it made it to periperi or not with the large size photo + of schematic +<dammsan> this is related to "plan b" in case ulrich can't get it going +<dammsan> apart from that nothing to report [17:00] +<pinchartl> thank you [17:01] +<pinchartl> I'm next [17:02] +<pinchartl> I've been on holidays for two weeks, so not much to report +<pinchartl> my short term plan is catching up with my e-mail backlogs and with + patch reviews +<pinchartl> kbingham: you're next [17:03] +<kbingham> Ack! +<kbingham> Nothing to report since last time, I've been working on other + projects as my Renesas budget was empty. +<kbingham> In the upcoming weeks, I expect that to replenish, and will be + getting my existing series' rebased and following up on review + comments. +<kbingham> I have a small support task for jinzai which should be solving + today, and then I will be following whatever the latest plan is on + our multimedia task force. +<kbingham> The notes from the last meeting suggest that I will be looking at + the ADV7482 sometime, but I don't know any further details about + this planned work yet. +<kbingham> -- EOT -- [17:04] +<pinchartl> thank you [17:05] +<kbingham> Any comments? Is the ADV7482 still my task in the plan? +<pinchartl> yes +<pinchartl> I propose discussing it with Niklas early next week [17:06] +<kbingham> I was about to say the same :D +<pinchartl> Monday morning or Tuesday would work best for me +<kbingham> Tuesday is better for me ... +<kbingham> But I can do monday. +<pinchartl> neg: how about you? +<neg> both work for me +<kbingham> oh wait +<kbingham> Actually I think Tuesday might be bad for me :) +* kbingham checks +<kbingham> I have to go out at 10am on Tuesday, so Monday is better :) [17:07] +<neg> so standard meeting time monday morning? +<kbingham> Can we make it 9am UK time :) [17:08] +<pinchartl> works for me +<neg> sure +<kbingham> great. +<pinchartl> I've sent you an invitation [17:09] +<kbingham> Received. [17:10] +<pinchartl> jmondi: you're next (and last) +<jmondi> thanks! [17:11] +<jmondi> few things to report since last time +<jmondi> I only spent 1 week of my time on multimedia, and I have ported the + DRM/KMS test application to gen 3 +<jmondi> not tested with VIN patches yet +<jmondi> but I have closed pinchartl review comments on last version [17:12] +<jmondi> I should send out an email with details probably... +<pinchartl> that would be nice +<jmondi> apart from that not much, still waiting to have a more defined plan + for next months, where I should be all about multimedia +<pinchartl> thank you [17:13] +<jmondi> I guess the OV datasheet export issue has impact on me, as I was + supposed to work on ov10(don't remember name) sensor, right? +<pinchartl> correct [17:14] +<pinchartl> morimoto: maybe the datasheet should appear magically on a server + somewhere +<pinchartl> nobody will know where it came from [17:15] +<pinchartl> and nobody will ask any question +<jmondi> for just a few minutes maybe? +<pinchartl> life will be good, everybody will be happy +<morimoto> pinchartl: actually, it will takes long term for export [17:16] +<morimoto> but, I can put it on Redmine if I can be guilty guy [17:17] +<pinchartl> nobody will tell :-) +<morimoto> Hehe :) +<morimoto> jmondi: when do you need it ? immediately ? [17:18] +<jmondi> morimoto: the sooner the better +<morimoto> OK... +<jmondi> since we're both online, you can upload and delete in 5 minutes +<morimoto> Please pray that no stone-head guys come here :) +<pinchartl> there's usually an application note that goes with the OV sensors + datasheets +<pinchartl> if you have to too, it would be nice to get it +<morimoto> It will be formal, but not yet now +* kbingham grabbed a copy to see too :) [17:22] +<pinchartl> no problem +<morimoto> I only have datasheets, not application note +<pinchartl> that closes the first topic +<pinchartl> Topic 2. Multimedia plan +<morimoto> If you need it, I can ask to OmniVision guy +<pinchartl> dammsan: what's the status of base contracts and additional tasks + for Q2 ? +<pinchartl> morimoto: it would be nice to get it, the datasheet usually lacks + important information that is present in the application note +<morimoto> pinchartl: OK, will do [17:23] +<morimoto> neg: I will delete datasheet, are you OK ? +<neg> yes [17:24] +<neg> thanks, and what datasheet :-) +<dammsan> pinchartl: the base tasks have been submitted, waiting for + processing [17:25] +<dammsan> additional tasks +<pinchartl> do you expect any issue or delay for the base tasks ? +<dammsan> not really +<dammsan> i think the only unknown is that camera prototype at this point +* morimoto bye-bye datasheet [17:26] +<dammsan> i expect base tasks to be ready this week +<pinchartl> ok +<pinchartl> how about the additional tasks ? [17:27] +<dammsan> i think your idea with the shared more generic task description is + good +<dammsan> so i would like to proceed with that [17:28] +<dammsan> however, i would like to know that we at least have _something_ that + works first +<pinchartl> uli___: I think there's a bit of pressure on you :-) [17:29] +<dammsan> from my side, we can be blocked on several other random issues + before we get there +<pinchartl> but in any case we have to go in that direction +<dammsan> (who knows, another power supply needed or perhaps some jumper is + missing) +<pinchartl> which is why I want more generic tasks [17:30] +<pinchartl> to handle the issues as we progress +<dammsan> sure +<dammsan> i mainly want results myself =) +<pinchartl> have you submitted the generic task proposal internally to Renesas + to get their feedback ? [17:31] +<dammsan> nope +<dammsan> we've been busy with base tasks +<pinchartl> Q2 starts next week, and I think everybody is getting nervous + [17:32] +<dammsan> this is why we have the base tasks +<dammsan> i would have preferred to have overlapping ones myself +<dammsan> but hey +<pinchartl> how would you like to proceed ? +<dammsan> i want to get the updated result from the camera prototype [17:33] +<dammsan> i propose that we revisit next week, hopefully some update is + available then? +<dammsan> that should have sorted out the base tasks too +<pinchartl> ok [17:34] +<pinchartl> by the way +<pinchartl> morimoto: what's the status about the hardware setup that should + be sent to Europe ? [17:35] +<dammsan> in the mean time, lets do ping-pong-email you and me in case some + detail need to be adjusted in the additional task descripiton +<morimoto> pinchartl: camera board ? [17:36] +<pinchartl> morimoto: yes [17:37] +<morimoto> camera *board* I already have +<morimoto> camera itself will be arrive at 5 +<morimoto> 5 = May +<pinchartl> at 5 ? 5pm today ? :-) +<pinchartl> ok +<uli___> 5pm in may +<pinchartl> when in May ? +<morimoto> Hehe +<morimoto> Don't know, just "May" [17:38] +<pinchartl> so potentially we won't have access to local hardware before end + of May ? +<morimoto> Unfortunately +<jmondi> we can pick them at LCJ directly :/ [17:39] +<pinchartl> ok +<morimoto> jmondi: Unfortunately, it is not allowed +<pinchartl> that's not very nice, but we have no choice +<pinchartl> how comes the camera will arrive so late ? is it because of the + lead time from the manufacturer ? +<morimoto> I'm not sure, I know is that it will came from Philippine [17:40] +<pinchartl> who's the manufacturer ? do you have a model number ? [17:41] +<morimoto> Module name is "RDACM20-01" [17:42] +<pinchartl> thank you +<morimoto> manufacturer seems... IMI Japan [17:43] +<pinchartl> I don't think it makes sense to really update the multimedia plan + at this point before we have results from Ulrich's work + [17:45] +<pinchartl> uli___: is there any way we can help to speed it up ? +<uli___> during this meeting i have received an e-mail from my tax guy, who + has failed to do my taxes for 2015, which are at the absolute latest + due tomorrow, until now [17:46] +<uli___> i need to look up some documents +<geertu> http://www.global-imi.com/about-imi/global-facilities/ does not list + Japan. But it does list Czech Republic and Bulgaria +<uli___> i'm afraid that has 110% priority +<uli___> i'll still try to do the test today, though +<pinchartl> uli___: let's discuss the results tomorrow morning then [17:47] +<uli___> ok +<pinchartl> Topic 3. Meeting around LinuxCon Japan [17:48] +<pinchartl> we have agreed on dates for the trip [17:49] +<pinchartl> with a VIN code camp with local hardware access on the 29th and + 30th of May +<pinchartl> so far no meeting with the BSP team is scheduled, as no need to + have such a meeting has been expressed [17:50] +<pinchartl> morimoto: dammsan: does that still hold ? or do you think we + should organize a meeting ? +<morimoto> pinchartl: no plan with BSP team meeting at this point. [17:51] +<dammsan> pincharl: we should go out for drinks together at least =) [17:52] +<pinchartl> dammsan: of course :-) +<pinchartl> I'd like to spend as much time coding as possible [17:53] +<pinchartl> so if meetings are needed, I'd like to know ASAP +<dammsan> makes sense +<neg> I would also like to book my trip soonish :-) +* jmondi too ^ [17:54] +<kbingham> Yes, flights have increased in price by 30% already here I think. +<kbingham> (google keeps telling me when the price changes) +<kbingham> Of course that could just be because the £ has decreased in value + :) [17:55] +<neg> I think I managed to clear my previous date troubles so I should be + avaliable from/to both weekends before and after and be happy to stay + both if other ppl are around for code or drinking sessions ;-) +<pinchartl> neg: \o/ +<jmondi> neg: you're talking about the May 27th/28th weekend and June 3rd/4th, + right? [17:56] +<pinchartl> morimoto: persmission to book flights then ? +<kbingham> I can do before much easier than after :) [17:57] +<neg> jmondi: yes +<morimoto> pinchartl: sorry, what do you mean? +<pinchartl> morimoto: can we go ahead and book flights for the week in Japan ? + and can we invoice them to Jinso ? [17:58] +<morimoto> Ahh, OK. I will ask to our boss, please wait +<pinchartl> thank you [18:00] +<pinchartl> last topic, next meeting +<pinchartl> I propose two weeks from now [18:01] +<pinchartl> Tuesday the 11th of April +<jmondi> works for me I guess +<pinchartl> at 8:00 GMT / 09:00 CEST / 10:00 EEST / 16:00 JST +<pinchartl> (usual time) +<dammsan> sounds good +<kbingham> Ack here. [18:02] +<pinchartl> good, I'll send the invite now +<morimoto> pinchartl: how many people caming to Japan ? +<pinchartl> morimoto: Ulrich can't make it, so that would be Jacopo, Kieran, + Niklas and me +<morimoto> And Core/IO group member ? [18:03] +<neg> date works for me +<geertu> pinchartl: You really want to conflict with all future Core Meetings? +<pinchartl> morimoto: I don't know about Gert or Wolfram's plans for LCJ +<pinchartl> geertu: good point +<pinchartl> should we make it Wednesday the 12th ? +<geertu> pinchartl: What happened with the MM meetings on Wednesdays? +<pinchartl> geertu: lack of sleep I think :-) [18:04] +<pinchartl> we've switched this week, but let's go back to the original + schedule +<pinchartl> so Wednesday the 12th +<pinchartl> at 8:00 GMT / 09:00 CEST / 10:00 EEST / 16:00 JST +<dammsan> gotcha [18:05] +<pinchartl> I propose closing this meeting +<pinchartl> does anyone second? +<geertu> pinchartl: Thank you! +<morimoto> pinchartl: about trip budget, maybe OK +<pinchartl> geertu: you're welcome +<morimoto> pinchartl: about 4/12 2nd [18:06] +<pinchartl> 4/12 2nd ? +<morimoto> s/2nd/second/ +<morimoto> I mean OK for 4/12 meeting [18:07] +<pinchartl> :-) +<kbingham> 4th December is a bit late :D +<pinchartl> perfect +<pinchartl> thank you all for attending +<pinchartl> and have a nice day +<kbingham> Cheers all +<neg> thanks all +<morimoto> kbingham: oops, 4/12 = 4th December in Europe, it is April, 12th in + Japan ;P [18:08] +<jmondi> cheers! see you +<morimoto> thanks diff --git a/wiki/Chat_log/20170329-core-chatlog b/wiki/Chat_log/20170329-core-chatlog new file mode 100644 index 0000000..154230e --- /dev/null +++ b/wiki/Chat_log/20170329-core-chatlog @@ -0,0 +1,362 @@ +Core-chat-meeting-2017-03-29 + +10:07 < geertu> Welcome to today's Core Group Chat! +10:07 < geertu> Agenda: +10:07 < geertu> 1. Status updates +10:07 < geertu> 2. PFC drivers for RZ/G1 +10:07 < geertu> 3. Additional tasks for 2017/Q2 phase 1 +10:07 < geertu> Topic 1. Status updates +10:07 < geertu> A) What have I done since last time +10:07 < geertu> B) What I plan to do till next time +10:07 < geertu> C) Problems I have currently +10:07 < geertu> D) Posted/Accepted bugfix patches +10:07 < geertu> $(sort -r) says Simon is first +10:09 < horms> todo update: NULL +10:09 < horms> A) What have I done since last time +10:09 < horms> - No core tasks at this time; no updates +10:09 < horms> B) What I plan to do till next time +10:09 < horms> - Nothing for Core +10:09 < horms> C) Problems I have currently +10:09 < horms> - None +10:09 < horms> -- end -- +10:10 < geertu> Thank you Simon. +10:10 < geertu> Next is Shimoda-san +10:11 < shimoda> A) +10:11 < shimoda> - Nothing because I focused I/O group things (USB). +10:11 < shimoda> B) +10:11 < shimoda> - I will make/submit a workaround patch with whilelist. +10:11 < shimoda> C) +10:11 < shimoda> - Nothing. +10:11 < shimoda> D) +10:11 < shimoda> - Nothing. +10:12 < shimoda> -- end -- +10:12 < geertu> Thank you Shimoda-san! +10:12 < geertu> Next is Niklas +10:12 < neg> a) Posted patches for rcar-dmac resource freeing synchronization +10:12 < neg> b) Noting planed (yet) +10:13 < neg> c) None +10:13 < neg> d) None +10:13 < neg> --EOT-- +10:13 < geertu> Thank you Niklas! +10:13 < geertu> Next is Morimoto-san. I'll tell you what he mailed me: +10:14 < geertu> A) +10:14 < geertu> - I posted "SYS-DMAC + ARM64 + 40bit address + Descriptor Mode" patch, +10:14 < geertu> and it was accepted (see below for peripelist patch). +10:14 < geertu> - R-Car Gen3 datasheet export paper work for extended period +10:14 < geertu> B) +10:14 < geertu> - Nothing for Core +10:14 < geertu> C) +10:14 < geertu> - No hacking time +10:14 < geertu> D) +10:14 < geertu> - Nothing +10:14 < geertu> --EOT-- +10:15 < geertu> Next is Marek +10:15 < Marex> A) NULL +10:15 < Marex> B) Discuss VC6 and Rohm PMIC with geertu +10:15 < Marex> C) NULL +10:15 < Marex> D) NULL +10:15 < geertu> Thank you, Marek! +10:16 < geertu> Next is Magnus +10:16 < dammsan> A) Some initial update of the IPMMU driver stuff, not posted yet. And IPMMU USB integration. +10:16 < dammsan> B) Keep on hitting my head against the IPMMU driver code base +10:17 < dammsan> C) and D) Nothing +10:17 < geertu> Thank you, Magnus! +10:18 < geertu> Next is Laurent +10:18 < pinchartl> nothing to report, I'm just lurking +10:19 < geertu> Thank you, Laurent! +10:19 < geertu> Next is Jacopo +10:19 < jmondi> A) What have I done since last time +10:19 < jmondi> - 2 rounds of RZ/A1 PFC +10:19 < jmondi> - added ethernet to PFC devices +10:19 < jmondi> - tested RTC patches from Chris (not working on Genmai yet: probably my bad) +10:19 < jmondi> - Killed a GR-PEACH due to poor soldering abilities +10:20 < jmondi> B) What I plan to do +10:20 < jmondi> - close LinusW review feedback and have rz/a1 merged +10:20 < jmondi> - make rtc patches work on Genmai +10:20 < jmondi> - have a new Core/IO task assigned +10:20 < jmondi> C) = D) = NULL +10:20 < jmondi> -- eot -- +10:21 < geertu> Thank you, Jacopo! Sorry to hear about the GR-PEACH +10:21 < jmondi> my bad :) +10:21 < geertu> Next (last) is Geert +10:21 < geertu> A) What have I done since last time +10:21 < geertu> - v2 of resets for R-Car H3 and M3-W DTS +10:21 < geertu> - v2 of DTS for R-Car H3 ES2.0 +10:21 < geertu> - Reviewed physical pins of R-Car H3 SiP ES2.0 for PFC +10:22 < geertu> B) What I plan to do till next time +10:22 < geertu> - Finish R-Car H3 ES2.0: +10:22 < geertu> - Send pull request for clk +10:22 < geertu> - v3 of pfc (rename pfc-r8a7795es1.c to pfc-r8a7795-es1.c, cfr. BSP) +10:22 < geertu> + queue and pull request +10:22 < geertu> - v2 of soc_device_match() fixes + pull request for Greg / Arnd / Simon +10:22 < geertu> - Send pull request for rcar-sysc +10:22 < geertu> - R-Car Gen2 CPG/MSSR +10:22 < geertu> - DTS sharing on H3 ES1.x/ES2.0, Salvator-X/ULCB +10:22 < geertu> C) Problems I have currently +10:22 < geertu> - None +10:22 < geertu> D) Posted/Accepted bugfix patches +10:22 < geertu> - Clock fixes detected during R-Car Gen2 CPG/MSSR conversion +10:22 < geertu> - [PATCH] backlight: pwm_bl: Fix GPIO out for unimplemented .get_direction() +10:22 < geertu> - [PATCH v2 0/3] serial: sh-sci: Assorted flow control fixes +10:22 < geertu> (yes, these are really I/O, but better report them early, Wolfram is lurking anyway ;-) +10:22 < wsa_> :D +10:22 < geertu> --eot-- +10:23 < geertu> Topic 2. PFC drivers for RZ/G1 +10:23 < geertu> Cogent (Sergei) is preparing the upstreaming of the PFC drivers for r8a7743 +10:23 < geertu> (RZ/G1M) and r8a7745 (RZ/G1E). +10:23 < geertu> To avoid adding and maintaining 20 kLoC of new pinctrl code, I would like +10:23 < geertu> to reuse the existing drivers for R-Car M2-W and E2. +10:23 < geertu> While RZ/G1 supports less hardware than R-Car Gen2, my point is that if a +10:23 < geertu> device does not exist in r8a7743.dtsi or r8a7745.dtsi, you won't set up +10:23 < geertu> pinctrl for pins/groups/functions for that device, and thus won't use +10:23 < geertu> nonexisting PFC enums. +10:23 < dammsan> makes complete sense +10:23 < geertu> Sergei wants to make sure that adding further support for non-existing +10:23 < geertu> devices won't be possible, and thus wants to have separate drivers. +10:24 < dammsan> as opposed to +10:24 < geertu> Lately, it seems Sergei is becoming convinced. +10:25 < geertu> But perhaps only because I (wearing my sh-pfc hat) have to accept his patches... +10:25 < geertu> Unfortunately, he has less (different) information than we have, cfr. his resistance. +10:26 < geertu> It may be easier if we can share some information with him. +10:26 < dammsan> this different information, i wonder if we can work on that to improve things +10:27 < dammsan> of course sharing info would be nice, but i don't see how that will happen with the different ordering schemes and NDAs and whatnot +10:28 < dammsan> what is he missing? +10:28 < dammsan> (apart from the obvious =) =) =) +10:29 < geertu> However, a nice side-effect of his uninformedness is that he's rigorously comparing r8a7743 and r8a7791 PFC, and discovering bugs in pfc-r8a7791.c +10:29 < dammsan> well that is good +10:31 < dammsan> i think that trying to validate the DT from within a driver is not a very good approach +10:31 < dammsan> basic integration assumes that you input the right stuff into DTS including address ranges, interrupts and of course also pins +10:32 < dammsan> seems that he prefers to do some validation somehow, or perhaps i misunderstand +10:33 < geertu> dammsan: I think the only extra validation he can gain from using a separate driver is the ability to reject pin groups for on-SoC devices that are not documented in the RZ/G1 datasheet. +10:33 < horms> surely the dt describes the hardware and the driver implements some set of features which may overlap with what is described in dt +10:35 < geertu> dammsan: For a specific on-SoC device, I think the pins, groups, and functions will be the same. +10:35 < dammsan> i guess not duplicating information makes sense for sure +10:35 < dammsan> so not duplicating PFC information in different files must be correct +10:35 < geertu> Sure. +10:36 < dammsan> however one question is if the existing PFC code shall take SoC compat string into consideration and reject invalid stuff somehow +10:36 < dammsan> using the same kind of table +10:36 < geertu> It's just a bit difficult to explain the sharing to people not aware of the details. +10:36 < dammsan> yeah i understand +10:37 < dammsan> if it is useful then it seems like a per-soc feature flag or something +10:37 < geertu> That's definitely a possibility. But what would be the gain? It's not like people are gonna configure pinctrl for a function that has no corresponding device name in the SoC-specific dtsi +10:37 < dammsan> horms: can you explain about the overlap in driver vs DT in more detail? +10:37 < geertu> s/device name/devcie node/ +10:38 < dammsan> geertu: i agree +10:38 < geertu> s/device name/device node/ +10:38 < dammsan> if someone copy-pastes DTS wrong and it enables the wrong PFC combo then so be it +10:38 < dammsan> it is like assigning wrong IRQ number in DTS +10:39 < dammsan> simply dont do that +10:39 < horms> I meant; DT could conceivably ask for features that are not yet implemented in the driver (maybe not). And the driver can implement features not used on a particular bit of hw - in which case DT shouldn't ask for them. +10:39 < Marex> indeed, DT is not kindergarten ... +10:39 < horms> copy paste is a big problem for DT; its almost like the system is broken by design +10:40 < Marex> horms: the system is OK, uninformed integrators are the problem here and that cannot really be easily fixed +10:40 < horms> sure, but it is easy to make misakes +10:40 < horms> regardless, i don't think its the role of the driver to verify dt +10:40 < Marex> +1 +10:40 -!- morimoto [~user@relprex1.renesas.com] has joined #periperi +10:41 < dammsan> in most cases the driver cant even judge right from wrong +10:41 < dammsan> and spending extra cycles doing so seems stupid +10:41 < geertu> horms: It's not, but in this case (PFC), the pin group/function names are technically part of the binding. +10:41 < horms> I guess one risk is that someone might enable something on RZ/G1, which is documented not to exist but is implemented in the driver for R-Car, and then discover it does exist on RX/G1 +10:42 < horms> perhaps this is where Sergei's concern lies +10:42 < horms> I imagine that would conflict with Renesas's marketing goals +10:42 < horms> geertu: ok, i had missed that point +10:42 < neg> One drawback if it's shared is that the debugfs interface will show pins/groups that or not valid for the SoC in question +10:42 < geertu> horms: That someone has to add something to r8a774[34].dtsi first, too +10:43 < horms> sure, but that wouldn't be a problem from a maketing pov +10:43 < horms> anyway, its a non-technical reason +10:43 < geertu> neg: True, hadn't thought about debugfs +10:44 < dammsan> having a list of pin functions available together with compat string matching can't be that difficult +10:44 < dammsan> sergei might even be able to implement it himself +10:45 < geertu> neg: That would be limited to the pinmux_groups[] and pinmux_functions[] arrays +10:45 < dammsan> if he feels strongly about it +10:46 < dammsan> i wonder if the relationship beween M2 and RZ-G is similar to H3 ES2 and M3? +10:46 < horms> it could even be done in parallel with other tasks he may have +10:46 < horms> as i wouldn't think it blocks forward progress +10:46 < geertu> neg: we could sort it (common entries first, RZ/G1 entries last), and change sh_pfc_soc_info.nr_{groups,functions} based on compatible value. +10:46 < dammsan> especially since it goes backwards =) +10:47 < dammsan> horms: jokes aside i agree with you +10:47 < horms> we could ask him to implement it sideways :) +10:47 * geertu may be thinking too much about kernel size +10:47 < horms> I wondered about that too +10:48 < neg> geertu: yes that would work, is the pinmux_pins arrays equal on both SoC ? +10:48 < geertu> neg: I expect it is, both SoCs have the same package and nr. of pins, according to the Renesas website +10:49 < neg> that is good, then yes having some magic for the pinmux_groups[] and pinmux_functions[] would then take care of the debugfs issue +10:51 < geertu> Having separate pinmux_groups[] and pinmux_functions[] arrays would waste ca. 6 KiB +10:51 < geertu> so runtime patching may be worth it. +10:56 < geertu> We could also #ifdef out the various *_pins[] and *_groups[] on kernels not including support for r8a7791. +10:56 < dammsan> geertu: i wonder if the package type may limit exposed pins too on G1M compared to M2-W +10:56 < geertu> dammsan: renesas.com says they have the same package +10:59 < geertu> M2-W: 831 pin Flip Chip BGA (27 mm × 27 mm) +10:59 < dammsan> ok then i'm silent =) +10:59 < geertu> G1M: 831 HBGA (I'm quite sure that used to say Flip Chip BGA, too) +11:00 < geertu> E2: 501-pin Flip Chip BGA (21 mm × 21 mm) +11:00 < geertu> G1E: 501 HBGA +11:01 < dammsan> ok thanks! +11:02 < geertu> OK, I'll ask Sergei to use a separate sh_pfc_soc_info with different pinmux_groups/pinmux_functions +11:02 < neg> Did we not use to have runtime patching for Gen3 ES versions previusly? But now that I look in renesas-drivers I can't find it. In any case is that not something we can reuse? +11:02 < geertu> We have the infrastructure in place for handling that for H3 ES2 +11:02 < geertu> neg: Just the .init() callback to override something +11:03 < geertu> neg: patches of the tables is done for clk and rcar-sysc only. +11:03 < neg> I see +11:07 < geertu> Shall we continue? +11:08 < geertu> Topic 3. Additional tasks for 2017/Q2 phase 1 +11:08 < geertu> So far I have: +11:08 < geertu> Gen2,?,plan,geert,Migrate R-Car Gen2 to CPG/MSSR +11:08 < geertu> generic,?,plan,geert,DTS sharing on H3 ES1.x/ES2.0, Salvator-X/ULCB +11:08 < geertu> RCAR-DMAC,?,plan,niklas,Add transfer termination synchronization +11:08 < geertu> Salvator-X,?,plan,marek,BD9571 PMIC driver +11:08 < geertu> It would be good if someone could take over from Khiem: +11:08 < geertu> CPUFreq,v4.12,public,khiem,R-Car Gen3 CPUFreq support +11:08 < horms> I would be happy to look into that if there are no other takers +11:08 < geertu> Patches for that are pubic (with some comments), and in the BSP +11:09 < geertu> Once the PMIC driver is there, we can start doing DVFS +11:09 < geertu> Jacopo worked on the monitoring part using max9611 +11:09 < geertu> So perhaps he's interested as well? +11:09 < wsa_> simon: do you also have room then for the SDHI DMA refactoring task? +11:10 < wsa_> and interest? :) +11:10 < jmondi> geertu: I am :) +11:11 < neg> If horms have too much IO work I can also look at Khiems CPUFreq work +11:11 < Marex> geertu: so what do we do with the PMIC ? And what about the VC6 ? :) +11:12 < horms> Perhaps if I took the SDHI DMA refactoring task and neg could take CPUFreq? +11:13 < wsa_> neg: speaking of IO, there are also "emergency shutdown" and "WakeOnLan for Gen3" tasks for which you have some previous attachment ;) +11:13 < geertu> Marex: I thought you were going to take care of the PMIC, cfr. above? :-) +11:13 < wsa_> neg: but if you are busy, they might be interesting for Jacopo as well? +11:13 < geertu> Marex: VC6 will have to wait for board availability, as the board is expected to arrive before Digi-Key has VC6 devboard stock +11:14 < pinchartl> geertu: if I may, I'd like to discuss how to allocate developers to tasks across groups in a better way than "first group leader who asks will get developers" +11:14 < neg> wsa_: Yes I was hopping to do 'emergency shutdown' for IO sometime during Q2 but WoL for Gen3 is also a possibility +11:14 < pinchartl> there's lots of work to be done on multimedia, and I'm sure core and I/O are nont different from that point of view +11:15 < pinchartl> I could just chime in and say that I need Niklas and Jacopo full time, but that wouldn't be very nice to you :-) +11:15 < pinchartl> so how can we do better ? +11:15 < dammsan> pinchartl: +11:16 < geertu> Ah, the load balancer among groups has arrived ;-) +11:16 < dammsan> i think you may have the most complex dependencies +11:17 < Marex> geertu: got it +11:17 < pinchartl> dammsan: possibly (although I don't want to make it a contest :-)) +11:17 < Marex> geertu: sorry, got a little stuck discussing how to fix jmondi's peach +11:17 < dammsan> noneed =) +11:17 < pinchartl> dammsan: so how can we proceed ? +11:18 < pinchartl> I can't plan anything ahead if at the last minute I have to do with half of the developers I thought could work on multimedia +11:18 < dammsan> in case we have some super emergency in some group we nee +11:18 < pinchartl> so I need a way to plan ahead +11:18 < dammsan> d to allocate based on that +11:18 < geertu> pinchartl: So we need to increase base allocation? +11:18 < pinchartl> you told me yesterday during the multimedia meeting that you wanted to wait before assigning additional tasks for the multimedia group +11:18 < pinchartl> so core and I/O will come first +11:19 < pinchartl> and I'll be left without anyone +11:19 < dammsan> however, i would like to decide based on how each guy +11:19 < dammsan> prefers to work really +11:19 < dammsan> pinchartl: i don't think anyone will steal all the developers +11:19 < pinchartl> if you want me to plan ahead and stick to the plan, I need to know in advance who will be available +11:19 < dammsan> but without working hardware platform it is kind of hard to start a big project +11:19 < wsa_> pinchartl: for me, it is not about "coming first". My picture of the meeting today is that we are all here and discuss how to proceed +11:19 < geertu> marex: 800-3138-ND stil has 18 weeks lead time, 12/6/2016 - Delivery Date Past Due - Contact Digi-Key +11:20 < dammsan> right +11:20 < pinchartl> wsa_: the issue is that we allocate tasks seperately for each group +11:20 < Marex> geertu: yeah :( +11:20 < dammsan> so i would like each developer to join at least two groups +11:21 < dammsan> and in a perfect world i think additional tasks from two groups should be handled +11:21 < geertu> Marex: Buy a 5P49V6901A and put it on a protoboard? +11:21 < wsa_> pinchartl: my hope is that today we will do it differently +11:21 < pinchartl> dammsan: we're talking about half a quarter of additional tasks, so that's 60 / 2 / 2 = 15 days +11:21 < pinchartl> joining two groups seems quite dubious to me with such a short amount of time +11:22 < dammsan> pinchartl: it is possible to assign more than one batch of work too +11:22 < wsa_> one problem is, I don't know priorities from other groups, so I'd like to know about those as well +11:22 < dammsan> it depends on the kind of task +11:22 < dammsan> neg: how would you like to spend your time? =) +11:22 < wsa_> I mainly threw in the topics I have, so people know what is around +11:22 < Marex> geertu: well I can immediatelly get me a 6901 in a VFQFPN +11:22 < wsa_> I'd prefer if we can agree on priorities together +11:22 < pinchartl> 5 days tasks really don't make sense in most cases. the scheduling overhead is too large +11:22 < Marex> geertu: I guess I could wirebond it to a breadboard ... +11:22 < pinchartl> wsa_: I agree +11:23 < neg> dammsan: I would like to help as much as possible where the need is greatest. But I also like to if possible have tasks from two groups +11:23 < pinchartl> that would require a whole team meeting though +11:23 < dammsan> neg: so in case more work is needed for multimedia then perhaps allocating mroe slots there makes sense +11:24 < Marex> geertu: problem might be the external components ^_^' +11:24 < neg> dammsan: I also have quiet a lot of base-task time in April which currently is not fully allocated to tasks so I can do some tasks in that timeframe +11:24 < dammsan> makes sense +11:25 < dammsan> so the number of Core and I/O tasks are that not many, are they? +11:25 < wsa_> neg: how about doing "emergency shutdown" as a base task then? +11:25 < wsa_> neg: as I understood, you'd like to do that, and from my side it has not the highes priority +11:26 < neg> wsa_: sounds good to me, but if it's not high prio I can do something else as part of my base. Only problem is that IO is not listed as a group I should do work for in my base contract ATM +11:27 < dammsan> geertu: do you have some tasks that will cause delays for everyone if they are not executed before other groups? +11:27 < dammsan> PFC/CPG/SYSC something +11:28 < dammsan> i think not +11:28 < geertu> dammsan: I don't think I have any urgent core tasks +11:28 < neg> One crazy idea is to allocate more base contract time to multimeda tasks since there are so many dependecies there to provied flexability and do less complex tasks as additional contracts? +11:28 < dammsan> neg: whatever rocks your boat +11:28 < geertu> So "additional" is for the already-known tasks, and "base +11:28 < geertu> " for the unexpected ;-) +11:29 < pinchartl> neg: the proposal for multimedia additional tasks is already quite generic, so it's not very different from the base contract in that regard +11:29 < dammsan> geertu: ok, nothing urgent +11:29 < pinchartl> if we want detailed additional tasks, at this point of time I'd prefer using them for core or I/O +11:29 < pinchartl> I personally don't care in which report a patch will be included +11:30 < pinchartl> my concern is getting the work done in time +11:30 < dammsan> pinchartl: totally agree +11:31 < dammsan> neg: so how about assigning one slot of additional task per group per quarter? and base goes mainly to multimedia? +11:32 < neg> works for me. most setups works for me, as long as everyone is happy so am I +11:32 < dammsan> just a random proposal +11:32 < pinchartl> dammsan: personally I wouldn't agree to have a 5 days additional multimedia task as it would become too painful from a report overhead point of view, but if people want to bother, I don't care +11:32 < pinchartl> (good luck coming up with deliverables that jinzai could test though) +11:32 < dammsan> pinchartl: doesn't it depend on what kaind of task? +11:33 < dammsan> say a prototype to get that V2H camera going? +11:33 < pinchartl> dammsan: generally speaking it does, but with the tasks we have now, there's nothing suitable for 5 days +11:33 < dammsan> you can achieve a lot with 5 days +11:33 < pinchartl> you can write a report in 5 days, yes +11:34 < dammsan> perhaps it is possible to reduce the complexity of the reporting =) +11:34 < pinchartl> with a 5 days task I personally allocate at least 20% of the time to the report +11:34 < pinchartl> that's way too much +11:34 < dammsan> i agree +11:34 < pinchartl> (and with the time I spend negotiating the task descriptions with you, it goes to 30%) +11:34 < dammsan> if it takes more than one hour then something i wrong IMO +11:34 < dammsan> pinchartl: the task negotiation time is part of your base task as group leader +11:34 < pinchartl> beside, jinzai is pretty much useless when testing deliverables +11:35 < pinchartl> so it's really wasted time +11:35 < dammsan> it depends on what kind of task it is +11:35 < dammsan> no need to make it more complex than it has to be +11:35 < pinchartl> we've been making things more and more complex over time for the past 12 months ;-) +11:35 < dammsan> so lets try to make it easier to move +11:36 < wsa_> same here with 20%, an actually useful elinux page needs time +11:36 < dammsan> i feel this might be the case mainly for multimedia +11:36 < wsa_> they are not bad, though, but they do need time +11:36 < dammsan> wsa_: i didn't mean to include the wiki in that reporting time +11:36 < dammsan> not all tasks require wiki edit +11:36 < dammsan> some do +11:37 < dammsan> it is up to discussion when we make the tasks +11:37 < wsa_> i see +11:37 < dammsan> i was mainly counting time for the PDF report to jinzai +11:37 < pinchartl> dammsan: my concern isn't so much about time needed to write documentation or reports. it's roughly a fixed amount of time. with a 15 days task, the overhead is acceptable. with a 5 days task, it isn't +11:37 < dammsan> ok if you say so +11:38 < dammsan> last time i got a contiguous 5 days to work on something was a loong time ago +11:38 < dammsan> so i feel it would be a great luxury +11:38 < pinchartl> see, that's the problem :-) +11:38 < dammsan> but it is perhaps just me +11:38 < pinchartl> we have too much scheduling overhead +11:38 < pinchartl> no, it's not just you +11:39 < dammsan> ok that's good to know =) +11:39 < dammsan> so i wonder what the other members think? +11:39 < dammsan> especially the group leaders +11:40 < horms> fwiw, I agree there tends to be quite a lot of reporting overhead for extra tasks, especially 5 day ones +11:40 < dammsan> horms: even if you exclude wiki and testing? +11:40 < wsa_> when speaking about the tasks themselves, i assume IO tasks are better suited to 5 days contracts +11:40 < geertu> testing needs to be done. +11:40 < geertu> wiki can be useful (depending on the task) +11:40 < horms> dammsan: not if excluded wiki and testing +11:41 < dammsan> horms: right then we agree i think +11:41 < dammsan> so if we need wiki and testing included then 5 days is pushing it +11:41 < pinchartl> dammsan: don't forget to include babysitting jinzai in the overhead :-) +11:41 < pinchartl> I don't know if it happens to the other groups too +11:42 < dammsan> pinchartl: the multimedia group has the most complex dependencies and most code not-yet-upstream +11:42 < wsa_> plain reporting (excluding wiki and testing) is OK +11:42 < wsa_> it's the testing and documentation which fragments the 5 days tasks for me +11:42 < dammsan> so allocate two slots if testing and wiki is needed +11:43 < dammsan> end of story =) +11:43 < wsa_> aye aye, sir +11:43 < geertu> Sorry, guys, I have to go. +11:43 < geertu> Shall we conclude the official meeting? +11:43 < dammsan> i still think that there is plenty to do with 5 days in case you do some feature or protoype without additional documentation and testing +11:43 < dammsan> sure +11:44 < geertu> For next meeting, I propose Tuesday, April 11, same time +11:44 < jmondi> I have to leave in ~20 mins as well... I would like to write down what's my contract situation for next quarter, so group leaders know what I can do and when.. Can I? +11:44 < geertu> Thanks for joining, have a nice continued day! diff --git a/wiki/Chat_log/20170411-core-chatlog b/wiki/Chat_log/20170411-core-chatlog new file mode 100644 index 0000000..3bb4208 --- /dev/null +++ b/wiki/Chat_log/20170411-core-chatlog @@ -0,0 +1,169 @@ +Core-chat-meeting-2017-04-11 + +10:03 < geertu> Welcome to today's Core Group Chat! +10:03 < geertu> Agenda: +10:03 < geertu> 1. Status updates +10:04 < geertu> Topic 1. Status updates +10:04 < geertu> First is Niklas +10:05 < geertu> A) What have I done since last time +10:05 < geertu> B) What I plan to do till next time +10:05 < geertu> C) Problems I have currently +10:05 < geertu> D) Posted/Accepted bugfix patches +10:06 < neg> a) Nothing for core +10:06 < neg> b) Hope to pick something new from core TODO +10:06 < neg> c) None +10:06 < neg> d) None +10:06 < neg> --eot-- +10:07 < geertu> Thank you, Niklas +10:07 < geertu> Next is Jacopo +10:07 < jmondi> let me retreive the email I sent +10:07 < jmondi> A) +10:08 < jmondi> - v4 of RZ pin controller +10:08 < jmondi> - RZ clock tested and enabled on Genmai +10:08 < jmondi> - tested pin controller driver with DT overlays +10:08 < jmondi> - working on using JTAG debugger on Genmai +10:09 < geertu> So it's v4, not v5? +10:09 < jmondi> B) = C) = D) = NULL +10:09 < jmondi> geertu: I wrote v5 in the email, but I got confused +10:09 < jmondi> it's v4 +10:09 < jmondi> -- eot -- +10:10 < geertu> Thank you, Jacopo. +10:10 < geertu> Next is Laurent. I assume he's just lurking around? +10:10 < pinchartl> correct +10:10 < pinchartl> I have no core task +10:10 < geertu> Next is Morimoto-san +10:11 < morimoto> A) What have I done since last time +10:11 < morimoto> I posted "SYS-DMAC + 40bit + descriptor mode" patch to ML, and it was accepted. +10:11 < morimoto> I created/fixed periupport script. I hope it is now useful :) +10:11 < morimoto> I updated "R-Car Gen3 datasheet" export paper work (Not related to PeriPeri Member/Task :) +10:11 < morimoto> B) What I plan to do till next time +10:11 < morimoto> C) Problems I have currently +10:11 < morimoto> D) Posted/Accepted bugfix patch +10:11 < morimoto> Nothing for Core group +10:11 < morimoto> --EOT-- +10:12 < geertu> Thank you, Morimoto-san +10:12 < geertu> Next is Magnus +10:12 < dammsan> no update from me, just lurking +10:13 < geertu> Next is myself +10:13 < geertu> A) +10:13 < geertu> - Finished R-Car H3 ES2.0 for clk/pfc/sysc +10:13 < geertu> - R-Car Gen2 CPG/MSSR +10:13 < geertu> - Started DTS sharing on H3 ES1.x/ES2.0, Salvator-X/ULCB +10:13 < geertu> - Some Easter holidays +10:13 < geertu> B) +10:13 < geertu> - More Easter holidays +10:13 < geertu> - Rework drivers/{clk,soc}/renesas/Kconfig +10:13 < geertu> - Publish R-Car Gen2 CPG/MSSR +10:13 < geertu> - DTS sharing +10:13 < geertu> C) None +10:14 < geertu> D) More clock fixes detected during R-Car Gen2 CPG/MSSR conversion: +10:14 < geertu> - [PATCH 1/3] ARM: dts: r8a7790: Correct parent of SSI[0-9] clocks +10:14 < geertu> - [PATCH 2/3] ARM: dts: r8a7791: Correct parent of SSI[0-9] clocks +10:14 < geertu> - [PATCH 3/3] ARM: dts: r8a7793: Correct parent of SSI[0-9] clocks +10:14 < geertu> - [PATCH] ARM: dts: r8a7792: Correct Z clock +10:14 < geertu> - [PATCH] ARM: dts: r8a7794: Add Z2 clock +10:14 < geertu> - [PATCH] ARM: dts: koelsch: Correct clock frequency of X2 DU clock +10:14 < geertu> - [PATCH] clk: renesas: rcar-gen2: Fix PLL0 on R-Car V2H and E2 +10:14 < geertu> - [PATCH] clk: renesas: r8a7745: Remove nonexisting scu-src[0789] +10:14 < geertu> - [PATCH] clk: renesas: r8a7745: Remove PLL configs for MD19=0 +10:14 < geertu> EOT +10:14 < geertu> Next is Shimoda-san +10:14 < shimoda> A) +10:14 < shimoda> - I'm testing a new IPMMU workaround on R-Car H3 ES2.0. +10:14 < shimoda> B) +10:14 < shimoda> - Intend to make some plans about implementing IPMMU features with Magnus-san +10:14 < shimoda> C) and D) +10:15 < shimoda> - Nothing for core. +10:15 < shimoda> -- EOT -- +10:15 < geertu> Thank you, Shimoda-san +10:15 < geertu> Simon is excused, arriving in Kobe. His ABCD are: +10:15 < geertu> A) No Core task at this time +10:15 < geertu> B) No Core task at this time +10:15 < geertu> C) Selecting patches for upporting +10:15 < geertu> D) None +10:16 < geertu> Marek is also excused, he let me know the following: +10:16 < geertu> A) BD9571 MFD, GPIO, and regulator drivers +10:16 < geertu> B) Publish BD9571 drivers +10:16 < geertu> It's been a while I saw Khiem and Uli +10:17 < horms> I assume Khiem has been reassigned +10:18 < geertu> Probably +10:19 < geertu> And his email routed to (the Windows equivalent of) /dev/null +10:19 < geertu> Well, that went smooth! +10:19 < horms> likely +10:19 < geertu> Any other topics to discuss? +10:19 < dammsan> at least it is translated to CR LR before going into NULL +10:19 * horms has arrived in Kobe +10:19 -!- horms [~horms@g1-27-253-251-9.bmobile.ne.jp] has quit [Quit: Leaving] +10:19 < geertu> Perhaps periupport? +10:20 < geertu> I plan to go over the core related patches, as I believe several of them were upstreamed in some form +10:21 < geertu> I already did that for the patches that had identical patch IDs in upstream +10:22 < morimoto> geertu: I posted periupport patch again. I hope you can accept it +10:23 < geertu> morimoto: Thank you. But that will probably happen only next week. +10:24 < morimoto> OK, np +10:25 < geertu> Any other topics to discuss? +10:26 < geertu> For next meeting, I propose Tuesday, April 25, 08:00 GMT / 10:00 CEST / 11:00 EEST / 17:00 JST +10:26 < neg> I have a question about JTAG :-) +10:26 < geertu> neg: shoot! +10:26 < jmondi> I have -many- questions about JTAG +10:26 < jmondi> (joking, go on neg) +10:27 < geertu> neg: Machine gun questions? +10:27 < geertu> sorry, jmondi: Machine gun questions? +10:27 < neg> A while back I got my Flyswatter 2 and managed to find and modify some OpenOCD config files to get ut running on Gen2. If those could be tested on more boards then my Koelsch I think we could (re)try to get them picked up in upstream OpenOCD. Do you think there would be value in this? +10:28 < neg> I posted the configs at https://git.ragnatech.se/renesas-jtag/ and intend to write up elinux wiki page, I assume the SW settings to enable JTAG are OK to describe there as well? +10:30 < geertu> Cool! +10:30 < geertu> I only have +10:30 < geertu> source [find interface/ftdi/flyswatter2.cfg] +10:30 < geertu> reset_config trst_and_srst +10:30 < geertu> jtag_rclk 8 +10:30 < neg> last question is aimed at Morimoto-san :-) +10:30 < geertu> (most from Magnus, IIRC) so I never got that far... +10:31 < jmondi> neg: I will send you patches to use OpenOCD+Flyswatter on RZ as well :) +10:32 < neg> jmondi: nice :-) +10:35 < kbingham> neg: I guess you haven't looked at G3 yet :) +10:36 < neg> kbingham: thats right :-) +10:36 * geertu assumes kbingham is not talking about SH7367 (SH-Mobile G3) +10:37 < kbingham> geertu: Well, maybe I was ... :D +10:37 < geertu> Every spelling mistake is a different SoC ;-) +10:37 * morimoto geertu solved my confusion +10:37 < geertu> morimoto: cs2000? +10:37 < morimoto> No, about G3 :) +10:37 * kbingham coughs : Gen 3 +10:37 < geertu> kbingham: R-Car Gen3? +10:39 * morimoto I think neg's "last question" is not yet coming ? +10:39 < neg> morimoto: sry, my question was if it's OK to mention wich SW on the board you need to flip to enable JTAG, is this OK to mention on the elinux wiki? +10:40 < neg> for Gen2 that is +10:40 < morimoto> Ahh, OK. I think it is no problem +10:41 < neg> OK thanks +10:42 < neg> So I will let them stew in the reop and write a elinux page. If you try them out on Alt or Lager please let me know if all works I can resubmit them to OpenOCD and se what happens +10:43 < neg> that was all from me, thanks +10:46 < geertu> neg: Have you tried JTAG on the KZM9D? +10:46 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has quit [Remote host closed the connection] +10:46 < geertu> It may help to solve the SMP issue +10:46 < neg> geertu: no not yet, lurking in the back of my head tho +10:47 < neg> geertu: but I think Magnus once told me some special magic where needed to get it working +10:48 < geertu> OK +10:49 < geertu> Then I think we are finished? +10:49 < geertu> Thanks for joining, and have a nice continued day! +10:50 < shimoda> thank you! +10:50 < neg> I have nothing further, and the 25th works fine for me +10:50 < neg> thanks all +10:50 < jmondi> 25th is kind of bad for me +10:50 < jmondi> national holiday here and I don't plan to be home... +10:51 < jmondi> sorry I forgot to tell +10:52 < morimoto> 25th is OK for me too +10:52 < morimoto> thanks +11:01 < morimoto> geertu: are you still here ? +11:01 < morimoto> I want to ask you about cs2000 +11:07 < geertu> morimoto: yes, still here +11:07 < morimoto> what does your "a mux clock driver with three parents" ? +11:08 < geertu> morimoto: it's a very simple driver where you can select between 3 parents +11:08 < morimoto> How to select it ? by DT ? +11:08 < geertu> By clk_ops.set_parent() +11:09 < geertu> or .determine_rate(), which selects the best parent for the requested rate +11:09 < geertu> drivers/clk/clk-mux.c +11:09 < morimoto> Ahh.. +11:10 < morimoto> OK, thanks. I will check clk-mux.c +11:17 < morimoto> 1 question again. Who/How to select parent clock of .set_parent() ? +11:17 < morimoto> This AUX_OUT usage is board specific +11:18 < morimoto> Ahh, OK, I understand +11:18 < morimoto> Thanks diff --git a/wiki/Chat_log/20170412-mm-chatlog b/wiki/Chat_log/20170412-mm-chatlog new file mode 100644 index 0000000..7cffe38 --- /dev/null +++ b/wiki/Chat_log/20170412-mm-chatlog @@ -0,0 +1,539 @@ +Multimedia-chat-meeting-2017-04-12 + +<pinchartl> good morning [15:55] +<neg> morning +<morimoto> hi +<uli___> hello [15:56] +<pinchartl> let's wait a few minutes for Jacopo and Magnus to join [15:57] +<kbingham> Morning all +<jmondi> 'morning +<pinchartl> now only Magnus is missing :-) [15:58] +<neg> while we wait [16:00] +*** dammsan (~dammsan@s214090.ppp.asahi-net.or.jp) has joined channel + #periperi [16:01] +<neg> morimoto: is it enugho infomrmation about 'VIN issues on H3 ES2.0 and M3 + ES1x/M3W' to talk about it today or should we postpon it? +* morimoto Renesas talk now +<pinchartl> hi Magnus +<pinchartl> neg: I think we should at least mention it +<pinchartl> let's get started +<pinchartl> topics for today +<pinchartl> Topic 1. Status check for the multimedia tasks [16:02] +<pinchartl> Topic 2. VIN issues on H3 ES2.0 and M3 ES1x/M3W +<pinchartl> Topic 3. Upstream V4L2 development +<pinchartl> anything else ? +<pinchartl> ok, let's start with status updates [16:03] +<jmondi> maybe a check up on travel plans for OSS? +<pinchartl> jmondi: good point +<neg> Stamp of approvel for Tokyo dates, the mail thread is dead and time to + buy tickets ;-) +<kbingham> Ack with those :) ^ +<pinchartl> Kieran has to run away in the middle of the meeting, so he will + get started +<pinchartl> kbingham: the stage is yours +<kbingham> Why thankyou maestro :-) +* morimoto back [16:04] +<kbingham> So I'm now back on RCar developments and I've commenced looking at + the ADV7482 work +<kbingham> I have had some difficulty capturing frames through VIN so far, + getting the links set up to capture. +<morimoto> neg: we have no W/A at this point, so, nothing to discuss today. it + is just information sharing [16:05] +<kbingham> (I have tried to capture using the existing code base, using HDMI + in ) - and a RPi to generate HDMI data +<kbingham> But the issue is getting the formats to propogate - checking the + formats shows 'unknown' in the FMT field .. and things aren't + propogating through media ctl. [16:06] +<pinchartl> kbingham: do you have further things to try, or are you completely + blocked ? +<pinchartl> if it's a format propagation issue I assume you can try to debug + it +<kbingham> I'll have more things to try - like getting some prints in to see + why the formats aren't there [16:07] +<kbingham> yes - It's just a debug issue really. +<kbingham> But will help me walk the code base anyway +<pinchartl> ok +<neg> kbingham: did you try h3-compliance.sh from vin-tests? +<kbingham> neg: Yup ! Same issue +<kbingham> neg: And I set my RPi dev to 640x480 as you suggested - still no + avail - so I just need to dig and understand the issue +<neg> hum that is strange, guess I need to buy a RPI today :-) +<kbingham> If needed, I'll talk to (neg) later about that if possible. [16:08] +<pinchartl> you can also ask me +<pinchartl> not that I have tried it +<pinchartl> but I can guide you through the format propagation process and + code +<kbingham> pinchartl: Thankyou :D Anyway - otherwise- Once that issue is + resolved, I have started looking at how to create the subdevs, as + per our disucussions +<kbingham> and once I have established a baseline - I should be comfortable + hacking away at that. [16:09] +<pinchartl> ok, thank you +<neg> first guess is it's EDID related since the ADV7482 have no EDID support + I do all my testing using a Xbox as source so I assume it fallback to + something the ADV7482 likes +<neg> that is the ADV7482 driver have no EDID support +<kbingham> By default, the source is coming up as [fmt:unknown/1920x1080 + field:none] [16:10] +<kbingham> Anyway, we can go through that later :D [16:11] +<neg> kbingham: the ADV7482 prototype should autodetect the formats, I would + like to see the fill media graphyou get if possible, but maybe you and I + can hash this out after the meeting :-) +<pinchartl> jmondi: you're next in resumed alpbabetical order :-) +<kbingham> I agree - we'll go through this after the meeting rather than in + the meeting :) +<jmondi> fine... [16:12] +<jmondi> so, I started looking at moving the CEU driver away from soc_camera +<jmondi> I'm still evaluating if it is better to rewrite it or patch the + existing +<pinchartl> what's your opinion at this point ? [16:13] +<jmondi> I'm a bit more inclined to patch the existing, because at the moment + it seems to me the driver could be implemented without sub-devices, + just with a single video device +<jmondi> also, I saw there is a VEU driver, which seems simple enough to use + as "inspiration" [16:14] +<jmondi> even if it is a mem2mem device +<pinchartl> that sounds good to me +<pinchartl> you need a subdev for the camera sensor +<pinchartl> but you don't need to expose it to userspace [16:15] +<jmondi> yeah, camera sensor apart... +<jmondi> because the CEU has a format conversion unit, that can be modeled as + sub-device visibile to userspace +<pinchartl> the atmel/atmel-isc.c driver seems to be a good example +<jmondi> but I guess it can be left out for now [16:16] +<pinchartl> you don't need to, you can implement format conversion internally +<pinchartl> yes, also +<jmondi> pinchartl: thanks, I would have asked you suggestions on which driver + to look at +<jmondi> and that's all +<jmondi> I would have to clarify if OF support only is enough +<jmondi> because the remote mingor board we should start with, has no OF + support if I'm not wrong, right Magnus? [16:17] +<pinchartl> pxa_camera should also be an option +<jmondi> pinchartl: I gave a look at pxa camera, mostly for OF parsing +<pinchartl> correct, no OF support in Migor [16:18] +<pinchartl> you need to use platform data :-/ +<jmondi> that's bad, it means I have to implement both :/ +<pinchartl> you can start with platform data, and implement OF support later + [16:19] +<jmondi> we should also discuss about hw setup.. but it can be post-poned + after mingor has been made at least booting mainline +<pinchartl> sounds good to me [16:20] +<pinchartl> how about the next two weeks ? do you plan to continue working on + this ? +<jmondi> I'm still intrigued byt the idea of starting with an RZ device from + day 0 +<jmondi> pinchartl: yes, now that my other 2 tasks for IO/core are almost + done, I'll be fully on multimedia +<pinchartl> ok [16:21] +<jmondi> I'll stop here, not to steal the stage to all the others :) +<pinchartl> one more thing, could you please remember to send your status + report by e-mail before the meeting next time ? [16:22] +<dammsan> jmondi: yes there is no OF support for migor +<jmondi> pinchartl: uh, I'll do this right away +<jmondi> sorry about that +<pinchartl> jmondi: no need to for today, I'll include it in the report +<pinchartl> but it helps if I get them in advance +<jmondi> and, pinchartl, I'll ping you a bit more often in next days, hope you + won't mind ;) +<pinchartl> no problem with that :-) [16:23] +<jmondi> (I'll be away from tomorrow to Tues. since we're speaking) +<jmondi> ok, done with me +<pinchartl> next, me +<pinchartl> I've mostly worked on code review and various discussions, + internally and upstream +<pinchartl> as well as additional tasks negotiation [16:24] +<pinchartl> from a code point of view, I've tried to get the VSP rotation and + histogram support merged upstream in v4.12 +<pinchartl> it resulted in yet another fight with Mauro +<pinchartl> up to a point where I can't take his abusive behaviour anymore + [16:25] +<pinchartl> I took a few days to think this over +<pinchartl> among the various options most of them seemed unreasonable to me +<pinchartl> such as challenging him publicly for V4L2 maintainership for + instance +<pinchartl> Hans Verkuil proposed to me to act as an interface between Mauro + and me [16:26] +<pinchartl> to avoid all direct interactions +<pinchartl> I don't really think this would work, but I might give it a try +<pinchartl> in any case, I saw no other option that stepping out from upstream + V4L2 development, at least temporarily +<pinchartl> I will reconsider that decision if the situation changes [16:27] +<pinchartl> (or if I find a better idea) +<pinchartl> in effect, this means I can continue reviewing code and driving + discussions internally +<pinchartl> including architecture discussions +<pinchartl> but I'll remain silent publicly for now +<pinchartl> it also means I will likely need to refrain to author any V4L2 + patch [16:28] +<pinchartl> I still need to discuss this with Hans today, after this meeting +<dammsan> sounds good to me +<pinchartl> for the next two weeks, I plan to work on the multi-camera setup + and try to get it working +<pinchartl> VSP fences support is effectively on hold, I can't work on that + [16:29] +<dammsan> you can also consider putting mauro on fire +<pinchartl> I've considered that, but I don't think it will help +<pinchartl> he will fight back, and it would just create a bit mess, most + likely without any concrete improvement +<dammsan> he looks like he may burn well +<dammsan> probably +<pinchartl> dammsan: let's not resort to personal non-technical attacks + [16:30] +<pinchartl> that's it for me for today +<pinchartl> if any of you wants to discuss this further let's do so after the + status updates [16:31] +<pinchartl> next, dammsan +<neg> quick question, 'reviewing code internally' means no public review of + patches? +<dammsan> no update from my side, currently installing migor in the remote + access rack +<pinchartl> neg: correct. let's discuss the implications after the status + update [16:32] +<pinchartl> dammsan: thank you +<pinchartl> I assume you'll now try to get Migor to boot mainline ? +<dammsan> once it is installed yes [16:33] +<pinchartl> thank you +<dammsan> thanks +<pinchartl> next, Morimoto-san +<morimoto> A) What have I done since last time +<morimoto> continue OF-graph posting. I got response from Rob, but he mentions + small details which is related to ALSA SoC, not to OF-graph. +<morimoto> BSP team reported Sound issue. Almost all bugs are fixed. But some + noise issue was not yet solved. I'm thinking this is related to + board specific clk issue (L/R clock gets interference from Bit + clock) +<morimoto> 8ch camera datasheet export paper work +<morimoto> created periupport script +<morimoto> shared H3/M3 VIN issue to you guys ;P +<morimoto> B) What I plan to do till next time [16:34] +<morimoto> continue OF-graph posting +<morimoto> continue sound noise issue fix +<morimoto> 8ch camera board check by using demo program with BSP team +<morimoto> C) Problems I have currently +<morimoto> OF-graph stalling +<morimoto> --EOT-- +<pinchartl> thank you +<pinchartl> when do you think you will be able to verify the multi-camera + setup with the demo program ? [16:35] +<morimoto> According to BSP team, I and Magnus will check it on this Fri +<dammsan> huh, good to know +<dammsan> =) [16:36] +<pinchartl> :-D +<morimoto> dammsan: this means you need to bring it to Renesas Office on Fri + :P +<pinchartl> I'll wait until this weekend before working on it then +<pinchartl> could you post a status update when you will be done on Friday ? + [16:37] +<morimoto> Of course I will check 2 board which will be ship to Laurent/Niklas + after May +<pinchartl> and Magnus, will you be able to reinstall it in your remote access + setup after your done, to allow me to work on it during the + weekend ? +<morimoto> pinchartl: sure +<pinchartl> thank you [16:39] +<dammsan> pinchartl: not sure about when i will get time to do that +<morimoto> I think all needed 8ch camera datasheet/information exist on Wiki + now. do we still missing something ? +<pinchartl> dammsan: could you at least send me an e-mail when you will be + done ? and also notify me if you get delayed ? +<dammsan> it depends on how long time is needed in the renesas office [16:40] +<pinchartl> morimoto: I still don't know what the small microcontroller inside + the cameras does exactly. do you have any information about that ? + it's connected to the I2C control bus, and controls the sensor + power down signal +<dammsan> once it is working i will reinstall it in the remote access rack + [16:41] +<pinchartl> dammsan: you don't have to work around the clock obviously :-) but + for planning purposes, it would help if you could let me know at + the end of Friday if there will be delays +<morimoto> pinchartl: do you mean U402 ? and I think you are asking it to IMI + guys ? [16:42] +<pinchartl> morimoto: yes, U402. I've asked the IMI person who sent me the + schematics, but haven't received any answer +<dammsan> i highly doubt things will start workin on friday +<morimoto> OK, I will push him +<dammsan> and we have meetings most of the afternoon +<dammsan> so i think you can assume you will not get it this weekend [16:43] +<pinchartl> dammsan: ok. let me know if that changes then +<dammsan> will let you know once it is reinstalled +<dammsan> thanks +<pinchartl> morimoto: I see your e-mail report contains a list of patches. do + I need to include them in the meeting report, or will they be + picked up by your scripts ? [16:44] +<pinchartl> while waiting for that answer [16:45] +<pinchartl> neg: your turn +<neg> a) +<neg> - Fixed up some small CSI-2 stuff, patches pending waiting further +<neg> work before I post them. +<neg> - Had discussions with Laurent, Kieran and Sakari about V4L2 +<neg> extensions needed to support ADV7482. +<neg> - Took a stab at at extending the of graph framework to be able to +<neg> iterate over all DT nodes in a graph connected by endpoints. But +<neg> ceased work after the talk above since the core issue can +<neg> hopefully be solved in a better way and then there would be no +<neg> users of this. [16:46] +<neg> - Tried to help out as much as possible with the 8-channel VIN +<neg> prototype Ulrich and Laurent are working on. +<neg> b) +<neg> - Respin CSI-2 and VIN patches with my new found knowledge of V4L2 +<neg> async framework. +<neg> - Keep supporting 8-channel VIN if needed. +<neg> - Address any review comments on VIN and CSI-2 patches. +<neg> c) +<neg> - No review or other activity on VIN patches, the series [PATCH +<neg> 00/16] rcar-vin: fix issues with format and capturing' IMHO ready +<neg> to be picked up upstream but needs reviews. +<neg> Also Friday 14/4 and Monday 17/4 are holidays in Sweden and I will be + out of town at least on Friday, so my response times are reduced between + those dates. +<pinchartl> thanks for letting us know +<morimoto> pinchartl: I think bugfix patches of D) ? it will be pickuped + automatically by our script. you can drop it. thanks [16:47] +<pinchartl> those two days are public holidays in Finland too +<pinchartl> morimoto: thank you +<pinchartl> regarding the rcar-vin series +<pinchartl> I can review it internally [16:48] +<pinchartl> again, let's discuss that after the status updates +<pinchartl> uli___: your turn +<uli___> so the csi purports to capture frames from the max9286, but it + doesn't really +<uli___> i tried turning off integrity checks, but to no avail +<uli___> i guess the data is not valid; maybe the virtual channel setup is + wrong? [16:49] +<uli___> that's pretty much it. two suggestions for friday: +<uli___> 1. dump the registers of the max92* and ov10635, if it works +<uli___> 2. dump the microcontroller, if you have an isp programmer lying + around +<uli___> it has 8k of rom, and most of it will be ov10635 register settings +<uli___> should be easy to reverse-engineer... [16:50] +<pinchartl> uli___: do you think that U402 is an I2C master ? +<pinchartl> I thought it was a slave +<uli___> the driver code suggests so +<pinchartl> ouch +<uli___> it says that linux doesn't support multi-master busses +<uli___> and that it has to wait for the attiny to finish because of that +<pinchartl> that would require opening the camera, I'm not sure if that's + feasible [16:51] +<uli___> oh, i see... +<pinchartl> but if the microcontroller indeed configures the sensor by itself, + we might have issues, yes +<uli___> well, that's it from me [16:53] +<pinchartl> thank you for the suggestions +<pinchartl> that's it for the status updates +<pinchartl> Topic 2. VIN issues on H3 ES2.0 and M3 ES1x/M3W [16:54] +<pinchartl> Morimoto-san has reported VIN-related issues in the wiki +<pinchartl> + (https://osdr.renesas.com/projects/linux-kernel-development/wiki/R-Car-Gen3#VIN-issue) +<pinchartl> we don't have much information at this point though +<pinchartl> so there isn't much to discuss +<pinchartl> but I have a question [16:55] +<morimoto> Yes. but it is just information, and no W/A at this point. +<pinchartl> morimoto: do those issues impact the multi-camera setup we're + trying to get working ? +<neg> morimoto: W/A == Wanted Action? +<pinchartl> neg: Work Around +<pinchartl> (I assume) +<morimoto> yes Work Around, sorry [16:56] +<neg> thanks :-) +<morimoto> pinchartl: According to BSP team, upstream is supporting 2 Lane ? +<morimoto> 1 lane, and 4 lane have no issue +<morimoto> but 2 lane has issue on M3 +<morimoto> BSP team is using H3 [16:57] +<morimoto> and our remote access is using M3 +<pinchartl> dammsan: would it be possible to switch the remote access setup to + H3 ? +<morimoto> pinchartl: 1 question. are multimedia people tring to 8ch directly + ? [16:58] +<morimoto> I though 1ch camera as fist step [16:59] +<pinchartl> morimoto: no, we're trying to capture from a single camera first +<morimoto> OK +<morimoto> So then it is using 1lane ? maybe M3 +<morimoto> s/mabe M3// +<uli___> 4 lane [17:00] +<dammsan> pinchartl: i can attach the camera board to H3 instead [17:01] +<dammsan> but then our ground might become more stable +<dammsan> i mean more unstable since it is changing +<pinchartl> I think this can wait until Friday +<morimoto> sorry I was wrong. CSI40's 1lane and 2lane are NG. CSI40 4lane is + OK. CSI20 is all OK +<dammsan> after the hardware has been verified in the renesas office i will + use the same one for the remote access +<pinchartl> if you get it to work on H3 on Friday but can't on M3, then we'll + switch to H3 :-) [17:02] +<dammsan> of course if you have any special preference then we will follow + that +<pinchartl> I think we're done with status updates [17:03] +<pinchartl> sorry, with VIN :-) +<pinchartl> Topic 3. OSS Japan trip +<pinchartl> (FYI, my talk at OSS Japan has been approved) [17:04] +<pinchartl> we need to start booking planes and hotels +<pinchartl> morimoto: can we proceed with Renesas' blessing ? +<morimoto> blessing = trip cost ? [17:05] +<morimoto> or meeting ? +<pinchartl> blessing as in getting authorisation to book the trip, and + invoicing it to Jinso [17:06] +<morimoto> Maybe it is OK unless you enjoyed party like Oil tycoon ;P +<pinchartl> damn, my cunning plan has been understood :-) [17:07] +<pinchartl> we'll keep the costs down as usual [17:08] +<pinchartl> no champagne, we'll just drink nihonshu :-) +<pinchartl> jmondi: kbingham: neg: you can proceed booking tickets +<pinchartl> uli___: you could too, but you mentioned you won't be able to + join, right ? +<uli___> no, i won't. sorry. [17:09] +<morimoto> Renesas will pay up to Economy class for flight. Of course you can + upgrade, but it is your cost ;P +<neg> I assume ppl will book the conference hotel even for code camp days? +<dammsan> "up to Economy class" - makes it sound ike there is something + lower? =) [17:10] +<neg> dammsan: United? +<dammsan> haha, if you prefer to be dragged out +<neg> haha :-) +<jmondi> what days we said again? 26th to the 2nd? [17:11] +<pinchartl> jmondi: 29th to 3rd +<pinchartl> (Monday to Saturday) +<pinchartl> I suggest arriving on the 28th at the latest +<pinchartl> (that's what I'll do, in the morning) +<pinchartl> and leaving on the Sunday, or later if you want to take some time + to visit Tokyo [17:12] +<pinchartl> please be careful about the jetlag though +<pinchartl> flights from Europe often land early in the morning +<pinchartl> if you have trouble sleeping in the plane, the next day is very + painful +<pinchartl> you might want to arrive on the 27th to have more time to recover + [17:13] +<jmondi> looking at flights now +<pinchartl> neg: I've booked the conference hotel for the first two days too +<pinchartl> the rate allows changes +<morimoto> And we will have multimedia F2F meeting on 29th 30th ? +<pinchartl> so I might move to a different location after we decide on the + meeting location +<pinchartl> morimoto: correct. we still haven't decided where to host that + [17:14] +<morimoto> OK +<pinchartl> I would appreciate if our valued Japanese and Japanese resident + team members could advise on appropriate meetings locations +<morimoto> OK, I and Magnus will try it. dammsan: please say YES [17:15] +<dammsan> YEESS +<pinchartl> thank you :-) +<morimoto> How many member ? [17:16] +<pinchartl> it should be 4 from Europe [17:17] +<pinchartl> Jacopo, Kieran, Niklas and me +<pinchartl> I assume Magnus and you will join too +<pinchartl> I don't know who else would like to attend from Japan +<pinchartl> we will have a multimedia team meeting, but I also want to use + this opportunity to work on the multi-camera setup with local + access to the hardware [17:18] +<pinchartl> so I'd like part of those two days to be a code camp +<pinchartl> next topic, upstream V4L2 development [17:19] +<neg> If I understnad the mail thread corretly Wolfram won't be there so no IO + meeting to conflict with, but can't see any feedback from Geert. Anyone + know if extra days will be needed for Core meeting? +<pinchartl> neg: I don't know. let's ask geertu [17:20] +<neg> geertu: ^ :-) +<pinchartl> I've already explained the situation briefly. I assume some of you + may have questions +<pinchartl> (suggestions will be appreciated too, feel free to speak your mind + honestly) +<jmondi> pinchartl: is the discussion you had with Mauro on linux-media list? + [17:21] +<pinchartl> no, it was an IRC discussion on #v4l +<jmondi> oh, that's why :) [17:22] +<pinchartl> it's not that discussion as such that prompted me to reconsider my + involvement, but all the interactions I've had with Mauro over the + past 12 months (at least) +<pinchartl> this was just the last straw +<neg> First off. I think it's problematic that you step away from V4L2, even + for a while. But I understand why you do it and support it. [17:23] +<pinchartl> neg: thank you. for the record, when I said you're free to state + your mind, I could totally understand if you (or anyone else) + couldn't understand my decision, and thought it was a very bad + idea [17:24] +<jmondi> how can you really step away, involved as you are (saying this from + the point of view of someone outside the v4l2 community)? +<pinchartl> jmondi: but stopping all my involvement +<pinchartl> not sending any patch anymore +<pinchartl> not participating in any public discussion (mailingl list, irc, + face to face meetings) [17:25] +<pinchartl> not reviewing any code anymore +<pinchartl> (at least publicly) +<jmondi> I mean, everything you guys have discussed here has been shared to + other v4l2 members (and that's great)... will you drop everything? +<pinchartl> I plan to continue supporting the multimedia team and every member + who works on V4L2 through internal discussions and code reviews + [17:26] +<pinchartl> but that might be the most I will be able to do +<pinchartl> as mentioned earlier, I will discuss this with Hans Verkuil after + this meeting [17:27] +<neg> This creates voids since you is a big part when the media group interact + with the V4L2 community, I feel at least I would need to ask you from + time to time how to best proceed with things like that even if you won't + be a part of it +<pinchartl> he proposed acting as middleman between Mauro and me +<pinchartl> while I don't think it would work, I could still give it a try +<pinchartl> neg: I'll answer all questions from the team and will help as much + as I can [17:28] +<neg> The thing closest to my heart is to get the VIN Gen3 patches upstream + and my interpretation of the situation have been that Hans have waited + for you to review the patches, and now that you can't public review/ack + those patches I feel worried on how to proceed to get those patches + upstream. +<pinchartl> but you would need to be the one taking up the fight against Mauro + publicly +<pinchartl> I won't be able to support you when it comes to defending your + work in public +<jmondi> v4l3? :p +<pinchartl> jmondi: that's also an option I've considered, but I don't think + it's feasible. I might be wrong though +<pinchartl> ah, another point, for the record [17:30] +<pinchartl> Google will likely continue the work on the request API +<pinchartl> (in particular Alexandre Courbot and Tomasz Figa from the chromeos + team) +<pinchartl> I have a meeting scheduled tomorrow with them to explain how I + would like them to proceed +<pinchartl> but their main use case is video codecs +<pinchartl> they have no performance-related use case like we do [17:31] +<jmondi> and no android stupid HAL libraries to make happy +<pinchartl> so I fear this means that whatever will be merged upstream will + not support our use cases +<pinchartl> we might be left with no way to get decent performances from the + VSP with upstream APIs +<pinchartl> that would be a big gap that the BSP would need to cover +<pinchartl> I might be painting the situation blacker than it is really, but + it's a risk [17:32] +<pinchartl> dammsan: morimoto: you're silent, any comment or question about + all this ? +<pinchartl> I guess not [17:35] +<pinchartl> if there's no other question or comment, the next topic is the + next meeting [17:36] +<pinchartl> I propose two weeks from now, same time +<pinchartl> Wednesday 2017-04-26 at +<pinchartl> 08:00 GMT / 09:00 CEST / 10:00 EEST / 16:00 JST +<neg> works for me [17:37] +<uli___> ok [17:38] +<pinchartl> jmondi: does it work for you too ? +<pinchartl> I think we've lost Morimoto-san and Magnus. I'll assume it works + for them too +<neg> pinchartl: maybe we can have a short chat after you talked to Hans about + who I can best procced with getting attention on the VIN patches? +<dammsan> it is fine =) +<pinchartl> neg: sure +<neg> thanks +<jmondi> isn't there IO meeting on the 26th? [17:39] +<jmondi> no, it's the 18th sorry about that! +<jmondi> pinchartl: works for me then +<pinchartl> ok, it's settled then [17:40] +<pinchartl> if there's no other question, I propose adjourning this + meeting. you can always talk to me here or in private later today + or at any other time if there's something you'd like to discuss +<pinchartl> does anyone second ? +<neg> second [17:41] +<pinchartl> thank you all for attending, and have a nice day +<jmondi> second! +<neg> thanks all, have a nice day +<jmondi> can I send an email to periperi to discuss about OSS trip + organization? [17:43] +<pinchartl> jmondi: sure [17:44] +<dammsan> jmondi: yes, we said at 19:00 [17:54] +* morimoto I'm back from Renesas talk [18:17] +<morimoto> pinchartl: I will share about Request API topic to BSP team. Thanks diff --git a/wiki/Chat_log/20170418-io-chatlog b/wiki/Chat_log/20170418-io-chatlog new file mode 100644 index 0000000..81b9062 --- /dev/null +++ b/wiki/Chat_log/20170418-io-chatlog @@ -0,0 +1,191 @@ +--- Log opened Tue Apr 18 09:56:37 2017 +09:56 -!- wsa_ [~wsa@p54B33A49.dip0.t-ipconnect.de] has joined #periperi-io +09:56 -!- Irssi: #periperi-io: Total of 5 nicks [0 ops, 0 halfops, 0 voices, 5 normal] +09:56 -!- Irssi: Join to #periperi-io was synced in 0 secs +09:56 < wsa_> hey guys! +09:57 < neg> hello +09:57 < horms> hi all +09:58 < jmondi> Hi there +09:58 -!- uli___ [~uli___@static.206.203.46.78.clients.your-server.de] has joined #periperi-io +09:59 < geertu> Mornin' +09:59 -!- Irssi: #periperi-io: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal] +10:00 < uli___> hi +10:00 -!- morimoto [~user@relprex1.renesas.com] has joined #periperi-io +10:00 < wsa_> hi uli, morimoto-san! +10:00 < morimoto> Hi +10:00 -!- Irssi: #periperi-io: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal] +10:02 < wsa_> so, nice to have you here, let's start +10:02 < wsa_> i forgot to call for ABC answers, so let's do some informal update report here +10:03 < wsa_> like I worked on additional contracts mainly, and started with the I2C suspend/resume issue +10:04 < wsa_> jmondi: any news? +10:04 < wsa_> (sort -R power again ;) +10:04 < jmondi> wsa_: am I first? :) +10:05 < jmondi> I have closed max9611 driver, no answer from Baylibre on sampling time, no one on iio list commented, so driver will support sysfs attribute access only +10:05 < neg> wsa_: just to be clear, you are asking for ABC updates afther the mail 'IO: call for updates' from 2017-04-07 where this meeting was announced? +10:06 < jmondi> (remember last time we discussed about sampling frequencies for that driver) +10:06 < wsa_> neg: yes +10:06 < jmondi> as reported in the email, B = C = D = NULL +10:06 < wsa_> jmondi: sounds fine to me +10:07 < jmondi> on homework side, I gave a look at genmai schematics to search for un-supported chips, but there's nothing there +10:08 < geertu> jmondi: Is the audio codec connected to SPI supported now? +10:08 < wsa_> jmondi: so, i'll mark the driver as merged. Cool, thanks! +10:08 < jmondi> I also asked Magnus, that last time we spoke said he had some ideas for possible new parts to support, and he pointed me to an led controller, but very low priority it seems +10:08 < geertu> jmondi: When I worked on RSPI, it wasn't, except for a patch in the codec vendor tree, supporting i2c only +10:08 < jmondi> geertu: I've been looking for ADCs/DACs +10:09 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi-io +10:09 < wsa_> jmondi: we can discuss the next IO work for you later +10:09 < jmondi> wsa_: yeah! then --eot-- +10:09 < geertu> jmondi: Aren't audio codecs DACs? ;-) +10:10 < wsa_> next one, simon, already reported via mail. Thanks Simon! +10:10 < horms> np +10:10 < jmondi> geertu: you have a point, sir :) +10:10 < wsa_> one question about one problem: Priorities for upstreaming +10:11 < wsa_> can you elaborate a little +10:11 < wsa_> ? +10:11 < geertu> jmondi: sound/soc/codecs/wm8978.c exists, i2c only +10:11 < horms> sure +10:11 < horms> I think it should read priorities for upporting +10:11 < horms> I may have typed the wrong word in my email +10:12 < horms> sure +10:12 < wsa_> I see +10:12 < wsa_> Upporting, it is +10:13 < wsa_> did you get the add. task for SDHI? +10:13 < horms> as you may know Kaneko-san and I have been working on analysing the BSP for a while now. And to a lesser extent upporting patches. Meanwhile Morimoto-san has organised an effort to allow better feddback between team leaders and the BSP team on what is desirable to upport. I'm happy for Kaneko-san and I do some backporting based on priorities that come out of the teeam leader/BSP team communication. But I'm unsure what the priorities are. +10:13 < horms> Does that make sense? +10:14 < wsa_> yes +10:14 < horms> wsa_: yes. I have the task. Jinso have signed it. I will once I get access to a printer - I'm still on the road +10:14 < wsa_> good enough +10:14 < geertu> horms: Aren't the [HMLN] characters in the first column the priorities? +10:16 < wsa_> I guess there is some confusion how to merge the work done by Simon and the new list? +10:16 < horms> geertu: yes, indeed they are. +10:17 < horms> I guess my question is the one wsa_ stated +10:17 < horms> My assumption was that the team leaders would be directing upporting activities +10:17 < horms> And I wanted to avoid conflicting with that +10:18 < wsa_> I guess there is still something to be sorted out, but this is not specifically an IO issue. +10:19 < horms> If not, I can just look at the list and choose things based on HMLN :) +10:19 < horms> agreed +10:19 < wsa_> So, while I'd really like to resolve this somewhen, I'd like to go on with the IO stuff... +10:19 < horms> sure +10:19 < horms> no problem +10:20 < wsa_> morimoto: some input from you? +10:20 < morimoto> nothing from me for I/O +10:20 < morimoto> but I can show you my special smile for Wolfram, because you posted I2C suspend/resume support patch +10:20 < morimoto> v(^o^)v +10:20 < morimoto> +10:21 < wsa_> :D +10:21 < wsa_> uli: any news from your side? +10:22 < uli___> haven't done anything for io for a while; i'm waiting for my hscif variable timeout task +10:23 < wsa_> yup, same here +10:24 < wsa_> i'll ping Magnus to see if there are news... +10:24 < wsa_> neg: updates? +10:25 < neg> No public update since last ABC, I did a protype for avb WoL and at least my hack works but still waiting for contract for that, any news if it's delayed? +10:25 < wsa_> nope +10:25 < wsa_> I guess Magnus is just super-busy +10:26 < wsa_> dammsan: right? :) +10:26 < neg> OK np for me, if you want it erlier but delay for some reason I can always try to include it in my base. Let me know what you think is best +10:27 < wsa_> neg: i think it is best to wait a little longer +10:27 < wsa_> keep the 'base' for m/m for now +10:28 < wsa_> neg: if you have a minute after the meeting, can we chat a little? +10:28 < wsa_> geertu: last, but definately not least :) +10:28 < neg> wsa_: sure after meeting is fine +10:29 < geertu> geertu: No changes compared to my email from Apr 6 +10:30 < geertu> There seems to be a renewed interest in SPI slave, which is good. +10:30 < geertu> So I'll tackle that soon +10:30 < wsa_> cool! +10:31 < wsa_> looking forward to that +10:31 < wsa_> '/names +10:31 -!- Irssi: #periperi-io: Total of 8 nicks [0 ops, 0 halfops, 0 voices, 8 normal] +10:31 < wsa_> so much for the updates +10:32 < wsa_> now it is time for a big thank you for the "homework" +10:32 < wsa_> i'll include it in the todo list in the next days +10:33 < wsa_> very nice outcome +10:34 < wsa_> so, the only thing I have left is to discuss the next work for jacopo +10:34 < wsa_> but no need for everyone to be present for that +10:34 < wsa_> so, if you have questions comments or so, this is the time now... +10:35 < horms> none at this time +10:35 < neg> I'm happy thanks all +10:36 < wsa_> good then +10:36 < wsa_> then this was the official part +10:36 < wsa_> thanks guys +10:37 < wsa_> jmondi: what boards do you have currently? +10:37 < morimoto> bye-bye +10:38 < jmondi> wsa_: Salvator-X M3, a Genmai and a GR-Peach +10:39 < wsa_> GR-Peach? which SoC is that? +10:40 < geertu> RZ/A1 +10:40 < jmondi> RZ A1H +10:40 < wsa_> i see +10:41 < jmondi> this little tiny useless board here https://developer.mbed.org/platforms/Renesas-GR-PEACH/ +10:41 < wsa_> useless? :) +10:41 < jmondi> eh +10:41 < jmondi> it comes with on-board sdram only +10:42 < jmondi> it can run a xip kernel from Renesas US BSP +10:42 < jmondi> not tried mainline yet +10:42 < jmondi> it is designed to be used as an mbed platform +10:42 < jmondi> so, yes, a bit useless +10:42 < jmondi> :) +10:43 < wsa_> hehe +10:43 < geertu> s/on-board/on-SoC/ +10:44 < jmondi> geertu: correct +10:45 < wsa_> so, I just found out the task I had in mind was for H3. M3-W is not enabled for that yet. +10:45 < wsa_> so, i need to rethink and just write you a mail. +10:46 < jmondi> wsa_: we're going to meet in Japan in ~month, and I'm busy with multimedia, so if I need some particular board, I can collect it there +10:47 < wsa_> I'd think it would be nice if you have a Gen2 board as well (Lager or Koelsch) +10:47 < geertu> jmondi: Unfortunately an H3 has to be shipped officially +10:47 < wsa_> but I don't know the availability of those +10:47 < jmondi> geertu: I heard about that, in fact... +10:47 < geertu> wsa_: digi-key has porters ;-) +10:48 < jmondi> wsa_: I have access to an ALT board from Magnus farm +10:48 < wsa_> last resort :D +10:48 < wsa_> morimoto: do you think it is possible to provide jacopo with a Lager or Koelsch? +10:49 < wsa_> jmondi: so, you are currently busy with m/m anyhow and not exactly bored? +10:49 < jmondi> wsa_: not exactly, no +10:50 < jmondi> I have my hands full with a "background" multimedia task +10:50 < jmondi> that has been brought foreground until the end of May +10:51 < wsa_> full-time until end of may? +10:51 < wsa_> or due-date is end of may? +10:51 < jmondi> due date is end of may +10:51 < wsa_> i see +10:51 < jmondi> and it can be made full time and postpone IO work to June +10:52 < jmondi> I will have 2 weeks for IO if I'm not wrong +10:52 < jmondi> not that much, but I hope it can be extended later ;) +10:53 < wsa_> we'll see +10:53 < jmondi> wsa_: what did you have in mind? +10:53 < wsa_> ok, so you have stuff to do now which gives me some time to reschedule +10:54 < wsa_> we got some failure reports. And I wanted you to check a few of those +10:55 < wsa_> probably low-hanging fruits once the problem is analyzed +10:55 < wsa_> but exactly that needs to be done :) +10:55 < wsa_> like 'aplay' crashes when the i2c driver is rebound +10:55 < wsa_> but we don't have sound yet on M3 +10:56 < geertu> wsa_: Isn't that fixable by adding a few devices to the DTS? +10:56 < wsa_> might be +10:56 < geertu> You may want to check with Simon, as he was going to do that, IIRC (cfr. meeting before FOSDEM) +10:56 < wsa_> but that i need to check before assigning the task +10:57 < wsa_> because the task is not "enable sound on M3" ;) +10:57 < jmondi> wsa_: are those "The failure summary report of ..." ? +10:58 < jmondi> from jinso, usually.. +10:58 < wsa_> yes +10:59 < wsa_> but the newer ones are not sent to the list anymore +10:59 < wsa_> and careful, some of the issues are moot, IMO +11:00 < jmondi> I see, I read a bit of discussions on reported multimedia issues, and yes, they need double-checks :) +11:00 < wsa_> they do +11:00 < jmondi> so Wolfram, would you like to have some more time to think on this? +11:00 < wsa_> but one or two are worth being researched IMO +11:00 < wsa_> yes +11:01 < jmondi> as I've said, I'm not in a rush and not getting bored here +11:01 < wsa_> that's perfect +11:01 < wsa_> so, I'll come back to you when I sorted out things +11:01 < jmondi> sure! thanks for now then +11:01 < wsa_> and I'll see if we can get you a Gen2 board +11:01 < jmondi> that would be lovely +11:02 < jmondi> I still have some space on my desk :) +11:04 < wsa_> hehe +11:05 < wsa_> thanks, jacopo. i think we are done for now +11:07 < jmondi> thank you +11:07 < jmondi> I'll wait from updates then +11:08 < jmondi> bye bye +11:10 < wsa_> bye +11:13 -!- morimoto [~user@relprex1.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +11:13 -!- horms [~horms@103.5.140.161] has quit Ping timeout: 252 seconds +11:18 -!- uli___ [~uli___@static.206.203.46.78.clients.your-server.de] has left #periperi-io ["Leaving"] +11:55 -!- neg [~neg@unaffiliated/neg] has left #periperi-io [] +--- Log closed Tue Apr 18 12:39:15 2017 diff --git a/wiki/Chat_log/20170425-core-chatlog b/wiki/Chat_log/20170425-core-chatlog new file mode 100644 index 0000000..62e0a00 --- /dev/null +++ b/wiki/Chat_log/20170425-core-chatlog @@ -0,0 +1,145 @@ +Core-chat-meeting-2017-04-25 + +10:11 < geertu> Welcome to Today's Core Group Chat! +10:11 < geertu> Agenda: +10:11 < geertu> 1. Status updates +10:11 < geertu> 2. Special requests +10:11 < geertu> Topic 1. Status updates +10:11 < geertu> A) What have I done since last time +10:11 < geertu> B) What I plan to do till next time +10:11 < geertu> C) Problems I have currently +10:11 < geertu> D) Posted/Accepted bugfix patches +10:11 < geertu> The evil random generator has selected Magnus to be first +10:12 < dammsan> ouch +10:12 < dammsan> no special update, but i intend to focus on IPMMU during GW +10:12 < dammsan> so i will have something to report until next meeting +10:13 [Users #periperi] +10:13 [ dammsan] [ kbingham ] [ morimoto` ] [ pinchartl] +10:13 [ geertu ] [ Marex ] [ mturquette] [ shimoda ] +10:13 [ jmondi ] [ marex-cloud] [ neg ] [ uli___ ] +10:13 -!- Irssi: #periperi: Total of 12 nicks [0 ops, 0 halfops, 0 voices, 12 normal] +10:14 < geertu> Next is Ulrich +10:14 < geertu> Thak you, Magnus +10:14 < geertu> s/Thak/Thank/ +10:14 < uli___> nothing core-related to report from me +10:14 < geertu> Thank you, Ulrich +10:15 < geertu> Next is Niklas +10:15 < neg> A) B) No core task ATM +10:15 < neg> C) D) None +10:16 < geertu> Thank you, Niklas +10:16 < geertu> Next is Shimoda-san +10:16 < shimoda> A) What have I done since last time +10:16 < shimoda> - Investigate IPMMU workaround for Xen :) +10:16 < shimoda> - No core task for linux kernel upstreaming. +10:17 < shimoda> B) What I plan to do till next time +10:17 < shimoda> - No Core task for next time. +10:17 < shimoda> C) Problems I have currently +10:17 < shimoda> - I have concern when IPMMU driver for Gen3 is merged into iommu subsystem repo. +10:17 < shimoda> D) Posted/Accepted bugfix patch +10:17 < shimoda> - Nothing. +10:17 < shimoda> --- EOT --- +10:17 < geertu> Thank you, Shimoda-san +10:17 < geertu> Next is Marek +10:19 < geertu> He may still be asleep, as he was reducing the ravb driver in U-boot by 65% at 3 AM +10:19 < geertu> Next is Morimoto-san +10:19 < morimoto`> A) What have I done since last time +10:19 < morimoto`> I had confirmed Salvator-XS board request from EuroPeri. Geert, Laurent, Marek, Niklas will receive it by 1st shipping +10:19 < morimoto`> B) What I plan to do till next time +10:20 < morimoto`> Start export paper work for Salvator-XS board. +10:20 < morimoto`> I would like to support sound on M2 Salvator-X (On Geert's patches ?) +10:20 < morimoto`> C) Problems I have currently +10:20 < morimoto`> D) Posted/Accepted bugfix patches +10:20 < morimoto`> NULL, sir +10:20 < morimoto`> --EOT-- +10:20 < morimoto`> s/M2 Salvator-X/M3 Salvator-X/ +10:21 < geertu> Thank you, Morimoto-san +10:21 < geertu> Next is Geert +10:21 < geertu> A) What have I done since last time +10:21 < geertu> - Posted RFC patches for DTSI sharing (SiP, Salvator-X, ULCB) +10:21 < geertu> - Marked periupport priority H commits that are in next-20170421 +10:21 < geertu> - Sent third pull request for v4.12 PFC fixes +10:22 < geertu> B) What I plan to do till next time +10:22 < geertu> - Publish drivers/{clk,soc}/renesas/Kconfig rework +10:22 < geertu> - Publish R-Car Gen2 CPG/MSSR +10:22 < geertu> - Review v4 of RZ/A1 PFC +10:22 < geertu> - Take a break from Core to finish SPI slave +10:22 < geertu> - Mark periupport priority < H commits that are in linux-next +10:22 < geertu> C) Problems I have currently +10:22 < geertu> - What are the official names of the different versions of the R-Car +10:22 < geertu> H3/M3 SiPs? +10:22 < geertu> - Why doesn't Documentation/devicetree/bindings/sound/renesas,rsnd.txt +10:22 < geertu> document clocks and clock-names properties? +10:22 < geertu> This is needed for extension to resets and reset-names. +10:22 < geertu> D) Posted/Accepted bugfix patches +10:22 < geertu> - None +10:22 < geertu> --EOT-- +10:23 < geertu> Laurent is excused +10:23 < geertu> Jacopo is celebrating his national holiday, he reported no status updates +10:24 < geertu> Marek posted bd9571 pmic patches +10:24 < geertu> Simon is gone(?) +10:24 < geertu> He reported no core tasks +10:25 < geertu> Morimoto-san: Do you have solutions to my "problems"? +10:25 < morimoto`> what kind of problems ? +10:25 < geertu> See C above +10:26 < morimoto`> Ahh, let me check +10:27 < morimoto`> needed for resets ? +10:28 < morimoto`> missing "clocks" and "clock-names" are just my fail. I will post patch +10:28 < geertu> The resets and reset-names properties mimic the module clock and clock-names (CPG/MS and SR) +10:28 < geertu> morimoto: Thank you, then I can extent the bindings with the resets later +10:29 < geertu> The other problem is related to "[PATCH 0/8] arm64: dts: renesas: Break out R-Car H3 and M3-W SiP" +10:32 < geertu> Perhaps we should handle that offline? +10:33 < dammsan> i did not get the cover letter +10:33 < dammsan> for some reason i could not find patch 0/8, so i did not get the full picture +10:33 < dammsan> but the individual patches looked interesting =) +10:33 < geertu> https://www.spinics.net/lists/devicetree/msg173820.html +10:34 < geertu> Some evil spam filter +10:34 < geertu> ? +10:34 < geertu> Let's continue +10:34 < geertu> Topic 2. Special requests +10:34 < morimoto`> wait +10:34 < morimoto`> Your other problems which is related to Salvator-XS information. +10:34 < morimoto`> Renesas IT team is checking our mails, so, I can't answer you in officially, because export paper work is not yet finished (Thats why used "Secret words" in mail). +10:35 < morimoto`> This means, in officially, you never get its information, yet ;P +10:36 < morimoto`> s/never/didn't +10:36 < geertu> ok +10:37 < morimoto`> /me renesas talk +10:49 -!- morimoto` [~user@relprex3.renesas.com] has left #periperi ["ERC Version 5.3 (IRC client for Emacs)"] +10:50 -!- morimoto [~user@relprex3.renesas.com] has joined #periperi +10:50 * morimoto back from Renesas talk +10:52 < geertu> Was it a fruitful talk? +10:55 < morimoto> fruitful export papwer work talk +10:55 < morimoto> thanks +10:56 < geertu> OK +10:56 < geertu> Topic 2. Special requests +10:57 < geertu> Morimoto-san, the mic is yours +10:59 < morimoto> About periupport +11:00 < morimoto> According to Magnus, upport from BSP is now handled by each group leader +11:00 < morimoto> Is this correct ? +11:00 < geertu> morimoto: More or less +11:00 < morimoto> OK, I want to know how to handle it. +11:01 < geertu> The group leaders are supposed to look at the BSP as a low-priority task +11:01 < morimoto> Yes. +11:01 < morimoto> that's OK +11:01 < morimoto> I updated sound related commit on periupport +11:01 < morimoto> which is already upstreamed +11:02 < geertu> Good +11:02 < geertu> I started with the priority H commits +11:02 < morimoto> Nice, thanks +11:02 < morimoto> I want to each member (?) update to related driver/patch/commit +11:02 < morimoto> if possible +11:02 < geertu> I will work down the other priorities +11:03 < morimoto> thanks, but no stress +11:04 < geertu> It would definitely be a good idea if other members look at commits related to drivers they worked on in the past +11:04 < morimoto> Yes, that is easy +11:06 < morimoto> I'm happy if group leader can ask it to members, if possible +11:06 < morimoto> but, low priority +11:06 < morimoto> thats it from me +11:06 < geertu> OK, will do a formalize question +11:07 < geertu> s/formalize/formalized/ +11:07 < morimoto> Thanks a lot +11:07 < geertu> Thank you ! +11:08 < geertu> Do we have other topics to discuss? +11:08 < shimoda> i don't have other topic for now +11:09 < morimoto> ditto +11:10 < dammsan> same here +11:11 < geertu> OK, thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20170426-mm-chatlog b/wiki/Chat_log/20170426-mm-chatlog new file mode 100644 index 0000000..87fce2a --- /dev/null +++ b/wiki/Chat_log/20170426-mm-chatlog @@ -0,0 +1,440 @@ +Multimedia-chat-meeting-2017-04-26 + +<pinchartl> good morning/afternoon [15:55] +<uli___> morning +<morimoto> hi +<neg> morning +<jmondi> hello everyone [15:56] +<pinchartl> everybody is in the room +<pinchartl> but are kbingham and dammsan awake ? +* kbingham is definitely asleep +<pinchartl> :-) [15:57] +<pinchartl> Morimoto-san mentioned that he has a Renesas internal meeting at + 17:00, so let's get started and try to be quick +<pinchartl> topics for the day +<pinchartl> Topic 1. Status check for the multimedia tasks +<pinchartl> Topic 2. Requests from the BSP team +<pinchartl> (from Morimoto-san's e-mail) +<pinchartl> Topic 3. OSS Japan trip +<pinchartl> Topic 4. Next meeting +<pinchartl> anything else ? [15:58] +<pinchartl> I'll take that as a no +<pinchartl> jmondi: wanna start ? [15:59] +<jmondi> yeah sure +<jmondi> status update, as reported in the email +<jmondi> A) +<jmondi> - RFC patches to move CEU driver away from soc-camera +<jmondi> - studied hw platform to test it with a real camera, and possibily + not from remote [16:00] +<jmondi> B) +<jmondi> - Add OF support to that driver and add support to RZ device tree for + CEU driver +<jmondi> - That would maybe require cooking up a device tree for GR-Peach, if + that will ever run mainline [16:01] +<jmondi> C = D = Null +<jmondi> -- eot -- +<pinchartl> thank you +<pinchartl> a device tree for GR-Peach would be cool +<pinchartl> let's see what will happen +<jmondi> yeah, -would be- [16:02] +<pinchartl> I've seen your ceu RFC, I'll review that +<jmondi> please bear with me :) +<pinchartl> :-) +<pinchartl> what do you mean by "possibly not from remote" ? [16:03] +<pinchartl> will you get a Migo-R board ? +<jmondi> I don't think so +*** horms (~horms@217.111.208.18) has joined channel #periperi +<pinchartl> what do you mean then ? :-) +<jmondi> I want to use a GR-Peach, as it's the only RZ board I have with VIO + signal routed to connectors to test the driver +<jmondi> otherwise, I will have to test it from remote, on Migo-R, in MAgnus' + board farm [16:04] +<pinchartl> ok [16:05] +<pinchartl> next, kbingham +<kbingham> So I have mostly been working on ADV7482 with neg. [16:06] +<kbingham> The driver is now split into two subdevices (as a staging process) + for HDMI and AIN/CVBS... +<kbingham> These are registered and linked by rcar-vin using the device and an + extra 'port' specifier to determine which one is which from the + single DT node. [16:07] +<kbingham> Niklas has also been looking at incremental registrations, and I + plan to follow his work to further split into more subdev's - such + that the rcar vin registers the TXA/TXB subdevs, and they in turn + then register links to both the AIN/HDMI [16:08] +<kbingham> I've also started work on getting my older patchsets up to date for + ML, and I hope to get those posted in the next couple of weekes. + [16:09] +<kbingham> FInally - I have successfully commenced a local fork() which is due + for completion around Late October, and thus I predict I will not + be able to attend ELCE this year +<pinchartl> congratulations for that project ! you'll realize that, like + software development, it will keep you awake at night :-) + [16:10] +<kbingham> I work better at night :) [16:11] +<dammsan> congrats!! +<jmondi> kbingham: if I got this right, congrats! +<kbingham> Thanks :) +<pinchartl> you mentioned in your e-mail report a minor bugfix to rcar-vin + [16:12] +<pinchartl> has it been posted ? +<kbingham> Yes, it was posted. +<kbingham> It is *very* minor really :) +<pinchartl> with a Fixes: tag ? +<kbingham> Indeed - with a Fixes: tag, and it should have a -renesas in the + authorship - so any automated tools should be able to pick it up if + they hvae been developed. [16:13] +<pinchartl> thank you +<kbingham> Althoguh - as a trick to test the tooling ... +<pinchartl> :-) [16:14] +<kbingham> it has been sent from git-send-mail which defaulted to from: + kbingham@kernel.org - however the Patch authorship is certainly + From: kieran.bingham+renesas@ +<pinchartl> next, me [16:15] +<pinchartl> I've worked on the MAX9286+MAX9271+OV10635 camera support +<pinchartl> the first step is to get it working with the BSP kernel +<pinchartl> status: done +<pinchartl> the next step is to port it to mainline, using the BSP code for + the rcar-vin driver +<pinchartl> status: done [16:16] +<pinchartl> the next step is to move it from the legacy soc_camera rcar-vin + driver to the new rcar-vin driver +<pinchartl> status: http://www.ideasonboard.org/frame-000008.jpg +<dammsan> nice!! [16:17] +<uli___> impressive +<pinchartl> the code is available from git://linuxtv.org/pinchartl/media.git + vin/gmsl +<uli___> is that a famiclone? :) +<pinchartl> I'll add my kernel config, my buildroot config and instructions to + capture images on the wiki +<dammsan> yeah, providing vin analogue for one of the boards [16:18] +<pinchartl> I've also cleaned up the MAX9286+MAX9271+OV10635 code +<pinchartl> it's split in two drivers, one for the max9286 and one for the + max9271+ov10635 camera (called rdacm20, after the name of the + camera) +<pinchartl> they're both horrible +<pinchartl> but we'll hopefully be able to fix that later +<pinchartl> I've sent a list of hacks performed by the drivers at the I2C + level to Niklas to give him and Wolfram material for their work on + the topic [16:19] +<pinchartl> for the next two weeks, I plan to clean up the code a bit more, + and concentrate on my base contract to address smaller VSP and DU + tasks (including requests from the BSP team for which Porimoto-san + sent a nice reminder) [16:20] +<pinchartl> s/Porimoto-san/Morimoto-san/ +<pinchartl> (P and M are next to each other on Belgian keyboards) +<pinchartl> dammsan: would it be possible to install a small lamp in front of + the cameras ? it could even be something LED-based connected to + the camera power, so it would be off by default [16:21] +<pinchartl> otherwise it's difficult to perform tests during most of the day + here :-) +<dammsan> i'll see what i can do +<kbingham> pinchartl: You just need to improve the contrast response for dark + images :) [16:22] +<pinchartl> thank you [16:23] +<pinchartl> I forgot to mention that the tests have only been performed with a + single camera +<pinchartl> next, dammsan [16:25] +<pinchartl> or maybe not [16:26] +<pinchartl> maybe Magnus is now trying to find a lamp +<pinchartl> in the meantime, next, morimoto +<morimoto> A) What have I done since last time +<morimoto> - OF-graph update, but nothing happen +<morimoto> - OV camera datasheet export paper work (Officially, you are not + yet received OV camera datasheet) +<morimoto> - kicked IMI guy for camera board question (you could received + information from them) [16:27] +<morimoto> - fixed sound noise issue which is reported from BSP team. I posted + fixup patch to ML and it was accepted +<morimoto> - I had meeting with BSP team. I and BSP team will have this + meeting once per month. we can talk it in Topic 2 +<morimoto> B) What I plan to do till next time +<morimoto> - continue OF-graph posting. Japan will have long holiday from 28th + April to 7th May. So I will repost before holiday +<morimoto> C) Problems I have currently +<morimoto> D) Posted/Accepted bugfix patch +<morimoto> No, Sir +<morimoto> --EOT-- +<pinchartl> thank you +<pinchartl> next, neg [16:28] +<neg> A) [16:29] +<neg> - Patch to support to V4L2 for incremental async subdevice binding +<neg> - Adapted VIN and CSI-2 patches to make use of incremental async, +<neg> the code is cleaner and it will support arbitrary pipeline +<neg> lengths, that is both on-board use-case (ADV7482) and 8 channel +<neg> prototype. +<neg> - Started to plan 8 channel i2c prototype meeting with Wolfram in +<neg> Stockholm. Due to take place Monday 8th of May. If anyone have any +<neg> concerns about this topic please send them to Wolfram and me. +<neg> Laurent have already provided lots of nice feedback from his work +<neg> with the existing code. +<neg> - Passthru mode of i2c traffic +<neg> The two max9286 are connected to the same I2C bus and by +<neg> default they seems to broacast I2C messages to the other side +<neg> over the GSML bus. The devices on the other side of the +<neg> max9286 have same i2c addresses so special care is needed +<neg> here. +<neg> - Shared power supplies for all cameras +<neg> There is a delay needed when powering on the cameras, in the + [16:30] +<neg> prototype code it's set to wait 8 secondes, per camera. +<neg> - I2C address translation +<neg> The max9286 support address translation which is both +<neg> problematic but could be used to solve the i2c passthru issue +<neg> if handled with care. +<neg> - Had discussions with Kieran to hand over the ADV7482 prototype. +<neg> B) +<neg> - Post patches for incremental async subdevice +<neg> - See if it's feasible to add a new V4L2 operation to help map a DT +<neg> port/endpoint to a media controller pad. If so post patches for +<neg> this and make use of it in the CSI-2 driver. +<neg> - Post new versions of Gen3 VIN and CSI-2 series to incorporate bug +<neg> fixes and reports from Kieran and Laurent and the incremental +<neg> async subdevice changes to create a better base for the 8 channel +<neg> prototype work. +<neg> C) +<neg> None +<neg> D) +<neg> None +<neg> --eot-- +<pinchartl> thank you [16:31] +<pinchartl> regarding B.2, I think it should be a media controller operation, + not a V4L2 operation +<pinchartl> next, uli___ [16:32] +<neg> thanks, will start my work as a media controller operation then :-) + [16:33] +<uli___> > A) What have I done since last time +<uli___> Researched with Magnus on what we can hook up to the V2H board to get + a +<uli___> working camera setup. (We drew a blank. While the MAX +<uli___> serializer/deserializer chips are claimed to be compatible between + families +<uli___> for basic operation, they do not all support the same physical + interfaces. +<uli___> The existing Renesas camera hardware is coax, but the MAX9260 on the + V2H +<uli___> board only supports STP...) +<uli___> > B) What I plan to do till next time +<uli___> Prototype for multiplexing the V2H board's four MAX9260s to one SCIF + using +<uli___> the board's GPIO-based switch. +<uli___> > C) Problems I have currently +<uli___> None. +<uli___> > D) Posted/Accepted bugfix patch +<uli___> None. +<uli___> (did that work? i'm having cut-and-paste problems here...) +<uli___> anyway, EOT +<pinchartl> it's definitely readable :-) [16:34] +<pinchartl> thank you +<pinchartl> Topic 2. Requests from BSP team [16:35] +<pinchartl> morimoto: would you like to drive this, and explain about the + monthly meeting ? +<morimoto> OK [16:36] +<morimoto> I and BSP team talk about remaining request +<morimoto> some of them is new +<morimoto> some of them are already requested to you guys, but nothing happen + today [16:37] +<morimoto> * DU fence has missing feature +<morimoto> This is new +<morimoto> Can you read my email for detail ? +<morimoto> Maybe this is for Laurent (?) +<morimoto> * confirm DMA ATTR SKIP CPU patch +<morimoto> This is forgotten request [16:38] +<morimoto> Oops. +<morimoto> no +<morimoto> this is new one +<morimoto> I think Laurent or Kieran can handle it ? +<morimoto> Subject: VSP1 driver cache flush +<morimoto> Date: Mon, 17 Apr 2017 16:25:42 +0900 +<pinchartl> I'll handle the DU/VSP IOMMU support as part of my base contract, + yes +<morimoto> Thanks +<pinchartl> it will include the patch you mentioned +<morimoto> * confirm DU/VSPD initial sequence +<morimoto> This was requested long time ago [16:39] +<morimoto> Subject: Re: DU/VSPD initial sequence +<morimoto> Date: Wed, 11 Jan 2017 11:07:48 +0900 +<pinchartl> I'll work on that with Kieran, depending on who finds time first +<morimoto> OK +<morimoto> BSP team want to get it until 7/M if possible +<morimoto> Is it possible ? +<pinchartl> I think so, yes +<morimoto> Thanks +<morimoto> * confirm V4L2_FIELD_SEQ_TB/TB status +<morimoto> This is maybe for Niklas +<morimoto> +<pinchartl> we might create an additional task for the second part of Q2 for + the DU/VSP initial sequence [16:40] +<morimoto> Subject: [periperi] Question about V4L2_FIELD_SEQ_TB/TB on VIN +<morimoto> Date: Tue, 7 Mar 2017 10:34:16 +0900 +<pinchartl> yes, that's for Niklas I think +<pinchartl> neg: what do you think ? +<morimoto> pinchartl: thanks +<neg> Yes, it's for me and I think it could be possible to add + V4L2_FIELD_SEQ_TB/TB +<morimoto> neg: nice to know +<neg> But I really hope at least the Gen2 cleanup sereis needs to be picked up + first since I made some mistakes in the oringal code regarding scaling + which would interfere with this [16:41] +<pinchartl> neg: you can organize the branches any way you like, feel free to + develop on top of the Gen2 cleanup series +<morimoto> neg: no stress. I can explain it to BSP team [16:42] +<morimoto> pinchartl: do you have any commnets/idea for [1/5] ? +<pinchartl> morimoto: regaring "DU fence has missing feature", you mentioned + in your e-mail +<pinchartl> "Then, they created and tried gem_prime_res_obj.patch (I + attached)." +<pinchartl> but you haven't attached anything :-) +<morimoto> Oops +<morimoto> I will +<neg> ofc, I just don't want to add more to the already 50+ pile out of tree + patches of VIN :-) And from the initial discussion this was a low prio + thing, if that changes I will ofc work ontop of the out of tree patches +<pinchartl> thank you [16:44] +<pinchartl> I think this closes this topic, unless you have something to add +<pinchartl> I'll check the DU patch when I'll get it and reply by e-mail +* morimoto I posted mail which has mising patch/log [16:45] +<pinchartl> thank you [16:46] +<pinchartl> Topic 3. OSS Japan trip +<pinchartl> first question, have you all booked your flights and hotels ? +<kbingham> I have booked flights - and *partial* hotel. +<jmondi> both booked [16:47] +* morimoto time to go to Renesas meeting +<kbingham> I have booked in the hilton from the 28th to the 3rd of june. +<pinchartl> morimoto: have fun :-) +<pinchartl> thank you for joining +<kbingham> but the hilton on the day I arrive (27th) and on the Saturday (4th) + are towards the end of 'prohibitively expensive' in my opinion +<neg> I have both flight and hotell booked [16:48] +<kbingham> I have booked the days that were available at the LF rate, or + similar. +<pinchartl> kbingham: you have told me a few days ago that the hilton LF room + block seemed to have been fully booked. did you get any feedback + from the LF ? +<kbingham> The feedback was that the block had been fully booked on the + sunday, and that I could book from the monday ... +<pinchartl> lovely [16:49] +<kbingham> I was then able to book the 'sunday night' at a rate *less* than + the LF rate - by booking that night separately. +<pinchartl> :-) +<kbingham> The *saturday* night - is still Y 52,250 +<kbingham> And the Saturday night *after* is Y 45,000 +<pinchartl> I'm afraid you'll likely have to consider a different hotel +<kbingham> So I have *not* booked for either of those nights. +<pinchartl> I can recommend a much better hotel than the Hilton for that kind + of price :-) [16:50] +<kbingham> hehe indeed - unless anyone has a twin room and would let me crash + in their spare bed for the night :) +<pinchartl> I'll arrive on Sunday morning so I'm afraid I can't help you :-) +<neg> kbingham: what was the total for your hilton booking? I think I got the + LF rates for all nights and my total was Y 211.300 [16:51] +<pinchartl> neg: what are the dates ? +<neg> 28 May to 04 Jun [16:52] +<kbingham> For arrival I'll find something central and cheap that I can book + for the night before I arrive (at my own cost) so that I have a bed + to check into immediately on arrival if needed. +<kbingham> (I arrive at 7am, and I'd rather have a room I can dump my stuff in + - and get a shower) +<jmondi> kbingham: let me check my dates and what kind of room I have booked +<pinchartl> neg: for the same dates I got ¥142,247 + taxes + service charge = + ¥174,998 +<kbingham> 29th to the 3rd, I got a total at 124,999 Y [16:53] +<pinchartl> (whatever the service charge is...) +<jmondi> kbingham: I arrive the 27th as well +<neg> pinchartl: ohh that was inc taxes and serivce, without Y 172 000 +<pinchartl> neg: I don't think you got all the nights at the LF rate then + [16:54] +<neg> pinchartl: thanks, just wanted to make sure they did not try to fool me + :-) [16:55] +<pinchartl> neg: I'll let you see with Magnus what can be reasonably expensed + :-) +<jmondi> why is my rate so different from yours???? [16:56] +<kbingham> jmondi: What was your rate? +<pinchartl> jmondi: what are your dates and rate ? [16:57] +<jmondi> May 28th - Jun 2ns ~30K +<neg> pinchartl: more expensive rooms just meens we need to bring larger + bottels of booze as gifts, right? +<jmondi> s/ns/nd/ +<jmondi> may 27th 57.500 +<jmondi> Jun 2ns - June 4th 31.500 +<kbingham> jmondi: Ouch :) +<pinchartl> jmondi: I assume because you booked late and didn't get the LF + room block rate [16:58] +<jmondi> I assumed that was the LF rate +<kbingham> jmondi: Convert 57500 Yen to EUR :) +<pinchartl> I don't think you can expense ¥57.500 for one night :-) +<pinchartl> even ¥31.500 is quite high +<dammsan> [5~for domestic travel renesas usually limits to 10.000 jpy per + night [16:59] +<dammsan> some exception can be made for you guys, but 50.000 is way off +<jmondi> WHAAAAT? +<kbingham> jmondi: hahah +<pinchartl> jmondi: I see you have converted :-) +<kbingham> jmondi: And now you've realised why I chose not to book that night + :) +<pinchartl> dammsan: I assumed that the LF room rate would be acceptable, but + above that, it seems too high to me +<jmondi> I booked them in block assuming it was the LF rate [17:00] +<jmondi> I will cancel my reservation for the first night +<pinchartl> luckily it's cancellable, yes +<kbingham> jmondi: Indeed - that's what I tried to do as well.. .... Where I + went wrong was checking to see what the breakdown of costs was :) +<jmondi> dammsan: ~30K Y is ok? +<pinchartl> jmondi: if you try to book 29th to 3rd separately now you might + still be able to get the LF rate [17:01] +<pinchartl> and possibly a good rate if you book the 28th separately too, as + Kieran did +<pinchartl> anyway, I'll let you sort that out with Magnus [17:02] +<kbingham> pinchartl: jmondi: Sorry - small correction on the '28th being + cheaper' +<jmondi> from 28th to 2nd June I have 29500 +<dammsan> i think you should follow pinchartl +<kbingham> pinchartl: They tricked me - - They displayed the rate without + taxes, - it came through at 24K JPY +<pinchartl> kbingham: ok +<pinchartl> kbingham: I believe that's the LF rate +<pinchartl> ¥25K / night [17:03] +<pinchartl> that's roughly 200€ +<kbingham> jmondi: We should collaborate on our arrival hotel - and what ever + we get - get the same. +<dammsan> i think roughly 200 EUR is acceptable +<pinchartl> dammsan: thank you for the confirmation +<pinchartl> the other point I wanted to discuss [17:04] +<pinchartl> is our plans for Saturday the 3rd +<pinchartl> I propose spending the whole day together +<neg> yea Y 24 500 / night is what I also have + taxes and services +<pinchartl> and while we can certainly visit Tokyo, several of us have done so + already [17:05] +<jmondi> kbingham: we should, let's sync offline +<pinchartl> so another option is to spend the day outside town, doing + something a bit different +<jmondi> neg: I assume 24.500 + tax and services is roughly the 29.500 I have + for the 28th->2nd +<pinchartl> for instance, a day trip to mount Fuji [17:06] +<pinchartl> proposals are welcome +<kbingham> pinchartl: I would be very keen on a mount-fuji trip [17:07] +<pinchartl> could you all have a look and tell me if there's anything you'd + like to see/do around Tokyo ? +<neg> pinchartl: I will reread Tokyo Vice and get back to you.. ;-) +<pinchartl> dammsan: it's very likely less exotic for you, but recommendations + are welcome :-) +<neg> mount Fuji sounds fun, is it a valid trip during the rain seasson? + [17:09] +<pinchartl> neg: that's where I'd like recommendations from our locals :-) + [17:10] +<neg> The biggest lesson I learnt last time was to next time bring more + t-shirts :-) +<pinchartl> hehe [17:11] +<pinchartl> Topic 4. Next meeting +<pinchartl> I propose two weeks from now, on 2017-05-10, 08:00 GMT / 09:00 + CEST / 10:00 EEST / 16:00 JST [17:12] +<kbingham> http://zoomingjapan.com/travel/day-trips-from-tokyo/ +<kbingham> pinchartl: Ack on 10th May. [17:13] +<neg> 10th of May works for me +<pinchartl> let's go for the 10th of May then [17:15] +<pinchartl> it nobody has anything to add, I propose adjourning this + meeting. does anyone second ? +<neg> seconded +<dammsan> pinchart: i moved the cameras to let you look at the board leds +<pinchartl> dammsan: thank you [17:16] +<dammsan> hopefully it is better +<pinchartl> thank you all for attending diff --git a/wiki/Chat_log/20170509-core-chatlog b/wiki/Chat_log/20170509-core-chatlog new file mode 100644 index 0000000..ea061c7 --- /dev/null +++ b/wiki/Chat_log/20170509-core-chatlog @@ -0,0 +1,190 @@ +Core-chat-meeting-2017-05-09 + +10:06 < geertu> Wecome to today's Core Group Chat +10:06 < geertu> s/Wecome/Welcome/ +10:06 < geertu> Agenda: +10:06 < geertu> 1. Status updates +10:06 < geertu> Sort -R says I'm first +10:07 < geertu> A) What have I done since last time +10:07 < geertu> - Published drivers/{clk,soc}/renesas/Kconfig rework +10:07 < geertu> - Published R-Car Gen2 CPG/MSSR +10:07 < geertu> - Published v2 of DTSI board sharing (Salvator-X and ULCB) +10:07 < geertu> - Added more comments to periupport +10:07 < geertu> B) What I plan to do till next time +10:07 < geertu> - Add more comments to periupport +10:07 < geertu> - R-Car H3 ES2.0 DTS v2 +10:07 < geertu> C) Problems I have currently +10:07 < geertu> - What are the official names of the different versions of the R-Car +10:07 < geertu> H3/M3 SiPs? +10:07 < geertu> D) Posted/Accepted bugfix patches +10:07 < geertu> - None +10:07 < geertu> EOT +10:07 < geertu> Next is Jacopo +10:10 < geertu> Oh, he has no updates +10:10 < geertu> Next is Shimoda-san +10:10 < shimoda> yes +10:11 < shimoda> A) What have I done since last time +10:11 < shimoda> - Continue to investigate IPMMU workaround for Xen. +10:11 < shimoda> - However, HW guy found that the workaround way is not good. +10:11 < shimoda> So, he re-investigate the issue if we can have another way for workaround. +10:11 < shimoda> - No core task for linux kernel upstreaming. +10:11 < shimoda> B) What I plan to do till next time +10:11 < shimoda> - No Core task for next time. +10:11 < shimoda> C) Problems I have currently +10:11 < shimoda> - I have concern when IPMMU driver for Gen3 is merged into iommu subsystem repo. +10:11 < shimoda> D) Posted/Accepted bugfix patch +10:11 < shimoda> - Nothing. +10:11 < shimoda> EOT +10:12 < geertu> Thank you Shimoda-san. I assume we'll revise IPMMU when Magnus talks +10:12 < geertu> Next is Morimoto-san +10:13 < morimoto> I'm still under Renesas talk +10:13 < morimoto> sorry +10:13 < geertu> OK +10:13 < geertu> Let's postpone +10:13 [Users #periperi] +10:13 [ dammsan] [ jmondi ] [ marex-cloud] [ neg ] +10:13 [ geertu ] [ kbingham] [ morimoto ] [ pinchartl] +10:13 [ horms ] [ Marex ] [ mturquette ] [ shimoda ] +10:13 -!- Irssi: #periperi: Total of 12 nicks [0 ops, 0 halfops, 0 voices, 12 normal] +10:13 < geertu> Ulrich is not here +10:13 < geertu> Next is (IP)M(M)agnUs +10:14 < dammsan> hehe +10:14 < jmondi> ups, sorry, I missed you have called my name Geert... No updates from me, yes +10:14 < dammsan> i've been doing this and that, including some MTU fixes for remote access, +10:15 < dammsan> getting Migo-R to boot mainline and also updating the IPMMU driver +10:15 < dammsan> i have no code to share about the IPMMU driver yet, but this is my main focus from now on +10:15 < neg> Why is Migo-R interessting? +10:15 < dammsan> i would like to ask for your help with PFC on Migo-R, but maybe we can deal with that later +10:16 < geertu> Sure +10:16 < dammsan> Migo-R has CEU devices for camera development +10:16 < neg> ahh +10:16 < dammsan> that's it from my side +10:17 < geertu> Thank you, Magnus +10:17 < geertu> IPMMU is getting more and more complicated. +10:17 < geertu> The trick with xlate() no longer works, as errors are now checked, thanks to a two year old patch from Laurent, which was picked up by someone else +10:18 < dammsan> thanks guys =) +10:18 < geertu> Next is Niklas +10:18 < neg> A) No core task since last time +10:18 < neg> B) Try to move '[PATCH 0/3] dmaengine: rcar-dmac: fix resource freeing synchronization' forward. +10:18 < neg> C) None +10:18 < neg> D) None +10:19 < neg> EOT +10:20 < geertu> Thank you, Ni9klas +10:20 < geertu> s/Ni9klas/Niklas/ +10:21 < geertu> Next is Marek +10:21 < Marex> A) What have I done since last time +10:21 < Marex> - Submitted V2 of ROHM PMIC patches -> GPIO and Regulator bits in v4.12 -> MFD part waiting for Lee Jones (Mr. MFD), likely 4.13 +10:21 < Marex> - Fixed GyroADC driver DT clock bindings +10:21 < Marex> - Prepared r8a7796 mainline U-Boot patches for submission +10:21 < Marex> B) What I plan to do till next time +10:21 < Marex> - Submit U-Boot patches adding r8a7796 support and Salvator-X M3 support for mainline inclusion (incl. USB, ethernet, SD/MMC support) +10:21 < Marex> C) Problems I have currently +10:21 < Marex> - NONE +10:21 < Marex> D) Posted/Accepted bugfix patch +10:21 < Marex> - Patch from Morimoto-san superseding my r8a7791 audio fix: https://patchwork.kernel.org/patch/9691497/ +10:21 < Marex> EOT +10:21 < geertu> Thank you, Marek +10:22 < geertu> Next is Laurent +10:22 < geertu> lurking? +10:22 < pinchartl> yes :-) +10:22 < pinchartl> nothing to report for core +10:23 < geertu> Thank you, Laurent +10:23 < geertu> Last but not least is Simon +10:23 < horms> Todo Update +10:23 < horms> NULL +10:23 < horms> A) What have I done since last time +10:23 < horms> B) What I plan to do till next time +10:23 < horms> No Core task at this time +10:23 < horms> C) Problems I have currently +10:23 < horms> D) Posted/Accepted bugfix patch +10:23 < horms> None +10:23 < horms> --- +10:24 < geertu> Thank you, Simon +10:26 < geertu> I guess Morimoto-san is still meeting, to negotiate his insurance. It would be really bad for Renesas business if something happened to him! +10:27 < geertu> Jacopo: Do you want something to say about RZ/A1 PFC? +10:27 < jmondi> eh +10:27 < jmondi> I would have a lot of things to say :p +10:28 < geertu> I think you're suffering from the "code arriving just too late for the merge window has 7 extra weeks for biekshedding +10:28 < geertu> s/biekshedding/bikeshedding syndrome"/ +10:28 < jmondi> seriously, seems like Linus is now for "renesas,bi-directional" etc generic properties +10:29 < horms> its almost like some of these people don't have enough to do with their time +10:29 < jmondi> which is fine, if this means we can go forward on this... I will give some time to others to reply, and get back with a slightly different proposal +10:29 < jmondi> but -maybe- this will finally see the light of the day +10:30 < geertu> Let's hope so +10:30 < jmondi> indeed :) +10:30 < geertu> Does anyone else has something to discuss (I know Magnus and Migo-R PFC) +10:31 < geertu> ? +10:32 < neg> I have nothing +10:32 < horms> I was only wondering if anyone is waiting for me for anything - e.g. patches I have missed +10:33 < dammsan> horms: the recently PMIC driver and MAX chip from Marek and Jacopo want to get integrated +10:34 < dammsan> maybe you've got that sorted already +10:34 < dammsan> they will be in -rc1 +10:34 < Marex> dammsan: I think only the GPIO and Regulator bits will be in rc1 ... Lee didn't pick the MFD part +10:34 < geertu> "arm64: dts: salvator-x: Add current sense amplifiers" is in Simon's tree +10:34 < Marex> (yet) +10:35 < dammsan> good then i'll be silent =) +10:35 < horms> likewise +10:37 < geertu> OK, I think we can move on to Magnus' PFC problem? +10:37 < dammsan> Some detail exists in recently sent email "Running upstream Linux on Migo-R" +10:37 < dammsan> The boot log includes the following error: +10:38 < dammsan> sh-pfc pfc-sh7722: pin 0 already registered +10:38 < dammsan> sh-pfc pfc-sh7722: error during pin registration +10:38 < dammsan> sh-pfc pfc-sh7722: could not register: -22 +10:38 < dammsan> sh-pfc: probe of pfc-sh7722 failed with error -22i think it is relate to the SMSC ethernet error also listed +10:39 < dammsan> may i give this issue to the core group? =) +10:39 < geertu> There doesn't seem to be any message about Ethernet? +10:39 < geertu> I can give it a try +10:40 < geertu> Probably you have no idea which was the latest working version? +10:40 < dammsan> thanks +10:40 < dammsan> i was hoping that jacopo could help since he is the master of PFC +10:40 < dammsan> but it is really up to you guys how to handle it +10:40 < dammsan> i've tested a couple of different kernel versions +10:41 < dammsan> v2.6.34 v3.6.39 v3.19 v4.11 +10:41 < dammsan> v2.6.39 is should be +10:42 < dammsan> v2.6.39 seems to work pretty well with the CEU and all according to the boot log +10:42 < dammsan> v4.11 requires disabling of the SMSC ethernet to proceed to the initramfs shell prompt +10:42 < jmondi> dammsan: not sh PFC, sorry :P +10:42 < geertu> Ah, you disabled Ethernet +10:43 < dammsan> yeah to move forward +10:43 < jmondi> dammsan: also please have a look at my proposal to use Peach/Genami for CEU :) +10:43 < dammsan> i think v3.19 may have output other PFC errors, don't recall exactly +10:43 < geertu> PFC worked in v2.6.39? +10:43 < dammsan> yes i believe so +10:43 < dammsan> mainline used to be fine about 5 years ago +10:44 < geertu> Probably it's a conflict between traditional fixed pin numbers and new DT dynamics +10:44 < dammsan> might be +10:44 < dammsan> jmondi: feel free to poke around with your own hardware, but don't ignore existing working platforms +10:45 < jmondi> dammsan: working you said? :P +10:45 < dammsan> yeah +10:45 < dammsan> its a software issue +10:45 < dammsan> on a known working platform +10:45 < dammsan> as opposed to unknown status on an unknown platform =) +10:46 < jmondi> eheh, we live on the edge! +10:46 < geertu> OK, I'll see if I can reproduce the problem +10:46 < dammsan> thanks, do you need anything from me? +10:46 < dammsan> you may want to use the same tool chain +10:47 < dammsan> (which i'm not 100% sure if it is correct to be honest) +10:47 < geertu> I have cross-compilers for about everything +10:47 < geertu> sh4-linux-gcc 4.6.3 +10:47 < dammsan> great, let me know when sh7722 support gets merged upstream in gcc =) +10:47 < dammsan> and glibc =) +10:47 < dammsan> but anyway +10:48 < geertu> gcc-4.6.3-nolibc ;-) +10:48 < dammsan> i wish you the best of luck +10:48 < dammsan> i used to only stick to crosstool +10:48 < dammsan> then i was introduced to the hell also known as out-of-tree toolchain patches +10:49 < dammsan> i think sh7750 should have a good chance, but SH4ALDSP may not +10:49 < dammsan> work as-is out of the box +10:49 < dammsan> there is also half-assed FPU emulation in the kernel +10:49 < dammsan> let me know if you want the binary +10:51 < geertu> ok +10:51 < geertu> Anything else to discuss? +10:53 < jmondi> not from me! +10:53 < horms> geertu: do you have a cross compiler for ARCH=arc ? +10:53 < geertu> horms: No +10:54 < horms> np, it was a long shot +10:54 < geertu> I believe it's not available from kernel.org crosstool +10:54 < horms> it wasn't when I checked last week +10:55 < geertu> You can ask Arnd. If I send a patch for an issue with my old m68k gcc 4.1.2, he replies with a list of gcc versions that show the same warning ;-) +10:55 < horms> ok, thanks for the idea +10:55 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20170510-mm-chatlog b/wiki/Chat_log/20170510-mm-chatlog new file mode 100644 index 0000000..42ab2d7 --- /dev/null +++ b/wiki/Chat_log/20170510-mm-chatlog @@ -0,0 +1,499 @@ +Multimedia-chat-meeting-2017-05-10 + +<dammsan> pinchartl: if you could distill some additional task candidates that + would be great [15:59] +<dammsan> but it does not have to happen right now +<pinchartl> that's topic 2 isn't it ? :-) +<dammsan> good point =) +<dammsan> nice that someone is awake at least [16:00] +<pinchartl> :-D +<pinchartl> let's get started then +<pinchartl> Topic 1. Status check for the multimedia tasks +<pinchartl> jmondi: as you're the last one to have posted your status update, + you can start [16:01] +<jmondi> that's fair +<pinchartl> (not sure whether that will be a good enough incentive to get the + reports earlier in the future, let's see) +<jmondi> at least I can still go from the top of my head +<jmondi> A) +<jmondi> - Sent v3 of CEU driver [16:02] +<jmondi> - Working on Migo-R remote board to have CEU probe at least +<jmondi> - trying to build a local test platform with RZ devices +<jmondi> B) +<jmondi> - I expect a lot of review comments on CEU driver +<jmondi> - Have CEU probe on Migo-R [16:03] +<jmondi> - Have a test platform where I can at least run mainline and test the + driver +<jmondi> C = D = None +<jmondi> -- eot -- +<pinchartl> thank you [16:04] +<pinchartl> speaking of review comments +<pinchartl> I'd like the rest of the team to feel free to cross-review patches +<pinchartl> I certainly want to review them myself too +<pinchartl> but there's no reason for me to be the only reviewer +<neg> I agree, I will try to do more reviews in MM [16:05] +<pinchartl> neg: thank you +<dammsan> question: Geert seems to have sent a patch to fix the sh7722 PFC + issue, who can test and reply to him? +<kbingham> Also agree here! - I've started with some of Negs ' :) - but that + was easy becasuse I was looking at his patches directly. + [16:06] +<jmondi> dammsan: I will +<dammsan> great thanks +<pinchartl> dammsan: I believe that Geert has tested the patches, but it's of + course nice to double-check +<pinchartl> jmondi: thank you +<jmondi> I already planned to do so yesterday, but I failed to do so +<dammsan> nice with a tested-by tag +<pinchartl> uli___: as you're second last to have posted your status update, + you're next :-) [16:07] +<uli___> fair enough :) +<uli___> so i did a little stub driver for the max9260 using serdev +<uli___> seems pretty straightforward +<uli___> but it took me a while to figure out that the max9260 always talks + uart on the controlling side [16:08] +<uli___> even though it is capable of both i2c and uart on the same pins +<uli___> anyway, i got my hands on two chips, and i'll wire them up to the + salvator-x board +<uli___> and see that i can get it to talk +<uli___> i have vays... [16:09] +<uli___> scnr +<pinchartl> nice project +<pinchartl> just out of curiosity, what's the MAX9260 package ? +<uli___> tqfp +<uli___> at least mine is +<pinchartl> 0.65mm or 0.80mm ? +<uli___> .65 +<pinchartl> that's on the verge of becoming painful [16:10] +<dammsan> uli___: any reason for not using remote access? +<dammsan> if it is not working let me know [16:11] +<uli___> nothing wrong with it, i just dislike remote access. +<neg> uli___: Do you mean that the max9260 only can be controlled using uart + in your setup or at all? Is it still capable of beeing controlled over + i2c if the hw around it where different? +<uli___> dammsan: i'll try it eventually, of course, but i'd like to have + something to yell at first [16:12] +<dammsan> ok ok +<uli___> neg: on the local side (the one that sends the commands), it is + always uart +<uli___> but the link can be configured in both ways, and the other way + around, it can talk either uart or i2c +<pinchartl> uli___: are you (or do you plan to) use the serdev API ? [16:13] +<uli___> i do +<neg> uli___: ahh I see, thanks for the clearification :-) +<uli___> and then i intend to look at the gose vin dt thing [16:15] +<uli___> that's it for now +<pinchartl> thank you +<pinchartl> next in report order, Morimoto-san [16:16] +<morimoto> OK +<morimoto> A) What have I done since last time +<morimoto> - Finally Sound OF-graph DT which is needed for HDMI sound was + accepted, but not yet applied, because of merge-window. +<morimoto> - BSP team want to use AGL, and has issue on sound. I had worked + with them. it seems AGL is using SMACK security, and it seems be + reason of sound noise. +<morimoto> - BSP team noticed 24bit sound data noise (not for AGL), and I'm + helping for debugging. It seems related to HW issue, but not sure + yet. +<morimoto> - BSP team want to use ADSP on ALSA. We will have meeting with them + tomorrow. +<morimoto> B) What I plan to do till next time +<morimoto> - Wait OF-graph DT applying. Then, post HDMI sound patch-set +<morimoto> - post stalled patches (because of OF-graph) to ML +<morimoto> - Help BSP team +<morimoto> C) Problems I have currently +<morimoto> D) Posted/Accepted bugfix patch +<morimoto> No, sir +<morimoto> --EOT-- +<pinchartl> thank you +<pinchartl> looks like the BSP team always needs your help [16:17] +<pinchartl> you're becoming their super hero :-) +<morimoto> pinchartl: Unfortunately +<pinchartl> you have in your status report e-mail enquired about multiple work + items, let's go through them [16:18] +<pinchartl> * Fence for VSP +<pinchartl> this is not in my base task, as I have (at least temporarily) + retired from V4L2 upstream development due to conflicts with the + V4L2 maintainer +<pinchartl> however +<pinchartl> while I don't want to jinx it by making early announcements + [16:19] +<pinchartl> I hope to get confirmation at the end of the week that things will + get moving forward in V4L2 +<pinchartl> with a setup of co-maintainers proposed to Mauro +<pinchartl> please keep this information to yourselves for now [16:20] +<pinchartl> Mauro isn't aware of it yet +<pinchartl> if it works out well, I will be able to go back to working on + upstream MC and V4L2 APIs +<neg> :-) (wish I could show a bigger smile over irc) [16:21] +<pinchartl> :-) +<pinchartl> I don't expect things to be easy though, but there might be hope +<morimoto> I don't understand detail of your V4L2 problem, but I hope + everything goes to happy direction +<pinchartl> morimoto: in a nutshell, the conflict between the V4L2 maintainer + and me got so bad that I had to stop working on upstream V4L2 + [16:22] +<pinchartl> because I had to stop interact with him at all +<morimoto> him = Mauro ? +<pinchartl> yes +<morimoto> OK, so, this means Fence will be delay [16:23] +<morimoto> ? +<pinchartl> in the best case, delayed. in the worst case, if we don't succeed + moving forward on V4L2, it could be delayed undefinitely + [16:24] +<pinchartl> at least for upstream +<pinchartl> s/undefinitely/infinitely/ +<pinchartl> fences support in V4L2 requires API extensions [16:25] +<pinchartl> and at this time I can't propose new API extensions +<pinchartl> because the maintainer rejects all my proposals +<morimoto> Wow !! very serious ! +<pinchartl> yes :-) [16:26] +<pinchartl> it's been going on for too long +<pinchartl> so I've spent the last month or so to try and find a solution by + discussing the problem with many other V4L2 developers +<pinchartl> if all goes well we will propose something in the next few weeks + [16:27] +<morimoto> OK, nice to know +<pinchartl> I'm sorry for the delay and inconvenience all this is causing, but + there was no other option [16:28] +<pinchartl> * DU Fence is missing about asynchronous +<pinchartl> I saw the e-mail you sent a few days ago, I'll investigate and + reply to it soon +<morimoto> Thank you +<pinchartl> * Cache (DMA ATTR SKIP CPU) problem [16:29] +<pinchartl> it's on my to-do list for the next two weeks +<pinchartl> I'll rebase the code +<morimoto> Thanks +<dammsan> may i interrupt about this topic? +<pinchartl> dammsan: sure [16:30] +<dammsan> it seems to me that the DMA_ATTR_SKIP_CPU prototype patch is a local + reaction to insufficient performance or R-Car Gen3 +<pinchartl> dammsan: partly +<dammsan> however the root cause for this issue seems ignored +<pinchartl> the root cause isn't ignored. we're moving forward with cache + handling support in V4L2 and DRM [16:31] +<dammsan> at least i was told that the performance on Gen2 is different than + Gen3 and because of that this patch was created +<pinchartl> I started with the V4L2 side +<pinchartl> Sakari took my latest patch series and posted a new version a few + days ago +<pinchartl> I plan to review it +<dammsan> yeah ithink i know what the plan is +<pinchartl> so we're moving forward with fixes for the root causes +<dammsan> but i feel that randomly adjusting cache policy might not be the + best solution +<pinchartl> but in the meantime I think that using DMA_ATTR_SKIP_CPU makes + sense +<dammsan> do we know how the performance is affected? [16:32] +<pinchartl> yes +<pinchartl> the issue is that +<pinchartl> the VSP driver handles the cache +<pinchartl> and performs a cache cleaning +<pinchartl> while the memory is actually mapped uncached [16:33] +<pinchartl> so it makes sense to set DMA_ATTR_SKIP_CPU because the memory is + always mapped uncached +<dammsan> well, i can somewhat agree to that +<dammsan> but i don't understand why this is needed on Gen3 and not on Gen2 +<pinchartl> this will need to be revisited when we'll implement support for + cached mappings in the DU driver +<pinchartl> on Gen2 the buffers are allocated in the V4L2 framework [16:34] +<dammsan> of course the architecture has changed +<pinchartl> sorry, I'm mixing two thinks +<pinchartl> s/thinks/things/ +<pinchartl> on Gen2 DU doesn't use the VSP +<dammsan> i just want to avoid papering over things +<pinchartl> the VSP driver function where we need to set DMA_ATTR_SKIP_CPU + isn't called at all on Gen2 [16:35] +<dammsan> so this is for the DU? +<pinchartl> yes it's for the DU +<dammsan> ok +<dammsan> and it is not needed with V4L2 VSP +<dammsan> if so i'm ok +<pinchartl> for V4L2 VSP buffers are handled by videobuf2 and we already do + the right thing +<dammsan> gotcha thanks [16:36] +<pinchartl> you're welcome +<pinchartl> cache issues are always complex [16:37] +<pinchartl> * Request API +<pinchartl> for the same reason as explained with fences support, I had to + stop working on this upstream [16:38] +<pinchartl> I thus passed the project to Google +<pinchartl> Alexandre Courbot (ex-NVidia, he now works for Google Japan) has + taken over +<pinchartl> I've had a few meetings with him to discuss the implementation +<morimoto> Wow ! So, you don't work for "Request API" anymore ? [16:39] +<pinchartl> no I don't +<pinchartl> I had to stop all V4L2 upstream API work [16:40] +<pinchartl> I've explained that before (about a month ago I think, or even a + bit more) +<pinchartl> but clearly not well enough as you're now surprised +<pinchartl> I'm sorry about that +<dammsan> i think i explained this to Morimoto-san before as well [16:41] +<morimoto> OK +<dammsan> but we may have some language barrier +<morimoto> Yes, I think so +<morimoto> I'm sorry too +<pinchartl> it's a very unfortunate situation and I did all I could to avoid + it, but unfortunately all I could wasn't enough +<pinchartl> but I didn't want to give up either, which is why I spent the last + month trying to find a way to short-circuit the V4L2 maintainer + [16:42] +<pinchartl> again, I can't announce anything yet, but I hope to receive a + confirmation by the end of this week that we'll propose a + co-maintainer setup for V4L2 +<pinchartl> I don't expect Mauro to easily accept it though, but we're doing + all we can to propose a gradual and smooth transition to maximize + the chances he will accept [16:43] +<pinchartl> I should be able to tell more next week +<pinchartl> and again, please don't share this outside of the team [16:44] +<pinchartl> * DU / VSP initialize sequence +<pinchartl> on my to-do list for the next two weeks +<pinchartl> I've already started looking into it, it needs a bit more work +<morimoto> pinchartl: can I share this information to BSP team ? +<pinchartl> you can share the problem, and tell them that we're working on + trying to fix it, and that more information is expected by the end + of this week [16:45] +<morimoto> OK, thanks +<pinchartl> but please don't share the fact that we're trying to go for a + co-maintainers setup +<pinchartl> * VIN V4L2_FIELD_SEQ_TB/TB feature [16:46] +<pinchartl> neg: what's your plan ? +<pinchartl> still on your to-do list, based on top of the Gen2 cleanup patches + ? [16:47] +<neg> yes, was hoping to get the cleanups accepted first +<pinchartl> is there anything blocking them beside lack of review ? +<neg> nope +<pinchartl> ok thank you +<neg> as I undertood this was a low prio request, but if that changed I can + rescedule my plan for V4L2_FIELD_SEQ_TB/TB [16:48] +<pinchartl> I'll review them this afternoon. can you send me a pointer to the + patches by e-mail so that I don't forget ? :-) +<pinchartl> morimoto: what's the priority for V4L2_FIELD_SEQ_TB/TB ? +<neg> sure will do, thanks +<pinchartl> (and I assume it's actually V4L2_FIELD_SEQ_TB/BT, not + V4L2_FIELD_SEQ_TB/TB) +<morimoto> pinchartl: priority is not hi [16:49] +<morimoto> but want to have +<pinchartl> ok. it's definitely on the to-do list +<pinchartl> next, dammsan [16:50] +<morimoto> TB/TB <-> TB/BT. I'm shame ;) +<pinchartl> (who should actually have been first, as he sent no status report + at all ;-)) [16:51] +<morimoto> OK, thanks. [16:52] +<morimoto> I will share these information with BSP team +<pinchartl> seems we've lost dammsan +<pinchartl> I'll go next in the meantime +<pinchartl> I've reposted the Gen3 HDMI output DT integration patches [16:53] +<morimoto> Thanks. I will try it +<pinchartl> and asked Simon to merge them when v4.12-rc1 will be released +<pinchartl> I've provided a tag with the patchees +<dammsan> pinchartl: no update here apart from getting Migo-R going +<pinchartl> dammsan: thank you [16:54] +<pinchartl> now that you're back, I'd like to ask you if you have time for a 5 + minutes chat on IRC after this meeting ? +<pinchartl> (continuing with my report) [16:55] +<pinchartl> I've started working on the DU / VSP initialization sequence + [16:56] +<pinchartl> I've also reviewed Wolfram and Niklas' proposal for the I2C + software architecture for the multi-camera setup +<dammsan> sure +<pinchartl> (I'll reply to Wolfram's e-mail about that) [16:57] +<pinchartl> last but not least, I've spent a significant amount of time + handling the fallout of the V4L2 conflicts +<pinchartl> guiding Google with the request API development [16:58] +<pinchartl> and trying to find a solution to the human side of the problem + with other V4L2 developers +<pinchartl> for the next two weeks, I'll [16:59] +<pinchartl> - Look into the DU fence issue reported by the BSP team +<pinchartl> - Cache (DMA ATTR SKIP CPU) performance issue with VSP2 +<pinchartl> - DU / VSP initialization sequence +<pinchartl> and likely more (patch review hopefully) +<pinchartl> that's it for me +<pinchartl> this closes the first topic +<kbingham> pinchartl: Not quite :) +<kbingham> pinchartl: Not that I mind ! +<neg> I would also like to give my status report :-) +<pinchartl> oops sorry :-/ [17:00] +<morimoto> Hehe :) +<pinchartl> I had copied your report in my summary e-mail already +<pinchartl> so I thought you were done :-) +<pinchartl> neg: you're next +<morimoto> In this case, Japanese people uses "orz" +<neg> A) +<neg> - [PATCH] v4l2-async: add subnotifier registration for subdevices +<neg> - [PATCH 0/2] media: entity: add operation to help map DT node to media + pad +<neg> - [PATCH v4 00/27] rcar-vin: Add Gen3 with media controller support +<neg> - [PATCH v6 0/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 support +<neg> - Meeting with Wolfram to discuss DT bindings for 8-ch setup devices. + [17:01] +<neg> - Continued discussions about the ADV7482 with Kieran. +<neg> B) +<neg> - Post v2 of incremental v4l2-async and DT node to media patches, work + done (available in rcar-vin-fwnode-test-3) just need to convince my self + with more testing before posting. +<neg> - Post new version of CSI-2 patches (work done (available in + rcar-vin-fwnode-test-3), more tests. +<neg> - Act on Sakaris comments on Gen3 VIN driver and repost. +<neg> C) +<neg> - None +<neg> D) +<neg> - None +<neg> -- EOT -- +<pinchartl> thank you +<morimoto> http://kage-design.com/i/orz1.jpg +<pinchartl> morimoto: I'm working from a cafe this morning. if I did that I + think people would look at me in a very weird way :-) [17:02] +<pinchartl> kbingham: you're last ;)à [17:03] +<pinchartl> s/;)à/:-)/ +<kbingham> Keeping mine quick, and not jsut copying the email - I've been + working on ADV, which I feel is making good progress - the main + topic at the moment is the async subdevs which need to be matched + by the async framework. I'll be proposing a change to the matchings + for this framework this week. - Otherwise - the ADV748x driver now + has multiple subdevs to represent the entities. +<kbingham> http://janet.linuxembedded.co.uk/board-salvator-mc.png shows the + new layouts +<kbingham> Of course Niklas has helped me with several parts of that - so + thanks neg :) [17:04] +<kbingham> I've also been rebasing, reworking, and retesting my older + patchsets - 3/5 of which are reposted and pull-requested. +<kbingham> The last two caused me a bit more thought and hopefully will be + done soon (partition algorithm work) +<kbingham> Moving forwards over the next two weeks, I expect to see some good + progress on the v4l2-async subdev matching proposal (which will + require changing all the other users ... ugh) - and I hope that all + my existing patchsets will be freshened with an aim for them + getting closer to integration [17:05] +<kbingham> - eot - +<pinchartl> thank you [17:06] +<pinchartl> jmondi: before I forgot, could you try to document the RZ camera + hardware setup you're working on in the elinux.org wiki ? +<pinchartl> s/forgot/forget/ [17:08] +<pinchartl> now we're done with the first topic +<pinchartl> Topic 2. Additional tasks for the second batch of Q2 +<pinchartl> dammsan: how would you like to handle this ? +<pinchartl> we now have a working multi-camera setup [17:09] +<pinchartl> which you considered to be a blocker for the more general + additional tasks that I proposed before +<dammsan> right +<dammsan> i'm ok with more generic tasks +<dammsan> but we may have to adjust the outcome? +<pinchartl> how do you mean ? [17:10] +<jmondi> pinchartl: as soon as I have something assembled together :) +<pinchartl> jmondi: sure [17:11] +<pinchartl> dammsan: have you disappeared again ? [17:12] +<dammsan> nah i'm right here sorry [17:13] +<dammsan> i believe the old proposal included some fixed deliverables +<dammsan> but now kieran is working on the ADV driver +<dammsan> and we have slipped time wise +<dammsan> so some update may be needed to reflect the current state [17:14] +<pinchartl> sure +<pinchartl> what I propose is +<pinchartl> - updating the plan to take new developments into account +<pinchartl> - creating informal tasks based on the plan for the multi-camera + development [17:15] +<pinchartl> - assigning those tasks to developers +<pinchartl> - for those who would work on the multi-camera setup, going + forward with the generic additional task +<pinchartl> - for those who would work on other tasks, creating classic + additional tasks [17:16] +<dammsan> sounds good to me +<pinchartl> I believe you typed the SGTM line before my last item +<dammsan> right, SGTM again =) [17:17] +<pinchartl> thank you :-) +<pinchartl> so, I'd like to ask you all to provide me with a list of items not + related to the VIN multi-camera setup that you think you should + work on as additional tasks [17:18] +<pinchartl> that can be done on IRC or over e-mail +<pinchartl> you can use periperi as a source of inspiration +<pinchartl> and also propose other tasks [17:19] +<pinchartl> (such as V4L2_FIELD_SEQ_TB/BT for Niklas for instance) +<pinchartl> what I'd like to get from this is a good idea of what you'd enjoy + working on +<pinchartl> I'll compile that into a proposal at the end of this week [17:20] +<dammsan> thanks +<dammsan> if you can get the shared multi-camera task done soonish then i can + review this week in the renesas office =) [17:21] +<dammsan> it is up to you +<pinchartl> dammsan: I'll do my best but it will have to wait for tomorrow +<dammsan> sure, no problem [17:22] +<pinchartl> thank you +<pinchartl> this closes topic 2 +<pinchartl> Topic 3. OSS Japan trip +<pinchartl> Magnus has been very nice and booked a meeting space for us + [17:23] +<pinchartl> https://www.airbnb.com/rooms/17013981 +<pinchartl> accommodation is also available there +<pinchartl> how is everybody doing with accommodation ? +* kbingham is very excited for the meeting place. +<kbingham> dammsan: Good work on the meeting room :) +<pinchartl> kbingham, neg, jmondi, do you all have a place to stay at a + reasonable price ? +<neg> I still have my original booking at conference hotel for 28th May -- + 4th of Jun [17:24] +<kbingham> I think me and jmondi will have to share a room on the final + Saturday night at the conference hotel. +<jmondi> I've been able to reserve the conference hotel for the whole period + at a rate very close to the LF proposed one +<kbingham> I don't have a room for arrival - I need to find somewhere else + cheap. +<dammsan> kbingham: thanks, we'll se +<dammsan> e how it goes [17:25] +<jmondi> execept for last day, where price is almost double, but I'll be + sharing with kbingham (as he said) +<pinchartl> ok +<pinchartl> dammsan: will you be staying at the Taito-ku building ? +<jmondi> I'm quite proud of my "hotel room reservation"-foo now.. I had to + make 5 bookings to have the room at those rates :p +<dammsan> pinchartl: i might do so [17:26] +<kbingham> morimoto: dammsan: Could you recommend anywhere (in location terms) + that is good for a new arrival to Japan for lone-ranger sightseeing + upon arrival the weekend before the conference? +<pinchartl> we now need to work on the agenda for the meeting [17:27] +<pinchartl> I want to have time to do hacking all togther +<pinchartl> but there will also be a more regular meeting +<dammsan> kbingham: asakusa or shibuya or shinjuku? +<pinchartl> so please reply to the meeting report with a list of topics you + would like to discuss [17:28] +<pinchartl> and I will then draft the agenda +<pinchartl> I haven't received any proposal for the Saturday after the + conference [17:29] +<pinchartl> I can decide on something by myself, but I'd really appreciate if + you could all take just a bit of time to tell me what you would + enjoy seeing/doing [17:30] +* kbingham enjoys hiking - and seeing cultural / natural aspects. +<pinchartl> I expect feedback from everybody else by e-mail :-) [17:32] +<neg> You will :-) +<pinchartl> next and last topic, next meeting +<pinchartl> two weeks from now is Wednesday 2017-05-24 +<pinchartl> that's the week before the face-to-face meeting +<pinchartl> we could skip it, but I believe it would be useful to keep it, to + avoid spending time face-to-face discussing about topic that can + be handled during our regular bi-weekly meetings [17:33] +<kbingham> I agree..., and keeps the pace. +<neg> I agree too try keeping it to the 2 week schedule +<jmondi> agreed [17:34] +<pinchartl> and also to finalize the agenda +<kbingham> The one following OSS might be worth slipping a week though, + otherwise we will all just say "Went to japan" +<pinchartl> so I propose two weeks from now, same time +<neg> works for me +<uli___> ok for me +<jmondi> booked +<kbingham> Ack. +<pinchartl> thank you +<pinchartl> that's it for today +*** horms (~horms@217.111.208.18) has quit: Quit: Leaving +<pinchartl> unless anyone has anything else to discuss, I propose adjourning + the meeting [17:35] +<pinchartl> does anyone second ? +<kbingham> Straight to thirded. +*** horms (~horms@217.111.208.18) has joined channel #periperi +<pinchartl> thank you all for attending, and have a nice day ! +<dammsan> thanks, you too +<neg> thanks all, have a good day/evening +<jmondi> see you, thanks! +<uli___> bye +<morimoto> Thanks +ERC> diff --git a/wiki/Chat_log/20170516-io-chatlog b/wiki/Chat_log/20170516-io-chatlog new file mode 100644 index 0000000..33a27c6 --- /dev/null +++ b/wiki/Chat_log/20170516-io-chatlog @@ -0,0 +1,100 @@ +--- Log opened Tue May 16 09:58:51 2017 +09:58 -!- wsa_ [~wsa@p54B33129.dip0.t-ipconnect.de] has joined #periperi-io +09:58 -!- Irssi: #periperi-io: Total of 5 nicks [0 ops, 0 halfops, 0 voices, 5 normal] +09:58 -!- Irssi: Join to #periperi-io was synced in 5 secs +09:58 < wsa_> hey guys +09:59 < horms> hi wsa_ +09:59 < geertu> Hi all +09:59 < neg> hi +09:59 < jmondi> hello everyone +10:00 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi-io +10:00 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi-io +10:03 < wsa_> so, let's start +10:03 < wsa_> first question: is there any topic from your side? +10:04 < horms> not from me, thanks +10:04 < geertu> Not from me, neither +10:05 < jmondi> not here +10:05 < morimoto> Not here, neither +10:06 < shimoda> me, neither +10:06 < wsa_> ok then +10:07 < wsa_> i guess the big topic for today are next additional tasks +10:07 < wsa_> if you have a proposal right now, please let me know +10:08 < wsa_> otherwise, I'd like to ask horms if he is open for upstreaming the SDHI DMA driver? +10:08 < horms> not neceessarily a proposal, but where are we with enabling SDR104 on Gen3? +10:08 < wsa_> (BTW I'll try to review your DMA series today) +10:08 < horms> oh, I'm happy to do that if it makes sense. But I'd like to hear from R社 that it does make sense +10:08 < horms> (Thanks!) +10:09 < wsa_> not too much TDSEL progress, sadly +10:09 < horms> ok, then lets leave that haning out in the breeze +10:09 < wsa_> the I2C Cam document was too tricky +10:09 < wsa_> R社 ? +10:10 < horms> Renesas Ltd +10:10 < horms> Renesas Co. +10:10 < shimoda> i'm not sure there is suitable for additional tasks but i want to go forward about periupport as well :) +10:10 < horms> Something liek that +10:11 < wsa_> IIRC Renesas wanted to have SDHI DMA support for Gen3 upstream in Q2 +10:12 < wsa_> (originally Q1 even, but we needed the refactoring for that) +10:12 < horms> ok, that sounds good. I assume this will run by Magnus as part of the process to get the paperwork for the task +10:12 < wsa_> shimoda: morimoto: or am I wrong here? +10:13 < horms> iirc we can use H3/M3-W ES1.0 to test the internal DMAC, right? +10:13 < wsa_> horms: sure thing +10:14 < shimoda> wsa_: you're correct. I want to have DMA support for Gen3 in Q2 +10:14 < wsa_> horms: there you have it :) +10:14 < horms> thanks Shimoda-san. wsa_ sign me up :) +10:14 < wsa_> shimoda: thanks :) +10:14 < wsa_> cool! +10:15 < wsa_> jmondi: how is your busy state? +10:16 < wsa_> neg: you were focussing on m/m for batch2, or? +10:16 < wsa_> geertu: you are still busy doing SPI slave, right? +10:16 < geertu> wsa_: Yes, have make some small changes to please 0day +10:16 < jmondi> wsa_: I don't have that much for IO currently +10:17 < geertu> s/make/to make/ +10:17 < neg> wsa_: It looks like it, but not sure +10:17 < wsa_> jmondi: Ok, just checking +10:17 < geertu> Rob acked the bindings, and Mark was already happy, cfr. our f2f at FOSDEM +10:17 < wsa_> geertu: Good work, there +10:17 < wsa_> s/,// +10:19 < horms> wsa_: I will need to discuss with you how we should handle initialisation of the internal DMAC in the light of the reworked DMA support for SDHI that you are about to review +10:20 < wsa_> ok +10:20 < wsa_> i guess i understand more what you mean once I reviewed your patches +10:20 < horms> yes, lets discuss once that has happened +10:21 < wsa_> so, SDHI Gen3 DMA is the only urgent topic we have and we got this covered +10:21 < wsa_> I keep my slot free for potential I2C cam access hacking +10:21 < wsa_> actual hacking, not only writing documents ;) +10:22 -!- pinchartl [~pinchartl@185.26.127.97] has joined #periperi-io +10:22 < wsa_> If not, there is plenty of I2C or SDHI tasks I could choose from +10:24 < wsa_> shimoda: morimoto: do you have any idea how much this SD testing hardware 'SGDK320A' might cost? +10:24 < wsa_> https://www.solidgear.co.jp/product/product_02.html +10:25 < wsa_> for the English speaking: +10:25 < wsa_> https://www.solidgear.co.jp/eng/product/index.html#pd09 +10:25 < shimoda> i don't know how much it because i use it of other department asset +10:26 < shimoda> should i ask the department about the cost? +10:26 < wsa_> yes, that would be very kind +10:27 < shimoda> ok, i will ask :) +10:27 < wsa_> i'd think this device might be very helpful in regression testing +10:27 < wsa_> and I am a bit shy to ask you every time I have SDHI patches to go to the other department :) +10:28 < geertu> https://www.zauba.com/export-emmc-hs-code.html has the price in INR -> 16930 EUR +10:29 < geertu> How many hours of Shimoda-san's time can you steal for that amount of money? ;-) +10:30 < wsa_> wow +10:30 < wsa_> godd question +10:30 < wsa_> good +10:31 < wsa_> let's notify ulrich, he can do it cheaper :D +10:31 < neg> :-) +10:31 < geertu> +1 +10:33 < horms> I guess it comes out to about 1/2 hour :^) +10:34 < wsa_> ok +10:34 < wsa_> i think this was it? +10:34 < wsa_> short'n'sweet +10:36 < wsa_> so, thanks guys +10:36 < horms> thanks wsa_ +10:36 < wsa_> have a great rest of the week +10:36 < shimoda> thank you! +10:36 < pinchartl> you're welcome. it was a hard job but I'm glad I could help :-) +10:36 < geertu> Thanks +10:37 < jmondi> thank you.. sorry for being just lurking +10:37 < neg> thanks all +10:37 < wsa_> pinchartl: you saved us! +10:38 < wsa_> jmondi: no prob. i mean, you have nothing assigned to io currently +10:43 -!- shimoda [~shimoda@relprex1.renesas.com] has quit Quit: WeeChat 0.4.2 +11:00 -!- morimoto [~user@relprex2.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +11:01 -!- pinchartl [~pinchartl@185.26.127.97] has left #periperi-io [] diff --git a/wiki/Chat_log/20170523-core-chatlog b/wiki/Chat_log/20170523-core-chatlog new file mode 100644 index 0000000..05b56b0 --- /dev/null +++ b/wiki/Chat_log/20170523-core-chatlog @@ -0,0 +1,300 @@ +Core-chat-meeting-2017-05-23 + +10:05 < geertu> Welcome to today's Core Group Chat +10:05 < geertu> Agenda: +10:05 < geertu> 1. Status updates +10:05 < geertu> Topic 1. Status updates +10:05 < geertu> A) What have I done since last time +10:05 < geertu> B) What I plan to do till next time +10:05 < geertu> C) Problems I have currently +10:05 < geertu> D) Posted/Accepted bugfix patches +10:06 < geertu> sort -R says Magnus is first +10:06 < horms> geertu: it turns out I am here now +10:07 < geertu> horms: Great! +10:07 < neg> Hi all +10:08 < dammsan> hi +10:08 < neg> Sorry for beeing late, contractors who are to change my frontdoor (which where schdeuled for this afternoon just turned up...) +10:08 < dammsan> A) i sent IPMMU multiarch series and some minor cosmetic fix +10:09 < dammsan> B) send out r8a7795 series for IPMMU +10:09 < dammsan> C) Nothing in particular +10:09 < dammsan> D) Nada +10:10 < geertu> Thank you, Magnus +10:10 < geertu> Next is Laurent (lurking?) +10:11 < geertu> Next is Marek +10:11 < marex-cloud> ACD=NULL B=try to get as many remaining peripheral patches into uboot mainline (gpio,sdmmc,ravb eth), start phase2 which is conversion of r8a779x to DT in uboot +10:12 < pinchartl> geertu: sorry, lurking, yes +10:12 < pinchartl> although I debugged IOMMU issues last week, which can be considered as core group work +10:12 < pinchartl> Sricharan has posted patches that should hopefully reach v4.12-rc soon +10:12 < pinchartl> nothing else to report +10:13 < marex-cloud> first part I hope to land in 2017.07 , second part later (I'll also have to coordinate with Iwamatsu-san, the rmobile maintainer in uboot on that) +10:13 < marex-cloud> EOF +10:13 < geertu> Thanks Laurent +10:13 < geertu> Thanks Marek +10:13 < geertu> Next is Shimoda-san +10:13 < shimoda> a) +10:13 < shimoda> - I submitted a bugfix patch of usb-dmac and applied it. +10:13 < shimoda> b) +10:13 < shimoda> - nothing for core +10:13 < shimoda> c) +10:13 < shimoda> - nothing for core +10:14 < shimoda> d) +10:14 < shimoda> - [PATCH] dmaengine: usb-dmac: Fix DMAOR AE bit definition +10:14 < shimoda> EOT +10:14 < geertu> Thank you, Shimoda-san +10:14 < geertu> Next is Niklas +10:15 < neg> A) +10:15 < neg> - Talked to Vinod about '[PATCH v2 0/3] dmaengine: rcar-dmac: fix resource freeing synchronization' and he agreed to pickig it up now. +10:15 < neg> - Formed a plan on how to improve the freeing of channels for rcar-dmac and how we can verify the Renesas test-case which is the root of this work. +10:15 < neg> B) +10:15 < neg> - No core task ATM if I get bored on the plane to Tokyo I might start to look at how to add a WARN to dmaengine if one is trying to free a none idle channel. +10:15 < neg> C) +10:15 < neg> - None +10:15 < neg> D) +10:15 < neg> - None +10:15 < neg> EOT +10:16 < geertu> Thank you, Niklas +10:16 < geertu> Next is Jacopo +10:16 < jmondi> a) not really a core task but had mainline run on GRPeach: +10:17 < jmondi> http://elinux.org/RZ-A/Boards/GR-PEACH-mainline +10:18 < jmondi> b) let's see how the RZ/A pin controller discussion evolve now that guys from NXP have been submitting similar proposal for our generic properties +10:18 < jmondi> c) nothing for core +10:18 < jmondi> d) iio: adc: max9611: Fix attribute measure unit +10:18 < jmondi> but that's IO, not core :) +10:18 < jmondi> -- eot -- +10:19 < geertu> If we use the max9611 for DVFS, it's core ;-) +10:19 < geertu> Thank you, Jacopo +10:19 < geertu> Next is Geert +10:19 < geertu> A) +10:19 < geertu> - Implemented R-Car H3 ES2.0 CPG/MSSR errata +10:19 < geertu> - Published v2 drivers/{clk,soc}/renesas/Kconfig rework +10:19 < geertu> - Published v2 of R-Car Gen2 CPG/MSSR, incl. DTS updates +10:19 < geertu> - Published v2, v3, and v4 of H3 ES2.0 DTS +10:20 < geertu> B) +10:20 < geertu> - Look into suspend/resume for CPG/MSSR and PFC +10:20 < geertu> - Mark periupport priority < H commits that are in linux-next +10:20 < geertu> C) +10:20 < geertu> - None +10:20 < geertu> D) +10:20 < geertu> - [PATCH v2 0/4] sh: sh7722/sh7757i/sh7264/sh7269: Fix pinctrl registration +10:20 < geertu> - [PATCH v2 1/4] sh: sh7722: Remove nonexistent GPIO_PTQ7 to fix pinctrl registration +10:20 < geertu> - [PATCH v2 2/4] sh: sh7757: Remove nonexistent GPIO_PT[JLNQ]7_RESV to fix pinctrl registration +10:20 < geertu> - [PATCH v2 3/4] sh: sh7264: Remove nonexistent GPIO_PH[0-7] to fix pinctrl registration +10:20 < geertu> - [PATCH v2 4/4] sh: sh7269: Remove nonexistent GPIO_PH[0-7] to fix pinctrl registration +10:20 < geertu> - [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral +10:20 < geertu> -- eot -- +10:20 < dammsan> quick question, seems that GR-PEACH support is missing from mainline? +10:20 < geertu> Next is Morimoto-san +10:20 < dammsan> thanks for your efforts Geert!! +10:21 < morimoto> A) What have I done since last time +10:21 < morimoto> D) Posted/Accepted bugfix patch +10:21 < morimoto> I posted rcar-dmac descriptor mode residue calculation bugfix patch today. +10:21 < morimoto> Without this patch, Audio DMAC (= descriptor mode user) can't get correct residue. I'm happy if you can review it +10:21 < morimoto> B) What I plan to do till next time +10:21 < morimoto> C) Problems I have currently +10:21 < morimoto> No task, sir +10:21 < morimoto> --EOT-- +10:21 < geertu> Thank you, Morimoto-san +10:21 < geertu> Next is Simon +10:21 < jmondi> dammsan: let's discuss that later maybe +10:23 < horms> Todo Update +10:23 < horms> NULL +10:23 < horms> A) What have I done since last time +10:23 < horms> B) What I plan to do till next time +10:23 < horms> No Core task at this time +10:23 < horms> C) Problems I have currently +10:23 < horms> D) Posted/Accepted bugfix patch +10:23 < horms> None +10:23 < horms> It seems that I will be able to attend from 10am after all, see you then. +10:24 < geertu> Thank you, Simon +10:25 < horms> I have a question for morimoto-san: what is Premium Friday? +10:25 < geertu> So far for the status updates +10:25 < geertu> dammsan: jmondi: You want to talk about GR-PEACH? +10:26 < wsa_> i have one small question, too +10:26 < jmondi> "golden week" "premium Friday"... I love Japanes holiday names :) +10:27 < jmondi> geertu: sure, it's quite quick from my point of view: does anyone care about that small board? It can boot from SRAM only a very minimal kernel, otherwise it requires XIP +10:27 < jmondi> and we're not allowed to enable XIP without a small patch that has been rejected multiple times (according to Chris) +10:27 < morimoto> horms: in these days, japanese government created such day which is located on last Friday on this month +10:27 < horms> jmondi: there is also Lucky Monday - a holiday moved to Monday to give a long weekend +10:28 < horms> morimoto: thanks, enjoy your Friday :) +10:28 < morimoto> This month, it is 26th. They recommend to early quiting from office :) +10:29 < horms> oh ok, its not a whole day off, just encoragement to go home early? +10:29 < jmondi> horms: it would have been Lucky Friday otherwise... +10:30 < dammsan> jmondi: i dont think the question is if anyone cares. the question is why we wouldn't upstream it? =) +10:30 < morimoto> horms: Yes. But on this month, Renesas union's recommend is take a day off :P +10:30 < horms> I like your union +10:30 < dammsan> that makes one of us +10:31 < jmondi> dammsan: yes, I've said "does anyone care" because of the XIP thing +10:32 < geertu> What's missing is a DTS for GR-PEACH, right? +10:32 < jmondi> if we upstream that, without XIP support available, only a very minimal kernel image can be booted... +10:32 < jmondi> geertu: yes, that, and RZ pin controller ;) +10:32 < geertu> Well, it's a first step +10:32 < morimoto> horms: it is "Happy Monday", not "Lucky Monday" :) +10:32 < jmondi> geertu: http://jmondi.org/git/linux/commit/f38567427d2db4a8d14001f8aba860a307b41186 +10:32 < geertu> jmondi: That's true for genmai and RSK, too +10:32 < horms> morimoto: sorry, my bad +10:33 < jmondi> geertu: true indeed +10:34 < geertu> jmondi: Does the GR-PEACH work without the pinctrl driver? +10:34 < jmondi> geertu: I have not tried tbh... +10:35 < jmondi> I don't see why not, if pins are configured properly in u-boot... And they should be +10:37 < geertu> OK, so you can submit the GR-PEACH DTS without the pinctrl props now +10:37 < jmondi> I'll test and send +10:40 < dammsan> thanks guys +10:40 < geertu> The XIP and config issues can be solved later +10:40 < horms> nice. fwiw its common (perhaps usual) to add a board without pinctrl support +10:41 < geertu> horms: I guess we can provide a minimal defconfig for GR-PEACH? +10:41 < horms> hmmm.... +10:41 < geertu> For arm64, that issue is still unresolved +10:41 < horms> I think Arnd would have a cow +10:41 < geertu> cow? +10:42 < horms> I mean, I think Arnd would reject it +10:42 < horms> I think I'd want to at least talk to him about it first +10:42 < horms> For many years he asked us often to reduce to one defconfig, which we eventually did +10:42 < geertu> Would it be easier to convince him once we have XIP support? That can never work with multi_v7_defconfig +10:43 < jmondi> horms: geertu: I've got some XIP and non-XIP configs for peach I can share +10:43 < horms> geertu: yes, i think the conversation need to happen in the context of XIP +10:43 < geertu> IIRC, Arnd was on the "good" side of the discussion about XIP support +10:45 < horms> I think in Arnds opinion in-tree defconfigs are mainly there for the convenience of him and build bots, and that real users use out-of tree defconfigs. I do not share this opinion. +10:45 < horms> But it does imply that more defconfigs = bad +10:45 < dammsan> Does that mean more boards = bad? =) +10:46 < horms> To me that is a natural extension of the argument, but I'd be surprised if Arnd sees it that way +10:46 < geertu> For XIP and memory-constrained boards, there's no other solution than a separate defconfig +10:46 < dammsan> hehe +10:46 < geertu> or defconfig snippet +10:46 < horms> To be clear, I am not against this. I'm just making recomendations based on my experiences (with Arnd) +10:47 < horms> I think discussing a snippet would be worthwhile +10:49 < geertu> For arm64, no other defconfigs are allowed +10:50 < morimoto> Does previous topic was finished ? if so I have 1 topic +10:50 < horms> see comment above :) +10:50 < geertu> So I think we need an rcar3_defconfig in Simon's repo +10:50 < geertu> In a separate branch (which people can merge), also merged into the devel branch +10:50 < geertu> s/rcar3_defconfig/renesas_defconfig/ +10:51 < horms> we can try that if you think its worthwhile. but i think its unfortunate that upstream policy leads to out-of-tree patches +10:51 < geertu> That's an interesting point of view +10:52 < pinchartl> geertu: merging such branches is always a bit painful +10:52 < pinchartl> for instance when bisecting +10:52 < geertu> True +10:53 < pinchartl> by the way, is there a way to tell git bisect to cherry-pick a set of patches at each bisection point ? +10:53 < geertu> However, when bisecting, you want to keep more or less the config you're bisecting +10:53 < pinchartl> that could be DT patches when bisecting driver changes for instance +10:53 < horms> pinchartl: i usually write a script; it would nice if there was such an option +10:54 < geertu> git bisect run? +10:54 < geertu> I usualy stash the local changes I need, and stash apply them after each step +10:54 < geertu> sometimes there are conflicts +10:55 < pinchartl> I guess the run script could spawn a console, yes +10:55 < horms> anyway, these kind of problems are some of the reasons i object to out of tree code +10:55 < pinchartl> s/console/shell/ +10:55 < horms> but I also agree it should be managable for a defconfig +10:56 < pinchartl> I believe there's value in keeping a defconfig (or a set of defconfigs) *somewhere* +10:56 < horms> that i can agree with +10:56 < pinchartl> I've stopped counting the number of times Jinso reported failure to test deliverables due to their kernel config being bad +10:56 < horms> and i am not objecting to storing them in my tree if there is a value to doing so +10:56 < geertu> Well, bisecting an issue is sometimes similar to out-of-tree patches, as the bug may only show up when merging the driver and DT branches +10:57 < geertu> As defconfigs evolve over time, storing them in a VCS is the most sensible thing to do +10:57 < horms> i'm more objecting to upstream belligerence +10:57 < pinchartl> geertu: would it make sense to store the defconfigs in a repository to which we all have commit rights ? +10:58 < geertu> pinchartl: Really? +10:58 < pinchartl> just asking ;-) +10:58 < geertu> Should renesas-drivers pull requests include defconfig updates, too? +10:59 < pinchartl> you'll have fun with the conflicts :-) +10:59 < geertu> Exactly +11:00 < geertu> Maintaining defconfigs that are to be updated regularly is a real task +11:01 < geertu> Perhaps we should continue offline (on periperi-ml), as this affects I/O and MM, too? And Morimoto-san has another small topic to discuss +11:01 < pinchartl> sure +11:02 < morimoto> geertu: can I start my topic ? +11:03 < wsa_> i have a small question, too. +11:03 < wsa_> (after morimoto-san) +11:04 < geertu> morimoto: sure, please go ahead +11:04 < morimoto> Thanks +11:04 < morimoto> it is about Salvator-XS board shipping. +11:04 < morimoto> I will ship XS board to Geert/Marek/Laurent/Niklas as 1st shipping, other guys will receive it as 2nd shipping. +11:04 < morimoto> I can ship it this week in best case. +11:04 < morimoto> pinchartl: I think I need to keep it until 6/M for you ? Because you stay in Japan until 17th ? I can bring it meeting room if you want. +11:04 < morimoto> marex-cloud: neg: you will come to Japan, but I will ship it to OpensourceAB, So I can ship it soon ? +11:04 < morimoto> dammsan: I think OpensourceAB can keep it until after OSS Japan ? +11:04 < morimoto> geertu: you will not come to Japan, so you can receive it without receive trouble? +11:05 < geertu> morimoto: yes I can. Thanks! +11:05 < dammsan> morimoto: correct +11:05 < morimoto> geertu: dammsan: OK, thanks. and pinchartl ? +11:06 < morimoto> marex-cloud: neg: please discuss how to receive it with dammsan +11:06 < neg> morimoto: will do thanks +11:08 < pinchartl> morimoto: please. if you ship it now it will arrive when I'm away, and that will be difficult to handle +11:08 < morimoto> pinchartl: OK. will ship it around 6/ +11:08 < morimoto> +11:08 < morimoto> 6/M +11:08 < pinchartl> you could ship it on the 13th or 14th, then it should arrive when I'll be back +11:09 < morimoto> OK. geertu: thats it from me. thanks +11:10 < geertu> Thank you, Morimoto-san +11:10 < geertu> wsa_: You have a question? +11:11 < wsa_> yup, about a possible renesas-cpg-mssr and i2c-sh_mobile dependency? +11:11 < wsa_> bsp has a commit saying: +11:11 < wsa_> Since renesas-cpg-mssr clk driver has changed its initial function to subsys_initcall, so change the initial function of this module to lower level. +11:11 < wsa_> I may be totally missing something, but I don't see the connection +11:12 < wsa_> and I don't want i2c drivers to be subsys_initcall unless it is utterly necessary +11:15 < wsa_> any idea? +11:16 < wsa_> If it needs digging, we can do that by mail; but I thought it might be obvious for you guys :) +11:17 < shimoda> wsa_: i think we should ask bsp team about this patch "i2c: sh_mobile: Change driver init level(Dien Pham) " +11:17 < wsa_> yes, we can do that as well +11:17 < geertu> They want to avoid probe deferral, which would put it at the end of the list again +11:18 < wsa_> but then maybe, I should collect all the questions I have :) +11:18 < shimoda> I guess this patch is related to power management because Dien-san is a member of power management team. anyway I will ask bsp team later +11:18 < geertu> While they want the i2c bus serving the PMIC initialized early +11:18 < shimoda> ask both bsp team and power management team +11:19 < wsa_> i see +11:19 < wsa_> so this saves a cycle of deferred probing +11:20 < wsa_> and the patch description is a little misleading +11:21 < wsa_> ok, thanks! +11:21 < wsa_> jmondi: do you have a minute after the meeting? +11:21 < jmondi> wsa_: yup +11:22 < geertu> wsa_: I find this patch description less misleading than some others ;-) +11:22 < wsa_> true, "a little" meant to express that :) +11:24 < shimoda> wsa_: geertu: if the description is correct, this patch is reasonable? +11:24 < shimoda> I mean, the patch should revise the description +11:24 < shimoda> and after revised it, should the patch go to upstream? +11:25 < wsa_> I wouldn't like to upstream it if it is not really needed to get the machine alive +11:25 < geertu> A good patch description talks about current state, wy that's a problem, and how to fix it. +11:25 < geertu> wsa_: Note that it's already subsys_initcall() in upstream +11:25 < geertu> subsys_initcall_sync() is _later_ +11:26 < wsa_> It is more a hackish workaround about missing device dependencies +11:26 < wsa_> I see! +11:26 < shimoda> thanks, so I should ask bsp team why they don't want to deffer the driver +11:26 < wsa_> shimoda: wait, geertu has a point there +11:27 < wsa_> but it is still trying to describe a dependency via init levels :/ +11:27 < wsa_> I'll have a closer look +11:28 < geertu> shimoda: If the driver is deferred, it's moved to the end of the list, hence retried after all other drivers have been initialized +11:28 < geertu> Probing really should start taking into account phandles +11:29 < geertu> But that would break circular dependencies... +11:29 < geertu> (doh, not as in "break the circle", but as in "break operation if there are circles" +11:29 < geertu> ) +11:31 < wsa_> It is a tough problem, but it needs to be tackled properly somewhen +11:31 < wsa_> As a maintainer, I am very conservative when people try work around this via init levels +11:32 < wsa_> As I said, only if it is utterly needed +11:32 < wsa_> Sadly, there is already cruft in my subsystem, and it causes hazzles once in a while +11:32 < wsa_> one platform needs it like this the other like that +11:32 < wsa_> but i'll check this patch again +11:34 < shimoda> wsa_: ok, so i'm waiting for wolfram-san. no ask some teams. is it ok? +11:34 < wsa_> yes +11:35 < shimoda> wsa_: i got it +11:35 < wsa_> thank you shimoda-san +11:35 < shimoda> wsa_: you're welcome :) +11:37 < geertu> Anything else to discuss? +11:37 < geertu> Else we can finish +11:38 * Marex is back from outside +11:39 < Marex> dammsan: will handle the email from you tomorrow-ish , OK ? +11:42 < Marex> morimoto: jupp, I'll come to Japan (looking forward to it!!), will discuss with dammsan +11:42 < Marex> morimoto: I'll be back on June 15th (doing a trip of Hokkaido this time), so there's no need to hurry +11:43 < morimoto> Marex: OK, but XS shipping for Marex/neg will be happen in the same time +11:44 < Marex> morimoto: got it :) +11:44 < morimoto> Because it goes to OpensourceAB first +11:44 < morimoto> And OpensourceAB will forward it to you guys +11:44 < morimoto> OpensourceAB can keep it for you. +11:44 < morimoto> You can talk it to dammsan in Japan +11:45 < Marex> morimoto: jupp :) +11:45 < Marex> morimoto: pardon my ignorance, XS is r8a7795 or 7796 ? +11:45 < geertu> r8a7795 ES2.0 +11:45 < Marex> ooooh, super ! +11:47 * neg needs to goaway for ~2 min +11:50 * neg is back +11:50 < geertu> Let's finish +11:50 < horms> thanks everyone +11:50 < shimoda> thanks! +11:50 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20170524-mm-chatlog b/wiki/Chat_log/20170524-mm-chatlog new file mode 100644 index 0000000..a496e89 --- /dev/null +++ b/wiki/Chat_log/20170524-mm-chatlog @@ -0,0 +1,694 @@ +Multimedia-chat-meeting-2017-05-24 + +<pinchartl> hello [15:55] +<uli___> hi +<kbingham> Morning! [15:56] +<pinchartl> I see that everybody has provided status reports by e-mail, + excellent :-) [15:57] +<pinchartl> I know that Jacopo is awake [15:58] +<pinchartl> how about neg ? +<morimoto> Hi [15:59] +<jmondi> Hello there +<pinchartl> let's still wait a few minutes for Niklas [16:00] +<dammsan> hi guys [16:01] +<pinchartl> hopefully Niklas will join us soon [16:02] +<pinchartl> let's get started +<pinchartl> topics for today +<pinchartl> 1. Status check for the multimedia tasks +<pinchartl> 2. Additional tasks for Q2/2 +<pinchartl> 3. Meeting in Japan +<pinchartl> anything else ? [16:03] +<pinchartl> I'll take that as a no [16:04] +<pinchartl> Topic 1. Status check for the multimedia tasks [16:05] +<pinchartl> let's see who posted his report last... +* uli___ hides +<pinchartl> Ulrich, you can start :-) +<uli___> so i copied the blanche board's serial-multiplex max9260 setup using + wires and breakout boards [16:06] +<uli___> and wrote a stub serdev driver to access it +<uli___> that works on the blanche board as well +<uli___> but that needed a little infrastructure (pin control) +<uli___> then i resent the gose video input series with updated dt bindings + [16:07] +<uli___> there are numerous variations of the adv7180 +<uli___> but we only care about whether they have 3 or 6 inputs +<pinchartl> yes, it's painful :-/ +<uli___> to i added two compat strings ("adv7180cp" and "adv7180st", iirc) +<uli___> to avoid bloat +<uli___> rob herring acked it [16:08] +<uli___> next thing to do is to probe around the chromebook board to look for + a uart or something else we can use to get debug output +<geertu> uli___: To which variant does the existing "adi,adv7180" correspond + to? +<uli___> "unknown", i suppose +<pinchartl> I'll review the DT bindings [16:09] +<pinchartl> (and the other patches) +<uli___> thank you [16:10] +<pinchartl> next in report order, neg +<pinchartl> who doesn't seem to be here +<pinchartl> I'll copy his e-mail report for now +<pinchartl> since last meeting +<pinchartl> - [PATCH v2 0/2] v4l2-async: add subnotifier registration for + subdevices +<pinchartl> - [PATCH v2 0/2] media: entity: add operation to help map DT + node to media pad +<pinchartl> - [PATCH v7 0/2] media: rcar-csi2: add Renesas R-Car MIPI + CSI-2 support +<pinchartl> - [PATCH v2 00/17] rcar-vin: fix issues with format and + capturing +<pinchartl> for the next two weeks: [16:11] +<pinchartl> * Post: +<pinchartl> - [PATCH v5 00/28] rcar-vin: Add Gen3 with media controller + support +<pinchartl> * Attend OSS Japan and PeriPeri +<pinchartl> next [16:12] +<pinchartl> jmondi: [16:13] +<pinchartl> your turn +<jmondi> here I am +<jmondi> let me paste the email content a bit +<jmondi> since last meeting +<jmondi> - Migo-R machine init with new CEU driver: got both sensor probing + [16:14] +<jmondi> - Sensor drivers (ov772x and tw9910) removed soc_camera dependencies +<jmondi> - add support for multiple sub-devices to CEU driver +<jmondi> - started playing with notifiers on max9268 driver and 8-ch camera + setup [16:15] +<jmondi> for the next two weeks +<jmondi> - max9682 startup sequence +<jmondi> - split max9268 and max9271 drivers +<jmondi> - add support for OF to CEU driver and use camera module on GR-Peach + board [16:16] +<pinchartl> I'll add "- OSS Japan and multimedia meeting" to that list +<jmondi> ah, right! +<jmondi> I forgot I had to take a plane on Friday +<jmondi> :) +<jmondi> do we need to add accepted bug fixes to status report? [16:17] +<pinchartl> no +<jmondi> ok, then --eot-- +<pinchartl> Morimoto-san's script to pick them up works :-) +<jmondi> I knew it was like that for Core/IO, just wanted to make sure for mm + is the same... [16:18] +<neg> sorry for beeing late +<morimoto> jmondi: my script is collecting bugfix patch from our related ML +<pinchartl> hi Niklas +<jmondi> morimoto: great! [16:19] +<morimoto> jmondi: Thanks anyway +<pinchartl> next in report order, kbingham +<kbingham> I've been mostly working on ADV748x related tasks, and trying to + get it's dependencies sorted. [16:20] +<kbingham> With that - I have done 4 spins of the V4L2 async matching updates, + which I think are now ready and are going through Sakari's branches + I believe. +<kbingham> I need to discuss with Niklas what we will do about the link issues + that are not created in RVin +<kbingham> but I think for now - just using static immutable links in the ADV + is fine. [16:21] +<kbingham> I have also done two spins of the ADV748x driver itself with plenty + of review comments from both Laurent and Sakari which I have been + working through. +<kbingham> The last 'big tasks' for me before another repost is to try to get + regmap in place. +<kbingham> I have also done some review and maintenance work for the VSP1-DU + patches, and I have also got my remote access set up so I can boot + the Salvator-X without a wire in my laptop - This makes me happy :) +<kbingham> - Next up for me is of course the Japan trip, I leave for London + on Thursday evening, and fly out Friday morning. And hopefully one + or two final posts of the ADV748x [16:22] +<kbingham> -- eot -- +<morimoto> ? kbingham: do you come to japan ? [16:23] +<kbingham> morimoto: I am yes :) +<kbingham> morimoto: I need you to teach me how to speak Japanese in the next + 3 days :) +<morimoto> OK, so, total 5 periperi from Europe ? +<morimoto> Laurent/Niklas/Marek/Jacopo/Kieran [16:24] +<pinchartl> morimoto: correct +<morimoto> OK, thanks +<dammsan> will marek join the m/m meeting? +<pinchartl> dammsan: no, he will land on Tuesday evening I believe [16:25] +<dammsan> ok, so monday lunch how many people? =) +<dammsan> 6 from our side? +<jmondi> o/ +<morimoto> o/ +<pinchartl> dammsan: 4 European people, you and Morimoto-san, and whoever else + Renesas sends to spy on our meeting :-) [16:26] +<dammsan> gotcha, thanks +<pinchartl> next to go in report order, Morimoto-san +<morimoto> gotcha +<morimoto> A) What have I done since last time +<morimoto> - OF-graph for ALSA SoC was accepted ! I posted HDMI sound + patch-set to ML +<morimoto> - 24bit sound issue which was found by BSP team was solved. It was + data format issue on HW. I posted this patch to ML, and accepted. +<morimoto> - AGL sound issue which was found by BSP team was solved. It was + PulseAudio, and Audio-DMAC bugfix was needed. I posted patches. + [16:27] +<morimoto> - We could receive from Laurent about "DU and GPU synchronization + through fences". pinchartl: nThank you about that ! +<morimoto> About peripelist diff, please check my mail +<morimoto> B) What I plan to do till next time +<morimoto> - continue to HDMI sound +<morimoto> - BSP team nurse for ADSP +<morimoto> C) Problems I have currently +<morimoto> No, sir +<morimoto> but, I want to know/get "8ch camera prototype" patch (or something) + somehow +<morimoto> --EOT-- [16:28] +<pinchartl> you're welcome for the DU and GPU synchronization. sorry about the + delay, I had to check that with DRM developers +<morimoto> OK, no problem. thank [16:29] +<morimoto> s/thank/thans/ +<pinchartl> regarding the 8-channels camera prototype +<pinchartl> http://elinux.org/R-Car/Tests:rcar-vin#Multi-channel_CSI-2_tests +<pinchartl> there's a link to the code +<pinchartl> git://linuxtv.org/pinchartl/media.git vin-gmsl-20170515 +<morimoto> gr8 +<morimoto> thanks +<morimoto> About DMA bugfix patch, I think it is pinchartl: territory [16:31] +<pinchartl> isn't it a core team problem ? ;-) +<pinchartl> I will have a look +<morimoto> I can show you my cute smile if someone can review :) [16:32] +<pinchartl> :-) +<pinchartl> now I realize that, once again, I forgot to put Magnus first +<pinchartl> dammsan: be careful, the third time you get under the radar, you + earn the sneaky scoundrel badge :-) +<pinchartl> and we seem to have lost Magnus [16:33] +<morimoto> :) +<pinchartl> in the meantime, I'll go with my report (privilege of going last + as the team leader :-D) [16:34] +<pinchartl> since last meeting +<pinchartl> - Looked into the DU fence issue reported by the BSP team +<pinchartl> The BSP team couldn't get fences working without additional (and + complex) patches to the DU driver. This came from the fact that + they wanted to use implicit fences, while DRM has switched to an + explicit fences model. Only explicit fences are implemented in the + DRM core. The GPU driver will need to switch to explicit fences + too. +<pinchartl> - Cache (DMA ATTR SKIP CPU) performance issue with VSP2 +<pinchartl> Fixed in "[PATCH v2 0/5] R-Car DU: Fix IOMMU operation when + connected to VSP". +<pinchartl> - Handled administrative tasks (additional tasks negotiation, + Tokyo meeting preparation) [16:35] +<pinchartl> - Started looking into H3 ES2.0 display support +<pinchartl> for the next two weeks [16:36] +<pinchartl> - H3 ES2.0 DU support +<pinchartl> - OSS Japan and multimedia meeting +<pinchartl> - Vacation in Japan (from June the 4th to June the 17th) +<pinchartl> ah, I forgot to mention, I've also managed to get my Salvator-X + booting in my board farm, with power controlled through a + beaglebone black and a custom PCB to drive the external power + signal [16:37] +<dammsan> good!! +<pinchartl> now I need to setup remote access to the management machine +<pinchartl> (which at the moment is unfortunately a power-consuming PC, but I + hope to change that at some point) [16:38] +<pinchartl> that's it for me +<pinchartl> dammsan: anything to report ? +<pinchartl> seems we've lost Magnus again [16:40] +<dammsan> not much except that i intend to review your IPMMU DU/VSP/FCP series +<pinchartl> ok +<dammsan> also +<kbingham> I'll ping Mauro to get an ack on those +<dammsan> i would like to know which boards i should bring to the meeting + space +<pinchartl> kbingham: you can ping him on IRC. tell him you're leaving for + Japan tomorrow and that you'd like to know whether he's OK before + that [16:41] +<pinchartl> dammsan: that will be part of the third topic :-) +<dammsan> excellent!! +<pinchartl> Topic 2. Additional tasks for the second batch of Q2 +<kbingham> pinchartl: Yes, the on IRC bit was the part I meant - the Japan + trip is a good idea for a push :) +<pinchartl> has everybody received their SoW for Q2/2 ? [16:42] +<uli___> not me +<dammsan> right, that's yet to be finalized [16:43] +<dammsan> uli___: lets do that today so we can wrap it up at renesas office + tomorrow +<neg> pinchartl: I have received a SoW for TB/BT for rcar-vin, thanks for + writing that upp :-) +<pinchartl> neg: you're welcome +<uli___> dammsan: ok +<dammsan> neg: we should discuss papers soon, prefer to do it before japan? +<jmondi> pinchartl: beside our chat, not yet in a 'formal' document [16:44] +<neg> dammsan: whatever is convinient for you +<pinchartl> jmondi: I don't think you need a formal document for Q2 +<pinchartl> you're still covered by a base contract only until end of Q2 as + far as I understand [16:45] +<pinchartl> additional tasks fo Q3 will be discussed in Japan. uli___, we will + of course keep you involved in the process, likely through e-mail + due to the time zone difference +<pinchartl> uli___: if you have proposals for tasks you'd like to work on in + Q3, please send me an e-mail before Monday +<jmondi> pinchartl: then I'm fine with my base contract ending the 30th June +<dammsan> neg: will you show up at the meeting space on sunday night? [16:46] +<dammsan> if so we can finalise discussions there +<dammsan> if not then later in the week is fine too [16:47] +<pinchartl> any other comment regarding additional tasks ? +<neg> dammsan: that was my intention but then I saw the travel description :-) + I will look at a map and make sure I can get ther and if so yes I will + show up +<dammsan> neg: gotcha [16:48] +<neg> dammsan: so if I get lost handeling it on Monday is also fine with me if + it works for you +<dammsan> sure no worries [16:49] +<pinchartl> this leads us to the next topic +<pinchartl> Topic 3. OSS Japan trip +<pinchartl> Tokyo is in less than a week ! are you all excited ? :-D +<dammsan> \o/ [16:50] +<kbingham> \o/ :D [16:51] +<pinchartl> \o/ +<neg> \o/ [16:52] +<pinchartl> ahem... +<pinchartl> :-) +<pinchartl> so +<pinchartl> we have a meeting space booked from the 28th (3pm) to the 31st +<kbingham> Did the meeting place address get posted ? +<pinchartl> yes, to periperi [16:53] +<pinchartl> 2 Chome-4-3 Senzoku, Taitō-ku, Tōkyō-to 111-0031, Japan +<pinchartl> kbingham: welcome to your first Japanese lesson, street addresses + :-) +<kbingham> Thanks - I'll see if google-nav can get me there :) +<dammsan> since it is taito-ku i guess it is in between a pachinko place and a + soap land [16:54] +<kbingham> My arrival 'capsule' is in Taito - so I'll be nearby +<pinchartl> (:-D +<dammsan> cool +<pinchartl> if I'm not mistaken, the address is pronounced "ni Chome shi san + Senzoku, Taitō-ku, Tōkyō-to [16:55] +<pinchartl> that can be useful in a taxi +<dammsan> so far it seems like pinchartl wants to use the place for sleeping +<morimoto> dammsan: can you tell me meeting place name again ? +<morimoto> so-so-kan ? +<kbingham> 2 km away ... - 26 minute walk. +<pinchartl> morimoto: https://www.airbnb.com/rooms/17013981 +<dammsan> yuyutei +<kbingham> dammsan: I think if I'm able to adjust my conference hotel booking + I would like to too . +<dammsan> ok cool +<pinchartl> I haven't been able to adjust my Hilton booking yet [16:56] +<pinchartl> I tried doing it online but the only option was to cancel and + rebook +<pinchartl> which is more expensive now, for two night less than the original + booking +<pinchartl> I contacted them by e-mail but they never replied [16:57] +<morimoto> dammsan: pinchartl: thanks +<neg> yes that is why I have not alterd my Hilton booking... :-) If you figure + out how to change it let me know +<pinchartl> if I can't I guess I'll have a choice between two rooms :-) +<pinchartl> which could actually be convenient, as I'll land early in the + morning [16:58] +<jmondi> I've been able to get the last rooms at LF discount price there.. not + going to cancel and lose it :) +<dammsan> we have bed space for 5 people in 3 rooms +<pinchartl> dammsan: will you stay there ? +<dammsan> yeah i might do so +<dammsan> i heard morimoto-san might as well +<dammsan> in case we're not utilizing it fully anyway +<dammsan> so lunch with jinzai on monday [16:59] +<dammsan> we are 6 ppl +<dammsan> when shall we ask to meet them at the jinzai office? [17:00] +<dammsan> noon? +<pinchartl> first thing first +<dammsan> sure =) +<pinchartl> I propose starting the meeting at 9:00am +<dammsan> (thought i lost you =) +<neg> if the house is not fully used I might want to also stay there to be + able to hangout with you guys. But if the beds are needed I'm just as + fine making my way to the Hilton :-) +<pinchartl> to have time to discuss before meeting with Jinzai +<pinchartl> for those who are interested, we could meet earlier to have + breakfast [17:01] +<pinchartl> I'm sure we can find something nearby +<jmondi> that's for Monday morning, right? [17:02] +<pinchartl> yes +<dammsan> my only concern is rush hour train from odaiba +<pinchartl> good point +<jmondi> but you'll be there from Sunday +<pinchartl> dammsan: what do you recommend ? +<dammsan> that people staying at the meeting space go out for breakfast +<dammsan> and people from hilton take a taxi +<dammsan> and join when they arrive [17:03] +<pinchartl> sounds good to me +<pinchartl> should we all have dinner together on Sunday evening ? +<dammsan> it might take between 20 and 40 minutes to get to the meeting space, + maybe even 1h worst case +<jmondi> lovely! [17:04] +<dammsan> that sounds nice +<jmondi> Sunday dinner is fine! +<pinchartl> how about having dinner somewhere around the house ? +<pinchartl> so we can meet there first, people who stay there can drop their + luggage, and we can all go to dinner +<dammsan> yeah sure, i have no idea where but we can figure out something +<pinchartl> I'm sure there will be an interesting dinner place within a + reasonable distance from the hosue [17:05] +<pinchartl> should we meet there at 18:00 ? +<dammsan> asakusa will have something most likely +<dammsan> if so i'll ask to check-in at 17:00 [17:06] +<dammsan> and wait for your guys there +<dammsan> morimoto: shall we go to the house together on sunday? +<morimoto> sure +<dammsan> i'll bring my sleeping bag in case everyone will stay at the place + [17:07] +<pinchartl> then lunch with Jinso at 12:00 on Monday seems good to me +<jmondi> neg: will you leave from Odaiba on Sunday afternoon? Should we test + our ability to get there by public transportations? +<dammsan> pinchartl: meeting at jinzai office at 12:00 and let jinzai decide + timing for lunch is ok? inayoshi-san said a brief meeting only + [17:08] +<pinchartl> dammsan: yes, sure +<dammsan> excellent, will let them know right away [17:09] +<neg> jmondi: seems like a good plan +<pinchartl> I assume people will be interested in dinner on Monday evening +<pinchartl> going back to the hotel before dinner for those staying at the + Hilton might not be very convenient +<pinchartl> so should we wrap up not too late, let's say 18:30, and then head + to dinner ? [17:10] +<kbingham> I presume taxis/uber are easy in Tokyo? +*** horms (~horms@217.111.208.18) has quit: Ping timeout: 255 seconds +<kbingham> but yes - 18:30 for dinner sounds reasonable [17:11] +<pinchartl> kbingham: there are taxis all over the place. the hardest part is + to communicate your destination address :-) +<morimoto> kbingham: uber is not yet allowed in Japan +<kbingham> pinchartl: Thus the benefit of Uber :) +<kbingham> morimoto: Oh - then that's out ! +<neg> kbingham: also data is super expensive (at least for my .se phone) +<pinchartl> as a general note, make sure you have cash with you, credit cards + are not accepted everywhere +<pinchartl> you probably want a local SIM card [17:12] +<jmondi> something I would like to ask: do you recommend buying a sim card? +<jmondi> ah yes +<kbingham> ^ - When travelling I always get a local card :) +<pinchartl> you can buy one at the airport +<pinchartl> i paid ¥5500 for a 1GB SIM card last year) +<pinchartl> it might be possible to get cheaper ones in town [17:13] +<pinchartl> if you can get a SIM card that also allows voice, it can be useful + to coordinate +<morimoto> (I'm very flexible, if people want to stay at meeting room, I can + go back to my house) [17:14] +<pinchartl> but unless this has changed recently, don't bother with text + messages, they don't work across different operators +<pinchartl> so here's the tentative schedule +<uli___> ftr, last time i bought a sim card in japan, it would not work with + my dual-sim nokia phone +<pinchartl> Sunday 18:00: Meeting at the house, then heading out for dinner +<pinchartl> Monday 08:15: Breakfast for those staying at the house +<pinchartl> Monday 09:00: Multimedia group face-to-face meeting (we will wait + for everybody to arrive, rush hour is a valid excuse for being + late, but please try to not arrive too late) +<pinchartl> Monday 12:00: Visit to the Jinso office and lunch with them +<pinchartl> Monday 14:00: Multimedia group face-to-face meeting +<pinchartl> Tuesday 08:15: Breakfast for those staying at the house +<pinchartl> Tuesday 09:00: Multimedia group face-to-face meeting +<pinchartl> Monday 18:30: Dinner (TBD) +<pinchartl> Tuesday 12:00: Lunch (TBD) +<pinchartl> Tuesday 14:00: Multimedia group face-to-face meeting +<pinchartl> Tuesday 18:30: Dinner (TBD) +<pinchartl> we will try to minimize the time spent on discussions [17:15] +<pinchartl> so as soon as we finish covering all topics +<pinchartl> we'll switch to hacking mode +<pinchartl> Morimoto-san and Magnus can bring us boards, but they need to know + what we need [17:16] +<pinchartl> power supply should be provided too +<pinchartl> but please all bring the cables you need +<pinchartl> this includes ethernet and USB cables [17:17] +<pinchartl> and whatever else you need for your work +<kbingham> Will we have wifi at the house? +<pinchartl> (likely HDMI for instance) +<pinchartl> kbingham: according to airbnb, yes +<pinchartl> the quality of the network is unknown +<pinchartl> worst case we'll use our phones as access points I assume [17:18] +<morimoto> I can bring my WiMAX if you want +<pinchartl> morimoto: that would be very nice, just in case the wifi doesn't + work well +<morimoto> OK, will do> +<dammsan> good idea [17:19] +<pinchartl> what hardware do you all need ? +<pinchartl> we will work on the multi-camera setup +<pinchartl> dammsan: is it feasible to bring that ? +<kbingham> A video source ... +<neg> I have two thingns I like to hack on 1. Integrate my VIN+CSI-2 with + kbingham ADV7482 2. Take the 8-ch channel prototype for a real world + spin and indentify more "problem" areas. So for that I assume a + Salvator-X board and the 8-ch daughterboard is HW I would like dammsan + and morimoto to bring :-) [17:20] +<dammsan> good question +<dammsan> i guess no one else is bringing any hardware? +<morimoto> Unfortunately, bought 8ch camera are not yet arrive. So we have + Magnus's remote 8ch only +<jmondi> would like to see 8chan setup as well, and will bring a GR-Peach with + camera board and modules in case I have some time to work on it +<dammsan> ok i see +<pinchartl> dammsan: remote access is an option, but we might need to play + with the power supply jumper for the second max9286, which isn't + convenient if we can't access the board physically [17:21] +<dammsan> i can bring the 8-ch setup +<dammsan> right +<pinchartl> dammsan: thank you +<dammsan> ok, 8-ch setup, check +<pinchartl> dammsan: I'll need the Salvator-X H3 ES2.0 board +<jmondi> dammsan: pinchartl: Migo-R? Is it still a thing? [17:22] +<dammsan> ok, will bring +<morimoto> Now, we received XS !! I can bring it to meeting room +<pinchartl> morimoto: wow cool ! +<dammsan> morimoto: that might help but we have no board support code +<morimoto> Yes, that is issue :) +<dammsan> jmondi: is physical access heping? [17:23] +<pinchartl> dammsan: I'd still like to try the Salvator-XS if time permits +<jmondi> actually while there there should be less lag than from Europe, so + not that much I guess +<pinchartl> morimoto: so if you could bring it, it would be nice +<jmondi> dammsan: ^ +<dammsan> jmondi: i can bring it but i want to avoid removal/reinstall from + remove access rack unless it is really necessary [17:24] +<pinchartl> neg: kbingham: what do you use to the VIN on Salvator-X as HDMI + and analog sources ? +<jmondi> dammsan: no worries +<kbingham> pinchartl: I have an Amazon Fire stick for the HDMI in - and a DVD + player for the CVBS in. [17:25] +<kbingham> Something to replicate those video sources would be useful. +<pinchartl> kbingham: can you bring the amazon fire ? +<morimoto> pinchartl: OK will do +<neg> pinchartl: SNES and XBOX, but I bought a HDMI to CVBS adapter I'm + planing to bring and hoping that will work as a video source from my + laptop +<dammsan> jmondi: there is a photo of the migo-r here: [17:26] +<dammsan> + https://events.linuxfoundation.org/images/stories/slides/jls09/jls09_damm.pdf +<kbingham> pinchartl: I can ... I was going to leave it hooked on my board at + home ... but I could just leave the DVD player switched on instead. + [17:27] +<pinchartl> dammsan: would it be possible for you to bring an HDMI or VGA + screen ? +<neg> or maybe the hackday must include a trip to akihabara to buy snes clone + to act as input source :-) +<pinchartl> neg: hehe :-) +<dammsan> go go go super potato +<pinchartl> kbingham: another option is to use a laptop output as an HDMI + source, but the ADV7482 has no EDID support yet as far as I know, + so I'm not sure whether that would work +<dammsan> maybe morimoto-san can bring the LED projector? +<pinchartl> neg: kbingham: any comment on that ? +<dammsan> (my projector that is in the renesas office) [17:28] +<pinchartl> dammsan: a projector is a good idea +<kbingham> pinchartl: No - there is no EDID support yet - unless we add it + while we're there :) +<pinchartl> does it have VGA, HDMI or both ? +<dammsan> that might serve well as HDMI output +<dammsan> both i think +<kbingham> pinchartl: I started to look at that - but have postponed as it + didn't seem a priority for upstreaming the driver. +<pinchartl> kbingham: that would be nice but it's not very urgent, although + it's showing to be a partial blocker (or at least a nuisance) +<dammsan> morimoto: can you check projector ports please? +<pinchartl> kbingham: now you know what you'll do in the plane ;-) +<neg> pinchartl: I agree that EDID support is a issue and a laptop HDMI wont + work (at least not last time I tried) but I have high hopes on my + HDMI-to-CVBS dongle could work :-) [17:29] +<dammsan> (if you are in the renesas office) +<pinchartl> neg: yes, CVBS shouldn't care about EDID :-) +<kbingham> pinchartl: I'll need the business class upgrade for the flying + office then :) - I'll expense that you you yes ? :D +<pinchartl> kbingham: you don't have a private jet ? :-) +<kbingham> pinchartl: It's under repair currently [17:30] +<pinchartl> :-) +<pinchartl> so I think hardware access is sorted out [17:31] +<pinchartl> to summarize +<neg> also please bring local power cabe slitters :-) +<pinchartl> kbingham: Amazon Fire TV stick (HDMI source for VIN testing) +<pinchartl> dammsan: Salvator-X H3 ES1.1 + Multi-camera expansion board + 8 + cameras, Salvator-X H3 ES2.0 [17:32] +<pinchartl> morimoto: LED projector, Salvator-XS +<pinchartl> neg: HDMI to CVBS converter (CVBS source for VIN testing) +<pinchartl> everybody: cables +<pinchartl> a power strip would be useful, yes [17:33] +<pinchartl> Magnus or Morimoro-san, could you bring one ? +<morimoto> dammsan: it seems we lost your projector [17:34] +<pinchartl> I'll bring one with euro plugs so Jacopo, Niklas and I won't need + separate power adapters +<morimoto> I can't find it here (= Renesas office) +<jmondi> pinchartl: thanks +<dammsan> morimoto: i saw komatsu-san using it some week ago +<morimoto> OK, will check +<dammsan> (maybe he was busy planning on how not to give us salvator-xs boards + early) [17:35] +<pinchartl> then, moving on with the schedule, Wednesday-Friday will be + conference time. we can plan dinners, but I'm sure lots of + unexpected plan disruptions will occur, so it might not be worth + it starting with that now [17:36] +<pinchartl> for Saturday +<pinchartl> I propose visiting Kamakura or Hakone +<morimoto> OK, projector has HDMI in, RGB in, VIDEO in, Audio in +<pinchartl> (assuming the weather will permit) +<pinchartl> morimoto: by RGB, do you mean VGA ? [17:37] +<morimoto> Yes +<pinchartl> morimoto: perfect ! +<dammsan> morimoto: thanks for checking, can you bring it? +<pinchartl> Morimoto-san and Magnus, would you be interested in joining us for + a day trip to Kamakura or Hakone on Saturday the 3rd ? +<morimoto> Do you need HDMI cable ? [17:38] +<pinchartl> (or would you recommend avoiding those places ? :-)) +<pinchartl> morimoto: I'll bring a VGA and an HDMI cable, but if there are + cables with the projector please take them, just in case +<morimoto> OK +<dammsan> pinchartl: i think i need one free day this weekend, so i'll pass + this time [17:39] +<morimoto> In 3rd, I need to go to dentist. But I can adjust. +<morimoto> Then, I need to cancel it +<dammsan> oh, 3rd +<dammsan> that sounds nice +<dammsan> lets go together +<pinchartl> :-) +<pinchartl> morimoto: if you're not available it's fine, the trip is not + mandatory :-) +<pinchartl> but we would certainly be happy if you could join [17:40] +<pinchartl> (however, please not that if the weather is really bad we might + need to change the plan) +<morimoto> OK, let's go together :) +<pinchartl> would you recommend Kamakura or Hakone ? +<morimoto> (I will cancel dentist) +<pinchartl> Kamakura is a bit closer, one hour away by regular train +<pinchartl> while Hakone is also one hour away, but by Shinkansen [17:41] +<pinchartl> so if we book at the last minute to check the weather, the + Shinkansen might be full +<dammsan> both are nice i think +<pinchartl> (but at least we have a backup plan) +<morimoto> Kamakura has big Buddha. Hakone is On-sen place +<pinchartl> ok, I'll let you all check both places, and we'll decide later +<dammsan> shonan-enoshima is also nice +<morimoto> https://www.city.kamakura.kanagawa.jp/visitkamakura/en/index.html +<dammsan> it is in the same direction +<dammsan> sort of a beach place [17:42] +<morimoto> https://www.hakone.or.jp/en/ +<pinchartl> dammsan: thanks, I've added that to the list of proposals [17:43] +<neg> on-sen and beach place, sounds like I shuld pack swiming gear :-) +<morimoto> neg: you can't use swiming gear at on-sen :) [17:44] +<jmondi> both seems very nice! not sure what on-sen stands for :) +<pinchartl> neg: good point, please all pack a swimming suit in case we go to + the beach :-) +<pinchartl> jmondi: look it up or have the surprise ;-) +<jmondi> I'll go for the surprise! [17:45] +<morimoto> http://www.hakone-english.com/ +<pinchartl> dammsan: I had failed to see that Shonan-Enoshima is actually in + Kamakura :-) +<dammsan> it is also possible to go for an evening onsen visit from the + meeting space if you'd like +<dammsan> we can take a cab to tokyo dome area [17:46] +<dammsan> but anyway +<dammsan> people with tattoos might have a hard time getting accepted +<dammsan> but apart from that anything should be fine +<pinchartl> dammsan: small tattoos can be covered with a band-aid, right ? + [17:47] +<dammsan> yeah probably +<jmondi> dammsan: really? +<dammsan> yeah +<dammsan> and "antisocial persons" are also not usually welcome [17:48] +<dammsan> that would be me i guess =) +<jmondi> I might have problems then +<jmondi> ah crap, 2 problems then +<dammsan> hehe +<jmondi> how do they find out if you're an antisocial one? +<pinchartl> jmondi: tattoos are associated with the Yakuza and antisocial + behaviour in Japan [17:49] +<dammsan> i guess they look you up on facebook +<dammsan> just kidding +<dammsan> =) +<jmondi> and if you're not on faebook, you're anti-social-network? Ok, I'll + stop [17:50] +<pinchartl> jmondi: + http://www.kashiwaya.org/e/magazine/wp-content/uploads/2014/10/tattoo_cover.jpg +<neg> if they did, I'd say it's the first valid reason I heard to get a + facebook account :-) +<dammsan> =) +<dammsan> i'd say it is probably closer to "fax-book" than face book given how + old the rules are [17:51] +<jmondi> pinchartl: no way :) +<pinchartl> jmondi: :-) +<pinchartl> anyway, I think that's it for today's meeting [17:52] +<pinchartl> does anyone have another topic to discuss ? +<morimoto> 2nd plan ? http://www.senso-ji.jp/ +<morimoto> http://www.meijijingu.or.jp/english/index.html [17:53] +<neg> One short question, is anyone besides jmondi interessted in a joint + travel from the Hilton to the House on Sunday? +<pinchartl> neg: I might, if I can't change my Hilton booking +<pinchartl> morimoto: do you mean on June the 2nd ? +<morimoto> http://daiba.ooedoonsen.jp/en/ [17:54] +<morimoto> pinchartl: no no. +<kbingham> neg: Likewise here - although [17:55] +<neg> pinchartl: Ok I send the same question to periperi and if you wish to + join please respond to that :-) +<kbingham> I think I can easily cancel my sunday night at the hilton as it was + booked separately. +<dammsan> kbingham: nice to see that you've had your thinking cap on!! =) +<pinchartl> morimoto: ah, a backup plan then :-) +<morimoto> pinchartl: yes +<neg> pinchartl: also if you managed to find a way to alter your Hilton + booking please let me know since I failed in this endevor [17:56] +<pinchartl> neg: sure +<pinchartl> I'll land on Sunday morning [17:57] +<dammsan> if you are unsure where to find more interesting place to spend your + time on than odaiba, feel free to have a look at narita city +<pinchartl> so I'll be looking for company for the day +<pinchartl> but let's discuss that separately +<kbingham> I would suggest we share phone numbers or some contact details for + when we are in Japan, but I guess we might all end up with a new + temporary number on arrival ? +<pinchartl> this brings us to the next topics +<jmondi> I guess so +<pinchartl> s/topics/topic/ +<pinchartl> Topic 4. Next meeting +<pinchartl> The next meeting will be held face to face next week in Tōkyō, see + you there ! +<pinchartl> uli___: thanks for the chromebook pictures [17:58] +<uli___> welcome +<pinchartl> I propose adjourning this meeting +<pinchartl> does anyone second ? +<kbingham> Aye [17:59] +<jmondi> yup +<neg> second +<dammsan> yeah +<pinchartl> meeting adjourned +<pinchartl> thank you all for attending +<neg> thanks all, have a nice day and see (most of) you soon [18:00] +<kbingham> :) Yes - Looking forward to it +<pinchartl> uli___: there's so many unsoldered components [18:01] +<uli___> ? +<uli___> what are you referring to? +<pinchartl> the chromebook +<uli___> of course, but what components? +<pinchartl> not one in particular [18:02] +<pinchartl> I'm also puzzled by the component outlines on the silk screen that + just encompass plain areas of copper +<uli___> ah, you mean the pads with nothing on them +<pinchartl> for the unsoldered components, yes [18:03] +*** horms (~horms@217.111.208.18) has joined channel #periperi [18:04] +<neg> I just though of one more Japan related question, if I print a address + such as '2 Chome-4-3 Senzoku, Taitō-ku, Tōkyō-to 111-0031, Japan' on a + piece of paper is it good enugh to hand to a taxi driver and expect to + arrive at the correct location? [18:06] +<pinchartl> neg: try to print it in Japanese [18:07] +<pinchartl> or read it out with your best Japanese accent :-) +<jmondi> neg good question! +*** horms (~horms@217.111.208.18) has quit: Ping timeout: 260 seconds [18:09] +<neg> ok thanks [18:11] +<morimoto> neg: Maybe OK I think [18:13] +<morimoto> but you can ask to driver before ride +<morimoto> If you can bring Map, it is best [18:14] diff --git a/wiki/Chat_log/20170606-core-chatlog b/wiki/Chat_log/20170606-core-chatlog new file mode 100644 index 0000000..8d5f65f --- /dev/null +++ b/wiki/Chat_log/20170606-core-chatlog @@ -0,0 +1,124 @@ +Core-chat-meeting-2017-06-06 + +10:02 < geertu> Welcome to today's Core Group Chat! +10:03 < geertu> Agenda: +10:03 < geertu> 1. Status updates +10:03 < geertu> 2. Discussion topics +10:03 < geertu> Topic 1. Status updates +10:03 < geertu> A) What have I done since last time +10:03 < geertu> B) What I plan to do till next time +10:03 < geertu> C) Problems I have currently +10:04 < geertu> (tampered with) sort -R said Niklas is first +10:04 < neg> A) No core task ATM +10:04 < neg> B) No plane all time will go to multimeda work next two weeks. +10:04 < neg> C) None +10:04 < neg> EOT +10:05 < neg> s/plane/plan/ +10:05 < geertu> Thank you, Niklas +10:05 < geertu> Next is Marek +10:05 < Marex> A) ULCB U-Boot support patch (tested on dammsans board remotely by booting u-boot from u-boot) B) Submit the ULCB U-Boot patch mainline C) No ULCB available, need to buy one to test flashing the U-Boot instead of booting U-Boot from U-Boot +10:06 < Marex> EOT +10:07 < geertu> I think C is something to discuss with Öpensöurce AB +10:07 < Marex> geertu: correct, already work in progress +10:07 < geertu> Thank you Marek. +10:07 < geertu> Next is Morimoto-san +10:07 < morimoto> A) = B) = C) = NULL, sir +10:08 < geertu> Thank you Morimoto-san! +10:08 < geertu> Next is Mangnus, who is excused. +10:08 < geertu> Next is Laurent, who is on holidays +10:08 < geertu> Next is Jacopo +10:08 < jmondi> A) Add GR-Peach DTS file +10:09 < jmondi> - still discussing RZ pinctrl, found a possible way forward +10:09 < jmondi> B) RZ pinctrl +10:09 < jmondi> C) None +10:09 < jmondi> -- eof -- +10:09 < geertu> s@RZ@RZ/A1@ +10:10 < jmondi> geertu: yes, RZ/A1 +10:10 < geertu> Thank you Jacopo! +10:10 < jmondi> some other RZ are not really RZ :p +10:10 < geertu> Next is Geert +10:10 < geertu> A) What have I done since last time +10:11 < geertu> - Tested H3ULCB with H3 ES2.0 +10:11 < geertu> - Looked into D3 CPG/MSSR +10:11 < geertu> - Made inventory of code under arch/arm/mach-shmobile that still needs DT +10:11 < geertu> conversion, and converted that into a list of tasks for +10:11 < geertu> peripelist/core/todo +10:11 < geertu> - Started looking into suspend/resume for CPG/MSSR and PFC +10:11 < geertu> - Issue is complicated because hardware state is not just lost, but +10:11 < geertu> also different from hardware state on kernel entry during normal +10:11 < geertu> boot. +10:11 < geertu> E.g. on normal boot, U-Boot disables several module clocks. +10:11 < geertu> B) What I plan to do till next time +10:11 < geertu> - Test Salvator XS (when it has arrived) +10:11 < geertu> - Suspend/resume for CPG/MSSR and PFC +10:11 < geertu> - Mark periupport priority < H commits that are in linux-next +10:11 < geertu> C) Problems I have currently +10:11 < geertu> - None +10:11 < geertu> EOT +10:12 < geertu> Next is Simon, who is excused +10:12 < geertu> Next is Shimoda-san +10:12 < shimoda> A) study R-Car D3 CPG spec. and forwarded it to Geert-san :) +10:12 < shimoda> B) investigate R-Car D3 CPG things (especially, I should reply Geert-san's email) +10:12 < shimoda> C) about pause feature in rcar-dmac +10:12 < shimoda> -- EOT --- +10:13 < geertu> Thank you Shimoda-san! +10:13 < geertu> Which brings us to +10:13 < geertu> Topic 2. Discussion topics +10:13 < geertu> Shimoda-san? +10:13 < shimoda> yes +10:14 < geertu> Please explain your problem +10:16 < shimoda> problem is that sh-sci and rcar-dmac implementation is unbalance. I'm not sure it is OK or not +10:17 < geertu> You mean sh-sci calls dmaengine_pause(), while rcar-dmac doesn't implement it? +10:17 < shimoda> sh-sci driver calls dmaengine_pause() but rcar-dmac doesn't have .device_pause() for now +10:18 < shimoda> geertu: yes +10:18 < shimoda> for now, i don't encounter any problem, but this implementation is storange to me +10:18 < shimoda> s/storange/strange/ +10:19 < shimoda> since we don't have any issue, we can use them as-is though :) +10:20 < geertu> The sh-sci driver has a workaround for the absence of .pause(), cfr. the commit that introduced the call (e7327c09def48ccfd204025726f11b57a19a9c24) +10:21 < geertu> But I agree the DMA implementation of sh-sci is far from perfect +10:22 < geertu> So Magnus suggested to make a test case if .device_pause() is really needed or not? +10:22 < shimoda> geertu: yes +10:24 < geertu> Due to the workaround, I think it's not needed now. +10:26 < geertu> IIRC, dmaengine_pause() can be called in interrupt context, while dmaengine_terminate_all() cannot (but it's possible we still violate that) +10:26 < shimoda> geertu: "it's" means .device_pause? +10:26 < geertu> In the mean time, dmaengine_terminate_all() has been deprecated, in gavor of dmaengine_terminate_sync() or dmaengine_terminate_async() +10:27 < geertu> Yes, I meant .device_pause() is not needed due to the workaround +10:27 < geertu> s/gavor/favor/ +10:27 < shimoda> oh, i don't know dmaengine_terminate_all has been deprecated +10:28 < geertu> dmaengine_terminate_async() can be called from interrupt-context, dmaengine_terminate_sync() cannot +10:28 < shimoda> i see +10:28 < geertu> Perhaps Niklas has a better understanding of the modern DMA API? +10:31 < shimoda> about sh-sci point of view, keep the dmaengine_pause calling is better? or should we revert it? +10:31 < neg> not much about the pause implementation I only studied the terminate case +10:33 < geertu> shimoda: The commit that added the pause also added the workaround, so it's better to not revert it +10:35 < neg> but yes terminate_async() is the new API, and my understanding is that you should call device_synchronize() after that at some point to make sure it did terminate +10:35 < shimoda> geertu: about workaround patch, there are the followings? +10:36 < shimoda> 3b96304 serial: sh-sci: Do not terminate DMA engine when race condition occurs +10:36 < shimoda> 1d3db60 serial: sh-sci: Call dma_async_issue_pending when transaction completes +10:36 < shimoda> 371cfed serial: sh-sci: Redirect port interrupts to CPU _only_ when DMA stops +10:36 < geertu> https://patchwork.kernel.org/patch/7289991/ was an attempt to add pause support to rcar-dmac +10:37 < geertu> shimoda: Those are fixes for different issues +10:38 < shimoda> geertu: thank you! but the rcar-dmac patch was rejected in upstream, i think +10:38 < geertu> Indeed, Laurent didn't like it +10:41 < shimoda> i got it. i will check about Laurent-san's opinion in the patchwork later +10:41 < geertu> I'll also add a task to look into pause again +10:43 < shimoda> geertu: thank you for adding it +10:45 < shimoda> so my concern point is cleared, thank you! +10:45 < geertu> good to hear that +10:45 < geertu> Do we have anything else to discuss? +10:46 * Marex might've found VC6 devkit to buy +10:46 < shimoda> nothing from me +10:48 < Marex> geertu: shall I grab the VC6 kit ? +10:48 < geertu> Marex: I suppose you'll receive a Salvator-XS anytime soon? +10:48 < Marex> geertu: I will ? :-) +10:49 < Marex> geertu: anyway, the VC6 kit has RSMA connectors for each output to it's easy to measure the frequency +10:49 < geertu> morimoto: Has it been shipped to Öpensöurce AB yet? +10:49 < Marex> geertu: $186 ... hm +10:50 < geertu> Marex: You forgot to write the driver in Tokyo? ;-) +10:51 < Marex> geertu: I didn't have hardware access there :'-( +10:52 < geertu> Marex: too bad +10:52 < Marex> geertu: still, I feel like grabbing the kit would help also because the i2c is accessible and I can operate it with the clock commander (IDT tool for programming the chip) and I can snoop on the i2c bus to figure out the gaps in the datasheet +10:52 < geertu> Marex: Please check with Magnus +10:53 < Marex> geertu: OK +10:53 < geertu> Then I think we're finished +10:54 < geertu> Thanks for joining, and have a nice continued day diff --git a/wiki/Chat_log/20170613-io-chatlog b/wiki/Chat_log/20170613-io-chatlog new file mode 100644 index 0000000..50d7c29 --- /dev/null +++ b/wiki/Chat_log/20170613-io-chatlog @@ -0,0 +1,142 @@ +--- Log opened Tue Jun 13 10:01:42 2017 +10:01 -!- wsa_ [~wsa@p54B337D9.dip0.t-ipconnect.de] has joined #periperi-io +10:01 -!- Irssi: #periperi-io: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal] +10:01 < wsa_> hiya guys +10:01 -!- Irssi: Join to #periperi-io was synced in 5 secs +10:01 < horms> Happy birthday Morimoto-san! +10:01 < wsa_> sorry for being a little late +10:02 < wsa_> yay +10:02 < morimoto> horms: Thank you :) +10:02 < wsa_> Happy Birthday, Morimoto-san! +10:02 < morimoto> and Laurent too :) +10:02 < morimoto> wsa_: thank you +10:02 < neg> congrats +10:03 < morimoto> neg: thanks +10:03 < wsa_> /^\ +10:03 < wsa_> / (/^\) / +10:03 < wsa_> \ ( \ \ / ( \ /^\ +10:03 < wsa_> / ) \ | _|_ \ | |/^\| +10:03 < wsa_> | / _|_ | | _|_ \ / +10:03 < wsa_> _|_ | | | | | | _|_ +10:03 < wsa_> | | | | | | | | | | +10:03 < wsa_> | | | | ****| |******| | | | +10:03 < wsa_> | |****| |**** | | | |****| | +10:03 < wsa_> *| | | | | | | |***** +10:03 < wsa_> * | | H A P P Y | | * +10:03 < wsa_> * * +10:03 < wsa_> | * B I R T H D A Y ! * | +10:03 < wsa_> | ***** ***** | +10:03 < wsa_> |@ ********** ********** @| +10:03 < wsa_> | @ @ ************* @ @ | +10:03 < wsa_> | @@@ @ @ @ @ @@@ | +10:03 < wsa_> | @@@@ @ @ @ @ @@@@ | +10:03 < wsa_> * @@@@@@ @ @ @@@@@@ * +10:03 < wsa_> * @@@@@ * +10:03 < wsa_> ***** ***** +10:03 < wsa_> ********** ********** +10:04 < wsa_> ************* +10:04 < geertu> Happy Birthday, Morimoto-san! +10:05 < wsa_> so, while we eat the cake, let's start ;) +10:05 < wsa_> are there any updates left besides those which came in by mail? +10:05 < geertu> Only 5 candles? I thought he was much older than that. Unless birthday candles start counting at some special year ;-) +10:06 < wsa_> one candle per decade? +10:06 < wsa_> ;) +10:06 < geertu> per octade? heptade? +10:06 < morimoto> geertu: thanks +10:06 -!- shimoda [~shimoda@relprex3.renesas.com] has joined #periperi-io +10:07 < shimoda> sorry for the delayed +10:07 < wsa_> hello shimoda-san +10:08 < wsa_> okay, so no further updates it seems +10:08 < wsa_> are there topics from your side for today? +10:10 < wsa_> also no :) +10:10 < wsa_> i have currently one issue +10:10 < wsa_> i negotiated with zebax everything for the adapters +10:11 < wsa_> even got 5% discount (wohoo) +10:11 < wsa_> and now paypal is blocking the transaction +10:11 < wsa_> with a descriptive "we can't continue" error message +10:12 < geertu> Is your Paypal account tied to a credit card? +10:12 < geertu> Or some other payment method? +10:12 < wsa_> my private one, yes +10:12 < wsa_> but for the zebax order, i selected "order without account" +10:12 < geertu> And you haven't reached the credit limit? +10:13 < wsa_> nope +10:13 < neg> paypal is love... I have never managed to get it working using my Swedish credit card(s) +10:13 < wsa_> i used paypal once in my life so far +10:13 < geertu> OK, let's delegate ordering Zebax adapters to Niklas ;-) +10:13 < wsa_> because of that, how does neg call it, "love" +10:13 < wsa_> haha +10:14 < wsa_> i'll try some more +10:14 < geertu> I used it a few times when there was no other option (Zebax, Seeed Studio, LabNation) +10:15 < wsa_> I got a mail from them that they confirmed my SEPA authorization +10:15 < wsa_> so they confirmed that they have my bank details but they won't let me use their service +10:16 < wsa_> **#$!#$$! +10:16 < geertu> I have no experience with their bank account link. Always used credit card. +10:16 < wsa_> there was no credit-card option +10:16 < wsa_> once I selected Germany as destination +10:17 < geertu> Due to "order without account"? +10:17 < wsa_> likely +10:17 < wsa_> maybe they need a day to verify my account? +10:18 < wsa_> as is said, i will try some more, i'll let you know if I need help +10:18 < wsa_> other than that +10:18 < geertu> Good luck! +10:18 < horms> Neg seems to be the expert on tough love, perhaps a good plan B? +10:18 < geertu> (OTR) I thought that was Marex? ;-) +10:19 < wsa_> jmondi: if you ever need some small tasks to relax from camera hacking, let me know ;) +10:19 < wsa_> shimoda: morimoto: are there any news/requests from Renesas for the IO group? +10:22 < morimoto> nothing from me. shimoda-san ? +10:23 < shimoda> wsa_: as i sent an email yesterday, bsp team has a request about sdio things. but I investigate the request later :) +10:24 < shimoda> this means i cannot discuss it today +10:24 < wsa_> good +10:24 < morimoto> Ahh, about "news", I shipped XS board to you guys +10:24 < morimoto> And 8ch camera to Laurent and Magnus +10:24 < wsa_> that also means no further requests +10:24 < morimoto> (not I/O) +10:25 < shimoda> also i have news +10:25 < shimoda> we will have R-Car D3 boards. maybe in july. +10:25 < wsa_> lots of new boards +10:26 < shimoda> At first step, we have to prepare core things (cpg, pfc and etc...) +10:26 < morimoto> Ahh, this is not I/O, but it seems we have "HDMI compliance issue" now +10:26 <@jmondi> wsa_: missed notification, sorry about that +10:27 < shimoda> but, i don't deside who should have the D3 board. unfortunately we can get about 6 boards +10:28 < shimoda> as the first step, remote access is enough? +10:28 < geertu> Yes, that should be OK +10:29 < shimoda> geertu: thank you for the comment! +10:31 < wsa_> good, so there seem to be no current points to be discussed +10:31 < wsa_> the add. tasks are close to completion +10:31 < neg> morimoto: what can you tell us about the HDMI compliance issue? Me an Kieran found some odd things on H3 ES2.0 for HDMI input, have still not recived my ES2.0 so can't analize it further untill that time +10:31 < wsa_> and new tasks will be discussed somewhat later +10:32 < morimoto> neg: we will have meeting to know more detail. I will report it in MultiMedia chat meeting +10:33 < neg> morimoto: OK, thanks for the heads up :-) +10:33 < morimoto> neg: np +10:33 < wsa_> so, i think we are done +10:34 < shimoda> thank you! +10:34 < wsa_> good, that gives morimoto-san more time to celebrate his birthday +10:34 < wsa_> :D +10:34 < morimoto> hehe +10:34 < horms> adios +10:35 <@jmondi> morimoto: happy brithday (am I late, maybe? :) +10:35 < morimoto> jmondi: thank you +10:35 * jmondi seen "Tues" as meeting date and thought it was in two days.. good! +10:36 < wsa_> so, guys, happy hacking! +10:38 < geertu> Thx, happy hacking, too! +10:38 < neg> thanks all +10:41 < morimoto> neg: today I shipped 8ch camera and board to OpensourceAB. It will arrive in 2 - 3 days. you can talk with Magnus how and when forward it to you +10:42 < morimoto> (and XS boaard, too :) +10:42 < geertu> Note that my XS spent 7 days at customs +10:43 < neg> morimoto: thanks, looks like I know what I will be doing this summer :-) +10:44 < morimoto> neg: Hehe :) +10:45 < morimoto> 1 note is that actually prepared 4 camera + short cables + 4 camera + long cables +10:45 < morimoto> for Laurent / Niklas +10:45 < morimoto> But, export paper work guys didn't accept such combination +10:46 < morimoto> Thus, it will be 8 short camera / 8 long camera +10:46 < morimoto> I don't know who can receive long set / shrt set +10:48 < neg> morimoto: for me it do not matter if the cables are long or short, I have no plan to rig the setup all around my appartment :-) +10:50 < geertu> neg: You can watch yiur girlfriend and the front door all day! +10:50 < geertu> s/yiur/your/ +10:51 < morimoto> neg: I think you and Laurent can switch 4 cables each other in PeriPeriCon timing ? +10:52 -!- shimoda [~shimoda@relprex3.renesas.com] has quit Quit: WeeChat 0.4.2 +10:52 < neg> geertu: yea I suggested to setup that devboard in the bedroom, she was not thrilled about the idea +10:52 < neg> morimoto: yes ofc, no problem +10:54 < geertu> neg: as long as you have the long cables, the devboard itself can be in the bedroom (modulo fan noise) +11:04 -!- morimoto [~user@relprex2.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +--- Log closed Tue Jun 13 11:32:58 2017 diff --git a/wiki/Chat_log/20170620-core-chatlog b/wiki/Chat_log/20170620-core-chatlog new file mode 100644 index 0000000..6bebc1c --- /dev/null +++ b/wiki/Chat_log/20170620-core-chatlog @@ -0,0 +1,362 @@ +Core-chat-meeting-2017-06-20 + +10:06 < geertu> Welcome to today's Core Group Chat! +10:06 < dammsan> i've heard that issue before +10:06 < geertu> pinchartl: Does it happen on H3 ES2? +10:06 < dammsan> maybe m3-w don't recall +10:06 < pinchartl> geertu: haha, good joke :-) +10:06 < pinchartl> (I'll tell you when I'll have an H3 ES2.0 board...) +10:06 < geertu> pinchartl: Havenn't you played with H3 ES2 in Tokyo? +10:07 < pinchartl> geertu: not to the point where I could test this properly +10:07 < geertu> Agenda: +10:07 < geertu> 1. Status updates +10:07 < geertu> 2. Core additional tasks +10:07 < geertu> Topic 1. Status updates +10:07 < geertu> A) What have I done since last time +10:07 < geertu> B) What I plan to do till next time +10:07 < geertu> C) Problems I have currently +10:07 < pinchartl> dammsan: if anything comes back to your memory, please let me know +10:07 < dammsan> ok! +10:07 < pinchartl> (now I'll stop hijacking the meeting) +10:07 < dammsan> (same here) +10:07 < geertu> 'sort -R' tells me Niklas is first +10:08 < neg> A) Nothing +10:08 < neg> B) Nothing planed (Multimedia eats time...) +10:08 < neg> C) None +10:08 < neg> --eot-- +10:09 < geertu> Thank you, Niklas! +10:09 < geertu> Next is Magnus +10:09 < dammsan> A) IPMMU update posted +10:10 < dammsan> B) resend IPMMU if I get enough feedback, need to review patches from Laurent +10:10 < dammsan> C) None +10:10 < geertu> Thank you, Magnus! +10:11 < geertu> Next is Shimoda-san +10:11 < shimoda> yes +10:11 < shimoda> A) +10:12 < shimoda> - Nothing +10:12 < shimoda> B) +10:12 < shimoda> - Get feedback about R-Car D3's CPG for Geert-san's questions +10:12 < shimoda> C) +10:12 < shimoda> - Nothing +10:12 < shimoda> -- EOT -- +10:12 < geertu> Thank you, Shimoda-san! +10:12 < geertu> Next is Geert +10:13 < geertu> A) +10:13 < geertu> - RFC for CPG/MSSR module clock restore during resume +10:13 < geertu> - Initial Salvator XS support +10:13 < geertu> B) +10:13 < geertu> - More suspend/resume for CPG/MSSR and PFC +10:13 < geertu> - Mark periupport priority < H commits that are in linux-next +10:13 < geertu> C) +10:13 < geertu> - None +10:13 < geertu> -- EOT -- +10:13 < geertu> Next is Marek +10:14 < marex-cloud> Marek is broken +10:14 < marex-cloud> A) ULCB M3 U-Boot port is posted , but only tested by booting U-Boot from U-Boot +10:15 < marex-cloud> B) work on DT conversion of the U-Boot , so we can drop DT from Linux into U-Boot and create board ports that way instead +10:15 < marex-cloud> C) none +10:15 < marex-cloud> is U-Boot even part of the core group ? +10:16 < geertu> Good question! +10:16 < geertu> dammsan: It's not listed in my SoW ;-) +10:17 < geertu> But as it's part of basic infrastructure, it fits better in core than in any of the other groups +10:18 < geertu> Regarding B, that means we'll have to update U-Boot regularly, as we keep on adding more device support to the DTS? +10:18 < marex-cloud> that's a good question +10:19 < marex-cloud> usually you don't want to update your bootloader in a delivered product +10:19 < marex-cloud> on a devkit, that might be easier +10:19 < geertu> I guess if you TFTP a specific DTB, it will take precedence? +10:19 < marex-cloud> then again, while you're adding more devices to Linux, U-Boot will only support a subset of them (we don't need ie. any of the multimedia stuff in U-Boot, maybe video out, but that's about it) +10:20 < marex-cloud> geertu: for now, I'd like to keep bundling the DT with U-Boot just like we do on other boards +10:20 < geertu> Or is the DTB stored in a separate partition on FLASH, so it cane be updated easily? +10:20 < marex-cloud> geertu: we can unbundle that later, once things are a bit more fleshed out +10:20 < marex-cloud> geertu: also, we'd probably need to patch BL2/BL3 to load two files, U-Boot and DT +10:21 < pinchartl> marex-cloud: what "other boards" ? +10:21 < geertu> marex-cloud: IC, as U-Boot need the DT for its own initialization +10:22 < marex-cloud> pinchartl: other boards in U-Boot +10:22 < geertu> it cannot load it from FLASH later. +10:22 < geertu> s/need/needs/ +10:22 < pinchartl> marex-cloud: don't break my TFTP + NFS workflow +10:22 < marex-cloud> geertu: there are ways around that if your flash is memory mapped, which I'm not sure the RPC supports +10:22 < geertu> BL2/BL3 can pass a minimal DTB, and U-Boot can load a more advanced one later, which we can update when needed? +10:22 < pinchartl> I'm fine if U-Boot needs some DT that I don't need to update more often than updating the boot loader itself +10:22 < marex-cloud> pinchartl: eh ? how would that break it ? +10:23 < marex-cloud> pinchartl: OK +10:23 < pinchartl> but I want to be able to load kernel + DT over TFTP and boot them regardless of what DT is bundled with U-Boot +10:23 < marex-cloud> pinchartl: ah, that's fine then +10:23 < marex-cloud> pinchartl: you can use separate DTs for both (although it would be preferred if you didnt :) ) +10:24 < pinchartl> in particular, if U-Boot patches the DT (to set the DRAM size for instance), it has to patch the DT I load over TFTP +10:24 < marex-cloud> pinchartl: U-Boot does patch the DT passed to the kernel with RAM size and ethernet MAC +10:24 < marex-cloud> geertu: well, if that's the case already, we could use that to supply DT to U-Boot +10:25 < pinchartl> marex-cloud: if you want to use the same DT for U-Boot and Linux, then add TFTP support to BL3 :-) +10:25 < marex-cloud> geertu: but I'd rather like to start slow, get the DT support in at all first and then move on to fiddling with BL +10:26 < marex-cloud> geertu: I think these are two tasks which depend on one another, but getting the DT support into U-Boot with bundled DT is much easier then complicating it with passing DT from BL +10:27 < marex-cloud> pinchartl: just use U-Boot as your TFTP client ... +10:27 < geertu> marex-cloud: OK, bundling a (minimal) DT is fine. +10:28 < marex-cloud> geertu: I'd like to bundle the same DT as we use in linux, not a minimal one ... +10:29 < marex-cloud> geertu: the less we diverge with the DT, the better +10:29 < geertu> marex-cloud: OK, but we're still developing "the one in Linux" +10:29 < marex-cloud> geertu: you can sync the one in U-Boot with the one in Linux, that's OK +10:30 < marex-cloud> geertu: until Linux pulls out the DTs from it's codebase, we don't have much other options anyway ... +10:31 < geertu> OK +10:31 < geertu> Thank you, Marek! +10:31 < geertu> Next is Simon +10:33 < horms> Todo Update +10:33 < horms> NULL +10:33 < horms> A) What have I done since last time +10:33 < horms> B) What I plan to do till next time +10:33 < horms> No Core task at this time +10:33 < horms> C) Problems I have currently +10:33 < horms> D) Posted/Accepted bugfix patch +10:33 < horms> None +10:33 < horms> -- end -- +10:33 < geertu> Thank you, Simon! +10:33 < geertu> Next is Laurent +10:34 < pinchartl> nothing on my side +10:34 < pinchartl> as usual :-) +10:34 < geertu> Thank you, Laurent! +10:34 < geertu> Next is Jacopo +10:35 < jmondi> yep +10:35 < jmondi> A) RZ pinctrl: sent v6 off-line to collect feedback on how to handle pinmux flags inside the driver +10:36 < jmondi> A) pinconf generic: sent patch to add output-enable, on which the RZ pinctrl depends on +10:36 < jmondi> B) Keep working on this (mostly background due to high latencies in receiving feedbacks from gpio people) +10:36 < jmondi> C) Null +10:36 < jmondi> --eot-- +10:37 < geertu> Thank you, Jacopo! +10:38 < geertu> Topic 2. Core additional tasks +10:39 < geertu> Is anyone interested in doing a core additional task in Q3 (targets middle of August and middle of September)? +10:39 < geertu> Topics to consider: +10:40 < geertu> - Taking over R-Car Gen3 CPUFreq support +10:40 < geertu> - Salvator-XS board support +10:40 < geertu> - R-Car D3 and Draak board support +10:40 < geertu> - DMA (as usual ;-) +10:40 < geertu> - As v4.14 will be the next LTS, I think it would be good to tackle the +10:40 < geertu> missing DT description tasks by then. +10:40 < geertu> Whether these are done in the context of base or additional contracts is +10:40 < geertu> TBD. +10:40 < geertu> - H3 ES2.0 PFC tasks +10:40 < geertu> - Emergency shutdown +10:40 < geertu> - Detection = I/O +10:40 < geertu> - Handling = core +10:41 < horms> What is involved in the first two? +10:41 < neg> As previusly indicated I'm interested in Emergency shutdown :-) +10:42 < geertu> horms: Khiem posted a first version last year. It received some review comments, but they were never adressed. +10:43 < geertu> IIRC, the framework itself has seen some changes too, so the patches need to be updated. +10:43 < horms> Ok, I'd be happy to look at that loose end. +10:43 < geertu> The task is +10:43 < geertu> CPUFreq,v4.13,public,khiem,R-Car Gen3 CPUFreq support +10:43 < geertu> There's a related task +10:43 < geertu> DevFreq,?,noplan,?,GPU needs DevFreq, as DVFS is shared between CPU and GPU +10:44 < geertu> but that's more complicated, as we don't support the GPU in upstream +10:45 < geertu> so it may be more appropriate to consider the latter as a separate task +10:45 < jmondi> geertu: pinchartl: I only have 1 additional task for Q3 and I'm not sure where it will be allocated, but generally speaking I would be interested in looking in cpufreq.. Maybe I can help Simon on this in Q4? +10:46 < geertu> jmondi: It's a bit too early for Q4. And we'll have to see how it goes first. +10:46 < geertu> For D3/Draak one important question is: when will hardware be available? +10:46 < pinchartl> jmondi: if you have time for multimedia in Q3, I'd like you to continue the work on the max9286 and rdacm20 drivers +10:47 < jmondi> pinchartl: that will be most of my base time, on top of which there will be an additional task tbd +10:47 < dammsan> geertu: i think remote access for D3 may be possible for first batch +10:47 < shimoda> geertu: i will get D3 boards in early July. but i doubt it though... :) +10:48 < geertu> dammsan: Good to hear that! +10:48 < dammsan> shimoda: any other boards available? =) +10:48 < geertu> Japanese "I doubt it" == "No way!"? ;-) +10:48 < dammsan> "Maybe" == "No way" +10:48 < dammsan> =) +10:48 < shimoda> anyway I negotiate someone we must need a board at least :) +10:48 < marex-cloud> geertu: since when do japanese speak english ? :) +10:49 < shimoda> dammsan: :) +10:49 < geertu> Do other D3 boards exist? +10:50 < dammsan> Not sure +10:50 < shimoda> I don't know +10:50 < horms> I think there is a schrodinger board +10:50 < dammsan> shimoda: how about other SoC? =) +10:51 < shimoda> but, i heard some option boards exist for D3 +10:51 < pinchartl> dammsan: speaking of boards, is there a plan to send H3ULCBs to team members ? +10:51 < geertu> shimoda: The MCU-board for CN50? +10:52 < shimoda> dammsan: about V3M board, i'm asking board team when we can buy it +10:52 * marex-cloud would be interested in M3ULCB , since they're not in stock anywhere :-/ +10:52 < dammsan> pinchartl: i think ULCBs should be purchased from within EU +10:52 < marex-cloud> also, what about the RPC driver ? Can we do something about that ? +10:52 < shimoda> geertu: sorry i don't know the detail +10:52 < dammsan> however it might be wise to wait with H3 to get ES2+ +10:53 < pinchartl> dammsan: that's fine with me +10:53 < marex-cloud> dammsan: I tried, they're not in stock, more available in ~1 month ; digikey cannot ship them from US due to restrictions +10:53 < dammsan> shipito.com =) +10:54 < pinchartl> dammsan: have you used that to work around export restrictions ? +10:54 < dammsan> (they can fill in the customs declaration for you if you pay them) +10:54 < dammsan> i use them to get stuff from the US to JP all the time +10:54 < marex-cloud> dammsan: ooooooh :-) +10:55 < marex-cloud> dammsan: thanks +10:55 < pinchartl> https://www.shipito.com/en/help/faq#restricted +10:55 < dammsan> but i fill in my papers by myself +10:57 < marex-cloud> or maybe it's worth waiting for the ULCB to become available in EU again ? +10:57 < dammsan> no stress from my side +10:59 * marex-cloud really wants to test U-Boot on it :-) +10:59 < marex-cloud> dammsan: any opinion on the RPC driver ? +11:00 < pinchartl> (unrelated question as everybody seems idle: should I add comments such as "Under development" to the periupport file, or should I just leave the non-upported commits untouched ?) +11:01 < horms> <2c>seems useful to me </2c> +11:01 < pinchartl> horms: thanks +11:01 < dammsan> marex-cloud: sorry no time to look into things yet +11:02 < marex-cloud> dammsan: no stress :-) +11:05 < pinchartl> horms: another related question, are commit IDs in your arm64-dt-for-v4.13 branch stable ? can I use them in periupport, or will the commits be cherry-picked/rewritten when going upstream ? +11:06 < horms> simple answer: yes +11:06 < pinchartl> horms: thanks +11:06 < pinchartl> (unless something bad happens I assume, but that's ok) +11:06 < geertu> horms: Unless Olof is in a bad mood ;-) +11:06 < horms> That branch has been merged into ARM-SoC and is closed +11:06 < horms> Olof was a bit grumpy but pulled them anyway +11:07 < horms> However, before things are pulled they may change +11:07 < pinchartl> horms: how so ? +11:08 < horms> well for one things I make errors and fix things +11:08 < horms> for another people ask me to drop patches +11:08 < horms> and lastly the ARM-SoC maintainers ask for changes from time to time +11:09 < geertu> Anyone else interested in doing a core additional task? +11:09 < geertu> Well, you can still email me after the meeting. +11:09 < marex-cloud> geertu: what's missing on the XS ? +11:09 < pinchartl> horms: of course. fair enough. I was mostly interested in knowing whether the process involves modifying commits as part of the normal workflow +11:09 < geertu> Salvator-XS,?,plan,marek,VersaClock 5P49V6901A clock generator driver +11:10 < horms> pinchartl: no, its just for exceptions +11:10 < geertu> marex-cloud: I assume you're already looking into that? +11:10 < dammsan> geertu: at some point i would like to tackle the "multiple-devices" per pin issue we have with DT and PFC +11:10 < geertu> Plus Salvator-XS has H3 ES2.0, which has very limited PFC support for now. +11:11 < marex-cloud> geertu: patches are available, I sent them to dammsan to get an OK from him to submit to linux-clk ; will CC renesas-soc once cleared +11:11 < geertu> But lots of pins/functions/groups can be mined from the BSP. They just need review/testing. +11:11 < marex-cloud> geertu: speaking of that, dammsan , do I need to ask for clearance to submit patches from you always or shall I just submit ? +11:11 < marex-cloud> dammsan: which way do you prefer to handle this ? +11:12 < dammsan> good question +11:12 < dammsan> i think stuff ordered directly from my is good to handle the existing way +11:12 < marex-cloud> dammsan: if I ask for clearance every time, you have more control, but it introduces delays +11:12 < dammsan> however for your base task time there is no need to check with me +11:12 < geertu> Should all patches follow the reverse money path? ;-) +11:13 < dammsan> so if you have a strict contract then talk to me +11:13 < dammsan> otherwise ignore me +11:13 < dammsan> makes sense? +11:13 < dammsan> i expect everyone to coordinate with the group leaders anyway +11:14 < pinchartl> dammsan: just curious, is there any reason to hold off by default on posting patches ? +11:14 < dammsan> not really +11:14 < geertu> Most H3 ES2.0 PFC work needed is small things, not worth a full additional task. So I'd recommend just doing it when scratching an itch... +11:15 < dammsan> geertu: i noticed that ULCB has a SCIF1 as secondary debug port +11:15 < geertu> dammsan: What's the "multiple-devices" per pin issue again? +11:15 < dammsan> (that may not be populated on the board) +11:15 < geertu> dammsan: Salvator-X has, too? +11:16 < marex-cloud> dammsan: I don't quite get it, so I might just ask for your clearance until I see the pattern +11:16 < dammsan> on those two pins for RX and TX we can chose between SCIF and HSCIF +11:16 < dammsan> marex-cloud: thats fine +11:16 < dammsan> geertu: so the hardware allows us to select either SCIF or HSCIF +11:17 < dammsan> but can we do that with current DT? +11:17 < marex-cloud> dammsan: thank you +11:17 < dammsan> (without setting sofware policy) +11:17 < dammsan> that's what i mean by "multiple devices" per pin +11:18 < dammsan> i want to describe the hardware in DT =) +11:19 < geertu> dammsan: DT overlay? (modulo aliases, for which I have a hackish patch) +11:19 * pinchartl will have to leave soon +11:20 < pinchartl> I'd like to briefly discuss meeting schedules if that's fine +11:20 < marex-cloud> dammsan: is that what ie. IMX does now ? Each peripheral has a list of per-pin settings instead of what we have on RCar3 PFC ? +11:20 < pinchartl> dammsan: you expressed the desire to group multiple meetings in the same day +11:20 < dammsan> yes +11:20 < pinchartl> for this week it's too late, I'll send the invitation for the multimedia meeting for tomorrow +11:20 < dammsan> i would prefer that if possible +11:20 < dammsan> sure +11:20 < pinchartl> but for the next one, how would you like to handle this ? +11:20 < dammsan> not sure what other people think +11:21 < dammsan> i like to group together meetings and paperwork into a single day if possible +11:21 < geertu> You want to have Core, I/O, and MultiMedia meetings on the same day? +11:21 < dammsan> not sure what is the best way to deal with things +11:21 < geertu> Or on the same day of week? And switch to tri-weekly? +11:22 < dammsan> i just know that several meetings per week starting in the afternoon kind of kills the evening schedule pretty good +11:23 < geertu> With all meetings on a single day, it may be difficult to meet timezone constraints. +11:23 < dammsan> yeah there is that for sure +11:23 < pinchartl> we shouldn't start earlier than 8:00 British time +11:23 < dammsan> i would like to know if the other japanese guys have some opinion about schedule +11:24 < pinchartl> that's 16:00 Japanese time +11:24 < pinchartl> if we have three one-hour meetings, that's up to 19:00 in Japan +11:24 < pinchartl> 08:00-11:00 in the UK +11:24 < pinchartl> 09:00-12:00 in central Europe +11:24 < pinchartl> and 10:00-13:00 in Finland +11:25 < geertu> In Summer +11:25 < pinchartl> yes +11:25 < pinchartl> we'd have to strictly cap every meeting to one hour though +11:25 < dammsan> for me, i'd rather spend one day and continue after EU lunch time instead of two days +11:25 < pinchartl> which should be enough for status reporting +11:26 < pinchartl> but might be short if we need to start discussing issues +11:26 < pinchartl> or maybe 3x 1.5h meetings then ? +11:26 < neg> Maybe status reporting can be moved to email, as done for the IO group and only talk about points of interesst during the meeting? +11:26 < dammsan> with 2 group meetings on tue + wed and two days in the renesas office that kind of kills 4 nights without any chance for code output +11:27 < dammsan> if we could do it before EU lunch time then that would be very nice IMO +11:27 < pinchartl> neg: we already do status reporting through e-mail. I think it's useful to copy&paste it here, as it gives me (and others) a chance to ask questions +11:29 < neg> pinchartl: There is no call for A/B/C updates for the Core meeting by mail, but I agree that pasting it here is usefull +11:29 < dammsan> alternatively do brief 30 minutes per group before lunch, and schedule afternoon on-demand +11:29 < dammsan> but do that on a single day for all groups +11:30 < dammsan> perhaps that would make the situation worse for you guys +11:30 < pinchartl> I don't mind personally +11:30 < pinchartl> it would be nice if the meetings didn't overlap lunch time though +11:31 < dammsan> it is good with dinner break at this side of the world too +11:31 * marex-cloud doesn't mind either way +11:32 < dammsan> how about restricting to only A/B/C before lunch EU time +11:32 < dammsan> and propose afternoon topics on the fly +11:32 < dammsan> then have a lunch/dinner break +11:32 < dammsan> and get back to it +11:32 < jmondi> it's fine for me as well, but generally speaking, 1 day of just meetings it's really bad :) +11:33 < jmondi> but I understand the timezone thing... +11:33 < dammsan> yeah coming home at 21:00+ several days in a row with no code output kind of sucks +11:33 < pinchartl> another idea +11:33 < pinchartl> if it's just A/B/C in the morning +11:33 < pinchartl> and if we have the three groups on the same morning +11:33 < pinchartl> do we need to split the meeting between groups ? +11:34 < pinchartl> we could have a combined A/B/C +11:34 < dammsan> sounds good to me +11:34 < neg> I like that idea as well +11:34 < pinchartl> but then who will be responsible for writing reports ? :-) +11:35 < pinchartl> we could take turns I suppose +11:35 < dammsan> perhaps the group leaders need to bid on each patch =) +11:35 < pinchartl> I have to go now I'm afraid +11:36 < pinchartl> I'll let you continue the discussion and read the result after lunch +11:36 < dammsan> sure +11:36 < dammsan> bon apetit +11:36 < dammsan> ! +11:36 < pinchartl> (oh, and schedule-wise, Tuesday is probably the worst day for me, as that's the day of my weekly Linux developers lunch in Helsinki) +11:36 < dammsan> geertu: what is your opinion about meeting schedule? +11:37 < geertu> dammsan: We could move the A/B/C to email, and use the meeting for questions/discussions +11:37 < pinchartl> dammsan: if you're still at the office, could you check with Morimoto-san about the Salvator-XS shipping issues ? in particular I'd like to know whether a permanent import is fine, as explained in my last e-mail +11:38 < geertu> That frees up some time +11:38 < pinchartl> geertu: I'd still like to copy&paste the status report here, as it often leads to questions (at least for me) +11:38 < dammsan> pinchartl: i'm not in the renesas office. i will setup a H3 ES2 board for your remote access +11:38 < pinchartl> copy & paste shouldn't be long +11:38 < pinchartl> dammsan: thank you +11:38 < pinchartl> now I really have to go +11:38 * pinchartl is gone +11:39 < dammsan> geertu: that sounds good to me +11:39 < geertu> I'd prefer not to split the meeting in before/after lunch/dinner +11:39 < dammsan> same here ideally +11:39 < geertu> Just have 1 hour for each group? And each group leader is responsible for the report for his group, as is currently done +11:40 < dammsan> that seems pretty straightforward and good to me +11:40 < geertu> Round-robin reporting of a huge 3 hour meeting with topics you may not be interested in is a killer +11:40 < dammsan> yeah for sure +11:40 < dammsan> just want to avoid having that multiple days in a row =) +11:41 < geertu> So it's all about making effective use of the limited time (1 hour/topic) +11:41 < dammsan> i agree +11:41 < geertu> s@topic@group@ +11:41 < dammsan> geertu: can we improve how we handle SCIF/HSCIF in DT somehow? +11:42 < geertu> Or do we need a different split in 4 submeetings: Core. I/O, MultiMedia, Common? +11:43 < dammsan> as long as they are on the same day i'm happy =) +11:43 < geertu> I/O is usually a short meeting +11:43 < geertu> MM is usually long? +11:43 < dammsan> similar to core i think +11:43 < geertu> dammsan: pinctrl-0 and pinctrl-1, cfr. SDHI? +11:43 < neg> yes I think MM tends to be a bit longer then Core +11:45 < jmondi> a bit longer, yes +11:45 < dammsan> geertu: that's for two states within same device, no? +11:46 < geertu> dammsan: I know. As SCIF and HSCIF are handled by the same driver, we could hack in something? +11:46 < dammsan> hacking is possible for sure +11:47 < dammsan> maybe this is similar to the I2C master switch topic +11:47 < marex-cloud> dammsan: do you need to switch between those two at runtime ? +11:47 < geertu> In some sense all pinctrl is "software policy" +11:47 < geertu> have you looked at Pantelis' connector work? +11:48 < dammsan> i saw a talk from him +11:48 < marex-cloud> geertu: did that make it to mainline ? :) +11:48 < geertu> I think it would allow to describe a serial port the way we wwant +11:48 < dammsan> marex-cloud: i want to separate hardware description and software policy +11:48 < geertu> marex-cloud: No, just like DT overlays +11:49 < dammsan> if we can use both SCIF and HSCIF on pins then our DT should represent that somehow +11:49 < marex-cloud> geertu: DTOs are in mainline, I think the missing part is the configfs interface for loading them +11:49 < geertu> For the hungry people: shall we conclude the Core meeting itself? We can keep on chatting, of course. +11:49 < dammsan> geertu: good point +11:49 < geertu> marex-cloud: Right, that's the part I mean +11:55 < geertu> Thanks for joinin, and have a nice continued day! diff --git a/wiki/Chat_log/20170621-mm-chatlog b/wiki/Chat_log/20170621-mm-chatlog new file mode 100644 index 0000000..c7a92b6 --- /dev/null +++ b/wiki/Chat_log/20170621-mm-chatlog @@ -0,0 +1,245 @@ +Multimedia-chat-meeting-2017-06-21 + +09:03 < pinchartl> topics for today are +09:03 < pinchartl> - status update +09:03 < pinchartl> - additional tasks for Q3 (I'll keep this very brief) +09:03 < pinchartl> - next meeting +09:03 < pinchartl> anything else ? +09:04 < pinchartl> ok +09:04 < pinchartl> Topic 1. Status check for the multimedia tasks +09:04 < pinchartl> jmondi: you can start +09:05 < dammsan> hi guys sorry about the delay +09:05 < jmondi> pinchartl: thanks +09:05 < pinchartl> hi Magnus ! +09:05 < jmondi> I guess this is punishment for having sent a late update +09:05 < jmondi> A) +09:05 < jmondi> - OSS Japan] +09:05 < pinchartl> jmondi: not quite, it's alphabetical order. you can blame your first name ;-) +09:06 < jmondi> pinchartl: damn parents! +09:06 < jmondi> - digital/parallel input on Gen3 +09:06 < jmondi> -- hw setup (which took me longer than expected for several reasons) +09:07 < jmondi> -- sent RFC patches to add support for digital input on Gen3 +09:07 < jmondi> B) resume 8 channel camera setup where we left it in Japan +09:07 < jmondi> - Address review comments for digital input on Gen3 +09:07 < jmondi> C = NULL +09:07 < jmondi> --eot-- +09:08 < pinchartl> so the hardware setup for parallel camera is now working ? +09:08 < jmondi> meh +09:08 < jmondi> I can read/write registers (chip ID excluded) +09:09 < pinchartl> can you read other registers ? +09:09 < jmondi> on the I2c bus I mean +09:09 < jmondi> yes +09:09 < pinchartl> or do they all return 0 ? +09:09 < jmondi> no, just chip ID +09:09 < pinchartl> so other registers return meaningful values, but chip ID returns 0 ? +09:09 < jmondi> which is weird +09:09 < jmondi> yep +09:09 < pinchartl> that's very weird +09:09 < jmondi> it is +09:09 < pinchartl> there's something fishy there +09:10 < geertu> They forgot to program the chip with the chip ID? Can you write to the chip ID register (once)? +09:10 < pinchartl> jmondi: have you tested video capture ? does it work ? +09:10 < jmondi> to clear things out, I have planned to not only trust i2c-gpio debug ouput, but use a logica analyzer (which I now have) and see what's actually on the bus +09:11 < pinchartl> jmondi: good idea +09:11 * neg is lurking from cellphone +09:11 < pinchartl> hi neg +09:11 < jmondi> pinchartl: nope, I have problems with media-controller complaining about broken pipe when sending IOCTLs on the video device node +09:11 < pinchartl> jmondi: ok +09:11 < jmondi> geertu: no, it's read only +09:13 < pinchartl> jmondi: thank you +09:13 < pinchartl> next, kbingham[m] +09:14 < pinchartl> I'll copy & paste his report +09:14 < pinchartl> since last meeting +09:14 < pinchartl> - OSS Japan +09:14 < pinchartl> - ADV748x v4, v5 +09:14 < pinchartl> The final major blocker for upstream integration was the lack of EDID support. Hans would not accept upstream without this, so EDID has been implemented and tested it as working. (Can now capture from Laptop output). Once Hans' remaining comments are resolved a (final?) v6 to be posted very soon. +09:14 < pinchartl> - Discovered a bug in "v4l: vsp1: Repair suspend resume operations for video pipelines" +09:14 < pinchartl> The bug was introduced from the HGO/HGT control lock. Full log is available at http://paste.ubuntu.com/24864203/ +09:14 < pinchartl> - Supported Laurent in preparing VSP-DU branch for upstream pull +09:14 < pinchartl> - Tested Sakari's ACPI Graph / fwnode branches (used by ADV748x) +09:14 < pinchartl> for the next two weeks: +09:14 < pinchartl> - v6 ADV748x hopefully for mainline integration (DT bindings approval still pending) +09:14 < pinchartl> - Investigate HGO/HGT locking issue. +09:14 < pinchartl> - Work with Hans to get remaining VSP1 patches integrated upstream +09:14 < pinchartl> issues and blockers +09:14 < pinchartl> - HGO/HGT issue hampered desires to have the pending VSP1 patches upstream +09:14 < pinchartl> already, but should not block progress. It should be possible to split those patches out from testing and get some more momentum, and/or repair the issue. +09:15 < pinchartl> next, me +09:15 < pinchartl> since last meeting +09:15 < pinchartl> - OSS Japen +09:15 < pinchartl> Japan even +09:15 < pinchartl> - Holidays +09:15 < pinchartl> - H3 ES2.0 display support +09:16 < pinchartl> I've discovered issues in the patches I've posted and I'm working on addressing them +09:16 < pinchartl> - M3-W HDMI output support +09:16 < pinchartl> This is useful to test the ES2.0 code as the M3-W VSP and DU are similar to the H3 ES2.0 +09:16 < pinchartl> for the next two weeks +09:17 < pinchartl> - Continue H3 ES2.0 and M3-W display-related work +09:17 < pinchartl> - VSP / DU initialization order fix +09:17 < pinchartl> issues and blockers +09:18 < pinchartl> - Salvator-XS stuck in customs and Salvator-X H3 ES2.0 unavailable through remote access, so I'm left without a way to test H3 ES2.0 code +09:19 < dammsan> pinchartl: i'm working on enabling remote access for you +09:19 < pinchartl> dammsan: thank you. I'll also need local access very soon +09:19 < pinchartl> the shipping company hasn't replied to my e-mails +09:19 < pinchartl> possibly because they don't speak English +09:20 < jmondi> that's a good start with them, indeed +09:21 < pinchartl> or it might be that all my e-mails end up in their spam box +09:22 < pinchartl> I've sent them e-mails on Monday and Tuesday and they haven't replied +09:23 < pinchartl> dammsan: H3 ES2.0 will very likely not be ready in Q2 if I don't receive the board ASAP +09:23 < dammsan> have you tried communicating by smoke signals? =) +09:23 < pinchartl> I tried calling them, they don't speak English +09:23 < pinchartl> and they don't react to my e-mails +09:24 < dammsan> pinchartl: i can give you H3 ES2 on Salvator-X, Salvator-XS and ULCB +09:24 < dammsan> via remote access +09:24 < pinchartl> dammsan: I can perform limited testing only through remote access :-/ +09:24 < dammsan> i can hook up the VGA connector to VNC if that helps +09:24 < pinchartl> it's still useful +09:24 < pinchartl> but I need to test the LVDS output +09:24 < dammsan> not sure if ULCB has VGA +09:24 < pinchartl> that's the tricky one +09:24 < dammsan> yeah sorry no can do +09:25 < pinchartl> I know, not blaming you +09:25 < dammsan> i'll begin with Salvator-X H3 ES2 +09:25 < pinchartl> I'm just saying that if the board doesn't arrive tomorrow, I won't deliver for Q2 +09:25 < pinchartl> Friday is a public holiday here so they won't deliver anything +09:26 < pinchartl> and if I receive the board on Monday it will be too late for Q2 +09:26 < pinchartl> anyway, that's it for me +09:26 < pinchartl> dammsan: your turn :-) +09:26 < dammsan> nothing to report from me really +09:27 < dammsan> i have review of your IPMMU DU series on my TODO still +09:27 < pinchartl> speaking of IPMMU, have you checked whether the IOMMU fixes for the v4.12-rc1 regressions have been merged ? +09:28 < dammsan> no sorry i did not +09:28 < geertu> pinchartl: They were merged last week +09:29 < geertu> through joro's tree, IIRC +09:29 < pinchartl> geertu: thank you ! +09:29 < pinchartl> that's a relief +09:31 < pinchartl> next, Morimoto-san +09:31 < pinchartl> Since last meeting: +09:31 < pinchartl> - Posted remaining sound-related cleanup patches +09:31 < pinchartl> Almost all the patches have been accepted. +09:31 < pinchartl> - Cleanup the ALSA SoC framework +09:31 < pinchartl> This was Lars-Peter's plan, but nothing happen so far, so let's give it a try ourselves. +09:31 < pinchartl> For the next two weeks: +09:31 < pinchartl> - Continue ALSA SoC cleanup work +09:31 < pinchartl> Issues and Blockers: +09:31 < pinchartl> - HDMI legal issues +09:31 < pinchartl> Our Current Gen3 datasheet has HDMI related information, and because of it, we are upstreaming code. But it seems this is a compliance infraction. Now, our law team is checking the agreement with Synopsys and HDMI organization, and our current HDMI status, upstreamed code, ... +09:31 < pinchartl> While there is already upstreamed Synopsys HDMI code in Linux, this is a different issue. We have to keep distance from HDMI sound until this issue is cleared. +09:31 < pinchartl> the last point worries me +09:31 < pinchartl> Morimoto-san mentioned HDMI sound only +09:32 < pinchartl> I wonder what the implications are for HDMI video +09:33 < pinchartl> dammsan: do you have any information about that ? +09:33 < dammsan> no special information sorry +09:33 < dammsan> just smell wise it reminds me of SDHI +09:33 < dammsan> basically a lot of FUD +09:33 < dammsan> hopefully it will become less windy in the not so distant future +09:34 < dammsan> after people have sorted out the difference of documentation license, software license and open source and what not +09:34 < pinchartl> on the video output side we're mostly refactoring existing code so I don't plan to stop working on HDMI output for now +09:35 < dammsan> sounds fine with me +09:35 < dammsan> we will let you know if some special precaution is needed +09:35 < pinchartl> thank you +09:35 < pinchartl> next, Niklas +09:35 < pinchartl> Since last meeting: +09:35 < pinchartl> - [PATCH v3 0/2] v4l2-async: add subnotifier registration for subdevices +09:35 < pinchartl> - [PATCH v4 0/2] media: entity: add operation to help map DT node to media pad +09:35 < pinchartl> (merged to media-tree) +09:36 < pinchartl> For the next two weeks: +09:36 < pinchartl> - Try to address Hans comments on 'add subnotifier registration for subdevices'. Not sure how do make it work nice with v4l2, Laurent if possible I like to discuss options with you. +09:36 < pinchartl> - Look at the video device life time issues for VIN to for the Gen3 patch set. +09:36 < pinchartl> Issues and Blockers: +09:36 < pinchartl> - Not sire how to make v4l2 +09:36 < pinchartl> I assume s/sire/sure/ +09:36 < pinchartl> but I'm still not sire to understand that comment +09:37 < pinchartl> I suppose that's related to "add subnotifier registration for subdevices" +09:37 < neg> Yes :-) Sorry I'm not sure how to adress Hans comment about v4l2 incremental async, I have an idea but not sure it will work out +09:38 < pinchartl> we can discuss this later today if you're available +09:39 < neg> Plan is to try the idea and if it feels bad talk to you and seek guidance +09:40 < pinchartl> just ping me whenever convenient for you +09:41 < neg> thank you +09:41 < pinchartl> next, Ulrich +09:42 < uli___> so i've probed around the chromebook, and it is not very developer-friendly :) +09:42 < uli___> no uart, no jtag that i could find +09:42 < uli___> but you can reset the usb hub, and the data lines on the usb port change +09:42 < uli___> works reliably, and only requires a single write +09:42 < uli___> and no case opening +09:43 < uli___> also sent a serdev multiplexer prototype, to constructive feedback +09:43 < uli___> i'll incorporate that +09:43 < uli___> that also includes a max9260 i2c driver +09:43 < uli___> which works when talking to the max9260 itself +09:43 < uli___> but i cannot talk to anything behind the gmsl link +09:43 < dammsan> thanks for your efforts +09:43 < uli___> welcome +09:44 < dammsan> i'm interested in reproducing your chromebook modification +09:44 < uli___> you don't actually have to modify anything, that's the good part about it +09:44 < uli___> just hold a probe, or an led, or whatever you have to the usb data line +09:44 < uli___> and watch if the level changes +09:45 < dammsan> i'll see if i can incorporate that into my remote access setup somehow +09:45 < dammsan> together with the key press needed to boot +09:45 < uli___> robot arm? :) +09:45 < dammsan> hehe +09:46 < uli___> anyway, i need you to check if the max9259 are connected/powered properly +09:46 < uli___> because on this side of the link, everything looks fine +09:46 < uli___> all the registers are set up properly etc +09:47 < dammsan> yeah +09:48 < uli___> so that's it for me +09:48 < pinchartl> thank you +09:48 < pinchartl> Topic 2. Additional tasks for Q3/1 +09:48 < dammsan> did you get schematics from public space? +09:48 < pinchartl> We have several candidates for additional tasks in Q3/1, including +09:48 < pinchartl> - Gen3 support rework for media controller +09:48 < pinchartl> - CSI2 virtual channel support +09:48 < pinchartl> - ADV7482 CSI-2 virtual channel configuration +09:48 < pinchartl> - V4L2 .s_stream() pad-aware operation +09:48 < pinchartl> - V4L2 multiplexed stream support (.s_stream(), frame descriptors) +09:48 < pinchartl> - RDACM20 driver upstream +09:48 < pinchartl> - MAX9286 driver upstream +09:48 < pinchartl> it also makes sense to continue with the Blanche-related tasks, and with the Chromebook tasks +09:48 < pinchartl> dammsan: I'd like your feedback on that though +09:49 < pinchartl> please all also feel free to propose other tasks that you believe would be useful +09:49 < dammsan> ok, on exactly what? +09:49 < pinchartl> dammsan: on Blanche & Chromebook +09:49 < dammsan> oh i see +09:49 < pinchartl> I don't know how much time/budget we can spend on that for Q3 +09:49 < dammsan> yeah i guess they are currently blocked on me +09:50 < dammsan> we also may get access to V3H later on +09:50 < dammsan> but not for first batch most likely +09:51 < pinchartl> I want to send a proposal for Q3/1 additional tasks at the beginning of next week at the latest +09:51 < dammsan> uli: shall we try to unblock blanche later today? +09:51 < dammsan> please do, begin with task titles +09:52 < dammsan> so i can clear those with renesas side +09:53 < pinchartl> sounds good to me +09:53 < pinchartl> Topic 3. Next meeting +09:53 < neg> looks like it's my turn next at the hospital queue so I will drop of shortly. Will read backlog and comment on anything I think is interesting :-) Sorry for the scheduling conflict +09:53 < dammsan> i will be in the renesas offie tomorrow and thurday next week +09:54 < dammsan> so if task list updates can happen before that it would make review smooth +09:54 < pinchartl> as we still haven't decided on how to group multiple meetings in a single day, I propose scheduling the next meeting on Wednesday 2017-07-05 as usual +09:54 < pinchartl> and we can reschedule it if we can come to an agreement +09:54 < dammsan> sure +09:54 < pinchartl> dammsan: can I let you drive the meetings schedule discussion, as the request comes from you ? +09:55 < dammsan> sounds good +09:55 < pinchartl> thank you +09:55 < pinchartl> that's it for today +09:55 < jmondi> pinchartl: any update on v4l2 side? +09:56 < pinchartl> jmondi: not yet. I need to discuss it with Hans and Sakari, perhaps tomorrow or on Friday +09:56 < jmondi> and I admit I've not been following the remote setup issues, is 8 channel camera setup available now? +09:56 < jmondi> pinchartl: thanks +09:57 < pinchartl> jmondi: I think it's on port 8010 now +09:57 < pinchartl> dammsan: can you confirm ? +09:57 < dammsan> i have not reinstalled any boards +09:57 < uli___> dammsan: today i'm scheduled already, how about tomorrow? +09:57 < dammsan> uli___: sure, at what time? +09:58 < pinchartl> dammsan: could you reinstall the 8x camera boards too ? +09:58 < uli___> 10cest? +09:58 < uli___> i.e., in exactly 24 hours :) +09:58 < dammsan> uli___: my only appointment is between 16:00 and 17:00 JST +09:58 < jmondi> got "Permission denied (publickey,keyboard-interactive)." on port 8010 +09:59 < dammsan> ok, 17:00 JST it is =) +09:59 < uli___> ok +09:59 < dammsan> jmondi: all gen3 boards have been disconnected +09:59 < dammsan> i'll begin by installing some H3 boards =) +10:00 < dammsan> then 8 x camera tomorrow if i can escape from the renesas office at some point =) +10:00 < pinchartl> I propose adjourning the meeting, does anyone second ? +10:00 < dammsan> sounds good +10:01 < dammsan> cya later guys +10:01 < pinchartl> meeting adjourned +10:01 < pinchartl> thank you all for attending, and have a nice day diff --git a/wiki/Chat_log/20170706-core-chatlog b/wiki/Chat_log/20170706-core-chatlog new file mode 100644 index 0000000..5dd3dda --- /dev/null +++ b/wiki/Chat_log/20170706-core-chatlog @@ -0,0 +1,336 @@ +Core-chat-meeting-2017-07-06 + +Before Lunch/Dinner + +10:52 < geertu> Welcome to today's Core Group Chat! +10:52 < geertu> Let's start with the status updates +10:53 < geertu> Just like with MultiMedia, feel free to ask questions if there's anything you find unclear, but please keep the questions limited to task status reporting and planning +10:54 < geertu> First is Jacopo +10:54 < jmondi> here I am +10:54 < jmondi> very few core work from my side lately +10:54 < jmondi> A) +10:55 < jmondi> - RZ pinctrl finally part of v4.13 pull request +10:55 < geertu> Yeah! +10:55 < wsa_> cool +10:55 < jmondi> finally, yes :) +10:55 < jmondi> B) +10:55 < jmondi> add to GR-Peach pinctrl nodes +10:56 < jmondi> ping Simon for deferred patches for genmai's dts +10:56 < jmondi> C) +10:56 -!- horms [~horms@softbank126083087124.bbtec.net] has joined #periperi +10:56 < jmondi> none strictly for core +10:56 < jmondi> --eot-- +10:57 < geertu> Thank you, Jacopo +10:57 < geertu> Next one is Simon +10:57 < horms> Hi, sorry about my poor connection today +10:57 < horms> I have no updaes for the core group as I have no tasks at this time. Geert asked me to look into CPUFreq next quarter and I intend to make a start on that too. +10:57 < horms> s/too/soon/ +10:58 < geertu> Thank you, Simon +10:58 < geertu> Next is Niklas +11:00 < neg> A) +11:00 < neg> - Not much, I tested some of Geerts clock suspend/resume patches +11:00 < neg> together with RAVB WoL and it works. +11:00 < neg> B) +11:00 < neg> - Not much, if stuff is blocked in Multimedia land I will work with +11:00 < neg> core tasks. Either on my proposed additional task of emergency +11:00 < neg> shutdown or starting to execute the plan to improve dmaengine for +11:00 < neg> rcar-dmac test case (see [periperi] test for races in rcar-dmac). +11:00 < neg> C) +11:00 < neg> - Not sure if I should repost my RAVB WoL patch with a work around for +11:00 < neg> the clock or wait untill Geerts suspend/resume work for clocks is +11:00 < neg> picked up. I know I asked this before but I have lagged in posting +11:00 < neg> the driver with the workaround and since then Geerts patches have +11:00 < neg> made progress. +11:00 < neg> --EOT-- +11:01 < geertu> Regarding C, I still think having a workaround for now would allow it to make progress. +11:01 < geertu> Independent of clock fixes. +11:01 < neg> OK then I will include the fix and repost once I also tested it on the new board I recived the other day +11:02 < geertu> Without it, the RAVB WoL support can only enter one cycle after the clock fixes, which would be v4.15 at earliest +11:02 < geertu> Thanks, Niklas! +11:02 < geertu> Next is Laurent +11:04 < pinchartl> nothing on my side +11:04 < pinchartl> although I've been pinged by Rob Clark +11:04 < pinchartl> who wanted to know if we could exchange review on IOMMU drivers +11:04 < pinchartl> he has a patch series he needs to get reviewed, and we have IPMMU patches +11:04 < pinchartl> but I won't have time for that +11:05 < geertu> This is for non-Renesas hardware? +11:07 < pinchartl> yes +11:08 < pinchartl> that's the idea behind trading reviews :-) +11:08 < geertu> Sure +11:08 < geertu> If you don't have time, perhaps Magnus can review them? +11:08 < dammsan> sure +11:08 < dammsan> i also need to review some code from laurent, but adding it to the list is good +11:09 < geertu> OK. +11:09 < geertu> Thanks Laurent! +11:09 < geertu> Next is Geert +11:09 < geertu> A) What have I done since last time +11:09 < geertu> - Second RFC for CPG/MSSR module clock restore during resume +11:09 < geertu> - Fixed SMP on R-Car E2 +11:09 < geertu> - Started missing DT descriptions for R-Car Gen2 +11:09 < geertu> - Additional task preparations +11:10 < geertu> B) What I plan to do till next time +11:10 < geertu> - Continue missing DT descriptions for R-Car Gen2 +11:10 < geertu> - Suspend/resume for PFC +11:10 < geertu> - CPG/MSSR for R-Car D3 +11:10 < geertu> - Mark periupport priority < H commits that are in linux-next +11:10 < geertu> C) Problems I have currently +11:10 < geertu> - Proper R-Car Gen2 Generic Counter init may need a bootloader shim +11:11 < dammsan> shall we discuss that topic later? +11:11 < geertu> --EOT-- +11:11 < geertu> Sure. +11:11 < geertu> Next is Shimoda-san +11:11 < shimoda> A) +11:11 < shimoda> - Make USB2.0 clock selector driver as a CCF driver. +11:11 < shimoda> B) +11:11 < shimoda> - Continue to improve USB2.0 clock selector driver because it got some feedback from community. +11:11 < shimoda> - Need reply about R-Car D3's CPG things to Geert-san +11:11 < shimoda> C) +11:11 < shimoda> - Nothing +11:11 < shimoda> -- EOT -- +11:12 < geertu> Thanks, Shimoda-san! +11:12 < geertu> Next is Morimoto-san +11:12 < morimoto> A) = B) = C) = NULL, sir +11:12 < morimoto> --EOT-- +11:13 < geertu> Thank you, Morimoto-san! +11:13 < geertu> Next is Marek +11:13 < marex-cloud> A) continue on DT conversion of U-Boot, SH SDHI is converted to DM and probes from DT +11:13 < marex-cloud> B) NULL +11:13 < marex-cloud> C) MFD maintainer is difficult and blocks the Rohm PMIC patches for no good reason +11:13 < marex-cloud> Question: Is SH SDHI a Renesas/Hitachi block or is that bought from somewhere, ev. where ? I recently found during my plumbing in the U-Boot SDHI driver that Socionext Uniphier has the same block in it ... +11:14 < geertu> You also posted VC6 patches, right? +11:14 < marex-cloud> geertu: that's core or IO again ? +11:14 < geertu> clocks are core +11:14 < marex-cloud> U-Boot now has two drivers -- SH SDHI and Uniphier SD -- for the same block, we need to fix this +11:14 < dammsan> it is matsushita IP i think +11:14 < marex-cloud> also, I'm in touch with Socionext acquitance and he was about to send uniphier SD driver for linux, yet we already have SH MMCIF driver for the same block +11:15 < marex-cloud> dammsan: ah ... +11:15 < geertu> drivers/mmc/host/tmio_mmc.c says Toshiba? +11:15 < geertu> Linux:drivers/mmc/host/tmio_mmc.c says Toshiba? +11:15 < dammsan> it was reverse engineered from toshia +11:15 < wsa_> the oldest datasheet i have is also from toshiba +11:15 * marex-cloud rolls eyes ... +11:16 < geertu> Regarding C, kbingham will meet Lee on Monday? Should we discuss this later today? +11:16 < marex-cloud> geertu: but what's sh_mmcif.c about ? +11:16 < marex-cloud> geertu: gladly +11:16 < wsa_> wait, mmcif is something else +11:17 < geertu> Too many Renesas ancestors... (Toshiba and Matsushita even aren't) +11:17 < wsa_> Gen2 had SDHI for SD and MMCIF for MMC (simply spoken) +11:17 < marex-cloud> http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/uniphier-sd.c;h=3c462bd5835e9e4efae745791fdaaff80a4c2af5;hb=HEAD +11:17 < marex-cloud> here is a better register description ^ +11:17 < wsa_> Gen3 has only SDHI which gained MMC support +11:18 < geertu> Isn't this I/O? :-) (oh, U-Boot is core) +11:18 < kbingham> marex-cloud: geertu: If C) is causing problems I can see if I can help somewhere yes. Can someone send me a patch reference / ML links please ? +11:19 < marex-cloud> kbingham: https://patchwork.kernel.org/patch/9707899/ +11:19 < marex-cloud> wsa_: I only have Gen3 , so I'm talking about SDHI +11:20 < jmondi> I need to be away for ~15 mins... If IO report starts and I'm named, I may reply a bit late (No IO updates btw).. sorry about this +11:20 < marex-cloud> wsa_: which looks like the same block that's in Uniphier ... see above +11:20 < geertu> Let's continue with core... +11:20 < geertu> Thank Marek! +11:20 < geertu> Next is Magnus +11:20 < marex-cloud> geertu: so uh, I'd like to know which block it is ^_^' +11:20 < marex-cloud> we can do that later +11:21 < dammsan> [1;5Dno special update from me thanks +11:22 < geertu> Thank you, Magnus! +11:22 < geertu> Next is Ulrich +11:22 < uli___> nothing to report here +11:22 < dammsan> regarding SDHI, search for mn5774 for perhaps related panasonic IP +11:22 < marex-cloud> [11:22:28] <Masahiro Yamada> I asked some hardware engineers. Looks like Panasonic/Matsushita IP. +11:22 < geertu> Thank you, Uli! +11:22 < marex-cloud> dammsan: thank you +11:23 < geertu> So far for status reporting from the regular core members. +11:23 < marex-cloud> dammsan: might be worth adding that piece of trivia to the driver / DT +11:23 < geertu> Anything core-related from Wolfram or Kieran? +11:24 < wsa_> nope +11:24 < kbingham> geertu: I've ordered a new BusBlaster +11:24 < kbingham> I can't get my existing one working with OpenOCD (its an IMG varient ... ugh ) +11:24 < wsa_> marex-cloud: the register description in the link above is definately SDHI +11:24 < geertu> v4? +11:25 < kbingham> geertu: Actually I've ordered the v3 ... for better compatibility - With a desire that I should hope to see how to get JTAG connected at somepoint using OpenOCD. +11:25 < kbingham> But it's a desire rather than a task at present. +11:25 < marex-cloud> wsa_: roger +11:25 < geertu> OK. Then I think we can continue with I/O? +11:26 < geertu> wsa_: The mic is yours +11:26 < wsa_> oh, one question: any estimate for SDHI PFC settings for Salvator-XS? +11:26 < dammsan> geertu: if no further update is needed for additional tasks then i will submit, is that ok? +11:27 < geertu> wsa_: PFC for I/O devices is typically handled by the person doing the I/O device. Use BSP as a reference. +11:27 < wsa_> geertu: i see. ok, thanks +11:27 < geertu> dammsan: Fine for me (I had no feedback from Niklas and Simon?). +11:27 < dammsan> good, thanks +11:28 < neg> geertu: I'm sorry my mail that stated I was happy with the draft is stuck in my draft folder for som reasnon. Sorry about that +11:28 < geertu> neg: No problem, as long as it was a happy response ;) + +After Lunch/Dinner + +14:09 < geertu> dammsan: I take it you're the expert on early (boot-time wise) R-Car Gen2 hacks? +14:10 < dammsan> yes i believe so +14:10 < geertu> Or not, from the lack of comments on my patches? ;-) +14:10 < dammsan> hehe, i am ducking too much +14:11 < dammsan> you were talking about arch timer? +14:11 < geertu> and generic counter +14:11 < dammsan> i have little knowledge about the latter +14:11 < dammsan> did it use a different name earlier? +14:12 < dammsan> there is global timer too +14:12 < geertu> not AFAIK +14:12 < dammsan> i recall +14:12 < dammsan> what is it? +14:12 < jmondi> I'm bothering neg in private now, if my point on device tree shuffling was the only one to discuss about this afternoon +14:12 < dammsan> some sort of timer i guess? per-cpu? +14:13 < geertu> I think it's the real counter behind the arch timer +14:14 < geertu> It has the CNTFID0 and CNTCR register, being accessed in rcar_gen2_timer_init() +14:14 < dammsan> ok i see. different from arch timer and twd +14:14 < geertu> If it doesn't run, arch timer also doesn't work +14:14 < dammsan> i see +14:14 < dammsan> i guess that code was developed without global timer in mind +14:15 < dammsan> focus on arch timer instead +14:15 < geertu> unlike arch timer it's memory mapped +14:15 < geertu> using a hardcoded address +14:16 < geertu> The good news is that Mark Rutland doesn't want it to have DT bindings, nor to appear in DT +14:16 < geertu> ;-) +14:16 < dammsan> ok, but how is that different from say GIC +14:16 < geertu> However, according to him it should be handled in the boot loader/firmware +14:16 < dammsan> it is not preset at base_addr + offset? +14:16 < geertu> or a bootloader shim +14:17 < dammsan> is it available on single code cortex-a9? +14:17 < dammsan> s/code/core/g +14:17 < geertu> /* Remap "armgcnt address map" space */ +14:17 < geertu> base = ioremap(0xe6080000, PAGE_SIZE); +14:18 < geertu> I don't know. Perhaps not. We only need to play with it on Gen2, i.e. A15/A7 +14:18 < dammsan> ok, however the upstream global timer driver mentions cortex-a9 +14:18 < dammsan> so we may be able to use it on rz/a1 +14:18 < dammsan> but anyway +14:19 < geertu> It's not global timer, but generic counter' +14:19 < dammsan> i think that 0xe6080000 is base address + 0x80000 +14:19 < dammsan> where base happens to be 0xe6000000 on r-car gen2 +14:20 < dammsan> probably matches gic and other arm peripherals +14:20 < dammsan> i may be wrong +14:20 < dammsan> but usually there is a single base address for the arm stuff +14:20 < geertu> GIC is @f1001000 +14:20 < dammsan> hm +14:20 < dammsan> arch timer same? +14:20 < geertu> See R-Car Gen2 Section 9.2 +14:21 < geertu> No, arch timer uses mrc/cr asm, not mmio +14:21 < geertu> It refers to DDI0406C2c_arm_architecture_reference_manual Appendix D.3 Counter module control and status registers. +14:21 < geertu> but it's App. D.5 in later revisions of that document +14:21 < dammsan> right, and we are not using twd on those more recent 32-bit socs +14:22 < geertu> BTW, it's also mentioned in the Gen3 docs +14:22 < geertu> Both say: Set bit 0 in CNTCR to 1 to start the Generic Counter when the CPU is placed in the secure mode. +14:23 < geertu> which is not done on Gen2 boards. +14:23 < dammsan> interesting +14:24 < dammsan> i recall that one of the timer workarounds were related to undocumented clock frequency dividing based on the MD pins +14:24 < dammsan> maybe that is different than the issue you are mentioning +14:24 < geertu> Yes, the frequency depends on the crystal (H2/M2) or ZS clock (V2H/E2), which is somehow related to MD settings (set MD according to crystal) +14:25 < geertu> U-boot inits it on iMX in arch/arm/imx-common/syscounter.c +14:25 < geertu> We can fix U-Boot, but I guess we needs backwards-compatibility with whatever is in use +14:27 < dammsan> i think we want to avoid breaking stuff +14:27 < geertu> Indeed. +14:28 < geertu> So either we keep the existing code, or move it to a "bootloader shim" +14:28 < geertu> As it doesn't involve DT, I think the easiest is to keep the existing code ;-) +14:28 < dammsan> i recall that some data sheet mentioned that the arch timer was supposed to run on say 13MHz fixed but in reality the MD pin setting divided it in two or so +14:29 < geertu> Yes, the register is programmed for 13 MHz, while reality is 10 or 32.5 MHz +14:29 < geertu> Aha, u-boot:include/configs/salvator-x.h:#define COUNTER_FREQUENCY 0xFE502A /* 16.66MHz from CPclk */ +14:29 < dammsan> ok that makes sense +14:29 < geertu> The current code probably breaks virtualization +14:30 < dammsan> i guess developing a parallel workaround in that "bootloader shim" doesnt hurt +14:30 < dammsan> especially if it can run in parallel with the existing code +14:30 < dammsan> then we can phase out the in-kernel workaround over time +14:30 < dammsan> also fixing u-boot makes sense +14:31 < geertu> Any examples of "bootloader shim" out there? +14:31 < dammsan> not sure myself +14:31 < dammsan> i don't even know what it is +14:33 < dammsan> my feeling is that this kind of workaround should be in the CPG or MD-pin code +14:33 < geertu> AFAIK it's something that runs after the bootloader, and before Linux +14:33 < dammsan> under compressed/? +14:33 < dammsan> but it is possible to boot vmlinux too, right? +14:34 < geertu> I think even separate from the kernel +14:34 < dammsan> hm, i'm not too fond of throwing stuff over the fence and breaking things just for the sake of cleanups +14:35 < geertu> me neither +14:35 < dammsan> also we used to boot linux directly from the reset vector +14:35 < dammsan> this disappeared with the multi-arch migration +14:36 < geertu> Documentation/arm64/booting.txt has requirements for the state before entering Linux +14:36 < geertu> - Architected timers +14:36 < geertu> CNTFRQ must be programmed with the timer frequency and CNTVOFF must +14:36 < geertu> be programmed with a consistent value on all CPUs. If entering the +14:36 < geertu> kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) set where +14:36 < geertu> available. +14:36 < dammsan> but if we could have a board-specific compressed header then that would be fine +14:36 < dammsan> it does not say "correct frequency" =) +14:37 < dammsan> even if i would have preferred that +14:37 < dammsan> and this is on 32-bit linux, right? +14:37 < geertu> Yes +14:37 < geertu> 32-bit +14:38 < dammsan> having a well documented state of boot is not a bad thing though +14:38 -!- horms [~horms@2001:470:fe2c:302::1000] has joined #periperi +14:38 < dammsan> but i doubt that existed on 32-bit arm? +14:39 < dammsan> we could argue that we want to boot RZ/A1 directly into linux +14:39 < dammsan> and because of that need to perform various setup early on +14:39 < dammsan> of course it can be argued that the code should be somewhere else +14:40 < dammsan> i guess it is up to the maintainers in the end +14:40 < geertu> RZ/A1? +14:40 < horms> coming in late here, but we could revive the early-boot linux work that magnus and I did some years ago to strengthen our hand if it makes sense +14:40 < geertu> This is al about R-Car Gen2 and RZ/G1 +14:40 < dammsan> that is also 32-bit cortex-a9 +14:41 < dammsan> yeah i understand, just thought it may be useful on cortex-a9 too, but perhaps that was the global timer instead +14:41 < dammsan> horms: yeah something like that may make sense +14:42 < dammsan> it is not so easy to go against the desire of the arm guys though +14:43 < dammsan> for the timers i would have preferred to use CCF and then MD pin detection for the clock frequency workaround +14:43 < geertu> dammsan: All of that runs way too late, I think +14:43 < dammsan> but instead a static DT property was preferred, or preprogrammed value +14:43 < dammsan> that might be so +14:43 < geertu> The arch timer frequency can be put in DT. That also works. +14:43 < geertu> However, it's deprecated, and breaks virtualization +14:44 < dammsan> doesn't it also create mismatch if the MD pin setting is different from DT? +14:44 < dammsan> so it seems dynamic to me +14:44 < geertu> dammsan: Yes, but if you change MD, you should change the crystal, too +14:45 < dammsan> so the existing code is working around an incorrect setup? +14:45 < geertu> But we stopped using MD to derive the arch timer frequency a long time ago. These days we look at the extal clock-frequency in DT +14:46 < geertu> On V2H/E2, the value is hardcoded. It's ZS/8, but ZS must be fixed at 260 MHz anyway (unless you e.g. change the crystal without updating MD, but that's out-of-spec) +14:47 < dammsan> hm... +14:47 < dammsan> so there is no divider in the hardware? +14:48 < geertu> Somewhere there is, but it's not programmable: arch timer freq is either extal/2, or zs/8 +14:48 < dammsan> and that selection is done run-time, or via static DT configuration? +14:49 < dammsan> sorry for being a bit unclear =) +14:50 < dammsan> just wondering if we could solve multiple issues by assuming the clock to be more dynamic +14:51 < geertu> dammsan: based on SoC compatible (H2/M2 use extal/2, V2H/E2 use ZS/8) +14:51 < dammsan> ok that makes sense +14:51 < dammsan> thanks! +14:52 < dammsan> so what to do? =) +14:53 < geertu> I'll have a look to see if the shim is doable +14:54 < dammsan> is this the only workaround that is left for 32-bit arm? +14:54 < dammsan> for our socs i mean? +14:54 < dammsan> if we could move multiple things to that shim then that would be nice +14:54 < geertu> The other one is the CNTVOFF thingy +14:55 < geertu> We currently do that on the boot CPU of CA7 systems only. +14:55 < geertu> E2 needs it on all CPU cores. +14:56 < shimoda> oops, i kept to join this, but i worked other things :) i go home now, byebye! +14:56 -!- shimoda [~shimoda@relprex3.renesas.com] has quit [Quit: WeeChat 0.4.2] +14:56 < dammsan> i see +14:56 < geertu> No idea if shims can easily run on all CPUs. Probably not, as it involves actually booting them. +14:56 < geertu> However, Marc Zyngier doesn't seem to be opposed to doing it in the kernel. +14:57 < dammsan> the tricky part is that the secondary cpu cores come up from reset +14:57 < dammsan> so we need to setup stuff for those anyway +14:57 < geertu> He did say we also need it on CA15, as A15/A7 are very similar, and that it's sheer luck it worked for us. +14:57 < dammsan> yes that is inline with what i've seen +14:57 < dammsan> the power-on-reset value happened to be correct on CA15 +14:58 < dammsan> or at least not wrong +14:58 < dammsan> or correct enough to boot =) +14:58 < geertu> Always doing these few asm instructions when a CPU core boot won't delay it too much... +14:59 < dammsan> thats right +14:59 < dammsan> there are also cache workarounds needed for secondary cpus +14:59 < geertu> BTW, how can you boot from CA7 on (remote) lager? +14:59 < geertu> The cache workarounds may be handled by generic code +14:59 < dammsan> maybe these days +15:00 < dammsan> they used to be local code in some bsp +15:00 < dammsan> eventually made it into upstream and then got consolidated i think +15:00 < dammsan> would you like to boot CA7 on lager? +15:00 < geertu> So if we don't have to describe the gneric counter in DT, the only piece missing is ICRAM for SMP bringup (patches sent) +15:01 < dammsan> only piece missing for what? +15:02 < geertu> Having everything described in DT, so we can boot without relying on any hardcoded address in the kernel +15:02 < dammsan> ok i see +15:02 < dammsan> sounds good to me! +15:02 < geertu> I want to have a single flag day for all of that for Gen2 (incl. CPG/MSSR, SYSC, RST), so we can drop all workaround code at once. +15:03 < dammsan> i guess this is part of dropping the code in the mach-shmobile directory? +15:03 < geertu> We have two more places that use hardcoded addresses, but the devices are described in DT, so they need kernel code changes only: +15:04 < geertu> Gen2,?,noplan,?,Use IRQC in DT for da9063/da9210 regulator quirk +15:04 < geertu> Gen2,?,noplan,?,Use RST in DT for secondary CPU bringup +15:04 < geertu> Dropping it completely is not so easy. +15:04 < geertu> Not relying on hardcoded addresses is my goal. diff --git a/wiki/Chat_log/20170706-io-chatlog b/wiki/Chat_log/20170706-io-chatlog new file mode 100644 index 0000000..81e371c --- /dev/null +++ b/wiki/Chat_log/20170706-io-chatlog @@ -0,0 +1,119 @@ +11:25 < geertu> OK. Then I think we can continue with I/O? +11:26 < geertu> wsa_: The mic is yours +11:26 < wsa_> oh, one question: any estimate for SDHI PFC settings for Salvator-XS? +11:26 < dammsan> geertu: if no further update is needed for additional tasks then i will submit, is that ok? +11:27 < geertu> wsa_: PFC for I/O devices is typically handled by the person doing the I/O device. Use BSP as a reference. +11:27 < wsa_> geertu: i see. ok, thanks +11:27 < geertu> dammsan: Fine for me (I had no feedback from Niklas and Simon?). +11:27 < dammsan> good, thanks +11:28 < neg> geertu: I'm sorry my mail that stated I was happy with the draft is stuck in my draft folder for som reasnon. Sorry about that +11:28 < geertu> neg: No problem, as long as it was a happy response ;) +11:28 < wsa_> so, welcome to the io meeting +11:28 < neg> geertu: :-) +11:29 < wsa_> geertu: you won the sort -R game ;) +11:30 < geertu> A/C: None +11:30 < geertu> B: Enable/test MSIOF on Salvator-XS with R-Car H3 ES2.0 +11:30 < geertu> ---EOT--- +11:31 < wsa_> thanks. looking forward to see the outcome of b) +11:31 < wsa_> uli___: you are next +11:31 < uli___> 50% of the report for multimedia applies here :) (max9260 i2c host and serdev multiplexing) +11:32 < uli___> nothing beyond that +11:32 < wsa_> yup, nice to see that the mux subsystem was nice to use. Peter will be happy about another user :) +11:33 < uli___> conveniently, it already contains a gpio implementation +11:33 < wsa_> :) +11:34 < wsa_> I am next +11:34 < wsa_> A) * took part in both MAX9260 & MAX9286 review +11:34 < wsa_> * reviewed SDHI cleanup & DMA patches +11:34 < wsa_> * researched SCCB compatibility & patched i2c-gpio for it +11:34 < wsa_> * rebased and resend SDHI CBSY patch +11:34 < wsa_> * upported correct SDHI SD_BUF handling +11:34 < wsa_> * sent a patch for correct SDHI CMD12 handling +11:34 < wsa_> * additional task preparations +11:34 < wsa_> B) +11:34 < wsa_> * respin I2C core DMA patches +11:34 < wsa_> * upport some watchdog patches +11:34 < wsa_> * investigate some more SDHI patches for upporting +11:34 < wsa_> * create additional tasks +11:34 < wsa_> C) +11:34 < wsa_> * Gen3 SDHI DMA upstreaming issues +11:34 < wsa_> so, i took a closer look at the SDHI patches from the upport list and tried to recreate the issues +11:35 < wsa_> but we need to talk about the SDHI Gen3 DMA upstreaming +11:35 < horms> do you see any BSP patches that may address outstanding issues? +11:36 < wsa_> DMA wise or in general? +11:36 < horms> I am assuming one is the tuning issue that Geert reported (or maybe my memory fails me completely) +11:36 < horms> I meant in general. +11:36 < horms> I think the BSP does not address our DMA problems +11:36 < wsa_> yes, there are patches related to tuning, but it is hard to test them +11:36 < horms> understood. that does not surprise me at all +11:37 < horms> We can talk about DMA seprately, right? +11:37 < wsa_> and some I marked "unclear until we get new docs" which we now got! +11:37 < wsa_> so, thank you for the new documentation! +11:38 < horms> thanks for the update, no more comments from me for now +11:38 < wsa_> and i still have this one card which has re-tuning issues. But currently not clear if it is the same issues Geert sees on ALT +11:39 < geertu> wsa_: it's the ALT in Magnus' farm +11:39 < wsa_> ok +11:39 < wsa_> dammsan: requesting access to that one +11:40 < horms> I also have an Alt if that turns out to be useful, though its also in Japan +11:40 < dammsan> wsa_: done +11:41 < wsa_> dammsan: do you prefer to discuss the Gen3 DMA further by mail or by IRC? +11:41 < wsa_> we started by mail but seems we got interrupted +11:42 < wsa_> dammsan: thanks! +11:42 < dammsan> irc may be better +11:43 < wsa_> can i propose that you, simon, and me keep discussing after the meeting. My availability this afternoon is unclear right now +11:43 < wsa_> right after the meeting, i meant +11:44 < dammsan> thats fine with me +11:45 < horms> I need to be afk for about 2h as of about 1.25h from now. I can, however, re-arange that if really needed. +11:45 < wsa_> i hope we will have settled before that :) +11:45 < wsa_> ok, let's continue +11:45 < wsa_> niklas, please +11:46 < wsa_> or neg (to activate notifications) +11:46 < neg> A) +11:46 < neg> - No IO work. +11:46 < neg> - No IO work planed, other then if there is any overlap while working on the thermal driver. +11:46 < neg> B) +11:46 < neg> - None +11:46 < neg> C) +11:46 < neg> - None +11:46 < neg> --EOT-- +11:46 < wsa_> yep, "emergency shutdown" was kinda moved to core +11:47 < wsa_> thanks! +11:47 < neg> ops cut and paste failed.. but I'm sure you figured it out :-) +11:47 < wsa_> now shimoda-san, please +11:47 < shimoda> < I/O > +11:47 < shimoda> A) +11:47 < shimoda> - Debug USB3.0 peripheral driver because BSP team reports some bugs. +11:48 < shimoda> B) +11:48 < shimoda> - Continue to debug the USB3.0 peripheral driver. +11:48 < shimoda> C) +11:48 < shimoda> - Nothing +11:48 < shimoda> -- EOT -- +11:49 < wsa_> Thank you and good luck with debugging! :) +11:49 < shimoda> yes :) +11:49 < wsa_> simon, your turn +11:49 < horms> A) What have I done since last time: +11:49 < horms> - SDHI cleanups accepted +11:49 < horms> - Posted SDHI R-Car Gen3 internal DMAC patches v2 + v3 +11:49 < horms> B) What I plan to do till next time: +11:49 < horms> - TBD +11:49 < horms> C) Problems I have currently: +11:49 < horms> - Need a plan to handle/not handle SDHI with multiple DMAC implementations +11:49 < horms> D) Posted/Accepted bugfix patches: +11:49 < horms> - None +11:49 < horms> io/todo: +11:49 < horms> - No change +11:50 < horms> I don't think there are any surprises for you in the above +11:50 < horms> -- eot -- +11:50 < wsa_> in deed, no surprise ;) +11:51 < wsa_> morimoto-san, any surprises? +11:51 < morimoto> A) = B) = C) = NULL, sir. no surprise ;) +11:51 < morimoto> +11:51 < wsa_> :D +11:51 < wsa_> jmondi: you there? +11:51 < wsa_> but he already said he had no updates +11:51 < jmondi> wsa_: yep +11:51 < jmondi> but no updates for IO +11:52 < wsa_> ok, thank you all! +11:52 < wsa_> not much updates, which is no surprise again, since most tasks are usually handled by additional tasks +11:52 < wsa_> which we don't have this month. +11:53 < wsa_> so, last chance for questions now +11:53 < wsa_> otherwise I think we are done diff --git a/wiki/Chat_log/20170706-mm-chatlog b/wiki/Chat_log/20170706-mm-chatlog new file mode 100644 index 0000000..217a7bc --- /dev/null +++ b/wiki/Chat_log/20170706-mm-chatlog @@ -0,0 +1,189 @@ +Multimedia-chat-meeting-2017-07-06 + +10:04 < pinchartl> Wolfram proposed in an e-mail yesterday to start with multimedia +10:04 < pinchartl> if everybody is fine with that, I'll proceed +10:04 < pinchartl> wsa_: geertu: is that OK ? +10:05 < wsa_> ok +10:05 < geertu> pinchartl: OK +10:05 < pinchartl> let's begin +10:05 < pinchartl> and try to keep it short +10:06 < pinchartl> just as a reminder, we'll start with task status reporting only +10:06 < pinchartl> feel free to ask questions if there's anything you find unclear +10:06 < pinchartl> but please keep the questions limited to task status reporting and planning +10:07 < pinchartl> you can also bring up other topics, which I will then record, but we'll discuss them in the afternoon +10:08 < pinchartl> uli___: I think you were the last to report over e-mail, so you can start +10:08 < uli___> ok +10:08 < uli___> so we found the issue with the silent max9260s, it was an incorrect setup on the blanche board +10:08 < uli___> we can talk to all max9260 now, and the one max9259 that is connected +10:09 < uli___> (there is only one cable) +10:09 < uli___> i have retooled the serdev gpio multiplexing to use the new multiplexer subsystem +10:09 < pinchartl> nice +10:09 < uli___> pleasantly simple, but as yet untested. rsn... +10:10 < uli___> that's it, really +10:10 < uli___> i'll fix this up once it works and send out a new rfc +10:10 < pinchartl> thank you +10:10 < pinchartl> neg: you're next to report from the beach +10:11 < neg> Shorter IRC friendly version. longer one in status update mail, plase us it for the report :-) +10:11 < neg> A) +10:11 < neg> - Reworked VIN Gen3 DT parsing do deal with not registering the video +10:11 < neg> device at probe time but instead in the async complete callback(). +10:11 < neg> - Got feedback from Laurent that my idea for incremental async using +10:11 < neg> subnotifers was not his favorite way to solve this problem, Laurent +10:12 < neg> also provided feedback on how he thinks is the best way to implement it. +10:12 < neg> - Discussed an issue with Kieran about format size reporting in a +10:12 < neg> media graph pipeline. The issue is for sources providing streams +10:12 < neg> using the field type TOP, BOTTOM or more common ALTERNATE. Which +10:12 < neg> format size should they report? +10:12 < neg> - I'm not working from Stockholm this week but my "secretary" received +10:12 < neg> a packages from OpenSörce / Renesas yesterday which I'm hoping is +10:12 < neg> the new Gen3 board and/or the 8-channel camera setup. +10:12 < neg> B) +10:12 < neg> - Get a working prototype out the door to replace subnotfiers for +10:12 < neg> incremental async. +10:12 < neg> - Pickup Kierans ADV7482 DT patches and include them together with +10:12 < neg> other VIN+CSI-2 DT changes in my for-renesas-drivers branch. +10:12 < neg> - Hope fully resolve the format size reporting discussions and if +10:12 < neg> after that there is nothing more I want to solve in my VIN Gen3 +10:12 < neg> branch post it to ML :-) +10:12 < neg> - Inspect package with new boards and bring them in to my lab and if +10:12 < neg> it contains a new Gen3 board test how VIN works on it and report to ML. +10:12 < neg> C) +10:12 < neg> - None +10:12 < neg> Patches of interest) +10:12 < neg> - [PATCH 0/2] media: v4l: Add support for the Cadence MIPI-CSI2RX +10:12 < neg> --EOT-- +10:13 < pinchartl> thank you +10:13 < pinchartl> regarding formats, is that subdev formats ? +10:13 < kbingham> Yes - The subdev format of the ADV748x when using interlaced +10:14 < kbingham> I believe the subdev should report field height (frame_height/2) +10:14 < neg> for me it's about all formats wich can be read from the media graph +10:14 < pinchartl> yes, the height should be halved in that case +10:15 < pinchartl> if the V4L2 documentation isn't clear on this topic, patches are welcome :-) +10:15 < neg> and the SD should report field height and not frame height for ALTERNATE, TOP and BOTTOM formats? +10:15 < kbingham> pinchartl: There is a patch posted on this topic - but I do'nt think it's been integrated yet :) +10:15 < pinchartl> neg: correct +10:16 < neg> and then VIN needs to doubble the height if it uses the HW to interlace the fields before writing it to memory +10:16 < pinchartl> neg: correct as well +10:17 < pinchartl> thank you for reporting patches of interest +10:17 < pinchartl> please all try to keep this in mind +10:17 < neg> OK kbingham thanks for finding the documentaion patch +10:17 < pinchartl> I have that patch series in my inbox, Maxime CC'ed me to get it reviewed -_-' +10:17 < pinchartl> next, kbingham +10:17 < kbingham> ADV748x: version 6 is posted publicly, and comments from Hans have been addressed to create a v7. +10:17 < kbingham> I hope that this should be acceptable for integration now. The DT patch is being upstreamed though Niklas' work due to inherrent dependancies there. +10:18 < kbingham> The vblank issue is under investigation and prototype patch is posted but a couple of issues to be resolved. Laurent you mentioned you were going to look at this - but did you have time? +10:18 < kbingham> I also anticipate moving to ES2 hardware this week - A board should arrive this week. +10:18 < pinchartl> the board should hopefully arrive today :-) +10:19 < kbingham> And meanwhile I am looking at display list work - although I don't think this is a formal additional task yet :) +10:19 < kbingham> -- eot -- +10:20 < pinchartl> regarding the vblank issue, I haven't had time yet (beside fixing the small vblank interrupt issue we discussed yesterday) +10:20 < pinchartl> I can continue, if you prefer taking over, I'm fine with that too, but I remember you had issues reproducing the problem +10:20 < pinchartl> so I propose continuing on my side at least for today +10:20 < kbingham> That sounds good. +10:21 < kbingham> I think the reproduction of the issue was more clear when shutting down kmstest/cube with ctrl-c +10:21 < pinchartl> ok +10:21 < pinchartl> next, jmondi +10:22 < jmondi> ok! +10:22 < jmondi> A) +10:22 < jmondi> - Sent mx9286 cleanup patches (v1 and v2) +10:22 < jmondi> - Rebased max9286 patches (my series and Laurent's one) on top of Niklas VIN patches v10 +10:23 < jmondi> - Implemented skeleton for max9286 subdevice +10:23 < jmondi> - Found out what chip actually is the one I was using to test VIN parallel input +10:23 < jmondi> B) +10:24 < jmondi> - Complete rebase and have capture with a single channel working again +10:24 < jmondi> - Register max9286 subdevice and define DTS layout +10:24 < jmondi> C) +10:25 < jmondi> - Niklas' v10 VIN patch series is based on v4.12: massive DTS re-shuffling and also device tree parsing logic has changed. I now have links in the media controller graph not working +10:25 < jmondi> ^ this can be a topic for afternoon discussions, as I'm not sure what is the best way to re-enable and link VIN nodes with new dts layout +10:25 < jmondi> --eot-- +10:26 < pinchartl> thank you +10:26 < pinchartl> the sensor you have identified is an MT9V111, right ? +10:26 < jmondi> yes +10:26 < jmondi> not mt9m111 as I thought it was :/ +10:26 < pinchartl> and that's not supported upstream :-/ +10:26 < jmondi> nope +10:27 < pinchartl> we'll have to decide how to handle that, as there's a significant amount of work needed to support it +10:27 < dammsan> i'm glad we used migo-r instead of that sensor =) +10:27 < pinchartl> I don't think it's a priority +10:28 < pinchartl> dammsan: to test parallel VIN input ? :-) +10:28 < jmondi> I guess so, you pointed me to another driver for a "similar" chip, but for what I've seen, there's plenty of work to do anyway +10:28 < jmondi> migo-r was for CEU development +10:28 < pinchartl> jmondi: I know, I was teasing Magnus +10:29 < wsa_> jmondi: about MAX9286: a little more detailed "changes since last version" for a patch series would help reviewing quite a bit. otherwise i/we have to find out what you changed in detail. +10:29 < jmondi> that's a pretty nice task: complete CEU driver AND implement mt9v111 sensor driver +10:29 < jmondi> uh, I forgot the v1->v2 changelog? +10:29 < wsa_> jmondi: may I ask you to be a bit more detailed next time? +10:30 < jmondi> yes, not v1->v2 in cover letter, sorry about that +10:30 < pinchartl> jmondi: you mentioned in your e-mail report you will start travelling on Saturday, is it this saturday ? +10:30 < jmondi> this saturday yes +10:30 < jmondi> from next week I'll reduce my working days but I'll be available +10:31 < pinchartl> at what point should Kieran and I take over on the max9286 ? +10:32 < wsa_> jmondi: no big problem :) +10:32 < jmondi> so, this 2 days, I hope I'll be able -at least- to have capture working again with your series and my series rebased on Niklas' v10 +10:33 < jmondi> then I have a skeleton implementation of max9286 subdevice to be tested with incremental async registration +10:33 < pinchartl> how about giving you the rest of this week and next week, and then taking over ? would that be good ? +10:33 < jmondi> once that's done, I guess it's time for an handover +10:34 < jmondi> yes, next week I won't work full time but I hope I can complete that and assist with handover +10:34 < jmondi> so it's fine +10:34 < pinchartl> perfect, thank you +10:35 < pinchartl> next: Morimoto-san +10:35 < morimoto> A) What have I done since last time +10:35 < morimoto> I'm continuing ALSA SoC framework cleanup. I got good response from Maintainer about one of its idea. +10:35 < morimoto> But I noticed some issue exist on RFC v1. I posted RFC v2 to ML, no response yet. +10:35 < morimoto> B) What I plan to do till next time +10:35 < morimoto> Continue RFC v2 cleanup for all drivers +10:35 < morimoto> C) Problems I have currently +10:35 < morimoto> No, sir +10:35 < morimoto> --EOT-- +10:35 < pinchartl> quick and precise, thank you :-) +10:35 < morimoto> :) +10:36 < pinchartl> are you still supposed not to work on HDMI output for Gen3 due to legal reasons ? +10:36 < morimoto> Renesas Europe(?) guy want to use it. and I can support him +10:36 < morimoto> but, in offically, I still keep distance form it +10:36 < morimoto> on upstream +10:37 < morimoto> maybe not a big problem I think +10:37 < morimoto> but, paper work guys... +10:37 < pinchartl> for now it's fine, I hope it will be solved soon +10:37 < pinchartl> thank you +10:37 < morimoto> Yes, thanks +10:37 < pinchartl> next, dammsan +10:37 < morimoto> pinchartl: after lunch, I want to confirm about BSP team's request +10:37 < dammsan> i've had time off - nothing new to report +10:38 < pinchartl> morimoto: sure, I haven't forgotten, I noted the questions from your e-mail :-) +10:38 < pinchartl> dammsan: ok, that's an easy one +10:38 < morimoto> thanks +10:38 < pinchartl> are all the Gen3 boards back in the remote farm ? +10:39 < dammsan> good question, i think so =) +10:39 < dammsan> but at new locations +10:39 < dammsan> if there is something special you need then let me know +10:39 < pinchartl> thank you +10:39 < pinchartl> any plan to work on multimedia for the next two weeks ? :-) +10:40 < dammsan> not from my side +10:40 < dammsan> i might refresh ipmmu +10:40 < pinchartl> ok, thank you +10:40 < pinchartl> next, myself +10:41 < pinchartl> - since last meeting +10:41 < pinchartl> posted a new version of the H3 ES2.0 display output patches +10:41 < pinchartl> now that I'm back home all four outputs have been tested +10:41 < pinchartl> (and they work ;-)) +10:42 < pinchartl> I've also fixed the DU/VSP initialization order problem +10:42 < pinchartl> but we now have a vblank-related issue when stopping the display +10:42 < pinchartl> for the next two weeks +10:42 < pinchartl> fix the display stop issue +10:43 < pinchartl> clean up the max9286 and rdacm20 driver with Kieran, taking over work form Jacopo during his holidays +10:43 < pinchartl> and hopefully working on the DU automated test suite +10:43 < pinchartl> no issue or blocker for now +10:44 < pinchartl> and for today, I will send the additional tasks descriptions to Magnus +10:44 < pinchartl> sorry for the delay +10:44 < kbingham> pinchartl: Silly question - All four outputs tested ... whats' the fourth ... HDMI0 HDMI1 VGA ... +10:44 < pinchartl> kbingham: LVDS +10:44 < kbingham> pinchartl: Ah of course :) +10:44 < pinchartl> you need a special LVDS panel +10:45 < pinchartl> this closes the task reporting part of the multimedia meeting +10:46 < pinchartl> for this afternoon, I currently have the following topics +10:46 < pinchartl> - question from Morimoto-san +10:46 < pinchartl> - max9286 DT (Jacopo) +10:46 < pinchartl> anything else ? +10:47 < neg> not from me +10:47 < pinchartl> ok, I'll now let Wolfram and Geert decide who goes next :-) +10:47 < pinchartl> thank you all for attending diff --git a/wiki/Chat_log/20170720-core-chatlog b/wiki/Chat_log/20170720-core-chatlog new file mode 100644 index 0000000..f469d14 --- /dev/null +++ b/wiki/Chat_log/20170720-core-chatlog @@ -0,0 +1,263 @@ +Core-chat-meeting-2017-07-20 + +11:01 < geertu> Welcome to today's Core Group meeting! +11:01 < geertu> Agenda: +11:01 < geertu> 1. Status updates +11:01 < geertu> 2. Discussion Topics +11:01 < geertu> Topic 1. Status updates +11:01 < geertu> A) What have I done since last time +11:02 < geertu> B) What I plan to do till next time +11:02 < geertu> C) Problems I have currently +11:02 < geertu> First is Morimoto-san +11:02 [Users #periperi] +11:02 [ dammsan] [ kbingham ] [ marex-cloud] [ neg ] +11:02 [ geertu ] [ kbingham[m]] [ morimoto ] [ pinchartl] +11:02 [ jmondi ] [ Marex ] [ mturquette ] [ uli___ ] +11:02 -!- Irssi: #periperi: Total of 12 nicks [0 ops, 0 halfops, 0 voices, 12 normal] +11:03 < morimoto> OK +11:03 < morimoto> A)=B)=C)= NULL, sir +11:03 < geertu> Thank you, Morimoto-san! +11:03 < geertu> Next is Niklas +11:04 < neg> A) +11:04 < neg> - No Core tasks. +11:04 < neg> B) +11:04 < neg> - No Core tasks planed. +11:04 < neg> C) +11:04 < neg> - No Core problems. +11:04 < neg> --EOT-- +11:04 < geertu> Thank you, Niklas! +11:04 < geertu> Next is Geert +11:04 < geertu> A) +11:05 < geertu> - V2 of CNTVOFF initialization and SMP for R-Car E2 +11:05 < geertu> - Playing with r8a77995/draak +11:05 < geertu> B) +11:05 < geertu> - Publish CPG/MSSR for R-Car D3 after checking against datasheet rev. 0.55E +11:05 < geertu> - Holidays +11:05 < geertu> - Publich v2 of CPG/MSSR DT for R-Car Gen2 +11:05 < geertu> - Suspend/resume for PFC +11:05 < geertu> - Mark periupport priority < H commits that are in linux-next +11:05 < geertu> C) +11:05 < geertu> - None +11:05 < geertu> D) +11:05 < geertu> - [PATCH] ARM: shmobile: rcar-gen2: Fix deadlock in regulator quirk +11:05 < geertu> Needed to boot v4.13-rc1 on cold lager, koelsch, and gose!!! +11:06 < geertu> --EOT-- +11:06 < geertu> Next is Magnus +11:07 < dammsan> as per email +11:08 < geertu> A) +11:08 < geertu> - Flashed and hooked up D3 Draak for remote access +11:08 < geertu> - Updated and posted IPMMU cleanup series +11:08 < geertu> [PATCH v2 00/05] iommu/ipmmu-vmsa: 32-bit ARM update V2 +11:08 < geertu> B) +11:08 < geertu> - Update IPMMU Gen3 patches +11:08 < geertu> - Consider sysfs interface for IPMMU driver +11:08 < geertu> C) +11:08 < geertu> - None +11:08 < geertu> (FTR) +11:08 < geertu> Thank you, Magnus! +11:08 < dammsan> thx +11:08 < geertu> Next is Jacopo +11:09 < pinchartl> quick question, what is the sysfs interface for IPMMU about ? +11:09 < geertu> Ah, jmondi has left? +11:09 < morimoto> (borrowing morimoto keyboard) +11:09 < geertu> Next is Laurent +11:10 < pinchartl> #!/usr/bin/python +11:10 < pinchartl> for section in ('A', 'B', 'C'): +11:10 < pinchartl> print('%s) None' % section) +11:10 < morimoto> we need a way to assign devices to IPMMU iova spaces +11:10 < geertu> python: command not found +11:11 < morimoto> (says magnus) +11:11 < geertu> Thank you, Laurent! +11:11 < geertu> Next is Marek +11:11 < pinchartl> morimoto: by iova spaces, do you mean the IPMMU TLBs ? +11:11 < Marex> A) Linux: ROHM PMIC core is in, VC6 6901 is in clk-next +11:11 < Marex> A) U-Boot +11:11 < Marex> - Import DTS from Linux 4.12 +11:11 < Marex> - clock: Implement driver for R8A7795/R8A7796 +11:11 < Marex> - Serial-SH: - switch to use clock framework +11:11 < Marex> - probe from DT +11:11 < Marex> - RAVB: - Fix PHY detection +11:11 < Marex> - Switch to use clock framework +11:11 < Marex> - Probe from DT +11:11 < dammsan> yep +11:11 < Marex> - SH-SDHI: - Fix ACMD handling +11:11 < Marex> - Add clock framework support +11:11 < Marex> - Add support for probing from DT +11:11 < Marex> - Uniphier-SD: - Make it working on RCar Gen3 +11:11 < Marex> (this driver is much better) +11:11 < Marex> - USB: Zap ehci-rcar-gen3 in favor of ehci-generic +11:12 < Marex> B) U-Boot +11:12 < Marex> - pincontrol driver for Gen3 +11:12 < Marex> - rename uniphier-sd to matsushita-sd (?) +11:12 < Marex> - post the patches +11:12 < Marex> C) U-Boot +11:12 < Marex> - Lots of work to be done still :-) +11:12 < Marex> I also have questions, ie. D) +11:12 < Marex> D) U-Boot +11:12 < Marex> - Can I post the patches ? +11:12 < Marex> - What about RPC driver, can I start working on it ? +11:12 < Marex> (What about Linux RPC driver?) +11:12 < Marex> - EHCI/xHCI DT nodes for R8A7796 for Linux ? +11:12 < Marex> - Where is the Salvator-XS stuck, it didn't arrive yet +11:12 < Marex> -- EOF -- +11:12 < pinchartl> dammsan: ok, thanks. yes, that's an issue that we have to solve. I'm not sure what the best option is +11:12 < pinchartl> Marex: what's the RPC driver ? +11:13 < Marex> pinchartl: QSPI/Hyperflash driver , it would be useful for me with patched BL2 to reprogram U-Boot from U-Boot +11:13 < Marex> pinchartl: there's even some example code for RZ/A1, which I suspect has the same or very similar block +11:13 < pinchartl> ok, thanks +11:13 < Marex> (and -- putting on my MTD co-maint hat on -- I'd be interested to learn about Hyperflash and how we can add that to Linux =) ) +11:14 < geertu> Marex: Isn't it just QSPI / paired QSPI? +11:14 < Marex> geertu: I think the command set is different and the bus is a bit different too, but I didn't look too deeply +11:14 < Marex> geertu: we had a brief discussion about it on #mtd, but it didn't get far since there's no hardware in the wild +11:14 < Marex> (unless you bake a core into an FPGA of course :-) ) +11:14 < geertu> Marex: until now? +11:15 < Marex> geertu: kindof, the RPC is locked in the BL2 by default, so you cannot access the regs, you have to patch the BL2 mapping tables to allow access to those regs +11:15 * Marex has a patch of course and runs a patched BL2 :-) +11:16 < geertu> Shimoda-san would be greatful if you added EHCI/xHCI DT nodes for R8A7796 +11:16 < geertu> I believe the clocks are already there, courtesy Kaneko-san +11:16 < Marex> geertu: it works for me in U-Boot , so I probably should just test it in Linux too and submit the patch ; it's almost a copy of the R8A7795 with a bit of crosschecking the datasheet +11:16 < geertu> clocks -> in the driver +11:17 < geertu> The binding update needs to be resent, though (it dates from summer 2016?) +11:17 < Marex> geertu: the 7795 seems to have 4 EHCI, while the 7796 has two, I don't think on the EHCI side, there's any difference besides that +11:17 < Marex> geertu: jupp +11:17 < Marex> the HSUSB block is the same too, so should be easy +11:17 < geertu> dammsan: What about "Can I post the patches ?" +11:18 < dammsan> go ahead +11:18 < Marex> dammsan: thanks ! +11:18 < dammsan> thx +11:18 < geertu> Marex: The XS you no longer need, as the VC6 support for XS is already in Simon's tree ;-) +11:19 < Marex> dammsan: the stack I sent you is a bit outdated, but I think it's OK if I have a bit more free reign about sending the R8A779x patches ? +11:19 < Marex> dammsan: I added some more patches on the SD and USB side , no xhci yet, just driver improvements +11:20 < geertu> Marex: BTW, is there a CNTVOFF register to initialize, like on CA7/CA15? +11:20 < Marex> geertu: where ? +11:20 < Marex> geertu: re XS, doesn't that have the R8A7795 on it ? :) +11:20 < Marex> dammsan: re XS, I should notify Anders that I no longer expect it, yes ? +11:22 < dammsan> pls email anders +11:22 < Marex> dammsan: ACK +11:22 < geertu> Thank you, Marek +11:22 < geertu> Next is Ulrich +11:23 < uli___> no updates from me +11:23 < geertu> Thank you, Ulrich +11:24 < geertu> As Shimoda-san is not here, I'll copy his updates +11:24 < geertu> A) +11:24 < geertu> - Make USB2.0 clock selector driver as a CCF driver. +11:24 < geertu> But I have to update it for some feedbacks. +11:24 < geertu> - About R-Car D3's CPG things, unfortunately I don't get any information +11:24 < geertu> from BSP team yet. +11:24 < geertu> (BSP team intends to ask HW team but BSP team seems busy for now?) +11:24 < geertu> B) +11:24 < geertu> - Continue to improve USB2.0 clock selector driver. +11:24 < geertu> - Need reply about R-Car D3's CPG things to Geert-san. +11:24 < geertu> - Add USB3.0 clock to r8a7796-cpg-mssr.c for v4.14. +11:24 < geertu> - Add hsusb, [oex]hci[01], usb2_phy1 nodes on r8a7796.dtsi instead of each +11:24 < geertu> "placeholder" for v4.14. +11:24 < geertu> C) +11:24 < geertu> - If someone can handle adding usb3.0 clock and usb related device nodes +11:24 < geertu> for r8a7796, I'm very happy :) +11:24 < geertu> ---EOT--- +11:24 < geertu> Topic 2. Discussion Topics +11:25 < geertu> Do we have any? +11:25 < Marex> dammsan: email is out +11:26 < Marex> geertu: RPC, can I start working on it ? +11:26 < neg> geertu: Noting from me +11:26 < morimoto> useful defconfig for Gen3 board, somehow +11:27 < Marex> morimoto: make savedefconfig is flaky again ? +11:27 < geertu> This is a recurring topic. +11:27 * Marex had problems with that before, sigh +11:27 < morimoto> not a big deal though +11:28 < geertu> Personally, I think Simon should have arch/arm64/configs/renesas_defconfig in his devel branch, not for merge upstream +11:28 < geertu> Then the individual developers can send an update when they enable hardware support +11:28 < geertu> update = for renesas_defconfig and plain (arm64) defconfig +11:28 < morimoto> it sounds good to me +11:28 < neg> I like that idea +11:32 < geertu> Marex: About RPC, that's not my call, although I like it. +11:32 < Marex> geertu: I like it too :-) +11:33 < Marex> kbingham: it's 7.30 hrs from PRG to San Sebastian for me, heh +11:33 < geertu> I think we're done with core? +11:34 < pinchartl> when does everybody plan to arrive in San Sebastian ? I was thinking about Friday the 1st, but I'm also contemplating Thursday the 31st +11:35 < neg> I was looking at flights for the 1st but I'm flexible +11:36 < geertu> Monday, if possible +11:36 < morimoto> Japanese 3 member are planning it now. +11:36 < morimoto> We are thinking that we will arrive at 2nd or 3rd +11:36 < neg> also should we try to book a euro-periperi airbnb house? If so how many beds do we need? +11:36 < morimoto> but should we at 1st ? +11:37 < pinchartl> morimoto: the meetings will start on the 4th. it depends how long you need to get adjusted to jetlag ;-) +11:37 < morimoto> Hehe :) +11:37 < pinchartl> neg: I would like to +11:38 < morimoto> If we can have extra meeting before 4th, it can be good reason to escape from office for us :) +11:38 < Marex> heh +11:39 < pinchartl> I'm sure we could organize a meeting before the 4th if needed :-) +11:40 < neg> pinchartl: so that is you, kbingham, uli___, geertu, jmondi, wsa, Marex, simon and me => 9 ppl or am I forgeting someone? +11:41 * Marex is invited to the megaparty ? wow, I'm flattered +11:41 < pinchartl> I think that's it. however, some of us might prefer staying at a hotel, you would have to ask +11:41 < geertu> I don't mind a house +11:41 < geertu> I don't mind a hotel +11:41 < neg> ofc just looking for the upper limit to be able to browse the options +11:42 < pinchartl> geertu: there might be no pig this time +11:43 < neg> :-( +11:44 < geertu> pinchartl: As long as there's a pig in the main house, Morimoto-san will be happy +11:44 < pinchartl> neg: when do you plan to fly back ? +11:45 < morimoto> no pig this time :) +11:45 < neg> pinchartl: flexible, but I intend to stay atleast to the 9th to be able to join all meetings +11:46 < pinchartl> neg: I need to be in Belgium for the 10th, so I think I'll fly back on the 9th +11:46 < pinchartl> 1st to 9th then +11:46 < neg> I tentativly booked 4-10 in my calendar but as it now looks like ppl will show up the 1st I might as well make it 1-10 +11:47 < neg> 1-9 also works, should we set that as a target when looking for airbnb options? +11:48 < pinchartl> sounds good to me +11:48 < pinchartl> Kieran will likely leave on the 8th +11:48 < geertu> pinchartl: me too +11:49 < dammsan> me too +11:49 < neg> So since ppl intend to show up erlier should we aim to move the IO meeting from the 8th to some other day? +11:49 < pinchartl> geertu: and you will arrive on Monday the 4th, right ? +11:50 < pinchartl> neg: I'd rather not move the social day to Friday though +11:50 < dammsan> same here +11:50 < geertu> pinchartl: Correct (still to book flights) +11:50 < Marex> geertu: damned iberia is oneworld :/ +11:51 < dammsan> can we host i/o meeting in other airbnb place? +11:51 < pinchartl> dammsan: I think we should be able to +11:51 < neg> If we managed to find one I'm sure that is possible +11:52 < dammsan> my guess is that 9 ppl needs two more airbnb probably +11:52 < dammsan> unless you want to share a single shower +11:53 < dammsan> the map browsing feature of airbnb is pretty good btw +11:53 < dammsan> i recommend to check cancellation policy, the strict one is pretty strict imo +11:53 < neg> a qucik search suggest there are ~2 options near by that have >= 9 beds but yes there might be other constrains such as showers (but the sea is so close...) +11:54 < pinchartl> neg: maybe we should aim for 2 places +11:54 < dammsan> usually number of baths are kind of limited. also many double beds +11:54 < dammsan> think 12ppl place turns into 4ppl +11:55 * neg never used airbnb so good point about checking the cancellation policy +11:55 < dammsan> if you are tight on space then there most likely is an unused twin bed in my room +11:56 < dammsan> but we are a tad low on bath options so i prefer not to push it more than necessary +11:58 < neg> cheking the old mail thread it looks like everyone is attending but Marex who provided no prefrences on dates and Simon who did not prefere the dates but not sure if he made it work or not since, anyone know? +11:59 < dammsan> i think simon is fine +11:59 < geertu> Yeah, I talked to him last week, and he is planning to attend +12:04 < dammsan> Marex: how difficult is it to work on the RPC? can you do it w/o further docs? +12:08 < Marex> dammsan: I'd have to check that, but probably yes +12:09 < Marex> dammsan: I would need a few hours to familiarize myself with the hyperflash part +12:09 < Marex> dammsan: the RPC itself is documented and there is example code too +12:09 < dammsan> i think you should go ahead and scratch that itch +12:09 < Marex> dammsan: OK, thank you +12:09 < dammsan> worst case if renesas prefers not to use it then we can keep it disabled +12:10 < Marex> dammsan: right +12:17 < dammsan> pinchartl: i booked the airbnb meeting place from the 2nd. was thinking of exploring bilbao before that. +12:18 < dammsan> but if more people arrive in san sebastian earlier then i'm happy to be there instead +12:20 < pinchartl> dammsan: I'll fly to San Sebastian, but I could then move to Bilbao or somewhere else +12:20 < dammsan> its just around the corner +12:21 < dammsan> Bilbao is supposed to have a bit more of museums if i understand it correctly +12:22 < dammsan> according to my guide books busses to san sebastian tend to go via bilbao by default, but it may vary with airport and timing +12:23 < pinchartl> the question is, where are the good restaurants ? :-) +12:23 < dammsan> i got a michelin guide book but it is in spanish =) +12:24 < dammsan> still easier than japanese +12:24 < geertu> spanish is a (far) descendant of greek? +12:25 < dammsan> according to "lonely planet pocket bilbao and san sebastian" you should book months ahead +12:26 < pinchartl> indeed, there's a risk of that +12:26 < dammsan> geertu: not sure, but many words seem easy to understand to me +12:26 < pinchartl> there's clearly no way we'll fit the whole crowd around the same table anyway +12:26 * pinchartl is off for lunch, I'll be back later +12:26 < dammsan> probably so +12:28 < dammsan> we should be able to eat a lot of pintxos at least! +12:28 < geertu> dammsan: french, spanish, italian, latin, ... all the same ;-) +12:28 < dammsan> txoko seems interesting too +12:28 < dammsan> indeed =) +12:34 * geertu lunchtime +12:50 * morimoto will go back to lovely home +12:50 < morimoto> I hope someone can put this chat log to Wiki page somehow diff --git a/wiki/Chat_log/20170803-io-chatlog b/wiki/Chat_log/20170803-io-chatlog new file mode 100644 index 0000000..a315dd6 --- /dev/null +++ b/wiki/Chat_log/20170803-io-chatlog @@ -0,0 +1,107 @@ +09:59 < neg> wsa_: congrats on the SD issue fixes :-) +09:59 < wsa_> thanks :) +09:59 < wsa_> let's wait for Simon's test first, though +10:00 < wsa_> although I'm somewhat optimistic since my pretty stubbto SanDisk cards works now +10:00 < wsa_> sttubborn +10:00 < pinchartl> hi Wolfram +10:00 < wsa_> well, you know what i mean ;) +10:02 < wsa_> shall we start? +10:03 < wsa_> jmondi still on the road, I guess? +10:03 < pinchartl> I think he is, yes +10:03 < wsa_> ok, then +10:03 < wsa_> welcome everyone to the IO meeting part +10:03 < wsa_> let me summarize what happened +10:04 < wsa_> Niklas resent the WakeOnLan patches and got the accepted by Sergei at least +10:04 < wsa_> so we likely will see this in v4.14, I'd think +10:05 < wsa_> Simon sent the missing part for SDHI DMA support for Gen3 +10:05 < wsa_> so we likely will see this in v4.14, I'd think +10:05 < wsa_> I tested and found SDR104 support for SDHI stable and enabled it for Gen3 +10:05 < wsa_> so we likely will see this in v4.14, I'd think +10:06 < wsa_> Shimoda-san keeps updating the USB issues +10:06 < wsa_> and for future things: +10:06 < wsa_> ulrich will work on HSCIF HW timeout configuration +10:06 < wsa_> simon will work on IP CSum offloading +10:06 < wsa_> and I will work on fault injection for I2C +10:07 < wsa_> that's what I have on my radar +10:07 < wsa_> did i miss something? +10:07 < pinchartl> fault injection for I2C... that will hurt :-) +10:07 < wsa_> yes :D +10:07 < dammsan> wondering if sdr104 can be enabled on more boards/socs? +10:08 < wsa_> oh, and we have watchdog improvements +10:08 < wsa_> so we likely will see this in v4.14, I'd think +10:08 < wsa_> dammsan: i want to check the issues seen on ALT next +10:09 < dammsan> ok, just dont forget about the xs board and the ulcbs for r-car gen3... +10:09 < wsa_> dammsan: once I understood and fixed that, I hopefully can say more about Gen2 boards +10:09 < dammsan> it makes sense to keep support coherent +10:09 < wsa_> dammsan: i think xs is already supported because my patch is for salvator-common.dtsi +10:10 < horms> sdr104 is mostly enabled on Gen2, fwiiw +10:10 < horms> I can look up what the loose ends are +10:10 < horms> btw, there is an elinux wiki page to track this +10:10 < horms> but its probably missing recently upstreamed boards, for some value of recent +10:10 < wsa_> do we have ulcbs boards? +10:10 < horms> Magnus has some, he may be willing to arrange accesss +10:11 < dammsan> i have them in my remote access rack +10:11 < wsa_> are there UHS cards in there? :) +10:11 < dammsan> for people that want/need physical access it should be possible to purchase +10:11 < horms> wsa_: do you think insertion/removal tests will be needed on ulcb? +10:11 < horms> yes, they seemed easy enough to purchse last time I checked +10:12 < dammsan> i have not equipped the ulcbs with more than the power-on timer hardware, so no... +10:12 < horms> but I was concerned about getting a good version of the board after some comments somewhere, probably be Sergei +10:12 < dammsan> i don't mind hooking things up though +10:12 < horms> I can send you SD cards if it helps +10:12 < dammsan> let me know what you need and i'll fix it +10:12 < wsa_> horms: it wouldn't hurt to do this test, of course. Still, my feeling is that this kind of fault depends more on the cards used than on the boards used. +10:12 < horms> good ones, that break the driver ! +10:13 < horms> wsa_: i agree entirely +10:14 < horms> btw, the email on this topic was the best news I've had for some time :) +10:14 < wsa_> dammsan: ok, i'll send you links of some cards. +10:14 < dammsan> i can purchase some cards from amazon right away if you tell me what you need +10:14 < dammsan> thanks +10:14 < horms> I have some specific cards I like to test, but I defer to wsa on this +10:15 < dammsan> will you purchase ulcb boards if needed? +10:15 < horms> If they are needed, yes +10:15 < dammsan> good +10:15 < horms> But if they are not needed, which seems likely, then probably not +10:16 < wsa_> let's start with Magnus' boards first +10:16 < dammsan> you decide what is needed to keep the support level coherent =) +10:16 < horms> yes, of course +10:16 < dammsan> thanks +10:17 < wsa_> nice +10:17 < horms> wsa_: how does this relate to SDIO? +10:17 < wsa_> I haven't checked if the transfer speeds improved +10:17 < wsa_> i think cards should also be detected more reliably now +10:18 < wsa_> i could get my WLAN card to work by modifying the TDSEL value +10:18 < wsa_> this doesn't seem to be terribly needed anymore +10:18 < horms> ok, great. iirc it was tricky to upstream +10:19 < wsa_> I should give the WLAN card another try, though +10:19 < horms> do you see any issues with SD on Gen2, f.e. Lager? +10:19 < horms> I see errors in dmsg using mmc/next +10:19 < wsa_> really? +10:19 < horms> I'll get you some logs +10:19 < horms> ok? +10:19 < wsa_> please do +10:20 < horms> I should be able to so so very soon, i saw them as recently as yesterday +10:21 < wsa_> i will check, too +10:21 < wsa_> next week, though +10:21 < wsa_> i'll be unavailable for the rest of the week after this meeting :) +10:21 < horms> btw, you need the fix I posted for v4.13-rc1 to boot mmc/next on Gen2 +10:21 < horms> I mean, Geert posted and I sent a pull-request for +10:22 < horms> anyway, lets take this offline +10:22 < horms> sorry to hijack the meeting +10:22 < wsa_> so, i noted to check gen2 and SDIO with gen3/sdr104 +10:23 < wsa_> any other topics? +10:23 < dammsan> need additional tasks for batch 2 at some point +10:23 < dammsan> please ponder about those +10:24 < neg> wsa_: will you be around after the MM meeting is over? +10:25 < wsa_> dammsan: yup, will do +10:25 < wsa_> neg: not very likely +10:25 < neg> wsa_: Ok then quick question, is there room for me at the 'Alameda Apartment' for the entier booking period? +10:26 < wsa_> if you don't mind sharing a twin room, then you are very welcome +10:26 < neg> cool, that is no issue if someone else don't mind sharing with me +10:27 < neg> I sign my self up on the wiki, worst case I can sleep on the beach :-) +10:27 < wsa_> hehe +10:27 < wsa_> I don't think it will be a problem +10:28 < pinchartl> is there more to discuss for I/O, or can we start with MM ? +10:28 * wsa_ hands over the mic to Laurent +10:28 < wsa_> thanks for the meeting! +10:28 < pinchartl> thank you Wolfram diff --git a/wiki/Chat_log/20170803-mm-chatlog b/wiki/Chat_log/20170803-mm-chatlog new file mode 100644 index 0000000..9783fb9 --- /dev/null +++ b/wiki/Chat_log/20170803-mm-chatlog @@ -0,0 +1,243 @@ +Multimedia-chat-meeting-2017-08-03 + +10:28 < pinchartl> Jacopo is on vacation, Kieran and Morimoto-san have reported by e-mail and are excused +10:28 < wsa_> thanks, will have :D +10:28 < pinchartl> let's start with status update +10:29 < pinchartl> in inverse e-mail report order... *drum roll* +10:29 < pinchartl> uli___: welcome :-) +10:29 < uli___> do i at least get a prize? +10:29 < uli___> anyway... +10:29 < uli___> so i think one of the max9260 on the blanche board has actually died +10:29 < pinchartl> :-) +10:29 < uli___> not a problem for me, there are still 5 to go +10:29 < uli___> at least for now... :) +10:30 < pinchartl> do you know how it might have died ? +10:30 < uli___> no idea. but i strongly suspect that it's not a coincidence that it's the one the cable was attached to previously +10:30 < uli___> maybe the camera board does shady stuff +10:30 < uli___> but there's no way to tell, really +10:31 < pinchartl> does the IC get hotter than the other ones ? +10:31 < uli___> dammsan: please feel the chip for us :) +10:32 < pinchartl> not much we can do at this point I suppose +10:32 < pinchartl> but it would be interesting to log your actions to have data in case another one dies +10:32 < uli___> that might be a good idea +10:33 < uli___> so far, i have only read the id register on the max9259 +10:33 < pinchartl> is power to the MAX9260 controllable by Linux ? +10:34 < uli___> partially, i think. there are sleep modes; i would have to check the datasheet +10:34 < pinchartl> you might want to check power sequences, the chip might not appreciate having the camera powered if it isn't itself +10:35 < uli___> by default, all chips are up +10:35 < uli___> maybe the camera board stabilizes earlier than the blanche board? +10:35 < pinchartl> I have no idea +10:36 < uli___> there might have to be a power-up delay for safe operation +10:37 < uli___> anyway, apart from that i'm mentally preparing myself for a week of sd card swapping +10:37 < pinchartl> :-) +10:38 < uli___> in order to find out where the chromebook fails to boot +10:38 < uli___> that's it from me +10:38 < pinchartl> thank you +10:38 < pinchartl> next, Kieran, who reported by e-mail +10:38 < pinchartl> since last meeting: +10:39 < pinchartl> - Submitted 8 channel camera patches with Laurent. +10:39 < pinchartl> - Holiday +10:39 < pinchartl> - Reviewed Laurent's VSP-Du series' +10:39 < pinchartl> for the next two weeks: +10:39 < pinchartl> - Complete my dl-caching task +10:39 < pinchartl> - Finish reviewing Laurent's patches. +10:39 < pinchartl> Issues and blockers: None +10:39 < pinchartl> next, still through e-mail, Morimoto-san +10:40 < pinchartl> since last meeting: +10:40 < pinchartl> - More ALSA framework code cleanups, posted to mailing list and under review +10:40 < pinchartl> for the next two weeks: +10:40 < pinchartl> - Continue with code cleanup +10:40 < pinchartl> Issues and blockers: None +10:40 < pinchartl> next, Niklas +10:40 < neg> (IRC version, please use email for report) +10:40 < neg> A) +10:40 < neg> - [RFC 0/5] arm64: dts: renesas: add VIN, CSI-2 and ADV7482 nodes +10:40 < neg> - [PATCH 0/4] v4l: async: fixes for v4l2_async_notifier_unregister() +10:40 < neg> - Documented VIN findings on Salvator-XS, and fixed issue in CSI-2 +10:40 < neg> driver which effected CVBS capture on H3 ES2.0. +10:40 < neg> - Picked up minor tweaks to the CSI-2 driver from BSP code. +10:40 < neg> - Assembled and tested the 8-ch camera board, managed to capture from +10:40 < neg> one camera using one camera. +10:41 < neg> - Had planing meeting with Laurent and sent out plan and status +10:41 < neg> about Multiple Virtual Channels Development in collaboration with +10:41 < neg> Laurent and Kieran. +10:41 < neg> B) +10:41 < neg> - Finish a (somewhat) working prototype of Multiple Virtual +10:41 < neg> Channels. Goal is to do this using the max9286 board with ADV7482 +10:41 < neg> backup. +10:41 < neg> - Keep pushing updates for incremental async and R-Car CSI-2 driver +10:41 < neg> and its dependencies. +10:41 < neg> - Publish a new rcar-vin-elinux-v11 tag to elinux. +10:41 < neg> C) +10:41 < neg> - Sakari is and Hans have been on vacation so stuff is pending +10:41 < neg> awaiting there return :-) +10:41 < neg> - All 8 cameras I recived fail to probe at the same time, but I can +10:41 < neg> get all to probe "sometime". I'm investigating this but if others +10:41 < neg> know more please let me know. +10:41 < neg> - The suspicion that the MAX9286 can't output using different VC makes +10:41 < neg> me wonder if I should continue with the Multiple Virtual Channels plan? +10:41 < neg> Other) +10:41 < neg> - I will be on a short vacation to Rome 13/8 -- 17/8 +10:41 < neg> --EOT-- +10:42 < pinchartl> you managed to capture from one camera using one camera. well, that's kind of expected, I would have been surprised if you had captured from one camera using, let's say, a fridge :-) +10:42 < dammsan> roman holiday! +10:42 < neg> pinchartl: embrace the IoT +10:42 < pinchartl> could you please update https://osdr.renesas.com/projects/linux-kernel-development/wiki/Member_info with your holidays information ? +10:42 < neg> pinchartl: sure will update the wiki, thanks for reminindg me +10:43 < pinchartl> uli___: while at it, you're the only one without your public ssh key listed in https://osdr.renesas.com/projects/linux-kernel-development/wiki/Member_info +10:44 < pinchartl> neg: thank you +10:44 < pinchartl> next, Magnus +10:44 < pinchartl> dammsan: anything to report ? +10:44 < dammsan> nope +10:44 < dammsan> poking with v3m at the moment +10:44 < uli___> pinchartl: i'll rectify that then. +10:45 < pinchartl> uli___: thanks +10:45 < pinchartl> dammsan: ok +10:46 < pinchartl> next, me +10:46 -!- Irssi: Pasting 16 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +10:46 < pinchartl> Since last meeting: +10:46 < pinchartl> - More max9286 + rdacm20 cleanups +10:46 < pinchartl> - Discussed CSI-2 virtual channel support with Niklas +10:46 < pinchartl> - Fixed the DU + IPMMU issue (hopefully) for good +10:46 < pinchartl> - Rebased (and resubmitted some of the) pending DU patches +10:46 < pinchartl> For the next two weeks: +10:46 < pinchartl> - Extend the DU test suite +10:46 < pinchartl> - CSI-2 virtual channel support +10:46 < pinchartl> Issues and Blockers: +10:46 < pinchartl> - The MAX9286 requires sources to be synchronized. This will likely require V4L2 API extensions. +10:46 < pinchartl> - It isn't clear how the MAX9286 combines input frames. Multiple modes are supported, but the datasheet doesn't document how to select them. Support from Maxim might be needed. +10:47 < pinchartl> that's it for status reports +10:47 < pinchartl> any question so far ? +10:48 < neg> Should I push on with the Multiple Virtual Channels plan as we discussed even with the new suspicions of the MAX9286 and VC ? +10:48 < pinchartl> please do +10:48 < pinchartl> it's needed anyway +10:48 < pinchartl> I'll try to get more information +10:49 < neg> OK +10:50 < pinchartl> I will check with Morimoto-san if we can have support from Maxim +10:51 < pinchartl> what bothers me is that I recall getting information about I2C address programmation in the MAX9286 and MAX9271, from Maxim I believe, but I can't find the e-mail +10:51 < pinchartl> maybe it was a dream :-) +10:51 < pinchartl> next topic, questions from the BSP team +10:52 < pinchartl> Morimoto-san enquired in his e-mail about the status of +10:52 < pinchartl> - DU / VSP initial sequence +10:52 < pinchartl> - DU vblank handling +10:52 < pinchartl> - VIN V4L2_FIELD_SEQ_TB/TB +10:52 < pinchartl> the first two are done, patches have been posted, and I'm waiting for Kieran to review the last two patches before sending a pull request +10:53 < pinchartl> Niklas, the latter has been posted but depends on upstreaming Gen3 support for VIN as far as I understand, right ? +10:53 < neg> VIN V4L2_FIELD_SEQ_TB/TB is also done and patches posted, there is room for future improvment by makeing it possible to use the continues capture mode, but AFIU there is no request for this at the moment +10:54 < neg> Yes they depend on the Gen3 patches, but att support to both Gen2 and Gen3 +10:54 < neg> s/att/add/ +10:56 < pinchartl> thank you +10:56 < pinchartl> the next question comes from me and is for Magnus and Morimoto-san +10:56 < dammsan> shoot +10:57 < pinchartl> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Salvator-X_MAXIM_camera_board describes a "8ch Camera WorkAround" +10:57 < pinchartl> with the "Power ON order (with 8ch WorkAround if needed)" +10:57 < pinchartl> the workaround relates to powering one set of 4 cameras first, and the other after a delay +10:58 < pinchartl> this isn't needed anymore with the latest code +10:58 < pinchartl> so we don't bother +10:58 < pinchartl> however, we still power the MAX9286 one second later than the Salvator-X +10:58 < pinchartl> the wiki page doesn't explain why that is needed +10:58 < pinchartl> I'd like to understand the reason behind that delay to check whether it's still needed +10:59 < dammsan> i don't know why to be honest. feel free to ask morimoto-san via email =) +10:59 < dammsan> i suspect it is related to some issue with reset +11:00 < pinchartl> OK, I will ask Morimoto-san then +11:00 < pinchartl> thank you +11:00 < dammsan> thanks +11:01 < pinchartl> then, Magnus, two items for you +11:01 < pinchartl> one, an official ping about video codecs +11:01 < dammsan> go ahead +11:01 < pinchartl> you asked me to ping you to get more information about a possible future plan +11:01 < pinchartl> so here you are :-) +11:02 < dammsan> thanks =) +11:02 < dammsan> noted +11:02 < pinchartl> thank you +11:02 < pinchartl> then, you mentioned that you'd like to start discussing additional tasks for Q3/2 +11:02 < pinchartl> I don't know if that was for multimedia only or for all groups +11:02 < pinchartl> but the stage is yours +11:02 < dammsan> all groups really +11:03 < dammsan> i have no special requirements at this point +11:03 < dammsan> just noticed that some people still have unassigned slots +11:03 < pinchartl> for Q3/2 ? +11:03 < dammsan> yeah +11:04 < dammsan> so if you want to make use of your slots then i suggest that each guy and/or the group leaders suggest some activities =) +11:05 < pinchartl> is there any request you're aware of from Renesas ? +11:05 < pinchartl> or from you ? :-) +11:06 < dammsan> for m/m i care about consistent support level in mainline +11:06 < pinchartl> what do you mean by that ? +11:06 < dammsan> so perhaps salvator-x and xs and ulcbs may be in not-so-onsistent state +11:06 < dammsan> i mean that if we for instance enabled MMC on one board we should do it on other boards as well +11:06 < dammsan> not sure what the state is for m/m +11:07 < dammsan> with video out and video-in +11:07 < pinchartl> yes, I agree +11:07 < pinchartl> should we start buying ULCBs ? +11:08 < dammsan> i think that makes sense yes +11:08 < dammsan> you are free to use my boards via remote access too +11:08 < pinchartl> for display it's better to have local access +11:08 < pinchartl> can hardware costs for ULCBs be charged to Jinso ? +11:09 < dammsan> i got some converters so i should be able to use HDMI-out via the Adder IPEPS VNC magic too +11:09 < dammsan> i think it should be doable, but may i propose that we associate the cost with additional tasks? +11:09 < pinchartl> sure +11:09 < dammsan> if you can figure out what is missing then we can make sure to provide funding for the required h/w +11:10 < pinchartl> I suppose we should target both the H3SK and M3SK ? +11:10 < dammsan> also the never-ending vin-for-rcar-gen3 =) +11:10 < dammsan> i think so +11:10 < wsa_> dammsan: good news, SDHI/MMC enablement for D3/XS was planned for 9/M together with the drive_strength task +11:10 < dammsan> just make sure to get an H3 with ES2. +11:11 < dammsan> wsa_: good!! +11:12 < dammsan> then we have D3 and V3M as well, but those need to wait a bit i think +11:12 < pinchartl> thank you +11:12 < dammsan> thanks +11:13 < pinchartl> regarding additional tasks, if anyone has one (or more) specific task he wants to work on, please let me know +11:13 < wsa_> ditto +11:15 < pinchartl> (buying the H3SK might not be that easy) +11:15 < dammsan> you can begin with M3 perhaps +11:15 < pinchartl> no stock at digikey, avnet europe doesn't even list it on their website +11:15 < pinchartl> same for M3SK :-) +11:15 < dammsan> i've got both H3 ES1 and ES2 boards +11:16 < dammsan> if anyone wants to go down the route of remote access +11:16 < pinchartl> where did you buy them ? +11:16 < dammsan> i received them +11:16 < dammsan> and modified them to get the automatic power-on thing going +11:16 < pinchartl> (out of stock at future electronics as well) +11:17 < dammsan> friggin-push-button-power-on +11:17 < pinchartl> sounds like we'll have to postpone that +11:17 < pinchartl> or ask Renesas to ship them +11:17 < dammsan> that does not seem to be the preferred way +11:17 < dammsan> but feel free to ask morimoto-san =) +11:19 < pinchartl> well, if it's out of stock everywhere, and Renesas doesn't want to ship boards, then there's nothing we can do +11:19 < pinchartl> I'll ask Morimoto-san +11:19 < dammsan> thanks! +11:20 < dammsan> i can hook up hdmi cables for loopback testing +11:20 < dammsan> or use the adder ipeps +11:20 < dammsan> its just integration, right? +11:20 < dammsan> it should be fairly straight forward i believe +11:20 < pinchartl> it's just integration until we run into issues :-) +11:21 < dammsan> true +11:22 < pinchartl> and I'll assume we'll need ULCBs for Kingfisher development too +11:22 < pinchartl> so it makes sense to plan for that +11:23 < pinchartl> does Kingfisher support both H3SK and M3SK ? +11:24 < dammsan> for multi-camera development v3m might be less error-prone +11:24 < dammsan> not sure, it seems to have some hardware issues at the moment +11:25 < pinchartl> is there a V3M ULCB ? +11:25 < dammsan> not that i'm aware of +11:25 < dammsan> V3M seems to include max9286 +11:25 < pinchartl> ok +11:26 < pinchartl> what's the name of the board ? +11:26 < dammsan> eagle i think +11:26 < dammsan> quad gsml unless i'm mistaken +11:27 < pinchartl> https://github.com/CogentEmbedded/meta-rcar/commit/9e5839a0a7930e0677ff52ac116c81dbc6313b6e +11:27 < pinchartl> seems so +11:27 < pinchartl> and again, it seems that Cogent gets boards before we do +11:28 < dammsan> isn't it great? =\ +11:28 < dammsan> i had to struggle quite a bit to get the v3m +11:29 < pinchartl> I'll ask about that in the meeting report +11:29 < dammsan> good idea +11:29 < dammsan> thanks! +11:30 < pinchartl> you're welcome +11:30 < pinchartl> that's it for me +11:30 < pinchartl> any other discussion topic from anyone ? +11:31 < neg> Not from me +11:31 < pinchartl> the next meeting will take place two weeks from now on the 17th of August +11:31 < pinchartl> I propose adjourning this meeting. does anyone second ? +11:32 < dammsan> yep +11:32 < neg> seconded +11:32 < pinchartl> meeting adjourned, thank you for attending diff --git a/wiki/Chat_log/20170817-core-chatlog b/wiki/Chat_log/20170817-core-chatlog new file mode 100644 index 0000000..5b4d972 --- /dev/null +++ b/wiki/Chat_log/20170817-core-chatlog @@ -0,0 +1,88 @@ +Core-chat-meeting-2017-08-17 + +10:34 < geertu> Welcome to today's Core Group Chat Meeting! +10:34 < geertu> Agenda: +10:34 < geertu> 1. Status updates +10:34 < geertu> 2. Discussion Topics +10:35 < horms> Hello fearless leader! +10:35 < geertu> Topic 1. Status updates +10:35 < geertu> First is Marek (is he active?) +10:36 < geertu> Nope +10:36 < geertu> Next is Laurent +10:36 < geertu> (left stage?) +10:36 < geertu> Next is Ulrich +10:37 < uli___> no updates from me +10:37 < geertu> Thank you, Ulrich! +10:37 < geertu> Next is Simon +10:37 < pinchartl> geertu: nothing to report indeed +10:38 < geertu> (Marek is on a train) +10:38 < geertu> Thank you, Laurent! +10:39 < horms> A) +10:39 < horms> - Have CPUFreq working for r8a779[56] based on BSP patches +10:39 < horms> - Patches have been posted +10:39 < horms> - Some feedback from Geert on cpufreq driver patches - may no longer +10:39 < horms> be necessary +10:39 < horms> B) +10:39 < horms> - Continue work on above +10:39 < horms> C, D) +10:40 < horms> - None, life is good! +10:40 < geertu> Thank you, Simon! +10:40 < geertu> Next is Geert +10:40 < geertu> A) +10:40 < geertu> - Published base R-Car D3 Draak support (CPG/MSSR, SYSC, RST, DT) +10:40 < geertu> - Holidays +10:40 < geertu> - Queued lots of clk and pinctrl patches +10:40 < geertu> B) +10:40 < geertu> - Send pull requests for clk and pinctrl for v4.14 +10:40 < geertu> - Publish v2 of CPG/MSSR DT for R-Car Gen2 +10:40 < geertu> - Suspend/resume for PFC +10:40 < geertu> - Mark periupport priority < H commits that are in linux-next +10:40 < geertu> C) +10:40 < geertu> None +10:41 < geertu> ---EOT--- +10:41 < geertu> Niklas provided a status report by email +10:41 < geertu> A) +10:41 < geertu> - None +10:41 < geertu> B) +10:41 < geertu> - Start to look into the emergency shutdown task. +10:41 < geertu> C) +10:41 < geertu> - None +10:41 < geertu> ---EOT--- +10:42 < geertu> I think that's it for the status updates +10:42 < geertu> Topic 2. Discussion Topics +10:43 < geertu> I received no topics. +10:43 < pinchartl> geertu: I'd like to know if you have assigned any core task to Jacopo or Niklas for Q3/2 +10:43 < geertu> I wanted to enquire Magnus about the CMT rework driver patches, but he's not here. +10:43 < pinchartl> (same question for wsa_ actually) +10:44 < wsa_> nope +10:44 < geertu> Niklas will do R-Car Gen3 Thermal Emergency Shutdown Prototype (joint work with I/O?) +10:44 < wsa_> niklas has a task planned fir Q4/1 +10:44 < wsa_> geertu: kinda, dunno budgetwise, but planning wise, this was moved to core, I think +10:45 < wsa_> jacopo didn't report back to me to have time available +10:45 < wsa_> so no task for him +10:45 < wsa_> i wanted to talk about base-time distribution in SanSeb +10:45 < geertu> well, at least I submitted it to Magnus, and Niklas mentioned it under B above. +10:46 < wsa_> if the status-quo still holds true +10:46 < geertu> What's the task for Q4/1? +10:46 < wsa_> configurable MTU for EtherAVB +10:46 < pinchartl> wsa_: me too. it's annoying when assigning tasks not to know how much time everybody has availabe +10:46 < pinchartl> s/availabe/available/ +10:47 < horms> geertu: my gut feeling is that the CMT rework patches will need someone assigned to them +10:47 < geertu> horms: Hmmm... so DT flag day for R-Car Gen2 moves to v4.16 or later. +10:48 < horms> I guess so. +10:48 < geertu> Unless we can still sneak the driver bits in in v4.14, but that's unlikely to happen. +10:48 < geertu> Status report from Marek-on-the-train: +10:49 < geertu> I have no news except the rohm pmic landing in next, +10:49 < geertu> r8a7795 SalvatorXS uboot doesn't work(fix in progress) and +10:49 < geertu> Hyperflash driver is harder than expected (partly because +10:49 < geertu> MTD layer in uboot is crap) +10:49 < geertu> ---EOT--- +10:50 < geertu> I guess we can conclude core? There are no additional tasks for Q3/2 to discuss, as they've been assigned a while ago. +10:50 < geertu> Next meeting in San Sebastian, more add. tasks for Q4 ;-) +10:50 < marex-cloud> You didn't have to quote me verbatim ^_^' +10:51 < geertu> marex-cloud: Sorry, less work for me ;-) +10:51 < wsa_> marex-cloud: maybe we should move to barebox? :DDDD +10:51 < marex-cloud> Heh, anyway, my connection will drop again soon +10:52 < marex-cloud> wsa_: tianocore, uefi +10:52 < wsa_> marex-cloud: sorry for necrojoking +10:52 < geertu> Thanks for joining! diff --git a/wiki/Chat_log/20170817-io-chatlog b/wiki/Chat_log/20170817-io-chatlog new file mode 100644 index 0000000..67df725 --- /dev/null +++ b/wiki/Chat_log/20170817-io-chatlog @@ -0,0 +1,96 @@ +10:53 < wsa_> hey guys, welcome to the core meeting +10:53 < uli___> wot? +10:53 < geertu> again? +10:53 < wsa_> ups +10:53 < wsa_> io +10:53 < wsa_> sorry, geert +10:53 * wsa_ notes: copy&pasting meetings doesn't work +10:54 < wsa_> let me summarize the status updates: +10:54 < wsa_> simon got the Gen3 enablement patch merged +10:54 < wsa_> uli created the HW timeout config patch for HSCIF but it doesn't work +10:55 < wsa_> wolfram did various things with SDHI and rewrote the I2C core DMA helpers +10:55 < wsa_> please add something if I missed it +10:55 < wsa_> otherwise we have the issues of the non-working HSCIF register from Uli +10:56 < geertu> uli___: Have you checked out the R-Car E2X errata you received recently? +10:56 < geertu> They contain more info about registers that cannot be accessed at any time. +10:56 < wsa_> I'll try to play around today with that, but I'd think we need Morimoto-san on this? +10:56 < uli___> geertu: i'll check it out +10:56 -!- neg [~neg@unaffiliated/neg] has joined #periperi +10:57 < pinchartl> geertu: doesn't sound like very useful registers if they can't be accessed at any time +10:57 < geertu> pinchartl: From the POV of the SW engineer? +10:57 < wsa_> Gen3 docs say "HSSCR can always be read from and written to by the CPU." +10:57 < pinchartl> from any point of view :-) +10:58 < pinchartl> after the read-only register, the write-only register, we have the don't-access-only register +11:00 < wsa_> so, the other issue is SDR104 on Gen3 +11:00 < geertu> on H3 ES2.0? ;-) +11:00 < wsa_> (if there are not more ideas on the HSSCR register) +11:00 < wsa_> enabling ES2.0 is also somewhere on my todo-list +11:01 < wsa_> one of the tasks I'd really like to give away, but in my book, this is a base-task, not an additional task +11:02 < wsa_> this is why I'd like to discuss the status-quo in SanSeb +11:02 < wsa_> so, SDR104 memory cards now work fine on H3 ES1.* and M3-W 1.0 +11:03 < wsa_> it is the SDIO card which has problems in some slots +11:03 < wsa_> at high speeds +11:03 < wsa_> I think the fact that the line length is ~23cm instead of 10cm might have an influence +11:04 < wsa_> hard to test +11:04 < wsa_> resoldering in SanSeb was also kind of shot down :) +11:05 < wsa_> I wonder where is the line of not enabling-SDR104 because of some setup +11:05 < wsa_> I don't want to enable it now +11:05 < wsa_> ES2.0 testing should also happen and way more testing in SanSeb +11:05 < wsa_> but still +11:05 < pinchartl> wsa_: desoldering such connectors is pretty difficult. a soldering iron isn't the best tool for the job +11:05 < geertu> Can't the driver/subsystem downgrade the feature set if errors are detected? +11:07 < wsa_> on the mmc core layer, could be +11:07 < wsa_> dunno if a driver can request that if e.g. loading firmware fails +11:08 < wsa_> i'd guess if the core notices a problem it will schedule a retune +11:08 < geertu> And if retune fails? +11:09 < wsa_> i expect it to go down with the speed, but i haven't checked +11:10 < wsa_> so far, our tuning only failed because of stalled HW +11:10 < wsa_> but we fixed that +11:12 < wsa_> well, looks like this is a question for SanSeb, too; when we also have more data +11:13 < wsa_> i think that's it for io +11:13 < wsa_> unless you have something to add? +11:13 < geertu> I have one more comment +11:13 < wsa_> sure +11:13 < geertu> About shifting the UART sampling point: This can increase accuracy for serial +11:13 < geertu> speeds that are too much off, cfr. 92a0574867f3329c ("serial: sh-sci: Add +11:13 < geertu> support for SCIFA/SCIFB variable sampling rates"). +11:14 < geertu> If the actual speed differs more than a few % from the requested speed, it fails. +11:14 < geertu> Changing the sampling point can fix that. +11:16 < uli___> i'm looking into quantifying that effect in practice +11:16 < uli___> my current idea is to plop a 57.6 kHz square wave into an uart +11:16 < uli___> and then tweak the frequency until the received pattern is not repetitive any more +11:17 < uli___> and then check if pushing the sampling point can improve the margin +11:17 < uli___> dunno if that works, i'll see once i get my equipment +11:18 < geertu> I had a simpler test method when doing the variable sampling rates +11:18 < geertu> Just configure a speed that cannot be done exactly +11:18 < geertu> and see how it receives garbage. +11:19 < uli___> don't you need two ends for that, with differing imprecisions? +11:19 < geertu> USB serial adapters (e.g. FTDI) can usually do all standard rates. +11:20 < geertu> Renesas SCIF ports always can't, with the supplied clocks +11:20 < geertu> E.g. APE6EVM couldn't do 460800 bps before the aforementioned patch +11:22 < geertu> I think SCIFA on Gen2 still can't do 1500000 bps +11:22 < geertu> Perhaps also not 460800 +11:23 < uli___> frankly, i'm atm more concerned if that functionality in the hscif actually works at all... +11:24 < wsa_> i understand that +11:24 < wsa_> same here +11:24 < geertu> It's not that difficult to find out. +11:25 < geertu> Try all standard rates up to 4 Mbps, and see which fails. +11:25 < wsa_> if we get feedback from renesas next week, this is kinda late for setting up an add. task +11:25 < geertu> Then try all possible sampling points, and see if it helps +11:25 < wsa_> first start would be to see if you can actually change bits in the register ;) +11:26 < uli___> i'll look into it +11:27 < wsa_> for completeness, the planned IO tasks for Q3/2: +11:27 < wsa_> Simon - IP csum offloading for EtherAVB +11:27 < wsa_> Uli - (hopefully) this sampling point adaption for SCIF +11:28 < wsa_> Wolfram - DT bindings for SD/MMC drive strength settings (and side-effect: SDHI ES2.0 enabling) +11:28 < wsa_> note: not PFC drive strength +11:29 < wsa_> this is a command sent to the controllers on the other side +11:29 < wsa_> are we done? +11:30 < geertu> 10-4 +11:31 < wsa_> i don't know what it means, but I assume "yes" :) +11:31 < wsa_> I only know 7-1 +11:31 < uli___> https://en.wikipedia.org/wiki/Ten-code +11:32 < uli___> only used by really old men ;) +11:33 < wsa_> hehe +11:33 < wsa_> okay, then, thank you very much +11:33 < wsa_> meeting closed diff --git a/wiki/Chat_log/20170817-mm-chatlog b/wiki/Chat_log/20170817-mm-chatlog new file mode 100644 index 0000000..105ca8f --- /dev/null +++ b/wiki/Chat_log/20170817-mm-chatlog @@ -0,0 +1,104 @@ +Multimedia-chat-meeting-2017-08-17 + +10:04 < pinchartl> let's start with status updates +10:05 < pinchartl> kbingham: I've submitted my update to myself way ahead of everybody else ;-) +10:05 < kbingham> hehe +10:05 < pinchartl> I'll start by reporting for Niklas +10:05 < pinchartl> since last meeting: +10:06 < pinchartl> - - Working Virtual channel prototype for both onboard ADV748x and MAX9286 board. - [PATCH 0/4] 8 camera setup fixes - [PATCH 00/20] Add multiplexed media pads to support CSI-2 virtual channels - [PATCH 0/8] v4l: max9286: enable virtual channels +10:06 < pinchartl> - New base for onboard VIN component development tag, rcar-vin-elinux-v12. +10:06 < pinchartl> (apoogies for the weird copy and paste) +10:06 < pinchartl> until next meeting: +10:06 < pinchartl> - Keep pushing for the incremental async and other dependencies for the CSI-2 patches to be pushed up. +10:06 < pinchartl> - Make another drive to try and get attention to the VIN patches (will post new version once I'm back from my vacation). +10:06 < pinchartl> issues and blockers: none +10:07 < pinchartl> that's it +10:07 < pinchartl> next, uli___ +10:07 < uli___> tl;dr: chromebook works, headlessly +10:08 < uli___> funny DT that expects one device to be probed twice does not +10:08 < pinchartl> you mentioned that the culprit was an incorrect regulator voltage in DT. will you submit a patch for that ? +10:08 < uli___> that's in the elm board dts, that's not upstream +10:09 < pinchartl> will you submit the elm board dts upstream ? :-) +10:09 < uli___> i would submit that in its entirety once i have figured out how the mmsys probing is supposed to work +10:09 < pinchartl> sounds good to me +10:09 < geertu> uli___: For one device to be probed twice, you should either have a single driver that registers both driver typesm or use mfd +10:09 < geertu> s/typesm/types,/ +10:10 < uli___> any ideas why the dsi defers, but is never retried? +10:11 < pinchartl> uli___: no, but that should be easy to debug +10:12 < pinchartl> you mentioned that the mmsys device is both a DRM device and a clock controller +10:12 < uli___> yes +10:13 < pinchartl> that's pretty strange +10:14 < uli___> i know :) it provides clocks for the various display-related devices +10:14 < geertu> Looks like the simplest is to move the clock driver into the DRM device driver? +10:14 < pinchartl> there's no mention of that in the mediatek DRM DT bindings +10:14 < pinchartl> please contact upstream developers to sort it out +10:15 < uli___> the upstream stuff doesn't have the display-related things +10:15 < pinchartl> I mean the upstream mediatek developers +10:16 < pinchartl> the same compat string is indeed used by both the clock driver and the DRM driver +10:16 < pinchartl> and the display DT bindings don't document that compat string +10:16 < uli___> it looks like half of the display support made it in, there is also a lone drm regulator in the dts that is not used anywhere +10:16 < pinchartl> it's a big WTF, you can ask the DRM driver maintainers and CC the dri-devel mailing list +10:17 < uli___> i'll check the archives, there must have been some discussion on that +10:18 < pinchartl> I wouldn't be surprised if it had been overlooked +10:18 < pinchartl> DRM maintainers are x86-centered +10:19 < pinchartl> anything else to report ? +10:19 < uli___> that's it +10:19 < pinchartl> thank you +10:19 < pinchartl> kbingham: you're next +10:19 < kbingham> Well, I've only had 5 working days since the last meeting, +10:19 < kbingham> In that time I got the display list caching implementation working, and based on top of the tlb-optimise patchset. Then posted for renesas-drivers. +10:19 < kbingham> My 'next' task will be dependant upon the additional tasks disucssion :) +10:19 < kbingham> -- +10:19 < kbingham> EOT. +10:19 < kbingham> Ahh preprepared statement. Such fast. +10:20 < kbingham> :D +10:20 < pinchartl> thank you :-) +10:20 < pinchartl> my turn +10:20 -!- Irssi: Pasting 11 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +10:20 < pinchartl> Since last meeting: +10:20 < pinchartl> - Extended the DU test suite +10:20 < pinchartl> - DU and VSP fixes for issues found by the DU test suite +10:20 < pinchartl> - MAX9286 support for multiple CSI-2 virtual channel streams +10:20 < pinchartl> For the next two weeks: +10:20 < pinchartl> - Patch review +10:20 < pinchartl> - Next additional tasks (to be decided) +10:20 < pinchartl> Issues and Blockers: None +10:20 < pinchartl> that's it for me as well :-) +10:21 < pinchartl> that's it for status updates +10:21 < pinchartl> I wanted to discuss the face to face meeting agenda as the next topic +10:21 < pinchartl> but we don't have the quorum +10:22 < pinchartl> so I propose moving that discussion to e-mail +10:22 < kbingham> +1 +10:22 < kbingham> Do I recall that we won't have a meeting on #PeriPeri now before San Seb? +10:22 < pinchartl> that's what I was going to propose +10:22 < wsa_> I'd vote for that +10:22 < pinchartl> the next meeting should in theory be on the 31st of August, I propose skipping it +10:23 < kbingham> At this stage that seems to be reasonable. +10:23 < geertu> +1 +10:23 < kbingham> In terms of our F2F ... I see we have a disucssion on what to bring. Would you like me to bring the 8 camera setup ? +10:24 < pinchartl> I'm afraid I'd like you to +10:24 < kbingham> Ok - I'll do what I can. +10:24 < kbingham> :D +10:24 < pinchartl> the last topic to discuss today is additional tasks for Q3/2 +10:24 < pinchartl> I've submitted proposals to Magnus and I'm waiting for his reply +10:25 < pinchartl> I expect at least DU suspend/resume to be included +10:25 < wsa_> ditto +10:25 < pinchartl> uli___: do you have slots assigned to the I/O or core group for Q3/2 ? +10:26 < uli___> i/o, sort of; we still have to check if that task is viable, but let's assume it is +10:26 < pinchartl> how much time do you have left unassigned ? +10:26 < uli___> wsa_: what's the plan for the sampling point task? +10:26 < uli___> 5 days? +10:27 < wsa_> yup +10:27 < uli___> 10 days left then +10:27 < pinchartl> ok +10:27 < pinchartl> as usual, if there are items you would like to work on, please let let know +10:27 < pinchartl> that comment is valid for all members of course +10:28 < pinchartl> but Jacopo, Kieran, and Niklas already tell me about what they'd like to work on :-) +10:28 < pinchartl> I'd like to have your feedback on that too +10:28 < wsa_> uli___: if it doesn't take 5 days alone on the test setup procedure ;) +10:29 < uli___> that is something i'm still in the process of figuring out... +10:29 < wsa_> uli___: but that's the on-going investigation, right? +10:29 < uli___> yes +10:29 < pinchartl> any other topic we should discuss ? +10:30 < kbingham> None here. +10:30 < pinchartl> that's it for multimedia then. thank you all for attending diff --git a/wiki/Chat_log/20170906-core-chatlog b/wiki/Chat_log/20170906-core-chatlog new file mode 100644 index 0000000..b22eea8 --- /dev/null +++ b/wiki/Chat_log/20170906-core-chatlog @@ -0,0 +1,163 @@ +<html> +<link rel="stylesheet" type="text/css" href="../../wiki/css"> + <h1>Core-periperi-meeting-2017-09-06</h1> + + <h2>PeriPeriCon – Core Group Meeting</h2> + + <ul> + <li><i>Request from other team (for <span class="caps">KVM</span>)</i></li> + <li><span class="caps">IPMMU</span> features + <ul> + <li><span class="caps">IPMMU</span> current status + <ul> + <li>Context limitation not yet handled</li> + <li>Still many errata on H3/M3-W. D3 may be OK</li> + <li><span class="caps">TODO</span> + <ul> + <li>Upstream <span class="caps">DTS</span> part</li> + <li>Put driver code in renesas-drivers, nothing whitelisted</li> + <li>People interested in playing with it can add devices to the whitelist</li> + </ul></li> + </ul></li> + <li>Support for more than 32-bits <span class="caps">IOVA</span> space + <ul> + <li><span class="caps">GSX</span> needs it.</li> + <li><span class="caps">GSX</span> uses <span class="caps">OSID</span> for isolation</li> + <li>32-bit <span class="caps">IOVA</span> space limitation is a limitation of the <span class="caps">IPMMU</span> driver</li> + <li>It can be tested with other devices than <span class="caps">GSX</span></li> + </ul></li> + <li>Support for multiple guests + <ul> + <li>The current <span class="caps">IPMMU</span> implementation on Gen3 <span class="caps">BSP</span>, second guest OS cannot use <span class="caps">GSX</span>. (#3448, #3486) + <ul> + <li>Need more informtation about the use-case.</li> + </ul></li> + <li>Needs <span class="caps">GSX</span> for testing</li> + <li>Depends on D3</li> + </ul></li> + <li>Support “16.5.2 <span class="caps">IPMMU</span> configuration for <span class="caps">FCP</span>-CS”. + <ul> + <li><span class="caps">IPMMU</span>-PVn also need such handling (Rev.0.55 doesn’t mention it though).</li> + <li>Depends on H3/M3-W (or H3/M3-N, cfr. table 16.14?)</li> + </ul></li> + <li>Overlap with work done by <span class="caps">IGEL</span>?</li> + <li>Main <span class="caps">IPMMU</span> development target aim is D3</li> + </ul></li> + </ul> + + <ul> + <li><i>How to add support for R-Car D3?</i> + <ul> + <li>Smaller integration and binding tasks broken out to the ‘smalller tasks’ list.</li> + </ul></li> + </ul> + + <ul> + <li><i>How to add support for R-Car H3N?</i> + <ul> + <li>H3 ES3.0 and H3N ES3.0 are the same SoC</li> + <li>Different wire bonding: + <ul> + <li>H3 ES3.0 <span class="caps">PFC</span> is the same as H3 ES2.0 <span class="caps">PFC</span> (r8a77951)</li> + <li>H3N ES3.0 <span class="caps">PFC</span> is the same as M3-W</li> + <li><span class="caps">PRR</span> will be the same, Identify based on compatible value (H3N = r8a77955?)</li> + </ul></li> + <li>Use new “renesas,r8a77955” compatible value. + <ul> + <li>To avoid complication of using r8a7795 for both H3 and H3N.</li> + </ul></li> + </ul></li> + </ul> + + <ul> + <li>How to add support for R-Car M3-N? + <ul> + <li>For initial support, remote access env is ok</li> + <li>The HW is coming in Oct or Nov ’17</li> + </ul></li> + </ul> + + <ul> + <li>How to add support for R-Car V3M? + <ul> + <li>Cogent is working on this</li> + <li>PeriPeri has no schematics (yet)</li> + </ul></li> + </ul> + + <ul> + <li><i>R-Car Gen2 <span class="caps">DTS</span> Update Flag Day</i> + <ul> + <li>CMT driver upstreaming is the main blocker => take over from Magnus</li> + </ul></li> + </ul> + + <ul> + <li><i>U-Boot</i> + <ul> + <li>Currently support + <ul> + <li>Salvator-X M3-W and H3 ES2.0</li> + <li><span class="caps">ULCB</span> M3-W and H3 ES2.0</li> + </ul></li> + <li>We need + <ul> + <li>Buy M3-W and H3 <span class="caps">ULCB</span></li> + <li>Add D3 Draak support (remote access only)</li> + <li>Add V3M support (remote access only)</li> + <li>Gen3 <span class="caps">USB</span> <span class="caps">XHCI</span> support (medium prio) + <ul> + <li>needs firmware downloading</li> + </ul></li> + <li>Gen3 <span class="caps">SDMMC</span> HS200/400 and SDR104 modes (higher prio than <span class="caps">XHCI</span> support) + <ul> + <li><a href="https://lists.denx.de/pipermail/u-boot/2017-May/290986.html.html">https://lists.denx.de/pipermail/u-boot/2017-May/290986.html</a></li> + </ul></li> + <li>Finish <span class="caps">PFC</span> support</li> + <li>Submit <span class="caps">RPC</span> support</li> + <li>Mainline U-Boot support for Gen2 (low prio)</li> + <li>Disable <span class="caps">CONFIG</span>_ARCH_FIXUP_FDT_MEMORY to fix Xen breakage [for v2017.09]</li> + <li>Support for massive kernels (128 MiB) [for v2017.11]</li> + <li>Enable Distro environment variables [for v2017.11]</li> + </ul></li> + </ul></li> + </ul> + + <h2><i>Additional Tasks for Q4</i></h2> + + <ul> + <li>Candidates: + <ul> + <li>Support for more than 32-bits <span class="caps">IOVA</span> space (non-working prototype posted by Magnus)</li> + <li><span class="caps">IPMMU</span> DT binding and integration on various R-Car Gen3 SoCs [S?]</li> + <li>Check fallback compatible values (rcar-gen2-*, rcar-gen3-*); Especially <span class="caps">SDHI</span></li> + <li>Extend U-Boot support to more R-Car Gen3 platforms [MV]</li> + <li>DevFreq,?,noplan,?,GPU needs DevFreq, as <span class="caps">DVFS</span> is shared between <span class="caps">CPU</span> and <span class="caps">GPU</span></li> + <li>genpd,?,noplan,?,Fix handling of devices used as wake-up source</li> + <li>renesas-drivers maintenance</li> + </ul></li> + </ul> + + <ul> + <li>Smaller tasks: + <ul> + <li><span class="caps">GPIO</span>,v4.15,plan,shimoda, add D3 binding</li> + <li><span class="caps">SYS</span>-<span class="caps">DMAC</span>,v4.15,plan,?, add D3 binding</li> + <li><span class="caps">SYSC</span>,?,noplan,?,Keep I/O power areas powered on H3 ES1.x/ES2.0 and M3-W ES1.x</li> + <li>r8a77995,v4.15,plan,shimoda, integration for <span class="caps">GPIO</span></li> + <li>r8a77995,v4.15,plan,shimoda, integration for EthernetAVB</li> + <li>r8a77995,v4.15,plan,shimoda, integration for <span class="caps">USBPHY</span>/USB2-Host</li> + <li>r8a77995,v4.15,plan,?, integration for eMMC</li> + <li>r8a77995,v4.15,plan,?, integration for I2C/IIC</li> + <li>r8a77995,v4.15,plan,?, integration for {SYS,Audio}-<span class="caps">DMAC</span></li> + <li>r8a77995,v4.16,plan,?, integration for <span class="caps">IPMMU</span>s</li> + <li>r8a77995,v4.16,plan,?, integration for <span class="caps">RSND</span></li> + <li>r8a77995,v4.16,plan,?, integration for DU</li> + <li>r8a77995,v4.16,plan,?, integration for <span class="caps">VIN</span></li> + <li>Add power-supply to backlight in salvator-common <span class="caps">DTSI</span>: <a href="https://patchwork.kernel.org/patch/9702957/.html">https://patchwork.kernel.org/patch/9702957/</a></li> + <li><span class="caps">CMT</span> driver upstreaming [G]</li> + <li><span class="caps">RPC</span> Hyperflash Linux driver</li> + <li>Enable <span class="caps">EFI</span> library support in U-Boot (?) (check with Shimoda-san if needed) <a href="https://www.suse.com/docrep/documents/a1f0ledpbe/UEFI%20on%20Top%20of%20U-Boot.pdf.html">https://www.suse.com/docrep/documents/a1f0ledpbe/UEFI%20on%20Top%20of%20U-Boot.pdf</a></li> + </ul></li> + </ul> +</html> diff --git a/wiki/Chat_log/20170921-core-chatlog b/wiki/Chat_log/20170921-core-chatlog new file mode 100644 index 0000000..0051527 --- /dev/null +++ b/wiki/Chat_log/20170921-core-chatlog @@ -0,0 +1,166 @@ +Core-chat-meeting-2017-09-21 + +09:02 < geertu> Welcome to today's Core Group Meeting +09:02 < geertu> Agenda +09:02 < geertu> 1. Status updates +09:03 < geertu> 2. Discussion Topics +09:03 < geertu> Topic 1. Status updates +09:03 < morimoto> hi +09:03 < geertu> Morimoto-san is first +09:03 < morimoto> OK +09:03 < morimoto> But I have no Core task +09:03 < morimoto> --EOF-- +09:04 < geertu> Great! +09:04 < morimoto> Ahh, +09:04 < geertu> Laurent is next +09:04 < morimoto> but I found kernel WARNING issue +09:04 < morimoto> I reported it on ML +09:04 < morimoto> ML => PeriPeri ML +09:04 < morimoto> --EOF-- +09:05 < pinchartl> geertu: same +09:05 < geertu> OK +09:05 < geertu> morimoto-san: https://www.spinics.net/lists/arm-kernel/msg603844.html +09:05 < geertu> Known issue, people are working on a fix +09:05 < geertu> "[PATCH 0/4] Fix check address limit on user-mode" might be the fix, haven't tried it ey +09:06 < morimoto> geertu: oh thanks +09:06 < geertu> Next is Geert +09:06 < geertu> A) What have I done since last time (last status updates): +09:06 < geertu> - Sent pull requests for clk and pinctrl for v4.14, +09:06 < geertu> - Published v2 of CPG/MSSR DT for R-Car Gen2, incl. resets, +09:06 < geertu> - Brought up V3M/Eagle, using Sergei's clock patch, +09:06 < geertu> - CNTVOFF initialization for R-Car E2 (and RZ/G1E) SMP, +09:06 < geertu> - Took over CMT DT binding rework from Magnus, published update, +09:06 < geertu> - Lots of reviews (RZ/G1, V3M, Kingfisher, ...), +09:06 < geertu> - Core Additional Tasks for Q4. +09:06 < geertu> B) What I plan to do till next time: +09:06 < geertu> - Suspend/resume for PFC, +09:06 < geertu> - Mark periupport priority < H commits that are in linux-next, +09:06 < geertu> C) Problems I have currently: +09:06 < geertu> - None. +09:06 < geertu> --EOF-- +09:06 < geertu> Next is Simon +09:06 < morimoto> geertu: do you know how to indicate it on renesas_defconfig ? +09:07 < morimoto> normal renesas_defconfig didn't indicate +09:07 < horms> * Core +09:07 < horms> A) +09:07 < horms> - Began addressing review of CPUFreq patches +09:07 < horms> B) +09:07 < horms> - Finalise above and repost +09:07 < horms> C, D) +09:07 < horms> - None +09:08 < geertu> CONFIG_DEBUG_SPINLOCK=y? +09:09 < morimoto> geertu: it seems this URL and my issue is not same +09:10 < geertu> morimoto: Really? Both are about xprtiod vs. tk_work +09:10 < geertu> Thank you, Simon +09:10 < morimoto> Yeah, but my issue seems happen from +09:10 < geertu> Next is Jacopo +09:10 < morimoto> a1d14934ea4b9db816a8dbfeab1c3e7204a0d871 +09:10 < morimoto> (workqueue/lockdep: 'Fix' flush_work() annotation) +09:10 < morimoto> But This URL indicate it was +09:11 < morimoto> 73ac5d6a +09:11 < jmondi> Not much from me +09:11 < geertu> 73ac5d6a = arm32 only +09:11 < geertu> a1d14934ea4b9db816a8dbfeab1c3e7204a0d871 = generic +09:11 -!- horms_ [~horms@217.111.208.18] has joined #periperi +09:11 < geertu> I guess on arm64 it bisects to the latter +09:11 < morimoto> Ahh, ok, I see +09:12 < jmondi> I just tried to have gr-peach working as background task, with no luck so far +09:12 < jmondi> ^ gr-peach ethernet +09:12 < jmondi> and no core tasks scheduled +09:12 < jmondi> --eot +09:12 < geertu> Thank you, Jacopo +09:13 < geertu> Next is Shimoda-san +09:14 < shimoda> < Core > +09:14 < shimoda> A) +09:14 < shimoda> - Add usb device nodes for r8a7796. +09:14 < shimoda> - My concern about u-boot/dts memory nodes was resolved by Marek-san (Thanks!). +09:14 < shimoda> B) +09:14 < shimoda> - Add usb3.0 peripheral and usb3.0 phy device node for r8a779[56].dtsi. +09:14 < shimoda> - Prepare M3-N Salvator-X board for remote access if I obtain the SiP. +09:14 < shimoda> C) +09:14 < shimoda> - Nothing. +09:14 < shimoda> -- eot -- +09:15 < geertu> Thank you, Shimoda-san! +09:15 < geertu> Next is Niklas +09:15 [Users #periperi] +09:15 [ geertu] [ jmondi ] [ Marex ] [ mturquette] [ shimoda] +09:15 [ horms ] [ kbingham ] [ marex-cloud] [ neg ] [ wsa_ ] +09:15 [ horms_] [ kbingham[m]] [ morimoto ] [ pinchartl ] +09:15 -!- Irssi: #periperi: Total of 14 nicks [0 ops, 0 halfops, 0 voices, 14 normal] +09:15 < neg> A) +09:15 < neg> - [PATCH] thermal: rcar_gen3_thermal: fix initialization sequence for H3 ES2.0 +09:15 < neg> - [PATCH 0/2] arm64: dts: r8a7795: r8a7796: add thermal cooling management +09:15 < neg> - [RFC 0/3] thermal: rcar_gen3_thermal: read calibration from hardware +09:15 < neg> B) +09:15 < neg> - Send v2 of 'rcar_gen3_thermal: fix initialization sequence for H3 ES2.0' +09:15 < neg> C) +09:16 < neg> - Not sure if I should go ahead with '[RFC 0/3] thermal: rcar_gen3_thermal: +09:16 < neg> read calibration from hardware'. Before all registers are documented in +09:16 < neg> EOT +09:16 < neg> datasheet or I can find hardware with fused calibration registers. +09:16 < neg> What do core leader and Renesas think? +09:17 < geertu> I think it would be good to be able to test the fused calibration +09:17 < geertu> Is there any board that has it? If it could be put in Magnus' farm, it can be tested +09:18 < neg> I agree so then I will hold off on that patch as RFC untill I can find a board with have the calibration fused to test on +09:18 < neg> And yes if there is such a board today, testing it remote is fine :-) +09:18 < geertu> {morimoto,shimoda}-san? +09:19 < geertu> neg: Have you checked all Gen3 boards in Magnus' farm? (e.g. by a quick read of the fuse register from U-Boot)? +09:19 < geertu> Or are even all the ULCBs "hand prodcution" hardware? +09:20 < neg> geertu: I only have access to one board in Magnus farm (H3) and it did not have the values fused +09:20 < wsa_> Don't we have any information from HW team about that? +09:21 < wsa_> When/what is fused? +09:21 < neg> Yes ULCBs is a good idea I had not tought about that, I will ping magnus about access for that +09:21 < geertu> neg: If you tell me which register to check, I can check all boards I have access to +09:21 < neg> wsa_: All I know is derived from the dataheet which according to Morimot-san needs an update for the missing register and BSP code +09:22 < wsa_> Even if we find a board where the registers have some values, how can we know if we can trust them otherwise? +09:22 < geertu> wsa_: That's the second step ;-) +09:23 < wsa_> It would save some work if it was the first step :D +09:23 < wsa_> But you are free to choose, of course +09:23 < neg> geertu: thanks! I think the fastes check is just to boot with '[RFC 0/3] thermal: rcar_gen3_thermal: read calibration from hardware' applied and if it is booted on a board which have the registered fused it should print dev_info(dev, "Using fused calibration values\n"); +09:24 < neg> wsa_: acording to the BSP code there is a flag in the undocumented register which signals if the fused values ar OK or not +09:25 < morimoto> neg: I think you are talking about the register which you asked me few weeks ago ? +09:25 < neg> morimoto: yes +09:25 < morimoto> And you want to modify it ? +09:26 < neg> No I want a datasheet update where it is documented :-) +09:26 < wsa_> neg: ok, nice +09:26 < morimoto> Ahh, OK. datasheet said that it will be updated in next (?) version +09:26 < morimoto> let me check latest info +09:27 < geertu> neg: I can no longer boot Linux on the ULCBs, only U-Boot +09:27 < geertu> Thanks Niklas +09:27 < neg> geertu: ohh, I will send you an email with the register info, thanks for checking +09:28 < geertu> Next is Ulrich, who is excused, and has nothing to report for core +09:28 < geertu> Marek is also excused, and provided this for U-Boot: +09:28 < geertu> A) What have I done since last time (U-Boot) +09:28 < geertu> - Submitted: +09:28 < geertu> - Improved the Gen3 clock driver (SDxCKCR config, RPC clock) +09:28 < geertu> - RCar Gen3 R8A779{5,6} PFC pinmux driver +09:28 < geertu> - RCar Gen3 GPIO driver +09:28 < geertu> - Board cleanup (remove ad-hoc pinmux and gpio setup) +09:28 < geertu> - Fix xHCI stack in U-Boot to work with renesas xhci controller +09:28 < geertu> - Pending +09:28 < geertu> - xHCI driver (firmware licensing discussion, see B) ) +09:28 < geertu> B) What problems I have (U-Boot) +09:28 < geertu> - SD/MMC maintainer is not responding for over a month, my switch +09:28 < geertu> from sh-sdhi (horrible driver) to uniphier-sd (nice driver) is +09:28 < geertu> blocked +09:28 < geertu> - xHCI firmware discussion -- me, Geert and Tom Rini (u-boot head +09:28 < geertu> maintainer) think it is OK to bundle the firmware with U-Boot as +09:28 < geertu> the license permits it apparently. +09:28 < geertu> C) What will I do till next time (U-Boot) +09:28 < geertu> - Pester SD/MMC maintainer more, escalate further +09:28 < geertu> - Revisit SD/MMC HS200/H400/SDR104 patchset +09:28 < geertu> - D3 support +09:28 < geertu> - Post xHCI driver once the firmware discussion concludes +09:28 < geertu> ANy news from Magnus? On a plane to JP? +09:29 < geertu> Topic 2. Discussion Topics +09:29 < geertu> Anything to discuss during the last minute? +09:29 < morimoto> neg: can you show me its register name please ? +09:29 < shimoda> THSCP +09:29 < neg> morimoto: in BSP it is called THSCP +09:29 < morimoto> thanks +09:30 < neg> shimoda: :-) +09:32 < shimoda> :) +09:32 < shimoda> i checked errata doc, but it doesn't have it, so morimoto-san or i should ask hw team about this +09:33 < neg> shimoda: OK thanks +09:33 < geertu> We're slowly moving into the I/O area. +09:33 * geertu passes the mic to wsa_ diff --git a/wiki/Chat_log/20170921-io-chatlog b/wiki/Chat_log/20170921-io-chatlog new file mode 100644 index 0000000..21fdebf --- /dev/null +++ b/wiki/Chat_log/20170921-io-chatlog @@ -0,0 +1,66 @@ +09:34 < wsa_> so, let's continue with the IO meeting +09:34 < wsa_> I will do the summarized status updates. Please speak up after that in case I missed something. Then, discussion topics +09:34 < wsa_> a) +09:34 < wsa_> Uli got HSCIF variable timeout to work, Geert fixed a race in an older ethernet driver, Shimoda-san works on fixing a spinlock recursion in f_printer, Wolfram sent out series for eMMC drive strength and I2C core DMA helpers and investigated SDR104 issues (besides doing IO group related stuff like additional tasks) +09:35 < wsa_> b) +09:35 < wsa_> Uli will work on HSCIF receive margin, Niklas wants to test the SDIO-UHS card on Koelsch (yay!), Shimoda-san continues to fix USB issues, Wolfram will continue to work on topics mentioned in A) +09:35 < wsa_> c) +09:35 < wsa_> Shimoda-san is blocked by HW issues with role swap & battery charging, and Wolfram really has to do taxes now :( +09:35 < wsa_> ah, i forgot simon who replied to an old mail thread ;) +09:36 < wsa_> he worked on EtherAVB IP csum offloading, right? +09:36 < horms> Simon posted RAVB RX checksum offload pathes and will repost soon +09:36 < horms> No issues on that front +09:36 < wsa_> nice +09:37 < wsa_> anything I missed? +09:37 < horms> Is SDR104/SDIO taxing you? +09:38 < neg> speeding ticket :-) +09:38 < wsa_> I wish but it is the German state ;) +09:38 < wsa_> haha +09:39 < horms> We can compare notes in another forum :) +09:39 < wsa_> so, for the discussion topics, I'd like to start with add. tasks +09:40 < wsa_> I sent 6 of them out for 4Q and so far all involved people seem to be happy, right? +09:40 < horms> Ack +09:40 * geertu happy +09:41 < wsa_> neg: what was the consensus of the etheravb mtu task in san sebastian? did we move it to q1/2018 or delayed it to somewhen? +09:41 < neg> wsa_: delayed to somewhen I'm afriad but 2018/q1 is a possibility I would say +09:42 < wsa_> shimoda: ulrich has a D3 integration task. Because he is not here now, I will reply to your mail about D3. Just making sure the work is nicely distributed. +09:43 < wsa_> neg: and we wanted to check Gen2 first before deciding to go for 2k or 4k, right? +09:44 < wsa_> so, in general add. tasks seem fine. pity that magnus can't be here today but I assume things are going their way... +09:44 < neg> wsa_: yes and understand the potential HW limit which might limit us to ~2k +09:44 < wsa_> ok, thanks +09:45 < shimoda> wsa_: i got it. thanks! +09:45 < wsa_> i have one more topic about the upport list +09:45 < wsa_> there are TONS of patches in the BSP adding stuff to the DTS files +09:46 < wsa_> finding the upstream commits for that is time consuming +09:46 < wsa_> we used to have Kaneko-san to support us with this +09:46 < horms> hi +09:47 < wsa_> but I don't know the status of this new list and Simon's old list +09:47 < wsa_> and if we can benefit there somehow +09:47 < horms> Kaneko-san has been continuing his work in the maner as before. Its not clear to me what the relationship between that work and the upport list should be. But I am open to discussion. +09:48 < wsa_> i see +09:48 < geertu> esp. if you consider H3 ES1.x vs. ES2.0 +09:48 < wsa_> i'd propose having a meeting about that +09:48 < horms> Yes, I'm aware of this +09:49 < horms> the work Kaneko-san has been doing gives me a vary long list of changes +09:49 < wsa_> maybe in 2 weeks? +09:49 < horms> wsa_: some days I am a meeting +09:49 < horms> who should be involved? +09:50 < horms> From my pov Morimoto-san is a key person in this discussion +09:50 < wsa_> group leaders + morimoto-san + (shimoda-san?) + magnus +09:50 < shimoda> yes, i'd like to join upport things +09:51 < horms> ok, I'd like to be invited to +09:51 < wsa_> sorry, simon, you *of course*, too +09:51 < horms> :) +09:52 < wsa_> so, let's schedule a meeting for this in 2 weeks and I'll send out an introductory mail before to get the topic warmed up +09:52 < horms> I think the agenda should be something like: 1) How to better use and update the upport list 2) Appropriateness of involving Kaneko-san in this activity +09:52 < horms> Ok, in general this time of day is good for me. +09:52 < wsa_> horms: sounds good +09:52 < geertu> ok +09:53 < wsa_> that's all from my side, anything left from your side? +09:54 < morimoto> horms: sounds good for me too +09:54 < horms> wsa_: my side has nothing on it +09:56 < wsa_> then, i think we are done! +09:56 < wsa_> thanks, guys! +09:56 < shimoda> thanks! +09:56 < horms> thanks! +09:56 < wsa_> pinchartl: the stage is yours diff --git a/wiki/Chat_log/20170921-mm-chatlog b/wiki/Chat_log/20170921-mm-chatlog new file mode 100644 index 0000000..bd2376f --- /dev/null +++ b/wiki/Chat_log/20170921-mm-chatlog @@ -0,0 +1,175 @@ +Multimedia-chat-meeting-2017-09-21 + +09:54 < pinchartl> good morning everybody +09:54 < pinchartl> welcome to the multimedia group meeting +09:54 < pinchartl> topics for today are +09:55 < pinchartl> - status check for the multimedia tasks +09:55 < pinchartl> - additional tasks for Q4 +09:55 < pinchartl> - next meeting +09:55 < pinchartl> we will follow this meeting with a discussion about the gmsl cameras +09:55 < pinchartl> let's get started +09:55 < pinchartl> Topic 1. Status check for the multimedia tasks +09:55 < pinchartl> in alphabetical order, jmondi is first +09:55 < pinchartl> (with a lengthy report it seems) +09:57 < pinchartl> it seems we have lost Jacopo +09:58 < pinchartl> I'll copy & paste from the e-mail report +09:58 < pinchartl> since last meeting +09:58 < pinchartl> - Prepared support requests for Omnivision and Maxim +09:58 < pinchartl> (available in the OSDR wiki) +09:58 < pinchartl> the request has been sent to Omnivision, we will handle Maxim next +09:59 < pinchartl> - max9286: Implement links status monitoring +09:59 < pinchartl> - max9286: Adjusted timings to match datasheets +09:59 < pinchartl> - max9286: add additional checks to s_stream() startup routine +09:59 < pinchartl> - max9286: implement broadcast communications with serializer +10:00 < pinchartl> Jacopo reported achieving frame synchronization lock with this, but it seems that not everything is good under the sun, we'll discuss this next +10:00 < pinchartl> for the next two weeks: +10:00 < pinchartl> - Keep testing/investigating on max9286 frame synchronization and capture +10:00 < pinchartl> - Re-start CEU development on the mighty gr-peach +10:01 < pinchartl> issues and blockers: +10:01 < pinchartl> - max9286 & rdacm20 patches are scattered between different branches +10:02 < pinchartl> the next issue listed in the e-mail report is technical, we'll discuss it during the GMSL discussiong after the status update +10:02 < pinchartl> that's for for Jacopo +10:02 < pinchartl> kbingham: your turn +10:02 < kbingham> Morning :) +10:03 < kbingham> So - since #PeriPeriSanSeb, I have fixed suspend and resume on the DU :) \o/ +10:03 < kbingham> And Ive done some work on the new DU KMS-Test ... test suite +10:04 < kbingham> And (for the later topic on GMSL) I now have an RDACM20 'breakout' board ... +10:04 < kbingham> More interestingly - I now have a scope - and I'm looking for a reason to use it :D +10:04 < kbingham> which brings us into what will I do next... +10:04 < jmondi> uh! missed the notification! +10:05 < jmondi> thanks Laurent for impersonating me +10:05 < kbingham> I have some more review comments to finish up the TLB-optimisations work so I hope to post a v4 , and I have some more work to do on the KMS-Test suite. +10:06 < kbingham> That then brings us towards 'Q4' work - where I beleive possibly the first task for me from that will be the MAX9271 dump tool (pending discussions later) +10:06 < kbingham> Thats pretty much EOT for me. +10:06 < pinchartl> thank you +10:07 < pinchartl> next is me +10:07 < pinchartl> Since last meeting: +10:07 < pinchartl> - Linux Plumbers Conference +10:07 < pinchartl> - Started looking into FCP near-lossless compression +10:07 < pinchartl> For the next two weeks: +10:07 < pinchartl> - Complete the FCP nearl-lossless compression prototype +10:07 < pinchartl> - Assist with the GMSL camera development +10:07 < pinchartl> - Patch review +10:07 < pinchartl> - Embedded Recipes and Kernel Recipes conferences (26-29 of September in +10:07 < pinchartl> Paris) +10:07 < pinchartl> Issues and Blockers: None +10:07 < wsa_> gotta leave, next appointment... have a nice day all! +10:07 < pinchartl> next, Magnus, who's not here and hasn't reported by e-mail +10:08 < pinchartl> neg: is Magnus still at your place having fika ? +10:08 < neg> pinchartl: no :-( +10:09 < neg> He was heading to some sort of party so maybe he got lost during the event +10:09 < pinchartl> right +10:09 < pinchartl> in that case, next, morimoto +10:09 < morimoto> ok +10:09 < morimoto> A) What have I done since last time +10:09 < morimoto> - export paper work of V3M/D3 for EuroPeri +10:09 < morimoto> - start buying process for 8ch Camera / Cable +10:09 < morimoto> - I forwarded question mail to Omnivision, but no response yet. I sent ping mail to him +10:09 < morimoto> - continue ALSA SoC framework cleanups +10:09 < morimoto> - Became EuroPeri's father +10:09 < morimoto> B) What I plan to do till next time +10:09 < morimoto> - re-post ALSA SoC framework patch set. because, 2 weeks past, and nothing happen. +10:09 < morimoto> - paper work ? +10:10 < morimoto> C) Problems I have currently +10:10 < morimoto> - suddenly I had some children +10:10 < morimoto> - No response from Omnivision +10:10 < morimoto> I will ship V3M x2, and D3 x2 in few weeks (?). +10:10 < morimoto> And I will buy camera x16, but which camera should I buy ? +10:10 < morimoto> RDACM20 ? or RDACM21 ? or EuroPeri can buy it by yourself ? +10:10 < morimoto> --EOF-- +10:10 < pinchartl> I'll inform my father that you're replacing him, I'm not sure he will be happy +10:11 < morimoto> my father = whom :) ? +10:11 < pinchartl> my biological father :-) +10:11 < neg> haha "suddenly I had some children" :-) +10:11 < pinchartl> regarding Omnivision, do you plan to ping them, or should we wait a bit more ? +10:12 < morimoto> I sent ping to him. +10:12 < morimoto> already. Japan will have holiday tommorow +10:12 < jmondi> morimoto: thanks +10:12 < pinchartl> thank you +10:12 < neg> I'm also wondering about RDACM20 vs RDACM21 +10:12 < morimoto> thus, if no response on next Mon, I will call him +10:12 < pinchartl> regarding the RDACM20 vs RDACM21 +10:13 < pinchartl> as I understand, our new target should be the RDACM21 +10:13 < morimoto> BSP team (demo) is using 20, KF team want to use 21 +10:13 < jmondi> (for omnivision, and for the pocket money I'm gonna ask you since when you've become my dad) +10:13 < pinchartl> but supporting it might not be easy, the camera is very different +10:13 < pinchartl> I want to keep using the RDACM20 for internal development until we get it working in a stable way +10:13 < pinchartl> then we can switch to the RDACM21 +10:13 < pinchartl> I think we have enough RDACM20 cameras for now +10:14 < pinchartl> so we can buy RDACM21 +10:14 < neg> would it make sens to break out the max9271 as a separat driver at a later point ti support both 20 and 21? +10:14 < pinchartl> I will contact Global IMI today to see if we can buy them ourselves +10:14 < pinchartl> neg: possibly, but later :-) +10:15 < neg> pinchartl: ofc, we need to make it work first :-) +10:15 < morimoto> pinchartl: if Global IMI was OK, you can buy it by yourself, and no shipping from Japan is OK ? +10:15 < morimoto> if Global was NG, shipping is needed +10:16 < jmondi> neg: are you anxious to exercize arbitrary long pipeline of devices? (ov10635->max9271->max9286->csi2->vin) +10:16 < pinchartl> yes, if we can buy it, it will be easier +10:16 < jmondi> that's a good showcase for subnotifiers +10:16 < neg> jmondi: yes ! +10:16 < pinchartl> next in the list, neg +10:16 < morimoto> pinchartl: nice to know. so please let me know Global IMI's answer +10:17 < neg> A) +10:17 < neg> - [PATCH v6 00/25] rcar-vin: Add Gen3 with media controller +10:17 < neg> - [PATCH v2] device property: preserve usecount for node passed to +10:17 < neg> of_fwnode_graph_get_port_parent() +10:17 < neg> - [PATCH 0/4] GMSL link stabilization +10:17 < neg> I can now reliably probe and capture from all 8 cameras using the +10:17 < neg> maxim expansion board! +10:17 < neg> - Talked with Sakari and he have agreed to incorporate some of my +10:17 < neg> v4l2 async subnotifier work into his series and push that forward +10:17 < neg> as a part of his '[PATCH v13 00/25] Unified fwnode endpoint +10:17 < neg> parser, async sub-device notifier support, N9 flash DTS'. +10:17 < neg> Hopefully this will make it into the media tree soon clearing the +10:17 < neg> dependencies for the rcar-csi2 driver. +10:17 < neg> B) +10:17 < neg> - Rebase Gen3 rcar-vin and rcar-csi2 work ontop of Sakari's +10:17 < neg> subnotifer series and if his work is accepted in to the media tree +10:17 < neg> post new versions of those series. Hopefully the rcar-csi2 driver +10:17 < neg> have then cleared all dependencies! +10:17 < neg> - Rebase the multiplexed media pad work on top of other work done by +10:17 < neg> Sakari and repost the series. +10:17 < neg> - Keep poking at the 8 camera setup. +10:17 < neg> C) +10:17 < neg> - Unclear which camera module is target for the King Fisher setup, +10:17 < neg> will it be RDACM21-01 or RDACM20-01? +10:17 < neg> EOT +10:18 < neg> I also have a question for pinchartl, when do you plan to work on the ioctl shutdown for v4l2. No rush from my side only want to be ready for it :-) +10:18 < pinchartl> I think Morimoto-san answered your last question +10:18 < neg> Yes +10:19 < morimoto> neg: KF want to use 21 +10:19 < neg> morimoto: thanks +10:19 < pinchartl> likely the week after next, when I'll be back from Paris +10:19 < neg> pinchartl: nice, thanks +10:20 < pinchartl> next is Ulrich, who is excused +10:20 < pinchartl> from his e-mail report +10:20 < pinchartl> Since last meeting: +10:20 < pinchartl> - Sent fixup for Salvator backlight regulator warning. +10:21 < pinchartl> For the next two weeks: +10:21 < pinchartl> - Get the Chromebook display working. +10:21 < pinchartl> that's it for the status report +10:21 < pinchartl> Topic 2. Additional tasks for Q4 +10:21 < pinchartl> I will submit the additional tasks we have discussed in San Sebastian to Magnus this week +10:22 < pinchartl> if he emerges alive from his party they should be processed soon +10:22 < pinchartl> Topic 3. Next meeting +10:22 < pinchartl> I propose two weeks from now, on October the 5th +10:23 < pinchartl> same time as today, starting with core, I/O and multimedia +10:23 < pinchartl> with multimedia at 09:00 GMT / 10:00 CEST / 11:00 EEST / 17:00 JST +10:23 < pinchartl> geertu: is that fine with you ? +10:23 < pinchartl> Wolfram is gone so I assume he's fine :-) +10:23 < neg> 5th works for me +10:24 < morimoto> 5th doesn't work for me. but you can ignore me +10:24 < shimoda> 5th is ok to me +10:25 < geertu> pinchartl: 2017-10-05 is fine for me +10:25 * kbingham is available on the 5th +10:26 < jmondi> fine with me! +10:26 < pinchartl> morimoto: you have an official reason to ignore the meeting :-) +10:26 < morimoto> nice :9 +10:26 < geertu> Alternatively, we could skip one week, so the meeting thereafter is in Prague? +10:28 < shimoda> sorry i have other meeting. so see you next time! +10:28 < pinchartl> that's an option too, but I'm not sure we'll have a real meeting in Prague +10:28 < pinchartl> shimoda: no worries. thank you for attending +10:30 < morimoto> now finished ?? +10:30 < pinchartl> that's it for today then +10:30 < pinchartl> thank you all for attending +10:30 < morimoto> Thanks diff --git a/wiki/Chat_log/20171005-core-chatlog b/wiki/Chat_log/20171005-core-chatlog new file mode 100644 index 0000000..1c43b17 --- /dev/null +++ b/wiki/Chat_log/20171005-core-chatlog @@ -0,0 +1,219 @@ +Core-chat-meeting-2017-10-05 + +09:48 < geertu> Welcome to today's core group meeting. +09:48 < kbingham> and various people leave the room :D +09:48 * pinchartl has to go for one hour +09:48 * kbingham hides +09:48 < geertu> Given the small amount of time left, OK if I just summarize the copy-and-paste received status reports? +09:49 < geertu> A) What have I done since last time: +09:49 < geertu> +09:49 < geertu> Geert: +09:49 < geertu> - Sent patch to fix new unwind warnings with CONFIG_DEBUG_LOCK_ALLOC=y, +09:49 < geertu> - Sent v1 of sh-pfc suspend/resume, +09:49 < geertu> - Sent first pull requests for clk and pfc for v4.15, +09:49 < geertu> Jacopo: +09:49 < geertu> - Some small patches for Gr-Peach +09:49 < geertu> Marek (U-Boot): +09:49 < geertu> - Got more patches applied to u-boot-sh/rmobile, PR pending +09:49 < geertu> http://git.denx.de/?p=u-boot/u-boot-sh.git;a=shortlog;h=refs/heads/rmobile +09:49 < geertu> - Worked on the SDIF SDR104/HS200 support based on out-of-tree +09:49 < geertu> patchset (for now): +09:49 < geertu> - added support for the SDR104/HS200 calibration to the uniphier-sd +09:49 < geertu> driver +09:49 < geertu> - added support for pin voltage switching to PFC driver (POCCTRL) +09:49 < geertu> - added proper regulator handling to uniphier-sd +09:49 < geertu> - Worked on HS400, but that's still not ready +09:49 < geertu> Morimoto: +09:49 < geertu> - V3M/D3 shipping paper work +09:49 < geertu> Shimoda: +09:49 < geertu> - Submitted the following patches: +09:49 < geertu> * Add PWM entries of PFC for r8a77995. +09:49 < geertu> * Add USB3.0 entries of PFC for r8a7795{-es1} and merged. +09:49 < geertu> * Fix avb_pins for salvator-common, ulcb and draak. +09:49 < geertu> Remarks: "*" means merged into the subsystem repo. +09:49 < geertu> - I obtained a R-Car M3-N SiP, but I don't got bootloader yet. +09:49 < geertu> Simon: +09:49 < geertu> - Continued addressing review of CPUFreq patches +09:50 < geertu> B) What I plan to do till next time +09:50 < geertu> Geert: +09:50 < geertu> - v3 of cpg-mssr suspend/resume, +09:50 < geertu> - Fix genpd for wake-up devices. +09:50 < geertu> Marek (U-Boot): +09:50 < geertu> - Finish HS400 support +09:50 < geertu> - Finish sorting up remaining PCIe patches from the BSP (mostly +09:50 < geertu> suspend/resume support) +09:50 < geertu> Morimoto: +09:50 < geertu> - continue V3M/D3 paper work +09:50 < geertu> Niklas: +09:50 < geertu> - Send v2 of 'rcar_gen3_thermal: fix initialization sequence for H3 ES2.0' +09:50 < geertu> Shimoda: +09:50 < geertu> - Add usb3.0 phy device node for r8a779[56].dtsi after the usb3 peri +09:50 < geertu> supported a generic phy. +09:50 < geertu> - Prepare M3-N Salvator-X board for remote access if I obtain the +09:50 < geertu> bootloader. +09:50 < geertu> Simon: +09:50 < geertu> - Finalise addressing review of CPUFreq patches and repost +09:50 < geertu> C) Problems I have currently +09:50 < geertu> [Here I'll add breaks, in case people want to discuss] +09:51 < geertu> Jacopo: +09:51 < geertu> - Not really an issue to discuss with the whole group, but I keep seeing +09:51 < geertu> the GR-Peach hanging on sleeps longer than 1ms. I suspect this is also +09:51 < geertu> why ETHER is not working, and I had to substitute all sleep functions in +09:51 < geertu> the image sensor driver I am currently using to develop CEU with for +09:51 < geertu> loops of udelay(10). I blame XIP for this, but I'm currently not sure. +09:51 < geertu> Suggestions on how to debug and prove this are welcome :) +09:51 < geertu> jacopo: ? +09:51 < dammsan> use migo-r =) +09:51 < geertu> Does it work on Genmai? +09:51 < dammsan> (i don't dislike gr-peach support though) +09:52 < jmondi> geertu: here I am +09:52 < jmondi> never seen anything like this on genmai +09:52 < jmondi> but seems like sleeps longer than 1ms hang the board +09:53 < dammsan> which timer do you use? +09:53 < geertu> Peach doesn't have rtc_x1_clk in the DTS? +09:53 < jmondi> dammsan: as system clock? +09:53 < jmondi> geertu: no, no RTC +09:54 < geertu> The dmesg should tell you (compare genmai and peach) +09:54 < jmondi> not just in dts, not RTC at all on the board +09:54 < dammsan> rtc != clockevent != clocksource +09:55 < wsa_> marex-cloud: the PCIE patches you mentioned, are these for U-Boot or Linux? +09:55 < jmondi> let me look through dmesg +09:55 < dammsan> a single clockevent used to be enough to run the kernel +09:55 < Marex> wsa_: Linux, mostly suspend support +09:55 < dammsan> but the twd on CA9 used to exist only in case of multi-core +09:55 < dammsan> so instead of local timer i'm not sure what is used +09:56 < geertu> rskrza1 and genmai enable mtu2, peach doesn't +09:56 < dammsan> there you go +09:56 < wsa_> Marex: nice! did you send out patches already? I don't see any on the renesas-soc list. +09:56 < Marex> wsa_: I have them rebased to -next since a few days ago, I need to understand what some of them are doing +09:56 < geertu> rskrza1 enables ostm[01], peach and genmai don't +09:56 < wsa_> Marex: I can imagine :) +09:57 < geertu> Ok, issue assumed fixed until proven otherwise soon :-) +09:57 < Marex> wsa_: there's one which digs in the PCIe core , but not much details in the commit message +09:57 < geertu> Marek: +09:57 < geertu> - HS400 calibration doesn't pass on Salvator-XS for me in U-Boot, +09:57 < geertu> but that's because I'm doing something wrong, it works in Linux +09:57 < jmondi> geertu: dammsan: I lost you two +09:57 < jmondi> I'm so ignorant on this +09:57 < geertu> Marex: if you want to discuss this, I think I/O is more appropriate +09:58 < dammsan> jmondi: your timer configuration on gr-peach is incomplete +09:58 < geertu> jmondi: seacrh for mtu and ostm in the varipus r7s72100 DTS +09:58 < Marex> geertu: ACK, I have feedback from wsa_ , need to check it on real board +09:58 < geertu> Marex: OK +09:58 < geertu> Shimoda: +09:58 < geertu> - I got a request from BSP team about upstreaming of MFIS hwspinlock +09:58 < geertu> feature. +09:58 < geertu> - But, the current implementation is not good for upstreaming, I think. +09:58 < geertu> I have 3 concerns: +09:58 < geertu> 1) The device nodes ("mfis" and "mfis-lock") are duplicated like +09:58 < geertu> below... +09:58 < geertu> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795.dtsi?h=v4.9/rcar-3.5.8#n875 +09:58 < geertu> 2) The BSP team would like to support "MFIS lock register 8" in +09:58 < geertu> the future, but the register area is separated from "MFIS lock +09:58 < geertu> register [0-7]". +09:58 < geertu> 3) The "mfis" driver for rpmsg (Remote Processor Messaging) will +09:58 < geertu> be not upstreaming for now. +09:58 < geertu> - This module has two (or more) features and BSP supports the following +09:58 < geertu> features: +09:58 < geertu> 1) hwspinlock +09:58 < geertu> 2) rpmsg (Remote Processor Messaging) +09:58 < geertu> - My concern point is how to make the device node for it. +09:58 < geertu> - In my opinion, it should be a mfd driver like below: +09:58 < geertu> mfis { +09:58 < geertu> reg = <0 0xe6260000 0 0x1000>; +09:58 < geertu> hwspinlock { +09:58 < geertu> ... +09:58 < geertu> }; +09:58 < geertu> rpmsg { +09:58 < geertu> ... +09:58 < geertu> }; +09:58 < geertu> }; +09:58 < geertu> - But, what do you think? +09:58 < geertu> shimoda: I had a quick look at the DTS patch +09:59 < geertu> mfis-lock covers lock registers 0-7 +09:59 < geertu> The mfis node covers all registers in the first 0x200 byts, but the only registers there are the same lock registers? +09:59 < jmondi> dammsan: geert: will do.. in the meantime fyi: https://paste.debian.net/989118/ +10:00 < wsa_> Marex: and don't hesitate to forward questions to the BSP team via Shimoda-san or Morimoto-san +10:00 < shimoda> geertu: the mfis node is for rpmsg +10:00 < geertu> shimoda: Using the same lock registers? Or are there undocumented registers in that block? +10:01 < geertu> You can have multiple register blocks in a single reg property, cfr. the gic nodes +10:01 < Marex> wsa_: will do if anything pops up +10:01 < shimoda> the out of tree driver of mfis driver for rpmsg will not use the same lock registers. Yes, there is undocumented registers for now +10:01 < geertu> You can just have a single one, too (cfr. your "reg = <0 0xe6260000 0 0x1000>") +10:02 < Marex> wsa_: the HS400 was just a quick test bolted on top of HS200 +10:02 < geertu> A single driver can be both a hwspinlock and and rpcmsg provider, without using MFD, I think. +10:03 < geertu> Cfr. the CPG/MSSR driver, which is clk provider (for the clocks), genpd provider (for the clock domain), and reset controller (for module resets) +10:05 < shimoda> geertu: but, they make two drivers (hwspinlock and rpmsg) and two device nodes now +10:05 < geertu> shimoda: Two overlapping device nodes is a definite no-go +10:06 < shimoda> geertu: yes, I know. but bsp team doesn't know... +10:06 < geertu> shimoda: So you should tell them, so they know ;-) +10:07 < shimoda> geertu: yes, I should do so :) +10:07 < geertu> jmondi: timer_probe: no matching timers found +10:07 < geertu> jmondi: while my last boot on genmai of v4.9 said: +10:07 < geertu> sh_mtu2 fcff0000.timer: ch0: used for clock events +10:07 < geertu> sh_mtu2 fcff0000.timer: ch0: used for periodic clock events +10:08 < jmondi> geertu: yes... If I got this right, without MTU2 all clock events used for wake ups are not generated +10:08 < jmondi> so the only working methof for sleeping is busy waiting, as udelay does +10:09 < shimoda> about this mfis topic, bsp team don't want to make a single driver to support a hwspinlock and rpmsg, especially rpmsg. But, I'll forward this infor and discuss how do we do. Thanks! +10:09 < geertu> shimoda: Do you need any special properties in the hwspinlock and rpmsg nodes from your proposal? +10:09 < jmondi> I'm now testing it, just need to remove my workarounds in sensor driver code +10:10 < dammsan> shimoda: isn't hwspinlock vs rpmsg assignment software policy? +10:11 < shimoda> geertu: I don't need any special properties, I think. But, BSP team concern, M3-W and H3 ES1.x has only 8 locks, but other SoCs has 64 locks +10:11 < shimoda> s/BSP team concern/BSP team has concern/ +10:11 < geertu> That can be handled by the driver based on the renesas,mfis-<soctype> compatible value, right? +10:12 < geertu> (no, "renesas,<soctype>-mfis") +10:12 < shimoda> dammsan: I think so, BSP team wants hwspinlock to go to upstream, but rpmsg is no-go because this is related to undocumented +10:13 < jmondi> geertu: damsan: no more hangs... trying yout ETHER now... thank you both so far :) +10:13 < dammsan> i see. i think mfis has existed even on mobile platforms +10:13 < geertu> dammsan: Indeed, on all SoCs we still support, I think. +10:13 < dammsan> register layout in such case seemed similar to msiof but it was used for mailbox communication between cou coes +10:14 < dammsan> i mean cpu cores +10:14 < shimoda> geertu: i think so. but also need soc_device_match for H3 ES2.0 +10:14 < dammsan> but anyway, good with hwspinlock +10:14 < geertu> We're running out of time. Anything else related to this topic? +10:14 < geertu> Simon: +10:14 < geertu> - Correct handling of PLL dividor for CPUFreq +10:15 < geertu> horms: Do you want to discuss this here? +10:15 < horms> I think I should do some more investigation. Perhaps we can chat about it on this channel some time? +10:16 < geertu> OK. +10:16 < dammsan> FYI, i'm adding a silk board for remote access now +10:16 < geertu> Anything I missed in the status reports? +10:16 * Marex steals a bit of time, OK? +10:17 < horms> dammsan: great, can you give me access if its not already oversubscribed? +10:17 < dammsan> sure +10:17 < dammsan> i'll announce the reshuffled boards via email, lets take it from there +10:17 < geertu> Marex: Core related? I should hand over the mic to Wolfram... +10:17 < Marex> shimoda: I sent out the xhci patch I plan to submit to the U-Boot list to the periperi list first, the license grant should be OK, can you double-check please ? +10:18 < Marex> geertu: well it's inbetween, U-Boot is core and xhci is IO +10:18 < shimoda> Marex: sure, I will check it +10:18 < Marex> shimoda: thank you ! +10:18 < Marex> shimoda: it'd be convenient if this worked out, since now I can just type "usb reset" and it works :) +10:19 < Marex> shimoda: it's hassle-free +10:19 < shimoda> Marex: nice! :) +10:20 < wsa_> geertu: don't worry, I am fine +10:20 < Marex> shimoda: btw re HS200/400 and SDR104, I am a bit blocked by the SD/MMC maintainer in U-Boot, sorry about that +10:20 < Marex> shimoda: he's not picking patches as fast as I'd like him to +10:20 < Marex> shimoda: I'm looking for ways to ... uh ... expedite that process +10:21 < shimoda> Marex: i got it. thanks! +10:21 < Marex> shimoda: you're welcome, I'll keep you updated +10:22 < wsa_> Marex: is yamada-san working on this, too? +10:22 < Marex> wsa_: Masahiro Yamada-san ? +10:22 < wsa_> hai +10:22 < Marex> wsa_: he works for socionext, although he did implement the uniphier-sd which I now use on RCar Gen3 +10:22 * neg brb 2 min +10:22 < Marex> wsa_: their block doesn't support the HS200/400/SDR104 modes though, that's renesas specific +10:23 < Marex> wsa_: so he just reviews my uniphier-sd patches (which is nice) and makes sure they work on both +10:23 < wsa_> I see +10:24 < Marex> wsa_: the blocker really is the SD/MMC subsystem maintainer, he just doesn't respond much +10:24 < Marex> wsa_: some not long time ago I was really tempted to just replace him and start handling the SDMMC stuff myself +10:25 < Marex> wsa_: but then he came back, at like 5 mins to 12 and rolled out a PR ... +10:25 < wsa_> how about co-maintaining? +10:25 < Marex> wsa_: I feel like I'm hoarding functions ;-) +10:26 < wsa_> I see +10:26 < wsa_> that happens easily, yes +10:26 < Marex> wsa_: right +10:26 * neg back +10:26 < Marex> wsa_: and since U-Boot isn't as prestigeous as linux, maintainers don't really queue up to do it +10:27 < wsa_> okay +10:27 < Marex> wsa_: anyway ... maybe we should continue rather than complain about lack of manpower all over the place ? :) +10:27 < wsa_> ack diff --git a/wiki/Chat_log/20171005-io-chatlog b/wiki/Chat_log/20171005-io-chatlog new file mode 100644 index 0000000..05ef52a --- /dev/null +++ b/wiki/Chat_log/20171005-io-chatlog @@ -0,0 +1,121 @@ +10:17 < geertu> Marex: Core related? I should hand over the mic to Wolfram... +10:17 < Marex> shimoda: I sent out the xhci patch I plan to submit to the U-Boot list to the periperi list first, the license grant should be OK, can you double-check please ? +10:18 < Marex> geertu: well it's inbetween, U-Boot is core and xhci is IO +10:18 < shimoda> Marex: sure, I will check it +10:18 < Marex> shimoda: thank you ! +10:18 < Marex> shimoda: it'd be convenient if this worked out, since now I can just type "usb reset" and it works :) +10:19 < Marex> shimoda: it's hassle-free +10:19 < shimoda> Marex: nice! :) +10:20 < wsa_> geertu: don't worry, I am fine +10:20 < Marex> shimoda: btw re HS200/400 and SDR104, I am a bit blocked by the SD/MMC maintainer in U-Boot, sorry about that +10:20 < Marex> shimoda: he's not picking patches as fast as I'd like him to +10:20 < Marex> shimoda: I'm looking for ways to ... uh ... expedite that process +10:21 < shimoda> Marex: i got it. thanks! +10:21 < Marex> shimoda: you're welcome, I'll keep you updated +10:22 < wsa_> Marex: is yamada-san working on this, too? +10:22 < Marex> wsa_: Masahiro Yamada-san ? +10:22 < wsa_> hai +10:22 < Marex> wsa_: he works for socionext, although he did implement the uniphier-sd which I now use on RCar Gen3 +10:22 * neg brb 2 min +10:22 < Marex> wsa_: their block doesn't support the HS200/400/SDR104 modes though, that's renesas specific +10:23 < Marex> wsa_: so he just reviews my uniphier-sd patches (which is nice) and makes sure they work on both +10:23 < wsa_> I see +10:24 < Marex> wsa_: the blocker really is the SD/MMC subsystem maintainer, he just doesn't respond much +10:24 < Marex> wsa_: some not long time ago I was really tempted to just replace him and start handling the SDMMC stuff myself +10:25 < Marex> wsa_: but then he came back, at like 5 mins to 12 and rolled out a PR ... +10:25 < wsa_> how about co-maintaining? +10:25 < Marex> wsa_: I feel like I'm hoarding functions ;-) +10:26 < wsa_> I see +10:26 < wsa_> that happens easily, yes +10:26 < Marex> wsa_: right +10:26 * neg back +10:26 < Marex> wsa_: and since U-Boot isn't as prestigeous as linux, maintainers don't really queue up to do it +10:27 < wsa_> okay +10:27 < Marex> wsa_: anyway ... maybe we should continue rather than complain about lack of manpower all over the place ? :) +10:27 < wsa_> ack +10:29 < wsa_> geertu: can i take over? or did i already? :) +10:29 < geertu> wsa_: I think you already did +10:30 < jmondi> ETHER is working as well \o/ (sorry to jump in with random messages, is rude, but I'm happy, now the peach is a grown up baby!) +10:30 < wsa_> well, then: welcome to the already started io meeting :D +10:30 < wsa_> jmondi: no problem, but only for success messages ;) +10:31 < jmondi> wsa_: I would be mostly silent then :) +10:31 < wsa_> ok, i collected (and rephrased) the ABC questions +10:31 < wsa_> and added a comment here and there, here they go: +10:31 < wsa_> A) +10:31 < wsa_> * Geert worked on RAVB PHY reset to support supsend/resume +10:31 < wsa_> * Niklas did SDR104/SDIO tests on Koelsch +10:31 < wsa_> * Simon got the RAVB RX checksum offload patch merged +10:31 < wsa_> * Uli got the HSCIF HW timeout patch merged and resent the HSCIF sampling point shift patch +10:31 < wsa_> (the latter raised a few comments, though) +10:31 < wsa_> * Shimoda-san got f_printer driver merged and fixed quite some USB issues and added quite some +10:31 < wsa_> DT nodes, and added suspense/resume support for USB PHY +10:31 < wsa_> * Wolfram discussed add. tasks and upport lists, added I2C to Salvator-XS, resend the eMMC drive +10:31 < wsa_> strength patches, and commented on SDHI SDR104 tests and regulator patches +10:31 < wsa_> B) +10:31 < wsa_> * Geert will keep an eye to get RAVB PHY reset working and wants to tackle MSIOF again +10:31 < wsa_> (multiple chip selects, I assume?) +10:31 < wsa_> * Simon starts working on HS400 +10:31 < wsa_> (nice timing because Marek works on HS400 for U-Boot currently) +10:31 < wsa_> * I assume Uli will keep working on the sampling point patch? +10:31 < wsa_> * Shimoda-san works on the USBHS driver more if he gets feedback from HW team +10:31 < wsa_> * Wolfram wants to finalize the I2C DMA patches, improve the I2C fault injector and start +10:31 < wsa_> preparing the talk & showcase about it for ELCE, debug SDR104 on Gen2, and add. tasks +10:31 < wsa_> plus upport lists, of course. +10:31 < wsa_> C) +10:31 < wsa_> * Shimoda-san's patches for USB2.0 phy for r8a77995 got no feedback from PHY maintainer +10:31 < wsa_> * Wolfram wonders where all the time since San Sebastian has gone +10:32 < wsa_> please have a look if everything is correct or i missed something +10:33 < geertu> wsa_: German tax rate is how many %? ;-) +10:34 < wsa_> too many :D +10:35 < wsa_> it stops at 42% IIRC +10:35 < wsa_> okay, there don't seem to be any comments +10:35 < wsa_> other than taxes +10:35 < horms> HS400 will be fun, but the fun hasn't started yet. Tax is less fun, we can swap notes another time. +10:36 < Marex> horms: HS400 seems like HS200 DDR, why the worry ? +10:36 < wsa_> I don't really have other topics for now; I'd think the SDR stuff and the upport list discussion are better suited for emails currently +10:36 < wsa_> unless there is something you guys want to discuss right now +10:37 < horms> Marex: thanks for the encoragement :) +10:38 < Marex> horms: well I was serious, it doesn't seem all that different +10:38 < wsa_> at least we won't have "long cable" problems with HS400 :) +10:38 < Marex> ^_^' +10:38 < geertu> wsa_: Why not? +10:38 < wsa_> HS400 is eMMC only +10:38 < horms> eMMC is on the board +10:40 < wsa_> dammsan: do you need anything from me regarding add. tasks? +10:40 < geertu> UHS-III is even faster, and using actual cards? +10:41 < wsa_> looks like it +10:42 < wsa_> maybe microsd only, though +10:42 < Marex> wsa_: they use PCIe-like bus +10:42 < Marex> for UHS3 that is +10:43 < Marex> the full-size UHS3 cards have extra pads for that, differential ones +10:43 < Marex> I think the bus might even be PCIe compatible right away +10:43 < wsa_> heh +10:44 < Marex> well that's where it's all headed anyway +10:44 < wsa_> let's see what comes out of that :) +10:44 < Marex> USB3 and PCIe use the same physical layer, the SD probably joins that too +10:44 < Marex> shimoda: I just received USB3 Totalphase Beagle 5000 V2 :-3 +10:44 < wsa_> let's see how this will all end up in some R-Car Generation +10:45 < wsa_> but for now, it is SDR104 and HS400 :) +10:45 < wsa_> so, last call for topics from your side +10:46 < wsa_> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaand we are done! +10:46 < wsa_> Thank you guys! +10:46 < neg> thanks all +10:46 < shimoda> Marex: wow! nice! +10:46 < shimoda> thank you! +10:47 < jmondi> thank you all! +10:47 < Marex> thank you all! +10:47 < jmondi> neg: pinchartl: kbingham: catch you later +10:47 < uli__> see you +10:47 < horms> wsa_: were we going to talk about upporting about now? +10:48 < wsa_> i don't think so +10:48 < wsa_> i mean we can do +10:48 < wsa_> but i think it would be good to have morimoto-san here, too +10:48 < Marex> shimoda: jupp, so many hard-to-debug USB problems are hopefully fixed soon :) +10:48 < horms> Sure. Perhaps we can continue the discussion via email. +10:48 < wsa_> i'd suggest to keep discussing via email until then +10:49 < wsa_> ;D +10:49 < shimoda> Marex: I hope so :) +10:49 < horms> my question for you would be: do you think it would be more useful for Kaneko-san to help with keeping the upport list up to date, or to focus on upporting trivial patches +10:52 < wsa_> hmmm +10:53 -!- horms [~horms@217.111.208.18] has quit Quit: Leaving +10:55 < wsa_> seems this answer also needs to go via email... diff --git a/wiki/Chat_log/20171005-mm-chatlog b/wiki/Chat_log/20171005-mm-chatlog new file mode 100644 index 0000000..d22e4db --- /dev/null +++ b/wiki/Chat_log/20171005-mm-chatlog @@ -0,0 +1,191 @@ +Multimedia-chat-meeting-2017-10-05 + +09:04 < pinchartl> neg: you can start +09:05 < neg> A) +09:05 < neg> - Broke my 8 channel camera board by trying to measure the GMSL link with a scope. +09:05 < neg> - Repaired half my 8 channel camera board... I have one MAX9286 +09:05 < neg> working and have confirmed all 8 cameras working. +09:05 < neg> - Discovered that 3 out of 8 cameras needs auto ack on i2c from +09:05 < neg> MAX9286 to function. Reason for this unknown. +09:05 < neg> - Found issue with Sakari's subnotifier patchset for rcar-vin. Fix +09:05 < neg> is posted and seems like it is picked up. +09:05 < neg> - Got Acks from Hans on most VIN Gen3 patches, most of them are now +09:05 < neg> OK from Hans point of view. +09:05 < neg> B) +09:05 < neg> - Rebase VIN Gen3 patches and repost with Hans Acked-by. +09:05 < neg> - Try to rescue 8 camera board. +09:05 < neg> - If Laurents Kingfisher price information is OK from Renesas side +09:05 < neg> try to order one including camera boards. +09:05 < neg> - Rebase multiplexed pads on Sakari's patch series. +09:06 < neg> C) +09:06 < neg> - Lost a lot of working time on breaking and trying to restore the 8 camera board. +09:06 < neg> EOT +09:06 < pinchartl> thank you +09:06 < pinchartl> do you think it's worth it trying to rescue the second MAX9286 ? +09:06 < pinchartl> it's likely that the chip itself is dead +09:07 < neg> I think it's dead +09:07 < pinchartl> I wouldn't spend more time on that +09:07 < neg> So my focus now is to make sure I don't damage anything else while using "half" the board +09:08 < pinchartl> :-) +09:08 < neg> Yes, I have no plan to try and rescue the second MAX9286 :-) +09:08 < pinchartl> ok, thanks +09:08 < pinchartl> next, uli__ +09:09 < pinchartl> who should actually have gone first as I don't see any report through e-mail +09:09 < uli__> then you're not looking hard enough :) +09:09 * kbingham notices Uli got his report in before me :) +09:09 < uli__> anyway +09:10 < uli__> so i managed to fix the display on the Chromebook in mainline +09:10 < pinchartl> sorry, I might be having issues with my mail client :-( +09:10 < uli__> np +09:10 < uli__> panel didn't have regulators because of the weirdo device tree that deleted the correct description and replaced it with a bad one +09:11 < uli__> a lot of bisecting and two small hacks later it worked +09:11 < uli__> oh, and framebuffer console support was also missing +09:12 < uli__> (didn't know that was actually required...) +09:12 < pinchartl> :-) +09:12 < uli__> so that's really it. the only major hack remaining is the mmsys device that needs to be both a clock controller and a drm device +09:13 < uli__> nobody commented on that so far +09:13 < pinchartl> ok +09:14 < pinchartl> plans for the next two weeks ? +09:14 < uli__> fix some non-essential devices so i can use this thing myself :) +09:15 < uli__> that's as far as plans go for now +09:15 < pinchartl> I assume you'll start testing the GPU on mainline too ? +09:15 < pinchartl> (I found your e-mail now) +09:15 < uli__> that would be part of an additional task, right? +09:16 < pinchartl> yes +09:16 < pinchartl> they will come soon +09:16 < uli__> ok +09:16 < pinchartl> thank you +09:16 < pinchartl> next, kbingham +09:16 < wsa_> what WLAN device is used on that chromebook? +09:16 < uli__> moment, i'll take a look +09:17 < kbingham> Most of my time has been looking at 8camera probing and such. +09:18 < kbingham> I started by helping Jacopo investigate his FSYNC task - and also looking at the breakout camera. +09:18 < kbingham> Initially the breakout camera wasn't capturing anything ... and after trying various things we managed to capture from it. +09:18 * kbingham regrets not doing more testing on the camera at that stage as we then assumed it was fine. +09:19 < kbingham> So then we tried ... and I failed ... to capture anything from the I2C on the other side of the MAX9271 ... +09:20 < kbingham> Stashing that task to see if there were other issues - I investigated the 'stabilising probe' task - and that's when I discovered the alternate MAX9286 was auto-acking for devices on the other MAX. +09:21 < kbingham> Fixing that doesn't stop my cameras from probing (they already did) but does seem to hinder 3 of niklas' +09:21 < kbingham> So more investigation required there anyway. +09:21 < kbingham> I've also prepared a tool to capture the profile and status information from the RDACM20 cameras and parse it. +09:21 < kbingham> Other than a lot of sensor configuration it shows very little configuration to the MAX9271 +09:22 < kbingham> So ... next up ... Well - hopefully after this meeting we'll get together to discuss all of the current state and hte best next moves forwards. +09:22 < pinchartl> have you compared the profiles of all 8 cameras ? +09:22 < kbingham> I've compared 3. +09:22 < kbingham> They were the same. +09:23 < kbingham> I can do the full set if desired. +09:23 < kbingham> In fact it won't take long to do - so I'll do it today. +09:23 < pinchartl> it would be nice just to make sure +09:23 < pinchartl> neg: could you do the same with your cameras ? +09:24 < neg> yes +09:24 < pinchartl> thank you +09:25 < kbingham> Quickly finishing my status ... . Work next will be - discussed in todays meeting, as well as potetnitally looking at the DU/VIN loopback task before the next time I have a status update too :) +09:25 < kbingham> And my issues : +09:25 < kbingham> I need to check if I can publish code that parses the PROFILE of the cameras in case it conflicts with the NDA. +09:25 < kbingham> (I'll do that separately) +09:25 < kbingham> and I think I have broken the breakout camera. +09:26 < kbingham> Except ... I might not have ... +09:26 < kbingham> It might just not be responding - in exactly the same way that Niklas' three cameras require auto-ack ... (which I have disabled) +09:26 < kbingham> EOT from me. +09:26 < pinchartl> it would be nice if you could confirm that +09:27 < pinchartl> we have too much broken hardware already :-) +09:27 < pinchartl> thank you +09:27 < pinchartl> next, jmondi +09:27 < jmondi> here I go +09:27 < uli__> wsa_: marvell 8897 +09:27 < jmondi> A) -- fsync measurement with Kieran and his scope +09:28 < jmondi> --discussions and reviews on i2c stability +09:28 < wsa_> uli__: nice! that has upstream support :D +09:28 < jmondi> -- base respository for gmsl work +09:28 < jmondi> ceu: +09:28 < jmondi> -- resumed CEU development on GR-Peach +09:29 < jmondi> -- add OF parsing to already submitted ceu driver +09:29 < jmondi> -- some soldering and testing to add support for ov7670 camera board on gr-peach audiocamera shield +09:29 < jmondi> B) +09:29 < jmondi> -- capture on gr-peach +09:30 < jmondi> -- resume fsync investigation once i2c issues are mitigated +09:30 < jmondi> C) +09:30 < jmondi> -- could we sync how hw which we have to buy or will be shipped to us? +09:30 < jmondi> -- EOT +09:31 < pinchartl> thank you +09:31 < pinchartl> regarding hardware +09:31 < pinchartl> we need to buy the kingfisher camera setup ourselves +09:31 < jmondi> s/how/which +09:31 < pinchartl> that's the ULCB, the KF base board, the KF camera expansion board, cameras and cables +09:32 < pinchartl> I've started the process, ULCB is in back order, asked for a quote for KF, got quote for RDACM21 cameras and will buy cables +09:32 < pinchartl> at this point you don't need to do anything +09:32 < pinchartl> let's wait for the KF quote, and then we'll decide what to do, and who should buy hardware +09:32 < jmondi> pinchartl: thanks +09:33 < pinchartl> you're welcome +09:33 < pinchartl> next, Morimoto-san, who reported by e-mail +09:33 -!- Irssi: Pasting 7 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +09:33 < pinchartl> Since last meeting: +09:33 < pinchartl> - Customer requested Sound new feature (= MIX volume), I posted this support to ML, under review now. +09:33 < pinchartl> - Posted H3 ES2.0 / D3 audio PFC patch, under review now. +09:33 < pinchartl> - Re-posted ALSA SoC cleanup patch +09:33 < pinchartl> - V3M/D3 shipping paper work +09:33 < pinchartl> - Pinged MAXIM datasheet question, no response +09:33 < pinchartl> For the next two weeks: +09:33 < pinchartl> - Continue V3M/D3 paper work +09:33 < pinchartl> - Ping MAXIM datasheet question +09:33 < pinchartl> Issues and Blockers: +09:33 < pinchartl> - No response from ALSA maintainer, MAXIM... +09:34 < pinchartl> I assume s/MAXIM/Omnivision/ +09:35 < pinchartl> next, me +09:35 -!- Irssi: Pasting 5 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +09:35 < pinchartl> Since last meeting: +09:35 < pinchartl> - Completed the FCP near-lossless compression prototype +09:35 < pinchartl> - Assisted with the GMSL camera development +09:35 < pinchartl> - Embedded Recipes and Kernel Recipes conferences (September 26-29 in Paris) +09:35 -!- Irssi: Pasting 6 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +09:35 < pinchartl> For the next two weeks: +09:35 < pinchartl> - Finish the additional tasks descriptions for Q4 +09:35 < pinchartl> - More patch review +09:35 < pinchartl> - V4L2 lifetime management issues (for VIN Gen3 support) +09:35 < pinchartl> - Display color keying support for Gen3 +09:35 < pinchartl> Issues and Blockers: None +09:36 < pinchartl> next, dammsan +09:37 < pinchartl> silence... +09:37 < pinchartl> I assume I can copy & paste last week's report +09:38 < pinchartl> Since last meeting: None +09:38 < pinchartl> For the next two weeks: None +09:38 < pinchartl> Issues and Blockers: None +09:38 < pinchartl> :-) +09:38 < pinchartl> that's it for status updates +09:38 < pinchartl> as everybody is here, let's discuss the topic of the next meeting +09:38 < pinchartl> I propose not skipping the one two weeks from now, just before Prague +09:39 < pinchartl> there's no plan for a formal meeting in Prague at this time, even if most of us will be there +09:39 < pinchartl> so I'd rather have a status update meeting the week before, if only to avoid wasting time on it when we'll meet +09:39 < pinchartl> what do geertu and wsa_ think ? +09:39 < geertu> Fine for me +09:40 < geertu> wsa_: ? +09:41 < pinchartl> wsa_ seems to be AFK, I'll let him chime in if he thinks it's a bad idea +09:41 < wsa_> i m here +09:41 < pinchartl> welcome :-) +09:41 < wsa_> i agree with laurent +09:41 < pinchartl> thank you +09:41 < pinchartl> (uli__: I've found your e-mail, it was an issue on my side, sorry about that) +09:41 < uli__> again, np :) +09:42 < pinchartl> last topic for multimedia +09:42 < pinchartl> Niklas, Kieran and Jacopo would like to sync up on the 8 cameras work today +09:42 < pinchartl> what would be a good time for you all ? +09:42 < neg> I'm free all day +09:43 < pinchartl> I'll have to skip the core and I/O meeting I'm afraid, and will be back at 11:45 CEST. should we start then, or after lunch ? +09:43 < jmondi> I have to be away from ~1hr before lunch, then I'll be here +09:43 < jmondi> so I would prefer after lunch if that's fine with everyone +09:44 < pinchartl> kbingham: how about you ? +09:44 < kbingham> pinchartl: For me the sooner the better. +09:44 < kbingham> pinchartl: I'll make myself avaialble as soon as everyone else is. +09:44 < kbingham> (But I'm available all day) +09:45 < pinchartl> jmondi: when can you start ? +09:45 < jmondi> sorry for not being here in the morning, but this is the one time in years I have to show up in my bank branch to update the security device +09:45 < jmondi> after lunch, I plan to be back home not later than 1pm +09:46 < pinchartl> kbingham: 12:00 for you, is that OK ? +09:46 < kbingham> So 12pm GMT :) +09:46 < kbingham> pinchartl: Ack. +09:46 < kbingham> Wait - not GMT - BST :) +09:46 < pinchartl> :-) +09:46 < pinchartl> OK, let's do that then +09:46 < kbingham> Stupid timezones +09:47 < pinchartl> 12:00 BST / 13:00 CEST / 14:00 EEST +09:47 < pinchartl> that's it for the multimedia meeting +09:47 < pinchartl> thank you all for attending diff --git a/wiki/Chat_log/20171019-core-chatlog b/wiki/Chat_log/20171019-core-chatlog new file mode 100644 index 0000000..90bb268 --- /dev/null +++ b/wiki/Chat_log/20171019-core-chatlog @@ -0,0 +1,157 @@ +Core-chat-meeting-2017-10-19 + +09:41 < geertu> Welcome to today's Core Group Meeting +09:41 < neg> thanks wsa_ +09:41 < geertu> Agenda: +09:41 < geertu> 1. Status updates +09:41 < geertu> 2. Discussion Topics +09:41 < geertu> Topic 1. Status updates +09:41 < shimoda> neg: about v3m thermal, it's also the same with d3 +09:41 < geertu> I'll replay the reporting +09:41 < geertu> A) What have I done since last time +09:42 < geertu> Geert: +09:42 < geertu> - Enabled INTC-EX on R-Car H3 ES2.0, M3-W, and D3 (incl. pinctrl for +09:42 < geertu> H3 and M3-W), +09:42 < geertu> - Sent patches to enable BD9571MWV backup mode from sysfs, +09:42 < geertu> - Sent patches to add missing CPU clocks, +09:42 < geertu> - Sent v2 of renesas_defconfig, +09:42 < geertu> - Sent v3 of cpg-mssr suspend/resume, +09:42 < geertu> - Sent v2 of sh-pfc suspend/resume, +09:42 < geertu> - Sent first part of fixes for genpd for wake-up devices (network +09:42 < geertu> drivers). +09:42 < geertu> Jacopo: +09:42 < geertu> - More patches for Peach DTS (clock and timers, ethernet now working) +09:42 < geertu> Marek (U-Boot): +09:42 < geertu> - Got ACK on becoming SH co-maintainer to expedite patch acceptance +09:42 < geertu> - Posted SDR104/HS200 patches +09:42 < geertu> - Posted V2 and V3 of xHCI support for Gen3 and got ACK on it +09:42 < geertu> - Implemented D3 Draak and V3M Eagle board support +09:42 < geertu> - PFC, clock, DTS, board support are in place +09:42 < geertu> - untested yet due to HW access issues, but it compiles +09:42 < geertu> Niklas: +09:42 < geertu> - Sent "[PATCH v3] thermal: rcar_gen3_thermal: fix initialization +09:42 < geertu> sequence for H3 ES2.0" and it was picked up. +09:42 < geertu> Shimoda: +09:42 < geertu> - Prepared M3-N Salvator-X board for remote access. +09:42 < geertu> - Talked BSP team about MSIF lock driver. +09:42 < geertu> - Submitted the following patch(es): +09:42 < geertu> - arm64: dts: renesas: salvator-common: add dr_mode property for +09:42 < geertu> USB2.0 channel 0 +09:42 < geertu> Simon: +09:42 < geertu> - Reposted CPUFreq patches; recieved futher review +09:42 < geertu> - Rebased r8a7795 IPMMU DTS patchset +09:42 < geertu> B) What I plan to do till next time +09:42 < geertu> Geert: +09:42 < geertu> - Attend ELCE and DT Workshop (Thursday) +09:42 < geertu> - Lead DT Workshop discussion on generic bindings, +09:42 < geertu> - Fix genpd for wake-up devices, part two (interrupt routing). +09:42 < geertu> Marek (U-Boot): +09:42 < geertu> - Work on testing V3M Eagle remotely +09:42 < geertu> Niklas: +09:42 < geertu> - If dependencies for the rest of the thermal patches (CPUFreq) gets +09:42 < geertu> picked up, rebase and resend the cpu cooling patches. +09:42 < geertu> Shimoda: +09:42 < geertu> - Add usb3.0 phy device node for r8a779[56].dtsi. +09:42 < geertu> Simon: +09:42 < geertu> - Address review of CPUFreq patches +09:42 < geertu> - Test and post IPMMU patches +09:43 < geertu> C) Problems I have currently +09:43 < geertu> Niklas: +09:43 < geertu> - No hardware to test the thermal calibration from registers on. V3M +09:43 < geertu> uses different thermal hardware so it won't help. Plan is to hold +09:43 < geertu> on to the patches until they can be tested. +09:43 < geertu> - Not sure if we have plan for V3M thermal driver (maybe this is for +09:43 < geertu> IO?) +09:43 < geertu> I think we covered this? +09:43 < geertu> Shimoda: +09:43 < geertu> - R-Car D3 Draak doesn't have any PMICs. So, it cannot do reboot, +09:43 < geertu> shutdown, suspend and resume. +09:43 < geertu> - Could upstream team suggest other solutions to BSP team? +09:44 < geertu> Draak can reboot using the RWDT watchdog, which is already enabled +09:44 < horms> Marek: is that SH or SD maintainer? +09:45 < Marex> horms: SH +09:45 < horms> Ok, as in SuperH ? +09:45 < Marex> horms: actually rcar/rmobile, but the tree is called u-boot-sh +09:45 < Marex> horms: legacy naming +09:45 < geertu> For shutdown, you can use the standard "poweroff" command. Linux will put all devices to sleep. No idea what it will do when PSCI is called. +09:45 < horms> Marex: ack +09:45 < shimoda> about thermal, d3 spec is similar with gen2. so, power management team of bsp will use gen2 code to support d3. +09:45 < Marex> horms: I can apply my own patches and be in complete control again, yay +09:46 < horms> :) +09:46 < geertu> For suspend/resume, you can use s2idle, with whatever wakeup source supported by Linux +09:46 < neg> shimoda: thanks for the v3m/d3 hardware info +09:46 < shimoda> neg: you're welcome! +09:46 < geertu> s2ram will call into PSCI if PSCI advertises suspend support. No idea what will happen afterwards, or if there's a way to wakeup. +09:47 < geertu> shimoda: Do you know the details about PSCI on Draak? +09:47 < wsa_> i used to have a patch to reboot via WDT. I dropped it because of PSCI. I can try to dig it out if desired. (It was not rocket science anyhow ;)) +09:48 < shimoda> geertu: I don't know. so, I will ask IPL team +09:48 < geertu> Hmm, we don't delcare PSCI support for Draak in DTS yet +09:48 < geertu> s/delcare/declare/ +09:48 < Marex> wsa_: does gen3 have a wdt ot wake it up ie. with rtcwake ? +09:48 < geertu> So everything should work fine ;-) +09:49 < horms> I assume it would be described in DT. But if so should it also be described in DT for SoCs that also support other reset mechanisms +09:49 < geertu> I haven't tested suspend/resume on Draak yet, due to remote access. +09:50 < horms> Is there a non-local solution to that problem? +09:50 < geertu> s2idle and Wake-on-LAN should work now we have ravb support +09:51 < horms> thanks +09:51 < geertu> shimoda: Does that answer your question? +09:51 < wsa_> Marex: I don't get your question probably, I'd say WDT != RTC, but you know that, of course +09:51 < Marex> wsa_: errrr, 4 hours of sleep does this to me, sorry +09:51 < geertu> wsa_: On Gen2, the PMIC (DAxxxx) has an RTC +09:52 < Marex> wsa_: I meant rtc indeed +09:52 < shimoda> geertu: yes. thanks! +09:52 < geertu> On Salvator-X, there's no RTC +09:52 < geertu> shimoda: Speaking about remote access, you have prepared an M3-N board? +09:53 < shimoda> geertu: i gave Magnus-san the board. and magnus-san is preparing it for remote access now I heard +09:54 < dammsan> yep +09:54 < geertu> Good (I thought he was on a plane ;-) +09:54 < geertu> dammsan: Do you know what's wrong with TFTP timeouts on Eagle? It became unbootable due to that +09:55 < Marex> geertu: apparently fix is work-in-progress +09:55 < Marex> geertu: I got email about it this morning +09:55 < dammsan> geertu: i heard about eagle/draak issues, will replace the alix node with a different one +09:56 < shimoda> geertu: ah, i also saw such behavior (a lot of timeout happen and retry the tftp forever) on h3ulcb today. +09:56 < geertu> dammsan: Thx! (replacing whole nodes in case of issues feels like a real datacenter ;-) +09:57 < shimoda> so i intended to ask magnus-san later :) +09:57 < geertu> Topic 2. Discussion Topics +09:57 < geertu> Does anyone have other topics to discuss? +09:58 < shimoda> nothing from me +09:58 < Marex> no +10:00 < geertu> Who will be at ELCE next week? +10:00 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Miniperi-2017-10 looks a bit sparse +10:00 < jmondi> I didn't know about this link! +10:00 < jmondi> filling in details now! +10:01 < neg> Same, I will fill in details in a few min as to not overwrite jmondi update :-) +10:02 < geertu> neg: Which wiki did you update according tou your email? +10:02 < geertu> s/tou/to/ +10:02 < neg> geertu: but yes I will be there, and I also signed up for the DT workshop (hoping it won't collide with the media meetings) :-) +10:02 < geertu> neg: DT is all day +10:02 < neg> geertu: the 'memeber info' page related to upcomming holidays +10:03 < horms> oh, that reminds me; I am taking a holiday next week. Sorry, no ELCE for me. +10:03 < horms> Timing clash with conference and school holidays :( +10:04 < neg> geertu: OK I will attand as much as possible of the DT workshop then :-) +10:04 < Marex> geertu: ELCE ? me ... and if anyone of the group needs assistance or gets stuck in some weird ditch, let me know ... +10:04 < geertu> horms: In BE, the school holidays are one week later ;-) +10:04 < geertu> uli__: Will you be at ELCE? +10:04 < horms> They are tagered in NL. But my son goes to an independent school and they have their own schedule (maybe the UK one?) +10:04 < uli__> i'll be there to say hi, but not to attend the conference. any suggestions on when would be best? (matthias brugger wants to meet up between 23 and 26, so it would be one (or two) of these days +10:05 < uli__> ) +10:05 < geertu> uli__: Tuesday Marex Party Time? +10:05 < uli__> sounds promising :) +10:06 < pinchartl> sorry, I'm late +10:06 < pinchartl> I got stuck in traffic +10:07 < pinchartl> (let me know when I can start with multimedia) +10:07 < neg> pinchartl: welcome +10:08 < geertu> I think we're finished. +10:08 < geertu> Thanks for joining! +10:08 < geertu> One thing: next meeting? +10:08 < geertu> Does it make sense to have next one right after ELCE, or shall we postpone by one week? +10:09 < pinchartl> I propose postponing by one week +10:09 < Marex> pinchartl: +1 +10:09 < pinchartl> I couldn't join a meeting the week right after ELCE anyway +10:09 < geertu> wsa_: Still there? +10:10 < wsa_> yup +10:10 < wsa_> postponing +10:10 < wsa_> yes +10:11 < Marex> hm, YPDD, OpenWRT summit, DT workshop, all in one day ... sigh +10:11 < geertu> OK. +10:11 < geertu> pinchartl: The mic is yours diff --git a/wiki/Chat_log/20171019-io-chatlog b/wiki/Chat_log/20171019-io-chatlog new file mode 100644 index 0000000..289c990 --- /dev/null +++ b/wiki/Chat_log/20171019-io-chatlog @@ -0,0 +1,175 @@ +08:59 < wsa_> hi guys! +08:59 -!- uli__ [~uli___@static.206.203.46.78.clients.your-server.de] has joined #periperi +08:59 < geertu> Mornin' +08:59 < jmondi> 'morning! +09:00 < uli__> good morning +09:01 < morimoto> Marex: I will bring your sound board in next ELCE ;P +09:02 < Marex> morimoto: nice, thank you :-) +09:02 < wsa_> morimoto: do you know if Shimoda-san will attend the meeting? +09:02 < Marex> morimoto: at least we know where the problem is now +09:02 < morimoto> wsa_: Now shimoda-san is talking to our Boss. +09:02 < wsa_> I see +09:03 < wsa_> So, I guess we'll start then +09:03 < morimoto> Marex: the most biggest problem is that I have it ;P +09:03 < Marex> morimoto: why so ? +09:03 < morimoto> It means, I have your sound board. You can't fix it, right +09:04 < Marex> btw minor announcement regarding prague taxis and their price, I was just reading an article today about that in local news +09:04 < Marex> they did a test with local people and some foreigners and apparently there was some difference, so please be a bit careful +09:04 < wsa_> so, welcome to the io meeting! I collected all the status updates from you guys and will paste them now. After that, there is room for questions +09:04 < wsa_> A) +09:04 < wsa_> Geert: +09:04 < wsa_> - Sent patch to consolidate RAVB clock handling. +09:04 < wsa_> Simon: +09:04 < wsa_> - Began backporting HS400 from BSP +09:04 < wsa_> - Posted fallback bindings for SDHI and SH-Eth +09:04 < wsa_> - Posted and merged patches to use R-Car GPIO fallback bindings +09:04 < wsa_> Niklas: +09:04 < wsa_> - [RFC] mmc: tmio: fix tuning for stubborn cards +09:04 < wsa_> Not sure if I should repost this as a PATCH, got positive +09:04 < wsa_> feedback from Simon. +09:04 < wsa_> - Familiarised my self with SDIO and the basics of tuning +09:04 < wsa_> SDR50/SDR104. +09:04 < wsa_> Shimoda-san: +09:04 < wsa_> - Investigate MMC driver issues in v4.14-rc3. +09:04 < wsa_> - Submitted the following patch(es): +09:04 < wsa_> - Modify phy-rcar-gen3-usb2 driver for R-Car D3 support. +09:04 < wsa_> - Fix the SDHI driver for v4.14, but needs update the patch. +09:04 < wsa_> - Merged the following patch(es) into the subsystem: +09:04 < wsa_> - Add support suspend/resume and generic phy for USB3.0 peripheral. +09:04 < wsa_> - Add R-Car D3 support for phy-rcar-gen3-usb2 driver. +09:04 < wsa_> Wolfram: +09:04 < wsa_> * sent out PFC patches for HSCIF on XS +09:04 < wsa_> * discuss use of mmc_regulator_get_supply() and fix drivers +09:04 < wsa_> * resent eMMC driver strength patches addressing comments from Ulf +09:04 < wsa_> * implemented the missing bits for the I2C DMA series +09:04 < wsa_> * various SDHI discussions +09:04 < wsa_> * various I2C/IIC/RIIC discussions +09:04 < wsa_> * reviewed a few patches +09:04 < wsa_> * last Q4 add tasks on the way now +09:04 < wsa_> * started working on my talk for ELCE +09:04 < wsa_> B) +09:04 < wsa_> Geert: +09:04 < wsa_> - Rework EtherAVB PHY reset according to review comments +09:04 < wsa_> (Sergei's old patches look promising), +09:04 < wsa_> - MSIOF (add. task + issues reported by Dirk Behme). +09:04 < wsa_> Simon: +09:04 < wsa_> - Continue HS400 work +09:04 < wsa_> Niklas: +09:04 < wsa_> - Help Wolfram with more SDIO tests if he needs it. +09:04 < wsa_> Shimoda-san: +09:04 < wsa_> - Fix USBHS driver more if I got feedback from HW team. +09:04 < wsa_> - Continue to investigate how to implement bugfix code for MMC world. +09:04 < wsa_> - Continue to watch if Sergei submits updated patch for phylib gpio-reset. +09:04 < wsa_> Or, do I misunderstand somethings? +09:04 < wsa_> https://marc.info/?l=linux-netdev&m=150755343716727&w=2 +09:04 < wsa_> Wolfram: +09:04 < wsa_> * finish talk for ELCE +09:04 < wsa_> * add arbitration_lost_test to i2c_fault_injector and resend +09:04 < wsa_> * test I2C DMA patches and resend +09:04 < wsa_> * start working on no_busy_looping in MMC core +09:04 < wsa_> * verify Niklas' SDR findings +09:04 < wsa_> C) +09:04 < wsa_> Shimoda-san: +09:04 < wsa_> - HW team of USB area always blocks my works... +09:04 < wsa_> - Maintainer(s) doesn't review the following patch(es) yet...: +09:04 < wsa_> - Add PWM dt-binding for r8a77995. +09:04 < wsa_> Wolfram: +09:04 < wsa_> * private life issues usually have bad timing +09:05 < Marex> the distance from the airport to the city center is about 16 km and price per km is ~28 CZK, so that should give you the idea of how much and how long it takes +09:06 < wsa_> neg: please wait with resending the SDR tuning patch until I had the chance to test it +09:07 < neg> wsa_: OK, will do +09:07 < wsa_> geertu: i assume your "Rework EtherAVB PHY reset" is the same as what shimoda-san mentioned with "Continue to watch if Sergei submits updated patch for phylib gpio-reset"? +09:08 < horms> shimoda-san: in general i advise against waiting for sergei, i would take over anything you need done quckly. i would tell him if you think he would mind - probably he will not +09:08 < geertu> wsa_: Yes it is +09:08 < wsa_> good +09:08 < geertu> horms: I'll take over the series, It already works as-is. +09:08 < horms> good plan +09:09 < wsa_> so, then there is this swiotlb thing +09:10 < geertu> Commit 7453c549f5f6485c ("swiotlb: Export swiotlb_max_segment to users") appears to be the solution? +09:10 < wsa_> this has turned into a core issue IIUC? +09:10 < geertu> It's in v4.10 and later +09:10 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi +09:10 < shimoda> sorry for the delayed +09:10 < geertu> Let's repeat +09:10 < geertu> Commit 7453c549f5f6485c ("swiotlb: Export swiotlb_max_segment to users") appears to be the solution? +09:11 < wsa_> hello shimoda-san +09:11 < geertu> It's in v4.10 and later +09:11 < shimoda> geertu: I don't think so, because +09:12 < shimoda> a mmc device cannot recognise which ops (swiotlb or iommu) is used +09:12 < shimoda> on local code of mine, some api seems to detect it +09:12 < geertu> Indeed, the check is not a real runtime check +09:13 < geertu> On arm64, it will always limit the size, as swiotlb is always compiled in. +09:13 * pinchartl has to leave for a bit, I'll be back in 45 minutes at the latest +09:13 < shimoda> the api is of_iommu_configure(). +09:15 < shimoda> if the return value is not null, we can assume the device is on iommu. +09:15 < geertu> Thatg's called by core device code? +09:16 < shimoda> on my local code, it's called by sdhi code, not core device code. but i guess core device code can use it +09:17 < geertu> It's called from drivers/of/device.c:of_dma_configure +09:18 < geertu> which is called from drivers/base/dma-mapping.c:dma_configure() +09:18 < shimoda> in my opinion, we should fix this issue in v4.14. so, i'd like to apply a workaround code (adjust max_req_size) into v4.14. is it reasonable? +09:18 < wsa_> uli__: about the receive margin thing: any idea how to set it up without sysfs? +09:18 < geertu> whcih is called from drivers/base/dd.c:really_probe(), i.e. for all devices +09:19 < uli__> no, none yet +09:19 < geertu> uli__: Have you noticed any improvements by fiddling with the sampling point? +09:19 < uli__> it behaves as you would expect; shifting the sampling point down adds margin at the lower and and removes it at the higher end +09:19 < uli__> and vice versa +09:20 < geertu> uli__: So you can derive a formula to calculate optimal sampling point for sepcific requested bps? +09:20 < geertu> s/sepcific/specific/ +09:21 < uli__> yes, but i am not sure about how this should behave when you change the baud rate +09:21 < geertu> shimoda: Can you look at the dma_ops configured for the device? +09:21 < geertu> uli__: What do you mean? Can't you just recalculate? +09:22 < uli__> yes, but that makes little sense; if you have a device connected that deviates, it will not deviate the same way at different baud rates +09:22 < uli__> so scaling is not helpful +09:22 < uli__> resetting is even worse, it's a biting-the-carpet bug generator for userspace +09:23 < geertu> uli__: Ah, so the goal is to accomodate an off device at the other side. +09:23 < uli__> yes +09:23 < horms> shimoda: assuming the problem was introduced in v4.14 then fixing it there seems to be a good idea. and providing a simple fix/work around sounds appropriate if a full fix is too invasive. +09:23 < geertu> Then you need a way to communicate the other side's rate to the driver => sysfs? +09:23 < uli__> exactly +09:23 < geertu> Or ioctl. Ugh +09:24 < uli__> and that gregkh doesn't like new sysfs attributes doesn't help either +09:24 < geertu> But it can also be used if the local scif cannot support the exact requested rate, right? +09:25 < shimoda> geertu: you're request means what of_dma_configure() output the message? dev_dbg(dev, "device is%sbehind an iommu\n", iommu ? " " : " not "); +09:25 < geertu> shimoda: I mean if the MMC driver can figure out if the IOMMU is used by looking at its dma_ops +09:26 < geertu> I believe of_dma_configure() is already called anyway. +09:26 < shimoda> horms: thank you for your comment! I will add such document and submit v2 patch +09:26 < uli__> geertu: that is also possible, but it's not the use case i have looked into +09:26 < geertu> uli__: OK. But it's something that doesn't rely on sysfs ;-) +09:27 < geertu> So for now you could calculate sampling point based on requested rate vs. scif-supported rate. +09:28 < geertu> Later it can be extended to remote-supported rate vs. scif-supported rate +09:28 < uli__> that would probably work +09:28 < geertu> The latter of course depends on discussing with Greg and friends about a good way to configue remote-supported rate +09:28 < geertu> Does that make sense? +09:29 < uli__> i think it does +09:30 < wsa_> shimoda: was my mail about your IIC requests helpful to you? +09:31 < shimoda> geertu: i don't think dma_ops is useful to figure out if the iommu ise used or not because dma_ops only has function pointers. So, it is diffcult to use on multiple arch. +09:32 < shimoda> wsa_: I'm sorry, i need to read your comment more about stop condition. +09:32 < geertu> shimoda: OK. Then we have to bring up to Konrad that we can use his suggestion as a temporary workaround, but that it doesn't solve the full problem (i.e. it limits mapping size if the device uses the IOMMU) +09:33 < wsa_> shimoda: i see, no worries. Please ask if there are still questions or if it is more urgent +09:33 < horms> can you use dma_ops like this? if (dma_ops == renesas_sdhi_sys_dmac_dma_ops) ... +09:34 < shimoda> geertu: ok. you means we should use his suggested api on the sdhi driver instead of hardcoded value of max_blk_size? +09:35 < geertu> shimoda: Yes. If swiotlb_set_max_segment() returns non-zero, we should use the returned value. +09:35 < shimoda> wsa_: i got it. thanks! +09:35 < shimoda> geertu: i got it! +09:35 < geertu> shimoda: Optimization for IOMMU can be done later +09:35 < geertu> Correctness first ;-) +09:35 < wsa_> swiotlb_max_segment() +09:36 < wsa_> not swiotlb_set_max_segment +09:36 < geertu> wsa_: Thanks, copy-and-pasted the wrong fucntion +09:36 < geertu> s/fucntion/function/ +09:36 < wsa_> :) +09:36 < wsa_> ok, i think that was it for io? +09:37 < neg> One question is thermeal driver support IO or Core ? :-) +09:37 < geertu> neg: If you want to control e.g. CPUFreq, it's core +09:37 < geertu> neg: If it's just about measuring temperatures, it's I/O +09:38 < geertu> wsa_: Do you agree? ;-) +09:38 < wsa_> I was about to write the same thing, yes +09:38 < wsa_> :) +09:38 < neg> OK I'm thinking about thermal readig of temps for V3M, so then I guess it's IO :-) Do we have a request/plan for V3M support as it looks like this will be different from rcar_gen3_thermal +09:39 < wsa_> neg: I didn't get anything like that yet +09:40 < wsa_> I didn't get any request for V3M yet +09:40 < neg> wsa_: OK I just wanted you (or Geert if it where Core ;-) to be aware of the hardware difference that is all :-) +09:40 < wsa_> ok, thanks! +09:41 < wsa_> so, it's core time now... +09:41 < wsa_> thanks guys! happy hacking... +09:41 < geertu> wsa_: Thank you! diff --git a/wiki/Chat_log/20171019-mm-chatlog b/wiki/Chat_log/20171019-mm-chatlog new file mode 100644 index 0000000..9d45391 --- /dev/null +++ b/wiki/Chat_log/20171019-mm-chatlog @@ -0,0 +1,142 @@ +Multimedia-chat-meeting-2017-10-19 + +10:11 < pinchartl> thank you. let's get started with multimedia then +10:11 < pinchartl> let's see who's here +10:11 < pinchartl> we have jmondi +10:11 < pinchartl> dammsan: +10:11 < pinchartl> morimoto: +10:11 < pinchartl> neg: +10:11 < pinchartl> uli__: +10:11 < pinchartl> and possibly kbingham_ lurking +10:11 < wsa_> i gotta run, cya guys! +10:12 < pinchartl> first topic, status check for multimedia tasks +10:12 < pinchartl> jmondi: you reported last, please start :-) +10:12 < jmondi> Marex: why are you jumping between this and #renesas-soc room? Split personality as headless suggested? :) +10:12 < jmondi> sure +10:12 < pinchartl> (next will be uli__, neg, kbingham_, morimoto) +10:13 < jmondi> first max9286: I have re-based an old patch series on Kieran's stabilization one and submitted a new one to decide at run-time if we want to run in single source mode or not +10:14 < jmondi> also, I began testing OV10635 settings based on what OV suggested, anyway the information we received are incomplete (that should be a C) +10:15 < jmondi> on CEU I have implemented data synch fetch mode support as that's the one according to Chris, that people is mostly interested on, and debugged the driver format handling on Peach +10:16 < jmondi> unfortunately I see spurious VSYNC interrupts (and get VBS interrupts from CEU consequentially, for the interested readers) and I don't know if I want to blame, sensor driver or my driver +10:16 < jmondi> I have tried replacing mainline driver for ov7670 with the very simple one Chris provided me, but same results, so... +10:16 < jmondi> B is continue development of CEU on Migo-R and keep trying debugging GMSL setup +10:17 < jmondi> (I really would love to see what happens on the camera side of GSML setup, but we're struggling to attach probes there apparently) +10:17 < jmondi> --eot-- +10:18 < pinchartl> and C ? +10:18 < jmondi> pinchartl: correct +10:18 < jmondi> OV people has not provided complete answers, I need Migo-R access from remote as Peach in unreliable +10:19 < jmondi> that is --eot-- +10:19 < pinchartl> thank you +10:19 < pinchartl> next, uli__ +10:19 < uli__> i sent a new revision of the chromebook r13 support, with much fewer hacks +10:20 < uli__> it still has the mmsys hack, but discussions on how to solve that are underway +10:20 < uli__> next i'll start with porting the gpu driver +10:20 < morimoto> pinchartl: I need to go back home soon. Can I be next guys ? Sorry for my noise +10:20 < uli__> that's it from me +10:21 < pinchartl> thanks +10:21 < pinchartl> morimoto: sure, please go ahead +10:21 < morimoto> Thanks +10:21 < morimoto> A) What have I done since last time +10:21 < morimoto> I pinged to OmniVision guy this morning +10:21 < morimoto> I and ALSA maintainer worked for Hot-Unplug support. We needed to consider ALSA / ALSA SoC framework. but it OK now. ALSA framework patch will be added v4.15, ALSA SoC will be v4.16 +10:21 < morimoto> BSP team noticed sound noise issue for Capture. the issue was on DMAC (= TCR vs TCRB). I posted this patch. latest is v3. +10:21 < morimoto> virtual machine (= integrity) team noticed latest BSP can't output sound on VM. I'm supporting them now. +10:22 < morimoto> B) What I plan to do till next time +10:22 < morimoto> re-post DMAC patch v3 or more ? +10:22 < morimoto> continue posting ALSA SoC cleanup patch witch is needed for next generation ALSA SoC system. +10:22 < morimoto> C) Problems I have currently +10:22 < morimoto> Very slow progress for ALSA SoC cleanup +10:22 < morimoto> --EOL-- +10:22 < pinchartl> arigatō gozaimasu +10:22 < pinchartl> next, dammsan +10:23 < dammsan> nothing to report here +10:23 < pinchartl> I had already prefilled the report with that information ;-) +10:23 < pinchartl> next, kbingham_, who is likely away +10:23 < pinchartl> Since last meeting: +10:23 < pinchartl> - Continued on probe stabilization investigation +10:23 < pinchartl> - Exposed I2C bus on Breakout camera +10:23 < pinchartl> - Lots of trace and analysis of boot time, and power up of RDACM20 +10:23 < pinchartl> - Patches posted, and a better understanding of the early stages of camera +10:23 < pinchartl> probing all round +10:24 < pinchartl> For the next two weeks: +10:24 < pinchartl> - V3M board is en-route, so that will likely be the next task +10:24 < pinchartl> However, Kieran's availability will be low for the next couple of weeks. +10:24 < pinchartl> Issues and Blockers: None +10:24 < pinchartl> next, neg +10:24 < neg> Multimedia) +10:24 < neg> A) +10:24 < neg> - [PATCH] v4l: rdacm20: add delay after configuring data mode and rate +10:24 < neg> - [PATCH] v4l: rdacm20: add log_status operation +10:24 < neg> - Register investigations of the MAX9271 of "normal" and "troubled" cameras. +10:24 < neg> - Accepted that my 8-camera extension board is half broken and only MAX9286_B is functional :-( +10:24 < neg> - Started (hopefully) last rework of VIN Gen3 patches. +10:24 < neg> B) +10:24 < neg> - Rebase multiplexed pads on Sakari's patch series. +10:24 < neg> - Attend multimedia core dev meeting after ELCE together with Laurent. +10:24 < neg> - If V3M arrives, add support for it in the VIN Gen3 driver and DT. +10:24 < neg> C) +10:24 < neg> - Not sure about status of Laurents 'V4L2 lifetime management issues +10:24 < neg> (for VIN Gen3 support)' work which will be needed before I can +10:24 < neg> post the (hopefully) last version of VIN Gen3 support. I only +10:24 < neg> bring it up here as I'm about to sign an additional contract for +10:24 < neg> this task and don't want to commit to something which is not +10:24 < neg> feasible not to rush you Laurent :-) +10:24 < neg> --eot-- +10:25 < pinchartl> thank you +10:25 < pinchartl> let's discuss the object lifetime management with my report +10:25 < pinchartl> well, I'm next :-) +10:25 < pinchartl> Since last meeting: +10:25 < pinchartl> - Finished the additional tasks descriptions for Q4 +10:25 < pinchartl> - Patch review and GMSL debugging discussions +10:25 < pinchartl> - Started display color keying support for Gen3 +10:25 < pinchartl> Until next meeting: +10:25 < pinchartl> - More patch review +10:25 < pinchartl> - Complete display color keying support for Gen3 +10:25 < pinchartl> - V4L2 lifetime management issues (for VIN Gen3 support) +10:25 < pinchartl> Issues and Blockers: None +10:26 < pinchartl> so my plan is to handle object lifetime management after ELCE +10:26 < pinchartl> but I'll be travelling the week right after ELCE and take two days off +10:26 < jmondi> neg: I had missed "v4l: rdacm20: add log_status operation".. That's useful (sorry for the noise Laurent) +10:26 < pinchartl> so my availabilities will be a bit reduced +10:27 < pinchartl> as Niklas depends on that, I'll try to prioritize it over the weekends +10:27 < pinchartl> and possibly during ELCE, but based on personal experience I can't do all the work I plan during conferences +10:27 < pinchartl> neg: how would that work for you schedule-wise ? +10:28 < pinchartl> and is the remove / ioctl race the only one blocking the VIN driver ? +10:28 < neg> pinchartl: that would work and I would feel confident with my additional contract date. My concern is that I want to post the series as soon as possible so there is some time for review before the end of the contract :-) +10:29 < neg> and yes the ioctl race (and a api to interact with it for controll handeling on Gen2) is all that is missing +10:30 < pinchartl> let's see what I can get done over the weekend then +10:30 < pinchartl> that's it for me +10:31 < neg> n/p I wont postit before the 31st as I need to be in the office for full testing before sending it out +10:31 < pinchartl> we've covered the topic of the next meeting already, it will be on November the 9th +10:31 < pinchartl> how about meeting during ELCE ? +10:32 < pinchartl> dammsan: any plan for that ? +10:32 < dammsan> not apart from having dinner with marek +10:32 < dammsan> but we can schedule something if needed +10:33 < neg> I'm up for meeting anytime duinrg ELCE, but if possible not during ELCE time on Monday, too may good talks that day :-) +10:33 * morimoto morimoto need to go back home +10:33 < pinchartl> Tuesday or Wednesday should work. we'll see if there are topics to discuss +10:33 < pinchartl> anything else for today ? +10:33 < pinchartl> morimoto: have a nice evening +10:34 < morimoto> thanks +10:34 < morimoto> bye +10:34 < jmondi> not from me.. bye Morimoto-san +10:34 -!- morimoto [~user@relprex3.renesas.com] has left #periperi ["ERC Version 5.3 (IRC client for Emacs)"] +10:34 < geertu> pinchartl: We forgot one thing w.r.t. next meeting: end of Daylight Savings Time +10:35 < pinchartl> so what should we do ? :-) +10:36 < uli__> panic!! +10:36 < pinchartl> the time difference with Japan will increase by one hour +10:36 < pinchartl> one option is to keep the same time in Japan and move the meeting earlier in Europe +10:37 < pinchartl> but that would make it at 7:00 for Kieran, which is too early +10:37 < pinchartl> so I propose the other way around, keeping the same time in Europe +10:37 < pinchartl> dammsan: as you're in Japan, what do you think ? +10:37 < geertu> +1 +10:37 < geertu> (although Kieran will be used to wake up all day soon ;-) +10:38 < dammsan> sounds fine to me +10:38 < dammsan> i think this will have a positive impact for japan side +10:39 < pinchartl> good :-) +10:39 < pinchartl> what kind of positive impact ? +10:40 < Marex> keep that DST in mind when going to the airport in case you're departing after the DST switch please, so that you won't miss your flight +10:40 < dammsan> more time before the meeting starts? =) +10:40 < Marex> heh +10:41 < pinchartl> that's it for today thn +10:41 < pinchartl> thank you all for attending diff --git a/wiki/Chat_log/20171109-core-chatlog b/wiki/Chat_log/20171109-core-chatlog new file mode 100644 index 0000000..4029f0a --- /dev/null +++ b/wiki/Chat_log/20171109-core-chatlog @@ -0,0 +1,199 @@ +Core-chat-meeting-2017-11-09 + +09:38 < geertu> Welcome to today's core group meeting! +09:38 < geertu> Agenda: +09:38 < geertu> 1. Status updates +09:38 < geertu> 2. Discussion Topics +09:38 < geertu> Topic 1. Status updates +09:39 < geertu> I'll just replay (a sometimes shortened version of) the update sent by email +09:39 < geertu> A) What have I done since last time +09:39 < geertu> Geert: +09:39 < geertu> - Sent 2nd pull requests for clk-renesas and sh-pfc, +09:39 < geertu> - Attendend ELCE and DT Workshop (Thursday), +09:39 < geertu> - Sent patches to enable SMP on r8a77970/eagle, +09:39 < geertu> - Sent patches for initial support for Salvator-XS with R-Car M3-W. +09:39 < geertu> - Looked a bit into initial support for Salvator-X with R-Car M3-N. +09:39 < geertu> - Fixing genpd for wake-up devices: +09:39 < geertu> - Sent active_wakeup cleanups, +09:39 < geertu> - Working on part two (interrupt routing), +09:39 < geertu> Jacopo: +09:39 < geertu> - Attended ELCE and multimedia meeting on 26/27 November +09:39 < geertu> Marek: +09:39 < geertu> - UBoot: Fixed eMMC data line voltage setting bug in U-Boot DT +09:39 < geertu> - UBoot: Final testing in preparation for the 2017.11 release +09:39 < geertu> Morimoto: +09:39 < geertu> - Posted DMAC TCR/TCRB patch +09:39 < geertu> Niklas: +09:39 < geertu> - [PATCH] net: ethtool: remove error check for legacy setting transceiver +09:39 < geertu> type +09:39 < geertu> - Received a V3M. +09:40 < geertu> Shimoda: +09:40 < geertu> - Prepared test environment for a new feature of M3-N's IPMMU (stage-2 +09:40 < geertu> format). +09:40 < geertu> - Handle our 3rd party (EPAM) requests for Xen. +09:40 < geertu> - Handle our kernel test team for testing v4.14. +09:40 < geertu> - Merged the following patch(es): +09:40 < geertu> - arm64: dts: renesas: salvator-common: add dr_mode property for USB2.0 +09:40 < geertu> channel 0 +09:40 < geertu> Simon: +09:40 < geertu> - Posted, changes requested: +09:40 < geertu> - Gen3 SoC IPMMU DTS patches +09:40 < geertu> - Posted, now under review: +09:40 < geertu> - [PATCH 0/2] iommu/ipmmu-vmsa: r8a779(70|95) support +09:40 < geertu> - Posted, now accepted: +09:40 < geertu> [PATCH] ARM: dts: koelsch: Move cec_clock to root node +09:40 < geertu> [pause to let people catch up] +09:41 < geertu> Any persone I missed? +09:43 < geertu> B) What I plan to do till next time +09:43 < geertu> Geert: +09:43 < geertu> - Finalize genpd for wake-up devices, +09:43 < geertu> - Initial support for Salvator-X with R-Car M3-N? +09:43 < geertu> Marek (U-Boot): +09:43 < geertu> - UBoot: Start converting Gen2 to DM/DT +09:43 < geertu> Morimoto: +09:43 < geertu> - Solve DMAC TCR/TCRB issue. +09:44 < geertu> Niklas: +09:44 < geertu> - Hook up V3M and make sure I can boot it. +09:44 < geertu> - Start to look at 'Add support for more than 32-bits IOVA space' +09:44 < geertu> Shimoda: +09:44 < geertu> - Add usb3.0 phy device node for r8a779[56].dtsi. +09:44 < geertu> Simon: +09:44 < geertu> - Address review of CPUFreq/Z,Z2 Clock patches +09:44 < geertu> - Address review of Gen3 SoC IPMMU DTS patches +09:44 < geertu> - Upport lots of BSP pinctrl patches +09:45 < geertu> My comment here is that several of the patches listed are alrwady upstream ;-) +09:45 < geertu> s/alrwady/already/ +09:45 < horms> geertu: ok, I thought I had pruned those. I'll prune again. +09:45 < horms> Unless kaneko-san posts them before I get that far +09:48 < geertu> C) Problems I have currently +09:48 < geertu> Morimoto: +09:48 < geertu> - I still don't understand DMAC TCR/TCRB issue on serial. +09:48 < geertu> I think problem is in rx_timer_fn(). +09:48 < geertu> According to Geert, "With your patch, the serial driver doesn't know +09:48 < geertu> about them (residue == 0), and the console doesn't see them." What does +09:48 < geertu> this mean? +09:48 < geertu> BTW, about commit e7327c09def48ccf ("serial: sh-sci: Pause DMA engine and +09:48 < geertu> get DMA status again"), I guess the reason why "transaction completes +09:48 < geertu> _after_ DMA stopped" is that it used TCR instead of TCRB? +09:49 < geertu> Perhaps I wasn't very clear in my initial bug report, but serial console input just doesn't work when SCIF DMA is enabled. +09:50 < morimoto> geertu: thank you for your report, we will check it again. +09:51 < wsa_> gotta go, cya guys! +09:51 -!- wsa_ [~wsa@p54B33A46.dip0.t-ipconnect.de] has quit [Quit: ...] +09:51 < horms> ciao +09:51 < geertu> horms: Goodbye! +09:51 < geertu> Oops, wsa_: Goodbye! +09:52 < geertu> morimoto: Checking the direction again may help. +09:52 < morimoto> Yeah, it seems we can guarantee data if we can check DE bit +09:53 < morimoto> geertu: can you agree ? +09:53 < geertu> morimoto: But DE is not the direction bit? +09:54 < morimoto> Yes. using TCR vs TCRB is checking direction +09:54 < morimoto> and guarantee is checking DE bit +09:54 < geertu> With "guarantee", you mean to be sure the DMA has completed? +09:54 < morimoto> yes +09:55 <@pinchartl> geertu: as far as I understand, the DE bit will be cleared the the hardware when the DMA engine finishes draining its buffers +09:55 < geertu> ok +09:55 < morimoto> pinchartl: yes +09:55 <@pinchartl> I'd like to have a clear explanation as to why SCIF doesn't work with the current patch though +09:56 <@pinchartl> I don't think we should merge anything based on guesswork +09:56 < morimoto> Current SCIF is maybe, DMAC read data from device +09:56 < morimoto> then, TCR was updated +09:56 < morimoto> but, DMAC will buffer it untile transferable +09:57 < morimoto> thus, this timing, TCRB is not updated +09:57 < morimoto> Because of this time gap, TCRB indicate 0x20 +09:57 < morimoto> I guess +09:58 < geertu> OK, it's worth a try. +09:58 <@pinchartl> that's the thing, I would feel better with a "I'm sure" than a "I guess" :-) +09:58 < morimoto> :) +09:58 < morimoto> So, geertu: pinchartl: can you agree using direction and DE bit check ? +09:59 < morimoto> using direction = TCR vs TCRB +09:59 < geertu> Yes, it's worth a try. It needs to be tested, though. +10:00 < morimoto> Thanks. +10:00 < morimoto> How about pinchartl ? +10:01 < morimoto> ... +10:01 < morimoto> BTW, on commit e7327c09def48ccfd204025726f11b57a19a9c24, it seems rcar dmac driver doesn't support dmaengine_pause() ? +10:02 < geertu> That's correct, AFAIK. +10:02 <@pinchartl> morimoto: I'm not sure yet, I need to analyze the problem in details. knowing how it works when checking the DE bit would help me understanding +10:03 < morimoto> pinchartl: OK, so I will create patch, and add [RFC]. can you check it ? +10:04 <@pinchartl> morimoto: can you run the patch and include the results ? :-) +10:04 < geertu> morimoto: Please check it doesn't break the serial console before posting ;-) +10:04 < morimoto> geertu: Hehe OK :) +10:04 < morimoto> pinchartl: OK, will try +10:04 < horms> geertu: is "[PATCH 2/3] soc: renesas: Identify R-Car M3-W ES1.1" good to merge? I think so after our discussion with shimida-san on periperi ML. +10:05 < geertu> Case closed 9for now)? +10:05 < morimoto> Sound and SCIF are only user of residue ? +10:05 < geertu> horms: I think it is. +10:05 < horms> thanks, I'll add it the next time I go through my queue +10:05 < geertu> Do you want me to update the patch description with future ES info? Or is that considered too confidential for now? +10:05 < horms> Lets keep it to ourselves +10:06 < geertu> OK, fine for me. +10:06 < geertu> s/9now/(now/ +10:06 < horms> I'll just mention that we had some discussion and it seems likely to work for current and future SoCs +10:06 < geertu> If the hardware people change their mind, we need to change the tests anyway +10:06 < horms> About "[PATCH v4 0/3] iommu/ipmmu-vmsa: r8a7796 support V4". I suppose this is a question for dammsan. But should I rebase/repost? +10:06 < horms> geertu: yes, exactly +10:07 < geertu> horms: dammsan said repost in a recent email +10:07 < horms> The important bit is that its unlikely there will be a clash +10:07 < geertu> Indeed. +10:07 < geertu> Any other topics for +10:07 < geertu> Topic 2. Discussion Topics +10:07 < geertu> ? +10:07 < horms> ok. sorry for missing that. I'll do so +10:07 < morimoto> dammsan is here, please wait +10:07 < horms> I will leave very soon, btw +10:08 < dammsan> horms: i think it is fine to wait with the repost +10:08 < dammsan> but feel free to post if it helps your integration work +10:09 < horms> dammsan: what is the motivation for wating. It effects my integration work in the sense that it adds new bindings. and is a dependency for bindings for other SoCs. +10:09 < dammsan> my gut feeling is that it is good to hold off addting code to avoid potential issueeeees +10:10 < horms> ok, perhaps just repost the bindings? +10:10 < dammsan> good idea +10:10 < horms> ok, will do +10:10 < dammsan> together with other ones too if you like +10:10 < dammsan> we have to revisit non-H3 support in the driver anyway +10:10 < horms> I'll repost all the outstanding bindings but not the driver code. Is that what you have in mind? +10:10 < dammsan> sure +10:10 < dammsan> thanks +10:10 < dammsan> sounds ogod +10:11 < horms> One last question, I take it that you intentionaly did not post a fallback binding +10:11 < dammsan> yeah, the IP varies with soc +10:11 < horms> thanks, got it +10:11 < dammsan> thanks +10:12 < horms> I need to go now, sorry for any inconvenience that causes +10:12 < geertu> I think we're finished with core anyway +10:12 < geertu> horms: Bye! +10:12 < horms> perfect +10:12 < horms> bye +10:12 -!- horms [~horms@61.40.109.130] has quit [Quit: Leaving] +10:13 <@pinchartl> one question for core +10:13 <@pinchartl> (and actually for I/O too, I should have asked earlier) +10:13 <@pinchartl> what's the status of V3M support ? +10:15 < geertu> pinchartl: Boots using serial console, NFS root should work +10:15 <@pinchartl> and while waiting for an answer to that question, let's see who's ready for the multimedia meeting +10:15 <@pinchartl> hi jmondi2 +10:15 <@pinchartl> hi kbingham[m] +10:15 <@pinchartl> hi dammsan +10:15 [Users #periperi] +10:15 [@pinchartl] [ jmondi2 ] [ Marex ] [ mturquette] +10:15 [ dammsan ] [ kbingham ] [ marex-cloud] [ neg ] +10:15 [ geertu ] [ kbingham[m]] [ morimoto ] [ shimoda ] +10:15 -!- Irssi: #periperi: Total of 12 nicks [1 ops, 0 halfops, 0 voices, 11 normal] +10:15 <@pinchartl> hi morimoto +10:15 < kbingham[m]> I'm here +10:15 < kbingham[m]> Morning +10:15 <@pinchartl> hi ul[tab] +10:15 <@pinchartl> no Ulrich today +10:15 <@pinchartl> hi neg +10:15 < jmondi2> I'm here too! +10:15 < neg> pinchartl: I'm not sure about the status, got a V3M yesterday and plan to try and take it for a first spin +10:16 < kbingham[m]> geertu: . Does i2c work? +10:16 <@pinchartl> geertu: any idea whether I2C is working ? how about PFC, is that still unmerged ? +10:16 < geertu> pinchartl: Sergey is working on upstreaming PFC +10:17 < geertu> Unfortunately he discovered recently he doesn't have the xls files describing pin mappings +10:17 <@pinchartl> -_-' +10:17 <@pinchartl> that's a bit of a blocker +10:18 < geertu> I told him to post the initial version anyway. We typically don't bother reviewing the register definitions, and we can review pin groups +10:19 <@pinchartl> thanks +10:19 <@pinchartl> so let's start with the multimedia meeting +10:19 <@pinchartl> welcome everybody +10:19 <@pinchartl> (I expect Magnus and Morimoto-san to come back soon) +10:19 <@pinchartl> first topic, status update +10:20 < geertu> Let's finish the core meeting: Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20171109-io-chatlog b/wiki/Chat_log/20171109-io-chatlog new file mode 100644 index 0000000..1813aa5 --- /dev/null +++ b/wiki/Chat_log/20171109-io-chatlog @@ -0,0 +1,140 @@ +09:06 < wsa_> welcome to the io meeting +09:07 < wsa_> I didn't have the time to summarize your mail reports, so this time, we will do the good old 'sort -R ' way +09:07 < wsa_> however, I reduced the names to those who actually did work on IO +09:08 < wsa_> so, please post your updates now and we will see if there is something to discuss +09:08 < wsa_> shimoda-san, you are first this time :) +09:08 < shimoda> yes +09:08 < shimoda> A) +09:08 < shimoda> - handle our customer team requests for i2c-sh_mobile.c driver. +09:08 < shimoda> - Investigate USB3.0 peripheral issue that cannot use pipe 6 or more and I found the HW issue... +09:08 < shimoda> - Submitted the following patch(es): +09:08 < shimoda> - fix the SDHI driver for v4.14 as v2 +09:08 < shimoda> - Merged the following patch(es) into the subsystem: +09:09 < shimoda> - fix the SDHI driver for v4.14 +09:09 < shimoda> B) +09:09 < shimoda> - Add gpio feature into phy-rcar-gen3-usb2.c for R-Car D3. +09:09 < shimoda> - Submit changing USB3.0 peripheral spec. patch after management guys accepted for public. +09:09 < shimoda> - Investigate USB3.0 role swap issue. +09:09 < shimoda> - Fix USBHS driver more if I got feedback from HW team. +09:09 < shimoda> C) +09:09 < shimoda> - Maintainer(s) doesn't review the following patch(es) yet...: +09:09 < shimoda> - Add PWM dt-binding for r8a77995. +09:09 < shimoda> -- EOT -- +09:10 < wsa_> Thank you! +09:10 < wsa_> Yes, lots of IIC requests. Is the customer OK with the infos reported back so far? +09:11 -!- horms_ [~horms@61.40.109.130] has joined #periperi +09:11 < shimoda> yes, the customer support team would like to fix the datasheet until end of Nov. So, reports are useful for it +09:11 -!- horms [~horms@61.40.109.130] has quit Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org +09:12 -!- horms_ is now known as horms +09:12 < wsa_> Understood! +09:13 < wsa_> so, I am next: +09:13 < wsa_> A) +09:13 < wsa_> * gave talk and show case at ELCE +09:13 < wsa_> * processed various requests about IIC driver +09:13 < wsa_> * updated & resent I2C DMA series +09:13 < wsa_> * SDHI naming discussion +09:13 < wsa_> * assisted in riic clock frequency formula development +09:13 < wsa_> B) +09:13 < wsa_> * add. tasks about less MMC core busy looping +09:13 < wsa_> * process IIC requests further +09:13 < wsa_> * review SDHI patches from Yamada-san +09:13 < wsa_> * continue SDHI naming discussion +09:13 < wsa_> C) +09:13 < wsa_> * SDR tasks are on hold currently, because of IIC +09:13 < wsa_> and I found another IIC issue, but I will write a mail about it +09:14 < wsa_> geertu: your turn +09:15 < geertu> A) +09:15 < geertu> - Sent v3 of PHY reset patches (originally by Sergey), needed for ravb +09:15 < geertu> resume on Salvator-XS, +09:15 < geertu> - Sent patches to enable watchdog on r8a77970 and Eagle, +09:15 < geertu> B) +09:15 < geertu> - Rework PHY reset patches according to review comments, +09:15 < geertu> - MSIOF (add. task + issues reported by Dirk Behme). +09:15 < geertu> C) +09:15 < geertu> - Nothing. +09:15 < wsa_> Thank you! +09:16 < wsa_> jmondi2: the reliable testing hero, your turn ;) +09:16 < jmondi2> wsa_, eheh... just tested your patches on Migo-R +09:16 < jmondi2> no special IO items for me +09:17 < wsa_> but you did that, nothing wrong with exposing it :) +09:17 < wsa_> Marex: your turn +09:18 < jmondi2> wsa_: nothing wrong at all indeed! +09:18 < Marex> wsa_: well, I found the eMMC 1V8 issue on salvator-X, which we discussed in the email +09:18 < Marex> wsa_: plus I submitted the PCIe suspend/resume patches for Gen3 +09:18 < Marex> wsa_: V2 / V3 is needed +09:18 < Marex> wsa_: there was feedback from Sergej and geertu +09:19 < wsa_> Marex: thanks for taking over PCIE again. +09:19 < Marex> wsa_: there is still one patch missing which I did not submit, which is the DMA limit for Gen2 +09:19 < wsa_> Marex: about the eMMC issue, I'd still like to find that in the spec +09:20 < wsa_> because IIRC SD needs to start with 3.3V and an explicit switch to 1.8V +09:20 < Marex> wsa_: since the Gen2 address space is 32bit while the PCIe address space is 64bit, that needs to be cleaned up +09:20 < wsa_> I'd assume eMMC is different but that should be mentioned somewhere in the specs? +09:20 < Marex> wsa_: ACK +09:21 < Marex> wsa_: I only found the power distribution in the eMMC's datasheet, which would imply the IO always operates at 1V8 on salvator-x +09:21 < wsa_> Marex: and please add phil edworthy to the PCIE patches. He used to look at this driver, too +09:21 < Marex> wsa_: he should be on CC already, will double-check if he's on CC on all +09:21 < wsa_> thanks +09:22 < wsa_> horms: last but not least +09:22 < horms> * IO +09:22 < horms> A) +09:22 < horms> - Posted, now under review: +09:22 < horms> [PATCH] spi: sh-msiof: Fix DMA transfer size check +09:22 < horms> [PATCH] serial: sh-sci: Fix unlocked access to SCSCR register +09:22 < horms> - Posted, now accepted: +09:22 < horms> [PATCH] mmc: tmio: Replace msleep() of 20ms or less with usleep_range() +09:22 < horms> - Posted earlier, now accepted +09:22 < horms> + Add and use fallback bindings for SDHI and SH-Eth +09:22 < horms> + Use GPIO fallback bindings +09:22 < horms> B) +09:22 < horms> - Continue work on enabling HS400 +09:22 < horms> - Try to enable SDR-50 and SRR-104 on porter (patch posted, needs testing) +09:22 < horms> - Try to enable NFS on ULCB (patch posted, needs testing) +09:22 < horms> C) +09:22 < horms> - Is the following ready for upstream; should I rebase and repost? +09:22 < horms> [PATCH v4 0/3] iommu/ipmmu-vmsa: r8a7796 support V4 +09:22 < horms> - No commit access to periupport +09:22 < horms> D) +09:22 < horms> - None +09:22 < horms> I guess the first half of C is for Core, sorry for the mix up there +09:23 < wsa_> morimoto: can't we give simon access to periupport? +09:23 < morimoto> Oops ? +09:24 < horms> I have read access, but push seemed to fail. Perhaps it was an error on my part +09:24 < morimoto> let me check +09:24 < horms> thanks +09:25 < morimoto> I did +09:25 < morimoto> I think now it is OK +09:25 < horms> thanks +09:25 < wsa_> cool +09:25 < morimoto> (But I don't know this is OK for git policy :) +09:26 < morimoto> (= multi master) +09:26 < wsa_> so simon works now on periupport as well? merging the changes from his excel sheet slowly into the other list? or what is the current status? +09:26 < horms> I was looking over periupport manually +09:26 < horms> And I noticed some minor cleanups +09:27 < horms> No serious work to migrate from the spreadsheet yet +09:28 < horms> One problem I observe is that the spreadsheet tracks different information. F.e. if the patch is trivial, features or local. +09:28 < horms> But we can talk about this separately. +09:28 < wsa_> ok +09:29 < wsa_> did i forget someone / something concerning reports? +09:29 < horms> I only wanted to apply the patches I posted to periperi. I don't mind if someone else applies them. +09:29 < wsa_> well, seems you have write access now +09:29 < horms> ok, i'll push +09:29 < wsa_> I think it makes sense you have write access +09:30 < horms> done +09:30 < wsa_> OK then, another issue we have surely is the SDHI renaming issue, but I think, this is handled nicely by mail so far +09:31 < horms> agreed. I don't really mind much so long as things don't break +09:31 < horms> and we don't keep renaming the same driver endlessly... +09:32 < wsa_> about shimoda-sans request for r8a7795 bindings: I think we agreed that I will add SATA (unless somebody wants to take over), QSPI is not feasible on Linux currently, and CAN should be done by someone who can test. +09:32 < wsa_> D'accord? +09:32 < Marex> wsa_: what's the problem with QSPI ? +09:33 < Marex> wsa_: I plan to add RPC Hyperflash (CFI NOR) to Linux +09:33 < Marex> wsa_: QSPI is the same block, but I wonder how to make this support both CFI NOR and QSPI, that might need some thinking +09:33 < geertu> Marex: There's no "problem" with QSPI. There's just no need to add pinctrl support for it to Linux if there's no Linux driver. +09:34 < Marex> geertu: ah, sure +09:34 < geertu> If you write a driver, we can add pinctrl support (H3 ES1.x already has) +09:34 < Marex> geertu: ACK +09:34 < geertu> (... has pinctrl support) +09:35 < wsa_> that's it from my side. anything left from your side? +09:36 < shimoda> wsa_: about can pinctrl support, I asked Ramesh-san and Ramesh-san will do it. +09:36 < wsa_> Good news, thank you! +09:37 < wsa_> so, core takeover then? +09:38 < geertu> OK, thx diff --git a/wiki/Chat_log/20171109-mm-chatlog b/wiki/Chat_log/20171109-mm-chatlog new file mode 100644 index 0000000..d19b069 --- /dev/null +++ b/wiki/Chat_log/20171109-mm-chatlog @@ -0,0 +1,212 @@ +Multimedia-chat-meeting-2017-11-09 + +10:18 <@pinchartl> so let's start with the multimedia meeting +10:18 <@pinchartl> welcome everybody +10:18 <@pinchartl> (I expect Magnus and Morimoto-san to come back soon) +10:18 <@pinchartl> first topic, status update +10:19 <@pinchartl> Ulrich hasn't sent his status update by e-mail so he should go first, except that he's not here +10:20 <@pinchartl> I expect Magnus to have nothing to report +10:20 < morimoto> pinchartl: I and Magnus is still here. didn't go ;) +10:20 <@pinchartl> morimoto: nice to know :-) +10:20 <@pinchartl> so, for once, I'll start +10:20 <@pinchartl> Since last meeting: +10:20 <@pinchartl> - ELC-E and Linux media summit +10:20 <@pinchartl> - Nearly completed display color keying support for Gen3 +10:20 <@pinchartl> - Started V4L2 lifetime management issues (for VIN Gen3 support) +10:21 <@pinchartl> - Patch review and various discussions +10:21 -!- Irssi: Pasting 5 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +10:21 <@pinchartl> Until next meeting: +10:21 <@pinchartl> - More patch review +10:21 <@pinchartl> - Complete display color keying support for Gen3 +10:21 <@pinchartl> - complete V4L2 lifetime management issues (for VIN Gen3 support) +10:22 -!- Irssi: Pasting 5 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +10:22 <@pinchartl> Issues and Blockers: +10:22 <@pinchartl> - Patch review and technical discussions are taking too much time +10:22 <@pinchartl> Let's wait two more weeks to see if this is only a transient issue. +10:22 <@pinchartl> that's it for me +10:22 <@pinchartl> next, kbingham[m] +10:23 < kbingham[m]> Not a lot to report from me due to parental leave. But I've received and set up my v3m board +10:24 < kbingham[m]> Not actually booted a kernel yet though. And the other point to note was chasing the async parent patch which seems to be stalled on a branch with sakari +10:25 < kbingham[m]> For next, I expect due to v3m blockages I might be best to look at my vin loopback task first +10:26 <@pinchartl> if you want to still test V3M I think that adding I2C in DT should be fairly easy +10:26 <@pinchartl> assuming pins are muxed by the boot loader +10:26 < kbingham[m]> And I also plan to get the du patches respun as part of base to progress my outstanding patchsets. +10:26 <@pinchartl> if you need to deal with PFC, then don't bother for now +10:26 < kbingham[m]> Ok great +10:26 < kbingham[m]> If it's easy l have a go +10:26 < kbingham[m]> Sorry. Mobile device ... I'll have a go :-) +10:27 < kbingham[m]> Eot :-) +10:27 <@pinchartl> thank you +10:27 <@pinchartl> next, neg +10:27 < neg> A) +10:27 < neg> - [PATCH] media: v4l: async: fix unregister for implicitly registered sub-device notifier +10:27 < neg> - Made next version of both rcar-vin and rcar-csi2 ready but not posted, waiting private review from Laurent before posting. +10:27 < neg> - Attended ELCE and Multimedia summit (Thursday and Friday). +10:27 < neg> B) +10:27 < neg> - Post both series for VIN and CSI-2 +10:27 < neg> - See if I can get VIN to work on V3M +10:27 < neg> C) +10:28 < neg> - I want to post VIN patches latest on Friday so if there is to be a private review before I post them publicly please do so soon :-) +10:28 < neg> - Not sure about status of Laurents 'V4L2 lifetime management issues (for VIN Gen3 support)'. Should I post the VIN series without this fix in the framework? +10:28 < neg> --EOT and copy-paste errors-- +10:28 <@pinchartl> Friday might be a bit of a hard deadline for me but I'll do my best +10:28 <@pinchartl> regarding the V4L2 lifetime management issues, just mention that I'm working on it +10:29 < neg> OK, no worries if you don't have time before Friday, are you OK with me posting them to ML anyhow? +10:29 <@pinchartl> yes it is +10:30 < neg> I'm happy to learn you are working on the lifetime management issues :-) Do you think it's worthwile to try and upstream that work and VIN Gen3 in parallel or should the VIN work depend on it? +10:31 <@pinchartl> I don't think the VIN work should really depend on it, it's quite independent +10:32 < neg> OK, then I won't refere to it in the cover letter :-) Thanks for clearing that up for me +10:32 <@pinchartl> you're welcome +10:32 <@pinchartl> next, jmondi2 +10:33 <@pinchartl> (I wonder what happened to jmondi1) +10:33 < jmondi2> pinchartl, I cannot access my VPS this morning where irssi is running +10:33 < jmondi2> so here I am as jmondi2 on xchat +10:33 < jmondi2> btw +10:34 < jmondi2> A) +10:34 < jmondi2> - CEU driver multiplanar API support, data fetch, image capture support on Gr-Peach +10:34 < jmondi2> - Resumed development on Migo-R +10:34 < jmondi2> -- fought with memory issues +10:34 < jmondi2> -- [PATCH] sh: defconfig: Remove NUMA support from Migo-R +10:35 < jmondi2> -- [PATCH] sh: migor: Reserve memory block for CEU +10:35 < jmondi2> -- fought with userspace issues (due to FPU) +10:35 < jmondi2> -- Implemented platfrom data parsing for Migo-R on CEU driver +10:35 < jmondi2> -- Moved sensor drivers away from soc_camera +10:35 < jmondi2> B) +10:36 < jmondi2> - Submit CEU driver to linux-media +10:36 < jmondi2> - Document on elinux.org GR-Peach setup used to develop CEU +10:36 < jmondi2> - Submit to linux-sh Migo-R platform patches to use new CEU driver +10:36 < jmondi2> - Get rid of soc_camera framework from Linux! +10:36 < jmondi2> C) +10:36 < jmondi2> - Issues with CEU HW block enablement on Migo-R (all writes/reads are 0 on the IP Block) +10:37 < jmondi2> - There are more platforms using CEU in arch/sh.. we should port all of them before removing the original driver +10:37 < jmondi2> (and I wonder how we can test them) +10:37 < jmondi2> -- oet +10:37 < jmondi2> --eot +10:37 <@pinchartl> thank you +10:37 <@pinchartl> no need to test them, you can blindly port them +10:37 < jmondi2> love it! +10:37 <@pinchartl> if they compile, that's enough +10:38 < jmondi2> (love it)^2 +10:39 <@pinchartl> :-) +10:39 < jmondi2> I'm a bit worried about the well known low responsivness of sh maintainers, so I won't hold CEU driver integration in linux-media to wait for the SH part +10:39 <@pinchartl> regarding the soc_camera framework +10:39 <@pinchartl> the pxa-camera driver uses it :-( +10:39 <@pinchartl> even if it's in drivers/media/platform/ +10:39 <@pinchartl> Hans said he would handle that +10:39 < jmondi2> doh :( +10:40 <@pinchartl> yes, that was my reaction too +10:40 <@pinchartl> at least without sh_mobile_ceu in the way, Hans will have a bigger incentive to tackle pxa-camera +10:40 < jmondi2> for sure! +10:41 <@pinchartl> thank you for your report +10:41 <@pinchartl> next, morimoto +10:41 < morimoto> ok +10:41 < morimoto> A) What have I done since last time +10:41 < morimoto> Re-send ALSA SoC cleanup patches. 1 month pasted It is very big patch-set, so, I subdivided these "prepare" part into 6 small-patch-sets. Now, 2/6 steps. +10:41 < morimoto> Working with BSP team about sound issue which was pointed from Customer +10:41 < morimoto> B) What I plan to do till next time +10:41 < morimoto> Continue posting patches for ALSA SoC cleanup +10:41 < morimoto> C) Problems I have currently +10:41 < morimoto> None +10:41 < morimoto> --EOF-- +10:42 <@pinchartl> I'm happy to know you have no problem ! +10:42 < morimoto> Oops, I have TCR vs TCRV problem ;P +10:42 <@pinchartl> that's not for multimedia :-) +10:42 < morimoto> s/TCRV/TCRB/ +10:43 < morimoto> but it is related to sound noise :P +10:43 <@pinchartl> indeed +10:43 <@pinchartl> but the problem is in SCIF ;-) +10:43 < morimoto> Yes +10:43 <@pinchartl> anyway, let's see what will happen with the DE bit +10:43 <@pinchartl> thank you for your report +10:43 <@pinchartl> dammsan: anything to add to the usual "N/A" report this time ? :-) +10:44 < morimoto> dammsan said no +10:45 <@pinchartl> could you ask Dammsan whether there's a chance Kieran and I could get an SoW signed before the deadline ? +10:45 <@pinchartl> (I mean the 11/M deadline) +10:46 < morimoto> dammsan said that he already submitted it to Jinso today +10:47 <@pinchartl> \o/ +10:47 <@pinchartl> thank you +10:47 <@pinchartl> that's it for the status updates +10:47 <@pinchartl> topic 2, next meeting +10:47 <@pinchartl> I assume that will be two weeks from now at the same time ? +10:48 < morimoto> pinchartl: I posted request mail for MultiPeria +10:48 < morimoto> Of course, we can discuss it on mail +10:48 <@pinchartl> morimoto: do you mean for the code camp after the FOSDEM ? +10:48 < morimoto> code camp ?? +10:48 <@pinchartl> geertu: does that work for you? +10:48 < morimoto> BSP team request +10:49 <@pinchartl> morimoto: ah that +10:49 <@pinchartl> yes, I've replied +10:49 < morimoto> Sorry for our noise +10:49 <@pinchartl> don't worry +10:49 < morimoto> For neg about rvin_write(vin, 0, VNMC_REG). He already accepted this request. Thank you neg. +10:50 < morimoto> about ADV7511W(HDMI out) and ADV7612(HDMI in) address conflict on D3. +10:50 < morimoto> I don't know who can handle it +10:50 <@pinchartl> address conflict ? have you sent an e-mail about that ? +10:50 < morimoto> and, DU-VSPD connection request +10:52 < morimoto> Yes, address conflict +10:52 < morimoto> Subject: Re: [periperi] 2017-11-09 - Group meeting - Infos & Call for updates +10:52 < morimoto> Date: Tue, 07 Nov 2017 09:57:28 +0900 +10:52 < morimoto> 2nd topic on it +10:53 <@pinchartl> found it, thanks +10:54 <@pinchartl> so there are two chips at the same address +10:54 <@pinchartl> lovely +10:54 < morimoto> orz +10:54 <@pinchartl> could we get the Draak schematics ? +10:54 < morimoto> I think wiki already have it ? +10:54 <@pinchartl> good point :-) +10:55 <@pinchartl> let me check +10:57 <@pinchartl> and how are we supposed to handle that ? +10:57 < morimoto> This is not urgent. But can MultiPeria handle it somehow. maybe next or more next SoW ? +11:00 <@pinchartl> ah, it's about the secondary addresses, not the main address ? +11:01 < morimoto> They said that "But if it uses 0x72 (On Draak), it is same as ADV7612," +11:01 <@pinchartl> no, I'm not sure to see where the problem is +11:01 <@pinchartl> the ADV7612 uses 0x98 or 0x9A for its default address +11:01 < geertu> Ah, there's a secondary address, not mentioned in the schematics? +11:02 < geertu> pinchartl: Meeting in two weeks, or code camp after FOSDEM? +11:02 < geertu> Meeting in two weeks is OK for me +11:02 <@pinchartl> geertu: meeting in two weeks +11:03 <@pinchartl> the code camp is only for mutlimedia +11:03 <@pinchartl> and multimedia too of course +11:03 < geertu> I don't know mutlimedia, but I have a great fantasy about muttimedia ;-) +11:03 < morimoto> In ADV7511W, it has I2C_PACKET register +11:04 < morimoto> this address and ADV7612's HDMI slave address will be conflict, they said +11:05 < morimoto> I noticed that we have more detail info about this. +11:05 < morimoto> I will report it on mail +11:05 <@pinchartl> yes, it will conflict with ADV76XX_PAGE_HDMI +11:05 <@pinchartl> OK, we can handle that +11:05 < morimoto> Thanks. I will post more detail info about that +11:06 <@pinchartl> any other discussion topic ? +11:06 < morimoto> DU-VSPD connection +11:06 < morimoto> Our side opinion is that DT is very OK. +11:08 <@pinchartl> yes, but I don't think it is +11:08 <@pinchartl> it's not a hardware description, it's a particular use case +11:08 <@pinchartl> so we need another way +11:09 < morimoto> DU and VSPD connection are not hardware description ? +11:10 <@pinchartl> VSPD0 is connected to the input of DU's channels 0 and 3, VSPD1 to the input of DU's channel 1 and VSPD2 to the input of DU's channel 2 +11:10 <@pinchartl> that's a hardware description, and that's what we have in DT +11:11 <@pinchartl> now, how to route the DU inputs to the superposition processors inside the DU is not a hardware description, it's a configuration +11:11 <@pinchartl> the input of DU's channel 0 is routed by default to superposition processor 0 +11:11 <@pinchartl> and the input of DU's channel 1 is routed by default to superposition processor 1 +11:11 <@pinchartl> the DU has the ability to route the input of DU's channel 0 to superposition processor 1 +11:11 <@pinchartl> it's internal to the DU and selectable at runtime +11:13 <@pinchartl> the superposition processor 0 can even blend the input of DU's channel 0 and DU's channel 1 +11:14 <@pinchartl> luckily it seems we don't need this feature for now +11:14 <@pinchartl> (and hopefully never) +11:15 <@pinchartl> I'd like to know more about the use case and why the customer wants to connect VSPD1 to DU0 +11:15 < morimoto> Can you check +11:15 < morimoto> Subject: Re: [periperi] How to connect VSPD0 to DU1? +11:15 < morimoto> +11:15 < morimoto> Date: Wed, 8 Nov 2017 00:48:29 +0000 +11:15 < morimoto> +11:15 <@pinchartl> yes, I'll reply to the last e-mail +11:16 < morimoto> OK, thanks +11:16 <@pinchartl> any other general discussion topic ? +11:17 < morimoto> nothing from me. thanks +11:17 < neg> not from me, I'm happy :-) +11:17 <@pinchartl> jmondi2: are you happy too ? +11:17 <@pinchartl> and kbingham[m] ? +11:18 < jmondi2> pinchartl: nothing from here! +11:18 < kbingham[m]> I'm happy. +11:19 < kbingham[m]> Covered in baby pee. But sure. Happy :-) +11:19 <@pinchartl> if it's all rainbows and unicorns, then let's close this meeting +11:19 <@pinchartl> thank you all for attending diff --git a/wiki/Chat_log/20171123-mm-chatlog b/wiki/Chat_log/20171123-mm-chatlog new file mode 100644 index 0000000..3b34e7e --- /dev/null +++ b/wiki/Chat_log/20171123-mm-chatlog @@ -0,0 +1,173 @@ +Multimedia-chat-meeting-2017-11-23 + +08:59 < neg> morning +09:00 < uli___> good morning +09:00 <@pinchartl> huomenta +09:00 <@pinchartl> it looks like there will be no core and I/O meeting today +09:01 < kbingham[m]> Moaning :-) +09:01 < kbingham[m]> (making tea then switching to laptop) +09:02 <@pinchartl> the multimedia meeting was originally scheduled for 10:00 CET, but as there's no core or I/O portion, I suppose we can start right away +09:02 <@pinchartl> although we might be missing jmondi ? +09:03 < neg> pinchartl: hum just to clear that my new calender thinig handles timezoens ok, the invitation sent out was that for MM at 9 or 10? +09:04 < jmondi> no no, I'm here! +09:04 <@pinchartl> it was sent for 9:00 CET, adding to the confusion (or the lack of confusion, I don't know) +09:04 <@pinchartl> jmondi: hello +09:04 < jmondi> pinchartl: Hi there! +09:05 <@pinchartl> let's start as soon as Kieran's tea is ready +09:06 < kbingham[m]> Do start. I don't think I'm first :-) +09:06 <@pinchartl> ok :-) +09:06 <@pinchartl> so let's start with... +09:06 <@pinchartl> uli___: your turn +09:07 < uli___> ok +09:07 < uli___> so i ported the chromeos gpu driver to mainline +09:07 < uli___> and it sometimes works +09:07 < uli___> usually it fails while waiting for the GPU firmware to boot +09:07 < uli___> i think it's a power management issue +09:08 < uli___> i'll give matthias brugger's new mmsys implementation a try +09:08 < uli___> that might help because it manages the clocks +09:08 <@pinchartl> when it doesn't fail to boot, does it render opengl correctly ? +09:08 < uli___> yes +09:08 < uli___> sometimes it freezes after a few frames, but usually it works +09:09 < uli___> at any rate, this is not a problem that is likely to translate to gen3 +09:09 < uli___> so i'm not too worried about it for the next task +09:09 < uli___> that's it for me +09:10 <@pinchartl> ok +09:10 <@pinchartl> I'm not sure I agree with that conclusion, but we'll see anyway :-) +09:11 <@pinchartl> thank you +09:11 < neg> uli___: your GPU work sounds interesting :-) +09:11 <@pinchartl> next is... +09:11 <@pinchartl> neg: your turn +09:11 < neg> A) +09:11 < neg> - [PATCH] v4l: async: use the v4l2_dev from the root notifier when matching sub-devices +09:11 < neg> - [PATCH v11 0/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 +09:11 < neg> - [PATCH v7 00/25] rcar-vin: Add Gen3 with media controller +09:11 < neg> - Clarified last issue for VIN upstreming with Laurent and Hans +09:12 < neg> - Begun rebasing multiple stream work on-top of Sakari's vc branch. +09:12 < neg> B) +09:12 < neg> - Once -rc1 is public post next versions of VIN and CSI-2 which I have hopes this is coming to an end :-) +09:12 < neg> - Add V3M VIN routing table to VIN driver, and if nothing much else is missing on V3M test it. +09:12 < neg> - Post new base of VIN and CSI-2 for vin/mux+gmsl. This will use the latest VIN and CSI-2 drivers but the first multiple stream prototype as before. +09:12 < neg> - Continue the multiple stream work +09:12 < neg> C) +09:12 < neg> - None +09:12 < neg> --EOT-- +09:13 <@pinchartl> thank you +09:13 <@pinchartl> next is... +09:13 <@pinchartl> kbingham[m]: is your tea ready ? +09:13 < kbingham> pinchartl: Nice and hot yes :) +09:14 < kbingham> So for me, since last meeting has been revisiting my pending patchsets, tlb and +09:14 < kbingham> DL caching, and the support for suspend resume which didn't make it to mainline +09:14 < kbingham> yet. +09:14 < kbingham> From there - I've been mostly looking at V3M, and had a few stumbling points getting the board booting a default configuration. +09:15 < kbingham> That's now resolved, and I've been working towards getting the dependencies for more useful systems to work. +09:15 < kbingham> So I've now pulled in I2C and PFC support from Sergei's patches, (and Geert's integration branch) ... and started populating the DTB with more devices as specified on the data sheet. +09:16 < neg> kbingham: thanks for making your V3M i2c branch public :-) +09:16 < kbingham> Next, - I'll continue on the V3M for a bit - but I wonder if I should wait for Neg to look at the VIN routing ... +09:16 < kbingham> Otherwise I'll keep ploughing through whatever seems useful. +09:17 <@pinchartl> neg: when do you expect to post a patch for the VIN routing table ? +09:17 < kbingham> I still ahve the VIN loopback tests to look at so I won't be blocked if I wait for neg to do his bit - and he'll be more effective at VIN routes than me :) +09:18 < Marex> geertu: enjoyed what ? +09:18 < kbingham> neg: No worries- I thought it owuld be useful to you - and was more work to get to that point than I would have liked. Didn't want you to have to repeat it +09:18 < kbingham> So for me - VIN routes might be considered a blocker =- but other than that I seemingly have lots to do . +09:18 < kbingham> EOT. +09:19 <@pinchartl> kbingham: I think it makes sense to wait for Niklas, yes. you can move forward with I2C if you want up to the point where devices are detected, but for VIN support itself I'd leave it to Niklas +09:19 < kbingham> pinchartl: Ack. +09:19 < neg> pinchartl: goal is this week, just need to finish the VIN vdev registration probe() -> complete() which I hope I will manage today +09:19 < kbingham> Well hopefully I've saved neg some days :) +09:20 <@pinchartl> thank you +09:20 <@pinchartl> kbingham: I think you have :-) +09:20 < neg> kbingham: lookig at the hoops you jumped for V3M boot you saved me lots of time :-) +09:21 < kbingham> stooooopid hoops. +09:22 <@pinchartl> kbingham: feel free to tell Sergei to thread his patches +09:22 <@pinchartl> next is... +09:22 <@pinchartl> jmondi: your turn +09:22 < jmondi> yep +09:22 < kbingham> Ugh ... and that was annoying too - :D +09:22 < geertu> Marex: chocolates (in response to marex-cloud) +09:23 < jmondi> A) - submitted CEU driver to linux media and ported Migo-R to use the new CEU driver +09:23 < jmondi> - submitted patches for Migo-R and SH4 memory management +09:23 < jmondi> - resumed gmsl work: re-collecting patches for now and questions to Maxim +09:24 < jmondi> B) gmsl: several patches I need to rebase and retest +09:24 < jmondi> - check waht's in Cogent code-drop we have been notified about more than 1 month ago +09:24 < jmondi> - hope to receive answers from maxim +09:24 < jmondi> -- eot -- +09:24 < jmondi> that was quick! +09:25 < kbingham> jmondi: if you're planning to rebase the gmsl patches ... what base are you planning ? +09:26 < jmondi> kbingham: on top of your stabilization series +09:26 < jmondi> which currently is not part of gmsl/base +09:26 < kbingham> aha I see. +09:26 < jmondi> kbingham: you should send a v2, right? +09:26 < kbingham> You're not planning to rebase .. .the 'base' then. +09:26 < kbingham> jmondi: Oh - Do I have work there - I didn't realise ... sorry ... I'll take a look today. +09:27 < jmondi> kbingham: just trying to remember as well +09:28 < neg> the base of VIN+CSI-2 should be refreshed if the new base should be v4.15-rc1 due to the different async subnotifer implementations +09:28 < jmondi> kbingham: GMSL Stabilisation V2 +09:29 < jmondi> it was "v2", it just has "PATCH" in the subject in place of "PATCH v2".. sorry about this +09:29 < jmondi> neg: yeah, I read your answer from yesterday, thanks... that will be another rebase, for later :) +09:29 < kbingham> jmondi: Oh - sorry I must have misnumbered the patches. +09:30 < jmondi> no problem, got confused by the subject :) +09:31 <@pinchartl> next is... +09:31 <@pinchartl> me +09:31 < jmondi> kbingham: you actually have comments on v2... so yes, a v3 is needed somewhen +09:31 < kbingham> jmondi: Ok - I'll try to do that :) +09:31 -!- Irssi: Pasting 5 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +09:31 <@pinchartl> Since last meeting: +09:31 <@pinchartl> - Posted new version of DU plane boundaries fixes +09:31 <@pinchartl> - Posted DU dmabuf import fixes +09:31 <@pinchartl> - Posted V4L2 unbind/userspace race condition handling RFC +09:31 -!- Irssi: Pasting 8 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +09:31 <@pinchartl> Until next meeting: +09:31 <@pinchartl> - More patch review +09:31 <@pinchartl> - Complete display color keying support for Gen3 +09:31 <@pinchartl> - New version of the DU plane boundaries fixes +09:31 <@pinchartl> - New version of the V4L2 unbind/userspace race condition handling +09:31 <@pinchartl> - Test DU dmabuf import fixes locally +09:31 <@pinchartl> - Start reworking video device registration code +09:32 <@pinchartl> The goal is to allow video device registration at probe time. As an intermediate step, Hans Verkuil wants video device registration to be split into initialization and registration functions. +09:32 <@pinchartl> Issues and Blockers: None +09:32 <@pinchartl> --EOT-- +09:32 <@pinchartl> oh, I forgot to mention I have discussed video device registration issues with Niklas, Sakari and Hans +09:33 <@pinchartl> Hans still doesn't like registering video devices at probe time, we need to continue working on convincing him +09:33 < kbingham> when would he prefer they are registered? +09:33 <@pinchartl> at complete() time +09:34 < jmondi> pinchartl: I am missing in this discussion why it is bad to register video device at complete() time +09:34 < jmondi> because "complete()" might never not be called if one subdev fails? +09:34 < kbingham> Ahh .. I guess this would put me on the 'probe' side too then ... because I want device to exist if they exists :) +09:34 < neg> pinchartl: just a heads up for your unbind/bind race condition testing, whith the next VIN patches this will be borked as the registration is moved to complete() so using that for testing won't work :-( +09:35 <@pinchartl> his opinion is that the driver should be fully ready to be used as soon as video device nodes appear, as userspace currently relies on this behaviour +09:35 <@pinchartl> neg: I know :-/ I wanted to test it on subdevs, but subdev registration is ever more broken +09:35 < kbingham> pinchartl: Is this discussion on ML or IRC? +09:35 < kbingham> (*was) +09:35 <@pinchartl> and I don't think we should fix it, as the goal is to replace subdev nodes with the request API +09:36 <@pinchartl> kbingham: IRC +09:36 <@pinchartl> partly in #v4l, partly in #rcar-vin +09:36 < kbingham> Ahh ok. +09:36 <@pinchartl> (the latter for a private discussion with Niklas and Sakari) +09:36 < kbingham> :D +09:38 <@pinchartl> that's it for status reports +09:38 < neg> pinchartl: at least the device reattach() code is now removed :-) I cried a bit when I found that gem +09:38 <@pinchartl> anything else to discuss ? +09:39 < neg> Out of curiosity I'm interested in the current goal for GMSL work +09:39 < jmondi> not really, it's a bit too early to discuss about meetings I guess.. +09:39 < kbingham> neg: Make it actually work ? :) +09:40 < neg> I have no planed work for that in Q4 other then to provied a new base for jmondi, but wondering if someone is expecting me to do anything else in this area +09:40 < jmondi> neg: I think I'm the only one with gmsl work this batch... on my side I have to "make frame sync happen" +09:40 < jmondi> or at least try to +09:40 <@pinchartl> neg: you're good for Q4 :-) +09:41 < kbingham> neg: You mean aside from providing V3M VIN routing / :) +09:41 < neg> kbingham: :-) +09:43 <@pinchartl> As Core and I/O have skipped this meeting, the next joint meeting will be held one week from now, on Thursday 2017-11-30 at 08:00 GMT / 09:00 CET / 10:00 EET / 17:00 JST. We will have a brief Multimedia meeting at 09:00 GMT / 10:00 CET / 11:00 EET / 18:00 JST which you can skip if you have nothing to report (in this case please notify me on the periperi mailing list beforehand). +09:44 < kbingham> When should we plan #PeriMediaSnowConf :) +09:46 <@pinchartl> that's a very very good question +09:46 <@pinchartl> it would be the week after the FOSDEM +09:46 <@pinchartl> would you like to help me organizing it ? :-) +09:48 < jmondi> pinchartl: let's share effort... maybe starting with an email for a call for partecipants, should we? +09:49 < neg> I don't know much about the alps but tried to get information from a friend the other day and without a location in mind I could not get much other then week 6 (feb 05-11) is the week where prices starts to spike for the season acording to him +09:50 <@pinchartl> the French winter school holidays start on February the 10th, so that's usually when prices rise +09:51 <@pinchartl> (and were the slopes get crowded) +09:51 < neg> And I agree with jmondi a mail thread would be good to start locking things down such as time, location and partecipants :-) +09:52 <@pinchartl> I'll send you +09:52 <@pinchartl> today +09:53 <@pinchartl> so that's it for today +09:53 <@pinchartl> thank you all for attending +09:53 < kbingham> cheers all. diff --git a/wiki/Chat_log/20171130-core-chatlog b/wiki/Chat_log/20171130-core-chatlog new file mode 100644 index 0000000..c2aaf94 --- /dev/null +++ b/wiki/Chat_log/20171130-core-chatlog @@ -0,0 +1,154 @@ +Core-chat-meeting-2017-11-30 + +09:25 < neg> horms: quick question, what is the upstream plan (if any) for 'arm64: dts: r8a7795: Add OPPs table for cpu devices' et. al. ? +09:25 < horms> ok, that is a good question +09:26 < wsa_> horms: I'll check the I2C bus recovery on ES1.0, too, later this week. This is based on i2c/for-next which is based on v4.15-rc1. I'll let you know +09:26 < shimoda> horms: about small tasks, i have some items that issues in v4.14 but bsp patches can resolve it. it is related to suspend to ram +09:26 < geertu> horms: renesas-drivers with renesas_defconfig boots on Salvator-X/H3 ES1.0 +09:27 < horms> possibly it can go upstream if I clean it up a bit. would that help you? the bigger question is CPUFreq. THere I seem to have some problem getting the Z clk patches working. The fixed /2 divider seems to be a problem for me. I wonder if I could get some advice on how to fix it. Or at least what the propper behaviour to be observied in /sys is. My previous effort seemed to go in the wrong direction :( +09:27 < horms> shimoda: thanks, they sound like great candidates. Perhaps we can discuss on the periperi ML? +09:27 < geertu> horms: With the fix from the BSP, Z and Z2 are correct for me on H3 ES2.0 and M3-W +09:27 < wsa_> okay, we entered the core realm already, me thinks +09:27 < horms> Or here, a bit later, if you like +09:27 * wsa_ throws the mic to Geert +09:28 * geertu misses +09:28 < wsa_> thank you all for the IO meeting! +09:28 < shimoda> horms: i got it. i'll send this topic to the ML later +09:28 * geertu picks it up from the floor +09:28 < horms> geertu: ok. but are they correct when you change CPU frequency? +09:28 < horms> I can check again but it seemed kinda bogus to me +09:28 < geertu> horms: Haven't checked that. +09:28 < horms> geertu: ok. How about I collect some results and we can discuss properly +09:28 < geertu> There's an /2 or *2 missing +09:28 < horms> Yes, I understand that +09:29 < wsa_> geertu: guess you were surprised because it was 2 minutes early ;) +09:29 < horms> what I'm confused about is what the correct values to be read out of /sys are +09:29 < horms> but I can collect data, using the BSP fixes +09:29 < horms> and we can take it from there +09:29 < geertu> It should be 1.5 GHz after boot +09:29 < horms> what should be 1.5 GHz after boot? +09:29 < neg> horms: my interest is that it's blocking the thermal cooling patches, no biggi but on my task list :-) +09:29 < geertu> z clock +09:29 < horms> ok +09:29 < horms> and the cpu frequencies too, I suppose +09:30 < geertu> I always look at /sys/.../clk_summary differences after every boot +09:30 < horms> what should z clock be after the CPU clock is changed, say to 1.0GHz? +09:30 < geertu> 1.0 GHz +09:30 < geertu> Z clock == the CPU clock +09:30 < horms> ok +09:30 < horms> I assume that is ~= +09:30 < geertu> v4.15-rc1 also boots on Salvator-X/H3 ES1.0 +09:31 < horms> ok, it must have been me. did you use renesas_defconfig? +09:31 < geertu> Any chance Kaneko-san had the "move pmu nodes outside /soc" applied, without the interrupt-parent? +09:31 < geertu> Then it will hang, without output if not using earlycon +09:31 < geertu> For renesas-drivers I used renesas_defconfig +09:32 < geertu> After checking out v4.15-rc1, I ran oldconfig +09:32 < horms> It was me and it was without that patch +09:32 < horms> ok, thanks +09:32 < geertu> OK, so Welcome to today's Core Group Meeting! +09:32 < geertu> Although we've been in core territory for a few minutes +09:33 < neg> wsa_: thanks for IO meeting :-) +09:33 < geertu> Agenda: +09:33 < geertu> 1. Status updates +09:33 < geertu> 2. Discussion Topics +09:33 < geertu> I'll reply the status updates, FTR +09:34 < geertu> A) What have I done since last time +09:34 < geertu> Geert: +09:34 < geertu> - Sent v2 of genpd active_wakeup fixes (incl. interrupt routing), +09:34 < geertu> documented at +09:34 < geertu> https://elinux.org/R-Car/Tests:System-Suspend-and-Wake-Up +09:34 < geertu> - Reworked sh-sci Kconfig, +09:34 < geertu> - Fixed DT overlays for v4.14 and v4.15-rc1, +09:34 < geertu> - Resent patches after release of v4.15-rc1. +09:34 < geertu> Marek: +09:34 < geertu> - Massive cleanup of the Gen3 in U-Boot: +09:34 < geertu> - Removed most of the CONFIG_R8A779x checks, instead use PRR CPU ID +09:34 < geertu> - Wrote PRR syscon driver +09:34 < geertu> - Unified CONFIG_R8A779x as CONFIG_RCAR_GEN3 where applicable +09:34 < geertu> - Removed a lot of hard-coded config options and replaced them with +09:34 < geertu> fetching the configuration from DT +09:34 < geertu> - Removed _a_lot_ of unused macros +09:34 < geertu> - Implemented DT/DM capable IIC driver for the DVFS I2C bus +09:34 < geertu> - Fixed up minor bugs on M3/H3 ULCB +09:34 < geertu> - Fixed up the CPLD driver on ULCB so that reset actually works +09:34 < geertu> - Submitted all the stuff upstream [1]...[7] +09:34 < geertu> [1] http://patchwork.ozlabs.org/project/uboot/list/?series=15669 +09:34 < geertu> [2] http://patchwork.ozlabs.org/patch/842402/ +09:34 < geertu> [3] http://patchwork.ozlabs.org/patch/842403/ +09:34 < geertu> [4] http://patchwork.ozlabs.org/patch/842404/ +09:34 < geertu> [5] http://patchwork.ozlabs.org/patch/842405/ +09:34 < geertu> [6] http://patchwork.ozlabs.org/patch/842406/ +09:34 < geertu> [7] http://patchwork.ozlabs.org/patch/842407/ +09:34 < geertu> Niklas: +09:34 < geertu> - Hooked up and verified V3M functionality. +09:34 < geertu> - Had first look at 'Add support for more than 32-bits IOVA space', not much +09:34 < geertu> progress. Please see 'Re: [PATCH/RFC] iommu/ipmmu-vmsa: Initial R-Car Gen3 +09:34 < geertu> VA64 mode support' from 2017-11-13. +09:34 < geertu> Shimoda: +09:34 < geertu> - Test M3-N's IPMMU (stage-2 format). +09:34 < geertu> - Investigate M3-N IPMMU issue. +09:34 < geertu> Simon: +09:34 < geertu> - Posted, now accepted +09:34 < geertu> IPMMU integration patches +09:34 < geertu> pinctrl upports from BSP +09:34 < geertu> - Posted, changes requested: +09:34 < geertu> [PATCH v3] arm64: dts: renesas: r8a7795: Move nodes which have no reg +09:34 < geertu> - Posted, under review +09:34 < geertu> IPMMU bindings and driver patches +09:34 < geertu> Ulrich: +09:34 < geertu> - Sent various Draak integration patches (SYS-DMAC, I2C, SDHI/eMMC, CAN). +09:34 [Users #periperi] +09:34 [@pinchartl] [ horms ] [ kbingham[m]] [ mturquette] [ uli___] +09:34 [ dammsan ] [ jmondi ] [ Marex ] [ neg ] [ wsa_ ] +09:34 [ geertu ] [ kbingham] [ marex-cloud] [ shimoda ] +09:34 -!- Irssi: #periperi: Total of 14 nicks [1 ops, 0 halfops, 0 voices, 13 normal] +09:35 < geertu> B) What I plan to do till next time +09:35 < geertu> Geert: +09:35 < geertu> - Sent sh-sci Kconfig rework, +09:35 < geertu> - Initial support for Salvator-X with R-Car M3-N? +09:35 -!- wsa_ [~wsa@p54B33377.dip0.t-ipconnect.de] has quit [Quit: ...] +09:35 < geertu> Marek: +09:35 < geertu> - Continue with my quest to make U-Boot on Gen3 easy to use and port +09:35 < geertu> to new boards +09:35 < geertu> - Again push for HS200/SDR104 MMC core changes to get into U-Boot +09:35 < geertu> - Fix up U-Boot for V3M (and D3 when it become available to me) +09:35 < geertu> Niklas: +09:35 < geertu> - If free time keep banging at the 'Add support for more than 32-bits IOVA +09:35 < geertu> space', most likely not. +09:35 < geertu> Shimoda: +09:35 < geertu> - Add usb3.0 phy device node for r8a779[56].dtsi. +09:35 < geertu> Simon: +09:35 < geertu> - Continue fixing nodes which have no reg +09:35 < geertu> - Follow up on IPMMU bindings patches +09:35 < geertu> - Address review of CPUFreq/Z,Z2 Clock patches +09:35 < geertu> - Upport BSP patches +09:35 < geertu> 55f32e9ad018 clk: renesas: r8a7795: Change the RINT and OSC clocks frequency with reference to MD{13,14} +09:35 < geertu> 575998792004 clk: renesas: r8a7796: Change the RINT and OSC clocks frequency with reference to MD{13,14} +09:35 < geertu> fba4b288aba2 clk: renesas: rcar-gen3: Delete the RCKCR register definition +09:36 < geertu> C) Problems I have currently +09:36 < geertu> Geert: +09:36 < geertu> - Missing V3MSK docs hampering review. +09:36 < geertu> Marek: +09:36 < geertu> - The SD/MMC maintainer in U-Boot is slow +09:36 < geertu> EOT +09:36 < geertu> I don't think we can fix the second problem here? +09:37 < geertu> Anything I missed? +09:37 < geertu> I didn't receive reports fom +09:37 < geertu> jmondi: ? +09:37 < geertu> pinchartl: ? +09:37 < geertu> dammsan: ? +09:38 < jmondi> geertu: no core work for me! +09:38 < geertu> Morimoto-san is excused +09:38 < geertu> jmondi: Thanks for chiming in! +09:38 < jmondi> geertu: yeah, sorry, I should have told in advance +09:40 < geertu> Is V3MSK handled by a different business unit? +09:43 < shimoda> geertu: i don't know about V3MSK. oh, Cogent is submiting patches. So, I should ask V3M key person later +09:44 < geertu> shimoda: OK, thank you +09:44 < geertu> 2. Discussion Topics +09:44 < geertu> Seems core is quiet and going steady. +09:45 < geertu> Anything you want to discuss? +09:45 < Marex> geertu: I am suffering with RPC SPI on V3M, but I think I can manage somehow +09:46 < geertu> Marex: Good (the "manage" part ;-) +09:47 < geertu> I guess we will start thinking about core additional tasks for Q1/2018 soon, just like for I/O +09:51 < geertu> If there's nothing more to discuss, let's conclude the meeting. +09:51 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20171130-io-chatlog b/wiki/Chat_log/20171130-io-chatlog new file mode 100644 index 0000000..5fff67f --- /dev/null +++ b/wiki/Chat_log/20171130-io-chatlog @@ -0,0 +1,121 @@ +09:03 < wsa_> so, let's start the IO meeting and be welcome to that +09:04 < wsa_> I prepared a summary for the status-updates: +09:04 < wsa_> A) +09:04 < wsa_> Geert: +09:04 < wsa_> * Working on MSIOF (GPIO/SS1/SS2 slave select), +09:04 < wsa_> * Ethernet PHY reset v4 (needed for Salvator-XS resume). +09:04 < wsa_> Shimoda: +09:04 < wsa_> * Got feedback from HW team about HS-USB and investigate the driver how to implement it. +09:04 < wsa_> * Investigate runtime PM issue on R-Car Gen3 + USB host controllers. +09:04 < wsa_> * Submitted the following patch(es): +09:04 < wsa_> * Fix the USB3.0 peripheral driver that has just 5 pipes. +09:04 < wsa_> * Merged the "Add PWM dt-binding for r8a77995." into v4.15-rc1. +09:04 < wsa_> Simon: +09:04 < wsa_> * Got some patches accepted +09:04 < wsa_> * worked on HS400 support for SDHI +09:04 < wsa_> Wolfram: +09:04 < wsa_> * cured some kind of indigestion, back to full strength now +09:04 < wsa_> * implemented various IIC fixes requested by Shimoda-san/ +09:04 < wsa_> customer team +09:04 < wsa_> * improved I2C core bus recovery and implemented recovery for +09:04 < wsa_> i2c-rcar on top of that +09:04 < wsa_> * discussed SDHI naming scheme with Yamada-san +09:04 < wsa_> * reviewed various SDHI patches, mainly from Yamada-san +09:04 < wsa_> * quite some stuff got merged after rc1 :) +09:04 < wsa_> (IIC fixes, mmc_delay refactoring, I2C DMA series) +09:04 < wsa_> * had a look at Uli's D3 patches, but usually Geert is +09:04 < wsa_> faster than me ;) +09:04 < wsa_> Uli: +09:04 < wsa_> * Sent various Draak integration patches (SYS-DMAC, I2C, SDHI/eMMC, CAN) +09:04 < wsa_> * resent "R-Car D3 (r8a77995) SDHI (eMMC) integration" +09:04 < wsa_> B) +09:04 < wsa_> Geert: +09:04 < wsa_> * Continue MSIOF (GPIO/SS1/SS2 slave select, ...), +09:04 < wsa_> * Post Ethernet PHY reset v4 after opening of net-next merge window. +09:04 < wsa_> Shimoda: +09:04 < wsa_> * Submit renesas_usbhs driver paches about dequeue handling. +09:04 < wsa_> * Continue to investigate the runtime PM issue. +09:04 < wsa_> * Investigate USB3.0 role swap issue. +09:04 < wsa_> Simon: +09:04 < wsa_> * Continue work on enabling HS400 +09:04 < wsa_> * Try to enable SDR-50 and SRR-104 on porter (patch posted, needs testing) +09:04 < wsa_> * Upport BSP patch +09:04 < wsa_> ed8730231a98 arm64: dts: r8a7795-es1-h3ulcb: Enable UHS-I SDR-104 +09:04 < wsa_> Wolfram: +09:04 < wsa_> * write elinux test page for i2c-rcar bus recovery +09:04 < wsa_> * upstream I2C core switcher DTS changes +09:04 < wsa_> * prepare add. tasks for Q1/2018 +09:05 < wsa_> Uli: +09:05 < wsa_> * Send new revision of Draak I2C series. +09:05 < wsa_> C) +09:05 < wsa_> none! +09:05 < wsa_> The notes/questions I have: +09:06 < wsa_> horms: the SDR104 thing on porter might not working because the issue we have seen on alt is not fixed yet +09:07 < wsa_> I hope I can have a look after finishing the I2C bus recovery add. task +09:07 < horms> ahh. so I did test it. and it did not work. but I assumed I was doing something wrong and planned to come back to it. +09:07 < horms> I also noticed brokenness on Alt yesterday when testing something else (SMP) +09:07 < wsa_> uh, nice to know +09:07 < geertu> wsa_: So your assumption is that it's not SoC-specific, but board-specific? +09:08 < wsa_> geertu: it might even be a driver thing +09:08 < wsa_> neg found a revert which made it work for him again on Koelsch +09:08 < wsa_> have to verify this on alt, though +09:09 < neg> I think the sum of my findings are in '[RFC] mmc: tmio: fix tuning for stubborn cards' +09:10 < wsa_> horms: in general, how is HS400 coming along? did hell break loose, or is it not as bad? ;) +09:10 < horms> Its not going great +09:10 < horms> I backported a bunch of patches. +09:10 < wsa_> geertu: and well, yes, it is card specific +09:10 < horms> M3-W seems to not detect devices any more +09:11 < horms> H3 ES1.0 detects the device but it is slower +09:11 < horms> I need to make sure I have the latest from uptream as my base, in particular drive strength featues in the driver and DT +09:11 < Marex> horms: HS400 had issues in uboot too, just FYI, I didnt manage to tune it +09:12 < horms> My plan was to try to do some triage and report to the ML +09:12 < geertu> Non-matched PCB traces? +09:12 < wsa_> drive_strength is in 4.16-rc1 +09:13 < horms> s/15/16/ ? +09:13 < wsa_> 15 +09:13 < wsa_> heh, sorry +09:13 < horms> I think I had the driver portion in my most recent branch, as I based it on mmc/next +09:13 < wsa_> does the BSP work? +09:13 < horms> But I also think I was missing the DT bit which is in my devel branch (I didn't realise that at the time) +09:14 < horms> That is a good question. My assumption is yes. I will test. +09:14 < wsa_> If so, it would rule out HW problems to a high degree +09:14 < horms> good point +09:15 < wsa_> so, good luck with that! +09:16 < wsa_> shimoda: could you kindly provide me with a diff-style update for the io-todo file? I am not sure I can map the patch descriptions from your patches to the task titles 100% correctly :) +09:17 < horms> Thanks +09:17 < shimoda> wsa_: sure. I will send it by email later +09:17 < wsa_> Thank you! +09:18 < wsa_> So, the final not from me is that I'd like to start looking at add tasks for Q1/2018 slowly. +09:19 < wsa_> Maybe we can start talking about it in 2 weeks during an all-groups-meeting? +09:19 < wsa_> I will contact you individually for tasks I might have at hand to negotiate if there is interest +09:20 < wsa_> And please contact me if you see IO related tasks for you +09:21 < horms> Two from me, if there is time. +09:21 < geertu> Sounds good to me +09:21 < wsa_> horms: nice, can you mail them to me? +09:22 < horms> Not tasks, questsions for now :) +09:22 < wsa_> :D +09:22 < wsa_> then, please +09:22 < wsa_> fire away now +09:22 < horms> 1. If you have any small tasks that Kaneko-san might handle in the immediate future feel free to ask +09:23 < horms> 2. Does v4.15-rc1 work on Salvator-X/H3 ES1.0 or is it just me? +09:23 < horms> -- fin -- +09:23 < geertu> horms: Last renesas-drivers is supposed to work on that +09:24 < wsa_> horms: Thanks! I'll check if I have something for Kaneko-san... +09:24 < horms> geertu: ok, but v4.15-rc1 is broken? +09:24 < geertu> horms: Not AFAIK +09:24 < horms> wsa_: thanks. I've been mining the BSP but a lot of what was on my list is now upstream +09:24 < horms> geertu: ok, I'll assume it was just me +09:25 < horms> that was all, thanks! +09:25 < neg> horms: quick question, what is the upstream plan (if any) for 'arm64: dts: r8a7795: Add OPPs table for cpu devices' et. al. ? +09:25 < horms> ok, that is a good question +09:26 < wsa_> horms: I'll check the I2C bus recovery on ES1.0, too, later this week. This is based on i2c/for-next which is based on v4.15-rc1. I'll let you know +09:26 < shimoda> horms: about small tasks, i have some items that issues in v4.14 but bsp patches can resolve it. it is related to suspend to ram +09:26 < geertu> horms: renesas-drivers with renesas_defconfig boots on Salvator-X/H3 ES1.0 +09:27 < horms> possibly it can go upstream if I clean it up a bit. would that help you? the bigger question is CPUFreq. THere I seem to have some problem getting the Z clk patches working. The fixed /2 divider seems to be a problem for me. I wonder if I could get some advice on how to fix it. Or at least what the propper behaviour to be observied in /sys is. My previous effort seemed to go in the wrong direction :( +09:27 < horms> shimoda: thanks, they sound like great candidates. Perhaps we can discuss on the periperi ML? +09:27 < geertu> horms: With the fix from the BSP, Z and Z2 are correct for me on H3 ES2.0 and M3-W +09:27 < wsa_> okay, we entered the core realm already, me thinks +09:27 < horms> Or here, a bit later, if you like +09:27 * wsa_ throws the mic to Geert +09:28 * geertu misses +09:28 < wsa_> thank you all for the IO meeting! diff --git a/wiki/Chat_log/20171214-core-chatlog b/wiki/Chat_log/20171214-core-chatlog new file mode 100644 index 0000000..ff803b9 --- /dev/null +++ b/wiki/Chat_log/20171214-core-chatlog @@ -0,0 +1,150 @@ +Core-chat-meeting-2017-12-14 + +09:33 < wsa_> and with that I'd hand over to Geert for the core meeting +09:33 < geertu> One more questions (joined with core) +09:33 < wsa_> sure +09:33 < geertu> Meeting before FOSDEM +09:33 < geertu> Who will join: +09:33 < geertu> 1. Core Meeting (Friday morning) +09:33 < geertu> 2. Meeting Lunch +09:33 < geertu> 3. I/O Meeting (Friday afternoon) (or swap with morning?) +09:33 < geertu> 4. Meeting Dinner (@ KoKoB?) +09:34 < pinchartl> I plan to attend the whole day +09:34 < morimoto`> From Renesas side, noone goes to FOSDEM +09:34 < jmondi> me for 1) 2) 3) and 4) +09:34 < wsa_> I will be there +09:34 < horms> I plan to arrive on Thursday for dinner and depart on Saturday. I will likely need to step out for an hour, around 1600, on Friday +09:35 < wsa_> geertu: we also want to have add. task discussion on Friday +09:35 < horms> I already booked a room at Hotel BLOOM :) +09:35 < geertu> wsa_: OK, so meeting schedule is flexible +09:35 < horms> I have not yet asked the boss (my wife) +09:35 < neg> I will join the whole day +09:36 < geertu> horms: But you booked anyway ;-) +09:36 < wsa_> geertu: you plan the meeting room @ BLOOM again? +09:36 < horms> geertu: yes, i did :) +09:36 < geertu> wsa_: Yes +09:36 < pinchartl> morimoto`: so all trips have been cancelled ? :/ +09:36 < Marex> I'll join 1)...4) too +09:37 < Marex> morimoto`: :-( +09:37 < geertu> uli___: pinchartl : What about you? +09:37 < pinchartl> geertu: 09:34 < pinchartl> I plan to attend the whole day +09:38 < geertu> And no delegation from Japan? ;-( +09:38 < morimoto`> pinchartl: Yes. Renesas side doesn't go +09:38 < uli___> geertu: ask me again next year, please :) +09:38 < pinchartl> dammsan: how about you, do you plan to attend the FOSDEM ? +09:38 < morimoto`> I will miss you... +09:38 < pinchartl> morimoto`: that's bad news :( +09:38 < neg> uli___: :-) +09:39 < geertu> uli___: Will the answer be different? +09:39 < morimoto`> dammsan is included as "Renesas side" +09:39 < wsa_> so add. task meeting will be way more difficult +09:39 < uli___> geertu: possibly +09:39 < wsa_> and, yes, you guys will be missed +09:40 < horms> Can we schedule some sort of remote access to part of the meeting? +09:40 < geertu> morimoto: I thought he was ÖpenSöurce? ;-) +09:40 < horms> Not ideal but perhaps better than nothing +09:42 < morimoto`> geertu: He has many color of hat, Renesas, Jinso, OpenSource :) +09:42 < geertu> morimoto`: Igel? ;-) +09:42 < morimoto`> He "was", not now :) +09:42 < geertu> Yes, you guys will be missed. But as we have Internet, skype could be an option. +09:43 < geertu> morimoto: Tell LinkedIn ;-) +09:43 < geertu> OK, time to really start the Core Meeting +09:43 < geertu> Welcome to today's Core Group Chat +09:43 < geertu> Agenda: +09:43 < geertu> 1. Status updates +09:43 < geertu> Topic 2. Core additional tasks for Q1/2018 +09:43 < Marex> geertu: or Ekiga rather than proprietary MS solutions ? +09:43 < geertu> 3. Meeting before FOSDEM (done) +09:43 < geertu> Marex: It's been a while I used Ekiga... +09:44 < geertu> 4. Discussion Topics +09:44 < geertu> Topic 1. Status updates +09:44 < geertu> A) What have we done since last time +09:44 < geertu> Marek worked on initial support for r8a77970/eagle and r8a77995/draak in +09:44 < geertu> U-Boot, wrote https://elinux.org/R-Car/Boards/U-Boot-Gen3, and patched +09:44 < geertu> meta-renesas for mainline U-Boot at https://github.com/marex/meta-renesas. +09:44 < geertu> Shimoda-san submitted usb3.0 phy and peripheral patches, and investigated +09:44 < geertu> M3-N IPMMU issues, which need workarounds. +09:44 < geertu> Simon resolved Gen3 no-reg warnings, and worked on Z/Z2/CpuFreq for Gen3. +09:44 < geertu> Geert worked on sh-sci Kconfig, and fixed locking and memory bugs in DT +09:44 < geertu> overlays and PCIe. +09:45 < geertu> B) What we plan to do till next time +09:45 < geertu> Marek will work on RPC SPI support. +09:45 < geertu> Shimoda-san will continue evaluating M3-N IPMMU HW. +09:45 < geertu> Simon will continue no-reg work for Gen2 and RZ, Z/Z2/CpuFreq on Gen3, and +09:45 < geertu> repost IPMMU bindings patches. +09:45 < geertu> Geert will send clk-renesas and sh-pfc pull requests, continue bisecting +09:45 < geertu> "unhandled level 0 translation fault", and preparing additional tasks. +09:45 < geertu> C) Problems we have currently +09:45 < geertu> Marek remarks that the SD/MMC maintainer in U-Boot is slow. +09:45 < geertu> Simon has issues with Z/Z2 clock divider handling in conjunction with +09:45 < geertu> CPUFreq. +09:45 < geertu> Geert suffered from stuff that got broken (DT overlays, unhandled level 0 +09:45 < geertu> translation fault, DRM hang, ...) +09:45 < geertu> --EOS-- +09:46 < geertu> Anything I missed? +09:46 < geertu> Topic 2. Core additional tasks for Q1/2018 +09:47 < geertu> I've received the following candidate tasks: +09:47 < geertu> - JTAG Support for Gen3 platforms using OpenOCD (Kieran) +09:47 < geertu> - Virtualization (TBD later) +09:48 < geertu> I guess we should also start upstreaming initial support for Salvator-X with R-Car M3-N. +09:48 < geertu> Are there any other proposals or requests, especially from the Renesas side? +09:49 < Marex> PCIe support in U-Boot for example ? :-) +09:51 < shimoda> geertu: I'd like to improve IPMMU driver somehow but main person will be dammsan? :) +09:51 < dammsan> pinchartl: I dont plan on going to FOSDEM but it may change +09:52 < wsa_> maybe side question: morimoto-san said "M3N Salvator-XS board export paper work". Who will is planned to get one? +09:52 < wsa_> -will +09:53 < geertu> wsa_: I think I am, as Morimoto-san already sent the "official email" to me. +09:53 < pinchartl> dammsan: OK +09:53 < geertu> Dunno who else is planned +09:53 < uli___> i am, apparently +09:54 < horms> likewise +09:54 < morimoto`> wsa_: for all member +09:54 < morimoto`> but, 1st ship is for 4 member +09:54 < wsa_> morimoto`: I see +09:55 < wsa_> thanks, always nice to know who has what :) +09:55 < uli___> morimoto`: when is shipping expected, btw? i'd prefer to not get anything before january for logistical reasons (vacation) +09:55 < morimoto`> wsa_: you are 2nd ship member ;) +09:55 < morimoto`> uli___: it will be next year +09:55 < morimoto`> for some reason +09:56 < uli___> ok, thanks +09:56 < wsa_> no problem. no urgency on my side +09:56 < morimoto`> uli___: wsa_: thanks +09:57 < geertu> There's already a remote one in Magnus' farm +09:58 < dammsan> geertu: the soc is same but board is X not XS (i think) +09:58 < geertu> dammsan: Yes, It's X +09:58 < geertu> AFAIK +09:59 < geertu> No more task suggestions? +09:59 < geertu> Anything else to discuss? +09:59 < Marex> geertu: testing mainline u-boot ? +10:00 < Marex> geertu: who wants to start testing ? I have binaries available for M3/H3 ULCB and Salvator-X (only H3 ES2.0+ supported) +10:00 < Marex> or well, even better, you can build the whole stuff yourself ... +10:00 < dammsan> Marex: i want automated updating via script somehow +10:00 < geertu> And M3-W Salvator-X? +10:01 < Marex> geertu: what's 7796 salvator-x , right ? I didn't test, but should work, wanna try ? :-) +10:02 < Marex> geertu: wait, I tried 7796 salvator-x and 7795 salvator-xs ... +10:02 < geertu> Marex: Good, that's what I have ;-) +10:02 < Marex> dammsan: of uboot ? that can be done already (read: I use that to make my life easier), although it's undocumented, just like unlocking the RPC, for obvious reasons +10:03 < Marex> dammsan: I can documented that internally somehow though +10:04 < dammsan> neg: tack - behover tva separata men kan separaera sjalv sa inga problem +10:05 < geertu> Looks like we're finished. +10:05 < geertu> Thanks for joining, and have a nice continued day! +10:06 < dammsan> Marex: Documenting stuff is always good. Knowledge how to detect which version of various boot loader stack that are installed would be nice to document too +10:06 < horms> Thanks Geert! +10:06 < pinchartl> I'll give everybody a few minutes for a restroom break and we can then start with multimedia +10:06 < Marex> dammsan: we have "version" command and the version is printed upon boot too :-) +10:07 < Marex> dammsan: where are you aiming with this, some sort of update automation ? +10:07 < geertu> kbingham: Will you join the activities on Friday before FOSDEM? (cfr. "Meeting before FOSDEM" at 8:33 your time) +10:07 < Marex> dammsan: might be better to have some sort of "update_uboot" script in U-Boot, which you run to reinstall everything +10:08 < Marex> dammsan: hmmm, maybe you could deliver the update as a fitImage, containing all the components ... hmmmmm +10:08 < dammsan> Marex: I am thinking of more components than just U-bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbboot, butnks!! +10:08 < Marex> dammsan: feels like we're reinventing the UEFI update capsule +10:08 < dammsan> maybe so +10:08 < dammsan> automation would be nice to have +10:08 < Marex> dammsan: you mean updating IPL and U-Boot or even more stuff ? +10:09 < dammsan> yeah +10:09 < wsa_> gotta run +10:09 < wsa_> cya! +10:09 -!- wsa_ [~wsa@p54B3351E.dip0.t-ipconnect.de] has quit [Quit: ...] +10:10 < pinchartl> alright +10:10 < kbingham[m]> geertu: I'm planning to bring Hugo and Keri to Brussels for a trip and Hugo's first plane ride. So I'll be around but my schedule might be variable. But I'll treat most of the week as a working week +10:10 < Marex> dammsan: yes as in IPL and U-Boot or yes as in IPL/U-Boot/and-more-stuff ? diff --git a/wiki/Chat_log/20171214-io-chatlog b/wiki/Chat_log/20171214-io-chatlog new file mode 100644 index 0000000..fe881c1 --- /dev/null +++ b/wiki/Chat_log/20171214-io-chatlog @@ -0,0 +1,109 @@ +09:01 < wsa_> welcome to the io meeting +09:01 -!- morimoto` [~user@relprex1.renesas.com] has joined #periperi +09:01 -!- morimoto [~user@relprex1.renesas.com] has quit Read error: Connection reset by peer +09:01 < wsa_> here is my 'compiled' summary: +09:01 < wsa_> (of status updates) +09:01 < wsa_> A) +09:01 < wsa_> Geert worked on named i2c GPIO bindings, Ethernet PHY reset v4, SPI eeprom DT +09:01 < wsa_> support and MSIOF chip select support. Wolfram worked on R-Car I2C bus +09:01 < wsa_> recovery, I2C core switcher patches, add tasks for Q1/2018, and largely +09:01 < wsa_> reviewed a huge SDHI patch series. Shimoda-san worked on various USB issues and +09:01 < wsa_> sent them upstream, investigated RuntimePM issues and also forwarded questions +09:01 < wsa_> about SPI slave and IIC. Simon posted an RFC for eMMC HS400 support. +09:01 < wsa_> B) +09:01 < wsa_> Geert will work on more MSIOF issues. Wolfram will work on R-Car I2C bus +09:01 < wsa_> recovery V2, test DTS switcher patches remotely, add. tasks for Q1, +09:01 < wsa_> per-SoC-freq-calculation for IIC and continue to review the huge SDHI patch +09:01 < wsa_> series. Shimoda-san continues to work on the RuntimePM and USB role swap +09:01 < wsa_> issues, as well as resubmitting phy-rcar-gen3-usb2 and learning about KVM & +09:01 < wsa_> USB. Simon continues to work on the HS400 issues and wants to enable SDR on +09:01 < wsa_> Porter and H3ULCB. Ulrich wants to pick up outstanding patch series (SCIF +09:01 < wsa_> receive margin, D3 I2C patches) +09:01 < wsa_> C) +09:01 < wsa_> Wolfram struggled a little with the tax office again. Simon needs to mine +09:01 < wsa_> the BSP for more ideas about drive strength and HS400 issues. +09:02 < wsa_> anything I missed? or questions or other kinds of additions? +09:03 < wsa_> not the case +09:04 < wsa_> shimoda: the customer team seems happy with the IIC patches I did so far? +09:05 < wsa_> about the add. tasks: +09:05 < horms> wsa_: seems good, sorry for missing the 1 hour cutoff +09:05 < shimoda> wsa_: i hope so, but the team now continue to work for updating the doc with hw guys +09:06 < wsa_> I asked Niklas who expressed interest in bigger MTU handling for EtherAVB (if multimedia doesn't need him 100%) +09:06 < shimoda> so, we have to wait until thier work +09:06 < wsa_> shimoda: I understand. So, we could say: so far, so good :) +09:07 < wsa_> horms: no problem, if there is 1 exception I can handle it ;) +09:07 < shimoda> wsa_: yes :) +09:07 < wsa_> I asked Ulrich who expressed interest in hrtimer support for HSCIF +09:08 < wsa_> I asked Simon to continue on HS400. Did you get that mail, Simon? +09:08 < wsa_> I planned to work on NAK & REP_START issues for IIC as one task +09:08 < horms> wsa_: sorry, no i missed it +09:08 < wsa_> and on fixing SDHI PM issues as another task +09:08 < horms> I see it now +09:09 < wsa_> horms: ah, good, just wanted to know if it gets through +09:09 < horms> wsa_: I do have time. I do agree upstreaming is the easy part. The hard part is making the feature work (reliably). +09:09 < wsa_> that's all I have done now so far regarding add. tasks +09:09 < wsa_> Any more requests from Renesas side? +09:10 < wsa_> Someone with some free time and desire to work on an IO task? :) +09:12 < geertu> wsa_: Do you see anything missing in core that you need for I/O? +09:12 < wsa_> horms: great that you have time. so we need to phrase the add. task accordingly (maybe not so much about upstreaming?) +09:13 < horms> The way I see things is that we have many issues relating to handling tuning. +09:13 < wsa_> geertu: nope +09:14 < horms> And its hard to work out which BSP changes - issued addresst there - are a) real, b) upsreamable and c) related to hs400 +09:14 < horms> BTW, the BSP works fine :) +09:14 < wsa_> ok +09:14 < wsa_> so, it could be worse ;) +09:16 < wsa_> BTW, isn't there a request for the GETHER device? A new Gigabit ethernet controller only found on the V3H? +09:16 < horms> Yes, there is hope +09:16 < horms> Oh, really??? +09:17 < horms> Neither an SH-ETH or EtherAVB variant? +09:17 < geertu> Haven't looked at the spec, but probably it's SH-ETH? The one on R-Mobile A1 also does gigabit +09:18 < wsa_> chapter 51 in the 0.80 docs +09:18 < wsa_> geertu: ad, didn't know that +09:18 < geertu> I guess Cogent will work on V3H? +09:18 < wsa_> ah +09:18 < geertu> I always found it strange the one on R-Car Gen2 is limited to 100M +09:18 < geertu> given Armadillo has 1G +09:18 < horms> Is it? +09:19 < geertu> 7757, 7734, and 7763 also have 1G +09:20 < wsa_> well, from a glimpse the regs look a bit different +09:20 < horms> The stratergy for ethernet is somewhat of a puzzle for me. My only conclusion is its not that important. But then there are whole new IP blocks coming out from time to time... +09:20 < Marex> horms: maybe it's a matter of size of the block in the silicon ? +09:20 < Marex> horms: insert block which fits ... you have these three options +09:20 < horms> Marex: likely +09:21 < wsa_> but well, yeah, it seems there is no request anyhow +09:22 < wsa_> so, no more topics from me +09:22 < shimoda> wsa_: sorry for the delayed, from my side, i don't have any request from my side about add. tasks +09:22 < wsa_> thanks, shimoda-san +09:23 < wsa_> i will forward the task descriptions then to Magnus, once I know if Niklas is available in Q1 +09:24 < wsa_> what about the next meeting? +09:25 < geertu> in the middle of the Xmas holidays? +09:25 < wsa_> not a good option, me thinks +09:25 < geertu> Postpone by 1 week? +09:25 < geertu> 2 weeks? +09:26 < wsa_> is 4.1.18 realistic? or are ppl still on holiday then? +09:26 * geertu was cobfused for a split second, thinking about a kernel version +09:26 < wsa_> :D +09:26 < geertu> s/cobfused/confused/ +09:27 < neg> It would work for me +09:27 < geertu> 2018-01-04 is fine for me +09:27 < pinchartl> fine with me as well +09:27 < horms> " +09:27 < uli___> same here +09:27 < wsa_> I can make 4.1.2018 but very likely not 11.1.2018 +09:27 < shimoda> in renesas, we will be off at 4th Jan +09:27 < geertu> I just wanted to ask: "any Japanese holidays?" ;-) +09:28 < wsa_> hmmmm +09:28 < horms> 4th is probably not good in Japan +09:28 < morimoto`> Renesas side guys will have holidays untile 2018-1-8 +09:29 < horms> morimoto`: in general Japan closes for the first week of the year, right? +09:29 < shimoda> geertu: i'm not sure but some people will start at 3rd Jan in Japan companies +09:29 < wsa_> 9.1.2018 (Tue) would work for me +09:29 < shimoda> s/3rd/4th/ +09:30 < geertu> Fine for me, too +09:31 < morimoto`> horms: shimoda answered your question :) +09:31 < horms> :) +09:32 < wsa_> ok, let's sum it up for now: I am available on 9.1. If it is going to be 11.1. we will likely do the IO meeting part by mail. +09:32 < wsa_> shouldn't be a big deal since there won't be too much work over Xmas/New Year anyhow +09:32 < geertu> Indeed. Sounds fine to me. +09:33 < horms> Either is fine by me +09:33 < wsa_> and with that I'd hand over to Geert for the core meeting diff --git a/wiki/Chat_log/20171214-mm-chatlog b/wiki/Chat_log/20171214-mm-chatlog new file mode 100644 index 0000000..32ba354 --- /dev/null +++ b/wiki/Chat_log/20171214-mm-chatlog @@ -0,0 +1,328 @@ +Multimedia-chat-meeting-2017-12-14 + +10:10 < pinchartl> looks like we have a full hosue today +10:10 < pinchartl> hello everybody +10:10 < pinchartl> let's get started with status updates +10:10 * kbingham[m] should move to a real keyboard +10:11 < pinchartl> I'll copy & paste from e-mail to make it faster +10:11 < pinchartl> first, uli___ +10:12 < pinchartl> Since last meeting: +10:12 < pinchartl> - Forward-ported Rogue GPU driver on M3-W to mainline. +10:12 < pinchartl> OpenCL and proprietary API tests pass 100% on the mainline M3-W GPU driver. +10:12 < pinchartl> OpenGL tests (both shipped with the binary blobs and home-brewed tests) fail early, though. eglInitialize() not very helpfully returns EGL_NOT_INITIALIZED. +10:12 < pinchartl> This is suspected to be a user space problem, will try to find a user space/binary blob combination that works. +10:12 < pinchartl> For the next two weeks: +10:12 < pinchartl> - Mix and match the various versions of GPU user space libraries in +10:12 < pinchartl> an effort to get OpenGL to work +10:12 < pinchartl> Issues and Blockers: None +10:12 < pinchartl> uli___: anything to add? +10:12 < uli___> that's it, really +10:12 < pinchartl> thank you +10:12 < pinchartl> next, Kieran +10:12 < pinchartl> Since last meeting: +10:12 < pinchartl> - Rebased GMSL/base on top of renesas-drivers-v4.15-rc1 with Niklas' help +10:12 < pinchartl> - Eagle-V3M GMSL support +10:12 < pinchartl> - Implemented a VIN loopback test +10:12 < pinchartl> Frames are compared, and invalid frames stored for post-analysis +10:12 < pinchartl> - HDMI Interlaced support query +10:12 < pinchartl> For the next two weeks: +10:12 < pinchartl> - Christmas Holidays +10:12 < pinchartl> Issues and Blockers: None +10:12 < pinchartl> kbingham[m]: anything to add ? +10:13 < pinchartl> (or to fix, as I have reformatted the text from e-mail status updates for the report) +10:13 < pinchartl> or kbingham maybe ? +10:13 < neg> kbingham[m]: good work with the looptests! +10:13 < kbingham> pinchartl: Not since I put those in an email at 1am no :) +10:13 < pinchartl> :-) +10:14 < pinchartl> next, Jacopo +10:14 < pinchartl> Since last meeting: +10:14 < pinchartl> - Rebased and retested existing GMSL code +10:14 < pinchartl> - Tested and compared latest Cogent's code drop +10:14 < pinchartl> About aone month ago we have received a new code drop from Cogent (https:// +10:14 < pinchartl> github.com/CogentEmbedded/meta-rcar/blob/v2.23.0/meta-rcar-gen3-adas/recipes- +10:14 < pinchartl> kernel/linux/linux-renesas/0030-Gen3-LVDS-cameras.patch). It differs from our current code in OV10635 settings and MAX9286/MAX9271 settings. Using Cogent's settings has no impact on frame synchronization. +10:14 < pinchartl> - Added debug output to v4l2-async +10:14 < pinchartl> - Started building Yocto for GMSL setup to test Cogent's code. +10:14 < pinchartl> Renesas BSP layer built, still have to build Cogent's layer. +10:14 < pinchartl> For the next two weeks: +10:14 < pinchartl> - Collect CEU feedbacks and submit v2 +10:14 < pinchartl> - OV7670 device tree parsing +10:14 < pinchartl> - Update gmsl/base with kieran's new tag and test image capture on v4.15-rc1 +10:14 < pinchartl> - Yocto build of Cogent's BSP +10:14 < pinchartl> Issues and Blockers: +10:14 < pinchartl> - With v4.15-rc1 GMSL devices are registered but no frame could be captured +10:14 < pinchartl> - GMSL frame sync still no working and becoming a blocker +10:14 < pinchartl> jmondi: anything to add/fix ? +10:14 < kbingham> neg: Yes, it's certainly an interesting way forwards once we get through a few minor format issues :) +10:15 < jmondi> just wanted to know from neg if it expected to reecive an -EPIPE when capturing on v4.15-rc1 +10:15 < neg> jmondi: then the pipeline verification fails +10:15 < jmondi> (ie. because of missing mux support) +10:16 < neg> jmondi: we can take this after the meeting and try to bang it out? I'm also porting the new mux setup to the GMSL branch so will probobly run in to the same issues you have +10:16 < jmondi> and I should resend my last series to have gmsl device node created to better exaplain why we need that on v4.15-rc1 +10:17 < jmondi> neg: sure +10:17 < pinchartl> in that case +10:17 < pinchartl> next, Niklas +10:17 < neg> jmondi: The old mux implementation should be there in the GMSL branch but I have not tested it ontop of v4.15-rc1, only the new one and it wroks for adv748x at least +10:17 < pinchartl> Since last meeting: +10:17 < pinchartl> - Added VIN support to V3M +10:17 < pinchartl> - [PATCH] rcar-vin: enable support for r8a77970 +10:17 < pinchartl> - [PATCH 0/2] rcar-csi2: enable support for r8a77970 +10:17 < pinchartl> - [PATCH 0/3] arm64: dts: renesas: r8a77970: connect VIN to CSI40 +10:17 < pinchartl> - [PATCH v12 0/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 +10:17 < pinchartl> - [PATCH v8 00/28] rcar-vin: Add Gen3 with media controller +10:17 < pinchartl> - [PATCH v9 00/28] rcar-vin: Add Gen3 with media controller +10:17 < pinchartl> - Multiplexed pads based on routing and framedesc patches from Sakari and Laurent done for rcar-vin, rcar-csi2 and adv748x +10:17 < pinchartl> - User-space patches for v4l2-ctl to support routing operations needed to control multiplexed pads from user-space +10:17 < pinchartl> - Begun adopting 8-camera patches for new multiplexed pads +10:17 < pinchartl> - Confirmed CEC functionality on Koelsch (for Lager test-case). Found problems with CEC and adv7612. Hans have hack patch to make it works but it's not ready to be upstream but works to loopback test CEC on Gen2. +10:17 < pinchartl> - Started to address Laurent's review comments to rcar-vin Gen3 +10:17 < pinchartl> For the next two weeks: +10:17 < pinchartl> - Post multiplexed streams kernel and user-space patches +10:17 < pinchartl> - If time try to help Hans by adding and testing CEC on Lager, hopefully with the help from Laurent who kindly offered to test on his Lager. +10:17 < pinchartl> Issues and Blockers: None +10:17 < pinchartl> neg: anything to add/fix ? +10:18 < neg> pinchartl: only that CEC test on Lager will be postponed to next year :-) +10:18 < pinchartl> indeed :-) +10:18 < pinchartl> sorry about that, I thought I would have time today but unfortunately I won't +10:18 < neg> no problems +10:19 < pinchartl> well, it could still be done before the next meeting +10:19 < pinchartl> next, Morimoto-san +10:20 < pinchartl> - ALSA SoC cleanup prepare patches have been accepted +10:20 < pinchartl> Main cleanup patches are very big, still trying to find out when the best time to post them would be. +10:20 < pinchartl> - Fixes for sound issues reported by the BSP team +10:20 < pinchartl> - M3N Salvator-XS board export paper work +10:20 < pinchartl> Until next meeting: +10:20 < pinchartl> - Post main ALSA SoC cleanup patches +10:20 < pinchartl> - M3N Salvator-XS board export paper work +10:20 < pinchartl> Issues and Blockers: None +10:20 < geertu> dammsan's remote lager with manual fiddling on his side? +10:20 < pinchartl> anything to add/fix ? +10:20 < pinchartl> morimoto`: anything to add/fix ? +10:20 < morimoto`> nothing,thanks +10:21 < pinchartl> you're welcome +10:21 < pinchartl> next, me +10:21 < pinchartl> Since last meeting: +10:21 < pinchartl> - More patch review +10:21 < pinchartl> - Submitted DISCOM support to calculate CRC in the VSP +10:21 < pinchartl> - Nearly finished display color keying support for Gen3 +10:21 < pinchartl> - Submitted new version of the DU plane boundaries fixes +10:21 < pinchartl> - Tested DU dmabuf import fixes locally +10:21 < pinchartl> Until next meeting: +10:21 < pinchartl> - Submit display color keying support for Gen3 +10:21 < pinchartl> - More patch review +10:21 < pinchartl> - New version of the V4L2 unbind/userspace race condition handling +10:21 < pinchartl> - Start reworking video device registration code +10:21 < pinchartl> Issues and blockers: None +10:21 < pinchartl> and I agree with myself +10:21 < pinchartl> dammsan: anything to report on your side ? +10:22 < pinchartl> geertu: have we agreed on whether the next meeting will be on the 9th or the 11th ? +10:24 < pinchartl> while waiting for answers, let's move to the questions from Morimoto-san +10:24 < morimoto`> pinchartl: dammsan said "no" +10:25 < pinchartl> - Color Key support for DU/VSP +10:25 < pinchartl> This is due for tomorrow, I will post patches today +10:25 < morimoto`> thanks! +10:25 < pinchartl> - Calculate DU DPLLCR to have smaller jitter +10:25 < pinchartl> I've replied to your e-mail, I assume you will send a v3 +10:26 < morimoto`> Yes, thanks. +10:26 < pinchartl> - Interlace height calculation mismatch between HDMI <-> CVBS +10:26 < pinchartl> kbingham: ? +10:26 < pinchartl> - Remove "VNMC_REG = 0" writing from VIN driver +10:26 < pinchartl> neg: ? +10:27 < kbingham> - Ah - yes - I need to look at the interlace issue and send a patch I believe. +10:27 < neg> pinchartl: "VNMC_REG = 0" is addressed in the later vin series +10:27 < pinchartl> neg: thank you +10:27 < pinchartl> kbingham: when do you plan to do so ? +10:27 < morimoto`> neg: upsteamed already, do you mean ? +10:28 < kbingham> pinchartl: I find myself with very little spare time between now and Christmas ... If this is a high priority task - then I'll make time - but otherwise this will be a new year task for me. +10:28 < neg> morimoto`: no, it's part of VIN Gen3 patches which is not yet upstream +10:29 < kbingham> It's probably not a long task ... +10:29 < morimoto`> kbingham: no problem. it is not a high priority. I just asked +10:29 < pinchartl> kbingham: can we say for the next meeting then ? (9th or 11th, pending geertu's answer) +10:29 < kbingham> morimoto`: Ok thanks - +10:29 < neg> morimoto`: but the fault is also introduced by erlier versions of the same patch-set, so the fault have never been present upstream +10:29 < kbingham> pinchartl: Yes, I would hope January is achieveable :) +10:29 < pinchartl> thank you +10:30 < morimoto`> neg: OK, sounds nice. Thanks +10:30 < pinchartl> - ADV7511W slave address conflict issue on D3 +10:30 < pinchartl> I haven't had time to work on this yet, I will address it as part of my base contract, planned for the first two weeks of January as well +10:31 < morimoto`> pinchartl: thanks. no stress +10:32 < pinchartl> - drmModeAtomicCommit() API test makes VGA side bad +10:32 < pinchartl> I have confirmed the issue but not investigated it yet +10:32 < pinchartl> I'm not sure yet how big the problem is and whether an additional task would be needed +10:32 < pinchartl> how urgent is it ? +10:32 < morimoto`> Hmm.. not sure. +10:33 < pinchartl> it's pretty bad, so I'd like to prioritize it +10:33 < morimoto`> it can be next add. task ? +10:33 < pinchartl> yes, I think it's a good idea +10:33 < morimoto`> OK, thanks +10:33 < pinchartl> I think those were all your questions +10:34 < pinchartl> next topic, FOSDEM +10:35 < pinchartl> easy question first, who wants to join the multimedia dinner on Thursday evening ? +10:35 < jmondi> o/ +10:35 < neg> me +10:35 < morimoto`> pinchartl: I confirmed about drmModeAtomicCommit() priority. It is HI priority +10:36 < pinchartl> morimoto`: ok, thank you +10:36 < morimoto`> pinchartl: +1 topic is DU separation. +10:36 < pinchartl> kbingham: for virtualization ? +10:36 < pinchartl> I meant +10:36 < morimoto`> pinchartl: this is low priority +10:36 < pinchartl> morimoto`: for virtualization ? +10:36 < morimoto`> Yes +10:36 < pinchartl> ok +10:37 < pinchartl> let's discuss it as part of the additional tasks +10:37 < morimoto`> OK, thanks. +10:37 < pinchartl> uli___: no plan to attend the multimedia meeting on Thursday before the FOSDEM ? +10:37 < uli___> no definite plan for now +10:38 < pinchartl> ok +10:39 < pinchartl> ok +10:39 < pinchartl> then +10:39 < pinchartl> it seems our plan to organize a code camp during the week after the FOSDEM in a remote location that would force us to work needs to be cancelled +10:39 < pinchartl> be clearly can't do so without at least one Japanese attendee +10:40 < pinchartl> I would, however, still like to organize a GMSL code camp +10:40 < pinchartl> we've discussed this privately before, the idea would be to work together in Brussels before the FOSDEM from Monday to Thursday +10:40 < pinchartl> Jacopo, Kieran and Niklas have expressed their interest +10:41 < pinchartl> dammsan: morimoto`: I assume you won't be able to join +10:41 < pinchartl> but would this be feasible from a budget point of view ? +10:41 < pinchartl> assuming we can extend the apartment booking we have for Thursday-Monday, this will be cheap +10:42 < pinchartl> as the four of us can stay in the same apartment and work from there +10:43 < pinchartl> kbingham: how much would be the extra cost ? +10:43 < pinchartl> for 4 additional nights +10:43 < kbingham> I'll check the booking +10:44 < morimoto`> pinchartl: unfortunately, we can't join +10:45 < pinchartl> morimoto`: I wonder when our next face-to-face meeting should be. I will not attend ELC this year +10:45 < kbingham> I believe the apartment is €180 per night. +10:45 < pinchartl> so that's 45€ / person +10:46 < morimoto`> pinchartl: Good question, and difficult to say +10:46 < morimoto`> It seems we can't goto ELC too, at this point. but not sure +10:47 < pinchartl> do you have more information about those budget cut ? does it affect other things than travel ? how long is it expected to last ? +10:47 < jmondi> morimoto`: what's happening? are they trapping in you in Japan this year? +10:48 < morimoto`> In Renesas side, our group were changed. Then, budget was changed too. +10:48 < morimoto`> I don't know detail, but, it seems some kind of confusable things happen +10:49 < morimoto`> I can say this is paper work issue +10:49 < pinchartl> so there's no need for all of us to start looking for a new job today ? :-) +10:49 < morimoto`> pinchartl: no problem: ) +10:49 < pinchartl> :-) +10:50 < morimoto`> EuroPeri member are very important for us +10:50 < pinchartl> JapanesePeri is very important for us too :-) +10:50 < neg> Ohh and I already sent out my resume to McDonalds ;-) +10:50 < kbingham> neg: You're not qualified to work at McDonalds. .. you don't have the required skill set :) +10:51 < neg> kbingham: I know, I was hoping for som on-site traning on burger flipping +10:51 < jmondi> morimoto`: new fight with paperwork guy ahead? +10:51 < morimoto`> But because of this budget paper work, Renesas member (= morimoto, shimoda) will have issue next year +10:51 < pinchartl> anyway, I think we can move forward with our plan to work on GMSL from Monday to Thursday +10:51 < pinchartl> morimoto`: not a big issue I hope +10:52 < morimoto`> jmondi: not myside, but budget paper work guys +10:53 < pinchartl> jmondi, kbingham, neg: please plan to start working on Monday morning when you make your travel plans for the FOSDEM +10:53 < pinchartl> I will personally arrive on Sunday evening +10:53 < jmondi> morimoto`: budget paperwork guy is some kind of eveolution of regulare paperwork guy, sort of next level enemy? +10:53 < jmondi> we should get there on Sunday then +10:53 < neg> pinchartl: I also plan to arrive on Sunday +10:54 < jmondi> 28th then! +10:55 < morimoto`> jmondi: they have very hard stone head... +10:55 < pinchartl> next topic, additional tasks for 2018 Q1 +10:56 < pinchartl> are there tasks you would like to work on in particular ? +10:56 < pinchartl> I have a list, let me paste it +10:57 < pinchartl> * GMSL +10:57 < pinchartl> - Camera instantiation through DT overlay +10:57 < pinchartl> - Camera auto-detection from list of known types +10:57 < pinchartl> - RDACM21 +10:57 < pinchartl> - GMSL capture and display test using KMSxx +10:57 < pinchartl> - More GMSL work... +10:57 < pinchartl> (there's more) +10:57 < shimoda> sorry, i'll go home now. see you next time! +10:58 < pinchartl> * Testing +10:58 < pinchartl> - Run igt on the DU +10:58 < pinchartl> - Integrate DISCOM in DU test suite +10:58 < pinchartl> - JTAG Support for Gen3 platforms (more of a Core task) +10:58 < pinchartl> - Python helpers for media-controller +10:58 < pinchartl> - More work on VIN loopback +10:58 < pinchartl> * New hardware +10:58 < pinchartl> - Display Output Checker (DOC) +10:58 < pinchartl> - Upstream DISCOM support +10:58 < pinchartl> - DAB/FM +10:58 < pinchartl> - Video codecs +10:58 < pinchartl> * Bug fixes +10:58 < pinchartl> - Dynamic BRS/BRU allocation in display pipelines +10:58 < pinchartl> - drmModeAtomicCommit() API test makes VGA side bad +10:59 < pinchartl> * Virtualization +10:59 < pinchartl> - Display virtualization (DU0 + DU1 on host, DU2 + DU3 on guest) +10:59 < pinchartl> that's it +11:00 < pinchartl> JTAG support for Gen3 is a core task +11:00 < pinchartl> any other proposal ? +11:00 < jmondi> pinchartl: I have received a D3 I assume for VIN parallel input support +11:00 < uli___> what exactly does "jtag support" mean? +11:01 < pinchartl> kbingham: that question is for you +11:01 < kbingham> uli___: The ability to use OpenOCD to connect and debug the kernel using GDB on Gen3 platforms +11:01 < pinchartl> jmondi: indeed, let me add that +11:01 < jmondi> and I feel like we should move gmsl in the open asap (as soon as rcar-vin and rcar-csi2 are mainlined) +11:01 < jmondi> we are actually piling too many pateches around +11:02 < pinchartl> there's also near-lossless compression upstreaming, I'll add that too +11:02 < jmondi> also, ov10635 driver should be separated from rdacm20, if we want to ease rdacm21 support... +11:03 < pinchartl> I'm not sure how to handle the rdacm21 yet +11:03 < pinchartl> but I agree about moving development to the open +11:03 < morimoto`> sorry, I need to go too. +11:03 < morimoto`> bye +11:03 -!- morimoto` [~user@relprex1.renesas.com] has left #periperi ["ERC Version 5.3 (IRC client for Emacs)"] +11:03 < pinchartl> morimoto`: no worries. have a nice evening +11:03 < pinchartl> dammsan: are you still there ? +11:04 < pinchartl> uli___: I think JTAG support means OpenOCD + gdb debugging for Gen3 +11:04 < pinchartl> jmondi: we need to have upstreamable code then :-) +11:04 < jmondi> pinchartl: and code that works, also +11:05 < pinchartl> that an upstreaming requirement for me :-) +11:05 < jmondi> I feel like after Feb. code camp that should be our first effore for gmsl.. everything is so fragile (see moving to v4.15-rc1, we still have not been able to achieve) +11:05 < kbingham> uli___: I would particularly like to be able to use it - I have already hooked up a a BusBlaster - and it can see the 'dap' on the coresight module - but can't get access to the CPU's yet. +11:05 < jmondi> s/effore/effort/ +11:05 < pinchartl> checking an older additional tasks list, there' also +11:05 < pinchartl> * DU interlaced modes support +11:05 < pinchartl> * VIN scaler +11:05 < pinchartl> * VIN TB/BT field support in continuous mode +11:05 < pinchartl> neg: or is that one complete already ? +11:05 < kbingham> uli___: If this is an area your familiar with - I would certainly be happy to hand the topic over to someone who knows more than me - I just want it to work :) +11:06 < uli___> i did that for kzm9g before... +11:06 < pinchartl> kbingham: what's the status of * ADV7482 CEC support ? +11:06 < neg> pinchartl: no VIN UDS scaler work not started, feels like the driver shuld be upstreamd first +11:06 < kbingham> pinchartl: Not yet done, and therefore also on that list :) +11:06 < pinchartl> neg: I meant TB/BT in continuous mode +11:07 < neg> pinchartl: VIN TB/BT in continuous mode would depend on the rework of the capture loop to not use single capture mode, which I hope to also be able to postpone to after Gen3 support is megred upstream +11:07 < pinchartl> neg: OK +11:08 < pinchartl> uli___: how about on your side, do e need more additional task for the GPU ? or is there something else you'd like to work on ? +11:09 < uli___> the jtag thing sounds good, actually +11:09 < pinchartl> I like it too, but it's a core task, so it has to be coordinated with Geert +11:09 < pinchartl> anything on the multimedia side ? :-) +11:09 < uli___> about the gpu, i'd like to finish the current task before i make up my mind about it +11:10 < pinchartl> when do you expect to finish it ? +11:10 < uli___> it's due on friday +11:11 < uli___> apart from that, dab/fm stuff sounds interesting, depending on the details +11:11 < kbingham> DAB/FM was just something I put on the list because I noticed there is some hardware somewhere in the R-Car to handle it. +11:11 < pinchartl> I don't know if it's a priority for Renesas, but we can certainly propose it +11:11 < kbingham> So I don't really know details beyond that. +11:14 < pinchartl> ok +11:15 < pinchartl> so I have a list of tasks that I will include in the report +11:15 < pinchartl> and we'll need to prioritize it, based on Renesas' feedback +11:16 < pinchartl> as neither Morimoto-san near Magnus seem to be here, I think we'll handle that through e-mail +11:16 < pinchartl> dammsan: still not available ? +11:16 < pinchartl> geertu: ping +11:18 < geertu> pinchartl: pong +11:19 < pinchartl> geertu: have we decided on whether the next meeting will be on the 9th or the 11th ? +11:20 < geertu> pinchartl: Not yet. wsa is unavailable on the 11th +11:20 < pinchartl> when do we decide ? :-) +11:21 < geertu> Does the 9th fit for all of you? +11:21 < pinchartl> works for me +11:22 < jmondi> that's fine! +11:22 < uli___> ok for me +11:22 < pinchartl> kbingham: neg: how about you ? +11:23 < kbingham> 9th works for me - probably better than the 11th for the same reasons as wsa :D +11:24 < neg> works for me +11:24 < pinchartl> kbingham: what's happening on the 11th ? +11:25 < pinchartl> OK, let's go for the 9th then +11:25 < kbingham> pinchartl: It's the day after the day :) +11:25 < kbingham> I think I recall both me and WSA share the same birthday +11:26 < geertu> kbingham: You expect a hangover on the 11th? +11:26 < pinchartl> but isn't the 9th the day before the day then ? +11:26 < kbingham> geertu: Nope - I try hard to avoid hangovers lately ... +11:26 < geertu> kbingham: Screaming Hugo + hangover = profit? +11:27 < kbingham> geertu: haha +11:28 < pinchartl> so I think this is all for the multimedia meeting today +11:28 < pinchartl> does anyone else have anything to add ? +11:28 < neg> I'm good, thanks all +11:29 < pinchartl> thank you all for attending diff --git a/wiki/Chat_log/20180109-core-chatlog b/wiki/Chat_log/20180109-core-chatlog new file mode 100644 index 0000000..1a9463f --- /dev/null +++ b/wiki/Chat_log/20180109-core-chatlog @@ -0,0 +1,76 @@ +Core-chat-meeting-2018-01-09 + +09:37 < geertu> Welcome to today's Core Group Chat Meeting +09:37 < geertu> Agenda: +09:37 < geertu> 1. Status updates +09:37 < geertu> 2. Core additional tasks for Q1/2018 +09:37 < geertu> 3. Discussion Topics +09:37 < geertu> Topic 1. Status updates +09:37 < geertu> A) What have we done since last time +09:37 < geertu> Marek worked on HS200 for U-Boot again, assumed to go in after the 2018.01 +09:37 < geertu> release. +09:37 < geertu> Shimoda-san continued evaluation of the M3-N IPMMU HW. +09:37 < geertu> Simon fixed and merged Gen3 no-reg warnings, and addressed review for the +09:37 < geertu> Z/Z2/CpuFreq patches for Gen3. +09:37 < geertu> Ulrich sent ZG clock support for M3-W. +09:37 < geertu> Geert worked on additional tasks, prepared for the meeting before FOSDEM, +09:37 < geertu> sent clk and pfc pull requests, investigated a severe arm64 bug, tried +09:37 < geertu> Marek's new U-boot binary, and started looking into QEMU+kvm virtualization +09:37 < geertu> on arm64. +09:38 < geertu> (if anything is missing, please scream) +09:38 < geertu> B) What we plan to do till next time +09:38 < geertu> Marek will work on upstreaming Gen2 U-Boot rework. +09:38 < geertu> Shimoda-san will continue evaluating M3-N IPMMU HW. +09:38 < geertu> Simon will check Z2 clock handling for little CPUs on resume. +09:38 < geertu> Geert will do more virtualization work, try to build Marek's new U-Boot, +09:38 < geertu> and revisit in-kernel BD9571MWV DDR backup mode. +09:39 < geertu> C) Problems we have currently +09:40 < geertu> Simon lacks physical access to Lager board to set s2ram of little CPUs. +09:40 < geertu> Geert has issues with R-Car Gen3 firmware booting Linux in EL1 instead of +09:40 < geertu> HYP mode, precluding kvm. +09:40 < pinchartl> (I'll be back in 15 minutes, nothing to report for core) +09:40 < geertu> (in the mean time, Marek sent me firmware that should enable HYP mode, thx) +09:42 < geertu> Regarding Lager, does it need special firmware to enable 8 CPU cores? The one in Magnus' farm boots the big cores only +09:43 < shimoda> geertu: about 8 cores booting, i will ask someone +09:43 < wsa_> I can bring my Lager to Brussels if that helps and is not too late +09:44 < geertu> horms: Your particular issue is _local_ access to Lager, as the osdr wiki says you have a Lager (in Kobe)? +09:45 < horms> geertu: ues, that is correct +09:45 < horms> for paperwork reasons I left it there +09:45 < horms> I am wondering if anyone attending the Brussels session might bring a board +09:46 < wsa_> heh +09:46 * wsa_ waves again +09:46 < geertu> horms: Is the issue doing remote wakeup? You may get sufficiently far with /sys/power/pm_test +09:47 < horms> That is one issue. The other is upgrading the fw. +09:47 < geertu> OK, fw is more complicated +09:48 < horms> I can probably arrange to upgrade the fw somehow, f.e. by having the board sent to HQ, but its not entirely risk-free +09:48 < geertu> Sure, I understand +09:49 < geertu> So Wolfram's offer may be the simplest solution (depending on how much time is needed) +09:49 < geertu> Topic 2. Core additional tasks for Q1/2018 +09:49 < geertu> To the best of my knowledge, the following tasks have been issued for 2018 Q1 phase 1: +09:49 < geertu> - U-Boot for R-Car Gen2 DM and DT conversion (Marek) +09:49 < geertu> - QEMU+KVM on ARM64 and GPIO Pass-Through Prototype (Geert) +09:50 < horms> geertu: wsa_: yes, I think so. I can probably do preliminary testing in an hour or so. And then we can assess the next move. +09:51 < geertu> More tasks for 2018 Q1 phase 2 to be decided later... +09:51 < geertu> horms: OK +09:51 < horms> In news just in: I will likely push BSP v3.6.0 on Friday afternoon +09:51 < geertu> Topic 3. Discussion Topics +09:51 < geertu> (and announcements? ;-) +09:52 < geertu> Looking forward to the new BSP! +09:54 < geertu> morimoto: shimoda: Anything from the Renesas side? Are you happy (besides for holidays being over ;-)? +09:56 < shimoda> geertu: nothing from my side :) +09:57 < pinchartl> (back) +09:58 < morimoto> geertu: nothing too +09:58 < geertu> Anyone/anything else? +09:59 < neg> Only if there is any preparations needed for meetings or other activities during FOSDEM +10:00 < geertu> Make sure to attend Jacopo's, Marek's, and my presentations ;-) +10:00 < geertu> Anyone else who's presenting at FOSDEM? +10:01 < wsa_> hmm, i don't the ULCB COM Express type connector 440pin will be of much help :( +10:01 < neg> Hum are not two of those at the same timeslot :-) +10:01 < geertu> neg: Yes they are :-( +10:01 < geertu> neg: Live-streaming it is, multiple VIN inputs? +10:02 < geertu> wsa_: Soldering wires to random components indeed sounds easier +10:02 < geertu> Unless Uli makes COM Express breakout boards? +10:02 < geertu> uli___: ^ +10:02 < uli___> i'm not familiar with that connector, but it sounds horrible so far... :) +10:02 < wsa_> ack +10:03 < geertu> So, thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20180109-io-chatlog b/wiki/Chat_log/20180109-io-chatlog new file mode 100644 index 0000000..933768d --- /dev/null +++ b/wiki/Chat_log/20180109-io-chatlog @@ -0,0 +1,111 @@ +09:00 < wsa_> And 09:00 CET it is... +09:00 < wsa_> Welcome people to the first IO meeting of 2018 +09:01 < wsa_> Hope you all had a good start into 2018 +09:02 < wsa_> I had for two hours, then I had a crash with my bike :/ +09:02 < neg> :-( +09:02 < Marex> wsa_: heh, I caught the congress flu on day 3 ;-) +09:02 < wsa_> One wrist still hurts, but in general, I was lucky +09:03 < wsa_> so, not too bad somehow ;) +09:03 < wsa_> So, here is the summary of your reports: +09:03 < horms> Only damage on this side was a hangover on the 1st +09:03 < horms> quite a substantial one too +09:03 * jmondi fell from his bike in front of a running bus 3 weeks ago, so I'm with you _wsa +09:04 < wsa_> (just before I crashed, there was a speed measurement device, and I was so happy because I had a new personal record ;)) +09:04 < wsa_> A) +09:04 < wsa_> Uli sent revised D3 CAN series, and a few leftover bindings patches. +09:04 < wsa_> Geert fixed MSIOF timeout with TX-only DMA. +09:04 < wsa_> Niklas sent V2 of some thermal patches. +09:04 < wsa_> Wolfram worked on add. tasks, sigrok improvements and QEMU preparations. He enabled +09:04 < wsa_> SATA on H3-ES2.0 and sent V2 of IP core switcher patches. And answered requests +09:04 < wsa_> and questions, both internally and externally. +09:04 < wsa_> Shimoda-san worked on USB PHY patches for Gen3 and discussed them. +09:04 < wsa_> B) +09:04 < wsa_> Wolfram wants to finish add. tasks and keep on working on QEMU. R-Car I2C recovery +09:04 < wsa_> gets a V2 and IIC freq calculation patches shall be merged. Also, SDHI topics +09:04 < wsa_> need some love, too. +09:04 < wsa_> Shimoda-san wants to continue on the USB PHY issue as well as investigate a USB3.0 role swap issue. +09:04 < wsa_> Also, he wants to review RZ/A1 patches and get into QEMU & USB as well. +09:04 < wsa_> Simon wants to continue on hacking HS400 and to fix the "no-link" problem on all boards +09:04 < wsa_> C) +09:04 < wsa_> Niklas still misses hardware to test reading thermal calibration from fused registers. +09:04 < wsa_> Simon needs to mine the BSP for more ideas about HS400. +09:05 < wsa_> jmondi: I hope you had no injuries? +09:06 < wsa_> Are there any questions about this? Or about the add. tasks? +09:07 < wsa_> I sent around add. tasks drafts yesterday, except for Simon which I will do today +09:07 < wsa_> sorry for the delay, simon +09:07 < horms> no problem +09:08 < wsa_> so, about one question I have: +09:08 < wsa_> I don't have ULCB schematics. Does someone have? I'd be interested if the IIC_DVFS bus is exposed there somewhere? +09:08 < horms> maybe, i can check +09:09 < wsa_> I don't want to apply the new freq calculation there without testing +09:09 < geertu> wsa_: yes, we have. They are public (check elinux wiki) +09:09 < wsa_> nice +09:10 < wsa_> well, i need to register with renesas :) +09:11 < geertu> wsa_: And after that, you can win e.g. blinkenlight beer coasters ;) +09:11 < wsa_> woot! +09:11 < wsa_> and i have another question: +09:12 < wsa_> we use GPIOs with SDHI for card_detect and write_protect instead of the internal mechanisms. +09:13 < wsa_> does somebody know why? At least on Gen3, the internal mechanisms seem to work fine +09:13 < wsa_> (maybe a tad slower, but still fine) +09:13 < wsa_> was there an old SoC which had problems with that? +09:14 < wsa_> I seem to recall something like that but can't really remember... +09:14 < Marex> wsa_: or maybe a pinmux flexibility issue ? +09:14 < morimoto> I think Magnus knows it +09:14 < morimoto> It was his idea +09:15 < wsa_> OK, I will check with him +09:15 < wsa_> thanks morimoto-san! +09:16 < horms> maybe good to document the answer +09:16 < wsa_> So, this was it already from my side... +09:16 < wsa_> horms: in deed +09:16 < wsa_> shimoda: morimoto: anything else from your side? Are you / Is Renesas happy? :) +09:17 < geertu> wsa_: Using a GPIO has the advantage that the SD card controller can be put to sleep, while CD IRQ/wakeup is handled by GPIO +09:17 < shimoda> i have a problem about hscif and investigate an issue. +09:17 < geertu> Again, software policy vs. hardware desc. +09:18 < wsa_> geertu: yes, that makes sense +09:18 < shimoda> If we send a large data with DMAC, sometimes warning happens from rcar-dmac. but, we cannot reproduce minicom yet. (We use a windows tool "teraterm") +09:19 < shimoda> ("we" mean I and jinso) +09:19 < shimoda> so, we continue to investigate how to reproduce the issue by using minicom somehow +09:19 < wsa_> I see +09:20 < wsa_> Good luck with that! +09:20 < wsa_> minicom --teramode /dev/ttyS0 +09:20 < wsa_> at what speed? +09:20 < wsa_> maybe we can try, too... +09:21 < shimoda> about 1Mbps +09:21 < geertu> "about"? +09:21 < shimoda> with transfer delay per a line +09:21 < geertu> 921600 bps? +09:21 < shimoda> 921600bps +09:21 < shimoda> yes +09:22 < shimoda> if we add 100ms delay per a line, the issue happens easily. the datafile is random and 1Mbytes. +09:23 < wsa_> but only with teraterm? +09:23 < shimoda> minicom also has delayed transfer per a line. +09:23 < shimoda> wsa_: yes +09:25 < wsa_> I'll play around and let you know if I see a warning... +09:25 < wsa_> So, maybe one closing word about the FOSDEM meeting +09:26 < wsa_> with so many people not being there (sadly missed!), I assume the IO meeting will not need much time +09:26 < horms> oh, who will be there? +09:26 < wsa_> But I see some kind of virtualization BOF coming... +09:27 < morimoto> horms: All JaPERIese doesn't go FOSDEM +09:27 < horms> ack +09:27 < wsa_> and ulrich is not coming AFAIK +09:27 < geertu> morimoto: And the SwePERIese? +09:27 < morimoto> geertu: MagPeri ? +09:28 < geertu> morimoto: DamPeri +09:28 < morimoto> He is counted as JaPERIese +09:28 < wsa_> NiklaPERI is coming, though +09:29 < wsa_> So, I think we should have a regular IRC meeting on 25th +09:30 < geertu> Soudns fine to me. +09:30 < wsa_> and in Brussels do some hands-on stuff +09:30 < wsa_> and with that, I think we are done for today +09:31 < pinchartl> wsa_: we'll be busy with the multimedia code camp on the 25th though +09:31 < pinchartl> is there a need for a regular IRC meeting given that there will be an I/O face to face meeting the next day ? +09:32 < wsa_> not the next day +09:32 < wsa_> 8 days later +09:33 < wsa_> i thought your code camp starts on 29th? +09:33 < pinchartl> of course, my bad +09:33 < pinchartl> sorry, I got the weeks mixed up +09:34 < wsa_> good +09:34 < geertu> pinchartl: Does AirBnB agree? +09:34 < wsa_> geertu: prepared to catch the mic? +09:36 < geertu> wsa_: Yes, I'm ready to go! +09:36 < geertu> wsa_: Thanks for leading I/O diff --git a/wiki/Chat_log/20180109-mm-chatlog b/wiki/Chat_log/20180109-mm-chatlog new file mode 100644 index 0000000..f688249 --- /dev/null +++ b/wiki/Chat_log/20180109-mm-chatlog @@ -0,0 +1,328 @@ +Multimedia-chat-meeting-2018-01-09 + +10:04 < pinchartl> hello everybody +10:04 < pinchartl> it looks like we have a full house today +10:04 < kbingham> \o/ +10:04 < pinchartl> at least if Magnus is here +10:04 < pinchartl> but he doesn't seem to be +10:04 < pinchartl> first topic, status report +10:05 < pinchartl> * Kieran +10:05 < pinchartl> Since last meeting: +10:05 < pinchartl> - More GMSL/V4L async work (before Xmas) +10:05 < pinchartl> - Christmas / NY Holidays +10:05 < pinchartl> - HDMI Interlaced support query +10:05 < pinchartl> Until next meeting: +10:05 < pinchartl> - Additional tasks still to be confirmed, but those. +10:05 < pinchartl> - Resubmit kmstest verification based on review comments +10:05 < pinchartl> Issues and Blockers: None +10:05 < pinchartl> kbingham: anything to add ? +10:05 < kbingham> That's it from me I believe currently +10:05 < pinchartl> thank you +10:05 < pinchartl> * Morimoto-san +10:05 < pinchartl> Since last meeting: +10:05 < pinchartl> - Pinged OmniVision / IMI, no reply yet +10:05 < pinchartl> - More ALSA SoC framework cleanup +10:05 < pinchartl> - M3N Salvator-XS board export paper work (?) +10:05 < pinchartl> Until next meeting: +10:05 < pinchartl> - Keep pushing Omnivision and IMI +10:05 < pinchartl> - More ALSA SoC framework cleanup +10:05 < pinchartl> Issues and Blockers: None +10:05 < pinchartl> morimoto: anything to add ? +10:06 * morimoto Renesas Japan is very slow now +10:07 < morimoto> I have +1 for C) +10:07 < morimoto> I can't find DU jitter patch on Linux-Next > pinchartl? +10:07 < morimoto> [1/2] drm: rcar-du: use 1000 to avoid misunderstanding in rcar_du_dpll_divider() +10:07 < morimoto> [2/2] drm: rcar-du: calculate DPLLCR to be more small jitter +10:07 < pinchartl> it's in my tree but I'm afraid I missed the merge window with the xmas holidays. I'll send a pull request for the next kernel version +10:08 < morimoto> OK, thans +10:08 < morimoto> s/thans/thanks +10:08 < pinchartl> you're welcome +10:08 < pinchartl> * Niklas +10:08 < pinchartl> Since last meeting: +10:08 < pinchartl> - [RFC 0/2] v4l2-ctl: add ROUTING get and set options +10:08 < pinchartl> - [PATCH 0/4] Update the max9286 to the new multiplexed pad implementation +10:08 < pinchartl> - [PATCH/RFC v2 00/15] Add multiplexed pad streaming support +10:08 < pinchartl> - [HACK/RFT] v4l: max9286: take route configuration into account when configuring +10:08 < pinchartl> - Working on review comments from Laurent on rcar-vin. +10:08 < pinchartl> - Multiplexed streams support without a pad+stream-aware s_stream() +10:08 < pinchartl> There could be a way to add multiplexed stream support without the need for a pad+stream aware s_stream() implementation. More tests are needed but if it turns out OK adding multiplexed stream support upstream should be a lot easier. +10:08 < pinchartl> Until next meeting: +10:08 < pinchartl> - Post next version of VIN and CSI-2 +10:08 < pinchartl> - Keep working on the multiplexed pad series +10:08 < pinchartl> Issues and Blockers: None +10:08 < pinchartl> neg: anything to add ? +10:09 < pinchartl> should we try to schedule some time for Lager CEC tests ? +10:09 < neg> Yes that is the only thing I forgot to mention +10:09 < neg> Basicly whenever you have time and feel like it +10:09 < neg> Othre then that nothing to add +10:09 < pinchartl> this afternoon should work for me +10:10 < neg> sounds good +10:10 < pinchartl> * Laurent +10:10 < pinchartl> Since last meeting: +10:10 < pinchartl> - Submitted display color keying support for Gen3 +10:10 < pinchartl> - More patch review (including the VIN driver) +10:10 < pinchartl> Until next meeting: +10:10 < pinchartl> - Prepare the FOSDEM code camp +10:10 < pinchartl> I will work with the team to make sure all dependencies are sorted out, that +10:10 < pinchartl> necessary hardware will be available, and that support channels will be in +10:10 < pinchartl> place. +10:10 < pinchartl> - Virtualization investigation +10:10 < pinchartl> - Experiment dim usage for V4L2 maintenance +10:10 < pinchartl> The dim tool is available at https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html. +10:10 < pinchartl> Issues and blockers: None +10:11 < pinchartl> * Ulrich +10:11 < pinchartl> Since last meeting: +10:11 < pinchartl> - Sent ZG clock support for M3-W +10:11 < pinchartl> - Sent patches to get out-of-tree Rogue GPU driver to work on M3-W mainline +10:11 < pinchartl> - Working out with Jinso how to test the GPU support +10:11 < pinchartl> Until next meeting: +10:11 < pinchartl> Issues and Blockers: None +10:11 < pinchartl> uli___: you mentioned last time that you would mix and match the various versions of GPU user space libraries to get OpenGL working +10:11 < pinchartl> what's the status of that ? +10:12 < uli___> no success yet. the jinso tester is trying it with yocto, but that hasn't succeeded yet +10:12 < uli___> we're working on it still +10:13 < pinchartl> ok +10:13 < pinchartl> should I add it to the tasks you will work on during the next two weeks then ? +10:13 < uli___> please do so +10:13 < pinchartl> thanks +10:14 < pinchartl> and regarding the patches to get the out-of-tree GPU driver to work on M3-W mainline, I think you mentioned it as done during the last meeting already. is it a wrong copy&paste ? +10:14 < pinchartl> or has there been new work in that area ? +10:15 < uli___> i think i mixed up the dates because i sent it out after the meeting, but it was done before +10:15 < uli___> or something like that +10:16 < pinchartl> no worries +10:16 < pinchartl> that's it for the status reports, unless there is any question ? +10:16 < jmondi> pinchartl: where's mine status? :) +10:17 < jmondi> s/mine/my +10:17 < pinchartl> oops :-) +10:17 < pinchartl> * Jacopo +10:17 < pinchartl> Since last meeting: +10:17 < pinchartl> - Submitted CEU v2 and v3 +10:17 < pinchartl> - Submitted OV7670 v1 and v2 (DT parsing and PLL calculation) +10:17 < pinchartl> - Enable single camera capture with GMSL on Salvator-X v4.15-rc4 +10:17 < pinchartl> - GMSL patch reviews and discussions +10:17 < pinchartl> - Attempted to build Cogent GMSL Yocto layer (in progress) +10:17 < pinchartl> Until next meeting: +10:17 < pinchartl> - Submit CEU v4 (should be the last one) +10:17 < pinchartl> If the driver gets merged, start compile porting other SH boards that use old CEU driver. +10:17 < pinchartl> - Build and test the Cogent GMSL Yocto layer before the code camp +10:17 < pinchartl> - Keep pushing Maxim for support +10:17 < pinchartl> - Re-send v4l2-async debug patches +10:17 < pinchartl> There seems however to be little interest in the topic upstream given that use cases currently merged mainline are quite trivial. +10:17 < pinchartl> Issues and Blockers: None +10:17 < pinchartl> here :-) +10:17 < pinchartl> sorry +10:17 < pinchartl> any comment ? +10:18 < jmondi> if nothing breaks I should be able to compile Cogent's yocto images thanks to Vladimir provided link +10:19 < jmondi> I mean, it's running righ now.. apart from that, no +10:19 < pinchartl> let's see if something breaks then :) +10:19 < neg> \o/ +10:19 < jmondi> of course it will +10:19 < pinchartl> Morimoto-san, is there any question from the BSP team this time ? +10:20 < morimoto> I'm sending small question email to periperi ML +10:20 < morimoto> So no more topic from BSP team +10:20 < pinchartl> ok, thank you +10:21 < pinchartl> next topic, additional tasks +10:22 < pinchartl> I haven't heard back from Magnus since December the 22nd +10:22 < pinchartl> Morimoto-san, do you know if he's still alive ? +10:23 < neg> Too much Chirstmas food, still in food coma? +10:24 < morimoto> pinchartl: I don't know... +10:25 < pinchartl> :-/ +10:26 < pinchartl> I'm afraid all we can do is wait and see. the last thing I heard was that Magnus wanted a light Q1/1 and a heavier Q1/2. that means 5 days of additional multimedia tasks each for Niklas and Jacopo, and 10 days for Kieran and me +10:26 < pinchartl> for Q1/1 +10:26 < pinchartl> with the leftover in Q1/2 +10:27 < pinchartl> this means that more of the base contract should be consumed in Q1/1 (there will thus be very little left for Q1/2) +10:27 < pinchartl> and we of course need to agree on tasks for Q1/2 earlier than mid-February, in order to start working on them soon enough +10:27 < jmondi> pinchartl: you do have a list of possible tasks? +10:27 < morimoto> Hmm... I will contact to him tomorrow +10:28 < pinchartl> end of January would be my personal deadline for that, and I'd prefer earlier +10:28 < neg> pinchartl: I was offerd a IO additonal task for the first half of Q1 by wsa_, had you wished for me to also do a 5 day MM task during the first part of Q1 ? +10:28 < pinchartl> neg: Magnus would like you to have 5 days for multimedia, yes +10:28 < pinchartl> jmondi: the list was posted in the last meeting report +10:28 < pinchartl> and from that the following tasks were pre-selected: +10:29 * jmondi digs his emails +10:29 < pinchartl> - Multimedia PFC development (D3 + M3-N) +10:29 < pinchartl> - BRS/BRU bug fix (on your task list) +10:29 < pinchartl> - V3M Multimedia integration upstreaming +10:29 < pinchartl> - D3 ADV chip slave address conflict workaround +10:29 < pinchartl> - Multimedia Virtualization Investigation +10:30 < pinchartl> but I'm not entirely happy with that, I voiced my concerns to Magnus and I'm waiting for his feedback +10:32 < jmondi> ok, let's wait and see +10:32 < jmondi> there's plenty of GMSL related development, now that I see the list you shared after last meeting +10:32 < pinchartl> morimoto: thanks for offering to contact Magnus +10:33 < pinchartl> jmondi: Magnus wanted to focus on tasks that can produce upstream patches in Q1/1 +10:33 < pinchartl> so there will likely be no GMSL additional task scheduled +10:33 < jmondi> makes sense.. +10:33 < pinchartl> the GMSL code camp thus has to be covered by the base contract I'm afraid +10:34 < pinchartl> any other question related to additional tasks ? +10:34 < jmondi> not from here +10:35 < pinchartl> next topic then, the FOSDEM meeting +10:36 < pinchartl> first of all +10:36 < pinchartl> uli___: have you decided whether you will come to Brussels ? +10:36 < uli___> probably yes +10:37 < pinchartl> good news :) +10:37 < pinchartl> when would you arrive ? +10:37 < uli___> i basically made that decision the minute you asked, so i haven't worked out the details yet :) +10:38 < pinchartl> :-) +10:38 < pinchartl> well, let us know +10:38 < uli___> ok +10:38 < pinchartl> as everybody should be aware by now, there will be a GMSL code camp from Monday to Thursday +10:38 < pinchartl> we will have a multimedia meeting on Thursday afternoon +10:38 < pinchartl> and the core and I/O meetings will be on Friday +10:39 < pinchartl> the code camp and multimedia meeting will be held at Rue Antoine Dansaert 24, +10:39 < pinchartl> 1000 Brussels +10:39 < wsa_> pinchartl: can you add that to the internal wiki? +10:39 < pinchartl> wsa_: sure +10:39 < wsa_> thanks! +10:39 < pinchartl> we have rented an apartment +10:40 < pinchartl> and Jacopo, Kieran, Niklas and me will stay there +10:40 < pinchartl> the code camp will focus on GMSL development, and we need to plan for that +10:40 < pinchartl> on Thursday evening I have booked a table for dinner at Bonsoir Clara, Rue Antoine Dansaert 22, 1000 Brussels +10:40 < pinchartl> as you can notice it won't take long to get there :-) +10:41 < kbingham> pinchartl: Is Niklas in the apartment too? I thought he was staying with WSA? +10:41 < pinchartl> currently Jacopo, Kieran (+ Keri), Niklas, Simon and me have confirmed attendence +10:41 < geertu> and Hugo? +10:42 < kbingham> Anywhere Keri goes - Hugo goes :D +10:42 < pinchartl> and Hugo, yes +10:42 < pinchartl> I have thus booked a table for 6 adults. if anyone else wants to join, please let me know ASAP +10:42 < pinchartl> neg: if I'm not mistaken you will stay with us for the first half of the week and then move in with Wolfram, right ? +10:43 < neg> pinchartl: yes +10:43 < pinchartl> neg: what are the dates ? +10:44 < neg> pinchartl: I will stay with wsa_ from Friday to Monday +10:45 < pinchartl> ok +10:46 < pinchartl> any question regarding the logistics ? we'll then get to the topic of GMSL code camp planning +10:47 < neg> And so I don't mess up the apartment is avliable from the afternoon-ish on Sun the 28th right? +10:47 < jmondi> I will probably arrive earlier than everybody else, so I might want to sync with Kieran to enter the apartment +10:47 < kbingham> I arrive in Brussels at 19:45 on the sunday. +10:48 < pinchartl> neg: correct +10:48 < kbingham> I assumed pinchartl would be the first to arrive, and have thus added his name to the booking so he can check in. +10:48 < pinchartl> I'll arrive on Sunday as well but I'm not sure when yet +10:48 < kbingham> (/side note - I've since seen whomever checks in gets the priviledge of paying) +10:48 < pinchartl> jmondi: at what time will you arrive ? +10:48 < jmondi> let me check again +10:48 < jmondi> I guess it's 7pm +10:48 < jmondi> so not that earlier as I first thought +10:49 < jmondi> 19:35 +10:49 < jmondi> I guess I will meet Kieran&family at the airport +10:49 < pinchartl> I'll likely arrive earlier +10:49 < kbingham> jmondi: We can probably share a taxi or something in that case :) +10:49 < jmondi> kbingham: sure thing +10:50 * kbingham needs to move from the sofa to the office to plug laptop in ... +10:50 < pinchartl> could you please all fill your travel dates (and times if possible) in https://osdr.renesas.com/projects/linux-kernel-development/wiki/Periperi-2018-02 ? +10:51 < neg> I have yet to book my flight but will update wiki once I have done so +10:51 < pinchartl> kbingham: taxi is an option, otherwise you can take the train to Brussels North, and from there metro 3 or 4 to La Bourse - Beurs. the metro stop is a 5 minutes walk to the apartment (one block and a half) +10:53 < pinchartl> regarding the GMSL code camp +10:53 < kbingham> pinchartl: That might be better than us bringing a car seat actually. +10:53 < pinchartl> kbingham: it's pretty easy yes +10:53 < pinchartl> about 15-20 minutes by train from the airport to Brussels North +10:53 < pinchartl> you can even buy the train ticket while waiting for your luggage at the airport +10:54 < kbingham> :D +10:54 < pinchartl> we need to plan for hardware availability +10:54 < pinchartl> I believe the following would be useful +10:54 < pinchartl> H3 + expansion +10:54 < pinchartl> V3M +10:54 < pinchartl> H3 + kingfisher +10:54 < pinchartl> and of course cameras +10:54 < pinchartl> I'll bring the kingfisher-based setup +10:55 < pinchartl> Kieran and Niklas, you're the only ones to have cameras, please bring them +10:55 < jmondi> easy for me: I have nothing +10:55 < pinchartl> we'll focus on the RDACM20 +10:55 < pinchartl> but it would be useful to have some RDACM21 just in case +10:55 < pinchartl> 8 should be enough, there's no need to have 16 +10:55 < kbingham> I'll bring hte RDACM21's too ... they won't take up much room. +10:56 < pinchartl> the V3M is with Kieran if I'm not mistaken, Niklas you don't have one, right ? +10:56 < kbingham> I have V3M yes. +10:57 < kbingham> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Hardware says neg has one too! +10:57 < pinchartl> I'm not sure we will need the V3M though +10:58 < neg> Yes I have a V3M +10:58 < pinchartl> Kieran, you've worked on GMSL for V3M, would you focus on H3 + expansion or on V3M ? +10:58 < pinchartl> maybe Niklas could bring the V3M and Kieran the H3 + expansion ? +10:59 < neg> And I will bring all 16 cameras in case there should be some trading, maybe it would be useful to return some to pinchartl as he now has a kingfisher? +10:59 < pinchartl> neg: but then it would be useful if you could test Kieran's GMSL V3M patches beforehand, to make sure your hardware is functional +10:59 < pinchartl> neg: good point +10:59 < neg> pinchartl: I have tested my V3M and I can capture from it +10:59 < pinchartl> neg: perfect :) +11:00 < pinchartl> so that would be one H3 + expansion (Kieran), one V3M (Niklas) and one Kingfisher (Laurent) +11:00 < pinchartl> I think that should be enough +11:01 < pinchartl> jmondi: would you be able to bring your scope ? +11:01 < jmondi> I could, yes +11:02 < pinchartl> I'll bring a multimeter, a second one would be useful if someone could bring one +11:02 < jmondi> I have no boards, after all :) +11:02 < pinchartl> jmondi: I'd advise packing the scope in carry-on luggage and the probes in checked luggage +11:02 < jmondi> pinchartl: why that? +11:02 < pinchartl> because the scope is fragile and the probes are pointy +11:03 < pinchartl> you might have trouble going through security with the probes +11:03 < jmondi> indeed +11:03 < jmondi> I hope I'll be able to carry the scope in my carry-on +11:03 < pinchartl> and I would be worried packing a scope in checked luggage, as there are risks of losing it (or getting it stolen) +11:04 < jmondi> yes, I was thinking the same +11:04 < jmondi> I should be able to bring it, no worries +11:05 < geertu> FWIW, I had no issues with my scope probes when going to San Sebastian +11:05 < jmondi> geertu: better safe than sorry +11:06 < pinchartl> I'll bring a multimeter, a second one would be useful if someone could bring one +11:06 < jmondi> or, better safe than inspected +11:06 < pinchartl> oops, sorry, already mentioned that :) +11:06 < pinchartl> who has a multimeter he can bring ? +11:06 < geertu> I did suffer from my racial profiling in Biarritz, I think. +11:06 < neg> kbingham: I can bring my logic probe, is it possible to prep the break-out camera with i2c probe points? Or do the camera still break if probes are attached? +11:06 < jmondi> pinchartl: I do have a very basic one +11:06 < kbingham> neg: I'll bring hte breakout yes. The points are still attached and glued. +11:06 < neg> kbingham: greate! +11:07 < jmondi> geertu: being belgian increases the chances of being randomly selected for inspections in France? +11:07 < pinchartl> neg: good idea, thanks +11:07 < geertu> When I had issues understanding their "French", they asked where I was from, and immediately stopped bothering me. +11:07 < pinchartl> jmondi: please bring the multimeter if you can, thanks +11:08 < pinchartl> please all bring cables (network, USB and display) and power supplies for all the boards you will bring +11:08 < geertu> So I guess their French was the local Spanish from just across the border +11:08 < pinchartl> we will need power strips. in the worst case we can buy them in Belgium, but if you have space in your luggage please think about bringing a power strip +11:09 < kbingham> And a network switch +11:09 < kbingham> I can bring one - but it will be powered by a UK plug - an EU plug version would be useful. +11:09 < pinchartl> I only have a small 4-ports switch. can someone bring a larger one ? we'll need 8 ports +11:10 < pinchartl> kbingham: agreed +11:11 < pinchartl> I'll try to bring the power strip I bought in San Sebastian :) +11:11 < jmondi> I have a shiny new 8 ports switch +11:11 < neg> I also only have small 4port switch, but can bring if there is a need +11:11 < pinchartl> jmondi: could you bring it ? +11:11 < jmondi> still to be unpacked +11:12 < jmondi> I will +11:12 < pinchartl> thank you +11:12 < pinchartl> anything else we need to bring ? +11:12 < jmondi> I would like to write this list down... wiki page? +11:13 < pinchartl> I'll include it in the meeting report but we can add it to the wiki, yes, that's a good idea +11:13 < jmondi> doing it right now +11:13 < pinchartl> thank you +11:14 < pinchartl> that's it for me for the GMSL code camp topic +11:15 < pinchartl> the last topic for today is the next meeting, which will be held on 2018-01-25 (back on a Thursday) at the usual time +11:15 < pinchartl> is there anything else than anyone wants to discuss ? +11:16 < pinchartl> regarding the GMSL code camp I still want to synchronize with all of you and make sure we won't be blocked by any missing dependency but we can do that later +11:16 < neg> Anything else then GMSL preparations that should be prepared for the face-to-face meeting? +11:16 < pinchartl> this afternoon if everybody is available +11:17 < pinchartl> neg: good point. I don't think there's any need to prepare anything (well, I'll prepare a planning proposal), but if there's any topic you'd like to discuss, please submit it by e-mail +11:17 < wsa_> I'd like to discuss the time slots on 2018-01-25 +11:17 < wsa_> but we can do that by mail +11:17 < jmondi> pinchartl: sorry, I didn't get it.. would you like to meet thsi afternoon? +11:18 < wsa_> if possible, I'd like if IO is not first; the later the better +11:18 < pinchartl> jmondi: yes, to discuss GMSL, if you're available +11:18 < pinchartl> wsa_: multimedia has a tendency to spread over the 30 minutes boundary so it's convenient if it's last, but I'm sure we can find a schedule that will suit everybody +11:19 < neg> this afternoon works for me, I will work as always until ~17:00 CET then a break until ~22:00 CET. But is avilable inbetween if scheduled time as I try to do something else then sit at my desk duing the break :-) +11:19 < pinchartl> any time from 14:00 to 17:00 CET is fine with me +11:19 < jmondi> any time before 7pm is fine with me +11:20 < morimoto> So, JaPERIese side will quick. Thanks, bye-bye +11:21 < pinchartl> morimoto: thank you for attending. have a nice evening +11:21 < morimoto> thanks. happy new year, you guys +11:21 < pinchartl> kbingham: any preference time-wise ? +11:21 < kbingham> pinchartl: I'll leave the office at 5.30 GMT today... +11:22 < pinchartl> should we go for 14:00 CET ? or a bit later to allow Kieran to have a proper lunch break ? 14:30 CET ? +11:22 < kbingham> 14.00 CET will be fine here. +11:22 * kbingham usually eats lunch 'al desko' +11:23 < pinchartl> jmondi: is 14:00 CET OK for you too ? I know you usually have lunch late +11:23 < jmondi> no, it's fine +11:23 < pinchartl> ok +11:23 < jmondi> I can have lunch while talking with you :) +11:24 < pinchartl> it's settled then +11:24 < pinchartl> any other topic for today? +11:26 < neg> pinchartl: shall we try for the lager test after the GMSL meeting? +11:26 < pinchartl> neg: yes, or even at the same time :-) +11:26 < neg> pinchartl: sure :-) +11:26 < pinchartl> no other topic, I propose adjourning this meeting. does anyone second ? +11:27 < jmondi> yup! I'll see you later then +11:27 < pinchartl> meeting adjourned. thank you all for attending, and talk to you at 14:00 CET for GMSL diff --git a/wiki/Chat_log/20180125-core-chatlog b/wiki/Chat_log/20180125-core-chatlog new file mode 100644 index 0000000..3ad4f17 --- /dev/null +++ b/wiki/Chat_log/20180125-core-chatlog @@ -0,0 +1,129 @@ +Core-chat-meeting-2018-01-25 + +09:06 < geertu> Welcome to today's Core Group Chat +09:06 < geertu> Agenda: +09:06 < geertu> 1. Status Updates +09:06 < geertu> 2. Discussion Topics +09:06 < geertu> 3. PERIPERI BE Agenda +09:06 < geertu> Topic 1. Status updates +09:06 < geertu> A) What have we done since last time +09:06 < geertu> Jacopo started looking into the M3-N task and booted to console. +09:06 < geertu> Marek worked on the U-Boot platform conversion for R-Car Gen2 (Porter +09:06 < geertu> done). +09:06 < geertu> Shimoda-san continued evaluation of the M3-N IPMMU HW, which now works for +09:06 < geertu> VIN. +09:07 < geertu> Simon added soc nodes to R-Car Gen2 DTS files, and continued IPMMU +09:07 < geertu> integration. +09:07 < geertu> Geert fixed regressions in -next, upgraded firmware and U-Boot on +09:07 < geertu> Salvator-X(S), got QEMU+KVM working on arm64 (needs firmware with HYP mode, +09:07 < geertu> see https://elinux.org/R-Car/Virtualization), and started looking into GPIO +09:07 < geertu> pass-through using vfio-platform. +09:07 < geertu> EOF +09:08 < geertu> B) What we plan to do till next time +09:08 < geertu> Many Euro-members plan to enjoy PERIPERI BE and FOSDEM. +09:08 < geertu> Jacopo will start looking into PFC for M3-N. +09:08 < geertu> Marek will convert more R-Car Gen2 platforms to the new U-Boot, and start +09:08 < geertu> working on Stout after its arrival. +09:08 < geertu> Shimoda-san will discuss a plan to improve the IPMMU driver with +09:08 < geertu> Magnus-san. +09:08 < geertu> Simon will test CPUFreq/Z,Z2 Clock patches on BIG.little using Lager board +09:08 < geertu> to be borrowed from Wolfram, and is considering adding soc nodes to other +09:08 < geertu> DTSes. +09:08 < geertu> Geert will do more virtualization work (documentation, GPIO pass-through), +09:08 < geertu> and revisit in-kernel BD9571MWV DDR backup mode. +09:09 < geertu> EOF +09:09 < geertu> C) Problems we have currently +09:09 < geertu> None +09:09 < geertu> EOF +09:10 < geertu> That was quick ;-) +09:10 < neg> :-) +09:10 < geertu> Anything I missed, or that needs explanation? +09:11 < jmondi> I would have a question for morimoto-san, on Migo-R clocks, as it seems he and Magnus are the authors of that code +09:11 < jmondi> am I wrong Morimoto-san? +09:12 < morimoto> which clock ? +09:12 < jmondi> video_clk +09:12 < jmondi> it is said to be reduced to 10MHz for display panel issue, does this rings any bell to you? +09:12 < morimoto> Migo-R... I don't remember detail... +09:13 < jmondi> ok, I'll ping you offline maybe, don't want to hold the meeting for this +09:13 < morimoto> thanks +09:13 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi +09:13 < Marex> shimoda: any news on the RPC QSPI erase/write example please ? +09:13 < geertu> Topic 2. Discussion Topics +09:14 < morimoto> Marex: Now I'm working for export paper work for mini monitor +09:14 < Marex> morimoto: uh, sorry to make you suffer through that and thank you very much ! +09:14 < Marex> shimoda: ^ you too +09:14 < morimoto> No problem, but this paper work will takes more time. +09:16 < Marex> I was hoping there would be some small RPC QSPI example, I don't really need the entire minimon, but having the whole thing might be nice too ! +09:16 < shimoda> Marex: RPC QSPI erase/write example is in part of mini monitor code, so we have to finish the export paper work that Morimoto-san said +09:16 < Marex> aha, so that's why +09:16 < Marex> understood +09:17 < Marex> I'll see if I can get the SPI NOR access through GPIO bitbang during fosdem going at least +09:17 < Marex> as a stop-gap solution that is +09:18 < dammsan> Marex: please implement hyperflash gpio support =) +09:19 < geertu> dammsan: spi-gpio doesn't even do dual or quad mode yet +09:19 < Marex> dammsan: we have RPC HF support, doing it over GPIO would be painfully slow with no benefit +09:19 < geertu> should be fairly simple to add +09:19 < geertu> with GPIO [gs]et_multiple +09:19 < Marex> dammsan: plus, all the platforms that boot from HF that I have don't support GPIO on the HF pins :( +09:20 < Marex> it's only V3M and D3 that support that AFAIU +09:20 < Marex> M3/H3 cannot mux the RPC pins as GPIOs according to the documentation +09:20 * Marex would be happy to be proven wrong ... +09:21 < geertu> Marex: Remote access to D3 and V3m does exist... +09:22 < Marex> geertu: I know +09:22 < pinchartl> (hello) +09:22 < geertu> pinchartl: Hi +09:23 < geertu> pinchartl: You're earlier than wsa ;-) +09:23 < geertu> Marex: Not having GPIO muxes on the RPC pins is a security feature +09:24 < pinchartl> :-) +09:24 < Marex> geertu: not on V3M/D3 apparently +09:24 < geertu> Marex: Different target market segment +09:24 < Marex> :) +09:28 < pinchartl> as Wolfram isn't here yet should we start with multimedia ? +09:29 < Marex> pinchartl: give him 2 minutes ? +09:29 < Marex> in the meantime, I have one more question ... +09:30 < Marex> ... I have a spare M3SK, I'll take it to FOSDEM, anyone wants it ? +09:30 < geertu> M3SK = M3ULCB? +09:30 < Marex> jupp +09:30 < Marex> ... improved edition with mainline u-boot ! +09:30 < jmondi> If nobody else wants it, I do :) +09:30 < geertu> Could you please check if it does PSCI system suspend/resume? +09:31 < jmondi> that would be useful for kingfisher expansion maybe +09:31 < Marex> jmondi: sold to this gentlemen ! +09:31 < geertu> Does "reset" work from U-Boot? +09:31 < geertu> Does "reboot" work from Linux? +09:31 * Marex knocks the gavel +09:31 < pinchartl> jmondi: you'd need a kingfisher base board though +09:31 < jmondi> wait, maybe someone has more urgent things to do, afaik only pinchartl has been able to purchase a kingfisher expansion +09:31 < jmondi> pinchartl: it's not pluggable? +09:32 < Marex> geertu: drop me an email about it +09:32 < pinchartl> jmondi: it is, but you'd still need the board :-) +09:33 < jmondi> pinchartl: ah yes, but with a bit of patience I may be able to buy one, am I not? +09:33 * kbingham holds out for a condor with 8 fakra's on the same board :D +09:33 < morimoto> pinchartl: btw, did you receive KF ? +09:34 < pinchartl> morimoto: yes I did +09:34 < pinchartl> I have trouble paying it though +09:34 < morimoto> pinchartl: OK, sounds good +09:34 < pinchartl> I sent the money and the transfer was delayed +09:34 < pinchartl> my bank says the receiving bank in Japan is blocking the payment because they want to conduct additional verifications +09:35 < pinchartl> and Shimafuji says their bank just hasn't received the money +09:36 < horms> pinchartl: I initiate a transfer from inside Japan. Perhaps we can explore that option if you can't get yourself unstuck +09:37 < morimoto> pinchartl: sounds not good :( +09:37 < geertu> horms: And as soon as that one completes, pinchartl's will complete, too ;-) +09:38 < geertu> pinchartl: Anyway, you do have the board? Or will they send you the launch codes after receiving the money? +09:40 < pinchartl> horms: thanks. the money has already left my bank account though, so I'd want to make sure it comes back before sending it a second time :-) +09:40 < pinchartl> morimoto: I know :-( +09:40 * pinchartl dislikes banks +09:40 < morimoto> bit-coin :) +09:40 < horms> pinchartl: ack. i would want that oo +09:40 < horms> pinchartl: ack. i would want that too +09:40 < uli___> if it is any consolation, i've had such issues several times, and the money never gets lost +09:40 < uli___> but it can take a very long time to sort it out... +09:40 -!- geertu [~geert@d54C36AF6.access.telenet.be] has quit [Ping timeout: 265 seconds] +09:41 -!- geertu [~geert@d54C36AF6.access.telenet.be] has joined #periperi +09:41 -!- Topic for #periperi: marzen lock holder = none / managed in-channel rather than in-topic +09:41 -!- Topic set by geertu [] [Thu Oct 1 16:19:22 2015] +09:41 -!- Channel #periperi created Wed Jul 8 12:41:24 2015 +09:41 -!- Irssi: Join to #periperi was synced in 16 secs +09:41 < pinchartl> geertu: anything left for core or can we start with multimedia ? +09:42 < geertu> pinchartl: Just the shared partm that needs to wait for wsa +09:42 < geertu> So please go ahead! diff --git a/wiki/Chat_log/20180125-mm-chatlog b/wiki/Chat_log/20180125-mm-chatlog new file mode 100644 index 0000000..8a99d2d --- /dev/null +++ b/wiki/Chat_log/20180125-mm-chatlog @@ -0,0 +1,235 @@ +Multimedia-chat-meeting-2018-01-25 + +09:42 < pinchartl> so welcome to the multimedia meeting +09:42 < pinchartl> I think we have a full house today +09:42 < pinchartl> jmondi, kbingham[m], dammsan, morimoto, neg, uli___, yes +09:42 < pinchartl> first topic, status updates +09:43 < pinchartl> from last to first, let's start with Morimoto-san +09:43 < pinchartl> I'll post the update and ask for comments, like last time +09:44 < pinchartl> Since last meeting: +09:44 < pinchartl> - Posted ALSA SoC framework main cleanup patches +09:44 < pinchartl> Patches are too big, asked each driver author to test them. Few issues are already noticed and fixup patches posted. +09:44 < pinchartl> - Export paper work for datasheet, schematic, board, etc +09:45 < pinchartl> Until next meeting: +09:45 < pinchartl> - Continue the ALSA SoC framework things +09:45 < pinchartl> Issues and Blockers: None (other than paperwork killing your soul) +09:45 < pinchartl> any comment ? +09:47 < morimoto> no comment +09:47 < pinchartl> while waiting for comments, let's continue with Niklas +09:47 < pinchartl> ok :-) +09:47 < pinchartl> thank you +09:47 < pinchartl> neg: +09:47 < pinchartl> Since last meeting: +09:47 < pinchartl> - [PATCH 0/5] GMSL: enable multiple simultaneous streams from the same MAX9286 +09:47 < pinchartl> - [PATCH] v4l2-dev.h: fix symbol collision in media_entity_to_video_device() +09:47 < pinchartl> - Prepared VIN, CSI-2 and multiplexed patches for the GMSL code camp +09:47 < pinchartl> Until next meeting: +09:47 < pinchartl> - Media code camp working on GMSL related stuff.. +09:47 < pinchartl> - Post next versions of VIN, CSI-2 and multiplexed pads series +09:47 < pinchartl> - Look if rcar-vin can more aggressively switch to continues capture mode if it due to buffer starvation enters single capture mode. +09:47 < pinchartl> - Start on DU integration for V3M. +09:47 < pinchartl> Issues and Blockers: +09:47 < pinchartl> - Laurents excellent review comments on VIN have resulted in a rewrite of some parts of the driver. End result is much cleaner but have taken more time than expected. +09:47 < pinchartl> any comment ? +09:48 < neg> Thanks for your comments, other than that no :-) +09:48 < pinchartl> next, Jacopo +09:48 < pinchartl> Since last meeting: +09:48 < pinchartl> - v4/5/6 of the CEU driver +09:48 < pinchartl> Rebased on Hans' parm branch, fixed v4l2-compliance issues. +09:48 < pinchartl> - Add DTS support to ov7670 driver +09:48 < pinchartl> This was needed to test CEU polarities, now waiting for DT bindings ack. +09:48 < pinchartl> - Build and test the Cogent GMSL Yocto layer +09:48 < pinchartl> - Got FSYNC working +09:48 < pinchartl> Compared Cogent's settings again then niklas->magic() and got fsync working +09:48 < pinchartl> keeping reverse communication channel open as GPO transitions are sent through +09:48 < pinchartl> it. +09:48 < pinchartl> Until next meeting: +09:48 < pinchartl> - GMSL Code Camp: consolidate setup and test fsync reliability +09:48 < pinchartl> - Brussels FOSDEM +09:48 < pinchartl> - Handle frame rate setting in the ov7720 driver +09:48 < pinchartl> This implies working on Migo-R clocks and reverse engineer a poorly documented +09:48 < pinchartl> sensor. Hans won't take the driver otherwise, or we can park it in staging. +09:48 < pinchartl> Issues and Blockers: None +09:48 < pinchartl> any comment ? +09:49 < jmondi> nope +09:49 < jmondi> that's all +09:49 < pinchartl> thanks +09:49 < pinchartl> next, Ulrich +09:49 < pinchartl> Since last meeting: +09:49 < pinchartl> - Attempted to get mainline-patched GSX driver to work with Yocto +09:49 < pinchartl> Until next meeting: +09:49 < pinchartl> - Multimedia meeting in Belgium +09:49 < pinchartl> - Brussels FOSDEM +09:49 < pinchartl> - Multimedia-related PFC upstreaming for Gen3 SoCs +09:49 < pinchartl> Issues and Blockers: +09:49 < pinchartl> - The GSX driver still doesn't work (except for OpenCL) +09:49 < pinchartl> Even the officially sanctioned Yocto userspace fails, so it seems increasingly +09:49 < pinchartl> unlikely that it is userspace-related. Help from someone (i.e. Laurent) to +09:49 < pinchartl> check if the up-port of the DRM bits in Rogue driver makes sense when we meet +09:49 < pinchartl> in Brussels would be useful. +09:49 < pinchartl> any comment ? +09:50 < uli___> please help me. :) +09:50 < pinchartl> :-) +09:50 < morimoto> :) +09:50 < pinchartl> I think we can have a look at it in Brussels +09:50 < uli___> ok, thanks +09:50 < pinchartl> can you make sure to prepare everything to avoid spending time with build or other similar issues ? +09:51 < uli___> i'll prepare everything +09:51 < pinchartl> you will arrive on Thursday, right ? +09:51 < uli___> yes, early afternoon +09:51 < pinchartl> let's try to address that on Thursday later afternoon then +09:52 < uli___> ok +09:52 < uli___> there's going to be an h3 board there, right? +09:52 < pinchartl> I'll have a kingfisher with an H3SK +09:52 < pinchartl> and Kieran will bring a Salvator-XS +09:53 < pinchartl> next, Kieran +09:53 < pinchartl> * Kieran +09:53 < pinchartl> Since last meeting: +09:53 < pinchartl> - GMSL investigations and Yocto builds with Jacopo +09:53 < pinchartl> Extracted the Cogent Kernel so we can build independently. +09:53 < pinchartl> - ADV748x TXB lane power investigation and support +09:53 < pinchartl> - vsp1/tlb-optimise/v5 (rebase for updated DRM/UIF) +09:53 < pinchartl> - Eagle-V3M Display testing +09:53 < pinchartl> - ADV748x invalid page mapping fix +09:53 < pinchartl> - ADV7511 device tree I2C address mapping +09:53 < pinchartl> - ADV7604 device tree I2C address mapping +09:53 < pinchartl> Until next meeting: +09:53 < pinchartl> - GMSL Code Camp +09:53 < pinchartl> - Brussels FOSDEM +09:53 < pinchartl> - H3 ES2.0 LVDS + VGA Performance Investigation +09:53 < pinchartl> Issues and Blockers: +09:53 < pinchartl> - Draak D3 I2C support not yet integrated into renesas-drivers +09:53 < pinchartl> Draak ADV7511/ADV7612 development is based on out-of-tree patches. +09:53 < pinchartl> any comment ? +09:54 < kbingham> That's it - except for taking advantage of Uli being here so I can ask if he plans to work on the D3 i2c patches anytime (it doesn't matter if you don't plan too - I think geertu might pick the patches up for next renesas-drivers anyway, or I can base on the ones I have) +09:55 < kbingham> or rather uli___: ^ :D +09:55 < uli___> no immediate plan, but that's mostly because i forgot about those +09:55 < pinchartl> that was my question too, what are the plans to get that upstream ? +09:55 < uli___> i'll have a look +09:56 < kbingham> Ok, that's me done for today then :D +09:56 < pinchartl> thank you +09:57 < pinchartl> oh, last time you mentioned you were planning to resubmit kmstest verification based on review comments +09:57 < pinchartl> any update on that ? +09:59 < kbingham> Nope - it got stalled, blocked by other tasks - so I'll try to get that done this cycle. +10:01 < pinchartl> there's no hurry, but please keep it on your todo list +10:01 < pinchartl> I got the order wrong and nearly forgot Jacopo again +10:01 < pinchartl> Since last meeting: +10:01 < pinchartl> - v4/5/6 of the CEU driver +10:01 < pinchartl> Rebased on Hans' parm branch, fixed v4l2-compliance issues. +10:01 < pinchartl> - Add DTS support to ov7670 driver +10:01 < pinchartl> This was needed to test CEU polarities, now waiting for DT bindings ack. +10:01 < pinchartl> - Build and test the Cogent GMSL Yocto layer +10:01 < pinchartl> - Got FSYNC working +10:01 < pinchartl> Compared Cogent's settings again then niklas->magic() and got fsync working +10:01 < pinchartl> keeping reverse communication channel open as GPO transitions are sent through it. +10:01 < pinchartl> Until next meeting: +10:01 < pinchartl> - GMSL Code Camp: consolidate setup and test fsync reliability +10:01 < pinchartl> - Brussels FOSDEM +10:01 < pinchartl> - Handle frame rate setting in the ov7720 driver +10:01 < pinchartl> This implies working on Migo-R clocks and reverse engineer a poorly documented +10:01 < pinchartl> sensor. Hans won't take the driver otherwise, or we can park it in staging. +10:01 < pinchartl> Issues and Blockers: None +10:01 < pinchartl> any comment ? +10:02 < jmondi> you have pasted my report already :) +10:02 < jmondi> this time I don't feel left out :) +10:03 < jmondi> and no comments neither this time! +10:03 * pinchartl needs to wake up -_-' +10:03 < pinchartl> a few questions though +10:04 < pinchartl> do you still need support from Omnivision and Maxim ? +10:04 < jmondi> for GMSL? +10:04 < jmondi> I guess we'll find out once we can test fsync stability a bit more in Brussels +10:05 < morimoto> jmondi: I forwarded their response for you. does it works ? +10:05 < pinchartl> of course, but is there any open question for which we're still waiting for an answer ? +10:05 < morimoto> About register setting list +10:05 < jmondi> everything was revolving around fsync, now that niklas has made it working everything else is secondary +10:06 < pinchartl> ok, thanks +10:06 < jmondi> I guess we'll may need support when implementing support for more image resolutions +10:06 < jmondi> morimoto: yes thanks, that would be required when changing the image sizes +10:06 < pinchartl> finally, myself +10:06 < pinchartl> Since last meeting: +10:06 < pinchartl> - Prepared the FOSDEM code camp +10:06 < pinchartl> - DU LVDS rework +10:06 < pinchartl> - Patch review +10:06 < pinchartl> - Started virtualization investigation +10:06 < pinchartl> Until next meeting: +10:06 < pinchartl> - GMSL Code Camp +10:06 < pinchartl> - Brussels FOSDEM +10:06 < pinchartl> - Virtualization investigation +10:06 < pinchartl> Issues and blockers: None +10:08 < morimoto> jmondi: nice to know +10:08 < pinchartl> so that's it for the status update +10:08 < pinchartl> any question or comment ? +10:09 < morimoto> yes +10:09 < morimoto> pinchartl: I still can't find my DU 2 PLL fixup patches on linux-next. +10:10 < pinchartl> morimoto: that's because I still haven't sent the pull request. as the merge window is about to open the DRM tree is currently frozen +10:10 < pinchartl> I will send it as soon as the merge window closes +10:10 < morimoto> OK, your branch is not connected to linux-next directly (I don't know detail of it) +10:11 < pinchartl> no, it gets in linux-next through the DRM tree +10:11 < morimoto> Thanks ! nice to know +10:12 < pinchartl> dammsan: anything to report by any chance ? :-) +10:12 < dammsan> nope, sorry =) +10:12 < dammsan> just that i'm currently discussing your task proposals +10:13 < pinchartl> that at least is nice to hear +10:13 < dammsan> hope to get back to your about that tomorrow +10:13 < pinchartl> which leads to +10:13 < pinchartl> Topic 2. Additional Tasks for 2018 Q1 +10:13 < pinchartl> Additional tasks for 2018 Q1/1 have been approved, and candidates for 2018 +10:13 < pinchartl> Q1/2 submitted. The goal is to agree on the second batch for the end of +10:13 < pinchartl> January. +10:13 < pinchartl> I assume you've all seen the proposals for Q1/2 +10:15 < kbingham> yes, (now refreshed for a second time) +10:16 < pinchartl> neg: what would you think about the single/continuous capture mode support in VIN for Q1/2 ? it seems the BSP team would like to have it sooner than later +10:16 < neg> pinchartl: was just about suggest that so it would work good for me :-) +10:18 < pinchartl> dammsan: would that be OK with you ? +10:20 < dammsan> sure of course +10:20 < pinchartl> can you add it to the list of tasks to discuss with Renesas then ? +10:20 < dammsan> most important is to keep upstream focus though, so as long as we don'tloose that +10:20 < dammsan> i can +10:20 < dammsan> and will +10:21 < pinchartl> thank you +10:21 < pinchartl> jmondi, kbingham, uli___: any comment on the proposed tasks ? +10:21 < neg> dammsan: that task do not depend on VIN Gen3 support being merged first :-) +10:22 < uli___> i would like to look into the size and quality of that igt test suite before deciding whether that is 5 days +10:22 < uli___> other than that, i'm happy +10:22 < dammsan> neg: ok, not sure if it is good or bad =) +10:23 < pinchartl> uli___: ok. you won't need to get all tests running, an initial subset would be enough +10:23 < uli___> ok +10:23 < jmondi> For me D3 VIN supports seems fine, I'm not sure everythihg we need is upstream (ie D3 i2c). I have to made sure any of the camera modules I have may be connected to D3 expansions +10:23 < jmondi> and, what's DISCOM? :) +10:24 < pinchartl> it's a VSP module that computes CRCs +10:25 < jmondi> target platforms? I have an M3-W and a D# here +10:25 < jmondi> nice D#.. D3 I meant +10:27 < pinchartl> M3-W will work +10:27 < neg> jmondi: V3M also have a parallel input on its expansion board and there i2c works and I have verified the HDMI/CSI-2 input on the expansion board if all else fails +10:28 < jmondi> neg: nice, but I don't have V3M... ofc there's the remote option, but I need to wire a camera to the expansion headers +10:30 < pinchartl> next topic, GMSL code camp +10:30 < pinchartl> by now I assume you all have sorted out your travel plans +10:30 < pinchartl> and know what to bring +10:30 < pinchartl> please make sure you enter your travel plans in the wiki +10:32 < jmondi> FYI: https://osdr.renesas.com/projects/linux-kernel-development/wiki/Periperi-2018-02 +10:32 < pinchartl> I will post an agenda proposal for the Thursday afternoon multimedia meeting +10:32 < pinchartl> regarding the code camp itself I think the agenda is quite simple +10:32 < pinchartl> any question ? +10:33 < kbingham[m]> Neg, can you provide our latest gmsl branch to test? +10:34 < kbingham[m]> That is assuming that your latest patches are the most recent work +10:34 < neg> kbingham[m]: I'm working on bulding it, got gready and wanted the latest VIN patches as it's base. As soon as it's done I will provided a tag +10:35 < kbingham[m]> Great +10:35 < pinchartl> thank you +10:36 < pinchartl> regarding logistics, I will likely arrive in Brussels first +10:38 < neg> I will arrive Sunday BRU 1900 if anyone want to share a cab +10:38 < pinchartl> any other question ? +10:39 < jmondi> and I'll land at 19.35 if I'm not wrong +10:39 < jmondi> no question though +10:39 < kbingham> Best ways of contacting people upon arrival ? +10:39 < kbingham> jmondi - whatsapp, pinchartl sms, neg ? +10:39 < pinchartl> sms or phone for me, yes +10:39 < kbingham> (kb, IRC, whatsapp, or sms) +10:40 < neg> kbingham[m]: phone or sms is best for me +10:41 < jmondi> IRC, telegram or if no alternatives whatsapp +10:42 < pinchartl> any other topic to discuss ? +10:42 < neg> not from me +10:43 < pinchartl> I then propose adjourning this meeting. any objection ? +10:43 * kbingham seconds +10:43 < geertu> jmondi: Please don't use telegrams to contact me. The service was stopped in Belgium on 2017-12-29. +10:43 < pinchartl> meeting adjourned +10:43 < pinchartl> thank you all for attending diff --git a/wiki/Chat_log/20180215-core-chatlog b/wiki/Chat_log/20180215-core-chatlog new file mode 100644 index 0000000..d0b0fcc --- /dev/null +++ b/wiki/Chat_log/20180215-core-chatlog @@ -0,0 +1,129 @@ +Core-chat-meeting-2018-02-15 + +09:32 < geertu> Welcome to today's Core Group chat! +09:32 [Users #periperi] +09:32 [ geertu] [ kbingham ] [ marex-cloud] [ neg ] [ uli___] +09:32 [ horms ] [ kbingham[m]] [ morimoto ] [ pinchartl] [ wsa_ ] +09:32 [ jmondi] [ Marex ] [ mturquette ] [ shimoda ] +09:32 -!- Irssi: #periperi: Total of 14 nicks [0 ops, 0 halfops, 0 voices, 14 normal] +09:32 < geertu> FTR, Magnus is excused +09:32 < geertu> Agenda: +09:32 < geertu> 1. Status Updates +09:32 < geertu> 2. Discussion Topics +09:33 < geertu> Topic 1. Status updates +09:33 < geertu> A) What have we done since last time +09:33 < geertu> Jacopo submitted initial Salvator-x M3-N support. +09:33 < geertu> Marek submitted H2 Stout patches, and implemented RPC QSPI and HF +09:33 < geertu> drivers for U-Boot, incl. a method for easy updating of the bootloader +09:33 < geertu> using single fitImage payload. +09:33 < geertu> Shimoda-san submitted rcar-dmac fixes for max_chunk_size and +09:33 < geertu> rcar_dmac_chan_get_residue() issues. +09:33 < geertu> Simon posted and merged R8A77980 glue, misc cleanups, and tested +09:33 < geertu> CPUFreq/Z,Z2 Clock patches on big.LITTLE H3 and M3-W. +09:33 < geertu> Geert completed the GPIO pass-through prototype, wrote a generic +09:33 < geertu> vfio-platform reset driver, tried Fabrizio's R-Car Gen2 Watchdog Timer +09:33 < geertu> work, and extended it to all R-Car Gen2 SoCs and boards. +09:34 < geertu> EOT +09:34 < geertu> B) What we plan to do till next time +09:34 < geertu> Jacopo will address review comments and finalize M3-N upstreaming. +09:34 < geertu> Marek will submit Stout V2 after addressing feedback, and continue RPC +09:34 < geertu> work, also on D3/V3M. +09:34 < geertu> Shimoda-san will discuss a plan to improve the IPMMU driver with +09:34 < geertu> Magnus-san, and will submit M3-N PFC patches for USB. +09:34 < geertu> Simon will probably do more DT cleanups (soc node and sorting). +09:34 < geertu> Geert will run and improve Linux on M3-N Salvator-XS, and revisit +09:34 < geertu> in-kernel BD9571MWV DDR backup mode. +09:34 < geertu> EOT +09:36 < geertu> C) Problems we have currently +09:36 < geertu> Marek has issues with the slow U-Boot SD/MMC maintainer. +09:36 < geertu> Geert has issues with watchdog reset on early revisions of R-Car H2 and +09:36 < geertu> M2-W, and on V2H. +09:36 < geertu> EOT +09:36 < geertu> Anything missing? +09:37 < Marex> morimoto: thank you for the RPC stuff :-) +09:37 < geertu> About the watchdog issues: +09:37 < geertu> - R-Car H2 < ES2.0 and R-Car M2-W < ES3.0 (or < ES2.0?) need +09:37 < geertu> secondary cores offlined, +09:37 < geertu> - R-Car V2H ES1.1 needs CONFIG_SMP=n. +09:37 < geertu> Renesas UK doesn't care about these early revisions, but we all seem to have boards with such old SoCs. +09:38 < geertu> Hence I think we should blacklist them in the WDT driver using soc_device_match() +09:38 < wsa_> i am a bit confused that Simon took the dts patches already while the issues are still present. Is that intentional? +09:38 < horms> Good that they have newer hw than us! +09:38 < morimoto> Marex: my pleasure +09:38 < geertu> DT is hardware description +09:38 < horms> wsa_: we think the dt changes are clean but the driver side needs work +09:38 < horms> yes, it was intentional +09:38 < wsa_> ok +09:38 < horms> perhaps we will live to regret the decision +09:39 < horms> s/we/I/ +09:39 < Marex> morimoto: it really did help , cfr https://github.com/marex/u-boot-sh/commits/test/rpc , which is mostly done now (still need to fix one more cache issue there) +09:39 < wsa_> just wondering, because if we can't decide on a fix for 4.17, my Lager board could lock up when trying to reboot without PMIC drivers +09:40 < wsa_> but Geert's proposed fix looks fine to me +09:40 < horms> ok, so the current renesas-devel has the problem you describe? +09:40 < wsa_> haven't tried. from my experience, it should have +09:40 < wsa_> but i need to test obviously +09:40 < horms> ok, that is not good +09:40 < morimoto> Marex: looks nice ! Thank you for your help ! +09:40 < geertu> wsa_: And with a blacklist, it would not reboot without PMIC drivers? +09:40 < horms> please test :) +09:40 < wsa_> yes +09:41 < geertu> Given only the DT was accepted, there is no issue. +09:41 < wsa_> that is why I pushed the watchdog driver back then +09:41 < geertu> Watchdog driver has to go in last anyway +09:41 < geertu> v4.17: clocks +09:41 < geertu> v4.18: mach-shmobile reboot vector +09:41 < geertu> v4.19: watchdog driver +09:41 < geertu> v4.17: clocks + DT +09:42 < Marex> morimoto: sure, convenient method of updating u-boot/atf/etc is coming for 2018.05 or 07 (depends on how fast the maintainers react) +09:42 < wsa_> wow, this is a long term plan +09:42 < horms> ok, so its not until the driver goes in that problems can manifest? +09:42 < geertu> So we have plenty of time to perfect the blacklist ;-) +09:42 < geertu> horms: Correct. +09:42 < horms> ok, this is of course fine by me +09:44 < geertu> Topic 2. Discussion Topics +09:45 < geertu> From Shimoda-san: +09:45 < geertu> - H3 ES3.0 SiP will have 8GiB memory. +09:45 < geertu> - Do we need r8a7795-es2-salvator-x[s].dts? +09:45 < geertu> - E3 Ebisu board will have 2GiB memory, but first lot will have 1GiB. +09:45 < geertu> - I'd like to support 2GiB board only in upstream. +09:45 < geertu> EOT +09:45 < geertu> So both are related to memory size +09:45 < geertu> There's no need to describe all memory in DT, if U-Boot provides it. +09:45 < geertu> However, U-Boot now uses DT, so it needs a separate DTS? +09:45 < Marex> geertu: or we can extract how much RAM the board has from ATF somehow ? +09:45 < geertu> Or code to populate the memory node based on ES revision? +09:46 < Marex> geertu: then U-Boot can report it correctly and patch the Linux DT with the correct info +09:46 < geertu> shimoda: Will E3 be a SiP? Or a board with either 1 or 2 GiB populated? +09:46 < Marex> geertu: not ES revisions, that may not work if someone mixes and matches boards and CPUs +09:47 < morimoto> shimoda-san is talking with our boss now +09:47 < geertu> Marex: We already have that issue, as the H3 SiPs on Salvator-X and H3ULCB are different (different memory size + ???) +09:47 < Marex> geertu: isnt there some SMC call which can give you the DRAM configuration ? +09:47 < geertu> Marex: no idea +09:47 < Marex> geertu: that might be the thing to explore +09:47 < Marex> geertu: that way we can be always correct IFF the ATF is correct +09:48 < geertu> Marex: Yes, you want a shared U-Boot binary, while the ATF is still per-SoC +09:48 < Marex> geertu: I want one u-boot to rule them all ! +09:48 < Marex> geertu: one u-boot binary, with different DT attached to it on per-board basis, that'd be AWESOME +09:49 < Marex> geertu: but if we can avoid having per-memory-configuration DT for u-boot, that'd be AWESOME too +09:50 < Marex> geertu: ... before you mention applying DTOs to U-Boot DT, yes, I tried it, no, I don't want to go down that path here ;-) +09:51 < geertu> At one point, I considered SiP DT bindings and .dtsi +09:51 < geertu> "[PATCH 0/8] arm64: dts: renesas: Break out R-Car H3 and M3-W SiP" +09:51 < geertu> https://www.spinics.net/lists/devicetree/msg173820.html +09:51 < shimoda> geertu: sorry for delayed. E3 is not SiP. SDRAM on board +09:51 < geertu> shimoda: Thanks for checking. +09:52 < Marex> geertu: or apply DTOs to Linux DT on U-Boot level now ? :) +09:52 < geertu> shimoda: Will there be other differences in H3 ES3.0 to warrant a new .dts(i) file? +09:53 < shimoda> geertu: i don't know, i will ask some guy +09:55 < geertu> shimoda: OK, we will see +09:57 < shimoda> geertu: hw team is preparing such document. so, after i got it, i will inform you. +09:57 < Marex> morimoto: one thing which would be real cool in the ATF on Salvator-X would be if there was one of those switches on the board to unlock the RPC HF +09:57 -!- horms [~horms@83.137.1.222] has quit [Ping timeout: 260 seconds] +09:58 < Marex> morimoto: this way I won't have to hack the ATF to unlock the access to RPC on H3/M3 +09:58 < Marex> morimoto: it'd also make it convenient for users of the board, just flip a switch, update u-boot from u-boot, reboot, flip the switch back to "locked" +09:58 < geertu> Marex: IIRC, there's an MD switch to boot from external FLASH. Does that also go through the RPC? +09:58 < Marex> morimoto: I think I'll prepare some patches for that, maybe renesas ATF tean can integrate them if they like it +09:59 < geertu> shimoda: Thank you +09:59 < geertu> Any other topics to discuss? +09:59 < Marex> geertu: everything goes through RPC afaik +10:01 < geertu> OK, let's conclude +10:01 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20180215-io-chatlog b/wiki/Chat_log/20180215-io-chatlog new file mode 100644 index 0000000..ab4a855 --- /dev/null +++ b/wiki/Chat_log/20180215-io-chatlog @@ -0,0 +1,93 @@ +09:04 < wsa_> so, let's start the IO meeting +09:05 < wsa_> welcome everyone +09:05 < wsa_> let's start with the summary: +09:05 < wsa_> A) +09:05 < wsa_> Simon posted a new version of the HS400 patches addressing review comments and +09:05 < wsa_> started the virt+network task. Niklas sent out the first patch for variable +09:05 < wsa_> MTU size for RAVB. Shimoda-san got various USB-related bugfixes merged in +09:05 < wsa_> upstream. Ulrich fixed a SCIF lockup and converted the SCIF driver to use HR +09:05 < wsa_> timers. Wolfram reviewed a ton of patches all around, discussed some watchdog +09:05 < wsa_> isses, made preparations for OSS+AGLJ, got the IP core switcher series merged, and +09:05 < wsa_> worked on virt tasks, generic one and I2C specific one. +09:05 < wsa_> B) +09:05 < wsa_> Simon wants to look at the CLK changes needed for HS400 and will continue with +09:05 < wsa_> the virt task. Niklas wants to send out V2 of RAVB-MTU size patch and, if time +09:05 < wsa_> permits, look into his previous SDHI hack. Shimoda-san wants to work on USB3.0 +09:05 < wsa_> role swap, USBPHY GPIO support, M3-N USB enablement and the virt task. Ulricht +09:05 < wsa_> will send out patches to the solutions of the above SCIF tasks. Wolfram will +09:05 < wsa_> finish the IO virt task today and fully move to the virt+I2C task, continue +09:05 < wsa_> reviewing stuff, submit the talk proposal for AGL, keep at the watchdog issues, +09:05 < wsa_> and plans to talk with Kieran about reprogrammed I2C addresses. +09:05 < wsa_> C) +09:05 < wsa_> Geert noticed eMMC problems on resume. Simon needs a SDR104 card in the Porter +09:05 < wsa_> board of Magnus' farm. +09:05 < wsa_> Please check if I misunderstood something. And fire away questions if you have. +09:06 < wsa_> I have one +09:06 < wsa_> geertu: which branch showed the eMMC problem? linus or ren-drivers? +09:06 < geertu> wsa_: That was my dev branch, based on renesas-drivers. +09:07 < geertu> Haven't tried it on anything else. +09:07 < geertu> I recently started using the eMMC for native compilation of QEMU, as it's much faster than nfsroot +09:07 < wsa_> oh, and anothso, with HS400? +09:07 < geertu> Hence I don't know if it happened before. +09:07 < wsa_> with HS400? +09:08 < geertu> I guess you have experience with mounted SD cards and s2idle/s2ram? +09:08 < geertu> No HS400, AFAIK +09:08 < wsa_> Simon once reported suspend&resume problems with SDHI, too +09:08 < wsa_> don't recall the details anymore +09:09 < wsa_> there was never time to look into it :( +09:09 < wsa_> i'll boost priority on this one a bit +09:10 < wsa_> neg: what about the hack to increase the MTU size beyond 2k? Not tried or didn't work? +09:10 < geertu> I can do some more tests, after reporting +09:10 < wsa_> geertu: Thanks, much appreciated! +09:11 < wsa_> geertu: and doing native compiles, you would probably also like the HS400 patches :) +09:11 < horms> wsa_: those s2ram/sdhi problems were a long time ago +09:11 < neg> wsa_: it did not work out as I planed :-( Not sure if it can be done, not given up entierly on it, but won't presue it in the near future. Shimoda-san told me of this HW limitation at the beginning of the task but I tought I could break it :-) +09:11 < horms> I think they have been resolved though I don't recall how +09:12 < horms> On the porter/sdr104 front, there is a card present, but I think its in the wrong slot (not all slots support that speed) +09:13 < wsa_> neg: yeah, that's understandable. Well, maybe somewhen... +09:14 < wsa_> horms: that should be easily fixable ;) +09:14 < horms> yes, its not a large problem +09:14 < horms> nor an urgent one +09:14 < horms> my larger problem is the clk patch for HS400. I think you and I need to talk about that some time. +09:15 < wsa_> yes, we can do that +09:15 < horms> I suspect you have a different eMMC chip on hour H3 ES1.0 board +09:15 < wsa_> somewhen next week +09:15 < horms> sure, lets schedule a time (some time) +09:15 < wsa_> I can't check right now, but I recall something like this, yes +09:15 < horms> ok, i guess you need to go home first +09:15 < horms> let me know when the timing is good for you +09:16 < wsa_> monday should be good +09:16 < geertu> wsa_: How long before the eMMC will wear out? +09:17 < horms> ok, i should be around on monday. but if you want to schedule a time let me know +09:17 < horms> geertu: just before we confirm the bug fix +09:17 < wsa_> horms: let's try the ad-hoc method, I'd say +09:17 < horms> ok, sur +09:18 < horms> in general mornings are better for me, say from 9 to noon +09:18 < wsa_> geertu: so, tried to wear out a 64MB SD card once because I wanted to check if SDHI catches such errors well. +09:18 < horms> but mondays are pretty good in general +09:18 < wsa_> I wrote continously for days while hacking, no luck +09:19 < wsa_> but maybe that card was not MLC +09:20 < wsa_> so, do you guys have questions? +09:20 < wsa_> I am done, I think +09:21 < wsa_> JapaPERI is happy, too? +09:22 < shimoda> yes, but i cannot catch up the emmc issue though :) +09:23 < horms> shimoda: issue is that hs400 is working fine for me. but it involves patches that wsa_ has had trouble with before. next step if for wsa_ to verify the current patchset in his environment, then discuss +09:24 < horms> It seems likely his H3 1.0 and mine have different eMMC chips. but we should test before speculating more +09:25 < shimoda> horms: thanks! and geertu has other issue (doesn't work after resume) +09:27 < kbingham> wsa_: I'm happy to talk I2C addreses whenever you're free +09:27 < shimoda> about H3 1.0, i think it is very bad chip about clock thing +09:27 < kbingham> :) +09:27 < wsa_> kbingham: nice, we will see when. hopefully next week, but no promise yet +09:27 < kbingham> wsa_: Ack :) +09:28 < horms> shimoda: ok. so some boards have a chip that works badly with the clk fix? that would explain things +09:28 < horms> do you know which chip? +09:29 < wsa_> or maybe it is because some clks are running only at 50%? +09:29 < wsa_> we need to check, but keep in mind that ES1.0 is special regarding to clocks +09:30 < geertu> Yes, it has completely different handling for SD clocks, IIRC +09:31 < geertu> You may need to measure the actual clock signals... +09:31 < wsa_> heh +09:31 < horms> I suggest we take this offline and move onto Core +09:31 < wsa_> we will come back to this once I am back home +09:31 < wsa_> agreed +09:32 < wsa_> thanks for the meeting! +09:32 < wsa_> geertu: the stage is yours diff --git a/wiki/Chat_log/20180215-mm-chatlog b/wiki/Chat_log/20180215-mm-chatlog new file mode 100644 index 0000000..630960d --- /dev/null +++ b/wiki/Chat_log/20180215-mm-chatlog @@ -0,0 +1,334 @@ +Multimedia-chat-meeting-2018-02-15 + +10:01 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:01 < pinchartl> * Jacopo +10:01 < pinchartl> Since last meeting: +10:01 < pinchartl> - GMSL code camp in Brussels +10:01 < pinchartl> - Fought with buildroot to compile v4l-utils +10:01 < pinchartl> In order to help Hans testing the v4l2-compliance tool on V4L2 subdevs, a +10:01 < pinchartl> procedure to easily cross-compile the latest v4l-utils is desired. Buildroot +10:01 < pinchartl> can be used for that purpose. +10:01 < pinchartl> Until next meeting: +10:01 < pinchartl> - Nothing planned, but would like to give M3-W + camera board a spin +10:01 < pinchartl> - Help with GMSL upstreaming if required +10:01 < pinchartl> - Help a bit more with reviews +10:01 < pinchartl> Issues and Blockers: None +10:02 < pinchartl> jmondi: any comment ? +10:02 < jmondi> not particularly... +10:02 < pinchartl> a quick question from my side +10:02 < jmondi> shoot +10:02 < pinchartl> last time you mentioned you where planning to handle frame rate setting in the ov7720 driver +10:02 < pinchartl> what's the status ? +10:03 < jmondi> it's there, in CEU v8 patch series +10:03 < jmondi> isn't it? +10:04 < morimoto> Marex: can you give us its patch ? We can try to send it to AFT team. +10:04 < morimoto> s/AFT/ATF/ +10:04 < pinchartl> jmondi: thanks, just wanted to double-check +10:04 < Marex> morimoto: sure, once I have it, I'll get back to you! +10:04 < jmondi> pinchartl: uh, there are comments.. I guess that slipped from my mind because of FOSDEM code camp +10:05 < pinchartl> do you plan to try and address them at some point ? +10:05 < jmondi> pinchartl: ah ok, no comment that require rework... +10:06 < jmondi> pinchartl: yes, I have to if I want that driver in v4.17 +10:06 < jmondi> and yes, there is some rework required :) +10:07 < pinchartl> thank you +10:07 < pinchartl> next, kbingham +10:07 < pinchartl> * Kieran +10:07 < pinchartl> Since last meeting: +10:07 < pinchartl> - GMSL Code Camp +10:07 < pinchartl> This resulted in lots of refactoring on GMSL +10:07 < pinchartl> - H3 ES2.0 LVDS + VGA Performance issue resolved +10:07 < pinchartl> - Draak D3 i2c_new_secondary_device patches ongoing +10:07 < pinchartl> - D3 VSP enablement series +10:07 < pinchartl> Until next meeting: +10:07 < pinchartl> - D3 DU enablement +10:07 < pinchartl> Not an additional task itself, but doing as base work, because it's a pseudo- +10:07 < pinchartl> dependency of the D3 ADV7511/ADV7604 'i2c_new_secondary_device' work. +10:07 < pinchartl> - Wait for next contract, probably one of - Dynamic BRS/BRU allocation in display pipelines - DU interlaced modes support +10:07 < pinchartl> Issues and Blockers: +10:07 < pinchartl> - Need to get a patch tested on a Wheat board +10:07 < pinchartl> This semi-blocks the changes made to the ADV7511 driver. Sergei@Cogent doesn't +10:07 < pinchartl> seem to have access to one. +10:07 < pinchartl> any comment ? +10:08 < kbingham> One comment +10:08 < kbingham> For morimoto-san really - Just to highlight that there is a fix for the LVDS VGA, and I tried to find a mail thread where the issue was reported - but couldn't find one to highlight. +10:09 < morimoto> sorry what does "highlight" mean ? +10:10 < kbingham> morimoto: Make you aware of it :) +10:10 < kbingham> Or perhaps rather the BSP team would be interested in the patch (trying to dig out the title now) +10:11 < kbingham> "[PATCH] v4l: vsp1: Fix header display list status check in continuous mode" +10:11 < kbingham> That's it from me otherwise I think. +10:12 < kbingham> unless someone has a wheat board :) +10:12 * morimoto maybe British English is a Little bit difficult for me... +10:13 < morimoto> kbingham: Thank you for your help. I guess it will be send to Jinso in 2/E ? +10:13 < kbingham> morimoto: Yes, that's right. +10:13 < morimoto> Thanks. BSP team will be happy +10:14 < pinchartl> next, Morimoto-san +10:14 < pinchartl> * Morimoto-san +10:14 < pinchartl> Since last meeting: +10:14 < pinchartl> - ALSA SoC cleanup patches were (finally) applied in maintainer's tree !! +10:14 < pinchartl> - R-Car sound has ADSP which needs FW +10:14 < pinchartl> The BSP team has created a super original framework, driver, interface for +10:14 < pinchartl> userspace, and has released it to customers. We already know what will be +10:14 < pinchartl> happen with these kind of non-standard interface. +10:14 < pinchartl> Started to confirm ADSP releated things to solve this issue. +10:14 < pinchartl> - Shipped M3N board to EuroPeri, but not yet for Ideas on board guys +10:14 < pinchartl> Until next meeting: +10:14 < pinchartl> - ADSP investigation +10:14 < pinchartl> - M3N board shipping for Ideas on Board +10:14 < pinchartl> - Export paper work for V2H and others +10:14 < pinchartl> Issues and Blockers: None +10:14 < pinchartl> any comment ? +10:15 < morimoto> nothing. +10:15 < morimoto> shipping to Ideas is not yet finished +10:15 < morimoto> because of paper work guy +10:16 < morimoto> Ah, one comment. +10:16 < morimoto> I have X) from BSP team +10:17 < pinchartl> yes I've seen that +10:18 < pinchartl> we'll discuss it after the status update +10:18 < pinchartl> next, neg +10:18 < pinchartl> * Niklas +10:18 < pinchartl> Since last meeting: +10:18 < pinchartl> - [PATCH v2] v4l2-dev.h: fix symbol collision in media_entity_to_video_device() +10:18 < pinchartl> - [PATCH v2 0/5] arm64: dts: renesas: r8a77970: enable HDMI output +10:18 < pinchartl> - [PATCH v13 0/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 +10:18 < pinchartl> - [PATCH v10 00/30] rcar-vin: Add Gen3 with media controller +10:18 < pinchartl> - [PATCH] v4l: subdev: compat: update handling for VIDIOC_SUBDEV_[GS]_ROUTING +10:18 < pinchartl> - [PATCH v2] videodev2.h: add helper to validate colorspace +10:18 < pinchartl> - Rebased GMSL branch on renesas-drivers-2018-02-13-v4.16-rc1 +10:18 < pinchartl> The result has been pushed to the common GMSL repo in git@github.com:kbingham/linux.git v4l/next/gmsl/renesas-drivers-2018-02-13-v4.16-rc1 +10:18 < pinchartl> - Got review comments from Laurent on VIN v10 \o/, started to address them. +10:18 < pinchartl> - GMSL code camp + FOSDEM +10:18 < pinchartl> Until next meeting: +10:18 < pinchartl> - Finish VIN v11 and repost +10:18 < pinchartl> - Start pro-active work on removing single capture mode from VIN +10:18 < pinchartl> Issues and Blockers: +10:18 < pinchartl> - Naming schema for GMSL branches not yet set +10:18 < pinchartl> any comment ? +10:19 < neg> None thanks +10:19 < pinchartl> next, uli___ +10:19 < pinchartl> Issues and Blockers: +10:19 < pinchartl> - Naming schema for GMSL branches not yet set +10:19 < pinchartl> * Ulrich +10:19 < pinchartl> Since last meeting: +10:19 < pinchartl> - Multimedia meeting + FOSDEM +10:19 < pinchartl> - Added VIN*, DU pin control tables to R8A779{5,6,95} +10:19 < pinchartl> Until next meeting: +10:19 < pinchartl> Issues and Blockers: None +10:19 < pinchartl> any comment ? +10:20 < uli___> nope +10:20 < jmondi> I would be interested in the definition of topic branches naming scheme as well (not just for multimedia) +10:20 < pinchartl> jmondi: agreed +10:21 < pinchartl> uli___: we haven't had time to look at the SGX issues when we were in Belgium +10:22 < pinchartl> I'm sorry about that +10:22 < pinchartl> do you still plan to work on it ? +10:22 < kbingham> uli___: Oh - have you also posted patches for r8a77995 DU / VIN? +10:23 < uli___> pinchartl: not sure, actually. but i would appreciate it if you could look at the last patch, with the drm interface +10:23 < uli___> kbingham: yes, pin control tables. not actually posted yet, i'll do that today +10:23 < kbingham> uli___: I might have beaten you to it on parts :) +10:23 * kbingham slaps kbingham for duplicating work +10:24 < pinchartl> uli___: what was the subject of the patch? +10:24 < uli___> kbingham: yes, for the du part, it seems +10:25 < kbingham> uli___: Orz ... +10:26 < uli___> pinchartl: drm/img-rogue: replace call to obsolete drm_platform_init() +10:27 < uli___> https://github.com/uli/r8a7796-gpu +10:27 < pinchartl> thank you +10:27 < pinchartl> next, me +10:27 < pinchartl> * Laurent +10:27 < pinchartl> Since last meeting: +10:27 < pinchartl> - GMSL Code Camp +10:27 < pinchartl> - Brussels FOSDEM +10:27 < pinchartl> - Virtualization investigation +10:27 < pinchartl> - DU LVDS support rework (V3M preparation + DRM bridge API) +10:27 < pinchartl> - Patch review +10:27 < pinchartl> Until next meeting: +10:27 < pinchartl> - Get the GMSL patches posted to public mailing lists +10:27 < pinchartl> - Dynamic BRS/BRU allocation in display pipelines +10:27 < pinchartl> - DU interlaced modes support +10:27 < pinchartl> Issues and blockers: None +10:27 < pinchartl> no comment from my side +10:29 < pinchartl> kbingham: I forgot to ask +10:29 < pinchartl> about the Wheat board +10:29 < pinchartl> what's your plan ? +10:29 < pinchartl> if you really can't get access to one I think we can still send the patches upstream +10:30 < kbingham> pinchartl: morimoto-san suggested that Magnus might be able to hook up a wheat board to the board farm. +10:30 < pinchartl> let's see if that can happen during the next two weeks +10:30 < kbingham> If that happens I'll have to build an arm32 kernel and FS and run i2cdectect myself. +10:30 < pinchartl> otherwise, just go forward +10:30 < kbingham> pinchartl: Ack. +10:31 < pinchartl> next topic, additional tasks for Q1/2 +10:32 < pinchartl> the following tasks have been accepted by Renesas +10:32 < pinchartl> - Dynamic BRS/BRU allocation in display pipelines (Kieran, Laurent) +10:32 < pinchartl> - DU interlaced modes support (Kieran, Laurent) +10:32 < pinchartl> - Port and Run igt on the DU (Ulrich) +10:32 < pinchartl> - V3M Eagle display support (Jacopo) +10:32 < pinchartl> this one is still pending approval +10:32 < pinchartl> - VIN Capture mode update (Niklas) +10:33 < pinchartl> Renesas has accepted the task, but it's not clear whether it will be a prototype only or a full upstreaming task, it depends on budget +10:33 < pinchartl> I will send the full task descriptions to Magnus when I'll be done with the Q1/1 report, so likely tomorrow +10:34 < pinchartl> it will take a few days for the SoWs to be sent out +10:34 < pinchartl> but in the meantime I believe it's safe to start working on those tasks +10:34 < pinchartl> that's at least what I plan to do, but I'm not forcing anyone if you prefer waiting for a signed SoW +10:35 < pinchartl> any question ? +10:36 < morimoto> I have one +10:37 < morimoto> Before BSP team asked that they want to use DU / VSPD separately +10:37 < morimoto> Do you have such support plan ? +10:37 < pinchartl> on Gen3 ? +10:37 < morimoto> Yes +10:38 < pinchartl> how do they want to do that ? the DU requires VSPD for proper operation +10:38 < pinchartl> or does it mean they want to use the VSPD standalone when the corresponding DU channel is not needed ? +10:38 < morimoto> "separately" means, DU can be separate. They want to use 1 for Linux 1 for VM +10:38 < morimoto> for example +10:38 < pinchartl> ah ok +10:39 < pinchartl> I thought you meant using the DU and the VSPD separately from each other +10:39 < pinchartl> so they want to make some of the DU pipelines available to guests ? +10:39 < morimoto> Ah, sorry for my English +10:39 < pinchartl> no worries :-) +10:39 < morimoto> Yes +10:39 < morimoto> I think we talked it before ? +10:40 < morimoto> It is still our Todo list (In Renesas) +10:40 < morimoto> BSP team already have local patch, so, not a big deal +10:40 < pinchartl> I've worked on display virtualization in Q1/1, I'll send the report today +10:40 < pinchartl> the approach I've tested was paravirtualization, not pass-through +10:41 < pinchartl> we'll have to decide what is best +10:41 < pinchartl> there are two issues +10:41 < pinchartl> one is that on some SoCs (namely H3 ES2.0) a single VSPD instance handles two DU pipelines +10:41 < pinchartl> so those two pipelines can't be used in separate VMs +10:42 < pinchartl> LVDS for one guest and VGA for another guest won't be possible on H3 ES2.0 with pass-through +10:42 < pinchartl> but LVDS + VGA for one guest and HDMI for another guest should work +10:42 < morimoto> Yeah, some HW issue exist. +10:43 < pinchartl> the second issue is that the DU groups channels by two +10:43 < pinchartl> with shared resources +10:43 < pinchartl> so we can assign a group of two channels to one guest and another group to another guest +10:43 < pinchartl> but not split a group +10:44 < pinchartl> and unfortunately, on H3 ES2.0, the VSPD instance shared by two channels is split between two groups +10:44 < pinchartl> that's why I think a paravirtualized approach might be better +10:44 < pinchartl> but lots of work is still needed to prototype all that and see what we can do +10:44 < pinchartl> it's really long-term work +10:45 < pinchartl> especially if we want to make it upstream +10:45 < pinchartl> given the time we currently allocate to virtualization work, I wouldn't expect any upstream solution before the end of the year +10:46 < morimoto> OK, we knew some HW limitation exist, and we think we need to consider this kind of limition somehow +10:46 < pinchartl> yes +10:46 < morimoto> Actually, HW team didn't care about virtualization when they created chip +10:46 < pinchartl> that's interesting to know +10:47 < pinchartl> and now someone cares about virtualization ? :-) +10:47 < morimoto> That is the reason why it has such design +10:47 < morimoto> SW team start to consider virtualization, HW team didn't care +10:48 < pinchartl> does the software team have use cases that they can share for virtualization ? +10:48 < morimoto> The reason why it has not enough channel/IP/connection is HW team want to reduce cost +10:48 < pinchartl> I hope someone will tell the hardware team it wasn't the best idea +10:48 < morimoto> Just cost issue, no plan for virtualization +10:49 < pinchartl> there are a few things I consider as design mistakes in the DU +10:49 < morimoto> Yes, Now they noticed (I hope) +10:49 < pinchartl> I would really like to see them fixed at some point +10:49 < morimoto> I guess Gen4 timing +10:50 < morimoto> I think Renesas SW team will have discussion time with HW team then +10:50 < pinchartl> could the HW team listen to our feedback ? +10:50 < morimoto> Gen3 was better than Gen2. becaming better, but not yet perfect +10:51 < morimoto> That is the request from Renesas CEO +10:51 < morimoto> But, HW team have their reason. Thus, not 100% +10:52 < pinchartl> I wonder whether it could be useful to meet face to face before OSSJ to discuss Gen4 DU with the hardware team +10:53 < morimoto> Uhm, I don't know we can do it. +10:53 < morimoto> But let's try to ask +10:53 < pinchartl> thank you :-) +10:53 < morimoto> Thank you. it is all from me +10:54 < pinchartl> this leads us to Topic 3. BSP Team Requests that we have already started +10:54 < pinchartl> the other question being the memory leak in libdrm drmClose() +10:55 < pinchartl> I haven't reviewed libdrm from a memory management point of view +10:55 < pinchartl> this is a userspace issue, so I wonder what we're expected to do ? +10:59 < morimoto> I guess BSP team is thinking that you have some "userspace" friend ? +10:59 < morimoto> or report it to userspace ML +10:59 < pinchartl> I'm sure they could reach out to the libdrm developers directly if they wanted :-) +10:59 < morimoto> It sound good +11:02 < pinchartl> next topic +11:02 < pinchartl> Topic 4. FOSDEM Meeting Debriefing +11:02 < pinchartl> what went well, what can we do better ? +11:02 < pinchartl> I'll start +11:02 < pinchartl> I think the code camp was a success +11:03 < pinchartl> we've made good progress on GMSL +11:03 < pinchartl> but 3 days and a half was a bit short to wrap it up +11:03 < kbingham> I was impressed by our multi-developer instant review "Extreme Programming" rework cycle. I think we made massive progress in a short space of time. +11:04 < pinchartl> I agree +11:04 < jmondi> the code camp was a success imo! +11:04 < pinchartl> we should organize more code camps in the future +11:05 < pinchartl> 3 days is a minimum, up to 5 days could be nice +11:05 < jmondi> if we cannot meet per-quarter at conferences, we may want to organize camps like this one, if need be +11:05 < neg> yes, and I reallly think the shared appartment helpd, and the ease to travell to/from the destination +11:06 < jmondi> next time a room where to sleep instead of a corridor would be nice :p +11:06 < kbingham> neg: Perhaps we'll have our own rooms next time though :) +11:07 < neg> kbingham: well it was an improvment in space since the last code camp in .be, but it did not have a pig :-( +11:07 < pinchartl> :-) +11:07 * kbingham suspects neg will wake up with a pig in his bed next code camp ... +11:07 < jmondi> next time a want a corridor, and a pig +11:08 < pinchartl> I think we were also lacking proper planning tools when we discussed planning for Q2. a white board or flip chart would have been useful, but also an established methodology +11:08 * morimoto I can be pig for you :) +11:08 < jmondi> ok, I'll leave the pig to neg... I do not even eat it, it would be a waste +11:08 < jmondi> personally, the planning poker card has been really helpful to reason on task commitment +11:09 < neg> I also liked the early start in the days and that take-out food was had some nights to prolong the hacking sessions +11:11 < neg> Things to improve I think is that ad-hoc decisions taken during the week to prior to the MM meeting where not documented +11:11 -!- pinchartl_ [~unknown@81-175-216-236.bb.dnainternet.fi] has joined #periperi +11:12 < jmondi> neg: didn't get this +11:12 < pinchartl_> my hosted server stopped replying :-/ +11:12 < neg> jmondi: thing I think we should improve or take-out food? +11:12 < pinchartl_> the last thing I saw was +11:12 < pinchartl_> 11:08 < jmondi> personally, the planning poker card has been really helpful to reason on task commitment +11:12 < pinchartl_> what have I missed ? +11:13 < jmondi> pinchartl_: need logs? +11:13 < pinchartl_> please +11:13 < jmondi> pinchartl_: https://paste.debian.net/hidden/0e0035b0/ +11:14 < jmondi> you didn't miss much though +11:14 < pinchartl_> thank you +11:15 < pinchartl_> neg: what did you mean ? +11:15 < pinchartl_> by "Things to improve I think is that ad-hoc decisions taken +11:15 < pinchartl_> during the week to prior to the MM meeting where not documented" +11:16 < neg> For example we talked about the GMSL branch names ad-hoc and that was not documented and now we are confused :-) +11:16 < pinchartl_> (I think my server is being DOSed) +11:16 < pinchartl_> yes, I agree +11:17 < pinchartl_> maybe we should create a wiki page for the next code camp +11:17 < pinchartl_> and take notes whenever needed in a collaborative way +11:17 < pinchartl_> or an etherpad +11:18 < jmondi> neg: other non documented points you are thinking about? +11:18 < jmondi> because I cannot even remember the naming scheme thing :p +11:18 < kbingham> I think that may have just been an informal ish discussion between me and neg :D +11:18 < neg> Also we did not execute the plan to do a team event which was OK but I think it would have been good for the team. *real issue: brought my swimsuite and we did not go diving :-)* +11:19 < pinchartl_> :-) +11:19 < pinchartl_> I agree too +11:19 < pinchartl_> I think we did better than in San Sebastian +11:19 < pinchartl_> but still not good enough +11:19 < pinchartl_> from a social events point of view +11:20 < neg> jmondi: none that come to mind regarding un-documented stuff, but I was not part of all discussions nor do I remember all of them I took part in +11:20 < pinchartl_> several ideas for a social event were discussed before the meeting but we haven't officially agreed on anything, so nothing happened +11:21 < jmondi> we would had been short on time probably for social events... +11:21 < pinchartl_> next time I think we need to decide beforehand on what we want to do +11:21 < pinchartl_> yes, that too, but we will always be short of time anyway :-) +11:21 < neg> Yes, I too think if we are to make an event happen we should pre-allocate time for it +11:22 < jmondi> my understanding is that we're not meeting in Q2/Q3, right? +11:22 < jmondi> at least, not with Renesas sponsorship... +11:22 < pinchartl_> we should definitely meet +11:23 < pinchartl_> I assume there will be a meeting similar to San Sebastian around September +11:23 < pinchartl_> hopefully in Italy :-) +11:23 < pinchartl_> and I think another code camp at some point over the summer would be useful +11:24 < jmondi> pinchartl_: yeah, I meant before september, sorry.. +11:27 < pinchartl_> that's it for me +11:27 < pinchartl_> any other topic to discuss ? +11:27 < jmondi> I would like to ask you guys if I'm the only one that had to spend a day to cross-compile v4l-utils +11:28 < kbingham> jmondi: Normally I can just type 'make v4l2-utils' on my build - but the build does seem to have broken at the moment ... +11:29 < jmondi> it has a -ton- of dependencies, doesn't live well will musl or ulibc.. I remember buildroot shipped versions worked fine, with last version is a bit of pain... is it me? +11:29 < jmondi> kbingham: that's buildroot? +11:29 < neg> jmondi: I build it as a Arch packege on target and then install that in my NFS root for each board, if it helps :-) +11:29 < kbingham> So I'd say this is the life with cross compiling +11:29 < pinchartl_> I cross-compile it outside of buildroot without any issue +11:29 < kbingham> jmondi: (No that's my own custom outside-of-buildroot) +11:29 < kbingham> All it does is git clone the latest v4l2-utils, and attempt to configure and build inside my working environment. +11:30 < jmondi> neg: cross compile as arch package? that's nice +11:31 < jmondi> ok, I assume it is me then, I had to add a ton of packages to buildroot produced compiler sysroot to satisfy dependencies... +11:31 < neg> jmondi: not cross compile, Arch build system don't support that so I have to build the package on target (or in arm/arm64 VM but I don't have that) +11:31 < neg> jmondi: also "sed -i '/#define HAVE_QTGL 1/d' config.h" helps :-) +11:32 < jmondi> neg: oh, you're building on target! that's nasty :) +11:33 * kbingham adds a cross-docker environment which uses qemu-system-arm to provide a 'lightweight ARM64 VM' on host. +11:33 < kbingham> to his wish list +11:33 < jmondi> ok, that's all from me, just wanted to make sure I was not doing something super stupid... +11:34 < kbingham> Ok - back to report writing it is then :) +11:34 < jmondi> (/me wonders how pinchartl_ can build with the single line ./configure string he shared) +11:39 < pinchartl_> are we done for today ? +11:40 < neg> I have nothing more +11:42 < pinchartl_> then we're done +11:42 < pinchartl_> thank you for attending diff --git a/wiki/Chat_log/20180301-core-chatlog b/wiki/Chat_log/20180301-core-chatlog new file mode 100644 index 0000000..b351f51 --- /dev/null +++ b/wiki/Chat_log/20180301-core-chatlog @@ -0,0 +1,110 @@ +Core-chat-meeting-2018-03-01 + +09:49 < geertu> Welcome to today's Core Group Chat! +09:50 < geertu> First I'd like to welcome Vaishali +09:50 < geertu> Agenda: +09:50 < geertu> 1. Status Updates +09:50 < geertu> 2. Discussion Topics +09:50 < geertu> Topic 1. Status updates +09:51 < geertu> A) What have we done since last time: +09:51 < geertu> Jacopo continued upstreaming basic R-Car M3-N support. +09:51 < geertu> Niklas fixed the CLKOUT duplicate pin on R-Car H3 ES2.0. +09:51 < geertu> Shimoda-san discovered a new IPMMU issue on R-Car H3 ES3.0, and submmitted +09:51 < geertu> USB-related PFC patches for R-Car M3-N. +09:51 < geertu> Simon posted R-Car M3-N initial infrastructure patches. +09:51 < geertu> Ulrich up-ported PFC work for R-Car H3/M3-W from the BSP (TMU/HDMI/fixes). +09:51 < geertu> Geert did some R-Car M3-N work (initial Salvator-XS DTS, s2ram), and more +09:51 < geertu> watchdogi investigation (blacklisted early R-Car Gen2 SoCs, Gen2 vs. Gen3 +09:51 < geertu> comparison). +09:51 < geertu> Marek is excused, and enjoying(?) Embedded World +09:52 < geertu> B) What we plan to do till next time: +09:52 < geertu> Shimoda-san will submit PWM PFC and USB DTS patches for R-Car M3-N, and +09:52 < geertu> discuss with Magnus a plan to improve the IPMMU driver. +09:52 < geertu> Simon will probably do more DTS cleanup work (soc node and sorting). +09:52 < geertu> Geert will post V2 of in-kernel BD9571MWV DDR backup mode, and revisit vfio +09:52 < geertu> and qemu patches. +09:52 < geertu> C) Problems we have currently: +09:52 < geertu> Geert wonders if s2ram (PSCI suspend) works on ULCB, and Shimoda-san +09:52 < geertu> confirmed it. +09:53 < geertu> Anything I missed? +09:55 < geertu> Topic 2. Discussion Topics +09:55 < geertu> 1. SW feedback to HW team for R-Car Gen4. +09:55 < geertu> Personally, I have the following: +09:55 < geertu> - Virtualization: +09:55 < geertu> - All device instances should be resettable independently +09:55 < geertu> (e.g. PWM and DU share resets). +09:55 < geertu> - All device instances should be mappable independently +09:55 < geertu> (e.g. GPIO5/6/7 share (4 KiB) pages) +09:56 < geertu> Any other feedback? +09:56 < geertu> (IOMMU? ;-) +09:56 < neg> geertu: I have MM related feedback, do we split this per group or handle the topic for all groups now? +09:57 < geertu> neg: I think it makes sense to do it per-group, that's why I didn't mention your feedback +09:58 < neg> geertu: :-) +10:01 < geertu> OK, core is further perfect ;-) +10:01 < geertu> 2. RZ/N1D upstreaming. +10:01 < jmondi> no feedbacks from me (apart general reamarks on PFC, but I don't think they will listen :) +10:01 < geertu> So Renesas submitted two large patches to add support for RZ/N1D on the RZ/N1D-DB Board +10:02 < geertu> From a quick glance, there are several arres for improvement: +10:02 < geertu> - Too large patches +10:02 < geertu> - Board code +10:02 < geertu> - Macros in DTS +10:03 < geertu> So far I didn't reply in public, as I feel this is more appropriate for the official mach-shmobile maintainers +10:03 < jmondi> can I ask some questions on those patches, for informative purpose? +10:03 < geertu> jmondi: Sure +10:03 < jmondi> why they had to use board code? I see r7s72100 does the same... +10:04 < jmondi> I guess it's beacuse RZ is njot integrated in cpg-mssr, right? +10:04 < jmondi> and even in that case, why do not use something like drivers/clk/rz/ and drivers/soc/rz/ ... +10:06 < geertu> Probably we can get rid of arch/arm/mach-shmobile/setup-r7s72100.c +10:06 < geertu> It predates true DT support +10:06 < geertu> I guess they just took the quick and dirty approach +10:07 < geertu> horms: dammsan: Any comments from the mach-shmobile maintainers? +10:08 < horms> Well, my assumption is that the upstream policy is no more board files +10:08 < horms> So from my point of view the question is: how can support be added for RZ/N1D without a board file +10:09 < horms> There is also a similar, but arguably smaller, issue of a defconfig for the platform +10:09 < geertu> The board file contains sysctrl initialization (should be syscon node in DT instead), and a restart handler (should be a drivers/power/reset/ driver) +10:10 * jmondi thorws himself into the fire: I would like to remove board code from RZ/A... do you think there is any value there and it can be reused for RZ/N? +10:10 < dammsan> i agree =) +10:10 < geertu> There's not much R-{Car,Mobile} DNA shared +10:11 < geertu> jmondi: I encourage that task. But the board code for RZ/N1D is completely different from the one for RZ/A1. +10:12 < jmondi> I admit I haven't looked into RZ/N1D HW at all yet +10:14 < geertu> Looks like the DTB isn't even built... +10:14 < horms> Ok, so I think we should push back +10:14 < horms> I can do so. But I'm happy for someone else to do so. +10:14 < geertu> horms: Will you reply? +10:14 < geertu> IC +10:14 < horms> But we can't try to push a board file unless we have no other practical option +10:14 < geertu> I can reply with some technical feedback +10:14 < horms> Sure, will do +10:15 < dammsan> thanks guys +10:15 < horms> Thanks for bringing this up, I was also not sure how to proceed +10:15 < shimoda> about RZ/N, we don't need any document for now? +10:16 < geertu> shimoda: You are trying to get documentation, IIRC? (some RZ/N1D docs are public) +10:16 -!- wsa_ [~wsa@p54B339A5.dip0.t-ipconnect.de] has quit [Quit: ...] +10:16 < shimoda> geertu: yes, I'm asking now. +10:17 < geertu> I downloaded 4 PDF datasheets +10:17 < geertu> User’s Manual: System Introduction, Multiplexing, +10:17 < geertu> Electrical and Mechanical Information +10:17 < geertu> User’s Manual: Peripherals +10:17 < geertu> User’s Manual: System Control and Peripheral +10:18 < geertu> User’s Manual: R-IN Engine and Ethernet +10:18 < geertu> Peripherals +10:18 < geertu> No idea if this is complete +10:18 < geertu> But it's a start +10:20 < geertu> shimoda: Thanks! +10:20 < geertu> Any other discussion topics? +10:21 < neg> Not from me +10:21 < jmondi> geertu: no but yesterday you asked me if I have an ecovec +10:21 < shimoda> i have a minor topic +10:21 < jmondi> yes, Hans sent me one, but without camera modules :( +10:21 < jmondi> and I have an ULCB if you need testing for s2ram +10:21 < jmondi> shimoda: sorry shimoda-san, go on please +10:22 < geertu> jmondi: OK, so Hans no longer wants to be ecovec maintainer ;-) +10:22 < shimoda> about CMA_SIZE, it's default size is 16MiB. In general, if we want to change the size, we should use bootargs cma= or change the kernel config? +10:22 < shimoda> in renesas_defconfig, it has =128 +10:22 < shimoda> but, defconfig doesn't have the config, so it's default 16MiB. +10:24 < geertu> shimoda: You mean arm64_defconfig doesn't have it? +10:24 < kbingham> shimoda: bootargs will take precedence, so you can set a value you want there easily +10:26 < shimoda> geertu: yes. and thank you for your comment. i got it! +10:26 < shimoda> kbingham: thanks for your comment! +10:27 < geertu> I think we're finished? +10:28 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20180301-io-chatlog b/wiki/Chat_log/20180301-io-chatlog new file mode 100644 index 0000000..40d9f69 --- /dev/null +++ b/wiki/Chat_log/20180301-io-chatlog @@ -0,0 +1,144 @@ +09:03 < wsa_> so, simon is excused i think we can start the meeting +09:03 < pinchartl> hi Vaishali +09:04 < vthakkar> Hi Laurent +09:04 < morimoto> Japan becaming hot :) +09:04 < wsa_> and Vaishali also rejoined successfully, welcome! +09:04 < vthakkar> Yes, my network went off for a minute. Thanks +09:06 < wsa_> so, I'd like to start with the status updates, then officially welcome Vaishali (maybe with some words from her about her), and then have a few open questions, mostly about SDHI +09:06 < wsa_> let's see how much we can talk about with Simon not being here +09:07 < wsa_> Any complaints about that? +09:07 < vthakkar> sounds good. +09:07 < wsa_> nice :) +09:08 < wsa_> so, here are the collected and slightly reworded status updates +09:08 < wsa_> A) +09:08 < wsa_> Simon took part in the HS400 patch discussion and did performance testing of +09:08 < wsa_> host/guest networking with x86 QEMU. Kaneko-san prototyped support for D3 +09:08 < wsa_> thermal. Geert fixed alias usage for serial drivers and enabled IIC on M3N. +09:08 < wsa_> Niklas got his resizable MTU patch merged (what about David's remark?). +09:08 < wsa_> Shimoda-san added USB support for M3N. Wolfram finished his generic +09:08 < wsa_> virtualization task and is now evaluating I2C passthrough, reviewed HS400 +09:08 < wsa_> patches and assorted SDHI clock dividing, and worked on watchdog requests. +09:08 < wsa_> Uli got his SCIF patches merged. +09:08 < wsa_> B) +09:08 < wsa_> Simon wants to test HS400 on M3M and continue with his QEMU task. Kaneko-san +09:08 < wsa_> wants to send out support for D3 thermal. Geert wants to remove hard dependency +09:08 < wsa_> of serial aliases (needed for I2C as well?). If time allows, Niklas wants to +09:08 < wsa_> recheck the SDHI issue workaround patch he once created. Shimoda-san has +09:08 < wsa_> multiple USB issues to work on (role swap for SS, GPIO support for USB PHY, +09:08 < wsa_> resume issue) and also learns about USB virtualization. Wolfram wants to finish +09:08 < wsa_> his virtualization task, give HW team feedback about I2C IP core, pick up more +09:08 < wsa_> SDHI work, write a talk proposal for AGL, and still wants to talk with Kieran +09:08 < wsa_> about I2C addresses. +09:08 < wsa_> C) +09:08 < wsa_> Simon checked that SDR104 on Porter still fails (test Niklas patch maybe?). +09:08 < wsa_> Wolfram so far depends on gmane NNTP for reporting, but it has become +09:08 < wsa_> unreliable in the last days. +09:08 < wsa_> so, one question to neg +09:08 < wsa_> neg: can something be done about David's comment about the MTU patch? +09:09 < wsa_> he said most users would want to have interfaces enabled when they resize MTU? +09:09 < wsa_> and a question to geertu +09:10 < neg> wsa_: I'm sure it can be done, but if we choose to do so I also think we should apply a simlar work to sh_eth +09:10 < wsa_> geertu: I don't think we need to remove hard dependencies on I2C busses, because they match the schematics. Am I correct? +09:10 < wsa_> neg: for sure. I just wondered if it can be done at all and if it was feasible to do so +09:11 < geertu> wsa_: The issue is not related to matching buses with schematics. +09:11 < wsa_> neg: I don't know the HW in enough detail to unterstand if it can be done at all with reasonable effort +09:11 < geertu> The sh-sci driver has a hard dependency on th presence of the serialN aliases. Without them, the driver won't probe. +09:12 < wsa_> geertu: Ah! +09:12 < geertu> This is mostly a relic from the serial core working with a fixed array of ports. +09:12 < neg> wsa_: Sure it's feasible but I think it will take some work as we would have to resize the rings while the nic is up. I have no plan to address this at this time, but if you think it's a good idea I can look at it as part of base +09:12 < geertu> It makes DT overlays more difficult (need to update /aliases) +09:12 < wsa_> geertu: i see. that definately should be removed. +09:12 < neg> wsa_: I think in it self it would be a usefull change for both our network drivers +09:13 < geertu> Note that on SPI the aliases are already optional, as the SPI subsystem handles dynamic bus numbers. +09:13 < geertu> I think I2C is similar to SPI w.r.t. this +09:13 < wsa_> geertu: yes +09:14 < wsa_> neg: well, if David says "most users would want this" and you also say it would be useful, I think we should target that +09:14 < geertu> wsa_: (checked) yes, see i2c_add_adapter() +09:14 < geertu> I think I can do something similar in sh-sci. I won't touch core serial, though ;-) +09:15 < wsa_> geertu: dragons live there +09:15 < wsa_> neg: I will add a todo item for it +09:15 < wsa_> neg: and you want to do it as part of a base task? +09:16 < neg> wsa_: I would be fine to do that in base but are open to other arangements +09:17 < wsa_> okay +09:17 < wsa_> we will see about that when the next round of add. tasks is due +09:18 < wsa_> if you happen to have free base time (yeah, right) until then, please have a go +09:18 < wsa_> so, simon is not here, we will handle my remark then by mail +09:19 < wsa_> status updates done, if there are no remarks from your side? +09:19 < wsa_> Then +09:20 < wsa_> Vaishali, nice to have you here. Really looking forward to working with you. Do you want to introduce yourself to the group? +09:21 < vthakkar> Wolfram, Sure. thanks. +09:22 < vthakkar> Hi, everyone. I'm Vaishali Thakkar and I started my journey with Linux Kernel via Outreachy. And later worked on security and mm related stuff at Oracle. +09:22 < kbingham> Hello Vaishali :-) (I'm somewhat amused by the coincidence of finding you on twitter as kernel_girl - then the next day being told you were joining the team!) +09:23 < vthakkar> kbingham: Ah, I assumed that you knew that before following me. :) +09:23 < vthakkar> Nice to meet you here. +09:24 < jmondi> vthakkar: Nice to meet you (we have been introduced in Prague if I'm not wrong). Welcome! +09:24 < jmondi> (and good morning to everyone else) +09:25 < vthakkar> jmondi: Yes, you're right. Nice to meet you too. +09:25 < kbingham> vthakkar: Nope :-) - You came up in some post from either google+ or twitter +09:25 < vthakkar> kbingham: Cool. :) +09:25 < kbingham> vthakkar: Sounds like I missed you in Prague - (I couldn't attend as we were having our first baby here) +09:26 < pinchartl> kbingham: that's just an excuse. lots of people have babies in Prague :-) +09:26 < wsa_> vthakkar: out of interest, did you do some device driver work so far? +09:26 < kbingham> pinchartl: I'm not sure Keri would agree :) +09:27 < vthakkar> wsa_: I've experience working on microcontrollers [Arduino, Tessel etc] for small projects but not for kernel drivers. +09:27 < wsa_> vthakkar: nice! well, that connection can be easily made ;) +09:28 < vthakkar> And this is exactly why I wanted join because so far I had worked on mm and security related stuff only. :) +09:28 < vthakkar> specifically in mainline. +09:28 < vthakkar> wsa_: Sure +09:29 < geertu> vthakkar: We met in Prague, but I believe you were at ELCE in Dublin, too, right? +09:29 < wsa_> I think you found a good spot to do this :) Again, welcome to our team! +09:29 < neg> vthakkar: welcome +09:29 < vthakkar> geertu: I wasn't in Dublin. My visa was rejected ;) Julia presented my work. +09:30 < vthakkar> neg: thanks +09:30 < vthakkar> geertu: But yes, we met in Prague. +09:30 < vthakkar> wsa_: Thanks :) +09:30 < uli___> vthakkar: hi and welcome! may i ask how you got roped into this job specifically? +09:31 < geertu> vthakkar: Oops. But I did attend Julia's session, so that must be how I remembered. +09:32 < wsa_> okay, so for the remaining issues +09:32 < vthakkar> uli__: Magnus contacted me when Julia presented my work at Dublin one. Then for some reason, I had to take up a job at Oracle and then I met Magnus at 2-3 other conferences in last 2 years and we talked about the work your groups are doing. +09:33 < wsa_> morimoto: shimoda: what is your take on maybe not enabling eMMC HS400 mode on H3 ES1.0? +09:33 < wsa_> as far as I can see, we have no "recommended HW setting" for CPG for ES1.0 +09:34 < wsa_> and the one I tried on my own didn't work for writing data +09:34 < shimoda> wsa_: I don't remember about eMMC HS400 mode on H3 ES1.0 +09:34 < wsa_> or we could ask the HW guys if there is some recommended HW setting for ES1.0 maybe? +09:34 < shimoda> but, H3 ES1.0 is not good, especially clock thing +09:36 < shimoda> wsa_: hmm, I guess hw guys said you should not use ES1.0, but I'll ask anyway :) +09:36 < wsa_> shimoda: thank you. I agree that makes most sense, if they say "don't do it", then we won't do it +09:37 < wsa_> it = HS400 +09:37 < shimoda> wsa_: i got it +09:37 < wsa_> dammsan: are you here? +09:37 < wsa_> Marex: and you? +09:38 < dammsan> yep im here +09:38 < geertu> wsa_: Marex is excused (@EmbeddedWorld) +09:39 < wsa_> I see +09:39 < wsa_> dammsan: did you read the mail from Shimoda-san about listing the revisions in the SDHI driver? +09:41 < dammsan> yeah, I discussed this with him in the office today, and i only care about disabling disallowed combos from use, ie early ES versions. +09:41 < dammsan> one way to solve this could be a black list of those ES versions +09:41 < dammsan> but i have no strong feeling really +09:42 < wsa_> like blacklisting HS400 on ES1.0? ;) +09:42 < wsa_> I see +09:42 < wsa_> thanks for the heads up! +09:43 < dammsan> s/on ES1.0//g =) +09:43 < dammsan> thanks +09:43 < wsa_> okay, this was it from my side +09:43 < kbingham> wsa_: What topics would you like to discuss regarding I2C addresses, and when would you like to do so - I'm assuming it's related to us talking when we were in Brussels - but my memory has now faded. We do have an issue in core where we might need to be able to mark an address as 'unusable' without actually using it ourselves... (unless we use it in which case it's - "in use" ...) +09:44 < wsa_> kbingham: I wanted to talk about how to encode "reprogammable addresses" +09:44 -!- horms [~horms@penelope-musen.horms.nl] has joined #periperi +09:44 < wsa_> and how to handle them (including power-on default addresses) +09:44 < kbingham> Ah yes - handle it better at the core +09:44 < wsa_> That seemed to me like the first step +09:45 < kbingham> We do have a lot of reprogrammable addresses now. +09:45 < kbingham> Ok - now I understand the context - we can schedule outside of this meeting :) +09:45 < wsa_> all the other stuff we talked in Brussels seem to either depend on it or at least would be considerable easier when we have that +09:46 < wsa_> we should have a seperate meeting/thread about that +09:46 < wsa_> can't really predict when, though :( +09:46 < kbingham> wsa_: Ok - understood :) +09:46 < wsa_> hi simon +09:46 < pinchartl> I'd like to participate to that discussion too +09:47 < wsa_> pinchartl: sure, you are welcome +09:47 < horms> hi, sorry I am late +09:47 < wsa_> hope you enjoyed the performance at the school :) +09:47 < horms> I did, thanks +09:47 < wsa_> okay, any more issues? +09:49 < wsa_> okay, then I'll hand over to Geert (sorry for the delay!) +09:49 < geertu> np diff --git a/wiki/Chat_log/20180301-mm-chatlog b/wiki/Chat_log/20180301-mm-chatlog new file mode 100644 index 0000000..0c8afdb --- /dev/null +++ b/wiki/Chat_log/20180301-mm-chatlog @@ -0,0 +1,326 @@ +Multimedia-chat-meeting-2018-03-01 + +10:27 < pinchartl> let's start the multimedia part +10:27 < pinchartl> quick attendees check +10:27 < pinchartl> jmondi: checked +10:27 < pinchartl> kbingham: checked +10:27 < pinchartl> dammsan: checked +10:27 < pinchartl> morimoto: checked +10:27 < kbingham> mic check 1 2, check 1 2 +10:27 < pinchartl> uli___: checked +10:27 < pinchartl> pinchartl: checked +10:27 < pinchartl> so we have a full house today +10:27 < pinchartl> let's start with status updates +10:27 < neg> :-( +10:28 < neg> I'm also here :-) +10:28 < pinchartl> neg: ah yes I forgot to mention, usually I forget Jacopo, I thought I'd forget you this time +10:28 < pinchartl> so that you don't feel left out :-) +10:28 < jmondi> pinchartl: thank you! +10:28 < pinchartl> speaking of Jacopo +10:28 < jmondi> I'll sign your name in my black book now +10:29 < pinchartl> I'll go for alphabetical order this time +10:29 < pinchartl> * Jacopo +10:29 < pinchartl> Since last meeting: +10:29 < pinchartl> - CEU v9/v10/v11: CEU series picked up for v4.17 +10:29 < pinchartl> - [PATCH 00/13] media: ov772x/tw9910 cleanup +10:29 < pinchartl> - Briefly tested Kieran D3 DU support +10:29 < pinchartl> - Started looking into removing sh_mobile_camera from other SH boards +10:29 < pinchartl> Until next meeting: +10:29 < pinchartl> - Keep removing soc_camera from SH boards +10:29 < pinchartl> - V3M display support +10:29 < pinchartl> Issues and Blockers: None +10:29 < pinchartl> any comment ? +10:29 < jmondi> not much... +10:29 < jmondi> horms: CEU series has been picked up by Mauro +10:29 < jmondi> so you can pick up the DTS changes now +10:29 < jmondi> that's it +10:30 < pinchartl> thank you +10:30 < pinchartl> * Kieran +10:30 < pinchartl> Since last meeting: +10:30 < pinchartl> - ADV748x support for i2c_new_secondary_device +10:30 < pinchartl> Posted along with CBUS/regmap improvements v2 +10:30 < pinchartl> - D3 Enable DU patches sent +10:30 < pinchartl> - vsp1/tlb-optimise/v6 - rebased to linux-media/master +10:30 < pinchartl> Until next meeting: +10:30 < pinchartl> - Work towards getting vsp1/tlb-optimise upstream. +10:30 < pinchartl> - Working on DU/VSPD Interlaced support +10:30 < pinchartl> Issues and Blockers: +10:30 < pinchartl> - Need to get a patch tested on a Wheat board +10:30 < pinchartl> This semi-blocks the changes made to the ADV7511 driver. Sergei@Cogent doesn't +10:30 < pinchartl> seem to have access to one. +10:30 < pinchartl> The patches have been left untested for a long time now, and the situation +10:30 < pinchartl> isn't likely to change. Should the [RFT] tag be removed and the patches +10:30 < pinchartl> reposted ? (Or just ask Simon to merge ?) +10:30 < pinchartl> kbingham: any comment ? +10:30 < pinchartl> regarding the wheat board, I think we can get the patches merged +10:31 < pinchartl> horms: do you want them to be reposted ? (kbingham: I assume they would be reposted unchanged ?) +10:31 < kbingham> I didn't put DU interlaced in the 'since last meeting' but that has been my main task this week - so it has commenced. +10:31 < pinchartl> ok, I'll add that +10:31 < kbingham> pinchartl: And yes- I have no changes to make except for removing the [RFT] tag +10:32 < horms> pinchartl: if you let me know which patches i.e. here, then I can see if they still apply +10:32 < kbingham> (whcih I think would get stripped when applying anyway) +10:32 < pinchartl> horms: thank you +10:32 < pinchartl> kbingham: I'll let you handle that then +10:32 < kbingham> ack. +10:32 < horms> thanks, email is also fine +10:33 < pinchartl> * Laurent +10:33 < pinchartl> Since last meeting: +10:33 < pinchartl> - New versions of DU LVDS rework (hopefully nearing completion) +10:33 < pinchartl> - Dynamic BRS/BRU allocation in display pipelines +10:33 < pinchartl> Until next meeting: +10:33 < pinchartl> - Get the GMSL patches posted to public mailing lists +10:33 < pinchartl> - Skiing holidays (2018-03-10 to 2018-03-17) +10:33 < pinchartl> Issues and blockers: None +10:33 < pinchartl> and also, until next meeting, getting the DU LVDS rework merged +10:33 < pinchartl> any comment from anyone ? +10:33 < pinchartl> kbingham: should I also add a week of holidays for you ? +10:34 < kbingham> pinchartl: Ah yes- as of last night yes please :) +10:34 < morimoto> Skiing holidays in ELC timing :) +10:34 < kbingham> Although I will take my laptop ... :D +10:34 < neg> If I post VIN v11 today will you have time to look at the ~7 still not yet acked patches? :-) +10:34 < pinchartl> neg: I think so +10:34 < pinchartl> morimoto: what do you think is best, skiing or ELC ? :-) +10:35 < morimoto> Of course Skiing :) +10:35 < kbingham> ahem - - snowboarding! +10:35 < pinchartl> I wasn't very motivated by going to Po(rt)land in March +10:35 < morimoto> Hehe :) +10:35 < pinchartl> * Magnus: +10:35 < pinchartl> Since last meeting: Nothing +10:35 < pinchartl> Until next meeting: Nothing +10:35 < pinchartl> Issues and blockers: None +10:35 < pinchartl> dammsan: any comment ? :-) +10:35 < morimoto> Hehe :) +10:36 < morimoto> Very nice guy :) +10:36 < morimoto> He is now enjoying small business +10:36 < pinchartl> I'll let him answer later +10:36 < morimoto> Now, he backed +10:36 < pinchartl> * Morimoto-san +10:36 < pinchartl> Since last meeting: +10:36 < pinchartl> - Happy Paper Work +10:36 < pinchartl> - Renesas inside work +10:36 < pinchartl> - Answered some question for new ALSA SoC framwork +10:36 < pinchartl> Until next meeting: +10:36 < pinchartl> - Continue paper work +10:36 < pinchartl> - Continue Renesas inside work +10:36 < pinchartl> Issues and Blockers: None +10:36 < pinchartl> morimoto: any comment ? +10:37 < morimoto> no comment +10:37 < pinchartl> (I've noted the BSP team questions, we'll get to them later in the meeting) +10:37 < dammsan> i would like mr morimoto to comment on my small business +10:37 < dammsan> morimoto: any comment ? +10:38 < morimoto> You can tell me very detail :) +10:38 < morimoto> Ahh, OK, OK, no more. +10:38 < pinchartl> * Niklas +10:38 < pinchartl> Since last meeting: +10:38 < pinchartl> - [PATCH] i2c: adv748x: afe: fix sparse warning +10:38 < pinchartl> - Addressed all VIN v10 review comments. +10:38 < pinchartl> - Patch review +10:38 < pinchartl> - Mini vacation +10:38 < pinchartl> Until next meeting: +10:38 < pinchartl> - Run more tests on VIN v11 and post it. +10:38 < pinchartl> - Start pro-active work on removing single capture mode from VIN +10:38 < pinchartl> - Attend ELC +10:38 < pinchartl> Issues and blockers: None +10:38 < pinchartl> neg: any comment ? +10:39 < neg> No additonal comment +10:39 < pinchartl> thank you +10:39 < pinchartl> * Ulrich +10:39 < pinchartl> Since last meeting: +10:39 < pinchartl> - Set up the IGT test environment +10:39 < pinchartl> Until next meeting: +10:39 < pinchartl> - See how well those IGT tests perform for us +10:39 < pinchartl> Issues and Blockers: None +10:39 < pinchartl> uli___: any comment ? +10:39 < uli___> haven't received anything from jinso yet for that igt task +10:39 < pinchartl> nobody has +10:39 < pinchartl> and that's the next topic for this meeting :-) +10:40 < pinchartl> but before that, any additional comment from anyone ? +10:41 < pinchartl> no comment, so +10:41 < pinchartl> Topic 2. Additional Tasks for 2018 Q1/2 +10:41 < pinchartl> The following tasks have been accepted by Renesas. +10:41 < pinchartl> - Dynamic BRS/BRU allocation in display pipelines (Kieran, Laurent) +10:41 < pinchartl> - DU interlaced modes support (Kieran, Laurent) +10:41 < pinchartl> - Port and Run igt on the DU (Ulrich) +10:41 < pinchartl> - V3M Eagle display support (Jacopo) +10:41 < pinchartl> - VIN Capture mode update (Niklas) +10:41 < pinchartl> Full descriptions have been sent, we are now waiting for SoWs. +10:41 < pinchartl> dammsan: the ball is in your camp. can you give us a status update ? +10:41 < kbingham> pinchartl: I presume the date for the task prerequisites will be 'in the past' by the time we get contracts? +10:41 < dammsan> i have reviewed the tasks with Renesas side earlier today and am currently submitting tasks +10:42 < pinchartl> kbingham: last time Jinso updated that date +10:42 < dammsan> i took the liberty to get rid of the early test enviroment deliverable milestone +10:42 < pinchartl> thank you :-) +10:42 < pinchartl> dammsan: so no blocker, and we should receive the SoWs soon ? +10:42 < dammsan> i also added acceptance clause as usual +10:42 < dammsan> yep +10:43 < dammsan> jinso will most likely start sending out sows tomorrow +10:44 < pinchartl> thank you +10:45 < pinchartl> any question from anyone regarding the additional tasks ? +10:46 < pinchartl> no question, so +10:46 < pinchartl> Topic 3. BSP Team Requests +10:46 < pinchartl> - VIN driver doesn't seem to have 32bit compatibility +10:46 < pinchartl> There is no .compat_ioctl32 operation defined in the driver. +10:46 < pinchartl> as far as I know, 32-bit compatibility requires drivers to implement a .compat_ioctl32 handler only if they have custom ioctls +10:47 < pinchartl> standard ioctls are handled in the V4L2 core +10:47 < pinchartl> the VIN driver doesn't have any custom ioctl, so I think no action is needed +10:47 < pinchartl> neg: can you confirm that ? +10:47 < pinchartl> morimoto: did the BSP team run into a specific issue, or did they notice it through code analysis only ? +10:48 < neg> pinchartl: I will rerun my test but I'm sure I in the past have tested VIN on ARM64 with a 32 bit user-space without issues +10:48 < morimoto> I'm sorry that I posted it without checking (because I was busy this morning) +10:48 < pinchartl> morimoto: no worries +10:49 < morimoto> But it seems there is no issue on BSP side, this is *just* question +10:49 < pinchartl> ok +10:49 < pinchartl> then we have an answer :-) +10:49 < pinchartl> - vsp-test has many fail on H3 ES1.1 board +10:49 < pinchartl> The following tests failed: +10:49 < pinchartl> - UDS scaling (vsp-unit-test-0003.sh) - CLU/LUT (vsp-unit-test-0010.sh) - Runtime H/V flip (vsp-unit-test-0012.sh) - SRU scaling (vsp-unit-test-0015.sh) - HGT (vsp-unit-test-0023.sh) +10:49 < neg> pinchartl: Only difference is that v4l2-compliance prints an extra log line in console due to how the v4l2 compat layer is implemented, but that might be fixed lately :-) +10:50 < pinchartl> I've checked the logs briefly +10:51 < pinchartl> tests 3 and 15 fail due to a raw2rgbpnm conversion failure in YUV444M +10:51 < pinchartl> tests 10 and 12 fail due to a problem setting controls with yavta +10:51 < pinchartl> test 23 fail for an unknown reason +10:51 < kbingham> pinchartl: I have created a vsp-tests-0000 which reports the test running conditions - might be worth getting that in so that we know what conditions the tests get launched in. +10:52 < kbingham> (which binaries are available etc) +10:52 < pinchartl> at this time I would guess this is all caused by a combination of an incorrect yavta version, possibly an old raw2rgbpnm version, and possibly a wrong shell (the tests have been developed for the busybox ash shell) +10:52 < kbingham> a 'pre-test' test +10:53 < pinchartl> that can be useful too +10:53 < pinchartl> I'll investigate a bit more +10:53 < morimoto> (I thought this is not related to well-known CMA size issue) +10:53 < pinchartl> no it's not +10:53 < kbingham> aha - another pre-test condition to add to my test-0 :D +10:54 < pinchartl> next question +10:54 < pinchartl> - VIN continuous capture mode +10:54 < pinchartl> In the e-mail exchange +10:54 < pinchartl> Subject: [periperi] Question about v4.14 VIN driver transfer mode +10:54 < pinchartl> Date: Fri, 19 Jan 2018 06:22:20 +0000 +10:54 < pinchartl> Niklas said +10:54 < pinchartl> "Yes I will do my best to have this done by end of February. I don't see any +10:54 < pinchartl> blockers to have a patch to fix this by then." +10:54 < pinchartl> the work has since then been turned into an additional task that is scheduled +10:54 < pinchartl> for 3/M +10:55 < pinchartl> neg: is that correct ? +10:55 < pinchartl> morimoto: is that OK ? +10:56 < morimoto> OK, thanks +10:56 < neg> pinchartl: yes that was my understanding of the situation, sorry if I missunderstood +10:57 < pinchartl> neg: maybe we should have replied to the e-mail thread with the updated schedule +10:57 < pinchartl> but on the other hand I expect information about additional tasks and their schedule to be available within Renesas +10:58 < pinchartl> maybe that's an incorrect assumption +10:58 < neg> pinchartl: yes I agree, my bad the more information that is shared the better and I can contribute to that by replying to emails that is a good thing :-) +10:59 < pinchartl> neg: no worries +10:59 < pinchartl> morimoto: any other question from the BSP team ? +10:59 < morimoto> 1 small qestion +11:00 < morimoto> They want to use 4K with HDMI on Salvator-X(S) +11:00 < morimoto> But it doesn't work +11:00 < morimoto> do you have some plan for it ? +11:00 < pinchartl> not at the moment. we can schedule work for that for next quarter +11:00 < pinchartl> what is the issue, is there more information ? +11:00 < morimoto> Is it big work ? or easy work ? +11:01 * kbingham suspects his 4k TV is going to get moved.... +11:01 < kbingham> (or the -XS could move to the living room) +11:01 < pinchartl> morimoto: no idea, we need to research it first +11:01 < morimoto> OK +11:01 < morimoto> the background is +11:01 < morimoto> BSP + StarterKid works for 4K, they said, but upstream isn't +11:02 < morimoto> I know BSP have some local patch +11:02 < morimoto> so this is just question +11:03 < pinchartl> we can research that and fix it +11:03 < morimoto> Thank you ! +11:03 < morimoto> not hi priority, no stress +11:04 < pinchartl> what is starterkid ? +11:04 < pinchartl> starter kit ? :-) +11:04 < kbingham> pinchartl: Hugo :) +11:04 < morimoto> oops, yes kit, it is ULCB +11:04 < morimoto> Kid is me +11:05 < kbingham> morimoto: Young at heart eh :D +11:05 < pinchartl> :-) +11:05 < morimoto> :) +11:05 < pinchartl> next topic is SW Feedback to HW team for R-Car Gen4 +11:05 < pinchartl> but before that +11:05 < pinchartl> while everybody is still here +11:05 < pinchartl> let's schedule the next meeting +11:05 < pinchartl> as I mentioned earlier I'll be on holidays two weeks from now +11:05 < pinchartl> so I won't be able to attend the meeting +11:05 < pinchartl> and neither will Kieran +11:06 < pinchartl> I don't mind though, someone else can host it +11:06 < pinchartl> would that be ok ? +11:06 < kbingham> pinchartl: Nor neg - He'll be in ELC +11:06 < pinchartl> indeed +11:06 < pinchartl> and so will Magnus and Morimoto-san if I'm not mistaken ? +11:06 < neg> kbingham: you type faster then me :-) +11:06 < kbingham> I suspect postponing to the week after is best. +11:06 < kbingham> neg: :D +11:07 < morimoto> I and Magnus go to ELC too +11:07 < pinchartl> geertu: should we postpone by a week ? +11:07 < jmondi> I now need to go for a doctor appointment... I'll read later when next meeting is scheduled and I have no particular feedbacks for Gen4 +11:07 < jmondi> sorry about that +11:07 < pinchartl> jmondi: no worries +11:08 < pinchartl> while waiting for Geert to wake up, let's address +11:08 < pinchartl> Topic 4. SW Feedback to HW team for R-Car Gen4 +11:08 < pinchartl> * Niklas +11:08 < pinchartl> I find the VIN register VNCSI_IFMD_CSI_CHSEL to problematic and it have +11:08 < pinchartl> created a lot of extra work in driver development. The VIN instances are +11:08 < pinchartl> independent of each other and fits rather well with the Linux driver +11:08 < pinchartl> model in regard to PM and clocks etc. +11:08 < pinchartl> Since the VNCSI_IFMD_CSI_CHSEL are only present on VIN0 and VIN4 but +11:08 < pinchartl> controls input settings for VIN{1,2,3,5,6,7} this creates a dependency +11:08 < pinchartl> between the different VIN driver instances. This is annoying and I'm not +11:08 < pinchartl> sure if this really simplifies the hardware (I'm no hardware engineer)? +11:08 < pinchartl> As the register selects different inputs for different VINs based on a +11:08 < pinchartl> single integer value in the CHSEL register each VIN likely still have +11:08 < pinchartl> its own separate input multiplexing logic? +11:08 < pinchartl> I base this assumption on the presence of the VNMC_DPINE register which +11:08 < pinchartl> is yet another multiplexing selection bit which is present only in VIN4 +11:08 < pinchartl> and VIN5. This bit controls if the VIN input come from CSI-2 receiver or +11:08 < pinchartl> form the digital parallel input and this register is local to the VIN +11:08 < pinchartl> for which the selection is valid. +11:09 < pinchartl> neg: how would you like to see this implemented in Gen4 ? +11:10 < neg> I'm no HW engineer so there might be constraints I'm not aware of but in my mind makig the VNCSI_IFMD_CSI_CHSEL register local to each VIN and independent of each other would be nice if it where possible +11:12 < morimoto> it is almost same as geert's comment ? +11:12 < morimoto> - All device instances should be mappable independently +11:13 < pinchartl> if that can't be done, would moving it to a syscon help ? +11:14 < pinchartl> morimoto: I don't think so. the problem here is that a register field located in one VIN influences all VINs +11:14 < pinchartl> the VINs are still mappable independently +11:14 < neg> I'm not sure how a syscon would look like so I can't awensere that +11:15 < pinchartl> the register would be in a separate register space +11:15 < pinchartl> that would have its own DT node +11:15 < pinchartl> with a phandle pointing to it in all DT nodes +11:15 < pinchartl> s/DT nodes/VIN nodes/ +11:16 < neg> Yes I think that would help as a separate DT node and a separate driver would make things easier +11:18 < pinchartl> another issue from me +11:18 < pinchartl> * Laurent +11:18 < pinchartl> Resource sharing in DU and VSP is painful to handle in software. +11:18 < pinchartl> In Gen2 SoCs the DU shared a set of 8 planes per group of two DU channels. This was configured through registers that required both DU channels to be disabled to change the plane assignment. Moving a plane from one DU channel to another caused flicker on the screen as the two channels had to be disabled, even if the plane was disabled to start with (disabled planes were still assigned to one DU channel +11:18 < pinchartl> ). +11:18 < pinchartl> In Gen3 SoCs the problem disappeared as DU channels do not interface to memory directly anymore but go through VSP-D for that purpose. However, on H3 ES2.0, and on M3-N, the VSP-DL instance serves two DU channels (DU0 and DU3), creating a similar issue. The VSP-DL has 5 inputs and two blending units, BRU and BRS. The BRU can blend up to 5 inputs and the BRS up too 2 inputs. The BRU and BRS thus have to +11:18 < pinchartl> be assigned to the DU channels dynamically at runtime based on the number of inputs used by each channel. As the two DU channels run asynchronously, this requires stopping display on one channel to release the blending unit in use, reconfigure the other channel to use that blending unit, and finally restarting the first channel. This creates flicker on the screen. +11:20 < pinchartl> any comment ? +11:20 < pinchartl> Additionally, on both Gen2 and Gen3 resources shared by two channels in a group are controlled through registers in the first channel of the group. This prevents assigning DU channels from the same group to different guests in a virtualized environment. Furthermore, as VSP-DL serves DU0 and DU3, we can't assign DU0 and DU3 to different guests either, even though they are not in the same group. The DU t +11:20 < pinchartl> hus can't be split between different guests. +11:23 < pinchartl> any other pain point with Gen3 hardware ? +11:23 < pinchartl> morimoto: when is the deadline to submit the list of issues ? +11:24 < kbingham> Having also put thought into the BRU/BRS issue - it certainly is painful ... +11:24 < morimoto> I think end of April or May +11:24 < morimoto> I will forward these to HW guys +11:25 < morimoto> But, there is no guarantee to fixed, we are sorry m(_ _)m +11:25 < pinchartl> of course +11:25 < pinchartl> I'll include this in the meeting report +11:25 < pinchartl> we can then think about the other issues until end of March +11:25 < morimoto> Thanks, it is usefl +11:25 < morimoto> useful +11:25 < pinchartl> and compile a report with all the reported issues +11:25 < pinchartl> in order to submit everything together to the hardware team +11:25 < pinchartl> is that OK ? +11:26 < morimoto> Yes, I think so +11:27 < morimoto> "end of March" mean you will busy after skiing :) +11:27 < pinchartl> I'm always busy :-) +11:27 < morimoto> you can do it on lift +11:27 < pinchartl> I'd like to revisit this topic during the next meeting +11:28 < pinchartl> neg: can I rephrase your second paragraph as +11:28 < pinchartl> Since the VNCSI_IFMD_CSI_CHSEL are only present on VIN0 and VIN4 but controls input settings for VIN{1,2,3,5,6,7} this creates a dependency between the different VIN driver instances. This is annoying from a driver point of view, and it would be easier if each VIN had a CHSEL register that controlled its own input routing. +11:28 < neg> pinchartl: thank you +11:29 < pinchartl> ok, that's it for today +11:30 < pinchartl> any last comment ? +11:30 < pinchartl> still no word from Geert for the next meeting +11:30 < pinchartl> I'll propose having it in 3 weeks +11:31 < pinchartl> no more comment, meeting adjourned +11:31 < pinchartl> thank you all for attending diff --git a/wiki/Chat_log/20180322-core-chatlog b/wiki/Chat_log/20180322-core-chatlog new file mode 100644 index 0000000..38af15d --- /dev/null +++ b/wiki/Chat_log/20180322-core-chatlog @@ -0,0 +1,127 @@ +Core-chat-meeting-2018-03-22 + +09:40 < geertu> Welcome to today's Core Group Meeting! +09:41 < geertu> Laurent and Marek are excused +09:41 < geertu> Everybody else seems to be here +09:41 < geertu> Agenda: +09:41 < geertu> 1. Status Updates +09:41 < geertu> 2. Discussion Topics +09:41 < geertu> Topic 1. Status updates +09:42 < geertu> A) What have we done since last time: +09:42 < geertu> Marek added M3N support to mainline u-boot, revisited PCIe upports, and +09:42 < geertu> presented 4 talks about U-Boot in the US. +09:42 < geertu> Shimoda-san submitted M3-N usb related DTS patches, discussed about 4/8 +09:42 < geertu> GiB support for R-Car H3 ES3.0, and prepared IPMMU workarounds for R-Car +09:42 < geertu> H3 ES3.0. +09:42 < geertu> Ulrich sent fix-ups for VIN4 pin definitions. +09:42 < geertu> Geert sent the first clk and pfc pull request for v4.17, sanitized +09:42 < geertu> EtherAVB pin groups, sent V2 of in-kernel BD9571MWV DDR backup mode, and +09:42 < geertu> annotated upport items. +09:42 < geertu> (so I have received Simon's and Uli's emails in the mean time. Anything else I missed/still in email flight?) +09:43 < wsa_> except for discussion, no new updates arrived on my side +09:43 < jmondi> geertu: no updates for Core +09:43 < geertu> B) What we plan to do till next time: +09:43 < geertu> Shimoda-san will submit PWM PFC patches for R-Car M3-N, and +09:43 < geertu> discuss with Magnus a plan to improve the IPMMU driver, and will try to +09:43 < geertu> port initial code for R-Car E3 Ebisu. +09:43 < geertu> Simon will probably do more DTS cleanup work (soc node and sorting). +09:43 < geertu> Geert will send the second clk and pfc pull request for v4.17, and +09:43 < geertu> revisit vfio and qemu patches. +09:43 < geertu> jmondi: thx +09:44 < geertu> C) Problems we have currently: +09:44 < geertu> None (hmm) +09:45 < geertu> dammsan is playing with old boards? ;-) +09:46 < geertu> Topic 2. Discussion Topics +09:46 < dammsan> geertu: wait when you get to see the SH board collection =) +09:46 < geertu> We still sort of have the 4/8 GiB support for R-Car H3 ES3.0 +09:47 < geertu> dammsan: Do they boot renesas-drivers? +09:47 < geertu> Unfortunately Marek U-Boot is not here +09:48 < geertu> horms: What's your stake? +09:49 < Marex> geertu: I kinda am +09:49 < horms> Ok, so the problem is we have different memory available but no good way to handle that with out current DT arrangement? +09:49 < dammsan> geertu: they currently collect dust +09:50 < Marex> geertu: what's up ? +09:51 < geertu> Marex: Where do you get memory size from on Gen3? DTS? +09:51 < Marex> geertu: yes +09:52 < geertu> H3 ES3.0 SiP may come with either 4 or 8 GiB +09:52 < geertu> E3 SiP may come with either 1, 2, or 4 GiB of RAM +09:52 < Marex> joy +09:52 < horms> ok, nice and complex +09:52 < horms> I guess we have no nice way to handle this at run-time +09:52 < Marex> geertu: is there a way to probe/detect that ? +09:52 < shimoda> geertu: E3 is not SiP, that will be 3 boards :) +09:52 < Marex> geertu: U-Boot has the ability to check for memory mirrors, but that's about that +09:54 < geertu> shimoda: Sorry, E3 board (as long as we don't have SiP .dtsis, board or SiP doesn't matter ;-) +09:54 < wsa_> Marex: BTW is there Gen3 WDT support in U-Boot? +09:55 < Marex> wsa_: no, is it needed ? +09:55 < Marex> wsa_: I am collecting requests for stuff to make people's life easier +09:55 < shimoda> geertu: ;) +09:55 < wsa_> Marex: well, kinda. We want to fix an issue in the WDT driver but can't sell it to the maintainers as is. We could sell it if we implement WDT handover from the bootloader :/ +09:56 < wsa_> However, that might be a customer use case, too, so it is not that bad... +09:57 < Marex> wsa_: wdt handover ? how would that work ? +09:57 < Marex> wsa_: ha +09:57 < Marex> wsa_: U-Boot will just leave the WDT on and the kernel/userspace should continue poking it, to prevent reset +09:58 < wsa_> Marex: I haven't looked into the details, but probably the driver needs to check if the WDT is already running and tell the Linux WDT core +09:58 < shimoda> horms: geertu: since we have no nice way for memory map configuration automaticaly, may I reply to BSP team about this? This means BSP team will create several DTS files :) +09:58 < geertu> Marex: +09:58 < horms> shimoda: i think that is the best option at this time +09:59 < shimoda> horms: i got it. thanks! +09:59 < geertu> Marex: If U-Boot could check if all memory banks exist, it could do probe of memory size +09:59 < dammsan> exactly +09:59 < wsa_> Marex: but however it works, a way to start the WDT in U-Boot will be needed ;) +09:59 < geertu> Looks like md doesn't handle > 32-bit addresses? +09:59 < geertu> Or is it not mapped? +09:59 < dammsan> checking the ddr controller settings must be possible? +09:59 < geertu> md = U-Boot md command +10:00 < shimoda> horms: i have one more question. when bsp team creates 2 types of DTS, one of dts file can include another one? +10:00 < geertu> dammsan: ATF is responsible for programming the DDR ctrlr, right? +10:00 < dammsan> most likely +10:01 < dammsan> but determining the setting during runtime from u-boot might be possible? +10:01 < dammsan> other platforms must have the same issue +10:01 < geertu> shimoda: Yes, the sample 8-gb dts you had, including the 4-gb .dts and overriding it, looks fine to me (if we go the route of multiple dts) +10:02 < geertu> But I'd like to avoid the proliferation of DTSes +10:02 < dammsan> geertu: me too +10:02 < shimoda> geertu: I got it, thanks! I will forward this information to BSP team +10:02 < geertu> So if U-Boot can autodetect, that would be great +10:03 < dammsan> indeed +10:04 < geertu> We can e.g. compare DDR register between M3/Salvator-X and M3ULCB (4 GiB vs. 2 GiB) +10:05 < horms> shimoda: yes, i think there is an example of that for the RZ/G1 DT +10:07 < dammsan> geertu: or do a simple write-read test for mirroring +10:07 < shimoda> horms: thanks for the RZ/G1 info. I'll look that +10:08 < geertu> dammsan: If it shows up as a mirror copy of the existing RAM. It may go buserr, too. +10:08 < dammsan> but which areas that are mapped can probably be determined by DDR controller settings or similar +10:08 < geertu> yes +10:09 < dammsan> to see if it is safe to access them or not +10:09 < geertu> If U-Boot can access the registers (you never know with ATF) +10:09 < dammsan> true +10:10 < Marex> geertu: can't you do SVC call into the ATF to determine the memory size ? +10:10 < Marex> geertu: but then again, Id like to have one set of blobs per SoC (or even per family) +10:11 < dammsan> that would make sense +10:11 < geertu> On your M3ULCB, the non-existing memory at 80000000 reads back zeroes +10:11 < Marex> geertu: so being able to detect the DRAM size would be very welcome +10:11 < geertu> Marex: AFAIK there's no memory size API in the ATF +10:11 < geertu> Writing to 80000000 works (= does not crash), still reads back zeroes afterwards +10:11 < Marex> (I want to complain about ATF being sub-optimal, but I guess everyone knows my opinion on it) +10:11 < dammsan> worst case we can use spectre/meltdown to determine memory size without bothering ATF =) +10:12 < geertu> On M3/Salvator-X, I can read/write at 80000000 fine +10:12 * pinchartl is back +10:12 < shimoda> dammsan: sorry for the delay, about write-read test for mirroring is not good because the hw might caure deadlock. +10:13 < geertu> If H3 ES3 and E3 behave the same, we can probe that way +10:13 < geertu> shimoda: Yeah, that was my worry too, but it seems to work on M3-W SiP ;-) +10:13 < dammsan> shimoda: it would have to be probed in a certain safe order for it to be useful +10:14 < dammsan> shimoda: do you think it is impossible? =) +10:15 < shimoda> dammsan: BSP team asked hw guys about the this topic, and then hw guys rejected this approauch because this way is possible to cause deadlock +10:15 < geertu> Hmm, e6790000 reads back as zeroes +10:15 < geertu> so DBSC4 is protected? +10:17 < shimoda> geertu: I guess DBSC4 reg area is in secure world +10:18 < geertu> shimoda: So we cannot read the DBSC4 regs, but can cause deadlock by reading non-existent memory? ;-) +10:18 < dammsan> shimoda: thanks for explaining =) +10:19 < shimoda> geertu: yes :) +10:19 < geertu> shimoda: Then IMHO ATF should provide the information we need... +10:19 < shimoda> dammsan: I should have descriped such information on my report though... +10:20 < geertu> I think the time has come to conclude the meeting +10:20 < geertu> Annything else to discuss? +10:21 < shimoda> nothing from me +10:21 < geertu> OK +10:21 < geertu> Thanks for joining, and have a nice continued day! +10:22 < dammsan> geertu: AXI bus section has details about memory protection areas =) diff --git a/wiki/Chat_log/20180322-io-chatlog b/wiki/Chat_log/20180322-io-chatlog new file mode 100644 index 0000000..848bf3d --- /dev/null +++ b/wiki/Chat_log/20180322-io-chatlog @@ -0,0 +1,206 @@ +09:01 < wsa_> hiya! +09:02 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi +09:03 < jmondi> and now I have received the emails, but still can't send any +09:03 < wsa_> Greetings from snowy Berlin... +09:04 < wsa_> So, Vaishali is not here yet. Will she come, is that known? +09:05 < morimoto> Ohayo +09:06 < wsa_> well, let's start then, maybe she'll come later +09:06 < wsa_> welcome to the IO meeting! +09:07 < wsa_> is everyone fine? it is so quiet here... +09:07 < morimoto> I'm fine :) +09:08 < jmondi> email issues apart, I'm fine as well :p +09:08 < neg> I'm fine, just waking up and out of coffey :-) +09:08 < dammsan> i assume vaishali will join, but i dont know if she got the meeting announcement? +09:08 < wsa_> is she on the list? +09:08 < horms> I can check +09:09 < dammsan> thanks guys +09:09 < shimoda> hi, sorry i talked with customer team guy now +09:09 < horms> no, i don't think she is +09:09 < horms> let me know an address to add if appropriate +09:09 < wsa_> I think she should be... +09:10 < wsa_> So, let's start with the status updates: +09:10 < wsa_> A) +09:10 < wsa_> Geert removed the requirement to need DT aliases for SCIF. Niklas fixed a bad comment in RAVB and reviewed the thermal patches in the BSP. Shimoda-san upstreamed M3-N bindings for Gen3-USB2-PHY and PWM, and also added PM to PWM. Wolfram finished the QEMU-I2C-passthrough research, fixed some issues with QEMU EEPROM emulation, started working into the new upporting list, subitted a talk proposal for AGL, and +09:10 < wsa_> did various reviews discussions, mainly about SDHI and Watchdog. +09:10 < wsa_> B) +09:10 < wsa_> Geert wants to enable MSIOF on M3-N. Niklas wants to upport thermal patches once he gets feedback from BSP team. Shimoda-san wants to research USB role swap issue nad add GPIO support to Gen3-USB2-PHY. Wolfram wants to do more SDHI work (tuning & fast modes), write feedback to the HW team for Gen4, plan new tasks (upporting & additional), and hopes to find some time to finally talk about reprogrammable I2C +09:10 < wsa_> addresses. +09:10 < wsa_> C) +09:10 < wsa_> None +09:11 < wsa_> The summary is missing Simon's and Uli's report which came a bit too close to the deadline +09:11 < uli___> no i/o updates from me +09:12 < wsa_> horms: uli___ : please send them a tad earlier, so I have a chance ;) +09:12 < horms> wsa_: sorry about that +09:12 < horms> It completely slipped my mind +09:12 * geertu hasn't received Simon's and Uli's report yet, blames Gandi +09:12 * morimoto we need to care that non PeriPeri member are joined in periperi-ML. That is the reason why didn't post datasheet download announce mail to it this time... +09:12 < horms> morimoto: I can send you the list of people on the list +09:12 < morimoto> Thanks, but It is OK +09:12 < horms> The only person I think could be removed is Khiem-san +09:13 < dammsan> horms: morimoto-san: can you consider if vaishali should be added or not? +09:13 < dammsan> i think it would make sense +09:13 < wsa_> I agree +09:13 < morimoto> If member who has contact to Jinso / Renesas, he/she is OK +09:13 < morimoto> I mean NDA +09:13 < dammsan> morimoto: NDA download will handled separately anyway, right? +09:14 < wsa_> So, Kaneko sent the D3 thermal update and will keep at it +09:14 < geertu> dammsan: "morimoto: ... That is the reason why didn't post datasheet download announce mail" +09:14 < wsa_> And Simon finished his QEMU task about networking and wonders about HS400 +09:14 < morimoto> dammsan: Yeah, so it is no problem now +09:15 < morimoto> Previous time, I posted download announce to periperi-ML, but maybe it was wrong from NDA point of view +09:15 < Marex> ( geertu forgot to mention https://www.denx.de/wiki/view/U-Boot/UbootStat_2018_03 in my report, not that I'd like to boast ;-) ) +09:15 < wsa_> dammsan: about QEMU tasks: are you satisfied with the outcomes yet? Is it priority to continue with them? +09:16 < wsa_> we have this other priority now to reduce the delta between BSP and upstream, as I see it +09:16 < dammsan> wsa_: not yet checked yours - sorry will do tomorrow +09:16 < neg> Marex: nice stats, congrats :-) +09:16 < wsa_> but that doesn't necesserily mean that QEMU is out of sight, or? +09:17 < dammsan> wsa_: i think we should keep at it with virtualization +09:17 < morimoto> Marex: yes, congrats +09:18 < wsa_> horms: about HS400, can you give your summary of the current state? +09:18 < horms> I am aware of a few issues. +09:19 < horms> 1) works on my HS3 ES1.0 but not yours? Probably can be fixed by correctly handling clocks for ES1.0 as the current setup seems to be that of ES2.0. +09:19 < horms> 2) follow-up work required for M3-N +09:19 < wsa_> dammsan: ok, fine. I am still not 100% sure of all the use cases, so we might want to talk about it somewhen to form the next add. tasks? +09:19 < horms> I feel we need a plan to solve 1) first +09:19 < dammsan> wsa_: yeah i think so +09:20 < horms> what is your view of things? +09:20 < wsa_> horms: wasn't it agreed on periperi to drop HS400 for H3 ES1.0? +09:20 < wsa_> let me check... +09:20 < horms> ok, somehow I missed that +09:20 < horms> perhaps we can have a follow-up chat to clarrify +09:20 < horms> basically i'm not clear on the situation and way forwards +09:21 < wsa_> horms: Message-ID: <TY1PR06MB09920F022C0459489E7B34FBD8DA0@TY1PR06MB0992.apcprd06.prod.outlook.com> +09:21 < wsa_> horms: yes, let's do that +09:22 < dammsan> may i chime in +09:22 < wsa_> sure +09:22 < dammsan> just wanted to say that older ES versions may not require the most efficient performance really +09:22 < dammsan> so tracking latest ES version and optimizing those might be a good thing to focus on +09:23 < horms> wsa_: thanks, I see that message. +09:23 < dammsan> i highly doubt that any customer would cry if they had PIO-only for older ES versions +09:23 < Marex> neg: morimoto: thanks ;-) +09:23 < horms> dammsan: thanks, understood. +09:23 < dammsan> thanks guys +09:23 < horms> It seems the proposal from Shimoda-san is not to support HS400 on H3 ES1.x +09:23 < horms> is that acceptable to you? +09:23 < dammsan> for sure +09:23 < horms> Ok, thanks +09:24 < wsa_> I'd favor that, too +09:24 < horms> In that case I think we more or less have a way forwards. Just have to sort out the technical details. +09:24 < horms> There was one more issue relating to where tuning hooks in +09:24 < geertu> As long as we get access to the newer hardware, that's fine (for H3 ES2.0 we have, for H2/M2-W we haven't) +09:24 < horms> I did try the suggestion to move it to the usual place, which failed +09:24 < horms> I think I should try again +09:24 < wsa_> let's talk about this later in #periperi-io after the IO meeting ended (so other ppl can join, too if they want) +09:25 < horms> sure +09:25 < wsa_> thanks! +09:26 < wsa_> so, there have been requests for smaller tasks for Kaneko-san and Vaishali +09:26 < wsa_> I wonder if M3-M enablement would be suitable? +09:26 < wsa_> M3-N +09:26 < wsa_> most (if not all) IO devices are identical to M3-W +09:27 < wsa_> so, I'd think this is a good chance to learn about IP cores from datasheets etc... +09:27 < shimoda> wsa_: enablement means adding bindings and/or adding dts? +09:27 < wsa_> yes +09:27 < wsa_> exactly +09:27 < geertu> enablement means ... + testing +09:28 < wsa_> also true +09:28 < shimoda> wsa_: geertu: i got it. thanks +09:28 < wsa_> which can be done even by remote for quite some IO devices +09:28 < wsa_> but they'd need access to the datasheets +09:29 < wsa_> is it possible? does it make sense? +09:29 < wsa_> it would reduce the periupport list also quite a lot, I'd think :) +09:30 < wsa_> Marex: BTW is there Gen3 WDT support in U-Boot? +09:30 < dammsan> wsa_: there is no NDA in place for Vaishali yet +09:30 < dammsan> wsa_: but remote access is possible +09:31 < geertu> Without NDA, she can access RZ/G1, RZ/A1, and RZ/N1 datasheets +09:31 < wsa_> hmm, well it would be a bit ... difficult ... to add DTS magic number without the datasheet +09:31 < wsa_> horms: what about Kaneko-san? +09:32 < dammsan> geertu: yeah so older devices might be more suitable +09:32 < horms> I have a confidentiality agreement with Kaneko-san +09:32 < wsa_> dammsan: OK +09:32 < horms> which last time we discussed this - a long time ago - was thought to be sufficient +09:33 < wsa_> do you think such tasks are suitable for him? +09:33 < horms> Yes, I think it could work out +09:34 < geertu> horms: Does Kaneko-san have hardware access? +09:35 < horms> no, i assume some sort of remote access could be arranged +09:35 < wsa_> horms: Good news, thanks +09:35 < horms> perferably in Tokyo +09:35 < wsa_> dammsan: do you have some RZ/... boards in your farm? +09:35 < dammsan> i have a genmai boars setup +09:36 < dammsan> and another one in a box +09:36 < dammsan> waiting to get a boot loader +09:36 < wsa_> good, i might have a task for vaishali then where she could use the genmai +09:36 < dammsan> good! +09:36 < dammsan> please contact her +09:37 < wsa_> I will +09:37 < geertu> dammsan: "another one in a box" == rskrza1? +09:37 < dammsan> yep i think so +09:37 < dammsan> and a peach as well +09:37 < wsa_> good +09:38 < wsa_> so, there will be HS400 discussion right after this meeting in #periperi-io and I will contact a few people in private chat about other stuff, too +09:38 < wsa_> that was it from my side +09:38 < wsa_> anything from your side? +09:40 < wsa_> well, then +09:40 < wsa_> I think it is time for core now +09:40 < wsa_> Thanks for this meeting! +09:40 < wsa_> Have fun, Geert! + +==== split out discussion about HS400 follows + +09:43 < wsa_> hiya +09:46 < wsa_> so, about HS400 +09:46 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi-io +09:46 < wsa_> I think we all agreed now to drop HS400 support for ES1.x +09:46 < wsa_> which makes a lot of sense to me +09:47 < wsa_> horms said he would try using the core hook for HS400 preparation again +09:47 < wsa_> that would be really good if it worked out +09:48 <@horms> Ok, I will look into that +09:49 <@horms> Regarding H3 ES1.x, do we have an idea of how to exlude HS400 support for those SoCs? +09:49 < wsa_> But there is still the issue that M3-N changes the HS400 game +09:49 < wsa_> (as well as all future ES of H3 and M3-W) +09:50 < wsa_> It needs a different tuning clock (200 instead of 400MHz) and has 8 taps instead of 4 +09:50 < wsa_> (if I recall correctly) +09:50 < geertu> @horms: soc_device_match() and a maximum speed field in of_device_id.data? +09:51 <@horms> ok, could be as easy as that +09:51 <@horms> I'll investigate +09:51 < wsa_> soc_device_match() and disable the capability? +09:51 < wsa_> HS400 capability +09:51 <@horms> Right, I'll look into a good way to use soc_device_match() +09:53 < wsa_> I tend to think we should upstream HS400-M3N-support incrementally +09:53 < wsa_> so we can upstream this series now +09:53 < wsa_> but I am open to other thoughts +10:00 < wsa_> however, we should be prepared for that +10:01 <@horms> wsa_: yes, I think so too +10:01 <@horms> support is present in the BSP +10:01 <@horms> so it doesn't look like a major headache +10:01 <@horms> but it needs something to be based on +10:01 <@horms> and we may as well get the base right first +10:04 < wsa_> the SD clk divider patch belongs to that base, too +10:05 < wsa_> There is still an open issue: +10:05 < wsa_> Message-ID: <20180227215352.gztj6ezjm7wtbm2z@katana> +10:07 < wsa_> shimoda: can you help here? +10:07 < wsa_> I will check the latest BSP code... +10:12 < wsa_> still the same +10:14 <@horms> wsa_: regarding SD clk patch, ack. I think it is fine as-is given that we no longer want to support H3 ES1.x. Do you agree? +10:15 < wsa_> Well, the code matches the data sheet +10:16 < wsa_> However, AFAIU, M3-N tunes with a clock of 100MHz +10:16 < wsa_> I would like to have this confirmed by the HW engineers +10:17 < wsa_> or to be proven wrong :) +10:17 < wsa_> but this M3-N which we agreed to be incremental +10:17 <@horms> Ok, I see +10:17 <@horms> Maybe we can confirm this using the BSP? +10:18 < wsa_> Not sure +10:18 < wsa_> I need to dive in more +10:19 < wsa_> Otherwise, it could just work... but at the speed of 100MHz +10:19 <@horms> Ok, do you think you could look into that? +10:20 < wsa_> This is mainly about asking HW engineers +10:24 <@horms> Ok, but perhaps we can examine the BSP to get some insight? Or do you think the BSP may be wrong in this regard? +10:27 < wsa_> It matches the datasheet +10:27 < wsa_> I don't know if the datasheet is correct +10:27 < wsa_> That's what I want to ask the HW guys :) +10:27 <@horms> Ok, got it +10:31 < shimoda> wsa_: sorry missed your comment, I should check the email of 20180227...? +10:31 <@horms> I will take a break now, should be back soon +10:35 <@horms> back +10:39 < wsa_> shimoda: I think I will rewrite my question in a seperate mail +10:39 < wsa_> shimoda: so you can forward it to HW engineers more easily +10:44 < shimoda> wsa_: i got it. Thanks! diff --git a/wiki/Chat_log/20180322-mm-chatlog b/wiki/Chat_log/20180322-mm-chatlog new file mode 100644 index 0000000..48daa42 --- /dev/null +++ b/wiki/Chat_log/20180322-mm-chatlog @@ -0,0 +1,248 @@ +Multimedia-chat-meeting-2018-03-22 + +10:31 < pinchartl> so welcome to the multimedia meeting +10:31 < neg> I'm ready +10:31 < morimoto> me too +10:32 < pinchartl> I would have started with Jacopo as he hasn't sent his report +10:32 < pinchartl> but I assume that could be related to his e-mail problems +10:32 < pinchartl> so I'll let him report here +10:32 < pinchartl> * Kieran +10:32 < pinchartl> Since last meeting: +10:32 < pinchartl> - Submitted a talk proposal for ALS +10:32 < pinchartl> - 2 versions of DU/Interlaced submitted (and it works now) +10:32 < pinchartl> - vsp1/tlb-optimise/v7 posted. (RB tags welcome ...) +10:32 < pinchartl> - Some back breaking holiday time. +10:32 < pinchartl> - Tried and failed to boot the wheat remotely. +10:32 < pinchartl> Until next meeting: +10:32 < pinchartl> - Test Wheat (D3 I2C conflict work) at last. +10:32 < pinchartl> - Other work tasks to be discussed in Multimedia meeting. +10:32 < pinchartl> Issues and Blockers: None +10:32 < pinchartl> kbingham: any comment ? +10:33 * jmondi back +10:33 < kbingham> I realised I could also add " - Helped Jacopo with Eagle-v3m display testing" to what I have done +10:33 < pinchartl> OK I'll add that +10:33 < pinchartl> * Laurent +10:33 < pinchartl> Since last meeting: +10:33 < pinchartl> - Submitted a talk proposal for ALS +10:33 < pinchartl> - Got DU LVDS rework merged +10:33 < pinchartl> - Skiing holidays +10:33 < pinchartl> - Patch review +10:33 < pinchartl> Until next meeting: +10:33 < pinchartl> - Get the GMSL patches posted to public mailing lists +10:33 < pinchartl> - Harvest BSP for multimedia patches +10:33 < pinchartl> - Upstream pending VSP patches +10:34 < pinchartl> Issues and blockers: None +10:34 < pinchartl> * Magnus: +10:34 < pinchartl> Since last meeting: None +10:34 < pinchartl> Until next meeting: None +10:34 < pinchartl> Issues and blockers: None +10:34 < pinchartl> * Morimoto-san +10:34 < pinchartl> Since last meeting: None +10:34 < pinchartl> Until next meeting: None +10:34 < pinchartl> Issues and Blockers: None +10:34 < pinchartl> dammsan, morimoto: any comment ? :-) +10:34 < morimoto> no comment +10:35 < pinchartl> * Niklas +10:35 < pinchartl> Since last meeting: +10:35 < pinchartl> - [PATCH v11 00/32] rcar-vin: Add Gen3 with media controller +10:35 < pinchartl> - [PATCH v2 0/2] rcar-vin: always run in continues mode +10:35 < pinchartl> - [PATCH v2] i2c: adv748x: afe: fix sparse warning +10:35 < pinchartl> - [PATCH v12 00/33] rcar-vin: Add Gen3 with media controller +10:35 < pinchartl> - [PATCH v2 0/2] rcar-vin: always run in continues mode +10:35 < pinchartl> - Attended ELC, noteworthy discussions I had +10:35 < pinchartl> - Talked to Gustavo, vb2 fences series seems to reach its final form +10:35 < pinchartl> and will likely hit upstream in a not so distant future. +10:35 < pinchartl> - Talked to Hans, he likes the VIN continues mode and sent a pull +10:35 < pinchartl> request during ELC for that work :-) He also liked the current v12 +10:35 < pinchartl> of VIN Gen3 patches and he have reviewed all patches in the series. +10:35 < pinchartl> - Fixed left-over DT compatibility string for CSI-2 DT which are +10:35 < pinchartl> submitted for renesas-drivers as detected by Geert. +10:35 < pinchartl> Until next meeting: +10:35 < pinchartl> - Await Laurents comments on VIN Gen3 v12 and repost hopefully the last version :-) Laurent do you want me to post v13 before you review to address Hans small nit-pick? +10:35 < pinchartl> - Try to scope out some MM related task(s) for my base time for Q2. +10:35 < pinchartl> - If there is time or if I have down time fixup CEC register mismatch for adv on Gen2 (low prio). +10:35 < pinchartl> Issues and blockers: +10:35 < pinchartl> - Kieran reviewed the CSI-2 driver, do anyone else in the MM team review it before I try to push upstream to review or hopefully pick up the patch? I think the best way forward is to ask Sakari to have a lock at it Laurent is over loaded. +10:35 < pinchartl> neg: I won't have time to review the VIN patches before the middle of next week, so if it's not much work you can post a v13 +10:35 < pinchartl> or wait for me, as you wish +10:36 < neg> pinchartl: OK then I will hold off for hans pull-requst to hit the media-tree and rebase ontop of the continues mode and repost as soon as thay happens +10:36 < pinchartl> ok +10:36 < pinchartl> regarding the CSI-2 driver, I reviewed an old version, I'd like to review the last one too, but that's not mandatory +10:36 < pinchartl> if you can get a review from Sakari in the meantime it would be nice +10:38 < neg> OK what do you suggest is the best way to get motion for the CSI-2 driver? I don't want to bug Sakari too much as he also seem to have a lot to do these days +10:38 < neg> If you have time to look at in before next meeting that is fine, but it's been sitting on the ML since Feb so I kind of want it to pick up speed :-) +10:38 < pinchartl> maybe you can ask Maxime for a review too, he has posted CSI-2 drivers recently +10:38 < neg> good idea +10:38 < pinchartl> February was yesterday :-) +10:39 < neg> :-) +10:39 < pinchartl> I'll try to review it around the end of next week +10:39 * kbingham would like to borrow pinchartl's time machine :D +10:39 < pinchartl> kbingham: it only works in one direction, all it does it shrink time +10:39 < pinchartl> I don't recommend it +10:39 < pinchartl> * Ulrich +10:39 < pinchartl> Since last meeting: +10:39 < pinchartl> - Sent fixes for Intel IGT test suite for false negatives on R-Car DU +10:39 < pinchartl> Until next meeting: +10:39 < pinchartl> - Check out what seems like legitimate IGT test fails, of which there are a handful. +10:39 < pinchartl> Issues and Blockers: None +10:39 < pinchartl> uli___: any comment ? +10:40 < neg> Thanks, and if you run of time please let me know and I will try to push forward with Sakari :-) +10:40 < pinchartl> OK +10:40 < pinchartl> feel free to ping me in a week +10:40 < pinchartl> I will be travelling again tomorrow and back home next Wednesday +10:40 < uli___> i'll send a summary of test fails to periperi later, for reference +10:41 < pinchartl> uli___: thank you, that will be nice +10:41 < pinchartl> jmondi: your turn +10:41 < jmondi> pinchartl: thanks +10:41 < jmondi> sorry I have not sent report, email's not working +10:41 < neg> pinchartl: ok thanks, will ping you late next week before I ask Sakari for review thanks for the information +10:42 < jmondi> Multimedia) 10 A) Since last time 11 - THC631024LVD 12 -- [PATCH v6 0/3] drm: Add Thine THC63LVD1024 LVDS decoder bridge 13 -- [PATCH v2 0/4] Renesas CEU: SH7724 ECOVEC + Aptina mt9t112 14 15 B) Next week 16 - Propose and API extensions to propagate LVDS mode through bridges 17 18 C) NULL 19 +10:42 < jmondi> ups +10:42 < jmondi> A) Since last time +10:42 < jmondi> - THC631024LVD +10:42 < jmondi> -- [PATCH v6 0/3] drm: Add Thine THC63LVD1024 LVDS decoder bridge +10:42 < jmondi> - soc camera +10:42 < jmondi> -- [PATCH v2 0/4] Renesas CEU: SH7724 ECOVEC + Aptina mt9t112 +10:42 < jmondi> B) next week +10:43 < jmondi> - Propose and API extensions to propagate LVDS mode through bridges +10:43 < jmondi> - more soc camera removal +10:43 < jmondi> C) Problems +10:43 < jmondi> None +10:43 < jmondi> Hans will send me the Ecovec camera module he found +10:43 < jmondi> --eot +10:43 < jmondi> brb, door ring +10:44 < pinchartl> nice +10:44 < pinchartl> I think that's all for the status updates. who have I forgotten this time ? +10:44 < neg> jmondi: is the Ecovec camare module listed under C) ? :-) +10:47 < pinchartl> as I don't seem to have forgotten anyone, +10:47 < pinchartl> Topic 2. BSP Team Requests +10:48 < pinchartl> morimoto: I think the VIN question was answered on the mailing list already +10:48 < pinchartl> with continuous mode support being merged upstream for Gen2 +10:48 < morimoto> yes, thanks +10:48 < pinchartl> and included in renesas-drivers for Gen3 +10:48 < morimoto> sounds nice ! +10:48 < pinchartl> - Display DPLL support on ULCB board +10:49 < pinchartl> I've seen your e-mail +10:49 < jmondi> sorry, I may be away for 10 minutes :( +10:49 < pinchartl> I'll reply after the meeting +10:49 < pinchartl> to my knowledge DPLL should work +10:49 < pinchartl> but it might not +10:49 < pinchartl> in which case I'll have to fix it +10:49 < jmondi> people fixing the doorbell in the building... +10:50 < morimoto> ULCB team want to use HDMI, and it seems it needs DPLL +10:50 < morimoto> they solved their issue, but wrong way +10:50 < morimoto> s/wrong way/using wrong way/ +10:50 < pinchartl> the DPLL is internal to the SoC, and I'm pretty sure it works on H3 as without it HDMI output wasn't working +10:50 < pinchartl> which ULCB board is the BSP team testing ? +10:50 < morimoto> H3 ULCB +10:51 < morimoto> It was just question mail. I can post more detail if you have time to forcus it +10:51 < pinchartl> I'll have a look and reply to the e-mail +10:52 < morimoto> OK, but again, it is generic question. no stress +10:52 < morimoto> Ohh, they want to use ULCB + HDML + 4K +10:52 < morimoto> s/HDML/HDMI/ +10:52 < pinchartl> + 4k might make a difference :-) +10:53 * jmondi back (again, and hopefully untile the end of the meeting) +10:53 < pinchartl> anyway I'll have a look and reply to the e-mail ASAP +10:53 < pinchartl> I will fly tomorrow though, and come back home on Wednesday +10:53 < pinchartl> - DRM plane types +10:53 < pinchartl> The rcar-du driver uses two plane types, with one DRM_PLANE_TYPE_PRIMARY plane per CRTC and all other planes set as DRM_PLANE_TYPE_OVERLAY. The BSP team wants to know if it would be possible to set DRM_PLANE_TYPE_OVERLAY for all planes. +10:53 < pinchartl> morimoto: you also mentioned +10:53 < pinchartl> "The background is that our customer want to clip some part from plane A, and want to indicate it on plane B." +10:53 < pinchartl> I'm not sure to understand that +10:54 < pinchartl> what do you mean by "indicate it on plane B" ? +10:54 < morimoto> they want to print clipped image (= from plane A) on plane B +10:55 < morimoto> print ? indicate ? put ? I don't know which English is OK +10:56 < pinchartl> could you get a detailed description ? what is the order of planes A and B ? what part of the screen do they span ? +10:56 < pinchartl> I'm afraid I don't understand the problem +10:56 < morimoto> OK, will ask to them +10:56 < pinchartl> thank you +10:57 < pinchartl> that should be all for the BSP team requests +10:57 < pinchartl> Topic 3. Additional Tasks for 2018 Q2/1 +10:57 < pinchartl> we haven't started discussing those yet +10:58 < pinchartl> and I won't have time before the end of next week +10:59 < pinchartl> dammsan: any comment ? +10:59 < kbingham> Are there priorities from renesas as to the direction we should be working on for ATs ? I.e. - upporting, virtualisation etc ? +10:59 < dammsan> lets chat about that in a little while +11:00 < dammsan> up-porting seems like a hot topic +11:01 < dammsan> and a mixed burger lacking the answer to why in the commit message +11:01 < pinchartl> please all feel free to propose tasks you think would be useful, and we can then discuss them at the end of next week +11:01 < pinchartl> that's all I have for today +11:02 < pinchartl> any comment or question ? +11:02 < jmondi> small one for morimoto-san and damsan +11:02 < neg> For upport work shall we split the work per driver or other method to not step on eachothers toes? +11:03 < jmondi> neg: go on, my question is very simple +11:03 < dammsan> thanks morimoto: what do you think? +11:04 < pinchartl> neg: I think we should coordinate before starting the work +11:05 < pinchartl> I planned to go through the BSP patches next week to see what can be up-ported +11:05 < neg> I plan to start before next meeting to mine BSP for VIN and CSI-2 upport work if no one else is really keen on geting into that ? +11:05 < pinchartl> but feel free to beat me to that +11:05 < pinchartl> I think that, for non-trivial patches, the work should be assigned to the person working on the related driver(s) +11:06 < pinchartl> but I'm sure there will be overlaps here and there, so we need to sync up +11:07 < neg> OK shall we schdule this sync as part of periperi meeting or sync some other way? I'm looking for a way so I don't duplicate work but have no real preference on how the sync is done +11:08 < pinchartl> we can sync up as soon as the BSP analysis is done +11:08 < pinchartl> I won't work on it before next Thursday +11:08 < pinchartl> so we can sync up next Thursday on IRC if you want to have a look already +11:09 < kbingham> What is required to do the BSP analysis ? Just go through each patch and identify /classify ? or is this where Geert's magic script comes in ? +11:10 < pinchartl> kbingham: just going through the patches, yes +11:10 < neg> Sounds like a plan, I will try to get a overview before next week. Next Friday is a public holiday here so I will be offline but sync on Thursday or Monday works for me +11:11 < pinchartl> kbingham: if you have time for that before next Thursday you can coordinate with Niklas +11:11 < kbingham> Ah yes - I almost forgot - we're coming up to easter holidays here too. +11:11 < pinchartl> please avoid classifying the patches twice independently :) +11:11 < neg> pinchartl: :-) +11:11 < kbingham> Ack :) - although perhaps that's a useful verification :D +11:13 < neg> kbingham: I will for a start only look at the VIN and CSI-2 drivers for MM upport and will sync with you if I jump and look at other drivers +11:13 < kbingham> neg: Ack ... perhaps we can use an etherpad or something so we can see eachothers progress in realtime and avoid duplication. +11:14 < pinchartl> kbingham: or just coordinate on IRC ? you might not need to do the work at the same time +11:14 < neg> kbingham: or a clone of periupport so the result is more easly integrated by our mighty group leader +11:15 < kbingham> yup ... however it works ... Haven't seen what's required yet :D +11:15 < kbingham> As long as we sync when we start. +11:17 < pinchartl> jmondi: you also had a question ? +11:17 < jmondi> yup +11:17 < jmondi> very quick and simple +11:17 < jmondi> morimoto: I asked mt9t112 sensor manual, but it's covered by NDA +11:17 < morimoto> yes +11:17 < jmondi> does this NDA extends to Magnus and from Magnus to me? +11:18 < morimoto> Uhm... dificult question. it is too old for us +11:18 < morimoto> and actually +11:18 < morimoto> I don't have this datasheet anymore... +11:18 < jmondi> I don't want to create more paper work for you, or fights with legals for something like this +11:18 < jmondi> ok, problem solved +11:19 < jmondi> morimoto: thanks for looking into it +11:19 < morimoto> sorry I couldn't help you +11:19 < jmondi> no worries! +11:20 < pinchartl> jmondi: is it similar to the MT9T111 ? +11:20 < morimoto> I think these 2 have no big difference +11:20 < dammsan> it's like r8a7795 and r8a7796 +11:21 < pinchartl> http://www.uctronics.com/download/MT9T111_MT9T112_DS_A.pdf +11:21 < dammsan> no big difference +11:21 < jmondi> pinchartl: yes, it's the same driver +11:21 < dammsan> =) +11:21 < pinchartl> does that help ? +11:21 < morimoto> Wow ! open datasheet ! +11:21 < jmondi> pinchartl: thanks, I have that +11:21 < jmondi> there are no registers description there +11:23 < neg> morimoto: at ELC we talked about my renesas-tests repo for automated testing of som IPs that the BSP team might be interested in and I told you I publish that. I looked at the repo and I need to do some cleaning before that can happen due to some borrowed none GPL code :-) And this might take some time, is this OK for you? +11:23 < pinchartl> jmondi: http://www.ideasonboard.org/jmondi.tar.bz2.gpg +11:23 < pinchartl> does that help ? +11:23 < morimoto> neg: thanks. it is OK +11:24 < jmondi> pinchartl: let me look into that +11:24 < pinchartl> last topic, next meeting +11:24 < pinchartl> two weeks from now ? +11:24 < pinchartl> geertu: ^^ +11:24 < pinchartl> wsa_: ^^ +11:25 < geertu> pinchartl: ack +11:25 < geertu> Time (DST)? +11:25 < neg> morimoto: the VIN continues mode was merged in media-tree just now :-) +11:26 < jmondi> pinchartl: thanks! it will help for sure! +11:26 < morimoto> neg: sounds good ! +11:26 < pinchartl> geertu: 09:00 BST / 10:00 CEST / 11:00 EEST / 17:00 JST +11:26 < pinchartl> (if I'm not mistaken) +11:26 < pinchartl> jmondi: you're welcome +11:27 < jmondi> morimoto: as now I have hardware and documentation, I cannot refuse anymore to be listed as the new v4l2 driver maintainer I guess. As the original driver author is this ok for you? +11:27 < jmondi> morimoto: I should have asked for ov772x as well probably +11:28 < morimoto> do you mean I'm auther for new ov772x/mt9t112 ? +11:28 < neg> pinchartl: Meeting in 2 weeks from now works for me +11:29 < pinchartl> so this is all for the multimedia meeting +11:29 < pinchartl> thank you all for attending +11:29 < jmondi> morimoto: you're author of the original soc_camera based driver, I have moved those driver and made a proper v4l2 subdev driver out of them. + diff --git a/wiki/Chat_log/20180405-core-chatlog b/wiki/Chat_log/20180405-core-chatlog new file mode 100644 index 0000000..6a97527 --- /dev/null +++ b/wiki/Chat_log/20180405-core-chatlog @@ -0,0 +1,92 @@ +Core-chat-meeting-2018-04-05 + +10:43 < geertu> Welcome to today's Core Group Meeting! +10:43 < geertu> Agenda: +10:43 < geertu> 1. Status Updates +10:43 < geertu> 2. Discussion Topics +10:43 < geertu> Topic 1. Status updates +10:44 < geertu> A) What have we done since last time: +10:44 < geertu> Marek worked on U-Boot TPL ("Third Program Loader") support for Porter, +10:44 < geertu> updated R-Car M2-W JTAG support to latest OpenOCD. +10:44 < geertu> Shimoda-san submitted M3-N PFC patches, and discussed a plan to improve +10:44 < geertu> the IPMMU driver with Magnus-san. +10:44 < geertu> Geert sent a second clk and pfc pull request for v4.17, fixed the dead +10:44 < geertu> serial console after serial wake-up, reviewed RZ/G1C patches, and +10:44 < geertu> enjoyed some Easter holidays. +10:45 < geertu> (BTW, Simon is enjoying Easter holidays, and thus excused) +10:45 < geertu> B) What we plan to do till next time: +10:45 < geertu> Marek will clean up and submit TPL, RPC, and QSPI patches for U-Boot, +10:45 < geertu> JTAG patches for OpenOCD. +10:45 < geertu> Morimoto-san will prepare his stomach and mental state for Ninja food. +10:45 < geertu> Shimoda-san will pave the way forward for IPMMU, and will try to port +10:45 < geertu> initial code for R-Car E3 Ebisu. +10:45 < geertu> Geert will enjoy more Easter holidays. After that he will revisit vfio +10:45 < geertu> and qemu patches, do more periupport analysis, and will flush his patch +10:45 < geertu> queue after v4.17-rc1 has been released. +10:47 < geertu> C) Problems we have currently: +10:47 < geertu> Shimoda-san would like to know how to add a node for usb2.0 ch3 on H3 +10:47 < geertu> ES2.0. +10:47 < geertu> Anything I missed? +10:48 < neg> Not from my side :-) +10:49 < geertu> Topic 2. Discussion Topics +10:50 < geertu> Shimoda-san would like to know how to add a node for usb2.0 ch3 on H3 ES2.0. +10:50 < geertu> https://patchwork.kernel.org/patch/9980275/ +10:50 < geertu> Enabling this requires flipping a switch, right? +10:50 < neg> kbingham[m]: ping :-) +10:51 < kbingham> neg: pong :D +10:51 < shimoda> geertu: yes. (according to the ML archive and board datasheet) +10:52 < kbingham> So we must chose between ADV748x and USB2 ch3 and boot time somehow. +10:53 < wsa_> a bit like the PCIE/SATA switch maybe? +10:53 < kbingham> We wouldn't be so lucky to be able to read this switch at runtime would we ? +10:55 < geertu> kbingham: I'm afraid not +10:56 < kbingham> So how should this be handled for the generic case - does it need to be some sort of overlay support ? +10:57 < geertu> In upstream DTS, we have to assume a fixed switch configuration. +10:57 < kbingham> And would you like me to do anything in particular in adv748x ? +10:58 < geertu> shimoda: Have you tried my suggestion, of using GP6_3[01] in salvator-common.dtsi, and overriding it in r8a7795-salvator-xs.dtsi? +10:59 < shimoda> geertu: not yet. so, I will try later +11:00 < shimoda> if success, is it acceptable for upstream? +11:00 < geertu> I think so. +11:00 < geertu> IIRC, my suggestion means that everything keeps working as before, and people who want to make use of the extra channel on H3 ES2.0 and Salvator-XS need to flip the switch. +11:01 < geertu> And everything (e.g. ADV7482) still keeps working after that. +11:01 < kbingham> What will be the effect of flipping that switch - and *not* changing the DT ? (i.e. the user doesn't chagne the DT either by overlay or otherwise) +11:01 < kbingham> Will it just be that the USB2 ch3 won't work ? or will it break ADV748x ? +11:01 < geertu> Correction: after the DT change, r8a7796-salvator-xs.dts +11:02 < geertu> \deleteline -) +11:02 < geertu> Correction: after the DT change, ADV7482 will stop working, until the user flips the switch +11:02 < kbingham> Or more specifically - only one of the ADV748x interrupts ? +11:02 < geertu> Flipping the switch and not changing DT will break the ADV7482 interrupt only, which is not yet supported anyway? +11:02 < Marex> geertu: can DTO help here ? +11:03 < Marex> geertu: U-Boot can apply DTOs +11:03 < geertu> So "stop working" really means "yet unsupported ADV7482 interrupt cannot work +11:03 < geertu> ", so it is harmless? +11:03 < kbingham> Ok - so if I make the (not yet implemented) ADV748x hotplug use only the unaffected interrupt - will we be able to support both ADV748x and USB2 ch3 ? +11:04 < geertu> kbingham: I think so. The switch allows to wire both ADV and USB using the new switch setting. +11:05 < geertu> With the old setting it keeps backwards compatibility with Salvator-X, which doesn't have the switch, and doesn't support the extra USB channel. +11:06 < kbingham> Ok - so I think we have a good all round solution there then. I will have to make sure that only the unaffected IRQ is passed to the ADV748x, and the ADV will have to configure that interrupt to handle whatever it needs. As long as that second interrupt is definitely routed in :) +11:07 < geertu> kbingham: I don't think you have to do anything, the interrupt is to be specified in DT. +11:07 < kbingham> geertu: Quite - but the (not yet implemented) adv748x interrupt configuration will have to map to the correct interrupt pin. +11:07 < kbingham> But that's fine - as it will be named. +11:08 < geertu> Naming or not doesn't matter. +11:08 < geertu> The common salvator-common.dtsi would describe the hardwired (Salvator-X) or default switch setting (Salvator-XS) +11:09 < geertu> r8a7795-salvator-xs.dtsi would override the interrupts property to accommodate the changed switch setting +11:09 < geertu> Does it all make sense? +11:10 < kbingham> Sorry - I meant naming for the driver to know which of the two interrupt sources is connected - as it has two which can both be configured for all interrupt reasons I believ. +11:10 < kbingham> It means the AFE(analog) and HDMI would share the interrupt in the ADV748x, which is why I assume they provide two interrupts +11:10 < kbingham> But I don't think its a problem. +11:11 < geertu> In both cases you can use both interrupts +11:12 < geertu> They're just routed to different pairs of pins on the SoC. +11:12 < kbingham> Ah yes - and I just re-read your message above... the changes specfic to -xs will then be handled there. +11:13 < geertu> (Yes, you can use other switch combinations not listed in the table near SW31 ;-) +11:13 < geertu> (those are considered invalid) +11:13 < geertu> Is there anything else to discuss? +11:14 < shimoda> not from me. thanks! +11:14 < kbingham> shimoda: I posted a USB2 crash to linux-renesas-soc ... +11:14 < kbingham> And I've referenced it this morning for you. +11:15 < kbingham> Is it something that you're aware of? Or did I likely make a silly mistake ? +11:15 < kbingham> (like it being related to this ch3 or such ) +11:15 < geertu> kbingham: You inserted the USB plug in the correct direction? ;-) +11:15 < kbingham> geertu: I always rotate my plugs 3 times before they fit :D +11:16 < geertu> kbingham: Three is considered a good number (https://en.wikipedia.org/wiki/Chinese_numerology#Three) +11:17 < geertu> Anyway, USB is I/O +11:17 < geertu> So let's conclude +11:17 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20180405-io-chatlog b/wiki/Chat_log/20180405-io-chatlog new file mode 100644 index 0000000..cded704 --- /dev/null +++ b/wiki/Chat_log/20180405-io-chatlog @@ -0,0 +1,138 @@ +10:00 < wsa_> let's start the IO meeting +10:01 < wsa_> welcome all! +10:01 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi +10:01 < wsa_> hi magnus! +10:01 < dammsan> hi guys +10:01 < wsa_> what about Vaishali? Is she on the list now? +10:01 < dammsan> not yet i think +10:02 < wsa_> I see +10:02 < wsa_> okay, then let's start with the status updates: +10:02 < wsa_> A) +10:02 < wsa_> Marek: picked up PCIe patches again. +10:02 < wsa_> Geert: enabled MSIOF on M3-N +10:02 < wsa_> Niklas: started with Thermal upporting +10:02 < wsa_> Shimoda-san: USB bugfix and role swap prototype +10:02 < wsa_> Ulrich: sent out new version of HSCIF sampling point +10:02 < wsa_> Wolfram: SDHI DMA RX workaround, re-test I2C double NACK issue +10:02 < wsa_> upporting I2C & SDHI, scheduling upporting tasks +10:02 < wsa_> B) +10:02 < wsa_> Marek: send out new version of PCIe patches +10:02 < wsa_> Niklas: continue thermal upporting and start with SDHI +10:02 < wsa_> check if H3 ES3.0 has thermal fuses +10:02 < wsa_> Shimoda-san: continue role swap, check Wolfram's SDHI patch, +10:02 < wsa_> USB PHY GPIO support +10:02 < wsa_> Ulrich: upporting +10:02 < wsa_> Wolfram: I2C & SDHI upporting, talk to QEMU devs about I2C passthrough +10:02 < wsa_> C) +10:02 < wsa_> Wolfram: recreating test cases for BSP patches is time-consuming +10:03 < wsa_> not super much going on. It is the no-add.-task-phase + easter +10:03 < wsa_> are there questions to that? +10:04 < wsa_> (not to easter ;)) +10:04 < wsa_> otherwise I would re-cap and continue the discussion about upporting +10:04 < wsa_> which is hi-prio now +10:04 < wsa_> and we all have extended base time for that +10:05 < wsa_> meaning that add. tasks in IO will currently need a special request +10:05 < wsa_> so, please talk to me if you have one +10:06 < wsa_> otherwise I would like to discuss "assignments" to IP cores now +10:06 < wsa_> meaning taking care of those BSP patches for upstreaming +10:07 < wsa_> in the order as I discovered them in the html-report file +10:07 < wsa_> Marex: do you have bandwidth for the PCIe patches? +10:07 < wsa_> I heard that jmondi has some capacity left ;) +10:08 < Marex> wsa_: I am doing what I can +10:08 < Marex> wsa_: whats left is just resubmit them anyway +10:09 < wsa_> Sure you are doing what you can, no doubts here +10:09 < wsa_> just wondering if you are overloaded and open for assistance or if everything is fine +10:10 < Marex> wsa_: it should be fine +10:10 < wsa_> OK, thanks! +10:10 < wsa_> wsa_: you are doing I2C/IIC? +10:10 < wsa_> sure +10:11 < wsa_> SDHI is a big beast +10:11 < wsa_> I asked neg to assist in the upporting efforts and he agreed (thanks!) +10:11 < wsa_> I will be there, too +10:12 < wsa_> and Simon has experience in this field as well +10:12 < Marex> wsa_: did you get SDHI to up-calibrate from HS200 to HS400 ? +10:12 < wsa_> Marex: Simon did and it worked for me +10:12 < Marex> OK, I'll talk to him +10:13 < wsa_> there are lots of patches for SDHI, so making a plan when to upstream what is still WIP +10:13 < wsa_> (especially given the problem to recreate the test cases) +10:14 < wsa_> but I think we have a good team to handle that +10:14 < wsa_> shimoda: are you still okay with supporting PWM? +10:15 < wsa_> same question about being overloaded :) +10:15 < wsa_> if you are fine, I am, too +10:15 < shimoda> wsa_: yes. I'm ok with supporting PWM +10:15 < wsa_> good, thank you +10:16 < wsa_> RAVB is planned for Simon who is not here yet +10:16 < wsa_> uli___: can you take care of the SCIF patches? +10:16 < wsa_> they are not much +10:16 < wsa_> but still +10:16 < uli___> can do +10:16 < wsa_> thx! +10:17 < wsa_> geertu: you already did MSIOF. are you fine with keeping that? +10:17 < geertu> wsa_: Sure +10:17 < wsa_> great +10:18 < wsa_> for updating DTS files, we asked Kaneko-san to do it. Let's see how that goes, if he needs further assistance, etc... +10:19 < wsa_> neg: you are the thermal guy, right? :) +10:19 < neg> yes :-) +10:19 < wsa_> good +10:20 < wsa_> shimoda-san is also still our USB hero +10:20 < shimoda> wsa_: yes :) +10:20 < wsa_> i think most USB patches in the BSP are already taken care of +10:20 < wsa_> Thank you! +10:21 < shimoda> wsa_: i think so! +10:21 < wsa_> for watchdog, I asked Vaishali to work on that and she already started +10:22 < geertu> watchdog is M3-N enablement? +10:22 < wsa_> jmondi: there doesn't seem to be an IP core left, but I'd be surprised if there wasn't something unexpected showing up +10:23 < wsa_> jmondi: would that be OK for you, doing various stuff? +10:23 < wsa_> watchdog is basically adding PM +10:23 < jmondi> wsa_: no worries, as I've said I welcome a task to alternate with multimedia, but I should wait to see how AT proposed by Laurent are assigned +10:23 < wsa_> but since the code is HW independent, the task is to try to implement a generic solution +10:23 < jmondi> I might find myself full again in a bit :) +10:24 < wsa_> heh +10:24 < geertu> PM == suspend/resume? +10:24 < wsa_> yes +10:25 < geertu> linux-next 07278ca1ccc9a124 ("watchdog: renesas_wdt: Add suspend/resume support") +10:25 < wsa_> uli___: one more thing, you still have the D3? +10:25 < uli___> i do +10:26 < wsa_> to my knowledge, we haven't enabled MSIOF there yet +10:26 < wsa_> do have an SPI device to attach and do that? +10:26 < wsa_> and time to do that? +10:27 < uli___> i think so +10:27 < wsa_> geertu: uuuh, right +10:28 < wsa_> geertu: need to think if the generic solution still makes sense +10:28 < wsa_> uli___: thanks! +10:29 < wsa_> so, that was it from my side +10:29 < shimoda> wsa_: how about sata? +10:30 < shimoda> and I have a question about sdhi whitelist again :) +10:30 < wsa_> shimoda: right, this is not much. I can do that if noone else volunteers +10:31 < shimoda> wsa_: i got it. +10:31 < wsa_> shimoda: fire away +10:31 < wsa_> the whitelist question +10:32 < shimoda> about sdhi whitelist, bsp team would like to know about future plan of upstream team. +10:32 < shimoda> now the whitelist has M3 ES1.0 for instance, but we will have M3 ES1.1 and ES1.2 +10:33 < shimoda> in this case, how do we take care of adding support these new SoCs revision? +10:34 < wsa_> I thought the idea was to remove the revision field for the "generic" entries +10:34 < wsa_> (i.e. not the ones needing the DMA RX quirk) +10:34 < geertu> In all other cases (except IPMMU), we have blacklists. +10:34 < wsa_> I haven't done this in the DMA RX quirk patch yet because this is a seperate issue +10:34 < geertu> SDHI is special because of the internal vs. external DMAC issue? +10:35 < wsa_> yes +10:36 < wsa_> and the possibility that some SoC could have both DMA +10:36 < wsa_> shimoda: I hope I got all that right. Or did I misunderstand something? +10:38 < shimoda> wsa_: i also think removing the revision field for the "generic" entries is good idea. But, is it conflict with DMA RX quirk? +10:38 < shimoda> or we can support both? +10:38 < wsa_> I think so but I still need to test that :) +10:39 < wsa_> I'd think we can have specific entries first, and then more generic ones as fallback +10:39 < shimoda> wsa_: i got it :) If so, I'll answer this plan to BSP team. thanks! +10:39 < wsa_> shimoda: good :) +10:39 < wsa_> dammsan: anything left from your side? +10:41 < wsa_> ok, then, there is still email for further issues +10:41 < dammsan> not much +10:41 < dammsan> thanks for your assistance +10:42 < wsa_> sure, you're welcome +10:42 < wsa_> geertu: then, prepare to grab the mic +10:42 < wsa_> here it comes +10:42 * geertu is preparing +10:42 * wsa_ throws +10:42 * geertu catches +10:42 < wsa_> \o/ +10:42 < wsa_> thanks all! diff --git a/wiki/Chat_log/20180405-mm-chatlog b/wiki/Chat_log/20180405-mm-chatlog new file mode 100644 index 0000000..51fd72a --- /dev/null +++ b/wiki/Chat_log/20180405-mm-chatlog @@ -0,0 +1,322 @@ +Multimedia-chat-meeting-2018-04-05 + +11:16 < pinchartl> I'd like to start with the last topic this time +11:16 < pinchartl> next meeting +11:16 < pinchartl> as everybody is still here +11:16 < jmondi> thanks! +11:16 < pinchartl> I propose one hour earlier than today, which was the time I intended for today's meeting :-) +11:17 < pinchartl> Thursday 2018-04-19 at +11:17 < pinchartl> 09:00 BST / 10:00 CEST / 11:00 EEST / 17:00 JST +11:17 < pinchartl> for the multimedia part +11:17 < pinchartl> so one hour earlier for I/O +11:17 < pinchartl> and half an hour earlier for Core +11:17 < pinchartl> would that be OK with everybody ? +11:17 < kbingham> pinchartl: I'll likely be on holiday that week. +11:17 < kbingham> But otherwise fine for me :) +11:17 < neg> Works for me +11:17 < geertu> Why only half an hour earlier for Core? +11:18 < pinchartl> because we usually have I/O at start + 0:00, Core at start + 0:30 and multimedia at start + 1:00 ? +11:18 < pinchartl> I meant half an hour earlier than 09:00 BST / 10:00 CEST / 11:00 EEST / 17:00 JST +11:18 < pinchartl> to make it clear +11:18 < pinchartl> I/O: 08:00 BST / 09:00 CEST / 10:00 EEST / 16:00 JST +11:19 < pinchartl> Core: 08:30 BST / 09:30 CEST / 10:30 EEST / 16:30 JST +11:19 < pinchartl> MM: 09:00 BST / 10:00 CEST / 11:00 EEST / 17:00 JST +11:19 < geertu> OK, I didn't know MM was the universal reference point ;-) +11:19 < geertu> "I propose one hour earlier than today", for all meetings +11:19 < pinchartl> it's my reference point when I write the MM report :-) +11:20 < pinchartl> geertu: too easy to understand ;-) +11:20 < pinchartl> is everybody fine with that schedule ? +11:21 < neg> fine for me +11:21 < uli___> me, too +11:21 < shimoda> yes +11:21 < jmondi> yup, I think for Europe is not a big deal as we're back where we were, maybe Japan doed not like 16pm? +11:21 * jmondi shuts up then +11:22 < pinchartl> jmondi: I assume Japan wouldn't mind going back home an hour earlier ? +11:22 < Marex> jmondi: that's 4pm, 4 is an unlucky number +11:22 < dammsan> i think it is a good idea +11:22 < pinchartl> jmondi: can I assume you're back, can we start the meeting ? +11:23 < jmondi> I haven't gone anywhere actually, but you can start, I'll read in 5 minutes +11:23 < jmondi> I need a coffe, I'm sorry +11:23 < pinchartl> ok :-) +11:23 < pinchartl> (I need a cup of tea) +11:23 < pinchartl> so welcome to the multimedia meeting +11:23 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +11:23 < pinchartl> I was going to go in alphabetical order, but that would start with jmondi +11:23 < pinchartl> so let's do reverse alphabetical order this time +11:24 < pinchartl> * Ulrich +11:24 < pinchartl> Since last meeting: +11:24 < pinchartl> - Sent summary of IGT test fails +11:24 < pinchartl> - Reviewed proposed additional tasks +11:24 < pinchartl> Until next meeting: +11:24 < pinchartl> - Up-port BSP patches +11:24 < pinchartl> Issues and Blockers: None +11:24 < pinchartl> uli___: any comment ? +11:24 < uli___> nope +11:24 < pinchartl> I have a question +11:24 < uli___> yes? +11:24 < pinchartl> what's your plan to upstream the igt patches you have sent ? +11:25 < uli___> no specific plan +11:25 < uli___> i haven't gotten around to fixing them up yet +11:25 < uli___> i guess that's on the todo +11:25 < pinchartl> ok, I'll had it to the todo list +11:25 < pinchartl> thank you +11:25 < pinchartl> next, neg +11:26 < pinchartl> * Niklas +11:26 < pinchartl> Since last meeting: +11:26 < pinchartl> - [PATCH v3] i2c: adv748x: afe: fix sparse warning +11:26 < pinchartl> - [PATCH v13 00/33] rcar-vin: Add Gen3 with media controller +11:26 < pinchartl> - Fished BSP code for up-port patches for VIN, CSI-2 and v4l2. +11:26 < pinchartl> - All VIN Gen3 support is now acked by both Laurent and Hans ! +11:26 < pinchartl> - CSI-2 patches are now acked by Kieran, Laurent and Maxime ! +11:26 < pinchartl> - Easter holiday. +11:26 < pinchartl> Until next meeting: +11:26 < pinchartl> - Collect review tags and small comments and repost VIN. Hans have stated he intends to post a pull request for this as soon as -rc1 is out. +11:26 < pinchartl> - Collect review tags and small comments and repost CSI-2. Ask Hans if he also can send a pull request for that. +11:26 < pinchartl> - Once VIN Gen3 and/or CSI-2 driver is in media-tree start posting up-port patches for those drivers (might not happen before next meeting). +11:26 < pinchartl> Issues and blockers: None +11:26 < pinchartl> neg: any comment ? +11:26 < neg> Not on status update +11:27 < pinchartl> thank you +11:28 < pinchartl> * Morimoto-san +11:28 < pinchartl> Since last meeting: None +11:28 < pinchartl> Until next meeting: None +11:28 < pinchartl> Issues and Blockers: None +11:28 < pinchartl> morimoto: any comment ? +11:28 < morimoto> No :) +11:28 < pinchartl> easy :-) +11:28 < pinchartl> * Magnus: +11:28 < pinchartl> Since last meeting: None +11:28 < pinchartl> Until next meeting: None +11:28 < pinchartl> Issues and blockers: None +11:28 < pinchartl> dammsan: any comment ? +11:28 < dammsan> nope +11:29 < pinchartl> * Laurent +11:29 < pinchartl> Since last meeting: +11:29 < pinchartl> - Harvest BSP for multimedia patches +11:29 < pinchartl> - Patch review (VIN and CSI-2 are finally ready) +11:29 < pinchartl> - Preparation of additional tasks for Q2 +11:29 < pinchartl> - Posted v2 of VSP BRU/BRS dynamic assignment +11:29 < pinchartl> Until next meeting: +11:29 < pinchartl> - Get the GMSL patches posted to public mailing lists +11:29 < pinchartl> - Upstream pending VSP patches +11:29 < pinchartl> Issues and blockers: +11:29 < pinchartl> - Ran out of Ben Shan oolong +11:29 < pinchartl> any question from anyone ? +11:29 < dammsan> how long is ben shan? +11:29 < pinchartl> https://teatrekker.com/product/ben-shan-spring/ :-) +11:30 < dammsan> =) +11:30 < pinchartl> * Kieran +11:30 < pinchartl> Since last meeting: +11:30 < pinchartl> - Tested Wheat D3 patch. Patches will be integrated through Simon's tree. +11:30 < pinchartl> - PeriUpporting +11:30 < pinchartl> - Examined ADV748x upport patches - Queried ADV748x std RESERVED_BIT patch. - Re: DRM Upport activities (Jacopo's thread) - Examined RCar-DU upport patches +11:30 < pinchartl> - VSP1 fix reported from Mauro +11:30 < pinchartl> See patch "media: vsp1: Fix BRx conditional path in WPF" +11:30 < pinchartl> - 4K testing +11:30 < pinchartl> Tests fail on plane-positioning and mode-set testing. +11:30 < pinchartl> - Reviewed BRx series from Laurent +11:30 < pinchartl> Until next meeting: +11:30 < pinchartl> - More 4K tests when I can move my board again. +11:30 < pinchartl> - Talk to Hans regarding EDID defaults +11:30 < pinchartl> - ... Some sort of additional task ... +11:30 < pinchartl> Issues and Blockers: None +11:30 < pinchartl> kbingham: any comment ? +11:30 < kbingham> Yes +11:31 < kbingham> Please add that I intend to take a week offline from 16th to 20th (this week was going to be my easter holiday week - but it's now moved to the 16th) +11:31 < kbingham> I'll likely (assuming we can still book it) be in a cabin in a forest with no internet access .. . :D +11:32 < pinchartl> lovely :-) +11:32 < pinchartl> will that include the surrounding weekends ? +11:32 < pinchartl> (I'll mark the weekends as part of your holidays ;-)) +11:33 < kbingham> no actually ... but then we shouldn't be considering weekends as workdays ... uhm ... right ? :D +11:33 < pinchartl> :-) +11:33 < pinchartl> * Jacopo +11:33 < pinchartl> Since last meeting: +11:33 < pinchartl> - Analyzed BSP for DRM activities, helped with review of ADV devices and DU tasks, prepared list of suitable additional tasks. +11:33 < pinchartl> - LVDS encoder support: v[1-6] of the series. Waiting for Rob to tackle DTS properties name discussion +11:33 < pinchartl> - Review and discussion of Peter Rosin's bridge format patch +11:33 < pinchartl> - Implemented interlaced video support for CEU. Still to be tested +11:33 < pinchartl> - Reviews of sensor drivers (dw9870, ov7251) +11:33 < pinchartl> Until next meeting: +11:33 < pinchartl> - Tackle on of the D3/M3-N upporting tasks when assigned +11:33 < pinchartl> - Follow Peter Rosin's work for bridge format propagation and devel on top of it. +11:33 < pinchartl> - Possibly test CEU interlaced support +11:33 < pinchartl> - More SH fun with CEU camera +11:33 < pinchartl> Issues and Blockers: +11:33 < pinchartl> - Need to ping Rob directly to unblock LVDS +11:33 < pinchartl> - Welcome a Core/IO activity to alternate with Multimedia for Q2 +11:33 < pinchartl> jmondi: are you back ? +11:34 < pinchartl> (how long does it take to make an Italian coffee ?) +11:34 < pinchartl> let's move to Topic 2. BSP Team Requests, we'll go back to Jacopo afterwards +11:34 < jmondi> pinchartl: yes +11:34 < pinchartl> ah :-) +11:34 < pinchartl> let's move to Jacopo then +11:35 < pinchartl> any comment ? +11:35 < dammsan> wsa_: please discuss additional tasks with me when you have time +11:35 < jmondi> pinchartl: you know we have a ritual for coffee +11:35 < wsa_> dammsan: i have time now +11:35 < morimoto> ritual +11:35 < morimoto> :) +11:35 < geertu> jmondi: I heard Starbucks coffee is better than Italian coffee... +11:35 < dammsan> wsa_: please move that to hangouts +11:36 * geertu hasn't tried Starbucks yet, IHRC +11:36 < jmondi> geertu: now we're going to have a fight on this +11:36 < pinchartl> morimoto: it's the Italian equivalent to 茶の湯 +11:36 < morimoto> Ah, OK +11:36 < geertu> pinchartl: Nah, the Italian version takes less time +11:37 < pinchartl> コーヒー道 +11:37 < pinchartl> more seriously, jmondi, any comment about the above list ? +11:38 < jmondi> nope, apart that I'll wait this afternoon and try to ping rob on irc eventually +11:38 < pinchartl> ok +11:38 < pinchartl> thanks +11:39 * morimoto I thought "ritual" means praying, bowing, etc +11:39 < pinchartl> morimoto: there are religious rituals, but ritual can be used in other contexts too +11:39 < pinchartl> Topic 2. BSP Team Requests +11:39 < pinchartl> - VIN/CSI2 format +11:39 < pinchartl> The VIN driver supports +11:39 < pinchartl> - MEDIA_BUS_FMT_YUYV8_1X16 - MEDIA_BUS_FMT_UYVY8_2X8 - MEDIA_BUS_FMT_RGB888_1X24 - MEDIA_BUS_FMT_UYVY10_2X10 +11:39 < pinchartl> The VIN hardware can also support MEDIA_BUS_FMT_UYVY8_1X16 by using VnMC::YCAL. +11:39 < pinchartl> The CSI2 driver supports +11:39 < pinchartl> - MEDIA_BUS_FMT_RGB888_1X24 - MEDIA_BUS_FMT_UYVY8_1X16 - MEDIA_BUS_FMT_UYVY8_2X8 - MEDIA_BUS_FMT_YUYV10_2X10 +11:39 < pinchartl> The BSP team would like to have support for MEDIA_BUS_FMT_UYVY8_1X16 in VIN and for MEDIA_BUS_FMT_YUYV8_1X16 in CSI-2. Niklas will look into it. +11:40 < pinchartl> neg: morimoto: did I capture the e-mail communication correctly ? +11:40 < neg> yes +11:40 < morimoto> About format, yes +11:40 < morimoto> About mode, I posted use-case +11:41 < pinchartl> - VIN transfer mode +11:41 < pinchartl> Niklas solved the VIN transfer mode switching issue: +11:41 < pinchartl> git://git.ragnatech.se/linux v4l2/next/vin/mode-v2 https://patchwork.linuxtv.org/patch/47929/ +11:41 < pinchartl> The patches will be upstream in v4.17. +11:41 < pinchartl> The BSP team has tested the code and confirmed the issue has been fixed. However, they noticed the disappearance of single capture mode support, and would like that functionality to be restored. +11:41 < pinchartl> Niklas noted that using continuous capture mode unconditionally simplified the driver and improved performances. If single capture mode is needed he isn't opposed to adding it back, but would like to have a clear description of the use cases. +11:41 < morimoto> It seems BSP team doesn't have strong reason +11:41 < pinchartl> ok. I propose continuing the discussion about VIN capture more on the mailing list then +11:41 < pinchartl> morimoto: you posted X-1, X-2 and X-4. is there no X-3 or have I missed it ? +11:42 < dammsan> may i propose "random" capture mode" to make it more exciting? +11:42 < neg> And I can't see a clean/usefull way of readding it other then a sysfs option / module paramater / v4l2 control to force using single capture mode, and all of those solutions seems odd +11:42 < neg> dammsan: I like your style! +11:42 < kbingham> Surely single capture mode is just send one buffer :D +11:43 < neg> kbingham: you need to specify how many buffers the driver wants before a stream can start and currently that is more then one, so no dice :-P +11:43 < pinchartl> neg: I agree with you. I don't see a use case for single capture, as we can capture a single frame even in continuous capture mode, can't we ? +11:43 < morimoto> pinchartl) sorry X- numbering is very random. total tree +11:43 < dammsan> how about using spectre/meltdown utility instead of silly sysfs? +11:43 < kbingham> neg: The driver no longer needs 3 buffers to start :D - (just 3 buffers to capture smoothly) +11:43 < pinchartl> morimoto: no worries, I just wanted to make sure I hadn't missed a X-3 +11:43 < neg> pinchartl: yes, but you still need to queue 4 buffers as min_buffers_needed = 4 +11:44 < pinchartl> did we have a lower minimum number of buffers when we supported single capture mode ? +11:45 < neg> pinchartl: yes, at first submission it was 3 then in a rework where it switched between single and continues capture the minimum was 1 but that led to the performance issue +11:46 < neg> pinchartl: so now with the always continues capture we need 4, which with a bit of work in patches I will submitt after Gen3 support is picked up might be able to be reduced to 3 +11:46 < pinchartl> how about using single capture unconditionally when we have one or two buffers, and continuous capture when we have more ? +11:47 < pinchartl> I mean the number of buffers queued at streamon time +11:47 < pinchartl> that way we could support single capture using a single buffer +11:47 < pinchartl> without having to allocate buffers that will never be used +11:47 < neg> pinchartl: that could work, but then all v4l2 tools would run using single capture as they queue the min buffers needed and then start the stream +11:48 < pinchartl> do drivers report the minimum number of buffers they need ? +11:48 < neg> so to run in continues mode the applicaiton would need to know about this and queue more buffers before starting the stream or have bad performance +11:48 < kbingham> Can the driver report that it needs 4 buffers ... but 'accept' only one ? +11:48 < neg> pinchartl: yes in vb2_queue min_buffers_needed field +11:48 < pinchartl> neg: but that's not reported to userspace is it ? +11:49 < pinchartl> kbingham: I think the only information reported to userspace is through REQBUFS +11:49 < pinchartl> if you ask for less than the minimum, you get the minimum +11:49 < neg> pinchartl: not sure how user-space handles it, but somethigng in the v4l2 framework ensures that numbers of buffers are queued before s_stream is called +11:49 < kbingham> So no then :) +11:50 < pinchartl> if you ask for less than the minimum, you get the minimum +11:50 < pinchartl> oops +11:50 < pinchartl> we might need an API extension there +11:50 < pinchartl> but apart from that, I don't see how we could select between the two +11:51 < pinchartl> I agree that allocating buffers that will never be used is a waste of memory +11:51 < pinchartl> but to be honest, I also think that most use cases will capture video and will wait continuous capture mode +11:52 < neg> Yes, I agree. It's a waste of buffers if you only want to grab one frame but most use-cases IMHO would benefit from continues capture mode +11:53 < pinchartl> I think we could investigate that, but only if there's a real need, as development would require a substantial effort +11:53 < neg> So yes a API extension would probobly be needed if this where to be supported with a user-space interface +11:53 < pinchartl> are we done with this question ? +11:54 < neg> I still don't know if I shall handle this or if we are shelfing it +11:54 < dammsan> i propose shafing or quefing =) +11:54 < morimoto> The conclusion is supporting single mode is difficult at this point, and it needs API extension ? +11:54 < dammsan> instead of shelfing +11:54 < pinchartl> I'll state in the meeting report that we need feedback +11:54 < morimoto> And I think it is not realistic +11:55 < dammsan> please don't include my suggestions in the report +11:55 < neg> morimoto: I still don't understand the use-case, in your reply it only stated that single mode was used before, now it's not but it might be good if it where still an option. But I don't understand why that is :-) +11:55 < neg> dammsan: :-) +11:56 < pinchartl> morimoto: I think the conclusion is that we need an API extension to make real use of single capture mode, it will require substantial development effort, and we should thus only implement it if really needed +11:56 < wsa_> ack on the new meeting date. i can imagine 4pm is way better for JPeri +11:57 < morimoto> BSP team don't know how the customer is using single mode, or not. Their main reason is just simple. They want to keep compatibility, because they doesn't want to update BSP guid pdf :) +11:57 < wsa_> :D +11:57 < morimoto> I think we can drop single mode. what do you think ? +11:58 < pinchartl> morimoto: I think so too +11:58 < pinchartl> - Status of vsp-tests +11:58 < pinchartl> Morimoto-san reported vsp-tests failures on H3 ES1.1 in +11:58 < pinchartl> Subject: Re: [periperi] 2018-03-01 - Group meeting - Infos & Call for updates +11:58 < pinchartl> Date: Thu, 01 Mar 2018 15:50:45 +0900 +11:58 < pinchartl> The issue has been discussed in the multimedia meeting on that day. The BSP team would like a status update. +11:58 < pinchartl> We haven't had time to look into these issues yet, they are still on the to-do list. As far as we understand this isn't urgent, but the priority can be raised if needed. +11:59 < pinchartl> that's all for the BSP team questions +11:59 < morimoto> I think it is not urgent. +11:59 < pinchartl> but today we have a new topic +12:00 < pinchartl> Topic 3. Questions for the BSP Team +12:00 < pinchartl> :-) +12:00 < morimoto> Just checking progress +12:00 < pinchartl> While going through the BSP patches to pick upporting candidate the following questions were raised (for the full discussion see "VIN and CSI-2 Upport" on the periperi mailing list). We would like the BSP team to provide us with information. +12:00 < pinchartl> - rcar-vin: Add memory type of VB_USERPTR support 373b05b01463bfbeca8d6382da29fa038ea4b8e1 +12:00 < pinchartl> Is there a use-case for USERPTR? Niklas has never used it and Laurent explained that there are not many use-cases for this that are not better served by DMABUF. We would like to know more about this use-case before upporting this if possible. +12:00 < pinchartl> - rcar-vin: Add overflow debug message option 4c0da798c52053d5a10e6d74364c12c049af0caa +12:00 < pinchartl> Is there a test-case for this? Are overflows common or is this just some diagnostic help for debugging? If possible it would be useful to know more about the reason for this commit. +12:00 < pinchartl> - rcar-vin: Set MEDIA_LNK_FL_ENABLED by using rvin_get_chsel 29c1ff33427f2c56ccc3dd4a3dd79026b2316f77 +12:00 < pinchartl> Niklas and Laurent discussed this commit and both think this is not suitable for up-porting. The user should enable the links in the pipeline as part of the format configuration before starting a stream. Is there a use-case for this in the BSP which we should consider? How does Renesas feel about dropping this from the BSP ? +12:00 < pinchartl> - media: rcar-csi2: Add blank margin when caluculating bit rate e2f958eedfdcd63145e147f273585a66889fa0db +12:00 < pinchartl> What is the rationale behind this? Is this not a property of the video source and not the CSI-2 receiver? Should not this be included in the V4L2_CID_PIXEL_RATE reported by the source? +12:00 < pinchartl> On the periperi mailing list Niklas reported this should be upported, but Laurent disagreed and explained how it could be a property of the video source instead. +12:00 < pinchartl> - media: rcar-csi2: Fix field detection b6aac9f75929a1ac54e5b026eeb717a7db44aa8e +12:00 < pinchartl> We believe this patch follows a wrong approach. The standard shall not be propagated inside the kernel but be explicitly set by the user for a pipeline which is part of a media graph. Would this change in approach fulfill the use-case which lead to this patch in the BSP? +12:00 < pinchartl> morimoto: all this will be included in the meeting report, I don't expect you to answer right now :-) +12:01 < pinchartl> neg: did I capture all that correctly ? +12:01 < neg> pinchartl: wall of text, reading now :-) +12:01 < pinchartl> for everybody else: if you have any similar question regarding the BSP patches, please send them by e-mail (or ask them now if you want to) +12:03 < neg> pinchartl: looks good +12:03 < kbingham> pinchartl: I sent one question already to Matsuoka-san +12:03 < pinchartl> thank you +12:03 < kbingham> But really all I want to know is from "Re: [periperi] [PATCH] media: i2c: adv748x: Fix video standard selection register setting" if the patch fixes a known issue. +12:03 < morimoto> pinchartl: thanks, I will forward to BSP team +12:04 < kbingham> If it does'nt fix anything then I'll likely drop the patch. +12:04 < pinchartl> kbingham: sounds good to me +12:04 < pinchartl> so that's all for the question to the BSP team +12:04 < pinchartl> the next topic is something you've all been waiting for +12:04 < pinchartl> Topic 4. Additional Tasks for 2018 Q2/1 +12:05 < pinchartl> The following additional tasks have been proposed for Q2/1, and Renesas has sorted them according to their priorities. +12:05 < pinchartl> 1) VIN and CSI-2 D3 and M3-N Support [9] (Split D3/M3-N) +12:05 < pinchartl> 9) DU D3 and M3-N Support [14] (Split D3/M3-N) +12:05 < pinchartl> 3) VIN and CSI-2 Power Management Support [2] +12:05 < pinchartl> 8) DU LVDS Dual Link Mode Support [1] +12:05 < pinchartl> 2) VIN Scaler (UDS) Support [4] +12:05 < pinchartl> 4) D3 VIN Support (Parallel Input) [0] +12:05 < pinchartl> 5) DU LVDS PLL Support [1] +12:05 < pinchartl> 6) DU 4k Display Support [2] +12:05 < pinchartl> 7) DU DPLL Fixes [3] +12:05 < pinchartl> We now need to estimate the effort. +12:05 < kbingham> what are the numbers in [*] ? +12:05 < pinchartl> the number of BSP patches that will be upported +12:05 < pinchartl> there are likely more patches than that +12:05 < kbingham> Aha ok +12:06 < pinchartl> I've only taken the ones that have been reported in the upport-related e-mails +12:06 < pinchartl> we can start estimating efforts now, or have a break and work on it this afternoon +12:08 < pinchartl> any preference ? +12:08 < kbingham> pinchartl: I'm fine here now as its only 11am, but it might be lunch time for you guys... so I can be flexible. +12:09 < jmondi> at 13.30 I will have builders here for a few hours to estimate some work in my place +12:09 < neg> I;d prefer this afternoon, but now works but if we do it like last time it will might be a longer meeting and then I might wish for a short break +12:09 < jmondi> I may be away for a few hours then +12:09 < pinchartl> I'd prefer having lunch first too +12:09 < jmondi> if afternoon is after 15pm CEST it should be fine for me +12:09 < kbingham> Ok - afternoon then :P +12:09 < pinchartl> after 15:00 CEST sounds good to me +12:09 < jmondi> thanks +12:10 < pinchartl> any other topic to discuss today ? +12:10 < neg> 1500 works for me +12:10 < kbingham> So - that's in how many hours :D +12:10 < kbingham> 3 ? +12:10 < neg> Not from me, thanks for summary of the BSP questions +12:11 < jmondi> not from me, thanks for the additional tasks proposals list +12:11 < pinchartl> 2h46 from now +12:11 < pinchartl> you're welcome +12:11 < pinchartl> the meeting is then adjourned +12:11 < pinchartl> thank you all for attending + diff --git a/wiki/Chat_log/20180419-core-chatlog b/wiki/Chat_log/20180419-core-chatlog new file mode 100644 index 0000000..696bb19 --- /dev/null +++ b/wiki/Chat_log/20180419-core-chatlog @@ -0,0 +1,187 @@ +Core-chat-meeting-2018-04-19 + +09:36 < geertu> Welcome to today's Core Group Chat +09:36 < geertu> Agenda: +09:36 < geertu> 1. Status Updates +09:36 < geertu> 2. Discussion Topics +09:36 < geertu> Topic 1. Status updates +09:37 < geertu> A) What have we done since last time: +09:37 < geertu> Jacopo fixed regressions on SuperH, and updated DTS bindings for M3-N. +09:37 < geertu> Kaneko-san posted patches to sort DT nodes on R-Car Gen3. +09:37 < geertu> Marek worked on U-Boot (SDHI, SPL, QSPI, RPC, DM/DT conversion), OpenOCD +09:37 < geertu> for R-Car H2 and M2-W, QEMU, and Linux (PCIe). +09:37 < geertu> Morimoto-san used his ninja-skills to provide SoC and board +09:37 < geertu> documentation. +09:37 < geertu> Niklas troubleshot dual core issues after v4.16. +09:37 < geertu> Shimoda-san submmited patches for initial base R-Car E3 support. +09:37 < geertu> Ulrich is enjoying holidays. +09:37 < geertu> Geert enjoyed some Easter holidays, revisited vfio and qemu patches, +09:37 < geertu> added PM Domain handling to vfio-platform, reviewed lots of new SoC +09:37 < geertu> support, and updated periupport for v4.17-rc1. +09:38 < geertu> B) What we plan to do till next time: +09:38 < geertu> Kaneko-san will address review comments for his patches. +09:38 < geertu> Marek will keep working on U-Boot (DM/DT conversion, CI setup). +09:38 < geertu> Morimoto-san will prepare for OSSJ and side events. +09:38 < geertu> Niklas will keep working with Vincent to fix the dual core problem. +09:38 < geertu> Shimoda-san will update his R-Car E3 patches, add USB2.0 ch3 to H3 ES2.0 +09:38 < geertu> DTS, and pave the way forward for IPMMU. +09:38 < geertu> Simon will cleanup more DTS files. +09:38 < geertu> Geert will prototype interrupts on qemu+kvm, do more periupport +09:38 < geertu> analysis, and handle CPG/MSSR and SYSC errata. +09:38 < geertu> C) Problems we have currently: +09:38 < geertu> Kaneko-san is looking for small tasks. +09:38 < geertu> Marek needs access to a Koelsch with R-Car M2-W ES2.0 or newer. +09:39 < geertu> Anything I missed? +09:39 < geertu> vaishali: You're working on watchdog under the I/O umbrella, right? +09:40 < vaishali> geertu: Yes +09:40 < geertu> OK +09:40 < geertu> Topic 2. Discussion Topics +09:42 < geertu> Anyone who has a core topic to discuss? +09:42 < geertu> Anyone who has a Koelsch with M2-W ES2.0, for Marek? +09:44 < wsa_> Is there an issue with WDT on U-Boot? +09:44 < wsa_> I keep asking but there is no reply +09:45 < Marex> wsa_: first time I hear that question +09:45 < Marex> wsa_: by the looks of it, not supported +09:46 < Marex> wsa_: adding a driver should be trivial I guess ? +09:46 < wsa_> I replied to your status mail yesterday :D +09:46 < wsa_> and I am quite sure I can dig up one or two more logfiles / mails +09:46 < wsa_> but that's not the issue +09:46 < wsa_> yes, it should be trivial and we need it to implement WDT handover in Linux +09:47 < Marex> oh that topic +09:47 < Marex> WDT handoff from U-Boot to Linux, that sounds more familiar +09:47 < wsa_> that could be more a task for Vaishali +09:47 < wsa_> we will see about that +09:48 < wsa_> in any case, we need it in U-Boot first +09:48 < Marex> wsa_: did the requirement for this handoff crystalize better first ? +09:48 < Marex> s/first// +09:49 < wsa_> "crystalize"? +09:49 < Marex> wsa_: what is it we are aiming for, getting the WDT running ASAP and throughout the whole boot process ? +09:50 < Marex> wsa_: if so, then you also need to consider when you turn it on , in U-Boot ? In SPL ? earlier ... in bootrom maybe ? +09:50 < wsa_> not ASAP +09:50 < wsa_> it is research +09:50 < Marex> but then what is the point ? the system can hand before WDT is active +09:50 < Marex> *hang +09:50 < geertu> There's also the secure WDT +09:50 < geertu> to be handled by ATF? +09:50 < Marex> geertu: Gen3 only I guess ? +09:51 < geertu> Marex: Gen2 also has SWDT hardware block +09:51 < wsa_> can we just have it for research reasons? +09:51 < Marex> wsa_: what are you attempting to learn from this research ? +09:52 < wsa_> U-Boot <-> Linux handover +09:52 < geertu> FTR, "git grep -i swdt plat/renesas/rcar" reveals ATF has SWDT support +09:52 < Marex> wsa_: anything in particular ? that just seems a bit vague +09:53 < wsa_> it is not +09:53 < wsa_> it is what i want to research +09:53 < Marex> wsa_: well, adding a driver to u-boot is certainly possible +09:54 < Marex> wsa_: and I guess real easy +09:54 < wsa_> either we agree on "sure, let's try" or we agree on "no, we do only full solutions" +09:54 < Marex> wsa_: well said +09:54 < dammsan> but whats the purpose? +09:54 < dammsan> (sorry if i'm being slow) +09:54 < dammsan> cover the entire boot process from as early as possible? +09:55 < wsa_> We need to implement the handover first to get other changes upstream +09:55 < Marex> if that was the case, see my remark about TPL ... and on Gen3, that'd mean handoff from ATF to U-Boot and U-Boot to Linux +09:56 < wsa_> and i thought we could do that since the U-Boot driver would be trivial to add +09:56 < Marex> wsa_: what "other patches" ? +09:56 < Marex> *other changes +09:56 < dammsan> ok, but u-boot is rather late in the boot process +09:56 < dammsan> perhaps the ATF -> U-Boot thingie is similar to the DDR memory topic? +09:57 < dammsan> we need to pass state in both cases +09:57 < wsa_> Marex: proper timer initialization according to documentation +09:58 < geertu> The "receiving" side can easily read the WDT registers to find out if the RWDT is enabled and running. +09:58 < wsa_> upstream rejected the patch as unneeded because we don't handle takeover yet +09:59 < dammsan> so why do we need to block on u-boot then if it is just a matter of reading registers? +09:59 < geertu> wsa_: Which patch was rejected? Do you have a link? +09:59 < wsa_> so i thought we could add that to get the patch upstream and learn about it to get one step closer to having proper WDT support when booting +09:59 < wsa_> but I am about to just give up on that +09:59 < Marex> geertu: was about to ask the same thing , might make it more obvious what the issue is, you were faster +09:59 < dammsan> wsa_: dont give up =) +10:00 < wsa_> [PATCH] watchdog: renesas_wdt: adapt timer setup to recommended procedure +10:01 * Marex reads the discussion there +10:01 < wsa_> but I need to go to the workshop now +10:01 < geertu> wsa_: Thx +10:02 < geertu> Ah, that patch. +10:02 < geertu> IMHO it has only a vague dependency on handover support. +10:02 < geertu> "The only exception I can think of is if the watchdog is +10:02 < geertu> already running during boot, but that situation isn't handled +10:02 < geertu> anyway. +10:02 < geertu> " +10:03 < geertu> Does fixing that need watchdog core support? Or just driver changes? +10:03 < wsa_> That's what I wanted to investigate +10:03 < geertu> ATF SW executive summary: void bl2_swdt_exec() { ... ; panic(); } +10:04 < geertu> s/SW/SWDT/ +10:04 < Marex> looks like a more general issue to me +10:04 < geertu> Well done, ATF! +10:04 < geertu> Sorry, forgot to quote the comment: +10:04 < dammsan> "As expected by The Firmware" +10:04 < geertu> void bl2_swdt_exec() { ... ; /* Endless loop */ panic; } +10:05 < Marex> good thing U-Boot is not firmware , no matter what other people claim +10:05 < Marex> wsa_: so your plan is to fix the WDT core to handle the handoff case proper, right ? +10:05 < Marex> wsa_: and for that you need someone to enable WDT before Linux boots ? +10:05 < wsa_> yes +10:05 < Marex> wsa_: can't you simulate that by poking the WDT registers on the U-Boot command line for now ? +10:06 < geertu> Or in early kernel startup +10:06 < wsa_> sure +10:06 < dammsan> geertu: do we need to preserve clocks during init too? +10:06 < Marex> wsa_: in the boot command even ... setenv bootcmd run wdt boot_linux +10:06 < wsa_> I thought the driver was trivial and U-Boot commands would be easiert to use +10:06 < geertu> dammsan: watchdog needs the clock running. +10:06 < dammsan> or i guess it is always-on 32khz clock that is needed +10:06 < wsa_> If I had foreseen this discussio, I'd surely have gone with poking registers +10:07 < Marex> wsa_: there are no commands for WDT, it just gets poked during U-Boot just like it does during Linux +10:07 < Marex> wsa_: the driver is trivial, sure +10:07 < wsa_> i see +10:07 < Marex> wsa_: but if you just need to fire up the WDT, it is probably trivial-er to just poke the registers +10:07 < wsa_> I agree +10:07 < Marex> but if there is interest in adding the WDT support to U-Boot, that can be done too :) +10:08 < wsa_> so, good outcome of the discussion after all :) +10:08 < Marex> wsa_: indeed! +10:08 < Marex> wsa_: and we untangled the confusion, which is nice +10:08 < wsa_> Yes +10:08 < geertu> dammsan: for RWDT, there's an MSTP bit +10:08 < wsa_> I guess I got a little grumpy because I'll be late for the workshop +10:08 < geertu> for SWDT, there isn't, it runs directly for external OSCCLK +10:09 < wsa_> my apologies for getting grumpy +10:09 < Marex> wsa_: sorry for being a little slow ! +10:09 * geertu has faint memories of an SWDT MSTP bit in an older datasheet +10:11 < geertu> Unless someone has something (short) else to discuss, I think we're finished? +10:11 < geertu> wsa_: Thx, and now run! +10:11 < pinchartl> wsa_: before you run +10:11 < pinchartl> next meeting ? +10:11 < pinchartl> two weeks from now ? +10:12 < wsa_> gotta ack +10:12 < pinchartl> I will be unavailable I'm afraid, but that shouldn't stop anyone from meeting +10:12 < wsa_> ack +10:12 < geertu> pinchartl: Fine for me (for Core) +10:12 < wsa_> 3 weeks would also be fine with me +10:12 < dammsan> 3rd is holiday in japan +10:13 < wsa_> 10th then? +10:13 < dammsan> 10th is not holiday +10:13 < geertu> 10th is a holiday in Belgium +10:13 < dammsan> haha +10:13 -!- shimoda [~shimoda@relprex2.renesas.com] has quit [Read error: Connection reset by peer] +10:14 < pinchartl> I'll be unavailable from 29/04 to 14/05 so please ignore me :-) +10:14 < geertu> horms: Same in NL +10:14 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi +10:14 < wsa_> ok, i am fine with both options, so let me know +10:14 < wsa_> cya! +10:14 -!- wsa_ [~wsa@46.189.28.194] has quit [Quit: ...] +10:15 < geertu> And in DE, too ;-) +10:16 < pinchartl> so ? +10:16 < pinchartl> we can also move it to a different day than Thursday +10:16 < dammsan> might be a good idea +10:16 < pinchartl> again I have no preference as I'll be away for two weeks +10:17 < horms> My mornings are typically open these days +10:17 < dammsan> 8th or 9th? +10:17 < shimoda> 8th or 9th is good to me +10:17 < morimoto> me too +10:18 < dammsan> i would vote for 9th myself +10:18 < pinchartl> dammsan: so you want to avoid the whole golden week, not just 憲法記念日 and みどりの日 ? :-) +10:18 < dammsan> i want to avoid forever +10:18 < dammsan> =) +10:18 < pinchartl> :-) +10:18 < dammsan> renesas office is empty the entire week +10:19 < pinchartl> I propose the 9th then +10:19 < geertu> 9th is fine for me +10:20 < morimoto> +1 +10:20 < geertu> So thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20180419-io-chatlog b/wiki/Chat_log/20180419-io-chatlog new file mode 100644 index 0000000..edb82a5 --- /dev/null +++ b/wiki/Chat_log/20180419-io-chatlog @@ -0,0 +1,143 @@ +09:02 < wsa_> Welcome! +09:03 < jmondi> 'morning! +09:03 < wsa_> I will start with the collected status updates (which need a bit more lines because of markdown, but hopefully they are better readable, too) +09:03 < wsa_> Status updates +09:03 < wsa_> ============== +09:03 < wsa_> A - what have I done since last time +09:03 < wsa_> ------------------------------------ +09:03 < wsa_> Geert +09:03 < wsa_> : has nothing to report this time +09:03 < wsa_> Jacopo +09:03 < wsa_> : tested Kaneko-san patches for thermal on D3 +09:03 < wsa_> Kaneko-san +09:03 < wsa_> : sent out new version of D3 thermal patches +09:03 < wsa_> Marek +09:03 < wsa_> : kept upstreaming PCIe patches +09:03 < wsa_> Niklas +09:03 < wsa_> : sent out some thermal patches and had no luck finding thermal fuses on M3-N +09:03 < wsa_> Shimoda-san +09:03 < wsa_> : reviewed SDHI old ES workaround and added support for USB role switch +09:03 < wsa_> Simon +09:03 < wsa_> : sent out new version of SDHI HS400 support and upported RAVB patches +09:03 < wsa_> Ulrich +09:03 < wsa_> : is on holiday +09:03 < wsa_> Wolfram +09:03 < wsa_> : upported SDHI & watchdog patches, made SDHI upporting master plan, did various upporting reviews & list updates, +09:03 < wsa_> created tree-wide series to fix clumsy platform_device handling, discussed with the syzkaller-author about QEMU +09:03 < wsa_> I2C abstraction, and did this new meeting minute report system +09:04 < wsa_> B - what I want to do until next time +09:04 < wsa_> ------------------------------------- +09:04 < wsa_> Kaneko-san +09:04 < wsa_> : wants to address review comments of D3 thermal patches +09:04 < wsa_> Niklas +09:04 < wsa_> : wants to start looking into SDHI tuning patches +09:04 < wsa_> Shimoda-san +09:04 < wsa_> : wants to continue with USB role switch, investigate usb2.0 host suspend/resume issue, support PHY GPIO support for E3, and check QEMU with USB +09:04 < wsa_> Simon +09:04 < wsa_> : wants to continue with HS400 and RAVB upporting and also to update his QEMU host/guest networking comparison report +09:04 < wsa_> Wolfram +09:04 < wsa_> : wants to start I2C upporting, review Simon's new HS400 patches, get a first sketch of a new QEMU I2C +09:04 < wsa_> pass-through mechanism +09:04 < wsa_> C - problems I currently have +09:04 < wsa_> ----------------------------- +09:04 < wsa_> Kaneko-san +09:04 < wsa_> : is looking for small tasks +09:04 < wsa_> Niklas +09:04 < wsa_> : needs someone with access to a board with thermal fuses set +09:04 < wsa_> Simon +09:04 < wsa_> : may need to contact RAVB patch authors directly? +09:04 < wsa_> Wolfram +09:04 < wsa_> : needs a way to handle (get rid of?) need of a-priori knowledge for QEMU I2C pass-through +09:04 < wsa_> (to determine if a message is to be terminated with STOP or REPEATED_START) +09:04 < wsa_> vaishali: how are things on your side? +09:04 < pinchartl> hello +09:05 < wsa_> and are there further comments to the status updates? +09:06 < vaishali> wsa_ I'm almost there. Should be able to at least send RFC by tonight/tomorrow morning. +09:06 < wsa_> nice! +09:07 < wsa_> I will add this to the report +09:07 < vaishali> wsa_: Thanks. +09:08 < wsa_> horms: do you think RAVB patch authors will answer mails directly? +09:09 < horms> I have had successful correspondence with Mizuguchi-san before, so in that case yes +09:09 < wsa_> cool! +09:09 < horms> It was really a question for Shimoda-san to see if he would like to handle things a different way from the past +09:09 < wsa_> you have some language advantage there +09:09 < horms> As I haven't made any such contact for some time +09:09 < horms> it may or may not be an advantage :^) +09:10 < horms> I think these issues are not pressing +09:10 < horms> so how about I try to contact the developers directly +09:10 < horms> and report on progress or lack thereof? +09:10 < wsa_> sounds good to me +09:10 < wsa_> shimoda: are you fine with that? +09:10 < horms> It might have been better if I made such contact before posting the patches +09:10 < shimoda> horms: i would like to be interface guy to Mizuguchi-san and Nagai-san +09:11 < horms> shimoda: ok, sure +09:11 < horms> I'll seend you a summary of my questions +09:11 < shimoda> horms: i got it! +09:12 < wsa_> the other topic I have is somehow close to that +09:12 < wsa_> and not really new +09:12 < wsa_> for upporting "high"-priority I2C patches, I'd mostly always need a test case +09:13 < wsa_> how is this for you? +09:13 < wsa_> or are the patches more straightforward there +09:14 < wsa_> ? +09:15 < horms> wsa_: who is this question for? +09:15 < wsa_> open +09:15 < wsa_> throw in your experiences :) +09:15 < horms> Well, I think its better if there is a test case. But I also think that its possible that the patches are obviously correct. +09:16 < horms> Depending on their contents, of course. +09:16 < horms> My experience from RAVB +09:16 < horms> is that I was a bit to motivated to flush out the patches for admin/reporting/... reasons +09:16 < horms> and should have paid more attention to upstream requirements - motivation for the patch, relevance to current upstream code, etc... +09:17 < dammsan> horms: glass is half full there =) +09:17 < shimoda> i can ask bsp team about your questions. +09:17 < horms> Yes, then suddenly it was half empty :) +09:18 < dammsan> i would say 50% correct =) +09:18 < shimoda> wsa_: all patches need a test case? +09:18 < dammsan> but i guess it is case by case +09:19 < wsa_> shimoda: this is what I wanted to find out if every patch needs a test case? +09:19 < wsa_> shimoda: so I wanted to know if I2C and SDHI are special or not +09:19 < wsa_> but it seems really case by case +09:20 < wsa_> but in general: the more test-cases (or ways to reproduce) the better +09:21 < wsa_> even if it is just to make sure the issue was not only fixed in the BSP kernel but also in the upstream kernel +09:22 < wsa_> I guess we will see how it goes +09:23 < horms> Right, especially if the patch was made against a v4.9 based BSP, which is rather old by now +09:23 < wsa_> And I need to improve how to ask open questions ;) +09:23 < wsa_> I don't have any other topic +09:24 < wsa_> we don't have add. tasks this quarter and people are busy upporting +09:24 < dammsan> wsa_: why would I2C and SDHI be special? +09:24 < wsa_> no reason +09:24 < wsa_> that's why I asked +09:24 < wsa_> how other ppl would handle this +09:25 < dammsan> i think it is important to take target platform into consideration +09:25 < dammsan> my gut feeling is that BSP folks are focusing on solving the issue in front of them +09:25 < dammsan> and perhaps not thinking how it affects other generatiosn / sooooooooooocs +09:25 < shimoda> about test cases, bsp team described them in internal redmine tickets, but I don't know why but they don't describe into the commit log... +09:26 < shimoda> sometimes i could find the tickets, but +09:26 < shimoda> sometimes i asked bsp team +09:26 < wsa_> shimoda: are they described in Japanese or English? +09:26 < shimoda> of course Japanese :) +09:26 < wsa_> :D +09:27 < wsa_> maybe they could at least add the ticket number to the patch? +09:27 < wsa_> not much to type, but still helpful +09:28 < dammsan> horms: how did you handle things when you felt information was lacking? +09:28 < shimoda> I'm not sure about adding the ticket number. +09:28 < shimoda> anyway I'll ask them. +09:28 < geertu> wsa_: Under the ---, upstream doesn't like private ticket numbers in public commit messages +09:29 < dammsan> geertu: including not-yet-disclosed CVE? =) +09:29 < dammsan> (perhaps thats a different thing) +09:30 < wsa_> geertu: I would consider this part of the upporting work to remove them +09:30 < horms> dammsan: my usual approach is to try to work out what the BSP developer was trying to achieve with a patch. If I can fill in gaps with documentation or some creative testing then I try to do so. But if there are gaps - particularly if I think they have some inside information (f.e. this bit changed meaning between ES versions) then I try to ask specific questions of that nature. +09:30 < dammsan> makes sense +09:30 < wsa_> but for internal bsp patches, this could be nice? we will see what the BSP team thinks +09:31 < wsa_> thanks, shimoda-san! +09:31 < wsa_> horms: yes, that's what I am trying to do as well +09:33 < wsa_> but for quite some patches, it would speed up things a lot if test cases were available +09:34 < horms> of course +09:34 < wsa_> anyhow, i think we are aligned here +09:34 < wsa_> any other topics left? +09:34 < horms> but I think the BSP team is more receptive to specific rather than general requests +09:35 < wsa_> ok +09:35 < wsa_> then we can handover to core? +09:35 < wsa_> geertu: are you ready? +09:35 < geertu> wsa_: I am +09:35 < wsa_> good +09:35 < wsa_> thanks for this meeting! diff --git a/wiki/Chat_log/20180419-mm-chatlog b/wiki/Chat_log/20180419-mm-chatlog new file mode 100644 index 0000000..8b4eac1 --- /dev/null +++ b/wiki/Chat_log/20180419-mm-chatlog @@ -0,0 +1,258 @@ +Multimedia-chat-meeting-2018-04-19 + +10:24 < pinchartl> anyway, let's get started +10:24 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:24 < pinchartl> * Jacopo +10:24 < pinchartl> Since last meeting: +10:24 < pinchartl> - V3M Eagle display enablement +10:24 < pinchartl> Patches have been posted as "[PATCH v2 0/4] V3M-Eagle HDMI output enablement". +10:24 < pinchartl> - LVDS decoder support +10:24 < pinchartl> Patches have been posted as "[PATCH v9 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge". Not yet but almost ready features includes +10:24 < pinchartl> - Add static image format support to DRM bridges +10:24 < pinchartl> - Make du_lvds use DRM bridge image format +10:24 < pinchartl> - Patch review +10:24 < pinchartl> Until next meeting: +10:24 < pinchartl> - VIN enablement on D3 Draak +10:24 < pinchartl> - soc_camera removal +10:24 < pinchartl> Issues and Blockers: None +10:24 < pinchartl> jmondi: any comment ? +10:25 < jmondi> pinchartl: not really +10:25 < jmondi> apart from DRM people being a bit unresponsive +10:25 < pinchartl> please ping them +10:25 < jmondi> and that I'm holding the DRM bridge format series beacause of that +10:25 < jmondi> I setn v9 yesterday iirc +10:25 < jmondi> I'll wait a few days maybe +10:26 < pinchartl> ok +10:26 < pinchartl> do you think it's ready to be merged ? +10:27 < jmondi> I guess so, I have collected 3 or 4 reviewed-bys +10:27 < jmondi> rob's one on bindings +10:27 < jmondi> yours and Andrzej's one on driver +10:27 < pinchartl> you can ping Archit +10:27 < pinchartl> architt on IRC +10:27 < jmondi> it should be good I guess +10:27 < jmondi> I will +10:28 < pinchartl> thank you +10:28 < pinchartl> * Laurent +10:28 < pinchartl> Since last meeting: +10:28 < pinchartl> - Patch review +10:28 < pinchartl> - Additional tasks preparation +10:28 < pinchartl> - LVDS OF overlay fixes +10:28 < pinchartl> Until next meeting: +10:28 < pinchartl> - Get the GMSL patches posted to public mailing lists +10:28 < pinchartl> - Upstream pending VSP patches +10:28 < pinchartl> - Trip to Japan (29/04 to 17/05) +10:28 < pinchartl> Issues and blockers: None +10:28 < pinchartl> any question ? +10:29 < dammsan> will you post GMSL before going to Japan? =) +10:29 < pinchartl> I want to +10:29 < morimoto> you came to Japan from 29/04 ? +10:29 < pinchartl> yes, and I will be in Tokyo from 14/04 to 17/04 +10:30 < geertu> /05? +10:30 < pinchartl> sorry, 14/05 to 17/05 +10:30 < morimoto> for 1 month !? +10:30 < jmondi> 2019? +10:30 * jmondi hides +10:31 < pinchartl> landing in Haneda on 14/05 at 14:55 and leaving from Narita on 17/05 at 09:50 +10:31 < morimoto> And came again in Jun ? +10:31 < pinchartl> two weeks and a half :-) +10:31 < pinchartl> yes, then coming back in June +10:31 < morimoto> sound nice +10:32 < pinchartl> I hope it will be :-) +10:32 < pinchartl> it will be my first Golden Week in Japan +10:33 < pinchartl> * Magnus: +10:33 < pinchartl> Since last meeting: None +10:33 < pinchartl> Until next meeting: None +10:33 < pinchartl> Issues and blockers: None +10:33 < morimoto> :) +10:33 < pinchartl> dammsan: any comment ? :-) +10:34 < pinchartl> * Morimoto-san +10:34 < pinchartl> Since last meeting: +10:34 < pinchartl> - Wash up random request from BSP team +10:34 < pinchartl> As far as understood, almost all BSP team requests are already solved. The only exception is "[PATCH] media: rcar-vin: Fix image alignment for setting pre clipping". +10:34 < pinchartl> Until next meeting: None +10:34 < pinchartl> Issues and Blockers: None +10:34 < pinchartl> morimoto: any comment ? +10:34 < dammsan> no comment from me +10:34 < morimoto> no comment +10:34 < pinchartl> * Niklas +10:34 < pinchartl> Since last meeting: +10:34 < pinchartl> - [PATCH v14 00/33] rcar-vin: Add Gen3 with media controller +10:34 < pinchartl> Hans has sent a pull-request for VIN Gen3 patches \o/ +10:34 < pinchartl> - Found issue on v4.17-rc1 related to V4L2 and ADV748x, see blockers +10:34 < pinchartl> - Addressed all review comments on the CSI-2 driver, will repost after syncing with Laurent +10:34 < pinchartl> - Implemented Morimoto-sans request of extending media bus format support for VIN and CSI-2 +10:34 < pinchartl> - [PATCH] media: entity: fix spelling for media_entity_get_fwnode_pad() +10:34 < pinchartl> Until next meeting: +10:34 < pinchartl> - VIN and CSI-2 enhancements and upport +10:34 < pinchartl> Once VIN Gen3 and/or CSI-2 driver is in media-tree start posting up-port patches and patches held back for VIN due to dependency on Gen3 patches. +10:34 < pinchartl> - Start M3-N VIN integration +10:34 < pinchartl> Issues and blockers: +10:34 < pinchartl> - CMA problems on v4.17-rc1 +10:34 < pinchartl> v4.17-rc1 brings in bad8c6c0b1144694 ("mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE"). This issue brings a issue we are already aware of into a critical problem. +10:34 < pinchartl> The patch in question plays with CMA, The technical analysis is currently missing, but the result however is very noticeable. If the format configured in the media graph don't match reality more data then is allocated in the capture buffer can be written to the buffer. This was known before but this change appears to place the capture closer to other data which now easily crashes the whole system. +10:34 < pinchartl> To make matters worse there seems to be no way to set the video standard (PAL/NTSC/..) on a subdevice that is part of a media graph. This currently makes CVBS capture dangerous to to use with anything but a NTSC source as that is the adv748x drivers default standard. Niklas has developed a patch for the kernel subdevice implementation that allows for QUERYSTD, G_STD and S_STD to be controlled as for a +10:34 < pinchartl> video device, similar work have already been done for EDID and other similar IOCTLS. +10:34 < pinchartl> Before posting the patch Niklas wanted to discuss the solution with the multimedia team. As extending the IOCTLS that are allowed for a subdev might be useful the core of the problem is still the same. If the user selects NTSC and feed it a PAL source things will crash which is not really good. One idea is to have the get_fmt/set_fmt of the AFE in the adv748x detect the current standard and return +10:34 < pinchartl> format based on that, but we tried that in the past and it was rejected. +10:35 < dammsan> pinchartl: i want to ask you about ipmmu support at some point +10:35 < pinchartl> dammsan: sure, let's discuss that after the status update +10:35 < pinchartl> neg: any comment on done/todo ? +10:36 < pinchartl> have we lost Niklas ? +10:37 < pinchartl> seems so +10:37 < dammsan> pinchartl: just fyi there is a measels outbreak in okinawa now +10:37 < pinchartl> I'll reply to his issue by e-mail then +10:37 < pinchartl> dammsan: lovely... +10:38 < dammsan> you might want to get a vaccine if you are not covered already +10:38 < pinchartl> I think I got vaccinated when I was a kid +10:38 < dammsan> our generation of japanese are not fully vaccinated unfortunately +10:38 < dammsan> so it seems to be a bit of a mess +10:39 < dammsan> so i would enjoy seeing you _before_ your okinawa trip +10:39 < geertu> pinchartl: As a Belgian, you should have gotten either the disease, or the vaccine. +10:40 < jmondi> I got vaccinated when I was a kid, but they gave me another shot before I left for thailand +10:40 < pinchartl> dammsan: I'm afraid that would be difficult :-/ +10:41 < dammsan> might be good to be careful +10:41 < jmondi> pinchartl: you may want to ask, they told me the new raccomandation is to have 4 shots not just 3 as it used to +10:41 < dammsan> pinchartl: yeah +10:41 < pinchartl> as I'll land on the 30th in the morning in Narita and leave from Haneda on the same day in the afternoon +10:41 < jmondi> ofc you'll be autistic after that according to novax.info and other reliable sources +10:42 < dammsan> pinchartl: maybe we can meet at haneda? +10:42 < geertu> jmondi: Only 2 shots for my kids, according to their vaccination card. +10:42 < dammsan> anyway lets discuss later +10:42 < pinchartl> dammsan: :-) +10:42 < pinchartl> so neg is absent +10:42 < pinchartl> let's move on +10:43 < pinchartl> Topic 2. BSP Team Requests +10:43 < pinchartl> - kms-test-brxalloc.py failures +10:43 < pinchartl> The test team noticed that kms-test-brxalloc.py failed. The problem has been reported to Laurent who only came back from holidays yesterday. It will be investigated this week. +10:44 < pinchartl> morimoto: is that ok ? +10:44 < morimoto> Not yet OK. Is this kernel .config settings ? +10:44 < morimoto> Ahh.. sorry. +10:45 < morimoto> OK, please report to me +10:45 < pinchartl> sure :-) +10:45 < pinchartl> that's all I have for questions from the BSP team, anything else ? +10:45 < morimoto> Other questions are already solved. thank you for your help M/M member +10:46 < pinchartl> you're welcome +10:47 < pinchartl> Topic 3. Discussions +10:47 < pinchartl> dammsan: you wanted to discuss IPMMU ? +10:48 < dammsan> right, sorry for the delay +10:48 < dammsan> i noticed a topic branch in latest renesas-drivers +10:49 < pinchartl> yes ? +10:50 < dammsan> drm-du-iommu-v1-20171115 +10:50 < dammsan> i was wondering if there is any special target date for this one? +10:50 < dammsan> for upstream merge i mean +10:51 < pinchartl> let me have a look +10:51 < dammsan> thanks +10:51 < dammsan> just wanted to ping you about it if you had forgotten =) +10:51 < pinchartl> no there isn't. Daniel Vetter has pushed back on my proposal, I have to either convince him, or come up with a different implementation +10:52 < pinchartl> it's part of the backlog I need to handle +10:52 < dammsan> ok no stress +10:52 < pinchartl> I've decided to focus on review first in order to avoid blocking other people's backlogs :-) +10:52 < dammsan> slow and steady +10:52 < dammsan> sounds good +10:53 < dammsan> thanks +10:53 < pinchartl> you're welcome +10:53 < dammsan> and i wonder about vin for r-car gen3 +10:53 < dammsan> niklas is carrying a pretty heavy burden it seems to me +10:54 < pinchartl> we should ask Niklas, but as far as I know it will be merged in v4.18-rc1 +10:54 < dammsan> that would be good +10:55 < pinchartl> any other question ? +10:55 < dammsan> it almost looks like the ipmmu will be free of errata before vin gets support upstream =) +10:55 < pinchartl> :-D +10:55 < dammsan> (obviously a joke) +10:56 < dammsan> apart from that nothing special from my side +10:57 < pinchartl> if there's no other question +10:57 < pinchartl> Topic 4. Additional Tasks for 2018 Q2 +10:57 < pinchartl> dammsan: have all additional tasks for Q2/1 been submitted ? +10:58 < dammsan> yes and no +10:58 < pinchartl> I like the yes part of that answer +10:58 < dammsan> paper work for jacopo has one final step that will happen tomorrow +10:58 < dammsan> and i have not seen any signed document from your side either =) +10:59 < dammsan> but apart from that we're good +10:59 < pinchartl> but no blocker ? +10:59 < dammsan> no blocker +10:59 < pinchartl> I was on holidays, hence the lack of signature :-) +10:59 < pinchartl> for Q2/2 +10:59 < dammsan> i was waiting for papers myself too +10:59 < pinchartl> we have the following candidates +10:59 < pinchartl> - Jacopo: VIN scaler (UDS) +10:59 < pinchartl> - Kieran: DMA virtualization +10:59 < pinchartl> - Laurent: Display virtualization performance improvements +10:59 < pinchartl> - Niklas: VIN and CSI-2 power management +10:59 < pinchartl> - Ulrich: DU LVDS dual-link mode, DU LVDS PLL and DU DPLL fixes +10:59 < pinchartl> we need to estimate the effort +11:00 < dammsan> from my side +11:00 < pinchartl> but it's already known that VIN scaler would take more than 5 days, which is the budget available for Q2/2 for Jacopo +11:00 < dammsan> i think the virtualization bits are important +11:00 < pinchartl> that's why I've included them :-) +11:00 < dammsan> but the rest smells like best effort base task activity in my mind +11:00 < pinchartl> what's the different between base and additional from that point of view ? +11:01 < pinchartl> I mean, any work could be done under either umbrella +11:01 < dammsan> i don't want to order more VIN stuff when things are not in upstream yet +11:01 < dammsan> to give you time to focus on getting that sorted +11:01 < dammsan> only paper work is teh difference +11:02 < pinchartl> that at least matches my understanding :-) +11:02 < pinchartl> regarding VIN +11:02 < pinchartl> a pull request has been submitted to Mauro +11:02 < pinchartl> so Gen3 support will be in v4.18-rc1 +11:03 < dammsan> sounds good +11:03 < dammsan> i guess batch 1 additional adds on top of that perhaps +11:03 < pinchartl> https://www.spinics.net/lists/linux-media/msg132192.html +11:03 < pinchartl> it was sent on Monday +11:03 < pinchartl> I expect it to be merged in the very near future +11:04 < pinchartl> so I don't think it would block VIN development for Q2/2 +11:05 < dammsan> well, i think we've been carrying VIN for quite a few kernel versions +11:05 < pinchartl> yes, and now it's going upstream :-) +11:05 < dammsan> i'm currently in the "i believe it when i see it" mode +11:06 < pinchartl> that's why I pasted +11:06 < pinchartl> https://www.spinics.net/lists/linux-media/msg132192.html +11:06 < dammsan> excellent - looking forward to that! +11:06 < pinchartl> :-) +11:07 < dammsan> that's good +11:07 < dammsan> so at this point i'm inclined to move forward with the virtualization tasks for you and kieran +11:07 < dammsan> i am hoping that ulrich can do some early memory autodetection hacking +11:08 < dammsan> but i'm yet to hear back from him +11:08 < pinchartl> early memory autodetection ? +11:08 < dammsan> that would take care of all members with larger additional task pools +11:08 < dammsan> yeah some packages for R-Car Gen3 come with more memory mounted +11:08 < dammsan> BSP team is busy +11:09 < dammsan> shooting themselves in the foot by duplicating DTS +11:09 < dammsan> lets see how much time he needs for the memory stuff +11:09 < pinchartl> detection in U-Boot with automatic .dtb updates ? +11:09 < dammsan> yeah something like that +11:10 < dammsan> maybe board/package specific ATF +11:10 < dammsan> and read-only memory controller configuration +11:10 < dammsan> and some magic in u-boot to populate the memory nodes during runtime +11:10 < pinchartl> ok, if it's in U-Boot it sounds good to me +11:10 < dammsan> first a prototype for ulrich +11:10 < dammsan> and if it works out well then we will involve marek and perhaps otehrs +11:12 < geertu> dammsan: U-Boot already does the /memory population magic +11:12 < pinchartl> ok, so I'll put the DU tasks on hold +11:12 < dammsan> geertu: that's good - i guess we just need to learn how to detect +11:13 < geertu> dammsan: Indeed +11:13 < dammsan> geertu: and perhaps strip away some nodes from upstream DTS at some point later on if needed +11:13 < pinchartl> last topic +11:13 < pinchartl> Topic 5. Next Meeting +11:13 < pinchartl> The next meeting will be held three weeks from now, on Wednesday 2018-05-09 at +11:13 < pinchartl> 09:00 BST / 10:00 CEST / 11:00 EEST / 17:00 JST as a combined meeting with the +11:13 < pinchartl> Core and I/O groups. +11:13 < pinchartl> Please note that this it the time of the multimedia portion of the meeting, +11:13 < pinchartl> the I/O and core portions will start an hour earlier: +11:13 < pinchartl> I/O: 08:00 BST / 09:00 CEST / 10:00 EEST / 16:00 JST +11:13 < pinchartl> Core: 08:30 BST / 09:30 CEST / 10:30 EEST / 16:30 JST +11:13 < pinchartl> MM: 09:00 BST / 10:00 CEST / 11:00 EEST / 17:00 JST +11:13 < pinchartl> I will very likely not be able to join the meeting, in which case I will appoint a deputy. +11:13 < geertu> dammsan: Nah, Xen has already learned to ignore duplicate memory blocks ;-) +11:14 < dammsan> sounds good +11:14 < dammsan> geertu: yum +11:15 < pinchartl> that's all I have for today +11:15 < pinchartl> any other question ? +11:15 < dammsan> don't eat too much goya shampure in okinawa =) +11:16 < pinchartl> what is that ? +11:17 < dammsan> guya is the bitter cucumber thing +11:17 < shimoda> maybe Goya Chample? +11:17 < dammsan> shampure is like pad thai +11:17 < shimoda> ゴーヤチャンプル +11:17 < pinchartl> ah that :-) +11:18 < dammsan> anyway, enjoy your time off! +11:18 < pinchartl> I will +11:18 < pinchartl> thank you all for attending the meeting today diff --git a/wiki/Chat_log/20180509-core-chatlog b/wiki/Chat_log/20180509-core-chatlog new file mode 100644 index 0000000..dc9a99a --- /dev/null +++ b/wiki/Chat_log/20180509-core-chatlog @@ -0,0 +1,189 @@ +Core-chat-meeting-2018-05-09 + +09:37 < geertu> Welcome to today's Core Group Chat! +09:37 < geertu> Agenda: +09:37 < geertu> 1. Status Updates +09:37 < geertu> 2. Discussion Topics +09:37 < geertu> a. New U-Boot on R-Car Gen2 changes the FLASH layout. +09:37 < geertu> b. [PATCH/RFC] ARM: shmobile: defconfig: Enable LPAE +09:37 < geertu> (https://www.spinics.net/lists/arm-kernel/msg648585.html) +09:37 < geertu> Topic 1. Status updates +09:37 < geertu> Marek worked on U-Boot (R8A7792 DT clock driver, cleanups, pre-release +09:37 < geertu> testing). +09:37 < geertu> Morimoto-san enjoyed GW, worked on DMAC error handling for +09:37 < geertu> virtualization, and is working on a new tool "periject". +09:37 < geertu> Niklas replaced hardcoded SYSC numbers for M3-N, and helped to fix +09:37 < geertu> hickups on dual-CPU systems. +09:37 < geertu> Shimoda-san resubmitted clk and dts[i] support for R-Car E3, enabled +09:37 < geertu> usb2.0 ch3 dts on H3 ES2.0, and updated IPMMU material. +09:37 < geertu> Simon posted some misc enablement and cleanup patches. +09:37 < geertu> Geert reposted BD9571 DDR Backup Mode, made rcar-gpio interrupts work on +09:37 < geertu> qemu+kvm, enabled the PMU on R-Car Gen2, RZ/A1, and RZ/G1, and updated +09:37 < geertu> periupport for v4.17-rc4. +09:38 < geertu> B) What we plan to do till next time: +09:38 < geertu> Kaneko-san will upport M3-N WDT support. +09:38 < geertu> Marek will continue working on U-Boot (new DM/DT capable I2C driver, and +09:38 < geertu> E3 Ebisu support). +09:38 < geertu> Morimoto-san will design the new "periject" tool. +09:38 < geertu> Shimoda-san will update rcar-sysc for R-Car E3, and pave the way forward +09:38 < geertu> for IPMMU. +09:38 < geertu> Geert will send clk and pfc pull requests for v4.18, do periupport +09:38 < geertu> analysis and upporting, and handle CPG/MSSR and SYSC errata. +09:39 < geertu> C) Problems we have currently: +09:39 < geertu> Morimoto-san wants to know each member's opinion about periject. +09:39 < geertu> --- +09:39 < geertu> Anything I missed? +09:40 < geertu> Topic 2. Discussion Topics +09:40 < geertu> a. New U-Boot on R-Car Gen2 changes the FLASH layout. +09:41 < geertu> Unfortunately Marek is at the dentist. +09:41 < Marex> not yet +09:41 < Marex> but almost +09:41 < geertu> OK ;-) +09:41 < Marex> so yeah, thoughts ? +09:41 < geertu> But the issue is that the new and improved U-Boot for R-Car Gen2 needs more space in FLASH ROM than allowed by the current partitioning in DT +09:42 < geertu> Hence the partitioning should be changed to accomodate that. +09:43 < Marex> yes +09:44 < geertu> Marex: I assume this is for the "loader" partition? +09:44 < dammsan> as long as it is documented on a public wiki i am alright with that +09:44 < geertu> It seems most boards use 256 KiB for loader +09:45 < geertu> But Koelsch and Stout use 512 KiB +09:45 < geertu> Ah, Stout calls the partitions loader/uboot/uboot-env/flash +09:45 < Marex> sec +09:45 < geertu> All others use loader/user/flash +09:46 < Marex> https://elinux.org/R-Car/Boards/U-Boot-Gen2 +09:46 < Marex> see at the end +09:46 < Marex> "Flashing U-Boot" +09:48 < Marex> I would say we reserve the first 0x200000 bytes for U-Boot and go with that, if we decide to change flash layout +09:48 < dammsan> thanks - looking good +09:48 < neg> Marex: I like the ip address 'tftp 0x50000000 192.168.1.300:u-boot-spl.bin' :-) +09:48 < Marex> the original layout had 0x40000 bytes for U-Boot , which 0x40000 for the SPI loader (of which 16 kiB were used, but due to SPI NOR erase size of 64 kiB, that's what it is) and then used 8 bytes from another 64 kiB sector +09:49 < Marex> what I would like to have is even an improvement of what's in the wiki +09:49 < geertu> neg: Copied from a movie? +09:49 < Marex> first 64 KiB for U-Boot SPL, then four sectors for env , spare sector for env , redundant env , spare sector for redundant env and then three sectors for U-Boot +09:49 < geertu> neg: Does it crash U-Boot? +09:50 < Marex> that should be future-proof enough +09:50 < geertu> What's "redundant env"? +09:50 < wsa_> gotta run, cya guys! +09:50 -!- wsa_ [~wsa@p54B334D6.dip0.t-ipconnect.de] has quit [Quit: ...] +09:50 < Marex> geertu: another copy of env, in case the first copy gets corrupted +09:50 < geertu> Changing the partitioning in upstream DTS means that we do break anyone who has stored real data in his FLASH +09:51 < geertu> sector=64KiB? +09:51 < Marex> geertu: yes, if they update bootloader now, they should also update the layout +09:51 < Marex> yes +09:51 < dammsan> hm.. +09:51 < Marex> and we can pass that layout through the kernel command like via mtdparts= +09:51 < dammsan> wouldn't it make sense if U-Boot could pass the layout to the kernel? +09:51 < geertu> Marex: If they don't update U-Boot, but fetch tomorrow's upstream, their data is inaccessible, too +09:51 < Marex> yes, and remove it from DT +09:52 < dammsan> seems inline with the memory detection topic +09:52 < geertu> Having to remember to pass mtdparts= all the time is cumbersome. +09:52 < Marex> geertu: er, sector = 256 kiB on that flash, not 64 kiB +09:53 < geertu> And will lead to someone overwriting his/her boot loader when doing a FLASH test on Linux +09:53 < dammsan> oh, so no runtime patching like with memory nodes? +09:53 < Marex> flash partitioning isn't a HW property, so why would it be in DT ? +09:53 < dammsan> manually passing it seems cumbersome +09:53 < Marex> geertu: you can set bootargs to contain mtdparts +09:53 < geertu> dammsan: How to detect partitioning without a partition table on the medium? +09:54 < geertu> Marex: "four sectors for env" = 4 x 256 KiB = 1 MiB? +09:54 < dammsan> u-boot needs to be aware of it, so it can share this information? +09:54 < Marex> geertu: yes +09:54 < Marex> geertu: you cannot get below that with redundant env and spare sectors +09:55 < dammsan> obviously if we had a partition table that might be helpful with all the different boot stack components +09:55 < geertu> Marex: OK, I don't have anything large and valuable stored in that FLASH +09:55 < Marex> dammsan: U-Boot can be made aware of it and it can pass that information, sure +09:56 < dammsan> geertu: what do you think? +09:56 < geertu> dammsan: I think partition info in DTS is fragile +09:56 < dammsan> for sure +09:56 < dammsan> so where to put it? +09:57 < geertu> While even you don't really use the FLASH, you do want to have the partition info, so you can run a FLASH test on Linux (read-only everywhere, write to all but the boot loader partition) +09:57 < Marex> mtdparts on kernel command line ? +09:57 < geertu> s/even/even if/ +09:57 < Marex> with the first 1 MiB marked ro ? +09:58 < geertu> Marex: That's not sufficiently safe, IMHO +09:58 < dammsan> makes sense +09:58 < geertu> First MiB marked ro sounds good to me +09:58 < geertu> Marex: I mean that I regularly boot kernels with +09:58 < geertu> CONFIG_CMDLINE="ignore_loglevel root=/dev/ram" +09:59 < geertu> CONFIG_CMDLINE_FORCE=y +09:59 < geertu> (for using initrd on remote boards) +09:59 < dammsan> i suppose there is no way we can store a partition table somewhere? +09:59 < dammsan> one physical sector minimum per copy, 2 copies +09:59 < geertu> So the partition info must be stored in the board-spcific part +09:59 < geertu> dammsan: yes we can. +10:00 < dammsan> since it is a runtime configuration item it makes sense to separate that from DTS +10:00 < geertu> dammsan: We do have the SPI loader in the first 16KiB, but some partitioning schemes can have the part table elsewhere (not at the start of the device_ +10:00 < dammsan> aligning to the end of the flash? +10:01 < geertu> E.g. Amiga RDB can be anywhere in the first 2 cylinders (yeah, legacy naming) +10:01 < dammsan> must be possible to probe for the size somehow +10:02 < geertu> Size is known from FLASH type (even SPI NOR autoprobing) +10:02 < dammsan> ok +10:02 < dammsan> so either at the end or using some offset +10:03 < dammsan> if we are inconveniently disturbing the users with a partition chance +10:03 < dammsan> change i mean +10:03 < dammsan> then we may as well go all the way? +10:03 < geertu> Yep +10:03 < dammsan> or am i being overly difficulat as usual =) +10:03 < dammsan> probably =) +10:04 < geertu> No, if you do it wrong, the board needs JTAG rescue +10:04 < geertu> Better safe than sorry +10:04 < geertu> Next topic? +10:04 < dammsan> yeah so doing a generation jump with several features at once is probably good +10:04 < geertu> b. [PATCH/RFC] ARM: shmobile: defconfig: Enable LPAE +10:04 < geertu> (https://www.spinics.net/lists/arm-kernel/msg648585.html) +10:05 < dammsan> i think for 32-bit arm we need two configs +10:05 < dammsan> if we should bother about lpae +10:05 < horms> This is not the first time this has come up +10:05 < geertu> The RZ/G1 crew wants to have LPAE enabled, but that's incompatible with older SoCss +10:05 < geertu> Indeed, multi_v7_defconfig also doesn't have LPAE because of that +10:05 < Marex> geertu: so what is the decision ? +10:05 < horms> The last time, iirc, the answer was it'll all be awesome with fragments +10:05 < horms> but I guess fragments never got committed to mainline +10:05 < Marex> geertu: U-Boot generally uses mtdparts and I dont think it supports any of this partitioning stuff in flash ... +10:06 < geertu> Marex: On-FLASH partition table? +10:06 < Marex> geertu: I see, I don't think U-Boot supports it, so I'd have to check how that can be added +10:06 < dammsan> Marek: please +10:07 < geertu> horms: kernel/configs/ has some fragments +10:07 < horms> ok, can we add an lpae fragment? +10:07 < Marex> geertu: also, noone really uses that sort of thing, the systems I am aware of all use mtdparts passing on the kernel command line +10:07 < horms> would that solve the problem? +10:07 < horms> would it be more than one line long? +10:07 < geertu> I guess so, and Arnd will be happy, too, if it can be used with e.g. multi_v7_defconfig, too +10:07 < Marex> geertu: I guess we can have our special solution though +10:07 < Marex> dammsan: yes ? +10:08 < geertu> Marex: From one side, if everybody else uses mtdparts, I thinkl we should use it, too. +10:08 < dammsan> Marex: seems both geertu and i like the idea of on-flash partition table +10:08 < horms> geertu: ok, then I suggest we try that. I could make a patch and the RZ/G guys could test it. +10:08 < geertu> But there are too many use cases for kernels that cannot receive bootargs from U-Boot (uImage/zImage with appeneded DTB, CONFIG_CMDLINE_FORCE, ...) +10:09 < Marex> dammsan: then again, everyone else uses mtdparts and I have yet to see a recent system with on-flash partition table +10:09 < dammsan> sure +10:10 < dammsan> just feels like a sane thing to move towards +10:10 < dammsan> but the offset for the partition table needs to be described somewhere +10:10 < geertu> Given the SPI loader is 16 KiB, but the block size is 64 KiB, you have 48 KiB for partitioning? +10:10 < dammsan> both for U-Boot and Linux +10:11 < dammsan> geertu: we probably want dedicated physical sectors? +10:11 < dammsan> to be more fail safe +10:11 < geertu> dammsan: That's safer, yes +10:11 < Marex> dammsan: it wastes another sector of the SPI NOR too +10:11 < Marex> dammsan: while if it's in mtdparts, it could be stored alongside the other U-Boot environment +10:12 < dammsan> true +10:12 < dammsan> not having it in DTS must be good at least +10:12 < dammsan> we can agree on that +10:12 < Marex> and you can adjust it in U-Boot with setenv mtdparts instead of having a custom solution in some sector with custom command to set it up +10:12 < Marex> yes, it doesn't describe hardware, it shouldn't be in DT +10:12 < dammsan> sure makes sense +10:13 < dammsan> so how to move forward? +10:14 < dammsan> 1. remove DTS partion info from upstream +10:14 < Marex> I think U-Boot could be tweaked to pass mtdparts via bootargs automatically, which would solve geerts's problem with custom bootargs without mtdparts ? +10:14 < geertu> Marex: Nope, U-Boot cannot pass bootargs with uImage/zImage with appeneded DTB, or CONFIG_CMDLINE_FORCE +10:14 < dammsan> geertu: i understand your problem +10:15 < Marex> geertu: assume mainline U-Boot, which yes, can, if you don't use the uImage/zImage hack +10:15 < dammsan> but would on-flash partition help in such case? +10:15 < geertu> Marex: uImage/zImage with appeneded DTB is indeed mainly a workaround for old U-Boot +10:15 < geertu> Marex: CONFIG_CMDLINE_FORCE is a workaround for people changing bootargs on shared boards in a farm +10:16 < geertu> Although I could just add a "setenv bootargs" to my scripts +10:16 < geertu> Anyway, we ran out of time (no pinchartl to kick us out ;-) +10:17 * Marex gotta run too to make it for the train +10:18 < geertu> Anything else to discuss? +10:18 < dammsan> not from my side at this point +10:18 < neg> Not from me but the flash layout discussion was educational :-) +10:19 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20180509-io-chatlog b/wiki/Chat_log/20180509-io-chatlog new file mode 100644 index 0000000..6752037 --- /dev/null +++ b/wiki/Chat_log/20180509-io-chatlog @@ -0,0 +1,144 @@ +09:03 < wsa_> welcome to this io meeting +09:03 -!- morimoto [~user@relprex3.renesas.com] has joined #periperi +09:03 < wsa_> agenda will be status updates and open questions +09:04 < wsa_> here are my collected status updates: +09:04 < wsa_> A - what have I done since last time +09:04 < wsa_> ------------------------------------ +09:04 < wsa_> Geert +09:04 < wsa_> : updated the Gen2 watchdog blacklist +09:04 < wsa_> Kaneko-san +09:04 < wsa_> : posted series for M3-N SDHI support +09:04 < wsa_> Niklas +09:04 < wsa_> : got most thermal patches merged, did M3-N I2C enablement +09:04 < wsa_> Shimoda-san +09:04 < wsa_> : got upstream feedback about USB role switch, debugged suspend/resume issue +09:04 < wsa_> Simon +09:04 < wsa_> : sent out some DTS and defconfig patches +09:04 < wsa_> Ulrich +09:04 < wsa_> : checked BSP patch about RPM with SCIF +09:04 < wsa_> Wolfram +09:04 < wsa_> : started upstream discussions about I2C core PM and MMC/SD fallback for highspeed modes, +09:04 < wsa_> sent out patches for I2C PM & M3-N WDT & EEPROMs on Gen3 + Alt & documentation for i2c-rcar, +09:04 < wsa_> analyzed and reported back a breakage of a BSP patch for i2c-rcar, discussed periject, tested +09:04 < wsa_> M3-N SDHI, and sent out two tree-wide cleanup series +09:04 < wsa_> B - what I want to do until next time +09:04 < wsa_> ------------------------------------- +09:04 < wsa_> Kaneko-san +09:04 < wsa_> : wants to send next version of D3 thermal series and M3-N SDHI support +09:04 < wsa_> Niklas +09:04 < wsa_> : wants to resume SDHI upporting work +09:04 < wsa_> Shimoda-san +09:04 < wsa_> : wants to keep at the USB role switch topic, continue with the suspend/resume issue, and implement +09:04 < wsa_> PHY GPIO support for E3 as well as Ethernet support for E3 +09:04 < wsa_> Simon +09:04 < wsa_> : wants to continue HS400 support, follow up on RAVB upporting, and update QEMU performance testing report +09:04 < wsa_> Ulrich +09:04 < wsa_> : wants to ask BSP team about the SCIF patch +09:04 < wsa_> Wolfram +09:04 < wsa_> : wants to keep up with the started discussions, do more BSP upporting, implement QEMU VIRTIO +09:04 < wsa_> passthrough for I2C clients +09:04 < wsa_> C - problems I currently have +09:04 < wsa_> ----------------------------- +09:04 < wsa_> Niklas: +09:04 < wsa_> : lagged with SDHI work because of other stuff, still needs HW for Gen3 thermal fuses +09:04 < wsa_> Ulrich: +09:04 < wsa_> : needs decision how to handle DMA for SCIF2 on Gen3 +09:04 < wsa_> Wolfram +09:04 < wsa_> : couldn't find a non-VIRTIO solution for QEMU I2C passthrough because of the a-priori-knowledge problem +09:04 < wsa_> Please let me know if I missed / misinterpreted something +09:05 < wsa_> About I2C on M3-N, it seems we need conflict management here ;) +09:06 < wsa_> Niklas did it already because he needed it for MM work, but it was scheduled for Kaneko-san +09:06 < wsa_> However, there seems to be more testing missing +09:06 < geertu> wsa_: Same for M3-N WDT? +09:07 < neg> I'm happy to drop my patches as long as M3-N I2C4 are in next renesas-drivers ;-) +09:07 < wsa_> horms: did Kaneko-san already starte with I2C on M3-N? +09:07 < horms> wsa_: I asked him to but I doubt he has +09:08 < horms> likewise for WDT +09:08 < horms> the usual pattern is that I ping him after these meetings and magically patches appear +09:09 < horms> So how about I ask Kaneko-san to handle WDT and drop I2C? +09:09 < wsa_> so, maybe Niklas can post the patches as RFT and Kaneko-san can review/test them? Do you think this would work? +09:09 < geertu> Testing patches is always a good thing to do... +09:11 < horms> wsa_: well, the testing-arm of the Kaneko-san operation is me. but yes, that sounds like a good plan +09:11 < wsa_> about WDT: I only sent out the bindings, but didn't update the DTS etc... +09:11 < wsa_> or did someone do this and I missed it? +09:12 < wsa_> neg: can you post the patch as RFT then? +09:12 < horms> WDT: How about I check and task Kaneko-san with doing whatever is missing +09:12 < neg> wsa_: will do +09:12 < wsa_> horms: perfect +09:13 < wsa_> about the SCIF2 DMA issue +09:13 < wsa_> that came up before, no? +09:13 < wsa_> I think we know it is there but it is not official +09:14 < geertu> I've justed checked rev 1.00 +09:14 < geertu> SCIF2 exists in the SCIF section +09:14 < uli___> so it officially exists now? +09:14 < geertu> SCIF2 interrupt is now documented as SCIF2 (I think it wasn't in some older rev) +09:14 < geertu> SCIF2 module clock is now documented as SCIF2 (I think it wasn't in some older rev) +09:15 < geertu> SCIF2 DMA is not documented. +09:15 < geertu> Note that the interrupt, module clock, and DMA channel numbers are "odd", and may related to another undocumented module (irda?) +09:16 < wsa_> but it does work as a SCIF? +09:16 < geertu> IIRC, in the first rev SCIF2 didn't exist at all, but it obviously works, as it's the consle +09:16 < geertu> s/consle/console/ +09:16 < wsa_> that answers :) +09:17 < wsa_> well, let's stick to the documentation I'd say +09:17 < geertu> And DMA works, too. It doesn't work when you use the "expected" (check the holes in the datasheet) DMA channel numbers +09:17 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi +09:17 -!- horms_ [~horms@a80-127-179-77.adsl.xs4all.nl] has joined #periperi +09:18 -!- horms [~horms@2001:982:756:1:c685:8ff:fe7c:9971] has quit Quit: Leaving +09:18 -!- horms_ is now known as horms +09:18 < wsa_> uli___: so, I'd think no DMA for SCIF2 as of nwo +09:18 < wsa_> now +09:18 < geertu> Note: With "exist" I mean "documented" +09:19 < geertu> We have it enabled, and it works? +09:19 < geertu> on H3 +09:19 < geertu> not yet on M3-W (but I have it enabled in my local tree since the beginning) +09:20 < uli___> it's enabled on d3 as well, iirc +09:20 < geertu> Yep, D3 too +09:20 < wsa_> I currently get a number of requests from Renesas to make the drivers work like the documentation says +09:20 < wsa_> although they work as is +09:21 < wsa_> and having witnessed some safety workshops recently I know there are people taking care of using only documented things :) +09:22 < wsa_> we can ask why this is not documented +09:22 < horms> So the idea is to implement the driver as per the documentation. Does this usually not change the observed behaviour of the driver? +09:22 < wsa_> it sometimes does +09:23 < wsa_> I will have this discussion with the BSP team about the patch breaking REP_START on I2C +09:23 < wsa_> It will be interesting +09:23 < wsa_> I assume there can be exceptions to the rule +09:24 < wsa_> but not mentioning DMA channels is trivial, or? +09:25 < wsa_> or even better: +09:25 < wsa_> ask the HW team if we can use it in upstream kernels +09:26 < wsa_> and if so, add a comment where we got this add. information +09:27 < wsa_> uli___: can you do that? +09:27 < geertu> I think it was documented as the irda DMA channel in early datasheets +09:27 < uli___> so we leave the dmas in, but document that they are undocumented? +09:27 < wsa_> we ask the HW team if we can use these DMA channels in upstream which "work for us" +09:28 < uli___> ah, ok +09:28 < wsa_> although undocumented +09:28 < wsa_> and let's see what they say +09:28 < uli___> yes, i can do that +09:28 < wsa_> thx +09:29 < wsa_> short about SDHI +09:30 < wsa_> horms: about the core changes, I was hoping for Ulf to comment +09:30 < wsa_> I can have another look but I am not sure I can add much +09:30 < wsa_> I'd like to know Ulf's opinion because he knows way more MMC hardware +09:30 < horms> Ok, maybe I can ping him +09:31 < horms> I understand he wants us to use hooks +09:31 < wsa_> yes, please try +09:31 < horms> But as you can see from the patch I found the existing hooks inadequate +09:31 < horms> And then found myself guessing how he would like new hooks to look +09:31 < horms> Ok, will do +09:32 < wsa_> in general, what neg said is true for SDHI in general: it is a bit lagging; for me, too, since I did majorly I2C the last period +09:32 < horms> I think we can upstream M3-N (non HS400) SDHI support sooner than later, do you agree? +09:32 < wsa_> horms: certainly +09:33 < wsa_> so maybe we all can give it some more love in the next period (me included) +09:34 < horms> agreed +09:34 < wsa_> so, one more little wish: if you are on holidays, please mark it in the B) section of your report +09:34 < horms> by next period do you mean between now and the next meeting? +09:34 < wsa_> then i know better where to find it +09:34 < wsa_> horms: yes +09:35 < wsa_> for now ;) +09:35 < wsa_> it will need more love in general +09:35 < wsa_> this was it from my side, any topics from your side? +09:36 < wsa_> nope +09:36 < wsa_> geertu: then, I'll hand over to you +09:36 < wsa_> Thanks for this meeting! +09:37 < geertu> wsa_: Thanks! +09:37 < wsa_> enjoy the rest of the day diff --git a/wiki/Chat_log/20180509-mm-chatlog b/wiki/Chat_log/20180509-mm-chatlog new file mode 100644 index 0000000..a74ce94 --- /dev/null +++ b/wiki/Chat_log/20180509-mm-chatlog @@ -0,0 +1,169 @@ +Multimedia-chat-meeting-2018-05-09 + +<geertu> kbingham: Wake up! +<uli___> kbingham[m]: ^ +<geertu> MultiMedia is in (cryogenic?) stasis... [17:20] +<neg> Maybe he is on some odd none EU timezone ;-) In the meantime shall we do + status reports individually in name order (jmondi, kbingham, morimoto, + neg, uli___ )? +<jmondi> neg: fine with me [17:21] +<jmondi> even if I guess, the important part is collecting it, more than + re-writing here what we reported by email +<jmondi> I can start though +<jmondi> - DRM bridge format support [PATCH 0/8] drm: bridge: Add support for + static image formats HAve to really look into comments, unfortunately + seems like we opened pandora's box of bridges lifetime management. + [17:22] +<jmondi> - MT9T111 media: i2c: mt9t112: Add OF tree support[3~ +<jmondi> - Gen-3 VIN parallel support on D3 [17:23] +<jmondi> capture now sort-of-wroking on v4.16 -> v4.17 has severe issues with + memory corruption while capturing +<jmondi> Until next time) +<jmondi> - Complete VIN parallel support (due date 5/M) [17:24] +<jmondi> - Re-tackle the bridges issues +<jmondi> - Have MT9T111 capture working on peach, so I can integrate it on + Armadillo +<jmondi> - soc_camera removal +<jmondi> Problems I have now) +<jmondi> - Capturing on v4.17 is very fragile +<jmondi> --eot-- +<neg> soc_camera removal \o/ [17:25] +<jmondi> neg: slow down, it's the third time in a row that it gets post-poned + to "until next time" [17:26] +<jmondi> is very low priority +<neg> morimoto: do you have status update for MM? [17:28] +<morimoto> OK +<morimoto> A) What have I done since last time +<marex-cloud> geertu: not bootargs to your scripts, but mtdparts to your + bootargs, which you are clearly passing already ... btw we can + continue the discussion in #perimtd if you want ( dammsan too ) +<morimoto> IRQ +<morimoto> OK, continue [17:29] +<morimoto> - Enjoyed GW ! +<morimoto> - DMAC driver error handling fixup +<morimoto> # Current DMAC driver is sharing error IRQ for all channels, +<morimoto> # but, it will be issue if we uses Virtual Machine, Multi OS, etc. +<morimoto> # We can handle it on each channel's IRQ handler +<morimoto> - Considering new PeriPeri tool (= periupport + peripelist = + "periject") +<morimoto> - Posted ALSA SoC cleanup patches final step +<morimoto> B) What I plan to do till next time +<morimoto> - Consider periject design +<morimoto> C) Problems I have currently +<morimoto> - I want to know each member's opinion about periject. +<morimoto> but on-email is very OK +<morimoto> -- EOF -- +<shimoda> sorry, i have to go home. bye! [17:30] +*** shimoda (~shimoda@relprex3.renesas.com) has quit: Quit: WeeChat 0.4.2 +<morimoto> any question ? +<morimoto> if no, next is neg +<neg> So far I like the name periject :-) +<neg> thanks +<neg> rcar_csi2_write(priv, PHYCNT_REG, PHYCNT_RSTZ); +<neg> rcar_csi2_write(priv, PHTC_REG, PHTC_TESTCLR); [17:31] +<neg> wops +<neg> A) +<neg> - Posted and got merged second batch of VIN enhancement patches. +<neg> - VIN M3-N done. +<neg> - Rework CSI-2 based on datasheet v1.0, new patches pending. +<neg> - Investigated ADV748x behavior of AFE pixel clock. +<neg> B) +<neg> - More CSI-2 work +<neg> - Post next batch of VIN patches that piled up prior to Gen3 merger. + [17:32] +<neg> - Post fix for ADV748x +<neg> - Post prototype for v4l2-subdev video standard control +<neg> C) +* geertu joined #perimtd +<neg> - CSI-2 rework will maybe make it too late for v4.18 :-( +<neg> -- eot -- +<neg> if no questions please go a head uli___ [17:33] +<uli___> A) +<uli___> MM: wikified the instructions for running the IGT test suite +<uli___> (https://elinux.org/R-Car/Tests:igt) +<uli___> MM: rebasing IGT DU fixes, WIP +<uli___> MM: adding DU support to D3, WIP +<uli___> B) [17:34] +<uli___> MM: finish DU on D3 +<uli___> MM: send a new IGT DU fix series +<uli___> C) +<uli___> none +<uli___> correction: C) copy-and-paste doesn't work very well in xfce terminal +<uli___> that's it [17:35] +<neg> thanks, out of curiosity is there any DU work for M3-N in the pipeline? +<uli___> not from me [17:36] +<jmondi> neg: I think Kieran was about to work on that +<neg> jmondi: ok thanks I'm just curious [17:37] +<neg> anything else we need to discuss for MM, I had counted on kbingham to + handle this so I have nothng prepared but have not read all status mails + in detail if there where any open questions +<morimoto> I have nothing [17:39] +<jmondi> neg: I only have the issues with v4.17 capture not working +<uli___> none here +<geertu> neg: [PATCH v2 00/11] r8a77965: M3-N DU Enablement +<jmondi> but actually v4.16 behaves the same, I'm finding out as we speak +<neg> geertu: thanks how could I miss that, I need a beter interface to gmane + archive I keep missing patches [17:40] +<uli___> jmondi: how exactly does it not work? [17:41] +<jmondi> uli___: by 'randomly' hangs the CPU while capture operations is + starting [17:42] +<jmondi> uli___: yesterday Niklas suggested that power cyclcing the board + would help as it may be some v4.17 memory corruption issue + [17:43] +<kbingham> ?? +<kbingham> Have I just walked into a meeting that I didn't know was happening + ? +<jmondi> uli___: and it actually did, this morning I re-based on v4.16, first + boot was ok, but now I still need to power cycle to have capture + working +<neg> jmondi: have you nailed it down to know if s_stream() have been called + or if it's the set_fmt() that is the last v4l2 callback? [17:44] +<morimoto> kbingham: meeting is almost ending stage now :) +<kbingham> morimoto: Oh my ... I'm sorry ! I thought meetings were thursdays! +<jmondi> neg: with strace I see g_fmt being called and that's it +<neg> kbingham: :-) +<jmondi> but I would not trust strace too much to debug these kind of issues +<morimoto> kbingham: :) [17:45] +<neg> jmondi: i think some trace printouts in rcar-vin/rcar-dma.c would be + usefull to know if it's s_stream() or something else cousing the lockup + [17:46] +<jmondi> neg: you see, it is freaking 'random'.. I've been capturing images + for a good 2 hours, rebooted the board, no kernel updates, now it + hangs +<kbingham> neg: M3-N DU should be in renesas-drivers already. [17:47] +<jmondi> neg: I was not correct, I changed the pixel clock polarity between 2 + reboots, I hardly think that can hang the CPU [17:48] +<neg> jmondi: ouch that is bad, I had the impression it always failed on the + second capture attempt by bad +<jmondi> btw, let's tak it offline, I have nothing else for the meeting +<jmondi> neg: no, I made several captures in a row, until I have rebooted the + board [17:49] +<neg> Yes lets keep talking about that later to not hold everyone up :-) +<kbingham> So Shall I post my ABC ... and then that covers the status' :D +<neg> kbingham: please do so if you have it handy :-) [17:50] +<kbingham> Thursday 10th May +<kbingham> +<kbingham> A) What I have done since last time +<kbingham> - M3-N DU Enablement +<kbingham> - Got JTAG working with OpenOCD and Salvator-XS +<kbingham> - TLB-Opimise v7,8,9 +<kbingham> - DU/Interlaced v3, v4 +<kbingham> B) What I will do next +<kbingham> - DMA Virtualisation +<kbingham> C) Any issues I have currently +<kbingham> - None +<kbingham> Ahem ... ignore the first line ... [17:51] +<kbingham> I'll post that to the ML as a late addition +<neg> thanks, I think the last item on the agenda is to pick who will record + the MM log into the format pinchartl usually do and make sure it's sent + out and recorded in the wiki and what else normaly happens with it + [17:52] +<kbingham> neg: I think that was supposed to be me - but I'm not certain I + have all the scrollback ... [17:53] +*** horms (~horms@a80-127-179-77.adsl.xs4all.nl) has quit: Ping timeout: 264 + seconds +<morimoto> neg: I can put it to wiki [17:54] +<morimoto> kbingham: can you create it by using wiki ? +<kbingham> morimoto: Sure :) +<neg> kbingham: I can email you the full scrollback if you need it [17:55] +<kbingham> neg: morimoto: - An e-mail is probably easier thanks diff --git a/wiki/Chat_log/20180524-core-chatlog b/wiki/Chat_log/20180524-core-chatlog new file mode 100644 index 0000000..50e92a7 --- /dev/null +++ b/wiki/Chat_log/20180524-core-chatlog @@ -0,0 +1,190 @@ +Core-chat-meeting-2018-05-24 + +09:31 < geertu> Welcome to today's Core Group Chat! +09:32 < geertu> Agenda: +09:32 < geertu> 1. Status Updates +09:32 < geertu> 2. Discussion Topics +09:32 < geertu> a. Should we implement platform_driver.shutdown() on each device +09:32 < geertu> driver? +09:32 < geertu> Topic 1. Status updates +09:32 < geertu> A) What have we done since last time: +09:32 < geertu> Kaneko-san posted M3-N thermal support v4. +09:32 < geertu> Marek worked on Linux (PCIe and DA9063L support, dropped mtdparts from +09:32 < geertu> DT) and U-Boot (Blanche and I2C DM/DT conversion, PFC cleanups, xHCI +09:32 < geertu> fixes). +09:32 < geertu> Morimoto-san is happily hacking periject. +09:32 < geertu> Niklas added I2C support to M3-N PFC. +09:32 < geertu> Shimoda-san resubmitted E3 SYSC (incl. ES1.0 workaround), and upported +09:32 < geertu> E3 PFC and GPIO support. +09:32 < geertu> Ulrich posted DMAC bindings upports. +09:32 < geertu> Geert did some Periupport analysis and upporting, sent clk/pfc pull +09:32 < geertu> requests, assisted Gilad with H3 CryptoCell support, and removed legacy +09:32 < geertu> SMP fallback for H2 and M2-W. +09:33 < geertu> B) What we plan to do till next time: +09:33 < geertu> Kaneko-san will upport M3-N WDT support. +09:33 < geertu> Marek will handle PCIe suspend/resume for Linux, and automatic mtdparts +09:33 < geertu> bootargs on U-Boot. +09:33 < geertu> Morimoto-san will enhance periject based on feedback. +09:33 < geertu> Niklas will investigate pinctrl problems on V3M. +09:33 < geertu> Shimoda-san will upport USB2.0 PFC for E3, and pave the way forward +09:33 < geertu> for IPMMU. +09:33 < geertu> Ulrich will work on memory size detection for Gen3. +09:33 < geertu> Geert will review the RZ/N1 clock driver, do more periupport analysis +09:33 < geertu> and upporting, and handle CPG/MSSR and SYSC errata. +09:34 < geertu> C) Problems we have currently: +09:34 < geertu> Morimoto-san wants more periject feedback. +09:34 < geertu> Anything I missed? +09:35 < Marex> geertu: I did some gen3 JTAG digging yesterday +09:35 < Marex> geertu: on S-X, I observe the problem that reset halt doesn't halt the platform, I want to dig deeper at some point +09:36 < geertu> Marex: Halt is implemented by the BD9571 +09:36 < Marex> this would help me restore U-Boot on those platforms over JTAG, which in turn would be useful for U-Boot CIing +09:36 < Marex> geertu: reset halt in OpenOCD is what I mean +09:36 < geertu> Marex: what's is it supposed to do then? +09:37 < Marex> geertu: reset the CPU core and stop execution at the reset vector +09:37 < dammsan> could be power domain related +09:38 < Marex> dammsan: possibly, or it'll need similar funny hack as Gen2 (although I tried that and it didnt immediatelly work) +09:38 < Marex> like I said, I need to dig deeper +09:40 < geertu> OK, keep up the good work! +09:40 < dammsan> Marex: will you be able to look into OpenOCD support while you have physical board access in Tokyo? +09:40 < dammsan> in case it is applicable +09:40 < Marex> dammsan: I have physical Gen3 board here :-) +09:41 < Marex> dammsan: I can look into it now if it's desired +09:41 < dammsan> actually i was thinking of gen2 more +09:41 < Marex> dammsan: Gen2 JTAG is fine, Gen3 has this reset issue and isn't upstream +09:41 < dammsan> fore more complete support +09:41 < Marex> dammsan: Gen2 is partly upstream, board support is submitted and pending application, will be in OpenOCD 0.11 according to latest intel +09:42 < dammsan> cool +09:42 < dammsan> shall i bring e2 silk? =) +09:42 < Marex> if you want more Gen2 boards in OpenOCD, sure, why not :) +09:42 < Marex> dammsan: I have E2 silk on my desk and the board support is submitted, hehe +09:42 < dammsan> alright then i will shut up +09:42 < dammsan> let me know if you need some board +09:43 < Marex> http://openocd.zylin.com/#/c/4532/ +09:43 < Marex> dammsan: Silk, Porter, Stout are submitted, just let me know what other board you want in :-) +09:43 < kbingham> Marex, Did you post the Gen3? Or are you letting thinkfat handle that ? +09:45 < Marex> kbingham: thinkfat said he will post it, but I'd like to keep an eye on that +09:45 < Marex> kbingham: plus, there's the reset halt issue which I'd like to have fixed +09:46 < kbingham> Marex, halt-reset won't affect me as much - as I want to debug running systems - not necesarily boot it :) anyway - topic for another day :D +09:46 < Marex> kbingham: I mostly want to use that JTAG to start minimon without flipping the MD switches +09:46 < dammsan> Marex: wheat and maybe gose would be nice +09:46 < Marex> kbingham: that'd be real convenient for restoring U-Boot +09:47 < Marex> dammsan: ha, I dont think we support wheat in U-Boot (!), so that's another topic +09:47 < dammsan> would be good to fix +09:47 < Marex> jupp, and probably easy +09:47 < dammsan> i suppose blanche is missing as well then +09:48 < Marex> blanche is there +09:48 < Marex> but I think anything Gen2 but porter/stout/silk is broken in U-Boot to some degree +09:48 < Marex> Porter was before I fixed it, so was Silk +09:49 < Marex> so maybe a round of testing on all things wouldn't hurt +09:49 < dammsan> inndeed +09:50 < Marex> plus, test automation for U-Boot, that's something I'm cobbling together in my spare time +09:50 < Marex> the test.py framework is there, I just need some sort of board control and connector to dammsan 's farm for that +09:50 < Marex> to be done +09:51 * Marex stops talking, talks too much anyway +09:51 * uli___ has to take out the trash, brb +09:51 < geertu> Managing trash is a very important task in our society! +09:52 < geertu> uli___: CU! +09:52 < geertu> Topic 2. Discussion Topics +09:52 < geertu> a. Should we implement platform_driver.shutdown() on each device driver +09:52 < geertu> (especially for master IPs)? +09:52 < geertu> This is a question from BSP team, relayed through Shimoda-san +09:53 < geertu> Apparently Morimoto-san will steal the show and explain the rationale behind it? +09:53 < shimoda_cloud> Morimoto-san had a related question. but he can reply by himself :) +09:53 < shimoda_cloud> but, I'd still would like to get your opinion about this topic +09:54 < dammsan> yes? +09:54 < geertu> What's the use case? What do you want to do in .shutdown()? +09:55 * geertu tries to keep computers running all the time ;-) +09:55 < shimoda_cloud> background: If Linux system reboots, IPL do that. +09:56 < geertu> shimoda_cloud: What do you mean with "IPL do that"? +09:56 < shimoda_cloud> if IPL changes the DDR setting to "self refresh" and a master IPs are still running, the HW causes to access DDR +09:56 < shimoda_cloud> greetu: Gen3 ATR will access PMIC to reboot, IIUC +09:57 < shimoda_cloud> in this case, Gen3 SoCs will stuck because the DDR is in self refresh mode +09:57 < shimoda_cloud> To stop the HW, BSP team decide to add .shutdown ops to the DU driver +09:58 < geertu> BTW, what's ATR? ATF? +09:58 < shimoda_cloud> But, BSP team would like to know all drivers should have same way or not. +09:59 < shimoda_cloud> geertu: oops, ATF (arm-trusted-firmware) +09:59 < Marex> shimoda_cloud: what problem are you trying to solve by this ? +10:00 < dammsan> bus mastering devices are still running when firmware is entering self refresh +10:00 < Marex> ah +10:00 < shimoda_cloud> Marex: I'm not trying to solve this now. But, I'd like to give BSP team about upstream team's policy +10:00 < dammsan> the subsystem is not involved somehow? +10:00 < shimoda_cloud> dammsan: thanks for simple explanation :) +10:01 < dammsan> np +10:01 < geertu> And devices aren't stopped elseway before reboot? +10:02 < shimoda_cloud> geertu: indeed +10:03 < Marex> shouldnt the reboot put the system into defined state ? +10:03 < Marex> q2: doesnt the dram enter self-refresh only during suspend ? +10:03 < Marex> bbiab +10:03 < shimoda_cloud> dammsan: i checked roughly yesterday, but the subsystem doesn't have any solutions, I think +10:04 < geertu> Devices are suspended during system reboot +10:04 < geertu> Ah, DU doesn't have Runtime PM support yet? +10:06 < pinchartl> geertu: DU has complex clock handling requirements +10:06 < geertu> E.g. for sh_eth on Koelsch, genpd_stop_dev() is called before reboot (I still have some local debug code that tells me) +10:06 < pinchartl> runtime PM is not on the high priority list +10:06 < dammsan> that would make sense +10:06 < geertu> pinchartl: I know ;-) +10:07 < shimoda_cloud> geertu: thanks for the information about Runtime PM. This is easy to know which drivers needs for .shutdown() +10:08 < shimoda_cloud> s/needs for/needs/ +10:08 < dammsan> shimoda_cloud: is Runtime PM BSP-first? +10:09 < dammsan> the dependencies between different DU devices seem quite complex to me +10:11 < shimoda_cloud> dammsan: IIUC, almost all drivers have already supported Runtime PM +10:12 < geertu> The DU node in DT also doesn't have a power-domains property. +10:12 < dammsan> it would be good to fix that +10:13 < shimoda_cloud> some drivers (e.g. ehci-platform) lack Runtime PM though... +10:13 < geertu> Yep, separate device nodes for each channel, linked with "companion" properties +10:13 < dammsan> can't we have bus notifier in soc code to handle PM in such case? +10:16 < dammsan> BUS_NOTIFY_BIND_DRIVER +10:16 < dammsan> and a white list +10:16 < geertu> dammsan: That feels like the legacy clock domain to me... +10:16 < dammsan> as a temporary solution +10:16 < dammsan> might be better +10:17 < dammsan> i guess fixing up DT can be separated from actual SW implementation +10:18 < geertu> We've slowly entered MultiMedia space... +10:18 < pinchartl> let me know when you'll have fully entered multimedia space and I'll take over :-) +10:19 < geertu> I think we have, unless there's another core topic to discuss? +10:19 < pinchartl> (you have 60s, the tea water is heating up) +10:19 < shimoda_cloud> thanks! I have no core topic from my side +10:20 < kbingham> Except I was going to ask about DMAC virtualisation :) +10:20 < pinchartl> (which always reminds me of the 御茶ノ水 metro station in Tōkyō) +10:21 < pinchartl> kbingham: please go ahead +10:21 < dammsan> kbingham: seems like an important topic +10:22 < kbingham> dammsan, geertu: mainly - what's the method of use-case testing. +10:22 < dammsan> sertest inside the guest using a loopback? =) +10:22 < dammsan> not sure if it makes sense +10:23 < kbingham> dammsan, From multiple guests ? +10:23 < dammsan> i think testing a single guest is enough, but designing code for multi-guest +10:24 < kbingham> Ok so just exposing two serial devices into the guest - which then have a loopback. +10:24 < dammsan> for instance +10:24 < geertu> kbingham: That needs wiring. +10:24 < kbingham> geertu, It's the wiring that confuses me ... +10:24 < dammsan> something very basic is also ok with me +10:24 < geertu> Can't you just use the second serial port (debug serial) +10:25 < geertu> Tie it to USB, and you can talk to it from the host +10:25 < dammsan> that seems even better +10:25 < kbingham> as the serial ports on salvatorx are USB gadgets :) +10:25 < kbingham> Ok - so just take the serial and use it as a serial device :) +10:25 < kbingham> (as a usb serial device) +10:26 < geertu> Once it works, you can use that serial as the console for the guest +10:26 < geertu> And wire it up in your farm ;) +10:27 < dammsan> it is hard to beat virsh console +10:27 < dammsan> but hey +10:28 < dammsan> using the second debug serial console sounds great +10:28 < dammsan> if it supports SYS-DMAC that is +10:28 < kbingham> Is USB already supported through the guest ? +10:28 < kbingham> Or does it just do high level USB passthrough ... +10:29 < geertu> kbingham: Use USB on the host, please ;-) +10:29 < kbingham> (or in your test, do you mean then read the 'guest serial' on the 'host USB serial' +10:29 < kbingham> Ok - that's clearer - I thought this was some loopback out of the guest, then back into the guest. +10:30 < kbingham> Ok - well until I dive in and hit problems that's enough for me :) +10:30 < geertu> kbingham: You can also run https://github.com/geertu/sertest on the guest, and on the host +10:31 < geertu> guest=SCIF1 host=cp210x-usb-serial +10:32 < kbingham> geertu, Thanks for the sertest link - I'll get that going too. +10:33 < kbingham> Final question - was it left that I am writing the task description? +10:34 * kbingham was expecting to receive a description ... but that may not be the case +10:34 < geertu> I think so +10:34 < kbingham> geertu, Ok - I'll pull something together and run it past you. +10:34 < geertu> kbingham: Thanks! +10:35 < dammsan> thanks guys +10:35 < geertu> pinchartl: FFWD to MM? +10:35 < geertu> Thaks for joininh, and have a nice continued day! +10:35 < geertu> s/joininh/joining/ diff --git a/wiki/Chat_log/20180524-io-chatlog b/wiki/Chat_log/20180524-io-chatlog new file mode 100644 index 0000000..12330d1 --- /dev/null +++ b/wiki/Chat_log/20180524-io-chatlog @@ -0,0 +1,118 @@ +09:04 < wsa_> welcome to the io meeting! +09:04 < wsa_> Here are the collected status updates: +09:04 < wsa_> A - what have I done since last time +09:04 < wsa_> ------------------------------------ +09:04 < wsa_> Geert +09:04 < wsa_> : fixed SYNCAC handling for MSIOF +09:04 < wsa_> Kaneko-san +09:04 < wsa_> : got M3-N SDHI support merged +09:04 < wsa_> Marek +09:04 < wsa_> : worked on upporting PCIE, removed mtdparts from DT +09:04 < wsa_> Niklas +09:04 < wsa_> : had a high-priority-interrupt to finally get his VIN patches upstream, so no time for IO +09:04 < wsa_> Shimoda-san +09:04 < wsa_> : investigated usb1.1 host suspend/resume issue, submitted new role switch patchset, and upported E3 ethernet support +09:04 < wsa_> Simon +09:04 < wsa_> : got positive response about his SDHI HS400 patches +09:04 < wsa_> Ulrich +09:04 < wsa_> : enabled MSIOF, HSCIF, SCIF and successfully tested thermal on D3 +09:04 < wsa_> Wolfram +09:04 < wsa_> : discussed internally BSP patches and/or regressions about I2C and SDHI, tested periject, started SPDX conversion for drivers written by Renesas, and some patch review/resending +09:04 < wsa_> B - what I want to do until next time +09:04 < wsa_> ------------------------------------- +09:04 < wsa_> Geert +09:04 < wsa_> : wants to look into the DMA completion issue for MSIOF +09:04 < wsa_> Kaneko-san +09:04 < wsa_> : wants to upport PCIE support for M3-W and M3-N +09:04 < wsa_> Marek +09:04 < wsa_> : wants to work on PCIE suspend/resume +09:04 < wsa_> Niklas +09:04 < wsa_> : wants to resume SDHI work +09:04 < wsa_> Shimoda-san +09:04 < wsa_> : wants to continue with the suspend/resume issue and the role switch driver, add USB2 support for E3 including GPIO support for the PHY +09:04 < wsa_> Simon +09:04 < wsa_> : wants to keep working on HS400 including M3-N support and CPG changes +09:04 < wsa_> Wolfram +09:04 < wsa_> : wants to continue with SDHI upporting, SPDX conversion, and QEMU I2C passthrough +09:04 < wsa_> C - problems I currently have +09:04 < wsa_> ----------------------------- +09:04 < wsa_> Wolfram +09:04 < wsa_> : now needs some commited base time from Niklas. And a discussion with the Core group how to handle the 32bit DMA limitation of PCIE. +09:04 < wsa_> Niklas +09:04 < wsa_> : still missing HW fuses to test the thermal driver +09:05 < wsa_> feel free to comment if I missed something +09:05 < wsa_> otherwise about the C) items +09:06 < wsa_> neg needs HW fuses for thermal. Is there any internal plan where those should/could be added? +09:06 < wsa_> Or can we just keep waiting until they appear? +09:07 < wsa_> This is a question for JapaPeri :) +09:07 < neg> There are patches in the BSP so there must be hardware somewhere :-P +09:07 < wsa_> About neg's base time: After VIN is over, I'd like to give SDHI upporting some priority. +09:08 < dammsan> and i would like some world peace =) +09:08 < wsa_> This is a question for pinchartl. How are M/M priorities for him these days? +09:08 < wsa_> dammsan: this is your first wish? +09:08 < wsa_> :D +09:09 < pinchartl> wsa_: for Niklas ? +09:09 < dammsan> yes of course +09:10 < wsa_> and about the PCIE 32bit topic. I think we need to move it to core, and from there decide how to proceed. +09:10 < wsa_> geertu: do you agree? +09:10 < wsa_> pinchartl: yes +09:10 < pinchartl> wsa_: there was a budget of 5 days of additional tasks for Q2/2 that we couldn't use as no small task enough I proposed was deemed good enough by Renesas +09:10 < pinchartl> but I suspect you may want more than 5 days :-) +09:10 < Marex> wsa_: I am fine either way +09:10 < geertu> wsa_: OK +09:11 < Marex> wsa_: btw I discovered another bug in the PCIe driver dragged in by Sergei's PHY addition, fixing it now +09:11 < wsa_> Marex: nice +09:12 < wsa_> pinchartl: dunno if we can do it as additional task. AFAIU all our base time was increased to upport. And this is a upport task. +09:12 < wsa_> dammsan: what do you think? +09:12 < neg> My view is that with the VIN lump of lard behind me I will have more time for IO, not sure if pinchartl have something lined up. From a status of pending patches I feel I'm in a better position today then last meeting +09:13 < wsa_> neg: congrats again for getting "rid" of the VIN stuff, that's for sure! +09:13 < pinchartl> neg: for the rest of Q2, I'd like you to keep track of all pending VIN patches to make sure they all get merged +09:13 < dammsan> wsa_: lets use base time as much as possible +09:13 < pinchartl> which involves reposting patches that were delayed due to VIN/CSI-2 being out-of-tree +09:14 < pinchartl> apart from that, I'd like to continue GMSL development, but I think that can wait for Q3 +09:14 < wsa_> sounds good to me +09:15 < wsa_> neg: you fine with that, too? +09:17 < neg> wsa_: I'm not sure what the conclusion is :-) For Q2 I will sheperone delayed patches and focus on SDHI. While in Q3 GMSL might be back to drag me back more to MM? If so I'm fine with it +09:17 < wsa_> that's at least my understanding, too +09:17 < wsa_> pinchartl: d'accord? +09:18 < pinchartl> that's my understanding too :-) +09:18 < pinchartl> if that's fine with you +09:18 < wsa_> \o/ +09:18 < wsa_> perfect, thank you! +09:19 < wsa_> Then, I have a question about E3 upporting/enablement +09:19 < wsa_> Who has HW to test? +09:19 < wsa_> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Hardware is empty on that one +09:19 < geertu> wsa_: Shimoda-san only? +09:19 < wsa_> (BTW I sorted this page a little more) +09:20 < wsa_> I see +09:20 < shimoda_cloud> yes, i have a board only. i'll get more boards later (early July?) +09:21 < Marex> wsa_: I want to lend the board while Im in Japan so I can try U-Boot on it :) +09:21 < wsa_> ah, that's good to know +09:21 < wsa_> so, only trivial binding updates for now +09:21 < Marex> shimoda_cloud: would that work for you for a few days ? I'll arrive on the 13th in the morning +09:23 < wsa_> ok, I will contact some of you individually, too, for discussing upporting details +09:23 < wsa_> other than that, I have nore more topics +09:24 < shimoda_cloud> Marex: that work means U-Boot? I think I (or Magnus-san) can bring the board for you for a few days +09:24 < wsa_> Is there something from your side? +09:24 < dammsan> shimoda_cloud: my plan is to disconnect the E3 board from remote access when Marex arrives +09:24 < Marex> shimoda_cloud: jupp :) +09:25 < Marex> shimoda_cloud: I have the U-Boot patchset kinda ready, so I'll just need to iron out the details on that board +09:25 < shimoda_cloud> dammsan: Marex: I got it :) +09:25 < wsa_> If not, we could switch to core with the added topic of 32bit DMA +09:25 < Marex> shimoda_cloud: I hope for no big surprises, but we'll see +09:26 < geertu> dammsan: You mean the E3 is in your farm? And perhaps available? +09:26 < dammsan> geertu: will be next week +09:26 < geertu> wsa_: SDHI write protect +09:26 < geertu> Is this a regression? SDHI was refactored recently. +09:26 < shimoda_cloud> Marex: I also hope so +09:27 < wsa_> geertu: yes, it is. I am still puzzled because I am sure I tested Yamada-sans patches on Gen3 and Lager. +09:27 < wsa_> and my fixup of that +09:28 < Marex> shimoda_cloud: speaking of which, do you or renesas have a few spare JTAG adapters from Tokyo Eletech for ULCBs ? :) +09:28 < Marex> shimoda_cloud: or can they be bought somewhere in tokyo on the market ? +09:28 < geertu> Marex: "somewhere" == "Akihabara"? +09:29 < shimoda_cloud> Marex: I'll ask goda-san about the adapter +09:29 < Marex> shimoda_cloud: that'd be real nice, but no stress, it's just my curiosity :-) +09:29 < Marex> shimoda_cloud: thank you! +09:30 < wsa_> so, geertu, takeover? +09:31 < geertu> wsa_: OK, thank you! +09:31 < wsa_> have fun. and thanks all for this meeting diff --git a/wiki/Chat_log/20180524-mm-chatlog b/wiki/Chat_log/20180524-mm-chatlog new file mode 100644 index 0000000..4af076c --- /dev/null +++ b/wiki/Chat_log/20180524-mm-chatlog @@ -0,0 +1,126 @@ +Multimedia-chat-meeting-2018-05-24 + +10:36 < pinchartl> welcome to the multimedia meeting +10:36 < pinchartl> let's start as usual with status updates +10:36 < pinchartl> * Jacopo +10:36 < pinchartl> Since last meeting: +10:36 < pinchartl> - VIN parallel input support + Draak VIN support (4 iterations) +10:36 < pinchartl> - VIN endpoint cleanups +10:36 < pinchartl> - Miscellaneous CEU patches +10:36 < pinchartl> - Patch review +10:36 < pinchartl> Until next meeting: +10:36 < pinchartl> - Have VIN parallel merged + Draak VIN enable +10:36 < pinchartl> - Still have to make MT9T111 work with an ARM SoC +10:36 < pinchartl> - soc_camera still needs to be removed +10:36 < pinchartl> Issues and Blockers: None +10:36 < pinchartl> jmondi: any comment ? +10:37 < pinchartl> have you solved the D3 Draak hangs while capturing with v4.17 ? +10:37 < jmondi> only that I have sent a wrong patch name in the activity report +10:38 < jmondi> yes, that was due to the crop issue that was takled in v1, and then more opportunely by Niklas in a follow up patch +10:38 < pinchartl> thank you +10:38 < pinchartl> feel free to reply to the e-mail report with the correct patch name +10:38 < pinchartl> * Kieran +10:38 < pinchartl> Since last meeting: +10:38 < pinchartl> - Supported HDMI on KF issue in #linux-renesas-soc +10:38 < pinchartl> - TLB-Optimise v10, v11 (finally finished I think) +10:38 < pinchartl> - DU Interlaced rebased on top of latest TLB-Optimise +10:38 < pinchartl> - DRM fix patch reviews and testing +10:38 < pinchartl> - Built QEmu for AT +10:38 < pinchartl> Until next meeting: +10:38 < pinchartl> - DMA Virtualisation +10:38 < pinchartl> - Chase up DU Interlaced review +10:38 < pinchartl> Issues and blockers: None +10:38 < jmondi> yeah, no biggies +10:38 < pinchartl> kbingham: any comment ? +10:39 < kbingham> Nope. That's covered :) +10:39 < pinchartl> * Laurent +10:39 < pinchartl> Since last meeting: +10:39 < pinchartl> - Patch review: helped getting VIN CSI-2, DU M3-N and VSP1 TLB optimisations +10:39 < pinchartl> merged +10:39 < pinchartl> - VSP1 DISCOM upstreaming +10:39 < pinchartl> Until next meeting: +10:39 < pinchartl> - Display virtualization +10:39 < pinchartl> Issues and blockers: None +10:40 < pinchartl> v4.18 will be a big release for multimedia +10:40 < pinchartl> we have gone through a large part of the backlog +10:41 < pinchartl> * Magnus: +10:41 < pinchartl> Since last meeting: None +10:41 < pinchartl> Until next meeting: None +10:41 < pinchartl> Issues and blockers: None +10:41 < pinchartl> dammsan: any comment? +10:41 < pinchartl> * Morimoto-san +10:41 < pinchartl> Since last meeting: None +10:41 < pinchartl> Until next meeting: None +10:41 < pinchartl> Issues and Blockers: None +10:41 < pinchartl> morimoto: any comment? +10:42 < morimoto> no comment +10:42 < dammsan> i discovered the toilet program recently +10:42 < pinchartl> is that a multimedia program ? +10:42 < dammsan> but i might prefer figlet since it is closer to swedish figgan +10:43 < pinchartl> * Niklas +10:43 < pinchartl> Since last meeting: +10:43 < pinchartl> - [PATCH] v4l: Add support for STD ioctls on subdev nodes +10:43 < pinchartl> - [PATCH v2 0/2] v4l: Add support for STD ioctls on subdev nodes +10:43 < pinchartl> - [PATCH v2] media: i2c: adv748x: Fix pixel rate values +10:43 < pinchartl> - [PATCH 0/2] rcar-vin: Fix potential buffer overrun root cause +10:43 < pinchartl> - [PATCH v15 0/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 +10:43 < pinchartl> - [PATCH v2 0/2] Fix potential buffer overrun root cause +10:43 < pinchartl> - [PATCH 0/7] arm64: dts: renesas: enable VIN, CSI-2 and ADV7482 +10:43 < pinchartl> - [PATCH] media: rcar-vin: enable support for r8a77965 +10:43 < pinchartl> - [PATCH v16 0/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 +10:43 < pinchartl> - [PATCH] rcar-csi2: set default format if a unsupported one is requested +10:43 < pinchartl> - [PATCH] rcar-vin: sync which hardware buffer to start capture from +10:43 < pinchartl> - [PATCH] media: dt-bindings: media: rcar_vin: add support for r8a77965 +10:43 < pinchartl> - [PATCH] dt-bindings: media: rcar_vin: fix style for ports and endpoints +10:43 < pinchartl> - VIN, CSI-2 and DT patches are now on there way to v4.18 +10:43 < pinchartl> Looks like capture is going to work out-of-the box for most Gen3 SoC in v4.18. Niklas is so happy that he will need a big box of tissues. +10:43 < pinchartl> - Reviewed Jacopo's VIN parallel patches +10:43 < pinchartl> This includes getting parallel input working on V3M expansion board. It works but the media bus on the V3M parallel is different then from all other Renesas boards and the adv7604 driver don't support it so colors are messed up, but good enough to test. +10:43 < pinchartl> Until next meeting: +10:43 < pinchartl> - Keep reviewing Jacopo's patches +10:43 < pinchartl> - Keep track of capture patches so everything makes it for 4.18 +10:43 < pinchartl> Issues and blockers: None +10:43 < pinchartl> neg: any comment ? +10:44 < neg> Only that late last night using jmondi VIN parallel series I can switch in runtime between CSI-2 and parallel inputs. Greate work Jacopo! +10:44 < pinchartl> \o/ +10:44 < jmondi> \o/ thanks for testing! +10:45 < pinchartl> * Ulrich +10:45 < pinchartl> Since last meeting: +10:45 < pinchartl> - Posted D3 DU support +10:45 < pinchartl> - Rebasing IGT DU fixes, still WIP +10:45 < pinchartl> Until next meeting: +10:45 < pinchartl> - Send v2 of DU on D3 +10:45 < pinchartl> - Send a new IGT DU fix series +10:45 < pinchartl> Issues and blockers: None +10:45 < pinchartl> uli___: any comment ? +10:45 < uli___> lots of garbage is lots of heavy. no work-related comment, though :) +10:45 < pinchartl> :-) +10:46 < pinchartl> that's all for status updates +10:46 < pinchartl> Morimoto-san, you had a couple of questions from the BSP team, I've replied by e-mail already +10:47 < pinchartl> is there anything else to discuss ? +10:48 < pinchartl> seems not +10:48 < pinchartl> I have one question for Magnus then +10:48 < pinchartl> dammsan: what's your plan for additional tasks in Q3 ? +10:48 < pinchartl> how does it look like from a budget point of view ? +10:49 < dammsan> same as before i think +10:50 < dammsan> but as usual i am only interested in funding stuff going on in public space +10:50 < pinchartl> sure +10:50 * morimoto talked with someone +10:50 < pinchartl> so should we start thinking about additional tasks for Q3, with the same number of days as before for everybody ? +10:51 < pinchartl> morimoto: that's nice, never talking to anyone wouldn't be good for your mental health :) +10:51 < dammsan> it might be a good topic for meeting in japan for sure +10:52 < pinchartl> indeed +10:52 < pinchartl> that's all for me +10:52 < geertu> Next meeting on June 7? +10:53 < pinchartl> same time as today, yes +10:53 < pinchartl> unless anyone wants to add something, I propose adjourning this meeting +10:54 < pinchartl> does anyone second ? +10:54 < wsa_> June 7 is fine +10:54 < neg> 7 june works for me +10:54 < jmondi> I'll be happy to celebrate my birthday meeting with you :) +10:55 < shimoda_cloud> June 7 is good to me +10:55 < kbingham> looks good here. +10:55 < horms> 7 is my favourite number :) +10:55 < pinchartl> does anyone second ?? :) +10:56 < jmondi> adjourning the meeting? yes... +10:56 < pinchartl> meeting adjourned, thank you all for attending diff --git a/wiki/Chat_log/20180607-core-chatlog b/wiki/Chat_log/20180607-core-chatlog new file mode 100644 index 0000000..0e9f516 --- /dev/null +++ b/wiki/Chat_log/20180607-core-chatlog @@ -0,0 +1,113 @@ +Core-chat-meeting-2018-06-07 + +11:05 < geertu> Welcome to today's (delayed) Core Group Meeting! +11:05 < geertu> Agenda: +11:05 < geertu> 1. Status Updates +11:05 < geertu> 2. Discussion Topics +11:05 < geertu> Topic 1. Status updates +11:05 < geertu> A) What have we done since last time: +11:06 < geertu> Kaneko-san got M3-N thermal support merged. +11:06 < geertu> Kieran is investigating DMAC Virtualisation. +11:06 < geertu> Marek worked on U-Boot (Ebisu, mtdparts) and Linux (DA9063L, PCIe, Gen2 +11:06 < geertu> PMIC quirk). +11:06 < geertu> Morimoto-san is happily designing and hacking periject. +11:06 < geertu> Shimoda-san upported USB2.0 PFC for R-Car E3, and discussed M3-W ES1.2 +11:06 < geertu> handling. +11:06 < geertu> Ulrich is developing the R-Car Gen3 SoC memory size detection prototype. +11:06 < geertu> Geert revisited vfio PM Domain handling, coached Kieran for virt, played +11:06 < geertu> with Ebisu (upported SMP and WDT), did misc fixes and cleanups, reviews, +11:06 < geertu> and periupport analysis. +11:06 < geertu> B) What we plan to do till next time: +11:06 < geertu> Kaneko-san will upport M3-N WDT support. +11:06 < geertu> Kieran will continue his Virtualisation investigations. +11:06 < geertu> Marek will work on U-Boot (more Ebisu) and ATF (D3/Draak, V3M/Eagle, +11:06 < geertu> V3H/Condor?). +11:06 < geertu> Morimoto-san will enhance periject based on feedback. +11:06 < geertu> Niklas will investigate pinctrl problems on V3M. +11:06 < geertu> Shimoda-san will upport USB3.0 PFC for E3, and pave the way forward for +11:06 < geertu> IPMMU. +11:06 < geertu> Ulrich plans to finish memory size detection. +11:06 < geertu> Geert will handle CPG/MSSR and SYSC errata, and possibly additional tasks. +11:07 < geertu> C) Problems we have currently: +11:07 < geertu> Kieran's DMAC task was scheduled too late to complete before deadline. +11:07 < geertu> Morimoto-san wants more periject feedback. +11:07 < geertu> Ulrich has ATF support issues with Salvator-X H3 ES1.0, and needs ES3.0 +11:07 < geertu> remote firmware update facilities. +11:07 < geertu> EOL(ist) +11:08 < geertu> Anything I missed? +11:08 < Marex> geertu: upstreaming the ATF ? +11:08 < pinchartl> geertu: I haven't thought about reporting that +11:08 < pinchartl> but I've also worked with Kieran on DMA virtualization +11:08 < pinchartl> I was going to include it in my multimedia report, but it makes more sense to include it in the core report +11:09 < geertu> Marex: As we're "the upstream team", isn't upstreaming assumed? ;-) +11:09 < dammsan> pinchartl: nice to see you at the core chat =) +11:09 < geertu> pinchartl: Added +11:09 < Marex> geertu: well I mean, there's probably team in Renesas that does the ATF work +11:09 < Marex> geertu: I dont want to step on their toes +11:10 < geertu> Marex: But a good point, for ATF we never explicitly mentioned that +11:10 < Marex> geertu: I can just start the process, which would reduce the amount of patches in meta-renesas +11:10 < Marex> shimoda: morimoto ^ +11:10 < Marex> thoughts ? +11:10 < Marex> also, updating the D3 ATF and V3M/V3H ATF sucks +11:10 < Marex> I managed, but it needs testing +11:10 < Marex> if we got that upstream, this problem would go away +11:10 < geertu> Marex: Given there's no plat/master directory in upstream ATF, I doubt the Renesas ATF team is working on upstreaming +11:11 < dammsan> Marex: we might have some key person here at Renesas +11:11 < geertu> s/master/renesas/ +11:12 < dammsan> Marex: maybe we can do a f2f meeting when you come to japan? +11:12 < Marex> dammsan: jupp +11:12 < Marex> dammsan: I am open to anything which trims down the amount of patches which we lug around +11:12 < dammsan> we will ask ATF people here to join +11:12 < geertu> dammsan: Good idea. +11:13 < Marex> dammsan: btw any chance on getting V3MSK while in japan ? :) +11:13 < dammsan> not sure, add it to your list of boards you need =) +11:13 < dammsan> and email me +11:14 < geertu> About the problems (C): +11:14 < geertu> The task scheduling has been discussed before this meeting. +11:14 < geertu> I believe Morimoto-san is still waiting for periject feedback from Laurent? +11:14 < Marex> dammsan: done +11:15 < dammsan> thanks +11:15 < morimoto> geertu: laurentu: yes +11:15 < geertu> pinchartl: ^ +11:16 < morimoto> s/laurentu/pinchartl/ +11:16 < pinchartl> morimoto: I'll read all the pending e-mails and reply +11:16 < morimoto> \me pinchartl always ignored my email... +11:16 < pinchartl> but I wonder whether this shouldn't be tied to the meeting we will have in Tokyo +11:17 < morimoto> pinchartl: OK +11:17 < pinchartl> as planning requires tooling +11:17 < pinchartl> I will still reply to the e-mails as soon as I can +11:18 < geertu> dammsan: For Uli, you just need to add remote MD control to Salvator-X H3 ES3.0, right? +11:18 < uli___> i might not even need that (right away) if your tip about the driver strength turns out to be the (only) issue +11:19 < uli___> then i could prototype the whole thing on my own board +11:19 < geertu> uli___: But eventually, you want to test on the real target, right? +11:19 < uli___> i would, yes +11:20 < geertu> OK +11:20 < geertu> Topic 2. Discussion Topics +11:20 < geertu> Anything we still need to discuss? +11:20 < geertu> Are there explicit core requests from Renesas, or from other groups? +11:21 < wsa_> only this I2C CPG reset issue +11:21 < geertu> wsa_: OK, I still have to reply to that email +11:21 < morimoto> so far, I don't received from BSP team +11:22 < neg> I have a question, is there any conclusion on how we should lable and group DT patches to ease upstream consumption with regard to the recent feedback? +11:22 < dammsan> geertu: yep, on my todo with MD pin control +11:23 < dammsan> geertu: i want paravirtualzied GPIO support at some point! =) +11:25 < geertu> dammsan: Added to peripelist/core/todo +11:25 < dammsan> thanks!! +11:26 < geertu> Anything else to discuss? +11:26 < geertu> Next chat meeting? +11:27 < pinchartl> two weeks from now is during OSSJ +11:27 < geertu> correct +11:28 < geertu> four weeks from now? +11:28 < wsa_> yup +11:28 < pinchartl> that sounds good to mee +11:28 < Marex> pinchartl: I hope this OSSJ is gonna be as awesome as the previous one ;-) +11:28 < morimoto> 5th, july ? +11:29 < geertu> Now, if you're interested in doing a core additional task, please say so before next chat meeting ;-) +11:29 < geertu> s/task/task in Q3/ +11:29 < morimoto> awesome T Shirt +11:29 < kbingham> geertu, Well - I don't want to make any assumptions :D +11:30 < pinchartl> geertu: based on the discussion we just had, additional tasks for Q3.1 should be signed on June the 15th +11:30 < pinchartl> so I'd say, please say so before the end of this week +11:31 < geertu> Right. +11:31 < geertu> Time to pass the mic to the MM leader? +11:32 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20180607-io-chatlog b/wiki/Chat_log/20180607-io-chatlog new file mode 100644 index 0000000..3cae41d --- /dev/null +++ b/wiki/Chat_log/20180607-io-chatlog @@ -0,0 +1,620 @@ +09:03 < wsa_> Welcome to this IO meeting +09:03 < wsa_> first the status updates with a focus on the C) parts +09:03 < pinchartl> hello +09:04 < wsa_> A - what have I done since last time +09:04 < wsa_> ------------------------------------ +09:04 < wsa_> Geert +09:04 < wsa_> : upported R-Car M3-N HSCIF support (incl. PFC), discovered SCIF work_tx race condition, +09:04 < wsa_> discussed MSIOF related BSP patch about DMA +09:04 < wsa_> Kaneko-san +09:04 < wsa_> : posted M3-W PCIE support +09:04 < wsa_> Marek +09:04 < wsa_> : has posted multiple iterations of PCIE fixes, with success +09:04 < wsa_> Niklas +09:04 < wsa_> : sent out two SDHI related patch series (tuning behaviour and reset procedure), +09:04 < wsa_> retested SDIO on Koelsch (still fails, but a step later now) +09:04 < wsa_> Shimoda-san +09:04 < wsa_> : further investigated USB susped/resume issue, sent out new versions for USB role switch feature, +09:04 < wsa_> upstreamed USB for E3, and communicated various issue from the BSP team to us +09:04 < wsa_> Simon +09:04 < wsa_> : began reworking HS400 patches as per Ulf's feedback +09:04 < wsa_> Wolfram +09:04 < wsa_> : discussed various items and implemented proposed solutions (SDHI WP regression, I2C DMA RX handling, +09:04 < wsa_> I2C recovery flaw), upported SDHI DATA_STROBE and faster I2C speed patches, discussed periject tool, +09:04 < wsa_> added new fault injector to i2c-gpio, proposed new QEMU I2C passthrough sketch to Magnus, +09:04 < wsa_> various patch review and some backporting assistance, prepared travel to Japan +09:04 < wsa_> B - what I want to do until next time +09:04 < wsa_> ------------------------------------- +09:04 < wsa_> Geert +09:04 < wsa_> : wants to fix the SCIF work_tx issue +09:04 < wsa_> Kaneko-san +09:04 < wsa_> : wants to continue upporting M3-W and M3-N PCIE support +09:04 < wsa_> Niklas +09:04 < wsa_> : wants to keep upporting SDHI and keep at SDIO testing if time allows +09:04 < wsa_> Shimoda-san +09:04 < wsa_> : wants to keep at the USB role switch patches, continue to plan for GPIO PHY support for E3, +09:04 < wsa_> learn about KVM and USB virtualization +09:04 < wsa_> Simon +09:04 < wsa_> : wants to continue HS400 upstreaming activity +09:04 < wsa_> Wolfram +09:04 < wsa_> : wants to continue the above discussions, prepare the talk for ALS18, continue +09:04 < wsa_> SPDX conversion for Renesas drivers, start implementing QEMU solution (f Magnus +09:04 < wsa_> agrees) +09:04 < wsa_> C - problems I currently have +09:04 < wsa_> ----------------------------- +09:04 < wsa_> Niklas +09:04 < wsa_> : is still waiting for Gen3 thermal fuses +09:04 < wsa_> Shimoda-san +09:04 < wsa_> : has to struggle with microB connector on E3 Ebisu instead of microAB +09:04 < wsa_> Simon +09:04 < wsa_> : wants to discuss how to handle different HS400 versions on Gen3 +09:04 < wsa_> Wolfram +09:04 < wsa_> : is travelling until after next meeting, so has no direct HW access +09:05 < wsa_> neg: yes, well, I have it in the IO todo file, so it won't be forgotten. I guess no need to wait bi-weekly for it :/ +09:06 < wsa_> shimoda: well, not much we can do with the "wrong" connector, or? :) +09:06 < wsa_> horms: so far, I'd think the 0,4,8-tap decision is per-SoC only +09:06 < horms> wsa_: agreed +09:06 < neg> wsa_: check, will drop it from future status updates +09:07 < wsa_> I wonder if such a thing will change from one ES to another? +09:07 < wsa_> does JapaPERI have an idea? +09:07 < horms> My question is like this +09:07 < horms> Currently its between SoCs +09:07 < horms> and traditionally we handled such differences via the compat string +09:07 < horms> which may well be the cleanest option here +09:07 < horms> but it may be also possible to use soc_match +09:08 < neg> horms: in BSP there is a define HS400_USE_4TAP and bsp commit ce12154b826b955b6439546014870d038eff19ce seems to indicate this might be per SoC +09:08 < horms> Keep in mind that the per-SOC compat strings are more or less unimplemented for Gen3 SoCs in the SDHI driver at this time +09:08 < geertu> If there's no need to check for SoC revision, IMHO using the compat string is the easiest. +09:08 < wsa_> I'd agree with geertu +09:08 < horms> ok, let me do that then +09:09 < horms> no objection from my side +09:09 < wsa_> we can switch to soc_device_match when needed` +09:09 < wsa_> ? +09:09 < geertu> If you store (a pointer to) the features in soc_device_id.data, it's easy to retrieve. +09:09 < horms> yes, if its an implementation detail that should be possible +09:09 < horms> geertu: ok, thanks +09:10 < shimoda> wsa_: correct. i cannot development with the wrong connector. So, i intend to use DIP-SW gpio instead of actual ID signal to develop :) +09:10 < geertu> If a SoC revision check is needed later, it can be easily handled by taking the (pointer to) the features) from soc_device_match()->data +09:10 < wsa_> shimoda: role-DIP-switch, nice :D +09:11 < Marex> shimoda: can't you use hotair and replace the connector ? :) +09:11 < geertu> horms: drivers/media/platform/rcar-vin/rcar-core.c is a nice example: +09:11 < geertu> vin->info = of_device_get_match_data(&pdev->dev); +09:11 < geertu> attr = soc_device_match(r8a7795es1); +09:11 < geertu> if (attr) +09:11 < geertu> vin->info = attr->data; +09:12 < wsa_> so, with me being on the road already... +09:12 < shimoda> wsa_: :D +09:12 < wsa_> dammsan: can you give me remote access to H3 ES2.0 Salvator-XS? So, I can check stuff remote at least +09:13 < shimoda> Marex: it's difficult to me (my skill and Renesas office rule) +09:13 < horms> geertu: I am confused now. I see that is an exmple of using soc_device_match. And indeed there are already examples in the SDHI driver. But I thought that we decided to use compat strings for the case in question? +09:13 < geertu> horms: You can start with of_device_get_match_data() +09:14 < Marex> shimoda: ah :) +09:14 < geertu> If needed later, you add the next 3 lines enabling soc_device_match(), but needing no further driver logic change +09:14 < horms> Oh, I see. Very nice. +09:15 < wsa_> So, anything more from your side about the status updates? +09:16 < Marex> wsa_: PCIe32 got one reply ! +09:16 < wsa_> \o/ +09:16 < Marex> wsa_: and I keep resubmitting DA9063L patchset +09:17 < wsa_> Maybe some of the ARM core people are in Tokyo? It seems fastest to me to poke them personally, or get the right group together there... +09:17 < Marex> wsa_: let's see what happens at OSSJ ? +09:18 < Marex> wsa_: although, I doubt that +09:18 < wsa_> I share that feeling, but let's hope a bit... +09:18 < wsa_> okay, for the topic, there is only "add. tasks" from my side +09:18 < wsa_> although there is not much change for the IO group +09:19 < wsa_> pinchartl: notification for you :) +09:19 < wsa_> the focus is still on upporting and we should have increased base time for that +09:19 < wsa_> I'll contact you about upporting individually +09:19 < pinchartl> wsa_: I'm here :-) +09:20 < pinchartl> dammsan: ping +09:20 < pinchartl> we're missing Morimoto-san +09:20 < pinchartl> kbingham: ping +09:20 < wsa_> Add. tasks are possible on request which then are discussed by Renesas +09:20 < dammsan> wsa_: port 9006 is yours +09:20 < wsa_> but no request was made to me, and I don't see one urgent in my list +09:20 < wsa_> dammsan: thanks! +09:21 < kbingham> hola +09:21 < dammsan> pinchartl: whatsup? +09:21 < wsa_> so, doesn't look like add. tasks for IO +09:22 < shimoda> pinchartl: Morimoto-san has a trouble about his PC network setting on Ubuntu 18 :) +09:22 < wsa_> dammsan: unless there is something new I don't know up to now? :) +09:22 < pinchartl> dammsan: Wolfram mentioned additional tasks +09:22 < pinchartl> I requested that to be added to the agenda +09:22 < pinchartl> as this topic concerns all groups, should we discuss it now ? +09:23 < wsa_> Frankly, I am more interested in the base time distribution again +09:23 < dammsan> sure what do you want to know? +09:24 < pinchartl> dammsan: I want to know how we can get additional tasks working +09:24 < pinchartl> as in scheduled in time +09:24 < wsa_> horms: I assume you are so busy backporting LTSI that ravb upporting had to stand back? +09:24 < pinchartl> and not repeat the Q2.2 fiasco +09:24 < dammsan> well i think we need to do two things: +09:24 < pinchartl> we've had a lengthy e-mail discussion but that wasn't public, so I'd like to broaden the audience as I don't think I'm the only one to be bothered by this +09:24 < dammsan> 1) agree on quarterly schedule for meeting dates and additional due dates first +09:25 < horms> wsa_: correct +09:25 < shimoda> wsa_: after discuss about add. task, I'd like to ask you about i2c recovery. Did you see any issues (e.g. write data to a slave wronglty) on your R-Car environment? +09:25 < dammsan> 2) do task break out ahead of time +09:25 < horms> wsa_: also, I think that the ravb backporting is a very low yeild exercise +09:25 < dammsan> pinchartl: who else is bothered? +09:25 < pinchartl> kbingham: the mic is yours :-) +09:26 * kbingham has just about caught up wit hthe mornings mails ... +09:26 < pinchartl> who thinks additional tasks work just fine, and who tihnk they don't ? +09:26 < pinchartl> s/tihnk/thinks/ +09:26 < wsa_> shimoda: sure! +09:26 < kbingham> dammsan, I agree where you said this needs an F2F ... and fortunately one is coming up :) +09:26 < kbingham> Lets make sure we have time :) +09:26 < wsa_> horms: "low yield" means most patches are not suitable for upstream? +09:26 < dammsan> unfortunately not all members are present +09:27 < geertu> Personally, I've never been a big fan of additional tasks. +09:27 < horms> wsa_: yes, I think so +09:27 < horms> But I'll go over them again +09:27 < kbingham> Essentially - for me -the *big* problem is the 'rigid square wave workload' which it causes me. +09:27 < pinchartl> I've never been a big fan of additional tasks either. they were a minor nuisance when they were introduced, but they got more and more annoying over time as they got split in two batches per quarter, and we always got late negotiating them +09:28 < wsa_> "square wave workload" :D +09:28 < kbingham> But in particular - where the due dates are fixed, but tasks are always started late. +09:28 < kbingham> I realise that this last AT is a bit of a special case - but my concerns with planning have started long before. +09:28 < uli___> if i may weigh in: i like that additional tasks tell me what to do; i'm not a self-starter when it comes to work... +09:29 < uli___> the contractual framework is secondary to me +09:29 < kbingham> And it's just this one has been a cliff-edge drop for me :( +09:29 < geertu> kbingham: One very important thing to consider is that this is a prototype +09:29 < dammsan> so historically they were created to allow lower latency operation for our group +09:29 < geertu> which means many more unknowns than "normal" additional tasks +09:30 < dammsan> as opposed to have all the fixed tasks agreed on 3 months ahead +09:30 < pinchartl> dammsan: they have created a much higher latency +09:30 < geertu> IMHO they increase latency. +09:30 < dammsan> sure +09:30 < dammsan> but how can we keep the quality and perform development (not single patch wanking) and reduce paper work? +09:30 < geertu> If something is urgent, there may not be any base time available at that moment, as ATs have a fixed deadline, and thus preempt any base work +09:31 < kbingham> uli___, I also like that an AT specifies what to do - but in the latest case - that didn't happen - until it was too late for me to realistically be able to deliver that. +09:31 < pinchartl> in my opinion, they only advantage in additional tasks, and the reason why they have been introduced, is to give a stick to Renesas to hit developers who don't deliver. with fixed deliverables and fixed due dates the work has to be completed, no excuse +09:31 < pinchartl> apart from that I see no use for additional tasks +09:32 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi +09:32 < geertu> An AT deadline around the closing of a maintainer's merge window causes patches to be delayed by one kernel release. +09:32 < geertu> pinchartl: +1 +09:32 < wsa_> horms: if you could add what you currently know to the periupport list? so, we at least know which patches to "drop" +09:32 < dammsan> so we have been discussing dropping AT before +09:33 < dammsan> but at that point i requested some way to get plans from the group leaders +09:33 < horms> wsa_: sure, sorry for not having already done that +09:33 < pinchartl> dammsan: we can reduce paperwork and increase quality by dropping additional tasks completely and measuring performances to make sure we don't slow down (or even sleep) +09:33 < dammsan> this was last year i recall +09:33 < pinchartl> alternatively, we can keep fixed-price, fixed-term tasks, but with a higher latency. they *have* to be negotiated in advance +09:33 < dammsan> it is not a matter of increasing speed +09:34 < pinchartl> that is a contract has to be signed at least 2 months before the due date +09:34 < dammsan> it is a matter of improving visibility and communication +09:34 < jmondi> toothless jmondi's here +09:35 < dammsan> i will ask renesas if they can start considering 2 month delay +09:35 < dammsan> it is perfect for the last quarter of this year +09:35 < pinchartl> if the goal is to improve visibility and communication, then let's focus on that +09:35 < dammsan> until that time perhaps it is best that we drop additional tasks all together? =) +09:36 < dammsan> please note that some pipe lining is required +09:36 < pinchartl> dammsan: and I will also say that I agree we need to measure performances +09:36 < dammsan> one thing is the performance +09:36 < dammsan> another thing is to agree on what to do +09:37 < dammsan> i would like to have both +09:37 < kbingham> I'd like to not have high pressure workloads with short timescales :D +09:37 < dammsan> sure +09:37 < kbingham> I'd go join a tiger team if I wanted that ;D +09:38 < dammsan> but tell me how your 5 weeks can be split onto the existing slots +09:38 < neg> That is what I like about additional contracts, it provieds me with a clear channel from Renesas on what new task/feature is moste valuable for them and therefor I should focus on it. +09:38 < pinchartl> neg: I can only agree partially to that +09:39 < pinchartl> we are tasked with proposing additional tasks +09:39 < Marex> I have to admit, I like my kinda-free reign over U-Boot, since I can focus on doing what needs to be done when it needs to be done +09:39 < pinchartl> without being told what Renesas needs +09:39 < Marex> but maybe Im wrong :) +09:39 < pinchartl> so we try to guess +09:39 < kbingham> Marex, Do you not have additional tasks ? +09:39 < pinchartl> and then we are either told that the guess was right +09:39 < dammsan> he does but he prefers not to consume them +09:39 < pinchartl> or that it was wrong, in which case we are asked to guess again +09:39 < Marex> kbingham: I do, but I can live with that +09:40 < dammsan> what a nice fellow =) +09:40 < pinchartl> neg: I don't count that as being told by Renesas what is valuable for them :-) +09:40 < dammsan> pincharl: you seem to think the content of the bsp up porting list is enough +09:41 < neg> pinchartl: agreed, sometime the planing and late scheduling/decision point for a add. task is messy and creates higher workload. All I'm saying is that for me the task once scheduled provieds value +09:41 < pinchartl> Marex: I think most of us would like to focus on what needs to be done when it needs to be done, with additional inputs from Renesas when they have specific urgent needs +09:42 < dammsan> so may i ask if fixing the quarterly dates ahead of time has any drawback? +09:42 < kbingham> dammsan, What benefit are you addding with fixed dates... +09:42 < dammsan> i am not saying it solves all the problems +09:42 < pinchartl> dammsan: do you mean the Q2.1 and Q2.2 due dates, as in Q+1.5 and Q+2.5 ? +09:42 < kbingham> the 'due dates' are already predictable ... +09:42 < dammsan> this means we are clear about the dates +09:43 < dammsan> yes and meeting dates for chat meetings +09:43 < dammsan> if we agree on these ahead of time +09:43 < pinchartl> kbingham: the due dates are not just predictable, they are fixed :-) +09:43 < dammsan> and yet we fail to schedule tasks, then we won't schedule any tasks +09:43 < kbingham> :) +09:43 < pinchartl> dammsan: but we have already agreed, haven't we ? +09:44 < dammsan> i thought we had agreed to the AT due dates somehow +09:44 < dammsan> but yet it seems that the discussion of no time available and conference timing seems to happen again and again =) +09:44 < geertu> dammsan: Agreed as in: yes, let's use the dates Jinso needs the deliverables? +09:44 < dammsan> so if we know ahead of time.. +09:44 < pinchartl> dammsan: no, the problem isn't conference timing, the problem is late scheduling +09:45 < kbingham> If I'm going to 'lose' 3 weeks of work - then I need to know in advance - so I can find another three weeks of work to fill that time. Or Hugo losses his college fund! +09:45 < pinchartl> conferences and other events happen from time to time +09:45 < pinchartl> I can handle them by myself +09:45 < dammsan> kbingham: sure understood +09:45 < pinchartl> if you give me 3 weeks of work 6 weeks ahead of the due date +09:45 < pinchartl> I'll work around the conference that happens during those 6 weeks +09:45 < dammsan> makes sense +09:45 < pinchartl> if you give me 3 weeks of work 3 weeks ahead of the due date, that won't be possible +09:45 < geertu> pinchartl: Now, if you have 2x3 weeks of AT... +09:46 < pinchartl> and that's what is happening all the time +09:46 < pinchartl> in the best case we get the AT for 3 weeks of work 3 weeks ahead of the due date... +09:46 < dammsan> that seems to be because we don't do bre +09:46 < pinchartl> sometimes it's even later +09:46 < wsa_> kbingham: Hugo should be a rich kernel developer at college time, or? ;) +09:46 < dammsan> akout early enough +09:47 < kbingham> wsa_, I'm hoping he'll be a kernel developer at primary school :D +09:47 < pinchartl> dammsan: what do you mean by not breaking out early enough ? +09:47 < dammsan> well +09:47 < dammsan> for instance this virtualization topic +09:47 < dammsan> i wish we could meet and discuss how to proceed with that +09:47 < dammsan> now we have not met so much recently +09:47 < dammsan> and when we met in san sebastian the purpose seemed more to be for hacking than planning +09:48 < dammsan> i would like to meet with group leaders (+ others maybe) to do some planning +09:48 < pinchartl> I don't think we could have planned work for Q2 2018 in detail in San Sebastien +09:48 < pinchartl> there are various ways to meet, face to face or online +09:48 < kbingham> dammsan, I get that it was a communications issue - but in the Virt task - I was only told that *I* was supposed to write the task descriptoin - well after the point at which I would have expected to start the task - - hence for me - it's just impossible to fit in to a schedule in this current instance. +09:49 < dammsan> ok but i got the impression that you wanted to do the task? +09:49 < dammsan> i was pleasantly surprised that you signed up =) +09:49 < dammsan> obviously it was a too big jump +09:49 < pinchartl> dammsan: in general I think most of us are willing to help with work that is considered to be important by Renesas or you +09:49 < pinchartl> that shouldn't be a surprise :-) +09:49 < geertu> Exactly. +09:50 < dammsan> sure +09:50 < dammsan> i feel that +09:50 < dammsan> thanks for your help +09:50 < geertu> kbingham: You should have had some idea of what the task as about when volunteering, right? +09:50 < dammsan> but how to plan? +09:50 < dammsan> (and break out) +09:50 < kbingham> I knew very little about the task. +09:50 < dammsan> (that makes you the brave man in the room) =) +09:51 < kbingham> We are trying to hunt in the dark for tasks to fit into slots. +09:51 < kbingham> From my perspective - laurent said that dammsan wants us to look into virtualisatoin topics ... +09:51 < dammsan> sorry for being unclear +09:51 < kbingham> And thus I was expeting a virt topic to fill my available slots +09:51 < kbingham> However - I was expecting it to have been planned early - and be clear so that I could ramp up +09:52 < dammsan> but we had not done enough break out +09:52 < dammsan> also i feel we are moving slowly +09:52 < dammsan> probably due to lack of resources +09:52 < kbingham> I don't even mind if it would take me longer than the available time slots to do the investigation / self learning / and ramp up - but for that to happen - +09:52 < kbingham> the task *must start weeeeeellll in advance* +09:52 < dammsan> i would love to ask geertu to focus on virt activities +09:53 < dammsan> but without AT i feel i cannot request stuff +09:53 < kbingham> I see AT time slots as time slots that I reserve in my planning for to allow Renesas to fill with tasks. +09:53 < kbingham> But they can't be booked or not booked with zero notice. +09:53 < dammsan> kbingham: that view makes sense +09:54 < dammsan> but the default IMO is unbooked unless otherwise agreed +09:54 < horms> dammsan: when you say break out, do you mean you think it would help if there were more face-to-face meetings between say yourself and group leaders? +09:54 < dammsan> horms: yes +09:54 < dammsan> thank you +09:54 < horms> ok, I see a farily obvious way to see if that helps +09:54 < pinchartl> dammsan: unbooked unless otherwise agreed isn't something I can agree on as long as we book at the last minute +09:55 < pinchartl> if you want that, then I want to be booked 3 months in advance +09:55 < kbingham> So I should assume that 6/12 weeks of my time are not scheduled - and find another customer to fill that time ? +09:55 < pinchartl> as Kieran said in an e-mail, you don't expect to call a builder for your house and have him show up the next morning +09:55 < dammsan> sure, that fits perfectly fine with current budget situation =) +09:56 < kbingham> Ok - if we have budget restrictions - can we be clear about that!? +09:56 < pinchartl> there were no budget restrictions for Q2, were there ? +09:56 < dammsan> sorry if that has not communicated enough +09:56 < dammsan> but ATs are not guaranteed to be filled +09:56 < pinchartl> dammsan: it has been communicated badly, as in "beware of the big bad wolf" +09:57 < dammsan> never has been, and they are getting closer to be more sparse if budget is going bad +09:57 < kbingham> (beware, followed by - but don't go away) +09:57 < dammsan> well +09:57 < dammsan> it was actually my proposal to renesas side to tell you in advance +09:57 < dammsan> before you signed your base contracts +09:57 < dammsan> that budget is looking bad +09:57 < dammsan> so you should look into other options if you want to sustain +09:58 < neg> I think the budget situation have been communicated and also that there are possibilities that not all additional task slots will be used. Is this not why the base time was adjusted? +09:58 < dammsan> of course i want to work to with you +09:58 < dammsan> neg: yes +09:58 < dammsan> but i can't control our budget +09:58 < kbingham> Ok - but if AT's are not to be filled - they need to be filled with something else +09:58 < dammsan> especially if i can't make plans to show to renesas side +09:58 < kbingham> and tha'ts not possible - if the AT is filled at the last minute +09:59 < pinchartl> dammsan: why have additional tasks for Q2.2 not been scheduled in time, as there was no budget restriction for that period ? +09:59 < dammsan> kbingham: we seem to have different ideas how the contracts work +10:00 < kbingham> dammsan, I agree :) +10:00 < dammsan> what says that there was no budget restriction that period? +10:00 < dammsan> i was asked to reduce cost +10:00 < dammsan> i asked to reduce travel +10:00 < dammsan> did not to to EU +10:00 < dammsan> now if other members ask renesas directly +10:01 < dammsan> and they change their mind over a week +10:01 < dammsan> then it is not my problem +10:01 < kbingham> It's a shame you could not come to EU brussels - as it would have been good to do F2F then... :( +10:01 < dammsan> i agree +10:01 < pinchartl> dammsan: when we discussed additional tasks for Q2.2 there was no budget issue that was brought up, and tasks were agreed on to fill slots (but too late to be completed on time) +10:02 < dammsan> i have no intention to reduce the slots just for the sake of it +10:02 < dammsan> but we need to know what to do before doing it +10:02 < dammsan> and like my old fried paul said +10:02 < dammsan> you don't pay contractors to learn +10:02 < dammsan> you pay contractors to do what they are good at +10:03 < dammsan> of course some ramp up time is needed +10:03 < dammsan> and acceptable +10:03 < dammsan> but either you can do what you say +10:03 < dammsan> or you cant +10:03 < kbingham> dammsan, I actually agree on that - +10:03 < dammsan> and if we cant agree before the due date +10:03 < dammsan> too bad +10:03 < kbingham> That's why I expected the virt work to be planned well in advance :) +10:03 < dammsan> sure +10:04 < dammsan> so we had a some kerfuffle there +10:04 < dammsan> and in general when it comes to task break out and planning that may happen +10:04 < dammsan> probably my fault as usual +10:04 < dammsan> =( +10:04 < dammsan> but i stand by that we need to know before we do it +10:04 < pinchartl> it's not that it may happen, it happens all the time :-( that's for me a clear indication that the process is wrong +10:05 < dammsan> sure +10:05 < dammsan> but ive asked for plans forever +10:05 < dammsan> i would like to improve the situation +10:05 < pinchartl> I can't make a plan without being able to allocate resources +10:05 < dammsan> well +10:05 < pinchartl> I can't say what we'll do and when we'll do it if I'm not given a predictable amount of development time +10:05 < kbingham> I think we're well in to the territory of best discussed F2F :) +10:06 < kbingham> which is conveniently in 2 weeks or less. +10:06 < dammsan> i would like to separate assignment from planning +10:06 < dammsan> also time required from planning +10:06 < dammsan> only focus on break out and dependencies +10:06 < dammsan> i would like to discuss this with group leaders +10:06 < dammsan> ahead of time +10:07 < dammsan> then from the result of that activity feed AT and base work +10:07 < dammsan> if we manage to move forward with base only then we can skip AT +10:07 < dammsan> but dropping AT without any plans seems insane to me +10:08 < dammsan> kbingham: sorry that it became a mess +10:08 < pinchartl> so how do we move forward ? +10:08 < dammsan> how can we proceed? +10:09 < dammsan> i proposed my two ideas to improve the planning +10:09 < pinchartl> my requirement is that anything with a fixed due date has to be scheduled (as in contracts signed) at due date - max(2 * duration, duration + 2 weeks) +10:09 < dammsan> dates ahead of time + separate planning and breakout +10:09 < pinchartl> (the numbers can be fine-tuned +10:09 < dammsan> pinchartl: i want to agree as early as you +10:10 < dammsan> but we need to work together to break out stuff +10:10 < dammsan> and say that we are late +10:10 < dammsan> what happens then? +10:10 < dammsan> i don't want to be late +10:10 < dammsan> but if we end up there anyway? +10:10 < pinchartl> if you remember, I initially proposed a long list of tasks, and most got rejected with "this should be base time" or "this isn't a priority". I was then suppose to magically come up with new ides +10:11 < dammsan> also, crossi +10:11 < dammsan> ng quarterly boundaries is difficult +10:11 < dammsan> pinchartl: sorry if i made you feel rejected +10:11 < pinchartl> if we always end up being late we'll reach a point where stress and frustration will be so high that we'll lose developers completely. it won't just be a matter of some slots not being filled, people will go away +10:12 < dammsan> i understand. that's no good +10:12 < dammsan> but lets agree on a view with the contracts +10:12 < dammsan> no contract means no agreement +10:12 < dammsan> when it comes to assigned work +10:12 < pinchartl> if Renesas prefer stopping upstream development and only release BSPs, I won't stop them +10:13 < dammsan> well +10:13 < dammsan> if renesas can chose by themselves then we all have been reduced to up-porting machines +10:13 < dammsan> so no development on the horizon there no +10:13 < pinchartl> I'm sure they can find plenty of cheap developers who can write bad code +10:13 < dammsan> yep +10:13 < dammsan> we agree on that +10:13 < dammsan> so question is how to remedy that situation +10:14 < dammsan> without leaving people in a bad situation +10:14 < dammsan> also +10:14 < pinchartl> and if they prefer going that way, I have no issue making sure those bad patches won't make it to mainline +10:14 < dammsan> i don't want people to think they should be spoon fed with work +10:14 < dammsan> i want to share the burden of breaking out stuff with you +10:15 < dammsan> so we can collaborate to learn what next steps we need to take +10:15 * kbingham doesn't full understand what "breaking out stuff" means +10:15 < kbingham> Is that investigation and planning ? +10:15 < dammsan> kbingham: both perhaps +10:15 < pinchartl> by trying to move away from spoon-feeding and asking people to come up with task ideas for themselves, with such a fine-grained control, we have reached a situation that reminds me of kids in school who have to ask permission to go to the toilet +10:15 < dammsan> i asked for the dma virtualization topic +10:16 < dammsan> but in reality pinchartl found it to be 4 subtasks +10:16 < dammsan> unfortunately the ordering was odd +10:16 < pinchartl> dammsan: and it shouldn't have been my job to breakout a core task... +10:16 < dammsan> so we did the paper work before the so it happened after the contract was finalized =) +10:17 < dammsan> pinchartl: it seems that your role as coworked of kbingham might be conflicting with group leader +10:17 < dammsan> so i think we need to be more clear +10:18 < dammsan> kbingham: do you understand what i mean by breakout now? +10:18 < pinchartl> dammsan: I don't see a conflict. if you expect developers to work with group leaders to break out tasks I'm fine with that. what I disliked here is that Kieran and I were supposed to do the work all by ourselves +10:18 < kbingham> 'breakout = create additional task details' +10:18 < dammsan> kbingham: and split into subtasks +10:18 < kbingham> Yes - I was about to add that ;) +10:19 < dammsan> if we would have broken out ahead of time +10:19 < dammsan> then we could have assigned you something smaller instead +10:19 < dammsan> pinchartl: it was unclear about responsibility for sure +10:20 < dammsan> so how to proceed in the short term? +10:20 < dammsan> i proposed serial pass through only or also include clocks like you mentioned before +10:21 < pinchartl> today is June the 7th. the due date is the 15th. I'll let Kieran decide as this is his task, but personally I think it's too late to do anything +10:22 < dammsan> i have been told we may push back the due date until later this month +10:22 < dammsan> but you have your travels too +10:22 < kbingham> for available time remaining, I think perhaps dropping that to a 5 day task to cover the investigation already completed, and we can consider revisiting the task for next quarter. +10:23 < dammsan> kbingham: so serial pass through only? +10:23 < dammsan> which due date would you like? +10:23 < dammsan> is 15th ok or is later better? +10:23 < kbingham> I have got serial pass through working - so I don't mind the usual due date for that. +10:23 < dammsan> good! +10:24 < dammsan> can you email me your proposal how to change the text? +10:24 < kbingham> Sure I'll do that after the meeting. +10:24 < dammsan> perfect - thanks +10:24 < dammsan> i'll deal with this later today +10:25 < dammsan> so as final topic, how can we agree on the same view for the contracts +10:25 < dammsan> ? +10:25 < kbingham> dammsan, By sitting down with a beer. +10:25 < dammsan> alrighty =) +10:26 < dammsan> geertu: what do you think about agreeing on dates one quarter ahead of time? +10:26 < kbingham> :D +10:26 < geertu> dammsan: due dates and meeting dates? +10:26 < dammsan> wsa_: and what do you think about agreeing on dates one quarter ahead? +10:26 < dammsan> yeah +10:27 < geertu> What does that solve? We know the due dates, and can guess meeting dates (about every two weeks)? +10:27 < wsa_> for add. tasks? +10:27 < pinchartl> dammsan: haven't we agreed on due dates until the end of times already ? they're at Q+1.5 and Q+2.5. what else is there to agree on ? +10:27 < dammsan> chat meeting dates +10:27 < dammsan> so we know when we have to fix the AT titles + descriptions +10:27 < geertu> Do we have an issue with not knowing all future chat meeting dates? +10:28 < dammsan> we have an issue with AT creation which operates on chat meeting tick +10:28 < horms> dammsan: the chat meeting dates seem pretty predictable from my side +10:28 < horms> is the problem that sometimes we skip a week? +10:28 < pinchartl> dammsan: why don't we then decouple AT creation and chat meetings ? +10:28 < pinchartl> we can have ad-hoc meetings to create ATs +10:29 < dammsan> horms: sspinchartl: i agree if we can schedule break out meetings first =) +10:29 < dammsan> horms: no problem i think +10:29 < horms> sorry, the breakout term is very confusing to me +10:30 < horms> do you mean meetings to break out AT tasks? +10:30 < dammsan> tasks in general +10:30 < dammsan> that may or may not turn into AT +10:30 < horms> Ok, so task discussion meetings, separate from our regular meetings? +10:30 < geertu> Don't we usually handle AT titles over email? Decoupled from chat meeting? +10:30 < dammsan> if we have a bunch of tasks already broken out +10:30 < kbingham> https://paste.ubuntu.com/p/JcT9DrMQkT/ :D +10:31 < dammsan> then those should be easier to assign +10:31 < dammsan> horms: these discussions take time +10:31 < dammsan> and usually they get lower priority than actual hacking +10:32 < dammsan> and with travels and conferences and whatnot +10:32 < dammsan> it seems that we so far have not been able to come up with any plan (visible to me) +10:32 < pinchartl> dammsan: what kind of plan to you expect ? +10:32 < dammsan> a good example is the dma virtualization topic +10:33 < dammsan> you broke it out into 4 subtasks +10:33 < pinchartl> as I said, I can't create a plan with dates as I don't have development time I can assign to tasks +10:33 < dammsan> no need for dates +10:33 < dammsan> or time estimates +10:33 < dammsan> only titles and dependencies +10:33 < pinchartl> so if there's no date or time estimate, what kind of plan do you expect ? +10:33 < dammsan> maybe some details if possible +10:33 < pinchartl> a list of tasks ? +10:33 < dammsan> yes +10:33 < dammsan> with dependencies +10:33 < dammsan> for instance, clocks are missing from QEMU +10:33 < dammsan> so lets include a prototype task for that +10:34 < dammsan> before we do real development +10:34 < pinchartl> to find that out, nearly 5 days of work were needed. how could we have found out in a better way ? +10:34 < dammsan> we could have done it at aa different time IMO +10:34 < dammsan> maybe we should have aimed at serial pass through instead of going directly to DMA virt +10:35 < pinchartl> yes, but how ? what should have triggered that investigaion ? +10:35 < dammsan> serial pass through prototype? +10:35 < pinchartl> ok +10:35 < pinchartl> is it acceptable, when we schedule a prototype AT, to not deliver the expected prototype ? +10:35 < dammsan> or us sitting down and looking of +10:35 < dammsan> at what is needed? +10:35 < pinchartl> when features are missing for instance +10:35 < pinchartl> sitting down for 5 days ? :-) +10:35 < dammsan> we need deliverables +10:35 < pinchartl> it really required work +10:36 < dammsan> sure no doubt about that +10:36 < dammsan> (that's why i don't want to do it myself) =) +10:36 < dammsan> anyway +10:36 < dammsan> we can set aside base time +10:36 < pinchartl> in my opinion, there's no guarantee that a prototype can be delivered, ever +10:36 < dammsan> and meet and discuss these things over some time +10:36 < dammsan> then we are aiming too high +10:36 < pinchartl> by definition we create prototypes when the risk is high +10:37 < dammsan> so far all prototypes have been delivered =) +10:37 < pinchartl> and so we can run into blocking issues that can't be solved within the scheduled time frame +10:37 < dammsan> well, you take shortcuts +10:37 < pinchartl> so far we're had a combination of luck and dipping in base time. I don't think that's something we want to rely on as a rule +10:37 < dammsan> and if you cant then you have aimed too high +10:38 < dammsan> i'm open to suggestions though +10:38 < pinchartl> you can't know for sure how to aim, that's the whole point of prototypes +10:38 < dammsan> if you have any other ideas how to figure it out +10:38 < pinchartl> and taking shortcut can be acceptable to some extent +10:38 < pinchartl> but if we end up rushing to deliver something by taking too many shortcuts, then we delivere useless crap +10:38 < pinchartl> and waste time and money +10:38 < dammsan> there is a balance for sure +10:38 < pinchartl> in this specific case +10:39 < pinchartl> you could rush to create lots of hacks that will allow serial pass-through +10:39 < pinchartl> or start working on the missing features and not deliver the pass-through in time +10:39 < pinchartl> in the first came the patches will be garbage, nobody will ever use time +10:39 < kbingham> If a task 'suggestion' has begun - Investigtiaons and breakout - can simply occur in base time - in the quarter before>? +10:39 < dammsan> yeah? +10:39 < pinchartl> while in the second case the time is invested in a more productive and useful way +10:40 < dammsan> pinchartl: except the second does not consider the output of broken out tasks as useful +10:40 < pinchartl> dammsan: sorry, I didn't get that +10:40 < dammsan> kbingham: i agree +10:40 < dammsan> no sane person will take a prototype and put it into production +10:41 < kbingham> dammsan, Great - so we just need to get task suggestions started early. +10:41 < dammsan> but we can learn various things from it +10:41 < pinchartl> it's not about putting things into production +10:41 < dammsan> of course the ultimate goal is to solve the problem +10:41 < dammsan> but we need to learn what the problems are too +10:41 < dammsan> to know what we need to do +10:42 < dammsan> is it any more clear? +10:42 < pinchartl> if you spend 5 days learning about the issues and finding out what has to be solved, and have 5 days of budget left, consuming the remaining 5 days to write throw-away hacks just to tick the "done" box in the report is useless +10:42 < pinchartl> prototypes are valuable to find out about issues +10:43 < pinchartl> but once the issues are known it's pointless to create the dirtiest hacks just to check a box +10:43 < dammsan> if the prototypes happened by themselves then i would be the happiest man on the planet =) +10:43 < pinchartl> some hacks can be useful when they allow moving to the next step and finding about the next problem +10:43 < dammsan> the question is how the issues become known =) +10:43 < geertu> The hacks are useful to unblock you, and continue getting it to work, perhaps finding more issues to solve later. +10:44 < dammsan> geertu: yes +10:44 < pinchartl> or when they make a dependency for another task available faster than the proper solution +10:44 < geertu> Ineed, you won't know about the issues if you don't try. +10:44 < pinchartl> but if nothing else depends on your prototype, more hacks after all problems are known become throw-away code +10:44 < dammsan> i believe prototypes should be quick hacks +10:45 < dammsan> and i think my request to you was over reaching =) +10:45 < pinchartl> I think it's time to wrap this discussion up +10:45 < pinchartl> can we schedule a face to face discussion in Tokyo ? +10:45 < dammsan> sure, but how to make non-present members not feeling omitted? +10:46 < pinchartl> geertu: I think that question is for you +10:46 * geertu is wondering about this recent invention called "tubes", or "the Internet" +10:46 < dammsan> this travel planning is a cluster flower +10:47 < dammsan> geertu: i need to read the friendly manual =) +10:47 < pinchartl> dammsan: we have been told that there's no travel budget, and now we find out a face to face meeting is needed. there's an unavoidable conflict between those two :-) +10:47 < dammsan> i know - welcome to my life +10:47 < dammsan> i don't recommend it +10:48 < pinchartl> dammsan: I have never doubted that I'm not the only person to be frustrated by this :-) +10:48 < geertu> pinchartl: fall-out from the lack of travel budget around FOSDEM? +10:48 < pinchartl> so how can we schedule a meeting ? +10:48 < horms> dammsan: I recommend you have a f2f meeting. If its possible let people know so they can post questions via chat or etherpad. But likely it won't be due to times zones, being in a bar, ... So pleasae provide some sort of summary so a follow-up discussion can occur via chat or email +10:49 < horms> s/please/I recommend/ +10:49 < dammsan> horms: sounds good +10:49 < dammsan> thanks +10:49 < dammsan> pinchartl: when are you guys available? +10:50 < pinchartl> for me, Wednesday, Thursday, Saturday, Sunday, +10:50 < kbingham> My talk is on the Thursday. +10:51 < kbingham> but it might be scheduled early - so after would be fine. +10:51 < pinchartl> my talk is on Friday at 15:15, so starting at 16:00 Friday is fine too +10:51 < dammsan> i have some plans sat + sun +10:51 < wsa_> not the weekend, please +10:52 < pinchartl> how about Wednesday then ? +10:52 < wsa_> how about we get some weapons at the NinjaRestaurant and fight it out? ;) +10:52 < neg> All OSS-J days and the weekend works for me +10:52 < dammsan> sure +10:52 < neg> wsa_: I like your style +10:52 < dammsan> 20th, right? +10:53 < wsa_> wednesday morning? +10:53 < wsa_> or did someone here want to go to the keynotes? ;) +10:53 < dammsan> in a ditch in east shinjuku =) +10:53 < pinchartl> wednesday morning sounds good, there are only keynots +10:53 < kbingham> Wednesday morning works :) +10:53 < neg> +1 +10:53 < pinchartl> 9:00 on Monday ? +10:54 < pinchartl> we might be able to host the meeting at our apartment +10:54 < pinchartl> who wants to join ? +10:54 < wsa_> monday? +10:54 < pinchartl> sorry +10:54 < pinchartl> Wednesday +10:54 < geertu> If you want people in EU to join, morning meetings may not be the right time... +10:55 < wsa_> wed 09:00 is fine with me +10:55 < wsa_> and if your apartment turns out to be not big enough, we will surely find a place at the conference +10:55 < wsa_> with only keynotes going on +10:56 < pinchartl> geertu: attending remotely would require a properly A/V equipped room. I don't know if we could get that +10:56 -!- shimoda [~shimoda@relprex2.renesas.com] has quit Read error: Connection reset by peer +10:56 < dammsan> morimoto-san seems to suggest 18 or 19 =) +10:57 < dammsan> but from my side +10:57 < dammsan> if we have this kind of business meeting then reneeesas should pay for airfares IMO +10:57 < pinchartl> dammsan: I'll fly in on the 18th, and on the 19th there's a whole day V4L2 meeting that I need to attend to make sure the right design decisions will be taken +10:57 < dammsan> pinchart: gotcha +10:58 < pinchartl> otherwise I would have proposed Tuesday +10:58 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi +10:58 < pinchartl> we might be able to to Tuesday evening, but it's probably better to start fresh +10:58 < wsa_> yes +10:59 < morimoto> all: I'm OK for Web +10:59 < pinchartl> I agree with Simon, I think we should start proposing ideas over e-mail first, so that everybody can express themselves +10:59 < dammsan> for anyone in town the weekend before is also possible from my side +10:59 < pinchartl> send the minutes of the discussions after the meeting +10:59 < pinchartl> and then wrap up with an online discussion for the final agreement so that nobody is left out +10:59 < wsa_> then again, being tired in a bar might also help to keep it short :D +11:00 < dammsan> i think we need several opportunities to vent =) +11:00 < pinchartl> wsa_: I want short and productive, but I'd rather have long and useful than short and useless :-) +11:00 < dammsan> so the more the better +11:00 < dammsan> pinchartl: is this on of those "size matters" discussions? +11:01 < pinchartl> so can we wrap up now ? +11:02 < dammsan> wednesday it is then? +11:02 < pinchartl> yes +11:02 < wsa_> booked +11:03 < neg> 09:00 what location? +11:03 < pinchartl> neg: possibly our apartment, or if it's too small, somewhere else +11:04 < pinchartl> geertu: I think the mic is now yours for the core meeting diff --git a/wiki/Chat_log/20180607-mm-chatlog b/wiki/Chat_log/20180607-mm-chatlog new file mode 100644 index 0000000..861a049 --- /dev/null +++ b/wiki/Chat_log/20180607-mm-chatlog @@ -0,0 +1,147 @@ +Multimedia-chat-meeting-2018-06-07 + +11:32 < pinchartl> welcome to the multimedia meeting +11:32 < pinchartl> topic 1, status updates +11:32 < pinchartl> * Jacopo +11:32 < pinchartl> Since last meeting: +11:32 < pinchartl> - VIN parallel input +11:32 < pinchartl> [PATCH v5 0/10] rcar-vin: Add support for parallel input on Gen3 +11:32 < pinchartl> [PATCH v3 0/8] media: rcar-vin: Brush endpoint properties +11:32 < pinchartl> Very close to having this finalized. The work hasn't been rushed as we were late for v4.18 already. +11:32 < pinchartl> - SOC camera removal +11:32 < pinchartl> [PATCH 0/5] Remove sh_mobile_ceu_camera from arch/sh +11:32 < pinchartl> Remove all sh_mobile_ceu_camera dependencies from arch/sh. This means no more soc_camera users in mainline \o/ +11:32 < pinchartl> - MT9V111 camera module +11:32 < pinchartl> The gr-peach audiocamera shield comes with a camera module equipped with MT9V111 image sensor for which there's currently no support in Linux. Driver is very close to be complete, only missing support for extended controls. +11:32 < pinchartl> - CEU improvements +11:32 < pinchartl> While developing support for the mt9v111 camera module: +11:32 < pinchartl> - [PATCH] media: renesas-ceu: Add support for YUYV permutations +11:32 < pinchartl> - [RFC] media: renesas-ceu: Add media-controller support +11:32 < pinchartl> Until next meeting: +11:32 < pinchartl> - Complete and upstream MT9V111 camera module support +11:32 < pinchartl> - Upstream audiocamera shield DTS support +11:32 < pinchartl> - Find out why the Mt9T112 camera module does not work +11:32 < pinchartl> - Start preparing for Japan trip! +11:32 < pinchartl> Issues and Blockers: +11:32 < pinchartl> - The gr-peach audiocamera shield is a daugther board that can be separately purchased and plugs on top of gr-peach. What is the policy for such add-on boards DTS files? Can they be upstreamed? +11:32 < pinchartl> jmondi: any comment ? +11:34 < pinchartl> Jacopo might be away trying to get toothache under control +11:34 < pinchartl> * Kieran +11:34 < pinchartl> Since last meeting: +11:34 < pinchartl> - TLB-Optimise - Now integrated +11:34 < pinchartl> - Minor field not documented - sent patch to fix. +11:34 < pinchartl> - 'Fault tolerant V4L2' (will integrate concept to be part of my GMSL talk) +11:34 < pinchartl> - Schedule Planning +11:34 < pinchartl> - GMSL patches squashed, rebased and posted \o/ +11:34 < pinchartl> Until next meeting: +11:34 < pinchartl> - Prepare GMSL talk +11:34 < pinchartl> - Japan OSS/ALS +11:34 < pinchartl> Issues and blockers: None +11:34 < pinchartl> kbingham: any comment ? I've left out the DMAC parts as that's core +11:34 < kbingham> No - that's fine I think +11:34 < pinchartl> * Laurent +11:34 < pinchartl> Since last meeting: +11:34 < pinchartl> - Resubmitted pending patches +11:34 < pinchartl> - Patch review +11:34 < pinchartl> - Multimedia upport list update +11:34 < pinchartl> Until next meeting: +11:34 < pinchartl> - Display virtualization +11:34 < pinchartl> - OSSJ talk preparation +11:34 < pinchartl> - OSSJ +11:34 < pinchartl> - V4L2 meeting @OSSJ +11:34 < pinchartl> Issues and blockers: +11:34 < pinchartl> - Additional tasks are scheduled too late, resulting in stress and frustration. +11:35 < pinchartl> * Magnus: +11:35 < pinchartl> Since last meeting: None +11:35 < pinchartl> Until next meeting: None +11:35 < pinchartl> Issues and blockers: None +11:35 < pinchartl> * Morimoto-san +11:35 < pinchartl> Since last meeting: None +11:35 < pinchartl> Until next meeting: None +11:35 < pinchartl> Issues and Blockers: None +11:35 < pinchartl> dammsan: morimoto: any comment ? +11:35 < morimoto> no comment, but waiting response from you :) +11:35 < dammsan> i hope we can find time to discuss how to break out tasks together =) +11:36 < pinchartl> so do I :-) +11:36 < pinchartl> * Niklas +11:36 < pinchartl> Since last meeting: +11:36 < pinchartl> - [PATCH v2] dt-bindings: media: rcar_vin: fix style for ports and endpoints +11:36 < pinchartl> - [PATCH v2] rcar-vin: sync which hardware buffer to start capture from +11:36 < pinchartl> - [PATCH v2] media: rcar-vin: enable support for r8a77965 +11:36 < pinchartl> - Looked at potential CSI-2 V3M ES differences. Initialization sequence in datasheet v1.0 don't work on my V3M ES1.x. +11:36 < pinchartl> - Reviewed patches. +11:36 < pinchartl> Until next meeting: +11:36 < pinchartl> - Keep working V3M CSI-2 ES difference +11:36 < pinchartl> - Complex Camera Workshop in Tokyo +11:36 < pinchartl> - OSS in Tokyo +11:36 < pinchartl> Issues and blockers: +11:36 < pinchartl> - Tokyo trip will limit my time with hardware access so less work than normal is to be expected next 2 weeks. +11:36 < pinchartl> neg: any comment ? +11:36 < neg> No, thanks +11:36 < pinchartl> * Ulrich +11:36 < pinchartl> Since last meeting: +11:36 < pinchartl> - Prepared v2 of DU on D3, ETA this week +11:36 < pinchartl> - Prepared v2 IGT DU fixes, ETA this week probably +11:36 < pinchartl> Until next meeting: None +11:36 < pinchartl> Issues and blockers: None +11:36 < pinchartl> uli___: any comment ? +11:37 < uli___> serious question: does anybody have alternative cooling methods? +11:37 < uli___> because these test suite runs take a long time +11:37 < uli___> and i usually run my boards with fans unplugged +11:37 < uli___> but with these temperatures... +11:37 < kbingham> uli___, Marex' quiet fans are awesome +11:37 < jmondi> pinchartl: sorry, I was distracted, no comments, just that question on DTS for add-on boards +11:38 < kbingham> uli___, Noctua fans +11:38 < uli___> thanks, i'll check those out +11:38 < pinchartl> jmondi: I think they can be upstreamed in the form of .dtsi files that can be #include'd +11:38 < pinchartl> when overlay will become a real thing they could be turned into overlays +11:38 < jmondi> pinchartl: but left them non-included of course... +11:38 < pinchartl> we already have .dtsi files for display panels for instance +11:39 < pinchartl> yes, don't include them +11:39 < jmondi> ok, I was afraid not having them includede made them not useful +11:39 < pinchartl> it's better than nothing in my opinion +11:39 < jmondi> sure it is +11:39 < jmondi> fine with me, there will be patches then +11:40 < pinchartl> thanks +11:40 < pinchartl> topic 2, additional tasks +11:40 < pinchartl> we'll have a face to face discussion on Tokyo +11:41 < pinchartl> for Q3.1 additional tasks, the contract deadline should be June the 15th, so please propose tasks by the end of this week +11:41 < pinchartl> topic 3, discussions +11:41 < pinchartl> any question ? +11:42 < neg> Not from me +11:42 < morimoto> +1 +11:42 < jmondi> not from here +11:42 < dammsan> nooooooooooooooooooooooooooooo +11:42 < dammsan> t here either +11:42 < uli___> keyboard issues? +11:43 < dammsan> always +11:43 < pinchartl> ok +11:43 < neg> dammsan: emergency bourbon kicking in? :-) +11:43 < pinchartl> topic 4, next meeting +11:43 < pinchartl> as already discussed, it will be 4 weeks from now, same place, same time +11:43 < pinchartl> topic 5, June the 7th +11:43 < pinchartl> happy birthday Jacopo :-) +11:44 < geertu> jmondi: How many teeth^H^H^H^H^Hcandles? +11:44 < geertu> Congrats!!! +11:44 < neg> jmondi: happy birthday! +11:44 < dammsan> happy birthday! +11:44 < uli___> congratulations +11:44 < kbingham> HB JM! +11:44 < shimoda> jmondi: happy birthday! +11:44 < morimoto> happy birthday ! +11:45 < pinchartl> (now I hope I wasn't mistaken with the date :-D) +11:46 < jmondi> thanks guys! +11:46 < jmondi> pinchartl: no, you're right, I'm getting older today :) +11:46 < jmondi> or :( +11:46 < vaishali> jmondi: Happy Birthday. +11:46 < jmondi> not sure +11:46 < jmondi> thanks ;) +11:47 < wsa_> jmondi: all the best from me, too! +11:47 < pinchartl> :-) +11:47 < jmondi> :) +11:47 < pinchartl> that's all for today. I propose adjourning this meeting. does anyone second ? +11:48 < neg> second +11:48 < uli___> no, i want to keep going. +11:48 * uli___ ducks +11:48 < pinchartl> uli___: feel free to stay :-) +11:48 < pinchartl> meeting adjourned, thank you all for attending diff --git a/wiki/Chat_log/20180712-core-chatlog b/wiki/Chat_log/20180712-core-chatlog new file mode 100644 index 0000000..6fc83f9 --- /dev/null +++ b/wiki/Chat_log/20180712-core-chatlog @@ -0,0 +1,173 @@ +Core-chat-meeting-2018-07-12 + +09:34 < geertu> Welcome to Today's Core Group Meeting +09:35 < geertu> Agenda: +09:35 < geertu> 1. Status Updates +09:35 < geertu> 2. Discussion Topics +09:35 < neg> geertu: which datasheet can I find that in? :-) +09:35 < kbingham> geertu, so ... do we have to be rivals now or something ? I've never quite understood football :D +09:36 < geertu> Topic 1. Status updates +09:36 < geertu> A) What have we done since last time: +09:36 < geertu> Jacopo picked up and respun lost ipmmu patches, and attended OSS-J and +09:36 < geertu> met periperi people in Tokyo. +09:36 < geertu> Kieran supported Hoan/Jinso with serial passthrough testing. +09:36 < geertu> Marek worked on U-Boot (E3 Ebisu, V3M Eagle, D3 Draak, Spectre), ATF +09:36 < geertu> (V3M Eagle and D3 Draak), and OpenOCD (H2/M2/E2 support accepted). +09:36 < geertu> Morimoto is enforcing SPDX license tags, and working on periject v2 +09:36 < geertu> (please send feedback!). +09:36 < geertu> Niklas fixed a V3M pinctrl crash. +09:36 < geertu> Shimoda-san submitted patches for PFC (E3 USB3.0), IPMMU (IMUCTR.TTSEL +09:36 < geertu> handling), R-Car DMAC (a.o. pause support), DTS (E2 USB2.0, RWDT +09:36 < geertu> unification), and asked BSP team about INTC-{AP,EX} clocks and +09:36 < geertu> resets removal. +09:36 < geertu> Ulrich sent ATF/U-Boot patches for H3 ES3.0 memory detection. +09:36 < geertu> Geert resubmitted bd9571mwv toggle power switch support, sent a first +09:36 < geertu> set of CLK and PFC pull requests for v4.19, tested 4.14 backports from +09:36 < geertu> Simon for LTSI, upported R-Car gen3 OSC and RCLK improvements, and +09:36 < geertu> submitted a GPIO virtualization presentation to ELCE2018. +09:37 < geertu> B) What we plan to do till next time: +09:37 < geertu> Jacopo will work on M3-W ULCB Z clock support and CPU idle. +09:37 < geertu> Kaneko-san will work on M3-N CPUFreq upport. +09:37 < geertu> Kieran may work on the DMAC virtualisation investigation continuation +09:37 < geertu> (TBC). +09:37 < geertu> Marek will work on U-Boot (SPL-alike replacement for Minimon) and +09:37 < geertu> OpenOCD for Gen3. +09:37 < geertu> Morimoto-san will continue SPDX and periject. +09:37 < geertu> Niklas will provide a fix for the V3M PFC crash for the stable tree. +09:37 < geertu> Shimoda-san will add the USB3 node to E3 DTS, and pave the way forward +09:37 < geertu> for IPMMU. +09:37 < geertu> Ulrich will revise the H3 ES3.0 memory detection patches, and is hoping +09:37 < geertu> for a consensus on the solution to use. +09:37 < geertu> Geert plans to work on rcar-gpio get_direction(), BD9571MWV toggle power +09:37 < geertu> switch rework, SYSC errata, and LTSI sub-maintainership, and hopes to +09:37 < geertu> look into GPIO paravirtualization. +09:38 < geertu> (anything I missed?) +09:38 < geertu> C) Problems we have currently: +09:38 < geertu> Ulrich is living in a house right between a Croatian and an English pub. +09:38 < geertu> Geert is worried by module clocks and resets that are described in DT, +09:38 < geertu> but disappeared from the datasheet, and by RZ/N1D pincontrol etc. +09:38 < geertu> EOT +09:39 < geertu> I assume Uli's problem has been solved by now, (or for now, reduced by 50%) +09:40 < ulih> loss of sleep is still noticable +09:40 < geertu> and they killed your Internet connection? +09:41 < geertu> Topic 2. Discussion Topics +09:41 < ulih> for their sake, i hope not +09:42 < geertu> So, how many resources do we want to spend on "Handle 32-bit DMA limitation"? +09:43 < Marex> given how the maintainers keep bouncing it between one another like a hot potato, a lot ? +09:43 < Marex> it seems to be moving from "PCI problem" to "DMA problem" to "generic arch problem" +09:43 < wsa_> I guess the task as a whole is more of an add. task +09:43 < dammsan> ZONE_DMA32? +09:44 < wsa_> however to find out how much time we really need some initial effort is needed? +09:44 < dammsan> isn't this same as Gen2 PCI-based USB? +09:44 < geertu> Correct +09:45 < geertu> ("Correct" for the estimation effort) +09:46 < Marex> dammsan: gen2 has 32bit address space, so it's "fine" there, right ? +09:46 < dammsan> Marex: no, with LPAE we have 40 +09:46 < Marex> dammsan: gen3 has 64bit address space and the PCIe devices cannot access all of it +09:46 < Marex> dammsan: ha +09:47 < dammsan> ok so similar to 32-bit PCI space on a 40-bit machine =) +09:48 < dammsan> so we have bus mastering limitations for our PCI hosts +09:48 < dammsan> i guess we should describe those as part of DT +09:49 < dammsan> and then implement workarounds somehow, maybe bounce buffer or ZONE32 +09:49 < Marex> dammsan: but it's not the host, it's how it's connected to the CPU bus +09:49 < Marex> dammsan: that's how I understand it anyway +09:49 < dammsan> to the CPU? +09:49 < Marex> dammsan: my understanding is that only 32 out of 64 address lines are connected +09:50 < dammsan> haha, if so surprisingly similar to gen2 =) +09:50 < dammsan> but this results that PCI cards cannot access memory outside 32 bits? +09:51 < dammsan> if we use IPMMU we can make that IOVA perhaps and translate that to any 64-bit address? +09:51 < Marex> dammsan: I believe that is the actual problem, PCIe cards cannot accesss stuff above 32bit boundary +09:52 < dammsan> so bounce buffer or IOMMU? +09:52 < dammsan> perhaps we need to clearly identify the problem unless already done +09:53 < dammsan> do we have a test case to reproduce? +09:53 < Marex> dammsan: I am looking for a suitable device +09:54 < Marex> dammsan: if my understanding is correct, one of those memory mapped storage devices would do nicely, since it needs a massive amount of PCIe space, well beyond 32bit +09:55 < dammsan> i recall intel based nics were popular +09:55 < dammsan> oh i see +09:55 < dammsan> i recall paul used graphics cards for PCI testing on SH +09:55 < Marex> dammsan: the intel NICs I have map below 32bit just fine +09:55 < dammsan> but you can force allocation of memory to higher address ? +09:55 < Marex> dammsan: oh, that could do too, but the slot is usually x1 only +09:56 < dammsan> to check if address lines mismatch somehow +09:56 < Marex> possibly, but how would that help ? +09:56 < dammsan> i guess those are two separate issues +09:57 < dammsan> maximum window space limited by 32 bits +09:57 < dammsan> and +09:57 -!- uli___ [~uli___@static.206.203.46.78.clients.your-server.de] has joined #periperi +09:57 < dammsan> address for bus mastering limited to lowest 32 bits +09:57 < dammsan> ? +09:57 -!- ulih [~Mutter@x2f7fd43.dyn.telefonica.de] has quit [Quit: Mutter: www.mutterirc.com] +09:57 < Marex> right +09:57 < horms> sounds like two variants of the same limit to me +09:58 < Marex> the window limit can be already dealt with +09:58 < Marex> that's nothing new +09:58 < dammsan> my point is that gfx card will be suitable for the first case +09:58 < Marex> but the bus mastering limit is the problem +09:58 < geertu> We're running out of time. Any closing remarks about PCIe and 32-bit limits? +09:58 < dammsan> and nic or any i/o card fine for the second +09:59 < dammsan> but anyway +09:59 < Marex> dammsan: or an FPGA +09:59 < dammsan> sure +09:59 < Marex> dammsan: I have an example design, maybe I should revisit it +09:59 < pinchartl> geertu: you can take a5 minutes extra, I'm slightly late +09:59 < Marex> dammsan: and it actually fits into the slot on the renesas board(s) +09:59 < geertu> Marex: would be nice +09:59 < dammsan> for sure +10:01 < dammsan> let me know how to reproduce =) +10:01 < Marex> dammsan: the 32bit limitation ? +10:01 < dammsan> yeah +10:02 < Marex> dammsan: I'll look for a suitable HW and let you know +10:02 < dammsan> thanks +10:02 < geertu> Does anyone care about RZ/N1? +10:03 < horms> If its a question of 1x PCI slots, I think you can get adapters if need be +10:03 < dammsan> in general yes, but it is not part of automotive effort, right? +10:04 < Marex> geertu: follow up question -- does anyone care about U-Boot on RZ ? :-) +10:04 < geertu> Marex: RZ/N, RZ/G, RZ/A, or RZ/T? +10:04 < geertu> RZ/G we probably do +10:05 < geertu> RZ/A Chris Brandt does +10:05 < geertu> RZ/T too low spec +10:05 < geertu> RZ/N the new kid on the block +10:06 < Marex> geertu: you can run U-Boot on cortex-m/r ;-) +10:06 < Marex> geertu: but yes, what about RZ/G and RZ/N ? +10:06 < Marex> geertu: maybe we should fix them early on +10:07 < geertu> I expect RZ/N using the worst Fankenboot +10:07 < geertu> s/Fan/Fran/ +10:07 < dammsan> sausage boot +10:07 < geertu> RZ/G should be similar to R-Car Gen2 +10:07 < Marex> geertu: exactly +10:08 < dammsan> my opinion is that after gen2 u-boot is complete we can move over to other RZ as a low prio activity +10:08 < geertu> And RZ/G should be trivial to handle +10:09 < dammsan> openocd for rz/g? +10:09 < geertu> Trivial +10:10 < dammsan> good, the more reason to do it then =) +10:10 < geertu> The trivial ones are not consuming our cycles +10:11 < geertu> Things like RZ/N1D pincontrol do +10:11 < geertu> Anyway, time to finish. +10:11 < geertu> Anyone else who has a (quick) topic to discuss? +10:11 < dammsan> geertu: i guess we have no funding from RZ/N guys? +10:11 * pinchartl is ready +10:11 < dammsan> no other topic from me +10:11 < dammsan> thanks +10:12 < pinchartl> dammsan: is there a chance we could get funding ? or to put it differently, do you think it's worth trying to push in that direction ? +10:12 < geertu> Thanks for joining, and have a nice continued day! +10:12 * geertu passes the mic to pinchartl +10:12 < Marex> dammsan: do we have RZ/G and RZ/N board ? +10:13 < dammsan> Marex: nope, never seen them +10:13 < dammsan> pinchartl: yes it would make sense to get funding from those groups too +10:14 < pinchartl> dammsan: would you like to lead that effort, or should group leaders do so individually ? I think a joint effort would make more sense +10:15 < dammsan> pinchartl: good question +10:15 < Marex> dammsan: so uh, how do we do U-Boot port if we don't have reference platform ? :) +10:16 < pinchartl> dammsan: should we discuss that separately ? +10:16 < dammsan> perhaps we can begin by asking to get hardware platforms for free? +10:16 < pinchartl> that's a good idea +10:17 < dammsan> my opinion is that we can do that on an individual basis or group leaders do it +10:17 < dammsan> whenever there is demand +10:17 < pinchartl> ok +10:17 < dammsan> and then based on outcome of activity improve relationship +10:17 < dammsan> let me know if i can help somehow +10:18 < geertu> Marex: r8a7743-sk-rzg1m ~ Porter, r8a7745-sk-rzg1e ~ ALT +10:20 < horms> As I understand it the RZ/G work is coming out of Renesas UK. Chris Patterson seems pretty friendly. I would talk with him. But perhaps dammsan has a better idea +10:20 < horms> s/tt/t/ +10:21 < kbingham> I think me and Chris have a 'special relationship' now that we sang the grease song in duet :D +10:21 < Marex> geertu: I can imagine, should be easy to implement U-Boot support then +10:22 < dammsan> sounds good to me - thanks! diff --git a/wiki/Chat_log/20180712-io-chatlog b/wiki/Chat_log/20180712-io-chatlog new file mode 100644 index 0000000..01f3694 --- /dev/null +++ b/wiki/Chat_log/20180712-io-chatlog @@ -0,0 +1,113 @@ +09:03 < wsa_> welcome :) +09:03 < wsa_> here is the condensed summary, please double check: +09:03 < wsa_> A - what have I done since last time +09:03 < wsa_> ------------------------------------ +09:03 < wsa_> Geert +09:03 < wsa_> : upported MSIOF DMA completion improvement and fixed SCIF race conditions +09:03 < wsa_> during shutdown. +09:03 < wsa_> Kaneko-san +09:03 < wsa_> : got PCIE support for M3-W and M3-N merged. +09:03 < wsa_> Niklas +09:03 < wsa_> : resent a patch series to improve SDHI tuning, started reworking the BSP +09:03 < wsa_> SDHI reset patches, and started looking into DMA max seg size for SDHI. +09:03 < wsa_> Shimoda-san +09:03 < wsa_> : added USB3 role switch support, sent a bugfix for the SDHI DMA RX case, +09:03 < wsa_> implemented USB support for r8a77990, and investigated a SCIF overrun +09:03 < wsa_> issue. +09:03 < wsa_> Simon +09:03 < wsa_> : got SDHI HS400 support merged. +09:03 < wsa_> Ulrich +09:03 < wsa_> : sent first version of D3 MSIOF support and researched origins of SCIF +09:03 < wsa_> REIE handling +09:03 < wsa_> Wolfram +09:03 < wsa_> : fixed a problem in and improved R-Car support for I2C bus recovery and +09:03 < wsa_> improved wiki documentation for it, sent a new version of the I2C RXDMA +09:03 < wsa_> workaround patch, guided the SCCB redesign including needed preparations, +09:03 < wsa_> fixed a regression introduced with the I2C fault injector and resent a +09:03 < wsa_> new fault injector, and looked into a SDHI DMA mapping problem. +09:03 < wsa_> Before that, he attended ALS2018 and held a talk about DMA safe buffers. +09:03 < wsa_> B - what I want to do until next time +09:03 < wsa_> ------------------------------------- +09:03 < wsa_> Kaneko-san +09:03 < wsa_> : wants to upport M3-N SATA and D3 MSIOF. +09:03 < wsa_> Niklas +09:03 < wsa_> : wants to post patch for the now started work and continue with +09:03 < wsa_> SDHI tuning improvements. +09:03 < wsa_> Shimoda-san +09:03 < wsa_> : wants to make a plan for USB role switch on E3 despite the connector +09:03 < wsa_> issue, continue with the SCIF issue if needed, add PWM for E3, and +09:03 < wsa_> continue to learn QEMU with USB. +09:03 < wsa_> Simon +09:03 < wsa_> : wants to work CPG and DTS changes for HS400. +09:03 < wsa_> Wolfram +09:03 < wsa_> : wants to merge the I2C recovery and RXDMA work, keep guiding the SCCB +09:03 < wsa_> refactoring, review Niklas SDHI patch series, and check if the SDHI +09:03 < wsa_> NON_REMOVABLE workaround is still needed. +09:03 < wsa_> C - problems I currently have +09:03 < wsa_> ----------------------------- +09:03 < wsa_> Niklas +09:03 < wsa_> : mentions that figuring SDHI testing slows him down. +09:03 < wsa_> Shimoda-san +09:03 < wsa_> : needs more info from the HW team to make renesas_usbhs work again. +09:03 < wsa_> Wolfram +09:03 < wsa_> : is so busy with all the other tasks that QEMU development is lagging. +09:06 < wsa_> I have a question for shimoda about the SCIF issue and if I got the current status right +09:06 < wsa_> We all did some research about the REIE and TOIE bit and you reported back our findings to the BSP team +09:06 < wsa_> and we are waiting now if this is enough for them +09:07 < wsa_> Is this correct or am I forgetting something? +09:07 < wsa_> Do we need to work more on this? +09:08 < wsa_> shimoda: ? (let's try the IRC notification thingie) +09:09 < wsa_> Other than that, IO group is promised an E3 board +09:09 < neg> Nice +09:10 < wsa_> Since E3 is mainly DTS enablement which we agreed to be worked on by Kaneko-san, I voted to have it sent to Simon +09:10 < wsa_> neg: core and M/M will get one, too +09:10 < wsa_> so he can test the patches +09:11 < wsa_> horms: is hat okay with you? +09:11 < horms> sure! +09:12 < wsa_> nice +09:12 < shimoda> wsa_: sorry for the delayed. about REIE and TOIE, this is enough for now. +09:12 < wsa_> shimoda: thanks! +09:14 < shimoda> by the way, i'd like to get some opinions about SCIF console overrun issue +09:14 < shimoda> i sent an email at 2018-07-09 pm 2:48 JST +09:15 < geertu> shimoda: This is input overrun, right? +09:15 < shimoda> geertu: yes +09:16 < geertu> I'm afraid that with flow control disable, there's not much we can do. +09:16 < geertu> s/disable/disabled/ +09:18 < shimoda> geertu: thanks for your opinion! does this mean this is not a bug on the driver? +09:19 < geertu> shimoda: Well, printing kernel messages on the serial console is known to interfere with normal serial operation. +09:19 -!- ulih [~Mutter@x2f7fd43.dyn.telefonica.de] has joined #periperi +09:20 < geertu> To make it perfectly safe without any interference would mean loosing most of its value (kernel messages may not come through) +09:20 * geertu wonders if ulih is the SCIF expert? +09:20 < ulih> morning. network outage, using my wife’s iphone +09:21 < ulih> what is the matter? +09:21 < geertu> ulih: We were just talking about the SCIF console overrun issue +09:23 < wsa_> shimoda-san wrote an email about it on 2018-07-09 pm 2:48 JST +09:23 < wsa_> but geert already mentioned that "kernel messages on the serial console is known to interfere with normal serial operation" +09:23 < wsa_> and "I'm afraid that with flow control disable, there's not much we can do." +09:24 < ulih> ok. thanks for filling me in +09:25 < wsa_> while ulih thinks about it, are there any other topics from your side? +09:26 < wsa_> I am done with the "bigger" topics +09:26 < wsa_> details about upporting will be done 1:1 privately +09:26 < wsa_> vaishali: I really hope to have the SDHI check done this week +09:27 < geertu> Has anyone tried QEMU+KVM and I/O pass-through (vfio) with a DMA-capable device directly connected to the IPMMU (i.e. not via SYS-DMAC)? +09:27 < vaishali> wsa_: Thanks. :) +09:27 < wsa_> but I'd think the other topics do not depend on it, or? +09:27 < wsa_> geertu: nope +09:28 < Marex> wsa_: two more PCIe fixes got in +09:28 < Marex> wsa_: you wanted to ask about the 32bit limitation of the PCIe at some point +09:28 < dammsan> geertu: i don't see how the guest dma map/unmap operations would affect the host that has the IPMMU driver? +09:28 < wsa_> Marex: nice +09:29 < wsa_> Marex: yup, we missed to talk about this in Japan :( Seems we need to do it by email +09:29 < dammsan> geertu: i have not tried it, but i dismissed it before doig so =) +09:29 < wsa_> I will do this later +09:30 < Marex> wsa_: the thread (Re: [PATCH][RFC] PCI: rcar: Add bus notifier so we can limit the DMA range) died on the 6th of June, sadly +09:30 < Marex> wsa_: I can poke the thread if you think it makes sense, although I don't have anything to contribute without really digging in +09:31 < geertu> dammsan: I hoped it would just work out-of-the-box, as IOMMU and pass-through should work on other systems +09:31 < geertu> Marex: I can assign "ARM64,?,noplan,?,Handle 32-bit DMA limitation (https://patchwork.kernel.org/patch/10416861/) +09:31 < geertu> " to you with a single vim edit ;-) +09:32 < geertu> If you're interested +09:32 < wsa_> geertu: how about I give you the mic and we talk about it in the core meeting? :) +09:32 < geertu> wsa_: Sounds like a good idea! +09:32 < wsa_> good! +09:32 < dammsan> geertu: maybe reproducing a x86-based environment with vfio might bbbe good? +09:32 < wsa_> thank you all for this meeting! diff --git a/wiki/Chat_log/20180712-mm-chatlog b/wiki/Chat_log/20180712-mm-chatlog new file mode 100644 index 0000000..67c5e28 --- /dev/null +++ b/wiki/Chat_log/20180712-mm-chatlog @@ -0,0 +1,414 @@ +Multimedia-chat-meeting-2018-07-12 + +10:25 < pinchartl> welcome to the multimedia meeting +10:25 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:25 < pinchartl> * Jacopo +10:25 < pinchartl> Since last meeting: +10:25 < pinchartl> - MT9V111 and GR-Peach audiocamera shield +10:25 < pinchartl> [PATCH 0/2] media: i2c: mt9v111 sensor driver +10:25 < pinchartl> [PATCH] ARM: dts: gr-peach: Add GR-Peach audiocamerashield support +10:25 < pinchartl> - Respin of iommu patches that got lost +10:25 < pinchartl> [RESEND 0/6] iommu: ipmmu-vmsa: Add more Gen3 SoCs support +10:25 < pinchartl> - Got parallel input support for VIN merged +10:25 < pinchartl> - New iteration of VIN endpoint properties refreshing +10:25 < pinchartl> - Attend OSS-J and meet periperi people in Tokyo +10:25 < pinchartl> - Complex Camera Workshop in Tokyo +10:25 < pinchartl> Until next meeting: TBD +10:25 < pinchartl> Issues and Blockers: None +10:25 < pinchartl> jmondi: TBD stands for To Be Decided +10:25 < pinchartl> you provided a long list of items you could work on +10:26 < pinchartl> I propose discussing them after the status update +10:26 < pinchartl> any comment ? +10:26 < kbingham> pinchartl, (I believe Jacopo is on a plane) +10:26 < pinchartl> oh, OK +10:27 < pinchartl> indeed, he wrote that he wouldn't be able to attend in his e-mail +10:27 < pinchartl> * Kieran +10:27 < pinchartl> Since last meeting: +10:27 < pinchartl> - Japan OSS/ALS +10:27 < pinchartl> - Gave GMSL Talk +10:27 < pinchartl> https://www.slideshare.net/KieranBingham/gmsl-in-linux +10:27 < pinchartl> - Complex Camera Workshop in Tokyo +10:27 < pinchartl> - ATF build and update for qemu-kvm +10:27 < pinchartl> - Proposed GMSL talk for ELCE +10:27 < pinchartl> - Proposed Fault Tolerant V4L2 for ELCE +10:27 < pinchartl> Until next meeting: +10:27 < pinchartl> - DU/Interlaced review actions +10:27 < pinchartl> - Submit GMSL for Renesas-drivers +10:27 < pinchartl> Issues and blockers: None +10:27 < pinchartl> kbingham: any comment ? +10:27 < kbingham> Aha - you've added the complex camera workshop :) thanks :) +10:28 < kbingham> That looks good for me +10:28 < pinchartl> you're welcome +10:29 < pinchartl> * Laurent +10:29 < pinchartl> Since last meeting: +10:29 < pinchartl> - Display virtualization +10:29 < pinchartl> - Japan OSS/ALS +10:29 < pinchartl> - Gave talk about display virtualization at ALS +10:29 < pinchartl> https://schd.ws/hosted_files/ossalsjp18/27/20180622-ossj.pdf +10:29 < pinchartl> - Complex Camera Workshop in Tokyo +10:29 < pinchartl> - Patch review +10:29 < pinchartl> Until next meeting: +10:29 < pinchartl> - Patch review +10:29 < pinchartl> - Additional tasks preparation +10:29 < pinchartl> - Revive the GMSL efforts +10:29 < pinchartl> - Part-time vacation +10:29 < pinchartl> Issues and blockers: +10:29 < pinchartl> - No additional tasks scheduled yet for Q3. +10:29 < pinchartl> any comment from anyone? +10:29 < pinchartl> * Magnus: +10:29 < pinchartl> Since last meeting: None +10:29 < pinchartl> Until next meeting: None +10:29 < pinchartl> Issues and blockers: None +10:29 < pinchartl> * Morimoto-san +10:29 < pinchartl> Since last meeting: None +10:29 < pinchartl> Until next meeting: None +10:29 < pinchartl> Issues and Blockers: None +10:30 < pinchartl> dammsan: morimoto: any comment ? +10:30 < morimoto> no +10:31 < dammsan> ditto +10:32 < pinchartl> * Niklas +10:32 < pinchartl> Since last meeting: +10:32 < pinchartl> - Summer VIN cleaning +10:32 < pinchartl> Dug out and prepared batch test of patches held back until VIN was accepted. Will post in before next meeting. Mostly related to VIN SEQ_TB/BT support, additional formats and fixes to the ADV7180. +10:32 < pinchartl> - Working on V4L subdev STD handling for MC-centric devices. +10:32 < pinchartl> - Complex Camera Workshop in Tokyo. +10:32 < pinchartl> Until next meeting: +10:32 < pinchartl> - Keep testing and getting the held back patches out +10:32 < pinchartl> - Try to work with Mauro and have him accept the subdev STD patch +10:32 < pinchartl> - If GMSL efforts are stepped up by the team keep phusing for the VC patch set +10:32 < pinchartl> Issues and blockers: +10:32 < pinchartl> - Mauro refuse to understand the MC-centric use-cases +10:32 < pinchartl> Please MM members read and respond to the thread '[PATCH v2 0/2] v4l: Add support for STD ioctls on subdev nodes'. We need this on Gen3 to be able to control the video standard of CVBS capture. +10:32 < pinchartl> neg: any comment ? +10:33 < neg> pinchartl: can you please step-up as MC maintainer ? ;-) +10:33 < neg> other than thet no comment +10:33 < pinchartl> neg: I would if Mauro let me. feel free to propose that :-) +10:34 < pinchartl> * Ulrich +10:34 < pinchartl> Since last meeting: +10:34 < pinchartl> - Sent revised D3 DU support +10:34 < pinchartl> Until next meeting: None +10:34 < pinchartl> Issues and blockers: None +10:34 < pinchartl> uli___: any comment ? +10:34 < uli___> one thing about the d3 du +10:34 < uli___> it does not support interlacing +10:35 < uli___> no difference in the register layouts etc, so as long as it is not used +10:35 < uli___> we're fine +10:35 < uli___> but how can i make sure of that? +10:35 < kbingham> uli___, As interlacing is not yet supported, I don't think it's an issue for you +10:35 < uli___> that's good to hear :) +10:35 < kbingham> But I will consider that on my DU/Interlacig series +10:35 < uli___> nothing else from me +10:35 < kbingham> (I plan to work through laurent's review comments on that this week) +10:36 < pinchartl> thank you +10:37 < pinchartl> anything to add before moving to the next topic (additional tasks) ? +10:38 < neg> nothing from me +10:39 < kbingham> nor me +10:39 < pinchartl> Topic 2. Additional Multimedia Tasks for Q3 +10:39 < pinchartl> two additional tasks have been accepted for Q3 +10:39 < pinchartl> - R-Car Gen3 display output limitations +10:40 < pinchartl> - D3/E3 LVDS PLL support +10:40 < pinchartl> we now need to split them between all of us, and schedule them +10:41 < pinchartl> Renesas has requested us to reduce the budget +10:41 < pinchartl> by a 15, 20 or 25% amount depending on the phase of the moon +10:42 < pinchartl> the latest information I've been given is that we should prepare for a 15-20% reduction +10:42 < kbingham> I'm ok reducing some budget at the moment. +10:42 < uli___> is that a grand total, or for add. tasks only? +10:42 < dammsan> former +10:42 < pinchartl> grant total, but it seems OK to apply the reduction to additional tasks only +10:43 < pinchartl> that is, if you have 30 base + 30 additional, a 15% reduction is 9 days +10:43 < pinchartl> so you would end up with 30 base + 21 additional +10:43 < uli___> ok +10:44 < horms> I am happy to donate time other than that required for LTSI +10:44 < pinchartl> here are the current projections +10:44 < pinchartl> Member | Base + Add. | 15% | 20% | 25% +10:44 < pinchartl> -------------------------------------------------------------------- +10:44 < pinchartl> Jacopo | 33 + 15 | - 7.2 -> 5 | - 9.6 -> 10 | - 12 -> 10 +10:44 < pinchartl> Kieran | 20 + 25 | - 6.75 -> 5 | - 9 -> 10 | - 11.25 -> 10 +10:44 < pinchartl> Laurent | 35 + 25 | - 9 -> 10 | - 12 -> 10 | - 15 -> 15 +10:44 < pinchartl> Niklas | 20 + 10 | - 4.5 -> 5 | - 6 -> 5 | - 7.5 -> 10 +10:44 < pinchartl> Ulrich | 35 + 25 | - 9 -> 10 | - 12 -> 10 | - 15 -> 15 +10:45 < pinchartl> with the number of days rounded to the nearest multiple of 5 +10:45 < geertu> ;-) +10:46 < geertu> (about rounding) +10:46 < pinchartl> I know :-) +10:46 < pinchartl> if we prepare for 20%, we will be left with the following number of additional task days +10:46 < pinchartl> Jacopo: 5 +10:46 < pinchartl> Kieran: 15 +10:46 < pinchartl> Laurent: 15 +10:46 < pinchartl> Niklas: 5 +10:46 < pinchartl> Ulrich: 15 +10:47 < pinchartl> total: 55 +10:48 < pinchartl> who has or plan to have additional tasks scheduled for the core and I/O groups ? +10:48 < neg> My only plan is to have the 5 days I have for additional to happen in the second batch of Q3 if possible +10:49 < pinchartl> s/plan/plans/ +10:49 < pinchartl> I plan to ask for scheduling everything for the second batch (unless someone insists on having to deliver earlier) +10:49 < dammsan> seems good to me +10:50 < pinchartl> uli___: do you have additional tasks planned for Q3 for core ? I think I recall memory autodetection ? +10:50 < uli___> i intend to do that, but no talks about making that an add. task yet +10:51 < kbingham> pinchartl, for me, if there is not enough work to go around in MM, I could go back to looking at virt-topics with core ... but I'd want to make sure I've got a good understanding of the task requirements for that ;) +10:54 < pinchartl> sorry, I lost my internet connection +10:54 < pinchartl> kbingham: I think we'll have enough work on the multimedia side :-) +10:54 < pinchartl> uli___: geertu: how much time do you think will be needed by that ? +10:56 < uli___> 10 days, if i can get an atf upstreaming waiver (that's unknown territory for me) +10:56 < pinchartl> that would leave 5 days for multimedia then +10:57 < pinchartl> I should get an E3 board which has the sasme LVDS PLL +10:57 < pinchartl> so we could share the work between you and me +10:58 < uli___> do you have an idea how to split that? +10:58 < pinchartl> an easy way would be prototype + upstreaming +10:58 < pinchartl> 5 days fits a prototype better than an upstreaming task +10:58 < uli___> i would say +10:59 < pinchartl> do you think that makes sense, or would you prefer a different arrangement ? +10:59 < uli___> i think that could work +11:00 < pinchartl> would you be able to schedule that for mid-August ? otherwise I'd have trouble finishing it for mid-September, as my work would depend on yours +11:00 < uli___> would be ok +11:01 < pinchartl> thank you. I'll write task proposals then +11:01 < uli___> ok, thanks +11:01 < pinchartl> so that covers us +11:01 < pinchartl> for Jacopo, Kieran and Niklas, there are 25 days in total +11:02 < pinchartl> I think that can be covered by the "R-Car Gen3 display output limitations" task +11:02 < pinchartl> any opinion ? +11:03 < neg> I'm not sure what's included by the output limitation task +11:03 < kbingham> Are we thus going to just submit that as a task, and each work on it ? +11:04 < pinchartl> kbingham: more or less, but as we need to split the work anyway, I think we should include that information in the task description +11:04 < pinchartl> neg: +11:04 < pinchartl> - R-Car Gen3 display output limitations +11:04 < pinchartl> Display output on Gen3 platforms are subject to various resolution, pixel +11:04 < pinchartl> fomat and clock rate limitations depending on the SoC (or rather on the VSP, +11:04 < pinchartl> DU and internal encoders) and board. Few of these limitations are properly +11:04 < pinchartl> taken into account, which leads to random display output stability issues. For +11:04 < pinchartl> instance, 4k output isn't working properly, and parallel output (for VGA) +11:04 < pinchartl> pixel frequency limitations are not taken into account. +11:04 < pinchartl> I would like to propose an additional task to fix all this. The goal is to go +11:04 < pinchartl> through the documentation for each SoC and board we support, as well as +11:04 < pinchartl> through the contents of the BSP, to identify limitations for each platform and +11:04 < pinchartl> make sure they are all taken into account in the appropriate drivers. The work +11:04 < pinchartl> isn't extremely difficult, but in some cases we will need to implement +11:04 < pinchartl> currently unimplemented operations (in particular in the DU driver to take +11:04 < pinchartl> pixel rate limits into account), or possibly to even extend frameworks +11:04 < pinchartl> (although I don't think that should be needed, but I haven't double-checked). +11:06 < neg> pinchartl: thanks +11:06 < pinchartl> another option would be to find a 5 days additional task related to VIN for you, and have Jacopo and Kieran handle the display side. there's plenty of work in VIN, that's not an issue, but I don't know if that could be accepted as an additional task +11:06 < pinchartl> dammsan: any comment ? +11:06 < dammsan> fine with me +11:06 < neg> Only VIN task I see which is fit for add task is a UDS scaler prototype +11:07 < pinchartl> dammsan: which option is fine with you ? :-) everybody working on display, or proposing a VIN additional task ? +11:07 < pinchartl> neg: I'd like to move forward with the scaler too +11:07 < pinchartl> I think it's important to prototype that in the not too distant future +11:07 < dammsan> i'm ok either way, niklas working on vin makes sense to me +11:07 < pinchartl> in order to plan for proper upstreaming +11:07 < pinchartl> dammsan: thanks. it makes sense to me too +11:08 < pinchartl> so should we go for a VIN scaler prototype task ? +11:08 < neg> I would be fine working on the scaler +11:09 < pinchartl> I'll propose that then, thanks +11:09 < pinchartl> and split the DU work between Kieran and Jacopo +11:09 < neg> thank you +11:09 < pinchartl> (who can't disagree as he's not here :-)) +11:09 < kbingham> Well I'll handle the 4k work as I have already bought the 4K TV :) +11:10 < pinchartl> :-) +11:10 < pinchartl> we'll decide how to split the work when Jacopo will be available +11:10 < kbingham> What's the VGA issue? +11:11 < neg> kbingham: that's selfish, I thin Jacopo who do not yet own a 4k tv should handle that ;-) +11:11 < kbingham> (agreed, we can take further planning offline until Jacopo is here) +11:11 < pinchartl> various SoCs have different maximum pixel clock limits, this affects VGA and should be taken into account when reporting supported modes to userspace +11:11 < kbingham> neg, Well he could certainly test any patches if he needs a reason to expense a 4kTV :) +11:12 < neg> kbingham: :-) +11:12 < kbingham> pinchartl, Aha - ok I think I understand yes ;) +11:14 < pinchartl> so I think this covers additional tasks for Q3 +11:14 < pinchartl> any question or comment ? +11:14 < morimoto> quick question from me +11:14 < morimoto> wsa_: pinchartl: About tool, are you OK v2 style ? It is assuming you uses your own editor. I don't want to re-work script many times. It still doesn't have bsp upport and report features +11:14 < pinchartl> morimoto: is that an additional task ? :-) +11:14 < morimoto> but you can see its behavior +11:14 < morimoto> hehe :) +11:14 < morimoto> Just question +11:15 < pinchartl> I'll reply to your e-mails today or tomorrow. I'm sorry for the delay, I've been traveling a lot after our meeting in Tokyo +11:15 < morimoto> OK +11:15 < morimoto> but, your "I will do it in next week" never worked for me :) +11:15 < morimoto> +1. do you think it will be useful if new tool can handle base/additional task days ? +11:15 < wsa_> morimoto: I wanted to have a look later today +11:15 < pinchartl> I know, that's why I said today or tomorrow, not next week :-) +11:15 < morimoto> wsa_: thanks +11:15 < pinchartl> I haven't had time to read the latest mails in the thread yet +11:15 < morimoto> pinchartl: OK, thanks +11:16 < morimoto> OK, no problem. +11:16 < morimoto> I'm looking forward to see you respoce +11:16 < morimoto> thanks, thats all from me +11:16 < pinchartl> thank you +11:16 < pinchartl> this leads us to +11:16 < pinchartl> Topic 3. Q3 Development Schedule +11:17 < pinchartl> Kieran and Jacopo have proposed tasks in their biweekly e-mail reports +11:17 < pinchartl> for Kieran +11:17 < pinchartl> s/for/from/ +11:17 < pinchartl> * Media +11:17 < pinchartl> - GMSL prototype continuation +11:17 < pinchartl> - RDACM21 +11:17 < pinchartl> - Fault redundant V4L2 +11:17 < pinchartl> - DU +11:17 < pinchartl> - 4K support +11:17 < pinchartl> - VSP1 +11:17 < pinchartl> - YUV420M formats support +11:17 < pinchartl> the DU and VSP1 work is included in additional tasks +11:18 * morimoto need to go back to my home +11:18 < pinchartl> morimoto: thank you for attending +11:18 < morimoto> thanks, bye +11:18 < pinchartl> from Jacopo +11:18 < pinchartl> - GMSL +11:18 < pinchartl> - Is there interest in RDACM21 which has a different image sensor? There's +11:18 < pinchartl> plenty of work there. +11:18 < pinchartl> - The kingfisher boards has GMSL and TI concurrent solution for remote +11:18 < pinchartl> camera/displays. Having one would be sweet but it is hardly available and +11:18 < pinchartl> expensive. +11:18 < pinchartl> - Driver sent upstream but not yet received feedback +11:19 < pinchartl> - From the periperi upport list +11:19 < pinchartl> (All commit reference from https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/) +11:19 < pinchartl> - EBISU needs VIN and display output support +11:19 < pinchartl> commit/?id=5ee0043347b63d40cf088740fb07285d4178f82c +11:19 < pinchartl> commit/?id=51b12d070f3ddc9bbf7232028e5d1571c95eb473 +11:19 < pinchartl> - M3-W ULCB fixes: Z clock support, CPU idle +11:19 < pinchartl> commit/?id=9c21d6d3ebacf11cb241e086902a2ecfe6e779d6 +11:19 < pinchartl> commit/?id=22fa2b4b9dd0f78e02f8d890a9cf98fda8757ad4 +11:19 < pinchartl> commit/?id=fe16e454b991dbd280a95ebe48aa595915d4610b +11:19 < pinchartl> - There is an LVDS panel driver, which I'm not sure in which board/expansion +11:19 < pinchartl> is. Does periperi Japan knows what's that for? +11:19 < pinchartl> commit/?id=4e3cc360666b5c8cc52c47b5eb7b16a8ef80bd40 +11:19 < pinchartl> - VIN: support for ARGB and NV12 +11:19 < pinchartl> commit/?id=9fb2f061c046d530adacd73946d00febf6027a81 +11:19 < pinchartl> commit/?id=1196884f275fb0f1a1cec04ce56a92453798292b +11:19 < pinchartl> - VIN and CSI-2 power management: +11:19 < pinchartl> commit/?id=1b1b3b1445fd5479cf0d8a43d69690dec5ecd854 +11:19 < pinchartl> - CEU related work +11:19 < pinchartl> - CEU interlaced support (need an analogue source connected to remote Migo-R) +11:19 < pinchartl> - Fabrizio Castro and Chris Patterson sent patches to add support for BT656 on OV7725, found on iWave platform. The board is expensive (1000€) so buying it is not an option. The patches can still be upstreamed if Chris and Fabrizio can test the rebased version. +11:19 < pinchartl> - MT9T112: this chip is integrated in some old SH boards with CEU. Jacopo has a camera module that can be connected to a Peach to board test the driver. He hasn't been able to capture any image yet. +11:19 < pinchartl> - RZ/N pincontrol has been sent upstream and then abandoned. Is there interest in those chips ? +11:19 < pinchartl> I'm not sure why Z clock support and CPU idle is there, it's not multimedia +11:20 < pinchartl> so I'll remove that +11:20 < kbingham> I would like to start some pressure on the fault redundant V4L2 topic, so if it's ok - I'll try to formulate a RFC patch / and or email thread to bring the topic up with Hans as base work. +11:20 < pinchartl> I think that make sense +11:21 < pinchartl> CEU is more or less unfunded +11:21 < pinchartl> Jacopo seems to like it though +11:21 < pinchartl> so if he can find a bit of time to spend on it, I have no issue +11:21 < pinchartl> but I'd like to concentrate on two topics for the base time +11:21 < pinchartl> - backlog reduction +11:21 < pinchartl> this includes both our own backlog and the BSP patches +11:21 < pinchartl> - GMSL +11:22 < pinchartl> fault-tolerant V4L2 is part of that +11:22 < pinchartl> any comment ? +11:22 < geertu> FWIW, Armadillo also has an MT9T112. So if it works on Peach, I can test CEU on Armadillo. +11:22 < geertu> s/CEU/the new CEU/ +11:22 < neg> I think the two focus areas for base are good +11:23 < kbingham> Yes, I think having directed focus is definitely a postive +11:23 < pinchartl> geertu: thanks for the offer +11:23 < neg> kbingham: as a first step now that parallel input support is in media-tree would be to move the vl42 video device registration to VIN probe(), I'm sure Hans will react to that :-) +11:24 < kbingham> neg, I think getting an initial reaction is a good starting point for the dicussion :) +11:28 < pinchartl> regarding backlog reduction and GMSL, I propose to discuss tasks over e-mail as this meeting is already running late. I'll initiate the discussion +11:28 < pinchartl> is that ok ? +11:28 < kbingham> Yes. +11:28 < neg> ok for me +11:28 < pinchartl> thanks +11:29 < pinchartl> next topic +11:29 < pinchartl> Topic 4. Periperi Annual Meeting +11:30 < pinchartl> lots of locations have been proposed since our last meeting in San Sebastian +11:30 < pinchartl> it's now time to decide +11:30 < pinchartl> Wolfram has proposed meeting in Paris right before or after Kernel Recipes +11:31 < pinchartl> while a week under the sun in southern Europe would have been more tempting for me, I think his proposal makes +11:31 < pinchartl> sense +11:31 < pinchartl> Paris isn't as horrible as the Belgian countryside :-) +11:31 < pinchartl> Magnus already mentioned he won't be able to attend due to a personal additional task +11:32 < pinchartl> the real question, of course, is whether we'll have budget to organize this +11:32 < pinchartl> while it hasn't been confirmed, I have repeatedly been told that we should move forward with planning +11:32 < pinchartl> dammsan: is my understanding correct ? +11:32 < dammsan> i think so +11:33 < pinchartl> thank you +11:33 < pinchartl> what's everybody's opinion about the proposed location and time ? +11:34 < pinchartl> KR is Sep 26-28 +11:34 < dammsan> it is about time for me to wrap up, may i be excused? +11:34 < Marex> pinchartl: I'll be speaking at ER, vaishali at KR I think +11:34 < Marex> pinchartl: how does one register to KR , are the tickets available already ? +11:34 < Marex> pinchartl: it'd suck to have to wait it out +11:34 < kbingham> Marex, no I don't think tickets are available yet. +11:35 < kbingham> But they go pretty fast - so it's best to register on the day they come out;. +11:35 < Marex> kbingham: which is ... when ? :) +11:35 < Marex> kbingham: happened to me last time, yeah +11:35 < kbingham> Marex, Exactly. +11:35 < kbingham> When :) +11:36 < kbingham> The time I went - the release date was announced on twitter. +11:36 < pinchartl> there's usually about 100 seats available +11:36 < Marex> bleh +11:36 < pinchartl> I'm not sure it would be fair taking 10% of that for our team... +11:37 < pinchartl> I mean, if people want to attend, sure, but I don't think we should push everybody to attend just because we would meet before or after the conference +11:37 < Marex> pinchartl: except I think many people do want to attend anyway +11:37 < wsa_> I am only available before KR +11:38 < pinchartl> Marex: has the schedule been decided already, or is it still worth proposing a talk ? +11:38 < pinchartl> ER is Sep 24-25 +11:38 < Marex> pinchartl: they are announcing speakers +11:39 < Marex> pinchartl: you can always try +11:39 < pinchartl> so the best option would likely be to meet the week before the conference +11:39 < pinchartl> Sep 17-21 +11:39 < pinchartl> is everybody available ? +11:40 < kbingham> Yes here. +11:40 < pinchartl> Marex: just for my information, when did you submit your talk proposal ? +11:40 < geertu> I think it's doable +11:40 < pinchartl> wsa_: how about you ? +11:41 < wsa_> that week works for me +11:41 < wsa_> we have a meeting scheduled on 20th anyhow ;) +11:41 < pinchartl> :-) +11:41 < neg> 17-21 looks OK in my calendar +11:41 < uli___> good for me, too +11:43 < Marex> pinchartl: they polled me for a talk in Feb or so +11:43 < Marex> pinchartl: then I heard nothing for a long time, then they asked me for abstract a few days ago +11:43 < Marex> 17-21 is I think OK for me +11:43 < pinchartl> Marex: thanks +11:43 < pinchartl> ok, please block those dates +11:43 < pinchartl> and submit a travel plan to secure budget +11:44 < pinchartl> with cost estimates for travel and accommodation +11:44 < uli___> to whom? +11:44 < wsa_> I assume we are going for the huge appartment thing again? +11:44 < Marex> in Paris ? :) +11:44 < Marex> I thought there were only small romantic apartments there +11:44 < pinchartl> dammsan: as Morimoto-san isn't here, should he volunteer to handle this ? :-) +11:45 < pinchartl> I think we can send him the travel plans +11:45 < pinchartl> wsa_: I think it would make sense, both from a cost point of view and from a meeting infrastructure point of view +11:45 < wsa_> Marex: if that's the case, I might have no time to work +11:45 < wsa_> ;) +11:45 < pinchartl> we will need two or three apartments I assume +11:45 < Marex> pinchartl: +1 +11:46 < dammsan> good idea +11:46 < dammsan> =) +11:47 * vaishali wonders what happens in periperi annual meeting and if she is supposed to attend it. +11:47 < geertu> wsa_: How many small romantic apartments do you need? ;-) +11:47 < pinchartl> 3 apartments = one per group leader ? +11:49 < geertu> 162€ for the train to/from Paris +11:49 < pinchartl> dammsan: could you be so kind to explain to vaishali what the annual meetings are ? +11:49 < wsa_> geertu: depends a bit on how widespread polyamory is in Paris :) +11:49 < neg> 3 group leaders, 3 apartments ... is this one of these TV realtiy shows where we compete and vote ppl to exile? +11:50 < dammsan> i think neg summed it up pretty well =) +11:50 < kbingham> Lol :) +11:50 < geertu> vaishali: Pinchartl may ask you to bring a spoon... +11:51 < marex-cloud> geertu: whatever happens in periperi annual meeting, stays in the meeting ... it's like Vegas ;-) +11:51 < geertu> marex-cloud: Can you get married with Elvis? +11:51 < pinchartl> vaishali: in a nutshell, we spend a week together to discuss yearly planning +11:51 < marex-cloud> geertu: sssssssssssh +11:51 < wsa_> We have something like a mixture of a co-working space and a hotel near where I live. Maybe something like this exists in Paris as well? I'll check +11:51 < pinchartl> and possibly organize code camps on the side if time permits +11:53 < neg> I think more code camp time is a good idea, the FOSDEM one was productive IMHO +11:54 < pinchartl> neg: I agree with you +11:54 < vaishali> pinchartl: Ok, code camps sounds like fun. As I'm coming for KR anyway, I think I can come a week early. +11:54 < pinchartl> vaishali: perfect :-) +11:54 < pinchartl> let's try to close the meeting, it's getting late +11:54 < pinchartl> Topic 5. Next Meeting +11:54 < pinchartl> two weeks from now +11:54 < pinchartl> it has been agreed on already, so that's easy +11:55 < pinchartl> that's all for me. is there anything else that anyone would like to discuss ? +11:55 < kbingham> All good here! +11:55 < neg> not from me, thanks all +11:55 < marex-cloud> uli___: I've got to step out for a bit, but please recheck the ATF U-Boot dram thing +11:55 < marex-cloud> All good here +11:55 < wsa_> all fine here +11:56 < pinchartl> uli___: dammsan: anything else for you ? +11:56 < uli___> nope +11:56 < marex-cloud> uli___: I'm happy to discuss that over IRC +11:56 < pinchartl> in that case +11:57 < pinchartl> I declare the meeting adjourned +11:57 < pinchartl> thank you all for attending +11:57 < pinchartl> have a nice day diff --git a/wiki/Chat_log/20180726-core-chatlog b/wiki/Chat_log/20180726-core-chatlog new file mode 100644 index 0000000..c880f55 --- /dev/null +++ b/wiki/Chat_log/20180726-core-chatlog @@ -0,0 +1,173 @@ +Core-chat-meeting-2018-07-26 + +09:32 < geertu> Welcome to today's Core Group Chat Meeting! +09:33 < geertu> Agenda: +09:33 < geertu> 1. Status Updates +09:33 < geertu> 2. Discussion Topics +09:33 < geertu> Topic 1. Status updates +09:33 < geertu> A) What have we done since last time: +09:33 < geertu> Marek studied PCIe errate. +09:33 < geertu> Morimoto-san worked on PeriJect. +09:33 < geertu> Niklas provided a fix for the V3M PFC crash for the stable tree. +09:33 < geertu> Shimoda-san investigated and fixed rcar-dmac issues, submmited an R-Car +09:33 < geertu> E3 USB3 host DTS node patch, and asked the HW team about V3H EXTAL +09:33 < geertu> value. +09:33 < geertu> Geert implemented rcar-gpio get_direction(), added author signoff +09:33 < geertu> checking to checkpatch, got bd9571mwv toggle power switch support +09:33 < geertu> accepted, made SATA device-passthrough for virtualization work, and +09:33 < geertu> reworked the R-Car gen3 OSC and RCLK improvements. +09:34 < geertu> B) What we plan to do till next time: +09:34 < geertu> Marek will work on U-Boot (SPL-alike replacement for Minimon) and +09:34 < geertu> OpenOCD for Gen3. +09:34 < geertu> Morimoto-san will add HTML support to PeriJect. +09:34 < geertu> Shimoda-san will pave the way forward for IPMMU. +09:34 < geertu> Geert plans to submit v2 of the R-Car gen3 OSC and RCLK improvements, +09:34 < geertu> work on LTSI sub-maintainership, and look into GPIO paravirtualization, +09:34 < geertu> and SYSC and PFC errata. +09:35 < geertu> C) Problems we have currently: +09:35 < geertu> Marek is suffering from the European heat wave. +09:35 < geertu> Morimoto-san wonders if PeriJect is good enough to use, and how to +09:35 < geertu> migrate from periupport and peripelist. +09:35 < geertu> Ulrich has been suffering flaky Internet for weeks. +09:35 < geertu> Anything I missed? +09:35 < geertu> Ah, Simon just sent his report +09:36 < geertu> Kaneko-san posted M3-N CPUFreq upport, and will test it. +09:37 < horms> On the Kaneko-san front. Main task is to get him hooked up to Magnus's lab. Second task is to address missing patches he reported in his backports. I'm assuming these tasks fall to me. +09:37 < horms> Missing patches are only in backports he hasn't posted :) +09:38 < horms> Sorry once again for the late report. +09:39 < geertu> horms: Havw you tried contacting Olof privately? +09:40 < horms> I am considering it after the most recent wave of feedback. +09:40 < horms> I think he is conciously or otherwise trying to tweak the realationship between himself and us (and possibly other downstreams too) +09:40 < horms> It might help to understand why that is happening. +09:41 < horms> e.g. he is unhappy about something; Linus is unhappy about something; he has assumed more control over ARM SoC, ... +09:42 < horms> Feedback from the team is of coruse welcome as I see my role mainly as an intermedeary +09:42 < wsa_> TBH I didn't notice much of that, except his wish to aquash patches more +09:42 < geertu> Most other pull requests seem to be answered with "Merged, thanks" +09:42 < wsa_> squash +09:43 < wsa_> and i do understand that +09:43 < horms> So the thing is. I don't mind if we tweak our processes and that works better for everyone. +09:43 < Marex> horms: you think Linus is pushing on Ojn ? +09:43 < horms> Squashing may be in that category, but its a bit too early to say +09:44 < Marex> horms: ah, forget what I said ... +09:44 < horms> But I don't want Renesas to become some sort of punching bag +09:44 < horms> Marex: I think is possible +09:44 < horms> Its also possible that I am blowing things out of proportions +09:44 < wsa_> horms: i surely agree on not being a punching bag :) +09:44 < Marex> horms: please ask him what's this about, being forced to drop patches is really sad +09:45 < horms> And his requests can be distilled into 3 categories each of which are reasonable(ish) +09:45 < horms> 1) sqaush 2) shorter changelogs (Arnd liked longer ones) 3) specific opinions on some specific patches +09:45 < wsa_> does renesas add more SoCs than other vendors these days? +09:46 < horms> But perhaps there is little harm in simply asking him privately +09:46 < horms> wsa_: maybe. It certainly has a lot upstream +09:46 < kbingham> horms, Is olof changing your tags, and thus breaking your signatures? (/me grabs popcorn to read Olof's replies) +09:46 < wsa_> yes +09:47 < geertu> Renesas is pumping out SoCs at 2 SoCs/kernel release these days +09:47 < geertu> Anyway, let's continue +09:47 < geertu> Topic 2. Discussion Topics +09:47 < geertu> RZ/G2 compatible values +09:47 * wsa_ still recalls Arnd at last ELCE mentioning Renesas at second place when asked about vendors having good upstream support +09:48 < geertu> Chris Patterson just asked about this, and he would like to join our discussion. Is that OK? +09:48 < pinchartl> wsa_: who was first ? +09:48 < wsa_> with Atmel being 1st, but all agreed they have more simple chips in the first place :) +09:49 < wsa_> I think GPUs were excluded in that discussion :/ +09:49 -!- patersonc [c18ddb24@gateway/web/freenode/ip.193.141.219.36] has joined #periperi +09:49 < patersonc> Mornin +09:49 < geertu> Welcome chris +09:49 < wsa_> Hi Chris! +09:50 < kbingham> Hola :) +09:50 < Marex> Hey +09:50 < geertu> Some of you may have met Chris. He's working on RZ/G. +09:50 < horms> Hi Chris +09:50 < uli___> hi +09:50 < geertu> So the first SoC they're upstreaming support for is RZ/G2M aka R8A774A1 +09:50 < neg> patersonc: hi :-) +09:51 < geertu> using compatible value "renesas,r8a774a1" +09:51 < geertu> But more are to follow, cfr. the email I sent to the mailing list. +09:52 < patersonc> Fun times +09:52 < geertu> Recently, we started using 5 digits in compatible values, even if the last one is a zero (e.g. r8a77970) +09:53 < geertu> However, there will also be an RZ/G2M variant R8A774A0 +09:53 * jmondi would bribe patersonc to get an iWave board :p +09:53 < geertu> AFAIC it would be identical, except for the lack of HDMI +09:54 < geertu> Of course I'd like to avoid having both "renesas,r8a774a1" and ""renesas,r8a774a0" compatible values. +09:54 < patersonc> jmondi: depends on what you want to do with it ;) +09:55 < geertu> We could settle on "renesas,r8a774a", but then there's the risk there will be a comnpletely differeny R8A774A5 later (cfr. M3-W and M3-N) +09:55 < geertu> s/comnpletely differeny/completely different/ +09:56 < horms> I think that this is not very different to the problem we have faced in the past +09:56 < geertu> Does anyone have an opinion about this? +09:56 < wsa_> I gotta run +09:56 < horms> And the solution has essetntially been that new compat values are cheap +09:56 < wsa_> cya guys +09:56 < geertu> wsa_: Bye! +09:57 -!- wsa_ [~wsa@p5099505f.dip0.t-ipconnect.de] has quit [Quit: ...] +09:57 < horms> And the cost of finding ourselves painted into a corner would be unbearable +09:57 < geertu> "cheap" as in lot's of DT binding doc updates? +09:57 < kbingham> is it bad to have "renesas,r8a774a" and "renesas,r8a774a5" ? +09:57 < horms> Yes, that has essetntially been the possition for some time now +09:57 < geertu> patersonc: R8A774A1 and R8A774A0 would really be the same die? +09:58 < patersonc> I would assume so. Just the HDMI IP disabled +09:58 < patersonc> For licencing reasons +09:58 < horms> Ok, so we could have an extra .dsti file that did disabled/removed that node? +09:58 < geertu> Then using "renesas,r8a774a1" for R8A774A0, too, would be acceptable, as it conforms to the original meaning of compatible values +09:59 < geertu> horms: The HDMI node would not be instantiated unless someone changes its status to "okay" in the board DTS +10:00 < horms> ack +10:00 < horms> Perhaps that is an easy way out in this case +10:00 < pinchartl> patersonc: does "HDMI IP disabled" really mean disabled ? or will it work if someone tries to use it ? +10:00 < patersonc> Would we use both r8a774a* compatible strings in r8a774a1.dtsi? +10:00 < geertu> It would only be an issue if someone plugs an A0 SoC into a board designed for an A1 (assumed they'll be pin compatible) +10:00 < horms> kbingham: I think that is not bad but at the same time it would be confusing -> not particularly good +10:01 < patersonc> pinchartl: I would hope they would blow an efuse for HDMI, so it won't be usable +10:01 < kbingham> horms, Ack. +10:01 < geertu> patersonc: No, just "renesas,r8a774a1" (and "renesas,*rcar-gen3*" as fallback for individual IP cores where appropriate, cfr. RZ/G1) +10:01 < patersonc> Okay +10:02 < horms> geertu: I think that is fine if we are satisfied that these two SoCs really are compatibile. That seems to be the case from what Chris is saying +10:02 < geertu> horms: Agreed +10:02 < patersonc> That's the information I have! +10:02 < horms> A lot of this thining regarding compat values goes back to a time when we could not tell if hw A was really compatibile with B or not +10:03 < horms> geertu: ok, so assuming that is settled. are there other related compat valeues to discuss +10:03 < pinchartl> horms: I agree with you +10:03 < patersonc> Given that they aren't creating a new device anyway (using R-Car), I doubt they are going to create a new device just to remove the HDMI IF ;) +10:04 < geertu> patersonc: Will they blow eFuses for the other "removed" devices? +10:04 < patersonc> geertu that would be my assumption +10:04 < geertu> Did they actually do that on RZ/G1? +10:04 < patersonc> As far as I understand it, yet +10:04 < patersonc> yes * +10:04 < geertu> OK. +10:04 < patersonc> The whole point was to save on costs +10:05 < geertu> So let's go for "renesas,r8a774a1". +10:05 < geertu> patersonc: Thanks for joining, Chris! +10:05 < patersonc> Thank you all! +10:05 < horms> This sounds like a good option: It leaves us room to move in future. And solves the curent problem. +10:06 < patersonc> You can ack Biju's patches now ;) +10:06 < geertu> patersonc: Sure. Will do. +10:06 < horms> Are you sure you don't also want to document "renesas,r8a774a2"? +10:06 < patersonc> horms you mean a0? +10:06 < horms> I guess there is no point unless its also used in a .dtsi +10:06 < horms> yes, sorry, my bad +10:07 < horms> and we seem to now want an extra .dtsi at this point +10:07 < geertu> Perhaps at the highest SoC level (DT root node)? +10:07 < horms> I'm just thinking in terms of freedom to move if we need to +10:07 < horms> But perhaps I need to just accept that the hw is the same +10:07 < patersonc> We could document a0 (and all the others), but I'm not sure I'll ever actually get hold of an a0 device. They will just go straight to customers. Only a1 will be used on the reference hardware. +10:07 < geertu> We don't have r8a77951 for H3 ES2+ neither +10:08 < horms> True. I was pondering the similarities between this problem and R-Car Gen 3 ES versions. +10:08 < patersonc> At least with RZ/G we shouldn't have lots of ES versions +10:08 < patersonc> (famous last words) +10:09 < horms> Ok, so we think the hw is compatible +10:09 < horms> with good reason. +10:09 < horms> It might change, f.e. with a new ES versinos +10:09 < horms> But we don't have a good way to deal with that +10:09 < horms> And as a bonus we think its unlikely +10:10 < horms> So the simple solution of just documenting and using "renesas,r8a774a1" seems sufficiently safe +10:10 < horms> Is that about where we are? +10:10 < geertu> In hindsight, probably we should have made H3 ES1.0 a different SoC, and thus used r8a77951 for H3 ES2+ +10:10 < patersonc> Sounds good to me horms +10:11 < geertu> Agreed +10:11 < horms> geertu: true. I guess my only question is if we should learn from that mistake at this time +10:11 < geertu> horms: Well, most ES increments are small fixed +10:12 < patersonc> I'm sorry but I have to go to the doctors. I'll be back in a couple of hours. Thank you all for your time! +10:12 < geertu> patersonc: Thx, CU, and take care! +10:12 < geertu> Any other topic to discuss for the regular core meeting? +10:14 < horms> I also need to leave soon as someone is coming to inspect my current home +10:14 < horms> patersonc, all: thanks for the good conversation on this topic +10:14 < geertu> So I think we're done. +10:14 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20180726-io-chatlog b/wiki/Chat_log/20180726-io-chatlog new file mode 100644 index 0000000..7b6ac76 --- /dev/null +++ b/wiki/Chat_log/20180726-io-chatlog @@ -0,0 +1,65 @@ +09:03 < wsa_> Welcome to the IO meeting! +09:04 < wsa_> As mentioned in my mail, I couldn't prepare a summary this time, so I will start with questions I have about the reports you sent +09:04 < wsa_> and/or about upport status +09:04 < wsa_> geertu: I noticed some suspend/resume patches in periupport which have no further comments +09:04 < wsa_> for msiof +09:05 < wsa_> do you know about them? +09:05 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi +09:05 < morimoto> Hi +09:05 < wsa_> other than that, thanks for the suggestions about SATA, I think we are on a good path there +09:05 -!- ulih [~Mutter@x2f7feb1.dyn.telefonica.de] has quit Quit: Mutter: www.mutterirc.com +09:06 < wsa_> hi morimoto-san +09:06 < geertu> wsa_: I'll have a look again +09:06 < wsa_> thanks! +09:07 < wsa_> neg: about using !4tap in your newest patch series. We got that behaviour from the BSP, right? Does it make sense to get some confirmation from the HW team? +09:08 < wsa_> Or do you understand why it is not needed in this case? I have to admit, I don't. +09:08 < horms> Unfortunately I have no insight beyond the BSP code +09:09 * wsa_ wonders if neg fell asleep again to win another bottle of schnaps... +09:10 < Marex> wsa_: the SDHI chapter from new release of the datasheet explains the !4tap better, maybe that's where it came from ? +09:11 < wsa_> shimoda: would you be so kind and send me a diff for the USB tasks in peripelist/io/todo? I think the tasks got more detailed and I am not sure I can map it properly. +09:11 < shimoda> wsa_: about upport status of "M,090dcb6d8ad59559610dc51b62636a74b6ac1d4a", bsp team agree about this marks to 'N' +09:11 < shimoda> wsa_: I'll check the todo +09:12 < wsa_> Marex: does it explain why to not read SCC errors? I can't recall but just might have missed it... +09:12 < Marex> wsa_: oh that one, where you shouldn't read the SCC error register in HS400 mode ? :) +09:13 < wsa_> pinchartl: jmondi: I hope you like the new SCCB handling, too? I think it is an elegant solution :) +09:13 < Marex> wsa_: I think the whole HS400 switch is real simple, which is what the SDHI tries to explain in a tad clumsy way +09:14 < wsa_> And it gets rid of the "implement I2C_M_STOP" task for i2c-rcar... +09:14 < Marex> wsa_: you don't need to calibrate again for the HS400 +09:14 < pinchartl> wsa_: I've always thought that regmap had a bit too large overhead for my tastes, but apart from that, yes, it's all fine +09:14 < Marex> wsa_: that's why you don't need to read the SCC register I think +09:15 < pinchartl> but I2C_M_STOP should still be implemented, don't you think ? :-) +09:15 < wsa_> Marex: but 8 tap vs 4 tap has nothing to do with HS400. It is only different between SoC versions... +09:15 < geertu> wsa_: H3 switches between 4 and 8 taps for HS200 vs. HS400 +09:16 < Marex> wsa_: from what I understand, on Gen3, it's 8 tap in HS200 and 8/4 tap in HS400 depending on SoC +09:16 < wsa_> shimoda: thanks for checking the todo +09:17 < wsa_> huh? +09:17 < neg> Sorry for oversleeping, just got hear reading up on the backlog +09:17 < wsa_> We need to clarify this understanding :) But this is better done by email I'd think +09:17 < wsa_> Unless neg doesn't have that killer arguemt ;) +09:18 < Marex> wsa_: read the latest SDHI chapter, this information is right at the end ;-) +09:18 < wsa_> I will read it (again) +09:20 < wsa_> uli___: thanks for the interest in the scif task, I will add you to the task +09:20 < neg> No argument beyond the BSP so probobly email is a good idea +09:20 < Marex> wsa_: R-CarH3_M3_05_70_71_SDHI_MMC_0019_e.pdf this is what I'm reading, but I hear there's something even newer +09:20 < wsa_> uli___: i think there is also SCIF suspend/resume patches open (which shouldn't be much work from what I recall) +09:21 < wsa_> there is 0024 +09:21 < wsa_> and I found the last chapter a bit confusing with the latest additions +09:22 < Marex> wsa_: the 0019 was nice and clear, so that helped me understand it a bit better +09:22 < wsa_> we should discuss our understanding on periperi, that's a good idea, me thinks +09:23 < wsa_> vaishali_cloud: are you here? +09:24 < vaishali_cloud> wsa_: Yes, for next 20 minutes. Have to enter visa office after that :) +09:24 < vaishali_cloud> s/enter/enter in +09:24 < wsa_> good luck with the visa office! +09:25 < shimoda> wsa_: i sent an email about io/todo of usb tasks +09:25 < wsa_> I wanted to know if you have everything you need for stress-testing SDHI suspend/resume? +09:26 < wsa_> the above was for vaishali_cloud (triggering notification again ;)) +09:26 < vaishali_cloud> wsa_: dammsan is going to get back to me today. I'll email you after that. +09:27 < wsa_> okay +09:27 < vaishali_cloud> Thanks for being patient on that. :) +09:27 < wsa_> if you have not started yet, it might make sense to start with suspend/resume for the GPIO multiplexer we need for SATA +09:28 < wsa_> but I'll wait for your email +09:28 < wsa_> and respond to that +09:28 < wsa_> That's all from my side, any questions from your side? +09:29 < vaishali_cloud> wsa_: Sure, I'll check that too. +09:30 < wsa_> ok, then, my time is up! +09:30 < wsa_> thanks all for this meeting diff --git a/wiki/Chat_log/20180726-mm-chatlog b/wiki/Chat_log/20180726-mm-chatlog new file mode 100644 index 0000000..a156dd6 --- /dev/null +++ b/wiki/Chat_log/20180726-mm-chatlog @@ -0,0 +1,290 @@ +Multimedia-chat-meeting-2018-07-26 + +10:15 < pinchartl> welcome to the multimedia meeting +10:15 < pinchartl> let's start with status updates +10:15 < pinchartl> * Jacopo +10:15 < pinchartl> Since last meeting: +10:15 < pinchartl> - soc camera removal +10:15 < pinchartl> - BSP drm/du patch fishing and analysis +10:15 < pinchartl> - v2 mt9v111 +10:15 < pinchartl> - Patch review: ov5640, a few bits of sccb, & other multimedia related stuff +10:15 < pinchartl> Until next meeting: +10:15 < pinchartl> - More du/drm BSP patch fishing and upporting +10:15 < pinchartl> - Possibly resume drm_bridge work (Laurent: priority of this task?) +10:15 < pinchartl> - Ebisu VIN+DU: is anyone working on it? Is it of interest? +10:15 < pinchartl> Issues and Blockers: +10:15 < pinchartl> - BSP patch handling is time consuming with not a lot of visible output. +10:15 < pinchartl> Is this known and OK ? +10:16 < pinchartl> to answer your last question, I think it's known and OK, as one of the metrics used to evaluate us is the number of patches "upported" +10:16 < pinchartl> (as in dropped from the BSP as a result from our work) +10:16 < pinchartl> handling BSP patches improves that metric, so it should be fine +10:16 < pinchartl> morimoto: any comment on that ? +10:17 < pinchartl> jmondi: any other comment ? +10:17 < jmondi> pinchartl: I see... I'm only concerned that the output might be not much compared to the time spent on that... +10:17 < jmondi> but I understand... +10:18 < jmondi> pinchartl: what about ebisu and drm_bridge format? what are priorities? +10:19 < pinchartl> I'll work on DU for Ebisu as part of an additional task related to DU LVDS PLL +10:20 < pinchartl> for VIN, yes, it's of interest +10:20 < jmondi> neg: are you on this? ^ +10:20 < pinchartl> and regarding drm_bridge format, it's still useful, but has low priority at the moment +10:21 < jmondi> pinchartl: I see... ok then, please proceed with status updates +10:21 < pinchartl> thanks +10:22 < pinchartl> one question though +10:22 < pinchartl> how far are we from dropping soc-camera ? +10:22 < jmondi> good question +10:22 < jmondi> on our side (ceu and sh) I guess we're done +10:23 < neg> jmondi: ? +10:23 < pinchartl> have we addressed all the SH boards ? +10:23 < jmondi> Hans is to clean up the ARM part, I asked if he needs help and he said he'll handle this +10:23 < jmondi> pinchartl: yes, the only remaning bits is defconfigs, which Mauro is bouncing to SH people +10:24 < pinchartl> great news, thanks +10:24 < jmondi> neg: Enabling VIN on Ebisu: do you have plans? +10:25 < neg> jmondi: no plan as I no one steped up to test it, do have plans for V3H as Sergie steped up as a tester +10:25 < pinchartl> jmondi: you can go for it then +10:26 < pinchartl> * Kieran +10:26 < pinchartl> Since last meeting: +10:26 < pinchartl> - PeriSchedule - Is this useful to anyone else? +10:26 < pinchartl> https://gitlab.com/PeriPeri/peri-schedule # <source repo> +10:26 < pinchartl> https://periperi.gitlab.io/peri-schedule/ # <url> +10:26 < pinchartl> https://periperi.gitlab.io/peri-schedule/periperi.ics # <live +10:26 < pinchartl> calendar feed> +10:26 < pinchartl> (Note, because we can't host arbitrary code/projects on OSDR Kieran has created a private group "periperi" at gitlab, if you want to host code +10:26 < pinchartl> there, just create an account and join the group, or ask him to add you +10:26 < pinchartl> to it) +10:26 < pinchartl> - DU/Interlaced respin - v5 posted +10:26 < pinchartl> - D3 Interlaced investigation +10:26 < pinchartl> - Reviewed driver for Aptina MT9V111 +10:26 < pinchartl> - Looked at PeriJect +10:26 < pinchartl> - Planning tasks with Jacopo +10:26 < pinchartl> - Created git-hooks for periupport +10:26 < pinchartl> - Rebased vsp1 writeback prototype +10:26 < pinchartl> Until next meeting: +10:26 < pinchartl> - Retest/examine partition algorithm limitation patch +10:26 < pinchartl> - Repost writeback prototype +10:26 < pinchartl> - Submit GMSL for Renesas-drivers? <sometime ... soon> +10:26 < pinchartl> Issues and blockers: None +10:26 < jmondi> I need a tester or handle it from remote somehow +10:26 < pinchartl> kbingham: any comment ? +10:26 < pinchartl> jmondi: we should receive Ebisu boards soon(ish?), so I think you could find testers +10:26 < pinchartl> provided it doesn't require external hardware difficult to source +10:27 < kbingham> morimoto, I like your output (colorisation) on your peri-schedule example. ... +10:27 < kbingham> but I do worry - like pinchartl mentioned if one tool should do everything. ... though storing the data in a common place may not be terrible. +10:28 < kbingham> The part for me was linking to a generated ICS which is hosted so it integrates into my live google calendars, but we could automate the conversion of perischedule to ICS still and host somewhere. +10:28 < kbingham> It's mainly keeping the data live that matters ;) +10:29 < kbingham> Other than that ... no further comments from me at the moment. +10:29 < pinchartl> the concept of a task manager + bug tracker + calendar tool makes me wonder when we'll turn it into an e-mail client :-) +10:29 < kbingham> :D +10:29 < pinchartl> * Laurent +10:29 < pinchartl> Since last meeting: +10:29 < pinchartl> - Patch review +10:29 < pinchartl> - Additional tasks preparation +10:29 < pinchartl> - Part-time vacation +10:29 < pinchartl> Until next meeting: +10:29 < pinchartl> - Patch review +10:29 < pinchartl> - Additional tasks preparation +10:29 < pinchartl> - Revive the GMSL efforts +10:29 < pinchartl> Issues and blockers: None +10:29 < pinchartl> I'm back from holidays and fully operational now +10:29 < pinchartl> (well, as operational as possible at least +10:29 < pinchartl> ) +10:30 < jmondi> is that a good thing for us or not? +10:30 < pinchartl> any comment, anything I should look at with high priority ? +10:30 < pinchartl> jmondi: only you can tell +10:30 < jmondi> we managed to skip all the work while you were away +10:30 < kbingham> pinchartl, Will DU/Interlaced be able to make it to v4.19 ? +10:31 < kbingham> Oh ... actaully it may be blocked on me ... as I might need to find a way to limit on D3 still :( +10:31 < pinchartl> kbingham: for v4.19 I don't think so, we're too close to the merge window +10:31 < kbingham> Ok. +10:32 < kbingham> New target of v5 (v4.20) then :) +10:32 < pinchartl> that's reasonable I think +10:32 < pinchartl> * Morimoto-san +10:32 < pinchartl> Since last meeting: None +10:32 < pinchartl> Until next meeting: None +10:32 < pinchartl> Issues and Blockers: None +10:32 < pinchartl> morimoto: any comment? :-) +10:33 < pinchartl> * Niklas +10:33 < pinchartl> Since last meeting: +10:33 < pinchartl> - [PATCH 0/2] adv7180: fix format and frame interval +10:33 < pinchartl> - Talking to Hans about patchwork legacy. +10:33 < pinchartl> - Working on v4l2 virtual channel patches. +10:33 < pinchartl> - Reviewed potential CSI-2 VC patch-sets. +10:33 < pinchartl> - Worked with Mauro on STD merger of v4l patches. +10:33 < pinchartl> Until next meeting: +10:33 < pinchartl> - Vacation but hope to post next VC patch series. +10:33 < pinchartl> - Errata from latest datasheet for VIN and CSI-2 patches. +10:33 < pinchartl> Issues and blockers: None +10:33 < pinchartl> neg: any comment? +10:33 < pinchartl> when are your holidays exactly ? +10:33 < neg> no additional comment +10:34 < neg> Next week i will holiday and work, the week after I will be offline +10:34 < pinchartl> thank you +10:35 < pinchartl> * Simon (Kaneko-san) +10:35 < pinchartl> Since last meeting: +10:35 < pinchartl> - v1 and v2 of M3-N Audio support +10:35 < pinchartl> Until next meeting: +10:35 < pinchartl> - Testing M3-N Audio support +10:35 < pinchartl> - D3 Audio support +10:35 < pinchartl> Issues and blockers: +10:35 < pinchartl> - Some trouble finding patch to add Audio DMA node for R-Car D3 +10:35 * morimoto it is too fast, there is no chance to explain for me... +10:35 < pinchartl> morimoto: take your time :-) +10:35 < pinchartl> we won't ignore your messages +10:36 < pinchartl> Simon is gone... +10:36 < pinchartl> * Ulrich +10:36 < pinchartl> Since last meeting: +10:36 < pinchartl> - Reviewed Condor DU/LVDS/HDMI patch +10:36 < pinchartl> Until next meeting: None +10:36 < pinchartl> Issues and blockers: None +10:36 < pinchartl> uli___: any comment? +10:36 < uli___> none +10:36 < pinchartl> thanks +10:36 < pinchartl> morimoto: now you have our full attention :-) +10:37 < morimoto> ahh, thanks +10:38 < morimoto> but, there is still no rule for us how to handle periject +10:38 < morimoto> thus, it seems bike-shade story for me, for now +10:38 < pinchartl> it's still an important matter +10:39 < pinchartl> I've replied to most of the e-mails, I'll handle the remaining one today and tomorrow +10:39 < morimoto> I still don't understand why you guys doesn't like 1 tool for multi topics +10:39 < kbingham> morimoto, It seems to me that we should ... just start using it ? +10:39 < pinchartl> in my opinion, we're really moving in the right direction +10:39 < pinchartl> and I think we should be able to start using it soon +10:39 < morimoto> kbingham: I agree. maybe we are misunderstanding each +10:40 < pinchartl> thanks for pushing it to a git repo, that will help tracking changes +10:40 < morimoto> np +10:40 < kbingham> (in regards to the peri-schedule, I saw it as a specialised tool that would turn human readable text into a google calendar feed, and didn't necesarily expect that to be part of periject) +10:40 < pinchartl> regarding one tool for multiple purposes, I'm fine with that when the purposes are related +10:40 < kbingham> That code 'could' live in periject too. +10:41 < morimoto> kbingham: about google calendar, can you share it to us ? +10:41 < kbingham> morimoto, I have :) +10:41 < morimoto> I think google calendar is such feature +10:41 < morimoto> nice +10:41 < kbingham> morimoto, https://periperi.gitlab.io/peri-schedule/periperi.ics +10:42 < kbingham> It's generated by code which is currently hosted privatly on gitlab, (because it contains our group confidential information about our meetings, so I didn't want that to be unnecessarily public) +10:42 < morimoto> no, I think you can select me on google calendar +10:42 < pinchartl> regarding periject, I'd like to concentrate on tasks and BSP commits (bug reports) first as that's the main target +10:42 < kbingham> The ICS file can be added as a calendar feed in google-calendar or any other calendar tool +10:42 < pinchartl> once done with that, let's see what else would make sense to integrate in the tool +10:43 < kbingham> (sorry - not file - URL ... you add the URL - and google reads it when it's updated) +10:43 < kbingham> you don't need to download the file, and then uplaod or anything like that - it's a one add job :) +10:44 < kbingham> To do the same from periject would require a public url space ... that's all. +10:44 < pinchartl> something that I think would be useful is to start populating the repository with a set of real tasks (let's say about 10) +10:44 < pinchartl> in order to better understand how it works +10:44 < kbingham> ^ I agree :) +10:45 < kbingham> Is it one file per task ? +10:45 < morimoto> kbingham: you can select +10:45 < pinchartl> I don't like having multiple options +10:45 < morimoto> 1 file / 1 task or 1 file / multi tasks +10:45 < pinchartl> as in one task per file, or multiple tasks per filie +10:46 < pinchartl> or with or without white spaces to indent lines within a file +10:46 < pinchartl> we should document the file format clearly +10:46 < pinchartl> and stick to one format +10:46 < pinchartl> otherwise it will become messy with everybody having a slightly different style +10:46 < kbingham> peri-lint.py ;) +10:47 < pinchartl> kbingham: we need a git commit hook that will validate the format +10:47 < kbingham> pinchartl, morimoto-san already has a git hook in place to do sanity checks +10:47 < kbingham> So I'm sure that can be extended as necessary +10:48 < kbingham> And actually - I like that the code lives in the same repository as the data in this instance - because it will enforce everyone being on the latest version of the code - if they have the latest version of the data ;) +10:48 < pinchartl> I think we should continue this discussion over e-mail to ensure we keep track of it +10:48 < kbingham> (normally I would have separated) +10:48 < morimoto> about alignment, creating "tool rule" is OK for me. But 1 task / 1 file vs multi task / 1 file is "operation rule" for me +10:48 < pinchartl> kbingham: I have mixed feelings about that +10:48 < pinchartl> it makes the history pretty messy +10:49 < morimoto> I want to have flexibility +10:49 < pinchartl> morimoto: why is it an "operation rule" ? (and what do you mean by that exactly ?) +10:51 < morimoto> I understand "you" don't like it. But "otherone" might like it. I don't want to force to 1 opinion +10:51 < morimoto> If you don't like it, you just don't do it. +10:52 < pinchartl> it then becomes a real mess +10:52 < morimoto> This is my "operation rule". If tool forced it it is "tool rule" +10:52 < pinchartl> what if I'd prefer a third format and implement support for it ? will it be accepted as I won't force anyone to use it ? +10:52 < pinchartl> or a fourth, fifth format ? +10:52 < pinchartl> also, it's not true that nobody would be forced to do it +10:52 < pinchartl> as we'll all have to modify tasks not created by us +10:52 < pinchartl> or at least read them +10:53 < pinchartl> readability is very important, and comes from consistency +10:53 < pinchartl> same as for coding style, if we had no coding style rule in the linux kernel, it would be awful +10:53 < morimoto> Having coding rule is OK for me. +10:54 < morimoto> About task vs file, let's use 1st. I think you are misunderstanding +10:54 < morimoto> or I'm misunderstanding +10:55 < pinchartl> the reason why I think we should have a single task per file is that looking at the contents of the tasks directory should give us an overview of all tasks, with file names containing the task subjects +10:55 < pinchartl> you can't do that with multiple tasks per fil +10:55 < pinchartl> e +10:56 < pinchartl> but again, I think we should continue this discussion over e-mail, it's getting out of scope for multimedia +10:56 < morimoto> agree +10:57 < pinchartl> thank you +10:57 < pinchartl> Topic 2. Additional Multimedia Tasks for Q3 +10:57 < pinchartl> we have agreed on additional tasks last time, I'll submit task descriptions to Magnus before the end of the week +10:57 < neg> thanks for doing that +10:57 < pinchartl> kbingham: jmondi: have you sorted out how to split the work between the two of you ? +10:57 < pinchartl> neg: you're welcome +10:58 < jmondi> pinchartl: so far we've been working in going through the BSP patches realted to du/drm together +10:59 < pinchartl> do you need any help ? +10:59 < jmondi> so short answer is "not yet" +10:59 < kbingham> pinchartl, not a direct split, because we don't have a clear boundary +10:59 < pinchartl> ok :-) +10:59 < jmondi> Help yes, but I think going through email is easier +11:00 < pinchartl> fine with me +11:00 < pinchartl> Topic 3. Periperi Meetings +11:00 < pinchartl> The plan for an annual meeting in Paris around Kernel Recipes has been canceled, and the meeting will take place in Edinburgh around ELCE. +11:00 < pinchartl> I would still like to organize a multimedia code camp in September, the two candidate locations being Paris around Kernel Recipes and A Coruña around XDC. +11:00 < pinchartl> who would join such a code camp ? +11:00 < jmondi> if it is fine to send patches to periupport as we've been doing recently... we can identify patches to look into and have them reviewed commented by you and the team +11:00 < pinchartl> jmondi: yes, it's totally fine +11:00 < jmondi> sorry, I was still on previous point +11:01 < jmondi> pinchartl: o/ +11:01 < kbingham> pinchartl, I'm more likely to head to paris than A Coruna. +11:01 < jmondi> conference wide I would go for Paris, location wide for XDC +11:02 < jmondi> but I've never been to XDC, so it might be a pleasant surprise +11:02 < pinchartl> conference-wise I think XDC is more related to multimedia than KR +11:02 < pinchartl> also, with the very limited number of tickets for KR, we might not be able to attend the conference +11:02 < neg> would join both but as stated erlier I need to go back during weekend for the proposed dates. If we are in Paris I will rejoin if we are in A Coruna maybe not +11:03 < pinchartl> if we go to A Coruna should we then try to host the code camp before the conference ? +11:04 < jmondi> neg: shouldn't you be back on the weekend of the 22? +11:05 < jmondi> pinchartl: before the conference it would be 24th to 26th, after it would span to the 28th to the Monday after? +11:05 < jmondi> more or less +11:05 < neg> jmondi: yes the 22 I need to be in Stockholm. Other dates I'm free +11:06 < jmondi> neg: both conferences are 26th to 28th +11:06 < pinchartl> jmondi: the conference is on 26-28 +11:06 < pinchartl> neg: sorry I got the dates wrong +11:06 < jmondi> Embedded recepies is 24th to 26th +11:06 < pinchartl> we should then have the code camp after the conference +11:06 < jmondi> pinchartl: I think so +11:07 < pinchartl> regardless of whether it's in Paris or Spain +11:07 < pinchartl> I think we decided for the week before because Wolfram wasn't available the week after (if I recall correctly) +11:07 < pinchartl> we if it's just multimedia, it doesn't matter +11:07 < pinchartl> s/we/but/ +11:07 < neg> if the reschdeuling of code camp to after the conference is possible it would be benificial for me and then I would vote for Spain :-) +11:09 < pinchartl> ok +11:09 < pinchartl> I'll sleep over that, let's discuss it again in the next few days +11:09 < pinchartl> Topic 4. Next Meeting +11:09 < pinchartl> that's settled already, 2 weeks from now +11:09 < pinchartl> any other topic to discuss ? +11:10 < neg> not from me +11:10 < pinchartl> anyone else ? +11:10 < pinchartl> jmondi: ? +11:10 < pinchartl> kbingham: ? +11:10 < pinchartl> morimoto: ? +11:10 < pinchartl> uli___: ? +11:10 < kbingham[m]> Good here +11:10 < morimoto> not from me +11:10 < uli___> nope +11:11 < pinchartl> in that case I declare the meeting adjourned +11:11 < pinchartl> thank you all for attending +11:11 < pinchartl> and have a nice day +11:11 < jmondi> bye bye, thanks +11:11 < pinchartl> oh, a generic question +11:11 < pinchartl> shimoda: if you're still here +11:11 < neg> thanks all +11:11 < pinchartl> when do you plan to ship the Ebisu boards ? +11:11 < shimoda> pinchartl: yes? +11:12 < shimoda> ah, morimoto-san is doing export control +11:12 < pinchartl> morimoto: the question is for you then :-) +11:12 < morimoto> pinchartl: now it is under export paper work +11:12 < pinchartl> do you have an idea when it would ship ? my additional task due for 9/M will depend on access to an Ebisu board +11:13 < morimoto> I think paper work will takes 1 week or 2week +11:13 < morimoto> but no +11:13 < morimoto> but no guarantee +11:13 < pinchartl> ok. if it gets delayed, could you please keep me informed ? +11:14 < morimoto> OK +11:14 < pinchartl> thank you very much +11:14 < pinchartl> no other question :-) +11:14 < pinchartl> have a nice day everybody diff --git a/wiki/Chat_log/20180809-core-chatlog b/wiki/Chat_log/20180809-core-chatlog new file mode 100644 index 0000000..50e210d --- /dev/null +++ b/wiki/Chat_log/20180809-core-chatlog @@ -0,0 +1,231 @@ +Core-chat-meeting-2018-08-09 + +09:31 < geertu> Welcome to today's Core Group Chat! +09:31 < geertu> Agenda: +09:31 < geertu> 1. Status Updates +09:31 < geertu> 2. Discussion Topics +09:31 < geertu> Topic 1. Status updates +09:31 < geertu> nA) What have we done since last time: +09:31 < geertu> Marek worked on U-Boot (USB VBUS and PHY on Gen2, HS400 on Gen3) and Linux +09:31 < geertu> (PCIe L0s/L1 handling on Gen3). +09:31 < geertu> Morimoto-san worked on PeriJect and Ebisu-4D export. +09:31 < geertu> Shimoda-san submitted PWM patches, and provided LTSI v4.14 snapshot +09:31 < geertu> feedback. +09:31 < geertu> Geert submmited v2 of R-Car gen3 OSC and RCLK improvements, reviewed lots +09:31 < geertu> of patches, enabled the Global Timer on Cortex-A9 MPCore SoCs, +09:31 < geertu> sub-maintained LSTI, and started looking into QEMU GPIO handling. +09:32 < geertu> B) What we plan to do till next time: +09:32 < geertu> Kaneko-san will test the M3-N CPUFreq upport. +09:32 < geertu> Marek will continue U-Boot SDHI HS400 support. +09:32 < geertu> Morimoto-san will ship Ebisu-4D boards. +09:32 < geertu> Shimoda-san will check the new LTSI v4.14 snapshot test results from the +09:32 < geertu> RVC test team, and will pave the way forward for IPMMU. +09:32 < geertu> Geert will review LTSI submissions during the merge window. +09:33 < geertu> C) Problems we have currently: +09:33 < geertu> Linus postponed v4.18 by one week, conflicting with Geert's holiday +09:33 < geertu> schedule. Hence next renesas-drivers release will be +09:33 < geertu> renesas-drivers-2018-08-21-v4.18. +09:33 < geertu> Anything I missed? +09:34 < geertu> s/submmited/submitted/ +09:35 < geertu> Lazy Summer (although it's a lot colder again)... +09:35 < Marex> geertu: well, HS400 in U-Boot is dragging on because the MMC maintainer is horribly slow to respond ... I might need to bypass him again at some point +09:35 < geertu> Marex: I'm sure you'll handle that fine +09:35 < horms> ... and for the same reasons my LTSI submission will be up to v4.18-rc8 rather than v4.18 +09:36 < Marex> geertu: just like last time ... sadly ... we might be looking for a new mmc maintainer ;-) +09:36 < geertu> horms: Np, as v4.18 will (should) be released long before the LTSI merge window closes +09:36 < horms> not before the end of this week which is when I will be sending the next round of patches +09:36 < horms> before my holiday next week +09:37 < horms> otherwise it all falls to the last week of the merge window and the wheels could easily fall off at that point +09:37 < horms> I will follow-up with any patches added between v4.18-rc8 and v4.18 +09:37 < geertu> horms: Postponing to the last week makes it more difficult for Intel to try to counter Renesas again ;-) +09:38 < horms> That is true +09:38 < geertu> (although they already know our plan anyway) +09:38 < geertu> Topic 2. Discussion Topics +09:38 < horms> But I'd rather de-risk other parts aspects of the project +09:39 < geertu> horms: Sure, thx a lot! +09:39 < geertu> morimoto: periject? +09:39 < wsa> what's with that Intel vs Renesas talk? +09:40 < horms> wsa: its a story from many years ago +09:40 < morimoto> geertu: sorry I didn't read text, but periject what ? +09:40 < horms> wsa: whereby there were two major contributors to LTSI. Renesas and Intel. And magically Intel had slightly more patches than Renesas +09:40 < geertu> wsa: Intel ended up backporting ca. 3 more patches than Renesas +09:41 < geertu> morimoto: Can we discuss periject? +09:41 < wsa> so they could claim #1 +09:41 < wsa> ? +09:41 < horms> They also caused a hidious conflict with our work +09:41 < horms> wsa: yes, that is the theory +09:42 < morimoto> geertu: yes +09:42 < wsa> horms: bastards, I will only buy AMD cpus from now on! +09:42 < wsa> ;) +09:42 < horms> wsa: I got over it in time +09:43 < wsa> "There is no politics in open source" +09:44 < geertu> morimoto: The mic is yours! +09:44 < morimoto> thanks. +09:45 < morimoto> As you know I already posted periject on gitlab. you can try it. +09:45 < morimoto> I think "tool feature" is not yet 100% but almost OK +09:45 < geertu> morimoto: You have rebased the master branch? +09:45 < morimoto> Ah... yes +09:46 < morimoto> sorry, it is still v0.x version +09:46 < morimoto> After v1.0, I will not +09:46 < pinchartl> if I may chime in on this topic (being the main source of controversy...) +09:46 < pinchartl> I think we still haven't agreed on the development process +09:46 < pinchartl> and I don't see how we can build a tool to support a process if we don't define the process first +09:47 < pinchartl> that's been my issue since the beginning +09:47 < pinchartl> the face to face discussion Morimoto-san and I had in Tokyo answered lots of my questions +09:47 < pinchartl> and I tried to summarize the process discussions on the periperi mailing list +09:47 < pinchartl> but the mail thread quickly died +09:47 < pinchartl> to word this differently, I think we need to agree about what we want to do before doing it +09:48 < morimoto> 1 question. what is your problem ?? +09:49 < wsa> what are the open questions there? I am fine with trying morimoto-san's tools for now... +09:49 < damm> i think we should split the process discussion from the tool +09:49 < damm> that said, i agree that process is important +09:49 < pinchartl> morimoto: my issue is that we still don't know what we want to do +09:49 < pinchartl> there have been lots of bikeshedding discussions about the tool +09:50 < pinchartl> about the format of stored data +09:50 < morimoto> OK, yes, let's split the topic +09:50 < pinchartl> and other topics +09:50 < pinchartl> and to answer those questions, we first need to know what we want to do +09:50 < pinchartl> at the moment, I see a tool, and I have no idea how to use it +09:50 < damm> i don't disagree +09:50 < pinchartl> for instance +09:50 < pinchartl> for your last report +09:50 < pinchartl> you tried to use the tool to generate the e-mail +09:51 < pinchartl> there were no B) and C) +09:51 < pinchartl> which isn't surprising +09:51 < wsa> we are at the tool level again +09:51 < pinchartl> as the tool doesn't support tracking future work plans at a bi-weekly level +09:51 < pinchartl> nor does it support tracking blockers +09:51 < wsa> I agree that "reporting emails" should be maybe a second or third step for the tool +09:51 < pinchartl> so, as an experiment, you tried adding that information to the task description +09:51 < pinchartl> it then ended up in the generated report +09:52 < pinchartl> but that's a hack +09:52 < damm> but does it blend? +09:52 < pinchartl> and if we start using a tool without knowing what we want to do it with +09:52 < pinchartl> we'll keep making hacks like that +09:52 < pinchartl> in different ways, for different people +09:52 < pinchartl> it will quickly become unusable +09:52 < wsa> we first need to deal with handling tasks, or? +09:52 < pinchartl> personally speaking, the logical order would be +09:53 < pinchartl> 1. what are the issues we have? +09:53 < pinchartl> 2. how do we want to solve them? +09:53 < pinchartl> 3. how do we implement tools to support that? +09:53 < wsa> and I would still like to understand why we can't use the tool for that right now... +09:53 < pinchartl> if we start by 3, then 2, then 1, I don't see how it could work :-) +09:53 < morimoto> wsa: +1 +09:54 < morimoto> Many times I explain it ... +09:54 < wsa> and I think it is not only about the issues we have but also about the issue Morimoto-san is having +09:54 < wsa> issues +09:54 < pinchartl> wsa: we have a mostly free-formed text format as a database. that won't work, we will end up with one format per person depending on personal preferences +09:54 < damm> pinchartl: i thought that it was the germans that liked process and order? +09:54 < pinchartl> see the discussion of 1 task per file vs. several tasks per file +09:55 < pinchartl> or Morimoto-san's today's e-mail report with free-formed B) and C) in the task description +09:55 < pinchartl> we haven't really started using this, and it's already forking :-) +09:56 < damm> my opinion is that people should use the tools that they like +09:56 < wsa> I do like processes, but there is just talk :) +09:56 < pinchartl> at the moment I feel that we're being given a database engine and we're told it's our bug and task tracker +09:56 < damm> but some interface/format is needed together with a known process +09:57 < pinchartl> what I'd like to get is jira/bugzilla/whatever. not those tools in particular, but something that operates at a similar level. with a defined work flow +09:57 < damm> how about the people that like processes come up with a process proposal? +09:58 < damm> i am for sure in the process camp +09:58 < damm> the we have a tool camp as well +09:58 < pinchartl> damm: let me locate the e-mail thread +09:58 < damm> once both are in semi-ok order we merge +09:58 < morimoto> I explained many times, but, I can create "Tool", but, you can create "Rule" +09:58 < damm> how many people are in the pro-process discussion camp? +09:59 < kbingham> I'm in the ... I want something that works camp ... +09:59 < damm> obviously not morimoto-san +09:59 < wsa> okay, let me summarize my take: +09:59 < pinchartl> morimoto: but my point is that the tool should be based on the rules, not the other way around +09:59 < damm> obviously laurent likes process +09:59 < kbingham> And ... I'm confused why we're writting our own tools when opensource tools already exist :) +09:59 < morimoto> pinchartl: yes, and, no my opinion +10:00 < morimoto> My opinion is like this +10:00 < damm> kibingham: i guess we need to know which problem we are solving first +10:00 < wsa> even the current process works for me as groupleader. not perfect, but works. I see Morimoto-san has problems reporting our progress upwards. I'd surely like to have this issue solved, it is important for all of us. +10:01 < morimoto> You can use Emacs, or VIM. it is editor. but, what you can write is under your rule. +10:01 < pinchartl> "Re: [periperi] Peri Tool Next" from "Date: Sat, 14 Jul 2018 05:27:30 +0300" +10:01 < pinchartl> Message-ID: <2412691.0qdXsgRgLR@avalon> +10:01 < wsa> I don't think I need details on this, because I'd think there is a lot of internal information and culture involved. +10:01 < damm> so why can't we simply do a work split? +10:01 < damm> break out the process discussion into a group that cares? +10:02 < damm> and figure out what we _need_ to do +10:02 < pinchartl> damm: that would work for me +10:02 < damm> then we can apply that to tools or whatnot +10:02 < damm> so currently the process group includes pinchartl and myself +10:03 < morimoto> my opinion is, try 1st, fix 2nd, rule 3rd :) +10:03 < damm> morimoto: that's why you are not in the process group =) +10:03 < morimoto> ok :) +10:03 < damm> morimoto: you are however very welcome to join if you'd like +10:03 < morimoto> I still don't understand what is the issue... +10:04 < damm> morimoto: you and i have discussed this before +10:04 < pinchartl> morimoto: ok, to make it very simple, my first issue is that with today's version of the tool, file format and documentation, I have no idea how to use it +10:04 < damm> if you get interested in the process let me know +10:05 < damm> pinchartl: you and i are at the same wave length +10:05 < morimoto> pinchartl: yeah, I don't know too. thus, it is "trial" +10:05 < pinchartl> damm: I don't know if that's a good or bad thing :) +10:05 < damm> but lets give morimoto-san freedom to poke around +10:05 < pinchartl> morimoto: shouldn't the trial phase be done separately from the production phase ? :-) +10:06 < damm> you are using process-think now =) +10:06 < damm> lets take that elsewhere +10:06 < morimoto> My opinion is, +10:06 < wsa> damm: I assume you know what is needed from the Renesas side for that process? +10:07 < damm> sort of +10:07 < morimoto> we can use tool to get all information. But we don't know how many information we have or we need, so far +10:07 < morimoto> So far I know is +10:07 < morimoto> 1) task, 2) BSP list +10:08 < morimoto> For each purpose, we can use 1) task/mm for example, 2) task/bsp, etc +10:08 < morimoto> each folder has each rule +10:08 < morimoto> few rule is it should use "clear Title", etc +10:09 < morimoto> we can create each rule for each purpose / each folder +10:09 < morimoto> Because of this, "tool" have limited rule +10:10 < morimoto> If you want to have "fixed" fule/format, you can create it +10:10 < morimoto> and force it by git hook ? +10:10 < morimoto> it is operation rule, not tool rule +10:10 < morimoto> this is my basic idea +10:11 < pinchartl> morimoto: I think the tool should enforce operation rules. otherwise they won't be enforced, and the "database" will be "corrupted" all the time +10:11 < damm> morimoto: this discussion is similar to someone wanting to cook a pancake and asks how to do it, but the answer is a swiss army knife. =) +10:12 < morimoto> pinchartl: tool has operation rules. like "status:" tag +10:12 < wsa> how urgent is all this? +10:12 < morimoto> ? sorry, what does your "operation rule" ? +10:12 < wsa> I am under the impression Morimoto-san may need the tool to create proper reports so we can be evaluated correctly +10:12 < wsa> but i may be wrong +10:13 < damm> wsa: i have my own tools to monitor upstream contribution rate for each group +10:13 < pinchartl> wsa: I think you're right, but it's not just the tool that's needed for that, it's also the data. reports can't be created before we all start using the tool and keep the data up to date +10:13 < morimoto> wsa: creating reports is option, not purpose +10:13 < wsa> ok +10:13 < wsa> that relieves me +10:13 < damm> and to avoid spending time unwisely i don't bother you with that unless things are not progressing as expected +10:14 < wsa> I have absolutely zero doubts in trusting Magnus and Laurent figuring out an awesome process... +10:14 < damm> it would be interesting to hear how shimoda-san and morimoto-san would like to receive information how to handle those BSP upporting lists +10:15 < wsa> ... yet they are both probably the busiest people we have? +10:15 < damm> are we in a rush somehow? +10:16 < wsa> that was my initial question. i thought so and I am happy I was wrong :) +10:16 < pinchartl> wsa: I think we're all busy. I agree however that I might be one of the people who sometimes has the hardest time setting priorities straight :) +10:16 < damm> pinchartl: it is good to see that someone cares +10:16 < damm> pinchartl: shall we take that process discussion elsewhere? +10:17 < pinchartl> and as we're all busy, if this new tools requires spending more time to keep data up to date, I'm pretty sure it won't happen. I don't see how it could be adopted unless it makes everybody's life easier +10:17 < pinchartl> damm: sure. on the mailing list ? or do you have another preference ? +10:18 < damm> pinchartl: lets use private email to schedule a video conference you and me +10:19 < pinchartl> is anyone else interested ? +10:20 < geertu> I'm interested in the outcome +10:20 < kbingham> perhaps in the outcome of discussions :) - and the list of features required +10:21 < pinchartl> alright +10:21 < pinchartl> damm: seems like we have a date then :-) +10:21 < damm> pinchartl: yay +10:22 < pinchartl> ok, let's do that +10:23 < wsa> damm: you have a second now to chat (IRC or Hangout)? +10:25 < pinchartl> damm: mail sent +10:26 * kbingham posts "PeriZilla" to "PeriPeri" and awaits to be laughed at +10:27 < pinchartl> damm: seems like our e-mails have crossed each other :) +10:29 < geertu> kbingham: is there a perl-bugzilla, too? +10:29 < kbingham> geertu, If not you could write one :D +10:29 * geertu notices the similarities between peri and perl +10:30 < uli_> geertu: bugzilla itself is written in perl; i'd be surprised if there weren't +10:30 < geertu> Are we finished with core? +10:30 < kbingham> geertu, https://devzing.com/blog/index.php/access-bugzilla-from-perl/ +10:30 < geertu> Any other topics to discuss? +10:34 < wsa> damm: you have a second now to chat (IRC or Hangout)? +10:34 < damm> wsa: hangouts pls +10:34 < pinchartl> geertu: not for me. I'm fine proceeding with multimedia +10:34 < geertu> OK. +10:36 < geertu> Thanks for joining, and have a nice continued day. diff --git a/wiki/Chat_log/20180809-io-chatlog b/wiki/Chat_log/20180809-io-chatlog new file mode 100644 index 0000000..56623bc --- /dev/null +++ b/wiki/Chat_log/20180809-io-chatlog @@ -0,0 +1,112 @@ +09:05 < wsa> so, let's start the IO meeting +09:06 < wsa> first collected updates, then questions +09:06 < wsa> Status updates +09:06 < wsa> ============== +09:06 < wsa> A - what have I done since last time +09:06 < wsa> ------------------------------------ +09:06 < wsa> Geert +09:06 < wsa> : fixed QEMU SCIF emulation with Linux v4.11-rc1+ and SCIF regressions due to +09:06 < wsa> RZ/A2 support. +09:06 < wsa> Kaneko-san +09:06 < wsa> : works on D3 MSIOF upporting. +09:06 < wsa> Marek +09:06 < wsa> : has revisited PCIe L0s/L1 handling on Gen3 in Linux. +09:06 < wsa> Niklas +09:06 < wsa> : sent a new version of the SCC error patches and first version of ES handling +09:06 < wsa> for SDHI. Also worked into SDHI tuning and sorted out more patches for +09:06 < wsa> upporting. +09:06 < wsa> Shimoda-san +09:06 < wsa> : fixed ep0 for USB3 UDC SuperSpeed and upported PWM support for r8a77990. +09:06 < wsa> Ulrich +09:06 < wsa> : tested QEMU SCIF FIFO timeout fix. +09:06 < wsa> Wolfram +09:06 < wsa> : upported more SATA patches and a reworked version of I2C REP_START generation, +09:06 < wsa> reviewed Niklas' various SDHI series, tested SDR104 on Gen3, discussed SDHI +09:06 < wsa> feedback from the HW team, focalized an upstream discussion about I2C transfers +09:06 < wsa> with disabled irq, and worked on a needed DMA safe buffer API update. +09:06 < wsa> B - what I want to do until next time +09:06 < wsa> ------------------------------------- +09:06 < wsa> Kaneko-san +09:06 < wsa> : wants to continue D3 MSIOF upporting. +09:06 < wsa> Niklas +09:06 < wsa> : wants to keep on upporting SDHI patches and act on the responses we got from +09:06 < wsa> the HW team. +09:06 < wsa> Shimoda-san +09:06 < wsa> : wants to ping HW team to get USB unknown things and modify USB2 PHY for E3 +09:06 < wsa> accordingly, and continue to learn KVM (and virtualization) with USB host. +09:06 < wsa> Simon +09:06 < wsa> : wants to revisit RAVB upporting candidates. +09:06 < wsa> Ulrich +09:06 < wsa> : wants to implement checks for other SCIF error flags. +09:06 < wsa> Wolfram +09:06 < wsa> : wants to upstream SDR104 on Gen3, finish the DMA safe buffer API, recheck +09:06 < wsa> the watchdog task mentioned by Shimoda-san, check Yamada-san's patches +09:06 < wsa> for SDHI, and reactivate the work on I2C core PM improvements. +09:06 < wsa> C - problems I currently have +09:06 < wsa> ----------------------------- +09:06 < wsa> Geert +09:06 < wsa> : mentions the SCIF driver is very fragile. +09:06 < wsa> Shimoda-san +09:06 < wsa> : is blocked on some USB tasks because of waiting for answers from the HW team. +09:06 < wsa> Topics +09:06 < wsa> ====== +09:06 < wsa> Holidays +09:06 < wsa> -------- +09:06 < wsa> The following people have holidays the next week. +09:06 < wsa> * Geert +09:06 < wsa> * Niklas +09:06 < wsa> * Shimoda-san +09:06 < wsa> * Simon +09:06 < wsa> Next meeting +09:06 < wsa> ============ +09:06 < wsa> 2018-08-23, 09:00 CEST, 16:00 JST +09:07 < wsa> please double check and ask if you have questions +09:07 < wsa> my questions: +09:07 < wsa> Marex: what does "revisited PCIe L0s/L1 handling" mean? did you get the errata docs now? +09:09 < Marex> wsa: nope, I didnt find any +09:09 < Marex> wsa: I poked the ML thread since I was getting nothing there either +09:09 < wsa> maybe it is an idea to ask the HW team about it? +09:10 < Marex> wsa: yes +09:10 < wsa> I have limited hopes we get useful information out of that mail thread in time +09:11 < Marex> wsa: pretty much ... the discussion went somewhat off-topic, but Bjorn seemed to be quite helpful, so I'll check with him on IRC too +09:12 < wsa> good idea, too +09:12 < wsa> thanks! +09:12 < Marex> np +09:13 < wsa> that's mainly it, I think +09:14 < wsa> not super much happening at the moment, because people are busy with other things (LTSI) or enjoy the summer +09:14 < Marex> wsa: the summer that's roasting everyone, yeah +09:15 < Marex> wsa: I was barely able to do anything in the last month or so due to the heat +09:15 < Marex> wsa: it's getting better now +09:16 < wsa> so, questions from your side? +09:16 < wsa> JapaPERI maybe? +09:17 < shimoda> nothing from my side +09:17 < wsa> one word about my SDR104 results: transfer rates on M3N are awesom, H3 ES2.0 are terrible :/ +09:17 < wsa> "awesome" +09:17 < Marex> wsa: SDR104 with SD card in the full-sized slots ? +09:17 < wsa> yes +09:18 < Marex> wsa: same exact card I presume ? +09:18 < wsa> yes +09:18 < wsa> M3N is > 60MB/s, H3 is ~10MB/s +09:18 < shimoda> it's depends on swiotlb? +09:19 < shimoda> M3N don't use swiotlb because it has 1GiB +09:19 < wsa> oh, that might be a pointer. Totally forgot about that... +09:19 < geertu> Sho it should improve when booted with mem=1G? +09:19 < shimoda> oh, i think H3 seems terrible too.. +09:20 < geertu> ... or when enabling the IOMMU? ;-) +09:20 < shimoda> geertu: yeah, but should be 768M instead of 1G because all soc reserves 128M +09:21 < shimoda> or 256M +09:21 < wsa> I will play with all that +09:21 < geertu> shimoda: right, thx! +09:21 < horms> wsa: I also noticed "awesome" on M3-N, fwiiw +09:22 < wsa> horms: I think I never had >60MB/s with any other board so far... +09:22 * geertu is always confused by awesome and awful +09:22 < horms> yeah, something like that for me too +09:23 < Marex> wsa: you can also always check how the card behaves in U-Boot on that platform, it supports sdr104 +09:24 < wsa> Marex: true +09:24 < horms> geertu: its like chotto vs chou. Sometimes they are the opposite, sometimes they are the same. For extra fun the latter is a homoniem +09:24 < wsa> although it is more how the board behaves ;) +09:25 < wsa> so, i think we are done? +09:25 < wsa> summer influences also the meeting time... +09:26 < wsa> geertu: shall we continue with core right away or have a short break? +09:27 < wsa> anyway, thanks for this meeting everyone! +09:27 < wsa> enjoy your time! diff --git a/wiki/Chat_log/20180809-mm-chatlog b/wiki/Chat_log/20180809-mm-chatlog new file mode 100644 index 0000000..7c9386d --- /dev/null +++ b/wiki/Chat_log/20180809-mm-chatlog @@ -0,0 +1,206 @@ +Multimedia-chat-meeting-2018-08-09 + +10:36 < pinchartl> welcome everybody to the multimedia meeting +10:37 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:37 < pinchartl> * Jacopo +10:37 < pinchartl> Since last meeting: +10:37 < pinchartl> - DU input clock selection improvement +10:37 < pinchartl> [PATCH 0/3] drm: rcar-du: Rework clock configuration +10:37 < pinchartl> - LVDS reset handling +10:37 < pinchartl> [PATCH] drm: rcar-du: lvds: Handle LVDS interface reset +10:37 < pinchartl> - MT9V11 driver merged: a few follow ups: +10:37 < pinchartl> [PATCH] media: i2c: mt9v111: Fix v4l2-ctrl error handling +10:37 < pinchartl> [PATCH] media: i2c: mt9v111: Add VIDEO_V4L2_SUBDEV_API dependency +10:37 < pinchartl> - Tested and reviewed new v4l2 notifier helpers on CEU and VIN +10:37 < pinchartl> [PATCH v6 00/17] media: imx: Switch to subdev notifiers +10:37 < pinchartl> - Misc reviews: +10:37 < pinchartl> [PATCH v6 0/3] drm/atmel-hlcdc: bus-width override support +10:37 < pinchartl> [PATCH 00/14] Add minimal DTS support for M3-N Starter Kit +10:37 < pinchartl> - periupport patches: +10:37 < pinchartl> [PATCH v2] v4.14: LVDS: Mark LVDS panel patches as optional du clock sources +10:37 < pinchartl> patches +10:37 < pinchartl> Until next meeting: +10:37 < pinchartl> - Follow DU clock rework +10:37 < pinchartl> - Ebisu VIN upstreaming +10:37 < pinchartl> - Start looking again to GMSL? +10:37 < pinchartl> - Sakari's v4l2-fwnode properties rework +10:37 < pinchartl> - Keep looking into display upstreaming (vga still to be clarified) +10:37 < pinchartl> Issues and Blockers: +10:37 < pinchartl> - Planning for September/October meetings conference still pending +10:37 < pinchartl> jmondi: any comment ? +10:38 < jmondi> not really +10:38 < jmondi> just catching up with backlog curently +10:38 < pinchartl> regarding conference planning, let's discuss that towards the end of the meeting +10:39 < pinchartl> * Kieran +10:39 < pinchartl> Since last meeting: +10:39 < pinchartl> - Reviewed/supported "[PATCH] v4l: vsp1: Fix deadlock in VSPDL DRM pipelines" +10:39 < pinchartl> - D3 DU/Interlaced investigations +10:39 < pinchartl> - Chasing GMSL. Need to rebase Sakari's VC work. +10:39 < pinchartl> - VSP1 1x1 pixel issue +10:39 < pinchartl> - DU/interlaced v6. Accepted by Maintainer at last \o/ +10:39 < pinchartl> - GMSL for-renesas driver pull request (finally) +10:39 < pinchartl> - GMSL v2 public posting (sans VC) +10:39 < pinchartl> - Documented ADV748x secondary addresses +10:39 < pinchartl> Until next meeting: +10:39 < pinchartl> - 4K support +10:39 < pinchartl> - DU/D3 interlaced restrictions +10:39 < pinchartl> Issues and blockers: None +10:39 < pinchartl> kbingham: you also mentioned two weeks ago that you would look at reposting the VSP pending patches series (partition algo & writeback) +10:39 < pinchartl> is that still planned ? +10:39 < kbingham> The need to rebase Sakari's VC work was wrong/removed. I posted GMSL without VC +10:40 < kbingham> Hrm ... I rebased writeback ... +10:40 < kbingham> I guess I haven't included it in my notes as I haven't posted it... +10:40 < pinchartl> should I add both to the todo list ? +10:41 < kbingham> Yup. +10:41 < pinchartl> thanks +10:41 < pinchartl> * Laurent +10:41 < pinchartl> Since last meeting: +10:41 < pinchartl> - Patch review +10:41 < pinchartl> - Got VSP interlaced support merged (DU will follow in v4.20) +10:41 < pinchartl> - Additional tasks preparation +10:41 < pinchartl> Until next meeting: +10:41 < pinchartl> - Patch review +10:41 < pinchartl> - D3/E3 DU LVDS PLL upstreaming +10:41 < pinchartl> - Get GMSL patches merged +10:41 < pinchartl> Issues and blockers: None +10:42 < pinchartl> any comment from anyone? +10:42 < jmondi> that's a big one, and I don't want to resume the process/periject discussion +10:43 < jmondi> but how would you prefer to receive periupport updates? patches are ok? do you handle that by yourself looking at patches sent to mailing list? +10:43 < pinchartl> jmondi: patches are best +10:44 < pinchartl> as that's easiest to handle for me +10:44 < jmondi> I sent a few updates to periupport not "for inclusion" but as a matter of keeping track of which BSP patches we were more or less working with +10:44 < pinchartl> otherwise I do it manually (but not very often) +10:44 < jmondi> I think there needs to be some work from your side too to apply those patches, I'm wondering how to minimize that +10:45 < jmondi> I feel like bulk updates do not work that well +10:45 < pinchartl> ideally we would update it in real time as soon as we get something merged upstream +10:46 < pinchartl> but in reality I don't think this will ever happen +10:46 < jmondi> I'm thinking for each BSP whose status changed, a single patch to periupport you can then squash, with a referce to the series/task that upports/obsolates them +10:46 * kbingham goes to check periupport du/interlaced lines :) +10:46 < pinchartl> same problem as filling timesheets really, how often is that done at the end of the week when we can't remember what we've done and have to dig up, knowing perfectly well it would be easier to do it in realtime ? +10:46 < jmondi> because we rarely have a 1 to 1 match +10:48 < pinchartl> I don't really see a good solution to this problem if we don't enforce updates through process and tooling +10:48 < pinchartl> so at the moment, bulk patches is likely the best I can hope for +10:49 < pinchartl> unless someone else has a better advice ? +10:50 < kbingham> chmod g+w periupport ? +10:50 < pinchartl> kbingham: we'll still need review, based on my experience with patches that Jacopo posted before +10:50 < jmondi> kbingham: I'm not sure we all should push to periupport +10:51 < jmondi> kbingham: in the last week I would have screwed up myself only a few times +10:51 < kbingham> Ok :) +10:52 < pinchartl> * Morimoto-san +10:52 < pinchartl> Since last meeting: +10:52 < pinchartl> - RSND multi DAI support +10:52 < pinchartl> Until next meeting: +10:52 < pinchartl> - Continue multi DAI support and post patches +10:52 < pinchartl> Issues and Blockers: None +10:52 < pinchartl> morimoto: any comment? +10:54 < pinchartl> seems not :) +10:54 < pinchartl> * Niklas +10:54 < pinchartl> Since last meeting: +10:54 < pinchartl> - [PATCH] rcar-csi2: update stream start for V3M +10:54 < pinchartl> - [PATCH] v4l2-ctl: add support for SUBDEV_{G_STD,S_STD,QUERYSTD} +10:54 < pinchartl> - Reviewed V3H VIN and CSI-2 patches. +10:54 < pinchartl> Until next meeting: +10:54 < pinchartl> - Finish last VC patch for adv748x use-case. +10:54 < pinchartl> - Post VC series. +10:54 < pinchartl> - Post held back VIN format patches. +10:54 < pinchartl> Issues and blockers: None +10:54 < pinchartl> neg: any comment ? I know you might be lurking :-) +10:55 < neg> no comment :-) +10:55 < pinchartl> :-) +10:55 < pinchartl> * Simon (Kaneko-san) +10:55 < pinchartl> Since last meeting: +10:55 < pinchartl> - D3 audio support upport +10:55 < pinchartl> Until next meeting: +10:55 < pinchartl> - Continue D3 audio support upport +10:55 < pinchartl> - Testing M3-N audio support +10:55 < pinchartl> Issues and blockers: None +10:55 < pinchartl> horms: any comment? +10:56 < horms> hi pinchartl +10:56 < morimoto> pinchartl: sorry for delay: no comment +10:56 < horms> The D3 audio backport looks good. We have access to a machine in Magnus's lab. And it has looback audio present. So that part can proceed. +10:56 < pinchartl> morimoto: no issue +10:56 < horms> s/D2/M3-N/ +10:57 < horms> I think upporting for M3-N can also proceed as I unblocked Kaneko-san regarding a BSP patch he couldn't locate +10:57 < horms> But going might be a bit slow due to holiday activities +10:57 < horms> No other comments :) +10:57 < pinchartl> no worries about that :) +10:57 < pinchartl> thanks +10:57 < pinchartl> * Ulrich +10:57 < pinchartl> Since last meeting: +10:57 < pinchartl> - Prototyping LVDS PLL support on D3 +10:57 < pinchartl> Until next meeting: +10:57 < pinchartl> - Finish prototyping LVDS PLL support on D3 +10:57 < pinchartl> Issues and blockers: None +10:57 < pinchartl> uli_: any comment ? +10:57 < uli_> nope +10:58 < pinchartl> I got a question though, do you think you will be able to post a functional prototype by the 15th ? +10:58 * geertu starts looking for all "remove before leaving on holidays" tags... +10:58 < uli_> i think so +10:58 < pinchartl> great, thanks +10:59 < pinchartl> Topic 2. Additional Multimedia Tasks for Q3 +10:59 < pinchartl> additional tasks are out now, you should all have received them +10:59 < pinchartl> please let me know if there's any issue +10:59 < pinchartl> Topic 3. Periperi Meetings +11:00 < pinchartl> it looks like all of us will go to Edinburgh +11:00 < pinchartl> and that the best day for a global meeting will be Friday the 26th +11:00 < pinchartl> is that correct ? +11:01 < morimoto> no topics yet ? +11:01 < pinchartl> morimoto: do you mean for the meeting agenda ? +11:01 < morimoto> yes +11:02 < pinchartl> I would personally like to discuss the development process and its relationship with periject. by the time of the conference I certainly hope we will bee able to reach a consensus +11:03 < pinchartl> and if we complete that topic earlier, then we'll have more time to discuss other topics :-) +11:03 < morimoto> OK, F2F is nice for it :) +11:03 < pinchartl> we can lock the room until we reach an agreement :-D +11:03 < wsa> morimoto: I am very glad to hear that you will come to ELCE! :D +11:04 < morimoto> hehe :) +11:04 < morimoto> I'm looking forward to see you guys again ! +11:04 < neg> wsa: are you OK with moving SDHI hacking day so it won't collide with the V4L2 meeting? +11:04 < wsa> someone else from JapaPERI coming? +11:05 < kbingham> I guess we aught to do a haggis and whisky evening while we're there :) +11:05 < Marex> neg: can I join the SDHI hacking day ? +11:05 < Marex> wsa: ^ +11:05 < morimoto> wsa: I and Ito-san maybe. No Magnus, No shimoda-san +11:06 < Marex> no morimoto no life (TM) ? +11:06 < wsa> morimoto: I see. Then you have to take Magnus place when boozing with Niklas :D +11:06 < Marex> morimoto: looking forward to seeing you again in the UK :) +11:06 < wsa> Marex: in general, sure yes, very welcome +11:06 < morimoto> Marex: you are correct :) +11:07 < morimoto> wsa: :) +11:07 < Marex> wsa: thanks ... I seem to be doing something with SDHI in U-Boot on my own and it seems you and neg are solving similar problems in Linux ... I think it makes sense to sync up +11:07 < wsa> not decided yet, if we do a full hacking day on saturday (but we won't have the flat anymore then), or spread it over the days (doesn't sound likely)... +11:07 < morimoto> Marex: me to +11:07 < wsa> Marex: makes perfect sense +11:08 < Marex> morimoto: :)) +11:08 < wsa> Marex: although some of the sync should happen before ELCE by mail ;) +11:08 < Marex> wsa: fine by me +11:08 < wsa> or we do the SDHI hacking in Dunbar at the coast :D +11:09 < wsa> at weekends +11:09 < pinchartl> do we have an agreement for the 26th then ? +11:09 < wsa> yes +11:09 < wsa> SDHI hacking involves less people, so let's move this around +11:09 < neg> works for me +11:09 < wsa> since everyone else has time on Friday for the "big" meeting +11:09 < horms> fewer people +11:10 < wsa> oh! +11:10 < pinchartl> on the multimedia side, I still want to organize a code camp +11:10 < pinchartl> KR and XDC have been mentioned before +11:10 < pinchartl> but I think LPC could be a better option +11:11 < Marex> pinchartl: who's going to LPC ? did you submit anything ? +11:12 < wsa> Marex: did you plan to stay the weekend after ELCE? +11:12 < pinchartl> I haven't submitted anything +11:12 < pinchartl> but I will go +11:12 < kbingham> I plan to go to LPC +11:13 < pinchartl> neg: so do you I think? +11:13 < pinchartl> jmondi: will you be there? +11:13 < pinchartl> uli_: how about you? +11:14 < uli_> not at lpc +11:15 < pinchartl> the plan would be to spend at least 3 days together +11:15 < pinchartl> so likely the week before or after the conference +11:16 < neg> If there is MM meeting at LPC I will go if not I stay home +11:17 < pinchartl> ok +11:17 < pinchartl> that's it for me for today. any other topic that we should discuss ? +11:18 * morimoto good timing for me. I need to go back to home soon +11:20 < morimoto> sorry, but I will quit +11:20 < morimoto> bye-bye, enjoy your summer vacation +11:21 < pinchartl> as there's no other topic let's adjourne this meeting +11:21 < pinchartl> thank you all for attending diff --git a/wiki/Chat_log/20180823-core-chatlog b/wiki/Chat_log/20180823-core-chatlog new file mode 100644 index 0000000..4be234b --- /dev/null +++ b/wiki/Chat_log/20180823-core-chatlog @@ -0,0 +1,390 @@ +Core-chat-meeting-2018-08-23 + +09:35 < geertu> Welcome to today's Core Group Meeting! +09:35 < geertu> Agenda: +09:35 < geertu> 1. Status Updates +09:35 < geertu> 2. Discussion Topics +09:35 < geertu> Topic 1. Status updates +09:35 < geertu> A) What have we done since last time: +09:35 < geertu> Kaneko-san upported M3-N CPUFreq upport. +09:35 < geertu> Marek worked on U-Boot (discussing PCI DT parsing, and Gen2 USB PHY) and +09:35 < geertu> Linux (PCIe link L0/L1 switching on Gen3). +09:35 < geertu> Morimoto-san worked on PeriJect and Ebisu-4D export (Laurent/Simon/Geert). +09:35 < geertu> Shimoda-san says the RVC test team will test the new LTSI v4.14 snapshot. +09:35 < geertu> Simon tested M3-N CPUFreq, and submitted backports for LTSI-4.14. +09:35 < geertu> Ulrich sent H3/M3-W cpuidle support. +09:35 < geertu> Geert tested Simon's 4.14.61-based backport. +09:36 < geertu> B) What we plan to do till next time: +09:36 < geertu> Marek will continue Linux PCIe L0/L1 switching and U-Boot PCI DT parsing +09:36 < geertu> discussions. +09:36 < geertu> Morimoto-san will continue PeriJect development and Ebisu-4D export +09:36 < geertu> (Magnus). +09:36 < geertu> Shimoda-san will check the new LTSI v4.14 snapshot test results from the +09:36 < geertu> RVC test team, and will pave the way forward for IPMMU. +09:36 < geertu> Simon will continue testing M3-N CPUFreq. +09:36 < geertu> Geert will continue QEMU GPIO virtualization, handle SYSC and PFC errata, +09:36 < geertu> and review LTSI submissions during the merge window. +09:38 < geertu> C) Problems we have currently: +09:38 < geertu> Marek needs feedback from HW team on the PCI L0/L1 switching. +09:38 < geertu> Anything I missed? +09:38 < Marex> shimoda: OK, email sent, please let me know if I can tweak it somehow to get useful feedback from the HW team soon :) +09:39 < geertu> Topic 2. Discussion Topics +09:39 < geertu> Anything to discuss? +09:40 < damm> memory auto detect! +09:40 < damm> how to proceed +09:40 < pinchartl> I'd like to discuss handling of BSP patches, in relation with periject +09:40 < pinchartl> damm: you can go first +09:41 < geertu> uli___: Any update? +09:41 < damm> thankssssssssssssssssssss +09:41 < uli___> not from me +09:41 < shimoda> Marex: Thank you for the email! by the way, what's your envirnoment? H3 ES1.x? +09:41 < damm> so whats the next step forward with the memory detection i wonder? +09:42 < Marex> shimoda: H3 ES2 +09:43 < shimoda> Marex: Thanks! +09:43 < geertu> Marex: You had some feedback from the generic U-Boot side? +09:43 < Marex> shimoda: the latest greatest is H3 ES3, right ? :) +09:43 < Marex> shimoda: you're welcome +09:43 < damm> i suppose this topic is related to ATF +09:43 < Marex> geertu: generic u-boot side of ... what ? +09:43 < geertu> memory detection +09:43 < Marex> geertu: oh that +09:43 < Marex> geertu: nope, nothing +09:44 < Marex> geertu: I can just implement the decoder for the ATF memory layout tables and put it in ... +09:44 < damm> we have no ATF code in upstream yet, right? +09:44 < shimoda> Marex: you're right :) +09:44 < damm> but i recall Marex doing some work somewhere +09:44 < Marex> damm: not yet, sorry +09:44 < Marex> damm: I upported the D3/V3M ATF to 1.0.22r2 (latest) +09:45 < Marex> damm: I didnt start feeding it upstream yet +09:45 < damm> to have at least one known working system with autodetection, perhaps we can upstream ATF support for one board/SoC and complete upstreaming of the u-boot portion too? +09:45 < Marex> damm: the U-Boot portion is easy I think +09:46 < Marex> damm: from what pinchartl told me, the ATF just puts memory layout tables in RAM, so U-Boot can parse that and fill linux DT with that information +09:46 < damm> i suppose we want something robust so in case ATF doesn't support memory detection we still have working upstream u-boot +09:47 < Marex> damm: fall back to small amount of memory that's always present ? +09:47 < damm> sure +09:47 < damm> i suppose we want to disconnect the upstreaming/upgrade path of u-boot from ATF +09:47 < geertu> Seems like there's also an H3ULCB with 8 GiB of RAM? +09:48 < Marex> damm: yes, those things should be separate +09:48 < damm> but starting with ATF must make sense so we don't implement code in u-boot that can't be merged +09:48 < Marex> damm: there should be a minimum version requirement for ATF on which U-Boot and Linux works fine, but that's about it +09:49 < Marex> damm: start with ATF how ? by patching it support passing some more sane memory info to the upper layers ? +09:50 < damm> i guess since everything is out of tree when it comes to ATF we don't want to make it more difficult than necessary to adopt upstream code +09:50 < damm> i would say upstreaming of ATF for one platform +09:50 < Marex> damm: sure +09:51 < damm> some basic minimal support level +09:51 < damm> and then add that auto-detection bit +09:51 < damm> that would make sense to me at least +09:51 < Marex> damm: the autodetection can be implemented with current ATF already, the question is whether that (those tables that ATF populates) can be considered an ABI +09:52 < damm> then we can handle features and other SoCs/board incrementally after that +09:52 < damm> out of tree ABIs are not exactly smelling good in my book +09:52 < Marex> damm: right +09:53 < damm> so shall we get Renesas to approve upstreaming of H3 ATF for instance? +09:53 < damm> would anyone including Marex and Uli be interested in that kind of work? +09:54 < geertu> damm: Yes please (for upstreaming) +09:54 < Marex> damm: I have upstreaming of the ATF for D3/V3M on my list I wrote in Japan +09:55 < damm> ok so lets check with Renesas about preferred platform out of D3/V3M/H3 +09:55 < damm> I suppose we can make use of memory autodetect on H3 mainly +09:55 < Marex> :-) +09:55 < damm> but hey, this is just an ordering problem really +09:56 < geertu> For H3/M3-W/M3-N, the memory is on the SiP (for M3-N that may not be true for production SoCs) +09:56 < geertu> Is there any ID on the SiP that can be read? +09:57 < damm> that would indeed be nice +09:57 < geertu> Which brings us to [PATCH 0/8] arm64: dts: renesas: Break out R-Car H3 and M3-W SiP"[PATCH 0/8] arm64: dts: renesas: Break out R-Car H3 and M3-W SiP" (https://www.spinics.net/lists/devicetree/msg173820.html) again ;-) +09:58 < geertu> No, we don't want _more_ DTS files to maintain... +09:58 < Marex> geertu: but if it's SiP, someone can populate pretty much random DRAM chip on it, right ? +09:58 < Marex> geertu: it's just a matter of soldering it on +09:59 < geertu> Marex: the same is true for boards with an SoC instead of an SiP +09:59 < geertu> Although soldering the SiP may be a tiny bit harder ;-) +10:00 < geertu> Anyway, we're deviating. +10:00 < geertu> So: +10:00 < geertu> 1) upstream ATF for one R-Car Gen3 SoCs +10:00 < geertu> 2) update ATF for memory auto-detected +10:00 < geertu> 3) update U-Boot for memory auto-detect +10:00 < geertu> Sounds good? +10:00 < damm> yeah perfect +10:00 < damm> thanks +10:01 < Marex> geertu: sounds good +10:01 < damm> oh one thing +10:01 < Marex> geertu: so we just need the approval for H3/M3x or get me a physical D3/V3M :-) +10:01 < damm> will uli simply hand over stuff to Marex then? +10:02 < uli___> i would prefer that +10:02 < damm> lets do that then +10:02 < shimoda> damm: about ATF upstreaming, does it need Renesas side help? or, we can upport from in-house code anyway? +10:02 < damm> shimoda: maybe q&a is needed +10:03 < damm> shimoda: but apart from that i don't expect much help is needed +10:03 < Marex> shimoda: I think the goal would be to move in-house code (after cleanup and maybe rewrite) to upstream ... and then there would be no more inhouse code :) +10:03 < damm> Marex: what do you think? +10:05 < shimoda> damm: i see... I heard BayLibre tried upstreaming ATF but they have many questions to Ito-san, but since Ito-san and renesas ATF team are very busy, so no progress now... ;) +10:05 < Marex> damm: I might have a few questions if there are registers which are not in the documentation or weird things happening, but in general from what I saw, not much help would be needed +10:05 < damm> so letting Marex use the in-house code as sample and then he can decide by himself how to handle upstreaming? +10:05 < damm> shimoda: maybe our friends at BL will be happy with some assistance then +10:05 < geertu> Any political conflict with BayLibre? +10:06 < damm> don't think so +10:06 < damm> so lets see how Marex will accelerate this activity =) +10:06 < geertu> Great! +10:07 < shimoda> damm: should I ask Ito-san about who is trying to upstream in BayLibre? +10:07 < geertu> Last(?) topic: BSP and periject? +10:07 < damm> shimoda: sure, and please ask about what target platform they focus on +10:07 < Marex> damm: can I get a go/no-go when you check with BayLibre and input on which SoC I should use for upstreaming (H3/M3x/D3/V3x) ? +10:08 < damm> sure +10:08 * pinchartl takees the microphone +10:08 < damm> will let you know +10:08 < Marex> damm: thanks, so in the meantime I'll keep haggling about the PCI +10:08 * geertu releases +10:08 < shimoda> damm: i got it +10:08 < pinchartl> I attended the "periperi process meeting yesterday" +10:08 < Marex> on both U-Boot and Linux front no less , sigh +10:08 < Marex> damm: thanks +10:08 < pinchartl> which turned out to be a discussion between Magnus and I :-) +10:09 < pinchartl> we spent two hours going around many topics +10:09 < morimoto> wow +10:09 < jmondi> I missed it was yesterday, my bad +10:09 < pinchartl> no worries +10:10 < pinchartl> we decided to segment the problem, as handling everything in one go would be a too large task +10:10 < pinchartl> so the topic I'd like to discuss today is handling of the BSP patches +10:10 < pinchartl> today's situation is as follows (in a very summarized form) +10:10 < morimoto> This is good timing, we got new upport list from BSP team +10:11 < pinchartl> we, the upstreaming team, work on the upstream kernel +10:11 < pinchartl> Renesas consumes the result of our work, through renesas-drivers, and creates BSPs +10:11 < pinchartl> there are several layers there, as not all kernel code is in the public BSP (I'm thinking about codec drivers for instance) +10:11 < pinchartl> and I'm sure there are customer trees as well +10:12 < pinchartl> but in a nutshell, we get a BSP +10:12 < damm> (or a bucket of mud as i referred to it) +10:12 < pinchartl> the BSP is the result of a process that takes the upstream kernel, identifies issues (bugs, performance problems, missing features...), and fixes those issues +10:13 < pinchartl> that process, internally, uses various means of bug tracking (including lots of excell spreadsheets from what I've been told), to which we have no access externally +10:13 < wsa> all Japanese, too, probably? +10:13 < neg> damm: :-) +10:14 < pinchartl> as an upstreaming team, we strive for feature completeness, stability and performances +10:14 < pinchartl> so it is of value to us to know about the issues that have been identified +10:14 < pinchartl> we have started efforts to implement automated tests ourselves to catch regressions and other problems +10:15 < pinchartl> but given that we are resource-constrained, we can't match for now all the testing effort done internally by Renesas +10:15 < pinchartl> and by Renesas' customers (I've been told that customers are the best source of bug reports) +10:15 < pinchartl> wsa: and yes, lots of information is in Japanese +10:15 < pinchartl> so that's the current situation +10:15 < pinchartl> now, where do we want to go ? +10:15 < pinchartl> *ideally* +10:16 < pinchartl> we should get access to a common issue tracker, with all the information available for all identified issues +10:16 < pinchartl> that's something I'd like to happen, but it's a very long term project +10:16 < pinchartl> we can't expect that in the short or mid term +10:17 < pinchartl> so today, our largest source of information about issues in the upstream kernel is the BSP +10:17 < pinchartl> as most BSP commits fix an issue (alleged or real) +10:18 < pinchartl> for that reason, Magnus and I agreed that we need to base our process to achieve feature completeness, stability and performances partly at least on the BSP commits +10:19 < pinchartl> furthermore, we are, at least partly, evaluated on how we reduce the delta between the BSP and upstream +10:19 < pinchartl> and thus on the amount of BSP code that we "upport" +10:19 < pinchartl> "upporting" here means either direct upporting, or development of equivalent fixes +10:19 < pinchartl> so it's often more about superseding the BSP commits than really uppporting them +10:20 < pinchartl> it's thus useful internally for Renesas, at least if my understanding is correct, to track how BSP commits are replaced +10:20 < pinchartl> we thus need a list of BSP commit, associated with a status, in order to track our progress +10:21 < pinchartl> both on our side, to make sure no BSP commit falls through the cracks, and on Renesas' side, to evaluate progress +10:21 < pinchartl> we have such a list, in a shared git tree +10:21 < pinchartl> but there's one issue that I haven't mentioned yet +10:21 < pinchartl> BSP commits come with very little information +10:21 < pinchartl> there's often no commit message +10:21 < pinchartl> and when there's a message, it's usually terse +10:22 < pinchartl> there's usually no information about which platforms are affected by the issue +10:22 < pinchartl> or how to reproduce it +10:22 < wsa> ^ that! +10:22 < pinchartl> or the userspace use cases +10:22 < pinchartl> we are thus often left in the dark +10:23 < pinchartl> and we randomly send e-mails to Morimoto-san, sometimes CC'ing the author of the BSP commit, asking for clarifications +10:23 < pinchartl> that's not a very efficient process +10:23 < pinchartl> as information gets lost somewhere in mailing list archives +10:23 < pinchartl> or in private e-mails +10:24 < pinchartl> so Magnus and I are proposing storing additional information in the database of BSP commits +10:24 < pinchartl> which would become, in a way, an interface with the BSP team +10:24 < pinchartl> when a new BSP is released, the BSP team will add commits to the database (they already do today) +10:25 < pinchartl> and our proposal is to add a way for the BSP team to add a description for each commit +10:25 < pinchartl> ideally that wouldn't be needed +10:25 < pinchartl> as all information we need should be in the commit messages +10:26 < pinchartl> but realistically that won't happen +10:26 < pinchartl> we should try to get there gradually, but things will never be perfect anyway +10:26 < pinchartl> so, the idea is to have, for each BSP commit, a status, and a description +10:26 < pinchartl> if we need more information we can just mark the commit as requiring information +10:27 < pinchartl> all that would still be stored in a git tree, as it is today +10:27 < pinchartl> and both us and the BSP team would have access to that tree +10:27 < pinchartl> we need to extend the storage format used today for the BSP commits +10:28 < pinchartl> and, on top of that, tools could also be developed +10:28 < pinchartl> as long as the storage format is defined, we could even have multiple tools, command-line-based, GUI, web-based, if someone has time to spend :-) +10:29 < geertu> Sounds good to me. thx! +10:29 < pinchartl> to conclude on the topic, what we'd like to agree on, is the data storage format, and the process to handle BSP commits +10:29 < kbingham> Another git-backed-information-storage tool I came across lately might be of interest on this topic: https://github.com/sit-fyi/sit +10:29 < pinchartl> (who adds them, who updates them, how, ...) +10:29 < pinchartl> now the mic is yours, we take questions :-) +10:30 < pinchartl> kbingham: thanks for the link +10:30 < damm> may i raise two points from my side? +10:31 < pinchartl> sure +10:31 < damm> thanks for sharing the details very well +10:31 < damm> i just wanted to mention two things +10:31 < damm> 1. we should remember that BSP is one source of issues +10:32 < damm> issues may come from a mailing list too for instance +10:32 < damm> 2. we will have multiple buckets in progress at any given time +10:32 < kbingham> Or issues /we/ find in our testing :) +10:32 < pinchartl> damm: regarding the first item +10:32 < pinchartl> sure +10:33 < pinchartl> we also get requests or bug reports by e-mail +10:33 < wsa> we also find bugs by ourselves :) +10:33 < pinchartl> (both e-mails from Renesas and from third-parties, in public or private e-mails) +10:33 < pinchartl> possibly on IRC +10:33 < damm> yeah, so no need to keep a too bsp-upport centric view +10:33 < pinchartl> and there are bugs we find ourselves, yes :-) +10:33 < pinchartl> so yesterday we also discussed the need to have an issue tracker +10:34 < pinchartl> which would be at a level just above the BSP commit tracker +10:34 < pinchartl> but that's a second step, I don't want to try and solve all problems in one go as I explained in the beginning +10:34 < damm> totall agree, thanks! +10:34 < pinchartl> tracking BSP commits is the low-hanging fruit in my opinion +10:34 < pinchartl> as we know it's useful and needed +10:34 < pinchartl> (both for us and Renesas) +10:35 < pinchartl> the information we need to track are limited, the workflow is simple +10:35 < pinchartl> so it can be implemented in a relatively simple way +10:35 < pinchartl> once we get there I'd like to move to issue tracking +10:35 < pinchartl> of course if someone has too much free time, we can work in parallel :-) +10:36 < jmondi> one question: instead of going in the "BSP -> issue tracker" direction, shouldn't it be smarter to setup an issue tracker and ask BSP to use it? so that it's there already for us to use if we have bugs to list too +10:36 < geertu> Public bug reports (email, irc) are usually fixed quicker, mostly because there's a direct link with the reporter, leading to more accurate bug information. +10:36 < jmondi> it would also force BSP to reason in terms of "issue -> patch series" not the other way around +10:36 < pinchartl> jmondi: that's a very good question +10:37 < pinchartl> and I think the answer is yes +10:37 < pinchartl> but I'm concerned about how to get there +10:37 < pinchartl> I'd like to tell the BSP team today that we'll stop taking BSP commit directly, and that they should file proper issue reports +10:37 < pinchartl> but I doubt they will +10:38 < pinchartl> my hope is that, but creating a BSP commit tracker that they feed as they do today +10:38 < wsa> I'd think our possibilty to "force" something onto the BSP team is limited +10:38 < jmondi> run a $BUGZILLA hosted by renesas? +10:38 < jmondi> I'm sure it might take a long time, but... +10:38 < wsa> I think we should aim for cooperation +10:38 < pinchartl> with an additional feature of having a description they can fill as well +10:38 < pinchartl> will let us push them to fill descriptions +10:38 < pinchartl> once they get used to that +10:38 < wsa> They probably have lots of other issues/people to deal with +10:39 < jmondi> wsa: as well as we do +10:39 < pinchartl> we could get better commit messages in the first place +10:39 < pinchartl> and it might be easier to ask them to transition from BSP commit tracking to issue tracking too +10:39 < pinchartl> maybe I'm too optimistic though +10:39 < jmondi> wsa: I just don't think it's efficient we go through the process "Oh look a series, who knows what it tries to solve" +10:39 < wsa> it isn't +10:39 < pinchartl> but the only way I see to get better information is to make it more painful for them when they don't provide the information :-) +10:40 < pinchartl> if a commit has no commit message, we just send it back, asking for information +10:40 < wsa> I could imagine a workshop +10:40 < jmondi> so if we spend a day trying to figure out what they meant to solve, they can spend 10 minutes creating issues, and linking there the series that tackle the issue +10:40 < pinchartl> if we always do that consistently and stop trying to guess what the commits do, they might get the message +10:40 < wsa> or any other way to give examples +10:41 < jmondi> sorry, I don't mean to be rude, but I don't get why we have to treat them as uncapable of adhering to a process +10:41 < pinchartl> our responsability will be to mark the BSP commits we supersede +10:41 < jmondi> what's hard in "if you want to have a commit usptreamed, open an issue" +10:41 < Marex> jmondi: the redmine running at osdr has a tracker plugin +10:41 < pinchartl> the BSP team's responsability will be to provide us with detailed information about the issues +10:42 < jmondi> pinchartl: yup +10:42 < wsa> is there a language barrier? +10:42 < pinchartl> jmondi: the hard part in "if you want to have a commit usptreamed, open an issue" is that *they* don't want to get commits upstreamed +10:42 < pinchartl> we do +10:42 < pinchartl> because we're asked to do so by Renesas +10:42 < jmondi> s/we/Renesas +10:42 < pinchartl> it's a case of left hand not talking to the right hand +10:42 < wsa> I see Shimoda-san and Morimoto-san translating a lot +10:43 < jmondi> fine, so that's an internal Renesas issues then :) +10:43 < pinchartl> as I understand it, we're part of an external feedback loop that goes through multiple teams internally +10:43 < jmondi> a team in Renesas wants BSP commits to be usptreamed, BSP doesn't care... that's an issue +10:44 < pinchartl> (I don't know exactly how it works internally of course) +10:44 < Marex> jmondi: big company, multiple departments with different management people and management strategies +10:44 < jmondi> I understand it's not an easy issue +10:44 < Marex> jmondi: some want FOO, others want BAR +10:44 < jmondi> :) +10:45 < damm> discussing with Renesas about how to improve the process must be a good thing +10:47 < pinchartl> so, time for a conclusion +10:47 < pinchartl> damm: will you do the honours ? :-) +10:47 < horms> <2c> It seems to me that this is primarily a process rather than a tooling issue. And a cross-team process issue at that. So I agree some sort of cross-team discussion would likely be valuable </2c> +10:48 * morimoto phew long English... +10:48 < morimoto> 1st, we can ask BSP team soemthing +10:48 < pinchartl> horms: agreed, it's a process discussion. we can then build tools on top of it, if desired +10:48 < morimoto> And from next BSP release, we are already requesting about BSP commit log +10:48 < morimoto> more clearly +10:48 < morimoto> It seems they want to some kind of "format" +10:48 < damm> i think i should have a q&a with the renesas folks using the chat log until next time if someone could include the chat log in the report +10:49 < morimoto> Many BSP team member are working, but they are beginner +10:49 < pinchartl> geertu: will you include this in the core meeting report ? +10:50 < morimoto> if we can show format, they can followcl +10:50 < morimoto> s/followcl/follow +10:50 < morimoto> I think it can 1st step ? +10:50 < geertu> pinchartl: Yes I will +10:50 < morimoto> And about database, how about our Redmine ? +10:51 < pinchartl> geertu: thanks +10:51 < morimoto> I know some member want to use "git" base database, but Redmine is tracking tool +10:51 < pinchartl> morimoto: redmine as an issue tracker is certainly an option we can consider +10:51 < morimoto> No new tool is needed. +10:52 * kbingham is only exploring git based tool options :) - no git requirement from me. +10:52 < morimoto> Now we are usign "wiki" feature only +10:52 < morimoto> it is "mottainai" +10:52 < pinchartl> I wonder if it's a good option to track BSP commits though, as it would mean that the BSP team would have to open a redmine ticket for every BSP commit (or sets of commits). do you think they could do that ? +10:52 < morimoto> I think we can't force them to focus it +10:53 < pinchartl> morimoto: thank you for the Japanese lesson of the day. I agree about the mottainai +10:53 < morimoto> They are busy guy +10:53 < pinchartl> I expect them to be busy, yes +10:53 < morimoto> pinchartl: Sorry, I don't know about English version of it +10:53 < geertu> The advantage of anything git-based over redmine is that it works offline. +10:53 < damm> and lacks a gui +10:53 < morimoto> Thus, me or Shimoda-san pick-up, and do something is possible +10:54 < pinchartl> (https://en.wikipedia.org/wiki/Mottainai) +10:55 < damm> you could consider utf8 mottainai compared to shift-jis +10:55 < shimoda> morimoto: Redmine can change the language by 個人設定 +10:56 < pinchartl> damm: https://upload.wikimedia.org/wikipedia/commons/b/ba/JIS_and_Shift-JIS_variants.svg +10:56 < morimoto> shimoda: I mean "mottainai" English, not "Redmine" :) +10:57 * geertu wonders what's the "R-Car Emotion Engine" (https://elinux.org/Emotion_Engine_SDK_Image_preparation_guide) +10:57 < shimoda> shimoda: oops, sorry :) +10:57 < jmondi> morimoto: you and shimoda-san are the ones taking the most burden from this, translating back and forth, asking question etc.. there's no way your team can agree on a process with BSP to mediate all upporting requests through redmine? +10:58 * kbingham clicks geertu's link and wonders who RKDM is... +10:58 < geertu> jmondi: Or rebase -i and add the info to the commits (excessive (sic) information under the "---" line?) +10:58 < jmondi> again, I think "forcing" them to reason through "issue first -> then patches" would make things a lot smoother +10:59 < pinchartl> geertu: we would lose commit IDs, I don't think that would be very usable in the end +10:59 < damm> pinchartl: that table is geek t-shirt material for sure +10:59 < pinchartl> if we could get back to the topic at hand :-) +10:59 < jmondi> geertu: they want fixed format and I feel like an issue request on redmine would force them to use a standard tool and not think about "formats" +10:59 < pinchartl> 1. do we want to replace the git BSP commit list with redmine ? +11:00 < pinchartl> 2.1. if so, who will create the redmine issues ? +11:00 < damm> i dont think so +11:00 < pinchartl> 2.2. if not, do we agree with the process that I have proposed ? +11:00 < pinchartl> I would personally answer no to the first question because I can't see a good answer for 2.1. +11:00 < damm> worth discussing perhaps, but in a different setting? +11:01 < morimoto> pinchartl: "git BSP commit list" = periupport ? +11:01 < pinchartl> damm: would you like to take this internally and report the result of the discussions in the next meeting ? (or possibly before) +11:02 < damm> sure +11:02 < Marex> geertu: probably some AI thing ? +11:02 < pinchartl> morimoto: yes, git BSP commit list = periupport, but with a different format to allow adding descriptions (including platforms, userspace context, use cases, ...) +11:02 -!- horms_ [~horms@penelope-musen.amstelveen.horms.nl] has joined #periperi +11:02 < geertu> pinchartl: Or store it in periject? +11:02 < morimoto> Ahh, OK +11:03 < wsa> i think the biggest difference between periupport and what you proposed is a clear "status" +11:03 < wsa> like "need info" +11:03 < morimoto> geertu: yeah agree. how about to use periject with such tag ? +11:03 < pinchartl> geertu: I want to agree on the process and interface with the BSP team (a.k.a. data format). tooling is a separate discussion, on top of this +11:03 < wsa> currently this is hidden in the free form text field and might be easy to miss +11:03 < geertu> pinchartl: Do you want to script redmine queries? +11:03 < pinchartl> wsa: yes, we need a status field, and at least a comment field +11:04 < pinchartl> (and possibly other fields such as platform, although that could possibly be included in the comment/description) +11:04 < wsa> so, a status field like, "worked on", "accepted", "rejected", "need info" etc would be a good addition IMO +11:05 -!- horms [~horms@ip4dab7138.direct-adsl.nl] has quit [Ping timeout: 252 seconds] +11:05 < pinchartl> depending on the result of the internal discussions, I'll try to propose a format +11:06 < pinchartl> can that be our conclusion for today ? +11:07 < damm> seems all good to me at least +11:07 < neg> I think the discussion have been real good and I agree with pinchartl. However I'm a bit unclear how this new periupport repo will be handeled by us, do the whole team push directly to it? +11:07 -!- horms_ [~horms@penelope-musen.amstelveen.horms.nl] has quit [Ping timeout: 265 seconds] +11:08 < pinchartl> neg: that's part of the process that needs to be defined. I think we should all be allowed to push, yes +11:08 -!- horms_ [~horms@penelope-musen.amstelveen.horms.nl] has joined #periperi +11:08 < kbingham> What ever the resulting solution - we /need/ to have global access to add comments etc. +11:08 < neg> I think maybe group leaders should be involved in changes somehow but sending patches on ML seems a bit of extra workload for them +11:09 < geertu> neg: Agreed +11:10 < jmondi> what about 'locking' the master branch and have group leaders cherry-picking from developers' branches? +11:10 * morimoto I will talk this topic with BSP team +11:10 < jmondi> I agree sending periupport patches is a bit of a waste, but I would like to make sure my udpates to the upport list are validated first.. I would have screwed up a few times already +11:11 < pinchartl> jmondi: think about a regular issue tracker for a minute, like jira for instance. imagine how it would be if you couldn't modify anything yourself and always had to go through someone else :-) +11:12 < jmondi> well, not always, updates to periupport happens weekly at the most to me +11:12 < pinchartl> and they should happen more frequently +11:13 < pinchartl> whenever you get a patch accepted upstream, the corresponding BSP commit(s) should be updated +11:13 < neg> I think we reached the point where we need to empolye a secretarial pool :-) +11:13 < jmondi> well, usually it takes me ~week to upport a series +11:13 < jmondi> neg: seconded +11:13 < pinchartl> anyway, I propose closing this topic to start the multimedia meeting. we're only an hour and 15 minutes late :-) +11:14 < jmondi> pinchartl: we're not -only- upporting, I hardly see me updating periupport daily +11:14 < jmondi> ok, sorry +11:14 < jmondi> I'll get back when the secretarial pool selection process topic is raised again +11:15 < pinchartl> geertu: anything else for the core group ? +11:15 < geertu> pinchartl: Don't think so. +11:16 < geertu> Thanks for joining, and have a nice continued day (and/or meeting)! diff --git a/wiki/Chat_log/20180823-io-chatlog b/wiki/Chat_log/20180823-io-chatlog new file mode 100644 index 0000000..27ee67a --- /dev/null +++ b/wiki/Chat_log/20180823-io-chatlog @@ -0,0 +1,117 @@ +09:04 < wsa> then, let's start and welcome to the IO meeting! +09:04 < horms> sorry for being late +09:05 < wsa> again, first the status update, then topics +09:05 < wsa> here they are: +09:05 < wsa> Status updates +09:05 < wsa> ============== +09:05 < wsa> A - what have I done since last time +09:05 < wsa> ------------------------------------ +09:05 < wsa> Geert +09:05 < wsa> : fixed SPI controllers using DT aliases +09:05 < wsa> Marek +09:05 < wsa> : discussed the PCIe link L0/L1 switching on Gen3 upstream and created inquiry for the HW +09:05 < wsa> team +09:05 < wsa> Shimoda-san +09:05 < wsa> : fixed a build error for the USB gadget and continued learning virtualization of USB +09:05 < wsa> Ulrich +09:05 < wsa> : sent I2C0/3/5 pin control for H3 and M3-W, reviewed new REP_START generation series from +09:05 < wsa> Wolfram, and worked on the SCIF task about checking other flags in sci_receive_chars +09:05 < wsa> Wolfram +09:05 < wsa> : picked up watchdog task mentioned by Shimoda-san, sketched a better I2C safe DMA buffer API, +09:05 < wsa> reviewed & tested Yamada-san's SDHI patches as well as SDHI patches from Sergei and Fabrizio, +09:05 < wsa> upstreamed SDR104 support for Gen3, planned ELCE and IO hackfest in Edinburgh and +09:05 < wsa> sent a SPDX patch series +09:05 < wsa> B - what I want to do until next time +09:05 < wsa> ------------------------------------- +09:05 < wsa> Geert +09:05 < wsa> : wants to get SCIF earlycon fixed in upstream handle SISTR.[TR]DREQ in MSIOF +09:05 < wsa> Kaneko-san +09:05 < wsa> : wants to continue D3 MSIOF upporting and start with E3 MSIOF upporting +09:05 < wsa> Marek +09:05 < wsa> : wants to continue with PCIe link L0/L1 switching on Gen3 +09:05 < wsa> Niklas +09:05 < wsa> : wants to handle response about SDHI mapping sg segment size and respin +09:05 < wsa> 4-tap HS400 tuning patch +09:05 < wsa> Shimoda-san +09:05 < wsa> : wants to ping the HW team for information about USB errata and create fixes based on that, +09:05 < wsa> experiment with KVM, and document his findings about USB virtualization on the wiki +09:05 < wsa> Simon +09:05 < wsa> : wants to revisit RAVB upporting candidates +09:05 < wsa> Wolfram +09:05 < wsa> : wants to finish watchdog task mentioned by Shimoda-san, finish the better I2C safe DMA +09:05 < wsa> buffer API, review next version of Yamada-san's SDHI patches and do I2C core PM +09:05 < wsa> improvements +09:05 < wsa> C - problems I currently have +09:05 < wsa> ----------------------------- +09:05 < wsa> Marek +09:05 < wsa> : also needs info from the HW team about PCIe L0/L1 handling +09:05 < wsa> Shimoda-san +09:05 < wsa> : is still blocked by HW team concerning USB tasks +09:05 < wsa> Wolfram +09:05 < wsa> : still has zero time for the QEMU task +09:05 < wsa> Topics +09:05 < wsa> ====== +09:05 < wsa> Next meeting +09:05 < wsa> ============ +09:05 < wsa> 2018-04-19, 09:00 CEST, 16:00 JST +09:05 < wsa> ehrm, the next meeting line is bogus, of course +09:06 -!- vaishali [~vaishali@116.75.86.10] has joined #periperi +09:07 < wsa> and the overall summary would probably be "vacation time" ;) +09:07 < wsa> Marex: glad to see the PCIe thread being so lively again! +09:08 < Marex> wsa: it's more of an IRC thing now +09:08 < Marex> (#linux-pci on oftc) +09:08 < wsa> horms: is the priority boost for this RAVB patch okay with you, or are you still stuck with LTSI? +09:08 < Marex> but the real question is, what is the controller doing when the transition to L1 is mid-way +09:08 < Marex> shimoda: ^ :) +09:09 < horms> wsa: should be fine if LTSI goes to plan +09:09 < Marex> wsa: I will need to rework the patch using IRQs to conserve as much power as possible when switching to L1 state, but still ... +09:09 < wsa> Marex: i think it is great that you reached the "real question" +09:10 < Marex> wsa: why does the controller not do the transition automatically ? is there an errata ? what is really happening to the 5.3.2.1 state machine point 6..8 ? where is it broken ? +09:10 < Marex> wsa: it's a start, yeah +09:11 < wsa> geertu: the BSP patches for MSIOF suspend/resume are not commented in periupport. Do you have an eye on those? +09:12 < geertu> wsa: I plan to test them, together with the other MSIOF work +09:12 < wsa> geertu: 3e1497927bdf76dcad93f928ba0e4bf8d34a23e0 and 18f856640582163b365babdf9ab69c9ef4e02d57 +09:12 < wsa> Good, thanks +09:13 < shimoda> Marex: I'll ask HW team about this PCIe things, but the person is the same as USB, so I don't think he replies soon... By the way, I'm not familiar about PCIe, so I'd like get a simple question for asking HW guys from you :) If simple, I think I can translate it to Japanese +09:15 < wsa> uli___: what about this series "serial: sh-sci: Use pm_runtime_get_sync()/put()"? Any reason to not continue it? +09:15 < Marex> shimoda: sure :) +09:16 < Marex> shimoda: maybe I can talk to him directly ? :) +09:16 < uli___> wsa: i honestly don't remember what that was about, i'll look into it :) +09:17 < wsa> Please do +09:17 < Marex> shimoda: but the question really is ... "what happens when the Gen3 PCIe controller receives PM_Enter_L1 DLLP from the PCI device?" +09:17 < shimoda> Marex: by the way, R-Car Gen3 supports PCIe spec Rev.2.0, not Rev.3.0 +09:17 < wsa> So, any questions from your side? +09:17 < wsa> I have one but we can do this last +09:18 < Marex> shimoda: From PCI EXPRESS BASE SPECIFICATION v3.0 , the Gen3 PCIe controller should send PM_Request_ACK . Does it ? +09:18 < Marex> shimoda: I think it does not, it needs to be forced to do so by setting this bit 31 in PMCTRL +09:19 < Marex> shimoda: I only have the newer version of the PCIe spec, 3.0, but the L0-L1 transition procedure is the same +09:19 < wsa> My question is about watchdog and clocks +09:20 < Marex> shimoda: the v3.0 of the spec covers PCIe 1.0,2.0,3.0, I just ignore the PCIe 3.0 specific extra parts +09:20 < wsa> if we don't have NOWAYOUT enabled, it does RuntimePM clock handling as our other drivers +09:20 < wsa> if NOWAYOUT is set, we want to enable it once and never disable it again +09:21 < wsa> I could skip pm_runtime_put on remove(), but isn't that kind of leaking? +09:22 < wsa> Is pm_runtime_forbid() better? Yet, it also increments the ref counter +09:22 < wsa> Any ideas on how to do that properly? +09:22 < Marex> shimoda: do those three questions above make it easier to inquire about the PCIe or shall I rephrase them ? +09:23 < geertu> pm_runtime_forbid() sounds like a good solution to me, also in wording (nowayout -> forbid) +09:23 < wsa> yet, there will also be no pm_runtime_allow to balance it +09:25 < wsa> ok, seems I will try pm_runtime_forbid and CC the rpm people +09:25 < geertu> Will it ever call pm_runtime_put() if WDOG_NO_WAY_OUT is set? +09:25 < geertu> watchdog_stop() returns -EBUSY +09:27 < wsa> 1004 if (watchdog_active(wdd) && +09:27 < wsa> 1005 test_bit(WDOG_STOP_ON_UNREGISTER, &wdd->status)) { +09:27 < wsa> 1006 watchdog_stop(wdd); +09:27 < wsa> 1007 } +09:28 < geertu> nowautout assumes it has been started (once), right? +09:28 < wsa> according to the docs, this will only trigger for !NOWAYOUT +09:29 < shimoda> Marex: I'm afraid but, would you send an email about your questions? So, it' easy to forward to HW guy :) +09:29 < Marex> shimoda: one moment please +09:29 < wsa> geertu: i don't think so, but need to check +09:31 < wsa> the problem I want to avoid is to increase the ref counter every time on rebind with NOWAYOUT enabled +09:31 < wsa> dunno if this is academic +09:31 < geertu> nowayout sounds mutually exclusive with unbind to me ;-) +09:32 < wsa> yes :) somehow +09:32 < geertu> Of course there's no way to enforce that in the driver framework (zero .remove callback?) +09:32 < wsa> nice idea! +09:33 < wsa> OK, maybe it is time now for the core meeting? +09:34 < wsa> Looks like it... thanks everyone! diff --git a/wiki/Chat_log/20180823-mm-chatlog b/wiki/Chat_log/20180823-mm-chatlog new file mode 100644 index 0000000..2372550 --- /dev/null +++ b/wiki/Chat_log/20180823-mm-chatlog @@ -0,0 +1,135 @@ +Multimedia-chat-meeting-2018-08-23 + +11:16 < pinchartl> welcome to the multimedia meeting! +11:16 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +11:16 < pinchartl> * Jacopo +11:16 < pinchartl> Since last meeting: +11:16 < pinchartl> - Ebisu HDMI and CVBS integration +11:16 < pinchartl> [RFT 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input +11:16 < pinchartl> - DU non DPLL channel clock selection +11:16 < pinchartl> [PATCH v2 0/2] drm: rcar-du: Rework clock configuration +11:16 < pinchartl> Tested Laurent's re-implementation +11:16 < pinchartl> - More DU work +11:16 < pinchartl> [PATCH 0/3] drm: rcar-du: A few cosmetic changes +11:16 < pinchartl> WIP: Handle ESCR/OTAR register according to new datasheet +11:16 < pinchartl> - soc_camera removal: more patches are coming from community +11:16 < pinchartl> review: [PATCH v1 0/5] [media] soc_camera: ov9640 switch to v4l2_async +11:16 < pinchartl> - Tested and reviewed Sakari's v4l2-fwnode rework on VIN and CEU +11:16 < pinchartl> Testing + review: [PATCH 00/21] V4L2 fwnode rework; support for default +11:16 < pinchartl> configuration +11:16 < pinchartl> - Autumn conference planning +11:16 < pinchartl> - Got a talk accepted at ELC-E +11:16 < pinchartl> Until next meeting: +11:16 < pinchartl> - Keep pushing on DU's patch upport +11:16 < pinchartl> - Finalize clock selection patch series +11:16 < pinchartl> - Finalize ESCR/OTAR handling +11:16 < pinchartl> - Finalize Ebisu HDMI and CVBS upstreaming and support Laurent for testing +11:16 < pinchartl> - I will have a few days off at the end of the month +11:16 < pinchartl> Issues and Blockers: None +11:16 < pinchartl> jmondi: any comment ? +11:17 < jmondi> yes +11:17 < jmondi> you have taken in your tree the non-DPLL channel clock selection patch +11:17 < jmondi> are we good then? +11:18 < pinchartl> I think so, yes. I'll move that to the done list +11:18 < pinchartl> (it's already there, so I'll just remove it from the "until next meeting" list) +11:18 < jmondi> you have taken the 'cosmetic' patche too, so, yeah! +11:19 < pinchartl> * Kieran +11:19 < pinchartl> Since last meeting: +11:19 < pinchartl> - Updated periupport list +11:19 < pinchartl> - RCar DU Interlaced restrictions +11:19 < pinchartl> - RCar DU 4K support +11:19 < pinchartl> - Updated GMSLv3 based on review comments +11:19 < pinchartl> - Organised ELCE attendance +11:19 < pinchartl> - VSP1 clamp for 1x1 +11:19 < pinchartl> Until next meeting: +11:19 < pinchartl> - More DU/VSP Cleanup work +11:19 < pinchartl> - Retest/examine partition algorithm limitation patch +11:19 < pinchartl> - Repost writeback prototype +11:19 < pinchartl> Issues and blockers: None +11:19 < pinchartl> Notes: +11:19 < pinchartl> - Will be on vacation from September 1st to the 14th +11:19 < pinchartl> kbingham: any comment ? +11:19 < kbingham> None currently. +11:20 < pinchartl> thanks +11:20 < pinchartl> * Laurent +11:20 < pinchartl> Since last meeting: +11:20 < pinchartl> - Patch review +11:20 < pinchartl> - Reworked DU clock configuration +11:20 < pinchartl> - D3/E3 DU LVDS PLL upstreaming +11:20 < pinchartl> - Reviewed GMSL patches +11:20 < pinchartl> - Worked with Niklas face-to-face for two days +11:20 < pinchartl> Until next meeting: +11:20 < pinchartl> - Patch review +11:20 < pinchartl> - D3/E3 DU LVDS PLL upstreaming +11:20 < pinchartl> - Get GMSL patches merged +11:20 < pinchartl> Issues and blockers: None +11:20 < pinchartl> I have no comment :-) +11:20 < pinchartl> * Morimoto-san +11:20 < pinchartl> Since last meeting: +11:20 < pinchartl> - RSND TDM expand mode upport +11:20 < pinchartl> - RSND Multi DAI support +11:20 < pinchartl> Until next meeting: +11:20 < pinchartl> - Continue multi DAI support and post patches +11:20 < pinchartl> Issues and Blockers: None +11:20 < pinchartl> morimoto: any comment ? +11:20 < morimoto> yes +11:20 < morimoto> but not this +11:21 < morimoto> please contine +11:21 < pinchartl> ok :-) +11:21 < pinchartl> * Niklas +11:21 < pinchartl> Since last meeting: +11:21 < pinchartl> - Extended multiplexed stream patch-set +11:21 < pinchartl> ADV7482 virtual channel can now be selected at runtime. +11:21 < pinchartl> - Shared office with Laurent for 2 days of work and meetings. +11:21 < pinchartl> Until next meeting: +11:21 < pinchartl> - Post multiplexed stream patch-set. +11:21 < pinchartl> - Post held back VIN format patches. +11:21 < pinchartl> Issues and blockers: +11:21 < pinchartl> - kbuild boot keeps finding small issues in the multiplexed stream patch-set +11:21 < pinchartl> This has delayed posting of the series. +11:21 < pinchartl> neg: any comment ? +11:21 < neg> No comment +11:22 < pinchartl> * Simon (Kaneko-san) +11:22 < pinchartl> Since last meeting: +11:22 < pinchartl> - D3 Audio upport +11:22 < pinchartl> Until next meeting: +11:22 < pinchartl> - Testing M3-N Audio support +11:22 < pinchartl> - E3 Audio upport +11:22 < pinchartl> Issues and blockers: None +11:22 < pinchartl> horms_: any comment ? +11:23 < pinchartl> * Ulrich +11:23 < pinchartl> Since last meeting: +11:23 < pinchartl> - Sent D3 HDMI prototype with LVDS PLL support +11:23 < pinchartl> Until next meeting: None +11:23 < pinchartl> Issues and blockers: None +11:23 < pinchartl> uli___: any comment ? +11:23 < uli___> nope +11:23 < pinchartl> any comment from anyone on the status check ? +11:24 < jmondi> pinchartl: will you need a D3 for testing then? +11:24 < jmondi> or can you do it with E3? +11:24 < neg> not on the status check but I'm interested if you plan to test jmondi VIN/CSI-2 patches +11:24 < jmondi> neg: ebisu patches? +11:25 < pinchartl> jmondi: I'll test primarily on E3, but testing on D3 would be useful too +11:25 < neg> jmondi: yes +11:25 < jmondi> pinchartl: let me know how can I help +11:25 < pinchartl> thanks +11:25 < pinchartl> neg: I will test Jacopo's patches, yes +11:25 < jmondi> neg: I would like to look into the CSI-2 E3 integration, the BSP patch is quite big +11:25 < neg> pinchartl: thanks +11:25 < jmondi> s/I would like to/I would like you to/ +11:26 < jmondi> makes quite a difference :) +11:26 < neg> jmondi: :-) +11:26 < neg> It's on my list of things to review but wanted to make sure someone was testing them as I feel bad about them going upstream without being tested +11:26 < pinchartl> morimoto: you said you have a comment, the mic is yours +11:27 < jmondi> neg: thanks ;) +11:28 < morimoto> pinchartl: thanks. but I found answer from your email +11:28 < morimoto> thus, all clear for me now +11:28 < pinchartl> ok :-) +11:28 < pinchartl> anything else from anyone ? +11:28 < neg> not from me, I'm happy +11:28 < jmondi> not from here +11:28 < morimoto> nothing from me, too +11:28 < pinchartl> alright, that's it for today then +11:28 < kbingham> all good here +11:29 < pinchartl> the next meeting will be two weeks from now, on September the 6th +11:29 < pinchartl> thank you all for attending, have a nice day and evening diff --git a/wiki/Chat_log/20180906-core-chatlog b/wiki/Chat_log/20180906-core-chatlog new file mode 100644 index 0000000..3b7adc7 --- /dev/null +++ b/wiki/Chat_log/20180906-core-chatlog @@ -0,0 +1,214 @@ +Core-chat-meeting-2018-09-06 + +09:37 < geertu> Welcome to Today's Core Group Meeting +09:38 < geertu> Agenda: +09:38 < geertu> 1. Status Updates +09:38 < geertu> 2. Discussion Topics +09:38 < Marex> shimoda: but I think this would be just a few transistors more and would make the software very happy +09:38 < Marex> shimoda: but maybe that's indeed it :) +09:38 < geertu> Marex: Changing software is easier than adding transistors ;-) +09:39 < geertu> Topic 1. Status updates +09:39 < Marex> shimoda: I'll keep you posted on the ATF news ASAP +09:39 < geertu> A) What have we done since last time: +09:39 < geertu> Kaneko-san got M3-N CPUFreq merged. +09:39 < geertu> Marek cleant up the TMU driver in U-Boot slightly. +09:39 < geertu> Morimoto-san worked on PeriJect and Ebisu-4D export (arrived at Simon/Geert). +09:39 < geertu> Niklas fixed the return type of dma_set_max_seg_size(). +09:39 < geertu> Shimoda-san says the Renesas Vietnam test team finished testing of the new +09:39 < geertu> LTSI v4.14 snapshot, and he submitted a patch to revise usb2 properties on +09:39 < geertu> R-Car Gen3. +09:39 < geertu> Geert reviewed the second socfpga and additional rcar-i2c submissions for +09:39 < geertu> LTSI, worked on defconfig updates, tested s2ram on Ebisu-4D (fails), sent +09:39 < geertu> his first clk and pfc pull requests for v4.20, and worked through his +09:39 < geertu> holiday backlog. +09:39 < geertu> B) What we plan to do till next time: +09:39 < geertu> Morimoto-san will ship Ebisu-4D to Magnus. +09:39 < geertu> Shimoda-san says the Renesas Vietnam test team will test 4.14-ltsi-rc1 when +09:39 < geertu> released. +09:39 < geertu> Geert will continue QEMU GPIO virtualization, handle SYSC and PFC errata, +09:39 < geertu> and test 4.14-ltsi-rc1 when released. +09:40 < geertu> C) Problems we have currently: +09:40 < geertu> Morimoto-san wants the team to start using periject from October, but +09:40 < geertu> Magnus/Laurent haven't accepted it yet. +09:40 < geertu> Niklas is looking for a solution to control the SDn/SDnH clocks properly. +09:40 < geertu> Greg is too busy with normal stable updates, but promised to release +09:40 < geertu> 4.14-ltsi-rc1 this week. +09:40 < geertu> --- +09:40 < geertu> Anything I missed? +09:41 < pinchartl> geertu: do you want to discuss the periject topic ? +09:41 < geertu> pinchartl: Yes ;-) But let's do the technical one first? +09:42 < geertu> Topic 2. Discussion Topics +09:42 < geertu> A) SDn/SDnH clocks +09:42 < pinchartl> geertu: sure, I just wanted to know whether I should prepare myself mentally :-) +09:42 < geertu> pinchartl: Fetch the booze ;-) +09:42 < horms> What are the LTSI-4.14 backporting implications of the patch that Shimoda-san posted? +09:42 < geertu> horms: Which patch? +09:43 < geertu> USB2 properties? +09:43 < horms> Yes +09:44 < horms> Reading the above for a second time, perhaps LTSI and the USB2 properties patch are only related by virtue of being handled by Shimoda-san +09:44 < wsa_> neg: you there? +09:45 < neg> wsa_: yes +09:45 < shimoda> geertu: horms: usb2 properties patche is for mainline first, not LTSI only +09:45 < shimoda> s/patche/patch/ +09:45 < horms> ok +09:45 < wsa_> neg: before I forget, HS400 on H3 ES1.0 is considered broken and we do not support it +09:45 < geertu> horms: USB2 properties come with DT binding updates, driver updates. +09:45 < wsa_> there should be a patch in the BSP for that, too +09:46 < neg> wsa_: OK good to know, will reduce the number of tests needed :-) +09:46 < horms> geertu: unerstood. I now recall the patches in question. I guess that means its not suitable for LTSI-4.14 at this point. But we can discuss if desired +09:46 < geertu> Some parts I don't fully grasp yet. And some additional clocks are not documented in the DT bindings? +09:46 < geertu> horms: Indeed. TBD when fully accepted. +09:46 < neg> wsa_: Then the clock issue only effects H3 ES2.0 and M3-W ES1.* +09:47 < wsa_> neg: right, the 4tap ones +09:47 < geertu> One issue is the SDnH clocks are referred nowhere. +09:47 < shimoda> horms: i agree this usb2 properties patch is not suitable for the LTSI +09:47 < geertu> Which is due to MSTP clocks being a single clock, while the "module stop" operation may apply to multiple clock signals provided to the module. +09:48 < shimoda> geertu: i posted https://patchwork.kernel.org/patch/10589889/ , but not enough? (especially host and phy?) +09:48 < wsa_> so, the problem with the SDHI clocks is that we want to request 200MHz for HS400 which needs different setting that 200MHz for SDR104 depending if we have a 4tap SoC or 8tap SoC, right? +09:50 < neg> wsa_: I have not looked at what setting SDR104 needs, but for HS400 on 4tap we need a different setting then on 8tap +09:50 < geertu> neg: 4tap or 8tap is a property of the SoC, not of the SDHI mode? +09:51 < geertu> shimoda: What about the added clocks to the ehci/ohci nodes? +09:51 < neg> geertu: yes 4tap = H3 ES1.* (broken no concern) ES2.0 and M3-W ES1.* +09:51 < wsa_> if you mean HS400 etc as "SDHI mode", then yes, it is a property of the SoC +09:51 < geertu> OK, so soc_device_match() can do? +09:52 < wsa_> neg: please take SDR104 into account as well, we need a complete solution +09:52 < geertu> I thought the clock settings depends on the HSx/SDRx mode, too, which the clock driver cannot lnow about. +09:52 < geertu> s/lnow/know/ +09:52 < neg> wsa_: will do +09:53 < wsa_> the 4tap need a different setting for 200MHz depending on SDR104 or HS400 +09:53 < wsa_> the BSP solves this by requesting 400MHz +09:53 < geertu> So the clock settings purely depend on (A) requested clock rate from SDHI driver and (B) SoC model and revision? +09:53 < wsa_> which looks as a workaround to me +09:54 < wsa_> clock rate, mode (SDR or HS), SoC revision +09:55 < wsa_> model & revision +09:55 < shimoda> geertu: for now, gen3 ehci/ohci is related to usb/usb-ehci.txt. But, should I add ehci-rcar for instance? Or, revise usb-ehci.txt somehow? +09:56 < geertu> wsa_: And the clock driver only knows clock rate and SoC revision, it doesn't know about SDR or HS, right? +09:56 < wsa_> yes +09:56 < wsa_> I wonder if exposing SDnH is the proper solution +09:57 < geertu> I was just going to ask about that... +09:57 < geertu> I don't fully understand the cpg_sd_div_table[] +09:57 < wsa_> Then, the driver can handle both clocks individually +09:57 < geertu> What's the physical clock difference between HS200 and HS400? +09:57 < wsa_> we need to take care of backward compatibility then +09:57 < Marex> geertu: SDR vs DDR +09:58 < wsa_> geertu: 0. It is DDR +09:58 < Marex> geertu: the bus runs at 200 MHz in both cases +09:58 < geertu> Marex: I mean the SDn and SDnH clock rates +09:59 < neg> for backward compability as SDnH is the parent of SDn can't we leave DT as is and have the driver get the parent of SDn (which it have access to today) and than control it's rate? +09:59 < Marex> geertu: they do differ, depends on SoC and revision, which is documented in the SDHI addendum +09:59 < geertu> shimoda: ehci/ohci DT bindings are very vague about clocks. I think adding an R-Car section may help. +09:59 < Marex> geertu: it's almost at the end of that document +10:00 < wsa_> neg: that might work. leaving dt as is would be much preferred +10:01 < geertu> Marex: Thx. So SDn=200 MHz, while SDnH=400 or 800 MHz +10:01 < wsa_> yup +10:02 < geertu> And the SD-IF module clock is based on SDn, while we could change that in the kernel to SDnH. +10:02 < shimoda> geertu: "adding an R-Car section" means into usb-ehci.txt? Or, as a new file? +10:02 < geertu> shimoda: Documentation/devicetree/bindings/usb/usb-ohci.txt and Documentation/devicetree/bindings/usb/usb-ehci.txt +10:03 < shimoda> geertu: Thanks! I'll add it. +10:04 < geertu> neg: You still need some heuristic to know if the Sdn divider is /2 or /4, right? +10:05 < neg> geertu: not following you +10:05 < geertu> Is there some table available listening all modes and according clocks rates? +10:06 < geertu> neg: If the driver request SDnH = 800 Mhz, it should program SDn to SDnH / 4 +10:06 < geertu> neg: If the driver request SDnH = 400 Mhz, it should program SDn to SDnH / 2 +10:07 < neg> geertu: yes, but if we expose SDnH as the parent clock of SDn the driver can control them both "independently" right? +10:07 < geertu> driver = clock driver or sdhi driver? +10:07 < neg> driver = sdhi +10:08 < neg> geertu: so first setting SDnH=800Mhz or 400Mhz and then SDn = 200Mhz would do the "right" thing? +10:08 < geertu> If the sdhi driver needs to see both, you have to update DT +10:08 < geertu> which may not be that unlogical ;-) +10:08 < neg> geertu: why can't I in the sdhi driver get the parent clock of SDn which is described in DT today? +10:10 < geertu> neg: DT describes SD-IFn, it's parent is SDn +10:11 < neg> geertu: ahh +10:11 < geertu> SDn's parent is SDSRC 9currently). +10:11 < geertu> You want to change that to SDSRC -> SDnH -> SDn -> SD-IFn. +10:12 < geertu> So the sdhi driver would get the parent of the parent of its clock, and modify that? +10:13 < neg> it would work but don't feel right :-) +10:13 < geertu> That's doable (clk_get_parent), but we need to modify all clock drivers at once. +10:13 < geertu> Exactly. +10:13 < wsa_> isn't SDnH derived from SDSRC as well? (don't have a datasheet handy at the moment) +10:13 < geertu> What about adding the SDnH clock to the clocks property of the SDHI nodes? +10:14 < wsa_> we could make HS400 dependent on the availability of this second clock +10:14 < wsa_> we haven't enabled it yet, so no regressions +10:14 < geertu> Yes, both are derived from SDSRC +10:14 < geertu> Exactly my thought. +10:15 < geertu> SDSRC -> 1/{1,2,4,8,16} -> SDnH -> 1/{2,4} -> SDn +10:15 < geertu> And we model (in the clock driver) SDn -> SD-IF +10:16 < geertu> Alternatively, we can model (in the clock driver) SDnH -> SD-IF, and use a heuristic (in the clock driver) to set the rate of SDn based on SDnH +10:16 < geertu> But before we do that, I'd like to see the full table of all modes and clock rates. +10:17 < geertu> What about impact on Gen2? +10:18 * geertu realizes we're running into the MM meeting time (and pinchartl is trembling) +10:18 < wsa_> Gen2 has no HS400 +10:18 < wsa_> it has SDR104, though +10:18 < geertu> But it does have SDnH, which we don't model. +10:19 < pinchartl> geertu: if we want to discuss periject, that's core time ;-) +10:19 < pinchartl> (I'm not requesting that topic to be discussed, I was just enquiring) +10:19 < neg> seems like SDH and SDn have fixed freq on Gen2, but I just looked at the blockdiagram +10:21 < neg> To not spend anymore time on this topic it seems we have concensus that SDnH should be exposed on Gen3? So that will be the first step and I'm happy to have a direction for now :-) +10:22 < geertu> neg: Not according to SDCKCR, which controls SDH, SD0, and SD1 +10:22 < geertu> Ugh, they share SDH for SD0 and SD1 on H2 +10:22 < geertu> Let's move on to +10:23 < geertu> B) Periject +10:23 < wsa_> neg: yes, i think that direction looks worthwhile +10:25 < geertu> Do we have (silent) Magnus in the house? +10:25 < damm> yep +10:26 < pinchartl> mostly silent Laurent is here too +10:26 < pinchartl> damm: have you had a chance to discuss the process internally with Renesas ? +10:26 < geertu> Let's start speaking up ;-) +10:26 < damm> nope, i thought you wanted to finalize stuff internally first =) +10:27 < damm> in general i like your approach last meeting, but there were some loose ends i think +10:27 < damm> jacopo had some ideas +10:28 < pinchartl> damm: +10:28 < pinchartl> 11:05 < pinchartl> depending on the result of the internal discussions, I'll try to propose a format +10:28 < pinchartl> 11:06 < pinchartl> can that be our conclusion for today ? +10:28 < pinchartl> (from last meeting) +10:28 < pinchartl> 11:07 < damm> seems all good to me at least +10:28 < pinchartl> 11:01 < pinchartl> damm: would you like to take this internally and report the result of the discussions in the next meeting ? (or possibly before) +10:28 < pinchartl> (out of order, sorry) +10:28 < pinchartl> I thought internally meant inside Renesas +10:28 < damm> then we have a misunderstanding =) +10:28 < damm> i thought you were going to go over it once internally in our group =) +10:29 < pinchartl> 10:48 < damm> i think i should have a q&a with the renesas folks using the chat log until next time if someone could include the chat log in the report +10:29 < pinchartl> that's what I meant by internally -_-' +10:29 < damm> ok sorry, i have not done that +10:29 < damm> gotcha +10:29 < pinchartl> if we both wait for each other, lack of progress isn't surprising :-) +10:29 < damm> so no update from me, but i'll add it to my calendar +10:29 < damm> what's the plan with the opinion from jacopo? +10:29 < pinchartl> thanks +10:30 < pinchartl> which opinion ? +10:31 < damm> i recall he voiced his opinion (some ideas about the process) but we ran out of time +10:31 < damm> did you hear anything from him? +10:32 < damm> i did not. if neither one of us heard anything more then lets igore it to keep things simple +10:32 < pinchartl> I haven't +10:32 < pinchartl> jmondi: do you remember what your opinion was ? :-) +10:32 < jmondi> pinchartl: sort of :) +10:33 < jmondi> I basically asked for BSP to use $TOOL to clearly describe issues/features they try to solve, and then consider the patch series +10:33 < jmondi> not the other way around... +10:34 < jmondi> but there was quite a bit of push back, because BSP team do not want this burden, because, well, they do not care much about upstreaming +10:34 < jmondi> that's it +10:36 < pinchartl> I do agree that we need more information from the BSP team in many cases as commit messages are very terse +10:39 < pinchartl> that seems to be it for today ? +10:39 < damm> ok, so can we proceed with the process as-is as described by laurent? +10:39 < pinchartl> no issue on my side +10:39 < damm> i will check with renesas side and get back to you next meeting +10:39 < pinchartl> (I fortunately agree with my own proposal :-)) +10:40 < damm> hehe +10:40 < pinchartl> damm: would you have time for a quick HO discussion after this meeting ? +10:40 < jmondi> damm: me too +10:40 < jmondi> :) +10:41 < wsa_> HO? +10:41 < damm> sure, just connect to me +10:41 < pinchartl> HO=hangout +10:42 < geertu> wsa_: https://www.urbandictionary.com/tags.php?tag=ho +10:42 < pinchartl> geertu: the mic is now yours to finish the core meeting +10:43 < geertu> Thanks ;-) +10:43 < geertu> Next meeting date? Will there be new contracts? +10:43 < ldts> Marex: https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/porting-guide.rst#extternal-abort-handling-and-ras-support +10:44 < geertu> I propose September 20th +10:44 < pinchartl> sounds good to m +10:44 < pinchartl> e +10:44 < wsa_> ack +10:45 < horms> Likewise +10:46 < neg> I also think new contracts sounds good :-) +10:47 < damm> fine here too of course +10:48 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20180906-io-chatlog b/wiki/Chat_log/20180906-io-chatlog new file mode 100644 index 0000000..5c0263c --- /dev/null +++ b/wiki/Chat_log/20180906-io-chatlog @@ -0,0 +1,145 @@ +09:06 < wsa_> ok, let's start the IO meeting +09:06 < Marex> morimoto: I hope even the quake tonight was OK for you all ? +09:06 < shimoda> wsa_: Near tokyo area is OK. But, today I'm supprized Hokkaido had a big earthquake +09:06 < ldts> hi horms morimoto , nice to meet you too +09:06 < Marex> shimoda: 6 upper :( +09:06 < morimoto> Marex: thanks. Yeah, arround +09:07 < morimoto> arround tokyo is OK +09:07 < wsa_> oh, wow. 6 upper is a lot! +09:07 < shimoda> Marex: Yes :( my mother and my brother's family live in there, but all they are OK now +09:07 < horms> I'm glad to hear that +09:07 < Marex> shimoda: whew, glad to hear that +09:07 < wsa_> really glad to hear that! +09:08 < shimoda> horms: Marex: wsa_: Thanks! +09:08 < morimoto> Thank you guys ! +09:08 < wsa_> sure thing +09:09 < wsa_> with the good news in place, let's get back to our duty here +09:09 < wsa_> status updates: +09:09 < wsa_> A - what have I done since last time +09:09 < wsa_> ------------------------------------ +09:09 < wsa_> Geert +09:09 < wsa_> : fixed earlycon with SCIF, enabled MSIOF on R-Car E3/Ebisu, upported MSIOF +09:09 < wsa_> suspend/resume and reserved register bit patches, and fixed QSPI interruption +09:09 < wsa_> and suspend/resume bugs. +09:09 < wsa_> Kaneko-san +09:09 < wsa_> : did D3 and E3 MSIOF upporting +09:09 < wsa_> Marek +09:09 < wsa_> : retrieved more information about the PCIe L0/L1 transition handling +09:09 < wsa_> Niklas +09:09 < wsa_> : got SDHI SCC error patches merged, sent patches for DMA max_segment size, +09:09 < wsa_> worked on HS400 clocks differences on various H3 ES, tested SDIO on Koelsch. +09:09 < wsa_> Shimoda-san +09:09 < wsa_> : sent out reset_control and multiple clock to USBHS, designed USB2.0 (host and +09:09 < wsa_> peripheral) support for R-Car E3/D3, and investigated the eMMC suspend issue +09:09 < wsa_> Simon +09:09 < wsa_> : reviewed BSP RAVB patches +09:09 < wsa_> Ulrich +09:09 < wsa_> : resent "spi: sh-msiof: Document R-Car D3 support" +09:09 < wsa_> Wolfram +09:09 < wsa_> : worked on proper watchdog handling when removing the driver, implemented a +09:09 < wsa_> better I2C safe DMA buffer API, reviewed various versions of SDHI patches by +09:09 < wsa_> Niklas and Yamada-san, tried to reproduce SDHI suspend problems with mounted +09:09 < wsa_> filesystems on eMMC, discussed and sent RFC for I2C core regarding irqless +09:09 < wsa_> transfers at shutdown timeand did some SPDX updates +09:09 < wsa_> B - what I want to do until next time +09:09 < wsa_> ------------------------------------- +09:09 < wsa_> Kaneko-san +09:09 < wsa_> : wants to address review comments of previous patches +09:09 < wsa_> Marek +09:09 < wsa_> : wants to check if changing the ATF can support Linux to handle the PCIe L0/L1 +09:09 < wsa_> transition +09:09 < wsa_> Niklas +09:09 < wsa_> : wants to work on a solution to 4-tap clock issue. +09:09 < wsa_> Shimoda-san +09:09 < wsa_> : wants to continue with the USBHS patches, the E3/D3 USB integration, the eMMC +09:09 < wsa_> susped issue investigation, enable KVM on arm64 and update the elinux wiki about +09:09 < wsa_> QEMU + USB +09:09 < wsa_> Simon +09:09 < wsa_> : wants to revisit RAVB patch to avoid writing to reserved bits +09:09 < wsa_> Ulrich +09:09 < wsa_> : wants to send next version of "I2C0/3/5 pin control for H3 and M3-W" +09:09 < wsa_> Wolfram +09:09 < wsa_> : wants to reproduce SDHI eMMC suspend problems, implement generic helpers for DMA +09:09 < wsa_> properties, keep the 'I2C irqless transfers' development going, work on I2C core +09:09 < wsa_> PM improvements +09:09 < wsa_> C - problems I currently have +09:09 < wsa_> ----------------------------- +09:09 < wsa_> Wolfram +09:09 < wsa_> : couldn't reproduce the eMMC suspend issue yet +09:10 < wsa_> so, we have this interesting update to the eMMC problem that it might be fixed upstream already +09:10 -!- damm [~damm@l193216.ppp.asahi-net.or.jp] has joined #periperi +09:10 < wsa_> and we need to identify the good commit(s) +09:11 < wsa_> Marex: thanks for your work in tackling the PCIE L0/L1 issue +09:11 < wsa_> Marex: if you want something easy for a change, there is a super-simple E3 enablement patch in the BSP still to upport ;) +09:12 < Marex> wsa_: oh ? +09:12 < Marex> wsa_: let me guess, 32bit PCI limitation ? +09:12 < wsa_> d38d4fc29e8cd71b2173443df9c057bea37624b6 +09:12 < Marex> wsa_: I spent quite a bit pestering lorenzo and catalin about this L0/L1 stuff, ultimatelly, we think there might juuust be a way to work around it in ATF +09:13 < Marex> wsa_: but that's a thing to research in the upcoming week-ish +09:13 < wsa_> As I understand it, the HW is not doing it right, or? Might be worth some feedback to the HW team? +09:13 < Marex> wsa_: since it's a transient fault, it might just make sense to trap the SError in ATF and restart the instruction +09:14 < geertu> Marex: So the issue happens when the arm64 core accesses the PCIe bus while a device sent a link status change? +09:14 < Marex> wsa_: what happens is that <someone> may start transitioning the PCIe device to lower power state (think D3hot for simplicity) ... at one point, the device sends PM_Enter_L1 DLLP to the controller +09:15 < geertu> And that's where "restart the instruction" comes into the picture? +09:15 < Marex> that one triggers automatic PLL shutdown in the PCIe controller, but does not completely transition the link to L1 state from the PCIe controller side +09:15 < Marex> at that point, you cannot trigger config accesses to the card anymore, it will trigger those SErrors +09:15 < Marex> the software must at that point poke the controller PMCTRL register bit to finish the transition to L1 state +09:16 < Marex> once that happens, everything is great again and you can do config accesses ; the config access will recover the link to L0 state etc etc +09:17 < Marex> the problem is, IFF ie. a user decides to send config access with ie. setpci just at the right (or wrong?) time between the controller receiving PM_Enter_L1 DLLP from the card and the PMCTRL poke, the system crashes with unhandled SError +09:17 < Marex> and I think it might just be possible to trap that SError in ATF and restart the instruction which caused it (it's a single register write, so that should be fine) +09:17 < geertu> Thanks for explaining. I was always wondering where the instruction restart fit in the picture. +09:18 < geertu> As long as it's not an imprecise external abort, you're fine ;-) +09:18 < Marex> now there's another funky thing, but that's probably kinda ... hypothetical +09:18 < Marex> IFF someone does config access from an interrupt handler , the CPU gets async SError and that's sort of the end +09:19 < wsa_> horms: when could you start working on the 4byte RAVB alignment patch? I think ASAP would be cool, before LTSI becomes super big again? Does that make sense? +09:19 < Marex> geertu: the async serror is a problem too ^ +09:19 < Marex> geertu: I still need to verify if this cannot happen outside of interrupt context somehow too +09:19 < horms> wsa_: ASAP is fine :) +09:19 < wsa_> horms: great! +09:20 < wsa_> Marex: do the HW guys know the controller should do the L1 link properly on PLL shutdown? +09:20 < wsa_> is it a known errata? +09:20 < geertu> wsa_: Doesn't commit d38d4fc29e8cd71b ("PCI: rcar: Add compatible string for r8a77990") need actual testing? E.g. Magnus inserts PCIe card in Ebisu, and Marex dooms it? +09:21 < Marex> wsa_: it should do it automatically, I don't know why they decided to require this register poke +09:21 < shimoda> Marex: I'm not sure but, can we avoid to send PM_Enter_L1 DLLP from the card somehow? +09:21 < wsa_> Marex: that's what we need to discuss IMHO +09:21 < Marex> shimoda: I was thinking about the same, but the user can just use setpci to bypass it +09:22 < Marex> shimoda: user can use setpci to set PM_CAP+4 register on the card or maybe some other funny register which is implementation defined by the card and that'd be it +09:23 < Marex> wsa_: that's what needs to be fixed in the next generation of hardware I think +09:23 < wsa_> Marex: I agree. That's why I want to make sure HW people are aware there is a problem +09:23 < Marex> geertu: my question would rather be, why do we need another compatible which is not in the compat table of the controller driver ? Is the PCIe different on ebisu somehow ? maybe like the i2c ? +09:24 < wsa_> it is just for DTS verification +09:24 < Marex> wsa_: it's probably better to explicitly state it one more time then +09:24 < geertu> Marex: We don't know. We may find out only later, so that's why we need the SoC-specific compaible values. +09:25 < Marex> wsa_: but then. aren't we missing also 77980 and 77970 entries ? +09:25 < wsa_> we want specific compatibles before the generic fallbacks just in case +09:25 < wsa_> Marex: you can add them if you want +09:25 < Marex> jupp, fine +09:25 < wsa_> but usually, those SoCs are upstreamed by Cogent +09:26 < Marex> shimoda: so do you think the HW team would be willing to fix this L1 transition issue in next HW cycle ? +09:27 < Marex> shimoda: or could they maybe add a bit which says "do L1 transition automatically and if someone does config access during transition, stall the bus until transition completes" ? +09:27 < wsa_> geertu: shall I update the MSIOF entries in periupport, or can you do it when you update core items? +09:28 < Marex> wsa_: OK, the patch ^ is picked +09:28 < geertu> wsa_: I will update them with the proper commit ID (broonie is fast) +09:28 < shimoda> Marex: I don't know. But, I should ask them for next hw. +09:29 < wsa_> geertu: thanks! +09:29 < wsa_> are there any questions from your side? +09:29 < wsa_> I'd guess neg's question about SDHI clocks could also be discussed in the core meeting? +09:30 < geertu> yes +09:31 < horms> I'd like to ask about coordinating / requests for upporting tasks for Kaneko-san. +09:32 < horms> But perhaps that is best done in Core or elsewhere +09:32 < wsa_> uli___: any news on the SCIF suspend/resume patches? +09:32 < geertu> horms: Sorry for stepping on Kaneko-san's toes. +09:32 < Marex> shimoda: yes please ! :) +09:32 < geertu> But MSIOF is something you need to test with HW access. +09:33 < horms> It happens, don't worry about it +09:33 < uli___> wsa_: no, not yet +09:34 < wsa_> uli___: any specific problems with it? or just too many tasks? +09:34 < geertu> horms: Does Kaneko-san has access to periupport? +09:34 < Marex> shimoda: I still have to wonder why they decided to insert this bit into PMCTRL and effectivelly stall the L1 enter state machine, all the controllers I know just do the transition fully automatically +09:34 < uli___> wsa_: stuff unrelated to work lowered my productivity severely... +09:34 < geertu> horms: "arm64: dts: r8a77995-draak: Add MSIOF ch2 pins support" is marked "Proposing 'N': MSIOF2 is unused on the Draak board"? +09:35 < wsa_> uli___: oh, didn't know that. Hope things go well for you soon again! +09:36 < horms> geertu: thanks, somehow I missed that +09:37 < wsa_> ok, seems we can transition to core group now... +09:37 < wsa_> geertu: here is the mic +09:37 < wsa_> thank you everyone for this meeting diff --git a/wiki/Chat_log/20180906-mm-chatlog b/wiki/Chat_log/20180906-mm-chatlog new file mode 100644 index 0000000..c605107 --- /dev/null +++ b/wiki/Chat_log/20180906-mm-chatlog @@ -0,0 +1,98 @@ +Multimedia-chat-meeting-2018-09-06 + +10:48 < pinchartl> welcome to the multimedia meeting +10:48 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:49 < pinchartl> * Jacopo +10:49 < pinchartl> Since last meeting: +10:49 < pinchartl> - Upported a few DU patches +10:49 < pinchartl> [PATCH 0/4] drm: rcar-du: Update to SoC manual revision 1.00 +10:49 < pinchartl> - Ebisu HDMI/CVBS support v2 +10:49 < pinchartl> [PATCH/RFT v2 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input +10:49 < pinchartl> - adv748x single output support (required for Ebisu to work) +10:49 < pinchartl> [PATCH v2 0/5] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input +10:49 < pinchartl> - vin-tests Draak support +10:49 < pinchartl> [PATCH v2 0/4] vin-tests: Add D3 Draak support +10:49 < pinchartl> - Tested D3/E3 lvds-pll support on D3 with HDMI +10:49 < pinchartl> Until next meeting: +10:49 < pinchartl> - Ebisu HDMI/CVBS and adv748x +10:49 < pinchartl> - Also review Laurent's D3/E3 lvds-pll patches +10:49 < pinchartl> - Another round of patch upporting for DU (vga?) +10:49 < pinchartl> Issues and Blockers: None +10:49 < pinchartl> jmondi: any comment ? +10:49 < geertu> horms: Please +1 https://github.com/getpatchwork/patchwork/issues/60#issuecomment-418592452 +10:49 < jmondi> not really +10:50 < jmondi> ah, I forgot I should have a more detailed look at the mux series from Niklas +10:50 < jmondi> and support you in testing Ebisu HDMI input +10:50 < pinchartl> I'll add that, thanks +10:50 < pinchartl> * Kieran +10:50 < pinchartl> Since last meeting: +10:50 < pinchartl> - DU/VSP cleanup and limitation patches +10:50 < pinchartl> - Partition Algorithm limitation patch updated and reposted +10:50 < pinchartl> - ADV748x reviews +10:50 < pinchartl> - Supporting Biju on ADV748x CVBS VIN input +10:50 < pinchartl> - Testing on Salvator-XS M3-N Discovered a possible VSP1 ROT bug +10:50 < pinchartl> Until next meeting: +10:50 < pinchartl> - Holiday! +10:50 < pinchartl> - ADV748x dynamic routing (unless Jacopo does this) +10:50 < pinchartl> - Writeback repost? +10:50 < pinchartl> The BSP has an alternate implementation here as a screenshot, rather than a v4l2 device. Is this the actual requirement? (No one ever gave us requirements other than make a v4l2 device) +10:50 < pinchartl> - Partition Phase work bubbles back up the priority list +10:50 < pinchartl> This will need a lot of time though. +10:50 < pinchartl> Issues and blockers: None +10:51 < pinchartl> * Laurent +10:51 < pinchartl> Since last meeting: +10:51 < pinchartl> - Patch review +10:51 < pinchartl> - D3/E3 DU LVDS PLL upstreaming +10:51 < pinchartl> The first version of the functional patch series has been posted. Jacopo has tested it on D3. +10:51 < pinchartl> Until next meeting: +10:51 < pinchartl> - More patch review +10:51 < pinchartl> - D3/E3 DU LVDS PLL upstreaming +10:51 < pinchartl> - Get GMSL patches merged +10:51 < pinchartl> Issues and blockers: None +10:51 < pinchartl> * Morimoto-san +10:51 < pinchartl> Since last meeting: +10:51 < pinchartl> - RSND TDM expand mode upport +10:51 < pinchartl> - RSND Multi DAI support +10:51 < pinchartl> Until next meeting: None +10:51 < pinchartl> Issues and Blockers: +10:51 < pinchartl> - We don't have any board/platform on which to check TDM expand mode. +10:51 < pinchartl> - No progress on ALSA framework changes for multi DAI support +10:51 < pinchartl> Patches have been submitted by another developer but don't move forward. +10:52 < pinchartl> morimoto: any comment ? +10:52 < horms> geertu: done +10:53 < pinchartl> * Niklas +10:53 < pinchartl> Since last meeting: +10:53 < pinchartl> - [PATCH 00/30] v4l: add support for multiplexed streams +10:53 < pinchartl> - Started work on UDS scaler prototype. +10:53 < pinchartl> Until next meeting: +10:53 < pinchartl> - Post UDS scaler prototype. +10:53 < pinchartl> - Pray for feedback to the multiplexed streams patch-set. +10:53 < pinchartl> Issues and blockers: +10:53 < pinchartl> - Not sure if I want to travel to XDC or not  +10:53 < pinchartl> neg: any comment ? +10:53 < morimoto> pinchartl: sorry for my late. no comment +10:54 < pinchartl> morimoto: thanks +10:54 < pinchartl> * Simon (Kaneko-san) +10:54 < pinchartl> Since last meeting: None +10:54 < pinchartl> Until next meeting: +10:54 < pinchartl> - Testing M3-N and E3 Audio support +10:54 < pinchartl> Issues and blockers: None +10:54 < pinchartl> horms: any comment ? +10:54 < neg> no comment +10:54 < pinchartl> neg: thanks +10:54 < pinchartl> * Ulrich +10:54 < pinchartl> Since last meeting: None +10:54 < pinchartl> Until next meeting: +10:54 < pinchartl> - Review "R-Car D3/E3 display support (with LVDS PLL)" +10:54 < pinchartl> Issues and blockers: None +10:54 < pinchartl> uli___: any comment ? +10:54 < horms> pinchartl: no. let me know if any upporting is desired +10:54 < uli___> nope +10:55 < pinchartl> horms: I will. thanks +10:55 < pinchartl> uli___: thanks +10:55 < pinchartl> second topic, discussions +10:55 < pinchartl> is there anything that anyone would like to discuss ? +10:56 < neg> nothing from me +10:57 < morimoto> nothing from me +10:57 < pinchartl> that's it then. the next meeting will be two weeks from now, on the 20th, at the usual time +10:57 < pinchartl> thank you all for attending diff --git a/wiki/Chat_log/20180920-core-chatlog b/wiki/Chat_log/20180920-core-chatlog new file mode 100644 index 0000000..8b7298e --- /dev/null +++ b/wiki/Chat_log/20180920-core-chatlog @@ -0,0 +1,180 @@ +Core-chat-meeting-2018-09-20 + +09:24 < Marex> wsa: besides the news that I finally managed to extract all the relevant info out of Lorenzo ... +09:24 < Marex> wsa: yet still, there's one last bit which he didn't answer fully and I have to read the PCIe spec for that +09:24 < Marex> wsa: that is, can a register other than PMCSR put a card into D3hot and thus link into L1 ? +09:24 < geertu> Marex: PCIe is core? +09:24 < Marex> wsa: and if so, is that PCIe compliant configuration +09:25 < Marex> geertu: PCIe is a bus :-) +09:25 < geertu> wsa: I'll wait 5 more minutes? +09:26 < wsa> Marex: I see. Thanks for keeping at it and diving into it. +09:26 < wsa> geertu: ok +09:26 < Marex> thing is, if PMCSR is the only register which can put a card into D3hot state, we can intercept such accesses in the PCIe code +09:26 < Marex> if not, we're doomed and need the ATF fixup +09:26 < wsa> understood +09:26 < Marex> I am afraid it's the later ... +09:26 < Marex> I mean, I can cook such a setup in an FPGA +09:27 < Marex> the question really is, does PCIe spec permit this +09:27 < Marex> and that neither me nor Lorenzo know ... and thus I need to read the spec again +09:27 < wsa> and what does hardware in reality really do +09:28 < Marex> wsa: what do you mean ? you can use setpci to write any register you want pretty much :) +09:28 < Marex> wsa: I don't know if such a card with custom register to enter D3hot exists, but I know it can be created with relative ease ... +09:28 < wsa> i mean specs are one thing, reality is another +09:28 < wsa> not more than that... +09:29 < Marex> wsa: there's too much hardware to know whether PMCSR is the only reg ever used to enter D3hot +09:30 < Marex> wsa: but if the spec says it is, then the certification checks it and we only support certified PCIe hardware +09:31 < wsa> we can do that +09:31 < Marex> wsa: ... and we can ignore hardware which doesn't use PMCSR to enter the D3hot as non-compliant +09:32 < damm> maybe non-compliant + non-compliant = success? +09:32 < damm> its like xor +09:32 < wsa> we only support non-compliant HW :D +09:32 < damm> =) +09:32 < geertu> damm: nah, it's like a CMOS gate with a floating input ;-) +09:33 < Marex> damm: isn't that more multiplicative operation ? +09:33 < wsa> Well, our HW semms broken, so if this is the best we can do, then OK +09:34 < wsa> but once we got more information about what to do (ATF or not), we should report again to the HW team +09:34 < damm> geertu: reminds me of sh7751 PCI power management +09:34 < damm> Marex: you are right +09:34 < wsa> ok, so now we are 5 minutes over time again :D +09:35 < geertu> So let's start? +09:35 < geertu> Welcome to today's Core Group Meeting! +09:35 < geertu> Agenda: +09:35 < geertu> 1. Status Updates +09:35 < geertu> 2. Discussion Topics +09:35 < geertu> Topic 1. Status updates +09:36 < geertu> A) What have we done since last time: +09:36 < geertu> Jacopo reviewed the RZ/N1 pinctrl driver, and discussed it with Phil +09:36 < geertu> Edworthy. +09:36 < geertu> Marek fixed various issues in U-Boot (DT memory node parsing, timer +09:36 < geertu> frequency, reset), resubmitted the R-Car Gen2 PMIC quirk handling patch, +09:36 < geertu> and continued working on fixing the PCIe L1 issue (ATF, JTAG, discussion +09:36 < geertu> with Lorenzo). +09:36 < geertu> Morimoto-san says BSP 3.7.0 will be handled using periupport, and has +09:36 < geertu> shipped an Ebisu-4D to Magnus. +09:36 < geertu> Morimoto-san and Shimoda-san provided BSP git commit description feedback +09:36 < geertu> to the BSP team, to improve descriptions. +09:36 < geertu> Shimoda-san says Renesas Vietnam started testing LTSI v4.14-rc1, and +09:36 < geertu> discussed power management support in the IPMMU driver with Magnus. +09:36 < geertu> Simon posted a backport of I2C fixes for v4.14-ltsi-rc2, and prepared a +09:36 < geertu> backport of an MSIOF fix. +09:36 < geertu> Wolfram worked on dma_params (subsystem, SYS-DMAC, SDHI-DMAC). +09:36 < geertu> Geert revisited VFIO and QEMU platform device pass-through patches, +09:36 < geertu> reviewed lots of patches. He also created two branches to assist GregKH +09:36 < geertu> with releasing v4.14-ltsi-rc1, tested v4.14.70-ltsi, and reviewed rcar-i2c +09:36 < geertu> fixes submitted for rc2. +09:38 < geertu> B) What we plan to do till next time: +09:38 < geertu> Magnus will prepare a plan for IPMMU PM development. +09:38 < geertu> Marek will continue workijg on the PCIe L1 issue. +09:38 < geertu> Niklas will aggregate different SDHI clocks settings user in aid of trying +09:38 < geertu> to solve the different setting between ES versions of H3. +09:38 < geertu> Shimoda-san says Renesas Vietnam will continue testing LTSI v4.14-rc1 until +09:38 < geertu> Sep 25th. He will submit v2 of the usb2.0 host/peripheral properties +09:38 < geertu> update. +09:38 < geertu> Geert will continue QEMU GPIO virtualization, handle SYSC and PFC errata, +09:38 < geertu> and review fixes to be submitted for v4.14-ltsi-rc2. +09:39 < geertu> C) Problems we have currently: +09:39 < geertu> Marek has problems with "the" PCI controller ;-) +09:39 < geertu> Geert reviewed too many(?) patches. +09:39 < geertu> --- +09:40 < geertu> Anything I missed? +09:41 < Marex> geertu: I got U-Boot test suite running on Gen2 Porter :) +09:41 < horms> I think it might be worth mentioning that there seem to be a lot of patches to review over the past few months. Not that this is a problem. But it does take some time fore review etc... +09:42 < horms> s/fore/for/ +09:42 < geertu> It's the penalty to pay for the RZ/G marketing decisions... +09:43 < geertu> Topic 2. Discussion Topics +09:43 < horms> Yes, a lot of them relate to that work +09:43 < geertu> We already had the PCIe stuff in the intermeeting period +09:44 < wsa> I just hope that does get recognized inside Renesas when it comes to "why do we need an upstream team"... +09:44 < damm> i'd like to report back about the process review +09:45 < damm> whenever is a good time +09:45 < geertu> wsa: AFAIK their original plan was to just use the existing compatible properties, and be done with it. +09:45 < geertu> damm: Yes please +09:46 < damm> so i sat down with the Rennesas guys and went over the chat log from earlier when pinchartl outlined stuff +09:46 < damm> and basically there are no objections at all +09:46 < damm> we had to zoom out quite a few times +09:47 < damm> the focus was tool vs process +09:47 < damm> to clarify focus and expected order from my side +09:48 < damm> and it became evident that some expectation existed from Renesas side to use some tool for the upcoming 6 month period +09:48 < pinchartl> did they define "some tool" ? +09:48 < damm> well, i basically gave some home work to make a 6 month plan +09:49 < damm> it should include teh following: +09:49 < damm> - when to discuss process with laurent +09:49 < damm> - which tool to use when +09:49 < damm> - which input format when (bsp format changes) +09:50 < damm> (also whenever new bsp releases are made those should be in there too) +09:50 < damm> this to make it clear which tool to use when and what the expected output of the process discussion is +09:51 < damm> i hope that morimoto-san can bring the plan to ELCE and discuss with pinchartl +09:51 < damm> for further feedback +09:51 < damm> and potential coutner prooposal +09:51 < pinchartl> I hope that the plan will start with a process discussion :-) +09:51 < damm> i asked to focus on this until next chat meeting +09:52 < damm> and lets see where that takes us +09:52 < damm> pinchartl: me too! =) +09:52 < damm> that's it from my side +09:54 * Marex afk , doctors' appointment , bye +09:54 -!- neg [~neg@unaffiliated/neg] has quit [Read error: Connection reset by peer] +09:54 < horms> do I understand correctly that there will be a follow-up discussion with Renesas before the next chat meeting? +09:54 < damm> correct +09:54 -!- neg [~neg@unaffiliated/neg] has joined #periperi +09:55 < wsa> so, Renesas wants to use "the tool" for Q4Q1 already? And we discuss about it at ELCE end of October? +09:55 < wsa> or did i get something wrong? +09:55 < horms> Is there also a dialog in progress regarding the value/role of the upstream team? +09:57 < damm> wsa: i want the plan to point out clarly which tool to use when +09:57 < damm> wsa: if you have any preference feel free to share that +09:57 < wsa> horms: I wonder about that, too. Especially since there I know of some good example recently where our good connections with upstream saved us some work (SCCB rework, irqless I2C transactions, DMA 32bit limitation) +09:58 < damm> horms: not yet +09:58 < pinchartl> damm: that's a very vague question... +09:58 < damm> horms: at this point it is just focusing on the interface/format for the up port work +09:58 < damm> so about "the tool" +09:59 < horms> damm: feel free to drag me into any conversation if you think I can be of assistance +09:59 < horms> But lets get back to the process/tool discussion - sorry for the noise +09:59 < damm> horms: thanks +09:59 < damm> np +09:59 < damm> so the way the tool was developed and the expected process order from my (and pinchartl) seems to mismatchhhh +10:00 < damm> so rolling in the tool urgently w/o a clear process seems rusing in the potentially wrong direction +10:00 < wsa> damm: I am fine with your plan to point that out clearly. I just was confused about the dates +10:00 < damm> ok +10:00 < pinchartl> from my side the problem is clear. I can't comment on tooling if I'm not told what the process is, in *details* +10:00 < damm> i want to clarify the expectation from each side +10:01 < pinchartl> (to use an analogy everybody here should be able to understand, I can't review an implementation if I'm not told what API it implements) +10:01 < damm> maybe we will see that we have different expectations =) +10:01 < damm> pinchartl: i'm with you +10:02 < damm> i want to help clarify expectation from renesas side first +10:02 < damm> then let you guys hash it out during ELCE +10:02 < wsa> damm: same as horms, I'd like to be assistance for that discussion if you think I could be useful. (and now back to "the tool") +10:02 < damm> while i am in hiding some place else +10:03 < damm> wsa: so you should join pinchartl for the process discussion topic +10:04 < damm> so i expect you guys to take the plan from renesas side and request minor updates or ask for major change with your own proposal if needed +10:04 < damm> this to make sure we have a healthy discussion +10:04 < damm> just accepting won't help anyone +10:04 < wsa> damm: you mean at ELCE, sure thing +10:05 < damm> (i don't expect that from pinchartl) =) +10:05 < damm> wsa: yep +10:05 < damm> is my expecation about this far ooff? +10:06 < damm> (thats how it gets when you live in your PJs most of the time) +10:06 < pinchartl> damm: if you expect me to make a major counter proposal, I may be able to live up to your expectations :-) +10:06 < damm> haha +10:06 < damm> i hope to give you some clear expectation to work with +10:07 < damm> perhaps you can adjust timing of tool change etc +10:07 < damm> depending on how much time you expect is needed for the process discussion +10:08 < damm> so let me report back next chat meeting about the plan so far +10:09 < pinchartl> sounds good to me +10:09 < damm> any questions that i ducked? +10:09 < damm> or new ones? +10:10 < damm> pinchartl: do you have any expected frequency of broken out process discussions? +10:10 < damm> for next 6 months +10:11 < pinchartl> damm: not really. ideally we'll have one good discussion, decide on a plan, and move forward +10:12 < damm> then do your best at ELCE timing and we can take minor increments from there? +10:12 < damm> shall we do one more process discussion meeting via HO or similar before ELCE? +10:13 < damm> maybe we can ponder a bit for now and book something next chat meeting? +10:13 < pinchartl> I think you know my position. if there's more information to share, we can have another discussion, otherwise I don't think it would be very useful +10:14 < damm> we will have some info in form of a plan next meeting +10:15 < damm> my point is that when we discussed last time we only got to touch part of the subject +10:15 < damm> but anyway +10:15 < damm> no questions? +10:16 < pinchartl> not from me +10:16 < damm> ok shall we close the topic? +10:16 < geertu> ok for now +10:17 < damm> thanks +10:18 < geertu> Anything else to discuss? +10:19 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20180920-io-chatlog b/wiki/Chat_log/20180920-io-chatlog new file mode 100644 index 0000000..8451871 --- /dev/null +++ b/wiki/Chat_log/20180920-io-chatlog @@ -0,0 +1,127 @@ +09:03 < wsa> Welcome everyone to the IO meeting +09:03 < wsa> No surprises today, status updates, and topics +09:03 < wsa> Here are the status updates: +09:03 < wsa> A - what have I done since last time +09:03 < wsa> ------------------------------------ +09:03 < wsa> Kaneko-san +09:03 < wsa> : added MSIOF to D3 PFC +09:03 < wsa> Marek +09:03 < wsa> : continued to deeply investigate the PCIE L1 link state handling +09:03 < wsa> Shimoda-san +09:03 < wsa> : sent add reset_control and multiple clocks support for USBHS, and made patches +09:03 < wsa> for USB2.0 (host and peripheral) support for R-Car E3/D3. +09:03 < wsa> Simon +09:03 < wsa> : sent out RAVB patches on not writing reserved bits and removing an alignment +09:03 < wsa> restriction for Gen3, and helped tracking down a RAVB PHY link regression +09:03 < wsa> Ulrich +09:03 < wsa> : revisited patches about SCIF RPM improvements +09:03 < wsa> Wolfram +09:03 < wsa> : sent prototypes to handle dangling pointers in the DMA subsystem, sent +09:03 < wsa> patches to set dma_parms for some R-Car DMA controllers, implemented core +09:03 < wsa> part of irqless I2C transfer prototype, update new bsp370 ticket file with +09:03 < wsa> comments from old ticket file and so far overlooked already upstream commits, +09:03 < wsa> and did reviews of SDHI patches +09:03 < wsa> B - what I want to do until next time +09:03 < wsa> ------------------------------------- +09:03 < wsa> Kaneko-san +09:03 < wsa> : wants to enable SYS-DMAC support for E3 MSIOF +09:03 < wsa> Marek +09:03 < wsa> : wants to continue to investigate the PCIE L1 link state handling and revisit +09:03 < wsa> a new upstream patch series dealing with the 32-bit bus limitation +09:03 < wsa> Niklas +09:03 < wsa> : wants to work on the SDHI reset patch series and on the handling of '4TAP +09:03 < wsa> only' devices +09:03 < wsa> Shimoda-san +09:03 < wsa> : wants to update patches renesas_usbhs and phy-rcar-gen3-usb2 for R-Car E3/D3, +09:03 < wsa> continue to investigate the eMMC suspend issue, and continue with KVM on Gen3 +09:03 < wsa> and document findings on the elinux wiki. +09:03 < wsa> Simon +09:03 < wsa> : wants to follow up on the link regression and alignment patches as well as +09:03 < wsa> checking the BSP for more RAVB patches +09:03 < wsa> Ulrich +09:03 < wsa> : wants to continue with SCIF RPM upporting +09:03 < wsa> Wolfram +09:03 < wsa> : wants to find and backport patches to fix suspend with SDHI, work on I2C +09:03 < wsa> core PM improvements, and upport I2C/SDHI patches from new BSP release +09:03 < wsa> C - problems I currently have +09:03 < wsa> ----------------------------- +09:03 < wsa> Marek +09:03 < wsa> : with the limitations of the PCIE controller +09:03 < wsa> Niklas +09:03 < wsa> : might have less time assigned for SDHI work +09:04 < wsa> please fire away questions you have +09:04 < wsa> I have the following ones: +09:04 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi +09:05 < wsa> shimoda: I guess the usb-dmac driver could also benefit from the dma_parms update I did for the SYS-DMAC? +09:05 < wsa> shimoda: do you want to have a look at this or shall I add it for USB-DMAC, too? +09:05 < wsa> any other DMACs I missed? +09:07 < wsa> shimoda: should I pause with finding the SDHI commits which make resume on eMMC possible because you and Renesas Vietnam are working on it? +09:07 < geertu> usb-dmac is a separate driver, audio-dmac is just rcar-dmac +09:07 < shimoda> wsa: i think so, but I'd like to confirm first the usb-dmac also has the same issue :) +09:07 < wsa> or does it make sense working on that in parallel? +09:08 < geertu> We should find that commit by Sep 28, to get the fix in v4.14-ltsi-rc2 +09:09 < wsa> shimoda: ok, sure, then I will wait +09:09 < shimoda> wsa: about SDHI/eMMC suspend/resume issue, since Renesas vietnam is focusing on LTSI testing, they cannot find the commits until 28th Sep. +09:09 < wsa> neg: +09:10 < wsa> shimoda: understood, I'll give it a priority boost then to make it until sep, 28th +09:10 < shimoda> wsa: thanks! +09:11 < neg> wsa: ? +09:11 < wsa> neg: (sorry, I hit enter to early, real question coming up) +09:12 < neg> :-) +09:12 < wsa> neg: I wonder a bit about no A) being NULL for the last two weeks although I thought this was the month with more SDHI time reserved? +09:13 < horms> On the subject of LTSI-4.14. I have one fix that is more or less ready to post. I'm unsure if its best to do so or wait, say until early next week, to see if any more fixes emerge. +09:13 < wsa> were there unforseen issues? or do you need assistance? +09:14 < wsa> or urgent m/m stuff? +09:15 < wsa> I don't want to blame you, I just wonder if we as groupleaders can do better planning +09:15 < neg> wsa: no it was mor or less planed as I spent most of the the previous two weeks segment on IO. 5.5 days/month on base is thin to spread around sometime +09:15 < wsa> I see +09:15 < wsa> Sorry, I thought you had more time assigned +09:16 < neg> wsa: I try to focus on one IP at a time to not waste time context switching :-) +09:16 < wsa> That sounds good +09:17 < wsa> OK, I learn from this that we (as groupleaders) maybe should talk more about absolute numbers +09:17 < neg> wsa: I do it's 6.6 not 5.5 days :-P +09:18 < wsa> can I cheer for you getting more days? :D +09:18 < wsa> you are probably fine as is this way, I assume +09:19 < wsa> ok, but with you having less time for SDHI in the future, I need to add another C) item for myself +09:19 < wsa> C) +09:20 < wsa> * developer time for SDHI is scarce +09:21 < wsa> (with developer time being scarce is nothing new :/) +09:21 < wsa> okay, other questions? +09:23 < wsa> well, seems core can have an early start today? +09:23 < wsa> geertu: are you up for it? +09:24 < Marex> wsa: besides the news that I finally managed to extract all the relevant info out of Lorenzo ... +09:24 < Marex> wsa: yet still, there's one last bit which he didn't answer fully and I have to read the PCIe spec for that +09:24 < Marex> wsa: that is, can a register other than PMCSR put a card into D3hot and thus link into L1 ? +09:24 < geertu> Marex: PCIe is core? +09:24 < Marex> wsa: and if so, is that PCIe compliant configuration +09:25 < Marex> geertu: PCIe is a bus :-) +09:25 < geertu> wsa: I'll wait 5 more minutes? +09:26 < wsa> Marex: I see. Thanks for keeping at it and diving into it. +09:26 < wsa> geertu: ok +09:26 < Marex> thing is, if PMCSR is the only register which can put a card into D3hot state, we can intercept such accesses in the PCIe code +09:26 < Marex> if not, we're doomed and need the ATF fixup +09:26 < wsa> understood +09:26 < Marex> I am afraid it's the later ... +09:26 < Marex> I mean, I can cook such a setup in an FPGA +09:27 < Marex> the question really is, does PCIe spec permit this +09:27 < Marex> and that neither me nor Lorenzo know ... and thus I need to read the spec again +09:27 < wsa> and what does hardware in reality really do +09:28 < Marex> wsa: what do you mean ? you can use setpci to write any register you want pretty much :) +09:28 < Marex> wsa: I don't know if such a card with custom register to enter D3hot exists, but I know it can be created with relative ease ... +09:28 < wsa> i mean specs are one thing, reality is another +09:28 < wsa> not more than that... +09:29 < Marex> wsa: there's too much hardware to know whether PMCSR is the only reg ever used to enter D3hot +09:30 < Marex> wsa: but if the spec says it is, then the certification checks it and we only support certified PCIe hardware +09:31 < wsa> we can do that +09:31 < Marex> wsa: ... and we can ignore hardware which doesn't use PMCSR to enter the D3hot as non-compliant +09:32 < damm> maybe non-compliant + non-compliant = success? +09:32 < damm> its like xor +09:32 < wsa> we only support non-compliant HW :D +09:32 < damm> =) +09:32 < geertu> damm: nah, it's like a CMOS gate with a floating input ;-) +09:33 < Marex> damm: isn't that more multiplicative operation ? +09:33 < wsa> Well, our HW semms broken, so if this is the best we can do, then OK +09:34 < wsa> but once we got more information about what to do (ATF or not), we should report again to the HW team +09:34 < damm> geertu: reminds me of sh7751 PCI power management +09:34 < damm> Marex: you are right +09:34 < wsa> ok, so now we are 5 minutes over time again :D diff --git a/wiki/Chat_log/20180920-mm-chatlog b/wiki/Chat_log/20180920-mm-chatlog new file mode 100644 index 0000000..00c88ea --- /dev/null +++ b/wiki/Chat_log/20180920-mm-chatlog @@ -0,0 +1,281 @@ +Multimedia-chat-meeting-2018-09-20 + +10:22 < pinchartl> welcome to the multimedia meeting +10:22 < pinchartl> topic 1, status updates +10:23 < pinchartl> * Jacopo +10:23 < pinchartl> Since last meeting: +10:23 < pinchartl> - R8A77990 (E3) VIN and CSI-2 +10:23 < pinchartl> Respined Ebisu support patch, supported Laurent and Niklas in testing. +10:23 < pinchartl> - Respined the adv748x single endpoint probe patches +10:23 < pinchartl> - Reviewed and tested Sakari's v4l2-fwnode patches +10:23 < pinchartl> - Ported CEU driver to use new fwnode defaults +10:23 < pinchartl> - Tested and reviewed the D3/E3 LDS PLL patches +10:23 < pinchartl> Until next meeting: +10:23 < pinchartl> - Really look into the E3 CSI-2 issue +10:23 < pinchartl> - Test niklas v4l2-mux series +10:23 < pinchartl> - Have adv748x patches merged +10:23 < pinchartl> Issues and Blockers: None +10:23 < pinchartl> jmondi: any comment ? +10:23 < jmondi> pinchartl: not really +10:23 < jmondi> apart deciding how to procede forward with E3 VIN and CSi-2 testing +10:24 < jmondi> but that's for later, with you and neg +10:24 < pinchartl> I plan to test the next version of the adv748x patch +10:25 < jmondi> pinchartl: great, let's sync so I can support +10:25 < pinchartl> in the meantime, if there are CSI-2 and VIN debug registers that could help diagnosing the problem, it would be nice to have a small hack debug patch to read them +10:26 < pinchartl> * Kieran +10:26 < pinchartl> Since last meeting: +10:26 < pinchartl> - VSP1 and DU patch respins and posting +10:26 < pinchartl> - Testing D3/E3 LVDS patch series +10:26 < pinchartl> - Discovered and investigated rcar-du Alpha Blending bug. +10:26 < pinchartl> - ADV748x development and reviews +10:26 < pinchartl> - periupport updates for bsp370/v4.14 +10:26 < pinchartl> - Posted patches to fix the alpha blend regression +10:26 < pinchartl> - Conference planning +10:26 < pinchartl> Until next meeting: +10:26 < pinchartl> - M3-N Rotation bug needs investigation. +10:26 < pinchartl> - Writeback rebase and repost. +10:26 < pinchartl> - Partition phase work +10:26 < pinchartl> - ADV748x dynamic routing. +10:26 < pinchartl> Issues and blockers: None +10:26 < pinchartl> kbingham: any comment ? +10:26 < jmondi> pinchartl: not sure where we have to look into, my guesses are now adv748x 2 lanes config (you have to test if I got it right) and the CSI-2 interface VC configuration +10:26 < jmondi> sorry +10:26 < kbingham> Only one for morimoto-san +10:26 < kbingham> morimoto, Do we need to submit cost plans for ELCE? +10:27 < morimoto> Yes, please +10:27 < kbingham> morimoto, Ack. I'll send an email this morning :) +10:27 < kbingham> Otherwise good here. +10:27 < morimoto> and, Hotel cost, too +10:28 < kbingham> Sure +10:28 < kbingham> Me Laurent and Jacopo will share accomodation I believe +10:28 < pinchartl> jmondi: I don't know where the problem is, so I can't tell you what to look into either :-) +10:29 < jmondi> pinchartl: I understand, but it's hard to pick a register to help debug, if we don't know where the problem is :) anyway, let's sync and try +10:30 < pinchartl> * Laurent +10:30 < pinchartl> Until next meeting: +10:30 < pinchartl> - More patch review +10:30 < pinchartl> - D3/E3 DU LVDS PLL upstreaming +10:30 < pinchartl> - Attend XDC (X Developers Conference) next week +10:30 < pinchartl> Since last meeting: +10:30 < pinchartl> - More patch review +10:30 < pinchartl> - D3/E3 DU LVDS PLL upstreaming +10:30 < pinchartl> - Get GMSL patches merged +10:30 < pinchartl> Issues and blockers: None +10:30 < pinchartl> any question ? +10:31 < jmondi> what about GMSL? +10:31 < jmondi> just respin the series? +10:31 < jmondi> or you need support for that? +10:32 < pinchartl> I need to finish the review, and then send a pull request +10:32 < pinchartl> or one of you could send the pull request, no issue with that +10:33 < pinchartl> * Morimoto-san +10:33 < pinchartl> Since last meeting: +10:33 < pinchartl> - TDM investigations (???) +10:33 < pinchartl> Until next meeting: +10:33 < pinchartl> - Implement TDM expand mode using StarterKit + KingFisher +10:33 < pinchartl> Issues and Blockers: +10:33 < pinchartl> - We can't check TDM split mode +10:33 < pinchartl> morimoto: any comment ? +10:33 < morimoto> no, thanks +10:34 < pinchartl> * Niklas +10:34 < pinchartl> Since last meeting: +10:34 < pinchartl> - [PATCH] v4l2-common: fix typo in documentation for v4l_bound_align_image() +10:34 < pinchartl> - [PATCH 0/3] rcar-vin: add support for UDS (Up Down Scaler) +10:34 < pinchartl> - [PATCH 0/3] i2c: adv748x: add support for CSI-2 TXA to work in 1-, 2- +10:34 < pinchartl> and 4-lane mod +10:34 < pinchartl> Until next meeting: +10:34 < pinchartl> - Work on review comments to UDS and adv748x +10:34 < pinchartl> - Pray for feedback to the multiplexed streams patch-set +10:34 < pinchartl> Issues and blockers: None +10:35 < pinchartl> neg: any comment ? +10:35 < neg> no comment, thanks +10:35 < pinchartl> prayers seem not to have worked well, could you try to push me a bit more explicitly to get the muxed streams series reviewed ? +10:36 < kbingham> morimoto, What is TDM investigations ? +10:36 < neg> will do :-) +10:36 < kbingham> Is that an audio thing ? +10:36 < morimoto> kbingham: yes. there are 3 type of format +10:36 < morimoto> TDM x 2, and Mono +10:37 < morimoto> I did was Mono, not TDM. sorry pinchartl +10:37 < morimoto> --eol-- +10:38 < pinchartl> thanks, I'll update that +10:38 < pinchartl> * Simon (Kaneko-san) +10:38 < pinchartl> Since last meeting: +10:38 < pinchartl> - Merged: [PATCH v2] ASoC: rsnd: Add device tree binding for r8a77990 +10:38 < pinchartl> Until next meeting: +10:38 < pinchartl> - Testing M3-N and E3 Audio support +10:38 < pinchartl> Issues and blockers: None +10:38 < pinchartl> horms: any comment ? +10:39 < horms> Not that I need to find time to actually do the testing +10:39 < horms> Not other than that... +10:40 < pinchartl> * Ulrich +10:40 < pinchartl> Since last meeting: None +10:40 < pinchartl> - Reviewed (half of) "R-Car D3/E3 display support (with LVDS PLL)" +10:40 < pinchartl> Until next meeting: TBD +10:40 < pinchartl> Issues and blockers: None +10:40 < pinchartl> uli___: any comment ? +10:41 < uli___> i'll be afk until tuesday, will it still be ok to review the back half of the d3/e3 hdmi series then? +10:41 < horms> possibly related: I plan to close the reneas tree for v4.20 next Wednesday +10:42 < pinchartl> uli___: sure +10:42 < pinchartl> horms: ok +10:42 < uli___> ok. no other comments. +10:42 < pinchartl> the DT bindings have been approved, can I then send the DT changes for v4.20 ? +10:44 < pinchartl> horms: that was a question for you :-) +10:45 < horms> If they have been approved and you think the DT changes are finalised, then yes, feel free. +10:45 < pinchartl> thanks +10:45 < pinchartl> that's it for the status updates +10:45 < pinchartl> topic 2, additional tasks for Q4 +10:46 < pinchartl> damm: do you have any comment on that before we start ? +10:47 < damm> nope +10:47 * morimoto I believe I can get some answer about 3 questions +10:47 * morimoto in later +10:48 < pinchartl> morimoto: I've seen them, we'll get to that, don't worry :-) +10:48 < pinchartl> so regarding additional tasks for Q4 +10:48 < morimoto> thanks +10:48 < pinchartl> we have reduced budget +10:48 < pinchartl> which implies reduced additional tasks +10:49 < pinchartl> with 10 days per quarter I don't see how we can reasonably include upstreaming in any additional task anymore +10:49 < pinchartl> damm: I would thus like to know what type of tasks Renesas will expect now +10:49 < pinchartl> they just can't include everything from development to upstreaming anymore +10:50 < pinchartl> upstreaming will need to be handled under base time +10:50 < damm> pinchartl: yes i agree +10:51 < jmondi> which makes, depending on how much time one has left, only one task in total for q4 per person acceptable +10:51 < pinchartl> jmondi: I would go for one task per quarter, yes +10:51 < jmondi> as it will consume additional time for implementation and all base time for upstreaming +10:52 < jmondi> pinchartl: yeah, my point is that also base time will be affected, leaving not much time for the usual base tasks (review, backlog, etc) +10:53 < jmondi> but I think this a well known issue... +10:53 < pinchartl> it should be known at least +10:53 < pinchartl> it's certainly known on our side that less time means less output :-) +10:54 < pinchartl> damm: you explained before that Renesas expected upstreaming to be included in additional tasks. now that this can't be done anymore, what type of tasks would be acceptable ? +10:58 < damm> prototypes, minor bug fixes, building some hardware rig to extend testing etc +10:58 < pinchartl> ok, thanks +10:58 < damm> makign test programs +10:58 < damm> or extending them +10:58 < pinchartl> so we need to come up with additional tasks +10:58 < damm> that's my take at least +10:58 < pinchartl> I would like all multimedia developers to submit proposals +10:59 < pinchartl> you can reply to the meeting report e-mail, or we can discuss them now if you already have ideas +10:59 < kbingham> pinchartl, I'd probably consider the M3-N Rotation bug as a candidate then +11:00 < jmondi> there are a few things around adv748x but I'm not sure how to assign them +11:00 < neg> I would love to work on improving test rigs but is that not a dangerus path to prove the value of the upstream team? +11:00 < neg> Would it not be a bit more clever to package a set of IP specific upport commits as add tasks? +11:01 < pinchartl> neg: my understanding is that upport as an additional task was frowned upon by Renesas, but things might have changed +11:02 < neg> pinchartl: ahh I see was not aware of that scrap that then :-) +11:02 < damm> actually +11:02 < damm> i don't mind including the up-port bit +11:02 < damm> if it is something that can be defined clearly and is in demand +11:02 < pinchartl> damm: that's good to hear :-) +11:02 < damm> also about test rig +11:03 < damm> if we can document how things may be done in a public space then i think it has value by itself +11:04 < damm> (this is how we automate eject/insert of SD cards for example) +11:04 < kbingham> There is an automated-testing mailinglist (I think started by Tim Bird) where lots of farming talks are currently occuring in public space. +11:04 < kbingham> And a test-summit at ELCE +11:04 < kbingham> geertu, Are you attendign that test summit? +11:04 < pinchartl> the testing summit will occur at the same time as the V4L2 summit I believe :-( +11:05 < geertu> kbingham: yes I will. Will mostly be about the automated testing part, I believe +11:05 < kbingham> geertu, I'm sure that's what we need more of :) +11:06 < geertu> pinchartl: Yes, -ETOOMANYCONCURRENCY +11:06 < pinchartl> geertu: something like that +11:06 < geertu> kbingham: Not if it involves Jenkins +11:06 < kbingham> geertu, Is that their only solution ? :S +11:08 < pinchartl> let's move to the next topic +11:08 < pinchartl> morimoto: you had questions +11:08 < morimoto> yeah +11:08 < pinchartl> I've just replied to them by e-mail +11:08 < pinchartl> I'll paste my replies here +11:08 < morimoto> I got answer from kbingham and jacopo +11:09 < neg> kbingham: well is not gerrit + jenkins the silver bullet solution to all software quality and assurence it be devliverd on time? +11:09 < morimoto> thanks ! I got your answer +11:09 < pinchartl> ah, there are other answers too +11:10 < pinchartl> regarding the VSP 1x1 image size, Mauro has applied to the patch to this tree +11:10 < pinchartl> s/this tree/his tree/ +11:11 < kbingham> Oh - I missed that :) +11:11 < kbingham> But great :) +11:11 < pinchartl> for the DU reserved registers, Jacopo has submitted patches +11:12 < pinchartl> but I'm concerned about all the changes that are requested to match the datasheet to the last detail, when there's no clear indication that this is needed +11:13 < pinchartl> I can consider merging Jacopo's series this time, but next time we'll get a request along the lines of "the datasheets states this order of operations, the driver need to match" I will request a proof that the current implementation causes a real bug +11:14 < wsa> damm: about remote inserting SD cards: I got a device from Pengutronix which does that +11:14 < pinchartl> and regarding the D3/E3 LVDS PLL and clock issue, I plan to submit that as an additional task for Q4 +11:14 < pinchartl> morimoto: does this answer your questions ? +11:14 < damm> wsa: great! i recall linaro had something like that too +11:14 < jmondi> pinchartl: awmm (I don't know how to properly express demotivating feelings with onomatopoeic expressions in English, hope it's clear) +11:15 < pinchartl> jmondi: it's not a judgment on the quality of your work, but I think that several requests we have received are pointless to start with +11:15 < wsa> damm: https://www.pengutronix.de/2017-10-23-usb-sd-mux-automated-sd-card-juggler.html +11:15 < pinchartl> and I don't want to continue increasing the complexity of an already complex piece of code when there's no need to +11:15 < morimoto> pinchartl: sorry my late response. Thanks, nice answer +11:15 < damm> pinchartl: since many devices are shared IP that should work on many SoCs it would make sense to give feedback to renesas to make sure the register read/write order is consistent across products +11:16 < morimoto> I will forward these to BSP team +11:16 < jmondi> pinchartl: sure I get it, I was referring to this kind of requests +11:16 < pinchartl> damm: it's not just about consistency between products, it's also that in many cases a specific write order is not required +11:17 < pinchartl> if you have to program lots of registers before starting the hardwarer +11:17 < pinchartl> more often than not the order doesn't matter +11:17 < damm> lets just say that i agree with you very much +11:17 < wsa> I could ask if they can bring some to ELCE if that helps. I can bring the one I have, too +11:17 < pinchartl> and mandating a specific order sometimes creates extra complexity in the driver by breaking the natural grouping of parameters we get from existing APIs +11:18 < damm> i'm with you +11:18 < pinchartl> thanks :-) +11:18 < damm> that kind of request makes the "alpabetize the headers" thing look good +11:18 < morimoto> pinchartl: sometimes (anytimes ?) BSP team cares very picky point +11:19 < pinchartl> damm: :-D +11:19 < pinchartl> morimoto: in many cases they have good points, they point us to small bugs that are hard to find or only happen in some corner cases, but that are bugs nevertheless, and I'm happy to fix them +11:20 < pinchartl> but sometimes it really feels like they have been asked to do something and they push the request down to us, even if the request wasn't very sensible to start with +11:20 < damm> if there are dependenices and ordering between several IPs it would be helpful to know those ahead of time +11:20 < morimoto> one reason is that it is related to customer +11:21 < morimoto> customer is checking "datasheet" and "driver" +11:21 < pinchartl> morimoto: then I think the datasheet should be updated +11:21 < pinchartl> as that's where the problem is +11:21 < morimoto> and ask to us "why datasheet and driver are not same ?" if driver and datasheet are mismatched +11:21 < pinchartl> if the hardware can work with multiple orders +11:21 < pinchartl> and the datasheet says that a specific order is required +11:21 < pinchartl> then the datasheet is wrong :-) +11:22 < damm> the data sheet is like a recommendation +11:22 < damm> it is more like fiction than fact +11:22 < morimoto> yeah, sometimes multiple order is OK. but it is case-by-case +11:23 < morimoto> This is unfortunately complex area to solve +11:23 < pinchartl> of course when some operations have to be ordered a certain way, and the driver doesn't follow that, we should fix the code +11:23 < damm> morimoto: but changing order requirement late in the process seems not very useful +11:23 < morimoto> HW team vs datasheet team vs softweare team vs customer +11:23 < pinchartl> one problem with the datasheet documenting a particular order without stating whether it's mandatory or not, +11:24 < damm> morimoto: if this was a requirement then we want to know this from day 0 +11:24 < pinchartl> is that important information get lost in the noise +11:24 < pinchartl> as it then becomes easy to read the datasheet and think that it's just the usual case of a recommended order +11:24 < pinchartl> while it's actually super important +11:25 < pinchartl> so by saying that things are mandatory all around when they are not, the real mandatory ones don't clearly show +11:25 < pinchartl> but I don't think there's any fundamental disagreement among us here +11:25 < pinchartl> any other discussion topic ? +11:26 < damm> pinchartl: maybe we can implement some hardware abstraction layer and use the drivers from Integrity(tm) that follow the correct order(tm) +11:26 < morimoto> This kind of topic is unfortunately difficult to solve. I will ask to BSP team whether it is very important, or datasheet side can updated or so. +11:27 < damm> my opinion is that shared IP needs to be discussed on a broader scale +11:27 < damm> renesas needs to learn how to manage shared ip +11:28 < damm> i expect you guys to help out that process by good feedback =) +11:28 < damm> no other topic from me +11:28 < morimoto> I think this is not only Renesas issue. Many people are related to this kind of topic, but no one knows who has correct answer... +11:28 < morimoto> no topic from me, too +11:29 < jmondi> nothing to add from my side neither +11:29 < pinchartl> alright +11:29 < pinchartl> last topic then +11:29 < pinchartl> next meeting +11:29 < pinchartl> two weeks from now, on October the 4th, same time as usual ? +11:30 < kbingham> Aribtrary question from me - Has Gen4 hardware been started already ? +11:30 < morimoto> kbingham: not yet +11:30 < kbingham> ( I assume they start gen4 before Gen3 ships) +11:30 < kbingham> Oh ok - so my assumption is wrong ;) +11:30 < morimoto> it is depend on what is your "start" mean +11:31 < morimoto> "Gen4 plan" is started, "Gen4 implement" is not yet +11:31 < kbingham> :) +11:32 < kbingham> So it's 18-24 months at least or more before any g4 hardware appears then :) +11:32 < morimoto> But we will have Gen3.5 :) +11:32 < kbingham> Oh :) +11:32 < morimoto> I don't know detail, thought +11:32 < neg> Gen3.5 = new ES versions ? +11:33 < morimoto> neg: I don't know, sorry +11:33 < geertu> s/arm/risc-v/? +11:33 < neg> morimoto: no worries just curious :-) +11:33 < morimoto> geertu: not Risc-V :) +11:34 < kbingham> pinchartl, Oct 4th sounds good to me. +11:34 < morimoto> Oct 4th is OK to me +11:35 < pinchartl> that's all I have for today +11:35 < neg> 4th OK for me +11:35 < pinchartl> I propose adjourning the meeting +11:35 < pinchartl> does anyone second ? +11:36 < jmondi> fine wiht me +11:36 < neg> seconded, thanks for hosting the meeting +11:36 < morimoto> 2nd +11:36 < pinchartl> meeting adjourned, thank you all for attending, and have a nice day ! diff --git a/wiki/Chat_log/20181004-core-chatlog b/wiki/Chat_log/20181004-core-chatlog new file mode 100644 index 0000000..135a15d --- /dev/null +++ b/wiki/Chat_log/20181004-core-chatlog @@ -0,0 +1,111 @@ +Core-chat-meeting-2018-10-04 + +09:35 < geertu> Welcome to Today's Core Group Chat! +09:35 < geertu> Agenda: +09:35 < geertu> 1. Status Updates +09:35 < geertu> 2. Discussion Topics +09:35 < geertu> Topic 1. Status updates +09:35 < geertu> A) What have we done since last time: +09:35 < geertu> Jacopo reviewed the RZ/N1 pinctrl driver. +09:35 < geertu> Marek worked on Linux PCIe 32bit DMA, ATF (memory config passing), and +09:35 < geertu> U-Boot (memory config passing, Gen3 USB PHY, TMIO SDMMC, SPL as minimon +09:35 < geertu> replacement). +09:35 < geertu> Morimoto-san discussed the PeriPeri process, reviewed BSP commit +09:35 < geertu> descriptions, and reports Magnu's Ebisu-4D has arrived. +09:35 < geertu> Shimoda-san says Renesas Vietnam started testing LTSI v4.14-rc2, +09:35 < geertu> discussed power management support in the IPMMU driver with Magnus, and +09:35 < geertu> submitted v2 of the usb2.0 host/peripheral property updates. +09:35 < geertu> Geert worked on virtualization (pass-through preparatory work, device +09:35 < geertu> reset, proof-of-concept for QEMU GPIO virtualization), sent +09:35 < geertu> clock/pinctrl pull requets, and upported/enabled INTC-EX on R-Car E3. +09:36 < geertu> B) What we plan to do till next time: +09:36 < geertu> Marek will continue ATF-U-Boot DT memory layout handoff and SPL +09:36 < geertu> experiments, and will revisit PCIe SError. +09:36 < geertu> Morimoto-san will create process images for ELCE. +09:36 < geertu> Shimoda-san says Renesas Vietnam will continue testing LTSI v4.14-rc2 until +09:36 < geertu> Oct 5th. He will discuss with Simon-san about R-Car E3 enablement. +09:36 < geertu> Geert will sent a third pinctrl pull-request for v4.20, Remove +09:36 < geertu> SoC-specific ARCH_* symbols to please arm-soc, and handle SYSC and PFC +09:36 < geertu> errata. +09:38 < geertu> Anything I missed? +09:38 < horms> geertu: I'd like to talk about those symbols and how to finalise getting our v4.20 patches accepted. But it can be outside of this meeting. +09:40 < geertu> OK, let me summarize +09:40 < geertu> Arnd asked to remove all SoC-specific ARCH_* symbols, as other vendors don't have them. +09:40 < geertu> However, this means the SoC-specific CLK_* and SH_PFC_* symbols will become user-visible. +09:41 < geertu> In addition, there are a few other places (mostly drivers/soc/renesas/) where these ARCH_* symbols are used, so they have to be "fixed". +09:42 < Marex> geertu: I wanna focus on U-Boot testing, but that's a detail +09:42 < geertu> We do want to avoid including too much unneeded stuff where it makes sense (e.g. RZ/A with internal SRAM only and XIP) +09:43 < geertu> horms: Any comments? +09:43 < horms> geertu: So I see we will need to make some adjustments. Will they be for both ARM and arm64? Once we have sorted out what they are, can we make sure everyone, including Chris Patterson, is aware so new patches follow the new way. I assume any changes will take effect in v4.21 at the earliest, in which case we can prod Arnd to take the existing pull request. +09:44 < geertu> horms: If we do it for arm64, I think it makes sense to do it for arm32, too. +09:44 < horms> It seems to me that Arnd has a policy that he wishes to enforce - for no other reason than it exists. Iguess we have to work with that. +09:44 < horms> Ok, consistency is good for me. +09:45 < horms> Is the plan to expose the CLK_* and SH_PFC_* symbols? +09:45 < horms> It doesn't seem terrible to me +09:45 < horms> Though it does seem slightly worse than the current situation +09:45 < geertu> We will need a new ARCH_RCAR_GEN3 symbol, as ARCH_RENESAS applies to arm64 and arm32, and Arnd was OK with that +09:46 < geertu> Correct, CLK_* and SH_PFC_* symbols will become user-visible (they already were for RZ/A1 and RZ/N1, as they may rely on the bootloader for pinctrl setup, to reduce kernel size) +09:46 < horms> Ok, I'm a little confused about the purpose of ARCH_RCAR_GEN3 +09:47 < wsa_> ARCH_RENESAS64? +09:47 < horms> I assume it would cover RZ/G2 but not some other SoCs, say RZ/A2 +09:47 < geertu> Correct. +09:47 < geertu> RZ/A2 is arm32, so not affected +09:47 < horms> Would it be user-visible? +09:48 < geertu> drivers/soc/renesas/Kconfig +09:48 < geertu> select RST_RCAR if ARCH_RCAR_GEN1 || ARCH_RCAR_GEN2 || \ +09:48 < geertu> ARCH_R8A774A1 || ARCH_R8A774C0 || ARCH_R8A7795 || \ +09:48 < geertu> ARCH_R8A7796 || ARCH_R8A77965 || ARCH_R8A77970 || \ +09:48 < geertu> ARCH_R8A77980 || ARCH_R8A77990 || ARCH_R8A77995 +09:48 < geertu> The last part would be replaced by ARCH_RCAR_GEN3 +09:49 < geertu> Oh, we also have SYSC_*, forgot about those... +09:49 < geertu> But the sysc files are smaller, so we could always include them, based on SoC family. +09:50 < geertu> ARCH_RCAR_GEN3 would not be user-visible +09:50 < geertu> For now, once e.g. RZ/A3 becomes arm64, we need a new family selector. +09:50 < horms> Ok, so we would end up with the same amount or rst code compiled in +09:50 < horms> More sysc code, but it would be onl a little bit more +09:50 < horms> And pinctl and clk would be selected by the user +09:51 < geertu> Correct. +09:51 < horms> Ok, I understand +09:51 < geertu> pinctrl code for one SoC is O(tens of KiB) +09:51 -!- neg [~neg@unaffiliated/neg] has quit [Read error: Connection reset by peer] +09:51 < geertu> clock code for one SoC is O(some KiB) +09:51 < horms> This does seem slightly worse than the current situation. But if thats what Arnd wants I think we can live with it +09:51 < geertu> sysc code for one SoC is O(few hundred bytes) +09:52 -!- neg [~neg@unaffiliated/neg] has joined #periperi +09:52 < horms> I look forward to reciving a request from him to have per-soc Kconfig symbols to be more like other vendors :^) +09:52 < geertu> horms: That may come from Olof, or Kevin ;-) +09:52 < horms> Regarding v4.20, can we prod him to take the pull-request as is +09:52 < horms> geertu: haha +09:52 < geertu> horms: Probably yes. +09:52 < horms> Ok, will you prod him or shall I. If so, when? +09:53 < geertu> horms: Didn't he take your PR? +09:54 < horms> No, I don't think so. +09:54 < horms> I did check that yesterday +09:55 < horms> I don't see it in arm-soc/for-next +09:55 < geertu> Indeed. I will ask him to pull it. +09:55 < horms> Thanks +09:56 < horms> From my pov we have a way forwards to fix his greivance, and can likely implement it in v4.21, but we'd be most grateful if he could take the pr for v4.20 in its current form to enable our new hw in upstream in that release. +09:57 < horms> sorry to take so much of everyones time in the meeting +09:58 < geertu> Replied to Arnd. +09:58 -!- patersonc [c18ddb24@gateway/web/freenode/ip.193.141.219.36] has joined #periperi +09:58 < horms> dank u wel +09:58 < geertu> Inserting "Topic 2. Discussion Topics +09:58 < geertu> " above +09:58 < geertu> Any other discussion topics? +10:01 < wsa_> do we have a place to meet on Friday in Edinburgh? +10:01 < wsa_> I am not aware +10:02 < wsa_> but I may have missed it +10:02 < geertu> I am not aware, neither +10:02 < Marex> geertu: U-Boot testing ? +10:02 < pinchartl> wsa_: in that case I missed it too +10:02 < geertu> Anyone familiar with Edinburgh? +10:03 < Marex> geertu: U-Boot has a testsuite, so we should start running it continously +10:03 < wsa_> I can have a look +10:03 < geertu> Marex: yes, (automated) testing is great! +10:04 < Marex> geertu: do we do any automated testing for Linux ? +10:05 < geertu> wsa_: Thx! +10:05 < geertu> Marex: Not enough, I guess +10:06 < Marex> geertu: I think once I finish the current batch of tasks, I'd like to start looking in that direction +10:06 < geertu> Marex: That would be great! +10:08 < geertu> Time to pass the mic to pinchartl? +10:08 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20181004-io-chatlog b/wiki/Chat_log/20181004-io-chatlog new file mode 100644 index 0000000..7fb21bd --- /dev/null +++ b/wiki/Chat_log/20181004-io-chatlog @@ -0,0 +1,128 @@ +09:07 < wsa_> okay, let's start the IO meeting then +09:07 < wsa_> here are the status updates +09:08 < wsa_> Status updates +09:08 < wsa_> ============== +09:08 < wsa_> A - what have I done since last time +09:08 < wsa_> ------------------------------------ +09:08 < wsa_> Geert +09:08 < wsa_> : made a small MSIOF test rig fitting Ebisu and Draak containing an EEPROM, +09:08 < wsa_> fixed workqueue-related issues on suspend/unbind in thermal drivers +09:08 < wsa_> Marek +09:08 < wsa_> : handled Linux PCIe 32bit DMA test feedback +09:08 < wsa_> Niklas +09:08 < wsa_> : started rework for v2 SDHI reset series and sent sent next version of the +09:08 < wsa_> interrupt initialization patch +09:08 < wsa_> Shimoda-san +09:08 < wsa_> : sent patches for D3/E3 support for renesas_usbhs and phy-rcar-gen3-usb2, +09:08 < wsa_> and E3 support for gadget/udc/renesas_usb3. Also, finished investigating +09:08 < wsa_> the eMMC suspend issue +09:08 < wsa_> Simon +09:08 < wsa_> : upstreamed removal of 4 byte alignment and fixed a regression in link +09:08 < wsa_> negotiation, both for RAVB +09:08 < wsa_> Ulrich +09:08 < wsa_> : re-checked "serial: sh-sci: Use pm_runtime_get_sync()/put()" +09:08 < wsa_> Wolfram +09:08 < wsa_> : sent RFCs for irqless I2C transfers to communicate very late and for +09:08 < wsa_> rejecting transfers after noirq suspend stage, reviewed various patches +09:08 < wsa_> for SDHI and I2C, upported patches for SCIF and BD9571 +09:08 < wsa_> B - what I want to do until next time +09:08 < wsa_> ------------------------------------- +09:08 < wsa_> Geert +09:08 < wsa_> : wants to test E3 MSIOF DMAC if patches are ready +09:08 < wsa_> Kaneko-san +09:08 < wsa_> : wants to upport E3 MSIOF DMAC enablement +09:08 < wsa_> Marek +09:08 < wsa_> : wants to go back to PCIe SError again +09:08 < wsa_> Niklas +09:08 < wsa_> : wants to find a good solution to 4-tap clock issue +09:08 < wsa_> Shimoda-san +09:08 < wsa_> : wants to work on KVM + QEMU + USB +09:08 < wsa_> Simon +09:08 < wsa_> : wants to investigate RAVB no-link patches in BSP 3.7.2 +09:08 < wsa_> Ulrich +09:08 < wsa_> : prepares for stay in the Philippines until Dec 10 +09:08 < wsa_> Wolfram +09:08 < wsa_> : wants to continue with above I2C PM related tasks and continue upporting +09:08 < wsa_> patches for SDHI and I2C +09:08 < wsa_> C - problems I currently have +09:08 < wsa_> ----------------------------- +09:08 < wsa_> Wolfram +09:08 < wsa_> : needs more time with I2C PM as expected. +09:08 < wsa_> my questions: +09:09 < wsa_> neg: what about the SD clock divider patches? Can you give them priority because we need them to enable HS400? +09:10 < wsa_> neg: or does the reset issue fix a set of problems I am currently unaware of? +09:10 < wsa_> morimoto: is it correct to not update BSP-ticket files older than 'bsp370'? +09:11 < morimoto> on what ? +09:11 < wsa_> in other words, I only update 'bsp370' now and consider the other ones "v4.x" outdated +09:11 < wsa_> periupport +09:11 < morimoto> My understanding is that basically we want to 100% done all ticket on periupport +09:12 < morimoto> if possible +09:12 < morimoto> next ver bsp380 (?) can be started on new tool +09:12 < morimoto> Is this good answer for you ? +09:12 < horms> morimoto: I think this is not a question about what to do, but rather what to track +09:12 < horms> Currently we have bsp70 4.14 and 4.9 tickets +09:12 < morimoto> Yes +09:12 < neg> wsa_: sure I can try and move it up on the list, my plan was to work on that after ELCE during the SDHI hacking days as that issue has the most unclear solution to me at this time +09:13 < horms> Can we assume that all relevant tickets are included in bsp370 and ignore the old 4.14 and 4.9 tickets because they are assumed to be duplicates +09:13 < wsa_> neg: ah, this is included in the "4tap" task? +09:13 < morimoto> If working for v4.x is too old or impossible, I think we can skip +09:13 < horms> Or do we need to keep tracking all bsp370 4.14 and 4.9 tickets +09:13 < horms> with all duplicates? +09:13 < morimoto> horms: Ohh, yes, I think so +09:14 < horms> ok, i think that was wsa_'s question +09:14 < wsa_> horms: thanks for the clarification. that was exactly what i meant +09:14 < horms> One thing on the BSP: I expect BSP 3.7.2 will be released today or tomorrow +09:14 < neg> wsa_: yes that is core problem of the 4-tap clock issue, maybe I should use a better description for the task, sorry about that +09:15 < wsa_> neg: ok, good +09:15 < shimoda> horms: "with all duplicates" means these tickets (bsp370, 4.14, 4.9) have duplicate commits? +09:16 < horms> shimoda: yes, maybe with different commit ids due to rebasing +09:16 < wsa_> neg: please note that Geert won't be at the SDHI hackfest (and probably not available by mail because it is a weekend). +09:16 < horms> shimoda: so its a bit of extra work to update the duplicate tickets +09:17 < wsa_> neg: so, some discussion beforehand might be helpful? +09:17 < neg> wsa_: I agree that is something to handle and as you suggest try to discuss beforehand with geertu +09:19 < wsa_> thanks +09:19 < geertu> wsa_: I'll be stuck in Edinburgh until my late afternoon flight +09:19 < wsa_> geertu: which day? +09:20 < geertu> wsa_: Saturday +09:21 * geertu has never been to Edinburh before, so there may be more interesting things to visit ;-) +09:21 < wsa_> good to know +09:21 < morimoto> horms: sorry maybe I answered strange things for you. +09:21 < wsa_> SDHI hackfest will not be in Edinburgh, though +09:21 < wsa_> but close +09:21 < neg> geertu: more interesting that solving clock divider problmes? What could it possibli be? :-) +09:22 < wsa_> I think we will see at "runtime", but let's plan for you having some sightseeing time in Edinburgh :) +09:22 < horms> morimoto: I'm fine with your answer. The overhead is managable for now, IMHO +09:22 < morimoto> we can ignore 4.9. basically 4.14 and bsp370 have no coflictl +09:22 < morimoto> s/conflictl/conflict/ +09:23 < morimoto> We want to focus 4.14 and bsp370 +09:23 < Marex> wsa_: btw re that pci stuff, I am thinking of implementing U-Boot PCI driver for Gen3, so I can have faster turnaround when testing the ATF SError handling +09:23 < wsa_> v4.9 is horribly outdated by now +09:23 < morimoto> was_: yes, let's ignore it. +09:24 < wsa_> v4.14 needs a little backporting; but, yes, managable +09:25 < wsa_> I will create a periperi meeting page in our wiki today +09:25 < wsa_> I liked the collection of who leaves when and stays where and what we planned +09:26 < wsa_> Marex: ok +09:26 < wsa_> Marex: is it just for faster turnaround time, or is there a use case? :) +09:26 < shimoda> horms: thanks, as morimoto-san mentioned, to avoid a bit of extra work, let's stop v4.9 updating +09:27 < Marex> wsa_: faster turnaround, but maybe there could be a usecase +09:27 < Marex> wsa_: it shouldn't take long to write the driver +09:27 < horms> shimoda: thanks, got it +09:28 < geertu> Marex: Intel Ethernet TFTP? +09:28 < geertu> Marex: Remote DMA using IEEE-1394? +09:29 < geertu> Marex: nVidia U-Boot splashscreen? +09:29 < wsa_> geertu, uli___ : there is a SCIF patch left for upporting, is one of you interested? +09:29 < wsa_> sci: sh-sci: Fix transfer sequence of unsupport DMA transfer(6beb1f98d3bd30) +09:30 < uli___> i can do it +09:30 < wsa_> uli___: thanks! +09:31 < geertu> probably we should lower that message from dev_warn to dev_dbg? +09:31 < Marex> geertu: which one of those is exactly useful for us ? ;-) +09:32 < Marex> geertu: I think if you have an option rom, you can run option roms, so the posibilities grow even further ... +09:32 < wsa_> okay, any more questions from your side? +09:32 < Marex> geertu: I think if you have an option rom in your hardware, you can run it, so the posibilities grow even further ... +09:33 < Marex> (I need coffee) +09:33 < geertu> Marex: Remote DMA may allow to read ATF-protected memory? +09:33 < Marex> geertu: we should make sure this is actually NOT possible ;-) +09:34 < Marex> geertu: that's the point of the memory being protected +09:34 < wsa_> okay, then +09:34 < wsa_> thanks for this meeting +09:35 < wsa_> geertu: the stage is yours! diff --git a/wiki/Chat_log/20181004-mm-chatlog b/wiki/Chat_log/20181004-mm-chatlog new file mode 100644 index 0000000..0c8cd0b --- /dev/null +++ b/wiki/Chat_log/20181004-mm-chatlog @@ -0,0 +1,169 @@ +Multimedia-chat-meeting-2018-10-04 + +10:09 < pinchartl> welcome to the multimedia meeting +10:09 * kbingham wakes up +10:09 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:09 < pinchartl> * Jacopo +10:09 < pinchartl> Since last meeting: +10:09 < pinchartl> - Review and test of v4l2-mux series from Laurent, Sakari and Niklas +10:09 < pinchartl> - Review of v4l2 drivers (imx214, ov5640, seco-cec) +10:09 < pinchartl> Until next meeting: +10:09 < pinchartl> - E3 VIN (CSI-2 issue) +10:09 < pinchartl> Issues and Blockers: None +10:09 < pinchartl> jmondi: any comment ? +10:10 < jmondi> not really +10:10 < pinchartl> you mentioned two weeks ago that you would work on "Get adv748x patches merged". any update on that ? +10:10 < jmondi> I think we have agreed we'll swap boards, right? +10:10 < jmondi> they got merged actually, thanks to Kieran's pull request fot eh adv748x +10:10 < pinchartl> yes, we will swap board +10:11 < pinchartl> ok, I'll add that as an achievement then :-) +10:11 < jmondi> yeah, sorry for not mentioning it +10:11 < pinchartl> no worries at all +10:11 < pinchartl> * Kieran +10:11 < pinchartl> Since last meeting: +10:11 < pinchartl> - Rebased and retested the write back work (not yet functional :s) +10:11 < pinchartl> - Pinged GMSL work for review and integration +10:11 < pinchartl> - Rebased GMSL-v3 for renesas-drivers +10:11 < pinchartl> - ADV748x pull request for linux-media +10:11 < pinchartl> - Working on partition algorithm phases and overlaps +10:11 < pinchartl> - rcar-du/shmobile-du patch reviews +10:11 < pinchartl> - Planning for Fault Tolerant V4L2 at ELCE Media Summit +10:11 < pinchartl> Until next meeting: +10:11 < pinchartl> - Complete the VSP1 partition algorithm phase overlap (top priority) +10:11 < pinchartl> - Any Fault Tolerant V4L2 planning required before ELCE/Media summit +10:11 < pinchartl> Issues and blockers: +10:11 < pinchartl> - The writeback prototype has completely broken/bitrotted and needs fixing +10:11 < pinchartl> kbingham: any comment ? +10:12 < kbingham> I think that covers it :) +10:12 < pinchartl> ~* Laurent +10:12 < pinchartl> Since last meeting: +10:12 < pinchartl> - More patch review +10:12 < pinchartl> - D3/E3 DU LVDS PLL merged upstream +10:12 < pinchartl> - Attended XDC 2018 +10:12 < pinchartl> Until next meeting: +10:12 < pinchartl> - More patch review +10:12 < pinchartl> - Submit multimedia additional tasks for Q4 +10:12 < pinchartl> - Get GMSL patches merged +10:12 < pinchartl> Issues and blockers: None +10:12 < pinchartl> any question ? +10:13 < wsa_> (first draft done: https://osdr.renesas.com/projects/linux-kernel-development/wiki/Periperi-2018-10) +10:14 < pinchartl> I can also add that XDC was interesting, but much more focussed on userspace and mesa than on the kernel side or compositors +10:14 < morimoto> wsa_: thanks ! +10:14 < pinchartl> so given our GPU situation there was little overlap +10:15 < pinchartl> one Imagination developer attended, but didn't announce that the company would open their driver :-) +10:15 < neg> pinchartl: :-) +10:15 < jmondi> are there rumors about this ^ ? +10:16 < pinchartl> none that I've heard +10:16 < jmondi> or it's just so unlikely that it is funny just to mention it? +10:16 < pinchartl> the Mali midgard (Txxx) and bitfrost (Gxxx) reverse engineering is going quite well though +10:16 < pinchartl> time to switch GPU vendor for Gen4 ? :-) +10:16 < morimoto> :) +10:16 < jmondi> yeah, let's switch to .... +10:16 < jmondi> intel i915? +10:17 < wsa_> vivante +10:17 < pinchartl> :-) +10:17 * morimoto I need to leave in 15min +10:18 < pinchartl> in that case +10:18 < pinchartl> * Morimoto-san +10:18 < pinchartl> Since last meeting: +10:18 < pinchartl> - Started work on TDM sound on StarterKit + KingFisher +10:18 < pinchartl> Until next meeting: +10:18 < pinchartl> - Continue work on TDM sound on StarterKit + KingFisher +10:18 < pinchartl> Issues and Blockers: +10:18 < pinchartl> - Can't check TDM in split mode +10:18 < pinchartl> morimoto: any comment ? +10:18 < morimoto> no, thanks +10:18 < pinchartl> * Niklas +10:18 < pinchartl> Since last meeting: +10:18 < pinchartl> - [PATCH] rcar-vin: fix redeclaration of symbol +10:18 < pinchartl> - Reworked ADV748x 1-, 2- and 4-lane mode +10:18 < pinchartl> Work done waiting to end of week before sending out to give dependencies which +10:18 < pinchartl> PR are sent for time to land in media tree. +10:18 < pinchartl> - Started v2 of UDS series +10:18 < pinchartl> Until next meeting: +10:18 < pinchartl> - Work on review comments to UDS and adv748x +10:18 < pinchartl> - Prepare for E3 VIN+CSI-2 hands on testing during ELCE +10:18 < pinchartl> Issues and blockers: None +10:18 < pinchartl> neg: any comment ? +10:18 < neg> No additional comment +10:18 < pinchartl> * Simon (Kaneko-san) +10:18 < pinchartl> Since last meeting: +10:18 < pinchartl> - M3-N audio tested and merged +10:18 < pinchartl> - E3 audio tested +10:18 < pinchartl> Until next meeting: TBD +10:18 < pinchartl> Issues and blockers: +10:18 < pinchartl> - E3 audio does not bring up any device that ALSA can see +10:19 < pinchartl> Same status in BSP 3.7.2-rc2. +10:19 < pinchartl> horms: any comment ? +10:19 < horms> Any thoughts on what to do about E3 audio? +10:19 < pinchartl> morimoto: any opinion on that ? +10:21 < morimoto> no special opinion +10:21 < morimoto> Does it mean, no codec driver ? +10:23 < pinchartl> horms: how about trying to debug it with Morimoto-san's help ? +10:24 < horms> pinchartl: yes, that is a good idea. +10:24 < morimoto> horms: OK +10:24 < horms> morimoto: I did post some boot logs a week or so ago. Let me know how we can work on this +10:25 < morimoto> horms: OK, will do. But, I will take day off tomorrow. It will be next week +10:25 < horms> morimoto: enjoy your day off :) +10:26 < morimoto> horms: Thanks. Can you re-post it to me ? or give me title ? +10:27 < pinchartl> * Ulrich +10:27 < pinchartl> Since last meeting: +10:27 < pinchartl> - Reviewed the rest of the D3/E3 DU LVDS PLL series +10:27 < pinchartl> Until next meeting: TBD +10:27 < pinchartl> Issues and blockers: None +10:27 < pinchartl> uli___: any comment ? +10:27 < uli___> nope +10:28 < pinchartl> thank you +10:28 < horms> morimoto: https://www.spinics.net/lists/linux-renesas-soc/msg33367.html "Re: [PATCH/RFT] arm64: dts: renesas: r8a77990: Add Audio-DMAC and Sound device nodes" +10:28 < pinchartl> Topic 2. Additional Tasks for Q4 +10:28 < pinchartl> here are the additional tasks that have been proposed so far +10:28 < pinchartl> * ADV748x Dynamic Routing +10:28 < pinchartl> * M3-N rotation bug fix +10:28 < pinchartl> * Handle LVDS PLL clock separately from encoder on D3/E3 +10:28 < pinchartl> * Fix RGB output routing on D3 and E3 +10:28 < pinchartl> * Joint automated test suite for DU and VIN +10:28 < pinchartl> * R-Car VIN and CSI-2 suspend and resume support prototype +10:29 < pinchartl> * Upporting and addition of pixel format +10:29 < pinchartl> we need to estimate the required time, I will then submit the tasks list to Magnus +10:29 < damm> thanks +10:30 < pinchartl> as far as I understand, all tasks proposed by Jacopo, Kieran and Niklas are 5 days tasks. is this correct ? +10:30 < neg> yes +10:30 < kbingham> yes +10:31 < pinchartl> jmondi: yes as well ? +10:31 < jmondi> pinchartl: yes, 5 days +10:31 < pinchartl> ok +10:32 < morimoto> horms: the reason I think is that Ebisu-4D doesn't have "sound codec" and "sound card" settings +10:32 < pinchartl> Topic 3. Discussions +10:32 < morimoto> In salvator case, it is "ak4613" and "simple-audio-card" +10:33 < pinchartl> does anyone have a topic to discuss ? +10:33 < pinchartl> I see Simon and Morimoto-san already have one :-) +10:33 < horms> morimoto: ok, so something missing from the DT description? +10:33 < morimoto> I think so +10:33 < morimoto> or .config doesn't select codec +10:33 < horms> Thanks, I'll take a look +10:34 < neg> Only topic I think of is if something should be prepared for the face to face meeting after ELCE to make the most out of that day +10:35 < pinchartl> neg: we need to prepare an agenda +10:35 < kbingham> I have a Q regarding peri-upport ... Do I need to do any update to my last series post in regards to that ? wsa_ suggested I sqaush the commits... any preference from the reviewer ? +10:35 < pinchartl> and I'm not sure we'll have time for the usual status update meetings +10:35 < pinchartl> so I'm wondering whether we should keep the normal meeting schedule and have an IRC meeting on the 18th +10:36 < pinchartl> kbingham: I have no preference, let me know if you will repost or if I should use the version you have sent +10:36 < kbingham> I won't repost unless I need to - so I'll leave it with the version that's there. +10:37 * morimoto time to go, bye-bye +10:37 < pinchartl> morimoto: have a nice day +10:37 < pinchartl> or rather evening +10:37 < pinchartl> kbingham: ok +10:38 < pinchartl> geertu: wsa_: any opinion regarding the ELCE meeting ? +10:38 < morimoto> pinchartl: thanks. bye +10:39 < wsa_> i am fine with both options +10:39 < wsa_> a tad more t having the meeting on 18th, actually +10:39 < wsa_> so we have more time for non-usual discussion in edinburgh +10:39 < geertu> I'm available the 18th, too. +10:40 < geertu> And on the 18th, we will have a better view on issues to tackle around ELCE time. +10:40 < pinchartl> I agree. we can use the meeting on the 18th to finalize the agenda for Edinburgh +10:41 < wsa_> yes +10:42 < pinchartl> already +10:42 < pinchartl> that's it then +10:42 < pinchartl> if there's nothing else to discuss, I propose adjourning this meeting. does anyone second ? +10:44 < neg> seconed +10:44 < wsa_> yup +10:44 < pinchartl> meeting adjourned, thank you all for attending diff --git a/wiki/Chat_log/20181018-core-chatlog b/wiki/Chat_log/20181018-core-chatlog new file mode 100644 index 0000000..c07db2b --- /dev/null +++ b/wiki/Chat_log/20181018-core-chatlog @@ -0,0 +1,272 @@ +Core-chat-meeting-2018-10-18 + +09:53 < geertu> Welcome to today's Core Group Chat! +09:53 < Marex> morimoto: sure :) +09:53 < geertu> Agenda: +09:53 < geertu> 1. Status Updates +09:53 < geertu> 2. Discussion Topics +09:53 < geertu> Topic 1. Status updates +09:53 < geertu> A) What have we done since last time: +09:53 < geertu> Jacopo reviewed RZ/A2 pinctrl, and joined the discussion on +09:53 < geertu> non-exclusive GPIOs. +09:53 < geertu> Kaneko-san posted D3 Thermal support. +09:53 < geertu> Marek handled Renesas feedback on U-Boot (incl. CPLD revival), +09:53 < geertu> worked on board compat string and FCNL node passing from ATF to +09:53 < geertu> U-Boot, and implemented PCIe SError recovery in ATF. +09:53 < geertu> Morimoto-san prepared images for the periperi and upport processes. +09:53 < geertu> Shimoda-san says Renesas Vietnam started testing LTSI v4.14, got an +09:53 < geertu> updated plan for the IPMMU driver from Magnus, and submitted usbhs +09:53 < geertu> patches (D3/E3 enablement + updates for other SoCs). +09:53 < geertu> Simon tested D3 Thermal support, posted periupport updates focussing on +09:53 < geertu> E3/D3, and looked for upstream/upporting tasks for Kaneko-san. +09:53 < geertu> Geert sent a pinctrl pull-request, an RFC to move SoC-specific ARCH_* +09:53 < geertu> symbols. He received an RSKRZA1 board, and has started digesting SYSC +09:53 < geertu> errata. +09:54 < morimoto> Marek: from BSP 3.8.0 (= next BSP), it will use U-Boot 2018.09 +09:54 < geertu> B) What we plan to do till next time: +09:54 < geertu> Kaneko-san will follow up on D3 Thermal support, and plans to enable +09:54 < geertu> E3 PMIC support. +09:54 < geertu> Marek will enjoy ELCE, PeriPeriCon, and the SDHI hackfest, and will +09:54 < geertu> continue discussing FCNL. +09:54 < geertu> Morimoto-san will finalize the process images, explain and discuss +09:54 < geertu> processes in Edinburgh, and confirm BSP review results to the BSP team. +09:54 < geertu> Shimoda-san will review the new IPMMU driver's plan, and says the RCV +09:54 < geertu> test team will continue testing LTSI v4.14 until Oct 24th. +09:54 < geertu> Simon will follow up on D3 thermal support, and update periupport +09:54 < geertu> updates using "make patch". +09:54 < geertu> Geert will attend ELC-E and the Automated Testing Summit, enjoy autumn +09:54 < geertu> holidays, and plans to continue digesting SYSC and PFC errata. +09:55 < geertu> C) Problems we have currently: +09:55 < geertu> Marek wonders if 0x47fe0000 is a reasonable address for parameter +09:55 < geertu> passing from ATF to U-Boot, and where to submit patches for Renesas' +09:55 < geertu> ATF? +09:55 < geertu> Morimoto-san thinks Laurent has a plan to create a sample format for BSP +09:55 < geertu> commits. +09:55 < geertu> Geert discovered the stock kernel doesn't work on RSKRZA1 (reboots +09:55 < geertu> immediately). +09:56 < geertu> Anything I missed? +09:56 < Marex> morimoto: awesome :-) +09:56 < Marex> morimoto: do you know if renesas is satisfied with the current state of U-Boot ? +09:56 < pinchartl> Marex: should we discuss ATF+U-Boot+FCNL now ? +09:57 < Marex> pinchartl: it's MM topic +09:57 < geertu> Topic 2. Discussion Topics +09:57 < geertu> FCNL itself is MM +09:57 < geertu> ATF+U-Boot is core +09:57 < patersonc> morimoto: BSP v3.8.0 = internal Yocto v3.13.0 release right? +09:58 < pinchartl> Marex: it's in-between :-) +09:58 < geertu> A. PeriPeriEdi Agenda +09:59 < geertu> I'll follow wsa, for core: +09:59 < geertu> - Overview +09:59 < geertu> - High level "what happened since last f2f meeting" +09:59 < geertu> - Is the group happy +09:59 < morimoto> Marex: I think so :) +09:59 < morimoto> patersonc: sorry, I'm not sure BSP <-> Yocto relationship +09:59 < geertu> I was also thinking about a (short) virtualization status? +10:00 < Marex> morimoto: whew, OK, thank you +10:00 < patersonc> morimoto: No worries. Yocto v3.13.0 is the release due out e/Oct +10:00 < geertu> And of course Morimoto-san's graphics skills: +10:00 < geertu> - PeriPeri "process" explanation and discussion. +10:00 < geertu> - "upport process" +10:00 -!- wsa_ is now known as wsa +10:01 < morimoto> :) +10:02 < wsa> geertu: no updates for virt from my side :( +10:03 < geertu> wsa: I meant for the PeriperiEdi agenda ;-) +10:03 < geertu> You have a few more days to change that ;-) +10:03 < Marex> morimoto: looks like I have a few bsp u-boot patches to review :) +10:03 < wsa> geertu: yeah :D +10:03 < patersonc> Marex: So u-boot 2018.09 supports all R-Car Gen2/3 boards? +10:04 < geertu> Any other topics for the PeriPeriEdi agenda? +10:04 < morimoto> I asked it to BSP team now. It seems they are happy, but want to have more feature. They said that shimoda-san is interface guy for it? I was asked to bring SD card for you in ELCE +10:05 < Marex> geertu: all Gen3 and about half of Gen2 (the ones which I have access to) +10:05 < Marex> patersonc: ^ +10:05 < Marex> patersonc: I still need to sort out the rest of Gen2 +10:06 < geertu> B. ATF+U-Boot+FCNL +10:06 < Marex> patersonc: it should be trivial, given that I have a Silk, Porter and Stout , so E2, M2W, H2 +10:06 < Marex> patersonc: porting Koelsch, Lager, Alt should be boring +10:06 < Marex> patersonc: Blanche might be challenging due to it's PNOR boot +10:06 < patersonc> Marex: Great +10:07 < patersonc> Marex: Thank you for the update +10:07 < Marex> morimoto: which features do they want ? +10:08 < Marex> patersonc: I'll probably do it next time I'm in Japan and can grab a few boards from damm -san's farm +10:08 < morimoto> Marex: it seems shimoda-san / goda-san will (?) post mail to you +10:08 < Marex> morimoto: got it :) +10:08 < horms> pinchartl: I pushed an update to periupport +10:09 < morimoto> Marex: when is that ? +10:09 < Marex> morimoto: the only grueling item for me is HS200 , it takes a lot of boot time to calibrate :( +10:09 < geertu> Marex: Anything to discuss about ATF+U-Boot+FCNL? +10:09 < Marex> morimoto: I'd like it to be next year for the first Jamboree that's gonna happen +10:09 < Marex> geertu: well, ATF, is the 0x47fe0000 good address for the DT ? +10:09 < morimoto> Marex: OK, looking forward to see you then +10:10 < pinchartl> horms: thank you +10:10 < Marex> morimoto: :-) +10:10 < Marex> morimoto: I'll make sure to submit some talk +10:10 < geertu> Marex: Do all R-Car Gen3 SoCs/boards have memory there? +10:10 < Marex> yeah +10:10 < Marex> geertu: all we know about +10:11 < Marex> geertu: plus the FCNL tables are at 0x47fd7000 , so I didn't pick the address at random +10:12 < wsa> Marex: i can give you my lager + alt in edi for a few days before the SDHI hackfest ;) +10:12 < geertu> That's part of the "first 128MB is reserved for secure area", right? +10:12 < Marex> wsa: I have a talk at E-ALE-E and two at YPDD, so I dont think I'll have time +10:12 < pinchartl> Marex: how about replacing the FCNL tables completely +10:13 < Marex> pinchartl: ABI ? +10:13 < wsa> Marex: ok +10:13 < Marex> wsa: but maybe in Dunbar ? +10:13 < geertu> And no suitable space in ICRAM? +10:14 < pinchartl> Marex: there's no upstream user of that ABI. BSPs can always revert the removal +10:14 < wsa> Marex: you mean if we run out of SDHI topics ;))) +10:14 < Marex> wsa: heh +10:14 < Marex> pinchartl: we can have both, it costs us nothing +10:15 < Marex> maybe a few instructions, but it's probably easier for renesas +10:15 < wsa> Marex: j/k, sure the boards will be in Dunbar, too +10:15 < pinchartl> Marex: code bloat ? +10:15 < Marex> not really +10:15 < Marex> wsa: :) +10:16 < Marex> wsa: should be quick too, so maybe a lunch topic +10:16 < Marex> pinchartl: the tables are generated while the FDT is generated, so that's really not adding much +10:17 < pinchartl> Marex: I won't work on it myself, but given that it's a BSP ABI, we don't neeed to care about it +10:17 < Marex> pinchartl: the real question is, what is the purpose of those tables and who is the user of those tables ? +10:17 < pinchartl> that's my opinion at least +10:17 < geertu> Agreed +10:17 < pinchartl> there's no upstream user +10:17 < pinchartl> FCNL isn't supported upstream +10:17 < geertu> yet? +10:18 < pinchartl> even enabling FCNL in ATF right now with upstream U-Boot + Linux will lead to a certain death +10:19 < Marex> so there's more than just parsing the tables in U-Boot +10:19 < Marex> U-Boot itself must not relocate itself into those areas +10:19 < Marex> so that's another item to add to the list +10:20 < pinchartl> data will be difficult to parse if it's overwritten, indeed :-) +10:20 < Marex> can someone put FCNL at 0x47000000 + 0x01000000 ? +10:20 < Marex> if so, then the FCNL tables would be in FCNL and it's all over +10:21 < damm> pinchartl: any reason why we cannot use dynamic FCNL handling? +10:21 < geertu> ICRAM would be safer for that... +10:21 < pinchartl> damm: what do you mean by dynamic ? +10:22 < damm> i meant that we can program the memory ranges for decoding on the fly +10:22 < damm> instead of using fixed reserved areas +10:22 < pinchartl> the memory ranges are programmed in the DRAM controller registers, and that's only available in secure mode :-( +10:22 < geertu> If ATF programs the security engine to allow that +10:23 < Marex> geertu: could be a security issue +10:23 < damm> pinchartl: isn't that a LifeC configuration issue? +10:23 < Marex> but allocating the FCNL dynamically would be indeed nice +10:24 < damm> i always thought we could use physical mirror addresses for the compression purpose +10:24 < damm> and statically configure the mirror addresses for de-compression purpose +10:24 < pinchartl> sa +10:24 < damm> and then let the linux-side just fiddle some physical bit to enable decompression +10:24 < pinchartl> damm: can LifeC allow access to only part of the DRAM controller registers in non-secure mode ? +10:25 < damm> pinchartl: not sure +10:25 < pinchartl> compression is handled by the FCP +10:25 < pinchartl> only decompression is done on the fly by the DRAM controller +10:25 < pinchartl> (amazing design, if you ask me...) +10:25 < damm> so i don't think the memory controller needs to be dynamically configured +10:25 < damm> just the use of physical addresses in linux needs to be dynamic +10:26 < geertu> pinchartl: decompression is simpler, and needs less resources, than compression +10:26 < pinchartl> geertu: I would have put everything in the FCP +10:26 < pinchartl> damm: I'm not sure to follow you +10:26 < damm> ok +10:26 < geertu> So if the DRAM is configured to do decompression on the whole shadow area, it'll work? +10:27 < damm> so right now we reserve a physical memory range for decompression +10:27 < damm> geertu: i think it should be considered at least +10:27 < geertu> pinchartl: Does the FCP do mem-to-mem decompression? That needs and extra memory buffer +10:27 < geertu> s/and/an/ +10:27 < pinchartl> geertu: no it doesn't, the FCP operates on the fly only, as a proxy for the VSP and other MM IP cores +10:28 < damm> i say we don't reserve a range and instead rely on the shadow area (that's the same as mirror i guess) +10:28 < pinchartl> right +10:28 < pinchartl> I got it +10:28 < pinchartl> it's not that simple +10:28 < pinchartl> as data can be stored in memory in different formats +10:29 < pinchartl> each FCNL area is configured for a specific format +10:29 < damm> i think with such solution we could enable compression per-buffer +10:29 < damm> so can we use multiple shadow areas? +10:29 < pinchartl> well, I suppose we could divide the shadow area, yes +10:29 < pinchartl> the division of the shadow area should still be passed from ATF all the way to Linux though +10:30 < damm> then just look at the physical address to determine format +10:30 < damm> yes +10:30 < pinchartl> so we would use the same mechanism +10:30 < damm> i'm not sure it would work but i think it is worth checking +10:30 < damm> right +10:30 < pinchartl> and use regular DRAM addresses or shadow addresses depending on whether we need to decompress or not +10:31 < damm> exactly +10:31 < pinchartl> this assumes that the shadow area won't be used for a different purpose, do we have any information about that ? +10:31 < damm> nope +10:31 < pinchartl> ok +10:31 < damm> sorry =) +10:31 < pinchartl> in any case, I expect that the mechanism for passing memory information from ATF to Linux to be the same +10:32 < pinchartl> it's just the Linux side that would be more dynamic +10:32 < pinchartl> it will be interesting to handle in combination with the IOMMU... +10:32 < damm> yes! +10:32 < pinchartl> interesting as in "get me out of here" :-) +10:33 < geertu> pinchartl: Depends on which memory region is set up for FCNL +10:33 < geertu> Again, can we use ICRAM to pass the info? +10:33 < pinchartl> geertu: to pass the FDT from ATF to U-Boot ? +10:33 < geertu> pinchartl: yes +10:33 < pinchartl> I have no issue with that +10:33 < Marex> geertu: that'd be perfect, but do we know what exactly renesas hides in ICRAM and where ? +10:33 < pinchartl> it's out of my scope :-) +10:34 < geertu> Marex: The first 16 KiB turns out to be inaccessible +10:34 < Marex> geertu: I need about 4 kiB of it +10:34 < geertu> It's used for secondary CPU bringup +10:34 < geertu> On Gen2 , that's Linux domain ;-) +10:34 < Marex> geertu: there's also the certheader +10:34 < Marex> geertu: we need to avoid overwriting that too +10:34 < Marex> geertu: and if we decide on using ICRAM, which address is "good" for renesas ? +10:34 < geertu> Marex: Can we (are we allowed) to overwrite that? +10:35 < Marex> geertu: I'd rather not, and it should be possible to avoid it +10:35 < geertu> Marex: Ehat happens if we overwrite that? +10:35 < geertu> s/Ehat/What/ +10:36 < Marex> geertu: I didn't try +10:36 < geertu> Marex: If it's critical, ATF should protect it +10:36 < Marex> geertu: heh +10:36 < geertu> "4 kiB should be enough for everyone"? +10:37 < Marex> morimoto: what does renesas think? Is there a 4 kiB space in ICRAM which we can use for the DT ? +10:37 < Marex> morimoto: and if so, which address would be preferred ? +10:37 < Marex> geertu: keep in mind there are systems with 128 kiB ICRAM (D3 and E3 I think), so they are a bit more size constrained +10:38 < Marex> geertu: and ... oh, BL2 is in ICRAM :/ +10:39 < Marex> geertu: but I wonder if BL2 can have a buffer at fixed location for this FDT in it +10:39 < Marex> geertu: then it'd be in ICRAM and in control of the compiler/linker +10:39 < morimoto> Marex: I don't know, I need to ask BSP team. please wait. +10:40 < Marex> morimoto: speaking of BSP team, I wonder if Yokoyama-san would be willing to hang out on this fine IRC ? :) +10:40 < geertu> Does it have to be a fixed address? Header with magic value? +10:40 < Marex> morimoto: would be nice to cooperate with him on U-Boot more +10:41 < Marex> geertu: it has to be fixed, since we thus far have no way to pass the FDT address from ATF to U-Boot +10:41 < Marex> geertu: that's only gonna happen in ATF 2.0 I think +10:42 < geertu> Marex: As I said, search for a magic header value in ICRAM? +10:42 < Marex> geertu: if I can put the buffer at a fixed address with simple linker magic, I'd go for that +10:43 < geertu> Marex: Sure, but if that's not possible on all SoCs... +10:43 < Marex> geertu: why wouldn't it be ? +10:43 < Marex> geertu: size constraints ? +10:43 < pinchartl> if the magic header can be searched on page boundaries it shouldn't be much of an overhead +10:44 < pinchartl> but if the address can also be fixed, it should be even less of an overhead :-) +10:44 < geertu> Marex: as you said, some SoCs have less ICRAM, and may use different parts for other purposes +10:46 < Marex> geertu: only D3 it seems +10:46 < geertu> Marex: Have you checked H3-N? +10:46 < Marex> I dont have minimon sources for H3N +10:46 < Marex> geertu: let's see the docs +10:46 < geertu> And the other unknown SoC being produced the day after tomorrow? +10:47 < Marex> geertu: silicon/next ? +10:47 < Marex> geertu: anyway, if we can put it into ICRAM, good +10:47 < damm> it can't be too difficult to read SoC version register (PRR?) and from there go for per-SoC base address if needed? +10:47 < Marex> geertu: then the question is, would renesas be willing to take the ATF patches ? +10:48 < Marex> damm: but unified == better +10:48 < damm> sure +10:48 < Marex> damm: I had this idea ... +10:48 < damm> we can be unified with what we have today, and special case upcoming stuff +10:48 < morimoto> Marex: I asked to BSP team, but it is implemented/using by 3rd party. So they don't know detail. If you can send me question mail, I can forward it to BSP/3rd party. +10:48 < Marex> damm: IFF ATF can pass board compatible string, U-Boot can select the right DT and then we can have single U-Boot for all Gen3 boards +10:48 < Marex> *gasp* +10:49 < Marex> morimoto: ATF ? +10:49 < damm> not bad +10:49 < Marex> geertu: the ICRAM is not documented in the datasheet, is it ? +10:50 < geertu> Marex: 21A System RAM? +10:51 < Marex> geertu: so D3/E3 could be an issue +10:51 < Marex> since I have ebisu, I can try +10:51 < morimoto> Marex: It was for 4kiB space in ICRAM +10:52 < morimoto> And it seems Yokoyama-san already go back to home today +10:52 < Marex> morimoto: sorry for keeping you here for so long +10:52 < morimoto> np +10:54 < geertu> Time to wrap up, and pass the torch^H^H^H^H^Hmic to pinchartl? +10:54 < Marex> geertu: well, let's try bundling the FDT into ICRAM then +10:54 < Marex> geertu: or, BL2 +10:55 < pinchartl> geertu: whenever you want +10:55 < pinchartl> we're only one hour late :-) +10:56 < geertu> And Niklas is still busy ;-) +10:56 < geertu> Let's fin(n)ish this ;-) +10:56 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20181018-io-chatlog b/wiki/Chat_log/20181018-io-chatlog new file mode 100644 index 0000000..250108a --- /dev/null +++ b/wiki/Chat_log/20181018-io-chatlog @@ -0,0 +1,207 @@ +09:05 < wsa_> welcome to this io meeting everyone +09:06 < wsa_> here is the collected status update +09:06 < wsa_> Status updates +09:06 < wsa_> ============== +09:06 < wsa_> A - what have I done since last time +09:06 < wsa_> ------------------------------------ +09:06 < wsa_> Geert +09:06 < wsa_> : fixed receive regression on SCIFA/B with DMA, tested MSIOF with DMA on Ebisu, +09:06 < wsa_> optimized AT25 SPI EEPROM driver for DMA, posted RFC to fix fallback to PIO +09:06 < wsa_> in the sh-sci driver +09:06 < wsa_> Kaneko-san +09:06 < wsa_> : got E3 SYS-DMAC enablement for MSIOF merged +09:06 < wsa_> Marek +09:06 < wsa_> : implemented PCIe SError recovery in ATF to handle link state problems +09:06 < wsa_> Niklas +09:06 < wsa_> : sent a new version of the SDHI reset series and prepared a summary of the +09:06 < wsa_> HS400 clock divider issue +09:06 < wsa_> Shimoda-san +09:06 < wsa_> : reviewed RZ/G1C's USB2.0 host/peripheral proposal, proxied an issue of sh-sci +09:06 < wsa_> with Gen2 (SCIFA) + dmaengine, added D3/E3 support to renesas_usbhs and +09:06 < wsa_> phy-rcar-gen3-usb2, fixed gadget/udc/renesas_usb3 for E3, and confirmed the +09:06 < wsa_> eMMC suspend issue is gone in latest LTSI +09:06 < wsa_> Wolfram +09:06 < wsa_> : did organizational preparations for PeriPeriCon and SDHI-Hackfest in Edinburgh, +09:06 < wsa_> reviewed and tested various SDHI and SCIF patches, prepared another cleanup +09:06 < wsa_> series regarding dev_get_drvdata(), sent RFC to Shimoda-san's question about +09:06 < wsa_> clearing DMA in i2c-rcar, assisted Fabrizio with his I2C passthrough issue, +09:06 < wsa_> and updated his DMA talk for the ELCE conference +09:06 < wsa_> B - what I want to do until next time +09:06 < wsa_> ------------------------------------- +09:06 < wsa_> Marek +09:06 < wsa_> : wants to go to ELCE, PeriPeriCon, SDHI hackfest in Edinburgh +09:06 < wsa_> Niklas +09:06 < wsa_> : wants to attend ELCE and the SDHI hackfest +09:06 < wsa_> Shimoda-san +09:06 < wsa_> : wants to work on KVM + QEMU + USB and update information to elinux wiki +09:06 < wsa_> Simon +09:06 < wsa_> : wants to investigate RAVB no-link patches in BSP 3.7.2 +09:06 < wsa_> Wolfram +09:06 < wsa_> : wants to pick up the I2C core PM rework again, upport more patches, and +09:06 < wsa_> organize PeriPeriCon and SDHI-Hackfest in Edinburgh +09:06 < wsa_> C - problems I currently have +09:06 < wsa_> ----------------------------- +09:06 < wsa_> Marek +09:06 < wsa_> : wants to know how we can get the ATF patches into the Renesas ATF release? +09:06 < wsa_> Wolfram +09:06 < wsa_> : has a long-standing open ticket for a SCIF related susped-resume issue +09:06 < wsa_> and needs SCIF experts to look at the latest mail about it +09:07 < wsa_> about the SCIF related issue in C) +09:07 < wsa_> is Uli completely away when in the Philipines? +09:07 < wsa_> did he mention that to someone? +09:08 < wsa_> otherwise we have to just find out +09:08 < wsa_> geertu: do you have some minutes to look at it? +09:08 -!- jmondi [~jmondi@250.ip-164-132-57.eu] has quit Ping timeout: 244 seconds +09:09 < geertu> I think the SCIF driver doesn't need any suspend/resume fixes +09:09 < geertu> Uli also couldn't reproduce the issue, with and without the fix rom the BSP. +09:09 < geertu> My feeling is that the fix is just cargo-cult suspend/resume programming +09:09 < geertu> s/rom/from/ +09:09 < wsa_> okay +09:10 < wsa_> so the serial core also doesn't need a fix? +09:10 < geertu> On older SH/R-Mobile SoCs (e.g. removed sh7372/mackerel), the SoC was powered down, too. +09:10 < geertu> (but that was before my time) +09:11 < geertu> Difficult to know without testing on other non-Renesas SoCs +09:12 < wsa_> As I mentioned, if at all, it could be more the OMAP guys having problems +09:12 < geertu> IFF there's an issue, it should be fixed in the serial core, as that manages PM +09:12 < wsa_> ack +09:12 < geertu> Exactly. +09:12 < wsa_> okay, i'll mark the patches as such then +09:12 < wsa_> thanks, geert! +09:13 -!- jmondi [~jmondi@250.ip-164-132-57.eu] has joined #periperi +09:13 < Marex> so what about the atf ? +09:13 < wsa_> Marex: for your ATF upstreaming issue, we probably need Shimoda-san to be around? +09:13 < Marex> wsa_: yeah +09:13 < Marex> wsa_: for both of my ATF questions really +09:13 < Marex> wsa_: and he's having a day off today +09:14 < wsa_> who is not here, so please continue that by email +09:14 < geertu> Marex: ATF is core, not I/O +09:14 < Marex> geertu: PCI is IO +09:15 < wsa_> that is why I took only one of the ATF issues into the io report :D +09:15 < Marex> wsa_: btw I see some patches from Dirk Behme in the renesas ATF release, so it has to be possible to get patches into i +09:15 < Marex> t +09:16 < wsa_> hehe :) +09:17 < wsa_> horms: you don't have write access to the periupport repo? +09:17 < Marex> wsa_: still, while I didn't manage to trigger any other error anymore with the PCI after the ATF fix, I wonder what other dead bodies are hidden in that core, that will float up everytually +09:18 < horms> wsa_: probably I do. And I'm happy to use it if others are happy +09:18 < horms> I also wanted to ask, regarding periupport about plans to: update for recent upstreaming and BSP releases +09:18 < wsa_> horms: I am. geertu, pinchartl: what about you? +09:19 < wsa_> horms: what do you mean? +09:20 < pinchartl> what about me ? :-) +09:20 < pinchartl> happy to use periupport ? +09:20 < geertu> wsa_: I'm fine with other people updating periupport ;-) +09:20 < horms> part a) periupport seems a bit out ot date wrt to patches that have been upstreamed of late. I tried to fix some of that but it was by no means comprehensive. Are there any plans for a sweep? Tools to do so? +09:20 < wsa_> pinchartl: are you happy with Simon updating periupport by himself? +09:20 < pinchartl> sure, I have no problem with that, I don't want to be a maintainer for periupport :-) +09:21 < pinchartl> speaking of which +09:21 < horms> part b) there is a task frile for v4.14 and bsp370. Do we plan to make one for newer BSP(s), f.e. bsp380 +09:21 < pinchartl> commit eeed48e8e603359ca7a91adf2f42296e86c19488 +09:21 < pinchartl> Author: Wolfram Sang <wsa+renesas@sang-engineering.com> +09:21 < pinchartl> Date: Wed Oct 17 21:55:11 2018 +0200 +09:21 < pinchartl> v4.14: fix a bad object error +09:21 < pinchartl> -M,96592017a20ceea6b1795a52fea191e2171c8c36|54f9ffa8ee70a88e2da6bf4729ffb5dfc67d94f4 +09:21 < pinchartl> +M,96592017a20ceea6b1795a52fea191e2171c8c36|linux-next:54f9ffa8ee70a88e2da6bf4729ffb5dfc67d94f4 +09:21 < pinchartl> 54f9ffa8ee70a88e2da6bf4729ffb5dfc67d94f4 doesn't exist in linux-next as far as I can tell +09:22 < horms> r.e. push: it sounds like I should push directly, I'll do so after double checking my proposed changes +09:23 < wsa_> pinchartl: okay, i thought "linux-next" was missed because that commit is referenced as being in linux-next a few times in other places +09:23 < pinchartl> horms: git blame points to you +09:23 < pinchartl> I assume it's a commit ID from your local tree +09:24 < horms> pinchartl: thanks, I will investigate +09:24 < geertu> Probably it's been rebased +09:24 < geertu> It's also not in renesas-drivers +09:24 < pinchartl> please try to push a fix asap, as compilation is broken due to this +09:24 < horms> I think the correct commit is 55697cbb44e4 +09:24 < horms> pinchartl: ok! +09:25 < horms> do yoy mean make of periupport? +09:25 < geertu> Yep, always run "make" before pushing (also for peripelist) +09:26 < horms> I don't push but I do run make. Anyway I will fix this +09:26 < wsa_> rebasing is a problem, ulfh does it occasionally for mmc, and I can't convince him to skip it :( +09:26 < horms> Maybe make works because that commit exists in my tree? +09:26 < geertu> horms: Possibly. +09:27 < geertu> git tag --contains 54f9ffa8ee70a88e2da6bf4729ffb5dfc67d94f4 +09:27 < geertu> git branch -a --contains 54f9ffa8ee70a88e2da6bf4729ffb5dfc67d94f4 +09:27 < geertu> if no output, it will be gone after git prune and git gc +09:27 < pinchartl> git tag --contains 54f9ffa8ee70a88e2da6bf4729ffb5dfc67d94f4 | grep '^next-' +09:28 < pinchartl> if no output, not good +09:28 < geertu> I have almost all next- tags in my repo, but don't have the commit +09:29 < horms> 54f9ffa8ee70a88e2da6bf4729ffb5dfc67d94f4 is in my tree but its not related to 96592017a20ceea6b1795a52fea191e2171c8c36 +09:29 < horms> So it an error +09:29 * geertu wonders if morimoto-san thinks we already switched to winter time +09:30 < wsa_> are there any other questions from your side? +09:32 < pinchartl> no other question from me +09:32 < wsa_> okay then +09:32 < wsa_> i will keep you updated about the peripericon location +09:32 < geertu> PeriPeriEdi I/O agenda topics? +09:33 < wsa_> for sure, overview + high level "what happened since last f2f meeting" + is the group happy +09:34 < wsa_> more technical stuff will likely be dealt at the SDHI hackfest +09:34 < wsa_> but I'll think about it some more +09:34 < wsa_> and am welcoming suggestions +09:34 < pinchartl> when will the I/O and Core meetings be held in Edinburgh ? +09:35 < geertu> IIRC, discussing the agenda was the main reason to have a meeting today ;-) +09:35 < geertu> On Fri? +09:35 < pinchartl> I mean at what time ? +09:36 < wsa_> my proposal would be like super short per-group discussions at the beginning to have max time for the process presentation? +09:36 < geertu> sounds good to me +09:38 < wsa_> I am negotiating for the room a schedule of +09:38 < wsa_> 09-13 meeting part1 +09:38 < wsa_> 13-14 lunch break (lunch included) +09:38 < wsa_> 14-18 meeting part2 +09:39 < wsa_> it will hopefully be here +09:39 < wsa_> https://www.themeltingpotedinburgh.org.uk/venue-hire-in-edinburgh/ +09:39 < pinchartl> will lunch be onsite ? +09:39 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi +09:39 < geertu> On Tursday, they have Open Day ;-) +09:39 -!- patersonc [c18ddb24@gateway/web/freenode/ip.193.141.219.36] has joined #periperi +09:40 < morimoto> sorry for late +09:40 < geertu> morimoto: Mornin' +09:40 < morimoto> Hi +09:41 < wsa_> pinchartl: yes +09:41 < Marex> morimoto: good morning ! +09:41 < morimoto> Hi Marex +09:41 < pinchartl> wsa_: ok. otherwise one hour would have been too short +09:41 < pinchartl> (it might still be even if it's onsite) +09:42 < wsa_> pinchartl: and I got a recommendation for a steak restaurant from a local, so morimoto-san should be happy ;) +09:42 < wsa_> and they have vegetarian options, so jacopo should be happy +09:42 < wsa_> I hope it will make all of you happy :D +09:43 < morimoto> I can be happy (^o^) +09:43 < wsa_> hi morimoto-san :) +09:44 < wsa_> so, any more questions? +09:44 < morimoto> Hi wsa_: sorry for my late +09:44 * wsa_ prepares to give the mic to geert... +09:44 < wsa_> morimoto: no worries... +09:45 < Marex> morimoto: who's coming from japaperi ? +09:45 < wsa_> geertu: aaaaannd here you have it +09:45 < wsa_> Thanks everyone for this meeting! +09:45 < morimoto> Marex: to ELCE ? +09:45 < Marex> jupp +09:45 < morimoto> Marex: me, Ito-san +09:45 < geertu> And to the PeriPeri meeting... +09:45 < morimoto> No Magnus, No Shimoda-san +09:45 < Marex> morimoto: OK, got it :) +09:45 < patersonc> wsa_ Scottish karaoke you say? +09:46 < geertu> morimoto: Will Ito-san join the periperi meeting? +09:46 < geertu> I guess Munakata-san will be present at ELC-E, too? +09:46 < morimoto> I you want to, I can ask to him. So far I didn't ask +09:46 < morimoto> s/I/If/ +09:47 < wsa_> morimoto: ah, ito-san, too? then 10 people +09:47 < morimoto> wsa_: after PeriPeriCon ? +09:47 < wsa_> hmmm +09:48 < morimoto> Then, let's ask to him to join it. +09:48 < morimoto> wsa_: So far, not yet asked +09:48 < wsa_> yeah, please let me know if Ito-san wants to join a) the periperi meeting and/or b) the dinner afterwards +09:48 -!- neg [~neg@unaffiliated/neg] has quit Read error: Connection reset by peer +09:48 -!- neg [~neg@unaffiliated/neg] has joined #periperi +09:48 < morimoto> He is now other business trip. maybe for AGL ? +09:49 < wsa_> just so I have the number of people when reserving +09:49 < morimoto> I will ask to him, but will be later +09:49 < wsa_> (although +/- 1 shouldn't be a huge issue) +09:49 < wsa_> patersonc: haha, that would probably be a pub with a live band :D +09:50 < geertu> AGL All Member Meeting +09:50 < geertu> October 17-18. 2018 +09:50 < wsa_> not very far from here +09:50 < patersonc> wsa_: Looking forward to it :P +09:50 < Marex> AGL AMM sounds great! +09:51 < Marex> I heard great things about that +09:51 < Marex> morimoto: btw the new BSP with mainline U-Boot is really happening ? +09:52 < geertu> Shall I start? +09:52 < morimoto> Marex: please wait +09:52 < wsa_> geertu: i think so diff --git a/wiki/Chat_log/20181018-mm-chatlog b/wiki/Chat_log/20181018-mm-chatlog new file mode 100644 index 0000000..894fc25 --- /dev/null +++ b/wiki/Chat_log/20181018-mm-chatlog @@ -0,0 +1,251 @@ +Multimedia-chat-meeting-2018-10-18 + +11:02 < pinchartl> welcome to the multimedia meeting +11:02 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +11:02 < pinchartl> * Jacopo +11:02 < pinchartl> Since last meeting: +11:02 < pinchartl> - Mostly review (v4l2-mux, gmsl v3, some other media related patches) +11:02 < pinchartl> - Slides and talk preparation for ELC-E +11:02 < pinchartl> - Some patches to periupport +11:02 < pinchartl> Until next meeting: +11:02 < pinchartl> - ELC-E +11:02 < pinchartl> - Get an E3 from Laurent and start looking into the CSI-2 issue +11:02 < pinchartl> - Resume adv748x work (dynamic channel configuration) +11:02 < pinchartl> Issues and Blockers: None +11:02 < pinchartl> jmondi: any comment ? +11:03 < jmondi> not really +11:03 < pinchartl> thanks +11:03 < pinchartl> * Kieran +11:03 < pinchartl> Since last meeting: +11:03 < pinchartl> - GMSL rebase for renesas-drivers (conflicts with async/fwnode/csi2 changes) +11:03 < pinchartl> - VIN circular locking dependency report +11:03 < pinchartl> - Working on partition algorithm phases and overlaps +11:03 < pinchartl> Until next meeting: +11:03 < pinchartl> - ELCE +11:03 < pinchartl> - Aim to get pa-phase work out +11:03 < pinchartl> - Look at KUnit for testing! Looks interesting (to me?) +11:03 < pinchartl> Issues and blockers: None +11:03 < pinchartl> kbingham: any comment ? +11:03 < kbingham> Nope :) +11:03 < pinchartl> thanks +11:03 < pinchartl> * Laurent +11:03 < pinchartl> Since last meeting: +11:03 < pinchartl> - More patch review +11:03 < pinchartl> - Submitted multimedia additional tasks for Q4 +11:03 < pinchartl> - Miscellaneous DU fixes +11:03 < pinchartl> - BSP upport (periupport updates) +11:03 < pinchartl> - FCNL reserved memory areas discussions (see Marek's ATF work) +11:03 < pinchartl> Until next meeting: +11:03 < pinchartl> - More patch review +11:03 < pinchartl> - Finalize multimedia additional tasks for Q4 +11:03 < pinchartl> - Attend ELC-E, Linux media summit and peripericon +11:03 < pinchartl> - Get GMSL patches merged +11:03 < pinchartl> Issues and blockers: None +11:03 < pinchartl> any question ? +11:04 < pinchartl> ah, and I forgot to mention that I've reviewed the DS90x9xx patches (FPD-Link III serializers and deserializers) +11:05 < kbingham> Well yes, I could have put some FPD-Link III in my "since last meeting" section too :) +11:05 < pinchartl> I'll add that +11:05 < pinchartl> * Morimoto-san +11:05 < pinchartl> Since last meeting: +11:05 < pinchartl> - Continued work on TDM sound on StarterKit + KingFisher +11:05 < pinchartl> - Solved codec driver issue on cold-boot, it needed clock switching. +11:05 < pinchartl> - Solved codec kctrl settings issue, few register needed clocks. +11:05 < pinchartl> - Solved clock switching, used gpio-mux-clock. +11:05 < pinchartl> - Solved TDM issues, SSI driver needed few bugfix patches. +11:05 < pinchartl> All patches have been posted to the ALSA mailing list. +11:05 < pinchartl> Until next meeting: +11:05 < pinchartl> - Continue work on TDM sound on StarterKit + KingFisher +11:05 < pinchartl> Expanded sound card and BUSIF detail control are needed, will work on them +11:05 < pinchartl> next. +11:05 < pinchartl> morimoto: any comment ? +11:05 < morimoto> No comment, but I would say I'm looking forward to see you in ELCE :) +11:06 < pinchartl> :-) +11:06 < pinchartl> I think we all are +11:06 < pinchartl> * Niklas +11:06 < pinchartl> Since last meeting: +11:06 < pinchartl> - [PATCH v2 0/3] rcar-vin: add support for UDS (Up Down Scaler) +11:06 < pinchartl> - [PATCH v2 0/5] i2c: adv748x: add support for CSI-2 TXA to work in 1-, 2- and +11:06 < pinchartl> 4-lane mode +11:06 < pinchartl> - [PATCH] v4l2-ioctl: fix CROPCAP type handling +11:06 < pinchartl> - Tested CEC patches for Koelsch and it now works +11:06 < pinchartl> Until next meeting: +11:06 < pinchartl> - Post v3 of adv748x 1-, 2- and 4-lane mode +11:06 < pinchartl> - Attend multimedia summit during ELCE +11:06 < pinchartl> Issues and blockers: None +11:06 < pinchartl> neg isn't here +11:06 < pinchartl> * Simon +11:06 < pinchartl> Since last meeting: +11:06 < pinchartl> - E3 Audio now working, patches posted +11:06 < pinchartl> Until next meeting: +11:06 < pinchartl> - Follow up on above as necessary +11:06 < pinchartl> Issues and blockers: None +11:06 < pinchartl> horms: any comment ? +11:06 < neg> I'm back just in time it seems :-) No comment +11:07 < pinchartl> neg: welcome back ! +11:07 < neg> thanks, sorry for the conflict +11:08 < horms> pinchartl: none, I had issues with E3 Audio. Morimoto's guidance helped me fix them. No problems at this time +11:08 < horms> Let me know if you want any upporting done :) +11:08 < morimoto> horms: good to know :) +11:08 < pinchartl> sure :-) +11:09 < pinchartl> I'm marking patches as 'MM upstreaming candidates' in periupport, feel free to pick them if you want +11:09 < pinchartl> there's nothing particularly urgent so far +11:09 < pinchartl> the pinctrl and DT integration commits are good candidates for non-urgent upporting +11:11 < pinchartl> Ulrich isn't here, did he say he would miss this meeting ? the last I heard was "prepare for stay in the Philippines until Dec 10" two weeks ago, but I don't know if that means holidays or working under the sun +11:11 < wsa> pinchartl: same question here +11:11 < pinchartl> wsa: I thus assume you don't know the answer :-) +11:11 < pinchartl> geertu: damm: any info ? +11:12 < geertu> pinchartl: I don't know. +11:12 < pinchartl> ok +11:13 < geertu> His "tips-and-tricks to use free Wifi effectively" may not be applicable to the Philippines ;-) +11:13 < pinchartl> :-D +11:13 < pinchartl> on the topic of periupport +11:14 < pinchartl> morimoto: in the bsp370 ticket file, you have marked lots of commits with a reference to previous BSP releases +11:14 < pinchartl> if I update a commit in the v4.14 file, should I update the corresponding commit in bsp370, or leave the reference ? +11:15 < morimoto> uhm +11:15 < morimoto> Basically there are no conflict commits between v4.14 vs bsp370 +11:15 < morimoto> But, you had it ? +11:16 < pinchartl> it's not a matter of conflicts +11:16 < pinchartl> for instance +11:16 < morimoto> sorry, not conflicts, duplicate +11:16 < pinchartl> commit 543637cb084774608dc67144be0ac0ae9e534350 +11:16 < pinchartl> is +11:16 < pinchartl> in bsp370 +11:16 < pinchartl> N,543637cb084774608dc67144be0ac0ae9e534350|requested upport with f7cac36f6d7862f93a12cfb8d4d0d9b47f132179 of BSPv3.6.0 +11:17 < pinchartl> what should I do with that ? +11:17 < pinchartl> not touch it because it's marked N ? +11:17 < morimoto> Ahh, please ignore "N" commit. +11:17 < morimoto> Mainly, we need latest ticket only. so, bsp370 +11:18 < morimoto> is important to Renesas +11:19 < pinchartl> hmmmm... +11:19 < wsa> Yet, 'N' is all the Ebisu upporting for example (enablement of SCIF, I2C, for example) +11:19 < wsa> we surely want that, or? +11:19 < morimoto> on bsp370 ? +11:20 < morimoto> pinchartl: sorry, what is wrong ? +11:20 < pinchartl> another example +11:20 < pinchartl> in bsp370 +11:20 < pinchartl> N,068d08088b263a2c037656ea9668f8bb2be3d046|requested upport with 6ea68fc0ce880bdfa511b45b8e7ace42303c71e5 of BSPv3.6.0 +11:21 < pinchartl> and in v4.14 +11:21 < pinchartl> M,6ea68fc0ce880bdfa511b45b8e7ace42303c71e5 +11:21 < pinchartl> have you marked it as N in bsp370 because you expect it to be upported from v4.14 ? +11:22 < morimoto> Oops, I misunderstood... +11:23 < morimoto> BSP team is thinking that they avoid duplicate request +11:23 < morimoto> It seems +11:24 < morimoto> We need to avoid N, and care about M/H on both v4.14 and bsp370 +11:24 < morimoto> Renesas inside doesn't matter about "N", but counting how many patch are upported +11:24 < morimoto> (= for L/M/H) +11:25 < pinchartl> ok +11:25 < horms> Ok, so for KPI N is irrelevant +11:25 < horms> I asked this a bit earlier, but is there a plan to produce bsp380 ? +11:25 < pinchartl> wouldn't it have been better to mark the commit as N in v4.14 and as M bsp370 ? +11:25 < pinchartl> that way the latest BSP ticket file would contain most of the work to be done +11:26 < morimoto> pinchartl: it is good idea. thanks +11:26 < pinchartl> similarly to when you post a v2 of a patch, v1 is marked as superseded and everybody forgets about it +11:27 < pinchartl> so how should we handle this ? does anyone have a magic script to reconcile everything ? :-) +11:28 < morimoto> I can't use magic :( +11:28 < horms> is it against company policy? +11:29 < morimoto> horms: is it question to me ? +11:29 < horms> morimoto: sorry, it was a joke about magic. +11:29 < pinchartl> I'll try to write a script to handle this +11:30 < pinchartl> morimoto: thanks for the feedback +11:30 < morimoto> horms: yeah, it is joke my side too :) +11:30 < pinchartl> Topic 2. Discussions +11:30 < horms> morimoto:) +11:30 < pinchartl> Marex: you've requested a discussion about FCNL +11:30 < pinchartl> we've already discussed the topic, is there something you would like to add ? +11:32 < morimoto> pinchartl: Marex: I think you had question about it to BSP team, but 1) they don't know detail, because it is used by 3rd party 2) related guy already go back to home today. So please send me question mail, I can forward it to BSP/3rd party, and feedback to you. +11:34 < wsa> horms: what is KPI? +11:34 < pinchartl> while waiting for Marex, does anyone have any other topic they would like to discuss ? +11:34 < pinchartl> wsa: Key Performance Indicator +11:34 < Marex> pinchartl: let +11:34 < wsa> thanks +11:35 < morimoto> wsa: KPI = key performance indicator +11:35 < Marex> pinchartl: let's postpone FCNL until we have DT support in ATF ? :) +11:35 < Marex> pinchartl: and until the FCNL is sorted out in Linux too ? +11:35 < neg> I would only like to ask if anyone wish me to prepare or bring something specail to facilitate MM work during ELCE. As we talked about E3 testing maybe there is something else? +11:35 < Marex> morimoto: would Takuya Sakata-san be willing to discuss ATF with me ? :) +11:36 < morimoto> hmm.. I don't know him... +11:36 < morimoto> discuss by what ? mail ? +11:36 < Marex> morimoto: jupp, email +11:36 < Marex> morimoto: I'd like to send him some ATF patches +11:36 < Marex> morimoto: OK, I'll just send him the patches :) +11:37 < wsa> pinchartl: I think I can brush up my 'transfer upporting info from ticket x to ticket y' script to transfer the old prio if the new one is 'N' +11:37 < morimoto> Marex: OK, please do +11:37 < pinchartl> Marex: but please keep FCNL support in your ATF patch series +11:38 < Marex> pinchartl: but the bindings are not fleshed out yet and I don't want them to become ABI +11:39 < pinchartl> wsa: that would be nice, as I was thinking about writing such a script :-) my idea is roughly if (new prio == N and comment == reference to old commit) { copy old commit prio and comment to new commit; set old prio to N and comment to reference new commit } +11:39 < pinchartl> wsa: do you think you could do that ? +11:39 < pinchartl> it would be useful to commit the script to the repo too +11:40 < pinchartl> Marex: you don't have to upstream it yet, but I'd like the patches to be included in the series, in order to make sure that the proposal will work +11:40 < pinchartl> would that be OK with you ? +11:40 < Marex> I do keep the patch, it's not like I threw it away +11:40 < wsa> pinchartl: I'll try +11:41 < wsa> and let you all know :) +11:41 < pinchartl> Marex: thanks :-) +11:41 < pinchartl> wsa: thanks +11:41 * Marex wonders if we can generate FDT at compile time ... :-) +11:41 < Marex> I guess we can +11:41 < pinchartl> Marex: interesting idea +11:41 < Marex> pinchartl: we can ... +11:42 < pinchartl> so if there's no more discussion topic, +11:42 < pinchartl> Topic 3. Additional Tasks for Q4 +11:42 < pinchartl> The following additional tasks have been submitted and approved, they are now going through the usual process. SoWs should be sent in the near future, with a 12/M due date. +11:42 < pinchartl> * ADV748x Dynamic Routing (Jacopo) +11:42 < pinchartl> * M3-N rotation bug fix (Kieran) +11:42 < pinchartl> * Fix RGB output routing on D3 and E3 (Laurent) +11:42 < pinchartl> * Upporting and addition of pixel format (Niklas) +11:42 < geertu> Marex: if we know the parameters at compile-time, we can +11:42 < pinchartl> any question/comment ? +11:43 < neg> Looks good to me +11:43 < Marex> geertu: but then why should it be part of ATF ? We can have the bootrom load the DT +11:43 < jmondi> fine with me, thanks +11:44 < kbingham> Sounds OK to me. +11:44 < geertu> Marex: ATF programs the DRAMC +11:44 < Marex> geertu: but the programming of that is given to ATF by the integrator +11:44 < pinchartl> next, Topic 4. Face to Face Meeting in Edinburgh +11:44 < Marex> geertu: it's literally a few C macros +11:45 < pinchartl> I don't think we should spend time discussing status updates there, as there will not be much +11:45 < pinchartl> are there any particular topic that team members would like to discuss face to face ? +11:45 < kbingham> There's going to be a v4l2 codec meeting at ELCE +11:45 < pinchartl> correct +11:46 < kbingham> But from previous attempts at suggesting codec work - I assume renesas has little interest? +11:46 < neg> Potential plan and for unified DU and VIN test suite :-) +11:46 < kbingham> ^ Plus automated testing, + unit testing :) +11:47 < morimoto> interesting topic for test team +11:47 < pinchartl> kbingham: I wouldn't expect Renesas to have any new interest all of a sudden, but if you can think about a strategy to make them change their mind, I'd love to discuss that +11:50 < kbingham> pinchartl, well that depends on what their concerns are regarding the codecs. Whether it's keeping firmware out - or just completley hiding the implementation altogether. But once there is a standard API for codecs - It would be silly not to use it - and it seems unfortunate not to be part of those early designs +11:50 < pinchartl> I would like to also briefly discuss the GMSL and FPD-Link plans +11:50 < kbingham> Yes :) +11:51 < pinchartl> kbingham: I'll add codecs to the agenda, we can then spend some time discussing how to report the ongoing V4L2 codecs API developments to Renesas +11:51 < pinchartl> any other topic ? +11:52 < jmondi> not from here, thanks +11:52 < kbingham> Dont think so ... +11:53 < neg> not from me +11:53 < morimoto> not from me too +11:53 < morimoto> s/too/either/ +11:55 < pinchartl> ok, thanks +11:55 < pinchartl> in that case +11:55 < pinchartl> Topic 5. Next Meeting +11:55 < pinchartl> two weeks from now ? +11:56 < pinchartl> three weeks from now ? +11:56 < pinchartl> four weeks from now ? :-) +11:56 < pinchartl> geertu: wsa: ^^ +11:56 < morimoto> * PeriPeri: chat: Chat meeting 18Q4-B +11:56 < morimoto> +11:56 < morimoto> date: 2018-11-08 +11:56 < morimoto> +11:56 < morimoto> I/O: 08:00 BST / 09:00 CEST / 10:00 EEST / 16:00 JST +11:56 < morimoto> Core: 08:30 BST / 09:30 CEST / 10:30 EEST / 16:30 JST +11:56 < morimoto> MM: 09:00 BST / 10:00 CEST / 11:00 EEST / 17:00 JST +11:56 < wsa> geertu already wrote 8.11. and I think this is good +11:56 < morimoto> +11:56 < wsa> let's check what we agreed with dammsan +11:57 < geertu> pinchartl: That's the date from Morimoto-san's calendar +11:57 < wsa> we agreed that with dammsan +11:57 < pinchartl> ok, 3 weeks from now +11:57 < pinchartl> wsa: indeed +11:58 < pinchartl> that's all for today +11:58 < pinchartl> I propose adjourning the meeting +11:58 < pinchartl> does anyone second ? +11:58 < wsa> ack +11:59 < morimoto> 2nd +11:59 < pinchartl> meeting adjourned, thank you all for attending ! diff --git a/wiki/Chat_log/20181108-core-chatlog b/wiki/Chat_log/20181108-core-chatlog new file mode 100644 index 0000000..a3ac50b --- /dev/null +++ b/wiki/Chat_log/20181108-core-chatlog @@ -0,0 +1,60 @@ +Core-chat-meeting-2018-11-08 + +09:41 < geertu> Welcome to today's core group chat! +09:41 < geertu> Agenda: +09:41 < geertu> 1. Status Updates +09:41 < geertu> 2. Discussion Topics +09:41 < geertu> Topic 1. Status updates +09:42 < geertu> A) What have we done since last time: +09:42 < geertu> Jacopo worked on VIN PFC. +09:42 < geertu> Marek worked on U-Boot (HS200/SDR104 etc., M3-W MMU init fix), +09:42 < geertu> Linux (E3 SCIF2 PFC upport, SDHI), and ATF (PCIe L1 workaround +09:42 < geertu> improvement). +09:42 < geertu> Morimoto-san attended ELCE and PeriPeriCon. +09:42 < geertu> Shimoda-san says Renesas Vietnam finished testing LTSI v4.14 +09:42 < geertu> succesfully. He also reviewed Magnus' IPMMU plan, submitted USB3.0 +09:42 < geertu> peripheral patches, and reviewed E3 SDHI DTS and PFC patches. +09:42 < geertu> Simon posted and merged IPMMU enablement on E3. +09:42 < geertu> Ulricht reviewed VIN PFC patches. +09:42 < geertu> Geert attended ELC-E, Automated Testing Summit, and PeriPeri EDI, +09:42 < geertu> enjoined holidays, and investigated an IOMMU regression in v4.20-rc1. +09:43 < geertu> B) What we plan to do till next time: +09:43 < geertu> Kaneko-san plans to enable E3 PMIC support. +09:43 < geertu> Marek plans to work on U-Boot (upstreaming SDHI, investigating HS400 +09:43 < geertu> performance mysteries) and Linux (upporting of E3 PCI, DVFS I2C and +09:43 < geertu> PMIC, PCA953x suspend/resume support for Salvator-XS SATA). +09:43 < geertu> Shimoda-san plans to continue to make an IPMMU driver's plan with +09:43 < geertu> Magnus-san. +09:43 < geertu> Simon will address review of E3 and Ebisu I2C patches. +09:43 < geertu> Ulricht plans to review more patches. +09:43 < geertu> Geert will rework the move of SoC-specific ARCH_* symbols and generic +09:43 < geertu> reset support for VFIO platform, and plans to continue digesting SYSC +09:43 < geertu> and PFC errata. +09:44 < geertu> C) Problems we have currently: +09:44 < geertu> Simon wonders about E3 IIC lacking ICSTART and its impact on DTS +09:44 < geertu> upporting, and informs that Kaneko-san's D3 Thermal upport is stuck on +09:44 < geertu> the mailing list. +09:44 < geertu> Ulrich is suffering from physiological and technological illness in the +09:44 < geertu> Philippines. +09:44 < geertu> Anything I missed? +09:45 < Marex> geertu: HS400 performance mystery is half-way solved, only 4tap part remains +09:45 < horms> wsa: sorry, i was mia. back now +09:45 < geertu> ok +09:48 < geertu> Topic 2. Discussion Topics +09:48 < geertu> Anything to discuss? +09:52 < Marex> geertu: I kinda hoped shimoda-san would show up, so we can discuss the cache issues, but he seems absent +09:52 < wsa> he has a day off +09:52 < geertu> Marex: Yes, he has a holiday +09:52 < Marex> geertu: but we can discuss that via email +09:52 < Marex> :) +09:54 < Marex> geertu: maybe you wanna tell us about the testing summit ? +09:54 < geertu> Marex: That already happened, twice +09:54 < pinchartl> :-) +09:55 < Marex> geertu: no record ? :) +09:55 < geertu> https://elinux.org/ATS_2018_Minutes +09:55 < horms> geertu: I had access to the H3 ES3.0 in Magnus's farm at one point. But it was withdrawn as it was needed by someone else. I imagine you could ask for access. +09:56 < geertu> damm: Is your farm operational again? +09:56 * geertu means the board farm, not the human farm +09:58 < pinchartl> if there's no more topic to be discussed, I'll take the mic +09:58 < geertu> ok +09:58 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20181108-io-chatlog b/wiki/Chat_log/20181108-io-chatlog new file mode 100644 index 0000000..41e5c91 --- /dev/null +++ b/wiki/Chat_log/20181108-io-chatlog @@ -0,0 +1,150 @@ +09:02 < wsa> again, welcome everyone. IO meeting time now +09:02 < wsa> status updates: +09:02 < wsa> Status updates +09:02 < wsa> ============== +09:02 < wsa> A - what have I done since last time +09:02 < wsa> ------------------------------------ +09:02 < wsa> Kaneko-san +09:02 < wsa> : upported I2C, SCIF, HSICF enablement for E3 +09:02 < wsa> Marek +09:02 < wsa> : upported SCIF2 pinmux patches, SDHI patches for E3 and submitted V2 for +09:02 < wsa> the PCIe L1 ATF workaround +09:02 < wsa> Niklas +09:02 < wsa> : (did various SDHI patches to enable HS400 but missed to send in his report) +09:02 < wsa> Shimoda-san +09:02 < wsa> : fixed remove function of SCIF driver and investigated an issue for USB3.0 +09:02 < wsa> peripheral with E3 +09:02 < wsa> Ulrich +09:02 < wsa> : reviewed two SCIF patches +09:02 < wsa> Wolfram +09:02 < wsa> : organied and participted in SDHI hackfest, imported periupport priorities to +09:02 < wsa> latest ticket file, picked up TDSEL and WDT patches again, reviewed lots of +09:02 < wsa> SDHI patches and some general PM rework, updated periupport, and started to +09:02 < wsa> pick up I2C core PM rework again +09:02 < wsa> B - what I want to do until next time +09:02 < wsa> ------------------------------------- +09:02 < wsa> Geert +09:02 < wsa> : wants to resubmit fixes for fallback to PIO in the sh-sci driver +09:02 < wsa> Kaneko-san +09:02 < wsa> : wants to upport HSCIF, PWM, and PCIE for E3 +09:02 < wsa> Marek +09:02 < wsa> : wants to continue on PCI, DVFS I2C and PMIC upporting for E3 and PCA953x +09:02 < wsa> suspend/resume support +09:02 < wsa> Shimoda-san +09:02 < wsa> : wants to fix the USB3.0 issue for E3 and investigate a USB related reset +09:02 < wsa> issue for Gen2 +09:02 < wsa> Simon +09:02 < wsa> : wants to investigate RAVB no-link patches in BSP 3.7.2 +09:02 < wsa> Ulrich +09:02 < wsa> : wants to continue reviewing patches +09:02 < wsa> Wolfram +09:02 < wsa> : wants to continue I2C core PM rework and upport BSP patches +09:02 < Marex> wsa: clock +09:03 < wsa> C - problems I currently have +09:03 < wsa> ----------------------------- +09:03 < wsa> Shimoda-san: +09:03 < wsa> asks for documentation introducing to virtualization +09:03 < wsa> Simon: +09:03 < wsa> has D3 thermal support tested but patches stuck on upstream mailing list +09:03 < wsa> my questions: +09:04 < wsa> horms: I assume the IIC issue with ICSTART are resolved now? +09:04 < wsa> horms: any plan when you can start working on the RAVB no-link patches? +09:05 < wsa> Marex: did you coordinate your E3 upporting work with someone? I mean it is great to see progress there, but there is work assigned to Kaneko-san already and I'd like to avoid duplication of work... +09:06 < Marex> wsa: I checked with geertu, he said it was OK +09:06 < Marex> wsa: I was concerned about Kaneko-san, yes +09:07 < Marex> wsa: is the PCI/I2C/PMIC task assigned ? +09:08 < wsa> Marex: Good, thanks! I will check with geertu then how to handle this in the future... +09:08 < wsa> PCIE and IIC is, PMIC not +09:08 < geertu> Marex: i2c was not mentioned in last's IO meeting report, PMIC was for core +09:09 < wsa> It probably makes sense to combine IIC and PMIC +09:09 < wsa> to you +09:09 < geertu> I've been running with iic and pmic enabled on e3 +09:09 < wsa> It is a grey area, I think, because PFC is core and I2C itself is IO +09:09 < geertu> iic works +09:10 < geertu> pmic is blocked by Ebisu firmware not supporting s2ram on the 4D variant yet +09:10 < geertu> Else I would have had submitted it myself the week I got the board. +09:10 < wsa> so, not much harm done (I think), but a sign to install some communication between geert and me here +09:12 < wsa> I also think it would make sense to assign PCIE to Marex but we also need work for Kaneko-san +09:12 < wsa> I will check this when I update the lists after the meeting +09:12 < wsa> horms: is this all OK with you? +09:12 < Marex> wsa: OK +09:12 < geertu> Can Kaneko-san test his work on some board now? +09:12 < geertu> Apparently his last PFC patch was not even compile-tested +09:12 < Marex> wsa: I tested the PCIe on Ebisu 4D already +09:13 < Marex> wsa: so I can roll out the patch right away +09:13 < wsa> neg: you there? +09:13 < wsa> Marex: heh +09:15 < wsa> I also wonder about Jinso sending thermal patches... +09:16 < wsa> why exactly this driver? :) +09:16 < wsa> damm: do you know about this? +09:16 < damm> nope sorry +09:17 < wsa> pity neg seems not here, too +09:17 < wsa> neither he sent a report, I hope he is well +09:17 < Marex> wsa: probably on his way to Canada ? +09:17 < Marex> wsa: so anyway, I'll wait with the PCIe patches ? +09:18 < geertu> He said his mail and git trees will be cut off for a week by its hosting provider, perhaps that has already started, and caused more damage than expected? +09:18 < wsa> Marex: yes, but probably just until this evening +09:18 < wsa> just until I updated all my lists +09:18 < Marex> wsa: got it, will do +09:19 < wsa> Marex: thanks +09:20 < wsa> so, the updated periupport list with imported priorities... +09:20 < wsa> morimoto: are you okay with this (in general)? +09:20 < wsa> geertu: did you have a chance to look at it? +09:20 * morimoto talking with our Boss now +09:21 < wsa> I would be nice to merge it rather soonish, I'd think. pinchartl and my updates are already depending on it... +09:22 < wsa> pinchartl: thanks for the prompt review! +09:22 < geertu> wsa: I only had a brief look. +09:23 < wsa> Marex: did the HS400 clock fix from this night also fix the HS400 issue in Linux then? +09:23 < geertu> I did do some auto-updates and fixed obsolete linux-next references +09:23 < wsa> geertu: before or after the conversion? +09:24 < Marex> wsa: no, I'm still seeing that and I'm not sure why +09:24 < Marex> wsa: I have a hypothesis, but I need to test it +09:24 < geertu> wsa: on master +09:25 < wsa> Marex: which hypothesis? +09:25 < morimoto> wsa: basically I have no objection (= for periupport) +09:25 < Marex> wsa: that it has to do somehow with the board physical properties, possibly temperature +09:25 < wsa> Marex: there are HS400 related patches in the latest BSP dealing with temperature +09:26 < Marex> wsa: I have very little samples to support the hypothesis, but the HS400 worked in Linux if I cold started the board after some idle period +09:26 < Marex> wsa: on the next reboot or power cycle, it failed +09:26 < Marex> wsa: even if I waited a bit to discharge the caps +09:27 < Marex> thus, I suspect temperature, but like I said, I have very little samples to support this +09:27 < Marex> I need to test more +09:27 < wsa> +09:27 < wsa> Since Gen3 SDHI has a internal DS signal AC-spec violation in HS400 mode, +09:27 < wsa> CRC-error may occur in read command. It is only HS400 mode. +09:27 < wsa> This phoenomenon occurs at low/High temperature. +09:27 * wsa wonders about Marex room temperature ;) +09:29 < wsa> geertu: do you want to have time for another look at the periupport changes? +09:30 < Marex> wsa: I saw that patch +09:30 < Marex> wsa: I rather wonder if this has to do with the CPU heating up the board, or itself +09:30 < wsa> Marex: sure, was j/k +09:30 < geertu> wsa: I'll have a closer look +09:31 < geertu> (using the pre-commit hook or make patch ;-) +09:31 < Marex> wsa: I suspect that violation is also present on older Gen3s and that results in the 4TAP 400MHz SDnH limitation ? +09:31 < wsa> geertu: ok, let me know what you think by mail then. Thanks! +09:32 < Marex> wsa: but then I wonder if on 4tap SoCs, the performance in the HS400 mode is worse than on 8tap SoC ... +09:33 < wsa> Marex: my gut feeling is there is some bigger thing going wrong, but it's all speculation +09:33 < wsa> and not terribly important why exactly there are 4 taps +09:33 < Marex> wsa: the thing is, when I configured the clock correctly for the 8tap/HS400, the raw read performance almost doubled ... +09:34 < Marex> wsa: so I wonder if on 4tap SoCs, the read performance in HS400 would be lower than on 8tap SoC +09:34 < wsa> Marex: I expect the 4tap performance to be worse than 8tap +09:34 < wsa> but as long as it is > HS200... +09:35 < Marex> wsa: it was exactly equal for me +09:35 < Marex> wsa: but I need to revisit the 4tap case +09:35 < wsa> AFAICS there is not much we can do, and the focus should be the latest ES version anyhow +09:36 < wsa> neg did a chart +09:36 < Marex> wsa: right, the scratchpad +09:36 < geertu> Who has access to H3 ES3.0? +09:37 < Marex> geertu: I had it in my hands once +09:37 < wsa> neg had a slight increase on H3 ES2.0. that matches my experiences +09:37 * wsa notes to update the chart with his results +09:38 < wsa> okay, are there questions from your side +09:38 < wsa> ? +09:39 < wsa> sadly, no responses from horms about questions to him. Simon, if you read this later, please respond by mail to periperi +09:39 < Marex> wsa: on H3, I had 170MB/s in both HS200 and HS400, so no increase for me :( +09:40 < Marex> wsa: but I suspect 200 MB/s might be the limit for 4tap configs +09:40 < wsa> let's update the table and continue the discussion by mail, too +09:40 < Marex> wsa: sounds good +09:40 < wsa> Marex: thanks! +09:41 < wsa> let's get to the core now :) +09:41 < wsa> geertu: have fun! diff --git a/wiki/Chat_log/20181108-mm-chatlog b/wiki/Chat_log/20181108-mm-chatlog new file mode 100644 index 0000000..e622f42 --- /dev/null +++ b/wiki/Chat_log/20181108-mm-chatlog @@ -0,0 +1,173 @@ +Multimedia-chat-meeting-2018-11-08 + +09:59 < pinchartl> welcome to the multimedia meeting :-) +09:59 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +09:59 < pinchartl> * Jacopo +09:59 < pinchartl> Since last meeting: +09:59 < pinchartl> - ELC-E +09:59 < pinchartl> - E3 HDMI+CVBS upstreaming +09:59 < pinchartl> [PATCH v4 0/6] media: rcar-vin: Add support for R-Car E3 +09:59 < pinchartl> - adv748x, GMSL and misc media patches review +09:59 < pinchartl> Until next meeting: +09:59 < pinchartl> - adv748x power management +09:59 < pinchartl> - adv748x dynamic routing +09:59 < pinchartl> Issues and Blockers: None +09:59 < pinchartl> jmondi: any comment ? +10:00 < kbingham> Wait - what? MM starting before 9am ? +10:00 < kbingham> :D +10:00 < jmondi> not really +10:00 < pinchartl> :-) +10:00 < pinchartl> thanks +10:00 < pinchartl> kbingham: as you're awake +10:00 < pinchartl> * Kieran +10:00 < pinchartl> Since last meeting: +10:00 < pinchartl> - ELCE +10:00 < pinchartl> - Presented/discussed Fault Tolerant V4L2 at Media-Summit +10:00 < pinchartl> - #PeriPeri-Edinburgh +10:00 < pinchartl> - PeriJect YAML validation schema development +10:00 < pinchartl> - GMSL v4 posted. <review comment from Rob on bindings> +10:00 < pinchartl> - GMSL discussions with Luca Ceresoli +10:00 < pinchartl> Until next meeting: +10:00 < pinchartl> - Linux Plumbers Conference (Canada from 10th to 20th November) +10:00 < pinchartl> Issues and blockers: None +10:00 < pinchartl> any comment ? +10:01 < kbingham> Please add " - M3N Rotation bug." to my B: as I will work on it some +10:01 < kbingham> Additional tasks take priority right :) +10:01 < pinchartl> :-) +10:01 < pinchartl> done +10:01 < pinchartl> you reported the following two tasks last time, should they still be listed ? +10:01 < pinchartl> - Aim to get pa-phase work out +10:01 < pinchartl> - Look at KUnit for testing! Looks interesting (to me?) +10:02 < kbingham> They will be done ... but not between now and the next meeting. +10:02 < kbingham> So if you want B) to list things that 'will be done sometime' then I have a much bigger todo list :) +10:02 < pinchartl> :-) +10:02 < pinchartl> no worries +10:02 < pinchartl> * Laurent +10:02 < pinchartl> Since last meeting: +10:02 < pinchartl> - BSP upport (periupport updates) +10:02 < pinchartl> - Periject-NG discussions and review +10:02 < pinchartl> - DU oops fix when clock is not present +10:02 < pinchartl> - Attended ELC-E, Linux media summit and peripericon +10:02 < pinchartl> - Patch review +10:02 < pinchartl> Until next meeting: +10:02 < pinchartl> - Attend LPC in Vancouver +10:02 < pinchartl> - D3/E3 RGB output routing +10:02 < pinchartl> - More BSP upport +10:02 < pinchartl> - More patch review +10:02 < pinchartl> Issues and blockers: None +10:03 < pinchartl> any question ? +10:03 < pinchartl> * Morimoto-san +10:03 < pinchartl> Since last meeting: +10:03 < pinchartl> - ELCE + PeriPeriCon +10:03 < pinchartl> - Upstreamed TDM Split mode support patches (will be in v4.21) +10:03 < pinchartl> - Posted ULCB + KF sound support patches to mailing list +10:03 < pinchartl> Until next meeting: +10:03 < pinchartl> - Update sound card driver for TDM split mode +10:03 < pinchartl> TDM splut mode itself is OK, the but current sound "card" driver can't handle it with the normal sound interface (= ak4613). +10:03 < pinchartl> Issues and Blockers: None +10:03 < pinchartl> morimoto: any comment ? +10:04 < morimoto> no, thanks +10:04 < morimoto> +10:04 < pinchartl> thank you +10:05 < pinchartl> * Simon +10:05 < pinchartl> Since last meeting: +10:05 < pinchartl> - E3 Audio support merged (DT/defconfig updates/pfc) +10:05 < pinchartl> Requires IPPMU to be enabled for DMA to be initialised (see Core) +10:05 < pinchartl> Until next meeting: None +10:05 < pinchartl> Issues and blockers: None +10:05 < pinchartl> horms: any comment ? +10:06 < uli___> sorry, i think i have to go now. i'm camping out at the real estate developer's back office, and i think they want to close shop, but are too polite to throw me out... +10:06 < uli___> no mm update from me anyway +10:06 < uli___> see you in two weeks, i guess +10:06 < pinchartl> uli___: I've listed +10:07 < pinchartl> * Ulrich +10:07 < pinchartl> Since last meeting: +10:07 < pinchartl> - Reviewed patches +10:07 < pinchartl> [PATCH 1/2] pinctrl: sh-pfc: Introduce VIN_DATA_PIN_GROUP_VER +10:07 < pinchartl> [PATCH 2/2] pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions +10:07 < pinchartl> Until next meeting: +10:07 < pinchartl> - More patch review +10:07 < pinchartl> Issues and blockers: Influenza +10:07 < pinchartl> I hope you'll get better soon +10:07 < pinchartl> thank you for joining +10:07 < uli___> ok, i though that counts as core :) +10:07 < uli___> see you! +10:07 -!- uli___ [~uli___@175.158.200.156] has left #periperi ["Leaving"] +10:07 < pinchartl> :-) +10:07 < pinchartl> neg: any update ? +10:07 < pinchartl> I haven't seen your e-mail, or have I missed it ? +10:09 < pinchartl> neg seems to be MIA +10:09 < pinchartl> that's it for the status update +10:09 < kbingham> That's what happens when the MM starts on time... catches us off guard :D +10:10 < pinchartl> :-) +10:10 < pinchartl> Topic 2. Discussions +10:10 < kbingham> Gotta keep us on our toes. +10:10 < pinchartl> any question or comment ? +10:10 < kbingham> For Discussions ? or status ? +10:10 < kbingham> (None for status) +10:10 < pinchartl> either :-) +10:11 < wsa> do you guys have your add. tasks already? +10:11 < kbingham> We should think about v4l2 fault tolerance at some point- but that probably doesn't matter until after GMSL is accepted mainline. +10:12 < jmondi> wsa: yes I do +10:12 < horms> pinchartl: mpcp,,emt +10:12 < horms> pinchartl: no comment +10:12 < geertu> wsa: Yes I do +10:12 < jmondi> gmsl people, where do we sleep for 8 secs? I cannot find it anymore in code +10:12 < wsa> Oh, since when? +10:13 < jmondi> (maybe because I'm looking at it through a browser...) +10:13 < kbingham> jmondi, It's in the DT on the regulator delay +10:13 < pinchartl> jmondi: in DT :-) +10:13 < geertu> wsa: Right before ELCE +10:13 < jmondi> startup-delay-us = <(250000 + IMI_MCU_DELAY)> +10:13 < jmondi> gotcha +10:13 < jmondi> sorry +10:14 < geertu> wsa: Correction, at ELCE +10:15 < wsa> geertu: Thanks! +10:15 < pinchartl> wsa: the MM team also got them AFAIK +10:15 < kbingham> The only other thing I need to discuss is - how much time do people want me to spend on periject (i.e. should I do more yaml validation scripting etc...) I have 39 hours of base time left for 2018 ... so I don't know if my focus should be periject - or (as I would assume) continuing on backlog patches. +10:15 * morimoto sorry, I need to leave soon +10:15 < damm> wsa: need to coordinate with shimoda-san about additional tasks for i/o +10:16 < geertu> s/at/during/ (takes a while for the coffee to reach the brain) +10:16 < pinchartl> morimoto: thank you for attending +10:16 < morimoto> pinchartl: thanks. bye +10:16 -!- morimoto [~user@relprex2.renesas.com] has left #periperi ["ERC (IRC client for Emacs 24.5.1)"] +10:17 < pinchartl> kbingham: that would have been a question for Morimoto-san :-/ +10:17 < kbingham> pinchartl, Yup :) +10:17 < kbingham> I did ask a full 14 seconds before he said he was leaving :D +10:17 < damm> nice with the yaml stuff guys btw +10:17 < wsa> damm: Ok, thanks. Seems IO is last this time... +10:18 < kbingham> damm, I do like how it defines the structure well. +10:18 < damm> wsa: perhaps you can ask shimoda-san and cc me +10:18 < kbingham> Feels both readable and 'interpretable' +10:18 < wsa> damm: will do +10:18 < damm> thanks +10:19 < wsa> damm: hope you are fine! long time no hear :) +10:19 < pinchartl> damm: any opinion on base task allocation to work on periject ? +10:19 < damm> help +10:20 < damm> no objections what so ever +10:20 < pinchartl> help? doesn't seem fine :-) +10:20 < damm> sorry struggling with my irc client, feeling old =) +10:20 < pinchartl> kbingham: :-) +10:20 < pinchartl> I meant damm: :-) +10:20 < damm> all is good here so no worries thanks +10:21 < pinchartl> kbingham: I'll include the question in the report, let's discuss it there with Morimoto-san +10:21 < damm> good thanks +10:21 < kbingham> Ok ... I just need someone to tell me what the priority is ... periject vs backlog :) +10:21 < damm> maybe you can spend half the calender time that was spent on the previous tool =) +10:22 < kbingham> :) +10:22 < damm> ping me again around spring =) +10:22 < damm> but seriously, please check priorities with morimoto-san +10:22 < pinchartl> :-) +10:23 < kbingham> Ok - moving that to e-mail +10:24 < pinchartl> any other discussion topic ? +10:24 < wsa> damm: mail sent +10:24 < wsa> and I'll be off... +10:25 < pinchartl> Topic 3. Next Meeting +10:25 < pinchartl> two weeks from now, same time ? +10:25 < wsa> ack +10:26 < pinchartl> alright +10:26 < pinchartl> if there's nothing else to discuss, I propose adjourning this meeting +10:26 < pinchartl> does anyone second ? +10:26 < horms> second +10:26 < jmondi> seconded! thank you all +10:27 < pinchartl> meeting adjourned! thank you all for attending diff --git a/wiki/Chat_log/20181122-core-chatlog b/wiki/Chat_log/20181122-core-chatlog new file mode 100644 index 0000000..9a0a4a1 --- /dev/null +++ b/wiki/Chat_log/20181122-core-chatlog @@ -0,0 +1,98 @@ +09:33 < geertu> Welcome to Today's Core Group Chat! +09:34 < geertu> Due to Wolfram's overbooking, and Laurent's misbooking, there are less people than usual +09:34 < geertu> Agenda: +09:34 < geertu> 1. Status Updates +09:34 < geertu> 2. Discussion Topics +09:34 < geertu> Topic 1. Status updates +09:34 < geertu> A) What have we done since last time: +09:34 < geertu> Marek worked on U-Boot (HS400 on R-Car Gen3, special SD card support) +09:34 < geertu> and Linux (Upported M3-N and E3 CAN/CANFD support). +09:34 < geertu> Geert resubmitted the move of SoC-specific ARCH_* symbols, and generic +09:34 < geertu> reset support for VFIO platform, and explored SYSC errata. +09:35 < geertu> B) What we plan to do till next time: +09:35 < geertu> Marek plans to work on PCA953x suspend/resume support for Salvator-XS +09:35 < geertu> SATA, and will continue researching HS400 performance on E3. +09:35 < geertu> Shimoda-san plans to continue to make an IPMMU driver's plan with +09:35 < geertu> Magnus-san. +09:35 < geertu> Geert will sent the first CLK and PFC pull requests for v4.21, and plans +09:35 < geertu> to continue exploring SYSC errata, and submit resulting patches. +09:36 < geertu> C) Problems we have currently: +09:36 < geertu> Kaneko-san reports that the R-Car E3 thermal driver and bindings have +09:36 < geertu> been reviewed, but not merged. +09:36 < geertu> Anything I missed? +09:37 < patersonc> Marek: What is the status of M3N/E3 CAN/CAN FD? +09:37 < Marex> patersonc: I submitted the patches, tested on E3, for M3N I need to cook some small HW with MCP2551 or so +09:37 < patersonc> Marex: Thanks +09:37 < Marex> patersonc: since there's no CAN transceiver on the M3N S-XS, I need to build one ... +09:38 < patersonc> Yep +09:38 < patersonc> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a414cb9dc73a746c71ce79d6422d086745311626 +09:38 < patersonc> Looks like E3 is in +09:38 < Marex> patersonc: you have M3N with CAN(FD) transceiver ? :) +09:38 < Marex> maybe you can test my patch +09:38 < Marex> s/my/Kaneko-san's/ +09:39 < horms> patersonc: yes, I applied E3 CAN DT patches earlier this week +09:40 < patersonc> Marex: As it happens we do have a small CAN board for Sal-XS. It was developed by ze Germans +09:41 < Marex> patersonc: Schön +09:41 < Marex> patersonc: maybe you can save me a trip to local parts store ? +09:42 < patersonc> Sure +09:42 < Marex> patersonc: ah, sweet :) +09:42 < patersonc> I'll sort it before the boss comes in ;) +09:42 < geertu> patersonc: thx! +09:44 < patersonc> Marex: Just ping your patches/branch over +09:44 < geertu> I guess the R-Car E3 thermal patches will be applied, eventually, as usual? +09:44 < Marex> geertu: hrm, but he'd need a DT patch adding the pinmux etc. on M3N +09:44 < Marex> geertu: I might build me the CAN transceiver anyway +09:44 < horms> geertu: I guess so too. I'm holding off on the DT patches until the driver patches are accepted. +09:44 < horms> But perhaps I should just apply them +09:45 < geertu> Marex: That's a 5 line DT patch? +09:45 < Marex> patersonc: will do, sec +09:46 < Marex> geertu: once you know the mux ... +09:47 < Marex> geertu: although, there are not that many options +09:48 < geertu> Marex: If they have a CAN extensaion board for Salvator-X(S), they should have some DT description, no? +09:49 < geertu> can1_data or canfd1_data +09:49 < Marex> geertu: not necessarily +09:49 < geertu> and perhaps can_clk +09:49 < Marex> geertu: is can_clk actually needed ? +09:50 < geertu> Marex: depends on the hardware expansion, I guess +09:50 < geertu> Topic 2. Discussion Topics +09:50 < Marex> patersonc: https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=44491 https://patchwork.kernel.org/patch/10691447/ +09:50 < geertu> Anything else to discuss (CAN is actually I/O ;-) +09:51 < Marex> patersonc: you need these two series + the M3N extras enabling the can controller +09:51 < Marex> geertu: well, HS400 slowness on E3 , it's unclear if that's IO or core, since it might be QoS issue +09:51 < patersonc> Marex: Ta. I'll try and do it tomorrow. Please nag. +09:51 < Marex> patersonc: did you have a chance to try HS400 performance on E3 ? +09:51 < Marex> patersonc: will do, thanks +09:52 < Marex> patersonc: I'll also grab the transceiver today, just to be sure +09:52 < geertu> Marex: Well, that's indeed to be seen +09:53 < geertu> Marex: Tried a logic analyzer, to compare with a "fast" board? +09:53 < Marex> geertu: we're talking 200 MHz LVTTL here +09:54 < Marex> geertu: scope which can sample that reliably costs like a small car +09:54 < geertu> Marex: OK +09:55 < patersonc> Marex: I can tell you HS400 works on E3 :) +09:55 < geertu> Could it be the clock is running at half the frequency of what you'd expect? +09:55 < Marex> patersonc: it works for me too +09:55 < Marex> patersonc: it's just slower than I'd expect +09:55 < Marex> geertu: I checked the clock, pinmux, memory bandwidth, nope ... +09:56 < Marex> geertu: clock was the issue with HS400 I had before, so I checked that first +09:56 < Marex> patersonc: can you do a dd if=/dev/mmcblk0 bs=32M count=16 of=/dev/null and tell me how fast that goes ? +09:56 < geertu> Marex: I meant measured the clock? +09:57 < Marex> patersonc: on the card that's on Ebisu, it should be some 230-250 MB/s +09:57 < patersonc> Marex: I'll check +09:57 < Marex> geertu: don't have such a good equipment here, so no +09:58 < geertu> Marex: Add some high-speed flip-flops to reduce the clock rate to something you can measure? +09:59 < Marex> geertu: did you see _any_ such high speed stuff recently ? +10:00 < geertu> Marex: The above dd command gives me 128 MB/s on Ebisu +10:00 < Marex> geertu: you also forgot the antenna effect, capacitance of the extra stuff etc +10:00 < Marex> geertu: we're talking 200 MHz here, very different from 20 MHz +10:00 < Marex> geertu: yeah, I see 128 MB/s with Ebisu 4D using vendorkernel which reports HS400 too +10:00 < geertu> Marex: Are slower speeds also slower than expected? +10:00 < Marex> geertu: U-Boot gives me up to 170 MB/s, but that's still too slow +10:01 < Marex> geertu: U-Boot gives me up to 170 MB/s in HS200, which is what I'd expect +10:01 < Marex> geertu: U-Boot gives me up to 172 MB/s in HS400, which is too slow +10:01 * geertu has a kernel without HS400 support, so test result was for HS200 +10:02 < geertu> I mean anything slower that you can measure? The clocks may be off in all modes +10:02 < Marex> geertu: with HS200, you should get 170 MB/s, that's what the datasheet says and what my measurements confirm on this board and other boards with the same eMMC +10:03 < geertu> We used to have off-clocks on Armadillo, which I only discovered by measuring +10:04 < geertu> And e.g. R-Car H3 ES1.0 lacked a by-2 divider after some PLLs +10:04 < geertu> Anyway, time to conclude +10:04 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20181122-mm-chatlog b/wiki/Chat_log/20181122-mm-chatlog new file mode 100644 index 0000000..06e799c --- /dev/null +++ b/wiki/Chat_log/20181122-mm-chatlog @@ -0,0 +1,82 @@ +Multimedia-chat-meeting-2018-11-22 + +10:06 < pinchartl> welcome to the multimedia group chat meeting +10:07 < pinchartl> topic 1, status update +10:07 < kbingham> Hola +10:07 < pinchartl> Jacopo is excused +10:07 < pinchartl> (I think :-)) +10:08 < pinchartl> he hasn't reported his status by e-mail +10:08 < pinchartl> but I'm fairly certain I can say he has attended LPC +10:08 < pinchartl> and plans to work on his adv748x addition task +10:08 < horms> Looks like neg attended to... +10:09 < pinchartl> :-) +10:09 < pinchartl> * Kieran +10:09 < pinchartl> Since last meeting: +10:09 < pinchartl> - More GMSL discussions with Luca Ceresoli +10:09 < pinchartl> - Identified and resolved VSP M3N Rotation issue (patch to follow) +10:09 < pinchartl> - Linux Plumbers Conference +10:09 < pinchartl> Until next meeting: +10:09 < pinchartl> - VSP partition algorithm - phase handling +10:09 < pinchartl> This is still the highest backlog priority, will resume now that the +10:09 < pinchartl> conference season is over. +10:09 < pinchartl> Issues and blockers: None +10:09 < pinchartl> Interesting topics (From LPC): +10:09 < pinchartl> - Device tree track discussions +10:09 < pinchartl> Overlay support, YAML schema validation of DT +10:09 < pinchartl> - Testing and Fuzzing track +10:09 < pinchartl> Testing in Userspace - pointers to compiling unit tests (similar to kunit, but +10:09 < pinchartl> without UML), KernelCI discussions +10:09 < pinchartl> - Xarray data structure implementation +10:09 < pinchartl> kbingham: any comment ? +10:10 < kbingham> pinchartl, I think that covers me ;) +10:10 < kbingham> Except a discussion later on what to do for PJ2 +10:10 < pinchartl> thank you +10:11 < pinchartl> PJ2 ? +10:11 < kbingham> PeriJect2 :) +10:12 < pinchartl> ah yes +10:12 < pinchartl> should I record you will keep working on that ? +10:12 < kbingham> Not until we have the discussion to identify if I will or not :) +10:12 < patersonc> Marex: HS400 on E3 with latest BSP, in Linux: 168 MB/s +10:12 < pinchartl> :-) +10:13 < pinchartl> * Laurent +10:13 < pinchartl> Since last meeting: +10:13 < pinchartl> - Attended LPC in Vancouver +10:13 < pinchartl> - Started D3/E3 RGB output routing +10:13 < pinchartl> - v4.20 DU regression ("media: vsp1: Fix LIF buffer thresholds") +10:13 < pinchartl> - Patch review +10:13 < pinchartl> Until next meeting: +10:13 < pinchartl> - Finish D3/E3 RGB output routing +10:13 < pinchartl> - Next v4.20 DU regression (VGA hang on R8A77965) +10:13 < pinchartl> - More BSP upport +10:13 < pinchartl> - More patch review +10:13 < pinchartl> Issues and blockers: None +10:13 < pinchartl> any question ? +10:13 < marex-cloud> patersonc: yeah, too slow, should be over 250 according to Emmc data sheet +10:13 < pinchartl> Morimoto-san is excused +10:13 < pinchartl> * Morimoto-san +10:13 < pinchartl> Since last meeting: +10:13 < pinchartl> - Posted special sound card driver for TDM split mode +10:13 < pinchartl> Until next meeting: +10:13 < pinchartl> - Continue patch posting +10:13 < pinchartl> Issues and Blockers: None +10:14 < pinchartl> * Niklas +10:14 < pinchartl> Since last meeting: +10:14 < pinchartl> - Reviewed Jacopos VIN E3 patches, looks good +10:14 < pinchartl> - Attended LPC +10:14 < pinchartl> Until next meeting: +10:14 < pinchartl> - Post new version of adv748x lane series +10:14 < pinchartl> - Start VIN and CSI-2 suspend/resume support +10:14 < pinchartl> Issues and Blockers: None +10:14 < pinchartl> neg: any comment ? +10:14 < neg> No comment +10:14 < pinchartl> thank you +10:14 < pinchartl> Ulrich isn't here +10:15 < pinchartl> and Simon had no multimedia task to report +10:15 < pinchartl> horms: correct ? +10:15 < horms> correct +10:15 < horms> all quiet on the western seaboard +10:16 < pinchartl> thank you +10:16 < pinchartl> topic 2, discussions +10:16 < pinchartl> anything from anyone ? +10:17 < kbingham> PJ2 ... but that's not strictly MM +10:18 < pinchartl> in this case we're done with MM. thank you all for joining our shortest meeting ever :-) diff --git a/wiki/Chat_log/20181206-core-chatlog b/wiki/Chat_log/20181206-core-chatlog new file mode 100644 index 0000000..14cb8a7 --- /dev/null +++ b/wiki/Chat_log/20181206-core-chatlog @@ -0,0 +1,99 @@ +10:03 < geertu> Welcome to Today's Core Group Meeting! +10:03 < geertu> (and today we're celebrating https://en.wikipedia.org/wiki/Sinterklaas !) +10:04 [Users #periperi] +10:04 [ damm ] [ kbingham ] [ Marex ] [ mturquette] [ pinchartl] +10:04 [ geertu] [ kbingham[m]] [ marex-cloud] [ neg ] [ shimoda ] +10:04 [ jmondi] [ ldts ] [ morimoto ] [ patersonc ] [ wsa_ ] +10:04 -!- Irssi: #periperi: Total of 15 nicks [0 ops, 0 halfops, 0 voices, 15 normal] +10:04 < geertu> Agenda: +10:04 < geertu> 1. Status Updates +10:04 < geertu> 2. Discussion Topics +10:04 < pinchartl> (and https://en.wikipedia.org/wiki/Independence_Day_(Finland)) +10:04 < geertu> pinchartl: But I read the islands are under attack again? +10:04 < geertu> Topic 1. Status updates +10:05 < geertu> A) What have we done since last time: +10:05 < geertu> Kaneko-san worked on R-ar E3 thermal and PMIC support. +10:05 < geertu> Marek work on U-Boot (SDHI, various fixes and cleanups), Linux (PCA953x, +10:05 < geertu> VC5 suspend/resume, RPC review), and ATF (DRAM config passing). +10:05 < geertu> Niklas submitted HS400 clock driver patches. +10:05 < geertu> Shimoda-san worked on IPMMU whitelisting and reported an R-Car E3's +10:05 < geertu> USB3_OVC pull-up issue. +10:05 < geertu> Geert worked on CPG/IPMMU/SYSC topology errata, SYSCEXTMASK support, +10:05 < geertu> sent CLK/PFC pull requests, and reviewed lots of patches. +10:05 < geertu> B) What we plan to do till next time: +10:05 < geertu> Kaneko-san will follow up on posted work. +10:05 < geertu> Marek plans to work on U-Boot (extracting patches from the Android BSP, +10:05 < geertu> USB gadget rework) and ATF (updates from Renesas + PCI suspend). +10:05 < geertu> Morimoto-san will ask the HW team about SYSCEXTMASK. +10:05 < geertu> Shimoda-san plans to continue to make an IPMMU driver's plan with +10:05 < geertu> Magnus-san. +10:05 < geertu> Ulrich plans to review patches. +10:05 < geertu> Geert will fix the pull-up only pin on R-Car E3, and plans to finalize +10:05 < geertu> instantiating generic devices from DT in QEMU. +10:07 < geertu> C) Problems we have currently: +10:07 < geertu> None. +10:07 < geertu> EOT +10:07 < geertu> Anything I missed? +10:08 < pinchartl> geertu: possibly Kieran working on periject ? +10:08 < pinchartl> (is that part of core ?) +10:10 < geertu> Is that under A or C? ;-) +10:10 < pinchartl> A +10:11 < kbingham> Good point - I guess that is part of core rather than MM :) +10:12 < geertu> It's part of meta +10:12 < kbingham> Now then - I have a question for periject - Who 'owns' the project. I have done a small task to help define the schema ... I am not assuming that I now own periject ... so I'm concerned that it is losing direction and management fast ! +10:13 < pinchartl> morimoto: ^^ +10:13 < pinchartl> kbingham: you may well be the owner now :-) +10:16 < pinchartl> seems there's a lack of volunteers ? +10:17 < morimoto> according to EthPad (http://muistio.tieke.fi/p/ppcedi18) +10:17 < morimoto> I can do is create git tree +10:19 < kbingham> Aha - we have earlier defined action points. +10:20 < kbingham> morimoto, could you let me know where to push the patches I have done so far then please? +10:21 < pinchartl> morimoto: about the next steps, would you like to continue development with Kieran ? +10:21 < morimoto> development what ? +10:22 < pinchartl> development of periject +10:22 < morimoto> kbingham: do you want to have new clean git repository ? +10:22 < morimoto> or contine +10:23 < morimoto> continue to use exist one ? +10:23 < morimoto> I can do both +10:25 < kbingham> I would have said continue to use the existing one - but there is quite a lot of code that would need to be ported to the new formats. So that makes me think a clean repository, as we import existing functionality on the new data format. What do you think ? +10:26 < morimoto> OK, no problem +10:26 < morimoto> I will remove existing periject, and create new clean one +10:27 < kbingham> morimoto, Don't 'remove' it completely :) +10:27 < pinchartl> or create a new branch in the existing repo ? +10:27 < morimoto> kbingham: I don't think we can reuse it +10:28 < morimoto> OK, not remove, but rename. periject -> periject-nack +10:31 < kbingham> Well either a new branch, in the same repo - or a fresh repo (whilst keeping the existing code in a separate) repo is fine by me. I think it's important to keep the existing code as reference for the design goals you had +10:31 < geertu> Yes, just rename the old master branch. +10:32 < morimoto> OK, move existing code to new branch, and create clean main branch ! +10:34 < kbingham> Ok great. So I saw wsa_ had interest in participation from the EDI notes... +10:35 < kbingham> wsa_, Is there anything blocking you currently ? +10:35 < wsa_> what kind of "participation"? +10:35 < kbingham> wsa_, "Peri upport list # Wofram : migrate data # Wolfram" +10:36 < wsa_> the discussions i saw on the mailing list were YAML state details where I had no strong opinion on +10:36 < wsa_> ah, that +10:36 < wsa_> yes, I am still there for that +10:36 < kbingham> wsa_, Great ... is there anything blocking you from doing it :) (other than time.. :D) +10:37 < wsa_> yes, a notification like "everything you need for that is in place now" :) +10:37 < wsa_> like YAML scheme being ready, repo to work on +10:37 < wsa_> "ready enough" is good enough, too +10:38 < kbingham> Well then you can reply to the YAML schema saying 'Acked-by:' then :) +10:38 < kbingham> The YAML schema is 'close enough' as far as I can tell... +10:39 < kbingham> And it can still change where necessary ... +10:39 < wsa_> good to know +10:39 < kbingham> So having some real data put in and run with the validator to know if it works would certainly help. +10:39 < wsa_> okay +10:39 < wsa_> morimoto: can you announce when the updated repo is ready? +10:40 < morimoto> Yeah +10:40 < wsa_> on periperi-list? +10:40 < wsa_> great +10:40 < wsa_> thanks! +10:40 < morimoto> Maybe tomorrow +10:40 < morimoto> (Japanese time zone, of course :) +10:42 < kbingham> Ok - so we have some progress points ... +10:42 < kbingham> Shall we move on - and try to continue this in the ML? +10:42 < wsa_> ack +10:44 < pinchartl> should we proceed with multimedia then ? +10:44 < geertu> I think so, unless someone has another Core discussion topic? +10:45 < neg> I'm all cored out :-) +10:45 < pinchartl> :-) +10:46 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20181206-io-chatlog b/wiki/Chat_log/20181206-io-chatlog new file mode 100644 index 0000000..e726f66 --- /dev/null +++ b/wiki/Chat_log/20181206-io-chatlog @@ -0,0 +1,152 @@ +09:04 < wsa_> ah, simon is excused +09:04 < wsa_> in which timezone is he now? +09:05 < wsa_> anyhow, let's start +09:05 < wsa_> welcome to this IO meeting +09:05 < wsa_> 1) status updates 2) topics +09:05 < geertu> wsa_: AFAIK, he's in California +09:05 < wsa_> Status updates +09:05 < wsa_> ============== +09:05 < wsa_> A - what have I done since last time +09:05 < wsa_> ------------------------------------ +09:05 < wsa_> Kaneko-san +09:05 < wsa_> : got I2C SYS-DMAC enablement for E3 merged +09:05 < wsa_> Marek +09:05 < wsa_> : improved the PCA953x driver to handle suspend/resume for SATA properly, +09:05 < wsa_> tested CAN on M3N using homemade CAN transceived, and bisected an upstream +09:05 < wsa_> network breakage +09:05 < wsa_> Niklas +09:05 < wsa_> : resent HS400 patch series about reset operation, ES revision handling, and +09:05 < wsa_> clock driver updates +09:05 < wsa_> Shimoda-san +09:05 < wsa_> : created patch and discussed proper upstream handling of some ethernet PHY +09:05 < wsa_> behaviour, handled the Q-Tag VLAN frame issue requested by the BSP team, +09:05 < wsa_> discussed SCIF flowchart issues, improved Gen3 USB2 phy handling, and +09:05 < wsa_> prepared a elinux page about USB virtualization +09:05 < wsa_> Simon +09:05 < wsa_> : got E3 IIC patches merged, sent patch for no-link property on Ebisu, and +09:05 < wsa_> provided feedback for the Q-Tag VLAN frame issue +09:05 < wsa_> Ulrich +09:05 < wsa_> : sent D3 CAN binding patches +09:05 < wsa_> Wolfram +09:05 < wsa_> : picked up I2C core PM work again, implemented patch and discussed about +09:05 < wsa_> WDT timer value during suspend, sent new version of MMC RPMB core fix and +09:05 < wsa_> improved some more smaller RPMB issues, answered GMSL questions from Jacopo, +09:05 < wsa_> reviewed IIC enablement, Niklas latest HS400 patches, and orchestrated +09:05 < wsa_> periupport some more +09:05 < wsa_> B - what I want to do until next time +09:05 < wsa_> ------------------------------------- +09:05 < wsa_> Geert +09:05 < wsa_> : wants to resubmit fixes for fallback to PIO in the sh-sci driver +09:05 < wsa_> Kaneko-san +09:05 < wsa_> : wants to enable PWM pn E3 +09:05 < wsa_> Niklas +09:05 < wsa_> : wants to keep tracking HS400 patches +09:05 < geertu> UTC-8? +09:06 < wsa_> Shimoda-san +09:06 < wsa_> : wants to continue to investigate USB2.0 host/peripheral resets behavior on +09:06 < wsa_> mainline, submit the USB virtualization page for eLinux, and wants to +09:06 < wsa_> investigate VFIO usage for Gen3 +09:06 < wsa_> Simon +09:06 < wsa_> : wants to follow up on the Q-Tag VLAN frame issue +09:06 < wsa_> Ulrich +09:06 < wsa_> : wants to send D3 CAN DT patches and do more patch review +09:06 < wsa_> Wolfram +09:06 < wsa_> : wants to submit I2C core PM work, check upstream SDHI bug report about +09:06 < wsa_> accessing large files, keep at watchdog and (older and revived) thermal +09:06 < wsa_> discussions, work on known IIC issues, more GMSL discussion +09:06 < wsa_> C - problems I currently have +09:06 < wsa_> ----------------------------- +09:06 < wsa_> Simon +09:06 < wsa_> : is waiting on various feedback about patches +09:07 < wsa_> so, my questions: +09:07 < wsa_> Marex: shimoda: are you in sync with upstreaming the PCIe ATF code? +09:08 < pinchartl> C - The pwm-rcar driver is broken with the PWM atomic API +09:08 < Marex> wsa_: I hope so, I need to rebase the PCI patch on top of upstream ATF, since they added all of the exception handling boilerplate and the patch doesn't apply anymore, but besides that, it should be doable +09:09 < wsa_> also, (not super much IO but upporting): who has a D3 board? According to the list, jmondi and Uli. Sound support needs to be upported... +09:09 < pinchartl> wsa_: I have Jacopo's D3 board, we exchanged the D3 and E3 +09:10 < shimoda> wsa_: about D3, I also have a board +09:10 < pinchartl> I thought I had updated the wiki, does it still show the D3 as being with Jacopo ? +09:10 < wsa_> pinchartl: will add the PWM issue to C), thanks! +09:10 < geertu> General comment: please update https://osdr.renesas.com/projects/linux-kernel-development/wiki/Hardware +09:11 < wsa_> pinchartl: you have. that was a race condition :D +09:11 < jmondi> ups, forgot to update this ^ +09:11 < jmondi> but somebody did already :) +09:12 < wsa_> so, if somebody is interested in that, there are some Jinso-patches for that on the list... +09:14 < wsa_> with simon not being here, that were all of my questions, I guess +09:14 < wsa_> are there some more from you, guys? +09:15 < pinchartl> if there's nothing else to discuss, I'd like to know if someone would like to address the PWM issue +09:15 < Marex> wsa_: speaking of D3/E3, I'm still curious about the HS400 performance on E3, it's lower than on M3N (with the same controller and same eMMC), both on BSP and mainline U-Boot +09:15 < geertu> Shimoda-san enquired about using VFIO. +09:15 < wsa_> shimoda: pinchartl: I assume you are linked now concerning the PWM issue? +09:15 < Marex> wsa_: I wonder if that's a QoS thing (if I fiddle with the QoS settings in ATF, it does affect that a bit) or something else +09:16 < neg> a cross IO/core question, do you think it's possible for us to aim to enable HS400 for 4.21 or are we a tad to late? +09:16 < pinchartl> shimoda: do you have time to work on pwm-rcar, or should I try to fix the problem ? +09:16 < wsa_> neg: I would very much hope so +09:17 < shimoda> pinchartl: i have time to work on pwm-rcar +09:17 < wsa_> neg: we could ask geertu if he is happy with the clock patches :) +09:17 < wsa_> neg: from the reviews, only minor stuff needs to be changed +09:18 < geertu> I plan to apply the clock patches, with the two nits fixed. +09:18 < shimoda> pinchartl: so I'd like to know how to reproduce the issue. +09:18 < geertu> And send a PR tomorrow. +09:18 < pinchartl> shimoda: great :-) I noticed the issue with backlight on E3, but I think it can be reproduced on any board. the problem comes from using the PWM atomic API. as the pwm-rcar driver doesn't suport it natively, the PWM core translates the calls to the legacy PWM API (set config, enable). the sequence of calls doesn't work well +09:18 < wsa_> geertu: one nit was not in the commit message but only in the changelog +09:19 < neg> wsa_: Yes even so I noticed Simon closed the renesas tree yesterday for 4.21 but maybe he can take it anyhow. Will ask him once he is awake +09:19 < geertu> wsa_: Which one? +09:19 < wsa_> s/rete/rate/ +09:19 < pinchartl> rcar_pwm_config() returns immediately because pwm->state.duty_cycle = 0 +09:20 < pinchartl> and then rcar_pwm_enable() will return an error because RCAR_PWMCNT_CYC0 == 0 and RCAR_PWMCNT_PH0 == 0 +09:20 < wsa_> neg: can you resend the other patch ASAP? +09:20 * geertu has a PWM déjà vue +09:20 < geertu> s/vue/vu/ +09:21 < pinchartl> so I think we need rcar_pwm_config() first compute the config parameters and store them, and then return if the PWM is not enabled, or program the hardware if it is +09:21 < wsa_> then let's hope simon will make an exception for the final HS400 DTS enablement patch +09:21 < pinchartl> then rcar_pwm_enable() should always proceed with the stored config +09:21 < pinchartl> and program the hardware if it's not programmed yet +09:21 < shimoda> pinchartl: I didn't know about the PWM atomic API. I'll check that. as you said, the driver prevents to enable it with CYC0 == 0 and PH0 == 0. +09:21 < geertu> Simon is still applying patches. +09:22 < neg> wsa_: I talked to geertu about the patches yesterday and he has generously agreed to fix the nit commetns when applying them. My question was more about if it was to late for the HS400 DT patch +09:22 < wsa_> neg: I don't think so :) +09:22 < neg> good :-) +09:23 < pinchartl> shimoda: it's a chicken and egg problem. rcar_pwm_config() doesn't program RCAR_PWMCNT because the channel is disabled, and then rcar_pwm_enable() errors out because RCAR_PWMCNT isn't programmed :-) +09:24 < geertu> Is this a recent PWM issue? +09:24 < pinchartl> one option to test this is to use my git://linuxtv.org/pinchartl/media.git drm/du/d3e3 branch +09:25 < pinchartl> make sure to compile the pwm-backlight driver +09:25 < pinchartl> then you can control the backlight from sysfs +09:25 < pinchartl> in /sys/class/backlight +09:25 < pinchartl> pwm-backlight now uses the PWM atomic API +09:25 < pinchartl> geertu: I don't think it's new, what has changed is the way client drivers use the PWM API +09:26 < pinchartl> the call sequence was always valid +09:26 < pinchartl> but never tested +09:26 < wsa_> eeeks, my thunderbird crashes badly...(?) so I can't look now... is there somebody at the ethernet breakage that Marex bisected? +09:26 < shimoda> pinchartl: :) so, i added a trickly code at line 157 of pwm-rcar.c. But, I think I should support .apply ops instead of legacy ops +09:27 < pinchartl> that would of course be a good option too :-) +09:27 < geertu> wsa_: It's hch's DMA cleanup +09:27 < geertu> Marex pointed to https://patchwork.kernel.org/patch/10668093/ +09:27 < wsa_> geertu: i see. thanks +09:28 < geertu> Aboiut Shimoda-san's VFIO question +09:28 < geertu> The answer is "yes, you can". SATA is the most mature example. You still need to apply out-of-tree kernel and qemu patches, cfr. https://elinux.org/R-Car/Virtualization/VFIO +09:28 < pinchartl> shimoda: the apply operation should be easier to implement for the driver, and should fix the probleem +09:29 < pinchartl> that's all on my side for pwm-rcar +09:29 < Marex> wsa_: the link also contains a patch , which fixes the breakage +09:29 < wsa_> cool +09:29 < pinchartl> on a different, common topic, I would like to talk about peripericon @FOSDEM2019. we can do that now or later as part of core or multimedia +09:30 < shimoda> pinchartl: thank you for the detailed information! I'll try to implement the apply operation. +09:30 < wsa_> Yeah, I'd like to talk about that if there are no more IO related questions? +09:30 < Marex> wsa_: speaking of D3/E3, I'm still curious about the HS400 performance on E3, it's lower than on M3N (with the same controller and same eMMC), both on BSP and mainline U-Boot +09:30 < Marex> wsa_: I wonder if that's a QoS thing (if I fiddle with the QoS settings in ATF, it does affect that a bit) or something else +09:30 < wsa_> shimoda: cool, thanks for taking care of that. +09:31 < shimoda> geertu: thank you aboit VFIO. I didn't check the eLinux page. I'll check it after I made a patch for pwm-rcar :) +09:31 < wsa_> Marex: did you try using the BSP also? +09:31 < geertu> shimoda: You're welcome. If you have issues, please ping me! +09:32 < Marex> wsa_: yes, that's why I wrote it happens both on BSP and mainline U-Boot +09:32 < Marex> wsa_: BSP Linux that is +09:32 < shimoda> geertu: sure! +09:33 < wsa_> Marex: ah linux, too, okay +09:34 < wsa_> Marex: If it happens the same on BSP and upstream, this is usually the point where I would ask BSP team or HW team... +09:34 < Marex> wsa_: I brought it up in the periperi list, but that discussion died out +09:34 < Marex> wsa_: I'll restart it +09:35 < wsa_> Marex: please do +09:36 < wsa_> okay +09:36 < wsa_> FOSDEM talk? +09:37 < wsa_> geertu: are you okay with that? +09:37 < geertu> Sure diff --git a/wiki/Chat_log/20181206-mm-chatlog b/wiki/Chat_log/20181206-mm-chatlog new file mode 100644 index 0000000..75c9596 --- /dev/null +++ b/wiki/Chat_log/20181206-mm-chatlog @@ -0,0 +1,116 @@ +Multimedia-chat-meeting-2018-12-06 + +10:46 < pinchartl> welcome to the multimedia meeting +10:46 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:46 < pinchartl> * Jacopo +10:46 < pinchartl> Since last meeting: +10:46 < pinchartl> - GMSL discussions (still have to reply to Wolfram's answers) +10:46 < pinchartl> - Miscellaneous V4L2 activities: +10:46 < pinchartl> - reviews (ov7670, Marvel CIC) +10:46 < pinchartl> - a few more sensor driver patches (ov5640) +10:46 < pinchartl> - Additional task to support CVBS input on Ebisu through CSI-2 +10:46 < pinchartl> - Media graph patches written, not sent yet +10:46 < pinchartl> Until next meeting: +10:46 < pinchartl> - Complete addtional taks and submit +10:46 < pinchartl> - Reply to Wolfram and keep an eye on GMSL discussions +10:46 < pinchartl> Issues and blockers: +10:46 < pinchartl> - I need to bother Niklas to help testing the Ebisu series on Salvator with +10:46 < pinchartl> CVBS input +10:46 < pinchartl> jmondi: any comment ? +10:47 < pinchartl> have we lost Jacopo ? :-) +10:47 < neg> jmondi: just ping me when you need testing of CVBS, I'm i the office until the 21st +10:47 < jmondi> I'm here sorry +10:48 < jmondi> nothing to add +10:48 < jmondi> neg: surely before than that :) +10:48 < pinchartl> thank you +10:48 < pinchartl> * Kieran +10:48 < pinchartl> Since last meeting: +10:48 < pinchartl> - M3N VGA reviews +10:48 < pinchartl> - Reworked RDACM20 with (most) review comments from Sakari +10:48 < pinchartl> Updated on my rcar.git gmsl/v5 branch +10:48 < pinchartl> - yavta --reset-controls implementation +10:48 < pinchartl> [PATCH] Add support to reset device controls +10:48 < pinchartl> - [VSP-Tests PATCH 0/7] Reset controls and unloved patches +10:48 < pinchartl> - KUnit test review (part of working towards PA-Phase testing) +10:48 < pinchartl> - gmsl/for-renesas-drivers update due to merge conflict in CSI2 from +10:48 < pinchartl> neg/jmondi +10:48 < pinchartl> Until next meeting: +10:48 < pinchartl> - More work on Partition Algorithm Phase +10:48 < pinchartl> Now that the AT is done, this might actually get done +10:48 < pinchartl> - v4l2-ctl --reset-ctrls implementation ? +10:48 < pinchartl> Fairly low priority - but a nice to have +10:48 < pinchartl> Issues and blockers: +10:48 < pinchartl> - Had hoped to add --reset-ctrls to v4l2-ctl but building v4l2-utils is a real pain at the moment. +10:48 < pinchartl> kbingham: any comment ? +10:49 < pinchartl> what's your issue with building v4l2-utils ? I thought I was the only one finding that painful, but if you do as well, we should bring that up with upstream +10:49 < kbingham> please add "Review and (hopefully) PR pending adv748x patches" to B +10:49 < pinchartl> done +10:50 < kbingham> pinchartl, I cloned v4l2-utils - ran mkdir build; cd build; ../configure; make ; as I normally would - and it fails to build - in both cross compiling and native (on my laptop) ... so I stopped :) +10:51 < kbingham> Maybe I should write a gitlab-ci.yml file to send so it can have automatic build tests run :) +10:51 < pinchartl> kbingham: please report that upstream +10:51 < kbingham> Ack. +10:52 < pinchartl> * Laurent +10:52 < pinchartl> Since last meeting: +10:52 < pinchartl> - Fixed display regressions in v4.20 +10:52 < pinchartl> - Submitted DPAD output routing for D3/E3 +10:52 < pinchartl> - Patch review +10:52 < pinchartl> Until next meeting: +10:52 < pinchartl> - Get DPAD output routing merged +10:52 < pinchartl> - Using the same DOTCLKIN input for multiple DU channels +10:52 < pinchartl> - Tentatively try to get VGA output on D3/E3 working properly +10:52 < pinchartl> - More patch review +10:52 < pinchartl> Issues and blockers: +10:52 < pinchartl> - The rcar-pwm driver seems to be broken when using the PWM atomic API +10:52 < pinchartl> any question ? +10:53 < kbingham> None here. +10:53 < pinchartl> * Morimoto-san +10:53 < pinchartl> Since last meeting: +10:53 < pinchartl> - Merge audio-graph and audio-graph-scu +10:53 < pinchartl> We had common audio-graph card for normal sound and audio-graph-scu card for special use case. These are similar, but using different framework. Because of it, ULCB/KF couldn't use all sound. I tried to merge these into audio-graph card. Patches have been posted to the mailing list, some of them are accepted, but not all, yet. +10:53 < pinchartl> - Merge simple-card and simple-scu-card +10:53 < pinchartl> Did same things for simple-card version, posting these patches to ML. +10:53 < pinchartl> - Reviewing patches from Mentor developer +10:53 < pinchartl> The developer is aggressively posting new feature patch for sound, but they break sound in upstream. +10:53 < pinchartl> Until next meeting: +10:53 < pinchartl> - Continue posting patches +10:53 < pinchartl> - Keep reviewing the Mentor developer's patches +10:53 < pinchartl> Issues and Blockers: None +10:53 < wsa_> cya guys! +10:53 < pinchartl> morimoto: any comment ? +10:54 < morimoto> no, thanks +10:55 < pinchartl> * Niklas +10:55 < pinchartl> Since last meeting: +10:55 < pinchartl> - [PATCH v4 0/4] i2c: adv748x: add support for CSI-2 TXA to work in 1-, 2- and +10:55 < pinchartl> 4-lane mode +10:55 < pinchartl> - [PATCH] v4l2: async: remove locking when initializing async notifier +10:55 < pinchartl> - Started VIN and CSI-2 suspend/resume support. +10:55 < pinchartl> Until next meeting: +10:55 < pinchartl> - Finish VIN and CSI-2 suspend/resume support. +10:55 < pinchartl> Issues and Blockers: +10:55 < pinchartl> - Would be nice to get the media graph from a H3 GMSL setup with 8 cameras in +10:55 < pinchartl> dot format, to attach it to the multiplexed stream series to show a real a +10:55 < pinchartl> world use-case. +10:55 < pinchartl> Unfortunately for electrical reasons Niklas' setup only shows 4 cameras... +10:55 < pinchartl> neg: any comment ? +10:55 < neg> I forgot to add I'm looking into the lockdep warning from rcar-vin +10:56 < neg> other than that no comment +10:56 < pinchartl> in the "until next meeting" section ? +10:57 < neg> I will keep tracking it but don't think I have a solution by next meeting, but I think that is the best section to put it in +10:57 < pinchartl> ok +10:57 < pinchartl> thanks +10:57 < pinchartl> that's it for the status reports +10:57 < pinchartl> any discussion topic for today ? +10:57 < kbingham> pinchartl, I think discussion topics are already covered. +10:58 < pinchartl> I think so too, I don't have any other item to discuss +10:58 < neg> none from me +10:58 < pinchartl> morimoto: is there any pending question from the BSP team ? +10:58 < pinchartl> ah... +10:59 < pinchartl> in which case, I think that's it for today +10:59 < neg> thanks all have a great day/evening +11:00 < shimoda> morimoto-san quited accidentaly. I heard he doesn't have any pending question +11:00 < jmondi> thank you all +11:00 < pinchartl> an Emacs accident ? :-) +11:00 < pinchartl> shimoda: please thank him for attending the meeting +11:00 < pinchartl> thank you all for attending +11:00 < pinchartl> the next meeting will be two weeks from now, same schedule +11:01 < shimoda> pinchartl: sure! diff --git a/wiki/Chat_log/20181220-core-chatlog b/wiki/Chat_log/20181220-core-chatlog new file mode 100644 index 0000000..058ba1c --- /dev/null +++ b/wiki/Chat_log/20181220-core-chatlog @@ -0,0 +1,140 @@ +09:56 < geertu> Welcome to today's Core Group Chat Meeting! +09:56 < geertu> Agenda: +09:56 < geertu> 1. Status Updates +09:56 < geertu> 2. Discussion Topics +09:56 < geertu> Marex: Topic 2 +09:57 < geertu> A) What have we done since last time: +09:57 < geertu> Kaneko-san reposted R-Car E3 thermal support. +09:57 < geertu> Kieran got the linux-renesas-soc archives on lore.kernel.org, accepted +09:57 < geertu> patchwork maintenance for multi-media, is working on patchwork +09:57 < geertu> auto-delegation, and updated the periject schema. +09:57 < geertu> Marek worked on U-Boot (cache, HS200, ATF loading via SCIF), Linux (Gen2 +09:57 < geertu> PMIC quirk, thermal no_hwmon, PCA953x and VC5 suspend/resume), and ATF +09:57 < geertu> (prepate for upstream merge). +09:57 < geertu> Shimoda-san worked on D3/E3 MOD_SEL bit field order, to be clarified +09:57 < geertu> with the hardware team. +09:57 < geertu> Ulricht reviewed R-Car Gen2 and RZ/A2 patches. +09:57 < geertu> Geert looked into fdtoverlay for SoC DTS fixups, sent clk/pfc pull +09:57 < geertu> requests, fixed lots of pfc bugs exposed by new validation code, and +09:57 < geertu> reviewed lots of patches. +09:58 < geertu> B) What we plan to do till next time: +09:58 < geertu> Kaneko-san will follow up on posted work. +09:58 < geertu> Marek plans to work on the U-Boot M3ULCB HS200 problem, ATF upstreaming, +09:58 < geertu> and Linux thermal feedback. +09:58 < geertu> Shimoda-san plans to continue to make an IPMMU driver's plan with +09:58 < geertu> Magnus-san. +09:58 < geertu> Simon will follow-up Ebisu PMIC enablement, and fix arm64 defconfig to +09:58 < geertu> have RCAR_THERMAL builtin. +09:58 < geertu> Ulrich will take a Christmas break. +09:58 < geertu> Geert plans to finalize instantiating generic devices from DT in QEMU, +09:58 < geertu> and will try to enjoy Christmas and New Year holidays. +09:58 < geertu> C) Problems we have currently: +09:58 < geertu> Geert wonders how to verify MOD_SEL bitfield order on D3/E3. +09:59 < geertu> EOL +09:59 < geertu> Anything I missed? +10:00 < geertu> So that was Topic 1. Status updates +10:00 < geertu> Topic 2. Discussion Topics +10:00 < geertu> Kieran wants to define what automatic patch delegation paths are suitable. +10:00 < kbingham> Yup. +10:00 < kbingham> I hope that's quick - and can be handled on e-mail if you and simon reply to the mail :) +10:01 < geertu> First, thanks a lot for offering to take care of patchwork for MM, and looking into this, Kieran! +10:01 < geertu> Yes, I think email is fine there. +10:01 < kbingham> We can add 'priorities' to the match to help determine which match wins based on a multiple match. +10:01 < geertu> Probably we also want to enable the patchbot, to mark superseded/applied patches automatically? +10:01 < kbingham> (or rather, which order the patterns are matched) +10:01 < kbingham> I believe I've already asked for patchbot to be added. +10:02 < kbingham> I don't know how we verify it's working yet though ... +10:02 < Marex> geertu: patchbot would be useful for u-boot too, link ? +10:02 < horms> kbingham: Is there an email outstanding for Geert and I to reply to? +10:03 < geertu> Marex: It's for kernel.org patchworks +10:03 < kbingham> horms, Only my latest status mail which had a short suggestion +10:03 < kbingham> I'll break out a new thread. +10:03 < Marex> geertu: proprietary ? +10:03 < geertu> kbingham: For linux-spi, I regularly see emails like https://spinics.net/lists/linux-spi/msg15473.html +10:04 < geertu> Marex: do you have a kernel.org account? +10:04 < geertu> Marex: https://korg.wiki.kernel.org/userdoc/pwbot +10:07 < geertu> Next Topic? +10:07 < geertu> Peripericon around FOSDEM +10:07 < kbingham> thread broken out on periperi for delegation +10:07 < horms> kbingham: thanks, will look at it +10:08 < Marex> geertu: I do +10:09 < pinchartl> Re: FOSDEM, I think we agreed on core + I/O meeting on Friday, global meeting on Sunday evening, and multimedia the next week +10:09 < pinchartl> is that correct ? +10:10 < wsa> yup +10:10 < kbingham> geertu, Aha - thanks - I didn't see there is some extra process to handle mappings to submit. +10:10 < geertu> Marex: In that case you should be on the mailing list (users@linux.kernel.org) where all of this is announced by Konstantin? +10:10 < geertu> Ah, so wsa is confirmed for Friday? +10:11 < Marex> geertu: probably, not like I read all those 200 mails I am CCed on, much less all the MLs +10:11 < kbingham> (re pw-bot) - I'll tackle it sometime over the holidays. but Konstantin is on holiday I think so he won't do much yet :) +10:11 < geertu> Who plans to attend FOSDEM? +10:11 < Marex> geertu: me +10:11 < uli_> +1 +10:11 < geertu> me +10:11 < pinchartl> I will be there from Sunday morning +10:11 < kbingham> o/ +10:11 < Marex> pinchartl: you miss the important part +10:11 < geertu> pinchartl: Unless we get elections that day? ;-) +10:12 < geertu> kbingham: o/ is yes or no? +10:12 < kbingham> yes :) +10:12 < pinchartl> geertu: that would surprise me :-) +10:12 < kbingham> it's raising my hand :) +10:12 < wsa> i'm there, too +10:12 < geertu> pinchartl: Yeah, too early +10:12 < pinchartl> so everybody but our Japanese friends will attend ? +10:12 < geertu> Anyone from JP? +10:13 < geertu> damm: ^ +10:13 < horms> pinchartl: I was hoping to go home on sunday evening. but don't let me change destiny +10:13 < morimoto> noone from JP +10:13 < Marex> :'-( +10:14 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has quit [Ping timeout: 268 seconds] +10:14 < geertu> damm doesn't want to answer? +10:14 < neg> I will arrive Thursday, at least that's my current plan +10:14 < pinchartl> horms: if I'm the only one not available at a more convenient time I can delegate my duties :-) +10:14 < geertu> I'll send an email to periperi +10:14 < geertu> sounds easier +10:15 < horms> good plan +10:15 < pinchartl> is the whole multimedia team OK with a multimedie meeting on Monday morning ? +10:16 < geertu> Anything else to discuss for core? +10:16 < geertu> Ah, next meeting +10:16 < wsa> pinchartl: last week, you were interested in CopyleftConf on Monday +10:16 * kbingham can do MM on the monday. +10:17 < geertu> Thursday January 3? or 10? or 17? When are the NY holidays in JP? +10:17 < neg> pinchartl: Monday morning works for me +10:17 * wsa votes for 3rd or 17th +10:17 < pinchartl> wsa: I was, but I don't think I should ask for the whole MM team to spend one extra day waiting for me :-) +10:17 < uli_> i have an appointment on the 3rd +10:18 < uli_> so i wouldn't be able to join until 11 or so +10:18 < uli_> 11am that is +10:18 < shimoda> JP side has a vacation from 28th Dec to 6th Jan. So, I prefer 10 or 17 +10:18 < Marex> I'll probably be on my way to LCA on 17th, so 10th would be great +10:19 < geertu> uli_: I thought 11 jan ;-) +10:20 < pinchartl> 10th sounds good to me +10:20 < kbingham> wsa, Something planned again on the 10th ? :) +10:20 < wsa> birthday :D +10:20 * kbingham knows ;) +10:20 < kbingham> jan-10 should be a global holiday really. It's too important a day :) +10:20 < geertu> kbingham: You get to talk more about periject as a BD present ;-) +10:20 < Marex> wsa: also a capricorn then ? +10:21 < wsa> kbingham: :D +10:21 < wsa> wsa: yeah, a very typical one, I'd think +10:22 < geertu> Are we finished (for core), and can I activate Laurent? +10:22 < horms> shimoda: are those holiday dates inclusive? +10:23 < pinchartl> geertu: what date have we picked for the next meeting ? +10:23 < geertu> pinchartl: kbingham day? +10:23 < shimoda> horms: sorry, I cannot understand your question. what is "those holiday dates"? +10:24 < horms> I mean: is the 28th the last day of work or the first day of holiday. Likewise for the 6th +10:25 < shimoda> horms: ah, those dates are inclusive. +10:25 < pinchartl> geertu: all 3 dates work for me +10:26 < shimoda> so, the first day of holiday is at 28th (someone is from 29th though) +10:26 < geertu> Let's pick the 10th +10:26 < horms> shimoda: thanks. enjoy the holiday! +10:26 < neg> 10th sounds good to me +10:26 < horms> can we add all meetings to the google calendar. It is tremendously useful to me +10:27 < Marex> horms: would be nice +10:27 < kbingham> horms, which google calendar? +10:27 < horms> lol +10:27 < shimoda> horms: thanks! +10:27 < wsa> kinda likely that the IO meeting will be email only then... +10:27 * kbingham agrees though :) +10:28 < geertu> kbingham: Morimoto-san's PeriPeri calendar +10:28 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20181220-io-chatlog b/wiki/Chat_log/20181220-io-chatlog new file mode 100644 index 0000000..9bcc8c7 --- /dev/null +++ b/wiki/Chat_log/20181220-io-chatlog @@ -0,0 +1,202 @@ +09:05 < wsa> welcome to the last IO meeting this year +09:05 -!- horms [~horms@2400:2650:39e2:a000:c685:8ff:fe7c:9971] has joined #periperi +09:05 < wsa> here are the status updates: +09:05 < wsa> Status updates +09:05 < wsa> ============== +09:05 < wsa> A - what have I done since last time +09:05 < wsa> ------------------------------------ +09:05 < wsa> Geert +09:05 < wsa> : resubmitted fixes for fallback to PIO in the sh-sci driver +09:05 < wsa> Kaneko-san +09:05 < wsa> : got r8a77990 I2C SYS-DMAC enablement merged +09:05 < wsa> Marek +09:05 < wsa> : adjusted the thermal API to handle per-driver parameters and converted drivers +09:05 < wsa> to use it, also reposted PCA953x PM patches +09:05 < wsa> Niklas +09:05 < wsa> : got all HS400 patches in an upstream tree merged (except for the final DT patch) +09:05 < wsa> Shimoda-san +09:05 < wsa> : investigate the PWM backlight issues and submitted a workaround patches, +09:05 < wsa> submitted an explanation of USB virtualization for eLinux, reviewed RZ/G2E USB +09:05 < wsa> related patches, investigating an issue that USB3 peripheral's transfer stops +09:05 < wsa> unexpectedly if g_ether/g_ncm is used, and investigate an issue that SCIF5 on +09:05 < wsa> R-Car E3 doesn't work with SYS-DMAC +09:05 < wsa> Simon +09:05 < wsa> : posted RAVB phy-mode and no-link patches for Ebisu and posted an RFC to fix +09:05 < wsa> the RAVB rx csum VLAN issue +09:05 < wsa> Wolfram +09:05 < wsa> : sent out two new series for I2C core suspend handling, implemented two scripts +09:05 < wsa> to convert data to periject, further discussed and reached agreement about +09:05 < wsa> watchdog suspend/resume handling and documented it properly, review of various +09:05 < wsa> patches including Marek's thermal series, looking for and sending out +09:05 < wsa> stalled patches +09:05 < wsa> B - what I want to do until next time +09:05 < wsa> ------------------------------------- +09:05 < wsa> Geert +09:05 < wsa> : wants to resubmit final patch for fallback to PIO in the sh-sci driver +09:05 < wsa> Kaneko-san +09:05 < wsa> : wants to +09:05 < wsa> Marek +09:05 < wsa> : wants to handle the thermal patchset feedback +09:05 < wsa> Shimoda-san +09:05 < wsa> : wants to ping the PWM maintainer if needed and continue to investigate +09:05 < wsa> the USB3 peripheral + g_ther/g_ncm issues +09:05 < wsa> Simon +09:05 < wsa> : wants to follow-up on RAVB rx csum for VLAN patch +09:05 < wsa> Wolfram +09:05 < wsa> : wants to keep at the I2C core suspend handling series, check upstream SDHI bug +09:05 < wsa> report about accessing large files, work on known IIC issues, upport I2C/SDHI +09:05 < wsa> patches +09:05 < wsa> C - problems I currently have +09:05 < wsa> ----------------------------- +09:05 < wsa> Simon +09:05 < wsa> : needs testing for his RAVB rx csum for VLAN patch +09:05 < wsa> Wolfram +09:05 < wsa> : got no response for my bsp-ticket-file to periject converter and no response to +09:05 < wsa> the mail I sent to the MM team about GMSL +09:06 < wsa> Kaneko-san's B) is still open because I wondered about the PWM on E3 (c.f. my mail) +09:06 < wsa> horms: you are waiting for the tests from the BSP team, right? +09:07 < horms> Yes. I can push the patch without such tests. But I'd rather not +09:08 < wsa> I agree +09:09 < wsa> shimoda: can you gently ping BSP team and/or Jinzo to test this patch? +09:10 < wsa> Marex: when do you think will the PCIe ATF code be upstream? +09:10 < shimoda> wsa: sorry, about what? +09:10 < wsa> shimoda: about the patch simon created for "[periperi] Cannot receive a Q-Tag VLAN flame on the ravb driver (#194782)" +09:11 < wsa> Marex: any rough estimate? +09:11 < Marex> wsa: as soon as I rework the patch on top of upstream ATF EA changes +09:11 < Marex> wsa: and then there's gonna be discussion for sure, since it's a bit controversial ... February-ish ? +09:12 < wsa> Marex: okay, thanx! +09:12 < shimoda> wsa: Jinso test team already tested the patch, so I believe he can submit Tested-by. So, I'll ask him. Also, I'll ask BSP team when they can test it. +09:12 < wsa> shimoda: ah, good news :) +09:12 < Marex> wsa: my understanding is that syncing upstream ATF with renesas ATF has higher prio, which is what I'm working on now +09:13 < wsa> Marex: I see, makes sense +09:13 < wsa> jmondi is not here now, so I'll skip the GMSL question for now +09:14 < wsa> geertu: about TDSEL, latest news look like we can implement initializing TDSEL for early ES versions. D'accord? +09:15 < geertu> wsa: Yeah, looks like that +09:15 < wsa> So, I could resend those with proper soc_device_match()? +09:15 < geertu> Yes please +09:15 < wsa> cool +09:15 < Marex> wsa: btw there's another ATF topic where upstream is concerned about renesas stuff -- whether the ATF code is properly locked out and cannot be read by later stages -- I need to check that +09:15 < horms> shimoda: thanks! +09:16 < wsa> Marex: yes. but that's more core stuff, or? +09:17 < wsa> any more IO related questions from your side? my next questions deal with periject, so I'd like to have technical discussions before that +09:17 < Marex> wsa: ask geertu :) +09:17 < wsa> :D +09:17 < Marex> wsa: I have a feeling U-Boot and ATF is kinda on the side and outside of the usual split :S +09:19 < wsa> kbingham: you there? +09:19 < wsa> pinchartl: and you? +09:19 < pinchartl> wsa: I am +09:20 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has quit Ping timeout: 250 seconds +09:20 < wsa> so, I wrote those two scripts. the second one needing a bugfix, still +09:20 < wsa> but in general, was it that what was desired? +09:21 < wsa> what are the next periject steps if so? +09:21 < pinchartl> I still need to check the second script +09:22 < pinchartl> regarding next steps +09:22 < pinchartl> we likely need a query tool +09:22 < pinchartl> but I think that can be developed as we go +09:22 < pinchartl> what I think is needed is proper integration of validation in the git commit hook +09:22 < pinchartl> and probably on the server side too +09:23 < pinchartl> I think it was Simon who raised the issue that uuids are not very usable (and I believe we pretty much all agree) +09:23 < pinchartl> so I think we should also try to replace that with a global ID at commit/push time +09:24 < pinchartl> I'm not sure if that can be done on the server side or just on the local side +09:24 < pinchartl> apart from that, I think we're ready to give it a try +09:24 < horms> (I don't think it was me) +09:25 < pinchartl> ok, could have been someone else :-) +09:25 < wsa> yes, i recall consensus that the unique-key should be generated at push-time +09:25 < pinchartl> one option would be this +09:25 < pinchartl> we create a file in the root directory of the git tree +09:26 < pinchartl> containing the next ID +09:26 < pinchartl> at commit time, a git hook could +09:26 < pinchartl> - fetch the latest version +09:26 < pinchartl> - increase the ID to reserve as many IDs as needed +09:26 < pinchartl> - push with non-fast-forward denied +09:27 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has joined #periperi +09:27 < pinchartl> - patch the content locally to replace uuids with ids +09:27 < pinchartl> - push +09:27 < pinchartl> that wouldn't require server-side hooks +09:27 < geertu> And if the push fails, retry? +09:27 * kbingham[m] just woke up... +09:28 < pinchartl> geertu: if the push fails it means there was a race, so retry +09:29 < wsa> why can't we use the sha from the commit? +09:30 < kbingham> I can't believe a uuid is any less unique than a sha1? +09:30 < pinchartl> wsa: it's not about unicity, it's about +09:31 < pinchartl> "can you look at ticket 37 ? I think it duplicates 31" +09:31 < pinchartl> vs. +09:31 < wsa> i see +09:31 < pinchartl> "can you look at ticket e2ebc538-9ca3-4cab-ac9f-70563fb95b40 ? I think it duplicates 97a5e041-7835-4a20-ab53-3d16c10081e3" +09:32 < kbingham> Oh - those ids :) +09:34 < wsa> but we all should be used to sha1 with abbrev 14? +09:34 < wsa> :) +09:34 < Marex> wsa: git will soon switch to sha256, so that might be a good idea :) +09:34 < geertu> They're as easy to remember as recent Renesas SoC part numbers ;) +09:35 < horms> I believe a key requirement of the project, which lead us to develop it rather than reuse an existing system, was for offline access. Thus the attraction of a sha, uuid, or similar +09:35 < wsa> morimoto: do you know when/if there will be a new ticket file? ticket file is "bsp370" but latest bsp is 3.9.2 +09:35 < geertu> We could start with sha1s, and run (atomically) a script to replace them by generated numbers at mdnight? +09:36 < pinchartl> horms: I think combining guids and global ids would be a good way to ensure both usability and offline access +09:36 < kbingham> Would that rewrite history ? or just do some magic to append a commit on top giving the id a number? +09:36 < pinchartl> we start with guids for anything new created locally +09:36 < geertu> So you can work offline, and once in a while the new commits get assigned an simpler ticket number (mapping file) +09:36 < kbingham> And if it's just a commit on top - couldn't that already 'just work' ? +09:36 < pinchartl> and they're replaced with ids when you push (which implies that you're online) +09:37 < pinchartl> kbingham: it could apply a commit on top +09:37 < pinchartl> or, as I explained, patch locally before pushing, in a local git hook +09:37 < pinchartl> I don't know if we can get access to server-side hooks +09:37 < geertu> When using a sha1, it would refer to the the sha1 of the original ticket at creation time anyway, while the ticket file itself can change later, right? +09:37 < pinchartl> or even whether server-side hooks would actually work best for what we're trying to do +09:37 < horms> pinchartl: fine, so long as there isn't a requirement to refer to gloabl ids before they are available - e.g. latency when using the debian bugtracker (maybe fixed by now) +09:38 < pinchartl> horms: I don't think we'll refer to guids in a shared environment anyway. if the guids are used locally and then patched when you push, you will have an id available as soon as the content is available to others +09:38 < geertu> I.e. all references can be to <sha1>|<Tn>, with <sha1> replaced by <Tn> over time +09:39 < pinchartl> so you would only need to use the guid during discussions if you want to refer to a ticket that hasn't been pushed yet +09:39 < pinchartl> which would cause the other party to have trouble looking at it anyway :-) +09:39 < horms> makes sense +09:40 < wsa> :) +09:40 < geertu> s/sha1/uuid/ to your liking +09:40 < pinchartl> geertu: or s/uuid/sha1/ +09:41 < geertu> "s" stands for symmetry ;-) +09:41 < pinchartl> :-) +09:41 < pinchartl> the issue with using sha1 is that they're not available before you coommit +09:41 < pinchartl> commit +09:41 < pinchartl> so if you want to commit two new tickets in one go, that refer to each other, it won't be possible with a git sha1 +09:42 < pinchartl> (whether we want to allow that is another question, but there could be other similar valid use cases) +09:42 < geertu> Do you need to have the sha1 of the ticket file before you add he ticket file? Or are all references added later? +09:42 < pinchartl> that's why we went for guid instead +09:42 < geertu> OK +09:42 < pinchartl> but if they're patched as soon as you push, I don't think that's a bit problem +09:42 < pinchartl> it will be very temporary +09:42 < morimoto> wsa: sorry for my late response. I don't know. I will ask to BSP team +09:42 * geertu discovers R-Car M3-W+ +09:42 < pinchartl> we could actually make it even simpler +09:42 < pinchartl> - have a serial number file containing the next ID +09:43 < pinchartl> - create tickets, allocate IDs from that file +09:43 < pinchartl> - at push time, fetch first, then compute the diff between local ID and server ID +09:43 < pinchartl> - increase all new local IDs by the diff +09:43 < pinchartl> (patching new tickets) +09:43 < pinchartl> - push +09:43 < pinchartl> something like that +09:43 < pinchartl> so we wouldn't need guids +09:44 < pinchartl> but the ids would only become meaningful globally when we push +09:44 < pinchartl> using guids as temporary ids makes it clear that they're temporary +09:44 < pinchartl> so it might be better +09:44 < geertu> That would be an additional commit on top, or an ammendment of the existing commits? +09:44 < pinchartl> (although we could prefix temporary numerical ids without something to make that clear too) +09:44 < geertu> The former makes it confusing if you look at history (oh, this old reference to #4 is now actually #7) +09:45 < pinchartl> if we run all this process on the client side, it would be nice if the scripts could rewrite the history +09:45 < geertu> The latter makes it impossible to share early with a team member (non-rebasing policy) +09:45 < pinchartl> if we run hooks on the server side it would likely need to be commits on top +09:46 < geertu> So there needs to be a clear distincation between temporary and final IDs +09:46 < geertu> (e.g. uuid or Tn for temporary, #n for final) +09:47 < pinchartl> it could be as simple as using T#n vs. #n, yes +09:47 < geertu> s/distincation/distinction +09:47 < pinchartl> or ~n, or whatever +09:49 < pinchartl> does this make sense ? +09:49 < geertu> yes, it does to me +09:49 < kbingham> pinchartl, We're looking forwards to the prototype :) +09:50 < geertu> Be prepared to discover bugs in the git hook implementation? ;-) +09:50 < pinchartl> I guess it's fair to assign it to me this time :-) +09:51 < pinchartl> I won't have time before the holidays though +09:51 < wsa> i'll update my second script before the holidays +09:51 < kbingham> It doesn't sound like it would take /too/ long to sketch out. +09:52 < pinchartl> kbingham: no, it shouldn't take /too/long +09:55 < wsa> so, we can conclude this io/periject meeting? +09:55 < pinchartl> I think so +09:55 < wsa> me too +09:56 < wsa> thank you everyone! diff --git a/wiki/Chat_log/20181220-mm-chatlog b/wiki/Chat_log/20181220-mm-chatlog new file mode 100644 index 0000000..cb9025e --- /dev/null +++ b/wiki/Chat_log/20181220-mm-chatlog @@ -0,0 +1,103 @@ +Multimedia-chat-meeting-2018-12-20 + +10:29 < pinchartl> welcome to the multimedia meeting +10:29 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:29 < pinchartl> * Kieran +10:29 < pinchartl> Since last meeting: +10:29 < pinchartl> - Got linux-media archives on lore.kernel.org +10:29 < pinchartl> - Got linux-renesas-soc archives on lore.kernel.org +10:29 < pinchartl> The archives can be accessed through NNTP at nntp.lore.kernel.org +10:29 < pinchartl> - Now a kernel.org patchwork maintainer for linux-renesas-soc +10:29 < pinchartl> With added admin rights. Trying to get auto-delegation sorted, rules to be discussed. +10:29 < pinchartl> - Periject schema patches updated and pushed to osdg.renesas.com +10:29 < pinchartl> - Patch review for media +10:29 < pinchartl> - Supported Marex with DU issues on linux-next +10:29 < pinchartl> Until next meeting: +10:29 < pinchartl> - Winter holidays break +10:29 < pinchartl> Issues and blockers: None +10:29 < pinchartl> kbingham: any comment ? +10:30 < kbingham> None right now no :) +10:30 < kbingham> except I'm very happy that we now have lore.kernel.org for linux-media/linux-renesas-soc :) +10:30 < pinchartl> :-) +10:30 < pinchartl> * Laurent +10:30 < pinchartl> Since last meeting: +10:30 < pinchartl> - Got DPAD output routing reviewed +10:30 < pinchartl> Will send pull request as soon as the v4.21 merge window closes. +10:30 < pinchartl> - Looked at how to use the same DOTCLKIN input for multiple DU channels +10:30 < pinchartl> This is work in progress. +10:30 < pinchartl> - VC5 suspend/resume review and testing +10:30 < pinchartl> - PWM pinmux review and testing +10:30 < pinchartl> - Patch review +10:30 < pinchartl> Until next meeting: +10:30 < pinchartl> - Use the same DOTCLKIN input for multiple DU channels +10:30 < pinchartl> Issues and blockers: None +10:30 < pinchartl> any question ? +10:31 < pinchartl> * Morimoto-san +10:31 < pinchartl> Since last meeting: +10:31 < pinchartl> - Updated audio-graph/simple sound card +10:31 < pinchartl> This is a major/common sound card driver, and is needed for ULCB-KF sound. The patches have been accepted. +10:31 < pinchartl> - Bugfix/cleanup for above sound card +10:31 < pinchartl> Patches are being posted. +10:31 < pinchartl> - Discussed with EAVB guys about clock tuning for sound +10:31 < pinchartl> Th current struct clk seems not to be a good match for it, maybe we need an EAVB special framework, and it seems ALSA SoC guys have already starting its discussion. +10:31 < pinchartl> Until next meeting: +10:31 < pinchartl> - Continue to post patches +10:31 < pinchartl> - Continue work on EAVB tuning +10:31 < pinchartl> Issues and Blockers: None +10:31 < pinchartl> morimoto: any comment ? +10:32 < morimoto> nothing. thanks +10:32 < pinchartl> * Niklas +10:32 < pinchartl> Since last meeting: +10:32 < pinchartl> - Finished VIN and CSI-2 suspend/resume support +10:32 < pinchartl> [PATCH 0/4] rcar-vin: add support for suspend and resume +10:32 < pinchartl> Until next meeting: +10:32 < pinchartl> - Try to push the VIN lockdep warning forward. +10:32 < pinchartl> Issues and Blockers: None +10:32 < pinchartl> neg: any comment ? +10:32 < neg> No comment +10:32 < pinchartl> * Ulrich +10:32 < pinchartl> Since last meeting: +10:32 < pinchartl> - Patch review +10:32 < pinchartl> Until next meeting: +10:32 < pinchartl> - Winter holidays break +10:32 < pinchartl> Issues and Blockers: None +10:32 < pinchartl> uli_: any comment ? +10:32 < uli_> nope +10:33 < pinchartl> * Jacopo +10:33 < pinchartl> Since last meeting: +10:33 < pinchartl> - E3 HDMI/CVBS support +10:33 < pinchartl> Support for E3 in rcar-csi2 merged. adv748x dynamic routing is ongoing, patches have been posted in "[PATCH 0/5] media: adv748x: Implement dynamic routing support" +10:33 < pinchartl> Until next meeting: +10:33 < pinchartl> - Possibly a respin of adv748x routing series +10:33 < pinchartl> - Long term plan: add a v4l2 operation for negotiation of CSI-2 data lanes +10:33 < pinchartl> - Reply to Wolfram and keep an eye on GMSL discussions +10:33 < pinchartl> Issues and blockers: +10:33 < pinchartl> - Not much time left until end of year. +10:33 < pinchartl> jmondi: are you back ? +10:34 < pinchartl> doesn't seem so +10:34 < pinchartl> Topic 2. peripericon @FOSDEM 2019 +10:34 < pinchartl> we've already covered this as part of the core meeting +10:34 < pinchartl> we will have our multimedia meeting on Monday morning right after the FOSDEM +10:35 < pinchartl> any comment/question/issue ? +10:36 < neg> None from me +10:37 < pinchartl> alright +10:37 < pinchartl> next topic, discussions +10:37 < pinchartl> anything to discuss today ? +10:37 < kbingham> we'll need to sort next Q's AT's - but I think that can be deferred for now. +10:38 < pinchartl> I'll send a mail to Magnus +10:39 < pinchartl> morimoto: do you know what the plan is for next quarter's additional tasks ? +10:40 < morimoto> We need to talk with Magnus +10:40 * geertu thought magnus would attend FOSDEM +10:42 < pinchartl> ok, then we'll talk to Magnus +10:42 < pinchartl> that's it for today +10:43 < pinchartl> next meeting will be on the 10th of January, same time +10:43 < pinchartl> I proposed adjourning this meeting. does anyone seconod ? +10:43 < pinchartl> s/seconod/second/ +10:43 < neg> second +10:43 < kbingham> third +10:44 < pinchartl> meeting adjourned +10:44 < pinchartl> thank you all for attending +10:44 < pinchartl> and have a merry christmas and a happy new year ! +10:45 < neg> Thanks all, and a happy xmas and a happy new year +10:47 < kbingham> Cheers all +10:48 < uli_> see you next year diff --git a/wiki/Chat_log/20190110-core-chatlog b/wiki/Chat_log/20190110-core-chatlog new file mode 100644 index 0000000..b384199 --- /dev/null +++ b/wiki/Chat_log/20190110-core-chatlog @@ -0,0 +1,124 @@ +09:30 < geertu> Welcome to today's core group chat! +09:31 < geertu> damm: Yes, happy evening ;-) +09:31 < geertu> Agenda: +09:31 < geertu> 1. Status Updates +09:31 < geertu> 2. Discussion Topics +09:32 < geertu> Topic 1. Status updates +09:32 < geertu> A) What have we done since last time: +09:32 < geertu> Kaneko-san upported thermal zone IPA support. +09:32 < geertu> Marek worked on ATF (upstream Renesas patches, TravisCI, +09:32 < geertu> D3/Eagle/Condor), SPL and ATF BL2 integration for U-Boot, and fixed +09:32 < geertu> Ebisu eMMC breakage in Linux. +09:32 < geertu> Shimoda-san discovered dmatest issues. +09:32 < geertu> Simon enabled R-Car thermal support in the arm64 defconfig. +09:32 < geertu> Geert verified MOD_SEL bitfield order on E3, resubmitted the QEMU patch +09:32 < geertu> for instantiating generic devices from DT, and worked on fixing +09:32 < geertu> kselftest builds. +09:32 < geertu> B) What we plan to do till next time: +09:32 < geertu> Kaneko-san plans to add DRIF and TMU support to the E3 and M3-N PFC +09:32 < geertu> drivers. +09:32 < geertu> Marek plans to check the ATF patchset with Morimoto-san, debug eMMC +09:32 < geertu> issues in U-Boot, and will speak at LCA about U-Boot. +09:32 < geertu> Shimoda-san plans to continue to make an IPMMU driver's plan with +09:32 < geertu> Magnus-san. +09:32 < geertu> Simon will follow up Ebisu PMIC enablement. +09:32 < geertu> Ulrich will follow up on unmerged patches. +09:32 < geertu> Geert plans to submit kselftest fixes, improve pinctrl table validation, +09:32 < geertu> and may work on IPMMU suspend/resume. +09:34 < geertu> C) Problems we have currently: +09:34 < geertu> Kaneko-san is eagerly awaiting review of IPA patches. +09:34 < geertu> Geert wonders how to verify MOD_SEL bitfield order on D3. +09:34 < geertu> --- +09:34 < geertu> Anything I missed? +09:35 < geertu> Topic 2. Discussion Topics +09:35 < geertu> I'm open for topics +09:36 < shimoda> I have a topic. this is from BSP team question today. +09:36 < horms> Is it appropriate to discuss Z2 clock for or CPUIdle for R-Car Gen3 +09:37 < geertu> Sure. +09:37 < shimoda> this is not important for arm64, but bsp team wonder if how to handle more than 2GHz on .round_rate callback on 32-bit arch +09:37 < geertu> I think Shimoda-san was first +09:38 < shimoda> because .round_rate return type is just long ,not long long +09:38 < shimoda> on 32-bit arch, we don't have any 2GHz CPU ? :) +09:39 < shimoda> s/CPU/CPU and internal busses/ +09:39 < geertu> This is indeed a serious issue. I think it should be taken up with the clock maintainers. +09:40 < geertu> Usually the rate is unsigned long, but there are a few places where long is used. +09:40 < shimoda> why BSP team realized this topic because they used static analyses (QAC) +09:41 < geertu> If long is used, a negative value is used to indicate an error code. +09:41 < geertu> Since error codes are small negative numbers, one approach to solve this would be similar to IS_ERR(), which uses +09:41 < geertu> #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO) +09:42 < geertu> with MAX_ERRNO = 4095, that would allow up to 4.2 GHz. +09:42 < geertu> Of course doing that would require many changes in code handling long rates, plus it's not a final solution. +09:43 < Marex> shimoda: maybe you can compile 32bit kernel and run it on H3 in 32bit mode ? +09:43 < Marex> shimoda: at least raspi3 is capable of running 32bit kernel on arm64 CPU, and H3 has some 3.2 GHz bus in it IIRC +09:43 < geertu> IIRC, the general census (hope?) was that high-rate clocks are contained on 64-bit architectures, where long is 64-bit +09:44 < shimoda> Marex: yes, but I never try it though. +09:44 < geertu> Marex: Even the old Cell Broadband Engine ran at 3.2 GHz +09:44 < Marex> geertu: the VC5 also has ~2.9GHz PLL and it can be well connected to 32bit CPU +09:45 < Marex> I guess there are many 32bit systems with > 2GHz clock +09:46 < geertu> [PATCH v2 00/34] change clk_ops->round_rate to scale past LONG_MAX +09:46 < geertu> https://lore.kernel.org/lkml/1514833681-30737-1-git-send-email-pure.logic@nexus-software.ie/ +09:47 < geertu> v1 did fave feedback +09:47 < geertu> https://lore.kernel.org/lkml/20180102190159.GH7997@codeaurora.org/ +09:47 < Marex> shimoda: I didn't try it either, I'd expect a few things to break there too +09:48 < geertu> implement the determine_rate op instead of the +09:48 < geertu> round_rate op +09:50 < geertu> None of the drivers/clk/renesas/ drivers implement that yet +09:50 < geertu> So that seems the way to go, for now. +09:51 < shimoda> geertu: oh, thank you for the information! so, now we can use up to 4GHz on 32bit arch if we add the determine_rate op on drivers/clk/renesas +09:51 < geertu> shimoda: Does that answe your question? +09:51 < shimoda> geertu: yes, thanks! +09:51 < Marex> geertu: isn't that more of a workaround ? +09:52 < geertu> Marex: More or less. I gains us a factor 2, until everything is 64-bit and Y2038-compliant +09:52 < geertu> s/I/It/ +09:53 < geertu> horms: Next topic? +09:53 < Marex> btw I think the realtime core in Gen3 is 32bit and can run Linux ? +09:53 < geertu> Marex: I guess it can. Same for the RT on older SoCs +09:53 < horms> geertu: uli___: is there a prospect of including Z2 support for R-Car Gen3? This came up for me while scaning BSP patches for E3 +09:54 < uli___> if that's desired, sure +09:54 < Marex> geertu: older SoCs don't have fast PLLs like the Gen3, so they clock code there won't fail +09:55 < Marex> shimoda: thank you for the M3W SDHI suggestion, I'll check it today-ish :-) +09:55 < geertu> uli___: IIRC, you posted Z (ZG?) patches that have review comments? +09:55 < uli___> zg, iirc +09:56 < uli___> as mentioned in the update, i'll review my unmerged patches next +09:56 < geertu> uli___: OK, thanks! +09:57 < horms> ok great. my main aim in bringing this up was to avoid duplication of effort +09:57 < horms> geertu: do we know anything about if CPUIdle can be enabled on R-Car Gen3. Again question generated by BSP hunting +09:58 < geertu> horms: You mean e.g. a2e020874a4ad69a ("arm64: dts: r8a7796-m3ulcb: Disable CPUIdle support for CA53") in the BSP? +09:58 < geertu> Which claims it;s not supported on ES1, but doesn't tell why? +09:59 < shimoda> Marex: you're welcome! :) +09:59 < horms> I was thinking more of: +09:59 < horms> $ git log --oneline --grep=CPUIdle master..rcar-3.9.2 +09:59 < horms> df0d0ecb5f8a arm64: dts: r8a7796-m3ulcb: Disable CPUIdle support for CA53 +09:59 < horms> b96175039caa arm64: dts: r8a77990: Add CPUIdle support for CA53 +09:59 < horms> c635f6a8ad20 arm64: dts: r8a77965: Add CPUIdle support for CA57 +09:59 < horms> 902ff7caa32d arm64: dts: r8a7796: Add CPUIdle support for all CPU core +09:59 < horms> 3c3b44c752c4 arm64: dts: r8a7795: Add CPUIdle support for all CPU core +10:01 < horms> Perhaps a way forward would be ask for clarification on which SoCs+ES versions the feature is supported +10:02 < geertu> df0d0ecb5f8a is the same (rebased bsp versus periupport) +10:03 < geertu> So yes, we need clarification +10:03 < horms> sorry, i meant to aknowledge that the patch is the same +10:03 < horms> shimoda: morimoto: could we ask for such clarification? +10:03 < geertu> Ah, uli___ seems to have submitted these before, in Aug +10:04 < horms> ok, my bad again for not having remembered that +10:04 < geertu> To which I replied (incl. Kihara-san, Diem-san, Khiem-san): +10:04 < geertu> Given many Salvator-X boards (incl. mine) also have M3-W ES1.0, and PSCI is +10:04 < geertu> involved, I have to ask: is this a hardware (M3-W ES1.0) or firmware (PSCI) +10:04 < geertu> issue? +10:05 < horms> I think the slightly bigger picture is that we are getting rather close to parity between upstream and the BSP in so far as features that are appropriate for upstream +10:05 < horms> That is, for E3 +10:05 < geertu> true +10:05 < geertu> s/Diem/Dien/ +10:05 < horms> I agree with your question +10:06 < horms> My assumption is that it is not addressed in the BSP because Slavator-X boards are assumed to have more recent SoCs than ES1 +10:06 < horms> s/1/1.0/ +10:06 < horms> But its just an assumption +10:06 < horms> so clarification seems very appropriate +10:07 < geertu> Commerically-available boards are ULCB +10:07 < horms> Perhaps we can just add this to the minutes +10:07 < geertu> and the first patch disables it on r8a7796-m3ulcb +10:07 < horms> Its not urgent +10:07 < geertu> OK, will do. +10:07 < horms> Also, I had no other topics +10:07 < geertu> Any other topics? +10:07 < geertu> If not, I'll pass the em-eye-see to pinchartl +10:08 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20190110-mm-chatlog b/wiki/Chat_log/20190110-mm-chatlog new file mode 100644 index 0000000..a3d7f8e --- /dev/null +++ b/wiki/Chat_log/20190110-mm-chatlog @@ -0,0 +1,116 @@ +Multimedia-chat-meeting-2019-01-10 + +10:08 < pinchartl> welcome to the multimedia meeting +10:08 * geertu is muted +10:08 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:08 < pinchartl> * Jacopo +10:08 < pinchartl> Since last meeting: +10:08 < pinchartl> - v2 of adv748x dynamic routing to support E3 CVBS input +10:08 < pinchartl> Until next meeting: +10:08 < pinchartl> - v3 of adv748x dynamic routing +10:08 < pinchartl> - Propose a V4L2 API to dynamically negotiate the number of CSI-2 data lanes +10:08 < pinchartl> Issues and blockers: None +10:08 < pinchartl> jmondi: any comment ? +10:09 < jmondi> geertu: mic drop https://tenor.com/view/drop-the-mic-mic-drop-gif-10994492 +10:09 < jmondi> pinchartl: not really, I would need some guidance on how to make that v4l2 sub consumable +10:10 < pinchartl> have you talked to Sakari about it ? +10:10 < jmondi> pinchartl: not yet +10:10 < jmondi> should I ping him first? +10:10 < pinchartl> I think that would be a good first step. I can join the discussiong if you want +10:11 < jmondi> ok, I'll try to get a hold of him on #v4l +10:11 * kbingham tucks in to birthday breakfast waffles +10:11 < morimoto> Happy Birthday, kbingham +10:12 < pinchartl> * Kieran +10:12 < pinchartl> Since last meeting: +10:12 < pinchartl> - Christmas holidays +10:12 < pinchartl> - Patch review for adv748x series +10:12 < pinchartl> - DRM patch review +10:12 < pinchartl> - FOSDEM travel arrangements +10:12 < pinchartl> Until next meeting: +10:12 < pinchartl> - Celebrate birthday with best wishes from the whole team +10:12 < pinchartl> - Work through media upport patches +10:12 < pinchartl> Issues and blockers: +10:12 < pinchartl> - Turning one year older every year +10:12 < kbingham> morimoto, Domo arigato :) +10:12 < pinchartl> kbingham: happy birthday :-) +10:13 < kbingham> status updates seem accurate :) +10:13 < kbingham> cheers :) +10:13 < pinchartl> * Laurent +10:13 < pinchartl> Since last meeting: +10:13 < pinchartl> - Patch review +10:13 < pinchartl> - Christmas holidays +10:13 < pinchartl> Until next meeting: +10:13 < pinchartl> - Use the same DOTCLKIN input for multiple DU channels +10:13 < pinchartl> - D3/E3 VGA output support +10:13 < pinchartl> Issues and blockers: None +10:13 < pinchartl> any question ? +10:14 < pinchartl> * Morimoto-san +10:14 < pinchartl> Since last meeting: +10:14 < pinchartl> - Created new year for the people +10:14 < pinchartl> - All posted sound patches are accepted +10:14 < pinchartl> - Worked on ALSA SoC framework cleanup +10:14 < pinchartl> Until next meeting: +10:14 < pinchartl> - Solve a reported issue with ALSA SoC kernel module +10:14 < pinchartl> Issues and Blockers: None +10:14 < pinchartl> morimoto: any comment ? +10:15 < morimoto> no, thanks +10:15 < pinchartl> * Niklas +10:15 < pinchartl> Since last meeting: +10:15 < pinchartl> - [PATCH] rcar-vin: remove unneeded locking in async callbacks +10:15 < pinchartl> Until next meeting: +10:15 < pinchartl> - Clean up the VIN crop and compose code +10:15 < pinchartl> This is needed to make it easier to merge UDS and PM support. +10:15 < pinchartl> Issues and Blockers: None +10:15 < pinchartl> neg: any comment ? +10:15 < neg> You are set as Delegate for the multiplexed stream series, I plan to respin that soon-ish anthing I can do to expidite the merge of it as it's rather large? +10:16 < pinchartl> oh, am I ? +10:16 < pinchartl> I'll review it today +10:16 < neg> Ohh maybe I just took to first step then :-) We can get back to it once you had a look at it :-) No other comment +10:16 < pinchartl> :-) +10:17 < pinchartl> thank you +10:17 < pinchartl> uli___: if I'm not mistaken you had nothing to report for multimedia, right ? +10:17 < uli___> correct +10:18 < pinchartl> ok, thank you +10:18 < pinchartl> Topic 2. Discussions +10:18 < pinchartl> any discussion topic ? +10:19 < neg> Kick off agenda planing for the FOSDEM meeting? Or maybe we can do that on ML +10:20 < pinchartl> I was planning to do so on the list +10:20 < pinchartl> but we can start now :-) +10:21 < pinchartl> I'll include a call for topic in the group chat report in any case +10:22 < pinchartl> speaking of the meeting, I want to point out that the date has been moved from Monday the 4th to Tuesday the 5th +10:22 < kbingham> I feel like we need to do a structured review of what work we need to plan for upporting. (i.e. probably a fosdem-mm topic) +10:22 < neg> I would like to do add some sort of up-port status item, so we can try and quantify how much work is left to close the gap between BSP and upstream and if needed discuss patches/features who should not be upstreamed +10:22 < kbingham> ha +10:22 < kbingham> +1 then :) +10:23 < neg> kbingham: :-) +10:23 < pinchartl> :-) +10:24 < jmondi> I'll add my +1 to both neg and kbingham +10:25 < pinchartl> we can discuss other topics on the list +10:25 < kbingham> ack. +10:27 < neg> I have no other discussion topic to bring up +10:29 < horms> neg: could you review the "IPA" patches on the ML? +10:29 < kbingham> I have candles to blow out so I guess we can keep it short this week ;) +10:29 < geertu> kbingham: Happy Birthday! +10:29 < pinchartl> if there are no other discussion topics, I think it's time for https://www.youtube.com/watch?v=HQ0_it5Y0Ds to celebrate Kieran's and Wolfram's birthdays +10:29 < pinchartl> although, in the purest Finnish tradition, https://www.youtube.com/watch?v=0qNVQgOYaJo would be more appropriate +10:30 < neg> horms: sure, can you give me the subject of the cover-letter so I can dig it out? +10:30 < kbingham> geertu, :D +10:30 < kbingham> pinchartl, I'm a bit scared by that kitten :) +10:31 < jmondi> kbingham: you should see the second video he linked then +10:31 < horms> Cover letter seems absent but first patch in the thread is: [PATCH/RFT] arm64: dts: renesas: r8a7795: Create thermal zone to support IPA +10:31 < kbingham> jmondi, yeah ... I'm just regretting clicking on that now. +10:31 < pinchartl> :-) +10:31 < horms> neg: thanks. see above +10:31 < neg> pinchartl: that sums up my view of the proud Finnish people quiet nicely ;-) +10:31 < pinchartl> I will leave those two videos from the chat report :-) +10:32 < neg> horms: thanks, I will get to it today +10:32 < horms> thanks neg +10:33 < pinchartl> I propose adjourning the meeting. does anyone second ? +10:33 < jmondi> magnus did +10:34 < jmondi> ah no, he's back +10:34 < jmondi> damm: Hi Magnus o/~ +10:34 < jmondi> pinchartl: seconded btw +10:34 < neg> second +10:34 < morimoto> 2nd +10:34 < kbingham> Cheers all! have a good day :) +10:34 < pinchartl> meeting adjourned. thank you all for attending diff --git a/wiki/Chat_log/20190124-core-chatlog b/wiki/Chat_log/20190124-core-chatlog new file mode 100644 index 0000000..69bd736 --- /dev/null +++ b/wiki/Chat_log/20190124-core-chatlog @@ -0,0 +1,64 @@ +09:44 < geertu> Welcome to today's Core Group Chat! +09:44 < geertu> Agenda: +09:44 < geertu> 1. Status Updates +09:44 < geertu> 2. Discussion Topics +09:44 < geertu> Topic 1. Status updates +09:44 < geertu> A) What have we done since last time: +09:44 < geertu> Kaneko-san posted CPUFreq DT and DRIF/TMU PFC patches for R-ar E3. +09:44 < geertu> Marek attended LCA, where he presented about U-Boot, fixed SDHI DMA issues in +09:44 < geertu> U-Boot, and investigated Renesas ATF patches. +09:44 < geertu> Morimoto-san published the BSP 3.9.2 upport request. +09:44 < geertu> Shimoda-san investigated and fixed dmatest test procedure issues, discussed +09:44 < geertu> with Magnus the IPMMU improvement plan, and submitted a fix for usb-dmac +09:44 < geertu> suspend/resume. +09:44 < geertu> Ulrich sent v2 of cpuidle support for R-Car H3 and M3-W. +09:44 < geertu> Geert booked PeriPeriBE(IO/Core/Global) Meeting and Dinner, and submitted +09:44 < geertu> pinctrl and kselftest patches. +09:45 < geertu> B) What we plan to do till next time: +09:45 < geertu> Kaneko-san will follow up on review of PFC patches, and will upport similar +09:45 < geertu> work for R-Car M3-N. +09:45 < geertu> Marek will degrade eMMC to HS mode in U-Boot, before booting Linux. +09:45 < geertu> Niklas will attend periperi meetings and FOSDEM. +09:45 < geertu> Simon will follow-up R-Car E3 PMIC enablement and thermal zone IPA, and plans +09:45 < geertu> to test R-Car E3 CPUFreq. +09:45 < geertu> Ulrich will prepare for FOSDEM. +09:45 < geertu> Geert plans to submit clk/pfc pull requests for v5.1, present about QEMU +09:45 < geertu> device-passthrough at FOSDEM, attend PeriPeriBE and FOSDEM, submit more pinctrl +09:45 < geertu> fixes, and may work on IPMMU suspend/resume. +09:47 < geertu> C) Problems we have currently: +09:47 < geertu> Niklas will be in Brussels from Jan 29th -- Feb 10th, affecting his output. +09:47 < geertu> Simon needs to upgrade firmware on Ebisu, and to confirm which SoCs/ES versions +09:47 < geertu> support CPUIdle. +09:47 < geertu> Anything I missed? +09:47 < geertu> Upgrading frimware can be pain. I still have to upgrade my Ebisu, and do a new run on the Salvator-* boards. +09:47 < geertu> s/pain/a pain/ +09:49 < geertu> Topic 2. Discussion Topics +09:49 < geertu> A) PeriPeriBE agenda +09:50 < geertu> Is there anything specific you want to discuss at the PeriPeri Core or Global meeting? +09:50 < pinchartl> for the global meeting: +09:50 < pinchartl> - periject +09:50 < geertu> Personally, I'm interested in the long-awaited IPMMU plan +09:51 < pinchartl> - plans for the next quarters +09:51 < geertu> definitely +09:52 < geertu> Virtualization status and future plan? +09:53 < pinchartl> it would be nice to have feedback from Renesas for that +09:54 < geertu> Status hasn't changed much from Edinburgh, so that can be used as a basis for feedback +09:58 < geertu> Anything else for PeriPeriBE? +09:59 < geertu> Anything else for today? +10:00 < pinchartl> next meeting after the FOSDEM ? +10:00 < pinchartl> 2019-02-21 ? +10:00 < geertu> What about in 3 weeks? +10:00 < geertu> Oh, 4 weeks? +10:02 < geertu> Both are fine for me +10:02 < geertu> wsa_: ^ +10:03 < wsa_> well, shimoda-san checking +10:03 < wsa_> dljslkjdflk +10:03 < wsa_> checking +10:04 < wsa_> 4 weeks would be better for me +10:04 < wsa_> 2019-02-21 +10:04 < pinchartl> sounds good to me +10:04 < neg> wsa_: I'm not sure I want to work on the dljslkjdflk driver, sounds messy :-) +10:05 < geertu> OK, 4 weeks +10:05 < wsa_> neg: it's a breeze compared to SDHI ;) +10:06 < morimoto> wsa_: :) +10:06 < geertu> Thanks for joining, have a nice continued day, and see most of you in Brussels! diff --git a/wiki/Chat_log/20190124-io-chatlog b/wiki/Chat_log/20190124-io-chatlog new file mode 100644 index 0000000..1159b6e --- /dev/null +++ b/wiki/Chat_log/20190124-io-chatlog @@ -0,0 +1,143 @@ +09:02 < wsa_> welcome to the IO meeting +09:02 < geertu> Even without me screwing up the meeting time(zone)s +09:02 < wsa_> here is the status update: +09:03 < wsa_> Status updates +09:03 < wsa_> ============== +09:03 < wsa_> A - what have I done since last time +09:03 < wsa_> ------------------------------------ +09:03 < wsa_> Geert +09:03 < wsa_> : tested HSCIF on Bock-W +09:03 < wsa_> Kaneko-san +09:03 < wsa_> : +09:03 < wsa_> Niklas +09:03 < wsa_> : investigated the SDHI clk imbalance issues further +09:03 < wsa_> Shimoda-san +09:03 < wsa_> : worked on various USB issues, handled Wolfram's questions to the BSP team, +09:03 < wsa_> and is improving Gen3 PHY USB2 driver to work with virtualized environments +09:03 < wsa_> Simon +09:03 < wsa_> : +09:03 < wsa_> Ulrich +09:03 < wsa_> : +09:03 < wsa_> Wolfram +09:03 < wsa_> : merged the I2C core suspend handling series, refactored parts of the IIC +09:03 < wsa_> driver to prepare it for upcoming changes, cleaned up i2c-gpio and algo-bit, +09:03 < wsa_> added an 'arbitration lost' fault injector on top of that, started upporting +09:03 < wsa_> I2C patches from bsp392, reviewed Niklas' SDHI series fixing clock imbalance +09:03 < wsa_> and Simon's E3 SDHI enablement, updated the periject converter for BSP ticket +09:03 < wsa_> files, merged older comments into the new bsp392 ticket file, helped organizing +09:03 < wsa_> the PeriPeriBE meetings +09:03 < wsa_> B - what I want to do until next time +09:03 < wsa_> ------------------------------------- +09:03 < wsa_> Geert +09:03 < wsa_> : wants to test at25 spimem conversion +09:03 < wsa_> Kaneko-san +09:03 < wsa_> : wants to +09:03 < wsa_> Niklas +09:03 < wsa_> : wants to attend PeriPeriBE and FSODEM +09:03 < wsa_> Shimoda-san +09:03 < wsa_> : wants to work on PWM suspend/resume once his atomic API patches are merged, +09:03 < wsa_> and to continue the USB PHY virtualization work +09:03 < wsa_> Simon +09:03 < wsa_> : wants to +09:03 < wsa_> Ulrich +09:03 < wsa_> : wants to +09:03 < wsa_> Wolfram +09:03 < wsa_> : wants to fix remaining flaws of periject converter, fix arbitration lost and +09:03 < wsa_> NACK handling on IIC, continue upporting I2C patches, participate in +09:03 < wsa_> PeriPeriBE and FOSDEM meetings +09:03 < wsa_> C - problems I currently have +09:03 < wsa_> ----------------------------- +09:03 < wsa_> Niklas +09:03 < wsa_> : needs access to ape6emv or kzm9g to continue working on the SDHI clk +09:03 < wsa_> imbalance issue +09:03 < wsa_> Wolfram +09:03 < wsa_> : got no response from some developers about their status/availability and also +09:03 < wsa_> biweekly status reports are getting in late sometimes. +09:04 < wsa_> There are no updates from uli_ and horms yet, they came too late for this summary. I will add them later. But next time, please send them a day before +09:05 < horms> sorry about that +09:05 < uli_> ok +09:05 < wsa_> thanks! +09:06 < morimoto> Unfortunately, shimoda-san can't joint today. He caught a cold, and backed to his home. +09:06 < wsa_> So, why is Bock-W hot again? I seem to have missed something :) +09:06 < wsa_> morimoto: thanks for telling. I hope he gets well soon +09:07 < morimoto> Yeah, thanks +09:07 < geertu> wsa_: It was an old patch I had applied locally, and finally got to testing when Bock-W became avaiable. +09:08 < wsa_> about neg's hw request: according to our wiki pinchartl has a kzm9g and uli_ has a ape6evm. Are those available for a short exchange? +09:08 < geertu> s/avaiable/available again/ +09:08 < wsa_> I assume geertu's boards are heavily built into his testing rack +09:08 < geertu> wsa_: I already asked dammsan if he could bring a few to Brussels +09:09 < geertu> If that fails, I can bring mine to Brussels. +09:09 < geertu> AFAIU, Niklas will have almost 2 weeks to play with it ;-) +09:09 < neg> ;-) +09:10 < horms> I recently sent my kzm9g and ape6evm to Magnus +09:10 < geertu> But given there are rumours about a big stockpile in JP, I prefer that solution, for the long run +09:10 < wsa_> Is there a MM codecamp after FOSDEM in Brussels or is neg so excited about the Belgian weather in February? :D +09:10 < horms> The later was very large +09:10 < wsa_> geertu: a few = BockW? +09:11 < neg> wsa_: I miss the pig, so I will try to track it down :-) +09:11 < geertu> wsa_: a few = APE6EVM +09:11 < wsa_> damm: is that likely to happen? +09:13 < damm> yes +09:13 < geertu> damm: Thx! +09:13 < wsa_> horms: the bsp392 ticket files has a few new ravb & thermal patches which look to me like good material for you and/or Kaneko-san. Can you check? +09:14 < horms> Sure, can do +09:14 < wsa_> so: damm brings neg a APE6EVM to Brussels? Correct? +09:14 < wsa_> horms: thanks! +09:14 < damm> it is not allowed to export those most likely, but renesas mobile does no longer exist. i plan on bringing some for demonstration purpose and plese remind me to bring them back so i don't forget =) +09:15 < geertu> damm: If you plan to get them into the UK, better hurry up ;-) +09:15 < damm> indeed =) +09:15 < wsa_> damm: we will surely do that! :) +09:15 < damm> =) +09:16 < wsa_> geertu: about the tee driver, are we aligned this is core realm? +09:16 < neg> damm: :-) +09:17 < geertu> wsa_: Is this implemented in all firmware versions? +09:17 < geertu> wsa_: But yes, this smells like core +09:18 < wsa_> yes, we surely need to find out the true status for upporting +09:19 < wsa_> But I first wanted to make sure it doesn't fall through the cracks because it is surprisingly (to me) still in bsp392 +09:20 < geertu> wsa_: The TEE tasks are yellow, not red +09:20 < geertu> "Because the upstream policy of the driver is unknown" +09:21 < wsa_> true, yet they have non-"N" prio +09:21 < wsa_> o +09:22 < wsa_> but yeah, it is not urgent otherwise we would know about it... +09:22 < wsa_> are there any questions from your side? +09:22 < wsa_> I have only periject on my agenda, not sure if pinchartl is ATK now... +09:24 < wsa_> pinchartl: ? +09:24 < geertu> Any I/O topics for the PeriPeriBE agenda? +09:26 < wsa_> yes, so far, the I2C/GMSL discussion and short lookahead (tasks / add tasks) +09:26 < horms> Perhaps not for that agenda but I am wondering what if anything we want to do to investigate HS500 performance on E3 +09:27 < wsa_> yeah, that would be a good topic, too +09:27 < wsa_> especially to sync with Marek's SDHI experiences on U-Boot +09:27 < pinchartl> wsa_: hello +09:27 < pinchartl> sorry for the delay +09:29 < wsa_> pinchartl: we'll soon switch to periject ;) +09:30 < wsa_> horms: do you have time to validate your measurement with other Gen3 HW? +09:31 < horms> Sure, I can do some tests on my local boards +09:31 < wsa_> so, i think the new bsp392 ticket file might be a good occasion to switch to periject. +09:31 < wsa_> opinions on that? +09:32 < wsa_> horms: cool, thanks! +09:32 < horms> That would be Salvator-XS/H3 ES2.0, Salvator-X/M3-W ES1.0 and Salvator-XS/M3-N ES1.0 +09:33 < horms> I'll collect some resulds and report back +09:33 < wsa_> thanks! +09:33 < geertu> I think you need to use the latest ATF for all benchmarks. +09:34 < geertu> ATF programs QoS. +09:34 < wsa_> Note that HS400 will be rejected on M3-W1.0 +09:35 < wsa_> pinchartl: gone again? +09:35 < horms> Ok, I will not test on that platform +09:35 < wsa_> let's continue with the core meeting then if there are no other questions? +09:36 < pinchartl> wsa_: I'm here +09:37 < wsa_> pinchartl: morimoto: geertu: what do you think about testing periject with bsp392? +09:38 < morimoto> It is nice idea for me :) +09:38 < pinchartl> I think it's a good idea too +09:38 < geertu> geertu: Fine for me! +09:39 < wsa_> good, then I will fix the remaining issues of the script till weekend +09:39 < pinchartl> we most probably want task patches to be reviewed with even more scrutiny than usual, as there will be discussions about the processs and the format +09:39 < pinchartl> once the script is ready I think group leaders could start creating tasks +09:40 < pinchartl> we're still missing the commit hook that will turn guids into integer ids, right ? +09:40 < wsa_> there are issues left with multiple "B:" and "U:" entries. And I will also check setting the task status automatically +09:40 < wsa_> pinchartl: i think so +09:42 < wsa_> so we can play around with it next week and discuss first results at the global meeting +09:42 < wsa_> sounds good to me +09:42 < geertu> Great! +09:43 < wsa_> good, then i think it is time to get to the core +09:43 < wsa_> :D +09:43 < wsa_> geertu: have fun diff --git a/wiki/Chat_log/20190124-mm-chatlog b/wiki/Chat_log/20190124-mm-chatlog new file mode 100644 index 0000000..b6a4ffa --- /dev/null +++ b/wiki/Chat_log/20190124-mm-chatlog @@ -0,0 +1,167 @@ +Multimedia-chat-meeting-2019-01-24 + +10:06 < pinchartl> welcome to the multimedia meeting ! +10:07 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:07 < pinchartl> * Jacopo +10:07 < pinchartl> Since last meeting: +10:07 < pinchartl> - adv748x dynamic routing v4 merged +10:07 < pinchartl> - soc_camera removal - small help to finalize removal +10:07 < pinchartl> Until next meeting: +10:07 < pinchartl> - Update vin-tests for the CSVB->TXA use case on E3 +10:07 < pinchartl> - Propose a V4L2 API to dynamically negotiate the number of CSI-2 data lanes +10:07 < pinchartl> This should be discussed with Sakari first. +10:07 < pinchartl> - FOSDEM and meetings +10:07 < pinchartl> Issues and blockers: None +10:07 < pinchartl> jmondi: any comment ? +10:07 < jmondi> not really +10:08 < pinchartl> thank you +10:08 < pinchartl> * Kieran +10:08 < pinchartl> Since last meeting: +10:08 < pinchartl> - ADV748x upstreaming/ refactor reset routine, and remote PAGE_WAIT +10:08 < pinchartl> - GMSL v5 review updates, rebase, and fixes for renesas-drivers +10:08 < pinchartl> Until next meeting: +10:08 < pinchartl> - Post GMSL v5 +10:08 < pinchartl> - DU D3/E3 support review +10:08 < pinchartl> - Attend PeriPeri Meetings in Brussels and FOSDEM +10:08 < pinchartl> - Continue on Upporting +10:08 < pinchartl> Issues and blockers: +10:08 < pinchartl> - Development laptop failure resulted in a re-install of Ubuntu OS :( +10:08 < pinchartl> kbingham: any comment ? +10:08 < kbingham> none here. +10:09 < pinchartl> thank you +10:09 < pinchartl> * Laurent +10:09 < pinchartl> Since last meeting: +10:09 < pinchartl> - Updated ATF & U-Boot on Salvator-XS M3-N and Draak (was quite painful) +10:09 < pinchartl> - D3/E3 RGB output (complete, pending review) +10:09 < pinchartl> - Reviewed multiplexed streams series +10:09 < pinchartl> Until next meeting: +10:09 < pinchartl> - Skiing holidays +10:09 < pinchartl> - FOSDEM & multimedia meeting +10:09 < pinchartl> Issues and blockers: +10:09 < pinchartl> - Updating ATF and U-Boot was painful +10:09 < pinchartl> Locating the right version of Minimon and the right memory locations is not +10:09 < pinchartl> straightforward. While it is nice to have firmware packages in the wiki for +10:09 < pinchartl> some of the boards, centralizing the information on how to obtain Minimon for +10:09 < pinchartl> each board and where to flash the various components would be useful. +10:09 < pinchartl> any question ? +10:09 < morimoto> Skiing holidays +10:09 < morimoto> where ? +10:10 < pinchartl> very good question :)- +10:10 < pinchartl> https://www.valdisere.com/ +10:10 < kbingham> morimoto, We still need a snowboarding holiday! :) +10:10 < pinchartl> in the French Alps +10:11 < morimoto> kbingham: Yeah, I think so +10:11 < morimoto> PeriPeriSki meeting +10:11 < kbingham> :) +10:11 < morimoto> pinchartl: looks nice. Enjoy +10:12 < pinchartl> thank you, I will try to +10:12 < pinchartl> * Morimoto-san +10:12 < pinchartl> Since last meeting: +10:12 < pinchartl> - Investigated ALSA SoC cleanup +10:12 < pinchartl> It is time to final cleanup for ALSA SoC. Initial investigations are done and +10:12 < pinchartl> discussed with the maintainer. +10:12 < pinchartl> Until next meeting: +10:12 < pinchartl> - Continue ALSA SoC work +10:12 < pinchartl> Issues and Blockers: None +10:12 < pinchartl> morimoto: any comment ? +10:12 < morimoto> no comment, thanks +10:12 < pinchartl> thank you +10:12 < pinchartl> * Niklas +10:12 < pinchartl> Since last meeting: +10:12 < pinchartl> - Investigated new LOCKDEP warnings in rcar-vin +10:12 < pinchartl> Had a brief look of new fun LOCKDEP warnings due to the v4l2-async core +10:12 < pinchartl> rework, rcar-vin async callback changes fallout. No clear conclusion so far. +10:12 < pinchartl> Until next meeting: +10:12 < pinchartl> - Try to solve the LOCKDEP warning in rcar-vin +10:12 < pinchartl> - Try to clean up VIN crop and compose code +10:12 < pinchartl> This is needed to to make it easier to merge UDS and PM support. +10:12 < pinchartl> - Attend periperi meetings and FOSDEM. +10:12 < pinchartl> Issues and blockers: +10:12 < pinchartl> - I will be in Brussels from the Jan 29th -- Feb 10th, I expect this +10:12 < pinchartl> will effect my output. +10:12 < pinchartl> neg: any comment ? +10:13 < neg> No additional comment +10:13 < pinchartl> thank you +10:13 < pinchartl> any other comment or question from anyone regarding the status updates ? +10:15 < pinchartl> Topic 2. Questions from the BSP team +10:15 < pinchartl> - DRM render node support +10:15 < pinchartl> The BSP team was informed by Igalia that R-Car doesn't have DRM render node [1][2] +10:15 < pinchartl> support. Igalia is working on Chromium support, and Chromium uses render nodes to +10:15 < pinchartl> separates the UI process and the GPU rendering for speed-up. +10:15 < pinchartl> [1] https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Render_nodes +10:15 < pinchartl> [2] https://01.org/linuxgraphics/gfx-docs/drm/drmExternals.html +10:15 < pinchartl> Tomohito Esaki from Igel has created a "quick hack" solution and provided a test +10:15 < pinchartl> application. The BSP team would like to know our opinion. +10:15 < pinchartl> morimoto: this may be a stupid question, but +10:15 < pinchartl> the DU doesn't have rendering support, as we have a separate GPU for that +10:16 < pinchartl> why would the DU driver need to create a render node when it can't do rendering ? :-) +10:16 < pinchartl> the GPU node should create the buffers, and they should be imported by the DU driver normally +10:16 < pinchartl> the render node API shouldn't be needed for that +10:16 < morimoto> "DU doesn't have rendering support" = "HW" or "SW " ? I think "SW" +10:17 < pinchartl> neither +10:17 < pinchartl> the DU can compose multiple planes +10:17 < pinchartl> but the DU hardware can't do rendering, it's not a GPU +10:18 < pinchartl> so there's no rendering support in the driver because there's no rendering support in the hardware :-) +10:18 < damm> Can IMR do rendering? +10:18 < morimoto> Ahh, OK, thanks. I was misunderstanding +10:18 < pinchartl> damm: IMR does some kind of rendering +10:19 < pinchartl> as such it would be nice to support it with a DRM driver (and that would create a render node) +10:19 < pinchartl> but it seems that the direction that was chosen was to use V4L2 instead +10:19 < pinchartl> for the GPU I certainly hope V4L2 won't be used :-) +10:19 < damm> i think the input from the m/m group leader is highly regarded +10:19 < pinchartl> but DRM may not either, and that's out of our control +10:20 < pinchartl> I commented on that in the past I believe +10:20 < pinchartl> I think that was when Cogent posted IMR patches +10:20 < pinchartl> (I'd have to check though, it was a long time ago) +10:20 < morimoto> [PATCH v5] media: platform: Renesas IMR driver +10:20 < morimoto> > https://lore.kernel.org/linux-renesas-soc/20170309200818.786255823@cogentembedded.com/ +10:20 < morimoto> ? +10:20 < damm> gotcha. thanks +10:22 * kbingham likes that lore is getting good use :) +10:22 < pinchartl> morimoto: that driver, yes. I think I commented on a previous version +10:22 < geertu> Sergei plans to work on v6 soon +10:23 < morimoto> soon. OK thanks. Nice to know +10:23 < morimoto> pinchartl: Thanks. I will feedback this info to BSP team +10:23 < kbingham> https://lore.kernel.org/linux-renesas-soc/1770632.4GFlW6r2cg@avalon/ +10:23 < morimoto> s/this/these/ +10:25 < morimoto> kbingham: thanks +10:25 < kbingham> pinchartl, https://lore.kernel.org/linux-renesas-soc/15d3888d-e15c-db23-27b4-51d5e2840618@cogentembedded.com/ Konstantin replied saying the name "image renderer is misguiding" +10:25 < pinchartl> it's a bit of a borderline case, depending on whether you think it performs texture rendering, or lens distortion correction +10:26 < geertu> The former is more generic than the latter +10:27 < geertu> Can the latter be implemented on top of the former? +10:27 < pinchartl> possibly, depending on lots of details +10:28 < pinchartl> the use case here, if I understand correctly, is to create the bird-eye-view from four fish-eye cameras +10:28 < pinchartl> so it doesn't just do lens distortion correction +10:28 < pinchartl> it actually creates distortion, just the other way around :-) +10:29 < kbingham> sounds like texture rendering onto a sphere :) +10:30 < wsa_> oh, we do this on c64, too +10:31 < pinchartl> LOL +10:31 < pinchartl> in any case, render nodes shouldn't be needed for the DU as far as I can tell +10:31 < geertu> wsa_: On Amiga, I used the copper for that (only in one dimension, or helix scrolls) +10:31 < geertu> s/or/for/ +10:31 < pinchartl> Topic 3. peripericon @FOSDEM 2019 +10:32 < pinchartl> the multimedia meeting will be on Tuesday 2019-02-05 from 09:00 to 12:00 +10:32 < wsa_> geertu: so, the copper needs render-nodes then? :) +10:33 < geertu> wsa_: No, it doesn't render, it's just a step in the display output pipeline +10:35 < pinchartl> the current agenda is +10:35 < pinchartl> - Up-port status and planning +10:35 < pinchartl> - Planning for the next quarters +10:35 < pinchartl> if you have any other topic to propose, you can submit them here, or reply to the group chat report e-mail later +10:35 < pinchartl> any other topic to discuss for today ? +10:35 < neg> Not from me +10:37 < wsa_> jmondi: please send the preparational material for IO discussion soon +10:37 < jmondi> wsa_: sure, it's on my list for next week +10:37 < jmondi> would you like it before, like tomorrow? +10:37 < wsa_> actually, yes +10:38 < wsa_> I would like at least some days to really prepare +10:38 < jmondi> I actually would then +10:38 < jmondi> s/would/will +10:38 < wsa_> and give other people also time to prepare +10:38 < pinchartl> if there's no other question or topic, I proposed adjourning this meeting. does anyone second ? +10:38 < jmondi> I see... will do +10:38 < jmondi> seconded +10:39 < damm> thanks guys, see ya later +10:39 < wsa_> jmondi: thanks +10:39 < jmondi> wsa_: long overdue +10:40 < pinchartl> meeting adjourned +10:40 < pinchartl> thank you all for attending, and have a great day diff --git a/wiki/Chat_log/20190221-core-chatlog b/wiki/Chat_log/20190221-core-chatlog new file mode 100644 index 0000000..983d15d --- /dev/null +++ b/wiki/Chat_log/20190221-core-chatlog @@ -0,0 +1,167 @@ +09:31 < geertu> Welcome to today's Core Group Chat Meeting! +09:31 < geertu> Agenda: +09:31 < geertu> 1. Status Updates +09:31 < geertu> 2. Discussion Topics +09:31 < geertu> Topic 1. Status updates +09:31 < geertu> A) What have we done since last time: +09:31 < geertu> Kaneko-san posted DRIF and TMU PFC support for E3 and M3-N. +09:31 < geertu> Marek worked on U-Boot (SDHI, multi-DTB, Gen2 conversion, PSCI), ATF +09:31 < geertu> (reset BAR and PCIe), and Linux (eMMC, thermal, TDSEL, GPIO regulator +09:31 < geertu> regressions). +09:31 < geertu> Morimoto-san forwarded a deadlock issue, and worked on the PeriJect +09:31 < geertu> viewer. +09:31 < geertu> Niklas attended the face-to-face periperi Core meeting. +09:31 < geertu> Simon worked on Z2 clock support and CPUfreq for E3 and derivatives, and +09:31 < geertu> discussed about CPUidle. +09:31 < geertu> Ulrich reviewed PFC patches and resubmitted R-Car H1 HSCIF PFC support. +09:31 < geertu> Geert worked on PFC table validation, upgraded firmware, enabled the +09:31 < geertu> GPIO expander on Ebisu, and added suspend/resume support to IPMMU. +09:33 < geertu> B) What we plan to do till next time: +09:33 < geertu> Kaneko-san plans to upport temperature calculation fixes for R-Car Gen3 +09:33 < geertu> and RZ/G2 SoCs. +09:33 < geertu> Marek plans to continue helping Goda-san with U-Boot SDHI, and improve +09:33 < geertu> ATF reset address handling. +09:33 < geertu> Morimoto-san plans to continue work on the PeriJect viewer. +09:33 < geertu> Simon plans to add ZG clock support, and follow-up R-Car E3 PMIC +09:33 < geertu> enablement and thermal zone IPA. +09:33 < geertu> Geert will investigate the reported deadlock, and plans to flush his +09:33 < geertu> pinctrl backlog. +09:34 < geertu> C) Problems we have currently: +09:34 < geertu> Morimoto-san is suffering from delayed email off his island. +09:34 < geertu> Simon needs to upgrade firmware on Ebisu. +09:34 < geertu> Geert wonders about the IPMM driver using the same context for all uTLBs +09:34 < geertu> on the same IPMMU instance, requiring e.g. SATA and PCIe to be assigned +09:34 < geertu> together to host or (the same) guest. +09:35 < geertu> --- +09:35 < geertu> Anything I missed? +09:37 < pinchartl> what is this delayed e-mails issue ? +09:37 < geertu> Perhaps also applicable to irc? +09:37 < Marex> pinchartl: what issue , care to elaborate ? +09:37 < geertu> Vger or Google delaying emails from JP? +09:38 < neg> geertu: I'm just curious if you saved the binaries you produced to update the fw on all your boards so they can be reused ? :-) +09:38 < pinchartl> Marex: I'm referring to Morimoto-san's reported problem +09:39 < geertu> neg: Of course I have ;-) +09:39 < Marex> pinchartl: oh +09:39 < geertu> Now, where to put them, to avoid a GPL class action lawsuit ;-) +09:39 < Marex> geertu: ATF is BSD +09:40 < Marex> sadly +09:40 < geertu> Topic 2. Discussion Topics +09:40 < neg> I'm sure there are no licensing issues in the osdr wiki... maybe... +09:41 < Marex> neg: or just build the binaries yourself ? +09:42 < geertu> My firmware images are not perfect, they don't work with current mainline Linux due to HS400 +09:43 < geertu> And given Marex' track record, firmware images become obsolete, soon +09:43 < Marex> geertu: same could be said about Linux +09:43 < Marex> bugs just get fixed +09:44 < geertu> Yes, that's why we don't upload Linux kernel binaries to the osdr wiki +09:45 < Marex> geertu: well, technically we could use travis to upload ATF and U-Boot binaries to some github repo, but they would only be compile-tested +09:45 < neg> Marex: I tried at some point, but digging in bitbake recipes to decode ancient hieroglyphs to learn the secret of what options is needed for each board was not my definition of a fun time +09:45 < Marex> geertu: essentially build on push and deliver somewhere +09:45 < Marex> neg: clone mbedtls, then MBEDTLS_DIR=/path/to/mbedtls/ make -j9 bl2 bl31 rcar PLAT=rcar LSI=M3N MACHINE=salvator-x SPD=opteed RCAR_BL33_EXECUTION_EL=1 LOG_LEVEL=50 DEBUG=0 RCAR_RPC_HYPERFLASH_LOCKED=0 +09:45 < Marex> neg: that's about it for 77965 S-XS +09:46 < wsa> didn't we agree in Brussels to have a wiki page for the build instructions? +09:46 < geertu> IMHO we need proper config files, like for Linux and U-Boot, instead of all these FOO=BAR options +09:46 < geertu> wsa: Yes! +09:46 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi +09:47 < pinchartl> wsa: I'd really like that +09:47 < morimoto> sorry for my delay +09:47 < Marex> geertu: well we can add it to elinux wiki +09:47 < geertu> morimoto: You're forgiven +09:47 < Marex> geertu: basically a transcript of the CI yaml https://travis-ci.org/marex/arm-trusted-firmware-1/builds/496068832/config +09:47 < geertu> Marex: Good, are you "we"? +09:47 < morimoto> geertu: thanks. I was under Renesas talk +09:48 < Marex> morimoto: おはようございます +09:48 < morimoto> Marex: good morning :) +09:48 < Marex> maybe not ... ^_^' +09:48 < Marex> good evening :) +09:48 < morimoto> Ahh, OK (^ ^); +09:49 < geertu> morimoto: How's Renesas doing? +09:49 < neg> There are already fw tarballs in the osdr wiki so I thought it could be nice if new ones where added so they where easier to consume and all not interested in fw hacking could run the same binaries and hopefully share the bug discovery process. No big deal, build instructions on a wiki are also fine with me +09:49 < Marex> geertu: "we" ? +09:50 < morimoto> geertu: I will have meeting with Magnus next week. about its topic +09:50 < geertu> Marex: "we can add it to elinux wiki" +09:50 < wsa> hi morimoto-san! +09:50 < morimoto> wsa: Hi +09:50 < pinchartl> neg: I think it would be best to ease the firmware build instead, and making it as easy as downloading the binaries from the wiki. that way we'll ensure we always run up-to-date firmwares +09:52 < geertu> pinchartl: +1 +09:53 < Marex> pinchartl: and who would put those binaries on the wiki ? +09:53 < Marex> pinchartl: the travis CI tool can put them on github automatically +09:53 < pinchartl> Marex: you got me wrong, I don't think we should have binaries in the wiki +09:53 < geertu> Marex: No one, we go for the one-click-build-from-source(TM) +09:54 < Marex> pinchartl: I need another coffee +09:54 < pinchartl> we should have a documented build procedure that makes building firmwares for a board as easy (or easier) than downloading a binary from the wiki +09:54 < Marex> pinchartl: I just added an item into taskwarrior about documenting the ATF build on elinux wiki +09:55 < pinchartl> Marex: thank you +09:55 < pinchartl> should we have per-board instructions ? +09:55 < Marex> a website like the u-boot for gen3 one would be preferred +09:55 < pinchartl> would it make sense to have a git tree with scripts to build the firmware for each board ? +09:55 < Marex> most of the stuff is the same for all boards, it's just parameters that differ +09:56 < pinchartl> not only ATF, but building minimon would be useful too +09:56 < pinchartl> I struggled with that +09:57 < neg> I agree that making the build easier would remove the need for binaries and build instructions. All I'm saying is that everytime I had some time and wanted to update fw I stopped after spending too much time trying to figure out what to build and how for each board +09:57 < geertu> minimon is not public, is it? +09:57 < Marex> pinchartl: speaking of monimon ... +09:57 < Marex> morimoto: is there source of monimon 5.x available somewhere ? :) +09:58 < pinchartl> geertu: no, but https://github.com/renesas-rcar/flash_writer is and I've had some success using it for a few boards +09:58 < pinchartl> so we could standardize our instructions on that +09:58 < pinchartl> or get minimon released +09:58 < morimoto> Marex: monimon ? minimon ? +09:58 < pinchartl> neg: last time I wanted to update the Draak firmware it took me a whole day +09:59 < Marex> morimoto: jupp, the piece of software that you start from SCIF loader and use to update the flash on Gen3 +09:59 < pinchartl> unlike other boards, there's no minimon binary for Draak in the wiki, that didn't help +09:59 < Marex> pinchartl: the draak in Magnus's vlab supports 'fitupd' from U-Boot +10:00 < Marex> pinchartl: wait until I get physical access to it, then I'll push proper ATF port upstream and then you can unlock HF and update via U-Boot +10:00 < pinchartl> Marex: mine doesn't :-) +10:00 < pinchartl> and to update u-boot I needed a flash writer +10:00 < Marex> pinchartl: the current ATF port is kinda meh, it's better than what it came with, but still downstream +10:00 < Marex> pinchartl: well, only once ... +10:00 < pinchartl> sure +10:00 < Marex> pinchartl: soon you'll be able to use U-Boot SPL on some platforms ... +10:01 < Marex> pinchartl: that's kinda work in progress +10:01 < pinchartl> but until then, flash-writer is needed +10:01 < wsa> you need a can-opener once :) +10:01 < pinchartl> in any case, we need a solution for the current problems. if we can improve the situation even more in the future, I'll be very happy +10:02 < pinchartl> Marex: will U-Boot SPL support being loaded over SCIF ? +10:02 < geertu> And you need to make ATF builds point-and-click once ;-) +10:02 < Marex> pinchartl: already does, although it's a bit hacky, which is why it needs cleanup first +10:02 < pinchartl> ok +10:04 < pinchartl> in the meantime, I think a canonical source of instructions on how to retrieve a working minimon binary for each board, or build flash-writer, would be very useful too +10:04 < pinchartl> the expect scripts shouldn't be in the wiki, they should be in a git tree +10:04 < Marex> pinchartl: feel free to take that one up, and put it on the OSDR (!) wiki +10:04 < Marex> pinchartl: this stuff is not public +10:04 < pinchartl> we can have a private git tree for that +10:05 < Marex> pinchartl: btw are we still in the core meeting ? +10:05 < pinchartl> I won't have time to take this one up I'm afraid +10:05 < pinchartl> I believe we are, this doesn't sound like multimedia to me :-) +10:05 < Marex> pinchartl: I have no interest in minimon, except for extracting knowledge burried in it's sources +10:05 < Marex> pinchartl: U-Boot has some sound support, FYI +10:07 < geertu> Let's start with the other parts +10:07 < pinchartl> Marex: oh ? what is sound used for in u-boot ? +10:07 < neg> Marex: wake me up when it supports VIN ;-P +10:07 < kbingham> beep() :D +10:08 < Marex> pinchartl: dunno, x86 people use it for something ... +10:08 < Marex> pinchartl: maybe the nice blurpy sound apple does on boot ... +10:08 < geertu> Can we (you) start with the actual firmware parts, thus not including minimon? +10:10 < Marex> morimoto: btw. updated minimon sources are super-low prio , I think you'd have to go through export paperwork and all other kind of hassle , so don't worry about it too much +10:10 < morimoto> Marex: OK, thanks :) +10:10 < Marex> geertu: didn't I say I added item to my TW to document it on elinux wiki ? +10:10 < geertu> As all the actual firmware parts are FLOSS, there's no issue here +10:11 < geertu> Marex: Good! +10:11 < geertu> Thanks! +10:11 < geertu> Any other topics to discuss for core? +10:11 < morimoto> geertu +10:11 < geertu> Periject path forward? +10:11 < Marex> morimoto: I still owe you a reply to that "updated android patchset" email, I am working toward that, I didn't forget +10:11 < morimoto> I think I sent deadlock email to you +10:11 < morimoto> is it arrived +10:11 < morimoto> ? +10:12 < geertu> morimoto: Yes, I received it. +10:13 < morimoto> Marex: OK, no problem +10:13 < morimoto> geertu: OK, nice to know +10:13 < geertu> morimoto: Thanks! +10:13 < morimoto> in these days, Renesas email seems strange +10:13 < geertu> (cfr. my B) Investigate clk/genpd deadlock reported by Jiada) +10:14 < morimoto> It is not only Renesas problem, I think +10:14 < morimoto> But, I'm not sure +10:15 < Marex> morimoto: I think pareto principle applies here, now it's only the hard bugs :) +10:15 < geertu> I think it's time to conclude the core meeting +10:17 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20190221-io-chatlog b/wiki/Chat_log/20190221-io-chatlog new file mode 100644 index 0000000..67989cb --- /dev/null +++ b/wiki/Chat_log/20190221-io-chatlog @@ -0,0 +1,99 @@ +09:04 < wsa> welcome to today's IO meeting +09:04 < wsa> status reports: +09:04 < wsa> Status updates +09:04 < wsa> ============== +09:04 < wsa> A - what have I done since last time +09:04 < wsa> ------------------------------------ +09:04 < wsa> Geert +09:04 < wsa> : tested at25 spimem conversion, replaced spi_master by spi_controller in +09:04 < wsa> various SPI drivers, and preliminary testing of SCIF5 DMA on R-Car E3 +09:04 < wsa> Marek +09:04 < wsa> : worked on various SDHI issues in U-Boot, upported eMMC reset patch for SDHI, +09:04 < wsa> got thermal patch which adds hwmon interfaces merged +09:04 < wsa> Shimoda-san +09:04 < wsa> : +09:04 < wsa> Simon +09:04 < wsa> : posted fix for AVB phy-mode on Draak, needs testing +09:04 < wsa> Wolfram +09:04 < wsa> : implemented a fault injector to simulate 'arbitration lost' without having a +09:04 < wsa> multi-master setup, implemented a fault injector which panics during a +09:04 < wsa> transfer so rebooting with an inconsistent bus state can be tested, converted +09:04 < wsa> Gen2/3 IIC to use a better formula to calc the freqs, upported SDHI patch for +09:04 < wsa> HW adjustment depending on speed mode, reviewed a few I2C and SDHI patches, +09:04 < wsa> converted and pushed first periject data, sent my first glibc patch +09:04 < wsa> B - what I want to do until next time +09:04 < wsa> ------------------------------------- +09:04 < wsa> Geert +09:04 < wsa> : wants to do more testing of SCIF5 DMA on R-Car E3 +09:04 < wsa> Kaneko-san +09:04 < wsa> : wants to pport temperature calculation fixes for R-Car Gen3 and RZ/G2 SoCs +09:04 < wsa> Niklas +09:04 < wsa> : wants to nbox APE6EVM and make sure it boots and hopefully have a first look +09:04 < wsa> at the MMC PM imbalance issue +09:04 < wsa> Shimoda-san +09:04 < wsa> : wants to +09:04 < wsa> Simon +09:04 < wsa> : wants to asses RAVB patches in BSP v3.9.2, measure MMC performance across +09:04 < wsa> various Gen3 boards +09:04 < wsa> Wolfram +09:04 < wsa> : wants to upport I2C patches, continue working on atomic I2C transfers, assist +09:04 < wsa> with whatever topics JapaPERI brings to the table +09:04 < wsa> C - problems I currently have +09:04 < wsa> ----------------------------- +09:04 < wsa> None reported +09:05 < wsa> I am still waiting for Shimoda-san's report, I guess it will come along... +09:05 < wsa> I dropped all "meetings in BE" items because for me the reports should have been since the meetings in BE :) +09:06 < wsa> geertu: any plans for the MSIOF patches in bsp392? +09:06 < wsa> Marex: wasn't there also PCIe link handling in ATF as B)? +09:07 < Marex> PCI link handling in ATF is in submitted PR +09:07 < wsa> neg: can we drop the "hopefully" from the SDHI clk imbalance thing? +09:07 < Marex> since a few hours ago +09:07 < wsa> Marex: cool! +09:07 < Marex> (before I went to bed) +09:08 < wsa> uli___: dunno if you maybe did it already, but could you test the D3 phy patch that Simon mentioned in his report? +09:08 < neg> wsa: Depends on how confident you are that the APE6EVM works :-) Magnus warned me its status is unkown. But yes please remover it form the report +09:08 < uli___> wsa: can do +09:08 < wsa> uli___: thx +09:08 < geertu> wsa: Is there anything non-controversial w.r.t. MSIOF left? +09:09 < wsa> neg: ah, "hopefully" means "if the board works" and not "if I have time"? +09:09 < wsa> geertu: if it is controversial, please add comments to the ticket file, so I know +09:09 < neg> wsa: Yes +09:10 < wsa> neg: ah, good, I misunderstood this. Let me know how the board is doing :) +09:10 < neg> Will do, plan is to try it on Monday +09:11 < wsa> sounds good +09:12 < wsa> what is so special about SCIF5 DMA on Ebisu, BTW? +09:13 < geertu> The DMA documentation about it was wrong, so DT was wrong, too +09:14 < wsa> I see +09:14 < wsa> any questions from your side? +09:15 < geertu> I sort of verified the new one is OK, but am now looking for CP45 on the board, to connect a probe ;-) +09:15 < wsa> oh, we are on that level :) +09:16 < wsa> neg: do you still have that SDIO WIFI card or did you give it to JapaPERI? +09:16 < neg> I still have it +09:17 < neg> I try it from time to time tracking progress in the thread 'Test of EVK-EMMY-W161-A on Koelsch with SDR50 and SDR104' ;-) +09:18 < wsa> can you just check if it works with SDR104 for you? When testing Sergei's patch, I had to reduce it to SDR50 to make it probe :( +09:18 < Marex> geertu: I wonder what else is wrong on E3 Ebisu ... maybe the SDHI performance ? +09:18 < wsa> My test was on M3N +09:19 < geertu> Marex: Have you looked into the meaning of the values written to the QoS registers? +09:20 < neg> wsa: to be clear SDIO + M3N + '[PATCH v3] mmc: tmio_mmc_core: don't claim spurious interrupts' right? +09:21 < Marex> geertu: is there any documentation besides "QoS Level x Threshold y Setting" ? +09:21 < Marex> geertu: besides, we do not know whether it is QoS problem at all +09:21 < wsa> neg: yes. but other Gen3 boards are interesting, too +09:22 < wsa> neg: and the probing should really be independent of Sergei's patch +09:22 < neg> wsa: OK will do +09:22 < wsa> thx! +09:23 < geertu> Marex: From a quick glance, I already read things like "1.95 usec not supported on E3", so it uses 7.80 intead +09:24 < Marex> geertu: both work, changing that doesn't help +09:24 < Marex> geertu: and I think it was using 3.9 , not 7.8 +09:25 < Marex> geertu: IIRC you can select either or with a MD switch +09:25 < geertu> ok +09:25 < neg> wsa: for reference did you test on top of mmc/fixes or mmc/next ? +09:25 < Marex> and if not, rebuild ATF for either or ... nonetheless, doesn't help +09:26 < Marex> either the SDHI is somehow underclock, or the bus somewhere between SDHI and DRAM is too narrow , or there's DRAM bottleneck +09:27 < wsa> neg: hmmm, either mmc/next or v5.0-rcX. Need to look this up, code is on another machine... +09:27 < Marex> DRAM bottleneck is unlikely, I did memtester and calculations, it gives more then plenty of bandwidth ... way more than 400 MB/s +09:27 < Marex> s/memtester/lmbench/ +09:27 < neg> wsa: OK no worries I figure it out +09:28 < wsa> shall we move to core meeting then? +09:29 < wsa> looks like it +09:29 < wsa> geertu: the stage is yours +09:29 < wsa> thanks for this meeting! diff --git a/wiki/Chat_log/20190221-mm-chatlog b/wiki/Chat_log/20190221-mm-chatlog new file mode 100644 index 0000000..1c5af93 --- /dev/null +++ b/wiki/Chat_log/20190221-mm-chatlog @@ -0,0 +1,202 @@ +Multimedia-chat-meeting-2019-02-21 + +10:17 < pinchartl> welcome to the multimedia meeting +10:18 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:18 < pinchartl> * Jacopo +10:18 < pinchartl> Since last meeting: +10:18 < pinchartl> - Take over the V4L2 multiplexed streams patch series +10:18 < pinchartl> Started addressing review comments and adding documentation. Plan to +10:18 < pinchartl> submit next week and implement data lane negotiation on top of that. +10:18 < pinchartl> - Investigated adv748x CSI-2 data lane configuration on AFE->TXA +10:18 < pinchartl> - Reviewed VIN and miscellaneous V4L2 patches +10:18 < pinchartl> - Attended FOSDEM and periBe meetings +10:18 < pinchartl> Until next meeting: +10:18 < pinchartl> - Finalize the next version of the V4L2 multiplexed streams patch series +10:18 < pinchartl> Issues and blockers: None +10:18 < pinchartl> jmondi: any comment ? +10:19 < kbingham> jmondi, If you publish an updated/rebased mux branch - please let me know so that I can rebase my gmsl/for-renesas-drivers on top of it. +10:19 < pinchartl> we seem to be missing Jacopo +10:19 < pinchartl> * Kieran +10:19 < pinchartl> Since last meeting: +10:19 < pinchartl> - PeriPeri meetings in Brussels +10:19 < pinchartl> - FOSDEM +10:19 < pinchartl> - Hans' VSP1 smatch testing +10:19 < pinchartl> - Various reviews +10:19 < pinchartl> - VSP partition algorithm phase investigations +10:19 < pinchartl> Until next meeting: +10:19 < pinchartl> - Focus on VSP partition algorithm phase until complete +10:19 < pinchartl> - On holidays until the end of the week +10:19 < pinchartl> Issues and blockers: +10:19 < pinchartl> - VSP partition algorithm phase is difficult to understand +10:19 < pinchartl> kbingham: any comment ? +10:20 < kbingham> No. +10:20 < pinchartl> thank you +10:20 < pinchartl> * Laurent +10:20 < pinchartl> Since last meeting: +10:20 < pinchartl> - FOSDEM & multimedia meeting +10:20 < pinchartl> - DU writeback support for Gen3 +10:20 < pinchartl> A working patch series has been posted, but the upstream DRM community +10:20 < pinchartl> requested the DU driver to use the DRM/KMS writeback connector API +10:20 < pinchartl> instead of V4L2 for writeback capture. A new version is under +10:20 < pinchartl> development. +10:20 < pinchartl> - Upstreamed VSP test suite and related yavta patches +10:20 < pinchartl> - Upstreamed D3/R3 RGB output +10:20 < pinchartl> Until next meeting: +10:20 < pinchartl> - DU writeback support +10:20 < pinchartl> - Finalize additional tasks for 2019 Q1 +10:20 < pinchartl> Issues and blockers: None +10:20 < pinchartl> any question ? +10:20 < morimoto> Thank you for Brussels souvenir +10:21 < morimoto> for all M/M member +10:21 < pinchartl> you're welcome :-) +10:21 < jmondi> I'm here sorry +10:21 < jmondi> got distracted :) no comments from here +10:21 < pinchartl> it was a bit more Finnish than Belgian, but we signed it all in Brussels :-) +10:21 < pinchartl> jmondi: thank you +10:21 < pinchartl> * Morimoto-san +10:21 < pinchartl> Since last meeting: +10:21 < pinchartl> - ALSA SoC v5.0 bugfix for issues reported by users +10:21 < pinchartl> Until next meeting: +10:21 < pinchartl> - ALSA SoC needs to be updated for modern device +10:21 < pinchartl> Issues and Blockers: +10:21 < pinchartl> - ALSA SoC work depends on a developer from Intel +10:21 < pinchartl> morimoto: any comment ? +10:21 < morimoto> No, thanks +10:22 < pinchartl> thank you +10:22 < pinchartl> who is that Intel person ? and is there something we can help to make him help you ? +10:23 < morimoto> He is Pierre-Louis Bossart +10:23 < morimoto> He is working for other Intel work. +10:23 < morimoto> And mine is depend to it +10:24 < pinchartl> is his work progressing ? that is, is it "just" a matter of waiting for him to complete his work, or is it stalled for some reason ? +10:24 < morimoto> I think he is working very hard. +10:25 < morimoto> And I need some prepare work for my task +10:25 < morimoto> so, both are under hard work +10:25 < morimoto> :) +10:25 < pinchartl> ok :-) +10:26 < pinchartl> * Niklas +10:26 < pinchartl> Since last meeting: +10:26 < pinchartl> - [PATCH] rcar-vin: Fix lockdep warning at stream on +10:26 < pinchartl> - [PATCH] rcar-csi2: Use standby mode instead of resetting +10:26 < pinchartl> - [PATCH] rcar-csi2: Allow configuring of video standard +10:26 < pinchartl> - [PATCH 0/2] arm64: dts: r8a77990-ebisu: small fixes for VIN +10:26 < pinchartl> - [PATCH 0/3] rcar-csi2: Update start procedures to latest revision of datasheet +10:26 < pinchartl> - [PATCH] rcar-csi2: restart CSI-2 link if error is detected +10:26 < pinchartl> - Attended face-to-face periperi Multimedia meeting +10:26 < pinchartl> Until next meeting: +10:26 < pinchartl> - Try to clean up the VIN crop and compose code +10:26 < pinchartl> This is needed to ease merging of UDS and PM support. +10:26 < pinchartl> Issues and blockers: +10:26 < pinchartl> - Unsure how to upstream updates for periupport bsp392 +10:26 < pinchartl> Are we using periject or periupport to track upporting now? +10:26 < pinchartl> neg: any comment ? +10:27 < neg> No comment, thanks +10:27 < pinchartl> do you want to discuss how to handle upporting after the status update ? +10:28 < neg> Yes please +10:28 < pinchartl> ok +10:28 < pinchartl> thanks +10:28 < pinchartl> * Ulrich +10:28 < pinchartl> Since last meeting: +10:28 < pinchartl> - Reviewed "rcar-csi2: Update start procedures to latest revision of +10:28 < pinchartl> datasheet" series +10:28 < pinchartl> Until next meeting: None +10:28 < pinchartl> Issues and Blockers: None +10:28 < pinchartl> uli___: any comment ? +10:28 < uli___> nope +10:29 < pinchartl> thank you +10:29 < pinchartl> Topic 2. Discussions +10:29 < pinchartl> - BSP Upporting +10:29 < pinchartl> neg: please go ahead :-) +10:30 < neg> Thanks, I'm only unsure if we track upport progress in periupport or periject +10:31 < neg> In the past I sent patches to group leaders to periupport but after preparing such a patch recently I became unsure if we are 'live' with periject for this yet or not +10:31 < pinchartl> does anyone have an answer to that question ? wsa maybe ? +10:31 < kbingham> neg, Do we have multimedia tasks in periject yet? +10:34 < pinchartl> silence... +10:34 < Marex> morimoto: I sent you an IRC PM, did you receive it ? +10:34 < pinchartl> have we lost neg ? +10:34 < pinchartl> wsa: ping ? +10:35 < morimoto> Marex: sorry what is "PM" ? +10:35 < kbingham> Aha - we have a viewer starting :) (thanks morimoto-san) +10:35 < neg> kbingham: no, but there are upport tasks for IO, d5c115890a419f77 ("projects: add upport tasks from bsp392 for IO") +10:35 < Marex> morimoto: private message +10:35 < morimoto> Marex: I think no +10:35 < Marex> morimoto: OK, I can send you an email later, it's not important +10:35 < morimoto> kbingham: I'm creating HTML version now :) +10:36 < pinchartl> neg: Wolfram seems gone already, I fear we'll have to discuss it on the list +10:36 < kbingham> From what I can see - wsa has created IO tasks only. +10:36 < morimoto> Marex: OK +10:36 < wsa> what was the question? +10:36 < pinchartl> wsa: 10:31 < neg> In the past I sent patches to group leaders to periupport but after preparing such a patch recently I became unsure if we are 'live' with periject for this yet or not +10:37 < kbingham> morimoto, "./ject --oneline" Nice :) +10:37 < wsa> yes, sure I have created IO tasks only. Conversions needs manual updates and I can't do that for other groups +10:37 < wsa> What did you expect here? +10:38 < pinchartl> wsa: I certainly didn't expect you to handle the multimedia tasks :-) +10:38 < wsa> So, for IO, periject has gone live, but for me, we are still in beta-testing phase +10:38 < pinchartl> the question is whether we are live with periject +10:38 < wsa> pinchartl: thanks :) +10:38 < pinchartl> ok +10:38 * kbingham has a Hugo returning ... so I must leave. +10:38 < wsa> to answer neg's question: during beta-test, both is fine for me +10:39 < pinchartl> so you would say it can be a per-group decision at this time ? +10:39 < pinchartl> ok +10:39 < pinchartl> neg: what's your preference ? do you want to beta-test periject for multimedia ? :-) +10:39 < wsa> I will ensure both are in sync, and we will find out what is best +10:39 < neg> I think the confusion answers my question for MM, I will send out the patch to periupport :-) +10:39 < wsa> pinchartl: I wished everyone would go live with periject. Dunno why this has not happened yet. +10:40 < kbingham> wsa, lack of understanding I expect. +10:40 < kbingham> I think we should move to it asap. +10:41 < wsa> Okay, in case you just need someone to tell you to do it... +10:41 < wsa> Do it! +10:41 < wsa> :D +10:41 < pinchartl> neg: I agree with Wolfram, I think it would be nice if we all moved to it +10:41 < kbingham> wsa, Excellent ^ you just did :) +10:41 < pinchartl> so I'd favour using periject instead of sending patches for periupport +10:41 * kbingham really has to leave now +10:43 < Marex> morimoto: I was just curious whether it's a great idea to drop by at the end of march to see the sakura blooms and whether they're beautiful in Tokyo :) +10:44 < pinchartl> neg: ? +10:44 < neg> I'm OK with periject but keeping the two projects in sync if manual steps is involved scares me +10:45 < morimoto> March: According to web, 2019 sakura in Tokyo is from 23th March +10:45 < Marex> morimoto: jupp +10:45 < pinchartl> neg: let's go for periject only then +10:45 < neg> Sorry got lost in the periject code, it seems periject does not yet have the same feature set as periject when it comes to track upport data. Looking at wsa commits 'normal tasks are created to group sets of upport commits +10:45 < morimoto> Thank you periupport, welcome periject +10:48 < neg> So to switch to periject all MM related patches from bsp392 needs to be extracted and grouped for periject, which is fine but a task someone needs to do +10:48 < morimoto> Marex: This is Japanese page, but for 2019 sakura +10:48 < morimoto> https://jp.zekkeijapan.com/article/index/493/ +10:48 < Marex> morimoto: I need to practice anyway ! +10:48 < pinchartl> neg: Wolfram developed a script to classify commits. we can then manually edit the tasks +10:48 < Marex> morimoto: I am slowly starting to be able to make sense from emails between you and Hosoya-san :) +10:48 < pinchartl> neg: I can help you with that +10:49 < morimoto> Marex: Thanks. But no stress +10:49 < pinchartl> neg: would you be ok working on it with me ? +10:50 < Marex> morimoto: thank you for translating them for me :) +10:50 < neg> pinchartl: absolutely +10:50 < pinchartl> thank you +10:50 < pinchartl> let's do it then +10:50 < pinchartl> any other discussion topic ? +10:51 < neg> not from me +10:51 < wsa> pinchartl: note that the unique-key topic is still open for periject +10:51 < Marex> morimoto: btw there's an updated forecast from Feb. 7th, https://www.jnto.go.jp/sakura/eng/index.php , I think there should be new one on 21st too +10:51 < jmondi> not from here +10:51 < morimoto> Not from me. Just information, I will enjoy snowboard from tomorrow ;P +10:51 < pinchartl> wsa: I know. I'll see if I can have a look at that +10:52 < wsa> cool +10:52 < pinchartl> morimoto: nice ! :-) +10:52 < jmondi> morimoto: now we're jealous +10:52 < wsa> morimoto: have fun! +10:52 < pinchartl> Topic 3. Additional Tasks for 2019 Q1 +10:52 < pinchartl> The following additional tasks will be submitted to Renesas today: +10:52 < pinchartl> - DU External Pixel Clock Routing Support +10:52 * jmondi learns there is a calendar for Japanese cherry blossom season +10:52 < pinchartl> - DU LVDS Dual Link Support Prototype +10:52 < morimoto> pinchartl: jmondi: wsa: thanks ! +10:52 < pinchartl> if anyone wants another AT for Q1, please chime in today +10:53 < wsa> jmondi: it is part of the weather forecast in Japanese TV :) +10:53 < pinchartl> that's it for today +10:53 < pinchartl> next meeting two weeks from now on March the 7th ? +10:53 < wsa> ack +10:53 < neg> works for me +10:54 < pinchartl> I propose adjourning this meeting. does anyone second ? +10:54 < neg> second +10:54 < morimoto> 2nd +10:54 < jmondi> yup +10:55 < pinchartl> meeting adjourned. thank you all for attending, and have a nice day diff --git a/wiki/Chat_log/20190307-core-chatlog b/wiki/Chat_log/20190307-core-chatlog new file mode 100644 index 0000000..502b05c --- /dev/null +++ b/wiki/Chat_log/20190307-core-chatlog @@ -0,0 +1,119 @@ +10:04 < geertu> Welcome to today's Core Group chat! +10:04 < geertu> Agenda: +10:04 < geertu> 1. Status Updates +10:04 < geertu> 2. Discussion Topics +10:04 < geertu> Topic 1. Status updates +10:04 < geertu> A) What have we done since last time: +10:04 < geertu> Marek worked on ATF (build instructions, parameter passing, upporting, +10:04 < geertu> QoS impact on SDHI, assumed maintainership), U-Boot (i2c, pfc, M3N ULCB, +10:04 < geertu> parameter passing, defconfigs), and Linux (TDSEL save/restore, +10:04 < geertu> Alt/Blanche PMIC, Draak CAN, PCIe 32-bit limitation). +10:04 < geertu> Morimoto-san enjoyed snowboarding and added HTML support to the periject +10:04 < geertu> viewer. +10:04 < geertu> Shimoda-san looked into an rcar-dmac glitch fix from Bosch. +10:04 < geertu> Simon posted support for the ZG clock on E3/D3 and RZ/G2E. +10:04 < geertu> Ulrich tested patches and visited Renesas people at Embedded World. +10:04 < geertu> Geert investigated the clock/genpd deadlock with Jiada, and did a rough +10:04 < geertu> periupport->periject conversion for core. +10:04 -!- Marex [~Marex@195.140.253.167] has quit [Client Quit] +10:05 < geertu> B) What we plan to do till next time: +10:05 < geertu> Marek plans to revisit PWRC mailboxes in ATF, and SDHI calibration in +10:05 < geertu> U-Boot. +10:05 < geertu> Morimoto-san plans to fix the clock/sound issue, and plan an +10:05 < geertu> Hanami-party. +10:05 < geertu> Simon plans to continue working on the ZG clock, and follow up r8a77990 +10:05 < geertu> PMIC enablement. +10:05 < geertu> Geert plans to spend more time on the clock/genpd deadlock, flush his +10:05 < geertu> pinctrl backlog, and follow-up on IPMMU suspend/resume. +10:06 < geertu> C) Problems we have currently: +10:06 < geertu> Geert doesn't like clock/genpd deadlocks. +10:06 < geertu> Morimoto-san misses the snowboard season, already. +10:06 < geertu> Simon needs to upgrade firmware on Ebisu. +10:07 < geertu> ---EOT--- +10:07 < geertu> Anything I missed? +10:07 < pinchartl> geertu: who likes clock/genpd deadlocks ? :-) +10:07 < geertu> pinchartl: Dunno +10:08 < geertu> morimoto: I'm afraid we cannot fix your problem right here, unfortunatly +10:09 < geertu> But snowboarding season may open soon on the southern hemisphere +10:10 < geertu> Topic 2. Discussion Topics +10:10 < geertu> Do we have anything special to discuss? +10:10 < wsa> I have an upport request :) +10:10 < geertu> Any special requests or issue from the Renesas side? +10:11 < wsa> There is this IO related PFC patch in the BSP "pinctrl: sh-pfc: r8a77965: Add I2C{0,3,5} pins, groups and functions" +10:11 < wsa> It would be nice to have that upstream +10:11 < wsa> I recall uli__ did it for the other Gen3 SoCs already +10:11 < uli__> correct +10:13 < geertu> Looks like I found a first use for the "assignee" field in periject? +10:13 < wsa> :D +10:13 < geertu> uli__: Do you have time to take care of that? +10:13 < uli__> sure +10:13 < geertu> uli__: thx! +10:14 < wsa> out of interest: what came out of the cpuidle patches? on the way upstream? +10:15 < shimoda> geertu: about sd clock on cpg driver, I got v2 patch from kihara-san, so I'll send it later +10:16 < geertu> shimoda: ok, thx! +10:16 < shimoda> geertu: kihara-san would like you to review it to apply the bsp +10:16 < wsa> shimoda: BTW I will have a look at the HS400 & MMC core issue you mentioned +10:17 < shimoda> wsa: thanks! +10:17 < geertu> wsa: cpuidle is postponed until we have access to hardware (newer ES revisions) to test. +10:17 < geertu> Cfr. PERIPERI-BRU meeting +10:18 < wsa> ah, right +10:18 < wsa> it is idling ;) +10:18 < marex-cloud> wsa: HS400? There's more? :( +10:19 < wsa> marex-cloud: yes, check shimoda-san's status update. It is a Linux-internal thing, though +10:19 < marex-cloud> Ok +10:21 -!- Marex [~Marex@195.140.253.167] has joined #periperi +10:22 < geertu> Anything left to mention/discuss? +10:23 < pinchartl> date for the next meeting ? +10:23 < pinchartl> two weeks from now is the 21st +10:23 < pinchartl> and it's a public holiday in Japan +10:23 < geertu> pinchartl: snowboard day? +10:24 < pinchartl> morimoto: shimoda: damm: I assume the 21st isn't a good date for you ? +10:25 < shimoda> pinchartl: true, I prefer other day, but I'll take day off 22nd too +10:25 < geertu> Vernal Equinox Day +10:25 < morimoto> Yeah, 21st is holiday in Japan +10:26 < wsa> 28th then? +10:26 < geertu> morimoto: border between snowboard and non-snowboard season? +10:26 < geertu> 28th is fine for me +10:27 < pinchartl> I'll be in a plane on the 28th, I'll see if there's wifi on board +10:27 * Marex will connect from Japan :-) +10:27 < morimoto> Unfortunately, it is already non-snowboard season (; ;) +10:27 < Marex> pinchartl: dinner plans for 27th ? +10:27 < pinchartl> Marex: I plan to have dinner on the 27th :-) +10:27 < Marex> morimoto: maybe you can add wheels to the snowboard, like rollerskating ? :) +10:28 < morimoto> Hehe :) +10:30 < morimoto> It is alreay exist call as "mountain board" +10:31 < Marex> morimoto: clearly you already researched that option :) +10:31 < morimoto> It seems I feel very pain if I falling... +10:32 < geertu> morimoto: Do ... not ... fall? +10:32 < Marex> morimoto: one would assume the same thing applies for snowboarding +10:32 < geertu> Alternatively, we can meet on march 20? +10:32 < morimoto> n? not falling, I don't know hot to say in English +10:33 < Marex> play it safe ? +10:33 < morimoto> I'm OK for 20th +10:33 < geertu> In preparation of the equinox? +10:33 < wsa> 20th would be a tad better for me, even +10:34 < shimoda> ah, at 20th, I and morimoto-san should end the work at 17:30... +10:34 < morimoto> shimoda: not "force" day, I guess +10:35 < shimoda> 20th is third wed, so I think it's force go to home day :) +10:35 < morimoto> Oops, indeed +10:36 < pinchartl> I won't be available on the 20th, but don't let that block you +10:39 < pinchartl> conclusion ? +10:39 -!- damm [~damm@KD106161169141.au-net.ne.jp] has quit [Ping timeout: 246 seconds] +10:39 < morimoto> How about skip then, it looks very tight schedule in the week ? +10:39 < morimoto> 4th April ? +10:40 < geertu> Fine for me +10:40 < neg> Works for me +10:40 < Marex> neg: 33c3 +10:40 < morimoto> Marex: what does it mean ? 33c3 +10:41 < shimoda> fine for me +10:41 < Marex> morimoto: https://media.ccc.de/c/33c3 +10:41 < Marex> morimoto: whitehat hacker conference on various topics, the theme of 33c3 was "works for me" +10:41 < geertu> let-me-marex-that-for-you ;-) +10:42 < wsa> 4.4. , ack +10:42 < neg> Marex: I liked 29c3 better "Not my department" I have the poster on my wall in the office +10:42 < Marex> morimoto: e.g. in this years' edition, we were kinda discussing random stuff and learnt that for some reason, Sony PS Vita CPU is made by Toshiba and it's a derivative of their ARM SoC :) +10:42 < Marex> morimoto: one learns a lot of interesting inobvious stuff there +10:43 < Marex> neg: nice +10:43 < geertu> So.... Thanks for joining, and have a nic continued day! +10:43 < wsa> but i would like to have status updates on 21/03, still +10:43 < geertu> wsa: ok diff --git a/wiki/Chat_log/20190307-io-chatlog b/wiki/Chat_log/20190307-io-chatlog new file mode 100644 index 0000000..aee5994 --- /dev/null +++ b/wiki/Chat_log/20190307-io-chatlog @@ -0,0 +1,204 @@ +09:03 < wsa> welcome to today's IO meeting +09:03 < wsa> here are the status updates: +09:03 < wsa> A - what have I done since last time +09:03 < wsa> ------------------------------------ +09:03 < wsa> Geert +09:03 < wsa> : corrected and tested SCIF5 DMA on R-Car E3, and upported MSIOF patches for +09:03 < wsa> reset handling and bits-per-word restrictions +09:03 < wsa> Kaneko-san +09:03 < wsa> : posted patch to update thermal calculation for E3 +09:03 < wsa> Marek +09:03 < wsa> : sent patches for AHCI and NVME PCI to respect the 32bit limitation of the +09:03 < wsa> R-Car PCIe controller +09:03 < wsa> Shimoda-san +09:03 < wsa> : fixed a memory leak in the R-Car Gen2 PHY driver, discussed with BSP team +09:03 < wsa> a HS400 problem and found a patch for a similar issue +09:03 < wsa> Ulrich +09:03 < wsa> : +09:03 < wsa> Wolfram +09:03 < wsa> : sent out another RFC implementing atomic I2C transfers, sent out a series +09:03 < wsa> improving concurrency and one improving DMA robustness for i2c-rcar, fixed +09:03 < wsa> SDHI issue regarding Block Count register, helped fixing an I2C core issue +09:03 < wsa> about reusing irqs, reviewed I2C, thermal, MSIOF, PMIC related patches, did +09:03 < wsa> minor periject work +09:03 < wsa> B - what I want to do until next time +09:03 < wsa> ------------------------------------- +09:03 < wsa> Geert +09:03 < wsa> : wants to convert MSIOF to use GPIO descriptors for CS and to make use of +09:03 < wsa> readl_poll_timeout() +09:03 < wsa> Kaneko-san +09:03 < wsa> : wants to post patch to update thermal calculation for H3, M3-W, M3-N +09:03 < wsa> Niklas +09:03 < wsa> : wants to investigate MMC PM imbalance issue on APE6EVM +09:03 < wsa> Shimoda-san +09:03 < wsa> : wants to wants to work on PWM suspend/resume once his atomic API patches +09:03 < wsa> are merged, and to continue to improve phy-rcar-gen3-usb2 driver to enable +09:03 < wsa> each source independency instead of all sources +09:03 < wsa> Simon +09:03 < wsa> : wants to asses RAVB patches in BSP v3.9.2, measure MMC performance across +09:03 < wsa> various Gen3 boards +09:03 < wsa> Wolfram +09:03 < wsa> : wants to keep up with the atomic I2C transfer topic, handle 'arbitration lost' +09:03 < wsa> and 'NAK' better with the IIC core, investigate SDR104 regression with SDIO +09:03 < wsa> C - problems I currently have +09:03 < wsa> ----------------------------- +09:03 < wsa> Geert +09:03 < wsa> : detected a QSPI FLASH regression on Koelsch +09:03 < wsa> Wolfram +09:03 < wsa> : needs attention of someone with expertise to comment on the use of 'in_atomic()' +09:03 < wsa> in his series about atomic I2C transfers +09:04 < wsa> uli__: so, is the D3 phy-mode patch one of those you tested? +09:05 < wsa> ah, now i see the mail +09:05 < wsa> so, it is, thanks +09:05 < uli__> yup +09:07 < wsa> horms: what about the RAVB upporting? do you have time for them or are you super busy and wouldn't mind someone else working on them? +09:08 < wsa> shimoda: a similar question to you. There is a PWM patch to be upported fixing an issue found by lockdep. Do you have time for that or would you actually be happy if this was delegated to someone interested? +09:08 < jmondi> 'morning, sorry, I'm a bit late +09:09 < horms> wsa: I am a bit busy. My main problem is that I don't know how to test them and they seem likely to have negative performance impatct. +09:09 < shimoda> wsa: please wait a little, I'd like to check the BSP patch +09:10 < wsa> shimoda: https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=70b4a22f220fef943c45a1122fa02d6faa42d2fe +09:11 < wsa> horms: one of them references an errata, wouldn't that do? +09:12 < wsa> and maybe we could request more information about the other one then? +09:13 < wsa> neg: did the cable arrive? +09:13 < neg> wsa: Not since last night when I wrote the status update ;-P +09:13 < wsa> ehrm, yes :) +09:14 < neg> wsa: If it's not here tomorrow I will buy one over the counter to get this thing rolling +09:14 < wsa> neg: yes, please +09:14 < shimoda> wsa: OK. I'll try to upport it. of course, reproduce this issue on mainline first :) +09:14 < horms> wsa: the errata patch has a fix which involves not supporting 1GB/s on E3. +09:14 < wsa> shimoda: thanks! +09:14 < horms> And yet that works fine in my environment. +09:15 < horms> But I do take your point. +09:15 < horms> Perhaps the way forwards is to a) test (probably they work) b) post the patches +09:15 < horms> I just feel that these patches apply a sledgehammer to crack an egg +09:15 < horms> But I don't have an alternate solution +09:17 < wsa> horms: right, the patch description say "It communication at 1Gbps may fail" ... "may" +09:17 < horms> Yes, this is my red flag +09:17 < horms> In my limited testing I have never seen it fail +09:17 < wsa> horms: probably this would need communication with the HW guys then? +09:17 < horms> Yes, maybe that is a good idea +09:17 < wsa> if they can think of a better solution? +09:18 < horms> The other one I should test +09:18 < horms> and see if there is a performance impact +09:18 < wsa> Marex: so, was there anything more needed for D3 CAN? +09:18 < horms> if not then I'm not so worried about it +09:18 < wsa> horms: please, do +09:18 < horms> but even in that case I feel that upstream will require some sort of test case +09:19 < horms> How about this +09:19 < horms> 1) I will test the patches +09:19 < horms> 2) I will send some feedback to the periperi ML +09:19 < horms> 3) Shimoda-san or Morimoto-san can pass some questions on to Renesas +09:20 < wsa> sounds good to me +09:20 < wsa> thanks! +09:21 < horms> Likewise, thanks! +09:21 < Marex> wsa: DT enablement ? +09:21 < wsa> Marex: driver or board? +09:21 < morimoto> horms: for 3) anytime is OK for me. But I'm not familiar with it, please add "background, question" etc ;) +09:21 < Marex> wsa: board +09:22 < horms> morimoto: thanks. I will include background information +09:22 < morimoto> horms: thanks +09:22 < Marex> wsa: Draak has both CANs on pins, it just needs to be enabled and tested +09:23 < wsa> I recall Uli did some CAN enablement patches, I was wondering... +09:24 < Marex> wsa: I didn't see any for Draak +09:24 < geertu> wsa: : They were just .dtsi additions based on the datasheet, AFAIK +09:24 < wsa> will check +09:24 < Marex> yep, only the DTSi and documentation +09:24 < Marex> s/documentation/dt bindings/ +09:26 < wsa> right +09:26 < wsa> the board was missed :( +09:26 < wsa> OK, thanks for doing it, Marek +09:27 < Marex> wsa: I need to test it when I have access to Draak tho +09:28 < Marex> wsa: damm -san said he might install a cable between those two CANs on Draak at least, so I can play around with it remotely +09:28 < wsa> OK, nice +09:28 < wsa> any questions from your side? +09:29 < Marex> wsa: PCI 32bit limitation , will we have to patch each and every driver to not rewrite the DMA masks ? +09:29 < Marex> wsa: I think so +09:30 < wsa> I am not deep enough into that topic, it doesn't sound like it would scale well, though +09:31 < Marex> wsa: eventually the drivers shouldn't change the DMA masks at all +09:31 < Marex> unless there's a good reason, in which case they need to respect the bus DMA mask too +09:31 < wsa> that sounds way better to me +09:32 < Marex> wsa: it still means patching a whole lot of drivers +09:32 < geertu> Yah, DMA masks are not a property of the driver, but of the device and bus +09:32 < Marex> I sent out an RFC for AHCI and NVME drivers, which I tested on Gen3 and Gen2 with a PCIe card and those start working with the change +09:33 < Marex> so did xhci controller, but I didn't send a patch yet, I want some feedback on those two RFCs first +09:33 < Marex> on Gen2 , I still have trouble with NVMe, I am not sure why though ... and it seems unrelated to this problem +09:33 < geertu> Marex: So NVMe is working now? +09:33 < Marex> geertu: on Gen3 +09:34 < Marex> geertu: on Gen2 I get timeouts , but see above +09:34 < Marex> geertu: I suspect this has to do with the NVMe being mostly tested on 64bit systems +09:35 < geertu> Marex: Probably. It's not a good performance improvement investion on systems limited to 32-bit DMA anyway ;-) +09:36 < wsa> so, shall we move to discussing Magnus' request? +09:36 < wsa> and my own for that matter? :) +09:36 * geertu assumes his NVMe does DMA to all 36-bit of RAM present ;-) +09:36 * morimoto focus to Renesas inside work from now +09:37 < Marex> geertu: probably all 64bit +09:38 < wsa> so, some comments have been made by mail +09:38 < wsa> About the original proposal from damm: +09:38 < geertu> damm: Alive? +09:39 < damm> yep +09:39 < wsa> I agree with pinchartl that review doesn't always result in a rev-by tag +09:39 < geertu> True +09:39 < wsa> if I have review comments not addressed yet, I don't give the tag +09:40 < geertu> I always assume a new version will appear, where I can provide mine, but probably I'm too optimistic... +09:40 < pinchartl> I sometimes end a review e-mail with "and if you address all these, Reviewed-by: ..." but that's only when the patch is mostly ready and I trust that the next round will be correct +09:40 < pinchartl> if deep rework is needed I don't do that +09:41 < wsa> pinchartl: ack +09:41 < pinchartl> sometimes the result of a review is also the realization that a patch isn't needed, in which case no new version appears +09:41 < pinchartl> there's still value there +09:42 < geertu> The list I provide to Magnus is auto-generated, so it only includes actual R-b's given. +09:42 < wsa> would it be an option to include 4) "reviewed patches still pending" or something alike? +09:42 < geertu> Sure! +09:42 < geertu> Reviewed-but-not-approved-by ;-) +09:43 < pinchartl> it's more work to split the two for me, so I'd like to know if that's actually needed +09:43 < pinchartl> same for the tested patches, if the test fails I don't give a Tested-by tag :-) +09:44 < geertu> Everything seems to be success-driven, like social media +09:44 < pinchartl> damm: was your request about splitting the list of patches in the submitted, reviewed and tested catagories, or do you need to account patches that carry a tag separately ? +09:44 < geertu> "bad" outcomes don't end up in the report +09:44 < neg> Test-failed-by: :-) +09:44 < pinchartl> in the latter case, can't we just harvest Linus' tree to extract tags automatically without needing us to account those patches manually ? +09:45 < pinchartl> it won't be linked to a particular reporting period though +09:45 < geertu> Yep, add a 2-3 month delay +09:45 < geertu> Harvesting from patchwork would have less latency +09:45 < pinchartl> but as I explained in the e-mails, a metric based on tags given out is quite useless as most of the value is attached to tags that are not given +09:45 < damm> pinchartl: splitting patches in categories would be good from my side +09:45 < jmondi> that might fail to capture reviewes that do not end up in a tag +09:46 < pinchartl> damm: then I'm fine with that, that's what I do already :-) +09:46 < damm> =) +09:48 < wsa> well, if it is just seperating reviews from tests done (without the need of a tag), I can easily do that +09:48 < wsa> and will happily do so +09:49 < wsa> consensus on that one? damm-san? +09:49 * geertu has already copied-and-modified his list-patches-reviewed-by-me script +09:50 < damm> sure +09:50 < damm> thanks guys +09:50 < wsa> cool +09:51 < wsa> so, about my request on adding desc to reviews / tests... +09:51 < wsa> I am pretty much with pinchartl here again when it comes to seperation between ack and rev. but this is not the main point for me. +09:52 < wsa> rev by only is fine enough for me, but i'd like to know what kind of review +09:52 < jmondi> wsa: I have missed if you're suggesting such a lenghty description in patch reviews or for the bi-weekly report +09:52 < wsa> nope +09:53 < wsa> just some text around the rev-by tag like "i verified against the errata" or "not familiar with PCI internals, but checked the API" or "did formal check" +09:54 < wsa> jmondi: do you get the picture? +09:54 < jmondi> I see, in the patch review email then, not just as a note to report during our meetings, right? +09:54 < pinchartl> wsa: how about not making that a strict requirement to start with, only adding such text when there's value to it +09:54 < pinchartl> (especially when the review is partial only) +09:54 < wsa> pinchartl: I'd like that +09:54 < pinchartl> and the other question was what you'll do with the information +09:55 < pinchartl> as there's no standard it then include it in the commit message +09:55 < pinchartl> s/it then/to then/ +09:55 < wsa> What I'll do with it? As a maintainer, it gives me an idea what I still need to review +09:56 < wsa> Or if a patch has enough review / test that I can send it back to stable or give it another cycle in -next +09:56 < pinchartl> ok, it gives you more information to know how much you can trust the review +09:56 < pinchartl> that's useful +09:57 -!- Marex [~Marex@195.140.253.167] has quit Ping timeout: 259 seconds +09:57 < wsa> It doesn't need to be a whole lot of text; I think it can be covered in one line mostly +09:59 < marex-cloud> Hmmm, something went wrong with my primary irc system +10:00 < wsa> I think it will increase quality because it is clear what is reviewed. There are no assumptions about the review which could be wrong +10:00 < neg> marex-cloud *switchs to the backup troll generator console* ;-) +10:00 < wsa> This is an overall experience, also coming from I2C maintenance +10:01 < wsa> but it seems there are no further comments +10:01 < geertu> I agree it's good to have such information, and thus provide it, if it makes sense. +10:02 < wsa> I totally agree it can be skipped for trivial patches +10:02 -!- Marex [~Marex@195.140.253.167] has joined #periperi +10:02 < wsa> ok, so, let's please do that from now on +10:03 < wsa> and with that we can switch to the Core meeting? +10:03 < geertu> Sounds good to me! diff --git a/wiki/Chat_log/20190307-mm-chatlog b/wiki/Chat_log/20190307-mm-chatlog new file mode 100644 index 0000000..312cbcb --- /dev/null +++ b/wiki/Chat_log/20190307-mm-chatlog @@ -0,0 +1,195 @@ +Multimedia-chat-meeting-2019-03-07 + +10:44 < pinchartl> annnnnnddddd welcome to the multimedia meeting +10:46 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:46 < morimoto> You can teach me at Japan as F2F :) +10:46 < pinchartl> * Jacopo +10:46 < pinchartl> Since last meeting: +10:46 < pinchartl> - V4L2 multiplexed stream +10:46 < pinchartl> Took over Niklas' work and posted a new version under "[PATCH v3 00/31] +10:46 < pinchartl> v4l: add support for multiplexed streams". +10:46 < pinchartl> - adv748x dynamic routing fix +10:46 < pinchartl> Capture didnb't work on media-tree master with some HDMI transmitters, +10:46 < pinchartl> fixed it with "[PATCH] media: adv748x: Don't disable CSI-2 on +10:46 < pinchartl> link_setup". +10:46 < pinchartl> - Patches review on the linux-media mailing list +10:46 < pinchartl> - DU related patches upport investigation (see Up-port below) +10:46 < pinchartl> Until next meeting: +10:46 < pinchartl> - Propose data-lane negotiation on top of v4l2-mux patches +10:46 < pinchartl> - Implement full AFE->TXA dynamic routing for E3 and other SoCs +10:46 < pinchartl> - Investigate DU up-ports tasks +10:46 < pinchartl> Issues and blockers: None +10:46 < morimoto> to Marex +10:46 < pinchartl> jmondi: any comment ? I've moved to detail of the up-port to a separate discussion after the status update +10:47 < jmondi> no comment, thanks for moving the upport part later +10:47 < pinchartl> thank you +10:48 < pinchartl> Kieran is unavailable, he reported through e-mail +10:48 < pinchartl> * Kieran +10:48 < pinchartl> Since last meeting: +10:48 < pinchartl> - PA-Phase revitalising +10:48 < pinchartl> Wrote a VSP1 phase test utility to calculate all scaling combinations, +10:48 < pinchartl> and posted new RFC patch series. +10:48 < pinchartl> - Started the DU clock sharing +10:48 < pinchartl> - Patch reviews +10:48 < pinchartl> Until next meeting: +10:48 < pinchartl> - DU group refactoring and clock sharing +10:48 < pinchartl> Issues and blockers: +10:48 < pinchartl> - Implementation of section 32.3.7.5 : Procedure 3 fails on some ratios +10:48 < pinchartl> An integer overflow or a similar issue is suspected, more work is +10:48 < pinchartl> needed. +10:48 < pinchartl> - Additional task for Q1 was ordered very late +10:48 < pinchartl> Now have to focus only on that, and can't continue PA-phase or anything +10:48 < pinchartl> else until next quarter. +10:48 < pinchartl> * Laurent +10:48 < pinchartl> Since last meeting: +10:48 < pinchartl> - LVDS dual-link prototype for the DU +10:48 < pinchartl> - DU writeback using DRM writeback connectors +10:48 < pinchartl> - Submitted additional tasks for Q1 +10:48 < pinchartl> - Patch review +10:48 < pinchartl> Until next meeting: +10:48 < pinchartl> - Finish the LVDS dual-link prototype +10:48 < pinchartl> - Prepare multimedia plan for face-to-face meeting +10:48 < pinchartl> Issues and blockers: None +10:48 < pinchartl> any question ? +10:49 < neg> Not from me +10:49 < jmondi> not here +10:49 < pinchartl> * Morimoto-san +10:49 < pinchartl> Since last meeting: +10:49 < pinchartl> - ALSA SoC framwork cleanup preparation +10:49 < pinchartl> This is still blocked by Intel. +10:49 < pinchartl> - Debugged sound issue on latest renesas-drivers +10:49 < pinchartl> The root cause has been found in commit 4472287a3b ("clk: Introduce +10:49 < pinchartl> of_clk_get_hw_from_clkspec()"), but it's not clear yet how to solve it. +10:49 < pinchartl> Discussions with the patch author are ongoing. +10:49 < pinchartl> Until next meeting: +10:49 < pinchartl> - Fix the sound clock issue +10:49 < pinchartl> - Planning Hanami-party +10:49 < pinchartl> Issues and Blockers: None +10:50 < pinchartl> morimoto: any comment ? +10:50 < morimoto> one comment is that my issue was already solved +10:50 < morimoto> yesterday +10:50 < morimoto> And posted patch, too. +10:50 < morimoto> thanks +10:51 < pinchartl> nice ! +10:51 < pinchartl> I'll update the report +10:51 < pinchartl> thank you +10:51 < pinchartl> * Niklas +10:51 < pinchartl> Since last meeting: +10:51 < pinchartl> - [PATCH] arm64: dts: renesas: r8a77990: Remove invalid compatible value for CSI40 +10:51 < pinchartl> - [PATCH] projects: Import upport tasks from bsp392 for Multimedia +10:51 < pinchartl> - Prepared v2 of CSI-2 upporting patches, one issue remains +10:51 < pinchartl> - Tracked down and updated CSI-2 and VIN patch status in periject +10:51 < pinchartl> Until next meeting: +10:51 < pinchartl> - Try to clean up the VIN crop and compose code +10:51 < pinchartl> This is needed to ease merging of UDS and PM support. +10:51 < pinchartl> - Resolve last issue for v2 of CSI-2 upporting effort and send out +10:51 < pinchartl> Issues and blockers: None +10:51 < pinchartl> neg: any comment ? +10:51 < neg> I would like to have your feedback on the rcar-csi2 video standard discussion so I can send out v2 of the upport work. Other then that I'm good +10:52 < pinchartl> I think we should discuss it on #v4l with Hans and possible Sakari +10:52 < neg> sounds good let's do it +10:52 < pinchartl> thank you +10:52 < pinchartl> * Ulrich +10:52 < pinchartl> Since last meeting: None +10:52 < pinchartl> Until next meeting: None +10:52 < pinchartl> Issues and Blockers: None +10:52 < morimoto> :) +10:53 < pinchartl> uli__: any comment ? I wasn't sure if TBD meant there would be something on the multimedia front +10:55 < pinchartl> Topic 2. Up-port +10:55 < pinchartl> Jacopo has worked on up-porting patches +10:55 < uli__> no comment +10:55 < pinchartl> - drm: rcar-du: Add clock function for LVDS PLL +10:55 < pinchartl> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=e69fabc4a6fe42c03ef7ad24e9dbb76b75efa27d +10:55 < pinchartl> This has been addressed by a6cc417d3eee ("drm: rcar-du: Turn LVDS clock +10:55 < pinchartl> output on/off for DPAD0 output on D3/E3"), present in renesas-drivers. +10:55 < pinchartl> - drm: rcar-du: Fix dpad signal routing for R8A7799X +10:55 < pinchartl> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=99547173de6e8e1ab5ef1505bf1ec0eb736c4bca +10:55 < pinchartl> Status unclear, but seems part of du/next. Will be investigated further. +10:55 < pinchartl> - arm64: dts: r8a77990-ebisu: Enable simultaneous output of VGA and HDMI +10:55 < pinchartl> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=d3394635755093f8539acfdbaf932a164ec59533 +10:55 < pinchartl> Tested VGA and HDMI output with kms-test-modeset.py on Laurent's latest +10:55 < pinchartl> drm/du/base and confirm the issue has been addressed by 3109a1bfe264 +10:55 < pinchartl> ("arm64: dts: renesas: r8a77995: draak: Enable LVDS1 encoder"). +10:55 < pinchartl> - drm: rcar-du: Add register access check +10:55 < pinchartl> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=87064ac2cbb559fa8a68ed72f7bb6c4427b02087 +10:55 < pinchartl> We have already been there with "[PATCH 0/4] drm: rcar-du: Update to SoC +10:55 < pinchartl> manual revision 1.00". Needs rebase and re-submit. +10:55 < pinchartl> - ADV7511 suspend/resume +10:55 < pinchartl> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=f8bc2cd28575d2c483d15116d41810b8b9410026 +10:55 < pinchartl> jmondi: anything to discuss then ? +10:56 < pinchartl> or did you just want to report that ? +10:56 < jmondi> this should be integrated in Niklas' great work on importing upport tasks in periject +10:57 < jmondi> apart from that we have clarified off-line most of these tasks +10:57 < pinchartl> how about we import them, and you send a periject patch on top to address these ? +10:57 < jmondi> I will investigate "drm: rcar-du: Fix dpad signal routing for R8A7799X" +10:57 < jmondi> and adv7511 suspend/resume +10:58 < jmondi> pinchartl: you mean first get Niklas' patch in, and then send patches on top? fine with me +10:58 < pinchartl> yes +10:58 < pinchartl> thank you +10:58 < pinchartl> Topic 3. Discussions +10:58 < pinchartl> any topic to discuss ? +10:59 < jmondi> pinchartl: should I wait for more reviews on v4l2-mux before trying to handle the CSI-2 data lane negotiation? +10:59 < jmondi> or could I send on top of v3? +10:59 < pinchartl> I think you can send it on top +10:59 < jmondi> pinchartl: do you plan to review v3? :p +11:01 < pinchartl> yes I do :-) +11:01 < jmondi> thanks :) +11:01 < neg> Any update on the Multimedia development plan work? +11:01 < jmondi> ah! Sakari just replied to v3 :) +11:02 < pinchartl> neg: I think at this stage I'd like to have initial feedback from Japan +11:02 < pinchartl> on Jacopo's proposal +11:02 < pinchartl> in order to discuss and finalize the plan with the team +11:02 < pinchartl> before going to Japan +11:03 < pinchartl> morimoto: damm: do you plan to review the plan proposal sent by Jacopo ? +11:04 < morimoto> I think we need to. damm-san ? +11:04 < neg> I was wondering if you had any feedback on that from none mail sources but a face to face meeting coming up might be better. I'm just being curious :-) +11:05 < pinchartl> damm: have we lost you ? :-) +11:06 < morimoto> damm: I miss you... so.. much... +11:07 < jmondi> morimoto: :) +11:07 < pinchartl> while waiting for Magnus to reply +11:07 < damm> yes +11:07 < pinchartl> ah +11:07 < pinchartl> good timing :-) +11:07 < pinchartl> was that a "yes, we lost you" ? +11:08 < damm> pretty much, but morimoto-san and i need time to review +11:08 < jmondi> morimoto: and no, we very much like you, but we all hate HTML :p +11:08 < pinchartl> have you had a chance to read Jacopo's e-mail ? do you have any feedback, or could you provide feedback by the end of next week ? +11:08 < pinchartl> damm: sure, take your time +11:09 < morimoto> jmondi: hehe :) +11:09 < pinchartl> let me know if you would like to schedule a HO discussion about it, or if you prefer interacting over e-mai +11:09 < pinchartl> l +11:09 < pinchartl> do you think you could provide early feedback by the end of next week ? +11:11 < damm> let me and morimoto-san check our schedules and see if we can meet +11:11 < pinchartl> thank you +11:11 < pinchartl> Topic 4. Additional Tasks for 2019 Q2 +11:11 < pinchartl> it's time to start thinking about those +11:11 < pinchartl> but there's a question that needs to be answered first +11:12 < pinchartl> what's the budget situation for Q2 ? +11:12 < pinchartl> I'm afraid this is again a question for our esteemed Japanese team members +11:13 < morimoto> It is very serious question +11:13 < morimoto> Only I can say *so far* is that Q2 is no problem *at this point* +11:14 < pinchartl> ok +11:14 < pinchartl> does this mean that we should currently consider that the Q2 budget will be identical to the Q1 budget, and start submitting additional tasks accordingly ? +11:15 < morimoto> I think so, shimoda-san any comment ? +11:18 < morimoto> shimoda: I miss you... so.. much... again... +11:18 < morimoto> what's happen at Japanese network ?? +11:20 < shimoda> sorry for delayed. as morimoto-san mentioned, Q2 budget is OK (same as Q1) +11:21 < pinchartl> ok +11:22 < pinchartl> we will then start proposing additional tasks +11:22 < pinchartl> any other topic to discuss today ? if not, I propose adjourning this meeting +11:23 < neg> No other topics from me +11:23 < jmondi> neg: let's sync on updating periject maybe +11:24 < jmondi> no other topics from me, thank you all +11:24 < geertu> Woops, will we switch to Summer Time on March 31, or not? +11:24 < neg> jmondi: I was hoping pinchartl would push my patch once he have looked at it +11:24 < neg> jmondi: And all changes would go on top of that +11:24 < jmondi> geertu: for the last time, yes! +11:24 < pinchartl> neg: I'll review your patch indeed, and we can then push it +11:25 < pinchartl> I think we can do so offline +11:26 < neg> sounds good to me +11:26 < pinchartl> geertu: does it mean that the next meeting will be at 16:00 JST ? +11:26 < geertu> 08:00 BST / 09:00 CEST / 10:00 EEST / 12:30 IST / 16:00 JST. +11:26 < geertu> (assuming I don't have it wrong) +11:27 < pinchartl> that's my understanding too, thanks +11:27 < pinchartl> multimedia meeting adjourned +11:27 < pinchartl> thank you all for attending, and have a nice day diff --git a/wiki/Chat_log/20190404-core-chatlog b/wiki/Chat_log/20190404-core-chatlog new file mode 100644 index 0000000..73a448f --- /dev/null +++ b/wiki/Chat_log/20190404-core-chatlog @@ -0,0 +1,117 @@ +09:29 < geertu> Welcome to today's Core Group Chat +09:30 < geertu> Agenda: +09:30 < geertu> 1. Status Updates +09:30 < geertu> 2. Discussion Topics +09:30 < geertu> Topic 1. Status updates +09:30 < geertu> A) What have we done since last time: +09:30 < geertu> Kieran is attending Linaro Connect in Bangkok. +09:30 < geertu> Marek worked on ATF (D3 Draak and V3M Eagle upstreaming, and BSP v2.0.3 +09:30 < geertu> upporting), U-Boot (E2 Alt and M3N ULCB), Linux (64bit MSI and PCIe +09:30 < geertu> cleanup), and OpenOCD (SH QSPI prototype for automated testing). +09:30 < geertu> Morimoto-san fixed sound clock issus in v5.1-rcX, fixed R-Car datasheet +09:30 < geertu> disclosure, welcomed Laurent and Marek to Hanami, and did Renesas work. +09:30 < geertu> Shimoda-san supported the BSP in CPG driver review. +09:30 < geertu> Simon enabled S2RAM on Ebisu and reposted E3 Z/Z2 clock patches. +09:30 < geertu> Ulrich reviewed pcie-rcar patches, posted I2C PFC patchs, and performend +09:30 < geertu> APE6EVM boot loader archeology. +09:30 < geertu> Geert assisted Jiada with the clk/genpd deadlock fix, posted PFC +09:30 < geertu> validation and compile-testing v3 and IPMMU suspend/resume v2, enabled +09:30 < geertu> CFI NOR FLASH on APE6EVM, upported clock and pin control errata fixes, +09:30 < geertu> completed the peri{upport,pelist}=>periject conversion for Core, and +09:30 < geertu> programmed all CP2102 USB-to-UART bridges to have unique names. +09:31 < geertu> (I hope I didn't miss anything when merging two sets of email reports) +09:32 < geertu> B) What we plan to do till next time: +09:32 < geertu> Kieran will finish Linaro Connect, and has booked holidays from 15th to +09:32 < geertu> 19th April. +09:32 < geertu> Marek plans to test and submit the BSP v2.0.3 ATF upport, to continue on +09:32 < geertu> the SH QSPI driver. +09:32 < geertu> Geert will send clock and pin control pull requests for v5.2, and will +09:32 < geertu> escape on holidays afterwards (until April 22th). +09:33 < geertu> C) Problems we have currently: +09:33 < geertu> Simon abandoned work on Gen3 ZG clocks as this is too complex to +09:33 < geertu> consider upstreaming without an upstream driver to exercise the code. +09:33 < geertu> Geert reports that the APE6EVM test application does not work when +09:33 < geertu> uploaded by OpenOCD to 0xe8200000. +09:33 < Marex> geertu: update: SH QSPI driver is in reasonable shape already , I can update U-Boot with it on E2 Alt at least ;-) +09:33 < Marex> geertu: from OpenOCD that is +09:34 < geertu> Marex: BTW, what's "SH QSPI"? +09:34 < Marex> geertu: the QSPI controller in Gen2 SoCs , used to talk to the boot SPI NOR +09:34 < Marex> geertu: it's likely in older SoCs too +09:34 < geertu> OK, so RSPI/QSPI +09:35 < geertu> Nice! +09:35 < geertu> Anything I missed? +09:37 < geertu> Topic 2. Discussion Topics +09:37 < geertu> Anything to discuss after 4 weeks of no chat meetings? +09:37 < wsa> general upporting status: +09:38 < wsa> looks like core is also mostly done with bsp392? +09:38 < geertu> Yes, there's not much left +09:39 < geertu> Most leftovers are due to missing hardware access (new ES dependencies), missing upstream drivers (3DG), or unclear policies (OPTEE) +09:41 < Marex> geertu: what's unclear about optee ? +09:41 < geertu> Marex: What does it do? +09:43 < damm> slices and dices? +09:43 < Marex> geertu: optee OS does secure tasks +09:43 < Marex> geertu: the linux side only communicates with the optee OS via SVCs +09:44 < Marex> geertu: by secure tasks, it looks like e.g. RPC HF update in a controlled manner +09:44 < Marex> geertu: you can use it to rewrite the HF even if it's locked in ATF, since Optee OS has privileges to do so +09:45 < geertu> Marex: Aha? But that needs to be enabled in firmware, too? +09:45 < geertu> And how does access control work in that case? +09:46 < Marex> geertu: "that" ? +09:46 < Marex> geertu: Linux is running in non-secure world and optee OS is the access controller +09:47 < Marex> that's my understanding of the bare bones situation +09:48 < geertu> Marex: Can it distinguish between my Linux or your Linux? +09:48 < Marex> geertu: there is some setting where optee os boots the next stage (u-boot), so it can authenticate what it starts +09:49 < Marex> geertu: and it can block your linux from running at all +09:50 < Marex> geertu: whether it can authenticate requests from random stuff in the non-secure world, I didn't check ; presumably yes +09:52 < geertu> ok +09:53 < Marex> geertu: optee OS upporting is on my list, when I get to it, I'll know more +09:53 < geertu> Marex: Great! +09:53 < Marex> geertu: ... is what you think, until you see the code :) +09:54 < Marex> morimoto: off-topic, when shall we meet tomorrow ? +09:55 < morimoto> Marex: 13:00 at Kokubuji ? +09:56 < geertu> Next Core Group Chat date? +09:56 < geertu> I won't be available in two weeks. +09:57 < marex-cloud> morimoto: Roger! +09:58 < pinchartl> geertu: I'm afraid I won't be available in 3 weeks +09:58 < shimoda> geertu: how about 18th Apr? +09:58 < geertu> shimoda: That's in two weeks ;-) +09:58 < morimoto> pinchartl: because Sky :) ? +09:58 < pinchartl> morimoto: I wish. because work :-) +09:59 < morimoto> pinchartl: ohh... orz +09:59 < horms> I will be on a break on the 18th. But I can send in a report via email. +09:59 < geertu> May 2nd? +09:59 < morimoto> geertu: it is GW (= Golden week) at Japan +09:59 < morimoto> GW = long Holiday +10:00 < pinchartl> geertu: or maybe you could appoint a deputy on the 18th ? :-) +10:01 < shimoda> geertu: oops. i missed your comment ;) In Japan side, from 29th Apr and 6th May is a GW. so 9th May? +10:01 < geertu> pinchartl: Are you volunteering? ;-) +10:01 < pinchartl> may the 2nd is in 4 weeks. if we can afford to always wait for four weeks between meetings they we should make them monthly meetings, not bi-weekly meetings +10:01 < kbingham> I'm away on the 18th :) +10:01 < pinchartl> geertu: not at all :-) +10:01 < pinchartl> 17th ? +10:01 < geertu> Marex: U R deputy? +10:02 < geertu> May 9th is an option for me +10:02 < morimoto> pinchartl: April 17th ? or May 17th ? +10:03 < geertu> As long a it's not May 32 (which is a Brexit joke in the newspaper ;-) +10:03 < pinchartl> morimoto: April +10:03 < morimoto> pinchartl: IC +10:04 < damm> pinchartl: need to leave early to prepare for another appointment, will check the report =) +10:04 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has quit [Quit: leaving] +10:05 < morimoto> 17th April is available if meeting can be finished until JSP 17:30 ;) +10:05 < morimoto> It is Renesas special-go-back-day +10:05 < pinchartl> geertu: jokes aside, there's no issue if you have to skip one of the meetings, you can appoint a deputy +10:05 < pinchartl> or we can move it to another day of the same week +10:05 < geertu> I'm not available before April 22 +10:06 < geertu> I won't have anything to report anyway +10:06 < geertu> Without Core, you can probably finish by JST 1730 on April 17th? +10:07 < wsa> how about keeping the 18th and have core reports email only? +10:07 < wsa> I can host core discussions in my IO slot if needed +10:08 < geertu> wsa: thx! +10:09 < wsa> and probaby we should schedule the next meeting after that to may, 9th because of GW? +10:09 < geertu> wsa: OK +10:09 < morimoto> 18th April, and 9th May are OK for me +10:09 < wsa> actually, that would fit my schedule very well. I am busy on May, 2nd as well +10:10 < wsa> pinchartl: ok? +10:11 < pinchartl> works for me +10:12 < wsa> cool +10:12 < pinchartl> can we start with MM ? +10:12 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20190404-io-chatlog b/wiki/Chat_log/20190404-io-chatlog new file mode 100644 index 0000000..5e23f35 --- /dev/null +++ b/wiki/Chat_log/20190404-io-chatlog @@ -0,0 +1,92 @@ +09:02 < wsa> so, let's start the IO meeting! +09:02 < wsa> here are the collected status updates: +09:02 < marex-cloud> Evening +09:02 < wsa> A - what have I done since last time +09:02 < wsa> ------------------------------------ +09:02 < wsa> Geert +09:02 < wsa> : investigated and fixed SCIF sampling point adjustment bug, reviewed SPI EEPROM +09:02 < wsa> spi-mem conversion, and converted MSIOF to readl_poll_timeout() and CS GPIO +09:02 < wsa> descriptor +09:02 < wsa> Kaneko-san +09:02 < wsa> : posted thermal calculation update for Gen3 +09:02 < wsa> Marek +09:02 < wsa> : investigated and resolved 64bit MSI addresses on Gen3, and submitted new +09:02 < wsa> versions of the PCIe cleanup series +09:02 < wsa> Niklas +09:02 < wsa> : resumed work on MMC PM imbalance on APE6EVM +09:02 < wsa> Shimoda-san +09:02 < wsa> : fixed a MMC core issue when initializing MMC, sent out a patch series about +09:02 < wsa> for en-/disabling USB PHY irqs independently, and reviewed USB and thermal +09:02 < wsa> patches +09:02 < wsa> Simon +09:02 < wsa> : tested thermal calculation update for Gen3 and discussed its problems, and +09:02 < wsa> merged PHY mode fix for Draak +09:02 < wsa> Ulrich +09:02 < wsa> : helped fixing and testing SCIF sampling point adjustment bug +09:02 < wsa> Wolfram +09:02 < wsa> : discussed in_atomic() use with Peter Zijlstra and extended and resent patch +09:02 < wsa> series for atomic I2C transfers based on this, reviewed PCIE, RTC, thermal, +09:02 < wsa> MSIOF, SCIF and SDHI patches, debugged 'no interrupt' issue for DA9063 RTC and +09:02 < wsa> tested the fix, sent minor cleanup patches while working on all of the above, +09:02 < wsa> and guided a GSoC student who wants to work on I2C passthrough with QEMU +09:02 < wsa> B - what I want to do until next time +09:02 < wsa> ------------------------------------- +09:02 < wsa> Kaneko-san +09:02 < wsa> : wants to address review of thermal calculation update for Gen3 +09:02 < wsa> Niklas +09:02 < wsa> : wants to start implement HS400 adjustment by manual calibration mode for +09:02 < wsa> upstream +09:02 < wsa> Shimoda-san +09:02 < wsa> : wants to keep at the MMC core bugfix, continue to review some RZ/G[12] patches +09:02 < wsa> for USB, and continue to investigate how to resolve the SDHI and SDIO card +09:02 < wsa> with IOMMU +09:02 < wsa> Simon +09:02 < wsa> : wants to add his MMC performance measurements to internal wiki, work on the +09:02 < wsa> unsupported internal delay mode on R-Car D3/E3, and follow up on feedback +09:02 < wsa> for on thermal zone IPA DT patches +09:02 < wsa> Wolfram +09:02 < wsa> : wants to revive the devm_i2c_new_dummy() series, handle 'arbitration lost' +09:02 < wsa> better with the IIC core, and investigate SDR104 regression with SDIO more +09:02 < wsa> C - problems I currently have +09:02 < wsa> ----------------------------- +09:02 < wsa> Geert +09:02 < wsa> : wonders how to test SCIF sampling point adjustment +09:02 < wsa> Kaneko-san +09:02 < wsa> : got thermal calculation update for E3 reviewed but is still pending acceptance +09:03 < wsa> let me know if you have comments or found bugs in there +09:03 < wsa> questions i have: +09:03 < wsa> neg: can you explain where you are with the APE6? Can you reproduce Geert's findings? +09:03 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has joined #periperi +09:05 < wsa> shimoda: there are two USB related patches for upporting: f2d95125e9b042d45eac818edfd6f2ce5d89780f and be61ce267539e16c9fca8fb793fbf3ef975554bd. Do you have time to handle these? (Or maybe they are already handled and I missed it?) +09:06 < shimoda> wsa: sure! I'll check them +09:06 < wsa> shimoda: thanks! +09:07 < neg> wsa: I have not tried I started ambitious to see if I could remove the !CONFIG_PM case and how that would look +09:08 < wsa> And how does it look? :) +09:09 < neg> To early to tell but it feels good +09:10 < wsa> Ok, so you are at it +09:11 < wsa> Marex: do have interest/resources to check further "PCI: Avoid PCI device removing/rescanning through sysfs triggers a deadlock"? +09:12 < wsa> Or shall I rather mark it "Proposed N"? +09:12 < Marex> wsa: I have it on my list +09:13 < Marex> wsa: there was some feedback where even the maintainer himself was unsure how to deal with it +09:13 < wsa> ah, good, I wondered because it wasn't in your B) part +09:13 < wsa> yes, it needs some digging +09:14 < Marex> wsa: I seem to be getting sidetracked by other lowlevel bits and pieces +09:14 < Marex> shimoda: did you have a chance to ask someone in the HW team about the PCIe 64bit MSI ? +09:15 < Marex> shimoda: basically, is the MSI address suffering from a 32bit limitation or is the MSI block a separate unit which filters full 64bit address out of the PCIe packets and triggers an interrupt ? +09:16 < Marex> shimoda: I think it's the later +09:17 < wsa> are there other questions? +09:17 < shimoda> Marex: Sure. I didn't check the manual yet, but MSI is described on the HW manual? if so, what is the section? +09:18 < wsa> in general, we are mostly through with upporting the bsp392 list +09:18 < wsa> however, the newer BSP has some additional commits which may be interesting +09:18 < wsa> I will also check the peripelist for tasks suitable for base contracts +09:19 < Marex> shimoda: 54.2.23 PCIEMSIALR and 54.2.24 PCIEMSIAUR +09:20 < Marex> shimoda: in manual v1.50 from Nov 30, 2018 +09:21 < Marex> shimoda: also, 54.3.3 on general MSI operation +09:22 < wsa> okay, I guess Marex and Shimoda-san will handle this +09:22 < wsa> if there are no further questions +09:23 < wsa> we could switch to core? +09:24 < neg> No questions from me +09:25 < wsa> geertu: are you ready? +09:25 < geertu> wsa: Yep +09:25 < wsa> then, here is the mic! +09:25 < wsa> Thank you all for this meeting diff --git a/wiki/Chat_log/20190404-mm-chatlog b/wiki/Chat_log/20190404-mm-chatlog new file mode 100644 index 0000000..4c13c7d --- /dev/null +++ b/wiki/Chat_log/20190404-mm-chatlog @@ -0,0 +1,242 @@ +Multimedia-chat-meeting-2019-04-04 + +10:13 < pinchartl> welcome to the multimedia meeting +10:13 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:13 < pinchartl> * Jacopo +10:13 < pinchartl> Since last meeting: +10:13 < pinchartl> - [RFC 0/5] media: Implement negotiation of CSI-2 data lanes +10:13 < pinchartl> - [PATCH v4 00/31] v4l: add support for multiplexed streams +10:13 < pinchartl> - Patch review +10:13 < pinchartl> - [PATCH v4 0/7] TVP5150 new features +10:13 < pinchartl> - [PATCH v3 2/2] media: Introduce helpers to fill pixel format struct +10:13 < pinchartl> Until next meeting: +10:13 < pinchartl> - v5 of multiplexed stream support + data lane negotiation +10:13 < pinchartl> Issues and blockers: None +10:14 < pinchartl> I believe Jacopo is busy getting is mouth tortured by a dentist +10:14 < pinchartl> * Kieran +10:14 < pinchartl> Since last meeting: +10:14 < pinchartl> - DU group handling refactoring +10:14 < pinchartl> - UDS phase handling in VSP partition algorithm +10:14 < pinchartl> - Linaro Connect in Bangkok +10:14 < pinchartl> Until next meeting: +10:14 < pinchartl> - Finish Linaro Connect +10:14 < pinchartl> - Complete UDS phase handling in VSP partition algorithm +10:14 < pinchartl> - Work on the DU group rework issues reported by Test Team +10:14 < pinchartl> Issues and blockers: None +10:14 < pinchartl> kbingham: any comment ? +10:15 < kbingham> That' sums it up :) +10:15 < pinchartl> thank you +10:15 < pinchartl> * Laurent +10:15 < pinchartl> Since last meeting: +10:15 < pinchartl> - Finished the LVDS dual-link prototype +10:15 < pinchartl> - Submitted DU pull requests (writeback support, misc fixes) +10:15 < pinchartl> - Added support for missing RGB formats in the VSP and DU drivers +10:15 < pinchartl> - Prepared multimedia plan for face-to-face meeting +10:15 < pinchartl> - Face-to-face meeting with Renesas in Japan +10:15 < pinchartl> Until next meeting: +10:15 < pinchartl> - Move forward with the LVDS dual-link prototype +10:15 < pinchartl> - Prepare 2019 Q2 additional tasks in sync with the multimedia +10:15 < pinchartl> development plan +10:15 < pinchartl> Issues and blockers: None +10:15 < pinchartl> (let's handle the face-to-face meeting as part of the discussions after the status update) +10:15 < pinchartl> any question ? +10:16 < neg> Not from me +10:16 < morimoto> Thank you for F2F meeting at Renesas +10:16 < pinchartl> thank you for hosting it :-) +10:16 < pinchartl> * Morimoto-san +10:16 < pinchartl> Since last meeting: +10:16 < pinchartl> - Fixed sound clock issue for v5.1-rcX +10:16 < pinchartl> - Reviewed E3 sound support patch +10:16 < pinchartl> - Sound-related Q/A with customer +10:16 < pinchartl> - Fixed a sound DT regression in v5.1 +10:16 < pinchartl> Until next meeting: +10:16 < pinchartl> - Continue with ALSA SoC work +10:16 < pinchartl> Issues and Blockers: None +10:16 < pinchartl> morimoto: you also reported by e-mail about creating a "pseudo", but I'm not sure to understand what you meant +10:17 < pinchartl> could you please elaborate ? +10:17 < morimoto> Ahh +10:17 < morimoto> The perfect is like this +10:17 < morimoto> "Linux" + "Intel guys work" + "my work" +10:18 < morimoto> but "Intel guys work" is based on Intel guys +10:18 < morimoto> So, I created pseudo code, like this +10:18 < morimoto> "Linux" + "pseudo Intel code" + "my work" +10:18 < morimoto> Is it clear for you ? +10:19 < pinchartl> yes, thank you +10:19 < pinchartl> do you plan to upstream the pseudo Intel code ? :-) +10:19 < morimoto> Good question :) +10:19 < morimoto> but no such plan ;) +10:20 < morimoto> Sorry for my unclear mail +10:20 < pinchartl> seriously speaking, if Intel stalls forever, and that blocks your work, after pinging them several times you could take over that work if needed +10:21 < morimoto> Yeah, I tried it few weeks ago +10:21 < morimoto> And agreed. thank you for your advice +10:21 < pinchartl> you're welcome. let me know if I can help +10:21 < pinchartl> * Niklas +10:21 < pinchartl> Since last meeting: +10:21 < pinchartl> - [PATCH v2 0/2] rcar-csi2: Use standby mode instead of resetting +10:21 < pinchartl> - [PATCH v2] rcar-csi2: Propagate the FLD signal for NTSC and PAL +10:21 < pinchartl> - [PATCH v2 0/3] rcar-csi2: Update start procedures to latest revision of datasheet +10:21 < pinchartl> - [PATCH] arm64: dts: renesas: r8a774c0: Remove invalid compatible value for CSI40 +10:21 < pinchartl> - [PATCH v3 0/2] rcar-csi2: Use standby mode instead of resetting +10:21 < pinchartl> - [PATCH v3] rcar-csi2: Propagate the FLD signal for NTSC and PAL +10:21 < pinchartl> - [PATCH v3 0/3] rcar-csi2: Update start procedures to latest revision of datasheet +10:21 < pinchartl> Until next meeting: +10:21 < pinchartl> - Try to clean up the VIN crop and compose code +10:21 < pinchartl> This is needed to merge UDS and PM support. +10:21 < pinchartl> Issues and blockers: None +10:21 < pinchartl> neg: any comment ? +10:22 < neg> No additional comment +10:22 < pinchartl> thank you +10:22 < pinchartl> * Ulrich +10:22 < pinchartl> Since last meeting: None +10:22 < pinchartl> Until next meeting: None +10:22 < pinchartl> Issues and Blockers: None +10:22 < pinchartl> uli___: no MM work planned so far, is that correct ? +10:23 < uli___> yes +10:23 < pinchartl> thank you +10:24 < pinchartl> Topic 2. Discussions +10:24 < pinchartl> I'll start with +10:24 < pinchartl> - Face-to-face meeting in Japan +10:24 < pinchartl> as you probably all know, I met with the BSP team in Tokyo on March the 26th +10:25 < pinchartl> I explained the multimedia development plan and strategy, and expanded that to also touch areas outside of the MM group +10:26 < pinchartl> the feedback I have received during the meeting was limited, and mostly consisted of BSP requests for MM development unrelated to the plan that was presented +10:26 < pinchartl> *however* +10:26 < pinchartl> there were several interesting points worth noting +10:27 < pinchartl> one, even though I tried to include more text than usual on my slides to make it easier to follow, there was still probably a language barrier that made communication a bit hard +10:27 < pinchartl> I know I speak too fast :-S +10:27 < pinchartl> so the BSP team has received the slides, and Morimoto-san said they would provide feedback on the plan +10:27 < pinchartl> two, the budget situation is very unclear, with all options being on the table +10:28 < pinchartl> in some discussions the future looked gloomy, but in others the BSP team talked about Gen4 +10:28 < pinchartl> we don't know what will happen next year (or even after Q3) but hoping is still permitted +10:29 < pinchartl> three, on the multimedia side, there was a good match between key areas we have identified and one request from the BSP team related to VSP performance improvement +10:29 < pinchartl> that match is the request API, which I plan to propose as one of the core work items for MM in the next two quarters +10:30 < pinchartl> to finalize the plan proposal I will need the feedback from the BSP team I mentioned above +10:30 < pinchartl> four, I explained during the meeting that the thin slicing of budget in small additional tasks made it difficult to tackle bigger development tasks +10:30 < pinchartl> and asked if we could solve that somehow +10:30 < pinchartl> the request seemed to be well received, and Morimoto-san said he would try to help with that +10:31 < pinchartl> we thus need to make a proposal +10:31 < pinchartl> this depends on the finalization of the development plan +10:31 < pinchartl> that's a coarse summary of the discussions +10:31 < pinchartl> any question or comment ? +10:31 < pinchartl> morimoto: anything you would like to add, anything I missed ? +10:32 < morimoto> please wait few min +10:32 < neg> morimoto: pinchartl: Thanks to you both for having this meeting and sharing the results of it +10:33 < pinchartl> morimoto: sure +10:33 < pinchartl> neg: you're welcome +10:33 < pinchartl> in the meantime, any other question or comment ? +10:33 < pinchartl> or any other discussion point for today (I want to discuss additional tasks for Q2) +10:33 < neg> pinchartl: I know the burden of traveling to Japan for it must have been gruesome ;-) +10:34 < wsa> I want to point out (again) that M/M is (rightfully) different from IO, and probably core +10:34 < morimoto> About one, sorry for our English skill +10:34 < pinchartl> neg: you know I will always donate my person for the good cause (I hope this comes out correctly in English) +10:34 < wsa> the thin slicing wasn't too bad for IO +10:34 < pinchartl> morimoto: no need to be sorry. the issue wasn't caused by your bad English skills, it was caused by my lack of Japanese skills :-) +10:34 < wsa> but I understand that it was difficult for M/M +10:35 < pinchartl> wsa: I agree, the problem differs in the three groups, and also depends on the tasks at hand +10:35 < wsa> I'm just saying a "one process for all" will always face this diversity +10:36 < morimoto> About three, thank you for your help +10:36 < neg> For the limitations we identified in MM I think it's encouraging that talk of how to handle that in a new format of additional contracts have started +10:36 < morimoto> About four, it depends with two +10:37 < morimoto> But I want to solve the issue +10:37 < morimoto> It needs Jinso-Renesas-Magnus-SoW connection +10:38 < morimoto> It is my (our) home-work +10:39 < pinchartl> my opinion is that the SoWs and additional tasks are related to the development plan. I would thus like to finalize the plan based on the feedback from the BSP team, and then discuss together how we can create SoWs that keep the concept of additional tasks, but make that fit with larger development +10:39 < pinchartl> do you know when we could receive feedback on the proposals ? +10:40 < morimoto> from BSP team ? +10:40 < pinchartl> yes +10:40 < morimoto> I'm waiting it. I will send ping to them +10:41 < pinchartl> thank you +10:42 < pinchartl> any other question or comment ? +10:43 < neg> Is it too early to start to plan Renesas days around OSSJ ? +10:43 < pinchartl> I'd say the earlier the better +10:44 < pinchartl> the first question is then, will we have a periperi meeting in Japan ? +10:44 < pinchartl> (around OSSJ- +10:44 < pinchartl> ) +10:45 < pinchartl> morimoto: any plan on Renesas side ? +10:45 < morimoto> No plan so far +10:46 < pinchartl> morimoto: do you think we should make a plan ? :-) +10:46 < wsa> I am not going to OSSJ this year, too many schedule conflicts :( +10:46 < pinchartl> wsa: :-( +10:46 < morimoto> I'm plannng so far for OSSJ is Chanko which is requested from wsa +10:46 < pinchartl> how about everybody else, who plans to go, who will not go, and who is still undecided ? +10:46 < morimoto> wsa: Grrr you don't this year +10:47 < pinchartl> I know Kieran will likely not be able to join, due to having a wedding on both sides of the conference +10:47 < wsa> morimoto: didn't i tell you? +10:47 < uli___> i intend to go +10:47 < pinchartl> (getting married once is already crazy, having two weddings is even worse if you ask me :-)) +10:47 < pinchartl> uli___: that's the right decision :-) +10:47 < kbingham> Correct. OSSJ is highly unlikekly for me I'm afraid. +10:47 < morimoto> wsa: did you ? I don't remember... +10:47 < wsa> i thought we discussed OSSJ attendance somewhen already on IRC +10:48 < pinchartl> geertu: how about you ? +10:48 < neg> kbingham: will the divorce papers clear in time for the second wedding? +10:48 < pinchartl> horms: same question ? +10:48 < wsa> morimoto: I'm sad myself :'-( +10:49 < kbingham> neg, They'll be fine. +10:49 < horms> If the question is about OSSJ then the answer is that I currently have no plans to attend +10:49 < morimoto> wsa: I will miss you, so much... +10:49 < pinchartl> horms: yes, that was the question. would you make plans to attend if needed, or is that unlikely ? +10:50 < wsa> maybe we should do this by email, but what about you guys attending Plumbers (Lisboa) and/or Embedded/Kernel-Recipes (Paris) in September +10:50 < wsa> ? +10:50 < wsa> morimoto: will we meet in Lyon at ELCE? +10:50 < pinchartl> wsa: LPC or ELCE would be a good idea too +10:50 < morimoto> Maybe I can't joint to ELCE this year +10:51 < morimoto> s/joint/join/ +10:51 < pinchartl> morimoto: I suppose it depends on the budget situation, and we will only know about it later ? +10:52 < pinchartl> geertu: ping ? +10:52 < horms> pinchartl: if its important I can make a plan. but other plans would work better for me, f.e. I do plan to attend LPC and ELCE would take me about as long to drive to as it would to fly to OSSJ +10:53 < pinchartl> horms: ok +10:53 < pinchartl> so a whole periperi meeting seems more likely at LPC or ELCE time than OSSJ time at the moment +10:53 < pinchartl> I have submitted a talk proposal for OSSJ so I will likely go +10:54 < pinchartl> maybe we'll have a MM meeting instead of a global meeting then +10:54 < geertu> pinchartl: I can go to OSSJ +10:55 < pinchartl> geertu: nice :-) +10:55 < geertu> I will be at Embedded-Recipes (invited speaker) +10:55 < wsa> same here for Embedded Recipes +10:55 < geertu> It's been 3 years since I've been to JP :-( +10:55 < wsa> not sure about Plumbers yet +10:55 < geertu> wsa: Marex did a good job ;-) +10:55 < pinchartl> what will you speak about at RC ? +10:55 < wsa> yes :D +10:55 < pinchartl> s/RC/ER/ +10:56 < geertu> pinchartl: No topic set so far +10:56 < wsa> similar here, a rough idea was to speak about my subsystem (new things, workflow...) +10:56 * geertu considers a talk about the Japanese cherry tree in his garden +10:58 < pinchartl> :-) +10:58 < geertu> Probably I should install a camra to take daily Sakura pictures +10:58 < wsa> morimoto: you are not coming to Lyon? Well, looks like I need to find another excuse than OSSJ to come to Japan then :) +10:58 < geertu> And I plan to attend ELCE, as usual +10:59 < geertu> (until LF has exploded by then) +10:59 < geertu> s/until/unless/ +11:00 < pinchartl> any plan to make LF explode ? +11:00 < wsa> Yeah, I plan for ELCE, too +11:01 < morimoto> wsa: yeah, I can't this year. so sorry +11:01 < geertu> http://techrights.org/2019/03/30/what-happened-lf/ +11:02 < pinchartl> geertu: interesting, I had missed that +11:02 < pinchartl> anyway, the conclusion for now is +11:02 < pinchartl> likely no official global meeting around OSSJ +11:02 < pinchartl> perhaps a multimedia meeting +11:03 < pinchartl> and perhaps a global meeting around LPC or ELCE (but that is likely conditioned by budget) +11:03 < pinchartl> next discussion topic for the MM meeting +11:03 < pinchartl> additional tasks for Q2 +11:03 < pinchartl> as discussed before, the plan is to makes those tasks fit in the global MM development plan +11:04 < pinchartl> I would like to already move forward with tasks related to the request API +11:04 < pinchartl> for other tasks, I would like to first receive feedback from the BSP team on the plan +11:04 < pinchartl> neg: if I understand correctly, you have all your additional task time allocated already for Q2, right ? +11:06 < marex-cloud> morimoto: I'll likely be at OSSJ :) +11:06 < geertu> marex-cloud: Critical mass reached! +11:07 < marex-cloud> geertu: heh +11:07 < neg> pinchartl: yes Q2 already allocated +11:07 < marex-cloud> geertu: I'll also be at ER most likely, I seem to be roped into a special role +11:07 < pinchartl> neg: thanks +11:08 < marex-cloud> geertu: godfather was the name I think +11:08 < pinchartl> so I'll work on a proposal for the request API already, and wait for feedback for the rest +11:08 < pinchartl> any other dicussion topic for today ? +11:09 < neg> not from me, thanks +11:09 < morimoto> marex-cloud: nice to know :) +11:09 < marex-cloud> geertu: what about doing a trip to Toyama around OSSJ, eat great food etc? +11:09 < pinchartl> I then propose adjourning this meeting. does anyone second ? +11:10 < neg> second +11:10 < morimoto> 3rd +11:10 < marex-cloud> morimoto: maybe I should consider relocation ^_^' +11:10 < morimoto> marex-cloud: sorry for what ? +11:10 < pinchartl> meeting adjourned. thank you all for attending diff --git a/wiki/Chat_log/20190418-io-chatlog b/wiki/Chat_log/20190418-io-chatlog new file mode 100644 index 0000000..4974755 --- /dev/null +++ b/wiki/Chat_log/20190418-io-chatlog @@ -0,0 +1,135 @@ +2019-04-18 09:02:21 wsa so, let's start the IO meeting (with a core appendix, if needed) +2019-04-18 09:02:34 wsa updates: +2019-04-18 09:02:39 wsa A - what have I done since last time +2019-04-18 09:02:39 wsa ------------------------------------ +2019-04-18 09:02:39 wsa Kaneko-san +2019-04-18 09:02:39 wsa : posted a new version of thermal calculation update for Gen3 +2019-04-18 09:02:39 wsa Marek +2019-04-18 09:02:41 wsa : clarified further MSI 32bit limitation question for PCIE +2019-04-18 09:02:44 wsa Niklas +2019-04-18 09:02:46 wsa : posted a new version of the SDHI clock imbalance fix +2019-04-18 09:02:49 wsa Shimoda-san +2019-04-18 09:02:51 wsa : posted new versions for fixing a MMC core issue when initializing MMC and +2019-04-18 09:02:54 wsa for en-/disabling USB PHY irqs independently, reviewed various USB patches +2019-04-18 09:02:56 wsa for r8a77470 +2019-04-18 09:02:59 wsa Simon +2019-04-18 09:03:01 wsa : posted RAVB patches to address no TX internal delay on D3/E3 +2019-04-18 09:03:04 wsa Wolfram +2019-04-18 09:03:06 wsa : reworked and merged atomic transfers for I2C, started updating the +2019-04-18 09:03:09 wsa devm_i2c_new_dummy() series, did initial travel planning for LinuxPlumbers +2019-04-18 09:03:11 wsa and ELCE, refactored watchdog core and users for better timeout initialization, +2019-04-18 09:03:14 wsa did minor updates to DA9063 and RWDT watchdog drivers, supported Steven Twiss +2019-04-18 09:03:17 wsa (Diasemi) to ensure continued upstream support for our DA9063-AD variant, +2019-04-18 09:03:20 wsa reviewed a few RAVB and SDHI patches +2019-04-18 09:03:22 wsa B - what I want to do until next time +2019-04-18 09:03:25 wsa ------------------------------------- +2019-04-18 09:03:27 wsa Kaneko-san +2019-04-18 09:03:30 wsa : wants to address review of thermal calculation update for Gen3 +2019-04-18 09:03:32 wsa Niklas +2019-04-18 09:03:35 wsa : wants to support Geert in testing the SDHI clock imbalance issue +2019-04-18 09:03:37 wsa Shimoda-san +2019-04-18 09:03:40 wsa : wants to continue to investigate how to resolve the SDHI and SDIO card with +2019-04-18 09:03:42 wsa IOMMU issue, and ping the PHY maintainer about pending patches +2019-04-18 09:03:45 wsa Simon +2019-04-18 09:03:47 wsa : wants to repost the RAVB patch, and discuss with Renesas if the delay mode +2019-04-18 09:03:50 wsa of the PHY can be utilized for RAVB gigabit +2019-04-18 09:03:52 wsa Wolfram +2019-04-18 09:03:55 wsa : wants to handle 'arbitration lost' better with the IIC core, and investigate +2019-04-18 09:03:57 wsa SDR104 regression with SDIO more +2019-04-18 09:04:00 wsa C - problems I currently have +2019-04-18 09:04:02 wsa ----------------------------- +2019-04-18 09:04:05 wsa Kaneko-san +2019-04-18 09:04:07 wsa : got thermal calculation update for E3 reviewed but is still pending acceptance +2019-04-18 09:04:10 wsa Niklas +2019-04-18 09:04:13 wsa : could not reproduce the PM issue on APEVE6 as reported by Geert +2019-04-18 09:04:15 wsa Shimoda-san +2019-04-18 09:04:18 wsa : struggles with the problematic budget situation +2019-04-18 09:04:20 wsa Wolfram +2019-04-18 09:04:23 wsa : had some annoying (but likely not serious) health issues this week +2019-04-18 09:04:25 wsa mistakes in there? questions? +2019-04-18 09:04:28 wsa horms: about the pending E3 thermal patch, maybe a resend would be a good idea? +2019-04-18 09:04:31 wsa when you gave the Tested-by tag, you also made a review comment, probably also good to address it then. +2019-04-18 09:05:01 wsa neg: thanks for the new clock imbalance patch, but we definately need Geert to reproduce the issue, I think. +2019-04-18 09:05:19 neg wsa: Yes I agree, Geerts input is needed +2019-04-18 09:05:26 horms wsa: sure, will resend +2019-04-18 09:05:40 wsa morimoto: shimoda: thanks for all the brave budget fighting! +2019-04-18 09:05:52 morimoto Yeah, not yet finished +2019-04-18 09:05:56 wsa magnus, too, of course +2019-04-18 09:06:06 horms likewise, thanks! +2019-04-18 09:06:23 neg yes, thanks! +2019-04-18 09:06:51 wsa uli__: did you have a chance to look into the RAVB & MTU topic yet? +2019-04-18 09:07:57 wsa morimoto: since we are now in the process of using periject, do you think it is currently still needed to update peripelist? And update its 'schedule.wiki' in our redmine page? +2019-04-18 09:08:43 morimoto wsa: my understanding is that we already agreed to switch to periject before ? +2019-04-18 09:08:52 wsa yes +2019-04-18 09:08:54 morimoto no more peripelist update is needed +2019-04-18 09:09:06 wsa i understand, thank you +2019-04-18 09:09:08 neg wsa: I missed RAVB+MTU issue, what thread should I dig up? +2019-04-18 09:09:15 morimoto I have no idea about "redmine page update" +2019-04-18 09:09:23 neg only curious +2019-04-18 09:09:38 wsa morimoto I wasn't sure if there was a transition time where it would make sense to update both +2019-04-18 09:10:36 wsa neg: no new thread, I asked Uli if he had time to work on the "update max MTU size while interface is up" task since it seemed he had some time available +2019-04-18 09:10:50 morimoto we don't need to update peripelist, and periject doesn't have xx.wiki output +2019-04-18 09:10:58 morimoto update both is difficult ? +2019-04-18 09:11:21 neg wsa: ahh, nice sorry for being nosy :-) +2019-04-18 09:11:35 wsa morimoto: no, not difficult. but if it is not needed, there is no need to do it :) +2019-04-18 09:11:40 Marex wsa: is anyone planning to implement TMPPORT4-7 workaround for HS400 in Linux ? (see emmc_109.pptx in the workaround/ dir for details) +2019-04-18 09:11:46 wsa morimoto: if it has use, I can still do it +2019-04-18 09:12:09 wsa Marex: yes, this is (hopefully) and add. task for neg in Q2 +2019-04-18 09:12:26 Marex wsa: ah, good +2019-04-18 09:12:41 Marex neg: make sure to grill it on ULCBs and E3 Ebisu, those things are sensitive, esp. Ebisu +2019-04-18 09:13:04 morimoto We (= Renesas side) have no request for redmine update +2019-04-18 09:13:29 morimoto wsa: but thank you for caring about it +2019-04-18 09:13:32 wsa morimoto: good to know, thanks! +2019-04-18 09:13:45 neg Marex: I have no ULCBs nor E3, if I get a task I will CC you and hope you will bbq them for me ;-) +2019-04-18 09:14:13 Marex neg: Magnus has one in remote access rack +2019-04-18 09:15:11 wsa because that depends on temperature, it might make sense to have a physical board... +2019-04-18 09:15:23 neg Marex: thanks, lets see if I can get access to it/them +2019-04-18 09:15:47 Marex wsa: I would very much love to have a physical V3M/V3H board(s) :-) +2019-04-18 09:15:48 wsa horms: do you use your Ebisu a lot? :) +2019-04-18 09:16:16 horms wsa: I'm not sure how you define a lot, but yes I use it. How can I help? +2019-04-18 09:16:47 horms I'm happy to send it out as a loaner if that helps move something forwards. +2019-04-18 09:17:04 wsa Yes, that might be useful for neg's task in Q2 +2019-04-18 09:17:18 horms Sure, happy to help +2019-04-18 09:17:26 wsa cool! +2019-04-18 09:17:31 wsa thanks! +2019-04-18 09:17:37 horms neg: just send me some shipping details if/when you want to move forwards on this +2019-04-18 09:18:29 wsa hi magnus! +2019-04-18 09:18:54 damm hi wolfram! +2019-04-18 09:19:15 damm sorry for being late, lost track of time when poking around with the pc +2019-04-18 09:19:24 neg horms: sure will do, but if I get the task and need to test on E3 I might as well ship myself to AMS for a day or two ;-) +2019-04-18 09:20:05 horms shimoda: do you have any feedback regarding using the TX delay mode on the phy on Ebisu/Draak? I think that is blocking progress on resolving the related errata. Though I can finlise the RAVB driver portion regardless. +2019-04-18 09:20:13 wsa you should burn the board, not yourself ;))) +2019-04-18 09:20:19 Marex damm: did it involve some JTAG too ? :-)) +2019-04-18 09:20:20 horms neg: of course that is also fine +2019-04-18 09:20:36 damm Marex: unfortunately not +2019-04-18 09:20:53 Marex damm: OK, that's fine too :) +2019-04-18 09:22:29 shimoda horms: unfortunately, i don't get any feedback from BSP team. But, I found information on internal redmine. So, I'll forward this info later. +2019-04-18 09:22:50 shimoda the information contains sample dt properties +2019-04-18 09:22:52 Marex shimoda: thank you for checking the PCIe MSI bits for me +2019-04-18 09:24:05 shimoda Marex: you're welcome. But, as you mentioned, the hw manual seems to mention both EP and RC of the PCICE +2019-04-18 09:24:31 shimoda so, I'll ask hw team later +2019-04-18 09:24:49 Marex shimoda: I think so, it makes a lot of sense that the HW people tested R-Car Gen3 vs R-Car Gen3 and wrote the procedure down in the datasheet +2019-04-18 09:25:05 wsa so, a short comment about my private chat with Steve Twiss from Diasemi: +2019-04-18 09:25:14 Marex shimoda: would it make sense to implement PCIe endpoint mode for Linux at some point ? +2019-04-18 09:25:20 horms shimoda: thanks +2019-04-18 09:25:41 wsa he was curious because we have the 9063AD variant on our Gen2 boards which according to his HW engineers is not out in the wild +2019-04-18 09:26:18 wsa IIUC the upper management wanted to remove that AD variant support from Linux (he didn't want to) +2019-04-18 09:26:49 wsa so, having found actual users seems to be a good argument to keep the support +2019-04-18 09:27:35 shimoda Marex: I don't know whether adding endpoint mode makes sense or not. also I'm not sure sal-xs can acts as endpoint mode. +2019-04-18 09:28:14 Marex shimoda: I can check, but I suspect it might need a minor HW adjustment +2019-04-18 09:28:29 Marex wsa: heh +2019-04-18 09:28:49 Marex morimoto: shimoda: btw. is renesas somehow cooperating with Alibaba Inc. ? I had them asking about mainline U-Boot recently :) +2019-04-18 09:29:17 wsa Are there any Core related items to discuss? +2019-04-18 09:29:28 wsa i think we are done with the IO specific parts, or? +2019-04-18 09:29:41 morimoto Marex: maybe but we don't know detail +2019-04-18 09:30:08 Marex morimoto: OK, I'll try to help them out +2019-04-18 09:30:39 morimoto Marex: thanks +2019-04-18 09:30:47 Marex sure +2019-04-18 09:32:55 wsa okay, if there are no more questions (neither core or IO)... +2019-04-18 09:33:03 neg wsa: I have no more IO things to talk about +2019-04-18 09:33:12 wsa neg: shoot +2019-04-18 09:33:23 wsa ah, 'no more'... +2019-04-18 09:33:25 wsa :D +2019-04-18 09:33:25 neg ;-) +2019-04-18 09:33:49 wsa pinchartl: seems like M/M turn now, do you want the mic now? +2019-04-18 09:33:54 pinchartl please diff --git a/wiki/Chat_log/20190418-mm-chatlog b/wiki/Chat_log/20190418-mm-chatlog new file mode 100644 index 0000000..02d8aef --- /dev/null +++ b/wiki/Chat_log/20190418-mm-chatlog @@ -0,0 +1,125 @@ +Multimedia-chat-meeting-2019-04-18 + +09:34 < pinchartl> welcome to the multimedia meeting +09:34 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +09:34 < pinchartl> * Jacopo +09:34 < pinchartl> Since last meeting: +09:34 < pinchartl> - holding v5 of v4l2-multiplexed stream due to a pending clarification +09:34 < pinchartl> Likewise, data lane negotiation support is on hold for the same reason. +09:34 < pinchartl> Discussions with Sakari are ongoing. +09:34 < pinchartl> - [PATCH] arm64: dts: renesas: r8a77965: Remove reg-names of display node +09:34 < pinchartl> - [PATCH 0/2] media: rcar-vin: Add "renesas,id" to V3H +09:34 < pinchartl> - Patch review +09:34 < pinchartl> Until next meeting: +09:34 < pinchartl> - Multiplexed streams again and again until we merge something +09:34 < pinchartl> - More low bandwidth upporting +09:34 < pinchartl> - Review Niklas' series on Gen2/Gen3 VIN unification +09:34 < pinchartl> Issues and blockers: None +09:34 < pinchartl> jmondi: any comment ? +09:35 < neg> I think jmondi excused him self from the meeting due to dentist +09:35 < pinchartl> * Kieran +09:35 < pinchartl> Since last meeting: +09:35 < pinchartl> - VSP partition algorithm improvements to handle UDS phase +09:35 < pinchartl> - Reviewed DU/VSP support for RZ/G2M +09:35 < pinchartl> - Reviewed Jacopo's adv748x work and helped with io_10 register rework +09:35 < pinchartl> Until next meeting: +09:35 < pinchartl> - Work on the DU group rework issues reported by Test Team +09:35 < pinchartl> Issues and blockers: None +09:35 < pinchartl> neg: my bad +09:35 < pinchartl> Kieran is also way, he sent me his status report directly +09:36 < pinchartl> * Laurent +09:36 < pinchartl> Since last meeting: +09:36 < pinchartl> - Fixes for DU/VSP additional 4CCs support +09:36 < pinchartl> - Merge DU support for the RZ/G2M (r8a774a1) +09:36 < pinchartl> - LVDS dual-link rebase +09:36 < pinchartl> - Patch review +09:36 < pinchartl> Until next meeting: +09:36 < pinchartl> - Get the LVDS dual-link prototype merged +09:36 < pinchartl> - Prepare 2019 Q2 additional tasks in sync with the multimedia +09:36 < pinchartl> development plan +09:36 < pinchartl> Issues and blockers: None +09:36 < pinchartl> any question ? +09:36 < neg> not from me +09:37 < morimoto> I sent question mail to you, and no return yet... +09:37 < morimoto> s/return/reply/ +09:38 < pinchartl> morimoto: my bad, that mail got buried in my inbox as I was travelling +09:38 < pinchartl> I'll reply right after the meeting +09:38 < pinchartl> sorry about it +09:38 < morimoto> thanks a lot, no problem +09:39 < pinchartl> * Morimoto-san +09:39 < pinchartl> Since last meeting: +09:39 < pinchartl> - ALSA SoC framework modernisation +09:39 < pinchartl> Intel's plans have changed, removing the dependency we had on them. Work +09:39 < pinchartl> has thus moved forward, with patches posted, and Intel provided +09:39 < pinchartl> feedback. +09:39 < pinchartl> Until next meeting: +09:39 < pinchartl> - Continue with ALSA SoC work +09:39 < pinchartl> Issues and Blockers: None +09:39 < pinchartl> morimoto: any comment ? +09:39 < morimoto> No, thanks +09:39 < pinchartl> thank you +09:39 < pinchartl> * Niklas +09:39 < pinchartl> Since last meeting: +09:39 < pinchartl> - [PATCH v3] rcar-csi2: Move setting of Field Detection Control Register +09:39 < pinchartl> - [PATCH v2] rcar-csi2: restart CSI-2 link if error is detected +09:39 < pinchartl> - [PATCH v4] rcar-csi2: Propagate the FLD signal for NTSC and PAL +09:39 < pinchartl> - PATCH 0/8] rcar-vin: Merge Gen2 and Gen3 file operations +09:39 < pinchartl> - Code review and arguing with Steve Longerbeam ;-) +09:39 < pinchartl> Until next meeting: +09:39 < pinchartl> - Try to clean up the VIN crop and compose code +09:39 < pinchartl> This is needed to merge UDS and PM support. +09:39 < pinchartl> Issues and blockers: None +09:40 < pinchartl> neg: any comment ? +09:40 < neg> No comment +09:40 < pinchartl> thank you +09:40 < pinchartl> * Simon +09:40 < pinchartl> Since last meeting: None +09:40 < pinchartl> Until next meeting: None +09:40 < pinchartl> Issues and Blockers: +09:40 < pinchartl> - Testing needed for Draak VIN DT patch +09:40 < pinchartl> [PATCH] arm64: dts: renesas: draak: Remove unecessary index from vin4 port +09:41 < pinchartl> horms: I have a Draak board +09:41 < pinchartl> how can I test the patch ? +09:42 * jmondi back +09:43 < jmondi> dentist indeed, sorry for being late +09:43 < neg> pinchartl: Look at the media graph before and after applying the patch, they should look the same +09:43 < pinchartl> neg: ok, that's easy. I'll do so +09:43 < pinchartl> jmondi: welcome +09:43 < pinchartl> * Ulrich +09:43 < pinchartl> Since last meeting: None +09:43 < pinchartl> Until next meeting: None +09:43 < pinchartl> Issues and Blockers: None +09:43 < pinchartl> uli__: any comment ? +09:44 < pinchartl> any question or comment from anyone on the status update ? +09:45 < neg> not from me +09:45 < jmondi> still reading backlog, but I would say no +09:45 < pinchartl> thank you +09:46 < pinchartl> Topic 2. Discussions +09:46 < pinchartl> any topic to discuss ? +09:46 < pinchartl> there's the elephant in the room topic of budget after Q3. it's not limited to multimedia though +09:46 < jmondi> pinchartl: neg: I plan to reply to Sakari to his long email today, do you think you will have time to read his email too? +09:47 < jmondi> I would be interested in your opinion ofc +09:48 < pinchartl> jmondi: I'll try. what's the subject ? +09:48 < neg> jmondi: which mail, in the [PATCH v4 00/31] v4l: add support for multiplexed streams thread ? +09:49 < jmondi> nope +09:49 < jmondi> Route lifetime in SUBDEV_[GS]_ROUTING +09:49 < jmondi> on linux-media +09:49 < jmondi> I can forward it +09:49 < jmondi> I have not read it yet, might be simple +09:50 < pinchartl> I'll let you read it first, and then tell me if I should have a look too +09:51 < pinchartl> any other discussion topic ? +09:51 < jmondi> no, sorry for interrupting +09:52 < neg> no new topics from me +09:54 < pinchartl> in that case that's it for today +09:54 < pinchartl> the next meeting is two weeks from now, on May the 2nd +09:54 < pinchartl> at the usual time +09:54 < morimoto> It is GW in Japan +09:54 < morimoto> GW = Golden Week = long holiday +09:55 < pinchartl> you will be excused then, no worries :-) +09:55 < morimoto> OK thanks +09:55 < pinchartl> if Core and I/O would prefer to move the meeting by one week I'll join them +09:55 < pinchartl> (on the 9th of May) +09:56 < pinchartl> wsa: any preference ? +09:57 < pinchartl> or should we wait for Geert to be back next week to decide ? +09:58 < pinchartl> Wolfram seems to have left already, so let's keep May the 2nd for now and adjourn this meeting +09:58 < pinchartl> thank you all for attending, and have a nice day diff --git a/wiki/Chat_log/20190509-core-chatlog b/wiki/Chat_log/20190509-core-chatlog new file mode 100644 index 0000000..418365b --- /dev/null +++ b/wiki/Chat_log/20190509-core-chatlog @@ -0,0 +1,123 @@ +09:26 < Marex> so I can probably ask now ... does anyone still care about retaining SH2/SH3 in U-Boot ? I'd like to remove those and only keep SH4/SH4A, since the SH2/SH3 were not updated for years +09:26 < wsa> thanks for the IO meeting! +09:26 < geertu> wsa: thx! +09:26 < wsa> Marex: is it in the way somehow? +09:27 < Marex> wsa: they were not converted to any of the modern frameworks and spew warnings in the build, which are unlikely to be ever fixed +09:28 < wsa> Marex: okay, i see, still using old frameworks is "in the way" +09:28 < damm> how much is a j-core board? +09:29 < Marex> damm: you can probably put it into an FPGA +09:29 < damm> ok sure, i was just hoping something turn-key existed +09:29 < Marex> damm: but I'd much rather reduce the number of boards and CPUs we support first, get the small(er) code into shape and only then add new boards +09:29 < damm> i recall they were doing sh2 +09:29 < morimoto> Marex: I talked it with Goda-san this morning. Renesas BSP is using UBoot from many years ago, but when "SH Generation +09:30 < morimoto> Oops +09:30 < damm> Marex: if you prefer to rip stuff out then that's fine with me +09:31 < Marex> damm: I do, the SH2 CPU part is small and can be re-added easily if anyone cares +09:31 < morimoto> when "SH Generation" BSP, it is of course using Uboot, but very BSP-UBoot. We tried to upstream, but not super match. Renesas user still using these old board today, but there are using BSP-U-boot, not upstream-U-boot. +09:31 < Marex> damm: the bulk of the stuff I plan to nuke are boards, which I doubt anyone tested since forever +09:32 < Marex> morimoto: well ... what shall we do ? +09:32 < morimoto> It means, "up to you" :) +09:33 < damm> morimoto: do you have a list of SH-based boards that are in-use? +09:33 < Marex> morimoto: I saw iwamatsu-san did a great job on those SH platforms, but that was years ago :( +09:33 < geertu> Marex: Have you asked Iwamatsu-san? +09:33 < morimoto> Renesas side doesn't get damage if SH2/SH3 were removed, I mean +09:33 < shimoda> http://oss.renesas.com/ ? +09:33 < Marex> it seems debian is still using some SH4 boards +09:33 < geertu> He may have a more educated opinion +09:33 < shimoda> it seems sh4 base only +09:34 < Marex> shimoda: ah, so if we keep SH4, it should be OK ? +09:34 < kbingham> damm, I have a numato which runs the SH2 (J2) +09:35 < Marex> kbingham: great, would you like to upstream it ? :) +09:35 < geertu> J2 is DT based, so all modern? +09:35 < Marex> geertu: mimas v2 is, which is J2 +09:36 < Marex> geertu: the only DT-based SH board I think +09:36 < shimoda> Marex: i think so +09:36 < geertu> http://oss.renesas.com/Documentations/Kernel_TODO_List.pdf +09:36 < kbingham> I believe there is kernel support upstream for J2, Rich Felker upstreamed it I think ... +09:36 < Marex> shimoda: OK, let's do that +09:37 < damm> kbingham: can you use JTAG on that somehow? +09:37 < Marex> shimoda: and since I can start code on the SH4A core in R-Car Gen2 , I might add some of those boards as SH4A targets too, which in turn would help us retain SH4A in for a bit longer +09:39 < geertu> Let's start the Core meeting after the first Core question ;-) +09:39 < geertu> Welcome to Today's Core Group Chat! +09:39 < geertu> Agenda: +09:39 < geertu> 1. Status Updates +09:39 < geertu> 2. Discussion Topics +09:39 < geertu> Topic 1. Status updates +09:39 < geertu> A) What have we done since last time: +09:39 < geertu> Marek worked on ATF (BSP v2.0.3 upstreaming), OpenOCD (RPC HF and SH +09:39 < geertu> QSPI), and U-Boot (GPIO, PFC, GR-Peach, SH2/SH3 removal). +09:39 < geertu> Morimoto-san fought with Renesas about our budget. +09:39 < geertu> Niklas updated copyright in rcar-dmac. +09:39 < geertu> Geert sent clock and pin control pull requests for v5.2, enjoyed +09:39 < geertu> holidays, posted IPMMU suspend/resume and PFC validation patches, wrote +09:39 < geertu> a driver for the RZ/A1 IRQC, and enabled TPU pin groups on R-Car +09:39 < geertu> H3/M3-W/M3-N. +09:39 < kbingham> damm, on the Numato board? Hrm ... not sure. I thnik the the fpga is programmed over jtag - not sure what happens after that :) +09:40 < Marex> kbingham: can you JTAG the SH2 core ? Maybe ask in #j-core ;-) +09:40 < Marex> kbingham: or at least read the backlog +09:40 < kbingham> Marex, Can the SH4a be set up with rproc framework? +09:40 < damm> kbingham: ok, thanks =) +09:40 < kbingham> (sorry - I'll let geertu continue now) +09:42 < geertu> kbingham: https://marc.info/?l=linux-sh&m=130034400711357 +09:42 < geertu> B) What we plan to do till next time: +09:42 < geertu> Marek plans to submit SH2/SH3 removal patches for U-Boot. +09:42 < geertu> Geert wants to finish on-going sh-pfc non-GPIO-pin cleanup. +09:43 < geertu> C) Problems we have currently: +09:43 < geertu> Marek wonders if anyone still cares about SH2/SH3 and SH4/SH4A boards in +09:43 < geertu> U-Boot. +09:43 < geertu> Morimoto-san was shocked by Magnus hurting his leg. +09:43 < geertu> EOT +09:43 < geertu> Anything I missed? +09:43 < Marex> kbingham: didn't we discuss that somewhere yet ? maybe it was something I discussed with damm -san . Yep, for starters, remoteproc in U-Boot would be good to bootstrap U-Boot on that SH4A core ; remoteproc in Linux, hum, maybe ; but once the U-Boot is in decent shape, I'd like to boot it natively by flipping MD7 +09:44 < Marex> geertu: I worked on ATF ? :) +09:45 < Marex> geertu: I dont see it in my current report from yesterday +09:45 < geertu> Marex: Since last meeting, i.e. 2019-04-04 +09:45 < geertu> So I combined with the 2019-04-18 report, when there was no meeting +09:46 < Marex> geertu: ah, OK +09:47 < geertu> Topic 2. Discussion Topics +09:47 < geertu> Looks like SH* removal from U-BOot has received some discussion already +09:48 < geertu> Anything to be added? +09:48 < Marex> ah +09:48 < shimoda> i have a question about coresight as I sent an email. +09:48 < Marex> morimoto: shimoda: are r-car gen2 or r-car gen3 BSDL files (for boundary scan testing) available somewhere ? +09:49 < shimoda> do you know how to use the linux coresight framework? maybe no? :) +09:49 < kbingham> Marex, haha bootloader guys "We'll boot the core in the bootloader" : Linux guys "We'll boot the core in linux" :D +09:49 < Marex> shimoda: I had a vague look into it as some point, what do you plan to do with it ? +09:50 < geertu> I haven't used the linux coresight framework yet +09:50 < Marex> geertu: i did on socfpga, it can do way too many things and is convoluted as heck +09:52 < geertu> I'm also wondering if "Chapter 85. Debug and Trace" contains sufficient information to describe everything in DT, as per Documentation/devicetree/bindings/arm/coresight.txt +09:54 < shimoda> Marex: i searched the internal sharepoint and then i found r8a7796 bsdl file. But, I don't know I can export it to you. +09:57 < Marex> shimoda: ah, all right, does it contain the MD pins on the IO chain ? :) +09:57 < Marex> shimoda: I wonder if we could somehow use BST to simulate toggling MD pins over JTAG +09:58 < geertu> Marex: The MD pins are sampled ay reset time +09:58 < Marex> shimoda: then we won't need any of those remote-setup MD-pin toggling contraptions, but only a JTAG probe +09:58 < Marex> geertu: reset time of what ? the CPU core ? +09:58 < geertu> But you mean their internal state may be accessable on the chain? +09:58 < Marex> geertu: hold the CPU in reset, do your BST setup, EXTEST, release CPU from reset +09:58 < geertu> System reset time +09:59 < geertu> Which CPU core? There are many ;-) +09:59 < wsa> shimoda: no coresight experience here, I am sorry +09:59 < Marex> geertu: the boot CPU +10:00 < Marex> geertu: some of the MD pins are sampled either by the bootrom or only be the ATF, so I dont think they are necessarily all used at _system_ reset time +10:00 < geertu> Marex: "[MODEMR] register is initialized only by PRESET#" +10:00 < Marex> geertu: the ones which are used to select boot mode are probably sampled by bootrom, so if you can flip them via JTAG, you can put the CPU into SCIF loader mode and then use that to unblock RPC access and reflash the board +10:01 < shimoda> Marex: i greped "MD" and "MODE" in the bsdl file but it doesn't seems to contain them +10:02 < geertu> shimoda: For now, I'll add CoreSight as a task to periject +10:02 < Marex> shimoda: hum :( +10:02 < damm> shimoda: i think you should grep for something else. the MD pins are shared with data or address lines, so A or D would make more sense +10:02 < Marex> shimoda: I wonder what lauterbach does in their debug probe to unlock the RPC +10:03 < Marex> shimoda: it would seem that the ADIT people somehow use the lauterbach probe to unlock RPC and reflash the ATF/U-Boot on the Gen3 boards and that it just works (TM) +10:03 < Marex> shimoda: maybe there's some sort of a trick to it +10:04 < shimoda> Marex: geertu: wsa: about coresight, thank you for the reply. just i would like to know who have some experience for it. now i will reply to BSP team that upstream team have never tried the coresight framework for now +10:05 < Marex> shimoda: I tried the CTI, on a different SoC, but not more than that +10:06 < geertu> OK +10:07 < geertu> Anything else to discuss? We've entered the MultiMedia space/time continuum +10:07 < pinchartl> geertu: next meeting date ? +10:08 < Marex> geertu: the final frontier ? +10:08 < geertu> pinchartl: wsa: In 2 weeks? Or 4 weeks? (3 weeks is public holiday in most of EU) +10:09 < pinchartl> 2 weeks seems good to me +10:09 < pinchartl> in 3 weeks I won't be available +10:10 < wsa> 2 weeks +10:10 < geertu> 2 weeks is fine for me +10:10 < geertu> All set? +10:10 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20190509-io-chatlog b/wiki/Chat_log/20190509-io-chatlog new file mode 100644 index 0000000..f3f1d38 --- /dev/null +++ b/wiki/Chat_log/20190509-io-chatlog @@ -0,0 +1,99 @@ +09:07 < wsa> okay, let's start the meeting now +09:08 < jmondi> wsa: :) +09:08 < Marex> heh +09:08 < wsa> here are the collected IO reports +09:08 < wsa> A - what have I done since last time +09:08 < wsa> ------------------------------------ +09:08 < wsa> Geert +09:08 < wsa> : tested TPU on Salvator-XS, and investigated sh_eth and SPI EEPROM regressions +09:08 < wsa> Kaneko-san +09:08 < wsa> : addressed review of thermal calculation update for Gen3 +09:08 < wsa> Niklas +09:08 < wsa> : retested SDHI PM issues using Geerts instructions and figured them out, +09:08 < wsa> worked on clarifying the cooling-states for the Gen3 thermal driver +09:08 < wsa> Shimoda-san +09:08 < wsa> : sent a patch series to improve performance by using IOMMU, measured SDHI & USB +09:08 < wsa> SSD performance to verify the CPU load, reviewed patches about USB & DMA +09:08 < wsa> Simon +09:08 < wsa> : updated patch to avoid using TX delay mode on E3/D3, sent new version of +09:08 < wsa> rcar_thermal patch to update calculation foromula, sent new versiof of patch +09:08 < wsa> to add thermal zone to support IPA on H3, tested thermal calculation update +09:08 < wsa> for Gen3 +09:08 < wsa> Ulrich +09:08 < wsa> : sent RAVB patch to implement MTU change while device is up +09:08 < wsa> Wolfram +09:08 < wsa> : reviewed first upstream backend of i2c slave interface, sent out final version +09:08 < wsa> for watchdog_init_timeout refactoring, fixed a reported bug about not-ratelimited +09:08 < wsa> error messages with suspended I2C adapters, prepared proposal for Linux Plumbers, +09:08 < wsa> took over maintainership for the i2c-gpio driver, reviewed Shimoda-san's patches +09:08 < wsa> for SDHI and IOMMU, minor patch review for Renesas Europe +09:08 < wsa> B - what I want to do until next time +09:08 < wsa> ------------------------------------- +09:08 < wsa> Kaneko-san +09:08 < wsa> : wants to continue with thermal calculation update for Gen3 +09:08 < wsa> Niklas +09:08 < wsa> : wants to finish analyses of Geerts issues with the SDHI PM patch +09:08 < wsa> Shimoda-san +09:08 < wsa> : wants to update SDHI with IOMMU patches, and continue to discuss about +09:08 < wsa> RZ/A2 USBHS support +09:08 < wsa> Simon +09:08 < wsa> : wants to address feedback for above thermal patches, and follow up on RAVB +09:08 < wsa> on E3/D3 +09:08 < wsa> Wolfram +09:08 < wsa> : wants to investigate SDR104 regression with SDIO, handle 'arbitration lost' better +09:08 < wsa> with the IIC core +09:08 < wsa> C - problems I currently have +09:08 < wsa> ----------------------------- +09:08 < wsa> Kaneko-san +09:08 < wsa> : is looking for upporting candidates +09:08 < wsa> Simon +09:08 < wsa> : doesn't know how to handle 100MBit speed limit on D3/E3 because he cannot +09:08 < wsa> test the alternative solution (PHY settings) +09:08 < wsa> Wolfram +09:08 < wsa> : has been knocked out by an illness for nearly two weeks +09:08 < wsa> fire away any comments or questions +09:09 < wsa> horms: about your upporting question for Kaneko +09:09 < wsa> unless we get a new ticket file (bsp395?), IO is all done/assigned with upporting +09:09 < wsa> I think only MM has upporting tasks left +09:10 < wsa> dunno if that is suitable for Kaneko +09:10 < wsa> I keep looking around for other non-upporting tasks, though +09:11 < wsa> geertu: I rediscovered a clock related question to you, it's about the WDT +09:11 < wsa> https://patchwork.kernel.org/patch/10900571/ +09:11 < wsa> If you have some time... +09:11 < horms> wsa: ack, thanks +09:12 < wsa> neg: can you give a quick summary what the two issues were which you found with the MMC clock imbalance thing? +09:12 < wsa> The mails confused me a little, because I read one was MMCIF which is != SDHI? +09:12 < geertu> wsa: Thanks, will reply +09:13 < wsa> geertu: thanks! +09:13 < pinchartl> horms: there are BSP patches not addressed yet for MM, we can have a look at that during the MM part of this meeting +09:14 < wsa> neg: ? +09:14 < wsa> neg: fallen asleep on the sofa again? ;) +09:15 < horms> pinchartl: thanks. unfortunately I have to leave this meeting soon. perhaps we can chat in the not too distant future +09:15 < pinchartl> sure, works for me +09:15 < wsa> horms: do you still have a few minutes to talk about the RAVB D3/E3 testing issue? +09:15 < horms> yes, i have a few minutes +09:16 < wsa> so, we got some magic values from the BSP team for the PHY which could add this "delay mode" +09:16 < wsa> but we don't have a way to test that? +09:16 < horms> yes, that is correct +09:16 < horms> I can try the values and see if ethernet works +09:17 < horms> But I don't have a test case for the unreliable gigabit communication problem we are trying to solve +09:17 < wsa> is it possible to verify that the PHY actually uses the "delay mode"? +09:17 < horms> So I can probably say "it doesn't seem to make things worse" +09:17 < horms> But I can't say "it addresses the issue rasied by the BSP team" +09:18 < geertu> If you have a fast scope (unikely), you might notice the impact of configuring delay mode on the PHY.. +09:18 < horms> geertu: i do not +09:18 < horms> wsa: maybe, I can look into that +09:20 < wsa> At least, that would be okay with me. If the SoC has broken "delay mode" but the PHY has a working one, and we can prove that it is active, I'd think this is what we can do for now without super-fancy test hardware +09:20 < horms> Undersood. Let me a) think about if I agree and b) do some testing and see what data I can collect +09:21 < horms> In general I think we should try to move ourselves into a better position to decide +09:21 < horms> I'll see about making that so +09:21 < horms> Thanks for your advice +09:21 < wsa> Thanks, Simon! +09:22 < wsa> So, neg is still not here, which means I ran out of questions +09:22 < horms> I'll drop off now, sorry that I can't stay for the entire meeting +09:22 < wsa> have a nice day! +09:22 -!- horms [~horms@ip4dab7138.direct-adsl.nl] has quit Quit: Leaving +09:22 < wsa> are there more questions from your side? +09:24 < wsa> well then +09:24 < wsa> geertu: do you want to start now or at 09:30? +09:25 < geertu> wsa: I prefer at 09:30, for the least amount of surprise diff --git a/wiki/Chat_log/20190509-mm-chatlog b/wiki/Chat_log/20190509-mm-chatlog new file mode 100644 index 0000000..addf4d4 --- /dev/null +++ b/wiki/Chat_log/20190509-mm-chatlog @@ -0,0 +1,114 @@ +Multimedia-chat-meeting-2019-05-09 + +10:10 < pinchartl> welcome to the multimedia meeting +10:10 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:10 < pinchartl> * Jacopo +10:10 < pinchartl> Since last meeting: +10:10 < pinchartl> - CMM plumbing +10:10 < pinchartl> [RFC 0/9] drm: rcar-du: Add CMM support to M3-W (plumbing only) +10:10 < pinchartl> CMM support patches have been sent by Bosh in a form not consumable by +10:10 < pinchartl> upstream. Provide plumbing to integrate DU and CMM. RFC as the actual +10:10 < pinchartl> CMM driver does nothing ATM. +10:10 < pinchartl> - More and more discussion on v4l2-mux: v5 is ready but not sent yet +10:10 < pinchartl> - Investigated RZ/A JCU unit +10:10 < pinchartl> - Investigated RZ/A video decoder support +10:10 < pinchartl> - Patch review on linux-media +10:10 < pinchartl> Until next meeting: +10:10 < pinchartl> - One week holiday +10:10 < pinchartl> - More CMM work if any feedback is received +10:10 < pinchartl> - Would like to test V4l2-mux with a GMSL setup +10:10 < pinchartl> Issues and blockers: None +10:10 < pinchartl> jmondi: any comment? +10:11 < jmondi> not really +10:11 < pinchartl> thank you +10:11 < pinchartl> * Kieran +10:11 < pinchartl> Since last meeting: +10:11 < pinchartl> - PA-Phase review and update +10:11 < pinchartl> - DU Group refactor debugging +10:11 < pinchartl> Until next meeting: +10:11 < pinchartl> - Post a new (final?) PA-Phase series +10:11 < pinchartl> - Fix DU Group refactor series +10:11 < pinchartl> Issues and blockers: None +10:11 < pinchartl> kbingham: any comment ? +10:12 < kbingham> I see we have an update from morimoto-san about the pa-phase UDS calculation. +10:12 < kbingham> Which is helpful thankyou morimoto :) +10:12 < kbingham> But doesn't particularly give us a clear answer. +10:13 < kbingham> Otherwise status update is fine. +10:13 < pinchartl> let's continue that discusion over e-mail then +10:13 < pinchartl> thank you +10:13 < pinchartl> * Laurent +10:13 < pinchartl> Since last meeting: +10:13 < pinchartl> - Prepared the LVDS dual-link prototype for merge +10:13 < pinchartl> - Manage CMM driver work with Jacopo +10:13 < pinchartl> - Patch review +10:13 < pinchartl> Until next meeting: +10:13 < pinchartl> - Get the LVDS dual-link prototype merged +10:13 < pinchartl> - Merge the VSP partition algorithm improvements +10:13 < pinchartl> Issues and blockers: None +10:13 < pinchartl> any question ? +10:14 < pinchartl> * Morimoto-san +10:14 < pinchartl> Since last meeting: +10:14 < pinchartl> - ALSA SoC framework cleanups +10:14 < pinchartl> The ALSA SoC framework grew organically. Its numerous features are not +10:14 < pinchartl> always cleanly connect, with the underlying code not very readable, and +10:14 < pinchartl> wastefully complicated. For this reason one of the R-Car sound feature +10:14 < pinchartl> can only be half-supported. ALSA SoC cleanups are need to fix that and +10:14 < pinchartl> move to 100% support. Discussions are ongoing with the ALSA soC +10:14 < pinchartl> maintainer on how to fix this. +10:14 < pinchartl> Until next meeting: +10:14 < pinchartl> - Continue with ALSA SoC work +10:14 < pinchartl> Issues and Blockers: None +10:14 < pinchartl> morimoto: any comment ? +10:16 < morimoto> no. thanks +10:16 < pinchartl> thank you +10:16 < pinchartl> * Niklas +10:16 < pinchartl> Since last meeting: +10:16 < pinchartl> - Started work on cleaning up VIN format handling +10:16 < pinchartl> - Prepared VIN fops v2 +10:16 < pinchartl> Until next meeting: +10:16 < pinchartl> - Keep cleaning up the VIN crop and compose code +10:16 < pinchartl> This is needed to merge UDS and PM support. +10:16 < pinchartl> Issues and blockers: None +10:16 < pinchartl> neg: any comment ? +10:18 < pinchartl> ah Niklas is attending a conference today +10:18 < pinchartl> * Simon +10:18 < pinchartl> Since last meeting: +10:18 < pinchartl> - Applied "[PATCH] arm64: dts: renesas: draak: Remove unecessary index +10:18 < pinchartl> from vin4 port" +10:18 < pinchartl> Until next meeting: None +10:18 < pinchartl> Issues and Blockers: +10:18 < pinchartl> - Kaneko-san is looking for up-porting candidates +10:18 < pinchartl> and Simon has left already +10:18 < pinchartl> * Ulrich +10:18 < pinchartl> Since last meeting: None +10:18 < pinchartl> Until next meeting: None +10:18 < pinchartl> Issues and Blockers: None +10:18 < pinchartl> uli___: correct? +10:18 < pinchartl> if so I assume there's no special comment :) +10:20 < pinchartl> any discussion point for today ? +10:21 < kbingham> only UDS overlap for me - but that might be suited to email. +10:22 < pinchartl> we have some time now +10:22 < pinchartl> any particular point you'd like to discuss ? +10:23 < kbingham> morimoto, Was it confirmed that the calculation in procedure 1-7 does not calculate any extra overlap? (I.e. my assumption is that it *just* converts a position) +10:23 < kbingham> In otherwords, that this 'undocumented' margin must be added. +10:25 < kbingham> pinchartl, does a 2 pixel overlap sound right for the UDS requiremnts? +10:25 < kbingham> It sounds small to me - considering the SHP has a much larger set of taps... +10:25 < pinchartl> two pixels in total, including both the margin and the 1-7 procedure ? +10:27 < pinchartl> that's a 5 taps filter +10:27 < pinchartl> possibly a bit small, but not uncommon +10:27 < pinchartl> I think +10:27 < kbingham> today's mail from the HW engineer (via morimoto) states: "When I created the code, there was no guide/information, I used (unofficial) attached file's formula. It calculates to be overlap will be over 2pixel" +10:28 < pinchartl> doesn't the overlap depend on the scaling factor in your code ? +10:28 < kbingham> Yes. +10:30 < pinchartl> let's wait and see if we receive more information by e-mail +10:30 < pinchartl> I think you should also use a horizontal gradient and see if it scales correctly +10:30 < pinchartl> instead of the existing test image +10:30 < kbingham> yes, we discussed this before. I'll update the test image +10:31 < kbingham> Ok - well that's me for now I think +10:31 < pinchartl> I think that's it for today +10:31 < pinchartl> I propose adjourning this meeting +10:31 < pinchartl> does anyone second ? +10:32 < kbingham> oh go on then +10:32 < jmondi> fine with me +10:32 < pinchartl> meeting adjourned +10:33 < pinchartl> thank you all for attending diff --git a/wiki/Chat_log/20190523-core-chatlog b/wiki/Chat_log/20190523-core-chatlog new file mode 100644 index 0000000..b7b5ef1 --- /dev/null +++ b/wiki/Chat_log/20190523-core-chatlog @@ -0,0 +1,73 @@ +09:32 < geertu> Welcome to today's Core Group Chat! +09:32 < geertu> Agenda: +09:32 < geertu> 1. Status Updates +09:32 < geertu> 2. Discussion Topics +09:32 < geertu> Topic 1. Status updates +09:32 < geertu> A) What have we done since last time: +09:32 < geertu> Marek worked on U-Boot (SH2/SH3 and some SH4 removal), R-Car Gen3 PCIe, +09:32 < geertu> SDHI HS400 upporting, DRAM size/layout handling), ATF (M3-W QoS +09:32 < geertu> upporting and R-Car Gen3 multi-console API conversion), and OpenOCD (SH +09:32 < geertu> QSPI). +09:32 < geertu> Niklas tested PFC patches. +09:32 < geertu> Shimoda-san supported Marek with automated reflashing, and reviewed +09:32 < geertu> IPMMU suspend/resume patches. +09:32 < geertu> Simon reposted R-Car Gen3 CMT bindings updates and unused sudmac +09:32 < geertu> removal. +09:32 < geertu> Geert posted PFC rework for pins without GPIO function, investigatd and +09:32 < geertu> reported merge window regressions, and updated peri* for v5.2-rc1. +09:33 < geertu> B) What we plan to do till next time: +09:33 < geertu> Marek is considering adding remoteproc support to U-Boot for starting +09:33 < geertu> the SH core on R-Car Gen2. +09:33 < geertu> Shimoda-san plans to continue support Marek with automated reflashing. +09:34 < geertu> C) Problems we have currently: +09:34 < geertu> Morimoto-san sees too many warning when compiling v5.2-rc1 with gcc +09:34 < geertu> 8.1.0. +09:34 < geertu> eot +09:34 < geertu> Anything I missed? +09:35 < geertu> Topic 2. Discussion Topics +09:35 < morimoto> kbingham: I'm afraid I'm using Japanese-English +09:35 < kbingham> morimoto, That's better than american-english +09:35 < morimoto> :) +09:35 < Marex> morimoto: -いぜ or -いせ ? :) +09:35 < geertu> Looks like things were a bit quiter than usual, probably due to the merge window +09:37 < geertu> Anything to discuss? +09:37 < morimoto> Marex: about SH2/SH3, can you show me the posted mail some how ? +09:37 < morimoto> URL is better +09:38 < Marex> morimoto: one moment +09:38 < morimoto> thx +09:39 < Marex> morimoto: http://patchwork.ozlabs.org/patch/1098321/ and related 12 patches +09:39 < Marex> morimoto: I also sent http://patchwork.ozlabs.org/patch/1101769/ and related 6 patches , but didn't apply it yet +09:40 < morimoto> thanks a lot !! +09:40 < Marex> morimoto: you're welcome +09:41 < Marex> morimoto: is there any board you want me to bring back ? +09:42 < morimoto> nothing, thanks +09:42 < shimoda> Marex: oh, I didn't realized the patches because my email address is inccorect :) s/shimoda.yoshihiro.uh/yoshihiro.shimoda.uh/ +09:42 < geertu> Marex: migo-r, rts7751r2, ecovec24?? +09:43 < morimoto> migo-r, ecovec24 are SH4, if my mermory was correct +09:43 < Marex> shimoda: I pulled that address from the sources, seems someone wrote it the japanese way and swapped name/surname +09:43 < Marex> shimoda: thank you for the heads up, I'll double-check next time I CC you +09:44 < geertu> morimoto: right, you were askign about sh2/sh3. sorry +09:44 < morimoto> geertu: no problem +09:44 < Marex> I am keeping some SH4s around and planning to eventually use R-Car Gen2 SHX4 core to keep the SH support in U-Boot +09:45 < shimoda> geertu: by the way, about the warning from Morimoto-san, what do you think? my suggestion seems to fix the warning +09:46 < geertu> shimoda: I expect Arnd to have sent a fix for that already +09:47 < geertu> (but I haven't checked) +09:47 < morimoto> geertu: thanks ! nice to know +09:47 < morimoto> geertu: Do you know the patch title ? +09:48 < geertu> morimoto: No, I only assume he has posted a patch +09:48 < morimoto> OK, thanks +09:49 < geertu> as he typically fixes all such warnings in arm code +09:50 < shimoda> geertu: i see. but, i don't find such a patch. so, should i send such a patch with RFC? +09:52 < geertu> shimoda: Yes, please do so. It looks like a genuine bug +09:52 < geertu> no one ever noticed before +09:52 < shimoda> geertu: i got it. thanks! +09:52 < geertu> Fixes: 34b8ab091f9ef57a ("bpf, arm64: use more scalable stadd over ldxr / stxr loop in xadd") +09:53 < shimoda> geertu: thanks for suggested the Fixes tag! +09:55 < geertu> Anything else to discuss? +09:55 < geertu> Next meeting on Thursday, June 6? +09:56 < geertu> wsa: pinchartl ^ +09:56 < wsa> ack +09:56 < pinchartl> geertu: works for me +09:57 < morimoto> geertu: OK for me +09:58 < geertu> OK +09:58 < geertu> So thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20190523-io-chatlog b/wiki/Chat_log/20190523-io-chatlog new file mode 100644 index 0000000..77f60b7 --- /dev/null +++ b/wiki/Chat_log/20190523-io-chatlog @@ -0,0 +1,159 @@ +09:02 < wsa> let's start with the IO meeting then +09:02 < jmondi> Hello, good morning +09:02 < wsa> usual status updates +09:02 < wsa> A - what have I done since last time +09:02 < wsa> ------------------------------------ +09:02 < wsa> Kaneko-san +09:02 < wsa> : posted v3 of update calculation formula for Gen3 Thermal +09:02 < wsa> Niklas +09:02 < wsa> : investigated Geert's comments on SDHI PM issue and came to an agreement +09:02 < wsa> Shimoda-san +09:02 < wsa> : sent patches for USB and SDHI with IOMMU support, reviewed a lot of USB +09:02 < wsa> patches as well as SDHI and SCIF patches +09:02 < wsa> Simon +09:02 < wsa> : posted v3 of H3 IPA support and dynamic power coefficient patches, tested +09:02 < wsa> v3 of update calculation formula for Gen3 Thermal +09:02 < wsa> Ulrich +09:02 < wsa> : sent RAVB patch to implement MTU change while device is up and investigated +09:02 < wsa> review comments +09:02 < wsa> Wolfram +09:02 < wsa> : sent and merged better API for i2c_new_device and i2c_new_dummy, sent a +09:02 < wsa> watchdog cleanup series, resent DA9063 cleanup patches after rc1, tried to +09:02 < wsa> reproduce an OOPS, upported patch avoiding SDHI CRC error, reviewed SDHI and +09:02 < wsa> SCIF and I2C slave support patches, submitted talk proposal for plumbers +09:02 < wsa> B - what I want to do until next time +09:02 < wsa> ------------------------------------- +09:02 < wsa> Kaneko-san +09:02 < wsa> : wants to keep at update calculation formula for Gen3 Thermal +09:02 < wsa> Shimoda-san +09:02 < wsa> : wants to continue discussions about SDHI with IOMMU support, Gen2 ethernet +09:02 < wsa> driver, SCIF with DMAC issue, send patches for USB, remove some meanwhile +09:02 < wsa> obsolete USB stuff and revise USB2 phy nodes for Gen3 +09:02 < wsa> Simon +09:02 < wsa> : wants to send v4 of H3 IPA support and dynamic power coefficient patches, +09:02 < wsa> and follow up on RAVB on E3/D3 Errata +09:02 < wsa> Ulrich +09:02 < wsa> : wants to send v2 of RAVB patch to implement MTU change while device is up +09:02 < wsa> Wolfram +09:02 < wsa> : wants to upport new SDHI HS400 patch, start converting i2c_new_* users, +09:02 < wsa> handle 'arbitration lost' better with the IIC core, investigate SDR104 +09:02 < wsa> regression with SDIO +09:02 < wsa> C - problems I currently have +09:02 < wsa> ----------------------------- +09:02 < wsa> Niklas +09:02 < wsa> : needs review tags for his SDHI PM patch +09:02 < wsa> Wolfram +09:02 < wsa> : had no success in reproducing the OOPS so far +09:02 < wsa> let me know if it needs updates +09:03 < wsa> neg, geertu: can you give me a short summary of your agreement? Were the things Geert was seeing another issue? +09:04 < wsa> kbingham: you there already? +09:05 < neg> wsa: In short, geertu noticed more clock imbalances which turned out to be caused by other drivers (and non sdhi related clocks) +09:05 < geertu> wsa: my suspend script changed pm_qos_resume_latency_us, which caused some issues +09:05 < geertu> Changing pm_qos_resume_latency_us used to be needed, but apparently it now works without +09:05 < geertu> hence the issues caused by it are gon +09:05 < geertu> s/gon/gone/ +09:06 < geertu> So while SDHI is fine, there's another issue in MMCIF +09:06 < wsa> neg: maybe it is a good idea to resend the patch then, and geert gives a tag for that resend +09:06 < wsa> should make it more visible to Ulf +09:07 < neg> geertu: thanks again for your effort working with this patch +09:07 < wsa> geertu: only with APE6 or with Gen2 as well? +09:07 < neg> wsa: OK, sounds good I will resend the patch +09:07 < geertu> wsa: Only on older SH/R-Mobile +09:08 < wsa> Does it look complicated? +09:08 < geertu> MMC is always complicated ;-) +09:08 < wsa> :D +09:09 < neg> +1 ;-) +09:10 < neg> Clocks that show imbalance are mmcif and sys-dmac +09:10 < wsa> Well, if it is kinda simple, I'd like to ask neg to handle it somewhen in his base time. If it is complicated, then I think it is not worth it for that old platform. +09:10 < neg> I only looked into mmcif, and I'm not sure it's a issue and might even be expected behavior +09:11 < neg> Did not dig into sys-dmac after confirmed it was not related to the SDHI driver +09:12 < wsa> I think Geert should have an opinion if that is expected behaviour? ;) +09:12 < neg> I added it to my list of tasks to potentially work on as it's old boards. The SDHI fix seemed to be more important as it also effects Gen3 +09:12 < wsa> But I let you decide if it is worth the effort... +09:12 < wsa> I'm all happy that the SDHI patch works as is :) +09:13 < wsa> Thanks for working on that (with all the APE6 trouble), Niklas and Geert. +09:13 < wsa> ok +09:14 < geertu> the sys-dmac imbalance is on gen3 +09:14 < wsa> kbingham seems not here yet, I wanted to ask him about potential preferences for i2c_new_* conversion +09:14 < wsa> will do that later today +09:14 < wsa> any questions / comments from your side? +09:15 < Marex> yep +09:15 < geertu> I'll have a deeper look at the sys-dmac issue +09:15 < Marex> I just learnt this https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.14.75-ltsi/rcar-3.9.5.rc2&id=a0d396ede95a55a4dff6aa15ea314a3d35e2e842 patch might be limited to M3W only +09:15 < Marex> just FYI +09:16 < wsa> argh +09:16 < wsa> all of M3-W? +09:16 < horms> ouch! +09:16 < Marex> wsa: I mean, I hope I wasnt off topic and that was a general question/comment call +09:16 < wsa> "might" means we still need confirmation from the HW team? +09:17 < wsa> definately on topic +09:17 < Marex> wsa: I submitted similar patch to U-Boot, but Goda-san told me REL is working on confirming it on other SoCs and that it's confirmed on M3W only for now +09:17 < wsa> good to know +09:17 < Marex> wsa: that is all I know +09:17 < kbingham> wsa, Hola +09:17 < kbingham> Sorry - just saw your message :) +09:17 < Marex> wsa: I said I'll wait for further information +09:17 < kbingham> Oh - it wasn't even that long ago :) +09:18 < Marex> wsa: will keep you updated +09:18 < wsa> I'll postpone my todo-item for that patch, then +09:18 < wsa> Marex: thanks for the heads up! +09:18 < wsa> hi kbingham! +09:18 < kbingham> wsa, Heya! +09:18 < kbingham> Seems I forgot today was meeting day :) +09:18 < wsa> kbingham: dunno if you saw it but i2c_new_dummy and _device now return errnos +09:18 < Marex> wsa: feels like E3 might also be affected +09:18 < wsa> you once requested that ont he I2c list, too +09:18 < kbingham> wsa, I reviewed the patches didn't I :) +09:18 < Marex> wsa: but that's just my guess +09:18 < wsa> right +09:19 < wsa> Marex: ok, will wait for official confirmation from Renesas +09:19 < shimoda> Marek: all Gen3 SoCs has the HS400 correction issue. but we can look the issue on M3-W easily +09:19 < shimoda> for some reason +09:20 < wsa> kbingham: in that old mail, you said you were also interested in i2c_new_secondary_device() returning errno. Is that still needed? +09:20 < shimoda> anyway, the correction feature is corrupt on the SoCs, BSP team made a kernel patch that Marek-san shows +09:20 < kbingham> wsa, Hrm... new me doesn't remember what long ago me said - I'll go see. +09:21 < wsa> kbingham: the thread was "i2c_new_{secondary_device,dummy,device}() return type." +09:21 < Marex> shimoda: sooooo, how shall we proceed ? :) +09:21 < wsa> shimoda: what would be your suggestion then? Should I upport that patch for Linux or wait until we have more information? +09:22 < Marex> wsa: +1 +09:23 < kbingham> wsa, Aha, wow - old thread :) I do indeed make a lot of use of i2c_new_secondary_device() so Yes, i would also like to see that be converted. +09:23 < shimoda> Marex: wsa: sorry for lack conclution. we should upport the patch for Linux. +09:23 < kbingham> I think the number of users of i2c_new_secondary_device() are probably low enough that it could be converted directly ? +09:23 < wsa> kbingham: yes +09:23 < kbingham> (now that we have the return types on the other apis +09:23 < kbingham> ) +09:23 < kbingham> Is that something you would like me to tackle ? +09:24 < kbingham> Seems you have now done the blocking work that was necessary from my original request. +09:24 < wsa> kbingham: there a lot of ways to start, so I wanted to ask you which would be most benefitial to you :) +09:24 < wsa> kbingham: I'll do it +09:24 < Marex> shimoda: is that OK with Goda-san too ? +09:24 < wsa> shimoda: thanks for the conclusion +09:25 < wsa> shimoda: I will work on upporting the patch, then. It needs a bit of preparational refactoring first, anyhow +09:25 < kbingham> wsa, My usage is in "drivers/media/i2c/adv748x/adv748x-core.c:186"" +09:25 < shimoda> Marex: let me talk with goda-san now. please wait for a while +09:26 < kbingham> And it seems there are only 5 users of the call ... so it should be an easy conversion. +09:26 < wsa> yup +09:26 < Marex> shimoda: thank you :) +09:26 < wsa> "adv748x_initialise_clients" +09:27 < wsa> ? +09:27 < wsa> is that OK in English? +09:27 < kbingham> "Initialise the client" with an adv748x prefix ? +09:28 < Marex> kbingham: s/s/z/ probably ? +09:28 < wsa> i thought it must be "initialize" +09:28 < pinchartl> wsa: British English vs. American English :-) +09:29 < kbingham> https://simple.wikipedia.org/wiki/British_English +09:29 < geertu> wsa: That's US English, isn't it? +09:29 < kbingham> Some words in British English use "-ise" where "-ize" is used in American English. Spelling them with "-ize" is also done in Britain sometimes. However, this is very much frowned upon and would not be considered acceptable if writing for a British audience. +09:29 < kbingham> :) +09:29 < wsa> Good, so I learned something today +09:29 < pinchartl> kbingham: I'm afraid that function names in the kernel use american english... +09:29 < kbingham> (I had that page up already while writing a review to Neg :D heheh) +09:29 < Marex> kbingham: but kernel is written in simplified English, so -ize ? +09:29 * geertu realizes Trump wants a Brekzit +09:30 < geertu> simplified -> "init" +09:30 < pinchartl> you could make everybody happy with adv748x_init_clients() +09:30 < shimoda> Marex: wsa: I'm sorry. my understanding is wrong. As goda-san said, we should wait for hw team conclusion because hw team still investigate this root cause. So, our upstream team also should wait. +09:30 < wsa> shimoda: fine, too. will do +09:30 < Marex> shimoda: will do, thank you for checking :-) +09:31 < shimoda> Marex: wsa: thanks! +09:31 < wsa> ok, I think we are done with IO diff --git a/wiki/Chat_log/20190523-mm-chatlog b/wiki/Chat_log/20190523-mm-chatlog new file mode 100644 index 0000000..fe3ef9f --- /dev/null +++ b/wiki/Chat_log/20190523-mm-chatlog @@ -0,0 +1,119 @@ +Multimedia-chat-meeting-2019-05-23 + +10:02 < pinchartl> welcome to the multimedia meeting +10:02 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:02 < pinchartl> let's go in reverse order today +10:03 < pinchartl> * Ulrich +10:03 < pinchartl> Since last meeting: +10:03 < pinchartl> - Patch review +10:03 < pinchartl> Until next meeting: None +10:03 < pinchartl> Issues and Blockers: None +10:03 < pinchartl> uli_: any comment ? +10:04 < pinchartl> uli_ didn't seem prepared to go first, let's wait until he wakes up :-) +10:04 < pinchartl> * Simon +10:04 < pinchartl> Since last meeting: +10:04 < pinchartl> - Updated the BSP ticket file +10:04 < pinchartl> Until next meeting: +10:04 < pinchartl> - Upport of DT patches from the BSP (Kaneko-san) +10:04 < pinchartl> Issues and Blockers: None +10:04 < pinchartl> horms: any comment ? +10:05 < horms> pinchartl: not much. I've made some requests to Kaneko-san and am awaiting a response. From there I expect a) patches to appear and b) be able to update the ticket file. No problems so far. Thanks for your help! +10:06 < pinchartl> horms: you're welcome +10:06 < morimoto> jmondi: I'm detective !! +10:06 < pinchartl> I have a question though +10:06 < pinchartl> when we discussed the upporting list +10:07 < pinchartl> there was a larger set of patches +10:07 < pinchartl> do you plan to address all the ones we discussed, or only a subset ? +10:07 < pinchartl> in the latter case I would like to know which ones you plan to address, in order to work on the rest +10:08 < horms> my intention is to address all the patches we discussed. if I only listed a subset then that is most likely an oversight on my part. I'll double check my list(s) +10:09 < pinchartl> I mean that in your e-mail status update there's only three patches listed. I understand that's due to phasing the work, I was just wondering if there was a plan for the rest +10:09 < pinchartl> and now I know there is, thanks +10:09 < pinchartl> * Niklas +10:09 < pinchartl> Since last meeting: +10:09 < pinchartl> - [PATCH] rcar-csi2: Fix coccinelle warning for PTR_ERR_OR_ZERO() +10:09 < pinchartl> - [PATCH] dt-bindings: rcar-{csi2,vin}: Rename bindings documentation files +10:09 < pinchartl> - [PATCH 0/3] rcar-vin: Add support for RGB formats with alpha component +10:09 < pinchartl> - [PATCH v2 0/8] rcar-vin: Merge Gen2 and Gen3 file operations +10:09 < pinchartl> Until next meeting: +10:09 < pinchartl> - Keep cleaning up the VIN crop and compose code +10:09 < pinchartl> This is needed to merge UDS and PM support. +10:09 < pinchartl> - Vacation (May 28th - 31st) +10:09 < pinchartl> Issues and blockers: None +10:09 < pinchartl> neg: any comment ? +10:09 < neg> No comment, thanks +10:10 < pinchartl> thank you +10:10 < pinchartl> * Morimoto-san +10:10 < pinchartl> Since last meeting: +10:10 < pinchartl> - ALSA SoC framework cleanups +10:10 < pinchartl> Ongoing, the code is in a bad shape, it will take time. +10:10 < pinchartl> - ALSA SoC modern device support +10:10 < pinchartl> Until next meeting: +10:10 < pinchartl> - Continue with ALSA SoC work +10:10 < pinchartl> Issues and Blockers: None +10:10 < pinchartl> morimoto: any comment ? +10:11 < morimoto> nothing, thanks +10:11 < pinchartl> thank you +10:11 < pinchartl> * Laurent +10:11 < pinchartl> Since last meeting: +10:11 < pinchartl> - Debugged DU group refactoring with Kieran +10:11 < pinchartl> - Request API brainstorming +10:11 < pinchartl> - Patch review +10:11 < pinchartl> Until next meeting: +10:11 < pinchartl> - Get the LVDS dual-link prototype merged +10:11 < pinchartl> - Holidays (26th - 31st) +10:11 < pinchartl> Issues and blockers: +10:11 < pinchartl> - No review for the LVDS dual-link series +10:11 < pinchartl> any question ? +10:12 < kbingham> I forgot to add +10:12 < kbingham> Fix a rcar-du writeback compile warning, and add support for M3N and E3 to fdp1 +10:12 < pinchartl> kbingham: it's not your turn yet :-) +10:13 < pinchartl> I would be really glad if someone could review the still unreviewed LVDS dual-link patches +10:13 < pinchartl> they have been sitting idle on the list for a long time, and I would like to send a pull request tomorrow +10:14 < kbingham> :D oops +10:14 < kbingham> Sorry I saw my name +10:14 < kbingham> being too reactive. +10:14 < jmondi> pinchartl: I planned to have a look at that series, as soon as I can find some review time +10:14 < pinchartl> jmondi: thank you +10:15 < pinchartl> * Kieran +10:15 < pinchartl> Since last meeting: +10:15 < pinchartl> - Repost and debugging of the PA phase series +10:15 < pinchartl> There's still an off-by-one error hiding somewhere. Need to figure out if the +10:15 < pinchartl> documented procedure is incorrect, or just the code. +10:15 < pinchartl> - DU group refactoring fixes +10:15 < pinchartl> The VSP wasn't properly handled, work is ongoing. +10:15 < pinchartl> - Fixed a rcar-du writeback compile warning +10:15 < pinchartl> - Add support for M3N and E3 to the fdp1 driver +10:15 < pinchartl> - VSP1 datasheet documentation updates +10:15 < pinchartl> Until next meeting: +10:15 < pinchartl> - Post a new (final?) PA-Phase series +10:15 < pinchartl> - Fix DU group refactoring series +10:15 < pinchartl> - Review the LVDS dual-link mode series +10:15 < pinchartl> Issues and blockers: None +10:15 < pinchartl> kbingham: any comment ? +10:15 < pinchartl> (I may have added an item to the B section ;-)) +10:16 < pinchartl> * Jacopo +10:16 < pinchartl> Since last meeting: +10:16 < pinchartl> - Vacation +10:16 < pinchartl> Until next meeting: +10:16 < pinchartl> - Send v5 of the V4L2 multiplex streams series +10:16 < pinchartl> Clarify a few points with Sakari first, and rebase GMSL on top if necessary +10:16 < pinchartl> (thanks to remote access to GMSL hardware in Kieran's lab). +10:16 < pinchartl> - Send v2 of the CMM series +10:16 < pinchartl> Issues and blockers: None +10:17 < pinchartl> jmondi: any comment ? +10:17 < jmondi> not really +10:17 < jmondi> not much there +10:17 < jmondi> except that I will need to get an handle of you to procede with CMM +10:17 < jmondi> but we can sync offline +10:18 < pinchartl> I think I stated in an e-mail that I would like to see support for gamma tables implemented. do you think you could do that ? +10:19 < jmondi> gamma table, with some value I cannot tell how should be calculated is fine +10:19 < jmondi> I was more interested in knowing about the properties interface and how to expose the parameters of the CMM +10:19 < pinchartl> let's discuss that after this meeting +10:20 < pinchartl> any comment, question, or discussion topic ? +10:21 < kbingham> (countering early response with late one, "that's fine") +10:21 < neg> not from me, thanks +10:21 < jmondi> I've cc-ed you neg and kbingham on the v4l2-mux discussion with sakari, if you're willing to read and discuss it, I would be glad +10:21 < pinchartl> jmondi: ok, I will +10:22 < pinchartl> if there's no other topic I propose adjourning this meeting. does anyone second ? +10:22 < jmondi> seconded, thanks! +10:22 < pinchartl> thank you all for attending, and have a nice day diff --git a/wiki/Chat_log/20190606-core-chatlog b/wiki/Chat_log/20190606-core-chatlog new file mode 100644 index 0000000..8bb969e --- /dev/null +++ b/wiki/Chat_log/20190606-core-chatlog @@ -0,0 +1,32 @@ +09:57 < geertu> Welcome to today's Core Group Chat! +09:57 < geertu> Agenda: +09:57 < geertu> 1. Status Updates +09:57 < geertu> 2. Discussion Topics +09:57 < geertu> Topic 1. Status updates +09:57 < geertu> A) What have we done since last time: +09:57 < geertu> Marek worked on Linux (Gen3 PCIe lockdep splat on root complex removal) +09:57 < geertu> and U-Boot (ULCB CPLD control and boot partition handling with HS400 +09:57 < geertu> mode enabled). +09:57 < geertu> Shimoda-san submitted an RFC patch about arm64 insn.h. +09:57 < geertu> Geert resubmitted IPMMU suspend/resume and RZ/A1 IRQC support, received +09:57 < geertu> an RZA2MEVB board, and looked into SYS-DMAC clock imbalances/ +09:58 < geertu> B) What we plan to do till next time: +09:58 < geertu> Shimoda-san will ping the Renesas guys about BSDL files. +09:58 < geertu> Geert plans to send clk-renesas and sh-pfc pull requests for v5.3, +09:58 < geertu> modernize Renesas clock drivers, and enable SDRAM on RZA2MEVB. +09:59 < geertu> C) Problems we have currently: +09:59 < geertu> Marek wonders if we can release ULCB CPLD control tools and information. +09:59 < geertu> Moriomoto-san cannot sync datasheet updates to Magnus' server. +09:59 < geertu> Simon reports that the reposted CMT binding updates seem stuck. +09:59 < geertu> EOT +09:59 < geertu> Anything I missed? +09:59 < geertu> I believe Morimoto-san's issue has been fixed in the mean time +09:59 < geertu> (Magnus' docs server access, not lack of Swedish ;-) +10:01 < geertu> Topic 2. Discussion Topics +10:01 < morimoto> geertu: no more error from his server, but nothing happen ... +10:01 < geertu> Anything else to discuss? +10:02 < geertu> Any special requests from Tokyo? +10:02 < morimoto> geertu: oops, error... +10:02 < morimoto> geertu: no topic from our side, thanks +10:04 < geertu> In that case, I think we can move on to MM? +10:04 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20190606-io-chatlog b/wiki/Chat_log/20190606-io-chatlog new file mode 100644 index 0000000..06a1875 --- /dev/null +++ b/wiki/Chat_log/20190606-io-chatlog @@ -0,0 +1,173 @@ +09:05 < wsa> So, let's start the IO meeting +09:05 < morimoto> she can't talk anyway :) +09:05 < neg> Swedish is easy, don't know what you are talking about +09:05 < morimoto> geertu: thanks +09:05 < wsa> as always, the collected reports, let me know if that needs fixing: +09:05 < wsa> A - what have I done since last time +09:05 < wsa> ------------------------------------ +09:05 < wsa> Geert +09:05 < wsa> : reduced delays in the MSIOF driver and looked into USB regression causing +09:05 < wsa> WARNING during second system suspend +09:05 < wsa> Marek +09:05 < wsa> : worked on and sent patch for Gen3 PCIe lockdep issue on root complex removal +09:05 < wsa> Niklas +09:05 < wsa> : got issues with "SDHI runtime PM enablement" resolved and patch was applied, +09:05 < wsa> assisted Wolfram with OOPS debugging +09:05 < wsa> Shimoda-san +09:05 < wsa> : submitted patches to improve SDHI performance with IOMMU, PM and SPDX patches +09:05 < wsa> for PWM, removed unused features in USBHS, fix imbalance powered flag for +09:05 < wsa> USB2-PHY, and handled delays for the WDT, reviewed USB patches dealing with +09:05 < wsa> role switch support, researched removing the r8a66597-udc, and reported a bug +09:05 < wsa> about USB SSD with xHCI +09:05 < wsa> Simon +09:05 < wsa> : posted and merged v4 of Gen3 IPA support and dynamic power coefficient patches +09:05 < wsa> Ulrich +09:05 < wsa> : sent v2 of "ravb: implement MTU change while device is up" +09:05 < wsa> Wolfram +09:05 < wsa> : started to work on converting i2c_new_dummy users, worked on analyzing various +09:05 < wsa> OOPSes, sent out a series improving HS400 quirks, took over add. SDHI task from +09:05 < wsa> Niklas, assisted Shimoda-san with WDT delay cycles and SDHI IPMMU improvements, +09:05 < wsa> picked up "WDT handover after boot" topic again, reviewed RWDT, SDHI, i2c slave +09:05 < wsa> patches +09:05 < wsa> B - what I want to do until next time +09:05 < wsa> ------------------------------------- +09:05 < wsa> Geert +09:05 < wsa> : wants to look into SCIF TX DMA length of 0 issue +09:05 < wsa> Shimoda-san +09:05 < wsa> : wants to continue to discuss SDHI driver with IOMMU, change memcpy() to +09:05 < wsa> assignments in USBHS driver, and investigate imbalance enable/disable +09:05 < wsa> in rcar-gen3-usb2 driver as well as USB SSD issue +09:05 < wsa> Simon +09:05 < wsa> : wants to follow up on RAVB on E3/D3 Errata +09:05 < wsa> Wolfram +09:05 < wsa> : wants to continue with i2c_new_dummy conversion, finalize HS400 quirks patch +09:05 < wsa> series, continue with add. SDHI task, ask for help regarding the workqueue +09:05 < wsa> related OOPS +09:05 < wsa> C - problems I currently have +09:05 < wsa> ----------------------------- +09:05 < wsa> Kaneko-san +09:05 < wsa> : patch "rcar_gen3_thermal: Update calculation" is reviewed but stuck +09:05 < wsa> Wolfram +09:05 < wsa> : got no response from Guenter about the WDT handover topic, needs the +09:05 < wsa> information which Gen3 SoCs cannot do SDHI tap auto correction with HS400 +09:05 < wsa> because this issue crashes M3N with current upstream kernels +09:06 < wsa> about Kaneko-san's patches being stuck, maybe it would help if we add some Tested-by tags? +09:06 < wsa> (I didn't see any in patchwork) +09:07 < wsa> horms: neg: do you have some minutes to do that? +09:08 < horms> wsa: I think I have done so. But perhaps I should repost with those tags? +09:08 < neg> wsa: will do +09:08 < wsa> uli_: David Miller nacked "ravb: implement MTU change while device is up". does his reply show a clear way forward? +09:09 < wsa> horms: I also thought you did... but I couldn't find the tags +09:09 < uli_> depends if i understand him correctly +09:09 < horms> wsa: let me take a look and take some appropriate action +09:09 < wsa> It may be good to resend with tags, and then Niklas can add his as well +09:09 < wsa> horms: thanks +09:09 < uli_> we could reset the mtu if the re-open fails, but then the device may still go down because of an mtu change +09:09 < uli_> in theory... +09:09 < geertu> uli_: I failed to parse his last sentence. +09:10 < uli_> i think there is an if too many at the start +09:10 < geertu> OK, so he wants to revert the MTU change on failure +09:10 < uli_> that's how i read it +09:11 < geertu> Fortunately netdev_update_features() cannot fail (at least it returns void ;-) +09:11 < wsa> how are other drivers handling it? +09:11 < uli_> they aren't, as far as i could tell :) +09:11 < uli_> some implement mtu changes while the device is up, but that is somewhat complex +09:11 < uli_> most just take the device down and up again +09:12 < horms> I think that such a scheme would be an improvement over what we currently have +09:12 < geertu> And, in theory, the ravb_open() after MTU revert might fail, too? +09:12 < uli_> possibly +09:13 < wsa> That sounds like a question for David? +09:14 < uli_> i suppose so +09:14 < wsa> can you take care of that? +09:14 < uli_> i will +09:14 < wsa> thanks! +09:15 < horms> I wonder why a failure might occur and if there is any value in trying to unwind +09:15 < wsa> shimoda: any news which SoCs have the issue with "SDHI tap autocorrection and HS400"? +09:16 < geertu> horms: The device might not support the new MTU value? +09:16 < wsa> (I suppose not, but I still wanted to ask :)) +09:16 < geertu> (e.g. too large) +09:16 < wsa> Last time, Goda-san suggested to wait some time for confirmation from the HW team, I think +09:16 < horms> geertu: sure. its possiible. but the driver should know the max mtu of the device +09:17 < horms> geertu: anyway, I'm just thinking out loud +09:17 < geertu> horms: .ndo_change_mtu() is passed the value from userspace? +09:17 < uli_> i assumed that one if the various initializations may fail (dmac, clock, phy, whatever) +09:17 < wsa> morimoto: I got a mail two weeks ago "peripelist | Access to project was granted". Is there a change in infrastructure? (Maybe I missed some information?) +09:17 < geertu> without checking? +09:18 < morimoto> wsa: I exchanged periject git repository access for periperi people. now all member can push. I guess it is for it ? +09:19 < shimoda> wsa: unfortunately hw team is investigating this issue now +09:19 < geertu> morimoto: I received the access email for peripelist and periupport +09:19 < wsa> morimoto: the mails mentioned "peripelist" and "periupport", not "periject" +09:20 < morimoto> wsa: Oops, "peripelist". I exchanged *not* to push it. +09:20 < morimoto> "periject" : all member can push +09:20 < wsa> shimoda: Ok, I will wait some more. Thanks for the heads up. +09:20 < morimoto> peripelist / periupport : all member can't push +09:21 < wsa> Ah, now I see +09:21 < morimoto> wsa: geertu: I guess no more update for peripelist / periupport, right ? +09:22 < geertu> morimoto: Indeed: GitLab: You are not allowed to push code to this project. +09:22 < geertu> morimoto: Good, we we won't update those anymore ;-) periject rulez! +09:22 < morimoto> I'm sorry I didn't mention +09:22 < morimoto> mention about it +09:22 < wsa> any open questions from your side? +09:24 < horms> geertu: dev_set_mtu_ext() calls __dev_set_mtu() which in turn calls ndo_change_mtu(). dev_set_mtu_ext() also chacks dev->max_mtu +09:24 < geertu> horms: So it's not expected to fail +09:24 < wsa> horms: just to make sure, please drop the SDHI upport for Kaneko-san. We need the info from the HW team before we decide how to continue +09:24 < horms> geertu: I can't say for sure. But that is my reasoning at this point +09:24 < horms> wsa: ack +09:25 < wsa> horms: I see you found some MM upporting tasks for him meanwhile :) +09:25 < horms> geertu: I recall that this kind of helper is a relatively new invention to simplify driver code. So I think the assumption is the check prevents some failure modes. +09:26 < horms> wsa: yes, pinchartl was very helpful +09:28 < wsa> okay, then, I think we are done with this meeting +09:28 < wsa> So, thank you all for your work! +09:29 < pinchartl> regarding periupport, we're still missing support for an equivalent feature in periject... +09:30 < wsa> you mean a visualization of which patch is already processed? +09:30 < morimoto> pinchartl: which feature ?? +09:31 < pinchartl> visualization is one of them +09:31 < pinchartl> but also a way to easily mark patches that we don't want to upstream +09:31 < pinchartl> with a reason +09:31 < pinchartl> in a nutshell, a BSP patch tracker +09:31 < pinchartl> which is exactly what pariupport is +09:31 < geertu> And I need to improve my YAML parsing skills, as my old bash scripts to auto-update upstreamed periupport commits can no longer be used +09:31 < pinchartl> periject being a task tracker +09:32 < morimoto> pinchartl: about visualization, you can merge "viewer" branch +09:32 < morimoto> pinchartl: and do "make". you can find html file again :) +09:33 < pinchartl> that doesn't bring me a list of MM patches from the BSP :-) +09:34 < morimoto> I think it is "idea" issue, not "tool" issue ? How about to add "remain BSP patches" file +09:35 < pinchartl> but BSP patches != tasks ... +09:35 < pinchartl> I don't want to create a task titled "Do not port these BSP MM patches" that refers to BSP patches that I don't want to upport +09:37 < pinchartl> I fully agree that for BSP patches that we want to upport we should create tasks +09:37 < pinchartl> but it's the other ones that we have no good way to handle +09:38 < wsa> The way I handle it: some topics get a dedicated task, like "SDHI: HS400 autocorrection". The leftovers get a task like "bsp395: upport SDHI patches". In there, I can comment on them to be not upported +09:40 < pinchartl> I don't like that much :-( +09:40 < pinchartl> to me periupport is similar to patchwork +09:40 < pinchartl> it tracks commits +09:40 < pinchartl> to make sure none of them gets forgotten +09:40 < pinchartl> while periject is a task tracker +09:42 < morimoto> I don't understand what is the issue ... +09:42 < morimoto> How about this ? +09:42 < morimoto> task name = "sort BSP patches" +09:42 < morimoto> you can list up all remain patches. +09:42 < morimoto> you can use comment or tag or something to mark up. +09:42 < morimoto> pick up them if it could tasks. +09:43 < geertu> Thigns become complicated when combining multiple commits in a single task, with different paths forward +09:43 < pinchartl> that would be like replacing patchwork by a process that adds an entry in a bugzilla titled "Handle patches posted to the mailing list" and then using it to track the state of patches +09:44 < pinchartl> we *could* do something like that, but it's quite a hack, and I don't think it would be very practical +09:44 < wsa> pinchartl: send patches :) +09:44 < pinchartl> wsa: for what ? :-) +09:45 < shimoda> pinchartl: in other words, you'd like to maintain both periupport and periject? +09:45 < wsa> pinchartl: whatever you like +09:46 < pinchartl> shimoda: yes and no. I think the two tools handle different needs. but I also think we could integrate periupport in periject if we wanted to, but in that case we should have a ticket file similar to what we have today in periject +09:46 < pinchartl> (possibly in a different format, we can standardize everything on yaml if we want, but the idea remains the same) +09:47 < geertu> Hence new BSP commits start with being an individual new periject ticket, but may be absorbed/aggreated into a larger task? +09:47 < geertu> s/ticket/task/ +09:47 < pinchartl> geertu: no, I don't think we should create a ticket for each BSP commit +09:48 < pinchartl> BSP commits would be stored in a single file like we do in periupport, and we would create tasks out of them as we plan/perform the backporting +09:48 < pinchartl> one ticket per BSP commit would soon become very, very impractical +09:49 < pinchartl> but in any case I don't think I'll win this fight, as none of us will have time to specify how this would be handled, not even talking about implementing the tooling :-) +09:49 < neg> How about a bsp-commit.txt file similar to periupport, in it one can nack a patch and give a reason. Then add some visualisation of the delta of patches that should be upported but are not listed in any task file ? +09:49 < pinchartl> neg: I think that's what I meant by importing a periupport-style BSP commits file, yes +09:50 < pinchartl> (again, could be in the same format as today, or we could use yaml if we wanted to store everything in yaml) +09:51 < wsa> pinchartl: I don't think it is a fight. It is just about spending time on it as you mentioned +09:52 < pinchartl> wsa: it was just a metaphor, but not the best choice of word, I agree +09:54 < geertu> Time for Core chat? +09:55 < wsa> i think so +09:56 < geertu> ok diff --git a/wiki/Chat_log/20190606-mm-chatlog b/wiki/Chat_log/20190606-mm-chatlog new file mode 100644 index 0000000..059a252 --- /dev/null +++ b/wiki/Chat_log/20190606-mm-chatlog @@ -0,0 +1,132 @@ +Multimedia-chat-meeting-2019-06-06 + +10:05 < pinchartl> welcome to the multimedia meeting +10:05 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:05 < pinchartl> * Jacopo +10:05 < pinchartl> Since last meeting: +10:05 < pinchartl> - CMM driver upport +10:05 < pinchartl> Work in progress, can srt LUT on the CMM using KMS properties. +10:05 < pinchartl> - Patch review +10:05 < pinchartl> Until next meeting: +10:05 < pinchartl> - Send v2 of the CMM series +10:05 < pinchartl> - Face to face Meeting with Sakari Ailus +10:05 < pinchartl> Will discuss V4L2 multiplexed streams support using GMSL as an example. +10:05 < pinchartl> Issues and blockers: None +10:05 < pinchartl> jmondi: any comment ? +10:06 < jmondi> pinchartl: not really +10:06 < jmondi> apart that I plan to send CMM patches this morning after the cleanup +10:07 < pinchartl> nice ! +10:07 < pinchartl> thank you +10:07 < jmondi> I welcome comments from you and anyone in the MM team on the v4l2-multiplexing issue since I will have to meet Sakari +10:07 < jmondi> and I will have some question for you on DRM/KMS APIs, but we can bring them offline +10:07 < jmondi> and that was a "not really" not really comment +10:07 < pinchartl> let's schedule a discussion for that before you meet with Sakari then. could you send a mail to propose a date and time ? +10:07 < jmondi> indeed +10:08 < pinchartl> thanks +10:08 < pinchartl> * Kieran +10:08 < pinchartl> Since last meeting: None +10:08 < pinchartl> Until next meeting: +10:08 < pinchartl> - Post a new (final?) PA-Phase series +10:08 < pinchartl> - Fix DU group refactoring series +10:08 < pinchartl> - Review the LVDS dual-link mode series +10:08 < pinchartl> Issues and blockers: None +10:08 < pinchartl> kbingham: any comment ? +10:09 < kbingham[m]> No, that's fine +10:09 < pinchartl> thank you +10:09 < pinchartl> * Morimoto-san +10:09 < pinchartl> Since last meeting: +10:09 < pinchartl> - ALSA SoC modern device support +10:09 < pinchartl> The patches seem to be blocked due to the ongoing USA-China trade war +10:09 < pinchartl> and export control restrictions related to Huawei. +10:09 < pinchartl> Until next meeting: +10:09 < pinchartl> - Continue with ALSA SoC work +10:09 < pinchartl> Issues and Blockers: None +10:10 < pinchartl> morimoto: any comment ? +10:10 < pinchartl> do you have more details on this Huawei-related issue ? +10:10 < pinchartl> were there discussions on a public mailing list ? +10:10 < morimoto> pinchartl: no I hear +10:10 < morimoto> I heared it at off-line +10:11 < morimoto> ALSA SoC maintatenor said the reason why he can't push new branch was related to it. +10:11 < morimoto> I'm not sure detail... +10:12 < pinchartl> it would be useful to get more information +10:12 < morimoto> and thanks. no comment for me +10:13 < morimoto> s/for/from +10:13 < pinchartl> if you receive any extra information, could you please share it ? +10:13 < morimoto> pinchartl: of course +10:13 < pinchartl> thank you +10:13 < pinchartl> * Laurent +10:13 < pinchartl> Since last meeting: +10:13 < pinchartl> - Vacation +10:13 < pinchartl> Until next meeting: +10:13 < pinchartl> - Get the LVDS dual-link prototype merged +10:13 < pinchartl> Issues and blockers: None +10:13 < pinchartl> (I had forgotten myself...) +10:13 < pinchartl> any question ? +10:14 * kbingham wonders how far the huawaei blockade will escalate. +10:14 < pinchartl> * Niklas +10:14 < pinchartl> Since last meeting: +10:14 < pinchartl> - Vacation +10:14 < pinchartl> Until next meeting: +10:14 < pinchartl> - Keep cleaning up the VIN crop and compose code +10:14 < pinchartl> This is needed to merge UDS and PM support. +10:14 < pinchartl> Issues and blockers: None +10:14 < pinchartl> neg: any comment ? +10:15 < neg> kbingham: you will no longer be allowed to use leaked datasheets in your work if the leak is from China... ;-P +10:15 < neg> no comment, thanks +10:15 < pinchartl> * Simon +10:15 < pinchartl> Since last meeting: None +10:15 < pinchartl> Until next meeting: +10:15 < pinchartl> - Upport of DT patches from the BSP (Kaneko-san) +10:15 < pinchartl> Issues and Blockers: None +10:15 < pinchartl> horms: any comment ? +10:15 < horms> I had hoped to report some progress, but there is none. I've pinged Kaneko-san again this morning +10:16 < pinchartl> * Ulrich +10:16 < pinchartl> Since last meeting: None +10:16 < pinchartl> Until next meeting: None +10:16 < pinchartl> Issues and Blockers: None +10:16 < pinchartl> uli_: any comment ? +10:16 < uli_> nope +10:16 < kbingham> neg, Until China buys softbank, and then owns Arm, and restricts all licenses of Arm products to prevent american companies from using it ... and then ... +10:16 < pinchartl> that's it for the status report then +10:17 < wsa> kbingham: that would be an interesting move! +10:17 < pinchartl> any discussion topic ? +10:17 < kbingham> wsa, I don't think Trump realises the scale of things he's playing with :) +10:18 < kbingham> No current mm topic for me at the moment. +10:18 < pinchartl> if there's nothing else to discuss, I propose adjourning this meeting. does anyone second ? +10:18 < neg> I have one quick +10:18 < pinchartl> sure +10:19 < neg> are you OK with me pushing periject patches for VIN + CSI-2 upporting status? Basically dropping all tasks not related to them from the periject patch I posted a few months back +10:20 < pinchartl> I'm totally fine with pushing the tasks we work on to periject, of course :-) +10:20 < neg> Or do you wish us to handle MM periupport -> periject in a more coordinated fashion ? +10:20 < jmondi> ah right, I should have asked how to handle CMM upporting too, with periject or periupport.... +10:21 < pinchartl> jmondi: it's hardly an upporting task, you're more or less rewriting it :-) +10:21 < pinchartl> neg: I think everybody should manage the tickets related to the tasks they're working on +10:21 < neg> cool then I will push such patches before end of month per .jp request, thanks +10:22 < neg> No more questions from me +10:22 < jmondi> pinchartl: yeah, but it's something that's in BSP and that we're brining to mainline +10:22 < jmondi> but it's not in the periupport ticket +10:22 < pinchartl> neg: please make sure that the tasks are worded as tasks, not as an upport request +10:22 < pinchartl> jmondi: it's still not an upport :-) +10:23 < pinchartl> the fact that someone, somewhere, sometime, developed an out-of-tree driver doesn't make your new driver an upport +10:23 < jmondi> pinchartl: I see... to bad, I'm sure Japan would be happy if it was an upport :) +10:24 < pinchartl> they should be happier that it's not ;-) +10:24 < jmondi> (if you're referring to the Bosh patches, they're an "upport" from the Renesas 4.19 based BSP +10:25 < pinchartl> I'm referring to the fact that what we will upstream should be better than an upport +10:25 < jmondi> hopefully yes :) +10:26 < jmondi> anyway, I'm fine not having to create a periject task for it if not necessary! +10:26 < pinchartl> no, please create a periject task +10:27 < pinchartl> you're working on it, so it should have a task +10:27 * jmondi confused :) +10:27 < pinchartl> what's confusing ? +10:27 < jmondi> I thought it was to track upport only, but I'll do it anyhow! +10:27 < jmondi> sorry, I'm stealing time for nothing here +10:27 < pinchartl> no, periject is not about tracking upporting, it's a task manager +10:27 < pinchartl> unless I completely misunderstood it +10:28 < jmondi> I'm sure I did +10:28 < pinchartl> any other discussion topic, or should we adjourn this meeting ? +10:28 < morimoto> Yeah +10:28 < jmondi> please adjurn the meeting if you want to, I'll stop blathering +10:29 < pinchartl> morimoto: yeah to other discussion topic, or yeah to adjourning the meeting ? +10:29 < morimoto> for adjourning, sorry +10:29 < pinchartl> :-) +10:29 < pinchartl> meeting adjourned, thank you all for attending diff --git a/wiki/Chat_log/20190618-mm-chatlog b/wiki/Chat_log/20190618-mm-chatlog new file mode 100644 index 0000000..931dba4 --- /dev/null +++ b/wiki/Chat_log/20190618-mm-chatlog @@ -0,0 +1,118 @@ +Multimedia-chat-meeting-2019-06-18 + +10:15 < pinchartl> welcome to the multimedia meeting +10:15 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:15 < pinchartl> * Jacopo +10:15 < pinchartl> Since last meeting: +10:15 < pinchartl> - CMM: Sent v1 after the 'plumbing' RFC patches +10:15 < pinchartl> - Face to face Meeting with Sakari Ailus +10:15 < pinchartl> Met with Sakari in Milan to discuss how to move forward with V4L2 +10:15 < pinchartl> multiplexed streams. I presented him the restriction specific to Renesas +10:15 < pinchartl> devices. The series is currently stalled due to on-going discussion with +10:15 < pinchartl> Laurent and Niklas and relatively low feedback from the rest of the +10:15 < pinchartl> V4L2 community. +10:15 < pinchartl> - Patch review +10:15 < pinchartl> Until next meeting: +10:15 < pinchartl> - Send next version of the CMM series +10:15 < pinchartl> Hope to meet the deadline for the v5.3 merge window (or is it late +10:15 < pinchartl> already?) +10:15 < pinchartl> Issues and blockers: +10:15 < pinchartl> - Consensus is hard to reach on v4l2-mux, stalling the work +10:15 < pinchartl> jmondi: any comment ? +10:16 < jmondi> I'm late for 5.3, rigth? +10:17 < pinchartl> I think the last chance would be tomorrow +10:17 < jmondi> ah +10:17 < jmondi> I don't think I could get your review on CMM for tomorrow, right? +10:17 < pinchartl> but there's no guarantee +10:17 < pinchartl> not unless you post the patches :-) +10:17 < jmondi> which assumes I should be able to resend today, which might not be impossible +10:18 < pinchartl> and one more version may be needed +10:18 < jmondi> ah you don't review not-posted patches? How lazy from you +10:18 < jmondi> indeed it might +10:18 < jmondi> pinchartl: should we try 5.3 or consider it late already? +10:18 < pinchartl> so there's no need to rush I think +10:19 < pinchartl> if you have spare cycles you can try, but it's getting late +10:19 < jmondi> a spare what? +10:19 < jmondi> :p +10:19 < pinchartl> :-) +10:19 < jmondi> I'll ping you if I'm able to resend today +10:19 < pinchartl> ok +10:19 < pinchartl> thank you +10:19 < pinchartl> * Kieran +10:19 < pinchartl> Since last meeting: +10:19 < pinchartl> - More investigation on partition algorithm phase +10:19 < pinchartl> New 'datasheet' implementation is still 'off' by x pixels. +10:19 < pinchartl> - Supported Laurent with DU group rework +10:19 < pinchartl> - Reviewed the LVDS dual-link mode series +10:19 < pinchartl> Until next meeting: +10:19 < pinchartl> - Continue digging on PA-phase +10:19 < pinchartl> Issues and blockers: +10:19 < pinchartl> - 'new' PA Phase is generating partitions that are not aligned correctly +10:19 < pinchartl> The 'dumbed down' implementation works, but following the datasheet +10:19 < pinchartl> procedure does not. Still not sure if that's a bug in the +10:19 < pinchartl> implementation, of if the algorithm provided by the datasheet just isn't +10:19 < pinchartl> creating the correct alignments. Needs extensive debug. +10:19 < pinchartl> kbingham: any comment ? +10:20 < kbingham> yes - its' painful :) Because I have low visibility of what the hardware does except for a 'yes/no' it's worked or hasn't :S +10:21 < kbingham> Otherwise status is correct :) +10:21 < pinchartl> really ? don't we know quite well what the hardware does ? +10:21 < kbingham> Do we know which pixels are being processed exactly and why it's unaligned when I expect it not to be? +10:22 < pinchartl> I don't see why it wouldn't be possible to find it out +10:22 < pinchartl> you can create specially crafted images to see what pixels are processed +10:23 < kbingham> Ok - lets work on something to do that next. But we can discuss that offline from here. +10:23 < pinchartl> ok +10:23 < pinchartl> thanks +10:23 < pinchartl> * Laurent +10:23 < pinchartl> Since last meeting: +10:23 < pinchartl> - Got the LVDS dual-link prototype merged +10:23 < pinchartl> - Posted next version of DU group refactoring +10:23 < pinchartl> - Patch review +10:23 < pinchartl> Until next meeting: +10:23 < pinchartl> - Get DU group refactoring merged +10:23 < pinchartl> Issues and blockers: None +10:23 < pinchartl> any question ? +10:25 < pinchartl> * Morimoto-san +10:25 < pinchartl> Since last meeting: +10:25 < pinchartl> - ALSA SoC modern device support +10:25 < pinchartl> Patches were posted and accepted. +10:25 < pinchartl> Until next meeting: +10:25 < pinchartl> - Post ALSA SoC framework cleanup +10:25 < pinchartl> Issues and Blockers: None +10:25 < pinchartl> morimoto: any comment ? +10:25 < morimoto> thanks. no comment +10:25 < pinchartl> thank you +10:25 < pinchartl> * Niklas +10:25 < pinchartl> Since last meeting: +10:25 < pinchartl> - First big VIN series accepted upstream +10:25 < pinchartl> - Add support for RGBA formats to VIN +10:25 < pinchartl> Until next meeting: +10:25 < pinchartl> - Keep cleaning up the VIN crop and compose code +10:25 < pinchartl> This is needed to merge UDS and PM support. +10:25 < pinchartl> Issues and blockers: None +10:25 < pinchartl> neg: any comment ? +10:26 < neg> no comment +10:26 < pinchartl> thank you +10:26 < pinchartl> * Simon + Kaneko-san +10:26 < pinchartl> Since last meeting: +10:26 < pinchartl> - Add CPG reset to DU node in D3/E3 DT +10:26 < pinchartl> - Fix register range for DU in D3/E3 DT +10:26 < pinchartl> Until next meeting: +10:26 < pinchartl> - Update BSP ticket file +10:26 < pinchartl> Issues and Blockers: None +10:26 < pinchartl> horms: any comment ? +10:27 < horms> Nothing more to add +10:27 < pinchartl> thank you +10:27 < pinchartl> * Ulrich +10:27 < pinchartl> Since last meeting: +10:27 < pinchartl> - Patch review +10:27 < pinchartl> Until next meeting: None +10:27 < pinchartl> Issues and Blockers: None +10:27 < pinchartl> uli__: any comment ? +10:27 < uli__> nope +10:27 < pinchartl> thank you +10:27 < pinchartl> that's it for status updates +10:27 < pinchartl> any discussion topic ? +10:29 < pinchartl> if not, I propose adjourning this meeting. does anyone second ? +10:29 < neg> second +10:29 < morimoto> 2nd +10:29 < pinchartl> meeting adjourned, thank you for attending diff --git a/wiki/Chat_log/20190620-core-chatlog b/wiki/Chat_log/20190620-core-chatlog new file mode 100644 index 0000000..6374cba --- /dev/null +++ b/wiki/Chat_log/20190620-core-chatlog @@ -0,0 +1,145 @@ +09:31 < geertu> Welcome to Today's Core Group Chat! +09:31 < geertu> Agenda: +09:31 < geertu> 1. Status Updates +09:31 < geertu> 2. Discussion Topics +09:31 < geertu> Topic 1. Status updates +09:31 < geertu> A) What have we done since last time: +09:31 < geertu> Marek cleaned up the QoS and PFC drivers in ATF, and moved them out of +09:31 < geertu> staging. +09:31 < geertu> Morimoto-san gained one year of wisdom. +09:31 < geertu> Shimoda-san worked on exporting BSDL files to Marek. +09:31 < geertu> Simon posted CMT DT binding patches for R-Car H3/M3-N/E3. +09:31 < geertu> Geert sent clk-renesas and sh-pfc pull requests for v5.3, posted an RFC +09:31 < geertu> to create DMA slave links in sysfs, and implemented the +09:31 < geertu> .determine_rate() callback for Z and SD clocks on R-Car Gen2/Gen3. +09:32 < geertu> B) What we plan to do till next time: +09:32 < geertu> Marek may look into DDR support in ATF. +09:32 < geertu> Shimoda plans to perform export control for BSDL files. +09:32 < geertu> Geert plans to send a second clk-renesas pull request for v5.3,enable +09:32 < geertu> SDRAM on RZA2MEVB, and start queuing Renesas arm/arm64 patches for v5.4. +09:33 < geertu> C) Problems we have currently: +09:33 < geertu> Simon wonders if +09:33 < geertu> Documentation/devicetree/.../renesas-memory-controllers.txt should be +09:33 < geertu> renamed. +09:33 < geertu> EOT +09:33 < geertu> Anything I missed? +09:34 < geertu> horms: Personally, I don't like the proposed renesas-memory,controllers.txt +09:34 < geertu> What about renesas,dbsc.text (.yaml ;-)? +09:35 < geertu> As of R-Mobile A1, all SoCs have a DDR DRAM controller, hence DBSC +09:35 < geertu> Up to SH-Mobile AG5, it was SBSC (SDRAM ...) +09:36 < horms> Sure, that is fine +09:36 < horms> this is exactly the kind of suggestion I was hoping for +09:37 < geertu> Good ;-) +09:38 < geertu> Topic 2. Discussion Topics +09:39 < geertu> morimoto: Now the access to Magnus' server has been restored, do you have documentation updates? +09:41 < morimoto> No, I guess Renesas closed port 22 +09:41 < morimoto> So, I have no chance to update datasheet so far +09:41 < geertu> It's port 10000 +09:42 < damm> geertu: i am still waiting for an email with a summary of the problem from morimoto-san +09:43 < damm> it probably takes me 5 minutes to fix +09:43 < geertu> damm: my access was restored 2 weeks ago +09:43 < damm> yeah i restarted the vm +09:43 < damm> but i asked morimoto-san to send me an email at that point too +09:44 < damm> no response though +09:44 < damm> since long i added a workaround for renesas network +09:44 < damm> and it might need some update +09:44 < geertu> PEBCAC? +09:45 < damm> it doesn't matter how much you or morimoto-san look into it +09:45 < damm> the handle is on this side +09:45 < morimoto> I sent it via google hangout +09:45 < damm> i asked for email +09:45 < damm> how difficult can that be? +09:45 < damm> i asked for it 3 times +09:45 < damm> just send it +09:47 < morimoto> I sent it now +09:48 < geertu> Thx +09:48 < damm> thank you, does it work better now? +09:49 < kbingham> damm, Aha - I can confirm my update.sh script is now operational. :) +09:49 < Marex> same here +09:50 < kbingham> but now the speed has dropped to 4kB/s :D +09:50 < damm> i restarted the port forwarding for renesas +09:50 < kbingham> (but it was fine) +09:50 < morimoto> damm: wow !! It start works +09:50 < damm> good +09:50 < damm> thank you for sending the email +09:50 < morimoto> thanks +09:51 < geertu> 1.8 MB/s for R-Car-Gen3-rev1.50-20190605.zip +09:51 < kbingham> geertu, You're hogging all the bandwidth :) +09:51 * Marex furiously downloads +09:51 < geertu> kbingham: done +09:51 < morimoto> I will skip to send announce mail to PeriPeri-ML this time :) +09:51 < wsa> Yay, let's download all at the same time :D +09:51 < kbingham> Oh and I'm back up to 1MB/s +09:52 < kbingham> #periperi hammers damns' server :) +09:52 < Marex> kbingham: stop hogging the bandwidth, I'm at 500 kiB ;-) +09:52 < kbingham> hehe +09:52 < Marex> 19 kiB now +09:52 < damm> should be a gigabit link +09:52 * kbingham synced complete +09:52 < geertu> As you may have noticed from the report, the plan is for me to take over Renesas arm/arm64 maintenance from Simon as of v5.4 +09:52 < Marex> 5.12 kiB/s :-D +09:52 < kbingham> damm, I guess it's the wet pieces of string in the middle :) +09:52 < geertu> Simon will continue to take care of fixes for v5.3 +09:54 < horms> Yes, I have now closed my tree for v5.3. And will send pull-requests, handle any changes requested for them, and handle any fixes for v5.3. +09:55 < horms> Geert, could I ask you to hold off until the pull requests are sent until you accept anything for v5.4. i.e. until next week? +09:55 < Marex> shimoda: btw. do you think we could release that ULCB CPLD USB control tool in public ? +09:55 < geertu> horms: Sure, I had planned to wait to Jul 1 +09:55 < geertu> s/to/until/ +09:56 < horms> That is up to you :) +09:56 < geertu> horms: Thanks for taking care during all these years! +09:56 < horms> Thanks, its been a pleasure. +09:56 < shimoda> Marex: it's depend on Renesas Europe side policy. I heard from Goda-san that Renesas Europe made the tool +09:57 < Marex> shimoda: but I made my own tool, which implements the same protocol, and I would like to release my own tool +09:57 < pinchartl> horms: do I understand correctly that our ways will part (at least on the Renesas side) after v5.3 ? should I assume this applies to Kaneko-san too ? +09:57 < Marex> shimoda: the renesas europe windoze-only tool is not interesting to me +09:57 < horms> I am handing over the maintenance role now, as Geert described. +09:57 < Marex> shimoda: but maybe I can ask Mr. Dege from Renesas Europe for approval and if he says yes, I can release my own tool ? +09:57 < horms> Kaneko-san and I plan to part ways with Renesas at the end of next quarter, i.e. end of Sept. +09:58 < Marex> horms: :-( +09:58 < pinchartl> horms: I'm sure we will still hear from you, one way or another :-) +09:58 < horms> Yes, I don't plan to stop existing alltogether +09:59 < geertu> horms: Will you join Microsoft? ;-) +09:59 < pinchartl> that is very good news, although not really a surprise :-) +09:59 < morimoto> Marex: windoze :) +09:59 < shimoda> Marex: oh, you made the tool. Yeah, i think if Mr Dege accepts you can release in public +09:59 < pinchartl> horms: thank you for the information. so I can expect more MM patches from you and Kaneko-san in Q3 \o/ +09:59 < horms> geertu: anything is possible! +09:59 < wsa> horms: thanks for all your maintenance work! +09:59 < jmondi> horms: I'm sorry to hear that, I hope you'll get around here anyhow after Q3 +10:00 < horms> patersonc: yes. I think most of the patching is complete and I owe you a ticket update. I'll try and get that to you soon so we can clafify what is/isn't outstanding +10:00 < patersonc> horms: Thank you! It's a shame you're stopping! +10:00 < Marex> shimoda: yep, I analyzed the protocol and made my own tool, which would be convenient for CI / testing +10:00 < patersonc> horms: Sure, no worries +10:00 < horms> patersonc: sorry, i meant that response for pinchartl. But thanks for yuor good wishes +10:01 < horms> patersonc: I can also send you a list of patches if you like, but it won't be very different to what is visible on patchwork +10:01 < patersonc> horms: :) no worries +10:01 < patersonc> horms: The system seems to work +10:01 < Marex> shimoda: i didn't want to circumvent you, hence I asked you about releasing the tool first, but if it's renesas europe who's in charge, I can ask for approval there +10:03 < geertu> Anything else to discuss? +10:03 < shimoda> Marex: thank you for asking first :) +10:03 < patersonc> Marex: Asking Dege is probably a good idea. +10:03 < Marex> shimoda: you're welcome +10:04 < patersonc> horms: What are your plans for the future? +10:04 < pinchartl> geertu: next meeting ? +10:04 < neg> flipping burgers at McDonalds ? +10:05 < pinchartl> now that many team members have seen their time allocation significantly reduced, I wonder if a bi-weekly meeting isn't too frequent +10:05 < kbingham> neg, That's automated now by IoT machines connected to the McNet :) +10:06 < morimoto> McNet :) +10:06 < wsa> pinchartl: i wondered about this, too, starting from Q4. But maybe Q3 is apropriate also? +10:07 < pinchartl> all additional tasks have been dropped, so we're down to 5 days a month on average for some of us +10:07 < pinchartl> and spending two mornings per months in meetings would be relative large in comparison +10:08 < geertu> so jul 4 is too early? +10:08 < kbingham> pinchartl, Indeed 4 hours of meetings per month is rather a large quantity of my renesas time budget +10:08 < geertu> jul 18 several people are in JP +10:09 < pinchartl> I think that on the multimedia side there will be very little to report by July the 4th +10:11 < geertu> For Core too, I think +10:11 < pinchartl> and the 18th will be during OSSJ, so not an option +10:11 < wsa> would that make July, 11th a candidate? I won't be available but we can handle IO stuff by mail, I'd think +10:12 < geertu> Jul 11 is fine for me +10:12 < morimoto> in 3 weeks pattern, 11th July -> 1st Aug -> 22th Aug... +10:13 < morimoto> or 4 weeks ? +10:13 < shimoda> or once per month? anyway Jul 11 is fine for me. +10:13 < pinchartl> we can try the 11th, but MM may need to be handled by e-mail too +10:14 < geertu> I don't want to be an exception ;-) +10:14 < geertu> we'll see +10:15 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20190620-io-chatlog b/wiki/Chat_log/20190620-io-chatlog new file mode 100644 index 0000000..affed2d --- /dev/null +++ b/wiki/Chat_log/20190620-io-chatlog @@ -0,0 +1,98 @@ +09:04 < wsa> then, let's start the IO meeting +09:05 < wsa> first status updates: +09:05 < wsa> Status updates +09:05 < wsa> ============== +09:05 < wsa> A - what have I done since last time +09:05 < wsa> ------------------------------------ +09:05 < wsa> Geert +09:05 < wsa> : started looking into sh-sci tx_dma_len == 0 issue +09:05 < wsa> Kaneko-san +09:05 < wsa> : got "rcar_gen3_thermal: Update calculation" merged +09:05 < wsa> Shimoda-san +09:05 < wsa> : sent new versions of the SDHI & IOMMU patch series and a DMA documentation +09:05 < wsa> fix, sent USB patches about removing memcpy and an unbalanced flag and +09:05 < wsa> adding a limitation, reviewed USB binding documentation changes +09:05 < wsa> Simon +09:05 < wsa> : posted patches renaming bindings documentation to a common pattern +09:05 < wsa> Wolfram +09:05 < wsa> : converted i2c_new_dummy() calls and i2c_new_secondary_device() to new API, +09:05 < wsa> updated SDHI HS400 quirk patches and got them merged, worked on upporting +09:05 < wsa> SDHI manual calibration offsets, sent two treewide series fixing an awkward +09:05 < wsa> way to determine the adapter of an I2C client, smaller cleanup patches to the +09:05 < wsa> I2C + MFD + and media subsystems, reviewed Shimoda-san's next version of the +09:05 < wsa> SHDI IOMMU series + watchdog delay patches and some SDHI DTS patches, sent +09:05 < wsa> talk proposal for ELCE in Lyon +09:05 < wsa> B - what I want to do until next time +09:05 < wsa> ------------------------------------- +09:05 < wsa> Geert +09:05 < wsa> : wants to fix sh-sci tx_dma_len == 0 issue +09:05 < wsa> Shimoda-san +09:05 < wsa> : wants to keep working on the SDHI & IOMMU patch series, refactor the struct +09:05 < wsa> members of the usbhs driver, and keep an eye on upstream patches to avoid +09:05 < wsa> using virt_boundary_mask API +09:05 < wsa> Simon +09:05 < wsa> : wants to address review comments +09:05 < wsa> Wolfram +09:05 < wsa> : wants to continue working on upporting SDHI manual calibration offsets, +09:05 < wsa> upport more SDHI patches, continue working on I2C API changes, resend patch +09:05 < wsa> to handle watchdog handover from bootloader +09:05 < wsa> C - problems I currently have +09:05 < wsa> ----------------------------- +09:05 < wsa> Ulrich +09:05 < wsa> : didn't get a reply from Dave Miller about the RAVB MTU change implementation +09:05 < wsa> Wolfram +09:05 < wsa> : needs to delay the i2c_new_dummy() conversion because of a missing declaration +09:05 < wsa> in the i2c headers, and suffers from a lagging buildbot with lots of incomplete +09:05 < wsa> builds delaying the build tests of the I2C API changes +09:06 < wsa> uli__: what about just sending the patch and asking the questions again next to the patch description? +09:07 < wsa> horms: what happened to the "follow up on RAVB on E3/D3 Errata" task? +09:07 < wsa> any patches I missed there? +09:07 < horms> oops, let me add that back on the list +09:08 < uli__> wsa: do you suggest to re-send the patch as is, or to implement the rollback somehow and ask if that's ok? +09:09 < horms> I believe that the status is that we need to verify if setting tx timing delays in the phy is sufficient to miliate against the errata. The likely answer is no and thus we will be back to updating the driver/DT +09:09 < wsa> uli__: I thought of trying the latter... unless you or others here have a different opinion? +09:10 < uli__> no, i think that makes sense +09:10 < wsa> cool +09:11 < wsa> then, about the HS400 tap auto correction issue.. we still don't have further information from the HW team +09:11 < wsa> yet, it causes troubles on at least my M3-N +09:12 < wsa> troubles == WARNs and OOPSes +09:13 < Marex> wsa: which patch is that ? +09:13 < wsa> If we don't get the information very soon(tm), I think we should disable HS400 until we got more information +09:13 < horms> wsa: I agree +09:14 < wsa> Marex: the one you already implemented for U-Boot and then we got advised to wait for more details +09:14 < horms> Would it only be disabled on M3-N, or more widely? +09:14 < shimoda> wsa: about hs400 issue, the bsp commit e6a40476f25287eb6e6df5c4 seems a workaround code, but I'll ask someone that is final decision or not +09:14 < Marex> wsa: OK, that one +09:15 < wsa> horms: I think we should first test on various SoCs again. I prefer "per-SoC", but if we can't get a clear picture, we need to disable it globally +09:15 < horms> wsa: that sounds reasonable to me +09:15 < Marex> wsa: I _think_ it improved the HS400 calibration behavior on E3, but I might be wrong +09:16 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has joined #periperi +09:16 < wsa> shimoda: thanks for asking them! +09:18 < wsa> That being said: I really wonder about the WARNings and OOPSes. I'd think we can fail more gracefully if the tuning is out-of-sync, but there seem to be competing workqueue issues +09:18 < wsa> I didn't have time to follow up on those, though. So, I wonder if there is someone interested to have a look at that? +09:19 < wsa> uli__ maybe? or kaneko maybe? +09:19 < Marex> wsa: maybe the whole calibration code needs a once-over? It seems like a convoluted mess :) +09:20 < geertu> How come you get an OOPS if tuning fails? +09:20 < horms> wsa: I would be happy to take a look into this +09:20 < horms> if no one else wants it / you think that is appropriate +09:21 < wsa> horms: sure, I just thougth you might be busy, but if you have the time I'd be happy if you have a look +09:22 < horms> I expect to have a bit of time next quarter, which is coming up pretty soon now +09:22 < wsa> On my M3-N, it shows by booting recent upstream kernel with renesas_defconfig and wait for 4 minutes or so +09:22 < wsa> if it doesn't show on your M3-N, I can give you a .config we could try +09:23 < horms> ok, sure +09:23 < wsa> horms: first thing would be to check if you can reproduce it +09:23 < horms> so I boot, then wait for mahem? +09:23 < shimoda> wsa: I asked Goda-san about HS400 issue, Renesas needs to continue investigate the issue. This means the BSP patch I indicated is still not good unfortunately.. +09:24 < wsa> yup, I can mail you some logs with stuff I was seeing +09:24 < wsa> so you know what to look for +09:24 < horms> thanks, that would be helpful +09:24 < wsa> shimoda: thanks for checking! +09:24 < wsa> shimoda: do you agree that we need to disable HS400 if we don't get the information in time for v5.2? +09:25 < Marex> indeed, I will hold off the U-Boot patch too +09:26 < wsa> are there other questions / requests from your side? +09:27 < shimoda> wsa: now i am working for eMMC + IOMMU patch series, if possible, i'd like to keep HS400 mode as-is +09:29 < wsa> then, for now, let's just hope we will get more details in time :) +09:29 < wsa> so, i think this was it for the IO meeting? +09:30 < wsa> geertu: you are ready? +09:30 * geertu is ready +09:30 < wsa> then, thank you all for this meeting! diff --git a/wiki/Chat_log/20190801-core-chatlog b/wiki/Chat_log/20190801-core-chatlog new file mode 100644 index 0000000..848ba3c --- /dev/null +++ b/wiki/Chat_log/20190801-core-chatlog @@ -0,0 +1,62 @@ +09:37 < geertu> Welcome to today's Core Group chat! +09:37 < geertu> Agenda: +09:37 < geertu> 1. Status Updates +09:37 < geertu> 2. Discussion Topics +09:38 < geertu> Topic 1. Status updates +09:38 < geertu> A) What have we done since last time: +09:38 < geertu> Kaneko-san sorted nodes in arm64 DTS. +09:38 < geertu> Marek worked on U-Boot (GPIO 0_00 fix and V3H Condor support). +09:38 < geertu> Shimoda-san started looking into supporting SYS-DMAC on R-Car V3U +09:38 < geertu> Ulrich reviwed V3H IPMMU-VC0 and sh-pfc patches. +09:38 < geertu> Geert fixed the CPG/MSSR reset issue, had holidays, booted Linux on +09:38 < geertu> RZA2MEVB with SDRAM enabled now the cache issue is fixed, and flushed +09:38 < geertu> his patch queue. +09:39 < geertu> B) What we plan to do till next time: +09:39 < geertu> Marek will test Linux on V3H Condor. +09:39 < geertu> Shimoda-san plans to ping the BSDL files, watch the pinctrl/PWM patch +09:39 < geertu> series direction, and continue preparing rcar-dmac patches for V3U. +09:39 < geertu> Geert plans to send first renesas-devel pull requests to arm-soc, +09:39 < geertu> review the PWM duty zero patches, and look into improving board farm +09:39 < geertu> automation for better testing. +09:39 < geertu> C) Problems we have currently: +09:39 < geertu> Geert is waiting for renesas-devel/next to appear in linux-next. +09:39 < geertu> Simon worries about DT bindings patches getting stuck. +09:39 < geertu> --- +09:40 < geertu> Anything I missed? +09:40 < horms> I think you can pick up those bindings, btw. +09:41 < geertu> Yes, that was my plan. But I wanted to wait a bit, to make the first PR for arm-soc not too big. +09:41 < geertu> FTR, renesas-devel/next is part of linux-next since today +09:43 < geertu> Topic 2. Discussion Topics +09:43 < geertu> Marex: Any news about the ULCB CPLD USB control tool? +09:45 < Marex> geertu: I got permission to release it +09:45 < Marex> geertu: I will document it and do it +09:47 < geertu> Marex: Great, thanks! +09:48 < wsa> I have an upport request: +09:48 < wsa> 46a818b22337 ("clk: renesas: rcar-gen3: Fix cpg_sd_clock_round_rate return value") +09:48 < wsa> geertu already reviewed it, so it should be a sane one ;) +09:48 < wsa> I can upport it, too, if noone else is interested +09:49 < wsa> or is it already on its way? +09:49 < geertu> wsa: Isn't that in v5.2? +09:50 < wsa> huh? +09:51 < geertu> Improved version in v5.2 is b953eaaeb58efc94 ("clk: renesas: rcar-gen3: Fix cpg_sd_clock_round_rate() return value") +09:51 < geertu> Or am I missing something? +09:51 < wsa> cool +09:51 < wsa> where the heck did I look then? +09:51 * wsa grabs a brown paper bag +09:56 < geertu> Anything else to discuss? +09:58 < wsa> not directly core, but as the mail just got in: kbingham: I can still send you a Gen2-Alt board if that will help you. +09:59 < kbingham> wsa, Thanks, if it's not in use it might be useful for the future. I was going to ask damm in the next discussion topics if there is a gen2 platform I could use remotely in his farm too :) +09:59 < kbingham> But it might be better to have a display output for Display reworks :) +10:00 < damm> kbingham: there are plenty +10:00 < geertu> Thanks for joining, and have a nice continued day! +10:01 < shimoda> about next meeting date? +10:02 < geertu> shimoda: Right, that aligns with wsa's question about meeting frequency +10:02 < shimoda> 22th Aug? In Japan side, from 9th to 18 is a vacation. +10:02 < geertu> August 22 is fine for me +10:02 < shimoda> geertu: ah, yeah, we don't decide the meeting frequency +10:02 < geertu> Some people may be at ELC-A, and asleep? +10:03 < wsa> aug 22 looks good to me +10:04 < wsa> aug 22 is also half between now and Plumbers +10:08 < wsa> my suggestion for the meetings were: status reports every 2 weeks, chat meetings every 4 +10:08 < wsa> but with the holidays and plumbers coming up, aug 22nd is fine as next meeting for me +10:09 < wsa> but maybe we can keep discussing this diff --git a/wiki/Chat_log/20190801-io-chatlog b/wiki/Chat_log/20190801-io-chatlog new file mode 100644 index 0000000..26aa842 --- /dev/null +++ b/wiki/Chat_log/20190801-io-chatlog @@ -0,0 +1,104 @@ +09:04 < wsa> welcome, welcome, and here are the collected status updates: +09:04 < wsa> Status updates +09:04 < wsa> ============== +09:04 < wsa> A - what have I done since last time +09:04 < wsa> ------------------------------------ +09:04 < wsa> Shimoda-san +09:04 < wsa> : sent out improved SDHI & IPMMU patch series, fixed the syfs interface for +09:04 < wsa> the USB "role", and got the USB SSD issue resolved +09:04 < wsa> Simon +09:04 < wsa> : sent series to rename DT binding files and limited RAVB speed on Draak and +09:04 < wsa> Ebisu +09:04 < wsa> Ulrich +09:04 < wsa> : sent v2 of SDHI PM handling update, reviewed serial and thermal patch +09:04 < wsa> Wolfram +09:04 < wsa> : sent out multiple patch series to convert using newer I2C API, reviewed +09:04 < wsa> some SDHI & media & RAVB patches, commented on Kieran's I2C questions, +09:04 < wsa> distributed BSP 3.9.6. patches, and had some time off because of holidays +09:04 < wsa> and tax declarations +09:04 < wsa> B - what I want to do until next time +09:04 < wsa> ------------------------------------- +09:04 < wsa> Niklas +09:04 < wsa> : wants to test SDHI patches +09:04 < wsa> Shimoda-san +09:04 < wsa> : wants to keep at the SDHI & IPMMU patch series, and make a patch to add a +09:04 < wsa> "XHCI_SLOW_SUSPEND" quirk to XHCI +09:04 < wsa> Simon +09:04 < wsa> : wants to follow-up on RAVB PTP patches in BSP and review of the renaming +09:04 < wsa> patches +09:04 < wsa> Ulrich +09:04 < wsa> : wants to send v3 of ravb MTU change +09:04 < wsa> Wolfram +09:04 < wsa> : wants to pick up again prototype for a minimal SDHI clock to keep SCC active, +09:04 < wsa> and to update SDHI manual calibration once we get more infos from HW team +09:04 < wsa> C - problems I currently have +09:04 < wsa> ----------------------------- +09:04 < wsa> Wolfram +09:04 < wsa> : still got no new HS400 infos from the HW team +09:05 < wsa> List shows that OSSJ and summer holidays happened, too +09:06 < wsa> but some people are looking for tasks, too, right? +09:06 < wsa> so, if there are no questions to the update... +09:07 < morimoto> geertu: IC, I mis-read it "thought" <-> "through" +09:08 < wsa> ... I'd align with who has availability in Q3 with contracts changed and such. +09:08 < wsa> I know that Simon and Kaneko-san are looking for tasks +09:08 < wsa> horms: still correct? +09:08 < horms> Yes, correct. +09:09 < horms> Thanks for the ravb tasks +09:09 < wsa> uli__: do you have resources left? are you looking for tasks? +09:10 < wsa> Marex: still interested in more Linux tasks? +09:10 < uli__> i am +09:10 < geertu> Not really related to I/O (mostly sound etc), but there is duplication in the various *-salvator-x*dts files, that could be factored out into salvator-common.dtsi, once M3N has been brought up to the same support level +09:11 < geertu> Perhaps that's a suitable task for the task-craving? +09:11 < Marex> wsa: what do you have in there ? +09:11 < wsa> geertu, neg: I'd think you are kinda busy with other subsystems, but will jump in once in a while? +09:11 < Marex> wsa: I'm currently fighting ATF DDR drivers +09:12 < wsa> Marex: generally asking. the bsp396 ticket adds support for a new PMIC, for example. (that's core, though) +09:13 < geertu> That's BD9574, right? -ENODOCS? +09:14 < wsa> shimoda: there are two patches in the BSP which are USB related. Do you have time to investigate them? Or are you happy if someone else would have a look? +09:15 < wsa> "USB: ohci-hcd.c: Add spinlock when disabling OHCI interrupts in ohci_shutdown(Tho Vu)" +09:15 < wsa> "phy: rcar-gen3-usb2: Correct VBUS behavior at over-current(Kazuya Mizuguchi)" +09:15 < Marex> geertu: google doesn't even know bd9574 +09:15 < wsa> Marex: then we need to ask a bigger force than google... morimoto-san? +09:16 < shimoda> wsa: I'd like to investigate them. +09:17 < wsa> shimoda: Ok, I will update the YAML file accordingly. Thanks! +09:17 < shimoda> wsa: thanks! +09:18 < wsa> shimoda: similar questions with the SDHI-sys-dmac removal for Gen3. Do you want to do it? Or do you just want to have it done by someone? :) +09:19 < shimoda> wsa: about the SDHI topic, if someone has this task, I'm happy :) +09:20 < wsa> shimoda: ok. noted :) +09:20 < horms> geertu: I can take a look intot that if no one else is interested. +09:20 < geertu> Regarding Magnus' reply supporting only the latest SoCs with the most advanced features: how to we test on the latest SoCs? Where's the hardware? +09:21 < wsa> horms: i think the bsp396 ticket might have some candidates for you/Kaneko in there, but most of them are core. +09:21 < horms> ok, perhaps I could go through the list and come up with some candidates +09:22 < wsa> geertu: maybe this is more "latest hardware we have"? +09:22 < morimoto> wsa: it will check about BD9574 +09:22 < morimoto> s/it/I/ +09:22 < wsa> morimoto: Thanks! +09:23 < geertu> Where is bd9574 used? The BSP seems to carry driver changes only, and doesn't even provide a new compatible value? +09:23 < damm> geertu: very good question +09:25 < wsa> heh, so the upporting already started :D +09:26 < morimoto> wsa: about -ENODOCS, I don't know detail, but +09:26 < morimoto> if (!has_NDA()) return -ENODOCS +09:27 < wsa> morimoto: you mean if the developer has no NDA? or the document itself is not under an NDA? +09:28 < morimoto> you can get it if you have NDA +09:28 < shimoda> by the way, about the bd9574, according to one of renesas redmine ticket, it seems a new E3 ES1.1 board uses it. +09:29 * morimoto talking to Renesas gusy +09:29 < morimoto> OK, it seems export paper work issue. +09:30 < morimoto> But, it seems it can be difficult work +09:31 < wsa> well, we have a status "blocked" +09:31 < wsa> blocked by export paperwork issue :) +09:31 < horms> wrt exports, wsa, let me know when you come up with a plan for the Ebisu board that I have +09:31 < wsa> seems we silently slipped to core already +09:32 < wsa> horms: My plan is that you send it to me after you don't need it anymore and before you leave for good :) +09:32 < horms> Ok, good plan. +09:33 < geertu> horms: Do you have other boards you want to get rid of, and that can be of use to someone else? +09:34 < wsa> I have only one more generic item: biweekly chat meetings with reduced contracts still feasible? but we can do that a tad later +09:34 < wsa> are there IO related questions left? +09:34 < geertu> (I guess the ones still in Kobe, if any, don't count) +09:35 < wsa> no further questions, I think we can officially switch to core now +09:36 < horms> Want is a strong word. But I have the following boards and am happy to pass them on: Salvator-XS H3 ES2.0, Salvator-XS M3-N ES1.0, Salvator-X M3-W ES 1.0. These are in my office in Amsterdam. The boards that were in Kobe have all been returned to Magnus. +09:36 < geertu> OK +09:36 < geertu> horms: I have (copies of) them, too +09:37 * wsa prepares to throw the mic +09:37 * geertu is ready to catch it +09:37 * wsa throws +09:37 * geertu picks it up from the floor diff --git a/wiki/Chat_log/20190822-core-chatlog b/wiki/Chat_log/20190822-core-chatlog new file mode 100644 index 0000000..ee0387b --- /dev/null +++ b/wiki/Chat_log/20190822-core-chatlog @@ -0,0 +1,103 @@ +09:36 < geertu> Welcome to today's core group chat +09:36 < geertu> Agenda: +09:36 < geertu> 1. Status Updates +09:36 < geertu> 2. Discussion Topics +09:37 < geertu> Topic 1. Status updates +09:37 < geertu> A) What have we done since last time: +09:37 < geertu> Kaneko-san sorted more nodes in arm64 DTS. +09:37 < geertu> Marek worked on ATF (Condor, DDR B, BSP upport), U-Boot (ULCB CPLD +09:37 < geertu> control tool, R8A66597 DM/DT), Linux (PCIe 32bit limitation and DMA +09:37 < geertu> range handling). +09:37 < geertu> Shimoda-san submitted PFC fixes. +09:37 < geertu> Simon cleant up DT binding doc filenames. +09:37 < geertu> Ulrich reviewed R-Car H1 DTS fixes. +09:37 < geertu> Geert reviewed the pwm-rcar/pfc/gpio patches, sent pull requests for +09:37 < geertu> v5.4 (arm-soc/pfc), submitted OSTM unique device names and always-on PM +09:37 < geertu> Domain fixes, did periject housekeeping, and improved ARM Cortex-A7/A9 +09:37 < geertu> Errata selection. +09:38 < geertu> B) What we plan to do till next time: +09:38 < geertu> Marek plans to work on U-Boot (limited USB sticks, Migo-R and R2D +09:38 < geertu> DM/DT). +09:38 < geertu> Shimoda-san plans to ping the BSDL files, and continue preparing +09:38 < geertu> rcar-dmac patches for V3U. +09:38 < geertu> Simon plans to continue cleaning up DT binding doc filenames. +09:38 < geertu> Geert plans to send more pull requests for v5.4 for clk/pfc/arm-soc, and +09:38 < geertu> rework always-on PM Domain fixes, determine_rate() patches, and the GPIO +09:38 < geertu> aggregator. +09:38 < geertu> C) Problems we have currently: +09:38 < geertu> Geert wonders how to treat R-Car M3-W ES3.0 aka M3-W+. +09:38 < geertu> ---EOL--- +09:38 < geertu> Anything I missed? +09:39 < geertu> shimoda: About "Switching multiplexed LSI pins during operation is not guaranteed" +09:39 < geertu> I think this means that it cannot guarantee that there are no glitches +09:40 < geertu> For PWM output, glitches shouldn't harm much +09:41 < geertu> As the PWM hardware doesn't seem to finish the current cycle when changing PWM parameters, glitches cannot be avoided anyway. +09:45 < shimoda> geertu: sorry I cannot understand your last comment. is this related to gpio thing? or just PWM hardware? +09:46 < geertu> shimoda: My last comment was related to the rcar-pwm hardware +09:47 < geertu> IIRC, you replied that to a question from Uwe about finishing cycles? +09:49 < geertu> Oops, looks like I misread: "the hardware will complete the currently running period" +09:49 < shimoda> geertu: Yes, I replied to Uwe. this is a violation between PWM subsystem vs the rcar-pwm hardware. +09:49 < geertu> but not when disabling it. +09:51 < shimoda> pwm itself is no problem about glitches point of view, I think. +09:51 < shimoda> s/pwm/rcar-pwm hardware/ +09:51 < geertu> So the question for continuing with PWM/GPIO is: can we live with the glitches +09:54 < shimoda> geertu: I don't think we can live for now. Especially, any customer don's ask us about this topic for now. If customer wants such a feature, our hardware team will start to investigate how to achieve it :) +09:54 < geertu> OK +09:54 < geertu> case closed ;-) +09:54 < shimoda> :) +09:55 < geertu> I think that already counted as a Topic 2. Discussion Topics +09:55 < geertu> B) R-Car M3-W ES3.0 aka M3-W+ +09:56 < geertu> Eugeniu nicely summarized the possible approaches +09:56 < geertu> He did miss H3 ES2.0 cam with a new part number, too (r8a77951) +09:56 < geertu> s/cam/came/ +09:59 < geertu> For H3 ES2.0, it turned out to be a different SoC than ES1.x (H3 ES2.0 is more similar to M3-W ES1.0 than to H3 ES1.x) +10:00 < geertu> It was mentioned before that in hindsight, we should have gone for separate compatible values for H3 ES2.0 +10:00 < geertu> So I'm leaning towards doing that for R-Car M3-W+ +10:01 < geertu> In the mean time, we did become used to five digit part numbers. +10:02 < geertu> My questions: +10:02 < geertu> 1) What do you think? +10:02 < geertu> 2) Do we have hardware access (e.g. in Magnus' farm)? +10:05 < shimoda> about M3-W and M3-W+, we can keep both dts files? (Unfortunately) this is because both SoCs will be mass production. +10:06 < geertu> If both will be mass-production, that's another reason to treat them different +10:06 < shimoda> about 2), I will bring one of M3-W+ board to Magnus' farm. +10:06 < geertu> shimoda: 2) thx! +10:06 < geertu> I guess H3 ES1.x is no longer produced +10:07 < geertu> BTW, if hardware bugs need to be fixed, will M3-W have both ES 2.1 (without +) and ES4.0 (with +)? ;-) +10:07 < shimoda> geertu: yes. H3 ES1.x will not be mass-production +10:08 < wsa> geertu: please stop, my head is already spinning :) +10:08 < shimoda> geertu: i think so. maybe ES1.4 and ES3.1 though :) +10:09 < geertu> Ah yes, they cannot have ES2 due to the PRID screwup ;-) +10:10 < geertu> For H3, we always said the upstream default should be the production version +10:11 < geertu> For M3-W, there will be two, so that warrants having both r8a7796 and r8a77961 +10:12 < geertu> Let's stop spinning heads for now... +10:12 < geertu> 3) ELC-E: Do we need/want/have a periperi meeting? +10:13 < wsa> who will be at plumbers? +10:13 < morimoto> no JaPeri +10:13 < uli_> i will +10:13 < pinchartl> I will be at LPC and ELCE +10:13 < jmondi> me 2 +10:14 < geertu> I won't be at LPC, bit I will at ER and ELCE +10:14 < pinchartl> Niklas will attend both too, Kieran will only attend ELCE +10:14 < wsa> I'll be at LPC, the recipes, and ELCE +10:15 < wsa> my gut feeling says, let's have email-only reports in three weeks +10:15 < pinchartl> I think that's best +10:15 < morimoto> +1 +10:15 < wsa> the alternative might be an IRC meeting in 2 weeks +10:15 < pinchartl> for ELCE, do we have topics that require face to face discussions ? on the multimedia side, I don't think we do +10:16 < geertu> pinchartl: same for core, I think, unless I'm missing something +10:16 < wsa> pinchartl: i don't know yet +10:16 < geertu> email-only reports in three weeks is fine for me +10:17 < wsa> okay, email-reports in 3 weeks is it then +10:17 < pinchartl> then we should certainly meet at ELCE, but I don't think we need to reserve a day for full-time meetings :-) +10:17 < pinchartl> a dinner meeting may be more appropriate +10:17 < wsa> pinchartl: same impression here +10:19 < geertu> Monday evening is partner reception (some of us?) +10:19 < wsa> yup +10:19 < geertu> Tuesday evening is attendee reception (all of us?) +10:19 < pinchartl> I won't be free on Tuesday +10:19 < geertu> So that makes Wednesday evening, after the closing game? +10:20 < pinchartl> for preference would be Wednesday indeed +10:20 < geertu> (and I can rail back home on Thursday ;) +10:20 < pinchartl> there may be V4L2 discussions on Thursday, but I don't suppose you'll want to attend :-) +10:23 < geertu> Anything else to discuss (besides multimedia)? +10:24 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20190822-io-chatlog b/wiki/Chat_log/20190822-io-chatlog new file mode 100644 index 0000000..3fa0f3b --- /dev/null +++ b/wiki/Chat_log/20190822-io-chatlog @@ -0,0 +1,117 @@ +09:03 < wsa> neg, jmondi: my I2C BoF has been accepted at Plumbers! +09:04 < wsa> I was waiting for the acceptance to get my free ticket +09:04 < wsa> But they were waiting for my registration to accept the BoF +09:04 < wsa> no free tickets there +09:04 < wsa> We solved that deadlock one day before the deadline :) +09:05 < horms> :) +09:06 < jmondi> wsa: ah! ticket deadlock! +09:07 < jmondi> wsa: happy about the BoF, is it in the schedule already? let me check... +09:07 < jmondi> wsa: had a look at Luca's ATF work? I read the series but refrained from commenting so far +09:07 < wsa> If I had known that in advance I would have bought an early-bird ticket, of course. Well, life... +09:08 < wsa> jmondi: yes, a short look. I still don't like the re-introduction of attach/detach callbacks. I think I proposed an alternative last time, but couldn't find it anynmore :/ Need to rethink +09:09 < wsa> jmondi: nope, it is not in the schedule yet :( +09:09 < wsa> ok, seems JapaPERI is busy +09:09 < wsa> let's start the meeting and hope they will join soon +09:09 < Marex> ATF ? +09:10 < wsa> ATF? +09:10 < wsa> welcome to the IO meeting +09:10 < wsa> here are the collected status updates +09:10 < wsa> A - what have I done since last time +09:10 < wsa> ------------------------------------ +09:10 < wsa> Jacopo (long time no see here :)) +09:10 < wsa> : fixed a bug when reading temperature with a max9611 +09:10 < wsa> Marek +09:10 < wsa> : resubmitted PCIe DMA range handling patch, and revisited PCIe 32bit +09:10 < wsa> limitation with a new approach. +09:10 < wsa> Shimoda-san +09:10 < wsa> : fixed a timeout in the XHCI driver, upported a fix from the BSP for the USBPHY, +09:10 < wsa> removed all Gen3 occurences in the SYS-DMAC part of the SDHI driver, cleaned +09:10 < wsa> up the PWM driver a little, and gave up on using GPIO for zero duty cycle for +09:10 < wsa> PWM (it is a hardware limitation) +09:10 < wsa> Simon +09:10 < wsa> : renamed binding documentation files, fixed a use-after-free case in the RAVB +09:10 < wsa> driver, and limited RAVB link speed for Draak and Ebisu +09:10 < wsa> Ulrich +09:10 < wsa> : sent v3 of changing MTU while RAVB is up, and already prepared v4 +09:10 < wsa> Wolfram +09:10 < wsa> : continued with I2C API changes in core and drivers, fixed a race condition in +09:10 < wsa> Renesas I2C slave drivers, picked up watchdog-handover-from-bootloader again, +09:10 < wsa> reviewed smaller SDHI, media, ravb... patches, continued to organize Plumbers +09:10 < wsa> BoF about I2C addressing problems (now officially accepted) +09:10 < wsa> B - what I want to do until next time +09:10 < wsa> ------------------------------------- +09:10 < wsa> Marek +09:10 < wsa> : wants to keep at the PCI patches +09:10 < wsa> Shimoda-san +09:10 < wsa> : wants to send next version of his MMC/IOMMU/BLOCK series, and update the PWM +09:10 < wsa> driver with the known limitations +09:10 < wsa> Simon +09:10 < wsa> : wants to follow-up on RAVB undocumented register patch in BSP, and keep +09:10 < wsa> renaming binding documentation files +09:10 < wsa> Ulrich +09:10 < wsa> : wants to keep at changing MTU while RAVB is up +09:10 < wsa> Wolfram +09:10 < wsa> : wants to pick up again prototype for a minimal SDHI clock to keep SCC active, +09:10 < wsa> update SDHI manual calibration once we get more infos from HW team, keep at +09:10 < wsa> the I2C API updates, run the BoF at Plumbers +09:11 < wsa> C - problems I currently have +09:11 < wsa> ----------------------------- +09:11 < wsa> Shimoda-san +09:11 < wsa> : is currently blocked by the block layer maintainer (pun intended(tm)) +09:11 < wsa> Wolfram +09:11 < wsa> : found out that handling a watchdog clock when probe fails is surprisingly +09:11 < wsa> difficult +09:13 < wsa> Marex: maybe it helps a little getting attention for your patches if you'd write a cover letter? I kinda missed your new 32-bit PCIE limitation approach because it was described somewhere in patch 2/2 only? +09:14 < geertu> Perhaps we should reconsider and mark the WDT module clock critical, so it will never be disabled? +09:14 < Marex> wsa: it's the usual, Lorenzo takes forever to review stuff +09:15 < Marex> wsa: he is "busy" and last time I checked with him on IRC, ARM is "working on solving this issue" (although, this is the reply I keep getting for months, with zero activity visible from them) +09:15 < wsa> Marex: that's also a part of the equation ;) +09:15 < wsa> Marex: OK. Thanks for the heads up +09:16 < Marex> in particular, Robin (from ARM) is "working" on a fix ... except Robin is even less responsive than Lorenzo +09:16 < wsa> Marex: Still, *I* missed the patch because of that. Just a small feedback. You can take it or not. +09:16 < Marex> funny thing is, now there are at least three SoCs which have the same problem (R-Car3, iMX8 and some broadcom SoCs), ARM claims to know about it, but does nothing +09:16 < Marex> wsa: ah, right +09:17 < wsa> Marex: let's see if we can chat with ARM people at Plumbers... +09:18 < wsa> geertu: I was thinking in a similar direction (critical clock) +09:18 < wsa> geertu: can we do something like: +09:18 < Marex> wsa: I am not going to plumbers +09:18 < wsa> if (clock_enabled_by_fw) clock_is_critical else clock_is_not_critical +09:18 < wsa> ? +09:19 < wsa> Marex: but I am :) +09:19 < Marex> wsa: and is Lorenzo or Robin ? +09:19 < Marex> wsa: those are the people you want to talk to +09:20 < wsa> I didn't find them on the speakers list +09:20 < wsa> but I'll keep my ears open if they are there... +09:23 < wsa> uli_: you are still at the RAVB MTU topic, or? Would be nice to have that task closed somewhen soon. +09:24 < uli_> working on it +09:24 < wsa> horms: has it already been discussed what happens with the periperi-ML from October on? +09:24 < wsa> uli_: Great, thanks! +09:25 < horms> wsa: no, thanks for raising that +09:25 < horms> I'm happy to keep hosting it +09:25 < horms> and ubsubscribe myself +09:25 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi +09:25 < horms> but I'd appreciate it if, eventually, it could migrate somewhere else +09:25 * morimoto we had Renesas inside meeting +09:26 < wsa> hello morimoto-san! +09:26 < morimoto> wsa: hi +09:26 < horms> hi morimoto-san +09:26 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi +09:26 < morimoto> horms: hi +09:27 < shimoda> hi, sorry to delay +09:27 < wsa> horms: okay, so we it would be good if we started looking for a new home for the periperi-ml +09:27 < wsa> hi shimoda-san +09:27 < wsa> horms: thanks for giving us time to look +09:28 < wsa> geertu: can we decide on the wdt clock being critical at runtime? +09:29 < horms> wsa: no rush on my side :) +09:30 < wsa> okay, we can move the wdt discussion to the ML +09:30 < geertu> wsa: You can send a patch to provoke comments +09:32 < wsa> just for completeness: the clock getting disabled has nothing to do with RPM being active or not when bailing out. AFAIU, the genpd disables the device as soon as probe fails with an errno +09:32 < horms> wsa: I guess it would be good to assign another admin/moderator of the ML +09:34 < wsa> horms: my hope would be that we find a new ML before October and, thus, automatically habe a new admin +09:34 < horms> perfect +09:34 < wsa> so, any more questions or comments? +09:35 < wsa> JapaPERI side is happy (IO wise)? +09:36 < wsa> seems like we are ready to move to core +09:36 < wsa> geertu: ready? +09:36 < geertu> Yep. +09:36 < wsa> Have fun! diff --git a/wiki/Chat_log/20190822-mm-chatlog b/wiki/Chat_log/20190822-mm-chatlog new file mode 100644 index 0000000..cd1fc48 --- /dev/null +++ b/wiki/Chat_log/20190822-mm-chatlog @@ -0,0 +1,179 @@ +Multimedia-chat-meeting-2019-08-22 + +10:25 < pinchartl> welcome to the multimedia meeting +10:25 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:25 < pinchartl> * Jacopo +10:25 < pinchartl> Since last meeting: +10:25 < pinchartl> - Tested HDMI audio support on Salvator-XS M3-N +10:25 < pinchartl> - Resumed CMM upstream work +10:25 < pinchartl> - Broke and fixed my NFS setup +10:25 < pinchartl> - Small patches review on linux-media +10:25 < pinchartl> - Periject task update +10:25 < pinchartl> Until next meeting: +10:25 < pinchartl> - Re-send CMM support +10:25 < pinchartl> Issues and blockers: None +10:25 < pinchartl> jaany comment ? +10:26 < pinchartl> no, not ja +10:26 < morimoto> jmondi: thank you for HDMI sound testing ! +10:26 < jmondi> ahem +10:26 < pinchartl> jmondi: any comment ? :-) +10:26 < jmondi> no comments, but nice name, thanks +10:26 < jmondi> morimoto: you're welcome! +10:27 < jmondi> pinchartl geertu uli_ thanks for CMM comments, I'll resubmit a new version soon +10:27 < pinchartl> thank you +10:27 < pinchartl> * Kieran +10:27 < pinchartl> Since last meeting: +10:27 < pinchartl> - GMSL review (Add MAX9286 driver with single camera support) +10:27 < pinchartl> - Summer holiday +10:27 < pinchartl> Until next meeting: +10:27 < pinchartl> - Summer holiday +10:27 < pinchartl> Issues and blockers: None +10:28 < pinchartl> (kbingham is excused) +10:28 < pinchartl> * Morimoto-san +10:28 < pinchartl> Since last meeting: +10:28 < pinchartl> - ALSA SoC framework cleanup +10:28 < pinchartl> Posting more patches (in small batches) and resending pending patches. +10:28 < pinchartl> Until next meeting: +10:28 < pinchartl> - Continue progressing cleanup patches +10:28 < pinchartl> More than 200 patches to be posted. +10:28 < pinchartl> Issues and Blockers: +10:28 < pinchartl> - Large number of cleanup patches to upstream +10:28 < pinchartl> The cleanup patches are not complex from a technical point of view, but +10:28 < pinchartl> given the large quantity review, and thus merging, is slow. +10:28 < pinchartl> morimoto: any comment ? +10:29 < morimoto> no comment, thanks +10:29 < pinchartl> regarding the review speed and the large number of patches, I haven't checked the patches themselves, but maybe it would be possible to squash some of them together if they're small and related to the same topic ? +10:30 < pinchartl> for instance, does ALSA require one patch per driver when you refactor APIs ? (or maybe your patches are already squashed and you just have a very large number of changes) +10:30 < morimoto> Yeah, but current patches are for framework, not for driver. +10:31 < morimoto> Thank you for your advice +10:31 < morimoto> too many very small cleanup patches :) +10:32 < pinchartl> ok :-) +10:32 < pinchartl> good luck then, or as we say in Finnish, tsemppiä ! +10:32 < morimoto> Thanks :) +10:33 < pinchartl> * Laurent +10:33 < pinchartl> Since last meeting: +10:33 < pinchartl> - Sent pull requests for v5.3 fixes and v5.4 +10:33 < pinchartl> - FCP version read at probe time +10:33 < pinchartl> - CMM & VI patch review +10:33 < pinchartl> - Assisted Fabrizio with LVDS dual link support for r8a774c0-ek874.dts +10:33 < pinchartl> - DRM bridge API refactoring work with Boris Brezillon +10:33 < pinchartl> Until next meeting: +10:33 < pinchartl> - DU group refactoring +10:33 < pinchartl> Issues and Blockers: None +10:33 < pinchartl> (I had forgotten myself in alphabetical order) +10:33 < pinchartl> and I also forgot in the tasks since last meeting +10:34 < pinchartl> - Investigated HDMI output issues on Lager +10:34 < pinchartl> any question ? +10:34 < jmondi> are the DU group refactoring patches out? +10:34 < jmondi> should I take them into account for CMM ? +10:35 < pinchartl> let me check +10:36 < jmondi> thanks +10:36 < pinchartl> [PATCH v3 00/10] drm: rcar-du: Rework CRTC and groups for atomic commits +10:36 < pinchartl> I'd appreciate if you could take a look to at least be aware of what's going on +10:36 < pinchartl> but I think it's too early to rebase on top of that +10:38 < jmondi> pinchartl: sure +10:38 < jmondi> I'll have a look indeed +10:38 < pinchartl> thank you +10:38 < pinchartl> * Niklas +10:38 < pinchartl> Since last meeting: +10:38 < pinchartl> - [PATCH v3] dt-bindings: rcar-{csi2,vin}: Rename bindings documentation files +10:38 < pinchartl> - [PATCH v2 0/6] rcar-vin: Add support for V4L2_FIELD_ALTERNATE +10:38 < pinchartl> - [PATCH] rcar-vin: Report correct image stride +10:38 < pinchartl> - [PATCH 0/2] max9286: Add MAX9286 driver with single camera support +10:38 < pinchartl> Until next meeting: +10:38 < pinchartl> - Keep cleaning up VIN and get out-of-tree patches merged. +10:38 < pinchartl> - Keep pushing for a GMSL progress. +10:38 < pinchartl> Issues and blockers: None +10:39 < pinchartl> (neg is excused, he's loading a moving truck) +10:39 < pinchartl> * Simon + Kaneko-san +10:39 < pinchartl> Since last meeting: +10:39 < pinchartl> - [PATCH] dt-bindings: sh-mobile-ceu: Rename bindings documentation file +10:39 < pinchartl> Will drop the bindings instead as the driver was removed. +10:39 < pinchartl> Until next meeting: +10:39 < pinchartl> - Continue bindings documentation filename cleanup +10:39 < pinchartl> - Follow up on BSP patch triage with Laurent +10:39 < pinchartl> Issues and Blockers: None +10:39 < pinchartl> horms: any comment ? +10:39 < pinchartl> how would you like to proceed for the BSP patch triage follow up ? +10:39 < horms> We could chat here, perhaps after this meeting. Or just continue the email thread. +10:40 < horms> No other comment :) +10:41 < pinchartl> I'm available this afternoon but not right after this meeting I'm afraid +10:41 < pinchartl> would you be able to summarize the status by e-mail ? we can then discuss it on IRC if needed +10:41 < jmondi> horms: pinchartl please keep me in the loop for ebisu upporting as I have the board if you need testing/support +10:42 < jmondi> specifically on the puzzling: "d3394635755093f8539acfdbaf932a164ec59533 # arm64: dts: 8a77990-ebisu: Enable simultaneous output of VGA and HDMI" +10:42 < horms> pinchartl: my email from yesterday does sumarise the status from my pov +10:42 < horms> jmondi: sure will do +10:43 < jmondi> horms: thanks, do you have the board ? +10:43 < horms> Yes :) +10:43 < pinchartl> horms: ok, I'll reply to the e-mail this afternoon, and if needed will ping you on IRC +10:44 < pinchartl> thank you +10:44 < horms> pinchartl: thanks, good plan +10:44 < jmondi> great, just let me know then if you need any support in testing +10:44 < pinchartl> * Ulrich +10:44 < pinchartl> Since last meeting: None +10:44 < pinchartl> Until next meeting: None +10:44 < pinchartl> Issues and Blockers: None +10:44 < pinchartl> uli_: is that correct ? +10:44 < uli_> yes +10:44 < horms> jmondi: my main problem with thesting that is getting some cables. And a test scenario +10:44 < pinchartl> thank you +10:45 < pinchartl> any other question or comment for the multimedia meeting, or any discussion topic ? +10:45 < morimoto> I have 1 +10:46 < jmondi> pinchartl: I have a small one too +10:46 < pinchartl> morimoto: please go ahead +10:46 < morimoto> thanks :) +10:46 < jmondi> horms: I do have cables, but to test simulatanous output I was wondering as well how to do so.. I toyed myself with the idea that we need to write a test to add to the du-test suite to do so +10:47 < morimoto> I had asked about 8ch camera rebase for v4.x base kernel at OSS-J. +10:47 < morimoto> "rebase" request became fake, but I believe "upstream" request is still alive. +10:47 < morimoto> But, is this correct ? +10:47 < morimoto> It is not super rush, but BSP team want to use it as upstream base. +10:47 < horms> jmondi: perhaps we can chat offline about that part +10:48 < jmondi> horms: yes, ping me whenever +10:48 < pinchartl> morimoto: yes, we dropped the rebase (after unfortunately spending some time on it) but will continue with upstream development +10:48 < pinchartl> I believe Niklas has sent a development plan proposal, right ? +10:48 < morimoto> Yes +10:48 < morimoto> OK, thanks +10:49 < morimoto> I guess it takes long term ? +10:49 < pinchartl> it won't be done tomorrow :-) but I want to focus our efforts on it. very short term I would like to get pending patches merged for DU and CMM, but apart from that I want to focus on GMSL +10:50 < morimoto> Ohh, not tomorrow orz +10:50 < morimoto> joke ;) +10:50 < jmondi> morimoto: :) +10:50 < morimoto> OK, thanks +10:50 < morimoto> that's all from me. thanks +10:50 < jmondi> morimoto: any feedback on the proposed plan, and on the anticipated interest for rdacm21 +10:50 < jmondi> ? +10:51 < morimoto> they want to use rdacm21 camera, thanks +10:52 < morimoto> No big feedback. +10:52 < morimoto> They are worry about upstream base 8ch camera. +10:52 < morimoto> because they are using old kernel base 8ch camera (= soc-camera) +10:53 < morimoto> and they need to update kernel version. +10:53 < jmondi> and we killed soc-camera in newer kernel, I see +10:53 < morimoto> jmondi: yes, it is the reason. +10:53 < jmondi> well, the fact they want to use rdacm21 is a feedback already +10:55 < pinchartl> thank you +10:55 < pinchartl> jmondi: you had a question too ? +10:55 < jmondi> let's keep pushing to have the max9286 driver merged then! thanks +10:55 < jmondi> yes, small one +10:55 < jmondi> I sent a periject patch to track CMM work +10:55 < jmondi> who collects them ? (I know the question has been asked multiple times already) +10:56 < morimoto> good question :) +10:56 < jmondi> :) +10:56 < morimoto> I think all member can push, but I don't know the rule +10:56 < pinchartl> I don't plan to collect them, so from my point of view you should push it :-) +10:57 < morimoto> after review ? or without posting to ML ? +10:57 < pinchartl> after review +10:58 < morimoto> OK, good to know +10:58 < pinchartl> I think they should be posted to the mailing list so that everybody can see what is happening +10:58 < morimoto> push it after getting leader's Ack is more nice +10:58 < pinchartl> I'll try to ack them +10:58 < pinchartl> but if there's no review feedback within a few days, I think the changes can be pushed +10:59 < jmondi> fine then +10:59 < jmondi> I'll wait for an ack for a few more days... now that you know the patch is there, could you have a brief look ? +10:59 < jmondi> pinchartl: ^ +10:59 < jmondi> that's ll from me! +11:01 < pinchartl> jmondi: done +11:01 < pinchartl> any other question or discussion topic ? +11:01 < morimoto> nothing from me ! +11:03 < pinchartl> then this meeting is adjourned +11:03 < pinchartl> thank you everybody for attending +11:03 < pinchartl> and have a nice day diff --git a/wiki/Chat_log/20191010-core-chatlog b/wiki/Chat_log/20191010-core-chatlog new file mode 100644 index 0000000..610667c --- /dev/null +++ b/wiki/Chat_log/20191010-core-chatlog @@ -0,0 +1,119 @@ +09:12 < geertu> Welcome to today's Core Group Chat Meeting! +09:12 < geertu> Agenda: +09:12 < geertu> 1. Status Updates +09:12 < geertu> 2. Discussion Topics +09:12 < geertu> Topic 1. Status updates +09:12 < geertu> A) What have we done since last time: +09:12 < geertu> Marek worked on U-Boot (SH4 build with new binutils, PCI on r2dplus, +09:12 < geertu> SDHI regulator delay, USB storage transfer length for broken sticks) and +09:12 < geertu> Linux (PCI DMA, incl. 32-bit limitation). +09:12 < geertu> Niklas struggled with a merge window regression on Koelsch. +09:12 < geertu> Shimoda-san submitted rcar-dmac and ipmmu patches, and pinged the BSDL +09:12 < geertu> files. +09:12 < geertu> Geert presented at and attended Embedded Recipes in Paris, posted +09:12 < geertu> initial R-Car M3-W+ support, investigated merge window regressions, and +09:12 < geertu> reviewed lots of RZ/G2N patches. +09:13 < geertu> B) What we plan to do till next time: +09:13 < geertu> Marek plans to submit U-Boot USB storage fixes/improvements. +09:13 < geertu> Shimoda-san plans to ping the BSDL files, enable ipmmu for sdhi, and +09:13 < geertu> review R-Car M3-W+ and RZ/G2N patches. +09:13 < geertu> Geert plans to look into timer_of conversion, +09:13 < geertu> Laurent, Niklas, Ulrich, and Geert (anyone else?) will attend ELC-E. +09:13 < Marex> morimoto: please forward my thanks to shimoda-san /wrt the BSDL files :) +09:14 < geertu> C) Problems we have currently: +09:14 < geertu> Kaneko-san and Simon left the team. +09:14 < geertu> A big thanks to them for their work during the past years! +09:15 < geertu> --- +09:15 < geertu> Anything I missed? +09:17 < neg> Not that I can think of +09:17 < geertu> Topic 2. Discussion Topics +09:17 < geertu> Anything to discuss from your side? Special requests from Tokyo? +09:21 * patersonc will attend ELC-E +09:21 * Marex will attend ELC-E +09:21 < pinchartl> who won't attend ELC-E ? +09:22 < wsa> JapaPERI :( +09:22 < morimoto> \me not attend :( +09:22 < Marex> no morimoto no good ELCE :'-( +09:22 < patersonc> pinchartl: Anyone else from Renesas Europe? +09:23 < morimoto> Marex: Hehe :) Thanks +09:23 < jmondi> geertu: I'll be at ELC-E (I just noticed I was not listed) +09:23 < morimoto> wsa: I can access to ML management page, but don't know how to add new address. I will ask to shimoda-san tomorrow +09:23 < pinchartl> Kieran won't be able to make it due to prioritising his baby project +09:24 < wsa> BTW, next OSSJ is listed for September 15 – 16 in the LF events calendar +09:24 < wsa> morimoto: thank you! +09:24 * wsa will be at ELCE, too, of course +09:24 < Marex> jmondi: listed where ? +09:25 < geertu> Marex: in the B) above +09:25 < pinchartl> wsa: probably due to the olympics. having OSSJ just before would have been quite impractical +09:25 * pinchartl checks the weather in Okinawa for September +09:25 < jmondi> Marex: in Geert's message +09:26 < wsa> pinchartl: I know. What I heard, it wasn't clear if a new date or a new city will be chosen. I am happy it is a new date and the same city :) +09:26 < jmondi> I really risked to not be registered, as I ignored multiple times the LF emails requesting me to register as speaker, as my brain filter LF emails as 'spam' +09:26 < Marex> wsa: does that mean we need some earlier hanameeting ? +09:27 < geertu> jmondi: So you won't be giving the Airbus talk? Pity +09:27 < Marex> jmondi: ah ok +09:27 < jmondi> geertu: unfortunately not +09:27 < wsa> Marex: I will go to Japan next year again, but unlikely I will go twice +09:27 < Marex> pinchartl: okinawa would've been AWESOME +09:28 < pinchartl> wsa: I would have preferred okinawa :-) +09:28 < geertu> https://events.linuxfoundation.org/about/calendar/?_sft_lfevent-country=japan says Tokyo +09:28 < pinchartl> Marex: https://weatherspark.com/m/142278/8/Average-Weather-in-August-in-Okinawa-Japan#Sections-Humidity +09:29 < pinchartl> only "oppressive" in September, not "miserable" :-) +09:29 < patersonc> It's a shame that OSS-J will be so close to ELC-E 2020 though +09:29 < wsa> OSSJ@Okinawa: "The talk from Laurent Pinchart has to be cancelled because he went to the beach and we can't find him anymore" +09:29 < pinchartl> (well, less chances of miserable) +09:29 < Marex> pinchartl: lol +09:29 < pinchartl> wsa: what's wrong with giving the talk on the beach ? +09:29 < patersonc> A lot of people may only chose 1. The same happened this year with OSS-J and ELC-NA +09:30 < geertu> pinchartl: That's August? Will spend the whole August (and Sep 1-4) in Okinawa? +09:30 < geertu> s/1-4/1-14/ +09:30 < pinchartl> geertu: you're tempting me +09:30 < Marex> pinchartl: https://weatherspark.com/m/143438/7/Average-Weather-in-July-in-Kyoto-Japan wow , Kyoto is only oppresive :-O +09:30 < Marex> pinchartl: I can't imagine what miserable must be like ... +09:32 < geertu> Note that that website calls early April in BE "very cold" +09:32 < Marex> geertu: well, early Feb. in BE is miserable :) +09:32 < geertu> Marex: Fortunately you have FOSDEM to keep your heart warm ;-) +09:35 < geertu> Anything else to discuss? +09:35 < geertu> ELC-E dinner plan on Wed eve? +09:36 < wsa> There is a " +09:36 < wsa> Desserts & Drinks Attendee Reception +09:36 < wsa> " +09:36 < wsa> on Wed evening +09:36 < pinchartl> doesn't sound good +09:36 < pinchartl> they expect us to finish dinner at 20:00 to attend the reception +09:36 < patersonc> It's not a good plan +09:36 < pinchartl> Lyond doesn't eat that early +09:37 < pinchartl> I plan to skip the reception +09:37 < wsa> Tue evening still might be better +09:37 < pinchartl> I'm busy on Tuesday I'm afraid +09:37 < patersonc> After the Tech Showcase? +09:38 < patersonc> Just skip the desert reception thingy +09:38 * patersonc pretends that he's invited ;) +09:39 < geertu> "When sessions conclude, attendees are encouraged to explore Lyon, known as the Capital of Gastronomy, to enjoy some of the famous local restaurants before reconvening at our late-night Desserts & Drinks Attendee Reception! " +09:39 < geertu> Indeed weird if you have to finish by 20h00 +09:39 < pinchartl> they have a weird concept of late night +09:39 < Marex> pinchartl: 3am ? :) +09:39 * geertu wonders how the LF people survived Barcelona +09:40 < Marex> geertu: that +09:40 < neg> I'm fine in skipping the reception in favor of a nice proper periperi dinner +09:41 < Marex> ACK +09:41 < geertu> Yah, usually it;s hard to get food during those mega-OSS events, and this time they explicitly tell you to eat first +09:41 < wsa> I'd still prefer Tue after the showcase, but will not block Wed evening if you all are happy with it +09:42 * geertu wonders if he has to choose between wsa and pinchartl +09:42 < patersonc> Don't the have the usual attendee reception on Tues? +09:42 < patersonc> *they +09:42 < geertu> Both Tue and Wed are fine for me +09:42 < wsa> patersonc: https://osseu19.sched.com/ +09:42 < geertu> patersonc: They have, until 19h15 +09:43 < patersonc> Gotcha +09:43 < geertu> "Join your fellow attendees after sessions conclude for drinks, canapes, networking and the opportunity to check out the latest and greatest sponsor products and technologies! +09:43 < geertu> " +09:43 < geertu> canapes? +09:43 < patersonc> Huzzah +09:43 < patersonc> Including Edge AI running on RZ/G2 :) +09:44 < geertu> patersonc: I'm sold +09:44 < pinchartl> wsa: do you still need time to read the I/O status e-mails, in which case I could proceed with MM ? :-) +09:46 < wsa> I am done preparing +09:46 < wsa> I think IO will be super fast +09:47 < geertu> OK +09:47 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20191010-io-chatlog b/wiki/Chat_log/20191010-io-chatlog new file mode 100644 index 0000000..c785ab3 --- /dev/null +++ b/wiki/Chat_log/20191010-io-chatlog @@ -0,0 +1,150 @@ +09:02 < wsa> welcome everyone to the IO meeting! +09:03 < wsa> 1st topic is the missing status updates ;) I didn't get either Geert's reminder nor any update. Is this because of the mailing list switch? +09:03 < wsa> Did you guys get it? +09:04 < neg> Yes +09:04 < marex-cloud> Yes +09:04 < morimoto> Yes +09:04 < geertu> yes +09:04 < uli_> yes +09:04 < wsa> Ha +09:04 < morimoto> Subject: [periperi] 2019-10-10 - Group meeting - Infos & Call for updates +09:04 < morimoto> +09:04 < morimoto> Date: Wed, 9 Oct 2019 10:36:30 +0200 +09:04 < morimoto> +09:05 < wsa> Interesting, I only got the one from Shimoda-san because I was on CC there +09:05 < wsa> morimoto: can you check if I am subscribed to the new ML? +09:05 < wsa> It came all via the new ML? +09:06 < geertu> wsa: You also haven't received "[periperi] This is a test email of a new "periperi" mailing list +09:06 < geertu> " from Shimoda-san, I guess? +09:07 < neg> wsa: I have bounced the status update thread to you +09:07 < wsa> geertu: nope :( +09:07 < geertu> Oops +09:07 < geertu> wsa: Nor Kieran's announcement... +09:08 < morimoto> wsa: Now I'm checking ML, indeed you are not listed +09:08 < wsa> darn, seems i missed some stuff +09:08 < morimoto> Which email address you want to register ? +09:08 < morimoto> OK :) +09:09 < wsa> wsa@the-dreams.de +09:09 < wsa> wsa+renesas@sang-engineering.com +09:10 < wsa> neg: thanks for bouncing the mails +09:10 * Marex is here +09:10 < Marex> good morning +09:10 < wsa> May I suggest to switch to the core meeting now, so I have some time to read the status updates? +09:11 < geertu> Fine for me. I guess everyone is here, except for dammsan? + +... + +09:47 < wsa> IO meetings part 2 +09:47 < wsa> I have read the status updates but not combined them into one report yet +09:48 < wsa> BTW here is mine (can't send mails to ML yet): +09:48 < wsa> A) +09:48 < wsa> * refactoring my I2C API patches because of a missing error condition +09:48 < wsa> * went to Kernel recipes and gave a talk about kernel workflow scalability issues +09:48 < wsa> * also talked with Vladimir about I2C multiple times +09:48 < wsa> * picked up again prototype for a minimal SDHI clock to keep SCC active +09:48 < wsa> * reviewed and/or tested SDHI, MMCIF, RIIC & I2C patches +09:48 < wsa> * sent out a marriage request which got accepted +09:48 < wsa> B) +09:48 < wsa> * send out the I2C API conversion patches +09:48 < wsa> * finish SCC clock handling for SDHI +09:48 < wsa> * visit ELCE and give a talk +09:48 < wsa> * update SDHI manual calibration once we get more infos from HW team +09:48 < wsa> * plan a huge party next year +09:48 < wsa> C) +09:48 < wsa> * error condition for minimal SDHI clock is hard to trigger +09:48 < wsa> Marex: thank you for all the PCI work! and congrats for being the new maintiner ;) +09:49 < jmondi> wsa: could you tell us a bit of what you discussed with Vladimir +09:49 < wsa> uli_: i think increasing the buffer size by 30% percent pays off if it saves us all the refactoring complexity +09:49 < jmondi> (and which party are you organizing :) +09:50 < wsa> uli_: have you checked with davem if this is acceptable to him? +09:50 < wsa> jmondi: there is a hint in A) which party it could be ;) +09:50 < uli_> wsa: not yet. i want to send a prototype for local review before engaging in more public discussion +09:50 < wsa> uli_: OK +09:51 < jmondi> wsa: oh man! I missed that! that's big news! +09:51 < geertu> wsa: Congrats! +09:51 < jmondi> congratualtions! +09:51 < neg> wsa: congratulations on your accepted requests ;-) +09:52 < wsa> jmondi: I kinda convinced him about a few things like I am okay with having two ways to address the same client (like 0x50@bus 5 and alias 0x12@ bus 1) +09:52 < pinchartl> wsa: I'm sorry, but are you sure you got it right ? I'm pretty sure I haven't received any request :-) +09:52 < geertu> neg: wsa wrote "request", i.e. singular +09:53 < wsa> Thanks everyone! :D +09:53 < wsa> geertu: Actually, we made multiple requests to each other :) (but always the same girl and me ;)) +09:54 < Marex> wsa: uhhhh ... yeah +09:54 < pinchartl> wsa: did you send it as a git pull request ? :-) +09:54 < wsa> pinchartl: Never been more sure. Sorry ;) +09:55 < jmondi> broadcast marriage request.. seems like a strategy that could work +09:55 < wsa> uuuh, I see quite some merge conflicts there +09:56 < geertu> jmondi: RMS didn't go that far... +09:56 < wsa> (trust someone with experiences in open relationships ;)) +09:57 < jmondi> wsa: that's the kind of merge conflicts that seems hard to solve :) +09:57 < jmondi> surely they need the --patience switch +09:57 < wsa> jmondi: but you surely learn something on the way +09:57 < jmondi> I would not use 'octopus' as merge strategy +09:57 < wsa> RTOFL +09:57 < jmondi> geertu: you're mean +09:57 < jmondi> :) +09:59 < morimoto> \me I finally could understand about party +09:59 < morimoto> wsa: congratulations !! +09:59 < wsa> Thank you everyone for your congratulations! :) +10:00 < wsa> let me just finish my summary about my talks with Vladimir and then I think the IO meeting is done +10:01 < wsa> So, Vladimir wanted me to review his patches as-is. I told him that I don't think they are a good representation of the actual HW. +10:01 < Marex> wsa: congratulations! +10:01 < Marex> wsa: I had some "fun" with FPDlink this week too +10:01 < Marex> wsa: I studied the datasheets quite thoroughly, there's a LOT of weird junk +10:01 < Marex> wsa: and yes, it can do multi-master on _both_ ends of the link +10:02 < wsa> I told him that we worked out in Lisbon that the key difference between GMSL and FPD (when it comes to the I2C core) is when they need the dynamically assigned address +10:02 < wsa> probe-time vs. device creation time +10:03 < wsa> I first want to think about this. To understand what could be generic and what should be specific +10:03 < jmondi> did you get why he -really- does not want to create adapters for the remote devices ? +10:03 < wsa> And then, we can talk about implementations. +10:04 < Marex> wsa: FYI, one funny observation which might be useful for you +10:04 < wsa> He wants to hardcode everything because it is most simple +10:04 < Marex> wsa: the FPDlink de-serializer has actual PHYSICAL I2C master in it +10:05 < Marex> wsa: so, when you talk to the serializer (connected to your CPU), it just listens on the I2C bus and does some marshalling, but on the other side, the deserializer is a kind-of separate I2C bus altogether +10:05 < wsa> jmondi: he wants the deserializer to have 10 addresses and that's it. No locking issues, not much new code needed +10:05 < Marex> it can even run at different clock rate (!) +10:05 < wsa> Marex: thanks +10:05 < Marex> wsa: just dumping the info while it's still hot in cache +10:05 < wsa> Marex: yes, the fact that it can run at a different clock rate was used as an argument that it really should be a seperate bus +10:06 < Marex> wsa: well since it's an actual full I2C master, it probably should ? +10:06 < wsa> Marex: talk to Vladimir about that :) +10:06 < Marex> wsa: is he gonna be at ELCE ? +10:06 < Marex> wsa: CC me on that discussion +10:06 < wsa> i think so +10:07 < jmondi> Marex: you have a serializer connected to your CPU and a remote deserializer ? +10:07 < jmondi> I assume you're working with displays then ? +10:07 < wsa> Marex: will do +10:08 < Marex> jmondi: yes +10:08 < jmondi> that would be interesting to explore, as we're considering the case where the deserializer is the local end +10:08 < jmondi> local = connected to the CPU +10:08 < Marex> jmondi: I have display + i2c touch and a few other remote components +10:09 < jmondi> https://lore.kernel.org/patchwork/cover/1030123/ +10:09 < jmondi> that's the latest proposal from Luca. I think the discussion has some pointers, and in the end there are links to the notes taken during the BoF by Kieran and Luca +10:11 < Marex> jmondi: well, you should consider using it the other way around too :) +10:12 < Marex> wsa: there's another bizzare thing, FPDlink supports hotplug :-D +10:12 < jmondi> Marex: ah yes indeed, I think nobody in that discussion has yet had a use case for this +10:12 < Marex> wsa: you can yank the cable out and you get hotplug event on the controller +10:12 < Marex> jmondi: with display, that might actually make a bit of sense +10:13 < wsa> luca wants hotplug +10:13 < wsa> however, this is probably more a v4l2 thing than I2C +10:13 < wsa> however, no need to respin the whole discussion here +10:14 < wsa> the thread is out there +10:14 < Marex> I want to believe +10:14 < wsa> and there will likely be another one +10:14 < jmondi> x-files music plays in the back of my head now +10:14 < wsa> anything else we need to discuss right now? +10:15 < jmondi> wsa: just to know if you have plans to start looking into i2c address assignment, and if you need support +10:15 < jmondi> but it can be taken offline to the mailing list maybe +10:15 < wsa> jmondi: i got 5 days as an add. task for it \o/ +10:16 < wsa> I will think about the probe-timing vs. device-creation timing +10:16 < wsa> first +10:16 < wsa> I will let you know if I need add. thoughts and/or input +10:16 < jmondi> wsa: good! I think we really need to get a spin for having at least max9286 driver in, and additional work around it might help +10:16 < Marex> wsa: luckily, the FPDlink can also work in full passthrough mode +10:17 < wsa> It is an action item +10:17 < jmondi> wsa: thanks! +10:17 < wsa> yes, sure thing. and thanks for Renesas to fund this add. task! +10:17 < wsa> with that, I think we are done +10:18 < geertu> jmondi: Any plans to fix max9611? +10:18 < wsa> pinchartl: your turn now! +10:18 < pinchartl> thank you diff --git a/wiki/Chat_log/20191010-mm-chatlog b/wiki/Chat_log/20191010-mm-chatlog new file mode 100644 index 0000000..d14fd99 --- /dev/null +++ b/wiki/Chat_log/20191010-mm-chatlog @@ -0,0 +1,144 @@ +Multimedia-chat-meeting-2019-10-10 + +10:18 < pinchartl> welcome to the multimedia meeting +10:18 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:18 < pinchartl> * Jacopo +10:18 < pinchartl> Since last meeting: +10:18 < pinchartl> - Restarted work on CMM +10:18 < pinchartl> Ezequiel (Collabora) is developing a very similar feature for Rockchip, +10:18 < pinchartl> and Sean's review on his patches will be taken into account for CMM. +10:18 < pinchartl> Until next meeting: N/A +10:18 < pinchartl> Issues and blockers: None +10:18 < pinchartl> jmondi: any comment ? +10:19 < jmondi> pinchartl: yes, quick one +10:19 < jmondi> Ezequiel has moved all their gamma LUT handing to atomic_enable/begin +10:20 < jmondi> Sean suggested that, and that removes the need to restore the color_management_changed flag after suspend as we do now +10:20 < jmondi> I plan to do the same for CMM, but before going down that path I would like your opinion there +10:20 < pinchartl> that seems wrong, the gamma LUT should be modifyable at runtime +10:20 < jmondi> [PATCH v4 0/3] RK3288 Gamma LUT +10:20 < pinchartl> why did they do that ? +10:21 < jmondi> I'm not sure I did completely understood Sean's reply to v3 +10:21 < jmondi> I asked eze too yesterday, but then I had to run +10:21 < pinchartl> could you check it with them ? please raise the issue of modifying the gamma table at runtime +10:22 < jmondi> also, they moved everything to crct_enable/begin, while we had that in the commit_tail helper +10:22 < jmondi> so the CMM would be set per-CRTC ? +10:22 < pinchartl> to determine if it has to be supported (and if not, why, and where that is documented) +10:22 < jmondi> I will keep pressing Ezequiel on that +10:22 < jmondi> it's fun how many corner cases we're hitting with CMM +10:22 < jmondi> well, fun.. +10:23 < pinchartl> it doesn't matter if it's set in the atomic tail handler or the CRTC operations, that's not relevant +10:23 < pinchartl> what is relevant is if modifying the gamma LUT without a modeset needs to be supported +10:23 < jmondi> ah well, no +10:23 < jmondi> we do +10:23 < jmondi> for_each_old_crtc_in_state +10:24 < jmondi> so we go through each crtc anyhow +10:24 < pinchartl> sure, we have to as gamma tables are per CRTC +10:24 < jmondi> indeed, my bad, I got confused +10:25 < jmondi> I'll try to know more +10:25 < pinchartl> so please check with them before changing anything, and please let me know +10:25 < pinchartl> thank you +10:25 < jmondi> you'll be cc-ed +10:26 < pinchartl> ok. I don't plan to participate in the discussion though, please make sure to drive it +10:26 < pinchartl> next, Kieran, who is AWOL due to having a new baby +10:27 < pinchartl> (what wouldn't people do to have a few weeks of off ? :-)) +10:27 < pinchartl> * Laurent +10:27 < pinchartl> Since last meeting: +10:27 < pinchartl> - CMM & other patches review +10:27 < pinchartl> - Attended XDC (X.Org Developer's Conference) +10:27 < pinchartl> Discussed, among other topics, a new kernel API for cameras, +10:27 < pinchartl> interoperability between displays and cameras, fences for V4L2, buffer +10:27 < pinchartl> allocator API with constraint resolution, ... +10:27 < pinchartl> Until next meeting: +10:27 < pinchartl> - CMM review to finish the upstreaming +10:27 < pinchartl> - DU group refactoring +10:27 < pinchartl> - Attending ELC-E (with V4L2 workshop) +10:27 < pinchartl> Issues and Blockers: None +10:27 < pinchartl> any question ? +10:27 < pinchartl> * Morimoto-san +10:27 < pinchartl> Since last meeting: +10:27 < pinchartl> - ALSA SoC framework cleanup +10:27 < pinchartl> Posted patches have been accepted, posted next set. +10:27 < pinchartl> - ALSA SoC small bug fixes +10:27 < pinchartl> Until next meeting: +10:27 < pinchartl> - Continue progressing cleanup patches +10:27 < pinchartl> Issues and Blockers: +10:27 < pinchartl> - Can't test Intel-related changes +10:27 < pinchartl> Some of the cleanup patches are related to an Intel-specific features. +10:27 < pinchartl> The code is compile-tested only due to lack of a test platform. +10:27 < pinchartl> - Large number of cleanup patches to upstream +10:27 < pinchartl> ALSA SoC is too complex today, hence the need for a large cleanup, with +10:27 < pinchartl> more than 500 local patches still pending. The next step will focus on +10:27 < pinchartl> soc-pcm that supports flexible CPU/codec connections, and this area is +10:27 < pinchartl> too complex. +10:27 < pinchartl> morimoto: any comment ? +10:28 < morimoto> Intel said that they are using Github to test hardware +10:28 < morimoto> He can test it +10:29 < pinchartl> ? how does that work ? +10:29 < morimoto> I'm not sure detail, but if he push patches to Github, +10:29 < morimoto> test script (?) works automatically +10:30 < morimoto> Some magical machine is working +10:30 < pinchartl> I would have assumed them to use gitlab for self-hosted CI integration +10:30 < morimoto> And it seems my patches were OK +10:30 < pinchartl> that's good news :-) +10:30 < pinchartl> so it's not an issue anymore ? +10:30 < morimoto> yes :) +10:30 < morimoto> Yeah, thanks +10:31 < pinchartl> thank you +10:32 * pinchartl wonders if ALSA SoC cleanup is Morimoto-san's secret plan to boost his kernel commits statistics ;-) +10:32 < pinchartl> * Niklas +10:32 < pinchartl> Since last meeting: +10:32 < pinchartl> - [PATCH 0/2] rcar-vin: Cleanup how subdevice format is handled +10:32 < pinchartl> - [PATCH v2 0/2] rcar-vin: Support V4L2_FIELD_SEQ_{TB,BT} +10:32 < pinchartl> - Attended LPC +10:32 < pinchartl> Until next meeting: +10:32 < pinchartl> - Attend ELC-E and join the V4L2 workshop +10:32 < pinchartl> - Keep pushing VIN patches unlocked by recent acceptance of cleanup patches +10:32 < pinchartl> Issues and blockers: None +10:32 < pinchartl> neg: any comment ? +10:32 < neg> No comment, thanks +10:33 < morimoto> pinchartl: not *secret* but *official* plan :) +10:33 < pinchartl> :-) +10:33 < pinchartl> * Ulrich +10:33 < pinchartl> Since last meeting: +10:33 < pinchartl> - Patch review +10:33 < pinchartl> Until next meeting: N/A +10:33 < pinchartl> Issues and Blockers: None +10:33 < pinchartl> uli_: any comment ? +10:33 < uli_> nope +10:34 < pinchartl> thank you +10:34 < pinchartl> any discussion topic ? +10:35 < neg> Anything to plan/bring to ELC-E ? +10:35 < wsa> I could bring my Gen2 Alt board for Kieran if he still needs that? +10:36 < neg> I'm thinking if we need some face-to-face talks or exchange of hardware. I take it we will not have a periperi meeting day ? +10:36 < pinchartl> wsa: could you check with him ? +10:36 < pinchartl> kbingham[m]: ^^ +10:36 < geertu> wsa: kbhingham won't be there +10:36 < pinchartl> geertu: of course. stupid me +10:36 < wsa> right +10:36 < pinchartl> Kieran can't get the hardware if doesn't attend +10:36 < geertu> and the goods may receive increased scrutiny at border control +10:36 < pinchartl> neg: that was my next question. when will the next meeting be ? +10:37 < pinchartl> 3 weeks from now is October the 31st +10:37 < pinchartl> it will collide with the gstreamer conference for Jacopo and me +10:37 < wsa> that's elce time +10:37 < pinchartl> and I believe Niklas won't be back home yet either +10:38 < neg> I will go back home on the 3rd of Nov +10:38 < pinchartl> should we push it back by one week ? +10:38 < wsa> yup +10:38 < pinchartl> so November 7th, same time as usual ? +10:38 < wsa> works for me +10:38 < pinchartl> we will have switched to winter time +10:39 < geertu> pinchartl: Will we? ;) +10:39 < pinchartl> won't we ? +10:39 < morimoto> not in Japan :) +10:39 < geertu> Seems like the killing of DST has been moved to the background noise... +10:40 < pinchartl> geertu: I think we would have been notified if there would be no chance this autumn +10:41 < geertu> pinchartl: Right. So ELC-E will be held in Winter Time +10:42 < geertu> I hope Thalys knows ;-) +10:42 < pinchartl> so the meeting will start at 17:00 JST, right ? +10:42 < geertu> I think so +10:43 < pinchartl> ok +10:43 < pinchartl> that's all for the multimedia meeting +10:43 < pinchartl> I propose adjourning, does anyone second ? +10:43 < neg> second +10:44 < pinchartl> meeting adjourned. thank you all for attending diff --git a/wiki/Chat_log/20191107-core-chatlog b/wiki/Chat_log/20191107-core-chatlog new file mode 100644 index 0000000..ba2d1aa --- /dev/null +++ b/wiki/Chat_log/20191107-core-chatlog @@ -0,0 +1,56 @@ +09:40 < geertu> Welcome to today's Core Group Chat Meeting! +09:40 < geertu> Agenda: +09:40 < geertu> 1. Status Updates +09:40 < geertu> 2. Discussion Topics +09:40 < geertu> Topic 1. Status updates +09:40 < geertu> A) What have we done since last time: +09:40 < geertu> Marek worked on U-Boot (HS400), Linux (PCI dma-ranges), and OpTee +09:40 < geertu> (patchset cleanup). +09:40 < geertu> Shimoda-san sent BSDL files to Marek, submitted rcar-usb2-clock-sel and +09:40 < geertu> ipmmu patches, and reviewed R-Car M3-W+ and RZ/G2N patches. +09:40 < geertu> Geert posted the OSTM timer_of conversion, debugfs_create() fixes, and +09:40 < geertu> initial R-Car M3-W+ support, and started improving sh-pfc runtime +09:40 < geertu> checks. +09:41 < jmondi> geertu: could you please add "Jacopo: tested GPIO backlight patch series for SH4 Ecovec" ? +09:41 < geertu> Sure +09:42 < geertu> Jacopo tested the GPIO backlight patch series for SH4 Ecovec +09:42 < geertu> B) What we plan to do till next time: +09:42 < geertu> Marek plans to continue working on U-Boot HS400 and OpTee. +09:42 < geertu> Geert plans to add more R-Car M3-W+ support, post new sh-pfc runtime +09:42 < geertu> checks and related fixes, and resume gpio-aggregator and DMAC sysfs +09:42 < geertu> work. +09:43 < geertu> C) Problems we have currently: +09:43 < geertu> Shimoda-san wonders who should be listed as the maintainer for DT +09:43 < geertu> binding documentation. +09:44 < geertu> ---EOT--- +09:44 < geertu> Anything I missed? +09:45 < geertu> shimoda: The maintainer for DT binding documentations is typically the same as the driver maintainer. +09:46 < morimoto> geertu: jmondi: interesting. Ecovec is still working, and/or still exist +09:46 < geertu> But lately people (doing the conversion to yaml) have been "creative" with it ;-) +09:47 < pinchartl> wsa_: now I'm here. sorry for the delay +09:47 < jmondi> morimoto: was quite an effort to resurect it :) +09:47 < jmondi> morimoto: Geert told everyone I still have that board, so I'm now receiveing patches to test on it -> JOY +09:48 < morimoto> jmondi: Nice to know ! +09:48 < morimoto> resurrect :) +09:48 < jmondi> yes indeed :) +09:49 < wsa_> pinchartl: No worries, I'll ask you during the MM meeting +09:49 < geertu> shimoda: both the rcar-dmac and ipmmu-vmsa drivers are authored by pinchartl, but who is the de-facto maintainer? +09:50 < wsa_> In I2C, I got a patch from people only wanting to maintain the YAML file but not the driver :/ +09:50 < shimoda> geertu: lets try to use get_maintainer.pl :) +09:51 < geertu> wsa_: Everybody wants to avoid maintaining i2c drivers, apparently ;-) +09:51 < geertu> shimoda: That'll be Jörg and Vinod... +09:52 < geertu> Is the maintainers field mandatory in yaml bindings? +09:52 < kbingham> does get_maintainers parse the yaml bindings? +09:53 < morimoto> I'm CC:ing to Rob if it was DT yaml patch +09:53 < geertu> kbingham: Nope (i.e. not yet) +09:54 < kbingham> geertu, get_maintainers will get crazy slow if it has to parse all files :S ? +09:55 < kbingham> geertu, Also - I presume the patchwork bot is working well now? I see more rreports from it on the mailing list ? +09:56 < geertu> kbingham: yes, seems to work well. Thanks! +09:57 < kbingham> I don't think it's cleaning up historical patch series', but it seems to be updating current ones. +09:57 < kbingham> I'll go through and see what needs cleaning up from the MM side +09:57 < geertu> kbingham: Thanks, that would be great! +09:58 < geertu> Note to all: feel free to mark your historical patches in https://patchwork.kernel.org/project/linux-renesas-soc/list/ +09:58 < geertu> So we're already at +09:58 < geertu> Topic 2. Discussion Topics +09:58 < geertu> Anything else to discuss? +10:00 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20191107-io-chatlog b/wiki/Chat_log/20191107-io-chatlog new file mode 100644 index 0000000..de037a5 --- /dev/null +++ b/wiki/Chat_log/20191107-io-chatlog @@ -0,0 +1,106 @@ +09:08 < wsa_> so, let's start the IO meeting then +09:08 < wsa_> status updates +09:08 < wsa_> A - what have I done since last time +09:08 < wsa_> ------------------------------------ +09:08 < wsa_> Geert +09:08 < wsa_> : investigated the MAX9611 boot failure issue, soldered some wires to his +09:08 < wsa_> Salvator-X (H3 ES1.0), and found out that the bus speed is slightly too +09:08 < wsa_> high +09:08 < wsa_> Marek +09:08 < wsa_> : continued discussion on the PCI dma-ranges, resubmitted the PCI +09:08 < wsa_> dma-ranges patches, and started cleaning up the downstream patchset +09:08 < wsa_> for OpTee +09:08 < wsa_> Shimoda-san +09:08 < wsa_> : submitted multiple patches to convert binding docs to YAML, fixed issues +09:08 < wsa_> in the PCI, USBHS and USN gadget drivers +09:08 < wsa_> Ulrich +09:08 < wsa_> : +09:08 < wsa_> Wolfram +09:08 < wsa_> : sent out two larger series for I2C API conversion and prepared some I2C +09:08 < wsa_> core cleanups, went to ELCE and gave a talk and discussed dynamic address +09:08 < wsa_> assignments there, started looking into new BSP patches about HS400, +09:08 < wsa_> reviewed and/or tested SDHI, MMC core, I2C, RAVB patches +09:08 < wsa_> B - what I want to do until next time +09:08 < wsa_> ------------------------------------- +09:08 < wsa_> Geert +09:08 < wsa_> : wants to continue debugging the MAX9611 issue +09:08 < wsa_> Marek +09:08 < wsa_> : wants to continue with OpTee work +09:08 < wsa_> Shimoda-san +09:08 < wsa_> : wants to collect information about "R-Car Gen4" hardware IPs +09:08 < wsa_> Ulrich +09:08 < wsa_> : wants to +09:08 < wsa_> Wolfram +09:08 < wsa_> : wants to finish SCC clock handling for SDHI, update SDHI manual calibration, +09:08 < wsa_> assist Geert with MAX9611 issue, do more I2C API conversions +09:08 < wsa_> C - problems I currently have +09:08 < wsa_> ----------------------------- +09:08 < wsa_> Wolfram +09:08 < wsa_> : has a disagreement with MMC maintainer how to handle pinctrl failures +09:08 < wsa_> during probe (bail out or not) +09:09 -!- Irssi: #periperi: Total of 16 nicks [0 ops, 0 halfops, 0 voices, 16 normal] +09:09 < wsa_> uli is missing. does someone know about him? +09:10 < wsa_> Marex: the OpTee work, is it for U-Boot or both Linux/U-Boot +09:10 < wsa_> ? +09:11 < Marex> wsa_: neither +09:11 < wsa_> ATF? +09:11 < Marex> wsa_: it's separate from everything +09:11 < Marex> wsa_: it's another component +09:11 < Marex> wsa_: optee OS is that secure-world operating system +09:12 < Marex> wsa_: it co-exists with Linux, has access to everything (because it's secure) and Linux can call into it via syscall interface +09:12 < jmondi> 'morning, sorry for being a bit late +09:13 < wsa_> Is that generic meanwhile? Because we have BSP-specific patches... +09:14 < Marex> wsa_: what , optee ? +09:14 < wsa_> the syscall interface +09:15 < Marex> wsa_: the syscall interface is (except for custom renesas syscalls for RPC access) +09:15 < Marex> those custom syscalls are not yet mainline, and probably wont ever be +09:15 < wsa_> if somebody wants to add an opinion to the disagreement I have with Ulf, this is the thread BTW: [PATCH] mmc: renesas_sdhi: add checks for pinctrl_lookup_state +09:15 < geertu> wsa_: So OpTee is core +09:15 < wsa_> Marex: ok, this is a clear answer :) +09:16 < wsa_> (well, except for "probably", but still gives me an idea) +09:16 < Marex> but yes, it's core +09:17 * geertu reads mmc: renesas_sdhi: add ... +09:19 < wsa_> shimoda: we removed Gen3 blacklisting from SDHI SYS_DMAC. Do you think we could also remove white listing Gen3 from SDHI Internal DMAC? And just make it a quirk table for those SoCs which have quirks? +09:20 < wsa_> We need to add every now SoC revision and I don't see value since we dropped black listing from SYS DMAC. But maybe I am overlooking something? +09:20 < geertu> wsa_: This it not just for UHS, but also for the default state? +09:20 < geertu> So preventing 1.8v modes is not the only failure mode +09:21 < wsa_> hmmm, yes +09:21 < wsa_> unless the firmware did the initial setup, but we shouldn't rely on this +09:21 < geertu> But "state_uhs" is optinal. What does pinctrl_lookup_state() return if it's just missing? +09:22 < geertu> s/optinal/optional/ +09:22 < geertu> Ah, -ENODEV, unless pinctrl_dummy_state is true (yikes) +09:24 < wsa_> geertu: any assistance you need for the MAX9611 debugging? As mentioned, I will scope some busses on some devices, too +09:25 < wsa_> pinchartl: you there? +09:25 < geertu> wsa_: I'll try the slower speed. If that fails, I'm afraid I will be blocked, as I don't think my SmartScope can capture all of the i2c4 actitivity during boot. +09:25 < jmondi> geertu: is the max9611 issue the POR one ? +09:25 < geertu> jmondi: Yes +09:25 < shimoda> wsa_: Do you mean the converting white list to black list (quirks)? if so, i agree :) +09:26 < jmondi> ah! thanks for investigating! +09:27 < wsa_> shimoda: not black list as in "forbid SDHI with that device" but as in "use this quirk with that device" +09:27 < wsa_> so, basically remove everything below "/* generic ones */" and adapt the code accordingly +09:27 < wsa_> other questions from your side? +09:28 < Marex> wsa_: yes +09:28 < Marex> wsa_: do you have the manual calibration patches somewhere ? I would like to take a look +09:28 < Marex> wsa_: seems we will have to add that into U-Boot as well, HS200 is not sufficient +09:29 < wsa_> you mean my reworked ones? +09:29 < Marex> wsa_: probably, I dont know in what state that work is on your end +09:30 < wsa_> https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/log/?h=renesas/topic/sdhi-manual-calib +09:30 < Marex> wsa_: thanks +09:30 < wsa_> this needs to be adapted to the latest BSP patches... +09:31 < wsa_> I agreed with Shimoda-san that DT configuration for all this is not needed upstream +09:31 < shimoda> wsa_: removing everything below "generic ones" sounds good to me. +09:31 < wsa_> so that part from the BSP can be skipped +09:31 < Marex> right +09:31 < wsa_> shimoda: cool, thanks! +09:32 < Marex> I suspect this special tuning might take longer than loading that one file from the eMMC in U-Boot, but we will see +09:32 < wsa_> shimoda: and I am looking forward to your Gen4 IP research results :) +09:33 < shimoda> wsa_: :) +09:33 < geertu> wsa_: needs to be adapted to the latest mainline or mmc-next, too +09:34 < wsa_> Marex: if you want to measure that, and have numbers for it, I think it makes sense to share them +09:34 < geertu> The branch was dropped from renesas-drivers as it contains a commit that has been upstream +09:34 < geertu> s/been/been reverted/ +09:34 < Marex> wsa_: I didn't implement it yet, so I dont +09:35 < wsa_> Marex: yeah, I was talking future here :) +09:36 < wsa_> so, any other questions? +09:37 < wsa_> if not, then I'll pass the mic to you, Geert +09:37 < wsa_> thanks everyone for this meeting! diff --git a/wiki/Chat_log/20191128-core-chatlog b/wiki/Chat_log/20191128-core-chatlog new file mode 100644 index 0000000..72d8592 --- /dev/null +++ b/wiki/Chat_log/20191128-core-chatlog @@ -0,0 +1,67 @@ +09:08 < geertu> Welcome to today's Core Group Chat Meeting! +09:09 < geertu> Agenda: +09:09 < geertu> 1. Status Updates +09:09 < geertu> 2. Discussion Topics +09:09 < geertu> Topic 1. Status updates +09:09 < geertu> A) What have we done since last time: +09:09 < geertu> Marek worked on U-Boot (HS400), OpTee (Renesas patch stack cleanup, +09:09 < geertu> passing DT from ATF), OpenOCD (RPC-HF + SH-QSPI), and ATF (DDR). +09:09 < geertu> Morimoto-san started a private CI. +09:09 < geertu> Shimoda-san tried ARM SMMU-v3 on ARM Neoverse N1. +09:09 < geertu> Geert implemented new PFC errata, sent v3 of the GPIO +09:09 < geertu> Aggregator/Repeater, investigated ARM Cryptocell on R-Car Gen3, and +09:09 < geertu> updated periject/core for v5.4. +09:09 < geertu> Ulrich reviewed the GPIO Aggregator/Repeater patches. +09:10 < geertu> B) What we plan to do till next time: +09:10 < geertu> Marek plans to continue working on OpTee, and may resume Gen2 U-Boot. +09:10 < geertu> Morimoto-san plans to create and test his private CI. +09:10 < geertu> Shimoda-san plans to convert rcar-dmac and ipmmu DT bindings to +09:10 < geertu> json-schema, and will continue using SMMU-v3. +09:10 < geertu> Geert plans to add more R-Car M3-W+ support, post new sh-pfc runtime +09:10 < geertu> checks and related fixes, and resume DMAC sysfs work. +09:10 < geertu> C) Problems we have currently: +09:10 < geertu> Marek suffers from long and non-transparent ATF patch review, and is +09:10 < geertu> considering alternatives use U-Boot SPL. +09:10 < geertu> Ulrich is learning to cope with Philippinean environmental and +09:10 < geertu> infrastructural quirks. +09:11 < geertu> ---EOT--- +09:11 < geertu> s/use/using/ +09:11 < geertu> Anything I missed? +09:13 < geertu> Topic 2. Discussion Topics +09:13 < geertu> Anything to discuss? +09:14 < shimoda> i don't have any topic +09:14 < kbingham> geertu, Will you aim to get your periject helper scripts/hooks into periject? Or are they stalled on the git-add issue? +09:14 < geertu> kbingham: They're already on master +09:14 < kbingham> Oh! I missed that :) +09:14 < kbingham> excellent. +09:15 < kbingham> Next question - do we have a script for creating a new task yet? Or is it just a manual copy/paste +09:15 < geertu> I think the gain is bigger than the issues +09:15 < kbingham> geertu, I agree, that's why I was hoping it would go to master already :) and now I learn it is :) +09:16 < geertu> Still manual copy/paste, AFAIK (like for anything yaml/python/<insert fancy new language here>... related) +09:18 < geertu> Nothing else to discuss? +09:18 < wsa> not from me +09:18 < geertu> Then I'm happy to thank you for joining, and pass the mic to whoever wants to take it +09:19 < kbingham> I guess that's me then +09:19 < morimoto> geertu: I have 1 +09:20 < morimoto> periject now has per-commit, but you didn't use "git merge" ? +09:20 < morimoto> Because commit ID not much to gitlab/pre-commit branch, I think +09:21 < geertu> morimoto: No I didn't, as your branch contained an older version +09:21 < morimoto> OK, I see. +09:21 < morimoto> Then, we can remove gitlab/pre-commit ? +09:22 < geertu> morimoto: Sorry for confusing you +09:22 < morimoto> no problem. +09:22 < geertu> morimoto: I think so +09:22 < morimoto> OK, will do +09:23 < morimoto> now, he is gone +09:23 < kbingham> Well if we're finishing off some discussions - geerty would you like me to try to set up the patchwork bot and see what we can do to manage that ourselves? +09:24 < kbingham> (gerrty must be my new nickname for geertu :D) +09:24 < morimoto> :D +09:24 < geertu> kbingham: Is it easy to set up your own instance? +09:25 < geertu> BTW, it looks like the bot didn't detect all new commits in renesas-devel that I had missed to mark accepted in patchwork +09:25 < kbingham> geertu, I don't yet know - that's what we'll need to find out. I looked breiefly, so I think it's essentialyl jsut a script that can run on a cron job, and just needs configuring to map to which git repos it will parse, and handle auth-tokens for patchwork. +09:26 < kbingham> Having our own instance will help us debug issues like that too I guess. +09:26 < geertu> yep +09:27 < kbingham> Ok - I'll try to set it up, and I can document what is needed to run it incase we want to set it up somewhere specifically (rather than my dev box/always on pc) +09:27 < geertu> ok, thx! +09:28 < kbingham> geertu, Ready for a mic-drop? :-D +09:29 < geertu> kbingham: Sure, I thought it was already dropped diff --git a/wiki/Chat_log/20191128-io-chatlog b/wiki/Chat_log/20191128-io-chatlog new file mode 100644 index 0000000..9592ea6 --- /dev/null +++ b/wiki/Chat_log/20191128-io-chatlog @@ -0,0 +1,114 @@ +09:53 < wsa> ok, now for the IO meeting, welcome! +09:53 < wsa> Here are the status updates +09:54 < wsa> Status updates +09:54 < wsa> ============== +09:54 < wsa> A - what have I done since last time +09:54 < wsa> ------------------------------------ +09:54 < wsa> Geert +09:54 < wsa> : investigated MAX9611 regression caused by too low conversion time and asked +09:54 < wsa> Maxim about a proper value, researched eMMC regression on R-Car M3-N +09:54 < wsa> Shimoda-san +09:54 < wsa> : submitted a patch series to change DMA buswidth for SDHI +09:54 < wsa> Ulrich +09:54 < wsa> : developed a new version of the RAVB MTU runtime change patch and got it +09:54 < wsa> merged, reviewed SDHI and GPIO patches +09:54 < wsa> Wolfram +09:54 < wsa> : updated I2C API conversions and created minor cleanup patches on the way, +09:54 < wsa> worked with Geert on MAX9611 issue and eMMC regression and sent out a revert, +09:54 < wsa> discussed with MMC maintainer about CAP_ERASE with SDHI, reviewed/tested +09:54 < wsa> patches for I2C core, SDHI, MMC core, I2C, IIC, updated periject to BSP 3.9.7 +09:54 < wsa> B - what I want to do until next time +09:54 < wsa> ------------------------------------- +09:54 < wsa> Geert +09:54 < wsa> : wants to send v2 of MAX9611 fix +09:54 < wsa> Shimoda-san +09:54 < wsa> : wants to collect information about "R-Car Gen4" hardware IPs +09:54 < wsa> Ulrich +09:54 < wsa> : wants to take over the watchdog handover task from Wolfram +09:54 < wsa> Wolfram +09:54 < wsa> : wants to send more I2C API conversion patches after rc1, finish SCC clock +09:54 < wsa> handling for SDHI, update SDHI manual calibration, implement and send out +09:54 < wsa> prototypes for dynamic i2c adresses +09:54 < wsa> C - problems I currently have +09:54 < wsa> ----------------------------- +09:54 < wsa> None +09:54 < wsa> uli__: I took the liberty to add the watchdog task to your B) section because you agreed to that in Lyon :) I'll send you the details later this week, okay? +09:54 -!- Irssi: #periperi: Total of 17 nicks [0 ops, 0 halfops, 0 voices, 17 normal] +09:55 < wsa> Marex: are the PCI ranges discussions going well? +09:55 < uli__> okidok +09:55 < wsa> Marex: or are they stalled? +09:55 < wsa> any other questions/additions to the status updates? +09:57 < wsa> geertu: while updating periject, I found MSIOF patches in the BSP. However, one for H3 ES3.0 can't be checked because of no HW, and one working around issues for H3 ES1.0/1.1 is dropped because why? We can't reproduce? +09:57 < geertu> wsa: Because I never got it to work on H3 ES1 +09:58 < geertu> The logic analyzer showed that the clock starts and stops before the data starts and stops, so completely broken +09:59 < geertu> IIRC, I posted analyzer screenshots to periperi ML a few years ago +09:59 < wsa> so, basically: -EINVALID? +10:00 < geertu> yep +10:01 < wsa> ok, thanks for the heads up +10:03 < morimoto> \me "okidoki" sounds like "okidokei" for me. "okidokei" is "table clock" in Japan +10:03 < wsa> kbingham: about the I2C API conversion: I hope to get all i2c_new_device patches into 5.6 +10:03 < wsa> if that works out, I'll remove the outdated functions after 5.6-rc1 +10:03 < kbingham> wsa, Great. +10:03 < kbingham> Let me know if there's anything I can help with on those, though I suspect you've got it covered. +10:03 < geertu> morimoto: ticks like a table clock +10:04 < wsa> I want to send the i2c_get_dynamic_address prototype before that (= mid December, latest) +10:04 < wsa> then, we will see, if this is 5.6 material, too +10:04 < kbingham> that's when things get interesting of course :) +10:05 < wsa> do you need more information? +10:06 < wsa> I will share my sketch even before the prototype if there turns out to be something different than what we discussed so far +10:06 < kbingham> wsa, Not currently I don't think - feel free to cc me on patches directly if you want (then I'll be more likely to see them) +10:07 < wsa> will do +10:08 < wsa> ah, another topic: FOSDEM - just a high level view, who is going there? do we want a Renesas meeting there? +10:08 < geertu> wsa: I'll be there (20th time) +10:09 < wsa> geertu: nice anniversary! +10:09 < geertu> wsa: Yeah, FOSDEM will be celebrating too. +10:09 < kbingham> I plan to attend FOSDEM. +10:09 < uli__> i'll be back in EU in time for FOSDEM +10:09 < neg> I will attend FOSDEM +10:09 < geertu> uli__: to release some spiders in packed rooms? +10:09 < jmondi> I'll be in Brussels +10:10 < morimoto> No JaPari go there... +10:11 < wsa> morimoto: :( +10:11 < damm> I was considering going there +10:11 < wsa> damm: \o/ +10:11 < damm> but not sure +10:11 < wsa> ok, then I will plan to go there as well +10:11 < morimoto> I miss you guys (; ;) +10:12 * geertu too +10:12 < wsa> and the meeting again on the friday before? +10:13 < geertu> sounds good to me +10:14 < wsa> good, I'll plan accordingly +10:14 < wsa> next meeting, 2019-12-19? +10:15 * morimoto ok for me +10:15 < geertu> sounds good to me +10:15 < neg> I will be traveling on the 19th so not sure how much I can join from the road +10:15 < geertu> neg: Wifi on IcE? +10:15 < morimoto> neg: winter vacation +10:15 < morimoto> ? +10:16 < wsa> back to sweden +10:16 < neg> morimoto: Going home to family for Christmas +10:16 < morimoto> Nice ! +10:16 < neg> geertu: No IcE to Sweden :-( wifi from SAS +10:17 < geertu> neg: How will you attend FOSDEM in Sweden? +10:17 * geertu mixed dec 19 with jan 31, doh +10:18 < wsa> okay, I hope 2019-12-19 is okay then because I am not available on 2019-12-12 +10:19 < wsa> kbingham: 2019-12-12? +10:19 < geertu> wsa: BTW, have you looked into i2c clock rates? +10:20 < kbingham> wsa, I'm good with 12-12, (htough I presume pinchartl will re-gain control of the mm-meetings by then), 12-19 I might be out with baby activities. +10:20 < geertu> 2019-12-12 is fine for me, too +10:20 < wsa> you mean that your measurements showed some unexpected clocks? +10:21 < geertu> wsa: Yeah, 427 kHz instead of 397 kHz +10:21 < wsa> okay, then let's continue this by email so pinchartl can give his favourite choice +10:21 < wsa> geertu: not yet, slipped through the cracks :/ +10:21 < Marex> hello +10:21 < geertu> ok +10:21 < Marex> wsa: stalled, I will revisit them this weekend +10:22 < wsa> Marex: ok, thanks! +10:23 < Marex> sorry for being late +10:23 < wsa> no worries +10:23 < wsa> other questions? +10:23 < wsa> otherwise I think we are done +10:25 < morimoto> Thanks +10:25 < geertu> thx, and have a nice continued day +10:25 < neg> thanks all +10:25 < wsa> good, EOM, have a nice day everyone! diff --git a/wiki/Chat_log/20191219-io-chatlog b/wiki/Chat_log/20191219-io-chatlog new file mode 100644 index 0000000..6c218c9 --- /dev/null +++ b/wiki/Chat_log/20191219-io-chatlog @@ -0,0 +1,117 @@ +09:02 < wsa> so, let's start the meeting now... +09:02 < geertu> wsa: Mornin' +09:02 < wsa> welcome to the IO meeting +09:02 < wsa> Morning Geert :) +09:02 < wsa> Here are the status updates, I haven't included Uli yet, as they just arrived +09:02 < wsa> will do that for the report +09:03 < wsa> Status updates +09:03 < wsa> ============== +09:03 < wsa> A - what have I done since last time +09:03 < wsa> ------------------------------------ +09:03 < wsa> Geert +09:03 < wsa> : got final version of max9611 fix merged, worked on Runtime PM for MTD physmap (needed for CFI and SPIBSC FLASHes) +09:03 < wsa> Shimoda-san +09:03 < wsa> : reviewed SDHI driver patches which Wolfram made +09:03 < wsa> Ulrich +09:03 < wsa> : +09:03 < wsa> Wolfram +09:03 < wsa> : rebased and sent out various I2C API changes after rc1, upported some SDHI patches which resulted in multiple series after refactoring, reviewed / tested / merged various patches all over the place, gave Renesas Europe some I2C assistance +09:03 < wsa> B - what I want to do until next time +09:03 < wsa> ------------------------------------- +09:03 < wsa> Geert +09:03 < wsa> : wants to do RSPI cs-gpios support +09:03 < wsa> Shimoda-san +09:03 < wsa> : wants to continue to collect information about "R-Car Gen4" hardware IPs, and update renesas_sdhi_sys_dmac patches if possible. +09:03 < wsa> Ulrich +09:03 < wsa> : wants to +09:03 < wsa> Wolfram +09:03 < wsa> : wants to boost priority for I2C dynamic addresses, keep upporting SDHI patches, and send out final I2C API changes +09:03 < wsa> C - problems I currently have +09:03 < wsa> ----------------------------- +09:03 < wsa> Shimoda-san +09:03 < wsa> : has difficulties to find upstream activity time because he has to investigate about R-Car Gen4's specifications now +09:03 < wsa> Wolfram +09:03 < wsa> : I2C dynamic address prototype might not be sent out before Christmas, is still not able to reproduce the stalled SCC despite working a lot with SDHI lately, and discovered two dependencies before he can upport the "avoid BAD_TAP" patch from the BSP so it will be delayed to next year. +09:03 < wsa> Fire away if you have questions... +09:04 < wsa> I have one question for Morimoto-san: with Redmine going away, is there still interest to add the irc chatlogs from meetings to it? +09:04 < wsa> I can keep doing that if there is interest +09:04 < wsa> I will keep doing that for my local folder anyhow :) +09:04 < jmondi> wsa: no questions but looking forward to test dynamic i2c addresses on gmsl :) +09:05 < wsa> jmondi: I know. Sorry for not-making the mid-December target :( +09:05 < jmondi> no worries, we have some gmsl work to do, we're not stalling on this :) +09:05 < wsa> that's good news! :) +09:06 < Marex> wsa: maybe we can switch to gitlab wiki for that :) +09:06 < morimoto> wsa: it can be nice topic today +09:06 < wsa> do you know about the circular dependency issue that Kieran asked me about? Did he resolve it? +09:06 < morimoto> I forwarded old meeting log to PeriJect.Wiki +09:07 < jmondi> wsa: wat that for me ? ^ +09:07 < wsa> jmondi: about Kieran's issue, yes +09:07 < jmondi> ok :) +09:08 < jmondi> I think it has been 'solved' in non-upstreamable way at the moment waiting to investigate if MFD might help +09:08 < jmondi> kbingham is around to confirm this ? +09:08 < morimoto> wsa: If you can update meeting log, you can put it to ${PERIJECT}/wiki/Chat_log, and udpate ${PERIJECT}/wiki/Chat_log.wiki +09:08 < wsa> Marex: do you have time for PCI patches currently? +09:09 < geertu> morimoto: How do I watch the local wiki with textile? +09:09 < wsa> morimoto: Ah, I understand. Thanks for the heads up! +09:09 < morimoto> geertu: you can make, and check index.html +09:09 < morimoto> you can find new "Wiki" on menu +09:09 < wsa> Marex: There is "[RFC] PCI: rcar: Fix incorrect programming of OB windows" unanswered and Shimoda-san seems busy... +09:09 < wsa> Marex: https://patchwork.kernel.org/patch/11174493/ +09:10 < wsa> If you don't have time, we maybe can delegate it? +09:11 < kbingham[m]> Not resolved the issue yet no. Might be a long ongoing thing :-) +09:11 < Marex> wsa: it's on my list of things to look into +09:11 < geertu> morimoto: ModuleNotFoundError: No module named 'textile' +09:11 < geertu> I did do "sudo apt install libtext-textile-perl" and "pip install textile" +09:12 < morimoto> geertu: oops, you need to install textile for python +09:13 < wsa> kbingham[m]: Does "not resolved" mean there *is* a circular dependency or you haven't had the time to check this in detail? +09:13 < morimoto> geertu: pip install textile +09:13 < wsa> Marex: thanks! +09:13 < wsa> Marex: I'll add it to your B) section :) +09:13 < kbingham[m]> wsa there is, and i need to work out the next way forward to resolve it. +09:13 < morimoto> geertu: thanks. it is indicated in README.md. but yes new feature +09:13 < geertu> morimoto: "sudo apt install python-textile" +09:14 -!- pinchartl [~laurent@perceval.ideasonboard.com] has quit Ping timeout: 250 seconds +09:14 < geertu> but still fails +09:14 < kbingham[m]> We have a couple of things to try , so we'll see how it goes. +09:15 < morimoto> geertu: humm.. +09:15 < wsa> Regarding PCI, there is also " Add support for PCIe controller to work in endpoint mode on R-Car SoCs. " +09:15 < Marex> morimoto: I hope you didn't get some strange chocolate/plum poisoning :) +09:15 < wsa> But geertu kept them busy with commenting on the bindings ;) +09:15 < morimoto> Marex: I enjoyed it today :) +09:15 < Marex> wsa: I went to AITENDO and got some PCIe x1 extender cables +09:15 < Marex> morimoto: was it any good ? +09:15 < morimoto> Marex: Yes, thanks a lot +09:16 < Marex> morimoto: whew, I'm glad to hear that +09:16 < wsa> This "PCI endpoint" thing is a bigger piece of code, we probably need to schedule that... +09:17 < Marex> wsa: oh yes +09:17 < Marex> wsa: and you actually need equipment for that +09:18 < wsa> Marex: the cable you mentioned? +09:18 < wsa> I don't have any further technical questions +09:19 < wsa> remaining questions (because I need to leave after IO meeting): +09:19 < wsa> next chat meeting - is 2020-01-09 too early after the holidays or is it good? +09:20 < Marex> wsa: I would have to assemble two of those together I think +09:20 < Marex> wsa: and there might be the obvious problem of PCIe clock generation +09:20 < geertu> morimoto: "sudo apt install python3-textile", and now it works +09:20 < Marex> wsa: thing is, usually a PCIe RC generates clock +09:20 < wsa> gitlab vs. private git - what do we want? +09:20 < wsa> Marex: if it turns out too complicated, we have to stick with visual review +09:20 < Marex> wsa: if you want to bind two RCs together (one in EP mode, other in RC mode), one has to receive clock , the other has to generate them +09:21 < wsa> Marex: I mean all the SDHI upporting now is basedon that because I can't test in these extreme temp ranges:) +09:21 < morimoto> geertu: thanks. Can you update README.md ? +09:21 < Marex> wsa: I ran into this issue with this SoCFPGA Cyclone V devkit, where to get it going as a PCIe EP, I would have to desolder the oscillator from the board +09:21 < Marex> wsa: I figured that's a bit too damaging +09:21 < geertu> wsa: 2020-01-09 may be a bit early, but it's in the middle beween now and FOSDEM +09:21 < Marex> wsa: can't you put the ULCB into an owen ? +09:21 < morimoto> geertu: "pip install textile" was OK for me. I'm not sure detail... +09:22 < Marex> wsa: the thermal driver should tell you whether you're overbaking it or not +09:26 < wsa> so, shall we leave the next meeting date open for now? +09:27 < wsa> and about the gitlab thing - I don't really mind +09:27 < geertu> fine for me +09:27 < wsa> If Magnus is willing to setup a private instance, I have a small preference for using own stuff +09:28 < geertu> As long as his RAM is fine, and he has backups ;-) +09:29 < wsa> :D +09:30 < wsa> okay, so not much discussion about that as well +09:30 < wsa> we can continue by mail, this is fine, too +09:31 < wsa> are we ready to move to core meeting now? +09:31 < geertu> Yeah, dammsan is not online +09:31 < geertu> Fine for me diff --git a/wiki/D3_Draak.wiki b/wiki/D3_Draak.wiki new file mode 100644 index 0000000..9a797c0 --- /dev/null +++ b/wiki/D3_Draak.wiki @@ -0,0 +1,11 @@ +h1. D3 Draak + +| "v2.21.0-custom":../../wiki/D3_Draak/d3_draak-20170713b.tar.gz +|BL2: R-Car Gen3 Initial Program Loader(CA53) Rev.0.0.1 +BL2: Built : 13:05:09, Jun 1 2017 +U-Boot 2015.04 (Jun 01 2017 - 19:31:38) | + +h1. Files + +"pdf: D3 Draak hwman v1.20":../../wiki/D3_Draak/D3_Draak_hwman_rev120.pdf +"pdf: D3 Draak circuit v0.29":../../wiki/D3_Draak/d3_draak_ref_circuit_rev029.pdf diff --git a/wiki/D3_Draak/D3_Draak_hwman_rev120.pdf b/wiki/D3_Draak/D3_Draak_hwman_rev120.pdf Binary files differnew file mode 100644 index 0000000..40141ce --- /dev/null +++ b/wiki/D3_Draak/D3_Draak_hwman_rev120.pdf diff --git a/wiki/D3_Draak/d3_draak-20170713b.tar.gz b/wiki/D3_Draak/d3_draak-20170713b.tar.gz Binary files differnew file mode 100644 index 0000000..d95b626 --- /dev/null +++ b/wiki/D3_Draak/d3_draak-20170713b.tar.gz diff --git a/wiki/D3_Draak/d3_draak_ref_circuit_rev029.pdf b/wiki/D3_Draak/d3_draak_ref_circuit_rev029.pdf Binary files differnew file mode 100644 index 0000000..b3a41a5 --- /dev/null +++ b/wiki/D3_Draak/d3_draak_ref_circuit_rev029.pdf diff --git a/wiki/E3_Ebisu.wiki b/wiki/E3_Ebisu.wiki new file mode 100644 index 0000000..ca1f5fa --- /dev/null +++ b/wiki/E3_Ebisu.wiki @@ -0,0 +1,5 @@ +h1. E3 Ebisu + +h1. Files + +"zip: E3 Ebisu 1GiB v2018-03-02/":../../wiki/E3_Ebisu/e3_ebisu_2018-03-02-for-ddr-1GiB.zip diff --git a/wiki/E3_Ebisu/e3_ebisu_2018-03-02-for-ddr-1GiB.zip b/wiki/E3_Ebisu/e3_ebisu_2018-03-02-for-ddr-1GiB.zip Binary files differnew file mode 100644 index 0000000..61daa12 --- /dev/null +++ b/wiki/E3_Ebisu/e3_ebisu_2018-03-02-for-ddr-1GiB.zip diff --git a/wiki/EMMC-speed-raw-data.wiki b/wiki/EMMC-speed-raw-data.wiki new file mode 100644 index 0000000..ae6b2ea --- /dev/null +++ b/wiki/EMMC-speed-raw-data.wiki @@ -0,0 +1,676 @@ +h1. EMMC-speed-raw-data + +h2. Preface + +Testing of HS200 using kernel v5.0 and HS400 using renesas-devel-20190306-v5.0 on +the following boards: + +* E3 1.0 / Ebisu-4D +* H3 ES2.0 / Salvator-XS +* M3-W / Salvator-X +* M3-N / Salvator-XS + + +h2. renesas-devel-20190306-v5.0 + +h3. E3 1.0 / Ebisu-4D + +* dmesg | grep mmc0 +[ 2.977456] renesas_sdhi_internal_dmac ee160000.sd: mmc0 base at 0xee160000 max clock rate 200 MHz +[ 3.061607] mmc0: new HS400 MMC card at address 0001 +[ 3.072077] mmcblk0: mmc0:0001 BGSD3R 29.1 GiB +[ 3.077188] mmcblk0boot0: mmc0:0001 BGSD3R partition 1 16.0 MiB +[ 3.087688] mmcblk0boot1: mmc0:0001 BGSD3R partition 2 16.0 MiB +[ 3.094290] mmcblk0rpmb: mmc0:0001 BGSD3R partition 3 4.00 MiB, chardev (243:0) +* cat /sys/kernel/debug/mmc0/ios +clock: 200000000 Hz +vdd: 21 (3.3 ~ 3.4 V) +bus mode: 2 (push-pull) +chip select: 0 (don't care) +power mode: 2 (on) +bus width: 3 (8 bits) +timing spec: 10 (mmc HS400) +signal voltage: 1 (1.80 V) +driver type: 0 (driver type B) +* cat /sys/devices/platform/soc/ee160000.sd/mmc_host/mmc0/mmc0:0001/cid +150100424753443352074e1b520e1500 + +h4. Read from MMC, direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 6.19636 s, 86.6 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 4.3704 s, 123 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 5.59537 s, 95.9 MB/s + +h4. Read from MMC, no direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 3.74477 s, 143 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 3.73702 s, 144 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 3.75046 s, 143 MB/s + +h4. Write to MMC, direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 8.98055 s, 59.8 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 10.087 s, 53.2 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 8.76716 s, 61.2 MB/s + +h4. Write to MMC, no direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 26.3785 s, 20.4 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 25.7717 s, 20.8 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 25.5235 s, 21.0 MB/s + +h3. H3 ES2.0 / Salvator-XS + +* dmesg | grep mmc0 +[ 3.638737] renesas_sdhi_internal_dmac ee140000.sd: mmc0 base at 0xee140000 max clock rate 200 MHz +[ 3.726050] mmc0: new HS400 MMC card at address 0001 +[ 3.734480] mmcblk0: mmc0:0001 BGSD3R 29.1 GiB +[ 3.744840] mmcblk0boot0: mmc0:0001 BGSD3R partition 1 16.0 MiB +[ 3.755265] mmcblk0boot1: mmc0:0001 BGSD3R partition 2 16.0 MiB +[ 3.765367] mmcblk0rpmb: mmc0:0001 BGSD3R partition 3 4.00 MiB, chardev (243:0) +* cat /sys/kernel/debug/mmc0/ios +clock: 200000000 Hz +vdd: 21 (3.3 ~ 3.4 V) +bus mode: 2 (push-pull) +chip select: 0 (don't care) +power mode: 2 (on) +bus width: 3 (8 bits) +timing spec: 10 (mmc HS400) +signal voltage: 1 (1.80 V) +driver type: 0 (driver type B) +* cat /sys/devices/platform/soc/ee140000.sd/mmc_host/mmc0/mmc0:0001/cid +1501004247534433520760a14ca96300 + +h4. Read from MMC, direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 18.7236 s, 28.7 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 16.0568 s, 33.4 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 13.5902 s, 39.5 MB/s + +h4. Read from MMC, no direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 3.25914 s, 165 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 3.2559 s, 165 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 3.27348 s, 164 MB/s + +h4. Write to MMC, direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 13.7446 s, 39.1 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 14.255 s, 37.7 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 16.9957 s, 31.6 MB/s + +h4. Write to MMC, no direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 20.9244 s, 25.7 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 20.9963 s, 25.6 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 18.3432 s, 29.3 MB/s + +h3. M3-W / Salvator-X + +* dmesg | grep mmc0 +[ 2.908701] renesas_sdhi_internal_dmac ee140000.sd: mmc0 base at 0xee140000 max clock rate 200 MHz +[ 3.028399] mmc0: new HS400 MMC card at address 0001 +[ 3.038233] mmcblk0: mmc0:0001 BGSD3R 29.1 GiB +[ 3.046540] mmcblk0boot0: mmc0:0001 BGSD3R partition 1 16.0 MiB +[ 3.060175] mmcblk0boot1: mmc0:0001 BGSD3R partition 2 16.0 MiB +[ 3.072615] mmcblk0rpmb: mmc0:0001 BGSD3R partition 3 4.00 MiB, chardev (243:0) +* cat /sys/kernel/debug/mmc0/ios +clock: 200000000 Hz +vdd: 21 (3.3 ~ 3.4 V) +bus mode: 2 (push-pull) +chip select: 0 (don't care) +power mode: 2 (on) +bus width: 3 (8 bits) +timing spec: 10 (mmc HS400) +signal voltage: 1 (1.80 V) +driver type: 0 (driver type B) +* cat /sys/devices/platform/soc/ee140000.sd/mmc_host/mmc0/mmc0:0001/cid +15010042475344335207e3d561ae8300 + +h4. Read from MMC, direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 10.2969 s, 52.1 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 10.736 s, 50.0 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 12.3474 s, 43.5 MB/s + +h4. Read from MMC, no direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 2.41708 s, 222 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 2.30209 s, 233 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 2.42179 s, 222 MB/s + +h4. Write to MMC, direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 7.41429 s, 72.4 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 8.75909 s, 61.3 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 9.18989 s, 58.4 MB/s + +h4. Write to MMC, no direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 18.7652 s, 28.6 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 18.7519 s, 28.6 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 18.0232 s, 29.8 MB/s + +h3. M3-N / Salvator-XS + +* dmesg | grep mmc0 +[ 3.138064] renesas_sdhi_internal_dmac ee140000.sd: mmc0 base at 0xee140000 max clock rate 200 MHz +[ 3.322792] mmc0: new HS200 MMC card at address 0001 +[ 3.328545] mmcblk0: mmc0:0001 eMMC 28.8 GiB +[ 3.333443] mmcblk0boot0: mmc0:0001 eMMC partition 1 4.00 MiB +[ 3.339705] mmcblk0boot1: mmc0:0001 eMMC partition 2 4.00 MiB +[ 3.351206] mmcblk0rpmb: mmc0:0001 eMMC partition 3 4.00 MiB, chardev (243:0) +* cat /sys/kernel/debug/mmc0/ios +clock: 200000000 Hz +vdd: 21 (3.3 ~ 3.4 V) +bus mode: 2 (push-pull) +chip select: 0 (don't care) +power mode: 2 (on) +bus width: 3 (8 bits) +timing spec: 9 (mmc HS200) +signal voltage: 1 (1.80 V) +driver type: 0 (driver type B) +* cat /sys/devices/platform/soc/ee140000.sd/mmc_host/mmc0/mmc0:0001/cid +89010a654d4d4320200126140246b200 + +h4. Read from MMC, direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 16.0305 s, 33.5 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 16.4025 s, 32.7 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 10.3156 s, 52.0 MB/s + +h4. Read from MMC, no direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 4.39188 s, 122 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 4.5587 s, 118 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 4.73909 s, 113 MB/s + +h4. Write to MMC, direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 25.9352 s, 20.7 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 13.8409 s, 38.8 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 14.2439 s, 37.7 MB/s + +h4. Write to MMC, no direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 33.2101 s, 16.2 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 33.1642 s, 16.2 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 33.1741 s, 16.2 MB/s + +h2. v5.0 + +h3. E3 1.0 / Ebisu-4D + +* dmesg | grep mmc0 +[ 2.913485] renesas_sdhi_internal_dmac ee160000.sd: mmc0 base at 0xee160000 max clock rate 200 MHz +[ 2.997527] mmc0: new HS200 MMC card at address 0001 +[ 3.007954] mmcblk0: mmc0:0001 BGSD3R 29.1 GiB +[ 3.013098] mmcblk0boot0: mmc0:0001 BGSD3R partition 1 16.0 MiB +[ 3.023460] mmcblk0boot1: mmc0:0001 BGSD3R partition 2 16.0 MiB +[ 3.030193] mmcblk0rpmb: mmc0:0001 BGSD3R partition 3 4.00 MiB, chardev (243:0) +* cat /sys/kernel/debug/mmc0/ios +clock: 200000000 Hz +vdd: 21 (3.3 ~ 3.4 V) +bus mode: 2 (push-pull) +chip select: 0 (don't care) +power mode: 2 (on) +bus width: 3 (8 bits) +timing spec: 9 (mmc HS200) +signal voltage: 1 (1.80 V) +driver type: 0 (driver type B) +* cat /sys/devices/platform/soc/ee160000.sd/mmc_host/mmc0/mmc0:0001/cid +150100424753443352074e1b520e1500 + +h4. Read from MMC, direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 17.5103 s, 30.7 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 6.28591 s, 85.4 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 13.8617 s, 38.7 MB/s + +h4. Read from MMC, no direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 3.90563 s, 137 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 3.88221 s, 138 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 3.90208 s, 138 MB/s + +h4. Write to MMC, direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 16.3188 s, 32.9 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 12.5534 s, 42.8 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 12.7248 s, 42.2 MB/s + +h4. Write to MMC, no direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 26.37 s, 20.4 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 26.3305 s, 20.4 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 27.0765 s, 19.8 MB/s + +h3. H3 ES2.0 / Salvator-XS + +* dmesg | grep mmc0 +[ 3.639006] renesas_sdhi_internal_dmac ee140000.sd: mmc0 base at 0xee140000 max clock rate 200 MHz +[ 3.722240] mmc0: new HS200 MMC card at address 0001 +[ 3.727982] mmcblk0: mmc0:0001 BGSD3R 29.1 GiB +[ 3.732859] mmcblk0boot0: mmc0:0001 BGSD3R partition 1 16.0 MiB +[ 3.739120] mmcblk0boot1: mmc0:0001 BGSD3R partition 2 16.0 MiB +[ 3.745221] mmcblk0rpmb: mmc0:0001 BGSD3R partition 3 4.00 MiB, chardev (243:0) +* cat /sys/kernel/debug/mmc0/ios +clock: 200000000 Hz +vdd: 21 (3.3 ~ 3.4 V) +bus mode: 2 (push-pull) +chip select: 0 (don't care) +power mode: 2 (on) +bus width: 3 (8 bits) +timing spec: 9 (mmc HS200) +signal voltage: 1 (1.80 V) +driver type: 0 (driver type B) +* cat /sys/devices/platform/soc/ee140000.sd/mmc_host/mmc0/mmc0:0001/cid +1501004247534433520760a14ca96300 + +h4. Read from MMC, direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 20.471 s, 26.2 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 19.5774 s, 27.4 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 15.4084 s, 34.8 MB/s + +h4. Read from MMC, no direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 4.19071 s, 128 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 4.18751 s, 128 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 4.19751 s, 128 MB/s + +h4. Write to MMC, direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 16.5855 s, 32.4 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 17.1501 s, 31.3 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 17.2643 s, 31.1 MB/s + +h4. Write to MMC, no direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 22.0624 s, 24.3 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 22.0098 s, 24.4 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 20.5633 s, 26.1 MB/s + +h3. M3-W / Salvator-X + +* dmesg | grep mmc0 +[ 3.137959] renesas_sdhi_internal_dmac ee140000.sd: mmc0 base at 0xee140000 max clock rate 200 MHz +[ 3.256875] mmc0: new HS200 MMC card at address 0001 +[ 3.262728] mmcblk0: mmc0:0001 eMMC 28.8 GiB +[ 3.267669] mmcblk0boot0: mmc0:0001 eMMC partition 1 4.00 MiB +[ 3.280205] mmcblk0boot1: mmc0:0001 eMMC partition 2 4.00 MiB +[ 3.293733] mmcblk0rpmb: mmc0:0001 eMMC partition 3 4.00 MiB, chardev (243:0) +* cat /sys/kernel/debug/mmc0/ios +clock: 200000000 Hz +vdd: 21 (3.3 ~ 3.4 V) +bus mode: 2 (push-pull) +chip select: 0 (don't care) +power mode: 2 (on) +bus width: 3 (8 bits) +timing spec: 9 (mmc HS200) +signal voltage: 1 (1.80 V) +driver type: 0 (driver type B) +* cat /sys/devices/platform/soc/ee140000.sd/mmc_host/mmc0/mmc0:0001/cid +89010a654d4d4320200126140246b200 + +h4. Read from MMC, direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 15.1949 s, 35.3 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 10.8901 s, 49.3 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 16.583 s, 32.4 MB/s + +h4. Read from MMC, no direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 10.5155 s, 51.1 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 10.5016 s, 51.1 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 10.5351 s, 51.0 MB/s + +h4. Write to MMC, direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 23.6249 s, 22.7 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 19.8348 s, 27.1 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 20.4312 s, 26.3 MB/s + +h4. Write to MMC, no direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 30.4137 s, 17.7 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 33.1452 s, 16.2 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 33.0829 s, 16.2 MB/s + +h3. M3-N / Salvator-XS + +* dmesg | grep mmc0 +[ 2.911377] renesas_sdhi_internal_dmac ee140000.sd: mmc0 base at 0xee140000 max clock rate 200 MHz +[ 3.008909] mmc0: new HS200 MMC card at address 0001 +[ 3.018096] mmcblk0: mmc0:0001 BGSD3R 29.1 GiB +[ 3.026954] mmcblk0boot0: mmc0:0001 BGSD3R partition 1 16.0 MiB +[ 3.033266] mmcblk0boot1: mmc0:0001 BGSD3R partition 2 16.0 MiB +[ 3.039519] mmcblk0rpmb: mmc0:0001 BGSD3R partition 3 4.00 MiB, chardev (243:0) +* cat /sys/kernel/debug/mmc0/ios +clock: 200000000 Hz +vdd: 21 (3.3 ~ 3.4 V) +bus mode: 2 (push-pull) +chip select: 0 (don't care) +power mode: 2 (on) +bus width: 3 (8 bits) +timing spec: 9 (mmc HS200) +signal voltage: 1 (1.80 V) +driver type: 0 (driver type B) +* cat /sys/devices/platform/soc/ee140000.sd/mmc_host/mmc0/mmc0:0001/cid +15010042475344335207e3d561ae8300 + +h4. Read from MMC, direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 9.14324 s, 58.7 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 5.08557 s, 106 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 7.94226 s, 67.6 MB/s + +h4. Read from MMC, no direct + +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 3.35788 s, 160 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 3.29605 s, 163 MB/s +# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 3.36475 s, 160 MB/s + +h4. Write to MMC, direct + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 10.7108 s, 50.1 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 11.0851 s, 48.4 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 7.36998 s, 72.8 MB/s + +h4. Write to MMC, nodirect + +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 19.7179 s, 27.2 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 19.6944 s, 27.3 MB/s +# dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 +512+0 records in +512+0 records out +536870912 bytes (537 MB) copied, 18.9546 s, 28.3 MB/s + +h2. Test Script + +"Script used for testing":../../wiki/EMMC-speed-raw-data/mmc.sh diff --git a/wiki/EMMC-speed-raw-data/mmc.sh b/wiki/EMMC-speed-raw-data/mmc.sh new file mode 100644 index 0000000..0faaa82 --- /dev/null +++ b/wiki/EMMC-speed-raw-data/mmc.sh @@ -0,0 +1,38 @@ +#!/bin/bash + +do_one () +{ + echo "# $@" + "$@" +} + +do_test () +{ + for i in $(seq 3); do + do_one "$@" + sleep 10 + done +} + +echo "# dmesg | grep mmc0" +dmesg | grep mmc0 +do_one cat /sys/kernel/debug/mmc0/ios +do_one cat /sys/devices/platform/soc/*/mmc_host/mmc0/mmc0:0001/cid + +echo +echo "Read from MMC, direct" +do_test dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct + +echo +echo "Read from MMC, no direct" +do_test dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 + +echo +echo "Write to MMC, direct" +do_test dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 oflag=direct + +echo +echo "Write to MMC, no direct" +do_test dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=512 + +echo diff --git a/wiki/GMSL_Camera_Setup.wiki b/wiki/GMSL_Camera_Setup.wiki new file mode 100644 index 0000000..b13b5d2 --- /dev/null +++ b/wiki/GMSL_Camera_Setup.wiki @@ -0,0 +1,76 @@ +h1. GMSL Camera Setup + +h2. Details on system configuration + +[[GMSL Configuration]] + +h2. Open issues and testing + +[[GMSL Cameras Open Issues and testing]] + +h2. Software support + +h3. External Patches: + +h4. Cogent Patches: + +https://github.com/CogentEmbedded/meta-rcar/blob/v2.23.0/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0030-Gen3-LVDS-cameras.patch + +h4. NXP Patches: + +https://community.nxp.com/docs/DOC-158531 + +h3. Linux kernel + +A base branch is available at + +* git://jmondi.org/linux-gen3#gmsl/base + +The base branch includes VIN and mux support from Niklas' branch git://git.ragnatech.se/linux#vin/mux+gmsl +with the ""max9286: More cleanups and fixes" series from Laurent on top. +vin/mux+gmsl contains the GMSL link stabilization series from Niklas: [PATCH 0/4] GMSL link stabilization. + +On top of this branch, some developers branch are available: + +* git://jmondi.org/linux-gen3#gmsl/devel/jacopo + Fixes sent out as "[PATCH v2 0/5] v4l: max9286: Additional fixes" + sensor configuration + link status monitoring + +* git://jmondi.org/linux-gen3#gmsl/devel/jacopo-i2c-bcast + gmsl/devel/jacopo branch with on top implementation of broadcast transmission of SEREN command to max9271 serializers + +h3. Config + +Configuration file for Linux-v4.13-rc5 available here: ("linux-v4.13-max9286.config":../../wiki/GMSL_Camera_Setup/linux-v4.13-max9286.config) + +h1. I2C configuration + +* The MAX9271 does appear to expose all traffic received across the GMSL link on it's I2C bus pins. +* There does not appear to be any cross-talk traffic currently. +* 'Bit-errors' have been seen ... most evidently when an address write incorrectly wrote to register 0x00 instead and 'forcefully' changed the MAX9271 address. All following writes were then 'NACKed'. +* This shows that auto-ack from the MAX9286 (which was enabled at that time) *does not* traverse the GMSL link. +* If the delays between bus configuration writes are not long enough - the following write/read can be corrupted with bit errors, or not be present on the bus at all. +** This shows that the delay after configuration writes must be conservative, and therefore at least 5 ms (recommended by the MAX9286 data sheet) rather than 3 ms or less (as suggested by the MAX9271 DS. + + +h1. I2C address space allocations + +h2. The GMSL camera set up uses the I2C-4 bus on the RCar platform. This has the following pre-existing address assignments: + +| Address | Physical | Part | SCL | SDA | Description | +| | CN29 | EXIO-Connector C | 51 | 53 | MIPI CSI-2 Zebax Connector | +| 0x20 | U6 | PCA9654EDTR2G | 14 | 15 | 8 bit IO Expander | +| 0x68 | U11 | 9FGV0841AKILF | 10 | 11 | Salvator-X Page 11 : 8 Output PCIe Clock Gen | +| 0x6a | U61 | 5P49V5923A | 9 | 8 | Salvator-X Page 3 : Versaclock5 | +| 0x70 | U31 | ADV7482WBBCZ | J8 | K8 | Salvator-X Page 19 : ADV7482 HDMI Receiver | +| 0x7C | U58 | MAX9611AUB+ | 6 | 7 | Salvator-X Page 25 : Current Sense Amplifier with ADC | +| 0x7F | U59 | MAX9611AUB+ | 6 | 7 | Salvator-X Page 25 : Current Sense Amplifier with ADC | + +h2. Maxim Expansion Board + +| Address | Physical | Part | SCL | SDA | Description | +| 0x4c | U1 | MAX9286GTN/V+ | 8 | 7 | MAX9286 GMSL De-serialiser (MAX9286 A) | +| 0x6c | U3 | MAX9286GTN/V+ | 8 | 7 | MAX9286 GMSL De-serialiser (MAX9286 A) | +| | | | | | | +| 0x30 | RDACM20 | OV10635 Default | | | OV10635 Default address | +| 0x40 | RDACM20 | MAX9271 Default | | | MAX9271 Default address | +| 0x50 | RDACM20 | Microcontroller | | | Microcontroller (MCU) Default address | diff --git a/wiki/GMSL_Camera_Setup/linux-v4.13-max9286.config b/wiki/GMSL_Camera_Setup/linux-v4.13-max9286.config new file mode 100644 index 0000000..88db889 --- /dev/null +++ b/wiki/GMSL_Camera_Setup/linux-v4.13-max9286.config @@ -0,0 +1,3003 @@ +# +# Automatically generated file; DO NOT EDIT. +# Linux/arm64 4.13.0-rc4 Kernel Configuration +# +CONFIG_ARM64=y +CONFIG_64BIT=y +CONFIG_ARCH_PHYS_ADDR_T_64BIT=y +CONFIG_MMU=y +CONFIG_ARM64_PAGE_SHIFT=12 +CONFIG_ARM64_CONT_SHIFT=4 +CONFIG_ARCH_MMAP_RND_BITS_MIN=18 +CONFIG_ARCH_MMAP_RND_BITS_MAX=24 +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11 +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 +CONFIG_NO_IOPORT_MAP=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000 +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_GENERIC_BUG=y +CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CSUM=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_ZONE_DMA=y +CONFIG_HAVE_GENERIC_GUP=y +CONFIG_ARCH_DMA_ADDR_T_64BIT=y +CONFIG_NEED_DMA_MAP_STATE=y +CONFIG_NEED_SG_DMA_LENGTH=y +CONFIG_SMP=y +CONFIG_SWIOTLB=y +CONFIG_IOMMU_HELPER=y +CONFIG_KERNEL_MODE_NEON=y +CONFIG_FIX_EARLYCON_MEM=y +CONFIG_PGTABLE_LEVELS=3 +CONFIG_ARCH_SUPPORTS_UPROBES=y +CONFIG_ARCH_PROC_KCORE_TEXT=y +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" +CONFIG_IRQ_WORK=y +CONFIG_BUILDTIME_EXTABLE_SORT=y +CONFIG_THREAD_INFO_IN_TASK=y + +# +# General setup +# +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_CROSS_COMPILE="" +# CONFIG_COMPILE_TEST is not set +CONFIG_LOCALVERSION="-yocto-standard" +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_DEFAULT_HOSTNAME="(none)" +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +CONFIG_POSIX_MQUEUE_SYSCTL=y +CONFIG_CROSS_MEMORY_ATTACH=y +CONFIG_FHANDLE=y +CONFIG_USELIB=y +CONFIG_AUDIT=y +CONFIG_HAVE_ARCH_AUDITSYSCALL=y +CONFIG_AUDITSYSCALL=y +CONFIG_AUDIT_WATCH=y +CONFIG_AUDIT_TREE=y + +# +# IRQ subsystem +# +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_GENERIC_IRQ_SHOW=y +CONFIG_GENERIC_IRQ_SHOW_LEVEL=y +CONFIG_GENERIC_IRQ_MIGRATION=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_CHIP=y +CONFIG_IRQ_DOMAIN=y +CONFIG_IRQ_DOMAIN_HIERARCHY=y +CONFIG_HANDLE_DOMAIN_IRQ=y +# CONFIG_IRQ_DOMAIN_DEBUG is not set +CONFIG_IRQ_FORCED_THREADING=y +CONFIG_SPARSE_IRQ=y +# CONFIG_GENERIC_IRQ_DEBUGFS is not set +CONFIG_ARCH_CLOCKSOURCE_DATA=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_ARCH_HAS_TICK_BROADCAST=y +CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y + +# +# Timers subsystem +# +CONFIG_TICK_ONESHOT=y +CONFIG_NO_HZ_COMMON=y +# CONFIG_HZ_PERIODIC is not set +CONFIG_NO_HZ_IDLE=y +# CONFIG_NO_HZ_FULL is not set +# CONFIG_NO_HZ is not set +CONFIG_HIGH_RES_TIMERS=y + +# +# CPU/Task time and stats accounting +# +CONFIG_TICK_CPU_ACCOUNTING=y +# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set +# CONFIG_IRQ_TIME_ACCOUNTING is not set +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_BSD_PROCESS_ACCT_V3=y +CONFIG_TASKSTATS=y +CONFIG_TASK_DELAY_ACCT=y +CONFIG_TASK_XACCT=y +CONFIG_TASK_IO_ACCOUNTING=y + +# +# RCU Subsystem +# +CONFIG_PREEMPT_RCU=y +# CONFIG_RCU_EXPERT is not set +CONFIG_SRCU=y +CONFIG_TREE_SRCU=y +# CONFIG_TASKS_RCU is not set +CONFIG_RCU_STALL_COMMON=y +CONFIG_RCU_NEED_SEGCBLIST=y +CONFIG_BUILD_BIN2C=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=17 +CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 +CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 +CONFIG_GENERIC_SCHED_CLOCK=y +CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y +CONFIG_CGROUPS=y +CONFIG_PAGE_COUNTER=y +CONFIG_MEMCG=y +CONFIG_MEMCG_SWAP=y +CONFIG_MEMCG_SWAP_ENABLED=y +# CONFIG_BLK_CGROUP is not set +CONFIG_CGROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_CFS_BANDWIDTH is not set +# CONFIG_RT_GROUP_SCHED is not set +# CONFIG_CGROUP_PIDS is not set +# CONFIG_CGROUP_RDMA is not set +# CONFIG_CGROUP_FREEZER is not set +CONFIG_CGROUP_HUGETLB=y +# CONFIG_CPUSETS is not set +# CONFIG_CGROUP_DEVICE is not set +# CONFIG_CGROUP_CPUACCT is not set +# CONFIG_CGROUP_PERF is not set +# CONFIG_CGROUP_DEBUG is not set +# CONFIG_SOCK_CGROUP_DATA is not set +# CONFIG_CHECKPOINT_RESTORE is not set +CONFIG_NAMESPACES=y +# CONFIG_UTS_NS is not set +# CONFIG_IPC_NS is not set +# CONFIG_USER_NS is not set +CONFIG_PID_NS=y +# CONFIG_NET_NS is not set +CONFIG_SCHED_AUTOGROUP=y +# CONFIG_SYSFS_DEPRECATED is not set +# CONFIG_RELAY is not set +# CONFIG_BLK_DEV_INITRD is not set +CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y +CONFIG_HAVE_UID16=y +CONFIG_SYSCTL_EXCEPTION_TRACE=y +CONFIG_BPF=y +# CONFIG_EXPERT is not set +CONFIG_UID16=y +CONFIG_MULTIUSER=y +# CONFIG_SGETMASK_SYSCALL is not set +CONFIG_SYSFS_SYSCALL=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_POSIX_TIMERS=y +CONFIG_KALLSYMS=y +CONFIG_KALLSYMS_ALL=y +# CONFIG_KALLSYMS_ABSOLUTE_PERCPU is not set +CONFIG_KALLSYMS_BASE_RELATIVE=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +# CONFIG_BPF_SYSCALL is not set +CONFIG_SHMEM=y +CONFIG_AIO=y +CONFIG_ADVISE_SYSCALLS=y +# CONFIG_USERFAULTFD is not set +CONFIG_MEMBARRIER=y +# CONFIG_EMBEDDED is not set +CONFIG_HAVE_PERF_EVENTS=y +# CONFIG_PC104 is not set + +# +# Kernel Performance Events And Counters +# +CONFIG_PERF_EVENTS=y +# CONFIG_DEBUG_PERF_USE_VMALLOC is not set +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLUB_DEBUG=y +# CONFIG_SLUB_MEMCG_SYSFS_ON is not set +# CONFIG_COMPAT_BRK is not set +# CONFIG_SLAB is not set +CONFIG_SLUB=y +CONFIG_SLAB_MERGE_DEFAULT=y +# CONFIG_SLAB_FREELIST_RANDOM is not set +CONFIG_SLUB_CPU_PARTIAL=y +# CONFIG_SYSTEM_DATA_VERIFICATION is not set +CONFIG_PROFILING=y +# CONFIG_KPROBES is not set +CONFIG_JUMP_LABEL=y +# CONFIG_STATIC_KEYS_SELFTEST is not set +# CONFIG_UPROBES is not set +# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set +CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_ARCH_TRACEHOOK=y +CONFIG_HAVE_DMA_CONTIGUOUS=y +CONFIG_GENERIC_SMP_IDLE_THREAD=y +CONFIG_GENERIC_IDLE_POLL_SETUP=y +CONFIG_ARCH_HAS_FORTIFY_SOURCE=y +CONFIG_ARCH_HAS_SET_MEMORY=y +CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y +CONFIG_HAVE_CLK=y +CONFIG_HAVE_DMA_API_DEBUG=y +CONFIG_HAVE_HW_BREAKPOINT=y +CONFIG_HAVE_PERF_REGS=y +CONFIG_HAVE_PERF_USER_STACK_DUMP=y +CONFIG_HAVE_ARCH_JUMP_LABEL=y +CONFIG_HAVE_RCU_TABLE_FREE=y +CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y +CONFIG_HAVE_CMPXCHG_LOCAL=y +CONFIG_HAVE_CMPXCHG_DOUBLE=y +CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y +CONFIG_HAVE_ARCH_SECCOMP_FILTER=y +CONFIG_HAVE_GCC_PLUGINS=y +# CONFIG_GCC_PLUGINS is not set +CONFIG_HAVE_CC_STACKPROTECTOR=y +# CONFIG_CC_STACKPROTECTOR is not set +CONFIG_CC_STACKPROTECTOR_NONE=y +# CONFIG_CC_STACKPROTECTOR_REGULAR is not set +# CONFIG_CC_STACKPROTECTOR_STRONG is not set +CONFIG_THIN_ARCHIVES=y +CONFIG_HAVE_CONTEXT_TRACKING=y +CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y +CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y +CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y +CONFIG_HAVE_ARCH_HUGE_VMAP=y +CONFIG_MODULES_USE_ELF_RELA=y +CONFIG_ARCH_HAS_ELF_RANDOMIZE=y +CONFIG_HAVE_ARCH_MMAP_RND_BITS=y +CONFIG_ARCH_MMAP_RND_BITS=18 +CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y +CONFIG_ARCH_MMAP_RND_COMPAT_BITS=11 +# CONFIG_HAVE_ARCH_HASH is not set +# CONFIG_ISA_BUS_API is not set +CONFIG_CLONE_BACKWARDS=y +CONFIG_OLD_SIGSUSPEND3=y +CONFIG_COMPAT_OLD_SIGACTION=y +# CONFIG_CPU_NO_EFFICIENT_FFS is not set +# CONFIG_HAVE_ARCH_VMAP_STACK is not set +# CONFIG_ARCH_OPTIONAL_KERNEL_RWX is not set +# CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT is not set +CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y +CONFIG_STRICT_KERNEL_RWX=y +CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y +CONFIG_STRICT_MODULE_RWX=y +# CONFIG_REFCOUNT_FULL is not set + +# +# GCOV-based kernel profiling +# +# CONFIG_GCOV_KERNEL is not set +CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +# CONFIG_MODULE_SIG is not set +# CONFIG_MODULE_COMPRESS is not set +# CONFIG_TRIM_UNUSED_KSYMS is not set +CONFIG_MODULES_TREE_LOOKUP=y +CONFIG_BLOCK=y +CONFIG_BLK_SCSI_REQUEST=y +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_BSGLIB is not set +# CONFIG_BLK_DEV_INTEGRITY is not set +# CONFIG_BLK_DEV_ZONED is not set +# CONFIG_BLK_CMDLINE_PARSER is not set +# CONFIG_BLK_WBT is not set +# CONFIG_BLK_DEBUG_FS is not set +# CONFIG_BLK_SED_OPAL is not set + +# +# Partition Types +# +# CONFIG_PARTITION_ADVANCED is not set +CONFIG_MSDOS_PARTITION=y +CONFIG_EFI_PARTITION=y +CONFIG_BLOCK_COMPAT=y + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +# CONFIG_IOSCHED_DEADLINE is not set +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_CFQ=y +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="cfq" +# CONFIG_MQ_IOSCHED_DEADLINE is not set +# CONFIG_MQ_IOSCHED_KYBER is not set +# CONFIG_IOSCHED_BFQ is not set +CONFIG_UNINLINE_SPIN_UNLOCK=y +CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y +CONFIG_MUTEX_SPIN_ON_OWNER=y +CONFIG_RWSEM_SPIN_ON_OWNER=y +CONFIG_LOCK_SPIN_ON_OWNER=y +CONFIG_FREEZER=y + +# +# Platform selection +# +# CONFIG_ARCH_ACTIONS is not set +# CONFIG_ARCH_SUNXI is not set +# CONFIG_ARCH_ALPINE is not set +# CONFIG_ARCH_BCM2835 is not set +# CONFIG_ARCH_BCM_IPROC is not set +# CONFIG_ARCH_BERLIN is not set +# CONFIG_ARCH_BRCMSTB is not set +# CONFIG_ARCH_EXYNOS is not set +# CONFIG_ARCH_LAYERSCAPE is not set +# CONFIG_ARCH_LG1K is not set +# CONFIG_ARCH_HISI is not set +# CONFIG_ARCH_MEDIATEK is not set +# CONFIG_ARCH_MESON is not set +# CONFIG_ARCH_MVEBU is not set +# CONFIG_ARCH_QCOM is not set +# CONFIG_ARCH_REALTEK is not set +# CONFIG_ARCH_ROCKCHIP is not set +# CONFIG_ARCH_SEATTLE is not set +CONFIG_ARCH_SHMOBILE=y +CONFIG_ARCH_RENESAS=y +CONFIG_ARCH_R8A7795=y +CONFIG_ARCH_R8A7796=y +# CONFIG_ARCH_STRATIX10 is not set +# CONFIG_ARCH_TEGRA is not set +# CONFIG_ARCH_SPRD is not set +# CONFIG_ARCH_THUNDER is not set +# CONFIG_ARCH_THUNDER2 is not set +# CONFIG_ARCH_UNIPHIER is not set +# CONFIG_ARCH_VEXPRESS is not set +# CONFIG_ARCH_VULCAN is not set +# CONFIG_ARCH_XGENE is not set +# CONFIG_ARCH_ZX is not set +# CONFIG_ARCH_ZYNQMP is not set + +# +# Bus support +# +# CONFIG_PCI is not set +# CONFIG_PCI_DOMAINS is not set +# CONFIG_PCI_DOMAINS_GENERIC is not set +# CONFIG_PCI_SYSCALL is not set + +# +# DesignWare PCI Core Support +# + +# +# PCI Endpoint +# +# CONFIG_PCI_ENDPOINT is not set + +# +# Kernel Features +# + +# +# ARM errata workarounds via the alternatives framework +# +CONFIG_ARM64_ERRATUM_826319=y +CONFIG_ARM64_ERRATUM_827319=y +CONFIG_ARM64_ERRATUM_824069=y +CONFIG_ARM64_ERRATUM_819472=y +CONFIG_ARM64_ERRATUM_832075=y +CONFIG_ARM64_ERRATUM_845719=y +CONFIG_ARM64_ERRATUM_843419=y +CONFIG_CAVIUM_ERRATUM_22375=y +CONFIG_CAVIUM_ERRATUM_23154=y +# CONFIG_CAVIUM_ERRATUM_27456 is not set +CONFIG_CAVIUM_ERRATUM_30115=y +# CONFIG_QCOM_FALKOR_ERRATUM_1003 is not set +# CONFIG_QCOM_FALKOR_ERRATUM_1009 is not set +# CONFIG_QCOM_QDF2400_ERRATUM_0065 is not set +CONFIG_ARM64_4K_PAGES=y +# CONFIG_ARM64_16K_PAGES is not set +# CONFIG_ARM64_64K_PAGES is not set +CONFIG_ARM64_VA_BITS_39=y +# CONFIG_ARM64_VA_BITS_48 is not set +CONFIG_ARM64_VA_BITS=39 +# CONFIG_CPU_BIG_ENDIAN is not set +CONFIG_SCHED_MC=y +# CONFIG_SCHED_SMT is not set +CONFIG_NR_CPUS=64 +CONFIG_HOTPLUG_CPU=y +# CONFIG_NUMA is not set +# CONFIG_PREEMPT_NONE is not set +# CONFIG_PREEMPT_VOLUNTARY is not set +CONFIG_PREEMPT=y +CONFIG_PREEMPT_COUNT=y +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +# CONFIG_HZ_300 is not set +# CONFIG_HZ_1000 is not set +CONFIG_HZ=250 +CONFIG_SCHED_HRTICK=y +CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y +CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y +CONFIG_ARCH_SPARSEMEM_ENABLE=y +CONFIG_ARCH_SPARSEMEM_DEFAULT=y +CONFIG_ARCH_SELECT_MEMORY_MODEL=y +CONFIG_HAVE_ARCH_PFN_VALID=y +CONFIG_HW_PERF_EVENTS=y +CONFIG_SYS_SUPPORTS_HUGETLBFS=y +CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y +CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_SPARSEMEM_MANUAL=y +CONFIG_SPARSEMEM=y +CONFIG_HAVE_MEMORY_PRESENT=y +CONFIG_SPARSEMEM_EXTREME=y +CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y +CONFIG_SPARSEMEM_VMEMMAP=y +CONFIG_HAVE_MEMBLOCK=y +CONFIG_NO_BOOTMEM=y +CONFIG_MEMORY_ISOLATION=y +# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set +CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_COMPACTION=y +CONFIG_MIGRATION=y +CONFIG_PHYS_ADDR_T_64BIT=y +CONFIG_BOUNCE=y +CONFIG_KSM=y +CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 +CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y +# CONFIG_MEMORY_FAILURE is not set +CONFIG_TRANSPARENT_HUGEPAGE=y +CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y +# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set +# CONFIG_ARCH_WANTS_THP_SWAP is not set +CONFIG_TRANSPARENT_HUGE_PAGECACHE=y +# CONFIG_CLEANCACHE is not set +# CONFIG_FRONTSWAP is not set +CONFIG_CMA=y +# CONFIG_CMA_DEBUG is not set +# CONFIG_CMA_DEBUGFS is not set +CONFIG_CMA_AREAS=7 +# CONFIG_ZPOOL is not set +# CONFIG_ZBUD is not set +# CONFIG_ZSMALLOC is not set +CONFIG_GENERIC_EARLY_IOREMAP=y +# CONFIG_IDLE_PAGE_TRACKING is not set +CONFIG_FRAME_VECTOR=y +# CONFIG_PERCPU_STATS is not set +# CONFIG_SECCOMP is not set +# CONFIG_PARAVIRT is not set +# CONFIG_PARAVIRT_TIME_ACCOUNTING is not set +# CONFIG_KEXEC is not set +# CONFIG_CRASH_DUMP is not set +# CONFIG_XEN is not set +CONFIG_FORCE_MAX_ZONEORDER=11 +# CONFIG_ARMV8_DEPRECATED is not set +# CONFIG_ARM64_SW_TTBR0_PAN is not set + +# +# ARMv8.1 architectural features +# +CONFIG_ARM64_HW_AFDBM=y +CONFIG_ARM64_PAN=y +# CONFIG_ARM64_LSE_ATOMICS is not set +# CONFIG_ARM64_VHE is not set + +# +# ARMv8.2 architectural features +# +CONFIG_ARM64_UAO=y +CONFIG_ARM64_MODULE_CMODEL_LARGE=y +# CONFIG_RANDOMIZE_BASE is not set + +# +# Boot options +# +CONFIG_CMDLINE="console=ttyAMA0" +# CONFIG_CMDLINE_FORCE is not set +# CONFIG_EFI is not set + +# +# Userspace binary formats +# +CONFIG_BINFMT_ELF=y +CONFIG_COMPAT_BINFMT_ELF=y +CONFIG_ELFCORE=y +# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +CONFIG_BINFMT_SCRIPT=y +# CONFIG_HAVE_AOUT is not set +# CONFIG_BINFMT_MISC is not set +CONFIG_COREDUMP=y +CONFIG_COMPAT=y +CONFIG_SYSVIPC_COMPAT=y + +# +# Power management options +# +CONFIG_SUSPEND=y +CONFIG_SUSPEND_FREEZER=y +# CONFIG_HIBERNATION is not set +CONFIG_PM_SLEEP=y +CONFIG_PM_SLEEP_SMP=y +# CONFIG_PM_AUTOSLEEP is not set +# CONFIG_PM_WAKELOCKS is not set +CONFIG_PM=y +# CONFIG_PM_DEBUG is not set +CONFIG_PM_OPP=y +CONFIG_PM_CLK=y +CONFIG_PM_GENERIC_DOMAINS=y +# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set +CONFIG_PM_GENERIC_DOMAINS_SLEEP=y +CONFIG_PM_GENERIC_DOMAINS_OF=y +CONFIG_CPU_PM=y +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_SUSPEND_POSSIBLE=y + +# +# CPU Power Management +# + +# +# CPU Idle +# +CONFIG_CPU_IDLE=y +CONFIG_CPU_IDLE_MULTIPLE_DRIVERS=y +# CONFIG_CPU_IDLE_GOV_LADDER is not set +CONFIG_CPU_IDLE_GOV_MENU=y +CONFIG_DT_IDLE_STATES=y + +# +# ARM CPU Idle Drivers +# +CONFIG_ARM_CPUIDLE=y +# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set + +# +# CPU Frequency scaling +# +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_GOV_ATTR_SET=y +CONFIG_CPU_FREQ_GOV_COMMON=y +CONFIG_CPU_FREQ_STAT=y +CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y +# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set +# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set +# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set +# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set +# CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set +CONFIG_CPU_FREQ_GOV_PERFORMANCE=y +CONFIG_CPU_FREQ_GOV_POWERSAVE=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_ONDEMAND=y +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y +# CONFIG_CPU_FREQ_GOV_SCHEDUTIL is not set + +# +# CPU frequency scaling drivers +# +CONFIG_CPUFREQ_DT=y +CONFIG_CPUFREQ_DT_PLATDEV=y +# CONFIG_ARM_BIG_LITTLE_CPUFREQ is not set +# CONFIG_ARM_DB8500_CPUFREQ is not set +# CONFIG_ARM_KIRKWOOD_CPUFREQ is not set +# CONFIG_QORIQ_CPUFREQ is not set +CONFIG_NET=y + +# +# Networking options +# +CONFIG_PACKET=y +# CONFIG_PACKET_DIAG is not set +CONFIG_UNIX=y +# CONFIG_UNIX_DIAG is not set +# CONFIG_TLS is not set +# CONFIG_XFRM_USER is not set +# CONFIG_NET_KEY is not set +CONFIG_INET=y +# CONFIG_IP_MULTICAST is not set +# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_IP_PNP_RARP=y +# CONFIG_NET_IPIP is not set +# CONFIG_NET_IPGRE_DEMUX is not set +# CONFIG_NET_IP_TUNNEL is not set +# CONFIG_SYN_COOKIES is not set +# CONFIG_NET_UDP_TUNNEL is not set +# CONFIG_NET_FOU is not set +# CONFIG_INET_AH is not set +# CONFIG_INET_ESP is not set +# CONFIG_INET_IPCOMP is not set +# CONFIG_INET_XFRM_TUNNEL is not set +# CONFIG_INET_TUNNEL is not set +# CONFIG_INET_XFRM_MODE_TRANSPORT is not set +# CONFIG_INET_XFRM_MODE_TUNNEL is not set +# CONFIG_INET_XFRM_MODE_BEET is not set +CONFIG_INET_DIAG=y +CONFIG_INET_TCP_DIAG=y +# CONFIG_INET_UDP_DIAG is not set +# CONFIG_INET_RAW_DIAG is not set +# CONFIG_INET_DIAG_DESTROY is not set +# CONFIG_TCP_CONG_ADVANCED is not set +CONFIG_TCP_CONG_CUBIC=y +CONFIG_DEFAULT_TCP_CONG="cubic" +# CONFIG_TCP_MD5SIG is not set +# CONFIG_IPV6 is not set +# CONFIG_NETWORK_SECMARK is not set +CONFIG_NET_PTP_CLASSIFY=y +# CONFIG_NETWORK_PHY_TIMESTAMPING is not set +# CONFIG_NETFILTER is not set +# CONFIG_IP_DCCP is not set +# CONFIG_IP_SCTP is not set +# CONFIG_RDS is not set +# CONFIG_TIPC is not set +# CONFIG_ATM is not set +# CONFIG_L2TP is not set +# CONFIG_BRIDGE is not set +CONFIG_HAVE_NET_DSA=y +# CONFIG_NET_DSA is not set +# CONFIG_VLAN_8021Q is not set +# CONFIG_DECNET is not set +# CONFIG_LLC2 is not set +# CONFIG_IPX is not set +# CONFIG_ATALK is not set +# CONFIG_X25 is not set +# CONFIG_LAPB is not set +# CONFIG_PHONET is not set +# CONFIG_IEEE802154 is not set +# CONFIG_NET_SCHED is not set +# CONFIG_DCB is not set +CONFIG_DNS_RESOLVER=y +# CONFIG_BATMAN_ADV is not set +# CONFIG_OPENVSWITCH is not set +# CONFIG_VSOCKETS is not set +# CONFIG_NETLINK_DIAG is not set +# CONFIG_MPLS is not set +# CONFIG_HSR is not set +# CONFIG_NET_SWITCHDEV is not set +# CONFIG_NET_L3_MASTER_DEV is not set +# CONFIG_NET_NCSI is not set +CONFIG_RPS=y +CONFIG_RFS_ACCEL=y +CONFIG_XPS=y +# CONFIG_CGROUP_NET_PRIO is not set +# CONFIG_CGROUP_NET_CLASSID is not set +CONFIG_NET_RX_BUSY_POLL=y +CONFIG_BQL=y +CONFIG_BPF_JIT=y +CONFIG_NET_FLOW_LIMIT=y + +# +# Network testing +# +# CONFIG_NET_PKTGEN is not set +# CONFIG_HAMRADIO is not set +# CONFIG_CAN is not set +# CONFIG_IRDA is not set +# CONFIG_BT is not set +# CONFIG_AF_RXRPC is not set +# CONFIG_AF_KCM is not set +# CONFIG_STREAM_PARSER is not set +# CONFIG_WIRELESS is not set +# CONFIG_WIMAX is not set +# CONFIG_RFKILL is not set +# CONFIG_NET_9P is not set +# CONFIG_CAIF is not set +# CONFIG_CEPH_LIB is not set +# CONFIG_NFC is not set +# CONFIG_PSAMPLE is not set +# CONFIG_NET_IFE is not set +# CONFIG_LWTUNNEL is not set +# CONFIG_DST_CACHE is not set +# CONFIG_GRO_CELLS is not set +# CONFIG_NET_DEVLINK is not set +CONFIG_MAY_USE_DEVLINK=y +CONFIG_HAVE_EBPF_JIT=y + +# +# Device Drivers +# +CONFIG_ARM_AMBA=y + +# +# Generic Driver Options +# +CONFIG_UEVENT_HELPER=y +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +CONFIG_STANDALONE=y +CONFIG_PREVENT_FIRMWARE_BUILD=y +CONFIG_FW_LOADER=y +CONFIG_FIRMWARE_IN_KERNEL=y +CONFIG_EXTRA_FIRMWARE="" +# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set +CONFIG_ALLOW_DEV_COREDUMP=y +# CONFIG_DEBUG_DRIVER is not set +# CONFIG_DEBUG_DEVRES is not set +# CONFIG_DEBUG_TEST_DRIVER_REMOVE is not set +# CONFIG_TEST_ASYNC_DRIVER_PROBE is not set +# CONFIG_SYS_HYPERVISOR is not set +# CONFIG_GENERIC_CPU_DEVICES is not set +CONFIG_GENERIC_CPU_AUTOPROBE=y +CONFIG_SOC_BUS=y +CONFIG_REGMAP=y +CONFIG_REGMAP_I2C=y +CONFIG_REGMAP_SPI=y +CONFIG_REGMAP_MMIO=y +CONFIG_DMA_SHARED_BUFFER=y +# CONFIG_DMA_FENCE_TRACE is not set +CONFIG_DMA_CMA=y + +# +# Default contiguous memory area size: +# +CONFIG_CMA_SIZE_MBYTES=256 +CONFIG_CMA_SIZE_SEL_MBYTES=y +# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set +# CONFIG_CMA_SIZE_SEL_MIN is not set +# CONFIG_CMA_SIZE_SEL_MAX is not set +CONFIG_CMA_ALIGNMENT=8 +CONFIG_GENERIC_ARCH_TOPOLOGY=y + +# +# Bus devices +# +# CONFIG_ARM_CCI400_PMU is not set +# CONFIG_ARM_CCI5xx_PMU is not set +# CONFIG_ARM_CCN is not set +# CONFIG_BRCMSTB_GISB_ARB is not set +# CONFIG_SIMPLE_PM_BUS is not set +CONFIG_VEXPRESS_CONFIG=y +# CONFIG_CONNECTOR is not set +# CONFIG_MTD is not set +CONFIG_DTC=y +CONFIG_OF=y +# CONFIG_OF_UNITTEST is not set +CONFIG_OF_FLATTREE=y +CONFIG_OF_EARLY_FLATTREE=y +CONFIG_OF_ADDRESS=y +CONFIG_OF_IRQ=y +CONFIG_OF_NET=y +CONFIG_OF_MDIO=y +CONFIG_OF_RESERVED_MEM=y +# CONFIG_OF_OVERLAY is not set +# CONFIG_PARPORT is not set +CONFIG_BLK_DEV=y +# CONFIG_BLK_DEV_NULL_BLK is not set +# CONFIG_BLK_DEV_COW_COMMON is not set +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 +# CONFIG_BLK_DEV_CRYPTOLOOP is not set +# CONFIG_BLK_DEV_DRBD is not set +# CONFIG_BLK_DEV_NBD is not set +# CONFIG_BLK_DEV_RAM is not set +# CONFIG_CDROM_PKTCDVD is not set +# CONFIG_ATA_OVER_ETH is not set +# CONFIG_BLK_DEV_RBD is not set +# CONFIG_NVME_FC is not set + +# +# Misc devices +# +# CONFIG_SENSORS_LIS3LV02D is not set +# CONFIG_AD525X_DPOT is not set +# CONFIG_DUMMY_IRQ is not set +# CONFIG_ICS932S401 is not set +# CONFIG_ENCLOSURE_SERVICES is not set +# CONFIG_APDS9802ALS is not set +# CONFIG_ISL29003 is not set +# CONFIG_ISL29020 is not set +# CONFIG_SENSORS_TSL2550 is not set +# CONFIG_SENSORS_BH1770 is not set +# CONFIG_SENSORS_APDS990X is not set +# CONFIG_HMC6352 is not set +# CONFIG_DS1682 is not set +# CONFIG_TI_DAC7512 is not set +# CONFIG_USB_SWITCH_FSA9480 is not set +# CONFIG_LATTICE_ECP3_CONFIG is not set +# CONFIG_SRAM is not set +# CONFIG_VEXPRESS_SYSCFG is not set +# CONFIG_C2PORT is not set + +# +# EEPROM support +# +CONFIG_EEPROM_AT24=y +# CONFIG_EEPROM_AT25 is not set +# CONFIG_EEPROM_LEGACY is not set +# CONFIG_EEPROM_MAX6875 is not set +# CONFIG_EEPROM_93CX6 is not set +# CONFIG_EEPROM_93XX46 is not set +# CONFIG_EEPROM_IDT_89HPESX is not set + +# +# Texas Instruments shared transport line discipline +# +# CONFIG_TI_ST is not set +# CONFIG_SENSORS_LIS3_SPI is not set +# CONFIG_SENSORS_LIS3_I2C is not set + +# +# Altera FPGA firmware download module +# +# CONFIG_ALTERA_STAPL is not set + +# +# Intel MIC Bus Driver +# + +# +# SCIF Bus Driver +# + +# +# VOP Bus Driver +# + +# +# Intel MIC Host Driver +# + +# +# Intel MIC Card Driver +# + +# +# SCIF Driver +# + +# +# Intel MIC Coprocessor State Management (COSM) Drivers +# + +# +# VOP Driver +# +# CONFIG_ECHO is not set +# CONFIG_CXL_BASE is not set +# CONFIG_CXL_AFU_DRIVER_OPS is not set +# CONFIG_CXL_LIB is not set + +# +# SCSI device support +# +CONFIG_SCSI_MOD=y +# CONFIG_RAID_ATTRS is not set +CONFIG_SCSI=y +CONFIG_SCSI_DMA=y +# CONFIG_SCSI_NETLINK is not set +# CONFIG_SCSI_PROC_FS is not set + +# +# SCSI support type (disk, tape, CD-ROM) +# +CONFIG_BLK_DEV_SD=y +# CONFIG_CHR_DEV_ST is not set +# CONFIG_CHR_DEV_OSST is not set +# CONFIG_BLK_DEV_SR is not set +# CONFIG_CHR_DEV_SG is not set +# CONFIG_CHR_DEV_SCH is not set +# CONFIG_SCSI_CONSTANTS is not set +# CONFIG_SCSI_LOGGING is not set +# CONFIG_SCSI_SCAN_ASYNC is not set + +# +# SCSI Transports +# +# CONFIG_SCSI_SPI_ATTRS is not set +# CONFIG_SCSI_FC_ATTRS is not set +# CONFIG_SCSI_ISCSI_ATTRS is not set +# CONFIG_SCSI_SAS_ATTRS is not set +# CONFIG_SCSI_SAS_LIBSAS is not set +# CONFIG_SCSI_SRP_ATTRS is not set +# CONFIG_SCSI_LOWLEVEL is not set +# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set +# CONFIG_SCSI_DH is not set +# CONFIG_SCSI_OSD_INITIATOR is not set +CONFIG_HAVE_PATA_PLATFORM=y +# CONFIG_ATA is not set +# CONFIG_MD is not set +# CONFIG_TARGET_CORE is not set +CONFIG_NETDEVICES=y +CONFIG_MII=y +CONFIG_NET_CORE=y +# CONFIG_BONDING is not set +# CONFIG_DUMMY is not set +# CONFIG_EQUALIZER is not set +# CONFIG_NET_TEAM is not set +# CONFIG_MACVLAN is not set +# CONFIG_VXLAN is not set +# CONFIG_MACSEC is not set +# CONFIG_NETCONSOLE is not set +# CONFIG_NETPOLL is not set +# CONFIG_NET_POLL_CONTROLLER is not set +CONFIG_TUN=y +# CONFIG_TUN_VNET_CROSS_LE is not set +# CONFIG_VETH is not set +# CONFIG_NLMON is not set + +# +# CAIF transport drivers +# + +# +# Distributed Switch Architecture drivers +# +CONFIG_ETHERNET=y +# CONFIG_NET_VENDOR_ALACRITECH is not set +# CONFIG_ALTERA_TSE is not set +# CONFIG_NET_VENDOR_AMAZON is not set +# CONFIG_NET_VENDOR_AMD is not set +# CONFIG_NET_VENDOR_AQUANTIA is not set +# CONFIG_NET_VENDOR_ARC is not set +# CONFIG_NET_VENDOR_AURORA is not set +# CONFIG_NET_CADENCE is not set +# CONFIG_NET_VENDOR_BROADCOM is not set +# CONFIG_DNET is not set +# CONFIG_NET_VENDOR_EZCHIP is not set +# CONFIG_NET_VENDOR_HISILICON is not set +# CONFIG_NET_VENDOR_INTEL is not set +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MICREL is not set +# CONFIG_NET_VENDOR_MICROCHIP is not set +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_NETRONOME is not set +# CONFIG_ETHOC is not set +# CONFIG_NET_VENDOR_QUALCOMM is not set +CONFIG_NET_VENDOR_RENESAS=y +# CONFIG_SH_ETH is not set +CONFIG_RAVB=y +# CONFIG_NET_VENDOR_ROCKER is not set +# CONFIG_NET_VENDOR_SAMSUNG is not set +# CONFIG_NET_VENDOR_SEEQ is not set +# CONFIG_NET_VENDOR_SOLARFLARE is not set +# CONFIG_NET_VENDOR_SMSC is not set +# CONFIG_NET_VENDOR_STMICRO is not set +# CONFIG_NET_VENDOR_VIA is not set +# CONFIG_NET_VENDOR_WIZNET is not set +# CONFIG_NET_VENDOR_SYNOPSYS is not set +CONFIG_MDIO_DEVICE=y +CONFIG_MDIO_BUS=y +# CONFIG_MDIO_BCM_UNIMAC is not set +CONFIG_MDIO_BITBANG=y +# CONFIG_MDIO_BUS_MUX_GPIO is not set +# CONFIG_MDIO_BUS_MUX_MMIOREG is not set +# CONFIG_MDIO_GPIO is not set +# CONFIG_MDIO_HISI_FEMAC is not set +# CONFIG_MDIO_OCTEON is not set +CONFIG_PHYLIB=y +CONFIG_SWPHY=y +# CONFIG_LED_TRIGGER_PHY is not set + +# +# MII PHY device drivers +# +# CONFIG_AMD_PHY is not set +# CONFIG_AQUANTIA_PHY is not set +# CONFIG_AT803X_PHY is not set +# CONFIG_BCM7XXX_PHY is not set +# CONFIG_BCM87XX_PHY is not set +# CONFIG_BROADCOM_PHY is not set +# CONFIG_CICADA_PHY is not set +# CONFIG_CORTINA_PHY is not set +# CONFIG_DAVICOM_PHY is not set +# CONFIG_DP83848_PHY is not set +# CONFIG_DP83867_PHY is not set +CONFIG_FIXED_PHY=y +# CONFIG_ICPLUS_PHY is not set +# CONFIG_INTEL_XWAY_PHY is not set +# CONFIG_LSI_ET1011C_PHY is not set +# CONFIG_LXT_PHY is not set +# CONFIG_MARVELL_PHY is not set +# CONFIG_MARVELL_10G_PHY is not set +CONFIG_MICREL_PHY=y +# CONFIG_MICROCHIP_PHY is not set +# CONFIG_MICROSEMI_PHY is not set +# CONFIG_NATIONAL_PHY is not set +# CONFIG_QSEMI_PHY is not set +# CONFIG_REALTEK_PHY is not set +# CONFIG_SMSC_PHY is not set +# CONFIG_STE10XP is not set +# CONFIG_TERANETICS_PHY is not set +# CONFIG_VITESSE_PHY is not set +# CONFIG_XILINX_GMII2RGMII is not set +# CONFIG_MICREL_KS8995MA is not set +# CONFIG_PPP is not set +# CONFIG_SLIP is not set + +# +# Host-side USB support is needed for USB Network Adapter support +# +# CONFIG_WLAN is not set + +# +# Enable WiMAX (Networking options) to see the WiMAX drivers +# +# CONFIG_WAN is not set +# CONFIG_ISDN is not set +# CONFIG_NVM is not set + +# +# Input device support +# +CONFIG_INPUT=y +CONFIG_INPUT_LEDS=y +# CONFIG_INPUT_FF_MEMLESS is not set +# CONFIG_INPUT_POLLDEV is not set +# CONFIG_INPUT_SPARSEKMAP is not set +# CONFIG_INPUT_MATRIXKMAP is not set + +# +# Userland interfaces +# +CONFIG_INPUT_MOUSEDEV=y +CONFIG_INPUT_MOUSEDEV_PSAUX=y +CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 +CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 +# CONFIG_INPUT_JOYDEV is not set +CONFIG_INPUT_EVDEV=y +# CONFIG_INPUT_EVBUG is not set + +# +# Input Device Drivers +# +CONFIG_INPUT_KEYBOARD=y +# CONFIG_KEYBOARD_ADP5588 is not set +# CONFIG_KEYBOARD_ADP5589 is not set +# CONFIG_KEYBOARD_ATKBD is not set +# CONFIG_KEYBOARD_QT1070 is not set +# CONFIG_KEYBOARD_QT2160 is not set +# CONFIG_KEYBOARD_DLINK_DIR685 is not set +# CONFIG_KEYBOARD_LKKBD is not set +CONFIG_KEYBOARD_GPIO=y +# CONFIG_KEYBOARD_GPIO_POLLED is not set +# CONFIG_KEYBOARD_TCA6416 is not set +# CONFIG_KEYBOARD_TCA8418 is not set +# CONFIG_KEYBOARD_MATRIX is not set +# CONFIG_KEYBOARD_LM8323 is not set +# CONFIG_KEYBOARD_LM8333 is not set +# CONFIG_KEYBOARD_MAX7359 is not set +# CONFIG_KEYBOARD_MCS is not set +# CONFIG_KEYBOARD_MPR121 is not set +# CONFIG_KEYBOARD_NEWTON is not set +# CONFIG_KEYBOARD_OPENCORES is not set +# CONFIG_KEYBOARD_SAMSUNG is not set +# CONFIG_KEYBOARD_STOWAWAY is not set +# CONFIG_KEYBOARD_SUNKBD is not set +# CONFIG_KEYBOARD_SH_KEYSC is not set +# CONFIG_KEYBOARD_OMAP4 is not set +# CONFIG_KEYBOARD_TM2_TOUCHKEY is not set +# CONFIG_KEYBOARD_XTKBD is not set +# CONFIG_KEYBOARD_CAP11XX is not set +# CONFIG_KEYBOARD_BCM is not set +# CONFIG_INPUT_MOUSE is not set +# CONFIG_INPUT_JOYSTICK is not set +# CONFIG_INPUT_TABLET is not set +# CONFIG_INPUT_TOUCHSCREEN is not set +# CONFIG_INPUT_MISC is not set +# CONFIG_RMI4_CORE is not set + +# +# Hardware I/O ports +# +CONFIG_SERIO=y +# CONFIG_SERIO_SERPORT is not set +# CONFIG_SERIO_AMBAKMI is not set +# CONFIG_SERIO_LIBPS2 is not set +# CONFIG_SERIO_RAW is not set +# CONFIG_SERIO_ALTERA_PS2 is not set +# CONFIG_SERIO_PS2MULT is not set +# CONFIG_SERIO_ARC_PS2 is not set +# CONFIG_SERIO_APBPS2 is not set +# CONFIG_USERIO is not set +# CONFIG_GAMEPORT is not set + +# +# Character devices +# +CONFIG_TTY=y +CONFIG_VT=y +CONFIG_CONSOLE_TRANSLATIONS=y +CONFIG_VT_CONSOLE=y +CONFIG_VT_CONSOLE_SLEEP=y +CONFIG_HW_CONSOLE=y +CONFIG_VT_HW_CONSOLE_BINDING=y +CONFIG_UNIX98_PTYS=y +CONFIG_LEGACY_PTYS=y +CONFIG_LEGACY_PTY_COUNT=16 +# CONFIG_SERIAL_NONSTANDARD is not set +# CONFIG_N_GSM is not set +# CONFIG_TRACE_SINK is not set +CONFIG_DEVMEM=y + +# +# Serial drivers +# +CONFIG_SERIAL_EARLYCON=y +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y +# CONFIG_SERIAL_8250_FINTEK is not set +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_DMA=y +CONFIG_SERIAL_8250_NR_UARTS=4 +CONFIG_SERIAL_8250_RUNTIME_UARTS=4 +# CONFIG_SERIAL_8250_EXTENDED is not set +# CONFIG_SERIAL_8250_ASPEED_VUART is not set +CONFIG_SERIAL_8250_FSL=y +CONFIG_SERIAL_8250_DW=y +# CONFIG_SERIAL_8250_RT288X is not set +CONFIG_SERIAL_OF_PLATFORM=y + +# +# Non-8250 serial port support +# +# CONFIG_SERIAL_AMBA_PL010 is not set +CONFIG_SERIAL_AMBA_PL011=y +CONFIG_SERIAL_AMBA_PL011_CONSOLE=y +# CONFIG_SERIAL_EARLYCON_ARM_SEMIHOST is not set +# CONFIG_SERIAL_MAX3100 is not set +# CONFIG_SERIAL_MAX310X is not set +# CONFIG_SERIAL_UARTLITE is not set +CONFIG_SERIAL_SH_SCI=y +CONFIG_SERIAL_SH_SCI_NR_UARTS=11 +CONFIG_SERIAL_SH_SCI_CONSOLE=y +# CONFIG_SERIAL_SH_SCI_EARLYCON is not set +# CONFIG_SERIAL_SH_SCI_DMA is not set +CONFIG_SERIAL_CORE=y +CONFIG_SERIAL_CORE_CONSOLE=y +# CONFIG_SERIAL_SCCNXP is not set +# CONFIG_SERIAL_SC16IS7XX is not set +# CONFIG_SERIAL_ALTERA_JTAGUART is not set +# CONFIG_SERIAL_ALTERA_UART is not set +# CONFIG_SERIAL_IFX6X60 is not set +CONFIG_SERIAL_XILINX_PS_UART=y +CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y +# CONFIG_SERIAL_ARC is not set +# CONFIG_SERIAL_FSL_LPUART is not set +# CONFIG_SERIAL_CONEXANT_DIGICOLOR is not set +CONFIG_SERIAL_MCTRL_GPIO=y +# CONFIG_SERIAL_DEV_BUS is not set +# CONFIG_HVC_DCC is not set +# CONFIG_IPMI_HANDLER is not set +# CONFIG_HW_RANDOM is not set +# CONFIG_R3964 is not set + +# +# PCMCIA character devices +# +# CONFIG_RAW_DRIVER is not set +# CONFIG_TCG_TPM is not set +# CONFIG_XILLYBUS is not set + +# +# I2C support +# +CONFIG_I2C=y +CONFIG_I2C_BOARDINFO=y +CONFIG_I2C_COMPAT=y +# CONFIG_I2C_CHARDEV is not set +CONFIG_I2C_MUX=y + +# +# Multiplexer I2C Chip support +# +# CONFIG_I2C_ARB_GPIO_CHALLENGE is not set +# CONFIG_I2C_MUX_GPIO is not set +# CONFIG_I2C_MUX_GPMUX is not set +# CONFIG_I2C_MUX_LTC4306 is not set +# CONFIG_I2C_MUX_PCA9541 is not set +# CONFIG_I2C_MUX_PCA954x is not set +# CONFIG_I2C_MUX_PINCTRL is not set +# CONFIG_I2C_MUX_REG is not set +# CONFIG_I2C_DEMUX_PINCTRL is not set +# CONFIG_I2C_MUX_MLXCPLD is not set +CONFIG_I2C_HELPER_AUTO=y +CONFIG_I2C_ALGOBIT=y + +# +# I2C Hardware Bus support +# + +# +# I2C system bus drivers (mostly embedded / system-on-chip) +# +# CONFIG_I2C_CADENCE is not set +# CONFIG_I2C_CBUS_GPIO is not set +# CONFIG_I2C_DESIGNWARE_PLATFORM is not set +# CONFIG_I2C_EMEV2 is not set +CONFIG_I2C_GPIO=y +# CONFIG_I2C_NOMADIK is not set +# CONFIG_I2C_OCORES is not set +# CONFIG_I2C_PCA_PLATFORM is not set +# CONFIG_I2C_PXA_PCI is not set +# CONFIG_I2C_RIIC is not set +# CONFIG_I2C_RK3X is not set +CONFIG_I2C_SH_MOBILE=y +# CONFIG_I2C_SIMTEC is not set +# CONFIG_I2C_XILINX is not set +CONFIG_I2C_RCAR=y + +# +# External I2C/SMBus adapter drivers +# +# CONFIG_I2C_PARPORT_LIGHT is not set +# CONFIG_I2C_TAOS_EVM is not set + +# +# Other I2C/SMBus bus drivers +# +# CONFIG_I2C_STUB is not set +CONFIG_I2C_SLAVE=y +# CONFIG_I2C_SLAVE_EEPROM is not set +# CONFIG_I2C_DEBUG_CORE is not set +# CONFIG_I2C_DEBUG_ALGO is not set +# CONFIG_I2C_DEBUG_BUS is not set +CONFIG_SPI=y +# CONFIG_SPI_DEBUG is not set +CONFIG_SPI_MASTER=y + +# +# SPI Master Controller Drivers +# +# CONFIG_SPI_ALTERA is not set +# CONFIG_SPI_AXI_SPI_ENGINE is not set +# CONFIG_SPI_BITBANG is not set +# CONFIG_SPI_CADENCE is not set +# CONFIG_SPI_DESIGNWARE is not set +# CONFIG_SPI_GPIO is not set +# CONFIG_SPI_FSL_SPI is not set +# CONFIG_SPI_OC_TINY is not set +CONFIG_SPI_PL022=y +# CONFIG_SPI_PXA2XX_PCI is not set +# CONFIG_SPI_ROCKCHIP is not set +# CONFIG_SPI_RSPI is not set +# CONFIG_SPI_SC18IS602 is not set +CONFIG_SPI_SH_MSIOF=y +# CONFIG_SPI_SH_HSPI is not set +# CONFIG_SPI_XCOMM is not set +# CONFIG_SPI_XILINX is not set +# CONFIG_SPI_ZYNQMP_GQSPI is not set + +# +# SPI Protocol Masters +# +CONFIG_SPI_SPIDEV=y +# CONFIG_SPI_LOOPBACK_TEST is not set +# CONFIG_SPI_TLE62X0 is not set +# CONFIG_SPI_SLAVE is not set +# CONFIG_SPMI is not set +# CONFIG_HSI is not set +CONFIG_PPS=y +# CONFIG_PPS_DEBUG is not set + +# +# PPS clients support +# +# CONFIG_PPS_CLIENT_KTIMER is not set +# CONFIG_PPS_CLIENT_LDISC is not set +# CONFIG_PPS_CLIENT_GPIO is not set + +# +# PPS generators support +# + +# +# PTP clock support +# +CONFIG_PTP_1588_CLOCK=y + +# +# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks. +# +CONFIG_PINCTRL=y + +# +# Pin controllers +# +CONFIG_PINMUX=y +CONFIG_PINCONF=y +CONFIG_GENERIC_PINCONF=y +# CONFIG_DEBUG_PINCTRL is not set +# CONFIG_PINCTRL_AMD is not set +# CONFIG_PINCTRL_MCP23S08 is not set +# CONFIG_PINCTRL_SINGLE is not set +# CONFIG_PINCTRL_SX150X is not set +CONFIG_PINCTRL_SH_PFC=y +CONFIG_PINCTRL_PFC_R8A7795=y +CONFIG_PINCTRL_PFC_R8A7796=y +CONFIG_GPIOLIB=y +CONFIG_OF_GPIO=y +CONFIG_GPIOLIB_IRQCHIP=y +# CONFIG_DEBUG_GPIO is not set +# CONFIG_GPIO_SYSFS is not set +CONFIG_GPIO_GENERIC=y + +# +# Memory mapped GPIO drivers +# +# CONFIG_GPIO_74XX_MMIO is not set +# CONFIG_GPIO_ALTERA is not set +# CONFIG_GPIO_DWAPB is not set +# CONFIG_GPIO_FTGPIO010 is not set +CONFIG_GPIO_GENERIC_PLATFORM=y +# CONFIG_GPIO_GRGPIO is not set +# CONFIG_GPIO_MOCKUP is not set +CONFIG_GPIO_PL061=y +CONFIG_GPIO_RCAR=y +# CONFIG_GPIO_SYSCON is not set +CONFIG_GPIO_XGENE=y +# CONFIG_GPIO_XILINX is not set + +# +# I2C GPIO expanders +# +# CONFIG_GPIO_ADP5588 is not set +# CONFIG_GPIO_ADNP is not set +# CONFIG_GPIO_MAX7300 is not set +# CONFIG_GPIO_MAX732X is not set +# CONFIG_GPIO_PCA953X is not set +# CONFIG_GPIO_PCF857X is not set +# CONFIG_GPIO_SX150X is not set +# CONFIG_GPIO_TPIC2810 is not set + +# +# MFD GPIO expanders +# + +# +# SPI GPIO expanders +# +# CONFIG_GPIO_74X164 is not set +# CONFIG_GPIO_MAX7301 is not set +# CONFIG_GPIO_MC33880 is not set +# CONFIG_GPIO_PISOSR is not set +# CONFIG_GPIO_XRA1403 is not set +# CONFIG_W1 is not set +CONFIG_POWER_AVS=y +CONFIG_POWER_RESET=y +# CONFIG_POWER_RESET_BRCMSTB is not set +# CONFIG_POWER_RESET_GPIO is not set +# CONFIG_POWER_RESET_GPIO_RESTART is not set +# CONFIG_POWER_RESET_LTC2952 is not set +# CONFIG_POWER_RESET_RESTART is not set +CONFIG_POWER_RESET_VEXPRESS=y +CONFIG_POWER_RESET_XGENE=y +CONFIG_POWER_RESET_SYSCON=y +# CONFIG_POWER_RESET_SYSCON_POWEROFF is not set +# CONFIG_SYSCON_REBOOT_MODE is not set +CONFIG_POWER_SUPPLY=y +# CONFIG_POWER_SUPPLY_DEBUG is not set +# CONFIG_PDA_POWER is not set +# CONFIG_TEST_POWER is not set +# CONFIG_BATTERY_DS2780 is not set +# CONFIG_BATTERY_DS2781 is not set +# CONFIG_BATTERY_DS2782 is not set +# CONFIG_BATTERY_SBS is not set +# CONFIG_CHARGER_SBS is not set +# CONFIG_BATTERY_BQ27XXX is not set +# CONFIG_BATTERY_MAX17040 is not set +# CONFIG_BATTERY_MAX17042 is not set +# CONFIG_CHARGER_MAX8903 is not set +# CONFIG_CHARGER_LP8727 is not set +# CONFIG_CHARGER_GPIO is not set +# CONFIG_CHARGER_MANAGER is not set +# CONFIG_CHARGER_LTC3651 is not set +# CONFIG_CHARGER_DETECTOR_MAX14656 is not set +# CONFIG_CHARGER_BQ2415X is not set +# CONFIG_CHARGER_BQ24257 is not set +# CONFIG_CHARGER_BQ24735 is not set +# CONFIG_CHARGER_BQ25890 is not set +# CONFIG_CHARGER_SMB347 is not set +# CONFIG_BATTERY_GAUGE_LTC2941 is not set +# CONFIG_CHARGER_RT9455 is not set +# CONFIG_HWMON is not set +CONFIG_THERMAL=y +CONFIG_THERMAL_EMERGENCY_POWEROFF_DELAY_MS=0 +CONFIG_THERMAL_OF=y +# CONFIG_THERMAL_WRITABLE_TRIPS is not set +# CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE is not set +# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set +# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set +CONFIG_THERMAL_DEFAULT_GOV_POWER_ALLOCATOR=y +# CONFIG_THERMAL_GOV_FAIR_SHARE is not set +# CONFIG_THERMAL_GOV_STEP_WISE is not set +# CONFIG_THERMAL_GOV_BANG_BANG is not set +# CONFIG_THERMAL_GOV_USER_SPACE is not set +CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y +CONFIG_CPU_THERMAL=y +# CONFIG_CLOCK_THERMAL is not set +# CONFIG_THERMAL_EMULATION is not set +# CONFIG_QORIQ_THERMAL is not set +# CONFIG_RCAR_THERMAL is not set +CONFIG_RCAR_GEN3_THERMAL=y + +# +# ACPI INT340X thermal drivers +# +# CONFIG_WATCHDOG is not set +CONFIG_SSB_POSSIBLE=y + +# +# Sonics Silicon Backplane +# +# CONFIG_SSB is not set +CONFIG_BCMA_POSSIBLE=y + +# +# Broadcom specific AMBA +# +# CONFIG_BCMA is not set + +# +# Multifunction device drivers +# +# CONFIG_MFD_CORE is not set +# CONFIG_MFD_ACT8945A is not set +# CONFIG_MFD_AS3711 is not set +# CONFIG_MFD_AS3722 is not set +# CONFIG_PMIC_ADP5520 is not set +# CONFIG_MFD_AAT2870_CORE is not set +# CONFIG_MFD_ATMEL_FLEXCOM is not set +# CONFIG_MFD_ATMEL_HLCDC is not set +# CONFIG_MFD_BCM590XX is not set +# CONFIG_MFD_AXP20X_I2C is not set +# CONFIG_MFD_CROS_EC is not set +# CONFIG_PMIC_DA903X is not set +# CONFIG_MFD_DA9052_SPI is not set +# CONFIG_MFD_DA9052_I2C is not set +# CONFIG_MFD_DA9055 is not set +# CONFIG_MFD_DA9062 is not set +# CONFIG_MFD_DA9063 is not set +# CONFIG_MFD_DA9150 is not set +# CONFIG_MFD_MC13XXX_SPI is not set +# CONFIG_MFD_MC13XXX_I2C is not set +# CONFIG_MFD_HI6421_PMIC is not set +# CONFIG_HTC_PASIC3 is not set +# CONFIG_HTC_I2CPLD is not set +# CONFIG_MFD_KEMPLD is not set +# CONFIG_MFD_88PM800 is not set +# CONFIG_MFD_88PM805 is not set +# CONFIG_MFD_88PM860X is not set +# CONFIG_MFD_MAX14577 is not set +# CONFIG_MFD_MAX77620 is not set +# CONFIG_MFD_MAX77686 is not set +# CONFIG_MFD_MAX77693 is not set +# CONFIG_MFD_MAX77843 is not set +# CONFIG_MFD_MAX8907 is not set +# CONFIG_MFD_MAX8925 is not set +# CONFIG_MFD_MAX8997 is not set +# CONFIG_MFD_MAX8998 is not set +# CONFIG_MFD_MT6397 is not set +# CONFIG_MFD_MENF21BMC is not set +# CONFIG_EZX_PCAP is not set +# CONFIG_MFD_CPCAP is not set +# CONFIG_MFD_RETU is not set +# CONFIG_MFD_PCF50633 is not set +# CONFIG_MFD_RT5033 is not set +# CONFIG_MFD_RC5T583 is not set +# CONFIG_MFD_RK808 is not set +# CONFIG_MFD_RN5T618 is not set +# CONFIG_MFD_SEC_CORE is not set +# CONFIG_MFD_SI476X_CORE is not set +# CONFIG_MFD_SM501 is not set +# CONFIG_MFD_SKY81452 is not set +# CONFIG_MFD_SMSC is not set +# CONFIG_ABX500_CORE is not set +# CONFIG_MFD_STMPE is not set +CONFIG_MFD_SYSCON=y +# CONFIG_MFD_TI_AM335X_TSCADC is not set +# CONFIG_MFD_LP3943 is not set +# CONFIG_MFD_LP8788 is not set +# CONFIG_MFD_TI_LMU is not set +# CONFIG_MFD_PALMAS is not set +# CONFIG_TPS6105X is not set +# CONFIG_TPS65010 is not set +# CONFIG_TPS6507X is not set +# CONFIG_MFD_TPS65086 is not set +# CONFIG_MFD_TPS65090 is not set +# CONFIG_MFD_TPS65217 is not set +# CONFIG_MFD_TI_LP873X is not set +# CONFIG_MFD_TI_LP87565 is not set +# CONFIG_MFD_TPS65218 is not set +# CONFIG_MFD_TPS6586X is not set +# CONFIG_MFD_TPS65910 is not set +# CONFIG_MFD_TPS65912_I2C is not set +# CONFIG_MFD_TPS65912_SPI is not set +# CONFIG_MFD_TPS80031 is not set +# CONFIG_TWL4030_CORE is not set +# CONFIG_TWL6040_CORE is not set +# CONFIG_MFD_WL1273_CORE is not set +# CONFIG_MFD_LM3533 is not set +# CONFIG_MFD_TC3589X is not set +# CONFIG_MFD_TMIO is not set +# CONFIG_MFD_ARIZONA_I2C is not set +# CONFIG_MFD_ARIZONA_SPI is not set +# CONFIG_MFD_WM8400 is not set +# CONFIG_MFD_WM831X_I2C is not set +# CONFIG_MFD_WM831X_SPI is not set +# CONFIG_MFD_WM8350_I2C is not set +# CONFIG_MFD_WM8994 is not set +# CONFIG_MFD_VEXPRESS_SYSREG is not set +CONFIG_REGULATOR=y +# CONFIG_REGULATOR_DEBUG is not set +CONFIG_REGULATOR_FIXED_VOLTAGE=y +# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set +# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set +# CONFIG_REGULATOR_ACT8865 is not set +# CONFIG_REGULATOR_AD5398 is not set +# CONFIG_REGULATOR_ANATOP is not set +# CONFIG_REGULATOR_DA9210 is not set +# CONFIG_REGULATOR_DA9211 is not set +# CONFIG_REGULATOR_FAN53555 is not set +CONFIG_REGULATOR_GPIO=y +# CONFIG_REGULATOR_ISL9305 is not set +# CONFIG_REGULATOR_ISL6271A is not set +# CONFIG_REGULATOR_LP3971 is not set +# CONFIG_REGULATOR_LP3972 is not set +# CONFIG_REGULATOR_LP872X is not set +# CONFIG_REGULATOR_LP8755 is not set +# CONFIG_REGULATOR_LTC3589 is not set +# CONFIG_REGULATOR_LTC3676 is not set +# CONFIG_REGULATOR_MAX1586 is not set +# CONFIG_REGULATOR_MAX8649 is not set +# CONFIG_REGULATOR_MAX8660 is not set +# CONFIG_REGULATOR_MAX8952 is not set +# CONFIG_REGULATOR_MAX8973 is not set +# CONFIG_REGULATOR_MT6311 is not set +# CONFIG_REGULATOR_PFUZE100 is not set +# CONFIG_REGULATOR_PV88060 is not set +# CONFIG_REGULATOR_PV88080 is not set +# CONFIG_REGULATOR_PV88090 is not set +# CONFIG_REGULATOR_PWM is not set +# CONFIG_REGULATOR_TPS51632 is not set +# CONFIG_REGULATOR_TPS62360 is not set +# CONFIG_REGULATOR_TPS65023 is not set +# CONFIG_REGULATOR_TPS6507X is not set +# CONFIG_REGULATOR_TPS65132 is not set +# CONFIG_REGULATOR_TPS6524X is not set +# CONFIG_REGULATOR_VCTRL is not set +# CONFIG_REGULATOR_VEXPRESS is not set +CONFIG_MEDIA_SUPPORT=y + +# +# Multimedia core support +# +CONFIG_MEDIA_CAMERA_SUPPORT=y +# CONFIG_MEDIA_ANALOG_TV_SUPPORT is not set +# CONFIG_MEDIA_DIGITAL_TV_SUPPORT is not set +# CONFIG_MEDIA_RADIO_SUPPORT is not set +# CONFIG_MEDIA_SDR_SUPPORT is not set +# CONFIG_MEDIA_RC_SUPPORT is not set +# CONFIG_MEDIA_CEC_SUPPORT is not set +CONFIG_MEDIA_CONTROLLER=y +CONFIG_VIDEO_DEV=y +CONFIG_VIDEO_V4L2_SUBDEV_API=y +CONFIG_VIDEO_V4L2=y +CONFIG_VIDEO_ADV_DEBUG=y +# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set +CONFIG_V4L2_FWNODE=y +CONFIG_VIDEOBUF2_CORE=y +CONFIG_VIDEOBUF2_MEMOPS=y +CONFIG_VIDEOBUF2_DMA_CONTIG=y +# CONFIG_TTPCI_EEPROM is not set + +# +# Media drivers +# +CONFIG_V4L_PLATFORM_DRIVERS=y +# CONFIG_VIDEO_SH_VOU is not set +# CONFIG_VIDEO_MUX is not set +CONFIG_SOC_CAMERA=y +CONFIG_SOC_CAMERA_PLATFORM=y +# CONFIG_VIDEO_SH_MOBILE_CEU is not set +# CONFIG_VIDEO_XILINX is not set +CONFIG_VIDEO_RCAR_CSI2=y +CONFIG_VIDEO_RCAR_VIN=y +CONFIG_V4L_MEM2MEM_DRIVERS=y +# CONFIG_VIDEO_MEM2MEM_DEINTERLACE is not set +# CONFIG_VIDEO_SH_VEU is not set +# CONFIG_VIDEO_RENESAS_JPU is not set +# CONFIG_VIDEO_RENESAS_FCP is not set +# CONFIG_V4L_TEST_DRIVERS is not set + +# +# Supported MMC/SDIO adapters +# + +# +# Media ancillary drivers (tuners, sensors, i2c, spi, frontends) +# +# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set + +# +# I2C Encoders, decoders, sensors and other helper chips +# + +# +# Audio decoders, processors and mixers +# +# CONFIG_VIDEO_TVAUDIO is not set +# CONFIG_VIDEO_TDA7432 is not set +# CONFIG_VIDEO_TDA9840 is not set +# CONFIG_VIDEO_TEA6415C is not set +# CONFIG_VIDEO_TEA6420 is not set +# CONFIG_VIDEO_MSP3400 is not set +# CONFIG_VIDEO_CS3308 is not set +# CONFIG_VIDEO_CS5345 is not set +# CONFIG_VIDEO_CS53L32A is not set +# CONFIG_VIDEO_TLV320AIC23B is not set +# CONFIG_VIDEO_UDA1342 is not set +# CONFIG_VIDEO_WM8775 is not set +# CONFIG_VIDEO_WM8739 is not set +# CONFIG_VIDEO_VP27SMPX is not set +# CONFIG_VIDEO_SONY_BTF_MPX is not set + +# +# RDS decoders +# +# CONFIG_VIDEO_SAA6588 is not set + +# +# Video decoders +# +# CONFIG_VIDEO_ADV7180 is not set +# CONFIG_VIDEO_ADV7183 is not set +CONFIG_VIDEO_ADV748X=y +# CONFIG_VIDEO_ADV7604 is not set +# CONFIG_VIDEO_ADV7842 is not set +# CONFIG_VIDEO_BT819 is not set +# CONFIG_VIDEO_BT856 is not set +# CONFIG_VIDEO_BT866 is not set +# CONFIG_VIDEO_KS0127 is not set +# CONFIG_VIDEO_ML86V7667 is not set +# CONFIG_VIDEO_AD5820 is not set +# CONFIG_VIDEO_DW9714 is not set +# CONFIG_VIDEO_SAA7110 is not set +# CONFIG_VIDEO_SAA711X is not set +# CONFIG_VIDEO_TC358743 is not set +# CONFIG_VIDEO_TVP514X is not set +# CONFIG_VIDEO_TVP5150 is not set +# CONFIG_VIDEO_TVP7002 is not set +# CONFIG_VIDEO_TW2804 is not set +# CONFIG_VIDEO_TW9903 is not set +# CONFIG_VIDEO_TW9906 is not set +# CONFIG_VIDEO_VPX3220 is not set +CONFIG_VIDEO_MAX9286=y + +# +# Video and audio decoders +# +# CONFIG_VIDEO_SAA717X is not set +# CONFIG_VIDEO_CX25840 is not set + +# +# Video encoders +# +# CONFIG_VIDEO_SAA7127 is not set +# CONFIG_VIDEO_SAA7185 is not set +# CONFIG_VIDEO_ADV7170 is not set +# CONFIG_VIDEO_ADV7175 is not set +# CONFIG_VIDEO_ADV7343 is not set +# CONFIG_VIDEO_ADV7393 is not set +# CONFIG_VIDEO_ADV7511 is not set +# CONFIG_VIDEO_AD9389B is not set +# CONFIG_VIDEO_AK881X is not set +# CONFIG_VIDEO_THS8200 is not set + +# +# Camera sensor devices +# +# CONFIG_VIDEO_OV2640 is not set +# CONFIG_VIDEO_OV2659 is not set +# CONFIG_VIDEO_OV5640 is not set +# CONFIG_VIDEO_OV5645 is not set +# CONFIG_VIDEO_OV5647 is not set +# CONFIG_VIDEO_OV6650 is not set +# CONFIG_VIDEO_OV5670 is not set +# CONFIG_VIDEO_OV7640 is not set +CONFIG_VIDEO_OV7670=y +# CONFIG_VIDEO_OV9650 is not set +# CONFIG_VIDEO_OV13858 is not set +# CONFIG_VIDEO_VS6624 is not set +# CONFIG_VIDEO_MT9M032 is not set +CONFIG_VIDEO_MT9M111=y +# CONFIG_VIDEO_MT9P031 is not set +# CONFIG_VIDEO_MT9T001 is not set +# CONFIG_VIDEO_MT9V011 is not set +# CONFIG_VIDEO_MT9V032 is not set +# CONFIG_VIDEO_SR030PC30 is not set +# CONFIG_VIDEO_NOON010PC30 is not set +# CONFIG_VIDEO_M5MOLS is not set +# CONFIG_VIDEO_S5K6AA is not set +# CONFIG_VIDEO_S5K6A3 is not set +# CONFIG_VIDEO_S5K4ECGX is not set +# CONFIG_VIDEO_S5K5BAF is not set +# CONFIG_VIDEO_SMIAPP is not set +# CONFIG_VIDEO_ET8EK8 is not set +# CONFIG_VIDEO_S5C73M3 is not set +CONFIG_VIDEO_RDACM20=y + +# +# Flash devices +# +# CONFIG_VIDEO_ADP1653 is not set +# CONFIG_VIDEO_AS3645A is not set +# CONFIG_VIDEO_LM3560 is not set +# CONFIG_VIDEO_LM3646 is not set + +# +# Video improvement chips +# +# CONFIG_VIDEO_UPD64031A is not set +# CONFIG_VIDEO_UPD64083 is not set + +# +# Audio/Video compression chips +# +# CONFIG_VIDEO_SAA6752HS is not set + +# +# SDR tuner chips +# + +# +# Miscellaneous helper chips +# +# CONFIG_VIDEO_THS7303 is not set +# CONFIG_VIDEO_M52790 is not set + +# +# Sensors used on soc_camera driver +# + +# +# soc_camera sensor drivers +# +# CONFIG_SOC_CAMERA_IMX074 is not set +# CONFIG_SOC_CAMERA_MT9M001 is not set +# CONFIG_SOC_CAMERA_MT9M111 is not set +# CONFIG_SOC_CAMERA_MT9T031 is not set +# CONFIG_SOC_CAMERA_MT9T112 is not set +# CONFIG_SOC_CAMERA_MT9V022 is not set +# CONFIG_SOC_CAMERA_OV5642 is not set +# CONFIG_SOC_CAMERA_OV772X is not set +# CONFIG_SOC_CAMERA_OV9640 is not set +# CONFIG_SOC_CAMERA_OV9740 is not set +# CONFIG_SOC_CAMERA_RJ54N1 is not set +# CONFIG_SOC_CAMERA_TW9910 is not set + +# +# SPI helper chips +# +# CONFIG_VIDEO_GS1662 is not set + +# +# Customise DVB Frontends +# + +# +# Tools to develop new frontends +# + +# +# Graphics support +# +# CONFIG_DRM is not set + +# +# ACP (Audio CoProcessor) Configuration +# +# CONFIG_DRM_LIB_RANDOM is not set + +# +# Frame buffer Devices +# +CONFIG_FB=y +# CONFIG_FIRMWARE_EDID is not set +CONFIG_FB_CMDLINE=y +CONFIG_FB_NOTIFY=y +# CONFIG_FB_DDC is not set +# CONFIG_FB_BOOT_VESA_SUPPORT is not set +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set +# CONFIG_FB_SYS_FILLRECT is not set +# CONFIG_FB_SYS_COPYAREA is not set +# CONFIG_FB_SYS_IMAGEBLIT is not set +# CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA is not set +# CONFIG_FB_FOREIGN_ENDIAN is not set +# CONFIG_FB_SYS_FOPS is not set +# CONFIG_FB_SVGALIB is not set +# CONFIG_FB_MACMODES is not set +# CONFIG_FB_BACKLIGHT is not set +CONFIG_FB_MODE_HELPERS=y +# CONFIG_FB_TILEBLITTING is not set + +# +# Frame buffer hardware drivers +# +CONFIG_FB_ARMCLCD=y +# CONFIG_FB_OPENCORES is not set +# CONFIG_FB_S1D13XXX is not set +# CONFIG_FB_SH_MOBILE_LCDC is not set +# CONFIG_FB_IBM_GXT4500 is not set +# CONFIG_FB_VIRTUAL is not set +# CONFIG_FB_METRONOME is not set +# CONFIG_FB_BROADSHEET is not set +# CONFIG_FB_AUO_K190X is not set +# CONFIG_FB_SIMPLE is not set +# CONFIG_FB_SH_MOBILE_MERAM is not set +# CONFIG_FB_SSD1307 is not set +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_LCD_CLASS_DEVICE=y +# CONFIG_LCD_L4F00242T03 is not set +# CONFIG_LCD_LMS283GF05 is not set +# CONFIG_LCD_LTV350QV is not set +# CONFIG_LCD_ILI922X is not set +# CONFIG_LCD_ILI9320 is not set +# CONFIG_LCD_TDO24M is not set +# CONFIG_LCD_VGG2432A4 is not set +# CONFIG_LCD_PLATFORM is not set +# CONFIG_LCD_S6E63M0 is not set +# CONFIG_LCD_LD9040 is not set +# CONFIG_LCD_AMS369FG06 is not set +# CONFIG_LCD_LMS501KF03 is not set +# CONFIG_LCD_HX8357 is not set +CONFIG_BACKLIGHT_CLASS_DEVICE=y +CONFIG_BACKLIGHT_GENERIC=y +CONFIG_BACKLIGHT_PWM=y +# CONFIG_BACKLIGHT_PM8941_WLED is not set +# CONFIG_BACKLIGHT_ADP8860 is not set +# CONFIG_BACKLIGHT_ADP8870 is not set +# CONFIG_BACKLIGHT_LM3630A is not set +# CONFIG_BACKLIGHT_LM3639 is not set +# CONFIG_BACKLIGHT_LP855X is not set +# CONFIG_BACKLIGHT_GPIO is not set +# CONFIG_BACKLIGHT_LV5207LP is not set +# CONFIG_BACKLIGHT_BD6107 is not set +# CONFIG_BACKLIGHT_ARCXCNN is not set +# CONFIG_VGASTATE is not set +CONFIG_VIDEOMODE_HELPERS=y + +# +# Console display driver support +# +CONFIG_DUMMY_CONSOLE=y +CONFIG_DUMMY_CONSOLE_COLUMNS=80 +CONFIG_DUMMY_CONSOLE_ROWS=25 +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y +# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set +CONFIG_LOGO=y +# CONFIG_LOGO_LINUX_MONO is not set +# CONFIG_LOGO_LINUX_VGA16 is not set +CONFIG_LOGO_LINUX_CLUT224=y +# CONFIG_SOUND is not set + +# +# HID support +# +CONFIG_HID=y +# CONFIG_HID_BATTERY_STRENGTH is not set +# CONFIG_HIDRAW is not set +# CONFIG_UHID is not set +CONFIG_HID_GENERIC=y + +# +# Special HID drivers +# +CONFIG_HID_A4TECH=y +# CONFIG_HID_ACRUX is not set +CONFIG_HID_APPLE=y +# CONFIG_HID_ASUS is not set +# CONFIG_HID_AUREAL is not set +CONFIG_HID_BELKIN=y +CONFIG_HID_CHERRY=y +CONFIG_HID_CHICONY=y +# CONFIG_HID_CMEDIA is not set +CONFIG_HID_CYPRESS=y +# CONFIG_HID_DRAGONRISE is not set +# CONFIG_HID_EMS_FF is not set +# CONFIG_HID_ELECOM is not set +CONFIG_HID_EZKEY=y +# CONFIG_HID_GEMBIRD is not set +# CONFIG_HID_GFRM is not set +# CONFIG_HID_KEYTOUCH is not set +# CONFIG_HID_KYE is not set +# CONFIG_HID_WALTOP is not set +# CONFIG_HID_GYRATION is not set +# CONFIG_HID_ICADE is not set +CONFIG_HID_ITE=y +# CONFIG_HID_TWINHAN is not set +CONFIG_HID_KENSINGTON=y +# CONFIG_HID_LCPOWER is not set +# CONFIG_HID_LED is not set +# CONFIG_HID_LENOVO is not set +CONFIG_HID_LOGITECH=y +# CONFIG_HID_LOGITECH_HIDPP is not set +# CONFIG_LOGITECH_FF is not set +# CONFIG_LOGIRUMBLEPAD2_FF is not set +# CONFIG_LOGIG940_FF is not set +# CONFIG_LOGIWHEELS_FF is not set +# CONFIG_HID_MAGICMOUSE is not set +# CONFIG_HID_MAYFLASH is not set +CONFIG_HID_MICROSOFT=y +CONFIG_HID_MONTEREY=y +# CONFIG_HID_MULTITOUCH is not set +# CONFIG_HID_NTI is not set +# CONFIG_HID_ORTEK is not set +# CONFIG_HID_PANTHERLORD is not set +# CONFIG_HID_PETALYNX is not set +# CONFIG_HID_PICOLCD is not set +# CONFIG_HID_PLANTRONICS is not set +# CONFIG_HID_PRIMAX is not set +# CONFIG_HID_SAITEK is not set +# CONFIG_HID_SAMSUNG is not set +# CONFIG_HID_SPEEDLINK is not set +# CONFIG_HID_STEELSERIES is not set +# CONFIG_HID_SUNPLUS is not set +# CONFIG_HID_RMI is not set +# CONFIG_HID_GREENASIA is not set +# CONFIG_HID_SMARTJOYPLUS is not set +# CONFIG_HID_TIVO is not set +# CONFIG_HID_TOPSEED is not set +# CONFIG_HID_THINGM is not set +# CONFIG_HID_THRUSTMASTER is not set +# CONFIG_HID_UDRAW_PS3 is not set +# CONFIG_HID_WACOM is not set +# CONFIG_HID_WIIMOTE is not set +# CONFIG_HID_XINMO is not set +# CONFIG_HID_ZEROPLUS is not set +# CONFIG_HID_ZYDACRON is not set +# CONFIG_HID_SENSOR_HUB is not set +# CONFIG_HID_ALPS is not set + +# +# I2C HID support +# +# CONFIG_I2C_HID is not set +CONFIG_USB_OHCI_LITTLE_ENDIAN=y +# CONFIG_USB_SUPPORT is not set +# CONFIG_UWB is not set +CONFIG_MMC=y +# CONFIG_MMC_DEBUG is not set +CONFIG_PWRSEQ_EMMC=y +CONFIG_PWRSEQ_SIMPLE=y +CONFIG_MMC_BLOCK=y +CONFIG_MMC_BLOCK_MINORS=8 +# CONFIG_SDIO_UART is not set +# CONFIG_MMC_TEST is not set + +# +# MMC/SD/SDIO Host Controller Drivers +# +# CONFIG_MMC_ARMMMCI is not set +# CONFIG_MMC_SDHCI is not set +# CONFIG_MMC_SPI is not set +CONFIG_MMC_TMIO_CORE=y +CONFIG_MMC_SDHI=y +# CONFIG_MMC_DW is not set +# CONFIG_MMC_SH_MMCIF is not set +# CONFIG_MMC_USDHI6ROL0 is not set +# CONFIG_MMC_MTK is not set +# CONFIG_MEMSTICK is not set +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +# CONFIG_LEDS_CLASS_FLASH is not set +# CONFIG_LEDS_BRIGHTNESS_HW_CHANGED is not set + +# +# LED drivers +# +# CONFIG_LEDS_BCM6328 is not set +# CONFIG_LEDS_BCM6358 is not set +# CONFIG_LEDS_LM3530 is not set +# CONFIG_LEDS_LM3642 is not set +# CONFIG_LEDS_PCA9532 is not set +CONFIG_LEDS_GPIO=y +# CONFIG_LEDS_LP3944 is not set +# CONFIG_LEDS_LP3952 is not set +# CONFIG_LEDS_LP5521 is not set +# CONFIG_LEDS_LP5523 is not set +# CONFIG_LEDS_LP5562 is not set +# CONFIG_LEDS_LP8501 is not set +# CONFIG_LEDS_LP8860 is not set +# CONFIG_LEDS_PCA955X is not set +# CONFIG_LEDS_PCA963X is not set +# CONFIG_LEDS_DAC124S085 is not set +# CONFIG_LEDS_PWM is not set +# CONFIG_LEDS_REGULATOR is not set +# CONFIG_LEDS_BD2802 is not set +# CONFIG_LEDS_LT3593 is not set +# CONFIG_LEDS_TCA6507 is not set +# CONFIG_LEDS_TLC591XX is not set +# CONFIG_LEDS_LM355x is not set +# CONFIG_LEDS_IS31FL319X is not set +# CONFIG_LEDS_IS31FL32XX is not set + +# +# LED driver for blink(1) USB RGB LED is under Special HID drivers (HID_THINGM) +# +# CONFIG_LEDS_BLINKM is not set +CONFIG_LEDS_SYSCON=y +# CONFIG_LEDS_USER is not set + +# +# LED Triggers +# +CONFIG_LEDS_TRIGGERS=y +# CONFIG_LEDS_TRIGGER_TIMER is not set +# CONFIG_LEDS_TRIGGER_ONESHOT is not set +CONFIG_LEDS_TRIGGER_HEARTBEAT=y +# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set +CONFIG_LEDS_TRIGGER_CPU=y +# CONFIG_LEDS_TRIGGER_GPIO is not set +# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set + +# +# iptables trigger is under Netfilter config (LED target) +# +# CONFIG_LEDS_TRIGGER_TRANSIENT is not set +# CONFIG_LEDS_TRIGGER_CAMERA is not set +# CONFIG_LEDS_TRIGGER_PANIC is not set +# CONFIG_ACCESSIBILITY is not set +CONFIG_EDAC_SUPPORT=y +CONFIG_RTC_LIB=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_HCTOSYS=y +CONFIG_RTC_HCTOSYS_DEVICE="rtc0" +CONFIG_RTC_SYSTOHC=y +CONFIG_RTC_SYSTOHC_DEVICE="rtc0" +# CONFIG_RTC_DEBUG is not set +CONFIG_RTC_NVMEM=y + +# +# RTC interfaces +# +CONFIG_RTC_INTF_SYSFS=y +CONFIG_RTC_INTF_PROC=y +CONFIG_RTC_INTF_DEV=y +# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set +# CONFIG_RTC_DRV_TEST is not set + +# +# I2C RTC drivers +# +# CONFIG_RTC_DRV_ABB5ZES3 is not set +# CONFIG_RTC_DRV_ABX80X is not set +# CONFIG_RTC_DRV_DS1307 is not set +# CONFIG_RTC_DRV_DS1374 is not set +# CONFIG_RTC_DRV_DS1672 is not set +# CONFIG_RTC_DRV_HYM8563 is not set +# CONFIG_RTC_DRV_MAX6900 is not set +# CONFIG_RTC_DRV_RS5C372 is not set +# CONFIG_RTC_DRV_ISL1208 is not set +# CONFIG_RTC_DRV_ISL12022 is not set +# CONFIG_RTC_DRV_X1205 is not set +# CONFIG_RTC_DRV_PCF8523 is not set +# CONFIG_RTC_DRV_PCF85063 is not set +# CONFIG_RTC_DRV_PCF8563 is not set +# CONFIG_RTC_DRV_PCF8583 is not set +# CONFIG_RTC_DRV_M41T80 is not set +# CONFIG_RTC_DRV_BQ32K is not set +# CONFIG_RTC_DRV_S35390A is not set +# CONFIG_RTC_DRV_FM3130 is not set +# CONFIG_RTC_DRV_RX8010 is not set +# CONFIG_RTC_DRV_RX8581 is not set +# CONFIG_RTC_DRV_RX8025 is not set +# CONFIG_RTC_DRV_EM3027 is not set +# CONFIG_RTC_DRV_RV8803 is not set + +# +# SPI RTC drivers +# +# CONFIG_RTC_DRV_M41T93 is not set +# CONFIG_RTC_DRV_M41T94 is not set +# CONFIG_RTC_DRV_DS1302 is not set +# CONFIG_RTC_DRV_DS1305 is not set +# CONFIG_RTC_DRV_DS1343 is not set +# CONFIG_RTC_DRV_DS1347 is not set +# CONFIG_RTC_DRV_DS1390 is not set +# CONFIG_RTC_DRV_MAX6916 is not set +# CONFIG_RTC_DRV_R9701 is not set +# CONFIG_RTC_DRV_RX4581 is not set +# CONFIG_RTC_DRV_RX6110 is not set +# CONFIG_RTC_DRV_RS5C348 is not set +# CONFIG_RTC_DRV_MAX6902 is not set +# CONFIG_RTC_DRV_PCF2123 is not set +# CONFIG_RTC_DRV_MCP795 is not set +CONFIG_RTC_I2C_AND_SPI=y + +# +# SPI and I2C RTC drivers +# +# CONFIG_RTC_DRV_DS3232 is not set +# CONFIG_RTC_DRV_PCF2127 is not set +# CONFIG_RTC_DRV_RV3029C2 is not set + +# +# Platform RTC drivers +# +# CONFIG_RTC_DRV_DS1286 is not set +# CONFIG_RTC_DRV_DS1511 is not set +# CONFIG_RTC_DRV_DS1553 is not set +# CONFIG_RTC_DRV_DS1685_FAMILY is not set +# CONFIG_RTC_DRV_DS1742 is not set +# CONFIG_RTC_DRV_DS2404 is not set +# CONFIG_RTC_DRV_STK17TA8 is not set +# CONFIG_RTC_DRV_M48T86 is not set +# CONFIG_RTC_DRV_M48T35 is not set +# CONFIG_RTC_DRV_M48T59 is not set +# CONFIG_RTC_DRV_MSM6242 is not set +# CONFIG_RTC_DRV_BQ4802 is not set +# CONFIG_RTC_DRV_RP5C01 is not set +# CONFIG_RTC_DRV_V3020 is not set +# CONFIG_RTC_DRV_ZYNQMP is not set + +# +# on-CPU RTC drivers +# +# CONFIG_RTC_DRV_SH is not set +# CONFIG_RTC_DRV_PL030 is not set +# CONFIG_RTC_DRV_PL031 is not set +# CONFIG_RTC_DRV_FTRTC010 is not set +# CONFIG_RTC_DRV_SNVS is not set +# CONFIG_RTC_DRV_R7301 is not set + +# +# HID Sensor RTC drivers +# +CONFIG_DMADEVICES=y +# CONFIG_DMADEVICES_DEBUG is not set + +# +# DMA Devices +# +CONFIG_DMA_ENGINE=y +CONFIG_DMA_VIRTUAL_CHANNELS=y +CONFIG_DMA_OF=y +# CONFIG_AMBA_PL08X is not set +# CONFIG_FSL_EDMA is not set +# CONFIG_INTEL_IDMA64 is not set +# CONFIG_MV_XOR_V2 is not set +# CONFIG_PL330_DMA is not set +# CONFIG_XILINX_DMA is not set +# CONFIG_XILINX_ZYNQMP_DMA is not set +# CONFIG_QCOM_HIDMA_MGMT is not set +# CONFIG_QCOM_HIDMA is not set +# CONFIG_DW_DMAC is not set +CONFIG_RENESAS_DMA=y +CONFIG_SH_DMAE_BASE=y +# CONFIG_SH_DMAE is not set +CONFIG_RCAR_DMAC=y +CONFIG_RENESAS_USB_DMAC=y +# CONFIG_SUDMAC is not set + +# +# DMA Clients +# +# CONFIG_ASYNC_TX_DMA is not set +# CONFIG_DMATEST is not set + +# +# DMABUF options +# +CONFIG_SYNC_FILE=y +# CONFIG_SW_SYNC is not set +# CONFIG_AUXDISPLAY is not set +# CONFIG_UIO is not set +# CONFIG_VIRT_DRIVERS is not set + +# +# Virtio drivers +# +# CONFIG_VIRTIO_MMIO is not set + +# +# Microsoft Hyper-V guest support +# +# CONFIG_HYPERV_TSCPAGE is not set +CONFIG_STAGING=y +# CONFIG_COMEDI is not set + +# +# Speakup console speech +# +# CONFIG_SPEAKUP is not set +# CONFIG_STAGING_MEDIA is not set + +# +# Android +# +CONFIG_STAGING_BOARD=y +# CONFIG_LNET is not set +# CONFIG_GS_FPGABOOT is not set +# CONFIG_COMMON_CLK_XLNX_CLKWZRD is not set +# CONFIG_FB_TFT is not set +# CONFIG_MOST is not set +# CONFIG_GREYBUS is not set +# CONFIG_CRYPTO_DEV_CCREE is not set + +# +# USB Power Delivery and Type-C drivers +# +# CONFIG_GOLDFISH is not set +# CONFIG_CHROME_PLATFORMS is not set +CONFIG_CLKDEV_LOOKUP=y +CONFIG_HAVE_CLK_PREPARE=y +CONFIG_COMMON_CLK=y + +# +# Common Clock Framework +# +# CONFIG_COMMON_CLK_VERSATILE is not set +# CONFIG_COMMON_CLK_SI5351 is not set +# CONFIG_COMMON_CLK_SI514 is not set +# CONFIG_COMMON_CLK_SI570 is not set +# CONFIG_COMMON_CLK_CDCE706 is not set +# CONFIG_COMMON_CLK_CDCE925 is not set +CONFIG_COMMON_CLK_CS2000_CP=y +# CONFIG_CLK_QORIQ is not set +# CONFIG_COMMON_CLK_XGENE is not set +# CONFIG_COMMON_CLK_NXP is not set +# CONFIG_COMMON_CLK_PWM is not set +# CONFIG_COMMON_CLK_PXA is not set +# CONFIG_COMMON_CLK_PIC32 is not set +# CONFIG_COMMON_CLK_VC5 is not set +CONFIG_CLK_RENESAS=y +CONFIG_CLK_R8A7795=y +CONFIG_CLK_R8A7796=y +CONFIG_CLK_RCAR_GEN3_CPG=y +CONFIG_CLK_RENESAS_CPG_MSSR=y +CONFIG_CLK_RENESAS_DIV6=y +# CONFIG_HWSPINLOCK is not set + +# +# Clock Source drivers +# +CONFIG_TIMER_OF=y +CONFIG_TIMER_PROBE=y +CONFIG_ARM_ARCH_TIMER=y +CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y +# CONFIG_FSL_ERRATUM_A008585 is not set +# CONFIG_HISILICON_ERRATUM_161010101 is not set +# CONFIG_ARM64_ERRATUM_858921 is not set +# CONFIG_ARM_TIMER_SP804 is not set +# CONFIG_ATMEL_PIT is not set +# CONFIG_SH_TIMER_CMT is not set +# CONFIG_SH_TIMER_MTU2 is not set +# CONFIG_SH_TIMER_TMU is not set +# CONFIG_EM_TIMER_STI is not set +# CONFIG_MAILBOX is not set +# CONFIG_IOMMU_SUPPORT is not set + +# +# Remoteproc drivers +# +# CONFIG_REMOTEPROC is not set + +# +# Rpmsg drivers +# + +# +# SOC (System On Chip) specific Drivers +# + +# +# Broadcom SoC drivers +# +# CONFIG_SOC_BRCMSTB is not set + +# +# i.MX SoC drivers +# +CONFIG_SOC_RENESAS=y +CONFIG_SYSC_R8A7795=y +CONFIG_SYSC_R8A7796=y +CONFIG_RST_RCAR=y +CONFIG_SYSC_RCAR=y +# CONFIG_SUNXI_SRAM is not set +# CONFIG_SOC_TI is not set +# CONFIG_PM_DEVFREQ is not set +# CONFIG_EXTCON is not set +# CONFIG_MEMORY is not set +# CONFIG_IIO is not set +CONFIG_PWM=y +CONFIG_PWM_SYSFS=y +# CONFIG_PWM_FSL_FTM is not set +# CONFIG_PWM_PCA9685 is not set +CONFIG_PWM_RCAR=y +# CONFIG_PWM_RENESAS_TPU is not set +CONFIG_IRQCHIP=y +CONFIG_ARM_GIC=y +CONFIG_ARM_GIC_MAX_NR=1 +CONFIG_ARM_GIC_V3=y +CONFIG_RENESAS_IRQC=y +CONFIG_PARTITION_PERCPU=y +# CONFIG_IPACK_BUS is not set +CONFIG_RESET_CONTROLLER=y +# CONFIG_RESET_ATH79 is not set +# CONFIG_RESET_BERLIN is not set +# CONFIG_RESET_GEMINI is not set +# CONFIG_RESET_IMX7 is not set +# CONFIG_RESET_LPC18XX is not set +# CONFIG_RESET_MESON is not set +# CONFIG_RESET_PISTACHIO is not set +# CONFIG_RESET_SOCFPGA is not set +# CONFIG_RESET_STM32 is not set +# CONFIG_RESET_SUNXI is not set +# CONFIG_RESET_TI_SYSCON is not set +# CONFIG_RESET_ZYNQ is not set +# CONFIG_RESET_TEGRA_BPMP is not set +# CONFIG_FMC is not set + +# +# PHY Subsystem +# +CONFIG_GENERIC_PHY=y +# CONFIG_PHY_XGENE is not set +# CONFIG_BCM_KONA_USB2_PHY is not set +# CONFIG_PHY_PXA_28NM_HSIC is not set +# CONFIG_PHY_PXA_28NM_USB2 is not set +# CONFIG_PHY_RCAR_GEN2 is not set +# CONFIG_PHY_RCAR_GEN3_USB3 is not set +# CONFIG_POWERCAP is not set +# CONFIG_MCB is not set + +# +# Performance monitor support +# +CONFIG_ARM_PMU=y +# CONFIG_RAS is not set + +# +# Android +# +# CONFIG_ANDROID is not set +# CONFIG_LIBNVDIMM is not set +# CONFIG_DAX is not set +CONFIG_NVMEM=y +# CONFIG_STM is not set +# CONFIG_INTEL_TH is not set + +# +# FPGA Configuration Support +# +# CONFIG_FPGA is not set + +# +# FSI support +# +# CONFIG_FSI is not set +# CONFIG_TEE is not set + +# +# Firmware Drivers +# +CONFIG_ARM_PSCI_FW=y +# CONFIG_ARM_PSCI_CHECKER is not set +# CONFIG_FIRMWARE_MEMMAP is not set +CONFIG_HAVE_ARM_SMCCC=y +# CONFIG_GOOGLE_FIRMWARE is not set +# CONFIG_MESON_SM is not set + +# +# Tegra firmware driver +# + +# +# File systems +# +CONFIG_DCACHE_WORD_ACCESS=y +CONFIG_EXT2_FS=y +# CONFIG_EXT2_FS_XATTR is not set +CONFIG_EXT3_FS=y +# CONFIG_EXT3_FS_POSIX_ACL is not set +# CONFIG_EXT3_FS_SECURITY is not set +CONFIG_EXT4_FS=y +# CONFIG_EXT4_FS_POSIX_ACL is not set +# CONFIG_EXT4_FS_SECURITY is not set +# CONFIG_EXT4_ENCRYPTION is not set +# CONFIG_EXT4_DEBUG is not set +CONFIG_JBD2=y +# CONFIG_JBD2_DEBUG is not set +CONFIG_FS_MBCACHE=y +# CONFIG_REISERFS_FS is not set +# CONFIG_JFS_FS is not set +# CONFIG_XFS_FS is not set +# CONFIG_GFS2_FS is not set +# CONFIG_BTRFS_FS is not set +# CONFIG_NILFS2_FS is not set +# CONFIG_F2FS_FS is not set +# CONFIG_FS_DAX is not set +# CONFIG_FS_POSIX_ACL is not set +CONFIG_EXPORTFS=y +# CONFIG_EXPORTFS_BLOCK_OPS is not set +CONFIG_FILE_LOCKING=y +CONFIG_MANDATORY_FILE_LOCKING=y +# CONFIG_FS_ENCRYPTION is not set +CONFIG_FSNOTIFY=y +CONFIG_DNOTIFY=y +CONFIG_INOTIFY_USER=y +CONFIG_FANOTIFY=y +# CONFIG_QUOTA is not set +# CONFIG_QUOTACTL is not set +CONFIG_AUTOFS4_FS=y +# CONFIG_FUSE_FS is not set +# CONFIG_OVERLAY_FS is not set + +# +# Caches +# +# CONFIG_FSCACHE is not set + +# +# CD-ROM/DVD Filesystems +# +# CONFIG_ISO9660_FS is not set +# CONFIG_UDF_FS is not set + +# +# DOS/FAT/NT Filesystems +# +CONFIG_FAT_FS=y +# CONFIG_MSDOS_FS is not set +CONFIG_VFAT_FS=y +CONFIG_FAT_DEFAULT_CODEPAGE=437 +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" +# CONFIG_FAT_DEFAULT_UTF8 is not set +# CONFIG_NTFS_FS is not set + +# +# Pseudo filesystems +# +CONFIG_PROC_FS=y +# CONFIG_PROC_KCORE is not set +CONFIG_PROC_SYSCTL=y +CONFIG_PROC_PAGE_MONITOR=y +# CONFIG_PROC_CHILDREN is not set +CONFIG_KERNFS=y +CONFIG_SYSFS=y +CONFIG_TMPFS=y +# CONFIG_TMPFS_POSIX_ACL is not set +# CONFIG_TMPFS_XATTR is not set +CONFIG_HUGETLBFS=y +CONFIG_HUGETLB_PAGE=y +CONFIG_ARCH_HAS_GIGANTIC_PAGE=y +# CONFIG_CONFIGFS_FS is not set +CONFIG_MISC_FILESYSTEMS=y +# CONFIG_ORANGEFS_FS is not set +# CONFIG_ADFS_FS is not set +# CONFIG_AFFS_FS is not set +# CONFIG_ECRYPT_FS is not set +# CONFIG_HFS_FS is not set +# CONFIG_HFSPLUS_FS is not set +# CONFIG_BEFS_FS is not set +# CONFIG_BFS_FS is not set +# CONFIG_EFS_FS is not set +# CONFIG_CRAMFS is not set +CONFIG_SQUASHFS=y +CONFIG_SQUASHFS_FILE_CACHE=y +# CONFIG_SQUASHFS_FILE_DIRECT is not set +CONFIG_SQUASHFS_DECOMP_SINGLE=y +# CONFIG_SQUASHFS_DECOMP_MULTI is not set +# CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU is not set +# CONFIG_SQUASHFS_XATTR is not set +CONFIG_SQUASHFS_ZLIB=y +# CONFIG_SQUASHFS_LZ4 is not set +# CONFIG_SQUASHFS_LZO is not set +# CONFIG_SQUASHFS_XZ is not set +# CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set +# CONFIG_SQUASHFS_EMBEDDED is not set +CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3 +# CONFIG_VXFS_FS is not set +# CONFIG_MINIX_FS is not set +# CONFIG_OMFS_FS is not set +# CONFIG_HPFS_FS is not set +# CONFIG_QNX4FS_FS is not set +# CONFIG_QNX6FS_FS is not set +# CONFIG_ROMFS_FS is not set +# CONFIG_PSTORE is not set +# CONFIG_SYSV_FS is not set +# CONFIG_UFS_FS is not set +CONFIG_NETWORK_FILESYSTEMS=y +CONFIG_NFS_FS=y +CONFIG_NFS_V2=y +CONFIG_NFS_V3=y +# CONFIG_NFS_V3_ACL is not set +# CONFIG_NFS_V4 is not set +# CONFIG_NFS_SWAP is not set +CONFIG_ROOT_NFS=y +# CONFIG_NFSD is not set +CONFIG_GRACE_PERIOD=y +CONFIG_LOCKD=y +CONFIG_LOCKD_V4=y +CONFIG_NFS_COMMON=y +CONFIG_SUNRPC=y +# CONFIG_SUNRPC_DEBUG is not set +# CONFIG_CEPH_FS is not set +# CONFIG_CIFS is not set +# CONFIG_NCP_FS is not set +# CONFIG_CODA_FS is not set +# CONFIG_AFS_FS is not set +CONFIG_NLS=y +CONFIG_NLS_DEFAULT="iso8859-1" +CONFIG_NLS_CODEPAGE_437=y +# CONFIG_NLS_CODEPAGE_737 is not set +# CONFIG_NLS_CODEPAGE_775 is not set +# CONFIG_NLS_CODEPAGE_850 is not set +# CONFIG_NLS_CODEPAGE_852 is not set +# CONFIG_NLS_CODEPAGE_855 is not set +# CONFIG_NLS_CODEPAGE_857 is not set +# CONFIG_NLS_CODEPAGE_860 is not set +# CONFIG_NLS_CODEPAGE_861 is not set +# CONFIG_NLS_CODEPAGE_862 is not set +# CONFIG_NLS_CODEPAGE_863 is not set +# CONFIG_NLS_CODEPAGE_864 is not set +# CONFIG_NLS_CODEPAGE_865 is not set +# CONFIG_NLS_CODEPAGE_866 is not set +# CONFIG_NLS_CODEPAGE_869 is not set +# CONFIG_NLS_CODEPAGE_936 is not set +# CONFIG_NLS_CODEPAGE_950 is not set +# CONFIG_NLS_CODEPAGE_932 is not set +# CONFIG_NLS_CODEPAGE_949 is not set +# CONFIG_NLS_CODEPAGE_874 is not set +# CONFIG_NLS_ISO8859_8 is not set +# CONFIG_NLS_CODEPAGE_1250 is not set +# CONFIG_NLS_CODEPAGE_1251 is not set +# CONFIG_NLS_ASCII is not set +CONFIG_NLS_ISO8859_1=y +# CONFIG_NLS_ISO8859_2 is not set +# CONFIG_NLS_ISO8859_3 is not set +# CONFIG_NLS_ISO8859_4 is not set +# CONFIG_NLS_ISO8859_5 is not set +# CONFIG_NLS_ISO8859_6 is not set +# CONFIG_NLS_ISO8859_7 is not set +# CONFIG_NLS_ISO8859_9 is not set +# CONFIG_NLS_ISO8859_13 is not set +# CONFIG_NLS_ISO8859_14 is not set +# CONFIG_NLS_ISO8859_15 is not set +# CONFIG_NLS_KOI8_R is not set +# CONFIG_NLS_KOI8_U is not set +# CONFIG_NLS_MAC_ROMAN is not set +# CONFIG_NLS_MAC_CELTIC is not set +# CONFIG_NLS_MAC_CENTEURO is not set +# CONFIG_NLS_MAC_CROATIAN is not set +# CONFIG_NLS_MAC_CYRILLIC is not set +# CONFIG_NLS_MAC_GAELIC is not set +# CONFIG_NLS_MAC_GREEK is not set +# CONFIG_NLS_MAC_ICELAND is not set +# CONFIG_NLS_MAC_INUIT is not set +# CONFIG_NLS_MAC_ROMANIAN is not set +# CONFIG_NLS_MAC_TURKISH is not set +# CONFIG_NLS_UTF8 is not set +# CONFIG_VIRTUALIZATION is not set + +# +# Kernel hacking +# + +# +# printk and dmesg options +# +CONFIG_PRINTK_TIME=y +CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7 +CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4 +# CONFIG_BOOT_PRINTK_DELAY is not set +CONFIG_DYNAMIC_DEBUG=y + +# +# Compile-time checks and compiler options +# +CONFIG_DEBUG_INFO=y +# CONFIG_DEBUG_INFO_REDUCED is not set +# CONFIG_DEBUG_INFO_SPLIT is not set +# CONFIG_DEBUG_INFO_DWARF4 is not set +# CONFIG_GDB_SCRIPTS is not set +CONFIG_ENABLE_WARN_DEPRECATED=y +CONFIG_ENABLE_MUST_CHECK=y +CONFIG_FRAME_WARN=2048 +# CONFIG_STRIP_ASM_SYMS is not set +# CONFIG_READABLE_ASM is not set +# CONFIG_UNUSED_SYMBOLS is not set +# CONFIG_PAGE_OWNER is not set +CONFIG_DEBUG_FS=y +# CONFIG_HEADERS_CHECK is not set +# CONFIG_DEBUG_SECTION_MISMATCH is not set +CONFIG_SECTION_MISMATCH_WARN_ONLY=y +CONFIG_ARCH_WANT_FRAME_POINTERS=y +CONFIG_FRAME_POINTER=y +# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set +CONFIG_MAGIC_SYSRQ=y +CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1 +CONFIG_MAGIC_SYSRQ_SERIAL=y +CONFIG_DEBUG_KERNEL=y + +# +# Memory Debugging +# +# CONFIG_PAGE_EXTENSION is not set +# CONFIG_DEBUG_PAGEALLOC is not set +# CONFIG_PAGE_POISONING is not set +# CONFIG_DEBUG_RODATA_TEST is not set +# CONFIG_DEBUG_OBJECTS is not set +# CONFIG_SLUB_DEBUG_ON is not set +# CONFIG_SLUB_STATS is not set +CONFIG_HAVE_DEBUG_KMEMLEAK=y +# CONFIG_DEBUG_KMEMLEAK is not set +# CONFIG_DEBUG_STACK_USAGE is not set +# CONFIG_DEBUG_VM is not set +CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y +# CONFIG_DEBUG_VIRTUAL is not set +CONFIG_DEBUG_MEMORY_INIT=y +# CONFIG_DEBUG_PER_CPU_MAPS is not set +CONFIG_HAVE_ARCH_KASAN=y +# CONFIG_KASAN is not set +CONFIG_ARCH_HAS_KCOV=y +# CONFIG_KCOV is not set +# CONFIG_DEBUG_SHIRQ is not set + +# +# Debug Lockups and Hangs +# +# CONFIG_SOFTLOCKUP_DETECTOR is not set +CONFIG_DETECT_HUNG_TASK=y +CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120 +# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set +CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 +# CONFIG_WQ_WATCHDOG is not set +# CONFIG_PANIC_ON_OOPS is not set +CONFIG_PANIC_ON_OOPS_VALUE=0 +CONFIG_PANIC_TIMEOUT=0 +# CONFIG_SCHED_DEBUG is not set +CONFIG_SCHED_INFO=y +# CONFIG_SCHEDSTATS is not set +# CONFIG_SCHED_STACK_END_CHECK is not set +# CONFIG_DEBUG_TIMEKEEPING is not set +# CONFIG_DEBUG_PREEMPT is not set + +# +# Lock Debugging (spinlocks, mutexes, etc...) +# +# CONFIG_DEBUG_RT_MUTEXES is not set +# CONFIG_DEBUG_SPINLOCK is not set +# CONFIG_DEBUG_MUTEXES is not set +# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set +# CONFIG_DEBUG_LOCK_ALLOC is not set +# CONFIG_PROVE_LOCKING is not set +# CONFIG_LOCK_STAT is not set +# CONFIG_DEBUG_ATOMIC_SLEEP is not set +# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set +# CONFIG_LOCK_TORTURE_TEST is not set +# CONFIG_WW_MUTEX_SELFTEST is not set +# CONFIG_STACKTRACE is not set +# CONFIG_WARN_ALL_UNSEEDED_RANDOM is not set +# CONFIG_DEBUG_KOBJECT is not set +CONFIG_HAVE_DEBUG_BUGVERBOSE=y +CONFIG_DEBUG_BUGVERBOSE=y +# CONFIG_DEBUG_LIST is not set +# CONFIG_DEBUG_PI_LIST is not set +# CONFIG_DEBUG_SG is not set +# CONFIG_DEBUG_NOTIFIERS is not set +# CONFIG_DEBUG_CREDENTIALS is not set + +# +# RCU Debugging +# +# CONFIG_PROVE_RCU is not set +# CONFIG_TORTURE_TEST is not set +# CONFIG_RCU_PERF_TEST is not set +# CONFIG_RCU_TORTURE_TEST is not set +CONFIG_RCU_CPU_STALL_TIMEOUT=21 +# CONFIG_RCU_TRACE is not set +# CONFIG_RCU_EQS_DEBUG is not set +# CONFIG_DEBUG_WQ_FORCE_RR_CPU is not set +# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set +# CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set +# CONFIG_NOTIFIER_ERROR_INJECTION is not set +# CONFIG_FAULT_INJECTION is not set +# CONFIG_LATENCYTOP is not set +CONFIG_HAVE_FUNCTION_TRACER=y +CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y +CONFIG_HAVE_DYNAMIC_FTRACE=y +CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y +CONFIG_HAVE_SYSCALL_TRACEPOINTS=y +CONFIG_HAVE_C_RECORDMCOUNT=y +CONFIG_TRACING_SUPPORT=y +# CONFIG_FTRACE is not set + +# +# Runtime Testing +# +# CONFIG_LKDTM is not set +# CONFIG_TEST_LIST_SORT is not set +# CONFIG_TEST_SORT is not set +# CONFIG_BACKTRACE_SELF_TEST is not set +# CONFIG_RBTREE_TEST is not set +# CONFIG_INTERVAL_TREE_TEST is not set +# CONFIG_PERCPU_TEST is not set +# CONFIG_ATOMIC64_SELFTEST is not set +# CONFIG_TEST_HEXDUMP is not set +# CONFIG_TEST_STRING_HELPERS is not set +# CONFIG_TEST_KSTRTOX is not set +# CONFIG_TEST_PRINTF is not set +# CONFIG_TEST_BITMAP is not set +# CONFIG_TEST_UUID is not set +# CONFIG_TEST_RHASHTABLE is not set +# CONFIG_TEST_HASH is not set +# CONFIG_DMA_API_DEBUG is not set +# CONFIG_TEST_LKM is not set +# CONFIG_TEST_USER_COPY is not set +# CONFIG_TEST_BPF is not set +# CONFIG_TEST_FIRMWARE is not set +# CONFIG_TEST_SYSCTL is not set +# CONFIG_TEST_UDELAY is not set +# CONFIG_MEMTEST is not set +# CONFIG_TEST_STATIC_KEYS is not set +# CONFIG_BUG_ON_DATA_CORRUPTION is not set +# CONFIG_TEST_KMOD is not set +# CONFIG_SAMPLES is not set +CONFIG_HAVE_ARCH_KGDB=y +# CONFIG_KGDB is not set +CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y +# CONFIG_ARCH_WANTS_UBSAN_NO_NULL is not set +# CONFIG_UBSAN is not set +CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y +# CONFIG_STRICT_DEVMEM is not set +# CONFIG_ARM64_PTDUMP_CORE is not set +# CONFIG_ARM64_PTDUMP_DEBUGFS is not set +# CONFIG_PID_IN_CONTEXTIDR is not set +# CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET is not set +# CONFIG_DEBUG_WX is not set +# CONFIG_DEBUG_ALIGN_RODATA is not set +# CONFIG_ARM64_RELOC_TEST is not set +# CONFIG_CORESIGHT is not set + +# +# Security options +# +CONFIG_KEYS=y +CONFIG_KEYS_COMPAT=y +# CONFIG_PERSISTENT_KEYRINGS is not set +# CONFIG_BIG_KEYS is not set +# CONFIG_ENCRYPTED_KEYS is not set +# CONFIG_KEY_DH_OPERATIONS is not set +# CONFIG_SECURITY_DMESG_RESTRICT is not set +# CONFIG_SECURITY is not set +# CONFIG_SECURITYFS is not set +CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y +# CONFIG_HARDENED_USERCOPY is not set +# CONFIG_FORTIFY_SOURCE is not set +# CONFIG_STATIC_USERMODEHELPER is not set +CONFIG_DEFAULT_SECURITY_DAC=y +CONFIG_DEFAULT_SECURITY="" +CONFIG_CRYPTO=y + +# +# Crypto core or helper +# +CONFIG_CRYPTO_ALGAPI=y +CONFIG_CRYPTO_ALGAPI2=y +CONFIG_CRYPTO_AEAD=y +CONFIG_CRYPTO_AEAD2=y +CONFIG_CRYPTO_BLKCIPHER=y +CONFIG_CRYPTO_BLKCIPHER2=y +CONFIG_CRYPTO_HASH=y +CONFIG_CRYPTO_HASH2=y +CONFIG_CRYPTO_RNG=y +CONFIG_CRYPTO_RNG2=y +CONFIG_CRYPTO_AKCIPHER2=y +CONFIG_CRYPTO_KPP2=y +CONFIG_CRYPTO_ACOMP2=y +# CONFIG_CRYPTO_RSA is not set +# CONFIG_CRYPTO_DH is not set +# CONFIG_CRYPTO_ECDH is not set +CONFIG_CRYPTO_MANAGER=y +CONFIG_CRYPTO_MANAGER2=y +# CONFIG_CRYPTO_USER is not set +CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y +# CONFIG_CRYPTO_GF128MUL is not set +# CONFIG_CRYPTO_NULL is not set +CONFIG_CRYPTO_NULL2=y +# CONFIG_CRYPTO_PCRYPT is not set +CONFIG_CRYPTO_WORKQUEUE=y +CONFIG_CRYPTO_CRYPTD=y +# CONFIG_CRYPTO_MCRYPTD is not set +# CONFIG_CRYPTO_AUTHENC is not set +# CONFIG_CRYPTO_TEST is not set +CONFIG_CRYPTO_SIMD=y + +# +# Authenticated Encryption with Associated Data +# +# CONFIG_CRYPTO_CCM is not set +# CONFIG_CRYPTO_GCM is not set +# CONFIG_CRYPTO_CHACHA20POLY1305 is not set +# CONFIG_CRYPTO_SEQIV is not set +# CONFIG_CRYPTO_ECHAINIV is not set + +# +# Block modes +# +# CONFIG_CRYPTO_CBC is not set +# CONFIG_CRYPTO_CTR is not set +# CONFIG_CRYPTO_CTS is not set +# CONFIG_CRYPTO_ECB is not set +# CONFIG_CRYPTO_LRW is not set +# CONFIG_CRYPTO_PCBC is not set +# CONFIG_CRYPTO_XTS is not set +# CONFIG_CRYPTO_KEYWRAP is not set + +# +# Hash modes +# +# CONFIG_CRYPTO_CMAC is not set +# CONFIG_CRYPTO_HMAC is not set +# CONFIG_CRYPTO_XCBC is not set +# CONFIG_CRYPTO_VMAC is not set + +# +# Digest +# +CONFIG_CRYPTO_CRC32C=y +# CONFIG_CRYPTO_CRC32 is not set +# CONFIG_CRYPTO_CRCT10DIF is not set +# CONFIG_CRYPTO_GHASH is not set +# CONFIG_CRYPTO_POLY1305 is not set +# CONFIG_CRYPTO_MD4 is not set +# CONFIG_CRYPTO_MD5 is not set +# CONFIG_CRYPTO_MICHAEL_MIC is not set +# CONFIG_CRYPTO_RMD128 is not set +# CONFIG_CRYPTO_RMD160 is not set +# CONFIG_CRYPTO_RMD256 is not set +# CONFIG_CRYPTO_RMD320 is not set +# CONFIG_CRYPTO_SHA1 is not set +CONFIG_CRYPTO_SHA256=m +# CONFIG_CRYPTO_SHA512 is not set +# CONFIG_CRYPTO_SHA3 is not set +# CONFIG_CRYPTO_TGR192 is not set +# CONFIG_CRYPTO_WP512 is not set + +# +# Ciphers +# +CONFIG_CRYPTO_AES=y +# CONFIG_CRYPTO_AES_TI is not set +# CONFIG_CRYPTO_ANUBIS is not set +# CONFIG_CRYPTO_ARC4 is not set +# CONFIG_CRYPTO_BLOWFISH is not set +# CONFIG_CRYPTO_CAMELLIA is not set +# CONFIG_CRYPTO_CAST5 is not set +# CONFIG_CRYPTO_CAST6 is not set +# CONFIG_CRYPTO_DES is not set +# CONFIG_CRYPTO_FCRYPT is not set +# CONFIG_CRYPTO_KHAZAD is not set +# CONFIG_CRYPTO_SALSA20 is not set +# CONFIG_CRYPTO_CHACHA20 is not set +# CONFIG_CRYPTO_SEED is not set +# CONFIG_CRYPTO_SERPENT is not set +# CONFIG_CRYPTO_TEA is not set +# CONFIG_CRYPTO_TWOFISH is not set + +# +# Compression +# +# CONFIG_CRYPTO_DEFLATE is not set +# CONFIG_CRYPTO_LZO is not set +# CONFIG_CRYPTO_842 is not set +# CONFIG_CRYPTO_LZ4 is not set +# CONFIG_CRYPTO_LZ4HC is not set + +# +# Random Number Generation +# +CONFIG_CRYPTO_ANSI_CPRNG=y +# CONFIG_CRYPTO_DRBG_MENU is not set +# CONFIG_CRYPTO_JITTERENTROPY is not set +# CONFIG_CRYPTO_USER_API_HASH is not set +# CONFIG_CRYPTO_USER_API_SKCIPHER is not set +# CONFIG_CRYPTO_USER_API_RNG is not set +# CONFIG_CRYPTO_USER_API_AEAD is not set +CONFIG_CRYPTO_HW=y +# CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_DESC is not set +# CONFIG_CRYPTO_DEV_CCP is not set +# CONFIG_ASYMMETRIC_KEY_TYPE is not set + +# +# Certificates for signature checking +# +# CONFIG_SYSTEM_BLACKLIST_KEYRING is not set +CONFIG_ARM64_CRYPTO=y +# CONFIG_CRYPTO_SHA256_ARM64 is not set +# CONFIG_CRYPTO_SHA512_ARM64 is not set +CONFIG_CRYPTO_SHA1_ARM64_CE=y +CONFIG_CRYPTO_SHA2_ARM64_CE=y +CONFIG_CRYPTO_GHASH_ARM64_CE=y +# CONFIG_CRYPTO_CRC32_ARM64_CE is not set +# CONFIG_CRYPTO_AES_ARM64 is not set +CONFIG_CRYPTO_AES_ARM64_CE=y +CONFIG_CRYPTO_AES_ARM64_CE_CCM=y +CONFIG_CRYPTO_AES_ARM64_CE_BLK=y +CONFIG_CRYPTO_AES_ARM64_NEON_BLK=y +# CONFIG_CRYPTO_CHACHA20_NEON is not set +# CONFIG_CRYPTO_AES_ARM64_BS is not set +# CONFIG_BINARY_PRINTF is not set + +# +# Library routines +# +CONFIG_BITREVERSE=y +CONFIG_HAVE_ARCH_BITREVERSE=y +CONFIG_RATIONAL=y +CONFIG_GENERIC_STRNCPY_FROM_USER=y +CONFIG_GENERIC_STRNLEN_USER=y +CONFIG_GENERIC_NET_UTILS=y +CONFIG_GENERIC_PCI_IOMAP=y +CONFIG_GENERIC_IO=y +CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y +# CONFIG_CRC_CCITT is not set +CONFIG_CRC16=y +# CONFIG_CRC_T10DIF is not set +CONFIG_CRC_ITU_T=y +CONFIG_CRC32=y +# CONFIG_CRC32_SELFTEST is not set +CONFIG_CRC32_SLICEBY8=y +# CONFIG_CRC32_SLICEBY4 is not set +# CONFIG_CRC32_SARWATE is not set +# CONFIG_CRC32_BIT is not set +# CONFIG_CRC4 is not set +CONFIG_CRC7=y +# CONFIG_LIBCRC32C is not set +# CONFIG_CRC8 is not set +CONFIG_AUDIT_GENERIC=y +CONFIG_AUDIT_ARCH_COMPAT_GENERIC=y +CONFIG_AUDIT_COMPAT_GENERIC=y +# CONFIG_RANDOM32_SELFTEST is not set +CONFIG_ZLIB_INFLATE=y +CONFIG_XZ_DEC=y +CONFIG_XZ_DEC_X86=y +CONFIG_XZ_DEC_POWERPC=y +CONFIG_XZ_DEC_IA64=y +CONFIG_XZ_DEC_ARM=y +CONFIG_XZ_DEC_ARMTHUMB=y +CONFIG_XZ_DEC_SPARC=y +CONFIG_XZ_DEC_BCJ=y +# CONFIG_XZ_DEC_TEST is not set +CONFIG_GENERIC_ALLOCATOR=y +CONFIG_RADIX_TREE_MULTIORDER=y +CONFIG_ASSOCIATIVE_ARRAY=y +CONFIG_HAS_IOMEM=y +CONFIG_HAS_DMA=y +# CONFIG_DMA_NOOP_OPS is not set +# CONFIG_DMA_VIRT_OPS is not set +CONFIG_CPU_RMAP=y +CONFIG_DQL=y +CONFIG_GLOB=y +# CONFIG_GLOB_SELFTEST is not set +CONFIG_NLATTR=y +# CONFIG_CORDIC is not set +# CONFIG_DDR is not set +# CONFIG_IRQ_POLL is not set +CONFIG_LIBFDT=y +CONFIG_FONT_SUPPORT=y +# CONFIG_FONTS is not set +CONFIG_FONT_8x8=y +CONFIG_FONT_8x16=y +# CONFIG_SG_SPLIT is not set +CONFIG_SG_POOL=y +CONFIG_ARCH_HAS_SG_CHAIN=y +CONFIG_SBITMAP=y diff --git a/wiki/GMSL_Cameras_Open_Issues/vsync-csi-output.png b/wiki/GMSL_Cameras_Open_Issues/vsync-csi-output.png Binary files differnew file mode 100644 index 0000000..bc17abf --- /dev/null +++ b/wiki/GMSL_Cameras_Open_Issues/vsync-csi-output.png diff --git a/wiki/GMSL_Cameras_Open_Issues_and_testing.wiki b/wiki/GMSL_Cameras_Open_Issues_and_testing.wiki new file mode 100644 index 0000000..ad17ec7 --- /dev/null +++ b/wiki/GMSL_Cameras_Open_Issues_and_testing.wiki @@ -0,0 +1,139 @@ +h1. GMSL Cameras Open Issues and testing + +h2. Frame synchronization isn't fully understood + +The MAX9286 deserializer requires input frames to be synchronized. Cameras does operate in external trigger mode, where a frame sync signal broadcasted by the MAX9286 over all enabled GMSL links is output by the MAX9271 serializers on their GPO pin to the camera sensor. The MAX9286 can be configured to generate the frame sync signal internally, or based on an external sync signal received on its GPI pin. The current code uses internal sync unconditionally. Previous experiments used external sync when enabling a single camera. As the SoC GPIO connected to the MAX9286 GPI pin is never toggled this shouldn't have worked, but for an unknown reason we could still capture valid frames. This has to be investigated and understood. + +Understand how frame sync is emitted and which conditions prevent it from locking. + +h3. Test + +1) +Use manual frame sync with a frame period of 1905x840 pixels ( = 1905x840x2 PCLK pulses in YUYV8 format) +No locking, but monitoring calculated master link VSYNC period returns the exact number of expected PCLK pulses + +<pre> + master vsync period - 0x30d590 = 3200400 = 1905*840*2 +</pre> + +This at least confirms that FSYNC is successfully fed to camera sensors + +2) +Play around with KVAL, PVAL and DIFF periods +Anticipating that the manual does not provide any information on what time constraints have to be respected to have a successful KVAL + PVAL hit (Figure 46, above reported), play around with configuration parameters. +DIFF can be disabled (to confirm what does it mean) + +h3. patch + +http://jmondi.org/owncloud/index.php/s/RG0rq870YEHOtAy + +3) +Change AUTO_MODE to SEMI_AUTO_MODE +Try to have VSYNC follow the master link, not slowest one + +4) Try to use i2c broadcast address +To start all cameras at the same time + +h3. patch + +http://jmondi.org/owncloud/index.php/s/Fj56fNUWsFPlhBi + +h2. Horizontal and vertical sync configuration + +The MAX9286 is configured to invert vertical sync, while the MAX9271 isn't. Check whether this is caused by the sensor using a vertical sync polarity opposite of what the MAX9286 expects. Furthermore, sync signals can be encoded in different GMSL bits, make sure the serializer and deserializer agree. + +Possible answer: the INVSYNC option on de-serializer side, is used to invert vsync signal on CSI output (pag. 14 of MAX9286 programming guide) + +<pre> + INVVS Invert Vsync in CSI output +</pre> + +1) Theory 1: +De-serialize outputs <fs> on VSYNC rising edge, <fe> on VSYCN falling edge. +This would result in an invalid <fs><fe><fs> sequence on CSI-2 bus and that would explain why vertical synchronism are inverted on CSI-2 bus output. + +Figure 32 in de-serialize manual is below reported +!GMSL_Cameras_Open_Issues/vsync-csi-output.png! + +and seems to contradict the hypothesis since a single short packet is emitted on VSYNC falling edge + +<pre> +Hypothesis 1: CSI short packets for frame start/end are inverted + _ _ _ +VSYNC ________| |________________________________| |_______... ______| |_______________ + ____ ____ ____ +HREF ___________| |__| |__ ... __| |__ ... +GMSL DATA <VS1><VS0><HS1><pixel data> ... <pixel data><HS0><HS1><pixel data> ... <pixel data><HS0><VS1><VS0> +CSI <fs> <fe> <ls-0> <pixel data> ... <pixel data> <le-0> ... <ls-n> <pixel data> ... <pixel data> <le-n> <fs> <fe> +INVSYCN +CSI <fe> <fs> <ls-0> <pixel data> ... <pixel data> <le-0> ... <ls-n> <pixel data> ... <pixel data> <le-n> <fe> <fs> +</pre> + +2) Theory 2 +The OV10635 sensor is sending inverted VSYNC. +Try to change this setting bit 2 of register 0x4708 + +h3. Testing + +The deserializer is configured to invert VSYNC. Frame capture from one camera, with this configuration works fine. + +1. Remove VSYNC inversion in max9286 -> green frames +2. Invert VSYNC polarity on OV10635 side ( 0x4708 = 0x02 ) and remove VSYNC inversion on max9286 -> good frames + +This seems to confirm, OV10635 is configured to use active low VSYNC signal polarity + +h2. Lock and synchronization monitoring + +The MAX9286 provides status registers to monitor locking and synchronization. We need to make use of them for instrumentation purpose, in order to better understand the MAX9286 operation and detect error conditions. This includes the control link, serial link and video synchronization. + +Register used to monitor MAX9286 operations + +|_. Register Name |_. Register Address |_. Bits |_. Comment| +| Video Links Detected | 0x49 | D3:D0 | | +| Links Locked | 0x27 | D7 | All video links are locked | +| VSYNC Detected | 0x27 | D3:D0 | VSYNC detected on link 3:0 in the last 100ms (0ed when read) | +| Frame Diff | 0x31 0x30 | D5:D0 - D7:D0 | Difference in master PCLK cycles between fastest and slowest link | +| Master Link | 0x71 | D5:D4 | ID of link selected as master | +| FSYNC Error Counter | 0x5e | D7:D0 | Frame sync error counter (reset to zero when read)| +| Master VSYNC period | 0x5d 0x5c 0x5b | D7:D0 | Calculated VSYNC period of master link in PCLK cycles | +| FSYNC Locked | 0x31 | D6 | Frame sync locked | + +h3. Testing + +Printout of values while waiting for FSYNC locking. +Configuration: +# Link 0 and 1 enabled +# AUTO FSYNC mode +# + +<pre> +[ 48.760818] vsync detected 0x27[3:0] = b3 +[ 48.764843] fsync locked 0x31[6] = 00 +[ 48.768515] framediff 0x31[5:0] 0x30 = 3f fe +[ 48.772791] master link 0x71[5:4] = 00 +[ 48.776547] fsync err 0x52[7:0]= 01 +[ 48.780042] master vsync per - 2d 07 50 +[ 48.783884] <-------- usleep_range(2000, 50000); +[ 48.841958] vsync detected 0x27[3:0] = b3 +[ 48.845974] fsync locked 0x31[6] = 00 +[ 48.849634] framediff 0x31[5:0] 0x30 = 3f fe +[ 48.853916] master link 0x71[5:4] = 00 +[ 48.857672] fsync err 0x52[7:0]= 06 +[ 48.861158] master vsync per - 2d 07 50 +</pre> + +h3. Patch + +http://jmondi.org/owncloud/index.php/s/OLz8Ah7ZZH6X1t0 + +h2. Frame combination isn't fully understood + +According to page 26 of the MAX9286 datasheet, the deserializes combines all input video streams into a single (4 x W) x H or W x (4 x H) frame. How to select which combination mode to use isn't specified in the datasheet, neither is it explained how CSI-2 virtual channels are used. Previous experiments to capture a (4 x W) x H frame failed, with the VIN never signalling frame completion. More experiments are needed to understand how frame combination operates. + +h2. Errors in the MAX9271 datasheet + +The MAX9271 datasheet contradicts some of the tests we have performed, which could indicate errors in the datasheet. + +* Register 0x15 - PCLKDET + + The bit seems to be inverted, we read PCLKDET = 1 when a pixel clock is present. diff --git a/wiki/GMSL_Configuration.wiki b/wiki/GMSL_Configuration.wiki new file mode 100644 index 0000000..d0f2b4b --- /dev/null +++ b/wiki/GMSL_Configuration.wiki @@ -0,0 +1,213 @@ +h1. GMSL Configuration + +The system is composed by three distinct entities, each one configured separately. + +Their configurations and operating modes are below summarized, along with some points that have to be clarified on each component operations. + +h2. OV10635 + +h3. Relevant Pins and Configuration Parameters + +|_. PIN |_. Function| +|FSIN | frame sync input| +|VSYNC |vertical sync output| +|HREF | horizontal data valid output| +|D [9:0]| data pins| +|SIOD-SIOC | SCCB interface| + +h3. VSYNC/HREF Polarities + +Register 0x4708 = 0x00 + +0x4708 [2] = HREF Polarity +0x4708 [1] = VSYNC Polarity +0x4708 [0] = PCLK Polarity + +_The sensor datasheet does not report what bit value corresponds to what; Application note or support from OV may be required_ + +As default value of 0x4708 register is 0x01, we may assume what is reported in timing diagrams in the sensor manual is respected with inverted pixel clock edge (rising instead of default falling). +As the serializer is configured to latch data on the falling PCLK edge, this seems correct, as timing diagram of serializer operations show data are latched on the edge opposite to the one where pixel are emitted by the sensor) + +h3. Format configuration + +0x4300 = 0x3a = UYVY components ordering +0x4605 = 0x08 = 8-bit YUV422 mode + +h3. Timing diagram + +!GMSL_Configuration/ov10635_timings.png! + +*Note* +HREF != HSYNC +HREF (or DE Data Enable) stays high while valid data are output, for the whole line length. +VSYNC pulses at beginning of a new sensor scanout and stays low during the whole frame output duration. + +h2. MAX9271 Serializer + +h3. Relevant Pin and Configuration Parameters + +_LCCEN_: Enable/disable local control channel pins + When LCCEN pin is high the serializer operating parameters are configured through register 0x07. Alternatively if LCCEN is low, pin 14/15/22 and 23 values are used to configure the serializer + +Pull-up to Vdd in RDACM20 configuration: register 0x07 is used to configure the following parameters + +_DBL_ : Double input mode +In single input mode, pixel data are latched to PCLK falling/rising edge and their value stored one at the time in LATCH A to be then serialized on GMSL serial link. +In double input mode, pixel data are read at PCLK/2 frequency and stored in LATCH B two at the time to be then serialized on GMSL serial link. +Double input mode is required to have the serializer work with higher PCLK frequencies ( in the [33,3 - 100]MHz range in RDACM20). + +_HEVN_: Enable HS/VS encoding +Timing signals generated by the image sensor (VSYNC/HSYNC) are encoded in serial data sent on GSML link. + +_BWS_: Serial link bus width. 1 = 32bit bus width; 0 = 24bit bus width; + +_EDC_: Error correction enable/disable + +_ES_: Specifies if data are latched on rising/falling PCLK edge. 1 = falling edge; 0 = rising edge + +h3. RDACM20 Configuration + +|_. Parameter |_. Value| +|DBL | 1| +|BWS | 0| +|HVEN | 1| +|EDC | 0| +|ES | 1| + +RDACM20 uses double input mode, with a 24 bit serial link bus width, HSYNC/VSYNC encoding enabled and error correction disabled (one parity bit per word is used). Data are latched on falling PCLK edge and serialized at PCLK/2 frequency as we're using double input mode. + +The 24 bit encoded on the GMSL serial link are: + +<pre> +0:21 = 2 * 11 bit pixel data (LATCH B content, or DIN-A + DIN-B in sensor manual) +22 = Forward control channel bit +23 = parity bit +</pre> + +*Note* see Table 2 (input map) because it reports HS and VS signals in DIN-A and DIN-B but they're not part of the data sent on serial link. + +h3. Serial link data output +!GMSL_Configuration/IMG_20170822_214808.jpg! + +From the serializer manual, same image +!GMSL_Configuration/max9271-serialization.png! + +*Questions* +There are some ambiguities in the serializer manual. + +1) with HVEN enabled, synchronization signals are said to be encoded in data sent on the serial link. + +Page 33, _HS/VS Encoding and/or Tracking_ paragraph: + +<pre> + HS/VS encoding by a GMSL serializer allows horizontal + and vertical synchronization signals to be transmitted + while conserving pixel data bandwidth. With HS/VS + encoding enabled, 10-bit pixel data with a clock up to + 100MHz can be transmitted using one video pixel of + data per HS/VS transition, versus 8-bit data with a clock + up to 100MHz without HS/VS encoding. +</pre> + +From this statement it seems that each time VSYNC/HSYNC is detected (see below for what "detected" means) a special packet containing no pixel data but a "code" to indicate VS/HS is sent on the serial link ("code" as in something "GMSL proprietary" and part of the GSML protocol, not described in serializer/deserializer manual). + +From MAX9286 de-serializer manual instead, specifically in the HVSRC parameter description, it seems like the de-serializer expects HS/VS encoded in bits 14:15 (or 16:17) of the data sent on the serial link, along with pixel data. + +Possible answer: +According to information provided by the manual of a different Maxim GMSL serializer (MAX96705) [manual[https://datasheets.maximintegrated.com/en/ds/MAX96705.pdf]], when HS/VS encoding is used, a packet with no pixel data but only informations about synchronism signals are sent during blank periods. Alternatively, if no HS/VS encoding is used, 2 bit of pixel data are reserved for HS/VS tracking. This seems to match the "10-bit vs 8-bit" reported in the above quote from serializer manual. + +2) The following statement is not clear to me. +Page 33, _HS/VS Encoding and/or Tracking_ paragraph + +<pre> + HS/VS encoding sends packets when HSYNC or VSYNC is low, use H/V + inversion register bits if input HSYNC and VSYNC signals + use an active-low convention to send data packets during the + inactive pixel clock periods. +</pre> + +It seems from this statement that the serializer expects VSYNC to behave as Data Valid (stay high during the whole frame duration) and low during frame blanking (which is basically the inverted logic compared to what the image sensor does). +If this is true, we should receive VSYNC packets during the whole frame duration, but that's not possible, as we actually receive data. Also, VSYNC polarity is inverted on de-serializer side, not on serializer one. + +Possible answer: +The above quote from the serializer manual may be interpreted simply as the confirmation that packets containing encoded HS/VS information (now that another serializer manual confirmed that actual packets are sent for this purpose) are sent on the serial link when the synch signal is low, to guarantee no active pixel data are sent by the sensor during this "inactive" periods (this allows to connect HREF signal to HSYNC, as it happens in rdacm20 configuration). + +It is legit to assume the encoded HS/VS signals are sent recording transactions of falling and rising edges + +h3. Synchronism signal timings +To be verified in image sensor configuration if the following constraints are respected + +With DBL=1: +* HS/VS low pulse duration >= 5 PCLK cycles +* HS/VS high pulse duration >= 2 PCLK cycles +* Active duration of HS/VS + Blankings must be an even multiple of PCLK pulses + +h2. MAX9286 De-Serializer + +h3. De-serializer Configuration Parameters + +h3. general configuration + +Register 0x12 +|DBL | 1| +|EDC | 0| +|BWS |0 (pull down to ground)| + +h3. FSYNC and VSYNC signal configuration + +The de-serializer run by default with inverted VSYNC +Register 0x0c +|HVEN |1| +|INVS |1| +|HVSRC | 01| + +FSYNC parameters + +|_. Parameter |_. Register |_. Bits |_.Default value |_.max9286 setting|_. Comment | +|MSTLINKSEL | 0x00 | 7:5 | 111 | 111| Autodetect link used for CSI clock source | +|EN_VS_GEN| 0x00 | 4 | 0 | 0 | Disable internal VSYNC (comes from Cameras) | +|FSYNCMODE | 0x01 | 7:6 | 00 | 00 | Internally generate FSYNC| +|FSYNCMETH | 0x01 | 1:0 | 10 | 10 | Auto mode: fsync follows slowest link | +|FSYNC_PERDIV | 0x02 | 7:4 | 0000 | 0000 | FSYNC generated after 1 VSYNC pulse (on slowest link: auto mode) | +|KVALSIGN | 0x03 | 4 | 0 | 0 | Positive KVAL value | +|KVAL| 0x03 | 3:0 | 0001 | 0001 | 2us margin respect to rising edge of sloweset (auto mode) link | +|PVALL|0x04 | 7:0 | 00000000 | 00000000 | Desired margin in PCLK cycles from rising edge of slowest (auto mode) link; Low byte | +|PVALH| 0x05 | 4:0 | 0000 | 0000 | Desired margin in PCLK cycles from rising edge of slowest (auto mode) link; High byte | +|PVALSIGN| 0x05 | 5 | 0 | 0 | Positive PVAL value | +|FRMDIFFTHRL| 0x61 | 7:0 | 0 | 0 | Low byte of error threshold between the earliest and latest +VSYNC (in pixel clock cycles) | +|FRMDIFFTHRL| 0x62 | 4:0 | 01111 | 01111 | High byte of error threshold between the earliest and latest +VSYNC (in pixel clock cycles). Disabled if all 13 bits are 0s| +|ENFSINLAST | 0x64 | 5 | 0 | 0 | FSIN occurs anytime between VS rising edges (alternative is: FSIN occurs after all VS rising edges| + +KVAL and PVAL not configured in max9286 setup :/ + +The previously values determinate how frame synchronization is performed + +!GMSL_Configuration/fsync.png! + + +h3. HS/VS location + +HVSRC parameter description in register 0x0c (page 66) reports that the de-serializer expects HS/VS in bit 14:15 + +<pre> + Use D14/D15 for HSYNC/VSYNC (D[19:16] shifted to D[17:14]). + For use with the MAX9271 when DBL = 0 or when HVEN = 1._ +</pre> + +The following image describing the input map expected by deserializer for yuv8 format confirms that + +!GMSL_Configuration/de-serializer-input-map.png! + +This seems pretty different from what the serializer sends on the serial link, as bit 0:21 are reserved for two 11bit pixel data word, and there is no mention of HS/VS encoding in bits 14:15 (or 16:17). +So, HS/VS are either encoded in special packets with no pixel data (something like CSI-2 short packets) or their bits part of the data sent on the serial link along with pixel data (but in that case, it seems all the 24 bits used by the serializer are actually used by two pixel data word) + +h3. VSYNC inversion + +The deserializer is configured to run with inverted VSYNC output on CSI bus. +See below what it can possibly mean (inversion of short packet vertical synchronization codes?) + +h2. Open issues and testing + +A list of open issues and performed testing is reported in the following page diff --git a/wiki/GMSL_Configuration/de-serializer-input-map.png b/wiki/GMSL_Configuration/de-serializer-input-map.png Binary files differnew file mode 100644 index 0000000..b2315e6 --- /dev/null +++ b/wiki/GMSL_Configuration/de-serializer-input-map.png diff --git a/wiki/GMSL_Configuration/fsync.png b/wiki/GMSL_Configuration/fsync.png Binary files differnew file mode 100644 index 0000000..39c8382 --- /dev/null +++ b/wiki/GMSL_Configuration/fsync.png diff --git a/wiki/GMSL_Configuration/max9271-serialization.png b/wiki/GMSL_Configuration/max9271-serialization.png Binary files differnew file mode 100644 index 0000000..e73092f --- /dev/null +++ b/wiki/GMSL_Configuration/max9271-serialization.png diff --git a/wiki/GMSL_Configuration/ov10635_timings.png b/wiki/GMSL_Configuration/ov10635_timings.png Binary files differnew file mode 100644 index 0000000..29b2e18 --- /dev/null +++ b/wiki/GMSL_Configuration/ov10635_timings.png diff --git a/wiki/H3_Salvator-X.wiki b/wiki/H3_Salvator-X.wiki new file mode 100644 index 0000000..282958d --- /dev/null +++ b/wiki/H3_Salvator-X.wiki @@ -0,0 +1,127 @@ +h1. H3 Salvator-x + +h2. Update FirmWare + +# download update script from below +# run script + +h3. SW10 + +0 corresponds to the switch in the OFF position and 1 to the ON position. Bits are given in the 1-8 order. + +<pre> +for update: xxxx 0000 +for use : xxxx 1100 (HyperFlash = 80MHz, stable) or + xxxx 1101 (HyperFlash = 160MHz, aggressive) +</pre> + +Maybe it is *1100 1100* or *1100 1101* on your board + +h3. Run script + +see readme +<pre> +./do_xls2.expect /dev/ttyUSB1 ./AArch64_secure_writer.mot ./table.txt +</pre> +or +<pre> +for ES1.0 : ./do_xls2.expect /dev/ttyUSB1 57600 ./AArch64_secure_writer.mot ./table.txt +for ES1.1 : ./do_xls2.expect /dev/ttyUSB1 115200 ./AArch64_secure_writer_es11.mot ./table.txt +for ES2.0 : ./do_xls2.expect /dev/ttyUSB1 115200 ./AArch64_Gen3_Scif_MiniMon_H3ES2.0_V0.03.mot ./table.txt +</pre> + +h3. Log + +<pre> +> ./do_xls2.expect /dev/ttyUSB1 ./AArch64_secure_writer.mot ./table.txt +uploading loader file +performing xls2 e6320000 000000 bootparam_sa0.srec +performing xls2 e6302000 040000 bl2-salvator-x.srec +performing xls2 e6320000 180000 cert_header_sa6.srec +performing xls2 44000000 1c0000 bl31-salvator-x.srec +performing xls2 44100000 200000 tee-salvator-x.srec +performing xls2 49000000 640000 u-boot-elf.srec +</pre> + +h3. version + +| "v2.2.0":../../wiki/H3_Salvator-X/update_salvator_bootloader_v220.tar.bz2 |BL2: R-Car H3 Loader Rev.1.00 +BL2: Built : 19:20:17, Nov 2 2015 +U-Boot 2015.04 (Nov 02 2015 - 19:20:59) |*require SWICH settings* +- -SW6: 3 pin side- +- SW7: 2 pin side | +| "v2.3.0":../../wiki/H3_Salvator-X/update_salvator_bootloader_v230.tar.bz2 |BL2: R-Car H3 Loader Rev.1.0.1 +BL2: Built : 11:47:26, Nov 19 2015 +U-Boot 2015.04 (Nov 19 2015 - 11:47:49) |*require SWICH settings* +- -SW6: 3 pin side- +- SW7: 2 pin side | +| "v2.7.0 4core":../../wiki/H3_Salvator-X/update_salvator_bootloader_v270-4core.tar.bz2 |BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.5 +BL2: Built : 12:41:15, Mar 30 2016 +U-Boot 2015.04 (Mar 30 2016 - 12:41:37) |*require SWICH settings* +- -SW6: 3 pin side- +- SW7: 2 pin side | +| "v2.7.0 8core":../../wiki/H3_Salvator-X/update_salvator_bootloader_v270-8core.tar.bz2 |BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.5 +BL2: Built : 12:59:01, Mar 30 2016 +U-Boot 2015.04 (Mar 30 2016 - 12:41:37) |*require SWICH settings* +- -SW6: 3 pin side- +- SW7: 2 pin side | +| "v2.9.0 for 8ch camera":../../wiki/H3_Salvator-X/update_salvator_bootloader_v290-v2.tar.bz2 |BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.7 +BL2: Built : 16:41:30, May 26 2016 +U-Boot 2015.04 (May 26 2016 - 16:49:14) |*require SWICH settings* +- -SW6: 3 pin side- +- SW7: 2 pin side | +| "v2.11.0 no lossy":../../wiki/H3_Salvator-X/update_salvator_bootloader_v2110-nolossy.tar.bz2 |BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.8 +BL2: Built : 19:35:27, Jul 27 2016 +U-Boot 2015.04 (Jul 25 2016 - 20:28:04) |*require SWICH settings* +- -SW6: 3 pin side- +- SW7: 2 pin side | +| "v2.12.0":../../wiki/H3_Salvator-X/update_salvator_bootloader_v2120.tar.bz2 | BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.9 +BL2: Built : 11:32:54, Sep 13 2016 +U-Boot 2015.04 (Sep 13 2016 - 11:32:36) | PMIC will be shutdown on this version when S2RAM +*require SWICH settings* +- -SW6: 1 pin side (default is 3)- +- SW7: 1 pin side (default is 2) +- SW8: all OFF +*How to S2RAM* +- Set to PMIC to backup mode via i2c-tools command +<pre># i2cset -f -y 7 0x30 0x20 0x0F</pre> +- (Suspend) Change SW23 to OFF +- Request System Suspend to RAM +<pre># echo mem > /sys/power/state</pre> +- (Resume) Change SW23 to ON | +| "v2.16.0":../../wiki/H3_Salvator-X/update_salvator_bootloader_v2160.tar.bz2|BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.12 +BL2: Built : 16:03:29, Jan 30 2017 +U-Boot 2015.04 (Jan 30 2017 - 16:03:32)|*require SWICH settings* +- -SW6: 1 pin side (default is 3)- +- SW7: 1 pin side (default is 2) +- SW8: all OFF +*How to S2RAM* +see above +*uboot position* was moved from *H'49000000* to *H'50000000* | +| "v2.19.0+es2.0":../../wiki/H3_Salvator-X/update_salvator_bootloader_v2190+es20.tar.bz2 |BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.14 +BL2: Built : 12:21:23, Apr 27 2017 +U-Boot 2015.04 (Apr 27 2017 - 12:21:26)|*require SWICH settings* +- -SW6: 1 pin side (default is 3)- +- SW7: 1 pin side (default is 2) +- SW8: all OFF +*How to S2RAM* +see above| +| "v2.23.0":../../wiki/H3_Salvator-X/update_salvator_bootloader_v2230.tar.bz2 |BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.16 +BL2: Built : 16:16:53, Oct 2 2017 +U-Boot 2015.04 (Oct 02 2017 - 16:12:31)|*require SWICH settings* +- -SW6: 1 pin side (default is 3)- +- SW7: 1 pin side (default is 2) +- SW8: all OFF +*How to S2RAM* +see above| + + +h2. Release Note + +* "Yocto Release Note":../../wiki/H3_Salvator-X/RENESAS_RCH3M3_YoctoReleaseNote_E_v2.23.0.pdf +* "IPL Release Note":../../wiki/H3_Salvator-X/RENESAS_RCH3M3_IPL_ReleaseNote_E_v1.0.16.pdf + +h1. Files + +"zip: Gen3 MiniMonitor v3.03":../../wiki/H3_Salvator-X/Gen3_MiniMonitor_V3.03-20180208.zip +"mot: Gen3 H3/M3 MiniMon v3.03":../../wiki/H3_Salvator-X/AArch64_Gen3_H3_M3_Scif_MiniMon_V3.03.mot diff --git a/wiki/H3_Salvator-X/AArch64_Gen3_H3_M3_Scif_MiniMon_V3.03.mot b/wiki/H3_Salvator-X/AArch64_Gen3_H3_M3_Scif_MiniMon_V3.03.mot new file mode 100644 index 0000000..97c0416 --- /dev/null +++ b/wiki/H3_Salvator-X/AArch64_Gen3_H3_M3_Scif_MiniMon_V3.03.mot @@ -0,0 +1,10678 @@ +S02B0000414172636836345F6F75747075742F414172636836345F47656E335F48335F4D335F536369665F4D4E +S309E630040000000000DC +S309E630048C0000000050 +S309E63005D4002030E6D1 +S309E63006E400C0020034 +S309E6301154002030E645 +S309E630126400C00200A8 +S315E6302000000080D2010080D2020080D2030080D266 +S315E6302010040080D2050080D2060080D2070080D246 +S315E6302020080080D2090080D20A0080D20B0080D226 +S315E63020300C0080D20D0080D20E0080D20F0080D206 +S315E6302040100080D2110080D2120080D2130080D2E6 +S315E6302050140080D2150080D2F60300AAF70300AA50 +S315E6302060F80300AAF90300AAFA0300AAFB0300AABA +S315E6302070FC0300AAFD0300AAFE0300AA600300588B +S315E630208021030018010000B940030058004118D575 +S315E630209000411CD500411ED51F000091204018D5C1 +S315E63020A020401CD520401ED5004018D500401CD512 +S315E63020B000401ED500103ED5000074B200007FB257 +S315E63020C000007DB200101ED5DF3F03D5AF01009488 +S315E63020D03C020094A0020094440B0094FE47009420 +S315E63020E0420D00940100000018007FE60000000073 +S315E63020F0000033E6000000001F2003D51F2003D57D +S315E6302100818280D2C1C0BCF2200040B900000A32DA +S315E6302110E303202AC2C0BCD2430000B9200000B98E +S315E6302120808280D2C0C0BCF2000040B9A0FFB7368C +S315E6302130818A80D2C1C0BCF2200040B9007809124B +S315E6302140E303202AC2C0BCD2430000B9200000B95E +S315E6302150808A80D2C0C0BCF2000040B9A0FFB73753 +S315E6302160FD7BBEA9FD030091F30B00F920008052FA +S315E630217037030094E1018052C0008052190300947F +S315E6302180F303002A818A80D2C1C0BCF2200040B96E +S315E630219000000A32E303202AC2C0BCD2430000B9AB +S315E63021A0200000B9808A80D2C0C0BCF2000040B9B7 +S315E63021B0A0FFB7362000805225030094E101805215 +S315E63021C0C000805207030094E303002A828280D25D +S315E63021D0C2C0BCF2410040B921780912E403212A93 +S315E63021E0C0C0BCD2040000B9410000B9818280D2B9 +S315E63021F0C1C0BCF2210040B920000A1281FFB737D0 +S315E63022007F02036B4000005420008052F30B40F906 +S315E6302210FD7BC2A8C0035FD6018380D2C1C0BCF2C3 +S315E6302220200040B900000032E303202AC2C0BCD207 +S315E6302230430000B9200000B9008380D2C0C0BCF2AA +S315E6302240000040B9A0FF0736018B80D2C1C0BCF290 +S315E6302250200040B900781F12E303202AC2C0BCD260 +S315E6302260430000B9200000B9008B80D2C0C0BCF272 +S315E6302270000040B9A0FF0737FD7BBEA9FD030091FC +S315E6302280F30B00F920008052F102009421038052CC +S315E6302290C0008052D3020094F303002A018B80D229 +S315E63022A0C1C0BCF2200040B900000032E303202A68 +S315E63022B0C2C0BCD2430000B9200000B9008B80D240 +S315E63022C0C0C0BCF2000040B9A0FF073620008052FD +S315E63022D0DF02009421038052C0008052C10200948E +S315E63022E0E303002A028380D2C2C0BCF2410040B981 +S315E63022F021781F12E403212AC0C0BCD2040000B9FB +S315E6302300410000B9018380D2C1C0BCF2210040B998 +S315E63023102000001281FF07377F02036B400000542E +S315E630232020008052F30B40F9FD7BC2A8C0035FD68E +S315E6302330800880D200FEBFF2000040B9023C0012AF +S315E6302340810200D022D800B9021C1812810200D0D0 +S315E630235022DC00B9001C0012810200D020D000B980 +S315E6302360C0035FD6800200D001DC40B900408A5215 +S315E63023703F00006B21010054800200D000D040B906 +S315E6302380C0000035FD7BBFA9FD030091D126009440 +S315E6302390FD7BC1A8C0035FD6C0035FD6FD7BBBA974 +S315E63023A0FD03009101008052200100B000401591F6 +S315E63023B0980C009482008052A1430091800200D0AE +S315E63023C000D840B9E10D009401008052A043009157 +S315E63023D0900C009421008052200100F000202991D3 +S315E63023E08C0C0094FD7BC5A8C0035FD6FD7BBFA9E8 +S315E63023F0FD030091011C0053800200D002DC40B997 +S315E630240000408A525F00006B20020054A800005458 +S315E630241000E089525F00006B20010054180000147A +S315E630242000808A525F00006BA001005400008B5298 +S315E63024305F00006BC001005411000014200100B0AB +S315E630244000A01591730C009410000014200100B022 +S315E630245000E015916F0C00940C000014200100B0DA +S315E6302460002016916B0C009408000014200100B091 +S315E630247000601691670C009404000014200100B049 +S315E630248000A01691630C0094FD7BC1A8C0035FD60D +S315E6302490FD7BBAA9FD030091F35301A9141C005341 +S315E63024A001008052200100B000401791590C00948B +S315E63024B0800200D001D840B900428A523F00006B14 +S315E63024C0C1000054E103142A200100B000601791E0 +S315E63024D0500C00941F000014930200D060D240B92D +S315E63024E0000C1C1222008052A1830091004000119C +S315E63024F0960D009401008052A0830091450C00941D +S315E630250020008052FF0C009401008052200100F03A +S315E6302510000037913F0C009460D240B922008052D9 +S315E6302520A1830091000C1C53880D00940100805263 +S315E6302530A0830091370C009420008052F10C009471 +S315E6302540E103142A200100D000A02B91310C00942F +S315E6302550F35341A9FD7BC6A8C0035FD6FD7BBFA971 +S315E6302560FD03009101008052200100B000801791F2 +S315E6302570280C0094000080529DFFFF972000805281 +S315E6302580C4FFFF97FD7BC1A8C0035FD6FD7BBEA91E +S315E6302590FD030091000280520E41009424008052E1 +S315E63025A0A3730091020E80520114805200028052CB +S315E63025B043420094A0734039FD7BC2A8C0035FD680 +S315E63025C0FD7BBEA9FD030091000080529544009440 +S315E63025D024008052A3730091020E80520114805279 +S315E63025E00000805256430094A0734039FD7BC2A862 +S315E63025F0C0035FD6FD7BBDA9FD030091F30B00F961 +S315E6302600131C005300028052F2400094A3C300919B +S315E630261073CC1FB824008052020E805201148052C9 +S315E630262000028052EF420094200080524D02009420 +S315E6302630E01F8052A02F00B9330080520A00001402 +S315E630264024008052A3B3009162C201110114805274 +S315E630265000028052E3420094200080524102009408 +S315E6302660730600117F3E0071C9FEFF54F30B40F945 +S315E6302670FD7BC3A8C0035FD6FD7BBDA9FD030091F4 +S315E6302680F30B00F9131C00530000805265440094A6 +S315E630269021008052200100B000E01791DD0B009456 +S315E63026A0A3C3009173CC1FB824008052020E805229 +S315E63026B00114805200008052CA4300944001805291 +S315E63026C028020094E01F8052A02F00B933008052D2 +S315E63026D00A00001424008052A3B3009162C20111AD +S315E63026E00114805200008052BE430094400180526D +S315E63026F01C020094730600117F3E0071C9FEFF543A +S315E6302700F30B40F9FD7BC3A8C0035FD6FD7BBFA9BB +S315E6302710FD030091810200D022DC40B901E0895206 +S315E63027205F00016B6100005499FFFF97001C005370 +S315E6302730810200D022DC40B901408A525F00016B4B +S315E63027406100005492FFFF97001C0053810200D0CF +S315E630275021DC40B902808A523F00026B41000054C8 +S315E63027600003805202008B523F00026B6100005438 +S315E630277094FFFF97001C0053810200D020500339A6 +S315E6302780FD7BC1A8C0035FD6FD7BBFA9FD030091E3 +S315E6302790E8FEFF97DEFFFF97FD7BC1A8C0035FD655 +S315E63027A0FD7BBEA9FD030091F30B00F9131C005324 +S315E63027B0800200D001DC40B900E089523F00006B70 +S315E63027C061000054E003132A8BFFFF97800200D0A6 +S315E63027D001DC40B900408A523F00006B610000548C +S315E63027E0E003132A84FFFF97800200D001DC40B96C +S315E63027F000008B523F00006B61000054E003132A61 +S315E63028009EFFFF97C2FFFF97F30B40F9FD7BC2A809 +S315E6302810C0035FD600101D121F600171E803005435 +S315E6302820E100009021C03B912048603861000010FD +S315E63028302088208B00001FD6200100B0004018917A +S315E6302840C0035FD6200100B000A01891C0035FD662 +S315E6302850200100B000E01891C0035FD6200100B039 +S315E630286000001991C0035FD6200100B000401991EF +S315E6302870C0035FD6200100B000801991C0035FD651 +S315E6302880200100B000A01991C0035FD6200100B048 +S315E630289000C01991C0035FD6200100B000201A911E +S315E63028A0C0035FD6200100B000801891C0035FD622 +S315E63028B0FD7BBEA9FD030091F30B00F9131C005313 +S315E63028C0800200D000504339D3FFFF97E103132A45 +S315E63028D0500B0094F30B40F9FD7BC2A8C0035FD6DC +S315E63028E000080012E100009021303D912048603822 +S315E63028F0610000102088208B00001FD6200100B032 +S315E630290000801A91C0035FD6200100B000A01A916C +S315E6302910C0035FD6200100B000C01A91C0035FD66F +S315E6302920200100D000002991C0035FD6200100B017 +S315E630293000E01A91C0035FD6200100B000001B917B +S315E6302940C0035FD6200100D000E00091C0035FD619 +S315E6302950200100B000601A91C0035FD6FD7BBEA9A8 +S315E6302960FD030091F30B00F9131C0053800200D0EF +S315E630297000504339DBFFFF97E103132A250B00941A +S315E6302980F30B40F9FD7BC2A8C0035FD6FD7BBFA93A +S315E6302990FD030091DBFDFF97A00000341FFEFF9795 +S315E63029A0A000003500018052040000140000805279 +S315E63029B00200001400028052FD7BC1A8C0035FD638 +S315E63029C0800200D01FE000B9800200D000504339C3 +S315E63029D01FFC0371A102005421008052800200D010 +S315E63029E001E000B9800200D001DC40B900E089524E +S315E63029F03F00006BE2179F1A00408A523F00006B99 +S315E6302A00E0179F1A4000002A00010034FD7BBFA97B +S315E6302A10FD030091DEFFFF97810200D02050033997 +S315E6302A20FD7BC1A8C0035FD6C0035FD6810200D066 +S315E6302A3020500339C0035FD6FD7BBFA9FD03009165 +S315E6302A40011C0053820200D04250433942101D72B7 +S315E6302A50E4179F1A5F800071E3179F1A8300032AF3 +S315E6302A60A3000034200100B000201B91E90A00944F +S315E6302A70200000145F200071A1000054200100B050 +S315E6302A8000801891E30A00941A0000145F40007142 +S315E6302A90E0179F1A5F600171E3179F1A0300032A56 +S315E6302AA0A3000034200100B000A01B91D90A00949F +S315E6302AB0100000145F600071A1000054200100B0E0 +S315E6302AC000E01891D30A00940A0000145FE0007122 +S315E6302AD0A1000054200100B000A01991CD0A00945F +S315E6302AE004000014200100B000401C91C90A00948D +S315E6302AF0FD7BC1A8C0035FD6FD7BBEA9FD03009171 +S315E6302B00F30B00F9131C005301008052200100B08C +S315E6302B1000A01C91BF0A0094800200D000E040B9C4 +S315E6302B20C0000034E103132A200100B000001D91F5 +S315E6302B30B80A009405000014E103132A200100B018 +S315E6302B4000601D91B30A0094F30B40F9FD7BC2A8F1 +S315E6302B50C0035FD6FD7BBFA9FD030091800200D09E +S315E6302B6000DC40B901E089521F00016B8100005458 +S315E6302B709D050094ED0500940600001401408A5246 +S315E6302B801F00016B610000540D0300946903009445 +S315E6302B90FD7BC1A8C0035FD6FD7BBFA9FD030091CF +S315E6302BA0800200D000DC40B901E089521F00016B9B +S315E6302BB0E2179F1A01408A521F00016BE1179F1AEE +S315E6302BC04100012A61000034FB0500940A00001436 +S315E6302BD001808A521F00016B61000054F6050094AD +S315E6302BE00500001401008B521F00016B41000054B2 +S315E6302BF0F1050094FD7BC1A8C0035FD6FD7BBFA976 +S315E6302C00FD030091800200D000DC40B901E0895234 +S315E6302C101F00016B810000542F040094FF040094DA +S315E6302C201000001401408A521F00016B81000054E7 +S315E6302C3004020094910200940A00001421008052A6 +S315E6302C40200100B000A01D91720A0094DE090094BE +S315E6302C5001008052200100B000A016916D0A009462 +S315E6302C60FD7BC1A8C0035FD6FD7BBFA9FD030091FE +S315E6302C70800200D000DC40B901E089521F00016BCA +S315E6302C8081000054320400940705009410000014C5 +S315E6302C9001408A521F00016B8100005407020094FE +S315E6302CA0890200940A00001421008052200100B007 +S315E6302CB000A01D91570A0094C30900940100805282 +S315E6302CC0200100B000A01691520A0094FD7BC1A8FF +S315E6302CD0C0035FD6FD7BB9A9FD030091F30B00F97E +S315E6302CE0800200D01FE400B921008052200100D0D6 +S315E6302CF000A02B91470A0094330100B073E21D9190 +S315E6302D0021008052E00313AA420A00942100805241 +S315E6302D10200100B000A01E913E0A009421008052A8 +S315E6302D20200100B000601F913A0A009421008052DB +S315E6302D30200100B000202091360A0094210080520E +S315E6302D40200100B000E02091320A00942100805242 +S315E6302D50E00313AA2F0A0094330080521D000014B4 +S315E6302D6001008052200100B000A02191290A00948A +S315E6302D70A1BF0091A0C30091560A0094A0C3403982 +S315E6302D801FC80071200100541FCC00718001005429 +S315E6302D901FC40071E1010054A1F2AE52800200D0A8 +S315E6302DA001E400B90A00001421028052A1F2AE72A3 +S315E6302DB0800200D001E400B90500001441028052D9 +S315E6302DC0A1F2AE72800200D001E400B9130080525F +S315E6302DD093FCFF35F30B40F9FD7BC7A8C0035FD6FE +S315E6302DE0E200009042603D91405860F8020040B9FA +S315E6302DF0200080520120C11A2000026A40000054A9 +S315E6302E0020008052C0035FD6000780D2A0C2BCF253 +S315E6302E10000040B9A001C83600780612E203202A3F +S315E6302E20012081D2A1C2BCF2220000B9812680D22D +S315E6302E30A1C2BCF2200000B9000780D2A0C2BCF223 +S315E6302E40000040B9A0FFCF37C0035FD6FD7BBEA9F1 +S315E6302E50FD030091F30B00F9F303002AEBFFFF972E +S315E6302E60000280D2C0C3BCF21F000079800200D0D7 +S315E6302E7001DC40B900E089523F00006BE2179F1A49 +S315E6302E8000408A523F00006BE0179F1A4000002A46 +S315E6302E908000003500808A523F00006B21010054E5 +S315E6302EA0A0028052810180D2C1C3BCF2200000B9B3 +S315E6302EB0010180D2C1C3BCF2200000B90B00001478 +S315E6302EC000008B523F00006B0101005480078052B0 +S315E6302ED0810180D2C1C3BCF2200000B9010180D2A3 +S315E6302EE0C1C3BCF2200000B9810080D2C1C3BCF2B6 +S315E6302EF020004039001C0053000000322000003923 +S315E6302F00010080520D000014000280D2C0C3BCF22C +S315E6302F1000004079A0FF4736020280D2C2C3BCF237 +S315E6302F2040004079003C005300781712003C0053CD +S315E6302F3040000079210400113F00136B63FEFF5415 +S315E6302F40810080D2C1C3BCF22000403900181F127E +S315E6302F5020000039F30B40F9FD7BC2A8C0035FD6EB +S315E6302F60FD7BBEA9FD030091F30B00F9F303002ABE +S315E6302F70A6FFFF97000280D2C0C3BCF21F000079DD +S315E6302F80800200D001DC40B900E089523F00006B98 +S315E6302F90E2179F1A00408A523F00006BE0179F1AED +S315E6302FA04000002A8000003500808A523F00006BE0 +S315E6302FB021010054202C8A52810180D2C1C3BCF251 +S315E6302FC0200000B9010180D2C1C3BCF2200000B9AD +S315E6302FD00B00001400008B523F00006B01010054D9 +S315E6302FE0004C9D52810180D2C1C3BCF2200000B9AB +S315E6302FF0010180D2C1C3BCF2200000B9810080D283 +S315E6303000C1C3BCF220004039001C00530000003238 +S315E630301020000039010080520D000014000280D2F3 +S315E6303020C0C3BCF200004079A0FF4736020280D228 +S315E6303030C2C3BCF240004079003C00530078171218 +S315E6303040003C005340000079210400113F00136B29 +S315E630305063FEFF54810080D2C1C3BCF22000403902 +S315E630306000181F1220000039F30B40F9FD7BC2A889 +S315E6303070C0035FD6FD7BBFA9FD03009138FDFF9700 +S315E6303080C7FCFF97FD7BC1A8C0035FD6C0C0BCD2E4 +S315E630309001008012010000B902A080D2C2C0BCF2A3 +S315E63030A05F0000B9010000B9421000915F0000B937 +S315E63030B0010000B9002014911F0000B9C0035FD6A5 +S315E63030C0800200B00050433900101D121F200071F7 +S315E63030D001010054E1078012C0C0BCD2010000B93C +S315E63030E0E107805200000E91010000B9C0035FD6B9 +S315E63030F001F89F52E100B872C0C0BCD2010000B9F7 +S315E6303100E107805201FFA77200000E91010000B977 +S315E6303110C0035FD6C0C0BCD2E1E70232010000B9D7 +S315E6303120E2E70032016080D2C1C0BCF2220000B9CB +S315E6303130019999528199B972010000B9421000118C +S315E6303140816080D2C1C0BCF2220000B9E2E301322E +S315E6303150020000B9E1EB0032036180D2C3C0BCF2B3 +S315E6303160610000B9020000B963100091610000B950 +S315E6303170020000B963100091610000B9020000B99F +S315E630318063100091610000B9020000B96310009146 +S315E6303190610000B9020000B963100091610000B920 +S315E63031A0020000B963100091610000B9020000B96F +S315E63031B063100091610000B9020000B96310009116 +S315E63031C0610000B9831991520311B172030000B957 +S315E63031D064E68E52E4EEAE72836580D2C3C0BCF24C +S315E63031E0640000B9E3F99F52E399B972030000B976 +S315E63031F0040680520466A672036680D2C3C0BCF269 +S315E6303200640000B9031191520391B972030000B913 +S315E6303210E4EE8E52E46EA672836680D2C3C0BCF20A +S315E6303220640000B9020000B963100091610000B98C +S315E6303230020000B963100091610000B9020000B9DE +S315E630324063100091610000B9020000B96310009185 +S315E6303250610000B9020000B963100091610000B95F +S315E6303260020000B963100091610000B9020000B9AE +S315E630327063100091610000B9020000B96310009155 +S315E6303280610000B9020000B963100091610000B92F +S315E6303290020000B9826B80D2C2C0BCF2410000B9EE +S315E63032A0E11191520111B172010000B901EE8E526F +S315E63032B0E1EEAE7200800D91010000B9C0035FD633 +S315E63032C0C0C0BCD2E1F78B12010000B9E2F78B52EF +S315E63032D0018880D2C1C0BCF2220000B921009E52DC +S315E63032E0E1FBBF72010000B9C2FF81520204A0724F +S315E63032F0818880D2C1C0BCF2220000B921C39F5278 +S315E6303300E19FB972010000B9C23C80520260A672F2 +S315E6303310018980D2C1C0BCF2220000B9015C8012BC +S315E6303320010000B9025C8052818980D2C1C0BCF20C +S315E6303330220000B9E11F8052010000B9E21F801277 +S315E6303340018A80D2C1C0BCF2220000B9010F805298 +S315E63033500114B072010000B9E2F09F52E2EBAF72AF +S315E6303360818A80D2C1C0BCF2220000B9A10A80129D +S315E6303370010000B9A10A805200601191010000B93E +S315E6303380C0035FD6C0C0BCD2E1FF8112010000B9EE +S315E6303390E2FF8152018080D2C1C0BCF2220000B980 +S315E63033A061B99F52E1FDBF72010000B98246805293 +S315E63033B00202A072818080D2C1C0BCF2220000B97E +S315E63033C081988012010000B982988052018180D2BC +S315E63033D0C1C0BCF2220000B901408012010000B93A +S315E63033E002408052818180D2C1C0BCF2220000B94F +S315E63033F001C0A712010000B902C0A752018280D2ED +S315E6303400C1C0BCF2220000B941FF9E52E11FBC7238 +S315E6303410010000B9A200815202E0A372818280D215 +S315E6303420C1C0BCF2220000B9C1008012010000B969 +S315E6303430C100805200601091010000B9C0035FD62A +S315E6303440C0C0BCD2E1BB9B52A1BBBF72010000B982 +S315E6303450024484524244A072814080D2C1C0BCF25A +S315E6303460220000B901008012010000B9024180D283 +S315E6303470C2C0BCF25F0000B9010000B9421000914B +S315E63034805F0000B9010000B9421000915F0000B953 +S315E6303490010000B9421000915F0000B9010000B9A1 +S315E63034A0421000915F0000B9010000B90070089142 +S315E63034B01F0000B9C0035FD6C0C0BCD2819999520D +S315E63034C0E1FFB372010000B9626686520200AC7261 +S315E63034D0814080D2C1C0BCF2220000B9213393527A +S315E63034E02133BF72010000B9C2CC8C52C2CCA07275 +S315E63034F0014180D2C1C0BCF2220000B9E4FF93524A +S315E63035002433B372040000B903008C52C3CCAC72D8 +S315E630351021100091230000B9C2CC8012020000B916 +S315E6303520C1CC8052054280D2C5C0BCF2A10000B9FA +S315E630353005C08012050000B906C08052854280D2A9 +S315E6303540C5C0BCF2A60000B9040000B9044380D277 +S315E6303550C4C0BCF2830000B9020000B9007008911D +S315E6303560010000B9C0035FD6FD7BBEA9FD0300911D +S315E6303570F35301A9D3C0BCD214008012740200B949 +S315E6303580004080D2C0C0BCF21F0000B9CBFFFF9727 +S315E63035902022A212600200B92122A252004480D231 +S315E63035A0C0C0BCF2010000B9740200B90010009147 +S315E63035B01F0000B90000A212600200B90100A25253 +S315E63035C0004580D2C0C0BCF2010000B9C0FF9F52B0 +S315E63035D0E07FBF72600200B9210080520180A0729E +S315E63035E0804580D2C0C0BCF2010000B900808012AE +S315E63035F0600200B901808052004680D2C0C0BCF27B +S315E6303600010000B9E09F9F52E0FFAF72600200B959 +S315E6303610016080520100B072804680D2C0C0BCF2F2 +S315E6303620010000B900078012600200B90107805236 +S315E6303630004780D2C0C0BCF2010000B9740200B9BE +S315E6303640001000911F0000B9740200B90010009115 +S315E63036501F0000B900028012600200B901028052F2 +S315E6303660804880D2C0C0BCF2010000B9F35341A90C +S315E6303670FD7BC2A8C0035FD6C0C0BCD2E1FFBF5255 +S315E6303680010000B9E2FF9F52012080D2C1C0BCF2F0 +S315E6303690220000B90120BC52010000B90220BC125A +S315E63036A0812080D2C1C0BCF2220000B9E17F8F1200 +S315E63036B0010000B9E17F8F5200200491010000B984 +S315E63036C0C0035FD6C0C0BCD201E09F12010000B98C +S315E63036D002E09F52012080D2C1C0BCF2220000B97E +S315E63036E001E0815201FEBC72010000B9E21F9E5232 +S315E63036F0E201A372812080D2C1C0BCF2220000B9B9 +S315E6303700E1778F12010000B9E1778F5200200491FC +S315E6303710010000B9C0035FD6FD7BBFA9FD0300916A +S315E6303720E9FFFF97C0C0BCD2E1E78712010000B9D6 +S315E6303730E2E78752812180D2C1C0BCF2220000B9CD +S315E630374001008C52C1FFBF72010000B9E2FF93520D +S315E63037502200A072012280D2C1C0BCF2220000B99A +S315E6303760C141805241FABF72010000B922BE9F5272 +S315E6303770A205A072812280D2C1C0BCF2220000B975 +S315E6303780011E9F522104B872010000B9E2E180526F +S315E6303790C2FBA772012380D2C1C0BCF2220000B9B7 +S315E63037A0E1018012010000B9E10180520070049116 +S315E63037B0010000B9FD7BC1A8C0035FD6FD7BBFA97A +S315E63037C0FD03009132FEFF9768FFFF97D3FFFF9721 +S315E63037D03CFEFF9750FEFF97BAFEFF97EAFEFF974D +S315E63037E0FD7BC1A8C0035FD6000480D2A0C0BCF280 +S315E63037F01F0000B9000440911F0000B90004409153 +S315E63038001F0000B9000440911F0000B90004409142 +S315E63038101F0000B9000440911F0000B90000109166 +S315E63038201F0000B9C0035FD6A0C0BCD21F0000B9E6 +S315E6303830000440911F0000B9000440911F0000B912 +S315E6303840000440911F0000B9000440911F0000B902 +S315E6303850000440911F0000B9000010911F0000B926 +S315E6303860C0035FD6000182D2A0C0BCF21F0000B909 +S315E63038700180805200044091010000B9800200B018 +S315E63038800050433900101D121F200071C10000544C +S315E630389001009052000186D2A0C0BCF2010000B908 +S315E63038A00500001401009852000186D2A0C0BCF291 +S315E63038B0010000B9C100805200018AD2A0C0BCF234 +S315E63038C0010000B90110875200001091010000B9DD +S315E63038D0C0035FD6800080D2A0C0BCF21F0000B91C +S315E63038E0014081520120A07200044091010000B9E6 +S315E63038F00180805200044091010000B901009852DF +S315E630390000044091010000B9000440911F0000B95F +S315E6303910C141805200044091010000B9011087523E +S315E63039202100A07200001091010000B9C0035FD6F5 +S315E6303930FD7BBFA9FD030091ACFFFF97BBFFFF9769 +S315E6303940C9FFFF97E4FFFF97FD7BC1A8C0035FD6AB +S315E6303950C0C0BCD201008012010000B902A080D2FC +S315E6303960C2C0BCF25F0000B9010000B94210009156 +S315E63039705F0000B9010000B9002014911F0000B9BC +S315E6303980C0035FD601F89F52E100B872C0C0BCD220 +S315E6303990010000B9E107805201FFA77200000E91DF +S315E63039A0010000B9C0035FD6C0C0BCD2E1E702323F +S315E63039B0010000B9E2E70032016080D2C1C0BCF254 +S315E63039C0220000B9019999528199B972010000B97C +S315E63039D042100011816080D2C1C0BCF2220000B92B +S315E63039E0E2E30132020000B9E1EB0032036180D254 +S315E63039F0C3C0BCF2610000B9020000B963100091A1 +S315E6303A00610000B9020000B963100091610000B9A7 +S315E6303A10020000B963100091610000B9020000B9F6 +S315E6303A2063100091610000B9020000B9631000919D +S315E6303A30610000B9020000B963100091610000B977 +S315E6303A40020000B963100091610000B9020000B9C6 +S315E6303A5063100091610000B9831991520311B17276 +S315E6303A60030000B964E68E52E4EEAE72836580D228 +S315E6303A70C3C0BCF2640000B9E3F99F52E399B97268 +S315E6303A80030000B9040680520466A672036680D245 +S315E6303A90C3C0BCF2640000B9031191520391B97206 +S315E6303AA0030000B9E4EE8E52E46EA672836680D2E7 +S315E6303AB0C3C0BCF2640000B9020000B963100091DD +S315E6303AC0610000B9020000B963100091610000B9E7 +S315E6303AD0020000B963100091610000B9020000B936 +S315E6303AE063100091610000B9020000B963100091DD +S315E6303AF0610000B9020000B963100091610000B9B7 +S315E6303B00020000B963100091610000B9020000B905 +S315E6303B1063100091610000B9020000B963100091AC +S315E6303B20610000B9020000B9826B80D2C2C0BCF235 +S315E6303B30410000B9E11191520111B172010000B9AB +S315E6303B4001EE8E52E1EEAE7200800D91010000B9C3 +S315E6303B50C0035FD6C0C0BCD2E1F78B12010000B914 +S315E6303B60E2F78B52018880D2C1C0BCF2220000B99E +S315E6303B7021009E52E1FBBF72010000B9C2FF8152BD +S315E6303B800204A072818880D2C1C0BCF2220000B99C +S315E6303B9021C39F52E19FB972010000B9C23C8052FF +S315E6303BA00260A672018980D2C1C0BCF2220000B999 +S315E6303BB0015C8012010000B9025C8052818980D2B4 +S315E6303BC0C1C0BCF2220000B9E11F8052010000B943 +S315E6303BD0E21F8012018A80D2C1C0BCF2220000B94F +S315E6303BE0010F80520114B072010000B9E2F09F5223 +S315E6303BF0E2EBAF72818A80D2C1C0BCF2220000B954 +S315E6303C00A10A8012010000B9A10A80520060119122 +S315E6303C10010000B9C0035FD6C0C0BCD2E1FF811255 +S315E6303C20010000B9E2FF8152018080D2C1C0BCF208 +S315E6303C30220000B961B99F52E1FDBF72010000B9B9 +S315E6303C40824680520202A072818080D2C1C0BCF226 +S315E6303C50220000B981988012010000B9829880521C +S315E6303C60018180D2C1C0BCF2220000B90140801287 +S315E6303C70010000B902408052818180D2C1C0BCF2D7 +S315E6303C80220000B901C0A712010000B902C0A7524E +S315E6303C90018280D2C1C0BCF2220000B941FF9E52F9 +S315E6303CA0E11FBC72010000B9A200815202E0A372A4 +S315E6303CB0818280D2C1C0BCF2220000B9C100801236 +S315E6303CC0010000B9C100805200601091010000B9D0 +S315E6303CD0C0035FD6C0C0BCD2E1BB9B52A1BBBF72AC +S315E6303CE0010000B9024484524244A072814080D237 +S315E6303CF0C1C0BCF2220000B901008012010000B951 +S315E6303D00024180D2C2C0BCF25F0000B9010000B900 +S315E6303D10421000915F0000B9010000B942100091EF +S315E6303D205F0000B9010000B9421000915F0000B9AA +S315E6303D30010000B9421000915F0000B9010000B9F8 +S315E6303D40007008911F0000B9C0035FD6C0C0BCD270 +S315E6303D5081999952E1FFB372010000B962668652E3 +S315E6303D600200AC72814080D2C1C0BCF2220000B9FA +S315E6303D70213393522133BF72010000B9C2CC8C5243 +S315E6303D80C2CCA072014180D2C1C0BCF2220000B9D9 +S315E6303D90E4FF93522433B372040000B903008C5225 +S315E6303DA0C3CCAC7221100091230000B9C2CC80128C +S315E6303DB0020000B9C1CC8052054280D2C5C0BCF201 +S315E6303DC0A10000B905C08012050000B906C08052D0 +S315E6303DD0854280D2C5C0BCF2A60000B9040000B95F +S315E6303DE0044380D2C4C0BCF2830000B9020000B9F5 +S315E6303DF000700891010000B9C0035FD6FD7BBEA90D +S315E6303E00FD030091F35301A9D3C0BCD2140080124E +S315E6303E10740200B9004080D2C0C0BCF21F0000B9BF +S315E6303E20CBFFFF972022A212600200B92122A252CE +S315E6303E30004480D2C0C0BCF2010000B9740200B9B9 +S315E6303E40001000911F0000B9800200B001DC40B9D5 +S315E6303E5000E089523F00006BC1060054800200B094 +S315E6303E6000D040B91F3C007148060054E00313AA5F +S315E6303E70C1FD9F52E17FBF72610200B922028052D4 +S315E6303E800280A072014580D2C1C0BCF2220000B9E0 +S315E6303E9001808012610200B902808052814580D26B +S315E6303EA0C1C0BCF2220000B9E19F9F52E1FFAF727A +S315E6303EB0610200B9026080520200B072014680D2D9 +S315E6303EC0C1C0BCF2220000B901078012610200B916 +S315E6303ED002078052814680D2C1C0BCF2220000B9C8 +S315E6303EE0140000B9024780D2C2C0BCF25F0000B906 +S315E6303EF022028012620200B923028052824780D2C1 +S315E6303F00C2C0BCF2430000B902028012620200B9B6 +S315E6303F1003028052024880D2C2C0BCF2430000B9E6 +S315E6303F20140000B9601209911F0000B93800001478 +S315E6303F30C0C0BCD20100A212010000B90200A252F2 +S315E6303F40014580D2C1C0BCF2220000B9C1FF9F5202 +S315E6303F50E17FBF72010000B9220080520280A07272 +S315E6303F60814580D2C1C0BCF2220000B90180801200 +S315E6303F70010000B902808052014680D2C1C0BCF24F +S315E6303F80220000B9E19F9F52E1FFAF72010000B90E +S315E6303F90026080520200B072814680D2C1C0BCF265 +S315E6303FA0220000B901078012010000B902078052EB +S315E6303FB0014780D2C1C0BCF2220000B901008012AE +S315E6303FC0010000B9824780D2C2C0BCF25F0000B9B8 +S315E6303FD022028012020000B923028052024880D2C1 +S315E6303FE0C2C0BCF2430000B902028012020000B938 +S315E6303FF003028052824880D2C2C0BCF2430000B986 +S315E6304000010000B9002009911F0000B9F35341A918 +S315E6304010FD7BC2A8C0035FD6E1FFBF52C0C0BCD2AB +S315E6304020010000B9E1FF9F5200000491010000B99A +S315E63040308002009001DC40B900E089523F00006B17 +S315E6304040810100548002009000D040B91F3C0071D7 +S315E6304050080100540120BE52C0C0BCD2010000B9EE +S315E63040600120BE1200100491010000B907000014C9 +S315E63040700120BC52C0C0BCD2010000B90120BC123E +S315E630408000100491010000B9E17F8F12C0C0BCD2A6 +S315E6304090010000B9E17F8F5200200491010000B99A +S315E63040A0C0035FD601E09F12C0C0BCD2010000B9A2 +S315E63040B001E09F5200000491010000B980020090B1 +S315E63040C001DC40B900E089523F00006BC101005483 +S315E63040D08002009000D040B91F3C00714801005480 +S315E63040E001E0815201FEBE72C0C0BCD2010000B909 +S315E63040F0E11F9E52E101A17200100491010000B960 +S315E63041000900001401E0815201FEBC72C0C0BCD287 +S315E6304110010000B9E11F9E52E101A372001004913D +S315E6304120010000B9E1778F12C0C0BCD2010000B9F8 +S315E6304130E1778F5200200491010000B9C0035FD6C3 +S315E6304140FD7BBFA9FD030091D7FFFF97C0C0BCD268 +S315E6304150E1E78712010000B9E2E78752812180D292 +S315E6304160C1C0BCF2220000B901008C52C1FFBF7259 +S315E6304170010000B9E2FF93522200A072012280D2FA +S315E6304180C1C0BCF2220000B9C141805241FABF72C9 +S315E6304190010000B922BE9F52A205A072812280D2CA +S315E63041A0C1C0BCF2220000B9011E87522104B872A2 +S315E63041B0010000B9E2E19852C2FBA772012380D230 +S315E63041C0C1C0BCF2220000B9E1018012010000B99B +S315E63041D0E101805200700491010000B9FD7BC1A86F +S315E63041E0C0035FD6FD7BBFA9FD030091D9FDFF97DE +S315E63041F003FFFF97D3FFFF97E3FDFF97EBFDFF97AF +S315E630420055FEFF9785FEFF97FD7BC1A8C0035FD6B7 +S315E6304210000480D2A0C0BCF21F0000B90004409171 +S315E63042201F0000B9000440911F0000B90004409118 +S315E63042301F0000B9000440911F0000B90004409108 +S315E63042401F0000B9000010911F0000B9C0035FD609 +S315E6304250A0C0BCD21F0000B9000440911F0000B9CF +S315E6304260000440911F0000B9000440911F0000B9D8 +S315E6304270000440911F0000B9000440911F0000B9C8 +S315E6304280000010911F0000B9C0035FD6000182D24C +S315E6304290A0C0BCF21F0000B90180805200044091F4 +S315E63042A0010000B90100985200044091010000B9BE +S315E63042B0C100805200084091010000B901108752D2 +S315E63042C000001091010000B9C0035FD6800080D2AD +S315E63042D0A0C0BCF21F0000B9014081520120A07295 +S315E63042E000044091010000B90180805200044091FB +S315E63042F0010000B90100985200044091010000B96E +S315E6304300000440911F0000B9C1418052000440913B +S315E6304310010000B9011087522100A0720000109109 +S315E6304320010000B9C0035FD6FD7BBFA9FD0300914E +S315E6304330B8FFFF97C7FFFF97D5FFFF97E4FFFF97D5 +S315E6304340FD7BC1A8C0035FD600048052014080D20F +S315E630435041C4BDF2200000B921100091200000B919 +S315E6304360C0035FD6006486520042A572014680D20B +S315E630437041C4BDF2200000B921100091200000B9F9 +S315E6304380C0035FD6005080D240C4BDF21F0000B9EC +S315E6304390001000911F0000B9C0035FD6005480D2EA +S315E63043A040C4BDF21F0000B9008000911F0000B97D +S315E63043B0C0035FD6FD7BBFA9FD030091E3FFFF9700 +S315E63043C0E9FFFF97F0FFFF97F5FFFF97FD7BC1A863 +S315E63043D0C0035FD681808012C0C0BCD2010000B96E +S315E63043E08180805200001491010000B9C0035FD687 +S315E63043F0C0C0BCD21F0000B901008012027080D264 +S315E6304400C2C0BCF2410000B91F0000B942100091AB +S315E6304410410000B9010000B9421000915F0000B9D1 +S315E6304420010000B900000F911F0000B9C0035FD646 +S315E6304430C0C0BCD201FEAF52010000B902FEAF12D7 +S315E6304440018880D2C1C0BCF2220000B9014C81524B +S315E6304450010000B9024C8112818880D2C1C0BCF21B +S315E6304460220000B9C1FC9F52E1BFB172010000B92A +S315E6304470220380520240AE72018980D2C1C0BCF2BC +S315E6304480220000B9E1770F32010000B9E1071132B7 +S315E630449000301191010000B9C0035FD6C0C0BCD26E +S315E63044A001FEAF52010000B902FEAF12018080D2A2 +S315E63044B0C1C0BCF2220000B9014C8152010000B9FC +S315E63044C0024C8112818080D2C1C0BCF2220000B992 +S315E63044D0C1FC9F52E1BFB172010000B9220380529E +S315E63044E00240AE72018180D2C1C0BCF2220000B970 +S315E63044F0E1770F32010000B9E10711320030109151 +S315E6304500010000B9C0035FD6C0C0BCD2E2E70232D2 +S315E6304510020000B9E1E70032034080D2C3C0BCF204 +S315E6304520610000B9020000B963100091610000B97C +S315E63045308399995283F9BF72030000B9646686524D +S315E63045406406A072034180D2C3C0BCF2640000B9EF +S315E63045500344A012030000B90444A052834180D23A +S315E6304560C3C0BCF2640000B9E3FF99528399B972CD +S315E6304570030000B9040086526466A672034280D20E +S315E6304580C3C0BCF2640000B9020000B96310009102 +S315E6304590610000B9020000B9024380D2C2C0BCF263 +S315E63045A0410000B981FF99528177BF72010000B9A7 +S315E63045B0620086526288A072814380D2C1C0BCF264 +S315E63045C0220000B98100A012010000B98100A05294 +S315E63045D000800891010000B9C0035FD6C0C0BCD2E6 +S315E63045E001008012010000B9024080D2C2C0BCF29E +S315E63045F05F0000B9010000B9421000915F0000B9D2 +S315E6304600010000B9421000915F0000B90244A012E1 +S315E6304610020000B90344A052824180D2C2C0BCF245 +S315E6304620430000B9010000B9421000915F0000B9BD +S315E6304630010000B9421000915F0000B9010000B9EF +S315E6304640014380D2C1C0BCF23F0000B90188A01256 +S315E6304650010000B90288A052814380D2C1C0BCF2C3 +S315E6304660220000B98100A012010000B98100A052F3 +S315E630467000800891010000B9C0035FD6FD7BBFA973 +S315E6304680FD030091D6FFFF97FD7BC1A8C0035FD639 +S315E6304690C0C0BCD201F8BF52010000B902F8BF1261 +S315E63046A0012080D2C1C0BCF2220000B9213FBE5201 +S315E63046B0010000B9223FBE12812080D2C1C0BCF2D1 +S315E63046C0220000B9E1E78152C1FFBF72010000B9AD +S315E63046D002189E522200A072012180D2C1C0BCF2DD +S315E63046E0220000B9C1FFBF52010000B9C2FFBF12B6 +S315E63046F0812180D2C1C0BCF2220000B9E107801226 +S315E6304700010000B9E2078052012280D2C1C0BCF274 +S315E6304710220000B9E1FF8112010000B9E1FF8152C2 +S315E630472000500491010000B9C0035FD6C0C0BCD2C8 +S315E630473001008012010000B9022080D2C2C0BCF26C +S315E63047405F0000B9223FBE52020000B9233FBE12D7 +S315E6304750822080D2C2C0BCF2430000B90218801271 +S315E6304760020000B903188052022180D2C2C0BCF2E0 +S315E6304770430000B9010000B9812180D2C1C0BCF244 +S315E63047803F0000B961068012010000B96206805228 +S315E6304790012280D2C1C0BCF2220000B9E1FF81120B +S315E63047A0010000B9E1FF815200500491010000B9E1 +S315E63047B0C0035FD6FD7BBFA9FD030091DCFFFF9703 +S315E63047C0FD7BC1A8C0035FD6FD7BBFA9FD03009183 +S315E63047D001FFFF97AAFFFF97F7FFFF9705FFFF97C2 +S315E63047E014FFFF972EFFFF97FD7BC1A8C0035FD668 +S315E63047F0000480D2A0C0BCF21F0000B9000440918C +S315E63048001F0000B9000440911F0000B90004409132 +S315E63048101F0000B9000440911F0000B90004409122 +S315E63048201F0000B9C0035FD6A0C0BCD21F0000B9D6 +S315E6304830000440911F0000B9000440911F0000B902 +S315E6304840000440911F0000B9000440911F0000B9F2 +S315E6304850000440911F0000B9C0035FD62100A05284 +S315E6304860000182D2A0C0BCF2010000B901008E522E +S315E630487000104091010000B9C0035FD6800080D2B7 +S315E6304880A0C0BCF21F0000B92100A052000440913E +S315E6304890010000B9000440911F0000B900044091C0 +S315E63048A01F0000B9000440911F0000B901008E5286 +S315E63048B000044091010000B9C0035FD6FD7BBFA975 +S315E63048C0FD030091CBFFFF97D8FFFF97E4FFFF97F5 +S315E63048D0EBFFFF97FD7BC1A8C0035FD6C0C0BCD255 +S315E63048E0E1FF9B52E1EBB772010000B90200845258 +S315E63048F00214A87201A080D2C1C0BCF2220000B96F +S315E630490001008012010000B9001014911F0000B9B1 +S315E6304910C0035FD6C0C0BCD201FEA752010000B9C3 +S315E630492002FEA712017080D2C1C0BCF2220000B9E5 +S315E630493021008052010000B922008012017180D236 +S315E6304940C1C0BCF2220000B901008012010000B9F4 +S315E630495000000F911F0000B9C0035FD6C0C0BCD2BD +S315E6304960E1FF875281F7BF72010000B90200985223 +S315E63049706208A072018880D2C1C0BCF2220000B9BA +S315E6304980E17F8012010000B9E27F8052818880D2D1 +S315E6304990C1C0BCF2220000B9E1FF8B52010000B97A +S315E63049A0E2FF8B12018980D2C1C0BCF2220000B987 +S315E63049B0214E805201BEB872010000B9C2B19F5293 +S315E63049C0E241A772818980D2C1C0BCF2220000B929 +S315E63049D001008012010000B9028A80D2C2C0BCF260 +S315E63049E05F0000B9010000B9005011911F0000B90F +S315E63049F0C0035FD6C0C0BCD2E1FF875281F7BF7233 +S315E6304A00010000B9020098526208A072018080D295 +S315E6304A10C1C0BCF2220000B9E17F8012010000B9C4 +S315E6304A20E27F8052818080D2C1C0BCF2220000B9DA +S315E6304A30E1FF8B52010000B9E2FF8B12018180D291 +S315E6304A40C1C0BCF2220000B9214E805201BEB87216 +S315E6304A50010000B9C2B19F52E241A772818180D28C +S315E6304A60C1C0BCF2220000B901008012010000B9D3 +S315E6304A70028280D2C2C0BCF25F0000B9010000B942 +S315E6304A80005010911F0000B9C0035FD6C0035FD651 +S315E6304A90C0C0BCD221008012010000B9220080528B +S315E6304AA0014080D2C1C0BCF2220000B901008012BA +S315E6304AB0010000B9824080D2C2C0BCF25F0000B9C4 +S315E6304AC0010000B9421000915F0000B9010000B95B +S315E6304AD0421000915F0000B902008412020000B96C +S315E6304AE003008452024280D2C2C0BCF2430000B90F +S315E6304AF0010000B9421000915F0000B9010000B92B +S315E6304B00421000915F0000B9010000B942100091F1 +S315E6304B105F0000B9C29F9952E2DFBD72020000B96A +S315E6304B20236086520320A272024480D2C2C0BCF20F +S315E6304B30430000B9E2EB0332020000B9E3E30032A8 +S315E6304B40824480D2C2C0BCF2430000B94200A01211 +S315E6304B50020000B94300A052024580D2C2C0BCF280 +S315E6304B60430000B90200A812020000B90300A852B9 +S315E6304B70824580D2C2C0BCF2430000B9010000B91A +S315E6304B80421000915F0000B9010000B900D00891EB +S315E6304B901F0000B9C0035FD6FD7BBFA9FD030091B8 +S315E6304BA0BCFFFF97FD7BC1A8C0035FD6C0035FD6C7 +S315E6304BB0C0C0BCD2E13B8012010000B9E23B805274 +S315E6304BC0012080D2C1C0BCF2220000B90100BC523D +S315E6304BD0010000B90200BC12812080D2C1C0BCF20D +S315E6304BE0220000B90100B052010000B90200B0124D +S315E6304BF0012180D2C1C0BCF2220000B9E17F801229 +S315E6304C00010000B9E27F8052812180D2C1C0BCF278 +S315E6304C10220000B921109E52E177A072010000B958 +S315E6304C20C2EF81520288BF72012280D2C1C0BCF285 +S315E6304C30220000B9E100805281FCBF72010000B962 +S315E6304C4002FF9F526203A072812280D2C1C0BCF2BB +S315E6304C50220000B9E1FF8712010000B9E1FF875271 +S315E6304C6000600491010000B9C0035FD6FD7BBFA9A1 +S315E6304C70FD030091CFFFFF97FD7BC1A8C0035FD64A +S315E6304C80FD7BBFA9FD03009115FFFF97C3FFFF9795 +S315E6304C90F7FFFF9720FFFF9731FFFF9756FFFF9706 +S315E6304CA0FD7BC1A8C0035FD6000480D2A0C0BCF2AB +S315E6304CB01F0000B9000440911F0000B9000440917E +S315E6304CC01F0000B9000440911F0000B9000440916E +S315E6304CD01F0000B9000440911F0000B90000109192 +S315E6304CE01F0000B9C0035FD6A0C0BCD21F0000B912 +S315E6304CF0000440911F0000B9000440911F0000B93E +S315E6304D00000440911F0000B9000440911F0000B92D +S315E6304D10000440911F0000B9000010911F0000B951 +S315E6304D20C0035FD6000180D2A0C0BCF21F0000B936 +S315E6304D300100A85200044091010000B900044091F8 +S315E6304D401F0000B9000440911F0000B901108052DF +S315E6304D500140A07200044091010000B90004409180 +S315E6304D601F0000B9000010911F0000B9C0035FD6DE +S315E6304D7001048052800080D2A0C0BCF2010000B9A6 +S315E6304D800100A85200044091010000B90100B0527A +S315E6304D9000044091010000B9000440911F0000B9BB +S315E6304DA0211080520140A07200044091010000B902 +S315E6304DB08100A05200044091010000B90000109134 +S315E6304DC01F0000B9C0035FD6FD7BBFA9FD03009186 +S315E6304DD0B6FFFF97C5FFFF97D3FFFF97E5FFFF9730 +S315E6304DE0FD7BC1A8C0035FD6FD7BBFA9FD0300915D +S315E6304DF0800200900050433900101D121F6000718A +S315E6304E006100005462000094060000141FE0007151 +S315E6304E10610000540B01009402000014E100009496 +S315E6304E20FD7BC1A8C0035FD6001C0053010280D2C9 +S315E6304E30C1DCBCF2210040793F041B7280FFFF548F +S315E6304E40810180D2C1DCBCF220000039211000910C +S315E6304E5020004079003C005300741912003C0053A0 +S315E6304E602000007900008052C0035FD6F37BBFA9ED +S315E6304E70F30300AA000280D2C0DCBCF2000040791F +S315E6304E80211280523F00006A00010054020280D2AD +S315E6304E90C2DCBCF240004079013C0053201280125D +S315E6304EA02000000A40000079800480D2C0DCBCF2E3 +S315E6304EB0000040794001003621008052000100F0C2 +S315E6304EC000002291D3010094810480D2C1DCBCF289 +S315E6304ED02000407900381F1220000079000280D287 +S315E6304EE0C0DCBCF20000407960FC0F36800280D22E +S315E6304EF0C0DCBCF20000403960020039010280D2E3 +S315E6304F00C1DCBCF220004079003C005300781E122A +S315E6304F10003C00532000007900008052F37BC1A8A4 +S315E6304F20C0035FD6000880D2A0C2BCF2000040B90A +S315E6304F30A001383600781812E203202A012081D201 +S315E6304F40A1C2BCF2220000B9012780D2A1C2BCF2CE +S315E6304F50200000B9000880D2A0C2BCF2000040B9F9 +S315E6304F60A0FF3F37C0035FD621008052060000140B +S315E6304F70000280D2C0DCBCF2000040794000303618 +S315E6304F800100805261FFFF35C0035FD6F353BEA9F9 +S315E6304F90FE0B00F9E4FFFF97800480D2C0DCBCF25A +S315E6304FA0010040791F000079000280D2C0DCBCF2F5 +S315E6304FB01F000079130180D2D3DCBCF27F02007980 +S315E6304FC0140380D2D4DCBCF2C00080528002007971 +S315E6304FD04000805260020079C0DCBCD21F00007906 +S315E6304FE0800C80524403009401018052000680D240 +S315E6304FF0C0DCBCF201000079001000911F00007998 +S315E6305000800C80523C0300949F0200794006805221 +S315E630501060020079800C805237030094FE0B40F92B +S315E6305020F353C2A8C0035FD6003C0053010680D2D4 +S315E6305030C1DCBCF220000079C0035FD6001C005309 +S315E6305040010290D201DDBCF2210040793F041B72A9 +S315E630505080FFFF54810190D201DDBCF22000003999 +S315E63050602110009120004079003C0053007419125B +S315E6305070003C00532000007900008052C0035FD622 +S315E6305080F37BBFA9F30300AA000290D200DDBCF29F +S315E630509000004079211280523F00006A0001005438 +S315E63050A0020290D202DDBCF240004079013C005368 +S315E63050B0201280122000000A40000079800490D247 +S315E63050C000DDBCF200004079400100362100805216 +S315E63050D0000100D0000022914E010094810490D266 +S315E63050E001DDBCF22000407900381F12200000793D +S315E63050F0000290D200DDBCF20000407960FC0F364B +S315E6305100800290D200DDBCF2000040396002003900 +S315E6305110010290D201DDBCF220004079003C00531A +S315E630512000781E12003C00532000007900008052C1 +S315E6305130F37BC1A8C0035FD6000980D2A0C2BCF219 +S315E6305140000040B9A001503600781512E203202A55 +S315E6305150012081D2A1C2BCF2220000B9812780D2D9 +S315E6305160A1C2BCF2200000B9000980D2A0C2BCF2CE +S315E6305170000040B9A0FF5737C0035FD62100805202 +S315E630518006000014000290D200DDBCF20000407941 +S315E6305190400030360100805261FFFF35C0035FD6EE +S315E63051A0F353BEA9FE0B00F9E4FFFF97800490D2D5 +S315E63051B000DDBCF2010040791F000079000290D292 +S315E63051C000DDBCF21F000079130190D213DDBCF28C +S315E63051D07F020079140390D214DDBCF2C00080520F +S315E63051E0800200794000805260020079000090D259 +S315E63051F000DDBCF21F000079800C8052BE020094BE +S315E630520001018052000690D200DDBCF20100007941 +S315E6305210001000911F000079800C8052B60200948F +S315E63052209F0200794006805260020079800C8052F7 +S315E6305230B1020094FE0B40F9F353C2A8C0035FD621 +S315E6305240F37BBFA9BDFFFF97000C80D2C0C2BCF28C +S315E6305250130040B973324CD3800490D200DDBCF2F1 +S315E6305260010040791F000079000290D200DDBCF2E1 +S315E63052701F000079000190D200DDBCF21F000079F4 +S315E6305280C2008052010390D201DDBCF222000079E1 +S315E63052904100805201000079000090D200DDBCF278 +S315E63052A01F000079800C805293020094D3000035BB +S315E63052B021128052000690D200DDBCF20100007960 +S315E63052C006000014B300003401118052000690D275 +S315E63052D000DDBCF20100007901008852800690D2EA +S315E63052E000DDBCF201000079800C80528202009427 +S315E63052F0000390D200DDBCF21F00007941068052F1 +S315E6305300000190D200DDBCF201000079800C8052BB +S315E630531079020094F37BC1A8C0035FD6003C005304 +S315E6305320010690D201DDBCF220000079C0035FD6DB +S315E6305330F37BBFA9131C0053000090D200DDBCF20C +S315E63053401F000079800C80526B020094800090D268 +S315E630535000DDBCF213000039F37BC1A8C0035FD68B +S315E6305360FE0F1FF8001C0053610200F0215043394E +S315E630537021101D123F60007161000054ABFEFF97AD +S315E6305380020000142EFFFF9700008052FE0741F818 +S315E6305390C0035FD6FE0F1FF8610200F02150433995 +S315E63053A021101D123F60007161000054B0FEFF9778 +S315E63053B00200001433FFFF9700008052FE0741F8E3 +S315E63053C0C0035FD6FE0F1FF8600200F00050433987 +S315E63053D000101D121F60007161000054E3FEFF9756 +S315E63053E00200001466FFFF97FE0741F8C0035FD65A +S315E63053F0FD7BBFA9FD03009132040094FD7BC1A875 +S315E6305400C0035FD6FD7BBFA9FD0300912100805224 +S315E6305410000100D0002022917E000094C00000D02A +S315E630542000E019919D000094C00000D000A01991CB +S315E63054308C000094C00000D0006019918900009479 +S315E6305440FD7BC1A8C0035FD6FD7BBFA9FD030091F6 +S315E630545001008052000100D0004022916D00009498 +S315E6305460600200F000E040B980000034200080524F +S315E630547072F5FF9703000014200080520DF5FF9772 +S315E630548037F4FF9721008052000100D000202291A8 +S315E630549060000094FD7BC1A8C0035FD6610200F0D0 +S315E63054A03FEC00B912000014240040395F00046B6B +S315E63054B001010054630400912104009102000014B6 +S315E63054C0E30300AA6200403902FFFF35020000140A +S315E63054D0220080526200003521004039E101003475 +S315E63054E0A5040011610200F025EC00B9610200F076 +S315E63054F025EC40B9A17C409322E87BD3410C01CB25 +S315E6305500C20000D042800391416861F8A1FDFFB543 +S315E6305510200080D2C0035FD6000080D2C0035FD6BB +S315E6305520FD7BBAA9FD03009101008052000100D04F +S315E630553000A0229137000094A17F0091600200F02E +S315E630554000C0039163000094A07F403960000034C8 +S315E6305550610200F03FE800B9C0000035600200F0B5 +S315E630556000E840B91F04007141000054100400946D +S315E6305570A28301915FEC1B3803008052A183009130 +S315E6305580600200F000C00391B8010094A07B403978 +S315E63055901F040071A0FCFF54A0830091040100941F +S315E63055A0A0830091BEFFFF97600100B5600200F070 +S315E63055B000EC80B901E87BD3200C00CBC10000D0EB +S315E63055C0218003912000008B000440F900003FD68D +S315E63055D0D6FFFF1721008052000100D000C022918D +S315E63055E00C000094D1FFFF17FD7BBFA9FD030091A8 +S315E63055F080FFFF9784FFFF97200080523FF5FF97A5 +S315E630560020008052063B009490FFFF97C5FFFF9738 +S315E6305610FD7BBEA9FD030091F35301A9F30300AA6E +S315E6305620341C0053030000144EFFFF9773060091B7 +S315E630563060024039A0FFFF359F060071A100005495 +S315E6305640A001805247FFFF974001805245FFFF9702 +S315E630565000008052F35341A9FD7BC2A8C0035FD652 +S315E6305660FD7BBEA9FD030091F35301A9F40300AA1D +S315E6305670130080520400001421008052E5FFFF97A4 +S315E63056807306001180DA73F880FFFFB5F35341A94C +S315E6305690FD7BC2A8C0035FD6FD7BBEA9FD030091A4 +S315E63056A0F35301A9F40300AA130080520400001450 +S315E63056B001008052D7FFFF977306001180DA73F840 +S315E63056C080FFFFB5F35341A9FD7BC2A8C0035FD681 +S315E63056D0FD7BBEA9FD030091F35301A9F30300AAAE +S315E63056E0F40301AA3F00003920008052030000147B +S315E63056F0E00313AA28FFFF971F040071A0FFFF54AB +S315E6305700600240391F340071200300541F200071B7 +S315E6305710800000541F28007180FEFF540E000014EE +S315E63057208002403920FEFF34000180520DFFFF979C +S315E6305730000480520BFFFF970001805209FFFF9766 +S315E6305740800240390004005180020039730600D1E8 +S315E6305750E6FFFF1703FFFF97730600918002403995 +S315E63057600004001180020039E0FFFF177F0200399E +S315E630577040018052FBFEFF97A0018052F9FEFF976B +S315E630578000008052F35341A9FD7BC2A8C0035FD621 +S315E6305790FD7BBDA9FD030091F35301A9F51300F98D +S315E63057A0F50300AAF40301AA3F000039F30300AA81 +S315E63057B02000805203000014E00313AAF6FEFF979A +S315E63057C01F040071A0FFFF54600240391F34007198 +S315E63057D0A00300541F200071800000541F2800717A +S315E63057E0800200540E000014800240392002003454 +S315E63057F000018052DBFEFF9700048052D9FEFF9708 +S315E630580000018052D7FEFF978002403900040051EE +S315E630581080020039730600D106000014D1FEFF97E8 +S315E63058207306009180024039000400118002003987 +S315E6305830A00240391FB80071600000541F7801712C +S315E630584081FBFF547F02003940018052C5FEFF9747 +S315E6305850A0018052C3FEFF9700008052F35341A960 +S315E6305860F51340F9FD7BC3A8C0035FD646018052E7 +S315E630587007008052080080521800001465701D53E8 +S315E6305880A304030B840400110300001424008052A1 +S315E6305890E303042ADF00046B28FFFF54040080523A +S315E63058A0050000140000034B84040011841C0053E9 +S315E63058B0270080527F00006B69FFFF54C700003433 +S315E63058C084C000112400003908050011081D005374 +S315E63058D021040091C6040051A6FDFF35A800003527 +S315E63058E0000680522014003808050011081D0053C2 +S315E63058F03F000039480000B900008052C0035FD649 +S315E6305900FD7BBEA9FD030091F35301A9F303002AFB +S315E630591014008052090000140001805291FEFF9770 +S315E63059200000805202000014000400111F8C017141 +S315E6305930CDFFFF54940600119F02136BEBFEFF5426 +S315E630594014008052090000140004805285FEFF9749 +S315E63059500000805202000014000400111F8C017111 +S315E6305960CDFFFF54940600119F02136BEBFEFF54F6 +S315E630597014008052090000140001805279FEFF9728 +S315E63059800000805202000014000400111F8C0171E1 +S315E6305990CDFFFF54940600119F02136BEBFEFF54C6 +S315E63059A0F35341A9FD7BC2A8C0035FD608000014B5 +S315E63059B022840151421C00535F6400716800005432 +S315E63059C02180005101000039000400910100403980 +S315E63059D001FFFF35C0035FD6FD7BBEA9FD0300910F +S315E63059E0F35301A9F30300AAF40301AA3F0000B971 +S315E63059F0EFFFFF97600240391F00017180030054C4 +S315E6305A00010080521700001402C00051421C0053B8 +S315E6305A105F240071C800005400C00051820240B9CC +S315E6305A200010022A800200B909000014020401516E +S315E6305A30421C00535F140071E801005400DC00514B +S315E6305A40820240B90010022A800200B9730600913C +S315E6305A5021040011211C00533F2000710801005437 +S315E6305A606002403920FDFF350600001460008052A2 +S315E6305A7004000014200080520200001420008052F8 +S315E6305A80F35341A9FD7BC2A8C0035FD6FD7BBEA911 +S315E6305A90FD030091F35301A9F30300AAF40301AA27 +S315E6305AA03F0000F9C2FFFF97600240391F000171DF +S315E6305AB0C0030054010080521900001402C00051A0 +S315E6305AC0421C00535F240071E800005400C00051C8 +S315E6305AD0007C4093820240F9001002AA800200F967 +S315E6305AE00A00001402040151421C00535F1400718F +S315E6305AF00802005400DC0051007C4093820240F9F3 +S315E6305B00001002AA800200F9730600912104001102 +S315E6305B10211C00533F4000710801005460024039B1 +S315E6305B20E0FCFF35060000146000805204000014E5 +S315E6305B30200080520200001420008052F35341A91F +S315E6305B40FD7BC2A8C0035FD6421C00535F080071D6 +S315E6305B50000100545F100071200100545F040071AB +S315E6305B6001010054001C085344008052050000141D +S315E6305B70003C105384008052020000140401805227 +S315E6305B80020080520D000014037C1C537F24007102 +S315E6305B908800005463C00011230000390300001466 +S315E6305BA063DC001123000039006C1C5342040011FB +S315E6305BB0421C0053210400919F00026B68FEFF549D +S315E6305BC03F00003900008052C0035FD6421C0053C6 +S315E6305BD0420400515F1C007128020054C30000B035 +S315E6305BE063603E9162486238630000106288228BB9 +S315E6305BF040001FD6001C48D34400805208000014EB +S315E6305C00003C50D38400805205000014007C60D3FB +S315E6305C1004018052020000140402805202008052CF +S315E6305C200D00001403FC7CD37F2400F18800005479 +S315E6305C3063C00011230000390300001463DC001151 +S315E6305C402300003900EC7CD342040011421C005399 +S315E6305C50210400919F00026B68FEFF543F00003935 +S315E6305C6000008052C0035FD6631C005344004039BF +S315E6305C700000048B06008052050080521B0000149B +S315E6305C8004004039C40100349F800071210200547B +S315E6305C90460200347F001F6BE8179F1A7F8000713B +S315E6305CA0E4179F1A0401042A840100343F000039C0 +S315E6305CB00704805225008052080000143F00003960 +S315E6305CC0000400910700805225008052030000143C +S315E6305CD024140038260080524400403984040011EA +S315E6305CE04400003900040091C5FCFF34E003072A7E +S315E6305CF0C0035FD6FF4300D1FF0F00B9040000149E +S315E6305D00E10F40B921040011E10F00B9E10F40B9C6 +S315E6305D103F00006B63FFFF54FF430091C0035FD63D +S315E6305D20FD7BBDA9FD030091F30B00F933008052EC +S315E6305D300B000014A0BF009197FDFF97A1BF403935 +S315E6305D403FE40171E2179F1A3F640171E0179F1A2B +S315E6305D504000002A4000003413008052D3FEFF355F +S315E6305D60F30B40F9FD7BC3A8C0035FD6FD7BBEA926 +S315E6305D70FD030091A07F009187FDFF97A07F403914 +S315E6305D801FE40171E2179F1A1F640171E1179F1A2A +S315E6305D904100012A210100351FB80171E1179F1A2A +S315E6305DA01F380171E0179F1A2000002A40FEFF34A3 +S315E6305DB0200080520200001400008052FD7BC2A80B +S315E6305DC0C0035FD6030080D20400001424144038A2 +S315E6305DD004140038630400917F0002EB83FFFF541E +S315E6305DE0C0035FD6FD7BBFA9FD030091010080525B +S315E6305DF0000100D00020239106FEFF97C9FFFF97EA +S315E6305E00A0098052BFFEFF97FD7BC1A8C0035FD6CF +S315E6305E10FD7BBFA9FD03009101008052000100D051 +S315E6305E2000602491FBFDFF97BEFFFF97C0088052C6 +S315E6305E30B4FEFF97FD7BC1A8C0035FD6FD7BBFA945 +S315E6305E40FD03009101008052000100D000802591CB +S315E6305E50F0FDFF97B3FFFF9740088052A9FEFF9704 +S315E6305E60FD7BC1A8C0035FD6FD7BBFA9FD030091CC +S315E6305E7001008052000100D000A02691E5FDFF9793 +S315E6305E80A8FFFF97600580529EFEFF97010080527D +S315E6305E90000100D000602791DEFDFF97A1FFFF9756 +S315E6305EA06005805297FEFF9701008052000100D0D0 +S315E6305EB000202891D7FDFF979AFFFF97600580521D +S315E6305EC090FEFF97FD7BC1A8C0035FD6FD7BBFA9D9 +S315E6305ED0FD03009101008052000100D000A026911A +S315E6305EE0CCFDFF978FFFFF976005805285FEFF97C3 +S315E6305EF001008052000100D000602791C5FDFF9772 +S315E6305F0088FFFF97600580527EFEFF97010080523C +S315E6305F10000100D000E02891BEFDFF9781FFFF9794 +S315E6305F206005805277FEFF9701008052000100D06F +S315E6305F3000A02991B7FDFF977AFFFF97600580525B +S315E6305F4070FEFF97FD7BC1A8C0035FD6FD7BBFA978 +S315E6305F50FD03009101008052000100D000602A91D5 +S315E6305F60ACFDFF976FFFFF976005805265FEFF97A2 +S315E6305F7001008052000100D000202B91A5FDFF974D +S315E6305F8068FFFF97600580525EFEFF97FD7BC1A8EE +S315E6305F90C0035FD6FD7BBFA9FD03009101008052A9 +S315E6305FA0000100D000A026919AFDFF975DFFFF978E +S315E6305FB06005805253FEFF9701008052000100D003 +S315E6305FC00060279193FDFF9756FFFF976005805255 +S315E6305FD04CFEFF9701008052000100D000E02B9185 +S315E6305FE08CFDFF974FFFFF976005805245FEFF9782 +S315E6305FF001008052000100D00020289185FDFF97F0 +S315E630600048FFFF97600580523EFEFF97FD7BC1A8AD +S315E6306010C0035FD6FD7BBFA9FD0300910100805228 +S315E6306020000100B000A026917AFDFF973DFFFF976D +S315E63060306005805233FEFF9701008052000100B0C2 +S315E63060400060279173FDFF9736FFFF976005805214 +S315E63060502CFEFF9701008052000100B000E02B9144 +S315E63060606CFDFF972FFFFF976005805225FEFF9761 +S315E630607001008052000100B000E0289165FDFF97EF +S315E630608028FFFF97600580521EFEFF97010080527B +S315E6306090000100B000A029915EFDFF9721FFFF9732 +S315E63060A06005805217FEFF97FD7BC1A8C0035FD619 +S315E63060B0FD7BBFA9FD03009101008052000100B0CF +S315E63060C000602A9153FDFF9716FFFF9760058052D1 +S315E63060D00CFEFF9701008052000100B000202B91A4 +S315E63060E04CFDFF970FFFFF976005805205FEFF9741 +S315E63060F001008052000100B000A02C9145FDFF97CB +S315E630610008FFFF9760058052FEFDFF97FD7BC1A82D +S315E6306110C0035FD6FD7BBFA9FD0300910100805227 +S315E6306120000100B000602D913AFDFF97FDFEFF9726 +S315E630613040068052F3FDFF9701008052000100B021 +S315E630614000402E9133FDFF97F6FEFF9740068052CC +S315E6306150ECFDFF9701008052000100B000202F9140 +S315E63061602CFDFF97EFFEFF9740068052E5FDFF9741 +S315E6306170FD7BC1A8C0035FD6FD7BBFA9FD030091B9 +S315E630618001008052000100B000602D9121FDFF979D +S315E6306190E4FEFF9740068052DAFDFF970100805213 +S315E63061A0000100B000402E911AFDFF97DDFEFF9705 +S315E63061B040068052D3FDFF9701008052000100B0C1 +S315E63061C00000309113FDFF97D6FEFF9740068052CA +S315E63061D0CCFDFF97FD7BC1A8C0035FD6FD7BBFA98B +S315E63061E0FD03009101008052000100B000E03091DD +S315E63061F008FDFF97CBFEFF9740068052C1FDFF971D +S315E630620001008052000100B000C0319101FDFF97D8 +S315E6306210C4FEFF9740068052BAFDFF97FD7BC1A8C4 +S315E6306220C0035FD6FD7BBFA9FD0300910100805216 +S315E6306230000100B000A03291F6FCFF97B9FEFF9759 +S315E6306240E0048052AFFDFF9701008052000100B0B6 +S315E630625000403391EFFCFF97B2FEFF97E0048052A1 +S315E6306260A8FDFF9701008052000100B000E03391AF +S315E6306270E8FCFF97ABFEFF97E0048052A1FDFF975F +S315E6306280FD7BC1A8C0035FD6FD7BBFA9FD030091A8 +S315E630629001008052000100B000A03291DDFCFF978C +S315E63062A0A0FEFF97E004805296FDFF9701008052EC +S315E63062B0000100B000803491D6FCFF9799FEFF9737 +S315E63062C0E00480528FFDFF9701008052000100B056 +S315E63062D000E03391CFFCFF9792FEFF97E0048052C1 +S315E63062E088FDFF97FD7BC1A8C0035FD6FD7BBFA9BE +S315E63062F0FD03009101008052000100B00020359187 +S315E6306300C4FCFF9787FEFF97E00480527DFDFF973A +S315E630631001008052000100B000C03591BDFCFF9708 +S315E630632080FEFF97E004805276FDFF97FD7BC1A89D +S315E6306330C0035FD6FD7BBFA9FD0300910100805205 +S315E6306340000100B000603691B2FCFF9775FEFF970C +S315E6306350800880526BFDFF97FD7BC1A8C0035FD6F0 +S315E6306360FD7BBFA9FD03009101008052000100B01C +S315E630637000803791A7FCFF976AFEFF97400680526A +S315E630638060FDFF9701008052000100B00060389151 +S315E6306390A0FCFF9763FEFF974006805259FDFF97B4 +S315E63063A001008052000100B00040399199FCFF9718 +S315E63063B05CFEFF974006805252FDFF97FD7BC1A8F3 +S315E63063C0C0035FD6610200D02150433921101D1239 +S315E63063D03F60007160020054E80000543F200071CF +S315E63063E0800100543F40007180010054C1020035FF +S315E63063F0140000143FE00071C00100543F600171A3 +S315E6306400C00100543F800071E101005407000014DA +S315E630641020008052C0035FD640008052C0035FD66C +S315E630642060008052C0035FD680008052C0035FD6DC +S315E6306430A0008052C0035FD6C0008052C0035FD64C +S315E630644000008052C0035FD6FD7BBFA9FD030091F5 +S315E630645001008052000100B000203A916DFCFF97B2 +S315E630646030FEFF97A009805226FDFF97FD7BC1A837 +S315E6306470C0035FD6FD7BBFA9FD03009101008052C4 +S315E6306480000100B000603B9162FCFF9725FEFF9766 +S315E6306490800480521BFDFF97FD7BC1A8C0035FD603 +S315E63064A0FD7BBFA9FD03009121008052000100B0BB +S315E63064B000003C9157FCFF97FD7BC1A8C0035FD631 +S315E63064C0600200D0026007911FEC00F9600200D04E +S315E63064D0018005911FB000F9E01F80D2400400F933 +S315E63064E0200400F9610200D0222007913FC801B9A5 +S315E63064F0400400B921008052600200D0017801B92B +S315E6306500600200D01FE800B900148052610200D064 +S315E6306510203002B9610200D0202C02B9600200D0E8 +S315E630652001C004911F3001B900048052200400B93D +S315E6306530610200D0224005913F5001B9E107805211 +S315E6306540410400B9610200D0220005913F4001B90D +S315E6306550400400B900008052030000140004001124 +S315E6306560003C00131FCC0771ADFFFF54C0035FD666 +S315E6306570FD7BBAA9FD030091A28301915FFC1B382E +S315E630658003008052A1830091600200D000C00391DF +S315E6306590B6FDFF9780000035C00000B000E01491EC +S315E63065A030FCFF97FD7BC6A8C0035FD6FD7BBDA951 +S315E63065B0FD030091F30B00F921008052600200D012 +S315E63065C001E800B9600200D00180059100B040F9DB +S315E63065D0A01700F9200440F9A1C30091200C1FF85A +S315E63065E0A0A30091C6040094131C0053600200D0A9 +S315E63065F0007841B91F100071800100541F200071E8 +S315E6306600400200541F08007101030054A01740F9F8 +S315E6306610C002003621008052000100D0008002918F +S315E6306620FCFBFF972D000014A01740F900044092BA +S315E6306630C00100B421008052000100D000800291F2 +S315E6306640F4FBFF9725000014A01740F900084092A6 +S315E6306650C00000B421008052000100D000800291D3 +S315E6306660ECFBFF971D0000147F060071A100005475 +S315E630667021008052000100D000E00291E5FBFF9751 +S315E63066807F0A0071A100005421008052000100D03B +S315E630669000200391DFFBFF9713020035600200D03E +S315E63066A0027841B9A11340F9A01740F9770300946F +S315E63066B0A01340F9010C40B2A01740F92000008B38 +S315E63066C000040091610200D02280059120B000F9E5 +S315E63066D0E01F80D2400400F9F30B40F9FD7BC3A8F6 +S315E63066E0C0035FD6FD7BBEA9FD030091F35301A936 +S315E63066F0F30300AAF40301AAADFCFF976102403921 +S315E63067003F080171C100005460064039800000350B +S315E630671021008052810200B9190000143F5C0171F4 +S315E6306720C100005460064039800000354100805291 +S315E6306730810200B9120000143F300171C1000054E5 +S315E6306740600640398000003581008052810200B90A +S315E63067500B0000143F600171C100005460064039F9 +S315E6306760C000003501018052810200B904000014F0 +S315E6306770200080520200001420008052F35341A9D3 +S315E6306780FD7BC2A8C0035FD6FD7BBAA9FD030091A7 +S315E6306790BF5F0039600200D0007841B9A05F00B92A +S315E63067A003008052A25F0091A1630091600200D09F +S315E63067B000C003912DFDFF97001C00538004003581 +S315E63067C001008052000100D00080039191FBFF97D3 +S315E63067D0600200D0007841B9000400511F1C0071F8 +S315E63067E0A8050054C10000B02160149120486038F5 +S315E63067F0610000102088208B00001FD621008052D1 +S315E6306800000100D000C0039182FBFF9722000014FE +S315E630681021008052000100D000E003917DFBFF9716 +S315E63068201D00001421008052000100D000000491C2 +S315E630683078FBFF971800001421008052000100D043 +S315E63068400020049173FBFF97130000140300805277 +S315E6306850A25F0091A1630091600200D000C003916F +S315E630686002FDFF97A1730191A06300919EFFFF970A +S315E6306870001C0053A000003421008052000100D0F5 +S315E630688000E0029163FBFF97A15F40B9600200D05A +S315E6306890017801B9FD7BC6A8C0035FD6FD7BBDA9ED +S315E63068A0FD030091F30B00F9F303002A600200D0F2 +S315E63068B001EC40F9A0C30091018C1FF8390400942D +S315E63068C0001C00531F040071C100005421008052A1 +S315E63068D0000100D000E002914EFBFF97270000143E +S315E63068E0C00400357F120071800100547F220071AA +S315E63068F0400200547F0A007101030054A01740F9A4 +S315E6306900C002003621008052000100D0008002919C +S315E630691040FBFF9719000014A01740F90004409297 +S315E6306920C00100B421008052000100D000800291FF +S315E630693038FBFF9711000014A01740F90008409283 +S315E6306940C00000B421008052000100D000800291E0 +S315E630695030FBFF970900001402008052E103132A48 +S315E6306960A01740F945030094600200D001EC40F9E7 +S315E63069703340338B13EC00F9F30B40F9FD7BC3A8B8 +S315E6306980C0035FD6FD7BBFA9FD0300912000805290 +S315E6306990C3FFFF97FD7BC1A8C0035FD6FD7BBFA9CA +S315E63069A0FD03009140008052BDFFFF97FD7BC1A8F5 +S315E63069B0C0035FD6FD7BBFA9FD0300918000805200 +S315E63069C0B7FFFF97FD7BC1A8C0035FD6FD7BBFA9A6 +S315E63069D0FD03009100018052B1FFFF97FD7BC1A810 +S315E63069E0C0035FD6FD7BBCA9FD030091F35301A935 +S315E63069F0F403002AA3930091A2A30091A1C30091C8 +S315E6306A00A0E300912F040094A12740B93F0C007112 +S315E6306A10A0020054001C00531F040071C10000544C +S315E6306A2021008052000100D000E00291F9FAFF978A +S315E6306A302D0000141F080071C10000542100805259 +S315E6306A40000100D000200391F2FAFF9726000014E9 +S315E6306A5021008052000100D000E00291EDFAFF9766 +S315E6306A60210000149F12007121010054A01F40F945 +S315E6306A7000044092C00000B421008052000100D0EC +S315E6306A8000800291E3FAFF97170000149F22007107 +S315E6306A9021010054A01F40F900084092C00000B41E +S315E6306AA021008052000100D000800291D9FAFF978A +S315E6306AB00D000014B31F40F906000014E203142A51 +S315E6306AC0A11740F9E00313AAD90200947342348B36 +S315E6306AD0A01B40F9A11F40F92000008B7F0200EB96 +S315E6306AE0E9FEFF54F35341A9FD7BC4A8C0035FD644 +S315E6306AF0FD7BBFA9FD03009120008052BAFFFF97C8 +S315E6306B00FD7BC1A8C0035FD6FD7BBFA9FD0300911F +S315E6306B1080008052B4FFFF97FD7BC1A8C0035FD6E5 +S315E6306B20FD7BBFA9FD03009100018052AEFFFF97C2 +S315E6306B30FD7BC1A8C0035FD6FD7BBBA9FD030091F3 +S315E6306B40F35301A9600200D01FF401B9A3D3009133 +S315E6306B50A2E30091A1030191A02301911B040094C5 +S315E6306B60B42340F9A03740B91F0C0071C000005479 +S315E6306B7021008052000100D000E00291A5FAFF978D +S315E6306B8065000014E06740B29F0200EBC80000548F +S315E6306B9021008052000100D0006004919DFAFF97F3 +S315E6306BA05D000014E09766B28002008BE16740B282 +S315E6306BB01F0001EB48040054E1040094C00A003596 +S315E6306BC0600200D000F441B91F0400718000005421 +S315E6306BD01F040471C00100542B000014A02340F9B1 +S315E6306BE0A11F40F90100010B210400512305009451 +S315E6306BF0A02340F9A11F40F90100018BA22740F9F5 +S315E6306C00210400D1750500941F000014A02340F935 +S315E6306C10A11F40F90100010B210400519D060094A5 +S315E6306C20A02340F9A11F40F90100018BA22740F9C4 +S315E6306C30210400D11C07009413000014B32740F951 +S315E6306C400B00001422008052A1A30091E00313AAA0 +S315E6306C50F601009422008052A11740F9E00314AA07 +S315E6306C60730200949406009173060091A01F40F9D2 +S315E6306C70A12740F92000008B000400D17F0200EB0B +S315E6306C8029FEFF5401008052000100D000A0049195 +S315E6306C9060FAFF97B32740F9B42340F9140000149D +S315E6306CA022008052A1A30091E00313AADF010094EB +S315E6306CB022008052A1830091E00314AADB010094FE +S315E6306CC0A01740F9A11340F93F0000EBC00000548D +S315E6306CD0210080522001009000602B914DFAFF97FB +S315E6306CE00D0000149406009173060091A01F40F93A +S315E6306CF0A12740F92000008B000400D17F0200EB8B +S315E6306D0009FDFF5421008052000100D000E00491D5 +S315E6306D1040FAFF97F35341A9FD7BC5A8C0035FD67A +S315E6306D20FD7BBFA9FD030091600200D01FF401B9D7 +S315E6306D3021008052000100D00000059135FAFF9718 +S315E6306D40AFEFFF9795EFFF979FFDFF97C100009056 +S315E6306D5021803E9120D860F800003FD67804009432 +S315E6306D6060000034C1EFFF970300001470330094DF +S315E6306D70BEEFFF97FD7BC1A8C0035FD6FD7BBFA9FB +S315E6306D80FD030091600200D00050433900101D72B9 +S315E6306D90E2179F1A1F800071E1179F1A4100012AF8 +S315E6306DA0610000351F200071C10000540000AA5270 +S315E6306DB0FB120094E0000035DAFFFF970500001479 +S315E6306DC021008052000100D00080059111FAFF972C +S315E6306DD0FD7BC1A8C0035FD6FD7BBDA9FD0300914F +S315E6306DE0F35301A9F51300F9F303002AF403012A54 +S315E6306DF0F503022A600200D01FF401B9500400946C +S315E6306E00E0040035600200D000F441B91F04007199 +S315E6306E10800000541F040471400200542000001420 +S315E6306E2021008052000100D000000691F9F9FF9763 +S315E6306E30E103142AE003132A9004009421008052D9 +S315E6306E40000100D000800691F2F9FF97E203152A99 +S315E6306E50E103142AE003132AE00400941000001438 +S315E6306E6021008052000100D000000691E9F9FF9733 +S315E6306E70E103142AE003132A060600942100805221 +S315E6306E80000100D000800691E2F9FF97E203152A69 +S315E6306E90E103142AE003132A83060094F35341A947 +S315E6306EA0F51340F9FD7BC3A8C0035FD6FD7BBFA9CA +S315E6306EB0FD030091600200D000E00791DD02009408 +S315E6306EC0001C00531F040071E1000054210080527B +S315E6306ED0000100D000E00291CEF9FF972000805203 +S315E6306EE0190000141F080071E10000542100805299 +S315E6306EF0000100D000E00291C6F9FF9720008052EB +S315E6306F0011000014E0010035600200D000FC40F9C3 +S315E6306F1001044092E10000B421008052000100D025 +S315E6306F2000800291BBF9FF972000805206000014DC +S315E6306F30610200D020F001B9000080520200001450 +S315E6306F4020008052FD7BC1A8C0035FD6FD7BBAA97F +S315E6306F50FD030091F30B00F9F303002A8200805219 +S315E6306F60A1830091F9FAFF9701008052000100D023 +S315E6306F7000000791A7F9FF9721008052A083009180 +S315E6306F80A4F9FF9710F9FF97E003132AF30B40F9BC +S315E6306F90FD7BC6A8C0035FD6FD7BBFA9FD03009186 +S315E6306FA0C3FFFF971F040071A0000054600200D0B3 +S315E6306FB000F041B9E6FFFF97A6290094FD7BC1A80C +S315E6306FC0C0035FD6FD7BBFA9FD030091600200D00A +S315E6306FD01FF401B921008052000100D0004007912C +S315E6306FE08CF9FF97D603009460010035600200D035 +S315E6306FF000F441B91F040071800000541F04047187 +S315E630700080000054040000142E050094020000149B +S315E63070100D070094FD7BC1A8C0035FD6FD7BBFA9F3 +S315E6307020FD03009121008052000100B00000089176 +S315E630703078F9FF9701008052000100B000600891B0 +S315E630704074F9FF974AFBFF97001C00538000003423 +S315E6307050000180522BFAFF970C0000140001805293 +S315E630706028FAFF97E6EEFF97CCEEFF97D6FCFF972A +S315E6307070A10000F021803E9120D860F800003FD68E +S315E6307080D1FFFF97F9EEFF97FD7BC1A8C0035FD628 +S315E6307090FD7BBFA9FD030091600200B00050433985 +S315E63070A000101D72E2179F1A1F800071E1179F1AB2 +S315E63070B04100012A610000351F200071610000544D +S315E63070C0D7FFFF970500001421008052000100B07B +S315E63070D0008005914FF9FF97FD7BC1A8C0035FD6C7 +S315E63070E0FD7BBFA9FD03009121008052000100B06F +S315E63070F000A0089147F9FF9721008052000100B0C1 +S315E630710000E0089143F9FF97AFF8FF97600200B0C9 +S315E63071100050433900101D121F6000718100005483 +S315E630712040008052C1F7FF970300001440008052BA +S315E63071307BF8FF97FD7BC1A8C0035FD6FD7BBEA972 +S315E6307140FD030091F35301A9000C80D2C0C2BCF214 +S315E6307150000040B913304CD321008052000100B014 +S315E630716000A008912BF9FF97600200B00050433932 +S315E630717000101D121FE0007181000054B300003488 +S315E6307180F300003405000014340080520400001485 +S315E6307190540280520200001434028052210080529A +S315E63071A0000100B000E009911AF9FF9786F8FF97DB +S315E63071B0600200B00050433900101D121F600071A6 +S315E63071C081000054E003142A98F7FF970300001471 +S315E63071D0E003142A52F8FF97F35341A9FD7BC2A880 +S315E63071E0C0035FD6FD7BBFA9FD030091600200B008 +S315E63071F00050433900101D121FE000716100005443 +S315E6307200CFFFFF970C000014600200B001DC40B9F6 +S315E630721000E089523F00006BC1000054600200B0C6 +S315E630722000D040B960000035AEFFFF97020000148B +S315E6307230C3FFFF97FD7BC1A8C0035FD6FD7BBFA921 +S315E6307240FD03009121008052000100B000A00891B4 +S315E6307250F0F8FF9721008052000100B000E00A9175 +S315E6307260ECF8FF9758F8FF970001805231F8FF9710 +S315E6307270FD7BC1A8C0035FD6421C005364040051AF +S315E63072809F1C0071280B0054C5000090A580149110 +S315E6307290A448643865000010A488248B80001FD685 +S315E63072A0001C005303800051631C00537F78017144 +S315E63072B088000054421C005320682238C0035FD64B +S315E63072C0421C0053C005805220682238C0035FD680 +S315E63072D0E40F054B842000110424C49A841C005321 +S315E63072E086800051C61C0053DF780171A800005431 +S315E63072F0461C0053C600258B246826380500001444 +S315E6307300441C00538400258BC605805226682438F3 +S315E6307310A5040011A51C0053020000140500805296 +S315E63073207F00056B68FDFF54C0035FD6640080526C +S315E63073308400054B84701D530424C49A841C005380 +S315E630734086800051C61C0053DF780171A8000054D0 +S315E6307350461C0053C600258B2468263805000014E3 +S315E6307360441C00538400258BC60580522668243893 +S315E6307370A5040011A51C0053020000140500805236 +S315E63073807F00056B48FDFF54C0035FD6E4008052AC +S315E63073908400054B84701D530424C49A841C005320 +S315E63073A086800051C61C0053DF780171A800005470 +S315E63073B0461C0053C600258B246826380500001483 +S315E63073C0441C00538400258BC60580522668243833 +S315E63073D0A5040011A51C00530200001405008052D6 +S315E63073E07F00056B48FDFF54C0035FD61F48003962 +S315E63073F041048052014400390102805207000014EC +S315E6307400221C00530300028B63F05F380368223890 +S315E630741021040051211C005341FFFF3541048052BF +S315E630742001000039C0035FD6420400515F1C00718B +S315E6307430A8020054C300009063A0149162486238F3 +S315E6307440630000106288228B40001FD60000403968 +S315E6307450001C0053200000F9C0035FD600004079D7 +S315E6307460003C0053200000F9C0035FD6000040B967 +S315E6307470E003002A200000F9C0035FD6000040F999 +S315E6307480200000F9C0035FD6FD7BB7A9FD03009166 +S315E6307490F35301A9F55B02A9F76303A9F92300F9CA +S315E63074A0F80300AAF70301AAF403022A200C409255 +S315E63074B01F3C00F140000054370C40B2F60318AAE0 +S315E63074C01500805251000014B90E00724000005487 +S315E63074D09501003502018052A1C30191E00316AA57 +S315E63074E0BBF9FF9701008052A0C3019149F8FF9797 +S315E63074F001008052000100900020229145F8FF9766 +S315E6307500E203142AA1430191E00316AAC7FFFF97C7 +S315E6307510E203142AA1C30191A02B40F9ACF9FF97F7 +S315E6307520831E0053A20E0012A1630191A02B40F9EF +S315E630753052FFFF979502183701008052A0C301919A +S315E630754034F8FF971300805206000014010080528B +S315E6307550000100D000A02E912EF8FF977306001199 +S315E63075607F02146B43FFFF540D0000140100805276 +S315E6307570000100D000A02E9126F8FF977306001181 +S315E630758002000014130080527F02146B03FFFF548F +S315E630759001008052A0C301911EF8FF979F06007145 +S315E63075A0610000543F3F0071A00100549F0A00710C +S315E63075B0610000543F3B0071200100549F12007178 +S315E63075C0610000543F330071A00000549F220071E1 +S315E63075D0810100543F23007141010054A0630191BB +S315E63075E083FFFF9701008052000100900020229130 +S315E63075F008F8FF9721008052A063019105F8FF97BE +S315E6307600B502140BD642348BE002188BDF0200EB60 +S315E6307610C9F5FF54F35341A9F55B42A9F76343A98C +S315E6307620F92340F9FD7BC9A8C0035FD64204005171 +S315E63076305F1C007108020054C300009063C01491C9 +S315E630764062486238630000106288228B40001FD69B +S315E6307650211C005301000039C0035FD6213C00539C +S315E630766001000079C0035FD6010000B9C0035FD6DA +S315E6307670010000F9C0035FD6FD7BB6A9FD03009194 +S315E6307680F35301A9F55B02A9F71B00F9F40300AA47 +S315E6307690F503012AF703022A160080525F0000142A +S315E63076A002018052A1C30191E00314AA48F9FF977B +S315E63076B001008052A0C30191D6F7FF9701008052B0 +S315E63076C0000100D000A02E91D2F7FF97E203152AEB +S315E63076D0A1630291E00314AA54FFFF97B31E005349 +S315E63076E0E203132AA1C30191A04F40F938F9FF9777 +S315E63076F001008052A0C30191C6F7FF970100805280 +S315E6307700000100B000E00B91C2F7FF97A13F01916F +S315E6307710A04301911FF8FF97A28302915FEC1A38D6 +S315E630772003008052A1C30191A04301914FF9FF971F +S315E630773080060035A03B41391F04007161000054D4 +S315E63077409442358B35000014A1C341393FB80071F8 +S315E6307750200600543F78017161000054944235CBDF +S315E63077602E000014731A1F53730600111F00336B75 +S315E6307770C900005421008052000100B000E00291B9 +S315E6307780A4F7FF9725000014A1430291A0C3019107 +S315E6307790BFF8FF97001C0053C0000034210080522A +S315E63077A0000100B000E002919AF7FF971B00001443 +S315E63077B0E203152AA14B40F9E00314AA9CFFFF9792 +S315E63077C0FF060071A1010054E203152AA163029176 +S315E63077D0E00314AA15FFFF97A04F40F9A14B40F9F5 +S315E63077E03F0000EBA000005421008052000100B0BB +S315E63077F000000C9187F7FF979442358B070000140B +S315E630780021008052000100B000E0029181F7FF9737 +S315E6307810020000143600805256F4FF34600200B09F +S315E630782014EC00F9F35341A9F55B42A9F71B40F98D +S315E6307830FD7BCAA8C0035FD6FD7BBDA9FD030091DB +S315E6307840F30B00F9F30300AAE00301AAA1A3009122 +S315E63078508FF8FF97001C00531F040071C0000054D8 +S315E6307860E0000035A01740F9600200F900008052CA +S315E630787004000014200080520200001400008052FA +S315E6307880F30B40F9FD7BC3A8C0035FD6FD7BBDA9EC +S315E6307890FD030091F35301A9F30300AAF40301AA09 +S315E63078A0A1A30091E00302AA79F8FF97001C0053E2 +S315E63078B01F0400714001005460010035610240F951 +S315E63078C0A01740F93F0000EB28010054000001CB39 +S315E63078D0800200F900008052060000142000805233 +S315E63078E0040000140000805202000014400080526A +S315E63078F0F35341A9FD7BC3A8C0035FD6FD7BB8A988 +S315E6307900FD030091F35301A9F55B02A9F50300AA3D +S315E6307910F60301AABFFF00391300805203008052F6 +S315E6307920A2FF0091A1030191600200B000C003916D +S315E6307930CEF8FF97141C00537F0600718000005482 +S315E63079407F0A0071200100540E000014A103019154 +S315E6307950E00315AAB9FFFF97001C00531F04007118 +S315E6307960010100540B000014A2030191E10316AAAB +S315E6307970E00315AAC6FFFF97001C0053A0000035AA +S315E630798073060011731E0053B4FCFF3500008052B7 +S315E6307990F35341A9F55B42A9FD7BC8A8C0035FD680 +S315E63079A0FD7BB8A9FD030091F35301A9F51300F960 +S315E63079B0F50300AABFFF0039130080520300805258 +S315E63079C0A2FF0091A1030191600200B000C00391CD +S315E63079D0A6F8FF97141C0053930000347F06007117 +S315E63079E08000005409000014140100350C00001420 +S315E63079F0A1030191E00315AA90FFFF97001C0053FF +S315E6307A001F040071E000005473060011731E005324 +S315E6307A1074FDFF35000080520200001420008052CB +S315E6307A20F35341A9F51340F9FD7BC8A8C0035FD6E9 +S315E6307A30FD7BB8A9FD030091F35301A9F51300F9CF +S315E6307A40F50300AABFFF00391300805203008052C7 +S315E6307A50A2FF0091A1030191600200B000C003913C +S315E6307A6082F8FF97141C0053930000347F060071AA +S315E6307A708000005409000014140100350C0000148F +S315E6307A80A1030191E00315AA6CFFFF97001C005392 +S315E6307A901F040071E000005473060011731E005394 +S315E6307AA074FDFF350000805202000014400080521B +S315E6307AB0F35341A9F51340F9FD7BC8A8C0035FD659 +S315E6307AC0FD7BB7A9FD030091F35301A9F55B02A946 +S315E6307AD0F76303A9F60300AAF80301AAF70302AA95 +S315E6307AE0F50303AA7F0000B9BF3F01391300805280 +S315E6307AF003008052A23F0191A1430191600200B09A +S315E6307B0000C0039159F8FF97141C00537F0E00719D +S315E6307B1068040054C000009000201A91004873387B +S315E6307B20610000102088208B00001FD694030035B4 +S315E6307B3020000014A1430191E00316AA3FFFFF9708 +S315E6307B40001C00531F04007160030054200080526D +S315E6307B50A00200B912000014A2430191E10318AA6B +S315E6307B60E00316AA4AFFFF97001C00534002003591 +S315E6307B7040008052A00200B909000014A1430191E9 +S315E6307B80E00317AA2DFFFF97001C00531F04007170 +S315E6307B902001005460008052A00200B9730600113D +S315E6307BA0731E005374FAFF3500008052020000144B +S315E6307BB020008052F35341A9F55B42A9F76343A906 +S315E6307BC0FD7BC9A8C0035FD6FD7BB7A9FD0300914F +S315E6307BD0F35301A9F55B02A9F76303A9F80300AAF3 +S315E6307BE0F70301AAF60302AAF50303AA7F0000B952 +S315E6307BF0BF3F01391300805203008052A23F019104 +S315E6307C00A1430191600200B000C0039117F8FF97D7 +S315E6307C10141C00537F0E007168040054C0000090B7 +S315E6307C2000301A9100487338610000102088208BA6 +S315E6307C3000001FD69403003520000014A1430191BD +S315E6307C40E00318AAFDFEFF97001C00531F040071DF +S315E6307C506003005420008052A00200B912000014DE +S315E6307C60A1430191E00317AAF4FEFF97001C0053E7 +S315E6307C701F0400714002005440008052A00200B951 +S315E6307C8009000014A1430191E00316AAEBFEFF9723 +S315E6307C90001C00531F04007120010054600080521E +S315E6307CA0A00200B973060011731E005374FAFF354D +S315E6307CB0000080520200001420008052F35341A99E +S315E6307CC0F55B42A9F76343A9FD7BC9A8C0035FD636 +S315E6307CD0FD7BB3A9FD030091F35301A9F55B02A938 +S315E6307CE0F71B00F9F60300AAF70301AAF50302AA81 +S315E6307CF05F0000B9BF3F013913008052030080525E +S315E6307D00A23F0191A1430291600200B000C0039107 +S315E6307D10D6F7FF97141C00537F060071E000005437 +S315E6307D20930000347F0A0071A00100542D00001440 +S315E6307D30940500353D000014E10316AAA0430291EE +S315E6307D4053F7FF97001C005340070035A00240B9B1 +S315E6307D5000000032A00200B922000014A10301910E +S315E6307D60A04302914AF7FF97001C00538001003585 +S315E6307D70A00240B900001F32A00200B9C10240F9A4 +S315E6307D80A02340F93F0000EB88050054000001CB04 +S315E6307D9000040091E00200F9120000141F0C007195 +S315E6307DA001050054A24303912000805240EC173877 +S315E6307DB003008052A1430191A0430291ABF7FF97AE +S315E6307DC0E10317AAA043019131F7FF97001C005350 +S315E6307DD0C0030035A00240B900001F32A00200B948 +S315E6307DE09FEE00718101005403008052A23F01915B +S315E6307DF0A1430291600200B000C003919BF7FF9762 +S315E6307E0080020035A00240B900001D32A00200B95A +S315E6307E101400805273060011731E005314F7FF35B3 +S315E6307E20000080520C000014400080520A00001414 +S315E6307E3020008052080000144000805206000014EC +S315E6307E402000805204000014200080520200001404 +S315E6307E5020008052F35341A9F55B42A9F71B40F95E +S315E6307E60FD7BCDA8C0035FD682AA82D20280A0F27D +S315E6307E70A3AA8A12430000799F3F03D5A4AA8A5261 +S315E6307E80435581D20380A0F2640000799F3F03D543 +S315E6307E90E3ED8D12430000799F3F03D50280A0D2F1 +S315E6307EA04300407903000079800080D20080A0F25A +S315E6307EB00000407920000079E0E181124000007947 +S315E6307EC09F3F03D5C0035FD6E1EC8C12802A80D281 +S315E6307ED00080A0F2010000799F3F03D5001580D2DD +S315E6307EE00080A0F200004079003C0053E2E18112C6 +S315E6307EF00180A0D2220000799F3F03D50120404A77 +S315E6307F00211C005341010035001C0053400100346A +S315E6307F10210080522020C01A007C0113610200B095 +S315E6307F202000047900008052C0035FD620008052DC +S315E6307F30C0035FD620008052C0035FD6FD7BBBA967 +S315E6307F40FD030091F30B00F980468252A09F00793B +S315E6307F50A143019120CC1F78A03B0191C3FFFF9747 +S315E6307F60A09F40791F04047181020054A29B407998 +S315E6307F70C1CF8F525F00016B01020054610200B03F +S315E6307F8020F401B921008052000100B000C02991E9 +S315E6307F90A0F5FF97CDFFFF97F303002A6004003480 +S315E6307FA021008052000100B000A02A9199F5FF9792 +S315E6307FB0330080522D00001421008052000100B0BB +S315E6307FC000C02B9193F5FF9782008052A1A30091D2 +S315E6307FD0A09F4079DDF6FF9701008052000100B0A0 +S315E6307FE000E02C918BF5FF9721008052A0A30091FB +S315E6307FF088F5FF9782008052A1A30091A09B407935 +S315E6308000D2F6FF97010080520001009000402D9194 +S315E630801080F5FF9721008052A0A300917DF5FF976A +S315E630802033008052110000140100805200010090A6 +S315E630803000A02D9177F5FF97A2930091A1E30091E9 +S315E6308040600200900000447909F6FF9701008052FD +S315E6308050A0E300916FF5FF97210080520001009072 +S315E630806000202E916BF5FF97E003132AF30B40F9C8 +S315E6308070FD7BC5A8C0035FD6FD7BBCA9FD03009199 +S315E6308080F35301A9F51300F900380F1234380F12FD +S315E6308090021E80520180A0D2220000799F3F03D58E +S315E63080A0F303002A43000014405581D20080A0F243 +S315E63080B043158052030000799F3F03D581AA80D2CB +S315E63080C00180A0F2A20A8052220000799F3F03D5B2 +S315E63080D004108052040000799F3F03D503000079EF +S315E63080E09F3F03D5220000799F3F03D5E10313AACC +S315E63080F000068052600200799F3F03D560024079E0 +S315E6308100003C0053250000144004283635004079FB +S315E6308110B53E005355043837011E80520080A0D252 +S315E630812001000079010080520001009000402E9156 +S315E630813038F5FF9782008052A1C30091E003132AF7 +S315E630814082F6FF9701008052A0C3009131F5FF9782 +S315E6308150010080520001009000202F912DF5FF9707 +S315E630816042008052A1C30091E003152A77F6FF97C5 +S315E630817001008052A0C3009126F5FF972100805278 +S315E63081800001009000602F9122F5FF970F00001452 +S315E630819020004079003C005380FB3F360100805298 +S315E63081A0000100B0000037911AF5FF9773824091CF +S315E63081B07F4234EBA9F7FF5421008052000100904C +S315E63081C000802F9113F5FF97F35341A9F51340F944 +S315E63081D0FD7BC4A8C0035FD6FD7BBBA9FD0300913A +S315E63081E0F35301A9F55B02A9F76303A9F60302AADD +S315E63081F0F70300AAA1000036350000CBB50600919C +S315E6308200B5FE41D3A5000014350000CBB50A009182 +S315E6308210B5FE41D3A1000014600200901400447903 +S315E6308220BF02146B48000054B43E0053E0420012DD +S315E6308230A000003501008052000100B00000379101 +S315E6308240F4F4FF9741158052405581D20080A0F272 +S315E6308250010000799F3F03D5A10A805280AA80D2D9 +S315E63082600080A0F2010000799F3F03D5A00480523A +S315E6308270E00200799F3F03D580060051003C00536B +S315E6308280E00200799F3F03D5F30317AA0000805238 +S315E63082900B000014630A0091C20A0091C1024079CC +S315E63082A0213C0053610200799F3F03D5000400115B +S315E63082B0003C0053F30303AAF60302AA9F02006BBF +S315E63082C0A8FEFF5420058052E00200799F3F03D591 +S315E63082D060E25F78003C0053D7E25F78F73E0053C2 +S315E63082E06A000014E005283678E25F78183F0053D6 +S315E63082F0E002184AE00C3836011E80520080A0D2E1 +S315E6308300010000799F3F03D50100805200010090BD +S315E630831000E02F91BFF4FF9782008052A1030191CE +S315E63083206006005109F6FF9701008052A0030191DD +S315E6308330B8F4FF97010080520001009000C03091FA +S315E6308340B4F4FF9742008052A1030191E003172A65 +S315E6308350FEF5FF9701008052A0030191ADF4FF9739 +S315E6308360010080520001009000202F91A9F4FF977A +S315E630837042008052A1030191E003182AF3F5FF97F4 +S315E630838001008052A0030191A2F4FF9721008052AA +S315E63083900001009000602F919EF4FF974400001490 +S315E63083A00007083678E25F78183F0053E002184A4D +S315E63083B000073836405581D20080A0F2411580520A +S315E63083C0010000799F3F03D5A20A805281AA80D266 +S315E63083D00180A0F2220000799F3F03D5011E80522C +S315E63083E0010000799F3F03D50100805200010090DD +S315E63083F00000319187F4FF9782008052A103019104 +S315E630840060060051D1F5FF9701008052A003019135 +S315E630841080F4FF97010080520001009000C0309151 +S315E63084207CF4FF9742008052A1030191E003172ABC +S315E6308430C6F5FF9701008052A003019175F4FF97C8 +S315E6308440010080520001009000202F9171F4FF97D1 +S315E630845042008052A1030191E003182ABBF5FF974B +S315E630846001008052A00301916AF4FF972100805201 +S315E63084700001009000602F9166F4FF970C0000141F +S315E630848060E25F78003C00530100174AC1F23F379D +S315E6308490B502144BF70313AA15ECFF3521008052CB +S315E63084A00001009000C031915AF4FF97F35341A989 +S315E63084B0F55B42A9F76343A9FD7BC5A8C0035FD642 +S315E63084C0FD7BBFA9FD03009121008052000100909B +S315E63084D0002032914FF4FF97011E80520080A0D2E1 +S315E63084E0010000799F3F03D500A82A9143158052B3 +S315E63084F0030000799F3F03D581AA80D20180A0F29E +S315E6308500A20A8052220000799F3F03D5041080529A +S315E6308510040000799F3F03D5030000799F3F03D5DA +S315E6308520220000799F3F03D501028052010000798F +S315E63085309F3F03D50080A0D200004079C0FF3F368A +S315E6308540011E80520080A0D2010000799F3F03D5FC +S315E6308550210080520001009000E032912DF4FF9721 +S315E6308560FD7BC1A8C0035FD6213C005302004079AB +S315E63085703F04007161000054421C005303000014AE +S315E630858041000035421C181202000079C0035FD65E +S315E6308590FD7BBEA9FD030091F30B00F9133C0053B6 +S315E63085A060060012E0010034E1E181120080A0D2DB +S315E63085B0010000799F3F03D5B300083601008052AB +S315E63085C0000100900020339112F4FF97B300003695 +S315E63085D00100805200010090000034910DF4FF97BF +S315E63085E07F061E720003005480AA82D20080A0F273 +S315E63085F0A1AA8A12010000799F3F03D5A2AA8A5220 +S315E6308600415581D20180A0F2220000799F3F03D501 +S315E6308610E1E18112010000799F3F03D5B3001836B8 +S315E6308620010080520001009000C03491F9F3FF97C3 +S315E6308630B30010360100805200010090008035917B +S315E6308640F4F3FF977F061C72E0010054E1E18112F4 +S315E63086500080A0D2010000799F3F03D5B3002836CB +S315E6308660210080520001009000403691E9F3FF97F1 +S315E6308670B300203621008052000100900000379189 +S315E6308680E4F3FF97F30B40F9FD7BC2A8C0035FD650 +S315E6308690FD7BBAA9FD030091F35301A9F55B02A967 +S315E63086A0F71B00F9BFBB007900340E1237340E12D1 +S315E63086B0E2E181120180A0D2220000799F3F03D504 +S315E63086C0F503002A160080526C00001480AA82D286 +S315E63086D00080A0F2A3AA8A12030000799F3F03D551 +S315E63086E0415581D20180A0F2A2AA8A5222000079AF +S315E63086F09F3F03D5E4EF8F12040000799F3F03D501 +S315E6308700030000799F3F03D5220000799F3F03D5CA +S315E6308710F40315AA00068652A00200799F3F03D5D8 +S315E6308720130080524A000014A083019101008012A2 +S315E630873001CC1F78E103132A8CFFFF97810240793B +S315E6308740A083019101EC1F78E103132A87FFFF9797 +S315E630875036000014000484523F00006AC005005417 +S315E630876081024079A083019101EC1F78E103132A57 +S315E63087707EFFFF97A1BF4079A0BB40792000004A33 +S315E6308780003C0053E1EF8F121F00016AC00500542A +S315E630879073000035D6021B32040000147F060071E2 +S315E63087A041000054D6021C3201008052000100908E +S315E63087B000402E9197F3FF9782008052A1230191D4 +S315E63087C0E003152AE1F4FF9701008052A0230191D8 +S315E63087D090F3FF97010080520001009000202F9120 +S315E63087E08CF3FF9742008052A1230191A0BF4079D6 +S315E63087F0D6F4FF9701008052A023019185F3FF97C7 +S315E6308800210080520001009000602F9181F3FF979E +S315E63088100D00001481024079A083019101EC1F78A6 +S315E6308820E103132A51FFFF97A1BF4079A0BB4079F8 +S315E63088302000004A003C0053E2EF8F121F00026A26 +S315E6308840A1F8FF5473060011733E00537F0600719C +S315E6308850C9F6FF5496000034E003162A4DFFFF971B +S315E63088600C00001401008052000100B00000379180 +S315E630887068F3FF97B5024191BF4237EB89F2FF5471 +S315E6308880210080520001009000802F9161F3FF971E +S315E6308890F35341A9F55B42A9F71B40F9FD7BC6A820 +S315E63088A0C0035FD6FD7BB9A9FD030091F35301A959 +S315E63088B0F55B02A9F76303A9F92300F9F50302AAE2 +S315E63088C0F40300AAA1000036370000CBF706009184 +S315E63088D0F7FE41D3D1000014370000CBF70A0091FA +S315E63088E0F7FE41D3CD0000146002009016004479BD +S315E63088F0FF06166B69000054D63A1F530200001481 +S315E6308900F63E005380460012A00000350100805244 +S315E6308910000100B0000037913EF3FF97A1AA8A1214 +S315E630892080AA82D20080A0F2010000799F3F03D56B +S315E6308930A1AA8A52405581D20080A0F20100007980 +S315E63089409F3F03D5A0A48452800200799F3F03D58A +S315E6308950C00600510020002A003C00538002007910 +S315E63089609F3F03D5F30314AA000080520B00001490 +S315E6308970630A0091A20A0091A1024079213C005394 +S315E6308980610200799F3F03D500040011003C005395 +S315E6308990F30303AAF50302AADF02006BA8FEFF542F +S315E63089A020258552800200799F3F03D5B8E25F786D +S315E63089B0183F005319008052140080528F0000147D +S315E63089C0A0C3019118CC1F78E103142AE7FEFF977E +S315E63089D061E25F78A0C3019101EC1F78E103142AC6 +S315E63089E0E2FEFF977C000014000484523F00006AE2 +S315E63089F02007005461E25F78A0C3019101EC1F784D +S315E6308A00E103142AD9FEFF97A1DF4079A0DB40794E +S315E6308A102000004A003C0053E1EF8F121F00016A46 +S315E6308A20800E00549F06007161000054390300320F +S315E6308A30030000145400003539031F32010080521A +S315E6308A400001009000E02F91F2F2FF97820080520B +S315E6308A50A1630191600600513CF4FF970100805214 +S315E6308A60A0630191EBF2FF9701008052000100907E +S315E6308A7000C03091E7F2FF9742008052A163019140 +S315E6308A80A0DB407931F4FF9701008052A063019173 +S315E6308A90E0F2FF97010080520001009000202F910E +S315E6308AA0DCF2FF9742008052A1630191A0DF407964 +S315E6308AB026F4FF9701008052A0630191D5F2FF9725 +S315E6308AC0210080520001009000602F91D1F2FF978D +S315E6308AD048000014404080523F00006A20070054A8 +S315E6308AE061E25F78A0C3019101EC1F78E103142AB5 +S315E6308AF09EFEFF97A1DF4079A0DB40792000004A51 +S315E6308B00003C0053E1EF8F121F00016A2007005444 +S315E6308B109F0600716100005439031E3203000014CB +S315E6308B205400003539031D320100805200010090B1 +S315E6308B3000003191B7F2FF9782008052A16301912E +S315E6308B406006005101F4FF9701008052A06301915F +S315E6308B50B0F2FF97010080520001009000C03091DC +S315E6308B60ACF2FF9742008052A1630191A0DB4079D7 +S315E6308B70F6F3FF9701008052A0630191A5F2FF97C5 +S315E6308B80010080520001009000202F91A1F2FF975C +S315E6308B9042008052A1630191A0DF4079EBF3FF9763 +S315E6308BA001008052A06301919AF2FF97210080522C +S315E6308BB00001009000602F9196F2FF970D000014A9 +S315E6308BC061E25F78A0C3019101EC1F78E103142AD4 +S315E6308BD066FEFF97A1DF4079A0DB40792000004AA8 +S315E6308BE0003C0053E2EF8F121F00026AE1EFFF54BA +S315E6308BF094060011943E00539F06007129EEFF5409 +S315E6308C0099000034E003192A62FEFF970800001443 +S315E6308C10F702164BF40313AA97E6FF352100805286 +S315E6308C200001009000C031917AF2FF97F35341A9E3 +S315E6308C30F55B42A9F76343A9F92340F9FD7BC7A85B +S315E6308C40C0035FD6FD7BBFA9FD03009121008052AC +S315E6308C500001009000C037916EF2FF97E1E1811294 +S315E6308C600080A0D2010000799F3F03D580AA82D248 +S315E6308C700080A0F2A3AA8A12030000799F3F03D5AB +S315E6308C80415581D20180A0F2A2AA8A522200007909 +S315E6308C909F3F03D5E4EF8F12040000799F3F03D55B +S315E6308CA0030000799F3F03D5220000799F3F03D525 +S315E6308CB001028252010000799F3F03D501008052BE +S315E6308CC00080A0D200004079003C0053E2EF8F12DC +S315E6308CD01F00026A8101005400A086528001A0720C +S315E6308CE03F00006BC100005401008052000100B025 +S315E6308CF00000379147F2FF970100805221040011B8 +S315E6308D00F0FFFF17E1E181120080A0D20100007981 +S315E6308D109F3F03D5210080520001009000E032915A +S315E6308D203CF2FF97FD7BC1A8C0035FD6FD7BBDA9AC +S315E6308D30FD030091F35301A9F51300F9F403002A74 +S315E6308D40F303012AF503022A5D0E0094E203152A9F +S315E6308D500100A1528102010BE003132A7E1600942C +S315E6308D60F35341A9F51340F9FD7BC3A8C0035FD69B +S315E6308D70FD7BBDA9FD030091F30B00F9F303002A51 +S315E6308D80C000A05200140094E003132AF80F0094B2 +S315E6308D90A0B30091CB130094A02F40B9C00028367B +S315E6308DA001008052000100900080389119F2FF9759 +S315E6308DB002000014E0FE0737F30B40F9FD7BC3A84B +S315E6308DC0C0035FD6FD7BBDA9FD030091F30B00F929 +S315E6308DD0F303002AC000A052EB130094E003132AF3 +S315E6308DE010100094A0B30091B6130094A02F40B9AA +S315E6308DF0C00028360100805200010090008038918C +S315E6308E0004F2FF9702000014E0FE0737F30B40F951 +S315E6308E10FD7BC3A8C0035FD6FD7BBEA9FD030091EB +S315E6308E20C000A052D8130094000CA052D61300947A +S315E6308E30A0730091A3130094A01F40B98000283791 +S315E6308E4080FF07370000805202000014200080526F +S315E6308E50FD7BC2A8C0035FD6FD7BBDA9FD030091AD +S315E6308E60F35301A9F303002AF403012AC000A05202 +S315E6308E70C5130094E103142AE003132A161000946E +S315E6308E80A0B300918F130094A02F40B9A0FF073707 +S315E6308E90F35341A9FD7BC3A8C0035FD6FD7BBDA9CD +S315E6308EA0FD030091F35301A9F55B02A9F403002A09 +S315E6308EB0F503012AF603022AC000A052B213009443 +S315E6308EC0F303152A06000014E103142AE003132AF5 +S315E6308ED0E2FFFF979402041173020411A002160B07 +S315E6308EE07F02006B23FFFF54F35341A9F55B42A99A +S315E6308EF0FD7BC3A8C0035FD6FD7BBEA9FD0300910B +S315E6308F00F35301A913340E1234340E12080000144A +S315E6308F10E003132A97FFFF9701008052000100B065 +S315E6308F2000003791BBF1FF97730241117F02146B54 +S315E6308F3009FFFF54210080520001009000802F91F6 +S315E6308F40B4F1FF97F35341A9FD7BC2A8C0035FD6C0 +S315E6308F50FD7BBEA9FD030091F35301A9134C141210 +S315E6308F60344C141208000014E003132A96FFFF97D8 +S315E6308F7001008052000100B000003791A5F1FF975D +S315E6308F80730640117F02146B09FFFF5421008052AD +S315E6308F900001009000802F919EF1FF97F35341A98F +S315E6308FA0FD7BC2A8C0035FD6FD7BBFA9FD0300915A +S315E6308FB08200A05200340E125DFFFF97FD7BC1A8FA +S315E6308FC0C0035FD6FD7BBDA9FD030091F35301A92E +S315E6308FD0F51300F9F403002AF303012AF503022A0E +S315E6308FE0B70D0094E203152A0100A1528102010B66 +S315E6308FF0E003132AD8150094F35341A9F51340F943 +S315E6309000FD7BC3A8C0035FD6FD7BBDA9FD030091FA +S315E6309010F35301A9F51300F9F403002AF303012A01 +S315E6309020F503022ADC0D0094E203152A0100A1526B +S315E63090308102010BE003132AC7150094F35341A9C5 +S315E6309040F51340F9FD7BC3A8C0035FD6FD7BBCA90B +S315E6309050FD030091F35301A9F55B02A9F503002A56 +S315E6309060F40301AAF603022AA13F00B9F303002A64 +S315E630907007000014A1F30091E003132A4811009487 +S315E6309080A03F40B9804600B873120011A002160B15 +S315E63090907F02006B03FFFF54F35341A9F55B42A908 +S315E63090A0FD7BC4A8C0035FD6FD7BBDA9FD03009159 +S315E63090B0F35301A9F51300F9F403002AF303012A61 +S315E63090C0F503022A05140094DA130094E203152A0E +S315E63090D00100A1528102010BE003132A9E1500948A +S315E63090E0F35341A9F51340F9FD7BC3A8C0035FD618 +S315E63090F0FD7BBEA9FD030091A17F009180008052E1 +S315E63091000010A07295110094A07F4039C00108374F +S315E6309110C000A0521C130094A17F403921001F32B3 +S315E6309120211C0053A17F0039800080520010A072C6 +S315E6309130C1110094A0630091E2120094A01B40B9DD +S315E6309140A0FF0737FD7BC2A8C0035FD6FD7BBDA96E +S315E6309150FD030091F30B00F9F303002AC000A05299 +S315E630916009130094E003132A010F0094A0B300918B +S315E6309170D4120094A02F40B9C000283601008052A0 +S315E6309180E00000F00080389122F1FF9702000014EB +S315E6309190E0FE0737F30B40F9FD7BC3A8C0035FD685 +S315E63091A0FD7BBDA9FD030091F30B00F9F303002A1D +S315E63091B0C000A052F4120094E003132A7013009410 +S315E63091C0A0B30091BF120094A02F40B9A0FF073795 +S315E63091D0F30B40F9FD7BC3A8C0035FD6FD7BBDA983 +S315E63091E0FD030091F30B00F9F303002AC000A05209 +S315E63091F0E5120094E003132A0A0F0094A0B3009117 +S315E6309200B0120094A02F40B9C00028360100805233 +S315E6309210E00000F000803891FEF0FF97020000147F +S315E6309220E0FE0737F30B40F9FD7BC3A8C0035FD6F4 +S315E6309230FD7BBEA9FD030091C000A052D212009478 +S315E6309240000CA052D0120094A07300919D120094A7 +S315E6309250A01F40B98000283780FF073700008052CC +S315E63092600200001420008052FD7BC2A8C0035FD600 +S315E6309270FD7BBDA9FD030091F35301A9F303002A53 +S315E6309280F403012AC000A052BF120094E103142A67 +S315E6309290E003132AB80F0094A0B300918912009424 +S315E63092A0A02F40B9A0FF0737F35341A9FD7BC3A8EA +S315E63092B0C0035FD6FD7BBCA9FD030091F35301A93C +S315E63092C0F51300F9F303002AF40301AA557C025399 +S315E63092D0C000A052AC120094E203152AE10314AAA8 +S315E63092E0E003132AEB0F0094A0F300917512009475 +S315E63092F0A03F40B9A0FF0737F35341A9F51340F92C +S315E6309300FD7BC4A8C0035FD6FD7BBDA9FD030091F6 +S315E6309310F35301A9F303002AF403012AC000A0524D +S315E630932099120094E103142AE003132A3E0F0094BF +S315E6309330A0B3009163120094A02F40B9A0FF07377F +S315E6309340F35341A9FD7BC3A8C0035FD6FD7BBDA918 +S315E6309350FD030091F35301A9F55B02A9F40300AAD4 +S315E6309360F503012AF603022AF303012A050000145F +S315E6309370814640B8E003132ABEFFFF977312001109 +S315E6309380A002160B7F02006B43FFFF54F35341A94D +S315E6309390F55B42A9FD7BC3A8C0035FD6FD7BBDA9BD +S315E63093A0FD030091F35301A9F55B02A9F503012A02 +S315E63093B0F603022AF40300AAF303012A070000148F +S315E63093C002208052E10314AAE003132ABAFFFF977C +S315E63093D09402049173020411A002160B7F02006B0D +S315E63093E003FFFF54F35341A9F55B42A9FD7BC3A8BE +S315E63093F0C0035FD6FD7BBDA9FD030091F35301A9FA +S315E6309400F55B02A9F503012AF603022AF40300AA5C +S315E6309410F303012A0700001402208052E10314AA5E +S315E6309420E003132AA4FFFF97940204917302041112 +S315E6309430A002160B7F02006B03FFFF54F35341A9DC +S315E6309440F55B42A9FD7BC3A8C0035FD6FD7BBDA90C +S315E6309450FD030091F35301A9F55B02A9F403002A53 +S315E6309460F503012AF603022AC000A05246120094FA +S315E6309470F303152A06000014E103142AE003132A3F +S315E6309480A2FFFF979402041173020411A002160B91 +S315E63094907F02006B23FFFF54F35341A9F55B42A9E4 +S315E63094A0FD7BC3A8C0035FD6FD7BBEA9FD03009155 +S315E63094B0F35301A913340E1234340E120DFFFF970F +S315E63094C008000014E003132A21FFFF9701008052BB +S315E63094D000010090000037914EF0FF97730241117C +S315E63094E07F02146B09FFFF5421008052E00000F042 +S315E63094F000802F9147F0FF97F35341A9FD7BC2A831 +S315E6309500C0035FD6FD7BBEA9FD030091F35301A9E7 +S315E6309510134C1412344C141208000014E003132AC8 +S315E63095202FFFFF970100805200010090000037912F +S315E630953038F0FF97730640117F02146B09FFFF542C +S315E630954021008052E00000F000802F9131F0FF9745 +S315E6309550F35341A9FD7BC2A8C0035FD6FD7BBFA905 +S315E6309560FD0300918200A05200340E12A7FEFF974B +S315E6309570FD7BC1A8C0035FD6FD7BBDA9FD03009187 +S315E6309580F35301A9F51300F9F403002AF303012A8C +S315E6309590F503022A4A0C0094E203152A0100A15289 +S315E63095A08102010BE003132A6B140094F35341A9AD +S315E63095B0F51340F9FD7BC3A8C0035FD6FD7BBCA996 +S315E63095C0FD030091F35301A9F55B02A9F503002AE1 +S315E63095D0F40301AAF603022AA13F00B9F303002AEF +S315E63095E007000014A1F30091E003132AEC0F009470 +S315E63095F0A03F40B9804600B873120011A002160BA0 +S315E63096007F02006B03FFFF54F35341A9F55B42A992 +S315E6309610FD7BC4A8C0035FD6FD7BBEA9FD030091E2 +S315E6309620A0630091000D0094A01B40B9C001083735 +S315E6309630C000A052D4110094A0730091A1110094F9 +S315E6309640A11B40B921001F32A11B00B9A01F40B9AA +S315E63096506E0D0094A07300919A110094A01F40B944 +S315E6309660A0FF0737FD7BC2A8C0035FD6FD7BBDA949 +S315E6309670FD030091F35301A9F51300F9F403002A2B +S315E6309680F303012AF503022AE4FFFF97E00B009481 +S315E6309690E203152A0100A1528102010BE003132AE7 +S315E63096A02D140094F35341A9F51340F9FD7BC3A875 +S315E63096B0C0035FD6FD7BBDA9FD030091F30B00F930 +S315E63096C0F303002AC000A052AF110094E003132A38 +S315E63096D0A70D0094A0B300917A110094A02F40B95B +S315E63096E0A0FF0737F30B40F9FD7BC3A8C0035FD66F +S315E63096F0FD7BBEA9FD030091C000A052A2110094E5 +S315E6309700000CA052A0110094A07300916D11009444 +S315E6309710A01F40B98000283780FF07370000805207 +S315E63097200200001420008052FD7BC2A8C0035FD63B +S315E6309730FD7BBEA9FD030091F35301A9F303002A8D +S315E6309740F403012AC000A0528F110094E103142AD3 +S315E6309750E003132A880E0094F35341A9FD7BC2A891 +S315E6309760C0035FD6FD7BBCA9FD030091F35301A987 +S315E6309770F51300F9F303002AF40301AA557C0253E4 +S315E6309780C000A05280110094E203152AE10314AA20 +S315E6309790E003132ABF0E0094A0F30091491100941A +S315E63097A0A03F40B9A0FF0737F35341A9F51340F977 +S315E63097B0FD7BC4A8C0035FD6FD7BBDA9FD03009142 +S315E63097C0F35301A9F303002AF403012AC000A05299 +S315E63097D06D110094E103142AE003132A120E009465 +S315E63097E0A0B3009137110094A02F40B9A0FF0737F8 +S315E63097F0F35341A9FD7BC3A8C0035FD6FD7BBDA964 +S315E6309800FD030091F35301A9F303002AF403012A79 +S315E6309810C000A0525C110094E103142AE003132A37 +S315E6309820AD0D0094A0B3009126110094A02F40B957 +S315E6309830A0FF0737F35341A9FD7BC3A8C0035FD624 +S315E6309840FD7BBDA9FD030091F35301A9F303002A7D +S315E6309850F403012A71FFFF97C000A0524A11009423 +S315E6309860E103142AE003132A71110094A0B30091A0 +S315E630987014110094A02F40B9A0FF0737F35341A93E +S315E6309880FD7BC3A8C0035FD6FD7BBDA9FD03009172 +S315E6309890F35301A9F303002AF403012A5FFFFF9786 +S315E63098A0C000A05238110094E103142AE003132ACB +S315E63098B0F30E0094A0B3009102110094A02F40B9A4 +S315E63098C0A0FF0737F35341A9FD7BC3A8C0035FD694 +S315E63098D0FD7BBDA9FD030091F35301A9F55B02A912 +S315E63098E0F40300AAF503012AF603022AF303012A52 +S315E63098F005000014814640B8E003132A8DFFFF9732 +S315E630990073120011A002160B7F02006B43FFFF5461 +S315E6309910F35341A9F55B42A9FD7BC3A8C0035FD6E5 +S315E6309920FD7BBDA9FD030091F35301A9F55B02A9C1 +S315E6309930F503012AF603022AF40300AAF303012A01 +S315E63099400700001402408052E10314AAE003132A0A +S315E630995085FFFF979402089173020811A002160B51 +S315E63099607F02006B03FFFF54F35341A9F55B42A92F +S315E6309970FD7BC3A8C0035FD6FD7BBDA9FD03009181 +S315E6309980F35301A9F55B02A9F503012AF603022A88 +S315E6309990F40300AAF303012A0700001402408052BA +S315E63099A0E10314AAE003132A6FFFFF9794020891A6 +S315E63099B073020811A002160B7F02006B03FFFF54F9 +S315E63099C0F35341A9F55B42A9FD7BC3A8C0035FD635 +S315E63099D0FD7BBDA9FD030091F35301A9F55B02A911 +S315E63099E0F403002AF503012AF603022AC000A05240 +S315E63099F0E5100094F303152A06000014E103142A51 +S315E6309A00E003132A6DFFFF979402041173020411E3 +S315E6309A10A002160B7F02006B23FFFF54F35341A9D6 +S315E6309A20F55B42A9FD7BC3A8C0035FD6FD7BBDA926 +S315E6309A30FD030091F35301A9F55B02A9F403002A6D +S315E6309A40F503012AF603022AC000A052CE1000948E +S315E6309A50F303152A06000014E103142AE003132A59 +S315E6309A6067FFFF979402041173020411A002160BE6 +S315E6309A707F02006B23FFFF54F35341A9F55B42A9FE +S315E6309A80FD7BC3A8C0035FD6FD7BBDA9FD03009170 +S315E6309A90F35301A9F55B02A9F40300AAF503012AFB +S315E6309AA0F603022AF303012A05000014814640B87C +S315E6309AB0E003132A75FFFF9773120011A002160B07 +S315E6309AC07F02006B43FFFF54F35341A9F55B42A98E +S315E6309AD0FD7BC3A8C0035FD6FD7BBEA9FD0300911F +S315E6309AE0F35301A913340E1234340E12080000145F +S315E6309AF0E003132AF0FEFF97010080520001009042 +S315E6309B0000003791C3EEFF97730241117F02146B63 +S315E6309B1009FFFF5421008052E00000F000802F91CB +S315E6309B20BCEEFF97F35341A9FD7BC2A8C0035FD6CF +S315E6309B30FD7BBFA9FD0300918200A05200340E12D0 +S315E6309B408EFEFF97FD7BC1A8C0035FD6FD7BBEA91F +S315E6309B50FD030091F35301A9F30300AAF40301AA26 +S315E6309B60020080528609009403008052A20A80528F +S315E6309B70E10314AAE00313AA01090094A003003511 +S315E6309B80A30A8052A20A8012E10314AAE00313AABA +S315E6309B90FB08009420030035A30A801202008012E7 +S315E6309BA0E10314AAE00313AAF5080094A0020035EF +S315E6309BB002008012E10314AAE00313AA870900948F +S315E6309BC04002003502008052E10314AAE00313AAEC +S315E6309BD0D509009402008052E10314AAE00313AAE1 +S315E6309BE0080A009440010034200080520800001430 +S315E6309BF02000805206000014200080520400001433 +S315E6309C00200080520200001420008052F35341A90E +S315E6309C10FD7BC2A8C0035FD6FD7BBDA9FD030091DF +S315E6309C20BF1300F9BF1700F9A2730091A183009123 +S315E6309C30A0A3009127F8FF97A11F40B9210400128F +S315E6309C40C100003521008052E00000F000E00291CC +S315E6309C5070EEFF976E000014001C00531F0400716F +S315E6309C60C100005421008052E00000F000E002918D +S315E6309C7068EEFF97660000141F080071C1000054B5 +S315E6309C8021008052E00000F00020039161EEFF975C +S315E6309C905F00001421008052E00000F000C03891E9 +S315E6309CA05CEEFF9721008052E00000F000603991CB +S315E6309CB058EEFF9721008052E00000F000003A911E +S315E6309CC054EEFF9721008052E00000F000A03A9172 +S315E6309CD050EEFF9721008052E00000F000403B91C5 +S315E6309CE04CEEFF9721008052E00000F000E03B9119 +S315E6309CF048EEFF9721008052E00000F000803C916C +S315E6309D0044EEFF9721008052E00000F000203D91BE +S315E6309D1040EEFF9721008052E00000F000C03D9112 +S315E6309D203CEEFF9721008052E00000F000603E9165 +S315E6309D3038EEFF9701008052E00000F000003F91D8 +S315E6309D4034EEFF97A01740F9A11340F90100018BD5 +S315E6309D507FFFFF974005003421008052E00000F097 +S315E6309D6000403F912BEEFF9702018052A1430091CE +S315E6309D70400200F0001C41F995EFFF970100805252 +S315E6309D80E00000F000803F9122EEFF9721008052FE +S315E6309D90A04300911FEEFF9702018052A143009146 +S315E6309DA0400200F0001041F989EFFF97010080523A +S315E6309DB0E00000F000C03F9116EEFF97210080529A +S315E6309DC0A043009113EEFF9702018052A143009122 +S315E6309DD0400200F0000441F97DEFFF970100805222 +S315E6309DE000010090000000910AEEFF9721008052B4 +S315E6309DF0A043009107EEFF9705000014210080523C +S315E6309E00000100900040009102EEFF97FD7BC3A86B +S315E6309E10C0035FD6FD7BBEA9FD030091F35301A9CE +S315E6309E20F30300AA341C0053050000141FC000716A +S315E6309E30400000544BEDFF977306009160024039BF +S315E6309E4060FFFF359F060071A1000054A0018052E5 +S315E6309E5044EDFF974001805242EDFF970000805275 +S315E6309E60F35341A9FD7BC2A8C0035FD6FD7BBFA9EC +S315E6309E70FD030091010080520001009000800091C0 +S315E6309E80E4EDFF97BAEFFF97001C005380000034ED +S315E6309E90400380529BEEFF97040000144003805245 +S315E6309EA098EEFF977C220094FD7BC1A8C0035FD66F +S315E6309EB0FD7BBFA9FD030091400200F00050433917 +S315E6309EC000101D72E2179F1A1F800071E1179F1A64 +S315E6309ED04100012A210100351F200071E0000054BF +S315E6309EE01F400071E1179F1A1F600171E0179F1A34 +S315E6309EF02000002A60000034DDFFFF9705000014DD +S315E6309F0021008052E00000F000800591C1EDFF9718 +S315E6309F10FD7BC1A8C0035FD6FD7BBBA9FD030091DF +S315E6309F20F35301A9F40300AA210080520001009000 +S315E6309F3000000191B7EDFF97330080522B000014F5 +S315E6309F40010080520001009000800191B1EDFF974B +S315E6309F50A1BF0091A0C30091DEEDFF97A243019128 +S315E6309F605FEC1D3803008052A1030191A0C3009136 +S315E6309F703EEFFF9720030035A0BB40391F04007142 +S315E6309F80400300541F0C0071C90000542100805272 +S315E6309F900001009000E001919EEDFF97130000145A +S315E6309FA0A1A30091A00301918CEEFF97001C00530C +S315E6309FB0C0000034210080520001009000E001919B +S315E6309FC094EDFF9709000014A02B40B9800200B942 +S315E6309FD013008052050000142100805200010090E3 +S315E6309FE000E001918BEDFF97D3FAFF35F35341A9A4 +S315E6309FF0FD7BC5A8C0035FD6FD7BB9A9FD030091FD +S315E630A000F35301A9F40300AA21008052E00000D000 +S315E630A01000A02B917FEDFF97F30000F073220291BB +S315E630A02021008052E00313AA7AEDFF972100805291 +S315E630A030E00000F000C0029176EDFF9721008052F5 +S315E630A040E00313AA73EDFF9721008052E00000F09B +S315E630A050006003916FEDFF9721008052E00000F03B +S315E630A06000E003916BEDFF97330080521400001445 +S315E630A07001008052E00000F00060049165EDFF9744 +S315E630A080A1BF0091A0C3009192EDFF97A0C34039DE +S315E630A0901FC40071800000541FC80071A000005430 +S315E630A0A007000014000C8052800200B90300001449 +S315E630A0B000148052800200B913008052B3FDFF359A +S315E630A0C0F35341A9FD7BC7A8C0035FD6FD7BB7A98D +S315E630A0D0FD030091F30B00F901008052E00000F039 +S315E630A0E000C004914BEDFF9722008052A1A3009168 +S315E630A0F0400200D0003042B994EEFF9721008052FC +S315E630A100A0A3009143EDFF9721008052E00000F0D6 +S315E630A110004005913FEDFF9721008052E00000F0C8 +S315E630A12000C005913BEDFF9721008052E00000F03C +S315E630A1300040069137EDFF97330080522600001433 +S315E630A14001008052E00000F000C0069131EDFF9745 +S315E630A150A13F0191A04301915EEDFF97A0434139BE +S315E630A1601FC8007180020054C80000541FC0007139 +S315E630A170200100541FC4007160010054160000141B +S315E630A1801F600171000200541FE00171C0010054E6 +S315E630A19011000014400200D000C008915FFFFF971F +S315E630A1A00C000014010C8052400200D0013002B996 +S315E630A1B00800001401148052400200D0013002B982 +S315E630A1C004000014400200D000C008918BFFFF97D0 +S315E630A1D01300805273FBFF3501008052E00000F039 +S315E630A1E0002007910BEDFF9722008052A1A3009144 +S315E630A1F0400200D0003042B954EEFF97210080523B +S315E630A200A0A3009103EDFF9700028052F12100945E +S315E630A210F30B40F9FD7BC9A8C0035FD6FD7BBFA92A +S315E630A220FD030091400200D00050433900101D7204 +S315E630A230E2179F1A1F800071E1179F1A4100012A23 +S315E630A240210100351F200071E00000541F400071E7 +S315E630A250E1179F1A1F600171E0179F1A2000002A46 +S315E630A260600000349AFFFF97050000142100805203 +S315E630A270E00000D000800591E6ECFF97FD7BC1A8B3 +S315E630A280C0035FD6FD7BBEA9FD030091A383009193 +S315E630A29061CC1FB824008052E203002A400200D087 +S315E630A2A0013042B900028052CE230094200080521B +S315E630A2B02CE3FF97FD7BC2A8C0035FD6FD7BBDA925 +S315E630A2C0FD030091F30B00F9F30301AA2400805253 +S315E630A2D0A3B30091E203002A400200D0013042B92E +S315E630A2E000028052F6220094A02F40B9600200F9AF +S315E630A2F0F30B40F9FD7BC3A8C0035FD6FD7BB6A959 +S315E630A300FD030091F35301A9F55B02A9F71B00F9AA +S315E630A310F40300AAF503012AF703022A160080524F +S315E630A3205F00001402018052A1C30191E00314AA32 +S315E630A33027EEFF9701008052A0C30191B5ECFF9757 +S315E630A34001008052E00000F000A02E91B1ECFF97BC +S315E630A350E203152AA1630291E00314AAD8FFFF9718 +S315E630A360B31E0053E203132AA1C30191A04F40F96D +S315E630A37017EEFF9701008052A0C30191A5ECFF9737 +S315E630A38001008052E00000D000E00B91A1ECFF978F +S315E630A390A13F0191A0430191FEECFF97A283029182 +S315E630A3A05FEC1A3803008052A1C30191A0430191B4 +S315E630A3B02EEEFF9780060035A03B41391F0400712B +S315E630A3C0610000549442358B35000014A1C34139FF +S315E630A3D03FB80071200600543F78017161000054A1 +S315E630A3E0944235CB2E000014731A1F5373060011B0 +S315E630A3F01F00336BC900005421008052E00000D0C4 +S315E630A40000E0029183ECFF9725000014A143029108 +S315E630A410A0C301919EEDFF97001C0053C0000034A7 +S315E630A42021008052E00000D000E0029179ECFF97FF +S315E630A4301B000014E203152AA14B40F9E00314AAE7 +S315E630A44091FFFF97FF060071A1010054E203152A3A +S315E630A450A1630291E00314AA99FFFF97A04F40F952 +S315E630A460A14B40F93F0000EBA0000054210080529A +S315E630A470E00000D000000C9166ECFF979442358BF5 +S315E630A4800700001421008052E00000D000E002917F +S315E630A49060ECFF97020000143600805256F4FF3423 +S315E630A4A0400200D0143001B9F35341A9F55B42A915 +S315E630A4B0F71B40F9FD7BCAA8C0035FD6FD7BBCA976 +S315E630A4C0FD030091400200D0013041B9A00301916D +S315E630A4D0018C1FF833F5FF97001C00531F040071FB +S315E630A4E0C100005421008052E00000D000E0029125 +S315E630A4F048ECFF9716000014A002003501008052A2 +S315E630A500E00000F000C0049142ECFF972200805252 +S315E630A510A1630091400200D0003042B98BEDFF973F +S315E630A52021008052A06300913AECFF9722008052D8 +S315E630A530E103022AA01F40F971FFFF97410200D0DE +S315E630A540203041B900040011203001B9FD7BC4A8A2 +S315E630A550C0035FD6FD7BBFA9FD030091400200D064 +S315E630A5600050433900101D72E2179F1A1F800071A2 +S315E630A570E1179F1A4100012A210100351F2000719B +S315E630A580E00000541F400071E1179F1A1F60017109 +S315E630A590E0179F1A2000002A60000034C8FFFF97B4 +S315E630A5A00500001421008052E00000D000800591BD +S315E630A5B018ECFF97FD7BC1A8C0035FD6FD7BB7A934 +S315E630A5C0FD030091F35301A9F55B02A9F76303A9ED +S315E630A5D0F92300F9F80300AAF70301AAF403022ADD +S315E630A5E001148052400200D0013002B9E00E4092AA +S315E630A5F01F3C00F140000054F70E40B2F60318AAAD +S315E630A6001500805251000014B90E00724000005415 +S315E630A6109501003502018052A1C30191E00316AAE5 +S315E630A6206BEDFF9701008052A0C30191F9EBFF97DE +S315E630A63001008052E00000B000202291F5EBFF9752 +S315E630A640E203142AA1430191E00316AA1CFFFF9701 +S315E630A650E203142AA1C30191A02B40F95CEDFF97E2 +S315E630A660831E0053A20E0012A1630191A02B40F97E +S315E630A67002F3FF979502183701008052A0C3019185 +S315E630A680E4EBFF9713008052060000140100805277 +S315E630A690E00000F000A02E91DEEBFF977306001186 +S315E630A6A07F02146B43FFFF540D0000140100805205 +S315E630A6B0E00000F000A02E91D6EBFF97730600116E +S315E630A6C002000014130080527F02146B03FFFF541E +S315E630A6D001008052A0C30191CEEBFF979F06007131 +S315E630A6E0610000543F3F0071A00100549F0A00719B +S315E630A6F0610000543F3B0071200100549F12007107 +S315E630A700610000543F330071A00000549F2200716F +S315E630A710810100543F23007141010054A063019149 +S315E630A72033F3FF9701008052E00000B0002022911B +S315E630A730B8EBFF9721008052A0630191B5EBFF9706 +S315E630A740B502140BD642348BE002188BDF0200EBEF +S315E630A750C9F5FF54F35341A9F55B42A9F76343A91B +S315E630A760F92340F9FD7BC9A8C0035FD6FD7BB9A9BD +S315E630A770FD030091F35301A9F55B02A9400200D02F +S315E630A78001400591145041B9350440B97220009420 +S315E630A790530200D0601A02B901008052E00000F0A0 +S315E630A7A000A007919BEBFF9722008052A1C3009150 +S315E630A7B0601A42B9E5ECFF9721008052A0C30091BA +S315E630A7C094EBFF97FA1F0094F603002A01008052B5 +S315E630A7D0E00000F0002008918EEBFF9722008052D1 +S315E630A7E0A1C30091E003162AD8ECFF9721008052E8 +S315E630A7F0A0C3009187EBFF9722008052E10315AAAA +S315E630A800E00314AA6EFFFF9721008052E00000D0E5 +S315E630A81000A02B917FEBFF97601A42B91F040071B7 +S315E630A82048030054400200D00050433900101D72F0 +S315E630A830E1179F1A1F800071E0179F1A2000002A41 +S315E630A8404002003401008052E00000F000C008917A +S315E630A85070EBFF9746EDFF97001C0053C0000034BF +S315E630A86021008052E00000D000A02B9169EBFF97E3 +S315E630A8702F00001418E1FF9721008052E00000D047 +S315E630A88000A02B9163EBFF9701008052E00000F0C9 +S315E630A890008009915FEBFF97D21F00942200805229 +S315E630A8A0A1C30091A9ECFF9701008052A0C30091A5 +S315E630A8B058EBFF9701008052E00000F000000A9165 +S315E630A8C054EBFF972AEDFF97001C0053C000003487 +S315E630A8D021008052E00000D000A02B914DEBFF978F +S315E630A8E01300001421008052E00000D000A02B9126 +S315E630A8F048EBFF97251E0094A001003521008052D3 +S315E630A900E00000F000400A9142EBFF9721008052CA +S315E630A910E00000F000A00A913EEBFF97220080525D +S315E630A920E10315AAE00314AA25FFFF97F35341A9DD +S315E630A930F55B42A9FD7BC7A8C0035FD6FD7BBFA901 +S315E630A940FD030091400200D00050433900101D72DD +S315E630A950E2179F1A1F800071E1179F1A4100012AFC +S315E630A960210100351F200071E00000541F400071C0 +S315E630A970E1179F1A1F600171E0179F1A2000002A1F +S315E630A980600000347AFFFF970500001421008052FC +S315E630A990E00000D0008005911EEBFF97FD7BC1A855 +S315E630A9A0C0035FD6FD7BBEA9FD030091A38300916C +S315E630A9B061CC1FB824008052E203002A400200D060 +S315E630A9C0012C42B9000080520623009420008052C2 +S315E630A9D064E1FF97FD7BC2A8C0035FD6FD7BBDA9C8 +S315E630A9E0FD030091F30B00F9F30301AA240080522C +S315E630A9F0A3B30091E203002A400200D0012C42B90B +S315E630AA00000080524E220094A02F40B9600200F931 +S315E630AA10F30B40F9FD7BC3A8C0035FD6FD7BB6A931 +S315E630AA20FD030091F35301A9F55B02A9F71B00F983 +S315E630AA30F40300AAF503012AF703022A1600805228 +S315E630AA405F00001402018052A1C30191E00314AA0B +S315E630AA505FECFF9701008052A0C30191EDEAFF97C4 +S315E630AA6001008052E00000F000A02E91E9EAFF975F +S315E630AA70E203152AA1630291E00314AAD8FFFF97F1 +S315E630AA80B31E0053E203132AA1C30191A04F40F946 +S315E630AA904FECFF9701008052A0C30191DDEAFF97A4 +S315E630AAA001008052E00000D000E00B91D9EAFF9732 +S315E630AAB0A13F0191A043019136EBFF97A283029124 +S315E630AAC05FEC1A3803008052A1C30191A04301918D +S315E630AAD066ECFF9780060035A03B41391F040071CE +S315E630AAE0610000549442358B35000014A1C34139D8 +S315E630AAF03FB80071200600543F780171610000547A +S315E630AB00944235CB2E000014731A1F537306001188 +S315E630AB101F00336BC900005421008052E00000D09C +S315E630AB2000E00291BBEAFF9725000014A1430291AB +S315E630AB30A0C30191D6EBFF97001C0053C00000344A +S315E630AB4021008052E00000D000E00291B1EAFF97A2 +S315E630AB501B000014E203152AA14B40F9E00314AAC0 +S315E630AB6091FFFF97FF060071A1010054E203152A13 +S315E630AB70A1630291E00314AA99FFFF97A04F40F92B +S315E630AB80A14B40F93F0000EBA00000542100805273 +S315E630AB90E00000D000000C919EEAFF979442358B98 +S315E630ABA00700001421008052E00000D000E0029158 +S315E630ABB098EAFF97020000143600805256F4FF34C6 +S315E630ABC0400200D0144001B9F35341A9F55B42A9DE +S315E630ABD0F71B40F9FD7BCAA8C0035FD6FD7BBCA94F +S315E630ABE0FD030091000080520E230094400200D00F +S315E630ABF0014041B9A0030191018C1FF869F3FF9733 +S315E630AC00001C00531F040071C1000054210080521D +S315E630AC10E00000D000E002917EEAFF9716000014CD +S315E630AC20A002003501008052E00000F000000B91F2 +S315E630AC3078EAFF9722008052A1630091400200D065 +S315E630AC40002C42B9C1EBFF9721008052A0630091F8 +S315E630AC5070EAFF9722008052E103022AA01F40F9EC +S315E630AC606FFFFF97410200D0204041B90004001142 +S315E630AC70204001B9FD7BC4A8C0035FD6FD7BBFA9E2 +S315E630AC80FD030091400200D00050433900101D12FA +S315E630AC901FE0007161000054D1FFFF9705000014F4 +S315E630ACA021008052E00000D00080059159EAFF97F6 +S315E630ACB0FD7BC1A8C0035FD6FD7BBBA9FD03009132 +S315E630ACC001008052E00000F000800B9151EAFF97D8 +S315E630ACD002018052A1430091400200D0000841F9BA +S315E630ACE0BBEBFF9721008052A043009149EAFF97DC +S315E630ACF001008052E00000F000E00B9145EAFF9754 +S315E630AD0082008052A1430091400200D0002842B929 +S315E630AD108EEBFF9721008052A04300913DEAFF97E4 +S315E630AD2001008052E00000F000400C9139EAFF97CE +S315E630AD3082008052A1430091400200D0003442B9ED +S315E630AD4082EBFF9721008052A043009131EAFF97CC +S315E630AD50FD7BC5A8C0035FD6FD7BBEA9FD0300918A +S315E630AD60F30B00F9F30300AA01008052E00000F08D +S315E630AD7000A00C9127EAFF970000805206000014E7 +S315E630AD80E103002A424B8B52424BAB72627A21B8D0 +S315E630AD900004001101FEBF121F00016B29FFFF54AC +S315E630ADA00000805214000014E103002A630A018B86 +S315E630ADB0627A61B8414B8B52414BAB725F00016BA5 +S315E630ADC080010054400200D0030801F9610040B921 +S315E630ADD0400200D0012802B9414B8B52414BAB724F +S315E630ADE0400200D0013402B9200080525A000014E5 +S315E630ADF00004001101FEBF121F00016B69FDFF540E +S315E630AE00E0018052BFEAFF9701008052E00000F091 +S315E630AE1000E00C91FFE9FF9700008052060000142F +S315E630AE20E103002AA2B49452A2B4B472627A21B88B +S315E630AE300004001101FEBF121F00016B29FFFF540B +S315E630AE400000805214000014E103002A630A018BE5 +S315E630AE50627A61B8A1B49452A1B4B4725F00016B60 +S315E630AE6080010054400200D0030801F9610040B980 +S315E630AE70400200D0012802B9A1B49452A1B4B4720A +S315E630AE80400200D0013402B920008052320000146C +S315E630AE900004001101FEBF121F00016B69FDFF546D +S315E630AEA0E001805297EAFF9701008052E00000F019 +S315E630AEB000200D91D7E9FF970000805201CF8A52E4 +S315E630AEC08146A27206000014E203002A617A22B8AD +S315E630AED0E2E300322100020B0004001102FEBF124B +S315E630AEE01F00026B29FFFF540000805201CF8A52C1 +S315E630AEF08146A27212000014E203002A630A028B2C +S315E630AF00627A62B83F00026B40010054400200D0DC +S315E630AF10030801F9620040B9400200D0022802B9BE +S315E630AF20400200D0013402B9200080520A000014F3 +S315E630AF30E2E300322100020B0004001102FEBF12EA +S315E630AF401F00026BA9FDFF54E00180526DEAFF97C0 +S315E630AF5000008052F30B40F9FD7BC2A8C0035FD6F2 +S315E630AF60FD7BBFA9FD03009121008052E00000F091 +S315E630AF7000600D91A7E9FF97400200D000DC40B9AA +S315E630AF8001E089521F00016B410E005421008052C8 +S315E630AF90E00000F000C00D919EE9FF970100805277 +S315E630AFA0E00000F000200E919AE9FF970000A2D269 +S315E630AFB08000C0F269FFFF976002003421008052BC +S315E630AFC0E00000F000A00E9192E9FF973BFFFF9775 +S315E630AFD001008052E00000F000C00E918DE9FF9747 +S315E630AFE063EBFF97001C0053800000344003805229 +S315E630AFF044EAFF97C20000144003805241EAFF97C5 +S315E630B0000500001421008052E00000D000400F9188 +S315E630B01080E9FF9701008052E00000D000600F9192 +S315E630B0207CE9FF97002080D2A000C0F24BFFFF9765 +S315E630B0306002003421008052E00000D000A00E917C +S315E630B04074E9FF971DFFFF9701008052E00000D0BC +S315E630B05000C00E916FE9FF9745EBFF97001C005352 +S315E630B060800000344003805226EAFF97A40000149D +S315E630B0704003805223EAFF970500001421008052F0 +S315E630B080E00000D000400F9162E9FF970100805260 +S315E630B090E00000D000E00F915EE9FF97002080D215 +S315E630B0A0C000C0F22DFFFF976002003421008052C7 +S315E630B0B0E00000D000A00E9156E9FF97FFFEFF971D +S315E630B0C001008052E00000D000C00E9151E9FF97B2 +S315E630B0D027EBFF97001C0053800000344003805274 +S315E630B0E008EAFF97860000144003805205EAFF9788 +S315E630B0F00500001421008052E00000D000400F9198 +S315E630B10044E9FF9701008052E00000D000601091DC +S315E630B11040E9FF97002080D2E000C0F20FFFFF97AC +S315E630B120E000003421008052E00000D000A00E910D +S315E630B13038E9FF97E1FEFF9771000014210080524F +S315E630B140E00000D000400F9132E9FF976C00001422 +S315E630B15001408A521F00016BC1060054210080521D +S315E630B160E00000D000E010912AE9FF970100805216 +S315E630B170E00000D000200E9126E9FF970000A2D22B +S315E630B1808000C0F2F5FEFF9760020034210080525F +S315E630B190E00000D000A00E911EE9FF97C7FEFF97AC +S315E630B1A001008052E00000D000C00E9119E9FF9709 +S315E630B1B0EFEAFF97001C00538000003440038052CC +S315E630B1C0D0E9FF974E00001440038052CDE9FF9751 +S315E630B1D00500001421008052E00000D000400F91B7 +S315E630B1E00CE9FF9701008052E00000D000E00F91B5 +S315E630B1F008E9FF97002080D2C000C0F2D7FEFF975D +S315E630B200E000003421008052E00000D000A00E912C +S315E630B21000E9FF97A9FEFF97390000142100805216 +S315E630B220E00000D000400F91FAE8FF9734000014B2 +S315E630B23001808A521F00016B0103005421008052BF +S315E630B240E00000D000401191F2E8FF97010080520D +S315E630B250E00000D000200E91EEE8FF970000A2D283 +S315E630B2608000C0F2BDFEFF97E00000342100805238 +S315E630B270E00000D000A00E91E6E8FF978FFEFF973C +S315E630B2801F00001421008052E00000D000400F91EC +S315E630B290E0E8FF971A00001401008B521F00016B9D +S315E630B2A0E102005421008052E00000D00080119186 +S315E630B2B0D8E8FF9701008052E00000D000200E91DA +S315E630B2C0D4E8FF970000A2D28000C0F2A3FEFF9733 +S315E630B2D0E000003421008052E00000D000A00E915C +S315E630B2E0CCE8FF9775FEFF970500001421008052E3 +S315E630B2F0E00000D000400F91C6E8FF97FD7BC1A87D +S315E630B300C0035FD6FD7BBFA9FD03009121008052C5 +S315E630B310E00000D000600D91BEE8FF97400200B035 +S315E630B32000DC40B901E089521F00016B211D005453 +S315E630B33021008052E00000D000C00D91B5E8FF97BD +S315E630B34001008052E00000D000200E91B1E8FF9770 +S315E630B3500000A2D28000C0F280FEFF976002003481 +S315E630B36021008052E00000D000A00E91A9E8FF97B8 +S315E630B37052FEFF9701008052E00000D000C01191E6 +S315E630B380A4E8FF977AEAFF97001C00538000003462 +S315E630B390400380525BE9FF9759010014400380521F +S315E630B3A058E9FF970500001421008052E00000D0EE +S315E630B3B000400F9197E8FF9701008052E00000D0F9 +S315E630B3C00020129193E8FF970000A8D28000C0F2E1 +S315E630B3D062FEFF976002003421008052E00000D022 +S315E630B3E000A00E918BE8FF9734FEFF97010080525E +S315E630B3F0E00000D000C00E9186E8FF975CEAFF9742 +S315E630B400001C005380000034400380523DE9FF972C +S315E630B4103B010014400380523AE9FF9705000014D9 +S315E630B42021008052E00000D000400F9179E8FF9786 +S315E630B43001008052E00000D000600F9175E8FF977A +S315E630B440002080D2A000C0F244FEFF9760020034AE +S315E630B45021008052E00000D000A00E916DE8FF9703 +S315E630B46016FEFF9701008052E00000D000C0119131 +S315E630B47068E8FF973EEAFF97001C005380000034E9 +S315E630B480400380521FE9FF971D01001440038052A6 +S315E630B4901CE9FF970500001421008052E00000D039 +S315E630B4A000400F915BE8FF9701008052E00000D044 +S315E630B4B000A0129157E8FF970000A8D2A000C0F28C +S315E630B4C026FEFF976002003421008052E00000D06D +S315E630B4D000A00E914FE8FF97F8FDFF9701008052E6 +S315E630B4E0E00000D000C00E914AE8FF9720EAFF97C9 +S315E630B4F0001C0053800000344003805201E9FF9778 +S315E630B500FF00001440038052FEE8FF970500001462 +S315E630B51021008052E00000D000400F913DE8FF97D1 +S315E630B52001008052E00000D000E00F9139E8FF9745 +S315E630B530002080D2C000C0F208FEFF9760020034D9 +S315E630B54021008052E00000D000A00E9131E8FF974E +S315E630B550DAFDFF9701008052E00000D000C011917D +S315E630B5602CE8FF9702EAFF97001C00538000003470 +S315E630B57040038052E3E8FF97E1000014400380522F +S315E630B580E0E8FF970500001421008052E00000D085 +S315E630B59000400F911FE8FF9701008052E00000D08F +S315E630B5A0002013911BE8FF970000A8D2C000C0F236 +S315E630B5B0EAFDFF976002003421008052E00000D0B9 +S315E630B5C000A00E9113E8FF97BCFDFF97010080526D +S315E630B5D0E00000D000C00E910EE8FF97E4E9FF9751 +S315E630B5E0001C00538000003440038052C5E8FF97C4 +S315E630B5F0C300001440038052C2E8FF9705000014EA +S315E630B60021008052E00000D000400F9101E8FF971C +S315E630B61001008052E00000D000601091FDE7FF9710 +S315E630B620002080D2E000C0F2CCFDFF974002003425 +S315E630B63021008052E00000D000A00E91F5E7FF979A +S315E630B6409EFDFF9701008052E00000D000C01191C8 +S315E630B650F0E7FF97C6E9FF97001C005380000034F9 +S315E630B66040038052A7E8FF97A500001440038052B6 +S315E630B670A4E8FF9721008052E00000D000400F9109 +S315E630B680E4E7FF9701008052E00000D000A0139176 +S315E630B690E0E7FF970000A8D2E000C0F2AFFDFF97E3 +S315E630B6A0E000003421008052E00000D000A00E9188 +S315E630B6B0D8E7FF9781FDFF9791000014210080526D +S315E630B6C0E00000D000400F91D2E7FF978C000014DF +S315E630B6D001408A521F00016B410E00542100805210 +S315E630B6E0E00000D000E01091CAE7FF9701008052F3 +S315E630B6F0E00000D000200E91C6E7FF970000A2D208 +S315E630B7008000C0F295FDFF9760020034210080523A +S315E630B710E00000D000A00E91BEE7FF9767FDFF97E9 +S315E630B72001008052E00000D000C01191B9E7FF97E2 +S315E630B7308FE9FF97001C00538000003440038052A7 +S315E630B74070E8FF976E000014400380526DE8FF976D +S315E630B7500500001421008052E00000D000400F9131 +S315E630B760ACE7FF9701008052E00000D0002014914C +S315E630B770A8E7FF970000B0D28000C0F277FDFF97CA +S315E630B7806002003421008052E00000D000A00E9125 +S315E630B790A0E7FF9749FDFF9701008052E00000D011 +S315E630B7A000C00E919BE7FF9771E9FF97001C0053A7 +S315E630B7B0800000344003805252E8FF975000001470 +S315E630B7C0400380524FE8FF9705000014210080526F +S315E630B7D0E00000D000400F918EE7FF9701008052DF +S315E630B7E0E00000D000E00F918AE7FF97002080D294 +S315E630B7F0C000C0F259FDFF97600200342100805246 +S315E630B800E00000D000A00E9182E7FF972BFDFF9770 +S315E630B81001008052E00000D000C011917DE7FF972D +S315E630B82053E9FF97001C00538000003440038052F2 +S315E630B83034E8FF97320000144003805231E8FF9730 +S315E630B8400500001421008052E00000D000400F9140 +S315E630B85070E7FF9701008052E00000D000A0149117 +S315E630B8606CE7FF970000B0D2C000C0F23BFDFF9711 +S315E630B870E000003421008052E00000D000A00E91B6 +S315E630B88064E7FF970DFDFF971D00001421008052F7 +S315E630B890E00000D000400F915EE7FF9718000014F5 +S315E630B8A001808A521F00016B41010054210080520B +S315E630B8B0E00000D00040119156E7FF972100805214 +S315E630B8C0E00000D00020159152E7FF970C000014F7 +S315E630B8D001008B521F00016B21010054210080527A +S315E630B8E0E00000D0008011914AE7FF9721008052B0 +S315E630B8F0E00000D00000169146E7FF97FD7BC1A831 +S315E630B900C0035FD60100805202CF8A528246A272C7 +S315E630B91006000014E303012A027823B8E3E3003293 +S315E630B9204200030B2104001103FEBF123F00036BF6 +S315E630B93029FFFF540100805202CF8A528246A27214 +S315E630B94012000014E303012A0408038B037863B874 +S315E630B9505F00036B40010054400200B0040801F971 +S315E630B960810040B9400200B0012802B9400200B079 +S315E630B970023402B920008052C0035FD6E3E30032D8 +S315E630B9804200030B2104001103FEBF123F00036B96 +S315E630B990A9FDFF5400008052C0035FD6FD7BBFA9E8 +S315E630B9A0FD030091D8FFFF97E00000342100805276 +S315E630B9B0E00000D00080169116E7FF97BFFCFF97B0 +S315E630B9C020008052FD7BC1A8C0035FD6FD7BBBA9B4 +S315E630B9D0FD030091F35301A9F40300AA2100805236 +S315E630B9E0E00000D000C016910AE7FF973300805298 +S315E630B9F02B00001401008052E00000D000201791A1 +S315E630BA0004E7FF97A1BF0091A0C3009131E7FF9706 +S315E630BA10A24301915FEC1D3803008052A1030191E8 +S315E630BA20A0C3009191E8FF9720030035A0BB4039CB +S315E630BA301F040071400300541F0C0071C900005406 +S315E630BA4021008052E00000D000E00191F1E6FF9758 +S315E630BA5013000014A1A30091A0030191DFE7FF973D +S315E630BA60001C0053C000003421008052E00000D0B4 +S315E630BA7000E00191E7E6FF9709000014A02B40B9F4 +S315E630BA8080020039130080520500001421008052EE +S315E630BA90E00000D000E00191DEE6FF97D3FAFF350D +S315E630BAA0F35341A9FD7BC5A8C0035FD6FD7BB7A995 +S315E630BAB0FD030091F30B00F900148052410200B009 +S315E630BAC0203002B9410200B0202C02B910DBFF97D4 +S315E630BAD001008052E00000D000801791CDE6FF9756 +S315E630BAE00000805273DBFF9701008052E00000D001 +S315E630BAF000C01791C7E6FF9722008052A1A30091B6 +S315E630BB00400200B00050433910E8FF9701008052FA +S315E630BB10A0A30091BFE6FF9721008052E00000D057 +S315E630BB2000202991BBE6FF9701008052E00000D065 +S315E630BB3000E01791B7E6FF978DE8FF97001C0053B4 +S315E630BB40C000003421008052E00000B000A02B9106 +S315E630BB50B0E6FF976E00001421008052E00000B098 +S315E630BB6000A02B91ABE6FF97F30000D073623F91CE +S315E630BB7021008052E00313AAA6E6FF972100805201 +S315E630BB80E00000D000601891A2E6FF9721008052CF +S315E630BB90E00000D000E018919EE6FF972100805243 +S315E630BBA0E00000D0006019919AE6FF9721008052B6 +S315E630BBB0E00000D000E0199196E6FF97210080522A +S315E630BBC0E00000D000601A9192E6FF97210080529D +S315E630BBD0E00000D000E01A918EE6FF972100805211 +S315E630BBE0E00000D000601B918AE6FF972100805284 +S315E630BBF0E00000D000E01B9186E6FF9721008052F8 +S315E630BC00E00313AA83E6FF9733008052260000143A +S315E630BC1001008052E00000D000601C917DE6FF977F +S315E630BC20A13F0191A0430191AAE6FF97A04341398E +S315E630BC3000C000511F24007168030054A100009033 +S315E630BC4021401A9120486038610000102088208B08 +S315E630BC5000001FD6A09F00915DFFFF9711000014EC +S315E630BC60BF9F00390F00001400018052A09F0039B3 +S315E630BC700C00001400028052A09F0039090000141F +S315E630BC8000048052A09F0039060000140007805257 +S315E630BC90A09F003903000014000B8052A09F0039A4 +S315E630BCA01300805273FBFF35A09F4039BDDAFF970C +S315E630BCB097DAFF9701008052E00000D000801791B6 +S315E630BCC054E6FF9700008052FADAFF970100805279 +S315E630BCD0E00000D000C017914EE6FF972200805272 +S315E630BCE0A1A30091400200B00050433997E7FF9791 +S315E630BCF001008052A0A3009146E6FF9721008052CC +S315E630BD00E00000D00020299142E6FF97F30B40F998 +S315E630BD10FD7BC9A8C0035FD6030090D203CEBCF242 +S315E630BD20610000B9810090D201CEBCF2200000B9A4 +S315E630BD30000190D200CEBCF2020000B921818A52CF +S315E630BD400102A07200100091010000B9C0035FD66F +S315E630BD50810190D201CEBCF2220040B900828A52ED +S315E630BD600002A0724000000A200000B9C0035FD688 +S315E630BD70011080D201CEBCF2200040B9000000327C +S315E630BD80200000B9C0035FD621008052000C80D275 +S315E630BD9000CEBCF201000079C0035FD6800190D2B6 +S315E630BDA000CEBCF2000040B960010836810190D27F +S315E630BDB001CEBCF2200040B900781E12200000B950 +S315E630BDC0000C80D200CEBCF21F0000790000805213 +S315E630BDD0C0035FD640FEFF36810190D201CEBCF27B +S315E630BDE0200040B900780012200000B920008052C9 +S315E630BDF0C0035FD6030090D223F8BFF2610000B9E4 +S315E630BE00810090D221F8BFF2200000B9000190D22D +S315E630BE1020F8BFF2020000B921818A520102A072EF +S315E630BE2000100091010000B9C0035FD6810190D2BF +S315E630BE3021F8BFF2220040B900818A520002A07290 +S315E630BE404000000A200000B9C0035FD6011080D258 +S315E630BE5021F8BFF2200040B900000032200000B9D8 +S315E630BE60C0035FD621008052000C80D220F8BFF2A4 +S315E630BE7001000079C0035FD6800190D220F8BFF288 +S315E630BE80000040B960010836810190D221F8BFF250 +S315E630BE90200040B900781E12200000B9000C80D28E +S315E630BEA020F8BFF21F00007900008052C0035FD64B +S315E630BEB040FEFF36810190D221F8BFF2200040B92C +S315E630BEC000780012200000B920008052C0035FD609 +S315E630BED020008052011080D221F8BFF2200000B94E +S315E630BEE0810390D221F8BFF202009052220000B9C7 +S315E630BEF0020C80D222F8BFF24000007983088052E5 +S315E630BF0003FEBF72020090D222F8BFF2430000B9B8 +S315E630BF1083038052A3D8BC7242100091430000B925 +S315E630BF2042100091400000B9000094D220F8BFF2EA +S315E630BF301F0000B9001000911F0000B90204A0529C +S315E630BF4000100091020000B900108052200000B9BE +S315E630BF502100945221F8BF72000A90D220F8BFF23F +S315E630BF60010000B9218180520140A672800190D24B +S315E630BF7020F8BFF2010000B9C0035FD6421C005379 +S315E630BF80631C0053040040397F00246BE10D0054F6 +S315E630BF900504009102000039040440397F00246B21 +S315E630BFA0A109005405080091020400390408403915 +S315E630BFB07F00246B41090054050C009102080039D4 +S315E630BFC0040C40397F00246BE108005405100091DB +S315E630BFD0020C0039041040397F00246B8108005486 +S315E630BFE00514009102100039041440397F00246BA1 +S315E630BFF02108005405180091021400390418403916 +S315E630C0007F00246BC1070054051C009102180039E5 +S315E630C010041C40397F00246B6107005405200091EB +S315E630C020021C0039042040397F00246B0107005496 +S315E630C0300524009102200039042440397F00246B20 +S315E630C040A106005405280091022400390428403917 +S315E630C0507F00246B41060054052C009102280039F6 +S315E630C060042C40397F00246BE105005405300091FD +S315E630C070022C0039043040397F00246B81050054A8 +S315E630C0800534009102300039043440397F00246BA0 +S315E630C0902105005405380091023400390438403918 +S315E630C0A07F00246BC1040054053C00910238003908 +S315E630C0B0043C40397F00246B61040054044000910F +S315E630C0C0023C00399F0001EB62050054E00304AA06 +S315E630C0D0ADFFFF17E00305AA1C000014E00305AA2E +S315E630C0E01A000014E00305AA18000014E00305AAB6 +S315E630C0F016000014E00305AA14000014E00305AAAE +S315E630C10012000014E00305AA10000014E00305AAA5 +S315E630C1100E000014E00305AA0C000014E00305AA9D +S315E630C1200A000014E00305AA08000014E00305AA95 +S315E630C13006000014E00305AA04000014E00305AA8D +S315E630C14002000014E00305AA41020090201C01F922 +S315E630C15000004039001C005341020090201001F9DE +S315E630C160631C005340020090030401F9200080521C +S315E630C170C0035FD600008052C0035FD6421C005330 +S315E630C180020000390204003902080039020C00398F +S315E630C190021000390214003902180039021C00393F +S315E630C1A0022000390224003902280039022C0039EF +S315E630C1B00230003902340039023800390340009142 +S315E630C1C0023C0039E00303AA7F0001EBA3FDFF54EE +S315E630C1D000008052C0035FD6421C00530304009130 +S315E630C1E0040040395F00246B2108005403080091AF +S315E630C1F0040440395F00246BA1070054030C009118 +S315E630C200040840395F00246B21070054031000917F +S315E630C210040C40395F00246BA106005403140091E8 +S315E630C220041040395F00246B210600540318009150 +S315E630C230041440395F00246BA1050054031C0091B9 +S315E630C240041840395F00246B210500540320009121 +S315E630C250041C40395F00246BA1040054032400918A +S315E630C260042040395F00246B2104005403280091F2 +S315E630C270042440395F00246BA1030054032C00915B +S315E630C280042840395F00246B2103005403300091C3 +S315E630C290042C40395F00246BA1020054033400912C +S315E630C2A0043040395F00246B210200540338009194 +S315E630C2B0043440395F00246BA1010054033C0091FD +S315E630C2C0043840395F00246B210100540340009165 +S315E630C2D0003C40395F00206BA10000547F0001EB43 +S315E630C2E0E2010054E00303AABDFFFF17610400D163 +S315E630C2F040020090011C01F960F05F38001C0053E3 +S315E630C30041020090201001F9421C00534002009091 +S315E630C310020401F920008052C0035FD60000805245 +S315E630C320C0035FD6421C005343040011631C00531E +S315E630C3300200003944080011841C00530304003916 +S315E630C340430C0011631C00530408003944100011F5 +S315E630C350841C0053030C003943140011631C00534C +S315E630C3600410003944180011841C005303140039B4 +S315E630C370431C0011631C0053041800394420001195 +S315E630C380841C0053031C003943240011631C0053FC +S315E630C3900420003944280011841C00530324003954 +S315E630C3A0432C0011631C0053042800394430001135 +S315E630C3B0841C0053032C003943340011631C0053AC +S315E630C3C00430003944380011841C005303340039F4 +S315E630C3D0433C0011631C0053043800390440009195 +S315E630C3E042400011421C0053033C0039E00304AAE4 +S315E630C3F09F0001EBA3F9FF5400008052C0035FD6DD +S315E630C400421C0053060400910400403943040011EF +S315E630C410631C00535F00246BC10D0054060800917F +S315E630C4200504403944080011841C00537F00256B0F +S315E630C430210B0054060C009105084039430C0011D7 +S315E630C440631C00539F00256B410C00540610009187 +S315E630C450050C403944100011841C00537F00256BCF +S315E630C460E1090054061400910510403943140011D1 +S315E630C470631C00539F00256BC10A005406180091D1 +S315E630C4800514403944180011841C00537F00256B8F +S315E630C490A1080054061C009105184039431C0011CA +S315E630C4A0631C00539F00256B41090054062000911A +S315E630C4B0051C403944200011841C00537F00256B4F +S315E630C4C061070054062400910520403943240011C3 +S315E630C4D0631C00539F00256BC10700540628009164 +S315E630C4E00524403944280011841C00537F00256B0F +S315E630C4F021060054062C009105284039432C0011BC +S315E630C500631C00539F00256B4106005406300091AC +S315E630C510052C403944300011841C00537F00256BCE +S315E630C520E1040054063400910530403943340011B5 +S315E630C530631C00539F00256BC104005406380091F6 +S315E630C5400534403944380011841C00537F00256B8E +S315E630C550A1030054063C009105384039433C0011AE +S315E630C560631C00539F00256B41030054064000913F +S315E630C570003C403942400011421C00537F00206B9C +S315E630C58061020054DF0001EBE2030054E00306AA41 +S315E630C5909DFFFF17E303042A0E000014E303042A83 +S315E630C5A00C000014E303042A0A000014E303042A09 +S315E630C5B008000014E303042A06000014E303042A01 +S315E630C5C004000014E303042A02000014E303022AFB +S315E630C5D0C10400D16304005140020090011C01F908 +S315E630C5E0C0F05F38001C005341020090201001F97C +S315E630C5F0631C005340020090030401F92000805288 +S315E630C600C0035FD600008052C0035FD6400200907A +S315E630C61001DC40B900E089523F00006B610100540D +S315E630C6204002009000D040B91F3C0071E80000544B +S315E630C630014C80520100B072800F80D200C4BDF248 +S315E630C640010000B906000014014C80526100B07258 +S315E630C650800F80D200C4BDF2010000B901609E525F +S315E630C660E13FA07200C4BDD2010000B9012080527C +S315E630C670E103A07200300091010000B9810DA052AD +S315E630C68000100091010000B921008052001000919F +S315E630C690010000B901E099524100A07200200091F4 +S315E630C6A0010000B9E100805200F00091010000B9C6 +S315E630C6B0001000911F0000B9C0035FD6400200901B +S315E630C6C001DC40B900E089523F00006B610100545D +S315E630C6D04002009000D040B91F3C0071E80000549B +S315E630C6E0014C80520100B072800F80D200C4BDF298 +S315E630C6F0010000B906000014014C80526100B072A8 +S315E630C700800F80D200C4BDF2010000B901609E52AE +S315E630C710E13FA07200C4BDD2010000B901208052CB +S315E630C720E103A07200300091010000B98101A05208 +S315E630C73000100091010000B92100805200100091EE +S315E630C740010000B901E0995200200091010000B9DC +S315E630C750E100805200F00091010000B9001000912E +S315E630C7601F0000B9C0035FD681288252212AA672FD +S315E630C770001080D200C4BDF2010000B9C0035FD616 +S315E630C780A12A8052001780D200C4BDF2010000B95A +S315E630C790C0035FD64002009001DC40B900E0895222 +S315E630C7A03F00006B610100544002009000D040B972 +S315E630C7B01F3C0071E8000054014C80520100B07213 +S315E630C7C0800F80D200C4BDF2010000B90600001425 +S315E630C7D0014C80526100B072800F80D200C4BDF247 +S315E630C7E0010000B901609E52E13FA07200C4BDD29D +S315E630C7F0010000B901208052E103A07200300091B9 +S315E630C800010000B96101A05200100091010000B9A3 +S315E630C810001000911F0000B9001000911F0000B90A +S315E630C82001E0985200100091010000B9E100805213 +S315E630C83000F00091010000B9001000911F0000B928 +S315E630C840C0035FD6FD7BBFA9FD0300911F80027151 +S315E630C850E00000541F400171E00000541FA0007153 +S315E630C860E000005400008052060000142002805298 +S315E630C870040000146002805202000014E002805286 +S315E630C880E203202A012081D2A1C2BCF2220000B9FD +S315E630C890014780D2A1C2BCF2200000B9006A9852A4 +S315E630C8A015E5FF97FD7BC1A8C0035FD61F800271F1 +S315E630C8B0E00000541F400171E00000541FA00071F3 +S315E630C8C0E000005400008052060000142002805238 +S315E630C8D004000014200080520200001460008052EA +S315E630C8E0E203202A012081D2A1C2BCF2220000B99D +S315E630C8F0014780D2A1C2BCF2200000B9C0035FD6A0 +S315E630C900FD7BBFA9FD0300911F80027140010054F3 +S315E630C9101F140271600100541F40017180010054FA +S315E630C9201FA00071A0010054020080520000805220 +S315E630C9300C0000140200805280198052090000145F +S315E630C94002008052A0068052060000142200805271 +S315E630C95080198052030000144200805280198052BA +S315E630C960011580D201C4BDF2220000B99F3F03D53E +S315E630C970E203202A012081D2A1C2BCF2220000B90C +S315E630C980014780D2A1C2BCF2200000B9006A9852B3 +S315E630C990D9E4FF97FD7BC1A8C0035FD601C4BDD2FB +S315E630C9A0200040B9001C1032200000B9C0035FD623 +S315E630C9B0FD7BBEA9FD030091F30B00F9F303002AD4 +S315E630C9C04002009000DC40B901808A521F00016BBC +S315E630C9D0A1000054F2FFFF97E003132AC9FFFF9741 +S315E630C9E00900001401008B521F00016B81000054D0 +S315E630C9F0E003132AAEFFFF9703000014E003132A81 +S315E630CA0091FFFF97F30B40F9FD7BC2A8C0035FD6D3 +S315E630CA10000980D200C4BDF2000040B9A0FF073657 +S315E630CA20C0035FD6FD7BBEA9FD030091F30B00F98B +S315E630CA30F30300AA4002009001DC40B900E08952D7 +S315E630CA403F00006B610100544002009000D040B9CF +S315E630CA501F3C0071E8000054014C80520100B07270 +S315E630CA60800F80D200C4BDF2010000B90600001482 +S315E630CA70014C80526100B072800F80D200C4BDF2A4 +S315E630CA80010000B901609E52E13FB07200C4BDD2EA +S315E630CA90010000B9A106A05200900091010000B94C +S315E630CAA0000001911F0000B901018852000680D2CC +S315E630CAB000C4BDF2010000B9A1008052000480D264 +S315E630CAC000C4BDF2010000B9D2FFFF97000780D25D +S315E630CAD000C4BDF200004039001C0053600200B9C4 +S315E630CAE0F30B40F9FD7BC2A8C0035FD6FD7BBFA939 +S315E630CAF0FD030091211C1853001C00532000002A28 +S315E630CB004102009022DC40B901E089525F00016BB8 +S315E630CB10610100544102009021D040B93F3C00719A +S315E630CB20E8000054024C80520200B072810F80D287 +S315E630CB3001C4BDF2220000B906000014024C805250 +S315E630CB406200B072810F80D201C4BDF2220000B914 +S315E630CB5002609E52E23FB07201C4BDD2220000B9F5 +S315E630CB602200A05221900091220000B921000191C5 +S315E630CB703F0000B982018852010680D201C4BDF277 +S315E630CB80220000B9214000912000007961008052F0 +S315E630CB90000480D200C4BDF2010000B99DFFFF97C4 +S315E630CBA04002009001DC40B900E089523F00006B5C +S315E630CBB0410100544002009000D040B91F3C00715C +S315E630CBC0C8000054014E8052800F80D200C4BDF2B8 +S315E630CBD0010000B906000014014E80526100A072D1 +S315E630CBE0800F80D200C4BDF2010000B921608052C8 +S315E630CBF0E13FA072800180D200C4BDF2010000B9E7 +S315E630CC00FD7BC1A8C0035FD6FD7BBDA9FD030091C0 +S315E630CC10F35301A9F55B02A9001C0053361C0053F9 +S315E630CC204102009022DC40B901E089525F00016B97 +S315E630CC30610100544102009021D040B93F3C007179 +S315E630CC40E8000054024C80520200B072810F80D266 +S315E630CC5001C4BDF2220000B906000014024C80522F +S315E630CC606200B072810F80D201C4BDF2220000B9F3 +S315E630CC7002609E52E23FB07201C4BDD2220000B9D4 +S315E630CC802200A05221900091220000B921000191A4 +S315E630CC903F0000B9150680D215C4BDF201018852AF +S315E630CCA0A10200B9140880D214C4BDF2800200395C +S315E630CCB0130480D213C4BDF260208052600200B9FC +S315E630CCC054FFFF9700018052A00200B99602003960 +S315E630CCD060008052600200B94EFFFF972100805215 +S315E630CCE006000014000980D200C4BDF2000040B947 +S315E630CCF0400008370100805261FFFF354002009060 +S315E630CD0001DC40B900E089523F00006B4101005436 +S315E630CD104002009000D040B91F3C0071C800005474 +S315E630CD20014E8052800F80D200C4BDF2010000B9B8 +S315E630CD3006000014014E80526100A072800F80D248 +S315E630CD4000C4BDF2010000B921608052E13FA07215 +S315E630CD50800180D200C4BDF2010000B9F35341A987 +S315E630CD60F55B42A9FD7BC3A8C0035FD6FD7BBFA9B1 +S315E630CD70FD0300914102009022DC40B901E0895280 +S315E630CD805F00016B610100544102009021D040B949 +S315E630CD903F3C0071E8000054024C80520200B0720B +S315E630CDA0810F80D201C4BDF2220000B9060000141C +S315E630CDB0024C80526200B072810F80D201C4BDF25D +S315E630CDC0220000B902609E52E23FB07201C4BDD283 +S315E630CDD0220000B9821BA05221900091220000B9B0 +S315E630CDE021100091200000B9800C80D200C4BDF23B +S315E630CDF01F0000B901E08952000680D200C4BDF2B8 +S315E630CE00010000B921008052000480D200C4BDF290 +S315E630CE10010000B9FFFEFF97FD7BC1A8C0035FD6D0 +S315E630CE20FD7BBFA9FD0300914102009022DC40B9AB +S315E630CE3001E089525F00016B6101005441020090C6 +S315E630CE4021D040B93F3C0071E8000054024C805294 +S315E630CE500200B072810F80D201C4BDF2220000B961 +S315E630CE6006000014024C80526200B072810F80D206 +S315E630CE7001C4BDF2220000B902609E52E23FB072B2 +S315E630CE8001C4BDD2220000B92204A05221900091FD +S315E630CE90220000B921100091200000B9800C80D222 +S315E630CEA000C4BDF21F0000B901E08952000680D207 +S315E630CEB000C4BDF2010000B921008052000480D2E0 +S315E630CEC000C4BDF2010000B9D2FEFF97FD7BC1A8D2 +S315E630CED0C0035FD623608052E33FA072820180D2E0 +S315E630CEE002C4BDF2430000B94202009043DC40B9C9 +S315E630CEF002E089527F00026B8101005442020090C3 +S315E630CF0042D040B95F3C007108010054834E8052EE +S315E630CF100300B072820F80D202C4BDF2430000B97C +S315E630CF20020080D20D000014834E80526300B07248 +S315E630CF30820F80D202C4BDF2430000B9F9FFFF1773 +S315E630CF40E303012A646862B8030090D203C4BDF2F3 +S315E630CF50446823B8421000915FFC03F129FFFF5481 +S315E630CF60FD7BBFA9FD03009102609E52E23FB0729F +S315E630CF7001C4BDD2220000B94202A05221900091EE +S315E630CF80220000B921100091200000B9800C80D231 +S315E630CF9000C4BDF21F0000B9E1E18952000680D235 +S315E630CFA000C4BDF2010000B961008052000480D2AF +S315E630CFB000C4BDF2010000B996FEFF97400200902C +S315E630CFC001DC40B900E089523F00006B4101005474 +S315E630CFD04002009000D040B91F3C0071C8000054B2 +S315E630CFE0614E8052800F80D200C4BDF2010000B996 +S315E630CFF006000014614E80526100A072800F80D226 +S315E630D00000C4BDF2010000B921608052E13FA07252 +S315E630D010800180D200C4BDF2010000B9FD7BC1A813 +S315E630D020C0035FD623608052E33FA072820180D28E +S315E630D03002C4BDF2430000B9220200F043DC40B937 +S315E630D04002E089527F00026B81010054220200F031 +S315E630D05042D040B95F3C007108010054834E80529D +S315E630D0600300B072820F80D202C4BDF2430000B92B +S315E630D070020080D20D000014834E80526300B072F7 +S315E630D080820F80D202C4BDF2430000B9F9FFFF1722 +S315E630D090E303012A646862B8030090D203C4BDF2A2 +S315E630D0A0446823B8421000915FFC03F129FFFF5430 +S315E630D0B0FD7BBFA9FD03009102609E52E23FB0724E +S315E630D0C001C4BDD2220000B94200A052219000919F +S315E630D0D0220000B921100091200000B9800C80D2E0 +S315E630D0E000C4BDF21F0000B9E1E18852000680D2E5 +S315E630D0F000C4BDF2010000B961008052000480D25E +S315E630D10000C4BDF2010000B942FEFF97200200F0EE +S315E630D11001DC40B900E089523F00006B4101005422 +S315E630D120200200F000D040B91F3C0071C800005420 +S315E630D130614E8052800F80D200C4BDF2010000B944 +S315E630D14006000014614E80526100A072800F80D2D4 +S315E630D15000C4BDF2010000B921608052E13FA07201 +S315E630D160800180D200C4BDF2010000B9FD7BC1A8C2 +S315E630D170C0035FD6FD7BBFA9FD030091220200F016 +S315E630D18043DC40B902E089527F00026B610100540C +S315E630D190220200F042D040B95F3C0071E80000540C +S315E630D1A0034C80520300B072820F80D202C4BDF2C5 +S315E630D1B0430000B906000014034C80526300B07297 +S315E630D1C0820F80D202C4BDF2430000B903609E529C +S315E630D1D0E33FB07202C4BDD2430000B94302A05267 +S315E630D1E042900091430000B942100091400000B9E8 +S315E630D1F0800C80D200C4BDF21F0000B9E2E189524C +S315E630D200000680D200C4BDF2020000B900400091AB +S315E630D210010000B961008052000480D200C4BDF23C +S315E630D220010000B9FBFDFF97200200F001DC40B9B2 +S315E630D23000E089523F00006B41010054200200F0C5 +S315E630D24000D040B91F3C0071C8000054614E805290 +S315E630D250800F80D200C4BDF2010000B9060000148A +S315E630D260614E80526100A072800F80D200C4BDF25A +S315E630D270010000B921608052E13FA072800180D280 +S315E630D28000C4BDF2010000B9FD7BC1A8C0035FD67C +S315E630D290FD7BBDA9FD030091F35301A9F51300F912 +S315E630D2A0F40301AAF503022A210200F022DC40B992 +S315E630D2B001E089525F00016B61010054210200F002 +S315E630D2C021D040B93F3C0071E8000054024C805210 +S315E630D2D00200B072810F80D201C4BDF2220000B9DD +S315E630D2E006000014024C80526200B072810F80D282 +S315E630D2F001C4BDF2220000B902609E52E23FB0722E +S315E630D30001C4BDD2220000B94202A052219000915A +S315E630D310220000B921100091200000B9800C80D29D +S315E630D32000C4BDF21F0000B9E1E18952000680D2A1 +S315E630D33000C4BDF2010000B9810240B90040009157 +S315E630D340010000B9BF060071C10000546100805289 +S315E630D350000480D200C4BDF2010000B90500001415 +S315E630D36061208052000480D200C4BDF2010000B9CB +S315E630D370A8FDFF9794120091BF0600718003005412 +S315E630D380E1018052000680D200C4BDF2010000B948 +S315E630D3903300805214000014810240B9000880D26E +S315E630D3A000C4BDF2010000B9A00600517F02006B51 +S315E630D3B0C100005461008052000480D200C4BDF240 +S315E630D3C0010000B90500001461208052000480D2C5 +S315E630D3D000C4BDF2010000B98EFDFF9794120091AC +S315E630D3E0730600117F02156B83FDFF5421008052D0 +S315E630D3F006000014000980D200C4BDF2000040B930 +S315E630D400400008370100805261FFFF35200200F008 +S315E630D41001DC40B900E089523F00006B410100541F +S315E630D420200200F000D040B91F3C0071C80000541D +S315E630D430614E8052800F80D200C4BDF2010000B941 +S315E630D44006000014614E80526100A072800F80D2D1 +S315E630D45000C4BDF2010000B921608052E13FA072FE +S315E630D460800180D200C4BDF2010000B9F35341A970 +S315E630D470F51340F9FD7BC3A8C0035FD6FD7BBFA994 +S315E630D480FD030091220200F043DC40B902E0895206 +S315E630D4907F00026B61010054220200F042D040B9AF +S315E630D4A05F3C0071E8000054034C80520300B072D2 +S315E630D4B0820F80D202C4BDF2430000B906000014E2 +S315E630D4C0034C80526300B072820F80D202C4BDF242 +S315E630D4D0430000B903609E52E33FB07202C4BDD248 +S315E630D4E0430000B98306A05242900091430000B94A +S315E630D4F042100091400000B9800C80D200C4BDF2E3 +S315E630D5001F0000B9E2E189524200A072000680D2DD +S315E630D51000C4BDF2020000B900400091010000B936 +S315E630D52061008052000480D200C4BDF2010000B929 +S315E630D53038FDFF97200200F001DC40B900E0895261 +S315E630D5403F00006B41010054200200F000D040B9A4 +S315E630D5501F3C0071C8000054614E8052800F80D265 +S315E630D56000C4BDF2010000B906000014614E8052D7 +S315E630D5706100A072800F80D200C4BDF2010000B90E +S315E630D58021608052E13FA072800180D200C4BDF2B4 +S315E630D590010000B9FD7BC1A8C0035FD6FD7BBEA9FD +S315E630D5A0FD030091F30B00F9F30301AA210200F023 +S315E630D5B022DC40B901E089525F00016B610100541B +S315E630D5C0210200F021D040B93F3C0071E80000541A +S315E630D5D0024C80520200B072810F80D201C4BDF295 +S315E630D5E0220000B906000014024C80526200B07286 +S315E630D5F0810F80D201C4BDF2220000B902609E528C +S315E630D600E23FB07201C4BDD2220000B98201A05217 +S315E630D61021900091220000B921100091200000B936 +S315E630D620E1008052000C80D200C4BDF2010000B9A0 +S315E630D630001000911F0000B9E1E19952000680D250 +S315E630D64000C4BDF2010000B9A1008052000480D2C8 +S315E630D65000C4BDF2010000B9EEFCFF97000780D2A8 +S315E630D66000C4BDF2000040B9600200B9F30B40F9E0 +S315E630D670FD7BC2A8C0035FD6FD7BBEA9FD03009144 +S315E630D680F30B00F9F30301AA210200F022DC40B9DC +S315E630D69001E089525F00016B61010054210200F01E +S315E630D6A021D040B93F3C0071E8000054024C80522C +S315E630D6B00200B072810F80D201C4BDF2220000B9F9 +S315E630D6C006000014024C80526200B072810F80D29E +S315E630D6D001C4BDF2220000B902609E52E23FB0724A +S315E630D6E001C4BDD2220000B98201A0522190009138 +S315E630D6F0220000B921100091200000B9E1008052E5 +S315E630D700000C80D200C4BDF2010000B900100091D1 +S315E630D7101F0000B901E19952000680D200C4BDF27D +S315E630D720010000B9A1008052000480D200C4BDF2E7 +S315E630D730010000B9B7FCFF97000780D200C4BDF2FE +S315E630D74000004039001C0053600200B9F30B40F983 +S315E630D750FD7BC2A8C0035FD6FD7BBEA9FD03009163 +S315E630D760F30B00F9F30301AA210200F022DC40B9FB +S315E630D77001E089525F00016B61010054210200F03D +S315E630D78021D040B93F3C0071E8000054024C80524B +S315E630D7900200B072810F80D201C4BDF2220000B918 +S315E630D7A006000014024C80526200B072810F80D2BD +S315E630D7B001C4BDF2220000B902609E52E23FB07269 +S315E630D7C001C4BDD2220000B9A20CA052219000912C +S315E630D7D0220000B921100091200000B9E100805204 +S315E630D7E0000C80D200C4BDF2010000B900100091F1 +S315E630D7F01F0000B901E19852000680D200C4BDF29E +S315E630D800010000B9A1008052000480D200C4BDF206 +S315E630D810010000B97FFCFF97000780D200C4BDF255 +S315E630D8200000403960020039F30B40F9FD7BC2A8AF +S315E630D830C0035FD6FD7BBFA9FD030091211C0053D3 +S315E630D840220200F043DC40B902E089527F00026BE7 +S315E630D85061010054220200F042D040B95F3C0071CB +S315E630D860E8000054034C80520300B072820F80D237 +S315E630D87002C4BDF2430000B906000014034C8052E0 +S315E630D8806300B072820F80D202C4BDF2430000B9A3 +S315E630D89003609E52E33FB07202C4BDD2430000B984 +S315E630D8A0230EA05242900091430000B942100091F7 +S315E630D8B0400000B9800C80D200C4BDF21F0000B92A +S315E630D8C002E18852000680D200C4BDF2020000B9F9 +S315E630D8D0004000910100003961008052000480D298 +S315E630D8E000C4BDF2010000B94AFCFF97200200F001 +S315E630D8F001DC40B900E089523F00006B410100543B +S315E630D900200200F000D040B91F3C0071C800005438 +S315E630D910614E8052800F80D200C4BDF2010000B95C +S315E630D92006000014614E80526100A072800F80D2EC +S315E630D93000C4BDF2010000B921608052E13FA07219 +S315E630D940800180D200C4BDF2010000B9FD7BC1A8DA +S315E630D950C0035FD6FD7BBDA9FD030091F35301A954 +S315E630D960F51300F9142081D2B4C2BCF25500A012E8 +S315E630D970950200B95300A052802481D2A0C2BCF2EF +S315E630D980130000B94000805231D5FF97950200B9B1 +S315E630D990802C81D2A0C2BCF2130000B9800080523E +S315E630D9A02BD5FF97F35341A9F51340F9FD7BC3A871 +S315E630D9B0C0035FD601808052800080D200C4BDF2BB +S315E630D9C0010000B9C0035FD6803481D2A0C2BCF272 +S315E630D9D0000040B98001883600780E12E203202A2C +S315E630D9E0012081D2A1C2BCF2220000B921500291B7 +S315E630D9F0200000B9803481D2A0C2BCF2000040B922 +S315E630DA00A0FF8F37C0035FD6FD7BBEA9FD0300912D +S315E630DA10F30B00F9F303002A200200F000DC40B9EC +S315E630DA2001E089521F00016BA1000054210200F08B +S315E630DA3021D040B93F3C0071E900005401408A529A +S315E630DA401F00016BC1010054210200F021D040B91C +S315E630DA506101003521008052E000009000E01C9123 +S315E630DA60ECDEFF97D9FFFF97E003132AD1FBFF974A +S315E630DA70B9FFFF97D0FFFF971100001401808A5255 +S315E630DA801F00016B4101005421008052E0000090F6 +S315E630DA9000801D91DFDEFF97CCFFFF97AEFFFF9745 +S315E630DAA0E003132AC3FBFF9705000014C7FFFF9771 +S315E630DAB0E003132ABFFBFF97A7FFFF9731FBFF97DC +S315E630DAC0F30B40F9FD7BC2A8C0035FD6FD7BBFA949 +S315E630DAD0FD030091000A8052CCFFFF9723FBFF97A8 +S315E630DAE0FD7BC1A8C0035FD6FD7BBFA9FD030091D0 +S315E630DAF000058052C5FFFF971CFBFF97FD7BC1A84B +S315E630DB00C0035FD6FD7BBEA9FD030091F30B00F99A +S315E630DB10F30300AA200200F001DC40B900E08952A6 +S315E630DB203F00006B61010054200200F000D040B99E +S315E630DB301F3C0071E8000054014C80520100B0727F +S315E630DB40800F80D200C4BDF2010000B90600001491 +S315E630DB50014C80526100B072800F80D200C4BDF2B3 +S315E630DB60010000B901609E52E13FB07200C4BDD2F9 +S315E630DB70010000B9E113A05200900091010000B90E +S315E630DB80000001911F0000B9E1018852000680D2FB +S315E630DB9000C4BDF2010000B9A1008052000480D273 +S315E630DBA000C4BDF2010000B99AFBFF97000780D2A8 +S315E630DBB000C4BDF2000040B9600200B9F30B40F98B +S315E630DBC0FD7BC2A8C0035FD6FD7BBCA9FD030091F1 +S315E630DBD0F35301A9F55B02A9F71B00F9F70300AA8F +S315E630DBE0F60301AA200200F001DC40B900E08952D2 +S315E630DBF03F00006B61010054200200F000D040B9CE +S315E630DC001F3C0071E8000054014C80520100B072AE +S315E630DC10800F80D200C4BDF2010000B906000014C0 +S315E630DC20014C80526100B072800F80D200C4BDF2E2 +S315E630DC30010000B901609E52E13FB07200C4BDD228 +S315E630DC40010000B9E113A05200900091010000B93D +S315E630DC50000001911F0000B9150680D215C4BDF249 +S315E630DC60E0018852A00200B9140480D214C4BDF291 +S315E630DC70A0208052800200B966FBFF97130780D258 +S315E630DC8013C4BDF2600240B9E00200B9E001805249 +S315E630DC90A00200B9A0008052800200B95DFBFF9772 +S315E630DCA0600240B9C00200B900008052F35341A980 +S315E630DCB0F55B42A9F71B40F9FD7BC4A8C0035FD6E6 +S315E630DCC0FD7BBEA9FD030091F30B00F9F30300AA31 +S315E630DCD0200200F001DC40B900E089523F00006BDB +S315E630DCE061010054200200F000D040B91F3C0071BB +S315E630DCF0E8000054014C80520100B072800F80D2A9 +S315E630DD0000C4BDF2010000B906000014014C805291 +S315E630DD106100B072800F80D200C4BDF2010000B956 +S315E630DD2001609E52E13FB07200C4BDD2010000B937 +S315E630DD30A100A05200900091010000B900000191C7 +S315E630DD401F0000B9E1018852000680D200C4BDF258 +S315E630DD50010000B9A1008052000480D200C4BDF2B1 +S315E630DD60010000B92BFBFF97000780D200C4BDF255 +S315E630DD70000040B9600200B9F30B40F9FD7BC2A85A +S315E630DD80C0035FD6FD7BBFA9FD030091210200F0FB +S315E630DD9022DC40B901E089525F00016B6101005433 +S315E630DDA0210200F021D040B93F3C0071E800005432 +S315E630DDB0024C80520200B072810F80D201C4BDF2AD +S315E630DDC0220000B906000014024C80526200B0729E +S315E630DDD0810F80D201C4BDF2220000B902609E52A4 +S315E630DDE0E23FB07201C4BDD2220000B92190009163 +S315E630DDF0200000B9800C80D200C4BDF21F0000B905 +S315E630DE0001008852000680D200C4BDF2010000B996 +S315E630DE1021008052000480D200C4BDF2010000B970 +S315E630DE20FCFAFF97FD7BC1A8C0035FD6236080521C +S315E630DE30E33FA072820180D202C4BDF2430000B94C +S315E630DE40220200F043DC40B902E089527F00026BE1 +S315E630DE5081010054220200F042D040B95F3C0071A5 +S315E630DE6008010054834E80520300B072820F80D28E +S315E630DE7002C4BDF2430000B9020080D20D000014A0 +S315E630DE80834E80526300B072820F80D202C4BDF2F6 +S315E630DE90430000B9F9FFFF17E303012A646862B865 +S315E630DEA0030090D203C4BDF2446823B84210009111 +S315E630DEB05FFC03F129FFFF54FD7BBFA9FD0300910B +S315E630DEC002609E52E23FB07201C4BDD2220000B972 +S315E630DED04200A05221900091220000B92110009113 +S315E630DEE0200000B9800C80D200C4BDF21F0000B914 +S315E630DEF0E1E18852000680D200C4BDF2010000B9E5 +S315E630DF0061008052000480D200C4BDF2010000B93F +S315E630DF10C0FAFF97200200F001DC40B900E08952F2 +S315E630DF203F00006B41010054200200F000D040B9BA +S315E630DF301F3C0071C8000054614E8052800F80D27B +S315E630DF4000C4BDF2010000B906000014614E8052ED +S315E630DF506100A072800F80D200C4BDF2010000B924 +S315E630DF6021608052E13FA072800180D200C4BDF2CA +S315E630DF70010000B9FD7BC1A8C0035FD6FD7BBFA912 +S315E630DF80FD030091210200F022DC40B901E089521E +S315E630DF905F00016B61010054210200F021D040B9E7 +S315E630DFA03F3C0071E8000054024C80520200B072E9 +S315E630DFB0810F80D201C4BDF2220000B906000014FA +S315E630DFC0024C80526200B072810F80D201C4BDF23B +S315E630DFD0220000B902609E52E23FB07201C4BDD261 +S315E630DFE0220000B9021BA05221900091220000B90E +S315E630DFF021100091200000B9800C80D200C4BDF219 +S315E630E0001F0000B901E08852000680D200C4BDF296 +S315E630E010010000B921008052000480D200C4BDF26E +S315E630E020010000B97BFAFF97FD7BC1A8C0035FD636 +S315E630E030200200D001DC40B900E089523F00006B97 +S315E630E04061010054200200D000D040B91F3C007177 +S315E630E050E8000054014C80520100B072800F80D245 +S315E630E06000C4BDF2010000B906000014014C80522E +S315E630E0706100B072800F80D200C4BDF2010000B9F3 +S315E630E08001609E52E13FA07200C4BDD2010000B9E4 +S315E630E09001208052E103A07200300091010000B900 +S315E630E0A0611DA05200100091010000B901E09852BE +S315E630E0B04140A07200300091010000B92101805242 +S315E630E0C04100A07200F00091010000B90010009105 +S315E630E0D01F0000B9C0035FD6FD7BBAA9FD030091E8 +S315E630E0E0BF7F0139BF5B00B9A17F01914000805205 +S315E630E0F00010A07299FDFF9782008052A1630091CD +S315E630E100A07F413991DEFF9701008052C00000F0D2 +S315E630E11000E01D913FDDFF9721008052A06300911C +S315E630E1203CDDFF97A07F4139000208372100805257 +S315E630E130C00000F000401E9136DDFF97C000A052C9 +S315E630E14011FFFF97A17F413921001F3240008052EF +S315E630E1500010A072B8FDFF97A0630191D9FEFF9734 +S315E630E160A05B40B9A0FF0737FD7BC6A8C0035FD6E4 +S315E630E170FD7BB9A9FD030091F30B00F9200200D02F +S315E630E1801F5402B921008052C00000F000801E9173 +S315E630E19020DDFF9721008052C00000F000001F917D +S315E630E1A01CDDFF97200200D00050433900101D12C7 +S315E630E1B01F400071E1179F1A1F600171E0179F1A21 +S315E630E1C02000002AC000003421008052C00000F052 +S315E630E1D000A01F910FDDFF97050000142100805245 +S315E630E1E0C00000F0004020910ADDFF97200200D003 +S315E630E1F00050433900101D121F200071C100005433 +S315E630E20021008052C00000F000E0209101DDFF974A +S315E630E2100C0000141FE00071C1000054210080524A +S315E630E220C00000F000802191FADCFF97050000146B +S315E630E23021008052C00000F000402291F5DCFF97C5 +S315E630E240330080523C00001401008052C00000F0DA +S315E630E25000E02291EFDCFF97A1BF0091A0C30091C9 +S315E630E2601CDDFF97A0C340391FC80071A0020054D9 +S315E630E2701FCC0071600400541FC40071C105005400 +S315E630E28021008052200200D0015402B9012090527A +S315E630E290200200D0015C02B9210084520103A0724B +S315E630E2A0200200D0014402B947E0FF97810000B072 +S315E630E2B02180029120D860F800003FD61D00001478 +S315E630E2C041008052200200D0015402B9010090523A +S315E630E2D0200200D0015C02B9214080520104A072CE +S315E630E2E0200200D0014402B937E0FF97810000B042 +S315E630E2F02180019120D860F800003FD60D00001449 +S315E630E30061008052200200D0015402B921008052C9 +S315E630E310C10FA072200200D0014402B92AE0FF976D +S315E630E320810000B02180009120D860F800003FD609 +S315E630E33013008052B3F8FF35F30B40F9FD7BC7A8DF +S315E630E340C0035FD6FD7BB9A9FD030091F30B00F957 +S315E630E350200200D01F5402B921008052C00000F0DE +S315E630E36000801E91ABDCFF9721008052C00000F0A2 +S315E630E37000202391A7DCFF9721008052C00000F0F1 +S315E630E38000E02391A3DCFF9721008052C00000F025 +S315E630E39000A024919FDCFF97330080523F000014A3 +S315E630E3A001008052C00000F000E0229199DCFF9730 +S315E630E3B0A1BF0091A0C30091C6DCFF97A0C3403948 +S315E630E3C01FC80071A00200541FCC007160040054CF +S315E630E3D01FC400712106005421008052200200D06D +S315E630E3E0015402B901209052200200D0015C02B9F4 +S315E630E3F0210084520103A072200200D0014402B902 +S315E630E400F1DFFF97810000B02180029120D860F8D5 +S315E630E41000003FD62000001441008052200200D092 +S315E630E420015402B901009052200200D0015C02B9D3 +S315E630E430214080520104A072200200D0014402B984 +S315E630E440E1DFFF97810000B02180019120D860F8A6 +S315E630E45000003FD61000001481008052200200D022 +S315E630E460015402B901209052200200D0015C02B973 +S315E630E470214080520104A072200200D0014402B944 +S315E630E480D1DFFF978100009021803F9120D860F858 +S315E630E49000003FD61300805253F8FF35F30B40F9B0 +S315E630E4A0FD7BC7A8C0035FD6FD7BBFA9FD03009100 +S315E630E4B0200200D00050433900101D121F60007153 +S315E630E4C061000054A0FFFF970200001429FFFF9772 +S315E630E4D0FD7BC1A8C0035FD6FD7BBFA9FD030091D6 +S315E630E4E0200200D0005442B91F0400716100005486 +S315E630E4F077FDFF970C0000141F0800716100005489 +S315E630E5007AFDFF97080000141F0C00716100005475 +S315E630E5108A0C0094040000141F1000714100005468 +S315E630E5206BFDFF97FD7BC1A8C0035FD6FD7BBAA91D +S315E630E530FD030091200200D0005442B91F0C007151 +S315E630E540A1000054A07300910E0E0094060E0094BE +S315E630E55036000014A1630091A07300919BFDFF97EE +S315E630E560A01F40B9005C0012A01F00B9A01B40B93D +S315E630E570001C1812A01B00B9210200D0215C42B95A +S315E630E5801F00016B2005005421008052C00000F0C8 +S315E630E590006025911FDCFF97A01B40B9007C08532D +S315E630E5A0A01B00B922008052A183009167DDFF9758 +S315E630E5B001008052C00000F00040269115DCFF973E +S315E630E5C001008052A083009112DCFF97A01B40B970 +S315E630E5D01F040271E100005421008052C00000F0B1 +S315E630E5E000A026910BDCFF97200080523400001401 +S315E630E5F01F000271E100005421008052C00000F095 +S315E630E60000E0269103DCFF97200080522C000014B0 +S315E630E61021008052C00000F000A02E91FDDBFF976E +S315E630E6202000805226000014200200D0004442B971 +S315E630E630A11F40B93F00006B4003005421008052D1 +S315E630E640C00000F000202791F2DBFF97820080526F +S315E630E650A1830091A01F40B93CDDFF9701008052AF +S315E630E660C00000F000E02791EADBFF9721008052F8 +S315E630E670A0830091E7DBFF97200200D0005442B931 +S315E630E6801F0C0071A001005421008052C00000F03A +S315E630E69000202891DFDBFF97200080520800001427 +S315E630E6A021008052C00000F000402991D9DBFF9767 +S315E630E6B0000080520200001420008052FD7BC6A87E +S315E630E6C0C0035FD6FD7BBFA9FD030091230200D0D0 +S315E630E6D064DC40B903E089529F00036B01010054C4 +S315E630E6E0230200D063D040B97F3C007188000054E5 +S315E630E6F042FC001142641A120300001442FC031174 +S315E630E700425C1812427C065384F5FF979FF5FF97D5 +S315E630E710A3F5FF978FF5FF9796F5FF97FD7BC1A893 +S315E630E720C0035FD6FD7BBFA9FD03009142FC031112 +S315E630E730425C1812427C0653AFF5FF97CAF5FF974F +S315E630E740CEF5FF97BAF5FF97C1F5FF97FD7BC1A8E2 +S315E630E750C0035FD6FD7BBFA9FD030091230200D03F +S315E630E76064DC40B903808A529F00036B6100005433 +S315E630E770EDFFFF9702000014D3FFFF97FD7BC1A89C +S315E630E780C0035FD6FD7BBBA9FD030091F35301A918 +S315E630E790F40300AA330080522B00001401008052A5 +S315E630E7A0C00000F0008029919ADBFF97A1BF009167 +S315E630E7B0A0C30091C7DBFF97A24301915FEC1D38FA +S315E630E7C003008052A1030191A0C3009127DDFF9794 +S315E630E7D020030035A0BB40391F04007140030054C6 +S315E630E7E01F240071C900005421008052C00000D0B9 +S315E630E7F000E0029187DBFF9713000014A1A3009196 +S315E630E800A003019175DCFF97001C0053C00000346D +S315E630E81021008052C00000D000E002917DDBFF97F8 +S315E630E82009000014A02B40B9800200B913008052CB +S315E630E8300500001421008052C00000D000E00291AD +S315E630E84074DBFF97D3FAFF35F35341A9FD7BC5A8B1 +S315E630E850C0035FD6027C409306000014430040397D +S315E630E860631C00537FFC0371E100005442040091BF +S315E630E8700300010B5FC023EB23FFFF5400008052F9 +S315E630E880C0035FD620008052C0035FD6FD7BBBA9AE +S315E630E890FD030091F35301A9F51300F9F503002AB8 +S315E630E8A0F403012AF303022A01008052C00000F085 +S315E630E8B000C0299157DBFF97E203132AE103152AB5 +S315E630E8C0E003142A6AEBFF97E103132AE003152ADD +S315E630E8D0E1FFFF976005003401008052E0000090CA +S315E630E8E000200B914BDBFF9782008052A10301910A +S315E630E8F0E003142A95DCFF9701008052A0030191CC +S315E630E90044DBFF9701008052C00000F000402A91B8 +S315E630E91040DBFF978002130B82008052A1C3009141 +S315E630E9200004005189DCFF9701008052A0C30091B4 +S315E630E93038DBFF9701008052C00000F000602A9174 +S315E630E94034DBFF970ADDFF97001C005320010034C5 +S315E630E95040048052EBDBFF9721008052C00000F086 +S315E630E96000A02A912BDBFF9720008052240000146A +S315E630E97040048052E3DBFF97200080520600001405 +S315E630E98021008052C00000F000C02A9121DBFF97BB +S315E630E990000080522003003401008052E0000090EF +S315E630E9A000200B911BDBFF9701008052A0030191FB +S315E630E9B018DBFF9701008052C00000F000402A9134 +S315E630E9C014DBFF9701008052A0C3009111DBFF975D +S315E630E9D001008052C00000F000E02A910DDBFF977F +S315E630E9E08102130B21040051E003142A3BECFF9716 +S315E630E9F0000080520200001400008052F35341A911 +S315E630EA00F51340F9FD7BC5A8C0035FD6FD7BBBA9F0 +S315E630EA10FD030091F35301A9F51300F9F503002A36 +S315E630EA20F403012AF303022A01008052C00000F003 +S315E630EA3000C02991F7DAFF97E203132AE103152A94 +S315E630EA40E003142A71E9FF97E103132AE003152A56 +S315E630EA5081FFFF976005003401008052E0000090A8 +S315E630EA6000200B91EBDAFF9782008052A1030191E9 +S315E630EA70E003142A35DCFF9701008052A0030191AA +S315E630EA80E4DAFF9701008052C00000F000402A9198 +S315E630EA90E0DAFF978002130B82008052A1C3009121 +S315E630EAA00004005129DCFF9701008052A0C3009193 +S315E630EAB0D8DAFF9701008052C00000F000602A9154 +S315E630EAC0D4DAFF97AADCFF97001C00532001003406 +S315E630EAD0400480528BDBFF9721008052C00000F065 +S315E630EAE000A02A91CBDAFF9720008052320000143C +S315E630EAF04004805283DBFF972000805206000014E4 +S315E630EB0021008052C00000F000C02A91C1DAFF979A +S315E630EB1000008052E004003480FFBF129F02006B93 +S315E630EB208801005401008052C00000F000202B918D +S315E630EB30B8DAFF9721008052C00000F000E02A9153 +S315E630EB40B4DAFF97E1FF8F52000080526EEAFF9704 +S315E630EB5001008052E000009000200B91ADDAFF977D +S315E630EB6001008052A0030191AADAFF970100805294 +S315E630EB70C00000F000402A91A6DAFF9701008052E5 +S315E630EB80A0C30091A3DAFF9701008052C00000F0DF +S315E630EB9000E02A919FDAFF978102130B2104005198 +S315E630EBA0E003142A41EAFF9700008052020000147F +S315E630EBB000008052F35341A9F51340F9FD7BC5A811 +S315E630EBC0C0035FD6FD7BBBA9FD030091F35301A9D4 +S315E630EBD0F51300F9F503002AF403012AF303022AB2 +S315E630EBE001008052C00000F000C0299189DAFF9713 +S315E630EBF0E203132AE103152AE003142A4CE8FF97C9 +S315E630EC00E103132AE003152A13FFFF976005003464 +S315E630EC1001008052E000009000200B917DDAFF97EC +S315E630EC2082008052A1030191E003142AC7DBFF97E5 +S315E630EC3001008052A003019176DAFF9701008052F7 +S315E630EC40C00000F000402A9172DAFF978002130B7B +S315E630EC5082008052A1C3009100040051BBDBFF97CE +S315E630EC6001008052A0C300916ADAFF970100805214 +S315E630EC70C00000F000602A9166DAFF973CDCFF9729 +S315E630EC80001C005320010034400480521DDBFF9700 +S315E630EC9021008052C00000F000A02A915DDAFF978D +S315E630ECA020008052320000144004805215DBFF9774 +S315E630ECB0200080520600001421008052C00000F089 +S315E630ECC000C02A9153DAFF9700008052E004003400 +S315E630ECD080FFBF129F02006B88010054010080520C +S315E630ECE0C00000F000202B914ADAFF9721008052CF +S315E630ECF0C00000F000E02A9146DAFF97E1FF8F5236 +S315E630ED000000805293E8FF9701008052E0000090C1 +S315E630ED1000200B913FDAFF9701008052A003019164 +S315E630ED203CDAFF9701008052C00000F000402A919D +S315E630ED3038DAFF9701008052A0C3009135DAFF97A3 +S315E630ED4001008052C00000F000E02A9131DAFF97E8 +S315E630ED508102130B21040051E003142A67E8FF977A +S315E630ED60000080520200001400008052F35341A99D +S315E630ED70F51340F9FD7BC5A8C0035FD6FD7BBBA97D +S315E630ED80FD030091F35301A9F51300F9F503002AC3 +S315E630ED90F403012AF303022A01008052C00000F090 +S315E630EDA000C029911BDAFF97E203132AE103152AFD +S315E630EDB0E003142A790C0094E103132AE003152ABA +S315E630EDC0A5FEFF976005003401008052E000009012 +S315E630EDD000200B910FDAFF9782008052A103019152 +S315E630EDE0E003142A59DBFF9701008052A003019114 +S315E630EDF008DAFF9701008052C00000F000402A9101 +S315E630EE0004DAFF978002130B82008052A1C3009189 +S315E630EE10000400514DDBFF9701008052A0C30091FC +S315E630EE20FCD9FF9701008052C00000F000602A91BD +S315E630EE30F8D9FF97CEDBFF97001C0053200100344C +S315E630EE4040048052AFDAFF9721008052C00000F0CE +S315E630EE5000A02A91EFD9FF972000805224000014B3 +S315E630EE6040048052A7DAFF9720008052060000144D +S315E630EE7021008052C00000F000C02A91E5D9FF9704 +S315E630EE80000080522003003401008052E0000090FA +S315E630EE9000200B91DFD9FF9701008052A003019144 +S315E630EEA0DCD9FF9701008052C00000F000402A917D +S315E630EEB0D8D9FF9701008052A0C30091D5D9FF97E4 +S315E630EEC001008052C00000F000E02A91D1D9FF97C8 +S315E630EED08102130B21040051E003142A8E0C0094B0 +S315E630EEE0000080520200001400008052F35341A91C +S315E630EEF0F51340F9FD7BC5A8C0035FD6FD7BB3A904 +S315E630EF00FD030091F35301A9F55B02A9F76303A963 +S315E630EF10F96B04A9FB2B00F921008052C00000F002 +S315E630EF2000802B91BBD9FF9721008052C00000F0BC +S315E630EF3000802C91B7D9FF970000AA5298F2FF9736 +S315E630EF40204C003559FDFF9764FDFF9778FDFF9716 +S315E630EF50A04B0035D30000F073022D91210080528C +S315E630EF60E00313AAABD9FF9721008052C00000F028 +S315E630EF7000002E91A7D9FF97D90000F039A32E913C +S315E630EF8021008052E00319AAA2D9FF9721008052C8 +S315E630EF90C00000F000C02E919ED9FF972100805226 +S315E630EFA0C00000F000C02F919AD9FF972100805219 +S315E630EFB0C00000F000C0309196D9FF97210080520C +S315E630EFC0E00319AA93D9FF9721008052C00000F0DA +S315E630EFD000C031918FD9FF9721008052C00000F0F2 +S315E630EFE000C032918BD9FF9721008052E00313AAF5 +S315E630EFF088D9FF97330080522100001401008052F1 +S315E630F000C00000D000C0339182D9FF97A1BF0191ED +S315E630F010A0430291AFD9FF97A04342391FC800718A +S315E630F020600100541FCC0071E00100541FC400712A +S315E630F0306102005421008052200200B0015002B92C +S315E630F0409500A052B4FFB5120C0000144100805270 +S315E630F050200200B0015002B91501A052B4FFB51234 +S315E630F0600600001461008052200200B0015002B959 +S315E630F0701502A0521480B5121300805213FCFF35E8 +S315E630F080200200B0005042B9010400513F0400713D +S315E630F090480100540100845201C6BC72200200B019 +S315E630F0A0014002B921008052C00000D000203491E0 +S315E630F0B058D9FF97440000141F0C007141080054DC +S315E630F0C021008052C00000D000E0349151D9FF973C +S315E630F0D0390080523B00001401008052C00000D057 +S315E630F0E000A035914BD9FF97A1BF0191A0C30191FD +S315E630F0F078D9FF97A24303915FEC19380300805223 +S315E630F100A1030291A0C30191D8DAFF972005003515 +S315E630F110A0BB41391F04007140050054A1034239B2 +S315E630F1203FB80071C10000540100A852200200B079 +S315E630F130014002B9F903132A220000141F24007194 +S315E630F140C900005421008052C00000B000E00291B0 +S315E630F15030D9FF971B000014A1A30191A0030291B9 +S315E630F1601EDAFF97001C0053C0000034210080529F +S315E630F170C00000B000E0029126D9FF9711000014D6 +S315E630F180A06B40B901040012C10000342100805260 +S315E630F190C00000B0008002911ED9FF970900001426 +S315E630F1A0210200B0204002B9F903132A0500001403 +S315E630F1B021008052C00000B000E0029115D9FF97D9 +S315E630F1C0D9F8FF35200200B0005042B901040051AB +S315E630F1D03F040071C800005421008052C00000D0C0 +S315E630F1E0006036910BD9FF97070000141F0C0071AB +S315E630F1F0A100005421008052C00000D00020379193 +S315E630F20004D9FF97E21F8052E103142A0000AA527E +S315E630F210DBF3FF97A1930191A0830191E31200946A +S315E630F220001C005300350035B36740B90000B652CE +S315E630F2306002000BB502000BA06340B90000134B29 +S315E630F240B402000B19040011A1360E1280460032C4 +S315E630F2500000014B02040011200200B0005442B90E +S315E630F2601F040071C1000054230080520000AB52E7 +S315E630F270E7FDFF9780320035150000141F08007150 +S315E630F280C1000054230080520000AB5280FDFF9748 +S315E630F290A03100350E0000141F0C0071C100005479 +S315E630F2A0230080520000AB52B5FEFF97C0300035E2 +S315E630F2B0070000141F100071A1000054230080528D +S315E630F2C00000AB5240FEFF97E02F0035010080523A +S315E630F2D0C00000D000E03791CED8FF97200200B0CC +S315E630F2E0005442B91F04007141010054E203192A61 +S315E630F2F0E103152AE003132A55E8FF9721008052E9 +S315E630F300C00000D000403891C2D8FF978400001480 +S315E630F3101F080071210D0054200200B000D040B91C +S315E630F3201F3C0071C901005401008052C00000D074 +S315E630F33000803891B7D8FF97E203192AE103152AF8 +S315E630F340E003132ABAE9FF9721008052C00000D0C5 +S315E630F35000403891AFD8FF977100001421008052F3 +S315E630F360C00000D000A02E91AAD8FF9700E0BF12C9 +S315E630F370BF02006B880800540020A0529F02006B43 +S315E630F38089060054F403002A1A00154B3B031A4B40 +S315E630F39082008052A1430291E0031A2AEBD9FF9705 +S315E630F3A001008052C00000D000E0389199D8FF972E +S315E630F3B021008052A043029196D8FF978200805270 +S315E630F3C0A1430291E0031B2AE0D9FF970100805260 +S315E630F3D0C00000D0004039918ED8FF972100805288 +S315E630F3E0A04302918BD8FF9701008052C00000D02F +S315E630F3F000A0399187D8FF97E2031A2AE103152A46 +S315E630F400E003132A73E9FF97D30000D073423891AD +S315E630F41021008052E00313AA7ED8FF97010080527E +S315E630F420C00000D000203A917AD8FF97E2031B2A33 +S315E630F430E103142A0020AA520000154B4FE9FF9744 +S315E630F44021008052E00313AA72D8FF9734000014E5 +S315E630F45001008052C00000D000A039916DD8FF97E8 +S315E630F460E203192AE103152AE003132A59E9FF973D +S315E630F47021008052C00000D00040389165D8FF9711 +S315E630F4802700001401008052C00000D000203A91D7 +S315E630F49060D8FF97E203192AE103152AE003132A17 +S315E630F4A036E9FF9721008052C00000D000403891FF +S315E630F4B058D8FF971A0000141F0C0071C10100548A +S315E630F4C0000580523BF5FF97E203192AE103152A38 +S315E630F4D0E003132AFB0A0094000A805235F5FF97BB +S315E630F4E021008052C00000D00040389149D8FF97BD +S315E630F4F00B0000141F10007121010054E203192A93 +S315E630F500E103152AE003132A65E6FF9721008052C8 +S315E630F510C00000D0004038913ED8FF972100805297 +S315E630F520C00000D000A03A913AD8FF97200200B04A +S315E630F530005042B91F040071C00000541F08007124 +S315E630F540400100541F0C0071410200540D000014B6 +S315E630F55097CC81D21700ABF298AA81D21800ABF2DB +S315E630F560160080520B000014974C82D21700ABF28D +S315E630F570982A82D21800ABF21600805205000014A3 +S315E630F580970080D29701ABF29801ABD29601A052A2 +S315E630F5901300AB52D302130B210200B0215442B909 +S315E630F5A03F040071A1010054000400511F040071AC +S315E630F5B0C800005402008452E103132AE003162AF7 +S315E630F5C092E6FF971E000014E103132AE003162A9B +S315E630F5D0E3E7FF971A0000143F080071A1000054D4 +S315E630F5E0E103132AE003162A52E9FF9714000014C2 +S315E630F5F03F0C0071A1000054E103132AE003162AFA +S315E630F600DB0A00940E0000143F10007181010054AD +S315E630F610000400511F040071C800005402008452F1 +S315E630F620E103132AE003162AC1E5FF970400001426 +S315E630F630E103132AE003162A5CE6FF97200200B0C0 +S315E630F640005042B9000400511F040071C80000544E +S315E630F65001008052C00000D000603B91EDD7FF97A5 +S315E630F6600500001401008052C00000D000203C9115 +S315E630F670E8D7FF97200200B0005442B91F04007164 +S315E630F680C1010054200200B0005042B900040051D6 +S315E630F6901F040071A8000054E1FF8352E003162AE6 +S315E630F6A099E7FF971F000014C11E0011E003162AE2 +S315E630F6B07EE7FF971B0000141F080071A100005477 +S315E630F6C0C11E0011E003162A04E9FF97150000145F +S315E630F6D01F0C0071A1000054C11E0011E003162A6A +S315E630F6E08D0A00940F0000141F100071A10100541A +S315E630F6F0200200B0005042B9000400511F040071E8 +S315E630F700A8000054E1FF8352E003162A11E6FF977C +S315E630F71004000014C11E0011E003162AF7E5FF9730 +S315E630F720200200B0004042B9000300B9397F0253E7 +S315E630F730F90200B901008052C00000D000E03791EE +S315E630F740B4D7FF97200200B0005442B91F040071C7 +S315E630F75001020054200200B0005042B900040051C4 +S315E630F7601F040071C800005402008452E103162AD1 +S315E630F770E003132A36E7FF97280000148200A052EA +S315E630F780E103162AE003132A31E7FF972300001434 +S315E630F7901F080071C10000548200A052E103162A08 +S315E630F7A0E003132A75E8FF971C0000141F0C00715E +S315E630F7B041010054000580527EF4FF978200A05244 +S315E630F7C0E103162AE003132A3E0A0094000A805221 +S315E630F7D078F4FF97110000141F100071E101005410 +S315E630F7E0200200B0005042B9000400511F040071F7 +S315E630F7F0C800005402008452E103162AE003132AB5 +S315E630F800A7E5FF97050000148200A052E103162A09 +S315E630F810E003132AA2E5FF9721008052C00000D00C +S315E630F820004038917BD7FF97D30000B073A22B9177 +S315E630F83021008052E00313AA76D7FF972100805243 +S315E630F840C00000D000E03C9172D7FF9701008052AD +S315E630F850C00000D000E03D916ED7FF97820080521F +S315E630F860A1430291200200B0004042B9B7D8FF97D3 +S315E630F87021008052A043029166D7FF9782008052DC +S315E630F880A1430291E003192AB0D8FF9701008052CE +S315E630F890C00000D000603E915ED7FF9721008052CF +S315E630F8A0A04302915BD7FF9721008052C00000D07B +S315E630F8B000E03E9157D7FF9721008052E00313AA26 +S315E630F8C054D7FF97F35341A9F55B42A9F76343A9AA +S315E630F8D0F96B44A9FB2B40F9FD7BCDA8C0035FD677 +S315E630F8E0FD7BBBA9FD030091F35301A9F40300AAFE +S315E630F8F0330080523A00001401008052C00000D036 +S315E630F90000E03F9143D7FF97A1BF0091A0C3009196 +S315E630F91070D7FF97A24301915FEC1D380300805202 +S315E630F920A1030191A0C30091D0D8FF970005003519 +S315E630F930A0BB40391F04007120050054A1034139AC +S315E630F9403FB80071C10000540100A852200200B051 +S315E630F950014002B913008052210000141F240071C1 +S315E630F960C900005421008052C00000B000E0029188 +S315E630F97028D7FF971A000014A1A30091A00301919E +S315E630F98016D8FF97001C0053C00000342100805281 +S315E630F990C00000B000E002911ED7FF9710000014B9 +S315E630F9A0A02B40B901040012C10000342100805278 +S315E630F9B0C00000B00080029116D7FF970800001409 +S315E630F9C0800200B9130080520500001421008052EF +S315E630F9D0C00000B000E002910ED7FF97F3F8FF358E +S315E630F9E0F35341A9FD7BC5A8C0035FD6FD7BB7A916 +S315E630F9F0FD030091F35301A9F55B02A9F76303A969 +S315E630FA0021008052C00000F00040009101D7FF97F8 +S315E630FA1021008052C00000D000802C91FDD6FF97A1 +S315E630FA2021008052C00000F000600191F9D6FF97C0 +S315E630FA300000AA52DAEFFF97002F00359BFAFF97C0 +S315E630FA40A6FAFF97BAFAFF97802E0035340200B051 +S315E630FA50950209919F4202B921008052C00000F01A +S315E630FA6000E00191EBD6FF9761008052200200B0AC +S315E630FA70015002B9B34302917F4E1BB89F4202B999 +S315E630FA8021008052C00000F000C00291E1D6FF9717 +S315E630FA90E00315AA93FFFF9721008052C00000D0FD +S315E630FAA000A02E91DBD6FF9721008052C00000F0F1 +S315E630FAB000A00391D7D6FF97E00313AA89FFFF97F5 +S315E630FAC0200200B0005442B91F040071E10100542F +S315E630FAD0E0FF8F52E01FA072A14740B93F00006BAE +S315E630FAE04903005421008052C00000F000800491A2 +S315E630FAF0C8D6FF9721008052C00000F000E004919E +S315E630FB00C4D6FF9745010014000800511F0800715E +S315E630FB10C80100540080BF12A14740B93F00006BD0 +S315E630FB204901005421008052C00000F00080049163 +S315E630FB30B8D6FF9721008052C00000F000800591CC +S315E630FB40B4D6FF973501001421008052C00000D0AC +S315E630FB5000203791AFD6FF97E21F80520180B5126B +S315E630FB600000AA5286F1FF97A1330191A0230191B5 +S315E630FB708E100094001C005300250035B44F40B972 +S315E630FB800000B6528102000BA04740B92000000BB8 +S315E630FB90A04700B9A14B40B92100144B1500010B23 +S315E630FBA033040011210200B0235442B97F040071B8 +S315E630FBB001040054E1FF8F52E11FA072BF02016BD0 +S315E630FBC0A907005421008052C00000F000200691BB +S315E630FBD090D6FF9701008052C00000F00080069173 +S315E630FBE08CD6FF9782008052A1430191A04740B957 +S315E630FBF0D6D7FF9721008052A043019185D6FF974D +S315E630FC0001008052C00000F00020079181D6FF97B0 +S315E630FC1082008052A1430191E003152ACBD7FF97A4 +S315E630FC2021008052A04301917AD6FF97FB0000145B +S315E630FC30610800513F080071E80300540180BF12A5 +S315E630FC40BF02016B8903005421008052C00000F0E8 +S315E630FC50002006916FD6FF9701008052C00000F073 +S315E630FC60008006916BD6FF9782008052A1430191C0 +S315E630FC70A04740B9B5D7FF9721008052A0430191FE +S315E630FC8064D6FF9701008052C00000F0002007914D +S315E630FC9060D6FF9782008052A1430191E003152A90 +S315E630FCA0AAD7FF9721008052A043019159D6FF97F4 +S315E630FCB0DA00001401340E12A04600320000014B81 +S315E630FCC0020400117F040071A10000540000AB521B +S315E630FCD04FFBFF97201A0035150000147F08007198 +S315E630FCE0C1000054230080520000AB52E8FAFF9779 +S315E630FCF0401900350E0000147F0C0071C100005427 +S315E630FD00230080520000AB521DFCFF976018003589 +S315E630FD10070000147F100071A100005423008052C2 +S315E630FD200000AB52A8FBFF978017003501008052E2 +S315E630FD30C00000D000E0379136D6FF97200200B0FB +S315E630FD40005442B91F04007141010054E203132AFC +S315E630FD50A14740B9E003142ABDE5FF97210080525A +S315E630FD60C00000D0004038912AD6FF9785000014AF +S315E630FD701F080071410D0054200200B000D040B992 +S315E630FD801F3C0071C901005401008052C00000D00A +S315E630FD90008038911FD6FF97E203132AA14740B970 +S315E630FDA0E003142A22E7FF9721008052C00000D0F4 +S315E630FDB00040389117D6FF97720000142100805222 +S315E630FDC0C00000D000A02E9112D6FF97B64740B9B4 +S315E630FDD000E0BF12DF02006B880800540020A05214 +S315E630FDE0BF02006B89060054F803002A1700164B4B +S315E630FDF07302174B82008052A1430191E003172A22 +S315E630FE0052D7FF9701008052C00000D000E038910B +S315E630FE1000D6FF9721008052A0430191FDD5FF978A +S315E630FE2082008052A1430191E003132A47D7FF9718 +S315E630FE3001008052C00000D000403991F5D5FF97D9 +S315E630FE4021008052A0430191F2D5FF9701008052FE +S315E630FE50C00000D000A03991EED5FF97E203172A0D +S315E630FE60A14740B9E003142ADAE6FF97D40000D07A +S315E630FE709442389121008052E00314AAE5D5FF97E3 +S315E630FE8001008052C00000D000203A91E1D5FF97BC +S315E630FE90E203132AE103182A0020AA520000164B81 +S315E630FEA0B6E6FF9721008052E00314AAD9D5FF972C +S315E630FEB03400001401008052C00000D000A0399111 +S315E630FEC0D4D5FF97E203132AA14740B9E003142AB3 +S315E630FED0C0E6FF9721008052C00000D0004038913E +S315E630FEE0CCD5FF972700001401008052C00000D021 +S315E630FEF000203A91C7D5FF97E203132AA14740B9C6 +S315E630FF00E003142A9DE6FF9721008052C00000D018 +S315E630FF1000403891BFD5FF971A0000141F0C0071C8 +S315E630FF20C101005400058052A2F2FF97E203132A7C +S315E630FF30A14740B9E003142A62080094000A8052C9 +S315E630FF409CF2FF9721008052C00000D000403891E5 +S315E630FF50B0D5FF970B0000141F1000712101005435 +S315E630FF60E203132AA14740B9E003142ACCE3FF970C +S315E630FF7021008052C00000D000403891A5D5FF97C9 +S315E630FF80D30000B073A22B9121008052E00313AA6E +S315E630FF90A0D5FF9721008052C00000F000C007913F +S315E630FFA09CD5FF9701008052C00000F00080069194 +S315E630FFB098D5FF9782008052A1430191A04740B978 +S315E630FFC0E2D6FF9721008052A043019191D5FF9763 +S315E630FFD001008052C00000F0002007918DD5FF97D2 +S315E630FFE082008052A1430191E003152AD7D6FF97C6 +S315E630FFF021008052A043019186D5FF972100805299 +S315E6310000C00000D000C0089182D5FF97210080520A +S315E6310010E00313AA7FD5FF97F35341A9F55B42A9CE +S315E6310020F76343A9FD7BC9A8C0035FD6FD7BBFA9AC +S315E6310030FD0300916EFEFF97FD7BC1A8C0035FD637 +S315E6310040FD7BB9A9FD030091F35301A9F55B02A93D +S315E631005021008052C00000D000C009916DD5FF97CE +S315E631006012F9FF971DF9FF9731F9FF97E00B003546 +S315E631007020020090005442B91F040071A1000054D9 +S315E63100800100AB520000805235E5FF9712000014AD +S315E63100901F080071A10000540100AB5200008052E6 +S315E63100A0A4E6FF970C0000141F0C0071A100005462 +S315E63100B00100AB52000080522D0800940600001470 +S315E63100C01F100071810000540100AB5200008052CE +S315E63100D0B6E3FF9780AA81D20000ABF2160040B9AB +S315E63100E000400491150040B900C00B91140040B9A7 +S315E63100F000400491130040B982008052A1C30091B9 +S315E63101000000ABD2000040B990D6FF97010080528D +S315E6310110C00000D000800A913ED5FF97210080527B +S315E6310120A0C300913BD5FF9782008052A1C30091CF +S315E6310130E003162A85D6FF9701008052C00000D02B +S315E631014000400B9133D5FF9721008052A0C3009131 +S315E631015030D5FF9782008052A1C30091E003152A7C +S315E63101607AD6FF9701008052C00000D000000C918C +S315E631017028D5FF9721008052A0C3009125D5FF9758 +S315E631018082008052A1C30091E003142A6FD6FF970D +S315E631019001008052C00000D000C00C911DD5FF97FA +S315E63101A021008052A0C300911AD5FF978200805272 +S315E63101B0A1C30091E003132A64D6FF97010080526A +S315E63101C0C00000D000800D9112D5FF9721008052F4 +S315E63101D0A0C300910FD5FF9721008052C00000D011 +S315E63101E000400E910BD5FF97F35341A9F55B42A932 +S315E63101F0FD7BC7A8C0035FD6FD7BB7A9FD0300919A +S315E6310200F30B00F9F30300AA000040B9A08F00B959 +S315E631021082008052A12301914CD6FF97210080526C +S315E6310220A0230191FBD4FF9701008052C00000D094 +S315E631023000200F91F7D4FF97A19F0091A0A30091DB +S315E631024024D5FF97A09F40391F040071E1FEFF5484 +S315E6310250A0A340391F640171E2179F1A1FE40171A9 +S315E6310260E1179F1A4100012A6101003421008052CB +S315E6310270C00000D000600F91E6D4FF97A03302911B +S315E631028041F9FF97A08F40B9600200B9200080524C +S315E6310290080000141F380171E1179F1A1FB8017162 +S315E63102A0E0179F1A2000002A00FCFF340000805236 +S315E63102B0F30B40F9FD7BC9A8C0035FD6FD7BBEA92A +S315E63102C0FD030091F30B00F921008052C00000D006 +S315E63102D000C00991CFD4FF9774F8FF977FF8FF975F +S315E63102E093F8FF976014003520020090005442B926 +S315E63102F01F040071C1000054020084520100AB5262 +S315E63103000000805241E3FF97130000141F08007185 +S315E6310310A10000540100AB520000805205E6FF977A +S315E63103200D0000141F0C0071A10000540100AB5200 +S315E6310330000080528E070094070000141F100071EA +S315E6310340A1000054020084520100AB5200008052F3 +S315E631035077E2FF9701008052C00000D000800A9113 +S315E6310360ACD4FF970000ABD2A4FFFF971F04007110 +S315E631037060000054130080520200001433008052AC +S315E631038001008052C00000D000400B91A1D4FF9706 +S315E631039080AA81D20000ABF298FFFF971F04007165 +S315E63103A0410000543300805201008052C00000D033 +S315E63103B000000C9197D4FF9780CC81D20000ABF246 +S315E63103C08EFFFF971F0400714100005433008052BF +S315E63103D001008052C00000D000C00C918DD4FF9749 +S315E63103E0802A82D20000ABF284FFFF971F040071A8 +S315E63103F0410000543300805201008052C00000D0E3 +S315E631040000800D9183D4FF97804C82D20000ABF207 +S315E63104107AFFFF971F040071410000543300805282 +S315E6310420930A003420020090005442B91F04007149 +S315E63104302101005401008052C00000D000C00F9166 +S315E631044074D4FF97E1FF8352000080522EE4FF9782 +S315E63104501E0000141F08007121010054010080526C +S315E6310460C00000B000603B916AD4FF9761008052CC +S315E63104700000805299E5FF97140000141F0C0071B5 +S315E63104802101005401008052C00000B000603B916A +S315E631049060D4FF9761008052000080521E070094B7 +S315E63104A00A0000141F100071010100540100805248 +S315E63104B0C00000D000C00F9156D4FF97E1FF8352BA +S315E63104C000008052A3E2FF9727060094010080528E +S315E63104D0C00000B000E037914ED4FF97200200907D +S315E63104E0005442B91F040071C1000054020084521F +S315E63104F0010080520000AB52D5E3FF971900001494 +S315E63105001F080071C10000548200A05201008052DA +S315E63105100000AB5219E5FF97120000141F0C00716B +S315E6310520410100540005805222F1FF978200A05224 +S315E6310530010080520000AB52E2060094000A805276 +S315E63105401CF1FF97070000141F100071A10000543B +S315E631055002008452010080520000AB5250E2FF970E +S315E631056021008052C00000B00040389129D4FF976F +S315E6310570F30B40F9FD7BC2A8C0035FD6FD7BBAA972 +S315E6310580FD030091F30B00F921008052C00000D043 +S315E6310590008010911FD4FF97C4F7FF97CFF7FF97E7 +S315E63105A0E3F7FF970007003520020090005442B981 +S315E63105B01F040071A10000548101AB528001A052A3 +S315E63105C0E7E3FF97120000141F080071A1000054FB +S315E63105D08101AB528001A05256E5FF970C0000141B +S315E63105E01F0C0071A10000548101AB528001A0526B +S315E63105F0DF060094060000141F10007181000054D6 +S315E63106008101AB528001A05268E2FF97800080D229 +S315E63106108001ABF2130040B982008052A18300918A +S315E63106208001ABD2000040B948D5FF970100805230 +S315E6310630C00000D000401191F6D3FF9721008052D9 +S315E6310640A0830091F3D3FF9782008052A183009174 +S315E6310650E003132A3DD5FF9701008052C00000D052 +S315E631066000C01191EBD3FF9721008052A083009110 +S315E6310670E8D3FF9721008052C00000D000400E91AA +S315E6310680E4D3FF97F30B40F9FD7BC6A8C0035FD6EB +S315E6310690FD7BBEA9FD030091F30B00F921008052E3 +S315E63106A0C00000D000801091DAD3FF977FF7FF972D +S315E63106B08AF7FF979EF7FF97400F003520020090A5 +S315E63106C0005442B91F040071A10000548101AB52B6 +S315E63106D08001A052A2E3FF97120000141F080071B1 +S315E63106E0A10000548101AB528001A05211E5FF977A +S315E63106F00C0000141F0C0071A10000548101AB52AD +S315E63107008001A0529A060094060000141F1000716B +S315E6310710810000548101AB528001A05223E2FF975A +S315E631072001008052C00000D000401191B9D3FF9745 +S315E63107308001ABD2B1FEFF971F0400716000005411 +S315E631074013008052020000143300805201008052B9 +S315E6310750C00000D000C01191AED3FF97800080D2A1 +S315E63107608001ABF2A5FEFF971F04007141000054EC +S315E6310770330080527309003401008052C00000B064 +S315E631078000203C91A3D3FF9720020090005442B952 +S315E63107901F040071C1000054610080528101A072CC +S315E63107A08001A05241E3FF97150000141F0800713E +S315E63107B0C1000054610080528101A0728001A052CD +S315E63107C0C6E4FF970E0000141F0C0071C1000054F9 +S315E63107D0610080528101A0728001A0524E060094DA +S315E63107E0070000141F100071A10000546100805209 +S315E63107F08101A0728001A052C0E1FF9701008052CB +S315E6310800C00000B000E0379182D3FF972002009016 +S315E6310810005442B91F040071C10000548200A0524F +S315E63108208101A0528001AB5209E3FF97190000140A +S315E63108301F080071C10000548200A0528101A05206 +S315E63108408001AB524DE4FF97120000141F0C007184 +S315E6310850410100540005805256F0FF978200A052BE +S315E63108608101A0528001AB5216060094000A8052ED +S315E631087050F0FF97070000141F100071A1000054D5 +S315E63108808200A0528101A0528001AB5284E1FF97EA +S315E631089021008052C00000B0004038915DD3FF9709 +S315E63108A0F30B40F9FD7BC2A8C0035FD6FD7BBFA93A +S315E63108B0FD03009121008052C00000D00040129124 +S315E63108C054D3FF9701008052C00000D00000139147 +S315E63108D050D3FF9726D5FF97001C0053800000348E +S315E63108E0C001805207D4FF9734000014C00180520C +S315E63108F004D4FF97EDF6FF97F8F6FF970CF7FF97D7 +S315E6310900C005003520020090005442B91F0400713B +S315E6310910E100005401008052C00000D0004013913E +S315E63109203CD3FF9743E2FF971A0000141F08007184 +S315E6310930E100005401008052C00000D000E013917E +S315E631094034D3FF976BE3FF97120000141F0C007147 +S315E6310950E100005401008052C00000D000801491BD +S315E63109602CD3FF97700500940A0000141F1000710E +S315E6310970E100005401008052C00000D000201591FC +S315E631098024D3FF9725E1FF97020000140000805239 +S315E6310990C000003521008052C00000B000403891D9 +S315E63109A01CD3FF970500001421008052C00000B029 +S315E63109B000A00E9117D3FF97FD7BC1A8C0035FD682 +S315E63109C0FD7BB9A9FD030091F30B00F920020090F6 +S315E63109D01F5402B921008052C00000D000C01591E3 +S315E63109E00CD3FF9721008052C00000D0000016914B +S315E63109F008D3FF9721008052C00000D000801691BF +S315E6310A0004D3FF9721008052C00000D00020179111 +S315E6310A1000D3FF9721008052C00000D000E0179145 +S315E6310A20FCD2FF9721008052C00000D00080189199 +S315E6310A30F8D2FF9721008052C00000D000401991CC +S315E6310A40F4D2FF9721008052C00000D000E0199120 +S315E6310A50F0D2FF97330080523C00001401008052F9 +S315E6310A60C00000D000801A91EAD2FF97A1BF00916B +S315E6310A70A0C3009117D3FF97A0C3403900C40051F4 +S315E6310A801F14007128060054610000F021701A9196 +S315E6310A9020486038610000102088208B00001FD680 +S315E6310AA02100805220020090015802B9610080523D +S315E6310AB020020090014C02B9230000142100805235 +S315E6310AC020020090015802B941008052200200907E +S315E6310AD0014C02B91C0000146100805220020090DC +S315E6310AE0015802B92100805220020090014C02B928 +S315E6310AF0150000146100805220020090015802B9B7 +S315E6310B004100805220020090014C02B90E000014D9 +S315E6310B104100805220020090015802B921008052EC +S315E6310B2020020090014C02B90700001441008052C0 +S315E6310B3020020090015802B96100805220020090ED +S315E6310B40014C02B913008052B3F8FF35F30B40F985 +S315E6310B50FD7BC7A8C0035FD6FD7BB9A9FD0300912E +S315E6310B60F30B00F9200200901F5402B9210080529E +S315E6310B70C00000D000C01591A6D2FF972100805261 +S315E6310B80C00000D000C01A91A2D2FF972100805250 +S315E6310B90C00000D000601B919ED2FF9721008052A3 +S315E6310BA0C00000D000201C919AD2FF9721008052D6 +S315E6310BB0C00000D000E01C9196D2FF97210080520A +S315E6310BC0C00000D000A01D9192D2FF97210080523D +S315E6310BD0C00000D000601E918ED2FF972100805270 +S315E6310BE0C00000D000201F918AD2FF973300805291 +S315E6310BF03C00001401008052C00000D000801A91FA +S315E6310C0084D2FF97A1BF0091A0C30091B1D2FF97DD +S315E6310C10A0C3403900C400511F14007128060054A0 +S315E6310C20610000F021901A91204860386100001089 +S315E6310C302088208B00001FD62100805220020090AA +S315E6310C40015802B98100805220020090014C02B966 +S315E6310C50230000142100805220020090015802B987 +S315E6310C604100805220020090014C02B91C0000146A +S315E6310C708100805220020090015802B9210080524B +S315E6310C8020020090014C02B9150000148100805211 +S315E6310C9020020090015802B94100805220020090AC +S315E6310CA0014C02B90E000014410080522002009038 +S315E6310CB0015802B92100805220020090014C02B956 +S315E6310CC0070000144100805220020090015802B913 +S315E6310CD08100805220020090014C02B91300805205 +S315E6310CE0B3F8FF35F30B40F9FD7BC7A8C0035FD6F2 +S315E6310CF0FD7BBFA9FD030091B3D5FF971F180071A0 +S315E6310D00A8040054610000F021B01A9120486038F9 +S315E6310D10610000102088208B00001FD6210080520A +S315E6310D20C00000D000E01F913AD2FF9725FFFF972A +S315E6310D301D00001421008052A00000F000801891B9 +S315E6310D4034D2FF971FFFFF97170000142100805218 +S315E6310D50C00000D0002020912ED2FF9719FFFF97D1 +S315E6310D601100001421008052A00000F000E0189135 +S315E6310D7028D2FF9779FFFF970B00001421008052A6 +S315E6310D80A00000F000A0199122D2FF970DFFFF9740 +S315E6310D900500001421008052C00000D00060209189 +S315E6310DA01CD2FF97FD7BC1A8C0035FD60004005174 +S315E6310DB01F0C0071E80A0054FD7BBFA9FD030091C3 +S315E6310DC0610000F021D01A912048603861000010A8 +S315E6310DD02088208B00001FD621008052C00000D02B +S315E6310DE000A020910BD2FF9721008052200200907D +S315E6310DF0015402B90120905220020090015C02B9F9 +S315E6310E00210084520103A07220020090014402B906 +S315E6310E106DD5FF97610000F02180029120D860F808 +S315E6310E2000003FD63900001421008052C00000D0C0 +S315E6310E3000E02091F7D1FF976100805220020090C1 +S315E6310E40015402B921008052C10FA07220020090EE +S315E6310E50014402B95CD5FF97610000F0218000912B +S315E6310E6020D860F800003FD62800001421008052D1 +S315E6310E70C00000D000202191E6D1FF974100805293 +S315E6310E8020020090015402B90100905220020090EE +S315E6310E90015C02B9214080520104A0722002009021 +S315E6310EA0014402B948D5FF97610000F021800191EE +S315E6310EB020D860F800003FD6140000142100805295 +S315E6310EC0C00000D000602191D2D1FF9781008052D7 +S315E6310ED020020090015402B901209052200200907E +S315E6310EE0015C02B9214080520104A07220020090D1 +S315E6310EF0014402B934D5FF97610000D021803F9194 +S315E6310F0020D860F800003FD6FD7BC1A8C0035FD686 +S315E6310F10C0035FD6FD7BBFA9FD0300912100805258 +S315E6310F20C00000D000C02191BAD1FF9771FFFF977B +S315E6310F3001008052C00000D000E02291B5D1FF9782 +S315E6310F4020020090005842B999FFFF9763F5FF9763 +S315E6310F5077F5FF974017003501008052C00000D083 +S315E6310F6000202391ABD1FF9701008052C00000D01B +S315E6310F7000C02391A7D1FF97E21F80520180B512B7 +S315E6310F800000AA527EECFF97A00480525DD2FF970D +S315E6310F9020020090005442B91F0400714101005409 +S315E6310FA0E22311320100AA520000805217E0FF9780 +S315E6310FB021008052C00000D00060249195D1FF9780 +S315E6310FC0210000141F0C007141010054E223113255 +S315E6310FD00100AA5200008052F003009421008052AB +S315E6310FE0C00000D0006024918AD1FF971600001424 +S315E6310FF01F08007141010054E22311320100AA5261 +S315E6311000000080529AE1FF9721008052C00000B07D +S315E6311010006024917FD1FF970B0000141F100071F9 +S315E631102021010054E22311320100AA520000805216 +S315E63110303FDFFF9721008052C00000B00060249167 +S315E631104074D1FF9721008052A00000F000A02B91C9 +S315E631105070D1FF9701008052C00000B00080249124 +S315E63110606CD1FF97000200F0004C42B950FFFF9772 +S315E63110701AF5FF972EF5FF97200E0035000200F0A0 +S315E6311080005442B91F040071210200540100805216 +S315E6311090C00000B000C024915ED1FF97E1FF8F52C8 +S315E63110A00000805218E1FF9701008052C00000B07F +S315E63110B00040259157D1FF97E1FF8F52E11FA0728C +S315E63110C000008052F9E0FF97280000141F0C0071EA +S315E63110D04101005401008052C00000B00040259124 +S315E63110E04CD1FF97E1FF8F52E11FA072000080528B +S315E63110F0090400941D0000141F08007141010054D3 +S315E631110001008052C00000B00040259141D1FF97E1 +S315E6311110E1FF8F52E11FA072000080526FE2FF9726 +S315E6311120120000141F1000710102005401008052B2 +S315E6311130C00000B000C0249136D1FF97E1FF8F524F +S315E63111400000805283DFFF9701008052C00000B075 +S315E6311150004025912FD1FF97E1FF8F52E11FA07213 +S315E63111600000805265DFFF9701008052C00000B073 +S315E63111700080259127D1FF97000200F0005442B94D +S315E63111801F04007141010054E223113201008052FD +S315E63111900000AA52AEE0FF9721008052C00000B0AF +S315E63111A0006024911BD1FF97250000141F0C0071B6 +S315E63111B0C101005400058052FEEDFF97E22311325C +S315E63111C0010080520000AA52BE030094000A805202 +S315E63111D0F8EDFF9721008052C00000B000602491FF +S315E63111E00CD1FF97160000141F0800714101005417 +S315E63111F0E2231132010080520000AA52F5E1FF974F +S315E631120021008052C00000B00060249101D1FF97E1 +S315E63112100B0000141F10007121010054E223113234 +S315E6311220010080520000AA521DDFFF97210080524D +S315E6311230C00000B000602491F6D0FF97FD7BC1A8CF +S315E6311240C0035FD6FD7BBFA9FD0300912100805225 +S315E6311250C00000B000202691EED0FF9721008052E3 +S315E6311260C00000B000C02691EAD0FF972100805237 +S315E6311270C00000B000602791E6D0FF97210080528A +S315E6311280A00000F000A02B91E2D0FF9787F4FF97FC +S315E631129092F4FF97A6F4FF97E0020035000200F0DC +S315E63112A0005442B91F040071610000543AEDFF97CC +S315E63112B0080000141F0800716100005400EDFF9725 +S315E63112C0040000141F0C007141000054E90000943B +S315E63112D0000200F0005442B91F100071410000547B +S315E63112E0F7ECFF9721008052C00000B0000028914C +S315E63112F0C8D0FF97FD7BC1A8C0035FD6FD7BBAA9EF +S315E6311300FD030091F35301A93DC6FF9723C6FF9727 +S315E631131021008052C00000B000602891BDD0FF9711 +S315E631132062F4FF976DF4FF9781F4FF97E007003596 +S315E6311330000200F0005442B91F040071A1000054C6 +S315E63113400100AB520000805285E0FF970C00001495 +S315E63113501F080071A10000540100AB520000805213 +S315E6311360F4E1FF97060000141F0C0071810000546A +S315E63113700100AB52000080527D030094800080D29A +S315E63113800000ABF2140040B900100091130040B9E9 +S315E631139082008052A18300910000ABD2000040B9B1 +S315E63113A0EAD1FF9701008052C00000B000A0299132 +S315E63113B098D0FF9721008052A083009195D0FF9770 +S315E63113C082008052A1830091E003142ADFD1FF9790 +S315E63113D001008052C00000B000202A918DD0FF97DF +S315E63113E021008052A08300918AD0FF9782008052F5 +S315E63113F0A1830091E003132AD4D1FF9701008052ED +S315E6311400C00000B000A02A9182D0FF972100805219 +S315E6311410A08300917FD0FF9721008052C00000B0B3 +S315E631142000400E917BD0FF97F35341A9FD7BC6A8C9 +S315E6311430C0035FD6FD7BBEA9FD030091F30B00F930 +S315E6311440EFC5FF97D5C5FF9721008052C00000B0A2 +S315E6311450006028916FD0FF9714F4FF971FF4FF973A +S315E631146033F4FF97E00E0035000200F0005442B93E +S315E63114701F040071C1000054020084520100AB52D0 +S315E631148000008052E1DEFF970C0000141F08007160 +S315E6311490A10000540100AB5200008052A5E1FF974E +S315E63114A0060000141F0C0071810000540100AB5296 +S315E63114B0000080522E03009401008052C00000B035 +S315E63114C000A0299153D0FF970000ABD24BFBFF9793 +S315E63114D01F040071600000541300805202000014AC +S315E63114E03300805201008052C00000B000202A91BC +S315E63114F048D0FF97800080D20000ABF23FFBFF97E2 +S315E63115001F040071410000543300805201008052BD +S315E6311510C00000B000A02A913ED0FF97000180D2EC +S315E63115200000ABF235FBFF971F0400714100005412 +S315E63115303300805273080034000200F0005442B999 +S315E63115401F0400712101005401008052C00000B031 +S315E631155000C00F912FD0FF97E1FF835200008052F2 +S315E6311560E9DFFF97140000141F08007121010054CA +S315E631157001008052C000009000603B9125D0FF9774 +S315E6311580610080520000805254E1FF970A00001450 +S315E63115901F0C00710101005401008052C000009019 +S315E63115A000603B911BD0FF9761008052000080526C +S315E63115B0D9020094EC01009401008052C0000090FB +S315E63115C000E0379113D0FF97000200F0005442B99C +S315E63115D01F040071C100005402008452010080529A +S315E63115E00000AB529ADFFF97120000141F08007114 +S315E63115F0C10000548200A052010080520000AB5275 +S315E6311600DEE0FF970B0000141F0C00712101005438 +S315E631161000058052E7ECFF978200A0520100805226 +S315E63116200000AB52A7020094000A8052E1ECFF9724 +S315E631163021008052C000009000403891F5CFFF97E7 +S315E6311640F30B40F9FD7BC2A8C0035FD6000000006C +S315E6311650E10300AA00103ED500F8739200101ED5BC +S315E6311660DF3F03D51F7108D5DF3F03D520001FD6EF +S315E6311670000200F001DC40B900E089523F00006B20 +S315E631168061010054000200F000D040B91F3C007100 +S315E6311690E8000054614C80528100B072800F80D2EE +S315E63116A000C4BDF2010000B906000014614C805257 +S315E63116B0E100B072800F80D200C4BDF2010000B9FC +S315E63116C021609E52E13FA07200C4BDD2010000B94D +S315E63116D001208052E103A07200300091010000B989 +S315E63116E00114A05200100091010000B901809A520E +S315E63116F04144B47200300091010000B9C101805213 +S315E631170000F00091010000B921208A5200100091C3 +S315E6311710010000B981288252212AA47200900091F3 +S315E6311720010000B941008052E1E0A072002000914B +S315E6311730010000B9C0035FD6FD7BBFA9FD03009169 +S315E6311740000A8052B1F0FF97FD7BC1A8C0035FD690 +S315E6311750FD7BBEA9FD030091F35301A9F40301AA6A +S315E6311760F303022A010200F022DC40B901E0895294 +S315E63117705F00016B61010054010200F021D040B9EE +S315E63117803F3C0071E8000054624C80520200B07270 +S315E6311790810F80D201C4BDF2220000B906000014E1 +S315E63117A0624C80526200B072810F80D201C4BDF2C2 +S315E63117B0220000B922609E52E23FB07201C4BDD228 +S315E63117C0220000B90210A05221900091220000B900 +S315E63117D0007C015321100091200000B9800580D2AA +S315E63117E000C4BDF21F0000B9C101805200D000919C +S315E63117F0010000B921208A5200100091010000B99A +S315E63118007F120071600100547F220071E0010054BD +S315E63118107F0A00714102005401819A524144B47201 +S315E6311820000680D200C4BDF2010000B90C000014F6 +S315E631183081819A524144B472000680D200C4BDF227 +S315E6311840010000B906000014E1819A524144B472AE +S315E6311850000680D200C4BDF2010000B9A100805273 +S315E6311860000480D200C4BDF2010000B969ECFF97ED +S315E63118707F220071A1000054000780D200C4BDF278 +S315E6311880000040B9800600B9800780D200C4BDF2B7 +S315E6311890000040B9800200B9F35341A9FD7BC2A8E5 +S315E63118A0C0035FD6FD7BBFA9FD030091020200F0BE +S315E63118B043DC40B902E089527F00026B6101005494 +S315E63118C0020200F042D040B95F3C0071E8000054B4 +S315E63118D0634C80520300B072820F80D202C4BDF2ED +S315E63118E0430000B906000014634C80526300B072BF +S315E63118F0820F80D202C4BDF2430000B923609E5204 +S315E6311900E33FB07202C4BDD2430000B942900091C2 +S315E63119105F0000B942100091400000B9800580D2DF +S315E631192000C4BDF21F0000B922208A5200E00091C0 +S315E6311930020000B902818A524244B472000680D26C +S315E631194000C4BDF2020000B900400091010000B9C1 +S315E631195061008052000480D200C4BDF2010000B9B4 +S315E63119602CECFF97FD7BC1A8C0035FD6FD7BBFA9F3 +S315E6311970FD030091020200F043DC40B902E08952F0 +S315E63119807F00026B61010054020200F042D040B999 +S315E63119905F3C0071E8000054634C80520300B0723C +S315E63119A0820F80D202C4BDF2430000B906000014AC +S315E63119B0634C80526300B072820F80D202C4BDF2AC +S315E63119C0430000B923609E52E33FB07202C4BDD2F2 +S315E63119D0430000B9429000915F0000B9007C0153A3 +S315E63119E042100091400000B9800580D200C4BDF2B4 +S315E63119F01F0000B922208A5200E00091020000B9A8 +S315E6311A0082818A524244B472000680D200C4BDF263 +S315E6311A10020000B9213C00530040009101000079F3 +S315E6311A2061008052000480D200C4BDF2010000B9E3 +S315E6311A30F8EBFF97FD7BC1A8C0035FD6001180D2D4 +S315E6311A4000C4BDF2000040B9A000083600781E1287 +S315E6311A50011180D201C4BDF2200000B9C0035FD6C0 +S315E6311A60FD7BBEA9FD030091F30B00F9F30301AA51 +S315E6311A70010200F022DC40B901E089525F00016BD8 +S315E6311A8061010054010200F021D040B93F3C0071BA +S315E6311A90E8000054624C80520200B072810F80D267 +S315E6311AA001C4BDF2220000B906000014624C805230 +S315E6311AB06200B072810F80D201C4BDF2220000B954 +S315E6311AC022609E52E23FB07201C4BDD2220000B915 +S315E6311AD00210A05221900091220000B9007C0153F8 +S315E6311AE021100091200000B9800580D200C4BDF2F4 +S315E6311AF01F0000B9C101805200D00091010000B942 +S315E6311B0021208A5200100091010000B9E1819A52F2 +S315E6311B104144B472000680D200C4BDF2010000B978 +S315E6311B20A1008052000480D200C4BDF2010000B9A2 +S315E6311B30B8EBFF97000780D200C4BDF2000040B98A +S315E6311B40600600B9800780D200C4BDF2000040B914 +S315E6311B50600200B9F30B40F9FD7BC2A8C0035FD63C +S315E6311B60FD7BBEA9FD030091F30B00F9F30300AA51 +S315E6311B700100AE52A0AA80524BFFFF97E10313AAAA +S315E6311B8000008052B7FFFF97031C0812011C1012A2 +S315E6311B90215C18532220432A013C48D34100012ACD +S315E6311BA0001C18532000002A003C0053F30B40F981 +S315E6311BB0FD7BC2A8C0035FD623608052E33FA072A5 +S315E6311BC0820180D202C4BDF2430000B9020200F0BE +S315E6311BD043DC40B902E089527F00026B8101005451 +S315E6311BE0020200F042D040B95F3C00710801005470 +S315E6311BF0E34E80520300B072820F80D202C4BDF248 +S315E6311C00430000B9020080D20D000014E34E805243 +S315E6311C106300B072820F80D202C4BDF2430000B9CE +S315E6311C20F9FFFF17E303012A646862B8030090D22D +S315E6311C3003C4BDF2446823B8421000915FFC03F158 +S315E6311C4029FFFF54FD7BBFA9FD03009122609E5219 +S315E6311C50E23FB07201C4BDD2220000B921900091B3 +S315E6311C603F0000B921100091200000B9800580D2ED +S315E6311C7000C4BDF21F0000B921208A5200E000916E +S315E6311C80010000B9E1818A524144B472000680D23C +S315E6311C9000C4BDF2010000B961008052000480D271 +S315E6311CA000C4BDF2010000B95AEBFF97000200F01D +S315E6311CB001DC40B900E089523F00006B4101005436 +S315E6311CC0000200F000D040B91F3C0071C800005454 +S315E6311CD0614E8052800F80D200C4BDF2010000B958 +S315E6311CE006000014614E80526100A072800F80D2E8 +S315E6311CF000C4BDF2010000B921608052E13FA07215 +S315E6311D00800180D200C4BDF2010000B9FD7BC1A8D5 +S315E6311D10C0035FD6FD7BBEA9FD030091F35301A94E +S315E6311D20F303002AF403012A0140B552A0AA8052F0 +S315E6311D30DDFEFF9701A0AA5240558052DAFEFF97A3 +S315E6311D400100B452A0AA8052D7FEFF97E103142AC6 +S315E6311D50607E015399FFFF97F35341A9FD7BC2A8F4 +S315E6311D60C0035FD6FD7BBFA9FD0300910100BE52DC +S315E6311D7000008052CCFEFF97FD7BC1A8C0035FD63B +S315E6311D80FD7BBCA9FD030091F35301A9F51300F9D7 +S315E6311D90F50300AA0140B552A0AA8052C2FEFF97CA +S315E6311DA001A0AA5240558052BFFEFF970100B252BA +S315E6311DB0A0AA8052BCFEFF971300805214008052CF +S315E6311DC01E00001402018052A1E30091E003142AB9 +S315E6311DD060FEFF97A13B40B9227C1053000200F02A +S315E6311DE0008009910258337862060011017822782B +S315E6311DF0A23F40B9447C1053630A00110478237834 +S315E6311E00630E0011027823787312001154010035FE +S315E6311E10201C0812221C1012425C18534220402A1A +S315E6311E20203C48D34000002A211C18530000012AE1 +S315E6311E30A00200B9942200119F3E007149FCFF547D +S315E6311E40C9FFFF9700008052F35341A9F51340F9D4 +S315E6311E50FD7BC4A8C0035FD6FD7BBDA9FD0300911A +S315E6311E60F35301A9F303002AF403012A0140B552DB +S315E6311E70A0AA80528CFEFF9701A0AA524055805205 +S315E6311E8089FEFF970100B452A0AA805286FEFF97DB +S315E6311E90E103142AE003132AB5FEFF97A0A30091C6 +S315E6311EA030FFFF97C0FF3F36F35341A9FD7BC3A809 +S315E6311EB0C0035FD6FD7BBDA9FD030091F30B00F9A7 +S315E6311EC0F303002A0140B552A0AA805276FEFF9767 +S315E6311ED001A0AA524055805273FEFF970100B052D7 +S315E6311EE0A0AA805270FEFF970140B552A0AA805251 +S315E6311EF06DFEFF9701A0AA52405580526AFEFF97C2 +S315E6311F000100A652607E015367FEFF97A0A30091BA +S315E6311F1014FFFF97C0FF3F36F30B40F9FD7BC3A8AD +S315E6311F20C0035FD6FD7BBEA9FD0300910140B552E4 +S315E6311F30A0AA80525CFEFF9701A0AA524055805274 +S315E6311F4059FEFF970100B052A0AA805256FEFF977E +S315E6311F500140B552A0AA805253FEFF9701A0AA527C +S315E6311F604055805250FEFF970100A252A0AA8052F8 +S315E6311F704DFEFF97A0630091FAFEFF978000283762 +S315E6311F80A0FF3F3600008052020000142000805246 +S315E6311F90FD7BC2A8C0035FD6FD7BBDA9FD030091DB +S315E6311FA0F35301A9F51300F9F403002AF303012AE1 +S315E6311FB0F503022AAFFDFF97E203152A0100A15286 +S315E6311FC08102010BE003132AE3F1FF97F35341A9AB +S315E6311FD0F51340F9FD7BC3A8C0035FD6FD7BBCA9EB +S315E6311FE0FD030091F35301A9F51300F9F403002A31 +S315E6311FF0F503022AA13F00B9F303002A05000014CE +S315E6312000A1F30091E003132A96FEFF9773120011AE +S315E63120108002150B7F02006B43FFFF54F35341A950 +S315E6312020F51340F9FD7BC4A8C0035FD6FD7BBDA998 +S315E6312030FD030091F35301A9F55B02A9F40300AA66 +S315E6312040F503012AF603022A7DFEFF97F303152AE5 +S315E631205005000014814640B8E003132A7FFFFF9757 +S315E631206073120011A002160B7F02006B43FFFF5479 +S315E6312070F35341A9F55B42A9FD7BC3A8C0035FD6FD +S315E6312080FD7BBDA9FD030091F35301A9F303002AB4 +S315E6312090F403012A6AFEFF97E103142AE003132AC1 +S315E63120A01DFFFF975BEAFF97A0A30091ADFEFF9771 +S315E63120B0C0FF3F36F35341A9FD7BC3A8C0035FD6C4 +S315E63120C0FD7BBDA9FD030091F35301A9F55B02A999 +S315E63120D0F403002AF503012AF603022AF303012A59 +S315E63120E006000014E103142AE003132AE5FFFF97FD +S315E63120F09402041173020411A002160B7F02006BDF +S315E631210023FFFF54F35341A9F55B42A9FD7BC3A8EF +S315E6312110C0035FD6FD7BBEA9FD030091F35301A94A +S315E631212013340E1234340E1208000014E003132A67 +S315E631213061FFFF9701008052A00000F00000379161 +S315E631214034CDFF97730241117F02146B09FFFF54B9 +S315E631215021008052A00000D000802F912DCDFF972F +S315E6312160F35341A9FD7BC2A8C0035FD6FD7BBFA968 +S315E6312170FD0300918200A05200340E1287FFFF97CD +S315E6312180FD7BC1A8C0035FD6FD7BB9A9FD030091EE +S315E6312190F30B00F9000280520E020094000200D0E1 +S315E63121A0001842B91F040071C8270054000200D056 +S315E63121B00050433900101D72E2179F1A1F800071D5 +S315E63121C0E1179F1A4100012A2105003580000014E6 +S315E63121D0000200D000E440B9A1F2AE521F00016B15 +S315E63121E0C1000054600000B000E01A91004873382F +S315E63121F0A02F00B91400001421028052A1F2AE726A +S315E63122001F00016BE1000054600000B000E01A9156 +S315E631221000C0009100487338A02F00B90A000014B7 +S315E631222041028052A1F2AE721F00016BC100005429 +S315E6312230600000B000E01A910080019100487338E1 +S315E6312240A02F00B924008052A3B30091E203132AEA +S315E63122500114805200028052E2030094200080523B +S315E631226040C3FF9773060011020000141300805233 +S315E63122707FB20071E9FAFF54130080525000001420 +S315E6312280000200D000E440B9A1F2AE521F00016B64 +S315E6312290C1000054600000B000E01A91004873387E +S315E63122A0A02F00B91400001421028052A1F2AE72B9 +S315E63122B01F00016BE1000054600000B000E01A91A6 +S315E63122C000C0009100487338A02F00B90A00001407 +S315E63122D041028052A1F2AE721F00016BC100005479 +S315E63122E0600000B000E01A91008001910048733831 +S315E63122F0A02F00B924008052A3A30091E203132A4A +S315E63123000114805200028052ED020094A02F40B9AA +S315E6312310A12B40B93F00006B0005005421008052E5 +S315E6312320C000009000202B91BACCFF970100805275 +S315E6312330C000009000802B91B6CCFF978200805288 +S315E6312340A1C30091E003132A00CEFF972100805204 +S315E6312350A0C30091AFCCFF9701008052C000009038 +S315E631236000002C91ABCCFF9782008052A1C300913D +S315E6312370A02B40B9F5CDFF9721008052A0C300913D +S315E6312380A4CCFF9701008052C000009000802C91CA +S315E6312390A0CCFF9782008052A1C30091A02F40B90D +S315E63123A0EACDFF9721008052A0C3009199CCFF97E1 +S315E63123B020008052FB000014730600117FB20071D3 +S315E63123C009F6FF5400008052F60000141F20007112 +S315E63123D0E10900540F000014600000B000E01A91E4 +S315E63123E000487338A3C3019160CC1BB824008052F0 +S315E63123F0E203132A011480520002805279030094D3 +S315E631240020008052D7C2FF977306001102000014EE +S315E6312410130080527FB2007109FEFF5413008052D9 +S315E631242037000014600000B000E01A9100487338B6 +S315E6312430A02F00B924008052A3A30091E203132A08 +S315E631244001148052000280529D020094A02F40B9B9 +S315E6312450A12B40B93F00006B0005005421008052A4 +S315E6312460C000009000202B916ACCFF970100805284 +S315E6312470C000009000802B9166CCFF978200805297 +S315E6312480A1C30091E003132AB0CDFF972100805214 +S315E6312490A0C300915FCCFF9701008052C000009047 +S315E63124A000002C915BCCFF9782008052A1C300914C +S315E63124B0A02B40B9A5CDFF9721008052A0C300914C +S315E63124C054CCFF9701008052C000009000802C91D9 +S315E63124D050CCFF9782008052A1C30091A02F40B91C +S315E63124E09ACDFF9721008052A0C3009149CCFF9740 +S315E63124F020008052AB000014730600117FB20071E2 +S315E631250029F9FF5400008052A60000141F400071DD +S315E6312510E1179F1A1F600171E0179F1A2000002A02 +S315E6312520200200359F000014600000B000E01A91E9 +S315E631253000C0009100487338A3C3019160CC1BB843 +S315E631254024008052E203132A01148052000280529B +S315E6312550240300942000805282C2FF97730600114D +S315E631256002000014130080527FB20071E9FDFF5478 +S315E63125701300805238000014600000B000E01A9172 +S315E631258000C0009100487338A02F00B9240080526C +S315E6312590A3A30091E203132A01148052000280526A +S315E63125A047020094A02F40B9A12B40B93F00006BFA +S315E63125B00005005421008052C000009000202B9186 +S315E63125C014CCFF9701008052C000009000802B9119 +S315E63125D010CCFF9782008052A1C30091E003132A03 +S315E63125E05ACDFF9721008052A0C3009109CCFF97BF +S315E63125F001008052C000009000002C9105CCFF9777 +S315E631260082008052A1C30091A02B40B94FCDFF97EE +S315E631261021008052A0C30091FECBFF970100805284 +S315E6312620C000009000802C91FACBFF978200805251 +S315E6312630A1C30091A02F40B944CDFF972100805226 +S315E6312640A0C30091F3CBFF972000805255000014CA +S315E6312650730600117FB2007109F9FF54000080520A +S315E631266050000014600000B000E01A91004002917B +S315E631267000487338A3C3019160CC1BB8240080525D +S315E6312680E203132A0114805200028052D5020094E5 +S315E63126902000805233C2FF97730600110200001400 +S315E63126A0130080527FD60071E9FDFF541300805244 +S315E63126B038000014600000B000E01A910040029143 +S315E63126C000487338A02F00B924008052A3A30091A5 +S315E63126D0E203132A0114805200028052F801009473 +S315E63126E0A02F40B9A12B40B93F00006B000500543D +S315E63126F021008052C000009000202B91C5CBFF9778 +S315E631270001008052C000009000802B91C1CBFF972B +S315E631271082008052A1C30091E003132A0BCDFF97C5 +S315E631272021008052A0C30091BACBFF9701008052B7 +S315E6312730C000009000002C91B6CBFF978200805204 +S315E6312740A1C30091A02B40B900CDFF97210080525D +S315E6312750A0C30091AFCBFF9701008052C000009035 +S315E631276000802C91ABCBFF9782008052A1C30091BA +S315E6312770A02F40B9F5CCFF9721008052A0C3009136 +S315E6312780A4CBFF9720008052060000147306001191 +S315E63127907FD6007109F9FF5400008052010000141A +S315E63127A0F30B40F9FD7BC7A8C0035FD6FD7BBEA917 +S315E63127B0FD03009100028052860000942400805287 +S315E63127C0A3730091E203042A011480520002805277 +S315E63127D0BB010094A01F40B9FD7BC2A8C0035FD6FA +S315E63127E0010200D0211842B93F040071C8030054F2 +S315E63127F0010200D02150433921101D72E3179F1A89 +S315E63128003F800071E2179F1A6200022AA201003464 +S315E6312810010200D021E440B9A2F2AE523F00026B8A +S315E631282060020054424400113F00026B40020054FC +S315E6312830420400113F00026BC1020054100000143D +S315E63128403F200071000200543F400071E2179F1AA3 +S315E63128503F600171E1179F1A4100012A8101003576 +S315E6312860C0035FD620028052C0035FD6E0018052B4 +S315E6312870C0035FD6C0018052C0035FD600028052E4 +S315E6312880C0035FD6E0018052C0035FD6C0018052F5 +S315E6312890C0035FD6FD7BB9A9FD030091F30B00F9C1 +S315E63128A0000280524B00009421008052A00000D0F5 +S315E63128B000A02B9157CBFF9721008052C0000090A4 +S315E63128C000002D9153CBFF9721008052C000009036 +S315E63128D000A02D914FCBFF971300805219000014BB +S315E63128E024008052A3B30091E203132A01148052E5 +S315E63128F0000280527201009401008052C0000090BD +S315E631290000802E9143CBFF9722008052A1C30091DE +S315E6312910A02F40B98DCCFF9701008052A0C300911C +S315E63129203CCBFF9721008052600000B000E01A915F +S315E631293000200391005873F836CBFF9773060011E2 +S315E63129407FD60071E9FCFF54F30B40F9FD7BC7A84E +S315E6312950C0035FD6FD7BBEA9FD030091000280521E +S315E63129601C00009424008052A373009142008052E9 +S315E6312970010C80520002805251010094A01F40B9E9 +S315E6312980FD7BC2A8C0035FD6C0035FD6803481D251 +S315E6312990A0C2BCF2000040B90001D036007805127B +S315E63129A0E203202A012081D2A1C2BCF2220000B97B +S315E63129B021500291200000B9C0035FD6FD7BBFA945 +S315E63129C0FD030091F2FFFF97FD7BC1A8C0035FD6F9 +S315E63129D01F400071C1000054FD7BBFA9FD03009184 +S315E63129E0F7FFFF97FD7BC1A8C0035FD6C0035FD66D +S315E63129F0800180D260C1BCF21F000039000180D26D +S315E6312A0060C1BCF21F000039800080D260C1BCF2E1 +S315E6312A101F000039C0035FD6FD7BBFA9FD030091D8 +S315E6312A20840080D264C1BCF29F000039830040390C +S315E6312A3063601932631C005383000039C500805246 +S315E6312A40030280D263C1BCF265000039650080526B +S315E6312A506310009165000039850180D265C1BCF20B +S315E6312A60A300403963140012A3000039A3004039AC +S315E6312A70631C005363040032A3000039630D8012F0 +S315E6312A80830000392400805203008052120000147C +S315E6312A90050180D265C1BCF2A50040394500003654 +S315E6312AA00400805263040011E5478852E501A072BD +S315E6312AB07F00056B0901005421008052C00000B049 +S315E6312AC000801B91D3CAFF97CAFFFF972000805239 +S315E6312AD0F9000014E4FDFF35850180D265C1BCF20B +S315E6312AE0A300403963181F12A3000039001C0053B6 +S315E6312AF063C1BCD2600000392500805203008052A2 +S315E6312B0012000014060180D266C1BCF2C600403915 +S315E6312B1046000836E503042A63040011E64788527F +S315E6312B20E601A0727F00066B09010054210080524E +S315E6312B30C00000B000201C91B6CAFF97ADFFFF97E3 +S315E6312B4020008052DC000014E5FDFF35211C0053E0 +S315E6312B5063C1BCD261000039630D8012810080D237 +S315E6312B6061C1BCF223000039830180D263C1BCF274 +S315E6312B7061004039211C00532100003261000039E1 +S315E6312B80030180D263C1BCF261004039211C005396 +S315E6312B9021781E12211C0053610000392300805230 +S315E6312BA00100805212000014040180D264C1BCF2E5 +S315E6312BB08400403944000836E303052A210400112E +S315E6312BC0E4478852E401A0723F00046B09010054E0 +S315E6312BD021008052C00000B000A01C918DCAFF973B +S315E6312BE084FFFF9720008052B3000014E3FDFF35E2 +S315E6312BF0040180D264C1BCF281004039211C005304 +S315E6312C0021781E12211C005381000039240080529E +S315E6312C100100805212000014050180D265C1BCF272 +S315E6312C20A500403945000036E403032A21040011A4 +S315E6312C30E5478852E501A0723F00056B090100546C +S315E6312C4021008052C00000B000201D9171CAFF9765 +S315E6312C5068FFFF972000805297000014E4FDFF35A8 +S315E6312C60830180D263C1BCF261004039211C005335 +S315E6312C7021001F32610000396100403921181F12E7 +S315E6312C806100003900040011001C005361C1BCD259 +S315E6312C9020000039210080520000805212000014D3 +S315E6312CA0030180D263C1BCF2630040394300083682 +S315E6312CB0E103042A00040011E3478852E301A072D6 +S315E6312CC01F00036B0901005421008052C00000B099 +S315E6312CD000A01D914FCAFF9746FFFF97200080520D +S315E6312CE075000014E1FDFF35C30F8012800080D2F6 +S315E6312CF060C1BCF203000039030180D263C1BCF284 +S315E6312D0060004039001C005300781E12001C005347 +S315E6312D106000003923008052000080521200001410 +S315E6312D20040180D264C1BCF28400403944000836DD +S315E6312D30E303012A00040011E4478852E401A07254 +S315E6312D401F00046B0901005421008052C00000B017 +S315E6312D5000401E912FCAFF9726FFFF97200080522B +S315E6312D6055000014E3FDFF35810180D261C1BCF225 +S315E6312D7020004039001C00530000003220000039A3 +S315E6312D80E1078012800080D260C1BCF201000039D1 +S315E6312D90010180D261C1BCF220004039001C0053EA +S315E6312DA000781E12001C00532000003924008052A0 +S315E6312DB00000805212000014010180D261C1BCF2DA +S315E6312DC02100403941000036E403032A00040011AC +S315E6312DD0E1478852E101A0721F00016B09010054F7 +S315E6312DE021008052C00000B000E01E9109CAFF976B +S315E6312DF000FFFF97200080522F000014E4FDFF35D7 +S315E6312E00810180D261C1BCF220004039001C0053F9 +S315E6312E1000781E12001C00532000003960C1BCD276 +S315E6312E2000004039001C0053400000B922008052B0 +S315E6312E300100805214000014000180D260C1BCF258 +S315E6312E400000403900041A121F0003714100005494 +S315E6312E50E203042A21040011E0478852E001A07218 +S315E6312E603F00006B0901005421008052C00000B0DA +S315E6312E7000801F91E7C9FF97DEFEFF97200080525B +S315E6312E800D000014A2FDFF35000180D260C1BCF20F +S315E6312E901F000039001000911F000039810080D2F1 +S315E6312EA061C1BCF220004039001800122000003919 +S315E6312EB000008052FD7BC1A8C0035FD61F4000717A +S315E6312EC0A1010054FD7BBFA9FD030091E60303AAE8 +S315E6312ED0E503022AE003012AE303042AE20306AA0A +S315E6312EE0E103052ACDFEFF9700008052FD7BC1A89E +S315E6312EF0C0035FD600008052C0035FD6FD7BBFA913 +S315E6312F00FD030091840080D264C1BCF29F00003992 +S315E6312F108300403963601932631C005383000039FC +S315E6312F2065018052030280D263C1BCF26500003985 +S315E6312F30E50080526310009165000039850180D243 +S315E6312F4065C1BCF2A300403963140012A30000390F +S315E6312F50A3004039631C005363040032A3000039F1 +S315E6312F60630D8012830000392400805203008052BB +S315E6312F7012000014050180D265C1BCF2A5004039C4 +S315E6312F80450000360400805263040011E547885255 +S315E6312F90E501A0727F00056B0901005421008052DC +S315E6312FA0C00000B000E01F919AC9FF9791FEFF97E6 +S315E6312FB02000805289000014E4FDFF35850180D278 +S315E6312FC065C1BCF2A300403963181F12A30000396C +S315E6312FD0001C005363C1BCD2600000392300805225 +S315E6312FE00000805212000014050180D265C1BCF2A0 +S315E6312FF0A500403945000836E303042A00040011EA +S315E6313000E5478852E501A0721F00056B09010054B8 +S315E631301021008052C0000090008020917DC9FF9743 +S315E631302074FEFF97200080526C000014E3FDFF35F5 +S315E6313030211C005360C1BCD201000039010180D2A6 +S315E631304061C1BCF220004039001C005300781E12E3 +S315E6313050001C0053200000392100805200008052C6 +S315E631306012000014040180D264C1BCF284004039F6 +S315E631307044000836E103032A00040011E447885286 +S315E6313080E401A0721F00046B09010054210080524D +S315E6313090C0000090000021915EC9FF9755FEFF976B +S315E63130A0200080524D000014E1FDFF3542004039E3 +S315E63130B060C1BCD202000039E20D801200100091E7 +S315E63130C002000039020180D262C1BCF240004039C9 +S315E63130D0001C005300781E12001C005340000039D4 +S315E63130E0230080520000805212000014020180D281 +S315E63130F062C1BCF24200403942000836E303012A96 +S315E631310000040011E2478852E201A0721F00026B09 +S315E63131100901005421008052C000009000A021919F +S315E63131203CC9FF9733FEFF97200080522B000014EF +S315E6313130E3FDFF35010180D261C1BCF220004039A1 +S315E6313140001C005300781E12001C00532000003983 +S315E6313150220080520100805214000014000180D210 +S315E631316060C1BCF20000403900041A121F00037137 +S315E631317041000054E203032A21040011E047885254 +S315E6313180E001A0723F00006B090100542100805234 +S315E6313190C0000090002022911EC9FF9715FEFF97C9 +S315E63131A0200080520D000014A2FDFF35000180D2C9 +S315E63131B060C1BCF21F000039001000911F000039D2 +S315E63131C0810080D261C1BCF220004039001800127C +S315E63131D02000003900008052FD7BC1A8C0035FD6CE +S315E63131E01F400071A1010054FD7BBFA9FD0300918B +S315E63131F0E60303AAE503022AE003012AE303042AE6 +S315E6313200E20306AAE103052A3DFFFF970000805255 +S315E6313210FD7BC1A8C0035FD600008052C0035FD6EE +S315E6313220000200B000DC40B901808A521F00016B12 +S315E6313230E1020054824380D2C2C0BCF2400040B9BA +S315E6313240005C1412E303202AC1C0BCD2230000B9C4 +S315E6313250400000B9022280D2C2C0BCF2400040B979 +S315E631326000040032E303202A230000B9400000B906 +S315E631327042E00B91400040B900741D12E303202A67 +S315E6313280230000B9400000B9C0035FD601008B5276 +S315E63132901F00016BE1010054012280D2C1C0BCF2AC +S315E63132A0200040B900041832E303202AC2C0BCD25A +S315E63132B0430000B9200000B921F00B91200040B956 +S315E63132C000740812E303202A430000B9200000B94E +S315E63132D0C0035FD6803481D2A0C2BCF2000040B9C9 +S315E63132E08001F83600780012E203202A012081D2E5 +S315E63132F0A1C2BCF2220000B921500291200000B9E8 +S315E6313300803481D2A0C2BCF2000040B9A0FFFF37BB +S315E6313310C0035FD6E00100B01F0000B9C0035FD637 +S315E631332081008052E00100B0010000B9C0035FD6EA +S315E6313330E00100B0000040B9C0035FD6FD7BBBA912 +S315E6313340FD030091F35301A9F55B02A9F76303A9DE +S315E6313350F92300F9F303002AF50303AAF403042A51 +S315E631336024110034E003132A03E079D3600C008B91 +S315E63133706300009063C024916000008B160440F927 +S315E6313380C00240B900041B121F000171C1FEFF5491 +S315E631339000118052C00200B921181F12E003132A28 +S315E63133A003E079D3600C008B6300009063C024910F +S315E63133B06000008B172040F9E10200B9421C001289 +S315E63133C0002840F9020000B9C00240B900041B12D8 +S315E63133D01F000171A1FFFF5420118052C00200B9CE +S315E63133E002008052E003132A01E079D3200C008BE8 +S315E63133F06100009021C024912000008B180C40F921 +S315E6313400000340B94000183620010037000C30374A +S315E6313410580400115FA00F71E80B00544001805249 +S315E63134208BBEFF97E203182AEFFFFF170011805292 +S315E6313430C00200B9010340B9C01E80522000000A1D +S315E6313440000300B901008052000340B92001183764 +S315E6313450600A3037390400113FA00F71480A00542B +S315E6313460400180527ABEFF97E103192AF7FFFF172B +S315E6313470E00240B9001C001200000032E00200B959 +S315E631348020118052C00200B91F0300B901008052F3 +S315E6313490000340B94000083620010037800830374E +S315E63134A0370400113FA00F7168080054400180527D +S315E63134B067BEFF97E103172AF6FFFF170011805221 +S315E63134C0C00200B99F060071610000544011805276 +S315E63134D0C00200B9000340B900141E12000300B958 +S315E63134E0190080521F0000149F060071C000005477 +S315E63134F0800600513F03006B610000544011805253 +S315E6313500C00200B901008052000340B920010837F4 +S315E631351060053037370400113FA00F714805005476 +S315E6313520400180524ABEFF97E103172AF7FFFF179C +S315E6313530E003132A01E079D3200C008B6100009079 +S315E631354021C024912000008B002440F9000040B9C7 +S315E6313550001C0012A04600B81F0300B93907001156 +S315E63135603F03146B23FCFF54000340B9E0FF2736D3 +S315E63135701F0300B900118052C00200B90000805223 +S315E631358012000014200080521000001440008052D0 +S315E63135900E000014600080520C0000144000805288 +S315E63135A00A00001460008052080000144000805280 +S315E63135B00600001460008052040000144000805278 +S315E63135C00200001460008052F35341A9F55B42A92B +S315E63135D0F76343A9F92340F9FD7BC5A8C0035FD656 +S315E63135E0FD7BBBA9FD030091F35301A9F55B02A966 +S315E63135F0F76303A9F92300F9F303002AF50303AACE +S315E6313600F403042AC40C0034E003132A03E079D325 +S315E6313610600C008B6300009063C024916000008BE0 +S315E6313620160440F9C00240B900041B121F000171AD +S315E6313630C1FEFF5400118052C00200B921181F1293 +S315E6313640E003132A03E079D3600C008B6300009024 +S315E631365063C024916000008B032040F9610000B914 +S315E6313660421C0012172840F9E20200B9C00240B9FD +S315E631367000041B121F000171A1FFFF542011805275 +S315E6313680C00200B902008052E003132A01E079D381 +S315E6313690200C008B6100009021C024912000008B24 +S315E63136A0180C40F9000340B94000183620010037BE +S315E63136B0A0073037580400115FA00F718807005410 +S315E63136C040018052E2BDFF97E203182AEFFFFF176A +S315E63136D000118052C00200B9010340B9C01E8052C2 +S315E63136E02000000A000300B901008052000340B908 +S315E63136F040001836A0031037E005303733040011A1 +S315E63137003FA00F71C805005440018052D0BDFF97E6 +S315E6313710E103132AF6FFFF17A04640B8E00200B9E7 +S315E6313720010340B9601E80522000000A000300B949 +S315E631373001008052000340B94000183620011037A7 +S315E631374020043037330400113FA00F7108040054CA +S315E631375040018052BEBDFF97E103132AF6FFFF17FC +S315E63137603907001102000014190080523F03146B29 +S315E631377043FDFF5440118052C00200B91F0300B920 +S315E6313780000340B9E0FF27361F0300B90011805226 +S315E6313790C00200B9000080520E00001420008052AB +S315E63137A00C000014400080520A000014600080527A +S315E63137B00800001440008052060000146000805272 +S315E63137C0040000144000805202000014600080526A +S315E63137D0F35341A9F55B42A9F76343A9F92340F9C6 +S315E63137E0FD7BC5A8C0035FD6C0000035FD7BBFA90A +S315E63137F0FD0300918BFEFF97FD7BC1A8C0035FD623 +S315E6313800C0035FD6C0000035FD7BBFA9FD0300913D +S315E6313810B1FEFF97FD7BC1A8C0035FD6C0035FD675 +S315E6313820FD7BBEA9FD030091F30B00F9F303002AF4 +S315E6313830F5FFFF97E003132AECFFFF976000009050 +S315E631384000C02491F303132A61E279D3330C138B47 +S315E63138500100138B222C40F95F0000B9221840F99A +S315E6313860E3038052430000B9006873F81F0000B9DC +S315E6313870200840F91F0000B9201040F91F0000B9B1 +S315E6313880201C40F91F0000B9200440F9021180528C +S315E6313890020000B9200C40F91F0000B9201440F9A6 +S315E63138A01F0000B9202040F91F0000B9F30B40F99B +S315E63138B0FD7BC2A8C0035FD6F353BDA9F55B01A96B +S315E63138C0FE1300F9F30300AAF603012A3500805206 +S315E63138D010000014E00313AAAFC6FF9702000014E6 +S315E63138E0200080521F04007160FFFF547406009178 +S315E63138F02000805203000014E00314AAA6C6FF97FF +S315E63139001F040071A0FFFF54730A0091B50600113A +S315E6313910BF02166B69FEFF547F020039F55B41A99A +S315E6313920FE1340F9F353C3A8C0035FD6F353BBA9DD +S315E6313930F55B01A9F77B02A921008052C000009010 +S315E63139400080229133C7FF971600805215008052C8 +S315E6313950E003019190C6FF97E00341391FCC01712F +S315E6313960E2179F1A1FB80071E1179F1A4100012A23 +S315E6313970610000351F4C0171C1FEFF541FB800715D +S315E6313980E1000054E003019183C6FF97E003413934 +S315E63139901F34007181FFFF54610000141F4C017121 +S315E63139A0E0179F1A4200002A02050034E00301912E +S315E63139B079C6FF97E003413900C000511F240071F3 +S315E63139C0E80300546100009021E0269120486038F2 +S315E63139D0610000102088208B00001FD6010080523E +S315E63139E0570080521D000014E00301916AC6FF9725 +S315E63139F0E10341393F340071E2179F1A3F280071DE +S315E6313A00E0179F1A4000002A8000003413008052E6 +S315E6313A10020000143300805293FEFF3521008052B6 +S315E6313A200E00001401008052970080520B000014FC +S315E6313A30360080520100805208000014350080526B +S315E6313A400100805205000014010080520300001483 +S315E6313A500100805277008052C002152A6001003497 +S315E6313A60E00301914CC6FF97E10341393F340071DA +S315E6313A70E2179F1A3F280071E0179F1A4000002A85 +S315E6313A8000FFFF342600001441F6FF35210080524F +S315E6313A90E003019189FFFF97E1F30091E00301919C +S315E6313AA0CEC7FF97F33F40B9E103172AE003019109 +S315E6313AB082FFFF97E1F30091E0030191C7C7FF97D4 +S315E6313AC0F43F40B97302174B0A00001421008052C5 +S315E6313AD0E003019179FFFF97E1F30091E00301916C +S315E6313AE0BEC7FF97E03F40B98016003873060051EE +S315E6313AF07F060071C8FEFF5421008052E003019132 +S315E6313B006EFFFF97E1F30091E0030191B3C7FF97AB +S315E6313B10E003019120C6FF978EFFFF17F55B41A9BA +S315E6313B20F77B42A9F353C5A8C0035FD6F353B9A9C8 +S315E6313B30F55B01A9F76302A9F96B03A9FE2300F93F +S315E6313B4021008052C000009000202391B1C6FF9734 +S315E6313B50E21F80520180B5120000AA5288E1FF9732 +S315E6313B6021008052C000009000802291A9C6FF97BD +S315E6313B7018008052160080121500805214008052C9 +S315E6313B80E083019104C6FF97E08341391FCC017189 +S315E6313B90E2179F1A1FB80071E1179F1A4100012AF1 +S315E6313BA0610000351F4C0171C1FEFF541FB800712B +S315E6313BB0E1000054E0830191F7C5FF97E08341398F +S315E6313BC01F34007181FFFF54720000141F4C0171DE +S315E6313BD0E0179F1A4200002A02050034E08301917C +S315E6313BE0EDC5FF97E083413900C000511F240071CE +S315E6313BF0E80300546100009021102791204860388F +S315E6313C00610000102088208B00001FD6010080520B +S315E6313C10570080521D000014E0830191DEC5FF97FF +S315E6313C20E18341393F340071E2179F1A3F2800712B +S315E6313C30E0179F1A4000002A8000003413008052B4 +S315E6313C40020000143300805293FEFF352100805284 +S315E6313C500E00001401008052970080520B000014CA +S315E6313C60350080520100805208000014340080523B +S315E6313C700100805205000014010080520300001451 +S315E6313C800100805277008052A002142A20020034C5 +S315E6313C90E0830191C0C5FF97E18341393F34007135 +S315E6313CA0E2179F1A3F280071E0179F1A4000002A53 +S315E6313CB000FFFF340080B652C002000B0103164BFB +S315E6313CC0E203162A0100010B44CCFF9731000014BA +S315E6313CD081F5FF3521008052E0830191F7FEFF97AA +S315E6313CE0E1730191E08301913CC7FF97F35F40B9F8 +S315E6313CF0E103172AE0830191F0FEFF97E173019123 +S315E6313D00E083019135C7FF977302174B0000AA523C +S315E6313D10FA5F40B95A03002AF9031A2A3F4336EBCA +S315E6313D2083010054FA03162A0A0000142100805250 +S315E6313D30E0830191E1FEFF97E1730191E083019121 +S315E6313D4026C7FF97E05F40B9201700387306005162 +S315E6313D507F060071C8FEFF54200700D11F4038EBBD +S315E6313D60490000543807005121008052E083019121 +S315E6313D70D2FEFF97E1730191E083019117C7FF9771 +S315E6313D80E083019184C5FF97F6031A2A7DFFFF1773 +S315E6313D90F55B41A9F76342A9F96B43A9FE2340F9DD +S315E6313DA0F353C7A8C0035FD6F353B7A9F55B01A9A9 +S315E6313DB0F76302A9F96B03A9FB7304A9FE2B00F994 +S315E6313DC0FC0300AAE13700F9000200B0005042B91F +S315E6313DD0010400513F040071A8000054010200B00D +S315E6313DE0384042B90100B6521803010B1F0C007177 +S315E6313DF0C1040054000200B0004042B90100B812D5 +S315E6313E001F00016B090100540100B6121F00016B58 +S315E6313E10A80000541800AA521803004B1B00805222 +S315E6313E201B0000140100B6121F00016B0901005494 +S315E6313E300100A8121F00016BA80000541800B65203 +S315E6313E401800180B3B00805211000014013AA352B8 +S315E6313E500100010B42FFBF123F00026BA80000547E +S315E6313E601800B6521800180B3B00805208000014B1 +S315E6313E7021008052C000009000C02391E5C5FF972E +S315E6313E80200080528D0000143B0080522100805282 +S315E6313E90C000009000802291DEC5FF971A0080525D +S315E6313EA0190080121600805215008052E003029105 +S315E6313EB039C5FF97E00342391FCC0171E2179F1AE4 +S315E6313EC01FB80071E1179F1A4100012A61000035DA +S315E6313ED01F4C0171C1FEFF541FB80071E100005459 +S315E6313EE0E00302912CC5FF97E00342391F34007196 +S315E6313EF081FFFF54700000141F4C0171E0179F1AC1 +S315E6313F004200002A02050034E003029122C5FF97FA +S315E6313F10E003423900C000511F240071E803005422 +S315E6313F2061000090214027912048603861000010F9 +S315E6313F302088208B00001FD6010080525700805220 +S315E6313F401D000014E003029113C5FF97E1034239E0 +S315E6313F503F340071E2179F1A3F280071E0179F1A26 +S315E6313F604000002A8000003413008052020000141B +S315E6313F703300805293FEFF35210080520E00001445 +S315E6313F8001008052970080520B00001436008052B1 +S315E6313F90010080520800001435008052010080523B +S315E6313FA0050000140100805203000014010080521E +S315E6313FB077008052C002152AE0010034E00302910F +S315E6313FC0F5C4FF97E10342393F340071E2179F1A90 +S315E6313FD03F280071E0179F1A4000002A00FFFF34A0 +S315E6313FE09A0300B9E03740F9190000B9000080526A +S315E6313FF032000014C1F5FF3521008052E00302910B +S315E63140002EFEFF97E1F30191E003029173C6FF9726 +S315E6314010F37F40B9E103172AE003029127FEFF97C2 +S315E6314020E1F30191E00302916CC6FF97F47F40B963 +S315E63140307B000034944238CB020000149442388B2C +S315E63140407302174B9F4239EB82010054F903142A66 +S315E63140500A00001421008052E003029117FEFF9711 +S315E6314060E1F30191E00302915CC6FF97E07F40B947 +S315E631407080160038730600517F060071C8FEFF547C +S315E6314080800600D11F403AEB490000549A060051AA +S315E631409021008052E003029108FEFF97E1F3019198 +S315E63140A0E00302914DC6FF97E0030291BAC4FF974A +S315E63140B07FFFFF1720008052F55B41A9F76342A9DE +S315E63140C0F96B43A9FB7344A9FE2B40F9F353C9A80F +S315E63140D0C0035FD6FD7BBFA9FD03009100020090C8 +S315E63140E00050433900101D72E2179F1A1F80007186 +S315E63140F0E1179F1A4100012A210100351F2000717F +S315E6314100E00000541F400071E1179F1A1F600171EC +S315E6314110E0179F1A2000002A400000343426009426 +S315E6314120FD7BC1A8C0035FD6FD7BBEA9FD03009129 +S315E6314130F30B00F9000200900050433900101D726E +S315E6314140E2179F1A1F800071E1179F1A4100012A73 +S315E6314150410100340002009000DC40B901E08952A9 +S315E63141601F00016B2004005401408A521F00016B87 +S315E6314170E10400541F0000141F400071E2179F1A34 +S315E63141801F600171E1179F1A4100012A410100348E +S315E63141900002009000DC40B901E089521F00016B54 +S315E63141A0C002005401408A521F00016B01030054DC +S315E63141B0140000141F200071E10000540002009043 +S315E63141C001DC40B900408A523F00006B01020054DF +S315E63141D00E00001421008052A00000F00060259107 +S315E63141E00CC5FF970A0000145300805208000014EC +S315E63141F01300805206000014530080520400001466 +S315E6314200730080520200001433008052E003132A11 +S315E6314210F30B40F9FD7BC2A8C0035FD6FD7BBEA991 +S315E6314220FD030091F30B00F9131C00530100805294 +S315E6314230A00000F000202691F6C4FF970002009018 +S315E631424000BC44B91F20007148050054410000F016 +S315E63142502170279120486038610000102088208B34 +S315E631426000001FD6E103132AA00000F00080269154 +S315E6314270E8C4FF9723000014E103132AA00000F0F7 +S315E631428000002791E3C4FF971E000014E103132AC9 +S315E6314290A00000F000602791DEC4FF9719000014F4 +S315E63142A0E103132AA00000F000402891D9C4FF9714 +S315E63142B014000014E103132AA00000F000C028918F +S315E63142C0D4C4FF970F000014E103132AA00000F0CF +S315E63142D000A02991CFC4FF970A000014E103132AFF +S315E63142E0A00000F000402A91CAC4FF9705000014E9 +S315E63142F0E103132AA00000F000E02A91C5C4FF9736 +S315E6314300F30B40F9FD7BC2A8C0035FD6FF4301D16B +S315E6314310E00700F9E10F00F9E21300F9E31700F9D6 +S315E6314320E41B00F9E51F00F9E62300F9E72700F972 +S315E63143301F2003D5FF430191C0035FD6FD7BBEA99E +S315E6314340FD030091A01F00B9A01F40B91F240071DB +S315E63143508800005420008052BDBAFF971D00001434 +S315E6314360A11F40B9A09999528099B972207CA09B38 +S315E631437000FC60D3007C035300781F5302741E534E +S315E63143800000020B2000004B1F001F6B400100545A +S315E6314390A11F40B9A09999528099B972207CA09B08 +S315E63143A000FC60D3007C035300040011A8BAFF97E2 +S315E63143B008000014A11F40B9A09999528099B972A3 +S315E63143C0207CA09B00FC60D3007C0353A0BAFF9708 +S315E63143D01F2003D5FD7BC2A8C0035FD6FF4300D1BC +S315E63143E0E00700F9E10700B9E00740F9E10740B92E +S315E63143F0010000B91F2003D5FF430091C0035FD604 +S315E6314400FF4300D1E00700F9E00740F9000040B983 +S315E6314410FF430091C0035FD6FD7BBEA9FD03009144 +S315E6314420A00F00F9A11700B9A21300B9A00F40F900 +S315E6314430F4FFFF97E103002AA01740B9E003202AEB +S315E63144402100000AA01340B92000002AE103002A20 +S315E6314450A00F40F9E2FFFF971F2003D5FD7BC2A8E7 +S315E6314460C0035FD640EC8052C0035FD6FD7BBFA961 +S315E6314470FD0300913B010094FD7BC1A8C0035FD6E5 +S315E6314480FD7BBCA9FD030091A02F00B9A11300F96C +S315E6314490A20F00F9000C80D2C0C2BCF2D9FFFF9759 +S315E63144A0007C0D5300040012A03F00B9A03F40B98D +S315E63144B01F0C007168040054810000F021A00291BE +S315E63144C0205860B86100001020C8208B00001FD646 +S315E63144D0A01340F941068052010000B9A00F40F918 +S315E63144E061008052010000B916000014A01340F9AC +S315E63144F081078052010000B9A00F40F96100805270 +S315E6314500010000B90F000014A01340F96109805289 +S315E6314510010000B9A00F40F961008052010000B9EF +S315E631452008000014A01340F941068052010000B993 +S315E6314530A00F40F961008052010000B91F2003D572 +S315E63145401F2003D5FD7BC4A8C0035FD6FD7BBCA97E +S315E6314550FD030091A02F00B9A11300F9A20F00F9CE +S315E6314560000C80D2C0C2BCF2A6FFFF97017C115384 +S315E6314570A00080522000000AA03F00B9A03F40B912 +S315E6314580017C0153A03F40B92000002A0004001205 +S315E6314590A03F00B9A03F40B91F0C00716804005432 +S315E63145A0810000F021E00291205860B861000010E8 +S315E63145B020C8208B00001FD6A01340F90190815206 +S315E63145C0010000B9A00F40F921008052010000B97F +S315E63145D016000014A01340F9015E8152010000B9BC +S315E63145E0A00F40F921008052010000B90F000014F6 +S315E63145F0A01340F9012C8152010000B9A00F40F910 +S315E631460021008052010000B908000014A01340F9D8 +S315E631461001C88052010000B9A00F40F9210080524D +S315E6314620010000B91F2003D51F2003D5FD7BC4A8A1 +S315E6314630C0035FD6FD7BBEA9FD030091A01F00B97D +S315E6314640A11B00B9A01B40B9E003202AE103002AE9 +S315E6314650C0C0BCD262FFFF97C0C0BCD269FFFF972C +S315E6314660E003202AA01B00B9A01F40B9A11B40B91F +S315E63146705BFFFF971F2003D5A01F40B961FFFF9768 +S315E6314680E103002AA01B40B93F00006B61FFFF54EE +S315E63146905E0200941F2003D5FD7BC2A8C0035FD618 +S315E63146A0FD7BBDA9FD030091002380D2C0C0BCF2DB +S315E63146B054FFFF97A02F00B9808280D2C0C0BCF2EA +S315E63146C050FFFF97A02B00B9808A80D2C0C0BCF2DA +S315E63146D04CFFFF97A02700B94C020094A02F40B9B2 +S315E63146E000781012A02300B9A12340B900238052E5 +S315E63146F0C0C0BC72D0FFFF97A02B40B9A02300B94A +S315E6314700A02340B900000A32A02300B9A12340B95B +S315E631471080828052C0C0BC72C7FFFF97A02740B9DE +S315E6314720A02300B9A02340B900780912A02300B925 +S315E6314730A12340B9808A8052C0C0BC72BEFFFF97C2 +S315E631474040018052FEFEFF9780818AD2A0C0BCF23C +S315E63147502CFFFF97007C0F5300000012A01F00B913 +S315E63147602A020094A02740B9A02300B9A02340B974 +S315E631477000000A32A02300B9A12340B9808A8052CB +S315E6314780C0C0BC72ACFFFF9740018052ECFEFF978A +S315E631479080818AD2A0C0BCF21AFFFF97007C0F5304 +S315E63147A000000012A01B00B918020094A12F40B9EF +S315E63147B000238052C0C0BC729FFFFF97A12B40B940 +S315E63147C080828052C0C0BC729BFFFF97A12740B959 +S315E63147D0808A8052C0C0BC7297FFFF97A11F40B94D +S315E63147E0A01B40B93F00006B6100005400008052C7 +S315E63147F00200001420008052FD7BC3A8C0035FD6B9 +S315E6314800FD7BBDA9FD030091002380D2C0C0BCF279 +S315E6314810FCFEFF97A02F00B9008380D2C0C0BCF260 +S315E6314820F8FEFF97A02B00B9008B80D2C0C0BCF250 +S315E6314830F4FEFF97A02700B9F4010094A02F40B902 +S315E631484000780612A02300B9A12340B9002380528D +S315E6314850C0C0BC7278FFFF97A02B40B9A02300B940 +S315E6314860A02340B900000032A02300B9A12340B904 +S315E631487000838052C0C0BC726FFFFF97A02740B954 +S315E6314880A02300B9A02340B900781F12A02300B9AE +S315E6314890A12340B9008B8052C0C0BC7266FFFF9738 +S315E63148A040018052A6FEFF9780818AD2A0C0BCF233 +S315E63148B0D4FEFF97007C195300000012A01F00B901 +S315E63148C0D2010094A02740B9A02300B9A02340B96C +S315E63148D000000032A02300B9A12340B9008B8052F3 +S315E63148E0C0C0BC7254FFFF974001805294FEFF97D9 +S315E63148F080818AD2A0C0BCF2C2FEFF97007C1953F2 +S315E631490000000012A01B00B9C0010094A12F40B9E6 +S315E631491000238052C0C0BC7247FFFF97A12B40B936 +S315E631492000838052C0C0BC7243FFFF97A12740B9CE +S315E6314930008B8052C0C0BC723FFFFF97A11F40B9C2 +S315E6314940A01B40B93F00006B610000540000805265 +S315E63149500200001420008052FD7BC3A8C0035FD657 +S315E6314960FD7BBEA9FD030091000200900080039114 +S315E6314970000040B91F001F6BA006005449FFFF97A0 +S315E6314980A01B00B99FFFFF97A01700B9A01B40B93E +S315E63149901F001F6B60030054A01740B91F001F6B41 +S315E63149A0A0020054E001009000200091010040B9D8 +S315E63149B000E089523F00006B81010054E00100902E +S315E63149C000300091000040B91F04007188000054A0 +S315E63149D040008052A01F00B964000014E000805206 +S315E63149E0A01F00B96100001460008052A01F00B913 +S315E63149F05E00001420008052A01F00B95B0000144F +S315E6314A00E001009000200091010040B900E08952B2 +S315E6314A103F00006B81010054E001009000300091C7 +S315E6314A20000040B91F0400718800005440008052EE +S315E6314A30A01F00B94D000014E0008052A01F00B956 +S315E6314A404A000014BF1F00B9480000140002009066 +S315E6314A50005003910000403900101D121F400071CD +S315E6314A60E000005400020090005003910000403906 +S315E6314A7000101D121F600171A1020054E001009081 +S315E6314A8000200091010040B900E089523F00006BF9 +S315E6314A9081010054E001009000300091000040B9F8 +S315E6314AA01F0400718800005440008052A01F00B9EF +S315E6314AB02E000014E0008052A01F00B92B0000142E +S315E6314AC060008052A01F00B9280000140002009051 +S315E6314AD0005003910000403900101D121F2000716D +S315E6314AE08100005420008052A01F00B91F00001437 +S315E6314AF000020090005003910000403900101D126B +S315E6314B001F001F6BE0000054000200900050039135 +S315E6314B100000403900101D121F80007161020054F9 +S315E6314B20E001009000200091010040B900E0895291 +S315E6314B303F00006B81010054E001009000300091A6 +S315E6314B40000040B91F0400718800005440008052CD +S315E6314B50A01F00B905000014E0008052A01F00B97D +S315E6314B6002000014BF1F00B90002009000F0129156 +S315E6314B70A11F40B9010000B9A01F40B9FD7BC2A80B +S315E6314B80C0035FD6FF8300D1E00F00B9E00F40B92D +S315E6314B90E01F00B90E000014E01F40B92100805233 +S315E6314BA02020C01AE103002A0002009000901191FC +S315E6314BB0000040B92000000A1F001F6B01010054B6 +S315E6314BC0E01F40B900040011E01F00B9E01F40B90B +S315E6314BD01F0C00712DFEFF54020000141F2003D571 +S315E6314BE0E01F40B9FF830091C0035FD6FD7BBEA9C6 +S315E6314BF0FD030091A01F00B9A11B00B9A01B40B966 +S315E6314C00E003202AE103002A002081D2A0C2BCF2C9 +S315E6314C10F3FDFF97A01F40B9A11B40B9F0FDFF9701 +S315E6314C201F2003D5FD7BC2A8C0035FD6FD7BBCA999 +S315E6314C30FD030091F30B00F9A02F00B9A12B00B9C2 +S315E6314C40001A80D2A0C2BCF2EEFDFF97A03700B9BA +S315E6314C50A03740B900781C12A03700B9A13740B960 +S315E6314C60001A8052A0C2BC72E1FFFF97E7000094BA +S315E6314C70E1870032801C8052A0C2BC72DCFFFF970E +S315E6314C80E2000094A02F40B91F001F6B8018005434 +S315E6314C90007080D2A0C2BCF2DAFDFF970000153271 +S315E6314CA0A03700B9A13740B900708052A0C2BC72B4 +S315E6314CB0CFFFFF97D5000094001A80D2A0C2BCF28E +S315E6314CC0D0FDFF97A03700B9A03740B900001D32B5 +S315E6314CD0A03700B9A13740B9001A8052A0C2BC72DA +S315E6314CE0C3FFFF97C9000094001A80D2A0C2BCF276 +S315E6314CF0C4FDFF97A03700B9A03740B900001512B9 +S315E6314D001F001F6B20FFFF54C0000094A02B40B953 +S315E6314D101F001F6B40050054E001009000900091A2 +S315E6314D20010040B9E001009000700091000040B901 +S315E6314D30217C001B007D8052217C001BE00100F0C6 +S315E6314D4000301191020040B9E00100900060009117 +S315E6314D50000040B9427C001BE001009000900091D2 +S315E6314D60000040B9407C001B000400112008C01A3F +S315E6314D70A03300B9A03340B901040011E00100F0D7 +S315E6314D8000301191000040B9207C001B000400512F +S315E6314D90001C0853A03B00B9A03340B91F001F6B76 +S315E6314DA0A0000054A03340B900040011A03F00B979 +S315E6314DB02B000014BF3F00B929000014E001009032 +S315E6314DC000900091010040B9E00100900070009139 +S315E6314DD0000040B9217C001B007D8052217C001BFE +S315E6314DE0E00100F000201191020040B9E0010090A7 +S315E6314DF000600091000040B9427C001BE001009062 +S315E6314E0000900091000040B9407C001B000400117F +S315E6314E102008C01AA03300B9A03340B90104001105 +S315E6314E20E00100F000201191000040B9207C001B22 +S315E6314E3000040051001C0853A03B00B9A03340B929 +S315E6314E401F001F6BA0000054A03340B900040011C7 +S315E6314E50A03F00B902000014BF3F00B9801C80D2E2 +S315E6314E60A0C2BCF267FDFF9700A00912A03700B9D0 +S315E6314E70A13740B9801C8052A0C2BC725CFFFF9755 +S315E6314E8062000094800080D2A0C2BCF25DFDFF973D +S315E6314E9000000132A03700B9A13740B9800080520F +S315E6314EA0A0C2BC7252FFFF9758000094A13B40B9AD +S315E6314EB0801B8052A0C2BC724DFFFF97530000940F +S315E6314EC0001A80D2A0C2BCF24EFDFF97A03700B9D8 +S315E6314ED0A03740B9000015121F001F6B20FFFF54A3 +S315E6314EE04A000094A03F40B9013C1053A03F40B977 +S315E6314EF03300002A801C80D2A0C2BCF241FDFF9766 +S315E6314F0000A009126002002AA03700B9A13740B9DC +S315E6314F10801C8052A0C2BC7235FFFF973B000094DD +S315E6314F20800080D2A0C2BCF236FDFF970000013286 +S315E6314F30A03700B9A13740B980008052A0C2BC7211 +S315E6314F402BFFFF9731000094001A80D2A0C2BCF243 +S315E6314F502CFDFF97A03700B9A03740B900001512EE +S315E6314F601F001F6B20FFFF5428000094007080D28B +S315E6314F70A0C2BCF223FDFF9700781412A03700B920 +S315E6314F80A13740B900708052A0C2BC7218FFFF97B4 +S315E6314F901E0000941F2003D5020000141F2003D5FE +S315E6314FA0F30B40F9FD7BC4A8C0035FD6FD7BBEA9F2 +S315E6314FB0FD030091A01F00B9A01F40B91F001F6B6A +S315E6314FC020010054210080522000805218FFFF97BD +S315E6314FD0000200900040029121008052010000B9A2 +S315E6314FE007000014010080522000805210FFFF971F +S315E6314FF000020090004002911F0000B91F2003D540 +S315E6315000FD7BC2A8C0035FD69F3F03D51F2003D5DC +S315E6315010C0035FD6FD7BBEA9FD030091004180D278 +S315E631502020CFBCF2F7FCFF97A01F00B9F7FFFF9739 +S315E6315030004280D220CFBCF2F2FCFF97A01F00B926 +S315E6315040F2FFFF97A01F40B9000000121F001F6B49 +S315E631505040000054F7FFFF171F2003D51F2003D565 +S315E6315060FD7BC2A8C0035FD6FD7BBEA9FD030091D9 +S315E6315070A01F00B9E8FFFF97A11F40B9004180D2D2 +S315E631508020CFBCF2D6FCFF97E0FFFF971F2003D572 +S315E6315090FD7BC2A8C0035FD6FD7BBDA9FD030091AA +S315E63150A0A01F00B9A11B00B9E00100F00040029152 +S315E63150B0000040B91F001F6B80000054400080524B +S315E63150C0A02700B90300001400018052A02700B9D9 +S315E63150D0A01F40B901641A5380C4805220CFBC72F6 +S315E63150E02000000BE003002AA11B40B9BCFCFF9768 +S315E63150F0C6FFFF9702000014C4FFFF97A01F40B911 +S315E631510001641A5380C4805220CFBC722000000B52 +S315E6315110E003002ABBFCFF97E103002AA01B40B956 +S315E63151203F00006BA1FEFF54B8FFFF97BF2B00B9D6 +S315E63151300D000014A01F40B901641A5300C5805210 +S315E631514020CFBC722000000BE003002AADFCFF97AE +S315E6315150A02F00B9ADFFFF97A02B40B9000400118F +S315E6315160A02B00B9A12B40B9A02740B93F00006B6F +S315E631517023FEFF54A02F40B9FD7BC3A8C0035FD6FB +S315E6315180FD7BBDA9FD030091A01F00B9A11B00B9A6 +S315E6315190A21700B9E00100F000400291000040B9E3 +S315E63151A01F001F6B8000005440008052A02B00B9CF +S315E63151B00300001400018052A02B00B9A01F40B9AC +S315E63151C001641A5380C4805220CFBC722000000B92 +S315E63151D0E003002AA11B40B981FCFF978BFFFF97BD +S315E63151E0BF2F00B90D000014A01F40B901641A5350 +S315E63151F080C4805220CFBC722000000BE003002A27 +S315E631520080FCFF97A02700B980FFFF97A02F40B912 +S315E631521000040011A02F00B9A12F40B9A02B40B947 +S315E63152203F00006B23FEFF54A01F40B901641A53B9 +S315E631523000C5805220CFBC722000000BE003002A65 +S315E6315240A11740B966FCFF9770FFFF97BF2F00B9EC +S315E63152500D000014A01F40B901641A5300C58052EF +S315E631526020CFBC722000000BE003002A65FCFF97D5 +S315E6315270A02700B965FFFF97A02F40B900040011BA +S315E6315280A02F00B9A12F40B9A02B40B93F00006B42 +S315E631529023FEFF541F2003D5FD7BC3A8C0035FD68B +S315E63152A0FD7BBDA9FD030091A01F00B9A11B00B985 +S315E63152B0E00100F000400291000040B91F001F6B8B +S315E63152C08000005440008052A02B00B90300001440 +S315E63152D000018052A02B00B9000080522AFEFF97CA +S315E63152E0A02700B90E000014A02740B901641A536D +S315E63152F080C4805220CFBC722000000BE003002A26 +S315E6315300A11F40B936FCFF9740FFFF97A02740B96A +S315E6315310000400111CFEFF97A02700B9A02740B96B +S315E63153201F0C007129FEFF5438FFFF9700008052AB +S315E631533015FEFF97A02700B90E000014A02740B945 +S315E631534001641A5300C5805220CFBC722000000B8F +S315E6315350E003002AA11B40B921FCFF972BFFFF97FB +S315E6315360A02740B90004001107FEFF97A02700B930 +S315E6315370A02740B91F0C007129FEFF54BF2F00B993 +S315E63153800900001400C580D220CFBCF21DFCFF9780 +S315E6315390A02300B91DFFFF97A02F40B900040011E5 +S315E63153A0A02F00B9A12F40B9A02B40B93F00006B21 +S315E63153B0A3FEFF541F2003D5FD7BC3A8C0035FD6EA +S315E63153C0FF4300D1E00F00B9C00100F00040009183 +S315E63153D0010040F9E00F40B900F47ED32000008B9E +S315E63153E0000040B9FF430091C0035FD6FF4300D1C9 +S315E63153F0E00F00B9C00100F000400091010040F92C +S315E6315400E00F40B900F47ED32000008B000040B9AE +S315E6315410003C0012FF430091C0035FD6FF4300D143 +S315E6315420E00F00B9C00100F000400091010040F9FB +S315E6315430E00F40B900F47ED32000008B000040B97E +S315E6315440007C1853FF430091C0035FD6FD7BBCA9B0 +S315E6315450FD030091A01F00B9A11B00B9A21700B93F +S315E6315460A31300B9A01740B9D6FFFF97A03B00B901 +S315E6315470A03B40B9013C0012A01B40B9006019536C +S315E63154802000000BA03700B9A03B40B9007C105391 +S315E6315490001C0012A03300B9A03B40B9007C18537A +S315E63154A0A02F00B9A03340B91F80007181000054A6 +S315E63154B000008012A03F00B908000014A03340B9BD +S315E63154C0210080522020C01A01040051A02F40B994 +S315E63154D02020C01AA03F00B9A13740B9A01F40B974 +S315E63154E0EEFEFF97A02B00B9A02F40B9A11340B924 +S315E63154F02120C01AA02B40B92100004AA03F40B96D +S315E63155002000000AA12B40B92000004AA02B00B9A1 +S315E6315510A22B40B9A13740B9A01F40B919FFFF9771 +S315E63155201F2003D5FD7BC4A8C0035FD6FD7BBCA98E +S315E6315530FD030091A01F00B9A11B00B9A21700B95E +S315E6315540A01740B99FFFFF97A03B00B9A03B40B9F2 +S315E6315550013C0012A01B40B9006019532000000B34 +S315E6315560A03700B9A03B40B9007C1053001C0012AD +S315E6315570A03300B9A03B40B9007C1853A02F00B93F +S315E6315580A03340B91F8000718100005400008012BB +S315E6315590A03F00B906000014A03340B9210080527D +S315E63155A02020C01A00040051A03F00B9A13740B906 +S315E63155B0A01F40B9B9FEFF97A02B00B9A02F40B97D +S315E63155C0A12B40B92124C01AA03F40B92000000AD8 +S315E63155D0A02B00B9A02B40B9FD7BC4A8C0035FD68A +S315E63155E0FD7BBEA9FD030091A01F00B9A11B00B941 +S315E63155F0A21700B9A31740B9A21B40B901008052E0 +S315E6315600A01F40B992FFFF971F2003D5FD7BC2A8A5 +S315E6315610C0035FD6FD7BBBA9FD030091A01F00B990 +S315E6315620A11B00B9A21700B9E00100F000400291D2 +S315E6315630000040B91F001F6B8000005440008052C5 +S315E6315640A04300B90300001400018052A04300B91B +S315E6315650A01B40B95BFFFF97A03F00B9A03F40B919 +S315E6315660013C0012A01F40B9006019532000000B1F +S315E6315670A03B00B9A03F40B9007C1053001C001294 +S315E6315680A03700B9A03F40B9007C1853A03300B922 +S315E6315690A03740B91F8000718100005400008012A6 +S315E63156A0A04B00B908000014A03740B9210080525A +S315E63156B02020C01A01040051A03340B92020C01A77 +S315E63156C0A04B00B9000080522FFDFF97A04F00B9DD +S315E63156D00D000014A04F40B901641A5380C48052BC +S315E63156E020CFBC722000000BE003002AA13B40B973 +S315E63156F03BFBFF97A04F40B90004001122FDFF970F +S315E6315700A04F00B9A04F40B91F0C007149FEFF54B6 +S315E63157103EFEFF97000080521BFDFF97A04F00B972 +S315E63157201D000014BF4700B913000014A04F40B95D +S315E631573001641A5300C5805220CFBC722000000B9B +S315E6315740E003002A2FFBFF97E103002AA04F40B979 +S315E631575000F47ED3A24301914000008B000440D190 +S315E631576001D00FB929FEFF97A04740B900040011D1 +S315E6315770A04700B9A14740B9A04340B93F00006B05 +S315E631578063FDFF54A04F40B900040011FEFCFF97BC +S315E6315790A04F00B9A04F40B91F0C007149FCFF5428 +S315E63157A000008052F8FCFF97A04F00B92E00001496 +S315E63157B0A04F40B900F47ED3A14301912000008B7E +S315E63157C0000440D101D04FB9A03340B9A21740B950 +S315E63157D04020C01A2100004AA04B40B92100000AF8 +S315E63157E0A04F40B900F47ED3A24301914000008B2D +S315E63157F0000440D100D04FB92000004AA14F40B94C +S315E631580021F47ED3A24301914100018B210440D19B +S315E631581020D00FB9A04F40B901641A5300C5805262 +S315E631582020CFBC722000000BE203002AA04F40B91C +S315E631583000F47ED3A14301912000008B000440D1D0 +S315E631584000D04FB9E103002AE00302AAE4FAFF9752 +S315E6315850EEFDFF97A04F40B900040011CAFCFF9751 +S315E6315860A04F00B9A04F40B91F0C007129FAFF5479 +S315E631587000008052C4FCFF97A04F00B91D0000140A +S315E6315880BF4700B913000014A04F40B901641A535B +S315E631589000C5805220CFBC722000000BE003002AFF +S315E63158A0D8FAFF97E103002AA04F40B900F47ED338 +S315E63158B0A24301914000008B000440D101D00FB9DB +S315E63158C0D2FDFF97A04740B900040011A04700B9C1 +S315E63158D0A14740B9A04340B93F00006B63FDFF5491 +S315E63158E0A04F40B900040011A7FCFF97A04F00B9BD +S315E63158F0A04F40B91F0C007149FCFF541F2003D558 +S315E6315900FD7BC5A8C0035FD6FD7BBEA9FD0300912D +S315E6315910A01F00B9A11B00B9A21B40B9A11F40B90E +S315E6315920000080523CFFFF971F2003D5FD7BC2A8BE +S315E6315930C0035FD6FD7BBDA9FD030091A01F00B96B +S315E6315940A11B00B9BF2F00B908000014A21B40B94C +S315E6315950A11F40B9A02F40B92FFFFF97A02F40B91D +S315E631596000040011A02F00B9A02F40B91F0C007119 +S315E6315970E9FEFF541F2003D5FD7BC3A8C0035FD6DE +S315E6315980FD7BBEA9FD030091A01F00B9A11B00B99D +S315E6315990A21B40B901008052A01F40B9E4FEFF9731 +S315E63159A0FD7BC2A8C0035FD6FD7BBCA9FD03009192 +S315E63159B0F30B00F9A02F00B9A11300F900008052CC +S315E63159C071FCFF97A03F00B90E000014A03F40B925 +S315E63159D000F47ED3A11340F93300008BA22F40B9F0 +S315E63159E001008052A03F40B9D1FEFF97600200B96F +S315E63159F0A03F40B90004001163FCFF97A03F00B910 +S315E6315A00A03F40B91F0C007129FEFF54A01340F99F +S315E6315A10000040B9F30B40F9FD7BC4A8C0035FD65D +S315E6315A20FD7BBCA9FD030091F30B00F9A02F00B96C +S315E6315A30A11300F9A01340F9A01B00F9000080522A +S315E6315A4051FCFF97A03F00B915000014BF3B00B9E2 +S315E6315A500C000014B31B40F960120091A01B00F94B +S315E6315A60A22F40B9A13B40B9A03F40B9B0FEFF975E +S315E6315A70600200B9A03B40B900040011A03B00B971 +S315E6315A80A03B40B91F0C007169FEFF54A03F40B9F7 +S315E6315A90000400113CFCFF97A03F00B9A03F40B996 +S315E6315AA01F0C007149FDFF54A01340F9000040B9BF +S315E6315AB0F30B40F9FD7BC4A8C0035FD6FFC300D123 +S315E6315AC0E00F00F9E10B00F9E20F00B9FF2F00B95B +S315E6315AD00E000014E02F40B900F47ED3E10F40F911 +S315E6315AE02000008BE12F40B921F47ED3E20B40F959 +S315E6315AF04100018B210040B9010000B9E02F40B9E0 +S315E6315B0000040011E02F00B9E12F40B9E00F40B9AA +S315E6315B103F00006B03FEFF541F2003D5FFC3009100 +S315E6315B20C0035FD6FD7BBCA9FD030091A00F00F94A +S315E6315B30A11700B9A21300B9A01740B921FEFF9704 +S315E6315B40A03700B9A03740B9003C0012A03300B9FE +S315E6315B50A03740B9007C1053001C0012A02F00B9C3 +S315E6315B60A03740B9007C1853A02B00B9A02F40B915 +S315E6315B701F8000718100005400008012A03F00B9F9 +S315E6315B8008000014A02F40B9210080522020C01A07 +S315E6315B9001040051A02B40B92020C01AA03F00B91C +S315E6315BA0A03340B91FFC0F7188000054E01F8052C4 +S315E6315BB0A03B00B903000014E00F8052A03B00B9C8 +S315E6315BC0A13340B9A03B40B92000000AE003002AE0 +S315E6315BD000F47ED3A10F40F92000008B000040B9D6 +S315E6315BE0A02700B9A02B40B9A11340B92120C01A8C +S315E6315BF0A02740B92100004AA03F40B92000000A5B +S315E6315C00A12740B92000004AA02700B9A13340B9FF +S315E6315C10A03B40B92000000AE003002A00F47ED317 +S315E6315C20A10F40F92000008BA12740B9010000B948 +S315E6315C301F2003D5FD7BC4A8C0035FD6FD7BBCA977 +S315E6315C40FD030091A00F00F9A11700B9A01740B9DD +S315E6315C50DCFDFF97A03700B9A03740B9003C00120A +S315E6315C60A03300B9A03740B9007C1053001C0012AE +S315E6315C70A02F00B9A03740B9007C1853A02B00B944 +S315E6315C80A02F40B91F8000718100005400008012B8 +S315E6315C90A03F00B906000014A02F40B9210080527A +S315E6315CA02020C01A00040051A03F00B9A03340B904 +S315E6315CB01FFC0F7188000054E01F8052A03B00B9EB +S315E6315CC003000014E00F8052A03B00B9A13340B97E +S315E6315CD0A03B40B92000000AE003002A00F47ED357 +S315E6315CE0A10F40F92000008B000040B9A02700B98A +S315E6315CF0A02B40B9A12740B92124C01AA03F40B90B +S315E6315D002000000AA02700B9A02740B9FD7BC4A828 +S315E6315D10C0035FD6FD7BBDA9FD030091C00100F04E +S315E6315D2000200091010040B900E089523F00006B46 +S315E6315D3021010054C00100F000300091000040B965 +S315E6315D401F0400718900005400088452A02700B967 +S315E6315D500300001420088452A02700B9A04300911D +S315E6315D60E10300AA003C805210FFFF97BF2B00B932 +S315E6315D700000805284FBFF97A02F00B91000001473 +S315E6315D80A02F40B900F47ED3A1C300912000008B49 +S315E6315D90000440D101E04FB9A02740B93F00006B7E +S315E6315DA06000005420008052A02B00B9A02F40B9E4 +S315E6315DB00004001174FBFF97A02F00B9A02F40B95C +S315E6315DC01F0C0071E9FDFF54A02B40B9FD7BC3A83A +S315E6315DD0C0035FD6FD7BBDA9FD030091F30B00F948 +S315E6315DE00000805268FBFF97A02F00B9100000141F +S315E6315DF0A02F40B901641A5380C4805220CFBC72B9 +S315E6315E002000000BF303002A807F805278FDFF974E +S315E6315E10E103002AE00313AA71F9FF97A02F40B9EF +S315E6315E200004001158FBFF97A02F00B9A02F40B907 +S315E6315E301F0C0071E9FDFF5474FCFF971F2003D553 +S315E6315E40F30B40F9FD7BC3A8C0035FD6FF8300D1D0 +S315E6315E50E00F00B9E10B00B9E20700B9E3070079D3 +S315E6315E60E10740B9E00F40B9207C001BE01B00B9E1 +S315E6315E70E10B40B900909052C003A072207C001B22 +S315E6315E80E11B40B92008C01AE01F00B9E11F40B94D +S315E6315E90E00B40B9217C001B00909052C003A07202 +S315E6315EA0217C001BE01B40B93F00006B80000054AB +S315E6315EB0E01F40B900040011E01F00B9E10740795F +S315E6315EC0E01F40B93F00006B82000054E01F40B945 +S315E6315ED0003C005302000014E0074079FF8300914D +S315E6315EE0C0035FD6FD7BBCA9FD030091F30B00F938 +S315E6315EF0A02F00B9A12B00B9A21300F9BF3F00B913 +S315E6315F001C000014A03F80B900F87FD3A11340F9F5 +S315E6315F103300008B800000D001200891A03F80B984 +S315E6315F2000F47ED32000008B00004079E203002A9C +S315E6315F30800000D001200891A03F80B900F47ED3DD +S315E6315F402000008B0008009100004079E303002A27 +S315E6315F50A12B40B9A02F40B9BDFFFF97003C0053B6 +S315E6315F6060020079A03F40B900040011A03F00B9B4 +S315E6315F70A03F40B91F5400716DFCFF54A01340F9A0 +S315E6315F8000A80091000040791F340071A900005441 +S315E6315F90A01340F900A80091C101805201000079B1 +S315E6315FA0A01340F900B00091A11340F921300091D8 +S315E6315FB022004079A11340F9212000912100407950 +S315E6315FC04100010B213C005301000079A01340F951 +S315E6315FD000B80091A11340F92130009122004079B1 +S315E6315FE0A11340F921280091210040794100010BA6 +S315E6315FF0213C0053010000791F2003D5F30B40F90C +S315E6316000FD7BC4A8C0035FD6FF8300D1E01F0079CC +S315E6316010E11FC079C00100D000800091000040B98F +S315E6316020207C001B00741E53E103002AC00100D018 +S315E631603000900091000040B9200CC01AE01F00B96B +S315E6316040E01F40B961D09B526163A872017C219B06 +S315E631605021FC60D3217C0C13007C1F132000004BFE +S315E6316060E01F00B9E01F40B9003C0013FF83009101 +S315E6316070C0035FD6FD7BBDA9FD030091F35301A9AC +S315E6316080C00100D000200091010040B900E08952FC +S315E63160903F00006BC1040054C00100D000300091CE +S315E63160A0000040B91F040071280400546030805264 +S315E63160B0CFFCFF97F303002A60308052D8FCFF9776 +S315E63160C0E103002A800C80520020C11AE103002A3E +S315E63160D0E003132A73FCFF97002D8052C4FCFF9729 +S315E63160E0F303002AE00100B000402A91012D8052E7 +S315E63160F0D3FEFF97E103002AE003132A69FCFF97F3 +S315E6316100E02F8052BAFCFF97F303002AE00100B094 +S315E631611000402A91E12F8052C9FEFF97E103002A1A +S315E6316120E003132A5FFCFF9740000014603080528B +S315E6316130AFFCFF97F303002A60308052B8FCFF9735 +S315E6316140E103002A800C8A520020C11AE103002AB3 +S315E6316150E003132A53FCFF97002D8052A4FCFF97E8 +S315E6316160F403002AE00100B000402A91212D805245 +S315E6316170B3FEFF97133C1053E00100B000402A917D +S315E6316180012D8052AEFEFF976002002AE103002A16 +S315E6316190E003142A43FCFF97402D805294FCFF9787 +S315E63161A0F303002AE00100B000402A91412D8052E6 +S315E63161B0A3FEFF97E103002AE003132A39FCFF9792 +S315E63161C0E02F80528AFCFF97F403002AE00100B003 +S315E63161D000402A910130805299FEFF97133C1053C5 +S315E63161E0E00100B000402A91E12F805294FEFF97FC +S315E63161F06002002AE103002AE003142A29FCFF970C +S315E6316200203080527AFCFF97F303002AE00100B092 +S315E631621000402A912130805289FEFF97E103002A18 +S315E6316220E003132A1FFCFF97EBFEFF97000080522F +S315E63162305FFBFF97C00100D000200091010040B915 +S315E631624000E089523F00006BC1000054C00100D026 +S315E631625000300091000040B91F040071A9010054D5 +S315E6316260203B805262FCFF97F303002A203B8052A3 +S315E63162706BFCFF97E103002A200080520020C11A09 +S315E6316280E103002AE003132A06FCFF97D2FEFF97C5 +S315E6316290000080523CFAFF97A02F00B90D0000149A +S315E63162A0A02F40B901641A5380C0805220CFBC7208 +S315E63162B02000000BE003002A01E2815248F8FF97FD +S315E63162C0A02F40B9000400112FFAFF97A02F00B98D +S315E63162D0A02F40B91F0C007149FEFF544BFBFF97C7 +S315E63162E00000805228FAFF97A02F00B90D0000145E +S315E63162F0A02F40B901641A5380C0805220CFBC72B8 +S315E63163002000000BE003002A21E2815234F8FF97A0 +S315E6316310A02F40B9000400111BFAFF97A02F00B950 +S315E6316320A02F40B91F0C007149FEFF5437FBFF978A +S315E63163300000805214FAFF97A02F00B9100000141E +S315E63163401F2003D5A02F40B9015C1853800A885225 +S315E631635020CFBC722000000BE003002A29F8FF9714 +S315E6316360001000121F7C0071E1FEFF54A02F40B9E8 +S315E63163700004001104FAFF97A02F00B9A02F40B907 +S315E63163801F0C0071E9FDFF5420FBFF971F2003D553 +S315E6316390F35341A9FD7BC3A8C0035FD6FD7BBCA9F8 +S315E63163A0FD03009140008052A03F00B91A00001467 +S315E63163B0800000B001E00691A03F80B900F87FD3B6 +S315E63163C002F47ED30000028B2000008B0000407978 +S315E63163D0E103002AC00100D000900091000040B9E7 +S315E63163E0207C001B02781F53C00100D0008000914B +S315E63163F0010040B9E003012A00781F530000010B82 +S315E63164005F00006B02010054A03F40B90004001161 +S315E6316410A03F00B9A03F40B91F180071ADFCFF544B +S315E6316420020000141F2003D5A03F40B91F140071A6 +S315E6316430CD000054E00100D000500291A100805217 +S315E6316440010000B905000014A13F40B9E00100D0D2 +S315E631645000500291010000B9C00100D000C00091A0 +S315E6316460000040F9000440391F001F6B200200543A +S315E6316470E00100D000500291020040B9800000B040 +S315E631648001E00691E003022A00F87FD302F47ED3D7 +S315E63164900000028B2000008B000C00910100403990 +S315E63164A0E00100D0003003910100003910000014FC +S315E63164B0E00100D000500291020040B9800000B000 +S315E63164C001E00691E003022A00F87FD302F47ED397 +S315E63164D00000028B2000008B000800910100403954 +S315E63164E0E00100D00030039101000039E00100D02F +S315E63164F000500291020040B9800000B001E00691F9 +S315E6316500E003022A00F87FD302F47ED30000028B41 +S315E63165102000008B0010009101004039E00100D0E7 +S315E63165200034039101000039C00100D000800091AA +S315E6316530030040B9C00100D000900091010040B996 +S315E6316540E00100D000600291E20300AAE003032AEB +S315E631655065FEFF97C00100D000200091010040B9E9 +S315E631656000E089523F00006B21160054C00100D08D +S315E631657000300091000040B91F040071080C005448 +S315E6316580600000D001E00C91E00100B000401291CC +S315E6316590020B80524AFDFF97600000D001601291EE +S315E63165A0E00100B000401A91A204805244FDFF9703 +S315E63165B0600000D001C01491E00100B000402291A4 +S315E63165C0A20480523EFDFF97600000D0012017916C +S315E63165D0E00100B000402A916207805238FDFF970C +S315E63165E0600000D001E01A91E00100B0004032913E +S315E63165F0A216805232FDFF97E00100B000401191BC +S315E631660001808052010000B9E00100B000501191DD +S315E631661001C08052010000B9E00100B0006011917D +S315E631662001D08052010000B9E00100B0007011914D +S315E631663001E08052010000B9E00100B0008011911D +S315E631664001408052010000B9E00100B0009011919D +S315E631665001108052010000B9E00100B000A01191AD +S315E631666001108052010000B9E00100B000B011918D +S315E631667001108052010000B9E00100B000C011916D +S315E631668001108052010000B9E00100B000D011914D +S315E631669001208052010000B9E00100B000E011911D +S315E63166A0010B8052010000B9E00100B000F0119112 +S315E63166B0A1048052010000B9E00100B00000129158 +S315E63166C0A1048052010000B9E00100B00010129138 +S315E63166D061078052010000B9E00100B00020129155 +S315E63166E0A1168052010000B9E00100B000301291E6 +S315E63166F021008052010000B9AB000014600000F0C1 +S315E631670001400191E00100B000401291220C805225 +S315E6316710EBFCFF97600000F001600791E00100B005 +S315E631672000401A91A2048052E5FCFF97600000F022 +S315E631673001200C91E00100B000402A91E209805235 +S315E6316740DFFCFF97600000F001201191E00100B017 +S315E631675000403291A21E8052D9FCFF97E00100B08B +S315E63167600040119101808052010000B9E00100B08C +S315E63167700050119101C08052010000B9E00100B02C +S315E63167800070119101D08052010000B9E00100B0EC +S315E63167900080119101408052010000B9E00100B05C +S315E63167A00090119101108052010000B9E00100B06C +S315E63167B000A0119101088052010000B9E00100B054 +S315E63167C000C0119101108052010000B9E00100B01C +S315E63167D000D0119101208052010000B9E00100B0EC +S315E63167E000E01191210C8052010000B9E00100B0C0 +S315E63167F000F01191A1048052010000B9E00100B028 +S315E631680000101291E1098052010000B9E00100B0B1 +S315E631681000201291A11E8052010000B9E00100B0BC +S315E6316820003012911F0000B95F000014600000D0FD +S315E631683001402691E00100B000401291220B8052D0 +S315E63168409FFCFF97600000D001E02B91E00100B09C +S315E631685000401A91A204805299FCFF97600000D05D +S315E631686001402E91E00100B000402291A20480520F +S315E631687093FCFF97600000D001A03091E00100B0B3 +S315E631688000402A91020880528DFCFF97600000D0C5 +S315E631689001A03491E00100B00040329142198052B4 +S315E63168A087FCFF97E00100B000401191010081526B +S315E63168B0010000B9E00100B000501191014081526A +S315E63168C0010000B9E00100B000601191015081523A +S315E63168D0010000B9E00100B00070119101708152FA +S315E63168E0010000B9E00100B000801191014080520B +S315E63168F0010000B9E00100B000901191011080521B +S315E6316900010000B9E00100B000A0119101108052FA +S315E6316910010000B9E00100B000B0119101108052DA +S315E6316920010000B9E00100B000C0119101108052BA +S315E6316930010000B9E00100B000D01191012080528A +S315E6316940010000B9E00100B000E01191210B80525F +S315E6316950010000B9E00100B000F01191A1048052C6 +S315E6316960010000B9E00100B000001291A1048052A5 +S315E6316970010000B9E00100B0001012910108805221 +S315E6316980010000B9E00100B00020129141198052B0 +S315E6316990010000B9E00100B00030129141008052A9 +S315E63169A0010000B9C00100D000200091010040B9D4 +S315E63169B000E089523F00006B01020054C00100D06D +S315E63169C000300091000040B91F04007161010054A6 +S315E63169D0E00100B000402A9142288252012D8052D0 +S315E63169E051FCFF97E00100B000402A9142288252DD +S315E63169F0E12F80524CFCFF97C00100D00020009178 +S315E6316A00010040B900408A523F00006B61010054F3 +S315E6316A10C00100D000300091000040B91F001F6B65 +S315E6316A20C1000054E00100B00040129102008052EC +S315E6316A30E10580523CFCFF97E00100D0006002910F +S315E6316A4000544079A05F0079A15F4079E00100B05A +S315E6316A5000401291E203012A211A805232FCFF9755 +S315E6316A60A05F407900080051E103002AE00100B059 +S315E6316A7000401291E203012A411A80522AFCFF971D +S315E6316A80E00100D00030039100004039E103002AED +S315E6316A90A05F40792000004BE103002AE00100B017 +S315E6316AA000403291E203012AC15980521EFCFF971A +S315E6316AB0E00100B0004012918117805260FCFF97E9 +S315E6316AC01F001F6BE0000054E00100D00034039153 +S315E6316AD00000403900040051A03300B90500001426 +S315E6316AE0E00100D00034039100004039A03300B90B +S315E6316AF0A03340B901080051E00100B000403291BF +S315E6316B00E203012A415A805207FCFF97E00100B0C1 +S315E6316B1000403291A23340B9C144805202FCFF971C +S315E6316B20C00100D000C00091000040F900044039B0 +S315E6316B301F001F6B80010054E00100B00040129146 +S315E6316B4022008052A1028052F7FBFF97E00100B0A6 +S315E6316B500040129102008052010B8052F2FBFF9700 +S315E6316B600B000014E00100B00040129102008052A1 +S315E6316B70A1028052ECFBFF97E00100B00040129192 +S315E6316B8002208052010B8052E7FBFF97E00100D0ED +S315E6316B9000500291020040B9800000B001E0069152 +S315E6316BA0E003022A00F87FD302F47ED30000028B9B +S315E6316BB02000008B001C009100004039A01B00B973 +S315E6316BC0E00100D000500291020040B9800000B0E9 +S315E6316BD001E00691E003022A00F87FD302F47ED380 +S315E6316BE00000028B2000008B002000910000403926 +S315E6316BF0A01F00B9E00100B000403291816D8052AC +S315E6316C000FFCFF97A03300B9C00100D000C0009158 +S315E6316C10000040F9000440391F001F6BA000005404 +S315E6316C20A03340B900041A32A02300B90400001497 +S315E6316C30A03340B900741812A02300B9BF3F00B99A +S315E6316C402D000014BF3700B925000014800000B0CE +S315E6316C5000600B91A13740B9A23F80B942F47ED3A9 +S315E6316C604100018B017861B8A21B40B9E00100B061 +S315E6316C7000403291ACFBFF97800000B000E00B910B +S315E6316C80A13740B9A23F80B942F47ED34100018BA8 +S315E6316C90017861B8A21F40B9E00100B000403291F7 +S315E6316CA0A1FBFF97800000B000600C91A13740B997 +S315E6316CB0A23F80B942F47ED34100018B017861B8B7 +S315E6316CC0A22340B9E00100B00040329196FBFF972E +S315E6316CD0A03740B900040011A03700B9A03740B952 +S315E6316CE01F0C007149FBFF54A03F40B90004001167 +S315E6316CF0A03F00B9A03F40B91F0400714DFAFF54D9 +S315E6316D00C00100D000200091010040B900E089526F +S315E6316D103F00006BC1000054C00100D00030009145 +S315E6316D20000040B91F04007149000054D2FCFF97B8 +S315E6316D3021008052A0268052F4FAFF972100805234 +S315E6316D40E0028052FCFAFF97BF3B00B923000014FC +S315E6316D50E00100B000901191010040B9A03B40B985 +S315E6316D60217C001BE00100B000401191000040B9E2 +S315E6316D702000000BA02B00B9BF3F00B90E0000146E +S315E6316D80A13F40B9A02B40B92200000BE00100B08B +S315E6316D9000401291A13F80B9007861B8E103002A3B +S315E6316DA0E003022A3FF9FF97A03F40B900040011FC +S315E6316DB0A03F00B9A13F40B9E00100B000E0119132 +S315E6316DC0000040B93F00006BC3FDFF54A03B40B91C +S315E6316DD000040011A03B00B9A03B40B91F0C00717D +S315E6316DE089FBFF54E00100B000501191000040B933 +S315E6316DF0A02B00B9BF3F00B90E000014A13F40B940 +S315E6316E00A02B40B92200000BE00100B000401A91F8 +S315E6316E10A13F80B9007861B8E103002AE003022A8E +S315E6316E2020F9FF97A03F40B900040011A03F00B911 +S315E6316E30A13F40B9E00100B000F01191000040B940 +S315E6316E403F00006BC3FDFF54E00100B00030129104 +S315E6316E50000040B91F001F6B60050054BF3B00B907 +S315E6316E6023000014E00100B000B01191010040B9F1 +S315E6316E70A03B40B9217C001BE00100B000601191D6 +S315E6316E80000040B92000000BA02B00B9BF3F00B986 +S315E6316E900E000014A13F40B9A02B40B92200000BE9 +S315E6316EA0E00100B000402291A13F80B9007861B897 +S315E6316EB0E103002AE003022AFAF8FF97A03F40B938 +S315E6316EC000040011A03F00B9A13F40B9E00100B08E +S315E6316ED000001291000040B93F00006BC3FDFF543C +S315E6316EE0A03B40B900040011A03B00B9E00100B077 +S315E6316EF000301291000040B9A13B40B93F00006B2A +S315E6316F0023FBFF54E00100B000701191000040B957 +S315E6316F10A02B00B9BF3F00B90E000014A13F40B91E +S315E6316F20A02B40B92200000BE00100B000402A91C7 +S315E6316F30A13F80B9007861B8E103002AE003022A6D +S315E6316F40D8F8FF97A03F40B900040011A03F00B939 +S315E6316F50A13F40B9E00100B000101291000040B9FE +S315E6316F603F00006BC3FDFF54E00100B00080119194 +S315E6316F70000040B9A02B00B9BF3F00B90E0000149E +S315E6316F80A13F40B9A02B40B92200000BE00100B089 +S315E6316F9000403291A13F80B9007861B8E103002A19 +S315E6316FA0E003022ABFF8FF97A03F40B9000400117B +S315E6316FB0A03F00B9A13F40B9E00100B000201291EF +S315E6316FC0000040B93F00006BC3FDFF541F2003D5D7 +S315E6316FD0FD7BC4A8C0035FD6FD7BBDA9FD03009149 +S315E6316FE000008052E8F6FF97A02B00B93A0100146B +S315E6316FF0BF2700B958000014C00100D000C0009187 +S315E6317000020040F9A12B40B9E00301AA00F47ED390 +S315E631701003F07DD30000038B0000018B00F47ED3B1 +S315E63170204000008B0050009100004079E103002AD0 +S315E6317030A02740B900741E532128C01A207C1F139D +S315E6317040007C1F532100000B210000122000004B6B +S315E6317050021C0053A02740B9A1433FD12000008B43 +S315E6317060E103022A01803F39C00100B000C0009138 +S315E6317070020040F9A32740B9A12B40B9E00301AAA2 +S315E631708000F47ED304F07DD30000048B0000018B3F +S315E63170900000038B00F47ED34000008B001840B924 +S315E63170A0E303002A02008052A12740B9A02B40B95A +S315E63170B0E7F8FF97C00100B000C00091030040F940 +S315E63170C0A22740B9A12B40B9E00301AA00F47ED349 +S315E63170D004F07DD30000048B0000018B00F47ED3EF +S315E63170E06000008B0000028B00A000910000403961 +S315E63170F0E303002A22008052A12740B9A02B40B9EA +S315E6317100D3F8FF97A02740B9A1433FD12000008BA2 +S315E631711000807F391F001F6BE00000540300805268 +S315E6317120E20B8052A12740B9A02B40B9C8F8FF97A8 +S315E63171300600001423008052E20B8052A12740B9A3 +S315E6317140A02B40B9C2F8FF97A02740B90004001139 +S315E6317150A02700B9A02740B91F0C0071E9F4FF5406 +S315E631716020008052A01B00B9C00100B000C00091DA +S315E6317170020040F9A12B40B9E00301AA00F47ED31F +S315E631718003F07DD30000038B0000018B00F47ED340 +S315E63171904000008B00400091010040B90011915248 +S315E63171A00011A0722000002AA02300B9C00100B068 +S315E63171B000200091010040B900E089523F00006BA2 +S315E63171C061020054C00100B000300091000040B9C0 +S315E63171D01F040071C9010054A22340B9A12080528F +S315E63171E0A02B40B9FFF8FF9702008052C1208052AA +S315E63171F0A02B40B9FBF8FF97A21B40B9013A805262 +S315E6317200A02B40B9F7F8FF9715000014A22340B931 +S315E6317210E1208052A02B40B9F2F8FF970200805266 +S315E631722001218052A02B40B9EEF8FF97A22340B94F +S315E631723021218052A02B40B9EAF8FF97020080520D +S315E631724041218052A02B40B9E6F8FF97A21B40B9FF +S315E631725061218052A02B40B9E2F8FF97C00100B018 +S315E631726000200091010040B900E089523F00006BF1 +S315E6317270C1020054C00100B000300091000040B9AF +S315E63172801F04007129020054C00100B000C000910C +S315E6317290020040F9A12B40B9E00301AA00F47ED3FE +S315E63172A003F07DD30000038B0000018B00F47ED31F +S315E63172B04000008B00400091000040B9005C0012AE +S315E63172C0A02300B925000014BF2300B9C00100B0E0 +S315E63172D000C00091020040F9A12B40B9E00301AAB2 +S315E63172E000F47ED303F07DD30000038B0000018BDF +S315E63172F000F47ED34000008B00400091000040B997 +S315E6317300A01F00B9BF2F00B911000014A01F40B964 +S315E6317310020C0012A12F40B9E003012A00741E5374 +S315E63173200000010B4020C01AA12340B92000002AF3 +S315E6317330A02300B9A01F40B9007C0453A01F00B9B1 +S315E6317340A02F40B900040011A02F00B9A02F40B9F3 +S315E63173501F140071CDFDFF54A22340B9E1238052BB +S315E6317360A02B40B99FF8FF97BF2300B9C00100B003 +S315E631737000C00091020040F9A12B40B9E00301AA11 +S315E631738000F47ED303F07DD30000038B0000018B3E +S315E631739000F47ED34000008B005000910000407926 +S315E63173A0A01F00B9C00100B000200091010040B92C +S315E63173B000E089523F00006B81050054C00100B000 +S315E63173C000300091000040B91F040071E904005411 +S315E63173D0A01F40B9A02300B92200805241848052D1 +S315E63173E0A02B40B97FF8FF97A02340B9000C0012D5 +S315E63173F0E203002A61848052A02B40B979F8FF97DF +S315E6317400A02340B9007C0453000C0012E203002AA3 +S315E631741081848052A02B40B972F8FF97A02340B9F8 +S315E6317420007C0853000C0012E203002AA184805244 +S315E6317430A02B40B96BF8FF97A02340B9007C0C53DB +S315E6317440000C0012E203002AC1848052A02B40B917 +S315E631745064F8FF9702008052C1398052A02B40B9B9 +S315E631746060F8FF9714000014BF2F00B90F0000141F +S315E6317470A01F40B901040012A02F40B900781F536E +S315E63174802020C01AA12340B92000002AA02300B942 +S315E6317490A01F40B9007C0453A01F00B9A02F40B904 +S315E63174A000040011A02F00B9A02F40B91F0C0071BE +S315E63174B00DFEFF54A22340B9A1398052A02B40B923 +S315E63174C048F8FF97A02B40B900040011AEF5FF97B7 +S315E63174D0A02B00B9A02B40B91F0C0071A9D8FF54D7 +S315E63174E01F2003D5FD7BC3A8C0035FD6FF8300D13A +S315E63174F0E00F00B9E10B00B9E20300F9E00B40B960 +S315E63175001F0400718900005460008052E01700B90B +S315E63175100300001420008052E01700B9FF1F00B9BE +S315E63175201B000014C00100B000C00091020040F912 +S315E6317530E10F40B9E00301AA00F47ED303F07DD32F +S315E63175400000038B0000018B00F47ED34000008BF4 +S315E63175500050009100004079E103002AE01F40B96E +S315E631756000741E532028C01A000C0012E01B00B925 +S315E6317570E11740B9E01B40B93F00006B000100540A +S315E6317580E01F40B900040011E01F00B9E01F40B921 +S315E63175901F0C007189FCFF54020000141F2003D52D +S315E63175A0C00100B000C00091020040F9E10F40B9D8 +S315E63175B0E00301AA00F47ED303F07DD30000038B0A +S315E63175C00000018B00F47ED34000008B0040009131 +S315E63175D0000040B9E01B00B9E01F40B900000012D7 +S315E63175E01F001F6BC0000054E11B40B900119152D8 +S315E63175F00011A0722000002AE01B00B9E00340F931 +S315E6317600E11B40B9010000B91F2003D5FF83009184 +S315E6317610C0035FD6FD7BBBA9FD0300910000805216 +S315E631762059F5FF97A04F00B91D010014BF4300B9C4 +S315E6317630BF4B00B958000014C00100B000C000913C +S315E6317640020040F9A14F40B9E00301AA00F47ED326 +S315E631765003F07DD30000038B0000018B00F47ED36B +S315E63176604000008B0050009100004079E103002A8A +S315E6317670A04B40B900741E532028C01A000C0012E4 +S315E6317680A02F00B9A02F40B9001C0053000000120C +S315E6317690021C0053A04B40B9A1C33ED12000008B5A +S315E63176A0E103022A01203F39A02F40B91F040071B8 +S315E63176B001010054A04B40B91F040071A9000054E2 +S315E63176C0A14340B9A00080522000002AA04300B968 +S315E63176D0A02F40B91F0C007101010054A04B40B9EF +S315E63176E01F040071A9000054A14340B9000A805233 +S315E63176F02000002AA04300B9C00100B000C00091C5 +S315E6317700020040F9A34B40B9A14F40B9E00301AAC3 +S315E631771000F47ED304F07DD30000048B0000018BA8 +S315E63177200000038B00F47ED34000008B001840B98D +S315E6317730E303002AC20B8052A14B40B9A04F40B9B0 +S315E631774043F7FF97A04B40B9A1C33ED12000008B4A +S315E631775000207F391F001F6BE00000540300805282 +S315E6317760E20B8052A14B40B9A04F40B938F7FF97AB +S315E63177700600001423008052E20B8052A14B40B939 +S315E6317780A04F40B932F7FF97A04B40B9000400113C +S315E6317790A04B00B9A04B40B91F0C0071E9F4FF5478 +S315E63177A0C00100B000C00091020040F9A14F40B9D6 +S315E63177B0E00301AA00F47ED303F07DD30000038B08 +S315E63177C00000018B00F47ED34000008B004000912F +S315E63177D0000040B9A02B00B9A22B40B9E123805273 +S315E63177E0A04F40B97FF7FF97A24340B9C1298052EE +S315E63177F0A04F40B97BF7FF97A0530091E20300AA69 +S315E631780001008052A04F40B939FFFF97C00100B061 +S315E631781000200091010040B900E089523F00006B3B +S315E631782081020054C00100B000300091000040B939 +S315E63178301F040071E9010054A01740B9E203002A9A +S315E6317840A1208052A04F40B966F7FF9702008052D9 +S315E6317850C1208052A04F40B962F7FF97220080528D +S315E6317860013A8052A04F40B95EF7FF9716000014F1 +S315E6317870A01740B9E203002AE1208052A04F40B971 +S315E631788058F7FF970200805201218052A04F40B946 +S315E631789054F7FF970200805221218052A04F40B91A +S315E63178A050F7FF970200805241218052A04F40B9EE +S315E63178B04CF7FF972200805261218052A04F40B9A2 +S315E63178C048F7FF97BF4B00B96E000014A00A805205 +S315E63178D0A09F0039A00A8052A09B003980478B527F +S315E63178E0A04B00792300805282588052A14B40B991 +S315E63178F0A04F40B9D6F6FF970301805262588052BF +S315E6317900A14B40B9A04F40B9D1F6FF97A04B40B94C +S315E6317910A1C33ED12000008B00207F391F001F6BAB +S315E631792080000054A09B4039A03F00B90300001403 +S315E6317930A09F4039A03F00B9C00100B000C0009118 +S315E6317940020040F9A34B40B9A14F40B9E00301AA81 +S315E631795000F47ED304F07DD30000048B0000018B66 +S315E63179600000038B00F47ED34000008B001840B94B +S315E6317970A02F00B9BF3B00B9BF3300B9BF3700B955 +S315E63179801D000014A03740B900741E53A12F40B92B +S315E63179902024C01A000C0012A02300B9A02340B956 +S315E63179A0210080522020C01AA13340B92000002A96 +S315E63179B0A03300B9A02340B9210080522120C01A54 +S315E63179C0A03F40B92000000A1F001F6BE0000054BB +S315E63179D0A03740B9210080522020C01AA13B40B9D8 +S315E63179E02000002AA03B00B9A03740B900040011B7 +S315E63179F0A03700B9A03740B91F1C007149FCFF54C6 +S315E6317A00A04B4079A04700B9A04B40B9A1C33ED1BE +S315E6317A102000008B00207F391F001F6BC100005408 +S315E6317A20A03B40B9001C0853A14740B92000002AC3 +S315E6317A30A04700B9A04B40B9A1C33ED12000008B87 +S315E6317A4000207F391F001F6BC0000054A03B40B9B0 +S315E6317A50003C1053A14740B92000002AA04700B99F +S315E6317A60A34740B9E2068052A14B40B9A04F40B98F +S315E6317A7077F6FF97A04B40B900040011A04B00B949 +S315E6317A80A04B40B91F0C007129F2FF54A04F40B903 +S315E6317A90000400113CF4FF97A04F00B9A04F40B95E +S315E6317AA01F0C007149DCFF541F2003D5FD7BC5A8A9 +S315E6317AB0C0035FD6FD7BBAA9FD030091F30B00F94E +S315E6317AC0C00100B000200091010040B900E08952C2 +S315E6317AD03F00006B01010054C00100B00030009157 +S315E6317AE0000040B91F04007168000054CAFEFF97D2 +S315E6317AF00200001439FDFF970000805222F4FF9709 +S315E6317B00A05B00B958000014BF5700B94F00001406 +S315E6317B10BFA70079BF5F00B928000014C00100B0E5 +S315E6317B2000C00091020040F9A35F80B9A15B40B97C +S315E6317B30E00301AA00F47ED304F07DD30000048B82 +S315E6317B400000018B00F87FD30000038B00400091E3 +S315E6317B5000F87FD34000008B00184079A04F00B97A +S315E6317B60A04F40B9021C0053A05F80B9A1833ED134 +S315E6317B702000008BE103022A01003F39A04F40B9CC +S315E6317B80000018121F001F6B20010054A05F40B998 +S315E6317B90210080522020C01A013C0013A0A7C079EB +S315E6317BA02000002A003C0013A0A70079A05F40B967 +S315E6317BB000040011A05F00B9A05F40B91F3C007117 +S315E6317BC0EDFAFF54A02340B9E303002A220B805293 +S315E6317BD0A15740B9A05B40B91DF6FF97A02740B93A +S315E6317BE0E303002A420B8052A15740B9A05B40B964 +S315E6317BF017F6FF97A02B40B9E303002A620B8052B2 +S315E6317C00A15740B9A05B40B911F6FF97A02F40B90D +S315E6317C10E303002A820B8052A15740B9A05B40B9F3 +S315E6317C200BF6FF97A0A74079E303002AA20B805211 +S315E6317C30A15740B9A05B40B905F6FF97A05740B9C1 +S315E6317C4000040011A05700B9A05740B91F0C0071C6 +S315E6317C5009F6FF54A05B40B900040011CAF3FF9759 +S315E6317C60A05B00B9A05B40B91F0C0071E9F4FF5483 +S315E6317C70C00100B000C00091000040F9000440792F +S315E6317C80F303002AC00100B000C00091000040F9BC +S315E6317C900008C079DDF8FF97003C00136002000B5F +S315E6317CA0A04B00B9E0038052790800940000805277 +S315E6317CB0B5F3FF97A05B00B92A000014BF5F00B9A0 +S315E6317CC021000014C00100B000C00091030040F964 +S315E6317CD0A25F80B9A15B40B9E00301AA00F47ED385 +S315E6317CE004F07DD30000048B0000018B00F47ED3D3 +S315E6317CF06000008B0000028B003001910000C03934 +S315E6317D00003C0013C1F8FF97A08F0079600000D0E0 +S315E6317D1000A02391A15F80B9037861B8A18FC079BC +S315E6317D20A04B40B92000000BE203002AE103032A07 +S315E6317D30A05B40B92BF6FF97A05F40B9000400116E +S315E6317D40A05F00B9A05F40B91F240071CDFBFF5497 +S315E6317D50A05B40B9000400118BF3FF97A05B00B935 +S315E6317D60A05B40B91F0C0071A9FAFF54000080529E +S315E6317D7047080094C00100B000C00091000040F908 +S315E6317D80000C4079A04B00B9000080527EF3FF9794 +S315E6317D90A05B00B94D000014BF5700B9440000148A +S315E6317DA0BF5F00B93C000014A05740B901701D53BE +S315E6317DB0A05F40B92000000BA04300B9A05F40B9EF +S315E6317DC01F20007141020054C00100B000C000918D +S315E6317DD0030040F9A25740B9A15B40B9E00301AAD5 +S315E6317DE000F47ED304F07DD30000048B0000018BD2 +S315E6317DF000F47ED36000008B0000028B00580191BF +S315E6317E0000004039A047013911000014C00100B025 +S315E6317E1000C00091030040F9A24340B9A15B40B9E5 +S315E6317E20E00301AA00F47ED304F07DD30000048B8F +S315E6317E300000018B00F47ED36000008B0000028BDC +S315E6317E400068019100004039A0470139A047C139A0 +S315E6317E50003C00136DF8FF97A07F0079600000D0F3 +S315E6317E6000402191A15F80B9027861B8A17FC079DE +S315E6317E70A04B40B92000000BE303002AA15740B9D5 +S315E6317E80A05B40B972F5FF97A05F40B900040011D7 +S315E6317E90A05F00B9A05F40B91F2000716DF8FF54AD +S315E6317EA0A05740B900040011A05700B9A05740B910 +S315E6317EB01F0C007169F7FF54A05B40B9000400114D +S315E6317EC031F3FF97A05B00B9A05B40B91F0C007197 +S315E6317ED049F6FF54C00100B000C00091000040F9F8 +S315E6317EE000104079A04B00B90000805226F3FF9787 +S315E6317EF0A05B00B958000014BF5700B94F00001413 +S315E6317F00BF5F00B947000014A05740B901701D5351 +S315E6317F10A05F40B92000000BA03B00B9A05F40B995 +S315E6317F201F20007141020054C00100B000C000912B +S315E6317F30030040F9A25740B9A15B40B9E00301AA73 +S315E6317F4000F47ED304F07DD30000048B0000018B70 +S315E6317F5000F47ED36000008B0000028B00E80191CD +S315E6317F6000004039A043013911000014C00100B0C8 +S315E6317F7000C00091030040F9A23B40B9A15B40B98C +S315E6317F80E00301AA00F47ED304F07DD30000048B2E +S315E6317F900000018B00F47ED36000008B0000028B7B +S315E6317FA000F8019100004039A0430139A043C139B7 +S315E6317FB0003C001315F8FF97A06F0079600000D0FA +S315E6317FC000E02191A15F80B9027861B8A16FC079ED +S315E6317FD0A04B40B92000000BE303002AA15740B974 +S315E6317FE0A05B40B91AF5FF97600000D00080229178 +S315E6317FF0A15F80B9027861B8A16FC079A04B40B96B +S315E63180002000000BE303002AA15740B9A05B40B933 +S315E63180100FF5FF97A05F40B900040011A05F00B9E4 +S315E6318020A05F40B91F2000710DF7FF54A05740B944 +S315E631803000040011A05700B9A05740B91F0C0071D2 +S315E631804009F6FF54A05B40B900040011CEF2FF9762 +S315E6318050A05B00B9A05B40B91F0C0071E9F4FF548F +S315E63180601F2003D5F30B40F9FD7BC6A8C0035FD6C7 +S315E6318070FD7BBEA9FD03009141018052000480D209 +S315E631808020CFBCF2D6F0FF9741008052008080D2F5 +S315E631809020CFBCF2D2F0FF9721008052000280D287 +S315E63180A020CFBCF2CEF0FF9741008052800080D2DD +S315E63180B020CFBCF2CAF0FF97C001009000200091B4 +S315E63180C0010040B900E089523F00006B410100549E +S315E63180D0C001009000300091000040B91F040071E4 +S315E63180E0A800005401028252800082D220CFBCF22F +S315E63180F0BBF0FF97BF1F00B918000014BF1B00B9CC +S315E631810010000014A11F40B960009252E0CCA17272 +S315E63181102000000B01741E53A01B40B92000000B52 +S315E631812000741E53E003002A4140815261C0A172B8 +S315E6318130ABF0FF97A01B40B900040011A01B00B9B4 +S315E6318140A01B40B91F0C0071E9FDFF54A01F40B9D1 +S315E631815000040011A01F00B9A01F40B91F0C007121 +S315E6318160E9FCFF54C001009000200091010040B9BE +S315E631817000408A523F00006BA10C0054809C9C5211 +S315E6318180809CBC72A01700B9BF1F00B95900001414 +S315E6318190C001009000C00091000040F9000040396E +S315E63181A0E103002AA01F40B92028C01A00000012B8 +S315E63181B01F001F6B80090054A01F40B900701D5384 +S315E63181C0E11F80522020C01AE003202AE103002A6B +S315E63181D0A01740B92200000AC001009000C0009104 +S315E63181E0030040F9A11F40B9E00301AA00F47ED3AA +S315E63181F004F07DD30000048B0000018B00F47ED3BE +S315E63182006000008B005000910000407903040012B3 +S315E6318210C001009000C00091040040F9A11F40B9A9 +S315E6318220E00301AA00F47ED305F07DD30000058B89 +S315E63182300000018B00F47ED38000008B0050009164 +S315E63182400000407900041C12007C02136300002A08 +S315E6318250C001009000C00091040040F9A11F40B969 +S315E6318260E00301AA00F47ED305F07DD30000058B49 +S315E63182700000018B00F47ED38000008B0050009124 +S315E63182800000407900041812007C04136300002ACA +S315E6318290C001009000C00091040040F9A11F40B929 +S315E63182A0E00301AA00F47ED305F07DD30000058B09 +S315E63182B00000018B00F47ED38000008B00500091E4 +S315E63182C00000407900041412007C06136100002A8E +S315E63182D0A01F40B900701D532020C01A4000002A65 +S315E63182E0A01700B9A01F40B900040011A01F00B9BC +S315E63182F0A01F40B91F0C0071C9F4FF54A11740B94C +S315E6318300003E81D220CFBCF235F0FF971F2003D550 +S315E6318310FD7BC2A8C0035FD6FD7BBDA9FD030091F7 +S315E6318320C001009000800091040040B9C001009080 +S315E631833000900091050040B9C00100F000001191AE +S315E6318340010040B9600000F000E00A91E103012A3C +S315E631835000786178E103002A007D8052207C001B9B +S315E631836003008052E203002AE103052AE003042AE8 +S315E6318370B7F6FF97013C0053E001009000600291A9 +S315E631838001600079C001009000800091040040B997 +S315E6318390C001009000900091050040B9C00100F09F +S315E63183A000001191010040B9600000F000E00A9149 +S315E63183B0E103012A211C009100786178E103002A64 +S315E63183C0007D8052207C001B03008052E203002AA6 +S315E63183D0E103052AE003042A9DF6FF97013C0053A3 +S315E63183E0E00100900060029101640079E0010090BD +S315E63183F00030039100004039E103002A006080D263 +S315E631840020CFBCF2F6EFFF97E001009000340391FE +S315E631841000004039E103002A806080D220CFBCF2E9 +S315E6318420EFEFFF9701008052006180D220CFBCF298 +S315E6318430EBEFFF97E001009000600291000C407986 +S315E6318440E103002A806180D220CFBCF2E4EFFF97C8 +S315E6318450E00100900060029100144079003C10532F +S315E6318460E101009021600291211040790000012A54 +S315E6318470E103002A006280D220CFBCF2D8EFFF9723 +S315E6318480E00100900060029100584079E103002A4C +S315E6318490806280D220CFBCF2D1EFFF97E001009027 +S315E63184A00060029100184079E103002A006380D228 +S315E63184B020CFBCF2CAEFFF97E0010090006002914F +S315E63184C000244079003C1053E1010090216002918D +S315E63184D0212440790000012AE103002A806380D213 +S315E63184E020CFBCF2BEEFFF97E0010090006002912B +S315E63184F0002C4079E103002A006480D220CFBCF219 +S315E6318500B7EFFF97E00100900060029100084079ED +S315E6318510E103002A806480D220CFBCF2B0EFFF9728 +S315E6318520E001009000500291020040B9600000F08F +S315E631853001E00691E003022A00F87FD302F47ED306 +S315E63185400000028B2000008B0014009100004039B8 +S315E6318550E103002A006580D220CFBCF2A0EFFF9777 +S315E6318560E00100900030039100004039E103002A32 +S315E6318570E001009000600291003040792000000B66 +S315E631858000240011E10100902134039121004039A4 +S315E63185900000014B00100011E103002A806580D20C +S315E63185A020CFBCF28EEFFF97E001009000340391C5 +S315E63185B00000403900240011E1010090216002916A +S315E63185C0212040790000010BA02300B9A02340B950 +S315E63185D0013C1053A02340B92000002AE103002ACA +S315E63185E0006680D220CFBCF27DEFFF97E0010090A6 +S315E63185F00060029100604079003C1053E101009041 +S315E631860021600291216440790000012AE103002AC2 +S315E6318610806680D220CFBCF271EFFF97E001009001 +S315E63186200060029100344079003C1053E10100903C +S315E631863021600291213440790000012AE103002AC2 +S315E6318640006780D220CFBCF265EFFF97E00100905C +S315E63186500060029100004079003C1053E101009040 +S315E631866021600291213C40790000012AE103002A8A +S315E6318670806780D220CFBCF259EFFF97C00100F078 +S315E631868000403291C14480526DF5FF97A01300B98F +S315E6318690C00100F000403291415A805268F5FF97A9 +S315E63186A0A01700B9E001009000300391000040398F +S315E63186B000400011A01B00B9C00100F00040329124 +S315E63186C0C15980525EF5FF9700040051A01F00B9EB +S315E63186D0A01F40B9011C0853A01B40B9003C1053FA +S315E63186E02100002AA01740B9005C18532100002A60 +S315E63186F0A01340B92000002AE103002A006880D29F +S315E631870020CFBCF236EFFF97A01340B900140051E3 +S315E6318710A01300B9A0008052A01700B9A01F40B936 +S315E631872000140011A01B00B9C0008052A01F00B989 +S315E6318730A01F40B9011C0853A01B40B9003C105399 +S315E63187402100002AA01740B9005C18532100002AFF +S315E6318750A01340B92000002AE103002A006C80D23A +S315E631876020CFBCF21EEFFF97E00100900060029148 +S315E631877000404079011C0853E00100900060029107 +S315E631878000484079003C10532000002AE103002AD4 +S315E6318790806880D220CFBCF211EFFF97010080527C +S315E63187A0006980D220CFBCF20DEFFF9701008052EF +S315E63187B0806980D220CFBCF209EFFF97E0010090C5 +S315E63187C00060029100644079E103002AE0010090FD +S315E63187D000600291003440792000000BA02300B9F5 +S315E63187E0A02340B9013C1053A02340B92000002A0A +S315E63187F0E103002A006A80D220CFBCF2F8EEFF9779 +S315E6318800C001009000A00091000040B91F20007120 +S315E631881061030054C001009000200091010040B987 +S315E631882000E089523F00006BC1000054C001009060 +S315E631883000300091000040B91F001F6B0002005462 +S315E631884000018052A02300B9A02340B9013C105360 +S315E6318850A02340B92000002AE103002A806A80D2AB +S315E631886020CFBCF2DEEEFF9741008052806B80D29C +S315E631887020CFBCF2DAEEFF9725000014C001009056 +S315E631888000A00091000040B91F2C00710802005487 +S315E631889060018052A02300B9A02340B9013C1053B0 +S315E63188A0A02340B92000002AE103002A806A80D25B +S315E63188B020CFBCF2CAEEFF9701008052806B80D2A0 +S315E63188C020CFBCF2C6EEFF9711000014C00100902E +S315E63188D000A00091000040B9A02300B9A02340B919 +S315E63188E0013C1053A02340B92000002AE103002AB7 +S315E63188F0806A80D220CFBCF2B9EEFF970100805272 +S315E6318900806B80D220CFBCF2B5EEFF97E0010090C6 +S315E631891000600291004C4079E103002A007D8052E5 +S315E6318920207C001BA02300B9A02340B9003C10539C +S315E6318930E1010090216002912150407921B0001188 +S315E63189400000012AA02300B9A12340B9006B80D2E9 +S315E631895020CFBCF2A2EEFF9701008052806C80D226 +S315E631896020CFBCF29EEEFF97BF2F00B9250000144B +S315E6318970A02F40B900741E53E1008E522028C01A4A +S315E6318980000C0012A02300B9BF2700B900008052BF +S315E63189907DF0FF97A02B00B90A000014A02740B955 +S315E63189A0016C1C53A02340B92000002AA02700B948 +S315E63189B0A02B40B90004001173F0FF97A02B00B944 +S315E63189C0A02B40B91F0C0071A9FEFF54A02F40B968 +S315E63189D00008001100741E53E103002A0086805216 +S315E63189E020CFBC722000000BE003002AA12740B954 +S315E63189F07BEEFF97A02F40B900040011A02F00B9F6 +S315E6318A00A02F40B91F0C00714DFBFF540100805277 +S315E6318A1000A080D220CFBCF271EEFF97E001009044 +S315E6318A200060029100584079013C0053C001009044 +S315E6318A3000900091000040B9E003002A207C009BBB +S315E6318A4000E87BD301F47ED30000018B01F47ED3BB +S315E6318A500100018BC001009000800091000040B911 +S315E6318A60E003002A2008C09AA01F00B9E001009071 +S315E6318A700060029100084079E103002AE0010090A6 +S315E6318A8000600291001040792000000B017C409392 +S315E6318A90C001009000900091000040B9E003002A41 +S315E6318AA0207C009B00E87BD301F47ED30000018B6A +S315E6318AB001F47ED30100018BC00100900080009164 +S315E6318AC0000040B9E003002A2008C09AA01B00B98D +S315E6318AD0E001009000340391000040390124001191 +S315E6318AE0E001009000500291030040B9600000F0C9 +S315E6318AF002E00691E003032A00F87FD303F47ED33E +S315E6318B000000038B4000008B0014009100004039D1 +S315E6318B102000000B017C4093C0010090009000914B +S315E6318B20000040B9E003002A207C009B00E87BD3B5 +S315E6318B3001F47ED30000018B01F47ED30100018B73 +S315E6318B40C001009000800091000040B9E003002AA0 +S315E6318B502008C09AA01700B9E001009000600291A2 +S315E6318B6000104079A01300B9A01F40B9011C085383 +S315E6318B70A01B40B9003C10532100002AA01740B98A +S315E6318B80005C18532100002AA01340B92000002AC0 +S315E6318B90E103002A00E082D220CFBCF210EEFF9745 +S315E6318BA0806580D220CFBCF216EEFF97E003002A2D +S315E6318BB0011C4092C001009000900091000040B93E +S315E6318BC0E003002A207C009B00E87BD301F47ED3C8 +S315E6318BD00000018B01F47ED30100018BC0010090C8 +S315E6318BE000800091000040B9E003002A2008C09ACF +S315E6318BF0A01F00B9006680D220CFBCF201EEFF9706 +S315E6318C00E003002A011C4092C001009000900091D9 +S315E6318C10000040B9E003002A207C009B00E87BD3C4 +S315E6318C2001F47ED30000018B01F47ED30100018B82 +S315E6318C30C001009000800091000040B9E003002AAF +S315E6318C402008C09AA01B00B9E001009000600291AD +S315E6318C50000C4079013C0053C00100900090009130 +S315E6318C60000040B9E003002A207C009B00E87BD374 +S315E6318C7001F47ED30000018B01F47ED30100018B32 +S315E6318C80C001009000800091000040B9E003002A5F +S315E6318C902008C09AA01700B980018052A01300B906 +S315E6318CA0A01F40B9011C0853A01B40B9003C105324 +S315E6318CB02100002AA01740B9005C18532100002A8A +S315E6318CC0A01340B92000002AE103002A00E182D24E +S315E6318CD020CFBCF2C2EDFF97E00100900060029131 +S315E6318CE000644079013C0053C00100900090009148 +S315E6318CF0000040B9E003002A207C009B00E87BD3E4 +S315E6318D0001F47ED30000018B01F47ED30100018BA1 +S315E6318D10C001009000800091000040B9E003002ACE +S315E6318D202008C09AA01300B9A01340B9E103002A7E +S315E6318D30800482D220CFBCF2A9EDFF970143865259 +S315E6318D408100A072802081D220CFBCF2A4EDFF97BC +S315E6318D50811E8052002181D220CFBCF2A0EDFF9751 +S315E6318D60212282524148A472000482D220CFBCF23B +S315E6318D709BEDFF9761248252E125A07280E182D292 +S315E6318D8020CFBCF296EDFF9721008052000282D2C7 +S315E6318D9020CFBCF292EDFF97E1068052E101A07257 +S315E6318DA0000082D220CFBCF28DEDFF97C001009054 +S315E6318DB000200091010040B900E089523F00006B86 +S315E6318DC041010054C001009000300091000040B9E5 +S315E6318DD01F040071A1000054010EA052000286D292 +S315E6318DE020CFBCF27EEDFF97C001009000200091C6 +S315E6318DF0010040B900E089523F00006B410300545F +S315E6318E00C001009000300091000040B91F001F6B91 +S315E6318E10C1000054E1008052803F81D220CFBCF2BE +S315E6318E206FEDFF9714000014C001009000300091F9 +S315E6318E30000040B91F040071C1000054A100805200 +S315E6318E40803F81D220CFBCF265EDFF970A00001450 +S315E6318E5021008052803F81D220CFBCF260EDFF9770 +S315E6318E600500001421008052803F81D220CFBCF22A +S315E6318E705BEDFF971F2003D5FD7BC3A8C0035FD605 +S315E6318E80FD7BBEA9FD030091000080523EEFFF97C0 +S315E6318E90A01F00B958000014BF1B00B93D000014ED +S315E6318EA0E001009000C01191A11B40B9A21F40B963 +S315E6318EB042F87FD34100018B007861B81FFC03711C +S315E6318EC0A1010054A11F40B960009252E0CCA172D3 +S315E6318ED02000000B01741E53A01B40B92000000B85 +S315E6318EE000741E53E003002A010080523CEDFF97E1 +S315E6318EF025000014A11F40B960009252E0CCA17260 +S315E6318F002000000B01741E53A01B40B92000000B54 +S315E6318F1000741E53E403002AE001009000C011916B +S315E6318F20A11B40B9A21F40B942F87FD34100018B5C +S315E6318F30007861B80000001201040253E0010090A6 +S315E6318F4000C01191A21B40B9A31F40B963F87FD384 +S315E6318F506200028B007862B800040011007C01538E +S315E6318F6000380011001C08532100002A4040815286 +S315E6318F706000A0722000002AE103002AE00304AA79 +S315E6318F8017EDFF97A01B40B900040011A01B00B9ED +S315E6318F90A01B40B91F04007149F8FF54A11F40B91F +S315E6318FA060009252E0CCA1722000000B006C1C539B +S315E6318FB000200011E003002A0100805208EDFF97F8 +S315E6318FC0A11F40B960009252E0CCA1722000000B9D +S315E6318FD0006C1C5300300011E003002A0100805278 +S315E6318FE0FFECFF97A01F40B900040011E6EEFF97AC +S315E6318FF0A01F00B9A01F40B91F0C0071E9F4FF5458 +S315E631900001028052800081D220CFBCF2F4ECFF9788 +S315E6319010A00100F000C00091000040F9000440399B +S315E63190201F001F6BA00000546100805200A380D25E +S315E631903020CFBCF2EAECFF97A00100F000200091C8 +S315E6319040010040B900E089523F00006BE10100546E +S315E6319050A00100F000300091000040B91F04007114 +S315E631906049010054A00100F000C00091000040F92A +S315E6319070000440391F001F6B800000540120A052C6 +S315E63190800002825287F0FF97F7ECFF97E103002A59 +S315E6319090A00100F000800091000040B9217C001B60 +S315E63190A060BA8952400CA272207CA09B00FC60D348 +S315E63190B0017C0753A00100F000900091000040B911 +S315E63190C02008C01AA01700B9A01740B9003C001213 +S315E63190D000000D32E103002A808280D220CFBCF235 +S315E63190E0BFECFF972100A052008380D220CFBCF29D +S315E63190F0BBECFF97010280520120A072808480D2B8 +S315E631910020CFBCF2B6ECFF97A00100F0002000912B +S315E6319110010040B900E089523F00006B610100541D +S315E6319120A00100F000300091000040B91F04007143 +S315E6319130C9000054210080528104A57280A580D2EF +S315E631914020CFBCF2A6ECFF97C00100F000A011914A +S315E6319150000040B91F040071A1010054200080527D +S315E63191608010A172C1EFFF97ABEFFF9720008052D7 +S315E63191708050A172BDEFFF97A7EFFF9700028052AD +S315E63191808090A072B9EFFF97A3EFFF972100805247 +S315E6319190804080D220CFBCF291ECFF9721008052FD +S315E63191A0004080D220CFBCF28DECFF971F2003D54D +S315E63191B0FD7BC2A8C0035FD6FD7BBDA9FD03009149 +S315E63191C02000A052A02300B9C00100D000402A9168 +S315E63191D0E13480529AF2FF97000000121F001F6BAE +S315E63191E0A000005401008052001A8052D2F1FF9756 +S315E63191F00400001421008052001A8052CEF1FF9706 +S315E6319200A00100F000200091010040B900E089524A +S315E63192103F00006B41060054A00100F0003000919A +S315E6319220000040B91F040071A8050054EAF2FF9721 +S315E6319230000080525EEFFF970000805252EEFF97B4 +S315E6319240A02F00B90D000014A02F40B901641A53BE +S315E631925080C0805220CFBC722000000BE003002A8A +S315E631926001E281525EECFF97A02F40B9000400116E +S315E631927045EEFF97A02F00B9A02F40B91F0C00711C +S315E631928049FEFF5461EFFF97000080523EEEFF97AD +S315E6319290A02F00B90D000014A02F40B901641A536E +S315E63192A080C0805220CFBC722000000BE003002A3A +S315E63192B021E281524AECFF97A02F40B90004001112 +S315E63192C031EEFF97A02F00B9A02F40B91F0C0071E0 +S315E63192D049FEFF544DEFFF970600001441008052D8 +S315E63192E0203B805294F1FF9748EFFF97BAF2FF970A +S315E63192F00000805224EEFF97A02F00B90D0000142E +S315E6319300A02F40B901641A5380C3805220CFBC7274 +S315E63193102000000BE003002A21E0995230ECFF975A +S315E6319320A02F40B90004001117EEFF97A02F00B920 +S315E6319330A02F40B91F0C007149FEFF5433EFFF975A +S315E6319340BF2B00B9BF2700B92D00001400008052AB +S315E63193500DEEFF97A02F00B918000014A12F40B9E2 +S315E631936000839C522073A0722000000B00641A53CE +S315E6319370E003002A23ECFF97A01F00B9A01F40B9EE +S315E6319380000000121F001F6B00010054A02F40B9E8 +S315E6319390210080522020C01AE103002AA02B40B9D1 +S315E63193A00000012AA02B00B9A02F40B90004001114 +S315E63193B0F5EDFF97A02F00B9A02F40B91F0C00712C +S315E63193C0E9FCFF5411EFFF97C00100F000901191CF +S315E63193D0000040B9A12B40B93F00006BE0010054D3 +S315E63193E0A02740B9001C00121F001F6B81000054F4 +S315E63193F021008052601080524FF1FF97A02740B985 +S315E631940001040011A12700B9A12340B91F00016B60 +S315E6319410E3F9FF54020000141F2003D5C00100F022 +S315E631942000901191010040B9A02B40B92100000A04 +S315E6319430C00100F000901191000040B93F00006B89 +S315E631944060000054E01F805216000014000080527E +S315E6319450CDEDFF97A02F00B90D000014A02F40B92E +S315E631946001641A5380C0805220CFBC722000000BB3 +S315E6319470E003002A01028052D9EBFF97A02F40B9CB +S315E631948000040011C0EDFF97A02F00B9A02F40B917 +S315E63194901F0C007149FEFF54DCEEFF970000805247 +S315E63194A0FD7BC3A8C0035FD6FD7BBCA9FD03009156 +S315E63194B0A01F00B9600000D001600E91A0A3009113 +S315E63194C0220040F9020000F9210840B9010800B945 +S315E63194D0BF3B00B92D00001400008052AAEDFF977C +S315E63194E0A03F00B923000014A03B40B900F47ED377 +S315E63194F0A10301912000008B000440D100E84FB969 +S315E6319500E103002AA03F40B91EF1FF97A03700B923 +S315E6319510A01F40B91F001F6BA0000054A03740B909 +S315E631952000001232A03700B904000014A03740B962 +S315E631953000781112A03700B9A03B40B900F47ED3CA +S315E6319540A10301912000008B000440D100E84FB918 +S315E6319550A23740B9E103002AA03F40B921F0FF978F +S315E6319560A03F40B90004001187EDFF97A03F00B94F +S315E6319570A03F40B91F0C007189FBFF54A03B40B9AF +S315E631958000040011A03B00B9A03B40B91F080071A9 +S315E631959049FAFF541F2003D5FD7BC4A8C0035FD625 +S315E63195A0FD7BBBA9FD030091F30B00F9C00100D0A9 +S315E63195B000402A91E1328052A1F1FF97A04300B9EA +S315E63195C0BF3F00B9BF4F00B913000014A04F40B9F1 +S315E63195D000741E53E103002A0008805220C2BC7291 +S315E63195E02000000BE003002A86EBFF97E103002A11 +S315E63195F0A04F80B900F47ED3A24301914000008B9F +S315E6319600000440D101D00FB9A04F40B90004001192 +S315E6319610A04F00B9A04F40B91F0400718DFDFF542C +S315E6319620BF4700B9600000D002200391A04740B998 +S315E6319630E10300AA20F47ED3E10300AA20F47ED327 +S315E6319640000001CB4000008B000040B91F04003119 +S315E6319650E0050054600000D002200391A04740B9EE +S315E6319660E10300AA20F47ED3E10300AA20F47ED3F7 +S315E6319670000001CB4000008B010040B9A02340B980 +S315E63196803F00006BC1030054600000D00220039115 +S315E6319690A04740B9E10300AA20F47ED3E10300AA4C +S315E63196A020F47ED3000001CB4000008B0010009100 +S315E63196B0010040B9A02740B93F00006B01020054D2 +S315E63196C0600000D002200391A04740B9E10300AA29 +S315E63196D020F47ED3E10300AA20F47ED3000001CB49 +S315E63196E04000008B00200091000040B9A04300B94C +S315E63196F020008052A03F00B906000014A04740B9C9 +S315E631970000040011A04700B9C7FFFF171F2003D594 +S315E6319710A03F40B91F001F6BA0030054BF4700B9F5 +S315E6319720170000146000009000202391A14740B94C +S315E6319730017861B8C00100D000402A9140F1FF9727 +S315E6319740A03700B9A03740B901380F12A04340B966 +S315E63197502000002AA03700B960000090002023914E +S315E6319760A14740B9007861B8A13740B967F0FF97AC +S315E6319770A04740B900040011A04700B9A04740B957 +S315E63197801F1C007109FDFF54A9000014A00100F069 +S315E631979000200091010040B900408A523F00006B3B +S315E63197A0C1000054A00100F000300091000040B93C +S315E63197B01F001F6BC013005421008052001A8052DD +S315E63197C05DF0FF97D3328052C1328052C00100D06C +S315E63197D000402A911AF1FF9700380F12E103002A69 +S315E63197E0E003132A49F0FF97210080520035805273 +S315E63197F046F0FF97210080522035805243F0FF979D +S315E631980000008052E0ECFF97A04B00B90D00001442 +S315E6319810E1358052A04B40B95AF0FF97A03700B9EF +S315E6319820A03740B9000009121F001F6B20FFFF5415 +S315E6319830A04B40B900040011D3ECFF97A04B00B919 +S315E6319840A04B40B91F0C007149FEFF54A00100F050 +S315E631985000300091000040B91F04007188090054B8 +S315E631986000008052C8ECFF97A04B00B944000014C3 +S315E6319870C0328052E103002AA04B40B941F0FF974E +S315E6319880A03700B9A03740B9007C0C53001000125E +S315E6319890A03B00B9A03B40B900200011A03B00B97E +S315E63198A0A03B40B91F7C007169000054E003805249 +S315E63198B0A03B00B9E1358052A04B40B931F0FF9774 +S315E63198C0A03700B9A03740B9007C06530014001220 +S315E63198D0A03300B9A03740B900140012A02F00B961 +S315E63198E0BF4700B91F0000146000009000202391A5 +S315E63198F0A14740B9017861B8C00100D000402A914C +S315E6319900CFF0FF97A03700B9A03740B901380F122B +S315E6319910A03B40B9004C14532100002AA03340B98C +S315E631992000641A532100002AA02F40B92000002AEC +S315E6319930A03700B96000009000202391A14740B9D5 +S315E6319940007861B8A23740B9E103002AA04B40B9A5 +S315E631995024EFFF97A04740B900040011A04700B9AC +S315E6319960A04740B91F1C007109FCFF54A04B40B912 +S315E63199700004001184ECFF97A04B00B9A04B40B927 +S315E63199801F0C007169F7FF5429000014000080525C +S315E63199907DECFF97A04B00B922000014BF4700B912 +S315E63199A0190000146000009000202391A14740B9C8 +S315E63199B0007861B8E103002AA04B40B9F1EFFF9791 +S315E63199C0A03700B96000009000202391A14740B945 +S315E63199D0037861B8A03740B901680F1200008A52A0 +S315E63199E02000A0722000002AE203002AE103032ABE +S315E63199F0A04B40B9FBEEFF97A04740B900040011F2 +S315E6319A00A04700B9A04740B91F1C0071C9FCFF54F5 +S315E6319A10A04B40B9000400115BECFF97A04B00B9AF +S315E6319A20A04B40B91F0C0071A9FBFF54A03F40B9CA +S315E6319A307F13009400008052F30B40F9FD7BC5A8F5 +S315E6319A40C0035FD6FD7BBDA9FD030091A01F00B91A +S315E6319A50A01F40B9002C0C53A02B00B92000805230 +S315E6319A60A02F00B978000014A02F40B900641A532C +S315E6319A70E103002AA02B40B92100002A00A1815238 +S315E6319A8080C0A1722000002A78EDFF97600000D0F1 +S315E6319A9001600B91A02F80B900EC7CD32000008BBE +S315E6319AA0010040B9C00100D00040329164F0FF9721 +S315E6319AB0A02700B9A12B40B9A02740B92100002A39 +S315E6319AC00020805280C0A1722000002A67EDFF9700 +S315E6319AD0600000D001E00B91A02F80B900EC7CD379 +S315E6319AE02000008B010040B9C00100D00040329120 +S315E6319AF053F0FF97A02700B9A12B40B9A02740B96B +S315E6319B002100002A0040805280C0A1722000002A3E +S315E6319B1056EDFF97600000D001600C91A02F80B919 +S315E6319B2000EC7CD32000008B010040B9C00100D0A7 +S315E6319B300040329142F0FF97A02700B9A12B40B9F8 +S315E6319B40A02740B92100002A0060805280C0A17268 +S315E6319B502000002A45EDFF97600000D001E00C9128 +S315E6319B60A02F80B900EC7CD32000008B010040B9F0 +S315E6319B70C00100D00040329131F0FF97A02700B9FD +S315E6319B80A12B40B9A02740B92100002A00608152B5 +S315E6319B9080C0A1722000002A34EDFF97600000D024 +S315E6319BA001600D91A02F80B900EC7CD32000008BAB +S315E6319BB0010040B9C00100D00040329120F0FF9754 +S315E6319BC0A02700B9A12B40B9A02740B92100002A28 +S315E6319BD00080815280C0A1722000002A23EDFF97D2 +S315E6319BE0600000D001E00D91A02F80B900EC7CD366 +S315E6319BF02000008B010040B9C00100D0004032910F +S315E6319C000FF0FF97A02700B9A12B40B9A02740B99D +S315E6319C102100002A00C0815280C0A1722000002AAC +S315E6319C2012EDFF97A12B40B9C0C2825280C0A17214 +S315E6319C302000002A0DEDFF97A02F40B90004005110 +S315E6319C40A02F00B9A02F40B91F001F6BEAF0FF54D1 +S315E6319C501F2003D5FD7BC3A8C0035FD6FD7BBDA917 +S315E6319C60FD030091A01F00B900D490522000A072E6 +S315E6319C70A02B00B9A00100F000200091010040B907 +S315E6319C8000E089523F00006B01010054A00100F06B +S315E6319C9000300091000040B91F040071680000549D +S315E6319CA00000805258000014A01F40B91F001F6BF8 +S315E6319CB04005005420008052A02F00B900008052A2 +S315E6319CC0B1EBFF97A02700B910000014A02740B9E1 +S315E6319CD001641A5300C6805220CFBC722000000BB5 +S315E6319CE0E003002AC7E9FF97E103002AA02F40B92E +S315E6319CF00000010AA02F00B9A02740B900040011DF +S315E6319D00A1EBFF97A02700B9A02740B91F0C007138 +S315E6319D10E9FDFF54A02B40B900040051A02B00B950 +S315E6319D20A02F40B9000000121F001F6BE0179F1AE3 +S315E6319D30011C0053A02B40B91F001F6BE0079F1A89 +S315E6319D40001C00532000000A001C00531F001F6B45 +S315E6319D5021FBFF5428000014BF2F00B900008052C2 +S315E6319D6089EBFF97A02700B910000014A02740B968 +S315E6319D7001641A5300C6805220CFBC722000000B14 +S315E6319D80E003002A9FE9FF97E103002AA02F40B9B5 +S315E6319D900000012AA02F00B9A02740B9000400111E +S315E6319DA079EBFF97A02700B9A02740B91F0C0071C0 +S315E6319DB0E9FDFF54A02B40B900040051A02B00B9B0 +S315E6319DC0A02F40B9000000121F001F6BE0079F1A53 +S315E6319DD0011C0053A02B40B91F001F6BE0079F1AE9 +S315E6319DE0001C00532000000A001C00531F001F6BA5 +S315E6319DF041FBFF54A02B40B91F001F6BE0179F1A9A +S315E6319E00001C0053FD7BC3A8C0035FD6FD7BBDA90D +S315E6319E10FD030091A01F00B9A01F40B91F001F6BBB +S315E6319E2080000054409EA152A02B00B902000014D6 +S315E6319E30BF2B00B90000805253EBFF97A02F00B934 +S315E6319E400D000014A02F40B901641A5300C38052A5 +S315E6319E5020CFBC722000000BE003002AA12B40B9CB +S315E6319E605FE9FF97A02F40B90004001146EBFF9753 +S315E6319E70A02F00B9A02F40B91F0C007149FEFF543F +S315E6319E801F2003D5FD7BC3A8C0035FD6FD7BBDA9E5 +S315E6319E90FD030091A01F00B9A00100F0002000915A +S315E6319EA0010040B900E089523F00006B610300547E +S315E6319EB0A00100F000300091000040B91F040071A6 +S315E6319EC0C8020054000080522FEBFF97A02F00B94D +S315E6319ED00E000014A02F40B901641A5380C2805295 +S315E6319EE020CFBC722000000BE003002AA21F40B946 +S315E6319EF0E103805249E9FF97A02F40B900040011EA +S315E6319F0021EBFF97A02F00B9A02F40B91F0C0071A6 +S315E6319F1029FEFF5418000014000080521AEBFF9711 +S315E6319F20A02F00B911000014A02F40B901641A53CD +S315E6319F3080C0805220CFBC722000000BE303002A9A +S315E6319F40A01F40B9001C0853E203002A01E0A352E0 +S315E6319F50E00303AA31E9FF97A02F40B900040011C7 +S315E6319F6009EBFF97A02F00B9A02F40B91F0C00715E +S315E6319F70C9FDFF5425ECFF971F2003D5FD7BC3A80A +S315E6319F80C0035FD6FD7BBDA9FD030091A01F00B9D5 +S315E6319F902000805232FFFF97A02F00B9A02F40B99B +S315E6319FA01F001F6B6000005420008052150000141C +S315E6319FB0A01F40B9FEEBFF97A01F40B9B4FFFF974C +S315E6319FC02000805292FFFF970000805224FFFF97D0 +S315E6319FD0A02F00B9000080528DFFFF97A02F40B920 +S315E6319FE01F001F6BC0000054600000D000A00E9128 +S315E6319FF0C7E8FF9720008052020000140000805225 +S315E631A000FD7BC3A8C0035FD6FD7BBFA9FD030091E7 +S315E631A01021008052C02780523CEEFF9721008052C4 +S315E631A0200038805239EEFF971F2003D5FD7BC1A854 +S315E631A030C0035FD6FD7BBBA9FD030091F30B00F9A7 +S315E631A0402000A052A03700B921008052C03B805291 +S315E631A0502EEEFF9700008052CBEAFF97A04700B974 +S315E631A06010000014A04740B901641A5380C48052E7 +S315E631A07020CFBC722000000BF303002A807F80528A +S315E631A080DBECFF97E103002AE00313AAD4E8FF9756 +S315E631A090A04740B900040011BBEAFF97A04700B9D3 +S315E631A0A0A04740B91F0C0071E9FDFF5421008052EB +S315E631A0B000A480D220CFBCF2C9E8FF97D3EBFF9755 +S315E631A0C0BF3300B9BF4F00B9BF3F00B9BF4300B98F +S315E631A0D0A03740B9A04B00B9A03340B901641A5351 +S315E631A0E000C6805220CFBC722000000BE003002A66 +S315E631A0F0C4E8FF9700000012A03B00B9A00100D0EA +S315E631A10000200091010040B900E089523F00006B22 +S315E631A110C1010054A00100D000300091000040B9E1 +S315E631A1201F04007128010054A04B40B9002C0012DF +S315E631A1301F0400718100005420008052A03B00B913 +S315E631A14002000014BF3B00B9A03B40B91F001F6BAC +S315E631A15040020054A04340B91F001F6BC0000054B3 +S315E631A1600000805288FFFF97A04F00B9BF4300B980 +S315E631A170060000142000805283FFFF97A04F00B9F6 +S315E631A18020008052A04300B9A04F40B91F001F6B93 +S315E631A1902007005440000014A04340B91F001F6B4E +S315E631A1A0A00600540000805277EAFF97A04700B92F +S315E631A1B028000014A04740B9210080522020C01A59 +S315E631A1C0E103002AA03F40B92000000A1F001F6BB9 +S315E631A1D061030054A04740B901641A5300C5805261 +S315E631A1E020CFBC722000000BE003002A85E8FF97FA +S315E631A1F0A02F00B9807F805289ECFF97E103002AD0 +S315E631A200A02F40B90024C11AA02F00B9A02F40B91A +S315E631A210000000121F001F6B40010054A04740B9F1 +S315E631A220210080522020C01AE103002AA03F40B91E +S315E631A2300000012AA03F00B9020000141F2003D511 +S315E631A240A04740B9000400114FEAFF97A04700B98D +S315E631A250A04740B91F0C0071E9FAFF54C00100D09E +S315E631A26000901191000040B9A13F40B93F00006B23 +S315E631A27000010054A04B40B900040051A04B00B98F +S315E631A280A04B40B91F001F6B81F2FF540200001448 +S315E631A2901F2003D5000080523BEAFF97A04700B95D +S315E631A2A012000014E235805201008052A04740B9CF +S315E631A2B09FECFF97A02F00B9817F8052A04740B926 +S315E631A2C0B0EDFF97A02F00B9A22F40B9A17F8052FA +S315E631A2D0A04740B9C3ECFF97A04740B90004001147 +S315E631A2E029EAFF97A04700B9A04740B91F0C00718C +S315E631A2F0A9FDFF5488EEFF971F001F6B60000054DF +S315E631A300A01F805202000014A03F40B9F30B40F97A +S315E631A310FD7BC5A8C0035FD6FD7BBCA9FD030091D5 +S315E631A320F30B00F9C00100D000A01191921200940E +S315E631A3300000805214EAFF97A03700B90D000014E9 +S315E631A340A03740B901641A5300C4805220CFBC729B +S315E631A3502000000BE003002A41AB945220E8FF9738 +S315E631A360A03740B90004001107EAFF97A03700B9D4 +S315E631A370A03740B91F0C007149FEFF5423EBFF9716 +S315E631A380A00100D000200091010040B900E08952D9 +S315E631A3903F00006B21020054A00100D0003000914D +S315E631A3A0000040B91F04007189010054A00100D0B4 +S315E631A3B000C00091000040F9000440391F001F6BD0 +S315E631A3C0C0000054210080520120A0720002825260 +S315E631A3D0B4EBFF970400001421008052000282524A +S315E631A3E0B0EBFF9723F7FF97EDEFFF97B2F5FF97C0 +S315E631A3F000008052E4E9FF97A03700B90D0000145A +S315E631A400A03740B901641A5300C2805220CFBC72DC +S315E631A4102000000BE003002A21008052F0E7FF9787 +S315E631A420A03740B900040011D7E9FF97A03700B944 +S315E631A430A03740B91F0C007149FEFF54F3EAFF9786 +S315E631A440B6F7FF9700008052CFE9FF97A03700B9FC +S315E631A4500D000014A03740B901641A5300C2805288 +S315E631A46020CFBC722000000BE003002A01008052A7 +S315E631A470DBE7FF97A03740B900040011C2E9FF9741 +S315E631A480A03700B9A03740B91F0C007149FEFF5419 +S315E631A490DEEAFF9749FBFF97A03300B9A03340B90F +S315E631A4A01F001F6B6000005400008012200100146B +S315E631A4B0C00100D000A01191000040B91F001F6B0A +S315E631A4C0A0000054600000B000E00E9190E7FF97DF +S315E631A4D004000014600000B000200F918CE7FF976E +S315E631A4E0C00100D000A01191000040B936120094A7 +S315E631A4F0A03300B9A03340B91F001F6BC00000542A +S315E631A500600000B000600F9181E7FF97000080128E +S315E631A5100701001423FCFF97A03300B9A03340B9F5 +S315E631A5201F001F6B6000005400008012000100140A +S315E631A530A00100D000300091000040B91F0400713F +S315E631A540890000541F0C0094A03300B903000014AF +S315E631A550BA0A0094A03300B9A03340B91F001F6B85 +S315E631A5606000005420008012F10000142100805270 +S315E631A570001A8052F0ECFF97E7EDFF97A03300B96A +S315E631A580A03340B91F001F6B6000005420008012D3 +S315E631A590E700001400008052C4FBFF9700018052A9 +S315E631A5A0A03700B9A03740B9012C0C538000A1522F +S315E631A5B02000002AADEAFF97A03740B9012C0C53AB +S315E631A5C0200080528000A1722000002AA7EAFF9778 +S315E631A5D0A03740B9012C0C53C0C2825280C0A17259 +S315E631A5E02000002AA1EAFF97A03740B9012C0C5387 +S315E631A5F0E009805280A0A1722000002A9BEAFF97EB +S315E631A600A03740B9012C0C53200A805280A0A172A2 +S315E631A6102000002A95EAFF97000080525AE9FF9713 +S315E631A620A03700B907000014A03740B906FDFF97F9 +S315E631A630A03740B90004001153E9FF97A03700B9B6 +S315E631A640A03740B91F0C007109FFFF542000805234 +S315E631A65096FBFF97000080524BE9FF97A03700B98A +S315E631A66027000014C1438052A03740B9C5ECFF97A5 +S315E631A670A03B00B9A00100D000E00091000040B94E +S315E631A680A13740B9220080524120C11A0000010AA1 +S315E631A6901F001F6BA1000054A13B40B94001805217 +S315E631A6A02000000AA03B00B9A00100D000E00091ED +S315E631A6B0000440B9A13740B9220080524120C11A7F +S315E631A6C00000010A1F001F6BA1000054A13B40B9EF +S315E631A6D0A00080522000000AA03B00B9A23B40B957 +S315E631A6E0C1438052A03740B9BEEBFF97A03740B998 +S315E631A6F00004001124E9FF97A03700B9A03740B925 +S315E631A7001F0C007109FBFF5401008052E0028052B2 +S315E631A71089ECFF97210080528019805286ECFF97AB +S315E631A72045FEFF97A02F00B9C00100D000901191E8 +S315E631A730010040B9A02F40B92100000AC00100D07E +S315E631A74000901191000040B93F00006B8000005443 +S315E631A750A02F40B9006C1C3275000014A00100D060 +S315E631A76000C00091000040F900044079F303002A65 +S315E631A770A00100D000C00091000040F90008C07980 +S315E631A78022EEFF97003C00136002000BA03B00B9B6 +S315E631A79000008052FCE8FF97A03700B92A00001482 +S315E631A7A0BF3F00B921000014A00100D000C00091DE +S315E631A7B0030040F9A23F80B9A13740B9E00301AAC7 +S315E631A7C000F47ED304F07DD30000048B0000018BC8 +S315E631A7D000F47ED36000008B0000028B00300191DD +S315E631A7E00000C039003C001308EEFF97A057007908 +S315E631A7F0400000F000A02391A13F80B9037861B80B +S315E631A800A157C079A03B40B92000000BE203002AEC +S315E631A810E103032AA03740B972EBFF97A03F40B96F +S315E631A82000040011A03F00B9A03F40B91F240071D2 +S315E631A830CDFBFF54A03740B900040011D2E8FF97AB +S315E631A840A03700B9A03740B91F0C0071A9FAFF54F9 +S315E631A850EEFDFF97A00100D000200091010040B93E +S315E631A86000E089523F00006BE1000054A00100D0C0 +S315E631A87000300091000040B91F04007148000054D1 +S315E631A880B80B0094C00100B0004012918117805296 +S315E631A890EBECFF971F001F6B40000054120C00943F +S315E631A8A00B090094A03300B9A03340B91F001F6BE2 +S315E631A8B060000054E00180121D000014D3FDFF97BD +S315E631A8C0C0040094A03300B9A03340B91F001F6B12 +S315E631A8D060000054E001801215000014CBFDFF97AD +S315E631A8E0A00100D000200091010040B900E0895274 +S315E631A8F03F00006B81010054A00100D00030009189 +S315E631A900000040B91F040071E9000054010080528D +S315E631A9102006805208ECFF9701008052C04B8052E8 +S315E631A920FAEBFF9757F9FF97A02F40B9F30B40F9AA +S315E631A930FD7BC4A8C0035FD6FD7BBBA9FD030091B1 +S315E631A940F30B00F9A02F00B9A12B00B9A22700B964 +S315E631A95000008252A03F00B9BF4300B921008052C0 +S315E631A960C0488052E9EBFF970000805286E8FF97B0 +S315E631A970A04F00B919000014A02F40B9010000120A +S315E631A980A00100D000E00091E103012A007861B828 +S315E631A990A14F40B9220080524120C11A0000010A76 +S315E631A9A01F001F6B20010054A22F40B9A12B40B9DD +S315E631A9B0A04F40B90BEBFF9722008052A12740B951 +S315E631A9C0A04F40B907EBFF97A04F40B900040011FD +S315E631A9D06DE8FF97A04F00B9A04F40B91F0C007143 +S315E631A9E0C9FCFF540000805267E8FF97A04F00B9D3 +S315E631A9F010000014A04F40B901641A5380C4805246 +S315E631AA0020CFBC722000000BF303002A4047805268 +S315E631AA1077EAFF97E103002AE00313AA70E6FF9788 +S315E631AA20A04F40B90004001157E8FF97A04F00B98F +S315E631AA30A04F40B91F0C0071E9FDFF54A02F40B974 +S315E631AA4001000012A00100D000E00091E103012AE5 +S315E631AA50007861B8A04700B96CE9FF97A03F40B9E5 +S315E631AA60A04B00B90000805247E8FF97A04F00B9E6 +S315E631AA7029000014A04F40B9210080522020C01A87 +S315E631AA80E103002AA04740B92000000A1F001F6BE8 +S315E631AA9080030054A04F40B901641A5300C5805271 +S315E631AAA020CFBC722000000BE003002A55E6FF9763 +S315E631AAB0A03B00B94047805259EAFF97E103002AA5 +S315E631AAC0A03B40B90024C11AA03B00B9A03B40B92E +S315E631AAD0000000121F001F6B60010054A04F40B901 +S315E631AAE0210080522020C01AE003202AE103002A01 +S315E631AAF0A04740B90000010AA04700B90200001498 +S315E631AB001F2003D5A04F40B9000400111EE8FF9778 +S315E631AB10A04F00B9A04F40B91F0C0071C9FAFF54D6 +S315E631AB20A04B40B900040051A04B00B9A04740B94B +S315E631AB301F001F6B80000054A04B40B91F001F6BEE +S315E631AB4021F9FF54A04B40B91F001F6B6100005439 +S315E631AB5020008052A04300B92CE9FF9721008052AC +S315E631AB60C048805269EBFF9728E9FF97A04340B981 +S315E631AB70F30B40F9FD7BC5A8C0035FD6FFC300D111 +S315E631AB80E00F00B9E10B00B9E00B40B90000001265 +S315E631AB90E02700B9A00100D000C00091000040F9DD +S315E631ABA0000C4079E02300B9FF2B00B9C10000144F +S315E631ABB0A00100D000C00091020040F9E10F40B992 +S315E631ABC0E00301AA00F47ED303F07DD30000038BC4 +S315E631ABD00000018B00F47ED34000008B00500091DB +S315E631ABE000004079E103002AE02B40B900741E5398 +S315E631ABF02028C01A000C0012E01F00B9E01F40B948 +S315E631AC001F0400718D000054E00B40B91F0400713A +S315E631AC1089140054E01F40B91F0400718C000054BA +S315E631AC20E00B40B91F040071C8130054FF2F00B979 +S315E631AC308400001421008052E02740B92100004B00 +S315E631AC40A00100D000E00091E103012A007861B865 +S315E631AC50E10F40B9220080524120C11A0000010AB3 +S315E631AC601F001F6B2006005421008052E02740B9B1 +S315E631AC702100004BC001009003003B91E42F80B9DF +S315E631AC80E003012AE22B40B9E50F40B9E10300AA18 +S315E631AC9020F47ED3E10300AA20F07DD32100008B98 +S315E631ACA0E00305AA00F07DD305F07DD30000058BE0 +S315E631ACB02100008BE00302AA00F07DD30000028B6F +S315E631ACC02000008B0000048B647860B8C0010090E8 +S315E631ACD003003B91E52F80B9E02740B9E22B40B935 +S315E631ACE0E60F40B9E10300AA20F47ED3E10300AAD8 +S315E631ACF020F07DD32100008BE00306AA00F07DD358 +S315E631AD0006F07DD30000068B2100008BE00302AA14 +S315E631AD1000F07DD30000028B2000008B0000058B0E +S315E631AD20647820B818000014C001009003003B9106 +S315E631AD30E42F80B9E02740B9E22B40B9E50F40B9B7 +S315E631AD40E10300AA20F47ED3E10300AA20F07DD305 +S315E631AD502100008BE00305AA00F07DD305F07DD313 +S315E631AD600000058B2100008BE00302AA00F07DD3BB +S315E631AD700000028B2000008B0000048BE12340B9F2 +S315E631AD80617820B8C001009003001791E42F80B9AD +S315E631AD90E02740B9E22B40B9E50F40B9E10300AA15 +S315E631ADA020F47ED3E10300AA20F07DD32100008B87 +S315E631ADB0E00305AA00F07DD305F07DD30000058BCF +S315E631ADC02100008BE00302AA00F07DD30000028B5E +S315E631ADD02000008B0000048B7F7820B8C0010090FC +S315E631ADE003002991E42F80B9E02740B9E22B40B937 +S315E631ADF0E50F40B9E10300AA20F47ED3E10300AAC8 +S315E631AE0020F07DD32100008BE00305AA00F07DD347 +S315E631AE1005F07DD30000058B2100008BE00302AA05 +S315E631AE2000F07DD30000028B2000008B0000048BFE +S315E631AE307F7820B8E02F40B900040011E02F00B941 +S315E631AE40E02F40B91F2000716DEFFF54C00100B00D +S315E631AE5000000D91E12B40B9E30F40B9E22740B945 +S315E631AE6063F87FD36200028B42F47ED34100018BD5 +S315E631AE701F7821B8C00100B000000F91E12B40B92F +S315E631AE80E30F40B9E22740B963F87FD36200028B1C +S315E631AE9042F47ED34100018B1F7821B802000014BB +S315E631AEA01F2003D5E02B40B900040011E02B00B991 +S315E631AEB0E02B40B91F0C0071C9E7FF541F2003D5BB +S315E631AEC0FFC30091C0035FD6FD7BBBA9FD030091AD +S315E631AED0A01F00B9A11B00B900F88052A03B00B90A +S315E631AEE0BF4700B9BF4B00B939010014A00100D004 +S315E631AEF000C00091020040F9A11F40B9E00301AA62 +S315E631AF0000F47ED303F07DD30000038B0000018B82 +S315E631AF1000F47ED34000008B00500091000040796A +S315E631AF20E103002AA04B40B900741E532028C01A0B +S315E631AF30000C0012A03700B9A03740B91F040071E2 +S315E631AF408D000054A01B40B91F04007189230054BB +S315E631AF50A03740B91F0400718C000054A01B40B9DC +S315E631AF601F040071C8220054A01B40B9000000122C +S315E631AF70A03300B9A33340B902038052A14B40B99D +S315E631AF80A01F40B932E9FF9702038052A14B40B97F +S315E631AF90A01F40B966E9FF97BF4F00B95D000014BF +S315E631AFA0A04B40B901701D53A04F40B92000000BAC +S315E631AFB0A02F00B9A04F40B91F20007141020054BD +S315E631AFC0A00100D000C00091030040F9A24B40B980 +S315E631AFD0A11F40B9E00301AA00F47ED304F07DD384 +S315E631AFE00000048B0000018B00F47ED36000008BF9 +S315E631AFF00000028B0058019100004039A0FF00396C +S315E631B00011000014A00100B000C00091030040F920 +S315E631B010A22F40B9A11F40B9E00301AA00F47ED3BD +S315E631B02004F07DD30000048B0000018B00F47ED35F +S315E631B0306000008B0000028B006801910000403908 +S315E631B040A0FF0039A0FFC039003C0013EFEBFF97B4 +S315E631B050A0570079400000D000402191A14F80B938 +S315E631B060007861B8E203002AA14B40B9A01F40B986 +S315E631B0702FE9FF97E103002AA057C0792000000B9C +S315E631B080A02700B9400000D000402191A14F80B9F8 +S315E631B090007861B8A32740B9E203002AA14B40B94B +S315E631B0A0A01F40B9EAE8FF97A00100F003003B9103 +S315E631B0B0A44F80B9A03340B9A24B40B9A51F40B9D8 +S315E631B0C0E10300AA20F47ED3E10300AA20F07DD382 +S315E631B0D02100008BE00305AA00F07DD305F07DD390 +S315E631B0E00000058B2100008BE00302AA00F07DD338 +S315E631B0F00000028B2000008B0000048BA12740B9AB +S315E631B100617820B8A04F40B900040011A04F00B9CC +S315E631B110A04F40B91F2000714DF4FF540300805211 +S315E631B12082198052A14B40B9A01F40B9C8E8FF97B2 +S315E631B130A20F8052A14B40B9A01F40B9FCE8FF9758 +S315E631B140A02700B9C001009000000D91A14B40B98E +S315E631B150A31F40B9A23340B963F87FD36200028BAD +S315E631B16042F47ED34100018BA22740B9027821B859 +S315E631B1700000B012A04300B9BF4F00B97C000014FD +S315E631B180A04F40B9E303002A820A8052A14B40B967 +S315E631B190A01F40B9AEE8FF97820F8052A14B40B966 +S315E631B1A0A01F40B9E2E8FF97A02700B9A00100F059 +S315E631B1B003002991A44F80B9A03340B9A24B40B9D7 +S315E631B1C0A51F40B9E10300AA20F47ED3E10300AA24 +S315E631B1D020F07DD32100008BE00305AA00F07DD374 +S315E631B1E005F07DD30000058B2100008BE00302AA32 +S315E631B1F000F07DD30000028B2000008B0000048B2B +S315E631B200A12740B9617820B8620F8052A14B40B987 +S315E631B210A01F40B9C6E8FF97A02700B9A00100F004 +S315E631B22003001791A44F80B9A03340B9A24B40B978 +S315E631B230A51F40B9E10300AA20F47ED3E10300AAB3 +S315E631B24020F07DD32100008BE00305AA00F07DD303 +S315E631B25005F07DD30000058B2100008BE00302AAC1 +S315E631B26000F07DD30000028B2000008B0000048BBA +S315E631B270A12740B9617820B8A00100F003002991F1 +S315E631B280A44F80B9A03340B9A24B40B9A51F40B906 +S315E631B290E10300AA20F47ED3E10300AA20F07DD3B0 +S315E631B2A02100008BE00305AA00F07DD305F07DD3BE +S315E631B2B00000058B2100008BE00302AA00F07DD366 +S315E631B2C00000028B2000008B0000048B637860B8A7 +S315E631B2D0A00100F004001791A54F80B9A03340B91B +S315E631B2E0A24B40B9A61F40B9E10300AA20F47ED3AA +S315E631B2F0E10300AA20F07DD32100008BE00306AA04 +S315E631B30000F07DD306F07DD30000068B2100008B5D +S315E631B310E00302AA00F07DD30000028B2000008B09 +S315E631B3200000058B807860B86000004BA02300B939 +S315E631B330A14340B9A02340B93F00006B6D000054EC +S315E631B340A02340B9A04300B9A12740B9A03B40B9F3 +S315E631B3503F00006B6300005440008052A04700B9BD +S315E631B360A04F40B900040011A04F00B9A04F40B933 +S315E631B3701F2000716DF0FF54A24340B9C001009021 +S315E631B38000000F91A14B40B9A41F40B9A33340B990 +S315E631B39084F87FD38300038B63F47ED36100018B1C +S315E631B3A0027821B82300805282198052A14B40B9E6 +S315E631B3B0A01F40B926E8FF97020000141F2003D5E7 +S315E631B3C0A04B40B900040011A04B00B9A04B40B9DF +S315E631B3D01F0C0071C9D8FF54A04740B9FD7BC5A8FB +S315E631B3E0C0035FD6FD7BBCA9FD030091A01F00B962 +S315E631B3F0A11B00B900008052E3E5FF97A03B00B9F7 +S315E631B4006A000014BF3300B961000014BF3700B9D2 +S315E631B41059000014A33340B902038052A13740B92B +S315E631B420A03B40B90AE8FF97A01F40B900000012D9 +S315E631B430A02F00B9A00100B000E00091000440B9A8 +S315E631B440A13B40B9220080524120C11A0000010ACF +S315E631B4501F001F6B41000054BF2F00B9BF3F00B933 +S315E631B4603F000014A01B40B91F001F6B2003005498 +S315E631B470A00100B003000191A43F40B9A03340B921 +S315E631B480A23740B9A53B40B9E10300AA20F07DD306 +S315E631B490E10300AA20F07DD32100008BE00305AA63 +S315E631B4A000EC7CD305F07DD30000058B2100008BC3 +S315E631B4B0E00302AA00F07DD30000028B2000008B68 +S315E631B4C00000048B607860B8A02B00B91800001430 +S315E631B4D0A00100B003000191A43F40B9A02F40B9C5 +S315E631B4E0A23740B9A53B40B9E10300AA20F07DD3A6 +S315E631B4F0E10300AA20F07DD32100008BE00305AA03 +S315E631B50000EC7CD305F07DD30000058B2100008B62 +S315E631B510E00302AA00F07DD30000028B2000008B07 +S315E631B5200000048B607860B8A02B00B9400000D0EB +S315E631B53000802291A13F40B9007861B8A32B40B98A +S315E631B540E203002AA13740B9A03B40B9C0E7FF97ED +S315E631B550A03F40B900100011A03F00B9A03F40B965 +S315E631B5601F10007109F8FF54A03740B900040011E5 +S315E631B570A03700B9A03740B91F0C0071C9F4FF54A2 +S315E631B580A03340B900040011A03300B9A03340B965 +S315E631B5901F040071C9F3FF54A03B40B90004001102 +S315E631B5A079E5FF97A03B00B9A03B40B91F0C007186 +S315E631B5B0A9F2FF541F2003D5FD7BC4A8C0035FD68D +S315E631B5C0FD7BBBA9FD030091000080526EE5FF9736 +S315E631B5D0A04B00B939000014A04B40B900F47ED334 +S315E631B5E0A14301912000008B000440D11FD00FB951 +S315E631B5F0BF4300B92A000014A00100B000C0009193 +S315E631B600020040F9A14B40B9E00301AA00F47ED32A +S315E631B61003F07DD30000038B0000018B00F47ED36B +S315E631B6204000008B0050009100004079E103002A8A +S315E631B630A04340B900741E532028C01A000C0012EC +S315E631B640A04F00B9A04F40B91F0400712D02005436 +S315E631B650A04B40B900F47ED3A14301912000008B83 +S315E631B660000440D100D04FB9A14340B922008052FF +S315E631B6704120C11A0000012AA14B40B921F47ED3FB +S315E631B680A24301914100018B210440D120D00FB96B +S315E631B690A04340B900040011A04300B9A04340B924 +S315E631B6A01F0C0071A9FAFF54A04B40B900040011F2 +S315E631B6B035E5FF97A04B00B9A04B40B91F0C007199 +S315E631B6C0C9F8FF54A00100B000200091010040B94D +S315E631B6D000E089523F00006B21010054A00100B021 +S315E631B6E000300091000040B91F0400718800005413 +S315E631B6F001008052E04B805284E8FF97BF3B00B9A8 +S315E631B700BF4700B919000014A14740B9000380527A +S315E631B71089E8FF97A00100B000200091010040B909 +S315E631B72000E089523F00006B41010054A00100B0B0 +S315E631B73000300091000040B91F040071A9000054A1 +S315E631B74021008052C00A80527BE8FF97040000143C +S315E631B75021008052E00A805277E8FF97A04740B948 +S315E631B76000040011A04700B9A04740B91F04007193 +S315E631B770C9FCFF5498E9FF97BF3700B9BF3F00B917 +S315E631B780E1000014A00100B000200091010040B9AB +S315E631B79000E089523F00006B41080054A00100B039 +S315E631B7A000300091000040B91F040071A80700542B +S315E631B7B000008052F4E4FF97A04B00B9360000143E +S315E631B7C0A04B40B901641A5380C0805220CFBC7277 +S315E631B7D02000000BE003002A0AE3FF97A03300B905 +S315E631B7E0A03340B9005C0812A03300B9A03F40B996 +S315E631B7F01F04007149010054A04B40B900F47ED3D1 +S315E631B800A14301912000008B000440D100D04FB90D +S315E631B810000C0052A04F00B908000014A04B40B905 +S315E631B82000F47ED3A14301912000008B000440D180 +S315E631B83000D04FB9A04F00B9A04F40B9003C1053E4 +S315E631B840E103002AA03340B90000012AA03300B94A +S315E631B850A04B40B901641A5380C0805220CFBC72E6 +S315E631B8602000000BE003002AA13340B9DCE2FF9762 +S315E631B870A04F40B9E203002A81688052A04B40B915 +S315E631B88058E7FF97A04B40B900040011BEE4FF9795 +S315E631B890A04B00B9A04B40B91F0C007129F9FF54F2 +S315E631B8A0A00100B000200091010040B900E08952C4 +S315E631B8B03F00006BC1000054A00100B0003000919A +S315E631B8C0000040B91F04007189010054A00100B09F +S315E631B8D000200091010040B900408A523F00006BDA +S315E631B8E021010054A00100B000300091000040B9BA +S315E631B8F01F001F6B8100005401008052A03F40B902 +S315E631B900B9FEFF97000080529FE4FF97A04B00B93E +S315E631B910130000146000009000E00D91A13F40B99C +S315E631B92021100091007861B8E103002AA04B40B9B5 +S315E631B93014E8FF97A03300B9E06D8052A23340B9DF +S315E631B940E103002AA04B40B926E7FF97A04B40B961 +S315E631B950000400118CE4FF97A04B00B9A04B40B927 +S315E631B9601F0C007189FDFF54C26A8052E16A80522A +S315E631B970A03F40B9F1FBFF97A03B00B9A03B40B9E8 +S315E631B9801F001F6B810C0054A03F40B91F001F6B8F +S315E631B99001030054000080527BE4FF97A04B00B9C7 +S315E631B9A010000014E06D8052E103002AA04B40B945 +S315E631B9B0F4E7FF97E103002AA04B40B900F47ED3C2 +S315E631B9C0A24301914000008B000440D101C00FB97A +S315E631B9D0A04B40B9000400116BE4FF97A04B00B9C8 +S315E631B9E0A04B40B91F0C0071E9FDFF541600001457 +S315E631B9F00000805264E4FF97A04B00B90F000014B3 +S315E631BA00E16D8052A04B40B900F47ED3A243019159 +S315E631BA104000008B000440D100C04FB9E203002A52 +S315E631BA20A04B40B9EFE6FF97A04B40B900040011B1 +S315E631BA3055E4FF97A04B00B9A04B40B91F0C0071F6 +S315E631BA4009FEFF54000080524FE4FF97A04B00B940 +S315E631BA5027000014A03F40B901000012A00100B052 +S315E631BA6000E00091E103012A007861B8A14B40B9C3 +S315E631BA70220080524120C11A0000010A1F001F6BC5 +S315E631BA80A1000054A13F40B9A04B40B93CFCFF9719 +S315E631BA9013000014A13F40B9A04B40B90BFDFF9707 +S315E631BAA0A03B00B9A03B40B91F001F6B60010054B3 +S315E631BAB0A03F40B901741E53A04B40B92000000B9C +S315E631BAC0210080522020C01AE103002AA03740B96E +S315E631BAD00000012AA03700B9BFE8FF97A04B40B96D +S315E631BAE00004001128E4FF97A04B00B9A04B40B9FA +S315E631BAF01F0C007109FBFF54A03F40B90004001149 +S315E631BB00A03F00B9A03F40B91F0C0071C9E3FF540D +S315E631BB10020000141F2003D521008052E04B8052EB +S315E631BB207AE7FF970000805217E4FF97A04B00B9FA +S315E631BB301C000014A04B40B901641A5380C08052F0 +S315E631BB4020CFBC722000000BE003002A2DE2FF97DE +S315E631BB50A03300B9A03340B9005C0812A03300B96E +S315E631BB60A04B40B901641A5380C0805220CFBC72D3 +S315E631BB702000000BE003002AA13340B918E2FF9713 +S315E631BB800200805281688052A04B40B995E6FF9714 +S315E631BB90A04B40B900040011FBE3FF97A04B00B977 +S315E631BBA0A04B40B91F0C007169FCFF54A13740B96F +S315E631BBB0A03B40B92000002AFD7BC5A8C0035FD66D +S315E631BBC0FD7BB8A9FD030091F30B00F90002805223 +S315E631BBD0A07300B901078052606880524BE7FF9740 +S315E631BBE0210680524068805248E7FF97BF7F00B909 +S315E631BBF021008052A067805244E7FF9721008052A8 +S315E631BC00006A805241E7FF9781018052806A80520D +S315E631BC103EE7FF97FDE4FF976AFEFF97A06F00B90F +S315E631BC2000008052D8E3FF97A07B00B920000014CC +S315E631BC30BF7700B9170000146000009000E00D915F +S315E631BC40A17740B921100091007861B8E103002A65 +S315E631BC50A07B40B94BE7FF97E203002AA07740B9CC +S315E631BC60A17B40B921F47ED32000008B00F47ED34C +S315E631BC70A10302912000008B000440D102A80FB93E +S315E631BC80E2E4FF97A07740B900040011A07700B946 +S315E631BC90A07740B91F0C007109FDFF54A07B40B96E +S315E631BCA000040011B8E3FF97A07B00B9A07B40B949 +S315E631BCB01F0C0071E9FBFF5481008052806A805285 +S315E631BCC012E7FF97E60800943EFEFF97A06F00B9AC +S315E631BCD000008052ACE3FF97A07B00B93B0000142D +S315E631BCE0BF7700B932000014A07740B9A17B40B9DD +S315E631BCF021F47ED32000008B00F47ED3A10302919A +S315E631BD002000008B000440D113A84FB960000090A3 +S315E631BD1000E00D91A17740B921100091007861B824 +S315E631BD20E103002AA07B40B916E7FF976002000BD4 +S315E631BD30007C0153A17740B9A27B40B942F47ED368 +S315E631BD404100018B21F47ED3A20302914100018B9E +S315E631BD50210440D120A80FB96000009000E00D9192 +S315E631BD60A17740B921100091037861B8A07740B93F +S315E631BD70A17B40B921F47ED32000008B00F47ED33B +S315E631BD80A10302912000008B000440D100A84FB9EF +S315E631BD90E203002AE103032AA07B40B911E6FF97C5 +S315E631BDA0A07740B900040011A07700B9A07740B971 +S315E631BDB01F0C0071A9F9FF54A07B40B900040011AC +S315E631BDC071E3FF97A07B00B9A07B40B91F0C0071E8 +S315E631BDD089F8FF5401008052006A8052CBE6FF971C +S315E631BDE001008052806A8052C8E6FF970100805290 +S315E631BDF0A0698052C5E6FF9701008052E06980521C +S315E631BE00C2E6FF9701008052C0698052BFE6FF97CE +S315E631BE10350A0094EBFDFF97A06F00B90100805219 +S315E631BE20A0678052B9E6FF97A06F40B91F001F6B36 +S315E631BE3000010054A07F40B900040011A07F00B98B +S315E631BE40A17F40B9A07340B93F00006B23EDFF54A3 +S315E631BE50A00100B000200091010040B900E089520E +S315E631BE603F00006BC1000054A00100B000300091E4 +S315E631BE70000040B91F04007189010054A00100B0E9 +S315E631BE8000200091010040B900408A523F00006B24 +S315E631BE9021010054A00100B000300091000040B904 +S315E631BEA01F001F6B81000054210080520000805232 +S315E631BEB04DFDFF97A17F40B9A07340B93F00006BB6 +S315E631BEC0E0379F1A001C0053F30B40F9FD7BC8A8F7 +S315E631BED0C0035FD6FFC300D1E00F00B9E10B00B96D +S315E631BEE0E00B40B900000012E02700B9A00100B02E +S315E631BEF000C00091000040F900104079E02300B916 +S315E631BF00FF2B00B96B010014A00100B000C000910F +S315E631BF10020040F9E10F40B9E00301AA00F47ED30D +S315E631BF2003F07DD30000038B0000018B00F47ED352 +S315E631BF304000008B0050009100004079E103002A71 +S315E631BF40E02B40B900741E532028C01A000C0012AB +S315E631BF50E01F00B9E01F40B91F0400718D0000549F +S315E631BF60E00B40B91F040071C9290054E01F40B9FE +S315E631BF701F0400718C000054E00B40B91F040071B8 +S315E631BF8008290054FF2F00B92E01001421008052F2 +S315E631BF90E02740B92100004BA00100B000E0009156 +S315E631BFA0E103012A007861B8E10F40B922008052F7 +S315E631BFB04120C11A0000010A1F001F6B800C005494 +S315E631BFC021008052E02740B92100004BA00100B0A4 +S315E631BFD003000191E42F80B9E003012AE22B40B94F +S315E631BFE0E50F40B9E10300AA20F07DD3E10300AACB +S315E631BFF020F07DD32100008BE00305AA00EC7CD34B +S315E631C00005F07DD30000058B2100008BE00302AA03 +S315E631C01000F07DD30000028B2000008B0000048BFC +S315E631C020647860B8A001009003000191E52F80B9EC +S315E631C030E02740B9E22B40B9E60F40B9E10300AA61 +S315E631C04020F07DD3E10300AA20F07DD32100008BD9 +S315E631C050E00306AA00EC7CD306F07DD30000068B1E +S315E631C0602100008BE00302AA00F07DD30000028BAB +S315E631C0702000008B0000058B647820B8E02B40B9B0 +S315E631C0800610001121008052E02740B92200004B0C +S315E631C090E02B40B901100011A00100900300019197 +S315E631C0A0E42F80B9E003022AE203012AE50F40B91B +S315E631C0B0E10300AA20F07DD3E10300AA20F07DD387 +S315E631C0C02100008BE00305AA00EC7CD305F07DD395 +S315E631C0D00000058B2100008BE00302AA00F07DD338 +S315E631C0E00000028B2000008B0000048B647860B878 +S315E631C0F0A001009003000191E52F80B9E02740B910 +S315E631C100E203062AE60F40B9E10300AA20F07DD321 +S315E631C110E10300AA20F07DD32100008BE00306AAD5 +S315E631C12000EC7CD306F07DD30000068B2100008B34 +S315E631C130E00302AA00F07DD30000028B2000008BDB +S315E631C1400000058B647820B831000014A001009018 +S315E631C15003000191E42F80B9E02740B9E22B40B9DB +S315E631C160E50F40B9E10300AA20F07DD3E10300AA49 +S315E631C17020F07DD32100008BE00305AA00EC7CD3C9 +S315E631C18005F07DD30000058B2100008BE00302AA82 +S315E631C19000F07DD30000028B2000008B0000048B7B +S315E631C1A0E12340B9617820B8E02B40B9011000119E +S315E631C1B0A001009003000191E42F80B9E02740B950 +S315E631C1C0E203012AE50F40B9E10300AA20F07DD367 +S315E631C1D0E10300AA20F07DD32100008BE00305AA16 +S315E631C1E000EC7CD305F07DD30000058B2100008B76 +S315E631C1F0E00302AA00F07DD30000028B2000008B1B +S315E631C2000000048BE12340B9617820B8A0010090A3 +S315E631C21003002591E42F80B9E02740B9E22B40B9F6 +S315E631C220E50F40B9E10300AA20F07DD3E10300AA88 +S315E631C23020F07DD32100008BE00305AA00EC7CD308 +S315E631C24005F07DD30000058B2100008BE00302AAC1 +S315E631C25000F07DD30000028B2000008B0000048BBA +S315E631C2607F7820B8E02B40B901100011A00100908B +S315E631C27003002591E42F80B9E02740B9E203012A8C +S315E631C280E50F40B9E10300AA20F07DD3E10300AA28 +S315E631C29020F07DD32100008BE00305AA00EC7CD3A8 +S315E631C2A005F07DD30000058B2100008BE00302AA61 +S315E631C2B000F07DD30000028B2000008B0000048B5A +S315E631C2C07F7820B8A00100B003000991E42F80B948 +S315E631C2D0E02740B9E22B40B9E50F40B9E10300AAC0 +S315E631C2E020F07DD3E10300AA20F07DD32100008B37 +S315E631C2F0E00305AA00EC7CD305F07DD30000058B7F +S315E631C3002100008BE00302AA00F07DD30000028B08 +S315E631C3102000008B0000048B7F7820B8E02B40B9F3 +S315E631C32001100011A00100B003000991E42F80B994 +S315E631C330E02740B9E203012AE50F40B9E10300AA55 +S315E631C34020F07DD3E10300AA20F07DD32100008BD6 +S315E631C350E00305AA00EC7CD305F07DD30000058B1E +S315E631C3602100008BE00302AA00F07DD30000028BA8 +S315E631C3702000008B0000048B7F7820B8A00100B046 +S315E631C38003002D91E42F80B9E02740B9E22B40B97D +S315E631C390E50F40B9E10300AA20F07DD3E10300AA17 +S315E631C3A020F07DD32100008BE00305AA00EC7CD397 +S315E631C3B005F07DD30000058B2100008BE00302AA50 +S315E631C3C000F07DD30000028B2000008B0000048B49 +S315E631C3D07F7820B8E02B40B901100011A00100B0FA +S315E631C3E003002D91E42F80B9E02740B9E203012A13 +S315E631C3F0E50F40B9E10300AA20F07DD3E10300AAB7 +S315E631C40020F07DD32100008BE00305AA00EC7CD336 +S315E631C41005F07DD30000058B2100008BE00302AAEF +S315E631C42000F07DD30000028B2000008B0000048BE8 +S315E631C4307F7820B8E02F40B900040011E02F00B92B +S315E631C440E02F40B91F2000712DDAFF54A00100D04C +S315E631C45000001391E12B40B9E30F40B9E22740B929 +S315E631C46063F87FD36200028B42F07DD34100018BC4 +S315E631C4701F7821B8A00100D000001191E12B40B917 +S315E631C480E30F40B9E22740B963F87FD36200028B06 +S315E631C49042F47ED34100018B1F7821B802000014A5 +S315E631C4A01F2003D5E02B40B900040011E02B00B97B +S315E631C4B0E02B40B91F0C007189D2FF541F2003D5FA +S315E631C4C0FFC30091C0035FD6FD7BBBA9FD03009197 +S315E631C4D0A01F00B9A11B00B9BF4300B9BF4700B9D8 +S315E631C4E0B7010014A001009000C00091020040F9A6 +S315E631C4F0A11F40B9E00301AA00F47ED303F07DD350 +S315E631C5000000038B0000018B00F47ED34000008BE4 +S315E631C5100050009100004079E103002AA04740B976 +S315E631C52000741E532028C01A000C0012A04B00B925 +S315E631C530A04B40B91F0400718D000054A01B40B9D1 +S315E631C5401F04007149330054A04B40B91F040071F2 +S315E631C5508C000054A01B40B91F0400718832005488 +S315E631C560A01B40B900000012A03300B9A33340B98D +S315E631C57002038052A14740B9A01F40B9B4E3FF9701 +S315E631C58015E6FF9702038052A14740B9A01F40B98D +S315E631C590E7E3FF9710E6FF97BF4F00B98B0000142C +S315E631C5A0A04740B901701D53A04F40B92000000B9A +S315E631C5B0A02F00B9A04F40B91F20007141020054A7 +S315E631C5C0A001009000C00091030040F9A24740B9AE +S315E631C5D0A11F40B9E00301AA00F47ED304F07DD36E +S315E631C5E00000048B0000018B00F47ED36000008BE3 +S315E631C5F00000028B00E8019100004039A0FF0039C6 +S315E631C60011000014A001009000C00091030040F92A +S315E631C610A22F40B9A11F40B9E00301AA00F47ED3A7 +S315E631C62004F07DD30000048B0000018B00F47ED349 +S315E631C6306000008B0000028B00F801910000403962 +S315E631C640A0FF0039A0FFC039003C00136FE6FF9723 +S315E631C650A0570079400000B000802291A14F80B901 +S315E631C660007861B8E203002AA14740B9A01F40B974 +S315E631C670AFE3FF97E103002AA057C0792000000B0C +S315E631C680A02700B9400000B000802291A14F80B9C1 +S315E631C690007861B8A32740B9E203002AA14740B939 +S315E631C6A0A01F40B96AE3FF97A0010090030001910C +S315E631C6B0A44F80B9A03340B9A24740B9A51F40B9C6 +S315E631C6C0E10300AA20F07DD3E10300AA20F07DD371 +S315E631C6D02100008BE00305AA00EC7CD305F07DD37F +S315E631C6E00000058B2100008BE00302AA00F07DD322 +S315E631C6F00000028B2000008B0000048BA12740B995 +S315E631C700617820B8400000B000E02191A14F80B9B0 +S315E631C710007861B8E203002AA14740B9A01F40B9C3 +S315E631C72083E3FF97E103002AA057C0792000000B87 +S315E631C730A02700B9400000B000E02191A14F80B9B1 +S315E631C740007861B8A32740B9E203002AA14740B988 +S315E631C750A01F40B93EE3FF97A04740B9011000114B +S315E631C760A001009003000191A44F80B9A03340B9EE +S315E631C770E203012AA51F40B9E10300AA20F07DD3E1 +S315E631C780E10300AA20F07DD32100008BE00305AA60 +S315E631C79000EC7CD305F07DD30000058B2100008BC0 +S315E631C7A0E00302AA00F07DD30000028B2000008B65 +S315E631C7B00000048BA12740B9617820B8A04F40B973 +S315E631C7C000040011A04F00B9A04F40B91F200071F7 +S315E631C7D08DEEFF540000B012A03B00B9BF4F00B951 +S315E631C7E0DF000014420F8052A14740B9A01F40B97D +S315E631C7F04FE3FF97A02700B9A00100D000001391BF +S315E631C800A14740B9A31F40B9A23340B963F87FD3F4 +S315E631C8106200028B42F07DD34100018BA22740B9FB +S315E631C820027821B8A04740B901100011A00100D025 +S315E631C83000001391E103012AA31F40B9A23340B99F +S315E631C84063F87FD36200028B42F07DD34100018BE0 +S315E631C850A22740B9027821B8BF4B00B9BA00001415 +S315E631C860A04F40B91F200071C1000054A04B40B91A +S315E631C8700008001100701D53A03700B906000014F8 +S315E631C880A04B40B901701D53A04F40B92000000BB3 +S315E631C890A03700B9A33740B9A2098052A14740B9BA +S315E631C8A0A01F40B9EAE2FF97E20E8052A14740B9AE +S315E631C8B0A01F40B91EE3FF97A02700B9A04B40B9A8 +S315E631C8C000741E53E103002AA04740B92100000B4C +S315E631C8D0A001009003002591A44F80B9A03340B959 +S315E631C8E0E203012AA51F40B9E10300AA20F07DD370 +S315E631C8F0E10300AA20F07DD32100008BE00305AAEF +S315E631C90000EC7CD305F07DD30000058B2100008B4E +S315E631C910E00302AA00F07DD30000028B2000008BF3 +S315E631C9200000048BA12740B9617820B8020F805206 +S315E631C930A14740B9A01F40B9FDE2FF97A02700B94C +S315E631C940A04B40B900741E53E103002AA04740B913 +S315E631C9502100000BA00100B003000991A44F80B974 +S315E631C960A03340B9E203012AA51F40B9E10300AA83 +S315E631C97020F07DD3E10300AA20F07DD32100008BA0 +S315E631C980E00305AA00EC7CD305F07DD30000058BE8 +S315E631C9902100008BE00302AA00F07DD30000028B72 +S315E631C9A02000008B0000048BA12740B9617820B8BE +S315E631C9B0220F8052A14740B9A01F40B9DCE2FF976A +S315E631C9C0A02700B9A04B40B900741E53E103002AF3 +S315E631C9D0A04740B92100000BA00100B003002D911C +S315E631C9E0A44F80B9A03340B9E203012AA51F40B965 +S315E631C9F0E10300AA20F07DD3E10300AA20F07DD33E +S315E631CA002100008BE00305AA00EC7CD305F07DD34B +S315E631CA100000058B2100008BE00302AA00F07DD3EE +S315E631CA200000028B2000008B0000048BA12740B961 +S315E631CA30617820B8A04B40B900741E53E103002A51 +S315E631CA40A04740B92100000BA00100B003000991CF +S315E631CA50A44F80B9A03340B9E203012AA51F40B9F4 +S315E631CA60E10300AA20F07DD3E10300AA20F07DD3CD +S315E631CA702100008BE00305AA00EC7CD305F07DD3DB +S315E631CA800000058B2100008BE00302AA00F07DD37E +S315E631CA900000028B2000008B0000048B637860B8BF +S315E631CAA0A04B40B900741E53E103002AA04740B9B2 +S315E631CAB02100000BA001009004002591A54F80B915 +S315E631CAC0A03340B9E203012AA61F40B9E10300AA21 +S315E631CAD020F07DD3E10300AA20F07DD32100008B3F +S315E631CAE0E00306AA00EC7CD306F07DD30000068B84 +S315E631CAF02100008BE00302AA00F07DD30000028B11 +S315E631CB002000008B0000058B807860B86000004B12 +S315E631CB10A02300B9A04F40B91F200071E0000054B0 +S315E631CB20A13B40B9A02340B93F00006B6D000054EC +S315E631CB30A02340B9A03B00B9A04B40B9000400118F +S315E631CB40A04B00B9A04B40B91F040071ADE8FF54C4 +S315E631CB50A04F40B900040011A04F00B9A04F40B92B +S315E631CB601F2000710DE4FF54A23B40B9A00100D06D +S315E631CB7000001191A14740B9A41F40B9A33340B98A +S315E631CB8084F87FD38300038B63F47ED36100018B14 +S315E631CB90027821B8A03B40B91F001F6BAC000054A8 +S315E631CBA040008052A04300B9020000141F2003D58D +S315E631CBB0A04740B900040011A04700B9A04740B9E3 +S315E631CBC01F0C007109C9FF54A04340B9FD7BC5A8C6 +S315E631CBD0C0035FD6FD7BBEA9FD030091BF1700B941 +S315E631CBE0BF1B00B93000001462538052A153805204 +S315E631CBF0A01B40B951F7FF97A01700B9A01740B966 +S315E631CC001F001F6B8105005400008052DEDFFF975F +S315E631CC10A01F00B91E000014A01B40B90100001286 +S315E631CC20A001009000E00091E103012A007861B8A5 +S315E631CC30A11F40B9220080524120C11A0000010AE3 +S315E631CC401F001F6BC1000054A11B40B9A01F40B99C +S315E631CC50A1FCFF9760E4FF9709000014A11B40B9D8 +S315E631CC60A01F40B919FEFF97A01700B95AE4FF97FE +S315E631CC70A01740B91F001F6B21020054A01F40B90F +S315E631CC8000040011C0DFFF97A01F00B9A01F40B90D +S315E631CC901F0C007129FCFF54A01B40B9000400119A +S315E631CCA0A01B00B9A01B40B91F0C0071E9F9FF546E +S315E631CCB0040000141F2003D5020000141F2003D5FB +S315E631CCC0A01740B9FD7BC2A8C0035FD6FD7BBEA9DE +S315E631CCD0FD03009120008052A01B00B9A00100F0AF +S315E631CCE00040129101028052D5E3FF9700001E32D1 +S315E631CCF0E103002A000280520FE3FF97A00100F01C +S315E631CD000040129141028052CDE3FF9700001E3278 +S315E631CD10E103002A4002805207E3FF97A00100F0C3 +S315E631CD200040129121028052C5E3FF97006C08124A +S315E631CD30E103002A20028052FFE2FF97A00100F0CC +S315E631CD400040129161028052BDE3FF97006C0812F2 +S315E631CD50E103002A60028052F7E2FF97BF1F00B96E +S315E631CD609DFFFF97A01700B91BE4FF97A01740B9BF +S315E631CD701F001F6B00010054A01F40B900040011CB +S315E631CD80A01F00B9A11F40B9A01B40B93F00006BF7 +S315E631CD9083FEFF54A00100F0004012910102805259 +S315E631CDA0A7E3FF97E103002A00028052E2E2FF970A +S315E631CDB0A00100F00040129141028052A0E3FF97B4 +S315E631CDC0E103002A40028052DBE2FF97A00100F040 +S315E631CDD0004012912102805299E3FF97E103002A3E +S315E631CDE020028052D4E2FF97A00100F00040129172 +S315E631CDF06102805292E3FF97E103002A6002805294 +S315E631CE00CDE2FF97A11F40B9A01B40B93F00006BA9 +S315E631CE10E0379F1A001C0053FD7BC2A8C0035FD6DC +S315E631CE20FF8300D1E00700F9E10700B9E007805258 +S315E631CE30E01B00B9E00740B91F001F6B61030054E0 +S315E631CE40E00740F900000012E01700B920008052F1 +S315E631CE50E01F00B90F000014E01F40B9E10740F9C1 +S315E631CE602024C09A00000012E01300B9E11340B95C +S315E631CE70E01740B93F00006B60000054E01F40B94F +S315E631CE8025000014E01F40B900040011E01F00B987 +S315E631CE90E11F40B9E01B40B93F00006BE9FDFF54A5 +S315E631CEA0E01B40B91C000014E00740B9E10740F940 +S315E631CEB02024C09A00000012E01700B9E00740B915 +S315E631CEC000040051E01F00B90F000014E01F40B91D +S315E631CED0E10740F92024C09A00000012E01300B9B8 +S315E631CEE0E11340B9E01740B93F00006B60000054EA +S315E631CEF0E01F40B908000014E01F40B900040051B4 +S315E631CF00E01F00B9E01F40B91F001F6B0AFEFF5450 +S315E631CF1000008052FF830091C0035FD6FF8300D1C4 +S315E631CF20E00F00B900088052E01B00B9A00100907D +S315E631CF3000200091010040B900E089523F00006BC4 +S315E631CF4081050054A001009000300091000040B9FF +S315E631CF501F040071E8040054E00F40B91F001F6B4F +S315E631CF60C1000054E01B40B90004005100001A32FA +S315E631CF70E01F00B92E000014E00F40B91F800071A2 +S315E631CF80E8010054E10F40B9000080520000014B40 +S315E631CF9000781F53E103002AE01B40B90000014B3C +S315E631CFA00004015101641A53E01B40B900040051F3 +S315E631CFB02000002AE01F00B91D000014E01B40B92D +S315E631CFC00004005101641A53E20F40B9E0671B329F +S315E631CFD04000000B00781F53E21B40B94000004B7E +S315E631CFE0000400512000002AE01F00B910000014A9 +S315E631CFF0E00F40B91F001F6BC1000054E01B40B97A +S315E631D0000004005100001A32E01F00B9080000148E +S315E631D010E00F40B901641A53E21B40B9E00F40B95B +S315E631D0204000004B2000002AE01F00B9E01F40B95E +S315E631D030FF830091C0035FD6FFC317D1FD7BBFA93E +S315E631D040FD03009100088052A0EF05B940008052F9 +S315E631D050A0EB05B9C0108052E5E0FF97A0E705B928 +S315E631D06021008052001A805233E2FF972100805226 +S315E631D0708010805230E2FF9700008052C2DEFF9781 +S315E631D080A0F705B92C000014BFF305B92300001447 +S315E631D090BFFF05B91B000014A4FF45B9A2F745B990 +S315E631D0A0A3F345B9E10302AA20F47ED3E10300AA4C +S315E631D0B020F47ED3000001CB000002CB00F47ED310 +S315E631D0C0E20303AA41F47ED3E20301AA41F47ED315 +S315E631D0D0210002CB210003CB0000018B0000048B3B +S315E631D0E000F07DD3A10318912000008B000440D1D6 +S315E631D0F01F0805F9A0FF45B900040011A0FF05B9DF +S315E631D100A0FF45B91F28007189FCFF54A0F345B944 +S315E631D11000040011A0F305B9A0F345B91F0C00715F +S315E631D12089FBFF54A0F745B90004001196DEFF9757 +S315E631D130A0F705B9A0F745B91F0C007169FAFF5496 +S315E631D140BFFB05B9BD000014A1FB45B9A0EB45B956 +S315E631D150207C001B72FFFF97A0E305B9A0E345B932 +S315E631D160003C1053A1E345B92000002AA0E305B9F6 +S315E631D170BFFF05B914000014BFF305B90C0000145E +S315E631D180A0F345B901601953A0E745B92100000B73 +S315E631D190A0FF45B92000000BA1E345B941E0FF9771 +S315E631D1A0A0F345B900040011A0F305B9A0F345B9DA +S315E631D1B01F0C007169FEFF54A0FF45B9000400114A +S315E631D1C0A0FF05B9A0FF45B91F14007169FDFF54EB +S315E631D1D08EDFFF97A0431691E10300AA2012805213 +S315E631D1E010E2FF970000805267DEFF97A0F705B998 +S315E631D1F08C000014BFF305B983000014A0F345B9DA +S315E631D200A1F745B921F47ED32000008B00F47ED315 +S315E631D210A10318912000008B000440D100904FB94C +S315E631D220A0E305B9BFFF05B971000014A0FF45B902 +S315E631D230210080522120C01AA0E345B92000000A18 +S315E631D2401F001F6B80060054A4FF45B9A2F745B906 +S315E631D250A3F345B9E10302AA20F47ED3E10300AA9A +S315E631D26020F47ED3000001CB000002CB00F47ED35E +S315E631D270E20303AA41F47ED3E20301AA41F47ED363 +S315E631D280210002CB210003CB0000018B0000048B89 +S315E631D29000F07DD3A10318912000008B000440D124 +S315E631D2A0010845F9A0FB45B9220080D24020C09A53 +S315E631D2B0240000AAA5FF45B9A2F745B9A3F345B9B6 +S315E631D2C0E10302AA20F47ED3E10300AA20F47ED359 +S315E631D2D0000001CB000002CB00F47ED3E20303AAC1 +S315E631D2E041F47ED3E20301AA41F47ED3210002CB97 +S315E631D2F0210003CB0000018B0000058B00F07DD3C6 +S315E631D300A10318912000008B000440D1040805F9E9 +S315E631D31034000014A4FF45B9A2F745B9A3F345B9DC +S315E631D320E10302AA20F47ED3E10300AA20F47ED3F8 +S315E631D330000001CB000002CB00F47ED3E20303AA60 +S315E631D34041F47ED3E20301AA41F47ED3210002CB36 +S315E631D350210003CB0000018B0000048B00F07DD366 +S315E631D360A10318912000008B000440D1010845F94C +S315E631D370A0FB45B9220080D24020C09AE00320AA1C +S315E631D3802400008AA5FF45B9A2F745B9A3F345B905 +S315E631D390E10302AA20F47ED3E10300AA20F47ED388 +S315E631D3A0000001CB000002CB00F47ED3E20303AAF0 +S315E631D3B041F47ED3E20301AA41F47ED3210002CBC6 +S315E631D3C0210003CB0000018B0000058B00F07DD3F5 +S315E631D3D0A10318912000008B000440D1040805F919 +S315E631D3E0A0FF45B900040011A0FF05B9A0FF45B974 +S315E631D3F01F280071C9F1FF54A0F345B900040011A5 +S315E631D400A0F305B9A0F345B91F0C007189EFFF54B6 +S315E631D410A0F745B900040011DBDDFF97A0F705B9A2 +S315E631D420A0F745B91F0C007169EEFF54A0FB45B96B +S315E631D43000040011A0FB05B9A1EF45B9A0EB45B94A +S315E631D4402108C01AA0FB45B93F00006BE8E7FF5457 +S315E631D45000008052CCDDFF97A0F705B94C000014E9 +S315E631D460BFF305B943000014BFFF05B93B0000140D +S315E631D470A4FF45B9A2F745B9A3F345B9E10302AA33 +S315E631D48020F47ED3E10300AA20F47ED3000001CB5B +S315E631D490000002CB00F47ED3E20303AA41F47ED345 +S315E631D4A0E20301AA41F47ED3210002CB210003CB6C +S315E631D4B00000018B0000048B00F07DD3A1031891A7 +S315E631D4C02000008B000440D1000845F9A0EF02F9AF +S315E631D4D001008052A0EF42F952FEFF97A0D705B977 +S315E631D4E0A1EF45B9A0EB45B92008C01A00040051B1 +S315E631D4F0E103002AA0EF42F94AFEFF97A0D305B928 +S315E631D500A1D745B9A0D345B92000000B007C01135C +S315E631D510A0E305B9A1E345B9A0EB45B9207C001BEB +S315E631D5207FFEFF97A0E305B9400000900080209189 +S315E631D530A1FF45B9007861B8A3E345B9E203002A0C +S315E631D540A1F345B9A0F745B9C1DFFF97A0FF45B9C4 +S315E631D55000040011A0FF05B9A0FF45B91F280071E7 +S315E631D56089F8FF54A0F345B900040011A0F305B9D3 +S315E631D570A0F345B91F0C007189F7FF54A0F745B9F9 +S315E631D5800004001180DDFF97A0F705B9A0F745B98C +S315E631D5901F0C007169F6FF540100805280108052EB +S315E631D5A0E5E0FF9701008052001A8052E2E0FF97EC +S315E631D5B000008052FD7BC1A8FFC31791C0035FD639 +S315E631D5C0FD7BB9A9FD03009121008052001A8052F4 +S315E631D5D0D9E0FF97E011805201008052D6E0FF97FD +S315E631D5E00100805280108052D3E0FF97E1018052EC +S315E631D5F0A0108052D0E0FF97BF6700B94B00001408 +S315E631D600A06740B9001C00121F001F6B8100005451 +S315E631D6102100805260108052C7E0FF97E0118052B8 +S315E631D620A1630091FFE0FF9720008052A06300B925 +S315E631D6300000805254DDFF97A06F00B93200001426 +S315E631D640BF6B00B929000014A06B40B9A16F40B990 +S315E631D65021F47ED32000008B00F47ED3A1C3019161 +S315E631D6602000008B000440D100A84FB9A05F00B975 +S315E631D670A05F40B901140012A05F40B9007C0653A1 +S315E631D680001400122000000BA05F00B9800100F003 +S315E631D69000200091010040B900E089523F00006B5D +S315E631D6A061010054800100F000300091000040B97C +S315E631D6B01F040071C9000054A05F40B91FF800711C +S315E631D6C0E0000054BF6300B905000014A05F40B91D +S315E631D6D01F00017140000054BF6300B9A06B40B929 +S315E631D6E000040011A06B00B9A06B40B91F0C0071A4 +S315E631D6F0C9FAFF54A06F40B90004001122DDFF9745 +S315E631D700A06F00B9A06F40B91F0C0071A9F9FF549B +S315E631D710A06340B91F001F6B01010054A06740B9F1 +S315E631D72000040011A06700B9A06740B91FFC3F713C +S315E631D73089F6FF54020000141F2003D501008052FA +S315E631D740001A80527CE0FF97A06340B91F001F6B39 +S315E631D750E0179F1A001C0053FD7BC7A8C0035FD6AE +S315E631D760FD7BBCA9FD0300910000805206DDFF97E3 +S315E631D770A03F00B956000014BF3700B9BF3B00B928 +S315E631D780270000140300805202038052A13B40B9C0 +S315E631D790A03F40B92EDFFF9742178052A13B40B9F1 +S315E631D7A0A03F40B962DFFF97A03300B962178052D6 +S315E631D7B0A13B40B9A03F40B95DDFFF97A02F00B945 +S315E631D7C0A02F40B901781F53A03340B9007C0853E6 +S315E631D7D02000000BA02F00B9A03B40B900F47ED360 +S315E631D7E0A10301912000008B000440D1E10300AA98 +S315E631D7F0A02F40B920D80FB9A13740B9A02F40B9EB +S315E631D8003F00006B62000054A02F40B9A03700B943 +S315E631D810A03B40B900040011A03B00B9A03B40B99A +S315E631D8201F0C007109FBFF54A03740B90004001103 +S315E631D83000781F12A03700B9BF3B00B91D000014AE +S315E631D840A03B40B900F47ED3A10301912000008BC1 +S315E631D850000440D100D84FB9A13740B92000004B7A +S315E631D860A02F00B9A02F40B9007C0153A02F00B9F3 +S315E631D870A02F40B91F001F6B60010054221B805256 +S315E631D880A13B40B9A03F40B929DFFF97000400111B +S315E631D890E303002A221B8052A13B40B9A03F40B99F +S315E631D8A0EBDEFF97A03B40B900040011A03B00B97F +S315E631D8B0A03B40B91F0C007149FCFF54A03F40B96B +S315E631D8C000040011B0DCFF97A03F00B9A03F40B994 +S315E631D8D01F0C007129F5FF541F2003D5FD7BC4A823 +S315E631D8E0C0035FD6FD7BBDA9FD03009100308052B2 +S315E631D8F0A02300B900008052A3DCFF97A02F00B920 +S315E631D90035000014BF2700B92C000014BF2B00B92F +S315E631D91024000014A32B40B902038052A12740B953 +S315E631D920A02F40B9CADEFF9702038052A12740B93C +S315E631D930A02F40B9FEDEFF97A2138052A12740B948 +S315E631D940A02F40B9FADEFF97A01F00B9A11F40B953 +S315E631D950A02340B93F00006BC901005482178052BB +S315E631D960A12740B9A02F40B9F1DEFF97A01B00B938 +S315E631D970A01B40B900040051E303002A8217805206 +S315E631D980A12740B9A02F40B9B1DEFF9702000014B6 +S315E631D9901F2003D5A02B40B900040011A02B00B9F6 +S315E631D9A0A02B40B91F04007169FBFF54A02740B98B +S315E631D9B000040011A02700B9A02740B91F0C007159 +S315E631D9C069FAFF54A02F40B9000400116EDCFF97C7 +S315E631D9D0A02F00B9A02F40B91F0C007149F9FF54A9 +S315E631D9E01F2003D5FD7BC3A8C0035FD6FD7BBCA94B +S315E631D9F0FD030091000490D220C3BCF2210080528F +S315E631DA00010000B9800880D200FEBFF27DDAFF97C9 +S315E631DA1001181812800100F000200091010000B9CA +S315E631DA20800880D200FEBFF276DAFF97011C00123B +S315E631DA30800100F000300091010000B9800100F06C +S315E631DA4000200091010040B900E089523F00006BA9 +S315E631DA50C1020054800100F000300091000040B967 +S315E631DA601F040071E8000054800100F00040009187 +S315E631DA70010000D021A02791010000F91C00001415 +S315E631DA8081468252002080D220CFBCF254DAFF970B +S315E631DA90800100F0004000912100009021403A914A +S315E631DAA0010000F912000014800100F00020009117 +S315E631DAB0010040B900408A523F00006BE100005454 +S315E631DAC0800100F000400091010000F021F0309134 +S315E631DAD0010000F906000014400000D000E00F9185 +S315E631DAE00BDAFF97E01F80525B01001460DAFF978D +S315E631DAF0E103002AA00100F000801191010000B98E +S315E631DB00A00100F000801191000040B91F24007198 +S315E631DB10C9000054400000D000401091FCD9FF976F +S315E631DB20E01F80524C010014A00100F000801191F3 +S315E631DB30000040B9E103002A804B80D2217C009B6C +S315E631DB4040000090004024912100008B800100F0D6 +S315E631DB5000C00091010000F9800100F000C000919B +S315E631DB60000040F900004039E103002AA00100F047 +S315E631DB7000901191010000B9A00100D00000119189 +S315E631DB801F0000B9A00100D0001011911F0000B9A5 +S315E631DB90BF3B00B908000014800100F000E00091B7 +S315E631DBA0A13B40B91F7821B8A03B40B9000400112A +S315E631DBB0A03B00B9A03B40B91F040071E9FEFF5412 +S315E631DBC000008052F0DBFF97A03F00B95700001402 +S315E631DBD0BF3B00B94E000014800100F000C0009151 +S315E631DBE0030040F9A23B40B9A13F40B9E00301AA9F +S315E631DBF000F47ED304F07DD30000048B0000018B64 +S315E631DC0000F47ED36000008B0000028B0030009179 +S315E631DC1000004039A02B00B9A00100F000C01191F7 +S315E631DC20A13B40B9A23F40B942F87FD34100018BCF +S315E631DC30A22B40B9027821B8A02B40B91FFC03715B +S315E631DC40A0050054A00100D000001191000040B9B2 +S315E631DC50A12B40B93F00006BA9000054A00100D0CA +S315E631DC6000001191A12B40B9010000B9A03B40B9A2 +S315E631DC701F04007181010054800100F000200091FB +S315E631DC80010040B900E089523F00006BC100005403 +S315E631DC90800100F000300091000040B91F040071A8 +S315E631DCA0E9020054A03B40B91F040071A1000054BB +S315E631DCB0A00100D00010119121008052010000B977 +S315E631DCC0800100F000E00091A13B40B9007861B8EF +S315E631DCD0A13F40B9220080524120C11A0200012AF1 +S315E631DCE0800100F000E00091A13B40B9027821B80D +S315E631DCF0040000141F2003D5020000141F2003D5AB +S315E631DD00A03B40B900040011A03B00B9A03B40B9A5 +S315E631DD101F04007129F6FF54A03F40B900040011F3 +S315E631DD2099DBFF97A03F00B9A03F40B91F0C0071C0 +S315E631DD3009F5FF54A00100F000801191030040B9C6 +S315E631DD40800100F001700091800100F000600091E1 +S315E631DD50E20301AAE10300AAE003032AC9D9FF9740 +S315E631DD60A00100F000801191030040B9800100F076 +S315E631DD7001900091800100F000800091E20301AA52 +S315E631DD80E10300AAE003032AF1D9FF97800100F007 +S315E631DD9000700091010040B900648052217C001B7D +S315E631DDA0800100F000600091000040B900781F5311 +S315E631DDB02108C01AA00100D000201191010000B956 +S315E631DDC0800100F000800091010040B9800100F049 +S315E631DDD000700091000040B9217C001B800100F003 +S315E631DDE000900091020040B9800100F00060009198 +S315E631DDF0000040B9407C001B00781F532108C01A49 +S315E631DE00A00100D000301191010000B9000580D2A1 +S315E631DE10A0C2BCF27BD9FF97A02B00B9A02B40B9A3 +S315E631DE20007C185300040011A02700B9A02B40B995 +S315E631DE30000019121F001F6B80000054400080520B +S315E631DE40A03300B90300001420008052A03300B994 +S315E631DE50800100F000600091010040B9A02740B989 +S315E631DE60207C001B00781F53A02300B9800100F007 +S315E631DE7000700091010040B9A03340B9207C001B07 +S315E631DE80A01F00B9800100F000800091010040B981 +S315E631DE90A01F40B9207C001B01701D53800100F0A4 +S315E631DEA000900091020040B9A02340B9407C001BA6 +S315E631DEB02008C01AA02F00B9800100F00080009139 +S315E631DEC0010040B9A01F40B9207C001B01701D53EB +S315E631DED0A22F40B9A02340B9427C001B800100F055 +S315E631DEE000900091000040B9407C001B3F00006B7A +S315E631DEF080000054A02F40B900040011A02F00B9CC +S315E631DF00A02F40B91F1C0071C8000054800100F0F3 +S315E631DF1000A0009101018052010000B9050000140C +S315E631DF20800100F000A00091A12F40B9010000B9AF +S315E631DF30800100F000800091010040B9800100F0D7 +S315E631DF4000900091000040B92108C01A400000D087 +S315E631DF5002A01091400000D000E01091ECD8FF9776 +S315E631DF60210080522000805231DBFF97200080521B +S315E631DF700FDCFF97E9F0FF97A02B00B9A00100F07F +S315E631DF8000901191000040B9A12B40B93F00006BDA +S315E631DF9061000054BF3700B90300001420008052F7 +S315E631DFA0A03700B9400000D000201191A13740B921 +S315E631DFB0D7D8FF9700008052F3DAFF97A03F00B932 +S315E631DFC00D000014A03F40B901641A5300C48052D3 +S315E631DFD020CFBC722000000BE003002A01008052FC +S315E631DFE0FFD8FF97A03F40B900040011E6DAFF9764 +S315E631DFF0A03F00B9A03F40B91F0C007149FEFF545E +S315E631E000800100D000200091010040B900E089523C +S315E631E0103F00006B41010054800100D00030009191 +S315E631E020000040B91F040071A90000540100805276 +S315E631E030002080D220CFBCF2E9D8FF97A03740B98D +S315E631E0401F001F6B6100005400008052020000146D +S315E631E05000008012FD7BC4A8C0035FD6FD7BBBA959 +S315E631E060FD03009100008052C7DAFF97A04F00B951 +S315E631E07097010014A00100D001601291A04F40B97A +S315E631E0800010009100F47ED32000008B000440B9E5 +S315E631E09000141A12007C0653A04700B9A00100D03D +S315E631E0A001601291A04F40B90010009100F47ED381 +S315E631E0B02000008B000440B900140012A04300B9D9 +S315E631E0C0A14340B9005A8452217C001BC09895522F +S315E631E0D03F00006BA9010054A14340B9005A84526E +S315E631E0E0217C001BA02793122100000B20EB8252E4 +S315E631E0F0E036BA72207CA09B00FC60D3007C0D53DF +S315E631E100A04B00B90D000014A14340B9005A845220 +S315E631E110207C001BC12793522100004B20EB825213 +S315E631E120E036BA72207CA09B00FC60D3007C0D53AE +S315E631E130E003004BA04B00B9A14740B900D2825269 +S315E631E140217C001B003A91522100000B20EB8252D2 +S315E631E150E036BA72207CA09B00FC60D3007C0D537E +S315E631E160A03F00B9A13F40B9A04740B92000000B16 +S315E631E170A14F40B921F47ED3A24301914100018BEF +S315E631E180210440D120C80FB9A14B40B9A04340B9CB +S315E631E1902000000BA14F40B921F47ED3A243019171 +S315E631E1A04100018B210440D120D80FB9A04F40B9A7 +S315E631E1B000F47ED3A14301912000008B000440D1C7 +S315E631E1C000C84FB91FFC007169040054A04F40B92D +S315E631E1D000F47ED3A14301912000008B000440D1A7 +S315E631E1E0E10300AAE007805220C80FB9A13F40B942 +S315E631E1F0E003012A21741E530000014B00781F53B8 +S315E631E200E103002AA04740B92000004B01FC00118A +S315E631E210A04B40B9217C001BA03F40B92108C01A6A +S315E631E220A04B40B900781F5302741E534000004B91 +S315E631E2302100000BA04340B92000000BA14F40B9A5 +S315E631E24021F47ED3A24301914100018B210440D1D1 +S315E631E25020D80FB9800100D000200091010040B9E5 +S315E631E26000E089523F00006BA1130054800100D0D3 +S315E631E27000300091000040B91F04007108130054C4 +S315E631E280C03280525ADCFF97E303002AA04F40B9E9 +S315E631E29000F47ED3A14301912000008B000440D1E6 +S315E631E2A001D84FB9A04F40B900F47ED3A2430191CC +S315E631E2B04000008B000440D100C84FB900641A53C0 +S315E631E2C02100002AA00100D002601291A04F40B988 +S315E631E2D00010009100F47ED34000008B000440B973 +S315E631E2E0004C14122000002AE203002AE103032A35 +S315E631E2F0A04F40B9A3DBFF97E03280523CDCFF9773 +S315E631E300E303002AA04F40B900F47ED3A14301913D +S315E631E3102000008B000440D101D84FB9A04F40B957 +S315E631E32000F47ED3A24301914000008B000440D134 +S315E631E33000C84FB900641A532100002AA00100D063 +S315E631E34002601291A04F40B90010009100F47ED3DD +S315E631E3504000008B000440B9004C14122000002A1C +S315E631E360E203002AE103032AA04F40B985DBFF9792 +S315E631E370003380521EDCFF97E303002AA04F40B9F3 +S315E631E38000F47ED3A14301912000008B000440D1F5 +S315E631E39001D84FB9A04F40B900F47ED3A2430191DB +S315E631E3A04000008B000440D100C84FB900641A53CF +S315E631E3B02100002AA00100D002601291A04F40B997 +S315E631E3C00010009100F47ED34000008B000440B982 +S315E631E3D0004C14122000002AE203002AE103032A44 +S315E631E3E0A04F40B967DBFF972033805200DCFF97B9 +S315E631E3F0E303002AA04F40B900F47ED3A14301914D +S315E631E4002000008B000440D101D84FB9A04F40B966 +S315E631E41000F47ED3A24301914000008B000440D143 +S315E631E42000C84FB900641A532100002AA00100D072 +S315E631E43002601291A04F40B90010009100F47ED3EC +S315E631E4404000008B000440B9004C14122000002A2B +S315E631E450E203002AE103032AA04F40B949DBFF97DD +S315E631E46000348052E2DBFF97E303002AA04F40B93E +S315E631E47000F47ED3A14301912000008B000440D104 +S315E631E48001D84FB9A04F40B900F47ED3A2430191EA +S315E631E4904000008B000440D100C84FB900641A53DE +S315E631E4A02100002AA00100D002601291A04F40B9A6 +S315E631E4B00010009100F47ED34000008B000440B991 +S315E631E4C0004C14122000002AE203002AE103032A53 +S315E631E4D0A04F40B92BDBFF9779000014C03280524A +S315E631E4E0C3DBFF97E303002AA04F40B900F47ED39E +S315E631E4F0A14301912000008B000440D101D84FB9E8 +S315E631E500A04F40B900F47ED3A24301914000008B7F +S315E631E510000440D100C84FB900641A532100002ADD +S315E631E52000008A526000A0722000002AE203002A27 +S315E631E530E103032AA04F40B912DBFF97E03280525E +S315E631E540ABDBFF97E303002AA04F40B900F47ED355 +S315E631E550A14301912000008B000440D101D84FB987 +S315E631E560A04F40B900F47ED3A24301914000008B1F +S315E631E570000440D100C84FB900641A532100002A7D +S315E631E58000008A522000A0722000002AE203002A07 +S315E631E590E103032AA04F40B9FADAFF9700338052F6 +S315E631E5A093DBFF97E303002AA04F40B900F47ED30D +S315E631E5B0A14301912000008B000440D101D84FB927 +S315E631E5C0A04F40B900F47ED3A24301914000008BBF +S315E631E5D0000440D100C84FB900641A532100002A1D +S315E631E5E000008A522000A0722000002AE203002AA7 +S315E631E5F0E103032AA04F40B9E2DAFF97203380528E +S315E631E6007BDBFF97E303002AA04F40B900F47ED3C4 +S315E631E610A14301912000008B000440D101D84FB9C6 +S315E631E620A04F40B900F47ED3A24301914000008B5E +S315E631E630000440D100C84FB900641A532100002ABC +S315E631E64000008A522000A0722000002AE203002A46 +S315E631E650E103032AA04F40B9CADAFF970034805264 +S315E631E66063DBFF97E303002AA04F40B900F47ED37C +S315E631E670A14301912000008B000440D101D84FB966 +S315E631E680A04F40B900F47ED3A24301914000008BFE +S315E631E690000440D100C84FB900641A532100002A5C +S315E631E6A000008A522000A0722000002AE203002AE6 +S315E631E6B0E103032AA04F40B9B2DAFF97A04F40B93A +S315E631E6C00004001130D9FF97A04F00B9A04F40B9E9 +S315E631E6D01F0C007109CDFF541F2003D5FD7BC5A85C +S315E631E6E0C0035FD6FD7BBEA9FD03009100008052D3 +S315E631E6F025D9FF97A01F00B947000014C0328052D2 +S315E631E7003BDBFF97E303002AA00100D001601291BB +S315E631E710A01F40B900F47ED32000008B000440B937 +S315E631E72000000F32E203002AE103032AA01F40B9B3 +S315E631E73094DAFF97E03280522DDBFF97E303002A26 +S315E631E740A00100D001601291A01F40B900F47ED33A +S315E631E7502000008B000440B9E203002AE103032AD4 +S315E631E760A01F40B987DAFF970033805220DBFF9747 +S315E631E770E303002AA00100D001601291A01F40B93F +S315E631E78000F47ED32000008B000440B9E203002A70 +S315E631E790E103032AA01F40B97ADAFF972033805284 +S315E631E7A013DBFF97E303002AA00100D00160129143 +S315E631E7B0A01F40B900F47ED32000008B000440B997 +S315E631E7C0E203002AE103032AA01F40B96DDAFF9777 +S315E631E7D00034805206DBFF97E303002AA00100D01E +S315E631E7E001601291A01F40B900F47ED32000008B60 +S315E631E7F0000440B9E203002AE103032AA01F40B927 +S315E631E80060DAFF97A01F40B900040011DED8FF9702 +S315E631E810A01F00B9A01F40B91F0C007109F7FF54BC +S315E631E8201F2003D5FD7BC2A8C0035FD6FD7BBDA9FC +S315E631E830FD030091A01F00B9A00100D0006012913E +S315E631E8401F0000B9BF2F00B911000014A00100D096 +S315E631E85001601291A02F40B900F47ED32000008BDF +S315E631E8601F0400B9A00100D001601291A02F40B972 +S315E631E8700010009100F47ED32000008B1F0400B90E +S315E631E880A02F40B900040011A02F00B9A02F40B93E +S315E631E8901F0C0071C9FDFF5400008052BAD8FF97AC +S315E631E8A0A02F00B91C000014E0328052E103002AA1 +S315E631E8B0A02F40B933DCFF97E203002AA00100D04E +S315E631E8C001601291A02F40B900F47ED32000008B6F +S315E631E8D0020400B9E0328052E103002AA02F40B9A2 +S315E631E8E028DCFF97E203002AA00100D001601291ED +S315E631E8F0A02F40B90010009100F47ED32000008BA2 +S315E631E900020400B9A02F40B9000400119ED8FF9742 +S315E631E910A02F00B9A02F40B91F0C007169FCFF5436 +S315E631E920A01F40B91F001F6B61180054000590D235 +S315E631E93020C3BCF2000040B9A02300B9A02340B9F8 +S315E631E9401FBC2B7188020054A12340B9E003012A8A +S315E631E950006C1C5302701D530000020B0000014B84 +S315E631E960005C41510060295161BA8952410CA2726B +S315E631E970017C219B21FC60D3217C0613007C1F138D +S315E631E9802100004BA00100D000601291010000B9D0 +S315E631E99014000014A22340B9E103022A20701D5364 +S315E631E9A0E103002A206C1C530000014B0000020BE8 +S315E631E9B00020415100B0155161BA8952410CA2721B +S315E631E9C0017C219B21FC60D3217C0613007C1F133D +S315E631E9D02100004BA00100D000601291010000B980 +S315E631E9E00000805268D8FF97A02F00B98B0000143B +S315E631E9F0A00100D001601291A02F40B900F47ED378 +S315E631EA002000008B000440B900140012A02B00B997 +S315E631EA10A00100D001601291A02F40B900F47ED357 +S315E631EA202000008B000440B9007C06530014001226 +S315E631EA30A02700B9A00100D000601291020040B9CA +S315E631EA40E103022A20741E53E103002A20701D5386 +S315E631EA500000014B0000020B00A4385161BA89521D +S315E631EA60410CA272017C219B21FC60D3217C0613E9 +S315E631EA70007C1F132100004BA02B40B93F00006BF1 +S315E631EA804A020054A00100D000601291010040B95B +S315E631EA9080038012207C001B00A4381161BA8952AA +S315E631EAA0410CA272017C219B21FC60D3217C0613A9 +S315E631EAB0007C1F132100004BA02B40B92000000B30 +S315E631EAC0A02B00B902000014BF2B00B9A00100D07B +S315E631EAD000601291010040B9C0068052217C001BCC +S315E631EAE0A04B83122000000B61BA8952410CA27207 +S315E631EAF0017C219B21FC60D3217C0613007C1F130C +S315E631EB002100004BA02740B93F00006B6A02005452 +S315E631EB10A00100D000601291010040B9A006801232 +S315E631EB20217C001BC04B83522000000B61BA89520F +S315E631EB30410CA272017C219B21FC60D3217C061318 +S315E631EB40007C1F132100004BA02740B92000000BA3 +S315E631EB50A02700B902000014BF2700B9800100D012 +S315E631EB6000200091010040B900E089523F00006B78 +S315E631EB7021030054800100D000300091000040B9F5 +S315E631EB801F04007188020054A00100D00160129181 +S315E631EB90A02F40B900F47ED32000008B000440B9A3 +S315E631EBA0014C1412A02740B900641A532100002AF9 +S315E631EBB0A02B40B92100002AA00100D002601291B3 +S315E631EBC0A02F40B900F47ED34000008B010400B992 +S315E631EBD00E000014A02740B901641A53A02B40B9A0 +S315E631EBE02100002A00008A522000A0722100002A64 +S315E631EBF0A00100D002601291A02F40B900F47ED375 +S315E631EC004000008B010400B9A02F40B90004001181 +S315E631EC10DDD7FF97A02F00B9A02F40B91F0C0071A1 +S315E631EC2089EEFF54A00100D000601291A10F805207 +S315E631EC30010000B91F2003D5FD7BC3A8C0035FD60B +S315E631EC40800100D000C00091000040F90000403953 +S315E631EC50C0035FD6FF4301D1E00700F9E10F00F9C2 +S315E631EC60E21300F9E31700F9E41B00F9E51F00F9B1 +S315E631EC70E62300F9E72700F91F2003D5FF43019183 +S315E631EC80C0035FD6FD7BBDA9FD030091A07F0039A8 +S315E631EC90A17B0039A20B00F9A07F403900781F53DA +S315E631ECA0E403002AA07B4039A1A3009123008052D8 +S315E631ECB0E20301AAE103002AE003042A57CFFF97CC +S315E631ECC0A02F00B9A02B40B9011C0053A00B40F987 +S315E631ECD001000039A02F40B91F001F6B60000054B8 +S315E631ECE0000080120200001400008052FD7BC3A8AA +S315E631ECF0C0035FD6FD7BBDA9FD030091A07F003938 +S315E631ED00A17B0039A2770039A0774039A02B00B92B +S315E631ED10A07F403900781F53E403002AA07B4039AF +S315E631ED20A1A3009123008052E20301AAE103002A5E +S315E631ED30E003042A72D0FF97A02F00B9A02F40B97D +S315E631ED401F001F6B600000540000801202000014A1 +S315E631ED5000008052FD7BC3A8C0035FD6FF4300D1D6 +S315E631ED60E00700F9E00740F9000040B9FF430091BA +S315E631ED70C0035FD6FD7BBDA9FD030091A00F00F967 +S315E631ED80800182D2A0C0BCF2F5FFFF97A02F00B971 +S315E631ED90A02F40B9000018121F001F6BA0000054C7 +S315E631EDA0A00F40F921008052010000B9030000149A +S315E631EDB0A00F40F91F0000B91F2003D5FD7BC3A87C +S315E631EDC0C0035FD6FD7BBCA9FD030091A01F00B948 +S315E631EDD0BF3F00B9BFBF003900008012A03700B986 +S315E631EDE0A01F40B91F040071E1070054A0BF00918E +S315E631EDF0E20300AA0104805200068052A2FFFF9781 +S315E631EE00A03700B9A03740B91F001F6BE0000054A8 +S315E631EE10400000B0004011918FFFFF97000080124D +S315E631EE20A03F00B915000014A0BF403900781B1287 +S315E631EE30001C0053A0BF0039A0BF4039E203002AC7 +S315E631EE400104805200068052ABFFFF97A03700B926 +S315E631EE50A03740B91F001F6B00010054A0BF4039EF +S315E631EE60E103002A400000B000C011917AFFFF9716 +S315E631EE7000008012A03F00B9007D8052A03B00B968 +S315E631EE800C000014800182D2A0C0BCF2B4FFFF9719 +S315E631EE90A03300B9A03340B9000018121F001F6B2A +S315E631EEA000010054A03B40B900040051A03B00B933 +S315E631EEB0A03B40B91F001F6B61FEFF5402000014F0 +S315E631EEC01F2003D5A03B40B91F001F6BC10000547C +S315E631EED0400000B0006012915FFFFF97000080129C +S315E631EEE0A03F00B9A03F40B9FD7BC4A8C0035FD6B9 +S315E631EEF000181818181818181B181818181818188A +S315E631EF00031818181818181806181818181818188B +S315E631EF1009181818181818180C181818181818186F +S315E631EF200F18181818181818121818181818181853 +S315E631EF301818181818181818181818181818181834 +S315E631EF4018181818181818181500000012150003A5 +S315E631EF5006090C0F000000000C0005E60000000073 +S315E631EF600C1005E6000000000C2005E60000000066 +S315E631EF700C3005E6000000000C4005E60000000016 +S315E631EF800C5005E6000000000C5405E600000000D2 +S315E631EF900C5805E60000000000030A060A0A0A09CB +S315E631EFA0606330E600000000606330E60000000092 +S315E631EFB0346330E600000000346330E600000000DA +S315E631EFC0606330E600000000346330E6000000009E +S315E631EFD0346330E600000000346330E600000000BA +S315E631EFE0E45D30E600000000E45D30E60000000056 +S315E631EFF0E45D30E600000000EC6230E60000000039 +S315E631F000E45D30E600000000E45D30E60000000035 +S315E631F010E45D30E600000000E45D30E60000000025 +S315E631F0204C5F30E600000000B06030E600000000DC +S315E631F030DC6130E6000000003C5E30E600000000B0 +S315E631F0404C5F30E600000000B06030E600000000BC +S315E631F050DC6130E6000000003C5E30E60000000090 +S315E631F060CC5E30E600000000146030E600000000B9 +S315E631F070786130E600000000886230E60000000084 +S315E631F080CC5E30E600000000146030E60000000099 +S315E631F090786130E600000000105E30E600000000E0 +S315E631F0A0685E30E600000000945F30E6000000005E +S315E631F0B0146130E600000000246230E6000000000C +S315E631F0C0685E30E600000000945F30E6000000003E +S315E631F0D0146130E600000000E45D30E60000000031 +S315E631F0E0207F32E600000000706530E60000000061 +S315E631F0F00000000000000000507732E60000000014 +S315E631F100AC6530E6000000000000000000000000BB +S315E631F110287F32E600000000886730E6000000000E +S315E631F1200000000000000000307F32E600000000FB +S315E631F130F06A30E600000000000000000000000042 +S315E631F140387F32E600000000086B30E6000000004A +S315E631F1500000000000000000407F32E600000000BB +S315E631F160206B30E6000000000000000000000000E1 +S315E631F170907532E600000000846930E60000000052 +S315E631F1800000000000000000487F32E60000000083 +S315E631F1909C6930E600000000000000000000000037 +S315E631F1A0507F32E600000000B46930E60000000028 +S315E631F1B00000000000000000587F32E60000000043 +S315E631F1C0CC6930E6000000000000000000000000D7 +S315E631F1D0607F32E600000000386B30E60000000062 +S315E631F1E00000000000000000687F32E60000000003 +S315E631F1F0189C30E600000000000000000000000028 +S315E631F200707F32E60000000060AF30E600000000B5 +S315E631F2100000000000000000787F32E600000000C2 +S315E631F22004B330E6000000000000000000000000F4 +S315E631F230887F32E6000000002C3931E60000000016 +S315E631F2400000000000000000907F32E6000000007A +S315E631F250986F30E600000000000000000000000074 +S315E631F260987F32E6000000007C6D30E60000000053 +S315E631F2700000000000000000A07F32E6000000003A +S315E631F280907030E60000000000000000000000004B +S315E631F290A87F32E600000000AC0831E60000000047 +S315E631F2A00000000000000000B07F32E600000000FA +S315E631F2B0FCEE30E600000000000000000000000031 +S315E631F2C0B87F32E6000000002C0031E6000000008F +S315E631F2D00000000000000000C07F32E600000000BA +S315E631F2E0400031E6000000000000000000000000AA +S315E631F2F0D07F32E600000000BC0231E600000000B5 +S315E631F3000000000000000000E07F32E60000000069 +S315E631F3107C0531E600000000000000000000000038 +S315E631F320E87F32E600000000900631E60000000094 +S315E631F3300000000000000000F07F32E60000000029 +S315E631F340E47130E600000000000000000000000035 +S315E631F350F87F32E600000000B09E30E6000000009D +S315E631F3600000000000000000088032E600000000E0 +S315E631F3703CA930E600000000000000000000000075 +S315E631F380188032E6000000001CA230E600000000DC +S315E631F3900000000000000000288032E60000000090 +S315E631F3A054A530E600000000000000000000000031 +S315E631F3B0308032E600000000FC2B30E6000000002B +S315E631F3C00000000000000000408032E60000000048 +S315E631F3D0982B30E600000000000000000000000037 +S315E631F3E0508032E600000000441231E600000000AB +S315E631F3F00000000000000000608032E600000000F8 +S315E631F400140F31E6000000000000000000000000A5 +S315E631F410688032E600000000ACBA30E60000000053 +S315E631F4200000000000000000708032E600000000B7 +S315E631F4307CAC30E600000000000000000000000071 +S315E631F440788032E600000000743030E600000000D5 +S315E631F4500000000000000000808032E60000000077 +S315E631F460FC1231E60000000000000000000000005A +S315E631F470908032E600000000341431E600000000E8 +S315E631F480000000000000000000000000000000005F +S315E631F490000000000000000000000000000000004F +S315E631F4A0000000000000000000000000000000003F +S315E631F4B0000000000000000000000000000000002F +S315E631F4C0000000000000000000000000000000001F +S315E631F4D0000000000000000000000000000000000F +S315E631F4E000000000000000000000000000000000FF +S315E631F4F000000000000000000000000000000000EF +S315E631F50000000000000000000000000000000000DE +S315E631F51000000000000000000005260A2626260F18 +S315E631F520001F52375252524F00040E080E0E0E0C81 +S315E631F5300003090609090908108332E600000000CE +S315E631F540308332E600000000708332E600000000C8 +S315E631F550A08332E600000000C88332E600000000F0 +S315E631F560F88332E600000000308432E6000000001F +S315E631F570608432E600000000908432E60000000046 +S315E631F580C08432E600000000F88432E6000000006E +S315E631F590208532E600000000508532E600000000A4 +S315E631F5A0888532E600000000D08532E600000000AC +S315E631F5B0F88532E600000000208632E600000000DB +S315E631F5C0688632E600000000A08632E600000000DA +S315E631F5D0D88632E600000000208732E600000000D9 +S315E631F5E0788732E600000000C88732E60000000080 +S315E631F5F0188832E600000000688832E6000000002E +S315E631F600B88832E600000000088932E600000000DC +S315E631F610488932E600000000808932E600000000C3 +S315E631F620B88932E600000000F08932E600000000D3 +S315E631F63000000000000000000000000000000000AD +S315E631F640000000000000000000000000000000009D +S315E631F6500000000000000000108A32E600000000DB +S315E631F6600000000000000000308A32E600000000AB +S315E631F6700000000000000000488A32E60000000083 +S315E631F680000000000000000000020B1400020B141B +S315E631F690000305080B0E1114142E000000070E1593 +S315E631F6A01C23000000070E151C23000000060C1271 +S315E631F6B000180C00002514398E0F525DE6E6B13A94 +S315E631F6C0B1B1B1B13A202004F4F44444F4F4F4F49B +S315E631F6D0F4F4F4F4F44F075252525253535353530C +S315E631F6E06F070705390000008E0E525DE6E6B13545 +S315E631F6F0E4E4E4E43520200AF4F44444F4F44444FE +S315E631F7004444F4F4F44F075252525253535353533B +S315E631F7106F070705660000008E10626DE5E5365126 +S315E631F720E4E4E4E43620200AF4F44444F4F44444CC +S315E631F7304444F4F4F44F0E52525252535353535304 +S315E631F7406F0707053E0000008E11626DE5E536B1BD +S315E631F750E4E4E4E43620200AF4F44444F4F444449C +S315E631F7604444F4F4F44F015252525253514F4D013F +S315E631F77052536000000000000000110001880000CD +S315E631F780A8AB32E600000000E0AB32E6000000004E +S315E631F79018AC32E60000000050AC32E6000000005C +S315E631F7A088AC32E600000000C0AC32E6000000006C +S315E631F7B0F8AC32E60000000030AD32E6000000007B +S315E631F7C068AD32E600000000A0AD32E6000000008A +S315E631F7D0D8AD32E60000000010AE32E60000000099 +S315E631F7E048AE32E60000000080AE32E600000000A8 +S315E631F7F0B8AE32E600000000F0AE32E600000000B8 +S315E631F80028AF32E60000000058AF32E600000000CD +S315E631F81088AF32E600000000B8AF32E600000000FD +S315E631F820E8AF32E60000000018B032E6000000002C +S315E631F83048B032E60000000078B032E6000000005B +S315E631F840A8B032E600000000D8B032E6000000008B +S315E631F85008B132E60000000038B132E600000000B9 +S315E631F86070B132E600000000A8B132E600000000D1 +S315E631F870E0B132E60000000018B232E600000000E0 +S315E631F88050B232E60000000088B232E600000000EF +S315E631F890C0B232E600000000F8B232E600000000FF +S315E631F8A030B332E60000000068B332E6000000000D +S315E631F8B0A0B332E600000000D8B332E6000000001D +S315E631F8C008B432E60000000038B432E60000000043 +S315E631F8D068B432E60000000098B432E60000000073 +S315E631F8E0C8B432E60000000000B532E6000000009A +S315E631F8F038B532E60000000070B532E600000000A9 +S315E631F900A8B532E600000000E0B532E600000000B8 +S315E631F91018B632E60000000048B632E600000000CE +S315E631F92078B632E600000000A8B632E600000000FE +S315E631F930000050E600000000040050E6000000003A +S315E631F940080050E6000000000C0050E6000000001A +S315E631F950100050E600000000140050E600000000FA +S315E631F960180050E6000000001C0050E600000000DA +S315E631F970200050E600000000240050E600000000BA +S315E631F980240050E600000000280050E600000000A2 +S315E631F9902C0050E600000000300050E60000000082 +S315E631F9A0340050E6000000003C0050E6000000005E +S315E631F9B0380050E6000000000E001D121818181522 +S315E631F9C0151500000E001D1218181815151500002C +S315E631F9D00E001D12181818151515000000050A0F28 +S315E631F9E0232319141E000000FFFFFFFFFFFFFFFF71 +S315E631F9F000040B00FFFFFFFFFFFFFFFF00040110CE +S315E631FA000004051801040500010405080104051082 +S315E631FA10010405180204050002040508020405106E +S315E631FA200204051803040400030403080404180059 +S315E631FA300404031805041800050402180604010037 +S315E631FA40060402080604011006040118070402003A +S315E631FA5007040408070404100704041808040A0016 +S315E631FA6008040410FFFFFFFFFFFFFFFF0804071836 +S315E631FA70FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF79 +S315E631FA80FFFFFFFFFFFFFFFF09040A000904041029 +S315E631FA90090401180A0401000A0402080A040910D5 +S315E631FAA00B0409000B0402100C042000FFFFFFFFD4 +S315E631FAB00D040100FFFFFFFFFFFFFFFFFFFFFFFF23 +S315E631FAC0FFFFFFFF0E0420000F0420001004200084 +S315E631FAD01104200012040300120401081204031073 +S315E631FAE0120403181304040013040408130404105F +S315E631FAF0130404181404010014040108140406104E +S315E631FB0014040418FFFFFFFF150406001504040864 +S315E631FB101504061015040418160402001604050821 +S315E631FB201604081017042000180406001804030802 +S315E631FB3018040B10190404001904040819040410F6 +S315E631FB40FFFFFFFF190401181A0409001B04200000 +S315E631FB501C0420001D0420001E0420001F04100092 +S315E631FB60200420002104010021040608210408109E +S315E631FB7022042000FFFFFFFF23040A0023040610B8 +S315E631FB8023040718240408002404080824040A1068 +S315E631FB90250407002504080825040810250403185A +S315E631FBA026040A0026040A1027041100280409004F +S315E631FBB0280409102904100029040E102A040E001F +S315E631FBC02A040C102B040A002B040A102C0402001A +S315E631FBD02D0420002E040B002E040B102F042000DA +S315E631FBE0300412003104200032042000FFFFFFFF0B +S315E631FBF0FFFFFFFF33040100330401083304081025 +S315E631FC0034040C0034040C1035040C0035040C10A5 +S315E631FC1036040C0036040C1037040C0037040C108D +S315E631FC2038040C0038040C1039040C0039040B1076 +S315E631FC30FFFFFFFFFFFFFFFF3A040B003A040B100D +S315E631FC403B040B003B040B103C040B003C040B104D +S315E631FC503D040B003D040B103E040B003E040A1036 +S315E631FC60FFFFFFFF3F040A003F040A1040040A0083 +S315E631FC7040040A1041040A0041040A1042040A000B +S315E631FC8042040A10FFFFFFFF43040A0043040A1049 +S315E631FC9044040A0044040A1045040A0045040A10DD +S315E631FCA046040A0046040A1047040A0047040A10C5 +S315E631FCB048040A0048040A1049040A0049040A10AD +S315E631FCC04A040A004A040A104B040A004B040A1095 +S315E631FCD04C040A004C0404104C0403184D040A0083 +S315E631FCE04D040A104E0401004E040A084E04041867 +S315E631FCF04F040B004F040A10FFFFFFFF50040800C4 +S315E631FD005004080850040810500408185104080035 +S315E631FD10FFFFFFFF5104080851040110510408188A +S315E631FD20520408005204020852040210520404181E +S315E631FD3053040400FFFFFFFF5304040853040A107B +S315E631FD405404060054040808FFFFFFFF5404041068 +S315E631FD5054040418550405005504040855040510E1 +S315E631FD6056040A0056040A1057040800FFFFFFFF3F +S315E631FD7057040408FFFFFFFFFFFFFFFF00060500FC +S315E631FD8000060508000605100006051801060500F9 +S315E631FD900106050801060B100206010002060308F4 +S315E631FDA003062000FFFFFFFF0406030004060A08E8 +S315E631FDB0FFFFFFFFFFFFFFFF0406031805060300FB +S315E631FDC0050601080506011005060618FFFFFFFFC1 +S315E631FDD0FFFFFFFFFFFFFFFF0606020006060308E9 +S315E631FDE00606011007060F00080620000906200060 +S315E631FDF00A060B000A060B100B060B00FFFFFFFF88 +S315E631FE00FFFFFFFF0C0618000D0618000E06180058 +S315E631FE100F0618000F06041810060500100602082C +S315E631FE201006041010060418110601001106010821 +S315E631FE3011060110110603181206200013062000DA +S315E631FE4014060100140614081506140016061400E5 +S315E631FE501706140018061400190614001A061400BB +S315E631FE601B0614001C0618001D060A001D060610A0 +S315E631FE701D0606181E060600FFFFFFFFFFFFFFFF02 +S315E631FE801F0608001F060B0820060B0020060B107E +S315E631FE9021060B0021060B1022060B002206041062 +S315E631FEA023060A002306061023060818FFFFFFFF7E +S315E631FEB024060400FFFFFFFFFFFFFFFF00070100F7 +S315E631FEC000070208000705100007051801070500B7 +S315E631FED00107050801070B100207050002070108AD +S315E631FEE002070110FFFFFFFF0207011803070100B2 +S315E631FEF00307040803070B1004070B00FFFFFFFF98 +S315E631FF000407041005070B00050704100507011859 +S315E631FF100607010006070108070720000807200043 +S315E631FF200907080009070A08090705180A070A0032 +S315E631FF300A0703100A0703180B0701000B07020825 +S315E631FF400B0701100B0701180C0701000C07020815 +S315E631FF50FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF94 +S315E631FF60FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF84 +S315E631FF70FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF74 +S315E631FF800C0701100C0701180D070D00FFFFFFFFE7 +S315E631FF90FFFFFFFF0E0705000F0701000F070E08EB +S315E631FFA010070E0010070E1011070E0011070E107E +S315E631FFB012070400FFFFFFFFFFFFFFFFFFFFFFFF13 +S315E631FFC0FFFFFFFF12070B0813070B0013070B1092 +S315E631FFD014070B00FFFFFFFFFFFFFFFFFFFFFFFFEA +S315E631FFE0FFFFFFFF15070D00FFFFFFFFFFFFFFFFD7 +S315E631FFF01507101016070800FFFFFFFF1607100852 +S315E632000017071000170710101807100018071010F8 +S315E63200101907030019070408190701101907041806 +S315E6320020FFFFFFFFFFFFFFFF1A0701001A0712085D +S315E63200301B070A001B070C101C0712001D071400CB +S315E63200401E0712001F0711002007110021071200B2 +S315E63200502207120023071200240712002507120090 +S315E6320060260712002707120028071200FFFFFFFFB6 +S315E6320070FFFFFFFF290719002A0719002B07200081 +S315E63200802C0717002C0708182D0701002D07010843 +S315E63200902E0720002F070800FFFFFFFF2F07030872 +S315E63200A03007180031071800FFFFFFFFFFFFFFFF9B +S315E63200B0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF32 +S315E63200C0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF22 +S315E63200D0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF12 +S315E63200E0FFFFFFFF32071000320701103207011811 +S315E63200F0330705003407200035070900FFFFFFFF07 +S315E6320100FFFFFFFF360720003707040037071008E0 +S315E63201103707061838071000FFFFFFFFFFFFFFFF1E +S315E6320120FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC1 +S315E6320130FFFFFFFFFFFFFFFF390720003A070B00FD +S315E6320140FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA1 +S315E6320150FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF91 +S315E6320160000201000002040800021010010201003A +S315E632017001020108FFFFFFFFFFFFFFFF010210103A +S315E6320180FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF61 +S315E6320190FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF51 +S315E63201A0FFFFFFFF020220000302100004022000D6 +S315E63201B005021000060220000702100007021010A0 +S315E63201C008022000090220000A0220000B02200063 +S315E63201D00C0210000D0220000E0220000F02200053 +S315E63201E01002200011021000120220001302200033 +S315E63201F0140220001502200016020900160201102A +S315E63202001702200018020500180201081802081023 +S315E63202101802081819021C001A021C001B021C00DE +S315E63202201C021C001D021C001E021C001F021C00C2 +S315E632023020021C0021021C0022021C0023021C00A2 +S315E632024024021C0025021C0026021C0027021C0082 +S315E632025028021C002902010029020108290201109E +S315E6320260290204182A0208002A0208082A02081075 +S315E63202702A0204182B020600FFFFFFFF2B020708AD +S315E63202802B020610FFFFFFFF2B0207182C02060091 +S315E6320290FFFFFFFF2C0207082C0202102C02011880 +S315E63202A0FFFFFFFF2D020A002D0210102E020A0072 +S315E63202B02E0210102F020A002F021010FFFFFFFF48 +S315E63202C030021000FFFFFFFFFFFFFFFF3002011093 +S315E63202D03002011831020100310201083102011001 +S315E63202E031020118320202003202020832020210EA +S315E63202F032020218330202003302030833020110D5 +S315E6320300330201183402010034020108FFFFFFFF0F +S315E6320310340202103402011835020100FFFFFFFFF4 +S315E6320320350202083502011035020118FFFFFFFFDA +S315E6320330360202003602010836020110FFFFFFFFDF +S315E63203403602021837020700370201083702011071 +S315E63203503702011838020100380201083802011064 +S315E6320360FFFFFFFF3802011839020400390204089A +S315E632037039020410390201183A0202003A02060834 +S315E63203803A020610FFFFFFFFFFFFFFFFFFFFFFFF09 +S315E63203903A0202183B0210003B0201103B020118F8 +S315E63203A0FFFFFFFF3C0204003C0201083C02041058 +S315E63203B03C0202183D020800FFFFFFFFFFFFFFFF88 +S315E63203C0FFFFFFFF3D020A083E0220003F02200001 +S315E63203D040020500400201084002051040020818B4 +S315E63203E041020100410208084102011041020818A1 +S315E63203F04202010042020408420204104202041892 +S315E6320400430204004302040843020410430204187A +S315E63204104402040044020408440204104402011869 +S315E63204204502040045020408450204104502041852 +S315E6320430460204004602040846020610460206183A +S315E63204404702060047020608470206104702061822 +S315E6320450FFFFFFFF48020100480201084802021088 +S315E6320460FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7E +S315E6320470FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF6E +S315E632048048020418490204004902010849020110E9 +S315E6320490FFFFFFFF490201184A020100FFFFFFFF95 +S315E63204A04A0201084A0201104A0201184B020400C6 +S315E63204B04B0204084B020A104C0220004D0204009D +S315E63204C04D020808FFFFFFFFFFFFFFFFFFFFFFFFBB +S315E63204D0FFFFFFFFFFFFFFFFFFFFFFFF4D020210A9 +S315E63204E04D0202184E0220004F0202004F02100859 +S315E63204F05002100050020410500204185102050050 +S315E632050051020508FFFFFFFFFFFFFFFFFFFFFFFF79 +S315E6320510FFFFFFFF51020110510201185202070096 +S315E63205205202070852020710520207185302070010 +S315E632053053020708530207105302071854020700FC +S315E63205405402070854020710FFFFFFFFFFFFFFFFC3 +S315E6320550FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8D +S315E632056054020318550201005502020855020110DB +S315E632057055020418560202005602010856020110C6 +S315E6320580FFFFFFFF5602011857020400570208081A +S315E632059057020A1058020A0058020A1059020A008D +S315E63205A059020A105A020A005B0220005C02200057 +S315E63205B05D020100FFFFFFFFFFFFFFFFFFFFFFFFC9 +S315E63205C05D0202085D0202105E0210005E0205104E +S315E63205D05E0206185F0205005F0205085F020E102C +S315E63205E06002050060020E086002051861020E001E +S315E63205F0610205106102011862020500620205080F +S315E632060062020A1063020A006302051063020518E3 +S315E632061064020A0064020A106502050065020508EC +S315E632062065020A1066020A00FFFFFFFFFFFFFFFFC1 +S315E6320630FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAC +S315E632064066020710660207186702040067020408A4 +S315E6320650FFFFFFFFFFFFFFFFFFFFFFFF670204100B +S315E6320660670208186802080068020408FFFFFFFFFF +S315E6320670FFFFFFFFFFFFFFFF68020410FFFFFFFFEA +S315E6320680FFFFFFFFFFFFFFFF68020418FFFFFFFFD2 +S315E6320690FFFFFFFFFFFFFFFF69020400690205085D +S315E63206A069020710690208186A0210006A0208101F +S315E63206B06B0210006B0208106C0210006C02081016 +S315E63206C06C0208186D0201006D0201086D02061011 +S315E63206D06D0206186E020600FFFFFFFF6E02010884 +S315E63206E06E020310FFFFFFFFFFFFFFFFFFFFFFFF75 +S315E63206F06F020A006F020A107002040070020108E5 +S315E632070070020410FFFFFFFFFFFFFFFFFFFFFFFF51 +S315E6320710FFFFFFFFFFFFFFFFFFFFFFFF7002071836 +S315E6320720710207007102050871020510FFFFFFFF2D +S315E6320730FFFFFFFFFFFFFFFF71020418720201009F +S315E6320740720201087202021072020818730220005F +S315E63207507402200075021000FFFFFFFFFFFFFFFF66 +S315E6320760FFFFFFFF7502021075020118FFFFFFFF5A +S315E63207707602020076020808760208107602081831 +S315E6320780770208007702080877020810FFFFFFFFB4 +S315E63207907702081878020800780208087802081004 +S315E63207A07802081879020800FFFFFFFF7902080887 +S315E63207B079020810790208187A0208007A020808DD +S315E63207C07A020810FFFFFFFF7A0208187B0208005A +S315E63207D07B0208087B0208107B0208187C020800B6 +S315E63207E07C020808FFFFFFFF7C0208107C0208182D +S315E63207F07D0208007D0208087D0208107D0208188F +S315E6320800FFFFFFFF7E0208007E0208087E0208101E +S315E63208107E0208187F0208007F020808FFFFFFFF04 +S315E63208207F0208107F020818800208008002080854 +S315E6320830800208108002081881020800FFFFFFFFD7 +S315E6320840810208088102081081020818820208002D +S315E63208508202080882020810FFFFFFFF82020818AA +S315E63208608302080083020808830208108302081806 +S315E632087084020800FFFFFFFF84020808840208109C +S315E632088084020818850208008502080885020810DF +S315E632089085020818FFFFFFFF86020800860208086F +S315E63208A086020810860208188702080087020808B8 +S315E63208B0FFFFFFFF87020810870208188802080042 +S315E63208C0880208088802081088020818FFFFFFFF28 +S315E63208D08902080089020208890203108A020A009E +S315E63208E08A020A108B020A008B0205108B02041862 +S315E63208F08C0208008C0208088C0206108C02061856 +S315E63209008D0211008D0208188E0204008E02060848 +S315E6320910FFFFFFFF8E0206108E020818FFFFFFFF6B +S315E63209208F0204008F0208088F0208108F0206181B +S315E6320930900206009002110891020800910204081C +S315E632094091020610FFFFFFFF910206189202080097 +S315E6320950FFFFFFFF9202040892020810920208187D +S315E632096093020600930206089402110094020818CE +S315E63209709502040095020608FFFFFFFF9502061070 +S315E632098095020818FFFFFFFF960204009602040856 +S315E63209909602041096020418970204009702040897 +S315E63209A09702041097020418980204009802040883 +S315E63209B0980204109802041899020400990204086F +S315E63209C099020410990204189A0204009A0204085B +S315E63209D09A0204109A0204189B0211009C02100035 +S315E63209E09D0211009E0220009F022000A0022000F6 +S315E63209F0A1022000A2022000A3022000A4022000C7 +S315E6320A00A5022000A6022000A7020200A7020508D8 +S315E6320A10A7020510FFFFFFFFFFFFFFFFFFFFFFFF06 +S315E6320A20FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB8 +S315E6320A30FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA8 +S315E6320A40FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF98 +S315E6320A50FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF88 +S315E6320A60FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF78 +S315E6320A70FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF68 +S315E6320A80FFFFFFFFA7020118A8020400A80210081A +S315E6320A90A9022000AA021000AB022000AC02100026 +S315E6320AA0AD022000AE020700AE020108AE02021027 +S315E6320AB0AE020618AF020100AF020108B00220000C +S315E6320AC0B1020200B2022000B3022000FFFFFFFFAE +S315E6320AD0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF08 +S315E6320AE0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8 +S315E6320AF0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE8 +S315E6320B00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD7 +S315E6320B10FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC7 +S315E6320B20FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB7 +S315E6320B30FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA7 +S315E6320B40FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF97 +S315E6320B50FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF87 +S315E6320B60FFFFFFFFB4020400FFFFFFFFFFFFFFFFB9 +S315E6320B70FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF67 +S315E6320B80FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF57 +S315E6320B90FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF47 +S315E6320BA0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF37 +S315E6320BB0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF27 +S315E6320BC0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF17 +S315E6320BD0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF07 +S315E6320BE0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7 +S315E6320BF0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE7 +S315E6320C00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD6 +S315E6320C10FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC6 +S315E6320C20FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB6 +S315E6320C30FFFFFFFFFFFFFFFFFFFFFFFF000820007A +S315E6320C400108040001080B08FFFFFFFFFFFFFFFF65 +S315E6320C50010801180208050002080508020805100F +S315E6320C6002080518030805000308050803080510F7 +S315E6320C7003080518040805000408040804080310E6 +S315E6320C8005081800050803180608180006080218AB +S315E6320C9007080100070802080708011007080118C5 +S315E6320CA008080200080804080808041008080418A8 +S315E6320CB009080A0009080410FFFFFFFFFFFFFFFFDE +S315E6320CC009080718FFFFFFFFFFFFFFFFFFFFFFFFE2 +S315E6320CD0FFFFFFFFFFFFFFFFFFFFFFFF0A080A00E6 +S315E6320CE00A0805100A0801180B0801000B08020863 +S315E6320CF00B0809100C0809000C0802100D08200032 +S315E6320D00FFFFFFFF0E080100FFFFFFFFFFFFFFFFBA +S315E6320D10FFFFFFFFFFFFFFFF0F082000100820004E +S315E6320D2011082000120820001308030013080108F0 +S315E6320D3013080310130803181408040014080408E9 +S315E6320D4014080410140804181508010015080108D9 +S315E6320D501508061015080418FFFFFFFF16080600E9 +S315E6320D6016080408160806101608041817080200AC +S315E6320D70170805081708081018082000190806008B +S315E6320D801908030819080B101A0804001A08040889 +S315E6320D901A080410FFFFFFFF1A0801181B0809009C +S315E6320DA01C0820001D0820001E0820001F0820000F +S315E6320DB020081000FFFFFFFF200801102008061862 +S315E6320DC02108080022082000FFFFFFFF23080A0059 +S315E6320DD023080610230807182408080024080808FA +S315E6320DE024080A10250807002508080825080810E9 +S315E6320DF02508031826080A0026080A1027081100CD +S315E6320E0028080900280809102908100029080E10B2 +S315E6320E102A080E002A080C102B080A002B080A109C +S315E6320E202C0802002D0820002E080B002E080B1087 +S315E6320E302F08200030081200310820003208200040 +S315E6320E40FFFFFFFFFFFFFFFF33080100330801080C +S315E6320E503308081034080C0034080C1035080C0038 +S315E6320E6035080C1036080C0036080C1037080C001C +S315E6320E7037080C1038080C0038080C1039080C0004 +S315E6320E8039080B10FFFFFFFFFFFFFFFF3A080B00A3 +S315E6320E903A080B103B080B003B080B103C080B00DC +S315E6320EA03C080B103D080B003D080B103E080B00C4 +S315E6320EB03E080A10FFFFFFFF3F080A003F080A1006 +S315E6320EC040080A0040080A1041080A0041080A109A +S315E6320ED042080A0042080A1043080A0043080A1082 +S315E6320EE044080A0044080A1045080A0045080A106A +S315E6320EF046080A0046080A1047080A0047080A1052 +S315E6320F0048080A0048080A1049080A0049080A1039 +S315E6320F104A080A004A080A104B080A004B080A1021 +S315E6320F204C080A004C080A104D0804004D0803081E +S315E6320F304D080A104E080A004E0801104F080A00FC +S315E6320F404F08041050080B0050080A10FFFFFFFF47 +S315E6320F5051080800510808085108081051080818BF +S315E6320F6052080800FFFFFFFF520808085208011030 +S315E6320F7052080818530808005308020853080210A4 +S315E6320F805308041854080400FFFFFFFF5408040808 +S315E6320F9054080A105508060055080808FFFFFFFFF1 +S315E6320FA0550804105508041856080500560804086C +S315E6320FB05608051057080A0057080A105808080056 +S315E6320FC0FFFFFFFF58080408FFFFFFFFFFFFFFFFA3 +S315E6320FD0000A0500000A0508000A0510000A051887 +S315E6320FE0010A0500010A0508010A0B10020A010088 +S315E6320FF0020A0308030A2000FFFFFFFF040A030082 +S315E6321000040A0A08FFFFFFFFFFFFFFFF040A031881 +S315E6321010050A0300050A0108050A0110050A06183B +S315E6321020FFFFFFFFFFFFFFFFFFFFFFFF060A02009C +S315E6321030060A0308060A0110070A0F00080A200004 +S315E6321040090A20000A0A0B000A0A0B100B0A0B00E1 +S315E6321050FFFFFFFFFFFFFFFF0C0A18000D0A18001D +S315E63210600E0A18000F0A18000F0A0418100A0200B0 +S315E6321070100A0208100A0410100A0418110A0100AE +S315E6321080110A0108110A0110110A0318120A200080 +S315E6321090130A2000FFFFFFFF140A1400150A140094 +S315E63210A0160A1400170A1400180A1400190A14004C +S315E63210B01A0A14001B0A14001C0A1E001D0A0A002C +S315E63210C01D0A06101D0A06181E0A0600FFFFFFFF56 +S315E63210D01E0A06081F0A08001F0A0B08200A0B001A +S315E63210E0200A0B10210A0B00210A0B10220A0B00EA +S315E63210F0220A0410230A0A00230A0610230A0818CB +S315E6321100FFFFFFFF240A0400FFFFFFFFFFFFFFFF9B +S315E6321110800B0100800B0208800B0510800B051848 +S315E6321120810B0500810B0508810B0B10820B05003E +S315E6321130820B0108820B0110FFFFFFFF820B0118BB +S315E6321140830B0100830B0408830B0B10840B0B0015 +S315E6321150FFFFFFFF840B0410850B0B00850B041093 +S315E6321160850B0118860B0100860B0108870B2000DA +S315E6321170880B2000890B0800890B0A08890B0518AB +S315E63211808A0B0A008A0B03108A0B03188B0B0100B3 +S315E63211908B0B02088B0B01108B0B01188C0B0100A3 +S315E63211A08C0B0308FFFFFFFF8C0B04108C0B041825 +S315E63211B08D0B04008D0B0408FFFFFFFFFFFFFFFFD9 +S315E63211C0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF11 +S315E63211D0FFFFFFFFFFFFFFFFFFFFFFFF8E0B0D0057 +S315E63211E08E0B0D108F0B0D00900B0500910B010047 +S315E63211F0910B0E08920B0E00920B0E10930B0E000D +S315E6321200930B0E10940B0400940B0408940B041003 +S315E6321210940B0418950B0400950B0B08960B0B00F2 +S315E6321220960B0B10970B0B00FFFFFFFFFFFFFFFF3F +S315E6321230FFFFFFFFFFFFFFFF980B0D00980B0D1028 +S315E6321240990B0D00990B10108D0B08108D0B0818A3 +S315E63212509A0B10009A0B10109B0B10009B0B10107A +S315E63212609C0B10009C0B03109C0B04189D0B010083 +S315E63212709D0B0408FFFFFFFFFFFFFFFF9D0B0110EB +S315E63212809E0B14009F0B0A009F0B0C10A00B12004C +S315E6321290A10B1400A20B1200A30B1100A40B110032 +S315E63212A0A50B1200A60B1200A70B1200A80B120012 +S315E63212B0A90B1200AA0B1200AB0B1200AC0B1200F2 +S315E63212C0FFFFFFFFFFFFFFFFAD0B1900AE0B190065 +S315E63212D0AF0B2000B00B1700B00B0818B10B0100AC +S315E63212E0B10B0108B20B2000B30B0800FFFFFFFF7C +S315E63212F0B30B0308B40B1800B50B1800FFFFFFFF5C +S315E6321300FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCF +S315E6321310FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBF +S315E6321320FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAF +S315E6321330FFFFFFFFFFFFFFFFB60B1000B60B0110F4 +S315E6321340B60B0118B70B0500B80B2000B90B09002E +S315E6321350FFFFFFFFFFFFFFFFBA0B2000BB0B0400C8 +S315E6321360BB0B1008BB0B0618BC0B1000FFFFFFFFCA +S315E6321370BC0B0810FFFFFFFFFFFFFFFFFFFFFFFF7C +S315E6321380BC0B0318BD0B0200FFFFFFFFBE0B2000AE +S315E6321390BF0B0B00FFFFFFFFFFFFFFFFFFFFFFFF66 +S315E63213A0BF0B0210FFFFFFFFFFFFFFFFFFFFFFFF4F +S315E63213B0FFFFFFFF000201000002040800021010E0 +S315E63213C00102010001020108FFFFFFFFFFFFFFFFF7 +S315E63213D001021010FFFFFFFFFFFFFFFFFFFFFFFFD8 +S315E63213E0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEF +S315E63213F0FFFFFFFFFFFFFFFF02022000030210009E +S315E63214000402200005021000060220000702100040 +S315E63214100702101008022000090220000A02200004 +S315E63214200B0220000C0210000D0220000E022000F4 +S315E63214300F022000100220001102100012022000D4 +S315E632144013022000140220001502200016020900BB +S315E632145016020110170220001802050018020108CA +S315E6321460180208101802081819021E001A021E007F +S315E63214701B021E001C021E001D021E001E021E005C +S315E63214801F021E0020021E0021021E0022021E003C +S315E632149023021E0024021E0025021E0026021E001C +S315E63214A027021E0028021E0029020100290201082F +S315E63214B029020110290204182A0208002A0208081B +S315E63214C02A0208102A0204182B0205002B02060805 +S315E63214D02B0207102B0205182C0206002C020708EF +S315E63214E02C0205102C0206182D0207002D020208E0 +S315E63214F02D020110FFFFFFFF2E020A002E02101008 +S315E63215002F020A002F02101030020A0030021010A3 +S315E6321510FFFFFFFF31021000FFFFFFFFFFFFFFFF76 +S315E6321520310201103102011832020100320201089B +S315E63215303202011032020118330202003302020885 +S315E6321540330202103302021834020200340203086E +S315E6321550340201103402011835020100350201085F +S315E6321560FFFFFFFF3502021035020118360201008F +S315E6321570FFFFFFFF36020208360201103602011875 +S315E6321580FFFFFFFF3702020037020108370201107A +S315E6321590FFFFFFFF3702021838020700380201085A +S315E63215A038020110380201183902010039020108FF +S315E63215B039020110FFFFFFFF390201183A02040031 +S315E63215C03A0204083A0204103A0201183B020200D1 +S315E63215D03B0206083B020610FFFFFFFFFFFFFFFF57 +S315E63215E0FFFFFFFF3B0202183C0210003C020110ED +S315E63215F03C020118FFFFFFFF3D0204003D020108EF +S315E63216003D0204103D0202183E020800FFFFFFFFCC +S315E6321610FFFFFFFFFFFFFFFF3E020A083F02200001 +S315E6321620400220004102050041020108410205104E +S315E6321630410208184202010042020808420201103B +S315E63216404202081843020100430204084302041028 +S315E63216504302041844020400440204084402041015 +S315E63216604402041845020400450204084502041001 +S315E632167045020118460204004602040846020410F0 +S315E632168046020418470204004702040847020610D7 +S315E632169047020618480206004802060848020610BD +S315E63216A048020618490204004902010849020110B5 +S315E63216B049020218FFFFFFFFFFFFFFFFFFFFFFFFB3 +S315E63216C0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0C +S315E63216D0FFFFFFFF4A0204004A0204084A020110EB +S315E63216E04A020118FFFFFFFF4B0201004B020108D7 +S315E63216F0FFFFFFFF4B0201104B0201184C020100BD +S315E63217004C0204084C0204104D020A004E02200036 +S315E63217104F0204004F020808FFFFFFFFFFFFFFFFFD +S315E6321720FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAB +S315E63217304F0202104F0202185002200051020200F6 +S315E632174051021008520210005202041052020418D4 +S315E63217505302050053020508FFFFFFFFFFFFFFFFB7 +S315E6321760FFFFFFFFFFFFFFFF53020110530201188F +S315E632177054020800540208085402081054020818A3 +S315E6321780550208005502080855020810550208188F +S315E6321790560208005602080856020810FFFFFFFFF7 +S315E63217A0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF2B +S315E63217B0FFFFFFFF560203185702010057020208DF +S315E63217C0570201105702041858020200580201085D +S315E63217D058020110FFFFFFFF5802011859020400B2 +S315E63217E05902080859020A105A020A005A020A101F +S315E63217F05B020A005B020A105C020A005D02200006 +S315E63218005E0220005F020100FFFFFFFFFFFFFFFFE0 +S315E6321810FFFFFFFF5F0202085F020210600210005E +S315E632182060020510600206186102050061020508CB +S315E632183061020E106202050062020E0862020518A5 +S315E632184063020E00630205106302011864020500A4 +S315E63218506402050864020A1065020A00650205108A +S315E63218606502051866020A0066020A106702050074 +S315E63218706702050867020A1068020A00FFFFFFFFE1 +S315E6321880FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4A +S315E6321890FFFFFFFF680207106802071869020400B5 +S315E63218A069020408FFFFFFFFFFFFFFFFFFFFFFFFAF +S315E63218B069020410690208186A0208006A02040814 +S315E63218C0FFFFFFFFFFFFFFFFFFFFFFFF6A02041086 +S315E63218D0FFFFFFFFFFFFFFFFFFFFFFFF6A0204186E +S315E63218E0FFFFFFFFFFFFFFFFFFFFFFFF6B02040075 +S315E63218F06B0205086B0207106B0208186C021000C1 +S315E63219006C0208106D0210006D0208106E021000AD +S315E63219106E0208106E0208186F0201006F020108A5 +S315E63219206F0206106F02061870020600FFFFFFFF0F +S315E63219307002010870020310FFFFFFFFFFFFFFFF91 +S315E6321940FFFFFFFF71020A0071020A1072020400FB +S315E63219507202010872020410FFFFFFFFFFFFFFFF6C +S315E6321960FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF69 +S315E6321970720207187302070073020508730205102E +S315E6321980FFFFFFFFFFFFFFFFFFFFFFFF73020418B4 +S315E63219907402010074020108740202107402081815 +S315E63219A0750220007602200077021000FFFFFFFF65 +S315E63219B0FFFFFFFFFFFFFFFF7702021077020118F4 +S315E63219C0FFFFFFFF78020200780210087902100064 +S315E63219D0790210107A0208007A0208087A020810AA +S315E63219E0FFFFFFFF7B0210007B0210107C02100025 +S315E63219F07C0208107C0208187D020800FFFFFFFF12 +S315E6321A007D0210087E0210007E0210107F02080068 +S315E6321A107F0208087F020810FFFFFFFF7F020818E1 +S315E6321A208002100080021010810210008102081036 +S315E6321A308102081882020800FFFFFFFF82021008C1 +S315E6321A40830210008302101084020800840208081A +S315E6321A5084020810FFFFFFFF850210008502101090 +S315E6321A6086021000860208108602081887020800E7 +S315E6321A70FFFFFFFF87020808870210108802100070 +S315E6321A8088021010890208008902080889020810BD +S315E6321A90FFFFFFFF8A0210008A0210108B02100047 +S315E6321AA08B0208108B0208188C020800FFFFFFFF34 +S315E6321AB08C0210088D0210008D0210108E0208007C +S315E6321AC08E0208088E020810FFFFFFFF8E02081804 +S315E6321AD08F0210008F02101090021000900208104A +S315E6321AE09002081891020800FFFFFFFF91021008E4 +S315E6321AF0920210009202101093020800930208082E +S315E6321B0093020810FFFFFFFF9402100094021010B2 +S315E6321B1095021000950208109502081896020800FA +S315E6321B20FFFFFFFF96020808960202109602031896 +S315E6321B3097020A0097020A1098020A0098020510DE +S315E6321B4098020418990208009902080899020610C2 +S315E6321B50990206189A0211009A0208189B020400A4 +S315E6321B609B020608FFFFFFFF9B0206109B02081840 +S315E6321B709C0208009C0204089C0208109C02081883 +S315E6321B809D0206009D0206089E0211009E02081874 +S315E6321B909F0204009F020608FFFFFFFF9F02061020 +S315E6321BA09F020818A0020800A0020408A002081044 +S315E6321BB0A0020818A1020600A1020608A202110036 +S315E6321BC0A2020818A3020400A3020608FFFFFFFFDB +S315E6321BD0A3020610A3020818A4020800A402040807 +S315E6321BE0A4020410A4020418A5020400A5020408FD +S315E6321BF0A5020410A5020418A6020400A6020408E9 +S315E6321C00A6020410A6020418A7020400A7020408D4 +S315E6321C10A7020410A7020418A8020400A8020408C0 +S315E6321C20A8020410A8020418A9020400A90212089E +S315E6321C30AA021100AB021200AC022000AD0220006D +S315E6321C40AE022000AF022000B0022000B102200030 +S315E6321C50B2022000B3022000B4022000B50203002D +S315E6321C60B5020508B5020510B5020118B602050039 +S315E6321C70B6020508B6020510B6020518B702050021 +S315E6321C80B7020508B7020510B7020518B80205000D +S315E6321C90B8020508B8020510B8020518B9020500F9 +S315E6321CA0B9020508B9020510B9020518BA020500E5 +S315E6321CB0BA020508BA020510BA020518BB020500D1 +S315E6321CC0BB020508BB020110BB020218BC020200C7 +S315E6321CD0BC020208BC020210BC020118BD020400B4 +S315E6321CE0BD021008BE022000BF021000C00220006C +S315E6321CF0C1021000C2022000C3020700C302010875 +S315E6321D00C3020210C3020618C4020100C402010865 +S315E6321D10C5022000C6020300C7022000C802200020 +S315E6321D20FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA5 +S315E6321D30FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF95 +S315E6321D40FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF85 +S315E6321D50FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF75 +S315E6321D60FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF65 +S315E6321D70FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF55 +S315E6321D80FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF45 +S315E6321D90FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF35 +S315E6321DA0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF25 +S315E6321DB0FFFFFFFFFFFFFFFFC9020400FFFFFFFF42 +S315E6321DC0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF05 +S315E6321DD0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5 +S315E6321DE0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE5 +S315E6321DF0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD5 +S315E6321E00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC4 +S315E6321E10FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB4 +S315E6321E20FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA4 +S315E6321E30FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF94 +S315E6321E40FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF84 +S315E6321E50FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF74 +S315E6321E60FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF64 +S315E6321E70FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF54 +S315E6321E80FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF44 +S315E6321E90000420000104040001040B0802040A00CF +S315E6321EA002040210020401180304050003040508BD +S315E6321EB003040510030405180404050004040508A2 +S315E6321EC0040405100404051805040500050404088F +S315E6321ED0050403100604180006040318070418005E +S315E6321EE0070402180804010008040208080401106F +S315E6321EF00804011809040200090404080904041056 +S315E6321F0009040418FFFFFFFF0A040400FFFFFFFF80 +S315E6321F10FFFFFFFF0A0409080A0401180B04200032 +S315E6321F200C041C000D0401000D0407080D0409100B +S315E6321F300E040A000E0405100E0401180F040110F1 +S315E6321F400F0402180F0409001004090010040210E7 +S315E6321F50110420001204010012040208FFFFFFFFFB +S315E6321F60FFFFFFFFFFFFFFFFFFFFFFFF1304200028 +S315E6321F70140420001504200016042000170403007A +S315E6321F80170401081704041017040318180404008A +S315E6321F901804040818040410180404181904010075 +S315E6321FA0190401081904061019040418FFFFFFFF85 +S315E6321FB01A0406001A0404081A0406101A04041847 +S315E6321FC01B0402001B0405081B040810FFFFFFFF73 +S315E6321FD01B0406181C0403001C040B081C04041814 +S315E6321FE01D0404001D0404081D040110FFFFFFFF53 +S315E6321FF01E0409001F0420002004200021042000CC +S315E63220002204200023041000FFFFFFFF2304011001 +S315E632201023040618240408002504200026041000AA +S315E632202026040A10270406002704070827040810A0 +S315E63220302704081828040A00280407102804081872 +S315E6322040290408002904030829040A102A040A0086 +S315E63220502B0411002C0409002C0409102D0410005F +S315E63220602D040E102E040E002F04120030040A0040 +S315E632207030040A10310402003204200033040B0025 +S315E632208033040B10340420003504120036042000E3 +S315E632209037042000380408003804010838040110F1 +S315E63220A0380401183904080039040C083A040C00DD +S315E63220B03A040C103B040C003B040C103C040C00B6 +S315E63220C03C040C103D040C003D040C103E040C009E +S315E63220D03E040C103F040B003F0409104004010095 +S315E63220E041040B0041040B1042040B0042040B1070 +S315E63220F043040B0043040B1044040B0044040B1058 +S315E632210045040B0045040A104604020046040A0852 +S315E632211047040A0047040A1048040A0048040A102B +S315E632212049040A0049040A104A040A004A040A1013 +S315E63221304B040A004B040A104C040A004C040A10FB +S315E63221404D040A004D040A104E040A004E040A10E3 +S315E63221504F040A004F040A1050040A0050040A10CB +S315E632216051040A0051040A1052040A0052040A10B3 +S315E632217053040A0053040A1054040A0054040410A1 +S315E63221805404031855040A0055040A10560401008D +S315E632219056040A085604041857040B0057040A1064 +S315E63221A0580403005904080059040808590408106B +S315E63221B0590408185A040800FFFFFFFF5A040808B4 +S315E63221C05A0401105A0408185B0408005B04020834 +S315E63221D05B0402105B0405185C040500FFFFFFFF93 +S315E63221E05C0404085C040A105D0406005D04080813 +S315E63221F05D0408105D0404185E0404005E040508F6 +S315E63222005E0404105E0405185F040A005F040A10D1 +S315E632221060040800FFFFFFFF60040408FFFFFFFFCC +S315E6322220FFFFFFFF0006050000060508000605105B +S315E632223000060518010605000106050801060B101B +S315E63222400206010002060308030620000406100011 +S315E63222500406041005060A000506091006060800F5 +S315E632226006060308060603100606011807060100E7 +S315E632227007060708070607100706051808060100C7 +S315E632228008060208080603100806011809060F00B2 +S315E63222900A0620000B0620000C060B000C060B1075 +S315E63222A00D060B000E0618000F061800FFFFFFFF9D +S315E63222B0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF10 +S315E63222C00F0602181006020010060408100604105D +S315E63222D0100601181106010011060108110603104F +S315E63222E01206200013062000FFFFFFFF1406140035 +S315E63222F015061400160614001706140018061400FE +S315E6322300190614001A0614001B0614001C061800D9 +S315E63223101D060A001D0606101D0606181E060600CE +S315E6322320FFFFFFFF1E0606081F0608001F060B08FC +S315E632233020060B0020060B1021060B0021060B1099 +S315E632234022060B002206041023060A00230606108E +S315E63223502306081824060800240604088006020026 +S315E632236081060100810601088106021081060518FA +S315E632237082060500820605088206051083060B00EC +S315E6322380830605108306011884060100FFFFFFFF68 +S315E632239084060108840601108406041885060B00B5 +S315E63223A085060B1086060B008606041087060B009A +S315E63223B08706041087060118880601008806010892 +S315E63223C0890620008A0620008B0608008B060A0854 +S315E63223D08B0605188C060A008C0603108C06031843 +S315E63223E08D0601008D0602088D0601108D0601184E +S315E63223F08E0601008E0602088E0601108F0604004E +S315E63224008F0604088F0604108F060418900601001C +S315E632241090060108900601109106200092062000E9 +S315E63224209306200094062000FFFFFFFF8E06011872 +S315E632243096060D0096060D1097060D0098060500CF +S315E63224409906010099060E089A060E009A060E10AD +S315E63224509B060E009B060E109C0604009C0604089C +S315E63224609C0604109C0604189D0604009D060B087D +S315E63224709E060B009E060B109F060B00FFFFFFFF24 +S315E6322480FFFFFFFFFFFFFFFFFFFFFFFFA0060D0087 +S315E6322490A0060D10A1060D00A1061010950608003D +S315E63224A095060808A2061000A2061010A30610002A +S315E63224B0A3061010A4061000A4060310A4060418F8 +S315E63224C0A5060100A5060808A5060110A506051803 +S315E63224D0A6060100A6061408A7060A00A7060C10E9 +S315E63224E0A8061200A9061400AA061200AB061100C7 +S315E63224F0AC061100AD061200AE061200AF061200A9 +S315E6322500B0061200B1061200B2061200B306120087 +S315E6322510B4061200B5061200B6061200B7060E006B +S315E6322520B7060D10B8062000B9061700BA06090036 +S315E6322530BA060110BA060118BB062000BC06080028 +S315E6322540BC060308BC060310BD061800BE06180014 +S315E6322550BE060718BF060500BF060808BF060810FE +S315E6322560BF060818C0060100C0060108C1062000EB +S315E6322570FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4D +S315E6322580FFFFFFFFFFFFFFFFFFFFFFFFC206100061 +S315E6322590C2060110C2060118C3060200C3060408C3 +S315E63225A0C3060910C4060700C4060408C506200099 +S315E63225B0C6060100C6060208C6060610C70610009B +S315E63225C0C7060110C8062000C9060800C906010872 +S315E63225D0C9060510FFFFFFFFC9060218CA06010043 +S315E63225E0CB062000CC060B00CC060110CC0603182F +S315E63225F0CD060800CD060208CD060C10CE0604003E +S315E6322600CE060108FFFFFFFF0002010000020408C2 +S315E63226100002101001020100010201080102011056 +S315E6322620FFFFFFFF0202100002020810FFFFFFFF64 +S315E6322630FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8C +S315E6322640FFFFFFFFFFFFFFFFFFFFFFFF0302200053 +S315E632265004021000050220000602100007022000DE +S315E632266008021000090214000A0220000B022000BA +S315E63226700C0220000D0220000E0214000F0220008A +S315E6322680100220001102200012022000130214006A +S315E6322690140220001502200016022000170220003E +S315E63226A01802090018020110190220001A02050062 +S315E63226B01A0201081A0208101A0208181B021C002E +S315E63226C01C021C001D021C001E021C001F021C00FE +S315E63226D020021C0021021C0022021C0023021C00DE +S315E63226E024021C0025021C0026021C0027021C00BE +S315E63226F028021C0029021C002A021C002B020100B9 +S315E63227002B0201082B0201102B0204182C020800B8 +S315E63227102C0208082C0208102C0204182D02070097 +S315E6322720FFFFFFFF2D0207082D020710FFFFFFFF0F +S315E63227302D0207182E020700FFFFFFFF2E020708BB +S315E63227402E0202102E0201182F0201002F020A086B +S315E63227503002140031020A003202140033020A0051 +S315E6322760340214003402011835021000350205101F +S315E63227703502011836020100360201083602011028 +S315E63227803602011837020100370201083702021013 +S315E632279037020218380202003802020838020210FC +S315E63227A038020318390201003902010839020110EA +S315E63227B039020118FFFFFFFF3A0202003A02010828 +S315E63227C03A020110FFFFFFFF3A0202183B0201000E +S315E63227D03B020108FFFFFFFF3B0202103B020118F4 +S315E63227E03C020100FFFFFFFF3C0202083C020710F3 +S315E63227F03C0201183D0201003D0201083D0201108C +S315E63228003D0201183E0201003E0201083E02011077 +S315E63228103E0204183F0204003F0204083F0201105A +S315E63228203F02021840020600400206084002021043 +S315E63228304002021841020200FFFFFFFF4102100882 +S315E63228404102011842020100420201084202041024 +S315E63228504202011843020400430202084302081008 +S315E6322860FFFFFFFFFFFFFFFFFFFFFFFF44020A0006 +S315E632287045022000460220004702050047020108CB +S315E632288047020510470208184802010048020808BE +S315E632289048020110480208184902010049020408B2 +S315E63228A049020410490204184A0204004A0204089C +S315E63228B04A0204104A0204184B0204004B02040888 +S315E63228C04B0204104B0201184C0204004C02040877 +S315E63228D04C0204104C0204184D0204004D02040860 +S315E63228E04D0206104D0206184E0206004E02060844 +S315E63228F04E0206104E020618FFFFFFFF4F02010098 +S315E63229004F0201084F020210FFFFFFFFFFFFFFFFF4 +S315E6322910FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA9 +S315E6322920FFFFFFFFFFFFFFFF4F02041850020400CE +S315E632293050020108500201105002011851020100FC +S315E632294051020108510201105102011852020100E8 +S315E632295052020108520204105202041853020A00C5 +S315E632296054022000550204005502080855020210A8 +S315E632297055020218560202005602020856020210A2 +S315E632298056020218FFFFFFFFFFFFFFFF5702200046 +S315E63229905802020058021008590210005902041071 +S315E63229A0590204185A0205005A0205085B0220004B +S315E63229B05C0220005D0220005E0220005F0201001A +S315E63229C05F0201085F0207105F020718600207001E +S315E63229D06002070860020710600207186102070004 +S315E63229E061020708610207106102071862020700F0 +S315E63229F062020708620207106202071863020300E0 +S315E6322A006302030863020310FFFFFFFF6302011846 +S315E6322A1064020200640201086402041064020218C7 +S315E6322A2065020100650201086502011065020118B8 +S315E6322A30660204006602080866020A1067020A009F +S315E6322A4067020A1068020A0068020A1069020A0078 +S315E6322A506A0220006B0220006C0201006C02020858 +S315E6322A606C0202106C020218FFFFFFFF6D020200D3 +S315E6322A706D0210086D0205186E0206006E02050832 +S315E6322A806E0205106F020E006F02051070020E001E +S315E6322A907002051071020E007102051071020118FC +S315E6322AA0720205007202050872020A1073020A0001 +S315E6322AB0730205107302051874020A0074020A10CC +S315E6322AC0750205007502050875020A1076020A00D5 +S315E6322AD0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE8 +S315E6322AE0FFFFFFFFFFFFFFFF7602071076020718AA +S315E6322AF07702040077020408FFFFFFFFFFFFFFFFBE +S315E6322B00FFFFFFFF77020410770208187802080003 +S315E6322B1078020408FFFFFFFFFFFFFFFFFFFFFFFF1D +S315E6322B2078020410FFFFFFFFFFFFFFFFFFFFFFFF05 +S315E6322B3078020418FFFFFFFFFFFFFFFFFFFFFFFFED +S315E6322B407902040079020508790207107902081833 +S315E6322B507A0210007A0208107B0210007B02081015 +S315E6322B607C0210007C0208107C0208187D02010005 +S315E6322B707D0201087D0206107D0206187E020600F7 +S315E6322B807E0201087E0201107E0203187F020A00E7 +S315E6322B907F020A1080020A00FFFFFFFF80020A1058 +S315E6322BA0810204008102010881020410FFFFFFFF61 +S315E6322BB0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF07 +S315E6322BC0FFFFFFFF8102071882020700820205082D +S315E6322BD082020510FFFFFFFFFFFFFFFFFFFFFFFF4A +S315E6322BE0820204188302010083020108830202107C +S315E6322BF0830208188402200085022000860210002D +S315E6322C00860202108602021887020200FFFFFFFFE3 +S315E6322C108702010887020110870202188802080035 +S315E6322C20880208088802081088020818890208000D +S315E6322C3089020808FFFFFFFF890208108902081891 +S315E6322C408A0208008A0208088A0208108A020818E6 +S315E6322C50FFFFFFFF8B0208008B0208088B02081083 +S315E6322C608B0208188C0208008C020808FFFFFFFF69 +S315E6322C708C0208108C0208188D0208008D020808AC +S315E6322C808D0208108D0208188E020800FFFFFFFF3C +S315E6322C908E0208088E0208108E0208188F02080085 +S315E6322CA08F0208088F020810FFFFFFFF8F0208180F +S315E6322CB0900208009002080890020810900208185E +S315E6322CC091020800FFFFFFFF910208089102081001 +S315E6322CD09102081892020800920208089202081037 +S315E6322CE092020818FFFFFFFF9302080093020808D4 +S315E6322CF09302081093020818940208009402080810 +S315E6322D00FFFFFFFF940208109402081895020800A6 +S315E6322D10950208089502081095020818FFFFFFFF8C +S315E6322D2096020800960208089602081096020818D5 +S315E6322D30970208009702080897020810FFFFFFFF7E +S315E6322D4097020818980208009802080898020810AE +S315E6322D509802081899020800FFFFFFFF9902080851 +S315E6322D6099020810990208189A0208009A02080887 +S315E6322D709A020810FFFFFFFF9A0208189B0202002A +S315E6322D809B0203089B020A109C020A009C020A1066 +S315E6322D909D0205009D0208089D0208109D0208184C +S315E6322DA09E0206009E0206089F0211009F0208183E +S315E6322DB0A0020400A0020608FFFFFFFFA0020610EB +S315E6322DC0A0020818FFFFFFFFA1020800A1020808C9 +S315E6322DD0A1020810A1020618A2020600A2021108F2 +S315E6322DE0A3020800A3020408A3020610FFFFFFFFB0 +S315E6322DF0A3020618A4020800FFFFFFFFA402080892 +S315E6322E00A4020810A4020818A5020600A5020608BE +S315E6322E10A6021100A6020818A7020400A7020608AF +S315E6322E20FFFFFFFFA7020610A7020818FFFFFFFF04 +S315E6322E30A8020400A8020408A8020410A80204188C +S315E6322E40A9020400A9020408A9020410A902041878 +S315E6322E50AA020400AA020408AA020410AA02041864 +S315E6322E60AB020400AB020408AB020410AB02041850 +S315E6322E70AC020400AC020408AC020410AC0204183C +S315E6322E80AD021200AE021100AF021200B00220000D +S315E6322E90B1022000B2022000B3022000B4022000C2 +S315E6322EA0B5022000B6022000B7022000B8022000A2 +S315E6322EB0B9020200B9020508B9020510B9020118CB +S315E6322EC0BA020400BA020408BA020410BA020418B4 +S315E6322ED0BB020400BB020408BB020410BB020418A0 +S315E6322EE0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD4 +S315E6322EF0FFFFFFFFFFFFFFFFBC020400BC02040830 +S315E6322F00BC020410BC020418BD020400BD02040869 +S315E6322F10BD020410BD020418BE020100BE0202085A +S315E6322F20BE020210BE020218BF020200BF0201084A +S315E6322F30BF020410C0021000C1022000C202100015 +S315E6322F40C3022000C4021000C5022000C6020700F2 +S315E6322F50C6020108C6020210C6020618C7020100F8 +S315E6322F60C7020108C8022000C9020200CA022000CE +S315E6322F70CB022000CC020C00CC020C10CD02200093 +S315E6322F80CE020300CF022000D0020300D102200097 +S315E6322F90D2020300D3022000D4020300D502200077 +S315E6322FA0D6020300D7022000D8020300D902200057 +S315E6322FB0DA020300DB022000DC020300DD02200037 +S315E6322FC0DE020300DF022000E0020300E00203082D +S315E6322FD0E0020210E0020218E1022000E2022000DC +S315E6322FE0E3022000E4022000E5020400E6021E00C7 +S315E6322FF0E7021E00E8021E00E9021E00EA021E0091 +S315E6323000EB021E00EC021E00ED021E00EE0204008A +S315E6323010FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA2 +S315E6323020EE020408EE020110EE020818EF02040080 +S315E6323030EF020108EF020810EF020418F00201006F +S315E6323040F0020808F0020410F0020118F102080054 +S315E6323050F1020408F1020110F1020818F202040044 +S315E6323060F2020108F2020810F2020418F302010033 +S315E6323070F3020808F3020410F3020118F402080018 +S315E6323080F4020808F4020110F4020518FFFFFFFF06 +S315E6323090FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF22 +S315E63230A0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF12 +S315E63230B0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF02 +S315E63230C0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF2 +S315E63230D0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE2 +S315E63230E0FFFFFFFF000820000108040001080B0875 +S315E63230F002080A000208021002080118030806004E +S315E6323100030806080308061003080618040806002C +S315E63231100408060804080510040806180508060019 +S315E632312005080408050803100608180006080318F9 +S315E632313007081800070802185E08010808080200A0 +S315E632314008080108080801100808021809080500E7 +S315E63231500908050809080410FFFFFFFF09080418E5 +S315E63231600A0802000A0805080A0809100B080100CF +S315E63231700C0820000D081C000E0801000E08070890 +S315E63231800E0809100F080A000F0805100F08011875 +S315E63231901008011010080218100809001108090073 +S315E63231A0110802101208200013080100130802085B +S315E63231B014082000150820001608200017082000FB +S315E63231C0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1 +S315E63231D01808030018080108180804101808031816 +S315E63231E019080400190804081908041019080418FD +S315E63231F01A0801001A0801081A0806101A080418ED +S315E63232001B0808001B0806081B0804101B080618CC +S315E63232101C0804001C0802081C0805101C080818BD +S315E6323220FFFFFFFF1D0806001D0803081D080B10E9 +S315E63232301E0804001E0804081E0804101E0801189B +S315E6323240FFFFFFFF1F0809002008200021082000A3 +S315E6323250220820002308200024081000FFFFFFFF83 +S315E63232602408011024080618250808002608200036 +S315E63232702708100027080B10280807002808070831 +S315E6323280280809102908090029080B102A08070018 +S315E63232902A0808082A0809102B0803002B080A0808 +S315E63232A02C080A002D0811002E080A002E080A10EC +S315E63232B02F0810002F080E1030080E0031081200C3 +S315E63232C032080A0032080A103308020034082000AF +S315E63232D035080B0035080B10360820003708130080 +S315E63232E038082000390820003A0808003A0801086A +S315E63232F03A0801103A0801183B0808003B080C0860 +S315E63233003C080C003C080C103D080C003D080C103D +S315E63233103E080C003E080C103F080C003F080C1025 +S315E632332040080C0040080C1041080B004108091011 +S315E63233304208010043080B0043080B1044080B0011 +S315E632334044080B1045080B0045080B1046080B00DF +S315E632335046080B1047080B0047080A1048080200D1 +S315E632336048080A0849080A0049080A104A080A00BB +S315E63233704A080A104B080A004B080A104C080A009B +S315E63233804C080A104D080A004D080A104E080A0083 +S315E63233904E080A104F080A004F080A1050080A006B +S315E63233A050080A1051080A0051080A1052080A0053 +S315E63233B052080A1053080A0053080A1054080A003B +S315E63233C054080A1055080A0055080A1056080A0023 +S315E63233D0560804105608031857080A0057080A1002 +S315E63233E05808010058080A085808041859080B0004 +S315E63233F059080A105A0803005B0808005B080808F1 +S315E63234005B0808105B0808185C0808005C080808C0 +S315E63234105C0808105C0801185D0808005D080808B3 +S315E63234205D0802105D0802185E0805005E080510A2 +S315E63234305E0805185F0804005F080B085F08061881 +S315E63234406008080060080808600804106008041876 +S315E632345061080600610804086108051062080A0078 +S315E632346062080A1063080800630801086308041054 +S315E63234706408020064080308000A0500000A050823 +S315E6323480000A0510000A0518010A0500010A0508B0 +S315E6323490010A0B10020A0100020A0308030A200097 +S315E63234A0040A1000040A0410050A0B00050A07107E +S315E63234B0060A0900060A0310060A0318070A010075 +S315E63234C0070A0108070A0710070A0718080A050055 +S315E63234D0080A0108080A0210080A0318090A01004E +S315E63234E0090A0F080A0A20000B0A20000C0A0B000A +S315E63234F00C0A0B100D0A0B000E0A18000F0A1800FA +S315E6323500FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAD +S315E6323510FFFFFFFF0F0A0218100A0200100A04081C +S315E6323520100A0410100A0118110A0100110A0108DC +S315E6323530110A0310120A2000130A2000FFFFFFFFCA +S315E6323540140A1400150A1400160A1400170A14008F +S315E6323550180A1400190A14001A0A14001B0A14006F +S315E63235601C0A1E001D0A0A001D0A06101D0A061846 +S315E63235701E0A06001E0A06081E0A06101F0A08005A +S315E63235801F0A0B08200A0B00200A0B10210A0B0031 +S315E6323590210A0B10220A0B00220A0410230A0B0018 +S315E63235A0230A0610230A0818240A0800240A0408FD +S315E63235B0800B0200810B0100810B0108810B0210A0 +S315E63235C0810B0518820B0500820B0508820B051066 +S315E63235D0830B0B00830B0510830B0118840B01005A +S315E63235E0840B0108840B0110840B0118850B040049 +S315E63235F0850B0B08860B0B00860B0B10870B04002C +S315E6323600870B0B08870B0418880B0100880B010819 +S315E6323610880B0110890B20008A0B20008B0B0800E1 +S315E63236208B0B0A088B0B05188C0B0B008C0B0310D5 +S315E63236308C0B03188D0B01008D0B02088D0B0110D6 +S315E63236408D0B01188E0B0100FFFFFFFF8E0B010873 +S315E63236508E0B04188F0B04008F0B04088F0B0410A5 +S315E63236608F0B0118900B0100900B0108910B20008D +S315E6323670920B2000930B2000940B2000FFFFFFFFF6 +S315E63236808E0B0110960B0D00960B0D10970B0D0057 +S315E6323690980B0500990B0100990B0E089A0B0E0052 +S315E63236A09A0B0E109B0B0E009B0B0E109C0B040016 +S315E63236B09C0B04089C0B04109C0B04189D0B04000F +S315E63236C09D0B0B089E0B0B009E0B0B109F0B0B00F4 +S315E63236D0A00B0400A00B0408A00B0410A00B0418E0 +S315E63236E0A10B0D00A10B0D10A20B0D00A20B1010B3 +S315E63236F0950B0800950B0808A30B1000A30B1010C8 +S315E6323700A40B1000A40B1010A50B1000A50B03108A +S315E6323710A50B0418A60B0100A60B0808A60B01108A +S315E6323720A70B0A00A70B0110A80B1400A90B0B0076 +S315E6323730A90B0C10AA0B1200AB0B1400AC0B120041 +S315E6323740AD0B1100AE0B1100AF0B1200B00B12002F +S315E6323750B10B1200B20B1200B30B1200B40B12000D +S315E6323760B50B1200B60B1200B70B1200B80B1200ED +S315E6323770B90B0E00B90B0D10BA0B2000BB0B1700B6 +S315E6323780BC0B0D00BC0B0110BC0B0118BD0B2000A7 +S315E6323790BE0B0800BE0B0308BE0B0310BF0B1800A8 +S315E63237A0C00B1800C00B0718C10B0700C10B08087F +S315E63237B0C10B0810C10B0818C20B0100C20B010877 +S315E63237C0C30B2000C40B0700C40B1408C50B140048 +S315E63237D0C60B1900C70B1700C80B1100C90B11002F +S315E63237E0CA0B1000CA0B0110CA0B0118CB0B02002A +S315E63237F0CB0B0408CB0B0910CC0B0700CC0B040819 +S315E6323800CD0B2000CE0B0100CE0B0208CE0B0610F6 +S315E6323810CF0B1000CF0B0110D00B2000D10B0800D6 +S315E6323820D10B0108D10B0510D10B0318D20B0200CE +S315E6323830FFFFFFFFD30B2000D40B0B00FFFFFFFF8A +S315E6323840D40B0310D40B0818D50B0200D50B0C0893 +S315E6323850D50B0418D60B0100D60B0508000201007B +S315E632386000020408000210100102010001020108FA +S315E632387001020110010201180202100002020810CA +S315E6323880020201180302200004022000050220008B +S315E632389006022000070202000702010807020110AB +S315E63238A008022000090214000A0220000B02140064 +S315E63238B00C0220000D0214000E0214000F02200044 +S315E63238C01002200011022000120220001302140018 +S315E63238D014022000150220001602200017022000EC +S315E63238E018021400190220001A0220001B022000D8 +S315E63238F01C0220001D0209001D0201101E022000D4 +S315E63239001F0205001F0201081F0208101F020818CF +S315E632391020021E0021021E0022021E0023021E0083 +S315E632392024021E0025021E0026021E0027021E0063 +S315E632393028021E0029021E002A021E002B021E0043 +S315E63239402C021E002D021E002E021E002F021E0023 +S315E6323950300201003002010830020110300204184A +S315E63239603102080031020808310208103102041821 +S315E6323970320207003202060832020710320207180E +S315E632398033020600330207083302071033020618FB +S315E632399034020700340202083402011034020118F6 +S315E63239A035020A003602140037020A0038021400DB +S315E63239B039020A003A021400FFFFFFFFFFFFFFFF5C +S315E63239C03B0205003C0201003C0201103C020118B2 +S315E63239D03D0201003D0201083D0201103D02011899 +S315E63239E03E0202003E0202083E0202103E02021881 +S315E63239F03F0202003F0203083F0201103F0201186E +S315E6323A00400201004002010840020110400202185B +S315E6323A104102010041020108410201104102021847 +S315E6323A204202010042020108420201104202021833 +S315E6323A30430201004302010843020110430202181F +S315E6323A40FFFFFFFF4402010044020108440201106F +S315E6323A5044020118450201004502010845020110F9 +S315E6323A6045020118460204004602040846020410DC +S315E6323A7046020118470202004702060847020610C6 +S315E6323A80470202184802020048020208FFFFFFFF19 +S315E6323A9048021010490201004902010849020110A2 +S315E6323AA0490204184A0201004A0204084A0203108D +S315E6323AB04A0208184B020A004B020A104C020A0066 +S315E6323AC0FFFFFFFF4D0220004E0220004F020500A7 +S315E6323AD03A0201183C0205084F0208084F02011065 +S315E6323AE04F0208185002010050020808500201102F +S315E6323AF0500204185102040051020408510204101D +S315E6323B005102041852020400520204085202041008 +S315E6323B1052020418530204005302010853020410F7 +S315E6323B2053020418540204005402040854020410E0 +S315E6323B3054020418550206005502060855020610C6 +S315E6323B4055020618560206005602060856020410B2 +S315E6323B50560201185702010057020208580220009F +S315E6323B60590220005A0220005B0220005C02200045 +S315E6323B705D0220005E0220005F0220006002040041 +S315E6323B806002040860020110600201186102010057 +S315E6323B906102010861020110610201186202010046 +S315E6323BA0620201086202011062020418630204002C +S315E6323BB063020A0864022000650204006502080808 +S315E6323BC06502021065020218660202006602020801 +S315E6323BD06602021066020218FFFFFFFFFFFFFFFFD3 +S315E6323BE067022000680203006802100869021000C4 +S315E6323BF069020410690204186A0205006A020508B7 +S315E6323C00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA6 +S315E6323C106A0201106A0201186B0208006B02080892 +S315E6323C206B0208106B0208186C0208006C02080870 +S315E6323C306C0208106C0208186D0208006D0208085C +S315E6323C406D0208106D0208186E0208006E02080848 +S315E6323C506E0203106E0203186F020300FFFFFFFFC8 +S315E6323C606F0201086F0202106F0201187002040039 +S315E6323C707002020870020110700201187102010028 +S315E6323C8071020108710204107102081872020A0002 +S315E6323C9072020A1073020A0073020A1074020A00EA +S315E6323CA074020A10750220007602200077020100BD +S315E6323CB0770202087702021077020218FFFFFFFF49 +S315E6323CC078020200780210087802051879020600B0 +S315E6323CD079020508790205107A020E007A02051093 +S315E6323CE07B020E007B0205107C020E007C0205107A +S315E6323CF07C0201187D0205007D0205087D020A1066 +S315E6323D007E020A007E0205107E0205187F020A004E +S315E6323D107F020A10800205008002050880020A1038 +S315E6323D2081020A0081020710810207188202070021 +S315E6323D30820207088202071082020718FFFFFFFF98 +S315E6323D40FFFFFFFF830204008302040883020410A6 +S315E6323D508302041884020400FFFFFFFF8402080888 +S315E6323D6084020810840204188502050085020808D2 +S315E6323D7085020510850204188602050086020808C1 +S315E6323D8086020510860204188702050087020808AD +S315E6323D90870205108702041888020500880207089A +S315E6323DA08802081089021000890208108A02100079 +S315E6323DB08A0208108B0210008B0208108B02081852 +S315E6323DC08C0201008C0201088C0206108C0206185F +S315E6323DD08D0206008D0201088D0201108D0203184E +S315E6323DE08E020A008E020A108F020A00FFFFFFFFDA +S315E6323DF08F020A1090020400900201089002041023 +S315E6323E0090020718910207009102070891020710FD +S315E6323E109102071892020700FFFFFFFFFFFFFFFF3F +S315E6323E2092020508920205109202041893020400E1 +S315E6323E3093020408FFFFFFFF930201109302011873 +S315E6323E4094020200940208089502200096022000A7 +S315E6323E5097021000970202109702021898020200A1 +S315E6323E60FFFFFFFF98020108980201109802021836 +S315E6323E7099021000990210109A0210009A0208105E +S315E6323E809A0208189B0208009B0208089B02101049 +S315E6323E909C0210009C0210109D0208009D02080842 +S315E6323EA09D0208109D0208189E0210009E0210100E +S315E6323EB09F0210009F0208109F020818A00208000F +S315E6323EC0A0020808A0020810A1021000A1021010F2 +S315E6323ED0A2021000A2020810A2020818A3020800E3 +S315E6323EE0A3020808A3021010A4021000A4021010BE +S315E6323EF0A5020800A5020808A5020810A5020818B8 +S315E6323F00A6021000A6021010A7021000A702081099 +S315E6323F10A7020818A8020800A8020808A80208108C +S315E6323F20A9021000A9021010AA021000AA0208106D +S315E6323F30AA020818AB020800AB020808AB02101058 +S315E6323F40AC021000AC021010AD020800AD02080851 +S315E6323F50AD020810AD020818AE021000AE0210101D +S315E6323F60AF021000AF020810AF020818B00208001E +S315E6323F70B0020808B0020810B1021000B102101001 +S315E6323F80B2021000B2020810B2020818B3020800F2 +S315E6323F90B3020808B3021010B4021000B4021010CD +S315E6323FA0B5020800B5020808B5020810B5020818C7 +S315E6323FB0B6021000B6021010B7021000B7020810A9 +S315E6323FC0B7020818B8020800B8020808B80208109C +S315E6323FD0B8020218B9020300B9020A08BA020A009E +S315E6323FE0BA020A10BB020500BB020808BB02081079 +S315E6323FF0BB020818BC020600BC020608BD02110066 +S315E6324000BD020818BE020400BE020608BE02081049 +S315E6324010BE020818BF020800BF020808BF0208102F +S315E6324020BF020818C0020800C0020608C00206101F +S315E6324030C1021100C1020818C2020400C202060811 +S315E6324040C2020810C2020818C3020800C3020808F0 +S315E6324050C3020810C3020818C4020800C4020608DE +S315E6324060C4020610C5021100C5020818C6020400CB +S315E6324070C6020608C6020810C6020818C7020800B3 +S315E6324080C7020808C7020410C7020418C8020400A9 +S315E6324090C8020408C8020410C8020418C902040099 +S315E63240A0C9020408C9020410C9020418CA02040085 +S315E63240B0CA020408CA020410CA020418CB02040071 +S315E63240C0CB020408CB020410CB020418CC0204005D +S315E63240D0CC020408CD021700CE021600CF02170034 +S315E63240E0D0022000D1022000D2022000D3022000E4 +S315E63240F0D4022000D5022000D6022000D7022000C4 +S315E6324100D8022000D9020200D9020508D9020510E2 +S315E6324110D9020118DA020500DA020508DA020510D2 +S315E6324120DA020518DB020500DB020508DB020510BA +S315E6324130DB020518DC020500DC020508DC020510A6 +S315E6324140DC020518DD020500DD020508DD02051092 +S315E6324150DD020518DE020500DE020508DE0205107E +S315E6324160DE020518DF020500DF020508DF0201106E +S315E6324170DF020218E0020200E0020208E002021062 +S315E6324180E0020118E1020800E1021508E202200027 +S315E6324190E3021500E4022000E5021500E6022000FD +S315E63241A0E7020700E7020108E7020210E70206180D +S315E63241B0E8020100E8020108E9022000EA0202000A +S315E63241C0EB022000EC022000ED020C00ED020C10B0 +S315E63241D0EE022000EF020300F0022000F1020300B5 +S315E63241E0F2022000F3020300F4022000F502030095 +S315E63241F0F6022000F7020300F8022000F902030075 +S315E6324200FA022000FB020300FC022000FD02030054 +S315E6324210FE022000FF020300000320000103030032 +S315E63242200103030801030210010302180203200008 +S315E632423003032000040320000503200006030400DE +S315E632424007031E0008031E0009031E000A031E00AA +S315E63242500B031E000C031E000D031E000E031E008A +S315E63242600F0304000F0301080F03101010031000AA +S315E6324270100310101103040011030108110308108C +S315E6324280110304181203010012030808120304107C +S315E6324290120301181303080013030408130301106B +S315E63242A01303081814030400140301081403081050 +S315E63242B01403041815030100150308081503041040 +S315E63242C0150301181603080016030408160301102F +S315E63242D01603081817030800180301001803050821 +S315E63242E0180301101803021819030100190301080D +S315E63242F019030110190301181A0301001A030108FA +S315E63243001A0301101A0301181B0301001B030108E5 +S315E63243101B0301101B0301181C0301001C030108D1 +S315E63243201C0301101C0301181D0308001D030808AF +S315E63243301D0308101D030818F004000000000000F3 +S315E632434000000000000100000C3C00010C3C0002BB +S315E6324350000301000001000400030000C00007006C +S315E63243600102B0002000000000000000000000005C +S315E6324370000000000000000000000000000000001F +S315E632438000000000000000090000080400040804EA +S315E63243900000000010321032080780000C000F00D1 +S315E63243A000010000AA55AA55CC33CC33F00FF00FF4 +S315E63243B0F0F00F0F388E000010325476010000000E +S315E63243C000000000000000000000000000000000CF +S315E63243D000000000000000000000000000000000BF +S315E63243E000000000000000000000000000000000AF +S315E63243F0000000000000000000000000000000009F +S315E632440000000000000020002008200820082008CE +S315E63244102008200820082008200820082008000066 +S315E63244200003000300030003000300030003000356 +S315E6324430000300000000000000000000000000005B +S315E632444000000000A000A000A000A000A000A0008E +S315E6324450A000A000A000A000A000A000A000A0003E +S315E6324460A000A000A000A00009010401000200009D +S315E6324470000000010002000041A14140A04101C016 +S315E6324480C000000E0C0010000842060C180C0F0095 +S315E63244904001E000200C00000000000000000000B1 +S315E63244A000000000000000000000000000000000EE +S315E63244B002000000000000000000000000000000DC +S315E63244C0200340004000000098BADC0000000000FD +S315E63244D098BADC000000000103000200000000008A +S315E63244E00000000000000000012A0000150000006E +S315E63244F0150000002A000000330000000C00000020 +S315E63245000C000000330000002088410000003F0026 +S315E63245103F0000006E0002000002000200020002C6 +S315E6324520000200001000084203000000000000000E +S315E63245300404040404040000000000000000000045 +S315E6324540000000000000000002000000000000004B +S315E6324550000000000000000020034000400000009A +S315E6324560000000000000000000000000000000012C +S315E63245700300020000000000000000000000000018 +S315E6324580012A000015000000150000002A0000008E +S315E6324590330000000C0000000C000000330000007F +S315E63245A00000000000000000000000006E0002007D +S315E63245B00002000200020002000200001000084279 +S315E63245C003000000000000000100000000000000C9 +S315E63245D005000000000F00048000020055000200CC +S315E63245E0000000000000000000000000500000005D +S315E63245F00000000000010101000200000211000085 +S315E632460000000000001F0F001F0F1F0F1F0F1F0FA6 +S315E6324610030002000002000200020000021100005E +S315E63246206400000000000000000000000205000001 +S315E6324630006E7F027F007F003C7F00006E7F0400C3 +S315E63246404F1503004F1501004F1501004F150100B6 +S315E63246504F150100EE3F00004F150100EE3F000018 +S315E63246604F1501003C7F00004F15010000000000A7 +S315E632467000000000000000000000006500000000B7 +S315E63246800000000001020000000000000000000009 +S315E632469000000000000000000000000000000000FC +S315E63246A000000000000000000000000000000000EC +S315E63246B00000000000000000000B000000010000D0 +S315E63246C000000000FFFF000000000000FFFF0000D0 +S315E63246D000000000FFFF4C3000020000000200003E +S315E63246E000020000000200004C300000000200002A +S315E63246F00002000000020000000200004C3000001A +S315E63247000002000000020000000200000002000083 +S315E63247100000010003000000010000010000000075 +S315E6324720000000000000000000000000000000006B +S315E6324730000000000000000000000000000000005B +S315E6324740000000000000000000000000000000004B +S315E63247500000000000000000000000000101000F2A +S315E6324760252D4908040C0E500E5002000300460071 +S315E6324770CF002618CF0026180500000000000000FC +S315E6324780000000000000000000000000000000000B +S315E632479000000000000000000000000104040400EE +S315E63247A0000A28010000000000000F00031800008E +S315E63247B000000000000000000200060001000100D1 +S315E63247C001010001010202040408080000000000AB +S315E63247D0000003080804151500000000000000007A +S315E63247E0000000000F0F1E0000000000000300016B +S315E63247F00000000000000000000000010101010097 +S315E63248000E0E0E000C0C0C0001060602000000002D +S315E632481003000000031718000600280016002800D9 +S315E63248201600000000000000000000000000000054 +S315E632483000000A140A010500038D01038D010A0000 +S315E632484000010600060000018E018E0100018E018E +S315E63248508E011111040201105006090902021120D5 +S315E63248600010200000102000001004040001021897 +S315E6324870180101004A004B0000000F051E02010C2A +S315E632488000000034000000000000000000000000D6 +S315E632489000D42E31321111D42E31321111D42E31B9 +S315E63248A032111100D42E31321111D42E3132111188 +S315E63248B0D42E3132111100D42E31321111D42E3199 +S315E63248C0321111D42E3132111100D42E3132111168 +S315E63248D0D42E31321111D42E3132111100000200AA +S315E63248E08D018D018D01080C221D121F44B3014341 +S315E63248F0062017100C221D121F44B3014306201759 +S315E6324900100C221D121F000044B301430620171075 +S315E63249100200020002000200020002000200020069 +S315E63249200200020000000000000000000000000065 +S315E63249300000000000000000000000000000000059 +S315E63249400000000000000000000000000000000049 +S315E63249500000000000040001004C3000F8E20100DD +S315E63249604C300000F8E201004C300000F8E201007B +S315E63249700000000800010000000000000000000010 +S315E63249800000000000000000020000000000000007 +S315E63249901032547608F004000000000000000000F1 +S315E63249A0000001000E6E6E030E6E6E02000301000B +S315E63249B00001000400030000C00017000102B00047 +S315E63249C020000300000000000000000000000000A6 +S315E63249D000000000000000000000000000000000B9 +S315E63249E00000000900000804000408040000000084 +S315E63249F010321032080780000C000F00000100006A +S315E6324A00AA55AA55CC33CC33F00FF00FF0F00F0F90 +S315E6324A10388E0100000000000000000000000000B1 +S315E6324A200000000000000000000000000000000068 +S315E6324A300000000000000000000000000000000058 +S315E6324A400000000000000000000000000000000048 +S315E6324A500000000000000000000000000000200018 +S315E6324A6020082008200820082008200820082008E8 +S315E6324A702008200820080000000300030003000394 +S315E6324A8000030003000300030003000000000000F9 +S315E6324A900000000000000000000000000000A00058 +S315E6324AA0A000A000A000A000A000A000A000A000E8 +S315E6324AB0A000A000A000A000A000A000A000A000D8 +S315E6324AC0A000090104010002000000000000010016 +S315E6324AD00002000041A14140A04101C0C000000EE3 +S315E6324AE00C0010000842060C180C0F004001E000DC +S315E6324AF0200C00000000000000000000000000006C +S315E6324B000000000000000000000000000000000087 +S315E6324B100200000000000000000000000000000075 +S315E6324B20200340004000000098BADC000000000096 +S315E6324B3098BADC0000000001030002000000000023 +S315E6324B4000000000000000002A0000001500000008 +S315E6324B50150000002A000000330000000C000000B9 +S315E6324B600C000000330000002088410A00003F00B6 +S315E6324B703F0000006EC00200C002C002C002C002A0 +S315E6324B80C0020000100008420300000000000000E8 +S315E6324B9004040404040400000000000000000000DF +S315E6324BA000000000000000000200000000000000E5 +S315E6324BB00000000000000000200340004000000034 +S315E6324BC000000000000000000000000000000001C6 +S315E6324BD003000200000000000000000000000000B2 +S315E6324BE02A00000015000000150000002A00000029 +S315E6324BF0330000000C0000000C0000003300000019 +S315E6324C000000000000000000000000006EC0020056 +S315E6324C10C002C002C002C002C00200001000084252 +S315E6324C200300000000000000010000000000000062 +S315E6324C3005000000000F0004800002005500020065 +S315E6324C4000000000000000000000000050000000F6 +S315E6324C500000000000010101000600000000645079 +S315E6324C6042114201420100000000000000160F0028 +S315E6324C70160F160F160F160F0300000000C00200BD +S315E6324C80C002C002C00200004211420142010000E7 +S315E6324C9000000000000000000000020500000000EF +S315E6324CA06E7F02007F027F046E7F02006E7F040013 +S315E6324CB04F5503004F5501004F5501004F55010040 +S315E6324CC04F550100EE3F00004F550100EE3F000022 +S315E6324CD04F5501006E7F02004F550100000000007D +S315E6324CE00000000000000000000000650000000041 +S315E6324CF00000000001020000000000000000000093 +S315E6324D000000000000000000000000000000000085 +S315E6324D1000000000000000000000E406000000008B +S315E6324D200000000000000100000B00000001000058 +S315E6324D3000000000FFFF000000000000FFFF000059 +S315E6324D4000000000FFFF4C300002000000020000C7 +S315E6324D5000020000000200004C30000000020000B3 +S315E6324D600002000000020000000200004C300000A3 +S315E6324D70000200000002000000020000000200000D +S315E6324D8000000100030000000100000100000000FF +S315E6324D9000000000000000000000000000000000F5 +S315E6324DA000000000000000000000000000000000E5 +S315E6324DB000000000000000000000000000000000D5 +S315E6324DC00000000000000000000000000101000FB4 +S315E6324DD0252D490804000C0E00500E005002000044 +S315E6324DE003004600CF002618CF002618050000003D +S315E6324DF00000000000000000000000000000000095 +S315E6324E000000000000000000000000000000000183 +S315E6324E1004040400000A28010000000000000F0026 +S315E6324E200318000000000000000000000200060041 +S315E6324E300100010001010001010202040408080032 +S315E6324E400000000000000308080415150000000003 +S315E6324E500000000000000000000F0F001E000000F8 +S315E6324E600000000000030001000000000000000020 +S315E6324E7000000001010101000E0E0E000C0C0C00C2 +S315E6324E8001060602000000000300000003171800C0 +S315E6324E900600280016002800160000000000000072 +S315E6324EA0000000000000000000000A140A010500B6 +S315E6324EB0038D01038D010A0000010600060000019A +S315E6324EC08E018E0100018E018E011111040201104E +S315E6324ED050060909020211200010200000102000B7 +S315E6324EE00010040400010218180101004A004B00C2 +S315E6324EF000000F051E02010C00000034000000001F +S315E6324F00000000000000000000D400002E00310050 +S315E6324F1036111100D4002E003100361111D40000BC +S315E6324F202E00310036111100D4002E003100361132 +S315E6324F3011D400002E00310036111100D4002E00B5 +S315E6324F40310036111100D4002E003100361111002F +S315E6324F50D4002E003100361111D400002E00310075 +S315E6324F6036111100D4002E003100361111D400006C +S315E6324F702E00310036111100D4002E0031003611E2 +S315E6324F80110000028D018D018D01080C221D121FC2 +S315E6324F9044B3014306201710100C221D121F0000DF +S315E6324FA044B3014306201710100C221D121F0000CF +S315E6324FB044B3014306201710100200020002000233 +S315E6324FC000020002000200020002000200000000B7 +S315E6324FD000000000000000000000000000000000B3 +S315E6324FE000000000000000000000000000000000A3 +S315E6324FF0000000000000000000000000000400008F +S315E6325000121314150E0F10110D0C0B08090A0405AE +S315E6325010060700010203000001020301004C3000DC +S315E6325020F8E201004C300000F8E201004C300000B4 +S315E6325030F8E201000000000800010000000000006E +S315E63250400000000000000000000000000200000040 +S315E63250501032547608F004003301020000000000F4 +S315E632506000000000000001000E6E6E010E6E6E024A +S315E63250700003010000010004000000010000000008 +S315E63250800000000000010000C0001700B000010277 +S315E632509020000300000000000100000000000000CE +S315E63250A000000000000000000000000000000000E2 +S315E63250B000000009000008040004080400000008A5 +S315E63250C00780000C000F000000010000AA55AA5521 +S315E63250D0CC33CC33F00FF00FF0F00F0F388E0100F1 +S315E63250E000000000000000000000000000000000A2 +S315E63250F00000000000000000000000000000000092 +S315E63251000000000000000000000000000000000081 +S315E63251100000000000000000000000000000000071 +S315E63251200000000000000000000000000000000061 +S315E63251300401000020200800200820082008200864 +S315E63251402008200820082008200820080000000051 +S315E6325150000000000003000300030003000300031F +S315E63251600003000300030000000000000000000018 +S315E6325170000000000000000000000000A000A000D1 +S315E6325180A000A000A000A000A000A000A000A00001 +S315E6325190A000A000A000A000A000A000A000A000F1 +S315E63251A009010401000200000000000100020000CD +S315E63251B00400000041A14140A04101C0C000000EFA +S315E63251C00C00100008423E060C180C0F4001E000B7 +S315E63251D0200C000000000000000000000000000085 +S315E63251E000000000000000000000000000000000A1 +S315E63251F0000000000000010000020000000000008E +S315E632520000000000000000002003400040000000DD +S315E632521098BADC000000000300020000000000003D +S315E632522000000000000000002A0000001500000021 +S315E6325230150000002A000000330000000C000000D2 +S315E63252400C000000330000002088410000003F00D9 +S315E63252503F0000006EC00200C002C002C002C002B9 +S315E6325260C0020000100008423E03000000000000C3 +S315E63252700000000000000000000000000000000010 +S315E63252800000000000000000000000000000000000 +S315E632529000000000000000000000000000000000F0 +S315E63252A000000000000000000000000000000000E0 +S315E63252B000000000000000000000000000000000D0 +S315E63252C000000000000000000000000000000000C0 +S315E63252D000000000000000000000000000000000B0 +S315E63252E000000000000000000000000000000000A0 +S315E63252F00000000000000000000000000000000090 +S315E6325300000000000000000000000000000100007E +S315E632531000000000000005000000000F00048000D7 +S315E632532032000200550002000000000000000000D4 +S315E632533000000000500000000000000000010101FC +S315E6325340000200000000000000010100000000003B +S315E6325350000000000000000000000000645000007B +S315E632536042114201420100000000000000110F0026 +S315E6325370110F110F110F00090300000000C00200E1 +S315E6325380C002C002C00200004211420142010000E0 +S315E632539000000000000000000000020500000014D4 +S315E63253A0006E7F027F027F046E7F02006E7F04000C +S315E63253B04F5503004F5501004F5501004F55010039 +S315E63253C04F550100EE3F00004F550100EE3F00001B +S315E63253D04F5501006E7F02004F5501001140000025 +S315E63253E0104400000000000000000000000000004B +S315E63253F06500000000000000010102000000000026 +S315E63254000000000308000000000000000000000073 +S315E6325410000000000000000001000000000000006D +S315E63254200000000000000000E400000098010100E0 +S315E63254300000000000000000000001070401000041 +S315E63254400000000000000000000B00000001000032 +S315E63254500000640000000000FFFF000000000000CC +S315E6325460FFFF000000000000FFFF00004C300000A6 +S315E63254700002000000020000000200000002000006 +S315E63254804C3000000002000000020000000200007C +S315E6325490000200004C30000000020000000200006C +S315E63254A000020000000200000000010003000000D6 +S315E63254B001000001000000000000000000000000CC +S315E63254C000000000000000000000000000000000BE +S315E63254D000000000000000000000000000000000AE +S315E63254E0000000000000000000000000000000009E +S315E63254F0000000000101000F252D4908040C0E506C +S315E63255000E5002000103000046000000CF00000004 +S315E632551026180000CF00000026180000050000001D +S315E6325520000000000000000000000000000000005D +S315E6325530000000000000000000000000000000004D +S315E632554000010104040400000A28010100000000FB +S315E6325550000000000F000300180000000000000003 +S315E63255600000000002000600010001000101000110 +S315E632557001020204040808000000000000000308E5 +S315E632558008041515000000000000000000000000C7 +S315E632559000000F0F1E0000000000000000030001AD +S315E63255A000010000000000000000000000000001DB +S315E63255B0010100005A5A55555A5A55555A5A5555B1 +S315E63255C05A5A555501000E0E0E000C0C0C00010609 +S315E63255D0060117170202020000000003000000006F +S315E63255E003171800060028001600280016000000E9 +S315E63255F00000000000000000000000000000000A83 +S315E6325600140A0100050003008D0103008D010A002C +S315E632561000010600060000018E018E0100018E01B0 +S315E63256208E0111110402011050060909020211FF18 +S315E63256300010FF000010FF000010040400010218FB +S315E6325640180001014A004A004A004B0000000F05E5 +S315E63256501E02010C000000340000000000000000CB +S315E63256600000000000000000D42E31361111D42E8F +S315E632567031361111D42E3136111100D42E3136117E +S315E632568011D42E31361111D42E3136111100D42ED3 +S315E632569031361111D42E31361111D42E313611114D +S315E63256A000D42E31361111D42E31361111D42E3193 +S315E63256B03611110000028D018D018D01080C221D75 +S315E63256C0121F000044B30143062017100C221D12A6 +S315E63256D01F44B30143062017100C221D121F000089 +S315E63256E044B301430620171002000200020002000C +S315E63256F00200020002000200020002000000000080 +S315E6325700000000000000000000000000000000007B +S315E6325710000000000000000000000000000000006B +S315E63257200000000000000000000000000004000057 +S315E6325730020304050E0F0001040506070001020303 +S315E632574000000102030100004C300000F8E20100DD +S315E63257504C300000F8E201004C300000F8E201007D +S315E63257600000000800010000000000000000000012 +S315E6325770000000000000000000000100000000000A +S315E632578000000000000000000000000000000000FB +S315E632579000000000000000000000000000000000EB +S315E63257A000000000000000000000000000000000DB +S315E63257B000000000000000000000000000000000CB +S315E63257C000000000000000000000000000000000BB +S315E63257D000000000000000000000000000000000AB +S315E63257E0000000000000000000000000000000009B +S315E63257F0000000000000000000000000000000008B +S315E63258000200000000000000000000000000000078 +S315E6325810000000000000000000000000000000006A +S315E6325820860000008700000088000000890000003C +S315E63258308A0000008B0000008C0000008D0000001C +S315E63258408E0000008F00000090000000000000008D +S315E632585094000000950000009600000097000000D4 +S315E632586098000000990000009A0000009B000000B4 +S315E63258709C0000009D000000A9000000AB0000007D +S315E6325880AD000000AF000000B1000000B30000003A +S315E6325890B5000000B7000000B900000000000000C5 +S315E63258A0A8000000AA000000AC000000AE0000002E +S315E63258B0B0000000B2000000B4000000B6000000FE +S315E63258C0B8000000000000009601000097010000D3 +S315E63258D098010000990100009A0100009C0100003F +S315E63258E09E010000A0010000270100002801000009 +S315E63258F0290100002A0100002B0100002C010000DC +S315E63259007701000078010000790100007A01000093 +S315E63259100301C00200000003A000000002020000FC +S315E63259201032540001320000432561707016254369 +S315E6325930706132453425671008080808AA00550012 +S315E6325940AA005501CC013301CC003300F0000F0139 +S315E6325950F0010F01F000F0000F000F010000000029 +S315E63259600000000000000000000000000000000019 +S315E63259700000000000000000000000000000000009 +S315E632598000000000000000000000000000000000F9 +S315E632599000000000000000000000000000000000E9 +S315E63259A000000000000000000000000000000000D9 +S315E63259B002020000103254001023000054763201FF +S315E63259C00761523470164235245361700808080866 +S315E63259D0AA005500AA005501CC013301CC003300AA +S315E63259E0F0000F01F0010F01F000F0000F000F0199 +S315E63259F00000000000000000000000000000000089 +S315E6325A000000000000000000000000000000000078 +S315E6325A100000000000000000000000000000000068 +S315E6325A200000000000000000000000000000000058 +S315E6325A300000000000000000000000000000000048 +S315E6325A400000000000000000000000000000000038 +S315E6325A500000000000000000000000000000000028 +S315E6325A600000000000000000000000000000000018 +S315E6325A700000000000000000000000000000000008 +S315E6325A8000000000000000000000000000000000F8 +S315E6325A9000000000000000000000000000000000E8 +S315E6325AA000000000000000000000000000000000D8 +S315E6325AB000000000000000000000000000000000C8 +S315E6325AC000000000000000000000000000000000B8 +S315E6325AD000000000000000000000000000000000A8 +S315E6325AE00000000000000000000000000000000098 +S315E6325AF00000000000000000000000000000000088 +S315E6325B000000000000000000000000000000000077 +S315E6325B100000000000000000000000000000000067 +S315E6325B200000000000000000000000000000000057 +S315E6325B300000000000000000000000000000000047 +S315E6325B400000000000000000000000000000000037 +S315E6325B500000000000000000000000000000000027 +S315E6325B600000000000000000000000000301C00251 +S315E6325B7000000003A00000000202000001523400D9 +S315E6325B800132000043256701071236450721634590 +S315E6325B903452716008080808AA005500AA00550171 +S315E6325BA0CC013301CC003300F0000F01F0010F01D6 +S315E6325BB0F000F0000F000F010000000000000000C8 +S315E6325BC000000000000000000000000000000000B7 +S315E6325BD000000000000000000000000000000000A7 +S315E6325BE00000000000000000000000000000000097 +S315E6325BF00000000000000000000000000000000087 +S315E6325C000000000000000000000000000202000072 +S315E6325C10542130001023000043256701071236452A +S315E6325C20072163453452716008080808AA00550010 +S315E6325C30AA005501CC013301CC003300F0000F0146 +S315E6325C40F0010F01F000F0000F000F010000000036 +S315E6325C500000000000000000000000000000000026 +S315E6325C600000000000000000000000000000000016 +S315E6325C700000000000000000000000000000000006 +S315E6325C8000000000000000000000000000000000F6 +S315E6325C9000000000000000000000000000000000E6 +S315E6325CA000000000000000000000000000000000D6 +S315E6325CB000000000000000000000000000000000C6 +S315E6325CC000000000000000000000000000000000B6 +S315E6325CD000000000000000000000000000000000A6 +S315E6325CE00000000000000000000000000000000096 +S315E6325CF00000000000000000000000000000000086 +S315E6325D000000000000000000000000000000000075 +S315E6325D100000000000000000000000000000000065 +S315E6325D200000000000000000000000000000000055 +S315E6325D300000000000000000000000000000000045 +S315E6325D400000000000000000000000000000000035 +S315E6325D500000000000000000000000000000000025 +S315E6325D600000000000000000000000000000000015 +S315E6325D700000000000000000000000000000000005 +S315E6325D8000000000000000000000000000000000F5 +S315E6325D9000000000000000000000000000000000E5 +S315E6325DA000000000000000000000000000000000D5 +S315E6325DB000000000000000000000000000000000C5 +S315E6325DC000000000000000000F000003C0FE0003E2 +S315E6325DD0A000000002FF000010325400103200002C +S315E6325DE065137420076125342103465732456170BF +S315E6325DF008080808AA005500AA005501CC01330165 +S315E6325E00CC003300F0000F01F0010F01F000F00094 +S315E6325E100F000F0100000000000000000000000045 +S315E6325E200000000000000000000000000000000054 +S315E6325E300000000000000000000000000000000044 +S315E6325E400000000000000000000000000000000034 +S315E6325E500000000000000000000000000000000024 +S315E6325E60000000000000000002FF0000103254007D +S315E6325E700231000010765423076152341023456707 +S315E6325E805467103208080808AA005500AA005501D8 +S315E6325E90CC013301CC003300F0000F01F0010F01E3 +S315E6325EA0F000F0000F000F010000000000000000D5 +S315E6325EB000000000000000000000000000000000C4 +S315E6325EC000000000000000000000000000000000B4 +S315E6325ED000000000000000000000000000000000A4 +S315E6325EE00000000000000000000000000000000094 +S315E6325EF000000000000000000000000002FF000083 +S315E6325F0010325400130200005467213010324567CE +S315E6325F10435216704523160708080808AA005500A4 +S315E6325F20AA005501CC013301CC003300F0000F0153 +S315E6325F30F0010F01F000F0000F000F010000000043 +S315E6325F400000000000000000000000000000000033 +S315E6325F500000000000000000000000000000000023 +S315E6325F600000000000000000000000000000000013 +S315E6325F700000000000000000000000000000000003 +S315E6325F8000000000000000000000000000000000F3 +S315E6325F9002FF00001032540013020000547632013A +S315E6325FA032546170230176544523160708080808E9 +S315E6325FB0AA005500AA005501CC013301CC003300C4 +S315E6325FC0F0000F01F0010F01F000F0000F000F01B3 +S315E6325FD000000000000000000000000000000000A3 +S315E6325FE00000000000000000000000000000000093 +S315E6325FF00000000000000000000000000000000083 +S315E63260000000000000000000000000000000000072 +S315E63260100000000000000000000000000000000062 +S315E6326020000000000301C00200000003A0000000E9 +S315E632603002FF00001032540001320000432561703F +S315E6326040701625437061324534256710080808080C +S315E6326050AA005500AA005501CC013301CC00330023 +S315E6326060F0000F01F0010F01F000F0000F000F0112 +S315E6326070FF00000000000000000000000000000003 +S315E632608000000000000000000000000000000000F2 +S315E632609000000000000000000000000000000000E2 +S315E63260A000000000000000000000000000000000D2 +S315E63260B000000000000000000000000000000000C2 +S315E63260C00000000002FF00001032540010230000E8 +S315E63260D05476320107615234701642352453617072 +S315E63260E008080808AA005500AA005501CC01330172 +S315E63260F0CC003300F0000F01F0010F01F000F000A2 +S315E63261000F000F0100000000000000000000000052 +S315E63261100000000000000000000000000000000061 +S315E63261200000000000000000000000000000000051 +S315E63261300000000000000000000000000000000041 +S315E63261400000000000000000000000000000000031 +S315E63261500000000000000000000000000000000021 +S315E63261600000000000000000000000000000000011 +S315E63261700000000000000000000000000000000001 +S315E632618000000000000000000000000000000000F1 +S315E632619000000000000000000000000000000000E1 +S315E63261A000000000000000000000000000000000D1 +S315E63261B000000000000000000000000000000000C1 +S315E63261C000000000000000000000000000000000B1 +S315E63261D000000000000000000000000000000000A1 +S315E63261E00000000000000000000000000000000091 +S315E63261F00000000000000000000000000000000081 +S315E63262000000000000000000000000000000000070 +S315E63262100000000000000000000000000000000060 +S315E63262200000000000000000000000000000000050 +S315E63262300000000000000000000000000000000040 +S315E63262400000000000000000000000000000000030 +S315E63262500000000000000000000000000000000020 +S315E63262600000000000000000000000000000000010 +S315E63262700000000000000000000000000000000000 +S315E63262800F00C002C0FE0003A000000002FF0000BD +S315E6326290245031002031000054126730371054262C +S315E63262A0234605174576301208080808AA0055002F +S315E63262B0AA005501CC013301CC003300F0000F01C0 +S315E63262C0F0010F01F000F0000F000F0100000000B0 +S315E63262D000000000000000000000000000000000A0 +S315E63262E00000000000000000000000000000000090 +S315E63262F00000000000000000000000000000000080 +S315E6326300000000000000000000000000000000006F +S315E6326310000000000000000000000000000000005F +S315E632632002FF00004351020010320000423561702E +S315E63263300753241645267130546370210808080837 +S315E6326340AA005500AA005501CC013301CC00330030 +S315E6326350F0000F01F0010F01F000F0000F000F011F +S315E6326360000000000000000000000000000000000F +S315E632637000000000000000000000000000000000FF +S315E632638000000000000000000000000000000000EF +S315E632639000000000000000000000000000000000DF +S315E63263A000000000000000000000000000000000CF +S315E63263B00000000002FF0000043152000123000013 +S315E63263C0423561700753241645267130546370217F +S315E63263D008080808AA005500AA005501CC0133017F +S315E63263E0CC003300F0000F01F0010F01F000F000AF +S315E63263F00F000F0100000000000000000000000060 +S315E6326400000000000000000000000000000000006E +S315E6326410000000000000000000000000000000005E +S315E6326420000000000000000000000000000000004E +S315E6326430000000000000000000000000000000003E +S315E6326440000000000000000002FF000002341500E2 +S315E6326450312000005412673037105426234605178A +S315E63264604576301208080808AA005500AA005501F2 +S315E6326470CC013301CC003300F0000F01F0010F01FD +S315E6326480F000F0000F000F010000000000000000EF +S315E632649000000000000000000000000000000000DE +S315E63264A000000000000000000000000000000000CE +S315E63264B000000000000000000000000000000000BE +S315E63264C000000000000000000000000000000000AE +S315E63264D00000000000000000000000000301C002D8 +S315E63264E000000003A000000002FF00000152340063 +S315E63264F00132000043256701071236450721634517 +S315E63265003452716008080808AA005500AA005501F7 +S315E6326510CC013301CC003300F0000F01F0010F015C +S315E6326520F000F0000F000F0100000000000000004E +S315E6326530000000000000000000000000000000003D +S315E6326540000000000000000000000000000000002D +S315E6326550000000000000000000000000000000001D +S315E6326560000000000000000000000000000000000D +S315E632657000000000000000000000000002FF0000FC +S315E632658054213000102300004325670107123645B1 +S315E6326590072163453452716008080808AA00550097 +S315E63265A0AA005501CC013301CC003300F0000F01CD +S315E63265B0F0010F01F000F0000F000F0100000000BD +S315E63265C000000000000000000000000000000000AD +S315E63265D0000000000000000000000000000000009D +S315E63265E0000000000000000000000000000000008D +S315E63265F0000000000000000000000000000000007D +S315E6326600000000000000000000000000000000006C +S315E6326610000000000000000000000000000000005C +S315E6326620000000000000000000000000000000004C +S315E6326630000000000000000000000000000000003C +S315E6326640000000000000000000000000000000002C +S315E6326650000000000000000000000000000000001C +S315E6326660000000000000000000000000000000000C +S315E632667000000000000000000000000000000000FC +S315E632668000000000000000000000000000000000EC +S315E632669000000000000000000000000000000000DC +S315E63266A000000000000000000000000000000000CC +S315E63266B000000000000000000000000000000000BC +S315E63266C000000000000000000000000000000000AC +S315E63266D0000000000000000000000000000000009C +S315E63266E0000000000000000000000000000000008C +S315E63266F0000000000000000000000000000000007C +S315E6326700000000000000000000000000000000006B +S315E6326710000000000000000000000000000000005B +S315E6326720000000000000000000000000000000004B +S315E632673000000000000000000F000003C0FE000368 +S315E6326740A0000000020200001032540010320000AF +S315E63267506513742007612534210346573245617045 +S315E632676008080808AA005500AA005501CC013301EB +S315E6326770CC003300F0000F01F0010F01F000F0001B +S315E63267800F000F01000000000000000000000000CC +S315E632679000000000000000000000000000000000DB +S315E63267A000000000000000000000000000000000CB +S315E63267B000000000000000000000000000000000BB +S315E63267C000000000000000000000000000000000AB +S315E63267D00000000000000000020200001032540001 +S315E63267E0023100001076542307615234102345678E +S315E63267F05467103208080808AA005500AA0055015F +S315E6326800CC013301CC003300F0000F01F0010F0169 +S315E6326810F000F0000F000F0100000000000000005B +S315E6326820000000000000000000000000000000004A +S315E6326830000000000000000000000000000000003A +S315E6326840000000000000000000000000000000002A +S315E6326850000000000000000000000000000000001A +S315E63268600000000000000000000000000202000006 +S315E63268701032540013020000546721301032456755 +S315E6326880435216704523160708080808AA0055002B +S315E6326890AA005501CC013301CC003300F0000F01DA +S315E63268A0F0010F01F000F0000F000F0100000000CA +S315E63268B000000000000000000000000000000000BA +S315E63268C000000000000000000000000000000000AA +S315E63268D0000000000000000000000000000000009A +S315E63268E0000000000000000000000000000000008A +S315E63268F0000000000000000000000000000000007A +S315E632690002020000103254001302000054763201BD +S315E6326910325461702301765445231607080808086F +S315E6326920AA005500AA005501CC013301CC0033004A +S315E6326930F0000F01F0010F01F000F0000F000F0139 +S315E63269400000000000000000000000000000000029 +S315E63269500000000000000000000000000000000019 +S315E63269600000000000000000000000000000000009 +S315E632697000000000000000000000000000000000F9 +S315E632698000000000000000000000000000000000E9 +S315E6326990000000000F01000300000003A000000023 +S315E63269A002FF0000103254001023000025146370F3 +S315E63269B01670523410765243674510320808080884 +S315E63269C0AA005500AA005501CC013301CC003300AA +S315E63269D0F0000F01F0010F01F000F0000F000F0199 +S315E63269E00000000000000000000000000000000089 +S315E63269F00000000000000000000000000000000079 +S315E6326A000000000000000000000000000000000068 +S315E6326A100000000000000000000000000000000058 +S315E6326A200000000000000000000000000000000048 +S315E6326A300000000002FF000032541000103200005F +S315E6326A400761254354231607674523106754230106 +S315E6326A5008080808AA005500AA005501CC013301F8 +S315E6326A60CC003300F0000F01F0010F01F000F00028 +S315E6326A700F000F01000000000000000000000000D9 +S315E6326A8000000000000000000000000000000000E8 +S315E6326A9000000000000000000000000000000000D8 +S315E6326AA000000000000000000000000000000000C8 +S315E6326AB000000000000000000000000000000000B8 +S315E6326AC0000000000000000002FF00001032540011 +S315E6326AD001230000547632015764310267452310AA +S315E6326AE06754320108080808AA005500AA0055017B +S315E6326AF0CC013301CC003300F0000F01F0010F0177 +S315E6326B00F000F0000F000F01000000000000000068 +S315E6326B100000000000000000000000000000000057 +S315E6326B200000000000000000000000000000000047 +S315E6326B300000000000000000000000000000000037 +S315E6326B400000000000000000000000000000000027 +S315E6326B5000000000000000000000000002FF000016 +S315E6326B60103254000123000065470312675410239E +S315E6326B70457601234567103208080808AA0055000B +S315E6326B80AA005501CC013301CC003300F0000F01E7 +S315E6326B90F0010F01F000F0000F000F0100000000D7 +S315E6326BA000000000000000000000000000000000C7 +S315E6326BB000000000000000000000000000000000B7 +S315E6326BC000000000000000000000000000000000A7 +S315E6326BD00000000000000000000000000000000097 +S315E6326BE00000000000000000000000000000000087 +S315E6326BF00F01000300000003A000000002020000BD +S315E6326C001032540010230000251463701670523485 +S315E6326C10107652436745103208080808AA0055002E +S315E6326C20AA005501CC013301CC003300F0000F0146 +S315E6326C30F0010F01F000F0000F000F010000000036 +S315E6326C400000000000000000000000000000000026 +S315E6326C500000000000000000000000000000000016 +S315E6326C600000000000000000000000000000000006 +S315E6326C7000000000000000000000000000000000F6 +S315E6326C8000000000000000000000000000000000E6 +S315E6326C90020200003254100010320000076125432A +S315E6326CA05423160767452310675423010808080854 +S315E6326CB0AA005500AA005501CC013301CC003300B7 +S315E6326CC0F0000F01F0010F01F000F0000F000F01A6 +S315E6326CD00000000000000000000000000000000096 +S315E6326CE00000000000000000000000000000000086 +S315E6326CF00000000000000000000000000000000076 +S315E6326D000000000000000000000000000000000065 +S315E6326D100000000000000000000000000000000055 +S315E6326D200000000002020000103254000123000087 +S315E6326D30547632015764310267452310675432017D +S315E6326D4008080808AA005500AA005501CC01330105 +S315E6326D50CC003300F0000F01F0010F01F000F00035 +S315E6326D600F000F01000000000000000000000000E6 +S315E6326D7000000000000000000000000000000000F5 +S315E6326D8000000000000000000000000000000000E5 +S315E6326D9000000000000000000000000000000000D5 +S315E6326DA000000000000000000000000000000000C5 +S315E6326DB0000000000000000002020000103254001B +S315E6326DC001230000654703126754102345760123F3 +S315E6326DD04567103208080808AA005500AA00550188 +S315E6326DE0CC013301CC003300F0000F01F0010F0184 +S315E6326DF0F000F0000F000F01000000000000000076 +S315E6326E000000000000000000000000000000000064 +S315E6326E100000000000000000000000000000000054 +S315E6326E200000000000000000000000000000000044 +S315E6326E300000000000000000000000000000000034 +S315E6326E400000000000000000000000000F01000311 +S315E6326E5000000003A000000002FF000010325400DA +S315E6326E60103200001053642710623475107246539E +S315E6326E701045672308080808AA005500AA005501F6 +S315E6326E80CC013301CC003300F0000F01F0010F01E3 +S315E6326E90F000F0000F000F010000000000000000D5 +S315E6326EA000000000000000000000000000000000C4 +S315E6326EB000000000000000000000000000000000B4 +S315E6326EC000000000000000000000000000000000A4 +S315E6326ED00000000000000000000000000000000094 +S315E6326EE000000000000000000000000002FF000083 +S315E6326EF010325400012300001045762310762543DE +S315E6326F00102675430124653708080808AA00550095 +S315E6326F10AA005501CC013301CC003300F0000F0153 +S315E6326F20F0010F01F000F0000F000F018080808043 +S315E6326F308080000000000000000000000000000033 +S315E6326F400000000000000000000000000000000023 +S315E6326F500000000000000000000000000000000013 +S315E6326F600000000000000000000000000000000003 +S315E6326F7000000000000000000000000000000000F3 +S315E6326F8002FF00000321450010320000104576323A +S315E6326F901076254310267543013457260808080825 +S315E6326FA0AA005500AA005501CC013301CC003300C4 +S315E6326FB0F0000F01F0010F01F000F0000F000F01B3 +S315E6326FC000000000000000000000000000000000A3 +S315E6326FD00000000000000000000000000000000093 +S315E6326FE00000000000000000000000000000000083 +S315E6326FF00000000000000000000000000000000073 +S315E63270000000000000000000000000000000000062 +S315E63270100000000002FF00001304520001230000C4 +S315E6327020012365471062347510724653014567325D +S315E632703008080808AA005500AA005501CC01330112 +S315E6327040CC003300F0000F01F0010F01F000F00042 +S315E63270500F000F01000000000000000000000000F3 +S315E63270600000000000000000000000000000000002 +S315E632707000000000000000000000000000000000F2 +S315E632708000000000000000000000000000000000E2 +S315E632709000000000000000000000000000000000D2 +S315E63270A000000000000000000000000007000000BB +S315E63270B00E00000015000000000000000700000088 +S315E63270C00E0000001500000010CC66B82104253B00 +S315E63270D0D558010010CC66B82104A53A55590100B7 +S315E63270E010CC66B82184A43A5559010010CC66B85C +S315E63270F0210CB03A9056010010CC66B8210CB13963 +S315E63271005357010010CC66B8218CAF3A935701003B +S315E632711010CC66B82194A33B9659010010CC66B8DA +S315E63271202114233CD759010010CC66B82114243CED +S315E632713097590100FFFFFFFFFFFFFFFF4F550100A3 +S315E63271400000000000000000000000000000000021 +S315E63271500000000000000000000000000000000011 +S315E63271600000000000000000000000000000000001 +S315E632717000000000000000000000000000000000F1 +S315E632718000000000000000000000000000000000E1 +S315E632719000000000000000000000000000000000D1 +S315E63271A000000000000000000000000000000000C1 +S315E63271B0000000000000000020030606040608046C +S315E63271C0400040060A0C080A0814490060090E1007 +S315E63271D00C1008245200800C14160A1408341B00CC +S315E63271E0A00F181C0C180A442400C0121C200E1ECE +S315E63271F00C542D00E015202410220E6436000019B8 +S315E63272002428122810743F00983A03004C1D0300D6 +S315E63272104C1D08005046040050460300085203004F +S315E632722010A4030050460400102708001027040075 +S315E632723000000000409C0000AC0D00004C1D03002F +S315E63272404C1D03004C1D03000000080010270A00FF +S315E6327250B0360A00E8030A0030750A001027000045 +S315E6327260983A03004C1D03004C1D0800A34D04005A +S315E6327270A34D03005B59030063AB0300504604009B +S315E6327280102708001027040000000000409C00008A +S315E6327290100E00004C1D03004C1D03004C1D03006E +S315E63272A00000080010270A00B0360A00E8030A0092 +S315E63272B030750A00102700003C005A005A008C004E +S315E63272C08C00180118018200B400B40018011801C6 +S315E63272D0300230020000000063030000790300004A +S315E63272E08F030000A50300006A0300008003000056 +S315E63272F096030000AC030000640300007A03000044 +S315E632730090030000A60300006B0300008103000031 +S315E632731097030000AD030000650300007B0300001F +S315E632732091030000A70300006C030000820300000D +S315E632733098030000AE030000660300007C030000FB +S315E632734092030000A80300006D03000083030000E9 +S315E632735099030000AF030000670300007D030000D7 +S315E632736093030000A90300006E03000084030000C5 +S315E63273709A030000B0030000680300007E030000B3 +S315E632738094030000AA0300006F03000085030000A1 +S315E63273909B030000B1030000940100009501000052 +S315E63273A09F0100000000000054696D65206F757418 +S315E63273B05B325D00000000005B5741524D5F424F43 +S315E63273C04F545D00000000005B434F4C445F424F32 +S315E63273D04F545D00000000005B424F4F545F5354FA +S315E63273E0415455535F5550444154455F4552524F89 +S315E63273F0525D0000000000004444523A556E6B6E10 +S315E63274006F776E2050726F64756374000000000009 +S315E63274104444523A556E6B6E6F776E20426F6172A6 +S315E632742064000000000000007265762E302E323798 +S315E63274300000000000000000424C323A204444523A +S315E632744025642825732900002E2E25640A000000BD +S315E6327450424B5550206D6F646520636E74205245FB +S315E63274604144204552524F522E0A00000000000097 +S315E6327470424B5550206D6F646520636E74205752C9 +S315E6327480495445204552524F522E2076616C7565E7 +S315E6327490203D2025640A00000A5761726D20626F2C +S315E63274A06F74696E672E2E2E0A2054686520706FC9 +S315E63274B074656E7469616C206F662047502D312D86 +S315E63274C03820646964206E6F7420737769746368F2 +S315E63274D020746F204C6F772E0A20496620796F75B5 +S315E63274E02065787065637420746865206F7065729E +S315E63274F06174696F6E206F6620636F6C6420626FAB +S315E63275006F742C0A20636865636B20746865206243 +S315E63275106F61726420636F6E6669677572617469EC +S315E63275206F6E202865782C204469702D53572920B2 +S315E6327530616E642F6F722074686520482F57206615 +S315E632754061696C7572652E0A000000000000000063 +S315E63275502028505252202620482737464646203D96 +S315E63275602048270000000000522D4361722048333E +S315E63275700000000000000000522D436172204D33B8 +S315E63275800000000000000000522D4361722056339F +S315E63275904D00000000000000522D43617220443354 +S315E63275A000000000000000004572726F72203A2039 +S315E63275B0534F4320636F6465206973206E6F742080 +S315E63275C0737570706F7274656400000000000000B7 +S315E63275D02045530000000000312E31000000000045 +S315E63275E02050726F6475637420436F646520202081 +S315E63275F0203A20000000000020426F61726449643E +S315E63276005772697465493263456570726F6D2000EB +S315E632761053616C7661746F722D580000000000007B +S315E63276204B7269656B000000537461727465722041 +S315E63276304B69742050726F004561676C65000000D5 +S315E632764053616C7661746F722D58530000000000F8 +S315E632765053616C7661746F722D4D530000000000F3 +S315E6327660436F6E646F720000447261616B000000B4 +S315E632767053746172746572204B6974205072656D0B +S315E63276806965720000000000556E6B6E6F776E208C +S315E6327690426F6172640000003100000000000000B3 +S315E63276A03200000000000000330000000000000057 +S315E63276B03400000000000000360000000000000042 +S315E63276C0370000000000000053616C7661746F7219 +S315E63276D02D58202F2053616C7661746F722D585374 +S315E63276E00000000000000000537461727465722077 +S315E63276F04B69742050726F202F2053746172746511 +S315E632770072204B6974205072656D696572000000AD +S315E63277104572726F72203A20426F617264206A75E0 +S315E6327720646765000000000020426F617264204A99 +S315E63277307564676520202020203A2000000000008C +S315E63277404E6F74205573656420426F6172642D49BB +S315E632775044000000000000005573656420426F6104 +S315E632776072642D4944000000522D43617220585806 +S315E632777020000000000000002D2D2D2D2D2D2D2D63 +S315E63277802D2D2D2D2D2D2D2D2D2D2D2D2D2D2D2D0B +S315E63277902D2D2D2D2D2D2D2D2D2D2D2D2D2D2D2DFB +S315E63277A02D2D2D2D2D2D2D00506C65617365207393 +S315E63277B0656C65637420746865207265766973698B +S315E63277C06F6E206F662074686520626F6172642E12 +S315E63277D000000000000000002031203A20525450CA +S315E63277E03052433737393553495042303031305398 +S315E63277F0202F205254503052433737393653495078 +S315E632780042303031305320002032203A2052545022 +S315E63278103052433737393553495042303031315366 +S315E6327820202F205254503052433737393653495047 +S315E632783042303031315320002033203A20525450F0 +S315E63278403052433737393553495042303031325335 +S315E6327850202F205254503052433737393653495017 +S315E63278604230303132532000202053656C656374E2 +S315E632787020626F61726428312D33293E00000000A2 +S315E63278804F52455200000000202000000000000062 +S315E632789020426F617264204E616D65202020202081 +S315E63278A0203A2000000000003E0000000000000002 +S315E63278B0636F6D6D616E64206E6F7420666F756E82 +S315E63278C06400000000000000506C65617365207349 +S315E63278D06574207468652073776974636820746F9B +S315E63278E0204F6E426F6172642D53504930283132E1 +S315E63278F0384D6269742920736964652E205365743E +S315E632790074696E67204F4B3F20285075736820594D +S315E6327910206B657929000000506C656173652073CA +S315E63279206574207468652073776974636820746F4A +S315E63279302051737069426F6172642D53504930201B +S315E6327940736964652E2053657474696E67204F4B8E +S315E63279503F2028507573682059206B6579290000D7 +S315E6327960506C65617365207365742074686520733F +S315E6327970776974636820746F204879706572466CED +S315E632798061736820736964652E2053657474696E13 +S315E632799067204F4B3F2028507573682059206B6518 +S315E63279A07929000000000000535731205357322020 +S315E63279B0416C6C204F4E2120202020536574746929 +S315E63279C06E67204F4B3F2028507573682059206BDF +S315E63279D06579290000000000535733204F46462189 +S315E63279E02020202020202020202020536574746910 +S315E63279F06E67204F4B3F2028507573682059206BAF +S315E6327A006579290000000000535731332031706919 +S315E6327A106E2D53696465212020202053657474697E +S315E6327A206E67204F4B3F2028507573682059206B7E +S315E6327A3065792900000000005357313320337069E7 +S315E6327A406E2D53696465212020202053657474694E +S315E6327A506E67204F4B3F2028507573682059206B4E +S315E6327A606579290000000000434E33203A2051530F +S315E6327A70504920466C61736820426F6172642053C6 +S315E6327A806574204F4B3F2028507573682059206B1A +S315E6327A9065792900000000005357312053573220CA +S315E6327AA0416C6C204F46462120202053657474691A +S315E6327AB06E67204F4B3F2028507573682059206BEE +S315E6327AC06579290000000000535733204F4E2120B6 +S315E6327AD0202020202020202020202053657474691F +S315E6327AE06E67204F4B3F2028507573682059206BBE +S315E6327AF0657929000000000053573331204F464658 +S315E6327B0021202020202020202020205365747469ED +S315E6327B106E67204F4B3F2028507573682059206B8D +S315E6327B20657929000000000053573331204F4E2144 +S315E6327B3020202020202020202020205365747469BE +S315E6327B406E67204F4B3F2028507573682059206B5D +S315E6327B506579290000000000535731202020204F56 +S315E6327B6046462120202020202020202020202020AA +S315E6327B70202053657474696E67204F4B3F20285038 +S315E6327B807573682059206B6579290000000000007C +S315E6327B905357365B335D204F464621202020202040 +S315E6327BA02020202020202020202053657474696E00 +S315E6327BB067204F4B3F2028507573682059206B65F6 +S315E6327BC079290000000000004A5031203170696E92 +S315E6327BD02D3270696E20436F6E6E656374696F6EB1 +S315E6327BE0212053657474696E67204F4B3F202850C7 +S315E6327BF07573682059206B6579290000000000000C +S315E6327C004A5031203370696E2D3270696E20436F79 +S315E6327C106E6E656374696F6E212053657474696E30 +S315E6327C2067204F4B3F2028507573682059206B6585 +S315E6327C307929000000000000535731202020204FDA +S315E6327C404E212020202020202020202020202020E7 +S315E6327C50202053657474696E67204F4B3F20285057 +S315E6327C607573682059206B6579290000000000009B +S315E6327C705357365B335D204F4E212020202020207D +S315E6327C802020202020202020202053657474696E1F +S315E6327C9067204F4B3F2028507573682059206B6515 +S315E6327CA07929000000000000535735203370696E9B +S315E6327CB02D53696465212053657474696E67204F66 +S315E6327CC04B3F2028507573682059206B6579290019 +S315E6327CD0535736203170696E2D53696465212053C8 +S315E6327CE0657474696E67204F4B3F2028507573680A +S315E6327CF02059206B6579290053573720416C6C2021 +S315E6327D004F4E212020202053657474696E67204FCA +S315E6327D104B3F2028507573682059206B65792900C8 +S315E6327D20535736203370696E2D5369646521205375 +S315E6327D30657474696E67204F4B3F202850757368B9 +S315E6327D402059206B65792900535735203170696E93 +S315E6327D502D53696465212053657474696E67204FC5 +S315E6327D604B3F2028507573682059206B6579290078 +S315E6327D7053573720416C6C204F46462120202053FC +S315E6327D80657474696E67204F4B3F20285075736869 +S315E6327D902059206B65792900506C656173652073CD +S315E6327DA06574207468652073776974636820746FC6 +S315E6327DB0204C4253432845585F4D454D2920736939 +S315E6327DC064652E2053657474696E67204F4B3F2087 +S315E6327DD028507573682059206B65792900000000B2 +S315E6327DE05357352C535736203170696E2073696492 +S315E6327DF06521202020202020202053657474696E68 +S315E6327E0067204F4B3F2028507573682059206B65A3 +S315E6327E1079290000000000005357372063656E74F7 +S315E6327E20657221202020202020202020202020209C +S315E6327E30202053657474696E67204F4B3F20285075 +S315E6327E407573682059206B657929000000000000B9 +S315E6327E50466C61736820426F6172642053573120F3 +S315E6327E604353312073696465212053657474696EB0 +S315E6327E7067204F4B3F2028507573682059206B6533 +S315E6327E807929000000000000506C65617365207345 +S315E6327E906574207468652073776974636820746FD5 +S315E6327EA0204F6E426F6172642D5350493028353118 +S315E6327EB0324D6269742920736964652E205365747E +S315E6327EC074696E67204F4B3F202850757368205988 +S315E6327ED0206B6579290000004368616E6765204C40 +S315E6327EE04253432053657474696E67204F4B3F2085 +S315E6327EF028507573682059206B6579290000000091 +S315E6327F00204572726F72203A20426F617264206641 +S315E6327F106C6167206E6F74206D6174636800000071 +S315E6327F204800000000000000444D0000000000005A +S315E6327F304600000000000000464C0000000000004B +S315E6327F4046580000000000004D57000000000000D1 +S315E6327F504D4C0000000000004D58000000000000C5 +S315E6327F604D5600000000000052414D434B000000E2 +S315E6327F70444452434B000000444452434B5F325230 +S315E6327F80414E4B00000000004C00000000000000AD +S315E6327F9047000000000000004C46000000000000EA +S315E6327FA0434600000000000058435300000000003C +S315E6327FB0584C530000000000584C53320000000083 +S315E6327FC058494E464F5F53413000000000000000EC +S315E6327FD058494E464F5F5341305F5300000000002A +S315E6327FE058494E464F00000058494E464F5F5300B9 +S315E6327FF05355500000000000524541445F504D490A +S315E632800043000000000000005345545F504D49439B +S315E632801000000000000000005345545F49494330F2 +S315E63280200000000000000000494943305F4D000081 +S315E63280305345545F4152454130000000000000008E +S315E63280405345545F4C4253430000000000000000A3 +S315E63280504558545F4D4F444500000000000000008D +S315E632806057460000000000005345545F424944003B +S315E6328070493243305F4D0000505252000000000054 +S315E632808058494E464F5F5341305F3200000000009A +S315E632809058494E464F5F5341305F53320000000037 +S315E63280A04D656D6F727920426F756E6461727920B5 +S315E63280B04572726F7200000053796E7461782045AC +S315E63280C072726F72000000004164647265737320E7 +S315E63280D053697A65204572726F72000000000000BD +S315E63280E0444D6D6F6465203D2000000000000000BF +S315E63280F06279746500000000776F726400000000F2 +S315E63281006C6F6E67000000006C6F6E67206C6F6E88 +S315E63281106700000000000000696E76616C696420D3 +S315E632812061646472657373005665726966792E2E7A +S315E63281302E00000000000000204F4B000000000039 +S315E63281404C6F61642050726F6772616D20746F2076 +S315E6328150466C617368206D656D6F7279000000005A +S315E63281603D3D3D206E6F7420737570706F72746527 +S315E63281706420636F6D6D616E64203D3D3D000000A7 +S315E6328180466C617368204D656D6F72792045726112 +S315E632819073652053746172740000000000000000BB +S315E63281A0464C415348204D656D6F7279202861728F +S315E63281B065612031292050726F6772616D00000069 +S315E63281C0206A756D7020746F2030780000000000EA +S315E63281D0464C415348204D454D4F52592036344D43 +S315E63281E04220414C4C20434C454152283235367377 +S315E63281F065635B7479705D292E2E2E2000000000B1 +S315E6328200436C656172206F6620466C617368206DD9 +S315E6328210656D6F72790000004F4B3F28792F6E29D4 +S315E63282200000000000000000536369662073706543 +S315E63282306564205550000000506C656173652063B5 +S315E632824068616E676520746F203436302E384B623D +S315E63282507073206261756420726174652073657429 +S315E632826074696E67206F6620746865207465726D10 +S315E6328270696E616C2E000000506C65617365206331 +S315E632828068616E676520746F203932312E364B62FD +S315E632829070732062617564207261746520736574E9 +S315E63282A074696E67206F6620746865207465726DD0 +S315E63282B0696E616C2E000000506C656173652063F1 +S315E63282C068616E676520746F203233302E344B62C6 +S315E63282D070732062617564207261746520736574A9 +S315E63282E074696E67206F6620746865207465726D90 +S315E63282F0696E616C2E000000203F2000000000000F +S315E6328300566572696679204572726F7200000000B0 +S315E632831020202020202020204D494E49206D6F6EA8 +S315E632832069746F7220636F6D6D616E640000000072 +S315E6328330204420207B73616472207B656164727DA2 +S315E63283407D202020202020202020206D656D6F7232 +S315E6328350792064756D70202028444D2073657473D8 +S315E63283602064756D702073697A6529000000000015 +S315E632837020444D207B427C577C4C7C587D20202005 +S315E63283802020202020202020202020736574266499 +S315E63283906973702064756D70206D6F6465000000D8 +S315E63283A0204620205B736164725D205B6561647290 +S315E63283B05D205B646174615D20202066696C6C20A9 +S315E63283C06D656D6F7279000020464C205B73616491 +S315E63283D0725D205B656164725D205B646174615DCA +S315E63283E020202066696C6C206D656D6F7279284C3B +S315E63283F04F4E472900000000204658205B736164E1 +S315E6328400725D205B656164725D205B646174615D99 +S315E632841020202066696C6C206D656D6F7279284C0A +S315E63284204F4E47204C4F4E472900000000000000D1 +S315E6328430204D20205B6164725D20202020202020A2 +S315E63284402020202020202020202020736574206DD5 +S315E6328450656D6F727928425954452900000000004D +S315E6328460204D57205B6164725D202020202020203B +S315E63284702020202020202020202020736574206DA5 +S315E6328480656D6F727928574F524429000000000015 +S315E6328490204D4C205B6164725D2020202020202016 +S315E63284A02020202020202020202020736574206D75 +S315E63284B0656D6F7279284C4F4E47290000000000F1 +S315E63284C0204D58205B6164725D20202020202020DA +S315E63284D02020202020202020202020736574206D45 +S315E63284E0656D6F7279284C4F4E47204C4F4E472971 +S315E63284F00000000000000000204D56205B736164E8 +S315E6328500725D205B646164725D205B6C656E5D20D4 +S315E63285102020206D6F7665206D656D6F727900006D +S315E63285202052414D434B205B736164725D205B653D +S315E63285306164722F4073697A655D2072616D20726D +S315E632854065616420777269746520636865636B007A +S315E632855020444452434B2020202020202020202035 +S315E63285602020202020202020202020444452206D26 +S315E6328570656D6F72792072656164207772697465AA +S315E632858020636865636B000020444452434B5F3296 +S315E632859052414E4B20202020202020202020202011 +S315E63285A0202020444452206D656D6F7279207265C3 +S315E63285B0616420777269746520636865636B202827 +S315E63285C04452414D5F53495A453D384742290000A8 +S315E63285D0204C202020202020202020202020202051 +S315E63285E020202020202020202020206C6F6164204D +S315E63285F070726F6772616D00204720207B737461FB +S315E632860072745F6164727D20202020202020202033 +S315E6328610202020676F2070726F6772616D000000EE +S315E6328620204C4620202020202020202020202020DA +S315E632863020202020202020202020206C6F616420FC +S315E632864050726F6772616D20746F20466C61736823 +S315E6328650206D656D6F7279207375622D626F617208 +S315E6328660640000000000000020434620202020203F +S315E632867020202020202020202020202020202020DC +S315E6328680202020436C65617220466C617368206DEA +S315E6328690656D6F7279207375622D626F61726400F1 +S315E63286A0205843532020202020202020202020201E +S315E63286B02020202020202020202020436C65617255 +S315E63286C020537069466C617368206F722048797000 +S315E63286D06572466C6173680020584C532020202020 +S315E63286E0202020202020202020202020202020206C +S315E63286F02020204C6F61642070726F6772616D2044 +S315E6328700746F20537069466C617368206F722048C5 +S315E632871079706572466C617368000000000000008D +S315E632872020584C5332202020202020202020202082 +S315E63287302020202020202020202020537069466CDD +S315E6328740617368206F72204879706572466C617320 +S315E632875068206164647265737320696E707574201D +S315E632876076657273696F6E206F6620584C53206356 +S315E63287706F6D6D616E6400002058494E464F5F5309 +S315E6328780413020202020202020202020202020209A +S315E6328790202020726561642053413020496E666F2F +S315E63287A0726D6174696F6E2028537069466C6173B7 +S315E63287B068206F72204879706572466C61736829F3 +S315E63287C000000000000000002058494E464F5F5335 +S315E63287D041305F53202020202020202020202020D8 +S315E63287E0202020736574202053413020496E666F0F +S315E63287F0726D6174696F6E2028537069466C617367 +S315E632880068206F72204879706572466C61736829A2 +S315E632881000000000000000002058494E464F202056 +S315E6328820202020202020202020202020202020202A +S315E6328830202020726561642053413320496E666F8B +S315E6328840726D6174696F6E2028537069466C617316 +S315E632885068206F72204879706572466C6173682952 +S315E632886000000000000000002058494E464F5F5394 +S315E632887020202020202020202020202020202020DA +S315E6328880202020736574202053413320496E666F6B +S315E6328890726D6174696F6E2028537069466C6173C6 +S315E63288A068206F72204879706572466C6173682902 +S315E63288B00000000000000000205355502020202002 +S315E63288C0202020202020202020202020202020208A +S315E63288D0202020536369662073706565642055509F +S315E63288E020284368616E676520746F20737065650C +S315E63288F064207570206261756420726174652073D6 +S315E6328900657474696E67290020524541445F504D5D +S315E632891049432020202020202020202020202020ED +S315E63289202020207265616420504D494320466972A3 +S315E63289306D776172652066726F6D20454550524F8E +S315E63289404D00000000000000205345545F504D496B +S315E632895043202020202020202020202020202020D6 +S315E63289602020207365742020504D49432046697293 +S315E63289706D7761726520746F20454550524F4D00D2 +S315E6328980205345545F494943302020202020202079 +S315E632899020202020202020202020207365742020CD +S315E63289A04949433020536C61766520416464726589 +S315E63289B0737300000000000020494943305F4D20C2 +S315E63289C05B6164725D20202020202020202020203A +S315E63289D0202020736574202049494330206D656D29 +S315E63289E06F7279284259544529000000000000008A +S315E63289F02048202020202020202020202020202031 +S315E6328A00202020202020202020202068656C70003F +S315E6328A1020576F726B204D656D6F7279202020205C +S315E6328A20203A2053797374656D52414D2000000029 +S315E6328A302056332E303320323031372E30382E32FE +S315E6328A403500000000000000522D43617220476572 +S315E6328A506E33205363696620446F776E6C6F61645A +S315E6328A60204D696E694D6F6E69746F720000000053 +S315E6328A705370616E73696F6E20666C6173682077C8 +S315E6328A80617320646574656374656420696E20611A +S315E6328A9072656120312028466C61736820426F61C7 +S315E6328AA07264292000000000466C61736820777292 +S315E6328AB0697465206275666665722073697A6520C1 +S315E6328AC0636F756C64206E6F7420626520676F74AF +S315E6328AD074656E202843464920436F6D6D616E6438 +S315E6328AE0204572726F7229200000000000000000F5 +S315E6328AF0466C617368206D656D6F7279206F66209C +S315E6328B003120696E2061726561206973206E6F74F9 +S315E6328B10205370616E73696F6E20284D616B657294 +S315E6328B2020436F6465202C204944204572726F7269 +S315E6328B302920000000000000205265616420206D85 +S315E6328B40616B6572436F6465203D203078000000C4 +S315E6328B5020526561642020646576494420202020CF +S315E6328B60203D203078000000466C617368207772CB +S315E6328B70697465206275666665722073697A652000 +S315E6328B80697320000000000020776F7264732E004E +S315E6328B90536563746F724572617365204661696CBB +S315E6328BA06564203A20666C61736820657261736526 +S315E6328BB02074696D656F75742061742061646472C0 +S315E6328BC0657373203078000020726561644461749F +S315E6328BD06120307800000000292E000000000000F7 +S315E6328BE0457261736520436F6D706C65746564209A +S315E6328BF00000000000000000577269746520466185 +S315E6328C00696C6564203A20666C61736820777269AE +S315E6328C1074652074696D656F75742061742061645C +S315E6328C20647265737320307800000000000000003D +S315E6328C302877726974654461746120307800000081 +S315E6328C405772697465204661696C6564203A2066B6 +S315E6328C506C6173682077726974652061626F7274CB +S315E6328C602061742061646472657373203078000023 +S315E6328C70577269746520436F6D706C6574656420EE +S315E6328C8000000000000000004F6E20426F61726401 +S315E6328C9020464C415348204D454D4F525920414C82 +S315E6328CA04C20434C4541522E2E2E20506C65617334 +S315E6328CB06520776169742000436F6D706C65746503 +S315E6328CC06420000000000000577269746520466130 +S315E6328CD0696C6564203A20666C61736820777269DE +S315E6328CE074652074696D656F75742044657669635B +S315E6328CF06520486967682E20000000000000000003 +S315E6328D005772697465204661696C6564203A2066F5 +S315E6328D106C6173682077726974652074696D656F04 +S315E6328D20757420446576696365204C6F772E20002C +S315E6328D305772697465204661696C6564203A2066C5 +S315E6328D406C6173682077726974652061626F7274DA +S315E6328D502044657669636520486967682E20000097 +S315E6328D605772697465204661696C6564203A206695 +S315E6328D706C6173682077726974652061626F7274AA +S315E6328D8020446576696365204C6F772E20000000B5 +S315E6328D904572617365204661696C6564203A2045A1 +S315E6328DA0726173652054696D656F757420446576B4 +S315E6328DB02048696768204572726F720000000000CB +S315E6328DC04572617365204661696C6564203A204571 +S315E6328DD0726173652054696D656F75742044657684 +S315E6328DE0204C6F77204572726F72000000000000E9 +S315E6328DF0466C61736820426F617264204D454D4F11 +S315E6328E00525920414C4C20434C4541522E2E2E206F +S315E6328E10506C6561736520776169742000000000E5 +S315E6328E204572617365204572726F7200000000000A +S315E6328E303D3D3D2052414D20434845434B20284255 +S315E6328E407974652041636365737329203D3D3D3D03 +S315E6328E5000000000000000002D2D204D617263688F +S315E6328E60696E67204461746120436865636B202DC1 +S315E6328E702D2D2D2D2D2D2D2D00000000000000006C +S315E6328E802020205B205772697465204827303020CF +S315E6328E902020202020202020202020202020205D77 +S315E6328EA000000000000000002020205B20436865B9 +S315E6328EB0636B2048273030202D3E20577269746521 +S315E6328EC0204827353520205D0000000000000000EE +S315E6328ED02020205B20436865636B204827353520A2 +S315E6328EE02D3E205772697465204827414120205D20 +S315E6328EF000000000000000002020205B2043686569 +S315E6328F00636B2048274141202D3E205772697465AE +S315E6328F10204827464620205D00000000000000007B +S315E6328F202020205B20436865636B2048274646202F +S315E6328F302020202020202020202020202020205DD6 +S315E6328F4000000000000000002D2D204465636F64AA +S315E6328F506572205061747465726E20436865636B20 +S315E6328F60202D2D2D2D2D2D2D000000000000000088 +S315E6328F702020205B20577269746520482730302CD2 +S315E6328F80482730312C48273032202E2E2E20205DAF +S315E6328F9000000000000000002020205B20436865C8 +S315E6328FA0636B20482730302C482730312C4827301F +S315E6328FB032202E2E2E20205D00000000000000001A +S315E6328FC0434845434B20524553554C542000000006 +S315E6328FD02D2D2D2D2D2D2D2D2D3E4E47000000000B +S315E6328FE04552524F5220414444524553533A000079 +S315E6328FF04552524F5220444154412020203A0000F5 +S315E6329000545255452044415441202020203A00000E +S315E63290102D2D2D2D2D2D2D2D2D3E4F4B00000000C5 +S315E63290205265616420504D49432D454550524F4D68 +S315E632903020204F4B3F28792F6E2900000000000092 +S315E63290402020506C6561736520496E7075742053C5 +S315E63290506C61766520616464726573732000000024 +S315E632906020205365742041646472657373203A2016 +S315E63290704827000000000000202053796E7461789C +S315E6329080204572726F7200003D3D3D3D3D3D3D3DB0 +S315E63290903D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3DE2 +S315E63290A03D3D3D3D3D3D3D3D0000000000000000BA +S315E63290B03D3D3D20205370656369616C2073656C76 +S315E63290C0656374696F6E206D656E7520203D3D3D34 +S315E63290D000000000000000002031203A207878783F +S315E63290E0787878787878787878782020482736309D +S315E63290F000000000000000002032203A207979791B +S315E63291007979797979797979797920204827413067 +S315E632911000000000000000002020506C6561736597 +S315E63291202073656C6563742028312D3229203E0022 +S315E63291304E6F7720494943302D534C4156452041AF +S315E63291404444524553533A48270000000000000093 +S315E63291502030203A20494E50555420534C415645FC +S315E6329160204144445245535320000000000000009B +S315E63291702031203A20506F776572204943204244A7 +S315E6329180393537314D57562D4D2020482736300062 +S315E63291902032203A20454550524F4D202020425229 +S315E63291A0323454303146564D2D5720482741300019 +S315E63291B02020506C656173652073656C6563742037 +S315E63291C028302D3229203E00202053657420494925 +S315E63291D043302D534C415645204144445245535330 +S315E63291E0203A204827000000504D49432D50726FF1 +S315E63291F064756374205265766973696F6E203A20B8 +S315E632920000000000000000004E6F77205265616470 +S315E632921020504D49432D454550524F4D20466972B1 +S315E63292206D77617265205265762E00000000000089 +S315E632923055706461746520746865204669726D7727 +S315E632924061726520526576206F6620504D49432D10 +S315E6329250454550524F4D2E4F4B3F28792F6E2900BA +S315E6329260577269746520504D49432D454550524FE4 +S315E63292704D204669726D77617265205265762E00AB +S315E6329280204F4B3F28792F6E290000000000000060 +S315E632929057726974652E2E2E636F6D706C657465C2 +S315E63292A02E000000000000005265616420504D49F0 +S315E63292B0432D454550524F4D000000000000000058 +S315E63292C04E6F7720493243302D534C415645204135 +S315E63292D04444524553533A48270000000000000002 +S315E63292E0206572726F7220616464726573732020D0 +S315E63292F03A20482700000000206572726F722064B9 +S315E632930061746120202020203A20482700000000A0 +S315E632931020747275652020646174612020202020D5 +S315E63293203A20482700000000446174613D307835C2 +S315E63293304135413541354100446174613D307841CC +S315E63293403541354135413500446174613D307831D8 +S315E632935032333435363738003D3D3D2044445220AB +S315E6329360522F5720434845434B203D3D3D3D000075 +S315E63293703D3D3D204D656D6F7279206D61702048B9 +S315E632938033203D3D3D3D0000436865636B3A3078B8 +S315E632939030345F3130303030303030202E2E2E20A1 +S315E63293A00000000000000000204661696C210000E2 +S315E63293B04E657874206368616E6E656C20546573AB +S315E63293C074204F4B3F28792F6E29000000000000AB +S315E63293D02050617373210000436865636B3A3078D7 +S315E63293E030355F3030303030313030202E2E2E2050 +S315E63293F00000000000000000436865636B3A30788F +S315E632940030365F3030303030313030202E2E2E202E +S315E63294100000000000000000436865636B3A30786E +S315E632942030375F3030303030313030202E2E2E200D +S315E632943000000000000000003D3D3D204D656D6FA9 +S315E63294407279206D6170204D33203D3D3D3D000001 +S315E63294503D3D3D202056334D20203D3D3D3D0000ED +S315E63294603D3D3D2020443320203D3D3D3D0000003C +S315E63294704E65787420417265612054657374204F67 +S315E63294804B3F28792F6E2900436865636B3A30780D +S315E632949030345F3430303030303030202E2E2E209D +S315E63294A00000000000000000436865636B3A3078DE +S315E63294B030355F3430303030303030202E2E2E207C +S315E63294C00000000000000000436865636B3A3078BE +S315E63294D030365F3430303030303030202E2E2E205B +S315E63294E00000000000000000436865636B3A30789E +S315E63294F030375F3430303030303030202E2E2E203A +S315E63295000000000000000000436865636B3A30787D +S315E632951030345F3830303030303030202E2E2E2018 +S315E63295200000000000000000436865636B3A30785D +S315E632953030365F3830303030303030202E2E2E20F6 +S315E632954000000000000000003D3D3D20436F6D6D9A +S315E6329550616E6473206E6F742065786563757465C3 +S315E6329560642E20284561676C6520626F61726420DD +S315E63295706973203147427974652E29203D3D3D0097 +S315E63295803D3D3D20436F6D6D616E6473206E6F7443 +S315E63295902065786563757465642E203D3D3D000031 +S315E63295A052414D20436865636B203A204E470000B0 +S315E63295B02020506C6561736520496E70757420445F +S315E63295C06174612000000000202053657420426FEA +S315E63295D06164204944203A20482700000000000012 +S315E63295E04E6F7720426F726164204944203A2000FA +S315E63295F020284827000000004368616E67652042EE +S315E63296006F617264204944204F4B3F2028792F6E92 +S315E632961029000000000000002030203A20494E5052 +S315E6329620555420424F41524420494420202020209E +S315E632963020202020202020002031203A2053616C41 +S315E63296407661746F722D582020202020202020202B +S315E632965020284827303029002032203A204B7269BA +S315E6329660656B20202020202020202020202020204C +S315E632967020284827303829002033203A205374618F +S315E632968072746572204B69742050726F20202020E6 +S315E632969020284827313029002034203A2053616C7D +S315E63296A07661746F722D5853202020202020202098 +S315E63296B020284827323029002035203A2044726164 +S315E63296C0616B2020202020202020202020202020F0 +S315E63296D020284827333829002036203A2053746129 +S315E63296E072746572204B6974205072656D69657263 +S315E63296F020284827353829002039203A2045786906 +S315E632970074202020202020202020202020202020E7 +S315E632971020202020202020002020506C65617365B1 +S315E63297202073656C6563742028302D36206F72207F +S315E63297303929203E00000000202020496E69744D0A +S315E632974061696E52504320202848335F455331587B +S315E6329750202F204D335F455331302920000000005B +S315E6329760202020496E69744D61696E52504320203D +S315E63297702856334D29200000636F6E666967526557 +S315E632978067284352315629203A48272000000000FE +S315E632979051554144206D6F6465207365742100002E +S315E63297A0506C656173652073656C6563742C466CC3 +S315E63297B06173684D656D6F72792E20000000000088 +S315E63297C020202031203A2051737069466C617368E5 +S315E63297D020202020202020285535203A20533235A5 +S315E63297E0465331323853290020202032203A20514E +S315E63297F0737069466C61736820426F6172642028C1 +S315E6329800434E323A20533235464C353132532900BD +S315E632981020202032203A2051737069466C61736893 +S315E632982020426F6172642028434E333A20533235F2 +S315E6329830464C35313253290020202033203A20480F +S315E632984079706572466C6173682020202020202864 +S315E63298505538363A205332364B5335313253290060 +S315E632986020202033203A204879706572466C61733F +S315E63298706820202020202028553131303A205332B4 +S315E6329880364B5335313253290000000000000000D2 +S315E632989020202033203A204879706572466C61730F +S315E63298A0682020202020202853695020696E74656E +S315E63298B0726E616C29000000202053656C65637414 +S315E63298C02028312D33293E0020202031203A2051DE +S315E63298D0737069466C6173685F3132384D626974AA +S315E63298E02028553720203A205332354653313238FE +S315E63298F0532900000000000020202032203A205171 +S315E6329900737069466C61736820426F6172642020B7 +S315E63299102028434E31383A20533235464C353132A9 +S315E6329920532900000000000020202033203A20513F +S315E6329930737069466C6173685F3531324D6269744C +S315E63299402028553620203A205332354653353132A1 +S315E6329950532900000000000020444556494345207D +S315E632996046414D495259204944204572726F722E0C +S315E632997020506C6561736520636865636B20737727 +S315E6329980697463682073657474696E6720000000D3 +S315E632999020524541442046414D49525920494420B8 +S315E63299A03D20307800000000202846535F535F465C +S315E63299B0414D494C592900002028464C5F535F46B3 +S315E63299C0414D494C592900002044455649434520E4 +S315E63299D04944204572726F722E20506C656173650A +S315E63299E020636865636B2073776974636820736591 +S315E63299F07474696E6720000020524541442049441A +S315E6329A00203D203078000000204E6F74653A2054AF +S315E6329A106865206C6F7765722032342D6269742000 +S315E6329A206F6E6C792069732076616C69642E2028B4 +S315E6329A3055707065722038206269747320697420B5 +S315E6329A406973206D61736B2E2900000000000000F9 +S315E6329A502052454144204944204F4B2E0000000017 +S315E6329A60205365742044617461203A200000000078 +S315E6329A70535049204461746120436C6561722848CB +S315E6329A802746462920436865636B203A0000000084 +S315E6329A902D000000000000002C436C656172204FF9 +S315E6329AA04B3F28792F6E29002045786974200000CD +S315E6329AB0204F4B20000000002045726173696E67C5 +S315E6329AC02E000000000000004827303030303030BB +S315E6329AD030302D48273030303037464646000000A3 +S315E6329AE03D3D3D3D3D20517370692F487970657233 +S315E6329AF0466C6173682077726974696E67206F6641 +S315E6329B002047656E3320426F61726420436F6D6D16 +S315E6329B10616E64203D3D3D3D3D3D3D3D00000000EC +S315E6329B204C6F61642050726F6772616D20746F207C +S315E6329B30537069666C6173680000000000000000CD +S315E6329B402D2D2D2D2D2D2D2D2D2D2D2D2D2D2D2D27 +S315E6329B502D2D2D2D2D2D2D2D2D2D2D2D2D2D2D2D17 +S315E6329B602D2D2D2D2D2D2D2D2D2D2D2D2D2D2D2D07 +S315E6329B702D2D2D2D2D2D2D2D2D2D2D2D00000000AB +S315E6329B80506C656173652073656C6563742C5173CD +S315E6329B9070692F4879706572466C617368205361D5 +S315E6329BA0766520417265612E2000000000000000D5 +S315E6329BB03D3D204C6F616465722050726F6772610B +S315E6329BC06D203A2050726F6772616D20746F206530 +S315E6329BD0786563757465206F6E2053797374656D37 +S315E6329BE052414D203D3D3D3D3D3D3D3D000000006F +S315E6329BF020202031203A20412D5369646520535086 +S315E6329C00495F41646472657373203D20482720308C +S315E6329C1030345F303030302D4827203030375F46AB +S315E6329C204646462020202020202020200000000024 +S315E6329C3020202032203A20422D5369646520535043 +S315E6329C40495F41646472657373203D20482720304C +S315E6329C5030385F303030302D4827203030425F465C +S315E6329C6046464620202020202020202000000000E4 +S315E6329C703D3D20557365722050726F6772616D2075 +S315E6329C803A2050726F6772616D20746F206578651F +S315E6329C9063757465206F6E204452414D206F722093 +S315E6329CA053797374656D52414D203D3D0000000097 +S315E6329CB020202033203A20202020202020205350F6 +S315E6329CC0495F41646472657373203D2048272030CC +S315E6329CD031305F303030302D4827203346465F46C6 +S315E6329CE04646462020202020202020200000000064 +S315E6329CF0202053656C656374206172656128312D67 +S315E6329D0033293E00000000002D2D204C6F6164653C +S315E6329D10722050726F6772616D202D2D2D2D2D2D8D +S315E6329D202D2D2D2D2D2D2D2D2D2D2D2D2D2D2D2D45 +S315E6329D302D2D2D2D000000002D2D20557365722018 +S315E6329D4050726F6772616D202D2D2D2D2D2D2D2D95 +S315E6329D502D2D2D2D2D2D2D2D2D2D2D2D2D2D2D2D15 +S315E6329D602D2D2D2D00000000506C6561736520495E +S315E6329D706E70757420557365722050726F677261B4 +S315E6329D806D20537461727420416464726573732014 +S315E6329D903A20000000000000576F726B2052414DA8 +S315E6329DA028482735303030303030302D4827353078 +S315E6329DB03032464646462920436C6561722E2E2E51 +S315E6329DC02E00000000000000576F726B2052414DA4 +S315E6329DD028482735303030303030302D4827353345 +S315E6329DE04646464646462920436C6561722E2E2EF7 +S315E6329DF02E000000000000005341564520535049DC +S315E6329E002D464C4153482E2E2E2E2E2E2E00000057 +S315E6329E1020636F6D706C657465210000000000008A +S315E6329E20205772697465427566666520577269743B +S315E6329E306520000000000000205772697474656E72 +S315E6329E4053697A652020202020203A4827200000D0 +S315E6329E502052656D61696E696E6753697A6520204F +S315E6329E6020203A4827200000537069417265612006 +S315E6329E703A20482730303030303030302D482730AF +S315E6329E80304646464646460053706941726561201B +S315E6329E903A20482730313030303030302D4827308E +S315E6329EA033464646464646002D2D20536176652094 +S315E6329EB02850726F6772616D2053746172742041F5 +S315E6329EC064647265737320262053697A6520292085 +S315E6329ED02D2D2D2D2D0000005350492044617461FD +S315E6329EE020436C6561722848274646293A48273028 +S315E6329EF030303030302D3033464646462045726174 +S315E6329F0073696E672E0000005350492044617461CE +S315E6329F1020436C6561722848274646293A482730F7 +S315E6329F2043303030302D304646464646204572611D +S315E6329F3073696E672E0000003D3D3D3D3D3D3D3D3C +S315E6329F403D3D2020517370692F4879706572466CB3 +S315E6329F50617368205361766520496E666F726D610C +S315E6329F6074696F6E20203D3D3D3D3D3D3D3D3D3D77 +S315E6329F703D3D3D3D3D3D3D002050726F6772616D20 +S315E6329F802053746172742041646472657373203A45 +S315E6329F9020204827000000002050726F6772616DFC +S315E6329FA02053697A652028427974652F3429203A16 +S315E6329FB020204827000000003D3D3D3D3D3D3D3DEC +S315E6329FC03D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3DA3 +S315E6329FD03D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D93 +S315E6329FE03D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D83 +S315E6329FF03D3D3D3D3D3D3D002020506C65617365FE +S315E632A00020496E707574203A204827000000000019 +S315E632A0103D3D3D3D3D20517370692F4879706572FD +S315E632A020466C6173682077726974696E67206F660B +S315E632A0302047656E3320426F61726420436F6D6DE1 +S315E632A040616E64203D3D3D3D3D3D3D3D3D3D3D3DC3 +S315E632A0503D00000000000000577269746573207493 +S315E632A0606F20616E79206F662053504920616464B1 +S315E632A070726573732E00000050726F6772616D20DF +S315E632A080546F70204164647265737320262051736F +S315E632A09070692F4879706572466C617368205361D0 +S315E632A0A076652041646472657373200000000000B1 +S315E632A0B03D3D3D3D3D20506C6561736520496E7090 +S315E632A0C075742050726F6772616D20546F702041DD +S315E632A0D0646472657373203D3D3D3D3D3D3D3D3D98 +S315E632A0E03D3D3D00000000003D3D3D3D3D20506C8E +S315E632A0F06561736520496E70757420517370692F88 +S315E632A1004879706572466C6173682053617665206C +S315E632A11041646472657373203D3D3D000000000084 +S315E632A1204164647265737320496E70757420457244 +S315E632A130726F72000000000052616E6765206F66CC +S315E632A1402048273030305F30303030207E20482786 +S315E632A1503046465F374646460000000000000000BD +S315E632A16052616E6765206F662048273030305F3041 +S315E632A170303030207E2048273346465F46464646CE +S315E632A180000000000000000050726F6772616D20B9 +S315E632A1906F7665722073697A65204572726F7200E0 +S315E632A1A020537069466C6173684D656D6F727920BE +S315E632A1B0537461742041646472657373203A20483D +S315E632A1C0270000000000000020537069466C617378 +S315E632A1D0684D656D6F727920456E642041646472AE +S315E632A1E065737320203A20482700000000000000FD +S315E632A1F03D3D3D3D3D3D3D20517370692F48797079 +S315E632A2006572466C617368205361766520496E667F +S315E632A2106F726D6174696F6E20203D3D3D3D3D3D09 +S315E632A2203D3D3D3D3D3D3D3D3D3D3D000000000071 +S315E632A2303D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D30 +S315E632A2403D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D20 +S315E632A2503D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D10 +S315E632A2603D3D3D3D3D3D3D3D3D3D3D000000000031 +S315E632A2703D3D3D2053504920534130205379737446 +S315E632A280656D204172656120496E666F726D6174E5 +S315E632A290696F6E20203D3D3D000000000000000063 +S315E632A2A020426F6F7420524F4D20506172616D6558 +S315E632A2B07465727320202020202020202020202042 +S315E632A2C02020202020203A204827000000000000E7 +S315E632A2D020412D736964652049504C20416464728D +S315E632A2E0657373202020284C6F6164657220416461 +S315E632A2F06472657373293A2048270000000000002D +S315E632A30020412D736964652049504C20646174613D +S315E632A3102073697A6520284C6F61646572207369A9 +S315E632A3207A65292020203A204827000000000000DE +S315E632A33020422D736964652049504C20416464722B +S315E632A340657373202020284C6F6164657220416400 +S315E632A3506472657373293A204827000000000000CC +S315E632A36020422D736964652049504C2064617461DC +S315E632A3702073697A6520284C6F6164657220736949 +S315E632A3807A65292020203A2048270000000000007E +S315E632A3903D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3DCF +S315E632A3A03D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3DBF +S315E632A3B03D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3DAF +S315E632A3C03D3D000000000000204368616E6765206F +S315E632A3D03F28592F4E29000020506C65617365205F +S315E632A3E0496E707574204E6577204461746120003B +S315E632A3F0535049204461746120436C656172284842 +S315E632A400274646293A48273030303030302D3030FC +S315E632A410314646462045726173696E672E00000004 +S315E632A4203D3D3D2053504920534133205379737491 +S315E632A430656D204172656120496E666F726D617433 +S315E632A440696F6E20203D3D3D0000000000000000B1 +S315E632A4502050726F6772616D205374617274204157 +S315E632A460646472657373203A204827000000000060 +S315E632A4702050726F6772616D2053697A6520284281 +S315E632A4807974652F3429203A2048270000000000E7 +S315E632A490414C4C20455241534520537069466C61D6 +S315E632A4A07368206F72204879706572466C6173689C +S315E632A4B0206D656D6F7279200000000000000000A5 +S315E632A4C0436C656172204F4B3F28792F6E29000027 +S315E632A4D020455241534520515350492D464C41531E +S315E632A4E048202836307365635B7479705D292E2E83 +S315E632A4F02E2E0000000000002045524153452051E1 +S315E632A5005350492D464C41534820283130337365F2 +S315E632A510635B7479705D292E2E2E2E0000000000C4 +S315E632A5202045524153452048595045522D464C41D5 +S315E632A5305348202839367365635B7479705D292E04 +S315E632A5402E2E2E0000000000204552415345205162 +S315E632A5505350492D464C41534820283232307365A2 +S315E632A560635B7479705D292E2E2E2E000000000074 +S315E632A570506C656173652073656C6563742E000095 +S315E632A580202020202020202046726F6D2020202099 +S315E632A59020202020202D2D2D3E20202020546F00F5 +S315E632A5A02031203A2051537069466C617368202017 +S315E632A5B020202020202D2D2D3E20487970657246AA +S315E632A5C06C617368000000002032203A20515370E5 +S315E632A5D069466C617368202020202020202D2D2D9F +S315E632A5E03E2051737069466C61736820426F6172C0 +S315E632A5F064000000000000002033203A20487970DB +S315E632A6006572466C6173682020202020202D2D2D20 +S315E632A6103E2051537069466C617368000000000053 +S315E632A6202034203A204879706572466C6173682028 +S315E632A63020202020202D2D2D3E2051737069466C28 +S315E632A64061736820426F61726400000000000000A8 +S315E632A6502035203A2051737069466C617368204220 +S315E632A6606F617264202D2D2D3E2051537069466CF2 +S315E632A67061736800000000002036203A205173707C +S315E632A68069466C61736820426F617264202D2D2DA6 +S315E632A6903E204879706572466C6173680000000048 +S315E632A6A0202053656C6563742028312D36293E00A9 +S315E632A6B0202020202020202046726F6D2020202068 +S315E632A6C020202020202020202D2D2D3E2020202027 +S315E632A6D0546F0000000000002031203A20515370BA +S315E632A6E069466C617368283132384D62697429205D +S315E632A6F02D2D2D3E2051537069466C61736828358F +S315E632A70031324D62697429002032203A2051537033 +S315E632A71069466C617368283132384D62697429202C +S315E632A7202D2D2D3E2051737069466C617368204239 +S315E632A7306F617264202020002033203A2051537014 +S315E632A74069466C617368283531324D6269742920FF +S315E632A7502D2D2D3E2051537069466C617368283132 +S315E632A76032384D62697429002034203A20515370CA +S315E632A77069466C617368283531324D6269742920CF +S315E632A7802D2D2D3E2051737069466C6173682042D9 +S315E632A7906F617264202020002035203A2051737092 +S315E632A7A069466C61736820426F61726420202020AC +S315E632A7B02D2D2D3E2051537069466C6173682831D2 +S315E632A7C032384D62697429002036203A2051737048 +S315E632A7D069466C61736820426F617264202020207C +S315E632A7E02D2D2D3E2051537069466C61736828359E +S315E632A7F031324D626974290053616C7661746F72D7 +S315E632A8000000000000000000537461727465722025 +S315E632A8104B697400000000006E6F742073757070B9 +S315E632A8206F7274656400000051537069466C6173E9 +S315E632A83068000000000000004879706572466C6177 +S315E632A840736800000000000051737069466C6173EC +S315E632A8506820426F6172640051537069466C617367 +S315E632A86068283531324D62697429000000000000ED +S315E632A8703D3D3D20636F707920577269746520627B +S315E632A88065747765656E2074686520466C617368B3 +S315E632A890206D656D6F72792028636F7079207369E2 +S315E632A8A07A65203D2031364D4279746529203D3D23 +S315E632A8B03D00000000000000536F75726365203D6F +S315E632A8C02000000000000000204C6F616420466CD8 +S315E632A8D0617368206461746120746F2052414D2839 +S315E632A8E0482735303030303030302D292E2E2E0076 +S315E632A8F0436C65617220576F726B2052414D284820 +S315E632A9002735303030303030302D482735334646ED +S315E632A91046464646290000006F6B000000000000FE +S315E632A92044657374696E6174696F6E203D2000000A +S315E632A93020506172616D65746572536563746F72C8 +S315E632A94045726173652E2E2E00000000000000006F +S315E632A95020536563746F7245726173652E2E2E00CF +S315E632A9602057726974652052616D20646174612084 +S315E632A970746F20466C617368204D656D6F72792E01 +S315E632A9802E2E0000000000003D3D20536574204522 +S315E632A99078742052656164204D6F6465202852656D +S315E632A9A06164204F6E6C7929202020203D3D0000DF +S315E632A9B03D3D20466F72204F6E626F617264202F84 +S315E632A9C02051737069466C617368202848273030A7 +S315E632A9D02D2020293D3D00003D3D204827303830A8 +S315E632A9E0305F303030302D4827304246465F464675 +S315E632A9F04646202020202020202020203D3D0000F3 +S315E632AA00536574204578742052656164204D6F64CF +S315E632AA10652E0000000000003D3D3D2053504920A2 +S315E632AA205341302053797374656D204172656120E6 +S315E632AA30496E666F726D6174696F6E2028204D615C +S315E632AA40736B524F4D2070726F6772616D2064651B +S315E632AA507369676E20417070656E64697820292065 +S315E632AA603D3D3D000000000020426F6F7420524F9C +S315E632AA704D20506172616D657465727320202020B7 +S315E632AA803A2048270000000020466C61736820436E +S315E632AA906C6F636B20506172616D6574657273209B +S315E632AAA03A204827000000002044756D6D79204330 +S315E632AAB079636C6520506172616D65746572732077 +S315E632AAC03A20482700000000454550524F4D20496E +S315E632AAD06E6974696C697A65204572726F720000C6 +S315E632AAE020454550524F4D206572726F7220616431 +S315E632AAF0647265737320203A20482700000000000E +S315E632AB0020454550524F4D206572726F7220646110 +S315E632AB10746120202020203A2048270000000000D9 +S315E632AB2020454550524F4D207365742064617461F9 +S315E632AB30202020202020203A20482700000000004E +S315E632AB40203D3D3D3D3D205265616420506D696351 +S315E632AB50456570726F6D44617461203D3D3D3D3DA4 +S315E632AB6000000000000000002020202020202020C7 +S315E632AB7020202020202020202020202020504D4931 +S315E632AB8043284F4C442920202020202020202F20E5 +S315E632AB902020202020504D4943284E455729000093 +S315E632ABA02020204827000000202028203030682048 +S315E632ABB020436F6E6E656374696F6E2043686563B4 +S315E632ABC06B20436F6465202F20436F6E6E65637428 +S315E632ABD0696F6E20436865636B20436F646529004F +S315E632ABE0202028203031682020454550524F4D20CE +S315E632ABF04657205265766973696F6E202020202F7C +S315E632AC0020454550524F4D20465720526576697358 +S315E632AC10696F6E2900000000202028203032682035 +S315E632AC2020504F57205472696767657220445646FC +S315E632AC30532020202020202F20504F57205472694F +S315E632AC4067676572204456465329000000000000C5 +S315E632AC50202028203033682020504F5720547269FE +S315E632AC606767657220564430392020202020202F0F +S315E632AC7020504F57205472696767657220564430C2 +S315E632AC8039290000000000002020282030346820D0 +S315E632AC9020504F5720547269676765722044445292 +S315E632ACA0302020202020202F20504F572054726902 +S315E632ACB0676765722044445230290000000000007E +S315E632ACC0202028203035682020504F57205472698C +S315E632ACD06767657220444452312020202020202F97 +S315E632ACE020504F5720547269676765722044445242 +S315E632ACF03129000000000000202028203036682066 +S315E632AD0020504F5720547269676765722056443130 +S315E632AD10382020202020202F20504F572054726989 +S315E632AD206767657220564431382900000000000014 +S315E632AD30202028203037682020504F572054726919 +S315E632AD406767657220564433332020202020202F31 +S315E632AD5020504F57205472696767657220564433DE +S315E632AD6033290000000000002020282030386820F1 +S315E632AD7020504F57205472696767657220534430C4 +S315E632AD80202020202020202F20504F572054726931 +S315E632AD9067676572205344302900000000000000E0 +S315E632ADA0202028203039682020504F5720547269A7 +S315E632ADB06767657220534431202020202020202FD9 +S315E632ADC020504F5720547269676765722053443173 +S315E632ADD029000000000000002020282030416820AB +S315E632ADE020504F5720547269676765722053443252 +S315E632ADF0202020202020202F20504F5720547269C1 +S315E632AE00676765722053443229000000000000006D +S315E632AE10202028203042682020504F57205472692D +S315E632AE206767657220534433202020202020202F66 +S315E632AE3020504F5720547269676765722053443300 +S315E632AE402900000000000000202028203043682038 +S315E632AE5020504F57205472696767657220564432DE +S315E632AE60352020202020202F20504F57205472693B +S315E632AE7067676572205644323529000000000000C5 +S315E632AE80202028203044682020504F5720547269BB +S315E632AE906767657220444452304320202020202FB3 +S315E632AEA020504F5720547269676765722044445280 +S315E632AEB03043290000000000202028203045682053 +S315E632AEC020504F5720547269676765722044445260 +S315E632AED0314320202020202F20504F5720547269AC +S315E632AEE06767657220444452314329000000000008 +S315E632AEF0202028203046682020504F572054726949 +S315E632AF006767657220505245534554422020202FBA +S315E632AF1020504F5720547269676765722050524502 +S315E632AF20534554422900000020202820313068203B +S315E632AF3020504F5720576169742044564653202095 +S315E632AF40202020202020202F20504F57205761697D +S315E632AF507420445646532900202028203131682071 +S315E632AF6020504F5720576169742056443039202095 +S315E632AF70202020202020202F20504F57205761694D +S315E632AF807420564430392900202028203132682070 +S315E632AF9020504F572057616974204444523020205E +S315E632AFA0202020202020202F20504F57205761691D +S315E632AFB07420444452302900202028203133682038 +S315E632AFC020504F572057616974204444523120202D +S315E632AFD0202020202020202F20504F5720576169ED +S315E632AFE07420444452312900202028203134682006 +S315E632AFF020504F5720576169742056443138202005 +S315E632B000202020202020202F20504F5720576169BC +S315E632B01074205644313829002020282031356820DC +S315E632B02020504F57205761697420564433332020D7 +S315E632B030202020202020202F20504F57205761698C +S315E632B04074205644333329002020282031366820AE +S315E632B05020504F57205761697420534430202020C0 +S315E632B060202020202020202F20504F57205761695C +S315E632B07074205344302900002020282031376820B6 +S315E632B08020504F572057616974205344312020208F +S315E632B090202020202020202F20504F57205761692C +S315E632B0A07420534431290000202028203138682084 +S315E632B0B020504F572057616974205344322020205E +S315E632B0C0202020202020202F20504F5720576169FC +S315E632B0D07420534432290000202028203139682052 +S315E632B0E020504F572057616974205344332020202D +S315E632B0F0202020202020202F20504F5720576169CC +S315E632B1007420534433290000202028203141682018 +S315E632B11020504F57205761697420564432352020E5 +S315E632B120202020202020202F20504F57205761699B +S315E632B13074205644323529002020282031426820B0 +S315E632B14020504F5720576169742044445230432089 +S315E632B150202020202020202F20504F57205761696B +S315E632B16074204444523043290000000000000000B7 +S315E632B170202028203143682020504F5720576169D6 +S315E632B1807420444452314320202020202020202F90 +S315E632B19020504F572057616974204444523143292F +S315E632B1A000000000000000002020282031446820FC +S315E632B1B020504F4E205761697420505245534554BC +S315E632B1C0422020202020202F20504F4E20576169E2 +S315E632B1D0742050524553455442290000000000007F +S315E632B1E02020282031456820204156532053746169 +S315E632B1F072742054696D20436E7420202020202FED +S315E632B200204156532053746172742054696D20433B +S315E632B2106E7429000000000020202820314668207E +S315E632B2202041565320564430392056494420302060 +S315E632B230202020202020202F2041565320564430ED +S315E632B240392056494420302900000000000000002B +S315E632B250202028203230682020415653205644306A +S315E632B2603920564944203120202020202020202F04 +S315E632B2702041565320564430392056494420312906 +S315E632B280000000000000000020202820323168202D +S315E632B29020415653205644303920564944203220EE +S315E632B2A0202020202020202F20415653205644307D +S315E632B2B039205649442032290000000000000000B9 +S315E632B2C020202820323268202041565320564430F8 +S315E632B2D03920564944203320202020202020202F92 +S315E632B2E02041565320564430392056494420332994 +S315E632B2F000000000000000002020282032336820BB +S315E632B300204156532044564653205649442030204F +S315E632B310202020202020202F2041565320445646F6 +S315E632B3205320564944203029000000000000000030 +S315E632B330202028203234682020415653204456466F +S315E632B3405320564944203120202020202020202F09 +S315E632B35020415653204456465320564944203129F5 +S315E632B3600000000000000000202028203235682048 +S315E632B37020415653204456465320564944203220DD +S315E632B380202020202020202F204156532044564686 +S315E632B39053205649442032290000000000000000BE +S315E632B3A020202820323668202041565320445646FD +S315E632B3B05320564944203320202020202020202F97 +S315E632B3C02041565320445646532056494420332983 +S315E632B3D000000000000000002020282032376820D6 +S315E632B3E020445646532056696E6974202020202022 +S315E632B3F0202020202020202F2041565320454E293A +S315E632B40000000000000000002020282032386820A4 +S315E632B410204456465320536574566D617820202073 +S315E632B420202020202020202F2056443039205669ED +S315E632B4306E697429000000002020282032396820FF +S315E632B44020564431382056494420202020202020D8 +S315E632B450202020202020202F20445646532056698D +S315E632B4606E697429000000002020282032416820C7 +S315E632B47020564432352056494420202020202020AA +S315E632B480202020202020202F204456465320536564 +S315E632B49074566D61782900002020282032426820D1 +S315E632B4A0205644333320564944202020202020207B +S315E632B4B0202020202020202F207265736572766543 +S315E632B4C0642900000000000020202820324368204C +S315E632B4D02043524320436865636B20436F6465209D +S315E632B4E0202020202020202F20504F5720536F66D1 +S315E632B4F07453746172742031290000000000000032 +S315E632B5002020282032446820202D2020202020208A +S315E632B5102020202020202020202020202020202FFE +S315E632B52020504F5720536F667453746172742032CB +S315E632B530290000000000000020202820324568203D +S315E632B540202D2020202020202020202020202020D0 +S315E632B550202020202020202F20504F5720536F6660 +S315E632B56074537461727420332900000000000000BF +S315E632B5702020282032466820202D20202020202018 +S315E632B5802020202020202020202020202020202F8E +S315E632B59020504F5720536F66745374617274203459 +S315E632B5A029000000000000002020282033306820E1 +S315E632B5B0202D202020202020202020202020202060 +S315E632B5C0202020202020202F20504F5720536F66F0 +S315E632B5D0745374617274203529000000000000004D +S315E632B5E02020282033316820202D202020202020BC +S315E632B5F02020202020202020202020202020202F1E +S315E632B60020504F5720536F667453746172742036E6 +S315E632B610290000000000000020202820333268206E +S315E632B620202D2020202020202020202020202020EF +S315E632B630202020202020202F2044434443204672D7 +S315E632B6406571290000000000202028203333682067 +S315E632B650202D2020202020202020202020202020BF +S315E632B660202020202020202F205353434720436E8C +S315E632B6707429000000000000202028203334682098 +S315E632B680202D20202020202020202020202020208F +S315E632B690202020202020202F20504F464642202FA1 +S315E632B6A0204D5242290000002020282033356820DA +S315E632B6B0202D20202020202020202020202020205F +S315E632B6C0202020202020202F204352432043686525 +S315E632B6D0636B20436F6465290000000000000000BA +S315E632B6E04932432072656164203A2053746172743A +S315E632B6F020436F6E646974696F6E204454452054F4 +S315E632B7004F555400000000004932432072656164A9 +S315E632B710203A20534C4156452057522057414954F8 +S315E632B72020544F5554000000493243207265616415 +S315E632B730203A20535542204144522057522057410F +S315E632B740495420544F555400493243207265616458 +S315E632B750203A2052455354415254204454452054BB +S315E632B7604F55540000000000493243207265616449 +S315E632B770203A20534C415645204144445245535390 +S315E632B780205244205741495420544F555400000024 +S315E632B7904932432072656164203A2052454349452F +S315E632B7A056452044415441205741495420544F5539 +S315E632B7B0540000000000000049324320726561649D +S315E632B7C0203A2073746F7020436F6E646974696FC2 +S315E632B7D06E2044455420544F555400000000000074 +S315E632B7E04932432072656164203A204255535920E4 +S315E632B7F0544F55540000000049324320777269743B +S315E632B80065203A20537461727420436F6E646974AC +S315E632B810696F6E2044544520544F5554000000005B +S315E632B820493243207772697465203A20534C415641 +S315E632B83045205752205741495420544F555400001B +S315E632B840493243207772697465203A20535542204D +S315E632B850414452205752205741495420544F555469 +S315E632B8600000000000000000493243207772697416 +S315E632B87065203A20656E6420444154412057414959 +S315E632B8805420544F55540000493243207772697436 +S315E632B89065203A204255535920544F5554000000FC +S315E632B8A0706C656173652073656E64202120282786 +S315E632B8B02E2720262043522073746F70206C6F61D8 +S315E632B8C0642900000000000052414D2848273530F1 +S315E632B8D03030303030302D482735334646464646C8 +S315E632B8E0462920436C6561722E2E2E2E000000000C +S315E632B8F04552524F52204C6F61642066696C652E12 +S315E632B9002020203C446F776E6C6F61642020666936 +S315E632B9106C6520204452414D284827343030303049 +S315E632B9203030302D48274246464646464646292058 +S315E632B9302C2052414D284827453633303030303088 +S315E632B9402D4827453633354646464629204F4E4C10 +S315E632B95059203E2000000000204572726F72206246 +S315E632B9606F6172645F6A75646765203A20426F6119 +S315E632B970726420666C616773206E6F74206D6174D3 +S315E632B9806368000000000000204444525F496E6955 +S315E632B9907420202020202020203A200000000000BB +S315E632B9A0626F617264636E665B305D2053616C769C +S315E632B9B061746F7220284D335349502900000000D6 +S315E632B9C0626F617264636E665B315D204B72696586 +S315E632B9D06B00000000000000626F617264636E669F +S315E632B9E05B325D2053616C7661746F72202F205321 +S315E632B9F0746172746572204B6974202848335349F0 +S315E632BA00505F564552312E5829000000000000009C +S315E632BA10626F617264636E665B335D205374617224 +S315E632BA20746572204B697420284D33534950290088 +S315E632BA30626F617264636E665B375D2053616C7604 +S315E632BA4061746F72202F2053746172746572204B63 +S315E632BA506974202848335349505F564552322E3060 +S315E632BA602900000000000000626F617264636E6650 +S315E632BA705B365D2053414C5641544F522048335340 +S315E632BA8049502D3272616E6B0000000000000000F4 +S315E632BA90626F617264636E665B385D2053414C5603 +S315E632BAA041544F522048335349505F766572322EAF +S315E632BAB0302D3272616E6B00626F617264636E66EE +S315E632BAC05B2D5D204572726F72203A206E6F74205E +S315E632BAD0737570706F727465640000000000000062 +S70500000000FA diff --git a/wiki/H3_Salvator-X/Gen3_MiniMonitor_V3.03-20180208.zip b/wiki/H3_Salvator-X/Gen3_MiniMonitor_V3.03-20180208.zip Binary files differnew file mode 100644 index 0000000..13838a5 --- /dev/null +++ b/wiki/H3_Salvator-X/Gen3_MiniMonitor_V3.03-20180208.zip diff --git a/wiki/H3_Salvator-X/RENESAS_RCH3M3_IPL_ReleaseNote_E_v1.0.16.pdf b/wiki/H3_Salvator-X/RENESAS_RCH3M3_IPL_ReleaseNote_E_v1.0.16.pdf Binary files differnew file mode 100644 index 0000000..07ff335 --- /dev/null +++ b/wiki/H3_Salvator-X/RENESAS_RCH3M3_IPL_ReleaseNote_E_v1.0.16.pdf diff --git a/wiki/H3_Salvator-X/RENESAS_RCH3M3_YoctoReleaseNote_E_v2.23.0.pdf b/wiki/H3_Salvator-X/RENESAS_RCH3M3_YoctoReleaseNote_E_v2.23.0.pdf Binary files differnew file mode 100644 index 0000000..4239886 --- /dev/null +++ b/wiki/H3_Salvator-X/RENESAS_RCH3M3_YoctoReleaseNote_E_v2.23.0.pdf diff --git a/wiki/H3_Salvator-X/update_salvator_bootloader_v2110-nolossy.tar.bz2 b/wiki/H3_Salvator-X/update_salvator_bootloader_v2110-nolossy.tar.bz2 Binary files differnew file mode 100644 index 0000000..3ba3474 --- /dev/null +++ b/wiki/H3_Salvator-X/update_salvator_bootloader_v2110-nolossy.tar.bz2 diff --git a/wiki/H3_Salvator-X/update_salvator_bootloader_v2120.tar.bz2 b/wiki/H3_Salvator-X/update_salvator_bootloader_v2120.tar.bz2 Binary files differnew file mode 100644 index 0000000..405dc9d --- /dev/null +++ b/wiki/H3_Salvator-X/update_salvator_bootloader_v2120.tar.bz2 diff --git a/wiki/H3_Salvator-X/update_salvator_bootloader_v2160.tar.bz2 b/wiki/H3_Salvator-X/update_salvator_bootloader_v2160.tar.bz2 Binary files differnew file mode 100644 index 0000000..9de4607 --- /dev/null +++ b/wiki/H3_Salvator-X/update_salvator_bootloader_v2160.tar.bz2 diff --git a/wiki/H3_Salvator-X/update_salvator_bootloader_v2190+es20.tar.bz2 b/wiki/H3_Salvator-X/update_salvator_bootloader_v2190+es20.tar.bz2 Binary files differnew file mode 100644 index 0000000..acec407 --- /dev/null +++ b/wiki/H3_Salvator-X/update_salvator_bootloader_v2190+es20.tar.bz2 diff --git a/wiki/H3_Salvator-X/update_salvator_bootloader_v220.tar.bz2 b/wiki/H3_Salvator-X/update_salvator_bootloader_v220.tar.bz2 Binary files differnew file mode 100644 index 0000000..3f0f83d --- /dev/null +++ b/wiki/H3_Salvator-X/update_salvator_bootloader_v220.tar.bz2 diff --git a/wiki/H3_Salvator-X/update_salvator_bootloader_v2230.tar.bz2 b/wiki/H3_Salvator-X/update_salvator_bootloader_v2230.tar.bz2 Binary files differnew file mode 100644 index 0000000..3526686 --- /dev/null +++ b/wiki/H3_Salvator-X/update_salvator_bootloader_v2230.tar.bz2 diff --git a/wiki/H3_Salvator-X/update_salvator_bootloader_v230.tar.bz2 b/wiki/H3_Salvator-X/update_salvator_bootloader_v230.tar.bz2 Binary files differnew file mode 100644 index 0000000..e26bc09 --- /dev/null +++ b/wiki/H3_Salvator-X/update_salvator_bootloader_v230.tar.bz2 diff --git a/wiki/H3_Salvator-X/update_salvator_bootloader_v270-4core.tar.bz2 b/wiki/H3_Salvator-X/update_salvator_bootloader_v270-4core.tar.bz2 Binary files differnew file mode 100644 index 0000000..33c7bea --- /dev/null +++ b/wiki/H3_Salvator-X/update_salvator_bootloader_v270-4core.tar.bz2 diff --git a/wiki/H3_Salvator-X/update_salvator_bootloader_v270-8core.tar.bz2 b/wiki/H3_Salvator-X/update_salvator_bootloader_v270-8core.tar.bz2 Binary files differnew file mode 100644 index 0000000..f10c8c1 --- /dev/null +++ b/wiki/H3_Salvator-X/update_salvator_bootloader_v270-8core.tar.bz2 diff --git a/wiki/H3_Salvator-X/update_salvator_bootloader_v290-v2.tar.bz2 b/wiki/H3_Salvator-X/update_salvator_bootloader_v290-v2.tar.bz2 Binary files differnew file mode 100644 index 0000000..ea5d712 --- /dev/null +++ b/wiki/H3_Salvator-X/update_salvator_bootloader_v290-v2.tar.bz2 diff --git a/wiki/H3_ULCB.wiki b/wiki/H3_ULCB.wiki new file mode 100644 index 0000000..1bcee05 --- /dev/null +++ b/wiki/H3_ULCB.wiki @@ -0,0 +1,5 @@ +h1. H3 ULCB + +h1. Files + +"tar.bz2: H3 ULCB 2016-08-25":../../wiki/H3_ULCB/H3_ULCB-2016-08-25.tar.bz2 diff --git a/wiki/H3_ULCB/H3_ULCB-2016-08-25.tar.bz2 b/wiki/H3_ULCB/H3_ULCB-2016-08-25.tar.bz2 Binary files differnew file mode 100644 index 0000000..08c1b43 --- /dev/null +++ b/wiki/H3_ULCB/H3_ULCB-2016-08-25.tar.bz2 diff --git a/wiki/Hardware.wiki b/wiki/Hardware.wiki new file mode 100644 index 0000000..d3dff58 --- /dev/null +++ b/wiki/Hardware.wiki @@ -0,0 +1,97 @@ +h1. [[Yocto]] + +h1. Hardware + +h2. +Who has which board?+ + +h3. Renesas board + +|_. SuperH boards |_. Geert |_. Laurent |_. Niklas |_. Simon |_. Wolfram |_. Ulrich |_. Kieran |_. Jacopo |_. Marek | +|_. ecovec | | | | | | | | O | | +|_. EMMA Mobile boards |_. Geert |_. Laurent |_. Niklas |_. Simon |_. Wolfram |_. Ulrich |_. Kieran |_. Jacopo |_. Marek | +|_. kzm9d | | | O | | O | | | | | +|_. SH/R-Mobile boards |_. Geert |_. Laurent |_. Niklas |_. Simon |_. Wolfram |_. Ulrich |_. Kieran |_. Jacopo |_. Marek | +|_. ape6evm | O | | O | | O | O | | | | +|_. armadillo | O | O | | | | O | | | | +|_. kzm9g | O | O | | | | | | | | +|_. RZ/A boards |_. Geert |_. Laurent |_. Niklas |_. Simon |_. Wolfram |_. Ulrich |_. Kieran |_. Jacopo |_. Marek | +|_. genmai | | | | | | | | O | | +|_. gr-peach | | | | | | | | O | | +|_. rskrza1 | O | | | | | | | | | +|_. rza2mevb | O | | | | | | | | | +|_. R-Car Gen1 boards |_. Geert |_. Laurent |_. Niklas |_. Simon |_. Wolfram |_. Ulrich |_. Kieran |_. Jacopo |_. Marek | +|_. bockw | | | | | | | | | | +|_. marzen | | O | | | | | | | | +|_. R-Car Gen2 boards |_. Geert |_. Laurent |_. Niklas |_. Simon |_. Wolfram |_. Ulrich |_. Kieran |_. Jacopo |_. Marek | +|_. E2 Alt | | | | | O | | | | | +|_. E2 Silk | | | | | | | | | | +|_. H2 Lager | | O | | | O | O | | | | +|_. [[M2N Gose]] | | | | | | | | | | +|_. M2W Koelsch | O | | O | | | | | | | +|_. M2W Porter | | | | | | | | | O | +|_. [[V2H Wheat]] | | | | | | | | | | +|_. R-Car Gen3 boards |_. Geert |_. Laurent |_. Niklas |_. Simon |_. Wolfram |_. Ulrich |_. Kieran |_. Jacopo |_. Marek | +|_. [[D3 Draak]] | | O | | | | O | | | | +|_. [[E3 Ebisu]] | O | | | | O | | | O | O | +|_. [[H3 Salvator-X]] | O | O | O | | O | O | O | | | +|_. H3 Salvator-XS | O | O | O | O | O | | O | | O | +|_. [[H3 ULCB]] | | O | | | | | | | O | +|_. [[M3W Salvator-X]] | O | O | O | O | O | O | O | O | O | +|_. M3N Salvator-XS | O | O | O | O | O | O | O | O | O | +|_. M3 ULCB | | | | | | | | O | O | +|_. [[V3H]] | | | | | | | | | | +|_. [[V3M Eagle]] | | | O | | | | O | | | + +h3. Expansion board + +|_. |_. Geert |_. Laurent |_. Niklas |_. Simon |_. Wolfram |_. Ulrich |_. Kieran |_. Jacopo |_. Marek | +|_. [[Salvator-X MAXIM camera board]] | | | | | | | O | O | | + +h3. other ARM board + +|_. |_. BeagleBone Black |_. DragonBoard 410c |_. NanoPi NEO |_. RaspBerry Pi 2 Model B | +|_. Geert | O | O | O | O | +|_. Kieran| O | O | | O | + +h3. Cameras + +|_. |_. RDACM20 |_. RDACM21 | +|_. Jacopo | | 00456, 00457 | +|_. Kieran | 5, 9, 10, 11, 12, 13 | 00464, 00465, 00466, 00468 | +|_. | | 00469, 00470, 00471, 00472 | +|_. Laurent | 7, 8, 14, 15, 16 | 00459, 00460, 00461, 00463 | +|_. Niklas | 1, 2, 3, 4, 6 | 00453, 00454 | + +The following RDACM20 cameras are suspected to be faulty: 3, 5, 8 + + +h2. +Embedded Linux Wiki+ + +* http://elinux.org/R-Car +* http://elinux.org/R-Mobile +* http://elinux.org/RZ-A +* http://elinux.org/RZ-G + + +h2. +Magnus' Board Farm+ + +h3. Install local TFTP server + +As root: +<pre> +tar zxf /tmp/busybox-x86.tar.gz +NET=192.168.97 +NODE=$(ifconfig br-control | head -1 | sed -e 's/^.*:0*//g') +ADDRESS=$NET.$((80 + $NODE)) +echo TFTP server at $ADDRESS +ifconfig br-net $ADDRESS +nohup udpsvd -v $ADDRESS 69 tftpd /tmp/tftpboot & +exit +</pre> + +The TFTP server's IP address is derived from the last two digits of the VM instance's port number. + +h1. Files + +* "tar.gz: Magnus' busybox binary containing a.o. a TFTP server":../../wiki/Hardware/busybox-x86.tar.gz +* "pdf: Renesas R-Car H3M3 Yocto Release Note v2.16.0":../../wiki/Hardware/RENESAS_RCH3M3_YoctoReleaseNote_E_v2.16.0.pdf
\ No newline at end of file diff --git a/wiki/Hardware/RENESAS_RCH3M3_YoctoReleaseNote_E_v2.16.0.pdf b/wiki/Hardware/RENESAS_RCH3M3_YoctoReleaseNote_E_v2.16.0.pdf Binary files differnew file mode 100644 index 0000000..63d020f --- /dev/null +++ b/wiki/Hardware/RENESAS_RCH3M3_YoctoReleaseNote_E_v2.16.0.pdf diff --git a/wiki/Hardware/busybox-x86.tar.gz b/wiki/Hardware/busybox-x86.tar.gz Binary files differnew file mode 100644 index 0000000..d58435c --- /dev/null +++ b/wiki/Hardware/busybox-x86.tar.gz diff --git a/wiki/M2N_Gose.wiki b/wiki/M2N_Gose.wiki new file mode 100644 index 0000000..ec84512 --- /dev/null +++ b/wiki/M2N_Gose.wiki @@ -0,0 +1,5 @@ +h1. M2N Gose + +h1. Files + +"RTP0RC7793SEB00010S_CD_v1.5.tar.bz2":../../wiki/M2N_Gose/RTP0RC7793SEB00010S_CD_v1.5.tar.bz2
\ No newline at end of file diff --git a/wiki/M2N_Gose/RTP0RC7793SEB00010S_CD_v1.5.tar.bz2 b/wiki/M2N_Gose/RTP0RC7793SEB00010S_CD_v1.5.tar.bz2 Binary files differnew file mode 100644 index 0000000..545a03d --- /dev/null +++ b/wiki/M2N_Gose/RTP0RC7793SEB00010S_CD_v1.5.tar.bz2 diff --git a/wiki/M3W_Salvator-X.wiki b/wiki/M3W_Salvator-X.wiki new file mode 100644 index 0000000..ee7672e --- /dev/null +++ b/wiki/M3W_Salvator-X.wiki @@ -0,0 +1,89 @@ +h1. M3 Salvator-X + +h2. Update FirmWare + +# download update script from below +# run script + +h3. SW10 + +0 corresponds to the switch in the OFF position and 1 to the ON position. Bits are given in the 1-8 order. + +<pre> +for update: xxxx 0000 +for use : xxxx 1100 (HyperFlash = 80MHz, stable) or + xxxx 1101 (HyperFlash = 160MHz, aggressive) +</pre> + +Maybe it is *1100 1100* or *1100 1101* on your board + +h3. Run script + +see readme +<pre> +./do_xls2.expect /dev/ttyUSB1 ./M3_Scif_Minimon_V0.10.mot ./table.txt +</pre> + +h3. Log + +<pre> +./do_xls2.expect /dev/ttyUSB1 ./M3_Scif_Minimon_V0.10.mot ./table.txt +uploading loader file +performing xls2 e6320000 000000 bootparam_sa0.srec +performing xls2 e6302000 040000 bl2-salvator-x.srec +performing xls2 e6320000 180000 cert_header_sa6.srec +performing xls2 44000000 1c0000 bl31-salvator-x.srec +performing xls2 44100000 200000 tee-salvator-x.srec +performing xls2 49000000 640000 u-boot-elf.srec +</pre> + +h3. version + +| "v2.9.0 lossy OFF":../../wiki/M3W_Salvator-X/M3_Yocto_290_lossy_off.tar.bz2 |BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.7 +BL2: Built : 14:27:08, Aug 8 2016 +U-Boot 2015.04 (Aug 08 2016 - 13:38:06) |*require SWICH settings* +- -SW6: 3 pin side- +- SW7: 2 pin side | +| "v2.12.0":../../wiki/M3W_Salvator-X/M3_Yocto_2120.tar.bz2|BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.9 +BL2: Built : 10:48:08, Sep 16 2016 +U-Boot 2015.04 (Sep 16 2016 - 10:48:08) | PMIC will be shutdown on this version when S2RAM +*require SWICH settings* +- -SW6: 1 pin side (default is 3)- +- SW7: 1 pin side (default is 2) +- SW8: all OFF +*How to S2RAM* +- Set to PMIC to backup mode via i2c-tools command +<pre># i2cset -f -y 7 0x30 0x20 0x0F</pre> +- (Suspend) Change SW23 to OFF +- Request System Suspend to RAM +<pre># echo mem > /sys/power/state</pre> +- (Resume) Change SW23 to ON | +| "v2.16.0":../../wiki/M3W_Salvator-X/M3_Yocto_2160.tar.bz2|BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.12 +BL2: Built : 08:28:19, Jan 30 2017 +U-Boot 2015.04 (Jan 30 2017 - 17:13:08)|*require SWICH settings* +- -SW6: 1 pin side (default is 3)- +- SW7: 1 pin side (default is 2) +- SW8: all OFF +*How to S2RAM* +see above +*uboot position* was moved from *H'49000000* to *H'50000000* | +| "v2.19.0":../../wiki/M3W_Salvator-X/update_m3_salvator_bootloader_v2190.tar.bz2|BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.14 +BL2: Built : 13:32:44, Apr 27 2017 +U-Boot 2015.04 (Apr 27 2017 - 13:38:24)|*require SWICH settings* +- -SW6: 1 pin side (default is 3)- +- SW7: 1 pin side (default is 2) +- SW8: all OFF +*How to S2RAM* +see above| +| "v2.23.0":../../wiki/M3W_Salvator-X/update_m3_salvator_bootloader_v2230.tar.bz2 <br> "v2.23.0 for ES1.1":../../wiki/M3W_Salvator-X/update_m3_salvator_bootloader_v2230_with_es1.1.tar.bz2|BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.16 +BL2: Built : 16:55:50, Oct 2 2017 +U-Boot 2015.04 (Oct 02 2017 - 17:01:56) |*require SWICH settings* +- -SW6: 1 pin side (default is 3)- +- SW7: 1 pin side (default is 2) +- SW8: all OFF +*How to S2RAM* +see above| + +h2. Release Note + +see "here":./H3_Salvator-X.html diff --git a/wiki/M3W_Salvator-X/M3_Yocto_2120.tar.bz2 b/wiki/M3W_Salvator-X/M3_Yocto_2120.tar.bz2 Binary files differnew file mode 100644 index 0000000..993520a --- /dev/null +++ b/wiki/M3W_Salvator-X/M3_Yocto_2120.tar.bz2 diff --git a/wiki/M3W_Salvator-X/M3_Yocto_2160.tar.bz2 b/wiki/M3W_Salvator-X/M3_Yocto_2160.tar.bz2 Binary files differnew file mode 100644 index 0000000..9d61e37 --- /dev/null +++ b/wiki/M3W_Salvator-X/M3_Yocto_2160.tar.bz2 diff --git a/wiki/M3W_Salvator-X/M3_Yocto_290_lossy_off.tar.bz2 b/wiki/M3W_Salvator-X/M3_Yocto_290_lossy_off.tar.bz2 Binary files differnew file mode 100644 index 0000000..6118a02 --- /dev/null +++ b/wiki/M3W_Salvator-X/M3_Yocto_290_lossy_off.tar.bz2 diff --git a/wiki/M3W_Salvator-X/update_m3_salvator_bootloader_v2190.tar.bz2 b/wiki/M3W_Salvator-X/update_m3_salvator_bootloader_v2190.tar.bz2 Binary files differnew file mode 100644 index 0000000..db3a6d2 --- /dev/null +++ b/wiki/M3W_Salvator-X/update_m3_salvator_bootloader_v2190.tar.bz2 diff --git a/wiki/M3W_Salvator-X/update_m3_salvator_bootloader_v2230.tar.bz2 b/wiki/M3W_Salvator-X/update_m3_salvator_bootloader_v2230.tar.bz2 Binary files differnew file mode 100644 index 0000000..2889caa --- /dev/null +++ b/wiki/M3W_Salvator-X/update_m3_salvator_bootloader_v2230.tar.bz2 diff --git a/wiki/M3W_Salvator-X/update_m3_salvator_bootloader_v2230_with_es1.1.tar.bz2 b/wiki/M3W_Salvator-X/update_m3_salvator_bootloader_v2230_with_es1.1.tar.bz2 Binary files differnew file mode 100644 index 0000000..5943323 --- /dev/null +++ b/wiki/M3W_Salvator-X/update_m3_salvator_bootloader_v2230_with_es1.1.tar.bz2 diff --git a/wiki/Ongoing_Multimedia_Development.wiki b/wiki/Ongoing_Multimedia_Development.wiki new file mode 100644 index 0000000..052f1a4 --- /dev/null +++ b/wiki/Ongoing_Multimedia_Development.wiki @@ -0,0 +1,115 @@ +h1. Ongoing Multimedia Development + +h2. Multi Camera status + +(2019/12/12 update) + +h3. Current MAX9286 development + +* git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git +* Tag: gmsl/v6 +* Development Branch: gmsl/dev + +h3. Current V4L2 Multiplex series + +* https://jmondi.org/cgit/linux +* Branch: v4l2-mux/media-master/v6 + +h3. MAX9286 driver + +I have been improving this driver state over the last couple of weeks to iron out some remaining issues that were left from earlier developments, and related to earlier review comments. I expect to post a v6 version of this imminently + +* https://lore.kernel.org/linux-renesas-soc/20191211124459.20508-1-kieran.bingham+renesas@ideasonboard.com/T/#t + +There are a couple of 'sub-parts' to this driver: + +h3. Eagle-V3M support. + +This does not block the posting of the max9286 driver, but has blocked me while I've been working on a fix. The Eagle-V3M powers the cameras from a GPIO connected to the MAX9286 itself. +Describing this as a regulator connected to the GPIO line creates a circular dependency on itself. +I have two lines of investigation to follow on this: Splitting max9286 gpio to an MFD, and creating a new 'bus' type to better define how (/when) the cameras are probed. + +To work around this, I have added a gpio-hog to enable the cameras and added a hardcoded 7 second delay into the probe sequence of the driver. +(Not a pretty fix, or upstreamable, but it brings the cameras up...) + +h3. Salvator-XS support + +This has the well known issue that there are two MAX9286's connected to the same I2C bus. We have a workaround for this, but it is not currently upstreamable. +This is separated out to a distinct patch to facilitate upstreaming the max9286. + +h2. Multi Camera plan + +(2019/12/12 update) + +h3. MAX9286 driver: + +I believe I now have a driver for the max9286 which has been greatly cleaned up, and functions on platforms (with a couple of workarounds for external requirements). +Excluding the dependency on the V4L2 Multiplexed stream series, this driver can capture from multiple streams on the RCAR-Vin (without per-stream-format-validation) and could be restricted further to support only a single stream if someone complains about the validation. + +I plan to post v6 imminently, and I hope that it is in a state that it could be upstreamed independently of the other topics. +I am already aware of an engineer using/developing on top of this driver at Linaro on a Qualcomm platform. + +* Upstream aims: +** Core driver +*** Short term (Hopefully!) +** Eagle-V3M extended requirements +*** Medium term. +** Salvator-X "two-max9286s" +*** Out of tree workaround + +h3. RDACM20 + +The Camera driver needs to be broken down to better support reuse of the individual components, (as expressed by the RDACM21 also using the max9271). + +Jacopo plans to work on this, and then later we will look at supporting the RDACM21, making use of the reusable components at that point. + +* Upstream Aims +** Medium term. + +h3. V4L2 Multiplexed streams + +Jacopo has refreshed this series recently, and has had meetings with other core V4L2 developers (I think he met with Sakari in particular) to discuss the direction of this patch series. +It is long and complex, and finding agreement on key topics such as how to correctly filter on DT (data-type, *not device-tree*) tags is difficult. + +The complexities of this series has led us to aim to getting the MAX9286 upstream without it so that we can progress, and aim to support the MAX9286 multiple streams correctly along with the ADV748x when the V4L2 Multiplex series progresses. + +* Upstream aims +** Long term. + +h2. Small Tasks Candidates + +When completing a task from this list please mark it as complete and mention your name and the patch series that addresses it. + +* Fix MEDIA_ENT_F_VID_IF_BRIDGE documentation + MEDIA_ENT_F_VID_IF_BRIDGE is documented in Documentation/media/uapi/mediactl/media-types.rst as follows. +** Video interface bridge. A video interface bridge entity must have at least one sink pad and at least one source pad. It receives video frames on its sink pad from an input video bus of one type (HDMI, eDP, MIPI CSI-2, ...), and outputs them on its source pad to an output video bus of another type (eDP, MIPI CSI-2, parallel, ...). +** The second and third sentences are incoherent regarding the number of pads. Fix them. + +* Fix media_entity_get_fwnode_pad() typo +** In include/media/media-entity.h, s/dose/does/. + +* Make i2c_new_secondary_device() return an error pointer +** To be meaningful that requires i2c_new_dummy() to return an error pointer too. + +* Fix "warning: Function parameter or member 'foo' not described in 'bar'" warnings when compiling kernel documentation + +* Fix the DU ESCR handling (DU channels that have a DPLL don't have ESCR dividers) + +* Fix vsp-test failures on H3 ES1.1 +** The following tests fail: +*** UDS scaling (vsp-unit-test-0003.sh) +*** CLU/LUT (vsp-unit-test-0010.sh) +*** Runtime H/V flip (vsp-unit-test-0012.sh) +*** SRU scaling (vsp-unit-test-0015.sh) +*** HGT (vsp-unit-test-0023.sh) + +* Support MEDIA_BUS_FMT_UYVY8_1X16 in VIN and MEDIA_BUS_FMT_YUYV8_1X16 in CSI-2 + +h2. Completed tasks + +* Fix the VSPD memory regions in r8a7795.dtsi and r8a7796.dtsi + +* The memory regions should include the RPF OSD-CLUT tables. +** [PATCH v3 3/5] arm64: dts: renesas: r8a7795-es1: Fix register mappings on VSPs +** [PATCH v3 4/5] arm64: dts: renesas: r8a7795: Fix register mappings on VSPs +** [PATCH v3 5/5] arm64: dts: renesas: r8a7796: Fix register mappings on VSPs diff --git a/wiki/Salvator-X_MAXIM_camera_board.wiki b/wiki/Salvator-X_MAXIM_camera_board.wiki new file mode 100644 index 0000000..d2ed221 --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board.wiki @@ -0,0 +1,88 @@ +h1. Salvator-X MAXIM camera board + +| J18, J19 | J17, J9 | +| !Salvator-X_MAXIM_camera_board/MAXIM_img1.jpg! | !Salvator-X_MAXIM_camera_board/MAXIM_img2.jpg! | +| !Salvator-X_MAXIM_camera_board/MAXIM_img3.jpg! | !Salvator-X_MAXIM_camera_board/MAXIM_img4.jpg! | + +h1. 8ch Camera WorkAround + +{J1, J2, J3, J4} and {J5, J10, J12, J13} are connected to each MAX9271, but these will get *%{color:#0000ff}same base address%* (= 0x80) if *%{color:#0000ff}J19%* jumper was connected when boot time. see "vin camera board2":../../wiki/Salvator-X_MAXIM_camera_board/vin_camera_board_20160606.xlsx +If this happen, MAX9286 can't control it correctly. Thus, we need to shift Power ON timing for MAX9271. see "Poer ON order (with 8ch WorkAround)" +This WorkAround is needed if you use each MAX9271 chip in the same time. + +h1. Power ON order (with 8ch WorkAround if needed) + +# Start Salvator-X and Camera Board with Powered OFF +# (Remove Power Jumper (J19)) +# Power on Salvator-X +# Power on Camera Board +# (Reapply Power Jumper (J19)) + +h1. Note + +* Reset +** both Salvator-X and Camera Board in the same time. Here, Camera board doesn't have reset button, thus Remove/Reapply power cable for it +* Power Cable +** We can use Salvator-X / Lager power for camera board +* Salvator board SW settings +** SW29 {ON, ON} => {OFF, OFF} +** see "quick setting guide":../../wiki/Salvator-X_MAXIM_camera_board/RCARH3_camera_quick_setting_20151201.xlsx + +h1. 8ch camera demo + +Morimoto is keeping 8ch camera demo, but can't attach it to this Wiki, because of its file size. +So, you need to contact to Renesas guy if you want to receive it. +For Renesas guy's information. You can get it from "here":https://renesasgroup-my.sharepoint.com/personal/kuninori_morimoto_gx_renesas_com/Documents/OSD2/Linux-NDA/2017-04-14-8ch_camera_Environment (From Renesas only), and use HDE for them. + +h1. VIN issue + +* On *R-Car H3 (ES2.0)*, HDMI input with 640x480@60H will be blackout +* On *R-Car M3 (ES1.x)*, when CSI40 module is used as 1-Lane or 2-Lane, VIN captures incorrect data. +** This bug was caused by the ECO modification of 4Lane highest bit rate input for M3W ES1.0. CSI40 Link module violated the interface protocol with VIN. So VIN was changed to delay 1 cycle capturing timing to solve above issue because CSI40 Link holds its output 4 bytes data for 1 cycle. However, it was not true when CSI40-Phy used 1- or 2-Lane connection. This phenomenon occurs only in M3W(ES1.0 and ES1.1). +** "detail 1":../../wiki/Salvator-X_MAXIM_camera_board/R-CarM3W_CSI2_VIN_Interface_Bug_20170410.pptx +** "detail 2":../../wiki/Salvator-X_MAXIM_camera_board/Gen3_limit_RCM3W_CSI2_VIN_IF_BUG.PPT (English page p10 - p14) + +h1. Maxim board power reset automation + +We can adapt the MAXIM board to be reset at the same time as the Salvator-X using an Arduino, and powering the Arduino from the Salvator-X + +* Use a molex connector to take power from the Salvator-X CN7:ATA_PWR (red is 5v, black is GND) +* Use a data pin from the arduino connected to the center pin of J17 (The example code uses D6 on the arduino) +* Connect the Data pin connection with a *pull down* resistor. around 2kΩ should be fine. +* Use the GSML-Control.ino software delay loop to control the EN signal on the MAX16951AUE/V+ (U23) via J17 + +Hardware used: +* https://store.arduino.cc/usa/arduino-nano +** A clone is suitable (Arduino original ~ $25, Clone ~ $3, I used a clone) +* Breadboard +* 1.9k Ω resistor +* Molex connector ("I used one like this":https://www.uk.insight.com/en-gb/productinfo/system-and-power-cables/0002646789-00000001?gclid=CjwKCAjwzMbLBRBzEiwAfFz4geenUnvYI4d3sz0A_cvqo-CoReOwop3T_CzAVBbOsLuFZPcTEQyGnhoClbgQAvD_BwE) + +Software Used: +* Arduino code available at "GSML-Control.ino":../../wiki/Salvator-X_MAXIM_camera_board/GSML-Control.ino + +Overview: +* "Images of the Arduino configuration":https://photos.app.goo.gl/dpFk0CzAZS5G0Fec2 + + +h1. *%{color:#ff0000}NDA information%* + +*%{color:#ff0000}CAUTION!!%* + +"MAX9286":../../wiki/Salvator-X_MAXIM_camera_board/MAX9286-DS-1.Renesas.pdf +"MAX9286 programing guide":../../wiki/Salvator-X_MAXIM_camera_board/MAX9286_Programming_Guide_2_10.pdf +"board schematic":../../wiki/Salvator-X_MAXIM_camera_board/R-CAR_H3_Rev_P2.pdf +"R-CARH3_Rev P2_BOM":../../wiki/Salvator-X_MAXIM_camera_board/R-CARH3_Rev_P2_BOM.XLSX +"RDACM20 camera schematic":../../wiki/Salvator-X_MAXIM_camera_board/RDACM20_SCHEMATIC_DIAGRAM-20151110.pdf +"RDAMC20 camera datasheet":../../wiki/Salvator-X_MAXIM_camera_board/MC_RDACM20-01_DataSheet_02.pdf +"OV10635 datasheet":../../wiki/Salvator-X_MAXIM_camera_board/OV10635-OV10135-Product-Specification-a-CSP_Version-2-4_Renesas-Electronics.pdf + +h1. datasheet / off-tree-driver + +"OV10635 camera driver":http://git.ti.com/android-sdk/kernel-omap/blobs/eb15176df1e988393d12a2b8c2becd30078edbd8/drivers/media/i2c/ov10635.c +"Ov10635 camera driver":https://patchwork.linuxtv.org/patch/18768/ +"MAX9286 driver":https://github.com/CogentEmbedded/meta-rcar/blob/v2.12.0/meta-rcar-gen3/recipes-kernel/linux/linux-renesas/0040-H3-MAX9286-TI964-support-add-10635-10640-cameras.patch +"MAX9271 datasheet":http://datasheets.maximintegrated.com/en/ds/MAX9271.pdf +"quick setting guide":../../wiki/Salvator-X_MAXIM_camera_board/RCARH3_camera_quick_setting_20151201.xlsx +"vin camera board1":../../wiki/Salvator-X_MAXIM_camera_board/vin_camera_board_1.xlsx +"vin camera board2":../../wiki/Salvator-X_MAXIM_camera_board/vin_camera_board_20160606.xlsx diff --git a/wiki/Salvator-X_MAXIM_camera_board/GSML-Control.ino b/wiki/Salvator-X_MAXIM_camera_board/GSML-Control.ino new file mode 100644 index 0000000..1837025 --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/GSML-Control.ino @@ -0,0 +1,48 @@ + + +// GMSL Configuration +const int MAX16951_EN = 6; + +void set_EN(int onoff) +{ + digitalWrite(MAX16951_EN, onoff); + + if (onoff) + Serial.print("Pin High\n"); + else + Serial.print("Pin Low\n"); +} + +void setup() { + pinMode(MAX16951_EN, OUTPUT); + set_EN(LOW); + + Serial.begin(115200); + Serial.print("\n"); + //Serial.setDebugOutput(true); +} + +void loop() { + int i; + // configure power-on state before delay + + set_EN(LOW); + + // blink a bit + for (i=0; i<10; i++) { + digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level) + delay(50); // wait for 50 ms + digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW + delay(50); // wait for 50 ms + } + + // configure final state after delay + set_EN(HIGH); + + digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level) + + while(1) { + delay(1000); + // Serial.print("Spinning\n"); + } +} diff --git a/wiki/Salvator-X_MAXIM_camera_board/Gen3_limit_RCM3W_CSI2_VIN_IF_BUG.PPT b/wiki/Salvator-X_MAXIM_camera_board/Gen3_limit_RCM3W_CSI2_VIN_IF_BUG.PPT Binary files differnew file mode 100644 index 0000000..02b86cf --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/Gen3_limit_RCM3W_CSI2_VIN_IF_BUG.PPT diff --git a/wiki/Salvator-X_MAXIM_camera_board/MAX9286-DS-1.Renesas.pdf b/wiki/Salvator-X_MAXIM_camera_board/MAX9286-DS-1.Renesas.pdf Binary files differnew file mode 100644 index 0000000..213d43e --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/MAX9286-DS-1.Renesas.pdf diff --git a/wiki/Salvator-X_MAXIM_camera_board/MAX9286_Programming_Guide_2_10.pdf b/wiki/Salvator-X_MAXIM_camera_board/MAX9286_Programming_Guide_2_10.pdf Binary files differnew file mode 100644 index 0000000..cb3f373 --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/MAX9286_Programming_Guide_2_10.pdf diff --git a/wiki/Salvator-X_MAXIM_camera_board/MAXIM_img1.jpg b/wiki/Salvator-X_MAXIM_camera_board/MAXIM_img1.jpg Binary files differnew file mode 100644 index 0000000..913e2c9 --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/MAXIM_img1.jpg diff --git a/wiki/Salvator-X_MAXIM_camera_board/MAXIM_img2.jpg b/wiki/Salvator-X_MAXIM_camera_board/MAXIM_img2.jpg Binary files differnew file mode 100644 index 0000000..689d393 --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/MAXIM_img2.jpg diff --git a/wiki/Salvator-X_MAXIM_camera_board/MAXIM_img3.jpg b/wiki/Salvator-X_MAXIM_camera_board/MAXIM_img3.jpg Binary files differnew file mode 100644 index 0000000..8929877 --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/MAXIM_img3.jpg diff --git a/wiki/Salvator-X_MAXIM_camera_board/MAXIM_img4.jpg b/wiki/Salvator-X_MAXIM_camera_board/MAXIM_img4.jpg Binary files differnew file mode 100644 index 0000000..1c2841c --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/MAXIM_img4.jpg diff --git a/wiki/Salvator-X_MAXIM_camera_board/MC_RDACM20-01_DataSheet_02.pdf b/wiki/Salvator-X_MAXIM_camera_board/MC_RDACM20-01_DataSheet_02.pdf Binary files differnew file mode 100644 index 0000000..20dd7f2 --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/MC_RDACM20-01_DataSheet_02.pdf diff --git a/wiki/Salvator-X_MAXIM_camera_board/OV10635-OV10135-Product-Specification-a-CSP_Version-2-4_Renesas-Electronics.pdf b/wiki/Salvator-X_MAXIM_camera_board/OV10635-OV10135-Product-Specification-a-CSP_Version-2-4_Renesas-Electronics.pdf Binary files differnew file mode 100644 index 0000000..e1563c9 --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/OV10635-OV10135-Product-Specification-a-CSP_Version-2-4_Renesas-Electronics.pdf diff --git a/wiki/Salvator-X_MAXIM_camera_board/R-CARH3_Rev_P2_BOM.XLSX b/wiki/Salvator-X_MAXIM_camera_board/R-CARH3_Rev_P2_BOM.XLSX Binary files differnew file mode 100644 index 0000000..ac71da6 --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/R-CARH3_Rev_P2_BOM.XLSX diff --git a/wiki/Salvator-X_MAXIM_camera_board/R-CAR_H3_Rev_P2.pdf b/wiki/Salvator-X_MAXIM_camera_board/R-CAR_H3_Rev_P2.pdf Binary files differnew file mode 100644 index 0000000..9bc6300 --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/R-CAR_H3_Rev_P2.pdf diff --git a/wiki/Salvator-X_MAXIM_camera_board/R-CarM3W_CSI2_VIN_Interface_Bug_20170410.pptx b/wiki/Salvator-X_MAXIM_camera_board/R-CarM3W_CSI2_VIN_Interface_Bug_20170410.pptx Binary files differnew file mode 100644 index 0000000..216a36a --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/R-CarM3W_CSI2_VIN_Interface_Bug_20170410.pptx diff --git a/wiki/Salvator-X_MAXIM_camera_board/RCARH3_camera_quick_setting_20151201.xlsx b/wiki/Salvator-X_MAXIM_camera_board/RCARH3_camera_quick_setting_20151201.xlsx Binary files differnew file mode 100644 index 0000000..0702d89 --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/RCARH3_camera_quick_setting_20151201.xlsx diff --git a/wiki/Salvator-X_MAXIM_camera_board/RDACM20_SCHEMATIC_DIAGRAM-20151110.pdf b/wiki/Salvator-X_MAXIM_camera_board/RDACM20_SCHEMATIC_DIAGRAM-20151110.pdf Binary files differnew file mode 100644 index 0000000..f8e2724 --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/RDACM20_SCHEMATIC_DIAGRAM-20151110.pdf diff --git a/wiki/Salvator-X_MAXIM_camera_board/vin_camera_board_1.xlsx b/wiki/Salvator-X_MAXIM_camera_board/vin_camera_board_1.xlsx Binary files differnew file mode 100644 index 0000000..ee64843 --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/vin_camera_board_1.xlsx diff --git a/wiki/Salvator-X_MAXIM_camera_board/vin_camera_board_20160606.xlsx b/wiki/Salvator-X_MAXIM_camera_board/vin_camera_board_20160606.xlsx Binary files differnew file mode 100644 index 0000000..0a6d654 --- /dev/null +++ b/wiki/Salvator-X_MAXIM_camera_board/vin_camera_board_20160606.xlsx diff --git a/wiki/V2H_Wheat.wiki b/wiki/V2H_Wheat.wiki new file mode 100644 index 0000000..54e006c --- /dev/null +++ b/wiki/V2H_Wheat.wiki @@ -0,0 +1,5 @@ +h1. V2H Wheat + +h1. Files + +* "pdf: R-Car V2H small rev3r2":../../wiki/V2H_Wheat/small_rev3r2.pdf
\ No newline at end of file diff --git a/wiki/V2H_Wheat/small_rev3r2.pdf b/wiki/V2H_Wheat/small_rev3r2.pdf Binary files differnew file mode 100644 index 0000000..b5ea67c --- /dev/null +++ b/wiki/V2H_Wheat/small_rev3r2.pdf diff --git a/wiki/V3H.wiki b/wiki/V3H.wiki new file mode 100644 index 0000000..5027e1d --- /dev/null +++ b/wiki/V3H.wiki @@ -0,0 +1,5 @@ +h1. V3H + +h1. Files + +"tar.gz: do_xls2 script for V3H Condor board":../../wiki/V3H/v3h-condor.tar.gz diff --git a/wiki/V3H/v3h-condor.tar.gz b/wiki/V3H/v3h-condor.tar.gz Binary files differnew file mode 100644 index 0000000..79c11d7 --- /dev/null +++ b/wiki/V3H/v3h-condor.tar.gz diff --git a/wiki/V3M_Eagle.wiki b/wiki/V3M_Eagle.wiki new file mode 100644 index 0000000..8202330 --- /dev/null +++ b/wiki/V3M_Eagle.wiki @@ -0,0 +1,11 @@ +h1. V3M Eagle + +| "v2.19.0-custom":../../wiki/V3M_Eagle/v3m_eagle_do_xls2-20170801b.tar.gz +|R-Car Gen3 Initial Program Loader(CR7) Rev.1.0.1 +BL2: R-Car Gen3 Initial Program Loader(CA53) Rev.1.0.9 +BL2: Built : 10:31:37, Mar 17 2017 +U-Boot 2015.04 (Jun 07 2017 - 19:52:37)| + +h1. Files + +"zip: V3M Eagle":../../wiki/V3M_Eagle/v3m_eagle.zip diff --git a/wiki/V3M_Eagle/v3m_eagle.zip b/wiki/V3M_Eagle/v3m_eagle.zip Binary files differnew file mode 100644 index 0000000..958c141 --- /dev/null +++ b/wiki/V3M_Eagle/v3m_eagle.zip diff --git a/wiki/V3M_Eagle/v3m_eagle_do_xls2-20170801b.tar.gz b/wiki/V3M_Eagle/v3m_eagle_do_xls2-20170801b.tar.gz Binary files differnew file mode 100644 index 0000000..b9cb01c --- /dev/null +++ b/wiki/V3M_Eagle/v3m_eagle_do_xls2-20170801b.tar.gz diff --git a/wiki/Yocto.wiki b/wiki/Yocto.wiki new file mode 100644 index 0000000..64588ed --- /dev/null +++ b/wiki/Yocto.wiki @@ -0,0 +1,11 @@ +h1. Yocto + +| v2.19 | "StartUpGuide":../../wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.19.0.pdf | +| v2.17 | "StartUpGuide":../../wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.17.0.pdf | +| v2.16 | "StartUpGuide":../../wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.16.0.pdf | +| v2.12 | "StartUpGuide":../../wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.12.0.pdf | +| v2.9 | "StartUpGuide":../../wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.9.0.pdf | +| v2.8 | "StartUpGuide":../../wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.90.pdf | +| v2.7 | "StartUpGuide":../../wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.80.pdf | +| v2.3 | "StartUpGuide":../../wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.40.pdf | +| v2.2 | "StartUpGuide":../../wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.30.pdf | diff --git a/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.30.pdf b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.30.pdf Binary files differnew file mode 100644 index 0000000..41a9e44 --- /dev/null +++ b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.30.pdf diff --git a/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.40.pdf b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.40.pdf Binary files differnew file mode 100644 index 0000000..ea9ba8a --- /dev/null +++ b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.40.pdf diff --git a/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.80.pdf b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.80.pdf Binary files differnew file mode 100644 index 0000000..f81a14e --- /dev/null +++ b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.80.pdf diff --git a/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.90.pdf b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.90.pdf Binary files differnew file mode 100644 index 0000000..05d8bf6 --- /dev/null +++ b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v0.90.pdf diff --git a/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.12.0.pdf b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.12.0.pdf Binary files differnew file mode 100644 index 0000000..d676ed1 --- /dev/null +++ b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.12.0.pdf diff --git a/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.16.0.pdf b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.16.0.pdf Binary files differnew file mode 100644 index 0000000..b2fbaa7 --- /dev/null +++ b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.16.0.pdf diff --git a/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.17.0.pdf b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.17.0.pdf Binary files differnew file mode 100644 index 0000000..0934ec2 --- /dev/null +++ b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.17.0.pdf diff --git a/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.19.0.pdf b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.19.0.pdf Binary files differnew file mode 100644 index 0000000..b267e21 --- /dev/null +++ b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.19.0.pdf diff --git a/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.9.0.pdf b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.9.0.pdf Binary files differnew file mode 100644 index 0000000..290ff4a --- /dev/null +++ b/wiki/Yocto/RENESAS_RCH3M3_YoctoStartupGuide_UME_v2.9.0.pdf diff --git a/wiki/member_info.wiki b/wiki/member_info.wiki new file mode 100644 index 0000000..d19dce7 --- /dev/null +++ b/wiki/member_info.wiki @@ -0,0 +1,102 @@ +h1. Member info + + +h2. Member Repositories (and related development trees) + +|_. Repository |_. URL | +| mainline | git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git | +| renesas-drivers | git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git | +| renesas-bsp | git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git | +| linux-media | git://linuxtv.org/media_tree.git | +| gmsl | git@github.com:kbingham/linux.git | +| airlied (drm-next) | git://people.freedesktop.org/~airlied/linux | +| horms | git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git | +| jmondi | git://jmondi.org/linux-gen3 | +| kbingham | git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git | +| neg | git://git.ragnatech.se/linux/ | +| pinchartl | git://linuxtv.org/pinchartl/media.git | +| uli | git@github.com:uli/kernel.git | +| wsa | git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git | + +Please keep the list alphabetically sorted. + +h2. Geert Uytterhoeven - geert@linux-m68k.org + +<pre> +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCvXuyHHS5NoTXM4lmqL1rJeBxbfw0bGtAeW4wXZOYy/SM2jAdPMWHytEZcmNhzKCCFwrEOoEHc7mvROVgONyXNF6/PxFrVYspp0MpoSEro+eBkMOpFwsHb6IS8wxEvGsrCF2kmiS6uzsro/2Yrn5oUtCTS5lajTRkHqUQgS5r9mTarCuNpb96ZKEw93W4Td5dr+7Ol0TYygO4IWvGPq+oMP8H0MYxOsllQ4cmhuMFGsRCco1kshmgduMye6HlMx8F11fVrcshF9lZAazEwevl7/ZKx0ohdE/U5zVK6MOVYc12ogQhwDtqTrLse2/Wizc+3KWXwjWXkaCs0YapVIFOD geert-at-home +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4WbozQ9wZC+VfnSOoBStyWkSIoFxnNAhL4bo8nncRuvP049rUn/AJfD4ScF1RUZcQ1OG18Hta4VPwWYN22Asb92fjjOP7isK2PDy1nS232MYYgn/F1sPZx4C3dZOV6EEE4Fazwp/gb+5hed0PANq0yQR7ZuEoaIW6aHVZWFa4PPZ3KNfMt2PSj9F8kOvvvglAWXenZwiQ0d8jcQgMTZiWGorC2wRmQ0psDbwBTOCR+TLbNejYYEvnbaP7tMCT6J5i3dDGQZGhKkGybJxW2ry+Ruvf1fTBiL3lRhUUvaSboB7kbCZOJ0LfNYRCeGs5dotTWvC27HbnX55hXVMN0d53 geert-on-the-road +</pre> + +Upcoming holidays: + +* 2018-08-09 - 2018-08-20 (+ padding) + +h2. Jacopo Mondi - jacopo@jmondi.org + +<pre> +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4lZbd/7stS60h+Zw2yQRFLIScjCZqwmptfqOlLKQYfxZpu5h+enfMy7Yn+zXN1HWG1JvOrog8UO2cJjiVh2nhNl+sz6KRTkQ7uh8FgYdB1zvQe6ud1rQwvPkUTDtTzwJzlzJDReg0mSzgrAWAYh2+pRGV5rhQN2rrMVVpLAy4f9jdWYwtNuykowpnaE9regCbuvGSUkzSpS3si/+BGXp1HamUiozyroUIX4r6MO07tevxnXWgBKVFPD2BhOYrv8CMA5JbAK5F/v8pRajVNCi5NRZ+wMfaCQkWXFKTCdqw9a/CDqPb30VbZgkBy1iaUqzjoFxN1CTiK1dTM613kW0P jmondi@w540 +</pre> + +h2. Kieran Bingham - kieran.bingham@ideasonboard.com + +<pre> +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDaudreJ8+NrJgZVSJvElycZWqwT6exvQRhWOj8JdxJm81p3pS2a2jws1YLtIgL53weXanjtx44gWyVETg1yiaBe/AJ3HCWbpLp4HJR9BgIH7DreccwBJ2qnBDSVHYXRfyra2EhY+/6BslB3rMaopel0zOk5ooRw3yuNYT/p3CPoVS4WLRadYqV29YQ5I8FoMghDkUwvLksljJdVGGHAgnh2L1+doJHFMm4gYPVnbvcs7xS8+CHM8t8dT9bk6EmOHY8guPRNrXuppqOydLpENnOASlBvfwtXUe3X2mqh5B4sVUDPbctha92qdUKCpdFF/UBaRPJYsCEfyNhg7D/D+cRz3VAKjBGOxojIrelkU3/3XCzXo6/RpNGRmtVXL0Ceu9J3qdWNjDQ9MVaJEb4uVYvA09DqtWNFIDM5JqiHfQKyXlUxaJoVFjSbieIvIrkGk2F77KHMKDbJgaryG1TnFgIOb42qaI8NDo3BnM8FyllSeAm+bEMpZI0W2fhcuaizSgjwfUbSO3EpcqtWTehDMEaxWXxgCzxpJx20C37SOpZNfkOD3oXGgPnnDrtXL0EniEEZ9egaieAEbTafH1BiGZh6fjNRVnEqhRb3pue1t/hBbtw+tIQJqWPgSU93VrIvDVvAjEJrwJXBart1sf7piMih4p0jWK5Qm7wfv1IlFyA5Q== kbingham@CookieMonster +</pre> + +h2. Kuninori Morimoto - kuninori.morimoto.gx@renesas.com + +<pre> +ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAz4yMLrm7qDBvNDeHIb2XC9jcwoLHkjj76QIY0IPxpXBo3wAuw3ZgPr98A4ZkI4MC5byLi/j/QmISvsrfTu2i6TAhSOKBFcOHavXjnlS0wphgKCAfXn2CVGiZEryKz06LZWET06s7PJ+JzbFr5/FP+wBxZjGPwsoJeT78/JEpK/js2VxDGzJrPniJcPNxNoOJwR18KtP6kgAl2/ljrrGbTcI5+B45nGybheCafHII98SsyPAXcU95kcDBXob1M1RaIwWAIkgAWzyRjQAYu9WftP2TiWSTimmRs5ZxQPnVlG3USamm3dke2RoL8F3zbwz0pHkwSIKcy3q77Evu5uE4gQ== SSH_KEY_FOR_Kuninori_Morimoto +</pre> + +h2. Laurent Pinchart - laurent.pinchart@ideasonboard.com + +<pre> +ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAtN8oXUBxELmTYME2EhuJQ+pL+RULG8Z03wszFbJOsst5fAJo6If1augpPTPhffDTvvyXVboQf9gJ8Rdin166Xra+Gxd4KAPLcLyNJXKUoWkBE12yl27QUXYd3TT1lKS3/dJCjyBHLAT8Tufs6ellFqw66olLbRodLJ/P4dxnfs3Zh0O17aG+cptDIeMBmxOBRIu/yiuNSDMPkm/z3R6LXVx/249fz811BcXOcK2dPwYWw2dQiHx3fcHpgtkTTYTK6GTmnQ8oeygK/1/CsHJlEf6JRYyFq3V/O2zDItYB1eNSeyYZp/TczPAU1fxfHB1Lpgp7e+DCmQnLrwTqCgQ9Qw== laurent@avalon +</pre> + +git: git://linuxtv.org/pinchartl/media.git + +Upcoming holidays: + +* 2018-04-29 - 2018-05-14 + +h2. Marek Vasut - marek.vasut@gmail.com + +<pre> +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCrz3tQGpLC+FlW2PaRO0d2eNjFCiGOi+zU+U3NBZNIqHZEYgbNsWe4Su1oSfC8xR1ROWAPvDftcCMCPJnwzzX3RhMS0F05jFrq9Jz8blDGOXLf7aUAyf3P6NrO0GzhG58n6G5b0v1x5PdBARSyhWfVTWUfCTpWjHdqXVVQdoqNFb2fzmxCBa0U4rYDugOWsZERbczTvhGAJfweJo9X8c3kxG55d9ZLe+VxKXoXpHY1PehiX5lDxg6NnKggZ/ZZi23dFCtxnZy/JdP3FA+uip2msN+kpChxUdME5ycYo3mqlU6F96GxJ41Zo+7J9iSmgdE2vgpMTxb+LCjwrVCZl+89AzjlH9pKw5pUVLOtv4tuPs0XR6YvJOcZk8/icb/kDHLqQPv46icm12cQ2KYXoKmJD+ahWFbB2Wlj+T7GDogBO91HwIw1fuAgoXIij9tJvS+qq+cr5AT6kVS9XEEQlxbL8fXo7dynTs/ejJHJI+zdcTRT4Ym6qtSnhW8pY0Rtd43l9MQ+aCS8zuJ9bDKtTGllgiMMDhNsJp7jP1wwd29FlQOvcWTzy97Y7ODYInGYDulE0VptSm1uPBZoygh3ea8QPErbGYR6jtaPMd0FQhKxVQgVsGMXC/bjGbfTMOIlNZrC6ZygL+kaji0baTC5ofXK8OXf0yQonMwORpEnJjlguw== renesas.docs +</pre> + +h2. Niklas Söderlund - niklas.soderlund@ragnatech.se + +<pre> +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDnSERzIhnrqEGYBsj8XhlGpVlUkVWmMXfNfpf+5Yph22fxjsJcH2BsFc8q2sThD5SfUAldq98N95vMJOFmeYyk6u0+xHo+Qv9+IznGjOhZ7k5aL5DbDnGVzu5pB7OGsidaX4I97ADki9oAefWk6UVfQpjJYMitQlBh6lsbwnbstoHB9scBF7Wwr/Qmzj0H6aoct/BKuzi/LN+i+O/lMMzh2ihYq5owZc0qeZ311l2/G43UMCE1q5Ipk9xNuK/CbL9FrCc2ICU5ZF9bLuZTp39whVAZFqWG8ezNfgzgjLqk4SwYxtDuEsgQhsyKUJqAgkotubAaLd+tEG5VZN7IqHGODe1ncCNV+yWe4d37FqpFMFKcUhKqKLbfaS9MqfNJ34/0XqnUR3wahhuJlzwsALqkTJBDb7Mbovgqin6B8Ou/5DTAr97NZyXF14ybhUCxqfidY0M+DycMqPkgy6f1hW2tniiWaCYv8xeCAdF8+/swd/kF6CxYwNfvgbjd/Xpw9j0zUetVtmYC2WV//rALo64AgDA55txHodpMeioGSkYL7PGXVswdsaOtL0GQcAHnUUSMlObrz2+vghtUaBuczmQr+YynNP86RA/9SG6729uSB5NWk6lnz1ifOTG9FH9RbrODLDe21r18+58kO4aRsDrmKbB4QiFilsKCZ8Te+ZWWhQ== renesas +</pre> + +h2. Simon Horman - simon@horms.net + +<pre> +ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsJq/3oJeJEFd1QVtAkHjhi67pp9QMnsr6fuitCoc8CrzzvdXWUnBwH4fbXBPNur4HYlzcKOc2l7IsgFXmAoGnoYJus2Ovhk/1xkijawGtGyTvHt7LPzvM/+c9l27MhmMtB2UyFqxJUE9aJfSaB+lJf+tPepc8JWP2gPkpMB5EIDazHD9gRTuNydO39ZxuqcuhqfX1GT3pnV4fNphbYgO0epYtwHjMgb4TiXZ73jyfZYpHVN0cVKmBa60iVgfIjCr6HQGl348rQCR0f6Si6JEsMLu3BSY42xA3kXxzQYahqlCjG+I2yqgsHEk2qupjk7nUeQ3QqDpEh+Thf1NGaSAjw== horms@yukiko.kent.sydney.vergenet.net +</pre> + +Upcoming holidays: + +* 2019-4-16 - 2019-2-19 + +h2. Ulrich Hecht - ulrich.hecht@gmail.com + +<pre> +ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqEw9JioTiymaj9VSNkD32DQShrlRD9qAuAiSZ4NgpkxJeEFuUgymrY4f4gkDx8KrQ3WUPygkrr6zKy1XK5i+1zKTpjfmUU7GuRuwKliqzFpFSDxxGnGqynffGZCk+SV8aB95/5O6INpY+oJngoH5DpRpSHDHwUUUqCXTUydrQdChnguE+ASFhTJfPSBWQUaZZhEQi0FBdPklQWaeWR/YQASbEbK4/fZG0LwZ3k2XsezcD/WMpAFnhbn3aeH+FBBy/4P1LBocVUQOEABw7hIc45Ws8vc/BhNghLGml8tJJo9EYm2izXgcZkMdtu0xwgPqefJms0MPnUQKzSzPhRWxKw== ulrich.hecht@gmail.com +</pre> + +h2. Magnus Damm - damm@opensource.se + +<pre> +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDkmdmt6OBLm4OdYYLEtEcU99cBAM1AyqXVf2vXcRdFA4MviYWj8fnnlpQnqHoS8VYgmCnrxagI6jit1FLMpqMyYqXEzD/tRkv+StG9Ic+lPNmt+WhND2OYt12yxWEAhpmk231DUIdskKDjuwsuDW3y4yLqDUA/ti5+rOW2jhKXh22RDK2DqetH2AQCselLWI2fBzB9Js1azfdDsqNtP9m29hPAYe+3bo+hH6Pe4iNMjUSdOu9pB/8RsKtRz0zU4xRHLXR6nOICmfGvdTqsFDkRh2cc09KuHJDp/P6MqEyidFCGaIi/H8SCiHXCvLN8wYXB9N6OB2WPZajUgFvoKFrcPa0BLgIwMplEtG2gPW6lR5dq1qdRzcXauwBRobvpMHVPGjLW/r1wEfoZGLrLXaJ8UQB0z8JiPeGQFxrnA7WV3IcyeC5SV107fPTp4NV3HKzZLrPPOREqarsrxW89nTmuImVAq100FHKPn4xCymRaIiYHZIVGgdNxHJkBc6HEpcFO4lBlqNeV6RKKmG0Wget6S6D0D63UPzEQ4HteLlc2VRM6Avhb1RoPxiuN+J15Gep7doWsKw49lTRPbsKWrYwPnFdcSl/HScpM7l2vhbi7dG84Tk+G35j8K1ySE38P7EuPujeX3KuYwxAoGBSp0ch0Ypigb4ztbvdSuac9BPSXzw== damm@Magnuss-MacBook.lan +</pre> + +h2. Wolfram Sang - wsa+renesas@sang-engineering.com + +<pre> +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDIfWJjjcxqYmI2fbaoy1QVLx9R5kerqXdNv0KGmynMMf0jQj2k8t1/ayQudzaZwIadlmY5/HRxrXGx/prIQsPS1oy41bXh96COqQtZb/Leu1vcgi/KEgBtQFw+VMqAq5NrvEvuxcOVoqFIdxwOmuHtT+Fc0dQxQOPkiklN9N8kcsQK0mLhZMY02FfpaS3fQkH9So5pYASAmdImoUT1W52X7NardQjmairOlAvEc0Pj/hqSGybNeN8CZWOe7ZE8EMuiE5ct39bGAdiag2B3UAnH/q0GDLFM8lMtmLI4hq98fTpVUkupQfN475lPyZZQou+pEXXKVwBT8yBIDoOc/LhH ninja@katana +</pre> diff --git a/wiki/sdhi_scratchpad.wiki b/wiki/sdhi_scratchpad.wiki new file mode 100644 index 0000000..87f28a7 --- /dev/null +++ b/wiki/sdhi_scratchpad.wiki @@ -0,0 +1,55 @@ +h1. Hardware matrix (Linux) + +|_. SoC |_. ES |_. eMMC |_. SDR25 |_. SDR50 |_. SDR104 |_. HS200 |_. HS400 |_. Suspend/Resume | +| H3 | 1.0 | KLMBG4GESD-B03P | | [1] 30.1 MB/s | [1] 72.4 MB/s | [1] 126 MB/s | Not Supported | | +| H3 | 1.1 | | | | | | Not Supported | | +| H3 | 2.0 | KLMBG4GESD-B03P | | [1] 30,8 MB/s | [1] 75,2 MB/s | [1] 127 MB/s [2] 29.5 MB/s (SD 4.66) | [1] 166 MB/s [3] 33.8 MB/s (SD 5.41) | | +| H3 | 3.0 | | | | | | | | +| M3-W | 1.0 | SM662PB | [1] 19.1 MB/s | [1] 30.8 MB/s| [1] 78.9 MB/s | [1] 52.9 MB/s [2] 39.0 MB/s (SD 9.04) | [3] 48.5 MB/s (SD 4.48) | | +| M3-N | 1.0 | KLMBG4GESD-B03P | [1] 19.7 MB/s | [1] 32.8 MB/s| [1] 84.1 MB/s | [1] 155 MB/s [2] 77.4 (SD 25.1) | [1] 223 MB/s [3] 33.4 MB/s (SD 10.9) | | +| E3| 1.0 | | [] | [] | [] | [2] 51.6 MB/s (SD 29.5) | [3] 102 MB/s (SD 18.9) | | +| Koelsch| 1.* | | | [1] 30.2 MB/s| [1] 47.5 MB/s | | | | + + +1. Hackfest code base. Tested using same SD cards using 'dd if=/dev/mmcblkX of=/dev/null bs=1M count=512' +2. v5.0. Tested using dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct "data : v5.0":./EMMC-speed-raw-data.html +3. renesas-devel-20190306-v5.0. Tested using dd if=/dev/mmcblk0 of=/dev/null bs=1M count=512 iflag=direct "data : renesas-devel-20190306-v5.0":./EMMC-speed-raw-data.html + + +h1. Hardware matrix (U-Boot) + +|_. SoC |_. ES |_. Board |_. eMMC |_. HS200 | +| H3 | 2.0 | Salvator-XS | Samsung KLMBG4GESD-B03P | 174 MB/s | +| H3 | 2.0 | ULCB | Samsung KLMBG1GESD-B04P | 169 MB/s | +| M3W | 1.0 | Salvator-X | SiliconMotion SM662PB | 54 MB/s | +| M3W | 1.0 | ULCB | Micron MTFC8GACAENS-K1 AIT (6XA28 D9TYY) | 171 MB/s | +| M3N | 1.0 | Salvator-XS | Samsung KLMBG4GESD-B03P | 174 MB/s | +| E3 | 1.0 | Ebisu 4D | Samsung KLMBG4GESD-B03P | 173 MB/s | + +|_. SoC |_. ES |_. Board |_. eMMC |_. HS400 | +| H3 | 2.0 | ULCB | Samsung KLMBG1GESD-B04P | 286 MB/s | +| H3 | 2.0 | ULCB | SanDisk SDINBDG4-64G | 131 MB/s | + +|_. SoC |_. ES |_. Board |_. SD |_. Class |_. SDR104 | +| M3N | 1.0 | Salvator-XS | AData Industrial MLC 16GB | SDHC, UHS I | 80.8 MB/s | +| M3N | 1.0 | Salvator-XS | Kingston Ultimate SDA10/16GB | SDHC, Class 10, UHS I | 68.5 MB/s | +| M3N | 1.0 | Salvator-XS | Kingston Ultimate SD10VG2/32GB | SDHC, Class 10, UHS I | 12.4 MB/s | +| M3N | 1.0 | Salvator-XS | Sandisk Extreme Pro 16GB | SDHC, Class 10, UHS I | 90.4 MB/s | +| M3N | 1.0 | Salvator-XS | Sandisk Extreme 32GB | MicroSDHC, UHS I, A1, V30 | 87.8 MB/s | +| M3N | 1.0 | Salvator-XS | Samsung Pro 16GB | MicroSDHC, UHS I | 89.1 MB/s | +| M3N | 1.0 | Salvator-XS | Toshiba Exceria M302-EA/32GB | MicroSDHC, Class 10, UHS I, U3 | 56.3 MB/s | + +Tested by measuring duration of the following command in U-Boot, which reads 512MB from the card to DRAM: +@=> mmc read 0x50000000 0 0x100000@ + +h1. Current schedule + +* RuntimePM still causes "non-removable":https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0bc0b6e86524526c92a9409faea79d53db8e7e6e workaround, probably related to SDnH clock disabled somhow +* upport SDHI manual calibration + +h1. Known issues + +* -HW support for eMMC High Priority Interrupts (HPI) not implemented- MMC maintainer doesn't recommend to implement it +* HW busy timeout not implemented. We could then remove the timeout tasklet and still support MMC_CAP_ERASE + +h1. References and links diff --git a/wiki/top.wiki b/wiki/top.wiki new file mode 100644 index 0000000..535a4d6 --- /dev/null +++ b/wiki/top.wiki @@ -0,0 +1,58 @@ +h1. "PeriJect":https://osdg.renesas.com/periperi/periject + +h1. [[member info]] + +h1. [[Chat log]] + +h1. Core group + +* member +** *Geert* +** Laurent +** Magnus +** Morimoto +** Shimoda +** Ulrich +** Niklas + +h1. I/O group + +* member +** Geert +** Marek +** Niklas +** Shimoda +** Ulrich +** *Wolfram* + +* [[sdhi scratchpad]] + +h1. Multimedia group + +* members +** Jacopo +** Kieran +** *Laurent* +** Magnus +** Morimoto +** Niklas +** Ulrich + +* [[Ongoing Multimedia Development]] +* [[GMSL Camera Setup]] + +h1. [[Hardware]] + +h1. PeriPeriCon + +* [[2019-02-periperi]] +* [[2018-10-periperi]] +* [[2018-02-periperi]] +* [[2017-10-miniperi]] +* [[2017-09-periperi]] +* [[2017-05-miniperi]] +* [[2017-02-miniperi]] +* [[2016-10-miniperi]] +* [[2016-07-renesas]] +* [[2016-07-miniperi]] +* [[2016-02-periperi]] |
