[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251018141551.3e5c46c1@jic23-huawei>
Date: Sat, 18 Oct 2025 14:15:51 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc: Frank Li <Frank.Li@....com>, Miquel Raynal <miquel.raynal@...tlin.com>,
David Lechner <dlechner@...libre.com>, Nuno Sá
<nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>, Rob Herring
<robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, linux-i3c@...ts.infradead.org,
linux-kernel@...r.kernel.org, imx@...ts.linux.dev,
linux-iio@...r.kernel.org, joshua.yeong@...rfivetech.com,
devicetree@...r.kernel.org, Carlos Song <carlos.song@....com>, Adrian
Fluturel <fluturel.adrian@...il.com>
Subject: Re: [PATCH v5 0/5] i3c: Add basic HDR mode support
On Mon, 13 Oct 2025 21:54:55 +0200
Alexandre Belloni <alexandre.belloni@...tlin.com> wrote:
> On 12/10/2025 18:03:27+0100, Jonathan Cameron wrote:
> > On Tue, 07 Oct 2025 16:06:12 -0400
> > Frank Li <Frank.Li@....com> wrote:
> >
> > > Add basic HDR mode support, only support private transfer, not support
> > > CCC command.
> > >
> > > Update i3c framework API to allow pass down mode and extend driver callback
> > > function.
> > >
> > > Implement HDR transfer in svc i3c master driver.
> > >
> > > Simplifed HDR flow is (ref i3c spec line 5514) Figure 129
> > >
> > > <-- SDR ---> | <--- HDR
> > > START 0x7E RnW(0) ACK CCC(ENTHDR0) T HDR-CMD(00-7f write, 80--ff read)
> > >
> > > ----> |
> > > HDR-DATA HDR-CRC HDR-RESTART .... HDR-EXIT
> > >
> > > Note: HDR-CMD is 16bit data, which included 7bit slave address and 8bit
> > > read/write command.
> > >
> > > svc hardware can auto issue SDR part.
> > >
> > > Signed-off-by: Frank Li <Frank.Li@....com>
> >
> > Whilst there will probably have to be a v6 for the ACPI ID issue in patch 5,
> > I'd like to ask the question of how are we planning to merge this?
> >
> > Maybe an immutable branch either in IIO or I3C trees that the other one picks up?
> >
> > It's a new driver so could gamble on taking the IIO driver the I3C tree but even
> > then I'd like a topic / immutable branch in case any IIO wide refactors or similar
> > hit this cycle.
> >
>
> I can definitively provide an immutable branch once this goes in or if
> you are more comfortable with this, I guess there is no urgency and we
> could apply this over two cycles, first the I3C part and then you can
> take the driver.
>
Mostly because I'm really forgetful and hence don't like tracking stuff over
multiple cycles, I'd prefer an immutable once all patches are ready to go.
Thanks,
Jonathan
>
Powered by blists - more mailing lists