mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeffrey Hugo <quic_jhugo@quicinc.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Jessica Zhang <quic_jesszhan@quicinc.com>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-msm@vger.kernel.org>,
	<linux-rockchip@lists.infradead.org>
Subject: Re: [PATCH v3 0/3] drm/panel-edp: remove several legacy compatibles used by the driver
Date: Fri, 31 May 2024 10:51:16 -0600	[thread overview]
Message-ID: <197777e0-e6e1-7004-be27-edb98f8a235e@quicinc.com> (raw)
In-Reply-To: <CAD=FV=Xcq-p5OxSnDJVF-Wp88ZfXOaOKJmh941ymy-f0wkhdhw@mail.gmail.com>

On 5/31/2024 10:20 AM, Doug Anderson wrote:
> Hi,
> 
> On Fri, May 31, 2024 at 9:18 AM Jeffrey Hugo <quic_jhugo@quicinc.com> wrote:
>>
>> On 5/30/2024 5:12 PM, Dmitry Baryshkov wrote:
>>> There are two ways to describe an eDP panel in device tree. The
>>> recommended way is to add a device on the AUX bus, ideally using the
>>> edp-panel compatible. The legacy way is to define a top-level platform
>>> device for the panel.
>>>
>>> Document that adding support for eDP panels in a legacy way is strongly
>>> discouraged (if not forbidden at all).
>>>
>>> While we are at it, also drop legacy compatible strings and bindings for
>>> five panels. These compatible strings were never used by a DT file
>>> present in Linux kernel and most likely were never used with the
>>> upstream Linux kernel.
>>>
>>> The following compatibles were never used by the devices supported by
>>> the upstream kernel and are a subject to possible removal:
>>>
>>> - lg,lp097qx1-spa1
>>> - samsung,lsn122dl01-c01
>>> - sharp,ld-d5116z01b
>>
>> Ok to drop the sharp one I added.  It should be able to be handled by
>> the (newish) edp-panel, but I think the TI bridge driver needs some work
>> for the specific platform (no I2C connection) to verify.
> 
> Is the platform supported upstream? If so, which platform is it? Is
> the TI bridge chip the ti-sn65dsi86? If so, I'm confused how you could
> use that bridge chip without an i2c connection, but perhaps I'm
> misunderstanding. :-P

Yes, the platform is upstream.  The 8998 laptops (clamshell).  It is the 
ti-sn65si86.  I suspect the I2C connection was not populated for cost 
reasons, then determined its much more convenient to have it as every 
generation after that I've seen has the I2C.

If you check the datasheet closely, the I2C connection is optional.  You 
can also configure the bridge inband using DSI commands.  This is what 
the FW and Windows does.

So, the DT binding needs to make the I2C property optional (this should 
be backwards compatible).  The driver needs to detect that the I2C 
connection is not provided, and fall back to DSI commands.  Regmap would 
be nice for this, but I got pushback on the proposal.  Then I got 
sidetracked looking at other issues.

-Jeff


  reply	other threads:[~2024-05-31 16:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-30 23:12 Dmitry Baryshkov
2024-05-30 23:12 ` [PATCH v3 1/3] drm/panel-edp: add fat warning against adding new panel compatibles Dmitry Baryshkov
2024-05-30 23:12 ` [PATCH v3 2/3] dt-bindings: display: panel-simple: drop several eDP panels Dmitry Baryshkov
2024-05-30 23:12 ` [PATCH v3 3/3] drm/panel-edp: drop several legacy panels Dmitry Baryshkov
2024-05-30 23:16 ` [PATCH v3 0/3] drm/panel-edp: remove several legacy compatibles used by the driver Doug Anderson
2024-05-30 23:25   ` Dmitry Baryshkov
2024-05-31 16:18 ` Jeffrey Hugo
2024-05-31 16:20   ` Doug Anderson
2024-05-31 16:51     ` Jeffrey Hugo [this message]
2024-05-31 17:29       ` Doug Anderson
2024-05-31 17:43   ` Dmitry Baryshkov
2024-05-31 17:46     ` Jeffrey Hugo

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=197777e0-e6e1-7004-be27-edb98f8a235e@quicinc.com \
    --to=quic_jhugo@quicinc.com \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dianders@chromium.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®