From da3bd413869d2f1111e086733676e46d49f842b2 Mon Sep 17 00:00:00 2001 From: Wolfram Sang Date: Thu, 7 Oct 2021 09:58:01 +0200 Subject: projects: linux: io: update tasks after meeting 20211007 Signed-off-by: Wolfram Sang --- projects/linux/io/BSP41-need-KF-patches.yaml | 6 ++++ .../linux/io/BSP41-upport-unsorted-patches.yaml | 2 ++ projects/linux/io/SDHI-refactor-SDHn.yaml | 1 + projects/linux/io/SDHI-refactor-abort-tuning.yaml | 5 +++ projects/linux/io/V3U-enable_CAN.yaml | 5 +++ projects/linux/io/V3U-enable_PWM.yaml | 21 ++++++++++++ projects/linux/io/V3U-enable_RPC.yaml | 13 ++++++++ projects/linux/io/V3U-enable_TPU.yaml | 38 ++++++++++++++++++++++ projects/linux/io/V3U-enable_TPU_PWM.yaml | 38 ---------------------- 9 files changed, 91 insertions(+), 38 deletions(-) create mode 100644 projects/linux/io/V3U-enable_PWM.yaml create mode 100644 projects/linux/io/V3U-enable_TPU.yaml delete mode 100644 projects/linux/io/V3U-enable_TPU_PWM.yaml (limited to 'projects/linux') diff --git a/projects/linux/io/BSP41-need-KF-patches.yaml b/projects/linux/io/BSP41-need-KF-patches.yaml index 000a5de..137a78a 100644 --- a/projects/linux/io/BSP41-need-KF-patches.yaml +++ b/projects/linux/io/BSP41-need-KF-patches.yaml @@ -14,7 +14,13 @@ bsp41x: - a6c6f67592709f9c1e5cdc79ff29fb583afb362e # IIO: lsm9ds0: add IMU driver upstream: + - torvalds: 6731ca3999ffa4c878a661b980759300dfb0237e # iio: st_sensors: Add lsm9ds0 IMU support comments: - only Laurent has a KF board currently which is not available with remote access. - most patches here need physical access, though + + - a6c6f67592709f9c1e5cdc79ff29fb583afb362e + - another driver went upstream meanwhile with accelerometer and magnetometer + - angular rate sensor might be missing, need to check + - also need to check if this is needed diff --git a/projects/linux/io/BSP41-upport-unsorted-patches.yaml b/projects/linux/io/BSP41-upport-unsorted-patches.yaml index 688820e..16cc8f0 100644 --- a/projects/linux/io/BSP41-upport-unsorted-patches.yaml +++ b/projects/linux/io/BSP41-upport-unsorted-patches.yaml @@ -12,6 +12,7 @@ bsp41x: upstream: - torvalds: 2ea2e019c190ee3973ef7bcaf829d8762e56e635 # serial: sh-sci: Fix off-by-one error in FIFO threshold register setting + - next: e7f4264821a4ee07775f3775f8530cfa9a6d4b5d # i2c: rcar: enable interrupts before starting transfer comments: - 86293fe9951d83eb6db6be8db54d5ff88bf89cab: @@ -20,6 +21,7 @@ comments: - the added comment does not really add additional information IMHO - the fix when to write ICMIER is correct and will be further tested and upstreamed - v1; https://lore.kernel.org/r/20210915134827.13043-1-wsa+renesas@sang-engineering.com + - merged - b6dde4a58f547e0c52ff4c797b9d378419833eb7: - double check and upport - f3670a6aa2bd5f47d79fb0360c0a7a3eb629d1a0: diff --git a/projects/linux/io/SDHI-refactor-SDHn.yaml b/projects/linux/io/SDHI-refactor-SDHn.yaml index 874c601..8d8f337 100644 --- a/projects/linux/io/SDHI-refactor-SDHn.yaml +++ b/projects/linux/io/SDHI-refactor-SDHn.yaml @@ -16,3 +16,4 @@ comments: - "BSP will use a workaround, but we should model SDHn as a seperate clock" - "This allows us to handle proper frequency settings from the SDHI driver" - "Wolfram has a sketch with two clocks using generic divider and gate combined" + - "rfc v1: https://lore.kernel.org/r/20210928200804.50922-1-wsa+renesas@sang-engineering.com" diff --git a/projects/linux/io/SDHI-refactor-abort-tuning.yaml b/projects/linux/io/SDHI-refactor-abort-tuning.yaml index 9dc26cc..9cc71ed 100644 --- a/projects/linux/io/SDHI-refactor-abort-tuning.yaml +++ b/projects/linux/io/SDHI-refactor-abort-tuning.yaml @@ -9,3 +9,8 @@ upstream: comments: - details at lore.kernel.org/all/20210831133349.18203-1-wsa+renesas@sang-engineering.com/ - v1; https://lore.kernel.org/r/20210914182023.8103-1-wsa+renesas@sang-engineering.com + - upstream review hinted that this might be only a workaround + - one alternative found by Wolfram is to delay 100ms after the cmd error + - for Wolfram's setup, the issue only happens with 4tap devices and a SanDisk card + - another alternative seems to use the 1:4 divider instead of the 2:2 + - needs further investigation diff --git a/projects/linux/io/V3U-enable_CAN.yaml b/projects/linux/io/V3U-enable_CAN.yaml index cc0d9d6..647237e 100644 --- a/projects/linux/io/V3U-enable_CAN.yaml +++ b/projects/linux/io/V3U-enable_CAN.yaml @@ -19,3 +19,8 @@ comments: - regmap conversion could be tested on Gen3 locally and on V3U by Renesas in Japan - waiting for budget - Ulrich was contracted + - Ulrich found out that regmap is not suitable but the macros from the BSP can be greatly simplified + - 745cdc4ea76af480cb9c4a47f78a580e08ed03b6, 236a7d2185b21c46064ccf6ece8905ddda16d5e7: + - v1; https://lore.kernel.org/r/20210924153113.10046-1-uli+renesas@fpond.eu + - Renesas Japan cannot test these changes, we have to find our own way + - discussing with Kieran and Ulrich how to accomplish this diff --git a/projects/linux/io/V3U-enable_PWM.yaml b/projects/linux/io/V3U-enable_PWM.yaml new file mode 100644 index 0000000..3489c64 --- /dev/null +++ b/projects/linux/io/V3U-enable_PWM.yaml @@ -0,0 +1,21 @@ +title: V3U; upport PWM fixes and enable for V3U +team: IO +key: 73d99160-2805-11ec-8a83-ab141cfec33e +status: Paused + +bsp41x: + - d9dbda2f774c38dd60f3b17b7e3dac11bb0e3a97 # dt-bindings: pwm: Add R-Car V3U device tree bindings + - 73d8a0fb46ab4f822f953ad20e5fbdb5998352c1 # pwm: rcar: Add a judgment of the period out of range + - 91284dd61b7c36fe536d8ad6c473bbc04b4328da # arm64: dts: renesas: r8a779a0: Add PWM nodes + - e9369406a0e148ddf941519ad7c4f54e4c8bdaec # arm64: dts: salvator-common: Enable PWM2 + +upstream: + +comments: + - testing PWM is currently unclear; BSP also doesn't have PWM on Falcon + - the idea was to use the GPIO logic analyzer with sniffing the GPIO input register + - however, unlike other Gen3 SoCs the V3U doesn't allow GPIO sniffing by default + - asking HW team if this can be achieved somehow + + - e9369406a0e148ddf941519ad7c4f54e4c8bdaec + - won't be upported because there are no users on the boards diff --git a/projects/linux/io/V3U-enable_RPC.yaml b/projects/linux/io/V3U-enable_RPC.yaml index 01d467b..653df63 100644 --- a/projects/linux/io/V3U-enable_RPC.yaml +++ b/projects/linux/io/V3U-enable_RPC.yaml @@ -15,6 +15,8 @@ bsp41x: - 44c210c0fa36a53c3fb08e95e5a6dad8ad9b345d # arm64: dts: renesas: falcon: Add QSPI flash support upstream: + - next: fff53a551db50f5edecaa0b29a64056ab8d2bbca # memory: renesas-rpc-if: Correct QSPI data transfer in Manual mode + - next: 797f082738b10ff397c8d3b7804b747d766e62e6 # dt-bindings: rpc: renesas-rpc-if: Add support for the R8A779A0 RPC-IF comments: - because HW access to V3U is still very limited, it is suggested to upport/refactor the driver fixes using locally available boards first @@ -25,16 +27,27 @@ comments: - c419cfd7766efb7bbc95d964586ca3668b61cdb7 - not a bugfix, no need to upport now - needs more investigation if burst read support needs more driver updates + - will be refactored to seperate task - f817442ce56d351a2c69515570ca750edb54622b - needs more information why the undocumented bits were needed previously - further investigation showed that the patch is okay, but maybe one bitfield was accidently removed - asked BSP team for clarification + - Renesas Europe upstreamed G2L support providing additional information + - BSP team responded, all information complete now + - patch will be created on top of G2L support. We wait for the new version - 3612986e5109c4de99cd3f75caf5bf6c756ef0f0, 85f41a8a4d61f366d1591516349ba2447a59e06f - no action needed, they revert each other - 0d37f69cacb3343514380ff4a9c271b746959190 - must be upported before enabling V3U. Otherwise flash memory might get broken, i.e. wrongly fused - very likely must be refactored. The mixture of regmap and direct register writes does not look good - RFC v1 sent to an internal mailing list + - v1; https://lore.kernel.org/r/20210922091007.5516-1-wsa+renesas@sang-engineering.com + - merged - e05ce4b3ba724c77bd19f138476dc97d27eba824, 44c210c0fa36a53c3fb08e95e5a6dad8ad9b345d - upstream needs also to refactor RPC clock handling into CPG lib - rfc v1; https://lore.kernel.org/r/20210913065317.2297-1-wsa+renesas@sang-engineering.com + - v1; https://lore.kernel.org/r/20210929064924.1997-1-wsa+renesas@sang-engineering.com + - v2; https://lore.kernel.org/r/20211006085836.42155-1-wsa+renesas@sang-engineering.com + - b587ed1d5e129cc32ab3c69b9489377bf158b9b6 + - v1; https://lore.kernel.org/r/20210922085831.5375-1-wsa+renesas@sang-engineering.com + - merged diff --git a/projects/linux/io/V3U-enable_TPU.yaml b/projects/linux/io/V3U-enable_TPU.yaml new file mode 100644 index 0000000..0c2cd99 --- /dev/null +++ b/projects/linux/io/V3U-enable_TPU.yaml @@ -0,0 +1,38 @@ +title: V3U; upport TPU fixes and enable for V3U +team: IO +key: 5b2c3266-a43a-11eb-8741-bb50e7fa7f92 +status: Active + +bsp41x: + - 18d27c55780cd8ba5a8c08461d73d2162333d818 # pwm: pwm-renesas-tpu: Correct the valid period and duty_cycle + - 65256a77c7c66d338317b5405437e1125c625001 # pwm: tpu: Add a compatible string for r8a779a0 + - c81a1645d1363e371a5a9df8f5b7fe211e195075 # arm64: defconfig: Enable R-Car PWM-TPU by default + - 30f8711382c676d89bcf59f068e764134dbbcc91 # dt-bindings: pwm: tpu: Add R-Car V3U device tree bindings + - 87133703bb5a16ce4285a761ae3bd3f554b4cb45 # arm64: dts: renesas: r8a779a0: Add TPU node + - e3552b314c8c27c57868f38f257ea1a0a0cf66ee # arm64: dts: r8a779a0-falcon: Add TPU support + +upstream: + - next: bdd8b0053f4ff0df889bd849f0789580e9faea3a # arm64: dts: renesas: r8a779a0: Add TPU device node + - next: 3e9dd11db00119001a1d05413f51804a35559956 # arm64: defconfig: Add Renesas TPU as module + +comments: + - TPU can probably be tested using GPIO_CN with the GPIO logic analyzer + - TPU + - testing TPU with GPIO logic analyzer was successful + - 87133703bb5a16ce4285a761ae3bd3f554b4cb45 + - v1; https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=540427&state=* + - merged + - 30f8711382c676d89bcf59f068e764134dbbcc91 + - v1; https://lore.kernel.org/all/20210901090719.35375-1-wsa+renesas@sang-engineering.com/ + - fix m3-w+ while here; https://lore.kernel.org/all/20210906094536.45223-1-wsa+renesas@sang-engineering.com/ + - 65256a77c7c66d338317b5405437e1125c625001 + - not needed. We have the generic fallback + - c81a1645d1363e371a5a9df8f5b7fe211e195075 + - should be changed to M + - v1; https://lore.kernel.org/r/20210915153143.25184-1-wsa+renesas@sang-engineering.com + - merged + - e3552b314c8c27c57868f38f257ea1a0a0cf66ee + - won't be upported because there are no users on the boards + - 18d27c55780cd8ba5a8c08461d73d2162333d818 + - v1; https://lore.kernel.org/r/20210915065542.1897-1-wsa+renesas@sang-engineering.com + - got reviewed, needs refactorization diff --git a/projects/linux/io/V3U-enable_TPU_PWM.yaml b/projects/linux/io/V3U-enable_TPU_PWM.yaml deleted file mode 100644 index b5ad45e..0000000 --- a/projects/linux/io/V3U-enable_TPU_PWM.yaml +++ /dev/null @@ -1,38 +0,0 @@ -title: V3U; upport TPU and PWM fixes and enable for V3U -team: IO -key: 5b2c3266-a43a-11eb-8741-bb50e7fa7f92 -status: Active - -bsp41x: - - 18d27c55780cd8ba5a8c08461d73d2162333d818 # pwm: pwm-renesas-tpu: Correct the valid period and duty_cycle - - 65256a77c7c66d338317b5405437e1125c625001 # pwm: tpu: Add a compatible string for r8a779a0 - - c81a1645d1363e371a5a9df8f5b7fe211e195075 # arm64: defconfig: Enable R-Car PWM-TPU by default - - 30f8711382c676d89bcf59f068e764134dbbcc91 # dt-bindings: pwm: tpu: Add R-Car V3U device tree bindings - - d9dbda2f774c38dd60f3b17b7e3dac11bb0e3a97 # dt-bindings: pwm: Add R-Car V3U device tree bindings - - 87133703bb5a16ce4285a761ae3bd3f554b4cb45 # arm64: dts: renesas: r8a779a0: Add TPU node - - e3552b314c8c27c57868f38f257ea1a0a0cf66ee # arm64: dts: r8a779a0-falcon: Add TPU support - - 73d8a0fb46ab4f822f953ad20e5fbdb5998352c1 # pwm: rcar: Add a judgment of the period out of range - - 91284dd61b7c36fe536d8ad6c473bbc04b4328da # arm64: dts: renesas: r8a779a0: Add PWM nodes - - e9369406a0e148ddf941519ad7c4f54e4c8bdaec # arm64: dts: salvator-common: Enable PWM2 - -upstream: - -comments: - - TPU can probably be tested using GPIO_CN with the GPIO logic analyzer - - testing PWM is currently unclear; BSP also doesn't have PWM on Falcon - - TPU - - testing TPU with GPIO logic analyzer was successful - - 87133703bb5a16ce4285a761ae3bd3f554b4cb45 - - v1; https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=540427&state=* - - 30f8711382c676d89bcf59f068e764134dbbcc91 - - v1; https://lore.kernel.org/all/20210901090719.35375-1-wsa+renesas@sang-engineering.com/ - - fix m3-w+ while here; https://lore.kernel.org/all/20210906094536.45223-1-wsa+renesas@sang-engineering.com/ - - 65256a77c7c66d338317b5405437e1125c625001 - - not needed. We have the generic fallback - - c81a1645d1363e371a5a9df8f5b7fe211e195075 - - should be changed to M - - v1; https://lore.kernel.org/r/20210915153143.25184-1-wsa+renesas@sang-engineering.com - - e3552b314c8c27c57868f38f257ea1a0a0cf66ee, e9369406a0e148ddf941519ad7c4f54e4c8bdaec - - won't be upported because there are no users on the boards - - 18d27c55780cd8ba5a8c08461d73d2162333d818 - - v1; https://lore.kernel.org/r/20210915065542.1897-1-wsa+renesas@sang-engineering.com -- cgit v1.2.3