public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Mikko Perttunen <mperttunen@nvidia.com>
To: Svyatoslav Ryhel <clamor95@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Thierry Reding <treding@nvidia.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Prashant Gaikwad <pgaikwad@nvidia.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Dmitry Osipenko <digetx@gmail.com>,
	dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-clk@vger.kernel.org
Subject: Re: [PATCH v1 5/5] ARM: tegra: add MIPI calibration binding for Tegra20/Tegra30
Date: Wed, 23 Jul 2025 10:57:38 +0900	[thread overview]
Message-ID: <4377642.OBFZWjSADL@senjougahara> (raw)
In-Reply-To: <CAPVz0n1f=bAHqZiF3yMGS2T5Bg6C=CbJbLCGQMGfiAqK1YVzFg@mail.gmail.com>

On Friday, July 18, 2025 6:26 PM Svyatoslav Ryhel wrote:
> пт, 18 лип. 2025 р. о 12:22 Mikko Perttunen <mperttunen@nvidia.com> пише:
> > On Friday, July 18, 2025 6:15 PM Svyatoslav Ryhel wrote:
> > > пт, 18 лип. 2025 р. о 12:01 Mikko Perttunen <mperttunen@nvidia.com> 
пише:
> > > > On Thursday, July 17, 2025 11:21 PM Svyatoslav Ryhel wrote:
> > > > > Add MIPI calibration device node for Tegra20 and Tegra30.
> > > > > 
> > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > ---
> > > > > 
> > > > >  arch/arm/boot/dts/nvidia/tegra20.dtsi | 14 ++++++++++++++
> > > > >  arch/arm/boot/dts/nvidia/tegra30.dtsi | 18 ++++++++++++++++++
> > > > >  2 files changed, 32 insertions(+)
> > > > > 
> > > > > diff --git a/arch/arm/boot/dts/nvidia/tegra20.dtsi
> > > > > b/arch/arm/boot/dts/nvidia/tegra20.dtsi index
> > > > > 92d422f83ea4..521261045cc8
> > > > > 100644
> > > > > --- a/arch/arm/boot/dts/nvidia/tegra20.dtsi
> > > > > +++ b/arch/arm/boot/dts/nvidia/tegra20.dtsi
> > > > > @@ -74,6 +74,16 @@ vi@54080000 {
> > > > > 
> > > > >                       status = "disabled";
> > > > >               
> > > > >               };
> > > > > 
> > > > > +             /* DSI MIPI calibration logic is a part of VI/CSI */
> > > > > +             mipi: mipi@54080220 {
> > > > > +                     compatible = "nvidia,tegra20-mipi";
> > > > > +                     reg = <0x54080220 0x100>;
> > > > > +                     clocks = <&tegra_car TEGRA20_CLK_VI>,
> > > > > +                              <&tegra_car TEGRA20_CLK_CSI>;
> > > > > +                     clock-names = "vi", "csi";
> > > > > +                     #nvidia,mipi-calibrate-cells = <1>;
> > > > > +             };
> > > > > +
> > > > 
> > > > As you say in the comment, MIPI calibration on Tegra20/30 is part of
> > > > VI/CSI. We can't add a "mipi" device here since such a device doesn't
> > > > exist in the hardware hierarchy. We already have the VI device in the
> > > > device tree, so we need to use that.
> > > 
> > > I understand your point, but embedding MIPI calibration logic into
> > > VI/CSI driver will bring up another lever of unnecessary complexity
> > > and excessive coding. While approach I have proposed preserves
> > > separation between CSI and DSI and reuses already existing MIPI
> > > calibration framework.
> > 
> > We can consider different driver architectures to simplify things, but the
> > device tree has to conform to hardware. The host1x bus has no 'mipi'
> > device on it so we can't put one in the device tree.
> 
> I assume then placing mipi node as CSI or VI child would resolve your
> concern?

The device tree is not intended to follow software architecture. Having a 
separate device node implies some sort of bus / parent-child hierarchy in 
hardware. So it seems a little difficult to justify.

In this case, it seems to me that it would be pretty easy to add/partially 
copy a small VI driver while integrating with the staging driver, based on how 
simple its probe function is. And given that you're planning on adding CSI 
support as well, utilizing the tegra-video driver seems like it's in the cards 
anyway.

Thanks,
Mikko

> > > > A driver for tegra20-vi already exists in
> > > > staging/drivers/media/tegra-video. We should aim not to break it.
> > > > Perhaps
> > > > bring it out of staging? (At least partially, but then why not the
> > > > whole
> > > > thing.)
> > > 
> > > It does not break VI/CSI, I have a WIP CSI implementation for
> > > Tegra20/Tegra30 which I hope to submit soon.
> > 
> > We have to use the tegra20-vi node as that matches hardware, and each node
> > can only be probed to one device, hence the issue.
> > 
> > Great to see a CSI driver!
> > 
> > Mikko
> > 
> > > > Thanks,
> > > > Mikko





      reply	other threads:[~2025-07-23  1:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-17 14:21 [PATCH v1 0/5] gpu/drm: tegra: add DSI support for Tegra20/Tegra30 Svyatoslav Ryhel
2025-07-17 14:21 ` [PATCH v1 1/5] dt-bindings: display: tegra: document MIPI calibration " Svyatoslav Ryhel
2025-07-17 14:21 ` [PATCH v1 2/5] clk: tegra20: reparent dsi clock to pll_d_out0 Svyatoslav Ryhel
2025-07-17 14:21 ` [PATCH v1 3/5] gpu/drm: host1x: mipi: add Tegra20/Tegra30 MIPI calibration logic Svyatoslav Ryhel
2025-07-18  9:11   ` Mikko Perttunen
2025-07-18  9:17     ` Svyatoslav Ryhel
2025-07-23  1:36       ` Mikko Perttunen
2025-08-16 14:36   ` Dmitry Osipenko
2025-07-17 14:21 ` [PATCH v1 4/5] gpu/drm: tegra: dsi: add support for Tegra20/Tegra30 Svyatoslav Ryhel
2025-07-18  9:15   ` Mikko Perttunen
2025-07-18  9:19     ` Svyatoslav Ryhel
2025-07-18  9:25       ` Mikko Perttunen
2025-07-17 14:21 ` [PATCH v1 5/5] ARM: tegra: add MIPI calibration binding " Svyatoslav Ryhel
2025-07-18  9:01   ` Mikko Perttunen
2025-07-18  9:15     ` Svyatoslav Ryhel
2025-07-18  9:22       ` Mikko Perttunen
2025-07-18  9:26         ` Svyatoslav Ryhel
2025-07-23  1:57           ` Mikko Perttunen [this message]

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=4377642.OBFZWjSADL@senjougahara \
    --to=mperttunen@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=clamor95@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=digetx@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jonathanh@nvidia.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=pgaikwad@nvidia.com \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=thierry.reding@gmail.com \
    --cc=treding@nvidia.com \
    --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