"EDID checksum is invalid"
On Tue, Jan 06, 2015 at 10:07:58PM -0800, Keith Packard wrote: > * PGP Signed by an unknown key > > Linus Torvalds writes: > > > it looks like the beginning is the same, but then it just turns to all > > ones at a random point (even *within* a byte). > > Looks like the EDID ROM is dropping off the i2c bus in the middle of the > transfer. Wonder if it's being 'clever' if things go too slowly at some > point, or if there's a bug in the DDC code that's in use. FWIW, I've seen that exact symptom on some monitors when the +5V pin on the DVI or HDMI cable from the GPU isn't enabled (or isn't providing enough current). Some monitors power the i2c/edid/DDC logic from that +5V either exclusively or when in the DPMS off state, and the i2c chip will just stop responding after a few cycles if not provided sufficient power. - Robert
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Oct 10, 2012 at 11:57:15PM -0700, Hans Verkuil wrote: > On Wed October 10 2012 23:02:06 Rob Clark wrote: > > On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox > > wrote: > > > On Wed, 10 Oct 2012 08:56:32 -0700 > > > Robert Morell wrote: > > > > > >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation > > >> issue, and not really an interface". The dma-buf infrastructure is > > >> explicitly intended as an interface between modules/drivers, so it > > >> should use EXPORT_SYMBOL instead. > > > > > > NAK. This needs at the very least the approval of all rights holders for > > > the files concerned and all code exposed by this change. > > > > Well, for my contributions to dmabuf, I don't object.. and I think > > because we are planning to use dma-buf in userspace for dri3 / > > dri-next, I think that basically makes it a userspace facing kernel > > infrastructure which would be required for open and proprietary > > drivers alike. So I don't see much alternative to making this > > EXPORT_SYMBOL(). Of course, IANAL. > > The whole purpose of this API is to let DRM and V4L drivers share buffers for > zero-copy pipelines. Unfortunately it is a fact that several popular DRM > drivers > are closed source. So we have a choice between keeping the export symbols GPL > and forcing those closed-source drivers to make their own incompatible API, > thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting > the closed source vendors worry about the legality. They are already using > such > functions (at least nvidia is), so they clearly accept that risk. > > I prefer the evil where the DMABUF API uses EXPORT_SYMBOL to prevent the worse > evil where an incompatible API is created to work around the EXPORT_SYMBOL_GPL > limitation. Neither situation is paradise, but at least one is a slightly less > depressing world than the other :-) > > In other words, I'm OK with EXPORT_SYMBOL for whatever it is worth as I did > not > do any coding but only some initial design help and reviewing. Thanks for the discussion. My intention is not to steal any code from the kernel or change any licenses. The goal here is to allow interoperation between drivers. I understand that it can be difficult to debug the kernel when the nvidia binary module is loaded; I'm not trying to force anyone to do that. You're free to continue to use your debug environment without change after this patch is applied. I believe that the developers and maintainers of dma-buf have provided the needed signoff, both in person and in this thread. If there are any objections from that group, I'm happy to discuss any changes necessary to get this merged. - Robert
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Oct 10, 2012 at 11:57:15PM -0700, Hans Verkuil wrote: On Wed October 10 2012 23:02:06 Rob Clark wrote: On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Wed, 10 Oct 2012 08:56:32 -0700 Robert Morell rmor...@nvidia.com wrote: EXPORT_SYMBOL_GPL is intended to be used for an internal implementation issue, and not really an interface. The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead. NAK. This needs at the very least the approval of all rights holders for the files concerned and all code exposed by this change. Well, for my contributions to dmabuf, I don't object.. and I think because we are planning to use dma-buf in userspace for dri3 / dri-next, I think that basically makes it a userspace facing kernel infrastructure which would be required for open and proprietary drivers alike. So I don't see much alternative to making this EXPORT_SYMBOL(). Of course, IANAL. The whole purpose of this API is to let DRM and V4L drivers share buffers for zero-copy pipelines. Unfortunately it is a fact that several popular DRM drivers are closed source. So we have a choice between keeping the export symbols GPL and forcing those closed-source drivers to make their own incompatible API, thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting the closed source vendors worry about the legality. They are already using such functions (at least nvidia is), so they clearly accept that risk. I prefer the evil where the DMABUF API uses EXPORT_SYMBOL to prevent the worse evil where an incompatible API is created to work around the EXPORT_SYMBOL_GPL limitation. Neither situation is paradise, but at least one is a slightly less depressing world than the other :-) In other words, I'm OK with EXPORT_SYMBOL for whatever it is worth as I did not do any coding but only some initial design help and reviewing. Thanks for the discussion. My intention is not to steal any code from the kernel or change any licenses. The goal here is to allow interoperation between drivers. I understand that it can be difficult to debug the kernel when the nvidia binary module is loaded; I'm not trying to force anyone to do that. You're free to continue to use your debug environment without change after this patch is applied. I believe that the developers and maintainers of dma-buf have provided the needed signoff, both in person and in this thread. If there are any objections from that group, I'm happy to discuss any changes necessary to get this merged. - Robert ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: Use EXPORT_SYMBOL
EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation issue, and not really an interface". The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead. Signed-off-by: Robert Morell --- This patch is based on Linus's master branch. We held a discussion at ELC, and agreed that EXPORT_SYMBOL is more appropriate for this interface than EXPORT_SYMBOL_GPL. drivers/base/dma-buf.c | 34 +- 1 files changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 460e22d..24c28be 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -122,7 +122,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops, return dmabuf; } -EXPORT_SYMBOL_GPL(dma_buf_export); +EXPORT_SYMBOL(dma_buf_export); /** @@ -148,7 +148,7 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags) return fd; } -EXPORT_SYMBOL_GPL(dma_buf_fd); +EXPORT_SYMBOL(dma_buf_fd); /** * dma_buf_get - returns the dma_buf structure related to an fd @@ -174,7 +174,7 @@ struct dma_buf *dma_buf_get(int fd) return file->private_data; } -EXPORT_SYMBOL_GPL(dma_buf_get); +EXPORT_SYMBOL(dma_buf_get); /** * dma_buf_put - decreases refcount of the buffer @@ -189,7 +189,7 @@ void dma_buf_put(struct dma_buf *dmabuf) fput(dmabuf->file); } -EXPORT_SYMBOL_GPL(dma_buf_put); +EXPORT_SYMBOL(dma_buf_put); /** * dma_buf_attach - Add the device to dma_buf's attachments list; optionally, @@ -234,7 +234,7 @@ err_attach: mutex_unlock(>lock); return ERR_PTR(ret); } -EXPORT_SYMBOL_GPL(dma_buf_attach); +EXPORT_SYMBOL(dma_buf_attach); /** * dma_buf_detach - Remove the given attachment from dmabuf's attachments list; @@ -256,7 +256,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) mutex_unlock(>lock); kfree(attach); } -EXPORT_SYMBOL_GPL(dma_buf_detach); +EXPORT_SYMBOL(dma_buf_detach); /** * dma_buf_map_attachment - Returns the scatterlist table of the attachment; @@ -283,7 +283,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, return sg_table; } -EXPORT_SYMBOL_GPL(dma_buf_map_attachment); +EXPORT_SYMBOL(dma_buf_map_attachment); /** * dma_buf_unmap_attachment - unmaps and decreases usecount of the buffer;might @@ -304,7 +304,7 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction); } -EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); +EXPORT_SYMBOL(dma_buf_unmap_attachment); /** @@ -332,7 +332,7 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len, return ret; } -EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access); +EXPORT_SYMBOL(dma_buf_begin_cpu_access); /** * dma_buf_end_cpu_access - Must be called after accessing a dma_buf from the @@ -354,7 +354,7 @@ void dma_buf_end_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len, if (dmabuf->ops->end_cpu_access) dmabuf->ops->end_cpu_access(dmabuf, start, len, direction); } -EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access); +EXPORT_SYMBOL(dma_buf_end_cpu_access); /** * dma_buf_kmap_atomic - Map a page of the buffer object into kernel address @@ -371,7 +371,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long page_num) return dmabuf->ops->kmap_atomic(dmabuf, page_num); } -EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic); +EXPORT_SYMBOL(dma_buf_kmap_atomic); /** * dma_buf_kunmap_atomic - Unmap a page obtained by dma_buf_kmap_atomic. @@ -389,7 +389,7 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned long page_num, if (dmabuf->ops->kunmap_atomic) dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr); } -EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic); +EXPORT_SYMBOL(dma_buf_kunmap_atomic); /** * dma_buf_kmap - Map a page of the buffer object into kernel address space. The @@ -406,7 +406,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long page_num) return dmabuf->ops->kmap(dmabuf, page_num); } -EXPORT_SYMBOL_GPL(dma_buf_kmap); +EXPORT_SYMBOL(dma_buf_kmap); /** * dma_buf_kunmap - Unmap a page obtained by dma_buf_kmap. @@ -424,7 +424,7 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num, if (dmabuf->ops->kunmap) dmabuf->ops->kunmap(dmabuf, page_num, vaddr); } -EXPORT_SYMBOL_GPL(dma_buf_kunmap); +EXPORT_SYMBOL(dma_buf_kunmap); /** @@ -466,7 +466,7 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma, return dmabuf->ops->mmap(dmabuf, vma); } -EXPORT_SYMBOL_GPL(dma_buf_mmap); +EXPORT_SYMBOL(dma_buf_mmap); /** * dma_buf_vmap - Create virtual ma
[PATCH] dma-buf: Use EXPORT_SYMBOL
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation issue, and not really an interface. The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead. Signed-off-by: Robert Morell rmor...@nvidia.com --- This patch is based on Linus's master branch. We held a discussion at ELC, and agreed that EXPORT_SYMBOL is more appropriate for this interface than EXPORT_SYMBOL_GPL. drivers/base/dma-buf.c | 34 +- 1 files changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 460e22d..24c28be 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -122,7 +122,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops, return dmabuf; } -EXPORT_SYMBOL_GPL(dma_buf_export); +EXPORT_SYMBOL(dma_buf_export); /** @@ -148,7 +148,7 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags) return fd; } -EXPORT_SYMBOL_GPL(dma_buf_fd); +EXPORT_SYMBOL(dma_buf_fd); /** * dma_buf_get - returns the dma_buf structure related to an fd @@ -174,7 +174,7 @@ struct dma_buf *dma_buf_get(int fd) return file-private_data; } -EXPORT_SYMBOL_GPL(dma_buf_get); +EXPORT_SYMBOL(dma_buf_get); /** * dma_buf_put - decreases refcount of the buffer @@ -189,7 +189,7 @@ void dma_buf_put(struct dma_buf *dmabuf) fput(dmabuf-file); } -EXPORT_SYMBOL_GPL(dma_buf_put); +EXPORT_SYMBOL(dma_buf_put); /** * dma_buf_attach - Add the device to dma_buf's attachments list; optionally, @@ -234,7 +234,7 @@ err_attach: mutex_unlock(dmabuf-lock); return ERR_PTR(ret); } -EXPORT_SYMBOL_GPL(dma_buf_attach); +EXPORT_SYMBOL(dma_buf_attach); /** * dma_buf_detach - Remove the given attachment from dmabuf's attachments list; @@ -256,7 +256,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) mutex_unlock(dmabuf-lock); kfree(attach); } -EXPORT_SYMBOL_GPL(dma_buf_detach); +EXPORT_SYMBOL(dma_buf_detach); /** * dma_buf_map_attachment - Returns the scatterlist table of the attachment; @@ -283,7 +283,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, return sg_table; } -EXPORT_SYMBOL_GPL(dma_buf_map_attachment); +EXPORT_SYMBOL(dma_buf_map_attachment); /** * dma_buf_unmap_attachment - unmaps and decreases usecount of the buffer;might @@ -304,7 +304,7 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, attach-dmabuf-ops-unmap_dma_buf(attach, sg_table, direction); } -EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); +EXPORT_SYMBOL(dma_buf_unmap_attachment); /** @@ -332,7 +332,7 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len, return ret; } -EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access); +EXPORT_SYMBOL(dma_buf_begin_cpu_access); /** * dma_buf_end_cpu_access - Must be called after accessing a dma_buf from the @@ -354,7 +354,7 @@ void dma_buf_end_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len, if (dmabuf-ops-end_cpu_access) dmabuf-ops-end_cpu_access(dmabuf, start, len, direction); } -EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access); +EXPORT_SYMBOL(dma_buf_end_cpu_access); /** * dma_buf_kmap_atomic - Map a page of the buffer object into kernel address @@ -371,7 +371,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long page_num) return dmabuf-ops-kmap_atomic(dmabuf, page_num); } -EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic); +EXPORT_SYMBOL(dma_buf_kmap_atomic); /** * dma_buf_kunmap_atomic - Unmap a page obtained by dma_buf_kmap_atomic. @@ -389,7 +389,7 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned long page_num, if (dmabuf-ops-kunmap_atomic) dmabuf-ops-kunmap_atomic(dmabuf, page_num, vaddr); } -EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic); +EXPORT_SYMBOL(dma_buf_kunmap_atomic); /** * dma_buf_kmap - Map a page of the buffer object into kernel address space. The @@ -406,7 +406,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long page_num) return dmabuf-ops-kmap(dmabuf, page_num); } -EXPORT_SYMBOL_GPL(dma_buf_kmap); +EXPORT_SYMBOL(dma_buf_kmap); /** * dma_buf_kunmap - Unmap a page obtained by dma_buf_kmap. @@ -424,7 +424,7 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num, if (dmabuf-ops-kunmap) dmabuf-ops-kunmap(dmabuf, page_num, vaddr); } -EXPORT_SYMBOL_GPL(dma_buf_kunmap); +EXPORT_SYMBOL(dma_buf_kunmap); /** @@ -466,7 +466,7 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma, return dmabuf-ops-mmap(dmabuf, vma); } -EXPORT_SYMBOL_GPL(dma_buf_mmap); +EXPORT_SYMBOL(dma_buf_mmap); /** * dma_buf_vmap - Create virtual mapping for the buffer object into kernel @@ -487,7 +487,7
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote: On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell rmor...@nvidia.com wrote: EXPORT_SYMBOL_GPL is intended to be used for an internal implementation issue, and not really an interface. The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead. + Konrad, Arnd, Mauro: there were strong objections on using EXPORT_SYMBOL in place of EXPORT_SYMBOL_GPL by all 3 of them; I suggest we first arrive at a consensus before merging this patch. This discussion seems to have stagnated; how do we move forward here? Sumit, as the primary author and new maintainer (congrats!) of the dma-buf infrastructure, it seems like it's really your call how to proceed. I'd still like to see this be something that we can use from the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave have argued in this thread. It really seems to me that this change on a technical level won't have any adverse effect on the scenarios where it can be used today, but it will allow it to be used more widely, which will prevent duplication and fragmentation in the future and be greatly appreciated by users of hardware such as Optimus. Let me know if you have any questions. Thanks, Robert ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote: > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell wrote: > > EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation > > issue, and not really an interface". ?The dma-buf infrastructure is > > explicitly intended as an interface between modules/drivers, so it > > should use EXPORT_SYMBOL instead. > > + Konrad, Arnd, Mauro: there were strong objections on using > EXPORT_SYMBOL in place of EXPORT_SYMBOL_GPL by all 3 of them; I > suggest we first arrive at a consensus before merging this patch. This discussion seems to have stagnated; how do we move forward here? Sumit, as the primary author and new maintainer (congrats!) of the dma-buf infrastructure, it seems like it's really your call how to proceed. I'd still like to see this be something that we can use from the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave have argued in this thread. It really seems to me that this change on a technical level won't have any adverse effect on the scenarios where it can be used today, but it will allow it to be used more widely, which will prevent duplication and fragmentation in the future and be greatly appreciated by users of hardware such as Optimus. Let me know if you have any questions. Thanks, Robert
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Jan 18, 2012 at 06:00:54AM -0800, Dave Airlie wrote: > On Wed, Jan 18, 2012 at 1:55 PM, Ilija Hadzic > wrote: > > On Wed, 18 Jan 2012, Dave Airlie wrote: > >> The problem is the x86 nvidia binary driver does sit outside of > >> subsystems, and I forsee wanting to share buffers with it from the > >> Intel driver in light of the optimus hardware. Although nouveau exists > >> and I'd much rather nvidia get behind that wrt the kernel stuff, I > >> don't forsee that happening. Yes, this is one potential use case that I have in mind. This is digressing a bit, but the binary nvidia driver is the best way that I see that we can support our users with a feature set compatible to that available to other operating systems. For technical reasons, we've chosen to leverage a lot of common code written internally, which allows us to release support for new hardware and software features much more quickly than if those of us working on the Linux/FreeBSD/Solaris drivers wrote it all from scratch. This means that we share a lot with other NVIDIA drivers, but we for better or worse can't share much infrastructure like DRI. > > Please correct me if I blab a nonsense here, but just the other day, we have > > seen a different thread in which it was decided that user cannot turn on > > buffer sharing at compile time explicitly, but rather a driver that needs it > > would turn it on automatically. > > > > Doesn't that alone exclude out-of-tree drivers? In other words if you have > > two out-of-tree drivers that want to use DMA buffer sharing, and no other > > enabled driver in the kernel enables it implicitly, then such a kernel won't > > make it possible for said two drivers to work. > > Well the use case at least on x86 would be open x86 driver sharing > with closed nvidia driver, if two closed drivers wanted to share I'd > except them to do it internally anyways. Correct. Right now, that covers Optimus laptops with Intel integrated graphics and an NVIDIA GPU. We'd only use the dma-buf interface in the case of interoperating with the Intel device. I only see such hardware becoming more common. For example, in the future, if we can't agree on using EXPORT_SYMBOL, then if somebody were to introduce a laptop that had a Tegra GPU (which uses GPL-compatible open-source Linux drivers) and a GeForce GPU (which is, as described above, supported by our existing binary driver) then I imagine we'd have no choice but to re-implement a different open-source buffer allocation mechanism for Tegra that could be used between the two, or just continue using our existing nvhost code. This, along with every other SoC's version, is exactly what the dma-buf project was intended to replace. > > Frankly, I never understood this "low-level interface" argument that is > > kicked around when EXPORT_SYMBOL_GPL topic is brought up. My view to > > EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL is that it really boils down to license > > controversy about binary/proprietary modules in Linux kernel. To me it's > > about whether the authors of certain code (for mostly phylosophical reasons) > > agree that their (GPL) code is OK or not OK to link against non-GPL module. > > > > From that angle, I am not sure if it is ethical at all to modify how the > > symbol is exported without explicit consent of the original author > > (regardless of what we think about GPL/proprietary modules covtroversy). So > > if NVidia needs to link DMA buffer sharing against their proprietary driver, > > they should have explicit permission from the original author to turn its > > symbols into EXPORT_SYMBOL. > > Which is the point of their patch, to ask permission from the author. Right. I never intended to submit this patch behind anyone's back, I just wanted to bring this to their attention and ask if the change could be made so that we could better serve shared-graphics users. Thanks, Robert
[PATCH] dma-buf: Use EXPORT_SYMBOL
EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation issue, and not really an interface". The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead. Signed-off-by: Robert Morell --- drivers/base/dma-buf.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index e38ad24..4ed5a5d 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -101,7 +101,7 @@ struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops, return dmabuf; } -EXPORT_SYMBOL_GPL(dma_buf_export); +EXPORT_SYMBOL(dma_buf_export); /** @@ -126,7 +126,7 @@ int dma_buf_fd(struct dma_buf *dmabuf) return fd; } -EXPORT_SYMBOL_GPL(dma_buf_fd); +EXPORT_SYMBOL(dma_buf_fd); /** * dma_buf_get - returns the dma_buf structure related to an fd @@ -152,7 +152,7 @@ struct dma_buf *dma_buf_get(int fd) return file->private_data; } -EXPORT_SYMBOL_GPL(dma_buf_get); +EXPORT_SYMBOL(dma_buf_get); /** * dma_buf_put - decreases refcount of the buffer @@ -167,7 +167,7 @@ void dma_buf_put(struct dma_buf *dmabuf) fput(dmabuf->file); } -EXPORT_SYMBOL_GPL(dma_buf_put); +EXPORT_SYMBOL(dma_buf_put); /** * dma_buf_attach - Add the device to dma_buf's attachments list; optionally, @@ -213,7 +213,7 @@ err_attach: mutex_unlock(>lock); return ERR_PTR(ret); } -EXPORT_SYMBOL_GPL(dma_buf_attach); +EXPORT_SYMBOL(dma_buf_attach); /** * dma_buf_detach - Remove the given attachment from dmabuf's attachments list; @@ -235,7 +235,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) mutex_unlock(>lock); kfree(attach); } -EXPORT_SYMBOL_GPL(dma_buf_detach); +EXPORT_SYMBOL(dma_buf_detach); /** * dma_buf_map_attachment - Returns the scatterlist table of the attachment; @@ -265,7 +265,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, return sg_table; } -EXPORT_SYMBOL_GPL(dma_buf_map_attachment); +EXPORT_SYMBOL(dma_buf_map_attachment); /** * dma_buf_unmap_attachment - unmaps and decreases usecount of the buffer;might @@ -288,4 +288,4 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, mutex_unlock(>dmabuf->lock); } -EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); +EXPORT_SYMBOL(dma_buf_unmap_attachment); -- 1.7.3.4
Expanding the use of DMA buffers in 3.3
The DMA buffer infrastructure (dma-buf) currently exposes its interface with EXPORT_SYMBOL_GPL. The documentation for EXPORT_SYMBOL_GPL says: "It implies that the function is considered an internal implementation issue, and not really an interface." This interface is clearly not just an "implementation issue" but an interface to be used across drivers/subsystems, so I think it makes sense for it to use EXPORT_SYMBOL instead. Work on dma-buf was originally started with the goal of unifying several competing "memory management" systems developed with different ARM SoCs in mind. It would be unfortunate if restricting its use to only GPL-licensed modules caused dma-buf adoption to be limited. For convenience, I'll send the trivial patch to implement this change. I'd like to see this in the first release with dma-buf in 3.3. Thanks, Robert
Expanding the use of DMA buffers in 3.3
The DMA buffer infrastructure (dma-buf) currently exposes its interface with EXPORT_SYMBOL_GPL. The documentation for EXPORT_SYMBOL_GPL says: It implies that the function is considered an internal implementation issue, and not really an interface. This interface is clearly not just an implementation issue but an interface to be used across drivers/subsystems, so I think it makes sense for it to use EXPORT_SYMBOL instead. Work on dma-buf was originally started with the goal of unifying several competing memory management systems developed with different ARM SoCs in mind. It would be unfortunate if restricting its use to only GPL-licensed modules caused dma-buf adoption to be limited. For convenience, I'll send the trivial patch to implement this change. I'd like to see this in the first release with dma-buf in 3.3. Thanks, Robert ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: Use EXPORT_SYMBOL
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation issue, and not really an interface. The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead. Signed-off-by: Robert Morell rmor...@nvidia.com --- drivers/base/dma-buf.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index e38ad24..4ed5a5d 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -101,7 +101,7 @@ struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops, return dmabuf; } -EXPORT_SYMBOL_GPL(dma_buf_export); +EXPORT_SYMBOL(dma_buf_export); /** @@ -126,7 +126,7 @@ int dma_buf_fd(struct dma_buf *dmabuf) return fd; } -EXPORT_SYMBOL_GPL(dma_buf_fd); +EXPORT_SYMBOL(dma_buf_fd); /** * dma_buf_get - returns the dma_buf structure related to an fd @@ -152,7 +152,7 @@ struct dma_buf *dma_buf_get(int fd) return file-private_data; } -EXPORT_SYMBOL_GPL(dma_buf_get); +EXPORT_SYMBOL(dma_buf_get); /** * dma_buf_put - decreases refcount of the buffer @@ -167,7 +167,7 @@ void dma_buf_put(struct dma_buf *dmabuf) fput(dmabuf-file); } -EXPORT_SYMBOL_GPL(dma_buf_put); +EXPORT_SYMBOL(dma_buf_put); /** * dma_buf_attach - Add the device to dma_buf's attachments list; optionally, @@ -213,7 +213,7 @@ err_attach: mutex_unlock(dmabuf-lock); return ERR_PTR(ret); } -EXPORT_SYMBOL_GPL(dma_buf_attach); +EXPORT_SYMBOL(dma_buf_attach); /** * dma_buf_detach - Remove the given attachment from dmabuf's attachments list; @@ -235,7 +235,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) mutex_unlock(dmabuf-lock); kfree(attach); } -EXPORT_SYMBOL_GPL(dma_buf_detach); +EXPORT_SYMBOL(dma_buf_detach); /** * dma_buf_map_attachment - Returns the scatterlist table of the attachment; @@ -265,7 +265,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, return sg_table; } -EXPORT_SYMBOL_GPL(dma_buf_map_attachment); +EXPORT_SYMBOL(dma_buf_map_attachment); /** * dma_buf_unmap_attachment - unmaps and decreases usecount of the buffer;might @@ -288,4 +288,4 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, mutex_unlock(attach-dmabuf-lock); } -EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); +EXPORT_SYMBOL(dma_buf_unmap_attachment); -- 1.7.3.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tue, Dec 13, 2011 at 07:10:02AM -0800, Arnd Bergmann wrote: > On Monday 12 December 2011, Robert Morell wrote: > > > > > > Doing a buffer sharing with something that is not GPL is not fun, as, if > > > any > > > issue rises there, it would be impossible to discover if the problem is > > > either > > > at the closed-source driver or at the open source one. At the time I was > > > using > > > the Nvidia proprietary driver, it was very common to have unexplained > > > issues > > > caused likely by bad code there at the buffer management code, causing X > > > applications and extensions (like xv) to break. > > > > > > We should really make this EXPORT_SYMBOL_GPL(), in order to be able to > > > latter > > > debug future share buffer issues, when needed. > > > > Sorry, I don't buy this argument. Making these exports GPL-only is not > > likely to cause anybody to open-source their driver, but will rather > > just cause them to use yet more closed-source code that is even less > > debuggable than this would be, to those without access to the source. > > But at least the broken module then won't be interacting with other modules > because it cannot share any buffers. One of the goals of this project is to unify the fragmented space of the ARM SoC memory managers so that each vendor doesn't implement their own, and they can all be closer to mainline. I fear that restricting the use of this buffer sharing mechanism to GPL drivers only will prevent that goal from being achieved, if an SoC driver has to interact with modules that use a non-GPL license. As a hypothetical example, consider laptops that have multiple GPUs. Today, these ship with onboard graphics (integrated to the CPU or chipset) along with a discrete GPU, where in many cases only the onboard graphics can actually display to the screen. In order for anything rendered by the discrete GPU to be displayed, it has to be copied to memory available for the smaller onboard graphics to texture from or display directly. Obviously, that's best done by sharing dma buffers rather than bouncing them through the GPU. It's not much of a stretch to imagine that we'll see such systems with a Tegra CPU/GPU plus a discrete GPU in the future; in that case, we'd want to be able to share memory between the discrete GPU and the Tegra system. In that scenario, if this interface is GPL-only, we'd be unable to adopt the dma_buffer sharing mechanism for Tegra. (This isn't too pie-in-the-sky, either; people are already combining Tegra with discrete GPUs: http://blogs.nvidia.com/2011/11/world%e2%80%99s-first-arm-based-supercomputer-to-launch-in-barcelona/ ) Thanks, Robert
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tue, Dec 13, 2011 at 07:10:02AM -0800, Arnd Bergmann wrote: On Monday 12 December 2011, Robert Morell wrote: Doing a buffer sharing with something that is not GPL is not fun, as, if any issue rises there, it would be impossible to discover if the problem is either at the closed-source driver or at the open source one. At the time I was using the Nvidia proprietary driver, it was very common to have unexplained issues caused likely by bad code there at the buffer management code, causing X applications and extensions (like xv) to break. We should really make this EXPORT_SYMBOL_GPL(), in order to be able to latter debug future share buffer issues, when needed. Sorry, I don't buy this argument. Making these exports GPL-only is not likely to cause anybody to open-source their driver, but will rather just cause them to use yet more closed-source code that is even less debuggable than this would be, to those without access to the source. But at least the broken module then won't be interacting with other modules because it cannot share any buffers. One of the goals of this project is to unify the fragmented space of the ARM SoC memory managers so that each vendor doesn't implement their own, and they can all be closer to mainline. I fear that restricting the use of this buffer sharing mechanism to GPL drivers only will prevent that goal from being achieved, if an SoC driver has to interact with modules that use a non-GPL license. As a hypothetical example, consider laptops that have multiple GPUs. Today, these ship with onboard graphics (integrated to the CPU or chipset) along with a discrete GPU, where in many cases only the onboard graphics can actually display to the screen. In order for anything rendered by the discrete GPU to be displayed, it has to be copied to memory available for the smaller onboard graphics to texture from or display directly. Obviously, that's best done by sharing dma buffers rather than bouncing them through the GPU. It's not much of a stretch to imagine that we'll see such systems with a Tegra CPU/GPU plus a discrete GPU in the future; in that case, we'd want to be able to share memory between the discrete GPU and the Tegra system. In that scenario, if this interface is GPL-only, we'd be unable to adopt the dma_buffer sharing mechanism for Tegra. (This isn't too pie-in-the-sky, either; people are already combining Tegra with discrete GPUs: http://blogs.nvidia.com/2011/11/world%e2%80%99s-first-arm-based-supercomputer-to-launch-in-barcelona/ ) Thanks, Robert ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Sat, Dec 10, 2011 at 03:13:06AM -0800, Mauro Carvalho Chehab wrote: > On 09-12-2011 20:50, Robert Morell wrote: > > On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote: > >> On Friday 02 December 2011, Sumit Semwal wrote: > >>> This is the first step in defining a dma buffer sharing mechanism. > >> > > [...] > >> > >>> + return dmabuf; > >>> +} > >>> +EXPORT_SYMBOL(dma_buf_export); > >> > >> I agree with Konrad, this should definitely be EXPORT_SYMBOL_GPL, > >> because it's really a low-level function that I would expect > >> to get used by in-kernel subsystems providing the feature to > >> users and having back-end drivers, but it's not the kind of thing > >> we want out-of-tree drivers to mess with. > > > > Is this really necessary? If this is intended to be a > > lowest-common-denominator between many drivers to allow buffer sharing, > > it seems like it needs to be able to be usable by all drivers. > > > > If the interface is not accessible then I fear many drivers will be > > forced to continue to roll their own buffer sharing mechanisms (which is > > exactly what we're trying to avoid here, needless to say). > > Doing a buffer sharing with something that is not GPL is not fun, as, if any > issue rises there, it would be impossible to discover if the problem is either > at the closed-source driver or at the open source one. At the time I was using > the Nvidia proprietary driver, it was very common to have unexplained issues > caused likely by bad code there at the buffer management code, causing X > applications and extensions (like xv) to break. > > We should really make this EXPORT_SYMBOL_GPL(), in order to be able to latter > debug future share buffer issues, when needed. Sorry, I don't buy this argument. Making these exports GPL-only is not likely to cause anybody to open-source their driver, but will rather just cause them to use yet more closed-source code that is even less debuggable than this would be, to those without access to the source. Thanks, Robert > Regards, > Mauro
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Sat, Dec 10, 2011 at 03:13:06AM -0800, Mauro Carvalho Chehab wrote: On 09-12-2011 20:50, Robert Morell wrote: On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote: On Friday 02 December 2011, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. [...] + return dmabuf; +} +EXPORT_SYMBOL(dma_buf_export); I agree with Konrad, this should definitely be EXPORT_SYMBOL_GPL, because it's really a low-level function that I would expect to get used by in-kernel subsystems providing the feature to users and having back-end drivers, but it's not the kind of thing we want out-of-tree drivers to mess with. Is this really necessary? If this is intended to be a lowest-common-denominator between many drivers to allow buffer sharing, it seems like it needs to be able to be usable by all drivers. If the interface is not accessible then I fear many drivers will be forced to continue to roll their own buffer sharing mechanisms (which is exactly what we're trying to avoid here, needless to say). Doing a buffer sharing with something that is not GPL is not fun, as, if any issue rises there, it would be impossible to discover if the problem is either at the closed-source driver or at the open source one. At the time I was using the Nvidia proprietary driver, it was very common to have unexplained issues caused likely by bad code there at the buffer management code, causing X applications and extensions (like xv) to break. We should really make this EXPORT_SYMBOL_GPL(), in order to be able to latter debug future share buffer issues, when needed. Sorry, I don't buy this argument. Making these exports GPL-only is not likely to cause anybody to open-source their driver, but will rather just cause them to use yet more closed-source code that is even less debuggable than this would be, to those without access to the source. Thanks, Robert Regards, Mauro ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote: On Friday 02 December 2011, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. [...] + return dmabuf; +} +EXPORT_SYMBOL(dma_buf_export); I agree with Konrad, this should definitely be EXPORT_SYMBOL_GPL, because it's really a low-level function that I would expect to get used by in-kernel subsystems providing the feature to users and having back-end drivers, but it's not the kind of thing we want out-of-tree drivers to mess with. Is this really necessary? If this is intended to be a lowest-common-denominator between many drivers to allow buffer sharing, it seems like it needs to be able to be usable by all drivers. If the interface is not accessible then I fear many drivers will be forced to continue to roll their own buffer sharing mechanisms (which is exactly what we're trying to avoid here, needless to say). - Robert ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote: > On Friday 02 December 2011, Sumit Semwal wrote: > > This is the first step in defining a dma buffer sharing mechanism. > [...] > > > + return dmabuf; > > +} > > +EXPORT_SYMBOL(dma_buf_export); > > I agree with Konrad, this should definitely be EXPORT_SYMBOL_GPL, > because it's really a low-level function that I would expect > to get used by in-kernel subsystems providing the feature to > users and having back-end drivers, but it's not the kind of thing > we want out-of-tree drivers to mess with. Is this really necessary? If this is intended to be a lowest-common-denominator between many drivers to allow buffer sharing, it seems like it needs to be able to be usable by all drivers. If the interface is not accessible then I fear many drivers will be forced to continue to roll their own buffer sharing mechanisms (which is exactly what we're trying to avoid here, needless to say). - Robert
