diff options
| -rw-r--r-- | projects/linux/core/bsp392_arm64_dts_renesas_r8a7795.yaml | 14 | ||||
| -rw-r--r-- | projects/linux/core/bsp392_arm64_dts_renesas_r8a7796.yaml | 14 | ||||
| -rw-r--r-- | projects/linux/core/done/bsp392_arm64_dts_renesas_r8a7795.yaml | 16 | ||||
| -rw-r--r-- | projects/linux/core/done/bsp392_arm64_dts_renesas_r8a7796.yaml | 16 | ||||
| -rw-r--r-- | projects/linux/core/dt_bindings_json_schema_core.yaml | 20 | ||||
| -rw-r--r-- | projects/linux/core/r8a77961_core.yaml | 6 | ||||
| -rw-r--r-- | projects/linux/io/I2C-fix-slave-corner-cases.yaml | 13 | ||||
| -rw-r--r-- | projects/linux/io/WDT-handover_from_bootloader.yaml | 6 | ||||
| -rw-r--r-- | projects/linux/io/dt_bindings_json_schema_io.yaml | 16 | ||||
| -rw-r--r-- | wiki/Chat_log/20200806-core-chatlog | 147 | ||||
| -rw-r--r-- | wiki/Chat_log/20200806-io-chatlog | 108 | ||||
| -rw-r--r-- | wiki/Chat_log/20200903-core-chatlog | 137 | ||||
| -rw-r--r-- | wiki/Chat_log/20200903-io-chatlog | 175 | ||||
| -rw-r--r-- | wiki/Chat_log/20200903-mm-chatlog | 255 |
14 files changed, 894 insertions, 49 deletions
diff --git a/projects/linux/core/bsp392_arm64_dts_renesas_r8a7795.yaml b/projects/linux/core/bsp392_arm64_dts_renesas_r8a7795.yaml deleted file mode 100644 index 60c7b76..0000000 --- a/projects/linux/core/bsp392_arm64_dts_renesas_r8a7795.yaml +++ /dev/null @@ -1,14 +0,0 @@ -title: "From bsp392, upport arm64: dts: renesas: r8a7795:" -team: Core -key: 9401ae0d-1d56-4cea-84b4-cea9aef1fcd5 -status: New - -relationships: - -bsp-commits: - - 55f098971fd427d4cf36b9424b99d3f2235c1c49 # arm64: dts: r8a7795: Add OPPs table-{1-7} for cpu devices - -upstream: - -comments: - - "55f098971fd427d4cf36b9424b99d3f2235c1c49: requested upport with 9c17869e23b54b41d75e09069efecb6c08464099 of BSPv3.6.0" diff --git a/projects/linux/core/bsp392_arm64_dts_renesas_r8a7796.yaml b/projects/linux/core/bsp392_arm64_dts_renesas_r8a7796.yaml deleted file mode 100644 index a3f26d9..0000000 --- a/projects/linux/core/bsp392_arm64_dts_renesas_r8a7796.yaml +++ /dev/null @@ -1,14 +0,0 @@ -title: "From bsp392, upport arm64: dts: renesas: r8a7796:" -team: Core -key: d3b5d78a-208e-4de2-9af7-b81611d9bcc7 -status: New - -relationships: - -bsp-commits: - - 033aee12f32ea1f75c4553ca8685edeb6e82a00f # arm64: dts: r8a7796: Add OPPs table-{1-7} for cpu devices - -upstream: - -comments: - - "033aee12f32ea1f75c4553ca8685edeb6e82a00f: requested upport with 1baee1bebe00e8741d57cf2e2c7fff6b04e41ae2 of BSPv3.6.0" diff --git a/projects/linux/core/done/bsp392_arm64_dts_renesas_r8a7795.yaml b/projects/linux/core/done/bsp392_arm64_dts_renesas_r8a7795.yaml new file mode 100644 index 0000000..2e8ae89 --- /dev/null +++ b/projects/linux/core/done/bsp392_arm64_dts_renesas_r8a7795.yaml @@ -0,0 +1,16 @@ +title: "From bsp392, upport arm64: dts: renesas: r8a7795:" +team: Core +key: 9401ae0d-1d56-4cea-84b4-cea9aef1fcd5 +status: Done + +relationships: + +bsp-commits: + - 55f098971fd427d4cf36b9424b99d3f2235c1c49 # arm64: dts: r8a7795: Add OPPs table-{1-7} for cpu devices + +upstream: + - torvalds: dd149e851ace00a7832846e46ddefc6b181522c2 # arm64: dts: renesas: r8a7795: Add OPPs table for cpu devices + - torvalds: 85618efe149082b50f846834356b3bc23c4d1141 # arm64: dts: renesas: r8a7795: Update OPPs to support CA53 dfs + +comments: + - Upstream does not have multiple OPP tables for AVS and 3DGE diff --git a/projects/linux/core/done/bsp392_arm64_dts_renesas_r8a7796.yaml b/projects/linux/core/done/bsp392_arm64_dts_renesas_r8a7796.yaml new file mode 100644 index 0000000..19a99fd --- /dev/null +++ b/projects/linux/core/done/bsp392_arm64_dts_renesas_r8a7796.yaml @@ -0,0 +1,16 @@ +title: "From bsp392, upport arm64: dts: renesas: r8a7796:" +team: Core +key: d3b5d78a-208e-4de2-9af7-b81611d9bcc7 +status: Done + +relationships: + +bsp-commits: + - 033aee12f32ea1f75c4553ca8685edeb6e82a00f # arm64: dts: r8a7796: Add OPPs table-{1-7} for cpu devices + +upstream: + - torvalds: fbdad84cc759abc469e476ee2518d77280e80cd0 # arm64: dts: renesas: r8a7796: Update OPPs to support CA53 dfs + - torvalds: da7e3113344fda50b10f1ad2c633abaaaf25d21b # arm64: dts: renesas: r8a7796: Add OPPs table for cpu devices + +comments: + - Upstream does not have multiple OPP tables for AVS and 3DGE diff --git a/projects/linux/core/dt_bindings_json_schema_core.yaml b/projects/linux/core/dt_bindings_json_schema_core.yaml index 25be229..77951f2 100644 --- a/projects/linux/core/dt_bindings_json_schema_core.yaml +++ b/projects/linux/core/dt_bindings_json_schema_core.yaml @@ -20,20 +20,20 @@ upstream: - torvalds: 59e7166fe0e2cb210252c3454a9241e586a2ba42 # dt-bindings: clock: renesas: div6: Convert to json-schema - torvalds: 9b9df63b50306b9602954d2f40fa8e05c0c27fda # dt-bindings: clock: renesas: mstp: Convert to json-schema - torvalds: c22fc62b516de5eeea7b518a68e258948e6276ce # dt-bindings: gpio: Add renesas,em-gio bindings - - lore: 20200427192259.27978-1-geert+renesas@glider.be # dt-bindings: gpio: rcar: Convert to json-schema - - lore: 20200507075503.32291-1-geert+renesas@glider.be # dt-bindings: irqchip: renesas-intc-irqpin: Convert to json-schema - - lore: 1587446152-23886-1-git-send-email-yoshihiro.shimoda.uh@renesas.com # dt-bindings: iommu: renesas,ipmmu-vmsa: convert to json-schema - - lore: 20200417140920.22596-1-geert+renesas@glider.be # dt-bindings: pinctrl: sh-pfc: Convert to json-schema - - lore: 20200518081644.23683-1-geert+renesas@glider.be # dt-bindings: clock: renesas: cpg: Convert to json-schema - - lore: 20200519080812.28632-1-geert+renesas@glider.be # dt-bindings: memory-controllers: renesas,dbsc: Convert to json-schema - - lore: 20200528132853.1751-1-geert+renesas@glider.be # dt-bindings: irqchip: renesas-rza1-irqc: Convert to json-schema + - torvalds: d9563c972c167e6e8b40c840d476d30af8e5f667 # dt-bindings: clock: renesas: cpg: Convert to json-schema + - torvalds: 4d0e62679f17b8bde01aa9995233b5b9ca05ab7f # dt-bindings: pinctrl: renesas,rza2-pinctrl: Convert to json-schema + - torvalds: 7f7d408e5a00d51519279e74176f7dc3a5eaa4a9 # dt-bindings: gpio: rcar: Convert to json-schema + - torvalds: 0be4ae74881c96ae8ff718bcfb517415ab61a41e # dt-bindings: irqchip: renesas-intc-irqpin: Convert to json-schema + - torvalds: dba496f36117a8d3d40c7e93e9a27d71168e302a # dt-bindings: iommu: renesas,ipmmu-vmsa: convert to json-schema + - torvalds: 8d6c65bd91bdccf98109916dc2d558af6c89396a # dt-bindings: memory-controllers: renesas,dbsc: Convert to json-schema + - torvalds: 2f6e6e11b23f9ee83eb568e56ef9867ffed950ba # dt-bindings: irqchip: renesas-rza1-irqc: Convert to json-schema + - lore: 20200821112208.5295-1-geert+renesas@glider.be # dt-bindings: pinctrl: sh-pfc: Convert to json-schema + - lore: 20200821111956.4989-1-geert+renesas@glider.be # dt-bindings: pinctrl: rza1: Convert to json-schema + - lore: 20200821112059.5133-1-geert+renesas@glider.be # dt-bindings: pinctrl: rzn1: Convert to json-schema comments: - Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt - Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt - Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt - Documentation/devicetree/bindings/dma/renesas,shdma.txt - - Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt - - Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt - - Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.txt - Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt diff --git a/projects/linux/core/r8a77961_core.yaml b/projects/linux/core/r8a77961_core.yaml index bcdc0c8..df31f48 100644 --- a/projects/linux/core/r8a77961_core.yaml +++ b/projects/linux/core/r8a77961_core.yaml @@ -14,8 +14,10 @@ upstream: - torvalds: 5ffce2f44fe9c163f0cb1c60ccb9e5e3f3b117a5 # dt-bindings: pinctrl: sh-pfc: Document r8a77961 support - torvalds: e7f1eb321b1a8497c5ddd59303c18864a95ab8bd # dt-bindings: power: rcar-sysc: Document r8a77961 support - torvalds: 248a887fc1aadd6681f772d5f797895fd9f0f863 # dt-bindings: reset: rcar-rst: Document r8a77961 support + - torvalds: 91a577e77fdf55bdc6cd863581658761908c1686 # dt-bindings: clock: renesas: rcar-usb2-clock-sel: Add r8a77961 support + - torvalds: 215c224f4dfa89f1d97500f419092c0110da3c2e # dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a77961 support + - torvalds: 17fe16181639801bfeba647a1e452a75efe651b4 # iommu/renesas: Add support for r8a77961 + - torvalds: f3e048b78ad37dff3ba81243f2533f336a240072 # iommu/ipmmu-vmsa: Add an entry for r8a77961 in soc_rcar_gen3[] comments: - - Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt - Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml - - Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt diff --git a/projects/linux/io/I2C-fix-slave-corner-cases.yaml b/projects/linux/io/I2C-fix-slave-corner-cases.yaml index e603c28..a71c6b3 100644 --- a/projects/linux/io/I2C-fix-slave-corner-cases.yaml +++ b/projects/linux/io/I2C-fix-slave-corner-cases.yaml @@ -5,12 +5,25 @@ assignee: Wolfram status: Active upstream: + - torvalds: 314139f9f0abdba61ed9a8463bbcb0bf900ac5a2 # i2c: rcar: slave: only send STOP event when we have been addressed + - torvalds: eb01597158ffb1853a7a7fc2c57d4c844640f75e # i2c: rcar: always clear ICSAR to avoid side effects + - torvalds: c7c9e914f9a0478fba4dc6f227cfd69cf84a4063 # i2c: rcar: avoid race when unregistering slave comments: - "Issue 1: we should not monitor every STOP but only when we have been addressed" - "v1 https://patchwork.kernel.org/patch/11632397/" - "v2 https://patchwork.kernel.org/patch/11632107/" + - "v1 merged" + - "Issue 2: how to properly handle the FNA bit" - "working prototype exists, waiting for confirmation from the HW team" + - "Issue 3: do we need to clear SAR when disabling the slave interface?" - "working prototype exists, needs confirmation from the HW team" + - "only applies to Gen2, Gen3 is fine" + - "v1: https://patchwork.kernel.org/patch/11643625/" + - "v1 merged" + + - "Issue 4: race when unregistering slave" + - "v1: https://patchwork.kernel.org/patch/11685989/" + - "v1 merged" diff --git a/projects/linux/io/WDT-handover_from_bootloader.yaml b/projects/linux/io/WDT-handover_from_bootloader.yaml index 8d3fa06..9cb69ab 100644 --- a/projects/linux/io/WDT-handover_from_bootloader.yaml +++ b/projects/linux/io/WDT-handover_from_bootloader.yaml @@ -2,9 +2,12 @@ title: Watchdog; implement handover from bootloader team: IO key: a0883915-709c-4116-afc3-2629f1b06a4f assignee: Ulrich -status: Done +status: Active upstream: + - torvalds: ed4a11807d2a35ccfc0d00371f20b826f670b5f2 # clk: renesas: cpg-mssr: Mark clocks as critical only if on at boot + - torvalds: f23f1101ad0ef1acdc219d3364522166e2c711ce # clk: renesas: rcar-gen3: Mark RWDT clocks as critical + - torvalds: 52bc5ea6edde35bc65ed6ecd7639534e78002c74 # clk: renesas: rzg2: Mark RWDT clocks as critical comments: - "RFC, needs discussion with Geert: https://patchwork.kernel.org/patch/10900571/" @@ -20,3 +23,4 @@ comments: - "Geert suggested to mark running WDT clocks as IS_CRITICAL during probe. Uli will implement this" - "v4: https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=303821&state=*" - "merged" + - "WDT driver update still missing, Wolfram will resend" diff --git a/projects/linux/io/dt_bindings_json_schema_io.yaml b/projects/linux/io/dt_bindings_json_schema_io.yaml index 8beac80..ba80f94 100644 --- a/projects/linux/io/dt_bindings_json_schema_io.yaml +++ b/projects/linux/io/dt_bindings_json_schema_io.yaml @@ -22,15 +22,16 @@ upstream: - torvalds: 45037dd681577e876b6085bad1aa44415b0cbe93 # dt-bindings: phy: renesas: usb2-phy: convert bindings to json-schema - torvalds: 007e358094bfb48f206c32b5c82777d980913d2f # dt-bindings: phy: renesas: usb3-phy: convert bindings to json-schema - torvalds: 809eb4e9bf9d84eb5b703358afd0d564d514f6d2 # dt-bindings: timer: Add renesas,em-sti bindings - - lore: 20200505155127.4836-1-geert+renesas@glider.be # dt-bindings: timer: renesas: cmt: Convert to json-schema + - torvalds: 038fb87fa3314e001de2dd4cf20a74fa623ac7ad # dt-bindings: usb: renesas,usb-xhci: convert to YAML + - torvalds: a1c76734095344fdbe43cbfe4940020e13151679 # dt-bindings: mmc: renesas,sdhi: convert to YAML + - torvalds: 41a053886b059d60945d3575e2328ff661599a04 # dt-bindings: timer: renesas: cmt: Convert to json-schema + - torvalds: d0941cfb9fa8ac69a67f264f81e2ba8ecb1caa0d # dt-bindings: watchdog: renesas-wdt: Convert to json-schema + - torvalds: 8f18632153e7f55d0150baa66af7a990fa812348 # dt-bindings: timer: renesas: ostm: Convert to json-schema + - torvalds: 37d1e94692e06a35c53ff052e2d0983548ef0395 # dt-bindings: thermal: rcar-gen3-thermal: Convert bindings to json-schema + - torvalds: 4b74c424a1b1d272e8677f26aeb5d37924fe7384 # dt-bindings: serial: Add renesas,em-uart bindings + - torvalds: bc6b83d636eb8b0083a166a6be6bae89440393c6 # dt-bindings: timer: renesas: mtu2: Convert to json-schema - lore: 20200518081506.23423-1-geert+renesas@glider.be # dt-bindings: timer: renesas: tmu: Convert to json-schema - - lore: 20200427192522.28365-1-geert+renesas@glider.be # dt-bindings: watchdog: renesas-wdt: Convert to json-schema - - lore: 20200427193224.29548-1-geert+renesas@glider.be # dt-bindings: timer: renesas: ostm: Convert to json-schema - - lore: 20200513151201.1258162-1-niklas.soderlund+renesas@ragnatech.se # dt-bindings: thermal: rcar-gen3-thermal: Convert bindings to json-schema - - lore: 20200519080945.28798-1-geert+renesas@glider.be # dt-bindings: serial: Add renesas,em-uart bindings - - lore: 20200528133033.4191-1-geert+renesas@glider.be # dt-bindings: timer: renesas: mtu2: Convert to json-schema - lore: 20200621081710.10245-1-geert+renesas@glider.be # dt-bindings: net: renesas,etheravb: Convert to json-schema - - lore: 1592822252-12338-1-git-send-email-yoshihiro.shimoda.uh@renesas.com # dt-bindings: usb: renesas,usb-xhci: convert to YAML comments: - Documentation/devicetree/bindings/i2c/renesas,i2c.txt @@ -39,7 +40,6 @@ comments: - Documentation/devicetree/bindings/i2c/renesas,riic.txt - Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt - Documentation/devicetree/bindings/mmc/renesas,mmcif.txt - - Documentation/devicetree/bindings/mmc/renesas,sdhi.txt - Documentation/devicetree/bindings/net/can/rcar_canfd.txt - Documentation/devicetree/bindings/net/can/rcar_can.txt - Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt diff --git a/wiki/Chat_log/20200806-core-chatlog b/wiki/Chat_log/20200806-core-chatlog new file mode 100644 index 0000000..28e4d93 --- /dev/null +++ b/wiki/Chat_log/20200806-core-chatlog @@ -0,0 +1,147 @@ +09:34 < marex> morimoto: shimoda: hi, I was curious, is there some extra documentation for the bootrom ? esp. the IPL A/B switching mechanism ? I recall the security LCS stuff in TFA implements some calls into bootrom, so maybe there is some list of bootrom functions you can call from your own system software ? is there some internal renesas documentation for that ? +09:35 < marex> I mean, there must be some way to push the bootrom to boot the IPL Bcopy, right ? +09:35 < geertu> marex: Sounds like Core? +09:35 < wsa> then, let's switch over to core. Zebax adapters fit there, too, if we want to keep the topic ;) +09:35 < wsa> geertu: have fun! +09:36 < geertu> wsa: Na, Samtec is I/O ;-) +09:36 < geertu> Welcome to today's Core Group Chat Meeting! +09:36 < geertu> +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> Marek worked on U-Boot (late driver teardown and SH4 fixes). +09:37 < geertu> Morimoto-san is considering a remote-access-system for COVID-19. +09:37 < geertu> Ulricht figured out i2c/wdt ordering for system restart. +09:37 < geertu> Geert attended ELC-NA, Reviewed RZ/G2 patches, investigated QEMU GPIO +09:37 < geertu> virtualization review suggestions, sent pull requests for v5.9, and +09:37 < geertu> enjoyed Summer Holidays. +09:37 < geertu> B) What we plan to do till next time: +09:37 < geertu> Marek plans to upstream CI test hooks for SH4 QEMU. +09:37 < geertu> Shimoda-san plans to convert the usb2-clock doc to json-schema, and +09:37 < geertu> start R-Car V3U initial support. +09:37 < geertu> Ulrich plans to follow-up i2c-sh_mobile atomic transfer work, and +09:37 < geertu> implement the same for i2c-rcar. +09:37 < geertu> Geert plans to do more DT binding doc conversions, and continue QEMU +09:37 < geertu> GPIO virtualization. +09:37 < geertu> (oops, looks like I included some I/O work) +09:38 < geertu> C) Problems we have currently: +09:38 < geertu> Geert is struggling with describing multi-level sh-pfc subnodes in +09:38 < geertu> json-schema, and discovered the QEMU GPIO virtualization review +09:38 < geertu> suggestions turned out to be unfeasible. +09:39 < geertu> ----EOT--- +09:39 < geertu> Anything I missed? +09:39 < geertu> morimoto: I'm looking forward to anything easing remote control of boards. +09:39 < morimoto> Yes, same here +09:39 < morimoto> but it is under discussion +09:39 < morimoto> now. no guarantee yet +09:40 < morimoto> marex: I have no idea. shimoda: do you know that ? +09:40 < geertu> You're aware Salvator-XS and Ebisu already provide all required signals for power/reset control on EXIO-D? +09:40 < morimoto> geertu: thank you for your help about v5.x booting +09:40 < geertu> Cfr. https://elinux.org/R-Car/Boards/Salvator-XS#Remote_Control +09:41 < geertu> You still need something to control main power, and provide the signals, so perhaps that's what "GPIO power/reset control" will be about on future boards? +09:41 < geertu> morimoto: You're welcome. The ability to boot boards is critical ;-) +09:42 < geertu> Topic 2. Discussion Topics +09:43 < geertu> A) IPL A/B switching +09:43 < geertu> marex: ^ ;-) +09:43 < marex> geertu: maybe if you could easily test your IPL before doing actual update, and with the ability to fall back to known working version by plain reboot ... +09:43 < marex> geertu: ... then people would finally ditch their old IPL and old U-Boot :-) +09:44 < geertu> marex: If only it supported H3 ES1.x... +09:44 < marex> geertu: and that easy test might be for example by being able to easily boot a B-copy of IPL ... +09:44 < shimoda> marex: As I wrote an email, IPL A/B feature is in secure boot +09:44 < shimoda> so, I don't think we can use IPL A/B in normal boot +09:44 < morimoto> geertu: we are considering for next new M4 board +09:44 < geertu> morimoto: BTW, what's M4? +09:44 < geertu> A, R-Car M4-something? +09:45 < marex> shimoda: isn't there some function call you can do to the bootrom, which would tell it to load the initial SA0 certificate from different location for example ? +09:45 < wsa> GeM4 +09:45 < wsa> ? +09:45 < marex> shimoda: or , patch the existing SA0 certificate in OCRAM at 0xe6300400 with the B-copy flag and then make bootrom start loading from that, without reloading the certificate ? +09:46 < morimoto> geertu: R-Car Gen4 M4-x board. +09:46 < marex> shimoda: there is https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/renesas/rcar/rom/rom_api.c +09:46 < geertu> morimoto: Cool! +09:46 < marex> shimoda: and that is some function call API to the bootrom itself +09:47 < marex> shimoda: so there clearly are some functions exported from the bootrom, and I wonder if maybe, there is a function which allows me to do the above :-) +09:47 < geertu> marex: Oh, that code does support H3 ES1.x +09:47 < marex> shimoda: in fact, is there a documentation which describes those bootrom functions ? +09:47 < wsa> morimoto: Cool, in deed! First time I hear about Gen4 becoming real +09:47 < marex> geertu: upstream ATF doesnt support H3 ES1.x, nor does upstream U-Boot +09:50 < morimoto> wsa: geertu: morimoto is the man who can fulfill your dreams +09:50 < marex> morimoto: do you still plan to run ATF-UBoot-Linux on that ? +09:51 < neg> marex: haha :-) +09:51 < neg> s/marex/morimoto/ about the fulfillment of dreams +09:52 < shimoda> marex: sorry, I don't understand what should i do about IPL A/B +09:52 < morimoto> neg: :) +09:52 < marex> shimoda: so, look at that rom_api.c code first +09:52 < wsa> morimoto: but it means a lot of paperwork for you again... :/ +09:52 < marex> shimoda: it seems that this allows ATF to call bootrom functions +09:52 < morimoto> marex: maybe, but not sure detail +09:52 < marex> shimoda: hence, there is likely a list of all such callable bootrom functions somewhere in renesas +09:53 < morimoto> wsa: yes :( +09:53 < marex> shimoda: and I wonder, can you share that list / document ? +09:53 < kbingham> marex, if ATF does support H3ES1.x (as listed in that table) does that mean I can update the firmwares/uboot on this gmsl board? or is uboot a hard blocker. +09:54 < marex> shimoda: and if not, can you look into that document and tell me whether there might be a function which allows me to skip reloading the SA0 certificate from HF and continue using the one in DBSC4 SystemRAM 0xe6300400 address instead , after reboot ? +09:54 < marex> kbingham: 07:47 < marex> geertu: upstream ATF doesnt support H3 ES1.x, nor does upstream U-Boot +09:54 < kbingham> marex, <geertu> marex: Oh, that code does support H3 ES1.x +09:55 < marex> kbingham: so if it was added and tested, you could +09:55 < kbingham> my question is given ATF has tables for H3ES1, does that mean there is a chance uboot will work, or it will need development. +09:55 < morimoto> \me I need to quit soon for next Renesas meeting +09:56 < marex> kbingham: its untested, so backup your HF and test it if you want :) +09:56 * morimoto n? +09:56 * morimoto I need to quit soon for next Renesas meeting +09:56 < wsa> then, next meeting? +09:56 < marex> morimoto: good bye :( +09:56 < wsa> Aug, 27th? +09:57 < geertu> I was just going to aak: 3 or 4 weeks? +09:57 < geertu> s/aak/ask/ +09:57 < kbingham> 27th is listed as Linux Plumbers (virtual) in my calendar +09:57 < morimoto> marex: I will miss you... +09:57 < marex> awwwww +09:57 < kbingham> morimoto, you can't go ... I didn't get to tell you that GMSL is headed upstream yet though ;-) +09:57 < kbingham> hehe +09:57 < wsa> Is Sep, 3rd better? It is fine for me +09:57 < geertu> both a re fine for me. +09:57 < geertu> Plumbers is in the afternoon/evening, right? +09:58 < kbingham> morimoto, Well, ok so I've told you now so you can go if you need ;D +09:59 < wsa> morimoto, shimoda: any preference for the next meeting? +09:59 < morimoto> kbingham: nice to know :) +10:00 < geertu> wsa: let's decide by email, as pinchartl isn't here +10:00 < morimoto> wsa: 27th Aug, 3rd Sep, both are OK for me +10:00 < wsa> geertu: good idea +10:00 < wsa> morimoto: so, enjoy your meetings! +10:00 < wsa> ;) +10:00 < geertu> Anything else to discuss? +10:00 < morimoto> wsa: thanks, and bye +10:00 < morimoto> exit +10:00 < shimoda> marex: now I understood a bit :) Renesas BSP doesn't have rom_api.c, but Baylibre submitted it. So, Renesas has a document which can share to someone for secure boot. OK, I'll ask a person in Renesas later. +10:00 < morimoto> oops +10:01 -!- morimoto [~user@FL1-119-240-85-188.iba.mesh.ad.jp] has left #periperi ["ERC (IRC client for Emacs 26.3)"] +10:02 < marex> shimoda: thank you, really appreciated :) +10:02 < geertu> Thanks for joining, and have a nice continued day! +10:02 < shimoda> perhaps, next meeting at 27th? +10:02 < shimoda> or, 3rd, Sep? +10:02 < marex> shimoda: see, the thing is, if I could do reboot-into-B-copy, I could also do easy-ish ATF CI testing without weird instrumentation around the boards +10:02 < shimoda> by the way, I used 2 laptop PCs, I can join both this meeting and Renesas internal meeting :) +10:03 < geertu> shimoda: smart ;-) +10:03 < shimoda> geertu: :) +10:03 < kbingham> geertu, Just digging for timezone of plumbers. Has it been announced? My registration just says "Timezone: TBD" +10:03 < geertu> Who takes the mic for MM? kbingham? +10:03 < shimoda> marex: I understood your expectation. thanks! +10:04 * kbingham fumbles in the air ready to catch. +10:04 < geertu> kbingham: It was originally planned to be held in US, right? +10:04 < geertu> ELC-NA was in NA timezone +10:04 < kbingham> geertu, I think there was a vote for preferred timezone of the virtual event, so they were going to make a decision on that. +10:04 < marex> shimoda: besides, we are lagging behind even NXP in this department +10:04 < kbingham> But I didn't see the decision results yet. +10:05 < marex> shimoda: NXP iMX can do this A/B copy update since iMX5x, which is like 10 years old now, we should improve +10:06 < shimoda> marex: thanks for sharing information about iMX +10:06 < geertu> marex: We have old SoCs. Arnd was wondering about us upstreaming "new" SoCs like RZ/G2H containing 2015-era CA57 ;-) +10:06 < marex> geertu: iMX51 is CA8 +10:07 < marex> shimoda: sure +10:08 < kbingham> Ok, so are we ready to head through to the mm room ? +10:08 < marex> shimoda: its also not any secret or secure feature, its all there in the datasheet, which btw is publicly available +10:08 < marex> kbingham: yep, I stop here +10:08 * kbingham waits to grab mic from geertu +10:09 < kbingham> or maybe I'll just shout without the mic ;-) +10:09 < geertu> kbingham: mic diff --git a/wiki/Chat_log/20200806-io-chatlog b/wiki/Chat_log/20200806-io-chatlog new file mode 100644 index 0000000..3273dec --- /dev/null +++ b/wiki/Chat_log/20200806-io-chatlog @@ -0,0 +1,108 @@ +09:03 < wsa> but now for the IO meeting +09:03 < wsa> hey shimoda-san, glad you could make it +09:03 < marex> wsa: run the crappy software in qemu and use usbmon ? +09:04 < wsa> marex: http://shop.sysmocom.de/products/openvizsla-v3-dot-2-usb-protocol-analyzer-pcba +09:04 < wsa> it's open HW, I always wanted to have it, but seems I need some reason ;) +09:04 < marex> wsa: what for ? you can use plain software +09:04 < wsa> not all the time +09:05 < marex> wsa: those few times I needed bus analyzer, I used beagle and it was good enough +09:05 < marex> wsa: USB is usually slightly broken, I don't feel like having to fix usually slightly broken debug tool too :) +09:06 * wsa prefers openHW over QEMU solutions, might be taste +09:06 < wsa> but now for the status updates! +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> : posted generic bindings for Ethernet MAC explicit internal delay setting as implemented by RAVB, fixed boot crash in pci-rcar-gen2 +09:06 < wsa> Shimoda-san +09:06 < wsa> : added DT support for eMMC needing full power cycle in suspend, converted the SDHI binding docs to YAML, fixed the USB PHY driver to handle DEBUG_SHIRQ, and fixed a re-initialization failure in the RAVB driver +09:06 < wsa> Ulrich +09:06 < wsa> : found a way to make sure the i2c controller is awake before triggering atomic transfers +09:06 < wsa> Wolfram +09:06 < wsa> : discussed and sent out binding to activate emulated SMBus features for I2C, reviewed the HostNotify I2C implementation and updated the usage of it in i2c-rcar, made bugfixes for I2C slave (race when unregistering, timeout problems with Gen2, better sanity checks in the core), reviewed proposal to increase I2C_M_RECV_LEN limit from 32 to 255 and added I2C_M_RECV_LEN to +09:06 < wsa> i2c-rcar, bugfixed the i2c slave testunit and added a I2C_M_RECV_LEN test, guided and reviewed generic initialization of i2c bus recover via GPIO/pinctrl, tested that the DEBUG_SHIRQ issue is gone, made patches to update its documentation +09:06 < wsa> B - what I want to do until next time +09:06 < wsa> ------------------------------------- +09:06 < wsa> Geert +09:06 < wsa> : wants to test PCIe suspend/resume after arrival of Intel PCIe Ethernet card +09:06 < wsa> Niklas +09:06 < wsa> : wants to do the yearly test with SDIO-WIFI on Koelsch +09:06 < wsa> Shimoda-san +09:06 < wsa> : wants to convert rcar-pci dt doc to json-schema, fix usbhs issue for u_serial driver +09:06 < wsa> Ulrich +09:06 < wsa> : wants to send next version of atomic transfers for IIC, and implement the same for I2C +09:06 < wsa> Wolfram +09:06 < wsa> : wants to activate generic I2C recovery for i2c-sh_mobile, upstream SMBus emulation binding and core HostNotify support and R-Car support for it, upstream I2C slave testunit, guide increase of I2C_M_RECV_LEN length to 255 and upstream R-Car support for it, fix all the flaws I found while developing the above, resend series 'fix stalled SCC' and 'implement manual calibration' for SDHI +09:06 < wsa> C - problems I currently have +09:06 < wsa> ----------------------------- +09:06 < wsa> Ulrich +09:06 < wsa> : wonders where to add the reboot notifier handling, in the driver or in the watchdog core +09:06 < wsa> Wolfram +09:06 < wsa> : has a second Zebax adapter which has a pin not working and wonders how the others are doing +09:07 < wsa> comments? +09:07 < wsa> we will talk about uli__'s question shortly +09:07 < wsa> (shortly? I meant "in a bit") +09:08 -!- morimoto [~user@FL1-119-240-85-188.iba.mesh.ad.jp] has joined #periperi +09:08 < wsa> from my side, it was nice that a few people tackled I2C issues which were also relevant for Renesas +09:08 < wsa> so, I could delegate some work to them and just guide them +09:09 < wsa> although it needed discussions, too +09:09 < wsa> however, this explains the heavy shift to I2C related work the last weeks +09:09 < wsa> shimoda: I will do an SDHI week next week to catch up with pending patches +09:10 < shimoda> wsa: i got it. thanks! JFYI, I will have a vacation from tomorrow to 16th +09:11 < shimoda> ah, just I got a report from BSP team about SDHI driver +09:11 < shimoda> so, I'll send an email to you today :) +09:12 < wsa> shimoda: thanks +09:14 < wsa> uli__: I wondered if you could add a helper function to the core (which still must be called from the driver) +09:14 < geertu> wsa: uli__ : or a flag, like spi_controller.auto_runtime_pm +09:15 < wsa> so, it is still not fully like "the core handles PM" but more like "there is code in the core reducing boilerplate if I want this feature" +09:15 < wsa> geertu: this will save converting the drivers, but still one would need to add generic PM handling to the core, right? +09:16 < geertu> wsa: yes +09:16 < geertu> Not much to do there, right? +09:16 < geertu> Start, Stop, Reboot? +09:17 < geertu> Adding 3 pm_runtime_*() calls if auto_runtime_pm is set? +09:17 < geertu> Or am I missing something? +09:18 < uli__> i must admit that i haven't looked in detail into what exactly those WDT drivers are doing in terms of PM, but that should be all I guess +09:18 < wsa> There are 4 WDT drivers using RPM +09:18 < wsa> 2 of them are from Renesas :) +09:19 < geertu> We are the RPM heroes ;-) +09:19 < wsa> just from grepping, it looks like OMAP does a bit more complicated things with RPM +09:21 < uli__> it still seems to me that the drivers that don't do runtime PM should do it, too. either i'm missing something, or it just "happens to work" for everyone +09:21 < wsa> i think it boils down if uli__ has the time and initiative to add this to the WDT core +09:21 < wsa> it would be nice to have, of course +09:23 < uli__> my gut feeling tells me to try getting it in the DA9063 driver first, and only do the WDT core if there are objections... +09:23 < geertu> That's always a valid approach. +09:24 < geertu> 1. Implement feature in one or more drivers +09:24 < geertu> 2. Move it to the core +09:24 < geertu> 3. Profit! +09:24 < wsa> Fine with me, too +09:24 < geertu> You could ponder step 2 in step 1 +09:25 < uli__> then i'll do that +09:25 < uli__> thanks for the advice +09:25 < wsa> sure thing, uli__ :) +09:25 < wsa> are there other questions or topics? +09:26 < wsa> has someone else experienced Zebax problems? Like Pin33 does not work anymore, but the rest does? +09:26 < geertu> It's the adapter, and not the board? +09:27 < geertu> IIRC, these are rated for less than 100 insertions, which I find a bit low. +09:28 < wsa> it is the adapter, another one works +09:28 < wsa> geertu: in deed :( +09:29 < wsa> I measured the adapter and the signal of my multimeter goes through. Very weird! +09:29 < wsa> But if you don't have problems, lucky you :) +09:29 < geertu> Probably a sloght displacement of the contact +09:29 < geertu> So far no problems (holds wood) +09:30 < uli__> which adapter are we talking about? +09:31 < wsa> uli__: The ones you dislike so much that you made your own one :) +09:31 < uli__> aren't there two kinds with different pin pitches? +09:31 < wsa> Samtec-to-breakout +09:32 < wsa> anyhow, I think this was it for the IO meeting +09:32 < wsa> uli__: yes, there are +09:33 < uli__> so which is the one that broke? +09:33 < wsa> uli__: I only have the "wide" pitch +09:33 < wsa> I'd like to have a narrow one somehow, but was irritated by the one losing a pin now +09:33 < geertu> That's 0.8 mm, right? +09:34 < wsa> yes +09:34 < marex> morimoto: shimoda: hi, I was curious, is there some extra documentation for the bootrom ? esp. the IPL A/B switching mechanism ? I recall the security LCS stuff in TFA implements some calls into bootrom, so maybe there is some list of bootrom functions you can call from your own system software ? is there some internal renesas documentation for that ? +09:35 < marex> I mean, there must be some way to push the bootrom to boot the IPL Bcopy, right ? +09:35 < geertu> marex: Sounds like Core? +09:35 < wsa> then, let's switch over to core. Zebax adapters fit there, too, if we want to keep the topic ;) +09:35 < wsa> geertu: have fun! diff --git a/wiki/Chat_log/20200903-core-chatlog b/wiki/Chat_log/20200903-core-chatlog new file mode 100644 index 0000000..cb355af --- /dev/null +++ b/wiki/Chat_log/20200903-core-chatlog @@ -0,0 +1,137 @@ +09:31 < geertu> Welcome to today's Core Group Chat Meeting! +09:31 < marex> wsa: nope +09:31 < geertu> wsa: No (new) family duties for you? +09:31 < wsa> (and I am not thinking of the sushi, honestly) +09:31 < geertu> Agenda: +09:31 < geertu> 1. Status Updates +09:31 < geertu> 2. Discussion Topics +09:31 < geertu> Topic 1. Status updates +09:32 < wsa> geertu: sure, but I can still go away for 2 weeks once in a while +09:32 < geertu> A) What have we done since last time: +09:32 < geertu> Marek work on SH4 QEMU test hooks for U-Boot, multiple mem node parsing +09:32 < geertu> for OpteeOS, and added basic R-Car Gen3 support to QEMU. +09:32 < geertu> Morimoto-san posted menu Kconfig patches. +09:32 < geertu> Shimoda-san started to develop initial support for R-Car V3U. +09:32 < geertu> Geert attended LPC, converted pinctrl bindings to json-schema, worked on +09:32 < geertu> head.S for RZ/A2, and kdump, and reviewed RZ/G patches. +09:32 < geertu> B) What we plan to do till next time: +09:32 < geertu> Marek plans to continue on QEMU. +09:32 < geertu> Shimoda-san plans to continue initial support for R-Car V3U, convert the +09:32 < geertu> usb2-clock doc to json-schema, and ping the hardware manual team about +09:32 < geertu> sharing the R-Car V3U manual. +09:32 < geertu> Geert plans to review more RZ/G patches, send pull request for v5.10, +09:32 < geertu> rename drivers/pinctrl/sh-pfc/, and perhaps continue QEMU GPIO +09:32 < geertu> virtualization. +09:33 < geertu> C) Problems we have currently: +09:33 < geertu> Geert suffers from failures in kernels booted through kexec. +09:33 < geertu> --EOT-- +09:33 < geertu> Anything I missed? +09:34 < marex> geertu: the gen3 qemu is still local and WIP +09:34 < geertu> Initial R-Car V3U support can be in v5.10, if it is posted and reviewed in time (i.e, during the next 2 weeks) +09:35 < wsa> no offence, but what do we need Gen3-QEMU for? +09:35 < marex> wsa: same as sh4 qemu, CI +09:35 < marex> wsa: and figuring out whether the bootrom can do switching between two copies of IPL somehow as a byproduct (for CI again) +09:36 < marex> wsa: SH4 U-Boot is tested in QEMU on every push to the repository +09:36 < geertu> Topic 2. Discussion Topics +09:36 < wsa> so, it is basically on CPU core level? I mean, you won't recode all of the IPs present, or? +09:37 < marex> wsa: I will model some subset of them +09:37 < marex> wsa: well, there is another upside in that you can track IO accesses and possibly detect writes to bits which you shouldn't be writing, like in PFC/clock +09:37 < wsa> yes, that's for sure +09:38 < geertu> Especially writes done by the boot ROM... +09:38 < marex> ... to registers which are undocumented ... +09:38 < wsa> I just wondered becuase Gen3 is, you know, HUGE +09:39 < marex> wsa: TFA/U-Boot doesn't use a large part of that, and Linux can also be reduced +09:39 < wsa> but I see the values you pointed out +09:39 < wsa> OK, I have a disucssion point +09:39 < wsa> pinctrl switching to GPIO +09:40 < wsa> major pain or small addition? :) +09:40 < geertu> wsa: I think that'll be rather a major pain, as it involves pinctrl core. +09:41 < geertu> Basically we need support for obtaining the GPIO corresponding to a function pin? +09:41 < geertu> Shimoda-san had a try at that a while ago +09:42 < wsa> Hmm, when I looked at other SoCs implementing bus recovery I had the impression they could do it using pinctrl. Am I wrong? +09:43 < geertu> wsa: Do you have a pointer to an example? +09:43 < marex> git grep pinctrl-1 +09:43 < damm> going back from pinctrl to GPIO? +09:43 < damm> full circle if so +09:44 < wsa> geertu: I am already checking +09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts- i2c1: i2c@fc028000 { +09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts- dmas = <0>, <0>; +09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts- pinctrl-names = "default", "gpio"; +09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts- pinctrl-0 = <&pinctrl_i2c1_default>; +09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts: pinctrl-1 = <&pinctrl_i2c1_gpio>; +09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi-&i2c1 { +09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi- clock-frequency = <100000>; +09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi- pinctrl-names = "default", "gpio"; +09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi- pinctrl-0 = <&pinctrl_i2c1>; +09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi: pinctrl-1 = <&pinctrl_i2c1_gpio>; +09:45 < wsa> [PATCH 0/4] i2c: core: add generic GPIO bus recovery +09:45 < damm> ah ok thanks for clarifying +09:46 < marex> wsa: so yep, the solution should be to call pinctrl_set_state() or whatever that is called now , pick the pinctrl-1 , do recovery, then pick pinctrl-0 +09:46 < geertu> These allow to specify GPIO in a DT pinctrl node +09:46 < geertu> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts +09:46 < geertu> pinmux = <PIN_PD21__TWD0> vs <PIN_PD21__GPIO> +09:47 < geertu> Do we need support for function = "gpio" in sh-pfc? +09:47 < wsa> marex: and this doesn't work for us +09:47 < geertu> Or teach the pinctrl core to do function -> gpio setup? +09:47 < marex> wsa: why ? +09:47 < geertu> The core already knows how to do the reverse +09:48 < wsa> marex: because we don't have 'function = "gpio"' +09:48 < marex> ah +09:49 < marex> wsa: shouldn't we ? +09:49 < geertu> Having it in the core means that we don't have to describe a second pinctrl state in DT +09:49 < geertu> The latter is basically superfluous, as the kernel already knows the mapping +09:49 < wsa> marex: this is what we are discussing now :) +09:50 < marex> wsa: it would make the behavior in-line with the other platforms at least +09:50 < wsa> geertu: but not all pins can be switched to a GPIO, won't that make it more difficult? +09:51 < wsa> Like IIC0 can't be switched to GPIO on Gen3 +09:51 < geertu> wsa: function would return -EINVAL? +09:51 < damm> may i propose that in case a user tries to swith a non-valid function to GPIO then instead of returning error we can just return a random GPIO? =) +09:52 < geertu> If the pin can't switch to GPIO, that can't be described in DT neither +09:52 < marex> geertu: it can, you can write invalid DT, but then -EINVAL is the way to go +09:53 < geertu> wsa: So all of that patch series has already been applied? Doh, just wanted to reply the kernel already knows the ampping... +09:53 < wsa> geertu: so, what would you suggest? pinctrl_unset_stete() will bring back GPIO? +09:53 * geertu kicks marex and damm +09:54 < wsa> damm: it should return the CAN connection to your car +09:54 < marex> wsa: well that sounds like a hack :) +09:54 < marex> (unset_state -> gpio) +09:55 < geertu> wsa: Hmm. The extra pinctrl state is superfluous, IMHO, but you still need to know which of the 2 GPIOs is SCL and which is SDA +09:55 < marex> geertu: for that you have the {scl,sda}-gpios in the DT ? +09:55 < geertu> For PWM it's simpler: just one pin ;-) +09:56 < geertu> marex: yes +09:56 < marex> but not for the pinmux if it's separate, hah +09:56 < wsa> geertu: that binding is also still needed to stay generic. you could have two other gpios wired to the bus just for recovery +09:56 < geertu> wsa: Good point. +09:56 < geertu> So sh-pfc needs support for 'function = "gpio"' it is? +09:57 < damm> this reminds me of uart flow control signals as gpio? +09:57 < damm> and the software gpio cs for msiof +09:57 < wsa> damm: and the zero-duty-cycle-GPIO for PWM +09:57 < geertu> Now, how does rwquest_gpio() work if the pin is considered busy by pinctrl? +09:58 < geertu> s/rwquest/requst/ +09:58 < wsa> -EBUSY +09:58 < geertu> Indeed, so does it really work? +09:59 < wsa> That's what I got when I tried the GPIO bus recovery with IIC on Lager +09:59 < geertu> So you have to undo the pinctrl state manually, and request the GPIO afterwards? No pinctrl-1 needed? +10:00 < wsa> that could work +10:00 < geertu> Later, unrequest GPIO + pinctrl enable again? +10:00 < wsa> this is what I meant above with "pinctrl_unset_state()" +10:00 < geertu> How does it work for the other people? No -EBUSY? +10:01 < wsa> they switch the state to GPIO +10:02 < geertu> Yeah, but the pin is still busy, according to pinctrl? Or they don't track busy/idle state? +10:03 < geertu> The pinctrl driver treats PIN_PD21__TWD0 vs PIN_PD21__GPIO the same, i.e. just as a value to write to a register +10:03 < geertu> cfr. RZ/A1 and RZ/A2 +10:03 < geertu> wsa: Tried your genmai? +10:04 < wsa> jmondi has the Genmai meanwhile +10:04 < jmondi> wsa: do I ? :) +10:04 < geertu> Or the peach ;) +10:04 < jmondi> didn't I give it back to you ? I'll check +10:04 < wsa> jmondi: I hope so! :D +10:04 < geertu> Remote genmai @ Magnus? +10:05 < jmondi> geertu: I use the peach for RZ/A1 +10:05 < jmondi> do you guys need any testing ? +10:05 < damm> i can probably find such a board somewhere +10:05 < geertu> Anyway, we're running late, violating MM space +10:05 < geertu> Let's take it to the ML? +10:05 < geertu> Anything else to discuss? +10:05 < wsa> jmondi: did you? If not, it would be nice to get it back because it is interesting for i2c slave development +10:06 < wsa> geertu: ack, let's take it to ML +10:07 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20200903-io-chatlog b/wiki/Chat_log/20200903-io-chatlog new file mode 100644 index 0000000..8d4e6a7 --- /dev/null +++ b/wiki/Chat_log/20200903-io-chatlog @@ -0,0 +1,175 @@ +<wsa> welcome everyone, hope you are fine +<wsa> here are the collected status updates +<wsa> Status updates +<wsa> ============== +<wsa> A - what have I done since last time +<wsa> ------------------------------------ +<wsa> Geert +<wsa> : did regression tests for SCIF with SH4 based hardware, fixed a few + other issues on the way, tested suspend/resume with PCIe and + investigated the problems, reposted RSPI bit rate improvements, posted + v3 of generic bindings for Ethernet MAC explicit internal delay setting, + implemented by RAVB, posted a revert for linkwatch after some more + investigation +<wsa> Niklas +<wsa> : unsuccessfully tested SDIO WiFi with Koelsch on Gen2. Probably because + of a too long cable. He will try a shorter one. +<wsa> Shimoda-san +<wsa> : sent a patch fixing the suspend handling of the USB serial gadget, + reviewed and tested Wolfram's SDHI patches about the stalled SCC and the + reset refactoring and the card reset after IP reset, also reviewed lots + of bindings for r8a774...- SoCs as well as USB bindings +<wsa> Ulrich +<wsa> : sent "watchdog: da9063: wake up parent ahead of reboot" to enable late + atomic transfers with IIC [16:01] +<wsa> Wolfram +<wsa> : refactored SDHI driver to use 'reset' and 'hw_reset' as intended by + the MMC subsystem, sent out a fix to reset the card after the IP core + was reset (needs follow up), finally was able to reproduce and inject + the stalled SCC case, reworked series 'fix stalled SCC' and 'implement + manual calibration' for SDHI and sent out, tried to add bus recovery to + the IIC module based on +<wsa> generic pinctrl bus recovery, refactored timeout handling in the I2C + driver, both for bus recovery and when resetting the IP core, sent patch + to correctly handle FNA bit of the I2C module, updated i2ctransfer to + support I2C_M_RECV_LEN, sent minor fixes along the way all over the + place +<wsa> B - what I want to do until next time +<wsa> ------------------------------------- +<wsa> Shimoda-san +<wsa> : wants to convert rcar-pci dt doc to json-schema, and ping the serial + gadget patch I have submitted +<wsa> Ulrich +<wsa> : wants to address feedback for "watchdog: da9063: wake up parent ahead + of reboot", and implement atomic transfers for i2c-rcar +<wsa> Wolfram +<wsa> : wants to upstream SMBus emulation binding, core HostNotify support, + and R-Car support for HostNotify, upstream I2C slave testunit, guide the + increase of I2C_M_RECV_LEN length to 255 and upstream R-Car support for + it +<wsa> C - problems I currently have +<wsa> ----------------------------- +<wsa> Geert +<wsa> : wonders how to avoid PCIe s2ram crash on R-Car Gen2 +<wsa> Wolfram +<wsa> : found out that adding bus recovery to IIC not possible at the moment + because we cannot switch to/from GPIO state using + pinctrl_set_state(). Might be a task for the core group because PWM + could use it, too, for zero duty-cycles. However, for IIC it is low + priority because bus recovery is mostly useful on Gen2. Another issue is + that there is no response from Rob about the SMBus emulation binding +<wsa> If you have questions or comments, please fire away +<wsa> I'll start with asking geertu a one-line summary for the PCIe crash? Is + there something in the s2ram which gets lost during suspend? [16:02] +<marex> I was about to ask the same +<geertu> wsa: marex: It's the same issue as on R-Car Gen3. +<geertu> But on arm64, it was fixed in ATF (by marex-san) +<marex> geertu: thats on RZ then ? +<geertu> marex: No, R-Car Gen2 (koelsch). But RZ/G1 should be affected, too. + [16:03] +<marex> ah sigh +<geertu> + https://github.com/ARM-software/arm-trusted-firmware/commit/0969397f295621aa26b3d14b76dd397d22be58bf + [16:04] +<geertu> On arm32, we need to hook up something into the exception handling in + Linux? +<marex> geertu: so is linux able to get the fault and fix it up ? +<geertu> marex: Currently not [16:05] +<marex> geertu: I suspect you might just need to do as iMX6 does +<marex> geertu: that one did generate some faults when PCIe went nuts too +<marex> geertu: and there both U-Boot and Linux hooked the fault handler +<wsa> geertu: what is missing for Linux? [16:06] +<marex> wsa: the same workaround as in TFA apparently +<geertu> marex: Sounds like a good job for the PCI DRIVER FOR RENESAS R-CAR + maintainer? ;-) +<marex> wsa: except implemented via the fault hooks [16:07] +<marex> wsa: that is , IFF , the gen2 generates such a fault instead of + locking up +<marex> needs to be checked +<geertu> marex: It generates such a fault +<wsa> ok, that's sounds doable? I understood Geert's comment that way that + Linux is missing some prerequisite to handle it [16:08] +<marex> wsa: nope +<wsa> So, on Gen3, why did we chose the ATF way instead of pure Linux? +<marex> wsa: the stuff should be all there +<marex> wsa: because on Gen3, you get a fault in EL3 [16:09] +<geertu> Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 +<wsa> ok +<geertu> (that line is from M2-W) +<marex> geertu: hold on, I need some coffee first +<wsa> ok, I'll wait for Marex to get some coffee and _then_ ask him if he is + interested in tackling it ;) [16:11] +<wsa> shimoda: thanks for the quick testing of my SDHI patches +<wsa> I really hope we have no more stalled SCC problems anymore +<shimoda> wsa: you're welcome! i'll review manual calib patches later [16:12] +<wsa> Though, the fact that it stalled when switching the divider was + interesting, but as said, I don't fully get it from the documentation I + have +<wsa> shimoda: Awesome, thanks! [16:13] +<marex> geertu: drivers/pci/controller/dwc/pci-imx6.c +<marex> 1300 hook_fault_code(8, imx6q_pcie_abort_handler, SIGBUS, 0, +<marex> 1301 "external abort on non-linefetch"); +<marex> look ^ +<marex> so we'll need similar "workaround" +<wsa> geertu: the 77961-io todo mentions adding cmt and sh-msiof. Is there a + chance to get this added via remote access? Didn't damm have some SPI + device to connect or am I remembering wrong? [16:15] +<geertu> wsa: No SPI devices, AFAIK +<wsa> uli___: seems that Guenter missed that there is no RPM that late, or? +<wsa> geertu: ah, okay. well, you would have known if there are any ;) [16:16] +<damm> i don't mind hooking up stuff if needed +<geertu> wsa: I think he doesn't know much about RPM in general +<uli___> wsa: just needs a little explaining, I guess [16:17] +<wsa> damm: that's great! next one will be the CAN devices ;) +<geertu> damm: Perhaps just a wire? Then we can do SPI loopback tests +<wsa> damm: so, get your car close to the lab +<damm> great! I need an extension cable to be able to reach all the way to the + car =) +<wsa> :) +<damm> send me an email with details please [16:18] +<damm> if you do it today EU time then I can finish it this week +<damm> otherwise it will have to wait for a couple of weeks +<wsa> magnus is going to okinawa? [16:19] +<damm> just leaving the remote access location for a while [16:20] +<marex> damm: would you still be able to reinstate and/or install ssh keys ? +<damm> yeah that i can do remotely +<geertu> marex: As you're mostly familiar with the PCIe issue, can you please + handle it? +<damm> cables are more difficult =) +<wsa> marex: that would be great, in deed [16:21] +<marex> yeah +<wsa> awesome, thanks! [16:22] +<wsa> this is all from my side, any question left? +<wsa> not the case [16:23] +<wsa> geertu: ready for core? +<geertu> wsa: But but... it's not yet hh:30? +<wsa> IO group is in HS400 mode [16:24] +<geertu> please retune now ;-) +<wsa> uh oh [16:25] +<moriperi> wsa: 1 thing from me +<marex> geertu: downshift to MMC52 is hard, dont torture them +<wsa> geertu triggerd a halted system again, great! ;) +<wsa> moriperi: what is it? +<moriperi> Now BSP team is tring to enable I2C on V3U board, but has timeout + error. +<moriperi> But, it started works if some delay was added, they said. [16:26] +<moriperi> 1 concern is that V3U is *almost* same as previous SoC, but in my + understanding, previous SoC needed some workaround. +<moriperi> If V3U was fixed around I2C, workaround might be not needed + anymore. +<moriperi> Now BSP team is investigating / confirming. +<moriperi> So nothing to do today, but just information for you. +<wsa> OK +<moriperi> We will ask something to you if V3U board was ready +<moriperi> that's all from me, thanks [16:27] +<wsa> I'll just wait +<wsa> I can't recall any workaround or additional delay from the top of my + head, but we will see... +<marex> real shame there's no OSSJ this year, we could've done V3U peripericon + and bring it all up +<geertu> marex: virtual peripericon? [16:28] +<geertu> Time to launch core? +<marex> geertu: someone would have to write a qemulation of v3u +<marex> oh ... +<wsa> can't we go to Japan just for V3U bringup +<wsa> :) diff --git a/wiki/Chat_log/20200903-mm-chatlog b/wiki/Chat_log/20200903-mm-chatlog new file mode 100644 index 0000000..13a4f02 --- /dev/null +++ b/wiki/Chat_log/20200903-mm-chatlog @@ -0,0 +1,255 @@ +<pinchartl> welcome to the multimedia group meeting +<jmondi> pinchartl: hello [17:05] +<pinchartl> Topic 1. Status Check for the Multimedia Tasks +<pinchartl> * Jacopo +<pinchartl> Since last meeting: +<pinchartl> - Linux Plumbers Conference +<pinchartl> - DT bindings image sensor conversion +<pinchartl> Converted mt9v111, imx214, ov5670 and ov772x +<pinchartl> - max9286 format configuration +<pinchartl> To prepare for upstreaming support for RDACM21, the max9286 driver +<pinchartl> has to be adapted to support different receivers. +<pinchartl> [PATCH 0/4] media: i2c: max9286: Use remote endpoint image format +<pinchartl> The series was not exactly apreciated, so a different solution is +<pinchartl> required. +<pinchartl> - Patch review +<pinchartl> Reviewed Prabhakar'd ov772x and ov5640 patches for Renesas G1H dev +<pinchartl> boards. +<pinchartl> Until next meeting: +<pinchartl> - Re-think how to handle formats for max9286 +<pinchartl> - Resume GMSL reverse channel configuration discussion +<pinchartl> - Re-send dt-bindings now that we have clarified how to handle +<pinchartl> endpoints +<pinchartl> Issues and blockers: None +<pinchartl> jmondi: you can go first :-) any comment ? +<jmondi> not really, I think I need to re-look at format handlin on max9286 + [17:06] +<jmondi> but no comment on the current status update thanks +<pinchartl> ok, thanks +<pinchartl> regarding format handling, would you like to discuss during this + meeting, or do you need to look at it first ? [17:07] +<jmondi> pinchartl: if we have 5 minutes at the end, let's discuss it +<pinchartl> ok, I'll add it to the discussion points +<jmondi> it shouldn't be long after all, I just need to convince you and + Sakari... it's gonna be like 5 minutes, right ? =) [17:08] +<pinchartl> * Kieran +<pinchartl> Since last meeting: +<pinchartl> - Linux Plumbers Conference +<pinchartl> - Patch review +<pinchartl> - GMSL reviews/fixups +<pinchartl> - ADV748x audio input +<pinchartl> Failed to successfully capture anything. Responded to author, not + sure +<pinchartl> if the test procedure is wrong or if the problem lies elsewhere. +<pinchartl> Until next meeting: +<pinchartl> - Aim to finish/resolve the ADV748x audio tests +<pinchartl> - Work towards DT integration/overlays for GMSL +<pinchartl> - Look at V4L2 Multiplex streams topics for GMSL +<pinchartl> Issues and blockers: None +<pinchartl> Kieran asked to be excused as he's stuck babysitting today +<pinchartl> * Laurent +<pinchartl> Since last meeting: +<pinchartl> - Linux Plumbers Conference +<pinchartl> Participated (among other topics) in the dmabuf heaps and + userspace +<pinchartl> buffer allocation library discussions. +<pinchartl> - DISCOM CRC calculation tool +<pinchartl> Implemented a tool to calculate the CRC of an image using the same +<pinchartl> algorithm as the DISCOM, and integrated it in the DU test + suite. This +<pinchartl> exposed a crash in the DU driver, developed and posted a fix. +<pinchartl> - V4L2 async subdev allocation fixes +<pinchartl> Posted fixes for V4L2 async subdev allocation in the various + Renesas +<pinchartl> V4L2 drivers. The fix for VIN has been superseded by patches from +<pinchartl> Niklas. The fix for DRIF is pending testing from the Renesas UK + team. [17:09] +<pinchartl> - Patch review +<pinchartl> Among other things, Renesas UK has provided the schematics for the + iWave +<pinchartl> board, which unblocked review of the DT integration. +<pinchartl> Until next meeting: +<pinchartl> - Follow-up on pending patch series +<pinchartl> Get pending patches merged, pinging maintainers where needed. +<pinchartl> - Help with debugging the DU + CMM suspend/resume crash if needed +<pinchartl> - Move forward with the V4L2 multiplexed streams proposal +<pinchartl> Issues and Blockers: None +<pinchartl> any question ? +<moriperi> Thank you for DISCOM tool +<pinchartl> you're welcome [17:10] +<pinchartl> * Morimoto-san +<pinchartl> Since last meeting: +<pinchartl> - Post Renesas menu Kconfig patch +<pinchartl> v3 may be needed. +<pinchartl> - Continue posting ALSA SoC cleanup patches +<pinchartl> - Complex connection handling in ALSA SoC +<pinchartl> Current ALSA SoC has 2 generic sound card (= glue for SoC / Codec) +<pinchartl> driver, and one of them is for OF-graph. Current ALSA SoC + maintainer is +<pinchartl> recommending to use it. But unfortunately, it can't handle complex +<pinchartl> connection for now. But in these days, at least 2 vendors want to + use +<pinchartl> complex connections by using this generic driver. One of them has + posted +<pinchartl> *hack* patches. Thus I started to think about *non-hack* expansion + for +<pinchartl> it. +<pinchartl> Until next meeting: +<pinchartl> - Create dummy test driver to develop complex connection handling +<pinchartl> - Continue posting ALSA SoC cleanup patches +<pinchartl> Issues and Blockers: None +<pinchartl> moriperi: any comment ? +<moriperi> thanks. no comment, but have question. later this. [17:11] +<pinchartl> ok +<pinchartl> * Niklas +<pinchartl> Since last meeting: +<pinchartl> - [PATCH 0/2] v4l: async: Switch to endpoint node matching +<pinchartl> - [PATCH 0/2] rcar-vin: Fix issues with partial probed media + graphs +<pinchartl> - Summer vacation, back in office Monday the 7th +<pinchartl> Until next meeting: +<pinchartl> - Post second round of improvements for VIN and V4L2 lifetime + issues +<pinchartl> - Backlog cleaning +<pinchartl> Issues and blockers: None +<pinchartl> Niklas asked to be excuse as he's travelling back to Germany +<pinchartl> Topic 2. Discussions +<pinchartl> moriperi: you said you have a question for later. I think later + could be now :-) [17:12] +<moriperi> jacopo first is oK +<pinchartl> ok :-) +<pinchartl> MAX9286 format handlign then +<pinchartl> jmondi: ? +<jmondi> yup [17:13] +<jmondi> well, I think the deser should reflect the remote's format, you and + Sakari think not +<jmondi> I think it boils down to that, right ? :) +<pinchartl> pretty much :-) [17:14] +<pinchartl> the design idea behind MC drivers is that format propagation + should be handled by userspace +<pinchartl> for multiplexed streams, we may do otherwise +<pinchartl> but the GMSL link isn't multiplexed, it carries a single stream + [17:15] +<jmondi> I don't see it being related to multiplexed, but more specifically on + what the de-serializer does +<jmondi> you can say it's not different from any other bridge + $protocol-to-csi2 +<pinchartl> correct [17:16] +<jmondi> I see +<pinchartl> and if you look at a parallel to CSI-2 chips, they don't fetch the + remote format on the parallel sink +<pinchartl> userspace propagates the format on the parallel side +<jmondi> and indeed format can be set on the sink pads +<jmondi> so it's maybe better handled by updating the vin-test scripts [17:17] +<jmondi> parsing the remote format and apply it on the deser sink pads +<pinchartl> media-ctl will do it for you [17:18] +<pinchartl> if you set the format on a source pad that has a connected link, + it will automatically set it on the remote sink pad +<jmondi> across links ? [17:19] +<jmondi> I never noticed that :/ +<pinchartl> yes, across links +<jmondi> good to know, now I should check why it doesn't happen then +<jmondi> anyway, let's defer to userspace +<pinchartl> ok [17:20] +<jmondi> thanks, moriperi please go ahead then +<pinchartl> another discussion point, DU + CMM suspend/resume crash +<jmondi> ah +<jmondi> I'm at "please rest (for now)" [17:21] +<pinchartl> moriperi: you mentioned in an e-mail that you would check with the + customer whether we need to look into this +<jmondi> any update ? +<pinchartl> do you have any update on that ? +<moriperi> no update if my memroy was correct [17:22] +<pinchartl> should we still wait ? I'd like to raise the issue with the PM + core developers, as I think the problem would be fixed if they + didn't forcefully PM-runtime-resume devices needlessly at system + suspend +<geertu> The person from Renesas EU who contacted me regards this issue, had + told me he pinged Eugeniu. [17:24] +<geertu> But so far no response from Eugeniu, AFAIK +<pinchartl> I propose initiating the PM discussion, as these matters may take + time +<moriperi> I don't remember detail, but DU also has bind/unbind issue ? + [17:25] +<pinchartl> is that a separate issue ? +<moriperi> oops ? please ignore, my fault maybe [17:26] +<pinchartl> it could just be me misremembering it :-) +<pinchartl> jmondi: does it ring a bell ? [17:27] +<jmondi> bind/unbind not really :( [17:28] +<moriperi> So is it my turn ? +<pinchartl> yes :-) +<jmondi> moriperi: please go ahead! +<moriperi> Thanks +<moriperi> About OF-graph +<moriperi> I know we can use "ports" for "port" groups +<moriperi> ports - port - endpoint +<moriperi> port - endpoint +<moriperi> ... +<moriperi> But now, I want to have sub-groups, like this +<moriperi> ports - port - endpoint +<moriperi> - port - endpoint +<moriperi> +<moriperi> - ports - port - endpoint <= [17:29] +<moriperi> - port - endpoint <= +<moriperi> I think OF-graph doesn't support it, right ? +<pinchartl> correct +<moriperi> Do you know someone who has same issue/idea ? +<pinchartl> not really, no +<pinchartl> what do you want to use that for ? +<moriperi> now I nama it as port3, port4. +<moriperi> s/nama/name [17:30] +<moriperi> port3, and port4 are separate device, but want to use in the same + time as same interface +<moriperi> thus we want to group [17:31] +<pinchartl> I don't know of anyone who would have tried to do that +<pinchartl> maybe the best option would be to post an RFC to explain the + problem and the proposed solution ? +<pinchartl> it would be helpful if it explained the hardware architecture and + gave a corresponding DT example [17:32] +<moriperi> Yes maybe. Or I already have other idea. but in that, the graph + will be very huge :( +<moriperi> but it is ok for now, not a big-deal. thanks [17:33] +<moriperi> pinchartl: ahhh, about bind/unbind, it was for VIN, not for DU + [17:34] +<pinchartl> you're welcome. I'd be happy to help if I can, please just let me + know :-) +<moriperi> sorry for my noise +<pinchartl> yes, for VIN we clearly had issues +<pinchartl> no worries +<pinchartl> any other discussion point for today ? +<moriperi> not from me [17:35] +<jmondi> pinchartl: one last thing +<jmondi> i2c sensor yaml :) (I know..) +<wsa> next meeting on October, 1st? +<jmondi> we decided to defer to of-graph.yaml ports/endpoint/remote-endpoint +<jmondi> but what if I have endpoint properties to document ? +<pinchartl> in that case you should have the endpoints in your bindings + [17:36] +<pinchartl> it's only for the case where nothing else needs to be documented + that you can drop them +<pinchartl> basically, of-graph.yaml will take care of the schema for + ports/port/endpoint/remote-endpoint [17:37] +<pinchartl> so it doesn't have to be duplicated everywhere +<pinchartl> but the rest needs to be handled manually +<pinchartl> any question still about this ? [17:39] +<jmondi> on +<jmondi> no +<jmondi> just wanted to make sure so next iteration is ok +<jmondi> thanks for the answer +<pinchartl> you're welcome [17:41] +<pinchartl> any other discussion topic ? +<wsa> next meeting on October, 1st? +<pinchartl> :-) +<pinchartl> works for me +<geertu> #metoo [17:42] +<shimoda> works for me +<pinchartl> I propose adjourning the multimedia meeting +<pinchartl> does anyone second ? +<wsa> good, then it is decided [17:43] +<geertu> third? +<jmondi> seconded! [17:44] +<pinchartl> meeting adjourned. thank you all for attending [17:45] +<pinchartl> have a nice day +<jmondi> thank you all +<damm> thanks guys [17:46] +<shimoda> thanks! [17:47] |