public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Besse <besse@motama.com>
To: unlisted-recipients:; (no To-header on input)@bombadil.infradead.org
Cc: linux-media@vger.kernel.org
Subject: Re: Order of dvb devices
Date: Mon, 18 Jan 2010 09:58:42 +0100	[thread overview]
Message-ID: <4B5422C2.5010203@motama.com> (raw)
In-Reply-To: <1a297b361001151508h42d3a4c9wdbc09b6199319c2a@mail.gmail.com>

Manu Abraham wrote:
> On Sat, Jan 16, 2010 at 3:00 AM, Oliver Endriss <o.endriss@gmx.de> wrote:
>   
>> Devin Heitmueller wrote:
>>     
>>> On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse <besse@motama.com> wrote:
>>>       
>>>> yes if there are different drivers I already observed the behaviour that
>>>> the ordering gets flipped after reboot.
>>>>
>>>> But if I assume, that there is only *one* driver that is loaded (e.g.
>>>> budget_av) for all dvb cards in the system, how is the ordering of these
>>>> devices determined? How does the driver "search" for available dvb cards?
>>>>         
>> The driver does not 'search' for a card. The driver registers the ids of
>> all supported cards with the pci subsystem of the kernel.
>>
>> When the pci subsystem detects a new card, it calls the 'probe' routine
>> of the driver (for example saa7146_init_one for saa7146-based cards).
>> So the ordering is determined by the pci subsystem.
>>
>>     
>>> I believe your assumption is incorrect.  I believe the enumeration
>>> order is not deterministic even for multiple instances of the same
>>> driver.  It is not uncommon to hear mythtv users complain that "I have
>>> two PVR-150 cards installed in my PC and the order sometimes get
>>> reversed on reboot".
>>>       
>> Afaik the indeterministic behaviour is caused by udev, not by the
>> kernel. We never had these problems before udev was introduced.
>>     
>
>
> True, the ordering is not exactly the same everytime. One will need to
> provide PCI Bus related info also to a practical udev configuration to
> get things sorted out in a sane way, rather than anything else.
>   
with "PCI Bus related info" you mean the KERNELS parameter which is
reported by udevinfo?

udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0)
[...]
  looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:08:00.0':
    KERNELS=="0000:08:00.0"
    SUBSYSTEMS=="pci"

does this KERNELS parameter always match the Slot-Id of "lspci -vmm" ?
Slot:   08:00.0
Class:  Multimedia controller
Vendor: Philips Semiconductors
Device: SAA7146
SVendor:        Technotrend Systemtechnik GmbH
SDevice:        S2-3200
Rev:    01

is it right that the Slot-Id is deterministic for PCI/PCIe based systems?






  parent reply	other threads:[~2010-01-18  8:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-14 15:35 Order of dvb devices Andreas Besse
2010-01-14 15:46 ` Devin Heitmueller
2010-01-14 16:01   ` Andreas Besse
2010-01-14 16:09     ` Devin Heitmueller
2010-01-14 17:19       ` Michael Krufky
2010-01-15 23:00       ` Oliver Endriss
2010-01-15 23:05         ` Devin Heitmueller
2010-01-15 23:08         ` Manu Abraham
2010-01-16  6:50           ` Mika Laitio
2010-01-18  8:58           ` Andreas Besse [this message]
2010-01-18 10:32             ` Manu Abraham
2010-01-18 13:16               ` Andreas Besse
2010-01-15 23:12         ` hermann pitton
  -- strict thread matches above, loose matches on Subject: below --
2010-01-16  8:36 Dan Taylor

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=4B5422C2.5010203@motama.com \
    --to=besse@motama.com \
    --cc=linux-media@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox