[PATCH 1/5] drm: add interface to get drm devices on the system v2

[Zhou, Jammy]

Hi Emil,

> If there are any other devices they will still be counted when drmGetDevices(NULL, 0)... Is that intentional ?
Yes, I think so, so that this interface can support different kinds of devices in the future. For example, we have some ARM platforms supporting PCIE, in which case we can connect one PCIE graphics card, then there will be one GPU with the platform bus (integrated GPU in the ARM SOC), and one discrete GPU on the PCIE bus. 

> Something funny is happening here - on my intel system vendor_id is reported as 0xff86, instead of 0x8086. Subvendor/device are also messed up - ffaa and ffda instead of 17aa + 21da.
That's really interesting. Did you try to update the system BIOS?

Regards,
Jammy

-----Original Message-----
From: Emil Velikov [mailto:emil.l.velikov at gmail.com] 
Sent: Thursday, August 13, 2015 9:58 PM
To: Zhou, Jammy
Cc: ML dri-devel
Subject: Re: [PATCH 1/5] drm: add interface to get drm devices on the system v2

On 13 August 2015 at 04:33, Jammy Zhou <Jammy.Zhou at amd.com> wrote:
> From: Emil Velikov <emil.l.velikov at gmail.com>
>
> For mutiple GPU support, the devices on the system should be 
> enumerated to get necessary information about each device, and the 
> drmGetDevices interface is added for this. Currently only PCI devices 
> are supported for the enumeration.
>
If there are any other devices they will still be counted when drmGetDevices(NULL, 0)... Is that intentional ?


> +static int drmParsePciDeviceInfo(const char *config,
> +                                 drmPciDeviceInfoPtr device) {
> +    if (config == NULL)
> +        return -EINVAL;
> +
> +    device->vendor_id = config[0] | (config[1] << 8);
> +    device->device_id = config[2] | (config[3] << 8);
> +    device->revision_id = config[8];
> +    device->subvendor_id = config[44] | (config[45] << 8);
> +    device->subdevice_id = config[46] | (config[47] << 8);
> +
Something funny is happening here - on my intel system vendor_id is reported as 0xff86, instead of 0x8086. Subvendor/device are also messed up - ffaa and ffda instead of 17aa + 21da.

One could bikeshed on the de-duplication error path(s), but considering that things work and there are no leaks we can leave that for some other day.

-Emil