| Age | Commit message (Collapse) | Author |
|---|
|
spi-max-frequency was set to 75MHz, which actually gets you 50MHz on the
bus as verified with an oscilloscope.
At 50MHz, data transfers are flakey with some q7 connector savers.
Running a flashcp loop throws verify errors every now and then.
Reduce freq to 10MHz which is stable also with the q7 connector saver.
Note that this is needed *in addition* to the spi1 cs-gpios fix.
Relates-to: HWIT-490
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
|
|
Hardware CS has a very slow rise time of about 6us,
causing transmission errors when CS does not reach
high between transaction.
It looks like it's not driven actively when transitioning
from low to high but switched to input, so only the CPU
pull-up pulls it high, slowly. Transitions from high to low
are fast. On the oscilloscope, CS looks like an irregular sawtooth
pattern like this:
_____
^ / |
^ /| / |
/| / | / |
/ | / | / |
___/ |___/ |_____/ |___
With cs-gpios we have a CS rise time of about 20ns, as it should be,
and CS looks rectangular.
This fixes the data errors when running a flashcp loop against a
m25p40 spi flash.
With the Rockchip 6.1 kernel we see the same slow rise time, but
for some reason CS is always high for long enough to reach a solid
high.
The RK3399 and RK3588 SoCs use the same SPI driver, so we also
checked our "Puma" (RK3399) and "Tiger" (RK3588) boards.
They do not have this problem. Hardware CS rise time is good.
Fixes: c484cf93f61b ("arm64: dts: rockchip: add PX30-µQ7 (Ringneck) SoM with Haikou baseboard")
Cc: stable@vger.kernel.org
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/all/20250627131715.1074308-1-jakob.unterwurzacher@cherry.de/
[conflicts: our &pinctrl has sdio-pwrseq causing the hunk to fail.
spi1 block inserted after sdio-pwrseq]
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
|
|
Our Mass Flasher solution will require mounting an exFAT partition so
let's enable its support.
Relates-to: JAG-323
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
commit 5ae4dca718eacd0a56173a687a3736eb7e627c77 upstream.
UART controllers without flow control seem to behave unstable
in case DMA is enabled. The issues were indicated in the message:
https://lore.kernel.org/linux-arm-kernel/CAMdYzYpXtMocCtCpZLU_xuWmOp2Ja_v0Aj0e6YFNRA-yV7u14g@mail.gmail.com/
In case of PX30-uQ7 Ringneck SoM, it was noticed that after couple
of hours of UART communication, the CPU stall was occurring,
leading to the system becoming unresponsive.
After disabling the DMA, extensive UART communication tests for
up to two weeks were performed, and no issues were further
observed.
The flow control pins for uart5 are not available on PX30-uQ7
Ringneck, as configured by pinctrl-0, so the DMA nodes were
removed on SoM dtsi.
Cc: stable@vger.kernel.org
Fixes: c484cf93f61b ("arm64: dts: rockchip: add PX30-µQ7 (Ringneck) SoM with Haikou baseboard")
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Link: https://lore.kernel.org/r/20250121125604.3115235-3-lukasz.czechowski@thaumatec.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ conflict resolution due to missing (cosmetic) backport of
4eee627ea59304cdd66c5d4194ef13486a6c44fc]
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit bcc87e2e01637a90d67c66ce6c2eb28a78bf79f2)
[conflict with UART controllers for Eagle in git context]
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
Disable the CONFIG_RT_GROUP_SCHED config entry. It was enabled in
commit 24d447786b8c, with preparation for container support.
However, in latest versions of check-config.sh from:
https://raw.githubusercontent.com/moby/moby/master/contrib/check-config.sh,
the check for RT_GROUP_SCHED entry was removed, as it is not
recommended to have it enabled. See:
https://github.com/moby/moby/commit/005150ed69c540fb0b5323e0f2208608c1204536
With the RT_GROUP_SCHED option enabled, setting RT scheduling for
tasks in userspace was only possible when explicitly configuring
RT scheduling limits.
Fixes: 24d447786b8c ("TSD: arm64: configs: puma: enable options for container")
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
|
|
Disable the CONFIG_RT_GROUP_SCHED config entry. It was enabled in
commit 4025893213f4, with preparation for container support.
However, in latest versions of check-config.sh from:
https://raw.githubusercontent.com/moby/moby/master/contrib/check-config.sh,
the check for RT_GROUP_SCHED entry was removed, as it is not
recommended to have it enabled. See:
https://github.com/moby/moby/commit/005150ed69c540fb0b5323e0f2208608c1204536
With the RT_GROUP_SCHED option enabled, setting RT scheduling for
tasks in userspace was only possible when explicitly configuring
RT scheduling limits.
Fixes: 4025893213f4 ("TSD: arm64: configs: ringneck: enable options for container")
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
|
|
compressed firmware
At least the Ubuntu Noble (24.04) linux-firmware package uses zstd to compress
the firmware files.
Signed-off-by: Klaus Goger <klaus.goger@cherry.de>
|
|
During mass manufacturing, we noticed the mmc_rx_crc_error counter,
as reported by "ethtool -S eth0 | grep mmc_rx_crc_error", to increase
above zero during nuttcp speedtests. Most of the time, this did not
affect the achieved speed, but it prompted this investigation.
Cycling through the rx_delay range on six boards (see table below) of
various ages shows that there is a large good region from 0x12 to 0x35
where we see zero crc errors on all tested boards.
The old rx_delay value (0x10) seems to have always been on the edge for
the KSZ9031RNX that is usually placed on Puma.
Choose "rx_delay = 0x23" to put us smack in the middle of the good
region. This works fine as well with the KSZ9131RNX PHY that was used
for a small number of boards during the COVID chip shortages.
Board S/N PHY rx_delay good region
--------- --- --------------------
Puma TT0069903 KSZ9031RNX 0x11 0x35
Puma TT0157733 KSZ9031RNX 0x11 0x35
Puma TT0681551 KSZ9031RNX 0x12 0x37
Puma TT0681156 KSZ9031RNX 0x10 0x38
Puma 17496030079 KSZ9031RNX 0x10 0x37 (Puma v1.2 from 2017)
Puma TT0681720 KSZ9131RNX 0x02 0x39 (alternative PHY used in very few boards)
Intersection of good regions = 0x12 0x35
Middle of good region = 0x23
Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
Cc: stable@vger.kernel.org
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # Puma v2.1 and v2.3 with KSZ9031
Link: https://lore.kernel.org/r/20241213-puma_rx_delay-v4-1-8e8e11cc6ed7@cherry.de
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
Relates-to: PUMA-111
Relates-to: HWIT-348
|
|
on rk3399-puma"
This was v1 of the patch, which was not applied upstream. We want v3,
which will be applied in the next commit.
This reverts commit 4cb8b05da726ae5d9244806e77fce3bfc59772dc.
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
|
|
During mass manufacturing, we noticed the mmc_rx_crc_error counter,
as reported by "ethtool -S eth0 | grep mmc_rx_crc_error" to increase
above zero during nuttcp speedtests.
Cycling through the rx_delay range on two boards shows that there is a
large "good" region from 0x11 to 0x35 (see below for details).
This commit increases rx_delay to 0x11, which is the smallest
possible change that fixes the issue we are seeing on the KSZ9031 PHY.
This also matches what most other rk3399 boards do.
Tests for Puma PCBA S/N TT0069903:
rx_delay mmc_rx_crc_error
-------- ----------------
0x09 (dhcp broken)
0x10 897
0x11 0
0x20 0
0x30 0
0x35 0
0x3a 745
0x3b 11375
0x3c 36680
0x40 (dhcp broken)
0x7f (dhcp broken)
Tests for Puma PCBA S/N TT0157733:
rx_delay mmc_rx_crc_error
-------- ----------------
0x10 59
0x11 0
0x35 0
Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
Cc: <stable@vger.kernel.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
Link: https://lore.kernel.org/lkml/20241202102543.204154-1-jakob.unterwurzacher@cherry.de/T/#u
|
|
Missing config options for docker/podman were determined by using
following to scripts as a base:
https://raw.githubusercontent.com/moby/moby/master/contrib/check-config.sh
https://github.com/opencontainers/runc/blob/main/script/check-config.sh
Just using these options alone was not enough when using docker/podman
on Debian 12. Additional following options were changed after making the
scripts above happy to make docker/podman work:
-CONFIG_SYN_COOKIES=y
-CONFIG_NETFILTER_XT_MARK=y
+CONFIG_NF_TABLES=y
+CONFIG_NF_TABLES_INET=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_NUMGEN=y
+CONFIG_NFT_CT=y
+CONFIG_NFT_CONNLIMIT=y
+CONFIG_NFT_LOG=y
+CONFIG_NFT_LIMIT=y
+CONFIG_NFT_MASQ=y
+CONFIG_NFT_REDIR=y
+CONFIG_NFT_NAT=y
+CONFIG_NFT_TUNNEL=y
+CONFIG_NFT_QUOTA=y
+CONFIG_NFT_REJECT=y
+CONFIG_NFT_COMPAT=y
+CONFIG_NFT_HASH=y
+CONFIG_NFT_XFRM=y
+CONFIG_NFT_SOCKET=y
+CONFIG_NFT_OSF=y
+CONFIG_NFT_TPROXY=y
+CONFIG_NFT_SYNPROXY=y
+CONFIG_NFT_DUP_NETDEV=y
+CONFIG_NFT_FWD_NETDEV=y
+CONFIG_NF_FLOW_TABLE_INET=y
+CONFIG_NF_FLOW_TABLE=y
+CONFIG_NETFILTER_XT_TARGET_MARK=y
+CONFIG_NF_TABLES_ARP=y
+CONFIG_NF_TABLES_BRIDGE=y
+CONFIG_TUN=y
Tested on Debian 12 generated via:
https://git.embedded.cherry.de/debos-recipes.git/
apt-get install docker.io
docker run -it alpine ping embedded.cherry.de
apt-get install podman
su user -l
podman run -it alpine wget embedded.cherry.de
Based on work that was done for RK3588 Jaguar on 6.1.
Relates-to: PUMA-109
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
Missing config options for docker/podman were determined by using
following to scripts as a base:
https://raw.githubusercontent.com/moby/moby/master/contrib/check-config.sh
https://github.com/opencontainers/runc/blob/main/script/check-config.sh
Just using these options alone was not enough when using docker/podman
on Debian 12. Additional following options were changed after making the
scripts above happy to make docker/podman work:
-CONFIG_SYN_COOKIES=y
-CONFIG_NETFILTER_XT_MARK=y
+CONFIG_NF_TABLES=y
+CONFIG_NF_TABLES_INET=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_NUMGEN=y
+CONFIG_NFT_CT=y
+CONFIG_NFT_CONNLIMIT=y
+CONFIG_NFT_LOG=y
+CONFIG_NFT_LIMIT=y
+CONFIG_NFT_MASQ=y
+CONFIG_NFT_REDIR=y
+CONFIG_NFT_NAT=y
+CONFIG_NFT_TUNNEL=y
+CONFIG_NFT_QUOTA=y
+CONFIG_NFT_REJECT=y
+CONFIG_NFT_COMPAT=y
+CONFIG_NFT_HASH=y
+CONFIG_NFT_XFRM=y
+CONFIG_NFT_SOCKET=y
+CONFIG_NFT_OSF=y
+CONFIG_NFT_TPROXY=y
+CONFIG_NFT_SYNPROXY=y
+CONFIG_NFT_DUP_NETDEV=y
+CONFIG_NFT_FWD_NETDEV=y
+CONFIG_NF_FLOW_TABLE_INET=y
+CONFIG_NF_FLOW_TABLE=y
+CONFIG_NETFILTER_XT_TARGET_MARK=y
+CONFIG_NF_TABLES_ARP=y
+CONFIG_NF_TABLES_BRIDGE=y
+CONFIG_TUN=y
Tested on Debian 12 generated via:
https://git.embedded.cherry.de/debos-recipes.git/
apt-get install docker.io
docker run -it alpine ping embedded.cherry.de
apt-get install podman
su user -l
podman run -it alpine wget embedded.cherry.de
Based on work that was done for RK3588 Jaguar on 6.1.
Relates-to: RNG-220
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
Ringneck v1.4 can contain (placement option) an on-board ATtiny
microcontroller instead of an STM32. In normal operation, this
is transparent to the software, as both microcontrollers emulate
the same ICs (amc6821 and isl1208).
For flashing the ATtiny, the SWITCH_REG1 regulator of the board's PMIC is
used to enable the ATtiny UPDI debug interface. If the STM32 is placed, or if
we are running on an older Ringneck revision, SWITCH_REG1 is not connected
and has no effect.
Add attiny-updi-gate-regulator so userspace can control it via sysfs
(needs CONFIG_REGULATOR_USERSPACE_CONSUMER):
echo enabled > /sys/devices/platform/attiny-updi-gate-regulator/state
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20240926132028.21910-1-jakob.unterwurzacher@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 1871e6f7c5e606b97708af50a7fec83a904a761b)
Relates-to: RNG-174
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
Ringneck v1.4 uses this for flashing the on-board ATtiny
microcontroller.
Relates-to: RNG-174
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
There is a PWRBTN# input pin exposed on a Q7 connector. The pin
is routed to a GPIO0_A1 through a diode. Q7 specification describes
the PWRBTN# pin as a Power Button signal.
Configure the pin as KEY_POWER, so it can function as power button and
trigger device shutdown.
Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20241001134741.210979-1-dse@thaumatec.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 52f21c63ed6ab7bc5d0ef310c15890ea6a6334c2)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
Haikou
We override pinctrl-0 of pinctrl node of Puma DTSI in Puma Haikou to add
&q7_sdio_wp_pin &q7_smb_alert_pin to it. However, the pinctrl-0 property
in Puma DTSI has changed recently, so we need to update Puma Haikou DTS
to not remove items in the array property.
[TSD] This is required only because we made a Haikou Tester-specific
modification to Puma Haikou but this isn't upstreamed (it could be
upstreamed but in a separate Device Tree (Overlay)).
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
RK3399 Puma
The Qseven BIOS_DISABLE signal on the RK3399-Q7 keeps the on-module eMMC
and SPI flash powered-down initially (in fact it keeps the reset signal
asserted). BIOS_DISABLE_OVERRIDE pin allows to override that signal so
that eMMC and SPI can be used regardless of the state of the signal.
Let's make this GPIO a hog so that it's reserved and locked in the
proper state.
At the same time, make sure the pin is reserved for the hog and cannot
be requested by another node.
Cc: stable@vger.kernel.org
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20240731-puma-emmc-6-v1-2-4e28eadf32d0@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 741f5ba7ccba5d7ae796dd11c320e28045524771)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
used on RK3399 Puma
In commit 91419ae0420f ("arm64: dts: rockchip: use BCLK to GPIO switch
on rk3399"), an additional pinctrl state was added whose default pinmux
is for 8ch i2s0. However, Puma only has 2ch i2s0. It's been overriding
the pinctrl-0 property but the second property override was missed in
the aforementioned commit.
On Puma, a hardware slider called "BIOS Disable/Normal Boot" can disable
eMMC and SPI to force booting from SD card. Another software-controlled
GPIO is then configured to override this behavior to make eMMC and SPI
available without human intervention. This is currently done in U-Boot
and it was enough until the aforementioned commit.
Indeed, because of this additional not-yet-overridden property, this
software-controlled GPIO is now muxed in a state that does not override
this hardware slider anymore, rendering SPI and eMMC flashes unusable.
Let's override the property with the 2ch pinmux to fix this.
Fixes: 91419ae0420f ("arm64: dts: rockchip: use BCLK to GPIO switch on rk3399")
Cc: stable@vger.kernel.org
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20240731-puma-emmc-6-v1-1-4e28eadf32d0@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit bb94a157b37ec23f53906a279320f6ed64300eba)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
For whatever reason the peripheral functionality is unstable on px30.
With wiggling some power-management things like we did on 6.0, we can
make it better, but that affects the host functionality, breaking
detection of usb devices plugged in at runtime.
So make the port host-only on ringneck until such time that someone
needs peripheral functionality.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
|
|
The DWC2 IP on the Rockchip SoCs doesn't support clock gating.
When a clock gating is enabled, system hangs.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Acked-by: Minas Harutyunyan <hminas@synopsys.com>
Link: https://lore.kernel.org/r/1703575199-23638-1-git-send-email-william.wu@rock-chips.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ca2dc35e555e7043de585f4e46123d8fbd2b5a21)
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
|
|
initialisation"
This reverts commit 341ba9fd09ec0f32c7015f597acb6f615ff298e1.
Introduced in v2 in december 2022
https://lore.kernel.org/lkml/20221206-dwc2-gadget-dual-role-v2-0-0de821615dd3@theobroma-systems.com/
the change was aiming at making peripheral mode more reliable.
We carried it over to the 6.6.39, where more heavy testing revealed it
to cause reliability problems in host-mode.
The dwc2 maintainer suggested in
https://lore.kernel.org/lkml/BYAPR12MB339938A2413F4D40A084F4DCA7EA9@BYAPR12MB3399.namprd12.prod.outlook.com/
This mostly happen if PHY not initialized correctly.
for the reported dwc2 hang message and also
If "still not flawlessly working" maybe required deeper investigate issue
and submit "flawlessly working" patch.
and we also are more in need of reliable host-mode, revert this change
for now and we'll need to dig deeper into this if the need to
peripheral mode arises.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
|
|
This reverts commit e206dbd15e9a8c8224b3ae648182549ee9cdb05d.
Introduced in v2 in december 2022
https://lore.kernel.org/lkml/20221206-dwc2-gadget-dual-role-v2-0-0de821615dd3@theobroma-systems.com/
the change was aiming at making peripheral mode more reliable.
We carried it over to the 6.6.39, where more heavy testing revealed it
to cause reliability problems in host-mode.
The dwc2 maintainer suggested in
https://lore.kernel.org/lkml/BYAPR12MB339938A2413F4D40A084F4DCA7EA9@BYAPR12MB3399.namprd12.prod.outlook.com/
This mostly happen if PHY not initialized correctly.
for the reported dwc2 hang message and also
If "still not flawlessly working" maybe required deeper investigate issue
and submit "flawlessly working" patch.
and we also are more in need of reliable host-mode, revert this change
for now and we'll need to dig deeper into this if the need to
peripheral mode arises.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
|
|
dual-role mode"
This reverts commit 80f93ba48791a68e9e19f7a3223ff9f14034ff78.
The change was originally submitted and applied upstream from
https://lore.kernel.org/all/20221206-dwc2-gadget-dual-role-v1-2-36515e1092cd@theobroma-systems.com/
It was found to cause issues on at least STM32 and thus reverted by
https://lore.kernel.org/lkml/20230315144433.3095859-1-fabrice.gasnier@foss.st.com/
We reintroduced it in our 6.6.39 kernel but after more heavy testing
also ran into problems when using the port in host-mode.
So, revert this change again, as working host-mode is a lot more important
and making dwc2 work in peripheral mode will take a lot more work
to make stable.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
|
|
This reverts commit de13db32b0f89a040b50a51d129b9443159a660a.
While in the previous kernel release (6.0.2) only 1080p HDMI displays were
supported, the now reverted 3-commit-series introduced very limited
support for a 4K mode, creating problems for a panel used in our products.
The panel in question has one additional mode of 1920x1200 that cannot
be satisfied by the current hdmi- and clock structure and throws the
hdmi modesetting for a a loop.
By reverting these commits, we reach feature parity with our previous
kernel release.
Relates-to: PUMA-108
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
|
|
This reverts commit 83b61f817f43ed67572d1e241c9f552e0a8bfff4.
While in the previous kernel release (6.0.2) only 1080p HDMI displays were
supported, the now reverted 3-commit-series introduced very limited
support for a 4K mode, creating problems for a panel used in our products.
The panel in question has one additional mode of 1920x1200 that cannot
be satisfied by the current hdmi- and clock structure and throws the
hdmi modesetting for a a loop.
By reverting these commits, we reach feature parity with our previous
kernel release.
Relates-to: PUMA-108
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
|
|
This reverts commit d13b10ec6696b0c523fa21b65c7ff6f246a49560.
While in the previous kernel release (6.0.2) only 1080p HDMI displays were
supported, the now reverted 3-commit-series introduced very limited
support for a 4K mode, creating problems for a panel used in our products.
The panel in question has one additional mode of 1920x1200 that cannot
be satisfied by the current hdmi- and clock structure and throws the
hdmi modesetting for a a loop.
By reverting these commits, we reach feature parity with our previous
kernel release.
Relates-to: PUMA-108
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
|
|
Recreate the defconfig via make savedefconfig
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
|
|
Q7_SMB_ALERT
Each of the above mentioned pins is connected to a diode
on the module which is used as a level shifter, and they
are configured internally pulled-down by default.
We need to configure these pins to internally pulled-up,
otherwise whenever one of the pins is configured as INPUT
and we try to control it externally the value will always
remain zero.
[TSD] Only applies to Haikou Tester as those pins aren't
necessarily used as input so we don't need to always have
a pull-up for it (e.g. if driving them as output).
[TSD] No upstream Haikou Tester support for now
Relates-to: PUMA-90, PUMA-91
Signed-off-by: Iskander Amara <iskander.amara@theobroma-systems.com>
|
|
Disable a sysfs userspace fallback mechanism for firmware load requests.
When enabled and device firmware was not found, this option will cause
a 60s delay, before initializing the device. For this reason, keep it
disabled by default.
Relates-to: PIXR-311
Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
|
|
tester daughterboard
This enables the SPI-NOR flash found on Puma Haikou with the tester
daughterboard attached.
We use this SPI-NOR flash to test that SPI bus exposed on the Haikou
works correctly.
[TSD] The tester daughterboard is removable and is rarely used, so not
much sense to upstream it. Just add it for end-of-line testing.
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
|
|
Enable PL2303 device driver, because we want to test it
with the SoM.
Relates-to: ENAB-35
Signed-off-by: Vahe Grigoryan <vahe.grigoryan@theobroma-systems.com>
|
|
Enable FTDI device driver, because we want to test it
with the SoM.
Relates-to: ENAB-35
Signed-off-by: Vahe Grigoryan <vahe.grigoryan@theobroma-systems.com>
|
|
Enable CP210x device driver, because we need it to
configure CP210x from the SoM.
Relates-to: ENAB-35
Signed-off-by: Vahe Grigoryan <vahe.grigoryan@theobroma-systems.com>
|
|
From https://www.kernel.org/doc/Documentation/networking/netconsole.txt :
> This module logs kernel printk messages over UDP allowing debugging of
> problem where disk logging fails and serial consoles are impractical.
That's exactly why we need it.
We also need CONFIG_NETCONSOLE_DYNAMIC because for many usecases, we
get an IP address over DHCP, and netconsole can only be enabled when
you have an IP address.
Relates-to: RNG-180
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
|
|
We don't use memory hotplug, but having it enabled means we have
/sys/devices/system/memory and that means lsmem now works.
lsmem is the only way I know of to find out the physical memory size.
Even /proc/iomem misses 18 MiB for some reason (it reports 4078 MiB
instead of 4096 MiB).
The Image gets about 64kiB larger, which seems worth having lsmem.
Relates-to: JAG-90
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
[imported from Tiger/Jaguar repo]
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
|
|
For consistency with the newer PX30-uQ7 module and also
because it seems to serve no purpose other than making the
"aplay -L" device list longer (a lot longer) and making
selecting the right device more difficult.
root@puma-debos:~# aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
hw:CARD=Loopback,DEV=0
Loopback, Loopback PCM
Direct hardware device without any conversions
hw:CARD=Loopback,DEV=1
Loopback, Loopback PCM
Direct hardware device without any conversions
plughw:CARD=Loopback,DEV=0
Loopback, Loopback PCM
Hardware device with all software conversions
plughw:CARD=Loopback,DEV=1
Loopback, Loopback PCM
Hardware device with all software conversions
default:CARD=Loopback
Loopback, Loopback PCM
Default Audio Device
sysdefault:CARD=Loopback
Loopback, Loopback PCM
Default Audio Device
front:CARD=Loopback,DEV=0
Loopback, Loopback PCM
Front output / input
surround21:CARD=Loopback,DEV=0
Loopback, Loopback PCM
2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=Loopback,DEV=0
Loopback, Loopback PCM
4.0 Surround output to Front and Rear speakers
surround41:CARD=Loopback,DEV=0
Loopback, Loopback PCM
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=Loopback,DEV=0
Loopback, Loopback PCM
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=Loopback,DEV=0
Loopback, Loopback PCM
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=Loopback,DEV=0
Loopback, Loopback PCM
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
dmix:CARD=Loopback,DEV=0
Loopback, Loopback PCM
Direct sample mixing device
dmix:CARD=Loopback,DEV=1
Loopback, Loopback PCM
Direct sample mixing device
hw:CARD=HaikouI2Scodec,DEV=0
Haikou,I2S-codec, ff880000.i2s-sgtl5000 sgtl5000-0
Direct hardware device without any conversions
plughw:CARD=HaikouI2Scodec,DEV=0
Haikou,I2S-codec, ff880000.i2s-sgtl5000 sgtl5000-0
Hardware device with all software conversions
default:CARD=HaikouI2Scodec
Haikou,I2S-codec, ff880000.i2s-sgtl5000 sgtl5000-0
Default Audio Device
sysdefault:CARD=HaikouI2Scodec
Haikou,I2S-codec, ff880000.i2s-sgtl5000 sgtl5000-0
Default Audio Device
dmix:CARD=HaikouI2Scodec,DEV=0
Haikou,I2S-codec, ff880000.i2s-sgtl5000 sgtl5000-0
Direct sample mixing device
|
|
This is a leftover from the defconfig that was created by deriving it
from one coming from Yocto Project where yocto is added to LOCALVERSION.
Since it is not provided this kernel will be used in a Yocto image,
let's remove the localversion entirely to not confuse users.
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
|
|
Tested and working with the following things connected to the
Q7-Camera-Demo v1.0 adapter PCBA:
* Top-to-Bottom flex cable connected to P2
* One SF2V5675AY10 camera connected to P3
The Q7-Camera-Demo supports three cameras in total and hdmi input,
but the Puma SoM only supports one camera.
This commit only adds support for the subset supported by the Puma SoM.
[TSD] rockchip,io-domains DT property is not upstreamed yet (and disputed),
see https://lore.kernel.org/lkml/20220802095252.2486591-1-foss+kernel@0leil.net/
Relates-to: EHSW-1509
Relates-to: EHHW-730
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
|
|
Set camera orientation to "front", because it is placed in the front of
the device.
[TSD] This change will be part of the original patch series once sent
upstream.
Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
|
|
Configure the camera sensor rotation on the Haikou Video Demo adapter.
Haikou Video Demo board reference system was defined basing on the
following assumptions:
- side with mounted adapter is the front of the device (display side),
- default display position is vertical.
Y-axis
^
! FRONT VIEW
!
!
! +-------------------------------------------------+
! |o Haikou |
! || |
! |+------------------------+ |
! || __ | |
! || / \ <-Camera | |
! || \__/ | |
! || +--------------------+ | |
! || | | | |
! || | | | |
! || | | | |
! || | | | |
! || | | | |
! || | | | |
! || | Video Demo | | |
! || | Adapter | | |
! || | | | |
! || | | | |
! || | | | |
! || | | | |
! || | | | |
! || | | | |
! || +--------------------+ | |
! |o------------------------+----------------o |
! +-------------------------------------------------+
!
0 +-------------------------------------------------------------->
0 X-axis
Set camera rotation to 180 degrees, because camera sensor is mounted
upside down in reference to the board reference system.
[TSD] This change will be part of the original patch series once sent
upstream.
Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
|
|
The Video Demo adapter can be connected to Haikou devkit via the Video
Connector connector which exposes video-related signals (CSI/DSI).
The Video Demo adapter is compatible with an OV5675 camera sensor fitted
with a DW9714 focus lens driver and a Leadtek LTK050H3148W panel fitted
with a Goodix GT911 touchscreen.
Some pins are controlled over a PCA9670 GPIO expander.
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
|
|
This adds a defconfig for Puma RK3399 on Haikou with support for
components found on the Haikou Video Demo adapter.
TSD: board defconfigs not allowed upstream
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
|
|
Puma RK3399 SoM
This adds support for the Video Demo adapter for Haikou devkit with Puma
RK3399 SoM.
The Video Demo adapter is an adapter connected to the fake PCIe slot
labeled "Video Connector" on the Haikou devkit. It has an Omnivision
OV5675 camera sensor fitted with a DW9714 focus lens driver, as well as
a Leadtek LTK050H3148W display fitted with a Goodix GT911 touchscreen.
It also has a SW controllable blue LED and most of the lanes are routed
through a GPIO expander connected over I2C.
The display is using MIPI-DSI while the camera is using MIPI-CSI for
their video streams.
[TSD] more work needs to be done on the driver side to allow non-19.2MHz
CSI MCLK before upstreaming this.
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
|
|
Rebuild the defconfig for 6.6
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
|
|
The MFD symbol was renamed between 6.0 and 6.6 when support
for the SPI variant of the rk8xx pmics was introduced.
Fix the symbol name in the defconfig.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
|
|
From https://www.kernel.org/doc/Documentation/networking/netconsole.txt :
> This module logs kernel printk messages over UDP allowing debugging of
> problem where disk logging fails and serial consoles are impractical.
That's exactly why we need it.
We also need CONFIG_NETCONSOLE_DYNAMIC because for many usecases, we
get an IP address over DHCP, and netconsole can only be enabled when
you have an IP address.
Relates-to: RNG-180
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
|
|
We don't use memory hotplug, but having it enabled means we have
/sys/devices/system/memory and that means lsmem now works.
lsmem is the only way I know of to find out the physical memory size.
Even /proc/iomem misses 18 MiB for some reason (it reports 4078 MiB
instead of 4096 MiB).
The Image gets about 66kiB larger, which seems worth having lsmem.
Relates-to: JAG-90
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
[imported from Tiger/Jaguar repo]
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
|
|
The End-of-Line test uses an FTDI USB to serial converter connected on
Haikou USB to flash the Mule ATtiny over UPDI, so let's enable support
for that converter.
[TSD] upstream does not take device defconfigs for aarch64 devices
Signed-off-by: Ermin Sunj <ermin.sunj@theobroma-systems.com>
|
|
This exports the PMIC's PWRKEY input as an input device.
systemd reacts to it and shuts the system down, which is what we want.
root@ringneck-debos:~# evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: rk805 pwrkey
/dev/input/event1: gpio-keys
Select the device event number [0-1]: 0
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "rk805 pwrkey"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 116 (KEY_POWER)
Properties:
Testing ... (interrupt to exit)
Event: time 1681977266.296379, type 1 (EV_KEY), code 116 (KEY_POWER), value 1
Event: time 1681977266.296379, -------------- SYN_REPORT ------------
Stopping Session 1 of user root.
[ OK ] Removed slice system-modprobe.slice.
[ OK ] Stopped target Graphical Interface.
[...]
[ OK ] Stopped Create Static Device Nodes in /dev.
[ OK ] Stopped Create System Users.
[ OK ] Stopped Remount Root and Kernel File Systems.
[ OK ] Reached target Shutdown.
[ OK ] Reached target Final Step.
[ OK ] Finished Power-Off.
[ OK ] Reached target Power-Off.
[ 115.161046] systemd-shutdown[1]: Syncing filesystems and block devices.
[ 115.511509] systemd-shutdown[1]: Sending SIGTERM to remaining processes...
[ 115.542933] systemd-journald[174]: Received SIGTERM from PID 1 (systemd-shutdow).
[ 115.850606] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
[ 115.884182] systemd-shutdown[1]: Unmounting file systems.
[ 115.896373] [404]: Remounting '/' read-only in with options '(null)'.
[ 116.084265] EXT4-fs (mmcblk2p1): re-mounted. Quota mode: none.
[ 116.104445] systemd-shutdown[1]: All filesystems unmounted.
[ 116.110876] systemd-shutdown[1]: Deactivating swaps.
[ 116.116875] systemd-shutdown[1]: All swaps deactivated.
[ 116.122836] systemd-shutdown[1]: Detaching loop devices.
[ 116.138654] systemd-shutdown[1]: All loop devices detached.
[ 116.145101] systemd-shutdown[1]: Stopping MD devices.
[ 116.151698] systemd-shutdown[1]: All MD devices stopped.
[ 116.157901] systemd-shutdown[1]: Detaching DM devices.
[ 116.164461] systemd-shutdown[1]: All DM devices detached.
[ 116.170821] systemd-shutdown[1]: All filesystems, swaps, loop devices, MD devices and DM devices detached.
[ 116.198617] systemd-shutdown[1]: Syncing filesystems and block devices.
[ 116.206400] systemd-shutdown[1]: Powering off.
[ 116.281941] reboot: Power down
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
|
|
This is required for the display to work on Haikou LVDS 9904379 adapter
so let's enable those options.
[TSD] upstream does not take device defconfigs for aarch64 devices
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
|
