Re: [Intel-gfx] [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation
On 11/18/19 5:35 AM, Daniel Vetter wrote:
There's no callers in-tree anymore.
For merging probably best to stuff this into drm-misc, since that's
where the dma-buf heaps will land too. And the resulting conflict
hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
implemenation.
Signed-off-by: Daniel Vetter
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: de...@driverdev.osuosl.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/staging/android/ion/ion.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index e6b1ca141b93..bb4ededc1150 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -274,18 +274,6 @@ static void ion_dma_buf_release(struct dma_buf *dmabuf)
_ion_buffer_destroy(buffer);
}
-static void *ion_dma_buf_kmap(struct dma_buf *dmabuf, unsigned long offset)
-{
- struct ion_buffer *buffer = dmabuf->priv;
-
- return buffer->vaddr + offset * PAGE_SIZE;
-}
-
-static void ion_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
- void *ptr)
-{
-}
-
static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
enum dma_data_direction direction)
{
@@ -349,8 +337,6 @@ static const struct dma_buf_ops dma_buf_ops = {
.detach = ion_dma_buf_detatch,
.begin_cpu_access = ion_dma_buf_begin_cpu_access,
.end_cpu_access = ion_dma_buf_end_cpu_access,
- .map = ion_dma_buf_kmap,
- .unmap = ion_dma_buf_kunmap,
};
static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
Acked-by: Laura Abbott
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up
On 04/06/2018 11:52 AM, Lyude Paul wrote:
When doing a modeset where the sink is transitioning from D3 to D0 , it
would sometimes be possible for the initial power_up_phy() to start
timing out. This would only be observed in the last action before the
sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
originally thought this might be an issue with us accidentally shutting
off the aux block when putting the sink into D3, but since the DP spec
mandates that sinks must wake up within 1ms while we have 100ms to
respond to an ESI irq, this didn't really add up. Turns out that the
problem is more subtle then that:
It turns out that the timeout is from us not enabling DPMS on the MST
hub before actually trying to initiate sideband communications. This
would cause the first sideband communication (power_up_phy()), to start
timing out because the sink wasn't ready to respond. Afterwards, we
would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in
intel_ddi_pre_enable_dp(), which would actually result in waking up the
sink so that sideband requests would work again.
Since DPMS is what lets us actually bring the hub up into a state where
sideband communications become functional again, we just need to make
sure to enable DPMS on the display before attempting to perform sideband
communications.
Changes since v1:
- Remove comment above if (!intel_dp->is_mst) - vsryjala
- Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to
keep enable/disable paths symmetrical
- Improve commit message - dhnkrn
Changes since v2:
- Only send DPMS off when we're disabling the last sink, and only send
DPMS on when we're enabling the first sink - dhnkrn
Changes since v3:
- Check against is_mst, not intel_dp->is_mst - dhnkrn/vsyrjala
For the booting docked with lid down case:
Tested-by: Laura Abbott <labb...@redhat.com>
Signed-off-by: Lyude Paul <ly...@redhat.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Cc: Laura Abbott <labb...@redhat.com>
Cc: sta...@vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
---
drivers/gpu/drm/i915/intel_ddi.c| 8 ++--
drivers/gpu/drm/i915/intel_dp_mst.c | 8 +++-
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a6672a9abd85..92cb26b18a9b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
intel_prepare_dp_ddi_buffers(encoder, crtc_state);
intel_ddi_init_dp_buf_reg(encoder);
- intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+ if (!is_mst)
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
@@ -2422,12 +2423,15 @@ static void intel_ddi_post_disable_dp(struct
intel_encoder *encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_digital_port *dig_port = enc_to_dig_port(>base);
struct intel_dp *intel_dp = _port->dp;
+ bool is_mst = intel_crtc_has_type(old_crtc_state,
+ INTEL_OUTPUT_DP_MST);
/*
* Power down sink before disabling the port, otherwise we end
* up getting interrupts from the sink on detecting link loss.
*/
- intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+ if (!is_mst)
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_disable_ddi_buf(encoder);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index c3de0918ee13..9e6956c08688 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -180,9 +180,11 @@ static void intel_mst_post_disable_dp(struct intel_encoder
*encoder,
intel_dp->active_mst_links--;
intel_mst->connector = NULL;
- if (intel_dp->active_mst_links == 0)
+ if (intel_dp->active_mst_links == 0) {
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_dig_port->base.post_disable(_dig_port->base,
old_crtc_state, NULL);
+ }
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
}
@@ -223,7 +225,11 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
*encoder,
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
+ if (intel_dp->active_mst_links == 0)
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+
drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST
On 04/02/2018 02:26 PM, Lyude Paul wrote:
While enabling/disabling DPMS before link training with MST hubs is
perfectly valid; unfortunately disabling DPMS results in some devices
disabling their AUX CH block as well. For SST this isn't as much of a
problem, but for MST we need to be able to continue handling aux
transactions even when none of the sinks are turned on since it's
possible for us to have a single atomic commit which results in
disabling each downstream sink, followed by subsequently re-enabling
each sink.
If we don't do this, we'll end up stalling any pending ESI interrupts
from the sink for up to 1ms. Unfortunately, dropping ESIs during this
timespan makes it so that link fallback retraining for MST (which I will
be submitting to the ML shortly) fails due to the channel EQ failure
interrupts potentially getting dropped. Additionally, when performing a
modeset that brings the hub status's link status from bad -> good having
ESIs disabled for that long causes us to miss the hub's response to us
trying to start link training as well.
Since any sink with MST is going to support DisplayPort 1.2 anyway, save
us the hassle of trying to wait until the sink comes back up and just
never shut the aux block down.
Changes since v2:
- Fix patch name, no functional changes
Signed-off-by: Lyude Paul <ly...@redhat.com>
Cc: Laura Abbott <labb...@redhat.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Cc: sta...@vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
Still able to boot docked and lid closed so
Tested-by: Laura Abbott <labb...@redhat.com>
---
drivers/gpu/drm/i915/intel_dp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..0479c377981b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int
mode)
return;
if (mode != DRM_MODE_DPMS_ON) {
+ unsigned char data = intel_dp->is_mst ?
+ DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
+
if (downstream_hpd_needs_d0(intel_dp))
return;
- ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
-DP_SET_POWER_D3);
+ ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, data);
} else {
struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.
On 03/14/2018 11:26 AM, Pandiyan, Dhinakaran wrote:
On Wed, 2018-03-14 at 15:35 +0200, Ville Syrjälä wrote:
On Tue, Mar 13, 2018 at 10:48:25PM -0700, Dhinakaran Pandiyan wrote:
If bios sets up an MST output and hardware state readout code sees this is
an SST configuration, when disabling the encoder we end up calling
->post_disable_dp() hook instead of the MST version. Consequently, we write
to the DP_SET_POWER dpcd to set it D3 state. Further along when we try
enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up
the MST hub. This results in continuous link training failures which keep
the system busy delaying boot. We could identify bios MST boot discrepancy
and handle it accordingly but a simple way to solve this is to write to the
DP_SET_POWER dpcd for MST too.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Cc: Jani Nikula <jani.nik...@intel.com>
Reported-by: Laura Abbott <labb...@redhat.com>
Cc: sta...@vger.kernel.org
Fixes: 5ea2355a100a ("drm/i915/mst: Use MST sideband message
transactions for dpms control")
Tested-by: Laura Abbott <labb...@redhat.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
---
drivers/gpu/drm/i915/intel_ddi.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index dbcf1a0586f9..8c2d778560f0 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2205,8 +2205,7 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
intel_prepare_dp_ddi_buffers(encoder, crtc_state);
intel_ddi_init_dp_buf_reg(encoder);
- if (!is_mst)
- intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
The spec is perhaps a bit unclear on this.
"If the message is sent as a path request, all DP nodes from the source
immediate downstream device and the targeted DP node will be placed in
the D0 power state."
Doesn't quite tell me whether the immediate downstream device is
included in that list of nodes.
However the spec goes on to say
"Each nodes immediate upstream device will use Native AUX writes to the
SET_POWER & SET_DP_PWR_VOLTAGE register (DPCD Address 00600h) to set
the power state of the downstream node."
and since we are the immediate upstream for that device I guess it makes
sense that we should still do the DP_SET_POWER manually.
But I have to wonder what the original issue was before we started to use
POWER_UP/DOWN_PHY. I suppose somehow some further downstream device
wasn't in D0 when we needed it.
Correct, sinks farther downstream weren't lighting up.
But that is a bit weird as I believe all
devices should really start up in D0.
Anyways based on my reading of the spec I can justify this so
Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
Thanks for the review.
I presume we want cc:stable + fixes: on this?
Yeah, I suppose we should wait for the reporter to confirm that this
indeed fixes the bug. It does fix the problem on the Thinkpad laptop +
dock I tested it on.
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
@@ -2304,14 +2303,12 @@ static void intel_ddi_post_disable_dp(struct
intel_encoder *encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_digital_port *dig_port = enc_to_dig_port(>base);
struct intel_dp *intel_dp = _port->dp;
- bool is_mst = intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST);
/*
* Power down sink before disabling the port, otherwise we end
* up getting interrupts from the sink on detecting link loss.
*/
- if (!is_mst)
- intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_disable_ddi_buf(encoder);
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv2] drm/prime: Forward declare struct device
We need a declaration of struct device to avoid warnings:
In file included from include/drm/drm_file.h:38:0,
from drivers/gpu/drm/drm_file.c:38:
include/drm/drm_prime.h:71:14: warning: 'struct device' declared inside
parameter list will not be visible outside of this definition or
declaration
struct device *attach_dev);
^~
Forward declare it.
Signed-off-by: Laura Abbott <labb...@redhat.com>
---
v2: Switch to foward declaration instead of including a header.
---
include/drm/drm_prime.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 46fd1fb..59ccab4 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -50,6 +50,8 @@ struct drm_prime_file_private {
struct rb_root handles;
};
+struct device;
+
struct dma_buf_export_info;
struct dma_buf;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/prime: include device.h
Explictly add linux/device.h to ensure struct device is defined: In file included from include/drm/drm_file.h:38:0, from drivers/gpu/drm/drm_file.c:38: include/drm/drm_prime.h:71:14: warning: 'struct device' declared inside parameter list will not be visible outside of this definition or declaration struct device *attach_dev); ^~ Signed-off-by: Laura Abbott <labb...@redhat.com> --- Sorry, missed sending this out --- include/drm/drm_prime.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h index 46fd1fb..8ef37c8 100644 --- a/include/drm/drm_prime.h +++ b/include/drm/drm_prime.h @@ -35,6 +35,7 @@ #include #include #include +#include /** * struct drm_prime_file_private - per-file tracking for PRIME -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/vgem: Convert to a struct drm_device subclass
On 05/08/2017 06:22 AM, Chris Wilson wrote:
With Laura's introduction of the fake platform device for importing
dmabuf, we add a second static that is logically tied to the vgem_device.
Convert vgem over to using the struct drm_device subclassing, so that
the platform device is stored inside its owner.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Laura Abbott <labb...@redhat.com>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
---
drivers/gpu/drm/vgem/vgem_drv.c | 63 +++--
1 file changed, 41 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index c9381d457a03..4b23ba049632 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -42,7 +42,10 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-static struct platform_device *vgem_platform;
+static struct vgem_device {
+ struct drm_device drm;
+ struct platform_device *platform;
+} *vgem_device;
static void vgem_gem_free_object(struct drm_gem_object *obj)
{
@@ -307,7 +310,9 @@ static struct sg_table *vgem_prime_get_sg_table(struct
drm_gem_object *obj)
static struct drm_gem_object* vgem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
{
- return drm_gem_prime_import_dev(dev, dma_buf, _platform->dev);
+ struct vgem_device *vgem = container_of(dev, typeof(*vgem), drm);
+
+ return drm_gem_prime_import_dev(dev, dma_buf, >platform->dev);
}
static struct drm_gem_object *vgem_prime_import_sg_table(struct drm_device *dev,
@@ -377,8 +382,19 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
return 0;
}
+static void vgem_release(struct drm_device *dev)
+{
+ struct vgem_device *vgem = container_of(dev, typeof(*vgem), drm);
+
+ platform_device_unregister(vgem->platform);
+ drm_dev_fini(>drm);
+
+ kfree(vgem);
+}
+
static struct drm_driver vgem_driver = {
.driver_features= DRIVER_GEM | DRIVER_PRIME,
+ .release= vgem_release,
.open = vgem_open,
.postclose = vgem_postclose,
.gem_free_object_unlocked = vgem_gem_free_object,
@@ -408,45 +424,48 @@ static struct drm_driver vgem_driver = {
.minor = DRIVER_MINOR,
};
-static struct drm_device *vgem_device;
-
static int __init vgem_init(void)
{
int ret;
- vgem_device = drm_dev_alloc(_driver, NULL);
- if (IS_ERR(vgem_device))
- return PTR_ERR(vgem_device);
+ vgem_device = kzalloc(sizeof(*vgem_device), GFP_KERNEL);
+ if (!vgem_device)
+ return -ENOMEM;
- vgem_platform = platform_device_register_simple("vgem",
- -1, NULL, 0);
+ ret = drm_dev_init(_device->drm, _driver, NULL);
+ if (ret)
+ goto out_free;
- if (!vgem_platform) {
+ vgem_device->platform =
+ platform_device_register_simple("vgem", -1, NULL, 0);
+ if (!vgem_device->platform) {
ret = -ENODEV;
- goto out;
+ goto out_fini;
}
- dma_coerce_mask_and_coherent(_platform->dev,
- DMA_BIT_MASK(64));
+ dma_coerce_mask_and_coherent(_device->platform->dev,
+DMA_BIT_MASK(64));
- ret = drm_dev_register(vgem_device, 0);
+ /* Final step: expose the device/driver to userspace */
+ ret = drm_dev_register(_device->drm, 0);
if (ret)
- goto out_unref;
+ goto out_unregister;
return 0;
-out_unref:
- platform_device_unregister(vgem_platform);
-out:
- drm_dev_unref(vgem_device);
+out_unregister:
+ platform_device_unregister(vgem_device->platform);
+out_fini:
+ drm_dev_fini(_device->drm > +out_free:
+ kfree(vgem_device);
return ret;
}
static void __exit vgem_exit(void)
{
- platform_device_unregister(vgem_platform);
- drm_dev_unregister(vgem_device);
- drm_dev_unref(vgem_device);
+ drm_dev_unregister(_device->drm);
+ drm_dev_unref(_device->drm);
}
module_init(vgem_init);
Reviewed-by: Laura Abbott <labb...@redhat.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv4 1/3] drm/vgem: Add a dummy platform device
The vgem driver is currently registered independent of any actual
device. Some usage of the dmabuf APIs require an actual device structure
to do anything. Register a dummy platform device for use with dmabuf.
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Laura Abbott <labb...@redhat.com>
---
v4: Switch from the now removed platformdev to a static platform device.
---
drivers/gpu/drm/vgem/vgem_drv.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 9fee38a..d1d98af 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -42,6 +42,8 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
+static struct platform_device *vgem_platform;
+
static void vgem_gem_free_object(struct drm_gem_object *obj)
{
struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
@@ -335,11 +337,20 @@ static int __init vgem_init(void)
int ret;
vgem_device = drm_dev_alloc(_driver, NULL);
- if (IS_ERR(vgem_device)) {
- ret = PTR_ERR(vgem_device);
+ if (IS_ERR(vgem_device))
+ return PTR_ERR(vgem_device);
+
+ vgem_platform = platform_device_register_simple("vgem",
+ -1, NULL, 0);
+
+ if (!vgem_platform) {
+ ret = -ENODEV;
goto out;
}
+ dma_coerce_mask_and_coherent(_platform->dev,
+ DMA_BIT_MASK(64));
+
ret = drm_dev_register(vgem_device, 0);
if (ret)
goto out_unref;
@@ -347,13 +358,15 @@ static int __init vgem_init(void)
return 0;
out_unref:
- drm_dev_unref(vgem_device);
+ platform_device_unregister(vgem_platform);
out:
+ drm_dev_unref(vgem_device);
return ret;
}
static void __exit vgem_exit(void)
{
+ platform_device_unregister(vgem_platform);
drm_dev_unregister(vgem_device);
drm_dev_unref(vgem_device);
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv4 2/3] drm/prime: Introduce drm_gem_prime_import_dev
The existing drm_gem_prime_import function uses the underlying
struct device of a drm_device for attaching to a dma_buf. Some drivers
(notably vgem) may not have an underlying device structure. Offer
an alternate function to attach using any available device structure.
Signed-off-by: Laura Abbott <labb...@redhat.com>
---
v4: Alternate implemntation to take an arbitrary struct dev instead of just
a platform device.
This was different enough that I dropped the previous Reviewed-by
---
drivers/gpu/drm/drm_prime.c | 30 --
include/drm/drm_prime.h | 5 +
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 9fb65b7..5ad9a26 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -595,15 +595,18 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
/**
- * drm_gem_prime_import - helper library implementation of the import callback
+ * drm_gem_prime_import_dev - core implementation of the import callback
* @dev: drm_device to import into
* @dma_buf: dma-buf object to import
+ * @attach_dev: struct device to dma_buf attach
*
- * This is the implementation of the gem_prime_import functions for GEM drivers
- * using the PRIME helpers.
+ * This is the core of drm_gem_prime_import. It's designed to be called by
+ * drivers who want to use a different device structure than dev->dev for
+ * attaching via dma_buf.
*/
-struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
- struct dma_buf *dma_buf)
+struct drm_gem_object *drm_gem_prime_import_dev(struct drm_device *dev,
+ struct dma_buf *dma_buf,
+ struct device *attach_dev)
{
struct dma_buf_attachment *attach;
struct sg_table *sgt;
@@ -625,7 +628,7 @@ struct drm_gem_object *drm_gem_prime_import(struct
drm_device *dev,
if (!dev->driver->gem_prime_import_sg_table)
return ERR_PTR(-EINVAL);
- attach = dma_buf_attach(dma_buf, dev->dev);
+ attach = dma_buf_attach(dma_buf, attach_dev);
if (IS_ERR(attach))
return ERR_CAST(attach);
@@ -655,6 +658,21 @@ struct drm_gem_object *drm_gem_prime_import(struct
drm_device *dev,
return ERR_PTR(ret);
}
+EXPORT_SYMBOL(drm_gem_prime_import_dev);
+
+/**
+ * drm_gem_prime_import - helper library implementation of the import callback
+ * @dev: drm_device to import into
+ * @dma_buf: dma-buf object to import
+ *
+ * This is the implementation of the gem_prime_import functions for GEM drivers
+ * using the PRIME helpers.
+ */
+struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
+ struct dma_buf *dma_buf)
+{
+ return drm_gem_prime_import_dev(dev, dma_buf, dev->dev);
+}
EXPORT_SYMBOL(drm_gem_prime_import);
/**
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 0b2a235..46fd1fb 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -65,6 +65,11 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
int *prime_fd);
struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf);
+
+struct drm_gem_object *drm_gem_prime_import_dev(struct drm_device *dev,
+ struct dma_buf *dma_buf,
+ struct device *attach_dev);
+
int drm_gem_prime_fd_to_handle(struct drm_device *dev,
struct drm_file *file_priv, int prime_fd,
uint32_t *handle);
struct dma_buf *drm_gem_dmabuf_export(struct drm_device *dev,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv4 3/3] drm/vgem: Enable dmabuf import interfaces
Enable the GEM dma-buf import interfaces in addition to the export
interfaces. This lets vgem be used as a test source for other allocators
(e.g. Ion).
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Laura Abbott <labb...@redhat.com>
---
v4: Use new drm_gem_prime_import_dev function
---
drivers/gpu/drm/vgem/vgem_drv.c | 136 +++-
drivers/gpu/drm/vgem/vgem_drv.h | 2 +
2 files changed, 109 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index d1d98af..c9381d45 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -48,6 +48,11 @@ static void vgem_gem_free_object(struct drm_gem_object *obj)
{
struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
+ drm_free_large(vgem_obj->pages);
+
+ if (obj->import_attach)
+ drm_prime_gem_destroy(obj, vgem_obj->table);
+
drm_gem_object_release(obj);
kfree(vgem_obj);
}
@@ -58,26 +63,49 @@ static int vgem_gem_fault(struct vm_fault *vmf)
struct drm_vgem_gem_object *obj = vma->vm_private_data;
/* We don't use vmf->pgoff since that has the fake offset */
unsigned long vaddr = vmf->address;
- struct page *page;
-
- page = shmem_read_mapping_page(file_inode(obj->base.filp)->i_mapping,
- (vaddr - vma->vm_start) >> PAGE_SHIFT);
- if (!IS_ERR(page)) {
- vmf->page = page;
- return 0;
- } else switch (PTR_ERR(page)) {
- case -ENOSPC:
- case -ENOMEM:
- return VM_FAULT_OOM;
- case -EBUSY:
- return VM_FAULT_RETRY;
- case -EFAULT:
- case -EINVAL:
- return VM_FAULT_SIGBUS;
- default:
- WARN_ON_ONCE(PTR_ERR(page));
- return VM_FAULT_SIGBUS;
+ int ret;
+ loff_t num_pages;
+ pgoff_t page_offset;
+ page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
+
+ num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
+
+ if (page_offset > num_pages)
+ return VM_FAULT_SIGBUS;
+
+ if (obj->pages) {
+ get_page(obj->pages[page_offset]);
+ vmf->page = obj->pages[page_offset];
+ ret = 0;
+ } else {
+ struct page *page;
+
+ page = shmem_read_mapping_page(
+ file_inode(obj->base.filp)->i_mapping,
+ page_offset);
+ if (!IS_ERR(page)) {
+ vmf->page = page;
+ ret = 0;
+ } else switch (PTR_ERR(page)) {
+ case -ENOSPC:
+ case -ENOMEM:
+ ret = VM_FAULT_OOM;
+ break;
+ case -EBUSY:
+ ret = VM_FAULT_RETRY;
+ break;
+ case -EFAULT:
+ case -EINVAL:
+ ret = VM_FAULT_SIGBUS;
+ break;
+ default:
+ WARN_ON(PTR_ERR(page));
+ ret = VM_FAULT_SIGBUS;
+ break;
+ }
+
}
+ return ret;
}
static const struct vm_operations_struct vgem_gem_vm_ops = {
@@ -114,12 +142,8 @@ static void vgem_postclose(struct drm_device *dev, struct
drm_file *file)
kfree(vfile);
}
-/* ioctls */
-
-static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
- struct drm_file *file,
- unsigned int *handle,
- unsigned long size)
+static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
+ unsigned long size)
{
struct drm_vgem_gem_object *obj;
int ret;
@@ -129,8 +153,31 @@ static struct drm_gem_object *vgem_gem_create(struct
drm_device *dev,
return ERR_PTR(-ENOMEM);
ret = drm_gem_object_init(dev, >base, roundup(size, PAGE_SIZE));
- if (ret)
- goto err_free;
+ if (ret) {
+ kfree(obj);
+ return ERR_PTR(ret);
+ }
+
+ return obj;
+}
+
+static void __vgem_gem_destroy(struct drm_vgem_gem_object *obj)
+{
+ drm_gem_object_release(>base);
+ kfree(obj);
+}
+
+static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
+ struct drm_file *file,
+
[Intel-gfx] [PATCHv4 0/3] dma_buf import support for vgem
Hi, This v4 of the series to add dma_buf import functions for vgem. This version primarily focuses on adding a new approach for an alternate dma_buf attach after platformdev was removed. Thanks, Laura Laura Abbott (3): drm/vgem: Add a dummy platform device drm/prime: Introduce drm_gem_prime_import_dev drm/vgem: Enable dmabuf import interfaces drivers/gpu/drm/drm_prime.c | 30 ++-- drivers/gpu/drm/vgem/vgem_drv.c | 155 +++- drivers/gpu/drm/vgem/vgem_drv.h | 2 + include/drm/drm_prime.h | 5 ++ 4 files changed, 154 insertions(+), 38 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform
On 05/03/2017 12:39 AM, Daniel Vetter wrote: > On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote: >> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote: >>> /** >>> + * drm_gem_prime_import_platform - alternate implementation of the import >>> callback >>> + * @dev: drm_device to import into >>> + * @dma_buf: dma-buf object to import >>> + * >>> + * This is identical to drm_gem_prime_import except the device used for >>> dma_buf >>> + * attachment is an internal platform device instead of the standard device >>> + * structure. The use of this function should be limited to drivers that >>> do not >>> + * set up an underlying device structure. >>> + */ >>> +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device >>> *dev, >> >> Simpler soluation will be for the caller to provide the platformdev? >> >> That works nicely for the vgem case, I think. > > Yeah looking at this again, do we really need this patch? Couldn't we > instead change patch 1 to first allocate the fake platform device, then > pass that to drm_dev_alloc (instead of NULL like we do now)? > That was what I proposed in the first version and it was rejected. It's useful to have at least one driver with a NULL device for testing edge cases. > That way no resurrection of drm_device.platform_dev is needed (and I'd > really like this zombie to stay dead on 2nd thought). > I had a hunch this would be unpopular but I figured it was worth a shot. I think an even cleaner solution is to allow passing of any struct device. I'll see about reworking this. > Sry about this yet-another-round review :-/ > -Daniel > Thanks for your patience. Laura ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv3 3/3] drm/vgem: Enable dmabuf import interfaces
Enable the GEM dma-buf import interfaces in addition to the export
interfaces. This lets vgem be used as a test source for other allocators
(e.g. Ion).
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Laura Abbott <labb...@redhat.com>
---
v3: Minor fixes suggested by Chris Wilson
---
drivers/gpu/drm/vgem/vgem_drv.c | 133 +++-
drivers/gpu/drm/vgem/vgem_drv.h | 2 +
2 files changed, 106 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 727eed2..c254c80 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -34,6 +34,9 @@
#include
#include
#include
+
+#include
+
#include "vgem_drv.h"
#define DRIVER_NAME"vgem"
@@ -46,6 +49,11 @@ static void vgem_gem_free_object(struct drm_gem_object *obj)
{
struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
+ drm_free_large(vgem_obj->pages);
+
+ if (obj->import_attach)
+ drm_prime_gem_destroy(obj, vgem_obj->table);
+
drm_gem_object_release(obj);
kfree(vgem_obj);
}
@@ -56,26 +64,49 @@ static int vgem_gem_fault(struct vm_fault *vmf)
struct drm_vgem_gem_object *obj = vma->vm_private_data;
/* We don't use vmf->pgoff since that has the fake offset */
unsigned long vaddr = vmf->address;
- struct page *page;
-
- page = shmem_read_mapping_page(file_inode(obj->base.filp)->i_mapping,
- (vaddr - vma->vm_start) >> PAGE_SHIFT);
- if (!IS_ERR(page)) {
- vmf->page = page;
- return 0;
- } else switch (PTR_ERR(page)) {
- case -ENOSPC:
- case -ENOMEM:
- return VM_FAULT_OOM;
- case -EBUSY:
- return VM_FAULT_RETRY;
- case -EFAULT:
- case -EINVAL:
- return VM_FAULT_SIGBUS;
- default:
- WARN_ON_ONCE(PTR_ERR(page));
- return VM_FAULT_SIGBUS;
+ int ret;
+ loff_t num_pages;
+ pgoff_t page_offset;
+ page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
+
+ num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
+
+ if (page_offset > num_pages)
+ return VM_FAULT_SIGBUS;
+
+ if (obj->pages) {
+ get_page(obj->pages[page_offset]);
+ vmf->page = obj->pages[page_offset];
+ ret = 0;
+ } else {
+ struct page *page;
+
+ page = shmem_read_mapping_page(
+ file_inode(obj->base.filp)->i_mapping,
+ page_offset);
+ if (!IS_ERR(page)) {
+ vmf->page = page;
+ ret = 0;
+ } else switch (PTR_ERR(page)) {
+ case -ENOSPC:
+ case -ENOMEM:
+ ret = VM_FAULT_OOM;
+ break;
+ case -EBUSY:
+ ret = VM_FAULT_RETRY;
+ break;
+ case -EFAULT:
+ case -EINVAL:
+ ret = VM_FAULT_SIGBUS;
+ break;
+ default:
+ WARN_ON(PTR_ERR(page));
+ ret = VM_FAULT_SIGBUS;
+ break;
+ }
+
}
+ return ret;
}
static const struct vm_operations_struct vgem_gem_vm_ops = {
@@ -112,12 +143,8 @@ static void vgem_postclose(struct drm_device *dev, struct
drm_file *file)
kfree(vfile);
}
-/* ioctls */
-
-static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
- struct drm_file *file,
- unsigned int *handle,
- unsigned long size)
+static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
+ unsigned long size)
{
struct drm_vgem_gem_object *obj;
int ret;
@@ -127,8 +154,31 @@ static struct drm_gem_object *vgem_gem_create(struct
drm_device *dev,
return ERR_PTR(-ENOMEM);
ret = drm_gem_object_init(dev, >base, roundup(size, PAGE_SIZE));
- if (ret)
- goto err_free;
+ if (ret) {
+ kfree(obj);
+ return ERR_PTR(ret);
+ }
+
+ return obj;
+}
+
+static void __vgem_gem_destroy(struct drm_vgem_gem_object *obj)
+{
+ drm_gem_object_release(>base);
+ kfree(obj);
+}
+
+static struc
[Intel-gfx] [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform
The existing drm_gem_prime_import function uses the underlying
struct device of a drm_device for attaching to a dma_buf. Some drivers
(notably vgem) may not have an underlying device structure. Offer
an alternate function to attach using a platform device associated
with drm_device.
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Laura Abbott <labb...@redhat.com>
---
v3: Rebase to drm-misc-next. Prototype moved to a new header file. Comments
added for new function. Brought back drm_device->platformdev as it had been
removed in 76adb460fd93 ("drm: Remove the struct drm_device platformdev field").
I'm not entirely thrilled about this since the platformdev removal was good
cleanup and this feels like a small step backwards. I don't know of a better
approach though.
---
drivers/gpu/drm/drm_prime.c | 49 +++--
include/drm/drmP.h | 2 ++
include/drm/drm_prime.h | 4
3 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 9fb65b7..a557a4b 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -594,16 +594,9 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
-/**
- * drm_gem_prime_import - helper library implementation of the import callback
- * @dev: drm_device to import into
- * @dma_buf: dma-buf object to import
- *
- * This is the implementation of the gem_prime_import functions for GEM drivers
- * using the PRIME helpers.
- */
-struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
- struct dma_buf *dma_buf)
+static struct drm_gem_object *__drm_gem_prime_import(struct drm_device *dev,
+ struct dma_buf *dma_buf,
+ struct device *attach_dev)
{
struct dma_buf_attachment *attach;
struct sg_table *sgt;
@@ -625,7 +618,7 @@ struct drm_gem_object *drm_gem_prime_import(struct
drm_device *dev,
if (!dev->driver->gem_prime_import_sg_table)
return ERR_PTR(-EINVAL);
- attach = dma_buf_attach(dma_buf, dev->dev);
+ attach = dma_buf_attach(dma_buf, attach_dev);
if (IS_ERR(attach))
return ERR_CAST(attach);
@@ -655,9 +648,43 @@ struct drm_gem_object *drm_gem_prime_import(struct
drm_device *dev,
return ERR_PTR(ret);
}
+
+/**
+ * drm_gem_prime_import - helper library implementation of the import callback
+ * @dev: drm_device to import into
+ * @dma_buf: dma-buf object to import
+ *
+ * This is the implementation of the gem_prime_import functions for GEM drivers
+ * using the PRIME helpers.
+ */
+struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
+ struct dma_buf *dma_buf)
+{
+ return __drm_gem_prime_import(dev, dma_buf, dev->dev);
+}
EXPORT_SYMBOL(drm_gem_prime_import);
/**
+ * drm_gem_prime_import_platform - alternate implementation of the import
callback
+ * @dev: drm_device to import into
+ * @dma_buf: dma-buf object to import
+ *
+ * This is identical to drm_gem_prime_import except the device used for dma_buf
+ * attachment is an internal platform device instead of the standard device
+ * structure. The use of this function should be limited to drivers that do not
+ * set up an underlying device structure.
+ */
+struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
+ struct dma_buf *dma_buf)
+{
+ if (WARN_ON_ONCE(!dev->platformdev))
+ return NULL;
+
+ return __drm_gem_prime_import(dev, dma_buf, >platformdev->dev);
+}
+EXPORT_SYMBOL(drm_gem_prime_import_platform);
+
+/**
* drm_gem_prime_fd_to_handle - PRIME import function for GEM drivers
* @dev: dev to export the buffer from
* @file_priv: drm file-private structure
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index e1daa4f..086daee 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -439,6 +439,8 @@ struct drm_device {
struct pci_controller *hose;
#endif
+ /**< Platform device for drivers that do not use the standard device */
+ struct platform_device *platformdev;
struct virtio_device *virtdev;
struct drm_sg_mem *sg; /**< Scatter gather memory */
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 0b2a235..9fe39f8 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -65,6 +65,10 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
int *prime_fd);
struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf);
+
+struct drm_gem_object *
[Intel-gfx] [PATCHv3 1/3] drm/vgem: Add a dummy platform device
The vgem driver is currently registered independent of any actual
device. Some usage of the dmabuf APIs require an actual device structure
to do anything. Register a dummy platform device for use with dmabuf.
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Laura Abbott <labb...@redhat.com>
---
v3: No changes
---
drivers/gpu/drm/vgem/vgem_drv.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 9fee38a..727eed2 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -335,11 +335,20 @@ static int __init vgem_init(void)
int ret;
vgem_device = drm_dev_alloc(_driver, NULL);
- if (IS_ERR(vgem_device)) {
- ret = PTR_ERR(vgem_device);
+ if (IS_ERR(vgem_device))
+ return PTR_ERR(vgem_device);
+
+ vgem_device->platformdev = platform_device_register_simple("vgem",
+ -1, NULL, 0);
+
+ if (!vgem_device->platformdev) {
+ ret = -ENODEV;
goto out;
}
+ dma_coerce_mask_and_coherent(_device->platformdev->dev,
+ DMA_BIT_MASK(64));
+
ret = drm_dev_register(vgem_device, 0);
if (ret)
goto out_unref;
@@ -347,13 +356,15 @@ static int __init vgem_init(void)
return 0;
out_unref:
- drm_dev_unref(vgem_device);
+ platform_device_unregister(vgem_device->platformdev);
out:
+ drm_dev_unref(vgem_device);
return ret;
}
static void __exit vgem_exit(void)
{
+ platform_device_unregister(vgem_device->platformdev);
drm_dev_unregister(vgem_device);
drm_dev_unref(vgem_device);
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv3 0/3] dma_buf import support for vgem
Hi, This is v3 of the series to add dma_buf import functions for vgem. This is mostly a rebase to drm-misc/drm-misc-next with a fixup of the resulting conflicts. More details can be found on the individual patches. Thanks, Laura Laura Abbott (3): drm/vgem: Add a dummy platform device drm/prime: Introduce drm_gem_prime_import_platform drm/vgem: Enable dmabuf import interfaces drivers/gpu/drm/drm_prime.c | 49 ++--- drivers/gpu/drm/vgem/vgem_drv.c | 150 +++- drivers/gpu/drm/vgem/vgem_drv.h | 2 + include/drm/drmP.h | 2 + include/drm/drm_prime.h | 4 ++ 5 files changed, 164 insertions(+), 43 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro
On 04/19/2017 12:36 PM, Logan Gunthorpe wrote: Seeing the kunmap_atomic dma_buf_ops share the same name with a macro in highmem.h, the former can be aliased if any dma-buf user includes that header. I'm personally trying to include highmem.h inside scatterlist.h and this breaks the dma-buf code proper. Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP. To maintain consistency I've renamed all four of kmap* and kunmap* to be map* and unmap*. (Even though only kmap_atomic presently conflicts.) [1] https://www.spinics.net/lists/target-devel/msg15070.html Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Sinclair Yeh <s...@vmware.com> --- Changes since v1: - Added the missing tegra driver (noticed by kbuild robot) - Rebased off of drm-intel-next to get the i915 selftest that is new - Fixed nits Sinclair pointed out. drivers/dma-buf/dma-buf.c | 16 drivers/gpu/drm/armada/armada_gem.c| 8 drivers/gpu/drm/drm_prime.c| 8 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 8 drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 8 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 8 drivers/gpu/drm/tegra/gem.c| 8 drivers/gpu/drm/udl/udl_dmabuf.c | 8 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 8 drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++-- drivers/media/v4l2-core/videobuf2-dma-sg.c | 4 ++-- drivers/media/v4l2-core/videobuf2-vmalloc.c| 4 ++-- drivers/staging/android/ion/ion.c | 8 include/linux/dma-buf.h| 22 +++--- 14 files changed, 61 insertions(+), 61 deletions(-) For Ion, Acked-by: Laura Abbott <labb...@redhat.com> I did some major Ion refactoring but I don't think this will conflict. Thanks, Laura ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
