mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Vinod Koul <vkoul@kernel.org>,
	Bard Liao <yung-chuan.liao@linux.intel.com>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	bard.liao@intel.com
Subject: Re: [PATCH 0/3] soundwire: allocate device_number with IDA
Date: Wed, 24 Aug 2022 09:42:22 +0200	[thread overview]
Message-ID: <6a9ad9b1-a6f2-c380-77a9-f10317f7054f@linux.intel.com> (raw)
In-Reply-To: <YwUHp3ivSktx6/Lo@matsya>

Hi Vinod,

>> The device_number is currently allocated in the scope of each bus and does
>> not need to be unique at the system level.
>> This leads e.g. on Dell devices with three or four Device1 on different
>> bus segments. 
> 
> And how is that an issue that should be fixed?

1. this makes things simpler for debug. You can look at the logs and see
what the device is without having to look at the link. It's been much
easier to track complicated issues when each device is tracked with a
unique system level number.

2. Intel hardware has a requirement that the device number be unique for
all links managed by  a given controller. This patch prepares that
transition. I cannot disclose more details at the moment, you will have
to trust me on this one.

>> To make the device_number unique at the system level, and
> 
> Why should we do that...
>> unified with the HDaudio/iDISP SDI values, this series allocates the
>> dev_number with an IDA restricted between 4 and 11 (inclusive).
> 
> Does this not place an artificial restriction that a system can have
> only 12 devices if we have unique device

It does indeed, but it simplifies debug and it allows future hardware to
be supported.

In practice, the most we've seen on Intel platforms is 4 devices at the
system level. Even if the SoundWire spec does allow for 11 devices per
link, it's way over-engineered due to capacitive load and signal
integrity issues. We've seen an absolute maximum of 4 devices on a
single link in test rigs, and that was never deployed. Two devices per
link were also only used in prototypes which never hit the market.

At any rate, this in an opt-in solution, not a requirement for non-Intel
platforms at all. Others can keep using as many devices as they wish,
within the bounds allowed by the standard.

Note that the device_number creates a de-facto priority, and it would be
perfectly acceptable for some platforms to tweak the current first-come
first-serve allocation to improve interrupt response time on each link,
etc. The standard says nothing about how the device numbers should be
allocated, only that they be unique on each link. In other words, you
should expect additional changes to the existing way of allocating
device numbers.

> Perhaps a better way would be to use dus:dev combination while dealing
> with a device always..??

That is not compatible with Intel hardware requirements. This wasn't a
decision where Bard and I were consulted, it is what it is.

Does this clarify things?
Thanks
-Pierre



  reply	other threads:[~2022-08-24  7:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-23  4:50 Bard Liao
2022-08-23  4:50 ` [PATCH 1/3] soundwire: bus: rename sdw_ida as sdw_bus_ida Bard Liao
2022-08-23  4:50 ` [PATCH 2/3] soundwire: bus: allow device number to be unique at system level Bard Liao
2022-08-23  4:50 ` [PATCH 3/3] soundwire: intel: set dev_num_ida_min Bard Liao
2022-08-23 17:00 ` [PATCH 0/3] soundwire: allocate device_number with IDA Vinod Koul
2022-08-24  7:42   ` Pierre-Louis Bossart [this message]
2022-08-30  4:46 ` Vinod Koul
  -- strict thread matches above, loose matches on Subject: below --
2022-07-13 14:25 Bard Liao

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=6a9ad9b1-a6f2-c380-77a9-f10317f7054f@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=bard.liao@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vkoul@kernel.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

all inboxes | Powered by JetHome®