I have a problem with identifying device class/subclass of PCI audio
device.
The ado_pci structure appears to contains something called ‘class’ but
it is 8 bit long and is always 0. The ‘Class’ member of pci_dev_info is
32bit long, but even if I read it directly, using
pci_read_config(ado_pci->handle, 12, 1, 4, &class) then its value for
audio card is 0x4000.
Looking at hw/pci.h, it defines PCI_CLASS_MULTIMEDIA as 0x00040000,
which is not exactly 0x4000. Why? Then there are subclasses defined,
what I am looking is PCI_SUBCLASS_MULTIMEDIA_AUDIO, which is 0x100 in
pci.h. Where is it? My problem is, some audio cards can have codec/modem
integrated and apparently (looking at Linux code) it would appear as PCI
device with same device ID as audio chip, so driver is checking subclass
to filter it out.
Does ado_pci_device() filter out inappropriate subclasses already? If
not, how do I get subclass?
Thanks,
Igor Kovalenko wrote:
I have a problem with identifying device class/subclass of PCI audio
device.
The ado_pci structure appears to contains something called ‘class’ but
it is 8 bit long and is always 0. The ‘Class’ member of pci_dev_info is
32bit long, but even if I read it directly, using
pci_read_config(ado_pci->handle, 12, 1, 4, &class) then its value for
audio card is 0x4000.
I figured I am looking at wrong structure and class+subclass field in
_pci_config_regs is really 3 bytes, not 4. However the question remains
what is ‘class’ in ado_pci structure (why it is always 0?) and if
there’s ‘class’ and ‘revision’ then why no ‘subclass’ byte? This seems
illogical…
Thanks,
Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:
I figured I am looking at wrong structure and class+subclass field in
_pci_config_regs is really 3 bytes, not 4. However the question remains
what is ‘class’ in ado_pci structure (why it is always 0?) and if
there’s ‘class’ and ‘revision’ then why no ‘subclass’ byte? This seems
illogical…
The ado_pci_device() function uses the pci_attach_device()
to attach to the vendor & device specified and then returns
a subset of that connection information in the ado_pci
struct.
So the abreviated code looks like:
{
struct pci_dev_info inf
…
if ((pci->handle = pci_attach_device (NULL, PCI_SEARCH_VENDEV |
PCI_MASTER_ENABLE | PCI_INIT_ALL, index, &inf)) == NULL)
…
pci->class = inf.Class;
…
}
You’ll need to ask the pci experts as to why the class is
not what you expect as they probably don’t read this group.
“Audio Support” <audio_support@qnx.com> wrote in message
news:9nqd4f$4rr$1@nntp.qnx.com…
Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
The ado_pci_device() function uses the pci_attach_device()
to attach to the vendor & device specified and then returns
a subset of that connection information in the ado_pci
struct.
So the abreviated code looks like:
{
struct pci_dev_info inf
…
if ((pci->handle = pci_attach_device (NULL, PCI_SEARCH_VENDEV |
PCI_MASTER_ENABLE | PCI_INIT_ALL, index, &inf)) == NULL)
…
pci->class = inf.Class;
…
}
You’ll need to ask the pci experts as to why the class is
not what you expect as they probably don’t read this group.
I don’t think it has anything to do with PCI experts. pci->class is declared
uint8_t and inf.Class is uint32_t. It does not take big expert to see the
screw up.