From: Boris Brezillon <boris.brezillon@collabora.com>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: devicetree@vger.kernel.org,
Laura Nixon <laura.nixon@team.mipi.org>,
Rob Herring <robh+dt@kernel.org>,
Robert Gough <robert.gough@intel.com>,
Matthew Schnoor <matthew.schnoor@intel.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
linux-i3c@lists.infradead.org
Subject: Re: [PATCH 2/2] i3c/master: add the mipi-i3c-hci driver
Date: Thu, 20 Aug 2020 19:14:24 +0200 [thread overview]
Message-ID: <20200820191424.29c42972@collabora.com> (raw)
In-Reply-To: <nycvar.YSQ.7.78.906.2008201234370.1479@knanqh.ubzr>
On Thu, 20 Aug 2020 12:47:49 -0400 (EDT)
Nicolas Pitre <nico@fluxnic.net> wrote:
> On Thu, 20 Aug 2020, Boris Brezillon wrote:
>
> > On Thu, 20 Aug 2020 10:08:29 +0200
> > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > > > + /*
> > > > + * TODO: Extend the subsystem layer to allow for registering
> > > > + * new device and provide BCR/DCR/PID at the same time.
> > >
> > > Not sure this is needed if you don't use it directly as the core will
> > > anyway (in its current form) send the relevant CCC to read these
> > > registers.
> >
> > We considered optimizing that in the past but that means making the DAA
> > and SETDASA registration different. I'm not sure it's worth it to be
> > honest, PID/DCR/BCR only happens when initializing devices and I
> > suspect the overhead of querying those DATA twice in case of DAA is
> > negligible anyway.
>
> Wellllll... I know some people who do feel strongly about this
> particular issue for some reasons.
Mind developing a bit why? Boot-time maybe?
> So I'd prefer giving them some hope
> and leave the door open to some i3c_master_add_i3c_dev_and_info()
> interface. In the end, it's just a matter of pre-filling the info struct
> and skipping the PID retrieval in i3c_master_getpid_locked() if already
> available, etc.
I'm definitely not closing the door, but I'd like to understand why this
is so important to them :-). Anyway, if the changes are not invasive, I
don't have a good reason to refuse it.
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
linux-i3c@lists.infradead.org, devicetree@vger.kernel.org,
Laura Nixon <laura.nixon@team.mipi.org>,
Robert Gough <robert.gough@intel.com>,
Rob Herring <robh+dt@kernel.org>,
Matthew Schnoor <matthew.schnoor@intel.com>
Subject: Re: [PATCH 2/2] i3c/master: add the mipi-i3c-hci driver
Date: Thu, 20 Aug 2020 19:14:24 +0200 [thread overview]
Message-ID: <20200820191424.29c42972@collabora.com> (raw)
In-Reply-To: <nycvar.YSQ.7.78.906.2008201234370.1479@knanqh.ubzr>
On Thu, 20 Aug 2020 12:47:49 -0400 (EDT)
Nicolas Pitre <nico@fluxnic.net> wrote:
> On Thu, 20 Aug 2020, Boris Brezillon wrote:
>
> > On Thu, 20 Aug 2020 10:08:29 +0200
> > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > > > + /*
> > > > + * TODO: Extend the subsystem layer to allow for registering
> > > > + * new device and provide BCR/DCR/PID at the same time.
> > >
> > > Not sure this is needed if you don't use it directly as the core will
> > > anyway (in its current form) send the relevant CCC to read these
> > > registers.
> >
> > We considered optimizing that in the past but that means making the DAA
> > and SETDASA registration different. I'm not sure it's worth it to be
> > honest, PID/DCR/BCR only happens when initializing devices and I
> > suspect the overhead of querying those DATA twice in case of DAA is
> > negligible anyway.
>
> Wellllll... I know some people who do feel strongly about this
> particular issue for some reasons.
Mind developing a bit why? Boot-time maybe?
> So I'd prefer giving them some hope
> and leave the door open to some i3c_master_add_i3c_dev_and_info()
> interface. In the end, it's just a matter of pre-filling the info struct
> and skipping the PID retrieval in i3c_master_getpid_locked() if already
> available, etc.
I'm definitely not closing the door, but I'd like to understand why this
is so important to them :-). Anyway, if the changes are not invasive, I
don't have a good reason to refuse it.
next prev parent reply other threads:[~2020-08-20 17:14 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-14 3:48 [PATCH 0/2] MIPI I3c HCI (Host Controller Interface) driver Nicolas Pitre
2020-08-14 3:48 ` Nicolas Pitre
2020-08-14 3:48 ` [PATCH 1/2] dt-bindings: i3c: MIPI I3C Host Controller Interface Nicolas Pitre
2020-08-14 3:48 ` Nicolas Pitre
2020-08-14 18:07 ` Rob Herring
2020-08-14 18:07 ` Rob Herring
2020-08-14 3:48 ` [PATCH 2/2] i3c/master: add the mipi-i3c-hci driver Nicolas Pitre
2020-08-14 3:48 ` Nicolas Pitre
2020-08-14 5:52 ` kernel test robot
2020-08-14 5:52 ` kernel test robot
2020-08-14 5:52 ` kernel test robot
2020-08-14 5:53 ` kernel test robot
2020-08-14 5:53 ` kernel test robot
2020-08-14 5:53 ` kernel test robot
2020-08-16 3:57 ` kernel test robot
2020-08-16 3:57 ` kernel test robot
2020-08-16 3:57 ` kernel test robot
2020-08-20 8:08 ` Miquel Raynal
2020-08-20 8:08 ` Miquel Raynal
2020-08-20 8:39 ` Boris Brezillon
2020-08-20 8:39 ` Boris Brezillon
2020-08-20 16:47 ` Nicolas Pitre
2020-08-20 16:47 ` Nicolas Pitre
2020-08-20 17:14 ` Boris Brezillon [this message]
2020-08-20 17:14 ` Boris Brezillon
2020-08-20 18:44 ` Nicolas Pitre
2020-08-20 18:44 ` Nicolas Pitre
2020-08-20 16:34 ` Nicolas Pitre
2020-08-20 16:34 ` Nicolas Pitre
2020-08-20 16:56 ` Boris Brezillon
2020-08-20 16:56 ` Boris Brezillon
2020-08-20 18:22 ` Nicolas Pitre
2020-08-20 18:22 ` Nicolas Pitre
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=20200820191424.29c42972@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=laura.nixon@team.mipi.org \
--cc=linux-i3c@lists.infradead.org \
--cc=matthew.schnoor@intel.com \
--cc=miquel.raynal@bootlin.com \
--cc=nico@fluxnic.net \
--cc=robert.gough@intel.com \
--cc=robh+dt@kernel.org \
/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.