From: Vinod Koul <vkoul@kernel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: alsa-devel@alsa-project.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
sanyog.r.kale@intel.com, yung-chuan.liao@linux.intel.com
Subject: Re: [PATCH] soundwire: debugfs: use controller id instead of link_id
Date: Wed, 3 Feb 2021 16:44:09 +0530 [thread overview]
Message-ID: <20210203111409.GM2771@vkoul-mobl> (raw)
In-Reply-To: <6eebbadd-d26b-9dba-f425-01988fb64bec@linux.intel.com>
On 02-02-21, 10:43, Pierre-Louis Bossart wrote:
>
>
> On 2/1/21 10:18 PM, Vinod Koul wrote:
> > On 01-02-21, 10:10, Pierre-Louis Bossart wrote:
> > > On 2/1/21 4:14 AM, Vinod Koul wrote:
> > > > On 21-01-21, 17:23, Srinivas Kandagatla wrote:
> > > > > On 21/01/2021 15:12, Pierre-Louis Bossart wrote:
> > > > > > On 1/21/21 6:03 AM, Srinivas Kandagatla wrote:
> >
> > > > > I totally agree!
> > > > >
> > > > > If I understand it correctly in Intel case there will be only one Link ID
> > > > > per bus.
> > > >
> > > > Yes IIUC there would be one link id per bus.
> > > >
> > > > the ida approach gives us unique id for each master,bus I would like to
> > > > propose using that everywhere
> > >
> > > We have cases where link2 is not used but link0, 1 and 3 are.
> > > Using the IDA would result in master-0,1,2 being shown, that would throw the
> > > integrator off. the link_id is related to hardware and can tolerate gaps,
> > > the IDA is typically always increasing and is across the system, not
> > > controller specific.
> > >
> > > We can debate forever but both pieces of information are useful, so my
> > > recommendation is to use both:
> > >
> > > snprintf(name, sizeof(name), "master-%d-%d", bus_id, bus->link_id);
> >
> > I agree we should use both, but does it really make sense for naming? We
> > can keep name in ida and expose the link_id as a parameter for
> > integrators to see in sysfs.
>
> That would mean changing the meaning of sysfs properties:
>
> /*
> * The sysfs for properties reflects the MIPI description as given
> * in the MIPI DisCo spec
> *
> * Base file is:
> * sdw-master-N
Key is "The sysfs for properties" is for property files. I am not sure
how this implies for a number above. I was thinking of using ID for N
here and add a link_id file below which represents the link-id property
> * |---- revision
> * |---- clk_stop_modes
> * |---- max_clk_freq
> * |---- clk_freq
> * |---- clk_gears
> * |---- default_row
> * |---- default_col
> * |---- dynamic_shape
> * |---- err_threshold
> */
>
> N is the link ID in the spec. I am not convinced we'd do the community a
> service by unilaterally changing what an external spec means, or add a
> property that's kernel-defined while the rest is supposed to come from
> firmware. If you want to change the spec then you can contribute feedback in
> MIPI circles (MIPI have a mechanism for maintainers to provide such feedback
> without company/employer membership requirements)
>
> So either we add a sysfs layer that represents a controller (better in my
> opinion so that we can show the link/master count), or keep the existing
> hierarchy but expand the name with a unique ID so that Qualcomm don't get
> errors with duplicate sysfs link0 entries.
Anyway we are late in cycle for this.. I am reverting this patch and we
can arrive at consensus and fix this for next cycle
Thanks
--
~Vinod
next prev parent reply other threads:[~2021-02-03 11:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-15 16:25 [PATCH] soundwire: debugfs: use controller id instead of link_id Srinivas Kandagatla
2021-01-19 14:52 ` Vinod Koul
2021-01-19 15:54 ` Pierre-Louis Bossart
2021-01-19 17:17 ` Srinivas Kandagatla
2021-01-19 19:09 ` Pierre-Louis Bossart
2021-01-21 12:03 ` Srinivas Kandagatla
2021-01-21 15:12 ` Pierre-Louis Bossart
2021-01-21 17:23 ` Srinivas Kandagatla
2021-01-21 18:22 ` Pierre-Louis Bossart
2021-02-01 10:14 ` Vinod Koul
2021-02-01 16:10 ` Pierre-Louis Bossart
2021-02-02 4:18 ` Vinod Koul
2021-02-02 16:43 ` Pierre-Louis Bossart
2021-02-03 11:14 ` Vinod Koul [this message]
2021-02-06 10:22 ` Vinod Koul
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=20210203111409.GM2771@vkoul-mobl \
--to=vkoul@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=sanyog.r.kale@intel.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=yung-chuan.liao@linux.intel.com \
/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;
as well as URLs for NNTP newsgroup(s).