[PATCH v4 0/3] Add support for the Sony IMX681 camera sensor

[Sergey Lebedev <lsa.uz@pm.me>]

The Sony IMX681 is the user-facing camera on the Microsoft Surface Pro 11 for
Business (Intel Lunar Lake, IPU7), enumerated as ACPI device SONY0681. Without
a driver the camera does not appear at all - not as a degraded device, not at
all.

  1/3  dt-bindings: media: Add Sony IMX681            (mine)
  2/3  media: i2c: Add Sony IMX681 sensor driver      (Andre Gilerson's)
  3/3  media: ipu-bridge: Add Sony IMX681             (mine)

The driver is Andre's work, reverse-engineered from I2C traces taken under
Windows. I am carrying the submission, not the code: his Signed-off-by is on
2/3 with mine beneath it as the person passing it on.

Changes in v4
=============

All three are Krzysztof Kozlowski's, from his review of v3 on 11 September.

  - MAINTAINERS: the T: line is gone. He is right that neither Andre nor I
    have commit rights to that tree, and the line was ours rather than his -
    the MAINTAINERS hunk went in with v2.

  - dev_err() followed by a return is now dev_err_probe(). He flagged one
    site, at the CCI init. The same shape was in twelve others on the probe
    path, so all thirteen are converted rather than only the one he quoted.
    Seven further sites are left alone, in imx681_start_streaming(),
    imx681_stop_streaming() and imx681_power_on(): dev_err_probe() is wrong
    outside probe, and power_on() is reached from runtime-PM resume as well
    as from probe, so it is not a probe path even though probe calls it.

  - The clock-rate dev_dbg is gone. clk_summary says it.

Nothing else changed. No behaviour changes except that the converted sites
now return the error through dev_err_probe() instead of beside it.

Trailers, and a correction I owe
================================

Krzysztof's Reviewed-by is on 1/3, and on 1/3 only.

German Pablo Lindo's Tested-by is on 2/3 and never on 1/3, per Krzysztof's
"Just remember that Tested-by does not apply here".

The correction, in the open because the error was: the v3 cover letter called
the tester by a surname I had taken from his email address rather than from
him. It was wrong. His name is German Pablo Lindo, and the Tested-by below is
his own wording.

Andre, and why this goes out before your ack
============================================

Krzysztof asked that Andre ack the binding, since it names him as maintainer.
That is properly his and he is away until 28 September, so this version does
not have it.

It goes now anyway, for a reason that is about the tags rather than about
impatience: patchwork.linuxtv.org populates its tags field for nobody on this
instance - not for our two patches and not for four accepted ones I checked
against today - so a maintainer applying from patchwork picks up neither
trailer.
They exist in the lore archive and in these commit messages, and nowhere else.
A v4 is the only thing that carries them.

Andre - the ack is yours whenever you are back, and nothing here needs it in
order to be read or reviewed.

Not addressed by this version: nobody has commented on 2/3 or 3/3 yet, and
the mirroring question raised against v3 is still open with Sakari, Dan and
Hans. If any of that lands, it lands in v5.

Checked
=======

checkpatch --strict, sparse and W=1 are all clean on 2/3 and 3/3. 1/3's only
checkpatch warning asks whether MAINTAINERS needs updating, which 2/3 does.

Built and run on the machine rather than only compiled: the driver probes,
ipu-bridge binds it at 3844x2640 over two lanes at 969.6 MHz per lane, and
captured frames render as a coherent image rather than as noise.

Limitations
===========

  error paths       The regulator get succeeds here because INT3472 hands out
                    dummies for dvdd and dovdd, so the fatal path is reasoned
                    rather than exercised.

  IVSC              None of the IVSC HIDs is present on this machine, so
                    sensor->csi_dev is NULL and ipu-bridge never enters those
                    paths.

  one machine       One Surface Pro 11 and one sensor sample. German has the
                    same HID on another machine but reaches IPU7 through the
                    staging driver, which is a second path rather than a
                    second test of this one.

  one mode          3844x2640 SGRBG10 at 969.6 MHz per lane is the only
                    configuration the driver has, and the only one measured.

  no sanitisers     Not built with KASAN or lockdep. That is a kernel rebuild
                    here rather than a problem, so ask if it would help.

Based on media/next at aedd77ea8168 ("media: qcom: camss: use
fwnode_graph_for_each_endpoint_scoped() to simplify code"). That branch
rewinds - v3's declared base is no longer in it either - so if this does not
apply where you are, say so and I will rebase rather than guess.

German reported this HID as a bug on this list on 3 September and has had no
reply since; he is on Cc here.

  https://lore.kernel.org/linux-media/20260903080854.16266-1-germanpapulindez@gmail.com/
-- 
2.54.0 (Apple Git-157)