From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> To: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>, Geert Uytterhoeven <geert+renesas@glider.be>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Magnus Damm <magnus.damm@gmail.com>, Rob Herring <robh+dt@kernel.org>, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org Cc: Andrzej Hajda <andrzej.hajda@intel.com>, Neil Armstrong <neil.armstrong@linaro.org>, Robert Foss <robert.foss@linaro.org>, Jonas Karlman <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@gmail.com>, Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Subject: Re: [PATCH v1 7/8] drm: rcar-du: dsi: Add r8A779g0 support Date: Tue, 22 Nov 2022 10:50:30 +0200 [thread overview] Message-ID: <4481a3fe-63a9-39d5-5394-a2f2639f1bcc@ideasonboard.com> (raw) In-Reply-To: <166869996543.50677.17182739414507530884@Monstersaurus> On 17/11/2022 17:46, Kieran Bingham wrote: > Quoting Tomi Valkeinen (2022-11-17 12:25:46) >> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> >> >> Add DSI support for r8a779g0. The main differences to r8a779a0 are in >> the PLL and PHTW setups. >> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> >> --- >> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 484 +++++++++++++++---- >> drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h | 6 +- >> 2 files changed, 384 insertions(+), 106 deletions(-) >> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c >> index a7f2b7f66a17..723c35726c38 100644 >> --- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c >> +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c >> @@ -9,6 +9,7 @@ >> #include <linux/delay.h> >> #include <linux/io.h> >> #include <linux/iopoll.h> >> +#include <linux/math64.h> >> #include <linux/module.h> >> #include <linux/of.h> >> #include <linux/of_device.h> >> @@ -28,6 +29,20 @@ >> #include "rcar_mipi_dsi.h" >> #include "rcar_mipi_dsi_regs.h" >> >> +#define MHZ(v) ((v) * 1000000u) >> + >> +enum rcar_mipi_dsi_hw_model { >> + RCAR_DSI_R8A779A0, >> + RCAR_DSI_R8A779G0, >> +}; >> + >> +struct rcar_mipi_dsi_device_info { >> + enum rcar_mipi_dsi_hw_model model; >> + const struct dsi_clk_config *clk_cfg; >> + u8 clockset2_m_offset; >> + u8 clockset2_n_offset; >> +}; >> + >> struct rcar_mipi_dsi { >> struct device *dev; >> const struct rcar_mipi_dsi_device_info *info; >> @@ -50,6 +65,17 @@ struct rcar_mipi_dsi { >> unsigned int lanes; >> }; >> >> +struct dsi_setup_info { >> + unsigned long hsfreq; >> + u16 hsfreqrange; >> + >> + unsigned long fout; >> + u16 m; >> + u16 n; >> + u16 vclk_divider; >> + const struct dsi_clk_config *clkset; >> +}; >> + >> static inline struct rcar_mipi_dsi * >> bridge_to_rcar_mipi_dsi(struct drm_bridge *bridge) >> { >> @@ -62,22 +88,6 @@ host_to_rcar_mipi_dsi(struct mipi_dsi_host *host) >> return container_of(host, struct rcar_mipi_dsi, host); >> } >> >> -static const u32 phtw[] = { >> - 0x01020114, 0x01600115, /* General testing */ >> - 0x01030116, 0x0102011d, /* General testing */ >> - 0x011101a4, 0x018601a4, /* 1Gbps testing */ >> - 0x014201a0, 0x010001a3, /* 1Gbps testing */ >> - 0x0101011f, /* 1Gbps testing */ >> -}; >> - >> -static const u32 phtw2[] = { >> - 0x010c0130, 0x010c0140, /* General testing */ >> - 0x010c0150, 0x010c0180, /* General testing */ >> - 0x010c0190, >> - 0x010a0160, 0x010a0170, >> - 0x01800164, 0x01800174, /* 1Gbps testing */ >> -}; >> - >> static const u32 hsfreqrange_table[][2] = { >> { 80000000U, 0x00 }, { 90000000U, 0x10 }, { 100000000U, 0x20 }, >> { 110000000U, 0x30 }, { 120000000U, 0x01 }, { 130000000U, 0x11 }, >> @@ -103,24 +113,53 @@ static const u32 hsfreqrange_table[][2] = { >> { /* sentinel */ }, >> }; >> >> -struct vco_cntrl_value { >> +struct dsi_clk_config { >> u32 min_freq; >> u32 max_freq; >> - u16 value; >> + u8 vco_cntrl; >> + u8 cpbias_cntrl; >> + u8 gmp_cntrl; >> + u8 int_cntrl; >> + u8 prop_cntrl; >> }; >> >> -static const struct vco_cntrl_value vco_cntrl_table[] = { >> - { .min_freq = 40000000U, .max_freq = 55000000U, .value = 0x3f }, >> - { .min_freq = 52500000U, .max_freq = 80000000U, .value = 0x39 }, >> - { .min_freq = 80000000U, .max_freq = 110000000U, .value = 0x2f }, >> - { .min_freq = 105000000U, .max_freq = 160000000U, .value = 0x29 }, >> - { .min_freq = 160000000U, .max_freq = 220000000U, .value = 0x1f }, >> - { .min_freq = 210000000U, .max_freq = 320000000U, .value = 0x19 }, >> - { .min_freq = 320000000U, .max_freq = 440000000U, .value = 0x0f }, >> - { .min_freq = 420000000U, .max_freq = 660000000U, .value = 0x09 }, >> - { .min_freq = 630000000U, .max_freq = 1149000000U, .value = 0x03 }, >> - { .min_freq = 1100000000U, .max_freq = 1152000000U, .value = 0x01 }, >> - { .min_freq = 1150000000U, .max_freq = 1250000000U, .value = 0x01 }, >> +static const struct dsi_clk_config dsi_clk_cfg_r8a779a0[] = { >> + { 40000000u, 55000000u, 0x3f, 0x10, 0x01, 0x00, 0x0b }, >> + { 52500000u, 80000000u, 0x39, 0x10, 0x01, 0x00, 0x0b }, >> + { 80000000u, 110000000u, 0x2f, 0x10, 0x01, 0x00, 0x0b }, >> + { 105000000u, 160000000u, 0x29, 0x10, 0x01, 0x00, 0x0b }, >> + { 160000000u, 220000000u, 0x1f, 0x10, 0x01, 0x00, 0x0b }, >> + { 210000000u, 320000000u, 0x19, 0x10, 0x01, 0x00, 0x0b }, >> + { 320000000u, 440000000u, 0x0f, 0x10, 0x01, 0x00, 0x0b }, >> + { 420000000u, 660000000u, 0x09, 0x10, 0x01, 0x00, 0x0b }, >> + { 630000000u, 1149000000u, 0x03, 0x10, 0x01, 0x00, 0x0b }, >> + { 1100000000u, 1152000000u, 0x01, 0x10, 0x01, 0x00, 0x0b }, >> + { 1150000000u, 1250000000u, 0x01, 0x10, 0x01, 0x00, 0x0c }, > > Sigh ... is it this one 0x0c value that means we need to keep all these > entries repeated ? :-S > > If it weren't for that, it seems we could keep just two sets of >> + u8 cpbias_cntrl; >> + u8 gmp_cntrl; >> + u8 int_cntrl; >> + u8 prop_cntrl; > > One for each of the 9a0, and the 9g0... > > But this is fine, and I guess the implication is there may be other > future differences to come in other platforms. > > It could be refactored then when we have more visibility. Yes, it's not so nice. And afaiu some of these values should really be solved dynamically in the code. But the docs list these tables and don't explain how to come up with those values, so... I think having these tables is the safest way. >> @@ -427,8 +671,21 @@ static int rcar_mipi_dsi_startup(struct rcar_mipi_dsi *dsi, >> dev_warn(dsi->dev, "unsupported format"); >> return -EINVAL; >> } >> - vclkset |= VCLKSET_COLOR_RGB | VCLKSET_DIV(setup_info.div) >> - | VCLKSET_LANE(dsi->lanes - 1); >> + >> + vclkset |= VCLKSET_COLOR_RGB | VCLKSET_LANE(dsi->lanes - 1); >> + >> + switch (dsi->info->model) { >> + case RCAR_DSI_R8A779A0: >> + vclkset |= VCLKSET_DIV_R8A779A0(__ffs(setup_info.vclk_divider)); >> + break; >> + >> + case RCAR_DSI_R8A779G0: >> + vclkset |= VCLKSET_DIV_R8A779G0(__ffs(setup_info.vclk_divider) - 1); > > Why is this a -1 here ? Seems an odd difference compared to the A0. You need to ask the HW designers =). That's how the register is on G0. Field value of 0 means divided by 2. Tomi
WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> To: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>, Geert Uytterhoeven <geert+renesas@glider.be>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Magnus Damm <magnus.damm@gmail.com>, Rob Herring <robh+dt@kernel.org>, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org Cc: Neil Armstrong <neil.armstrong@linaro.org>, Jonas Karlman <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@gmail.com>, Robert Foss <robert.foss@linaro.org>, Andrzej Hajda <andrzej.hajda@intel.com>, Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Subject: Re: [PATCH v1 7/8] drm: rcar-du: dsi: Add r8A779g0 support Date: Tue, 22 Nov 2022 10:50:30 +0200 [thread overview] Message-ID: <4481a3fe-63a9-39d5-5394-a2f2639f1bcc@ideasonboard.com> (raw) In-Reply-To: <166869996543.50677.17182739414507530884@Monstersaurus> On 17/11/2022 17:46, Kieran Bingham wrote: > Quoting Tomi Valkeinen (2022-11-17 12:25:46) >> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> >> >> Add DSI support for r8a779g0. The main differences to r8a779a0 are in >> the PLL and PHTW setups. >> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> >> --- >> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 484 +++++++++++++++---- >> drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h | 6 +- >> 2 files changed, 384 insertions(+), 106 deletions(-) >> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c >> index a7f2b7f66a17..723c35726c38 100644 >> --- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c >> +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c >> @@ -9,6 +9,7 @@ >> #include <linux/delay.h> >> #include <linux/io.h> >> #include <linux/iopoll.h> >> +#include <linux/math64.h> >> #include <linux/module.h> >> #include <linux/of.h> >> #include <linux/of_device.h> >> @@ -28,6 +29,20 @@ >> #include "rcar_mipi_dsi.h" >> #include "rcar_mipi_dsi_regs.h" >> >> +#define MHZ(v) ((v) * 1000000u) >> + >> +enum rcar_mipi_dsi_hw_model { >> + RCAR_DSI_R8A779A0, >> + RCAR_DSI_R8A779G0, >> +}; >> + >> +struct rcar_mipi_dsi_device_info { >> + enum rcar_mipi_dsi_hw_model model; >> + const struct dsi_clk_config *clk_cfg; >> + u8 clockset2_m_offset; >> + u8 clockset2_n_offset; >> +}; >> + >> struct rcar_mipi_dsi { >> struct device *dev; >> const struct rcar_mipi_dsi_device_info *info; >> @@ -50,6 +65,17 @@ struct rcar_mipi_dsi { >> unsigned int lanes; >> }; >> >> +struct dsi_setup_info { >> + unsigned long hsfreq; >> + u16 hsfreqrange; >> + >> + unsigned long fout; >> + u16 m; >> + u16 n; >> + u16 vclk_divider; >> + const struct dsi_clk_config *clkset; >> +}; >> + >> static inline struct rcar_mipi_dsi * >> bridge_to_rcar_mipi_dsi(struct drm_bridge *bridge) >> { >> @@ -62,22 +88,6 @@ host_to_rcar_mipi_dsi(struct mipi_dsi_host *host) >> return container_of(host, struct rcar_mipi_dsi, host); >> } >> >> -static const u32 phtw[] = { >> - 0x01020114, 0x01600115, /* General testing */ >> - 0x01030116, 0x0102011d, /* General testing */ >> - 0x011101a4, 0x018601a4, /* 1Gbps testing */ >> - 0x014201a0, 0x010001a3, /* 1Gbps testing */ >> - 0x0101011f, /* 1Gbps testing */ >> -}; >> - >> -static const u32 phtw2[] = { >> - 0x010c0130, 0x010c0140, /* General testing */ >> - 0x010c0150, 0x010c0180, /* General testing */ >> - 0x010c0190, >> - 0x010a0160, 0x010a0170, >> - 0x01800164, 0x01800174, /* 1Gbps testing */ >> -}; >> - >> static const u32 hsfreqrange_table[][2] = { >> { 80000000U, 0x00 }, { 90000000U, 0x10 }, { 100000000U, 0x20 }, >> { 110000000U, 0x30 }, { 120000000U, 0x01 }, { 130000000U, 0x11 }, >> @@ -103,24 +113,53 @@ static const u32 hsfreqrange_table[][2] = { >> { /* sentinel */ }, >> }; >> >> -struct vco_cntrl_value { >> +struct dsi_clk_config { >> u32 min_freq; >> u32 max_freq; >> - u16 value; >> + u8 vco_cntrl; >> + u8 cpbias_cntrl; >> + u8 gmp_cntrl; >> + u8 int_cntrl; >> + u8 prop_cntrl; >> }; >> >> -static const struct vco_cntrl_value vco_cntrl_table[] = { >> - { .min_freq = 40000000U, .max_freq = 55000000U, .value = 0x3f }, >> - { .min_freq = 52500000U, .max_freq = 80000000U, .value = 0x39 }, >> - { .min_freq = 80000000U, .max_freq = 110000000U, .value = 0x2f }, >> - { .min_freq = 105000000U, .max_freq = 160000000U, .value = 0x29 }, >> - { .min_freq = 160000000U, .max_freq = 220000000U, .value = 0x1f }, >> - { .min_freq = 210000000U, .max_freq = 320000000U, .value = 0x19 }, >> - { .min_freq = 320000000U, .max_freq = 440000000U, .value = 0x0f }, >> - { .min_freq = 420000000U, .max_freq = 660000000U, .value = 0x09 }, >> - { .min_freq = 630000000U, .max_freq = 1149000000U, .value = 0x03 }, >> - { .min_freq = 1100000000U, .max_freq = 1152000000U, .value = 0x01 }, >> - { .min_freq = 1150000000U, .max_freq = 1250000000U, .value = 0x01 }, >> +static const struct dsi_clk_config dsi_clk_cfg_r8a779a0[] = { >> + { 40000000u, 55000000u, 0x3f, 0x10, 0x01, 0x00, 0x0b }, >> + { 52500000u, 80000000u, 0x39, 0x10, 0x01, 0x00, 0x0b }, >> + { 80000000u, 110000000u, 0x2f, 0x10, 0x01, 0x00, 0x0b }, >> + { 105000000u, 160000000u, 0x29, 0x10, 0x01, 0x00, 0x0b }, >> + { 160000000u, 220000000u, 0x1f, 0x10, 0x01, 0x00, 0x0b }, >> + { 210000000u, 320000000u, 0x19, 0x10, 0x01, 0x00, 0x0b }, >> + { 320000000u, 440000000u, 0x0f, 0x10, 0x01, 0x00, 0x0b }, >> + { 420000000u, 660000000u, 0x09, 0x10, 0x01, 0x00, 0x0b }, >> + { 630000000u, 1149000000u, 0x03, 0x10, 0x01, 0x00, 0x0b }, >> + { 1100000000u, 1152000000u, 0x01, 0x10, 0x01, 0x00, 0x0b }, >> + { 1150000000u, 1250000000u, 0x01, 0x10, 0x01, 0x00, 0x0c }, > > Sigh ... is it this one 0x0c value that means we need to keep all these > entries repeated ? :-S > > If it weren't for that, it seems we could keep just two sets of >> + u8 cpbias_cntrl; >> + u8 gmp_cntrl; >> + u8 int_cntrl; >> + u8 prop_cntrl; > > One for each of the 9a0, and the 9g0... > > But this is fine, and I guess the implication is there may be other > future differences to come in other platforms. > > It could be refactored then when we have more visibility. Yes, it's not so nice. And afaiu some of these values should really be solved dynamically in the code. But the docs list these tables and don't explain how to come up with those values, so... I think having these tables is the safest way. >> @@ -427,8 +671,21 @@ static int rcar_mipi_dsi_startup(struct rcar_mipi_dsi *dsi, >> dev_warn(dsi->dev, "unsupported format"); >> return -EINVAL; >> } >> - vclkset |= VCLKSET_COLOR_RGB | VCLKSET_DIV(setup_info.div) >> - | VCLKSET_LANE(dsi->lanes - 1); >> + >> + vclkset |= VCLKSET_COLOR_RGB | VCLKSET_LANE(dsi->lanes - 1); >> + >> + switch (dsi->info->model) { >> + case RCAR_DSI_R8A779A0: >> + vclkset |= VCLKSET_DIV_R8A779A0(__ffs(setup_info.vclk_divider)); >> + break; >> + >> + case RCAR_DSI_R8A779G0: >> + vclkset |= VCLKSET_DIV_R8A779G0(__ffs(setup_info.vclk_divider) - 1); > > Why is this a -1 here ? Seems an odd difference compared to the A0. You need to ask the HW designers =). That's how the register is on G0. Field value of 0 means divided by 2. Tomi
next prev parent reply other threads:[~2022-11-22 8:50 UTC|newest] Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-17 12:25 [PATCH v1 0/8] Renesas V4H DSI & DP output support Tomi Valkeinen 2022-11-17 12:25 ` Tomi Valkeinen 2022-11-17 12:25 ` [PATCH v1 1/8] dt-bindings: display: renesas,du: Provide bindings for r8a779g0 Tomi Valkeinen 2022-11-17 12:25 ` [PATCH v1 1/8] dt-bindings: display: renesas, du: " Tomi Valkeinen 2022-11-17 13:56 ` [PATCH v1 1/8] dt-bindings: display: renesas,du: " Kieran Bingham 2022-11-17 13:56 ` [PATCH v1 1/8] dt-bindings: display: renesas, du: " Kieran Bingham 2022-11-17 18:07 ` [PATCH v1 1/8] dt-bindings: display: renesas,du: " Krzysztof Kozlowski 2022-11-17 18:07 ` [PATCH v1 1/8] dt-bindings: display: renesas, du: " Krzysztof Kozlowski 2022-11-22 2:44 ` [PATCH v1 1/8] dt-bindings: display: renesas,du: " Laurent Pinchart 2022-11-22 2:44 ` Laurent Pinchart 2022-11-17 12:25 ` [PATCH v1 2/8] dt-bindings: display: bridge: renesas,dsi-csi2-tx: Add r8a779g0 Tomi Valkeinen 2022-11-17 12:25 ` [PATCH v1 2/8] dt-bindings: display: bridge: renesas, dsi-csi2-tx: " Tomi Valkeinen 2022-11-17 13:58 ` [PATCH v1 2/8] dt-bindings: display: bridge: renesas,dsi-csi2-tx: " Kieran Bingham 2022-11-17 13:58 ` [PATCH v1 2/8] dt-bindings: display: bridge: renesas, dsi-csi2-tx: " Kieran Bingham 2022-11-17 15:14 ` Geert Uytterhoeven 2022-11-17 15:14 ` [PATCH v1 2/8] dt-bindings: display: bridge: renesas,dsi-csi2-tx: " Geert Uytterhoeven 2022-11-22 2:45 ` Laurent Pinchart 2022-11-22 2:45 ` Laurent Pinchart 2022-11-22 8:20 ` Tomi Valkeinen 2022-11-22 8:20 ` [PATCH v1 2/8] dt-bindings: display: bridge: renesas, dsi-csi2-tx: " Tomi Valkeinen 2022-11-22 8:55 ` [PATCH v1 2/8] dt-bindings: display: bridge: renesas,dsi-csi2-tx: " Geert Uytterhoeven 2022-11-22 8:55 ` [PATCH v1 2/8] dt-bindings: display: bridge: renesas, dsi-csi2-tx: " Geert Uytterhoeven 2022-11-17 18:07 ` [PATCH v1 2/8] dt-bindings: display: bridge: renesas,dsi-csi2-tx: " Krzysztof Kozlowski 2022-11-17 18:07 ` [PATCH v1 2/8] dt-bindings: display: bridge: renesas, dsi-csi2-tx: " Krzysztof Kozlowski 2022-11-17 12:25 ` [PATCH v1 3/8] clk: renesas: r8a779g0: Add display related clocks Tomi Valkeinen 2022-11-17 12:25 ` Tomi Valkeinen 2022-11-17 14:08 ` Kieran Bingham 2022-11-17 14:08 ` Kieran Bingham 2022-11-22 2:52 ` Laurent Pinchart 2022-11-22 2:52 ` Laurent Pinchart 2022-11-17 12:25 ` [PATCH v1 4/8] arm64: dts: renesas: r8a779g0: Add display related data Tomi Valkeinen 2022-11-17 12:25 ` Tomi Valkeinen 2022-11-17 15:03 ` Kieran Bingham 2022-11-17 15:03 ` Kieran Bingham 2022-11-22 3:00 ` Laurent Pinchart 2022-11-22 3:00 ` Laurent Pinchart 2022-11-22 8:35 ` Tomi Valkeinen 2022-11-22 8:35 ` Tomi Valkeinen 2022-11-17 12:25 ` [PATCH v1 5/8] arm64: dts: renesas: white-hawk-cpu: Add DP output support Tomi Valkeinen 2022-11-17 12:25 ` Tomi Valkeinen 2022-11-17 15:05 ` Kieran Bingham 2022-11-17 15:05 ` Kieran Bingham 2022-11-22 3:01 ` Laurent Pinchart 2022-11-22 3:01 ` Laurent Pinchart 2022-11-17 12:25 ` [PATCH v1 6/8] drm: rcar-du: Add r8a779g0 support Tomi Valkeinen 2022-11-17 12:25 ` Tomi Valkeinen 2022-11-17 15:08 ` Kieran Bingham 2022-11-17 15:08 ` Kieran Bingham 2022-11-22 3:05 ` Laurent Pinchart 2022-11-22 3:05 ` Laurent Pinchart 2022-11-22 8:42 ` Tomi Valkeinen 2022-11-22 8:42 ` Tomi Valkeinen 2022-11-17 12:25 ` [PATCH v1 7/8] drm: rcar-du: dsi: Add r8A779g0 support Tomi Valkeinen 2022-11-17 12:25 ` Tomi Valkeinen 2022-11-17 15:46 ` Kieran Bingham 2022-11-17 15:46 ` Kieran Bingham 2022-11-17 15:49 ` Tomi Valkeinen 2022-11-17 15:49 ` Tomi Valkeinen 2022-11-17 15:56 ` Kieran Bingham 2022-11-17 15:56 ` Kieran Bingham 2022-11-22 8:50 ` Tomi Valkeinen [this message] 2022-11-22 8:50 ` Tomi Valkeinen 2022-11-29 0:43 ` Laurent Pinchart 2022-11-29 0:43 ` Laurent Pinchart 2022-11-29 6:57 ` Tomi Valkeinen 2022-11-29 6:57 ` Tomi Valkeinen 2022-11-17 12:25 ` [PATCH v1 8/8] HACK: drm: rcar-du: dsi: use-extal-clk hack Tomi Valkeinen 2022-11-17 12:25 ` Tomi Valkeinen 2022-11-17 12:28 ` [PATCH v1 0/8] Renesas V4H DSI & DP output support Tomi Valkeinen 2022-11-17 12:28 ` Tomi Valkeinen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4481a3fe-63a9-39d5-5394-a2f2639f1bcc@ideasonboard.com \ --to=tomi.valkeinen@ideasonboard.com \ --cc=andrzej.hajda@intel.com \ --cc=devicetree@vger.kernel.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=geert+renesas@glider.be \ --cc=jernej.skrabec@gmail.com \ --cc=jonas@kwiboo.se \ --cc=kieran.bingham+renesas@ideasonboard.com \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=magnus.damm@gmail.com \ --cc=neil.armstrong@linaro.org \ --cc=robert.foss@linaro.org \ --cc=robh+dt@kernel.org \ --cc=tomi.valkeinen+renesas@ideasonboard.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.