mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Dave Airlie <airlied@linux.ie>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] gpu: Initial GPU layer addition. (03/07)
Date: Sat, 22 Jul 2006 12:54:06 -0700	[thread overview]
Message-ID: <200607221254.06817.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <11535827132905-git-send-email-airlied@linux.ie>

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

  parent reply	other threads:[~2006-07-22 19:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-22 15:38 [RFC] GPU device layer patchset (00/07) Dave Airlie
2006-07-22 15:38 ` [PATCH] drm: remove local copies of pci bus/slot/func (01/07) Dave Airlie
2006-07-22 15:38   ` [PATCH] drm: remove pci domain local copy (02/07) Dave Airlie
2006-07-22 15:38     ` [PATCH] gpu: Initial GPU layer addition. (03/07) Dave Airlie
2006-07-22 15:38       ` [PATCH] gpu/radeon: add a radeon lowlevel GPU driver (04/07) Dave Airlie
2006-07-22 15:38         ` [PATCH] gpu/radeonfb: add GPU support to radeonfb (05/07) Dave Airlie
2006-07-22 15:38           ` [PATCH] gpu/drm: Add GPU layer support to generic DRM (06/07) Dave Airlie
2006-07-22 15:38             ` [PATCH] drm/gpu/radeon: Add radeon DRM support to use GPU layer (07/07) Dave Airlie
2006-07-22 19:54       ` Jesse Barnes [this message]
2006-07-22 21:04       ` [PATCH] gpu: Initial GPU layer addition. (03/07) Nix
2006-07-23 20:04       ` Luca
2006-07-22 16:34     ` [PATCH] drm: remove pci domain local copy (02/07) Jeff Garzik
2006-07-22 16:53       ` Dave Airlie
2006-07-22 16:35 ` [RFC] GPU device layer patchset (00/07) Jeff Garzik
2006-07-22 17:00   ` Dave Airlie
2006-07-31 12:42     ` Pavel Machek

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=200607221254.06817.jbarnes@virtuousgeek.org \
    --to=jbarnes@virtuousgeek.org \
    --cc=airlied@linux.ie \
    --cc=linux-kernel@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

all inboxes | Powered by JetHome®