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@58000000 {
...
target-module@5000 {
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x5000 0x4>,
...
ranges = <0 0x5000 0x1000>;
dsi1: encoder@0 {
compatible = "ti,omap5-dsi";
target-module@9000 {
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x9000 0x4>,
<0x9010 0x4>,
<0x9014 0x4>;
...
ranges = <0 0x9000 0x1000>;
dsi2: encoder@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@0 should have a negative offset to end
up at address 0x58004000?
BR and thanks,
Nikolaus