[Letux-kernel] OMAP5: inconsistency between target-module and dsi_of_data_omap5

H. Nikolaus Schaller hns at goldelico.com
Sun Jul 5 15:47:37 CEST 2020


> Am 05.07.2020 um 09:40 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> Am 05.07.2020 um 08:52 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>> Hi Tony,
>> since v5.7-rc1 our Pyra (OMAP5) dsi panel doesn't initialize and we do not
>> get a /dev/fb0.
>> 
>> There is a suspicious log message:
>> 
>> [   15.352314] DSI: omapdss DSI error: unsupported DSI module
>> 
>> I could trace it down to be likely a discrepancy between
>> 
>> target-module at 58000000 { 
>> 
>> ...
>> 
>> 				target-module at 5000 {
>> 					compatible = "ti,sysc-omap2", "ti,sysc";
>> 					reg = <0x5000 0x4>,
>> ...
>> 					ranges = <0 0x5000 0x1000>;
>> 
>> 					dsi1: encoder at 0 {
>> 						compatible = "ti,omap5-dsi";
>> 
>> 				target-module at 9000 {
>> 					compatible = "ti,sysc-omap2", "ti,sysc";
>> 					reg = <0x9000 0x4>,
>> 					      <0x9010 0x4>,
>> 					      <0x9014 0x4>;
>> 
>> ...
>> 
>> 					ranges = <0 0x9000 0x1000>;
>> 
>> 					dsi2: encoder at 0 {
>> 						compatible = "ti,omap5-dsi";
>> 						reg = <0 0x200>,
>> 						      <0x200 0x40>,
>> 						      <0x300 0x40>;
>> 
>> 
>> 
>> and
>> 
>> static const struct dsi_of_data dsi_of_data_omap5 = {
>> 	.model = DSI_MODEL_OMAP5,
>> 	.pll_hw = &dss_omap5_dsi_pll_hw,
>> 	.modules = (const struct dsi_module_id_data[]) {
>> 		{ .address = 0x58004000, .id = 0, },
>> 		{ .address = 0x58009000, .id = 1, },
>> 		{ },
>> 	},
>> 
>> Therefore the address match logic in dsi_probe() fails and ends in
>> the mentioned log message.
>> 
>> Looking at git blame, the DTS was recently changed by 5a507162f096b54.
>> Commit 98e1a6a86a22d62 did do a similar change for dsi2 but did not
>> modify the address.
>> 
>> So I wonder if the 0x5000 is just a typo or if there is something
>> where the dsi1: encoder at 0 should have a negative offset to end
>> up at address 0x58004000?
>> 
>> BR and thanks,
>> Nikolaus
>> 
> 
> This patch makes the DSI error go away and omapdrm initialized:
> 
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index e147121513e644..b9f54f62163879 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -474,7 +474,7 @@ rfbi: encoder at 0  {
>                                        };
>                                };
> 
> -                               target-module at 5000 {
> +                               target-module at 4000 {
>                                        compatible = "ti,sysc-omap2", "ti,sysc";
>                                        reg = <0x5000 0x4>,
>                                              <0x5010 0x4>,
> @@ -490,7 +490,7 @@ SYSC_OMAP2_SOFTRESET |
>                                        ti,syss-mask = <1>;
>                                        #address-cells = <1>;
>                                        #size-cells = <1>;
> -                                       ranges = <0 0x5000 0x1000>;
> +                                       ranges = <0 0x4000 0x1000>;
> 
>                                        dsi1: encoder at 0 {
>                                                compatible = "ti,omap5-dsi";
> 
> But I still have no display:
> 
> [   17.537515] [drm] Initialized omapdrm 1.0.0 20110917 for omapdrm.0 on minor 2
> [   18.558950] omapdrm omapdrm.0: [drm] Cannot find any crtc or sizes
> 
> So there is more to fix.

A little more info:

on v5.7 I see:

[   13.850883] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dispc_component_ops [omapdss])
[   13.885714] omapdss_dss 58000000.dss: bound 58040000.encoder (ops hdmi5_component_ops [omapdss])

while on v5.6:

[   14.997890] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dsi_vc_flush_receive_data [omapdss])
[   15.007726] omapdss_dss 58000000.dss: bound 58004000.encoder (ops dsi_vc_flush_receive_data [omapdss])
[   15.026118] omapdss_dss 58000000.dss: bound 58040000.encoder (ops dsi_vc_flush_receive_data [omapdss])

So the dsi1 encoder isn't properly bound.

BR,
Nikolaus


More information about the Letux-kernel mailing list