summaryrefslogtreecommitdiff
path: root/projects/linux
diff options
context:
space:
mode:
Diffstat (limited to 'projects/linux')
-rw-r--r--projects/linux/io/BSP41-need-KF-patches.yaml6
-rw-r--r--projects/linux/io/BSP41-upport-unsorted-patches.yaml2
-rw-r--r--projects/linux/io/SDHI-refactor-SDHn.yaml1
-rw-r--r--projects/linux/io/SDHI-refactor-abort-tuning.yaml5
-rw-r--r--projects/linux/io/V3U-enable_CAN.yaml5
-rw-r--r--projects/linux/io/V3U-enable_PWM.yaml21
-rw-r--r--projects/linux/io/V3U-enable_RPC.yaml13
-rw-r--r--projects/linux/io/V3U-enable_TPU.yaml (renamed from projects/linux/io/V3U-enable_TPU_PWM.yaml)14
8 files changed, 60 insertions, 7 deletions
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_PWM.yaml b/projects/linux/io/V3U-enable_TPU.yaml
index b5ad45e..0c2cd99 100644
--- a/projects/linux/io/V3U-enable_TPU_PWM.yaml
+++ b/projects/linux/io/V3U-enable_TPU.yaml
@@ -1,4 +1,4 @@
-title: V3U; upport TPU and PWM fixes and enable for V3U
+title: V3U; upport TPU fixes and enable for V3U
team: IO
key: 5b2c3266-a43a-11eb-8741-bb50e7fa7f92
status: Active
@@ -8,22 +8,20 @@ bsp41x:
- 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:
+ - 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
- - 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=*
+ - 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/
@@ -32,7 +30,9 @@ comments:
- c81a1645d1363e371a5a9df8f5b7fe211e195075
- should be changed to M
- v1; https://lore.kernel.org/r/20210915153143.25184-1-wsa+renesas@sang-engineering.com
- - e3552b314c8c27c57868f38f257ea1a0a0cf66ee, e9369406a0e148ddf941519ad7c4f54e4c8bdaec
+ - 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