The panel can be downclocked to 156 MHz pixel clock (normally 162MHz). This yields a DSI DDR clock of 936MHz. A311D and SN65DSI86 can agree on this clock.
Note: g12a_sys_pll_mult_range.min
was reduced to 120, but unclear if it is still necessary.
As gleaned from https://android.googlesource.com/kernel/arm64/+/f5269100977385d1fd4a5ef68e49631892cf4fe4/drivers/amlogic/media/vout/lcd/lcd_tablet/mipi_dsi_util.c#769 there is another "state" where lp2hs, hs2lp timings are different for certain resolutions, like 1920 width as in our case.
These settings made the display come alive (dw_mipi_dsi_phy_get_timing
):
timing->clk_lp2hs = 23;
timing->clk_hs2lp = 38;
timing->data_lp2hs = 15;
timing->data_hs2lp = 9;
Something is wrong in DSI vsync calculation, there was a 3 line wraparound/offset. This is a workaround in panel-edp.c
:
static const struct drm_display_mode innolux_n125hce_gn1_mode = {
- .vsync_start = 1080 + 4,
- .vsync_end = 1080 + 4 + 4,
- .vtotal = 1080 + 4 + 4 + 24,
+ .vsync_start = 1080 + 1,
+ .vsync_end = 1080 + 1 + 4,
+ .vtotal = 1080 + 1 + 4 + 27,
VIU_OSD_HOLD_FIFO_LINES
had to be reduced, otherwise there is a glitch around every minute:
diff --git a/drivers/gpu/drm/meson/meson_viu.c b/drivers/gpu/drm/meson/meson_viu.c
index cd399b0b7181..119d00f23f8c 100644
--- a/drivers/gpu/drm/meson/meson_viu.c
+++ b/drivers/gpu/drm/meson/meson_viu.c
@@ -441,7 +441,7 @@ void meson_viu_init(struct meson_drm *priv)
VIU_OSD_FIFO_LIMITS(2); /* fifo_lim: 2*16=32 */
if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A))
- reg |= (VIU_OSD_BURST_LENGTH_32 | VIU_OSD_HOLD_FIFO_LINES(31));
+ reg |= (VIU_OSD_BURST_LENGTH_32 | VIU_OSD_HOLD_FIFO_LINES(4)); // FIXME altered
PHY_STOP_WAIT_TIME
was reduced before, but unclear if necessary.
- dsi_write(dsi, DSI_PHY_IF_CFG, PHY_STOP_WAIT_TIME(0x20) |
+ dsi_write(dsi, DSI_PHY_IF_CFG, PHY_STOP_WAIT_TIME(0x1) |
If the display pipeline is reset, the display won't work a second time: SN65DSI86 will fail PLL lock on the eDP display side. Perhaps there is a step or a delay missing in the re-init sequence.
To make dw-hdmi.c
not OOPS when connecting a display, I had to return false
in dw_hdmi_support_scdc()
. (Known bug)
To be investigated. Ethernet currently works only at 100Mbit/s and with the following settings, otherwise the link loops forever on and off:
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4.dtsi
@@ -197,7 +197,11 @@ &ext_mdio {
external_phy: ethernet-phy@0 {
/* Realtek RTL8211F (0x001cc916) */
reg = <0>;
- max-speed = <1000>;
+ max-speed = <100>;
+
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
+ reset-gpios = <&gpio GPIOZ_15 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>;
interrupt-parent = <&gpio_intc>;
/* MAC_INTR on GPIOZ_14 */
@@ -209,8 +213,10 @@ external_phy: ethernet-phy@0 {
ðmac {
pinctrl-0 = <ð_pins>, <ð_rgmii_pins>;
pinctrl-names = "default";
- phy-mode = "rgmii-txid";
+ phy-mode = "rgmii";
phy-handle = <&external_phy>;
+
+ //amlogic,tx-delay-ns = <2>;
};
Codec integration is incomplete, I need some help with this as the meson-g12b DAI stuff looks overwhelmingly complex.
With xdarklight
's help I figured out that we get RX buffer corruption with the rtl8822cs
SDIO module. It can connect to APs but will OOPS because of corrupt packet structures when doing bigger transfers. We noticed that the SDIO runs at a very low clock, 25MHz, even if 50MHz is specified in DTS. This needs to be investigated.