Re: [PATCH] gpu: Initial GPU layer addition. (03/07)

[Jesse Barnes]

On Saturday, July 22, 2006 8:38 am, Dave Airlie wrote:
> +config GPU
> +	bool
> +	default n
> +

Does this change existing userspace ABI or just add a new one (via new 
files in sysfs)?  If the latter, can this config option just be enabled 
by default or killed entirely, making the build dependent on the higher 
level CONFIG_DRM option?

> +/* GPUs we manage */
> +LIST_HEAD(gpu_bus_list);
> +
> +/* used when allocating bus numbers */
> +#define GPU_MAXBUS		16
> +struct gpu_busmap {
> +	unsigned long busmap [GPU_MAXBUS / (8*sizeof (unsigned long))];
> +};
> +static struct gpu_busmap busmap;
> +
> +/* used when updating list of gpus */
> +DEFINE_MUTEX(gpu_bus_list_lock);

Why 16?  Isn't there only one logical 'GPU bus' on the system containing 
all the graphics devices?  Or is this a limit on how many devices can 
be registered?  Or is each device considered a GPU bus in itself?

> + * This registers a GPU bus with the GPU layer,
> + * it fills in a default bus match function, and adds the device to
> the list + */
> +int gpu_register_bus(struct gpu_bus *bus)
> +{
> +	int busnum;
> +
> +	mutex_lock(&gpu_bus_list_lock);
> +
> +	busnum = find_next_zero_bit(busmap.busmap, GPU_MAXBUS, 1);
> +	if (busnum < GPU_MAXBUS) {
> +		set_bit(busnum, busmap.busmap);
> +		bus->busnum = busnum;
> +	} else {
> +		printk(KERN_ERR "%s: to many buses\n", "gpu");
> +		mutex_unlock(&gpu_bus_list_lock);
> +		return -E2BIG;

Is this the right return value or should it be -ENOSPC?  Also, I think 
you mean "too" on the previous line (figured I'd metion it before the 
spelling nazis get to you :).

Overall, seems like a nice layer to help with fb/drm coordination and 
possibly power management & suspend/resume.

Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/