Re: [RFC 0/4] Exynos DRM: add Picture Processor extension
Hi Dave, On 2017-04-20 21:02, Dave Airlie wrote: On 20 April 2017 at 19:13, Marek Szyprowski wrote: This is an updated proposal for extending EXYNOS DRM API with generic support for hardware modules, which can be used for processing image data from the one memory buffer to another. Typical memory-to-memory operations are: rotation, scaling, colour space conversion or mix of them. This is a follow-up of my previous proposal "[RFC 0/2] New feature: Framebuffer processors", which has been rejected as "not really needed in the DRM core": http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg146286.html In this proposal I moved all the code to Exynos DRM driver, so now this will be specific only to Exynos DRM. I've also changed the name from framebuffer processor (fbproc) to picture processor (pp) to avoid confusion with fbdev API. Here is a bit more information what picture processors are: Embedded SoCs are known to have a number of hardware blocks, which perform such operations. They can be used in paralel to the main GPU module to offload CPU from processing grapics or video data. One of example use of such modules is implementing video overlay, which usually requires color space conversion from NV12 (or similar) to RGB32 color space and scaling to target window size. The proposed API is heavily inspired by atomic KMS approach - it is also based on DRM objects and their properties. A new DRM object is introduced: picture processor (called pp for convenience). Such objects have a set of standard DRM properties, which describes the operation to be performed by respective hardware module. In typical case those properties are a source fb id and rectangle (x, y, width, height) and destination fb id and rectangle. Optionally a rotation property can be also specified if supported by the given hardware. To perform an operation on image data, userspace provides a set of properties and their values for given fbproc object in a similar way as object and properties are provided for performing atomic page flip / mode setting. The proposed API consists of the 3 new ioctls: - DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture processors, - DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture processor, - DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given property set. The proposed API is extensible. Drivers can attach their own, custom properties to add support for more advanced picture processing (for example blending). So this looks more like a command submission API like we have for other drivers. Is there an overarching reason why it needs to reuse the core drm object tracking and properties, or was that just a nice to have, vs something like amdgpu chunks. Thanks for your comment. DRM objects and properties were my first choice when designing this new api, but I'm still a bit new to DRM at all. I was also a bit fascinated by the atomic KMS approach, though. I selected them simply to reuse the code for managing objects and enumerating their properties from userspace. If this is not the preferred approach, I will rewrite the code to use something custom. I didn't know about amdgpu chunks, but from the quick look they are just a structure to store a set of ids and data for them. Maybe there is no need to use strings for enumerating the properties and limiting the API to the known set of IDs will be more than enough in this case. My worry about exposing objects and properties to the drivers is I'm sure someone could get quite inventive and end up with a forked atomic API that we don't see, or undocumented things. Okay. I will try different approach then. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 2/3] ARM: drm: Intel FPGA VIP Frame Buffer II drm driver
On Tue, 25 Apr 2017, hean.loong@intel.com wrote: > +++ b/drivers/gpu/drm/ivip/Makefile > @@ -0,0 +1,9 @@ > +# > +# Makefile for the drm device driver. This driver provides support for the > +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. > + > +ccflags-y := -Iinclude/drm Just a drive-by observation, there are patches on the list removing such ccflags from existing drivers. You shouldn't need this. Just make sure all your #includes begin with + > +obj-$(CONFIG_DRM_IVIP) += ivip.o > +ivip-objs := intel_vip_of.o intel_vip_core.o \ > +intel_vip_conn.o -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100761] `radeon_ib_ring_tests` takes 0.5 s on resume
https://bugs.freedesktop.org/show_bug.cgi?id=100761 --- Comment #3 from Paul Menzel --- (In reply to Christian König from comment #2) > (In reply to Paul Menzel from comment #0) > > Looking at the generated graph 540 ms is spent in `radeon_ib_ring_tests`, > > which contributes most of the time. > > > > It’d be awesome to improve these times. > > And impossible as well. UVD hardware startup just takes about 400-500ms on > the older boxes. No idea why. Interesting. What part is responsible for this? AtomBIOS? Does the UVD hardware need to start up before displaying something on the screen, or could it be moved to the user space driver? How long does it take on the new hardware? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/shmob: fix return value check in shmob_drm_probe()
Hi Wei, Thank you for the patch. On Tuesday 25 Apr 2017 03:08:08 Wei Yongjun wrote: > From: Wei Yongjun > > In case of error, the function devm_ioremap_resource() returns ERR_PTR() > and never returns NULL. The NULL test in the return value check should > be replaced with IS_ERR(). > > Signed-off-by: Wei Yongjun Reviewed-by: Laurent Pinchart and applied to my tree. I'll send a pull request for v4.13. > --- > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c > b/drivers/gpu/drm/shmobile/shmob_drm_drv.c index 800d1d2..6bd777a 100644 > --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c > +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c > @@ -235,8 +235,8 @@ static int shmob_drm_probe(struct platform_device *pdev) > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > sdev->mmio = devm_ioremap_resource(&pdev->dev, res); > - if (sdev->mmio == NULL) > - return -ENOMEM; > + if (IS_ERR(sdev->mmio)) > + return PTR_ERR(sdev->mmio); > > ret = shmob_drm_setup_clocks(sdev, pdata->clk_source); > if (ret < 0) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/4] drm: Add driver-private objects to atomic state
On 21-04-17 07:51, Dhinakaran Pandiyan wrote:
> From: "Pandiyan, Dhinakaran"
>
> It is necessary to track states for objects other than connector, crtc
> and plane for atomic modesets. But adding objects like DP MST link
> bandwidth to drm_atomic_state would mean that a non-core object will be
> modified by the core helper functions for swapping and clearing
> it's state. So, lets add void * objects and helper functions that operate
> on void * types to keep these objects and states private to the core.
> Drivers can then implement specific functions to swap and clear states.
> The other advantage having just void * for these objects in
> drm_atomic_state is that objects of different types can be managed in the
> same state array.
>
> v6: More kernel-doc to keep 0-day happy
> v5: Remove more NULL checks (Maarten)
> v4: Avoid redundant NULL checks when private_objs array is empty (Maarten)
> v3: Macro alignment (Chris)
> v2: Added docs and new iterator to filter private objects (Daniel)
>
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Archit Taneja
> Cc: Chris Wilson
> Cc: Harry Wentland
>
> Acked-by: Harry Wentland
> Suggested-by: Daniel Vetter
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/drm_atomic.c| 65 +++
> drivers/gpu/drm/drm_atomic_helper.c | 5 ++
> include/drm/drm_atomic.h| 101
>
> 3 files changed, 171 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 30229ab..8e5f3eb 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct
> drm_atomic_state *state)
> kfree(state->connectors);
> kfree(state->crtcs);
> kfree(state->planes);
> + kfree(state->private_objs);
> }
> EXPORT_SYMBOL(drm_atomic_state_default_release);
>
> @@ -184,6 +185,17 @@ void drm_atomic_state_default_clear(struct
> drm_atomic_state *state)
> state->planes[i].ptr = NULL;
> state->planes[i].state = NULL;
> }
> +
> + for (i = 0; i < state->num_private_objs; i++) {
> + void *obj_state = state->private_objs[i].obj_state;
> +
> + state->private_objs[i].funcs->destroy_state(obj_state);
> + state->private_objs[i].obj = NULL;
> + state->private_objs[i].obj_state = NULL;
> + state->private_objs[i].funcs = NULL;
> + }
> + state->num_private_objs = 0;
> +
> }
> EXPORT_SYMBOL(drm_atomic_state_default_clear);
>
> @@ -978,6 +990,59 @@ static void drm_atomic_plane_print_state(struct
> drm_printer *p,
> }
>
> /**
> + * drm_atomic_get_private_obj_state - get private object state
> + * @state: global atomic state
> + * @obj: private object to get the state for
> + * @funcs: pointer to the struct of function pointers that identify the
> object
> + * type
> + *
> + * This function returns the private object state for the given private
> object,
> + * allocating the state if needed. It does not grab any locks as the caller
> is
> + * expected to care of any required locking.
> + *
> + * RETURNS:
> + *
> + * Either the allocated state or the error code encoded into a pointer.
> + */
> +void *
> +drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
> + const struct drm_private_state_funcs *funcs)
> +{
> + int index, num_objs, i;
> + size_t size;
> + struct __drm_private_objs_state *arr;
> +
> + for (i = 0; i < state->num_private_objs; i++)
> + if (obj == state->private_objs[i].obj &&
> + state->private_objs[i].obj_state)
> + return state->private_objs[i].obj_state;
> +
> + num_objs = state->num_private_objs + 1;
> + size = sizeof(*state->private_objs) * num_objs;
> + arr = krealloc(state->private_objs, size, GFP_KERNEL);
> + if (!arr)
> + return ERR_PTR(-ENOMEM);
> +
> + state->private_objs = arr;
> + index = state->num_private_objs;
> + memset(&state->private_objs[index], 0, sizeof(*state->private_objs));
> +
> + state->private_objs[index].obj_state = funcs->duplicate_state(state,
> obj);
> + if (!state->private_objs[index].obj_state)
> + return ERR_PTR(-ENOMEM);
> +
> + state->private_objs[index].obj = obj;
> + state->private_objs[index].funcs = funcs;
> + state->num_private_objs = num_objs;
> +
> + DRM_DEBUG_ATOMIC("Added new private object state %p to %p\n",
> + state->private_objs[index].obj_state, state);
> +
> + return state->private_objs[index].obj_state;
> +}
> +EXPORT_SYMBOL(drm_atomic_get_private_obj_state);
> +
> +/**
> * drm_atomic_get_connector_state - get connector state
> * @state: global atomic state object
> * @connector: connector to get state object for
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic
Re: [PATCH v7 4/4] drm/dp: Track MST link bandwidth
On 21-04-17 07:51, Dhinakaran Pandiyan wrote:
> From: "Pandiyan, Dhinakaran"
>
> Use the added helpers to track MST link bandwidth for atomic modesets.
> Link bw is acquired in the ->atomic_check() phase when CRTCs are being
> enabled with drm_atomic_find_vcpi_slots() instead of drm_find_vcpi_slots().
> Similarly, link bw is released during ->atomic_check() with the connector
> helper callback ->atomic_release() when CRTCs are disabled.
>
> v5: Implement connector->atomic_check() in place of atomic_release()
> v4: Return an int from intel_dp_mst_atomic_release() (Maarten)
> v3:
> Handled the case where ->atomic_release() is called more than once
> during an atomic_check() for the same state.
> v2:
> Squashed atomic_release() implementation and caller (Daniel)
> Fixed logic for connector-crtc switching case (Daniel)
> Fixed logic for suspend-resume case.
>
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Archit Taneja
> Cc: Chris Wilson
> Cc: Harry Wentland
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/i915/intel_dp_mst.c | 57
> +
> 1 file changed, 51 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 5af22a7..20c557c 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -39,9 +39,9 @@ static bool intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> struct intel_dp *intel_dp = &intel_dig_port->dp;
> struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> - struct drm_atomic_state *state;
> + struct drm_atomic_state *state = pipe_config->base.state;
> int bpp;
> - int lane_count, slots;
> + int lane_count, slots = 0;
> const struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
> int mst_pbn;
>
> @@ -63,24 +63,68 @@ static bool intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> pipe_config->pipe_bpp = bpp;
> pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
>
> - state = pipe_config->base.state;
> -
> if (drm_dp_mst_port_has_audio(&intel_dp->mst_mgr, connector->port))
> pipe_config->has_audio = true;
> - mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
>
> + mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
> pipe_config->pbn = mst_pbn;
> - slots = drm_dp_find_vcpi_slots(&intel_dp->mst_mgr, mst_pbn);
>
> intel_link_compute_m_n(bpp, lane_count,
> adjusted_mode->crtc_clock,
> pipe_config->port_clock,
> &pipe_config->dp_m_n);
>
> + if (pipe_config->base.active) {
Is this check needed? If so it needs a comment as to why.
I know that the output won't actually turn on, but if the crtc is configured
vcpi slots should be allocated if possible.
Else the following will fail in the wrong place:
1. Configure CRTC with a valid mode and DP-MST connector, but set active=false.
connectors_changed = true, mode_changed = true. Not enough VCPI slots to enable
all crtc's at the same time now, but this returns OK.
2. Commit with active property set to true. There are too few vcpi slots to
make this work, this atomic commit returns -EINVAL. This might happen on a
different crtc than the newly configured one in stap 1, if they were all
previously set to !active.
> + slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr,
> + connector->port, mst_pbn);
> + if (slots < 0) {
> + DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots);
> + return false;
> + }
> + }
> pipe_config->dp_m_n.tu = slots;
>
> return true;
> +}
>
> +static inline bool release_resources(struct drm_crtc_state *crtc_state)
> +{
> + return (crtc_state->connectors_changed ||
> + crtc_state->mode_changed ||
> + (crtc_state->active_changed && !crtc_state->active));
> +}
> +
> +static int intel_dp_mst_atomic_check(struct drm_connector *connector,
> + struct drm_connector_state *new_conn_state)
> +{
> + struct drm_atomic_state *state = new_conn_state->state;
> + struct drm_connector_state *old_conn_state;
> + struct drm_crtc *old_crtc;
> + struct drm_crtc_state *crtc_state;
> + int slots, ret = 0;
> +
> + old_conn_state = drm_atomic_get_old_connector_state(state, connector);
> + old_crtc = old_conn_state->crtc;
> + if (!old_crtc)
> + return 0;
> +
> + crtc_state = drm_atomic_get_new_crtc_state(state, old_crtc);
> + slots = to_intel_crtc_state(crtc_state)->dp_m_n.tu;
> +
> + if (release_resources(crtc_state) && slots > 0) {
> + struct drm_dp_mst_topology_mgr *mgr;
> + struct drm_e
[Bug 100761] `radeon_ib_ring_tests` takes 0.5 s on resume
https://bugs.freedesktop.org/show_bug.cgi?id=100761 --- Comment #4 from Christian König --- (In reply to Paul Menzel from comment #3) > Interesting. What part is responsible for this? AtomBIOS? No, that is completely unrelated to AtomBIOS. The PLL just needs awfully long to settle and booting the firmware doesn't necessary succeed on the first try sometimes. If the later happens this can even take multiple seconds until everything is settled. > Does the UVD hardware need to start up before displaying something on the > screen, or could it be moved to the user space driver? Yes, all blocks must be started correctly for power management to work because we have a lot of interactions between the different blocks of the hardware. > How long does it take on the new hardware? I honestly don't know in detail. On newer hardware you give a single command to the power management uC and it does everything needed in the background. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100761] `radeon_ib_ring_tests` takes 0.5 s on resume
https://bugs.freedesktop.org/show_bug.cgi?id=100761 --- Comment #5 from Christian König --- What I've forgot: One thing that could possible help would be an HDP flush directly before we wait for the fence. Just in case the value written for the fence is stuck in the HDP (unlikely, but worth a try). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm: omapdrm: Add zpos property
On 24/04/17 17:05, Laurent Pinchart wrote: > Hi Tomi, > > On Monday 24 Apr 2017 17:00:52 Laurent Pinchart wrote: >> On Monday 24 Apr 2017 12:37:24 Tomi Valkeinen wrote: >>> On 15/04/17 12:16, Laurent Pinchart wrote: Create a standard zpos property for every plane as an alias to the omapdrm-specific zorder property. Unlike the zorder property that has to be instantiated for both planes and CRTCs due to backward compatibility, the zpos property is only instantiated for planes. When userspace will have switched to the zpos property the zorder property will be removed. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/omapdrm/omap_plane.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c b/drivers/gpu/drm/omapdrm/omap_plane.c index 521dd2ea519a..871a89b87e72 100644 --- a/drivers/gpu/drm/omapdrm/omap_plane.c +++ b/drivers/gpu/drm/omapdrm/omap_plane.c @@ -324,6 +324,7 @@ struct drm_plane *omap_plane_init(struct drm_device *dev, drm_plane_helper_add(plane, &omap_plane_helper_funcs); omap_plane_install_properties(plane, &plane->base); + drm_plane_create_zpos_property(plane, 0, 0, 3); >>> >>> I think this should use get_num_ovls() to get the max value. >> >> That's fine with me, but note that the code currently hardcodes the value to >> 3 for the zorder property. I can submit an addition patch on top of this to >> change both if you think it would be better. Ah, right, we have it already at 3 currently... > And should it be get_num_ovls() - 1 ? The zorder register field is two bits > wide, and we have up to 4 overlays on OMAP4. This will change the maximum > value of the property from 3 to 2 on OMAP3. Do you think that could cause > issues ? Yes, num_ovls - 1. On OMAP2/3 we can't even set the zorder, so it doesn't matter. Of course, we shouldn't even have the property for OMAP2/3... Or maybe we could have it, but as read-only. Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: omapdrm: Store the Z order in the plane state zpos field
On 24/04/17 17:00, Laurent Pinchart wrote: > Hi Tomi, > > On Monday 24 Apr 2017 12:40:10 Tomi Valkeinen wrote: >> On 15/04/17 12:16, Laurent Pinchart wrote: >>> The DRM core implements a standard "zpos" property to control planes >>> ordering. The omapdrm driver implements a similar property named >>> "zorder". Although we can't switch to DRM core handling of the "zpos" >>> property for backward compatibility reasons, we can store the zorder >>> value in the drm_plane_state zpos field, saving us from having to >>> implement custom plane state handling. >> >> I'm fine with the zpos change, but I'd like to keep the omap_plane_state >> around. It'll be empty after this patch, but we have a bunch of >> properties we need to add. Some can be added as common DRM properties, >> but perhaps not all. It's so much easier to handle those patches if the >> plumbing is there already, instead of adding it back. > > How about reverting the needed parts of this patch at that time then ? I > think > it would be better than keeping useless code around until a hypothetical time > when it will be needed. I kind of agree, but based on my experience, I disagree =). We have a bunch of HW properties for both crtcs and planes which are not supported in mainline. I have patches for those. It's difficult to upstream them, because the aim should be to get common properties. Creating common properties is Hard. So I need to carry those patches, maybe for a long time, which means rebasing, which means gazillion conflicts if the mainline version doesn't have the omap custom state for crtc and plane. In the minimum, the change for the zorder and the change that removes the omap_plane_state should be separate. Then the removal patch can be reverted, and the amount of conflicts drops to half a gazillion. Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/gvt: fix typo: "supporte" -> "support"
From: Colin Ian King
trivial fix to typo in WARN_ONCE message
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 0ad1a508e2af..c995e540ff96 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1244,7 +1244,7 @@ static int dma_ctrl_write(struct intel_vgpu *vgpu,
unsigned int offset,
mode = vgpu_vreg(vgpu, offset);
if (GFX_MODE_BIT_SET_IN_MASK(mode, START_DMA)) {
- WARN_ONCE(1, "VM(%d): iGVT-g doesn't supporte GuC\n",
+ WARN_ONCE(1, "VM(%d): iGVT-g doesn't support GuC\n",
vgpu->id);
return 0;
}
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/10] drm: omapdrm: Fix incorrect usage of the term 'cache coherency'
On 24/04/17 17:25, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Monday 24 Apr 2017 13:44:23 Tomi Valkeinen wrote:
>> On 21/04/17 00:33, Laurent Pinchart wrote:
>>> The is_cache_coherent() function currently returns true when the mapping
>>> is not cache-coherent. This isn't a bug as such as the callers interpret
>>> cache-coherent as meaning that the driver has to handle the coherency
>>> manually, but it is nonetheless very confusing. Fix it and add a bit
>>> more documentation to explain how cached buffers are handled.
>>>
>>> Signed-off-by: Laurent Pinchart
>>> ---
>>> Changes since v1:
>>>
>>> - Fixed one mistakenly inverted cache coherency check
>>> ---
>>>
>>> drivers/gpu/drm/omapdrm/omap_gem.c | 22 +++---
>>> 1 file changed, 15 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
>>> b/drivers/gpu/drm/omapdrm/omap_gem.c index d6d38e569fff..43b60a146edf
>>> 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
>>> @@ -719,16 +719,21 @@ int omap_gem_roll(struct drm_gem_object *obj,
>>> uint32_t roll)>
>>> * Memory Management & DMA Sync
>>> */
>>>
>>> -/**
>>> - * shmem buffers that are mapped cached can simulate coherency via using
>>> - * page faulting to keep track of dirty pages
>>> +/*
>>> + * shmem buffers that are mapped cached are not coherent.
>>
>> We use shmem only with TILER. Not all SoCs have TILER (and you can
>> disable TILER on the SoCs that have it).
>>
>> As this patch is more or less a cleanup, I'm not sure if the above
>> should be part of this patch. But it makes me wonder: if we don't use
>> shmem, we use dma_alloc_writecombine.
>
> Only for OMAP_BO_SCANOUT buffers. Other buffers will still be allocated
> through shmem.
Right... I hope nobody allocates those. omapdrm should be used for dss
buffers, which means scanout...
>> Do we still end up mapping it to the userspace as cached?
>
> Well, in that case, we actually end up not mapping it at all if the user
> requests cached mapping :-) omap_gem_mmap_obj() will return with a WARN_ON()
> and omap_gem_pin() (which used to be omap_gem_get_paddr()) will return -
> EINVAL.
>
> I believe we should disallow non-contiguous buffers without a DMM at
> allocation time. As for cached mapping of contiguous buffers, the dirty page
> tracking implementation requires shmem at the moment. This could be fixed,
> but
> isn't trivial. Do you see value in doing so, or should cached mappings of
> contiguous buffers be disallowed for the time being ?
I think the answer depends on whether cached buffers are usable
(performance-wise). If not, we should drop cached buffer support
totally. If yes, then we should support them for contiguous buffers too.
>>> static inline bool is_cached_coherent(struct drm_gem_object *obj)
>>> {
>>> struct omap_gem_object *omap_obj = to_omap_bo(obj);
>>>
>>> - return (omap_obj->flags & OMAP_BO_MEM_SHMEM) &&
>>> - ((omap_obj->flags & OMAP_BO_CACHE_MASK) == OMAP_BO_CACHED);
>>> + return !((omap_obj->flags & OMAP_BO_MEM_SHMEM) &&
>>> + ((omap_obj->flags & OMAP_BO_CACHE_MASK) == OMAP_BO_CACHED));
>>
>> Regardless of whether we support non-shmem cached buffers, isn't the
>> above overly complex? Why can't we just check for OMAP_BO_CACHED? Isn't
>> that the only case where the buffer is not coherent? At the moment this
>> function sounds more like "is_shmem_cached_coherent".
>
> You're right. I propose fixing that in an additional patch to avoid potential
> changes to the behaviour in this one.
Sounds good.
Tomi
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] drm: tackle byteorder issues, take two
On Tue, Apr 25, 2017 at 09:49:38AM +0900, Michel Dänzer wrote: > On 24/04/17 11:26 PM, Ville Syrjälä wrote: > > On Mon, Apr 24, 2017 at 04:54:25PM +0900, Michel Dänzer wrote: > >> On 24/04/17 04:36 PM, Gerd Hoffmann wrote: > >>> > > drm: fourcc byteorder: add DRM_FORMAT_CPU_* > > drm: fourcc byteorder: add bigendian support to > > drm_mode_legacy_fb_format > > As I explained in my last followup in the "[PATCH] drm: fourcc > byteorder: brings header file comments in line with reality." thread, > the mapping between GPU and CPU formats has to be provided by the > driver, it cannot be done statically. > >>> > >>> Well, the drm fourcc codes represent the cpu view (i.e. what userspace > >>> will fill the ADDFB2-created framebuffers with). > >> > >> Ville is adamant that they represent the GPU view. This needs to be > >> resolved one way or the other. > > > > Since the byte swapping can happen either for CPU or display access > > I guess we can't just consider the GPU and display as a single entity. > > > > We may need to consider several agents: > > 1. display > > 2. GPU > > 3. CPU > > 4. other DMA > > > > Not sure what we can say about 4. I presume it's going to be like the > > GPU or the CPU in the sense that it might go through the CPU byte > > swapping logic or not. I'm just going to ignore it. > > > > Let's say we have the following bytes in memory > > (in order of increasing address): A,B,C,D > > We'll assume GPU and display are LE natively. Each component will see > > the resulting 32bpp pixel as follows (msb left->lsb right): > > > > LE CPU w/ no byte swapping: > > display: DCBA > > GPU: DCBA > > CPU: DCBA > > = everyone agrees > > > > BE CPU w/ no byte swapping: > > display: DCBA > > GPU: DCBA > > CPU: ABCD > > = GPU and display agree > > > > BE CPU w/ display byte swapping: > > display: ABCD > > GPU: DCBA > > CPU: ABCD > > = CPU and display agree > > > > BE CPU w/ CPU access byte swapping: > > display: DCBA > > GPU: DCBA > > CPU: DCBA > > = everyone agrees > > Beware that for this list, you're using a format definition Actually I'm not using any format definitions here. > which is > based on a packed 32-bit value. This does *not* match the current > DRM_FORMAT_* definitions. E.g. in the last case, display and GPU use > the same DRM_FORMAT, but the CPU uses the "inverse" one. I wasn't concerned about the specific drm format, just what kind of a 32bpp value everyone will see given the same memory contents. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/6] drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format
On Tue, Apr 25, 2017 at 12:18:52PM +0900, Michel Dänzer wrote:
> On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
> > Return correct fourcc codes on bigendian. Drivers must be adapted to
> > this change.
> >
> > Signed-off-by: Gerd Hoffmann
>
> Just to reiterate, this won't work for the radeon driver, which programs
> the GPU to use (effectively, per the current definition that these are
> little endian GPU formats) DRM_FORMAT_XRGB with pre-R600 and
> DRM_FORMAT_BGRX with >= R600.
>
>
> > +#ifdef __BIG_ENDIAN
> > + switch (bpp) {
> > + case 8:
> > + fmt = DRM_FORMAT_C8;
> > + break;
> > + case 24:
> > + fmt = DRM_FORMAT_BGR888;
> > + break;
>
> BTW, endianness as a concept cannot apply to 8 or 24 bpp formats.
To 8bpp no, but it can easily apply to 24bpp. Same was as it applies to
16bpp. Neither matches the word size of the CPU or anything like that
but still the bytes have to stored in memory in some order.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Tue, Apr 25, 2017 at 10:12:37AM +0900, Michel Dänzer wrote: > On 24/04/17 10:03 PM, Ville Syrjälä wrote: > > On Mon, Apr 24, 2017 at 03:57:02PM +0900, Michel Dänzer wrote: > >> On 22/04/17 07:05 PM, Ville Syrjälä wrote: > >>> On Fri, Apr 21, 2017 at 06:14:31PM +0200, Gerd Hoffmann wrote: > Hi, > > >> My personal opinion is that formats in drm_fourcc.h should be > >> independent of the CPU byte order and the function > >> drm_mode_legacy_fb_format() and drivers depending on that incorrect > >> assumption be fixed instead. > > > > The problem is this isn't a kernel-internal thing any more. With the > > addition of the ADDFB2 ioctl the fourcc codes became part of the > > kernel/userspace abi ... > > Ok, added some printk's to the ADDFB and ADDFB2 code paths and tested a > bit. Apparently pretty much all userspace still uses the ADDFB ioctl. > xorg (modesetting driver) does. gnome-shell in wayland mode does. > Seems the big transition to ADDFB2 didn't happen yet. > > I guess that makes changing drm_mode_legacy_fb_format + drivers a > reasonable option ... > >>> > >>> Yeah, I came to the same conclusion after chatting with some > >>> folks on irc. > >>> > >>> So my current idea is that we change any driver that wants to follow the > >>> CPU endianness > >> > >> This isn't really optional for various reasons, some of which have been > >> covered in this discussion. > >> > >> > >>> to declare support for big endian formats if the CPU is > >>> big endian. Presumably these are mostly the virtual GPU drivers. > >>> > >>> Additonally we'll make the mapping performed by > >>> drm_mode_legacy_fb_format() > >>> driver controlled. That way drivers that got changed to follow CPU > >>> endianness can return a framebuffer that matches CPU endianness. And > >>> drivers that expect the GPU endianness to not depend on the CPU > >>> endianness will keep working as they do now. The downside is that users > >>> of the legacy addfb ioctl will need to magically know which endianness > >>> they will get, but that is apparently already the case. And users of > >>> addfb2 will keep on specifying the endianness explicitly with > >>> DRM_FORMAT_BIG_ENDIAN vs. 0. > >> > >> I'm afraid it's not that simple. > >> > >> The display hardware of older (pre-R600 generation) Radeon GPUs does not > >> support the "big endian" formats directly. In order to allow userspace > >> to access pixel data in native endianness with the CPU, we instead use > >> byte-swapping functionality which only affects CPU access. > > > > OK, I'm getting confused. Based on our irc discussion I got the > > impression you don't byte swap CPU accesses. > > Sorry for the confusion. The radeon kernel driver does support > byte-swapping for CPU access to VRAM with pre-R600 GPUs, and this is > used for fbdev emulation. What I meant on IRC is that the xf86-video-ati > radeon driver doesn't make use of this, mostly because it only applies > while a BO is in VRAM, and userspace can't control when that's the case > (while a BO isn't being scanned out). So that was my other question. So if someone just creates a bo, I presume ttm can more or less move it between system memory and vram at any time. So if we then mmap the bo, does it mean the CPU will see the bytes in different order depending on where the bo happens to live at the time the CPU access happens? And how would that work wih dumb bos? Would they be forced to live in vram? I see it's passing VRAM as the initial domain, but I can't quickly see whether that would mean it can't even be moved out. > > > > But since you do, how do you deal with mixing 8bpp vs. 16bpp vs. 32bpp? > > The byte-swapping is configured per-BO via the > RADEON_TILING_SWAP_16/32BIT flags. Which translates into usage of the surface regs it seems. So I wasn't totally crazy to think that such things existed :) -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100784] Fullscreen fade transitions in starsector run at a few frames per second
https://bugs.freedesktop.org/show_bug.cgi?id=100784 Bug ID: 100784 Summary: Fullscreen fade transitions in starsector run at a few frames per second Product: Mesa Version: 17.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: j...@moozaad.co.uk QA Contact: dri-devel@lists.freedesktop.org The game generally runs at the 60fps cap with this exception. Game forum bug link: http://fractalsoftworks.com/forum/index.php?topic=11972.0 http://i.imgur.com/5zbBSCc.png (see the double prongs on the draw calls, the buffer wait is just an alt-tab) I'm running Opensuse Tumbleweed (mesa 17.0.3/kernel 4.10.10) on a Fury X. Reproduction: Launch star sector (any resolution, windowed or fullscreen) Get into the game (skip tutorials etc) Initiated a UI transition (easiest is press tab for map, left click a planet to show planet info) I'm working on getting an API trace. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100785] [regression, bisected] arb_gpu_shader5 piglit fail
https://bugs.freedesktop.org/show_bug.cgi?id=100785 Bug ID: 100785 Summary: [regression, bisected] arb_gpu_shader5 piglit fail Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel@lists.freedesktop.org Reporter: hi-an...@yandex.ru QA Contact: dri-devel@lists.freedesktop.org Failing tests: bin/arb_gpu_shader5-interpolateAtSample -auto -fbo bin/arb_gpu_shader5-interpolateAtSample-nonconst -auto -fbo Bisection result: eb8aa93c03ee89ffd3041d41b6293e4b282b6ce6 is the first bad commit commit eb8aa93c03ee89ffd3041d41b6293e4b282b6ce6 Author: Timothy Arceri Date: Fri Apr 14 16:25:58 2017 +1000 glsl: disable varying packing for varying used by interpolateAt* Currently the NIR backends depend on GLSL IR copy propagation to fix up the interpolateAt* function params after varying packing changes the shader input to a global. It's possible copy propagation might not always do what we need it too, and we also shouldn't depend on optimisations to do this type of thing for us. I'm not sure if the same is true for TGSI, but the following commit should re-enable packing for most cases in a safer way, so we just disable it everywhere. No change in shader-db for i965 (BDW) Acked-by: Elie Tournier Reviewed-by: Kenneth Graunke Reverting the commit fixes the problem. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100785] [regression, bisected] arb_gpu_shader5 piglit fail
https://bugs.freedesktop.org/show_bug.cgi?id=100785
--- Comment #1 from Hi-Angel ---
Ah, a fail output:
$ LD_LIBRARY_PATH=/home/constantine/Projects/mesa/lib
LIBGL_DRIVERS_PATH=/home/constantine/Projects/mesa/lib/gallium
/home/constantine/Projects/piglit/bin/arb_gpu_shader5-interpolateAtSample -auto
-fbo
Probe color at (0,0)
Expected: 0 255 0
Observed: 20 195 0
PIGLIT: {"result": "fail" }
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 01/11] drm/atomic: Handle aspect ratio and scaling mode in core, v3.
This is required to for i915 to convert connector properties to atomic.
Changes since v1:
- Add docbook info. (danvet)
- Change picture_aspect_ratio to enum hdmi_picture_aspect.
Changes since v2:
- For i915 put the properties in connector_state, to prevent
regressions where the property doesn't match the real state.
Signed-off-by: Maarten Lankhorst
Cc: dri-devel@lists.freedesktop.org
Acked-by: Dave Airlie
Link:
http://patchwork.freedesktop.org/patch/msgid/1492074937-4774-1-git-send-email-maarten.lankho...@linux.intel.com
Reviewed-by: Daniel Vetter #v2
[mlankhorst: Change ASPECT_* to ASPECT_\*, based on danvet's suggestion]
---
drivers/gpu/drm/drm_atomic.c | 8
drivers/gpu/drm/i915/intel_dp.c| 2 ++
drivers/gpu/drm/i915/intel_dsi.c | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 1 +
drivers/gpu/drm/i915/intel_lvds.c | 2 ++
drivers/gpu/drm/i915/intel_modes.c | 4 +++-
drivers/gpu/drm/i915/intel_sdvo.c | 1 +
include/drm/drm_connector.h| 16
8 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 30229ab719c0..25ea6f797a54 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1123,6 +1123,10 @@ int drm_atomic_connector_set_property(struct
drm_connector *connector,
*/
if (state->link_status != DRM_LINK_STATUS_GOOD)
state->link_status = val;
+ } else if (property == config->aspect_ratio_property) {
+ state->picture_aspect_ratio = val;
+ } else if (property == config->scaling_mode_property) {
+ state->scaling_mode = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1199,6 +1203,10 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->tv.hue;
} else if (property == config->link_status_property) {
*val = state->link_status;
+ } else if (property == config->aspect_ratio_property) {
+ *val = state->picture_aspect_ratio;
+ } else if (property == config->scaling_mode_property) {
+ *val = state->scaling_mode;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 08834f74d396..6686ac98c4ee 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4902,6 +4902,7 @@ intel_dp_set_property(struct drm_connector *connector,
return 0;
}
intel_connector->panel.fitting_mode = val;
+ connector->state->scaling_mode = val;
goto done;
}
@@ -5192,6 +5193,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
connector->dev->mode_config.scaling_mode_property,
DRM_MODE_SCALE_ASPECT);
intel_connector->panel.fitting_mode = DRM_MODE_SCALE_ASPECT;
+ connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
}
}
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 3ffe8b1f1d48..35adbcc2e3f3 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1616,6 +1616,7 @@ static int intel_dsi_set_property(struct drm_connector
*connector,
return 0;
intel_connector->panel.fitting_mode = val;
+ connector->state->scaling_mode = val;
}
crtc = connector->state->crtc;
@@ -1682,6 +1683,7 @@ static void intel_dsi_add_properties(struct
intel_connector *connector)
dev->mode_config.scaling_mode_property,
DRM_MODE_SCALE_ASPECT);
connector->panel.fitting_mode = DRM_MODE_SCALE_ASPECT;
+ connector->base.state->scaling_mode = DRM_MODE_SCALE_ASPECT;
}
}
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 6efc3cb8c471..2b1e806319b9 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1662,6 +1662,7 @@ intel_hdmi_set_property(struct drm_connector *connector,
default:
return -EINVAL;
}
+ connector->state->picture_aspect_ratio = val;
goto done;
}
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 8b942ef2b3ec..5d9c1de0702b 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -618,6 +618,7 @@ static int
[PATCH v5 02/11] drm/core: Allow attaching custom scaling mode properties
Some connectors may not allow all scaling mode properties, this function will
allow
creating the scaling mode property with only the supported subset.
This will make it possible to convert i915 connectors to atomic.
Signed-off-by: Maarten Lankhorst
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_atomic.c| 3 ++-
drivers/gpu/drm/drm_connector.c | 45 +
include/drm/drm_connector.h | 5 +
3 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 25ea6f797a54..21db00d9a933 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1125,7 +1125,8 @@ int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
- } else if (property == config->scaling_mode_property) {
+ } else if (property == config->scaling_mode_property ||
+ property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9f847615ac74..49baa21b4ce7 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -954,6 +954,7 @@ int drm_mode_create_scaling_mode_property(struct drm_device
*dev)
drm_scaling_mode_enum_list,
ARRAY_SIZE(drm_scaling_mode_enum_list));
+
dev->mode_config.scaling_mode_property = scaling_mode;
return 0;
@@ -961,6 +962,50 @@ int drm_mode_create_scaling_mode_property(struct
drm_device *dev)
EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
/**
+ * drm_mode_connector_attach_custom_scaling_mode_property - TODO
+ */
+int drm_mode_connector_attach_custom_scaling_mode_property(struct
drm_connector *connector,
+ u32
scaling_mode_mask,
+ u32 default_scaler)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *scaling_mode_property;
+ int i;
+
+ if (!scaling_mode_mask)
+ scaling_mode_mask = ~0U;
+
+ scaling_mode_mask &= (1U << ARRAY_SIZE(drm_scaling_mode_enum_list)) - 1;
+
+ scaling_mode_property =
+ drm_property_create(dev, 0, "scaling mode",
+ hweight32(scaling_mode_mask));
+
+ for (i = 0; i < ARRAY_SIZE(drm_scaling_mode_enum_list); i++)
+ if (BIT(i) & scaling_mode_mask) {
+ int ret;
+
+ ret = drm_property_add_enum(scaling_mode_property, i,
+
drm_scaling_mode_enum_list[i].type,
+
drm_scaling_mode_enum_list[i].name);
+
+ if (ret) {
+ drm_property_destroy(dev,
scaling_mode_property);
+
+ return ret;
+ }
+ }
+
+ drm_object_attach_property(&connector->base,
+ scaling_mode_property, default_scaler);
+
+ connector->scaling_mode_property = scaling_mode_property;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_connector_attach_custom_scaling_mode_property);
+
+/**
* drm_mode_create_aspect_ratio_property - create aspect ratio property
* @dev: DRM device
*
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 934143720e5a..f55ae02135c2 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -770,6 +770,8 @@ struct drm_connector {
struct drm_property_blob *edid_blob_ptr;
struct drm_object_properties properties;
+ struct drm_property *scaling_mode_property;
+
/**
* @path_blob_ptr:
*
@@ -969,6 +971,9 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
unsigned int num_modes,
const char * const modes[]);
int drm_mode_create_scaling_mode_property(struct drm_device *dev);
+int drm_mode_connector_attach_custom_scaling_mode_property(struct
drm_connector *connector,
+ u32
scaling_mode_mask,
+ u32 default_value);
int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.or
[Bug 100784] Fullscreen fade transitions in starsector run at a few frames per second
https://bugs.freedesktop.org/show_bug.cgi?id=100784 --- Comment #1 from Jon --- API trace https://www.dropbox.com/s/i8do4s47w77uaow/java.trace?dl=0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors
Am 12.04.2017 um 18:55 schrieb Bjorn Helgaas: [SNIP] I think the specs would envision this being done via an ACPI _SRS method on the PNP0A03 host bridge device. That would be a more generic path that would work on any host bridge. Did you explore that possibility? I would prefer to avoid adding device-specific code if that's possible. I've checked quite a few boards, but none of them actually implements it this way. M$ is working on a new ACPI table to enable this vendor neutral, but I guess that will still take a while. I want to support this for all AMD CPU released in the past 5 years or so, so we are going to deal with a bunch of older boards as well. I've never seen _SRS for host bridges either. I'm curious about what sort of new table will be proposed. It seems like the existing ACPI resource framework could manage it, but I certainly don't know all the issues. No idea either since I'm not involved into that. My job is to get it working on the existing hw generations and that alone is enough work :) My best guess is that MS is going to either make _SRS on the host bridge or a pre-configured 64bit window mandatory for the BIOS. + pci_bus_add_resource(dev->bus, res, 0); We would need some sort of printk here to explain how this new window magically appeared. Good point, consider this done. But is this actually the right place of doing it? Or would you prefer something to be added to the probing code? I think those fixups are applied a bit later, aren't they? Logically, this should be done before we enumerate the PCI devices below the host bridge, so a PCI device fixup is not the ideal place for it, but it might be the most practical. Since the modification must be done on a device connected to the root bus I run into quite a chicken and egg problem if I try to do it before the enumeration. I could imagine some sort of quirk like the ones in drivers/pnp/quirks.c that could add the window to the host bridge _CRS and program the bridge to open it. But the PCI host bridges aren't handled through the path that applies those fixups, and it would be messy to identify your bridges (you currently use PCI vendor/device IDs, which are only available after enumerating the device). So this doesn't seem like a viable strategy. I've tried that, but gave up rather quickly. Looks like the current approach indeed work find even with "pci=realloc", so I'm going to stick with that. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] PCI: add functionality for resizing resources v3
From: Christian König
This allows device drivers to request resizing their BARs.
The function only tries to reprogram the windows of the bridge directly above
the requesting device and only the BAR of the same type (usually mem, 64bit,
prefetchable). This is done to make sure not to disturb other drivers by
changing the BARs of their devices.
If reprogramming the bridge BAR fails the old status is restored and -ENOSPC
returned to the calling device driver.
v2: rebase on changes in rbar support
v3: style cleanups, fail if memory decoding is enabled or resources
still allocated, resize all unused bridge BARs,
drop calling pci_reenable_device
Signed-off-by: Christian König
---
drivers/pci/setup-bus.c | 102
drivers/pci/setup-res.c | 60
include/linux/pci.h | 3 ++
3 files changed, 165 insertions(+)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index f30ca75..39351cf 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1923,6 +1923,108 @@ void pci_assign_unassigned_bridge_resources(struct
pci_dev *bridge)
}
EXPORT_SYMBOL_GPL(pci_assign_unassigned_bridge_resources);
+int pci_reassign_bridge_resources(struct pci_dev *bridge, unsigned long type)
+{
+ const unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
+ IORESOURCE_PREFETCH | IORESOURCE_MEM_64;
+
+ struct pci_dev_resource *dev_res;
+ LIST_HEAD(saved);
+ LIST_HEAD(added);
+ LIST_HEAD(failed);
+ unsigned i;
+ int ret = 0;
+
+ /* Walk to the root BUS, releasing bridge BARs when possible */
+ while (1) {
+ for (i = PCI_BRIDGE_RESOURCES; i < PCI_BRIDGE_RESOURCE_END;
+i++) {
+ struct resource *res = &bridge->resource[i];
+
+ if ((res->flags & type_mask) != (type & type_mask))
+ continue;
+
+ /* Ignore BARs which are still in use */
+ if (res->child)
+ continue;
+
+ ret = add_to_list(&saved, bridge, res, 0, 0);
+ if (ret)
+ goto cleanup;
+
+ if (res->parent)
+ release_resource(res);
+ res->start = 0;
+ res->end = 0;
+ dev_info(&bridge->dev, "BAR %d: released %pR\n",
+i, res);
+ break;
+ }
+ if (i == PCI_BRIDGE_RESOURCE_END)
+ break;
+
+ if (!bridge->bus || !bridge->bus->self)
+ break;
+
+ bridge = bridge->bus->self;
+ }
+
+ if (list_empty(&saved))
+ return -ENOENT;
+
+ __pci_bus_size_bridges(bridge->subordinate, &added);
+ __pci_bridge_assign_resources(bridge, &added, &failed);
+ BUG_ON(!list_empty(&added));
+
+ if (!list_empty(&failed)) {
+ ret = -ENOSPC;
+ goto cleanup;
+ }
+
+
+ list_for_each_entry(dev_res, &saved, list) {
+ /* Skip the bridge we just assigned resources for. */
+ if (bridge == dev_res->dev)
+ continue;
+
+ bridge = dev_res->dev;
+ pci_setup_bridge(bridge->subordinate);
+ }
+
+ free_list(&saved);
+ free_list(&failed);
+ return ret;
+
+cleanup:
+ /* restore size and flags */
+ list_for_each_entry(dev_res, &failed, list) {
+ struct resource *res = dev_res->res;
+
+ res->start = dev_res->start;
+ res->end = dev_res->end;
+ res->flags = dev_res->flags;
+ }
+ free_list(&failed);
+
+ /* Revert to the old configuration */
+ list_for_each_entry(dev_res, &saved, list) {
+ struct resource *res = dev_res->res;
+
+ bridge = dev_res->dev;
+ i = res - bridge->resource;
+
+ res->start = dev_res->start;
+ res->end = dev_res->end;
+ res->flags = dev_res->flags;
+
+ pci_claim_resource(bridge, i);
+ pci_setup_bridge(bridge->subordinate);
+ }
+ free_list(&saved);
+
+ return ret;
+}
+
void pci_assign_unassigned_bus_resources(struct pci_bus *bus)
{
struct pci_dev *dev;
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 9526e34..0d40adb 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -363,6 +363,66 @@ int pci_reassign_resource(struct pci_dev *dev, int resno,
resource_size_t addsiz
return 0;
}
+void pci_release_resource(struct pci_dev *dev, int resno)
+{
+ struct resource *res = dev->resource + resno;
+
+ release_resource(res);
+ res->end = resource_size(
[PATCH 3/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v2
From: Christian König
Most BIOS don't enable this because of compatibility reasons.
Manually enable a 64bit BAR of 64GB size so that we have
enough room for PCI devices.
v2: style cleanups, increase size, add resource name, set correct flags,
print message that windows was added
Signed-off-by: Christian König
---
arch/x86/pci/fixup.c | 53
1 file changed, 53 insertions(+)
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 6d52b94..8d949c4 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -571,3 +571,56 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x2fc0,
pci_invalid_bar);
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6f60, pci_invalid_bar);
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fa0, pci_invalid_bar);
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fc0, pci_invalid_bar);
+
+static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
+{
+ uint32_t base, limit, high;
+ struct resource *res, *conflict;
+ unsigned i;
+
+ for (i = 0; i < 8; ++i) {
+ pci_read_config_dword(dev, 0x80 + i * 0x8, &base);
+ pci_read_config_dword(dev, 0x180 + i * 0x4, &high);
+
+ /* Is this slot free? */
+ if ((base & 0x3) == 0x0)
+ break;
+
+ base >>= 8;
+ base |= high << 24;
+
+ /* Abort if a slot already configures a 64bit BAR. */
+ if (base > 0x1)
+ return;
+ }
+ if (i == 8)
+ return;
+
+ res = kzalloc(sizeof(*res), GFP_KERNEL);
+ if (!res)
+ return;
+
+ res->name = "PCI Bus :00";
+ res->flags = IORESOURCE_PREFETCH | IORESOURCE_MEM |
+ IORESOURCE_MEM_64 | IORESOURCE_WINDOW;
+ res->start = 0x1;
+ res->end = 0xfd - 1;
+
+ /* Just grab the free area behind system memory for this */
+ while ((conflict = request_resource_conflict(&iomem_resource, res)))
+ res->start = conflict->end + 1;
+
+ dev_info(&dev->dev, "adding root bus resource %pR\n", res);
+
+ base = ((res->start >> 8) & 0xff00) | 0x3;
+ limit = ((res->end + 1) >> 8) & 0xff00;
+ high = ((res->start >> 40) & 0xff) |
+ res->end + 1) >> 40) & 0xff) << 16);
+
+ pci_write_config_dword(dev, 0x180 + i * 0x4, high);
+ pci_write_config_dword(dev, 0x84 + i * 0x8, limit);
+ pci_write_config_dword(dev, 0x80 + i * 0x8, base);
+
+ pci_bus_add_resource(dev->bus, res, 0);
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x141b, pci_amd_enable_64bit_bar);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] PCI: add resizeable BAR infrastructure v4
From: Christian König
Just the defines and helper functions to read the possible sizes of a BAR and
update it's size.
See
https://pcisig.com/sites/default/files/specification_documents/ECN_Resizable-BAR_24Apr2008.pdf
and PCIe r3.1, sec 7.22.
This is useful for hardware with large local storage (mostly GFX) which only
expose 256MB BARs initially to be compatible with 32bit systems.
v2: provide read helper as well
v3: improve function names, use unsigned values, add better comments.
v4: move definition, improve commit message, s/bar/BAR/
Signed-off-by: Christian König
---
drivers/pci/pci.c | 115 ++
drivers/pci/pci.h | 4 ++
include/uapi/linux/pci_regs.h | 11 +++-
3 files changed, 128 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index ba34907..c2d9f78 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2944,6 +2944,121 @@ bool pci_acs_path_enabled(struct pci_dev *start,
}
/**
+ * pci_rbar_get_possible_sizes - get possible sizes for BAR
+ * @dev: PCI device
+ * @bar: BAR to query
+ *
+ * Get the possible sizes of a resizeable BAR as bitmask defined in the spec
+ * (bit 0=1MB, bit 19=512GB). Returns 0 if BAR isn't resizeable.
+ */
+u32 pci_rbar_get_possible_sizes(struct pci_dev *pdev, int bar)
+{
+ unsigned pos, nbars;
+ u32 ctrl, cap;
+ unsigned i;
+
+ pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
+ if (!pos)
+ return 0;
+
+ pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+ nbars = (ctrl & PCI_REBAR_CTRL_NBAR_MASK) >> PCI_REBAR_CTRL_NBAR_SHIFT;
+
+ for (i = 0; i < nbars; ++i, pos += 8) {
+ int bar_idx;
+
+ pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+ bar_idx = (ctrl & PCI_REBAR_CTRL_BAR_IDX_MASK) >>
+ PCI_REBAR_CTRL_BAR_IDX_SHIFT;
+ if (bar_idx != bar)
+ continue;
+
+ pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap);
+ return (cap & PCI_REBAR_CTRL_SIZES_MASK) >>
+ PCI_REBAR_CTRL_SIZES_SHIFT;
+ }
+
+ return 0;
+}
+
+/**
+ * pci_rbar_get_current_size - get the current size of a BAR
+ * @dev: PCI device
+ * @bar: BAR to set size to
+ *
+ * Read the size of a BAR from the resizeable BAR config.
+ * Returns size if found or negativ error code.
+ */
+int pci_rbar_get_current_size(struct pci_dev *pdev, int bar)
+{
+ unsigned pos, nbars;
+ u32 ctrl;
+ unsigned i;
+
+ pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
+ if (!pos)
+ return -ENOTSUPP;
+
+ pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+ nbars = (ctrl & PCI_REBAR_CTRL_NBAR_MASK) >> PCI_REBAR_CTRL_NBAR_SHIFT;
+
+ for (i = 0; i < nbars; ++i, pos += 8) {
+ int bar_idx;
+
+ pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+ bar_idx = (ctrl & PCI_REBAR_CTRL_BAR_IDX_MASK) >>
+ PCI_REBAR_CTRL_BAR_IDX_SHIFT;
+ if (bar_idx != bar)
+ continue;
+
+ return (ctrl & PCI_REBAR_CTRL_BAR_SIZE_MASK) >>
+ PCI_REBAR_CTRL_BAR_SIZE_SHIFT;
+ }
+
+ return -ENOENT;
+}
+
+/**
+ * pci_rbar_set_size - set a new size for a BAR
+ * @dev: PCI device
+ * @bar: BAR to set size to
+ * @size: new size as defined in the spec (log2(size in bytes) - 20)
+ *
+ * Set the new size of a BAR as defined in the spec (0=1MB, 19=512GB).
+ * Returns true if resizing was successful, false otherwise.
+ */
+int pci_rbar_set_size(struct pci_dev *pdev, int bar, int size)
+{
+ unsigned pos, nbars;
+ u32 ctrl;
+ unsigned i;
+
+ pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
+ if (!pos)
+ return -ENOTSUPP;
+
+ pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+ nbars = (ctrl & PCI_REBAR_CTRL_NBAR_MASK) >> PCI_REBAR_CTRL_NBAR_SHIFT;
+
+ for (i = 0; i < nbars; ++i, pos += 8) {
+ int bar_idx;
+
+ pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+ bar_idx = (ctrl & PCI_REBAR_CTRL_BAR_IDX_MASK) >>
+ PCI_REBAR_CTRL_BAR_IDX_SHIFT;
+ if (bar_idx != bar)
+ continue;
+
+ ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE_MASK;
+ ctrl |= size << PCI_REBAR_CTRL_BAR_SIZE_SHIFT;
+ pci_write_config_dword(pdev, pos + PCI_REBAR_CTRL, ctrl);
+ return 0;
+ }
+
+ return -ENOENT;
+}
+
+/**
* pci_swizzle_interrupt_pin - swizzle INTx for device behind bridge
* @dev: the PCI device
* @pin: the INTx pin (1=INTA, 2=INTB, 3=INTC, 4=INTD)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 4518562..1d27c22 100644
--- a/drivers/pci/pci.h
+++ b/driv
Resizeable PCI BAR support V4
Hi everyone, This is the fourth incarnation of this set of patches. It enables device drivers to resize and most likely also relocate the PCI BAR of devices they manage to allow the CPU to access all of the device local memory at once. This is very useful for GFX device drivers where the default PCI BAR is only about 256MB in size for compatibility reasons, but the device easily have multiple gigabyte of local memory. Some changes since V3: 1. A lot of minor style cleanups. 2. Make internal functions for changing BARs directly private to the PCI subsystem. 3. Fail if any BAR is still in use when we try to change it. 4. Handle intermediate bridges as well. 5. Print some more messages when changing something. Please review and/or comment, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2
From: Christian König
Try to resize BAR0 to let CPU access all of VRAM.
v2: rebased, style cleanups, disable mem decode before resize,
handle gmc_v9 as well, round size up to power of two.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37 ++
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 ---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 ---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 10
5 files changed, 54 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 4a16e3c..9484062 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1879,6 +1879,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
*adev, struct ttm_tt *ttm,
struct ttm_mem_reg *mem);
void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc,
u64 base);
void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc *mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
int amdgpu_ttm_init(struct amdgpu_device *adev);
void amdgpu_ttm_fini(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a09ad3cf..d5ca77a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -695,6 +695,43 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
struct amdgpu_mc *mc)
mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
}
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev)
+{
+ u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size);
+ u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) -1;
+ u16 cmd;
+ int r;
+
+ /* Free the doorbell mapping, it most likely needs to move as well */
+ amdgpu_doorbell_fini(adev);
+ pci_release_resource(adev->pdev, 2);
+
+ /* Disable memory decoding while we change the BAR addresses and size */
+ pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd);
+ pci_write_config_word(adev->pdev, PCI_COMMAND,
+ cmd & ~PCI_COMMAND_MEMORY);
+
+ r = pci_resize_resource(adev->pdev, 0, rbar_size);
+ if (r == -ENOSPC)
+ DRM_INFO("Not enough PCI address space for a large BAR.");
+ else if (r && r != -ENOTSUPP)
+ DRM_ERROR("Problem resizing BAR0 (%d).", r);
+
+ pci_write_config_word(adev->pdev, PCI_COMMAND, cmd);
+
+ /* When the doorbell BAR isn't available we have no chance of
+* using the device.
+*/
+ BUG_ON(amdgpu_doorbell_init(adev));
+}
+
/*
* GPU helpers function.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index a9083a1..ae71524 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -372,13 +372,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
}
adev->mc.vram_width = numchan * chansize;
}
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+ adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
#ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 4ac9978..1655de2 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -534,13 +534,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device *adev)
}
adev->mc.vram_width = numchan * chansize;
}
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_bas
Re: Resizeable PCI BAR support V4
On Tue, Apr 25, 2017 at 4:19 PM, Christian König wrote: > Hi everyone, > > This is the fourth incarnation of this set of patches. It would be nice if you put (next time) version of the series in each patch. Usually it's done quite easy by passing -vX (where X is version number) to git format-patch. > It enables device > drivers to resize and most likely also relocate the PCI BAR of devices > they manage to allow the CPU to access all of the device local memory at once. > > This is very useful for GFX device drivers where the default PCI BAR is only > about 256MB in size for compatibility reasons, but the device easily have > multiple gigabyte of local memory. > > Some changes since V3: > 1. A lot of minor style cleanups. > 2. Make internal functions for changing BARs directly private to the PCI > subsystem. > 3. Fail if any BAR is still in use when we try to change it. > 4. Handle intermediate bridges as well. > 5. Print some more messages when changing something. > > Please review and/or comment, Would look later (perhaps this week), -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2
On Tue, Apr 25, 2017 at 9:19 AM, Christian König
wrote:
> From: Christian König
>
> Try to resize BAR0 to let CPU access all of VRAM.
>
> v2: rebased, style cleanups, disable mem decode before resize,
> handle gmc_v9 as well, round size up to power of two.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37
> ++
> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 ---
> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 ---
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 10
> 5 files changed, 54 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 4a16e3c..9484062 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1879,6 +1879,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
> *adev, struct ttm_tt *ttm,
> struct ttm_mem_reg *mem);
> void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc,
> u64 base);
> void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc *mc);
> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
> void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
> int amdgpu_ttm_init(struct amdgpu_device *adev);
> void amdgpu_ttm_fini(struct amdgpu_device *adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index a09ad3cf..d5ca77a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -695,6 +695,43 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
> struct amdgpu_mc *mc)
> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
> }
>
> +/**
> + * amdgpu_resize_bar0 - try to resize BAR0
> + *
> + * @adev: amdgpu_device pointer
> + *
> + * Try to resize BAR0 to make all VRAM CPU accessible.
> + */
> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
I'd suggest renaming this to amdgpu_device_resize_bar() to try and
impose some consistency in this file, but not a big deal either way.
> +{
> + u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size);
> + u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) -1;
> + u16 cmd;
> + int r;
> +
> + /* Free the doorbell mapping, it most likely needs to move as well */
> + amdgpu_doorbell_fini(adev);
> + pci_release_resource(adev->pdev, 2);
This should check for if (adev->asic_type >= CHIP_BONAIRE) since SI
didn't have doorbells.
> +
> + /* Disable memory decoding while we change the BAR addresses and size
> */
> + pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd);
> + pci_write_config_word(adev->pdev, PCI_COMMAND,
> + cmd & ~PCI_COMMAND_MEMORY);
> +
> + r = pci_resize_resource(adev->pdev, 0, rbar_size);
> + if (r == -ENOSPC)
> + DRM_INFO("Not enough PCI address space for a large BAR.");
> + else if (r && r != -ENOTSUPP)
> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
> +
> + pci_write_config_word(adev->pdev, PCI_COMMAND, cmd);
> +
> + /* When the doorbell BAR isn't available we have no chance of
> +* using the device.
> +*/
> + BUG_ON(amdgpu_doorbell_init(adev));
Same here.
> +}
> +
> /*
> * GPU helpers function.
> */
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> index a9083a1..ae71524 100644
What about SI (gmc_v6_0.c)?
Alex
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> @@ -372,13 +372,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
> }
> adev->mc.vram_width = numchan * chansize;
> }
> - /* Could aper size report 0 ? */
> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> /* size in MB on si */
> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
> 1024ULL;
>
> + if (!(adev->flags & AMD_IS_APU))
> + amdgpu_resize_bar0(adev);
> + adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> + adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> +
> #ifdef CONFIG_X86_64
> if (adev->flags & AMD_IS_APU) {
> adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> index 4ac9978..1655de2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> @@ -534,13 +534,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device
Re: [PATCH 3/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v2
On Tue, Apr 25, 2017 at 9:19 AM, Christian König
wrote:
> From: Christian König
>
> Most BIOS don't enable this because of compatibility reasons.
>
> Manually enable a 64bit BAR of 64GB size so that we have
> enough room for PCI devices.
>
> v2: style cleanups, increase size, add resource name, set correct flags,
> print message that windows was added
>
> Signed-off-by: Christian König
> ---
> arch/x86/pci/fixup.c | 53
>
> 1 file changed, 53 insertions(+)
>
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index 6d52b94..8d949c4 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -571,3 +571,56 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x2fc0,
> pci_invalid_bar);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6f60, pci_invalid_bar);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fa0, pci_invalid_bar);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fc0, pci_invalid_bar);
> +
> +static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
> +{
> + uint32_t base, limit, high;
> + struct resource *res, *conflict;
> + unsigned i;
> +
> + for (i = 0; i < 8; ++i) {
> + pci_read_config_dword(dev, 0x80 + i * 0x8, &base);
> + pci_read_config_dword(dev, 0x180 + i * 0x4, &high);
Might be nice to define names for the register offsets.
> +
> + /* Is this slot free? */
> + if ((base & 0x3) == 0x0)
> + break;
> +
> + base >>= 8;
> + base |= high << 24;
> +
> + /* Abort if a slot already configures a 64bit BAR. */
> + if (base > 0x1)
> + return;
> + }
> + if (i == 8)
> + return;
> +
> + res = kzalloc(sizeof(*res), GFP_KERNEL);
> + if (!res)
> + return;
> +
> + res->name = "PCI Bus :00";
> + res->flags = IORESOURCE_PREFETCH | IORESOURCE_MEM |
> + IORESOURCE_MEM_64 | IORESOURCE_WINDOW;
> + res->start = 0x1;
> + res->end = 0xfd - 1;
> +
> + /* Just grab the free area behind system memory for this */
> + while ((conflict = request_resource_conflict(&iomem_resource, res)))
> + res->start = conflict->end + 1;
> +
> + dev_info(&dev->dev, "adding root bus resource %pR\n", res);
> +
> + base = ((res->start >> 8) & 0xff00) | 0x3;
> + limit = ((res->end + 1) >> 8) & 0xff00;
> + high = ((res->start >> 40) & 0xff) |
> + res->end + 1) >> 40) & 0xff) << 16);
> +
> + pci_write_config_dword(dev, 0x180 + i * 0x4, high);
> + pci_write_config_dword(dev, 0x84 + i * 0x8, limit);
> + pci_write_config_dword(dev, 0x80 + i * 0x8, base);
Same here. Either way:
Reviewed-by: Alex Deucher
> +
> + pci_bus_add_resource(dev->bus, res, 0);
> +}
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x141b, pci_amd_enable_64bit_bar);
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] PCI: add resizeable BAR infrastructure v4
On Tue, Apr 25, 2017 at 9:19 AM, Christian König
wrote:
> From: Christian König
>
> Just the defines and helper functions to read the possible sizes of a BAR and
> update it's size.
>
> See
> https://pcisig.com/sites/default/files/specification_documents/ECN_Resizable-BAR_24Apr2008.pdf
> and PCIe r3.1, sec 7.22.
>
> This is useful for hardware with large local storage (mostly GFX) which only
> expose 256MB BARs initially to be compatible with 32bit systems.
>
> v2: provide read helper as well
> v3: improve function names, use unsigned values, add better comments.
> v4: move definition, improve commit message, s/bar/BAR/
>
> Signed-off-by: Christian König
Patches 1, 2:
Reviewed-by: Alex Deucher
> ---
> drivers/pci/pci.c | 115
> ++
> drivers/pci/pci.h | 4 ++
> include/uapi/linux/pci_regs.h | 11 +++-
> 3 files changed, 128 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index ba34907..c2d9f78 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2944,6 +2944,121 @@ bool pci_acs_path_enabled(struct pci_dev *start,
> }
>
> /**
> + * pci_rbar_get_possible_sizes - get possible sizes for BAR
> + * @dev: PCI device
> + * @bar: BAR to query
> + *
> + * Get the possible sizes of a resizeable BAR as bitmask defined in the spec
> + * (bit 0=1MB, bit 19=512GB). Returns 0 if BAR isn't resizeable.
> + */
> +u32 pci_rbar_get_possible_sizes(struct pci_dev *pdev, int bar)
> +{
> + unsigned pos, nbars;
> + u32 ctrl, cap;
> + unsigned i;
> +
> + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
> + if (!pos)
> + return 0;
> +
> + pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
> + nbars = (ctrl & PCI_REBAR_CTRL_NBAR_MASK) >>
> PCI_REBAR_CTRL_NBAR_SHIFT;
> +
> + for (i = 0; i < nbars; ++i, pos += 8) {
> + int bar_idx;
> +
> + pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
> + bar_idx = (ctrl & PCI_REBAR_CTRL_BAR_IDX_MASK) >>
> + PCI_REBAR_CTRL_BAR_IDX_SHIFT;
> + if (bar_idx != bar)
> + continue;
> +
> + pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap);
> + return (cap & PCI_REBAR_CTRL_SIZES_MASK) >>
> + PCI_REBAR_CTRL_SIZES_SHIFT;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * pci_rbar_get_current_size - get the current size of a BAR
> + * @dev: PCI device
> + * @bar: BAR to set size to
> + *
> + * Read the size of a BAR from the resizeable BAR config.
> + * Returns size if found or negativ error code.
> + */
> +int pci_rbar_get_current_size(struct pci_dev *pdev, int bar)
> +{
> + unsigned pos, nbars;
> + u32 ctrl;
> + unsigned i;
> +
> + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
> + if (!pos)
> + return -ENOTSUPP;
> +
> + pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
> + nbars = (ctrl & PCI_REBAR_CTRL_NBAR_MASK) >>
> PCI_REBAR_CTRL_NBAR_SHIFT;
> +
> + for (i = 0; i < nbars; ++i, pos += 8) {
> + int bar_idx;
> +
> + pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
> + bar_idx = (ctrl & PCI_REBAR_CTRL_BAR_IDX_MASK) >>
> + PCI_REBAR_CTRL_BAR_IDX_SHIFT;
> + if (bar_idx != bar)
> + continue;
> +
> + return (ctrl & PCI_REBAR_CTRL_BAR_SIZE_MASK) >>
> + PCI_REBAR_CTRL_BAR_SIZE_SHIFT;
> + }
> +
> + return -ENOENT;
> +}
> +
> +/**
> + * pci_rbar_set_size - set a new size for a BAR
> + * @dev: PCI device
> + * @bar: BAR to set size to
> + * @size: new size as defined in the spec (log2(size in bytes) - 20)
> + *
> + * Set the new size of a BAR as defined in the spec (0=1MB, 19=512GB).
> + * Returns true if resizing was successful, false otherwise.
> + */
> +int pci_rbar_set_size(struct pci_dev *pdev, int bar, int size)
> +{
> + unsigned pos, nbars;
> + u32 ctrl;
> + unsigned i;
> +
> + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
> + if (!pos)
> + return -ENOTSUPP;
> +
> + pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
> + nbars = (ctrl & PCI_REBAR_CTRL_NBAR_MASK) >>
> PCI_REBAR_CTRL_NBAR_SHIFT;
> +
> + for (i = 0; i < nbars; ++i, pos += 8) {
> + int bar_idx;
> +
> + pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
> + bar_idx = (ctrl & PCI_REBAR_CTRL_BAR_IDX_MASK) >>
> + PCI_REBAR_CTRL_BAR_IDX_SHIFT;
> + if (bar_idx != bar)
> + continue;
> +
> + ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE_MASK;
> + ctrl |= size << PCI_REBAR_CTRL_BAR_SIZE_SHIFT;
> + pci_write_con
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2
Am 25.04.2017 um 16:34 schrieb Alex Deucher:
On Tue, Apr 25, 2017 at 9:19 AM, Christian König
wrote:
From: Christian König
Try to resize BAR0 to let CPU access all of VRAM.
v2: rebased, style cleanups, disable mem decode before resize,
handle gmc_v9 as well, round size up to power of two.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37 ++
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 ---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 ---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 10
5 files changed, 54 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 4a16e3c..9484062 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1879,6 +1879,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
*adev, struct ttm_tt *ttm,
struct ttm_mem_reg *mem);
void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc,
u64 base);
void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc *mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
int amdgpu_ttm_init(struct amdgpu_device *adev);
void amdgpu_ttm_fini(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a09ad3cf..d5ca77a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -695,6 +695,43 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
struct amdgpu_mc *mc)
mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
}
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev)
I'd suggest renaming this to amdgpu_device_resize_bar() to try and
impose some consistency in this file, but not a big deal either way.
+{
+ u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size);
+ u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) -1;
+ u16 cmd;
+ int r;
+
+ /* Free the doorbell mapping, it most likely needs to move as well */
+ amdgpu_doorbell_fini(adev);
+ pci_release_resource(adev->pdev, 2);
This should check for if (adev->asic_type >= CHIP_BONAIRE) since SI
didn't have doorbells.
+
+ /* Disable memory decoding while we change the BAR addresses and size */
+ pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd);
+ pci_write_config_word(adev->pdev, PCI_COMMAND,
+ cmd & ~PCI_COMMAND_MEMORY);
+
+ r = pci_resize_resource(adev->pdev, 0, rbar_size);
+ if (r == -ENOSPC)
+ DRM_INFO("Not enough PCI address space for a large BAR.");
+ else if (r && r != -ENOTSUPP)
+ DRM_ERROR("Problem resizing BAR0 (%d).", r);
+
+ pci_write_config_word(adev->pdev, PCI_COMMAND, cmd);
+
+ /* When the doorbell BAR isn't available we have no chance of
+* using the device.
+*/
+ BUG_ON(amdgpu_doorbell_init(adev));
Same here.
+}
+
/*
* GPU helpers function.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index a9083a1..ae71524 100644
What about SI (gmc_v6_0.c)?
As far as I know there is no SI hardware with resizeable BAR support.
The all VI generation can do this, but I'm not 100% sure if there aren't
any Bonaires out there which can handle it as well that's why I added
gmc_v7 support.
Still need to double check that.
Christian.
Alex
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -372,13 +372,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
}
adev->mc.vram_width = numchan * chansize;
}
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+ adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
#ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 4ac9978..1655de2 100644
--- a/drivers/gpu/drm
Re: [PATCH v5 02/11] drm/core: Allow attaching custom scaling mode properties
On Tue, Apr 25, 2017 at 01:55:26PM +0200, Maarten Lankhorst wrote:
> Some connectors may not allow all scaling mode properties, this function will
> allow
> creating the scaling mode property with only the supported subset.
>
> This will make it possible to convert i915 connectors to atomic.
>
> Signed-off-by: Maarten Lankhorst
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_atomic.c| 3 ++-
> drivers/gpu/drm/drm_connector.c | 45
> +
> include/drm/drm_connector.h | 5 +
> 3 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 25ea6f797a54..21db00d9a933 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1125,7 +1125,8 @@ int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> state->link_status = val;
> } else if (property == config->aspect_ratio_property) {
> state->picture_aspect_ratio = val;
> - } else if (property == config->scaling_mode_property) {
> + } else if (property == config->scaling_mode_property ||
> +property == connector->scaling_mode_property) {
Since scaling_mode_property isn't part of the atomic ABI before this series,
have you considered just supporting scaling mode property on connectors for
atomic? Then you wouldn't need to check both, and you wouldn't have the issue of
stomping properties if they're both set in a commit.
> state->scaling_mode = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 9f847615ac74..49baa21b4ce7 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -954,6 +954,7 @@ int drm_mode_create_scaling_mode_property(struct
> drm_device *dev)
> drm_scaling_mode_enum_list,
> ARRAY_SIZE(drm_scaling_mode_enum_list));
>
> +
nit: kruft.
> dev->mode_config.scaling_mode_property = scaling_mode;
>
> return 0;
> @@ -961,6 +962,50 @@ int drm_mode_create_scaling_mode_property(struct
> drm_device *dev)
> EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>
> /**
> + * drm_mode_connector_attach_custom_scaling_mode_property - TODO
It would be nice to fill in this TODO
> + */
> +int drm_mode_connector_attach_custom_scaling_mode_property(struct
> drm_connector *connector,
> +u32
> scaling_mode_mask,
> +u32 default_scaler)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_property *scaling_mode_property;
> + int i;
> +
> + if (!scaling_mode_mask)
> + scaling_mode_mask = ~0U;
It's hard to interpret this code without the docs above, but it seems like we're
just covering the case where the caller interprets a mask of 0 as "don't care".
I'd rather not try to be smart about interpreting invalid input, instead, I'd
prefer just to return -EINVAL if scaling_mode_mask is 0 after the next line.
> +
> + scaling_mode_mask &= (1U << ARRAY_SIZE(drm_scaling_mode_enum_list)) - 1;
scaling_mode_mask &= BIT(ARRAY_SIZE(drm_scaling_mode_enum_list)) - 1;
> +
> + scaling_mode_property =
> + drm_property_create(dev, 0, "scaling mode",
> + hweight32(scaling_mode_mask));
> +
> + for (i = 0; i < ARRAY_SIZE(drm_scaling_mode_enum_list); i++)
> + if (BIT(i) & scaling_mode_mask) {
nit: You can save a level of indentation if you do:
if (!(BIT(i) & scaling_mode_mask))
continue;
> + int ret;
> +
> + ret = drm_property_add_enum(scaling_mode_property, i,
> +
> drm_scaling_mode_enum_list[i].type,
> +
> drm_scaling_mode_enum_list[i].name);
> +
> + if (ret) {
> + drm_property_destroy(dev,
> scaling_mode_property);
> +
nit: extra line
> + return ret;
> + }
> + }
> +
> + drm_object_attach_property(&connector->base,
> +scaling_mode_property, default_scaler);
> +
> + connector->scaling_mode_property = scaling_mode_property;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_connector_attach_custom_scaling_mode_property);
> +
> +/**
> * drm_mode_create_aspect_ratio_property - create aspect ratio property
> * @dev: DRM device
> *
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 934143720e5a..f55ae02135c2 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2
On Tue, Apr 25, 2017 at 11:09 AM, Christian König
wrote:
> Am 25.04.2017 um 16:34 schrieb Alex Deucher:
>>
>> On Tue, Apr 25, 2017 at 9:19 AM, Christian König
>> wrote:
>>>
>>> From: Christian König
>>>
>>> Try to resize BAR0 to let CPU access all of VRAM.
>>>
>>> v2: rebased, style cleanups, disable mem decode before resize,
>>> handle gmc_v9 as well, round size up to power of two.
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37
>>> ++
>>> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 ---
>>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 ---
>>> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 10
>>> 5 files changed, 54 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> index 4a16e3c..9484062 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> @@ -1879,6 +1879,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
>>> amdgpu_device *adev, struct ttm_tt *ttm,
>>> struct ttm_mem_reg *mem);
>>> void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc
>>> *mc, u64 base);
>>> void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc
>>> *mc);
>>> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
>>> void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64
>>> size);
>>> int amdgpu_ttm_init(struct amdgpu_device *adev);
>>> void amdgpu_ttm_fini(struct amdgpu_device *adev);
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> index a09ad3cf..d5ca77a 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> @@ -695,6 +695,43 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
>>> struct amdgpu_mc *mc)
>>> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
>>> }
>>>
>>> +/**
>>> + * amdgpu_resize_bar0 - try to resize BAR0
>>> + *
>>> + * @adev: amdgpu_device pointer
>>> + *
>>> + * Try to resize BAR0 to make all VRAM CPU accessible.
>>> + */
>>> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
>>
>> I'd suggest renaming this to amdgpu_device_resize_bar() to try and
>> impose some consistency in this file, but not a big deal either way.
>>
>>> +{
>>> + u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size);
>>> + u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) -1;
>>> + u16 cmd;
>>> + int r;
>>> +
>>> + /* Free the doorbell mapping, it most likely needs to move as
>>> well */
>>> + amdgpu_doorbell_fini(adev);
>>> + pci_release_resource(adev->pdev, 2);
>>
>> This should check for if (adev->asic_type >= CHIP_BONAIRE) since SI
>> didn't have doorbells.
>>
>>> +
>>> + /* Disable memory decoding while we change the BAR addresses and
>>> size */
>>> + pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd);
>>> + pci_write_config_word(adev->pdev, PCI_COMMAND,
>>> + cmd & ~PCI_COMMAND_MEMORY);
>>> +
>>> + r = pci_resize_resource(adev->pdev, 0, rbar_size);
>>> + if (r == -ENOSPC)
>>> + DRM_INFO("Not enough PCI address space for a large
>>> BAR.");
>>> + else if (r && r != -ENOTSUPP)
>>> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
>>> +
>>> + pci_write_config_word(adev->pdev, PCI_COMMAND, cmd);
>>> +
>>> + /* When the doorbell BAR isn't available we have no chance of
>>> +* using the device.
>>> +*/
>>> + BUG_ON(amdgpu_doorbell_init(adev));
>>
>> Same here.
>>
>>> +}
>>> +
>>> /*
>>>* GPU helpers function.
>>>*/
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> index a9083a1..ae71524 100644
>>
>> What about SI (gmc_v6_0.c)?
>
>
> As far as I know there is no SI hardware with resizeable BAR support.
>
> The all VI generation can do this, but I'm not 100% sure if there aren't any
> Bonaires out there which can handle it as well that's why I added gmc_v7
> support.
>
> Still need to double check that.
I think NI or even evergreen supported resizeable bars in theory,
although I'm not sure if any boards were fused to expose it.
Alex
>
> Christian.
>
>
>>
>> Alex
>>
>>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> @@ -372,13 +372,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device
>>> *adev)
>>> }
>>> adev->mc.vram_width = numchan * chansize;
>>> }
>>> - /* Could aper size report 0 ? */
>>> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
>>> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
>>> /* size in MB on si */
>>>
[Bug 100781] "Black Mesa" will not Launch
https://bugs.freedesktop.org/show_bug.cgi?id=100781 katof...@protonmail.com changed: What|Removed |Added Resolution|NOTOURBUG |FIXED --- Comment #4 from katof...@protonmail.com --- Preloading did not work, but deleting it did, thank you. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 02/11] drm/core: Allow attaching custom scaling mode properties
On Tue, Apr 25, 2017 at 01:55:26PM +0200, Maarten Lankhorst wrote:
> Some connectors may not allow all scaling mode properties, this function will
> allow
> creating the scaling mode property with only the supported subset.
>
> This will make it possible to convert i915 connectors to atomic.
>
> Signed-off-by: Maarten Lankhorst
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_atomic.c| 3 ++-
> drivers/gpu/drm/drm_connector.c | 45
> +
> include/drm/drm_connector.h | 5 +
> 3 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 25ea6f797a54..21db00d9a933 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1125,7 +1125,8 @@ int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> state->link_status = val;
> } else if (property == config->aspect_ratio_property) {
> state->picture_aspect_ratio = val;
> - } else if (property == config->scaling_mode_property) {
> + } else if (property == config->scaling_mode_property ||
I would suggest ripping out the global property entirely, like I did for
the plane rotation property.
> +property == connector->scaling_mode_property) {
> state->scaling_mode = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 9f847615ac74..49baa21b4ce7 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -954,6 +954,7 @@ int drm_mode_create_scaling_mode_property(struct
> drm_device *dev)
> drm_scaling_mode_enum_list,
> ARRAY_SIZE(drm_scaling_mode_enum_list));
>
> +
> dev->mode_config.scaling_mode_property = scaling_mode;
>
> return 0;
> @@ -961,6 +962,50 @@ int drm_mode_create_scaling_mode_property(struct
> drm_device *dev)
> EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>
> /**
> + * drm_mode_connector_attach_custom_scaling_mode_property - TODO
> + */
> +int drm_mode_connector_attach_custom_scaling_mode_property(struct
> drm_connector *connector,
> +u32
> scaling_mode_mask,
> +u32 default_scaler)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_property *scaling_mode_property;
> + int i;
> +
> + if (!scaling_mode_mask)
> + scaling_mode_mask = ~0U;
> +
> + scaling_mode_mask &= (1U << ARRAY_SIZE(drm_scaling_mode_enum_list)) - 1;
> +
> + scaling_mode_property =
> + drm_property_create(dev, 0, "scaling mode",
> + hweight32(scaling_mode_mask));
> +
> + for (i = 0; i < ARRAY_SIZE(drm_scaling_mode_enum_list); i++)
> + if (BIT(i) & scaling_mode_mask) {
> + int ret;
> +
> + ret = drm_property_add_enum(scaling_mode_property, i,
> +
> drm_scaling_mode_enum_list[i].type,
> +
> drm_scaling_mode_enum_list[i].name);
> +
> + if (ret) {
> + drm_property_destroy(dev,
> scaling_mode_property);
> +
> + return ret;
> + }
> + }
> +
> + drm_object_attach_property(&connector->base,
> +scaling_mode_property, default_scaler);
> +
> + connector->scaling_mode_property = scaling_mode_property;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_connector_attach_custom_scaling_mode_property);
> +
> +/**
> * drm_mode_create_aspect_ratio_property - create aspect ratio property
> * @dev: DRM device
> *
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 934143720e5a..f55ae02135c2 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -770,6 +770,8 @@ struct drm_connector {
> struct drm_property_blob *edid_blob_ptr;
> struct drm_object_properties properties;
>
> + struct drm_property *scaling_mode_property;
> +
> /**
>* @path_blob_ptr:
>*
> @@ -969,6 +971,9 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
> unsigned int num_modes,
> const char * const modes[]);
> int drm_mode_create_scaling_mode_property(struct drm_device *dev);
> +int drm_mode_connector_attach_custom_scaling_mode_property(struct
> drm_connector *connector,
> +u32
> scaling_mode_mask,
> +
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2
Am 25.04.2017 um 17:14 schrieb Alex Deucher:
On Tue, Apr 25, 2017 at 11:09 AM, Christian König
wrote:
Am 25.04.2017 um 16:34 schrieb Alex Deucher:
On Tue, Apr 25, 2017 at 9:19 AM, Christian König
wrote:
From: Christian König
Try to resize BAR0 to let CPU access all of VRAM.
v2: rebased, style cleanups, disable mem decode before resize,
handle gmc_v9 as well, round size up to power of two.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37
++
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 ---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 ---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 10
5 files changed, 54 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 4a16e3c..9484062 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1879,6 +1879,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
amdgpu_device *adev, struct ttm_tt *ttm,
struct ttm_mem_reg *mem);
void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc
*mc, u64 base);
void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc
*mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64
size);
int amdgpu_ttm_init(struct amdgpu_device *adev);
void amdgpu_ttm_fini(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a09ad3cf..d5ca77a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -695,6 +695,43 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
struct amdgpu_mc *mc)
mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
}
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev)
I'd suggest renaming this to amdgpu_device_resize_bar() to try and
impose some consistency in this file, but not a big deal either way.
+{
+ u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size);
+ u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) -1;
+ u16 cmd;
+ int r;
+
+ /* Free the doorbell mapping, it most likely needs to move as
well */
+ amdgpu_doorbell_fini(adev);
+ pci_release_resource(adev->pdev, 2);
This should check for if (adev->asic_type >= CHIP_BONAIRE) since SI
didn't have doorbells.
+
+ /* Disable memory decoding while we change the BAR addresses and
size */
+ pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd);
+ pci_write_config_word(adev->pdev, PCI_COMMAND,
+ cmd & ~PCI_COMMAND_MEMORY);
+
+ r = pci_resize_resource(adev->pdev, 0, rbar_size);
+ if (r == -ENOSPC)
+ DRM_INFO("Not enough PCI address space for a large
BAR.");
+ else if (r && r != -ENOTSUPP)
+ DRM_ERROR("Problem resizing BAR0 (%d).", r);
+
+ pci_write_config_word(adev->pdev, PCI_COMMAND, cmd);
+
+ /* When the doorbell BAR isn't available we have no chance of
+* using the device.
+*/
+ BUG_ON(amdgpu_doorbell_init(adev));
Same here.
+}
+
/*
* GPU helpers function.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index a9083a1..ae71524 100644
What about SI (gmc_v6_0.c)?
As far as I know there is no SI hardware with resizeable BAR support.
The all VI generation can do this, but I'm not 100% sure if there aren't any
Bonaires out there which can handle it as well that's why I added gmc_v7
support.
Still need to double check that.
I think NI or even evergreen supported resizeable bars in theory,
although I'm not sure if any boards were fused to expose it.
In theory yes, in practice no.
Their PCIE config space defines the necessary registers, but I haven't
found any board from Evergreen, NI, SI or CIK generation where that is
actually validated.
Tonga is the first one I'm 100% sure that it is supported and I have
hardware to test it.
I would rather drop Bonaire support as well and wait for somebody with
the hardware to complain so that we can test and enable it.
Christian.
Alex
Christian.
Alex
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -372,13 +372,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device
*adev)
}
adev->mc.vram_width = numchan * chansize;
}
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev,
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2
On Tue, Apr 25, 2017 at 12:22 PM, Christian König
wrote:
> Am 25.04.2017 um 17:14 schrieb Alex Deucher:
>>
>> On Tue, Apr 25, 2017 at 11:09 AM, Christian König
>> wrote:
>>>
>>> Am 25.04.2017 um 16:34 schrieb Alex Deucher:
On Tue, Apr 25, 2017 at 9:19 AM, Christian König
wrote:
>
> From: Christian König
>
> Try to resize BAR0 to let CPU access all of VRAM.
>
> v2: rebased, style cleanups, disable mem decode before resize,
> handle gmc_v9 as well, round size up to power of two.
>
> Signed-off-by: Christian König
> ---
>drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37
> ++
>drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 ---
>drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 ---
>drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 10
>5 files changed, 54 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 4a16e3c..9484062 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1879,6 +1879,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
> amdgpu_device *adev, struct ttm_tt *ttm,
>struct ttm_mem_reg *mem);
>void amdgpu_vram_location(struct amdgpu_device *adev, struct
> amdgpu_mc
> *mc, u64 base);
>void amdgpu_gtt_location(struct amdgpu_device *adev, struct
> amdgpu_mc
> *mc);
> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
>void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64
> size);
>int amdgpu_ttm_init(struct amdgpu_device *adev);
>void amdgpu_ttm_fini(struct amdgpu_device *adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index a09ad3cf..d5ca77a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -695,6 +695,43 @@ void amdgpu_gtt_location(struct amdgpu_device
> *adev,
> struct amdgpu_mc *mc)
> mc->gtt_size >> 20, mc->gtt_start,
> mc->gtt_end);
>}
>
> +/**
> + * amdgpu_resize_bar0 - try to resize BAR0
> + *
> + * @adev: amdgpu_device pointer
> + *
> + * Try to resize BAR0 to make all VRAM CPU accessible.
> + */
> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
I'd suggest renaming this to amdgpu_device_resize_bar() to try and
impose some consistency in this file, but not a big deal either way.
> +{
> + u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size);
> + u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) -1;
> + u16 cmd;
> + int r;
> +
> + /* Free the doorbell mapping, it most likely needs to move as
> well */
> + amdgpu_doorbell_fini(adev);
> + pci_release_resource(adev->pdev, 2);
This should check for if (adev->asic_type >= CHIP_BONAIRE) since SI
didn't have doorbells.
> +
> + /* Disable memory decoding while we change the BAR addresses
> and
> size */
> + pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd);
> + pci_write_config_word(adev->pdev, PCI_COMMAND,
> + cmd & ~PCI_COMMAND_MEMORY);
> +
> + r = pci_resize_resource(adev->pdev, 0, rbar_size);
> + if (r == -ENOSPC)
> + DRM_INFO("Not enough PCI address space for a large
> BAR.");
> + else if (r && r != -ENOTSUPP)
> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
> +
> + pci_write_config_word(adev->pdev, PCI_COMMAND, cmd);
> +
> + /* When the doorbell BAR isn't available we have no chance of
> +* using the device.
> +*/
> + BUG_ON(amdgpu_doorbell_init(adev));
Same here.
> +}
> +
>/*
> * GPU helpers function.
> */
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> index a9083a1..ae71524 100644
What about SI (gmc_v6_0.c)?
>>>
>>>
>>> As far as I know there is no SI hardware with resizeable BAR support.
>>>
>>> The all VI generation can do this, but I'm not 100% sure if there aren't
>>> any
>>> Bonaires out there which can handle it as well that's why I added gmc_v7
>>> support.
>>>
>>> Still need to double check that.
>>
>> I think NI or even evergreen supported resizeable bars in theory,
>> although I'm not sure if any boards were fused to expose it.
>
>
> In theory yes, in practice no.
>
> Their PCIE config space defines the necessary registers, but I haven't found
> any board from
Re: [PATCH 11/28] drm/qxl: fix include notation and remove -Iinclude/drm flag
Masahiro Yamada writes: > Include instead of relative path from include/drm, then > remove the -Iinclude/drm compiler flag. > > Signed-off-by: Masahiro Yamada Please add Reviewed-by: Gabriel Krisman Bertazi for this and patch 1. Thanks, -- Gabriel Krisman Bertazi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 1/2] Add pl111 as a KMS driver for utils.
Signed-off-by: Eric Anholt
---
tests/util/kms.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/util/kms.c b/tests/util/kms.c
index 959b688158bd..c008f78a32e7 100644
--- a/tests/util/kms.c
+++ b/tests/util/kms.c
@@ -145,6 +145,7 @@ static const char * const modules[] = {
"virtio_gpu",
"mediatek",
"meson",
+ "pl111",
};
int util_open(const char *device, const char *module)
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/2] Add the DPI encoder/connector types to KMS utils.
Signed-off-by: Eric Anholt
---
tests/util/kms.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/util/kms.c b/tests/util/kms.c
index c008f78a32e7..028cc8d956df 100644
--- a/tests/util/kms.c
+++ b/tests/util/kms.c
@@ -79,6 +79,7 @@ static const struct type_name encoder_type_names[] = {
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
{ DRM_MODE_ENCODER_DSI, "DSI" },
{ DRM_MODE_ENCODER_DPMST, "DPMST" },
+ { DRM_MODE_ENCODER_DPI, "DPI" },
};
const char *util_lookup_encoder_type_name(unsigned int type)
@@ -117,6 +118,7 @@ static const struct type_name connector_type_names[] = {
{ DRM_MODE_CONNECTOR_eDP, "eDP" },
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
{ DRM_MODE_CONNECTOR_DSI, "DSI" },
+ { DRM_MODE_CONNECTOR_DPI, "DPI" },
};
const char *util_lookup_connector_type_name(unsigned int type)
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: Add support for clockgating on Fermi+
This adds support for enabling automatic clockgating on nvidia GPUs for
Fermi and later generations. This saves a little bit of power, bringing
my fermi GPU's power consumption from ~28.3W on idle to ~27W, and my
kepler's idle power consumption from ~23.6W to ~21.65W.
Similar to how the nvidia driver seems to handle this, we enable
clockgating for each engine that supports it after it's initialization.
Signed-off-by: Lyude
---
.../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 4 ++
drivers/gpu/drm/nouveau/nvkm/core/engine.c | 20 +-
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 14 ++--
drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild | 2 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 2 +
.../gpu/drm/nouveau/nvkm/subdev/therm/clkgate.c| 49 ++
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c | 77 ++
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 2 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gm107.c | 2 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gt215.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/therm/priv.h | 10 +++
11 files changed, 175 insertions(+), 9 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/clkgate.c
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
index b268b96..904aa56 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
@@ -84,6 +84,9 @@ struct nvkm_therm {
int (*attr_get)(struct nvkm_therm *, enum nvkm_therm_attr_type);
int (*attr_set)(struct nvkm_therm *, enum nvkm_therm_attr_type, int);
+
+ int (*clkgate_engine)(struct nvkm_therm *, enum nvkm_devidx);
+ void (*clkgate_set)(struct nvkm_therm *, int gate_idx, bool enable);
};
int nvkm_therm_temp_get(struct nvkm_therm *);
@@ -94,6 +97,7 @@ int nv40_therm_new(struct nvkm_device *, int, struct
nvkm_therm **);
int nv50_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int g84_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int gt215_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
+int gf100_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int gf119_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int gm107_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
#endif
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/engine.c
b/drivers/gpu/drm/nouveau/nvkm/core/engine.c
index b6c9169..473ad3e 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/engine.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/engine.c
@@ -26,6 +26,7 @@
#include
#include
+#include
bool
nvkm_engine_chsw_load(struct nvkm_engine *engine)
@@ -86,6 +87,13 @@ static int
nvkm_engine_fini(struct nvkm_subdev *subdev, bool suspend)
{
struct nvkm_engine *engine = nvkm_engine(subdev);
+ struct nvkm_therm *therm = subdev->device->therm;
+ int gate_idx;
+
+ gate_idx = therm->clkgate_engine(therm, subdev->index);
+ if (gate_idx != -1)
+ therm->clkgate_set(therm, gate_idx, false);
+
if (engine->func->fini)
return engine->func->fini(engine, suspend);
return 0;
@@ -96,12 +104,13 @@ nvkm_engine_init(struct nvkm_subdev *subdev)
{
struct nvkm_engine *engine = nvkm_engine(subdev);
struct nvkm_fb *fb = subdev->device->fb;
+ struct nvkm_therm *therm = subdev->device->therm;
int ret = 0, i;
s64 time;
if (!engine->usecount) {
nvkm_trace(subdev, "init skipped, engine has no users\n");
- return ret;
+ goto finish;
}
if (engine->func->oneinit && !engine->subdev.oneinit) {
@@ -123,6 +132,15 @@ nvkm_engine_init(struct nvkm_subdev *subdev)
for (i = 0; fb && i < fb->tile.regions; i++)
nvkm_engine_tile(engine, i);
+
+finish:
+ if (!ret) {
+ int gate_idx = therm->clkgate_engine(therm, subdev->index);
+
+ if (gate_idx != -1)
+ therm->clkgate_set(therm, gate_idx, true);
+ }
+
return ret;
}
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index b690bc1..d133016 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -1355,7 +1355,7 @@ nvc0_chipset = {
.mxm = nv50_mxm_new,
.pci = gf100_pci_new,
.pmu = gf100_pmu_new,
- .therm = gt215_therm_new,
+ .therm = gf100_therm_new,
.timer = nv41_timer_new,
.volt = gf100_volt_new,
.ce[0] = gf100_ce_new,
@@ -1392,7 +1392,7 @@ nvc1_chipset = {
.mxm = nv50_mxm_new,
.pci = gf106_pci_new,
.pmu = gf100_pmu_new,
- .therm = gt215_therm_new,
+ .t
[Bug 195577] New: Oops
https://bugzilla.kernel.org/show_bug.cgi?id=195577 Bug ID: 195577 Summary: Oops Product: Drivers Version: 2.5 Kernel Version: 4.10.11-1-ARCH Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: l...@5t9.de Regression: No -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: mali-dp: use div_u64 for expensive 64-bit divisions
On 32-bit machines, we can't divide 64-bit integers:
drivers/gpu/drm/arm/malidp_crtc.o: In function `malidp_crtc_atomic_check':
malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3c0): undefined reference to
`__aeabi_uldivmod'
malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3dc): undefined reference to
`__aeabi_uldivmod'
This calls the div_u64 function explicitly instead.
Fixes: 4cea4e9f6690 ("drm: mali-dp: Add plane upscaling support")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/arm/malidp_crtc.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index 19f1f3b34691..9446a673d469 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -266,7 +266,6 @@ static int malidp_crtc_atomic_check_scaling(struct drm_crtc
*crtc,
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
struct malidp_plane *mp = to_malidp_plane(plane);
- u64 crtc_w, crtc_h;
u32 phase;
if (!(mp->layer->id & scaling))
@@ -276,10 +275,10 @@ static int malidp_crtc_atomic_check_scaling(struct
drm_crtc *crtc,
* Convert crtc_[w|h] to U32.32, then divide by U16.16 src_[w|h]
* to get the U16.16 result.
*/
- crtc_w = (u64)pstate->crtc_w << 32;
- crtc_h = (u64)pstate->crtc_h << 32;
- h_upscale_factor = (u32)(crtc_w / pstate->src_w);
- v_upscale_factor = (u32)(crtc_h / pstate->src_h);
+ h_upscale_factor = div_u64((u64)pstate->crtc_w << 32,
+ pstate->src_w);
+ v_upscale_factor = div_u64((u64)pstate->crtc_h << 32,
+ pstate->src_h);
s->enhancer_enable = ((h_upscale_factor >> 16) >= 2 ||
(v_upscale_factor >> 16) >= 2);
--
2.9.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 195581] New: NULL pointer dereference when amdgpu driver calls drm_load_edid_firmware
https://bugzilla.kernel.org/show_bug.cgi?id=195581 Bug ID: 195581 Summary: NULL pointer dereference when amdgpu driver calls drm_load_edid_firmware Product: Drivers Version: 2.5 Kernel Version: 4.10.11-1-ARCH Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: l...@5t9.de Regression: No I experienced kernel crashes multiple times when drm_load_edid_firmware was called from the amdgpu driver, on the occasion of e.g. the external display shutting down after extended non-use. Since this same operation also works quite well often, I assume there is some sort of race condition when using kernel parameter drm_kms_helper.edid_firmware=my_edid_file - so I just wanted to open this report to inform you about the observation: [172643.308167] BUG: unable to handle kernel NULL pointer dereference at 0008 [172643.309348] IP: set_root+0x24/0xb0 [172643.310516] PGD 0 [172643.312844] Oops: [#1] PREEMPT SMP [172643.314013] Modules linked in: blowfish_generic blowfish_x86_64 blowfish_common des3_ede_x86_64 des_generic cast5_avx_x86_64 cast5_generic cast_common cbc twofish_generic twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_common serpent_avx2 serpent_avx_x86_64 serpent_sse2_x86_64 serpent_generic lrw ablk_helper xts gf128mul fuse joydev mousedev hid_generic hidp hid arc4 md4 nls_utf8 cifs dns_resolver fscache xt_tcpudp ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG xt_owner xt_mark iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_filter cmac bnep cpufreq_ondemand msr nls_iso8859_1 eeepc_wmi nls_cp437 asus_wmi sparse_keymap vfat video mxm_wmi snd_hda_codec_generic fat edac_mce_amd snd_hda_codec_hdmi edac_core btusb snd_hda_intel [172643.321641] btrtl igb sp5100_tco btbcm ptp kvm_amd pps_core btintel snd_hda_codec kvm bluetooth evdev snd_hda_core input_leds led_class snd_hwdep irqbypass mac_hid snd_pcm rfkill pcspkr dca crc16 i2c_piix4 snd_timer snd soundcore shpchp fjes wmi i2c_designware_platform 8250_dw i2c_designware_core acpi_cpufreq button tpm_tis tpm_tis_core tpm sch_fq_codel usbip_host usbip_core sg it87(O) hwmon_vid ip_tables x_tables algif_skcipher af_alg sd_mod uas usb_storage serio_raw atkbd libps2 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd ahci ccp libahci rng_core xhci_pci xhci_hcd libata usbcore scsi_mod usb_common i8042 serio amdgpu i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm xfs libcrc32c crc32c_generic crc32c_intel [172643.327265] dm_crypt dm_mod nvme nvme_core i2c_dev [172643.328089] CPU: 4 PID: 1071 Comm: Xorg Tainted: G O 4.10.11-1-ARCH #1 [172643.328920] Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 0604 04/06/2017 [172643.329759] task: 8807f6038e40 task.stack: c9000809c000 [172643.330595] RIP: 0010:set_root+0x24/0xb0 [172643.331426] RSP: 0018:c9000809f7e0 EFLAGS: 00010202 [172643.332256] RAX: 8807f6038e40 RBX: c9000809f910 RCX: 8807f72e7200 [172643.333084] RDX: 81d383c8 RSI: RDI: c9000809f910 [172643.333914] RBP: c9000809f7f8 R08: 8807f72e7200 R09: 8807f72e7200 [172643.334741] R10: ffea R11: R12: [172643.335558] R13: 88002a67d01c R14: c9000809f910 R15: 4650 [172643.336365] FS: 7f4604912940() GS:88081ed0() knlGS: [172643.337172] CS: 0010 DS: ES: CR0: 80050033 [172643.337981] CR2: 0008 CR3: 05a09000 CR4: 003406e0 [172643.338794] Call Trace: [172643.339604] path_init+0x1e3/0x350 [172643.340419] path_openat+0x7c/0x1180 [172643.341220] ? default_wake_function+0x12/0x20 [172643.342007] ? __wake_up_common+0x4d/0x80 [172643.342777] ? ep_poll_callback+0xef/0x1e0 [172643.343538] do_filp_open+0x91/0x100 [172643.344297] ? platform_match+0x29/0xa0 [172643.345046] ? getname_kernel+0x32/0xe0 [172643.345782] ? kmem_cache_alloc+0xdb/0x1b0 [172643.346510] file_open_name+0x112/0x140 [172643.347234] filp_open+0x33/0x60 [172643.347947] kernel_read_file_from_path+0x36/0x70 [172643.348654] _request_firmware+0x287/0xa70 [172643.349357] request_firmware+0x37/0x50 [172643.350047] drm_load_edid_firmware+0x316/0x530 [drm_kms_helper] [172643.350728] drm_helper_probe_single_connector_modes+0x16b/0x520 [drm_kms_helper] [172643.351403] drm_setup_crtcs+0x7b/0x9c0 [drm_kms_helper] [172643.352068] drm_fb_helper_hotplug_event+0xd2/0xf0 [drm_kms_helper] [172643.352732] drm_fb_helper_restore_fbdev_mode_unlocked+0x57/0x80 [drm_kms_helper] [172643.353388] amdgpu_fbdev_
[Bug 195577] Oops
https://bugzilla.kernel.org/show_bug.cgi?id=195577 Lutz Vieweg (l...@5t9.de) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Lutz Vieweg (l...@5t9.de) --- (sorry, duplicate bug created accidentally, see 195581 for the correct report.) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] GPU hangs and X shot down with 4.11-rc6
On Tue, Apr 25, 2017 at 06:41:20PM +0200, Michal Hocko wrote: > Hi, > I have just experienced X being shut down once with 4.11-rc2 and 2 times > with 4.11-rc6 kernel. I do not remember seeing something like this > before but it is quite possible I was just lucky to not trigger this > issue before. It always happened while I was working on a presentation > in LibreOffice which I do very seldom. The kernel log contains: > > [ 7456.721893] [drm] GPU HANG: ecode 9:0:0x86dd, in Xorg [3594], reason: > Hang on render ring, action: reset > [ 7456.721897] [drm] GPU hangs can indicate a bug anywhere in the entire gfx > stack, including userspace. > [ 7456.721898] [drm] Please file a _new_ bug report on bugs.freedesktop.org > against DRI -> DRM/Intel > [ 7456.721900] [drm] drm/i915 developers can then reassign to the right > component if it's not a kernel issue. > [ 7456.721901] [drm] The gpu crash dump is required to analyze gpu hangs, so > please always attach it. > [ 7456.721902] [drm] GPU crash dump saved to /sys/class/drm/card0/error > [ 7456.721925] drm/i915: Resetting chip after gpu hang > [ 7456.722117] [drm] RC6 on > [ 7456.734588] [drm] GuC firmware load skipped > [ 7464.686209] drm/i915: Resetting chip after gpu hang > [ 7464.686284] [drm] RC6 on > [ 7464.702469] [drm] GuC firmware load skipped > [ 7472.686180] drm/i915: Resetting chip after gpu hang > [ 7472.686241] [drm] RC6 on > [ 7472.704565] [drm] GuC firmware load skipped > [ 7480.686179] drm/i915: Resetting chip after gpu hang > [ 7480.686241] [drm] RC6 on > [ 7480.704583] [drm] GuC firmware load skipped > [ 7493.678130] drm/i915: Resetting chip after gpu hang > [ 7493.678206] [drm] RC6 on > [ 7493.696505] [drm] GuC firmware load skipped > > The kernel message tells that the problem might be anywhere and I should > report to freedesktop but I haven't changed the userspace recently so it > smells more like a kernel bug to me. Does this ring bells? The GPU crash > dump is attached in case it is useful. There are lots of very similar GPU hangs for mesa across a wide range of kernels, with several reports noting a correlation with libreoffice. At first glance, I would say you were just unlucky to hit it. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100695] Texture artifacts in Deus Ex: Mankind Divided
https://bugs.freedesktop.org/show_bug.cgi?id=100695 Hadrien changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #9 from Hadrien --- I uninstalled padoka packages and reinstalled plain mesa 17.0.3 from Ubuntu 17.04. I then reinstalled padoka and the problem is gone. I will probably never know what happened. Anyway, I'm closing the bug. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 2/2] Add the DPI encoder/connector types to KMS utils.
Hi Eric, On 25 April 2017 at 20:33, Eric Anholt wrote: > Signed-off-by: Eric Anholt Both are: Reviewed-by: Daniel Stone Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100400] Game Valhalla Hills crash on startup
https://bugs.freedesktop.org/show_bug.cgi?id=100400 --- Comment #10 from CraZy bisCuiT --- This problem affects me as well on mesa 17.04 and llvm 4.0.0-1 with AMD RX 480. Any ideas what causes this problem? We can't expect a patch from the developer since the studio doesn't exist anymore. For some reason proprietary AMD and nVidia drivers do work. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/4] Exynos DRM: add Picture Processor extension
Hi Marek, On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote: > Hi Laurent, > > On 2017-04-20 12:25, Laurent Pinchart wrote: > >Hi Marek, > > > >(CC'ing Sakari Ailus) > > > >Thank you for the patches. > > > >On Thursday 20 Apr 2017 11:13:36 Marek Szyprowski wrote: > >>Dear all, > >> > >>This is an updated proposal for extending EXYNOS DRM API with generic > >>support for hardware modules, which can be used for processing image data > >>from the one memory buffer to another. Typical memory-to-memory operations > >>are: rotation, scaling, colour space conversion or mix of them. This is a > >>follow-up of my previous proposal "[RFC 0/2] New feature: Framebuffer > >>processors", which has been rejected as "not really needed in the DRM > >>core": > >>http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg146286.html > >> > >>In this proposal I moved all the code to Exynos DRM driver, so now this > >>will be specific only to Exynos DRM. I've also changed the name from > >>framebuffer processor (fbproc) to picture processor (pp) to avoid confusion > >>with fbdev API. > >> > >>Here is a bit more information what picture processors are: > >> > >>Embedded SoCs are known to have a number of hardware blocks, which perform > >>such operations. They can be used in paralel to the main GPU module to > >>offload CPU from processing grapics or video data. One of example use of > >>such modules is implementing video overlay, which usually requires color > >>space conversion from NV12 (or similar) to RGB32 color space and scaling to > >>target window size. > >> > >>The proposed API is heavily inspired by atomic KMS approach - it is also > >>based on DRM objects and their properties. A new DRM object is introduced: > >>picture processor (called pp for convenience). Such objects have a set of > >>standard DRM properties, which describes the operation to be performed by > >>respective hardware module. In typical case those properties are a source > >>fb id and rectangle (x, y, width, height) and destination fb id and > >>rectangle. Optionally a rotation property can be also specified if > >>supported by the given hardware. To perform an operation on image data, > >>userspace provides a set of properties and their values for given fbproc > >>object in a similar way as object and properties are provided for > >>performing atomic page flip / mode setting. > >> > >>The proposed API consists of the 3 new ioctls: > >>- DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture > >> processors, > >>- DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture > >> processor, > >>- DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given > >> property set. > >> > >>The proposed API is extensible. Drivers can attach their own, custom > >>properties to add support for more advanced picture processing (for example > >>blending). > >> > >>This proposal aims to replace Exynos DRM IPP (Image Post Processing) > >>subsystem. IPP API is over-engineered in general, but not really extensible > >>on the other side. It is also buggy, with significant design flaws - the > >>biggest issue is the fact that the API covers memory-2-memory picture > >>operations together with CRTC writeback and duplicating features, which > >>belongs to video plane. Comparing with IPP subsystem, the PP framework is > >>smaller (1807 vs 778 lines) and allows driver simplification (Exynos > >>rotator driver smaller by over 200 lines). > >This seems to be the kind of hardware that is typically supported by V4L2. > >Stupid question, why DRM ? > > Let me elaborate a bit on the reasons for implementing it in Exynos DRM: > > 1. we want to replace existing Exynos IPP subsystem: > - it is used only in some internal/vendor trees, not in open-source > - we want it to have sane and potentially extensible userspace API > - but we don't want to loose its functionality > > 2. we want to have simple API for performing single image processing > operation: > - typically it will be used by compositing window manager, this means that >some parameters of the processing might change on each vblank (like >destination rectangle for example). This api allows such change on each >operation without any additional cost. V4L2 requires to reinitialize >queues with new configuration on such change, what means that a bunch of >ioctls has to be called. What do you mean by re-initialising the queue? Format, buffers or something else? If you need a larger buffer than what you have already allocated, you'll need to re-allocate, V4L2 or not. We also do lack a way to destroy individual buffers in V4L2. It'd be up to implementing that and some work in videobuf2. Another thing is that V4L2 is very stream oriented. For most devices that's fine as a lot of the parameters are not changeable during streaming, especially if the pipeline is handled by multiple drivers. That said, for devices that process data from memory to memory
Re: [PATCH libdrm 2/2] Add the DPI encoder/connector types to KMS utils.
Daniel Stone writes: > Hi Eric, > > On 25 April 2017 at 20:33, Eric Anholt wrote: >> Signed-off-by: Eric Anholt > > Both are: > Reviewed-by: Daniel Stone Pushed. Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100785] [regression, bisected] arb_gpu_shader5 piglit fail
https://bugs.freedesktop.org/show_bug.cgi?id=100785 --- Comment #2 from Timothy Arceri --- Does it work if you set: R600_DEBUG=nosb Also it would be helpful if you could attach a before and after shader dump using. R600_DEBUG=vs,ps -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/21] Introduce common scatterlist map function
Changes since v1: * Rebased onto next-20170424 * Removed the _offset version of these functions per Christoph's suggestion * Added an SG_MAP_MUST_NOT_FAIL flag which will BUG_ON in future cases that can't gracefully fail. This removes a bunch of the noise added in v1 to a couple of the drivers. (Per David Laight's suggestion) This flag is only meant for old code * Split the libiscsi patch into two (per Christoph's suggestion) the prep patch (patch 2 in this series) has already been sent separately * Fixed a locking mistake in the target patch (pointed out by a bot) * Dropped the nvmet patch and handled it with a different patch that has been sent separately * Dropped the chcr patch as they have already removed the code that needed to be changed I'm still hoping to only get Patch 1 in the series merged. (Any volunteers?) I'm willing to chase down the maintainers for the remaining patches separately after the first patch is in. The patchset is based on next-20170424 and can be found in the sg_map_v2 branch from this git tree: https://github.com/sbates130272/linux-p2pmem.git -- Hi Everyone, As part of my effort to enable P2P DMA transactions with PCI cards, we've identified the need to be able to safely put IO memory into scatterlists (and eventually other spots). This probably involves a conversion from struct page to pfn_t but that migration is a ways off and those decisions are yet to be made. As an initial step in that direction, I've started cleaning up some of the scatterlist code by trying to carve out a better defined layer between it and it's users. The longer term goal would be to remove sg_page or replace it with something that can potentially fail. This patchset is the first step in that effort. I've introduced a common function to map scatterlist memory and converted all the common kmap(sg_page()) cases. This removes about 66 sg_page calls (of ~331). Seeing this is a fairly large cleanup set that touches a wide swath of the kernel I have limited the people I've sent this to. I'd suggest we look toward merging the first patch and then I can send the individual subsystem patches on to their respective maintainers and get them merged independantly. (This is to avoid the conflicts I created with my last cleanup set... Sorry) Though, I'm certainly open to other suggestions to get it merged. Logan Gunthorpe (21): scatterlist: Introduce sg_map helper functions libiscsi: Add an internal error code libiscsi: Make use of new the sg_map helper function target: Make use of the new sg_map function at 16 call sites drm/i915: Make use of the new sg_map helper function crypto: hifn_795x: Make use of the new sg_map helper function crypto: shash, caam: Make use of the new sg_map helper function dm-crypt: Make use of the new sg_map helper in 4 call sites staging: unisys: visorbus: Make use of the new sg_map helper function RDS: Make use of the new sg_map helper function scsi: ipr, pmcraid, isci: Make use of the new sg_map helper scsi: hisi_sas, mvsas, gdth: Make use of the new sg_map helper function scsi: arcmsr, ips, megaraid: Make use of the new sg_map helper function scsi: libfc, csiostor: Change to sg_copy_buffer in two drivers xen-blkfront: Make use of the new sg_map helper function mmc: sdhci: Make use of the new sg_map helper function mmc: spi: Make use of the new sg_map helper function mmc: tmio: Make use of the new sg_map helper function mmc: sdricoh_cs: Make use of the new sg_map helper function mmc: tifm_sd: Make use of the new sg_map helper function memstick: Make use of the new sg_map helper function crypto/shash.c | 9 ++- drivers/block/xen-blkfront.c| 20 ++--- drivers/crypto/caam/caamalg.c | 8 +- drivers/crypto/hifn_795x.c | 32 +--- drivers/gpu/drm/i915/i915_gem.c | 27 --- drivers/md/dm-crypt.c | 39 ++--- drivers/memstick/host/jmb38x_ms.c | 11 +-- drivers/memstick/host/tifm_ms.c | 11 +-- drivers/mmc/host/mmc_spi.c | 26 -- drivers/mmc/host/sdhci.c| 14 ++-- drivers/mmc/host/sdricoh_cs.c | 14 ++-- drivers/mmc/host/tifm_sd.c | 50 +++- drivers/mmc/host/tmio_mmc.h | 7 +- drivers/mmc/host/tmio_mmc_pio.c | 12 +++ drivers/scsi/arcmsr/arcmsr_hba.c| 16 +++- drivers/scsi/csiostor/csio_scsi.c | 54 + drivers/scsi/cxgbi/libcxgbi.c | 5 ++ drivers/scsi/gdth.c | 9 ++- drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 14 ++-- drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 13 ++- drivers/scsi/ipr.c | 27 --- drivers/scsi/ips.c | 8 +- drivers/s
[PATCH v2 17/21] mmc: spi: Make use of the new sg_map helper function
We use the sg_map helper but it's slightly more complicated
as we only check for the error when the mapping actually gets used.
Such that if the mapping failed but wasn't needed then no
error occurs.
Signed-off-by: Logan Gunthorpe
Cc: Ulf Hansson
---
drivers/mmc/host/mmc_spi.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index 476e53d..d614f36 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -676,9 +676,15 @@ mmc_spi_writeblock(struct mmc_spi_host *host, struct
spi_transfer *t,
struct scratch *scratch = host->data;
u32 pattern;
- if (host->mmc->use_spi_crc)
+ if (host->mmc->use_spi_crc) {
+ if (IS_ERR(t->tx_buf))
+ return PTR_ERR(t->tx_buf);
+
scratch->crc_val = cpu_to_be16(
crc_itu_t(0, t->tx_buf, t->len));
+ t->tx_buf += t->len;
+ }
+
if (host->dma_dev)
dma_sync_single_for_device(host->dma_dev,
host->data_dma, sizeof(*scratch),
@@ -743,7 +749,6 @@ mmc_spi_writeblock(struct mmc_spi_host *host, struct
spi_transfer *t,
return status;
}
- t->tx_buf += t->len;
if (host->dma_dev)
t->tx_dma += t->len;
@@ -809,6 +814,11 @@ mmc_spi_readblock(struct mmc_spi_host *host, struct
spi_transfer *t,
}
leftover = status << 1;
+ if (bitshift || host->mmc->use_spi_crc) {
+ if (IS_ERR(t->rx_buf))
+ return PTR_ERR(t->rx_buf);
+ }
+
if (host->dma_dev) {
dma_sync_single_for_device(host->dma_dev,
host->data_dma, sizeof(*scratch),
@@ -860,9 +870,10 @@ mmc_spi_readblock(struct mmc_spi_host *host, struct
spi_transfer *t,
scratch->crc_val, crc, t->len);
return -EILSEQ;
}
+
+ t->rx_buf += t->len;
}
- t->rx_buf += t->len;
if (host->dma_dev)
t->rx_dma += t->len;
@@ -933,11 +944,11 @@ mmc_spi_data_do(struct mmc_spi_host *host, struct
mmc_command *cmd,
}
/* allow pio too; we don't allow highmem */
- kmap_addr = kmap(sg_page(sg));
+ kmap_addr = sg_map(sg, 0, SG_KMAP);
if (direction == DMA_TO_DEVICE)
- t->tx_buf = kmap_addr + sg->offset;
+ t->tx_buf = kmap_addr;
else
- t->rx_buf = kmap_addr + sg->offset;
+ t->rx_buf = kmap_addr;
/* transfer each block, and update request status */
while (length) {
@@ -967,7 +978,8 @@ mmc_spi_data_do(struct mmc_spi_host *host, struct
mmc_command *cmd,
/* discard mappings */
if (direction == DMA_FROM_DEVICE)
flush_kernel_dcache_page(sg_page(sg));
- kunmap(sg_page(sg));
+ if (!IS_ERR(kmap_addr))
+ sg_unmap(sg, kmap_addr, 0, SG_KMAP);
if (dma_dev)
dma_unmap_page(dma_dev, dma_addr, PAGE_SIZE, dir);
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/sun4i: Drop unused tcon pointer
The sun4i DRM driver now uses 2 lists to track backends and tcons.
During the switch, the original tcon pointer was not removed.
As it is now unused, remove it, so other new drivers can't accidentally
use it.
Signed-off-by: Chen-Yu Tsai
---
As mentioned in the cover letter, please squash this into the patch
drm/sun4i: Use lists to track registered display backends and TCONs
---
drivers/gpu/drm/sun4i/sun4i_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h
b/drivers/gpu/drm/sun4i/sun4i_drv.h
index 835bdb5cc0c2..250c29017ef5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.h
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
@@ -20,7 +20,6 @@
struct sun4i_drv {
struct list_headbackend_list;
struct list_headtcon_list;
- struct sun4i_tcon *tcon;
struct drm_fbdev_cma*fbdev;
};
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/21] drm/i915: Make use of the new sg_map helper function
This is a single straightforward conversion from kmap to sg_map.
We also create the i915_gem_object_unmap function to common up the
unmap code.
Signed-off-by: Logan Gunthorpe
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 07e9b27..2c33000 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2202,6 +2202,15 @@ static void __i915_gem_object_reset_page_iter(struct
drm_i915_gem_object *obj)
radix_tree_delete(&obj->mm.get_page.radix, iter.index);
}
+static void i915_gem_object_unmap(const struct drm_i915_gem_object *obj,
+ void *ptr)
+{
+ if (is_vmalloc_addr(ptr))
+ vunmap(ptr);
+ else
+ sg_unmap(obj->mm.pages->sgl, ptr, 0, SG_KMAP);
+}
+
void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
enum i915_mm_subclass subclass)
{
@@ -2229,10 +2238,7 @@ void __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj,
void *ptr;
ptr = ptr_mask_bits(obj->mm.mapping);
- if (is_vmalloc_addr(ptr))
- vunmap(ptr);
- else
- kunmap(kmap_to_page(ptr));
+ i915_gem_object_unmap(obj, ptr);
obj->mm.mapping = NULL;
}
@@ -2499,8 +2505,11 @@ static void *i915_gem_object_map(const struct
drm_i915_gem_object *obj,
void *addr;
/* A single page can always be kmapped */
- if (n_pages == 1 && type == I915_MAP_WB)
- return kmap(sg_page(sgt->sgl));
+ if (n_pages == 1 && type == I915_MAP_WB) {
+ addr = sg_map(sgt->sgl, 0, SG_KMAP);
+ if (IS_ERR(addr))
+ return NULL;
+ }
if (n_pages > ARRAY_SIZE(stack_pages)) {
/* Too big for stack -- allocate temporary array instead */
@@ -2567,11 +2576,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object
*obj,
goto err_unpin;
}
- if (is_vmalloc_addr(ptr))
- vunmap(ptr);
- else
- kunmap(kmap_to_page(ptr));
-
+ i915_gem_object_unmap(obj, ptr);
ptr = obj->mm.mapping = NULL;
}
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 19/21] mmc: sdricoh_cs: Make use of the new sg_map helper function
This is a straightforward conversion to the new function.
Signed-off-by: Logan Gunthorpe
Cc: Sascha Sommer
Cc: Ulf Hansson
---
drivers/mmc/host/sdricoh_cs.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdricoh_cs.c b/drivers/mmc/host/sdricoh_cs.c
index 5ff26ab..03225c3 100644
--- a/drivers/mmc/host/sdricoh_cs.c
+++ b/drivers/mmc/host/sdricoh_cs.c
@@ -319,16 +319,20 @@ static void sdricoh_request(struct mmc_host *mmc, struct
mmc_request *mrq)
for (i = 0; i < data->blocks; i++) {
size_t len = data->blksz;
u8 *buf;
- struct page *page;
int result;
- page = sg_page(data->sg);
- buf = kmap(page) + data->sg->offset + (len * i);
+ buf = sg_map(data->sg, (len * i), SG_KMAP);
+ if (IS_ERR(buf)) {
+ cmd->error = PTR_ERR(buf);
+ break;
+ }
+
result =
sdricoh_blockio(host,
data->flags & MMC_DATA_READ, buf, len);
- kunmap(page);
- flush_dcache_page(page);
+ sg_unmap(data->sg, buf, (len * i), SG_KMAP);
+
+ flush_dcache_page(sg_page(data->sg));
if (result) {
dev_err(dev, "sdricoh_request: cmd %i "
"block transfer failed\n", cmd->opcode);
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/21] target: Make use of the new sg_map function at 16 call sites
Fairly straightforward conversions in all spots. In a couple of cases
any error gets propogated up should sg_map fail. In other
cases a warning is issued if the kmap fails seeing there's no
clear error path. This should not be an issue until someone tries to
use unmappable memory in the sgl with this driver.
Signed-off-by: Logan Gunthorpe
Cc: "Nicholas A. Bellinger"
---
drivers/target/iscsi/iscsi_target.c| 29 +++---
drivers/target/target_core_rd.c| 3 +-
drivers/target/target_core_sbc.c | 103 +
drivers/target/target_core_transport.c | 18 --
drivers/target/target_core_user.c | 45 +-
include/target/target_core_backend.h | 4 +-
6 files changed, 134 insertions(+), 68 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target.c
b/drivers/target/iscsi/iscsi_target.c
index e3f9ed3..3ab8d21 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -578,7 +578,7 @@ iscsit_xmit_nondatain_pdu(struct iscsi_conn *conn, struct
iscsi_cmd *cmd,
}
static int iscsit_map_iovec(struct iscsi_cmd *, struct kvec *, u32, u32);
-static void iscsit_unmap_iovec(struct iscsi_cmd *);
+static void iscsit_unmap_iovec(struct iscsi_cmd *, struct kvec *);
static u32 iscsit_do_crypto_hash_sg(struct ahash_request *, struct iscsi_cmd *,
u32, u32, u32, u8 *);
static int
@@ -645,7 +645,7 @@ iscsit_xmit_datain_pdu(struct iscsi_conn *conn, struct
iscsi_cmd *cmd,
ret = iscsit_fe_sendpage_sg(cmd, conn);
- iscsit_unmap_iovec(cmd);
+ iscsit_unmap_iovec(cmd, &cmd->iov_data[1]);
if (ret < 0) {
iscsit_tx_thread_wait_for_tcp(conn);
@@ -924,7 +924,10 @@ static int iscsit_map_iovec(
while (data_length) {
u32 cur_len = min_t(u32, data_length, sg->length - page_off);
- iov[i].iov_base = kmap(sg_page(sg)) + sg->offset + page_off;
+ iov[i].iov_base = sg_map(sg, page_off, SG_KMAP);
+ if (IS_ERR(iov[i].iov_base))
+ goto map_err;
+
iov[i].iov_len = cur_len;
data_length -= cur_len;
@@ -936,17 +939,25 @@ static int iscsit_map_iovec(
cmd->kmapped_nents = i;
return i;
+
+map_err:
+ cmd->kmapped_nents = i - 1;
+ iscsit_unmap_iovec(cmd, iov);
+ return -1;
}
-static void iscsit_unmap_iovec(struct iscsi_cmd *cmd)
+static void iscsit_unmap_iovec(struct iscsi_cmd *cmd, struct kvec *iov)
{
u32 i;
struct scatterlist *sg;
+ unsigned int page_off = cmd->first_data_sg_off;
sg = cmd->first_data_sg;
- for (i = 0; i < cmd->kmapped_nents; i++)
- kunmap(sg_page(&sg[i]));
+ for (i = 0; i < cmd->kmapped_nents; i++) {
+ sg_unmap(&sg[i], iov[i].iov_base, page_off, SG_KMAP);
+ page_off = 0;
+ }
}
static void iscsit_ack_from_expstatsn(struct iscsi_conn *conn, u32 exp_statsn)
@@ -1609,7 +1620,7 @@ iscsit_get_dataout(struct iscsi_conn *conn, struct
iscsi_cmd *cmd,
rx_got = rx_data(conn, &cmd->iov_data[0], iov_count, rx_size);
- iscsit_unmap_iovec(cmd);
+ iscsit_unmap_iovec(cmd, iov);
if (rx_got != rx_size)
return -1;
@@ -1710,7 +1721,7 @@ int iscsit_setup_nop_out(struct iscsi_conn *conn, struct
iscsi_cmd *cmd,
if (!cmd)
return iscsit_add_reject(conn,
ISCSI_REASON_PROTOCOL_ERROR,
(unsigned char *)hdr);
-
+
return iscsit_reject_cmd(cmd, ISCSI_REASON_PROTOCOL_ERROR,
(unsigned char *)hdr);
}
@@ -2625,7 +2636,7 @@ static int iscsit_handle_immediate_data(
rx_got = rx_data(conn, &cmd->iov_data[0], iov_count, rx_size);
- iscsit_unmap_iovec(cmd);
+ iscsit_unmap_iovec(cmd, cmd->iov_data);
if (rx_got != rx_size) {
iscsit_rx_thread_wait_for_tcp(conn);
diff --git a/drivers/target/target_core_rd.c b/drivers/target/target_core_rd.c
index 5f23f34..348211c 100644
--- a/drivers/target/target_core_rd.c
+++ b/drivers/target/target_core_rd.c
@@ -432,7 +432,8 @@ static sense_reason_t rd_do_prot_rw(struct se_cmd *cmd,
bool is_read)
cmd->t_prot_sg, 0);
}
if (!rc)
- sbc_dif_copy_prot(cmd, sectors, is_read, prot_sg, prot_offset);
+ rc = sbc_dif_copy_prot(cmd, sectors, is_read, prot_sg,
+ prot_offset);
return rc;
}
diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index ee35c90..8ac07c6 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
@@ -420,17 +420,17 @@ static sense_reason_t xdreadwrite_callback(struct se_cmd
*cmd, bool success,
offset = 0;
for_each_
[PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function
Very straightforward conversion to the new function in the caam driver
and shash library.
Signed-off-by: Logan Gunthorpe
Cc: Herbert Xu
Cc: "David S. Miller"
---
crypto/shash.c| 9 ++---
drivers/crypto/caam/caamalg.c | 8 +++-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/crypto/shash.c b/crypto/shash.c
index 5e31c8d..5914881 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -283,10 +283,13 @@ int shash_ahash_digest(struct ahash_request *req, struct
shash_desc *desc)
if (nbytes < min(sg->length, ((unsigned int)(PAGE_SIZE)) - offset)) {
void *data;
- data = kmap_atomic(sg_page(sg));
- err = crypto_shash_digest(desc, data + offset, nbytes,
+ data = sg_map(sg, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ err = crypto_shash_digest(desc, data, nbytes,
req->result);
- kunmap_atomic(data);
+ sg_unmap(sg, data, 0, SG_KMAP_ATOMIC);
crypto_yield(desc->flags);
} else
err = crypto_shash_init(desc) ?:
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 398807d..62d2f5d 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -89,7 +89,6 @@ static void dbg_dump_sg(const char *level, const char
*prefix_str,
struct scatterlist *sg, size_t tlen, bool ascii)
{
struct scatterlist *it;
- void *it_page;
size_t len;
void *buf;
@@ -98,19 +97,18 @@ static void dbg_dump_sg(const char *level, const char
*prefix_str,
* make sure the scatterlist's page
* has a valid virtual memory mapping
*/
- it_page = kmap_atomic(sg_page(it));
- if (unlikely(!it_page)) {
+ buf = sg_map(it, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(buf)) {
printk(KERN_ERR "dbg_dump_sg: kmap failed\n");
return;
}
- buf = it_page + it->offset;
len = min_t(size_t, tlen, it->length);
print_hex_dump(level, prefix_str, prefix_type, rowsize,
groupsize, buf, len, ascii);
tlen -= len;
- kunmap_atomic(it_page);
+ sg_unmap(it, buf, 0, SG_KMAP_ATOMIC);
}
}
#endif
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 11/21] scsi: ipr, pmcraid, isci: Make use of the new sg_map helper
Very straightforward conversion of three scsi drivers.
Signed-off-by: Logan Gunthorpe
Cc: Brian King
Cc: Artur Paszkiewicz
---
drivers/scsi/ipr.c | 27 ++-
drivers/scsi/isci/request.c | 42 +-
drivers/scsi/pmcraid.c | 19 ---
3 files changed, 51 insertions(+), 37 deletions(-)
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index b0c68d2..b2324e1 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -3895,7 +3895,7 @@ static void ipr_free_ucode_buffer(struct ipr_sglist
*sglist)
static int ipr_copy_ucode_buffer(struct ipr_sglist *sglist,
u8 *buffer, u32 len)
{
- int bsize_elem, i, result = 0;
+ int bsize_elem, i;
struct scatterlist *scatterlist;
void *kaddr;
@@ -3905,32 +3905,33 @@ static int ipr_copy_ucode_buffer(struct ipr_sglist
*sglist,
scatterlist = sglist->scatterlist;
for (i = 0; i < (len / bsize_elem); i++, buffer += bsize_elem) {
- struct page *page = sg_page(&scatterlist[i]);
+ kaddr = sg_map(&scatterlist[i], 0, SG_KMAP);
+ if (IS_ERR(kaddr)) {
+ ipr_trace;
+ return PTR_ERR(kaddr);
+ }
- kaddr = kmap(page);
memcpy(kaddr, buffer, bsize_elem);
- kunmap(page);
+ sg_unmap(&scatterlist[i], kaddr, 0, SG_KMAP);
scatterlist[i].length = bsize_elem;
-
- if (result != 0) {
- ipr_trace;
- return result;
- }
}
if (len % bsize_elem) {
- struct page *page = sg_page(&scatterlist[i]);
+ kaddr = sg_map(&scatterlist[i], 0, SG_KMAP);
+ if (IS_ERR(kaddr)) {
+ ipr_trace;
+ return PTR_ERR(kaddr);
+ }
- kaddr = kmap(page);
memcpy(kaddr, buffer, len % bsize_elem);
- kunmap(page);
+ sg_unmap(&scatterlist[i], kaddr, 0, SG_KMAP);
scatterlist[i].length = len % bsize_elem;
}
sglist->buffer_len = len;
- return result;
+ return 0;
}
/**
diff --git a/drivers/scsi/isci/request.c b/drivers/scsi/isci/request.c
index 47f66e9..6f5521b 100644
--- a/drivers/scsi/isci/request.c
+++ b/drivers/scsi/isci/request.c
@@ -1424,12 +1424,14 @@ sci_stp_request_pio_data_in_copy_data_buffer(struct
isci_stp_request *stp_req,
sg = task->scatter;
while (total_len > 0) {
- struct page *page = sg_page(sg);
-
copy_len = min_t(int, total_len, sg_dma_len(sg));
- kaddr = kmap_atomic(page);
- memcpy(kaddr + sg->offset, src_addr, copy_len);
- kunmap_atomic(kaddr);
+ kaddr = sg_map(sg, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(kaddr))
+ return SCI_FAILURE;
+
+ memcpy(kaddr, src_addr, copy_len);
+ sg_unmap(sg, kaddr, 0, SG_KMAP_ATOMIC);
+
total_len -= copy_len;
src_addr += copy_len;
sg = sg_next(sg);
@@ -1771,14 +1773,16 @@ sci_io_request_frame_handler(struct isci_request *ireq,
case SCI_REQ_SMP_WAIT_RESP: {
struct sas_task *task = isci_request_access_task(ireq);
struct scatterlist *sg = &task->smp_task.smp_resp;
- void *frame_header, *kaddr;
+ void *frame_header;
u8 *rsp;
sci_unsolicited_frame_control_get_header(&ihost->uf_control,
frame_index,
&frame_header);
- kaddr = kmap_atomic(sg_page(sg));
- rsp = kaddr + sg->offset;
+ rsp = sg_map(sg, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(rsp))
+ return SCI_FAILURE;
+
sci_swab32_cpy(rsp, frame_header, 1);
if (rsp[0] == SMP_RESPONSE) {
@@ -1814,7 +1818,7 @@ sci_io_request_frame_handler(struct isci_request *ireq,
ireq->sci_status =
SCI_FAILURE_CONTROLLER_SPECIFIC_IO_ERR;
sci_change_state(&ireq->sm, SCI_REQ_COMPLETED);
}
- kunmap_atomic(kaddr);
+ sg_unmap(sg, rsp, 0, SG_KMAP_ATOMIC);
sci_controller_release_frame(ihost, frame_index);
@@ -2919,15 +2923,18 @@ static void isci_request_io_request_complete(struct
isci_host *ihost,
case SAS_PROTOCOL_SMP: {
struct scatterlist *sg = &task->smp_task.smp_req;
struct smp_req *smp_req;
- void *kaddr;
dma
[PATCH v2 08/21] dm-crypt: Make use of the new sg_map helper in 4 call sites
Very straightforward conversion to the new function in all four spots.
Signed-off-by: Logan Gunthorpe
Cc: Alasdair Kergon
Cc: Mike Snitzer
---
drivers/md/dm-crypt.c | 39 ++-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 8dbecf1..841f1fc 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -635,9 +635,12 @@ static int crypt_iv_lmk_gen(struct crypt_config *cc, u8
*iv,
if (bio_data_dir(dmreq->ctx->bio_in) == WRITE) {
sg = crypt_get_sg_data(cc, dmreq->sg_in);
- src = kmap_atomic(sg_page(sg));
- r = crypt_iv_lmk_one(cc, iv, dmreq, src + sg->offset);
- kunmap_atomic(src);
+ src = sg_map(sg, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(src))
+ return PTR_ERR(src);
+
+ r = crypt_iv_lmk_one(cc, iv, dmreq, src);
+ sg_unmap(sg, src, 0, SG_KMAP_ATOMIC);
} else
memset(iv, 0, cc->iv_size);
@@ -655,14 +658,18 @@ static int crypt_iv_lmk_post(struct crypt_config *cc, u8
*iv,
return 0;
sg = crypt_get_sg_data(cc, dmreq->sg_out);
- dst = kmap_atomic(sg_page(sg));
- r = crypt_iv_lmk_one(cc, iv, dmreq, dst + sg->offset);
+ dst = sg_map(sg, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(dst))
+ return PTR_ERR(dst);
+
+ r = crypt_iv_lmk_one(cc, iv, dmreq, dst);
/* Tweak the first block of plaintext sector */
if (!r)
- crypto_xor(dst + sg->offset, iv, cc->iv_size);
+ crypto_xor(dst, iv, cc->iv_size);
+
+ sg_unmap(sg, dst, 0, SG_KMAP_ATOMIC);
- kunmap_atomic(dst);
return r;
}
@@ -786,9 +793,12 @@ static int crypt_iv_tcw_gen(struct crypt_config *cc, u8
*iv,
/* Remove whitening from ciphertext */
if (bio_data_dir(dmreq->ctx->bio_in) != WRITE) {
sg = crypt_get_sg_data(cc, dmreq->sg_in);
- src = kmap_atomic(sg_page(sg));
- r = crypt_iv_tcw_whitening(cc, dmreq, src + sg->offset);
- kunmap_atomic(src);
+ src = sg_map(sg, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(src))
+ return PTR_ERR(src);
+
+ r = crypt_iv_tcw_whitening(cc, dmreq, src);
+ sg_unmap(sg, src, 0, SG_KMAP_ATOMIC);
}
/* Calculate IV */
@@ -812,9 +822,12 @@ static int crypt_iv_tcw_post(struct crypt_config *cc, u8
*iv,
/* Apply whitening on ciphertext */
sg = crypt_get_sg_data(cc, dmreq->sg_out);
- dst = kmap_atomic(sg_page(sg));
- r = crypt_iv_tcw_whitening(cc, dmreq, dst + sg->offset);
- kunmap_atomic(dst);
+ dst = sg_map(sg, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(dst))
+ return PTR_ERR(dst);
+
+ r = crypt_iv_tcw_whitening(cc, dmreq, dst);
+ sg_unmap(sg, dst, 0, SG_KMAP_ATOMIC);
return r;
}
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 16/21] mmc: sdhci: Make use of the new sg_map helper function
Straightforward conversion, except due to the lack of an error path we
have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases
in the future.
Signed-off-by: Logan Gunthorpe
Cc: Adrian Hunter
Cc: Ulf Hansson
---
drivers/mmc/host/sdhci.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ecd0d43..239507f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -513,15 +513,19 @@ static int sdhci_pre_dma_transfer(struct sdhci_host *host,
return sg_count;
}
+/*
+ * Note this function may return PTR_ERR and must be checked.
+ */
static char *sdhci_kmap_atomic(struct scatterlist *sg, unsigned long *flags)
{
local_irq_save(*flags);
- return kmap_atomic(sg_page(sg)) + sg->offset;
+ return sg_map(sg, 0, SG_KMAP_ATOMIC | SG_MAP_MUST_NOT_FAIL);
}
-static void sdhci_kunmap_atomic(void *buffer, unsigned long *flags)
+static void sdhci_kunmap_atomic(struct scatterlist *sg, void *buffer,
+ unsigned long *flags)
{
- kunmap_atomic(buffer);
+ sg_unmap(sg, buffer, 0, SG_KMAP_ATOMIC);
local_irq_restore(*flags);
}
@@ -585,7 +589,7 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
if (data->flags & MMC_DATA_WRITE) {
buffer = sdhci_kmap_atomic(sg, &flags);
memcpy(align, buffer, offset);
- sdhci_kunmap_atomic(buffer, &flags);
+ sdhci_kunmap_atomic(sg, buffer, &flags);
}
/* tran, valid */
@@ -663,7 +667,7 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
buffer = sdhci_kmap_atomic(sg, &flags);
memcpy(buffer, align, size);
- sdhci_kunmap_atomic(buffer, &flags);
+ sdhci_kunmap_atomic(sg, buffer, &flags);
align += SDHCI_ADMA2_ALIGN;
}
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: Add support for clockgating on Fermi+
Hi Lyude,
thanks for the great work. Just a view comments inline.
2017-04-25 20:38 GMT+02:00 Lyude :
> This adds support for enabling automatic clockgating on nvidia GPUs for
> Fermi and later generations. This saves a little bit of power, bringing
> my fermi GPU's power consumption from ~28.3W on idle to ~27W, and my
> kepler's idle power consumption from ~23.6W to ~21.65W.
>
> Similar to how the nvidia driver seems to handle this, we enable
> clockgating for each engine that supports it after it's initialization.
>
> Signed-off-by: Lyude
> ---
> .../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 4 ++
> drivers/gpu/drm/nouveau/nvkm/core/engine.c | 20 +-
> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 14 ++--
> drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild | 2 +
> drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 2 +
> .../gpu/drm/nouveau/nvkm/subdev/therm/clkgate.c| 49 ++
> drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c | 77
> ++
> drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 2 +
> drivers/gpu/drm/nouveau/nvkm/subdev/therm/gm107.c | 2 +
> drivers/gpu/drm/nouveau/nvkm/subdev/therm/gt215.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/therm/priv.h | 10 +++
> 11 files changed, 175 insertions(+), 9 deletions(-)
> create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/clkgate.c
> create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c
>
> diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> index b268b96..904aa56 100644
> --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> @@ -84,6 +84,9 @@ struct nvkm_therm {
>
> int (*attr_get)(struct nvkm_therm *, enum nvkm_therm_attr_type);
> int (*attr_set)(struct nvkm_therm *, enum nvkm_therm_attr_type, int);
> +
> + int (*clkgate_engine)(struct nvkm_therm *, enum nvkm_devidx);
> + void (*clkgate_set)(struct nvkm_therm *, int gate_idx, bool enable);
remove those and have a simple "nvkm_therm_clkgate_engine" function
This way you know that every user calls this function and don't have
to check for silly function pointers like you currently do in engine.c
> };
>
> int nvkm_therm_temp_get(struct nvkm_therm *);
> @@ -94,6 +97,7 @@ int nv40_therm_new(struct nvkm_device *, int, struct
> nvkm_therm **);
> int nv50_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
> int g84_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
> int gt215_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
> +int gf100_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
> int gf119_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
> int gm107_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
> #endif
> diff --git a/drivers/gpu/drm/nouveau/nvkm/core/engine.c
> b/drivers/gpu/drm/nouveau/nvkm/core/engine.c
> index b6c9169..473ad3e 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/core/engine.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/core/engine.c
> @@ -26,6 +26,7 @@
> #include
>
> #include
> +#include
>
> bool
> nvkm_engine_chsw_load(struct nvkm_engine *engine)
> @@ -86,6 +87,13 @@ static int
> nvkm_engine_fini(struct nvkm_subdev *subdev, bool suspend)
> {
> struct nvkm_engine *engine = nvkm_engine(subdev);
> + struct nvkm_therm *therm = subdev->device->therm;
> + int gate_idx;
> +
> + gate_idx = therm->clkgate_engine(therm, subdev->index);
> + if (gate_idx != -1)
> + therm->clkgate_set(therm, gate_idx, false);
> +
move this code inside "nvkm_therm_clkgate_engine". Nobody outside
nvkm_therm should even care about the index.
> if (engine->func->fini)
> return engine->func->fini(engine, suspend);
> return 0;
> @@ -96,12 +104,13 @@ nvkm_engine_init(struct nvkm_subdev *subdev)
> {
> struct nvkm_engine *engine = nvkm_engine(subdev);
> struct nvkm_fb *fb = subdev->device->fb;
> + struct nvkm_therm *therm = subdev->device->therm;
> int ret = 0, i;
> s64 time;
>
> if (!engine->usecount) {
> nvkm_trace(subdev, "init skipped, engine has no users\n");
> - return ret;
> + goto finish;
> }
>
> if (engine->func->oneinit && !engine->subdev.oneinit) {
> @@ -123,6 +132,15 @@ nvkm_engine_init(struct nvkm_subdev *subdev)
>
> for (i = 0; fb && i < fb->tile.regions; i++)
> nvkm_engine_tile(engine, i);
> +
> +finish:
> + if (!ret) {
> + int gate_idx = therm->clkgate_engine(therm, subdev->index);
> +
> + if (gate_idx != -1)
> + therm->clkgate_set(therm, gate_idx, true);
> + }
> +
same code as above. More code sharing!
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/devic
[PATCH v2 14/21] scsi: libfc, csiostor: Change to sg_copy_buffer in two drivers
These two drivers appear to duplicate the functionality of
sg_copy_buffer. So we clean them up to use the common code.
This helps us remove a couple of instances that would otherwise be
slightly tricky sg_map usages.
Signed-off-by: Logan Gunthorpe
Cc: Johannes Thumshirn
---
drivers/scsi/csiostor/csio_scsi.c | 54 +++
drivers/scsi/libfc/fc_libfc.c | 49 ---
2 files changed, 14 insertions(+), 89 deletions(-)
diff --git a/drivers/scsi/csiostor/csio_scsi.c
b/drivers/scsi/csiostor/csio_scsi.c
index a1ff75f..bd9d062 100644
--- a/drivers/scsi/csiostor/csio_scsi.c
+++ b/drivers/scsi/csiostor/csio_scsi.c
@@ -1489,60 +1489,14 @@ static inline uint32_t
csio_scsi_copy_to_sgl(struct csio_hw *hw, struct csio_ioreq *req)
{
struct scsi_cmnd *scmnd = (struct scsi_cmnd *)csio_scsi_cmnd(req);
- struct scatterlist *sg;
- uint32_t bytes_left;
- uint32_t bytes_copy;
- uint32_t buf_off = 0;
- uint32_t start_off = 0;
- uint32_t sg_off = 0;
- void *sg_addr;
- void *buf_addr;
struct csio_dma_buf *dma_buf;
+ size_t copied;
- bytes_left = scsi_bufflen(scmnd);
- sg = scsi_sglist(scmnd);
dma_buf = (struct csio_dma_buf *)csio_list_next(&req->gen_list);
+ copied = sg_copy_from_buffer(scsi_sglist(scmnd), scsi_sg_count(scmnd),
+dma_buf->vaddr, scsi_bufflen(scmnd));
- /* Copy data from driver buffer to SGs of SCSI CMD */
- while (bytes_left > 0 && sg && dma_buf) {
- if (buf_off >= dma_buf->len) {
- buf_off = 0;
- dma_buf = (struct csio_dma_buf *)
- csio_list_next(dma_buf);
- continue;
- }
-
- if (start_off >= sg->length) {
- start_off -= sg->length;
- sg = sg_next(sg);
- continue;
- }
-
- buf_addr = dma_buf->vaddr + buf_off;
- sg_off = sg->offset + start_off;
- bytes_copy = min((dma_buf->len - buf_off),
- sg->length - start_off);
- bytes_copy = min((uint32_t)(PAGE_SIZE - (sg_off & ~PAGE_MASK)),
-bytes_copy);
-
- sg_addr = kmap_atomic(sg_page(sg) + (sg_off >> PAGE_SHIFT));
- if (!sg_addr) {
- csio_err(hw, "failed to kmap sg:%p of ioreq:%p\n",
- sg, req);
- break;
- }
-
- csio_dbg(hw, "copy_to_sgl:sg_addr %p sg_off %d buf %p len %d\n",
- sg_addr, sg_off, buf_addr, bytes_copy);
- memcpy(sg_addr + (sg_off & ~PAGE_MASK), buf_addr, bytes_copy);
- kunmap_atomic(sg_addr);
-
- start_off += bytes_copy;
- buf_off += bytes_copy;
- bytes_left -= bytes_copy;
- }
-
- if (bytes_left > 0)
+ if (copied != scsi_bufflen(scmnd))
return DID_ERROR;
else
return DID_OK;
diff --git a/drivers/scsi/libfc/fc_libfc.c b/drivers/scsi/libfc/fc_libfc.c
index d623d08..ce0805a 100644
--- a/drivers/scsi/libfc/fc_libfc.c
+++ b/drivers/scsi/libfc/fc_libfc.c
@@ -113,45 +113,16 @@ u32 fc_copy_buffer_to_sglist(void *buf, size_t len,
u32 *nents, size_t *offset,
u32 *crc)
{
- size_t remaining = len;
- u32 copy_len = 0;
-
- while (remaining > 0 && sg) {
- size_t off, sg_bytes;
- void *page_addr;
-
- if (*offset >= sg->length) {
- /*
-* Check for end and drop resources
-* from the last iteration.
-*/
- if (!(*nents))
- break;
- --(*nents);
- *offset -= sg->length;
- sg = sg_next(sg);
- continue;
- }
- sg_bytes = min(remaining, sg->length - *offset);
-
- /*
-* The scatterlist item may be bigger than PAGE_SIZE,
-* but we are limited to mapping PAGE_SIZE at a time.
-*/
- off = *offset + sg->offset;
- sg_bytes = min(sg_bytes,
- (size_t)(PAGE_SIZE - (off & ~PAGE_MASK)));
- page_addr = kmap_atomic(sg_page(sg) + (off >> PAGE_SHIFT));
- if (crc)
- *crc = crc32(*crc, buf, sg_bytes);
- memcpy((char *)page_addr + (off & ~PAGE_MASK), buf, sg_bytes);
- kunmap_atomic(page_addr);
- buf += sg_bytes;
- *offset += sg_bytes;
- remaining -= sg_bytes;
[PATCH] drm/panel: Add driver for Seiko 43WVF1G panel
Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480)
TFT with Touch-Panel.
Datasheet available at:
http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf
Seiko 43WVF1G panel has two power supplies: AVDD and DVDD and they
require a specific power on/down sequence.
For this reason the simple panel driver cannot be used to drive this
panel, so create a new one heavily based on simple panel.
Based on initial patch submission from Breno Lima.
Signed-off-by: Marco Franchi
---
.../bindings/display/panel/seiko,43wvf1g.txt | 23 ++
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c| 372 +
4 files changed, 405 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt
create mode 100644 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
diff --git a/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt
b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt
new file mode 100644
index 000..cd1eeda
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt
@@ -0,0 +1,23 @@
+Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) TFT with Touch-Panel
+
+Required properties:
+- compatible: should be "sii,43wvf1g".
+- "DVDD-supply": 3v3 digital regulator.
+- "AVDD-supply": 5v analog regulator.
+
+Optional properties:
+- backlight: phandle for the backlight control.
+
+Example:
+
+ panel {
+ compatible = "sii,43wvf1g";
+ backlight = <&backlight_display>;
+ DVDD-supply = <®_lcd_3v3>;
+ AVDD-supply = <®_lcd_5v>;
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+ };
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e29a99..2f50325 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -74,6 +74,15 @@ config DRM_PANEL_SAMSUNG_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
+config DRM_PANEL_SEIKO_43WVF1G
+ tristate "Seiko 43WVF1G panel"
+ depends on OF
+ depends on BACKLIGHT_CLASS_DEVICE
+ select VIDEOMODE_HELPERS
+ help
+ Say Y here if you want to enable support for the Seiko
+ 43WVF1G controller for 800x480 LCD panels
+
config DRM_PANEL_SHARP_LQ101R1SX01
tristate "Sharp LQ101R1SX01 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 292b3c7..a93d04d 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
diff --git a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
new file mode 100644
index 000..2e58abe
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
@@ -0,0 +1,372 @@
+/*
+ * Copyright (C) 2017 NXP Semiconductors.
+ * Author: Marco Franchi
+ *
+ * Based on Panel Simple driver by Thierry Reding
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+struct seiko_panel_desc {
+ const struct drm_display_mode *modes;
+ unsigned int num_modes;
+ const struct display_timing *timings;
+ unsigned int num_timings;
+
+ unsigned int bpc;
+
+ /**
+* @width: width (in millimeters) of the panel's active display area
+* @height: height (in millimeters) of the panel's active display area
+*/
+ struct {
+ unsigned int width;
+ unsigned int height;
+ } size;
+
+ u32 bus_format;
+ u32 bus_flags;
+};
+
+struct seiko_panel {
+ struct drm_panel base;
+ bool prepared;
+ bool enabled;
+ const struct seiko_panel_desc *desc;
+ struct backlight_device *backlight;
+ struct regulator *DVDD;
+ struct regulator *AVDD;
+};
+
+static inline struct seiko_panel *to_seiko_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct seiko_panel, base);
+}
[PATCH v2 02/21] libiscsi: Add an internal error code
This is a prep patch to add a new error code to libiscsi. We want to
rework some kmap calls to be able to fail. When we do, we'd like to
use this error code.
This patch simply introduces ISCSI_TCP_INTERNAL_ERR and prints
"Internal Error." when it gets hit.
Signed-off-by: Logan Gunthorpe
---
drivers/scsi/cxgbi/libcxgbi.c | 5 +
include/scsi/libiscsi_tcp.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index bd7d39e..e38d0c1 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -1556,6 +1556,11 @@ static inline int read_pdu_skb(struct iscsi_conn *conn,
*/
iscsi_conn_printk(KERN_ERR, conn, "Invalid pdu or skb.");
return -EFAULT;
+ case ISCSI_TCP_INTERNAL_ERR:
+ pr_info("skb 0x%p, off %u, %d, TCP_INTERNAL_ERR.\n",
+ skb, offset, offloaded);
+ iscsi_conn_printk(KERN_ERR, conn, "Internal error.");
+ return -EFAULT;
case ISCSI_TCP_SEGMENT_DONE:
log_debug(1 << CXGBI_DBG_PDU_RX,
"skb 0x%p, off %u, %d, TCP_SEG_DONE, rc %d.\n",
diff --git a/include/scsi/libiscsi_tcp.h b/include/scsi/libiscsi_tcp.h
index 30520d5..90691ad 100644
--- a/include/scsi/libiscsi_tcp.h
+++ b/include/scsi/libiscsi_tcp.h
@@ -92,6 +92,7 @@ enum {
ISCSI_TCP_SKB_DONE, /* skb is out of data */
ISCSI_TCP_CONN_ERR, /* iscsi layer has fired a conn err */
ISCSI_TCP_SUSPENDED,/* conn is suspended */
+ ISCSI_TCP_INTERNAL_ERR, /* an internal error occurred */
};
extern void iscsi_tcp_hdr_recv_prep(struct iscsi_tcp_conn *tcp_conn);
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/sun4i: backend: Clarify sun4i_backend_layer_enable debug message
sun4i_backend_layer_enable can be called to enable or disable a layer.
However the debug message always says "Enable", which is confusing.
This patch makes the debug message vary according to the enable state.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index e9eca057ff35..e53107418add 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -73,7 +73,8 @@ void sun4i_backend_layer_enable(struct sun4i_backend *backend,
{
u32 val;
- DRM_DEBUG_DRIVER("Enabling layer %d\n", layer);
+ DRM_DEBUG_DRIVER("%sabling layer %d\n", enable ? "En" : "Dis",
+layer);
if (enable)
val = SUN4I_BACKEND_MODCTL_LAY_EN(layer);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/sun4i: Set TCON clock inside sun4i_tconX_mode_set
Currently we are configuring the TCON's dot clock or special clock
directly from the encoder mode_set functions. Since we already
provide mode_set helper functions for the TCON's 2 channels, we
can set the respective clock from those helpers, and reduce the
exposure of the TCON's internals.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 --
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++
drivers/gpu/drm/sun4i/sun4i_tv.c | 2 --
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 1147451eb993..51ece4c39d7e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -175,8 +175,6 @@ static void sun4i_rgb_encoder_mode_set(struct drm_encoder
*encoder,
sun4i_tcon0_mode_set(tcon, mode);
- clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
-
/* FIXME: This seems to be board specific */
clk_set_phase(tcon->dclk, 120);
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 8301389c411d..29fd829aa54c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -131,6 +131,9 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
u8 clk_delay;
u32 val = 0;
+ /* Configure the dot clock */
+ clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
+
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
@@ -206,6 +209,9 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
WARN_ON(!tcon->quirks->has_channel_1);
+ /* Configure the dot clock */
+ clk_set_rate(tcon->sclk1, mode->crtc_clock * 1000);
+
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 1);
regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 49c49431a053..542da220818b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -486,8 +486,6 @@ static void sun4i_tv_mode_set(struct drm_encoder *encoder,
SUN4I_TVE_RESYNC_FIELD : 0));
regmap_write(tv->regs, SUN4I_TVE_SLAVE_REG, 0);
-
- clk_set_rate(tcon->sclk1, mode->crtc_clock * 1000);
}
static struct drm_encoder_helper_funcs sun4i_tv_helper_funcs = {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/nouveau/secboot/gm20b: fix the error return code in gm20b_secboot_tegra_read_wpr()
From: Wei Yongjun
The error return code PTR_ERR(mc) is always 0 since mc is
equal to 0 in this error handling case.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
index b10ed59..30491d1 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
@@ -48,7 +48,7 @@ gm20b_secboot_tegra_read_wpr(struct gm200_secboot *gsb, u32
mc_base)
mc = ioremap(mc_base, 0xd00);
if (!mc) {
nvkm_error(&sb->subdev, "Cannot map Tegra MC registers\n");
- return PTR_ERR(mc);
+ return -ENOMEM;
}
sb->wpr_addr = ioread32_native(mc + MC_SECURITY_CARVEOUT2_BOM_0) |
((u64)ioread32_native(mc + MC_SECURITY_CARVEOUT2_BOM_HI_0) << 32);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 12/21] scsi: hisi_sas, mvsas, gdth: Make use of the new sg_map helper function
Very straightforward conversion of three scsi drivers.
Signed-off-by: Logan Gunthorpe
Cc: Achim Leubner
Cc: John Garry
---
drivers/scsi/gdth.c| 9 +++--
drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 14 +-
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 13 +
drivers/scsi/mvsas/mv_sas.c| 10 +-
4 files changed, 30 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index d020a13..c70248a2 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -2301,10 +2301,15 @@ static void gdth_copy_internal_data(gdth_ha_str *ha,
Scsi_Cmnd *scp,
return;
}
local_irq_save(flags);
-address = kmap_atomic(sg_page(sl)) + sl->offset;
+address = sg_map(sl, 0, SG_KMAP_ATOMIC);
+if (IS_ERR(address)) {
+scp->result = DID_ERROR << 16;
+return;
+ }
+
memcpy(address, buffer, cpnow);
flush_dcache_page(sg_page(sl));
-kunmap_atomic(address);
+sg_unmap(sl, address, 0, SG_KMAP_ATOMIC);
local_irq_restore(flags);
if (cpsum == cpcount)
break;
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index fc1c1b2..b3953e3 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -1381,18 +1381,22 @@ static int slot_complete_v1_hw(struct hisi_hba
*hisi_hba,
void *to;
struct scatterlist *sg_resp = &task->smp_task.smp_resp;
- ts->stat = SAM_STAT_GOOD;
- to = kmap_atomic(sg_page(sg_resp));
+ to = sg_map(sg_resp, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(to)) {
+ dev_err(dev, "slot complete: error mapping memory");
+ ts->stat = SAS_SG_ERR;
+ break;
+ }
+ ts->stat = SAM_STAT_GOOD;
dma_unmap_sg(dev, &task->smp_task.smp_resp, 1,
DMA_FROM_DEVICE);
dma_unmap_sg(dev, &task->smp_task.smp_req, 1,
DMA_TO_DEVICE);
- memcpy(to + sg_resp->offset,
- slot->status_buffer +
+ memcpy(to, slot->status_buffer +
sizeof(struct hisi_sas_err_record),
sg_dma_len(sg_resp));
- kunmap_atomic(to);
+ sg_unmap(sg_resp, to, 0, SG_KMAP_ATOMIC);
break;
}
case SAS_PROTOCOL_SATA:
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index e241921..3e674a4 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -2307,18 +2307,23 @@ slot_complete_v2_hw(struct hisi_hba *hisi_hba, struct
hisi_sas_slot *slot)
struct scatterlist *sg_resp = &task->smp_task.smp_resp;
void *to;
+ to = sg_map(sg_resp, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(to)) {
+ dev_err(dev, "slot complete: error mapping memory");
+ ts->stat = SAS_SG_ERR;
+ break;
+ }
+
ts->stat = SAM_STAT_GOOD;
- to = kmap_atomic(sg_page(sg_resp));
dma_unmap_sg(dev, &task->smp_task.smp_resp, 1,
DMA_FROM_DEVICE);
dma_unmap_sg(dev, &task->smp_task.smp_req, 1,
DMA_TO_DEVICE);
- memcpy(to + sg_resp->offset,
- slot->status_buffer +
+ memcpy(to, slot->status_buffer +
sizeof(struct hisi_sas_err_record),
sg_dma_len(sg_resp));
- kunmap_atomic(to);
+ sg_unmap(sg_resp, to, 0, SG_KMAP_ATOMIC);
break;
}
case SAS_PROTOCOL_SATA:
diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c
index c7cc803..a72e0ce 100644
--- a/drivers/scsi/mvsas/mv_sas.c
+++ b/drivers/scsi/mvsas/mv_sas.c
@@ -1798,11 +1798,11 @@ int mvs_slot_complete(struct mvs_info *mvi, u32
rx_desc, u32 flags)
case SAS_PROTOCOL_SMP: {
struct scatterlist *sg_resp = &task->smp_task.smp_resp;
tstat->stat = SAM_STAT_GOOD;
- to = kmap_atomic(sg_page(sg_resp));
- memcpy(to + sg_resp->offset,
- slot->response + sizeof(struct mvs_err_info),
- sg_dma_len(sg_resp));
- kunmap_atomic(to);
+ to = sg_map(sg_resp, 0, SG_KMAP_ATOMIC);
+ memcpy(to,
+ slot->response + sizeof(struct mvs_err_info),
+ sg_dma_len(sg_resp));
+
[PATCH v2 18/21] mmc: tmio: Make use of the new sg_map helper function
Straightforward conversion to sg_map helper. Seeing there is no
cleare error path, SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain
cases in the future.
Signed-off-by: Logan Gunthorpe
Cc: Wolfram Sang
Cc: Ulf Hansson
---
drivers/mmc/host/tmio_mmc.h | 7 +--
drivers/mmc/host/tmio_mmc_pio.c | 12
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index d0edb57..bc43eb0 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -202,17 +202,20 @@ void tmio_mmc_enable_mmc_irqs(struct tmio_mmc_host *host,
u32 i);
void tmio_mmc_disable_mmc_irqs(struct tmio_mmc_host *host, u32 i);
irqreturn_t tmio_mmc_irq(int irq, void *devid);
+/* Note: this function may return PTR_ERR and must be checked! */
static inline char *tmio_mmc_kmap_atomic(struct scatterlist *sg,
unsigned long *flags)
{
+ void *ret;
+
local_irq_save(*flags);
- return kmap_atomic(sg_page(sg)) + sg->offset;
+ return sg_map(sg, 0, SG_KMAP_ATOMIC | SG_MAP_MUST_NOT_FAIL);
}
static inline void tmio_mmc_kunmap_atomic(struct scatterlist *sg,
unsigned long *flags, void *virt)
{
- kunmap_atomic(virt - sg->offset);
+ sg_unmap(sg, virt, 0, SG_KMAP_ATOMIC);
local_irq_restore(*flags);
}
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index a2d92f1..bbb4f19 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -506,6 +506,18 @@ static void tmio_mmc_check_bounce_buffer(struct
tmio_mmc_host *host)
if (host->sg_ptr == &host->bounce_sg) {
unsigned long flags;
void *sg_vaddr = tmio_mmc_kmap_atomic(host->sg_orig, &flags);
+ if (IS_ERR(sg_vaddr)) {
+ /*
+* This should really never happen unless
+* the code is changed to use memory that is
+* not mappable in the sg. Seeing there doesn't
+* seem to be any error path out of here,
+* we can only WARN.
+*/
+ WARN(1, "Non-mappable memory used in sg!");
+ return;
+ }
+
memcpy(sg_vaddr, host->bounce_buf, host->bounce_sg.length);
tmio_mmc_kunmap_atomic(host->sg_orig, &flags, sg_vaddr);
}
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/21] staging: unisys: visorbus: Make use of the new sg_map helper function
Straightforward conversion to the new function.
Signed-off-by: Logan Gunthorpe
Acked-by: David Kershner
---
drivers/staging/unisys/visorhba/visorhba_main.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c
b/drivers/staging/unisys/visorhba/visorhba_main.c
index d372115..c77426c 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -843,7 +843,6 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct
scsi_cmnd *scsicmd)
struct scatterlist *sg;
unsigned int i;
char *this_page;
- char *this_page_orig;
int bufind = 0;
struct visordisk_info *vdisk;
struct visorhba_devdata *devdata;
@@ -870,11 +869,14 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct
scsi_cmnd *scsicmd)
sg = scsi_sglist(scsicmd);
for (i = 0; i < scsi_sg_count(scsicmd); i++) {
- this_page_orig = kmap_atomic(sg_page(sg + i));
- this_page = (void *)((unsigned long)this_page_orig |
-sg[i].offset);
+ this_page = sg_map(sg + i, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(this_page)) {
+ scsicmd->result = DID_ERROR << 16;
+ return;
+ }
+
memcpy(this_page, buf + bufind, sg[i].length);
- kunmap_atomic(this_page_orig);
+ sg_unmap(sg + i, this_page, 0, SG_KMAP_ATOMIC);
}
} else {
devdata = (struct visorhba_devdata *)scsidev->host->hostdata;
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/21] libiscsi: Make use of new the sg_map helper function
Convert the kmap and kmap_atomic uses to the sg_map function. We now
store the flags for the kmap instead of a boolean to indicate
atomicitiy. We use ISCSI_TCP_INTERNAL_ERR error type that was prepared
earlier for this.
Signed-off-by: Logan Gunthorpe
Cc: Lee Duncan
Cc: Chris Leech
---
drivers/scsi/libiscsi_tcp.c | 32
include/scsi/libiscsi_tcp.h | 2 +-
2 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c
index 63a1d69..a34e25c 100644
--- a/drivers/scsi/libiscsi_tcp.c
+++ b/drivers/scsi/libiscsi_tcp.c
@@ -133,25 +133,23 @@ static void iscsi_tcp_segment_map(struct iscsi_segment
*segment, int recv)
if (page_count(sg_page(sg)) >= 1 && !recv)
return;
- if (recv) {
- segment->atomic_mapped = true;
- segment->sg_mapped = kmap_atomic(sg_page(sg));
- } else {
- segment->atomic_mapped = false;
- /* the xmit path can sleep with the page mapped so use kmap */
- segment->sg_mapped = kmap(sg_page(sg));
+ /* the xmit path can sleep with the page mapped so don't use atomic */
+ segment->sg_map_flags = recv ? SG_KMAP_ATOMIC : SG_KMAP;
+ segment->sg_mapped = sg_map(sg, 0, segment->sg_map_flags);
+
+ if (IS_ERR(segment->sg_mapped)) {
+ segment->sg_mapped = NULL;
+ return;
}
- segment->data = segment->sg_mapped + sg->offset + segment->sg_offset;
+ segment->data = segment->sg_mapped + segment->sg_offset;
}
void iscsi_tcp_segment_unmap(struct iscsi_segment *segment)
{
if (segment->sg_mapped) {
- if (segment->atomic_mapped)
- kunmap_atomic(segment->sg_mapped);
- else
- kunmap(sg_page(segment->sg));
+ sg_unmap(segment->sg, segment->sg_mapped, 0,
+segment->sg_map_flags);
segment->sg_mapped = NULL;
segment->data = NULL;
}
@@ -304,6 +302,9 @@ iscsi_tcp_segment_recv(struct iscsi_tcp_conn *tcp_conn,
break;
}
+ if (segment->data)
+ return -EFAULT;
+
copy = min(len - copied, segment->size - segment->copied);
ISCSI_DBG_TCP(tcp_conn->iscsi_conn, "copying %d\n", copy);
memcpy(segment->data + segment->copied, ptr + copied, copy);
@@ -927,6 +928,13 @@ int iscsi_tcp_recv_skb(struct iscsi_conn *conn, struct
sk_buff *skb,
avail);
rc = iscsi_tcp_segment_recv(tcp_conn, segment, ptr, avail);
BUG_ON(rc == 0);
+ if (rc < 0) {
+ ISCSI_DBG_TCP(conn, "memory fault. Consumed %d\n",
+ consumed);
+ *status = ISCSI_TCP_INTERNAL_ERR;
+ goto skb_done;
+ }
+
consumed += rc;
if (segment->total_copied >= segment->total_size) {
diff --git a/include/scsi/libiscsi_tcp.h b/include/scsi/libiscsi_tcp.h
index 90691ad..58c79af 100644
--- a/include/scsi/libiscsi_tcp.h
+++ b/include/scsi/libiscsi_tcp.h
@@ -47,7 +47,7 @@ struct iscsi_segment {
struct scatterlist *sg;
void*sg_mapped;
unsigned intsg_offset;
- boolatomic_mapped;
+ int sg_map_flags;
iscsi_segment_done_fn_t *done;
};
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 21/21] memstick: Make use of the new sg_map helper function
Straightforward conversion, but we have to make use of
SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases
in the future.
Signed-off-by: Logan Gunthorpe
Cc: Alex Dubov
---
drivers/memstick/host/jmb38x_ms.c | 11 ++-
drivers/memstick/host/tifm_ms.c | 11 ++-
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/memstick/host/jmb38x_ms.c
b/drivers/memstick/host/jmb38x_ms.c
index 48db922..9019e37 100644
--- a/drivers/memstick/host/jmb38x_ms.c
+++ b/drivers/memstick/host/jmb38x_ms.c
@@ -303,7 +303,6 @@ static int jmb38x_ms_transfer_data(struct jmb38x_ms_host
*host)
unsigned int off;
unsigned int t_size, p_cnt;
unsigned char *buf;
- struct page *pg;
unsigned long flags = 0;
if (host->req->long_data) {
@@ -318,14 +317,14 @@ static int jmb38x_ms_transfer_data(struct jmb38x_ms_host
*host)
unsigned int uninitialized_var(p_off);
if (host->req->long_data) {
- pg = nth_page(sg_page(&host->req->sg),
- off >> PAGE_SHIFT);
p_off = offset_in_page(off);
p_cnt = PAGE_SIZE - p_off;
p_cnt = min(p_cnt, length);
local_irq_save(flags);
- buf = kmap_atomic(pg) + p_off;
+ buf = sg_map(&host->req->sg,
+off - host->req->sg.offset,
+SG_KMAP_ATOMIC | SG_MAP_MUST_NOT_FAIL);
} else {
buf = host->req->data + host->block_pos;
p_cnt = host->req->data_len - host->block_pos;
@@ -341,7 +340,9 @@ static int jmb38x_ms_transfer_data(struct jmb38x_ms_host
*host)
: jmb38x_ms_read_reg_data(host, buf, p_cnt);
if (host->req->long_data) {
- kunmap_atomic(buf - p_off);
+ sg_unmap(&host->req->sg, buf,
+off - host->req->sg.offset,
+SG_KMAP_ATOMIC);
local_irq_restore(flags);
}
diff --git a/drivers/memstick/host/tifm_ms.c b/drivers/memstick/host/tifm_ms.c
index 7bafa72..304985d 100644
--- a/drivers/memstick/host/tifm_ms.c
+++ b/drivers/memstick/host/tifm_ms.c
@@ -186,7 +186,6 @@ static unsigned int tifm_ms_transfer_data(struct tifm_ms
*host)
unsigned int off;
unsigned int t_size, p_cnt;
unsigned char *buf;
- struct page *pg;
unsigned long flags = 0;
if (host->req->long_data) {
@@ -203,14 +202,14 @@ static unsigned int tifm_ms_transfer_data(struct tifm_ms
*host)
unsigned int uninitialized_var(p_off);
if (host->req->long_data) {
- pg = nth_page(sg_page(&host->req->sg),
- off >> PAGE_SHIFT);
p_off = offset_in_page(off);
p_cnt = PAGE_SIZE - p_off;
p_cnt = min(p_cnt, length);
local_irq_save(flags);
- buf = kmap_atomic(pg) + p_off;
+ buf = sg_map(&host->req->sg,
+off - host->req->sg.offset,
+SG_KMAP_ATOMIC | SG_MAP_MUST_NOT_FAIL);
} else {
buf = host->req->data + host->block_pos;
p_cnt = host->req->data_len - host->block_pos;
@@ -221,7 +220,9 @@ static unsigned int tifm_ms_transfer_data(struct tifm_ms
*host)
: tifm_ms_read_data(host, buf, p_cnt);
if (host->req->long_data) {
- kunmap_atomic(buf - p_off);
+ sg_unmap(&host->req->sg, buf,
+off - host->req->sg.offset,
+SG_KMAP_ATOMIC | SG_MAP_MUST_NOT_FAIL);
local_irq_restore(flags);
}
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function
Straightforward conversion to the new helper, except due to the lack
of error path, we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in
certain cases in the future.
Signed-off-by: Logan Gunthorpe
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Konrad Rzeszutek Wilk
Cc: "Roger Pau Monné"
---
drivers/block/xen-blkfront.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 3945963..ed62175 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -816,8 +816,9 @@ static int blkif_queue_rw_req(struct request *req, struct
blkfront_ring_info *ri
BUG_ON(sg->offset + sg->length > PAGE_SIZE);
if (setup.need_copy) {
- setup.bvec_off = sg->offset;
- setup.bvec_data = kmap_atomic(sg_page(sg));
+ setup.bvec_off = 0;
+ setup.bvec_data = sg_map(sg, 0, SG_KMAP_ATOMIC |
+SG_MAP_MUST_NOT_FAIL);
}
gnttab_foreach_grant_in_range(sg_page(sg),
@@ -827,7 +828,7 @@ static int blkif_queue_rw_req(struct request *req, struct
blkfront_ring_info *ri
&setup);
if (setup.need_copy)
- kunmap_atomic(setup.bvec_data);
+ sg_unmap(sg, setup.bvec_data, 0, SG_KMAP_ATOMIC);
}
if (setup.segments)
kunmap_atomic(setup.segments);
@@ -1053,7 +1054,7 @@ static int xen_translate_vdev(int vdevice, int *minor,
unsigned int *offset)
case XEN_SCSI_DISK5_MAJOR:
case XEN_SCSI_DISK6_MAJOR:
case XEN_SCSI_DISK7_MAJOR:
- *offset = (*minor / PARTS_PER_DISK) +
+ *offset = (*minor / PARTS_PER_DISK) +
((major - XEN_SCSI_DISK1_MAJOR + 1) * 16) +
EMULATED_SD_DISK_NAME_OFFSET;
*minor = *minor +
@@ -1068,7 +1069,7 @@ static int xen_translate_vdev(int vdevice, int *minor,
unsigned int *offset)
case XEN_SCSI_DISK13_MAJOR:
case XEN_SCSI_DISK14_MAJOR:
case XEN_SCSI_DISK15_MAJOR:
- *offset = (*minor / PARTS_PER_DISK) +
+ *offset = (*minor / PARTS_PER_DISK) +
((major - XEN_SCSI_DISK8_MAJOR + 8) * 16) +
EMULATED_SD_DISK_NAME_OFFSET;
*minor = *minor +
@@ -1119,7 +1120,7 @@ static int xlvbd_alloc_gendisk(blkif_sector_t capacity,
if (!VDEV_IS_EXTENDED(info->vdevice)) {
err = xen_translate_vdev(info->vdevice, &minor, &offset);
if (err)
- return err;
+ return err;
nr_parts = PARTS_PER_DISK;
} else {
minor = BLKIF_MINOR_EXT(info->vdevice);
@@ -1483,8 +1484,9 @@ static bool blkif_completion(unsigned long *id,
for_each_sg(s->sg, sg, num_sg, i) {
BUG_ON(sg->offset + sg->length > PAGE_SIZE);
- data.bvec_offset = sg->offset;
- data.bvec_data = kmap_atomic(sg_page(sg));
+ data.bvec_offset = 0;
+ data.bvec_data = sg_map(sg, 0, SG_KMAP_ATOMIC |
+ SG_MAP_MUST_NOT_FAIL);
gnttab_foreach_grant_in_range(sg_page(sg),
sg->offset,
@@ -1492,7 +1494,7 @@ static bool blkif_completion(unsigned long *id,
blkif_copy_from_grant,
&data);
- kunmap_atomic(data.bvec_data);
+ sg_unmap(sg, data.bvec_data, 0, SG_KMAP_ATOMIC);
}
}
/* Add the persistent grant into the list of free grants */
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/21] RDS: Make use of the new sg_map helper function
Straightforward conversion except there's no error path, so we
make use of SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases
in the future.
Signed-off-by: Logan Gunthorpe
Cc: Santosh Shilimkar
Cc: "David S. Miller"
---
net/rds/ib_recv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
index e10624a..c665689 100644
--- a/net/rds/ib_recv.c
+++ b/net/rds/ib_recv.c
@@ -800,10 +800,10 @@ static void rds_ib_cong_recv(struct rds_connection *conn,
to_copy = min(RDS_FRAG_SIZE - frag_off, PAGE_SIZE - map_off);
BUG_ON(to_copy & 7); /* Must be 64bit aligned. */
+ addr = sg_map(&frag->f_sg, 0,
+ SG_KMAP_ATOMIC | SG_MAP_MUST_NOT_FAIL);
- addr = kmap_atomic(sg_page(&frag->f_sg));
-
- src = addr + frag->f_sg.offset + frag_off;
+ src = addr + frag_off;
dst = (void *)map->m_page_addrs[map_page] + map_off;
for (k = 0; k < to_copy; k += 8) {
/* Record ports that became uncongested, ie
@@ -811,7 +811,7 @@ static void rds_ib_cong_recv(struct rds_connection *conn,
uncongested |= ~(*src) & *dst;
*dst++ = *src++;
}
- kunmap_atomic(addr);
+ sg_unmap(&frag->f_sg, addr, 0, SG_KMAP_ATOMIC);
copied += to_copy;
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/21] crypto: hifn_795x: Make use of the new sg_map helper function
Conversion of a couple kmap_atomic instances to the sg_map helper
function.
However, it looks like there was a bug in the original code: the source
scatter lists offset (t->offset) was passed to ablkcipher_get which
added it to the destination address. This doesn't make a lot of
sense, but t->offset is likely always zero anyway. So, this patch cleans
that brokeness up.
Also, a change to the error path: if ablkcipher_get failed, everything
seemed to proceed as if it hadn't. Setting 'error' should hopefully
clear that up.
Signed-off-by: Logan Gunthorpe
Cc: Herbert Xu
Cc: "David S. Miller"
---
drivers/crypto/hifn_795x.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index e09d405..34b1870 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -1619,7 +1619,7 @@ static int hifn_start_device(struct hifn_device *dev)
return 0;
}
-static int ablkcipher_get(void *saddr, unsigned int *srestp, unsigned int
offset,
+static int ablkcipher_get(void *saddr, unsigned int *srestp,
struct scatterlist *dst, unsigned int size, unsigned int
*nbytesp)
{
unsigned int srest = *srestp, nbytes = *nbytesp, copy;
@@ -1632,15 +1632,17 @@ static int ablkcipher_get(void *saddr, unsigned int
*srestp, unsigned int offset
while (size) {
copy = min3(srest, dst->length, size);
- daddr = kmap_atomic(sg_page(dst));
- memcpy(daddr + dst->offset + offset, saddr, copy);
- kunmap_atomic(daddr);
+ daddr = sg_map(dst, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(daddr))
+ return PTR_ERR(daddr);
+
+ memcpy(daddr, saddr, copy);
+ sg_unmap(dst, daddr, 0, SG_KMAP_ATOMIC);
nbytes -= copy;
size -= copy;
srest -= copy;
saddr += copy;
- offset = 0;
pr_debug("%s: copy: %u, size: %u, srest: %u, nbytes: %u.\n",
__func__, copy, size, srest, nbytes);
@@ -1671,11 +1673,12 @@ static inline void hifn_complete_sa(struct hifn_device
*dev, int i)
static void hifn_process_ready(struct ablkcipher_request *req, int error)
{
+ int err;
struct hifn_request_context *rctx = ablkcipher_request_ctx(req);
if (rctx->walk.flags & ASYNC_FLAGS_MISALIGNED) {
unsigned int nbytes = req->nbytes;
- int idx = 0, err;
+ int idx = 0;
struct scatterlist *dst, *t;
void *saddr;
@@ -1695,17 +1698,24 @@ static void hifn_process_ready(struct
ablkcipher_request *req, int error)
continue;
}
- saddr = kmap_atomic(sg_page(t));
+ saddr = sg_map(t, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(saddr)) {
+ if (!error)
+ error = PTR_ERR(saddr);
+ break;
+ }
+
+ err = ablkcipher_get(saddr, &t->length,
+dst, nbytes, &nbytes);
+ sg_unmap(t, saddr, 0, SG_KMAP_ATOMIC);
- err = ablkcipher_get(saddr, &t->length, t->offset,
- dst, nbytes, &nbytes);
if (err < 0) {
- kunmap_atomic(saddr);
+ if (!error)
+ error = err;
break;
}
idx += err;
- kunmap_atomic(saddr);
}
hifn_cipher_walk_exit(&rctx->walk);
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 20/21] mmc: tifm_sd: Make use of the new sg_map helper function
This conversion is a bit complicated. We modiy the read_fifo,
write_fifo and copy_page functions to take a scatterlist instead of a
page. Thus we can use sg_map instead of kmap_atomic. There's a bit of
accounting that needed to be done for the offset for this to work.
(Seeing sg_map takes care of the offset but it's already added and
used earlier in the code.)
There's also no error path, so we use SG_MAP_MUST_NOT_FAIL which may
BUG_ON in certain cases in the future.
Signed-off-by: Logan Gunthorpe
Cc: Alex Dubov
Cc: Ulf Hansson
---
drivers/mmc/host/tifm_sd.c | 50 +++---
1 file changed, 29 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/host/tifm_sd.c b/drivers/mmc/host/tifm_sd.c
index 93c4b40..e64345a 100644
--- a/drivers/mmc/host/tifm_sd.c
+++ b/drivers/mmc/host/tifm_sd.c
@@ -111,14 +111,16 @@ struct tifm_sd {
};
/* for some reason, host won't respond correctly to readw/writew */
-static void tifm_sd_read_fifo(struct tifm_sd *host, struct page *pg,
+static void tifm_sd_read_fifo(struct tifm_sd *host, struct scatterlist *sg,
unsigned int off, unsigned int cnt)
{
struct tifm_dev *sock = host->dev;
unsigned char *buf;
unsigned int pos = 0, val;
- buf = kmap_atomic(pg) + off;
+ buf = sg_map(sg, off - sg->offset,
+SG_KMAP_ATOMIC | SG_MAP_MUST_NOT_FAIL);
+
if (host->cmd_flags & DATA_CARRY) {
buf[pos++] = host->bounce_buf_data[0];
host->cmd_flags &= ~DATA_CARRY;
@@ -134,17 +136,19 @@ static void tifm_sd_read_fifo(struct tifm_sd *host,
struct page *pg,
}
buf[pos++] = (val >> 8) & 0xff;
}
- kunmap_atomic(buf - off);
+ sg_unmap(sg, buf, off - sg->offset, SG_KMAP_ATOMIC);
}
-static void tifm_sd_write_fifo(struct tifm_sd *host, struct page *pg,
+static void tifm_sd_write_fifo(struct tifm_sd *host, struct scatterlist *sg,
unsigned int off, unsigned int cnt)
{
struct tifm_dev *sock = host->dev;
unsigned char *buf;
unsigned int pos = 0, val;
- buf = kmap_atomic(pg) + off;
+ buf = sg_map(sg, off - sg->offset,
+SG_KMAP_ATOMIC | SG_MAP_MUST_NOT_FAIL);
+
if (host->cmd_flags & DATA_CARRY) {
val = host->bounce_buf_data[0] | ((buf[pos++] << 8) & 0xff00);
writel(val, sock->addr + SOCK_MMCSD_DATA);
@@ -161,7 +165,7 @@ static void tifm_sd_write_fifo(struct tifm_sd *host, struct
page *pg,
val |= (buf[pos++] << 8) & 0xff00;
writel(val, sock->addr + SOCK_MMCSD_DATA);
}
- kunmap_atomic(buf - off);
+ sg_unmap(sg, buf, off - sg->offset, SG_KMAP_ATOMIC);
}
static void tifm_sd_transfer_data(struct tifm_sd *host)
@@ -170,7 +174,6 @@ static void tifm_sd_transfer_data(struct tifm_sd *host)
struct scatterlist *sg = r_data->sg;
unsigned int off, cnt, t_size = TIFM_MMCSD_FIFO_SIZE * 2;
unsigned int p_off, p_cnt;
- struct page *pg;
if (host->sg_pos == host->sg_len)
return;
@@ -192,33 +195,39 @@ static void tifm_sd_transfer_data(struct tifm_sd *host)
}
off = sg[host->sg_pos].offset + host->block_pos;
- pg = nth_page(sg_page(&sg[host->sg_pos]), off >> PAGE_SHIFT);
p_off = offset_in_page(off);
p_cnt = PAGE_SIZE - p_off;
p_cnt = min(p_cnt, cnt);
p_cnt = min(p_cnt, t_size);
if (r_data->flags & MMC_DATA_READ)
- tifm_sd_read_fifo(host, pg, p_off, p_cnt);
+ tifm_sd_read_fifo(host, &sg[host->sg_pos], p_off,
+ p_cnt);
else if (r_data->flags & MMC_DATA_WRITE)
- tifm_sd_write_fifo(host, pg, p_off, p_cnt);
+ tifm_sd_write_fifo(host, &sg[host->sg_pos], p_off,
+ p_cnt);
t_size -= p_cnt;
host->block_pos += p_cnt;
}
}
-static void tifm_sd_copy_page(struct page *dst, unsigned int dst_off,
- struct page *src, unsigned int src_off,
+static void tifm_sd_copy_page(struct scatterlist *dst, unsigned int dst_off,
+ struct scatterlist *src, unsigned int src_off,
unsigned int count)
{
- unsigned char *src_buf = kmap_atomic(src) + src_off;
- unsigned char *dst_buf = kmap_atomic(dst) + dst_off;
+ unsigned char *src_buf, *dst_buf;
+
+ src_off -= src->offset;
+ dst_off -= dst->offset;
+
+ src_buf = sg_map(src, src_off, SG_KMAP_ATOMIC | SG_MAP_MUST_NOT_FAIL);
+ dst_buf = sg_map(dst, dst_off, SG_KMAP_ATOMIC | SG_MAP_MUST_NOT_FAIL);
memcpy(dst_buf, src_buf, count);
- kunmap_atomic(dst_buf - dst_off);
-
[PATCH 0/3] drm/sun4i: More cleanups and fixes
Hi Maxime, The subject is probably getting old. Here are a few more cleanups. Patch 1 should have been part of the patch drm/sun4i: Use lists to track registered display backends and TCONs from my multiple pipeline support series. Please squash it in if you can. Patch 2 just moves setting the TCON clocks back inside the TCON driver. Patch 3 cleans up a DRM driver debug message. Regards ChenYu Chen-Yu Tsai (3): drm/sun4i: Drop unused tcon pointer drm/sun4i: Set TCON clock inside sun4i_tconX_mode_set drm/sun4i: backend: Clarify sun4i_backend_layer_enable debug message drivers/gpu/drm/sun4i/sun4i_backend.c | 3 ++- drivers/gpu/drm/sun4i/sun4i_drv.h | 1 - drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 -- drivers/gpu/drm/sun4i/sun4i_tcon.c| 6 ++ drivers/gpu/drm/sun4i/sun4i_tv.c | 2 -- 5 files changed, 8 insertions(+), 6 deletions(-) -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
GPU hangs and X shot down with 4.11-rc6
Hi, I have just experienced X being shut down once with 4.11-rc2 and 2 times with 4.11-rc6 kernel. I do not remember seeing something like this before but it is quite possible I was just lucky to not trigger this issue before. It always happened while I was working on a presentation in LibreOffice which I do very seldom. The kernel log contains: [ 7456.721893] [drm] GPU HANG: ecode 9:0:0x86dd, in Xorg [3594], reason: Hang on render ring, action: reset [ 7456.721897] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 7456.721898] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [ 7456.721900] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [ 7456.721901] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [ 7456.721902] [drm] GPU crash dump saved to /sys/class/drm/card0/error [ 7456.721925] drm/i915: Resetting chip after gpu hang [ 7456.722117] [drm] RC6 on [ 7456.734588] [drm] GuC firmware load skipped [ 7464.686209] drm/i915: Resetting chip after gpu hang [ 7464.686284] [drm] RC6 on [ 7464.702469] [drm] GuC firmware load skipped [ 7472.686180] drm/i915: Resetting chip after gpu hang [ 7472.686241] [drm] RC6 on [ 7472.704565] [drm] GuC firmware load skipped [ 7480.686179] drm/i915: Resetting chip after gpu hang [ 7480.686241] [drm] RC6 on [ 7480.704583] [drm] GuC firmware load skipped [ 7493.678130] drm/i915: Resetting chip after gpu hang [ 7493.678206] [drm] RC6 on [ 7493.696505] [drm] GuC firmware load skipped The kernel message tells that the problem might be anywhere and I should report to freedesktop but I haven't changed the userspace recently so it smells more like a kernel bug to me. Does this ring bells? The GPU crash dump is attached in case it is useful. Let me know if you need additional information. Thanks! -- Michal Hocko SUSE Labs gpu_dump.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/21] scatterlist: Introduce sg_map helper functions
This patch introduces functions which kmap the pages inside an sgl.
These functions replace a common pattern of kmap(sg_page(sg)) that is
used in more than 50 places within the kernel.
The motivation for this work is to eventually safely support sgls that
contain io memory. In order for that to work, any access to the contents
of an iomem SGL will need to be done with iomemcpy or hit some warning.
(The exact details of how this will work have yet to be worked out.)
Having all the kmaps in one place is just a first step in that
direction. Additionally, seeing this helps cut down the users of sg_page,
it should make any effort to go to struct-page-less DMAs a little
easier (should that idea ever swing back into favour again).
A flags option is added to select between a regular or atomic mapping so
these functions can replace kmap(sg_page or kmap_atomic(sg_page.
Future work may expand this to have flags for using page_address or
vmap. We include a flag to require the function not to fail to
support legacy code that has no easy error path. Much further in the
future, there may be a flag to allocate memory and copy the data
from/to iomem.
We also add the semantic that sg_map can fail to create a mapping,
despite the fact that the current code this is replacing is assumed to
never fail and the current version of these functions cannot fail. This
is to support iomem which may either have to fail to create the mapping or
allocate memory as a bounce buffer which itself can fail.
Also, in terms of cleanup, a few of the existing kmap(sg_page) users
play things a bit loose in terms of whether they apply sg->offset
so using these helper functions should help avoid such issues.
Signed-off-by: Logan Gunthorpe
---
include/linux/scatterlist.h | 85 +
1 file changed, 85 insertions(+)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index cb3c8fe..fad170b 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
struct scatterlist {
@@ -126,6 +127,90 @@ static inline struct page *sg_page(struct scatterlist *sg)
return (struct page *)((sg)->page_link & ~0x3);
}
+#define SG_KMAP (1 << 0) /* create a mapping with kmap */
+#define SG_KMAP_ATOMIC (1 << 1) /* create a mapping with kmap_atomic */
+#define SG_MAP_MUST_NOT_FAIL (1 << 2) /* indicate sg_map should not fail */
+
+/**
+ * sg_map - kmap a page inside an sgl
+ * @sg:SG entry
+ * @offset:Offset into entry
+ * @flags: Flags for creating the mapping
+ *
+ * Description:
+ * Use this function to map a page in the scatterlist at the specified
+ * offset. sg->offset is already added for you. Note: the semantics of
+ * this function are that it may fail. Thus, its output should be checked
+ * with IS_ERR and PTR_ERR. Otherwise, a pointer to the specified offset
+ * in the mapped page is returned.
+ *
+ * Flags can be any of:
+ * * SG_KMAP - Use kmap to create the mapping
+ * * SG_KMAP_ATOMIC- Use kmap_atomic to map the page atommically.
+ * Thus, the rules of that function apply: the
+ * cpu may not sleep until it is unmaped.
+ * * SG_MAP_MUST_NOT_FAIL - Indicate that sg_map must not fail.
+ * If it does, it will issue a BUG_ON instead.
+ * This is intended for legacy code only, it
+ * is not to be used in new code.
+ *
+ * Also, consider carefully whether this function is appropriate. It is
+ * largely not recommended for new code and if the sgl came from another
+ * subsystem and you don't know what kind of memory might be in the list
+ * then you definitely should not call it. Non-mappable memory may be in
+ * the sgl and thus this function may fail unexpectedly. Consider using
+ * sg_copy_to_buffer instead.
+ **/
+static inline void *sg_map(struct scatterlist *sg, size_t offset, int flags)
+{
+ struct page *pg;
+ unsigned int pg_off;
+ void *ret;
+
+ offset += sg->offset;
+ pg = nth_page(sg_page(sg), offset >> PAGE_SHIFT);
+ pg_off = offset_in_page(offset);
+
+ if (flags & SG_KMAP_ATOMIC)
+ ret = kmap_atomic(pg) + pg_off;
+ else if (flags & SG_KMAP)
+ ret = kmap(pg) + pg_off;
+ else
+ ret = ERR_PTR(-EINVAL);
+
+ /*
+* In theory, this can't happen yet. Once we start adding
+* unmapable memory, it also shouldn't happen unless developers
+* start putting unmappable struct pages in sgls and passing
+* it to code that doesn't support it.
+*/
+ BUG_ON(flags & SG_MAP_MUST_NOT_FAIL && IS_ERR(ret));
+
+ return ret;
+}
+
+/**
+ * sg_unmap - unmap a page that was mapped with sg_map_offset
+ * @sg:
[PATCH v2 13/21] scsi: arcmsr, ips, megaraid: Make use of the new sg_map helper function
Very straightforward conversion of three scsi drivers
Signed-off-by: Logan Gunthorpe
Cc: Adaptec OEM Raid Solutions
Cc: Kashyap Desai
Cc: Sumit Saxena
Cc: Shivasharan S
---
drivers/scsi/arcmsr/arcmsr_hba.c | 16
drivers/scsi/ips.c | 8
drivers/scsi/megaraid.c | 9 +++--
3 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index af032c4..8c2de17 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -2306,7 +2306,10 @@ static int arcmsr_iop_message_xfer(struct
AdapterControlBlock *acb,
use_sg = scsi_sg_count(cmd);
sg = scsi_sglist(cmd);
- buffer = kmap_atomic(sg_page(sg)) + sg->offset;
+ buffer = sg_map(sg, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(buffer))
+ return ARCMSR_MESSAGE_FAIL;
+
if (use_sg > 1) {
retvalue = ARCMSR_MESSAGE_FAIL;
goto message_out;
@@ -2539,7 +2542,7 @@ static int arcmsr_iop_message_xfer(struct
AdapterControlBlock *acb,
message_out:
if (use_sg) {
struct scatterlist *sg = scsi_sglist(cmd);
- kunmap_atomic(buffer - sg->offset);
+ sg_unmap(sg, buffer, 0, SG_KMAP_ATOMIC);
}
return retvalue;
}
@@ -2590,11 +2593,16 @@ static void arcmsr_handle_virtual_command(struct
AdapterControlBlock *acb,
strncpy(&inqdata[32], "R001", 4); /* Product Revision */
sg = scsi_sglist(cmd);
- buffer = kmap_atomic(sg_page(sg)) + sg->offset;
+ buffer = sg_map(sg, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(buffer)) {
+ cmd->result = (DID_ERROR << 16);
+ cmd->scsi_done(cmd);
+ return;
+ }
memcpy(buffer, inqdata, sizeof(inqdata));
sg = scsi_sglist(cmd);
- kunmap_atomic(buffer - sg->offset);
+ sg_unmap(sg, buffer, 0, SG_KMAP_ATOMIC);
cmd->scsi_done(cmd);
}
diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
index 3419e1b..6e91729 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -1506,14 +1506,14 @@ static int ips_is_passthru(struct scsi_cmnd *SC)
/* kmap_atomic() ensures addressability of the user buffer.*/
/* local_irq_save() protects the KM_IRQ0 address slot. */
local_irq_save(flags);
-buffer = kmap_atomic(sg_page(sg)) + sg->offset;
-if (buffer && buffer[0] == 'C' && buffer[1] == 'O' &&
+buffer = sg_map(sg, 0, SG_KMAP_ATOMIC);
+if (!IS_ERR(buffer) && buffer[0] == 'C' && buffer[1] == 'O' &&
buffer[2] == 'P' && buffer[3] == 'P') {
-kunmap_atomic(buffer - sg->offset);
+sg_unmap(sg, buffer, 0, SG_KMAP_ATOMIC);
local_irq_restore(flags);
return 1;
}
-kunmap_atomic(buffer - sg->offset);
+sg_unmap(sg, buffer, 0, SG_KMAP_ATOMIC);
local_irq_restore(flags);
}
return 0;
diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c
index 3c63c29..f8aee59 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -663,10 +663,15 @@ mega_build_cmd(adapter_t *adapter, Scsi_Cmnd *cmd, int
*busy)
struct scatterlist *sg;
sg = scsi_sglist(cmd);
- buf = kmap_atomic(sg_page(sg)) + sg->offset;
+ buf = sg_map(sg, 0, SG_KMAP_ATOMIC);
+ if (IS_ERR(buf)) {
+cmd->result = (DID_ERROR << 16);
+ cmd->scsi_done(cmd);
+ return NULL;
+ }
memset(buf, 0, cmd->cmnd[4]);
- kunmap_atomic(buf - sg->offset);
+ sg_unmap(sg, buf, 0, SG_KMAP_ATOMIC);
cmd->result = (DID_OK << 16);
cmd->scsi_done(cmd);
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100781] "Black Mesa" will not Launch
https://bugs.freedesktop.org/show_bug.cgi?id=100781 Michel Dänzer changed: What|Removed |Added Resolution|FIXED |NOTOURBUG -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 195581] NULL pointer dereference when amdgpu driver calls drm_load_edid_firmware
https://bugzilla.kernel.org/show_bug.cgi?id=195581 --- Comment #1 from Michel Dänzer (mic...@daenzer.net) --- Looks like https://bugs.freedesktop.org/show_bug.cgi?id=100375 . Is this a regression from older kernel versions? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: avoid scheduling on fence status query
When a timeout of zero is specified, the caller is only interested in
the fence status.
In the current implementation, dma_fence_default_wait will always call
schedule_timeout() at least once for an unsignaled fence. This adds a
significant overhead to a fence status query.
Avoid this overhead by returning early if a zero timeout is specified.
Signed-off-by: Andres Rodriguez
---
This heavily affects the performance of the Source2 engine running on
radv.
This patch improves dota2(radv) perf on a i7-6700k+RX480 system from
72fps->81fps.
drivers/dma-buf/dma-fence.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 0918d3f..348e9e2 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -380,6 +380,9 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr,
signed long timeout)
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
return ret;
+ if (!timeout)
+ return 0;
+
spin_lock_irqsave(fence->lock, flags);
if (intr && signal_pending(current)) {
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/6] drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format
On 25/04/17 06:52 PM, Ville Syrjälä wrote:
> On Tue, Apr 25, 2017 at 12:18:52PM +0900, Michel Dänzer wrote:
>> On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
>>> +#ifdef __BIG_ENDIAN
>>> + switch (bpp) {
>>> + case 8:
>>> + fmt = DRM_FORMAT_C8;
>>> + break;
>>> + case 24:
>>> + fmt = DRM_FORMAT_BGR888;
>>> + break;
>>
>> BTW, endianness as a concept cannot apply to 8 or 24 bpp formats.
>
> To 8bpp no, but it can easily apply to 24bpp.
Any byte swapping rips apart the bytes of a 24bpp pixel, so those
formats only make sense as straight array formats.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On 25/04/17 07:26 PM, Ville Syrjälä wrote: > On Tue, Apr 25, 2017 at 10:12:37AM +0900, Michel Dänzer wrote: >> On 24/04/17 10:03 PM, Ville Syrjälä wrote: >>> On Mon, Apr 24, 2017 at 03:57:02PM +0900, Michel Dänzer wrote: On 22/04/17 07:05 PM, Ville Syrjälä wrote: > On Fri, Apr 21, 2017 at 06:14:31PM +0200, Gerd Hoffmann wrote: >> Hi, >> My personal opinion is that formats in drm_fourcc.h should be independent of the CPU byte order and the function drm_mode_legacy_fb_format() and drivers depending on that incorrect assumption be fixed instead. >>> >>> The problem is this isn't a kernel-internal thing any more. With the >>> addition of the ADDFB2 ioctl the fourcc codes became part of the >>> kernel/userspace abi ... >> >> Ok, added some printk's to the ADDFB and ADDFB2 code paths and tested a >> bit. Apparently pretty much all userspace still uses the ADDFB ioctl. >> xorg (modesetting driver) does. gnome-shell in wayland mode does. >> Seems the big transition to ADDFB2 didn't happen yet. >> >> I guess that makes changing drm_mode_legacy_fb_format + drivers a >> reasonable option ... > > Yeah, I came to the same conclusion after chatting with some > folks on irc. > > So my current idea is that we change any driver that wants to follow the > CPU endianness This isn't really optional for various reasons, some of which have been covered in this discussion. > to declare support for big endian formats if the CPU is > big endian. Presumably these are mostly the virtual GPU drivers. > > Additonally we'll make the mapping performed by > drm_mode_legacy_fb_format() > driver controlled. That way drivers that got changed to follow CPU > endianness can return a framebuffer that matches CPU endianness. And > drivers that expect the GPU endianness to not depend on the CPU > endianness will keep working as they do now. The downside is that users > of the legacy addfb ioctl will need to magically know which endianness > they will get, but that is apparently already the case. And users of > addfb2 will keep on specifying the endianness explicitly with > DRM_FORMAT_BIG_ENDIAN vs. 0. I'm afraid it's not that simple. The display hardware of older (pre-R600 generation) Radeon GPUs does not support the "big endian" formats directly. In order to allow userspace to access pixel data in native endianness with the CPU, we instead use byte-swapping functionality which only affects CPU access. >>> >>> OK, I'm getting confused. Based on our irc discussion I got the >>> impression you don't byte swap CPU accesses. >> >> Sorry for the confusion. The radeon kernel driver does support >> byte-swapping for CPU access to VRAM with pre-R600 GPUs, and this is >> used for fbdev emulation. What I meant on IRC is that the xf86-video-ati >> radeon driver doesn't make use of this, mostly because it only applies >> while a BO is in VRAM, and userspace can't control when that's the case >> (while a BO isn't being scanned out). > > So that was my other question. So if someone just creates a bo, I presume > ttm can more or less move it between system memory and vram at any > time. So if we then mmap the bo, does it mean the CPU will see the bytes > in different order depending on where the bo happens to live at > the time the CPU access happens? If either of the RADEON_TILING_SWAP_16/32BIT flags was set when the BO was created, yes. That's why the xf86-video-ati radeon driver doesn't use this functionality. > And how would that work wih dumb bos? radeon_mode_dumb_create doesn't set the RADEON_TILING_SWAP_16/32BIT flags, so no byte swapping is performed for dumb BOs even in VRAM. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: avoid scheduling on fence status query
CC a few extra lists I missed.
Regards,
Andres
On 2017-04-25 09:36 PM, Andres Rodriguez wrote:
When a timeout of zero is specified, the caller is only interested in
the fence status.
In the current implementation, dma_fence_default_wait will always call
schedule_timeout() at least once for an unsignaled fence. This adds a
significant overhead to a fence status query.
Avoid this overhead by returning early if a zero timeout is specified.
Signed-off-by: Andres Rodriguez
---
This heavily affects the performance of the Source2 engine running on
radv.
This patch improves dota2(radv) perf on a i7-6700k+RX480 system from
72fps->81fps.
drivers/dma-buf/dma-fence.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 0918d3f..348e9e2 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -380,6 +380,9 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr,
signed long timeout)
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
return ret;
+ if (!timeout)
+ return 0;
+
spin_lock_irqsave(fence->lock, flags);
if (intr && signal_pending(current)) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] amdgpu/cs: split out fence dependency checking
From: Dave Airlie
This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.
Reviewed-by: Christian König
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 85 +++---
1 file changed, 47 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 99424cb..df25b32 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -963,56 +963,65 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device *adev,
return 0;
}
-static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
- struct amdgpu_cs_parser *p)
+static int amdgpu_process_fence_dep(struct amdgpu_cs_parser *p,
+ struct amdgpu_cs_chunk *chunk)
{
struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
- int i, j, r;
-
- for (i = 0; i < p->nchunks; ++i) {
- struct drm_amdgpu_cs_chunk_dep *deps;
- struct amdgpu_cs_chunk *chunk;
- unsigned num_deps;
+ unsigned num_deps;
+ int i, r;
+ struct drm_amdgpu_cs_chunk_dep *deps;
- chunk = &p->chunks[i];
+ deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata;
+ num_deps = chunk->length_dw * 4 /
+ sizeof(struct drm_amdgpu_cs_chunk_dep);
- if (chunk->chunk_id != AMDGPU_CHUNK_ID_DEPENDENCIES)
- continue;
+ for (i = 0; i < num_deps; ++i) {
+ struct amdgpu_ring *ring;
+ struct amdgpu_ctx *ctx;
+ struct dma_fence *fence;
- deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata;
- num_deps = chunk->length_dw * 4 /
- sizeof(struct drm_amdgpu_cs_chunk_dep);
+ r = amdgpu_cs_get_ring(p->adev, deps[i].ip_type,
+ deps[i].ip_instance,
+ deps[i].ring, &ring);
+ if (r)
+ return r;
- for (j = 0; j < num_deps; ++j) {
- struct amdgpu_ring *ring;
- struct amdgpu_ctx *ctx;
- struct dma_fence *fence;
+ ctx = amdgpu_ctx_get(fpriv, deps[i].ctx_id);
+ if (ctx == NULL)
+ return -EINVAL;
- r = amdgpu_cs_get_ring(adev, deps[j].ip_type,
- deps[j].ip_instance,
- deps[j].ring, &ring);
+ fence = amdgpu_ctx_get_fence(ctx, ring,
+deps[i].handle);
+ if (IS_ERR(fence)) {
+ r = PTR_ERR(fence);
+ amdgpu_ctx_put(ctx);
+ return r;
+ } else if (fence) {
+ r = amdgpu_sync_fence(p->adev, &p->job->sync,
+ fence);
+ dma_fence_put(fence);
+ amdgpu_ctx_put(ctx);
if (r)
return r;
+ }
+ }
+ return 0;
+}
- ctx = amdgpu_ctx_get(fpriv, deps[j].ctx_id);
- if (ctx == NULL)
- return -EINVAL;
+static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
+ struct amdgpu_cs_parser *p)
+{
+ int i, r;
- fence = amdgpu_ctx_get_fence(ctx, ring,
-deps[j].handle);
- if (IS_ERR(fence)) {
- r = PTR_ERR(fence);
- amdgpu_ctx_put(ctx);
- return r;
+ for (i = 0; i < p->nchunks; ++i) {
+ struct amdgpu_cs_chunk *chunk;
- } else if (fence) {
- r = amdgpu_sync_fence(adev, &p->job->sync,
- fence);
- dma_fence_put(fence);
- amdgpu_ctx_put(ctx);
- if (r)
- return r;
- }
+ chunk = &p->chunks[i];
+
+ if (chunk->chunk_id == AMDGPU_CHUNK_ID_DEPENDENCIES) {
+ r = amdgpu_process_fence_dep(p, chunk);
+ if (r)
+ return r;
}
}
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/syncobj: add sync_file interaction.
From: Dave Airlie
This interface allows importing the fence from a sync_file into
an existing drm sync object, or exporting the fence attached to
an existing drm sync object into a new sync file object.
This should only be used to interact with sync files where necessary.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_syncobj.c | 56 +++
include/uapi/drm/drm.h| 6 +++--
2 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index c24fea0..89bf120 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#include "drm_internal.h"
#include
@@ -279,6 +280,48 @@ static int drm_syncobj_fd_to_handle(struct drm_file
*file_private,
return 0;
}
+int drm_syncobj_import_sync_file_fence(struct drm_file *file_private,
+ int fd, int handle)
+{
+ struct dma_fence *fence = sync_file_get_fence(fd);
+ if (!fence)
+ return -EINVAL;
+
+ return drm_syncobj_replace_fence(file_private, handle, fence);
+}
+
+int drm_syncobj_export_sync_file(struct drm_file *file_private,
+int handle, int *p_fd)
+{
+ int ret;
+ struct dma_fence *fence;
+ struct sync_file *sync_file;
+ int fd = get_unused_fd_flags(O_CLOEXEC);
+
+ if (fd < 0)
+ return fd;
+
+ ret = drm_syncobj_fence_get(file_private, handle, &fence);
+ if (ret)
+ goto err_put_fd;
+
+ sync_file = sync_file_create(fence);
+ if (!sync_file) {
+ ret = -EINVAL;
+ goto err_fence_put;
+ }
+
+ fd_install(fd, sync_file->file);
+
+ dma_fence_put(fence);
+ *p_fd = fd;
+ return 0;
+err_fence_put:
+ dma_fence_put(fence);
+err_put_fd:
+ put_unused_fd(fd);
+ return ret;
+}
/**
* drm_syncobj_open - initalizes syncobj file-private structures at devnode
open time
* @dev: drm_device which is being opened by userspace
@@ -361,6 +404,12 @@ drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev,
void *data,
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
return -ENODEV;
+ if (args->flags & DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_FENCE_SYNC_FILE)
+ return drm_syncobj_export_sync_file(file_private, args->handle,
+ &args->fd);
+ else if (args->flags)
+ return -EINVAL;
+
return drm_syncobj_handle_to_fd(file_private, args->handle,
&args->fd);
}
@@ -374,6 +423,13 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev,
void *data,
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
return -ENODEV;
+ if (args->flags & DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE_FENCE)
+ return drm_syncobj_import_sync_file_fence(file_private,
+ args->fd,
+ args->handle);
+ else if (args->flags)
+ return -EINVAL;
+
return drm_syncobj_fd_to_handle(file_private, args->fd,
&args->handle);
}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 7c508d0..a06d370 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -707,13 +707,15 @@ struct drm_syncobj_destroy {
__u32 pad;
};
+#define DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE_FENCE (1 << 0)
+#define DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_FENCE_SYNC_FILE (1 << 0)
struct drm_syncobj_handle {
__u32 handle;
/** Flags.. only applicable for handle->fd */
- __u32 flags;
+ __u32 fd_flags;
__s32 fd;
- __u32 pad;
+ __u32 flags;
};
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/syncobj: add sync obj wait interface.
From: Dave Airlie
This interface will allow sync object to be used to back
Vulkan fences. This API is pretty much the vulkan fence waiting
API, and I've ported the code from amdgpu.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 162 -
include/uapi/drm/drm.h | 11 +++
4 files changed, 176 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 44ef903..a508ad9 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -156,3 +156,5 @@ int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_private);
int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 6da7adc..b142466 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -653,6 +653,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE,
drm_syncobj_fd_to_handle_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
};
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e6a99d4..c24fea0 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1,5 +1,7 @@
/*
* Copyright 2017 Red Hat
+ * Parts ported from amdgpu (fence wait code).
+ * Copyright 2016 Advanced Micro Devices, Inc.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -31,10 +33,13 @@
* that contain an optional fence. The fence can be updated with a new
* fence, or be NULL.
*
+ * syncobj's can be waited upon, where it will wait for the underlying
+ * fence.
+ *
* syncobj's can be export to fd's and back, these fd's are opaque and
* have no other use case, except passing the syncobj between processes.
*
- * TODO: sync_file interactions, waiting
+ * TODO: sync_file interactions.
*
* Their primary use-case is to implement Vulkan fences and semaphores.
*
@@ -372,3 +377,158 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev,
void *data,
return drm_syncobj_fd_to_handle(file_private, args->fd,
&args->handle);
}
+
+/**
+ * calc_timeout - calculate jiffies timeout from absolute value
+ *
+ * @timeout_ns: timeout in ns
+ *
+ * Calculate the timeout in jiffies from an absolute timeout in ns.
+ */
+unsigned long calc_wait_timeout(uint64_t timeout_ns)
+{
+unsigned long timeout_jiffies;
+ktime_t timeout;
+
+/* clamp timeout if it's to large */
+if (((int64_t)timeout_ns) < 0)
+return MAX_SCHEDULE_TIMEOUT;
+
+timeout = ktime_sub(ns_to_ktime(timeout_ns), ktime_get());
+if (ktime_to_ns(timeout) < 0)
+return 0;
+
+timeout_jiffies = nsecs_to_jiffies(ktime_to_ns(timeout));
+/* clamp timeout to avoid unsigned-> signed overflow */
+if (timeout_jiffies > MAX_SCHEDULE_TIMEOUT )
+return MAX_SCHEDULE_TIMEOUT - 1;
+
+return timeout_jiffies;
+}
+
+static int drm_syncobj_wait_all_fences(struct drm_device *dev,
+ struct drm_file *file_private,
+ struct drm_syncobj_wait *wait,
+ uint32_t *handles)
+{
+ uint32_t i;
+ int ret;
+
+ for (i = 0; i < wait->count_handles; i++) {
+ unsigned long timeout = calc_wait_timeout(wait->timeout_ns);
+ struct dma_fence *fence;
+
+ ret = drm_syncobj_fence_get(file_private, handles[i],
+ &fence);
+ if (ret)
+ return ret;
+
+ if (!fence)
+ continue;
+
+ ret = dma_fence_wait_timeout(fence, true, timeout);
+
+ dma_fence_put(fence);
+ if (ret < 0)
+ return ret;
+ if (ret == 0)
+ break;
+ }
+
+ wait->out_status = (ret > 0);
+ wait->first_signaled = 0;
+ return 0;
+}
+
+static int drm_syncobj_wait_any_fence(struct drm_device *dev,
+ struct drm_file *file_private,
+ stru
[PATCH 1/5] drm: introduce sync objects
From: Dave Airlie
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.
There is also a generic wait obj API modelled on the vulkan
wait API (with code modelled on some amdgpu code).
These objects can be converted to an opaque fd that can be
passes between processes.
TODO: define sync_file interaction.
Signed-off-by: Dave Airlie
---
Documentation/gpu/drm-internals.rst | 3 +
Documentation/gpu/drm-mm.rst| 6 +
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_fops.c | 8 +
drivers/gpu/drm/drm_internal.h | 13 ++
drivers/gpu/drm/drm_ioctl.c | 12 ++
drivers/gpu/drm/drm_syncobj.c | 374
include/drm/drmP.h | 5 +
include/drm/drm_drv.h | 1 +
include/drm/drm_syncobj.h | 104 ++
include/uapi/drm/drm.h | 25 +++
11 files changed, 552 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_syncobj.c
create mode 100644 include/drm/drm_syncobj.h
diff --git a/Documentation/gpu/drm-internals.rst
b/Documentation/gpu/drm-internals.rst
index e35920d..2ea3bce 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -98,6 +98,9 @@ DRIVER_ATOMIC
implement appropriate obj->atomic_get_property() vfuncs for any
modeset objects with driver specific properties.
+DRIVER_SYNCOBJ
+Driver support drm sync objects.
+
Major, Minor and Patchlevel
~~~
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index f5760b1..28aebe8 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -483,3 +483,9 @@ DRM Cache Handling
.. kernel-doc:: drivers/gpu/drm/drm_cache.c
:export:
+
+DRM Sync Objects
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
+ :export:
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 3ee9579..b5e565c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -16,7 +16,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
- drm_dumb_buffers.o drm_mode_config.o
+ drm_dumb_buffers.o drm_mode_config.o drm_syncobj.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index afdf5b1..9a61df2 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -219,6 +219,9 @@ static int drm_open_helper(struct file *filp, struct
drm_minor *minor)
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_open(dev, priv);
+ if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ drm_syncobj_open(priv);
+
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_prime_init_file_private(&priv->prime);
@@ -266,6 +269,8 @@ static int drm_open_helper(struct file *filp, struct
drm_minor *minor)
out_prime_destroy:
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_prime_destroy_file_private(&priv->prime);
+ if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ drm_syncobj_release(priv);
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_release(dev, priv);
put_pid(priv->pid);
@@ -400,6 +405,9 @@ int drm_release(struct inode *inode, struct file *filp)
drm_property_destroy_user_blobs(dev, file_priv);
}
+ if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ drm_syncobj_release(file_priv);
+
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_release(dev, file_priv);
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index f37388c..44ef903 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -142,4 +142,17 @@ static inline int drm_debugfs_crtc_crc_add(struct drm_crtc
*crtc)
{
return 0;
}
+
#endif
+
+/* drm_syncobj.c */
+void drm_syncobj_open(struct drm_file *file_private);
+void drm_syncobj_release(struct drm_file *file_private);
+int drm_syncobj_create_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_private);
+int drm_syncobj_destroy_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
+int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
+int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
diff --git a/drivers/gpu/drm
[rfc] drm sync objects (search for spock)
Okay I've gone around the sun with these a few times, and pretty much implemented what I said last week. This is pretty much a complete revamp. 1. sync objects are self contained drm objects, they have a file reference so can be passed between processes. 2. Added a sync object wait interface modelled on the vulkan fence waiting API. 3. sync_file interaction is explicitly different than opaque fd passing, you import a sync file state into an existing syncobj, or create a new sync_file from an existing syncobj. This means no touching the sync file code at all. \o/ I haven't used rcu anywhere here, I've used xchg to swap fence pointers in the hope that's safe. If this does need rcu'ing I suggest we do it in a follow on patch to minimise the review pain. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v4)
From: Dave Airlie
This creates a new command submission chunk for amdgpu
to add in and out sync objects around the submission.
Sync objects are managed via the drm syncobj ioctls.
The command submission interface is enhanced with two new
chunks, one for syncobj pre submission dependencies,
and one for post submission sync obj signalling,
and just takes a list of handles for each.
This is based on work originally done by David Zhou at AMD,
with input from Christian Konig on what things should look like.
In theory VkFences could be backed with sync objects and
just get passed into the cs as syncobj handles as well.
NOTE: this interface addition needs a version bump to expose
it to userspace.
v1.1: keep file reference on import.
v2: move to using syncobjs
v2.1: change some APIs to just use p pointer.
v3: make more robust against CS failures, we now add the
wait sems but only remove them once the CS job has been
submitted.
v4: rewrite names of API and base on new syncobj code.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 81 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
include/uapi/drm/amdgpu_drm.h | 6 +++
3 files changed, 87 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index df25b32..e86c832 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "amdgpu.h"
#include "amdgpu_trace.h"
@@ -217,6 +218,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void
*data)
break;
case AMDGPU_CHUNK_ID_DEPENDENCIES:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:
break;
default:
@@ -1008,6 +1011,40 @@ static int amdgpu_process_fence_dep(struct
amdgpu_cs_parser *p,
return 0;
}
+static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
+uint32_t handle)
+{
+ int r;
+ struct dma_fence *fence;
+ r = drm_syncobj_fence_get(p->filp, handle, &fence);
+ if (r)
+ return r;
+
+ r = amdgpu_sync_fence(p->adev, &p->job->sync, fence);
+ dma_fence_put(fence);
+
+ return r;
+}
+
+static int amdgpu_process_syncobj_in_dep(struct amdgpu_cs_parser *p,
+struct amdgpu_cs_chunk *chunk)
+{
+ unsigned num_deps;
+ int i, r;
+ struct drm_amdgpu_cs_chunk_sem *deps;
+
+ deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+ num_deps = chunk->length_dw * 4 /
+ sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+ for (i = 0; i < num_deps; ++i) {
+ r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle);
+ if (r)
+ return r;
+ }
+ return 0;
+}
+
static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
struct amdgpu_cs_parser *p)
{
@@ -1022,12 +1059,54 @@ static int amdgpu_cs_dependencies(struct amdgpu_device
*adev,
r = amdgpu_process_fence_dep(p, chunk);
if (r)
return r;
+ } else if (chunk->chunk_id == AMDGPU_CHUNK_ID_SYNCOBJ_IN) {
+ r = amdgpu_process_syncobj_in_dep(p, chunk);
+ if (r)
+ return r;
}
}
return 0;
}
+static int amdgpu_process_syncobj_out_dep(struct amdgpu_cs_parser *p,
+ struct amdgpu_cs_chunk *chunk)
+{
+ unsigned num_deps;
+ int i, r;
+ struct drm_amdgpu_cs_chunk_sem *deps;
+
+ deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+ num_deps = chunk->length_dw * 4 /
+ sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+ for (i = 0; i < num_deps; ++i) {
+ r = drm_syncobj_replace_fence(p->filp, deps[i].handle,
+ p->fence);
+ if (r)
+ return r;
+ }
+ return 0;
+}
+
+static int amdgpu_cs_post_dependencies(struct amdgpu_cs_parser *p)
+{
+ int i, r;
+
+ for (i = 0; i < p->nchunks; ++i) {
+ struct amdgpu_cs_chunk *chunk;
+
+ chunk = &p->chunks[i];
+
+ if (chunk->chunk_id == AMDGPU_CHUNK_ID_SYNCOBJ_OUT) {
+ r = amdgpu_process_syncobj_out_dep(p, chunk);
+ if (r)
+ return r;
+ }
+ }
+ return 0;
+}
+
static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
union drm_amdgpu_cs *cs)
{
@@ -1055,7 +1134,7 @@ static int amdgpu_cs_submit(struct amdgpu
Re: [PATCH 3/6] drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format
On Di, 2017-04-25 at 12:18 +0900, Michel Dänzer wrote:
> On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
> > Return correct fourcc codes on bigendian. Drivers must be adapted to
> > this change.
> >
> > Signed-off-by: Gerd Hoffmann
>
> Just to reiterate, this won't work for the radeon driver, which programs
> the GPU to use (effectively, per the current definition that these are
> little endian GPU formats) DRM_FORMAT_XRGB with pre-R600 and
> DRM_FORMAT_BGRX with >= R600.
Hmm, ok, how does bigendian fbdev emulation work on pre-R600 then?
> > +#ifdef __BIG_ENDIAN
> > + switch (bpp) {
> > + case 8:
> > + fmt = DRM_FORMAT_C8;
> > + break;
> > + case 24:
> > + fmt = DRM_FORMAT_BGR888;
> > + break;
>
> BTW, endianness as a concept cannot apply to 8 or 24 bpp formats.
I could move the 8 bpp case out of the #ifdef somehow, but code
readability will suffer then I think ...
For 24 we have different byte orderings, but yes, you can't switch from
one to the other with byteswapping. Probably one of the reasons why
this format is pretty much out of fashion these days ...
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/sun4i: More cleanups and fixes
On Tue, Apr 25, 2017 at 11:25:02PM +0800, Chen-Yu Tsai wrote: > Hi Maxime, > > The subject is probably getting old. Here are a few more cleanups. > > Patch 1 should have been part of the patch > > drm/sun4i: Use lists to track registered display backends and TCONs > > from my multiple pipeline support series. Please squash it in if you can. > > Patch 2 just moves setting the TCON clocks back inside the TCON driver. > > Patch 3 cleans up a DRM driver debug message. Applied all, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 13/15] drm/sun4i: Add HDMI support
Hi Chen-Yu,
On Fri, Apr 21, 2017 at 11:17:17PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard
> wrote:
> > The earlier Allwinner SoCs (A10, A10s, A20, A31) have an embedded HDMI
> > controller.
> >
> > That HDMI controller is able to do audio and CEC, but those have been left
> > out for now.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/sun4i/Makefile | 5 +-
> > drivers/gpu/drm/sun4i/sun4i_hdmi.h | 124 ++-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 128 ++-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 449 +-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 236 +++-
> > 5 files changed, 942 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi.h
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>
> Applying patch #9608371 using 'git am'
> Description: [13/15] drm/sun4i: Add HDMI support
> Applying: drm/sun4i: Add HDMI support
> .git/rebase-apply/patch:116: trailing whitespace.
>
> .git/rebase-apply/patch:531: trailing whitespace.
>
> .git/rebase-apply/patch:701: trailing whitespace.
>
> warning: 3 lines add whitespace errors.
Fixed.
> > +int sun4i_ddc_create(struct sun4i_hdmi *hdmi, struct clk *parent)
> > +{
> > + struct clk_init_data init;
> > + struct sun4i_ddc *ddc;
> > + const char *parent_name;
> > +
> > + parent_name = __clk_get_name(parent);
> > + if (!parent_name)
> > + return -ENODEV;
> > +
> > + ddc = devm_kzalloc(hdmi->dev, sizeof(*ddc), GFP_KERNEL);
> > + if (!ddc)
> > + return -ENOMEM;
> > +
> > + init.name = "hdmi-ddc";
> > + init.ops = &sun4i_ddc_ops;
> > + init.parent_names = &parent_name;
> > + init.num_parents = 1;
> > + init.flags = CLK_SET_RATE_PARENT;
>
> I don't think this is really needed. It probably doesn't hurt though,
> since DDC is used when HDMI is not used for displaying, but it might
> affect any upstream PLLs, which theoretically may affect other users
> of said PLLs. The DDC clock is slow enough that we should be able to
> generate a usable clock rate anyway.
Good point, I removed it.
> > + writel(SUN4I_HDMI_VID_TIMING_X(mode->hdisplay) |
> > + SUN4I_HDMI_VID_TIMING_Y(mode->vdisplay),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_ACT_REG);
> > +
> > + x = mode->htotal - mode->hsync_start;
> > + y = mode->vtotal - mode->vsync_start;
>
> I'm a bit skeptical about this one. All the other parameters are not
> inclusive of other, why would this one be different? Shouldn't it
> be "Xtotal - Xsync_end" instead?
By the usual meaning of backporch, you're right. However, Allwinner's
seems to have it's own, which is actually the backporch + sync length.
We also have that on all the other connectors (and TCON), and this was
confirmed at the time using a scope on an RGB signal.
>
> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_BP_REG);
> > +
> > + x = mode->hsync_start - mode->hdisplay;
> > + y = mode->vsync_start - mode->vdisplay;
> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_FP_REG);
> > +
> > + x = mode->hsync_end - mode->hsync_start;
> > + y = mode->vsync_end - mode->vsync_start;
> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_SPW_REG);
> > +
> > + val = SUN4I_HDMI_VID_TIMING_POL_TX_CLK;
> > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > + val |= SUN4I_HDMI_VID_TIMING_POL_HSYNC;
> > +
> > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > + val |= SUN4I_HDMI_VID_TIMING_POL_VSYNC;
> > +
> > + writel(val, hdmi->base + SUN4I_HDMI_VID_TIMING_POL_REG);
>
> You don't handle the interlaced video here, even though you set
>
> hdmi->connector.interlace_allowed = true
>
> later.
I'll fix that.
> The double clock and double scan flags aren't handled either, though
> I don't understand which one is supposed to represent the need for the
> HDMI pixel repeater. AFAIK this is required for resolutions with pixel
> clocks lower than 25 MHz, the lower limit of HDMI's TMDS link.
I'm not sure about this one though. I'd like to keep things quite
simple for now and build up on that once the basis is working. Is it
common in the wild?
> > + hdmi->base + SUN4I_HDMI_DDC_FIFO_CTRL_REG);
> > + writel(SUN4I_HDMI_DDC_ADDR_SEGMENT(offset >> 8) |
> > + SUN4I_HDMI_DDC_ADDR_EDDC(0x60) |
> > + SUN4I_HDMI_DDC_ADDR_OFFSET(offset) |
> > + SUN4I_HDMI_DDC_ADDR_SLAVE(0x50),
>
>
Re: [PATCH 1/5] drm: introduce sync objects
On 2017年04月26日 11:28, Dave Airlie wrote:
From: Dave Airlie
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.
There is also a generic wait obj API modelled on the vulkan
wait API (with code modelled on some amdgpu code).
These objects can be converted to an opaque fd that can be
passes between processes.
TODO: define sync_file interaction.
Signed-off-by: Dave Airlie
---
Documentation/gpu/drm-internals.rst | 3 +
Documentation/gpu/drm-mm.rst| 6 +
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_fops.c | 8 +
drivers/gpu/drm/drm_internal.h | 13 ++
drivers/gpu/drm/drm_ioctl.c | 12 ++
drivers/gpu/drm/drm_syncobj.c | 374
include/drm/drmP.h | 5 +
include/drm/drm_drv.h | 1 +
include/drm/drm_syncobj.h | 104 ++
include/uapi/drm/drm.h | 25 +++
11 files changed, 552 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_syncobj.c
create mode 100644 include/drm/drm_syncobj.h
diff --git a/Documentation/gpu/drm-internals.rst
b/Documentation/gpu/drm-internals.rst
index e35920d..2ea3bce 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -98,6 +98,9 @@ DRIVER_ATOMIC
implement appropriate obj->atomic_get_property() vfuncs for any
modeset objects with driver specific properties.
+DRIVER_SYNCOBJ
+Driver support drm sync objects.
+
Major, Minor and Patchlevel
~~~
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index f5760b1..28aebe8 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -483,3 +483,9 @@ DRM Cache Handling
.. kernel-doc:: drivers/gpu/drm/drm_cache.c
:export:
+
+DRM Sync Objects
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
+ :export:
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 3ee9579..b5e565c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -16,7 +16,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
- drm_dumb_buffers.o drm_mode_config.o
+ drm_dumb_buffers.o drm_mode_config.o drm_syncobj.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index afdf5b1..9a61df2 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -219,6 +219,9 @@ static int drm_open_helper(struct file *filp, struct
drm_minor *minor)
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_open(dev, priv);
+ if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ drm_syncobj_open(priv);
+
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_prime_init_file_private(&priv->prime);
@@ -266,6 +269,8 @@ static int drm_open_helper(struct file *filp, struct drm_minor *minor)
out_prime_destroy:
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_prime_destroy_file_private(&priv->prime);
+ if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ drm_syncobj_release(priv);
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_release(dev, priv);
put_pid(priv->pid);
@@ -400,6 +405,9 @@ int drm_release(struct inode *inode, struct file *filp)
drm_property_destroy_user_blobs(dev, file_priv);
}
+ if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ drm_syncobj_release(file_priv);
+
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_release(dev, file_priv);
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index f37388c..44ef903 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -142,4 +142,17 @@ static inline int drm_debugfs_crtc_crc_add(struct drm_crtc
*crtc)
{
return 0;
}
+
#endif
+
+/* drm_syncobj.c */
+void drm_syncobj_open(struct drm_file *file_private);
+void drm_syncobj_release(struct drm_file *file_private);
+int drm_syncobj_create_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_private);
+int drm_syncobj_destroy_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
+int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
+int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
+
