Open stefffe opened 6 months ago
The timing node is used differently in this driver:
The panel resolution is specified using the panel-timing node properties
hactive (width) and vactive (height). The other mandatory panel-timing
properties should be set to zero except clock-frequency which can be
optionally set to inform about the actual pixel clock frequency.
If the panel is wired to the controller at an offset specify this using
hback-porch (x-offset) and vback-porch (y-offset).
https://www.kernel.org/doc/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
Ah, yes! Removing the front-porch settings makes it all work. Thanks for the clarification!
Hey, I have a small Winstar 160x80 TFT LCD display that I wrote a custom driver for, but then I found this generic driver which seems to be a great option. I have however one issue. When adding my display, I use the following panel-timings for devicetree:
This is required since my display has both a back-poch and front-porch. But when inserting the above values and loading the driver, it bails out with:
panel-mipi-dbi-spi spi0.0: /n_ahb@e0000000/spi@e0011000/display@0: panel-timing out of bounds
So I read through the code, and found this check here which I do not fully understand:
Given the input above to devicetree, adding a few prints to the driver tells me during probe that the different values are:
The part of the panel-timing check above that always fails are:
mode->hsync_end > mode->hdisplay
(and corresponding vsync_end) Reading https://www.kernel.org/doc/Documentation/devicetree/bindings/display/panel/panel-timing.yaml leads me to believe that:If I change the check (replace hdisplay with htotal and vdisplay with vtotal), then the driver loads perfectly fine and my display works exactly as it should, with correct back-porch etc.
Now, is this a bug, or am I completely misunderstanding something here? :o)
Best Regards Stefan Nilsson