Re: [PATCH v12 00/18] drm: Add Samsung MIPI DSIM bridge

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 = <&reg_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 = <&reg_1V2>;
		vcc-supply = <&reg_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




[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux for Synopsys ARC Processors]    
  • [Linux on Unisoc (RDA Micro) SoCs]     [Linux Actions SoC]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  •   Powered by Linux