search for: 172,22

Displaying 11 results from an estimated 11 matches for "172,22".

Did you mean: 172,23
2012 Jun 11
1
[PATCH 10/21] nouveau: Add support for ARB_sampler_object
...tx, int emit) @@ -159,6 +160,7 @@ nv10_emit_tex_obj(struct gl_context *ctx, int emit) struct gl_texture_object *t; struct nouveau_surface *s; struct gl_texture_image *ti; + const struct gl_sampler_object *sa; uint32_t tx_format, tx_filter, tx_enable; PUSH_RESET(push, BUFCTX_TEX(i)); @@ -172,22 +174,23 @@ nv10_emit_tex_obj(struct gl_context *ctx, int emit) t = ctx->Texture.Unit[i]._Current; s = &to_nouveau_texture(t)->surfaces[t->BaseLevel]; ti = t->Image[0][t->BaseLevel]; + sa = _mesa_get_samplerobj(ctx, i); if (!nouveau_texture_validate(ctx, t)) return...
2013 Feb 07
11
[RFC PATCH 0/8] virtio: new API for addition of buffers, scatterlist changes
The virtqueue_add_buf function has two limitations: 1) it requires the caller to provide all the buffers in a single call; 2) it does not support chained scatterlists: the buffers must be provided as an array of struct scatterlist. Because of these limitations, virtio-scsi has to copy each request into a scatterlist internal to the driver. It cannot just use the one that was prepared by the
2013 Feb 07
11
[RFC PATCH 0/8] virtio: new API for addition of buffers, scatterlist changes
The virtqueue_add_buf function has two limitations: 1) it requires the caller to provide all the buffers in a single call; 2) it does not support chained scatterlists: the buffers must be provided as an array of struct scatterlist. Because of these limitations, virtio-scsi has to copy each request into a scatterlist internal to the driver. It cannot just use the one that was prepared by the
2013 Feb 12
12
[PATCH 0/9] virtio: new API for addition of buffers, scatterlist changes
Most device drivers do not need to perform any postprocessing on the scatterlists they receive from higher-level drivers (e.g. the block or SCSI layer), because they translate the request metadata directly from the various C structs into the data that is required by the device. virtio devices however do this translation in two steps: a device-specific step in the device driver, and generic
2013 Feb 12
12
[PATCH 0/9] virtio: new API for addition of buffers, scatterlist changes
Most device drivers do not need to perform any postprocessing on the scatterlists they receive from higher-level drivers (e.g. the block or SCSI layer), because they translate the request metadata directly from the various C structs into the data that is required by the device. virtio devices however do this translation in two steps: a device-specific step in the device driver, and generic
2013 Feb 19
24
[PATCH 00/16] virtio ring rework.
OK, this is (ab)uses some of Paolo's patches. The first 7 are candidates for this merge window (maybe), the rest I'm not so sure about. Thanks, Rusty. Paolo Bonzini (3): scatterlist: introduce sg_unmark_end virtio-blk: reorganize virtblk_add_req virtio-blk: use virtqueue_add_sgs on req path Rusty Russell (13): virtio_ring: virtqueue_add_sgs, to add multiple sgs. virtio-blk:
2013 Feb 19
24
[PATCH 00/16] virtio ring rework.
OK, this is (ab)uses some of Paolo's patches. The first 7 are candidates for this merge window (maybe), the rest I'm not so sure about. Thanks, Rusty. Paolo Bonzini (3): scatterlist: introduce sg_unmark_end virtio-blk: reorganize virtblk_add_req virtio-blk: use virtqueue_add_sgs on req path Rusty Russell (13): virtio_ring: virtqueue_add_sgs, to add multiple sgs. virtio-blk:
2013 Mar 18
28
[PATCH 00/22] virtqueue_add_sgs, virtqueue_add_outbuf, virtqueue_add_inbuf
Add virtqueue_add_sgs which is more general than virtqueue_add_buf, which makes virtio-scsi and virtio-blk nicer, then add virtqueue_add_inbuf and virtqueue_add_outbuf which handle the more general case, and finally delete virtqueue_add_buf(). I'm hoping this will be the final post of the whole series, and it can move from my pending-rebases tree into virtio-next. Thanks! Rusty. Paolo
2013 Mar 18
28
[PATCH 00/22] virtqueue_add_sgs, virtqueue_add_outbuf, virtqueue_add_inbuf
Add virtqueue_add_sgs which is more general than virtqueue_add_buf, which makes virtio-scsi and virtio-blk nicer, then add virtqueue_add_inbuf and virtqueue_add_outbuf which handle the more general case, and finally delete virtqueue_add_buf(). I'm hoping this will be the final post of the whole series, and it can move from my pending-rebases tree into virtio-next. Thanks! Rusty. Paolo
2020 Oct 17
10
[RFC] treewide: cleanup unreachable breaks
...nt; - break; case VME_LM: return list_entry(resource->entry, struct vme_lm_resource, list)->parent; - break; default: printk(KERN_ERR "Unknown resource type\n"); return NULL; - break; } } /** * vme_free_consistent - Allocate contiguous memory. @@ -177,26 +172,22 @@ size_t vme_get_size(struct vme_resource *resource) &aspace, &cycle, &dwidth); if (retval) return 0; return size; - break; case VME_SLAVE: retval = vme_slave_get(resource, &enabled, &base, &size, &buf_base, &aspace, &cycle); if (...
2020 Oct 17
10
[RFC] treewide: cleanup unreachable breaks
...nt; - break; case VME_LM: return list_entry(resource->entry, struct vme_lm_resource, list)->parent; - break; default: printk(KERN_ERR "Unknown resource type\n"); return NULL; - break; } } /** * vme_free_consistent - Allocate contiguous memory. @@ -177,26 +172,22 @@ size_t vme_get_size(struct vme_resource *resource) &aspace, &cycle, &dwidth); if (retval) return 0; return size; - break; case VME_SLAVE: retval = vme_slave_get(resource, &enabled, &base, &size, &buf_base, &aspace, &cycle); if (...