From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
To: Frieder Schrempf <frieder.schrempf@kontron.de>,
Marek Vasut <marex@denx.de>,
Jagan Teki <jagan@amarulasolutions.com>
Cc: Laurent.pinchart@ideasonboard.com, aford173@gmail.com,
andrzej.hajda@intel.com, dri-devel@lists.freedesktop.org,
inki.dae@samsung.com, kyungmin.park@samsung.com,
linux-amarula@amarulasolutions.com,
linux-arm-kernel@lists.infradead.org, linux-imx@nxp.com,
linux-samsung-soc@vger.kernel.org, m.szyprowski@samsung.com,
matteo.lisi@engicam.com, sw0312.kim@samsung.com,
tharvey@gateworks.com
Subject: Re: [PATCH v12 00/18] drm: Add Samsung MIPI DSIM bridge
Date: Tue, 7 Feb 2023 10:09:11 +0100 [thread overview]
Message-ID: <c9dc0b2b-8850-6227-163b-85c53c5d72ef@prevas.dk> (raw)
In-Reply-To: <1745c43d-06b4-933b-5dbd-50add565828e@kontron.de>
On 06/02/2023 09.11, Frieder Schrempf wrote:
> On 03.02.23 13:29, Rasmus Villemoes wrote:
>> On 01/02/2023 23.00, Marek Vasut wrote:
>>> On 1/30/23 13:45, Rasmus Villemoes wrote:
>>>> On 27/01/2023 12.30, Marek Vasut wrote:
>>>>> On 1/27/23 12:04, Jagan Teki wrote:
>>>>
>>>>>>> Thanks, but that's exactly what I'm doing, and I don't see any
>>>>>>> modification of imx8mp.dtsi in that branch. I'm basically looking for
>>>>>>> help to do the equivalent of
>>>>>>>
>>>>>>> 88775338cd58 - arm64: dts: imx8mm: Add MIPI DSI pipeline
>>>>>>> f964f67dd6ee - arm64: dts: imx8mm: Add eLCDIF node support
>>>>>>>
>>>>>>> for imx8mp in order to test those patches on our boards (we have two
>>>>>>> variants).
>>>>>>
>>>>>> Marek, any help here, thanks.
>>>>>
>>>>> Try attached patch.
>>>>
>>>> Thanks. I removed the lcdif2 and ldb nodes I had added from Alexander's
>>>> patch (94e6197dadc9 in linux-next) in order to apply it. I get a couple
>>>> of errors during boot:
>>>>
>>>> clk: /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to reparent
>>>> media_apb to sys_pll1_266m: -22
>>>>
>>>> and enabling a pr_debug in clk_core_set_parent_nolock() shows that this
>>>> is because
>>>>
>>>> clk_core_set_parent_nolock: clk sys_pll1_266m can not be parent of clk
>>>> media_apb
>>>>
>>>> Further, the mipi_dsi fails to probe due to
>>>>
>>>> /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to get
>>>> 'samsung,burst-clock-frequency' property
>>>>
>>>> All other .dtsi files seem to have those samsung,burst-clock-frequency
>>>> and samsung,esc-clock-frequency properties, so I suppose those should
>>>> also go into the imx8mp.dtsi and are not something that the board .dts
>>>> file should supply(?).
>>>
>>> No, that samsung,esc-clock-frequency (should be some 10-20 MHz, based on
>>> your panel/bridge) and samsung,burst-clock-frequency (that's the HS
>>> clock) should go into board DT, as those are property of the attached
>>> panel/bridge.
>>
>> OK.
>>
>> But I simply can't make that match what I see in that branch. For
>> example, there's imx8mm-icore-mx8mm-ctouch2-of10.dts and
>> imx8mm-icore-mx8mm-edimm2.2.dts which both seem to have a ti,sn65dsi84
>> bridge, neither override the values defined in imx8mm.dtsi, which are
>>
>> samsung,burst-clock-frequency = <891000000>;
>> samsung,esc-clock-frequency = <54000000>;
>>
>> and that 891MHz value seems to be out of range for the dsi84 bridge -
>> under Recommended Operating Conditions, the data sheet says "DSI HS
>> clock input frequency", min 40, max 500 MHz.
>
> Please note that the value in samsung,burst-clock-frequency is double
> the clock rate of the effective DSI HS clock. I can confirm that a
> SN65DSI84 is able to work with the default settings in general. Still
> the LVDS clock is derived from the DSI clock and the sn65dsi83 driver
> calculates its PLL values expecting a DSI input clock matching the panel
> mode. So you might have to tune this value.
>
Hm, but in my case, I don't have a DSI->LVDS bridge, but a
DSI->DisplayPort bridge (sn65dsi86), and I obviously don't and can't
know what monitor(s) will be attached at run-time.
I managed to get the whole chain lcdif -> mipi -> bridge -> dp-connector
to probe with these settings
display_port0: connector {
compatible = "dp-connector";
label = "DP0";
type = "full-size";
dp-pwr-supply = <®_DP_PWR>;
port {
dp_connector_in: endpoint {
remote-endpoint = <&sn65dsi86_out>;
};
};
};
eDP: bridge@2c {
compatible = "ti,sn65dsi86";
reg = <0x2c>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_eDP>;
interrupts-extended = <&gpio3 14 IRQ_TYPE_LEVEL_HIGH>;
enable-gpios = <&gpio3 9 GPIO_ACTIVE_HIGH>;
vpll-supply = <&VDD_1V8>;
vccio-supply = <&VDD_1V8>;
vcca-supply = <®_1V2>;
vcc-supply = <®_1V2>;
clocks = <&clk_38_4MHz>;
clock-names = "refclk";
#pwm-cells = <1>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
sn65dsi86_in_a: endpoint {
remote-endpoint = <&mipi_dsi_out>;
};
};
port@1 {
reg = <1>;
sn65dsi86_out: endpoint {
remote-endpoint = <&dp_connector_in>;
};
};
};
};
&mipi_dsi {
status = "okay";
samsung,burst-clock-frequency = <816000000>;
samsung,esc-clock-frequency = <60000000>;
ports {
port@1 {
reg = <1>;
mipi_dsi_out: endpoint {
remote-endpoint = <&sn65dsi86_in_a>;
};
};
};
};
&lcdif1 {
status = "okay";
};
Now hotplug-detect doesn't work with the current sn65dsi86 driver, but
that's a separate issue; when I boot with a monitor attached, its edid
is correctly read out. But I still don't get any output, and the monitor
says "no signal" - my naive attempt (which has worked fine in other
cases) was to just dd /dev/urandom to /dev/fb0, so I'm clearly missing
some important step.
Rasmus
WARNING: multiple messages have this Message-ID (diff)
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
To: Frieder Schrempf <frieder.schrempf@kontron.de>,
Marek Vasut <marex@denx.de>,
Jagan Teki <jagan@amarulasolutions.com>
Cc: Laurent.pinchart@ideasonboard.com, aford173@gmail.com,
andrzej.hajda@intel.com, dri-devel@lists.freedesktop.org,
inki.dae@samsung.com, kyungmin.park@samsung.com,
linux-amarula@amarulasolutions.com,
linux-arm-kernel@lists.infradead.org, linux-imx@nxp.com,
linux-samsung-soc@vger.kernel.org, m.szyprowski@samsung.com,
matteo.lisi@engicam.com, sw0312.kim@samsung.com,
tharvey@gateworks.com
Subject: Re: [PATCH v12 00/18] drm: Add Samsung MIPI DSIM bridge
Date: Tue, 7 Feb 2023 10:09:11 +0100 [thread overview]
Message-ID: <c9dc0b2b-8850-6227-163b-85c53c5d72ef@prevas.dk> (raw)
In-Reply-To: <1745c43d-06b4-933b-5dbd-50add565828e@kontron.de>
On 06/02/2023 09.11, Frieder Schrempf wrote:
> On 03.02.23 13:29, Rasmus Villemoes wrote:
>> On 01/02/2023 23.00, Marek Vasut wrote:
>>> On 1/30/23 13:45, Rasmus Villemoes wrote:
>>>> On 27/01/2023 12.30, Marek Vasut wrote:
>>>>> On 1/27/23 12:04, Jagan Teki wrote:
>>>>
>>>>>>> Thanks, but that's exactly what I'm doing, and I don't see any
>>>>>>> modification of imx8mp.dtsi in that branch. I'm basically looking for
>>>>>>> help to do the equivalent of
>>>>>>>
>>>>>>> 88775338cd58 - arm64: dts: imx8mm: Add MIPI DSI pipeline
>>>>>>> f964f67dd6ee - arm64: dts: imx8mm: Add eLCDIF node support
>>>>>>>
>>>>>>> for imx8mp in order to test those patches on our boards (we have two
>>>>>>> variants).
>>>>>>
>>>>>> Marek, any help here, thanks.
>>>>>
>>>>> Try attached patch.
>>>>
>>>> Thanks. I removed the lcdif2 and ldb nodes I had added from Alexander's
>>>> patch (94e6197dadc9 in linux-next) in order to apply it. I get a couple
>>>> of errors during boot:
>>>>
>>>> clk: /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to reparent
>>>> media_apb to sys_pll1_266m: -22
>>>>
>>>> and enabling a pr_debug in clk_core_set_parent_nolock() shows that this
>>>> is because
>>>>
>>>> clk_core_set_parent_nolock: clk sys_pll1_266m can not be parent of clk
>>>> media_apb
>>>>
>>>> Further, the mipi_dsi fails to probe due to
>>>>
>>>> /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to get
>>>> 'samsung,burst-clock-frequency' property
>>>>
>>>> All other .dtsi files seem to have those samsung,burst-clock-frequency
>>>> and samsung,esc-clock-frequency properties, so I suppose those should
>>>> also go into the imx8mp.dtsi and are not something that the board .dts
>>>> file should supply(?).
>>>
>>> No, that samsung,esc-clock-frequency (should be some 10-20 MHz, based on
>>> your panel/bridge) and samsung,burst-clock-frequency (that's the HS
>>> clock) should go into board DT, as those are property of the attached
>>> panel/bridge.
>>
>> OK.
>>
>> But I simply can't make that match what I see in that branch. For
>> example, there's imx8mm-icore-mx8mm-ctouch2-of10.dts and
>> imx8mm-icore-mx8mm-edimm2.2.dts which both seem to have a ti,sn65dsi84
>> bridge, neither override the values defined in imx8mm.dtsi, which are
>>
>> samsung,burst-clock-frequency = <891000000>;
>> samsung,esc-clock-frequency = <54000000>;
>>
>> and that 891MHz value seems to be out of range for the dsi84 bridge -
>> under Recommended Operating Conditions, the data sheet says "DSI HS
>> clock input frequency", min 40, max 500 MHz.
>
> Please note that the value in samsung,burst-clock-frequency is double
> the clock rate of the effective DSI HS clock. I can confirm that a
> SN65DSI84 is able to work with the default settings in general. Still
> the LVDS clock is derived from the DSI clock and the sn65dsi83 driver
> calculates its PLL values expecting a DSI input clock matching the panel
> mode. So you might have to tune this value.
>
Hm, but in my case, I don't have a DSI->LVDS bridge, but a
DSI->DisplayPort bridge (sn65dsi86), and I obviously don't and can't
know what monitor(s) will be attached at run-time.
I managed to get the whole chain lcdif -> mipi -> bridge -> dp-connector
to probe with these settings
display_port0: connector {
compatible = "dp-connector";
label = "DP0";
type = "full-size";
dp-pwr-supply = <®_DP_PWR>;
port {
dp_connector_in: endpoint {
remote-endpoint = <&sn65dsi86_out>;
};
};
};
eDP: bridge@2c {
compatible = "ti,sn65dsi86";
reg = <0x2c>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_eDP>;
interrupts-extended = <&gpio3 14 IRQ_TYPE_LEVEL_HIGH>;
enable-gpios = <&gpio3 9 GPIO_ACTIVE_HIGH>;
vpll-supply = <&VDD_1V8>;
vccio-supply = <&VDD_1V8>;
vcca-supply = <®_1V2>;
vcc-supply = <®_1V2>;
clocks = <&clk_38_4MHz>;
clock-names = "refclk";
#pwm-cells = <1>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
sn65dsi86_in_a: endpoint {
remote-endpoint = <&mipi_dsi_out>;
};
};
port@1 {
reg = <1>;
sn65dsi86_out: endpoint {
remote-endpoint = <&dp_connector_in>;
};
};
};
};
&mipi_dsi {
status = "okay";
samsung,burst-clock-frequency = <816000000>;
samsung,esc-clock-frequency = <60000000>;
ports {
port@1 {
reg = <1>;
mipi_dsi_out: endpoint {
remote-endpoint = <&sn65dsi86_in_a>;
};
};
};
};
&lcdif1 {
status = "okay";
};
Now hotplug-detect doesn't work with the current sn65dsi86 driver, but
that's a separate issue; when I boot with a monitor attached, its edid
is correctly read out. But I still don't get any output, and the monitor
says "no signal" - my naive attempt (which has worked fine in other
cases) was to just dd /dev/urandom to /dev/fb0, so I'm clearly missing
some important step.
Rasmus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
To: Frieder Schrempf <frieder.schrempf@kontron.de>,
Marek Vasut <marex@denx.de>,
Jagan Teki <jagan@amarulasolutions.com>
Cc: linux-samsung-soc@vger.kernel.org, matteo.lisi@engicam.com,
linux-amarula@amarulasolutions.com, sw0312.kim@samsung.com,
dri-devel@lists.freedesktop.org, kyungmin.park@samsung.com,
Laurent.pinchart@ideasonboard.com, andrzej.hajda@intel.com,
m.szyprowski@samsung.com, aford173@gmail.com,
linux-arm-kernel@lists.infradead.org, linux-imx@nxp.com
Subject: Re: [PATCH v12 00/18] drm: Add Samsung MIPI DSIM bridge
Date: Tue, 7 Feb 2023 10:09:11 +0100 [thread overview]
Message-ID: <c9dc0b2b-8850-6227-163b-85c53c5d72ef@prevas.dk> (raw)
In-Reply-To: <1745c43d-06b4-933b-5dbd-50add565828e@kontron.de>
On 06/02/2023 09.11, Frieder Schrempf wrote:
> On 03.02.23 13:29, Rasmus Villemoes wrote:
>> On 01/02/2023 23.00, Marek Vasut wrote:
>>> On 1/30/23 13:45, Rasmus Villemoes wrote:
>>>> On 27/01/2023 12.30, Marek Vasut wrote:
>>>>> On 1/27/23 12:04, Jagan Teki wrote:
>>>>
>>>>>>> Thanks, but that's exactly what I'm doing, and I don't see any
>>>>>>> modification of imx8mp.dtsi in that branch. I'm basically looking for
>>>>>>> help to do the equivalent of
>>>>>>>
>>>>>>> 88775338cd58 - arm64: dts: imx8mm: Add MIPI DSI pipeline
>>>>>>> f964f67dd6ee - arm64: dts: imx8mm: Add eLCDIF node support
>>>>>>>
>>>>>>> for imx8mp in order to test those patches on our boards (we have two
>>>>>>> variants).
>>>>>>
>>>>>> Marek, any help here, thanks.
>>>>>
>>>>> Try attached patch.
>>>>
>>>> Thanks. I removed the lcdif2 and ldb nodes I had added from Alexander's
>>>> patch (94e6197dadc9 in linux-next) in order to apply it. I get a couple
>>>> of errors during boot:
>>>>
>>>> clk: /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to reparent
>>>> media_apb to sys_pll1_266m: -22
>>>>
>>>> and enabling a pr_debug in clk_core_set_parent_nolock() shows that this
>>>> is because
>>>>
>>>> clk_core_set_parent_nolock: clk sys_pll1_266m can not be parent of clk
>>>> media_apb
>>>>
>>>> Further, the mipi_dsi fails to probe due to
>>>>
>>>> /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to get
>>>> 'samsung,burst-clock-frequency' property
>>>>
>>>> All other .dtsi files seem to have those samsung,burst-clock-frequency
>>>> and samsung,esc-clock-frequency properties, so I suppose those should
>>>> also go into the imx8mp.dtsi and are not something that the board .dts
>>>> file should supply(?).
>>>
>>> No, that samsung,esc-clock-frequency (should be some 10-20 MHz, based on
>>> your panel/bridge) and samsung,burst-clock-frequency (that's the HS
>>> clock) should go into board DT, as those are property of the attached
>>> panel/bridge.
>>
>> OK.
>>
>> But I simply can't make that match what I see in that branch. For
>> example, there's imx8mm-icore-mx8mm-ctouch2-of10.dts and
>> imx8mm-icore-mx8mm-edimm2.2.dts which both seem to have a ti,sn65dsi84
>> bridge, neither override the values defined in imx8mm.dtsi, which are
>>
>> samsung,burst-clock-frequency = <891000000>;
>> samsung,esc-clock-frequency = <54000000>;
>>
>> and that 891MHz value seems to be out of range for the dsi84 bridge -
>> under Recommended Operating Conditions, the data sheet says "DSI HS
>> clock input frequency", min 40, max 500 MHz.
>
> Please note that the value in samsung,burst-clock-frequency is double
> the clock rate of the effective DSI HS clock. I can confirm that a
> SN65DSI84 is able to work with the default settings in general. Still
> the LVDS clock is derived from the DSI clock and the sn65dsi83 driver
> calculates its PLL values expecting a DSI input clock matching the panel
> mode. So you might have to tune this value.
>
Hm, but in my case, I don't have a DSI->LVDS bridge, but a
DSI->DisplayPort bridge (sn65dsi86), and I obviously don't and can't
know what monitor(s) will be attached at run-time.
I managed to get the whole chain lcdif -> mipi -> bridge -> dp-connector
to probe with these settings
display_port0: connector {
compatible = "dp-connector";
label = "DP0";
type = "full-size";
dp-pwr-supply = <®_DP_PWR>;
port {
dp_connector_in: endpoint {
remote-endpoint = <&sn65dsi86_out>;
};
};
};
eDP: bridge@2c {
compatible = "ti,sn65dsi86";
reg = <0x2c>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_eDP>;
interrupts-extended = <&gpio3 14 IRQ_TYPE_LEVEL_HIGH>;
enable-gpios = <&gpio3 9 GPIO_ACTIVE_HIGH>;
vpll-supply = <&VDD_1V8>;
vccio-supply = <&VDD_1V8>;
vcca-supply = <®_1V2>;
vcc-supply = <®_1V2>;
clocks = <&clk_38_4MHz>;
clock-names = "refclk";
#pwm-cells = <1>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
sn65dsi86_in_a: endpoint {
remote-endpoint = <&mipi_dsi_out>;
};
};
port@1 {
reg = <1>;
sn65dsi86_out: endpoint {
remote-endpoint = <&dp_connector_in>;
};
};
};
};
&mipi_dsi {
status = "okay";
samsung,burst-clock-frequency = <816000000>;
samsung,esc-clock-frequency = <60000000>;
ports {
port@1 {
reg = <1>;
mipi_dsi_out: endpoint {
remote-endpoint = <&sn65dsi86_in_a>;
};
};
};
};
&lcdif1 {
status = "okay";
};
Now hotplug-detect doesn't work with the current sn65dsi86 driver, but
that's a separate issue; when I boot with a monitor attached, its edid
is correctly read out. But I still don't get any output, and the monitor
says "no signal" - my naive attempt (which has worked fine in other
cases) was to just dd /dev/urandom to /dev/fb0, so I'm clearly missing
some important step.
Rasmus
next prev parent reply other threads:[~2023-02-07 9:10 UTC|newest]
Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-26 14:44 [PATCH v12 00/18] drm: Add Samsung MIPI DSIM bridge Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 01/18] drm: of: Lookup if child node has DSI panel or bridge Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 02/18] drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:47 ` Maxime Ripard
2023-01-26 14:47 ` Maxime Ripard
2023-01-26 14:47 ` Maxime Ripard
2023-01-26 14:58 ` Jagan Teki
2023-01-26 14:58 ` Jagan Teki
2023-01-26 14:58 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 03/18] drm: exynos: dsi: Drop explicit call to bridge detach Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 04/18] drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 05/18] drm: exynos: dsi: Mark PHY as optional Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 06/18] drm: exynos: dsi: Add platform PLL_P (PMS_P) offset Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 07/18] drm: exynos: dsi: Introduce hw_type platform data Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 08/18] drm: exynos: dsi: Handle proper host initialization Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 09/18] drm: exynos: dsi: Add atomic check Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 10/18] drm: exynos: dsi: Add input_bus_flags Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 11/18] drm: exynos: dsi: Add atomic_get_input_bus_fmts Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 15:29 ` Marek Vasut
2023-01-26 15:29 ` Marek Vasut
2023-01-26 15:29 ` Marek Vasut
2023-01-26 14:44 ` [PATCH v12 12/18] drm: exynos: dsi: Consolidate component and bridge Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 13/18] drm: exynos: dsi: Add host helper for te_irq_handler Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 14/18] drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge Jagan Teki
2023-01-26 14:44 ` [PATCH v12 15/18] dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 16/18] drm: bridge: samsung-dsim: Add " Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 17/18] dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` [PATCH v12 18/18] drm: bridge: samsung-dsim: Add " Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-26 14:44 ` Jagan Teki
2023-01-27 10:33 ` [PATCH v12 00/18] drm: Add Samsung MIPI DSIM bridge Rasmus Villemoes
2023-01-27 10:33 ` Rasmus Villemoes
2023-01-27 10:33 ` Rasmus Villemoes
2023-01-27 10:39 ` Jagan Teki
2023-01-27 10:39 ` Jagan Teki
2023-01-27 10:39 ` Jagan Teki
2023-01-27 10:56 ` Rasmus Villemoes
2023-01-27 10:56 ` Rasmus Villemoes
2023-01-27 10:56 ` Rasmus Villemoes
2023-01-27 11:04 ` Jagan Teki
2023-01-27 11:04 ` Jagan Teki
2023-01-27 11:04 ` Jagan Teki
2023-01-27 11:30 ` Marek Vasut
2023-01-27 11:30 ` Marek Vasut
2023-01-27 11:30 ` Marek Vasut
2023-01-30 12:45 ` Rasmus Villemoes
2023-01-30 12:45 ` Rasmus Villemoes
2023-01-30 12:45 ` Rasmus Villemoes
2023-01-31 7:27 ` Alexander Stein
2023-01-31 7:27 ` Alexander Stein
2023-01-31 7:27 ` Alexander Stein
2023-02-01 22:00 ` Marek Vasut
2023-02-01 22:00 ` Marek Vasut
2023-02-01 22:00 ` Marek Vasut
2023-02-03 12:29 ` Rasmus Villemoes
2023-02-03 12:29 ` Rasmus Villemoes
2023-02-03 12:29 ` Rasmus Villemoes
2023-02-06 8:11 ` Frieder Schrempf
2023-02-06 8:11 ` Frieder Schrempf
2023-02-06 8:11 ` Frieder Schrempf
2023-02-07 9:09 ` Rasmus Villemoes [this message]
2023-02-07 9:09 ` Rasmus Villemoes
2023-02-07 9:09 ` Rasmus Villemoes
2023-02-07 9:23 ` Marek Vasut
2023-02-07 9:23 ` Marek Vasut
2023-02-07 9:23 ` Marek Vasut
2023-02-14 10:55 ` Rasmus Villemoes
2023-02-14 10:55 ` Rasmus Villemoes
2023-02-14 10:55 ` Rasmus Villemoes
2023-02-14 11:08 ` Rasmus Villemoes
2023-02-14 11:08 ` Rasmus Villemoes
2023-02-14 11:08 ` Rasmus Villemoes
2023-02-14 11:09 ` Fabio Estevam
2023-02-14 11:09 ` Fabio Estevam
2023-02-14 11:09 ` Fabio Estevam
2023-02-14 11:11 ` Fabio Estevam
2023-02-14 11:11 ` Fabio Estevam
2023-02-14 11:11 ` Fabio Estevam
2023-02-17 8:55 ` Rasmus Villemoes
2023-02-17 8:55 ` Rasmus Villemoes
2023-02-17 8:55 ` Rasmus Villemoes
2023-02-17 10:05 ` Alexander Stein
2023-02-17 10:05 ` Alexander Stein
2023-02-17 10:05 ` Alexander Stein
2023-02-17 18:22 ` Rasmus Villemoes
2023-02-17 18:22 ` Rasmus Villemoes
2023-02-17 18:22 ` Rasmus Villemoes
2023-02-22 10:05 ` Frieder Schrempf
2023-02-22 10:05 ` Frieder Schrempf
2023-02-22 10:05 ` Frieder Schrempf
2023-02-24 14:08 ` Rasmus Villemoes
2023-02-24 14:08 ` Rasmus Villemoes
2023-02-24 14:08 ` Rasmus Villemoes
2023-02-24 15:00 ` Adam Ford
2023-02-24 15:00 ` Adam Ford
2023-02-24 15:00 ` Adam Ford
2023-02-01 8:37 ` Frieder Schrempf
2023-02-01 8:37 ` Frieder Schrempf
2023-02-01 8:37 ` Frieder Schrempf
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=c9dc0b2b-8850-6227-163b-85c53c5d72ef@prevas.dk \
--to=rasmus.villemoes@prevas.dk \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=aford173@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=frieder.schrempf@kontron.de \
--cc=inki.dae@samsung.com \
--cc=jagan@amarulasolutions.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-amarula@amarulasolutions.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=marex@denx.de \
--cc=matteo.lisi@engicam.com \
--cc=sw0312.kim@samsung.com \
--cc=tharvey@gateworks.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: link
Be 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.