lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 17 May 2023 15:04:29 +0200
From:   Paulo <pavacic.p@...il.com>
To:     Jagan Teki <jagan@...rulasolutions.com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        neil.armstrong@...aro.org, conor+dt@...nel.org,
        devicetree@...r.kernel.org, sam@...nborg.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org
Subject: Re: [PATCH v2] dt-bindings: display: panel: add
 panel-mipi-dsi-bringup

On Wed, May 17 2023 at 05:50:22 PM +0530, Jagan Teki
<jagan@...rulasolutions.com> wrote:
 > Just to add a few pieces of information for you to understand better
 > on the context of dsi panels. DSI panels can be part of 
panel-simple.c
 > or panel-<vendor-part>.c DSI panels whose init and exit sequence is
 > generic are suitable to add it in panel-simple and have bindings on
 > panel-simple.yml.

This panel doesn't fit that well into panel-simple.c since it has
initialization sequence. For that reason it would fit more into
panel-sortofsimple.c which didn't exist so I have created new driver
and called it panel-mipi-dsi-bringup.c.

 > Some DSI panels have specific init and exit
 > sequences in terms of power, reset and DCS then those have separate
 > drivers to handle and whose driver name must be panel-<vendor-part>.c
 > or similar and bindings also follow a similar naming convention.

I have made a driver exactly for that purpose. Driver that allows
adding new panels which have specific init sequences (and of course 
timings and other stuff). fannal,c3004 can be seen as a working example.

Here is code snippet from the driver:
```
static const struct brup_panel_info brup_fannal_c3004_panel_info = {
 .display_mode = &brup_fannal_c3004_display_mode,
 .num_of_dsi_lanes = 2, //how many wires are connected to the panel
 .video_mode = BRUP_VIDEO_MODES[BRUP_SYNC_PULSE],
 .mipi_dsi_format = MIPI_DSI_FMT_RGB888,
 .mipi_dsi_mode_flags =
  MIPI_DSI_CLOCK_NON_CONTINUOUS | MIPI_DSI_MODE_VSYNC_FLUSH |
  MIPI_DSI_MODE_VIDEO_HSE | MIPI_DSI_MODE_NO_EOT_PACKET,
 .bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
 .panel_enable_function = &brup_panel_fannal_c3004_enable_function
};
```
where enable function is function with init sequence and other values 
are values that might be different for different displays.

All the inputs are appreciated as this is my first time submitting 
patch. If you see anything that is odd to you please reach out to me.
All in all I believe I now understand how should device tree look and 
the reasons/ideology behind it.

Best regards,
Paulo



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ