From: Jani Nikula <jani.nikula@linux.intel.com>
To: Maxime Ripard <mripard@kernel.org>,
Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@gmail.com>,
quic_abhinavk@quicinc.com, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org,
Thomas Zimmermann <tzimmermann@suse.de>,
Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH RFC 0/4] Support for Simulated Panels
Date: Wed, 17 Jan 2024 12:16:14 +0200 [thread overview]
Message-ID: <87cyu0qn81.fsf@intel.com> (raw)
In-Reply-To: <x6wi5xnihnbpqsujjfjfw3ft6njncruta5l3xa44pds5oxmdkw@mmvv4bciy65s>
On Wed, 17 Jan 2024, Maxime Ripard <mripard@kernel.org> wrote:
> Hi,
>
> On Tue, Jan 16, 2024 at 02:22:03PM -0800, Jessica Zhang wrote:
>> This series introduces a simulated MIPI DSI panel.
>>
>> Currently, the only way to validate DSI connectors is with a physical
>> panel. Since obtaining physical panels for all possible DSI configurations
>> is logistically infeasible, introduce a way for DSI drivers to simulate a
>> panel.
>>
>> This will be helpful in catching DSI misconfiguration bugs and catching
>> performance issues for high FPS panels that might not be easily
>> obtainable.
>>
>> For now, the simulated panel driver only supports setting customized
>> modes via the panel_simlation.mode modparam. Eventually, we would like
>> to add more customizations (such as configuring DSC, dual DSI, etc.).
>
> I think that it's more complicated than it needs to be.
Both too complicated and not complicated enough! :p
> Why do we need to support (and switch to) both the actual and
> "simulated" panel?
>
> Wouldn't it be simpler if we had a vkms-like panel that we could either
> configure from DT or from debugfs that would just be registered the
> usual way and would be the only panel we register?
I get the idea of trying to test DSI code without panels, and looking at
the goals above, I think your vkms suggestion is going to fall short of
those goals.
However, my gut feeling is that creating a simulated panel to catch DSI
misconfiguration etc. is going to be insanely complicated, and this
series doesn't even scratch the surface.
I guess my questions are, what's the scope here really, are those goals
realistic, does more code already exist beyond this skeleton?
BR,
Jani.
--
Jani Nikula, Intel
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Maxime Ripard <mripard@kernel.org>,
Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Sam Ravnborg <sam@ravnborg.org>,
quic_abhinavk@quicinc.com, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, Daniel Vetter <daniel@ffwll.ch>,
David Airlie <airlied@gmail.com>
Subject: Re: [PATCH RFC 0/4] Support for Simulated Panels
Date: Wed, 17 Jan 2024 12:16:14 +0200 [thread overview]
Message-ID: <87cyu0qn81.fsf@intel.com> (raw)
In-Reply-To: <x6wi5xnihnbpqsujjfjfw3ft6njncruta5l3xa44pds5oxmdkw@mmvv4bciy65s>
On Wed, 17 Jan 2024, Maxime Ripard <mripard@kernel.org> wrote:
> Hi,
>
> On Tue, Jan 16, 2024 at 02:22:03PM -0800, Jessica Zhang wrote:
>> This series introduces a simulated MIPI DSI panel.
>>
>> Currently, the only way to validate DSI connectors is with a physical
>> panel. Since obtaining physical panels for all possible DSI configurations
>> is logistically infeasible, introduce a way for DSI drivers to simulate a
>> panel.
>>
>> This will be helpful in catching DSI misconfiguration bugs and catching
>> performance issues for high FPS panels that might not be easily
>> obtainable.
>>
>> For now, the simulated panel driver only supports setting customized
>> modes via the panel_simlation.mode modparam. Eventually, we would like
>> to add more customizations (such as configuring DSC, dual DSI, etc.).
>
> I think that it's more complicated than it needs to be.
Both too complicated and not complicated enough! :p
> Why do we need to support (and switch to) both the actual and
> "simulated" panel?
>
> Wouldn't it be simpler if we had a vkms-like panel that we could either
> configure from DT or from debugfs that would just be registered the
> usual way and would be the only panel we register?
I get the idea of trying to test DSI code without panels, and looking at
the goals above, I think your vkms suggestion is going to fall short of
those goals.
However, my gut feeling is that creating a simulated panel to catch DSI
misconfiguration etc. is going to be insanely complicated, and this
series doesn't even scratch the surface.
I guess my questions are, what's the scope here really, are those goals
realistic, does more code already exist beyond this skeleton?
BR,
Jani.
--
Jani Nikula, Intel
next prev parent reply other threads:[~2024-01-17 10:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 22:22 [PATCH RFC 0/4] Support for Simulated Panels Jessica Zhang
2024-01-16 22:22 ` Jessica Zhang
2024-01-16 22:22 ` [PATCH RFC 1/4] drm/panel: add driver for simulated panel Jessica Zhang
2024-01-16 22:22 ` Jessica Zhang
2024-01-24 1:54 ` Dmitry Baryshkov
2024-01-24 1:54 ` Dmitry Baryshkov
2024-01-16 22:22 ` [PATCH RFC 2/4] drm/dsi: Add API to register simulated DSI panel Jessica Zhang
2024-01-16 22:22 ` Jessica Zhang
2024-01-16 22:22 ` [PATCH RFC 3/4] drm/panel: Introduce simulated panel bridge API Jessica Zhang
2024-01-16 22:22 ` Jessica Zhang
2024-01-16 22:22 ` [PATCH RFC 4/4] drm/msm/dsi: Add simulated panel support Jessica Zhang
2024-01-16 22:22 ` Jessica Zhang
2024-01-18 17:23 ` Dmitry Baryshkov
2024-01-18 17:23 ` Dmitry Baryshkov
2024-01-17 9:26 ` [PATCH RFC 0/4] Support for Simulated Panels Maxime Ripard
2024-01-17 9:26 ` Maxime Ripard
2024-01-17 10:16 ` Jani Nikula [this message]
2024-01-17 10:16 ` Jani Nikula
2024-01-17 17:36 ` Abhinav Kumar
2024-01-17 17:36 ` Abhinav Kumar
2024-01-26 12:45 ` Maxime Ripard
2024-01-26 12:45 ` Maxime Ripard
2024-01-29 19:05 ` Abhinav Kumar
2024-01-29 19:05 ` Abhinav Kumar
2024-01-30 8:53 ` Daniel Vetter
2024-01-30 8:53 ` Daniel Vetter
2024-02-02 10:15 ` Maxime Ripard
2024-02-28 21:49 ` Jessica Zhang
2024-02-29 10:45 ` Daniel Vetter
2024-02-02 10:12 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cyu0qn81.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=quic_abhinavk@quicinc.com \
--cc=quic_jesszhan@quicinc.com \
--cc=sam@ravnborg.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.